From owner-freebsd-current@FreeBSD.ORG Sun Apr 24 01:21: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 8A2BB16A4CE for ; Sun, 24 Apr 2005 01:21:57 +0000 (GMT) Received: from gromit.dlib.vt.edu (gromit.dlib.vt.edu [128.173.49.29]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2667943D60 for ; Sun, 24 Apr 2005 01:21:57 +0000 (GMT) (envelope-from paul@gromit.dlib.vt.edu) Received: from zappa.Chelsea-Ct.Org (pool-70-110-10-69.roa.east.verizon.net [70.110.10.69]) by gromit.dlib.vt.edu (8.13.3/8.13.3) with ESMTP id j3O1LsZv019426 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sat, 23 Apr 2005 21:21:55 -0400 (EDT) (envelope-from paul@gromit.dlib.vt.edu) Received: from zappa.Chelsea-Ct.Org (localhost.Chelsea-Ct.Org [127.0.0.1]) by zappa.Chelsea-Ct.Org (8.13.3/8.13.3) with ESMTP id j3O1LmZ8071740 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sat, 23 Apr 2005 21:21:48 -0400 (EDT) (envelope-from paul@gromit.dlib.vt.edu) Received: (from paul@localhost) by zappa.Chelsea-Ct.Org (8.13.3/8.13.3/Submit) id j3O1Llxn071739 for freebsd-current@freebsd.org; Sat, 23 Apr 2005 21:21:47 -0400 (EDT) (envelope-from paul@gromit.dlib.vt.edu) X-Authentication-Warning: zappa.Chelsea-Ct.Org: paul set sender to paul@gromit.dlib.vt.edu using -f From: Paul Mather To: freebsd-current@freebsd.org Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Sat, 23 Apr 2005 21:21:46 -0400 Message-Id: <1114305707.71309.40.camel@zappa.Chelsea-Ct.Org> Mime-Version: 1.0 X-Mailer: Evolution 2.2.2 FreeBSD GNOME Team Port Subject: Fatal TIMEOUT - WRITE_DMA errors return with ATA Mk.III X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 24 Apr 2005 01:21:57 -0000 Since somewhere in the 5.x release cycle, my system has fallen prey to the "TIMEOUT - WRITE_DMA" errors which result in the drive becoming detached (which causes my geom_mirror to break and require rebuilding). According to smartctl and disk diagnostics, there's nothing wrong with my drives. Plus, the problem does not manifest itself under 4-STABLE. (I'm not the only one to have reported this problem.) Lately, I'd had success using a patch posted to freebsd-current by Ian Dowse. The "TIMEOUT - WRITE_DMA" errors still occurred, but they weren't fatal. I updated my kernel and world recently, and, alas, the "TIMEOUT - WRITE_DMA" problem has returned once more: ad0: TIMEOUT - WRITE_DMA retrying (2 retries left) LBA=49981679 ad0: FAILURE - device detached subdisk0: detached ad0: detached GEOM_MIRROR: Cannot update metadata on disk ad0 (error=5). GEOM_MIRROR: Cannot update metadata on disk ad0 (error=6). GEOM_MIRROR: Device raid1: provider ad0 disconnected. GEOM_MIRROR: Request failed (error=6). ad0[WRITE(offset=3847741440, length=16384)] Ian's patch was against the pre-ATA Mk.III regime. I doubt it is applicable to the ATA Mk.III rewrite. :-( Here is my system (re: ATA), FWIW: FreeBSD 6.0-CURRENT #0: Mon Apr 18 12:25:24 EDT 2005 paul@zappa.Chelsea-Ct.Org:/usr/obj/usr/src/sys/ZAPPA Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel Pentium III (698.39-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x683 Stepping = 3 Features=0x383f9ff real memory = 536870912 (512 MB) avail memory = 520253440 (496 MB) [[...]] atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x1440-0x144f at device 7.1 on pci0 ata0: on atapci0 ata1: on atapci0 [[...]] ad0: 24405MB at ata0-master UDMA33 acd0: DVDR at ata0-slave UDMA33 ad2: 24405MB at ata1-master UDMA33 acd1: CDRW at ata1-slave PIO4 My kernel has ATAPICAM support compiled in. Here is the pciconf -vl output for my ATA controller: atapci0@pci0:7:1: class=0x010180 card=0x00000000 chip=0x71118086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = '82371AB/EB/MB PIIX4/4E/4M IDE Controller' class = mass storage subclass = ATA It is in a Dell Dimension XPS T700r. Is there any way to up the number of retries to, say, 5, to see if this helps? Oh, well, welcome back "gmirror rebuild..." :-) Cheers, Paul. -- e-mail: paul@gromit.dlib.vt.edu "Without music to decorate it, time is just a bunch of boring production deadlines or dates by which bills must be paid." --- Frank Vincent Zappa From owner-freebsd-current@FreeBSD.ORG Sun Apr 24 02:24: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 BF88F16A4CE; Sun, 24 Apr 2005 02:24:43 +0000 (GMT) Received: from mx.toxahost.ru (ns.toxahost.ru [62.89.204.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id E1CBF43D4C; Sun, 24 Apr 2005 02:24:42 +0000 (GMT) (envelope-from toxa@toxahost.ru) Received: from localhost (laptoxa.toxa.lan [192.168.1.3]) by mx.toxahost.ru (Toxa) with ESMTP id A310D76; Sun, 24 Apr 2005 06:25:02 +0400 (MSD) Date: Sun, 24 Apr 2005 06:24:34 +0400 From: Toxa To: FreeBSD-CURRENT X-Comment-To: "Anton A. Karpov" Message-ID: <20050424022434.GA3384@laptoxa.toxa.lan> Mail-Followup-To: FreeBSD-CURRENT , freebsd-geom@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline User-Agent: Outluck Express 1.5.6i for MS-DOS 6.22-SMP X-Mailer: See User-Agent above :) X-Operating-System: MS-DOS 6.22-CURRENT on Sony VAIO laptop X-PGP-Public-Key: http://toxahost.ru/gpg/pubkey.asc X-Useless-Header: Do Androids Dream of Electric Sheep? cc: freebsd-geom@freebsd.org Subject: gmirror: Not all disks connected X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 24 Apr 2005 02:24:43 -0000 I've installed 5.4-rc3 recently and decided to play with geom gmirror. I have two fresh SAMSUNG SP0411N/TW100-11, so I've put it together and followed steps described in http://people.freebsd.org/~rse/mirror/. Everything was ok, but when I rebooted with "the final two-disk GEOM mirror setup", I've noticed what it's probably still one disk in gm0: Timecounter "TSC" frequency 1817908512 Hz quality 800 Timecounters tick every 10.000 msec ad0: 38203MB [77619/16/63] at ata0-master UDMA100 ad1: 38204MB [77622/16/63] at ata0-slave UDMA100 GEOM_MIRROR: Device gm0 created (id=2404813840). GEOM_MIRROR: Device gm0: provider ad1 detected. GEOM_MIRROR: Force device gm0 start due to timeout. GEOM_MIRROR: Device gm0: provider ad1 activated. GEOM_MIRROR: Device gm0: provider mirror/gm0 launched. Mounting root from ufs:/dev/mirror/gm0s1a Well, maybe I've lost last changes ang gmirror still lives with ad1 only? cymbal# gmirror list Geom name: gm0 State: DEGRADED Components: 2 Balance: round-robin Slice: 4096 Flags: NONE GenID: 0 SyncID: 3 ID: 2404813840 Providers: 1. Name: mirror/gm0 Mediasize: 40060403200 (37G) Sectorsize: 512 Mode: r7w7e2 Consumers: 1. Name: ad1 Mediasize: 40060403712 (37G) Sectorsize: 512 Mode: r1w1e1 State: ACTIVE Priority: 0 Flags: DIRTY GenID: 0 SyncID: 3 ID: 3247857729 When I tried to repeat last steps, I got message "Not all disks connected". cymbal# gmirror configure -a gm0 Not all disks connected. cymbal# gmirror status Name Status Components mirror/gm0 DEGRADED ad1 It seems like gmirror think I've lost ad0, but it's ok. I've tried to play with gmirror utility but in most cases I've got "Not all disk connected" message. Any help will be very appreciated. Thanks in advance. From owner-freebsd-current@FreeBSD.ORG Sun Apr 24 02:41: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 8FC2216A4CE for ; Sun, 24 Apr 2005 02:41:08 +0000 (GMT) Received: from mail.sorbs.net (news.sorbs.net [203.15.51.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id C044D43D31 for ; Sun, 24 Apr 2005 02:41:07 +0000 (GMT) (envelope-from matthew@uq.edu.au) Received: from [10.200.254.98] by nemesis.sorbs.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0IFF00K0GJH5J8@nemesis.sorbs.net> for freebsd-current@freebsd.org; Sun, 24 Apr 2005 12:41:30 +1000 (EST) Date: Sun, 24 Apr 2005 12:39:49 +1000 From: Matthew Sullivan In-reply-to: <20050423152223.Q68772@lexi.siliconlandmark.com> To: Andre Guibert de Bruet Message-id: <426B06F5.3030506@uq.edu.au> MIME-version: 1.0 Content-type: multipart/signed; boundary=------------ms030802030906030802040104; micalg=sha1; protocol="application/x-pkcs7-signature" X-Accept-Language: en User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041231 References: <4267A1CF.3080903@uq.edu.au> <20050422190208.M68772@lexi.siliconlandmark.com> <20050423020305.I68772@lexi.siliconlandmark.com> <426A20E5.5020604@uq.edu.au> <20050423152223.Q68772@lexi.siliconlandmark.com> cc: freebsd-current@freebsd.org Subject: Re: SMP on Compaq DL380 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 24 Apr 2005 02:41:08 -0000 This is a cryptographically signed message in MIME format. --------------ms030802030906030802040104 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Andre Guibert de Bruet wrote: > > On Sat, 23 Apr 2005, Matthew Sullivan wrote: > >> Andre Guibert de Bruet wrote: >> >>> On Sat, 23 Apr 2005, Matthew Sullivan wrote: >>> >>>> Andre Guibert de Bruet wrote: >>>> >>>>> On Thu, 21 Apr 2005, Matthew Sullivan wrote: >>>>> >>>>>> I've been reading about problems with HP/Compaq's regarding >>>>>> launching of second CPUs on SMP systems. >>>>>> >>>>>> I've been through the BIOS settings and there seems to be no >>>>>> settings to change the APCI table etc.... >>>>>> >>>>>> Now one thing that does seem common, when I have BIOS's with MP >>>>>> table version set to 1.4 FreeBSD doesn't report the second CPU >>>>>> being launched (even though it is seen in the acpidump).... When >>>>>> I set the BIOS to version 1.2 of the MP table the second CPU is >>>>>> reported and launched. >>>>>> >>>>>> Now the Compaq DL380's I have done seem to have the ability to >>>>>> set 1.4 or 1.2 of the table ... mptable reports 1.4... (below) >>>>>> >>>>>> Any suggestions on how to launch the second CPU...? >>>>> >>>>> >>>>> Make a boot -v from this machine available. >>>> >>>> >>>> http://scorpion.sorbs.net/dmesg.txt >>> >>> >>> The lack of the following seems to indicate that you do not have >>> "device apic" enabled in your kernel config (You need "options SMP" >>> as well to get FreeBSD to do more than just recognize both CPUs): >>> >>> FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs >>> cpu0 (BSP): APIC ID: 0 >>> cpu1 (AP): APIC ID: >>> >>> Please share your config and the steps that you are taking to build >>> your kernel. >> >> >> /usr/src/sys/i386/conf/SCORPION has been copied to: >> http://scorpion.sorbs.net/SCORPION >> >> /etc/make.conf contains 'KERNCONF=SCORPION' >> then I follow the instructions in the Makefile.... >> >> cd /usr/src >> make buildworld >> make buildkernel >> make installkernel >> reboot >> mergemaster -p >> make installworld >> mergemaster >> reboot >> >> (before I read the man page for make.conf I was using >> KERNCONF=SCORPION in the appropriate places on the command line) > > > The dmesg shows that you compiled the kernel using this config file > anyway. All is good so far. > > Processors: APIC ID Version State Family Model > Step Flags > 0 0x10 BSP, usable 6 2 1 0x0381 > 0 0x10 AP, usable 6 8 6 0x383fbff > > The APIC IDs here are the same. The flags on the would-be AP are what > I would expect for a recent i686. The BSP barely qualify it to be a > gen-1 Pentium. I wouldn't trust any of the values being reported. > Could you obtain the real identity of these CPUs and confirm that > they're not mismatched? The easy way of doing this if your BIOS > doesn't post this information is using a Knoppix LiveCD and doing a > cat /proc/cpuinfo. Ok can't do the knoppix thing atm, however... CPU0 -> 866/256/133/1.65v SL47S CPU1 -> 866/256/133/1.70v SL48V Both are shown detected by the BIOS, and both are shown as 866MHz 133MHz busses, and 256k cache (as one would expect) > > If both CPUs are reporting the same ID, I can see how we're not > launching the second proc; We assume that ID 0 is the BSP and > additional processors have different APIC IDs. Is something really > borked here? Yep! But the acpidump -t shows 2 different ID's.... Regards, Mat -- Matthew Sullivan Specialist Systems Programmer Information Technology Services The University of Queensland --------------ms030802030906030802040104 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIG7DCC A3IwggJaoAMCAQICASowDQYJKoZIhvcNAQEEBQAwgaMxCzAJBgNVBAYTAkFVMRMwEQYDVQQI EwpRdWVlbnNsYW5kMREwDwYDVQQHEwhCcmlzYmFuZTElMCMGA1UEChMcVGhlIFVuaXZlcnNp dHkgb2YgUXVlZW5zbGFuZDEoMCYGA1UECxMfSW5mb3JtYXRpb24gVGVjaG5vbG9neSBTZXJ2 aWNlczEbMBkGA1UEAxMSQ2VydGlmaWNhdGUgU2VydmVyMB4XDTA0MDEyMTIzMzYyMVoXDTA2 MDEyMTIzMzYyMVowgbIxCzAJBgNVBAYTAkFVMSUwIwYDVQQKExxUaGUgVW5pdmVyc2l0eSBv ZiBRdWVlbnNsYW5kMScwJQYDVQQLEx5JbmZvcm1hdGlvbiBUZWNub2xvZ3kgU2VydmljZXMx FjAUBgoJkiaJk/IsZAEBEwZjY21hdHQxGTAXBgNVBAMTEE1hdHRoZXcgU3VsbGl2YW4xIDAe BgkqhkiG9w0BCQEWEW1hdHRoZXdAdXEuZWR1LmF1MFwwDQYJKoZIhvcNAQEBBQADSwAwSAJB AJsUfrw/QUqKIzDverWc2F4GFFRZmIeO+bAl+7BM6x/9frMzOtygx4QGb4oQwtOE8Sda1aIs v+yJF3Di9EuUyvMCAwEAAaNoMGYwDgYDVR0PAQH/BAQDAgXgMBEGCWCGSAGG+EIBAQQEAwIF oDAfBgNVHSMEGDAWgBQmqtoyueiWTYZBinvsnzeOWLtUuzAgBgNVHREEGTAXgRVtYXR0aGV3 QGl0cy51cS5lZHUuYXUwDQYJKoZIhvcNAQEEBQADggEBAF2gZrkqZsZlHd4K/+yBN6qrpD61 hctDf7/Eg4jk6DMknEs6nvHMFUMZ4SXvkqPLnHBygTARKAs7qBSLd7mUUBOOQEgk6ovQVY6S 1CDSt3P9O6wjG0K1igtk8v6u7lkQ8p2STXqrOePVINdaucUgBO/IpeUtt9ATl1qvPTWyM/fz oUZsIKeYjNQVEQsuimrZjdbIAFxdl1fggSngUv64wBn8wCssGrPZIZA2lpBBEW1wejoWrDOH IIr+SspGd0i8MovDTMRSvgTERLki17FU/ANilcrSXiODKeIvpXhnQqVScnsoMSZmBmN2QIoG SnBjNK5mYxx5E3v20VOwtP1hVdEwggNyMIICWqADAgECAgEqMA0GCSqGSIb3DQEBBAUAMIGj MQswCQYDVQQGEwJBVTETMBEGA1UECBMKUXVlZW5zbGFuZDERMA8GA1UEBxMIQnJpc2JhbmUx JTAjBgNVBAoTHFRoZSBVbml2ZXJzaXR5IG9mIFF1ZWVuc2xhbmQxKDAmBgNVBAsTH0luZm9y bWF0aW9uIFRlY2hub2xvZ3kgU2VydmljZXMxGzAZBgNVBAMTEkNlcnRpZmljYXRlIFNlcnZl cjAeFw0wNDAxMjEyMzM2MjFaFw0wNjAxMjEyMzM2MjFaMIGyMQswCQYDVQQGEwJBVTElMCMG A1UEChMcVGhlIFVuaXZlcnNpdHkgb2YgUXVlZW5zbGFuZDEnMCUGA1UECxMeSW5mb3JtYXRp b24gVGVjbm9sb2d5IFNlcnZpY2VzMRYwFAYKCZImiZPyLGQBARMGY2NtYXR0MRkwFwYDVQQD ExBNYXR0aGV3IFN1bGxpdmFuMSAwHgYJKoZIhvcNAQkBFhFtYXR0aGV3QHVxLmVkdS5hdTBc MA0GCSqGSIb3DQEBAQUAA0sAMEgCQQCbFH68P0FKiiMw73q1nNheBhRUWZiHjvmwJfuwTOsf /X6zMzrcoMeEBm+KEMLThPEnWtWiLL/siRdw4vRLlMrzAgMBAAGjaDBmMA4GA1UdDwEB/wQE AwIF4DARBglghkgBhvhCAQEEBAMCBaAwHwYDVR0jBBgwFoAUJqraMrnolk2GQYp77J83jli7 VLswIAYDVR0RBBkwF4EVbWF0dGhld0BpdHMudXEuZWR1LmF1MA0GCSqGSIb3DQEBBAUAA4IB AQBdoGa5KmbGZR3eCv/sgTeqq6Q+tYXLQ3+/xIOI5OgzJJxLOp7xzBVDGeEl75Kjy5xwcoEw ESgLO6gUi3e5lFATjkBIJOqL0FWOktQg0rdz/TusIxtCtYoLZPL+ru5ZEPKdkk16qznj1SDX WrnFIATvyKXlLbfQE5darz01sjP386FGbCCnmIzUFRELLopq2Y3WyABcXZdX4IEp4FL+uMAZ /MArLBqz2SGQNpaQQRFtcHo6FqwzhyCK/krKRndIvDKLw0zEUr4ExES5ItexVPwDYpXK0l4j gyniL6V4Z0KlUnJ7KDEmZgZjdkCKBkpwYzSuZmMceRN79tFTsLT9YVXRMYIDQDCCAzwCAQEw gakwgaMxCzAJBgNVBAYTAkFVMRMwEQYDVQQIEwpRdWVlbnNsYW5kMREwDwYDVQQHEwhCcmlz YmFuZTElMCMGA1UEChMcVGhlIFVuaXZlcnNpdHkgb2YgUXVlZW5zbGFuZDEoMCYGA1UECxMf SW5mb3JtYXRpb24gVGVjaG5vbG9neSBTZXJ2aWNlczEbMBkGA1UEAxMSQ2VydGlmaWNhdGUg U2VydmVyAgEqMAkGBSsOAwIaBQCgggItMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ KoZIhvcNAQkFMQ8XDTA1MDQyNDAyMzk0OVowIwYJKoZIhvcNAQkEMRYEFHeHARGWxyw2h1sr iITknrTPnJuAMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIG6BgkrBgEEAYI3EAQx gawwgakwgaMxCzAJBgNVBAYTAkFVMRMwEQYDVQQIEwpRdWVlbnNsYW5kMREwDwYDVQQHEwhC cmlzYmFuZTElMCMGA1UEChMcVGhlIFVuaXZlcnNpdHkgb2YgUXVlZW5zbGFuZDEoMCYGA1UE CxMfSW5mb3JtYXRpb24gVGVjaG5vbG9neSBTZXJ2aWNlczEbMBkGA1UEAxMSQ2VydGlmaWNh dGUgU2VydmVyAgEqMIG8BgsqhkiG9w0BCRACCzGBrKCBqTCBozELMAkGA1UEBhMCQVUxEzAR BgNVBAgTClF1ZWVuc2xhbmQxETAPBgNVBAcTCEJyaXNiYW5lMSUwIwYDVQQKExxUaGUgVW5p dmVyc2l0eSBvZiBRdWVlbnNsYW5kMSgwJgYDVQQLEx9JbmZvcm1hdGlvbiBUZWNobm9sb2d5 IFNlcnZpY2VzMRswGQYDVQQDExJDZXJ0aWZpY2F0ZSBTZXJ2ZXICASowDQYJKoZIhvcNAQEB BQAEQC4BzJebELW/eLTG0G1B29R3PTvZc11JBUeKMQQZHA4eMVWJ6usU+he9ILZSY4BwlUpQ W0pevXWthc0sV/xo0DQAAAAAAAA= --------------ms030802030906030802040104-- From owner-freebsd-current@FreeBSD.ORG Sun Apr 24 03:04: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 CB98716A4CE; Sun, 24 Apr 2005 03:04:45 +0000 (GMT) Received: from lexi.siliconlandmark.com (lexi.siliconlandmark.com [209.69.98.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4A6A243D2F; Sun, 24 Apr 2005 03:04:45 +0000 (GMT) (envelope-from andy@siliconlandmark.com) Received: from lexi.siliconlandmark.com (localhost [127.0.0.1]) j3O34cXP004372; Sat, 23 Apr 2005 23:04:38 -0400 (EDT) (envelope-from andy@siliconlandmark.com) Received: from localhost (andy@localhost)j3O34bMH004369; Sat, 23 Apr 2005 23:04:38 -0400 (EDT) (envelope-from andy@siliconlandmark.com) X-Authentication-Warning: lexi.siliconlandmark.com: andy owned process doing -bs Date: Sat, 23 Apr 2005 23:04:37 -0400 (EDT) From: Andre Guibert de Bruet To: Matthew Sullivan In-Reply-To: <426B06F5.3030506@uq.edu.au> Message-ID: <20050423224317.D68772@lexi.siliconlandmark.com> References: <4267A1CF.3080903@uq.edu.au> <20050422190208.M68772@lexi.siliconlandmark.com> <426A20E5.5020604@uq.edu.au><426B06F5.3030506@uq.edu.au> 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.539, required 6, autolearn=not spam, AWL 0.06, BAYES_00 -2.60) X-MailScanner-From: andy@siliconlandmark.com cc: njl@freebsd.org cc: freebsd-current@freebsd.org Subject: Re: SMP on Compaq DL380 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 24 Apr 2005 03:04:45 -0000 On Sun, 24 Apr 2005, Matthew Sullivan wrote: > Andre Guibert de Bruet wrote: > >> Processors: APIC ID Version State Family Model Step >> Flags >> 0 0x10 BSP, usable 6 2 1 0x0381 >> 0 0x10 AP, usable 6 8 6 0x383fbff >> >> The APIC IDs here are the same. The flags on the would-be AP are what I >> would expect for a recent i686. The BSP barely qualify it to be a gen-1 >> Pentium. I wouldn't trust any of the values being reported. Could you >> obtain the real identity of these CPUs and confirm that they're not >> mismatched? The easy way of doing this if your BIOS doesn't post this >> information is using a Knoppix LiveCD and doing a cat /proc/cpuinfo. > > Ok can't do the knoppix thing atm, however... > > CPU0 -> 866/256/133/1.65v SL47S > CPU1 -> 866/256/133/1.70v SL48V > > Both are shown detected by the BIOS, and both are shown as 866MHz 133MHz > busses, and 256k cache (as one would expect) > >> If both CPUs are reporting the same ID, I can see how we're not launching >> the second proc; We assume that ID 0 is the BSP and additional processors >> have different APIC IDs. Is something really borked here? Yep! > > But the acpidump -t shows 2 different ID's.... I don't know the way our ACPI implementation handles the information found in the tables well enough to be able to tell you exactly what we do with the IDs that are found in that dump. That's Nate Lawson's domain (I added him to the CC-list). >From your dmesg, it doesn't even appear that we're seeing the second CPU listed in your DSDT. There is only one reference of: cpu: on acpi0 Andy | Andre Guibert de Bruet | Enterprise Software Consultant > | Silicon Landmark, LLC. | http://siliconlandmark.com/ > From owner-freebsd-current@FreeBSD.ORG Sun Apr 24 03:11: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 5D81516A4CE; Sun, 24 Apr 2005 03:11:44 +0000 (GMT) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id C8F1C43D5A; Sun, 24 Apr 2005 03:11: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 j3O3BgXm092765; Sat, 23 Apr 2005 23:11:42 -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 j3O3Bhs0028746; Sat, 23 Apr 2005 23:11:43 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id E032E7306E; Sat, 23 Apr 2005 23:11:42 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050424031142.E032E7306E@freebsd-current.sentex.ca> Date: Sat, 23 Apr 2005 23:11: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 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: Sun, 24 Apr 2005 03:11:44 -0000 TB --- 2005-04-24 01:31:44 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-04-24 01:31:44 - starting CURRENT tinderbox run for amd64/amd64 TB --- 2005-04-24 01:31:44 - checking out the source tree TB --- 2005-04-24 01:31:44 - cd /home/tinderbox/CURRENT/amd64/amd64 TB --- 2005-04-24 01:31:44 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-04-24 01:38:22 - building world (CFLAGS=-O2 -pipe) TB --- 2005-04-24 01:38:22 - cd /home/tinderbox/CURRENT/amd64/amd64/src TB --- 2005-04-24 01:38:22 - /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-24 02:51:49 - building generic kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-04-24 02:51:49 - cd /home/tinderbox/CURRENT/amd64/amd64/src TB --- 2005-04-24 02:51:49 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Sun Apr 24 02:51:50 UTC 2005 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for GENERIC completed on Sun Apr 24 03:07:25 UTC 2005 TB --- 2005-04-24 03:07:25 - generating LINT kernel config TB --- 2005-04-24 03:07:25 - cd /home/tinderbox/CURRENT/amd64/amd64/src/sys/amd64/conf TB --- 2005-04-24 03:07:25 - /usr/bin/make -B LINT TB --- 2005-04-24 03:07:25 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-04-24 03:07:25 - cd /home/tinderbox/CURRENT/amd64/amd64/src TB --- 2005-04-24 03:07:25 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Apr 24 03:07:25 UTC 2005 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/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 -I/tinderbox/CURRENT/amd64/amd64/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 -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-ta bles -ffreestanding -Werror /tinderbox/CURRENT/amd64/amd64/src/sys/dev/acpica/Osd/OsdDebug.c In file included from /tinderbox/CURRENT/amd64/amd64/src/sys/dev/acpica/Osd/OsdDebug.c:45: /tinderbox/CURRENT/amd64/amd64/src/sys/dev/acpica/acpivar.h:425:1: "ACPI_MAX_THREADS" redefined In file included from /tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/acpica/acfreebsd.h:128, from /tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/acpica/acenv.h:208, from /tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/acpica/acpi.h:126, from /tinderbox/CURRENT/amd64/amd64/src/sys/dev/acpica/Osd/OsdDebug.c:43: ./opt_acpi.h:2:1: this is the location of the previous definition *** Error code 1 Stop in /tinderbox/CURRENT/amd64/amd64/obj/amd64/tinderbox/CURRENT/amd64/amd64/src/sys/LINT. *** Error code 1 Stop in /tinderbox/CURRENT/amd64/amd64/src. *** Error code 1 Stop in /tinderbox/CURRENT/amd64/amd64/src. TB --- 2005-04-24 03:11:42 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-04-24 03:11:42 - ERROR: failed to build lint kernel TB --- 2005-04-24 03:11:42 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Sun Apr 24 05:05: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 2346316A4CE; Sun, 24 Apr 2005 05:05:20 +0000 (GMT) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8A31643D3F; Sun, 24 Apr 2005 05:05: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 j3O55ID4094658; Sun, 24 Apr 2005 01:05:19 -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 j3O55Ikf024694; Sun, 24 Apr 2005 01:05:18 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 96AAA7306E; Sun, 24 Apr 2005 01:05:18 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050424050518.96AAA7306E@freebsd-current.sentex.ca> Date: Sun, 24 Apr 2005 01:05:18 -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: Sun, 24 Apr 2005 05:05:20 -0000 TB --- 2005-04-24 03:11:43 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-04-24 03:11:43 - starting CURRENT tinderbox run for i386/i386 TB --- 2005-04-24 03:11:43 - checking out the source tree TB --- 2005-04-24 03:11:43 - cd /home/tinderbox/CURRENT/i386/i386 TB --- 2005-04-24 03:11:43 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-04-24 03:18:30 - building world (CFLAGS=-O2 -pipe) TB --- 2005-04-24 03:18:30 - cd /home/tinderbox/CURRENT/i386/i386/src TB --- 2005-04-24 03:18: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 TB --- 2005-04-24 04:33:11 - building generic kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-04-24 04:33:11 - cd /home/tinderbox/CURRENT/i386/i386/src TB --- 2005-04-24 04:33:11 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Sun Apr 24 04:33: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 >>> Kernel build for GENERIC completed on Sun Apr 24 04:58:18 UTC 2005 TB --- 2005-04-24 04:58:18 - generating LINT kernel config TB --- 2005-04-24 04:58:18 - cd /home/tinderbox/CURRENT/i386/i386/src/sys/i386/conf TB --- 2005-04-24 04:58:18 - /usr/bin/make -B LINT TB --- 2005-04-24 04:58:18 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-04-24 04:58:18 - cd /home/tinderbox/CURRENT/i386/i386/src TB --- 2005-04-24 04:58:18 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Apr 24 04:58:20 UTC 2005 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/CURRENT/i386/i386/src/sys -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/altq -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/pf -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/ngatm -I/tinderbox/CURRENT/i386/i386/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 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -ffreestanding -Werror -fi nstrument-functions -Wno-inline /tinderbox/CURRENT/i386/i386/src/sys/dev/acpi_support/acpi_asus.c In file included from /tinderbox/CURRENT/i386/i386/src/sys/dev/acpi_support/acpi_asus.c:51: /tinderbox/CURRENT/i386/i386/src/sys/dev/acpica/acpivar.h:425:1: "ACPI_MAX_THREADS" redefined In file included from /tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/acpica/acfreebsd.h:128, from /tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/acpica/acenv.h:208, from /tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/acpica/acpi.h:126, from /tinderbox/CURRENT/i386/i386/src/sys/dev/acpi_support/acpi_asus.c:50: ./opt_acpi.h:2:1: this is the location of the previous definition *** Error code 1 Stop in /tinderbox/CURRENT/i386/i386/obj/tinderbox/CURRENT/i386/i386/src/sys/LINT. *** Error code 1 Stop in /tinderbox/CURRENT/i386/i386/src. *** Error code 1 Stop in /tinderbox/CURRENT/i386/i386/src. TB --- 2005-04-24 05:05:17 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-04-24 05:05:17 - ERROR: failed to build lint kernel TB --- 2005-04-24 05:05:17 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Sun Apr 24 09:10: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 141B116A4CE for ; Sun, 24 Apr 2005 09:10:11 +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 4E02543D3F for ; Sun, 24 Apr 2005 09:10:10 +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 j3O99hrI038159; Sun, 24 Apr 2005 11:09:43 +0200 (CEST) (envelope-from sos@DeepCore.dk) Message-ID: <426B61FF.80001@DeepCore.dk> Date: Sun, 24 Apr 2005 11:08:15 +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: Paul Mather References: <1114305707.71309.40.camel@zappa.Chelsea-Ct.Org> In-Reply-To: <1114305707.71309.40.camel@zappa.Chelsea-Ct.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: Fatal TIMEOUT - WRITE_DMA errors return with ATA Mk.III X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 24 Apr 2005 09:10:11 -0000 Paul Mather wrote: > Since somewhere in the 5.x release cycle, my system has fallen prey to > the "TIMEOUT - WRITE_DMA" errors which result in the drive becoming > detached (which causes my geom_mirror to break and require rebuilding).= > According to smartctl and disk diagnostics, there's nothing wrong with > my drives. Plus, the problem does not manifest itself under 4-STABLE. > (I'm not the only one to have reported this problem.) >=20 > Lately, I'd had success using a patch posted to freebsd-current by Ian > Dowse. The "TIMEOUT - WRITE_DMA" errors still occurred, but they > weren't fatal. I updated my kernel and world recently, and, alas, the > "TIMEOUT - WRITE_DMA" problem has returned once more: You should try a recent -current, I committed cleanups to the timeout=20 system on the 21'st. You might still have timeouts (which might due to=20 non-ATA issues) but they should not be fatal unless the HW really does=20 screw up.. --=20 -S=F8ren From owner-freebsd-current@FreeBSD.ORG Sun Apr 24 09:37: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 88AAF16A4CE for ; Sun, 24 Apr 2005 09:37:21 +0000 (GMT) Received: from pinus.cc.fer.hr (pinus.cc.fer.hr [161.53.73.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8B1C643D54 for ; Sun, 24 Apr 2005 09:37:20 +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 j3O9cIhE008865; Sun, 24 Apr 2005 11:38:19 +0200 (MEST) Message-ID: <426B68B6.7000709@fer.hr> Date: Sun, 24 Apr 2005 11:36:54 +0200 From: Ivan Voras User-Agent: Mozilla Thunderbird 1.0 (X11/20041213) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Matthew Sullivan , current@freebsd.org References: <4267A1CF.3080903@uq.edu.au> <20050422190208.M68772@lexi.siliconlandmark.com> <20050423020305.I68772@lexi.siliconlandmark.com> <426A20E5.5020604@uq.edu.au> <20050423152223.Q68772@lexi.siliconlandmark.com> <426B06F5.3030506@uq.edu.au> In-Reply-To: <426B06F5.3030506@uq.edu.au> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: SMP on Compaq DL380 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 24 Apr 2005 09:37:21 -0000 Matthew Sullivan wrote: >> they're not mismatched? The easy way of doing this if your BIOS >> doesn't post this information is using a Knoppix LiveCD and doing a >> cat /proc/cpuinfo. > > > Ok can't do the knoppix thing atm, however... Would ports/misc/cpuid help? From owner-freebsd-current@FreeBSD.ORG Sun Apr 24 09:43: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 6320E16A4CE; Sun, 24 Apr 2005 09:43:45 +0000 (GMT) Received: from darkness.comp.waw.pl (darkness.comp.waw.pl [195.117.238.136]) by mx1.FreeBSD.org (Postfix) with ESMTP id DC61043D48; Sun, 24 Apr 2005 09:43:44 +0000 (GMT) (envelope-from pjd@darkness.comp.waw.pl) Received: by darkness.comp.waw.pl (Postfix, from userid 1009) id B038DACAEE; Sun, 24 Apr 2005 11:43:43 +0200 (CEST) Date: Sun, 24 Apr 2005 11:43:43 +0200 From: Pawel Jakub Dawidek To: FreeBSD-CURRENT , freebsd-geom@freebsd.org Message-ID: <20050424094343.GA837@darkness.comp.waw.pl> References: <20050424022434.GA3384@laptoxa.toxa.lan> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="c5jIKqLJqsIKqNdf" Content-Disposition: inline In-Reply-To: <20050424022434.GA3384@laptoxa.toxa.lan> 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 Subject: Re: gmirror: Not all disks connected X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 24 Apr 2005 09:43:45 -0000 --c5jIKqLJqsIKqNdf Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Apr 24, 2005 at 06:24:34AM +0400, Toxa wrote: +> I've installed 5.4-rc3 recently and decided to play with geom gmirror. I +> have two fresh SAMSUNG SP0411N/TW100-11, so I've put it together and +> followed steps described in http://people.freebsd.org/~rse/mirror/. +> Everything was ok, but when I rebooted with "the final two-disk GEOM +> mirror setup", I've noticed what it's probably still one disk in gm0: +>=20 +> Timecounter "TSC" frequency 1817908512 Hz quality 800 +> Timecounters tick every 10.000 msec +> ad0: 38203MB [77619/16/63] at ata0-master +> UDMA100 +> ad1: 38204MB [77622/16/63] at ata0-slave +> UDMA100 +> GEOM_MIRROR: Device gm0 created (id=3D2404813840). +> GEOM_MIRROR: Device gm0: provider ad1 detected. +> GEOM_MIRROR: Force device gm0 start due to timeout. +> GEOM_MIRROR: Device gm0: provider ad1 activated. +> GEOM_MIRROR: Device gm0: provider mirror/gm0 launched. +> Mounting root from ufs:/dev/mirror/gm0s1a +>=20 +>=20 +> Well, maybe I've lost last changes ang gmirror still lives with ad1 only= ?=20 +>=20 +> cymbal# gmirror list +> Geom name: gm0 +> State: DEGRADED +> Components: 2 +> Balance: round-robin +> Slice: 4096 +> Flags: NONE +> GenID: 0 +> SyncID: 3 +> ID: 2404813840 +> Providers: +> 1. Name: mirror/gm0 +> Mediasize: 40060403200 (37G) +> Sectorsize: 512 +> Mode: r7w7e2 +> Consumers: +> 1. Name: ad1 +> Mediasize: 40060403712 (37G) +> Sectorsize: 512 +> Mode: r1w1e1 +> State: ACTIVE +> Priority: 0 +> Flags: DIRTY +> GenID: 0 +> SyncID: 3 +> ID: 3247857729 +>=20 +>=20 +> When I tried to repeat last steps, I got message "Not all disks connecte= d". +>=20 +> cymbal# gmirror configure -a gm0 +> Not all disks connected. +> cymbal# gmirror status +> Name Status Components +> mirror/gm0 DEGRADED ad1 +>=20 +>=20 +> It seems like gmirror think I've lost ad0, but it's ok. +> I've tried to play with gmirror utility but in most cases I've got "Not +> all disk connected" message. Please read description of 'forget' subcommand. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --c5jIKqLJqsIKqNdf Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFCa2pPForvXbEpPzQRAtl3AJ93IKlXe21+NQHadFtFNW4dwmVjEQCePswU SmxIVuYaHJR/38/6mpe3pOk= =Ewse -----END PGP SIGNATURE----- --c5jIKqLJqsIKqNdf-- From owner-freebsd-current@FreeBSD.ORG Sun Apr 24 10:16: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 6F7FE16A4CF for ; Sun, 24 Apr 2005 10:16:54 +0000 (GMT) Received: from mail.gmx.net (pop.gmx.net [213.165.64.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 7459643D41 for ; Sun, 24 Apr 2005 10:16:53 +0000 (GMT) (envelope-from shoesoft@gmx.net) Received: (qmail invoked by alias); 24 Apr 2005 10:16:50 -0000 Received: from M118P012.dipool.highway.telekom.at (EHLO localhost.localdomain) [62.46.4.172] by mail.gmx.net (mp005) with SMTP; 24 Apr 2005 12:16:50 +0200 X-Authenticated: #16703784 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, 24 Apr 2005 12:11:50 +0200 Message-Id: <1114337510.1178.1.camel@taxman.pepperland> Mime-Version: 1.0 X-Mailer: Evolution 2.2.2 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 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, 24 Apr 2005 10:16:54 -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? > 2. Did suspend/resume work after Mk III? > 3. Can you provide any information about hardware you're running? Just for the archives: With the latest commmits by sos, everything works fine again. Thanks. From owner-freebsd-current@FreeBSD.ORG Sun Apr 24 10:31: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 1464416A4CE for ; Sun, 24 Apr 2005 10:31:57 +0000 (GMT) Received: from lexi.siliconlandmark.com (lexi.siliconlandmark.com [209.69.98.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7232443D4C for ; Sun, 24 Apr 2005 10:31:56 +0000 (GMT) (envelope-from andy@siliconlandmark.com) Received: from lexi.siliconlandmark.com (localhost [127.0.0.1]) j3OAVk14010809; Sun, 24 Apr 2005 06:31:46 -0400 (EDT) (envelope-from andy@siliconlandmark.com) Received: from localhost (andy@localhost)j3OAVkFA010806; Sun, 24 Apr 2005 06:31:46 -0400 (EDT) (envelope-from andy@siliconlandmark.com) X-Authentication-Warning: lexi.siliconlandmark.com: andy owned process doing -bs Date: Sun, 24 Apr 2005 06:31:46 -0400 (EDT) From: Andre Guibert de Bruet To: Ivan Voras In-Reply-To: <426B68B6.7000709@fer.hr> Message-ID: <20050424062311.T68772@lexi.siliconlandmark.com> References: <4267A1CF.3080903@uq.edu.au> <20050422190208.M68772@lexi.siliconlandmark.com> <426A20E5.5020604@uq.edu.au><426B06F5.3030506@uq.edu.au> <426B68B6.7000709@fer.hr> 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.542, required 6, autolearn=not spam, AWL 0.06, BAYES_00 -2.60) X-MailScanner-From: andy@siliconlandmark.com cc: Matthew Sullivan cc: current@freebsd.org Subject: Re: SMP on Compaq DL380 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 24 Apr 2005 10:31:57 -0000 On Sun, 24 Apr 2005, Ivan Voras wrote: > Matthew Sullivan wrote: > >>> they're not mismatched? The easy way of doing this if your BIOS doesn't >>> post this information is using a Knoppix LiveCD and doing a cat >>> /proc/cpuinfo. >> >> >> Ok can't do the knoppix thing atm, however... > > Would ports/misc/cpuid help? On my dual xeon desktop, cpuid reports on APIC ID 6 only (The AP); which seems to indicate that it reports only on the first processor it finds. Unfortunately, the program doesn't make use of any command line args which could enable alternate behavior. I guess someone should bug the author to fix this. Andy | Andre Guibert de Bruet | Enterprise Software Consultant > | Silicon Landmark, LLC. | http://siliconlandmark.com/ > From owner-freebsd-current@FreeBSD.ORG Sun Apr 24 10:41: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 358C316A4CE for ; Sun, 24 Apr 2005 10:41:11 +0000 (GMT) Received: from mail.sorbs.net (mail.sorbs.net [203.15.51.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9223D43D41 for ; Sun, 24 Apr 2005 10:41:10 +0000 (GMT) (envelope-from matthew@uq.edu.au) Received: from [10.200.254.98] by nemesis.sorbs.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0IFG00C055P876@nemesis.sorbs.net> for current@freebsd.org; Sun, 24 Apr 2005 20:41:33 +1000 (EST) Date: Sun, 24 Apr 2005 20:39:50 +1000 From: Matthew Sullivan In-reply-to: <426B68B6.7000709@fer.hr> To: Ivan Voras Message-id: <426B7776.6060908@uq.edu.au> MIME-version: 1.0 Content-type: multipart/signed; boundary=------------ms060909080208050706090302; micalg=sha1; protocol="application/x-pkcs7-signature" X-Accept-Language: en User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041231 References: <4267A1CF.3080903@uq.edu.au> <20050422190208.M68772@lexi.siliconlandmark.com> <20050423020305.I68772@lexi.siliconlandmark.com> <426A20E5.5020604@uq.edu.au> <20050423152223.Q68772@lexi.siliconlandmark.com> <426B06F5.3030506@uq.edu.au> <426B68B6.7000709@fer.hr> cc: current@freebsd.org Subject: Re: SMP on Compaq DL380 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 24 Apr 2005 10:41:11 -0000 This is a cryptographically signed message in MIME format. --------------ms060909080208050706090302 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Ivan Voras wrote: > Matthew Sullivan wrote: > >>> they're not mismatched? The easy way of doing this if your BIOS >>> doesn't post this information is using a Knoppix LiveCD and doing a >>> cat /proc/cpuinfo. >> >> >> >> Ok can't do the knoppix thing atm, however... > > > Would ports/misc/cpuid help? > _______________________________________________ > 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" Probably not much help... eax in eax ebx ecx edx 00000000 00000002 756e6547 6c65746e 49656e69 00000001 00000683 00000002 00000000 0383f9ff 00000002 03020101 00000000 00000000 0c040882 Vendor ID: "GenuineIntel"; CPUID level 2 Intel-specific functions: Version 00000683: Type 0 - Original OEM Family 6 - Pentium Pro Model 8 - Pentium III/Pentium III Xeon - internal L2 cache Stepping 3 Reserved 0 Brand index: 2 [Pentium III processor] Feature flags 0383f9ff: FPU Floating Point Unit VME Virtual 8086 Mode Enhancements DE Debugging Extensions PSE Page Size Extensions TSC Time Stamp Counter MSR Model Specific Registers PAE Physical Address Extension MCE Machine Check Exception CX8 COMPXCHG8B Instruction SEP Fast System Call MTRR Memory Type Range Registers PGE PTE Global Flag MCA Machine Check Architecture CMOV Conditional Move and Compare Instructions FGPAT Page Attribute Table PSE-36 36-bit Page Size Extension MMX MMX instruction set FXSR Fast FP/MMX Streaming SIMD Extensions save/restore SSE Streaming SIMD Extensions instruction set TLB and cache info: 01: Instruction TLB: 4KB pages, 4-way set assoc, 32 entries 02: Instruction TLB: 4MB pages, 4-way set assoc, 2 entries 03: Data TLB: 4KB pages, 4-way set assoc, 64 entries 82: 2nd-level cache: 256KB, 8-way set assoc, 32 byte line size 08: 1st-level instruction cache: 16KB, 4-way set assoc, 32 byte line size 04: Data TLB: 4MB pages, 4-way set assoc, 8 entries 0c: 1st-level data cache: 16KB, 4-way set assoc, 32 byte line size -- Matthew Sullivan Specialist Systems Programmer Information Technology Services The University of Queensland --------------ms060909080208050706090302 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIG7DCC A3IwggJaoAMCAQICASowDQYJKoZIhvcNAQEEBQAwgaMxCzAJBgNVBAYTAkFVMRMwEQYDVQQI EwpRdWVlbnNsYW5kMREwDwYDVQQHEwhCcmlzYmFuZTElMCMGA1UEChMcVGhlIFVuaXZlcnNp dHkgb2YgUXVlZW5zbGFuZDEoMCYGA1UECxMfSW5mb3JtYXRpb24gVGVjaG5vbG9neSBTZXJ2 aWNlczEbMBkGA1UEAxMSQ2VydGlmaWNhdGUgU2VydmVyMB4XDTA0MDEyMTIzMzYyMVoXDTA2 MDEyMTIzMzYyMVowgbIxCzAJBgNVBAYTAkFVMSUwIwYDVQQKExxUaGUgVW5pdmVyc2l0eSBv ZiBRdWVlbnNsYW5kMScwJQYDVQQLEx5JbmZvcm1hdGlvbiBUZWNub2xvZ3kgU2VydmljZXMx FjAUBgoJkiaJk/IsZAEBEwZjY21hdHQxGTAXBgNVBAMTEE1hdHRoZXcgU3VsbGl2YW4xIDAe BgkqhkiG9w0BCQEWEW1hdHRoZXdAdXEuZWR1LmF1MFwwDQYJKoZIhvcNAQEBBQADSwAwSAJB AJsUfrw/QUqKIzDverWc2F4GFFRZmIeO+bAl+7BM6x/9frMzOtygx4QGb4oQwtOE8Sda1aIs v+yJF3Di9EuUyvMCAwEAAaNoMGYwDgYDVR0PAQH/BAQDAgXgMBEGCWCGSAGG+EIBAQQEAwIF oDAfBgNVHSMEGDAWgBQmqtoyueiWTYZBinvsnzeOWLtUuzAgBgNVHREEGTAXgRVtYXR0aGV3 QGl0cy51cS5lZHUuYXUwDQYJKoZIhvcNAQEEBQADggEBAF2gZrkqZsZlHd4K/+yBN6qrpD61 hctDf7/Eg4jk6DMknEs6nvHMFUMZ4SXvkqPLnHBygTARKAs7qBSLd7mUUBOOQEgk6ovQVY6S 1CDSt3P9O6wjG0K1igtk8v6u7lkQ8p2STXqrOePVINdaucUgBO/IpeUtt9ATl1qvPTWyM/fz oUZsIKeYjNQVEQsuimrZjdbIAFxdl1fggSngUv64wBn8wCssGrPZIZA2lpBBEW1wejoWrDOH IIr+SspGd0i8MovDTMRSvgTERLki17FU/ANilcrSXiODKeIvpXhnQqVScnsoMSZmBmN2QIoG SnBjNK5mYxx5E3v20VOwtP1hVdEwggNyMIICWqADAgECAgEqMA0GCSqGSIb3DQEBBAUAMIGj MQswCQYDVQQGEwJBVTETMBEGA1UECBMKUXVlZW5zbGFuZDERMA8GA1UEBxMIQnJpc2JhbmUx JTAjBgNVBAoTHFRoZSBVbml2ZXJzaXR5IG9mIFF1ZWVuc2xhbmQxKDAmBgNVBAsTH0luZm9y bWF0aW9uIFRlY2hub2xvZ3kgU2VydmljZXMxGzAZBgNVBAMTEkNlcnRpZmljYXRlIFNlcnZl cjAeFw0wNDAxMjEyMzM2MjFaFw0wNjAxMjEyMzM2MjFaMIGyMQswCQYDVQQGEwJBVTElMCMG A1UEChMcVGhlIFVuaXZlcnNpdHkgb2YgUXVlZW5zbGFuZDEnMCUGA1UECxMeSW5mb3JtYXRp b24gVGVjbm9sb2d5IFNlcnZpY2VzMRYwFAYKCZImiZPyLGQBARMGY2NtYXR0MRkwFwYDVQQD ExBNYXR0aGV3IFN1bGxpdmFuMSAwHgYJKoZIhvcNAQkBFhFtYXR0aGV3QHVxLmVkdS5hdTBc MA0GCSqGSIb3DQEBAQUAA0sAMEgCQQCbFH68P0FKiiMw73q1nNheBhRUWZiHjvmwJfuwTOsf /X6zMzrcoMeEBm+KEMLThPEnWtWiLL/siRdw4vRLlMrzAgMBAAGjaDBmMA4GA1UdDwEB/wQE AwIF4DARBglghkgBhvhCAQEEBAMCBaAwHwYDVR0jBBgwFoAUJqraMrnolk2GQYp77J83jli7 VLswIAYDVR0RBBkwF4EVbWF0dGhld0BpdHMudXEuZWR1LmF1MA0GCSqGSIb3DQEBBAUAA4IB AQBdoGa5KmbGZR3eCv/sgTeqq6Q+tYXLQ3+/xIOI5OgzJJxLOp7xzBVDGeEl75Kjy5xwcoEw ESgLO6gUi3e5lFATjkBIJOqL0FWOktQg0rdz/TusIxtCtYoLZPL+ru5ZEPKdkk16qznj1SDX WrnFIATvyKXlLbfQE5darz01sjP386FGbCCnmIzUFRELLopq2Y3WyABcXZdX4IEp4FL+uMAZ /MArLBqz2SGQNpaQQRFtcHo6FqwzhyCK/krKRndIvDKLw0zEUr4ExES5ItexVPwDYpXK0l4j gyniL6V4Z0KlUnJ7KDEmZgZjdkCKBkpwYzSuZmMceRN79tFTsLT9YVXRMYIDQDCCAzwCAQEw gakwgaMxCzAJBgNVBAYTAkFVMRMwEQYDVQQIEwpRdWVlbnNsYW5kMREwDwYDVQQHEwhCcmlz YmFuZTElMCMGA1UEChMcVGhlIFVuaXZlcnNpdHkgb2YgUXVlZW5zbGFuZDEoMCYGA1UECxMf SW5mb3JtYXRpb24gVGVjaG5vbG9neSBTZXJ2aWNlczEbMBkGA1UEAxMSQ2VydGlmaWNhdGUg U2VydmVyAgEqMAkGBSsOAwIaBQCgggItMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ KoZIhvcNAQkFMQ8XDTA1MDQyNDEwMzk1MFowIwYJKoZIhvcNAQkEMRYEFNVbAuT0TW8ktw+t sKuQZqdJQqczMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIG6BgkrBgEEAYI3EAQx gawwgakwgaMxCzAJBgNVBAYTAkFVMRMwEQYDVQQIEwpRdWVlbnNsYW5kMREwDwYDVQQHEwhC cmlzYmFuZTElMCMGA1UEChMcVGhlIFVuaXZlcnNpdHkgb2YgUXVlZW5zbGFuZDEoMCYGA1UE CxMfSW5mb3JtYXRpb24gVGVjaG5vbG9neSBTZXJ2aWNlczEbMBkGA1UEAxMSQ2VydGlmaWNh dGUgU2VydmVyAgEqMIG8BgsqhkiG9w0BCRACCzGBrKCBqTCBozELMAkGA1UEBhMCQVUxEzAR BgNVBAgTClF1ZWVuc2xhbmQxETAPBgNVBAcTCEJyaXNiYW5lMSUwIwYDVQQKExxUaGUgVW5p dmVyc2l0eSBvZiBRdWVlbnNsYW5kMSgwJgYDVQQLEx9JbmZvcm1hdGlvbiBUZWNobm9sb2d5 IFNlcnZpY2VzMRswGQYDVQQDExJDZXJ0aWZpY2F0ZSBTZXJ2ZXICASowDQYJKoZIhvcNAQEB BQAEQBGdBl8I4Hq7ycz+CbFHm0htgdOUdnbq/iZDoEE/3D+ygPu5+8FK1Y33SO5A3mZCNQ+0 HepWeueQwW/iIA09u2gAAAAAAAA= --------------ms060909080208050706090302-- From owner-freebsd-current@FreeBSD.ORG Sun Apr 24 11:40: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 42B7716A4CE for ; Sun, 24 Apr 2005 11:40:45 +0000 (GMT) Received: from lexi.siliconlandmark.com (lexi.siliconlandmark.com [209.69.98.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id DD93443D1D for ; Sun, 24 Apr 2005 11:40:44 +0000 (GMT) (envelope-from andy@siliconlandmark.com) Received: from lexi.siliconlandmark.com (localhost [127.0.0.1]) j3OBedJK018865; Sun, 24 Apr 2005 07:40:39 -0400 (EDT) (envelope-from andy@siliconlandmark.com) Received: from localhost (andy@localhost)j3OBea3R018862; Sun, 24 Apr 2005 07:40:37 -0400 (EDT) (envelope-from andy@siliconlandmark.com) X-Authentication-Warning: lexi.siliconlandmark.com: andy owned process doing -bs Date: Sun, 24 Apr 2005 07:40:36 -0400 (EDT) From: Andre Guibert de Bruet To: Matthew Sullivan In-Reply-To: <426B7776.6060908@uq.edu.au> Message-ID: <20050424073914.F68772@lexi.siliconlandmark.com> References: <4267A1CF.3080903@uq.edu.au> <20050422190208.M68772@lexi.siliconlandmark.com> <426A20E5.5020604@uq.edu.au><426B06F5.3030506@uq.edu.au> <426B68B6.7000709@fer.hr> <426B7776.6060908@uq.edu.au> 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.543, required 6, autolearn=not spam, AWL 0.06, BAYES_00 -2.60) X-MailScanner-From: andy@siliconlandmark.com cc: current@freebsd.org Subject: Re: SMP on Compaq DL380 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 24 Apr 2005 11:40:45 -0000 On Sun, 24 Apr 2005, Matthew Sullivan wrote: > Ivan Voras wrote: > >> Matthew Sullivan wrote: >> >>>> they're not mismatched? The easy way of doing this if your BIOS doesn't >>>> post this information is using a Knoppix LiveCD and doing a cat >>>> /proc/cpuinfo. >>> >>> Ok can't do the knoppix thing atm, however... >> >> Would ports/misc/cpuid help? > > Probably not much help... The utility that I was looking for is sysutils/x86info. Does it detect everything correctly? | Andre Guibert de Bruet | Enterprise Software Consultant > | Silicon Landmark, LLC. | http://siliconlandmark.com/ > From owner-freebsd-current@FreeBSD.ORG Sat Apr 23 16:07: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 1412B16A4CE for ; Sat, 23 Apr 2005 16:07:18 +0000 (GMT) Received: from lazir.toya.net.pl (lazir.toya.net.pl [217.113.224.3]) by mx1.FreeBSD.org (Postfix) with ESMTP id AEB3843D41 for ; Sat, 23 Apr 2005 16:07:17 +0000 (GMT) (envelope-from imachine@lazir.toya.net.pl) Received: from localhost (unknown [192.168.120.26]) by lazir.toya.net.pl (TOYAnet MailServer) with ESMTP id 521DF8BCB7 for ; Sat, 23 Apr 2005 18:07:15 +0200 (CEST) Received: from lazir.toya.net.pl ([192.168.120.25]) by localhost (agregat [192.168.120.26]) (amavisd-new, port 10024) with ESMTP id 32364-09 for ; Sat, 23 Apr 2005 18:07:13 +0200 (CEST) Received: by lazir.toya.net.pl (TOYAnet MailServer, from userid 9907) id 4771C8BCAE; Sat, 23 Apr 2005 18:07:13 +0200 (CEST) Date: Sat, 23 Apr 2005 18:07:13 +0200 To: freebsd-current@freebsd.org Message-ID: <20050423160713.GA24432@lazir.toya.net.pl> References: <20050423005715.G16129@it.hackers> <1114212379.955.15.camel@leguin> <20050423184110.O37477@it.hackers> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050423184110.O37477@it.hackers> User-Agent: Mutt/1.5.6+20040907i From: imachine@lazir.toya.net.pl (None) X-TOYA-AV: AntyVir-Skaner at toya.net.pl X-Mailman-Approved-At: Sun, 24 Apr 2005 11:49:52 +0000 Subject: Re: mgadrm fail in -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, 23 Apr 2005 16:07:18 -0000 On Sat, Apr 23, 2005 at 06:43:00PM +0400, Nguyen Tam Chinh wrote: > On Fri, 22 Apr 2005, Eric Anholt wrote: > > >On Sat, 2005-04-23 at 01:01 +0400, Nguyen Tam Chinh wrote: > >>Hello All, > >>I've just compiled -CURRENT (cvsup some hours ago) and the magdrm seemed > >>to be fail. > >>Last week's -CURRENT build was okay. > > > >Do you have device drm in your kernel? > >Did you do a clean build? > > > > Aha, I checked the config/NOTES and noticed that the new line: device drm > Thank you :) > > >There's no real reason to be building the drm into the kernel that I can > >see, as it's automatically loaded for you by the X Server. i might be off here, and dont intend to cause any offtopicness, altho i was informed perhaphs wrongly, that kernel-builtin drivers are having some speed improvements compared to loaded modules? cheers ;] > > > >-- > >Eric Anholt eta@lclark.edu > >http://people.freebsd.org/~anholt/ anholt@FreeBSD.org > > > > ----- > With best regards, | The Power to Serve > Nguyen Tam Chinh | http://www.FreeBSD.org > Loc: sp.cs.msu.ru | > _______________________________________________ > 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 24 11:55: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 E835716A4CE for ; Sun, 24 Apr 2005 11:55:24 +0000 (GMT) Received: from mail.sorbs.net (news.sorbs.net [203.15.51.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id 53AC843D39 for ; Sun, 24 Apr 2005 11:55:24 +0000 (GMT) (envelope-from matthew@uq.edu.au) Received: from [10.200.254.98] by nemesis.sorbs.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0IFG00C0C95176@nemesis.sorbs.net> for current@freebsd.org; Sun, 24 Apr 2005 21:55:50 +1000 (EST) Date: Sun, 24 Apr 2005 21:54:15 +1000 From: Matthew Sullivan In-reply-to: <20050424073914.F68772@lexi.siliconlandmark.com> To: Andre Guibert de Bruet Message-id: <426B88E7.2080606@uq.edu.au> MIME-version: 1.0 Content-type: multipart/signed; boundary=------------ms050902080605060901020306; micalg=sha1; protocol="application/x-pkcs7-signature" X-Accept-Language: en User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041231 References: <4267A1CF.3080903@uq.edu.au> <20050422190208.M68772@lexi.siliconlandmark.com> <426A20E5.5020604@uq.edu.au> <426B06F5.3030506@uq.edu.au> <426B68B6.7000709@fer.hr> <426B7776.6060908@uq.edu.au> <20050424073914.F68772@lexi.siliconlandmark.com> cc: current@freebsd.org Subject: Re: SMP on Compaq DL380 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 24 Apr 2005 11:55:25 -0000 This is a cryptographically signed message in MIME format. --------------ms050902080605060901020306 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Andre Guibert de Bruet wrote: > > On Sun, 24 Apr 2005, Matthew Sullivan wrote: > >> Ivan Voras wrote: >> >>> Matthew Sullivan wrote: >>> >>>>> they're not mismatched? The easy way of doing this if your BIOS >>>>> doesn't post this information is using a Knoppix LiveCD and doing >>>>> a cat /proc/cpuinfo. >>>> >>>> >>>> Ok can't do the knoppix thing atm, however... >>> >>> >>> Would ports/misc/cpuid help? >> >> >> Probably not much help... > > > The utility that I was looking for is sysutils/x86info. Does it detect > everything correctly? No... x86info v1.12b. Dave Jones 2001-2003 Feedback to . Found 1 CPU, but found 2 CPUs in MPTable. MP Table: # APIC ID Version State Family Model Step Flags # 0 0x10 BSP, usable 6 2 1 0x0381 # 0 0x10 AP, usable 6 8 6 0x383fbff -------------------------------------------------------------------------- eax in: 0x00000000, eax = 00000002 ebx = 756e6547 ecx = 6c65746e edx = 49656e69 eax in: 0x00000001, eax = 00000683 ebx = 00000002 ecx = 00000000 edx = 0383f9ff eax in: 0x00000002, eax = 03020101 ebx = 00000000 ecx = 00000000 edx = 0c040882 Family: 6 Model: 8 Stepping: 3 Type: 0 Brand: 2 CPU Model: Pentium III-M (Coppermine) [cB0] Original OEM Feature flags: Onboard FPU Virtual Mode Extensions Debugging Extensions Page Size Extensions Time Stamp Counter Model-Specific Registers Physical Address Extensions Machine Check Architecture CMPXCHG8 instruction SYSENTER/SYSEXIT Memory Type Range Registers Page Global Enable Machine Check Architecture CMOV instruction Page Attribute Table 36-bit PSEs MMX support FXSAVE and FXRESTORE instructions SSE support Extended feature flags: Instruction TLB: 4KB pages, 4-way associative, 32 entries Instruction TLB: 4MB pages, fully associative, 2 entries Data TLB: 4KB pages, 4-way associative, 64 entries L2 unified cache: Size: 256KB 8-way associative. line size=32 bytes. L1 Instruction cache: Size: 16KB 4-way associative. line size=32 bytes. Data TLB: 4MB pages, 4-way associative, 8 entries L1 Data cache: Size: 16KB 4-way associative. line size=32 bytes. /dev/cpu/0/msr: No such file or directory MTRR registers: MTRRcap (0xfe): MTRRphysBase0 (0x200): MTRRphysMask0 (0x201): MTRRphysBase1 (0x202): MTRRphysMask1 (0x203): MTRRphysBase2 (0x204): MTRRphysMask2 (0x205): MTRRphysBase3 (0x206): MTRRphysMask3 (0x207): MTRRphysBase4 (0x208): MTRRphysMask4 (0x209): MTRRphysBase5 (0x20a): MTRRphysMask5 (0x20b): MTRRphysBase6 (0x20c): MTRRphysMask6 (0x20d): MTRRphysBase7 (0x20e): MTRRphysMask7 (0x20f): MTRRfix64K_00000 (0x250): MTRRfix16K_80000 (0x258): MTRRfix16K_A0000 (0x259): MTRRfix4K_C8000 (0x269): MTRRfix4K_D0000 0x26a: MTRRfix4K_D8000 0x26b: MTRRfix4K_E0000 0x26c: MTRRfix4K_E8000 0x26d: MTRRfix4K_F0000 0x26e: MTRRfix4K_F8000 0x26f: MTRRdefType (0x2ff): 850MHz processor (estimate). Regards, -- Matthew Sullivan Specialist Systems Programmer Information Technology Services The University of Queensland --------------ms050902080605060901020306 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIG7DCC A3IwggJaoAMCAQICASowDQYJKoZIhvcNAQEEBQAwgaMxCzAJBgNVBAYTAkFVMRMwEQYDVQQI EwpRdWVlbnNsYW5kMREwDwYDVQQHEwhCcmlzYmFuZTElMCMGA1UEChMcVGhlIFVuaXZlcnNp dHkgb2YgUXVlZW5zbGFuZDEoMCYGA1UECxMfSW5mb3JtYXRpb24gVGVjaG5vbG9neSBTZXJ2 aWNlczEbMBkGA1UEAxMSQ2VydGlmaWNhdGUgU2VydmVyMB4XDTA0MDEyMTIzMzYyMVoXDTA2 MDEyMTIzMzYyMVowgbIxCzAJBgNVBAYTAkFVMSUwIwYDVQQKExxUaGUgVW5pdmVyc2l0eSBv ZiBRdWVlbnNsYW5kMScwJQYDVQQLEx5JbmZvcm1hdGlvbiBUZWNub2xvZ3kgU2VydmljZXMx FjAUBgoJkiaJk/IsZAEBEwZjY21hdHQxGTAXBgNVBAMTEE1hdHRoZXcgU3VsbGl2YW4xIDAe BgkqhkiG9w0BCQEWEW1hdHRoZXdAdXEuZWR1LmF1MFwwDQYJKoZIhvcNAQEBBQADSwAwSAJB AJsUfrw/QUqKIzDverWc2F4GFFRZmIeO+bAl+7BM6x/9frMzOtygx4QGb4oQwtOE8Sda1aIs v+yJF3Di9EuUyvMCAwEAAaNoMGYwDgYDVR0PAQH/BAQDAgXgMBEGCWCGSAGG+EIBAQQEAwIF oDAfBgNVHSMEGDAWgBQmqtoyueiWTYZBinvsnzeOWLtUuzAgBgNVHREEGTAXgRVtYXR0aGV3 QGl0cy51cS5lZHUuYXUwDQYJKoZIhvcNAQEEBQADggEBAF2gZrkqZsZlHd4K/+yBN6qrpD61 hctDf7/Eg4jk6DMknEs6nvHMFUMZ4SXvkqPLnHBygTARKAs7qBSLd7mUUBOOQEgk6ovQVY6S 1CDSt3P9O6wjG0K1igtk8v6u7lkQ8p2STXqrOePVINdaucUgBO/IpeUtt9ATl1qvPTWyM/fz oUZsIKeYjNQVEQsuimrZjdbIAFxdl1fggSngUv64wBn8wCssGrPZIZA2lpBBEW1wejoWrDOH IIr+SspGd0i8MovDTMRSvgTERLki17FU/ANilcrSXiODKeIvpXhnQqVScnsoMSZmBmN2QIoG SnBjNK5mYxx5E3v20VOwtP1hVdEwggNyMIICWqADAgECAgEqMA0GCSqGSIb3DQEBBAUAMIGj MQswCQYDVQQGEwJBVTETMBEGA1UECBMKUXVlZW5zbGFuZDERMA8GA1UEBxMIQnJpc2JhbmUx JTAjBgNVBAoTHFRoZSBVbml2ZXJzaXR5IG9mIFF1ZWVuc2xhbmQxKDAmBgNVBAsTH0luZm9y bWF0aW9uIFRlY2hub2xvZ3kgU2VydmljZXMxGzAZBgNVBAMTEkNlcnRpZmljYXRlIFNlcnZl cjAeFw0wNDAxMjEyMzM2MjFaFw0wNjAxMjEyMzM2MjFaMIGyMQswCQYDVQQGEwJBVTElMCMG A1UEChMcVGhlIFVuaXZlcnNpdHkgb2YgUXVlZW5zbGFuZDEnMCUGA1UECxMeSW5mb3JtYXRp b24gVGVjbm9sb2d5IFNlcnZpY2VzMRYwFAYKCZImiZPyLGQBARMGY2NtYXR0MRkwFwYDVQQD ExBNYXR0aGV3IFN1bGxpdmFuMSAwHgYJKoZIhvcNAQkBFhFtYXR0aGV3QHVxLmVkdS5hdTBc MA0GCSqGSIb3DQEBAQUAA0sAMEgCQQCbFH68P0FKiiMw73q1nNheBhRUWZiHjvmwJfuwTOsf /X6zMzrcoMeEBm+KEMLThPEnWtWiLL/siRdw4vRLlMrzAgMBAAGjaDBmMA4GA1UdDwEB/wQE AwIF4DARBglghkgBhvhCAQEEBAMCBaAwHwYDVR0jBBgwFoAUJqraMrnolk2GQYp77J83jli7 VLswIAYDVR0RBBkwF4EVbWF0dGhld0BpdHMudXEuZWR1LmF1MA0GCSqGSIb3DQEBBAUAA4IB AQBdoGa5KmbGZR3eCv/sgTeqq6Q+tYXLQ3+/xIOI5OgzJJxLOp7xzBVDGeEl75Kjy5xwcoEw ESgLO6gUi3e5lFATjkBIJOqL0FWOktQg0rdz/TusIxtCtYoLZPL+ru5ZEPKdkk16qznj1SDX WrnFIATvyKXlLbfQE5darz01sjP386FGbCCnmIzUFRELLopq2Y3WyABcXZdX4IEp4FL+uMAZ /MArLBqz2SGQNpaQQRFtcHo6FqwzhyCK/krKRndIvDKLw0zEUr4ExES5ItexVPwDYpXK0l4j gyniL6V4Z0KlUnJ7KDEmZgZjdkCKBkpwYzSuZmMceRN79tFTsLT9YVXRMYIDQDCCAzwCAQEw gakwgaMxCzAJBgNVBAYTAkFVMRMwEQYDVQQIEwpRdWVlbnNsYW5kMREwDwYDVQQHEwhCcmlz YmFuZTElMCMGA1UEChMcVGhlIFVuaXZlcnNpdHkgb2YgUXVlZW5zbGFuZDEoMCYGA1UECxMf SW5mb3JtYXRpb24gVGVjaG5vbG9neSBTZXJ2aWNlczEbMBkGA1UEAxMSQ2VydGlmaWNhdGUg U2VydmVyAgEqMAkGBSsOAwIaBQCgggItMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ KoZIhvcNAQkFMQ8XDTA1MDQyNDExNTQxNVowIwYJKoZIhvcNAQkEMRYEFJby7QOjir48MMP5 pT2a08HD9QsMMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIG6BgkrBgEEAYI3EAQx gawwgakwgaMxCzAJBgNVBAYTAkFVMRMwEQYDVQQIEwpRdWVlbnNsYW5kMREwDwYDVQQHEwhC cmlzYmFuZTElMCMGA1UEChMcVGhlIFVuaXZlcnNpdHkgb2YgUXVlZW5zbGFuZDEoMCYGA1UE CxMfSW5mb3JtYXRpb24gVGVjaG5vbG9neSBTZXJ2aWNlczEbMBkGA1UEAxMSQ2VydGlmaWNh dGUgU2VydmVyAgEqMIG8BgsqhkiG9w0BCRACCzGBrKCBqTCBozELMAkGA1UEBhMCQVUxEzAR BgNVBAgTClF1ZWVuc2xhbmQxETAPBgNVBAcTCEJyaXNiYW5lMSUwIwYDVQQKExxUaGUgVW5p dmVyc2l0eSBvZiBRdWVlbnNsYW5kMSgwJgYDVQQLEx9JbmZvcm1hdGlvbiBUZWNobm9sb2d5 IFNlcnZpY2VzMRswGQYDVQQDExJDZXJ0aWZpY2F0ZSBTZXJ2ZXICASowDQYJKoZIhvcNAQEB BQAEQCpn8ELRe+tigWzxRDW5yS8pb3FI8omixtLNVK9FzjfsgHv4wcLiwjajnqP/tZf8KZqh XwBltMfA7DIRIaaCCAYAAAAAAAA= --------------ms050902080605060901020306-- From owner-freebsd-current@FreeBSD.ORG Sun Apr 24 13:49: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 C034D16A4CE for ; Sun, 24 Apr 2005 13:49:24 +0000 (GMT) Received: from mail.qconline.com (mail.qconline.com [204.176.110.250]) by mx1.FreeBSD.org (Postfix) with ESMTP id 23B5243D3F for ; Sun, 24 Apr 2005 13:49:24 +0000 (GMT) (envelope-from harrycoin@qconline.com) Received: from devoffice.qconline.com (unverified [64.4.171.82]) by mail.qconline.com for ; Sun, 24 Apr 2005 08:49:47 -0500 Message-Id: <4.3.2.7.2.20050424084131.042e7570@mail.qconline.com> X-Sender: harrycoin@mail.qconline.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 24 Apr 2005 08:49:16 -0500 To: freebsd-current@freebsd.org From: Harry Coin In-Reply-To: <20050424120044.AD0BC16A4CE@hub.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: 5.4 RC3 fails to detect psm0. Normal except no PS/2 mouse. atapicam doesn't hang. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 24 Apr 2005 13:49:24 -0000 5.4 RC3 as of yesterday fails to detect ps/2 mouse ( /dev/psm0) on 2 different ASUS P4C800E boxes. Dmesg follows. 5.4 as of a few days ago worked. Normal functions otherwise so far as I can tell, it just doesn't load the psm0 driver. moused complains. So no X usability. P.S. I wrote before about how these machines hung (interrupt storm) on boot with atapicam in the kernel on 5.4 but not 5.3. atapicam does not cause boot problems any longer. I don't know if it actually permits function, it failed to read sectors past 16K using 2048 byte block sizes in K3B. Harry Coin dmesg follows 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-RC3 #5: Sat Apr 23 17:36:57 CDT 2005 root@server1.quietfountain.com:/usr/obj/usr/src/sys/SERVER1 ACPI APIC Table: Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Pentium(R) 4 CPU 2.80GHz (2806.37-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf29 Stepping = 9 Features=0xbfebfbff Hyperthreading: 2 logical CPUs real memory = 2146631680 (2047 MB) avail memory = 2090975232 (1994 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: 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 0x808-0x80b on acpi0 cpu0: on acpi0 cpu1: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 agp0: mem 0xf8000000-0xfbffffff at device 0.0 on pci0 pcib1: at device 1.0 on pci0 pci1: on pcib1 nvidia0: mem 0xe8000000-0xefffffff,0xfd000000-0xfdffffff irq 16 at device 0.0 on pci1 pcib2: at device 3.0 on pci0 pci2: on pcib2 em0: port 0xcf80-0xcf9f mem 0xfe9e0000-0xfe9fffff irq 18 at device 1.0 on pci2 em0: Ethernet address: 00:0c:6e:79:7a:bb em0: Speed:N/A Duplex:N/A uhci0: port 0xeec0-0xeedf irq 16 at device 29.0 on pci0 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 0xef00-0xef1f irq 19 at device 29.1 on pci0 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 0xef20-0xef3f irq 18 at device 29.2 on pci0 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 0xef40-0xef5f irq 16 at device 29.3 on pci0 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 pci0: at device 29.7 (no driver attached) pcib3: at device 30.0 on pci0 pci3: on pcib3 pci3: at device 3.0 (no driver attached) isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0xef90-0xef9f,0xefa8-0xefab,0xefa0-0xefa7,0xefac-0xefaf,0xefe0-0xefe7 irq 18 at device 31.1 on pci0 ata2: channel #0 on atapci0 ata3: channel #1 on atapci0 pci0: at device 31.3 (no driver attached) pcm0: port 0xee80-0xeebf,0xe800-0xe8ff mem 0xfebff000-0xfebff0ff,0xfebff400-0xfebff5ff irq 17 at device 31.5 on pci0 pcm0: acpi_button0: on acpi0 atkbdc0: port 0x64,0x60 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A fdc0: port 0x3f7,0x3f0-0x3f5 irq 6 drq 2 on acpi0 fd0: <1440-KB 3.5" drive> on fdc0 drive 0 ppc0: port 0x778-0x77b,0x378-0x37f irq 7 drq 3 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/9 bytes threshold ppbus0: on ppc0 plip0: on ppbus0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 orm0: at iomem 0xc0000-0xce7ff on isa0 pmtimer0 on isa0 ata0 at port 0x3f6,0x1f0-0x1f7 irq 14 on isa0 ata1 at port 0x376,0x170-0x177 irq 15 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Timecounters tick every 10.000 msec em0: Link is up 1000 Mbps Full Duplex ad4: 238475MB [484521/16/63] at ata2-master UDMA100 ad5: 238475MB [484521/16/63] at ata2-slave UDMA100 SMP: AP CPU #1 Launched! Mounting root from ufs:/dev/ad4s1a em0: Link is up 1000 Mbps Full Duplex From owner-freebsd-current@FreeBSD.ORG Sun Apr 24 15:02: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 0BC0816A4CE; Sun, 24 Apr 2005 15:02:15 +0000 (GMT) Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by mx1.FreeBSD.org (Postfix) with SMTP id 0978843D31; Sun, 24 Apr 2005 15:02:14 +0000 (GMT) (envelope-from dwmalone@maths.tcd.ie) Received: from walton.maths.tcd.ie ([134.226.81.10] helo=walton.maths.tcd.ie) by salmon.maths.tcd.ie with SMTP id ; 24 Apr 2005 16:02:13 +0100 (BST) Date: Sun, 24 Apr 2005 16:02:11 +0100 From: David Malone To: Matthew Sullivan Message-ID: <20050424150211.GA87520@walton.maths.tcd.ie> References: <426426AE.2060406@uq.edu.au> <20050420084413.GA27304@walton.maths.tcd.ie> <42663EA1.3020409@uq.edu.au> <426A3F49.6090203@uq.edu.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <426A3F49.6090203@uq.edu.au> User-Agent: Mutt/1.5.6i Sender: dwmalone@maths.tcd.ie cc: freebsd-current@freebsd.org cc: andre@freebsd.org Subject: Re: DF (Don't frag) issues X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 24 Apr 2005 15:02:15 -0000 On Sat, Apr 23, 2005 at 10:27:53PM +1000, Matthew Sullivan wrote: > Ok well thanks to Andrew @ Supernews and a lot of debugging it appears > there is a bug.... > > sys/netinet/ip_icmp.c: line 440 > if (!mtu) > mtu = ip_next_mtu(mtu, 1); > Problem is ip_next_mtu will always return 0 when called with (0, 1) ... I think this might be a bug, but Andre would know better. Andre - it looks to me as if the first argument to ip_next_mtu here should be the current MTU for the path, but it is being set to the mtu from the ICMP message, which (in this case) is zero. (This is in the code that has just been moved to tcp_ctlinput.) > Apparently the gateway should be suggesting a MTU value for use.... the > gateway is also FreeBSD 5.3 so something needs fixing .. :-/ Are you using ip fast forwarding on the gateway? It calculates the size that is put into the ICMP message in a slightly different way to the other forwrd path. David. From owner-freebsd-current@FreeBSD.ORG Sun Apr 24 15:58: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 499E916A4CE for ; Sun, 24 Apr 2005 15:58:36 +0000 (GMT) Received: from gromit.dlib.vt.edu (gromit.dlib.vt.edu [128.173.49.29]) by mx1.FreeBSD.org (Postfix) with ESMTP id D5BF843D48 for ; Sun, 24 Apr 2005 15:58:35 +0000 (GMT) (envelope-from paul@gromit.dlib.vt.edu) Received: from zappa.Chelsea-Ct.Org (pool-70-110-10-69.roa.east.verizon.net [70.110.10.69]) by gromit.dlib.vt.edu (8.13.3/8.13.3) with ESMTP id j3OFwPR0032911 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 24 Apr 2005 11:58:27 -0400 (EDT) (envelope-from paul@gromit.dlib.vt.edu) Received: from zappa.Chelsea-Ct.Org (localhost.Chelsea-Ct.Org [127.0.0.1]) by zappa.Chelsea-Ct.Org (8.13.3/8.13.3) with ESMTP id j3OFwKSb077512 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 24 Apr 2005 11:58:20 -0400 (EDT) (envelope-from paul@gromit.dlib.vt.edu) Received: (from paul@localhost) by zappa.Chelsea-Ct.Org (8.13.3/8.13.3/Submit) id j3OFwKZL077511; Sun, 24 Apr 2005 11:58:20 -0400 (EDT) (envelope-from paul@gromit.dlib.vt.edu) X-Authentication-Warning: zappa.Chelsea-Ct.Org: paul set sender to paul@gromit.dlib.vt.edu using -f From: Paul Mather To: =?ISO-8859-1?Q?S=F8ren?= Schmidt In-Reply-To: <426B61FF.80001@DeepCore.dk> References: <1114305707.71309.40.camel@zappa.Chelsea-Ct.Org> <426B61FF.80001@DeepCore.dk> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Date: Sun, 24 Apr 2005 11:58:19 -0400 Message-Id: <1114358299.77313.2.camel@zappa.Chelsea-Ct.Org> Mime-Version: 1.0 X-Mailer: Evolution 2.2.2 FreeBSD GNOME Team Port cc: freebsd-current@freebsd.org Subject: Re: Fatal TIMEOUT - WRITE_DMA errors return with ATA Mk.III X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 24 Apr 2005 15:58:36 -0000 On Sun, 2005-04-24 at 11:08 +0200, S=F8ren Schmidt wrote: > Paul Mather wrote: > > Since somewhere in the 5.x release cycle, my system has fallen prey to > > the "TIMEOUT - WRITE_DMA" errors which result in the drive becoming > > detached (which causes my geom_mirror to break and require rebuilding). > > According to smartctl and disk diagnostics, there's nothing wrong with > > my drives. Plus, the problem does not manifest itself under 4-STABLE. > > (I'm not the only one to have reported this problem.) > >=20 > > Lately, I'd had success using a patch posted to freebsd-current by Ian > > Dowse. The "TIMEOUT - WRITE_DMA" errors still occurred, but they > > weren't fatal. I updated my kernel and world recently, and, alas, the > > "TIMEOUT - WRITE_DMA" problem has returned once more: >=20 > You should try a recent -current, I committed cleanups to the timeout=20 > system on the 21'st. You might still have timeouts (which might due to=20 > non-ATA issues) but they should not be fatal unless the HW really does=20 > screw up.. Many thanks! I'll try an upgrade and see if that fixes things. Cheers, Paul. --=20 e-mail: paul@gromit.dlib.vt.edu "Without music to decorate it, time is just a bunch of boring production deadlines or dates by which bills must be paid." --- Frank Vincent Zappa From owner-freebsd-current@FreeBSD.ORG Sun Apr 24 16:21: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 89F4B16A4CE for ; Sun, 24 Apr 2005 16:21:31 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id B26C843D1D for ; Sun, 24 Apr 2005 16:21:30 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 1893 invoked from network); 24 Apr 2005 16:22:47 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.54]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 24 Apr 2005 16:22:47 -0000 Message-ID: <426BC78A.3E56D99B@freebsd.org> Date: Sun, 24 Apr 2005 18:21:30 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: David Malone References: <426426AE.2060406@uq.edu.au> <20050420084413.GA27304@walton.maths.tcd.ie> <42663EA1.3020409@uq.edu.au> <426A3F49.6090203@uq.edu.au> <20050424150211.GA87520@walton.maths.tcd.ie> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: Matthew Sullivan cc: freebsd-current@freebsd.org Subject: Re: DF (Don't frag) issues X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 24 Apr 2005 16:21:31 -0000 David Malone wrote: > > On Sat, Apr 23, 2005 at 10:27:53PM +1000, Matthew Sullivan wrote: > > Ok well thanks to Andrew @ Supernews and a lot of debugging it appears > > there is a bug.... > > > > sys/netinet/ip_icmp.c: line 440 > > if (!mtu) > > mtu = ip_next_mtu(mtu, 1); > > Problem is ip_next_mtu will always return 0 when called with (0, 1) ... > > I think this might be a bug, but Andre would know better. Andre - > it looks to me as if the first argument to ip_next_mtu here should > be the current MTU for the path, but it is being set to the mtu > from the ICMP message, which (in this case) is zero. This is a bug indeed. Let me think how to fix this most efficiently... > (This is in the code that has just been moved to tcp_ctlinput.) > > > Apparently the gateway should be suggesting a MTU value for use.... the > > gateway is also FreeBSD 5.3 so something needs fixing .. :-/ > > Are you using ip fast forwarding on the gateway? It calculates the > size that is put into the ICMP message in a slightly different way > to the other forwrd path. The quoted code above is used only for incoming ICMP packets. It does not generate them? What is the problem being observed exactly? -- Andre From owner-freebsd-current@FreeBSD.ORG Sun Apr 24 17:23: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 CAAA216A4CE for ; Sun, 24 Apr 2005 17:23:26 +0000 (GMT) Received: from mail.qconline.com (mail.qconline.com [204.176.110.250]) by mx1.FreeBSD.org (Postfix) with ESMTP id 901B843D31 for ; Sun, 24 Apr 2005 17:23:25 +0000 (GMT) (envelope-from harrycoin@qconline.com) Received: from devoffice.qconline.com (unverified [64.4.171.82]) by mail.qconline.com for ; Sun, 24 Apr 2005 12:23:48 -0500 Message-Id: <4.3.2.7.2.20050424085214.0434da60@www.n4comm.com> X-Sender: harrycoin@mail.qconline.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 24 Apr 2005 12:23:06 -0500 To: freebsd-current@freebsd.org From: Harry Coin Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: 5.4 RC3 fails to detect psm0. Normal except no PS/2 mouse. atapicam doesn't hang. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 24 Apr 2005 17:23:26 -0000 Here's the kernel config file that couldn't find the ps/2 mouse # # GENERIC -- Generic kernel configuration file for FreeBSD/i386 # # For more information on this file, please read the handbook section on # Kernel Configuration Files: # # http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig-config.html # # The handbook is also available locally in /usr/share/doc/handbook # if you've installed the doc distribution, otherwise always see the # FreeBSD World Wide Web server (http://www.FreeBSD.org/) for the # latest information. # # An exhaustive list of options and more detailed explanations of the # device lines is also present in the ../../conf/NOTES and NOTES files. # If you are in doubt as to the purpose or necessity of a line, check first # in NOTES. # # $FreeBSD: src/sys/i386/conf/GENERIC,v 1.413.2.6.2.2 2004/10/24 18:02:52 scottl Exp $ machine i386 #cpu I486_CPU #cpu I586_CPU cpu I686_CPU ident SERVER1 options SMP # Symmetric MultiProcessor Kernel # To statically compile in device wiring instead of /boot/device.hints #hints "GENERIC.hints" # Default places to look for devices. options SCHED_4BSD # 4BSD scheduler options INET # InterNETworking #options INET6 # IPv6 communications protocols options FFS # Berkeley Fast Filesystem options SOFTUPDATES # Enable FFS soft updates support options UFS_ACL # Support for access control lists options UFS_DIRHASH # Improve performance on big directories options MD_ROOT # MD is a potential root device options NFSCLIENT # Network Filesystem Client options NFSSERVER # Network Filesystem Server options NFS_ROOT # NFS usable as /, requires NFSCLIENT options MSDOSFS # MSDOS Filesystem options CD9660 # ISO 9660 Filesystem options PROCFS # Process filesystem (requires PSEUDOFS) options PSEUDOFS # Pseudo-filesystem framework options GEOM_GPT # GUID Partition Tables. options COMPAT_43 # Compatible with BSD 4.3 [KEEP THIS!] options COMPAT_FREEBSD4 # Compatible with FreeBSD4 options SCSI_DELAY=15000 # Delay (in ms) before probing SCSI options KTRACE # ktrace(1) support options SYSVSHM # SYSV-style shared memory options SYSVMSG # SYSV-style message queues options SYSVSEM # SYSV-style semaphores options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions options KBD_INSTALL_CDEV # install a CDEV entry in /dev options AHC_REG_PRETTY_PRINT # Print register bitfields in debug # output. Adds ~128k to driver. options AHD_REG_PRETTY_PRINT # Print register bitfields in debug # output. Adds ~215k to driver. options ADAPTIVE_GIANT # Giant mutex is adaptive. device apic # I/O APIC # Bus support. Do not remove isa, even if you have no isa slots device isa device eisa device pci # Floppy drives device fdc # ATA and ATAPI devices device ata device atadisk # ATA disk drives device ataraid # ATA RAID drives device atapicd # ATAPI CDROM drives device atapifd # ATAPI floppy drives device atapist # ATAPI tape drives options ATA_STATIC_ID # Static device numbering # SCSI Controllers device ahb # EISA AHA1742 family device ahc # AHA2940 and onboard AIC7xxx devices device ahd # AHA39320/29320 and onboard AIC79xx devices device amd # AMD 53C974 (Tekram DC-390(T)) device isp # Qlogic family device mpt # LSI-Logic MPT-Fusion #device ncr # NCR/Symbios Logic device sym # NCR/Symbios Logic (newer chipsets + those of `ncr') device trm # Tekram DC395U/UW/F DC315U adapters device adv # Advansys SCSI adapters device adw # Advansys wide SCSI adapters device aha # Adaptec 154x SCSI adapters device aic # Adaptec 15[012]x SCSI adapters, AIC-6[23]60. device bt # Buslogic/Mylex MultiMaster SCSI adapters device ncv # NCR 53C500 device nsp # Workbit Ninja SCSI-3 device stg # TMC 18C30/18C50 # SCSI peripherals device scbus # SCSI bus (required for SCSI) device ch # SCSI media changers device da # Direct Access (disks) device sa # Sequential Access (tape etc) device cd # CD device pass # Passthrough device (direct SCSI access) device ses # SCSI Environmental Services (and SAF-TE) # RAID controllers interfaced to the SCSI subsystem device amr # AMI MegaRAID device asr # DPT SmartRAID V, VI and Adaptec SCSI RAID device ciss # Compaq Smart RAID 5* device dpt # DPT Smartcache III, IV - See NOTES for options device hptmv # Highpoint RocketRAID 182x device iir # Intel Integrated RAID device ips # IBM (Adaptec) ServeRAID device mly # Mylex AcceleRAID/eXtremeRAID device twa # 3ware 9000 series PATA/SATA RAID # RAID controllers device aac # Adaptec FSA RAID device aacp # SCSI passthrough for aac (requires CAM) device ida # Compaq Smart RAID device mlx # Mylex DAC960 family device pst # Promise Supertrak SX6000 device twe # 3ware ATA RAID # atkbdc0 controls both the keyboard and the PS/2 mouse device atkbdc # AT keyboard controller device atkbd # AT keyboard device psm # PS/2 mouse device vga # VGA video card driver device splash # Splash screen and screen saver support # syscons is the default console driver, resembling an SCO console device sc # Enable this for the pcvt (VT220 compatible) console driver #device vt #options XSERVER # support for X server on a vt console #options FAT_CURSOR # start with block cursor device agp # support several AGP chipsets # Floating point support - do not disable. device npx # Power management support (see NOTES for more options) #device apm # Add suspend/resume support for the i8254. device pmtimer # PCCARD (PCMCIA) support # PCMCIA and cardbus bridge support device cbb # cardbus (yenta) bridge device pccard # PC Card (16-bit) bus device cardbus # CardBus (32-bit) bus # Serial (COM) ports device sio # 8250, 16[45]50 based serial ports # Parallel port device ppc device ppbus # Parallel port bus (required) device lpt # Printer device plip # TCP/IP over parallel device ppi # Parallel port interface device #device vpo # Requires scbus and da # If you've got a "dumb" serial or parallel PCI card that is # supported by the puc(4) glue driver, uncomment the following # line to enable it (connects to the sio and/or ppc drivers): #device puc # PCI Ethernet NICs. device de # DEC/Intel DC21x4x (``Tulip'') device em # Intel PRO/1000 adapter Gigabit Ethernet Card device ixgb # Intel PRO/10GbE Ethernet Card device txp # 3Com 3cR990 (``Typhoon'') device vx # 3Com 3c590, 3c595 (``Vortex'') # PCI Ethernet NICs that use the common MII bus controller code. # NOTE: Be sure to keep the 'device miibus' line in order to use these NICs! device miibus # MII bus support device bfe # Broadcom BCM440x 10/100 Ethernet device bge # Broadcom BCM570xx Gigabit Ethernet device dc # DEC/Intel 21143 and various workalikes device fxp # Intel EtherExpress PRO/100B (82557, 82558) device lge # Level 1 LXT1001 gigabit ethernet device nge # NatSemi DP83820 gigabit ethernet device pcn # AMD Am79C97x PCI 10/100 (precedence over 'lnc') device re # RealTek 8139C+/8169/8169S/8110S device rl # RealTek 8129/8139 device sf # Adaptec AIC-6915 (``Starfire'') device sis # Silicon Integrated Systems SiS 900/SiS 7016 device sk # SysKonnect SK-984x & SK-982x gigabit Ethernet device ste # Sundance ST201 (D-Link DFE-550TX) device ti # Alteon Networks Tigon I/II gigabit Ethernet device tl # Texas Instruments ThunderLAN device tx # SMC EtherPower II (83c170 ``EPIC'') device vge # VIA VT612x gigabit ethernet device vr # VIA Rhine, Rhine II device wb # Winbond W89C840F device xl # 3Com 3c90x (``Boomerang'', ``Cyclone'') # ISA Ethernet NICs. pccard NICs included. device cs # Crystal Semiconductor CS89x0 NIC # 'device ed' requires 'device miibus' device ed # NE[12]000, SMC Ultra, 3c503, DS8390 cards device ex # Intel EtherExpress Pro/10 and Pro/10+ device ep # Etherlink III based cards device fe # Fujitsu MB8696x based cards device ie # EtherExpress 8/16, 3C507, StarLAN 10 etc. device lnc # NE2100, NE32-VL Lance Ethernet cards device sn # SMC's 9000 series of Ethernet chips device xe # Xircom pccard Ethernet # ISA devices that use the old ISA shims #device le # Wireless NIC cards device wlan # 802.11 support device an # Aironet 4500/4800 802.11 wireless NICs. device awi # BayStack 660 and others device wi # WaveLAN/Intersil/Symbol 802.11 wireless NICs. #device wl # Older non 802.11 Wavelan wireless NIC. # Pseudo devices. device loop # Network loopback device mem # Memory and kernel memory devices device io # I/O device device random # Entropy device device ether # Ethernet support device sl # Kernel SLIP device ppp # Kernel PPP device tun # Packet tunnel. device pty # Pseudo-ttys (telnet etc) device md # Memory "disks" #device gif # IPv6 and IPv4 tunneling #device faith # IPv6-to-IPv4 relaying (translation) # The `bpf' device enables the Berkeley Packet Filter. # Be aware of the administrative consequences of enabling this! device bpf # Berkeley packet filter # USB support device uhci # UHCI PCI->USB interface device ohci # OHCI PCI->USB interface device usb # USB Bus (required) #device udbp # USB Double Bulk Pipe devices device ugen # Generic device uhid # "Human Interface Devices" device ukbd # Keyboard device ulpt # Printer device umass # Disks/Mass storage - Requires scbus and da device ums # Mouse device urio # Diamond Rio 500 MP3 player device uscanner # Scanners # USB Ethernet, requires mii #device aue # ADMtek USB Ethernet #device axe # ASIX Electronics USB Ethernet #device cue # CATC USB Ethernet #device kue # Kawasaki LSI USB Ethernet #device rue # RealTek RTL8150 USB Ethernet # FireWire support #device firewire # FireWire bus code #device sbp # SCSI over FireWire (Requires scbus and da) #device fwe # Ethernet over FireWire (non-standard!) #Sound Support device sound device "snd_ad1816" device snd_ich From owner-freebsd-current@FreeBSD.ORG Sun Apr 24 17:55: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 CF4DA16A4CE for ; Sun, 24 Apr 2005 17:55:44 +0000 (GMT) Received: from web51805.mail.yahoo.com (web51805.mail.yahoo.com [206.190.38.236]) by mx1.FreeBSD.org (Postfix) with SMTP id 43FB343D48 for ; Sun, 24 Apr 2005 17:55:44 +0000 (GMT) (envelope-from patrick_dkt@yahoo.com.hk) Received: (qmail 71043 invoked by uid 60001); 24 Apr 2005 17:55:43 -0000 Message-ID: <20050424175543.71041.qmail@web51805.mail.yahoo.com> Received: from [222.166.160.87] by web51805.mail.yahoo.com via HTTP; Mon, 25 Apr 2005 01:55:43 CST Date: Mon, 25 Apr 2005 01:55:43 +0800 (CST) From: Patrick Dung To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=big5 Content-Transfer-Encoding: 8bit Subject: FreeBSD 6 is coming too fast X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 24 Apr 2005 17:55:44 -0000 Hi I have read the recent status report. IMHO, FreeBSD 5-stable is still not as stable as 4.x series. FreeBSD-5 will have a short livetime when FreeBSD-6 comes. May someone who work in large companies tell us their experience that FreeBSD 4 or 5 is installed for servers now, please? Regards Patrick _________________________________________________________ ¥²±þ§Þ¡B¶Œºq¡B€p¬P¬P... ®öº©¹aÁn ±¡€ß³sÃŽ http://us.rd.yahoo.com/evt=22281/*http://ringtone.yahoo.com.hk/ From owner-freebsd-current@FreeBSD.ORG Sun Apr 24 18:19: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 BBEFD16A4CE for ; Sun, 24 Apr 2005 18:19:58 +0000 (GMT) Received: from leguin.anholt.net (69-30-77-85.dq1sn.easystreet.com [69.30.77.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5BC7843D53 for ; Sun, 24 Apr 2005 18:19:58 +0000 (GMT) (envelope-from eta@lclark.edu) Received: from leguin.anholt.net (localhost [127.0.0.1]) by leguin.anholt.net (8.13.3/8.13.1) with ESMTP id j3OIJVKl039223; Sun, 24 Apr 2005 11:19:31 -0700 (PDT) (envelope-from eta@lclark.edu) Received: (from anholt@localhost) by leguin.anholt.net (8.13.3/8.13.1/Submit) id j3OIJUJr039222; Sun, 24 Apr 2005 11:19:30 -0700 (PDT) (envelope-from eta@lclark.edu) X-Authentication-Warning: leguin.anholt.net: anholt set sender to eta@lclark.edu using -f From: Eric Anholt To: None In-Reply-To: <20050423160713.GA24432@lazir.toya.net.pl> References: <20050423005715.G16129@it.hackers> <1114212379.955.15.camel@leguin> <20050423184110.O37477@it.hackers> <20050423160713.GA24432@lazir.toya.net.pl> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Sun, 24 Apr 2005 11:19:29 -0700 Message-Id: <1114366769.965.0.camel@leguin> Mime-Version: 1.0 X-Mailer: Evolution 2.2.0 FreeBSD GNOME Team Port cc: freebsd-current@freebsd.org Subject: Re: mgadrm fail in -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, 24 Apr 2005 18:19:58 -0000 On Sat, 2005-04-23 at 18:07 +0200, None wrote: > On Sat, Apr 23, 2005 at 06:43:00PM +0400, Nguyen Tam Chinh wrote: > > On Fri, 22 Apr 2005, Eric Anholt wrote: > > > > >On Sat, 2005-04-23 at 01:01 +0400, Nguyen Tam Chinh wrote: > > >>Hello All, > > >>I've just compiled -CURRENT (cvsup some hours ago) and the magdrm seemed > > >>to be fail. > > >>Last week's -CURRENT build was okay. > > > > > >Do you have device drm in your kernel? > > >Did you do a clean build? > > > > > > > Aha, I checked the config/NOTES and noticed that the new line: device drm > > Thank you :) > > > > >There's no real reason to be building the drm into the kernel that I can > > >see, as it's automatically loaded for you by the X Server. > > i might be off here, and dont intend to cause any offtopicness, altho i > was informed perhaphs wrongly, that kernel-builtin drivers are having > some speed improvements compared to loaded modules? I've never seen any measurements showing that that's the case, and would highly doubt there being any measurable effect. -- Eric Anholt eta@lclark.edu http://people.freebsd.org/~anholt/ anholt@FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Sun Apr 24 19:09: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 CB19F16A4CE; Sun, 24 Apr 2005 19:09:17 +0000 (GMT) Received: from mx.toxahost.ru (ns.toxahost.ru [62.89.204.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id 685C543D54; Sun, 24 Apr 2005 19:09:17 +0000 (GMT) (envelope-from toxa@toxahost.ru) Received: from localhost (laptoxa.toxa.lan [192.168.1.3]) by mx.toxahost.ru (Toxa) with ESMTP id 1FA9B122; Sun, 24 Apr 2005 23:09:16 +0400 (MSD) Date: Sun, 24 Apr 2005 23:09:12 +0400 From: Toxa To: freebsd-current@freebsd.org, freebsd-geom@freebsd.org X-Comment-To: "Anton A. Karpov" Message-ID: <20050424190912.GA6743@laptoxa.toxa.lan> Mail-Followup-To: freebsd-current@freebsd.org, freebsd-geom@freebsd.org, Pawel Jakub Dawidek References: <20050424022434.GA3384@laptoxa.toxa.lan> <20050424094343.GA837@darkness.comp.waw.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20050424094343.GA837@darkness.comp.waw.pl> User-Agent: Outluck Express 1.5.6i for MS-DOS 6.22-SMP X-Mailer: See User-Agent above :) X-Operating-System: MS-DOS 6.22-CURRENT on Sony VAIO laptop X-PGP-Public-Key: http://toxahost.ru/gpg/pubkey.asc X-Useless-Header: Do Androids Dream of Electric Sheep? cc: Pawel Jakub Dawidek Subject: Re: gmirror: Not all disks connected X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 24 Apr 2005 19:09:17 -0000 On Sun, Apr 24, 2005 at 11:43:43AM +0200, Pawel Jakub Dawidek wrote: > Please read description of 'forget' subcommand. Well, FYI, the problem *I THINK* was in the fact disks are not equal in size (ad1 is 3 sectors bigger): ad0: 38203MB [77619/16/63] at ata0-master UDMA100 ad1: 38204MB [77622/16/63] at ata0-slave UDMA100 In this case, fresh system was installed onto ad0, gm0 was created on ad1, when synchronise with added ad0 (as described in your step-by-step guide). The first synchronisation process (after addinbg ad0 into gm0) *was ok*, but after reboot, *I THINK*, gmirror discovered ad0 is less size than ad1 and refused to include it into gm0. Is this a bug or feature? The problem was solved by forget'ing gm0, creating gm1 on ad0, whet rebooting and adding ad1 (wthic is bigger than ad0) into it. Now everything seems to work ok... Thanks for the gmirror. From owner-freebsd-current@FreeBSD.ORG Sun Apr 24 19:30: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 66E0516A4D1; Sun, 24 Apr 2005 19:30:21 +0000 (GMT) Received: from darkness.comp.waw.pl (darkness.comp.waw.pl [195.117.238.136]) by mx1.FreeBSD.org (Postfix) with ESMTP id A2A9243D39; Sun, 24 Apr 2005 19:30:20 +0000 (GMT) (envelope-from pjd@darkness.comp.waw.pl) Received: by darkness.comp.waw.pl (Postfix, from userid 1009) id BA935AC976; Sun, 24 Apr 2005 21:30:18 +0200 (CEST) Date: Sun, 24 Apr 2005 21:30:18 +0200 From: Pawel Jakub Dawidek To: freebsd-current@freebsd.org, freebsd-geom@freebsd.org Message-ID: <20050424193018.GH837@darkness.comp.waw.pl> References: <20050424022434.GA3384@laptoxa.toxa.lan> <20050424094343.GA837@darkness.comp.waw.pl> <20050424190912.GA6743@laptoxa.toxa.lan> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="XmZLSFikexiR11mx" Content-Disposition: inline In-Reply-To: <20050424190912.GA6743@laptoxa.toxa.lan> 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 Subject: Re: gmirror: Not all disks connected X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 24 Apr 2005 19:30:21 -0000 --XmZLSFikexiR11mx Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Apr 24, 2005 at 11:09:12PM +0400, Toxa wrote: +> On Sun, Apr 24, 2005 at 11:43:43AM +0200, Pawel Jakub Dawidek wrote: +>=20 +> > Please read description of 'forget' subcommand. +>=20 +> Well, FYI, the problem *I THINK* was in the fact disks are not equal in +> size (ad1 is 3 sectors bigger): +>=20 +> ad0: 38203MB [77619/16/63] at ata0-master UDM= A100 +> ad1: 38204MB [77622/16/63] at ata0-slave UDMA= 100 +>=20 +> In this case, fresh system was installed onto ad0, gm0 was created on ad= 1,=20 +> when synchronise with added ad0 (as described in your step-by-step guide= ). +> The first synchronisation process (after addinbg ad0 into gm0) *was ok*, +> but after reboot, *I THINK*, gmirror discovered ad0 is less size than +> ad1 and refused to include it into gm0. Is this a bug or feature? +>=20 +> The problem was solved by forget'ing gm0, creating gm1 on ad0, whet rebo= oting and adding +> ad1 (wthic is bigger than ad0) into it. Now everything seems to work +> ok... If you created gmirror giving first smaller disk and then connecting bigger one it should be ok. If disk which you want to insert is smaller than already existing components, gmirror should return an error, so this is probably not the case. PS. This step-by-step guide is not mine - Ralf S. Engelschall is its author. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --XmZLSFikexiR11mx Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFCa/PKForvXbEpPzQRAtqcAKDhhu9thufeS1tvdrgjgy97AhrqhgCfamS8 J/91pXXis4fb8xm52IbB5m4= =67XO -----END PGP SIGNATURE----- --XmZLSFikexiR11mx-- From owner-freebsd-current@FreeBSD.ORG Sun Apr 24 19:44: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 B5D5516A4CE for ; Sun, 24 Apr 2005 19:44:40 +0000 (GMT) Received: from lexi.siliconlandmark.com (lexi.siliconlandmark.com [209.69.98.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4852943D49 for ; Sun, 24 Apr 2005 19:44:40 +0000 (GMT) (envelope-from andy@siliconlandmark.com) Received: from lexi.siliconlandmark.com (localhost [127.0.0.1]) j3OJiaK3021533; Sun, 24 Apr 2005 15:44:36 -0400 (EDT) (envelope-from andy@siliconlandmark.com) Received: from localhost (andy@localhost)j3OJiaJG021530; Sun, 24 Apr 2005 15:44:36 -0400 (EDT) (envelope-from andy@siliconlandmark.com) X-Authentication-Warning: lexi.siliconlandmark.com: andy owned process doing -bs Date: Sun, 24 Apr 2005 15:44:36 -0400 (EDT) From: Andre Guibert de Bruet To: Patrick Dung In-Reply-To: <20050424175543.71041.qmail@web51805.mail.yahoo.com> Message-ID: <20050424151517.O68772@lexi.siliconlandmark.com> References: <20050424175543.71041.qmail@web51805.mail.yahoo.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.544, required 6, autolearn=not spam, AWL 0.06, BAYES_00 -2.60) X-MailScanner-From: andy@siliconlandmark.com cc: freebsd-current@freebsd.org Subject: Re: FreeBSD 6 is coming too fast X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 24 Apr 2005 19:44:40 -0000 On Mon, 25 Apr 2005, Patrick Dung wrote: > I have read the recent status report. > IMHO, FreeBSD 5-stable is still not as stable as 4.x series. FreeBSD-5 > will have a short livetime when FreeBSD-6 comes. Ah, the "word on the street"; the usual claims without facts to back them. 5.x's undue and unjust reputation is precisely one of the reasons why 6.x is coming so soon. The other reasons have been outlined by Scott in a string of emails. Search the archives, if you are interested. If there is something you know about "5.x's stability" that we do not, please go ahead and share it with us. > May someone who work in large companies tell us their experience that > FreeBSD 4 or 5 is installed for servers now, please? At work, we have dozens of machines running 5.3 right now. In fact, my work is drawing up plans to phase out our last handful of 4.x servers. Cheers, Andy | Andre Guibert de Bruet | Enterprise Software Consultant > | Silicon Landmark, LLC. | http://siliconlandmark.com/ > From owner-freebsd-current@FreeBSD.ORG Sun Apr 24 20:01: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 1A2B016A4CE for ; Sun, 24 Apr 2005 20:01:36 +0000 (GMT) Received: from plouf.absolight.net (plouf.absolight.net [193.30.224.136]) by mx1.FreeBSD.org (Postfix) with ESMTP id BBCA043D31 for ; Sun, 24 Apr 2005 20:01:35 +0000 (GMT) (envelope-from mat@FreeBSD.org) Received: from pb.in.mat.cc (pb.in.mat.cc [193.30.224.125]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by plouf.absolight.net (Postfix) with ESMTP id 4E029A2400A; Sun, 24 Apr 2005 22:01:30 +0200 (CEST) Date: Sun, 24 Apr 2005 22:01:23 +0200 From: Mathieu Arnold To: Andre Guibert de Bruet , Patrick Dung Message-ID: In-Reply-To: <20050424151517.O68772@lexi.siliconlandmark.com> References: <20050424175543.71041.qmail@web51805.mail.yahoo.com> <20050424151517.O68772@lexi.siliconlandmark.com> X-Mailer: Mulberry/4.0.0b1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline cc: freebsd-current@freebsd.org Subject: Re: FreeBSD 6 is coming too fast X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 24 Apr 2005 20:01:36 -0000 +- Le 24/4/05 15:44 -0400, Andre Guibert de Bruet a dit : |> May someone who work in large companies tell us their experience that |> FreeBSD 4 or 5 is installed for servers now, please? | | At work, we have dozens of machines running 5.3 right now. In fact, my | work is drawing up plans to phase out our last handful of 4.x servers. For what it's worth, I have a bunch of 5.2.1, 5.3, and a few 5.4-RC running. A good friend of mine also has about a hundred of 5.0 running game servers for years now. -- Mathieu Arnold From owner-freebsd-current@FreeBSD.ORG Sun Apr 24 20:04: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 D6E3C16A4CE for ; Sun, 24 Apr 2005 20:04:00 +0000 (GMT) Received: from pi.codefab.com (pi.codefab.com [199.103.21.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7B8CC43D2F for ; Sun, 24 Apr 2005 20:04:00 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from localhost (localhost [127.0.0.1]) by pi.codefab.com (Postfix) with ESMTP id 478775CFF; Sun, 24 Apr 2005 16:03:54 -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 28097-06; Sun, 24 Apr 2005 16:03:52 -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 045415CF1; Sun, 24 Apr 2005 16:03:51 -0400 (EDT) Message-ID: <426BFB9C.5040808@mac.com> Date: Sun, 24 Apr 2005 16:03:40 -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.7) Gecko/20050414 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Patrick Dung References: <20050424175543.71041.qmail@web51805.mail.yahoo.com> In-Reply-To: <20050424175543.71041.qmail@web51805.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at codefab.com cc: freebsd-current@freebsd.org Subject: Re: FreeBSD 6 is coming too fast X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 24 Apr 2005 20:04:01 -0000 Patrick Dung wrote: > I have read the recent status report. > IMHO, FreeBSD 5-stable is still not as stable as 4.x series. FreeBSD-5 > will have a short livetime when FreeBSD-6 comes. Software version numbering is an inexact science at best, just like logistics. I agree that 4.x is more stable than 5.x is now. However, I suspect people remember issues with 5.0 or 5.1 more clearly than they remember using 4.0 or 4.1. > May someone who work in large companies tell us their experience that > FreeBSD 4 or 5 is installed for servers now, please? Most of my machines are at 4.10 or 4.11. I've got two production systems running 5.3 which have been doing just fine, too, and I'll be building out new machines with 5.x, but I don't plan on replacing a 4.x system unless I need to. (Some of the older boxes I have are getting up there, so I have been migrating services off of the older P2-grade machines onto the new 5.x boxes, especially the ones with IDE rather than SCSI disks.) Anyway, it's useful to change the OS major version # whenever libc or other aspects of the system API change in such a critical fashion that it is advisable to recompile all software for the new OS version. Sure, compatibility shims exist, but system VM takes twice the hit for the standard shared library overhead. However, some people like having a new major release each year, or even prefer the Win98/Win2000/Win2003 naming convention of using yearname as the major version #. I'm not that found of it myself, although I suppose it makes sense for certain inherently time-fragile software like accounting and tax-filing software, or for online encyclopedia's and such. -- -Chuck PS: This thread would be incomplete without a mention of: http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/freebsd-versions.html From owner-freebsd-current@FreeBSD.ORG Sun Apr 24 21:57: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 5A86416A4CE; Sun, 24 Apr 2005 21:57:31 +0000 (GMT) Received: from mail.sorbs.net (news.sorbs.net [203.15.51.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id A4E1943D1D; Sun, 24 Apr 2005 21:57:30 +0000 (GMT) (envelope-from matthew@uq.edu.au) Received: from [10.200.254.98] by nemesis.sorbs.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0IFH00C0M10J76@nemesis.sorbs.net>; Mon, 25 Apr 2005 07:57:56 +1000 (EST) Date: Mon, 25 Apr 2005 07:56:16 +1000 From: Matthew Sullivan In-reply-to: <426BC78A.3E56D99B@freebsd.org> To: Andre Oppermann Message-id: <426C1600.106@uq.edu.au> MIME-version: 1.0 Content-type: multipart/signed; boundary=------------ms070602060505020301080106; micalg=sha1; protocol="application/x-pkcs7-signature" X-Accept-Language: en User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041231 References: <426426AE.2060406@uq.edu.au> <20050420084413.GA27304@walton.maths.tcd.ie> <42663EA1.3020409@uq.edu.au> <426A3F49.6090203@uq.edu.au> <20050424150211.GA87520@walton.maths.tcd.ie> <426BC78A.3E56D99B@freebsd.org> cc: David Malone cc: freebsd-current@freebsd.org Subject: Re: DF (Don't frag) issues X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 24 Apr 2005 21:57:31 -0000 This is a cryptographically signed message in MIME format. --------------ms070602060505020301080106 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Andre Oppermann wrote: >David Malone wrote: > > >>On Sat, Apr 23, 2005 at 10:27:53PM +1000, Matthew Sullivan wrote: >> >> >>>Ok well thanks to Andrew @ Supernews and a lot of debugging it appears >>>there is a bug.... >>> >>>sys/netinet/ip_icmp.c: line 440 >>> if (!mtu) >>> mtu = ip_next_mtu(mtu, 1); >>>Problem is ip_next_mtu will always return 0 when called with (0, 1) ... >>> >>> >>I think this might be a bug, but Andre would know better. Andre - >>it looks to me as if the first argument to ip_next_mtu here should >>be the current MTU for the path, but it is being set to the mtu >>from the ICMP message, which (in this case) is zero. >> >> > >This is a bug indeed. Let me think how to fix this most efficiently... > > > >>(This is in the code that has just been moved to tcp_ctlinput.) >> >> >> >>>Apparently the gateway should be suggesting a MTU value for use.... the >>>gateway is also FreeBSD 5.3 so something needs fixing .. :-/ >>> >>> >>Are you using ip fast forwarding on the gateway? It calculates the >>size that is put into the ICMP message in a slightly different way >>to the other forwrd path. >> >> > >The quoted code above is used only for incoming ICMP packets. It >does not generate them? What is the problem being observed exactly? > > > As David suggested my config is shown here: http://lists.freebsd.org/pipermail/freebsd-current/2005-April/048980.html After talking with people I see 2 issues..... 1/ The bug is being triggered when the incoming 'need frag' ICMP message doesn't have a suggested value. This ICMP message is being generated by 'stealth.sorbs.net' which is a FreeBSD 5.3 p9 server running FAST_IPSEC (no crypto card yet - waiting for delivery), and otherwise pretty standard kernel. As for fast forwarding: net.inet.ip.fastforwarding: 0 2/ The bug itself is also a problem, as it cannot be guarenteed that the host returning the ICMP 'need frag' will fill in a suggested mtu, so that also needs to be looked at (but I guess you know that already ;-)) Regards, Mat -- Matthew Sullivan Specialist Systems Programmer Information Technology Services The University of Queensland --------------ms070602060505020301080106 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIG7DCC A3IwggJaoAMCAQICASowDQYJKoZIhvcNAQEEBQAwgaMxCzAJBgNVBAYTAkFVMRMwEQYDVQQI EwpRdWVlbnNsYW5kMREwDwYDVQQHEwhCcmlzYmFuZTElMCMGA1UEChMcVGhlIFVuaXZlcnNp dHkgb2YgUXVlZW5zbGFuZDEoMCYGA1UECxMfSW5mb3JtYXRpb24gVGVjaG5vbG9neSBTZXJ2 aWNlczEbMBkGA1UEAxMSQ2VydGlmaWNhdGUgU2VydmVyMB4XDTA0MDEyMTIzMzYyMVoXDTA2 MDEyMTIzMzYyMVowgbIxCzAJBgNVBAYTAkFVMSUwIwYDVQQKExxUaGUgVW5pdmVyc2l0eSBv ZiBRdWVlbnNsYW5kMScwJQYDVQQLEx5JbmZvcm1hdGlvbiBUZWNub2xvZ3kgU2VydmljZXMx FjAUBgoJkiaJk/IsZAEBEwZjY21hdHQxGTAXBgNVBAMTEE1hdHRoZXcgU3VsbGl2YW4xIDAe BgkqhkiG9w0BCQEWEW1hdHRoZXdAdXEuZWR1LmF1MFwwDQYJKoZIhvcNAQEBBQADSwAwSAJB AJsUfrw/QUqKIzDverWc2F4GFFRZmIeO+bAl+7BM6x/9frMzOtygx4QGb4oQwtOE8Sda1aIs v+yJF3Di9EuUyvMCAwEAAaNoMGYwDgYDVR0PAQH/BAQDAgXgMBEGCWCGSAGG+EIBAQQEAwIF oDAfBgNVHSMEGDAWgBQmqtoyueiWTYZBinvsnzeOWLtUuzAgBgNVHREEGTAXgRVtYXR0aGV3 QGl0cy51cS5lZHUuYXUwDQYJKoZIhvcNAQEEBQADggEBAF2gZrkqZsZlHd4K/+yBN6qrpD61 hctDf7/Eg4jk6DMknEs6nvHMFUMZ4SXvkqPLnHBygTARKAs7qBSLd7mUUBOOQEgk6ovQVY6S 1CDSt3P9O6wjG0K1igtk8v6u7lkQ8p2STXqrOePVINdaucUgBO/IpeUtt9ATl1qvPTWyM/fz oUZsIKeYjNQVEQsuimrZjdbIAFxdl1fggSngUv64wBn8wCssGrPZIZA2lpBBEW1wejoWrDOH IIr+SspGd0i8MovDTMRSvgTERLki17FU/ANilcrSXiODKeIvpXhnQqVScnsoMSZmBmN2QIoG SnBjNK5mYxx5E3v20VOwtP1hVdEwggNyMIICWqADAgECAgEqMA0GCSqGSIb3DQEBBAUAMIGj MQswCQYDVQQGEwJBVTETMBEGA1UECBMKUXVlZW5zbGFuZDERMA8GA1UEBxMIQnJpc2JhbmUx JTAjBgNVBAoTHFRoZSBVbml2ZXJzaXR5IG9mIFF1ZWVuc2xhbmQxKDAmBgNVBAsTH0luZm9y bWF0aW9uIFRlY2hub2xvZ3kgU2VydmljZXMxGzAZBgNVBAMTEkNlcnRpZmljYXRlIFNlcnZl cjAeFw0wNDAxMjEyMzM2MjFaFw0wNjAxMjEyMzM2MjFaMIGyMQswCQYDVQQGEwJBVTElMCMG A1UEChMcVGhlIFVuaXZlcnNpdHkgb2YgUXVlZW5zbGFuZDEnMCUGA1UECxMeSW5mb3JtYXRp b24gVGVjbm9sb2d5IFNlcnZpY2VzMRYwFAYKCZImiZPyLGQBARMGY2NtYXR0MRkwFwYDVQQD ExBNYXR0aGV3IFN1bGxpdmFuMSAwHgYJKoZIhvcNAQkBFhFtYXR0aGV3QHVxLmVkdS5hdTBc MA0GCSqGSIb3DQEBAQUAA0sAMEgCQQCbFH68P0FKiiMw73q1nNheBhRUWZiHjvmwJfuwTOsf /X6zMzrcoMeEBm+KEMLThPEnWtWiLL/siRdw4vRLlMrzAgMBAAGjaDBmMA4GA1UdDwEB/wQE AwIF4DARBglghkgBhvhCAQEEBAMCBaAwHwYDVR0jBBgwFoAUJqraMrnolk2GQYp77J83jli7 VLswIAYDVR0RBBkwF4EVbWF0dGhld0BpdHMudXEuZWR1LmF1MA0GCSqGSIb3DQEBBAUAA4IB AQBdoGa5KmbGZR3eCv/sgTeqq6Q+tYXLQ3+/xIOI5OgzJJxLOp7xzBVDGeEl75Kjy5xwcoEw ESgLO6gUi3e5lFATjkBIJOqL0FWOktQg0rdz/TusIxtCtYoLZPL+ru5ZEPKdkk16qznj1SDX WrnFIATvyKXlLbfQE5darz01sjP386FGbCCnmIzUFRELLopq2Y3WyABcXZdX4IEp4FL+uMAZ /MArLBqz2SGQNpaQQRFtcHo6FqwzhyCK/krKRndIvDKLw0zEUr4ExES5ItexVPwDYpXK0l4j gyniL6V4Z0KlUnJ7KDEmZgZjdkCKBkpwYzSuZmMceRN79tFTsLT9YVXRMYIDQDCCAzwCAQEw gakwgaMxCzAJBgNVBAYTAkFVMRMwEQYDVQQIEwpRdWVlbnNsYW5kMREwDwYDVQQHEwhCcmlz YmFuZTElMCMGA1UEChMcVGhlIFVuaXZlcnNpdHkgb2YgUXVlZW5zbGFuZDEoMCYGA1UECxMf SW5mb3JtYXRpb24gVGVjaG5vbG9neSBTZXJ2aWNlczEbMBkGA1UEAxMSQ2VydGlmaWNhdGUg U2VydmVyAgEqMAkGBSsOAwIaBQCgggItMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ KoZIhvcNAQkFMQ8XDTA1MDQyNDIxNTYxNlowIwYJKoZIhvcNAQkEMRYEFDILw9fzIocfjjaS as/6eFz8tul3MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIG6BgkrBgEEAYI3EAQx gawwgakwgaMxCzAJBgNVBAYTAkFVMRMwEQYDVQQIEwpRdWVlbnNsYW5kMREwDwYDVQQHEwhC cmlzYmFuZTElMCMGA1UEChMcVGhlIFVuaXZlcnNpdHkgb2YgUXVlZW5zbGFuZDEoMCYGA1UE CxMfSW5mb3JtYXRpb24gVGVjaG5vbG9neSBTZXJ2aWNlczEbMBkGA1UEAxMSQ2VydGlmaWNh dGUgU2VydmVyAgEqMIG8BgsqhkiG9w0BCRACCzGBrKCBqTCBozELMAkGA1UEBhMCQVUxEzAR BgNVBAgTClF1ZWVuc2xhbmQxETAPBgNVBAcTCEJyaXNiYW5lMSUwIwYDVQQKExxUaGUgVW5p dmVyc2l0eSBvZiBRdWVlbnNsYW5kMSgwJgYDVQQLEx9JbmZvcm1hdGlvbiBUZWNobm9sb2d5 IFNlcnZpY2VzMRswGQYDVQQDExJDZXJ0aWZpY2F0ZSBTZXJ2ZXICASowDQYJKoZIhvcNAQEB BQAEQGuE+aAd3Sd023A6/iyjQSAInMzIyd+GLX9QeVuyyLaGQSB8N1R+BVfozMokG/hm+fjf UD7hVKHAebtE/Bwl724AAAAAAAA= --------------ms070602060505020301080106-- From owner-freebsd-current@FreeBSD.ORG Sun Apr 24 22:44: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 C92B116A4CE for ; Sun, 24 Apr 2005 22:44:17 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id E872143D31 for ; Sun, 24 Apr 2005 22:44:16 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 3917 invoked from network); 24 Apr 2005 22:45:30 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.54]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 24 Apr 2005 22:45:30 -0000 Message-ID: <426C213F.2AC415F6@freebsd.org> Date: Mon, 25 Apr 2005 00:44:15 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Matthew Sullivan References: <426426AE.2060406@uq.edu.au><42663EA1.3020409@uq.edu.au> <20050424150211.GA87520@walton.maths.tcd.ie> <426BC78A.3E56D99B@freebsd.org> <426C1600.106@uq.edu.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: David Malone cc: freebsd-current@freebsd.org Subject: Re: DF (Don't frag) issues X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 24 Apr 2005 22:44:17 -0000 Matthew Sullivan wrote: > > Andre Oppermann wrote: > > >David Malone wrote: > > > > > >>On Sat, Apr 23, 2005 at 10:27:53PM +1000, Matthew Sullivan wrote: > >> > >> > >>>Ok well thanks to Andrew @ Supernews and a lot of debugging it appears > >>>there is a bug.... > >>> > >>>sys/netinet/ip_icmp.c: line 440 > >>> if (!mtu) > >>> mtu = ip_next_mtu(mtu, 1); > >>>Problem is ip_next_mtu will always return 0 when called with (0, 1) ... > >>> > >>> > >>I think this might be a bug, but Andre would know better. Andre - > >>it looks to me as if the first argument to ip_next_mtu here should > >>be the current MTU for the path, but it is being set to the mtu > >>from the ICMP message, which (in this case) is zero. > >> > >> > > > >This is a bug indeed. Let me think how to fix this most efficiently... > > > > > > > >>(This is in the code that has just been moved to tcp_ctlinput.) > >> > >> > >> > >>>Apparently the gateway should be suggesting a MTU value for use.... the > >>>gateway is also FreeBSD 5.3 so something needs fixing .. :-/ > >>> > >>> > >>Are you using ip fast forwarding on the gateway? It calculates the > >>size that is put into the ICMP message in a slightly different way > >>to the other forwrd path. > >> > >> > > > >The quoted code above is used only for incoming ICMP packets. It > >does not generate them? What is the problem being observed exactly? > > > > > > > As David suggested my config is shown here: > > http://lists.freebsd.org/pipermail/freebsd-current/2005-April/048980.html > > After talking with people I see 2 issues..... > > 1/ The bug is being triggered when the incoming 'need frag' ICMP message > doesn't have a suggested value. > > This ICMP message is being generated by 'stealth.sorbs.net' which is a > FreeBSD 5.3 p9 server running FAST_IPSEC (no crypto card yet - waiting > for delivery), and otherwise pretty standard kernel. As for fast forwarding: > > net.inet.ip.fastforwarding: 0 > > 2/ The bug itself is also a problem, as it cannot be guarenteed that the > host returning the ICMP 'need frag' will fill in a suggested mtu, so > that also needs to be looked at (but I guess you know that already ;-)) Ok, I'm looking into this stuff. -- Andre From owner-freebsd-current@FreeBSD.ORG Sun Apr 24 23:29: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 525B016A4CE for ; Sun, 24 Apr 2005 23:29:36 +0000 (GMT) Received: from fast.dnswatch.com (fast.dnswatch.com [216.177.243.43]) by mx1.FreeBSD.org (Postfix) with ESMTP id 94CDB43D1F for ; Sun, 24 Apr 2005 23:29:35 +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 j3ONTWsm041919; Sun, 24 Apr 2005 16:29:35 -0700 (PDT) (envelope-from null@dnswatch.com) Received: (from www@localhost) by fast.dnswatch.com (8.12.6/8.12.6/Submit) id j3ONTVLK041918; Sun, 24 Apr 2005 16:29:31 -0700 (PDT) (envelope-from null@dnswatch.com) X-Authentication-Warning: fast.dnswatch.com: www set sender to null@dnswatch.com using -f Received: from ns0.1command.com ([216.177.243.38]) (DNSwatch.com_WebMail authenticated user null) by webmail.dnswatch.com with HTTP; Sun, 24 Apr 2005 16:29:30 -0700 (PDT) Message-ID: <3822.216.177.243.38.1114385370.localmail@webmail.dnswatch.com> In-Reply-To: <20050424151517.O68772@lexi.siliconlandmark.com> References: <20050424175543.71041.qmail@web51805.mail.yahoo.com> <20050424151517.O68772@lexi.siliconlandmark.com> Date: Sun, 24 Apr 2005 16:29:30 -0700 (PDT) From: "/dev/null" To: freebsd-current@freebsd.org, andy@siliconlandmark.com 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: FreeBSD 6 is coming too fast X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 24 Apr 2005 23:29:36 -0000 Greetings, I have been on FreeBSD since the start. As a hobby until 3.x where I began to replace Winblows servers with FBSD. I stayed with 4.2 the longest. I still have 2 servers running it. However, I decided to test 5.0-RC2 on a lightly used server. My reason for the upgrade decision was the fact that some of the applications I used in 4.x were a little immature, not as rhobust, or as stable as I would prefer. My upgrade path = tar cvgf /etc, /root, /var, /usr/home, /usr/local/etc, and /usr/local/www. Then booting to the 5.0-RC2 CD and performing a "fresh" install. Afterwhich I simply merged by backed-up settings and important files. A little while later I used the same upgrade method to upgrade a *heavily* used server. All seemed *mostly* O.K. But security issues were reported. Attempts to go the "patch" route failed miserably. I also found the security patch routes "intuitiveness" !> -1. The patches clobbered my src files and so I decided to go a different route - I chose to burn the 5.3-STABLE CD's, boot to #1 and choose "upgrade" from the insrtallation routine(s). I did *NOT* attempt this before backing up the important nodes listed above. Well, this route didn't turn out to be the most ideal route. So I ultimately blew all the slices away and performed a fresh install of 5.3-STABLE and merge my previous settings/ folders as needed. All in all life on 5.x and the "upgrade" wasn't too bad. I will say that there is ONE issue that I have found and have not yet solved. It now takes at least 2 times longer to build any of the ports. Performance in other areas seems to be lagging as well. I have since upgraded one of the 2 servers to 5.4-RC2 and have been chasing 5.x ever since hoping to find the performance issues will dissappear. Just my experiences thus far FWIW. -Chris > > On Mon, 25 Apr 2005, Patrick Dung wrote: > >> I have read the recent status report. >> IMHO, FreeBSD 5-stable is still not as stable as 4.x series. FreeBSD-5 >> will have a short livetime when FreeBSD-6 comes. > > Ah, the "word on the street"; the usual claims without facts to back them. > > 5.x's undue and unjust reputation is precisely one of the reasons why 6.x > is coming so soon. The other reasons have been outlined by Scott in a > string of emails. Search the archives, if you are interested. > > If there is something you know about "5.x's stability" that we do not, > please go ahead and share it with us. > >> May someone who work in large companies tell us their experience that >> FreeBSD 4 or 5 is installed for servers now, please? > > At work, we have dozens of machines running 5.3 right now. In fact, my > work is drawing up plans to phase out our last handful of 4.x servers. > > Cheers, > Andy > > | 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" > //////////////////////////////////////////////////// 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 Sun Apr 24 23:58: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 83E8916A4CE for ; Sun, 24 Apr 2005 23:58:14 +0000 (GMT) Received: from smtp807.mail.sc5.yahoo.com (smtp807.mail.sc5.yahoo.com [66.163.168.186]) by mx1.FreeBSD.org (Postfix) with SMTP id 43A5943D54 for ; Sun, 24 Apr 2005 23:58:14 +0000 (GMT) (envelope-from noackjr@alumni.rice.edu) Received: from unknown (HELO optimator.noacks.org) (noacks@swbell.net@70.240.205.64 with login) by smtp807.mail.sc5.yahoo.com with SMTP; 24 Apr 2005 23:58:13 -0000 Received: from localhost (localhost [127.0.0.1]) by optimator.noacks.org (Postfix) with ESMTP id 6EF6260D5; Sun, 24 Apr 2005 18:58:13 -0500 (CDT) Received: from optimator.noacks.org ([127.0.0.1]) by localhost (optimator.noacks.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 98046-03; Sun, 24 Apr 2005 18:58:12 -0500 (CDT) Received: from compgeek.noacks.org (compgeek [192.168.1.10]) by optimator.noacks.org (Postfix) with ESMTP id 0636060CF; Sun, 24 Apr 2005 18:58:11 -0500 (CDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by compgeek.noacks.org (8.13.3/8.13.3) with ESMTP id j3ONw2ma000908; Sun, 24 Apr 2005 18:58:03 -0500 (CDT) (envelope-from noackjr@alumni.rice.edu) Message-ID: <426C328A.9060606@alumni.rice.edu> Date: Sun, 24 Apr 2005 18:58:02 -0500 From: Jon Noack User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050406) X-Accept-Language: en-us, en MIME-Version: 1.0 To: /dev/null References: <20050424175543.71041.qmail@web51805.mail.yahoo.com> <20050424151517.O68772@lexi.siliconlandmark.com> <3822.216.177.243.38.1114385370.localmail@webmail.dnswatch.com> In-Reply-To: <3822.216.177.243.38.1114385370.localmail@webmail.dnswatch.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at noacks.org cc: freebsd-current@freebsd.org Subject: Re: FreeBSD 6 is coming too fast X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: noackjr@alumni.rice.edu List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Apr 2005 23:58:14 -0000 On 04/24/05 18:29, /dev/null wrote: > > > needed. All in all life on 5.x and the "upgrade" wasn't too bad. I will > say that there is ONE issue that I have found and have not yet solved. It > now takes at least 2 times longer to build any of the ports. Performance > in other areas seems to be lagging as well. I have since upgraded one of > the 2 servers to 5.4-RC2 and have been chasing 5.x ever since hoping to > find the performance issues will dissappear. If you are running a UP system, it is expected that 4.x will outperform 5.x in many situations due to the focus on SMP. Optimizing synchronization to increase performance is one of the main goals for 6.x (see the recent work on critical sections, for example). This will allow us to scale well on SMP systems without pessimizing performance on UP systems. Another point to remember is that compilation times with GCC 3.4 (default for recent 5.x) are much longer than those with 2.95 (default for 4.x), especially at higher optimization levels. This is one of the main reasons why it takes longer to compile a port. That said, in what specific areas are you seeing performance regressions? Jon From owner-freebsd-current@FreeBSD.ORG Mon Apr 25 00:01: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 C258016A4CE for ; Mon, 25 Apr 2005 00:01:01 +0000 (GMT) Received: from mail.fci.fsu.edu (mail.fci.fsu.edu [128.186.195.169]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8023643D49 for ; Mon, 25 Apr 2005 00:01:01 +0000 (GMT) (envelope-from neuro@mail.fci.fsu.edu) Received: from mail.fci.fsu.edu (mail.fci.fsu.edu [127.0.0.1]) by mail.fci.fsu.edu (Postfix) with ESMTP id 8D3941534DA; Sun, 24 Apr 2005 20:10:03 -0400 (EDT) Date: Sun, 24 Apr 2005 20:10:03 -0400 (EDT) From: neuro@mail.fci.fsu.edu To: Jon Noack In-Reply-To: <426C328A.9060606@alumni.rice.edu> Message-ID: References: <20050424175543.71041.qmail@web51805.mail.yahoo.com> <20050424151517.O68772@lexi.siliconlandmark.com> <3822.216.177.243.38.1114385370.localmail@webmail.dnswatch.com> <426C328A.9060606@alumni.rice.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed cc: /dev/null cc: freebsd-current@freebsd.org Subject: Re: FreeBSD 6 is coming too fast X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 25 Apr 2005 00:01:01 -0000 performance on many systems is very hard to gauge. I think this is something mostly left up to the individual, as hardware-software combinations truly make up the performance of a system. On Sun, 24 Apr 2005, Jon Noack wrote: > On 04/24/05 18:29, /dev/null wrote: >> >> >> needed. All in all life on 5.x and the "upgrade" wasn't too bad. I will >> say that there is ONE issue that I have found and have not yet solved. It >> now takes at least 2 times longer to build any of the ports. Performance >> in other areas seems to be lagging as well. I have since upgraded one of >> the 2 servers to 5.4-RC2 and have been chasing 5.x ever since hoping to >> find the performance issues will dissappear. > > If you are running a UP system, it is expected that 4.x will outperform 5.x > in many situations due to the focus on SMP. Optimizing synchronization to > increase performance is one of the main goals for 6.x (see the recent work on > critical sections, for example). This will allow us to scale well on SMP > systems without pessimizing performance on UP systems. > > Another point to remember is that compilation times with GCC 3.4 (default for > recent 5.x) are much longer than those with 2.95 (default for 4.x), > especially at higher optimization levels. This is one of the main reasons > why it takes longer to compile a port. > > That said, in what specific areas are you seeing performance regressions? > > Jon > _______________________________________________ > 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 25 00:05: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 E73BD16A4CE for ; Mon, 25 Apr 2005 00:05:00 +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 9FED443D1D for ; Mon, 25 Apr 2005 00:05:00 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 5827E514FE; Sun, 24 Apr 2005 17:04:59 -0700 (PDT) Date: Sun, 24 Apr 2005 17:04:59 -0700 From: Kris Kennaway To: /dev/null Message-ID: <20050425000459.GA28667@xor.obsecurity.org> References: <20050424175543.71041.qmail@web51805.mail.yahoo.com> <20050424151517.O68772@lexi.siliconlandmark.com> <3822.216.177.243.38.1114385370.localmail@webmail.dnswatch.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Nq2Wo0NMKNjxTN9z" Content-Disposition: inline In-Reply-To: <3822.216.177.243.38.1114385370.localmail@webmail.dnswatch.com> User-Agent: Mutt/1.4.2.1i cc: freebsd-current@freebsd.org Subject: Re: FreeBSD 6 is coming too fast X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 25 Apr 2005 00:05:01 -0000 --Nq2Wo0NMKNjxTN9z Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Sun, Apr 24, 2005 at 04:29:30PM -0700, /dev/null wrote: > needed. All in all life on 5.x and the "upgrade" wasn't too bad. I will > say that there is ONE issue that I have found and have not yet solved. It > now takes at least 2 times longer to build any of the ports. This is not a FreeBSD performance bug. FreeBSD 5.x uses gcc 3.x, which takes longer to compile code than gcc 2.x because it does much more optimization. > Performance in other areas seems to be lagging as well. Since you were wrong about the above, I have to ask whether you have evidence of this. Kris --Nq2Wo0NMKNjxTN9z Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFCbDQqWry0BWjoQKURAoEDAKDsecGoOo5l4C4qNMFbueeiwKjGjwCfenPd 5NneMcPzbhx3AgKALVleld4= =pQcq -----END PGP SIGNATURE----- --Nq2Wo0NMKNjxTN9z-- From owner-freebsd-current@FreeBSD.ORG Mon Apr 25 00:06: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 1C56A16A4CE for ; Mon, 25 Apr 2005 00:06:17 +0000 (GMT) Received: from avscan2.sentex.ca (avscan2.sentex.ca [199.212.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8DE5F43D3F for ; Mon, 25 Apr 2005 00:06:16 +0000 (GMT) (envelope-from mike@sentex.net) Received: from localhost (localhost.sentex.ca [127.0.0.1]) by avscan2.sentex.ca (8.12.11/8.12.11) with ESMTP id j3P06HcH077073; Sun, 24 Apr 2005 20:06:17 -0400 (EDT) (envelope-from mike@sentex.net) Received: from avscan2.sentex.ca ([127.0.0.1]) by localhost (avscan2.sentex.ca [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 76107-08; Sun, 24 Apr 2005 20:06:17 -0400 (EDT) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by avscan2.sentex.ca (8.12.11/8.12.11) with ESMTP id j3P06HNr077068; Sun, 24 Apr 2005 20:06:17 -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 j3P069Pv065221; Sun, 24 Apr 2005 20:06:09 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <6.2.1.2.0.20050424180315.04a43a38@64.7.153.2> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Sun, 24 Apr 2005 20:05:23 -0400 To: Patrick Dung , freebsd-current@freebsd.org From: Mike Tancsa In-Reply-To: <20050424175543.71041.qmail@web51805.mail.yahoo.com> References: <20050424175543.71041.qmail@web51805.mail.yahoo.com> 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 avscan2b Subject: Re: FreeBSD 6 is coming too fast X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 25 Apr 2005 00:06:17 -0000 At 01:55 PM 24/04/2005, Patrick Dung wrote: >May someone who work in large companies tell us their experience that >FreeBSD 4 or 5 is installed for servers now, please? We have a number of RELENG_5 boxes in production. The ones with the highest load are acting as avscanners (clamav, amavisd) and spamscanners (SA) as well as one box for customers who enable TMDA on their mailboxes which can really get punished. No problems at all. These are busy boxes with all sorts of bursty and sometimes sustained loads thrown on them. They are mostly CPU bound, but often busy with disk IO as well. We are also starting to deploy our managed firewall boxes for our customers on RELENG_5 The only problem I have run into is nfsd failing on some bonnie++ tests. e.g. [3w-mobile]# bonnie++ -u root -s 4G -n 40 -d /mnt Using uid:0, gid:0. Writing a byte at a time...done Writing intelligently...done Rewriting...done Reading a byte at a time...done Reading intelligently...done start 'em...done...done...done...done...done... Create files in sequential order...done. Stat files in sequential order...done. Delete files in sequential order...Bonnie: drastic I/O error (rmdir): Directory not empty Cleaning up test directory after error. [3w-mobile]# mount /dev/twed0s1a on / (ufs, local) devfs on /dev (devfs, local) /dev/twed0s1e on /tmp (ufs, local, soft-updates) /dev/twed0s1d on /usr (ufs, local, soft-updates) /dev/twed0s1f on /var (ufs, local, soft-updates) 10.1.1.1:/mnt on /mnt (nfs) [3w-mobile]# From owner-freebsd-current@FreeBSD.ORG Mon Apr 25 00: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 50AAC16A4CE; Mon, 25 Apr 2005 00:50:30 +0000 (GMT) Received: from vms040pub.verizon.net (vms040pub.verizon.net [206.46.252.40]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0F56D43D2D; Mon, 25 Apr 2005 00:50:30 +0000 (GMT) (envelope-from Alex.Kovalenko@verizon.net) Received: from RabbitsDen ([70.21.148.39]) by vms040.mailsrvcs.net (Sun Java System Messaging Server 6.2 HotFix 0.04 (built Dec 24 2004)) with ESMTPA id <0IFH00AYL904ZA46@vms040.mailsrvcs.net>; Sun, 24 Apr 2005 19:50:29 -0500 (CDT) Date: Sun, 24 Apr 2005 20:49:07 -0400 From: "Alexandre \"Sunny\" Kovalenko" In-reply-to: <20050418135458.M53307@pcle2.cc.univie.ac.at> To: Lukas Ertl Message-id: <1114390147.944.8.camel@RabbitsDen> MIME-version: 1.0 X-Mailer: Evolution 2.2.1.1 FreeBSD GNOME Team Port Content-type: multipart/mixed; boundary="Boundary_(ID_YOsjHkpanzf8T0SB17/sSw)" References: <20050416213144.9A08C7306E@freebsd-current.sentex.ca> <20050418134818.62d172f2.sebastian.ssmoller@gmx.net> <20050418135458.M53307@pcle2.cc.univie.ac.at> cc: freebsd-current@FreeBSD.org cc: sebastian ssmoller Subject: Re: powerd(8) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 25 Apr 2005 00:50:30 -0000 --Boundary_(ID_YOsjHkpanzf8T0SB17/sSw) Content-type: text/plain; charset=iso-8859-5 Content-transfer-encoding: 8BIT On Mon, 2005-04-18 at 13:55 +0200, Lukas Ertl wrote: > On Mon, 18 Apr 2005, sebastian ssmoller wrote: > > > the currently implemented strategy caused the fan of my notebook to switch > > on within 15 min which it never did with estctrl running :( ... > > I also noticed that powerd in adaptive mode keeps my laptop pretty warm. > > cheers, > le > When I was messing around with my laptop's cooling system (fan, heatsink, etc.) I have come up with the patch to powerd to keep temperature below certain level and added -t switch to command line with the single argument -- temperature limit in Celsius. I have attached it just in case someone finds it useful. It was originally made against powerd 1.4, I have subsequently changed it to patch against 1.6, but have not tested it extensively after that. -- Alexandre "Sunny" Kovalenko (ŸÛÕÚáÐÝÔà ºÞÒÐÛÕÝÚÞ) --Boundary_(ID_YOsjHkpanzf8T0SB17/sSw) Content-type: text/x-patch; name=powerd.c.patch; charset=ASCII Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=powerd.c.patch --- ./usr.sbin/powerd/powerd.c Sun Apr 17 11:25:41 2005 +++ /home/sunny/powerd.c Sun Apr 24 20:46:40 2005 @@ -46,7 +46,8 @@ #define DEFAULT_ACTIVE_PERCENT 65 #define DEFAULT_IDLE_PERCENT 90 -#define DEFAULT_POLL_INTERVAL 500 /* Poll interval in milliseconds */ +#define DEFAULT_POLL_INTERVAL 500 /* Poll interval in milliseconds */ +#define VERY_HIGH_TEMPERATURE 200 enum modes_t { MODE_MIN, @@ -83,11 +84,13 @@ static int freq_mib[4]; static int levels_mib[4]; static int acline_mib[3]; +static int temp_mib[5]; /* Configuration */ static int cpu_running_mark; static int cpu_idle_mark; static int poll_ival; +static int passive_cooling_mark; static int apm_fd; static int exit_requested; @@ -244,7 +247,7 @@ { fprintf(stderr, -"usage: powerd [-v] [-a mode] [-b mode] [-i %%] [-n mode] [-p ival] [-r %%]\n"); +"usage: powerd [-v] [-a mode] [-b mode] [-i %%] [-n mode] [-p ival] [-r %%] [-t temperature]\n"); exit(1); } @@ -252,7 +255,7 @@ main(int argc, char * argv[]) { long idle, total; - int curfreq, *freqs, i, *mwatts, numfreqs; + int curfreq, *freqs, i, *mwatts, numfreqs, temperature; int ch, mode_ac, mode_battery, mode_none, acline, mode, vflag; uint64_t mjoules_used; size_t len; @@ -263,10 +266,11 @@ cpu_idle_mark = DEFAULT_IDLE_PERCENT; poll_ival = DEFAULT_POLL_INTERVAL; mjoules_used = 0; + passive_cooling_mark = VERY_HIGH_TEMPERATURE; vflag = 0; apm_fd = -1; - while ((ch = getopt(argc, argv, "a:b:i:n:p:r:v")) != EOF) + while ((ch = getopt(argc, argv, "a:b:i:n:p:r:t:v")) != EOF) switch (ch) { case 'a': parse_mode(optarg, &mode_ac, ch); @@ -300,6 +304,16 @@ usage(); } break; + case 't': + passive_cooling_mark = atoi(optarg); + if(passive_cooling_mark < 0 || passive_cooling_mark > 100) { + warnx("%d is not valid temperature for passive cooling", + passive_cooling_mark); + usage(); + } + passive_cooling_mark *= 10; + passive_cooling_mark += 2733; + break; case 'v': vflag = 1; break; @@ -320,6 +334,9 @@ len = 4; if (sysctlnametomib("dev.cpu.0.freq_levels", levels_mib, &len)) err(1, "lookup freq_levels"); + len = 5; + if (sysctlnametomib("hw.acpi.thermal.tz0.temperature", temp_mib, &len)) + err(1, "lookup temperature"); /* Check if we can read the idle time and supported freqs. */ if (read_usage_times(NULL, NULL)) @@ -370,6 +387,10 @@ len = sizeof(curfreq); if (sysctl(freq_mib, 4, &curfreq, &len, NULL, 0)) err(1, "error reading current CPU frequency"); + /* Read current temperature. */ + len = sizeof(temperature); + if(sysctl(temp_mib, 5, &temperature, &len, NULL, 0)) + err(1, "error reading current temperature"); if (vflag) { for (i = 0; i < numfreqs; i++) { @@ -410,12 +431,31 @@ err(1, "error setting CPU freq %d", freqs[0]); } + /* Check for passive cooling override */ + if(temperature > passive_cooling_mark) { + if (vflag) { + printf("passive cooling override; " + "changing frequency to %d MHz\n", + freqs[numfreqs - 1]); + } + if (set_freq(freqs[numfreqs - 1])) + err(1, "error setting CPU freq %d", + freqs[numfreqs - 1]); + } continue; } /* Adaptive mode; get the current CPU usage times. */ if (read_usage_times(&idle, &total)) err(1, "read_usage_times"); + /* + * If temperature has risen over passive cooling mark, we + * would want to decrease frequency regardless of the load, + * Simplest way to go about this would be to report 100% + * idle CPU and let adaptive algorithm do its job. + */ + if(temperature > passive_cooling_mark) + idle = total; /* * If we're idle less than the active mark, jump the CPU to --Boundary_(ID_YOsjHkpanzf8T0SB17/sSw)-- From owner-freebsd-current@FreeBSD.ORG Mon Apr 25 00:54: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 CFEDF16A4CE for ; Mon, 25 Apr 2005 00:54:54 +0000 (GMT) Received: from avscan2.sentex.ca (avscan2.sentex.ca [199.212.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6333043D39 for ; Mon, 25 Apr 2005 00:54:54 +0000 (GMT) (envelope-from mike@sentex.net) Received: from localhost (localhost.sentex.ca [127.0.0.1]) by avscan2.sentex.ca (8.12.11/8.12.11) with ESMTP id j3P0st15083897; Sun, 24 Apr 2005 20:54:55 -0400 (EDT) (envelope-from mike@sentex.net) Received: from avscan2.sentex.ca ([127.0.0.1]) by localhost (avscan2.sentex.ca [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 83453-06; Sun, 24 Apr 2005 20:54:54 -0400 (EDT) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by avscan2.sentex.ca (8.12.11/8.12.11) with ESMTP id j3P0ssBq083872; Sun, 24 Apr 2005 20:54:54 -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 j3P0skMt065310; Sun, 24 Apr 2005 20:54:47 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <6.2.1.2.0.20050424204611.072105a0@64.7.153.2> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Sun, 24 Apr 2005 20:54:00 -0400 To: Kris Kennaway From: Mike Tancsa In-Reply-To: <20050425000459.GA28667@xor.obsecurity.org> References: <20050424175543.71041.qmail@web51805.mail.yahoo.com> <20050424151517.O68772@lexi.siliconlandmark.com> <3822.216.177.243.38.1114385370.localmail@webmail.dnswatch.com> <20050425000459.GA28667@xor.obsecurity.org> 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 avscan2b cc: freebsd-current@freebsd.org Subject: Re: FreeBSD 6 is coming too fast X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 25 Apr 2005 00:54:54 -0000 At 08:04 PM 24/04/2005, Kris Kennaway wrote: > > Performance in other areas seems to be lagging as well. > >Since you were wrong about the above, I have to ask whether you have >evidence of this. There was a lengthy discussion along with bonnie, dd, postmark and iozone results discussed in January on the freebsd-performance list that illustrate the disk io difference between RELENG_4 and RELENG_5 at the time. I also tried a CURRENT snapshot then and there wasn't much of a difference between it and RELENG_5. ---Mike From owner-freebsd-current@FreeBSD.ORG Mon Apr 25 00: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 DAB5616A4CE; Mon, 25 Apr 2005 00:57:08 +0000 (GMT) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5D24D43D46; Mon, 25 Apr 2005 00:57:08 +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 j3P0v7Q0043412; Sun, 24 Apr 2005 20:57: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 j3P0v7Gr023081; Sun, 24 Apr 2005 20:57:07 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 93BDB7306E; Sun, 24 Apr 2005 20:57:07 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050425005707.93BDB7306E@freebsd-current.sentex.ca> Date: Sun, 24 Apr 2005 20:57:07 -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 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: Mon, 25 Apr 2005 00:57:09 -0000 TB --- 2005-04-24 23:17:10 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-04-24 23:17:10 - starting CURRENT tinderbox run for amd64/amd64 TB --- 2005-04-24 23:17:10 - checking out the source tree TB --- 2005-04-24 23:17:10 - cd /home/tinderbox/CURRENT/amd64/amd64 TB --- 2005-04-24 23:17:10 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-04-24 23:23:54 - building world (CFLAGS=-O2 -pipe) TB --- 2005-04-24 23:23:54 - cd /home/tinderbox/CURRENT/amd64/amd64/src TB --- 2005-04-24 23:23:54 - /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-25 00:36:25 - building generic kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-04-25 00:36:25 - cd /home/tinderbox/CURRENT/amd64/amd64/src TB --- 2005-04-25 00:36:25 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Mon Apr 25 00:36:25 UTC 2005 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for GENERIC completed on Mon Apr 25 00:52:49 UTC 2005 TB --- 2005-04-25 00:52:49 - generating LINT kernel config TB --- 2005-04-25 00:52:49 - cd /home/tinderbox/CURRENT/amd64/amd64/src/sys/amd64/conf TB --- 2005-04-25 00:52:49 - /usr/bin/make -B LINT TB --- 2005-04-25 00:52:49 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-04-25 00:52:49 - cd /home/tinderbox/CURRENT/amd64/amd64/src TB --- 2005-04-25 00:52:49 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Apr 25 00:52: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 -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 -I/tinderbox/CURRENT/amd64/amd64/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 -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-ta bles -ffreestanding -Werror /tinderbox/CURRENT/amd64/amd64/src/sys/dev/acpica/Osd/OsdDebug.c In file included from /tinderbox/CURRENT/amd64/amd64/src/sys/dev/acpica/Osd/OsdDebug.c:45: /tinderbox/CURRENT/amd64/amd64/src/sys/dev/acpica/acpivar.h:425:1: "ACPI_MAX_THREADS" redefined In file included from /tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/acpica/acfreebsd.h:128, from /tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/acpica/acenv.h:208, from /tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/acpica/acpi.h:126, from /tinderbox/CURRENT/amd64/amd64/src/sys/dev/acpica/Osd/OsdDebug.c:43: ./opt_acpi.h:2:1: this is the location of the previous definition *** Error code 1 Stop in /tinderbox/CURRENT/amd64/amd64/obj/amd64/tinderbox/CURRENT/amd64/amd64/src/sys/LINT. *** Error code 1 Stop in /tinderbox/CURRENT/amd64/amd64/src. *** Error code 1 Stop in /tinderbox/CURRENT/amd64/amd64/src. TB --- 2005-04-25 00:57:07 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-04-25 00:57:07 - ERROR: failed to build lint kernel TB --- 2005-04-25 00:57:07 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Mon Apr 25 01:02: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 E775416A4CE for ; Mon, 25 Apr 2005 01:02: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 1CA8B43D2D for ; Mon, 25 Apr 2005 01:02:49 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 216A7531E2; Sun, 24 Apr 2005 18:02:43 -0700 (PDT) Date: Sun, 24 Apr 2005 18:02:42 -0700 From: Kris Kennaway To: Mike Tancsa Message-ID: <20050425010242.GA44110@xor.obsecurity.org> References: <20050424175543.71041.qmail@web51805.mail.yahoo.com> <20050424151517.O68772@lexi.siliconlandmark.com> <3822.216.177.243.38.1114385370.localmail@webmail.dnswatch.com> <20050425000459.GA28667@xor.obsecurity.org> <6.2.1.2.0.20050424204611.072105a0@64.7.153.2> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="oyUTqETQ0mS9luUI" Content-Disposition: inline In-Reply-To: <6.2.1.2.0.20050424204611.072105a0@64.7.153.2> User-Agent: Mutt/1.4.2.1i cc: freebsd-current@freebsd.org cc: Kris Kennaway Subject: Re: FreeBSD 6 is coming too fast X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 25 Apr 2005 01:02:50 -0000 --oyUTqETQ0mS9luUI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Apr 24, 2005 at 08:54:00PM -0400, Mike Tancsa wrote: > At 08:04 PM 24/04/2005, Kris Kennaway wrote: >=20 > >> Performance in other areas seems to be lagging as well. > > > >Since you were wrong about the above, I have to ask whether you have > >evidence of this. >=20 > There was a lengthy discussion along with bonnie, dd, postmark and iozone= =20 > results discussed in January on the freebsd-performance list that=20 > illustrate the disk io difference between RELENG_4 and RELENG_5 at the ti= me. >=20 > I also tried a CURRENT snapshot then and there wasn't much of a differenc= e=20 > between it and RELENG_5. disk I/O or filesystem I/O? It would be interesting to benchmark the latter since all the recent VFS work. Kris --oyUTqETQ0mS9luUI Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFCbEGxWry0BWjoQKURAropAKCHnQBq4McxN6HwWsmSRaFdvW2u1gCfZjSL yvDLA6Ov8aB/8KinY5PSz8g= =hYKy -----END PGP SIGNATURE----- --oyUTqETQ0mS9luUI-- From owner-freebsd-current@FreeBSD.ORG Mon Apr 25 01:36: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 1959216A4FB for ; Mon, 25 Apr 2005 01:36:14 +0000 (GMT) Received: from avscan1.sentex.ca (avscan1.sentex.ca [199.212.134.11]) by mx1.FreeBSD.org (Postfix) with ESMTP id AB27643D1D for ; Mon, 25 Apr 2005 01:36:13 +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 j3P1aCKI084375; Sun, 24 Apr 2005 21:36:12 -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 83962-05; Sun, 24 Apr 2005 21:36:12 -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 j3P1aCJV084370; Sun, 24 Apr 2005 21:36:12 -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 j3P1a66x065390; Sun, 24 Apr 2005 21:36:06 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <6.2.1.2.0.20050424210422.03d22990@64.7.153.2> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Sun, 24 Apr 2005 21:35:20 -0400 To: Kris Kennaway From: Mike Tancsa In-Reply-To: <20050425010242.GA44110@xor.obsecurity.org> References: <20050424175543.71041.qmail@web51805.mail.yahoo.com> <20050424151517.O68772@lexi.siliconlandmark.com> <3822.216.177.243.38.1114385370.localmail@webmail.dnswatch.com> <20050425000459.GA28667@xor.obsecurity.org> <6.2.1.2.0.20050424204611.072105a0@64.7.153.2> <20050425010242.GA44110@xor.obsecurity.org> 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 cc: freebsd-current@freebsd.org Subject: Re: FreeBSD 6 is coming too fast X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 25 Apr 2005 01:36:14 -0000 At 09:02 PM 24/04/2005, Kris Kennaway wrote: > > > > I also tried a CURRENT snapshot then and there wasn't much of a difference > > between it and RELENG_5. > >disk I/O or filesystem I/O? It would be interesting to benchmark the >latter since all the recent VFS work. This was on hardware using the 3ware driver which is essentially the same on RELENG_4 and RELENG_5. I also tested IDE performance which gave similar results (i.e. RELENG_4 and DragonFly was better), but the drivers are different so its hard to gage if thats a driver issue or not. I am not sure if any of those tests answers your question, as I am not sure how to answer it. I was looking for a way to measure overall throughput that samba, NFS, database and imap servers could do either on RELENG_4 or RELENG_5 as we start to migrate various servers from RELENG_4 to RELENG_5. I have a faster disk subsystem I can test against (Areca SATA RAID) that works on RELENG_4,RELENG_5 and HEAD and could re-run the tests varying just the base OS. If there is a particular test you feel best simulates disk performance, I am happy to test. ---Mike From owner-freebsd-current@FreeBSD.ORG Mon Apr 25 01:44: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 5B94716A4D1 for ; Mon, 25 Apr 2005 01:44:55 +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 E869A43D1F for ; Mon, 25 Apr 2005 01:44:54 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id C47E9514FE; Sun, 24 Apr 2005 18:44:53 -0700 (PDT) Date: Sun, 24 Apr 2005 18:44:53 -0700 From: Kris Kennaway To: Mike Tancsa Message-ID: <20050425014453.GA59981@xor.obsecurity.org> References: <20050424175543.71041.qmail@web51805.mail.yahoo.com> <20050424151517.O68772@lexi.siliconlandmark.com> <3822.216.177.243.38.1114385370.localmail@webmail.dnswatch.com> <20050425000459.GA28667@xor.obsecurity.org> <6.2.1.2.0.20050424204611.072105a0@64.7.153.2> <20050425010242.GA44110@xor.obsecurity.org> <6.2.1.2.0.20050424210422.03d22990@64.7.153.2> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="cNdxnHkX5QqsyA0e" Content-Disposition: inline In-Reply-To: <6.2.1.2.0.20050424210422.03d22990@64.7.153.2> User-Agent: Mutt/1.4.2.1i cc: freebsd-current@freebsd.org cc: Kris Kennaway Subject: Re: FreeBSD 6 is coming too fast X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: 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, 25 Apr 2005 01:44:56 -0000 --cNdxnHkX5QqsyA0e Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Apr 24, 2005 at 09:35:20PM -0400, Mike Tancsa wrote: > At 09:02 PM 24/04/2005, Kris Kennaway wrote: > >> > >> I also tried a CURRENT snapshot then and there wasn't much of a=20 > >difference > >> between it and RELENG_5. > > > >disk I/O or filesystem I/O? It would be interesting to benchmark the > >latter since all the recent VFS work. >=20 > This was on hardware using the 3ware driver which is essentially the same= =20 > on RELENG_4 and RELENG_5. This driver was recently updated, BTW. > I also tested IDE performance which gave similar=20 > results (i.e. RELENG_4 and DragonFly was better), but the drivers are=20 > different so its hard to gage if thats a driver issue or not. I am not= =20 > sure if any of those tests answers your question, as I am not sure how to= =20 > answer it. I was looking for a way to measure overall throughput that=20 > samba, NFS, database and imap servers could do either on RELENG_4 or=20 > RELENG_5 as we start to migrate various servers from RELENG_4 to RELENG_5. Measuring disk device performance (i.e. running a benchmark against the bare device) and filesystem performance (writing to a filesystem on the device) are very different things. > I have a faster disk subsystem I can test against (Areca SATA RAID) that= =20 > works on RELENG_4,RELENG_5 and HEAD and could re-run the tests varying ju= st=20 > the base OS. If there is a particular test you feel best simulates disk= =20 > performance, I am happy to test. As is well-known, doing meaningful (disk) benchmarks is hard, and it's easy to draw incorrect conclusions if you don't understand exactly what it is you're measuring. I'm not an expert in that, but it's been discussed on the lists before. Kris --cNdxnHkX5QqsyA0e Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFCbEuVWry0BWjoQKURAku7AKDlSZmf4EIS+7oCztFxh2FUpAwTEgCgqOWr jQ8gHSY0iEwqjkPJYtW2bDE= =+aK+ -----END PGP SIGNATURE----- --cNdxnHkX5QqsyA0e-- From owner-freebsd-current@FreeBSD.ORG Mon Apr 25 02:01: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 CAA8716A4CE for ; Mon, 25 Apr 2005 02:01:28 +0000 (GMT) Received: from lexi.siliconlandmark.com (lexi.siliconlandmark.com [209.69.98.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5050943D45 for ; Mon, 25 Apr 2005 02:01:28 +0000 (GMT) (envelope-from andy@siliconlandmark.com) Received: from lexi.siliconlandmark.com (localhost [127.0.0.1]) j3P21N9Z023809; Sun, 24 Apr 2005 22:01:23 -0400 (EDT) (envelope-from andy@siliconlandmark.com) Received: from localhost (andy@localhost)j3P21NqW023806; Sun, 24 Apr 2005 22:01:23 -0400 (EDT) (envelope-from andy@siliconlandmark.com) X-Authentication-Warning: lexi.siliconlandmark.com: andy owned process doing -bs Date: Sun, 24 Apr 2005 22:01:23 -0400 (EDT) From: Andre Guibert de Bruet To: Mike Tancsa In-Reply-To: <20050425014453.GA59981@xor.obsecurity.org> Message-ID: <20050424214939.B23468@lexi.siliconlandmark.com> References: <20050424175543.71041.qmail@web51805.mail.yahoo.com> <20050424151517.O68772@lexi.siliconlandmark.com> <3822.216.177.243.38.1114385370.localmail@webmail.dnswatch.com> <6.2.1.2.0.20050424204611.072105a0@64.7.153.2> <6.2.1.2.0.20050424210422.03d22990@64.7.153.2> <20050425014453.GA59981@xor.obsecurity.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.545, required 6, autolearn=not spam, AWL 0.05, BAYES_00 -2.60) X-MailScanner-From: andy@siliconlandmark.com cc: current@freebsd.org Subject: Re: FreeBSD 6 is coming too fast X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 25 Apr 2005 02:01:29 -0000 On Sun, 24 Apr 2005, Kris Kennaway wrote: > As is well-known, doing meaningful (disk) benchmarks is hard, and it's > easy to draw incorrect conclusions if you don't understand exactly > what it is you're measuring. I'm not an expert in that, but it's been > discussed on the lists before. This thread would not be complete without a reference to the most excellent posting made by phk and its follow-up by rwatson in January 2004: http://lists.freebsd.org/pipermail/freebsd-current/2004-January/019595.html Did this ever make it into the handbook? If so, anyone have a link? Cheers, Andy | Andre Guibert de Bruet | Enterprise Software Consultant > | Silicon Landmark, LLC. | http://siliconlandmark.com/ > From owner-freebsd-current@FreeBSD.ORG Mon Apr 25 02:35: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 8184316A4CE; Mon, 25 Apr 2005 02:35:13 +0000 (GMT) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id E112743D54; Mon, 25 Apr 2005 02:35:12 +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 j3P2ZC1b046288; Sun, 24 Apr 2005 22:35:12 -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 j3P2ZBrH056044; Sun, 24 Apr 2005 22:35:11 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 62DD07306E; Sun, 24 Apr 2005 22:35:11 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050425023511.62DD07306E@freebsd-current.sentex.ca> Date: Sun, 24 Apr 2005 22:35:11 -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: Mon, 25 Apr 2005 02:35:13 -0000 TB --- 2005-04-25 00:57:07 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-04-25 00:57:07 - starting CURRENT tinderbox run for i386/i386 TB --- 2005-04-25 00:57:07 - checking out the source tree TB --- 2005-04-25 00:57:07 - cd /home/tinderbox/CURRENT/i386/i386 TB --- 2005-04-25 00:57:07 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-04-25 01:03:42 - building world (CFLAGS=-O2 -pipe) TB --- 2005-04-25 01:03:42 - cd /home/tinderbox/CURRENT/i386/i386/src TB --- 2005-04-25 01:03:42 - /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-25 02:12:03 - building generic kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-04-25 02:12:03 - cd /home/tinderbox/CURRENT/i386/i386/src TB --- 2005-04-25 02:12:03 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Mon Apr 25 02:12: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 >>> Kernel build for GENERIC completed on Mon Apr 25 02:30:11 UTC 2005 TB --- 2005-04-25 02:30:11 - generating LINT kernel config TB --- 2005-04-25 02:30:11 - cd /home/tinderbox/CURRENT/i386/i386/src/sys/i386/conf TB --- 2005-04-25 02:30:11 - /usr/bin/make -B LINT TB --- 2005-04-25 02:30:11 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-04-25 02:30:11 - cd /home/tinderbox/CURRENT/i386/i386/src TB --- 2005-04-25 02:30:11 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Apr 25 02:30: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 [...] cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/CURRENT/i386/i386/src/sys -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/altq -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/pf -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/ngatm -I/tinderbox/CURRENT/i386/i386/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 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -ffreestanding -Werror -fi nstrument-functions -Wno-inline /tinderbox/CURRENT/i386/i386/src/sys/dev/acpi_support/acpi_asus.c In file included from /tinderbox/CURRENT/i386/i386/src/sys/dev/acpi_support/acpi_asus.c:51: /tinderbox/CURRENT/i386/i386/src/sys/dev/acpica/acpivar.h:425:1: "ACPI_MAX_THREADS" redefined In file included from /tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/acpica/acfreebsd.h:128, from /tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/acpica/acenv.h:208, from /tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/acpica/acpi.h:126, from /tinderbox/CURRENT/i386/i386/src/sys/dev/acpi_support/acpi_asus.c:50: ./opt_acpi.h:2:1: this is the location of the previous definition *** Error code 1 Stop in /tinderbox/CURRENT/i386/i386/obj/tinderbox/CURRENT/i386/i386/src/sys/LINT. *** Error code 1 Stop in /tinderbox/CURRENT/i386/i386/src. *** Error code 1 Stop in /tinderbox/CURRENT/i386/i386/src. TB --- 2005-04-25 02:35:11 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-04-25 02:35:11 - ERROR: failed to build lint kernel TB --- 2005-04-25 02:35:11 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Mon Apr 25 03:06: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 83FAC16A4CE for ; Mon, 25 Apr 2005 03:06:01 +0000 (GMT) Received: from avscan1.sentex.ca (avscan1.sentex.ca [199.212.134.11]) by mx1.FreeBSD.org (Postfix) with ESMTP id E361843D4C for ; Mon, 25 Apr 2005 03:06:00 +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 j3P35xSb096190; Sun, 24 Apr 2005 23:05:59 -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 95478-07; Sun, 24 Apr 2005 23:05:59 -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 j3P35xeX096183; Sun, 24 Apr 2005 23:05:59 -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 j3P35rax065549; Sun, 24 Apr 2005 23:05:53 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <6.2.1.2.0.20050424214757.02e56a18@64.7.153.2> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Sun, 24 Apr 2005 23:05:07 -0400 To: current@freebsd.org From: Mike Tancsa In-Reply-To: <20050425014453.GA59981@xor.obsecurity.org> References: <20050424175543.71041.qmail@web51805.mail.yahoo.com> <20050424151517.O68772@lexi.siliconlandmark.com> <3822.216.177.243.38.1114385370.localmail@webmail.dnswatch.com> <20050425000459.GA28667@xor.obsecurity.org> <6.2.1.2.0.20050424204611.072105a0@64.7.153.2> <20050425010242.GA44110@xor.obsecurity.org> <6.2.1.2.0.20050424210422.03d22990@64.7.153.2> <20050425014453.GA59981@xor.obsecurity.org> 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 cc: Kris Kennaway Subject: Re: FreeBSD 6 is coming too fast X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 25 Apr 2005 03:06:01 -0000 At 09:44 PM 24/04/2005, Kris Kennaway wrote: >This driver was recently updated, BTW. Are you sure you are not thinking of the twa driver ? The twe changes recently were some small bug fixes as far as I can tell. > > I have a faster disk subsystem I can test against (Areca SATA RAID) that > > works on RELENG_4,RELENG_5 and HEAD and could re-run the tests varying > just > > the base OS. If there is a particular test you feel best simulates disk > > performance, I am happy to test. > >As is well-known, doing meaningful (disk) benchmarks is hard, and it's >easy to draw incorrect conclusions if you don't understand exactly >what it is you're measuring. I'm not an expert in that, but it's been >discussed on the lists before. I know benchmarks are fraught with all sorts of caveats. However, I want to try and understand ahead of time if moving a certain application from RELENG_4 to RELENG_5 will work and not fail under real load. Ten to 15 or even 20% performance difference is not so great as the one time hits in buying a faster processor or faster disks or more RAM are inconsequential compared to greater stability or more useful features (e.g. filesystem ACLs, NSS). However, if the performance difference is greater than 50% than I need to know that ahead of time. An honest question, in the UP world, what have you found to be faster on RELENG_5 than RELENG_4 ? ---Mike From owner-freebsd-current@FreeBSD.ORG Mon Apr 25 03:59: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 5F1D716A4CE; Mon, 25 Apr 2005 03:59:28 +0000 (GMT) Received: from delight.idiom.com (delight.idiom.com [216.240.32.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0D54F43D55; Mon, 25 Apr 2005 03:59:28 +0000 (GMT) (envelope-from julian@elischer.org) Received: from idiom.com (idiom.com [216.240.32.1]) by delight.idiom.com (Postfix) with ESMTP id BAF591B6F2E; Sun, 24 Apr 2005 20:59:27 -0700 (PDT) Received: from [192.168.2.3] (home.elischer.org [216.240.48.38]) by idiom.com (8.12.11/8.12.11) with ESMTP id j3P3xQQC081458; Sun, 24 Apr 2005 20:59:26 -0700 (PDT) (envelope-from julian@elischer.org) Message-ID: <426C6B1D.3040704@elischer.org> Date: Sun, 24 Apr 2005 20:59:25 -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: current@freebsd.org References: <20050424175543.71041.qmail@web51805.mail.yahoo.com> <20050424151517.O68772@lexi.siliconlandmark.com> <3822.216.177.243.38.1114385370.localmail@webmail.dnswatch.com> <20050425000459.GA28667@xor.obsecurity.org> <6.2.1.2.0.20050424204611.072105a0@64.7.153.2> <20050425010242.GA44110@xor.obsecurity.org> <6.2.1.2.0.20050424210422.03d22990@64.7.153.2> <20050425014453.GA59981@xor.obsecurity.org> In-Reply-To: <20050425014453.GA59981@xor.obsecurity.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: Kris Kennaway cc: freebsd-current@freebsd.org cc: Mike Tancsa Subject: Re: FreeBSD 6 is coming too fast X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 25 Apr 2005 03:59:28 -0000 Kris Kennaway wrote: > Measuring disk device performance (i.e. running a benchmark against > the bare device) and filesystem performance (writing to a filesystem > on the device) are very different things. I wish people would stop trying to deny that we have serious work in front of us to get the VFS and disk IO figures back to where they were before. there ARE slowdowns and I have seen it both with tests on teh basic hardware and throug the filesystems. I don't know why this surproses people because we have still a lot of work to do in teh interrupt latency field for example, and I doubt that even PHK would say that there is no work left to do in geom. Where we are now is closing in on "feature complete". Now we need to profile and optimise. From owner-freebsd-current@FreeBSD.ORG Mon Apr 25 03:59: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 5F1D716A4CE; Mon, 25 Apr 2005 03:59:28 +0000 (GMT) Received: from delight.idiom.com (delight.idiom.com [216.240.32.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0D54F43D55; Mon, 25 Apr 2005 03:59:28 +0000 (GMT) (envelope-from julian@elischer.org) Received: from idiom.com (idiom.com [216.240.32.1]) by delight.idiom.com (Postfix) with ESMTP id BAF591B6F2E; Sun, 24 Apr 2005 20:59:27 -0700 (PDT) Received: from [192.168.2.3] (home.elischer.org [216.240.48.38]) by idiom.com (8.12.11/8.12.11) with ESMTP id j3P3xQQC081458; Sun, 24 Apr 2005 20:59:26 -0700 (PDT) (envelope-from julian@elischer.org) Message-ID: <426C6B1D.3040704@elischer.org> Date: Sun, 24 Apr 2005 20:59:25 -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: current@freebsd.org References: <20050424175543.71041.qmail@web51805.mail.yahoo.com> <20050424151517.O68772@lexi.siliconlandmark.com> <3822.216.177.243.38.1114385370.localmail@webmail.dnswatch.com> <20050425000459.GA28667@xor.obsecurity.org> <6.2.1.2.0.20050424204611.072105a0@64.7.153.2> <20050425010242.GA44110@xor.obsecurity.org> <6.2.1.2.0.20050424210422.03d22990@64.7.153.2> <20050425014453.GA59981@xor.obsecurity.org> In-Reply-To: <20050425014453.GA59981@xor.obsecurity.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: Kris Kennaway cc: freebsd-current@freebsd.org cc: Mike Tancsa Subject: Re: FreeBSD 6 is coming too fast X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 25 Apr 2005 03:59:28 -0000 Kris Kennaway wrote: > Measuring disk device performance (i.e. running a benchmark against > the bare device) and filesystem performance (writing to a filesystem > on the device) are very different things. I wish people would stop trying to deny that we have serious work in front of us to get the VFS and disk IO figures back to where they were before. there ARE slowdowns and I have seen it both with tests on teh basic hardware and throug the filesystems. I don't know why this surproses people because we have still a lot of work to do in teh interrupt latency field for example, and I doubt that even PHK would say that there is no work left to do in geom. Where we are now is closing in on "feature complete". Now we need to profile and optimise. From owner-freebsd-current@FreeBSD.ORG Mon Apr 25 04: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 60F8416A4CE; Mon, 25 Apr 2005 04:20:26 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 92E7343D4C; Mon, 25 Apr 2005 04:20:25 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.19] (ibook-nai.samsco.home [192.168.254.19]) (authenticated bits=0) by pooker.samsco.org (8.13.3/8.13.3) with ESMTP id j3P4PAJ7001335; Sun, 24 Apr 2005 22:25:10 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <426C7004.8020003@samsco.org> Date: Sun, 24 Apr 2005 22:20:20 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.5) Gecko/20041217 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Julian Elischer References: <20050424175543.71041.qmail@web51805.mail.yahoo.com> <20050424151517.O68772@lexi.siliconlandmark.com> <3822.216.177.243.38.1114385370.localmail@webmail.dnswatch.com> <20050425000459.GA28667@xor.obsecurity.org> <6.2.1.2.0.20050424204611.072105a0@64.7.153.2> <20050425010242.GA44110@xor.obsecurity.org> <6.2.1.2.0.20050424210422.03d22990@64.7.153.2> <20050425014453.GA59981@xor.obsecurity.org> <426C6B1D.3040704@elischer.org> In-Reply-To: <426C6B1D.3040704@elischer.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: Mike Tancsa cc: freebsd-current@freebsd.org cc: current@freebsd.org cc: Kris Kennaway Subject: I/O Benchmarking [Re: FreeBSD 6 is coming too fast] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 25 Apr 2005 04:20:26 -0000 Julian Elischer wrote: > Kris Kennaway wrote: > >> Measuring disk device performance (i.e. running a benchmark against >> the bare device) and filesystem performance (writing to a filesystem >> on the device) are very different things. > > > I wish people would stop trying to deny that we have serious work in > front of us to get the VFS and disk IO figures back to where they were > before. > > there ARE slowdowns and I have seen it both with tests on teh basic > hardware and throug the filesystems. I don't know why this surproses > people because we have still a lot of work to do in teh interrupt > latency field for example, and I doubt that even PHK would say that > there is no work left to do in geom. > Where we are now is closing in on "feature complete". Now we need to > profile and optimise. You are absolutely right. However, Kris is also absolutely right that I/O is hard to profile. These two statements are not mutually exclusive. What I don't want is for people to run around quoting how fast bonnie benchmarks their memory controller, that does nothing to characterize the memory subsystem. Here is what I want to see happen: Step 1: Get the easy crap out of the way Step 1a: Figure out a reliable way to measure sequential read/write performance of just the driver and the hardware. Prove that no needless copy operations are going on. Step 1b: Measure sequential read/write through the buffer cache. Prove that no needless copy operations are going on. Step 1c: Measure sequential read/write through the syscall layer. Prove that no needless copy operations are going on. The only thing that should affect sequential speed is the speed of the hardware, buses, and memory controller. If anything in the OS is standing in the way, we need to weed it out. Then we need to forget about sequential performance; that's the real of unscrupulous IDE marketeers and linnex kiddies. I don't really care how fast we can copy 20 bazillion terabytes of 0's, I want to know how many transactions per second our databases can do, how scalable our mail servers are, etc. None of that has anything to do with sequential I/O performance. Step 2: Do the real work Step 2a: Measure transaction latency and thoroughput through the driver and hardware. Profile lock contention. Measure interrupt latency. Step 2b: Measure VFS latency in both specfs and ufs. Profile lock contention and usage. Compare contention against the driver. Step 2c: Profile the buffer cache. Are pages being cached effectively? Are they being cleaned efficiently? Can we fix the "lemming syncer"? Measure lock contention. I imagine that this is where the real work is. And lots of it. Step 3: Beat the benchmarks Step 3a: Figure out what is being tested and how. How do the data sources and sinks work? Are other OS's beating the benchmarks by cheating here? Can we create our own high-speed sources and sinks? Step 3b: ??? This is important even if it does sound slimy. We could have a real kick-ass I/O subsystem, but be beaten by a linux rig that fools the benchmarks. Kinda like how Intel has benchmarks that show that their Pentium4 line is the fastest thing on the planet, when in reality it's just smoke and mirrors. Gotta win the PR race, here. Scott From owner-freebsd-current@FreeBSD.ORG Mon Apr 25 04: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 60F8416A4CE; Mon, 25 Apr 2005 04:20:26 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 92E7343D4C; Mon, 25 Apr 2005 04:20:25 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.19] (ibook-nai.samsco.home [192.168.254.19]) (authenticated bits=0) by pooker.samsco.org (8.13.3/8.13.3) with ESMTP id j3P4PAJ7001335; Sun, 24 Apr 2005 22:25:10 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <426C7004.8020003@samsco.org> Date: Sun, 24 Apr 2005 22:20:20 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.5) Gecko/20041217 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Julian Elischer References: <20050424175543.71041.qmail@web51805.mail.yahoo.com> <20050424151517.O68772@lexi.siliconlandmark.com> <3822.216.177.243.38.1114385370.localmail@webmail.dnswatch.com> <20050425000459.GA28667@xor.obsecurity.org> <6.2.1.2.0.20050424204611.072105a0@64.7.153.2> <20050425010242.GA44110@xor.obsecurity.org> <6.2.1.2.0.20050424210422.03d22990@64.7.153.2> <20050425014453.GA59981@xor.obsecurity.org> <426C6B1D.3040704@elischer.org> In-Reply-To: <426C6B1D.3040704@elischer.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: Mike Tancsa cc: freebsd-current@freebsd.org cc: current@freebsd.org cc: Kris Kennaway Subject: I/O Benchmarking [Re: FreeBSD 6 is coming too fast] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 25 Apr 2005 04:20:26 -0000 Julian Elischer wrote: > Kris Kennaway wrote: > >> Measuring disk device performance (i.e. running a benchmark against >> the bare device) and filesystem performance (writing to a filesystem >> on the device) are very different things. > > > I wish people would stop trying to deny that we have serious work in > front of us to get the VFS and disk IO figures back to where they were > before. > > there ARE slowdowns and I have seen it both with tests on teh basic > hardware and throug the filesystems. I don't know why this surproses > people because we have still a lot of work to do in teh interrupt > latency field for example, and I doubt that even PHK would say that > there is no work left to do in geom. > Where we are now is closing in on "feature complete". Now we need to > profile and optimise. You are absolutely right. However, Kris is also absolutely right that I/O is hard to profile. These two statements are not mutually exclusive. What I don't want is for people to run around quoting how fast bonnie benchmarks their memory controller, that does nothing to characterize the memory subsystem. Here is what I want to see happen: Step 1: Get the easy crap out of the way Step 1a: Figure out a reliable way to measure sequential read/write performance of just the driver and the hardware. Prove that no needless copy operations are going on. Step 1b: Measure sequential read/write through the buffer cache. Prove that no needless copy operations are going on. Step 1c: Measure sequential read/write through the syscall layer. Prove that no needless copy operations are going on. The only thing that should affect sequential speed is the speed of the hardware, buses, and memory controller. If anything in the OS is standing in the way, we need to weed it out. Then we need to forget about sequential performance; that's the real of unscrupulous IDE marketeers and linnex kiddies. I don't really care how fast we can copy 20 bazillion terabytes of 0's, I want to know how many transactions per second our databases can do, how scalable our mail servers are, etc. None of that has anything to do with sequential I/O performance. Step 2: Do the real work Step 2a: Measure transaction latency and thoroughput through the driver and hardware. Profile lock contention. Measure interrupt latency. Step 2b: Measure VFS latency in both specfs and ufs. Profile lock contention and usage. Compare contention against the driver. Step 2c: Profile the buffer cache. Are pages being cached effectively? Are they being cleaned efficiently? Can we fix the "lemming syncer"? Measure lock contention. I imagine that this is where the real work is. And lots of it. Step 3: Beat the benchmarks Step 3a: Figure out what is being tested and how. How do the data sources and sinks work? Are other OS's beating the benchmarks by cheating here? Can we create our own high-speed sources and sinks? Step 3b: ??? This is important even if it does sound slimy. We could have a real kick-ass I/O subsystem, but be beaten by a linux rig that fools the benchmarks. Kinda like how Intel has benchmarks that show that their Pentium4 line is the fastest thing on the planet, when in reality it's just smoke and mirrors. Gotta win the PR race, here. Scott From owner-freebsd-current@FreeBSD.ORG Mon Apr 25 06:15: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 2751E16A4CE; Mon, 25 Apr 2005 06:15:01 +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 CFB5E43D31; Mon, 25 Apr 2005 06:15:00 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 8F2FE51C02; Sun, 24 Apr 2005 23:14:59 -0700 (PDT) Date: Sun, 24 Apr 2005 23:14:59 -0700 From: Kris Kennaway To: Julian Elischer Message-ID: <20050425061459.GA33247@xor.obsecurity.org> References: <20050424175543.71041.qmail@web51805.mail.yahoo.com> <20050424151517.O68772@lexi.siliconlandmark.com> <3822.216.177.243.38.1114385370.localmail@webmail.dnswatch.com> <20050425000459.GA28667@xor.obsecurity.org> <6.2.1.2.0.20050424204611.072105a0@64.7.153.2> <20050425010242.GA44110@xor.obsecurity.org> <6.2.1.2.0.20050424210422.03d22990@64.7.153.2> <20050425014453.GA59981@xor.obsecurity.org> <426C6B1D.3040704@elischer.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="2oS5YaxWCcQjTEyO" Content-Disposition: inline In-Reply-To: <426C6B1D.3040704@elischer.org> User-Agent: Mutt/1.4.2.1i cc: Mike Tancsa cc: freebsd-current@freebsd.org cc: current@freebsd.org cc: Kris Kennaway Subject: Re: FreeBSD 6 is coming too fast X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 25 Apr 2005 06:15:01 -0000 --2oS5YaxWCcQjTEyO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Apr 24, 2005 at 08:59:25PM -0700, Julian Elischer wrote: > Kris Kennaway wrote: >=20 > >Measuring disk device performance (i.e. running a benchmark against > >the bare device) and filesystem performance (writing to a filesystem > >on the device) are very different things. >=20 > I wish people would stop trying to deny that we have serious work in fron= t=20 > of us to get the VFS and disk IO figures back to where they were before. >=20 > there ARE slowdowns and I have seen it both with tests on teh basic=20 > hardware and throug the filesystems. I don't know why this surproses=20 > people because we have still a lot of work to do in teh interrupt latency= =20 > field for example, and I doubt that even PHK would say that there is no= =20 > work left to do in geom. > Where we are now is closing in on "feature complete". Now we need to=20 > profile and optimise. OK, but note that I didn't deny anything, I only questioned whether the OP was observing a real problem (he didn't mention disk I/O, or in fact any specific claim) or whether it was a coloured perception based on the (incorrect) assumption that gcc compilation speed was measuring a performance loss in FreeBSD. Kris --2oS5YaxWCcQjTEyO Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFCbIrjWry0BWjoQKURAixoAKDz6DJfBTaaJLHHjbM4b91epqu1JQCggy+w c1zDPPELT9ZZUHZGrLq5wwo= =1XB2 -----END PGP SIGNATURE----- --2oS5YaxWCcQjTEyO-- From owner-freebsd-current@FreeBSD.ORG Mon Apr 25 06:15: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 2751E16A4CE; Mon, 25 Apr 2005 06:15:01 +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 CFB5E43D31; Mon, 25 Apr 2005 06:15:00 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 8F2FE51C02; Sun, 24 Apr 2005 23:14:59 -0700 (PDT) Date: Sun, 24 Apr 2005 23:14:59 -0700 From: Kris Kennaway To: Julian Elischer Message-ID: <20050425061459.GA33247@xor.obsecurity.org> References: <20050424175543.71041.qmail@web51805.mail.yahoo.com> <20050424151517.O68772@lexi.siliconlandmark.com> <3822.216.177.243.38.1114385370.localmail@webmail.dnswatch.com> <20050425000459.GA28667@xor.obsecurity.org> <6.2.1.2.0.20050424204611.072105a0@64.7.153.2> <20050425010242.GA44110@xor.obsecurity.org> <6.2.1.2.0.20050424210422.03d22990@64.7.153.2> <20050425014453.GA59981@xor.obsecurity.org> <426C6B1D.3040704@elischer.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="2oS5YaxWCcQjTEyO" Content-Disposition: inline In-Reply-To: <426C6B1D.3040704@elischer.org> User-Agent: Mutt/1.4.2.1i cc: Mike Tancsa cc: freebsd-current@freebsd.org cc: current@freebsd.org cc: Kris Kennaway Subject: Re: FreeBSD 6 is coming too fast X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 25 Apr 2005 06:15:01 -0000 --2oS5YaxWCcQjTEyO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Apr 24, 2005 at 08:59:25PM -0700, Julian Elischer wrote: > Kris Kennaway wrote: >=20 > >Measuring disk device performance (i.e. running a benchmark against > >the bare device) and filesystem performance (writing to a filesystem > >on the device) are very different things. >=20 > I wish people would stop trying to deny that we have serious work in fron= t=20 > of us to get the VFS and disk IO figures back to where they were before. >=20 > there ARE slowdowns and I have seen it both with tests on teh basic=20 > hardware and throug the filesystems. I don't know why this surproses=20 > people because we have still a lot of work to do in teh interrupt latency= =20 > field for example, and I doubt that even PHK would say that there is no= =20 > work left to do in geom. > Where we are now is closing in on "feature complete". Now we need to=20 > profile and optimise. OK, but note that I didn't deny anything, I only questioned whether the OP was observing a real problem (he didn't mention disk I/O, or in fact any specific claim) or whether it was a coloured perception based on the (incorrect) assumption that gcc compilation speed was measuring a performance loss in FreeBSD. Kris --2oS5YaxWCcQjTEyO Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFCbIrjWry0BWjoQKURAixoAKDz6DJfBTaaJLHHjbM4b91epqu1JQCggy+w c1zDPPELT9ZZUHZGrLq5wwo= =1XB2 -----END PGP SIGNATURE----- --2oS5YaxWCcQjTEyO-- From owner-freebsd-current@FreeBSD.ORG Mon Apr 25 06:21: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 9E13B16A4CE; Mon, 25 Apr 2005 06:21:12 +0000 (GMT) Received: from voodoo.oberon.net (voodoo.oberon.net [212.118.165.100]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4FA2143D1F; Mon, 25 Apr 2005 06:21:12 +0000 (GMT) (envelope-from krion@voodoo.oberon.net) Received: from krion by voodoo.oberon.net with local (Exim 4.50 (FreeBSD)) id 1DPwxu-000PqG-NB; Mon, 25 Apr 2005 08:21:06 +0200 Date: Mon, 25 Apr 2005 08:21:06 +0200 From: Kirill Ponomarew To: Kris Kennaway Message-ID: <20050425062106.GB91852@voodoo.oberon.net> References: <20050424175543.71041.qmail@web51805.mail.yahoo.com> <20050424151517.O68772@lexi.siliconlandmark.com> <3822.216.177.243.38.1114385370.localmail@webmail.dnswatch.com> <20050425000459.GA28667@xor.obsecurity.org> <6.2.1.2.0.20050424204611.072105a0@64.7.153.2> <20050425010242.GA44110@xor.obsecurity.org> <6.2.1.2.0.20050424210422.03d22990@64.7.153.2> <20050425014453.GA59981@xor.obsecurity.org> <426C6B1D.3040704@elischer.org> <20050425061459.GA33247@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050425061459.GA33247@xor.obsecurity.org> X-NCC-Regid: de.oberon X-NIC-HDL: KP869-RIPE Keywords: 579279786 cc: current@freebsd.org cc: freebsd-current@freebsd.org cc: Julian Elischer cc: Mike Tancsa Subject: Re: FreeBSD 6 is coming too fast X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 25 Apr 2005 06:21:12 -0000 On Sun, Apr 24, 2005 at 11:14:59PM -0700, Kris Kennaway wrote: > > >Measuring disk device performance (i.e. running a benchmark against > > >the bare device) and filesystem performance (writing to a filesystem > > >on the device) are very different things. > > > > I wish people would stop trying to deny that we have serious work in front > > of us to get the VFS and disk IO figures back to where they were before. > > > > there ARE slowdowns and I have seen it both with tests on teh basic > > hardware and throug the filesystems. I don't know why this surproses > > people because we have still a lot of work to do in teh interrupt latency > > field for example, and I doubt that even PHK would say that there is no > > work left to do in geom. > > Where we are now is closing in on "feature complete". Now we need to > > profile and optimise. > > OK, but note that I didn't deny anything, I only questioned whether > the OP was observing a real problem (he didn't mention disk I/O, or in > fact any specific claim) or whether it was a coloured perception based > on the (incorrect) assumption that gcc compilation speed was measuring > a performance loss in FreeBSD. According to gcc-4.0 release notes, compilation speed for C++ was dramatically increased, up to 25% IIRC. I think 4.0 is good candidate for merging into HEAD. -Kirill From owner-freebsd-current@FreeBSD.ORG Mon Apr 25 06:21: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 9E13B16A4CE; Mon, 25 Apr 2005 06:21:12 +0000 (GMT) Received: from voodoo.oberon.net (voodoo.oberon.net [212.118.165.100]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4FA2143D1F; Mon, 25 Apr 2005 06:21:12 +0000 (GMT) (envelope-from krion@voodoo.oberon.net) Received: from krion by voodoo.oberon.net with local (Exim 4.50 (FreeBSD)) id 1DPwxu-000PqG-NB; Mon, 25 Apr 2005 08:21:06 +0200 Date: Mon, 25 Apr 2005 08:21:06 +0200 From: Kirill Ponomarew To: Kris Kennaway Message-ID: <20050425062106.GB91852@voodoo.oberon.net> References: <20050424175543.71041.qmail@web51805.mail.yahoo.com> <20050424151517.O68772@lexi.siliconlandmark.com> <3822.216.177.243.38.1114385370.localmail@webmail.dnswatch.com> <20050425000459.GA28667@xor.obsecurity.org> <6.2.1.2.0.20050424204611.072105a0@64.7.153.2> <20050425010242.GA44110@xor.obsecurity.org> <6.2.1.2.0.20050424210422.03d22990@64.7.153.2> <20050425014453.GA59981@xor.obsecurity.org> <426C6B1D.3040704@elischer.org> <20050425061459.GA33247@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050425061459.GA33247@xor.obsecurity.org> X-NCC-Regid: de.oberon X-NIC-HDL: KP869-RIPE Keywords: 579279786 cc: current@freebsd.org cc: freebsd-current@freebsd.org cc: Julian Elischer cc: Mike Tancsa Subject: Re: FreeBSD 6 is coming too fast X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 25 Apr 2005 06:21:12 -0000 On Sun, Apr 24, 2005 at 11:14:59PM -0700, Kris Kennaway wrote: > > >Measuring disk device performance (i.e. running a benchmark against > > >the bare device) and filesystem performance (writing to a filesystem > > >on the device) are very different things. > > > > I wish people would stop trying to deny that we have serious work in front > > of us to get the VFS and disk IO figures back to where they were before. > > > > there ARE slowdowns and I have seen it both with tests on teh basic > > hardware and throug the filesystems. I don't know why this surproses > > people because we have still a lot of work to do in teh interrupt latency > > field for example, and I doubt that even PHK would say that there is no > > work left to do in geom. > > Where we are now is closing in on "feature complete". Now we need to > > profile and optimise. > > OK, but note that I didn't deny anything, I only questioned whether > the OP was observing a real problem (he didn't mention disk I/O, or in > fact any specific claim) or whether it was a coloured perception based > on the (incorrect) assumption that gcc compilation speed was measuring > a performance loss in FreeBSD. According to gcc-4.0 release notes, compilation speed for C++ was dramatically increased, up to 25% IIRC. I think 4.0 is good candidate for merging into HEAD. -Kirill From owner-freebsd-current@FreeBSD.ORG Mon Apr 25 06:52: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 CF9DA16A4CE for ; Mon, 25 Apr 2005 06:52:35 +0000 (GMT) Received: from ylpvm15.prodigy.net (ylpvm15-ext.prodigy.net [207.115.57.46]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7440243D4C for ; Mon, 25 Apr 2005 06:52:35 +0000 (GMT) (envelope-from nate@root.org) Received: from pimout7-ext.prodigy.net (pimout7-ext.prodigy.net [207.115.63.58])j3P6mgNA019732 for ; Mon, 25 Apr 2005 02:48:43 -0400 X-ORBL: [64.171.185.67] Received: from [10.0.5.51] (adsl-64-171-185-67.dsl.snfc21.pacbell.net [64.171.185.67])j3P6qTlo102076; Mon, 25 Apr 2005 02:52:33 -0400 Message-ID: <426C93AC.3030907@root.org> Date: Sun, 24 Apr 2005 23:52:28 -0700 From: Nate Lawson User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050416) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andre Guibert de Bruet References: <4267A1CF.3080903@uq.edu.au> <20050422190208.M68772@lexi.siliconlandmark.com> <20050423020305.I68772@lexi.siliconlandmark.com> <426A20E5.5020604@uq.edu.au> <20050423152223.Q68772@lexi.siliconlandmark.com> <426B06F5.3030506@uq.edu.au> <20050423224317.D68772@lexi.siliconlandmark.com> In-Reply-To: <20050423224317.D68772@lexi.siliconlandmark.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: Matthew Sullivan cc: freebsd-current@freebsd.org Subject: Re: SMP on Compaq DL380 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 25 Apr 2005 06:52:35 -0000 Andre Guibert de Bruet wrote: > > On Sun, 24 Apr 2005, Matthew Sullivan wrote: > >> Andre Guibert de Bruet wrote: >> >>> Processors: APIC ID Version State Family Model Step >>> Flags >>> 0 0x10 BSP, usable 6 2 1 0x0381 >>> 0 0x10 AP, usable 6 8 6 >>> 0x383fbff >>> >>> The APIC IDs here are the same. The flags on the would-be AP are what >>> I would expect for a recent i686. The BSP barely qualify it to be a >>> gen-1 Pentium. I wouldn't trust any of the values being reported. >>> Could you obtain the real identity of these CPUs and confirm that >>> they're not mismatched? The easy way of doing this if your BIOS >>> doesn't post this information is using a Knoppix LiveCD and doing a >>> cat /proc/cpuinfo. >> >> >> Ok can't do the knoppix thing atm, however... >> >> CPU0 -> 866/256/133/1.65v SL47S >> CPU1 -> 866/256/133/1.70v SL48V >> >> Both are shown detected by the BIOS, and both are shown as 866MHz >> 133MHz busses, and 256k cache (as one would expect) >> >>> If both CPUs are reporting the same ID, I can see how we're not >>> launching the second proc; We assume that ID 0 is the BSP and >>> additional processors have different APIC IDs. Is something really >>> borked here? Yep! >> >> >> But the acpidump -t shows 2 different ID's.... > > > I don't know the way our ACPI implementation handles the information > found in the tables well enough to be able to tell you exactly what we > do with the IDs that are found in that dump. That's Nate Lawson's domain > (I added him to the CC-list). I'd like to see the acpidump -t -d > matthew.asl There definitely is a problem when you have identical APIC ids. We already blacklist one version of this BIOS. -- Nate From owner-freebsd-current@FreeBSD.ORG Mon Apr 25 06: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 2B2E516A4CE for ; Mon, 25 Apr 2005 06:53:49 +0000 (GMT) Received: from ylpvm15.prodigy.net (ylpvm15-ext.prodigy.net [207.115.57.46]) by mx1.FreeBSD.org (Postfix) with ESMTP id CB35643D54 for ; Mon, 25 Apr 2005 06:53:48 +0000 (GMT) (envelope-from nate@root.org) Received: from pimout7-ext.prodigy.net (pimout7-ext.prodigy.net [207.115.63.58])j3P6nuNA020691 for ; Mon, 25 Apr 2005 02:49:56 -0400 X-ORBL: [64.171.185.67] Received: from [10.0.5.51] (adsl-64-171-185-67.dsl.snfc21.pacbell.net [64.171.185.67])j3P6rllo150364 for ; Mon, 25 Apr 2005 02:53:48 -0400 Message-ID: <426C93FB.1030908@root.org> Date: Sun, 24 Apr 2005 23:53:47 -0700 From: Nate Lawson User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050416) X-Accept-Language: en-us, en MIME-Version: 1.0 To: FreeBSD Current Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Fwd: cvs commit: src/sys/i386/conf NOTES] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 25 Apr 2005 06:53:49 -0000 Apologies for breaking the tinderbox. I'll MFC this as soon as it's ok. -------- Original Message -------- Subject: cvs commit: src/sys/i386/conf NOTES Date: Mon, 25 Apr 2005 06:24:24 +0000 (GMT) From: Nate Lawson To: njl@FreeBSD.ORG njl 2005-04-25 06:24:20 UTC FreeBSD src repository Modified files: sys/i386/conf NOTES Log: Remove obsolete option. MFC after: 1 day Revision Changes Path 1.1197 +0 -3 src/sys/i386/conf/NOTES Index: src/sys/i386/conf/NOTES diff -u src/sys/i386/conf/NOTES:1.1196 src/sys/i386/conf/NOTES:1.1197 --- src/sys/i386/conf/NOTES:1.1196 Wed Apr 20 22:19:51 2005 +++ src/sys/i386/conf/NOTES Mon Apr 25 06:24:19 2005 @@ -414,8 +414,6 @@ # Intel ACPICA code. (Note that the Intel code must also have USE_DEBUGGER # defined when it is built). # -# ACPI_MAX_THREADS sets the number of task threads started. -# # ACPI_NO_SEMAPHORES makes the AcpiOs*Semaphore routines a no-op. # # ACPICA_PEDANTIC enables strict checking of AML. Our default is to @@ -427,7 +425,6 @@ device acpi options ACPI_DEBUG -options ACPI_MAX_THREADS=1 #!options ACPI_NO_SEMAPHORES #!options ACPICA_PEDANTIC -- Nate From owner-freebsd-current@FreeBSD.ORG Mon Apr 25 08: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 D202B16A4CE for ; Mon, 25 Apr 2005 08:19:29 +0000 (GMT) Received: from mailhost.stack.nl (vaak.stack.nl [131.155.140.140]) by mx1.FreeBSD.org (Postfix) with ESMTP id E92E443D2D for ; Mon, 25 Apr 2005 08:19:28 +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 059CF1F09C; Mon, 25 Apr 2005 10:19:28 +0200 (CEST) Received: by hammer.stack.nl (Postfix, from userid 333) id DE878618D; Mon, 25 Apr 2005 10:19:27 +0200 (CEST) Date: Mon, 25 Apr 2005 10:19:27 +0200 From: Marc Olzheim To: Andre Guibert de Bruet Message-ID: <20050425081927.GA56859@stack.nl> References: <52997.83.226.116.53.1114121015.squirrel@webmail.chalmers.se> <20050421220902.GA2960@odin.ac.hmc.edu> <20050423024259.B68772@lexi.siliconlandmark.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="TB36FDmn/VVEgNH/" Content-Disposition: inline In-Reply-To: <20050423024259.B68772@lexi.siliconlandmark.com> 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: freebsd-current@freebsd.org cc: Niklas Sorensson Subject: Re: Debug options X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 25 Apr 2005 08:19:30 -0000 --TB36FDmn/VVEgNH/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Sat, Apr 23, 2005 at 02:44:53AM -0400, Andre Guibert de Bruet wrote: > May I also suggest tuning(7)? As in: may you suggest someone put this in tuning(7) ? Or what part of tuning(7) are you referring to ? No use pointing to manpages if the info isn't there. :-/ Marc --TB36FDmn/VVEgNH/ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFCbKgPezjnobFOgrERAoIuAKDLCPchbR86Uw6Rwur6dr3FJxnP5QCeIhGP a90RhMLk7qQs90XnshdyRpo= =85Lg -----END PGP SIGNATURE----- --TB36FDmn/VVEgNH/-- From owner-freebsd-current@FreeBSD.ORG Mon Apr 25 08:22: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 7506816A4CE for ; Mon, 25 Apr 2005 08:22:12 +0000 (GMT) Received: from mailhost.stack.nl (vaak.stack.nl [131.155.140.140]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3412343D54 for ; Mon, 25 Apr 2005 08:22: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 850541F251; Mon, 25 Apr 2005 10:22:11 +0200 (CEST) Received: by hammer.stack.nl (Postfix, from userid 333) id 6B82C618D; Mon, 25 Apr 2005 10:22:11 +0200 (CEST) Date: Mon, 25 Apr 2005 10:22:11 +0200 From: Marc Olzheim To: Danny Braniss Message-ID: <20050425082211.GB56859@stack.nl> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="oC1+HKm2/end4ao3" Content-Disposition: inline In-Reply-To: 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: freebsd-current@freebsd.org Subject: Re: serial console 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: Mon, 25 Apr 2005 08:22:12 -0000 --oC1+HKm2/end4ao3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Sat, Apr 23, 2005 at 03:16:36PM +0300, Danny Braniss wrote: > the receiver part of the serial console seems to be somewhat problematic, > i have to type almost every character more than once to be acccepted, making > debugging with kgdb impossible. BTW, 5.4 works fine, so it's not a hardware > problem, nor parity/speed/start-stop bits. And you are sure that no process is running on /dev/console with wchan 'ttyin' ? Marc --oC1+HKm2/end4ao3 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFCbKizezjnobFOgrERAq3BAJ4sFjAQmhRg6jaTDwZwk+uzqimCcQCgh7Wh mQtXqVAzQzy1ncl96im/sm0= =CD0Q -----END PGP SIGNATURE----- --oC1+HKm2/end4ao3-- From owner-freebsd-current@FreeBSD.ORG Mon Apr 25 08:36: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 1736116A4CE for ; Mon, 25 Apr 2005 08:36:56 +0000 (GMT) Received: from mail.sorbs.net (mail.sorbs.net [203.15.51.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8C21943D54 for ; Mon, 25 Apr 2005 08:36:55 +0000 (GMT) (envelope-from matthew@uq.edu.au) Received: from [10.200.254.98] by nemesis.sorbs.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0IFH00402UM4FB@nemesis.sorbs.net> for freebsd-current@freebsd.org; Mon, 25 Apr 2005 18:37:17 +1000 (EST) Date: Mon, 25 Apr 2005 18:35:35 +1000 From: Matthew Sullivan In-reply-to: <426C93AC.3030907@root.org> To: Nate Lawson Message-id: <426CABD7.8010201@uq.edu.au> MIME-version: 1.0 Content-type: multipart/signed; boundary=------------ms050206080600040809020101; micalg=sha1; protocol="application/x-pkcs7-signature" X-Accept-Language: en User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041231 References: <4267A1CF.3080903@uq.edu.au> <20050422190208.M68772@lexi.siliconlandmark.com> <20050423020305.I68772@lexi.siliconlandmark.com> <426A20E5.5020604@uq.edu.au> <20050423152223.Q68772@lexi.siliconlandmark.com> <426B06F5.3030506@uq.edu.au> <20050423224317.D68772@lexi.siliconlandmark.com> <426C93AC.3030907@root.org> cc: freebsd-current@freebsd.org Subject: Re: SMP on Compaq DL380 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 25 Apr 2005 08:36:56 -0000 This is a cryptographically signed message in MIME format. --------------ms050206080600040809020101 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Nate Lawson wrote: > > I'd like to see the acpidump -t -d > matthew.asl http://scorpion.sorbs.net/matthew.asl > > There definitely is a problem when you have identical APIC ids. We > already blacklist one version of this BIOS. > That's not something I wanted to here right now... :-( Regards, -- Matthew Sullivan Specialist Systems Programmer Information Technology Services The University of Queensland --------------ms050206080600040809020101 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIG7DCC A3IwggJaoAMCAQICASowDQYJKoZIhvcNAQEEBQAwgaMxCzAJBgNVBAYTAkFVMRMwEQYDVQQI EwpRdWVlbnNsYW5kMREwDwYDVQQHEwhCcmlzYmFuZTElMCMGA1UEChMcVGhlIFVuaXZlcnNp dHkgb2YgUXVlZW5zbGFuZDEoMCYGA1UECxMfSW5mb3JtYXRpb24gVGVjaG5vbG9neSBTZXJ2 aWNlczEbMBkGA1UEAxMSQ2VydGlmaWNhdGUgU2VydmVyMB4XDTA0MDEyMTIzMzYyMVoXDTA2 MDEyMTIzMzYyMVowgbIxCzAJBgNVBAYTAkFVMSUwIwYDVQQKExxUaGUgVW5pdmVyc2l0eSBv ZiBRdWVlbnNsYW5kMScwJQYDVQQLEx5JbmZvcm1hdGlvbiBUZWNub2xvZ3kgU2VydmljZXMx FjAUBgoJkiaJk/IsZAEBEwZjY21hdHQxGTAXBgNVBAMTEE1hdHRoZXcgU3VsbGl2YW4xIDAe BgkqhkiG9w0BCQEWEW1hdHRoZXdAdXEuZWR1LmF1MFwwDQYJKoZIhvcNAQEBBQADSwAwSAJB AJsUfrw/QUqKIzDverWc2F4GFFRZmIeO+bAl+7BM6x/9frMzOtygx4QGb4oQwtOE8Sda1aIs v+yJF3Di9EuUyvMCAwEAAaNoMGYwDgYDVR0PAQH/BAQDAgXgMBEGCWCGSAGG+EIBAQQEAwIF oDAfBgNVHSMEGDAWgBQmqtoyueiWTYZBinvsnzeOWLtUuzAgBgNVHREEGTAXgRVtYXR0aGV3 QGl0cy51cS5lZHUuYXUwDQYJKoZIhvcNAQEEBQADggEBAF2gZrkqZsZlHd4K/+yBN6qrpD61 hctDf7/Eg4jk6DMknEs6nvHMFUMZ4SXvkqPLnHBygTARKAs7qBSLd7mUUBOOQEgk6ovQVY6S 1CDSt3P9O6wjG0K1igtk8v6u7lkQ8p2STXqrOePVINdaucUgBO/IpeUtt9ATl1qvPTWyM/fz oUZsIKeYjNQVEQsuimrZjdbIAFxdl1fggSngUv64wBn8wCssGrPZIZA2lpBBEW1wejoWrDOH IIr+SspGd0i8MovDTMRSvgTERLki17FU/ANilcrSXiODKeIvpXhnQqVScnsoMSZmBmN2QIoG SnBjNK5mYxx5E3v20VOwtP1hVdEwggNyMIICWqADAgECAgEqMA0GCSqGSIb3DQEBBAUAMIGj MQswCQYDVQQGEwJBVTETMBEGA1UECBMKUXVlZW5zbGFuZDERMA8GA1UEBxMIQnJpc2JhbmUx JTAjBgNVBAoTHFRoZSBVbml2ZXJzaXR5IG9mIFF1ZWVuc2xhbmQxKDAmBgNVBAsTH0luZm9y bWF0aW9uIFRlY2hub2xvZ3kgU2VydmljZXMxGzAZBgNVBAMTEkNlcnRpZmljYXRlIFNlcnZl cjAeFw0wNDAxMjEyMzM2MjFaFw0wNjAxMjEyMzM2MjFaMIGyMQswCQYDVQQGEwJBVTElMCMG A1UEChMcVGhlIFVuaXZlcnNpdHkgb2YgUXVlZW5zbGFuZDEnMCUGA1UECxMeSW5mb3JtYXRp b24gVGVjbm9sb2d5IFNlcnZpY2VzMRYwFAYKCZImiZPyLGQBARMGY2NtYXR0MRkwFwYDVQQD ExBNYXR0aGV3IFN1bGxpdmFuMSAwHgYJKoZIhvcNAQkBFhFtYXR0aGV3QHVxLmVkdS5hdTBc MA0GCSqGSIb3DQEBAQUAA0sAMEgCQQCbFH68P0FKiiMw73q1nNheBhRUWZiHjvmwJfuwTOsf /X6zMzrcoMeEBm+KEMLThPEnWtWiLL/siRdw4vRLlMrzAgMBAAGjaDBmMA4GA1UdDwEB/wQE AwIF4DARBglghkgBhvhCAQEEBAMCBaAwHwYDVR0jBBgwFoAUJqraMrnolk2GQYp77J83jli7 VLswIAYDVR0RBBkwF4EVbWF0dGhld0BpdHMudXEuZWR1LmF1MA0GCSqGSIb3DQEBBAUAA4IB AQBdoGa5KmbGZR3eCv/sgTeqq6Q+tYXLQ3+/xIOI5OgzJJxLOp7xzBVDGeEl75Kjy5xwcoEw ESgLO6gUi3e5lFATjkBIJOqL0FWOktQg0rdz/TusIxtCtYoLZPL+ru5ZEPKdkk16qznj1SDX WrnFIATvyKXlLbfQE5darz01sjP386FGbCCnmIzUFRELLopq2Y3WyABcXZdX4IEp4FL+uMAZ /MArLBqz2SGQNpaQQRFtcHo6FqwzhyCK/krKRndIvDKLw0zEUr4ExES5ItexVPwDYpXK0l4j gyniL6V4Z0KlUnJ7KDEmZgZjdkCKBkpwYzSuZmMceRN79tFTsLT9YVXRMYIDQDCCAzwCAQEw gakwgaMxCzAJBgNVBAYTAkFVMRMwEQYDVQQIEwpRdWVlbnNsYW5kMREwDwYDVQQHEwhCcmlz YmFuZTElMCMGA1UEChMcVGhlIFVuaXZlcnNpdHkgb2YgUXVlZW5zbGFuZDEoMCYGA1UECxMf SW5mb3JtYXRpb24gVGVjaG5vbG9neSBTZXJ2aWNlczEbMBkGA1UEAxMSQ2VydGlmaWNhdGUg U2VydmVyAgEqMAkGBSsOAwIaBQCgggItMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ KoZIhvcNAQkFMQ8XDTA1MDQyNTA4MzUzNVowIwYJKoZIhvcNAQkEMRYEFCFx80+pU09UyxQB cbOmJAIbz7wgMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIG6BgkrBgEEAYI3EAQx gawwgakwgaMxCzAJBgNVBAYTAkFVMRMwEQYDVQQIEwpRdWVlbnNsYW5kMREwDwYDVQQHEwhC cmlzYmFuZTElMCMGA1UEChMcVGhlIFVuaXZlcnNpdHkgb2YgUXVlZW5zbGFuZDEoMCYGA1UE CxMfSW5mb3JtYXRpb24gVGVjaG5vbG9neSBTZXJ2aWNlczEbMBkGA1UEAxMSQ2VydGlmaWNh dGUgU2VydmVyAgEqMIG8BgsqhkiG9w0BCRACCzGBrKCBqTCBozELMAkGA1UEBhMCQVUxEzAR BgNVBAgTClF1ZWVuc2xhbmQxETAPBgNVBAcTCEJyaXNiYW5lMSUwIwYDVQQKExxUaGUgVW5p dmVyc2l0eSBvZiBRdWVlbnNsYW5kMSgwJgYDVQQLEx9JbmZvcm1hdGlvbiBUZWNobm9sb2d5 IFNlcnZpY2VzMRswGQYDVQQDExJDZXJ0aWZpY2F0ZSBTZXJ2ZXICASowDQYJKoZIhvcNAQEB BQAEQDyG7O4vcMjuNFFLJaAJSUG+0c2YYQUmro9vVIFF6wJfTG+CaJRmvkOSXwpxuqtY+sBL O7D1N66ajVcqyK8lrqwAAAAAAAA= --------------ms050206080600040809020101-- From owner-freebsd-current@FreeBSD.ORG Mon Apr 25 08:58: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 F37EA16A4CE for ; Mon, 25 Apr 2005 08:58:12 +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 A3CA743D55 for ; Mon, 25 Apr 2005 08:58:12 +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 1DPzPv-0008Vo-FE; Mon, 25 Apr 2005 11:58:11 +0300 X-Mailer: exmh version 2.7.0 06/18/2004 with nmh-1.0.4 To: Marc Olzheim In-Reply-To: Message from Marc Olzheim of "Mon, 25 Apr 2005 10:22:11 +0200." <20050425082211.GB56859@stack.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 25 Apr 2005 11:58:11 +0300 From: Danny Braniss Message-ID: cc: freebsd-current@freebsd.org Subject: Re: serial console 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: Mon, 25 Apr 2005 08:58:13 -0000 > > --oC1+HKm2/end4ao3 > Content-Type: text/plain; charset=us-ascii > Content-Disposition: inline > > On Sat, Apr 23, 2005 at 03:16:36PM +0300, Danny Braniss wrote: > > the receiver part of the serial console seems to be somewhat problematic, > > i have to type almost every character more than once to be acccepted, making > > debugging with kgdb impossible. BTW, 5.4 works fine, so it's not a hardware > > problem, nor parity/speed/start-stop bits. > > And you are sure that no process is running on /dev/console with wchan > 'ttyin' ? it certainly looks so, but no cookies :-) if init finishes, then breaking into the debugger, all seems ok, no characters are lost (the console IS the serial), but if it panics, which is what im trying to debug early in rc, most of the keystrokes are getting lost. danny From owner-freebsd-current@FreeBSD.ORG Mon Apr 25 09:38: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 CE4B316A4CE for ; Mon, 25 Apr 2005 09:38:52 +0000 (GMT) Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by mx1.FreeBSD.org (Postfix) with SMTP id EDB8C43D1F for ; Mon, 25 Apr 2005 09:38:51 +0000 (GMT) (envelope-from iedowse@maths.tcd.ie) Received: from walton.maths.tcd.ie ([134.226.81.10] helo=maths.tcd.ie) by salmon.maths.tcd.ie with SMTP id ; 25 Apr 2005 10:38:51 +0100 (BST) To: Daniel Eriksson In-Reply-To: Your message of "Sat, 23 Apr 2005 10:09:41 +0200." Date: Mon, 25 Apr 2005 10:38:50 +0100 From: Ian Dowse Message-ID: <200504251038.aa23541@salmon.maths.tcd.ie> cc: 'FreeBSD Current' Subject: Re: Serious I/O problems (bad performance and live-lock) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 25 Apr 2005 09:38:53 -0000 In message , Daniel Eriksson writes: > >Here are some further observations and speculations. > >On a newly booted system, this is what happens: > >1. Start a "dd if=/dev/zero of=/usr/test bs=128k". >2. While looking at 'top', "Inact" grows and "Free" shrinks. >3. Once "Free" has bottomed out, "Inact" stops growing (naturally). >4. 'dd' continues to put a load on the VM system, eventually forcing most >processes to be swapped out (illustrated by the "RES" column showing a very >low number for all but a few processes). This takes 30-60 seconds after >"Free" has bottomed out on my machine. >5. At this point the machine is mostly useless because it can take several >minutes to run a simple 'ls'. This may not be directly related, but the disk scheduling algorithm in bioq_disksort() has always behaved poorly for large sequential writes. Its keeps deciding to process the next request in the sequential pattern because the single-direction elevator sort always prefers offsets that are after the current position over smaller offsets. The intention is that this results in frequent sweeps across the whole disk, but with large sequential writes it can get stuck for long periods of time at one part of the disk. Below is a patch that offers a bit more control over this behaviour that I was experimenting with some time ago. I seem to remember finding that a smaller value for kern.bioq_maxbeforeswitch such as 5 might be a better default. The existing bioq_disksort() behaviour corresponds to a very large value of this sysctl. Ian Index: subr_disk.c =================================================================== RCS file: /dump/FreeBSD-CVS/src/sys/kern/subr_disk.c,v retrieving revision 1.83 diff -u -r1.83 subr_disk.c --- subr_disk.c 6 Jan 2005 23:35:39 -0000 1.83 +++ subr_disk.c 17 Feb 2005 20:53:18 -0000 @@ -14,11 +14,18 @@ #include #include +#include +#include #include #include #include #include +int bioq_maxbeforeswitch = 20; +SYSCTL_INT(_kern, OID_AUTO, bioq_maxbeforeswitch, CTLFLAG_RW, + &bioq_maxbeforeswitch, 0, + "Maximum number of operations to place before the switch point"); + /*- * Disk error is the preface to plaintive error messages * about failing disk transfers. It prints messages of the form @@ -71,6 +78,7 @@ head->last_offset = 0; head->insert_point = NULL; head->switch_point = NULL; + head->beforeswitchcnt = 0; } void @@ -85,8 +93,10 @@ } else if (bp == TAILQ_FIRST(&head->queue)) head->last_offset = bp->bio_offset; TAILQ_REMOVE(&head->queue, bp, bio_queue); - if (TAILQ_FIRST(&head->queue) == head->switch_point) + if (TAILQ_FIRST(&head->queue) == head->switch_point) { + head->beforeswitchcnt = 0; head->switch_point = NULL; + } } void @@ -179,7 +189,8 @@ * "locked" portion of the list, then we must add ourselves * to the second request list. */ - if (bp->bio_offset < bioq->last_offset) { + if (bp->bio_offset < bioq->last_offset || + bioq->beforeswitchcnt > bioq_maxbeforeswitch) { bq = bioq->switch_point; /* @@ -202,6 +213,7 @@ return; } } else { + bioq->beforeswitchcnt++; if (bioq->switch_point != NULL) be = TAILQ_PREV(bioq->switch_point, bio_queue, bio_queue); From owner-freebsd-current@FreeBSD.ORG Mon Apr 25 09:49: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 9521316A4CE for ; Mon, 25 Apr 2005 09:49:37 +0000 (GMT) Received: from lexi.siliconlandmark.com (lexi.siliconlandmark.com [209.69.98.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3285143D46 for ; Mon, 25 Apr 2005 09:49:37 +0000 (GMT) (envelope-from andy@siliconlandmark.com) Received: from lexi.siliconlandmark.com (localhost [127.0.0.1]) j3P9nSW5030398; Mon, 25 Apr 2005 05:49:28 -0400 (EDT) (envelope-from andy@siliconlandmark.com) Received: from localhost (andy@localhost)j3P9nSUh030395; Mon, 25 Apr 2005 05:49:28 -0400 (EDT) (envelope-from andy@siliconlandmark.com) X-Authentication-Warning: lexi.siliconlandmark.com: andy owned process doing -bs Date: Mon, 25 Apr 2005 05:49:28 -0400 (EDT) From: Andre Guibert de Bruet To: Marc Olzheim In-Reply-To: <20050425081927.GA56859@stack.nl> Message-ID: <20050425053736.K23468@lexi.siliconlandmark.com> References: <52997.83.226.116.53.1114121015.squirrel@webmail.chalmers.se> <20050423024259.B68772@lexi.siliconlandmark.com> <20050425081927.GA56859@stack.nl> 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.547, required 6, autolearn=not spam, AWL 0.05, BAYES_00 -2.60) X-MailScanner-From: andy@siliconlandmark.com cc: freebsd-current@freebsd.org cc: Niklas Sorensson Subject: Re: Debug options X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 25 Apr 2005 09:49:37 -0000 On Mon, 25 Apr 2005, Marc Olzheim wrote: > On Sat, Apr 23, 2005 at 02:44:53AM -0400, Andre Guibert de Bruet wrote: >> May I also suggest tuning(7)? > > As in: may you suggest someone put this in tuning(7) ? Just from the fact that the document refers to 4.5 in the loader tunables section, it might be time to revamp it with information that is relevant to the current state of affairs, yes. > Or what part of tuning(7) are you referring to ? The original question was: "Are there any other options that affect performance? The note mentions malloc-debugging flags, but I don't know how to turn it off." Tuning has good information on sysctls which directly affect networking and vm performance. Despite its age, this document is a good read for anyone that is trying to get cheap performance. > No use pointing to manpages if the info isn't there. :-/ Naturally. :-) Cheers, Andy | Andre Guibert de Bruet | Enterprise Software Consultant > | Silicon Landmark, LLC. | http://siliconlandmark.com/ > From owner-freebsd-current@FreeBSD.ORG Mon Apr 25 09:50: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 CCE7416A4CE; Mon, 25 Apr 2005 09:50:23 +0000 (GMT) Received: from mx.toxahost.ru (ns.toxahost.ru [62.89.204.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id E30D243D4C; Mon, 25 Apr 2005 09:50:22 +0000 (GMT) (envelope-from toxa@toxahost.ru) Received: from localhost (laptoxa.toxa.lan [192.168.1.3]) by mx.toxahost.ru (Toxa) with ESMTP id D1D0691; Mon, 25 Apr 2005 13:50:20 +0400 (MSD) Date: Mon, 25 Apr 2005 13:50:16 +0400 From: Toxa To: freebsd-current@freebsd.org, freebsd-geom@freebsd.org X-Comment-To: "Anton A. Karpov" Message-ID: <20050425095016.GA10621@laptoxa.toxa.lan> Mail-Followup-To: freebsd-current@freebsd.org, freebsd-geom@freebsd.org References: <20050424022434.GA3384@laptoxa.toxa.lan> <20050424094343.GA837@darkness.comp.waw.pl> <20050424190912.GA6743@laptoxa.toxa.lan> <20050424193018.GH837@darkness.comp.waw.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20050424193018.GH837@darkness.comp.waw.pl> User-Agent: Outluck Express 1.5.6i for MS-DOS 6.22-SMP X-Mailer: See User-Agent above :) X-Operating-System: MS-DOS 6.22-CURRENT on Sony VAIO laptop X-PGP-Public-Key: http://toxahost.ru/gpg/pubkey.asc X-Useless-Header: Do Androids Dream of Electric Sheep? Subject: Re: gmirror: Not all disks connected X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 25 Apr 2005 09:50:23 -0000 On Sun, Apr 24, 2005 at 09:30:18PM +0200, Pawel Jakub Dawidek wrote: > If you created gmirror giving first smaller disk and then connecting bigger > one it should be ok. If disk which you want to insert is smaller than > already existing components, gmirror should return an error, so this is > probably not the case. Well, as you can see, the disk I inserted was *a little* smaller, in fact, it should be equal size of the first one, and gmirror accepted it into gm0 *without any error*. But after final reboot it refused to attach it. Changing disk order (creating new gm1 on smaller disk, then attaching a bigger disk to gm1) solved this problem. So maybe this is a weird bug... From owner-freebsd-current@FreeBSD.ORG Mon Apr 25 10:04: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 4FA9916A4CE; Mon, 25 Apr 2005 10:04:42 +0000 (GMT) Received: from bgo1smout1.broadpark.no (bgo1smout1.broadpark.no [217.13.4.94]) by mx1.FreeBSD.org (Postfix) with ESMTP id C128243D1D; Mon, 25 Apr 2005 10:04:41 +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 <0IFH00HKPYE8OM30@bgo1smout1.broadpark.no>; Mon, 25 Apr 2005 11:58:56 +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 <0IFH00HNSYPHH450@bgo1sminn1.broadpark.no>; Mon, 25 Apr 2005 12:05:41 +0200 (CEST) Received: by dsa.des.no (Pony Express, from userid 666) id 65FC3EC99A; Mon, 25 Apr 2005 12:04:39 +0200 (CEST) Received: from xps.des.no (xps.des.no [10.0.0.12]) by dsa.des.no (Pony Express) with ESMTP id 85E7AEC2ED; Mon, 25 Apr 2005 12:04:35 +0200 (CEST) Received: by xps.des.no (Postfix, from userid 1001) id 72A6233C09; Mon, 25 Apr 2005 12:04:35 +0200 (CEST) Date: Mon, 25 Apr 2005 12:04:35 +0200 From: des@des.no (=?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?=) In-reply-to: <426C6B1D.3040704@elischer.org> To: Julian Elischer Message-id: <86ll778958.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: <20050424175543.71041.qmail@web51805.mail.yahoo.com> <20050424151517.O68772@lexi.siliconlandmark.com> <3822.216.177.243.38.1114385370.localmail@webmail.dnswatch.com> <20050425000459.GA28667@xor.obsecurity.org> <6.2.1.2.0.20050424204611.072105a0@64.7.153.2> <20050425010242.GA44110@xor.obsecurity.org> <6.2.1.2.0.20050424210422.03d22990@64.7.153.2> <20050425014453.GA59981@xor.obsecurity.org> <426C6B1D.3040704@elischer.org> 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: Mike Tancsa cc: freebsd-current@freebsd.org cc: current@freebsd.org cc: Kris Kennaway Subject: Re: FreeBSD 6 is coming too fast X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 25 Apr 2005 10:04:42 -0000 Julian Elischer writes: > I wish people would stop trying to deny that we have serious work in > front of us to get the VFS and disk IO figures back to where they were > before. A great way to help getting this fixed would be to write automated benchmarks and regression tests, or at least solid test protocols. The documentation for these benchmarks and tests should clearly explain which (part of a) real-life workload they are intended to simulate. These benchmarks and tests would serve a double purpose: as hard evidence to back your arguments in discussions about performance regressions, and as tools for developers who wish to do something about such regressions. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Mon Apr 25 10:04: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 4FA9916A4CE; Mon, 25 Apr 2005 10:04:42 +0000 (GMT) Received: from bgo1smout1.broadpark.no (bgo1smout1.broadpark.no [217.13.4.94]) by mx1.FreeBSD.org (Postfix) with ESMTP id C128243D1D; Mon, 25 Apr 2005 10:04:41 +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 <0IFH00HKPYE8OM30@bgo1smout1.broadpark.no>; Mon, 25 Apr 2005 11:58:56 +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 <0IFH00HNSYPHH450@bgo1sminn1.broadpark.no>; Mon, 25 Apr 2005 12:05:41 +0200 (CEST) Received: by dsa.des.no (Pony Express, from userid 666) id 65FC3EC99A; Mon, 25 Apr 2005 12:04:39 +0200 (CEST) Received: from xps.des.no (xps.des.no [10.0.0.12]) by dsa.des.no (Pony Express) with ESMTP id 85E7AEC2ED; Mon, 25 Apr 2005 12:04:35 +0200 (CEST) Received: by xps.des.no (Postfix, from userid 1001) id 72A6233C09; Mon, 25 Apr 2005 12:04:35 +0200 (CEST) Date: Mon, 25 Apr 2005 12:04:35 +0200 From: des@des.no (=?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?=) In-reply-to: <426C6B1D.3040704@elischer.org> To: Julian Elischer Message-id: <86ll778958.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: <20050424175543.71041.qmail@web51805.mail.yahoo.com> <20050424151517.O68772@lexi.siliconlandmark.com> <3822.216.177.243.38.1114385370.localmail@webmail.dnswatch.com> <20050425000459.GA28667@xor.obsecurity.org> <6.2.1.2.0.20050424204611.072105a0@64.7.153.2> <20050425010242.GA44110@xor.obsecurity.org> <6.2.1.2.0.20050424210422.03d22990@64.7.153.2> <20050425014453.GA59981@xor.obsecurity.org> <426C6B1D.3040704@elischer.org> 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: Mike Tancsa cc: freebsd-current@freebsd.org cc: current@freebsd.org cc: Kris Kennaway Subject: Re: FreeBSD 6 is coming too fast X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 25 Apr 2005 10:04:42 -0000 Julian Elischer writes: > I wish people would stop trying to deny that we have serious work in > front of us to get the VFS and disk IO figures back to where they were > before. A great way to help getting this fixed would be to write automated benchmarks and regression tests, or at least solid test protocols. The documentation for these benchmarks and tests should clearly explain which (part of a) real-life workload they are intended to simulate. These benchmarks and tests would serve a double purpose: as hard evidence to back your arguments in discussions about performance regressions, and as tools for developers who wish to do something about such regressions. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Mon Apr 25 10:36: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 ADF2B16A4CE; Mon, 25 Apr 2005 10:36:28 +0000 (GMT) Received: from darkness.comp.waw.pl (darkness.comp.waw.pl [195.117.238.136]) by mx1.FreeBSD.org (Postfix) with ESMTP id A5E1F43D39; Mon, 25 Apr 2005 10:36:27 +0000 (GMT) (envelope-from pjd@darkness.comp.waw.pl) Received: by darkness.comp.waw.pl (Postfix, from userid 1009) id 900EBAC861; Mon, 25 Apr 2005 12:36:11 +0200 (CEST) Date: Mon, 25 Apr 2005 12:36:11 +0200 From: Pawel Jakub Dawidek To: freebsd-current@freebsd.org, freebsd-geom@freebsd.org Message-ID: <20050425103611.GJ837@darkness.comp.waw.pl> References: <20050424022434.GA3384@laptoxa.toxa.lan> <20050424094343.GA837@darkness.comp.waw.pl> <20050424190912.GA6743@laptoxa.toxa.lan> <20050424193018.GH837@darkness.comp.waw.pl> <20050425095016.GA10621@laptoxa.toxa.lan> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="9b4eu16IbjLAsbt2" Content-Disposition: inline In-Reply-To: <20050425095016.GA10621@laptoxa.toxa.lan> 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 Subject: Re: gmirror: Not all disks connected X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 25 Apr 2005 10:36:28 -0000 --9b4eu16IbjLAsbt2 Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Apr 25, 2005 at 01:50:16PM +0400, Toxa wrote: +> On Sun, Apr 24, 2005 at 09:30:18PM +0200, Pawel Jakub Dawidek wrote: +> > If you created gmirror giving first smaller disk and then connecting b= igger +> > one it should be ok. If disk which you want to insert is smaller than +> > already existing components, gmirror should return an error, so this is +> > probably not the case. +>=20 +>=20 +> Well, as you can see, the disk I inserted was *a little* smaller, in +> fact, it should be equal size of the first one, and gmirror accepted it +> into gm0 *without any error*. But after final reboot it refused to attac= h it. +> Changing disk order (creating new gm1 on smaller disk, then attaching=20 +> a bigger disk to gm1) solved this problem. So maybe this is a weird +> bug... I checked the code and there was a bug, but only when there was one sector difference. So if in your case was 3 sectors, it should tell you that your provider is too small: # mdconfig -a -t malloc -s 100 md0 # mdconfig -a -t malloc -s 103 md1 # gmirror label foo md1 # gmirror insert foo md0 Provider md0 too small. Exit 1 --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --9b4eu16IbjLAsbt2 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFCbMgbForvXbEpPzQRAqH8AJ9MUMVKiqT4zAgcNtjps7cjuvBEpQCeI7Tj dExq81y8xJriOSJ6CB1gmPA= =S4p5 -----END PGP SIGNATURE----- --9b4eu16IbjLAsbt2-- From owner-freebsd-current@FreeBSD.ORG Mon Apr 25 10:54: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 970A516A4CE for ; Mon, 25 Apr 2005 10:54:13 +0000 (GMT) Received: from fast.dnswatch.com (fast.dnswatch.com [216.177.243.43]) by mx1.FreeBSD.org (Postfix) with ESMTP id E1F4543D5A for ; Mon, 25 Apr 2005 10:54:12 +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 j3PAs6sm044094; Mon, 25 Apr 2005 03:54:10 -0700 (PDT) (envelope-from null@dnswatch.com) Received: (from www@localhost) by fast.dnswatch.com (8.12.6/8.12.6/Submit) id j3PAs57O044093; Mon, 25 Apr 2005 03:54:05 -0700 (PDT) (envelope-from null@dnswatch.com) X-Authentication-Warning: fast.dnswatch.com: www set sender to null@dnswatch.com using -f Received: from ns0.1command.com ([216.177.243.38]) (DNSwatch.com_WebMail authenticated user null) by webmail.dnswatch.com with HTTP; Mon, 25 Apr 2005 03:54:04 -0700 (PDT) Message-ID: <1252.216.177.243.38.1114426444.localmail@webmail.dnswatch.com> In-Reply-To: <426C328A.9060606@alumni.rice.edu> References: <20050424175543.71041.qmail@web51805.mail.yahoo.com><20050424151517.O68772@lexi.siliconlandmark.com><3822.216.177.243.38.1114385370.localmail@webmail.dnswatch.com> <426C328A.9060606@alumni.rice.edu> Date: Mon, 25 Apr 2005 03:54:04 -0700 (PDT) From: "/dev/null" To: freebsd-current@freebsd.org, noackjr@alumni.rice.edu 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: FreeBSD 6 is coming too fast X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 25 Apr 2005 10:54:13 -0000 Greetings Jon/ All, Thank you for the *informative* response! ... > On 04/24/05 18:29, /dev/null wrote: >> >> >> needed. All in all life on 5.x and the "upgrade" wasn't too bad. I will >> say that there is ONE issue that I have found and have not yet solved. >> It >> now takes at least 2 times longer to build any of the ports. Performance >> in other areas seems to be lagging as well. I have since upgraded one of >> the 2 servers to 5.4-RC2 and have been chasing 5.x ever since hoping to >> find the performance issues will dissappear. > > If you are running a UP system, it is expected that 4.x will outperform > 5.x in many situations due to the focus on SMP. Optimizing > synchronization to increase performance is one of the main goals for 6.x > (see the recent work on critical sections, for example). This will > allow us to scale well on SMP systems without pessimizing performance on > UP systems. Ah hah, I see. Well, it's funny you should bring up SMP. I bought one about 2yrs. ago for the sole purpose of building an SMP FBSD kernel on it, joined the list and started building. Turns out I, nor anyone on the list could get one to work. Of all things, it was the AHA-2940 that killed the whole thing. It just kept polling and resetting the drives. Never brought 'em up. So now Win2k Advanced Server lives on it. GRRRRRRR >:( Anyway, don't get me started. ;) But don't get me wrong. I'm truly greatful for your answer - REALLY. I'm actually waiting for SIX to level out so I can take another stab at it and remove another copy of Winblows. This time I'll try to take advantage of the UDMA 100 on the SMP board, and when the AHA-2940UW drivers start working on an SMP (in 6?), I can add the SCSI devices then. > > Another point to remember is that compilation times with GCC 3.4 > (default for recent 5.x) are much longer than those with 2.95 (default > for 4.x), especially at higher optimization levels. This is one of the > main reasons why it takes longer to compile a port. Interesting. Does this also apply to 5.0-RC2? I never noticed any "slow-downs" until I loaded 5.3-STABLE. > > That said, in what specific areas are you seeing performance regressions? Thus far, I haven't been able to pin it down. That is *something* seems to start gobbling up CPU and/ or resources to the extent I notice slight to moderate delays in things I'm doing. So far, only appears to occur while I'm running X (Fluxbox + Filerunner + Xterm + NEdit and sometimes Mozilla 1.7.7). But not the whole time, just for periods of time with no (currently) apparent rhythm. I haven't yet been able to associate it with anything other than X. Anyone else? -Chris P.S. Thanks again! > > Jon > _______________________________________________ > 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 Mon Apr 25 10:57: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 6B69016A4CE for ; Mon, 25 Apr 2005 10:57:43 +0000 (GMT) Received: from fast.dnswatch.com (fast.dnswatch.com [216.177.243.43]) by mx1.FreeBSD.org (Postfix) with ESMTP id BCEE243D60 for ; Mon, 25 Apr 2005 10:57:42 +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 j3PAvfsm044232 for ; Mon, 25 Apr 2005 03:57:42 -0700 (PDT) (envelope-from null@dnswatch.com) Received: (from www@localhost) by fast.dnswatch.com (8.12.6/8.12.6/Submit) id j3PAvf5X044231; Mon, 25 Apr 2005 03:57:41 -0700 (PDT) (envelope-from null@dnswatch.com) X-Authentication-Warning: fast.dnswatch.com: www set sender to null@dnswatch.com using -f Received: from ns0.1command.com ([216.177.243.38]) (DNSwatch.com_WebMail authenticated user null) by webmail.dnswatch.com with HTTP; Mon, 25 Apr 2005 03:57:41 -0700 (PDT) Message-ID: <1263.216.177.243.38.1114426661.localmail@webmail.dnswatch.com> In-Reply-To: References: <20050424175543.71041.qmail@web51805.mail.yahoo.com><20050424151517.O68772@lexi.siliconlandmark.com><3822.216.177.243.38.1114385370.localmail@webmail.dnswatch.com><426C328A.9060606@alumni.rice.edu> Date: Mon, 25 Apr 2005 03:57:41 -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: FreeBSD 6 is coming too fast X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 25 Apr 2005 10:57:43 -0000 Same System, same Applications. With the exception of Xorg in place of XFree86. -Chris > performance on many systems is very hard to gauge. I think this is > something mostly left up to the individual, as hardware-software > combinations truly make up the performance of a system. > > On Sun, 24 Apr 2005, Jon Noack wrote: > >> On 04/24/05 18:29, /dev/null wrote: >>> >>> >>> needed. All in all life on 5.x and the "upgrade" wasn't too bad. I will >>> say that there is ONE issue that I have found and have not yet solved. >>> It >>> now takes at least 2 times longer to build any of the ports. >>> Performance >>> in other areas seems to be lagging as well. I have since upgraded one >>> of >>> the 2 servers to 5.4-RC2 and have been chasing 5.x ever since hoping to >>> find the performance issues will dissappear. >> >> If you are running a UP system, it is expected that 4.x will outperform >> 5.x >> in many situations due to the focus on SMP. Optimizing synchronization >> to >> increase performance is one of the main goals for 6.x (see the recent >> work on >> critical sections, for example). This will allow us to scale well on >> SMP >> systems without pessimizing performance on UP systems. >> >> Another point to remember is that compilation times with GCC 3.4 >> (default for >> recent 5.x) are much longer than those with 2.95 (default for 4.x), >> especially at higher optimization levels. This is one of the main >> reasons >> why it takes longer to compile a port. >> >> That said, in what specific areas are you seeing performance >> regressions? >> >> Jon >> _______________________________________________ >> 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 Mon Apr 25 11:08: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 9D7BA16A4CE for ; Mon, 25 Apr 2005 11:08:31 +0000 (GMT) Received: from fast.dnswatch.com (fast.dnswatch.com [216.177.243.43]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1192843D54 for ; Mon, 25 Apr 2005 11:08:31 +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 j3PB8Ssm044441; Mon, 25 Apr 2005 04:08:30 -0700 (PDT) (envelope-from null@dnswatch.com) Received: (from www@localhost) by fast.dnswatch.com (8.12.6/8.12.6/Submit) id j3PB8SwC044440; Mon, 25 Apr 2005 04:08:28 -0700 (PDT) (envelope-from null@dnswatch.com) X-Authentication-Warning: fast.dnswatch.com: www set sender to null@dnswatch.com using -f Received: from ns0.1command.com ([216.177.243.38]) (DNSwatch.com_WebMail authenticated user null) by webmail.dnswatch.com with HTTP; Mon, 25 Apr 2005 04:08:27 -0700 (PDT) Message-ID: <1282.216.177.243.38.1114427307.localmail@webmail.dnswatch.com> In-Reply-To: <20050425000459.GA28667@xor.obsecurity.org> References: <20050424175543.71041.qmail@web51805.mail.yahoo.com><20050424151517.O68772@lexi.siliconlandmark.com><3822.216.177.243.38.1114385370.localmail@webmail.dnswatch.com> <20050425000459.GA28667@xor.obsecurity.org> Date: Mon, 25 Apr 2005 04:08:27 -0700 (PDT) From: "/dev/null" To: "Kris Kennaway" , 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: FreeBSD 6 is coming too fast X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 25 Apr 2005 11:08:31 -0000 > On Sun, Apr 24, 2005 at 04:29:30PM -0700, /dev/null wrote: > >> needed. All in all life on 5.x and the "upgrade" wasn't too bad. I will >> say that there is ONE issue that I have found and have not yet solved. >> It >> now takes at least 2 times longer to build any of the ports. > > This is not a FreeBSD performance bug. FreeBSD 5.x uses gcc 3.x, > which takes longer to compile code than gcc 2.x because it does much > more optimization. > >> Performance in other areas seems to be lagging as well. > > Since you were wrong about the above, WRONG?! ME?! That'll be the day. ;) Seriously tho, I am aware of the gcc versioning differences. But most of the "optimizations" can be performed by choice. That is to say I can negate the additional opts. And really, I didn't notice it in 5.0-RC2. It wasn't till 5.3-STABLE. > I have to ask whether you have > evidence of this. Indeed. Please see my comments on this in my reply to Jon. If that's not enough. Please give a hawler and I'll be happy to provide whatever you need. -Chris > > Kris //////////////////////////////////////////////////// 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 Mon Apr 25 11:19: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 49A1816A4CE for ; Mon, 25 Apr 2005 11:19:37 +0000 (GMT) Received: from fast.dnswatch.com (fast.dnswatch.com [216.177.243.43]) by mx1.FreeBSD.org (Postfix) with ESMTP id C92DB43D2F for ; Mon, 25 Apr 2005 11:19:36 +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 j3PBJYsm044631 for ; Mon, 25 Apr 2005 04:19:36 -0700 (PDT) (envelope-from null@dnswatch.com) Received: (from www@localhost) by fast.dnswatch.com (8.12.6/8.12.6/Submit) id j3PBJXE3044630; Mon, 25 Apr 2005 04:19:33 -0700 (PDT) (envelope-from null@dnswatch.com) X-Authentication-Warning: fast.dnswatch.com: www set sender to null@dnswatch.com using -f Received: from ns0.1command.com ([216.177.243.38]) (DNSwatch.com_WebMail authenticated user null) by webmail.dnswatch.com with HTTP; Mon, 25 Apr 2005 04:19:33 -0700 (PDT) Message-ID: <1362.216.177.243.38.1114427973.localmail@webmail.dnswatch.com> In-Reply-To: <6.2.1.2.0.20050424204611.072105a0@64.7.153.2> References: <20050424175543.71041.qmail@web51805.mail.yahoo.com><20050424151517.O68772@lexi.siliconlandmark.com><3822.216.177.243.38.1114385370.localmail@webmail.dnswatch.com><20050425000459.GA28667@xor.obsecurity.org> <6.2.1.2.0.20050424204611.072105a0@64.7.153.2> Date: Mon, 25 Apr 2005 04:19:33 -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: FreeBSD 6 is coming too fast X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 25 Apr 2005 11:19:37 -0000 Greetings, You know, it didn't occur to me until just now that the box in question here *always* has other boxes FS' mounted. That box is sort of a Central Command Center. So has many of the other servers FS' mounted for various tasks and so forth. I'll have to look closer at this. -Chris > At 08:04 PM 24/04/2005, Kris Kennaway wrote: > >> > Performance in other areas seems to be lagging as well. >> >>Since you were wrong about the above, I have to ask whether you have >>evidence of this. > > There was a lengthy discussion along with bonnie, dd, postmark and iozone > results discussed in January on the freebsd-performance list that > illustrate the disk io difference between RELENG_4 and RELENG_5 at the > time. > > I also tried a CURRENT snapshot then and there wasn't much of a difference > between it and RELENG_5. > > ---Mike > > _______________________________________________ > 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 Sun Apr 24 13:53: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 3E0DA16A4CE for ; Sun, 24 Apr 2005 13:53:56 +0000 (GMT) Received: from mail14a.g14.rapidsite.net (mail14a.g14.rapidsite.net [128.121.64.70]) by mx1.FreeBSD.org (Postfix) with SMTP id D625F43D3F for ; Sun, 24 Apr 2005 13:53:55 +0000 (GMT) (envelope-from hcoin@n4comm.com) Received: from www.n4comm.com (128.121.136.199)2-07128832 for ; Sun, 24 Apr 2005 09:53:54 -0400 (EDT) Message-Id: <4.3.2.7.2.20050424085214.0434da60@www.n4comm.com> X-Sender: hcoin@www.n4comm.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 24 Apr 2005 08:53:47 -0500 To: freebsd-current@freebsd.org From: Harry Coin Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Loop-Detect: 1 X-DistLoop-Detect: 1 X-Mailman-Approved-At: Mon, 25 Apr 2005 11:52:47 +0000 Subject: Re: 5.4 RC3 fails to detect psm0. Normal except no PS/2 mouse. atapicam doesn't hang. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 24 Apr 2005 13:53:56 -0000 Here's the kernel config file that couldn't find the ps/2 mouse # # GENERIC -- Generic kernel configuration file for FreeBSD/i386 # # For more information on this file, please read the handbook section on # Kernel Configuration Files: # # http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig-config.html # # The handbook is also available locally in /usr/share/doc/handbook # if you've installed the doc distribution, otherwise always see the # FreeBSD World Wide Web server (http://www.FreeBSD.org/) for the # latest information. # # An exhaustive list of options and more detailed explanations of the # device lines is also present in the ../../conf/NOTES and NOTES files. # If you are in doubt as to the purpose or necessity of a line, check first # in NOTES. # # $FreeBSD: src/sys/i386/conf/GENERIC,v 1.413.2.6.2.2 2004/10/24 18:02:52 scottl Exp $ machine i386 #cpu I486_CPU #cpu I586_CPU cpu I686_CPU ident SERVER1 options SMP # Symmetric MultiProcessor Kernel # To statically compile in device wiring instead of /boot/device.hints #hints "GENERIC.hints" # Default places to look for devices. options SCHED_4BSD # 4BSD scheduler options INET # InterNETworking #options INET6 # IPv6 communications protocols options FFS # Berkeley Fast Filesystem options SOFTUPDATES # Enable FFS soft updates support options UFS_ACL # Support for access control lists options UFS_DIRHASH # Improve performance on big directories options MD_ROOT # MD is a potential root device options NFSCLIENT # Network Filesystem Client options NFSSERVER # Network Filesystem Server options NFS_ROOT # NFS usable as /, requires NFSCLIENT options MSDOSFS # MSDOS Filesystem options CD9660 # ISO 9660 Filesystem options PROCFS # Process filesystem (requires PSEUDOFS) options PSEUDOFS # Pseudo-filesystem framework options GEOM_GPT # GUID Partition Tables. options COMPAT_43 # Compatible with BSD 4.3 [KEEP THIS!] options COMPAT_FREEBSD4 # Compatible with FreeBSD4 options SCSI_DELAY=15000 # Delay (in ms) before probing SCSI options KTRACE # ktrace(1) support options SYSVSHM # SYSV-style shared memory options SYSVMSG # SYSV-style message queues options SYSVSEM # SYSV-style semaphores options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions options KBD_INSTALL_CDEV # install a CDEV entry in /dev options AHC_REG_PRETTY_PRINT # Print register bitfields in debug # output. Adds ~128k to driver. options AHD_REG_PRETTY_PRINT # Print register bitfields in debug # output. Adds ~215k to driver. options ADAPTIVE_GIANT # Giant mutex is adaptive. device apic # I/O APIC # Bus support. Do not remove isa, even if you have no isa slots device isa device eisa device pci # Floppy drives device fdc # ATA and ATAPI devices device ata device atadisk # ATA disk drives device ataraid # ATA RAID drives device atapicd # ATAPI CDROM drives device atapifd # ATAPI floppy drives device atapist # ATAPI tape drives options ATA_STATIC_ID # Static device numbering # SCSI Controllers device ahb # EISA AHA1742 family device ahc # AHA2940 and onboard AIC7xxx devices device ahd # AHA39320/29320 and onboard AIC79xx devices device amd # AMD 53C974 (Tekram DC-390(T)) device isp # Qlogic family device mpt # LSI-Logic MPT-Fusion #device ncr # NCR/Symbios Logic device sym # NCR/Symbios Logic (newer chipsets + those of `ncr') device trm # Tekram DC395U/UW/F DC315U adapters device adv # Advansys SCSI adapters device adw # Advansys wide SCSI adapters device aha # Adaptec 154x SCSI adapters device aic # Adaptec 15[012]x SCSI adapters, AIC-6[23]60. device bt # Buslogic/Mylex MultiMaster SCSI adapters device ncv # NCR 53C500 device nsp # Workbit Ninja SCSI-3 device stg # TMC 18C30/18C50 # SCSI peripherals device scbus # SCSI bus (required for SCSI) device ch # SCSI media changers device da # Direct Access (disks) device sa # Sequential Access (tape etc) device cd # CD device pass # Passthrough device (direct SCSI access) device ses # SCSI Environmental Services (and SAF-TE) # RAID controllers interfaced to the SCSI subsystem device amr # AMI MegaRAID device asr # DPT SmartRAID V, VI and Adaptec SCSI RAID device ciss # Compaq Smart RAID 5* device dpt # DPT Smartcache III, IV - See NOTES for options device hptmv # Highpoint RocketRAID 182x device iir # Intel Integrated RAID device ips # IBM (Adaptec) ServeRAID device mly # Mylex AcceleRAID/eXtremeRAID device twa # 3ware 9000 series PATA/SATA RAID # RAID controllers device aac # Adaptec FSA RAID device aacp # SCSI passthrough for aac (requires CAM) device ida # Compaq Smart RAID device mlx # Mylex DAC960 family device pst # Promise Supertrak SX6000 device twe # 3ware ATA RAID # atkbdc0 controls both the keyboard and the PS/2 mouse device atkbdc # AT keyboard controller device atkbd # AT keyboard device psm # PS/2 mouse device vga # VGA video card driver device splash # Splash screen and screen saver support # syscons is the default console driver, resembling an SCO console device sc # Enable this for the pcvt (VT220 compatible) console driver #device vt #options XSERVER # support for X server on a vt console #options FAT_CURSOR # start with block cursor device agp # support several AGP chipsets # Floating point support - do not disable. device npx # Power management support (see NOTES for more options) #device apm # Add suspend/resume support for the i8254. device pmtimer # PCCARD (PCMCIA) support # PCMCIA and cardbus bridge support device cbb # cardbus (yenta) bridge device pccard # PC Card (16-bit) bus device cardbus # CardBus (32-bit) bus # Serial (COM) ports device sio # 8250, 16[45]50 based serial ports # Parallel port device ppc device ppbus # Parallel port bus (required) device lpt # Printer device plip # TCP/IP over parallel device ppi # Parallel port interface device #device vpo # Requires scbus and da # If you've got a "dumb" serial or parallel PCI card that is # supported by the puc(4) glue driver, uncomment the following # line to enable it (connects to the sio and/or ppc drivers): #device puc # PCI Ethernet NICs. device de # DEC/Intel DC21x4x (``Tulip'') device em # Intel PRO/1000 adapter Gigabit Ethernet Card device ixgb # Intel PRO/10GbE Ethernet Card device txp # 3Com 3cR990 (``Typhoon'') device vx # 3Com 3c590, 3c595 (``Vortex'') # PCI Ethernet NICs that use the common MII bus controller code. # NOTE: Be sure to keep the 'device miibus' line in order to use these NICs! device miibus # MII bus support device bfe # Broadcom BCM440x 10/100 Ethernet device bge # Broadcom BCM570xx Gigabit Ethernet device dc # DEC/Intel 21143 and various workalikes device fxp # Intel EtherExpress PRO/100B (82557, 82558) device lge # Level 1 LXT1001 gigabit ethernet device nge # NatSemi DP83820 gigabit ethernet device pcn # AMD Am79C97x PCI 10/100 (precedence over 'lnc') device re # RealTek 8139C+/8169/8169S/8110S device rl # RealTek 8129/8139 device sf # Adaptec AIC-6915 (``Starfire'') device sis # Silicon Integrated Systems SiS 900/SiS 7016 device sk # SysKonnect SK-984x & SK-982x gigabit Ethernet device ste # Sundance ST201 (D-Link DFE-550TX) device ti # Alteon Networks Tigon I/II gigabit Ethernet device tl # Texas Instruments ThunderLAN device tx # SMC EtherPower II (83c170 ``EPIC'') device vge # VIA VT612x gigabit ethernet device vr # VIA Rhine, Rhine II device wb # Winbond W89C840F device xl # 3Com 3c90x (``Boomerang'', ``Cyclone'') # ISA Ethernet NICs. pccard NICs included. device cs # Crystal Semiconductor CS89x0 NIC # 'device ed' requires 'device miibus' device ed # NE[12]000, SMC Ultra, 3c503, DS8390 cards device ex # Intel EtherExpress Pro/10 and Pro/10+ device ep # Etherlink III based cards device fe # Fujitsu MB8696x based cards device ie # EtherExpress 8/16, 3C507, StarLAN 10 etc. device lnc # NE2100, NE32-VL Lance Ethernet cards device sn # SMC's 9000 series of Ethernet chips device xe # Xircom pccard Ethernet # ISA devices that use the old ISA shims #device le # Wireless NIC cards device wlan # 802.11 support device an # Aironet 4500/4800 802.11 wireless NICs. device awi # BayStack 660 and others device wi # WaveLAN/Intersil/Symbol 802.11 wireless NICs. #device wl # Older non 802.11 Wavelan wireless NIC. # Pseudo devices. device loop # Network loopback device mem # Memory and kernel memory devices device io # I/O device device random # Entropy device device ether # Ethernet support device sl # Kernel SLIP device ppp # Kernel PPP device tun # Packet tunnel. device pty # Pseudo-ttys (telnet etc) device md # Memory "disks" #device gif # IPv6 and IPv4 tunneling #device faith # IPv6-to-IPv4 relaying (translation) # The `bpf' device enables the Berkeley Packet Filter. # Be aware of the administrative consequences of enabling this! device bpf # Berkeley packet filter # USB support device uhci # UHCI PCI->USB interface device ohci # OHCI PCI->USB interface device usb # USB Bus (required) #device udbp # USB Double Bulk Pipe devices device ugen # Generic device uhid # "Human Interface Devices" device ukbd # Keyboard device ulpt # Printer device umass # Disks/Mass storage - Requires scbus and da device ums # Mouse device urio # Diamond Rio 500 MP3 player device uscanner # Scanners # USB Ethernet, requires mii #device aue # ADMtek USB Ethernet #device axe # ASIX Electronics USB Ethernet #device cue # CATC USB Ethernet #device kue # Kawasaki LSI USB Ethernet #device rue # RealTek RTL8150 USB Ethernet # FireWire support #device firewire # FireWire bus code #device sbp # SCSI over FireWire (Requires scbus and da) #device fwe # Ethernet over FireWire (non-standard!) #Sound Support device sound device "snd_ad1816" device snd_ich From owner-freebsd-current@FreeBSD.ORG Mon Apr 25 12:01: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 ED68716A4CE for ; Mon, 25 Apr 2005 12:01:04 +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 773CD43D39 for ; Mon, 25 Apr 2005 12:01:04 +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 1DQ2Gt-000C9O-Jx for current@freebsd.org; Mon, 25 Apr 2005 15:01:03 +0300 X-Mailer: exmh version 2.7.0 06/18/2004 with nmh-1.0.4 To: current@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 25 Apr 2005 15:01:03 +0300 From: Danny Braniss Message-ID: Subject: serial/ether console & ramblings X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 25 Apr 2005 12:01:05 -0000 hi, I was about to plunge in and 'try' to cleanup the serial console stuff, when it downed on me that newer machines are arriving without serial port! there goes that idea. So USB/serial dongle came to mind, might work, but messy, FireWire is not universaly available. So, why not serial over ethernet? IPMI 'was' to have solved this, but it will (if at all) work on server class MB only, and im still looking for a Unix Viewer. In my case, i have been using the serial console to debug stuff, but being of the old school, i try to stay away from debuggers :-), so printf and stack trace will do. So here are some of my quesions: o - is there some standard? ok, refrase, are there some standards? o - any WIP?, i'm checking out Robert Watson's ethercons o - any great ideas? danny From owner-freebsd-current@FreeBSD.ORG Mon Apr 25 13:24: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 7FEE316A4CE for ; Mon, 25 Apr 2005 13:24:12 +0000 (GMT) Received: from mail-sin2.microsoft.com (mail-sin2.microsoft.com [207.46.50.82]) by mx1.FreeBSD.org (Postfix) with ESMTP id ADC0143D49 for ; Mon, 25 Apr 2005 13:24:11 +0000 (GMT) (envelope-from mayank@microsoft.com) Received: from APS-MSG-01.southpacific.corp.microsoft.com ([157.60.218.45]) by mail-sin2.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 25 Apr 2005 21:19:09 +0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 25 Apr 2005 21:19:12 +0800 Message-ID: <3A5384BC2FBA4C488865F2275A036BFF027C1614@APS-MSG-01.southpacific.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Query regarding thread safety of few libc stdio functions thread-index: AcVJmHm33y2izWcETyyNZsTSYWUJwAAABKhw From: "Mayank Kumar" To: X-OriginalArrivalTime: 25 Apr 2005 13:19:09.0886 (UTC) FILETIME=[5D95F5E0:01C54999] Subject: Query regarding thread safety of few libc stdio functions X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 25 Apr 2005 13:24:12 -0000 Hi All Recently I have been looking at few freebsd libc functions and I found That they were not thread safe. Can one of you please confirm. Following functions in freebsd libc are not thread safe:- 1: vsnprintf 2: vsprintf 3: vsscanf theere are many more. Functions like vfprintf are written as follows:- ------------- int ret; FLOCKFILE(fp); ret =3D __vfprintf(fp, fmt0, ap); FUNLOCKFILE(fp); return (ret); ---------------- Which ensures that they are thread safe. Why is the same case not followed for eg with vsnprintf or vsprintf Vsnprintf calls directly __vfprintf which is not thread safe. Hence How is there thready safey guranteed. Any help on this front Would be helpful. Thanks and regards Mayank From owner-freebsd-current@FreeBSD.ORG Mon Apr 25 13:33: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 1EFA216A4CE for ; Mon, 25 Apr 2005 13:33:07 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0476343D2F; Mon, 25 Apr 2005 13:33:07 +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 j3PDX3Qq084226; Mon, 25 Apr 2005 13:33:05 GMT (envelope-from davidxu@freebsd.org) Message-ID: <426CF18E.5050203@freebsd.org> Date: Mon, 25 Apr 2005 21:33:02 +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: Mayank Kumar References: <3A5384BC2FBA4C488865F2275A036BFF027C1614@APS-MSG-01.southpacific.corp.microsoft.com> In-Reply-To: <3A5384BC2FBA4C488865F2275A036BFF027C1614@APS-MSG-01.southpacific.corp.microsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-current@freebsd.org Subject: Re: Query regarding thread safety of few libc stdio functions X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 25 Apr 2005 13:33:07 -0000 Mayank Kumar wrote: >Hi All >Recently I have been looking at few freebsd libc functions and I found >That they were not thread safe. Can one of you please confirm. > >Following functions in freebsd libc are not thread safe:- >1: vsnprintf >2: vsprintf >3: vsscanf > theere are many more. > >Functions like vfprintf are written as follows:- >------------- >int ret; > > FLOCKFILE(fp); > ret = __vfprintf(fp, fmt0, ap); > FUNLOCKFILE(fp); > return (ret); >---------------- >Which ensures that they are thread safe. > >Why is the same case not followed for eg with vsnprintf or vsprintf >Vsnprintf calls directly __vfprintf which is not thread safe. Hence >How is there thready safey guranteed. Any help on this front >Would be helpful. > >Thanks and regards >Mayank > vsnprintf and vsprintf use a on stack FILE structure, no other threads can see the structure, it won't be shared with other threads, so lock is not needed. Cheers, David Xu From owner-freebsd-current@FreeBSD.ORG Mon Apr 25 13:39: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 DD9E216A4CE for ; Mon, 25 Apr 2005 13:39:58 +0000 (GMT) Received: from arginine.spc.org (arginine.spc.org [83.167.185.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2C1A443D1D for ; Mon, 25 Apr 2005 13:39:58 +0000 (GMT) (envelope-from bms@spc.org) Received: from localhost (localhost [127.0.0.1]) by arginine.spc.org (Postfix) with ESMTP id 046BA65319; Mon, 25 Apr 2005 14:39:15 +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 88296-01-7; Mon, 25 Apr 2005 14:39:14 +0100 (BST) Received: from empiric.dek.spc.org (host81-134-90-164.in-addr.btopenworld.com [81.134.90.164]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by arginine.spc.org (Postfix) with ESMTP id 19E076530A; Mon, 25 Apr 2005 14:39:10 +0100 (BST) Received: by empiric.dek.spc.org (Postfix, from userid 1001) id 48BDC64CF; Mon, 25 Apr 2005 14:39:51 +0100 (BST) Date: Mon, 25 Apr 2005 14:39:51 +0100 From: Bruce M Simpson To: Mayank Kumar Message-ID: <20050425133951.GC769@empiric.icir.org> Mail-Followup-To: Mayank Kumar , freebsd-current@freebsd.org References: <3A5384BC2FBA4C488865F2275A036BFF027C1614@APS-MSG-01.southpacific.corp.microsoft.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="VrqPEDrXMn8OVzN4" Content-Disposition: inline In-Reply-To: <3A5384BC2FBA4C488865F2275A036BFF027C1614@APS-MSG-01.southpacific.corp.microsoft.com> cc: freebsd-current@freebsd.org Subject: Re: Query regarding thread safety of few libc stdio functions X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 25 Apr 2005 13:39:59 -0000 --VrqPEDrXMn8OVzN4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, On Mon, Apr 25, 2005 at 09:19:12PM +0800, Mayank Kumar wrote: > Why is the same case not followed for eg with vsnprintf or vsprintf > Vsnprintf calls directly __vfprintf which is not thread safe. Hence > How is there thready safey guranteed. Any help on this front > Would be helpful. 1) Thread safety/locking for the destination buffer is the calling program's responsibility -- the vsprintf() function could have no knowledge of this anyway. 2) In any event __vfprintf() references a file handle. For the vsprintf() case it looks like this is faked up. File handles are global, again, thread safety for C library file handles hasn't been specified by many iterations of the relevant standards (don't quote me on this, though, I'm no standards guru). 3) The __vfprintf() function doesn't appear to modify global data or use any data other than what's in its own scope. Whilst two variables are declared static it doesn't look like they are overwritten. The INITEXTRA() macro appears to iniitalize the pthread mutex used by the library functions to a default value. In any event the mutex should be unnecessary because of 1) above. So in short I think it's thread safe as long as your program performs the necessary locking around shared buffers, which is not an issue which libc will solve for you anyway. This is much the same situation as when working with MSVCRT.DLL (again, something I've had to deal with quite a bit lately at my dayjob). Regards, BMS --VrqPEDrXMn8OVzN4 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Comment: '' iD8DBQFCbPMmueUpAYYNtTsRAqjkAKCkdvZ6uiW3UsWiUT1ZQDlLzHvcnQCfdGaw QWiCfYmQsmtR0KSj/EIahyE= =si/N -----END PGP SIGNATURE----- --VrqPEDrXMn8OVzN4-- From owner-freebsd-current@FreeBSD.ORG Mon Apr 25 13:46: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 AA24C16A4CE; Mon, 25 Apr 2005 13:46:28 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id CD56343D45; Mon, 25 Apr 2005 13:46:25 +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.3/8.13.3) with ESMTP id j3PDp5Gi003924; Mon, 25 Apr 2005 07:51:06 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <426CF3DE.4000409@samsco.org> Date: Mon, 25 Apr 2005 07:42:54 -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: Kirill Ponomarew References: <20050424175543.71041.qmail@web51805.mail.yahoo.com> <20050424151517.O68772@lexi.siliconlandmark.com> <3822.216.177.243.38.1114385370.localmail@webmail.dnswatch.com> <20050425000459.GA28667@xor.obsecurity.org> <6.2.1.2.0.20050424204611.072105a0@64.7.153.2> <20050425010242.GA44110@xor.obsecurity.org> <6.2.1.2.0.20050424210422.03d22990@64.7.153.2> <20050425014453.GA59981@xor.obsecurity.org> <426C6B1D.3040704@elischer.org> <20050425061459.GA33247@xor.obsecurity.org> <20050425062106.GB91852@voodoo.oberon.net> In-Reply-To: <20050425062106.GB91852@voodoo.oberon.net> 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: Julian Elischer cc: Mike Tancsa cc: freebsd-current@freebsd.org cc: current@freebsd.org cc: Kris Kennaway Subject: Re: FreeBSD 6 is coming too fast X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 25 Apr 2005 13:46:28 -0000 Kirill Ponomarew wrote: > On Sun, Apr 24, 2005 at 11:14:59PM -0700, Kris Kennaway wrote: > >>>>Measuring disk device performance (i.e. running a benchmark against >>>>the bare device) and filesystem performance (writing to a filesystem >>>>on the device) are very different things. >>> >>>I wish people would stop trying to deny that we have serious work in front >>>of us to get the VFS and disk IO figures back to where they were before. >>> >>>there ARE slowdowns and I have seen it both with tests on teh basic >>>hardware and throug the filesystems. I don't know why this surproses >>>people because we have still a lot of work to do in teh interrupt latency >>>field for example, and I doubt that even PHK would say that there is no >>>work left to do in geom. >>>Where we are now is closing in on "feature complete". Now we need to >>>profile and optimise. >> >>OK, but note that I didn't deny anything, I only questioned whether >>the OP was observing a real problem (he didn't mention disk I/O, or in >>fact any specific claim) or whether it was a coloured perception based >>on the (incorrect) assumption that gcc compilation speed was measuring >>a performance loss in FreeBSD. > > > According to gcc-4.0 release notes, compilation speed for C++ was > dramatically increased, up to 25% IIRC. I think 4.0 is good > candidate for merging into HEAD. > > -Kirill Is this work that you plan on doing for us? What about the deprecated language constructs in 4.0? What about the lack of exposure that it's had outside of the FSF and Apple development circles? Scott From owner-freebsd-current@FreeBSD.ORG Mon Apr 25 13:46: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 AA24C16A4CE; Mon, 25 Apr 2005 13:46:28 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id CD56343D45; Mon, 25 Apr 2005 13:46:25 +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.3/8.13.3) with ESMTP id j3PDp5Gi003924; Mon, 25 Apr 2005 07:51:06 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <426CF3DE.4000409@samsco.org> Date: Mon, 25 Apr 2005 07:42:54 -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: Kirill Ponomarew References: <20050424175543.71041.qmail@web51805.mail.yahoo.com> <20050424151517.O68772@lexi.siliconlandmark.com> <3822.216.177.243.38.1114385370.localmail@webmail.dnswatch.com> <20050425000459.GA28667@xor.obsecurity.org> <6.2.1.2.0.20050424204611.072105a0@64.7.153.2> <20050425010242.GA44110@xor.obsecurity.org> <6.2.1.2.0.20050424210422.03d22990@64.7.153.2> <20050425014453.GA59981@xor.obsecurity.org> <426C6B1D.3040704@elischer.org> <20050425061459.GA33247@xor.obsecurity.org> <20050425062106.GB91852@voodoo.oberon.net> In-Reply-To: <20050425062106.GB91852@voodoo.oberon.net> 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: Julian Elischer cc: Mike Tancsa cc: freebsd-current@freebsd.org cc: current@freebsd.org cc: Kris Kennaway Subject: Re: FreeBSD 6 is coming too fast X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 25 Apr 2005 13:46:28 -0000 Kirill Ponomarew wrote: > On Sun, Apr 24, 2005 at 11:14:59PM -0700, Kris Kennaway wrote: > >>>>Measuring disk device performance (i.e. running a benchmark against >>>>the bare device) and filesystem performance (writing to a filesystem >>>>on the device) are very different things. >>> >>>I wish people would stop trying to deny that we have serious work in front >>>of us to get the VFS and disk IO figures back to where they were before. >>> >>>there ARE slowdowns and I have seen it both with tests on teh basic >>>hardware and throug the filesystems. I don't know why this surproses >>>people because we have still a lot of work to do in teh interrupt latency >>>field for example, and I doubt that even PHK would say that there is no >>>work left to do in geom. >>>Where we are now is closing in on "feature complete". Now we need to >>>profile and optimise. >> >>OK, but note that I didn't deny anything, I only questioned whether >>the OP was observing a real problem (he didn't mention disk I/O, or in >>fact any specific claim) or whether it was a coloured perception based >>on the (incorrect) assumption that gcc compilation speed was measuring >>a performance loss in FreeBSD. > > > According to gcc-4.0 release notes, compilation speed for C++ was > dramatically increased, up to 25% IIRC. I think 4.0 is good > candidate for merging into HEAD. > > -Kirill Is this work that you plan on doing for us? What about the deprecated language constructs in 4.0? What about the lack of exposure that it's had outside of the FSF and Apple development circles? Scott From owner-freebsd-current@FreeBSD.ORG Mon Apr 25 13:53: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 397F616A4CE; Mon, 25 Apr 2005 13:53:45 +0000 (GMT) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0AD9D43D1D; Mon, 25 Apr 2005 13:53:45 +0000 (GMT) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) j3PDrfJ1001991; Mon, 25 Apr 2005 06:53:41 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost)j3PDrf8t001990; Mon, 25 Apr 2005 06:53:41 -0700 (PDT) (envelope-from sgk) Date: Mon, 25 Apr 2005 06:53:41 -0700 From: Steve Kargl To: Scott Long Message-ID: <20050425135341.GA1965@troutmask.apl.washington.edu> References: <3822.216.177.243.38.1114385370.localmail@webmail.dnswatch.com> <20050425000459.GA28667@xor.obsecurity.org> <6.2.1.2.0.20050424204611.072105a0@64.7.153.2> <20050425010242.GA44110@xor.obsecurity.org> <6.2.1.2.0.20050424210422.03d22990@64.7.153.2> <20050425014453.GA59981@xor.obsecurity.org> <426C6B1D.3040704@elischer.org> <20050425061459.GA33247@xor.obsecurity.org> <20050425062106.GB91852@voodoo.oberon.net> <426CF3DE.4000409@samsco.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <426CF3DE.4000409@samsco.org> User-Agent: Mutt/1.4.2.1i cc: current@freebsd.org cc: Mike Tancsa cc: freebsd-current@freebsd.org cc: Julian Elischer cc: Kirill Ponomarew cc: Kris Kennaway Subject: Re: FreeBSD 6 is coming too fast X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 25 Apr 2005 13:53:45 -0000 On Mon, Apr 25, 2005 at 07:42:54AM -0600, Scott Long wrote: > Kirill Ponomarew wrote: > > > >According to gcc-4.0 release notes, compilation speed for C++ was > >dramatically increased, up to 25% IIRC. I think 4.0 is good > >candidate for merging into HEAD. > > > > Is this work that you plan on doing for us? What about the deprecated > language constructs in 4.0? What about the lack of exposure that it's > had outside of the FSF and Apple development circles? > I build gcc-4.x almost daily on i386 and amd64 FreeBSD systems. I would recommend a conservative approach of not updating at this time. -- Steve From owner-freebsd-current@FreeBSD.ORG Mon Apr 25 13:53: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 397F616A4CE; Mon, 25 Apr 2005 13:53:45 +0000 (GMT) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0AD9D43D1D; Mon, 25 Apr 2005 13:53:45 +0000 (GMT) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) j3PDrfJ1001991; Mon, 25 Apr 2005 06:53:41 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost)j3PDrf8t001990; Mon, 25 Apr 2005 06:53:41 -0700 (PDT) (envelope-from sgk) Date: Mon, 25 Apr 2005 06:53:41 -0700 From: Steve Kargl To: Scott Long Message-ID: <20050425135341.GA1965@troutmask.apl.washington.edu> References: <3822.216.177.243.38.1114385370.localmail@webmail.dnswatch.com> <20050425000459.GA28667@xor.obsecurity.org> <6.2.1.2.0.20050424204611.072105a0@64.7.153.2> <20050425010242.GA44110@xor.obsecurity.org> <6.2.1.2.0.20050424210422.03d22990@64.7.153.2> <20050425014453.GA59981@xor.obsecurity.org> <426C6B1D.3040704@elischer.org> <20050425061459.GA33247@xor.obsecurity.org> <20050425062106.GB91852@voodoo.oberon.net> <426CF3DE.4000409@samsco.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <426CF3DE.4000409@samsco.org> User-Agent: Mutt/1.4.2.1i cc: current@freebsd.org cc: Mike Tancsa cc: freebsd-current@freebsd.org cc: Julian Elischer cc: Kirill Ponomarew cc: Kris Kennaway Subject: Re: FreeBSD 6 is coming too fast X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 25 Apr 2005 13:53:45 -0000 On Mon, Apr 25, 2005 at 07:42:54AM -0600, Scott Long wrote: > Kirill Ponomarew wrote: > > > >According to gcc-4.0 release notes, compilation speed for C++ was > >dramatically increased, up to 25% IIRC. I think 4.0 is good > >candidate for merging into HEAD. > > > > Is this work that you plan on doing for us? What about the deprecated > language constructs in 4.0? What about the lack of exposure that it's > had outside of the FSF and Apple development circles? > I build gcc-4.x almost daily on i386 and amd64 FreeBSD systems. I would recommend a conservative approach of not updating at this time. -- Steve From owner-freebsd-current@FreeBSD.ORG Mon Apr 25 14:02: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 148A116A4CE; Mon, 25 Apr 2005 14:02:40 +0000 (GMT) Received: from mindfields.energyhq.es.eu.org (73.Red-213-97-200.pooles.rima-tde.net [213.97.200.73]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5F78B43D54; Mon, 25 Apr 2005 14:02:34 +0000 (GMT) (envelope-from flynn@energyhq.es.eu.org) Received: from scienide.energyhq.es.eu.org (scienide.energyhq.es.eu.org [IPv6:2001:470:1f01:198:210:4bff:fe3d:e256]) by mindfields.energyhq.es.eu.org (Postfix) with SMTP id E16E4364CD; Mon, 25 Apr 2005 16:02:31 +0200 (CEST) Date: Mon, 25 Apr 2005 16:01:46 +0200 From: Miguel Mendez To: Scott Long Message-Id: <20050425160146.4795fe1b.flynn@energyhq.es.eu.org> In-Reply-To: <426CF3DE.4000409@samsco.org> References: <20050424175543.71041.qmail@web51805.mail.yahoo.com> <20050424151517.O68772@lexi.siliconlandmark.com> <3822.216.177.243.38.1114385370.localmail@webmail.dnswatch.com> <20050425000459.GA28667@xor.obsecurity.org> <6.2.1.2.0.20050424204611.072105a0@64.7.153.2> <20050425010242.GA44110@xor.obsecurity.org> <6.2.1.2.0.20050424210422.03d22990@64.7.153.2> <20050425014453.GA59981@xor.obsecurity.org> <426C6B1D.3040704@elischer.org> <20050425061459.GA33247@xor.obsecurity.org> <20050425062106.GB91852@voodoo.oberon.net> <426CF3DE.4000409@samsco.org> X-Mailer: Sylpheed version 1.9.8 (GTK+ 2.6.4; i386-portbld-freebsd5.4) Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="PGP-SHA1"; boundary="Signature=_Mon__25_Apr_2005_16_01_46_+0200_H9ov_fo.WmCV/UuB" cc: current@freebsd.org cc: mike@sentex.net cc: freebsd-current@freebsd.org cc: julian@elischer.org cc: krion@voodoo.oberon.net cc: kris@obsecurity.org Subject: Re: FreeBSD 6 is coming too fast X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 25 Apr 2005 14:02:40 -0000 --Signature=_Mon__25_Apr_2005_16_01_46_+0200_H9ov_fo.WmCV/UuB Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, 25 Apr 2005 07:42:54 -0600 Scott Long wrote: > > According to gcc-4.0 release notes, compilation speed for C++ was > > dramatically increased, up to 25% IIRC. I think 4.0 is good > > candidate for merging into HEAD. > Is this work that you plan on doing for us? =20 Definitely not for 6.0, and I usually avoid .0 releases on critical software, but nonetheless it would interesting setting a tinderbox, launch a buildworld process with gcc40 and see where/if it breaks. I have a spare k6-2 box I could setup for that task. > What about the deprecated language constructs in 4.0? According to http://gcc.gnu.org/gcc-4.0/changes.html, some of the deprecated constructs are not even valid C, so I see this as an opportunity to fix buggy code.=20 >What about the lack of exposure that it's > had outside of the FSF and Apple development circles? Exactly the reason why testing will be beneficial. The more tested the product on FreeBSD the more robust it will be when it's time to get it into the tree. Cheers, --=20 Miguel Mendez http://www.energyhq.es.eu.org PGP Key: 0xDC8514F1 --Signature=_Mon__25_Apr_2005_16_01_46_+0200_H9ov_fo.WmCV/UuB Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFCbPhNnLctrNyFFPERAnaAAKC5egEPQUP/uJ2dfp4JR1iHeKYYkwCgreO/ ybrvxcde3SXoy/KA3UjRIcY= =J5FO -----END PGP SIGNATURE----- --Signature=_Mon__25_Apr_2005_16_01_46_+0200_H9ov_fo.WmCV/UuB-- From owner-freebsd-current@FreeBSD.ORG Mon Apr 25 14:02: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 148A116A4CE; Mon, 25 Apr 2005 14:02:40 +0000 (GMT) Received: from mindfields.energyhq.es.eu.org (73.Red-213-97-200.pooles.rima-tde.net [213.97.200.73]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5F78B43D54; Mon, 25 Apr 2005 14:02:34 +0000 (GMT) (envelope-from flynn@energyhq.es.eu.org) Received: from scienide.energyhq.es.eu.org (scienide.energyhq.es.eu.org [IPv6:2001:470:1f01:198:210:4bff:fe3d:e256]) by mindfields.energyhq.es.eu.org (Postfix) with SMTP id E16E4364CD; Mon, 25 Apr 2005 16:02:31 +0200 (CEST) Date: Mon, 25 Apr 2005 16:01:46 +0200 From: Miguel Mendez To: Scott Long Message-Id: <20050425160146.4795fe1b.flynn@energyhq.es.eu.org> In-Reply-To: <426CF3DE.4000409@samsco.org> References: <20050424175543.71041.qmail@web51805.mail.yahoo.com> <20050424151517.O68772@lexi.siliconlandmark.com> <3822.216.177.243.38.1114385370.localmail@webmail.dnswatch.com> <20050425000459.GA28667@xor.obsecurity.org> <6.2.1.2.0.20050424204611.072105a0@64.7.153.2> <20050425010242.GA44110@xor.obsecurity.org> <6.2.1.2.0.20050424210422.03d22990@64.7.153.2> <20050425014453.GA59981@xor.obsecurity.org> <426C6B1D.3040704@elischer.org> <20050425061459.GA33247@xor.obsecurity.org> <20050425062106.GB91852@voodoo.oberon.net> <426CF3DE.4000409@samsco.org> X-Mailer: Sylpheed version 1.9.8 (GTK+ 2.6.4; i386-portbld-freebsd5.4) Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="PGP-SHA1"; boundary="Signature=_Mon__25_Apr_2005_16_01_46_+0200_H9ov_fo.WmCV/UuB" cc: current@freebsd.org cc: mike@sentex.net cc: freebsd-current@freebsd.org cc: julian@elischer.org cc: krion@voodoo.oberon.net cc: kris@obsecurity.org Subject: Re: FreeBSD 6 is coming too fast X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 25 Apr 2005 14:02:40 -0000 --Signature=_Mon__25_Apr_2005_16_01_46_+0200_H9ov_fo.WmCV/UuB Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, 25 Apr 2005 07:42:54 -0600 Scott Long wrote: > > According to gcc-4.0 release notes, compilation speed for C++ was > > dramatically increased, up to 25% IIRC. I think 4.0 is good > > candidate for merging into HEAD. > Is this work that you plan on doing for us? =20 Definitely not for 6.0, and I usually avoid .0 releases on critical software, but nonetheless it would interesting setting a tinderbox, launch a buildworld process with gcc40 and see where/if it breaks. I have a spare k6-2 box I could setup for that task. > What about the deprecated language constructs in 4.0? According to http://gcc.gnu.org/gcc-4.0/changes.html, some of the deprecated constructs are not even valid C, so I see this as an opportunity to fix buggy code.=20 >What about the lack of exposure that it's > had outside of the FSF and Apple development circles? Exactly the reason why testing will be beneficial. The more tested the product on FreeBSD the more robust it will be when it's time to get it into the tree. Cheers, --=20 Miguel Mendez http://www.energyhq.es.eu.org PGP Key: 0xDC8514F1 --Signature=_Mon__25_Apr_2005_16_01_46_+0200_H9ov_fo.WmCV/UuB Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFCbPhNnLctrNyFFPERAnaAAKC5egEPQUP/uJ2dfp4JR1iHeKYYkwCgreO/ ybrvxcde3SXoy/KA3UjRIcY= =J5FO -----END PGP SIGNATURE----- --Signature=_Mon__25_Apr_2005_16_01_46_+0200_H9ov_fo.WmCV/UuB-- From owner-freebsd-current@FreeBSD.ORG Mon Apr 25 14: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 37D9C16A4CE for ; Mon, 25 Apr 2005 14:08:40 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8747C43D3F for ; Mon, 25 Apr 2005 14:08:39 +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.3/8.13.3) with ESMTP id j3PEDObb004046; Mon, 25 Apr 2005 08:13:24 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <426CF91A.8060907@samsco.org> Date: Mon, 25 Apr 2005 08:05:14 -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: Miguel Mendez References: <20050424175543.71041.qmail@web51805.mail.yahoo.com> <20050424151517.O68772@lexi.siliconlandmark.com> <3822.216.177.243.38.1114385370.localmail@webmail.dnswatch.com> <20050425000459.GA28667@xor.obsecurity.org> <6.2.1.2.0.20050424204611.072105a0@64.7.153.2> <20050425010242.GA44110@xor.obsecurity.org> <6.2.1.2.0.20050424210422.03d22990@64.7.153.2> <20050425014453.GA59981@xor.obsecurity.org> <426C6B1D.3040704@elischer.org> <20050425061459.GA33247@xor.obsecurity.org> <20050425062106.GB91852@voodoo.oberon.net> <426CF3DE.4000409@samsco.org> <20050425160146.4795fe1b.flynn@energyhq.es.eu.org> In-Reply-To: <20050425160146.4795fe1b.flynn@energyhq.es.eu.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: current@freebsd.org cc: mike@sentex.net cc: freebsd-current@freebsd.org cc: julian@elischer.org cc: krion@voodoo.oberon.net cc: kris@obsecurity.org Subject: GCC 4.0 [Re: FreeBSD 6 is coming too fast] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 25 Apr 2005 14:08:40 -0000 Miguel Mendez wrote: > On Mon, 25 Apr 2005 07:42:54 -0600 > Scott Long wrote: > > >>>According to gcc-4.0 release notes, compilation speed for C++ was >>>dramatically increased, up to 25% IIRC. I think 4.0 is good >>>candidate for merging into HEAD. > > >>Is this work that you plan on doing for us? > > > Definitely not for 6.0, and I usually avoid .0 releases on critical > software, but nonetheless it would interesting setting a tinderbox, > launch a buildworld process with gcc40 and see where/if it breaks. I > have a spare k6-2 box I could setup for that task. > > >>What about the deprecated language constructs in 4.0? > > > According to http://gcc.gnu.org/gcc-4.0/changes.html, some of the > deprecated constructs are not even valid C, so I see this as an > opportunity to fix buggy code. > > >>What about the lack of exposure that it's >>had outside of the FSF and Apple development circles? > > > Exactly the reason why testing will be beneficial. The more tested the > product on FreeBSD the more robust it will be when it's time to get it > into the tree. > > Cheers, Well, I'd caution against jumping into GCC 4.0 just because of the claims of 25% speed improvement. That's about the single worst reason to do it. But if you're interested in moving the technology forward, I'd happily encourage you. The changed language constructs are the big problem (extern struct foo bar[]; is no longer valid) since you not only need to sweep the FreeBSD tree for them, you also need to sweep the ports tree. I have mixed feeling on the value of GCC making sloppy language extentions available for years and then suddenly revoking them, and I know others that have been affected by 4.0 aren't terribly happy either. Scott From owner-freebsd-current@FreeBSD.ORG Mon Apr 25 14:08: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 6CA2216A4E7 for ; Mon, 25 Apr 2005 14:08:47 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id B672643D49 for ; Mon, 25 Apr 2005 14:08: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.3/8.13.3) with ESMTP id j3PEDObb004046; Mon, 25 Apr 2005 08:13:24 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <426CF91A.8060907@samsco.org> Date: Mon, 25 Apr 2005 08:05:14 -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: Miguel Mendez References: <20050424175543.71041.qmail@web51805.mail.yahoo.com> <20050424151517.O68772@lexi.siliconlandmark.com> <3822.216.177.243.38.1114385370.localmail@webmail.dnswatch.com> <20050425000459.GA28667@xor.obsecurity.org> <6.2.1.2.0.20050424204611.072105a0@64.7.153.2> <20050425010242.GA44110@xor.obsecurity.org> <6.2.1.2.0.20050424210422.03d22990@64.7.153.2> <20050425014453.GA59981@xor.obsecurity.org> <426C6B1D.3040704@elischer.org> <20050425061459.GA33247@xor.obsecurity.org> <20050425062106.GB91852@voodoo.oberon.net> <426CF3DE.4000409@samsco.org> <20050425160146.4795fe1b.flynn@energyhq.es.eu.org> In-Reply-To: <20050425160146.4795fe1b.flynn@energyhq.es.eu.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: current@freebsd.org cc: mike@sentex.net cc: freebsd-current@freebsd.org cc: julian@elischer.org cc: krion@voodoo.oberon.net cc: kris@obsecurity.org Subject: GCC 4.0 [Re: FreeBSD 6 is coming too fast] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 25 Apr 2005 14:08:47 -0000 Miguel Mendez wrote: > On Mon, 25 Apr 2005 07:42:54 -0600 > Scott Long wrote: > > >>>According to gcc-4.0 release notes, compilation speed for C++ was >>>dramatically increased, up to 25% IIRC. I think 4.0 is good >>>candidate for merging into HEAD. > > >>Is this work that you plan on doing for us? > > > Definitely not for 6.0, and I usually avoid .0 releases on critical > software, but nonetheless it would interesting setting a tinderbox, > launch a buildworld process with gcc40 and see where/if it breaks. I > have a spare k6-2 box I could setup for that task. > > >>What about the deprecated language constructs in 4.0? > > > According to http://gcc.gnu.org/gcc-4.0/changes.html, some of the > deprecated constructs are not even valid C, so I see this as an > opportunity to fix buggy code. > > >>What about the lack of exposure that it's >>had outside of the FSF and Apple development circles? > > > Exactly the reason why testing will be beneficial. The more tested the > product on FreeBSD the more robust it will be when it's time to get it > into the tree. > > Cheers, Well, I'd caution against jumping into GCC 4.0 just because of the claims of 25% speed improvement. That's about the single worst reason to do it. But if you're interested in moving the technology forward, I'd happily encourage you. The changed language constructs are the big problem (extern struct foo bar[]; is no longer valid) since you not only need to sweep the FreeBSD tree for them, you also need to sweep the ports tree. I have mixed feeling on the value of GCC making sloppy language extentions available for years and then suddenly revoking them, and I know others that have been affected by 4.0 aren't terribly happy either. Scott From owner-freebsd-current@FreeBSD.ORG Mon Apr 25 14:11: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 1A78E16A4CE for ; Mon, 25 Apr 2005 14:11:30 +0000 (GMT) Received: from mh1.centtech.com (moat3.centtech.com [207.200.51.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 35F7043D3F for ; Mon, 25 Apr 2005 14:11:29 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from [10.177.171.220] (neutrino.centtech.com [10.177.171.220]) by mh1.centtech.com (8.13.1/8.13.1) with ESMTP id j3PEBGTj029159; Mon, 25 Apr 2005 09:11:16 -0500 (CDT) (envelope-from anderson@centtech.com) Message-ID: <426CFA51.3060003@centtech.com> Date: Mon, 25 Apr 2005 09:10: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: Danny Braniss References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.82/851/Sun Apr 24 20:19:30 2005 on mh1.centtech.com X-Virus-Status: Clean cc: current@freebsd.org Subject: Re: serial/ether console & ramblings X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 25 Apr 2005 14:11:30 -0000 Danny Braniss wrote: > hi, > I was about to plunge in and 'try' to cleanup the serial console > stuff, when it downed on me that newer machines are arriving without serial > port! there goes that idea. So USB/serial dongle came to mind, might > work, but messy, FireWire is not universaly available. > So, why not serial over ethernet? IPMI 'was' to have solved > this, but it will (if at all) work on server class MB only, and im still > looking for a Unix Viewer. > > In my case, i have been using the serial console to debug stuff, but > being of the old school, i try to stay away from debuggers :-), so > printf and stack trace will do. > > So here are some of my quesions: > o - is there some standard? ok, refrase, are there some > standards? > o - any WIP?, i'm checking out Robert Watson's ethercons > o - any great ideas? There are a couple of ports that seem to try to use IPMI. I haven't tried them yet though. (sysutils/freeipmi and sysutils/ipmitool). I can tell you that being about to do serial over ethernet (and possibly power cycling) would be incredibly handy. 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 Mon Apr 25 14:41: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 F23E916A4CE; Mon, 25 Apr 2005 14:41:19 +0000 (GMT) Received: from voodoo.oberon.net (voodoo.oberon.net [212.118.165.100]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8547A43D69; Mon, 25 Apr 2005 14:41:19 +0000 (GMT) (envelope-from krion@voodoo.oberon.net) Received: from krion by voodoo.oberon.net with local (Exim 4.50 (FreeBSD)) id 1DQ4lo-0006Z8-TK; Mon, 25 Apr 2005 16:41:08 +0200 Date: Mon, 25 Apr 2005 16:41:08 +0200 From: Kirill Ponomarew To: Scott Long Message-ID: <20050425144108.GK91852@voodoo.oberon.net> References: <3822.216.177.243.38.1114385370.localmail@webmail.dnswatch.com> <20050425000459.GA28667@xor.obsecurity.org> <6.2.1.2.0.20050424204611.072105a0@64.7.153.2> <20050425010242.GA44110@xor.obsecurity.org> <6.2.1.2.0.20050424210422.03d22990@64.7.153.2> <20050425014453.GA59981@xor.obsecurity.org> <426C6B1D.3040704@elischer.org> <20050425061459.GA33247@xor.obsecurity.org> <20050425062106.GB91852@voodoo.oberon.net> <426CF3DE.4000409@samsco.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <426CF3DE.4000409@samsco.org> X-NCC-Regid: de.oberon X-NIC-HDL: KP869-RIPE Keywords: 579279786 cc: current@freebsd.org cc: Kris Kennaway cc: freebsd-current@freebsd.org cc: Julian Elischer cc: Mike Tancsa Subject: Re: FreeBSD 6 is coming too fast X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 25 Apr 2005 14:41:20 -0000 On Mon, Apr 25, 2005 at 07:42:54AM -0600, Scott Long wrote: > >According to gcc-4.0 release notes, compilation speed for C++ was > >dramatically increased, up to 25% IIRC. I think 4.0 is good > >candidate for merging into HEAD. > > > >-Kirill > > Is this work that you plan on doing for us? What about the deprecated > language constructs in 4.0? What about the lack of exposure that it's > had outside of the FSF and Apple development circles? No, I'm not going to do it because of lack of knowledge, there are people who have more experience with it than me. -Kirill From owner-freebsd-current@FreeBSD.ORG Mon Apr 25 14:41: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 F23E916A4CE; Mon, 25 Apr 2005 14:41:19 +0000 (GMT) Received: from voodoo.oberon.net (voodoo.oberon.net [212.118.165.100]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8547A43D69; Mon, 25 Apr 2005 14:41:19 +0000 (GMT) (envelope-from krion@voodoo.oberon.net) Received: from krion by voodoo.oberon.net with local (Exim 4.50 (FreeBSD)) id 1DQ4lo-0006Z8-TK; Mon, 25 Apr 2005 16:41:08 +0200 Date: Mon, 25 Apr 2005 16:41:08 +0200 From: Kirill Ponomarew To: Scott Long Message-ID: <20050425144108.GK91852@voodoo.oberon.net> References: <3822.216.177.243.38.1114385370.localmail@webmail.dnswatch.com> <20050425000459.GA28667@xor.obsecurity.org> <6.2.1.2.0.20050424204611.072105a0@64.7.153.2> <20050425010242.GA44110@xor.obsecurity.org> <6.2.1.2.0.20050424210422.03d22990@64.7.153.2> <20050425014453.GA59981@xor.obsecurity.org> <426C6B1D.3040704@elischer.org> <20050425061459.GA33247@xor.obsecurity.org> <20050425062106.GB91852@voodoo.oberon.net> <426CF3DE.4000409@samsco.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <426CF3DE.4000409@samsco.org> X-NCC-Regid: de.oberon X-NIC-HDL: KP869-RIPE Keywords: 579279786 cc: current@freebsd.org cc: Kris Kennaway cc: freebsd-current@freebsd.org cc: Julian Elischer cc: Mike Tancsa Subject: Re: FreeBSD 6 is coming too fast X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 25 Apr 2005 14:41:20 -0000 On Mon, Apr 25, 2005 at 07:42:54AM -0600, Scott Long wrote: > >According to gcc-4.0 release notes, compilation speed for C++ was > >dramatically increased, up to 25% IIRC. I think 4.0 is good > >candidate for merging into HEAD. > > > >-Kirill > > Is this work that you plan on doing for us? What about the deprecated > language constructs in 4.0? What about the lack of exposure that it's > had outside of the FSF and Apple development circles? No, I'm not going to do it because of lack of knowledge, there are people who have more experience with it than me. -Kirill From owner-freebsd-current@FreeBSD.ORG Mon Apr 25 14: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 752E616A4CE; Mon, 25 Apr 2005 14:43:01 +0000 (GMT) Received: from voodoo.oberon.net (voodoo.oberon.net [212.118.165.100]) by mx1.FreeBSD.org (Postfix) with ESMTP id F176F43D54; Mon, 25 Apr 2005 14:43:00 +0000 (GMT) (envelope-from krion@voodoo.oberon.net) Received: from krion by voodoo.oberon.net with local (Exim 4.50 (FreeBSD)) id 1DQ4nc-0006a7-1Y; Mon, 25 Apr 2005 16:43:00 +0200 Date: Mon, 25 Apr 2005 16:43:00 +0200 From: Kirill Ponomarew To: Scott Long Message-ID: <20050425144259.GL91852@voodoo.oberon.net> References: <6.2.1.2.0.20050424204611.072105a0@64.7.153.2> <20050425010242.GA44110@xor.obsecurity.org> <6.2.1.2.0.20050424210422.03d22990@64.7.153.2> <20050425014453.GA59981@xor.obsecurity.org> <426C6B1D.3040704@elischer.org> <20050425061459.GA33247@xor.obsecurity.org> <20050425062106.GB91852@voodoo.oberon.net> <426CF3DE.4000409@samsco.org> <20050425160146.4795fe1b.flynn@energyhq.es.eu.org> <426CF91A.8060907@samsco.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <426CF91A.8060907@samsco.org> X-NCC-Regid: de.oberon X-NIC-HDL: KP869-RIPE Keywords: 579279786 cc: current@freebsd.org cc: mike@sentex.net cc: freebsd-current@freebsd.org cc: julian@elischer.org cc: kris@obsecurity.org Subject: Re: GCC 4.0 [Re: FreeBSD 6 is coming too fast] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 25 Apr 2005 14:43:01 -0000 On Mon, Apr 25, 2005 at 08:05:14AM -0600, Scott Long wrote: > Well, I'd caution against jumping into GCC 4.0 just because of the > claims of 25% speed improvement. That's about the single worst reason > to do it. But if you're interested in moving the technology forward, > I'd happily encourage you. The changed language constructs are the big > problem (extern struct foo bar[]; is no longer valid) since you not only > need to sweep the FreeBSD tree for them, you also need to sweep the > ports tree. I have mixed feeling on the value of GCC making sloppy > language extentions available for years and then suddenly revoking them, > and I know others that have been affected by 4.0 aren't terribly happy > either. Well. if we're going to import it, it should be tested on pointyhat first. IIRC Kris already run tests for some pre 4.0 versions. -Kirill From owner-freebsd-current@FreeBSD.ORG Mon Apr 25 14: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 752E616A4CE; Mon, 25 Apr 2005 14:43:01 +0000 (GMT) Received: from voodoo.oberon.net (voodoo.oberon.net [212.118.165.100]) by mx1.FreeBSD.org (Postfix) with ESMTP id F176F43D54; Mon, 25 Apr 2005 14:43:00 +0000 (GMT) (envelope-from krion@voodoo.oberon.net) Received: from krion by voodoo.oberon.net with local (Exim 4.50 (FreeBSD)) id 1DQ4nc-0006a7-1Y; Mon, 25 Apr 2005 16:43:00 +0200 Date: Mon, 25 Apr 2005 16:43:00 +0200 From: Kirill Ponomarew To: Scott Long Message-ID: <20050425144259.GL91852@voodoo.oberon.net> References: <6.2.1.2.0.20050424204611.072105a0@64.7.153.2> <20050425010242.GA44110@xor.obsecurity.org> <6.2.1.2.0.20050424210422.03d22990@64.7.153.2> <20050425014453.GA59981@xor.obsecurity.org> <426C6B1D.3040704@elischer.org> <20050425061459.GA33247@xor.obsecurity.org> <20050425062106.GB91852@voodoo.oberon.net> <426CF3DE.4000409@samsco.org> <20050425160146.4795fe1b.flynn@energyhq.es.eu.org> <426CF91A.8060907@samsco.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <426CF91A.8060907@samsco.org> X-NCC-Regid: de.oberon X-NIC-HDL: KP869-RIPE Keywords: 579279786 cc: current@freebsd.org cc: mike@sentex.net cc: freebsd-current@freebsd.org cc: julian@elischer.org cc: kris@obsecurity.org Subject: Re: GCC 4.0 [Re: FreeBSD 6 is coming too fast] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 25 Apr 2005 14:43:01 -0000 On Mon, Apr 25, 2005 at 08:05:14AM -0600, Scott Long wrote: > Well, I'd caution against jumping into GCC 4.0 just because of the > claims of 25% speed improvement. That's about the single worst reason > to do it. But if you're interested in moving the technology forward, > I'd happily encourage you. The changed language constructs are the big > problem (extern struct foo bar[]; is no longer valid) since you not only > need to sweep the FreeBSD tree for them, you also need to sweep the > ports tree. I have mixed feeling on the value of GCC making sloppy > language extentions available for years and then suddenly revoking them, > and I know others that have been affected by 4.0 aren't terribly happy > either. Well. if we're going to import it, it should be tested on pointyhat first. IIRC Kris already run tests for some pre 4.0 versions. -Kirill From owner-freebsd-current@FreeBSD.ORG Mon Apr 25 14:48: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 117A716A4CE; Mon, 25 Apr 2005 14:48:03 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 50A9443D1F; Mon, 25 Apr 2005 14:48:02 +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.3/8.13.3) with ESMTP id j3PEqiIt004212; Mon, 25 Apr 2005 08:52:44 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <426D0252.5050805@samsco.org> Date: Mon, 25 Apr 2005 08:44:34 -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: Kirill Ponomarew References: <3822.216.177.243.38.1114385370.localmail@webmail.dnswatch.com> <20050425000459.GA28667@xor.obsecurity.org> <6.2.1.2.0.20050424204611.072105a0@64.7.153.2> <20050425010242.GA44110@xor.obsecurity.org> <6.2.1.2.0.20050424210422.03d22990@64.7.153.2> <20050425014453.GA59981@xor.obsecurity.org> <426C6B1D.3040704@elischer.org> <20050425061459.GA33247@xor.obsecurity.org> <20050425062106.GB91852@voodoo.oberon.net> <426CF3DE.4000409@samsco.org> <20050425144108.GK91852@voodoo.oberon.net> In-Reply-To: <20050425144108.GK91852@voodoo.oberon.net> 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: current@freebsd.org cc: Kris Kennaway cc: freebsd-current@freebsd.org cc: Julian Elischer cc: Mike Tancsa Subject: Re: FreeBSD 6 is coming too fast X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 25 Apr 2005 14:48:03 -0000 Kirill Ponomarew wrote: > On Mon, Apr 25, 2005 at 07:42:54AM -0600, Scott Long wrote: > >>>According to gcc-4.0 release notes, compilation speed for C++ was >>>dramatically increased, up to 25% IIRC. I think 4.0 is good >>>candidate for merging into HEAD. >>> >>>-Kirill >> >>Is this work that you plan on doing for us? What about the deprecated >>language constructs in 4.0? What about the lack of exposure that it's >>had outside of the FSF and Apple development circles? > > > No, I'm not going to do it because of lack of knowledge, there are > people who have more experience with it than me. > > -Kirill Well, as I said in another email, switching to GCC 4 just because of dubious "25% faster" (faster at what? compiling? resulting generated code? crashing?) claims in the changelog is not a terribly good reason =-) It seems that every time GCC claims to get "faster", our buildworld times increase by 10%. Maybe the generated code is better and faster, but it's no secret that gcc spends a lot more CPU cycles on code genreation and optimization than it did in the 2.x series. Note also that the GCC 4.0 changelog mentions that the -O0 flag is faster; that's wonderful, but has no practical value to real people. Scott From owner-freebsd-current@FreeBSD.ORG Mon Apr 25 14:48: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 117A716A4CE; Mon, 25 Apr 2005 14:48:03 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 50A9443D1F; Mon, 25 Apr 2005 14:48:02 +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.3/8.13.3) with ESMTP id j3PEqiIt004212; Mon, 25 Apr 2005 08:52:44 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <426D0252.5050805@samsco.org> Date: Mon, 25 Apr 2005 08:44:34 -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: Kirill Ponomarew References: <3822.216.177.243.38.1114385370.localmail@webmail.dnswatch.com> <20050425000459.GA28667@xor.obsecurity.org> <6.2.1.2.0.20050424204611.072105a0@64.7.153.2> <20050425010242.GA44110@xor.obsecurity.org> <6.2.1.2.0.20050424210422.03d22990@64.7.153.2> <20050425014453.GA59981@xor.obsecurity.org> <426C6B1D.3040704@elischer.org> <20050425061459.GA33247@xor.obsecurity.org> <20050425062106.GB91852@voodoo.oberon.net> <426CF3DE.4000409@samsco.org> <20050425144108.GK91852@voodoo.oberon.net> In-Reply-To: <20050425144108.GK91852@voodoo.oberon.net> 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: current@freebsd.org cc: Kris Kennaway cc: freebsd-current@freebsd.org cc: Julian Elischer cc: Mike Tancsa Subject: Re: FreeBSD 6 is coming too fast X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 25 Apr 2005 14:48:03 -0000 Kirill Ponomarew wrote: > On Mon, Apr 25, 2005 at 07:42:54AM -0600, Scott Long wrote: > >>>According to gcc-4.0 release notes, compilation speed for C++ was >>>dramatically increased, up to 25% IIRC. I think 4.0 is good >>>candidate for merging into HEAD. >>> >>>-Kirill >> >>Is this work that you plan on doing for us? What about the deprecated >>language constructs in 4.0? What about the lack of exposure that it's >>had outside of the FSF and Apple development circles? > > > No, I'm not going to do it because of lack of knowledge, there are > people who have more experience with it than me. > > -Kirill Well, as I said in another email, switching to GCC 4 just because of dubious "25% faster" (faster at what? compiling? resulting generated code? crashing?) claims in the changelog is not a terribly good reason =-) It seems that every time GCC claims to get "faster", our buildworld times increase by 10%. Maybe the generated code is better and faster, but it's no secret that gcc spends a lot more CPU cycles on code genreation and optimization than it did in the 2.x series. Note also that the GCC 4.0 changelog mentions that the -O0 flag is faster; that's wonderful, but has no practical value to real people. Scott From owner-freebsd-current@FreeBSD.ORG Mon Apr 25 14:49: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 1DAF216A4CE for ; Mon, 25 Apr 2005 14:49:51 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5DBE443D31 for ; Mon, 25 Apr 2005 14:49:50 +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.3/8.13.3) with ESMTP id j3PEsY2A004227; Mon, 25 Apr 2005 08:54:35 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <426D02C0.1030708@samsco.org> Date: Mon, 25 Apr 2005 08:46:24 -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: Kirill Ponomarew References: <6.2.1.2.0.20050424204611.072105a0@64.7.153.2> <20050425010242.GA44110@xor.obsecurity.org> <6.2.1.2.0.20050424210422.03d22990@64.7.153.2> <20050425014453.GA59981@xor.obsecurity.org> <426C6B1D.3040704@elischer.org> <20050425061459.GA33247@xor.obsecurity.org> <20050425062106.GB91852@voodoo.oberon.net> <426CF3DE.4000409@samsco.org> <20050425160146.4795fe1b.flynn@energyhq.es.eu.org> <426CF91A.8060907@samsco.org> <20050425144259.GL91852@voodoo.oberon.net> In-Reply-To: <20050425144259.GL91852@voodoo.oberon.net> 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: current@freebsd.org cc: mike@sentex.net cc: freebsd-current@freebsd.org cc: julian@elischer.org cc: kris@obsecurity.org Subject: Re: GCC 4.0 [Re: FreeBSD 6 is coming too fast] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 25 Apr 2005 14:49:51 -0000 Kirill Ponomarew wrote: > On Mon, Apr 25, 2005 at 08:05:14AM -0600, Scott Long wrote: > >>Well, I'd caution against jumping into GCC 4.0 just because of the >>claims of 25% speed improvement. That's about the single worst reason >>to do it. But if you're interested in moving the technology forward, >>I'd happily encourage you. The changed language constructs are the big >>problem (extern struct foo bar[]; is no longer valid) since you not only >>need to sweep the FreeBSD tree for them, you also need to sweep the >>ports tree. I have mixed feeling on the value of GCC making sloppy >>language extentions available for years and then suddenly revoking them, >>and I know others that have been affected by 4.0 aren't terribly happy >>either. > > > Well. if we're going to import it, it should be tested on pointyhat > first. IIRC Kris already run tests for some pre 4.0 versions. > > -Kirill Yes, that is a step, one of many, in porting a new compiler. So, if people want it done, there needs to be less hand-waving and more typing. Scott From owner-freebsd-current@FreeBSD.ORG Mon Apr 25 14:49:53 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EA34216A4F1 for ; Mon, 25 Apr 2005 14:49:53 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7AFC143D46 for ; Mon, 25 Apr 2005 14:49:53 +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.3/8.13.3) with ESMTP id j3PEsY2A004227; Mon, 25 Apr 2005 08:54:35 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <426D02C0.1030708@samsco.org> Date: Mon, 25 Apr 2005 08:46:24 -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: Kirill Ponomarew References: <6.2.1.2.0.20050424204611.072105a0@64.7.153.2> <20050425010242.GA44110@xor.obsecurity.org> <6.2.1.2.0.20050424210422.03d22990@64.7.153.2> <20050425014453.GA59981@xor.obsecurity.org> <426C6B1D.3040704@elischer.org> <20050425061459.GA33247@xor.obsecurity.org> <20050425062106.GB91852@voodoo.oberon.net> <426CF3DE.4000409@samsco.org> <20050425160146.4795fe1b.flynn@energyhq.es.eu.org> <426CF91A.8060907@samsco.org> <20050425144259.GL91852@voodoo.oberon.net> In-Reply-To: <20050425144259.GL91852@voodoo.oberon.net> 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: current@freebsd.org cc: mike@sentex.net cc: freebsd-current@freebsd.org cc: julian@elischer.org cc: kris@obsecurity.org Subject: Re: GCC 4.0 [Re: FreeBSD 6 is coming too fast] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 25 Apr 2005 14:49:54 -0000 Kirill Ponomarew wrote: > On Mon, Apr 25, 2005 at 08:05:14AM -0600, Scott Long wrote: > >>Well, I'd caution against jumping into GCC 4.0 just because of the >>claims of 25% speed improvement. That's about the single worst reason >>to do it. But if you're interested in moving the technology forward, >>I'd happily encourage you. The changed language constructs are the big >>problem (extern struct foo bar[]; is no longer valid) since you not only >>need to sweep the FreeBSD tree for them, you also need to sweep the >>ports tree. I have mixed feeling on the value of GCC making sloppy >>language extentions available for years and then suddenly revoking them, >>and I know others that have been affected by 4.0 aren't terribly happy >>either. > > > Well. if we're going to import it, it should be tested on pointyhat > first. IIRC Kris already run tests for some pre 4.0 versions. > > -Kirill Yes, that is a step, one of many, in porting a new compiler. So, if people want it done, there needs to be less hand-waving and more typing. Scott From owner-freebsd-current@FreeBSD.ORG Mon Apr 25 14:52: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 CA0D016A4CE; Mon, 25 Apr 2005 14:52:18 +0000 (GMT) Received: from voodoo.oberon.net (voodoo.oberon.net [212.118.165.100]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7E58043D54; Mon, 25 Apr 2005 14:52:18 +0000 (GMT) (envelope-from krion@voodoo.oberon.net) Received: from krion by voodoo.oberon.net with local (Exim 4.50 (FreeBSD)) id 1DQ4wQ-0006fk-FW; Mon, 25 Apr 2005 16:52:06 +0200 Date: Mon, 25 Apr 2005 16:52:06 +0200 From: Kirill Ponomarew To: Scott Long Message-ID: <20050425145206.GM91852@voodoo.oberon.net> References: <6.2.1.2.0.20050424204611.072105a0@64.7.153.2> <20050425010242.GA44110@xor.obsecurity.org> <6.2.1.2.0.20050424210422.03d22990@64.7.153.2> <20050425014453.GA59981@xor.obsecurity.org> <426C6B1D.3040704@elischer.org> <20050425061459.GA33247@xor.obsecurity.org> <20050425062106.GB91852@voodoo.oberon.net> <426CF3DE.4000409@samsco.org> <20050425144108.GK91852@voodoo.oberon.net> <426D0252.5050805@samsco.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <426D0252.5050805@samsco.org> X-NCC-Regid: de.oberon X-NIC-HDL: KP869-RIPE Keywords: 579279786 cc: current@freebsd.org cc: Kris Kennaway cc: freebsd-current@freebsd.org cc: Julian Elischer cc: Mike Tancsa Subject: Re: FreeBSD 6 is coming too fast X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 25 Apr 2005 14:52:19 -0000 On Mon, Apr 25, 2005 at 08:44:34AM -0600, Scott Long wrote: > >No, I'm not going to do it because of lack of knowledge, there are > >people who have more experience with it than me. > > > Well, as I said in another email, switching to GCC 4 just because of > dubious "25% faster" (faster at what? compiling? resulting generated > code? crashing?) claims in the changelog is not a terribly good > reason =-) 25% faster to compile the code, not running it. > It seems that every time GCC claims to get "faster", our > buildworld times increase by 10%. Maybe the generated code is > better and faster, but it's no secret that gcc spends a lot more > CPU cycles on code genreation and optimization than it did in the > 2.x series. Note also that the GCC 4.0 changelog mentions that > the -O0 flag is faster; that's wonderful, but has no practical > value to real people. -Kirill From owner-freebsd-current@FreeBSD.ORG Mon Apr 25 14:52: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 CA0D016A4CE; Mon, 25 Apr 2005 14:52:18 +0000 (GMT) Received: from voodoo.oberon.net (voodoo.oberon.net [212.118.165.100]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7E58043D54; Mon, 25 Apr 2005 14:52:18 +0000 (GMT) (envelope-from krion@voodoo.oberon.net) Received: from krion by voodoo.oberon.net with local (Exim 4.50 (FreeBSD)) id 1DQ4wQ-0006fk-FW; Mon, 25 Apr 2005 16:52:06 +0200 Date: Mon, 25 Apr 2005 16:52:06 +0200 From: Kirill Ponomarew To: Scott Long Message-ID: <20050425145206.GM91852@voodoo.oberon.net> References: <6.2.1.2.0.20050424204611.072105a0@64.7.153.2> <20050425010242.GA44110@xor.obsecurity.org> <6.2.1.2.0.20050424210422.03d22990@64.7.153.2> <20050425014453.GA59981@xor.obsecurity.org> <426C6B1D.3040704@elischer.org> <20050425061459.GA33247@xor.obsecurity.org> <20050425062106.GB91852@voodoo.oberon.net> <426CF3DE.4000409@samsco.org> <20050425144108.GK91852@voodoo.oberon.net> <426D0252.5050805@samsco.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <426D0252.5050805@samsco.org> X-NCC-Regid: de.oberon X-NIC-HDL: KP869-RIPE Keywords: 579279786 cc: current@freebsd.org cc: Kris Kennaway cc: freebsd-current@freebsd.org cc: Julian Elischer cc: Mike Tancsa Subject: Re: FreeBSD 6 is coming too fast X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 25 Apr 2005 14:52:19 -0000 On Mon, Apr 25, 2005 at 08:44:34AM -0600, Scott Long wrote: > >No, I'm not going to do it because of lack of knowledge, there are > >people who have more experience with it than me. > > > Well, as I said in another email, switching to GCC 4 just because of > dubious "25% faster" (faster at what? compiling? resulting generated > code? crashing?) claims in the changelog is not a terribly good > reason =-) 25% faster to compile the code, not running it. > It seems that every time GCC claims to get "faster", our > buildworld times increase by 10%. Maybe the generated code is > better and faster, but it's no secret that gcc spends a lot more > CPU cycles on code genreation and optimization than it did in the > 2.x series. Note also that the GCC 4.0 changelog mentions that > the -O0 flag is faster; that's wonderful, but has no practical > value to real people. -Kirill From owner-freebsd-current@FreeBSD.ORG Mon Apr 25 15:14: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 9825416A4CE for ; Mon, 25 Apr 2005 15:14:44 +0000 (GMT) Received: from pun.isi.edu (pun.isi.edu [128.9.160.150]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1AED443D58 for ; Mon, 25 Apr 2005 15:14:44 +0000 (GMT) (envelope-from faber@pun.isi.edu) Received: from pun.isi.edu (localhost [127.0.0.1]) by pun.isi.edu (8.13.3/8.13.1) with ESMTP id j3PFEh1L002881; Mon, 25 Apr 2005 08:14:43 -0700 (PDT) (envelope-from faber@pun.isi.edu) Received: (from faber@localhost) by pun.isi.edu (8.13.3/8.13.1/Submit) id j3PFEhuv002878; Mon, 25 Apr 2005 08:14:43 -0700 (PDT) (envelope-from faber) Date: Mon, 25 Apr 2005 08:14:43 -0700 From: Ted Faber To: Randy Bush Message-ID: <20050425151443.GA1523@pun.isi.edu> References: <17001.42481.325920.113852@roam.psg.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="FL5UXtIhxfXey3p5" Content-Disposition: inline In-Reply-To: <17001.42481.325920.113852@roam.psg.com> User-Agent: Mutt/1.4.2.1i X-url: http://www.isi.edu/~faber cc: FreeBSD Current Subject: Re: disk freeze? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 25 Apr 2005 15:14:44 -0000 --FL5UXtIhxfXey3p5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Apr 22, 2005 at 03:33:37PM -1000, Randy Bush wrote: > FreeBSD foo.bar.org 6.0-CURRENT FreeBSD 6.0-CURRENT #22: Thu Apr 21 19:09:22 GMT 2005 root@foo.bar.org:/usr/obj/usr/src/sys/FOO i386 > > locks up where it will echo typing on console or ssh, but hit CR and that > session locks. i.e. probably some locked disk issue > > did manage to get a reboot command in > > Syncing disks, vnodes remaining...2 2 ipfw: pullup failed > 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 timed out > Syncing disks, buffers remaining... 24 24 24 24 24 24 24 1 24 24 1 24 24 24 1 24 1 24 24 1 24 1 24 1 24 24 1 24 1 > Giving up on 24 buffers > Uptime: 1d5h8m13s > Shutting down ACPI > Rebooting... This seems to be my week for "me,too" ing Randy, but I'm seeing similar hard lockups. The machine locks to the point where it won't hear the soft power switch - I have to yank the plug out to reboot it. Needless to say, this is really annoying. I did come in this morning, cvsup a new kernel and make & install it (no lockups yet, but it's only been running a few minutes). When I rebooted after make kernel, I got a lockup on reboot (!) and a message indicating that one thread was not a sole owner of a lock. (Sorry, I didn't copy the text verbatim). And again a hard lock up to the pull the plug out of the machine stage, though there was a panic and an attempt to rebbot the machine. It seems to happen more frequently on my desktop which NFS mounts most of its filesystems (with -L). All kinds of configs, etc, available on request. I'm not set up for dumps or debugging, but I can get set up if it helps. -- Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG --FL5UXtIhxfXey3p5 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFCbQljaUz3f+Zf+XsRAtceAJ0Ssan9Cwi2VdzEG2OzxRdMddz5wwCeK0EV ZXcGvFGStuezTyw/l/Xzga8= =6JjN -----END PGP SIGNATURE----- --FL5UXtIhxfXey3p5-- From owner-freebsd-current@FreeBSD.ORG Mon Apr 25 15:19: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 4F4DE16A4CE for ; Mon, 25 Apr 2005 15:19:01 +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 01A2543D46 for ; Mon, 25 Apr 2005 15:19:01 +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 1DQ5MS-000FUi-51; Mon, 25 Apr 2005 18:19:00 +0300 X-Mailer: exmh version 2.7.0 06/18/2004 with nmh-1.0.4 To: Kirill Ponomarew In-reply-to: Your message of Mon, 25 Apr 2005 16:52:06 +0200 . Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 25 Apr 2005 18:19:00 +0300 From: Danny Braniss Message-ID: cc: current@freebsd.org Subject: Re: FreeBSD 6 is coming too fast X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 25 Apr 2005 15:19:01 -0000 > On Mon, Apr 25, 2005 at 08:44:34AM -0600, Scott Long wrote: > > >No, I'm not going to do it because of lack of knowledge, there are > > >people who have more experience with it than me. > > > > > Well, as I said in another email, switching to GCC 4 just because of > > dubious "25% faster" (faster at what? compiling? resulting generated > > code? crashing?) claims in the changelog is not a terribly good > > reason =-) > > 25% faster to compile the code, not running it. so that closes the argument! i can do a makeworld in about 25 minutes, cutting it down by 6 minutes will not make any real difference, but it will take much longer to recode all the 'usupported features'. if you have an application that takes hours to compile, then please, go ahead and use GCC 4. my 5c, danny From owner-freebsd-current@FreeBSD.ORG Mon Apr 25 15:26: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 BAEA616A4CE for ; Mon, 25 Apr 2005 15:26:48 +0000 (GMT) Received: from voodoo.oberon.net (voodoo.oberon.net [212.118.165.100]) by mx1.FreeBSD.org (Postfix) with ESMTP id 78C8943D66 for ; Mon, 25 Apr 2005 15:26:48 +0000 (GMT) (envelope-from krion@voodoo.oberon.net) Received: from krion by voodoo.oberon.net with local (Exim 4.50 (FreeBSD)) id 1DQ5U0-0006rJ-Bi; Mon, 25 Apr 2005 17:26:48 +0200 Date: Mon, 25 Apr 2005 17:26:48 +0200 From: Kirill Ponomarew To: Danny Braniss Message-ID: <20050425152648.GB25681@voodoo.oberon.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-NCC-Regid: de.oberon X-NIC-HDL: KP869-RIPE cc: current@freebsd.org Subject: Re: FreeBSD 6 is coming too fast X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 25 Apr 2005 15:26:48 -0000 On Mon, Apr 25, 2005 at 06:19:00PM +0300, Danny Braniss wrote: > > On Mon, Apr 25, 2005 at 08:44:34AM -0600, Scott Long wrote: > > > >No, I'm not going to do it because of lack of knowledge, there are > > > >people who have more experience with it than me. > > > > > > > Well, as I said in another email, switching to GCC 4 just because of > > > dubious "25% faster" (faster at what? compiling? resulting generated > > > code? crashing?) claims in the changelog is not a terribly good > > > reason =-) > > > > 25% faster to compile the code, not running it. > > so that closes the argument! i can do a makeworld in about 25 minutes, cutting > it down by 6 minutes will not make any real difference, but it will take > much longer to recode all the 'usupported features'. if you have an > application that takes hours to compile, then please, go ahead and use GCC 4. Do not forget about pointyhat which compiles a tons of ports. Switching it to gcc-4.0 would decrease builds time, and it's not a bad idea IMHO. But since I'm not going to handle it, I better shut up and let another people take decision. -Kirill From owner-freebsd-current@FreeBSD.ORG Mon Apr 25 16:05: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 C221216A4CE for ; Mon, 25 Apr 2005 16:05:08 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id ED1DE43D1D for ; Mon, 25 Apr 2005 16:05:05 +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.3/8.13.3) with ESMTP id j3PG9dGj004700; Mon, 25 Apr 2005 10:09:39 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <426D1459.1050504@samsco.org> Date: Mon, 25 Apr 2005 10:01: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: =?ISO-8859-1?Q?K=F6vesd=E1n_G=E1bor?= References: <20050424175543.71041.qmail@web51805.mail.yahoo.com> <20050424151517.O68772@lexi.siliconlandmark.com> <3822.216.177.243.38.1114385370.localmail@webmail.dnswatch.com> <20050425000459.GA28667@xor.obsecurity.org> <6.2.1.2.0.20050424204611.072105a0@64.7.153.2> <20050425010242.GA44110@xor.obsecurity.org> <6.2.1.2.0.20050424210422.03d22990@64.7.153.2> <20050425014453.GA59981@xor.obsecurity.org> <426C6B1D.3040704@elischer.org> <20050425061459.GA33247@xor.obsecurity.org> <20050425062106.GB91852@voodoo.oberon.net> <426CF3DE.4000409@samsco.org> <20050425160146.4795fe1b.flynn@energyhq.es.eu.org> <426D14A1.9080707@t-hosting.hu> In-Reply-To: <426D14A1.9080707@t-hosting.hu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit 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: mike@sentex.net cc: freebsd-current@freebsd.org cc: julian@elischer.org cc: krion@voodoo.oberon.net cc: kris@obsecurity.org Subject: Re: FreeBSD 6 is coming too fast X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 25 Apr 2005 16:05:08 -0000 Kövesdán Gábor wrote: > >> >> Definitely not for 6.0, and I usually avoid .0 releases on critical >> software, but nonetheless it would interesting setting a tinderbox, >> launch a buildworld process with gcc40 and see where/if it breaks. I >> have a spare k6-2 box I could setup for that task. >> >> >> > What about installing gcc40 port to an alternative location and testing > it with changing the CC, CFLAGS and CXXFLAGS macros so that make uses > that version of gcc? I'm compiling the new gcc now, I'm interested in > the result... > There is already /usr/ports/lang/gcc40. It's possible to substitute it into a 'buildworld' by re-assigning the CC variable in the shell. Scott From owner-freebsd-current@FreeBSD.ORG Mon Apr 25 16:10: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 9042916A4CE for ; Mon, 25 Apr 2005 16:10:30 +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 0904643D41 for ; Mon, 25 Apr 2005 16:10:30 +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 j3PGALfQ060355; Mon, 25 Apr 2005 09:10:21 -0700 (PDT) (envelope-from marcel@xcllnt.net) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <388c417aa38789ffd72114194b7facc3@xcllnt.net> Content-Transfer-Encoding: 7bit From: Marcel Moolenaar Date: Mon, 25 Apr 2005 09:10:20 -0700 To: Danny Braniss X-Mailer: Apple Mail (2.622) cc: current@freebsd.org Subject: Re: serial/ether console & ramblings X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 25 Apr 2005 16:10:30 -0000 On Apr 25, 2005, at 5:01 AM, Danny Braniss wrote: > So here are some of my quesions: > o - is there some standard? ok, refrase, are there some > standards? > o - any WIP?, i'm checking out Robert Watson's ethercons > o - any great ideas? I assume you're using sio(4) as the serial driver? Try using uart(4) and see if you have the same problems. If yes, then the problem is somewhat driver independent and any alternative to a serial console may exhibit the same problems. -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net From owner-freebsd-current@FreeBSD.ORG Mon Apr 25 16:13: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 981B016A4CE for ; Mon, 25 Apr 2005 16:13:19 +0000 (GMT) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6E8AC43D2D for ; Mon, 25 Apr 2005 16:13:19 +0000 (GMT) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) j3PGDBcM003077; Mon, 25 Apr 2005 09:13:11 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost)j3PGDBiA003076; Mon, 25 Apr 2005 09:13:11 -0700 (PDT) (envelope-from sgk) Date: Mon, 25 Apr 2005 09:13:11 -0700 From: Steve Kargl To: Kirill Ponomarew Message-ID: <20050425161311.GA3008@troutmask.apl.washington.edu> References: <20050425152648.GB25681@voodoo.oberon.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050425152648.GB25681@voodoo.oberon.net> User-Agent: Mutt/1.4.2.1i cc: current@freebsd.org Subject: Re: FreeBSD 6 is coming too fast X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 25 Apr 2005 16:13:19 -0000 On Mon, Apr 25, 2005 at 05:26:48PM +0200, Kirill Ponomarew wrote: > > Do not forget about pointyhat which compiles a tons of ports. Switching > it to gcc-4.0 would decrease builds time, and it's not a bad idea IMHO. > Any port that uses Fortran will be broken by a blanket switch to gcc-4.0.0. g77 is no longer a GCC frontend. Gfortran, which replaces g77, can handle somewhere around 95% of the Fortran 77 language and around 90% of the Fortran 95 language. If you want to try gcc-4.0.0, download the tar ball and do configure --prefix=/usr/local --program-suffix=4 languages=c,c++ Add CC=gcc4 to C++=g++4 to make.conf and try building a few ports. -- Steve From owner-freebsd-current@FreeBSD.ORG Mon Apr 25 16:20: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 1F7EB16A4CE for ; Mon, 25 Apr 2005 16:20:03 +0000 (GMT) Received: from hobbiton.shire.net (hobbiton.shire.net [166.70.252.250]) by mx1.FreeBSD.org (Postfix) with ESMTP id CA9C143D1F for ; Mon, 25 Apr 2005 16:20:02 +0000 (GMT) (envelope-from chad@shire.net) Received: from [67.161.222.227] (helo=[192.168.99.232]) by hobbiton.shire.net with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.43) id 1DQ6JV-0007wN-20; Mon, 25 Apr 2005 10:20:02 -0600 In-Reply-To: <1252.216.177.243.38.1114426444.localmail@webmail.dnswatch.com> References: <20050424175543.71041.qmail@web51805.mail.yahoo.com><20050424151517.O68772@lexi.siliconlandmark.com><3822.216.177.243.38.1114385370.localmail@webmail.dnswatch.com> <426C328A.9060606@alumni.rice.edu> <1252.216.177.243.38.1114426444.localmail@webmail.dnswatch.com> Mime-Version: 1.0 (Apple Message framework v728) X-Priority: 3 Message-Id: <9C139C36-3EBC-4714-9DFD-D95F69006C51@shire.net> From: "Chad Leigh -- Shire.Net LLC" Date: Mon, 25 Apr 2005 10:19:59 -0600 To: /dev/null X-Mailer: Apple Mail (2.728) X-SA-Exim-Connect-IP: 67.161.222.227 X-SA-Exim-Mail-From: chad@shire.net Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.0 (2004-09-13) on hobbiton.shire.net X-Spam-Status: No, score=-0.1 required=5.0 tests=AWL,BAYES_50 autolearn=disabled version=3.0.0 X-Spam-Level: X-SA-Exim-Version: 4.1+cvs (built Mon, 23 Aug 2004 08:44:05 -0700) X-SA-Exim-Scanned: Yes (on hobbiton.shire.net) cc: FreeBSD Current Subject: Re: FreeBSD 6 is coming too fast X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 25 Apr 2005 16:20:03 -0000 On Apr 25, 2005, at 4:54 AM, /dev/null wrote: > Of all things, it was the AHA-2940 that killed > the whole thing. It just kept polling and resetting the drives. Never > brought 'em up. So now Win2k Advanced Server lives on it. GRRRRRRR >:( > Anyway, don't get me started. ;) > But don't get me wrong. I'm truly greatful for your answer - REALLY. > I'm actually waiting for SIX to level out so I can take another > stab at > it and remove another copy of Winblows. This time I'll try to take > advantage of the UDMA 100 on the SMP board, and when the AHA-2940UW > drivers start working on an SMP (in 6?), I can add the SCSI devices > then. I don't have it running now, as I am using am Adaptec 2200S RAID, but for a LONG time I had SMP FreeBSD with the 2940UW without issue and problem. In fact, I just switched off the last such box in January, which had a 2100S RAID for the main disks and a 2940UW for the swap disk. Maybe your card was flaky or maybe it was an OEM specific version? Chad --- Chad Leigh -- Shire.Net LLC Your Web App and Email hosting provider chad@shire.net From owner-freebsd-current@FreeBSD.ORG Mon Apr 25 16:23: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 5E24816A4CE for ; Mon, 25 Apr 2005 16:23:54 +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 F376243D55 for ; Mon, 25 Apr 2005 16:23:53 +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 j3PGNhZw060439; Mon, 25 Apr 2005 09:23:43 -0700 (PDT) (envelope-from marcel@xcllnt.net) In-Reply-To: <20050425145206.GM91852@voodoo.oberon.net> References: <6.2.1.2.0.20050424204611.072105a0@64.7.153.2> <20050425010242.GA44110@xor.obsecurity.org> <6.2.1.2.0.20050424210422.03d22990@64.7.153.2> <20050425014453.GA59981@xor.obsecurity.org> <426C6B1D.3040704@elischer.org> <20050425061459.GA33247@xor.obsecurity.org> <20050425062106.GB91852@voodoo.oberon.net> <426CF3DE.4000409@samsco.org> <20050425144108.GK91852@voodoo.oberon.net> <426D0252.5050805@samsco.org> <20050425145206.GM91852@voodoo.oberon.net> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <657be6bca0955ea1d1571a92f074e43f@xcllnt.net> Content-Transfer-Encoding: 7bit From: Marcel Moolenaar Date: Mon, 25 Apr 2005 09:23:42 -0700 To: Kirill Ponomarew X-Mailer: Apple Mail (2.622) cc: current@freebsd.org cc: Mike Tancsa cc: Julian Elischer cc: Kris Kennaway Subject: Re: FreeBSD 6 is coming too fast X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 25 Apr 2005 16:23:54 -0000 On Apr 25, 2005, at 7:52 AM, Kirill Ponomarew wrote: > On Mon, Apr 25, 2005 at 08:44:34AM -0600, Scott Long wrote: >>> No, I'm not going to do it because of lack of knowledge, there are >>> people who have more experience with it than me. >>> >> Well, as I said in another email, switching to GCC 4 just because of >> dubious "25% faster" (faster at what? compiling? resulting generated >> code? crashing?) claims in the changelog is not a terribly good >> reason =-) > > 25% faster to compile the code, not running it. Not to pick on you, Kirill, but rather in general: That entirely depends on the optimization level and the configuration. I measured a small degradation (<5%) at -O3 on ia64. So, let's find out how the 25% compile-time performance improvement was achieved before we use it as an argument in any discussion, shall we? -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net From owner-freebsd-current@FreeBSD.ORG Mon Apr 25 16:26: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 9D22916A4CE for ; Mon, 25 Apr 2005 16:26:26 +0000 (GMT) Received: from mortis.over-yonder.net (adsl-19-150-252.jan.bellsouth.net [68.19.150.252]) by mx1.FreeBSD.org (Postfix) with ESMTP id 38A4C43D60 for ; Mon, 25 Apr 2005 16:26:26 +0000 (GMT) (envelope-from fullermd@over-yonder.net) Received: by mortis.over-yonder.net (Postfix, from userid 100) id 076DF20F1F; Mon, 25 Apr 2005 11:26:24 -0500 (CDT) Date: Mon, 25 Apr 2005 11:26:24 -0500 From: "Matthew D. Fuller" To: "Chad Leigh -- Shire.Net LLC" Message-ID: <20050425162624.GD96110@over-yonder.net> References: <426C328A.9060606@alumni.rice.edu> <1252.216.177.243.38.1114426444.localmail@webmail.dnswatch.com> <9C139C36-3EBC-4714-9DFD-D95F69006C51@shire.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9C139C36-3EBC-4714-9DFD-D95F69006C51@shire.net> X-Editor: vi X-OS: FreeBSD User-Agent: Mutt/1.5.9i-fullermd.2 cc: /dev/null cc: FreeBSD Current Subject: Re: FreeBSD 6 is coming too fast X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 25 Apr 2005 16:26:26 -0000 On Mon, Apr 25, 2005 at 10:19:59AM -0600 I heard the voice of Chad Leigh -- Shire.Net LLC, and lo! it spake thus: > On Apr 25, 2005, at 4:54 AM, /dev/null wrote: > >Of all things, it was the AHA-2940 that killed the whole thing. > > I don't have it running now, as I am using am Adaptec 2200S RAID, > but for a LONG time I had SMP FreeBSD with the 2940UW without issue > and problem. In fact, I just switched off the last such box in > January, which had a 2100S RAID for the main disks and a 2940UW for > the swap disk. > > Maybe your card was flaky or maybe it was an OEM specific version? I second the motion. I've got 3 2940UW's (well, technically one's an onboard 7880) in this box, which is currently running RELENG_5 from January, but was originally installed with an early 4.0-CURRENT. The controllers have been humming along fine the whole way. -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. From owner-freebsd-current@FreeBSD.ORG Mon Apr 25 16:29: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 CB57916A4CE for ; Mon, 25 Apr 2005 16:29:16 +0000 (GMT) Received: from avout3.midco.net (avout3.midco.net [24.220.0.102]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5463B43D39 for ; Mon, 25 Apr 2005 16:29:16 +0000 (GMT) (envelope-from pmes@bis.midco.net) Received: (qmail 26958 invoked by uid 1009); 25 Apr 2005 16:29:15 -0000 Received: from pmes@bis.midco.net by avout3 by uid 1003 with qmail-scanner-1.22 (f-prot: 4.4.2/3.14.11. Clear:RC:1(24.220.122.106):. Processed in 0.010585 secs); 25 Apr 2005 16:29:15 -0000 X-Qmail-Scanner-Mail-From: pmes@bis.midco.net via avout3 X-Qmail-Scanner: 1.22 (Clear:RC:1(24.220.122.106):. Processed in 0.010585 secs) Received: from host-106-122-220-24.midco.net (HELO [10.0.0.3]) ([24.220.122.106]) (envelope-sender ) by avout3.midco.net (qmail-ldap-1.03) with SMTP for ; 25 Apr 2005 16:29:15 -0000 Mime-Version: 1.0 (Apple Message framework v622) In-Reply-To: References: Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <0da2331a2bcd865848709e7c8bbf05b1@bis.midco.net> Content-Transfer-Encoding: 7bit From: Peter Schultz Date: Mon, 25 Apr 2005 11:29:14 -0500 To: current@freebsd.org X-Mailer: Apple Mail (2.622) Subject: Re: FreeBSD 6 is coming too fast X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 25 Apr 2005 16:29:16 -0000 On Apr 25, 2005, at 10:19 AM, Danny Braniss wrote: >> On Mon, Apr 25, 2005 at 08:44:34AM -0600, Scott Long wrote: >>>> No, I'm not going to do it because of lack of knowledge, there are >>>> people who have more experience with it than me. >>>> >>> Well, as I said in another email, switching to GCC 4 just because of >>> dubious "25% faster" (faster at what? compiling? resulting >>> generated >>> code? crashing?) claims in the changelog is not a terribly good >>> reason =-) >> >> 25% faster to compile the code, not running it. > > so that closes the argument! i can do a makeworld in about 25 minutes, > cutting > it down by 6 minutes will not make any real difference > I have a seven year old dual PII 350 machine here, and since the switch to 6-CURRENT I have seen *significant* increases in performance. Great job everyone! That being said, compiling FreeBSD in 25 minutes is exactly what's wrong and in my opinion a big reason the thread was started. Moore's Law is nifty and all but it doesn't help create excellent software. I say all FreeBSD developers should be forcing themselves to run old hardware so they're compelled to write better/faster code. Of course the slow hardware isn't necessary, but it'll prompt coders to go back to the matter at hand instead of just running bad code brute force with massive processors. Pete... From owner-freebsd-current@FreeBSD.ORG Mon Apr 25 17:04: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 9E8AA16A4CE for ; Mon, 25 Apr 2005 17:04:06 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id C335443D5C for ; Mon, 25 Apr 2005 17:04:05 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 11194 invoked from network); 25 Apr 2005 17:05:11 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.53]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 25 Apr 2005 17:05:11 -0000 Message-ID: <426D2307.97D15253@freebsd.org> Date: Mon, 25 Apr 2005 19:04:07 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Matthew Sullivan References: <426426AE.2060406@uq.edu.au><42663EA1.3020409@uq.edu.au> <20050424150211.GA87520@walton.maths.tcd.ie> <426BC78A.3E56D99B@freebsd.org> <426C1600.106@uq.edu.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: David Malone cc: freebsd-current@freebsd.org Subject: Re: DF (Don't frag) issues X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 25 Apr 2005 17:04:06 -0000 Matthew Sullivan wrote: > > As David suggested my config is shown here: > > http://lists.freebsd.org/pipermail/freebsd-current/2005-April/048980.html Ok, I see. Do you still have this setup at your disposal? I need to know the suggested MTU value in the ICMP packet. Best you look at it with ethereal. This will help a lot to get ahold of the bug. > After talking with people I see 2 issues..... > > 1/ The bug is being triggered when the incoming 'need frag' ICMP message > doesn't have a suggested value. If it comes from a FreeBSD box is certainly does have a suggested value but tcpdump does not show it. We need to know what it put in there to be able to figure out what is going wrong. > This ICMP message is being generated by 'stealth.sorbs.net' which is a > FreeBSD 5.3 p9 server running FAST_IPSEC (no crypto card yet - waiting > for delivery), and otherwise pretty standard kernel. As for fast forwarding: > > net.inet.ip.fastforwarding: 0 That's fine. > 2/ The bug itself is also a problem, as it cannot be guarenteed that the > host returning the ICMP 'need frag' will fill in a suggested mtu, so > that also needs to be looked at (but I guess you know that already ;-)) I'm testing a fix right now. Unfortunatly the whole situation is a lot more complex than thought at first. While stepping through the code I found some other incorrect assumptions. -- Andre From owner-freebsd-current@FreeBSD.ORG Mon Apr 25 17:15:28 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 618) id 7EF8B16A4D3; Mon, 25 Apr 2005 17:15:28 +0000 (GMT) To: freebsd-current@freebsd.org, freebsd-hardware@freebsd.org Date: Mon, 25 Apr 2005 17:15:28 +0000 (GMT) X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: <20050425171528.7EF8B16A4D3@hub.freebsd.org> From: wpaul@FreeBSD.ORG (Bill Paul) Subject: Too Evil, Too Furious X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 25 Apr 2005 17:15:28 -0000 Having reached yet another milestone of sorts in Project Evil develpment, it's time once again to concentrate on cleaning up some of the rough spots. This means fixing problems with cards/drivers that don't quite work right. Naturally, all the cards/drivers that people are having issues with are ones that I don't have. Now, it doesn't do any good to just tell me that your card/driver isn't working right: to fix the problem, whatever it is, I need to experiment, and for that I need access to the hardware. No, I won't send you patches to test. No, there isn't any debugging information you can give me via e-mail that will help. No, I'm not kidding. The cards that I can't seem to get my hands on are: - Marvell wireless -- supposedly D-Link used this on a card called the DWL-G510, but only on the first revision. The second board revision uses an Atheros chipset, which is already supported. Unfortunately, aside from this one PCI card, this chipset tends to only show up as a built-in component on motherboards or laptops, which makes it hard for me to just go out and get one. - Inprocomm wireless -- this chipset has been reported to work on i386, but there's also an amd64 driver, and to date nobody has reported trying it with FreeBSD/amd64. - AirGo Pre-N wireless -- there's apparently a Belkin cardbus card (F5D8010?) that uses this one - RayLink RT2500 wireless -- this one shows up on some PCI cards, but I haven't had any luck finding one locally yet The developers of the Marvell and Inprocomm drivers apparently chose to use Microsoft structured exception handling (*sigh*), which is interesting in that these devices have drivers for amd64 as well as i386. From what I've read, Microsoft's amd64 implementation of SEH should not cause any problems for Project Evil on amd64, but I haven't personally tested it since the only card I have with an amd64 driver is a Broadcom one. My problems with finding these cards locally are: - In-store selections around here really suck - In many cases, the chips appear on only certain revs of a given card, and either I can't find that rev, or the boxes aren't well enough marked for me to figure out just which rev is inside - Some of them show up most often as built-in devices, and I can't go out and buy a new laptop or motherboard just to test one network interface If you have one of these cards and would like to loan or donate it, we at Project Evil Laboratories would be most appreciative. If you don't want to part with your hardware, you can still help by giving me remote access to a system with the card installed. Note that just giving me a shell really doesn't help: in order to experiment, I need to be able to load, test and unload kernel modules, which requires superuser access. The ideal setup would be to use a serial console, since in some cases it may be necessary to poke around with the kernel debugger. Don't consider this unless you have a scratch box lying around that you can afford to have bounced a few times, because I guarantee you I will crash the thing a few times before I get it to work. Lastly, if you can't do either of these things, you can still help by providing some important information. If you have one of these cards, tell me where you got it! Tell me what manufacturer and model number it is, but also carefully inspect the box it came in and tell me _ANY_ identifying markings on it that will help me distinguish it from all the other cards out there. Very often, card distributors will sell two different cards with the same part number. (I own no less than 4 cards called the "LinkSys LNE100TX," all of which have different chipsets on them.) D-Link and Linksys are some of the worst offenders in this area. Even worse, most PCI cards now have metal RF shields on them that cover up the chipsets, which makes it impossible to tell what you're getting just by looking at the picture on the box. Look for hardware revision info. Look for firmware revision info. If you can provide a URL to the exact card you got from the place you ordered it, even better. Whatever you do, don't just tell "I have a D-Link model so-and-so." Instead, tell me "I have a D-Link model so-and-so that I ordered from the following URL, and the box has a sticker that says HW rev: B3 FW rev: 2.0." If I have info like this, I can grab a card off a store shelf when I find the right one. Otherwise, I can't take the chance on paying for it only to find out later it uses a chipset I already have. If you want to donate/load a card to Project Evil, you can send it to the following address: Attn: Bill Paul Wind River Systems 500 Wind River Way Alameda, CA. 94501 USA Bill's office phone number: 1 (510) 749-2329 Remember to include a note with your address so that the card can be shipped back to you, and specify how soon you need the card back. All loaned cards will be returned. -Bill -- ============================================================================= -Bill Paul (510) 749-2329 | Senior Engineer, Master of Unix-Fu wpaul@windriver.com | Wind River Systems ============================================================================= you're just BEGGING to face the moose ============================================================================= From owner-freebsd-current@FreeBSD.ORG Mon Apr 25 17:27: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 DA51B16A4D0 for ; Mon, 25 Apr 2005 17:27:26 +0000 (GMT) Received: from sb.santaba.com (sb.santaba.com [207.154.84.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id A84AB43D1F for ; Mon, 25 Apr 2005 17:27:26 +0000 (GMT) (envelope-from jbehl@fastclick.com) Received: from [192.168.3.100] (unknown [205.180.85.193]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sb.santaba.com (Postfix) with ESMTP id 606BF2848C; Mon, 25 Apr 2005 10:27:26 -0700 (PDT) Message-ID: <426D28DB.70600@fastclick.com> Date: Mon, 25 Apr 2005 10:28:59 -0700 From: Jeff Behl User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Anderson References: <426CFA51.3060003@centtech.com> In-Reply-To: <426CFA51.3060003@centtech.com> X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit cc: current@freebsd.org Subject: Re: serial/ether console & ramblings X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 25 Apr 2005 17:27:27 -0000 Eric Anderson wrote: > Danny Braniss wrote: > >> hi, >> I was about to plunge in and 'try' to cleanup the serial console >> stuff, when it downed on me that newer machines are arriving without >> serial >> port! there goes that idea. So USB/serial dongle came to mind, might >> work, but messy, FireWire is not universaly available. >> So, why not serial over ethernet? IPMI 'was' to have solved >> this, but it will (if at all) work on server class MB only, and im still >> looking for a Unix Viewer. >> >> In my case, i have been using the serial console to debug stuff, but >> being of the old school, i try to stay away from debuggers :-), so >> printf and stack trace will do. >> >> So here are some of my quesions: >> o - is there some standard? ok, refrase, are there some >> standards? >> o - any WIP?, i'm checking out Robert Watson's ethercons >> o - any great ideas? > > > There are a couple of ports that seem to try to use IPMI. I haven't > tried them yet though. (sysutils/freeipmi and sysutils/ipmitool). > > I can tell you that being about to do serial over ethernet (and > possibly power cycling) would be incredibly handy. > > Eric > > > NIC drivers have to be made aware of IPMI in order for it to function when a shared NIC is used. This is not the case with the bge driver, at the very least. See: http://lists.freebsd.org/mailman/htdig/freebsd-net/2005-March/thread.html#6725 This is also a very big issue for us and we're considering hiring a contractor to get the relevant parts put into the driver... From owner-freebsd-current@FreeBSD.ORG Mon Apr 25 17:55: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 41FEA16A4CE for ; Mon, 25 Apr 2005 17:55:56 +0000 (GMT) Received: from lakermmtao04.cox.net (lakermmtao04.cox.net [68.230.240.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7E77743D66 for ; Mon, 25 Apr 2005 17:55:55 +0000 (GMT) (envelope-from conrads@cox.net) Received: from dolphin.local.net ([68.11.70.216]) by lakermmtao04.cox.net (InterMail vM.6.01.04.00 201-2131-118-20041027) with ESMTP <20050425175551.QNCQ20878.lakermmtao04.cox.net@dolphin.local.net>; Mon, 25 Apr 2005 13:55:51 -0400 Received: from dolphin.local.net (conrads@localhost.local.net [127.0.0.1]) by dolphin.local.net (8.13.3/8.13.3) with ESMTP id j3PHtjBi020983; Mon, 25 Apr 2005 12:55:49 -0500 (CDT) (envelope-from conrads@cox.net) Date: Mon, 25 Apr 2005 12:55:45 -0500 From: "Conrad J. Sabatier" To: Andre Guibert de Bruet Message-ID: <20050425125545.0dcbf4ec@dolphin.local.net> In-Reply-To: <20050423161839.P68772@lexi.siliconlandmark.com> References: <20050418232455.2d530890@dolphin.local.net> <5265.1113888748@critter.freebsd.dk> <20050419130048.6e545269@dolphin.local.net> <20050423023605.A68772@lexi.siliconlandmark.com> <20050423135112.63c74617@dolphin.local.net> <20050423161839.P68772@lexi.siliconlandmark.com> X-Mailer: Sylpheed-Claws 1.0.4 (GTK+ 1.2.10; amd64-portbld-freebsd6.0) Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=Multipart_Mon__25_Apr_2005_12_55_45_-0500_nfjSn6y19Y+G31aY cc: freebsd-current@freebsd.org cc: Mathew Kanner Subject: Latest MIDI patchset from Mat X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 25 Apr 2005 17:55:56 -0000 --Multipart_Mon__25_Apr_2005_12_55_45_-0500_nfjSn6y19Y+G31aY Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline On Sat, 23 Apr 2005 16:40:44 -0400 (EDT), Andre Guibert de Bruet wrote: > > I have an emu10k1, so I guess I could give it a spin. Any ideas for > the whereabout of these patches? > > My synth is an S08. I've attached the latest patchset Mat sent me. They *should* apply cleanly to STABLE, but will yield a couple of failed hunks when applied to CURRENT, which are quite simple to fix by hand. Just do the following: cd /usr/src patch -p0 < /path/to/midi2-RELENG_5-mar05.diff Let us know if you need any help. And also, do be sure to let us know if you're successful with these! :-) Thanks! -- Conrad J. Sabatier -- "In Unix veritas" --Multipart_Mon__25_Apr_2005_12_55_45_-0500_nfjSn6y19Y+G31aY Content-Type: application/octet-stream; name=midi2-RELENG_5-mar05.diff Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=midi2-RELENG_5-mar05.diff SW5kZXg6IHN5cy9jb25mL2ttb2QubWsKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQpSQ1MgZmlsZTogL2hvbWUvbmN2cy9z cmMvc3lzL2NvbmYva21vZC5tayx2CnJldHJpZXZpbmcgcmV2aXNpb24gMS4xNjYuMi4xCmRpZmYg LXUgLXIxLjE2Ni4yLjEga21vZC5tawotLS0gc3lzL2NvbmYva21vZC5tawkyNSBGZWIgMjAwNSAy MTo0NTo1NSAtMDAwMAkxLjE2Ni4yLjEKKysrIHN5cy9jb25mL2ttb2QubWsJNSBNYXIgMjAwNSAx NjoyOToxNCAtMDAwMApAQCAtMjk5LDcgKzI5OSw4IEBACiAJZGV2L3VzYi91c2JfaWYubSBpc2Ev aXNhX2lmLm0gXAogCWtlcm4vYnVzX2lmLm0ga2Vybi9jcHVmcmVxX2lmLm0ga2Vybi9kZXZpY2Vf aWYubSBcCiAJbGlia2Vybi9pY29udl9jb252ZXJ0ZXJfaWYubSBvcGVuY3J5cHRvL2NyeXB0b19p Zi5tIFwKLQlwYzk4L3BjOTgvY2FuYnVzX2lmLm0gcGNpL2FncF9pZi5tIHNwYXJjNjQvcGNpL29m d19wY2lfaWYubQorCXBjOTgvcGM5OC9jYW5idXNfaWYubSBwY2kvYWdwX2lmLm0gc3BhcmM2NC9w Y2kvb2Z3X3BjaV9pZi5tIFwKKyAJZGV2L3NvdW5kL21pZGkvbXB1X2lmLm0gZGV2L3NvdW5kL21p ZGkvbXB1Zm9pX2lmLm0gZGV2L3NvdW5kL21pZGkvc3ludGhfaWYubQogCiAuZm9yIF9zcmNzcmMg aW4gJHtNRklMRVN9CiAuZm9yIF9leHQgaW4gYyBoCkluZGV4OiBzeXMvZGV2L3NvdW5kL21pZGkv bWlkaS5jCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT0KUkNTIGZpbGU6IHN5cy9kZXYvc291bmQvbWlkaS9taWRpLmMKZGlm ZiAtTiBzeXMvZGV2L3NvdW5kL21pZGkvbWlkaS5jCi0tLSAvZGV2L251bGwJMSBKYW4gMTk3MCAw MDowMDowMCAtMDAwMAorKysgc3lzL2Rldi9zb3VuZC9taWRpL21pZGkuYwk1IE1hciAyMDA1IDE3 OjA3OjM5IC0wMDAwCkBAIC0wLDAgKzEsMTUxNCBAQAorLyoKKyAqIChjKSAyMDAzIE1hdGhldyBL YW5uZXIKKyAqIAorICogQ29weXJpZ2h0IChjKSAxOTk4IFRoZSBOZXRCU0QgRm91bmRhdGlvbiwg SW5jLgorICogQWxsIHJpZ2h0cyByZXNlcnZlZC4KKyAqCisgKiBUaGlzIGNvZGUgaXMgZGVyaXZl ZCBmcm9tIHNvZnR3YXJlIGNvbnRyaWJ1dGVkIHRvIFRoZSBOZXRCU0QgRm91bmRhdGlvbgorICog YnkgTGVubmFydCBBdWd1c3Rzc29uIChhdWd1c3Rzc0BuZXRic2Qub3JnKS4KKyAqCisgKiBSZWRp c3RyaWJ1dGlvbiBhbmQgdXNlIGluIHNvdXJjZSBhbmQgYmluYXJ5IGZvcm1zLCB3aXRoIG9yIHdp dGhvdXQKKyAqIG1vZGlmaWNhdGlvbiwgYXJlIHBlcm1pdHRlZCBwcm92aWRlZCB0aGF0IHRoZSBm b2xsb3dpbmcgY29uZGl0aW9ucworICogYXJlIG1ldDoKKyAqIDEuIFJlZGlzdHJpYnV0aW9ucyBv ZiBzb3VyY2UgY29kZSBtdXN0IHJldGFpbiB0aGUgYWJvdmUgY29weXJpZ2h0CisgKiAgICBub3Rp Y2UsIHRoaXMgbGlzdCBvZiBjb25kaXRpb25zIGFuZCB0aGUgZm9sbG93aW5nIGRpc2NsYWltZXIu CisgKiAyLiBSZWRpc3RyaWJ1dGlvbnMgaW4gYmluYXJ5IGZvcm0gbXVzdCByZXByb2R1Y2UgdGhl IGFib3ZlIGNvcHlyaWdodAorICogICAgbm90aWNlLCB0aGlzIGxpc3Qgb2YgY29uZGl0aW9ucyBh bmQgdGhlIGZvbGxvd2luZyBkaXNjbGFpbWVyIGluIHRoZQorICogICAgZG9jdW1lbnRhdGlvbiBh bmQvb3Igb3RoZXIgbWF0ZXJpYWxzIHByb3ZpZGVkIHdpdGggdGhlIGRpc3RyaWJ1dGlvbi4KKyAq IDMuIEFsbCBhZHZlcnRpc2luZyBtYXRlcmlhbHMgbWVudGlvbmluZyBmZWF0dXJlcyBvciB1c2Ug b2YgdGhpcyBzb2Z0d2FyZQorICogICAgbXVzdCBkaXNwbGF5IHRoZSBmb2xsb3dpbmcgYWNrbm93 bGVkZ2VtZW50OgorICogICAgICAgIFRoaXMgcHJvZHVjdCBpbmNsdWRlcyBzb2Z0d2FyZSBkZXZl bG9wZWQgYnkgdGhlIE5ldEJTRAorICogICAgICAgIEZvdW5kYXRpb24sIEluYy4gYW5kIGl0cyBj b250cmlidXRvcnMuCisgKiA0LiBOZWl0aGVyIHRoZSBuYW1lIG9mIFRoZSBOZXRCU0QgRm91bmRh dGlvbiBub3IgdGhlIG5hbWVzIG9mIGl0cworICogICAgY29udHJpYnV0b3JzIG1heSBiZSB1c2Vk IHRvIGVuZG9yc2Ugb3IgcHJvbW90ZSBwcm9kdWN0cyBkZXJpdmVkCisgKiAgICBmcm9tIHRoaXMg c29mdHdhcmUgd2l0aG91dCBzcGVjaWZpYyBwcmlvciB3cml0dGVuIHBlcm1pc3Npb24uCisgKgor ICogVEhJUyBTT0ZUV0FSRSBJUyBQUk9WSURFRCBCWSBUSEUgTkVUQlNEIEZPVU5EQVRJT04sIElO Qy4gQU5EIENPTlRSSUJVVE9SUworICogYGBBUyBJUycnIEFORCBBTlkgRVhQUkVTUyBPUiBJTVBM SUVEIFdBUlJBTlRJRVMsIElOQ0xVRElORywgQlVUIE5PVCBMSU1JVEVECisgKiBUTywgVEhFIElN UExJRUQgV0FSUkFOVElFUyBPRiBNRVJDSEFOVEFCSUxJVFkgQU5EIEZJVE5FU1MgRk9SIEEgUEFS VElDVUxBUgorICogUFVSUE9TRSBBUkUgRElTQ0xBSU1FRC4gIElOIE5PIEVWRU5UIFNIQUxMIFRI RSBGT1VOREFUSU9OIE9SIENPTlRSSUJVVE9SUworICogQkUgTElBQkxFIEZPUiBBTlkgRElSRUNU LCBJTkRJUkVDVCwgSU5DSURFTlRBTCwgU1BFQ0lBTCwgRVhFTVBMQVJZLCBPUgorICogQ09OU0VR VUVOVElBTCBEQU1BR0VTIChJTkNMVURJTkcsIEJVVCBOT1QgTElNSVRFRCBUTywgUFJPQ1VSRU1F TlQgT0YKKyAqIFNVQlNUSVRVVEUgR09PRFMgT1IgU0VSVklDRVM7IExPU1MgT0YgVVNFLCBEQVRB LCBPUiBQUk9GSVRTOyBPUiBCVVNJTkVTUworICogSU5URVJSVVBUSU9OKSBIT1dFVkVSIENBVVNF RCBBTkQgT04gQU5ZIFRIRU9SWSBPRiBMSUFCSUxJVFksIFdIRVRIRVIgSU4KKyAqIENPTlRSQUNU LCBTVFJJQ1QgTElBQklMSVRZLCBPUiBUT1JUIChJTkNMVURJTkcgTkVHTElHRU5DRSBPUiBPVEhF UldJU0UpCisgKiBBUklTSU5HIElOIEFOWSBXQVkgT1VUIE9GIFRIRSBVU0UgT0YgVEhJUyBTT0ZU V0FSRSwgRVZFTiBJRiBBRFZJU0VEIE9GIFRIRQorICogUE9TU0lCSUxJVFkgT0YgU1VDSCBEQU1B R0UuCisgKi8KKworIC8qCisgICogUGFydHMgb2YgdGhpcyBmaWxlIHN0YXJ0ZWQgb3V0IGFzIE5l dEJTRDogbWlkaS5jIDEuMzEKKyAgKiBUaGV5IGFyZSBtb3N0bHkgZ29uZS4gIFN0aWxsIHRoZSBt b3N0IG9idmlvdXMgd2lsbCBiZSB0aGUgc3RhdGUKKyAgKiBtYWNoaW5lIG1pZGlfaW4KKyAgKi8K KworI2luY2x1ZGUgPHN5cy9wYXJhbS5oPgorI2luY2x1ZGUgPHN5cy9xdWV1ZS5oPgorI2luY2x1 ZGUgPHN5cy9rZXJuZWwuaD4KKyNpbmNsdWRlIDxzeXMvbG9jay5oPgorI2luY2x1ZGUgPHN5cy9t dXRleC5oPgorI2luY2x1ZGUgPHN5cy9wcm9jLmg+CisjaW5jbHVkZSA8c3lzL3NpZ25hbHZhci5o PgorI2luY2x1ZGUgPHN5cy9jb25mLmg+CisjaW5jbHVkZSA8c3lzL3NlbGluZm8uaD4KKyNpbmNs dWRlIDxzeXMvc3lzY3RsLmg+CisjaW5jbHVkZSA8c3lzL3R5cGVzLmg+CisjaW5jbHVkZSA8c3lz L21hbGxvYy5oPgorI2luY2x1ZGUgPHN5cy9wYXJhbS5oPgorI2luY2x1ZGUgPHN5cy9zeXN0bS5o PgorI2luY2x1ZGUgPHN5cy9wcm9jLmg+CisjaW5jbHVkZSA8c3lzL2ZjbnRsLmg+CisjaW5jbHVk ZSA8c3lzL3R5cGVzLmg+CisjaW5jbHVkZSA8c3lzL3Vpby5oPgorI2luY2x1ZGUgPHN5cy9wb2xs Lmg+CisjaW5jbHVkZSA8c3lzL3NidWYuaD4KKyNpbmNsdWRlIDxzeXMva29iai5oPgorI2luY2x1 ZGUgPHN5cy9tb2R1bGUuaD4KKworI2luY2x1ZGUgPGRldi9zb3VuZC9taWRpL21pZGkuaD4KKyNp bmNsdWRlICJtcHVfaWYuaCIKKworI2luY2x1ZGUgPGRldi9zb3VuZC9taWRpL21pZGlxLmg+Cisj aW5jbHVkZSAic3ludGhfaWYuaCIKK01BTExPQ19ERUZJTkUoTV9NSURJLCAibWlkaSBidWZmZXJz IiwgIk1pZGkgZGF0YSBhbGxvY2F0aW9uIGFyZWEiKTsKKworCisjZGVmaW5lIFBDTU1LTUlOT1Io dSwgZCwgYykgKCgoKGMpICYgMHhmZikgPDwgMTYpIHwgKCgodSkgJiAweDBmKSA8PCA0KSB8ICgo ZCkgJiAweDBmKSkKKyNkZWZpbmUgTUlESU1LTUlOT1IodSwgZCwgYykgUENNTUtNSU5PUih1LCBk LCBjKQorCisjZGVmaW5lIE1JRElfREVWX1JBVwkyCisjZGVmaW5lIE1JRElfREVWX01JRElDVEwg MTIKKworZW51bSBtaWRpX3N0YXRlcyB7CisJTUlESV9JTl9TVEFSVCwgTUlESV9JTl9TWVNFWCwg TUlESV9JTl9EQVRBCit9OworCisvKgorICogVGhlIE1QVSBpbnRlcmZhY2UgY3VycmVudCBoYXMg aW5pdCgpIHVuaW5pdCgpIGlucXNpemUoKCBvdXRxc2l6ZSgpCisgKiBjYWxsYmFjaygpIDogZmlk ZGxlIHdpdGggdGhlIHR4fHJ4IHN0YXR1cy4KKyAqLworCisjaW5jbHVkZSAibXB1X2lmLmgiCisK Ky8qCisgKiAvZGV2L3JtaWRpCVN0cnVjdHVyZSBkZWZpbml0aW9ucworICovCisKKyNkZWZpbmUg TUlESV9OQU1FTEVOICAgMTYKK3N0cnVjdCBzbmRfbWlkaSB7CisJS09CSl9GSUVMRFM7CisJc3Ry dWN0IG10eCAgICAgIGxvY2s7CS8qIFByb3RlY3RzIGFsbCBidXQgcXVldWVzICovCisJdm9pZCAg ICAgICAgICAgKmNvb2tpZTsKKworCWludCAgICAgICAgICAgICB1bml0OwkvKiBTaG91bGQgb25s eSBiZSB1c2VkIGluIG1pZGlzdGF0ICovCisJaW50ICAgICAgICAgICAgIGNoYW5uZWw7LyogU2hv dWxkIG9ubHkgYmUgdXNlZCBpbiBtaWRpc3RhdCAqLworCisJaW50ICAgICAgICAgICAgIGJ1c3k7 CisJaW50ICAgICAgICAgICAgIGZsYWdzOwkvKiBGaWxlIGZsYWdzICovCisJY2hhciAgICAgICAg ICAgIG5hbWVbTUlESV9OQU1FTEVOXTsKKwlzdHJ1Y3QgbXR4ICAgICAgcWxvY2s7CS8qIFByb3Rl Y3RzIGlucSwgb3V0cSBhbmQgZmxhZ3MgKi8KKwkgICAgICAgICAgICAgICAgTUlESVFfSEVBRCgs IGNoYXIpaW5xLCBvdXRxOworCWludCAgICAgICAgICAgICByY2hhbiwgd2NoYW47CisJc3RydWN0 IHNlbGluZm8gIHJzZWwsIHdzZWw7CisJaW50ICAgICAgICAgICAgIGhpd2F0OwkvKiBRTEVOKG91 dHEpPkhpZ2gtd2F0ZXIgLT4gZGlzYWJsZSB3cml0ZXMKKwkJICAgICAqIGZyb20gdXNlcmxhbmQg Ki8KKwllbnVtIG1pZGlfc3RhdGVzIGlucV9zdGF0ZTsKKwlpbnQgICAgICAgICAgICAgaW5xX3N0 YXR1cywgaW5xX2xlZnQ7CS8qIFZhcmlhYmxlcyBmb3IgdGhlIHN0YXRlCisJCQkgICAgICogbWFj aGluZSBpbiBNaWRpX2luLCB0aGlzCisJCQkgICAgICogaXMgdG8gcHJvdmlkZSB0aGF0IHNpZ25h bHMKKwkJCSAgICAgKiBvbmx5IGdldCBpc3N1ZWQgb25seQorCQkJICAgICAqIGNvbXBsZXRlIGNv bW1hbmQgcGFja2V0cy4gKi8KKwlzdHJ1Y3QgcHJvYyAgICAqYXN5bmM7CisJc3RydWN0IGNkZXYg ICAgKmRldjsKKwlzdHJ1Y3Qgc3ludGhfbWlkaSAqc3ludGg7CisJaW50CQlzeW50aF9mbGFnczsK KwlUQUlMUV9FTlRSWShzbmRfbWlkaSkgbGluazsKK307CisKK3N0cnVjdCBzeW50aF9taWRpIHsK KyAgICBLT0JKX0ZJRUxEUzsKKyAgICBzdHJ1Y3Qgc25kX21pZGkgKm07Cit9OworCitzdGF0aWMg c3ludGhfb3Blbl90IG1pZGlzeW50aF9vcGVuOworc3RhdGljIHN5bnRoX2Nsb3NlX3QgbWlkaXN5 bnRoX2Nsb3NlOworc3RhdGljIHN5bnRoX3dyaXRlcmF3X3QgbWlkaXN5bnRoX3dyaXRlcmF3Owor c3RhdGljIHN5bnRoX2tpbGxub3RlX3QgbWlkaXN5bnRoX2tpbGxub3RlOworc3RhdGljIHN5bnRo X3N0YXJ0bm90ZV90IG1pZGlzeW50aF9zdGFydG5vdGU7CitzdGF0aWMgc3ludGhfc2V0aW5zdHJf dCBtaWRpc3ludGhfc2V0aW5zdHI7CitzdGF0aWMgc3ludGhfYWxsb2NfdCBtaWRpc3ludGhfYWxs b2M7CitzdGF0aWMgc3ludGhfY29udHJvbGxlcl90IG1pZGlzeW50aF9jb250cm9sbGVyOworc3Rh dGljIHN5bnRoX2JlbmRlcl90IG1pZGlzeW50aF9iZW5kZXI7CisKKworc3RhdGljIGtvYmpfbWV0 aG9kX3QgbWlkaXN5bnRoX21ldGhvZHNbXSA9IHsKKyAgICAgICAgICAgIEtPQkpNRVRIT0Qoc3lu dGhfb3BlbixtaWRpc3ludGhfb3BlbiksCisgICAgICAgICAgICBLT0JKTUVUSE9EKHN5bnRoX2Ns b3NlLG1pZGlzeW50aF9jbG9zZSksCisgICAgICAgICAgICBLT0JKTUVUSE9EKHN5bnRoX3dyaXRl cmF3LG1pZGlzeW50aF93cml0ZXJhdyksCisgICAgICAgICAgICBLT0JKTUVUSE9EKHN5bnRoX3Nl dGluc3RyLG1pZGlzeW50aF9zZXRpbnN0ciksCisgICAgICAgICAgICBLT0JKTUVUSE9EKHN5bnRo X3N0YXJ0bm90ZSxtaWRpc3ludGhfc3RhcnRub3RlKSwKKyAgICAgICAgICAgIEtPQkpNRVRIT0Qo c3ludGhfa2lsbG5vdGUsbWlkaXN5bnRoX2tpbGxub3RlKSwKKwkgICAgS09CSk1FVEhPRChzeW50 aF9hbGxvYywgbWlkaXN5bnRoX2FsbG9jKSwKKwkgICAgS09CSk1FVEhPRChzeW50aF9jb250cm9s bGVyLCBtaWRpc3ludGhfY29udHJvbGxlciksCisJICAgIEtPQkpNRVRIT0Qoc3ludGhfYmVuZGVy LCBtaWRpc3ludGhfYmVuZGVyKSwKKyAgICAgICAgICAgIHsgMCwgMCB9Cit9OworCitERUZJTkVf Q0xBU1MobWlkaXN5bnRoLCBtaWRpc3ludGhfbWV0aG9kcywgMCk7CisKKy8qCisgKiBNb2R1bGUg RXhwb3J0cyAmIEludGVyZmFjZQorICogCisgKiBzdHJ1Y3QgbWlkaV9jaGFuICptaWRpX2luaXQo TVBVX0NMQVNTIGNscywgaW50IHVuaXQsIGludCBjaGFuKSBpbnQKKyAqIG1pZGlfdW5pbml0KHN0 cnVjdCBzbmRfbWlkaSAqKSAwID09IG5vIGVycm9yIEVCVVNZIG9yIG90aGVyIGVycm9yIGludAor ICogTWlkaV9pbihzdHJ1Y3QgbWlkaV9jaGFuICosIGNoYXIgKmJ1ZiwgaW50IGNvdW50KSBpbnQg TWlkaV9vdXQoc3RydWN0CisgKiBtaWRpX2NoYW4gKiwgY2hhciAqYnVmLCBpbnQgY291bnQpCisg KiAKKyAqIG1pZGlfe2luLG91dH0gcmV0dXJuIGFjdHVhbCBzaXplIHRyYW5zZmVyZWQKKyAqIAor ICovCisKKworLyoKKyAqIG1pZGlfZGV2cyB0YWlscSwgaG9sZGVyIG9mIGFsbCBybWlkaSBpbnN0 YW5jZXMgcHJvdGVjdGVkIGJ5IG1pZGlzdGF0X2xvY2sKKyAqLworCitUQUlMUV9IRUFEKCwgc25k X21pZGkpIG1pZGlfZGV2czsKKworLyoKKyAqIC9kZXYvbWlkaXN0YXQgdmFyaWFibGVzIGFuZCBk ZWNsYXJhdGlvbnMsIHByb3RlY3RlZCBieSBtaWRpc3RhdF9sb2NrCisgKi8KKworc3RhdGljIHN0 cnVjdCBtdHggbWlkaXN0YXRfbG9jazsKK3N0YXRpYyBpbnQgICAgICBtaWRpc3RhdF9pc29wZW4g PSAwOworc3RhdGljIHN0cnVjdCBzYnVmIG1pZGlzdGF0X3NidWY7CitzdGF0aWMgaW50ICAgICAg bWlkaXN0YXRfYnVmcHRyOworc3RhdGljIHN0cnVjdCBjZGV2ICptaWRpc3RhdF9kZXY7CisKKy8q CisgKiAvZGV2L21pZGlzdGF0CWRldl90IGRlY2xhcmF0aW9ucworICovCisKK3N0YXRpYyBkX29w ZW5fdCBtaWRpc3RhdF9vcGVuOworc3RhdGljIGRfY2xvc2VfdCBtaWRpc3RhdF9jbG9zZTsKK3N0 YXRpYyBkX3JlYWRfdCBtaWRpc3RhdF9yZWFkOworCisjZGVmaW5lIE1JRElfTUFKT1IgMzAKKwor c3RhdGljIHN0cnVjdCBjZGV2c3cgbWlkaXN0YXRfY2RldnN3ID0geworCS5kX3ZlcnNpb24gPSBE X1ZFUlNJT04sCisJLmRfb3BlbiA9IG1pZGlzdGF0X29wZW4sCisJLmRfY2xvc2UgPSBtaWRpc3Rh dF9jbG9zZSwKKwkuZF9yZWFkID0gbWlkaXN0YXRfcmVhZCwKKwkuZF9uYW1lID0gIm1pZGlzdGF0 IiwKKwkuZF9tYWogPSBNSURJX01BSk9SLAorfTsKKworCisvKgorICogL2Rldi9ybWlkaSBkZXZf dCBkZWNsYXJhdGlvbnMsIHN0cnVjdCB2YXJpYWJsZSBhY2Nlc3MgaXMgcHJvdGVjdGVkIGJ5Cisg KiBsb2NrcyBjb250YWluZWQgd2l0aGluIHRoZSBzdHJ1Y3R1cmUuCisgKi8KKworc3RhdGljIGRf b3Blbl90IG1pZGlfb3BlbjsKK3N0YXRpYyBkX2Nsb3NlX3QgbWlkaV9jbG9zZTsKK3N0YXRpYyBk X2lvY3RsX3QgbWlkaV9pb2N0bDsKK3N0YXRpYyBkX3JlYWRfdCBtaWRpX3JlYWQ7CitzdGF0aWMg ZF93cml0ZV90IG1pZGlfd3JpdGU7CitzdGF0aWMgZF9wb2xsX3QgbWlkaV9wb2xsOworCitzdGF0 aWMgc3RydWN0IGNkZXZzdyBtaWRpX2NkZXZzdyA9IHsKKwkuZF92ZXJzaW9uID0gRF9WRVJTSU9O LAorCS5kX29wZW4gPSBtaWRpX29wZW4sCisJLmRfY2xvc2UgPSBtaWRpX2Nsb3NlLAorCS5kX3Jl YWQgPSBtaWRpX3JlYWQsCisJLmRfd3JpdGUgPSBtaWRpX3dyaXRlLAorCS5kX2lvY3RsID0gbWlk aV9pb2N0bCwKKwkuZF9wb2xsID0gbWlkaV9wb2xsLAorCS5kX25hbWUgPSAicm1pZGkiLAorCS5k X21haiA9IE1JRElfTUFKT1IsCit9OworCisvKgorICogUHJvdG90eXBlcyBvZiBsaWJyYXJ5IGZ1 bmN0aW9ucworICovCisKK3N0YXRpYyBpbnQgICAgICBtaWRpX2Rlc3Ryb3koc3RydWN0IHNuZF9t aWRpICosIGludCk7CitzdGF0aWMgaW50ICAgICAgbWlkaXN0YXRfcHJlcGFyZShzdHJ1Y3Qgc2J1 ZiAqIHMpOworc3RhdGljIGludCAgICAgIG1pZGlfbG9hZCh2b2lkKTsKK3N0YXRpYyBpbnQgICAg ICBtaWRpX3VubG9hZCh2b2lkKTsKKworLyoKKyAqIE1pc2MgZGVjbHIuCisgKi8KK1NZU0NUTF9O T0RFKF9odywgT0lEX0FVVE8sIG1pZGksIENUTEZMQUdfUkQsIDAsICJNaWRpIGRyaXZlciIpOwor U1lTQ1RMX05PREUoX2h3X21pZGksIE9JRF9BVVRPLCBzdGF0LCBDVExGTEFHX1JELCAwLCAiU3Rh dHVzIGRldmljZSIpOworCitpbnQgICAgICAgICAgICAgbWlkaV9kZWJ1ZzsKK1NZU0NUTF9JTlQo X2h3X21pZGksIE9JRF9BVVRPLCBkZWJ1ZywgQ1RMRkxBR19SVywgJm1pZGlfZGVidWcsIDAsICIi KTsKKworaW50ICAgICAgICAgICAgIG1pZGlfZHVtcHJhdzsKK1NZU0NUTF9JTlQoX2h3X21pZGks IE9JRF9BVVRPLCBkdW1wcmF3LCBDVExGTEFHX1JXLCAmbWlkaV9kdW1wcmF3LCAwLCAiIik7CisK K2ludCAgICAgICAgICAgICBtaWRpX2luc3Ryb2ZmOworU1lTQ1RMX0lOVChfaHdfbWlkaSwgT0lE X0FVVE8sIGluc3Ryb2ZmLCBDVExGTEFHX1JXLCAmbWlkaV9pbnN0cm9mZiwgMCwgIiIpOworCitp bnQgICAgICAgICAgICAgbWlkaXN0YXRfdmVyYm9zZTsKK1NZU0NUTF9JTlQoX2h3X21pZGlfc3Rh dCwgT0lEX0FVVE8sIHZlcmJvc2UsIENUTEZMQUdfUlcsIAorCSZtaWRpc3RhdF92ZXJib3NlLCAw LCAiIik7CisKKyNkZWZpbmUgTUlESV9ERUJVRyhsLGEpCWlmKG1pZGlfZGVidWc+PWwpIGEKKy8q CisgKiBDT0RFIFNUQVJUCisgKi8KKworLyoKKyAqIFJlZ2lzdGVyIGEgbmV3IHJtaWRpIGRldmlj ZS4gY2xzIG1pZGlfaWYgaW50ZXJmYWNlIHVuaXQgPT0gMCBtZWFucworICogYXV0by1hc3NpZ24g bmV3IHVuaXQgbnVtYmVyIHVuaXQgIT0gMCBhbHJlYWR5IGFzc2lnbmVkIGEgdW5pdCBudW1iZXIs IGVnLgorICogbm90IHRoZSBmaXJzdCBjaGFubmVsIHByb3ZpZGVkIGJ5IHRoaXMgZGV2aWNlLiBj aGFubmVsLAlzdWItdW5pdAorICogY29va2llIGlzIHBhc3NlZCBiYWNrIG9uIE1QVSBjYWxscyBU eXBpY2FsIGRldmljZSBkcml2ZXJzIHdpbGwgY2FsbCB3aXRoCisgKiB1bml0PTAsIGNoYW5uZWw9 MS4uKG51bWJlciBvZiBjaGFubmVscykgYW5kIGNvb2tpZT1zb2Z0X2MgYW5kIHdvbid0IGNhcmUK KyAqIHdoYXQgdW5pdCBudW1iZXIgaXMgdXNlZC4KKyAqIAorICogSXQgaXMgYW4gZXJyb3IgdG8g Y2FsbCBtaWRpX2luaXQgd2l0aCBhbiBhbHJlYWR5IHVzZWQgdW5pdC9jaGFubmVsIGNvbWJvLgor ICogCisgKiBSZXR1cm5zIE5VTEwgb24gZXJyb3IKKyAqIAorICovCitzdHJ1Y3Qgc25kX21pZGkg KgorbWlkaV9pbml0KGtvYmpfY2xhc3NfdCBjbHMsIGludCB1bml0LCBpbnQgY2hhbm5lbCwgdm9p ZCAqY29va2llKQoreworCXN0cnVjdCBzbmRfbWlkaSAqbTsKKwlpbnQgICAgICAgICAgICAgaTsK KwlpbnQgICAgICAgICAgICAgaW5xc2l6ZSwgb3V0cXNpemU7CisJTUlESV9UWVBFICAgICAgKmJ1 ZjsKKworCU1JRElfREVCVUcoMSxwcmludGYoIm1pZGlpbml0OiB1bml0ICVkLyVkLlxuIiwgdW5p dCwgY2hhbm5lbCkpOworCW10eF9sb2NrKCZtaWRpc3RhdF9sb2NrKTsKKwkvKgorCSAqIFByb3Rl Y3QgYWdhaW5zdCBjYWxsIHdpdGggZXhpc3RpbmcgdW5pdC9jaGFubmVsIG9yIGF1dG8tYWxsb2Nh dGUgYQorCSAqIG5ldyB1bml0IG51bWJlci4KKwkgKi8KKwlpID0gLTE7CisJVEFJTFFfRk9SRUFD SChtLCAmbWlkaV9kZXZzLCBsaW5rKSB7CisJICAgIG10eF9sb2NrKCZtLT5sb2NrKTsKKwkgICAg aWYgKHVuaXQgIT0gMCkgeworCSAgICBpZiAobS0+dW5pdCA9PSB1bml0ICYmIG0tPmNoYW5uZWwg PT0gY2hhbm5lbCkgeworCSAgICAgICAgbXR4X3VubG9jaygmbS0+bG9jayk7CisJCWdvdG8gZXJy MDsKKwkJfQorCSAgICB9IGVsc2UgeworCS8qCisJICogRmluZCBhIGJldHRlciB1bml0IG51bWJl cgorCSAqLworCSAgICBpZiAobS0+dW5pdCA+IGkpCisJCWkgPSBtLT51bml0OworCSAgICB9CisJ ICAgIG10eF91bmxvY2soJm0tPmxvY2spOworCX0KKworCWlmICh1bml0ID09IDApCisJICAgIHVu aXQgPSBpICsgMTsKKworCU1JRElfREVCVUcoMSwgcHJpbnRmKCJtaWRpaW5pdCAjMjogdW5pdCAl ZC8lZC5cbiIsIHVuaXQsIGNoYW5uZWwpKTsKKwltID0gbWFsbG9jKHNpemVvZigqbSksIE1fTUlE SSwgTV9OT1dBSVQgfCBNX1pFUk8pOworCWlmIChtID09IE5VTEwpCisJICAgIGdvdG8gZXJyMDsK KworCW0tPnN5bnRoID0gbWFsbG9jKHNpemVvZigqbS0+c3ludGgpLCBNX01JREksIE1fTk9XQUlU IHwgTV9aRVJPKTsKKwlrb2JqX2luaXQoKGtvYmpfdCltLT5zeW50aCwgJm1pZGlzeW50aF9jbGFz cyk7CisJbS0+c3ludGgtPm0gPSBtOworCWtvYmpfaW5pdCgoa29ial90KW0sIGNscyk7CisJaW5x c2l6ZSA9IE1QVV9JTlFTSVpFKG0sIGNvb2tpZSk7CisJb3V0cXNpemUgPSBNUFVfT1VUUVNJWkUo bSwgY29va2llKTsKKworCU1JRElfREVCVUcoMSwgcHJpbnRmKCJtaWRpaW5pdCBxdWV1ZXMgJWQv JWQuXG4iLCBpbnFzaXplLCBvdXRxc2l6ZSkpOworCWlmICghaW5xc2l6ZSAmJiAhb3V0cXNpemUp CisJICAgIGdvdG8gZXJyMTsKKworCW10eF9pbml0KCZtLT5sb2NrLCAicmF3IG1pZGkiLCAwLCAw KTsKKwltdHhfaW5pdCgmbS0+cWxvY2ssICJxIHJhdyBtaWRpIiwgMCwgMCk7CisKKwltdHhfbG9j aygmbS0+bG9jayk7CisJbXR4X2xvY2soJm0tPnFsb2NrKTsKKworCWlmIChpbnFzaXplKQorCSAg ICBidWYgPSBtYWxsb2Moc2l6ZW9mKE1JRElfVFlQRSkgKiBpbnFzaXplLCBNX01JREksIE1fTk9X QUlUKTsKKwllbHNlCisJICAgIGJ1ZiA9IE5VTEw7CisKKwlNSURJUV9JTklUKG0tPmlucSwgYnVm LCBpbnFzaXplKTsKKworCWlmIChvdXRxc2l6ZSkKKwkgICAgYnVmID0gbWFsbG9jKHNpemVvZihN SURJX1RZUEUpICogb3V0cXNpemUsIE1fTUlESSwgTV9OT1dBSVQpOworCWVsc2UKKwkgICAgYnVm ID0gTlVMTDsKKwltLT5oaXdhdCA9IG91dHFzaXplIC8gMjsKKworCU1JRElRX0lOSVQobS0+b3V0 cSwgYnVmLCBvdXRxc2l6ZSk7CisKKwlpZiAoKGlucXNpemUgJiYgIU1JRElRX0JVRihtLT5pbnEp KSB8fAorCSAgICAob3V0cXNpemUgJiYgIU1JRElRX0JVRihtLT5vdXRxKSkpCisJICAgIGdvdG8g ZXJyMjsKKworCisJbS0+YnVzeSA9IDA7CisJbS0+ZmxhZ3MgPSAwOworCW0tPnVuaXQgPSB1bml0 OworCW0tPmNoYW5uZWwgPSBjaGFubmVsOworCW0tPmNvb2tpZSA9IGNvb2tpZTsKKworCWlmIChN UFVfSU5JVChtLCBjb29raWUpKQorCSAgICBnb3RvIGVycjI7CisKKwltdHhfdW5sb2NrKCZtLT5s b2NrKTsKKwltdHhfdW5sb2NrKCZtLT5xbG9jayk7CisKKwlUQUlMUV9JTlNFUlRfVEFJTCgmbWlk aV9kZXZzLCBtLCBsaW5rKTsKKworCW10eF91bmxvY2soJm1pZGlzdGF0X2xvY2spOworCisJbS0+ ZGV2ID0gbWFrZV9kZXYoJm1pZGlfY2RldnN3LAorCQkJTUlESU1LTUlOT1IodW5pdCwgTUlESV9E RVZfUkFXLCBjaGFubmVsKSwKKwkgICAgICAgICAJVUlEX1JPT1QsIEdJRF9XSEVFTCwgMDY2Niwg Im1pZGklZC4lZCIsIHVuaXQsIGNoYW5uZWwpOworCW0tPmRldi0+c2lfZHJ2MSA9IG07CisKKwly ZXR1cm4gbTsKKworZXJyMjoJbXR4X2Rlc3Ryb3koJm0tPnFsb2NrKTsKKwltdHhfZGVzdHJveSgm bS0+bG9jayk7CisKKwlpZiAoTUlESVFfQlVGKG0tPmlucSkpCisJICAgIGZyZWUoTUlESVFfQlVG KG0tPmlucSksIE1fTUlESSk7CisJaWYgKE1JRElRX0JVRihtLT5vdXRxKSkKKwkgICAgZnJlZShN SURJUV9CVUYobS0+b3V0cSksIE1fTUlESSk7CitlcnIxOglmcmVlKG0sIE1fTUlESSk7CitlcnIw OgltdHhfdW5sb2NrKCZtaWRpc3RhdF9sb2NrKTsKKwlNSURJX0RFQlVHKDEsIHByaW50ZigibWlk aV9pbml0IGVuZGVkIGluIGVycm9yXG4iKSk7CisJcmV0dXJuIE5VTEw7Cit9CisKKy8qCisgKiBt aWRpX3VuaW5pdCBkb2VzIG5vdCBjYWxsIE1JRElfVU5JTklULCBhcyBzaW5jZSB0aGlzIGlzIHRo ZSBpbXBsZW1lbnRvcnMKKyAqIGVudHJ5IHBvaW50LiBtaWRpX3VuaW50IGlmIGZhY3QsIGRvZXMg bm90IHNlbmQgYW55IG1ldGhvZHMuIEEgY2FsbCB0bworICogbWlkaV91bmluaXQgaXMgYSBkZWZh Y3RvIHByb21pc2UgdGhhdCB5b3Ugd29uJ3QgbWFuaXB1bGF0ZSBjaCBhbnltb3JlCisgKiAKKyAq LworCitpbnQKK21pZGlfdW5pbml0KHN0cnVjdCBzbmRfbWlkaSAqIG0pCit7CisJaW50ICAgICAg ICAgICAgIGVycjsKKworCWVyciA9IEVOWElPOworCW10eF9sb2NrKCZtaWRpc3RhdF9sb2NrKTsK KwltdHhfbG9jaygmbS0+bG9jayk7CisJaWYgKG0tPmJ1c3kpIHsKKwkgICAgaWYgKCEobS0+cmNo YW4gfHwgbS0+d2NoYW4pKQorCQlnb3RvIGVycjsKKworCSAgICBpZiAobS0+cmNoYW4pIHsKKwkJ d2FrZXVwKCZtLT5yY2hhbik7CisJCW0tPnJjaGFuID0gMDsKKwkgICAgfQorCSAgICBpZiAobS0+ d2NoYW4pIHsKKwkJd2FrZXVwKCZtLT53Y2hhbik7CisJCW0tPndjaGFuID0gMDsKKwkgICAgfQor CX0KKwllcnIgPSBtaWRpX2Rlc3Ryb3kobSwgMCk7CisJaWYoIWVycikKKwkJZ290byBleGl0Owor CitlcnI6CW10eF91bmxvY2soJm0tPmxvY2spOworZXhpdDoJbXR4X3VubG9jaygmbWlkaXN0YXRf bG9jayk7CisJcmV0dXJuIGVycjsKK30KKworLyoKKyAqIG1pZGlfaW46IHByb2Nlc3MgYWxsIGRh dGEgdW50aWwgdGhlIHF1ZXVlIGlzIGZ1bGwsIHRoZW4gZGlzY2FyZHMgdGhlIHJlc3QuCisgKiBT aW5jZSBtaWRpX2luIGlzIGEgc3RhdGUgbWFjaGluZSwgZGF0YSBkaXNjYXJkcyBjYW4gY2F1c2Ug aXQgdG8gZ2V0IG91dCBvZgorICogd2hhY2suICBQcm9jZXNzIGFzIG11Y2ggYXMgcG9zc2libGUu ICBJdCBjYWxscywgd2FrZXVwLCBzZWxub3RpZnkgYW5kCisgKiBwc2lnbmFsIGF0IG1vc3Qgb25j ZS4KKyAqLworCisjaWYgbm90ZGVmCitzdGF0aWMgaW50ICAgICAgbWlkaV9sZW5ndGhzW10gPSB7 MiwgMiwgMiwgMiwgMSwgMSwgMiwgMH07CisjZW5kaWYgLyogbm90ZGVmICovCisvKiBOdW1iZXIg b2YgYnl0ZXMgaW4gYSBNSURJIGNvbW1hbmQgKi8KKyNkZWZpbmUgTUlESV9MRU5HVEgoZCkgKG1p ZGlfbGVuZ3Roc1soKGQpID4+IDQpICYgN10pCisjZGVmaW5lIE1JRElfQUNLCTB4ZmUKKyNkZWZp bmUgTUlESV9JU19TVEFUVVMoZCkgKChkKSA+PSAweDgwKQorI2RlZmluZSBNSURJX0lTX0NPTU1P TihkKSAoKGQpID49IDB4ZjApCisKKyNkZWZpbmUgTUlESV9TWVNFWF9TVEFSVAkweEYwCisjZGVm aW5lIE1JRElfU1lTRVhfRU5ECSAgICAweEY3CisKKworaW50CittaWRpX2luKHN0cnVjdCBzbmRf bWlkaSAqIG0sIE1JRElfVFlQRSAqIGJ1ZiwgaW50IHNpemUpCit7CisJLyogaW50ICAgICAgICAg ICAgIGksIHNpZywgZW5xOyAqLworCWludCAgICAgICAgICAgICB1c2VkOworCS8qIE1JRElfVFlQ RSAgICAgICBkYXRhOyAqLworCU1JRElfREVCVUcoNSwgcHJpbnRmKCJtaWRpX2luOiBtPSVwIHNp emU9JWRcbiIsIG0sIHNpemUpKTsKKworLyoKKyAqIFhYWDogbG9ja2luZyBmbHViCisgKi8KKwlp ZiAoIShtLT5mbGFncyAmIE1fUlgpKQorCSAgICByZXR1cm4gc2l6ZTsKKworCXVzZWQgPSAwOwor CisJbXR4X2xvY2soJm0tPnFsb2NrKTsKKyNpZiAwCisJLyoKKwkgKiBEb24ndCBib3RoZXIgcXVl dWluZyBpZiBub3QgaW4gcmVhZCBtb2RlLiAgRGlzY2FyZCBldmVyeXRoaW5nIGFuZAorCSAqIHJl dHVybiBzaXplIHNvIHRoZSBjYWxsZXIgZG9lc24ndCBmcmVhayBvdXQuCisJICovCisKKwlpZiAo IShtLT5mbGFncyAmIE1fUlgpKQorCSAgICByZXR1cm4gc2l6ZTsKKworCWZvciAoaSA9IHNpZyA9 IDA7IGkgPCBzaXplOyBpKyspIHsKKworCSAgICBkYXRhID0gYnVmW2ldOworCSAgICBlbnEgPSAw OworCSAgICBpZiAoZGF0YSA9PSBNSURJX0FDSykKKwkJY29udGludWU7CisKKwkgICAgc3dpdGNo IChtLT5pbnFfc3RhdGUpIHsKKwkgICAgY2FzZSBNSURJX0lOX1NUQVJUOgorCQlpZiAoTUlESV9J U19TVEFUVVMoZGF0YSkpIHsKKwkJICAgIHN3aXRjaCAoZGF0YSkgeworCQkgICAgY2FzZSAweGYw OgkvKiBTeXNleCAqLworCQkJbS0+aW5xX3N0YXRlID0gTUlESV9JTl9TWVNFWDsKKwkJCWJyZWFr OworCQkgICAgY2FzZSAweGYxOgkvKiBNVEMgcXVhcnRlciBmcmFtZSAqLworCQkgICAgY2FzZSAw eGYzOgkvKiBTb25nIHNlbGVjdCAqLworCQkJbS0+aW5xX3N0YXRlID0gTUlESV9JTl9EQVRBOwor CQkJZW5xID0gMTsKKwkJCW0tPmlucV9sZWZ0ID0gMTsKKwkJCWJyZWFrOworCQkgICAgY2FzZSAw eGYyOgkvKiBTb25nIHBvc2l0aW9uIHBvaW50ZXIgKi8KKwkJCW0tPmlucV9zdGF0ZSA9IE1JRElf SU5fREFUQTsKKwkJCWVucSA9IDE7CisJCQltLT5pbnFfbGVmdCA9IDI7CisJCQlicmVhazsKKwkJ ICAgIGRlZmF1bHQ6CisJCQlpZiAoTUlESV9JU19DT01NT04oZGF0YSkpIHsKKwkJCSAgICBlbnEg PSAxOworCQkJICAgIHNpZyA9IDE7CisJCQl9IGVsc2UgeworCQkJICAgIG0tPmlucV9zdGF0ZSA9 IE1JRElfSU5fREFUQTsKKwkJCSAgICBlbnEgPSAxOworCQkJICAgIG0tPmlucV9zdGF0dXMgPSBk YXRhOworCQkJICAgIG0tPmlucV9sZWZ0ID0gTUlESV9MRU5HVEgoZGF0YSk7CisJCQl9CisJCQli cmVhazsKKwkJICAgIH0KKwkJfSBlbHNlIGlmIChNSURJX0lTX1NUQVRVUyhtLT5pbnFfc3RhdHVz KSkgeworCQkgICAgbS0+aW5xX3N0YXRlID0gTUlESV9JTl9EQVRBOworCQkgICAgaWYgKCFNSURJ UV9GVUxMKG0tPmlucSkpIHsKKwkJCXVzZWQrKzsKKwkJCU1JRElRX0VOUShtLT5pbnEsICZtLT5p bnFfc3RhdHVzLCAxKTsKKwkJICAgIH0KKwkJICAgIGVucSA9IDE7CisJCSAgICBtLT5pbnFfbGVm dCA9IE1JRElfTEVOR1RIKG0tPmlucV9zdGF0dXMpIC0gMTsKKwkJfQorCQlicmVhazsKKwkJLyoK KwkJICogRW5kIG9mIGNhc2UgTUlESV9JTl9TVEFSVDoKKwkJICovCisKKwkgICAgY2FzZSBNSURJ X0lOX0RBVEE6CisJCWVucSA9IDE7CisJCWlmICgtLW0tPmlucV9sZWZ0IDw9IDApCisJCSAgICBz aWcgPSAxOwkvKiBkZWxpdmVyIGRhdGEgKi8KKwkJYnJlYWs7CisJICAgIGNhc2UgTUlESV9JTl9T WVNFWDoKKwkJaWYgKGRhdGEgPT0gTUlESV9TWVNFWF9FTkQpCisJCSAgICBtLT5pbnFfc3RhdGUg PSBNSURJX0lOX1NUQVJUOworCQlicmVhazsKKwkgICAgfQorCisJICAgIGlmIChlbnEpCisJCWlm ICghTUlESVFfRlVMTChtLT5pbnEpKSB7CisJCSAgICBNSURJUV9FTlEobS0+aW5xLCAmZGF0YSwg MSk7CisJCSAgICB1c2VkKys7CisJCX0KKwkgICAgLyoKKwkgICAgICogRW5kIG9mIHRoZSBzdGF0 ZSBtYWNoaW5lcyBtYWluICJmb3IgbG9vcCIKKwkgICAgICovCisJfQorCWlmIChzaWcpIHsKKyNl bmRpZgorCU1JRElfREVCVUcoNiwgcHJpbnRmKCJtaWRpX2luOiBsZW4gJWpkIGF2YWlsICVqZFxu IiwgKGludG1heF90KU1JRElRX0xFTihtLT5pbnEpLCAoaW50bWF4X3QpTUlESVFfQVZBSUwobS0+ aW5xKSkpIDsKKwlpZiAoTUlESVFfQVZBSUwobS0+aW5xKSA+IHNpemUpIHsKKwkJdXNlZD1zaXpl OworCQlNSURJUV9FTlEobS0+aW5xLCBidWYsIHNpemUpOworCX0gZWxzZSB7CisJCU1JRElfREVC VUcoNCxwcmludGYoIm1pZGlfaW46IERpc2NhcmRpbmcgZGF0YSBxdVxuIikpOworCQltdHhfdW5s b2NrKCZtLT5xbG9jayk7CisJCXJldHVybiAwOworCX0KKwkgICAgaWYgKG0tPnJjaGFuKSB7CisJ CXdha2V1cCgmbS0+cmNoYW4pOworCQltLT5yY2hhbiA9IDA7CisJICAgIH0KKwkgICAgc2Vsd2Fr ZXVwKCZtLT5yc2VsKTsKKwkgICAgaWYgKG0tPmFzeW5jKSB7CisJCVBST0NfTE9DSyhtLT5hc3lu Yyk7CisJCXBzaWduYWwobS0+YXN5bmMsIFNJR0lPKTsKKwkJUFJPQ19VTkxPQ0sobS0+YXN5bmMp OworCSAgICB9CisjaWYgMAorCX0KKyNlbmRpZgorCW10eF91bmxvY2soJm0tPnFsb2NrKTsKKwly ZXR1cm4gdXNlZDsKK30KKworLyoKKyAqIG1pZGlfb3V0OiBUaGUgb25seSBjbGVhcmVyIG9mIHRo ZSBNX1RYRU4gZmxhZy4KKyAqLworaW50CittaWRpX291dChzdHJ1Y3Qgc25kX21pZGkgKiBtLCBN SURJX1RZUEUgKiBidWYsIGludCBzaXplKQoreworCWludCAgICAgICAgICAgICB1c2VkOworCisv KgorICogWFhYOiBsb2NraW5nIGZsdWIKKyAqLworCWlmICghKG0tPmZsYWdzICYgTV9UWEVOKSkK KwkJcmV0dXJuIDA7CisKKwlNSURJX0RFQlVHKDIsIHByaW50ZigibWlkaV9vdXQ6ICVwXG4iLCBt KSk7IAorCW10eF9sb2NrKCZtLT5xbG9jayk7CisJdXNlZCA9IE1JTihzaXplLCBNSURJUV9MRU4o bS0+b3V0cSkpOworCU1JRElfREVCVUcoMywgcHJpbnRmKCJtaWRpX291dDogdXNlZCAlZFxuIiwg dXNlZCkpOworCWlmICh1c2VkKQorCSAgICBNSURJUV9ERVEobS0+b3V0cSwgYnVmLCB1c2VkKTsK KwlpZiAoTUlESVFfRU1QVFkobS0+b3V0cSkpIHsKKwkgICAgbS0+ZmxhZ3MgJj0gfk1fVFhFTjsK KwkgICAgTVBVX0NBTExCQUNLUChtLCBtLT5jb29raWUsIG0tPmZsYWdzKTsKKwl9CisJaWYgKHVz ZWQgJiYgTUlESVFfQVZBSUwobS0+b3V0cSkgPiBtLT5oaXdhdCApIHsKKwkJaWYgKG0tPndjaGFu KSB7CisJCQl3YWtldXAoJm0tPndjaGFuKTsKKwkJCW0tPndjaGFuID0gMDsKKwkJfQorCQlzZWx3 YWtldXAoJm0tPndzZWwpOworCQkgaWYgKG0tPmFzeW5jKSB7CisJCQlQUk9DX0xPQ0sobS0+YXN5 bmMpOworCQkJcHNpZ25hbChtLT5hc3luYywgU0lHSU8pOworCQkJUFJPQ19VTkxPQ0sobS0+YXN5 bmMpOworCQl9CisJfQorCW10eF91bmxvY2soJm0tPnFsb2NrKTsKKwlyZXR1cm4gdXNlZDsKK30K KworCisvKgorICogL2Rldi9ybWlkaSMuIwlkZXZpY2UgYWNjZXNzIGZ1bmN0aW9ucworICovCitp bnQKK21pZGlfb3BlbihzdHJ1Y3QgY2RldiAqaV9kZXYsIGludCBmbGFncywgaW50IG1vZGUsIHN0 cnVjdCB0aHJlYWQgKiB0ZCkKK3sKKwlzdHJ1Y3Qgc25kX21pZGkgKm0gPSBpX2Rldi0+c2lfZHJ2 MTsKKwlpbnQgICAgICAgICAgICAgcmV0dmFsOworCisJTUlESV9ERUJVRygxLHByaW50ZigibWlk aW9wZW4gJXAgJXMgJXNcbiIsIHRkLAorCQlmbGFncyAmIEZSRUFEPyJNX1JYIjoiIiwgZmxhZ3Mg JiBGV1JJVEU/Ik1fVFgiOiIiKSk7CisJaWYgKG0gPT0gTlVMTCkKKwkgICAgcmV0dXJuIEVOWElP OworCisJbXR4X2xvY2soJm0tPmxvY2spOworCW10eF9sb2NrKCZtLT5xbG9jayk7CisKKwlyZXR2 YWwgPSAwOworCisJaWYgKGZsYWdzICYgRlJFQUQpIHsKKwkgICAgaWYgKE1JRElRX1NJWkUobS0+ aW5xKSA9PSAwKQorCQlyZXR2YWwgPSBFTlhJTzsKKwkgICAgZWxzZSBpZiAobS0+ZmxhZ3MgJiBN X1JYKQorCQlyZXR2YWwgPSBFQlVTWTsKKwkgICAgaWYgKHJldHZhbCkKKwkJZ290byBlcnI7CisJ fQorCWlmIChmbGFncyAmIEZXUklURSkgeworCSAgICBpZiAoTUlESVFfU0laRShtLT5vdXRxKSA9 PSAwKQorCQlyZXR2YWwgPSBFTlhJTzsKKwkgICAgZWxzZSBpZiAobS0+ZmxhZ3MgJiBNX1RYKQor CQlyZXR2YWwgPSBFQlVTWTsKKwkgICAgaWYgKHJldHZhbCkKKwkJZ290byBlcnI7CisJfQorCW0t PmJ1c3krKzsKKworCW0tPnJjaGFuID0gMDsKKwltLT53Y2hhbiA9IDA7CisJbS0+YXN5bmMgPSAw OworCisJaWYgKGZsYWdzICYgRlJFQUQpIHsKKwkgICAgbS0+ZmxhZ3MgfD0gTV9SWCB8IE1fUlhF TjsKKwkgICAgLyoKKwkgICAgICogT25seSBjbGVhciB0aGUgaW5xLCB0aGUgb3V0cSBtaWdodCBz dGlsbCBoYXZlIGRhdGEgdG8gZHJhaW4gZnJvbQorCSAgICAgKiBhIHByZXZpb3VzIHNlc3Npb24K KwkgICAgICovCisJICAgIE1JRElRX0NMRUFSKG0tPmlucSk7CisJfTsKKworCWlmIChmbGFncyAm IEZXUklURSkKKwkgICAgbS0+ZmxhZ3MgfD0gTV9UWDsKKworCU1QVV9DQUxMQkFDSyhtLCBtLT5j b29raWUsIG0tPmZsYWdzKTsKKworCU1JRElfREVCVUcoMiwgcHJpbnRmKCJtaWRpX29wZW46IG9w ZW5lZC5cbiIpKTsKKworZXJyOgltdHhfdW5sb2NrKCZtLT5xbG9jayk7CisJbXR4X3VubG9jaygm bS0+bG9jayk7CisJcmV0dXJuIHJldHZhbDsKK30KKworaW50CittaWRpX2Nsb3NlKHN0cnVjdCBj ZGV2ICppX2RldiwgaW50IGZsYWdzLCBpbnQgbW9kZSwgc3RydWN0IHRocmVhZCAqIHRkKQorewor CXN0cnVjdCBzbmRfbWlkaSAqbSA9IGlfZGV2LT5zaV9kcnYxOworCWludCAgICAgICAgICAgICBy ZXR2YWw7CisJaW50CQlvbGRmbGFnczsKKworCU1JRElfREVCVUcoMSwgcHJpbnRmKCJtaWRpX2Ns b3NlICVwICVzICVzXG4iLCB0ZCwKKwkJZmxhZ3MgJiBGUkVBRD8iTV9SWCI6IiIsIGZsYWdzICYg RldSSVRFPyJNX1RYIjoiIikpOworCisJaWYgKG0gPT0gTlVMTCkKKwkgICAgcmV0dXJuICAgICAg ICAgICBFTlhJTzsKKworCW10eF9sb2NrKCZtLT5sb2NrKTsKKwltdHhfbG9jaygmbS0+cWxvY2sp OworCisJaWYgKCAoZmxhZ3MgJiBGUkVBRCAmJiAhKG0tPmZsYWdzICYgTV9SWCkpIHx8IAorCSAg ICAgKGZsYWdzICYgRldSSVRFICYmICEobS0+ZmxhZ3MgJiBNX1RYKSkgKSB7CisJICAgIHJldHZh bCA9IEVOWElPOworCSAgICBnb3RvIGVycjsKKwl9CisKKwltLT5idXN5LS07CisKKwlvbGRmbGFn cyA9IG0tPmZsYWdzOworCisJaWYgKGZsYWdzICYgRlJFQUQpCisJICAgIG0tPmZsYWdzICY9IH4o TV9SWCB8IE1fUlhFTik7CisJaWYgKGZsYWdzICYgRldSSVRFKQorCSAgICBtLT5mbGFncyAmPSB+ TV9UWDsKKworCWlmKCAobS0+ZmxhZ3MgJiAoTV9UWEVOIHwgTV9SWEVOKSkgIT0gKG9sZGZsYWdz ICYgKE1fUlhFTiB8IE1fVFhFTikpICkKKwkJTVBVX0NBTExCQUNLKG0sIG0tPmNvb2tpZSwgbS0+ ZmxhZ3MpOworCisJTUlESV9ERUJVRygxLCBwcmludGYoIm1pZGlfY2xvc2U6IGNsb3NlZCwgYnVz eSA9ICVkLlxuIiwgbS0+YnVzeSkpOworCisJbXR4X3VubG9jaygmbS0+cWxvY2spOworCW10eF91 bmxvY2soJm0tPmxvY2spOworCXJldHZhbCA9IDA7CitlcnI6CXJldHVybiByZXR2YWw7Cit9Cisv KgorICogVE9ETzogbWlkaV9yZWFkLCBwZXIgb3NzIHByb2dyYW1tZXIncyBndWlkZSBwZy4gNDIg c2hvdWxkIHJldHVybiBhcyBzb29uIGFzIGRhdGEgaXMgYXZhaWxhYmxlLgorICovCitpbnQKK21p ZGlfcmVhZChzdHJ1Y3QgY2RldiAqaV9kZXYsIHN0cnVjdCB1aW8gKiB1aW8sIGludCBpb2ZsYWcp Cit7CisjZGVmaW5lIE1JRElfUlNJWkUgMzIKKwlzdHJ1Y3Qgc25kX21pZGkgKm0gPSBpX2Rldi0+ c2lfZHJ2MTsKKwlpbnQgICAgICAgICAgICAgcmV0dmFsOworCWludCAgICAgICAgICAgICB1c2Vk OworCWNoYXIgICAgICAgICAgICBidWZbTUlESV9SU0laRV07CisKKwlNSURJX0RFQlVHKDUsIHBy aW50ZigibWlkaXJlYWQ6IGNvdW50PSVsdVxuIiwgKHVuc2lnbmVkIGxvbmcpdWlvLT51aW9fcmVz aWQpKTsKKworCXJldHZhbCA9IEVJTzsKKworCWlmIChtID09IE5VTEwpCisJICAgIGdvdG8gZXJy MDsKKworCW10eF9sb2NrKCZtLT5sb2NrKTsKKwltdHhfbG9jaygmbS0+cWxvY2spOworCisJaWYg KCEobS0+ZmxhZ3MgJiBNX1JYKSkKKwkgICAgZ290byBlcnIxOworCisJd2hpbGUgKHVpby0+dWlv X3Jlc2lkID4gMCkgeworCSAgICB3aGlsZSAoTUlESVFfRU1QVFkobS0+aW5xKSkgeworCQlyZXR2 YWwgPSBFV09VTERCTE9DSzsKKwkJaWYgKGlvZmxhZyAmIE9fTk9OQkxPQ0spCisJCSAgICBnb3Rv IGVycjE7CisJCW10eF91bmxvY2soJm0tPmxvY2spOworCQltLT5yY2hhbiA9IDE7CisJCXJldHZh bCA9IG1zbGVlcCgmbS0+cmNoYW4sICZtLT5xbG9jaywKKwkJCVBDQVRDSCB8IFBEUk9QLCAibWlk aSBSWCIsIDApOworCQkvKgorCQkgKiBXZSBzbGVwdCwgbWF5YmUgdGhpbmdzIGhhdmUgY2hhbmdl ZCBzaW5jZSBsYXN0CisJCSAqIGR5aW5nIGNoZWNrCisJCSAqLworCQlpZiAocmV0dmFsID09IEVJ TlRSKQorCQkgICAgZ290byBlcnIwOworCQlpZiAobSAhPSBpX2Rldi0+c2lfZHJ2MSkKKwkJICAg IHJldHZhbCA9IEVOWElPOworCQkvKiBpZiAocmV0dmFsICYmIHJldHZhbCAhPSBFUkVTVEFSVCkg Ki8KKwkJaWYgKHJldHZhbCkKKwkJICAgIGdvdG8gZXJyMDsKKwkJbXR4X2xvY2soJm0tPmxvY2sp OworCQltdHhfbG9jaygmbS0+cWxvY2spOworCQltLT5yY2hhbiA9IDA7CisJCWlmICghbS0+YnVz eSkKKwkJICAgIGdvdG8gZXJyMTsKKwkgICAgfQorCQlNSURJX0RFQlVHKDYsIHByaW50ZigibWlk aV9yZWFkIHN0YXJ0XG4iKSk7CisJICAgIC8qCisJICAgICAqIEF0IHRoaXMgcG9pbnQsIGl0IGlz IGNlcnRhaW4gdGhhdCBtLT5pbnEgaGFzIGRhdGEKKwkgICAgICovCisKKwkgICAgdXNlZCA9IE1J TihNSURJUV9MRU4obS0+aW5xKSwgdWlvLT51aW9fcmVzaWQpOworCSAgICB1c2VkID0gTUlOKHVz ZWQsIE1JRElfUlNJWkUpOworCisJICAgIE1JRElfREVCVUcoNixwcmludGYoIm1pZGlyZWFkOiB1 aW9tb3ZlIGNjPSVkXG4iLCB1c2VkKSk7CisJICAgIE1JRElRX0RFUShtLT5pbnEsIGJ1ZiwgdXNl ZCk7CisJICAgIHJldHZhbCA9IHVpb21vdmUoYnVmLCB1c2VkLCB1aW8pOworCSAgICBpZiAocmV0 dmFsKQorCQlnb3RvIGVycjE7CisJfQorCisJLyoKKwkgKiBJZiB3ZSBNYWRlIGl0IGhlcmUgdGhl biB0cmFuc2ZlciBpcyBnb29kCisJICovCisJcmV0dmFsID0gMDsKK2VycjE6CW10eF91bmxvY2so Jm0tPnFsb2NrKTsKKwltdHhfdW5sb2NrKCZtLT5sb2NrKTsKK2VycjA6CU1JRElfREVCVUcoNCwg cHJpbnRmKCJtaWRpX3JlYWQ6IHJldCAlZFxuIixyZXR2YWwpKTsKKwlyZXR1cm4gcmV0dmFsOwor fQorCisvKgorICogbWlkaV93cml0ZTogVGhlIG9ubHkgc2V0dGVyIG9mIE1fVFhFTgorICovCisK K2ludAorbWlkaV93cml0ZShzdHJ1Y3QgY2RldiAqaV9kZXYsIHN0cnVjdCB1aW8gKiB1aW8sIGlu dCBpb2ZsYWcpCit7CisjZGVmaW5lIE1JRElfV1NJWkUgMzIKKwlzdHJ1Y3Qgc25kX21pZGkgKm0g PSBpX2Rldi0+c2lfZHJ2MTsKKwlpbnQgICAgICAgICAgICAgcmV0dmFsOworCWludCAgICAgICAg ICAgICB1c2VkOworCWNoYXIgICAgICAgICAgICBidWZbTUlESV9XU0laRV07CisKKworCU1JRElf REVCVUcoNCwgcHJpbnRmKCJtaWRpX3dyaXRlXG4iKSk7IAorCXJldHZhbCA9IDA7CisJaWYgKG0g PT0gTlVMTCkKKwkgICAgZ290byBlcnIwOworCisJbXR4X2xvY2soJm0tPmxvY2spOworCW10eF9s b2NrKCZtLT5xbG9jayk7CisKKwlpZiAoIShtLT5mbGFncyAmIE1fVFgpKQorCSAgICBnb3RvIGVy cjE7CisKKwl3aGlsZSAodWlvLT51aW9fcmVzaWQgPiAwKSB7CisJICAgIHdoaWxlIChNSURJUV9B VkFJTChtLT5vdXRxKSA9PSAwKSB7CisJCXJldHZhbCA9IEVXT1VMREJMT0NLOworCQlpZiAoaW9m bGFnICYgT19OT05CTE9DSykKKwkJICAgIGdvdG8gZXJyMTsKKwkJbXR4X3VubG9jaygmbS0+bG9j ayk7CisJCW0tPndjaGFuID0gMTsKKwkJTUlESV9ERUJVRygzLHByaW50ZigibWlkaV93cml0ZSBt c2xlZXBcbiIpKTsKKwkJcmV0dmFsID0gbXNsZWVwKCZtLT53Y2hhbiwgJm0tPnFsb2NrLAorCQkJ UENBVENIIHwgUERST1AsICJtaWRpIFRYIiwgMCk7CisJCS8qCisJCSAqIFdlIHNsZXB0LCBtYXli ZSB0aGluZ3MgaGF2ZSBjaGFuZ2VkIHNpbmNlIGxhc3QKKwkJICogZHlpbmcgY2hlY2sKKwkJICov CisJCWlmIChyZXR2YWwgPT0gRUlOVFIpCisJCSAgICBnb3RvIGVycjA7CisJCWlmIChtICE9IGlf ZGV2LT5zaV9kcnYxKQorCQkgICAgcmV0dmFsID0gRU5YSU87CisJCWlmIChyZXR2YWwpCisJCSAg ICBnb3RvIGVycjA7CisJCW10eF9sb2NrKCZtLT5sb2NrKTsKKwkJbXR4X2xvY2soJm0tPnFsb2Nr KTsKKwkJbS0+d2NoYW4gPSAwOworCQlpZiAoIW0tPmJ1c3kpCisJCSAgICBnb3RvIGVycjE7CisJ ICAgIH0KKworCSAgICAvKgorCSAgICAgKiBXZSBhcmUgY2VydGFpbiB0aGFuIGRhdGEgY2FuIGJl IHBsYWNlZCBvbiB0aGUgcXVldWUKKwkgICAgICovCisKKwkgICAgdXNlZCA9IE1JTihNSURJUV9B VkFJTChtLT5vdXRxKSwgdWlvLT51aW9fcmVzaWQpOworCSAgICB1c2VkID0gTUlOKHVzZWQsIE1J RElfV1NJWkUpOworCQlNSURJX0RFQlVHKDUscHJpbnRmKCJtaWRpb3V0OiByZXNpZCAlZCBsZW4g JWpkIGF2YWlsICVqZFxuIiwgdWlvLT51aW9fcmVzaWQsIChpbnRtYXhfdClNSURJUV9MRU4obS0+ b3V0cSksIChpbnRtYXhfdClNSURJUV9BVkFJTChtLT5vdXRxKSkpOworCisKKwkgICAgTUlESV9E RUJVRyg1LHByaW50ZigibWlkaV93cml0ZTogdWlvbW92ZSBjYz0lZFxuIiwgdXNlZCkpOworCSAg ICByZXR2YWwgPSB1aW9tb3ZlKGJ1ZiwgdXNlZCwgdWlvKTsKKwkgICAgaWYgKHJldHZhbCkKKwkJ Z290byBlcnIxOworCSAgICBNSURJUV9FTlEobS0+b3V0cSwgYnVmLCB1c2VkKTsKKwkgICAgLyoK KwkgICAgICogSW5mb3JtIHRoZSBib3R0b20gaGFsZiB0aGF0IGRhdGEgY2FuIGJlIHdyaXR0ZW4K KwkgICAgICovCisJICAgIGlmICghKG0tPmZsYWdzICYgTV9UWEVOKSkgeworCQltLT5mbGFncyB8 PSBNX1RYRU47CisJCU1QVV9DQUxMQkFDSyhtLCBtLT5jb29raWUsIG0tPmZsYWdzKTsKKwkgICAg fQorCX0KKwkvKgorCSAqIElmIHdlIE1hZGUgaXQgaGVyZSB0aGVuIHRyYW5zZmVyIGlzIGdvb2QK KwkgKi8KKwlyZXR2YWwgPSAwOworZXJyMToJbXR4X3VubG9jaygmbS0+cWxvY2spOworCW10eF91 bmxvY2soJm0tPmxvY2spOworZXJyMDoJcmV0dXJuIHJldHZhbDsKK30KKworaW50CittaWRpX2lv Y3RsKHN0cnVjdCBjZGV2ICppX2RldiwgdV9sb25nIGNtZCwgY2FkZHJfdCBhcmcsIGludCBtb2Rl LCBzdHJ1Y3QgdGhyZWFkICogdGQpCit7CisJcmV0dXJuIEVOWElPOworfQorCitpbnQKK21pZGlf cG9sbChzdHJ1Y3QgY2RldiAqaV9kZXYsIGludCBldmVudHMsIHN0cnVjdCB0aHJlYWQgKiB0ZCkK K3sKKwlzdHJ1Y3Qgc25kX21pZGkgKm0gPSBpX2Rldi0+c2lfZHJ2MTsKKwlpbnQgICAgICAgICAg ICAgcmV2ZW50czsKKworCWlmIChtID09IE5VTEwpCisJICAgIHJldHVybiAwOworCisJcmV2ZW50 cyA9IDA7CisKKwltdHhfbG9jaygmbS0+bG9jayk7CisJbXR4X2xvY2soJm0tPnFsb2NrKTsKKwor CWlmIChldmVudHMgJiAoUE9MTElOIHwgUE9MTFJETk9STSkpCisJICAgIGlmICghTUlESVFfRU1Q VFkobS0+aW5xKSkKKwkJZXZlbnRzIHw9IGV2ZW50cyAmIChQT0xMSU4gfCBQT0xMUkROT1JNKTsK KworCWlmIChldmVudHMgJiAoUE9MTE9VVCB8IFBPTExXUk5PUk0pKQorCSAgICBpZiAoTUlESVFf QVZBSUwobS0+b3V0cSkgPCBtLT5oaXdhdCkKKwkJZXZlbnRzIHw9IGV2ZW50cyAmIChQT0xMT1VU IHwgUE9MTFdSTk9STSk7CisKKwlpZiAocmV2ZW50cyA9PSAwKSB7CisJICAgIGlmIChldmVudHMg JiAoUE9MTElOIHwgUE9MTFJETk9STSkpCisJCXNlbHJlY29yZCh0ZCwgJm0tPnJzZWwpOworCisJ ICAgIGlmIChldmVudHMgJiAoUE9MTE9VVCB8IFBPTExXUk5PUk0pKQorCQlzZWxyZWNvcmQodGQs ICZtLT53c2VsKTsKKwl9CisJbXR4X3VubG9jaygmbS0+bG9jayk7CisJbXR4X3VubG9jaygmbS0+ cWxvY2spOworCisJcmV0dXJuIChyZXZlbnRzKTsKK30KKworLyoKKyAqIC9kZXYvbWlkaXN0YXQg ZGV2aWNlIGZ1bmN0aW9ucworICogCisgKi8KK3N0YXRpYyBpbnQKK21pZGlzdGF0X29wZW4oc3Ry dWN0IGNkZXYgKmlfZGV2LCBpbnQgZmxhZ3MsIGludCBtb2RlLCBzdHJ1Y3QgdGhyZWFkICogdGQp Cit7CisJaW50ICAgICAgICAgICAgIGVycm9yOworCisKKwlNSURJX0RFQlVHKDEscHJpbnRmKCJt aWRpc3RhdF9vcGVuXG4iKSk7CisJbXR4X2xvY2soJm1pZGlzdGF0X2xvY2spOworCisJaWYgKG1p ZGlzdGF0X2lzb3BlbikgeworCSAgICBtdHhfdW5sb2NrKCZtaWRpc3RhdF9sb2NrKTsKKwkgICAg cmV0dXJuIEVCVVNZOworCX0KKwltaWRpc3RhdF9pc29wZW4gPSAxOworCisJaWYgKHNidWZfbmV3 KCZtaWRpc3RhdF9zYnVmLCBOVUxMLCA0MDk2LCAwKSA9PSBOVUxMKSB7CisJICAgIGVycm9yID0g RU5YSU87CisJICAgIGdvdG8gb3V0OworCX0KKwltaWRpc3RhdF9idWZwdHIgPSAwOworCWVycm9y ID0gKG1pZGlzdGF0X3ByZXBhcmUoJm1pZGlzdGF0X3NidWYpID4gMCkgPyAwIDogRU5PTUVNOwor CitvdXQ6CWlmIChlcnJvcikKKwkgICAgbWlkaXN0YXRfaXNvcGVuID0gMDsKKwltdHhfdW5sb2Nr KCZtaWRpc3RhdF9sb2NrKTsKKwlyZXR1cm4gZXJyb3I7Cit9CisKK3N0YXRpYyBpbnQKK21pZGlz dGF0X2Nsb3NlKHN0cnVjdCBjZGV2ICppX2RldiwgaW50IGZsYWdzLCBpbnQgbW9kZSwgc3RydWN0 IHRocmVhZCAqIHRkKQoreworCWludHJtYXNrX3QgICAgICBzOworCisJTUlESV9ERUJVRygxLHBy aW50ZigibWlkaXN0YXRfY2xvc2VcbiIpKTsKKwltdHhfbG9jaygmbWlkaXN0YXRfbG9jayk7CisJ aWYgKCFtaWRpc3RhdF9pc29wZW4pIHsKKwkgICAgbXR4X3VubG9jaygmbWlkaXN0YXRfbG9jayk7 CisJICAgIHJldHVybiBFQkFERjsKKwl9CisJc2J1Zl9kZWxldGUoJm1pZGlzdGF0X3NidWYpOwor CW1pZGlzdGF0X2lzb3BlbiA9IDA7CisKKwltdHhfdW5sb2NrKCZtaWRpc3RhdF9sb2NrKTsKKwlz cGx4KHMpOworCXJldHVybiAwOworfQorCitzdGF0aWMgaW50CittaWRpc3RhdF9yZWFkKHN0cnVj dCBjZGV2ICppX2Rldiwgc3RydWN0IHVpbyAqIGJ1ZiwgaW50IGZsYWcpCit7CisJaW50ICAgICAg ICAgICAgIGwsIGVycjsKKworCU1JRElfREVCVUcoNCxwcmludGYoIm1pZGlzdGF0X3JlYWRcbiIp KTsKKwltdHhfbG9jaygmbWlkaXN0YXRfbG9jayk7CisJaWYgKCFtaWRpc3RhdF9pc29wZW4pIHsK KwkgICAgbXR4X3VubG9jaygmbWlkaXN0YXRfbG9jayk7CisJICAgIHJldHVybiAgICAgICAgICAg RUJBREY7CisJfQorCWwgPSBtaW4oYnVmLT51aW9fcmVzaWQsIHNidWZfbGVuKCZtaWRpc3RhdF9z YnVmKSAtIG1pZGlzdGF0X2J1ZnB0cik7CisJZXJyID0gMDsKKwlpZiAobCA+IDApCisJICAgIGVy ciA9IHVpb21vdmUoc2J1Zl9kYXRhKCZtaWRpc3RhdF9zYnVmKSArIG1pZGlzdGF0X2J1ZnB0ciwg bCwgYnVmKTsKKwllbHNlCisJICAgIGwgPSAwOworCW1pZGlzdGF0X2J1ZnB0ciArPSBsOworCW10 eF91bmxvY2soJm1pZGlzdGF0X2xvY2spOworCXJldHVybiBlcnI7Cit9CisKKy8qCisgKiBNb2R1 bGUgbGlicmFyeSBmdW5jdGlvbnMKKyAqLworCitzdGF0aWMgaW50CittaWRpc3RhdF9wcmVwYXJl KHN0cnVjdCBzYnVmICogcykKK3sKKwlzdHJ1Y3Qgc25kX21pZGkgKm07CisKKwltdHhfYXNzZXJ0 KCZtaWRpc3RhdF9sb2NrLCBNQV9PV05FRCk7CisKKwlzYnVmX3ByaW50ZihzLCAiRnJlZUJTRCBN aWRpIERyaXZlciAobWlkaTIpXG4iKTsKKwlpZiAoVEFJTFFfRU1QVFkoJm1pZGlfZGV2cykpIHsK KwkgICAgc2J1Zl9wcmludGYocywgIk5vIGRldmljZXMgaW5zdGFsbGVkLlxuIik7CisJICAgIHNi dWZfZmluaXNoKHMpOworCSAgICByZXR1cm4gc2J1Zl9sZW4ocyk7CisJfQorCXNidWZfcHJpbnRm KHMsICJJbnN0YWxsZWQgZGV2aWNlczpcbiIpOworCisJVEFJTFFfRk9SRUFDSChtLCAmbWlkaV9k ZXZzLCBsaW5rKSB7CisJICAgIG10eF9sb2NrKCZtLT5sb2NrKTsKKwkgICAgc2J1Zl9wcmludGYo cywgIiVzIFslZC8lZDolc10iLCBtLT5uYW1lLCBtLT51bml0LCBtLT5jaGFubmVsLAorCQkgICAg TVBVX1BST1ZJREVSKG0sIG0tPmNvb2tpZSkpOworCSAgICBzYnVmX3ByaW50ZihzLCAiJXMiLCBN UFVfREVTQ1IobSwgbS0+Y29va2llLCBtaWRpc3RhdF92ZXJib3NlKSk7CisJICAgIHNidWZfcHJp bnRmKHMsICJcbiIpOworCSAgICBtdHhfdW5sb2NrKCZtLT5sb2NrKTsKKwl9CisKKwlzYnVmX2Zp bmlzaChzKTsKKwlyZXR1cm4gc2J1Zl9sZW4ocyk7Cit9CisKKyNpZiBub3RkZWYKKy8qCisgKiBD b252ZXJ0IElPQ1RMIGNvbW1hbmQgdG8gc3RyaW5nIGZvciBkZWJ1Z2dpbmcKKyAqLworCitzdGF0 aWMgY2hhciAgICAqCittaWRpX2NtZG5hbWUoaW50IGNtZCkKK3sKKwlzdGF0aWMgc3RydWN0IHsK KwkgICAgaW50ICAgICAgICAgICAgIGNtZDsKKwkgICAgY2hhciAgICAgICAgICAgKm5hbWU7CisJ fSAgICAgICAgICAgICAgKnRhYiwgY21kdGFiX21pZGlpb2N0bFtdID0geworI2RlZmluZSBBKHgp CXt4LCAjIyB4fQorCSAgICAvKgorCSAgICAgKiBPbmNlIHdlIGhhdmUgc29tZSByZWFsIElPQ1RM cyBkZWZpbmUsIHRoZSBmb2xsb3dpbmcgd2lsbAorCSAgICAgKiBiZSByZWxhdmFudC4KKwkgICAg ICogCisJICAgICAqIEEoU05EQ1RMX01JRElfUFJFVElNRSksIEEoU05EQ1RMX01JRElfTVBVTU9E RSksCisJICAgICAqIEEoU05EQ1RMX01JRElfTVBVQ01EKSwgQShTTkRDVExfU1lOVEhfSU5GTyks CisJICAgICAqIEEoU05EQ1RMX01JRElfSU5GTyksIEEoU05EQ1RMX1NZTlRIX01FTUFWTCksCisJ ICAgICAqIEEoU05EQ1RMX0ZNX0xPQURfSU5TVFIpLCBBKFNORENUTF9GTV80T1BfRU5BQkxFKSwK KwkgICAgICogQShNSU9TUEFTU1RIUlUpLCBBKE1JT0dQQVNTVEhSVSksIEEoQUlPTldSSVRFKSwK KwkgICAgICogQShBSU9HU0laRSksIEEoQUlPU1NJWkUpLCBBKEFJT0dGTVQpLCBBKEFJT1NGTVQp LAorCSAgICAgKiBBKEFJT0dNSVgpLCBBKEFJT1NNSVgpLCBBKEFJT1NUT1ApLCBBKEFJT1NZTkMp LAorCSAgICAgKiBBKEFJT0dDQVApLAorCSAgICAgKi8KKyN1bmRlZiBBCisJICAgIHsKKwkJLTEs ICJ1bmtub3duIgorCSAgICB9LAorCX07CisKKwlmb3IgKHRhYiA9IGNtZHRhYl9taWRpaW9jdGw7 IHRhYi0+Y21kICE9IGNtZCAmJiB0YWItPmNtZCAhPSAtMTsgdGFiKyspCisJICAgIDsKKwlyZXR1 cm4gdGFiLT5uYW1lOworfQorI2VuZGlmIC8qIG5vdGRlZiAqLworCisvKgorICogbWlkaXN5bnRo CisgKi8KKworCitpbnQKK21pZGlzeW50aF9vcGVuKHZvaWQgKm4sIHZvaWQgKmFyZywgaW50IGZs YWdzKQoreworCXN0cnVjdCBzbmRfbWlkaSAqbSA9ICgoc3RydWN0IHN5bnRoX21pZGkgKiApIG4p LT5tOworCWludCAgICAgICAgICAgICByZXR2YWw7CisKKwlNSURJX0RFQlVHKDEscHJpbnRmKCJt aWRpc3ludGhfb3BlbiAlcyAlc1xuIiwKKwkJZmxhZ3MgJiBGUkVBRD8iTV9SWCI6IiIsIGZsYWdz ICYgRldSSVRFPyJNX1RYIjoiIikpOworCisJaWYgKG0gPT0gTlVMTCkKKwkgICAgcmV0dXJuIEVO WElPOworCisJbXR4X2xvY2soJm0tPmxvY2spOworCW10eF9sb2NrKCZtLT5xbG9jayk7CisKKwly ZXR2YWwgPSAwOworCisJaWYgKGZsYWdzICYgRlJFQUQpIHsKKwkgICAgaWYgKE1JRElRX1NJWkUo bS0+aW5xKSA9PSAwKQorCQlyZXR2YWwgPSBFTlhJTzsKKwkgICAgZWxzZSBpZiAobS0+ZmxhZ3Mg JiBNX1JYKQorCQlyZXR2YWwgPSBFQlVTWTsKKwkgICAgaWYgKHJldHZhbCkKKwkJZ290byBlcnI7 CisJfQorCWlmIChmbGFncyAmIEZXUklURSkgeworCSAgICBpZiAoTUlESVFfU0laRShtLT5vdXRx KSA9PSAwKQorCQlyZXR2YWwgPSBFTlhJTzsKKwkgICAgZWxzZSBpZiAobS0+ZmxhZ3MgJiBNX1RY KQorCQlyZXR2YWwgPSBFQlVTWTsKKwkgICAgaWYgKHJldHZhbCkKKwkJZ290byBlcnI7CisJfQor CW0tPmJ1c3krKzsKKworCS8qCisJICogVE9ETzogQ29uc2lkZXIgbS0+YXN5bmMgPSAwOworCSAq LworCisJaWYgKGZsYWdzICYgRlJFQUQpIHsKKwkgICAgbS0+ZmxhZ3MgfD0gTV9SWCB8IE1fUlhF TjsKKwkgICAgLyoKKwkgICAgICogT25seSBjbGVhciB0aGUgaW5xLCB0aGUgb3V0cSBtaWdodCBz dGlsbCBoYXZlIGRhdGEgdG8gZHJhaW4gZnJvbQorCSAgICAgKiBhIHByZXZpb3VzIHNlc3Npb24K KwkgICAgICovCisJICAgIE1JRElRX0NMRUFSKG0tPmlucSk7CisJICAgIG0tPnJjaGFuID0gMDsK Kwl9OworCisJaWYgKGZsYWdzICYgRldSSVRFKSB7CisJICAgIG0tPmZsYWdzIHw9IE1fVFg7CisJ ICAgIG0tPndjaGFuID0gMDsKKwl9CisKKwltLT5zeW50aF9mbGFncyA9IGZsYWdzICYgKEZSRUFE IHwgRldSSVRFKTsKKwkKKwlNUFVfQ0FMTEJBQ0sobSwgbS0+Y29va2llLCBtLT5mbGFncyk7CisK KworZXJyOgltdHhfdW5sb2NrKCZtLT5xbG9jayk7CisJbXR4X3VubG9jaygmbS0+bG9jayk7CisJ TUlESV9ERUJVRygyLCBwcmludGYoIm1pZGlzeW50aF9vcGVuOiByZXR1cm4gJWQuXG4iLCByZXR2 YWwpKTsKKwlyZXR1cm4gcmV0dmFsOworfQorCitpbnQKK21pZGlzeW50aF9jbG9zZSh2b2lkICpu KQoreworCXN0cnVjdCBzbmRfbWlkaSAqbSA9ICgoc3RydWN0IHN5bnRoX21pZGkgKiluKS0+bTsK KwlpbnQgICAgICAgICAgICAgcmV0dmFsOworCWludAkJb2xkZmxhZ3M7CisKKwlNSURJX0RFQlVH KDEsIHByaW50ZigibWlkaXN5bnRoX2Nsb3NlICVzICVzXG4iLAorCQltLT5zeW50aF9mbGFncyAm IEZSRUFEID8gIk1fUlgiIDogIiIsIAorCQltLT5zeW50aF9mbGFncyAmIEZXUklURSA/ICJNX1RY IiA6ICIiKSk7CisKKwlpZiAobSA9PSBOVUxMKQorCSAgICByZXR1cm4gRU5YSU87CisKKwltdHhf bG9jaygmbS0+bG9jayk7CisJbXR4X2xvY2soJm0tPnFsb2NrKTsKKworCWlmICggKG0tPnN5bnRo X2ZsYWdzICYgRlJFQUQgJiYgIShtLT5mbGFncyAmIE1fUlgpKSB8fCAKKwkgICAgIChtLT5zeW50 aF9mbGFncyAmIEZXUklURSAmJiAhKG0tPmZsYWdzICYgTV9UWCkpICkgeworCSAgICByZXR2YWwg PSBFTlhJTzsKKwkgICAgZ290byBlcnI7CisJfQorCisJbS0+YnVzeS0tOworCisJb2xkZmxhZ3Mg PSBtLT5mbGFnczsKKworCWlmIChtLT5zeW50aF9mbGFncyAmIEZSRUFEKQorCSAgICBtLT5mbGFn cyAmPSB+KE1fUlggfCBNX1JYRU4pOworCWlmIChtLT5zeW50aF9mbGFncyAmIEZXUklURSkKKwkg ICAgbS0+ZmxhZ3MgJj0gfk1fVFg7CisKKwlpZiggKG0tPmZsYWdzICYgKE1fVFhFTiB8IE1fUlhF TikpICE9IChvbGRmbGFncyAmIChNX1JYRU4gfCBNX1RYRU4pKSApCisJCU1QVV9DQUxMQkFDSyht LCBtLT5jb29raWUsIG0tPmZsYWdzKTsKKworCU1JRElfREVCVUcoMSwgcHJpbnRmKCJtaWRpX2Ns b3NlOiBjbG9zZWQsIGJ1c3kgPSAlZC5cbiIsIG0tPmJ1c3kpKTsKKworCW10eF91bmxvY2soJm0t PnFsb2NrKTsKKwltdHhfdW5sb2NrKCZtLT5sb2NrKTsKKwlyZXR2YWwgPSAwOworZXJyOglyZXR1 cm4gcmV0dmFsOworfQorCisvKgorICogQWx3YXlzIGJsb2NraW5nLgorICovCisKK2ludAorbWlk aXN5bnRoX3dyaXRlcmF3KHZvaWQgKm4sIHVpbnQ4X3QgKmJ1Ziwgc2l6ZV90IGxlbikKK3sKKwlz dHJ1Y3Qgc25kX21pZGkJKm0gPSAoKHN0cnVjdCBzeW50aF9taWRpICopbiktPm07CisJaW50ICAg ICAgICAgICAgIHJldHZhbDsKKwlpbnQgICAgICAgICAgICAgdXNlZDsKKwlpbnQgaTsKKworCU1J RElfREVCVUcoNCwgcHJpbnRmKCJtaWRpc3ludGhfd3JpdGVyYXdcbiIpKTsgCisKKwlyZXR2YWwg PSAwOworCisJaWYgKG0gPT0gTlVMTCkKKwkgICAgcmV0dXJuIEVOWElPOworCisJbXR4X2xvY2so Jm0tPmxvY2spOworCW10eF9sb2NrKCZtLT5xbG9jayk7CisKKwlpZiAoIShtLT5mbGFncyAmIE1f VFgpKQorCSAgICBnb3RvIGVycjE7CisKKwlpZiAobWlkaV9kdW1wcmF3KQorCSAgICBwcmludGYo Im1pZGkgZHVtcDogIik7CisKKwl3aGlsZSAobGVuID4gMCkgeworCSAgICB3aGlsZSAoTUlESVFf QVZBSUwobS0+b3V0cSkgPT0gMCkgeworCSAgICBpZiAoIShtLT5mbGFncyAmIE1fVFhFTikpIHsK KwkJbS0+ZmxhZ3MgfD0gTV9UWEVOOworCQlNUFVfQ0FMTEJBQ0sobSwgbS0+Y29va2llLCBtLT5m bGFncyk7CisJICAgIH0KKwkJbXR4X3VubG9jaygmbS0+bG9jayk7CisJCW0tPndjaGFuID0gMTsK KwkJTUlESV9ERUJVRygzLHByaW50ZigibWlkaXN5bnRoX3dyaXRlcmF3IG1zbGVlcFxuIikpOwor CQlyZXR2YWwgPSBtc2xlZXAoJm0tPndjaGFuLCAmbS0+cWxvY2ssCisJCQlQQ0FUQ0ggfCBQRFJP UCwgIm1pZGkgVFgiLCAwKTsKKwkJLyoKKwkJICogV2Ugc2xlcHQsIG1heWJlIHRoaW5ncyBoYXZl IGNoYW5nZWQgc2luY2UgbGFzdAorCQkgKiBkeWluZyBjaGVjaworCQkgKi8KKwkJaWYgKHJldHZh bCA9PSBFSU5UUikKKwkJICAgIGdvdG8gZXJyMDsKKworCQlpZiAocmV0dmFsKQorCQkgICAgZ290 byBlcnIwOworCQltdHhfbG9jaygmbS0+bG9jayk7CisJCW10eF9sb2NrKCZtLT5xbG9jayk7CisJ CW0tPndjaGFuID0gMDsKKwkJaWYgKCFtLT5idXN5KQorCQkgICAgZ290byBlcnIxOworCSAgICB9 CisKKwkgICAgLyoKKwkgICAgICogV2UgYXJlIGNlcnRhaW4gdGhhbiBkYXRhIGNhbiBiZSBwbGFj ZWQgb24gdGhlIHF1ZXVlCisJICAgICAqLworCisJICAgIHVzZWQgPSBNSU4oTUlESVFfQVZBSUwo bS0+b3V0cSksIGxlbik7CisJICAgIHVzZWQgPSBNSU4odXNlZCwgTUlESV9XU0laRSk7CisJICAg IE1JRElfREVCVUcoNSxwcmludGYoIm1pZGlfc3ludGg6IHJlc2lkICVkIGxlbiAlamQgYXZhaWwg JWpkXG4iLCAKKwkJCWxlbiwgKGludG1heF90KU1JRElRX0xFTihtLT5vdXRxKSwgCisJCQkoaW50 bWF4X3QpTUlESVFfQVZBSUwobS0+b3V0cSkpKTsKKworCSAgICBpZiAobWlkaV9kdW1wcmF3KQor CQlmb3IoaT0wO2k8dXNlZDtpKyspIHByaW50ZigiJXggIiwgYnVmW2ldKTsKKworCSAgICBNSURJ UV9FTlEobS0+b3V0cSwgYnVmLCB1c2VkKTsKKwkgICAgbGVuIC09IHVzZWQ7CisKKwkgICAgLyoK KwkgICAgICogSW5mb3JtIHRoZSBib3R0b20gaGFsZiB0aGF0IGRhdGEgY2FuIGJlIHdyaXR0ZW4K KwkgICAgICovCisJICAgIGlmICghKG0tPmZsYWdzICYgTV9UWEVOKSkgeworCQltLT5mbGFncyB8 PSBNX1RYRU47CisJCU1QVV9DQUxMQkFDSyhtLCBtLT5jb29raWUsIG0tPmZsYWdzKTsKKwkgICAg fQorCX0KKwkvKgorCSAqIElmIHdlIE1hZGUgaXQgaGVyZSB0aGVuIHRyYW5zZmVyIGlzIGdvb2QK KwkgKi8KKwlpZiAobWlkaV9kdW1wcmF3KQorCSAgICBwcmludGYoIlxuIik7CisKKwlyZXR2YWwg PSAwOworZXJyMToJbXR4X3VubG9jaygmbS0+cWxvY2spOworCW10eF91bmxvY2soJm0tPmxvY2sp OworZXJyMDoJcmV0dXJuIHJldHZhbDsKK30KKworc3RhdGljIGludAorbWlkaXN5bnRoX2tpbGxu b3RlKHZvaWQgKm4sIHVpbnQ4X3QgY2huLCB1aW50OF90IG5vdGUsIHVpbnQ4X3QgdmVsKQorewor CXVfY2hhciBjWzNdOworCisKKwlpZiAobm90ZSA+IDEyNyB8fCBjaG4gPiAxNSkKKwkJcmV0dXJu IChFSU5WQUwpOworCisJaWYgKHZlbCA+IDEyNykKKwkgICAgdmVsID0gMTI3OworCisJaWYgKHZl bCA9PSA2NCkgeworCQljWzBdID0gMHg5MCB8IChjaG4gJiAweDBmKTsgLyogTm90ZSBvbi4gKi8K KwkJY1sxXSA9ICh1X2NoYXIpbm90ZTsKKwkJY1syXSA9IDA7CisJfSBlbHNlIHsKKwkJY1swXSA9 IDB4ODAgfCAoY2huICYgMHgwZik7IC8qIE5vdGUgb2ZmLiAqLworCQljWzFdID0gKHVfY2hhcilu b3RlOworCQljWzJdID0gKHVfY2hhcil2ZWw7CisJfQorCisJcmV0dXJuIG1pZGlzeW50aF93cml0 ZXJhdyhuLCBjLCAzKTsKK30KKworc3RhdGljIGludAorbWlkaXN5bnRoX3NldGluc3RyKHZvaWQg Km4sIHVpbnQ4X3QgY2huLCB1aW50MTZfdCBpbnN0cikKK3sKKwl1X2NoYXIgY1syXTsKKworCWlm IChpbnN0ciA+IDEyNyB8fCBjaG4gPiAxNSkKKwkJcmV0dXJuIEVJTlZBTDsKKworCWNbMF0gPSAw eGMwIHwgKGNobiAmIDB4MGYpOyAvKiBQcm9nYW1tZSBjaGFuZ2UuICovCisJY1sxXSA9IGluc3Ry ICsgbWlkaV9pbnN0cm9mZjsKKworCXJldHVybiBtaWRpc3ludGhfd3JpdGVyYXcobiwgYywgMik7 Cit9CisKK3N0YXRpYyBpbnQKK21pZGlzeW50aF9zdGFydG5vdGUodm9pZCAqbiwgdWludDhfdCBj aG4sIHVpbnQ4X3Qgbm90ZSwgdWludDhfdCB2ZWwpCit7CisJdV9jaGFyIGNbM107CisKKwlpZiAo bm90ZSA+IDEyNyB8fCBjaG4gPiAxNSkKKwkJcmV0dXJuIEVJTlZBTDsKKworCWlmICh2ZWwgPiAx MjcpCisJICAgIHZlbCA9IDEyNzsKKworCWNbMF0gPSAweDkwIHwgKGNobiAmIDB4MGYpOyAvKiBO b3RlIG9uLiAqLworCWNbMV0gPSAodV9jaGFyKW5vdGU7CisJY1syXSA9ICh1X2NoYXIpdmVsOwor CisJcmV0dXJuIG1pZGlzeW50aF93cml0ZXJhdyhuLCBjLCAzKTsKK30KK3N0YXRpYyBpbnQKK21p ZGlzeW50aF9hbGxvYyh2b2lkICpuLCB1aW50OF90IGNoYW4sIHVpbnQ4X3Qgbm90ZSkKK3sKKwly ZXR1cm4gY2hhbjsKK30KKworc3RhdGljIGludAorbWlkaXN5bnRoX2NvbnRyb2xsZXIodm9pZCAq biwgdWludDhfdCBjaG4sIHVpbnQ4X3QgY3RybG51bSwgdWludDE2X3QgdmFsKQoreworCXVfY2hh ciBjWzNdOworCisJaWYgKGN0cmxudW0gPiAxMjcgfHwgY2huID4gMTUpCisJICAgIHJldHVybiBF SU5WQUw7CisKKwljWzBdID0gMHhiMCB8IChjaG4gJiAweDBmKTsgLyogQ29udHJvbCBNZXNzYWdl LiAqLworCWNbMV0gPSBjdHJsbnVtOworCWNbMl0gPSB2YWw7CisJcmV0dXJuIG1pZGlzeW50aF93 cml0ZXJhdyhuLCBjLCAzKTsKK30KKworc3RhdGljIGludAorbWlkaXN5bnRoX2JlbmRlcih2b2lk ICpuLCB1aW50OF90IGNobiwgdWludDE2X3QgdmFsKQoreworCXVfY2hhciBjWzNdOworCisKKwlp ZiAodmFsID4gMTYzODMgfHwgY2huID4gMTUpCisJCXJldHVybiAgRUlOVkFMOworCisJY1swXSA9 IDB4ZTAgfCAoY2huICYgMHgwZik7IC8qIFBpdGNoIGJlbmQuICovCisJY1sxXSA9ICh1X2NoYXIp dmFsICYgMHg3ZjsKKwljWzJdID0gKHVfY2hhcikodmFsID4+IDcpICYgMHg3ZjsKKworCXJldHVy biBtaWRpc3ludGhfd3JpdGVyYXcobiwgYywgMyk7Cit9CisKKy8qCisgKiBTaW5nbGUgcG9pbnQg b2YgbWlkaSBkZXN0cnVjdGlvbnMuCisgKi8KK3N0YXRpYyBpbnQKK21pZGlfZGVzdHJveShzdHJ1 Y3Qgc25kX21pZGkgKiBtLCBpbnQgbWlkaXVuaW5pdCkKK3sKKworCW10eF9hc3NlcnQoJm1pZGlz dGF0X2xvY2ssIE1BX09XTkVEKTsKKwltdHhfYXNzZXJ0KCZtLT5sb2NrLCBNQV9PV05FRCk7CisK KwlNSURJX0RFQlVHKDMscHJpbnRmKCJtaWRpX2Rlc3Ryb3lcbiIpKTsKKwltLT5kZXYtPnNpX2Ry djEgPSBOVUxMOworCWRlc3Ryb3lfZGV2KG0tPmRldik7CisJVEFJTFFfUkVNT1ZFKCZtaWRpX2Rl dnMsIG0sIGxpbmspOworCWlmIChtaWRpdW5pbml0KQorCSAgICBNUFVfVU5JTklUKG0sIG0tPmNv b2tpZSk7CisJZnJlZShNSURJUV9CVUYobS0+aW5xKSwgTV9NSURJKTsKKwlmcmVlKE1JRElRX0JV RihtLT5vdXRxKSwgTV9NSURJKTsKKwltdHhfZGVzdHJveSgmbS0+cWxvY2spOworCW10eF9kZXN0 cm95KCZtLT5sb2NrKTsKKwlmcmVlKG0sIE1fTUlESSk7CisJcmV0dXJuIDA7Cit9CisKKy8qCisg KiBMb2FkIGFuZCB1bmxvYWQgZnVuY3Rpb25zLCBjcmVhdGVzIHRoZSAvZGV2L21pZGlzdGF0IGRl dmljZQorICovCisKK3N0YXRpYyBpbnQKK21pZGlfbG9hZCgpCit7CisJbXR4X2luaXQoJm1pZGlz dGF0X2xvY2ssICJtaWRpc3RhdCBsb2NrIiwgMCwgMCk7CisJVEFJTFFfSU5JVCgmbWlkaV9kZXZz KTsJLyogSW5pdGlhbGl6ZSB0aGUgcXVldWUuICovCisKKwltaWRpc3RhdF9kZXYgPSBtYWtlX2Rl digmbWlkaXN0YXRfY2RldnN3LAorCQkgICAgTUlESU1LTUlOT1IoMCwgTUlESV9ERVZfTUlESUNU TCwgMCksCisJCSAgICBVSURfUk9PVCwgR0lEX1dIRUVMLCAwNjY2LCAibWlkaXN0YXQiKTsKKwor CXJldHVybiAwOworfQorCitzdGF0aWMgaW50CittaWRpX3VubG9hZCgpCit7CisJc3RydWN0IHNu ZF9taWRpICptOworCWludCAgICAgICAgICAgICByZXR2YWw7CisKKwlNSURJX0RFQlVHKDEscHJp bnRmKCJtaWRpX3VubG9hZCgpXG4iKSk7CisJcmV0dmFsID0gRUJVU1k7CisJbXR4X2xvY2soJm1p ZGlzdGF0X2xvY2spOworCWlmIChtaWRpc3RhdF9pc29wZW4pCisJICAgIGdvdG8gZXhpdDA7CisK KwlUQUlMUV9GT1JFQUNIKG0sICZtaWRpX2RldnMsIGxpbmspIHsKKwkgICAgbXR4X2xvY2soJm0t PmxvY2spOworCSAgICBpZiAobS0+YnVzeSkKKwkJcmV0dmFsID0gRUJVU1k7CisJICAgIGVsc2UK KwkJcmV0dmFsID0gbWlkaV9kZXN0cm95KG0sIDEpOworCSAgICBpZiAocmV0dmFsKQorCQlnb3Rv IGV4aXQxOworCX0KKworCWRlc3Ryb3lfZGV2KG1pZGlzdGF0X2Rldik7CisJLyoKKwkgKiBNYWRl IGl0IGhlcmUgdGhlbiB1bmxvYWQgaXMgY29tcGxldGUKKwkgKi8KKwltdHhfZGVzdHJveSgmbWlk aXN0YXRfbG9jayk7CisJcmV0dXJuIDA7CisKK2V4aXQxOgorCW10eF91bmxvY2soJm0tPmxvY2sp OworZXhpdDA6CisJbXR4X3VubG9jaygmbWlkaXN0YXRfbG9jayk7CisJaWYocmV0dmFsKSBNSURJ X0RFQlVHKDIscHJpbnRmKCJtaWRpX3VubG9hZDogZmFpbGVkXG4iKSk7CisJcmV0dXJuIHJldHZh bDsKK30KKworZXh0ZXJuIGludCBzZXFfbW9kZXZlbnQobW9kdWxlX3QgbW9kLCBpbnQgdHlwZSwg dm9pZCAqZGF0YSk7CisKK3N0YXRpYyBpbnQKK21pZGlfbW9kZXZlbnQobW9kdWxlX3QgbW9kLCBp bnQgdHlwZSwgdm9pZCAqZGF0YSkKK3sKKwlpbnQgICAgICAgICAgICAgcmV0dmFsOworCisJcmV0 dmFsID0gMDsKKworCXN3aXRjaCAodHlwZSkgeworCWNhc2UgTU9EX0xPQUQ6CisJICAgIHJldHZh bCA9IG1pZGlfbG9hZCgpOworCSAgICBpZiAocmV0dmFsID09IDApCisJCXJldHZhbCA9IHNlcV9t b2RldmVudChtb2QsIHR5cGUsIGRhdGEpOworCSAgICBicmVhazsKKworCWNhc2UgTU9EX1VOTE9B RDoKKwkgICAgcmV0dmFsID0gbWlkaV91bmxvYWQoKTsKKwkgICAgaWYgKHJldHZhbCA9PSAwKQor CQlyZXR2YWwgPSBzZXFfbW9kZXZlbnQobW9kLCB0eXBlLCBkYXRhKTsKKwkgICAgYnJlYWs7CisK KwlkZWZhdWx0OgorCSAgICBicmVhazsKKwl9CisKKwlyZXR1cm4gcmV0dmFsOworfQorCitrb2Jq X3QKK21pZGltYXBwZXJfYWRkc2VxKHZvaWQgKmFyZzEsIGludCAqdW5pdCwgdm9pZCAqKmNvb2tp ZSkKK3sKKwl1bml0ID0gMDsKKworCXJldHVybiAoa29ial90KSBhcmcxOworfQorCitpbnQKK21p ZGltYXBwZXJfb3Blbih2b2lkICphcmcxLCB2b2lkICoqY29va2llKQoreworCWludCByZXR2YWwg PSAwOworCXN0cnVjdCBzbmRfbWlkaSAqbTsKKworICAgICAgICBtdHhfbG9jaygmbWlkaXN0YXRf bG9jayk7CisKKyAgICAgICAgVEFJTFFfRk9SRUFDSChtLCAmbWlkaV9kZXZzLCBsaW5rKSB7CisJ ICAgIHJldHZhbCsrOworCSAgICAgICAgfQorCisgICAgICAgIG10eF91bmxvY2soJm1pZGlzdGF0 X2xvY2spOworICAgICAgICByZXR1cm4gcmV0dmFsOworfQorCitpbnQKK21pZGltYXBwZXJfY2xv c2Uodm9pZCAqYXJnMSwgdm9pZCAqY29va2llKQoreworCXJldHVybiAwOworfQorCitrb2JqX3QK K21pZGltYXBwZXJfZmV0Y2hfc3ludGgodm9pZCAqYXJnLCB2b2lkICpjb29raWUsIGludCB1bml0 KQoreworCXN0cnVjdCBzbmRfbWlkaSAqbTsKKwlpbnQgcmV0dmFsID0gMDsKKworCW10eF9sb2Nr KCZtaWRpc3RhdF9sb2NrKTsKKworCVRBSUxRX0ZPUkVBQ0gobSwgJm1pZGlfZGV2cywgbGluaykg eworCSAgIGlmICh1bml0ID09IHJldHZhbCkgeworCSAgICAgICBtdHhfdW5sb2NrKCZtaWRpc3Rh dF9sb2NrKTsKKwkgICAgICAgcmV0dXJuIChrb2JqX3QpbS0+c3ludGg7CisJICAgfQorCSAgIHJl dHZhbCsrOworCX0KKworCW10eF91bmxvY2soJm1pZGlzdGF0X2xvY2spOworCXJldHVybiBOVUxM OworfQorCitERVZfTU9EVUxFKG1pZGksIG1pZGlfbW9kZXZlbnQsIE5VTEwpOworTU9EVUxFX1ZF UlNJT04obWlkaSwgMSk7CkluZGV4OiBzeXMvZGV2L3NvdW5kL21pZGkvbWlkaS5oCj09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT0KUkNTIGZpbGU6IHN5cy9kZXYvc291bmQvbWlkaS9taWRpLmgKZGlmZiAtTiBzeXMvZGV2L3Nv dW5kL21pZGkvbWlkaS5oCi0tLSAvZGV2L251bGwJMSBKYW4gMTk3MCAwMDowMDowMCAtMDAwMAor Kysgc3lzL2Rldi9zb3VuZC9taWRpL21pZGkuaAk1IE1hciAyMDA1IDE2OjI3OjA3IC0wMDAwCkBA IC0wLDAgKzEsNTQgQEAKKy8qCisgKiAoYykgMjAwMyBNYXRoZXcgS2FubmVyCisgKiAKKyAqIFJl ZGlzdHJpYnV0aW9uIGFuZCB1c2UgaW4gc291cmNlIGFuZCBiaW5hcnkgZm9ybXMsIHdpdGggb3Ig d2l0aG91dAorICogbW9kaWZpY2F0aW9uLCBhcmUgcGVybWl0dGVkIHByb3ZpZGVkIHRoYXQgdGhl IGZvbGxvd2luZyBjb25kaXRpb25zIGFyZQorICogbWV0OiAxLiBSZWRpc3RyaWJ1dGlvbnMgb2Yg c291cmNlIGNvZGUgbXVzdCByZXRhaW4gdGhlIGFib3ZlIGNvcHlyaWdodAorICogbm90aWNlLCB0 aGlzIGxpc3Qgb2YgY29uZGl0aW9ucyBhbmQgdGhlIGZvbGxvd2luZyBkaXNjbGFpbWVyLiAyLgor ICogUmVkaXN0cmlidXRpb25zIGluIGJpbmFyeSBmb3JtIG11c3QgcmVwcm9kdWNlIHRoZSBhYm92 ZSBjb3B5cmlnaHQgbm90aWNlLAorICogdGhpcyBsaXN0IG9mIGNvbmRpdGlvbnMgYW5kIHRoZSBm b2xsb3dpbmcgZGlzY2xhaW1lciBpbiB0aGUgZG9jdW1lbnRhdGlvbgorICogYW5kL29yIG90aGVy IG1hdGVyaWFscyBwcm92aWRlZCB3aXRoIHRoZSBkaXN0cmlidXRpb24uCisgKiAKKyAqIFRISVMg U09GVFdBUkUgSVMgUFJPVklERUQgQlkgVEhFIEFVVEhPUiBBTkQgQ09OVFJJQlVUT1JTIGBgQVMg SVMnJyBBTkQgQU5ZCisgKiBFWFBSRVNTIE9SIElNUExJRUQgV0FSUkFOVElFUywgSU5DTFVESU5H LCBCVVQgTk9UIExJTUlURUQgVE8sIFRIRSBJTVBMSUVECisgKiBXQVJSQU5USUVTIE9GIE1FUkNI QU5UQUJJTElUWSBBTkQgRklUTkVTUyBGT1IgQSBQQVJUSUNVTEFSIFBVUlBPU0UgQVJFCisgKiBE SVNDTEFJTUVELiAgSU4gTk8gRVZFTlQgU0hBTEwgVEhFIEFVVEhPUiBPUiBDT05UUklCVVRPUlMg QkUgTElBQkxFIEZPUgorICogQU5ZIERJUkVDVCwgSU5ESVJFQ1QsIElOQ0lERU5UQUwsIFNQRUNJ QUwsIEVYRU1QTEFSWSwgT1IgQ09OU0VRVUVOVElBTAorICogREFNQUdFUyAoSU5DTFVESU5HLCBC VVQgTk9UIExJTUlURUQgVE8sIFBST0NVUkVNRU5UIE9GIFNVQlNUSVRVVEUgR09PRFMgT1IKKyAq IFNFUlZJQ0VTOyBMT1NTIE9GIFVTRSwgREFUQSwgT1IgUFJPRklUUzsgT1IgQlVTSU5FU1MgSU5U RVJSVVBUSU9OKSBIT1dFVkVSCisgKiBDQVVTRUQgQU5EIE9OIEFOWSBUSEVPUlkgT0YgTElBQklM SVRZLCBXSEVUSEVSIElOIENPTlRSQUNULCBTVFJJQ1QKKyAqIExJQUJJTElUWSwgT1IgVE9SVCAo SU5DTFVESU5HIE5FR0xJR0VOQ0UgT1IgT1RIRVJXSVNFKSBBUklTSU5HIElOIEFOWSBXQVkKKyAq IE9VVCBPRiBUSEUgVVNFIE9GIFRISVMgU09GVFdBUkUsIEVWRU4gSUYgQURWSVNFRCBPRiBUSEUg UE9TU0lCSUxJVFkgT0YKKyAqIFNVQ0ggREFNQUdFLgorICoKKyAqLworCisjaWZuZGVmIE1JRElf SAorI2RlZmluZSBNSURJX0gKKworI2luY2x1ZGUgPHN5cy90eXBlcy5oPgorI2luY2x1ZGUgPHN5 cy9tYWxsb2MuaD4KKworTUFMTE9DX0RFQ0xBUkUoTV9NSURJKTsKKworI2RlZmluZSBNX1JYCQkw eDAxCisjZGVmaW5lIE1fVFgJCTB4MDIKKyNkZWZpbmUgTV9SWEVOCQkweDA0CisjZGVmaW5lIE1f VFhFTgkJMHgwOAorCisjZGVmaW5lIE1JRElfVFlQRSB1bnNpZ25lZCBjaGFyCisKK3N0cnVjdCBz bmRfbWlkaTsKKworc3RydWN0IHNuZF9taWRpICptaWRpX2luaXQoa29ial9jbGFzc190IF9tcHVf Y2xzLCBpbnQgX3VuaXQsIGludCBfY2hhbm5lbCwgCisJCQl2b2lkICpjb29raWUpOworaW50IG1p ZGlfdW5pbml0KHN0cnVjdCBzbmRfbWlkaSAqIF9tKTsKK2ludCBtaWRpX291dChzdHJ1Y3Qgc25k X21pZGkgKiBfbSwgTUlESV9UWVBFICogX2J1ZiwgaW50IF9zaXplKTsKK2ludCBtaWRpX2luKHN0 cnVjdCBzbmRfbWlkaSAqIF9tLCBNSURJX1RZUEUgKiBfYnVmLCBpbnQgX3NpemUpOworCitrb2Jq X3QgbWlkaW1hcHBlcl9hZGRzZXEodm9pZCAqYXJnMSwgaW50ICp1bml0LCB2b2lkICoqY29va2ll KTsKK2ludCBtaWRpbWFwcGVyX29wZW4odm9pZCAqYXJnMSwgdm9pZCAqKmNvb2tpZSk7CitpbnQg bWlkaW1hcHBlcl9jbG9zZSh2b2lkICphcmcxLCB2b2lkICpjb29raWUpOwora29ial90IG1pZGlt YXBwZXJfZmV0Y2hfc3ludGgodm9pZCAqYXJnLCB2b2lkICpjb29raWUsIGludCB1bml0KTsKKwor I2VuZGlmCkluZGV4OiBzeXMvZGV2L3NvdW5kL21pZGkvbWlkaXEuaAo9PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09ClJDUyBm aWxlOiBzeXMvZGV2L3NvdW5kL21pZGkvbWlkaXEuaApkaWZmIC1OIHN5cy9kZXYvc291bmQvbWlk aS9taWRpcS5oCi0tLSAvZGV2L251bGwJMSBKYW4gMTk3MCAwMDowMDowMCAtMDAwMAorKysgc3lz L2Rldi9zb3VuZC9taWRpL21pZGlxLmgJNSBNYXIgMjAwNSAxNzowNjo0MSAtMDAwMApAQCAtMCww ICsxLDEwMyBAQAorCisvKgorICogKGMpIDIwMDMgTWF0aGV3IEthbm5lcgorICogCisgKiBSZWRp c3RyaWJ1dGlvbiBhbmQgdXNlIGluIHNvdXJjZSBhbmQgYmluYXJ5IGZvcm1zLCB3aXRoIG9yIHdp dGhvdXQKKyAqIG1vZGlmaWNhdGlvbiwgYXJlIHBlcm1pdHRlZCBwcm92aWRlZCB0aGF0IHRoZSBm b2xsb3dpbmcgY29uZGl0aW9ucyBhcmUKKyAqIG1ldDogMS4gUmVkaXN0cmlidXRpb25zIG9mIHNv dXJjZSBjb2RlIG11c3QgcmV0YWluIHRoZSBhYm92ZSBjb3B5cmlnaHQKKyAqIG5vdGljZSwgdGhp cyBsaXN0IG9mIGNvbmRpdGlvbnMgYW5kIHRoZSBmb2xsb3dpbmcgZGlzY2xhaW1lci4gMi4KKyAq IFJlZGlzdHJpYnV0aW9ucyBpbiBiaW5hcnkgZm9ybSBtdXN0IHJlcHJvZHVjZSB0aGUgYWJvdmUg Y29weXJpZ2h0IG5vdGljZSwKKyAqIHRoaXMgbGlzdCBvZiBjb25kaXRpb25zIGFuZCB0aGUgZm9s bG93aW5nIGRpc2NsYWltZXIgaW4gdGhlIGRvY3VtZW50YXRpb24KKyAqIGFuZC9vciBvdGhlciBt YXRlcmlhbHMgcHJvdmlkZWQgd2l0aCB0aGUgZGlzdHJpYnV0aW9uLgorICogCisgKiBUSElTIFNP RlRXQVJFIElTIFBST1ZJREVEIEJZIFRIRSBBVVRIT1IgQU5EIENPTlRSSUJVVE9SUyBgYEFTIElT JycgQU5EIEFOWQorICogRVhQUkVTUyBPUiBJTVBMSUVEIFdBUlJBTlRJRVMsIElOQ0xVRElORywg QlVUIE5PVCBMSU1JVEVEIFRPLCBUSEUgSU1QTElFRAorICogV0FSUkFOVElFUyBPRiBNRVJDSEFO VEFCSUxJVFkgQU5EIEZJVE5FU1MgRk9SIEEgUEFSVElDVUxBUiBQVVJQT1NFIEFSRQorICogRElT Q0xBSU1FRC4gIElOIE5PIEVWRU5UIFNIQUxMIFRIRSBBVVRIT1IgT1IgQ09OVFJJQlVUT1JTIEJF IExJQUJMRSBGT1IKKyAqIEFOWSBESVJFQ1QsIElORElSRUNULCBJTkNJREVOVEFMLCBTUEVDSUFM LCBFWEVNUExBUlksIE9SIENPTlNFUVVFTlRJQUwKKyAqIERBTUFHRVMgKElOQ0xVRElORywgQlVU IE5PVCBMSU1JVEVEIFRPLCBQUk9DVVJFTUVOVCBPRiBTVUJTVElUVVRFIEdPT0RTIE9SCisgKiBT RVJWSUNFUzsgTE9TUyBPRiBVU0UsIERBVEEsIE9SIFBST0ZJVFM7IE9SIEJVU0lORVNTIElOVEVS UlVQVElPTikgSE9XRVZFUgorICogQ0FVU0VEIEFORCBPTiBBTlkgVEhFT1JZIE9GIExJQUJJTElU WSwgV0hFVEhFUiBJTiBDT05UUkFDVCwgU1RSSUNUCisgKiBMSUFCSUxJVFksIE9SIFRPUlQgKElO Q0xVRElORyBORUdMSUdFTkNFIE9SIE9USEVSV0lTRSkgQVJJU0lORyBJTiBBTlkgV0FZCisgKiBP VVQgT0YgVEhFIFVTRSBPRiBUSElTIFNPRlRXQVJFLCBFVkVOIElGIEFEVklTRUQgT0YgVEhFIFBP U1NJQklMSVRZIE9GCisgKiBTVUNIIERBTUFHRS4KKyAqCisgKi8KKworI2lmbmRlZiBNSURJUV9I CisKKyNkZWZpbmUgTUlESVFfTU9WRShhLGIsYykgYmNvcHkoYixhLGMpCisKKyNkZWZpbmUgTUlE SVFfSEVBRChuYW1lLCB0eXBlKSAgICAgICAgICBcCitzdHJ1Y3QgbmFtZSB7ICAgICAgICAgICAg ICAgICAgICAgICAgICAgXAorICAgICAgICBpbnQgaCwgdCwgczsgICAgICAgICAgICAgICAgICAg IFwKKyAgICAgICAgdHlwZSAqIGI7ICAgICAgICAgICAgICAgICAgICAgICAgXAorfSAKKworI2Rl ZmluZSBNSURJUV9JTklUKGhlYWQsIGJ1Ziwgc2l6ZSkgZG8geyAgICAgICAgICAgICAgICBcCisg ICAgICAgIChoZWFkKS5oPShoZWFkKS50PTA7ICAgICAgICAgICAgICAgICAgICAgICAgICBcCisg ICAgICAgIChoZWFkKS5zPXNpemU7ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgXAor ICAgICAgICAoaGVhZCkuYj1idWY7ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFwK K30gd2hpbGUgKDApCisKKyNkZWZpbmUgTUlESVFfRU1QVFkoaGVhZCkgICAgICAgKChoZWFkKS5o ID09IChoZWFkKS50ICkKKworI2RlZmluZSBNSURJUV9MRU5CQVNFKGhlYWQpICAgICAgICAgKCho ZWFkKS5oIC0gKGhlYWQpLnQgPCAwID8gXAorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIChoZWFkKS5oIC0gKGhlYWQpLnQgKyAoaGVhZCkucyA6IFwKKyAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAoaGVhZCkuaCAtIChoZWFkKS50KQorCisjZGVm aW5lIE1JRElRX0ZVTEwoaGVhZCkgICAgICAgICgoaGVhZCkuaCA9PSAtMSkKKyNkZWZpbmUgTUlE SVFfQVZBSUwoaGVhZCkgICAgICAgKE1JRElRX0ZVTEwoaGVhZCkgPyAwIDogKGhlYWQpLnMgLSBN SURJUV9MRU5CQVNFKGhlYWQpKQorI2RlZmluZSBNSURJUV9MRU4oaGVhZCkJCSgoaGVhZCkucyAt IE1JRElRX0FWQUlMKGhlYWQpKQorI2RlZmluZSBNSURJUV9ERUJVRyAwCisvKgorICogTm8gcHJv dGVjdGlvbiBhZ2FpbnN0IG92ZXJmbG93LCB1bmRlcmZsb3cKKyAqLworI2RlZmluZSBNSURJUV9F TlEoaGVhZCwgYnVmLCBzaXplKSBkbyB7ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcCisJCWlmKE1JRElRX0RFQlVHKVwKKyAg ICAgICAgICAgICAgICAJcHJpbnRmKCIjMSAlcCAlcCBieXRlcyBjb3BpZWQgJWpkIHRyYW4gcmVx IHMgJWQgaCAlZCB0ICVkXG4iLCAgICAgICAgICAgIFwKKwkJCSAgICAgICAmKGhlYWQpLmJbKGhl YWQpLmhdLCAoYnVmKSwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgXAor CQkJICAgICAgIChpbnRtYXhfdCkoc2l6ZW9mKCooaGVhZCkuYikgKiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBcCisJCQkJCSAgTUlOKCAoc2l6ZSksIChoZWFkKS5zIC0gKGhl YWQpLmgpICksICAgICAgICAgICAgICAgICAgIFwKKwkJCSAgICAgICAoc2l6ZSksIChoZWFkKS5o LCAoaGVhZCkudCk7ICAgICAgICAgICAgICAgXAorICAgICAgICAgICAgICAgIE1JRElRX01PVkUo JihoZWFkKS5iWyhoZWFkKS5oXSwgKGJ1ZiksIHNpemVvZigqKGhlYWQpLmIpICogTUlOKChzaXpl KSwgKGhlYWQpLnMgLSAoaGVhZCkuaCkpOyAgICAgICAgICAgICAgICAgICAgICAgXAorICAgICAg ICAgICAgICAgIGlmKCAoaGVhZCkucyAtIChoZWFkKS5oIDwgKHNpemUpICkgeyAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcCisJCQlpZihNSURJUV9E RUJVRykgXAorICAgICAgICAgICAgICAgICAgICAgICAgCXByaW50ZigiIzIgJXAgJXAgYnl0ZXMg Y29waWVkICVqZFxuIiwgIChoZWFkKS5iLCAoYnVmKSArIChoZWFkKS5zIC0gKGhlYWQpLmgsIChp bnRtYXhfdClzaXplb2YoKihoZWFkKS5iKSAqICgoc2l6ZSkgLSAoaGVhZCkucyArIChoZWFkKS5o KSApOyAgICAgIFwKKyAgICAgICAgICAgICAgICAgICAgICAgIE1JRElRX01PVkUoKGhlYWQpLmIs IChidWYpICsgKGhlYWQpLnMgLSAoaGVhZCkuaCwgc2l6ZW9mKCooaGVhZCkuYikgKiAoKHNpemUp IC0gKGhlYWQpLnMgKyAoaGVhZCkuaCkgKTsgICAgICBcCisJCX0gXAorICAgICAgICAgICAgICAg IChoZWFkKS5oKz0oc2l6ZSk7ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFwKKyAgICAgICAgICAgICAgICAoaGVh ZCkuaCU9KGhlYWQpLnM7ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgXAorCQlpZihNSURJUV9FTVBUWShoZWFkKSkgKGhl YWQpLmg9LTE7IFwKKwkJaWYoTUlESVFfREVCVUcpXAorICAgICAgICAgICAgICAgIAlwcmludGYo IiNFIGggJWQgdCAlZFxuIiwgKGhlYWQpLmgsIChoZWFkKS50KTsgICAgICAgICAgICAgICAgICAg ICAgIFwKK30gd2hpbGUgKDApCisKKyNkZWZpbmUgTUlESVFfREVRX0koaGVhZCwgYnVmLCBzaXpl LCBtb3ZlLCB1cGRhdGUpIGRvIHsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIFwKKwkJaWYoTUlESVFfRlVMTChoZWFkKSkgKGhl YWQpLmg9KGhlYWQpLnQ7IFwKKwkJaWYoTUlESVFfREVCVUcpXAorICAgICAgICAgICAgICAgIAlw cmludGYoIiMxICVwICVwIGJ5dGVzIGNvcGllZCAlamQgdHJhbiByZXEgcyAlZCBoICVkIHQgJWRc biIsICYoaGVhZCkuYlsoaGVhZCkudF0sIChidWYpLCAoaW50bWF4X3Qpc2l6ZW9mKCooaGVhZCku YikgKiBNSU4oKHNpemUpLCAoaGVhZCkucyAtIChoZWFkKS50KSwgKHNpemUpLCAoaGVhZCkuaCwg KGhlYWQpLnQpOyAgICAgICAgICAgICAgICAgICAgICAgXAorICAgICAgICAgICAgICAgIGlmICht b3ZlKSBNSURJUV9NT1ZFKChidWYpLCAmKGhlYWQpLmJbKGhlYWQpLnRdLCBzaXplb2YoKihoZWFk KS5iKSAqIE1JTigoc2l6ZSksIChoZWFkKS5zIC0gKGhlYWQpLnQpKTsgICAgICAgICAgICAgICAg ICAgICAgIFwKKyAgICAgICAgICAgICAgICBpZiggKGhlYWQpLnMgLSAoaGVhZCkudCA8IChzaXpl KSApIHsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg XAorCQkJaWYoTUlESVFfREVCVUcpIFwKKyAgICAgICAgICAgICAgICAgICAgICAgIAlwcmludGYo IiMyICVwICVwIGJ5dGVzIGNvcGllZCAlamRcbiIsICAoaGVhZCkuYiwgKGJ1ZikgKyAoaGVhZCku cyAtIChoZWFkKS50LCAoaW50bWF4X3Qpc2l6ZW9mKCooaGVhZCkuYikgKiAoKHNpemUpIC0gKGhl YWQpLnMgKyAoaGVhZCkudCkgKTsgICAgICBcCisgICAgICAgICAgICAgICAgICAgICAgICBpZiAo bW92ZSkgTUlESVFfTU9WRSgoYnVmKSArIChoZWFkKS5zIC0gKGhlYWQpLnQsIChoZWFkKS5iLCBz aXplb2YoKihoZWFkKS5iKSAqICgoc2l6ZSkgLSAoaGVhZCkucyArIChoZWFkKS50KSApOyAgICAg IFwKKwkJfSBcCisJCWlmICh1cGRhdGUpIHsgXAorICAgICAgICAgICAgICAgIChoZWFkKS50Kz0o c2l6ZSk7ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIFwKKyAgICAgICAgICAgICAgICAoaGVhZCkudCU9KGhlYWQp LnM7ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgXAorCQl9IGVsc2UgeyBcCisJCSAgaWYgKE1JRElRX0VNUFRZKGhlYWQp KSAoaGVhZCkuaD0tMTsgXAorCQl9IFwKKwkJaWYoTUlESVFfREVCVUcpXAorICAgICAgICAgICAg ICAgIAlwcmludGYoIiNFIGggJWQgdCAlZFxuIiwgKGhlYWQpLmgsIChoZWFkKS50KTsgICAgICAg ICAgICAgICAgICAgICAgIFwKK30gd2hpbGUgKDApCisKKyNkZWZpbmUgTUlESVFfU0laRShoZWFk KSAoKGhlYWQpLnMpCisjZGVmaW5lIE1JRElRX0NMRUFSKGhlYWQpICgoaGVhZCkuaCA9IChoZWFk KS50ID0gMCkKKyNkZWZpbmUgTUlESVFfQlVGKGhlYWQpICgoaGVhZCkuYikKKyNkZWZpbmUgTUlE SVFfREVRKGhlYWQsIGJ1Ziwgc2l6ZSkgTUlESVFfREVRX0koaGVhZCwgYnVmLCBzaXplLCAxLCAx KQorI2RlZmluZSBNSURJUV9QRUVLKGhlYWQsIGJ1Ziwgc2l6ZSkgTUlESVFfREVRX0koaGVhZCwg YnVmLCBzaXplLCAxLCAwKQorI2RlZmluZSBNSURJUV9QT1AoaGVhZCwgc2l6ZSkgTUlESVFfREVR X0koaGVhZCwgJmhlYWQsIHNpemUsIDAsIDEpCisKKyNlbmRpZgpJbmRleDogc3lzL2Rldi9zb3Vu ZC9taWRpL21wdTQwMS5jCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT0KUkNTIGZpbGU6IHN5cy9kZXYvc291bmQvbWlkaS9t cHU0MDEuYwpkaWZmIC1OIHN5cy9kZXYvc291bmQvbWlkaS9tcHU0MDEuYwotLS0gL2Rldi9udWxs CTEgSmFuIDE5NzAgMDA6MDA6MDAgLTAwMDAKKysrIHN5cy9kZXYvc291bmQvbWlkaS9tcHU0MDEu Ywk1IE1hciAyMDA1IDE2OjU1OjU4IC0wMDAwCkBAIC0wLDAgKzEsMjgyIEBACisvKgorICogKGMp IDIwMDMgTWF0aGV3IEthbm5lcgorICogCisgKiBSZWRpc3RyaWJ1dGlvbiBhbmQgdXNlIGluIHNv dXJjZSBhbmQgYmluYXJ5IGZvcm1zLCB3aXRoIG9yIHdpdGhvdXQKKyAqIG1vZGlmaWNhdGlvbiwg YXJlIHBlcm1pdHRlZCBwcm92aWRlZCB0aGF0IHRoZSBmb2xsb3dpbmcgY29uZGl0aW9ucyBhcmUK KyAqIG1ldDogMS4gUmVkaXN0cmlidXRpb25zIG9mIHNvdXJjZSBjb2RlIG11c3QgcmV0YWluIHRo ZSBhYm92ZSBjb3B5cmlnaHQKKyAqIG5vdGljZSwgdGhpcyBsaXN0IG9mIGNvbmRpdGlvbnMgYW5k IHRoZSBmb2xsb3dpbmcgZGlzY2xhaW1lci4gMi4KKyAqIFJlZGlzdHJpYnV0aW9ucyBpbiBiaW5h cnkgZm9ybSBtdXN0IHJlcHJvZHVjZSB0aGUgYWJvdmUgY29weXJpZ2h0IG5vdGljZSwKKyAqIHRo aXMgbGlzdCBvZiBjb25kaXRpb25zIGFuZCB0aGUgZm9sbG93aW5nIGRpc2NsYWltZXIgaW4gdGhl IGRvY3VtZW50YXRpb24KKyAqIGFuZC9vciBvdGhlciBtYXRlcmlhbHMgcHJvdmlkZWQgd2l0aCB0 aGUgZGlzdHJpYnV0aW9uLgorICogCisgKiBUSElTIFNPRlRXQVJFIElTIFBST1ZJREVEIEJZIFRI RSBBVVRIT1IgQU5EIENPTlRSSUJVVE9SUyBgYEFTIElTJycgQU5EIEFOWQorICogRVhQUkVTUyBP UiBJTVBMSUVEIFdBUlJBTlRJRVMsIElOQ0xVRElORywgQlVUIE5PVCBMSU1JVEVEIFRPLCBUSEUg SU1QTElFRAorICogV0FSUkFOVElFUyBPRiBNRVJDSEFOVEFCSUxJVFkgQU5EIEZJVE5FU1MgRk9S IEEgUEFSVElDVUxBUiBQVVJQT1NFIEFSRQorICogRElTQ0xBSU1FRC4gIElOIE5PIEVWRU5UIFNI QUxMIFRIRSBBVVRIT1IgT1IgQ09OVFJJQlVUT1JTIEJFIExJQUJMRSBGT1IKKyAqIEFOWSBESVJF Q1QsIElORElSRUNULCBJTkNJREVOVEFMLCBTUEVDSUFMLCBFWEVNUExBUlksIE9SIENPTlNFUVVF TlRJQUwKKyAqIERBTUFHRVMgKElOQ0xVRElORywgQlVUIE5PVCBMSU1JVEVEIFRPLCBQUk9DVVJF TUVOVCBPRiBTVUJTVElUVVRFIEdPT0RTIE9SCisgKiBTRVJWSUNFUzsgTE9TUyBPRiBVU0UsIERB VEEsIE9SIFBST0ZJVFM7IE9SIEJVU0lORVNTIElOVEVSUlVQVElPTikgSE9XRVZFUgorICogQ0FV U0VEIEFORCBPTiBBTlkgVEhFT1JZIE9GIExJQUJJTElUWSwgV0hFVEhFUiBJTiBDT05UUkFDVCwg U1RSSUNUCisgKiBMSUFCSUxJVFksIE9SIFRPUlQgKElOQ0xVRElORyBORUdMSUdFTkNFIE9SIE9U SEVSV0lTRSkgQVJJU0lORyBJTiBBTlkgV0FZCisgKiBPVVQgT0YgVEhFIFVTRSBPRiBUSElTIFNP RlRXQVJFLCBFVkVOIElGIEFEVklTRUQgT0YgVEhFIFBPU1NJQklMSVRZIE9GCisgKiBTVUNIIERB TUFHRS4KKyAqCisgKi8KKworI2luY2x1ZGUgPHN5cy9wYXJhbS5oPgorI2luY2x1ZGUgPHN5cy90 eXBlcy5oPgorI2luY2x1ZGUgPHN5cy9wYXJhbS5oPgorI2luY2x1ZGUgPHN5cy9xdWV1ZS5oPgor I2luY2x1ZGUgPHN5cy9rZXJuZWwuaD4KKyNpbmNsdWRlIDxzeXMvbG9jay5oPgorI2luY2x1ZGUg PHN5cy9tdXRleC5oPgorI2luY2x1ZGUgPHN5cy9wcm9jLmg+CisjaW5jbHVkZSA8c3lzL3N5c3Rt Lmg+CisjaW5jbHVkZSA8c3lzL2tvYmouaD4KKyNpbmNsdWRlIDxzeXMvbWFsbG9jLmg+CisjaW5j bHVkZSA8c3lzL2J1cy5oPiAvKiB0byBnZXQgZHJpdmVyX2ludHJfdCAqLworCisjaW5jbHVkZSA8 ZGV2L3NvdW5kL21pZGkvbXB1NDAxLmg+CisjaW5jbHVkZSA8ZGV2L3NvdW5kL21pZGkvbWlkaS5o PgorCisjaW5jbHVkZSAibXB1X2lmLmgiCisjaW5jbHVkZSAibXB1Zm9pX2lmLmgiCisKKyNkZWZp bmUgTVBVX0RBVEFQT1JUICAgMAorI2RlZmluZSBNUFVfQ01EUE9SVCAgICAxCisjZGVmaW5lIE1Q VV9TVEFUUE9SVCAgIDEKKyNkZWZpbmUgTVBVX1JFU0VUICAgICAgMHhmZgorI2RlZmluZSBNUFVf VUFSVCAgICAgICAweDNmCisjZGVmaW5lIE1QVV9BQ0sgICAgICAgIDB4ZmUKKyNkZWZpbmUgTVBV X1NUQVRNQVNLICAgMHhjMAorI2RlZmluZSBNUFVfT1VUUFVUQlVTWSAweDQwCisjZGVmaW5lIE1Q VV9JTlBVVEJVU1kgIDB4ODAKKyNkZWZpbmUgTVBVX1RSWURBVEEgNTAKKyNkZWZpbmUgTVBVX0RF TEFZICAgMjUwMAorCisjZGVmaW5lIENNRChtLGQpCU1QVUZPSV9XUklURShtLCBtLT5jb29raWUs IE1QVV9DTURQT1JULGQpCisjZGVmaW5lIFNUQVRVUyhtKQlNUFVGT0lfUkVBRChtLCBtLT5jb29r aWUsIE1QVV9TVEFUUE9SVCkKKyNkZWZpbmUgUkVBRChtKQkJTVBVRk9JX1JFQUQobSwgbS0+Y29v a2llLCBNUFVfREFUQVBPUlQpCisjZGVmaW5lIFdSSVRFKG0sZCkJTVBVRk9JX1dSSVRFKG0sIG0t PmNvb2tpZSwgTVBVX0RBVEFQT1JULGQpCisKK3N0cnVjdCBtcHU0MDEgeworCUtPQkpfRklFTERT OworCXN0cnVjdCBzbmRfbWlkaSAqbWlkOworCWludCBmbGFnczsKKwlkcml2ZXJfaW50cl90ICpz aTsKKwl2b2lkICpjb29raWU7CisJc3RydWN0IGNhbGxvdXQgdGltZXI7Cit9OworCitzdGF0aWMg dm9pZCBtcHU0MDFfdGltZW91dCh2b2lkICptKSA7CitzdGF0aWMgbXB1NDAxX2ludHJfdCBtcHU0 MDFfaW50cjsKKworc3RhdGljIGludCBtcHU0MDFfbWluaXQoa29ial90IG9iaiwgc3RydWN0IG1w dTQwMSAqbSk7CitzdGF0aWMgaW50IG1wdTQwMV9tdW5pbml0KGtvYmpfdCBvYmosIHN0cnVjdCBt cHU0MDEgKm0pOworc3RhdGljIGludCBtcHU0MDFfbWlucXNpemUoa29ial90IG9iaiwgc3RydWN0 IG1wdTQwMSAqbSk7CitzdGF0aWMgaW50IG1wdTQwMV9tb3V0cXNpemUoa29ial90IG9iaiwgc3Ry dWN0IG1wdTQwMSAqbSk7CitzdGF0aWMgdm9pZCBtcHU0MDFfbWNhbGxiYWNrKGtvYmpfdCBvYmos IHN0cnVjdCBtcHU0MDEgKm0sIGludCBmbGFncyk7CitzdGF0aWMgdm9pZCBtcHU0MDFfbWNhbGxi YWNrcChrb2JqX3Qgb2JqLCBzdHJ1Y3QgbXB1NDAxICptLCBpbnQgZmxhZ3MpOworc3RhdGljIGNv bnN0IGNoYXIgKm1wdTQwMV9tZGVzY3Ioa29ial90IG9iaiwgc3RydWN0IG1wdTQwMSAqbSwgaW50 IHZlcmJvc2l0eSk7CitzdGF0aWMgY29uc3QgY2hhciAqbXB1NDAxX21wcm92aWRlcihrb2JqX3Qg b2JqLCBzdHJ1Y3QgbXB1NDAxICptKTsKKworc3RhdGljIGtvYmpfbWV0aG9kX3QgbXB1NDAxX21l dGhvZHNbXSA9IHsKKwlLT0JKTUVUSE9EKG1wdV9pbml0LG1wdTQwMV9taW5pdCksCisJS09CSk1F VEhPRChtcHVfdW5pbml0LG1wdTQwMV9tdW5pbml0KSwKKwlLT0JKTUVUSE9EKG1wdV9pbnFzaXpl LG1wdTQwMV9taW5xc2l6ZSksCisJS09CSk1FVEhPRChtcHVfb3V0cXNpemUsbXB1NDAxX21vdXRx c2l6ZSksCisJS09CSk1FVEhPRChtcHVfY2FsbGJhY2ssbXB1NDAxX21jYWxsYmFjayksCisJS09C Sk1FVEhPRChtcHVfY2FsbGJhY2twLG1wdTQwMV9tY2FsbGJhY2twKSwKKwlLT0JKTUVUSE9EKG1w dV9kZXNjcixtcHU0MDFfbWRlc2NyKSwKKwlLT0JKTUVUSE9EKG1wdV9wcm92aWRlcixtcHU0MDFf bXByb3ZpZGVyKSwKKyAgICAgICAgeyAwLCAwIH0KK307CisKK0RFRklORV9DTEFTUyhtcHU0MDEs IG1wdTQwMV9tZXRob2RzLCAwKTsKKwordm9pZAorbXB1NDAxX3RpbWVvdXQodm9pZCAqYSkgCit7 CXN0cnVjdCBtcHU0MDEgKm09KHN0cnVjdCBtcHU0MDEgKilhOworCisJaWYgKG0tPnNpKQorCQko bS0+c2kpKG0tPmNvb2tpZSk7CisKK30KK3N0YXRpYyBpbnQKK21wdTQwMV9pbnRyKHN0cnVjdCBt cHU0MDEgKm0pCit7CisjZGVmaW5lIE1QVV9JTlRSX0JVRgkxNgorCU1JRElfVFlQRSBiW01QVV9J TlRSX0JVRl07CisJaW50IGk7CisJaW50IHM7CisvKgorCXByaW50ZigibXB1NDAxX2ludHJcbiIp OworKi8KKyNkZWZpbmUgUlhSRFkobSkgKCAoU1RBVFVTKG0pICYgTVBVX0lOUFVUQlVTWSkgPT0g MCkKKyNkZWZpbmUgVFhSRFkobSkgKCAoU1RBVFVTKG0pICYgTVBVX09VVFBVVEJVU1kpID09IDAp CisjaWYgMAorI2RlZmluZSBEKHgsbCkgcHJpbnRmKCJtcHU0MDFfaW50ciAlZCAleCAlcyAlc1xu IixsLCB4LCB4Jk1QVV9JTlBVVEJVU1k/IlJYIjoiIiwgeCZNUFVfT1VUUFVUQlVTWT8iVFgiOiIi KQorI2Vsc2UKKyNkZWZpbmUgRCh4LGwpCisjZW5kaWYKKwlpPTA7CisJcyA9IFNUQVRVUyhtKTsK KwlEKHMsMSk7CisJd2hpbGUgKCAocyZNUFVfSU5QVVRCVVNZKSA9PSAwICYmIGk8TVBVX0lOVFJf QlVGKSB7CisJCWJbaV09UkVBRChtKTsKKy8qCisJCXByaW50ZigibXB1NDAxX2ludHIgaW4gaSAl ZCBkICVkXG4iLCBpLCBiW2ldKTsKKyovCisJCWkrKzsKKwlzID0gU1RBVFVTKG0pOworCX0KKwlp ZiAoaSkgbWlkaV9pbihtLT5taWQsIGIsIGkpOworCWk9MDsKKwl3aGlsZSAoICEocyZNUFVfT1VU UFVUQlVTWSkgJiYgaTxNUFVfSU5UUl9CVUYpIHsKKwkJaWYobWlkaV9vdXQobS0+bWlkLCBiLCAx KSkgeyAKKy8qCisJCQlwcmludGYoIm1wdTQwMV9pbnRyIG91dCBpICVkIGQgJWRcbiIsIGksIGJb MF0pOworKi8KKwkKKwkJCVdSSVRFKG0sICpiKTsKKwkJfQorCQllbHNlIHsKKy8qCisJCQlwcmlu dGYoIm1wdTQwMV9pbnRyIHdyaXRlOiBubyBvdXRwdXRcbiIpOworKi8KKwkJCXJldHVybiAwOwor CQl9CisJCWkrKzsKKwkvKiBERUxBWSgxMDApOyAqLworCXMgPSBTVEFUVVMobSk7CisJfQorCisJ aWYgKChtLT5mbGFncyAmIE1fVFhFTikgJiYgKG0tPnNpKSApIHsKKwkgICAgY2FsbG91dF9yZXNl dCgmbS0+dGltZXIsIDEsIG1wdTQwMV90aW1lb3V0LCBtKTsKKwl9CisKKwlyZXR1cm4gKG0tPmZs YWdzICYgTV9UWEVOKSA9PSBNX1RYRU47Cit9CisKK3N0cnVjdCBtcHU0MDEgKgorbXB1NDAxX2lu aXQoa29ial9jbGFzc190IGNscywgdm9pZCAqY29va2llLGRyaXZlcl9pbnRyX3Qgc29mdGludHIs IG1wdTQwMV9pbnRyX3QgKipjYikKK3sKKwlzdHJ1Y3QgbXB1NDAxICptOworCisJKmNiID0gTlVM TDsKKwltID0gbWFsbG9jKHNpemVvZigqbSksIE1fTUlESSwgTV9OT1dBSVQgfCBNX1pFUk8pOwor CisJaWYoIW0pCisJCXJldHVybiBOVUxMOworCisJa29ial9pbml0KChrb2JqX3QpbSwgY2xzKTsK KworCWNhbGxvdXRfaW5pdCgmbS0+dGltZXIsIDEpOworCisJbS0+c2kgPSBzb2Z0aW50cjsKKwlt LT5jb29raWUgPSBjb29raWU7CisJbS0+ZmxhZ3MgPSAwOworCisJbS0+bWlkID0gbWlkaV9pbml0 KCZtcHU0MDFfY2xhc3MsMCwwLG0pOworCWlmICghbS0+bWlkKQorCQlnb3RvIGVycjsKKwkqY2Ig PSBtcHU0MDFfaW50cjsKKwlyZXR1cm4gbTsKK2VycjoKKwlwcmludGYoIm1wdTQwMV9pbml0IGVy cm9yXG4iKTsKKwlmcmVlKG0sIE1fTUlESSk7CisJcmV0dXJuIE5VTEw7Cit9CisKK2ludAorbXB1 NDAxX3VuaW5pdChzdHJ1Y3QgbXB1NDAxICptKQoreworCWludCByZXR2YWw7CisKKwlDTUQobSwg TVBVX1JFU0VUKTsKKwlyZXR2YWwgPSBtaWRpX3VuaW5pdChtLT5taWQpOworCWlmIChyZXR2YWwp CisJCXJldHVybiByZXR2YWw7CisJZnJlZShtLCBNX01JREkpOworCXJldHVybiAwOworfQorCitz dGF0aWMgaW50CittcHU0MDFfbWluaXQoa29ial90IG9iaiwgc3RydWN0IG1wdTQwMSAqbSkKK3sK KwlpbnQgaTsKKworCUNNRChtLCBNUFVfUkVTRVQpOworCUNNRChtLCBNUFVfVUFSVCk7CisJcmV0 dXJuIDA7CisJaT0wOworCXdoaWxlKCsraTwyMDAwKSB7CisJCWlmKFJYUkRZKG0pKQorCQkJaWYo UkVBRChtKSA9PSBNUFVfQUNLKQorCQkJCWJyZWFrOworCX0KKworCWlmKCBpIDwgMjAwMCApIHsK KwkJQ01EKG0sIE1QVV9VQVJUKTsKKwkJcmV0dXJuIDA7CisJfQorCXByaW50ZigibXB1NDAxX21p bml0IGZhaWxlZCBhY3RpdmUgc2Vuc2luZ1xuIik7CisJcmV0dXJuIDE7Cit9CisKKworaW50Citt cHU0MDFfbXVuaW5pdChrb2JqX3Qgb2JqLCBzdHJ1Y3QgbXB1NDAxICptKQoreworCisJcmV0dXJu IE1QVUZPSV9VTklOSVQobSwgbS0+Y29va2llKTsKK30KKworaW50CittcHU0MDFfbWlucXNpemUo a29ial90IG9iaiwgc3RydWN0IG1wdTQwMSAqbSkKK3sKKwlyZXR1cm4gMTI4OworfQorCitpbnQK K21wdTQwMV9tb3V0cXNpemUoa29ial90IG9iaiwgc3RydWN0IG1wdTQwMSAqbSkKK3sKKwlyZXR1 cm4gMTI4OworfQorCitzdGF0aWMgdm9pZAorbXB1NDAxX21jYWxsYmFjayhrb2JqX3Qgb2JqLCBz dHJ1Y3QgbXB1NDAxICptLCBpbnQgZmxhZ3MpCit7CisjaWYgMAorCXByaW50ZigibXB1NDAxX2Nh bGxiYWNrICVzICVzICVzICVzXG4iLCAKKwkJZmxhZ3MgJiBNX1JYID8gIk1fUlgiIDogIiIsCisJ CWZsYWdzICYgTV9UWCA/ICJNX1RYIiA6ICIiLAorCQlmbGFncyAmIE1fUlhFTiA/ICJNX1JYRU4i IDogIiIsCisJCWZsYWdzICYgTV9UWEVOID8gIk1fVFhFTiIgOiAiIiApOworI2VuZGlmCisJaWYg KGZsYWdzICYgTV9UWEVOICYmIG0tPnNpKSB7CisJCWNhbGxvdXRfcmVzZXQoJm0tPnRpbWVyLCAx LCBtcHU0MDFfdGltZW91dCwgbSk7CisJfQorCisJbS0+ZmxhZ3MgPSBmbGFnczsKK30KKworc3Rh dGljIHZvaWQKK21wdTQwMV9tY2FsbGJhY2twKGtvYmpfdCBvYmosIHN0cnVjdCBtcHU0MDEgKm0s IGludCBmbGFncykKK3sKKy8qCXByaW50ZigibXB1NDAxX2NhbGxiYWNrcFxuIik7ICovCisJbXB1 NDAxX21jYWxsYmFjayhvYmosIG0sIGZsYWdzKTsKK30KKworc3RhdGljIGNvbnN0IGNoYXIgKgor bXB1NDAxX21kZXNjcihrb2JqX3Qgb2JqLCBzdHJ1Y3QgbXB1NDAxICptLCBpbnQgdmVyYm9zaXR5 KQoreworCisJcmV0dXJuICJkZXNjciBtcHU0MDEiOworfQorCitzdGF0aWMgY29uc3QgY2hhciAq CittcHU0MDFfbXByb3ZpZGVyKGtvYmpfdCBvYmosIHN0cnVjdCBtcHU0MDEgKm0pCit7CisJcmV0 dXJuICJwcm92aWRlciBtcHU0MDEiOworfQpJbmRleDogc3lzL2Rldi9zb3VuZC9taWRpL21wdTQw MS5oCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT0KUkNTIGZpbGU6IHN5cy9kZXYvc291bmQvbWlkaS9tcHU0MDEuaApkaWZm IC1OIHN5cy9kZXYvc291bmQvbWlkaS9tcHU0MDEuaAotLS0gL2Rldi9udWxsCTEgSmFuIDE5NzAg MDA6MDA6MDAgLTAwMDAKKysrIHN5cy9kZXYvc291bmQvbWlkaS9tcHU0MDEuaAk1IE1hciAyMDA1 IDE2OjI3OjA3IC0wMDAwCkBAIC0wLDAgKzEsMzYgQEAKKy8qCisgKiAoYykgMjAwMyBNYXRoZXcg S2FubmVyCisgKiAKKyAqIFJlZGlzdHJpYnV0aW9uIGFuZCB1c2UgaW4gc291cmNlIGFuZCBiaW5h cnkgZm9ybXMsIHdpdGggb3Igd2l0aG91dAorICogbW9kaWZpY2F0aW9uLCBhcmUgcGVybWl0dGVk IHByb3ZpZGVkIHRoYXQgdGhlIGZvbGxvd2luZyBjb25kaXRpb25zIGFyZQorICogbWV0OiAxLiBS ZWRpc3RyaWJ1dGlvbnMgb2Ygc291cmNlIGNvZGUgbXVzdCByZXRhaW4gdGhlIGFib3ZlIGNvcHly aWdodAorICogbm90aWNlLCB0aGlzIGxpc3Qgb2YgY29uZGl0aW9ucyBhbmQgdGhlIGZvbGxvd2lu ZyBkaXNjbGFpbWVyLiAyLgorICogUmVkaXN0cmlidXRpb25zIGluIGJpbmFyeSBmb3JtIG11c3Qg cmVwcm9kdWNlIHRoZSBhYm92ZSBjb3B5cmlnaHQgbm90aWNlLAorICogdGhpcyBsaXN0IG9mIGNv bmRpdGlvbnMgYW5kIHRoZSBmb2xsb3dpbmcgZGlzY2xhaW1lciBpbiB0aGUgZG9jdW1lbnRhdGlv bgorICogYW5kL29yIG90aGVyIG1hdGVyaWFscyBwcm92aWRlZCB3aXRoIHRoZSBkaXN0cmlidXRp b24uCisgKiAKKyAqIFRISVMgU09GVFdBUkUgSVMgUFJPVklERUQgQlkgVEhFIEFVVEhPUiBBTkQg Q09OVFJJQlVUT1JTIGBgQVMgSVMnJyBBTkQgQU5ZCisgKiBFWFBSRVNTIE9SIElNUExJRUQgV0FS UkFOVElFUywgSU5DTFVESU5HLCBCVVQgTk9UIExJTUlURUQgVE8sIFRIRSBJTVBMSUVECisgKiBX QVJSQU5USUVTIE9GIE1FUkNIQU5UQUJJTElUWSBBTkQgRklUTkVTUyBGT1IgQSBQQVJUSUNVTEFS IFBVUlBPU0UgQVJFCisgKiBESVNDTEFJTUVELiAgSU4gTk8gRVZFTlQgU0hBTEwgVEhFIEFVVEhP UiBPUiBDT05UUklCVVRPUlMgQkUgTElBQkxFIEZPUgorICogQU5ZIERJUkVDVCwgSU5ESVJFQ1Qs IElOQ0lERU5UQUwsIFNQRUNJQUwsIEVYRU1QTEFSWSwgT1IgQ09OU0VRVUVOVElBTAorICogREFN QUdFUyAoSU5DTFVESU5HLCBCVVQgTk9UIExJTUlURUQgVE8sIFBST0NVUkVNRU5UIE9GIFNVQlNU SVRVVEUgR09PRFMgT1IKKyAqIFNFUlZJQ0VTOyBMT1NTIE9GIFVTRSwgREFUQSwgT1IgUFJPRklU UzsgT1IgQlVTSU5FU1MgSU5URVJSVVBUSU9OKSBIT1dFVkVSCisgKiBDQVVTRUQgQU5EIE9OIEFO WSBUSEVPUlkgT0YgTElBQklMSVRZLCBXSEVUSEVSIElOIENPTlRSQUNULCBTVFJJQ1QKKyAqIExJ QUJJTElUWSwgT1IgVE9SVCAoSU5DTFVESU5HIE5FR0xJR0VOQ0UgT1IgT1RIRVJXSVNFKSBBUklT SU5HIElOIEFOWSBXQVkKKyAqIE9VVCBPRiBUSEUgVVNFIE9GIFRISVMgU09GVFdBUkUsIEVWRU4g SUYgQURWSVNFRCBPRiBUSEUgUE9TU0lCSUxJVFkgT0YKKyAqIFNVQ0ggREFNQUdFLgorICoKKyAq LworCisjaWZuZGVmIE1QVTQwMV9ICisjZGVmaW5lIE1QVTQwMV9ICisKK3N0cnVjdCBtcHU0MDE7 CisKK3R5cGVkZWYgaW50IG1wdTQwMV9pbnRyX3Qoc3RydWN0IG1wdTQwMSAqIF9vYmopOworCitl eHRlcm4gc3RydWN0IG1wdTQwMSAqbXB1NDAxX2luaXQoa29ial9jbGFzc190IF9jbHMsIHZvaWQg KmNvb2tpZSwgCisJCQlkcml2ZXJfaW50cl90ICpfc29mdGludHIsbXB1NDAxX2ludHJfdCAqKl9j Yik7CitleHRlcm4gaW50IG1wdTQwMV91bmluaXQoc3RydWN0IG1wdTQwMSAqIF9vYmopOworI2Vu ZGlmCkluZGV4OiBzeXMvZGV2L3NvdW5kL21pZGkvbXB1X2lmLm0KPT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQpSQ1MgZmls ZTogc3lzL2Rldi9zb3VuZC9taWRpL21wdV9pZi5tCmRpZmYgLU4gc3lzL2Rldi9zb3VuZC9taWRp L21wdV9pZi5tCi0tLSAvZGV2L251bGwJMSBKYW4gMTk3MCAwMDowMDowMCAtMDAwMAorKysgc3lz L2Rldi9zb3VuZC9taWRpL21wdV9pZi5tCTUgTWFyIDIwMDUgMTY6Mjc6MDcgLTAwMDAKQEAgLTAs MCArMSw0NiBAQAorI2luY2x1ZGUgPGRldi9zb3VuZC9taWRpL21pZGkuaD4KKworSU5URVJGQUNF IG1wdTsKKworTUVUSE9EIGludCBpbnFzaXpleworCXN0cnVjdCBzbmRfbWlkaSAqIF9rb2JqOwor CXZvaWQgKl9jb29raWU7Cit9OworCitNRVRIT0QgaW50IG91dHFzaXplIHsKKwlzdHJ1Y3Qgc25k X21pZGkgKiBfa29iajsKKwl2b2lkICpfY29va2llOworfTsKKworTUVUSE9EIGludCBpbml0IHsK KwlzdHJ1Y3Qgc25kX21pZGkgKiBfa29iajsKKwl2b2lkICpfY29va2llOworfTsKKworTUVUSE9E IHZvaWQgY2FsbGJhY2twIHsKKwlzdHJ1Y3Qgc25kX21pZGkgKiBfa29iajsKKwl2b2lkICpfY29v a2llOworCWludCBfZmxhZ3M7Cit9OworCitNRVRIT0Qgdm9pZCBjYWxsYmFjayB7IAorCXN0cnVj dCBzbmRfbWlkaSAqIF9rb2JqOworCXZvaWQgKl9jb29raWU7CisJaW50IF9mbGFnczsKK307CisK K01FVEhPRCBjb25zdCBjaGFyICogcHJvdmlkZXJ7CisJc3RydWN0IHNuZF9taWRpICogX2tvYmo7 CisJdm9pZCAqX2Nvb2tpZTsKK307CisKK01FVEhPRCBjb25zdCBjaGFyICogZGVzY3IgeyAKKwlz dHJ1Y3Qgc25kX21pZGkgKiBfa29iajsgCisJdm9pZCAqX2Nvb2tpZTsKKwlpbnQgX3ZlcmJvc2l0 eTsKK307CisKK01FVEhPRCBpbnQgdW5pbml0IHsgCisJc3RydWN0IHNuZF9taWRpICogX2tvYmo7 IAorCXZvaWQgKl9jb29raWU7Cit9OwpJbmRleDogc3lzL2Rldi9zb3VuZC9taWRpL21wdWZvaV9p Zi5tCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT0KUkNTIGZpbGU6IHN5cy9kZXYvc291bmQvbWlkaS9tcHVmb2lfaWYubQpk aWZmIC1OIHN5cy9kZXYvc291bmQvbWlkaS9tcHVmb2lfaWYubQotLS0gL2Rldi9udWxsCTEgSmFu IDE5NzAgMDA6MDA6MDAgLTAwMDAKKysrIHN5cy9kZXYvc291bmQvbWlkaS9tcHVmb2lfaWYubQk1 IE1hciAyMDA1IDE2OjI3OjA3IC0wMDAwCkBAIC0wLDAgKzEsMjIgQEAKKyNpbmNsdWRlIDxzeXMv YnVzLmg+CisjaW5jbHVkZSA8ZGV2L3NvdW5kL21pZGkvbXB1NDAxLmg+CisKK0lOVEVSRkFDRSBt cHVmb2k7CisKK01FVEhPRCB1bnNpZ25lZCBjaGFyIHJlYWQgeworCXN0cnVjdCBtcHU0MDEgKl9r b2JqOworCXZvaWQgKl9jb29raWU7CisJaW50IF9yZWc7Cit9OworCitNRVRIT0Qgdm9pZCB3cml0 ZSB7CisJc3RydWN0IG1wdTQwMSAqX2tvYmo7CisJdm9pZCAqX2Nvb2tpZTsKKwlpbnQgX3JlZzsK Kwl1bnNpZ25lZCBjaGFyIF9kOworfTsKKworTUVUSE9EIGludCB1bmluaXQgeworCXN0cnVjdCBt cHU0MDEgKl9rb2JqOworCXZvaWQgKl9jb29raWU7Cit9OwpJbmRleDogc3lzL2Rldi9zb3VuZC9t aWRpL3NlcXVlbmNlci5jCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT0KUkNTIGZpbGU6IHN5cy9kZXYvc291bmQvbWlkaS9z ZXF1ZW5jZXIuYwpkaWZmIC1OIHN5cy9kZXYvc291bmQvbWlkaS9zZXF1ZW5jZXIuYwotLS0gL2Rl di9udWxsCTEgSmFuIDE5NzAgMDA6MDA6MDAgLTAwMDAKKysrIHN5cy9kZXYvc291bmQvbWlkaS9z ZXF1ZW5jZXIuYwk1IE1hciAyMDA1IDE2OjU3OjQ4IC0wMDAwCkBAIC0wLDAgKzEsMjA0NiBAQAor LyoKKyAqIFRoZSBzZXF1ZW5jZXIgcGVyc29uYWxpdHkgbWFuYWdlci4KKyAqIChjKSAyMDAzIE1h dGhldyBLYW5uZXIKKyAqIENvcHlyaWdodCBieSBIYW5udSBTYXZvbGFpbmVuIDE5OTMKKyAqIAor ICogUmVkaXN0cmlidXRpb24gYW5kIHVzZSBpbiBzb3VyY2UgYW5kIGJpbmFyeSBmb3Jtcywgd2l0 aCBvciB3aXRob3V0CisgKiBtb2RpZmljYXRpb24sIGFyZSBwZXJtaXR0ZWQgcHJvdmlkZWQgdGhh dCB0aGUgZm9sbG93aW5nIGNvbmRpdGlvbnMgYXJlCisgKiBtZXQ6IDEuIFJlZGlzdHJpYnV0aW9u cyBvZiBzb3VyY2UgY29kZSBtdXN0IHJldGFpbiB0aGUgYWJvdmUgY29weXJpZ2h0CisgKiBub3Rp Y2UsIHRoaXMgbGlzdCBvZiBjb25kaXRpb25zIGFuZCB0aGUgZm9sbG93aW5nIGRpc2NsYWltZXIu IDIuCisgKiBSZWRpc3RyaWJ1dGlvbnMgaW4gYmluYXJ5IGZvcm0gbXVzdCByZXByb2R1Y2UgdGhl IGFib3ZlIGNvcHlyaWdodCBub3RpY2UsCisgKiB0aGlzIGxpc3Qgb2YgY29uZGl0aW9ucyBhbmQg dGhlIGZvbGxvd2luZyBkaXNjbGFpbWVyIGluIHRoZSBkb2N1bWVudGF0aW9uCisgKiBhbmQvb3Ig b3RoZXIgbWF0ZXJpYWxzIHByb3ZpZGVkIHdpdGggdGhlIGRpc3RyaWJ1dGlvbi4KKyAqIAorICog VEhJUyBTT0ZUV0FSRSBJUyBQUk9WSURFRCBCWSBUSEUgQVVUSE9SIEFORCBDT05UUklCVVRPUlMg YGBBUyBJUycnIEFORCBBTlkKKyAqIEVYUFJFU1MgT1IgSU1QTElFRCBXQVJSQU5USUVTLCBJTkNM VURJTkcsIEJVVCBOT1QgTElNSVRFRCBUTywgVEhFIElNUExJRUQKKyAqIFdBUlJBTlRJRVMgT0Yg TUVSQ0hBTlRBQklMSVRZIEFORCBGSVRORVNTIEZPUiBBIFBBUlRJQ1VMQVIgUFVSUE9TRSBBUkUK KyAqIERJU0NMQUlNRUQuICBJTiBOTyBFVkVOVCBTSEFMTCBUSEUgQVVUSE9SIE9SIENPTlRSSUJV VE9SUyBCRSBMSUFCTEUgRk9SCisgKiBBTlkgRElSRUNULCBJTkRJUkVDVCwgSU5DSURFTlRBTCwg U1BFQ0lBTCwgRVhFTVBMQVJZLCBPUiBDT05TRVFVRU5USUFMCisgKiBEQU1BR0VTIChJTkNMVURJ TkcsIEJVVCBOT1QgTElNSVRFRCBUTywgUFJPQ1VSRU1FTlQgT0YgU1VCU1RJVFVURSBHT09EUyBP UgorICogU0VSVklDRVM7IExPU1MgT0YgVVNFLCBEQVRBLCBPUiBQUk9GSVRTOyBPUiBCVVNJTkVT UyBJTlRFUlJVUFRJT04pIEhPV0VWRVIKKyAqIENBVVNFRCBBTkQgT04gQU5ZIFRIRU9SWSBPRiBM SUFCSUxJVFksIFdIRVRIRVIgSU4gQ09OVFJBQ1QsIFNUUklDVAorICogTElBQklMSVRZLCBPUiBU T1JUIChJTkNMVURJTkcgTkVHTElHRU5DRSBPUiBPVEhFUldJU0UpIEFSSVNJTkcgSU4gQU5ZIFdB WQorICogT1VUIE9GIFRIRSBVU0UgT0YgVEhJUyBTT0ZUV0FSRSwgRVZFTiBJRiBBRFZJU0VEIE9G IFRIRSBQT1NTSUJJTElUWSBPRgorICogU1VDSCBEQU1BR0UuCisgKgorICogJEZyZWVCU0Q6IHNy Yy9zeXMvZGV2L3NvdW5kL21pZGkvc2VxdWVuY2VyLmMsdiAxLjE1IDIwMDMvMDMvMDMgMTI6MTU6 NDYgcGhrIEV4cCAkCisgKgorICovCisKKyNpbmNsdWRlIDxzeXMvcGFyYW0uaD4KKyNpbmNsdWRl IDxzeXMvc3lzdG0uaD4KKyNpbmNsdWRlIDxzeXMvaW9jY29tLmg+CisKKyNpbmNsdWRlIDxzeXMv ZmlsaW8uaD4KKyNpbmNsdWRlIDxzeXMvbG9jay5oPgorI2luY2x1ZGUgPHN5cy9zb2NraW8uaD4K KyNpbmNsdWRlIDxzeXMvZmNudGwuaD4KKyNpbmNsdWRlIDxzeXMvdHR5Lmg+CisjaW5jbHVkZSA8 c3lzL3Byb2MuaD4KKyNpbmNsdWRlIDxzeXMvc3lzY3RsLmg+CisKKyNpbmNsdWRlIDxzeXMva2Vy bmVsLmg+IC8qIGZvciBEQVRBX1NFVCAqLworCisjaW5jbHVkZSA8c3lzL21vZHVsZS5oPgorI2lu Y2x1ZGUgPHN5cy9jb25mLmg+CisjaW5jbHVkZSA8c3lzL2ZpbGUuaD4KKyNpbmNsdWRlIDxzeXMv dWlvLmg+CisjaW5jbHVkZSA8c3lzL3N5c2xvZy5oPgorI2luY2x1ZGUgPHN5cy9lcnJuby5oPgor I2luY2x1ZGUgPHN5cy9tYWxsb2MuaD4KKyNpbmNsdWRlIDxzeXMvYnVzLmg+CisjaW5jbHVkZSA8 bWFjaGluZS9yZXNvdXJjZS5oPgorI2luY2x1ZGUgPG1hY2hpbmUvYnVzX21lbWlvLmg+CisjaW5j bHVkZSA8bWFjaGluZS9idXNfcGlvLmg+CisjaW5jbHVkZSA8bWFjaGluZS9idXMuaD4KKyNpbmNs dWRlIDxtYWNoaW5lL2Nsb2NrLmg+ICAgICAgLyogZm9yIERFTEFZICovCisjaW5jbHVkZSA8c3lz L3NvdW5kY2FyZC5oPgorI2luY2x1ZGUgPHN5cy9ybWFuLmg+CisjaW5jbHVkZSA8c3lzL21tYW4u aD4KKyNpbmNsdWRlIDxzeXMvcG9sbC5oPgorI2luY2x1ZGUgPHN5cy9tdXRleC5oPgorI2luY2x1 ZGUgPHN5cy9jb25kdmFyLmg+CisjaW5jbHVkZSA8c3lzL2t0aHJlYWQuaD4KKyNpbmNsdWRlIDxz eXMvdW5pc3RkLmg+CisjaW5jbHVkZSA8c3lzL3NlbGluZm8uaD4KKworCisjaW5jbHVkZSA8ZGV2 L3NvdW5kL21pZGkvbWlkaS5oPgorI2luY2x1ZGUgPGRldi9zb3VuZC9taWRpL21pZGlxLmg+Cisj aW5jbHVkZSAic3ludGhfaWYuaCIKKworI2luY2x1ZGUgPGRldi9zb3VuZC9taWRpL3NlcXVlbmNl ci5oPgorCisjZGVmaW5lIFRNUl9USU1FUkJBU0UgMTMKKworI2RlZmluZSBTTkRfREVWX1NFUQkx CS8qIFNlcXVlbmNlciBvdXRwdXQgL2Rldi9zZXF1ZW5jZXIgKEZNCisJCQkJICAgc3ludGhlc2l6 ZXIgYW5kIE1JREkgb3V0cHV0KSAqLworI2RlZmluZSBTTkRfREVWX01VU0lDCTgJLyogL2Rldi9t dXNpYywgbGV2ZWwgMiBpbnRlcmZhY2UgKi8KKworLyogTGVuZ3RoIG9mIGEgc2VxdWVuY2VyIGV2 ZW50LiAqLworI2RlZmluZSBFVl9TWiA4CisjZGVmaW5lIElFVl9TWiA4CisKKy8qIExvb2t1cCBt b2RlcyAqLworI2RlZmluZSBMT09LVVBfRVhJU1QJKDApCisjZGVmaW5lIExPT0tVUF9PUEVOCSgx KQorI2RlZmluZSBMT09LVVBfQ0xPU0UJKDIpCisKKyNkZWZpbmUgUENNTUtNSU5PUih1LCBkLCBj KSBcCisJICAgICgoKChjKSAmIDB4ZmYpIDw8IDE2KSB8ICgoKHUpICYgMHgwZikgPDwgNCkgfCAo KGQpICYgMHgwZikpCisjZGVmaW5lIE1JRElNS01JTk9SKHUsIGQsIGMpIFBDTU1LTUlOT1IodSwg ZCwgYykKKyNkZWZpbmUgTUlESVVOSVQoeSkgKChtaW5vcih5KSA+PiA0KSAmIDB4MGYpCisjZGVm aW5lIE1JRElERVYoeSkgKG1pbm9yKHkpICYgMHgwZikKKworLyogVGhlc2UgYXJlIHRoZSBlbnRy aWVzIHRvIHRoZSBzZXF1ZW5jZXIgZHJpdmVyLiAqLworc3RhdGljIGRfb3Blbl90IHNlcV9vcGVu Oworc3RhdGljIGRfY2xvc2VfdCBzZXFfY2xvc2U7CitzdGF0aWMgZF9pb2N0bF90IHNlcV9pb2N0 bDsKK3N0YXRpYyBkX3JlYWRfdCBzZXFfcmVhZDsKK3N0YXRpYyBkX3dyaXRlX3Qgc2VxX3dyaXRl Oworc3RhdGljIGRfcG9sbF90IHNlcV9wb2xsOworI2RlZmluZSBNSURJX01BSk9SIDMwCisKK3N0 YXRpYyBzdHJ1Y3QgY2RldnN3IHNlcV9jZGV2c3cgPSB7CisJLmRfdmVyc2lvbiA9IERfVkVSU0lP TiwKKwkuZF9vcGVuID0Jc2VxX29wZW4sCisJLmRfY2xvc2UgPQlzZXFfY2xvc2UsCisJLmRfcmVh ZCA9CXNlcV9yZWFkLAorCS5kX3dyaXRlID0Jc2VxX3dyaXRlLAorCS5kX2lvY3RsID0Jc2VxX2lv Y3RsLAorCS5kX3BvbGwgPQlzZXFfcG9sbCwKKwkuZF9uYW1lID0JInNlcXVlbmNlciIsCisJLmRf bWFqID0JTUlESV9NQUpPUiwKK307CisKK3N0cnVjdCBzZXFfc29mdGMgeworCUtPQkpfRklFTERT OworCisJc3RydWN0IG10eCBzZXFfbG9jaywgcV9sb2NrOworCXN0cnVjdCBjdiBlbXB0eV9jdiwg cmVzZXRfY3YsIGluX2N2LCBvdXRfY3YsIHN0YXRlX2N2LCB0aF9jdjsKKworCU1JRElRX0hFQUQo LCB1X2NoYXIpIGluX3EsIG91dF9xOworCisJdV9sb25nICBmbGFnczsKKwkvKiBGbGFncyAocHJv dGVjdGVkIGJ5IGZsYWdfbXR4IG9mIG1pZGlkZXZfaW5mbykgKi8KKwlpbnQJCWZmbGFnczsJCSAg LyogQWNjZXNzIG1vZGUgKi8KKwlpbnQJCW11c2ljOworCisJaW50CQlvdXRfd2F0ZXI7CS8qIFNl cXVlbmNlIG91dHB1dCB0aHJlc2hvdWxkICovCisJc25kX3N5bmNfcGFybQlzeW5jX3Bhcm07CQkv KiBBSU9TWU5DIHBhcmFtZXRlciBzZXQgKi8KKwlzdHJ1Y3QgdGhyZWFkCSpzeW5jX3RocmVhZDsJ CS8qIEFJT1NZTkNpbmcgdGhyZWFkICovCisJc3RydWN0IHNlbGluZm8gaW5fc2VsLCBvdXRfc2Vs OworCWludCBtaWRpX251bWJlcjsKKwlzdHJ1Y3QgY2RldiAqc2VxZGV2LCAqbXVzaWNkZXY7CisJ aW50IHVuaXQ7CisJaW50IG1heHVuaXRzOworCWtvYmpfdCAqbWlkaXM7CisJaW50ICptaWRpX2Zs YWdzOworCWtvYmpfdCBtYXBwZXI7CisJdm9pZCAqbWFwcGVyX2Nvb2tpZTsKKwlzdHJ1Y3QgdGlt ZXZhbCB0aW1lcnN0b3AsIHRpbWVyc3ViOworCWludCB0aW1lcmJhc2UsIHRlbXBvOworCWludCB0 aW1lcnJ1bjsKKwlpbnQgZG9uZTsKKwlpbnQgcGxheWluZzsKKwlpbnQgcmVjb3JkaW5nOworCWlu dCBidXN5OworCWludCBwcmVfZXZlbnRfdGltZW91dDsKKwlpbnQgd2FpdGluZzsKK307CisKKy8q CisgKiBNb2R1bGUgc3BlY2lmaWMgc3R1ZmYsIGluY2x1ZGluZyBob3cgbWFueSBzZXF1ZWNlcnMK KyAqIHdlIGN1cnJlbnRseSBvd24uCisgKi8KKworU1lTQ1RMX05PREUoX2h3X21pZGksIE9JRF9B VVRPLCBzZXEsIENUTEZMQUdfUkQsIDAsICJNaWRpIHNlcXVlbmNlciIpOworCitpbnQJCQkJCXNl cV9kZWJ1ZzsKK1NZU0NUTF9JTlQoX2h3X21pZGlfc2VxLCBPSURfQVVUTywgZGVidWcsIENUTEZM QUdfUlcsICZzZXFfZGVidWcsIDAsICIiKTsKKworbWlkaV9jbWR0YWIJY21kdGFiX3NlcWV2ZW50 W10gPSB7CisJe1NFUV9OT1RFT0ZGLAkJIlNFUV9OT1RFT0ZGIn0sCisJe1NFUV9OT1RFT04sCQki U0VRX05PVEVPTiJ9LAorCXtTRVFfV0FJVCwJCSJTRVFfV0FJVCJ9LAorCXtTRVFfUEdNQ0hBTkdF LAkJIlNFUV9QR01DSEFOR0UifSwKKwl7U0VRX1NZTkNUSU1FUiwJCSJTRVFfU1lOQ1RJTUVSIn0s CisJe1NFUV9NSURJUFVUQywJCSJTRVFfTUlESVBVVEMifSwKKwl7U0VRX0RSVU1PTiwJCSJTRVFf RFJVTU9OIn0sCisJe1NFUV9EUlVNT0ZGLAkJIlNFUV9EUlVNT0ZGIn0sCisJe1NFUV9FQ0hPLAkJ IlNFUV9FQ0hPIn0sCisJe1NFUV9BRlRFUlRPVUNILAkiU0VRX0FGVEVSVE9VQ0gifSwKKwl7U0VR X0NPTlRST0xMRVIsCSJTRVFfQ09OVFJPTExFUiJ9LAorCXtTRVFfQkFMQU5DRSwJCSJTRVFfQkFM QU5DRSJ9LAorCXtTRVFfVk9MTU9ERSwJCSJTRVFfVk9MTU9ERSJ9LAorCXtTRVFfRlVMTFNJWkUs CQkiU0VRX0ZVTExTSVpFIn0sCisJe1NFUV9QUklWQVRFLAkJIlNFUV9QUklWQVRFIn0sCisJe1NF UV9FWFRFTkRFRCwJCSJTRVFfRVhURU5ERUQifSwKKwl7RVZfU0VRX0xPQ0FMLAkJIkVWX1NFUV9M T0NBTCJ9LAorCXtFVl9USU1JTkcsCQkiRVZfVElNSU5HIn0sCisJe0VWX0NITl9DT01NT04sCQki RVZfQ0hOX0NPTU1PTiJ9LAorCXtFVl9DSE5fVk9JQ0UsCQkiRVZfQ0hOX1ZPSUNFIn0sCisJe0VW X1NZU0VYLAkJIkVWX1NZU0VYIn0sCisJey0xLAkJCU5VTEx9LAorfTsKKworbWlkaV9jbWR0YWIJ Y21kdGFiX3NlcWlvY3RsW10gPSB7CisJe1NORENUTF9TRVFfUkVTRVQsCSJTTkRDVExfU0VRX1JF U0VUIn0sCisJe1NORENUTF9TRVFfU1lOQywJIlNORENUTF9TRVFfU1lOQyJ9LAorCXtTTkRDVExf U1lOVEhfSU5GTywJIlNORENUTF9TWU5USF9JTkZPIn0sCisJe1NORENUTF9TRVFfQ1RSTFJBVEUs CSJTTkRDVExfU0VRX0NUUkxSQVRFIn0sCisJe1NORENUTF9TRVFfR0VUT1VUQ09VTlQsCSJTTkRD VExfU0VRX0dFVE9VVENPVU5UIn0sCisJe1NORENUTF9TRVFfR0VUSU5DT1VOVCwJIlNORENUTF9T RVFfR0VUSU5DT1VOVCJ9LAorCXtTTkRDVExfU0VRX1BFUkNNT0RFLAkiU05EQ1RMX1NFUV9QRVJD TU9ERSJ9LAorCXtTTkRDVExfRk1fTE9BRF9JTlNUUiwJIlNORENUTF9GTV9MT0FEX0lOU1RSIn0s CisJe1NORENUTF9TRVFfVEVTVE1JREksCSJTTkRDVExfU0VRX1RFU1RNSURJIn0sCisJe1NORENU TF9TRVFfUkVTRVRTQU1QTEVTLAkiU05EQ1RMX1NFUV9SRVNFVFNBTVBMRVMifSwKKwl7U05EQ1RM X1NFUV9OUlNZTlRIUywJIlNORENUTF9TRVFfTlJTWU5USFMifSwKKwl7U05EQ1RMX1NFUV9OUk1J RElTLAkiU05EQ1RMX1NFUV9OUk1JRElTIn0sCisJe1NORENUTF9TRVFfR0VUVElNRSwJIlNORENU TF9TRVFfR0VUVElNRSJ9LAorCXtTTkRDVExfTUlESV9JTkZPLAkiU05EQ1RMX01JRElfSU5GTyJ9 LAorCXtTTkRDVExfU0VRX1RIUkVTSE9MRCwJIlNORENUTF9TRVFfVEhSRVNIT0xEIn0sCisJe1NO RENUTF9TWU5USF9NRU1BVkwsCSJTTkRDVExfU1lOVEhfTUVNQVZMIn0sCisJe1NORENUTF9GTV80 T1BfRU5BQkxFLAkiU05EQ1RMX0ZNXzRPUF9FTkFCTEUifSwKKwl7U05EQ1RMX1BNR1JfQUNDRVNT LAkiU05EQ1RMX1BNR1JfQUNDRVNTIn0sCisJe1NORENUTF9TRVFfUEFOSUMsCSJTTkRDVExfU0VR X1BBTklDIn0sCisJe1NORENUTF9TRVFfT1VUT0ZCQU5ELAkiU05EQ1RMX1NFUV9PVVRPRkJBTkQi fSwKKwl7U05EQ1RMX1RNUl9USU1FQkFTRSwJIlNORENUTF9UTVJfVElNRUJBU0UifSwKKwl7U05E Q1RMX1RNUl9TVEFSVCwJIlNORENUTF9UTVJfU1RBUlQifSwKKwl7U05EQ1RMX1RNUl9TVE9QLAki U05EQ1RMX1RNUl9TVE9QIn0sCisJe1NORENUTF9UTVJfQ09OVElOVUUsCSJTTkRDVExfVE1SX0NP TlRJTlVFIn0sCisJe1NORENUTF9UTVJfVEVNUE8sCSJTTkRDVExfVE1SX1RFTVBPIn0sCisJe1NO RENUTF9UTVJfU09VUkNFLAkiU05EQ1RMX1RNUl9TT1VSQ0UifSwKKwl7U05EQ1RMX1RNUl9NRVRS T05PTUUsCSJTTkRDVExfVE1SX01FVFJPTk9NRSJ9LAorCXtTTkRDVExfVE1SX1NFTEVDVCwJIlNO RENUTF9UTVJfU0VMRUNUIn0sCisJe1NORENUTF9NSURJX1BSRVRJTUUsCSJTTkRDVExfTUlESV9Q UkVUSU1FIn0sCisJe0FJT05XUklURSwJCSJBSU9OV1JJVEUifSwKKwl7QUlPR1NJWkUsCQkiQUlP R1NJWkUifSwKKwl7QUlPU1NJWkUsCQkiQUlPU1NJWkUifSwKKwl7QUlPR0ZNVCwJCSJBSU9HRk1U In0sCisJe0FJT1NGTVQsCQkiQUlPU0ZNVCJ9LAorCXtBSU9HTUlYLAkJIkFJT0dNSVgifSwKKwl7 QUlPU01JWCwJCSJBSU9TTUlYIn0sCisJe0FJT1NUT1AsCQkiQUlPU1RPUCJ9LAorCXtBSU9TWU5D LAkJIkFJT1NZTkMifSwKKwl7QUlPR0NBUCwJCSJBSU9HQ0FQIn0sCisJey0xLAkJCU5VTEx9LAor fTsKKworbWlkaV9jbWR0YWIJY21kdGFiX3RpbWVyW10gPSB7CisJe1RNUl9XQUlUX1JFTCwJIlRN Ul9XQUlUX1JFTCJ9LAorCXtUTVJfV0FJVF9BQlMsCSJUTVJfV0FJVF9BQlMifSwKKwl7VE1SX1NU T1AsCSJUTVJfU1RPUCJ9LAorCXtUTVJfU1RBUlQsCSJUTVJfU1RBUlQifSwKKwl7VE1SX0NPTlRJ TlVFLAkiVE1SX0NPTlRJTlVFIn0sCisJe1RNUl9URU1QTywJIlRNUl9URU1QTyJ9LAorCXtUTVJf RUNITywJIlRNUl9FQ0hPIn0sCisJe1RNUl9DTE9DSywJIlRNUl9DTE9DSyJ9LAorCXtUTVJfU1BQ LAkiVE1SX1NQUCJ9LAorCXtUTVJfVElNRVNJRywJIlRNUl9USU1FU0lHIn0sCisJey0xLAkJTlVM TH0sCit9OworCittaWRpX2NtZHRhYgljbWR0YWJfc2VxY3ZbXSA9IHsKKwl7TUlESV9OT1RFT0ZG LAkJIk1JRElfTk9URU9GRiJ9LAorCXtNSURJX05PVEVPTiwJCSJNSURJX05PVEVPTiJ9LAorCXtN SURJX0tFWV9QUkVTU1VSRSwJIk1JRElfS0VZX1BSRVNTVVJFIn0sCisJey0xLAkJCU5VTEx9LAor fTsKKworbWlkaV9jbWR0YWIJY21kdGFiX3NlcWNjbW5bXSA9IHsKKwl7TUlESV9DVExfQ0hBTkdF LAkiTUlESV9DVExfQ0hBTkdFIn0sCisJe01JRElfUEdNX0NIQU5HRSwJIk1JRElfUEdNX0NIQU5H RSJ9LAorCXtNSURJX0NITl9QUkVTU1VSRSwJIk1JRElfQ0hOX1BSRVNTVVJFIn0sCisJe01JRElf UElUQ0hfQkVORCwJIk1JRElfUElUQ0hfQkVORCJ9LAorCXtNSURJX1NZU1RFTV9QUkVGSVgsCSJN SURJX1NZU1RFTV9QUkVGSVgifSwKKwl7LTEsCQkJTlVMTH0sCit9OworCisvKgorICogc3RhdGlj IGNvbnN0IGNoYXIgKm1wdTQwMV9tcHJvdmlkZXIoa29ial90IG9iaiwgc3RydWN0IG1wdTQwMSAq bSk7CisgKi8KKworc3RhdGljIGtvYmpfbWV0aG9kX3Qgc2VxX21ldGhvZHNbXSA9IHsKKwkvKiBL T0JKTUVUSE9EKG1wdV9wcm92aWRlcixtcHU0MDFfbXByb3ZpZGVyKSwgKi8KKyAgICAgICAgeyAw LCAwIH0KK307CitERUZJTkVfQ0xBU1Moc2VxdWVuY2VyLCBzZXFfbWV0aG9kcywgMCk7CisKKy8q IFRoZSBmb2xsb3dpbmdzIGFyZSB0aGUgbG9jYWwgZnVuY3Rpb24uICovCitzdGF0aWMgaW50IHNl cV9jb252ZXJ0b2xkKHVfY2hhciAqZXZlbnQsIHVfY2hhciAqb3V0KTsKKy8qCisgKiBzdGF0aWMg dm9pZCBzZXFfbWlkaWlucHV0KHN0cnVjdCBzZXFfc29mdGMgKiBzY3AsIHZvaWQgKm1kKTsKKyAq Lworc3RhdGljIHZvaWQgc2VxX3Jlc2V0KHN0cnVjdCBzZXFfc29mdGMgKiBzY3ApOworc3RhdGlj IGludCBzZXFfc3luYyhzdHJ1Y3Qgc2VxX3NvZnRjICogc2NwKTsKKworc3RhdGljIGludCBzZXFf cHJvY2Vzc2V2ZW50KHN0cnVjdCBzZXFfc29mdGMgKiBzY3AsIHVfY2hhciAqZXZlbnQpOworCitz dGF0aWMgaW50IHNlcV90aW1pbmcoc3RydWN0IHNlcV9zb2Z0YyAqIHNjcCwgdV9jaGFyICpldmVu dCk7CitzdGF0aWMgaW50IHNlcV9sb2NhbChzdHJ1Y3Qgc2VxX3NvZnRjICogc2NwLCB1X2NoYXIg KmV2ZW50KTsKKworc3RhdGljIGludCBzZXFfY2hudm9pY2Uoc3RydWN0IHNlcV9zb2Z0YyAqIHNj cCwga29ial90IG1kLCB1X2NoYXIgKmV2ZW50KTsKK3N0YXRpYyBpbnQgc2VxX2NobmNvbW1vbihz dHJ1Y3Qgc2VxX3NvZnRjICogc2NwLCBrb2JqX3QgbWQsIHVfY2hhciAqZXZlbnQpOworc3RhdGlj IGludCBzZXFfc3lzZXgoc3RydWN0IHNlcV9zb2Z0YyAqIHNjcCwga29ial90IG1kLCB1X2NoYXIg KmV2ZW50KTsKKworc3RhdGljIGludCBzZXFfZmV0Y2hfbWlkKHN0cnVjdCBzZXFfc29mdGMgKnNj cCwgaW50IHVuaXQsIGtvYmpfdCAqbWQpOwordm9pZCBzZXFfY29weXRvaW5wdXQoc3RydWN0IHNl cV9zb2Z0YyAqc2NwLCB1X2NoYXIgKmV2ZW50LCBpbnQgbGVuKTsKK2ludCBzZXFfbW9kZXZlbnQo bW9kdWxlX3QgbW9kLCBpbnQgdHlwZSwgdm9pZCAqZGF0YSk7CitzdHJ1Y3Qgc2VxX3NvZnRjICpz ZXFzWzEwXTsKK3N0YXRpYyBzdHJ1Y3QgbXR4CQkJc2VxaW5mb19tdHg7CitzdGF0aWMgdV9sb25n CQkJCW5zZXEgPSAwOworCitzdGF0aWMgdm9pZCB0aW1lcl9zdGFydChzdHJ1Y3Qgc2VxX3NvZnRj ICp0KTsKK3N0YXRpYyB2b2lkIHRpbWVyX3N0b3Aoc3RydWN0IHNlcV9zb2Z0YyAqdCk7CitzdGF0 aWMgdm9pZCB0aW1lcl9zZXR2YWxzKHN0cnVjdCBzZXFfc29mdGMgKnQsIGludCB0ZW1wbywgaW50 IHRpbWVyYmFzZSk7CitzdGF0aWMgdm9pZCB0aW1lcl93YWl0KHN0cnVjdCBzZXFfc29mdGMgKnQs IGludCB0aWNrcywgaW50IHdhaXRfYWJzKTsKK3N0YXRpYyBpbnQgdGltZXJfbm93KHN0cnVjdCBz ZXFfc29mdGMgKnQpOworCisKK3N0YXRpYyB2b2lkCit0aW1lcl9zdGFydChzdHJ1Y3Qgc2VxX3Nv ZnRjICp0KQoreworCXQtPnRpbWVycnVuID0gMTsKKwlnZXRtaWNyb3RpbWUoJnQtPnRpbWVyc3Vi KTsKK30KKworc3RhdGljIHZvaWQKK3RpbWVyX2NvbnRpbnVlKHN0cnVjdCBzZXFfc29mdGMgKnQp Cit7CisJc3RydWN0IHRpbWV2YWwgbm93OworCisJaWYgKHQtPnRpbWVycnVuID09IDEpCisJICAg IHJldHVybjsKKwl0LT50aW1lcnJ1biA9IDE7CisJZ2V0bWljcm90aW1lKCZub3cpOworCXRpbWV2 YWxzdWIoJm5vdywgJnQtPnRpbWVyc3RvcCk7CisJdGltZXZhbGFkZCgmdC0+dGltZXJzdWIsICZu b3cpOworfQorCitzdGF0aWMgdm9pZAordGltZXJfc3RvcChzdHJ1Y3Qgc2VxX3NvZnRjICp0KQor eworCXQtPnRpbWVycnVuID0gMDsKKwlnZXRtaWNyb3RpbWUoJnQtPnRpbWVyc3RvcCk7Cit9CisK K3N0YXRpYyB2b2lkCit0aW1lcl9zZXR2YWxzKHN0cnVjdCBzZXFfc29mdGMgKnQsIGludCB0ZW1w bywgaW50IHRpbWVyYmFzZSkKK3sKKwl0LT50ZW1wbyA9IHRlbXBvOworCXQtPnRpbWVyYmFzZSA9 IHRpbWVyYmFzZTsKK30KKworc3RhdGljIHZvaWQKK3RpbWVyX3dhaXQoc3RydWN0IHNlcV9zb2Z0 YyAqdCwgaW50IHRpY2tzLCBpbnQgd2FpdF9hYnMpCit7CisJc3RydWN0IHRpbWV2YWwgbm93LCB3 aGVuOworCWludCByZXQ7CisJdW5zaWduZWQgbG9uZyBsb25nIGk7CisKKwl3aGlsZSAodC0+dGlt ZXJydW4gPT0gMCkgeworCSAgICBTRVFfREVCVUcoMixwcmludGYoIlRpbWVyIHdhaXQgd2hlbiB0 aW1lciBpc24ndCBydW5uaW5nXG4iKSk7CisJICAgIC8qCisJICAgICAqIFRoZSBvbGQgc2VxdWVu Y2VyIHVzZWQgdGltZW91dHMgdGhhdCBvbmx5IGluY3JlYXNlZAorCSAgICAgKiB0aGUgdGltZXIg d2hlbiB0aGUgdGltZXIgd2FzIHJ1bm5pbmcuCisJICAgICAqIEhlbmNlIHRoZSBzZXF1ZW5jZXIg d291bGQgc3RpY2sgKD8pIGlmIHRoZQorCSAgICAgKiB0aW1lciB3YXMgZGlzYWJsZWQuCisJICAg ICAqLworCSAgICBjdl93YWl0KCZ0LT5yZXNldF9jdiwgJnQtPnNlcV9sb2NrKTsKKwkgICAgaWYg KHQtPnBsYXlpbmcgPT0gMCkKKwkJcmV0dXJuOworCX0KKworCWkgPSB0aWNrcyAqIDYwdWxsICog MTAwMDAwMHVsbCAvICh0LT50ZW1wbyAqIHQtPnRpbWVyYmFzZSk7CisKKwl3aGVuLnR2X3NlYyA9 IGkgLyAxMDAwMDAwOworCXdoZW4udHZfdXNlYyA9IGkgJSAxMDAwMDAwOworCisjaWYgMAorCXBy aW50ZigidGltZXJfd2FpdCB0ZW1wbyAlZCB0aW1lcmJhc2UgJWQgdGlja3MgJWQgYWJzICVkIHVf c2VjICVsbHVcbiIsIHQtPnRlbXBvLCB0LT50aW1lcmJhc2UsIHRpY2tzLCB3YWl0X2FicywgaSk7 CisjZW5kaWYKKworCWlmICh3YWl0X2FicyAhPSAwKSB7CisJICAgIGdldG1pY3JvdGltZSgmbm93 KTsKKwkgICAgdGltZXZhbHN1Yigmbm93LCAmdC0+dGltZXJzdWIpOworCSAgICB0aW1ldmFsc3Vi KCZ3aGVuLCAmbm93KTsKKwl9CisKKwlpZiAod2hlbi50dl9zZWMgPCAwIHx8IHdoZW4udHZfdXNl YyA8IDApIHsKKwkgICAgU0VRX0RFQlVHKDMscHJpbnRmKCJzZXFfdGltZXIgZXJyb3IgbmVnYXRp dmUgdGltZSAlbGQuJTA2bGRcbiIsIAorCQkgICAgd2hlbi50dl9zZWMsd2hlbi50dl91c2VjKSk7 CisJICAgIHJldHVybjsKKwl9CisKKwlpID0gd2hlbi50dl9zZWMgKiAxMDAwMDAwdWxsOworCWkg Kz0gd2hlbi50dl91c2VjOworCWkgKj0gaHo7CisJaSAvPSAxMDAwMDAwdWxsOworI2lmIDAKKwlw cmludGYoInNlcV90aW1lciB1c2VjICVsbHUgdGlja3MgJWxsdVxuIiwgd2hlbi50dl9zZWMgKiAx MDAwMDAwdWxsICsgd2hlbi50dl91c2VjLCBpKTsKKyNlbmRpZgorCXQtPndhaXRpbmcgPSAxOwor CXJldCA9IGN2X3RpbWVkd2FpdCgmdC0+cmVzZXRfY3YsICZ0LT5zZXFfbG9jaywgaSArIDEpOwor CXQtPndhaXRpbmcgPSAwOworCisJaWYgKHJldCAhPSBFV09VTERCTE9DSykKKwkgICAgU0VRX0RF QlVHKDMscHJpbnRmKCJzZXFfdGltZXIgZGlkbid0IHRpbWVvdXRcbiIpKTsKKworfQorCitzdGF0 aWMgaW50Cit0aW1lcl9ub3coc3RydWN0IHNlcV9zb2Z0YyAqdCkKK3sKKwlzdHJ1Y3QgdGltZXZh bCBub3c7CisJdW5zaWduZWQgbG9uZyBsb25nIGk7CisJaW50IHJldDsKKworCWlmICh0LT50aW1l cnJ1biA9PSAwKQorCSAgICBub3cgPSB0LT50aW1lcnN0b3A7CisJZWxzZQorCSAgICBnZXRtaWNy b3RpbWUoJm5vdyk7CisKKwl0aW1ldmFsc3ViKCZub3csICZ0LT50aW1lcnN1Yik7CisKKwlpID0g bm93LnR2X3NlYyAqIDEwMDAwMDB1bGw7CisJaSArPSBub3cudHZfdXNlYzsKKwlpICo9IHQtPnRp bWVyYmFzZTsKKy8qCWkgLz0gdC0+dGVtcG87ICovCisJaSAvPSAxMDAwMDAwdWxsOworCisJcmV0 ID0gaTsKKwkvKgorCSAqIHByaW50ZigidGltZXJfbm93OiAlbGx1ICVkXG4iLCBpLCByZXQpOwor CSAqLworCisJcmV0dXJuIHJldDsKK30KKworc3RhdGljIHZvaWQKK3NlcV9ldmVudHRocmVhZCh2 b2lkICphcmcpCit7CisJc3RydWN0IHNlcV9zb2Z0YyAqc2NwID0gYXJnOworCWNoYXIgZXZlbnRb RVZfU1pdOworCisJbXR4X2xvY2soJnNjcC0+c2VxX2xvY2spOworCXByaW50Zigic2VxX2V2ZW50 dGhyZWFkIHN0YXJ0ZWRcbiIpOworCXdoaWxlKHNjcC0+ZG9uZSA9PSAwKSB7CityZXN0YXJ0Ogor CSAgICB3aGlsZSAoc2NwLT5wbGF5aW5nID09IDApIHsKKwkJY3Zfd2FpdCgmc2NwLT5zdGF0ZV9j diwgJnNjcC0+c2VxX2xvY2spOworCQkgICAgaWYgKHNjcC0+ZG9uZSkKKwkJCWdvdG8gZG9uZTsK KwkgICAgfQorCisJICAgIHdoaWxlIChNSURJUV9FTVBUWShzY3AtPm91dF9xKSkgeworCQljdl9i cm9hZGNhc3QoJnNjcC0+ZW1wdHlfY3YpOworCQljdl93YWl0KCZzY3AtPm91dF9jdiwgJnNjcC0+ c2VxX2xvY2spOworCQlpZiAoc2NwLT5wbGF5aW5nID09IDApCisJCSAgICBnb3RvIHJlc3RhcnQ7 CisJCWlmIChzY3AtPmRvbmUpCisJCSAgICBnb3RvIGRvbmU7CisJICAgIH0KKworCSAgICBNSURJ UV9ERVEoc2NwLT5vdXRfcSwgZXZlbnQsIEVWX1NaKTsKKworCSAgICBpZiAoTUlESVFfQVZBSUwo c2NwLT5vdXRfcSkgPCBzY3AtPm91dF93YXRlcikgeworCQljdl9icm9hZGNhc3QoJnNjcC0+b3V0 X2N2KTsKKwkJc2Vsd2FrZXVwKCZzY3AtPm91dF9zZWwpOworCSAgICB9CisKKwkgICAgc2VxX3By b2Nlc3NldmVudChzY3AsIGV2ZW50KTsKKwl9CisKK2RvbmU6CisJY3ZfYnJvYWRjYXN0KCZzY3At PnRoX2N2KTsKKwltdHhfdW5sb2NrKCZzY3AtPnNlcV9sb2NrKTsKKwltdHhfbG9jaygmR2lhbnQp OworCXByaW50Zigic2VxX2V2ZW50dGhyZWFkIGZpbmlzaGVkXG4iKTsKKwlrdGhyZWFkX2V4aXQo MCk7Cit9CisKKy8qCisgKiBzZXFfcHJvY2Vzc2V2ZW50OiAgVGhpcyBtYXliZSBjYWxsZWQgYnkg dGhlIGV2ZW50IHRocmVhZCBvciB0aGUgSU9DVEwKKyAqIGhhbmRsZXIgZm9yIHF1ZXVlZCBhbmQg b3V0IG9mIGJhbmQgZXZlbnRzIHJlc3BlY3RpdmVseS4KKyAqLworc3RhdGljIGludAorc2VxX3By b2Nlc3NldmVudChzdHJ1Y3Qgc2VxX3NvZnRjICpzY3AsIHVfY2hhciAqZXZlbnQpCit7CisJaW50 IHJldDsKKwlrb2JqX3QgbTsKKworCXJldCA9IDA7CisKKwlpZiAoZXZlbnRbMF0gPT0gRVZfU0VR X0xPQ0FMKQorCQlyZXQgPSBzZXFfbG9jYWwoc2NwLCBldmVudCk7CisJZWxzZSBpZiAoZXZlbnRb MF0gPT0gRVZfVElNSU5HKQorCQlyZXQgPSBzZXFfdGltaW5nKHNjcCwgZXZlbnQpOworCWVsc2Ug aWYgKGV2ZW50WzBdICE9IEVWX0NITl9WT0lDRSAmJgorCQkJZXZlbnRbMF0gIT0gRVZfQ0hOX0NP TU1PTiAmJgorCQkJZXZlbnRbMF0gIT0gRVZfU1lTRVggJiYKKwkJCWV2ZW50WzBdICE9IFNFUV9N SURJUFVUQykgeworCQlyZXQgPSAxOworCQlTRVFfREVCVUcoMixwcmludGYoInNlcV9wcm9jZXNz ZXZlbnQgbm90IGtub3duICVkXG4iLCBldmVudFswXSkpOworCX0gZWxzZSBpZiAoc2VxX2ZldGNo X21pZChzY3AsIGV2ZW50WzFdLCAmbSkgIT0gMCkgeworCQlyZXQgPSAxOworCQlTRVFfREVCVUco MixwcmludGYoInNlcV9wcm9jZXNzZXZlbnQgbWlkaSB1bml0IG5vdCBmb3VuZCAlZFxuIiwgZXZl bnRbMV0pKTsKKwl9IGVsc2Ugc3dpdGNoKGV2ZW50WzBdKSB7CisJCWNhc2UgRVZfQ0hOX1ZPSUNF OiAKKwkJCXJldCA9IHNlcV9jaG52b2ljZShzY3AsIG0sIGV2ZW50KTsKKwkJCWJyZWFrOworCQlj YXNlIEVWX0NITl9DT01NT046CisJCQlyZXQgPSBzZXFfY2huY29tbW9uKHNjcCwgbSwgZXZlbnQp OworCQkJYnJlYWs7CisJCWNhc2UgRVZfU1lTRVg6CisJCQlyZXQgPSBzZXFfc3lzZXgoc2NwLCBt LCBldmVudCk7CisJCQlicmVhazsKKwkJY2FzZSBTRVFfTUlESVBVVEM6CisJCQltdHhfdW5sb2Nr KCZzY3AtPnNlcV9sb2NrKTsKKwkJCXJldCA9IFNZTlRIX1dSSVRFUkFXKG0sICZldmVudFsyXSwg MSk7CisJCQltdHhfbG9jaygmc2NwLT5zZXFfbG9jayk7CisJCQlicmVhazsKKwl9CisJcmV0dXJu IHJldDsKK30KKworc3RhdGljIGludAorc2VxX2FkZHVuaXQodm9pZCkKK3sKKwlzdHJ1Y3Qgc2Vx X3NvZnRjICpzY3A7CisJaW50IHJldDsKKwl1X2NoYXIgKmJ1ZjsKKworCS8qIEFsbG9jYXRlIHRo ZSBzb2Z0Yy4gKi8KKwlyZXQgPSBFTk9NRU07CisJc2NwID0gbWFsbG9jKHNpemVvZigqc2NwKSwg TV9ERVZCVUYsIE1fTk9XQUlUIHwgTV9aRVJPKTsKKwlpZiAoc2NwID09IE5VTEwpIHsKKwkJU0VR X0RFQlVHKDEscHJpbnRmKCJzZXFfYWRkdW5pdDogc29mdGMgYWxsb2NhdGlvbiBmYWlsZWQuXG4i KSk7CisJCWdvdG8gZXJyOworCX0KKwlrb2JqX2luaXQoKGtvYmpfdCkgc2NwLCAmc2VxdWVuY2Vy X2NsYXNzKTsKKworCWJ1ZiA9IG1hbGxvYyhzaXplb2YoKmJ1ZikgKiBFVl9TWiAqIDEwMjQsIE1f VEVNUCwgTV9OT1dBSVQgfCBNX1pFUk8pOworCWlmIChidWYgPT0gTlVMTCkKKwkgICAgZ290byBl cnI7CisJTUlESVFfSU5JVChzY3AtPmluX3EsIGJ1ZiwgRVZfU1ogKiAxMDI0KTsKKwlidWYgPSBt YWxsb2Moc2l6ZW9mKCpidWYpICogRVZfU1ogKiAxMDI0LCBNX1RFTVAsIE1fTk9XQUlUIHwgTV9a RVJPKTsKKwlpZiAoYnVmID09IE5VTEwpCisJICAgIGdvdG8gZXJyOworCU1JRElRX0lOSVQoc2Nw LT5vdXRfcSwgYnVmLCBFVl9TWiAqIDEwMjQpOworCXJldCA9IEVJTlZBTDsKKworCXNjcC0+bWlk aXMgPSBtYWxsb2Moc2l6ZW9mKGtvYmpfdCkgKiAzMiwgTV9URU1QLCBNX05PV0FJVCB8IE1fWkVS Tyk7CisJc2NwLT5taWRpX2ZsYWdzID0gbWFsbG9jKHNpemVvZigqc2NwLT5taWRpX2ZsYWdzKSAq IDMyLCBNX1RFTVAsCisJCU1fTk9XQUlUIHwgTV9aRVJPKTsKKworCWlmICggc2NwLT5taWRpcyA9 PSBOVUxMIHx8IHNjcC0+bWlkaV9mbGFncyA9PSBOVUxMKQorCSAgICBnb3RvIGVycjsKKworCXNj cC0+ZmxhZ3MgPSAwOworCisJbXR4X2luaXQoJnNjcC0+c2VxX2xvY2ssICJzZXFmbHEiLCAwLCAw KTsKKwljdl9pbml0KCZzY3AtPnN0YXRlX2N2LCAic2Vxc3RhdGUiKTsKKwljdl9pbml0KCZzY3At PmVtcHR5X2N2LCAic2VxZW1wdHkiKTsKKwljdl9pbml0KCZzY3AtPnJlc2V0X2N2LCAic2VxdGlt ZXIiKTsKKwljdl9pbml0KCZzY3AtPm91dF9jdiwgInNlcXFvdXQiKTsKKwljdl9pbml0KCZzY3At PmluX2N2LCAic2VxcWluIik7CisJY3ZfaW5pdCgmc2NwLT50aF9jdiwgInNlcXN0YXJ0Iik7CisK KwkvKgorCSAqIEluaXQgdGhlIGRhbW4gdGltZXIKKwkgKi8KKworCXNjcC0+bWFwcGVyID0gbWlk aW1hcHBlcl9hZGRzZXEoc2NwLCAmc2NwLT51bml0LCAmc2NwLT5tYXBwZXJfY29va2llKTsKKwlp ZiAoc2NwLT5tYXBwZXIgPT0gTlVMTCkKKwkgICAgZ290byBlcnI7CisKKwlzY3AtPnNlcWRldiA9 IG1ha2VfZGV2KCZzZXFfY2RldnN3LAorCQlNSURJTUtNSU5PUihzY3AtPnVuaXQsIFNORF9ERVZf U0VRLDApLCBVSURfUk9PVCwgCisJCUdJRF9XSEVFTCwgMDY2NiwgInNlcXVlbmNlciVkIiwgc2Nw LT51bml0KTsKKworCXNjcC0+bXVzaWNkZXYgPSBtYWtlX2Rldigmc2VxX2NkZXZzdywKKwkJTUlE SU1LTUlOT1Ioc2NwLT51bml0LCBTTkRfREVWX01VU0lDLDApLCBVSURfUk9PVCwgCisJCUdJRF9X SEVFTCwgMDY2NiwgIm11c2ljJWQiLCBzY3AtPnVuaXQpOworCisJaWYgKHNjcC0+c2VxZGV2ID09 IE5VTEwgfHwgc2NwLT5tdXNpY2RldiA9PSBOVUxMKQorCSAgICBnb3RvIGVycjsKKwkvKgorCSAq IFRPRE86IEFkZCB0byBsaXN0IG9mIHNlcXVlbmNlcnMgdGhpcyBtb2R1bGUgcHJvdmlkZXMKKwkg Ki8KKworCXJldCA9IGt0aHJlYWRfY3JlYXRlKHNlcV9ldmVudHRocmVhZCwgc2NwLCBOVUxMLCBS RkhJR0hQSUQsIDAsICJzZXF1ZW5jZXIgJTAyZCIsIHNjcC0+dW5pdCk7CisKKwlpZiAocmV0KQor CSAgICBnb3RvIGVycjsKKworCXNjcC0+c2VxZGV2LT5zaV9kcnYxID0gc2NwLT5tdXNpY2Rldi0+ c2lfZHJ2MSA9IHNjcDsKKworCXByaW50Zigic2VxdWVuY2VyICVkIGNyZWF0ZWQgc2NwICVwXG4i LCBzY3AtPnVuaXQsIHNjcCk7CisKKwlyZXQgPSAwOworCisJbXR4X2xvY2soJnNlcWluZm9fbXR4 KTsKKwlzZXFzW25zZXErK109c2NwOworCW10eF91bmxvY2soJnNlcWluZm9fbXR4KTsKKworCWdv dG8gb2s7CisKK2VycjoKKwlpZiAoc2NwICE9IE5VTEwpIHsKKwkgICAgaWYgKHNjcC0+c2VxZGV2 ICE9IE5VTEwpCisJCWRlc3Ryb3lfZGV2KHNjcC0+c2VxZGV2KTsKKwkgICAgaWYgKHNjcC0+bXVz aWNkZXYgIT0gTlVMTCkKKwkJZGVzdHJveV9kZXYoc2NwLT5tdXNpY2Rldik7CisJICAgIC8qCisJ ICAgICAqIFRPRE86IERlc3Ryb3kgbXV0ZXggYW5kIGN2CisJICAgICAqLworCSAgICBpZiAoc2Nw LT5taWRpcyAhPSBOVUxMKQorCQlmcmVlKHNjcC0+bWlkaXMsIE1fVEVNUCk7CisJICAgIGlmIChz Y3AtPm1pZGlfZmxhZ3MgIT0gTlVMTCkKKwkJZnJlZShzY3AtPm1pZGlfZmxhZ3MsIE1fVEVNUCk7 CisJICAgIGlmIChzY3AtPm91dF9xLmIpCisJCWZyZWUoc2NwLT5vdXRfcS5iLCBNX1RFTVApOwor CSAgICBpZiAoc2NwLT5pbl9xLmIpCisJCWZyZWUoc2NwLT5pbl9xLmIsIE1fVEVNUCk7CisJICAg IGZyZWUoc2NwLCBNX0RFVkJVRik7CisJfQorb2s6CisJcmV0dXJuIHJldDsKK30KKworc3RhdGlj IGludAorc2VxX2RlbHVuaXQoaW50IHVuaXQpCit7CisJc3RydWN0IHNlcV9zb2Z0YyAqc2NwID0g c2Vxc1t1bml0XTsKKwlpbnQgaTsKKworCS8vU0VRX0RFQlVHKDQscHJpbnRmKCJzZXFfZGVsdW5p dDogJWRcbiIsIHVuaXQpKTsKKwlwcmludGYoInNlcV9kZWx1bml0OiAxIFxuIik7CisJbXR4X2xv Y2soJnNjcC0+c2VxX2xvY2spOworCisJc2NwLT5wbGF5aW5nID0gMDsKKwlzY3AtPmRvbmUgPSAx OworCWN2X2Jyb2FkY2FzdCgmc2NwLT5vdXRfY3YpOworCWN2X2Jyb2FkY2FzdCgmc2NwLT5zdGF0 ZV9jdik7CisJY3ZfYnJvYWRjYXN0KCZzY3AtPnJlc2V0X2N2KTsKKwlwcmludGYoInNlcV9kZWx1 bml0OiAyIFxuIik7CisJY3Zfd2FpdCgmc2NwLT50aF9jdiwgJnNjcC0+c2VxX2xvY2spOworCXBy aW50Zigic2VxX2RlbHVuaXQ6IDMuMCBcbiIpOworCW10eF91bmxvY2soJnNjcC0+c2VxX2xvY2sp OworCXByaW50Zigic2VxX2RlbHVuaXQ6IDMuMSBcbiIpOworCisJY3ZfZGVzdHJveSgmc2NwLT5z dGF0ZV9jdik7CisJcHJpbnRmKCJzZXFfZGVsdW5pdDogNCBcbiIpOworCWN2X2Rlc3Ryb3koJnNj cC0+ZW1wdHlfY3YpOworCXByaW50Zigic2VxX2RlbHVuaXQ6IDUgXG4iKTsKKwljdl9kZXN0cm95 KCZzY3AtPnJlc2V0X2N2KTsKKwlwcmludGYoInNlcV9kZWx1bml0OiA2IFxuIik7CisJY3ZfZGVz dHJveSgmc2NwLT5vdXRfY3YpOworCXByaW50Zigic2VxX2RlbHVuaXQ6IDcgXG4iKTsKKwljdl9k ZXN0cm95KCZzY3AtPmluX2N2KTsKKwlwcmludGYoInNlcV9kZWx1bml0OiA4IFxuIik7CisJY3Zf ZGVzdHJveSgmc2NwLT50aF9jdik7CisKKwlwcmludGYoInNlcV9kZWx1bml0OiAxMCBcbiIpOwor CWlmIChzY3AtPnNlcWRldikKKwkgICAgZGVzdHJveV9kZXYoc2NwLT5zZXFkZXYpOworCXByaW50 Zigic2VxX2RlbHVuaXQ6IDExIFxuIik7CisJaWYgKHNjcC0+bXVzaWNkZXYpCisJICAgIGRlc3Ry b3lfZGV2KHNjcC0+bXVzaWNkZXYpOworCXByaW50Zigic2VxX2RlbHVuaXQ6IDEyIFxuIik7CisJ c2NwLT5zZXFkZXYgPSBzY3AtPm11c2ljZGV2ID0gTlVMTDsKKwlpZiAoc2NwLT5taWRpcyAhPSBO VUxMKQorCSAgICBmcmVlKHNjcC0+bWlkaXMsIE1fVEVNUCk7CisJcHJpbnRmKCJzZXFfZGVsdW5p dDogMTMgXG4iKTsKKwlpZiAoc2NwLT5taWRpX2ZsYWdzICE9IE5VTEwpCisJICAgIGZyZWUoc2Nw LT5taWRpX2ZsYWdzLCBNX1RFTVApOworCXByaW50Zigic2VxX2RlbHVuaXQ6IDE0IFxuIik7CisJ ZnJlZShzY3AtPm91dF9xLmIsIE1fVEVNUCk7CisJcHJpbnRmKCJzZXFfZGVsdW5pdDogMTUgXG4i KTsKKwlmcmVlKHNjcC0+aW5fcS5iLCBNX1RFTVApOworCisJcHJpbnRmKCJzZXFfZGVsdW5pdDog MTYgXG4iKTsKKworCW10eF9kZXN0cm95KCZzY3AtPnNlcV9sb2NrKTsKKwlwcmludGYoInNlcV9k ZWx1bml0OiAxNyBcbiIpOworCWZyZWUoc2NwLCBNX0RFVkJVRik7CisKKwltdHhfbG9jaygmc2Vx aW5mb19tdHgpOworCWZvciAoIGkgPSB1bml0IDsgaSA8IChuc2VxIC0gMSkgOyBpKysgKQorCSAg ICBzZXFzW2ldID0gc2Vxc1tpKzFdOworCW5zZXEtLTsKKwltdHhfdW5sb2NrKCZzZXFpbmZvX210 eCk7CisKKwlyZXR1cm4gMDsKK30KKworaW50CitzZXFfbW9kZXZlbnQobW9kdWxlX3QgbW9kLCBp bnQgdHlwZSwgdm9pZCAqZGF0YSkKK3sKKwlpbnQgcmV0dmFsLCByOworCisJcmV0dmFsID0gMDsK KworCXN3aXRjaCAodHlwZSkgeworCSAgICBjYXNlIE1PRF9MT0FEOgorCQltdHhfaW5pdCgmc2Vx aW5mb19tdHgsICJzZXFtb2QiLCAwLCAwKTsKKwkJcmV0dmFsID0gc2VxX2FkZHVuaXQoKTsKKwkJ YnJlYWs7CisKKwkgICAgY2FzZSBNT0RfVU5MT0FEOgorCQl3aGlsZSAobnNlcSkgeworCQkJcj1z ZXFfZGVsdW5pdChuc2VxLTEpOworCQkJaWYgKHIpIHsKKwkJCQlyZXR2YWwgPSByOworCQkJCWJy ZWFrOworCQkJfQorCQl9CisJCWlmKG5zZXEgPT0gMCkgeworCQkJcmV0dmFsID0gMDsKKwkJCW10 eF9kZXN0cm95KCZzZXFpbmZvX210eCk7CisJCX0KKwkJYnJlYWs7CisKKwkgICAgZGVmYXVsdDoK KwkJYnJlYWs7CisJfQorCisJcmV0dXJuIHJldHZhbDsKK30KKworc3RhdGljIGludAorc2VxX2Zl dGNoX21pZChzdHJ1Y3Qgc2VxX3NvZnRjICpzY3AsIGludCB1bml0LCBrb2JqX3QgKm1kKQorewor CisJaWYgKHVuaXQgPiBzY3AtPm1pZGlfbnVtYmVyIHx8IHVuaXQgPCAwKQorCSAgICByZXR1cm4g RUlOVkFMOworCisJKm1kID0gc2NwLT5taWRpc1t1bml0XTsKKworCXJldHVybiAwOworfQorCitp bnQKK3NlcV9vcGVuKHN0cnVjdCBjZGV2ICppX2RldiwgaW50IGZsYWdzLCBpbnQgbW9kZSwgc3Ry dWN0IHRocmVhZCAqdGQpCit7CisJc3RydWN0IHNlcV9zb2Z0YyAqc2NwID0gaV9kZXYtPnNpX2Ry djE7CisJaW50IGk7CisKKwlpZiAoc2NwID09IE5VTEwpCisJICAgIHJldHVybiBFTlhJTzsKKwor CVNFUV9ERUJVRygzLHByaW50Zigic2VxX29wZW46IHNjcCAlcCB1bml0ICVkLCBmbGFncyAweCV4 LlxuIiwKKwkJICAgIHNjcCwgc2NwLT51bml0LCBmbGFncykpOworCisJLyoKKwkgKiBNYXJrIHRo aXMgZGV2aWNlIGJ1c3kuIAorCSAqLworCisJbXR4X2xvY2soJnNjcC0+c2VxX2xvY2spOworCWlm IChzY3AtPmJ1c3kpIHsKKwkJbXR4X3VubG9jaygmc2NwLT5zZXFfbG9jayk7CisJCVNFUV9ERUJV RygyLHByaW50Zigic2VxX29wZW46IHVuaXQgJWQgaXMgYnVzeS5cbiIsIHNjcC0+dW5pdCkpOwor CQlyZXR1cm4gRUJVU1k7CisJfQorCXNjcC0+ZmZsYWdzID0gZmxhZ3M7CisJLyoKKwlpZiAoKHNj cC0+ZmZsYWdzICYgT19OT05CTE9DSykgIT0gMCkKKwkJc2NwLT5mbGFncyB8PSBTRVFfRl9OQklP OworCQkqLworCXNjcC0+bXVzaWMgPSBNSURJREVWKGlfZGV2KSA9PSBTTkRfREVWX01VU0lDOwor CisJLyoKKwkgKiBFbnVtZXJhdGUgdGhlIGF2YWlsYWJsZSBtaWRpIGRldmljZXMKKwkgKi8KKwlz Y3AtPm1pZGlfbnVtYmVyID0gMDsKKwlzY3AtPm1heHVuaXRzID0gbWlkaW1hcHBlcl9vcGVuKHNj cC0+bWFwcGVyLCAmc2NwLT5tYXBwZXJfY29va2llKTsKKworCWlmIChzY3AtPm1heHVuaXRzID09 IDApCisJICAgIFNFUV9ERUJVRygyLHByaW50Zigic2VxX29wZW46IG5vIG1pZGkgZGV2aWNlc1xu IikpOworCisJZm9yIChpID0gMCA7IGkgPCBzY3AtPm1heHVuaXRzOyBpKyspIHsKKwkgICAgc2Nw LT5taWRpc1tzY3AtPm1pZGlfbnVtYmVyXSA9CisJCW1pZGltYXBwZXJfZmV0Y2hfc3ludGgoc2Nw LT5tYXBwZXIsIHNjcC0+bWFwcGVyX2Nvb2tpZSwgaSk7CisJICAgIGlmIChzY3AtPm1pZGlzW3Nj cC0+bWlkaV9udW1iZXJdKSB7CisJCWlmICggU1lOVEhfT1BFTihzY3AtPm1pZGlzW3NjcC0+bWlk aV9udW1iZXJdLCBzY3AsIHNjcC0+ZmZsYWdzKQorCQkJIT0gMCApCisJCSAgICBzY3AtPm1pZGlz W3NjcC0+bWlkaV9udW1iZXJdID0gTlVMTDsKKwkJZWxzZSB7CisJCSAgICBzY3AtPm1pZGlfZmxh Z3Nbc2NwLT5taWRpX251bWJlcl0gPQorCQkJU1lOVEhfUVVFUlkoc2NwLT5taWRpc1tzY3AtPm1p ZGlfbnVtYmVyXSk7CisJCSAgICBzY3AtPm1pZGlfbnVtYmVyKys7CisJCX0KKwkgICAgfQorCX0K KworCXRpbWVyX3NldHZhbHMoc2NwLCA2MCwgMTAwKTsKKworCXRpbWVyX3N0YXJ0KHNjcCk7CisJ dGltZXJfc3RvcChzY3ApOworCS8qCisJICogYWN0dWFsbHksIGlmIHdlJ3JlIGluIHJkb25seSBt b2RlLCB3ZSBzaG91bGQgc3RhcnQgdGhlIHRpbWVyCisJICovCisJLyoKKwkgKiBUT0RPOiBIYW5k bGUgcmVjb3JkaW5nIG5vdworCSAqLworCisJc2NwLT5vdXRfd2F0ZXIgPSBNSURJUV9TSVpFKHNj cC0+b3V0X3EpIC8gMjsKKworCXNjcC0+YnVzeSA9IDE7CisJbXR4X3VubG9jaygmc2NwLT5zZXFf bG9jayk7CisKKwlTRVFfREVCVUcoMixwcmludGYoInNlcV9vcGVuOiBvcGVuZWQsIG1vZGUgJXMu XG4iLAorCQkgICAgc2NwLT5tdXNpYyA/ICJtdXNpYyIgOiAic2VxdWVuY2VyIikpOworCVNFUV9E RUJVRygyLHByaW50ZigiU2VxdWVuY2VyICVkICVwIG9wZW5lZCBtYXh1bml0cyAlZCBtaWRpX251 bWJlciAlZDpcbiIsIHNjcC0+dW5pdCwgc2NwLCBzY3AtPm1heHVuaXRzLCBzY3AtPm1pZGlfbnVt YmVyKSk7CisJZm9yIChpPTA7aTxzY3AtPm1pZGlfbnVtYmVyO2krKykKKwkJU0VRX0RFQlVHKDMs cHJpbnRmKCIgIG1pZGkgJWQgJXBcbiIsIGksIHNjcC0+bWlkaXNbaV0pKTsKKworCXJldHVybiAw OworfQorCisvKgorICogc2VxX2Nsb3NlCisgKi8KK2ludAorc2VxX2Nsb3NlKHN0cnVjdCBjZGV2 ICppX2RldiwgaW50IGZsYWdzLCBpbnQgbW9kZSwgc3RydWN0IHRocmVhZCAqdGQpCit7CisJaW50 IGk7CisJc3RydWN0IHNlcV9zb2Z0YyAqc2NwID0gaV9kZXYtPnNpX2RydjE7CisJaW50IHJldDsK KworCWlmIChzY3AgPT0gTlVMTCkKKwkgICAgcmV0dXJuIEVOWElPOworCisJU0VRX0RFQlVHKDIs cHJpbnRmKCJzZXFfY2xvc2U6IHVuaXQgJWQuXG4iLCBzY3AtPnVuaXQpKTsKKworCW10eF9sb2Nr KCZzY3AtPnNlcV9sb2NrKTsKKworCXJldCA9IEVOWElPOworCWlmIChzY3AtPmJ1c3kgPT0gMCkK KwkgICAgZ290byBlcnI7CisKKwlzZXFfcmVzZXQoc2NwKTsKKwlzZXFfc3luYyhzY3ApOworCisJ Zm9yIChpID0gMCA7IGkgPCBzY3AtPm1pZGlfbnVtYmVyOyBpKyspCisJICAgIGlmIChzY3AtPm1p ZGlzW2ldKQorCQlTWU5USF9DTE9TRShzY3AtPm1pZGlzW2ldKTsKKworCW1pZGltYXBwZXJfY2xv c2Uoc2NwLT5tYXBwZXIsIHNjcC0+bWFwcGVyX2Nvb2tpZSk7CisKKwl0aW1lcl9zdG9wKHNjcCk7 CisKKwlzY3AtPmJ1c3kgPSAwOworCXJldCA9IDA7CisKK2VycjoKKwlTRVFfREVCVUcoMyxwcmlu dGYoInNlcV9jbG9zZTogY2xvc2VkIHJldCA9ICVkLlxuIiwgcmV0KSk7CisJbXR4X3VubG9jaygm c2NwLT5zZXFfbG9jayk7CisJcmV0dXJuIHJldDsKK30KKworaW50CitzZXFfcmVhZChzdHJ1Y3Qg Y2RldiAqaV9kZXYsIHN0cnVjdCB1aW8gKnVpbywgaW50IGlvZmxhZykKK3sKKwlpbnQgcmV0dmFs LCB1c2VkOworCXN0cnVjdCBzZXFfc29mdGMgKnNjcCA9IGlfZGV2LT5zaV9kcnYxOworI2RlZmlu ZSBTRVFfUlNJWkUgMzIKKwl1X2NoYXIgYnVmW1NFUV9SU0laRV07CisKKwlpZiAoc2NwID09IE5V TEwpCisJICAgIHJldHVybiBFTlhJTzsKKworCVNFUV9ERUJVRyg3LHByaW50Zigic2VxX3JlYWQ6 IHVuaXQgJWQsIHJlc2lkICVkLlxuIiwKKwkJICAgIHNjcC0+dW5pdCwgdWlvLT51aW9fcmVzaWQp KTsKKworCW10eF9sb2NrKCZzY3AtPnNlcV9sb2NrKTsKKwlpZiAoKHNjcC0+ZmZsYWdzICYgRlJF QUQpID09IDApIHsKKwkgICAgU0VRX0RFQlVHKDIscHJpbnRmKCJzZXFfcmVhZDogdW5pdCAlZCBp cyBub3QgZm9yIHJlYWRpbmcuXG4iLAorCQkJc2NwLT51bml0KSk7CisJICAgIHJldHZhbCA9IEVJ TzsKKwkgICAgZ290byBlcnIxOworCX0KKworCS8qCisJICogQmVnaW4gcmVjb3JkaW5nLgorCSAq LworCS8qCisJICogaWYgKChzY3AtPmZsYWdzICYgU0VRX0ZfUkVBRElORykgPT0gMCkKKwkgKi8K KwkvKgorCSAqIFRPRE8sIHN0YXJ0IHJlY29yZGluZyBpZiBub3QgYWxyZWFkCisJICovCisKKwkv KgorCSAqIEkgdGhpbmsgdGhlIHNlbWFudGljcyBhcmUgdG8gcmV0dXJuIGFzIHNvb24KKwkgKiBh cyBwb3NzaWJsZS4KKwkgKiBTZWNvbmQgdGhvdWdodCwgaXQgZG9lbnMndCBzZWVtIGxpa2UgbWlk aW1vdXRhaW4KKwkgKiBleHBlY3RzIHRoYXQgYXQgYWxsLgorCSAqIFRPRE86IExvb2sgdXAgaW4g c29tZSBzb3J0IG9mIHNwZWMKKwkgKi8KKworCXdoaWxlICh1aW8tPnVpb19yZXNpZCA+IDApIHsK KwkgICAgd2hpbGUgKE1JRElRX0VNUFRZKHNjcC0+aW5fcSkpIHsKKwkJcmV0dmFsID0gRVdPVUxE QkxPQ0s7CisJCS8qCisJCSAqIEkgd2lzaCBJIGtuZXcgd2hpY2ggb25lIHRvIGNhcmUgYWJvdXQK KwkJICovCisKKwkJaWYgKHNjcC0+ZmZsYWdzICYgT19OT05CTE9DSykKKwkJICAgIGdvdG8gZXJy MTsKKwkJaWYgKGlvZmxhZyAmIE9fTk9OQkxPQ0spCisJCSAgICBnb3RvIGVycjE7CisKKwkJcmV0 dmFsID0gY3Zfd2FpdF9zaWcoJnNjcC0+aW5fY3YsICZzY3AtPnNlcV9sb2NrKTsKKwkJaWYgKHJl dHZhbCA9PSBFSU5UUikKKwkJICAgIGdvdG8gZXJyMTsKKwkgICAgfQorCisJICAgIHVzZWQgPSBN SU4oTUlESVFfTEVOKHNjcC0+aW5fcSksIHVpby0+dWlvX3Jlc2lkKTsKKwkgICAgdXNlZCA9IE1J Tih1c2VkLCBTRVFfUlNJWkUpOworCisJICAgIFNFUV9ERUJVRyg4LHByaW50ZigibWlkaXJlYWQ6 IHVpb21vdmUgY2M9JWRcbiIsIHVzZWQpKTsKKwkgICAgTUlESVFfREVRKHNjcC0+aW5fcSwgYnVm LCB1c2VkKTsKKwkgICAgcmV0dmFsID0gdWlvbW92ZShidWYsIHVzZWQsIHVpbyk7CisJICAgIGlm IChyZXR2YWwpCisJCWdvdG8gZXJyMTsKKwl9CisKKwlyZXR2YWwgPSAwOworZXJyMToKKwltdHhf dW5sb2NrKCZzY3AtPnNlcV9sb2NrKTsKKwlTRVFfREVCVUcoNixwcmludGYoInNlcV9yZWFkOiBy ZXQgJWQsIHJlc2lkICVkLlxuIiwKKwkJICAgIHJldHZhbCwgdWlvLT51aW9fcmVzaWQpKTsKKwor CXJldHVybiByZXR2YWw7Cit9CisKK2ludAorc2VxX3dyaXRlKHN0cnVjdCBjZGV2ICppX2Rldiwg c3RydWN0IHVpbyAqdWlvLCBpbnQgaW9mbGFnKQoreworCXVfY2hhciBldmVudFtFVl9TWl0sIG5l d2V2ZW50W0VWX1NaXSwgZXZfY29kZTsKKwlzdHJ1Y3Qgc2VxX3NvZnRjICpzY3AgPSBpX2Rldi0+ c2lfZHJ2MTsKKwlpbnQgcmV0dmFsOworCWludCB1c2VkOworCisJU0VRX0RFQlVHKDcscHJpbnRm KCJzZXFfd3JpdGU6IHVuaXQgJWQsIHJlc2lkICVkLlxuIiwKKwkJICAgIHNjcC0+dW5pdCwgdWlv LT51aW9fcmVzaWQpKTsKKworCWlmIChzY3AgPT0gTlVMTCkKKwkgICAgcmV0dXJuIEVOWElPOwor CisJbXR4X2xvY2soJnNjcC0+c2VxX2xvY2spOworCisJaWYgKChzY3AtPmZmbGFncyAmIEZXUklU RSkgPT0gMCkgeworCSAgICBTRVFfREVCVUcoMixwcmludGYoInNlcV93cml0ZTogdW5pdCAlZCBp cyBub3QgZm9yIHdyaXRpbmcuXG4iLAorCQkJc2NwLT51bml0KSk7CisJICAgIHJldHZhbCA9IEVJ TzsKKwkgICAgZ290byBlcnIwOworCX0KKworCXdoaWxlICh1aW8tPnVpb19yZXNpZCA+IDApIHsK KwkgICAgd2hpbGUgKE1JRElRX0FWQUlMKHNjcC0+b3V0X3EpID09IDApIHsKKwkJcmV0dmFsID0g RVdPVUxEQkxPQ0s7CisJCWlmIChzY3AtPmZmbGFncyAmIE9fTk9OQkxPQ0spCisJCSAgICBnb3Rv IGVycjA7CisJCWlmIChpb2ZsYWcgJiBPX05PTkJMT0NLKQorCQkgICAgZ290byBlcnIwOworCQlT RVFfREVCVUcoOCxwcmludGYoInNlcV93cml0ZSBjdndhaXRcbiIpKTsKKworCQlzY3AtPnBsYXlp bmcgPSAxOworCQljdl9icm9hZGNhc3QoJnNjcC0+b3V0X2N2KTsKKwkJY3ZfYnJvYWRjYXN0KCZz Y3AtPnN0YXRlX2N2KTsKKworCQlyZXR2YWwgPSBjdl93YWl0X3NpZygmc2NwLT5vdXRfY3YsICZz Y3AtPnNlcV9sb2NrKTsKKwkJICAgIC8qCisJCSAgICAgKiBXZSBzbGVwdCwgbWF5YmUgdGhpbmdz IGhhdmUgY2hhbmdlZCBzaW5jZSBsYXN0CisJCSAgICAgKiBkeWluZyBjaGVjaworCQkgICAgICov CisJCWlmIChyZXR2YWwgPT0gRUlOVFIpCisJCSAgICBnb3RvIGVycjA7CisjaWYgMAorCQkgICAg LyoKKwkJICAgICAqIFVzZWxlc3MgdGVzdAorCQkgICAgICovCisJCWlmIChzY3AgIT0gaV9kZXYt PnNpX2RydjEpCisJCSAgICByZXR2YWwgPSBFTlhJTzsKKyNlbmRpZgorCSAgICB9CisKKwkgICAg dXNlZCA9IE1JTih1aW8tPnVpb19yZXNpZCwgNCk7CisKKwkgICAgU0VRX0RFQlVHKDgscHJpbnRm KCJzZXFvdXQ6IHJlc2lkICVkIGxlbiAlamQgYXZhaWwgJWpkXG4iLAorCQkJdWlvLT51aW9fcmVz aWQsIChpbnRtYXhfdClNSURJUV9MRU4oc2NwLT5vdXRfcSksCisJCQkoaW50bWF4X3QpTUlESVFf QVZBSUwoc2NwLT5vdXRfcSkpKTsKKworCSAgICBpZiAodXNlZCAhPSA0KSB7CisJCXJldHZhbCA9 IEVOWElPOworCQlnb3RvIGVycjA7CisJICAgIH0KKworCSAgICByZXR2YWwgPSB1aW9tb3ZlKGV2 ZW50LCB1c2VkLCB1aW8pOworCSAgICBpZiAocmV0dmFsKQorCQlnb3RvIGVycjA7CisKKwkgICAg ZXZfY29kZSA9IGV2ZW50WzBdOworCSAgICBTRVFfREVCVUcoOCxwcmludGYoInNlcV93cml0ZTog dW5pdCAlZCwgZXZlbnQgJXMuXG4iLAorCQkJc2NwLT51bml0LCBtaWRpX2NtZG5hbWUoZXZfY29k ZSwgY21kdGFiX3NlcWV2ZW50KSkpOworCisJICAgIC8qIEhhdmUgYSBsb29rIGF0IHRoZSBldmVu dCBjb2RlLiAqLworCSAgICBpZiAoZXZfY29kZSA9PSBTRVFfRlVMTFNJWkUpIHsKKworCQkvKgor CQkgKiBUT0RPOiByZXN0b3JlIGNvZGUgZm9yIFNFUV9GVUxMU0laRQorCQkgKi8KKyNpZiAwCisJ CS8qIEEgbG9uZyBldmVudCwgdGhlc2UgYXJlIHRoZSBwYXRjaGVzL3NhbXBsZXMgZm9yIGEgc3lu dGhlc2l6ZXIuICovCisJCW1pZGl1bml0ID0gKih1X3Nob3J0ICopJmV2ZW50WzJdOworCQltdHhf bG9jaygmc2QtPnNlcV9sb2NrKTsKKwkJcmV0ID0gbG9va3VwX21pZGlkZXYoc2NwLCBtaWRpdW5p dCwgTE9PS1VQX09QRU4sICZtZCk7CisJCW10eF91bmxvY2soJnNkLT5zZXFfbG9jayk7CisJCWlm IChyZXQgIT0gMCkKKwkJICAgIHJldHVybiAocmV0KTsKKworCQlTRVFfREVCVUcocHJpbnRmKCJz ZXFfd3JpdGU6IGxvYWRpbmcgYSBwYXRjaCB0byB0aGUgdW5pdCAlZC5cbiIsIG1pZGl1bml0KSk7 CisKKwkJcmV0ID0gbWQtPnN5bnRoLmxvYWRwYXRjaChtZCwgKihzaG9ydCAqKSZldmVudFswXSwg YnVmLCBwICsgNCwgY291bnQsIDApOworCQlyZXR1cm4gKHJldCk7CisjZWxzZQorCQkvKgorCQkg KiBGb3Igbm93LCBqdXN0IGZsdXNoIHRoZSBkYXJuIGJ1ZmZlcgorCQkgKi8KKwkJU0VRX0RFQlVH KDIscHJpbnRmKCJzZXFfd3JpdGU6IFNFUV9GVUxMU0laRSBmbHVzaW5nIGJ1ZmZlci5cbiIpKTsK KwkJd2hpbGUgKHVpby0+dWlvX3Jlc2lkID4gMCkgeworCQkgICAgcmV0dmFsID0gdWlvbW92ZShl dmVudCwgRVZfU1osIHVpbyk7CisJCSAgICBpZiAocmV0dmFsKQorCQkJZ290byBlcnIwOworCisJ CX0KKwkJcmV0dmFsID0gMDsKKwkJZ290byBlcnIwOworI2VuZGlmCisJICAgIH0KKworCSAgICBy ZXR2YWwgPSBFSU5WQUw7CisJICAgIGlmIChldl9jb2RlID49IDEyOCkgeworCisJCS8qCisJCSAq IFNvbWUgc29ydCBvZiBhbiBleHRlbmRlZCBldmVudC4gVGhlIHNpemUgaXMgZWlnaHQgYnl0ZXMu CisJCSAqIHNjb29wIGV4dHJhIGluZm8uCisJCSAqLworCQlpZiAoc2NwLT5tdXNpYyAmJiBldl9j b2RlID09IFNFUV9FWFRFTkRFRCkgeworCQkgICAgU0VRX0RFQlVHKDIscHJpbnRmKCJzZXFfd3Jp dGU6IGludmFsaWQgbGV2ZWwgdHdvIGV2ZW50ICV4LlxuIiwgZXZfY29kZSkpOworCQkgICAgZ290 byBlcnIwOworCQl9CisJCWlmICh1aW9tb3ZlKChjYWRkcl90KSZldmVudFs0XSwgNCwgdWlvKSkg eworCQkgICAgU0VRX0RFQlVHKDIscHJpbnRmKCJzZXFfd3JpdGU6IHVzZXIgbWVtb3J5IG1hbmds ZWQ/XG4iKSk7CisJCSAgICBnb3RvIGVycjA7CisJCX0KKwkgICAgfSBlbHNlIHsKKwkJLyoKKwkJ ICogU2l6ZSBmb3VyIGV2ZW50LgorCQkgKi8KKwkJaWYgKHNjcC0+bXVzaWMpIHsKKwkJICAgIFNF UV9ERUJVRygyLHByaW50Zigic2VxX3dyaXRlOiBmb3VyIGJ5dGUgZXZlbnQgaW4gbXVzaWMgbW9k ZS5cbiIpKTsKKwkJICAgIGdvdG8gZXJyMDsKKwkJfQorCSAgICB9CisJICAgIGlmIChldl9jb2Rl ID09IFNFUV9NSURJUFVUQykgeworCQkvKgorCQkgKiBUT0RPOiBldmVudFsyXSBpcyB1bml0IG51 bWJlciB0byByZWNlaXZlIGNoYXIuICBSYW5nZSBjaGVjaworCQkgKiBpdAorCQkgKi8KKwkgICAg fQorCisJICAgIGlmIChzY3AtPm11c2ljKSB7CisjaWYgbm90X2V2ZXJfZXZlcgorCQlpZiAoZXZl bnRbMF0gPT0gRVZfVElNSU5HICYmIAorCQkJKGV2ZW50WzFdID09IFRNUl9TVEFSVCB8fCBldmVu dFsxXSA9PSBUTVJfU1RPUCkgKSB7CisJCSAgICAvKgorCQkgICAgICogRm9yIG5vdywgdHJ5IHRv IG1ha2UgbWlkaW1vdXRhaW4gd29yayBieQorCQkgICAgICogZm9yY2luZyB0aGVzZSBldmVudHMg dG8gYmUgcHJvY2Vzc2VkIGltbWVkaWF0bHkKKwkJICAgICAqLworCQkgICAgc2VxX3Byb2Nlc3Nl dmVudChzY3AsIGV2ZW50KTsKKwkJfQorCQllbHNlCisJCSAgICBNSURJUV9FTlEoc2NwLT5vdXRf cSwgZXZlbnQsIEVWX1NaKTsKKyNlbHNlCisJCU1JRElRX0VOUShzY3AtPm91dF9xLCBldmVudCwg RVZfU1opOworI2VuZGlmCisJICAgIH0gZWxzZSB7CisJCWlmIChzZXFfY29udmVydG9sZChldmVu dCwgbmV3ZXZlbnQpID4gMCkKKwkJICAgIE1JRElRX0VOUShzY3AtPm91dF9xLCBuZXdldmVudCwg RVZfU1opOworI2lmIDAKKwkJZWxzZQorCQkgICAgZ290byBlcnIwOworI2VuZGlmCisJICAgIH0K KworCX0KKworCXNjcC0+cGxheWluZyA9IDE7CisJY3ZfYnJvYWRjYXN0KCZzY3AtPnN0YXRlX2N2 KTsKKwljdl9icm9hZGNhc3QoJnNjcC0+b3V0X2N2KTsKKworCXJldHZhbCA9IDA7CisKK2VycjA6 CisJU0VRX0RFQlVHKDYscHJpbnRmKCJzZXFfd3JpdGUgZG9uZTogbGVmdG92ZXIgYnVmZmVyIGxl bmd0aCAlZCByZXR2YWwgJWRcbiIsCisJCSAgICB1aW8tPnVpb19yZXNpZCwgcmV0dmFsKSk7CisJ bXR4X3VubG9jaygmc2NwLT5zZXFfbG9jayk7CisJcmV0dXJuIHJldHZhbDsKK30KKworaW50Citz ZXFfaW9jdGwoc3RydWN0IGNkZXYgKmlfZGV2LCB1X2xvbmcgY21kLCBjYWRkcl90IGFyZywgaW50 IG1vZGUsIHN0cnVjdCB0aHJlYWQgKnRkKQoreworCWludCBtaWRpdW5pdCwgcmV0LCB0bXA7CisJ c3RydWN0IHNlcV9zb2Z0YyAqc2NwID0gaV9kZXYtPnNpX2RydjE7CisJc3RydWN0IHN5bnRoX2lu Zm8gKnN5bnRoaW5mbzsKKwlzdHJ1Y3QgbWlkaV9pbmZvICptaWRpaW5mbzsKKwl1X2NoYXIgZXZl bnRbRVZfU1pdOworCXVfY2hhciBuZXdldmVudFtFVl9TWl07CisKKwlrb2JqX3QgbWQ7CisJLyoK KwkgKiBzdHJ1Y3Qgc25kX3NpemUgKnNuZHNpemU7CisJICovCisKKwlpZiAoc2NwID09IE5VTEwp CisJICAgIHJldHVybiBFTlhJTzsKKworCVNFUV9ERUJVRyg2LHByaW50Zigic2VxX2lvY3RsOiB1 bml0ICVkLCBjbWQgJXMuXG4iLAorCQkgICAgc2NwLT51bml0LCBtaWRpX2NtZG5hbWUoY21kLCBj bWR0YWJfc2VxaW9jdGwpKSk7CisKKwlyZXQgPSAwOworCisJc3dpdGNoIChjbWQpIHsKKwkgICAg Y2FzZSBTTkRDVExfU0VRX0dFVFRJTUU6CisJCS8qCisJCSAqIGlvY3RsIG5lZWRlZCBieSBsaWJ0 c2UKKwkJICovCisJCW10eF9sb2NrKCZzY3AtPnNlcV9sb2NrKTsKKwkJKihpbnQgKilhcmcgPSB0 aW1lcl9ub3coc2NwKTsKKwkJbXR4X3VubG9jaygmc2NwLT5zZXFfbG9jayk7CisJCVNFUV9ERUJV Ryg2LHByaW50Zigic2VxX2lvY3RsOiBnZXR0aW1lICVkLlxuIiwgKihpbnQgKilhcmcpKTsKKwkJ cmV0ID0gMDsKKwkJYnJlYWs7CisJICAgIGNhc2UgU05EQ1RMX1RNUl9NRVRST05PTUU6CisJCS8q IGZhbGx0aHJvdWdoICovCisJICAgIGNhc2UgU05EQ1RMX1RNUl9TT1VSQ0U6CisJCS8qCisJCSAq IE5vdCBpbXBsZW1lbnRlZAorCQkgKi8KKwkJcmV0ID0gMDsKKwkJYnJlYWs7CisJICAgIGNhc2Ug U05EQ1RMX1RNUl9URU1QTzoKKwkJZXZlbnRbMV0gPSBUTVJfVEVNUE87CisJCWdvdG8gdGltZXJl dmVudDsKKwkgICAgY2FzZSBTTkRDVExfVE1SX1RJTUVCQVNFOgorCQlldmVudFsxXSA9IFRNUl9U SU1FUkJBU0U7CisJCWdvdG8gdGltZXJldmVudDsKKwkgICAgY2FzZSBTTkRDVExfVE1SX1NUQVJU OgorCQlldmVudFsxXSA9IFRNUl9TVEFSVDsKKwkJZ290byB0aW1lcmV2ZW50OworCSAgICBjYXNl IFNORENUTF9UTVJfU1RPUDoKKwkJZXZlbnRbMV0gPSBUTVJfU1RPUDsKKwkJZ290byB0aW1lcmV2 ZW50OworCSAgICBjYXNlIFNORENUTF9UTVJfQ09OVElOVUU6CisJCWV2ZW50WzFdID0gVE1SX0NP TlRJTlVFOworCSAgICB0aW1lcmV2ZW50OgorCQlldmVudFswXSA9IEVWX1RJTUlORzsKKwkJZXZl bnRbNF0gPSAqKGludCAqKWFyZyAmIDB4RkY7CisJCWV2ZW50WzVdID0gKCooaW50ICopYXJnID4+ IDgpICYgMHhGRjsKKwkJZXZlbnRbNl0gPSAoKihpbnQgKilhcmcgPj4gMTYpICYgMHhGRjsKKwkJ ZXZlbnRbN10gPSAoKihpbnQgKilhcmcgPj4gMjQpICYgMHhGRjsKKwkJbXR4X2xvY2soJnNjcC0+ c2VxX2xvY2spOworCQlpZiAoIXNjcC0+bXVzaWMpIHsKKwkJICAgIHJldCA9IEVJTlZBTDsKKwkJ ICAgIG10eF91bmxvY2soJnNjcC0+c2VxX2xvY2spOworCQkgICAgYnJlYWs7CisJCX0KKwkJc2Vx X3Byb2Nlc3NldmVudChzY3AsIGV2ZW50KTsKKwkJbXR4X3VubG9jaygmc2NwLT5zZXFfbG9jayk7 CisJCWJyZWFrOworCSAgICBjYXNlIFNORENUTF9UTVJfU0VMRUNUOgorCQlTRVFfREVCVUcoMixw cmludGYoInNlcV9pb2N0bDogU05EQ1RMX1RNUl9TRUxFQ1Qgbm90IHN1cHBvcnRlZFxuIikpOwor CQlyZXQgPSBFSU5WQUw7CisJCWJyZWFrOworCSAgICBjYXNlIFNORENUTF9TRVFfU1lOQzoKKwkJ aWYgKG1vZGUgPT0gT19SRE9OTFkpIHsKKwkJICAgIHJldCA9IDA7CisJCSAgICBicmVhazsKKwkJ fQorCQltdHhfbG9jaygmc2NwLT5zZXFfbG9jayk7CisJCXJldCA9IHNlcV9zeW5jKHNjcCk7CisJ CW10eF91bmxvY2soJnNjcC0+c2VxX2xvY2spOworCQlicmVhazsKKwkgICAgY2FzZSBTTkRDVExf U0VRX1BBTklDOgorCQkvKiBmYWxsdGhyb3VnaCAqLworCSAgICBjYXNlIFNORENUTF9TRVFfUkVT RVQ6CisJCS8qCisJCSAqIFNORENUTF9TRVFfUEFOSUMgPT0gU05EQ1RMX1NFUV9SRVNFVAorCQkg Ki8KKwkJbXR4X2xvY2soJnNjcC0+c2VxX2xvY2spOworCQlzZXFfcmVzZXQoc2NwKTsKKwkJbXR4 X3VubG9jaygmc2NwLT5zZXFfbG9jayk7CisJCXJldCA9IDA7CisJCWJyZWFrOworCSAgICBjYXNl IFNORENUTF9TRVFfVEVTVE1JREk6CisJCW10eF9sb2NrKCZzY3AtPnNlcV9sb2NrKTsKKwkJLyoK KwkJICogVE9ETzogU05EQ1RMX1NFUV9URVNUTUlESSBub3cgbWVhbnMgImNhbiBJIHdyaXRlIHRv IHRoZQorCQkgKiBkZXZpY2U/Ii4KKwkJICovCisJCW10eF91bmxvY2soJnNjcC0+c2VxX2xvY2sp OworCQlicmVhazsKKyNpZiAwCisJICAgIGNhc2UgU05EQ1RMX1NFUV9HRVRJTkNPVU5UOgorCQlp ZiAobW9kZSA9PSBPX1dST05MWSkKKwkJICAgICooaW50ICopYXJnID0gMDsKKwkJZWxzZSB7CisJ CSAgICBtdHhfbG9jaygmc2NwLT5zZXFfbG9jayk7CisJCSAgICAqKGludCAqKWFyZyA9IHNjcC0+ aW5fcS5ybDsKKwkJICAgIG10eF91bmxvY2soJnNjcC0+c2VxX2xvY2spOworCQkgICAgU0VRX0RF QlVHKHByaW50Zigic2VxX2lvY3RsOiBpbmNvdW50ICVkLlxuIiwgKihpbnQgKilhcmcpKTsKKwkJ fQorCQlyZXQgPSAwOworCQlicmVhazsKKwkgICAgY2FzZSBTTkRDVExfU0VRX0dFVE9VVENPVU5U OgorCQlpZiAobW9kZSA9PSBPX1JET05MWSkKKwkJICAgICooaW50ICopYXJnID0gMDsKKwkJZWxz ZSB7CisJCSAgICBtdHhfbG9jaygmc2NwLT5zZXFfbG9jayk7CisJCSAgICAqKGludCAqKWFyZyA9 IHNjcC0+b3V0X3EuZmw7CisJCSAgICBtdHhfdW5sb2NrKCZzY3AtPnNlcV9sb2NrKTsKKwkJICAg IFNFUV9ERUJVRyhwcmludGYoInNlcV9pb2N0bDogb3V0Y291bnQgJWQuXG4iLCAqKGludCAqKWFy ZykpOworCQl9CisJCXJldCA9IDA7CisJCWJyZWFrOworI2VuZGlmCisJICAgIGNhc2UgU05EQ1RM X1NFUV9DVFJMUkFURToKKwkJaWYgKCooaW50ICopYXJnICE9IDApIHsKKwkJICAgIHJldCA9IEVJ TlZBTDsKKwkJICAgIGJyZWFrOworCQl9CisJCW10eF9sb2NrKCZzY3AtPnNlcV9sb2NrKTsKKwkJ KihpbnQgKilhcmcgPSBzY3AtPnRpbWVyYmFzZTsKKwkJbXR4X3VubG9jaygmc2NwLT5zZXFfbG9j ayk7CisJCVNFUV9ERUJVRygzLHByaW50Zigic2VxX2lvY3RsOiBjdHJscmF0ZSAlZC5cbiIsICoo aW50ICopYXJnKSk7CisJCXJldCA9IDA7CisJCWJyZWFrOworCQkvKgorCQkgKiBUT0RPOiBpb2N0 bCBTTkRDVExfU0VRX1JFU0VUU0FNUExFUworCQkgKi8KKyNpZiAwCisJICAgIGNhc2UgU05EQ1RM X1NFUV9SRVNFVFNBTVBMRVM6CisJCW10eF9sb2NrKCZzY3AtPnNlcV9sb2NrKTsKKwkJcmV0ID0g bG9va3VwX21pZGlkZXYoc2NwLCAqKGludCAqKWFyZywgTE9PS1VQX09QRU4sICZtZCk7CisJCW10 eF91bmxvY2soJnNjcC0+c2VxX2xvY2spOworCQlpZiAocmV0ICE9IDApCisJCSAgICBicmVhazsK KwkJcmV0ID0gbWlkaV9pb2N0bChNSURJTUtERVYobWFqb3IoaV9kZXYpLCAqKGludCAqKWFyZywg U05EX0RFVl9NSURJTiksIGNtZCwgYXJnLCBtb2RlLCB0ZCk7CisJCWJyZWFrOworI2VuZGlmCisJ ICAgIGNhc2UgU05EQ1RMX1NFUV9OUlNZTlRIUzoKKwkJbXR4X2xvY2soJnNjcC0+c2VxX2xvY2sp OworCQkgICAgKihpbnQgKilhcmcgPSBzY3AtPm1pZGlfbnVtYmVyOworCQltdHhfdW5sb2NrKCZz Y3AtPnNlcV9sb2NrKTsKKwkJU0VRX0RFQlVHKDMscHJpbnRmKCJzZXFfaW9jdGw6IHN5bnRocyAl ZC5cbiIsICooaW50ICopYXJnKSk7CisJCXJldCA9IDA7CisJCWJyZWFrOworCSAgICBjYXNlIFNO RENUTF9TRVFfTlJNSURJUzoKKwkJbXR4X2xvY2soJnNjcC0+c2VxX2xvY2spOworCQlpZiAoc2Nw LT5tdXNpYykKKwkJICAgICooaW50ICopYXJnID0gMDsKKwkJZWxzZSB7CisJCSAgICAvKgorCQkg ICAgICogVE9ETzogY291bnQgdGhlIG51bWJkZXIgb2YgZGV2aWNlcyB0aGF0IGNhbiBXUklURVJB VworCQkgICAgICovCisJCSAgICAqKGludCAqKWFyZyA9IHNjcC0+bWlkaV9udW1iZXI7CisJCX0K KwkJbXR4X3VubG9jaygmc2NwLT5zZXFfbG9jayk7CisJCVNFUV9ERUJVRygzLHByaW50Zigic2Vx X2lvY3RsOiBtaWRpcyAlZC5cbiIsICooaW50ICopYXJnKSk7CisJCXJldCA9IDA7CisJCWJyZWFr OworCQkvKgorCQkgKiBUT0RPOiBpb2N0bCBTTkRDVExfU1lOVEhfTUVNQVZMCisJCSAqLworI2lm IDAKKwkgICAgY2FzZSBTTkRDVExfU1lOVEhfTUVNQVZMOgorCQltdHhfbG9jaygmc2NwLT5zZXFf bG9jayk7CisJCXJldCA9IGxvb2t1cF9taWRpZGV2KHNjcCwgKihpbnQgKilhcmcsIExPT0tVUF9P UEVOLCAmbWQpOworCQltdHhfdW5sb2NrKCZzY3AtPnNlcV9sb2NrKTsKKwkJaWYgKHJldCAhPSAw KQorCQkgICAgYnJlYWs7CisJCXJldCA9IG1pZGlfaW9jdGwoTUlESU1LREVWKG1ham9yKGlfZGV2 KSwgKihpbnQgKilhcmcsIFNORF9ERVZfTUlESU4pLCBjbWQsIGFyZywgbW9kZSwgdGQpOworCQli cmVhazsKKyNlbmRpZgorCSAgICBjYXNlIFNORENUTF9TRVFfT1VUT0ZCQU5EOgorCQlmb3IgKHJl dCA9IDA7IHJldCA8IEVWX1NaOyByZXQrKykKKwkJICAgIGV2ZW50W3JldF0gPSAodV9jaGFyKWFy Z1swXTsKKworCQltdHhfbG9jaygmc2NwLT5zZXFfbG9jayk7CisJCWlmIChzY3AtPm11c2ljKQor CQkgICAgcmV0ID0gc2VxX3Byb2Nlc3NldmVudChzY3AsIGV2ZW50KTsKKwkJZWxzZSB7CisJCSAg ICBpZiAoc2VxX2NvbnZlcnRvbGQoZXZlbnQsIG5ld2V2ZW50KSA+IDApCisJCQlyZXQgPSBzZXFf cHJvY2Vzc2V2ZW50KHNjcCwgbmV3ZXZlbnQpOworCQkgICAgZWxzZSByZXQgPSBFSU5WQUw7CisJ CX0KKwkJbXR4X3VubG9jaygmc2NwLT5zZXFfbG9jayk7CisJCWJyZWFrOworCSAgICBjYXNlIFNO RENUTF9TWU5USF9JTkZPOgorCQlzeW50aGluZm8gPSAoc3RydWN0IHN5bnRoX2luZm8gKilhcmc7 CisJCW1pZGl1bml0ID0gc3ludGhpbmZvLT5kZXZpY2U7CisJCW10eF9sb2NrKCZzY3AtPnNlcV9s b2NrKTsKKwkJaWYgKHNlcV9mZXRjaF9taWQoc2NwLCBtaWRpdW5pdCwgJm1kKSA9PSAwKSB7CisJ CSAgICBiemVybyhzeW50aGluZm8sIHNpemVvZigqc3ludGhpbmZvKSk7CisJCSAgICBzeW50aGlu Zm8tPm5hbWVbMF0gPSAnZic7CisJCSAgICBzeW50aGluZm8tPm5hbWVbMV0gPSAnYSc7CisJCSAg ICBzeW50aGluZm8tPm5hbWVbMl0gPSAnayc7CisJCSAgICBzeW50aGluZm8tPm5hbWVbM10gPSAn ZSc7CisJCSAgICBzeW50aGluZm8tPm5hbWVbNF0gPSAncyc7CisJCSAgICBzeW50aGluZm8tPm5h bWVbNV0gPSAneSc7CisJCSAgICBzeW50aGluZm8tPm5hbWVbNl0gPSAnbic7CisJCSAgICBzeW50 aGluZm8tPm5hbWVbN10gPSAndCc7CisJCSAgICBzeW50aGluZm8tPm5hbWVbOF0gPSAnaCc7CisJ CSAgICBzeW50aGluZm8tPmRldmljZSA9IG1pZGl1bml0OworCQkgICAgc3ludGhpbmZvLT5zeW50 aF90eXBlID0gU1lOVEhfVFlQRV9NSURJOworCQkgICAgc3ludGhpbmZvLT5jYXBhYmlsaXRpZXMg PSBzY3AtPm1pZGlfZmxhZ3NbbWlkaXVuaXRdOworCQkgICAgcmV0ID0gMDsKKwkJfSBlbHNlCisJ CSAgICByZXQgPSBFSU5WQUw7CisJCW10eF91bmxvY2soJnNjcC0+c2VxX2xvY2spOworCQlicmVh azsKKwkgICAgY2FzZSBTTkRDVExfTUlESV9JTkZPOgorCQltaWRpaW5mbyA9IChzdHJ1Y3QgbWlk aV9pbmZvICopYXJnOworCQltaWRpdW5pdCA9IG1pZGlpbmZvLT5kZXZpY2U7CisJCW10eF9sb2Nr KCZzY3AtPnNlcV9sb2NrKTsKKwkJaWYgKHNlcV9mZXRjaF9taWQoc2NwLCBtaWRpdW5pdCwgJm1k KSA9PSAwKSB7CisJCSAgICBiemVybyhtaWRpaW5mbywgc2l6ZW9mKCptaWRpaW5mbykpOworCQkg ICAgbWlkaWluZm8tPm5hbWVbMF0gPSAnZic7CisJCSAgICBtaWRpaW5mby0+bmFtZVsxXSA9ICdh JzsKKwkJICAgIG1pZGlpbmZvLT5uYW1lWzJdID0gJ2snOworCQkgICAgbWlkaWluZm8tPm5hbWVb M10gPSAnZSc7CisJCSAgICBtaWRpaW5mby0+bmFtZVs0XSA9ICdtJzsKKwkJICAgIG1pZGlpbmZv LT5uYW1lWzVdID0gJ2knOworCQkgICAgbWlkaWluZm8tPm5hbWVbNl0gPSAnZCc7CisJCSAgICBt aWRpaW5mby0+bmFtZVs3XSA9ICdpJzsKKwkJICAgIG1pZGlpbmZvLT5kZXZpY2UgPSBtaWRpdW5p dDsKKwkJICAgIG1pZGlpbmZvLT5jYXBhYmlsaXRpZXMgPSBzY3AtPm1pZGlfZmxhZ3NbbWlkaXVu aXRdOworCQkgICAgLyoKKwkJICAgICAqIFRPRE86IFdoYXQgZGV2dHlwZT8KKwkJICAgICAqLwor CQkgICAgbWlkaWluZm8tPmRldl90eXBlID0gMHgwMTsKKwkJICAgIHJldCA9IDA7CisJCX0gZWxz ZQorCQkgICAgcmV0ID0gRUlOVkFMOworCQltdHhfdW5sb2NrKCZzY3AtPnNlcV9sb2NrKTsKKwkJ YnJlYWs7CisJICAgIGNhc2UgU05EQ1RMX1NFUV9USFJFU0hPTEQ6CisJCW10eF9sb2NrKCZzY3At PnNlcV9sb2NrKTsKKwkJUkFOR0UoKihpbnQgKilhcmcsIDEsIE1JRElRX1NJWkUoc2NwLT5vdXRf cSkgLSAxKTsKKwkJc2NwLT5vdXRfd2F0ZXIgPSAqKGludCAqKWFyZzsKKwkJbXR4X3VubG9jaygm c2NwLT5zZXFfbG9jayk7CisJCVNFUV9ERUJVRygzLHByaW50Zigic2VxX2lvY3RsOiB3YXRlciAl ZC5cbiIsICooaW50ICopYXJnKSk7CisJCXJldCA9IDA7CisJCWJyZWFrOworCSAgICBjYXNlIFNO RENUTF9NSURJX1BSRVRJTUU6CisJCXRtcCA9ICooaW50ICopYXJnOworCQlpZiAodG1wIDwgMCkK KwkJICAgIHRtcCA9IDA7CisJCW10eF9sb2NrKCZzY3AtPnNlcV9sb2NrKTsKKwkJc2NwLT5wcmVf ZXZlbnRfdGltZW91dCA9IChoeiAqIHRtcCkgLyAxMDsKKwkJKihpbnQgKilhcmcgPSBzY3AtPnBy ZV9ldmVudF90aW1lb3V0OworCQltdHhfdW5sb2NrKCZzY3AtPnNlcV9sb2NrKTsKKwkJU0VRX0RF QlVHKDMscHJpbnRmKCJzZXFfaW9jdGw6IHByZXRpbWUgJWQuXG4iLCAqKGludCAqKWFyZykpOwor CQlyZXQgPSAwOworCQlicmVhazsKKwkgICAgY2FzZSBTTkRDVExfRk1fNE9QX0VOQUJMRToKKwkg ICAgY2FzZSBTTkRDVExfUE1HUl9JRkFDRToKKwkgICAgY2FzZSBTTkRDVExfUE1HUl9BQ0NFU1M6 CisJCS8qCisJCSAqIFBhdGNoIG1hbmFnZXIgYW5kIGZtIGFyZSBkZWQsIGRlZCwgZGVkLgorCQkg Ki8KKwkJLyogZmFsbHRocm91Z2ggKi8KKwkgICAgZGVmYXVsdDoKKwkJLyoKKwkJICogVE9ETzog Q29uc2lkZXIgaW9jdGwgZGVmYXVsdCBjYXNlLgorCQkgKiBPbGQgY29kZSB1c2VkIHRvCisJCSAq IGlmICgoc2NwLT5mZmxhZ3MgJiBPX0FDQ01PREUpID09IEZSRUFEKSB7CisJCSAqCXJldCA9IEVJ TzsKKwkJICoJYnJlYWs7CisJCSAqIH0KKwkJICogVGhlbiBwYXNzIG9uIHRoZSBpb2N0bCB0byBk ZXZpY2UgMAorCQkgKi8KKwkJU0VRX0RFQlVHKDIscHJpbnRmKCJzZXFfaW9jdGw6IHVuc3VwcG9y dGVkIElPQ1RMICVsZC5cbiIsIGNtZCkpOworCQlyZXQgPSBFSU5WQUw7CisJCWJyZWFrOworCX0K KworCXJldHVybiByZXQ7Cit9CisKK2ludAorc2VxX3BvbGwoc3RydWN0IGNkZXYgKmlfZGV2LCBp bnQgZXZlbnRzLCBzdHJ1Y3QgdGhyZWFkICp0ZCkKK3sKKwlpbnQgcmV0LCBsaW07CisJc3RydWN0 IHNlcV9zb2Z0YyAqc2NwID0gaV9kZXYtPnNpX2RydjE7CisKKwlTRVFfREVCVUcoMywgcHJpbnRm KCJzZXFfcG9sbDogdW5pdCAlZC5cbiIsIHNjcC0+dW5pdCkpOworCXByaW50Zigic2VxX3BvbGw6 IHVuaXQgJWQuXG4iLCBzY3AtPnVuaXQpOworCisJbXR4X2xvY2soJnNjcC0+c2VxX2xvY2spOwor CisJcmV0ID0gMDsKKworCS8qIExvb2sgdXAgdGhlIGFwcm9wcmlhdGUgcXVldWUgYW5kIHNlbGVj dCBpdC4gKi8KKwlpZiAoKGV2ZW50cyAmIChQT0xMT1VUIHwgUE9MTFdSTk9STSkpICE9IDApIHsK KwkgICAgLyogU3RhcnQgcGxheWluZy4gKi8KKwkgICAgc2NwLT5wbGF5aW5nID0gMTsKKwkgICAg Y3ZfYnJvYWRjYXN0KCZzY3AtPnN0YXRlX2N2KTsKKwkgICAgY3ZfYnJvYWRjYXN0KCZzY3AtPm91 dF9jdik7CisKKwkgICAgbGltID0gc2NwLT5vdXRfd2F0ZXI7CisKKwkgICAgaWYgKE1JRElRX0FW QUlMKHNjcC0+b3V0X3EpIDwgbGltKQorCQkvKiBObyBlbm91Z2ggc3BhY2UsIHJlY29yZCBzZWxl Y3QuICovCisJCXNlbHJlY29yZCh0ZCwgJnNjcC0+b3V0X3NlbCk7CisJICAgIGVsc2UKKwkJLyog V2UgY2FuIHdyaXRlIG5vdy4gKi8KKwkJcmV0IHw9IGV2ZW50cyAmIChQT0xMT1VUIHwgUE9MTFdS Tk9STSk7CisJfQorCisJaWYgKChldmVudHMgJiAoUE9MTElOIHwgUE9MTFJETk9STSkpICE9IDAp IHsKKwkgICAgLyogVE9ETzogU3RhcnQgcmVjb3JkaW5nLiAqLworCisJICAgIC8qIEZpbmQgb3V0 IHRoZSBib3VuZGFyeS4gKi8KKwkgICAgbGltID0gMTsKKwkgICAgaWYgKE1JRElRX0xFTihzY3At PmluX3EpIDwgbGltKQorCQkvKiBObyBkYXRhIHJlYWR5LCByZWNvcmQgc2VsZWN0LiAqLworCQlz ZWxyZWNvcmQodGQsICZzY3AtPmluX3NlbCk7CisJICAgIGVsc2UKKwkJLyogV2UgY2FuIHJlYWQg bm93LiAqLworCQlyZXQgfD0gZXZlbnRzICYgKFBPTExJTiB8IFBPTExSRE5PUk0pOworCX0KKwor CW10eF91bmxvY2soJnNjcC0+c2VxX2xvY2spOworCisJcmV0dXJuIChyZXQpOworfQorI2lmIDAK K3N0YXRpYyB2b2lkCitzZWluX3F0cih2b2lkICpwLCB2b2lkIC8qIG1pZGlkZXZfaW5mbyAqLyAq bWQpCit7CisJc3RydWN0IHNlcV9zb2Z0YyAqc2NwOworCisJc2NwID0gKHN0cnVjdCBzZXFfc29m dGMgKilwOworCisJbXR4X2xvY2soJnNjcC0+c2VxX2xvY2spOworCisJLyogUmVzdGFydCBwbGF5 aW5nIGlmIHdlIGhhdmUgdGhlIGRhdGEgdG8gb3V0cHV0LiAqLworCWlmIChzY3AtPnF1ZXVlb3V0 X3BlbmRpbmcpCisJCXNlcV9jYWxsYmFjayhzY3AsIFNFUV9DQl9TVEFSVCB8IFNFUV9DQl9XUik7 CisJLyogQ2hlY2sgdGhlIG1pZGkgZGV2aWNlIGlmIHdlIGFyZSByZWFkaW5nLiAqLworCWlmICgo c2NwLT5mbGFncyAmIFNFUV9GX1JFQURJTkcpICE9IDApCisJCXNlcV9taWRpaW5wdXQoc2NwLCBt ZCk7CisKKwltdHhfdW5sb2NrKCZzY3AtPnNlcV9sb2NrKTsKK30KKyNlbmRpZgorLyoKKyAqIHNl cV9jb252ZXJ0b2xkCisgKiBXYXMgdGhlIG9sZCBwbGF5ZXZlbnQuICBVc2UgdGhpcyB0byBjb252 ZXJ0IGFuZCBvbGQKKyAqIHN0eWxlIC9kZXYvc2VxdWVuY2VyIGV2ZW50IHRvIGEgL2Rldi9tdXNp YyBldmVudCAKKyAqLworc3RhdGljIGludAorc2VxX2NvbnZlcnRvbGQodV9jaGFyICpldmVudCwg dV9jaGFyICpvdXQpCit7CisJaW50IHVzZWQ7CisJdV9jaGFyIGRldiwgY2huLCBub3RlLCB2ZWw7 CisKKwlvdXRbMF0gPSBvdXRbMV0gPSBvdXRbMl0gPSBvdXRbM10gPSBvdXRbNF0gID0gb3V0WzVd ICA9IG91dFs2XSAgPSBvdXRbN10gICA9IDA7CisKKwlkZXYgPSAwOworCWNobiA9IGV2ZW50WzFd OworCW5vdGUgPSBldmVudFsyXTsKKwl2ZWwgPSBldmVudFszXTsKKworCXVzZWQgPSAwOworCity ZXN0YXJ0OgorCS8qCisJICogVE9ETzogRGVidWcgc3RhdGVtZW50CisJICovCisJc3dpdGNoKGV2 ZW50WzBdKSB7CisJICAgIGNhc2UgRVZfVElNSU5HOgorCSAgICBjYXNlIEVWX0NITl9WT0lDRToK KwkgICAgY2FzZSBFVl9DSE5fQ09NTU9OOgorY2FzZSBFVl9TWVNFWDoKK2Nhc2UgRVZfU0VRX0xP Q0FMOgorCQlvdXRbMF0gPSBldmVudFswXTsKKwkJb3V0WzFdID0gZXZlbnRbMV07CisJCW91dFsy XSA9IGV2ZW50WzJdOworCQlvdXRbM10gPSBldmVudFszXTsKKwkJb3V0WzRdID0gZXZlbnRbNF07 CisJCW91dFs1XSA9IGV2ZW50WzVdOworCQlvdXRbNl0gPSBldmVudFs2XTsKKwkJb3V0WzddID0g ZXZlbnRbN107CisJCXVzZWQgKz0gODsKKwkJYnJlYWs7CisJICAgIGNhc2UgU0VRX05PVEVPRkY6 CisJCW91dFswXSA9IEVWX0NITl9WT0lDRTsKKwkJb3V0WzFdID0gZGV2OworCQlvdXRbMl0gPSBN SURJX05PVEVPRkY7CisJCW91dFszXSA9IGNobjsKKwkJb3V0WzRdID0gbm90ZTsKKwkJb3V0WzVd ID0gMjU1OworCXVzZWQgKz0gNDsKKwkJYnJlYWs7CisKKwkgICAgY2FzZSBTRVFfTk9URU9OOgor CQlvdXRbMF0gPSBFVl9DSE5fVk9JQ0U7CisJCW91dFsxXSA9IGRldjsKKwkJb3V0WzJdID0gTUlE SV9OT1RFT047CisJCW91dFszXSA9IGNobjsKKwkJb3V0WzRdID0gbm90ZTsKKwkJb3V0WzVdID0g dmVsOworCXVzZWQgKz0gNDsKKwkJYnJlYWs7CisKKwkJLyoKKwkJICogd2FpdCBkZWxheSA9IChl dmVudFsyXSA8PCAxNikgKyAoZXZlbnRbM10gPDwgOCkgKyBldmVudFs0XQorCQkgKi8KKworCSAg ICBjYXNlIFNFUV9QR01DSEFOR0U6CisJCW91dFswXSA9IEVWX0NITl9DT01NT047CisJCW91dFsx XSA9IGRldjsKKwkJb3V0WzJdID0gTUlESV9QR01fQ0hBTkdFOworCQlvdXRbM10gPSBjaG47CisJ CW91dFs0XSA9IG5vdGU7CisJCW91dFs1XSA9IHZlbDsKKwl1c2VkICs9IDQ7CisJCWJyZWFrOwor LyoKKwkJb3V0WzBdID0gRVZfVElNSU5HOworCQlvdXRbMV0gPSBkZXY7CisJCW91dFsyXSA9IE1J RElfUEdNX0NIQU5HRTsKKwkJb3V0WzNdID0gY2huOworCQlvdXRbNF0gPSBub3RlOworCQlvdXRb NV0gPSB2ZWw7CisJCVNFUV9ERUJVRyg0LHByaW50Zigic2VxX3BsYXlldmVudDogc3luY3RpbWVy XG4iKSk7CisJCWJyZWFrOworKi8KKworCSAgICBjYXNlIFNFUV9NSURJUFVUQzoKKwkJU0VRX0RF QlVHKDQscHJpbnRmKCJzZXFfcGxheWV2ZW50OiBwdXQgZGF0YSAweCUwMngsIHVuaXQgJWQuXG4i LAorCQkJICAgIGV2ZW50WzFdLCBldmVudFsyXSkpOworCQkvKgorCQkgKiBQYXNzIHRocm91Z2gg dG8gdGhlIG1pZGkgZGV2aWNlLgorCQkgKiBkZXZpY2UgPSBldmVudFsyXQorCQkgKiBkYXRhID0g ZXZlbnRbMV0KKwkJICovCisJCW91dFswXSA9IFNFUV9NSURJUFVUQzsKKwkJb3V0WzFdID0gZGV2 OworCQlvdXRbMl0gPSBjaG47CisJdXNlZCArPSA0OworCQlicmVhazsKKyNpZiBub3R5ZXQKKwkg ICAgY2FzZSBTRVFfRUNITzoKKwkJLyoKKwkJICogVGhpcyBpc24ndCBoYW5kbGVkIGhlcmUgeWV0 IGJlY2F1c2UgSSBkb24ndCBrbm93IGlmIEkgY2FuCisJCSAqIGp1c3QgdXNlIGZvdXIgYnl0ZXMg ZXZlbnRzLiAgVGhlcmUgbWlnaHQgYmUgY29uc2VxdWVuY2VzIAorCQkgKiBpbiB0aGUgX3JlYWQg cm91dGluZworCQkgKi8KKwkJaWYgKHNlcV9jb3B5dG9pbnB1dChzY3AsIGV2ZW50LCA0KSA9PSBF QUdBSU4pIHsKKwkJICAgIHJldCA9IFFVRVVFRlVMTDsKKwkJICAgIGJyZWFrOworCQl9CisJCXJl dCA9IE1PUkU7CisJCWJyZWFrOworI2VuZGlmCisJICAgIGNhc2UgU0VRX0VYVEVOREVEOgorCQlz d2l0Y2ggKGV2ZW50WzFdKSB7CisJCSAgICBjYXNlIFNFUV9OT1RFT0ZGOgorCQkgICAgY2FzZSBT RVFfTk9URU9OOgorCQkgICAgY2FzZSBTRVFfUEdNQ0hBTkdFOgorCQkJZXZlbnQrKzsKKwkJCXVz ZWQgPSA0OworCQkJZ290byByZXN0YXJ0OworCQkJYnJlYWs7CisJCSAgICBjYXNlIFNFUV9BRlRF UlRPVUNIOgorCQkJLyoKKwkJCSAqIFNZTlRIX0FGVEVSVE9VQ0gobWQsIGV2ZW50WzNdLCBldmVu dFs0XSkKKwkJCSAqLworCQkgICAgY2FzZSBTRVFfQkFMQU5DRToKKwkJCS8qCisJCQkgKiBTWU5U SF9QQU5OSU5HKG1kLCBldmVudFszXSwgKGNoYXIpZXZlbnRbNF0pCisJCQkgKi8KKwkJICAgIGNh c2UgU0VRX0NPTlRST0xMRVI6CisJCQkvKgorCQkJICogU1lOVEhfQ09OVFJPTExFUihtZCwgZXZl bnRbM10sIGV2ZW50WzRdLCAqKHNob3J0ICopJmV2ZW50WzVdKQorCQkJICovCisJCSAgICBjYXNl IFNFUV9WT0xNT0RFOgorCQkJLyoKKwkJCSAqIFNZTlRIX1ZPTFVNRU1FVEhPRChtZCwgZXZlbnRb M10pIAorCQkJICovCisJCSAgICBkZWZhdWx0OgorCQkJU0VRX0RFQlVHKDIscHJpbnRmKCJzZXFf Y29udmVydG9sZDogU0VRX0VYVEVOREVEIHR5cGUgJWQiCisJCQkJIm5vdCBoYW5kbGVkXG4iLCBl dmVudFsxXSkpOworCQkJYnJlYWs7CisJCX0KKwkJYnJlYWs7CisJICAgIGNhc2UgU0VRX1dBSVQ6 CisJCW91dFswXSA9IEVWX1RJTUlORzsKKwkJb3V0WzFdID0gVE1SX1dBSVRfUkVMOworCQlvdXRb NF0gPSBldmVudFsyXTsKKwkJb3V0WzVdID0gZXZlbnRbM107CisJCW91dFs2XSA9IGV2ZW50WzRd OworCisJCVNFUV9ERUJVRyg1LHByaW50ZigiU0VRX1dBSVQgJWQiLCBldmVudFsyXSArIChldmVu dFszXSA8PCA4KSArIChldmVudFs0XSA8PCAyNCkpKTsKKworCQl1c2VkKz0gNDsKKwkJYnJlYWs7 CisKKwkgICAgY2FzZSBTRVFfRUNITzoKKwkgICAgY2FzZSBTRVFfU1lOQ1RJTUVSOgorCSAgICBj YXNlIFNFUV9QUklWQVRFOgorCSAgICBkZWZhdWx0OgorCQlTRVFfREVCVUcoMixwcmludGYoInNl cV9jb252ZXJ0b2xkOiBldmVudCB0eXBlICVkIG5vdCBoYW5kbGVkICVkICVkICVkXG4iLCBldmVu dFswXSwgZXZlbnRbMV0sIGV2ZW50WzJdLCBldmVudFszXSkpOworCQlicmVhazsKKwl9CisJcmV0 dXJuIHVzZWQ7Cit9CisKKy8qCisgKiBXcml0dGluZyB0byB0aGUgc2VxdWVuY2VyIGJ1ZmZlciBu ZXZlciBibG9ja3MgYW5kIGRyb3BzCisgKiBpbnB1dCB3aGljaCBjYW5ub3QgYmUgcXVldWVkCisg Ki8KK3ZvaWQKK3NlcV9jb3B5dG9pbnB1dChzdHJ1Y3Qgc2VxX3NvZnRjICpzY3AsIHVfY2hhciAq ZXZlbnQsIGludCBsZW4pCit7CisKKwltdHhfYXNzZXJ0KCZzY3AtPnNlcV9sb2NrLCBNQV9PV05F RCk7CisKKwlpZiAoTUlESVFfQVZBSUwoc2NwLT5pbl9xKSA8IGxlbikgeworCSAgICAvKgorCSAg ICAgKiBFTk9ST09NPyAgRUlOUFVURFJPUFBFRD8gRVRPVUdITFVDSz8KKwkgICAgICovCisJICBT RVFfREVCVUcoMixwcmludGYoInNlcV9jb3B5dG9pbnB1dDogcXVldWUgZnVsbFxuIikpOworCX0g ZWxzZSB7CisJICAgIE1JRElRX0VOUShzY3AtPmluX3EsIGV2ZW50LCBsZW4pOworCSAgICBzZWx3 YWtldXAoJnNjcC0+aW5fc2VsKTsKKwkgICAgY3ZfYnJvYWRjYXN0KCZzY3AtPmluX2N2KTsKKwl9 CisKK30KKworc3RhdGljIGludAorc2VxX2NobnZvaWNlKHN0cnVjdCBzZXFfc29mdGMgKnNjcCwg a29ial90IG1kLCB1X2NoYXIgKmV2ZW50KQoreworCWludCByZXQsIHZvaWNlOworCXVfY2hhciBj bWQsIGNobiwgbm90ZSwgcGFybTsKKworCXJldCA9IDA7CisJY21kID0gZXZlbnRbMl07CisJY2hu ID0gZXZlbnRbM107CisJbm90ZSA9IGV2ZW50WzRdOworCXBhcm0gPSBldmVudFs1XTsKKworCW10 eF9hc3NlcnQoJnNjcC0+c2VxX2xvY2ssIE1BX09XTkVEKTsKKworCVNFUV9ERUJVRyg1LHByaW50 Zigic2VxX2NobnZvaWNlOiB1bml0ICVkLCBkZXYgJWQsIGNtZCAlcywiCisJCSAgICIgY2huICVk LCBub3RlICVkLCBwYXJtICVkLlxuIiwgc2NwLT51bml0LCBldmVudFsxXSwgCisJCSAgIG1pZGlf Y21kbmFtZShjbWQsIGNtZHRhYl9zZXFjdiksIGNobiwgbm90ZSwgcGFybSkpOworCisJdm9pY2Ug PSBTWU5USF9BTExPQyhtZCwgY2huLCBub3RlKTsKKworCW10eF91bmxvY2soJnNjcC0+c2VxX2xv Y2spOworCisJc3dpdGNoIChjbWQpIHsKKwkgICAgY2FzZSBNSURJX05PVEVPTjoKKwkJaWYgKG5v dGUgPCAxMjggfHwgbm90ZSA9PSAyNTUpIHsKKyNpZiAwCisJCSAgICBpZiAoc2NwLT5tdXNpYyAm JiBjaG4gPT0gOSkgeworCQkJLyoKKwkJCSAqIFRoaXMgY2hhbm5lbCBpcyBhIHBlcmN1c3Npb24u IFRoZSBub3RlIG51bWJlciBpcyB0aGUKKwkJCSAqIHBhdGNoIG51bWJlci4gCisJCQkgKi8KKwkJ CS8qCisJCQltdHhfdW5sb2NrKCZzY3AtPnNlcV9sb2NrKTsKKwkJCWlmIChTWU5USF9TRVRJTlNU UihtZCwgdm9pY2UsIDEyOCArIG5vdGUpID09IEVBR0FJTikgeworCQkJICAgIG10eF9sb2NrKCZz Y3AtPnNlcV9sb2NrKTsKKwkJCSAgICByZXR1cm4gKFFVRVVFRlVMTCk7CisJCQl9CisJCQltdHhf bG9jaygmc2NwLT5zZXFfbG9jayk7CisJCQkqLworCQkJbm90ZSA9IDYwOyAvKiBNaWRkbGUgQy4g Ki8KKwkJICAgIH0KKyNlbmRpZgorCQkgICAgaWYgKHNjcC0+bXVzaWMpIHsKKwkJCS8qCisJCQlt dHhfdW5sb2NrKCZzY3AtPnNlcV9sb2NrKTsKKwkJCWlmIChTWU5USF9TRVRVUFZPSUNFKG1kLCB2 b2ljZSwgY2huKSA9PSBFQUdBSU4pIHsKKwkJCSAgICBtdHhfbG9jaygmc2NwLT5zZXFfbG9jayk7 CisJCQkgICAgcmV0dXJuIChRVUVVRUZVTEwpOworCQkJfQorCQkJbXR4X2xvY2soJnNjcC0+c2Vx X2xvY2spOworCQkJKi8KKwkJICAgIH0KKwkJICAgIFNZTlRIX1NUQVJUTk9URShtZCwgdm9pY2Us IG5vdGUsIHBhcm0pOworCQl9CisJCWJyZWFrOworCWNhc2UgTUlESV9OT1RFT0ZGOgorCQlTWU5U SF9LSUxMTk9URShtZCwgdm9pY2UsIG5vdGUsIHBhcm0pOworCQlicmVhazsKKwljYXNlIE1JRElf S0VZX1BSRVNTVVJFOgorCQlTWU5USF9BRlRFUlRPVUNIKG1kLCB2b2ljZSwgcGFybSk7CisJCWJy ZWFrOworCWRlZmF1bHQ6CisJCXJldCA9IDE7CisJCVNFUV9ERUJVRygyLHByaW50Zigic2VxX2No bnZvaWNlIGV2ZW50IHR5cGUgJWQgbm90IGhhbmRsZWRcbiIsIGV2ZW50WzFdKSk7CisJCWJyZWFr OworCX0KKworCW10eF9sb2NrKCZzY3AtPnNlcV9sb2NrKTsKKwlyZXR1cm4gcmV0OworfQorCitz dGF0aWMgaW50CitzZXFfY2huY29tbW9uKHN0cnVjdCBzZXFfc29mdGMgKnNjcCwga29ial90IG1k LCB1X2NoYXIgKmV2ZW50KQoreworCWludCByZXQ7CisJdV9zaG9ydCB3MTQ7CisJdV9jaGFyIGNt ZCwgY2huLCBwMTsKKworCXJldCA9IDA7CisJY21kID0gZXZlbnRbMl07CisJY2huID0gZXZlbnRb M107CisJcDEgPSBldmVudFs0XTsKKwl3MTQgPSAqKHVfc2hvcnQgKikmZXZlbnRbNl07CisKKwlT RVFfREVCVUcoNSxwcmludGYoInNlcV9jaG5jb21tb246IHVuaXQgJWQsIGRldiAlZCwgY21kICVz LCBjaG4gJWQsIgorCQkgICAgIiBwMSAlZCwgdzE0ICVkLlxuIiwgc2NwLT51bml0LCBldmVudFsx XSwKKwkJICAgIG1pZGlfY21kbmFtZShjbWQsIGNtZHRhYl9zZXFjY21uKSwgY2huLCBwMSwgdzE0 KSk7CisJbXR4X3VubG9jaygmc2NwLT5zZXFfbG9jayk7CisJc3dpdGNoIChjbWQpIHsKKwkgICAg Y2FzZSBNSURJX1BHTV9DSEFOR0U6CisJCSAgICBTRVFfREVCVUcoNCxwcmludGYoInNlcV9jaG5j b21tb24gcGdtY2huIGNobiAlZCBwZyAlZFxuIiwKKwkJCQljaG4sIHAxKSk7CisJCSAgICBTWU5U SF9TRVRJTlNUUihtZCwgY2huLCBwMSk7CisJCWJyZWFrOworCSAgICBjYXNlIE1JRElfQ1RMX0NI QU5HRToKKwkJU0VRX0RFQlVHKDQscHJpbnRmKCJzZXFfY2huY29tbW9uIGN0bGNoIGNobiAlZCBw ZyAlZCAlZFxuIiwKKwkJCSAgICBjaG4sIHAxLCB3MTQpKTsKKwkJU1lOVEhfQ09OVFJPTExFUiht ZCwgY2huLCBwMSwgdzE0KTsKKwkJYnJlYWs7CisJICAgIGNhc2UgTUlESV9QSVRDSF9CRU5EOgor CQlpZiAoc2NwLT5tdXNpYykgeworCQkgICAgLyoKKwkJICAgICAqIFRPRE86IE1JRElfUElUQ0hf QkVORAorCQkgICAgICovCisjaWYgMAorCQkgICAgbXR4X2xvY2soJm1kLT5zeW50aC52Y19tdHgp OworCQkgICAgbWQtPnN5bnRoLmNobl9pbmZvW2Nobl0uYmVuZGVyX3ZhbHVlID0gdzE0OworCQkg ICAgaWYgKG1kLT5taWRpdW5pdCA+PSAwKSB7CisJCQkvKiBIYW5kbGUgYWxsIG9mIHRoZSBub3Rl cyBwbGF5aW5nIG9uIHRoaXMgY2hhbm5lbC4gKi8KKwkJCWtleSA9ICgoaW50KWNobiA8PCA4KTsK KwkJCWZvciAoaSA9IDAgOyBpIDwgbWQtPnN5bnRoLmFsbG9jLm1heF92b2ljZSA7IGkrKykKKwkJ CSAgICBpZiAoKG1kLT5zeW50aC5hbGxvYy5tYXBbaV0gJiAweGZmMDApID09IGtleSkgeworCQkJ CW10eF91bmxvY2soJm1kLT5zeW50aC52Y19tdHgpOworCQkJCW10eF91bmxvY2soJnNjcC0+c2Vx X2xvY2spOworCQkJCWlmIChtZC0+c3ludGguYmVuZGVyKG1kLCBpLCB3MTQpID09IEVBR0FJTikg eworCQkJCSAgICBtdHhfbG9jaygmc2NwLT5zZXFfbG9jayk7CisJCQkJICAgIHJldHVybiAoUVVF VUVGVUxMKTsKKwkJCQl9CisJCQkJbXR4X2xvY2soJnNjcC0+c2VxX2xvY2spOworCQkJICAgIH0K KwkJICAgIH0gZWxzZSB7CisJCQltdHhfdW5sb2NrKCZtZC0+c3ludGgudmNfbXR4KTsKKwkJCW10 eF91bmxvY2soJnNjcC0+c2VxX2xvY2spOworCQkJaWYgKG1kLT5zeW50aC5iZW5kZXIobWQsIGNo biwgdzE0KSA9PSBFQUdBSU4pIHsKKwkJCSAgICBtdHhfbG9jaygmc2NwLT5zZXFfbG9jayk7CisJ CQkgICAgcmV0dXJuIChRVUVVRUZVTEwpOworCQkJfQorCQkJbXR4X2xvY2soJnNjcC0+c2VxX2xv Y2spOworCQkgICAgfQorI2VuZGlmCisJCX0gZWxzZQorCQkgICAgU1lOVEhfQkVOREVSKG1kLCBj aG4sIHcxNCk7CisJCWJyZWFrOworCSAgICBkZWZhdWx0OgorCQlyZXQgPSAxOworCQlTRVFfREVC VUcoMixwcmludGYoInNlcV9jaG5jb21tb24gZXZlbnQgdHlwZSAlZCBub3QgaGFuZGxlZC5cbiIs IGV2ZW50WzFdKSk7CisJCWJyZWFrOworCisJfQorCW10eF9sb2NrKCZzY3AtPnNlcV9sb2NrKTsK KwlyZXR1cm4gcmV0OworfQorCitzdGF0aWMgaW50CitzZXFfdGltaW5nKHN0cnVjdCBzZXFfc29m dGMgKnNjcCwgdV9jaGFyICpldmVudCkKK3sKKwlpbnQgcGFyYW07CisJaW50IHJldDsKKworCXJl dCA9IDA7CisJcGFyYW0gPSBldmVudFs0XSArIChldmVudFs1XSA8PCA4KSArCisJICAgIChldmVu dFs2XSA8PCAxNikgKyAoZXZlbnRbN10gPDwgMjQpOworCisJU0VRX0RFQlVHKDUscHJpbnRmKCJz ZXFfdGltaW5nOiB1bml0ICVkLCBjbWQgJWQsIHBhcmFtICVkLlxuIiwKKwkJICAgIHNjcC0+dW5p dCwgZXZlbnRbMV0sIHBhcmFtKSk7CisJc3dpdGNoIChldmVudFsxXSkgeworCWNhc2UgVE1SX1dB SVRfUkVMOgorCSAgICB0aW1lcl93YWl0KHNjcCwgcGFyYW0sIDApOworCQlicmVhazsKKwljYXNl IFRNUl9XQUlUX0FCUzoKKwkgICAgdGltZXJfd2FpdChzY3AsIHBhcmFtLCAxKTsKKwkJYnJlYWs7 CisJY2FzZSBUTVJfU1RBUlQ6CisJCXRpbWVyX3N0YXJ0KHNjcCk7CisJCWN2X2Jyb2FkY2FzdCgm c2NwLT5yZXNldF9jdik7CisJCWJyZWFrOworCWNhc2UgVE1SX1NUT1A6CisJCXRpbWVyX3N0b3Ao c2NwKTsKKwkJLyoKKwkJICogVGhlIGZvbGxvd2luZyBjdl9icm9hZGNhc3QgaXNuJ3QgbmVlZGVk IHNpbmNlIHdlIG9ubHkKKwkJICogd2FpdCBmb3IgMC0+MSB0cmFuc2l0aW9ucy4gIEl0IHByb2Jh Ymx5IHdvbid0IGh1cnQKKwkJICovCisJCWN2X2Jyb2FkY2FzdCgmc2NwLT5yZXNldF9jdik7CisJ CWJyZWFrOworCWNhc2UgVE1SX0NPTlRJTlVFOgorCQl0aW1lcl9jb250aW51ZShzY3ApOworCQlj dl9icm9hZGNhc3QoJnNjcC0+cmVzZXRfY3YpOworCQlicmVhazsKKwljYXNlIFRNUl9URU1QTzoK KwkJaWYgKHBhcmFtIDwgOCkKKwkJICAgIHBhcmFtID0gODsKKwkJaWYgKHBhcmFtID4gMzYwKQor CQkgICAgcGFyYW0gPSAzNjA7CisJCVNFUV9ERUJVRyg0LHByaW50ZigiVGltZXIgc2V0IHRlbXBv ICVkXG4iLCBwYXJhbSkpOworCQl0aW1lcl9zZXR2YWxzKHNjcCwgcGFyYW0sIHNjcC0+dGltZXJi YXNlKTsKKwkJYnJlYWs7CisJY2FzZSBUTVJfVElNRVJCQVNFOgorCQlpZiAocGFyYW0gPCAxKQor CQkgICAgcGFyYW0gPSAxOworCQlpZiAocGFyYW0gPiAxMDAwKQorCQkgICAgcGFyYW0gPSAxMDAw OworCQlTRVFfREVCVUcoNCxwcmludGYoIlRpbWVyIHNldCB0aW1lcmJhc2UgJWRcbiIsIHBhcmFt KSk7CisJCXRpbWVyX3NldHZhbHMoc2NwLCBzY3AtPnRlbXBvLCBwYXJhbSk7CisJCWJyZWFrOwor CWNhc2UgVE1SX0VDSE86CisJCS8qCisJCSAqIFRPRE86IENvbnNpZGVyIG1ha2luZyA0LWJ5dGUg ZXZlbnRzIGZvciAvZGV2L3NlcXVlbmNlcgorCQkgKiBQUk86IE1heWJlIG5lZWRlZCBieSBsZWdh Y3kgYXBwcworCQkgKiBDT046IHNvdW5kY2FyZC5oIGhhcyBiZWVuIHdhcm5pbmcgZm9yIGEgd2hp bGUgbWFueSB5ZWFycworCQkgKiB0byBleHBlY3QgOCBieXRlIGV2ZW50cy4KKwkJICovCisjaWYg MAorCQlpZiAoc2NwLT5tdXNpYykKKwkJCXNlcV9jb3B5dG9pbnB1dChzY3AsIGV2ZW50LCA4KTsK KwkJZWxzZSB7CisJCQlwYXJhbSA9IChwYXJhbSA8PCA4IHwgU0VRX0VDSE8pOworCQkJc2VxX2Nv cHl0b2lucHV0KHNjcCwgKHVfY2hhciAqKSZwYXJhbSwgNCk7CisJCX0KKyNlbHNlCisJCXNlcV9j b3B5dG9pbnB1dChzY3AsIGV2ZW50LCA4KTsKKyNlbmRpZgorCQlicmVhazsKKwkgICAgZGVmYXVs dDoKKwkJU0VRX0RFQlVHKDIscHJpbnRmKCJzZXFfdGltaW5nIGV2ZW50IHR5cGUgJWQgbm90IGhh bmRsZWQuXG4iLCBldmVudFsxXSkpOworCQlyZXQgPSAxOworCQlicmVhazsKKwl9CisJcmV0dXJu IHJldDsKK30KKworc3RhdGljIGludAorc2VxX2xvY2FsKHN0cnVjdCBzZXFfc29mdGMgKnNjcCwg dV9jaGFyICpldmVudCkKK3sKKwlpbnQgcmV0OworCisJcmV0ID0gMDsKKwltdHhfYXNzZXJ0KCZz Y3AtPnNlcV9sb2NrLCBNQV9PV05FRCk7CisKKwlTRVFfREVCVUcoNSxwcmludGYoInNlcV9sb2Nh bDogdW5pdCAlZCwgY21kICVkXG4iLCBzY3AtPnVuaXQsIGV2ZW50WzFdKSk7CisJc3dpdGNoIChl dmVudFsxXSkgeworCSAgICBkZWZhdWx0OgorCQlwcmludGYoInNlcV9sb2NhbCBldmVudCB0eXBl ICVkIG5vdCBoYW5kbGVkXG4iLCBldmVudFsxXSk7CisJCXJldCA9IDE7CisJCWJyZWFrOworCX0K KwlyZXR1cm4gcmV0OworfQorCitzdGF0aWMgaW50CitzZXFfc3lzZXgoc3RydWN0IHNlcV9zb2Z0 YyAqc2NwLCBrb2JqX3QgbWQsIHVfY2hhciAqZXZlbnQpCit7CisJaW50IGksIGw7CisKKwltdHhf YXNzZXJ0KCZzY3AtPnNlcV9sb2NrLCBNQV9PV05FRCk7CisJU0VRX0RFQlVHKDUscHJpbnRmKCJz ZXFfc3lzZXg6IHVuaXQgJWQgZGV2aWNlICVkXG4iLCBzY3AtPnVuaXQsIGV2ZW50WzFdKSk7CisJ bCA9IDA7CisJZm9yIChpID0gMCA7IGkgPCA2ICYmIGV2ZW50W2kgKyAyXSAhPSAweGZmIDsgaSsr KQorCQlsID0gaSArIDE7CisJaWYgKGwgPiAwKSB7CisJCW10eF91bmxvY2soJnNjcC0+c2VxX2xv Y2spOworCQlpZiAoU1lOVEhfU0VORFNZU0VYKG1kLCAmZXZlbnRbMl0sIGwpID09IEVBR0FJTikg eworCQkJbXR4X2xvY2soJnNjcC0+c2VxX2xvY2spOworCQkJcmV0dXJuIDE7CisJCX0KKwkJbXR4 X2xvY2soJnNjcC0+c2VxX2xvY2spOworCX0KKwlyZXR1cm4gMDsKK30KKworLyoKKyAqIFJlc2V0 IG5vIGxvbmdlciBjbG9zZXMgdGhlIHJhdyBkZXZpY2VzIG5vciBzZXFfc3luYydzCisgKiBDYWxs ZXJzIGFyZSBJT0NUTCBhbmQgc2VxX2Nsb3NlCisgKi8KK3N0YXRpYyB2b2lkCitzZXFfcmVzZXQo c3RydWN0IHNlcV9zb2Z0YyAqc2NwKQoreworCWludCBjaG4sICBpOworCWtvYmpfdCBtOworCisJ bXR4X2Fzc2VydCgmc2NwLT5zZXFfbG9jaywgTUFfT1dORUQpOworCisJU0VRX0RFQlVHKDUscHJp bnRmKCJzZXFfcmVzZXQ6IHVuaXQgJWQuXG4iLCBzY3AtPnVuaXQpKTsKKworCS8qCisJICogU3Rv cCByZWFkaW5nIGFuZCB3cml0aW5nLgorCSAqLworCisJLyogc2NwLT5yZWNvcmRpbmcgPSAwOyAq LworCXNjcC0+cGxheWluZyA9IDA7CisJY3ZfYnJvYWRjYXN0KCZzY3AtPnN0YXRlX2N2KTsKKwlj dl9icm9hZGNhc3QoJnNjcC0+b3V0X2N2KTsKKwljdl9icm9hZGNhc3QoJnNjcC0+cmVzZXRfY3Yp OworCisJLyoKKwkgKiBGb3Igbm93LCBkb24ndCByZXNldCB0aGUgdGltZXJzLgorCSAqLworCU1J RElRX0NMRUFSKHNjcC0+aW5fcSk7CisJTUlESVFfQ0xFQVIoc2NwLT5vdXRfcSk7CisKKwlmb3Ig KGkgPSAwOyBpIDwgc2NwLT5taWRpX251bWJlcjsgaSsrKSB7CisJICAgIG0gPSBzY3AtPm1pZGlz W2ldOworCSAgICBtdHhfdW5sb2NrKCZzY3AtPnNlcV9sb2NrKTsKKwkgICAgU1lOVEhfUkVTRVQo bSk7CisJICAgIGZvciAoY2huID0gMCA7IGNobiA8IDE2IDsgY2huKyspIHsKKwkJU1lOVEhfQ09O VFJPTExFUihtLCBjaG4sIDEyMywgMCkgOworCQlTWU5USF9DT05UUk9MTEVSKG0sIGNobiwgMTIx LCAwKTsKKwkJU1lOVEhfQkVOREVSKG0sIGNobiwgMSA8PCAxMyk7CisJICAgIH0KKwkgICAgbXR4 X2xvY2soJnNjcC0+c2VxX2xvY2spOworCX0KK30KKworLyoKKyAqIHNlcV9zeW5jCisgKiAqcmVh bGx5KiBmbHVzaCB0aGUgb3V0cHV0IHF1ZXVlCisgKiBmbHVzaCB0aGUgZXZlbnQgcXVldWUsIHRo ZW4gZmx1c2ggdGhlIHN5bnRoc2lzZXJzLgorICogQ2FsbGVycyBhcmUgSU9DVEwgYW5kIGNsb3Nl CisgKi8KKworI2RlZmluZSBTRVFfU1lOQ19USU1FT1VUIDgKK3N0YXRpYyBpbnQKK3NlcV9zeW5j KHN0cnVjdCBzZXFfc29mdGMgKnNjcCkKK3sKKwlpbnQgaSwgcmwsIHN5bmNbMTZdLCBkb25lOwor CisJbXR4X2Fzc2VydCgmc2NwLT5zZXFfbG9jaywgTUFfT1dORUQpOworCisJU0VRX0RFQlVHKDQs cHJpbnRmKCJzZXFfc3luYzogdW5pdCAlZC5cbiIsIHNjcC0+dW5pdCkpOworCisJLyoKKwkgKiBX YWl0IHVudGlsIG91dHB1dCBxdWV1ZSBpcyBlbXB0eS4gIENoZWNrIGV2ZXJ5IHNvIG9mdGVuIHRv IHNlZSBpZgorCSAqIHRoZSBxdWV1ZSBpcyBtb3ZpbmcgYWxvbmcuICBJZiBpdCBpc24ndCBqdXN0 IGFib3J0LgorCSAqLworCXdoaWxlICghTUlESVFfRU1QVFkoc2NwLT5vdXRfcSkpIHsKKworCSAg ICBpZiAoIXNjcC0+cGxheWluZykgeworCQlzY3AtPnBsYXlpbmcgPSAxOworCQljdl9icm9hZGNh c3QoJnNjcC0+c3RhdGVfY3YpOworCQljdl9icm9hZGNhc3QoJnNjcC0+b3V0X2N2KTsKKwkgICAg fQorCisJICAgIHJsID0gTUlESVFfTEVOKHNjcC0+b3V0X3EpOworCisJICAgIGkgPSBjdl90aW1l ZHdhaXRfc2lnKCZzY3AtPm91dF9jdiwgCisJCSAgICAmc2NwLT5zZXFfbG9jaywgU0VRX1NZTkNf VElNRU9VVCAqIGh6KTsKKworCSAgICBpZiAoaSA9PSBFSU5UUiB8fCBpID09IEVSRVNUQVJUKSB7 CisJCWlmIChpID09IEVJTlRSKSB7CisJCSAgICAvKgorCQkgICAgICogWFhYOiBJIGRvbid0IGtu b3cgd2h5IHdlIHN0b3AgcGxheWluZworCQkgICAgICovCisJCSAgICBzY3AtPnBsYXlpbmcgPSAw OworCQkgICAgY3ZfYnJvYWRjYXN0KCZzY3AtPm91dF9jdik7CisJCX0KKwkJcmV0dXJuIGk7CisJ ICAgIH0KKworCSAgICBpZiAoaSA9PSBFV09VTERCTE9DSyAmJiBybCA9PSBNSURJUV9MRU4oc2Nw LT5vdXRfcSkgJiYKKwkJICAgIHNjcC0+d2FpdGluZyA9PSAwKSB7CisJCS8qCisJCSAqIEEgcXVl dWUgc2VlbXMgdG8gYmUgc3R1Y2sgdXAuIEdpdmUgdXAgYW5kIGNsZWFyIHF1ZXVlcy4KKwkJICov CisJCU1JRElRX0NMRUFSKHNjcC0+b3V0X3EpOworCQlzY3AtPnBsYXlpbmcgPSAwOworCQljdl9i cm9hZGNhc3QoJnNjcC0+c3RhdGVfY3YpOworCQljdl9icm9hZGNhc3QoJnNjcC0+b3V0X2N2KTsK KwkJY3ZfYnJvYWRjYXN0KCZzY3AtPnJlc2V0X2N2KTsKKworCQkvKgorCQkgKiBUT0RPOiBDb25z aWRlciBpZiB0aGUgcmF3IGRldmljZXMgbmVlZCB0byBiZSBmbHVzaGVkCisJCSAqLworCisJCVNF UV9ERUJVRygxLHByaW50Zigic2VxX3N5bmMgcXVldWUgc3R1Y2ssIGFib3J0aW5nXG4iKSk7CisK KwkJcmV0dXJuIGk7CisJICAgIH0KKwl9CisKKwlzY3AtPnBsYXlpbmcgPSAwOworCS8qCisJICog U2luY2Ugc3luY2luZyBhIG1pZGkgZGV2aWNlIG1pZ2h0IGJsb2NrLCB1bmxvY2sgc2NwLT5zZXFf bG9jay4KKwkgKi8KKworCW10eF91bmxvY2soJnNjcC0+c2VxX2xvY2spOworCWZvcihpID0gMCA7 IGkgPCBzY3AtPm1pZGlfbnVtYmVyOyBpKyspCisJICAgIHN5bmNbaV0gPSAxOworCisJZG8gewor CSAgICBkb25lID0gMTsKKwkgICAgZm9yIChpID0gMCA7IGkgPCBzY3AtPm1pZGlfbnVtYmVyOyBp KyspCisJCWlmIChzeW5jW2ldKSB7CisJCSAgICBpZiAoU1lOVEhfSU5TWU5DKHNjcC0+bWlkaXNb aV0pID09IDApCisJCQlzeW5jW2ldID0gMDsKKwkJICAgIGVsc2UKKwkJCWRvbmUgPSAwOworCQl9 CisKKwkgICBpZiAoIWRvbmUpCisJCURFTEFZKDUwMDApOworCisJfSB3aGlsZSAoIWRvbmUpOwor CisJbXR4X2xvY2soJnNjcC0+c2VxX2xvY2spOworCXJldHVybiAwOworfQorCitjaGFyICoKK21p ZGlfY21kbmFtZShpbnQgY21kLCBtaWRpX2NtZHRhYiAqdGFiKQoreworCXdoaWxlICh0YWItPm5h bWUgIT0gTlVMTCkgeworCQlpZiAoY21kID09IHRhYi0+Y21kKQorCQkJcmV0dXJuICh0YWItPm5h bWUpOworCQl0YWIrKzsKKwl9CisKKwlyZXR1cm4gKCJ1bmtub3duIik7Cit9CkluZGV4OiBzeXMv ZGV2L3NvdW5kL21pZGkvc2VxdWVuY2VyLmgKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQpSQ1MgZmlsZTogc3lzL2Rldi9z b3VuZC9taWRpL3NlcXVlbmNlci5oCmRpZmYgLU4gc3lzL2Rldi9zb3VuZC9taWRpL3NlcXVlbmNl ci5oCi0tLSAvZGV2L251bGwJMSBKYW4gMTk3MCAwMDowMDowMCAtMDAwMAorKysgc3lzL2Rldi9z b3VuZC9taWRpL3NlcXVlbmNlci5oCTUgTWFyIDIwMDUgMTY6Mjc6MDcgLTAwMDAKQEAgLTAsMCAr MSw4OCBAQAorLyoKKyAqIEluY2x1ZGUgZmlsZSBmb3IgbWlkaSBzZXF1ZW5jZXIgZHJpdmVyLgor ICogKGMpIDIwMDMgTWF0aGV3IEthbm5lcgorICogQ29weXJpZ2h0IGJ5IFNlaWdvIFRhbmltdXJh IDE5OTkuCisgKgorICogUmVkaXN0cmlidXRpb24gYW5kIHVzZSBpbiBzb3VyY2UgYW5kIGJpbmFy eSBmb3Jtcywgd2l0aCBvciB3aXRob3V0CisgKiBtb2RpZmljYXRpb24sIGFyZSBwZXJtaXR0ZWQg cHJvdmlkZWQgdGhhdCB0aGUgZm9sbG93aW5nIGNvbmRpdGlvbnMKKyAqIGFyZSBtZXQ6CisgKiAx LiBSZWRpc3RyaWJ1dGlvbnMgb2Ygc291cmNlIGNvZGUgbXVzdCByZXRhaW4gdGhlIGFib3ZlIGNv cHlyaWdodAorICogICAgbm90aWNlLCB0aGlzIGxpc3Qgb2YgY29uZGl0aW9ucyBhbmQgdGhlIGZv bGxvd2luZyBkaXNjbGFpbWVyLgorICogMi4gUmVkaXN0cmlidXRpb25zIGluIGJpbmFyeSBmb3Jt IG11c3QgcmVwcm9kdWNlIHRoZSBhYm92ZSBjb3B5cmlnaHQKKyAqICAgIG5vdGljZSwgdGhpcyBs aXN0IG9mIGNvbmRpdGlvbnMgYW5kIHRoZSBmb2xsb3dpbmcgZGlzY2xhaW1lciBpbiB0aGUKKyAq ICAgIGRvY3VtZW50YXRpb24gYW5kL29yIG90aGVyIG1hdGVyaWFscyBwcm92aWRlZCB3aXRoIHRo ZSBkaXN0cmlidXRpb24uCisgKgorICogVEhJUyBTT0ZUV0FSRSBJUyBQUk9WSURFRCBCWSBUSEUg QVVUSE9SIEFORCBDT05UUklCVVRPUlMgYGBBUyBJUycnIEFORAorICogQU5ZIEVYUFJFU1MgT1Ig SU1QTElFRCBXQVJSQU5USUVTLCBJTkNMVURJTkcsIEJVVCBOT1QgTElNSVRFRCBUTywgVEhFCisg KiBJTVBMSUVEIFdBUlJBTlRJRVMgT0YgTUVSQ0hBTlRBQklMSVRZIEFORCBGSVRORVNTIEZPUiBB IFBBUlRJQ1VMQVIgUFVSUE9TRQorICogQVJFIERJU0NMQUlNRUQuICBJTiBOTyBFVkVOVCBTSEFM TCBUSEUgQVVUSE9SIE9SIENPTlRSSUJVVE9SUyBCRSBMSUFCTEUKKyAqIEZPUiBBTlkgRElSRUNU LCBJTkRJUkVDVCwgSU5DSURFTlRBTCwgU1BFQ0lBTCwgRVhFTVBMQVJZLCBPUiBDT05TRVFVRU5U SUFMCisgKiBEQU1BR0VTIChJTkNMVURJTkcsIEJVVCBOT1QgTElNSVRFRCBUTywgUFJPQ1VSRU1F TlQgT0YgU1VCU1RJVFVURSBHT09EUworICogT1IgU0VSVklDRVM7IExPU1MgT0YgVVNFLCBEQVRB LCBPUiBQUk9GSVRTOyBPUiBCVVNJTkVTUyBJTlRFUlJVUFRJT04pCisgKiBIT1dFVkVSIENBVVNF RCBBTkQgT04gQU5ZIFRIRU9SWSBPRiBMSUFCSUxJVFksIFdIRVRIRVIgSU4gQ09OVFJBQ1QsIFNU UklDVAorICogTElBQklMSVRZLCBPUiBUT1JUIChJTkNMVURJTkcgTkVHTElHRU5DRSBPUiBPVEhF UldJU0UpIEFSSVNJTkcgSU4gQU5ZIFdBWQorICogT1VUIE9GIFRIRSBVU0UgT0YgVEhJUyBTT0ZU V0FSRSwgRVZFTiBJRiBBRFZJU0VEIE9GIFRIRSBQT1NTSUJJTElUWSBPRgorICogU1VDSCBEQU1B R0UuCisgKgorICogJEZyZWVCU0Q6IHNyYy9zeXMvZGV2L3NvdW5kL21pZGkvc2VxdWVuY2VyLmgs diAxLjUgMjAwMi8wMS8wNCAwMToxMzo0NyB0YW5pbXVyYSBFeHAgJAorICoKKyAqLworCisjaWZu ZGVmIF9TRVFVRU5DRVJfSF8KKyNkZWZpbmUgX1NFUVVFTkNFUl9IXworCisKKyNkZWZpbmUgU0VR X0NERVZfTUFKT1IgTUlESV9DREVWX01BSk9SCisKKyNkZWZpbmUgTlNFUV9NQVgJMTYKKworLyoK KyAqIG1hbnkgdmFyaWFibGVzIHNob3VsZCBiZSByZWR1Y2VkIHRvIGEgcmFuZ2UuIEhlcmUgZGVm aW5lIGEgbWFjcm8KKyAqLworCisjZGVmaW5lIFJBTkdFKHZhciwgbG93LCBoaWdoKSAodmFyKSA9 IFwKKygodmFyKTwobG93KT8obG93KSA6ICh2YXIpPihoaWdoKT8oaGlnaCkgOiAodmFyKSkKKwor I2lmZGVmIF9LRVJORUwKKwordm9pZAlzZXFfdGltZXIodm9pZCAqYXJnKTsKKworU1lTQ1RMX0RF Q0woX2h3X21pZGlfc2VxKTsKKworZXh0ZXJuIGludAlzZXFfZGVidWc7CisjZGVmaW5lIFNFUV9E RUJVRyh5LCB4KQkJCVwKKwlkbyB7CQkJCVwKKwkJaWYgKHNlcV9kZWJ1ZyA+PSB5KSB7CVwKKwkJ CSh4KTsJCVwKKwkJfQkJCVwKKwl9IHdoaWxlKDApCisKK1NZU0NUTF9ERUNMKF9od19taWRpKTsK KworI2VuZGlmIC8qIF9LRVJORUwgKi8KKworI2RlZmluZSBTWU5USFBST1BfTUlESQkJMQorI2Rl ZmluZSBTWU5USFBST1BfU1lOVEgJCTIKKyNkZWZpbmUgU1lOVEhQUk9QX1JYCQk0CisjZGVmaW5l IFNZTlRIUFJPUF9UWAkJOAorCitzdHJ1Y3QgX21pZGlfY21kdGFiIHsKKyAgICBpbnQgICAgIGNt ZDsKKyAgICBjaGFyICogIG5hbWU7Cit9OwordHlwZWRlZiBzdHJ1Y3QgX21pZGlfY21kdGFiICAg ICAgbWlkaV9jbWR0YWI7CitleHRlcm4gbWlkaV9jbWR0YWIgY21kdGFiX3NlcWV2ZW50W107Citl eHRlcm4gbWlkaV9jbWR0YWIgY21kdGFiX3NlcWlvY3RsW107CitleHRlcm4gbWlkaV9jbWR0YWIg Y21kdGFiX3RpbWVyW107CitleHRlcm4gbWlkaV9jbWR0YWIgY21kdGFiX3NlcWN2W107CitleHRl cm4gbWlkaV9jbWR0YWIgY21kdGFiX3NlcWNjbW5bXTsKKworY2hhciAgICAgKm1pZGlfY21kbmFt ZShpbnQgY21kLCBtaWRpX2NtZHRhYiAqdGFiKTsKKworZW51bSB7CisJTU9SRSwKKwlUSU1FUkFS TUVELAorCVFVRVVFRlVMTAorfTsKKworI2VuZGlmCkluZGV4OiBzeXMvZGV2L3NvdW5kL21pZGkv c3ludGhfaWYubQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09ClJDUyBmaWxlOiBzeXMvZGV2L3NvdW5kL21pZGkvc3ludGhf aWYubQpkaWZmIC1OIHN5cy9kZXYvc291bmQvbWlkaS9zeW50aF9pZi5tCi0tLSAvZGV2L251bGwJ MSBKYW4gMTk3MCAwMDowMDowMCAtMDAwMAorKysgc3lzL2Rldi9zb3VuZC9taWRpL3N5bnRoX2lm Lm0JNSBNYXIgMjAwNSAxNjoyNzowNyAtMDAwMApAQCAtMCwwICsxLDI4NSBAQAorSU5URVJGQUNF IHN5bnRoOworCisjaW5jbHVkZSA8c3lzL3N5c3RtLmg+CisKK0NPREUgeworCitzeW50aF9raWxs bm90ZV90IG5va2lsbG5vdGU7CitzeW50aF9zdGFydG5vdGVfdCBub3N0YXJ0bm90ZTsKK3N5bnRo X3NldGluc3RyX3Qgbm9zZXRpbnN0cjsKK3N5bnRoX2h3Y29udHJvbF90IG5vaHdjb250cm9sOwor c3ludGhfYWZ0ZXJ0b3VjaF90IG5vYWZ0ZXJ0b3VjaDsKK3N5bnRoX3Bhbm5pbmdfdCBub3Bhbm5p bmc7CitzeW50aF9jb250cm9sbGVyX3Qgbm9jb250cm9sbGVyOworc3ludGhfdm9sdW1lbWV0aG9k X3Qgbm92b2x1bWVtZXRob2Q7CitzeW50aF9iZW5kZXJfdCBub2JlbmRlcjsKK3N5bnRoX3NldHVw dm9pY2VfdCBub3NldHVwdm9pY2U7CitzeW50aF9zZW5kc3lzZXhfdCBub3NlbmRzeXNleDsKK3N5 bnRoX2FsbG9jdm9pY2VfdCBub2FsbG9jdm9pY2U7CitzeW50aF93cml0ZXJhd190IG5vd3JpdGVy YXc7CitzeW50aF9yZXNldF90IG5vcmVzZXQ7CitzeW50aF9zaG9ydG5hbWVfdCBub3Nob3J0bmFt ZTsKK3N5bnRoX29wZW5fdCBub29wZW47CitzeW50aF9jbG9zZV90IG5vY2xvc2U7CitzeW50aF9x dWVyeV90IG5vcXVlcnk7CitzeW50aF9pbnN5bmNfdCBub2luc3luYzsKK3N5bnRoX2FsbG9jX3Qg bm9hbGxvYzsKKworICAgIGludAorCW5va2lsbG5vdGUodm9pZCAqX2tvYmosIHVpbnQ4X3QgX2No biwgdWludDhfdCBfbm90ZSwgdWludDhfdCBfdmVsKQorCXsKKwkgICAgcHJpbnRmKCJub2tpbGxu b3RlXG4iKTsKKwkgICAgcmV0dXJuIDA7CisJfQorCisgICAgaW50CisJbm9vcGVuKHZvaWQgKl9r b2JqLCB2b2lkICpfYXJnLCBpbnQgbW9kZSkKKwl7CisJICAgIHByaW50Zigibm9vcGVuXG4iKTsK KwkgICAgcmV0dXJuIDA7CisJfQorCisgICAgaW50CisJbm9xdWVyeSh2b2lkICpfa2JvaikKKwl7 CisJICAgIHByaW50Zigibm9xdWVyeVxuIik7CisJICAgIHJldHVybiAwOworCX0KKworICAgIGlu dAorCW5vc3RhcnRub3RlKHZvaWQgKl9rYiwgdWludDhfdCBfdm9pY2UsIHVpbnQ4X3QgX25vdGUs IHVpbnQ4X3QgX3Bhcm0pCisJeworCSAgICBwcmludGYoIm5vc3RhcnRub3RlXG4iKTsKKwkgICAg cmV0dXJuIDA7CisJfQorCisgICAgaW50CisJbm9zZXRpbnN0cih2b2lkICpfa2IsIHVpbnQ4X3Qg X2NobiwgdWludDE2X3QgX3BhdGNobm8pCisJeworCSAgICBwcmludGYoIm5vc2V0aW5zdHJcbiIp OworCSAgICByZXR1cm4gMDsKKwl9CisKKyAgICBpbnQKKwlub2h3Y29udHJvbCh2b2lkICpfa2Is IHVpbnQ4X3QgKl9ldmVudCkKKwl7CisJICAgIHByaW50Zigibm9od2NvbnRyb2xcbiIpOworCSAg ICByZXR1cm4gMDsKKwl9CisKKyAgICBpbnQgCisJbm9hZnRlcnRvdWNoICggdm9pZCAvKiBYICov ICogX2tvYmosIHVpbnQ4X3QgX3gxLCB1aW50OF90IF94MikKKwl7CisJICAgIHByaW50Zigibm9h ZnRlcnRvdWNoXG4iKTsKKwkgICAgcmV0dXJuIDA7CisJfQorCisgICAgaW50CisJbm9wYW5uaW5n ICggdm9pZCAvKiBYICovICogX2tvYmosIHVpbnQ4X3QgX3gxLCB1aW50OF90IF94MikKKwl7CisJ ICAgIHByaW50Zigibm9wYW5uaW5nXG4iKTsKKwkgICAgcmV0dXJuIDA7CisJfQorCisgICAgaW50 IAorCW5vY29udHJvbGxlciAoIHZvaWQgLyogWCAqLyAqIF9rb2JqLCB1aW50OF90IF94MSwgdWlu dDhfdCBfeDIsIHVpbnQxNl90IF94MykKKwl7CisJICAgIHByaW50Zigibm9jb250cm9sbGVyXG4i KTsKKwkgICAgcmV0dXJuIDA7CisJfQorCisgICAgaW50IAorCW5vdm9sdW1lbWV0aG9kICgKKwkJ dm9pZCAvKiBYICovICogX2tvYmosCisJCXVpbnQ4X3QgX3gxKQorCXsKKwkgICAgcHJpbnRmKCJu b3ZvbHVtZW1ldGhvZFxuIik7CisJICAgIHJldHVybiAwOworCX0KKworICAgIGludCAKKwlub2Jl bmRlciAoIHZvaWQgLyogWCAqLyAqIF9rb2JqLCB1aW50OF90IF92b2ljZSwgdWludDE2X3QgX2Jl bmQpCisJeworCSAgICBwcmludGYoIm5vYmVuZGVyXG4iKTsKKwkgICAgcmV0dXJuIDA7CisJfQor CisgICAgaW50IAorCW5vc2V0dXB2b2ljZSAoIHZvaWQgLyogWCAqLyAqIF9rb2JqLCB1aW50OF90 IF92b2ljZSwgdWludDhfdCBfY2huKQorCXsKKworCSAgICBwcmludGYoIm5vc2V0dXB2b2ljZVxu Iik7CisJICAgIHJldHVybiAwOworCX0KKworICAgIGludCAKKwlub3NlbmRzeXNleCAoIHZvaWQg LyogWCAqLyAqIF9rb2JqLCB2b2lkICogX2J1Ziwgc2l6ZV90IF9sZW4pCisJeworCSAgICBwcmlu dGYoIm5vc2VuZHN5c2V4XG4iKTsKKwkgICAgcmV0dXJuIDA7CisJfQorCisgICAgaW50IAorCW5v YWxsb2N2b2ljZSAoIHZvaWQgLyogWCAqLyAqIF9rb2JqLCB1aW50OF90IF9jaG4sIHVpbnQ4X3Qg X25vdGUsIHZvaWQgKl94KQorCXsKKwkgICAgcHJpbnRmKCJub2FsbG9jdm9pY2VcbiIpOworCSAg ICByZXR1cm4gMDsKKwl9CisKKyAgICBpbnQgCisJbm93cml0ZXJhdyAoIHZvaWQgLyogWCAqLyAq IF9rb2JqdCwgdWludDhfdCAqIF9idWYsIHNpemVfdCBfbGVuKQorCXsKKwkgICAgcHJpbnRmKCJu b3dyaXRlcmF3XG4iKTsKKwkgICAgcmV0dXJuIDE7CisJfQorCisgICAgaW50IAorCW5vcmVzZXQg KCB2b2lkIC8qIFggKi8gKiBfa29ianQpCisJeworCisJICAgIHByaW50Zigibm9yZXNldFxuIik7 CisJICAgIHJldHVybiAwOworCX0KKworICAgIGNoYXIgKgorCW5vc2hvcnRuYW1lICh2b2lkIC8q IFggKi8gKiBfa29ianQpCisJeworCSAgICBwcmludGYoIm5vc2hvcnRuYW1lXG4iKTsKKwkgICAg cmV0dXJuICJub3Nob3J0bmFtZSI7CisJfQorCisgICAgaW50IAorCW5vY2xvc2UgKCB2b2lkIC8q IFggKi8gKiBfa29ianQpCisJeworCisJICAgIHByaW50Zigibm9jbG9zZVxuIik7CisJICAgIHJl dHVybiAwOworCX0KKworICAgIGludAorCW5vaW5zeW5jICh2b2lkIC8qIFggKi8gKiBfa29ianQp CisJeworCisJICAgIHByaW50Zigibm9pbnN5bmNcbiIpOworCSAgICByZXR1cm4gMDsKKwl9CisK KyAgICBpbnQgCisJbm9hbGxvYyAoIHZvaWQgLyogeCAqLyAqIF9rYm9qdCwgdWludDhfdCBfY2hu LCB1aW50OF90IF9ub3RlKQorCXsKKwkgICAgcHJpbnRmKCJub2FsbG9jXG4iKTsKKwkgICAgcmV0 dXJuIDA7CisJfQorfQorCitNRVRIT0QgaW50IGtpbGxub3RlIHsKKyAgICB2b2lkIC8qIFggKi8g KiBfa29iajsKKyAgICB1aW50OF90IF9jaGFuOworICAgIHVpbnQ4X3QgX25vdGU7CisgICAgdWlu dDhfdCBfdmVsOworfSBERUZBVUxUIG5va2lsbG5vdGU7CisKK01FVEhPRCBpbnQgc3RhcnRub3Rl IHsKKyAgICB2b2lkIC8qIFggKi8gKiBfa29iajsKKyAgICB1aW50OF90IF92b2ljZTsKKyAgICB1 aW50OF90IF9ub3RlOworICAgIHVpbnQ4X3QgX3Bhcm07Cit9IERFRkFVTFQgbm9zdGFydG5vdGU7 CisKK01FVEhPRCBpbnQgc2V0aW5zdHIgeworICAgIHZvaWQgLyogWCAqLyAqIF9rb2JqOworICAg IHVpbnQ4X3QgX2NobjsKKyAgICB1aW50MTZfdCBfcGF0Y2hubzsKK30gREVGQVVMVCBub3NldGlu c3RyOworCitNRVRIT0QgaW50IGh3Y29udHJvbCB7CisgICAgdm9pZCAvKiBYICovICogX2tvYmo7 CisgICAgdWludDhfdCAqX2V2ZW50OworfSBERUZBVUxUIG5vaHdjb250cm9sOworCitNRVRIT0Qg aW50IGFmdGVydG91Y2ggeworICAgIHZvaWQgLyogWCAqLyAqIF9rb2JqOworICAgIHVpbnQ4X3Qg X3gxOworICAgIHVpbnQ4X3QgX3gyOworfSBERUZBVUxUIG5vYWZ0ZXJ0b3VjaDsKKworTUVUSE9E IGludCBwYW5uaW5nIHsKKyAgICB2b2lkIC8qIFggKi8gKiBfa29iajsKKyAgICB1aW50OF90IF94 MTsKKyAgICAgICAgdWludDhfdCBfeDI7Cit9IERFRkFVTFQgbm9wYW5uaW5nOworCitNRVRIT0Qg aW50IGNvbnRyb2xsZXIgeworICAgIHZvaWQgLyogWCAqLyAqIF9rb2JqOworICAgIHVpbnQ4X3Qg X3gxOworICAgIHVpbnQ4X3QgX3gyOworICAgIHVpbnQxNl90IF94MzsKK30gREVGQVVMVCBub2Nv bnRyb2xsZXI7CisKK01FVEhPRCBpbnQgdm9sdW1lbWV0aG9kIHsKKyAgICB2b2lkIC8qIFggKi8g KiBfa29iajsKKyAgICB1aW50OF90IF94MTsKK30gREVGQVVMVCBub3ZvbHVtZW1ldGhvZDsKKwor TUVUSE9EIGludCBiZW5kZXIgeworICAgIHZvaWQgLyogWCAqLyAqIF9rb2JqOworICAgIHVpbnQ4 X3QgX3ZvaWNlOworICAgIHVpbnQxNl90IF9iZW5kOworfSBERUZBVUxUIG5vYmVuZGVyOworCitN RVRIT0QgaW50IHNldHVwdm9pY2UgeworICAgIHZvaWQgLyogWCAqLyAqIF9rb2JqOworICAgIHVp bnQ4X3QgX3ZvaWNlOworICAgIHVpbnQ4X3QgX2NobjsKK30gREVGQVVMVCBub3NldHVwdm9pY2U7 CisKK01FVEhPRCBpbnQgc2VuZHN5c2V4IHsKKyAgICB2b2lkIC8qIFggKi8gKiBfa29iajsKKyAg ICB2b2lkICogX2J1ZjsKKyAgICBzaXplX3QgX2xlbjsKK30gREVGQVVMVCBub3NlbmRzeXNleDsK KworTUVUSE9EIGludCBhbGxvY3ZvaWNlIHsKKyAgICB2b2lkIC8qIFggKi8gKiBfa29iajsKKyAg ICB1aW50OF90IF9jaG47CisgICAgdWludDhfdCBfbm90ZTsKKyAgICB2b2lkICpfeDsKK30gREVG QVVMVCBub2FsbG9jdm9pY2U7CisKK01FVEhPRCBpbnQgd3JpdGVyYXcgeworICAgIHZvaWQgLyog WCAqLyAqIF9rb2JqdDsKKyAgICB1aW50OF90ICogX2J1ZjsKKyAgICBzaXplX3QgX2xlbjsKK30g REVGQVVMVCBub3dyaXRlcmF3OworCitNRVRIT0QgaW50IHJlc2V0IHsKKyAgICB2b2lkIC8qIFgg Ki8gKiBfa29ianQ7Cit9IERFRkFVTFQgbm9yZXNldDsKKworTUVUSE9EIGNoYXIgKiBzaG9ydG5h bWUgeworICAgIHZvaWQgLyogWCAqLyAqIF9rb2JqdDsKK30gREVGQVVMVCBub3Nob3J0bmFtZTsK KworTUVUSE9EIGludCBvcGVuIHsKKyAgICB2b2lkIC8qIFggKi8gKiBfa29ianQ7CisgICAgdm9p ZCAqIF9zeXRobjsKKyAgICBpbnQgX21vZGU7Cit9IERFRkFVTFQgbm9vcGVuOworCitNRVRIT0Qg aW50IGNsb3NlIHsKKyAgICB2b2lkIC8qIFggKi8gKiBfa29ianQ7Cit9IERFRkFVTFQgbm9jbG9z ZTsKKworTUVUSE9EIGludCBxdWVyeSB7CisgICAgdm9pZCAvKiBYICovICogX2tvYmp0OworfSBE RUZBVUxUIG5vcXVlcnk7CisKK01FVEhPRCBpbnQgaW5zeW5jIHsKKyAgICB2b2lkIC8qIFggKi8g KiBfa29ianQ7Cit9IERFRkFVTFQgbm9pbnN5bmM7CisKK01FVEhPRCBpbnQgYWxsb2MgeworICAg IHZvaWQgLyogeCAqLyAqIF9rYm9qdDsKKyAgICB1aW50OF90IF9jaG47CisgICAgdWludDhfdCBf bm90ZTsKK30gREVGQVVMVCBub2FsbG9jOwpJbmRleDogc3lzL2Rldi9zb3VuZC9wY2kvY21pLmMK PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PQpSQ1MgZmlsZTogL2hvbWUvbmN2cy9zcmMvc3lzL2Rldi9zb3VuZC9wY2kvY21p LmMsdgpyZXRyaWV2aW5nIHJldmlzaW9uIDEuMjkuMi4xCmRpZmYgLXUgLXIxLjI5LjIuMSBjbWku YwotLS0gc3lzL2Rldi9zb3VuZC9wY2kvY21pLmMJMzAgSmFuIDIwMDUgMDE6MDA6MDMgLTAwMDAJ MS4yOS4yLjEKKysrIHN5cy9kZXYvc291bmQvcGNpL2NtaS5jCTUgTWFyIDIwMDUgMTY6Mjc6MDcg LTAwMDAKQEAgLTQ4LDggKzQ4LDEwIEBACiAjaW5jbHVkZSA8ZGV2L3BjaS9wY2l2YXIuaD4KIAog I2luY2x1ZGUgPHN5cy9zeXNjdGwuaD4KKyNpbmNsdWRlIDxkZXYvc291bmQvbWlkaS9tcHU0MDEu aD4KIAogI2luY2x1ZGUgIm1peGVyX2lmLmgiCisjaW5jbHVkZSAibXB1Zm9pX2lmLmgiCiAKIFNO RF9ERUNMQVJFX0ZJTEUoIiRGcmVlQlNEOiBzcmMvc3lzL2Rldi9zb3VuZC9wY2kvY21pLmMsdiAx LjI5LjIuMSAyMDA1LzAxLzMwIDAxOjAwOjAzIGltcCBFeHAgJCIpOwogCkBAIC0xMTIsNiArMTE0 LDEzIEBACiAJaW50CQkJc3BkaWZfZW5hYmxlZDsKIAl1bnNpZ25lZCBpbnQJCWJ1ZnN6OwogCXN0 cnVjdCBzY19jaGluZm8gCXBjaCwgcmNoOworCisJc3RydWN0IG1wdTQwMQkqbXB1OworCW1wdTQw MV9pbnRyX3QJCSptcHVfaW50cjsKKwlzdHJ1Y3QgcmVzb3VyY2UgKm1wdV9yZWc7CisJaW50IG1w dV9yZWdpZDsKKwlidXNfc3BhY2VfdGFnX3QJbXB1X2J0OworCWJ1c19zcGFjZV9oYW5kbGVfdAlt cHVfYmg7CiB9OwogCiAvKiBDaGFubmVsIGNhcHMgKi8KQEAgLTU1MSw2ICs1NjAsOSBAQAogCiAJ CX0KIAl9CisJaWYoc2MtPm1wdV9pbnRyKSB7CisJCShzYy0+bXB1X2ludHIpKHNjLT5tcHUpOwor CX0KIAlzbmRfbXR4dW5sb2NrKHNjLT5sb2NrKTsKIAlyZXR1cm47CiB9CkBAIC03NDcsNiArNzU5 LDc0IEBACiB9OwogTUlYRVJfREVDTEFSRShjbWlfbWl4ZXIpOwogCisvKgorICogbXB1NDAxIGZ1 bmN0aW9ucworICovCisKK3N0YXRpYyB1bnNpZ25lZCBjaGFyCitjbWlfbXJlYWQodm9pZCAqYXJn LCBzdHJ1Y3Qgc2NfaW5mbyAqc2MsIGludCByZWcpCit7CQorCXVuc2lnbmVkIGludCBkOworCisJ CWQgPSBidXNfc3BhY2VfcmVhZF8xKDAsMCwgMHgzMzAgKyByZWcpOyAKKwkvKglwcmludGYoImNt aV9tcmVhZDogcmVnICV4ICV4XG4iLHJlZywgZCk7CisJKi8KKwlyZXR1cm4gZDsKK30KKworc3Rh dGljIHZvaWQKK2NtaV9td3JpdGUodm9pZCAqYXJnLCBzdHJ1Y3Qgc2NfaW5mbyAqc2MsIGludCBy ZWcsIHVuc2lnbmVkIGNoYXIgYikKK3sKKworCWJ1c19zcGFjZV93cml0ZV8xKDAsMCwweDMzMCAr IHJlZyAsIGIpOworfQorCitzdGF0aWMgaW50CitjbWlfbXVuaW5pdCh2b2lkICphcmcsIHN0cnVj dCBzY19pbmZvICpzYykKK3sKKworCXNuZF9tdHhsb2NrKHNjLT5sb2NrKTsKKwlzYy0+bXB1X2lu dHIgPSAwOworCXNjLT5tcHUgPSAwOworCXNuZF9tdHh1bmxvY2soc2MtPmxvY2spOworCisJcmV0 dXJuIDA7Cit9CisKK3N0YXRpYyBrb2JqX21ldGhvZF90IGNtaV9tcHVfbWV0aG9kc1tdID0gewor ICAgIAlLT0JKTUVUSE9EKG1wdWZvaV9yZWFkLAkJY21pX21yZWFkKSwKKyAgICAJS09CSk1FVEhP RChtcHVmb2lfd3JpdGUsCWNtaV9td3JpdGUpLAorICAgIAlLT0JKTUVUSE9EKG1wdWZvaV91bmlu aXQsCWNtaV9tdW5pbml0KSwKKwl7IDAsIDAgfQorfTsKKworREVGSU5FX0NMQVNTKGNtaV9tcHUs IGNtaV9tcHVfbWV0aG9kcywgMCk7CisKK3N0YXRpYyB2b2lkCitjbWlfbWlkaWF0dGFjaChzdHJ1 Y3Qgc2NfaW5mbyAqc2MpIHsKKy8qCisJY29uc3Qgc3RydWN0IHsKKwkJaW50IHBvcnQsYml0czsK Kwl9ICpwLCBwb3J0c1tdID0geyAKKwkJezB4MzMwLDB9LCAKKwkJezB4MzIwLDF9LCAKKwkJezB4 MzEwLDJ9LCAKKwkJezB4MzAwLDN9LCAKKwkJezAsMH0gfSA7CisJTm90ZXMsIENNUENJX1JFR19W TVBVU0VMIHNldHMgdGhlIGlvIHBvcnQgZm9yIHRoZSBtcHUuICBEb2VzCisJYW55b25lIGtub3cg aG93IHRvIGJ1c19zcGFjZSB0YWc/CisqLworCWNtaV9jbHI0KHNjLCBDTVBDSV9SRUdfRlVOQ18x LCBDTVBDSV9SRUdfVUFSVF9FTkFCTEUpOworCWNtaV9jbHI0KHNjLCBDTVBDSV9SRUdfTEVHQUNZ X0NUUkwsIAorCQkJQ01QQ0lfUkVHX1ZNUFVTRUxfTUFTSyA8PCBDTVBDSV9SRUdfVk1QVVNFTF9T SElGVCk7CisJY21pX3NldDQoc2MsIENNUENJX1JFR19MRUdBQ1lfQ1RSTCwgCisJCQkwIDw8IENN UENJX1JFR19WTVBVU0VMX1NISUZUICk7CisJY21pX3NldDQoc2MsIENNUENJX1JFR19GVU5DXzEs IENNUENJX1JFR19VQVJUX0VOQUJMRSk7CisJc2MtPm1wdSA9IG1wdTQwMV9pbml0KCZjbWlfbXB1 X2NsYXNzLCBzYywgY21pX2ludHIsICZzYy0+bXB1X2ludHIpOworfQorCisKKwogLyogLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLSAqLwogLyogUG93ZXIgYW5kIHJlc2V0ICovCiAKQEAgLTgwMiw2ICs4ODIsMTAg QEAKIAkJIENNUENJX1JFR19URE1BX0lOVFJfRU5BQkxFKTsKIAljbWlfY2xyNChzYywgQ01QQ0lf UkVHX0ZVTkNfMCwKIAkJIENNUENJX1JFR19DSDBfRU5BQkxFIHwgQ01QQ0lfUkVHX0NIMV9FTkFC TEUpOworCWNtaV9jbHI0KHNjLCBDTVBDSV9SRUdfRlVOQ18xLCBDTVBDSV9SRUdfVUFSVF9FTkFC TEUpOworCisJaWYoIHNjLT5tcHUgKQorCQlzYy0+bXB1X2ludHIgPSAwOwogfQogCiAvKiAtLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tICovCkBAIC04NTksNiArOTQzLDggQEAKIAlzYy0+c3QgPSBybWFuX2dldF9i dXN0YWcoc2MtPnJlZyk7CiAJc2MtPnNoID0gcm1hbl9nZXRfYnVzaGFuZGxlKHNjLT5yZWcpOwog CisJY21pX21pZGlhdHRhY2goc2MpOworCiAJc2MtPmlycWlkID0gMDsKIAlzYy0+aXJxICAgPSBi dXNfYWxsb2NfcmVzb3VyY2VfYW55KGRldiwgU1lTX1JFU19JUlEsICZzYy0+aXJxaWQsCiAJCQkJ CSAgIFJGX0FDVElWRSB8IFJGX1NIQVJFQUJMRSk7CkBAIC05MzgsNyArMTAyNCwxMiBAQAogCWJ1 c19kbWFfdGFnX2Rlc3Ryb3koc2MtPnBhcmVudF9kbWF0KTsKIAlidXNfdGVhcmRvd25faW50cihk ZXYsIHNjLT5pcnEsIHNjLT5paCk7CiAJYnVzX3JlbGVhc2VfcmVzb3VyY2UoZGV2LCBTWVNfUkVT X0lSUSwgc2MtPmlycWlkLCBzYy0+aXJxKTsKKwlpZihzYy0+bXB1KQorCQltcHU0MDFfdW5pbml0 KHNjLT5tcHUpOwogCWJ1c19yZWxlYXNlX3Jlc291cmNlKGRldiwgU1lTX1JFU19JT1BPUlQsIHNj LT5yZWdpZCwgc2MtPnJlZyk7CisJaWYgKHNjLT5tcHVfcmVnKQorCSAgICBidXNfcmVsZWFzZV9y ZXNvdXJjZShkZXYsIFNZU19SRVNfSU9QT1JULCBzYy0+bXB1X3JlZ2lkLCBzYy0+bXB1X3JlZyk7 CisKIAlzbmRfbXR4ZnJlZShzYy0+bG9jayk7CiAJZnJlZShzYywgTV9ERVZCVUYpOwogCkBAIC0x MDA5LDQgKzExMDAsNSBAQAogCiBEUklWRVJfTU9EVUxFKHNuZF9jbWksIHBjaSwgY21pX2RyaXZl ciwgcGNtX2RldmNsYXNzLCAwLCAwKTsKIE1PRFVMRV9ERVBFTkQoc25kX2NtaSwgc291bmQsIFNP VU5EX01JTlZFUiwgU09VTkRfUFJFRlZFUiwgU09VTkRfTUFYVkVSKTsKK01PRFVMRV9ERVBFTkQo c25kX2NtaSwgbWlkaSwgMSwxLDEpOwogTU9EVUxFX1ZFUlNJT04oc25kX2NtaSwgMSk7CkluZGV4 OiBzeXMvZGV2L3NvdW5kL3BjaS9lbXUxMGsxLmMKPT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQpSQ1MgZmlsZTogL2hvbWUv bmN2cy9zcmMvc3lzL2Rldi9zb3VuZC9wY2kvZW11MTBrMS5jLHYKcmV0cmlldmluZyByZXZpc2lv biAxLjUyLjIuMgpkaWZmIC11IC1yMS41Mi4yLjIgZW11MTBrMS5jCi0tLSBzeXMvZGV2L3NvdW5k L3BjaS9lbXUxMGsxLmMJMzAgSmFuIDIwMDUgMDE6MDA6MDQgLTAwMDAJMS41Mi4yLjIKKysrIHN5 cy9kZXYvc291bmQvcGNpL2VtdTEwazEuYwk1IE1hciAyMDA1IDE2OjMyOjQwIC0wMDAwCkBAIC0z NSw2ICszNSwxMCBAQAogI2luY2x1ZGUgPGRldi9wY2kvcGNpdmFyLmg+CiAjaW5jbHVkZSA8c3lz L3F1ZXVlLmg+CiAKKyNpbmNsdWRlIDxkZXYvc291bmQvbWlkaS9tcHU0MDEuaD4KKyNpbmNsdWRl ICJtcHVmb2lfaWYuaCIKKworCiBTTkRfREVDTEFSRV9GSUxFKCIkRnJlZUJTRDogc3JjL3N5cy9k ZXYvc291bmQvcGNpL2VtdTEwazEuYyx2IDEuNTIuMi4yIDIwMDUvMDEvMzAgMDE6MDA6MDQgaW1w IEV4cCAkIik7CiAKIC8qIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tICovCkBAIC0xMzYsNiArMTQwLDkgQEAKIAlzdHJ1 Y3QgZW11X3ZvaWNlIHZvaWNlWzY0XTsKIAlzdHJ1Y3Qgc2NfcGNoaW5mbyBwY2hbRU1VX01BWF9D SEFOU107CiAJc3RydWN0IHNjX3JjaGluZm8gcmNoWzNdOworCXN0cnVjdCBtcHU0MDEgICAqbXB1 OworCW1wdTQwMV9pbnRyX3QgICAgICAgICAgICptcHVfaW50cjsKKwlpbnQgbXB1dHg7CiB9Owog CiAvKiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLSAqLwpAQCAtMTA1OCw4ICsxMDY1LDY1IEBACiB9OwogQ0hBTk5FTF9E RUNMQVJFKGVtdXJjaGFuKTsKIAorc3RhdGljIHVuc2lnbmVkIGNoYXIKK2VtdV9tcmVhZCh2b2lk ICphcmcsIHN0cnVjdCBzY19pbmZvICpzYywgaW50IHJlZykKK3sJCisJdW5zaWduZWQgaW50IGQ7 CisKKwlkID0gZW11X3JkKHNjLCAweDE4ICsgcmVnLCAxKTsgCisJcmV0dXJuIGQ7Cit9CisKK3N0 YXRpYyB2b2lkCitlbXVfbXdyaXRlKHZvaWQgKmFyZywgc3RydWN0IHNjX2luZm8gKnNjLCBpbnQg cmVnLCB1bnNpZ25lZCBjaGFyIGIpCit7CisKKwllbXVfd3Ioc2MsIDB4MTggKyByZWcsIGIsIDEp OworfQorCitzdGF0aWMgaW50CitlbXVfbXVuaW5pdCh2b2lkICphcmcsIHN0cnVjdCBzY19pbmZv ICpzYykKK3sKKworCXNuZF9tdHhsb2NrKHNjLT5sb2NrKTsKKwlzYy0+bXB1X2ludHIgPSAwOwor CXNuZF9tdHh1bmxvY2soc2MtPmxvY2spOworCisJcmV0dXJuIDA7Cit9CisKK3N0YXRpYyBrb2Jq X21ldGhvZF90IGVtdV9tcHVfbWV0aG9kc1tdID0geworICAgIAlLT0JKTUVUSE9EKG1wdWZvaV9y ZWFkLAkJZW11X21yZWFkKSwKKyAgICAJS09CSk1FVEhPRChtcHVmb2lfd3JpdGUsCWVtdV9td3Jp dGUpLAorICAgIAlLT0JKTUVUSE9EKG1wdWZvaV91bmluaXQsCWVtdV9tdW5pbml0KSwKKwl7IDAs IDAgfQorfTsKKworREVGSU5FX0NMQVNTKGVtdV9tcHUsIGVtdV9tcHVfbWV0aG9kcywgMCk7CisK K3N0YXRpYyB2b2lkCitlbXVfaW50cjIodm9pZCAqcCkKK3sKKwlzdHJ1Y3Qgc2NfaW5mbyAqc2Mg PSAoc3RydWN0IHNjX2luZm8gKilwOworCisJaWYgKHNjLT5tcHVfaW50cikKKwkgICAgKHNjLT5t cHVfaW50cikoc2MtPm1wdSk7Cit9CisKK3N0YXRpYyB2b2lkCitlbXVfbWlkaWF0dGFjaChzdHJ1 Y3Qgc2NfaW5mbyAqc2MpCit7CisJaW50IGk7CisKKwlpID0gZW11X3JkKHNjLCBJTlRFLCA0KTsK KwlpIHw9IElOVEVfTUlESVJYRU5BQkxFOworCWVtdV93cihzYywgSU5URSwgaSwgNCk7CisKKwlz Yy0+bXB1ID0gbXB1NDAxX2luaXQoJmVtdV9tcHVfY2xhc3MsIHNjLCBlbXVfaW50cjIsICZzYy0+ bXB1X2ludHIpOworfQogLyogLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gKi8KIC8qIFRoZSBpbnRlcnJ1cHQgaGFuZGxl ciAqLworCiBzdGF0aWMgdm9pZAogZW11X2ludHIodm9pZCAqZGF0YSkKIHsKQEAgLTEwOTksNiAr MTE2MywxMSBAQAogI2VuZGlmCiAJCX0KIAorCSAgICBpZiAoc3RhdCAmIElQUl9NSURJUkVDVkJV RkVNUFRZKQorCQlpZiAoc2MtPm1wdV9pbnRyKSB7CisJCSAgICAoc2MtPm1wdV9pbnRyKShzYy0+ bXB1KTsKKwkJICAgIGFjayB8PSBJUFJfTUlESVJFQ1ZCVUZFTVBUWSB8IElQUl9NSURJVFJBTlNC VUZFTVBUWTsKKyAJCX0KIAkJaWYgKHN0YXQgJiB+YWNrKQogCQkJZGV2aWNlX3ByaW50ZihzYy0+ ZGV2LCAiZG9kZ3kgaXJxOiAleCAoaGFybWxlc3MpXG4iLAogCQkJICAgIHN0YXQgJiB+YWNrKTsK QEAgLTE4MTgsNyArMTg4Nyw2IEBACiAJCQl9CiAJCX0KIAl9Ci0KIAlyZXR1cm4gMDsKIH0KIApA QCAtMTg3MCw2ICsxOTM4LDggQEAKIAllbXVfZnJlZShzYywgc2MtPm1lbS5wdGJfcGFnZXMpOwog CWVtdV9mcmVlKHNjLCBzYy0+bWVtLnNpbGVudF9wYWdlKTsKIAorCWlmKHNjLT5tcHUpCisJICAg IG1wdTQwMV91bmluaXQoc2MtPm1wdSk7CiAJcmV0dXJuIDA7CiB9CiAKQEAgLTE5NTgsNiArMjAy OCw4IEBACiAJZ290bWljID0gKGFjOTdfZ2V0Y2Fwcyhjb2RlYykgJiBBQzk3X0NBUF9NSUNDSEFO TkVMKSA/IDEgOiAwOwogCWlmIChtaXhlcl9pbml0KGRldiwgYWM5N19nZXRtaXhlcmNsYXNzKCks IGNvZGVjKSA9PSAtMSkgZ290byBiYWQ7CiAKKwllbXVfbWlkaWF0dGFjaChzYyk7CisKIAlpID0g MDsKIAlzYy0+aXJxID0gYnVzX2FsbG9jX3Jlc291cmNlX2FueShkZXYsIFNZU19SRVNfSVJRLCAm aSwKIAkgICAgUkZfQUNUSVZFIHwgUkZfU0hBUkVBQkxFKTsKQEAgLTIwMzUsNiArMjEwNyw3IEBA CiBEUklWRVJfTU9EVUxFKHNuZF9lbXUxMGsxLCBwY2ksIGVtdV9kcml2ZXIsIHBjbV9kZXZjbGFz cywgMCwgMCk7CiBNT0RVTEVfREVQRU5EKHNuZF9lbXUxMGsxLCBzb3VuZCwgU09VTkRfTUlOVkVS LCBTT1VORF9QUkVGVkVSLCBTT1VORF9NQVhWRVIpOwogTU9EVUxFX1ZFUlNJT04oc25kX2VtdTEw azEsIDEpOworTU9EVUxFX0RFUEVORChzbmRfZW11MTBrMSwgbWlkaSwgMSwgMSwgMSk7CiAKIC8q IGR1bW15IGRyaXZlciB0byBzaWxlbmNlIHRoZSBqb3lzdGljayBkZXZpY2UgKi8KIHN0YXRpYyBp bnQKSW5kZXg6IHN5cy9tb2R1bGVzL3NvdW5kL01ha2VmaWxlCj09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KUkNTIGZpbGU6 IC9ob21lL25jdnMvc3JjL3N5cy9tb2R1bGVzL3NvdW5kL01ha2VmaWxlLHYKcmV0cmlldmluZyBy ZXZpc2lvbiAxLjIKZGlmZiAtdSAtcjEuMiBNYWtlZmlsZQotLS0gc3lzL21vZHVsZXMvc291bmQv TWFrZWZpbGUJMTYgSnVsIDIwMDQgMDM6NTg6NDYgLTAwMDAJMS4yCisrKyBzeXMvbW9kdWxlcy9z b3VuZC9NYWtlZmlsZQk1IE1hciAyMDA1IDE2OjI3OjA3IC0wMDAwCkBAIC0zLDUgKzMsNiBAQAog U1VCRElSID0KIFNVQkRJUiArPSBzb3VuZAogU1VCRElSICs9IGRyaXZlcgorU1VCRElSICs9IG1p ZGkKIAogLmluY2x1ZGUgPGJzZC5zdWJkaXIubWs+CkluZGV4OiBzeXMvbW9kdWxlcy9zb3VuZC9k cml2ZXIvY21pL01ha2VmaWxlCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KUkNTIGZpbGU6IC9ob21lL25jdnMvc3JjL3N5 cy9tb2R1bGVzL3NvdW5kL2RyaXZlci9jbWkvTWFrZWZpbGUsdgpyZXRyaWV2aW5nIHJldmlzaW9u IDEuMwpkaWZmIC11IC1yMS4zIE1ha2VmaWxlCi0tLSBzeXMvbW9kdWxlcy9zb3VuZC9kcml2ZXIv Y21pL01ha2VmaWxlCTcgRmViIDIwMDMgMTM6NTY6MzEgLTAwMDAJMS4zCisrKyBzeXMvbW9kdWxl cy9zb3VuZC9kcml2ZXIvY21pL01ha2VmaWxlCTUgTWFyIDIwMDUgMTY6Mjc6MDcgLTAwMDAKQEAg LTQsNiArNCw3IEBACiAKIEtNT0Q9CXNuZF9jbWkKIFNSQ1M9CWRldmljZV9pZi5oIGJ1c19pZi5o IHBjaV9pZi5oCitTUkNTKz0gbXB1Zm9pX2lmLmgKIFNSQ1MrPQljbWkuYwogCiAuaW5jbHVkZSA8 YnNkLmttb2QubWs+CkluZGV4OiBzeXMvbW9kdWxlcy9zb3VuZC9kcml2ZXIvZW11MTBrMS9NYWtl ZmlsZQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09ClJDUyBmaWxlOiAvaG9tZS9uY3ZzL3NyYy9zeXMvbW9kdWxlcy9zb3Vu ZC9kcml2ZXIvZW11MTBrMS9NYWtlZmlsZSx2CnJldHJpZXZpbmcgcmV2aXNpb24gMS40CmRpZmYg LXUgLXIxLjQgTWFrZWZpbGUKLS0tIHN5cy9tb2R1bGVzL3NvdW5kL2RyaXZlci9lbXUxMGsxL01h a2VmaWxlCTExIEphbiAyMDA0IDEwOjMwOjU2IC0wMDAwCTEuNAorKysgc3lzL21vZHVsZXMvc291 bmQvZHJpdmVyL2VtdTEwazEvTWFrZWZpbGUJNSBNYXIgMjAwNSAxNjoyNzowNyAtMDAwMApAQCAt NSw2ICs1LDcgQEAKIAogS01PRD0Jc25kX2VtdTEwazEKIFNSQ1M9CWRldmljZV9pZi5oIGJ1c19p Zi5oIHBjaV9pZi5oIGVtdTEwazEtYWxzYSVkaWtlZC5oCitTUkNTKz0gbXB1Zm9pX2lmLmgKIFNS Q1MrPQllbXUxMGsxLmMKIAogQ0xFQU5GSUxFUys9IGVtdTEwazEtYWxzYSVkaWtlZC5oCkluZGV4 OiBzeXMvbW9kdWxlcy9zb3VuZC9taWRpL01ha2VmaWxlCj09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KUkNTIGZpbGU6IHN5 cy9tb2R1bGVzL3NvdW5kL21pZGkvTWFrZWZpbGUKZGlmZiAtTiBzeXMvbW9kdWxlcy9zb3VuZC9t aWRpL01ha2VmaWxlCi0tLSAvZGV2L251bGwJMSBKYW4gMTk3MCAwMDowMDowMCAtMDAwMAorKysg c3lzL21vZHVsZXMvc291bmQvbWlkaS9NYWtlZmlsZQk1IE1hciAyMDA1IDE2OjI3OjA3IC0wMDAw CkBAIC0wLDAgKzEsMTMgQEAKKyMgJEZyZWVCU0QkCisKKy5QQVRIOiAkey5DVVJESVJ9Ly4uLy4u Ly4uL2Rldi9zb3VuZC9taWRpCisKK0tNT0Q9CW1pZGkKKworU1JDUz0JbWlkaS5jIG1wdTQwMS5j IHNlcXVlbmNlci5jCitTUkNTKz0JZGV2aWNlX2lmLmggYnVzX2lmLmggbXB1X2lmLmggbXB1Zm9p X2lmLmggc3ludGhfaWYuaAorU1JDUys9CW1wdV9pZi5jIG1wdWZvaV9pZi5jIHN5bnRoX2lmLmMK KworRVhQT1JUX1NZTVM9CVlFUwkjIFhYWCBldmFsdWF0ZQorCisuaW5jbHVkZSA8YnNkLmttb2Qu bWs+Cg== --Multipart_Mon__25_Apr_2005_12_55_45_-0500_nfjSn6y19Y+G31aY-- From owner-freebsd-current@FreeBSD.ORG Mon Apr 25 17:56: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 612EC16A4D1; Mon, 25 Apr 2005 17:56:14 +0000 (GMT) Received: from mail.fci.fsu.edu (mail.fci.fsu.edu [128.186.195.169]) by mx1.FreeBSD.org (Postfix) with ESMTP id D521043D64; Mon, 25 Apr 2005 17:56:13 +0000 (GMT) (envelope-from neuro@mail.fci.fsu.edu) Received: from mail.fci.fsu.edu (mail.fci.fsu.edu [127.0.0.1]) by mail.fci.fsu.edu (Postfix) with ESMTP id 90638153F22; Mon, 25 Apr 2005 14:05:18 -0400 (EDT) Date: Mon, 25 Apr 2005 14:05:18 -0400 (EDT) From: neuro@mail.fci.fsu.edu To: Bill Paul In-Reply-To: <20050425171528.7EF8B16A4D3@hub.freebsd.org> Message-ID: References: <20050425171528.7EF8B16A4D3@hub.freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed cc: freebsd-current@freebsd.org cc: freebsd-hardware@freebsd.org Subject: Re: Too Evil, Too Furious X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 25 Apr 2005 17:56:14 -0000 Dear Bill Paul, I asked if you needed help earlier in programming project evil. I was wondering if you have a CVS repository of the code. Also, if I partake in this endeavour I will be able to supply you with the cards as I am doing research for my university I can order these as extras and ship them to you. We do a lot of opensource development. Hell I'll even purchase these out of pocket. I would like to help tell me what you need done and we'll figure something out... --sahil On Mon, 25 Apr 2005, Bill Paul wrote: > > Having reached yet another milestone of sorts in Project Evil develpment, > it's time once again to concentrate on cleaning up some of the rough spots. > This means fixing problems with cards/drivers that don't quite work right. > > Naturally, all the cards/drivers that people are having issues with are > ones that I don't have. Now, it doesn't do any good to just tell me that > your card/driver isn't working right: to fix the problem, whatever it is, > I need to experiment, and for that I need access to the hardware. No, I > won't send you patches to test. No, there isn't any debugging information > you can give me via e-mail that will help. No, I'm not kidding. > > The cards that I can't seem to get my hands on are: > > - Marvell wireless -- supposedly D-Link used this on a card called the > DWL-G510, but only on the first revision. The second board revision > uses an Atheros chipset, which is already supported. Unfortunately, aside > from this one PCI card, this chipset tends to only show up as a built-in > component on motherboards or laptops, which makes it hard for me to just > go out and get one. > > - Inprocomm wireless -- this chipset has been reported to work on i386, > but there's also an amd64 driver, and to date nobody has reported trying > it with FreeBSD/amd64. > > - AirGo Pre-N wireless -- there's apparently a Belkin cardbus card > (F5D8010?) that uses this one > > - RayLink RT2500 wireless -- this one shows up on some PCI cards, but > I haven't had any luck finding one locally yet > > The developers of the Marvell and Inprocomm drivers apparently chose > to use Microsoft structured exception handling (*sigh*), which is > interesting in that these devices have drivers for amd64 as well as > i386. From what I've read, Microsoft's amd64 implementation of SEH > should not cause any problems for Project Evil on amd64, but I haven't > personally tested it since the only card I have with an amd64 driver > is a Broadcom one. > > My problems with finding these cards locally are: > > - In-store selections around here really suck > - In many cases, the chips appear on only certain revs of a given > card, and either I can't find that rev, or the boxes aren't well > enough marked for me to figure out just which rev is inside > - Some of them show up most often as built-in devices, and I can't > go out and buy a new laptop or motherboard just to test one network > interface > > If you have one of these cards and would like to loan or donate it, we > at Project Evil Laboratories would be most appreciative. If you don't want > to part with your hardware, you can still help by giving me remote access > to a system with the card installed. Note that just giving me a shell > really doesn't help: in order to experiment, I need to be able to load, > test and unload kernel modules, which requires superuser access. The > ideal setup would be to use a serial console, since in some cases it > may be necessary to poke around with the kernel debugger. Don't consider > this unless you have a scratch box lying around that you can afford to > have bounced a few times, because I guarantee you I will crash the thing > a few times before I get it to work. > > Lastly, if you can't do either of these things, you can still help by > providing some important information. If you have one of these cards, > tell me where you got it! Tell me what manufacturer and model number > it is, but also carefully inspect the box it came in and tell me _ANY_ > identifying markings on it that will help me distinguish it from all > the other cards out there. Very often, card distributors will sell two > different cards with the same part number. (I own no less than 4 cards > called the "LinkSys LNE100TX," all of which have different chipsets on > them.) D-Link and Linksys are some of the worst offenders in this area. > Even worse, most PCI cards now have metal RF shields on them that > cover up the chipsets, which makes it impossible to tell what you're > getting just by looking at the picture on the box. > > Look for hardware revision info. Look for firmware revision info. If > you can provide a URL to the exact card you got from the place you > ordered it, even better. Whatever you do, don't just tell "I have > a D-Link model so-and-so." Instead, tell me "I have a D-Link model > so-and-so that I ordered from the following URL, and the box has > a sticker that says HW rev: B3 FW rev: 2.0." If I have info like this, > I can grab a card off a store shelf when I find the right one. Otherwise, > I can't take the chance on paying for it only to find out later it > uses a chipset I already have. > > If you want to donate/load a card to Project Evil, you can send it > to the following address: > > Attn: Bill Paul > Wind River Systems > 500 Wind River Way > Alameda, CA. 94501 > USA > > Bill's office phone number: 1 (510) 749-2329 > > Remember to include a note with your address so that the card can be > shipped back to you, and specify how soon you need the card back. All > loaned cards will be returned. > > -Bill > > -- > ============================================================================= > -Bill Paul (510) 749-2329 | Senior Engineer, Master of Unix-Fu > wpaul@windriver.com | Wind River Systems > ============================================================================= > you're just BEGGING to face the moose > ============================================================================= > _______________________________________________ > 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 25 18:01: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 0745C16A4CE for ; Mon, 25 Apr 2005 18:01:19 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id D8B0C43D49 for ; Mon, 25 Apr 2005 18:01:17 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 11757 invoked from network); 25 Apr 2005 18:02:23 -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 ; 25 Apr 2005 18:02:23 -0000 Message-ID: <426D306B.7010000@freebsd.org> Date: Mon, 25 Apr 2005 20:01:15 +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: Andre Oppermann References: <426426AE.2060406@uq.edu.au><42663EA1.3020409@uq.edu.au> <20050424150211.GA87520@walton.maths.tcd.ie> <426BC78A.3E56D99B@freebsd.org> <426C1600.106@uq.edu.au> <426D2307.97D15253@freebsd.org> In-Reply-To: <426D2307.97D15253@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: David Malone cc: qingli@freebsd.org cc: Matthew Sullivan cc: silby@freebsd.org cc: freebsd-current@freebsd.org Subject: Re: DF (Don't frag) issues X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 25 Apr 2005 18:01:19 -0000 Andre Oppermann wrote: > Matthew Sullivan wrote: > >>2/ The bug itself is also a problem, as it cannot be guarenteed that the >>host returning the ICMP 'need frag' will fill in a suggested mtu, so >>that also needs to be looked at (but I guess you know that already ;-)) > > I'm testing a fix right now. Unfortunatly the whole situation is a lot > more complex than thought at first. While stepping through the code > I found some other incorrect assumptions. Ok, I've put up a patch that should fix all issues: http://www.nrg4u.com/freebsd/icmp_df_pmtu-20050425.diff It does the following things: - Change icmp_error() to pass the MTU as an integer argument instead of the interface pointer. This gives much more flexibility for returning the MTU value for strange constructs and tunnel stuff. Even now it removes a nasty XXX hack in IPSEC support in ip_forward(). - Handling of received ICMP Needfrag messages. The logic was broken for the cases where the ICMP didn't contain a suggested value. This brokeness is in there since 5.2R and comes from my cleanup of the routing table and introduction of TCP hostcache. However there is no way to fix it at all. It was broken even before I broke it more. The idea behind the old code was to step down the MTU when we got a ICMP Needfrag by one step and try again. Unfortunatly it is very likely that the tcp window was open by a few segments already when we hit this. This gets us a number of those ICMP's in rapid succession each stepping us one down. Not good and MTU going down to 296 or even 64 bytes. There is no fix other than falling back to the default MTU if we get ICMP Needfrag without a suggested MTU in them. I have no idea how many devices send them without an MTU suggestion. Probably not many, if any. Qing, Silby, David, please have a look at the patch. -- Andre From owner-freebsd-current@FreeBSD.ORG Mon Apr 25 18:20: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 0465B16A508; Mon, 25 Apr 2005 18:20:37 +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 26DC143D49; Mon, 25 Apr 2005 18:20:34 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 6CECC513A7; Mon, 25 Apr 2005 11:20:33 -0700 (PDT) Date: Mon, 25 Apr 2005 11:20:33 -0700 From: Kris Kennaway To: Kirill Ponomarew Message-ID: <20050425182033.GC40370@xor.obsecurity.org> References: <20050425010242.GA44110@xor.obsecurity.org> <6.2.1.2.0.20050424210422.03d22990@64.7.153.2> <20050425014453.GA59981@xor.obsecurity.org> <426C6B1D.3040704@elischer.org> <20050425061459.GA33247@xor.obsecurity.org> <20050425062106.GB91852@voodoo.oberon.net> <426CF3DE.4000409@samsco.org> <20050425160146.4795fe1b.flynn@energyhq.es.eu.org> <426CF91A.8060907@samsco.org> <20050425144259.GL91852@voodoo.oberon.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="m51xatjYGsM+13rf" Content-Disposition: inline In-Reply-To: <20050425144259.GL91852@voodoo.oberon.net> User-Agent: Mutt/1.4.2.1i cc: current@freebsd.org cc: mike@sentex.net cc: freebsd-current@freebsd.org cc: julian@elischer.org cc: kris@obsecurity.org Subject: Re: GCC 4.0 [Re: FreeBSD 6 is coming too fast] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 25 Apr 2005 18:20:38 -0000 --m51xatjYGsM+13rf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Apr 25, 2005 at 04:43:00PM +0200, Kirill Ponomarew wrote: > On Mon, Apr 25, 2005 at 08:05:14AM -0600, Scott Long wrote: > > Well, I'd caution against jumping into GCC 4.0 just because of the > > claims of 25% speed improvement. That's about the single worst reason > > to do it. But if you're interested in moving the technology forward, > > I'd happily encourage you. The changed language constructs are the big > > problem (extern struct foo bar[]; is no longer valid) since you not only > > need to sweep the FreeBSD tree for them, you also need to sweep the > > ports tree. I have mixed feeling on the value of GCC making sloppy > > language extentions available for years and then suddenly revoking them, > > and I know others that have been affected by 4.0 aren't terribly happy > > either. >=20 > Well. if we're going to import it, it should be tested on pointyhat > first. IIRC Kris already run tests for some pre 4.0 versions. No, only for 3.4.4, which is going to be imported after I finish testing the latest patchset from kan. Kris --m51xatjYGsM+13rf Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFCbTTwWry0BWjoQKURAp9pAKDWIBVfdh86XAJiL+4L3qwYCgIEfACgw64m qCGC8h+BixdKC9V23rdBqNk= =Qz4K -----END PGP SIGNATURE----- --m51xatjYGsM+13rf-- From owner-freebsd-current@FreeBSD.ORG Mon Apr 25 18:20: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 0465B16A508; Mon, 25 Apr 2005 18:20:37 +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 26DC143D49; Mon, 25 Apr 2005 18:20:34 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 6CECC513A7; Mon, 25 Apr 2005 11:20:33 -0700 (PDT) Date: Mon, 25 Apr 2005 11:20:33 -0700 From: Kris Kennaway To: Kirill Ponomarew Message-ID: <20050425182033.GC40370@xor.obsecurity.org> References: <20050425010242.GA44110@xor.obsecurity.org> <6.2.1.2.0.20050424210422.03d22990@64.7.153.2> <20050425014453.GA59981@xor.obsecurity.org> <426C6B1D.3040704@elischer.org> <20050425061459.GA33247@xor.obsecurity.org> <20050425062106.GB91852@voodoo.oberon.net> <426CF3DE.4000409@samsco.org> <20050425160146.4795fe1b.flynn@energyhq.es.eu.org> <426CF91A.8060907@samsco.org> <20050425144259.GL91852@voodoo.oberon.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="m51xatjYGsM+13rf" Content-Disposition: inline In-Reply-To: <20050425144259.GL91852@voodoo.oberon.net> User-Agent: Mutt/1.4.2.1i cc: current@freebsd.org cc: mike@sentex.net cc: freebsd-current@freebsd.org cc: julian@elischer.org cc: kris@obsecurity.org Subject: Re: GCC 4.0 [Re: FreeBSD 6 is coming too fast] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 25 Apr 2005 18:20:38 -0000 --m51xatjYGsM+13rf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Apr 25, 2005 at 04:43:00PM +0200, Kirill Ponomarew wrote: > On Mon, Apr 25, 2005 at 08:05:14AM -0600, Scott Long wrote: > > Well, I'd caution against jumping into GCC 4.0 just because of the > > claims of 25% speed improvement. That's about the single worst reason > > to do it. But if you're interested in moving the technology forward, > > I'd happily encourage you. The changed language constructs are the big > > problem (extern struct foo bar[]; is no longer valid) since you not only > > need to sweep the FreeBSD tree for them, you also need to sweep the > > ports tree. I have mixed feeling on the value of GCC making sloppy > > language extentions available for years and then suddenly revoking them, > > and I know others that have been affected by 4.0 aren't terribly happy > > either. >=20 > Well. if we're going to import it, it should be tested on pointyhat > first. IIRC Kris already run tests for some pre 4.0 versions. No, only for 3.4.4, which is going to be imported after I finish testing the latest patchset from kan. Kris --m51xatjYGsM+13rf Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFCbTTwWry0BWjoQKURAp9pAKDWIBVfdh86XAJiL+4L3qwYCgIEfACgw64m qCGC8h+BixdKC9V23rdBqNk= =Qz4K -----END PGP SIGNATURE----- --m51xatjYGsM+13rf-- From owner-freebsd-current@FreeBSD.ORG Mon Apr 25 18:23: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 1E2FD16A4CE for ; Mon, 25 Apr 2005 18:23:45 +0000 (GMT) Received: from eva.fit.vutbr.cz (eva.fit.vutbr.cz [147.229.10.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4D48843D41 for ; Mon, 25 Apr 2005 18:23:42 +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 j3PINdi5012667 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Mon, 25 Apr 2005 20:23:39 +0200 (CEST) Received: (from xdivac02@localhost) by eva.fit.vutbr.cz (8.13.4/8.13.3/Submit) id j3PINdGi012665 for current@freebsd.org; Mon, 25 Apr 2005 20:23:39 +0200 (CEST) Date: Mon, 25 Apr 2005 20:23:39 +0200 From: Divacky Roman To: current@freebsd.org Message-ID: <20050425182339.GA10821@stud.fit.vutbr.cz> References: <6.2.1.2.0.20050424204611.072105a0@64.7.153.2> <20050425010242.GA44110@xor.obsecurity.org> <6.2.1.2.0.20050424210422.03d22990@64.7.153.2> <20050425014453.GA59981@xor.obsecurity.org> <426C6B1D.3040704@elischer.org> <20050425061459.GA33247@xor.obsecurity.org> <20050425062106.GB91852@voodoo.oberon.net> <426CF3DE.4000409@samsco.org> <20050425160146.4795fe1b.flynn@energyhq.es.eu.org> <426CF91A.8060907@samsco.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <426CF91A.8060907@samsco.org> User-Agent: Mutt/1.4.2i X-Scanned-By: MIMEDefang 2.49 on 147.229.10.14 Subject: Re: GCC 4.0 [Re: FreeBSD 6 is coming too fast] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 25 Apr 2005 18:23:45 -0000 On Mon, Apr 25, 2005 at 08:05:14AM -0600, Scott Long wrote: > Miguel Mendez wrote: > >On Mon, 25 Apr 2005 07:42:54 -0600 > >Scott Long wrote: > > > > > >>>According to gcc-4.0 release notes, compilation speed for C++ was > >>>dramatically increased, up to 25% IIRC. I think 4.0 is good > >>>candidate for merging into HEAD. > > > > > >>Is this work that you plan on doing for us? > > > > > >Definitely not for 6.0, and I usually avoid .0 releases on critical > >software, but nonetheless it would interesting setting a tinderbox, > >launch a buildworld process with gcc40 and see where/if it breaks. I > >have a spare k6-2 box I could setup for that task. > > > > > >>What about the deprecated language constructs in 4.0? gcc40 revelas some interesting "bugs" in the code... look at hysteria.sk/~neologism/ddb.patch which is 10 minutes try to build kernel with gcc40, look at the sigedness bug (at the bottom of the patch) which is not (I dont know why) revealed by current gcc we use I dont claim the patch is absolutely ok or solves anything but its nice to see > >According to http://gcc.gnu.org/gcc-4.0/changes.html, some of the > >deprecated constructs are not even valid C, so I see this as an > >opportunity to fix buggy code. > > > > > >>What about the lack of exposure that it's > >>had outside of the FSF and Apple development circles? I kinda like the way dfly treats this. they have/had two gccs in tree which allowed them for more smoother transition to the newer one.. > >Exactly the reason why testing will be beneficial. The more tested the > >product on FreeBSD the more robust it will be when it's time to get it > >into the tree. > > > >Cheers, > > Well, I'd caution against jumping into GCC 4.0 just because of the > claims of 25% speed improvement. That's about the single worst reason > to do it. But if you're interested in moving the technology forward, > I'd happily encourage you. The changed language constructs are the big > problem (extern struct foo bar[]; is no longer valid) since you not only > need to sweep the FreeBSD tree for them, you also need to sweep the > ports tree. I have mixed feeling on the value of GCC making sloppy > language extentions available for years and then suddenly revoking them, > and I know others that have been affected by 4.0 aren't terribly happy > either. we will have to import gcc4.x one day just because old gccs tends to be abandoned and not supported anymore. and I personally think that the new gcc is improvement... sure, some work is needed but its not that big deal as it might seem.. just my 2 cents roman From owner-freebsd-current@FreeBSD.ORG Mon Apr 25 18:37: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 1852116A4CE for ; Mon, 25 Apr 2005 18:37:42 +0000 (GMT) Received: from nala.dohd.org (xaa.demon.nl [83.160.166.71]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7D30843D53 for ; Mon, 25 Apr 2005 18:37:40 +0000 (GMT) (envelope-from freebsd@dohd.org) Received: from localhost (localhost.local.dohd.org [127.0.0.1]) by nala.dohd.org (Postfix) with ESMTP id 2E597117CC for ; Mon, 25 Apr 2005 20:37:39 +0200 (CEST) Received: from nala.dohd.org ([127.0.0.1]) by localhost (eeyore.local.dohd.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 25780-03-10 for ; Mon, 25 Apr 2005 20:37:33 +0200 (CEST) Received: by nala.dohd.org (Postfix, from userid 1008) id E32CF117CB; Mon, 25 Apr 2005 20:37:33 +0200 (CEST) Date: Mon, 25 Apr 2005 20:37:33 +0200 From: Mark Huizer To: current@freebsd.org Message-ID: <20050425183733.GB24146@eeyore.local.dohd.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="oLBj+sq0vYjzfsbl" Content-Disposition: inline User-Agent: Mutt/1.5.9i X-Virus-Scanned: amavisd-new at dohd.org Subject: fxp0: device timeout X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 25 Apr 2005 18:37:42 -0000 --oLBj+sq0vYjzfsbl Content-Type: text/plain; charset=us-ascii Content-Disposition: inline My server in the attic was recently reinstalled from scratch with FreeBSD 5.stable (actually: RC2, and now upgraded to 5-stable), see the attached dmesg.boot for the dmesg info. This machine in the exact hardware configuration was running fine in its 6-current days. The reason for 'down'grading was the fact that overtime it seems that a subtle filesystem problem arose, that lead to random crashes (well, random... take a lot of vm activity and at some point vnlru would lead to a kernel panic), but the network was perfectly fine. Now, with the 5.x install, I have regular problems with fxp0. In /var/log/messages and dmesg I get this: (The last line comes from ifconfig fxp0 link0, which I added yesterday to see if it would solve problems, the same symptoms occur without that option) Apr 25 18:15:08 eeyore kernel: fxp0: device timeout Apr 25 18:15:08 eeyore kernel: fxp0: Microcode loaded, int_delay: 1000 usec bundle_max: 0 The symptoms: * network freezes for 30 seconds or something like that, after a while pings start to work again and everything moves on. When: * combinations of network activity and/or disk activity. Starting bacula will guarantee device timeouts, as will browsing from a workstation combined with e.g. using a samba share The interface: fxp0: port 0xe000-0xe01f mem 0xe3000000-0xe30fffff,0xe3101000-0xe3101fff irq 5 at device 17.0 on pci0 miibus1: on fxp0 fxp0: flags=9843 mtu 1500 options=8 inet6 fe80::208:c7ff:fe25:7560%fxp0 prefixlen 64 scopeid 0x2 ether 00:50:da:3d:d7:f6 media: Ethernet autoselect (100baseTX ) status: active There are 2 'special' things with this interface: * the mac address is changed from /etc/start_if.fxp0 * it is used with VLAN's (802.1q tagging) I looked in the mail archives, and of course it is clearly an interrupt problem. I did the usual stuff: put the card in different PCI slots, force it to different IRQ in the BIOS, but still no improvement. Furthermore I don't believe that hardware should change that much just by reinstalling FreeBSD, so I tend to believe that something is different between 5.x and 6.x. Does anyone recognize these symptoms and have a nice solution for me? Or if people decide I should PR this: what kind of info would make debugging easy? vmstat 1 info would take a little work to collect for these kind of outages, but I can do some scripting to fix that of course :-) Greetings, Mark -- Nice testing in little China... --oLBj+sq0vYjzfsbl Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="dmesg.boot" 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-STABLE #1: Thu Apr 21 02:25:25 CEST 2005 xaa@eeyore.local.dohd.org:/usr/obj/usr/src/sys/eeyore Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD Athlon(tm) XP (1660.52-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x681 Stepping = 1 Features=0x383f9ff AMD Features=0xc0400000 real memory = 536805376 (511 MB) avail memory = 515637248 (491 MB) 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 0x4008-0x400b on acpi0 cpu0: on acpi0 acpi_throttle0: on cpu0 acpi_button0: on acpi0 acpi_button1: on acpi0 pcib0: port 0x6000-0x607f,0x5000-0x500f,0x4080-0x40ff,0x4000-0x407f,0xcf8-0xcff on acpi0 pci0: on pcib0 agp0: mem 0xd0000000-0xd7ffffff at device 0.0 on pci0 pcib1: at device 1.0 on pci0 pci1: on pcib1 pci1: at device 0.0 (no driver attached) isab0: at device 7.0 on pci0 isa0: on isab0 atapci0: port 0xc000-0xc00f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 7.1 on pci0 atapci0: Correcting VIA config for southbridge data corruption bug ata0: channel #0 on atapci0 ata1: channel #1 on atapci0 uhci0: port 0xc400-0xc41f irq 10 at device 7.2 on pci0 usb0: on uhci0 usb0: USB revision 1.0 uhub0: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1: port 0xc800-0xc81f irq 10 at device 7.3 on pci0 usb1: on uhci1 usb1: USB revision 1.0 uhub1: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered pci0: at device 7.4 (no driver attached) sym0: <810a> port 0xd800-0xd8ff mem 0xe3100000-0xe31000ff irq 11 at device 15.0 on pci0 sym0: Symbios NVRAM, ID 7, Fast-10, SE, parity checking sym0: open drain IRQ line driver sym0: using LOAD/STORE-based firmware. xl0: <3Com 3c905C-TX Fast Etherlink XL> port 0xdc00-0xdc7f mem 0xe3102000-0xe310207f irq 10 at device 16.0 on pci0 miibus0: on xl0 ukphy0: on miibus0 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto xl0: Ethernet address: 00:04:75:c4:f4:43 fxp0: port 0xe000-0xe01f mem 0xe3000000-0xe30fffff,0xe3101000-0xe3101fff irq 5 at device 17.0 on pci0 miibus1: on fxp0 inphy0: on miibus1 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp0: Ethernet address: 00:08:c7:25:75:60 rl0: port 0xe400-0xe4ff mem 0xe3103000-0xe31030ff irq 12 at device 18.0 on pci0 miibus2: on rl0 rlphy0: on miibus2 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto rl0: Ethernet address: 00:50:fc:0b:28:ec pci0: at device 19.0 (no driver attached) fdc0: port 0x3f7,0x3f0-0x3f5 irq 6 drq 2 on acpi0 fd0: <1440-KB 3.5" drive> on fdc0 drive 0 sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A ppc0: port 0x378-0x37f irq 7 on acpi0 ppc0: Generic chipset (EPP/NIBBLE) in COMPATIBLE mode ppbus0: on ppc0 plip0: on ppbus0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 atkbdc0: port 0x64,0x60 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 orm0: at iomem 0xd1000-0xd17ff,0xd0000-0xd07ff on isa0 pmtimer0 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Timecounter "TSC" frequency 1660518050 Hz quality 800 Timecounters tick every 10.000 msec IP Filter: v3.4.35 initialized. Default = block all, Logging = enabled ad0: 38166MB [77545/16/63] at ata0-master UDMA100 acd0: CDROM at ata1-slave PIO4 Waiting 10 seconds for SCSI devices to settle (noperiph:sym0:0:-1:-1): SCSI BUS reset delivered. sa0 at sym0 bus 0 target 0 lun 0 sa0: Removable Sequential Access SCSI-2 device sa0: 10.000MB/s transfers (10.000MHz, offset 8) Mounting root from ufs:/dev/ad0s1a --oLBj+sq0vYjzfsbl-- From owner-freebsd-current@FreeBSD.ORG Mon Apr 25 18:53: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 66F6C16A4CE; Mon, 25 Apr 2005 18:53:50 +0000 (GMT) Received: from voodoo.oberon.net (voodoo.oberon.net [212.118.165.100]) by mx1.FreeBSD.org (Postfix) with ESMTP id 027EC43D55; Mon, 25 Apr 2005 18:53:50 +0000 (GMT) (envelope-from krion@voodoo.oberon.net) Received: from krion by voodoo.oberon.net with local (Exim 4.50 (FreeBSD)) id 1DQ8iL-0007bh-1g; Mon, 25 Apr 2005 20:53:49 +0200 Date: Mon, 25 Apr 2005 20:53:49 +0200 From: Kirill Ponomarew To: Kris Kennaway Message-ID: <20050425185349.GD25681@voodoo.oberon.net> References: <6.2.1.2.0.20050424210422.03d22990@64.7.153.2> <20050425014453.GA59981@xor.obsecurity.org> <426C6B1D.3040704@elischer.org> <20050425061459.GA33247@xor.obsecurity.org> <20050425062106.GB91852@voodoo.oberon.net> <426CF3DE.4000409@samsco.org> <20050425160146.4795fe1b.flynn@energyhq.es.eu.org> <426CF91A.8060907@samsco.org> <20050425144259.GL91852@voodoo.oberon.net> <20050425182033.GC40370@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050425182033.GC40370@xor.obsecurity.org> X-NCC-Regid: de.oberon X-NIC-HDL: KP869-RIPE cc: julian@elischer.org cc: freebsd-current@freebsd.org cc: current@freebsd.org cc: mike@sentex.net Subject: Re: GCC 4.0 [Re: FreeBSD 6 is coming too fast] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 25 Apr 2005 18:53:50 -0000 On Mon, Apr 25, 2005 at 11:20:33AM -0700, Kris Kennaway wrote: > On Mon, Apr 25, 2005 at 04:43:00PM +0200, Kirill Ponomarew wrote: > > On Mon, Apr 25, 2005 at 08:05:14AM -0600, Scott Long wrote: > > > Well, I'd caution against jumping into GCC 4.0 just because of the > > > claims of 25% speed improvement. That's about the single worst reason > > > to do it. But if you're interested in moving the technology forward, > > > I'd happily encourage you. The changed language constructs are the big > > > problem (extern struct foo bar[]; is no longer valid) since you not only > > > need to sweep the FreeBSD tree for them, you also need to sweep the > > > ports tree. I have mixed feeling on the value of GCC making sloppy > > > language extentions available for years and then suddenly revoking them, > > > and I know others that have been affected by 4.0 aren't terribly happy > > > either. > > > > Well. if we're going to import it, it should be tested on pointyhat > > first. IIRC Kris already run tests for some pre 4.0 versions. > > No, only for 3.4.4, which is going to be imported after I finish > testing the latest patchset from kan. Erm, is 3.4.4 already released, I couldn't find it on their page: http://www.gnu.org/software/gcc/releases.html -Kirill From owner-freebsd-current@FreeBSD.ORG Mon Apr 25 18:53: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 66F6C16A4CE; Mon, 25 Apr 2005 18:53:50 +0000 (GMT) Received: from voodoo.oberon.net (voodoo.oberon.net [212.118.165.100]) by mx1.FreeBSD.org (Postfix) with ESMTP id 027EC43D55; Mon, 25 Apr 2005 18:53:50 +0000 (GMT) (envelope-from krion@voodoo.oberon.net) Received: from krion by voodoo.oberon.net with local (Exim 4.50 (FreeBSD)) id 1DQ8iL-0007bh-1g; Mon, 25 Apr 2005 20:53:49 +0200 Date: Mon, 25 Apr 2005 20:53:49 +0200 From: Kirill Ponomarew To: Kris Kennaway Message-ID: <20050425185349.GD25681@voodoo.oberon.net> References: <6.2.1.2.0.20050424210422.03d22990@64.7.153.2> <20050425014453.GA59981@xor.obsecurity.org> <426C6B1D.3040704@elischer.org> <20050425061459.GA33247@xor.obsecurity.org> <20050425062106.GB91852@voodoo.oberon.net> <426CF3DE.4000409@samsco.org> <20050425160146.4795fe1b.flynn@energyhq.es.eu.org> <426CF91A.8060907@samsco.org> <20050425144259.GL91852@voodoo.oberon.net> <20050425182033.GC40370@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050425182033.GC40370@xor.obsecurity.org> X-NCC-Regid: de.oberon X-NIC-HDL: KP869-RIPE cc: julian@elischer.org cc: freebsd-current@freebsd.org cc: current@freebsd.org cc: mike@sentex.net Subject: Re: GCC 4.0 [Re: FreeBSD 6 is coming too fast] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 25 Apr 2005 18:53:50 -0000 On Mon, Apr 25, 2005 at 11:20:33AM -0700, Kris Kennaway wrote: > On Mon, Apr 25, 2005 at 04:43:00PM +0200, Kirill Ponomarew wrote: > > On Mon, Apr 25, 2005 at 08:05:14AM -0600, Scott Long wrote: > > > Well, I'd caution against jumping into GCC 4.0 just because of the > > > claims of 25% speed improvement. That's about the single worst reason > > > to do it. But if you're interested in moving the technology forward, > > > I'd happily encourage you. The changed language constructs are the big > > > problem (extern struct foo bar[]; is no longer valid) since you not only > > > need to sweep the FreeBSD tree for them, you also need to sweep the > > > ports tree. I have mixed feeling on the value of GCC making sloppy > > > language extentions available for years and then suddenly revoking them, > > > and I know others that have been affected by 4.0 aren't terribly happy > > > either. > > > > Well. if we're going to import it, it should be tested on pointyhat > > first. IIRC Kris already run tests for some pre 4.0 versions. > > No, only for 3.4.4, which is going to be imported after I finish > testing the latest patchset from kan. Erm, is 3.4.4 already released, I couldn't find it on their page: http://www.gnu.org/software/gcc/releases.html -Kirill From owner-freebsd-current@FreeBSD.ORG Mon Apr 25 18:56: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 DF05016A545 for ; Mon, 25 Apr 2005 18:56:03 +0000 (GMT) Received: from voodoo.oberon.net (voodoo.oberon.net [212.118.165.100]) by mx1.FreeBSD.org (Postfix) with ESMTP id 99EA943D53 for ; Mon, 25 Apr 2005 18:56:03 +0000 (GMT) (envelope-from krion@voodoo.oberon.net) Received: from krion by voodoo.oberon.net with local (Exim 4.50 (FreeBSD)) id 1DQ8kV-0007d3-2O; Mon, 25 Apr 2005 20:56:03 +0200 Date: Mon, 25 Apr 2005 20:56:03 +0200 From: Kirill Ponomarew To: Marcel Moolenaar Message-ID: <20050425185603.GE25681@voodoo.oberon.net> References: <6.2.1.2.0.20050424210422.03d22990@64.7.153.2> <20050425014453.GA59981@xor.obsecurity.org> <426C6B1D.3040704@elischer.org> <20050425061459.GA33247@xor.obsecurity.org> <20050425062106.GB91852@voodoo.oberon.net> <426CF3DE.4000409@samsco.org> <20050425144108.GK91852@voodoo.oberon.net> <426D0252.5050805@samsco.org> <20050425145206.GM91852@voodoo.oberon.net> <657be6bca0955ea1d1571a92f074e43f@xcllnt.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <657be6bca0955ea1d1571a92f074e43f@xcllnt.net> X-NCC-Regid: de.oberon X-NIC-HDL: KP869-RIPE cc: Julian Elischer cc: Kris Kennaway cc: current@freebsd.org cc: Mike Tancsa Subject: Re: FreeBSD 6 is coming too fast X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 25 Apr 2005 18:56:04 -0000 On Mon, Apr 25, 2005 at 09:23:42AM -0700, Marcel Moolenaar wrote: > >25% faster to compile the code, not running it. > > Not to pick on you, Kirill, but rather in general: > > That entirely depends on the optimization level and the configuration. > I measured a small degradation (<5%) at -O3 on ia64. So, let's find > out how the 25% compile-time performance improvement was achieved before > we use it as an argument in any discussion, shall we? The above statement was just the info from their release notes, so, of course, additional benchmarks are necessary. -Kirill From owner-freebsd-current@FreeBSD.ORG Mon Apr 25 18:56: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 3010316A4CE for ; Mon, 25 Apr 2005 18:56:17 +0000 (GMT) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1598D43D45 for ; Mon, 25 Apr 2005 18:56:17 +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 1DQ8ki-000A2Z-PH; Mon, 25 Apr 2005 18:56:16 +0000 Received: from [127.0.0.1] (helo=roam.psg.com.psg.com) by roam.psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DQ8kh-0002HQ-LW; Mon, 25 Apr 2005 08:56:15 -1000 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17005.15695.142230.959400@roam.psg.com> Date: Mon, 25 Apr 2005 08:56:15 -1000 To: Ted Faber References: <17001.42481.325920.113852@roam.psg.com> <20050425151443.GA1523@pun.isi.edu> cc: FreeBSD Current Subject: Re: disk freeze? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 25 Apr 2005 18:56:17 -0000 > It seems to happen more frequently on my desktop which NFS mounts most > of its filesystems (with -L). fwiw, my systems do not use nfs, not even compiled in randy From owner-freebsd-current@FreeBSD.ORG Mon Apr 25 18:58: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 F1A7516A4CE; Mon, 25 Apr 2005 18:58:26 +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 6CEE643D5D; Mon, 25 Apr 2005 18:58:26 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 920495132F; Mon, 25 Apr 2005 11:58:25 -0700 (PDT) Date: Mon, 25 Apr 2005 11:58:25 -0700 From: Kris Kennaway To: Kirill Ponomarew Message-ID: <20050425185825.GB43216@xor.obsecurity.org> References: <20050425014453.GA59981@xor.obsecurity.org> <426C6B1D.3040704@elischer.org> <20050425061459.GA33247@xor.obsecurity.org> <20050425062106.GB91852@voodoo.oberon.net> <426CF3DE.4000409@samsco.org> <20050425160146.4795fe1b.flynn@energyhq.es.eu.org> <426CF91A.8060907@samsco.org> <20050425144259.GL91852@voodoo.oberon.net> <20050425182033.GC40370@xor.obsecurity.org> <20050425185349.GD25681@voodoo.oberon.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="neYutvxvOLaeuPCA" Content-Disposition: inline In-Reply-To: <20050425185349.GD25681@voodoo.oberon.net> User-Agent: Mutt/1.4.2.1i cc: julian@elischer.org cc: mike@sentex.net cc: current@freebsd.org cc: freebsd-current@freebsd.org cc: Kris Kennaway Subject: Re: GCC 4.0 [Re: FreeBSD 6 is coming too fast] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 25 Apr 2005 18:58:27 -0000 --neYutvxvOLaeuPCA Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Apr 25, 2005 at 08:53:49PM +0200, Kirill Ponomarew wrote: > On Mon, Apr 25, 2005 at 11:20:33AM -0700, Kris Kennaway wrote: > > On Mon, Apr 25, 2005 at 04:43:00PM +0200, Kirill Ponomarew wrote: > > > On Mon, Apr 25, 2005 at 08:05:14AM -0600, Scott Long wrote: > > > > Well, I'd caution against jumping into GCC 4.0 just because of the > > > > claims of 25% speed improvement. That's about the single worst rea= son > > > > to do it. But if you're interested in moving the technology forwar= d, > > > > I'd happily encourage you. The changed language constructs are the= big > > > > problem (extern struct foo bar[]; is no longer valid) since you not= only > > > > need to sweep the FreeBSD tree for them, you also need to sweep the > > > > ports tree. I have mixed feeling on the value of GCC making sloppy > > > > language extentions available for years and then suddenly revoking = them, > > > > and I know others that have been affected by 4.0 aren't terribly ha= ppy > > > > either. > > >=20 > > > Well. if we're going to import it, it should be tested on pointyhat > > > first. IIRC Kris already run tests for some pre 4.0 versions. > >=20 > > No, only for 3.4.4, which is going to be imported after I finish > > testing the latest patchset from kan. >=20 > Erm, is 3.4.4 already released, I couldn't find it on their page: >=20 > http://www.gnu.org/software/gcc/releases.html It's probably a snapshot then. See the patchset in www.freebsd.org/~kan Kris --neYutvxvOLaeuPCA Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFCbT3RWry0BWjoQKURAl5hAJ46nmoYBc3jmjxHo7nLsAJ979V/oACgtu2m oXHaoHDIS74NUq+VPkX9Y9E= =nkUo -----END PGP SIGNATURE----- --neYutvxvOLaeuPCA-- From owner-freebsd-current@FreeBSD.ORG Mon Apr 25 18:58: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 F1A7516A4CE; Mon, 25 Apr 2005 18:58:26 +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 6CEE643D5D; Mon, 25 Apr 2005 18:58:26 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 920495132F; Mon, 25 Apr 2005 11:58:25 -0700 (PDT) Date: Mon, 25 Apr 2005 11:58:25 -0700 From: Kris Kennaway To: Kirill Ponomarew Message-ID: <20050425185825.GB43216@xor.obsecurity.org> References: <20050425014453.GA59981@xor.obsecurity.org> <426C6B1D.3040704@elischer.org> <20050425061459.GA33247@xor.obsecurity.org> <20050425062106.GB91852@voodoo.oberon.net> <426CF3DE.4000409@samsco.org> <20050425160146.4795fe1b.flynn@energyhq.es.eu.org> <426CF91A.8060907@samsco.org> <20050425144259.GL91852@voodoo.oberon.net> <20050425182033.GC40370@xor.obsecurity.org> <20050425185349.GD25681@voodoo.oberon.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="neYutvxvOLaeuPCA" Content-Disposition: inline In-Reply-To: <20050425185349.GD25681@voodoo.oberon.net> User-Agent: Mutt/1.4.2.1i cc: julian@elischer.org cc: mike@sentex.net cc: current@freebsd.org cc: freebsd-current@freebsd.org cc: Kris Kennaway Subject: Re: GCC 4.0 [Re: FreeBSD 6 is coming too fast] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 25 Apr 2005 18:58:27 -0000 --neYutvxvOLaeuPCA Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Apr 25, 2005 at 08:53:49PM +0200, Kirill Ponomarew wrote: > On Mon, Apr 25, 2005 at 11:20:33AM -0700, Kris Kennaway wrote: > > On Mon, Apr 25, 2005 at 04:43:00PM +0200, Kirill Ponomarew wrote: > > > On Mon, Apr 25, 2005 at 08:05:14AM -0600, Scott Long wrote: > > > > Well, I'd caution against jumping into GCC 4.0 just because of the > > > > claims of 25% speed improvement. That's about the single worst rea= son > > > > to do it. But if you're interested in moving the technology forwar= d, > > > > I'd happily encourage you. The changed language constructs are the= big > > > > problem (extern struct foo bar[]; is no longer valid) since you not= only > > > > need to sweep the FreeBSD tree for them, you also need to sweep the > > > > ports tree. I have mixed feeling on the value of GCC making sloppy > > > > language extentions available for years and then suddenly revoking = them, > > > > and I know others that have been affected by 4.0 aren't terribly ha= ppy > > > > either. > > >=20 > > > Well. if we're going to import it, it should be tested on pointyhat > > > first. IIRC Kris already run tests for some pre 4.0 versions. > >=20 > > No, only for 3.4.4, which is going to be imported after I finish > > testing the latest patchset from kan. >=20 > Erm, is 3.4.4 already released, I couldn't find it on their page: >=20 > http://www.gnu.org/software/gcc/releases.html It's probably a snapshot then. See the patchset in www.freebsd.org/~kan Kris --neYutvxvOLaeuPCA Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFCbT3RWry0BWjoQKURAl5hAJ46nmoYBc3jmjxHo7nLsAJ979V/oACgtu2m oXHaoHDIS74NUq+VPkX9Y9E= =nkUo -----END PGP SIGNATURE----- --neYutvxvOLaeuPCA-- From owner-freebsd-current@FreeBSD.ORG Mon Apr 25 18:59: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 DC5D216A4DE for ; Mon, 25 Apr 2005 18:59:33 +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 72A4B43D31 for ; Mon, 25 Apr 2005 18:59:33 +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 1DQ8ns-000JXj-Is; Mon, 25 Apr 2005 21:59:32 +0300 X-Mailer: exmh version 2.7.0 06/18/2004 with nmh-1.0.4 To: Jeff Behl In-reply-to: Your message of Mon, 25 Apr 2005 10:28:59 -0700 . Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 25 Apr 2005 21:59:32 +0300 From: Danny Braniss Message-ID: cc: current@freebsd.org Subject: Re: serial/ether console & ramblings X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 25 Apr 2005 18:59:34 -0000 > Eric Anderson wrote: > > > Danny Braniss wrote: > > > >> hi, > >> I was about to plunge in and 'try' to cleanup the serial console > >> stuff, when it downed on me that newer machines are arriving without > >> serial > >> port! there goes that idea. So USB/serial dongle came to mind, might > >> work, but messy, FireWire is not universaly available. > >> So, why not serial over ethernet? IPMI 'was' to have solved > >> this, but it will (if at all) work on server class MB only, and im still > >> looking for a Unix Viewer. > >> > >> In my case, i have been using the serial console to debug stuff, but > >> being of the old school, i try to stay away from debuggers :-), so > >> printf and stack trace will do. > >> > >> So here are some of my quesions: > >> o - is there some standard? ok, refrase, are there some > >> standards? > >> o - any WIP?, i'm checking out Robert Watson's ethercons > >> o - any great ideas? > > > > > > There are a couple of ports that seem to try to use IPMI. I haven't > > tried them yet though. (sysutils/freeipmi and sysutils/ipmitool). > > > > I can tell you that being about to do serial over ethernet (and > > possibly power cycling) would be incredibly handy. > > > > Eric > > > > > > > NIC drivers have to be made aware of IPMI in order for it to function > when a shared NIC is used. This is not the case with the bge driver, at > the very least. See: > > http://lists.freebsd.org/mailman/htdig/freebsd-net/2005-March/thread.html#6725 > > This is also a very big issue for us and we're considering hiring a > contractor to get the relevant parts put into the driver... > i guess IPMI means different things to different people. if it's hardware (not a software emulation), then it has some nice things: 1 - fiddling with the box from far away, without intervention of the OS, like 1.1 - turning off (sometimes on will work too :-), 1.2 - turning on/off the id light- cool if you have many boxes - i used to laugh at this, till i found out that on some u1 boxes there is no place to put a label in the back. 1.3- finding out all kind of stuff, like when was the box assembled, etc. 2- SOL, serial over lan: if this would realy work, then no need for all the cables/kvm etc. point 1.1 and 1.2 is done, so we can via a cli do those things, but it only saves a trip to the computer room. 1.3 is for the nit-picky, i have some 60 u1's, and knowing the status of the FRUs is not that helpful. point 2, on the other hand is exiting, not only because of the cabling, but being able to access the console when needed, without having to connect the serail port (which are disappearing). so is there a client for SOL that runs under FreeBSD? (either IPMI 1.5 or 2.0) danny From owner-freebsd-current@FreeBSD.ORG Mon Apr 25 19:01: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 DF55F16A4CE for ; Mon, 25 Apr 2005 19:01:16 +0000 (GMT) Received: from voodoo.oberon.net (voodoo.oberon.net [212.118.165.100]) by mx1.FreeBSD.org (Postfix) with ESMTP id 980CC43D39 for ; Mon, 25 Apr 2005 19:01:16 +0000 (GMT) (envelope-from krion@voodoo.oberon.net) Received: from krion by voodoo.oberon.net with local (Exim 4.50 (FreeBSD)) id 1DQ8pY-0007hB-Bs; Mon, 25 Apr 2005 21:01:16 +0200 Date: Mon, 25 Apr 2005 21:01:16 +0200 From: Kirill Ponomarew To: Kris Kennaway Message-ID: <20050425190116.GF25681@voodoo.oberon.net> References: <426C6B1D.3040704@elischer.org> <20050425061459.GA33247@xor.obsecurity.org> <20050425062106.GB91852@voodoo.oberon.net> <426CF3DE.4000409@samsco.org> <20050425160146.4795fe1b.flynn@energyhq.es.eu.org> <426CF91A.8060907@samsco.org> <20050425144259.GL91852@voodoo.oberon.net> <20050425182033.GC40370@xor.obsecurity.org> <20050425185349.GD25681@voodoo.oberon.net> <20050425185825.GB43216@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050425185825.GB43216@xor.obsecurity.org> X-NCC-Regid: de.oberon X-NIC-HDL: KP869-RIPE cc: freebsd-current@freebsd.org cc: julian@elischer.org cc: mike@sentex.net Subject: Re: GCC 4.0 [Re: FreeBSD 6 is coming too fast] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 25 Apr 2005 19:01:17 -0000 On Mon, Apr 25, 2005 at 11:58:25AM -0700, Kris Kennaway wrote: > > Erm, is 3.4.4 already released, I couldn't find it on their page: > > > > http://www.gnu.org/software/gcc/releases.html > > It's probably a snapshot then. See the patchset in > www.freebsd.org/~kan Ah ok. It would be also interesting to know the differences between 3.4.2 and 3.4.4 though. -Kirill From owner-freebsd-current@FreeBSD.ORG Mon Apr 25 19:06: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 B6C9116A4CE for ; Mon, 25 Apr 2005 19:06:20 +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 7119A43D4C for ; Mon, 25 Apr 2005 19:06:20 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id A3817514FE; Mon, 25 Apr 2005 12:06:19 -0700 (PDT) Date: Mon, 25 Apr 2005 12:06:19 -0700 From: Kris Kennaway To: Kirill Ponomarew Message-ID: <20050425190619.GA45535@xor.obsecurity.org> References: <20050425061459.GA33247@xor.obsecurity.org> <20050425062106.GB91852@voodoo.oberon.net> <426CF3DE.4000409@samsco.org> <20050425160146.4795fe1b.flynn@energyhq.es.eu.org> <426CF91A.8060907@samsco.org> <20050425144259.GL91852@voodoo.oberon.net> <20050425182033.GC40370@xor.obsecurity.org> <20050425185349.GD25681@voodoo.oberon.net> <20050425185825.GB43216@xor.obsecurity.org> <20050425190116.GF25681@voodoo.oberon.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="d6Gm4EdcadzBjdND" Content-Disposition: inline In-Reply-To: <20050425190116.GF25681@voodoo.oberon.net> User-Agent: Mutt/1.4.2.1i cc: mike@sentex.net cc: julian@elischer.org cc: freebsd-current@freebsd.org cc: Kris Kennaway Subject: Re: GCC 4.0 [Re: FreeBSD 6 is coming too fast] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 25 Apr 2005 19:06:20 -0000 --d6Gm4EdcadzBjdND Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Apr 25, 2005 at 09:01:16PM +0200, Kirill Ponomarew wrote: > On Mon, Apr 25, 2005 at 11:58:25AM -0700, Kris Kennaway wrote: > > > Erm, is 3.4.4 already released, I couldn't find it on their page: > > >=20 > > > http://www.gnu.org/software/gcc/releases.html > >=20 > > It's probably a snapshot then. See the patchset in > > www.freebsd.org/~kan >=20 > Ah ok. It would be also interesting to know the differences between > 3.4.2 and 3.4.4 though. See the patchset :P Kris --d6Gm4EdcadzBjdND Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFCbT+qWry0BWjoQKURAkbPAKCegFhr/vYLyBPff0jr++g8zMXohACfd7Tu t+FyGCDybvemRLiWgmvBPeU= =gSCz -----END PGP SIGNATURE----- --d6Gm4EdcadzBjdND-- From owner-freebsd-current@FreeBSD.ORG Mon Apr 25 19:12: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 03DB116A4CE for ; Mon, 25 Apr 2005 19:12:28 +0000 (GMT) Received: from sb.santaba.com (sb.santaba.com [207.154.84.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9DB3843D5C for ; Mon, 25 Apr 2005 19:12:27 +0000 (GMT) (envelope-from jbehl@fastclick.com) Received: from [192.168.3.100] (unknown [205.180.85.193]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sb.santaba.com (Postfix) with ESMTP id 6D9EA2848C; Mon, 25 Apr 2005 12:12:27 -0700 (PDT) Message-ID: <426D4179.1020508@fastclick.com> Date: Mon, 25 Apr 2005 12:14:01 -0700 From: Jeff Behl User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Danny Braniss References: In-Reply-To: X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit cc: current@freebsd.org Subject: Re: serial/ether console & ramblings X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 25 Apr 2005 19:12:28 -0000 Danny Braniss wrote: >>Eric Anderson wrote: >> >> >> >>>Danny Braniss wrote: >>> >>> >>> >>>>hi, >>>> I was about to plunge in and 'try' to cleanup the serial console >>>>stuff, when it downed on me that newer machines are arriving without >>>>serial >>>>port! there goes that idea. So USB/serial dongle came to mind, might >>>>work, but messy, FireWire is not universaly available. >>>>So, why not serial over ethernet? IPMI 'was' to have solved >>>>this, but it will (if at all) work on server class MB only, and im still >>>>looking for a Unix Viewer. >>>> >>>> In my case, i have been using the serial console to debug stuff, but >>>>being of the old school, i try to stay away from debuggers :-), so >>>>printf and stack trace will do. >>>> >>>> So here are some of my quesions: >>>> o - is there some standard? ok, refrase, are there some >>>> standards? >>>> o - any WIP?, i'm checking out Robert Watson's ethercons >>>> o - any great ideas? >>>> >>>> >>>There are a couple of ports that seem to try to use IPMI. I haven't >>>tried them yet though. (sysutils/freeipmi and sysutils/ipmitool). >>> >>>I can tell you that being about to do serial over ethernet (and >>>possibly power cycling) would be incredibly handy. >>> >>>Eric >>> >>> >>> >>> >>> >>NIC drivers have to be made aware of IPMI in order for it to function >>when a shared NIC is used. This is not the case with the bge driver, at >>the very least. See: >> >>http://lists.freebsd.org/mailman/htdig/freebsd-net/2005-March/thread.html#6725 >> >>This is also a very big issue for us and we're considering hiring a >>contractor to get the relevant parts put into the driver... >> >> >> >i guess IPMI means different things to different people. >if it's hardware (not a software emulation), then it has some nice things: >1 - fiddling with the box from far away, without intervention > of the OS, like > 1.1 - turning off (sometimes on will work too :-), > 1.2 - turning on/off the id light- cool if you have many boxes - i used > to laugh at this, till i found out that on some u1 boxes there is > no place to put a label in the back. > 1.3- finding out all kind of stuff, like when was the box assembled, > etc. >2- SOL, serial over lan: if this would realy work, then no need for > all the cables/kvm etc. > >point 1.1 and 1.2 is done, so we can via a cli do those things, but it only >saves a trip to the computer room. 1.3 is for the nit-picky, i have some >60 u1's, and knowing the status of the FRUs is not that helpful. > >point 2, on the other hand is exiting, not only because of the cabling, but >being able to access the console when needed, without having to connect the >serail port (which are disappearing). > >so is there a client for SOL that runs under FreeBSD? >(either IPMI 1.5 or 2.0) > >danny > > > > > but my whole point is that nothing in 1) works remotely (out of band) when the system and the BMC share the same ethernet controller, at least with the bge driver. as i mentioned in the thread, i can power cycle and see the serial console remotely (number 2 from above) all the way up to the point where the kernel loads. as soon as it does, the bge driver no longer shunts off RMCP packets (what IPMI uses) to the Baseboard Management Controller, so no IPMI... http://lists.freebsd.org/mailman/htdig/freebsd-net/2005-March/006725.html i'm by no means an expert on this, but i believe it is why IPMI doesn't work in our situation (IBM e325/6 servers). jeff From owner-freebsd-current@FreeBSD.ORG Mon Apr 25 19:17: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 1B43916A4CE for ; Mon, 25 Apr 2005 19:17:45 +0000 (GMT) Received: from fast.dnswatch.com (fast.dnswatch.com [216.177.243.43]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5C9AC43D4C for ; Mon, 25 Apr 2005 19:17:44 +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 j3PJHgsm049271 for ; Mon, 25 Apr 2005 12:17:43 -0700 (PDT) (envelope-from null@dnswatch.com) Received: (from www@localhost) by fast.dnswatch.com (8.12.6/8.12.6/Submit) id j3PJHfP4049270; Mon, 25 Apr 2005 12:17:41 -0700 (PDT) (envelope-from null@dnswatch.com) X-Authentication-Warning: fast.dnswatch.com: www set sender to null@dnswatch.com using -f Received: from ns0.1command.com ([216.177.243.38]) (DNSwatch.com_WebMail authenticated user null) by webmail.dnswatch.com with HTTP; Mon, 25 Apr 2005 12:17:40 -0700 (PDT) Message-ID: <2308.216.177.243.38.1114456660.localmail@webmail.dnswatch.com> In-Reply-To: <20050425171528.7EF8B16A4D3@hub.freebsd.org> References: <20050425171528.7EF8B16A4D3@hub.freebsd.org> Date: Mon, 25 Apr 2005 12:17:40 -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: Too Evil, Too Furious X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 25 Apr 2005 19:17:45 -0000 I see there are about 50 D-Link DWL-G510 802.11g Wireless PCI Adapter Cards available on Ebay. They aren't but about $16.00 US. I'd be willing to pick one up and send it to you. What do I need to ask the seller to ensure that I get the right one? I haven't tried looking for the other cards on your list yet. But I got to thinking that most of the sellers on Ebay are pretty helpful. So if one wanted to know about the card they are selling - where they got it, what it looks like, etc... that might be an added resource in helping you in your quest. I was also wondering if Project Evil will suport the Compaq 32-bit NetFlex-2 controllers? I got a Compaq EISA box some time ago and a whole bunch of the Netflex-2 cards with the intention of making a FreeBSD Switch out of it. But I wasn't thinking or I wouldn't have *assumed* that FBSD supported the Netflex-2 card. Anyway, still have all the eqpt. and think it would be a worthy project that I'd love to complete. Oh, one more thing; if it would be of any help, I can cough up an IP and a remote box that you can have *complete* control of if you like. -Chris > > Having reached yet another milestone of sorts in Project Evil develpment, > it's time once again to concentrate on cleaning up some of the rough > spots. > This means fixing problems with cards/drivers that don't quite work right. > > Naturally, all the cards/drivers that people are having issues with are > ones that I don't have. Now, it doesn't do any good to just tell me that > your card/driver isn't working right: to fix the problem, whatever it is, > I need to experiment, and for that I need access to the hardware. No, I > won't send you patches to test. No, there isn't any debugging information > you can give me via e-mail that will help. No, I'm not kidding. > > The cards that I can't seem to get my hands on are: > > - Marvell wireless -- supposedly D-Link used this on a card called the > DWL-G510, but only on the first revision. The second board revision > uses an Atheros chipset, which is already supported. Unfortunately, > aside > from this one PCI card, this chipset tends to only show up as a built-in > component on motherboards or laptops, which makes it hard for me to just > go out and get one. > > - Inprocomm wireless -- this chipset has been reported to work on i386, > but there's also an amd64 driver, and to date nobody has reported trying > it with FreeBSD/amd64. > > - AirGo Pre-N wireless -- there's apparently a Belkin cardbus card > (F5D8010?) that uses this one > > - RayLink RT2500 wireless -- this one shows up on some PCI cards, but > I haven't had any luck finding one locally yet > > The developers of the Marvell and Inprocomm drivers apparently chose > to use Microsoft structured exception handling (*sigh*), which is > interesting in that these devices have drivers for amd64 as well as > i386. From what I've read, Microsoft's amd64 implementation of SEH > should not cause any problems for Project Evil on amd64, but I haven't > personally tested it since the only card I have with an amd64 driver > is a Broadcom one. > > My problems with finding these cards locally are: > > - In-store selections around here really suck > - In many cases, the chips appear on only certain revs of a given > card, and either I can't find that rev, or the boxes aren't well > enough marked for me to figure out just which rev is inside > - Some of them show up most often as built-in devices, and I can't > go out and buy a new laptop or motherboard just to test one network > interface > > If you have one of these cards and would like to loan or donate it, we > at Project Evil Laboratories would be most appreciative. If you don't want > to part with your hardware, you can still help by giving me remote access > to a system with the card installed. Note that just giving me a shell > really doesn't help: in order to experiment, I need to be able to load, > test and unload kernel modules, which requires superuser access. The > ideal setup would be to use a serial console, since in some cases it > may be necessary to poke around with the kernel debugger. Don't consider > this unless you have a scratch box lying around that you can afford to > have bounced a few times, because I guarantee you I will crash the thing > a few times before I get it to work. > > Lastly, if you can't do either of these things, you can still help by > providing some important information. If you have one of these cards, > tell me where you got it! Tell me what manufacturer and model number > it is, but also carefully inspect the box it came in and tell me _ANY_ > identifying markings on it that will help me distinguish it from all > the other cards out there. Very often, card distributors will sell two > different cards with the same part number. (I own no less than 4 cards > called the "LinkSys LNE100TX," all of which have different chipsets on > them.) D-Link and Linksys are some of the worst offenders in this area. > Even worse, most PCI cards now have metal RF shields on them that > cover up the chipsets, which makes it impossible to tell what you're > getting just by looking at the picture on the box. > > Look for hardware revision info. Look for firmware revision info. If > you can provide a URL to the exact card you got from the place you > ordered it, even better. Whatever you do, don't just tell "I have > a D-Link model so-and-so." Instead, tell me "I have a D-Link model > so-and-so that I ordered from the following URL, and the box has > a sticker that says HW rev: B3 FW rev: 2.0." If I have info like this, > I can grab a card off a store shelf when I find the right one. Otherwise, > I can't take the chance on paying for it only to find out later it > uses a chipset I already have. > > If you want to donate/load a card to Project Evil, you can send it > to the following address: > > Attn: Bill Paul > Wind River Systems > 500 Wind River Way > Alameda, CA. 94501 > USA > > Bill's office phone number: 1 (510) 749-2329 > > Remember to include a note with your address so that the card can be > shipped back to you, and specify how soon you need the card back. All > loaned cards will be returned. > > -Bill > > -- > ============================================================================= > -Bill Paul (510) 749-2329 | Senior Engineer, Master of Unix-Fu > wpaul@windriver.com | Wind River Systems > ============================================================================= > you're just BEGGING to face the moose > ============================================================================= > _______________________________________________ > 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 Mon Apr 25 19:23: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 C11B516A4CE; Mon, 25 Apr 2005 19:23:00 +0000 (GMT) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3A6D043D53; Mon, 25 Apr 2005 19:23:00 +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 j3PJMx7B094197; Mon, 25 Apr 2005 15:22:59 -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 j3PJNSBW079055; Mon, 25 Apr 2005 15:23:28 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 7BC657306E; Mon, 25 Apr 2005 15:22:59 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050425192259.7BC657306E@freebsd-current.sentex.ca> Date: Mon, 25 Apr 2005 15:22:59 -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 alpha/alpha 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, 25 Apr 2005 19:23:00 -0000 TB --- 2005-04-25 19:15:00 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-04-25 19:15:00 - starting CURRENT tinderbox run for alpha/alpha TB --- 2005-04-25 19:15:00 - checking out the source tree TB --- 2005-04-25 19:15:00 - cd /home/tinderbox/CURRENT/alpha/alpha TB --- 2005-04-25 19:15:00 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-04-25 19:21:47 - building world (CFLAGS=-O2 -pipe) TB --- 2005-04-25 19:21:47 - cd /home/tinderbox/CURRENT/alpha/alpha/src TB --- 2005-04-25 19:21: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 [...] ===> rescue/rescue/ipf/ippool (cleandir) rm -f ippool_y.c ippool_y.h ippool_l.c ippool_l.h y.tab.c y.tab.h ippool ippool_y.o ippool_l.o kmem.o ippool.o ippool.5.gz ippool.8.gz ippool.5.cat.gz ippool.8.cat.gz rm -f .depend GPATH GRTAGS GSYMS GTAGS ===> rescue/rescue/ipf/ipresend (cleandir) rm -f y.tab.c y.tab.h ipresend ipresend.o ip.o resend.o sbpf.o sock.o 44arp.o ipresend.1.gz ipresend.1.cat.gz rm -f .depend GPATH GRTAGS GSYMS GTAGS cd /tinderbox/CURRENT/alpha/alpha/src/rescue/rescue/../../sbin/ipfs && MAKEOBJDIRPREFIX=/home/tinderbox/CURRENT/alpha/alpha/obj/alpha/tinderbox/CURRENT/alpha/alpha/src/rescue/rescue /home/tinderbox/CURRENT/alpha/alpha/obj/tinderbox/CURRENT/alpha/alpha/src/make.i386/make DIRPRFX=rescue/rescue/ipfs/ cleandir cd: can't cd to /tinderbox/CURRENT/alpha/alpha/src/rescue/rescue/../../sbin/ipfs *** Error code 2 Stop in /tinderbox/CURRENT/alpha/alpha/src/rescue/rescue. *** Error code 1 Stop in /tinderbox/CURRENT/alpha/alpha/src/rescue. *** Error code 1 Stop in /tinderbox/CURRENT/alpha/alpha/src. *** Error code 1 Stop in /tinderbox/CURRENT/alpha/alpha/src. *** Error code 1 Stop in /tinderbox/CURRENT/alpha/alpha/src. TB --- 2005-04-25 19:22:59 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-04-25 19:22:59 - ERROR: failed to build world TB --- 2005-04-25 19:22:59 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Mon Apr 25 19: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 A069516A4D0; Mon, 25 Apr 2005 19:26:43 +0000 (GMT) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7A80A43D5D; Mon, 25 Apr 2005 19:26:38 +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 j3PJQS27094501; Mon, 25 Apr 2005 15:26:28 -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 j3PJQSwo066039; Mon, 25 Apr 2005 15:26:28 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 804967306E; Mon, 25 Apr 2005 15:26:28 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050425192628.804967306E@freebsd-current.sentex.ca> Date: Mon, 25 Apr 2005 15:26:28 -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 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: Mon, 25 Apr 2005 19:26:43 -0000 TB --- 2005-04-25 19:22:59 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-04-25 19:22:59 - starting CURRENT tinderbox run for amd64/amd64 TB --- 2005-04-25 19:22:59 - checking out the source tree TB --- 2005-04-25 19:22:59 - cd /home/tinderbox/CURRENT/amd64/amd64 TB --- 2005-04-25 19:22:59 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-04-25 19:25:21 - building world (CFLAGS=-O2 -pipe) TB --- 2005-04-25 19:25:21 - cd /home/tinderbox/CURRENT/amd64/amd64/src TB --- 2005-04-25 19: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 [...] ===> rescue/rescue/ipf/ippool (cleandir) rm -f ippool_y.c ippool_y.h ippool_l.c ippool_l.h y.tab.c y.tab.h ippool ippool_y.o ippool_l.o kmem.o ippool.o ippool.5.gz ippool.8.gz ippool.5.cat.gz ippool.8.cat.gz rm -f .depend GPATH GRTAGS GSYMS GTAGS ===> rescue/rescue/ipf/ipresend (cleandir) rm -f y.tab.c y.tab.h ipresend ipresend.o ip.o resend.o sbpf.o sock.o 44arp.o ipresend.1.gz ipresend.1.cat.gz rm -f .depend GPATH GRTAGS GSYMS GTAGS cd /tinderbox/CURRENT/amd64/amd64/src/rescue/rescue/../../sbin/ipfs && MAKEOBJDIRPREFIX=/home/tinderbox/CURRENT/amd64/amd64/obj/amd64/tinderbox/CURRENT/amd64/amd64/src/rescue/rescue /home/tinderbox/CURRENT/amd64/amd64/obj/tinderbox/CURRENT/amd64/amd64/src/make.i386/make DIRPRFX=rescue/rescue/ipfs/ cleandir cd: can't cd to /tinderbox/CURRENT/amd64/amd64/src/rescue/rescue/../../sbin/ipfs *** Error code 2 Stop in /tinderbox/CURRENT/amd64/amd64/src/rescue/rescue. *** Error code 1 Stop in /tinderbox/CURRENT/amd64/amd64/src/rescue. *** 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-25 19:26:28 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-04-25 19:26:28 - ERROR: failed to build world TB --- 2005-04-25 19:26:28 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Mon Apr 25 19:31: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 E148116A4CE for ; Mon, 25 Apr 2005 19:31:35 +0000 (GMT) Received: from anuket.mj.niksun.com (gwnew.niksun.com [65.115.46.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id C731143D2F for ; Mon, 25 Apr 2005 19:31:32 +0000 (GMT) (envelope-from jkim@niksun.com) Received: from [10.70.0.244] (daemon.mj.niksun.com [10.70.0.244]) by anuket.mj.niksun.com (8.13.1/8.13.1) with ESMTP id j3PJVXJV054644; Mon, 25 Apr 2005 15:31:35 -0400 (EDT) (envelope-from jkim@niksun.com) From: Jung-uk Kim Organization: Niksun, Inc. To: freebsd-current@freebsd.org Date: Mon, 25 Apr 2005 15:31:03 -0400 User-Agent: KMail/1.6.2 References: <426C6B1D.3040704@elischer.org> <20050425185825.GB43216@xor.obsecurity.org> <20050425190116.GF25681@voodoo.oberon.net> In-Reply-To: <20050425190116.GF25681@voodoo.oberon.net> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200504251531.03095.jkim@niksun.com> X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on anuket.mj.niksun.com X-Virus-Status: Clean cc: mike@sentex.net cc: julian@elischer.org cc: Kirill Ponomarew cc: Kris Kennaway Subject: Re: GCC 4.0 [Re: FreeBSD 6 is coming too fast] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 25 Apr 2005 19:31:36 -0000 On Monday 25 April 2005 03:01 pm, Kirill Ponomarew wrote: > On Mon, Apr 25, 2005 at 11:58:25AM -0700, Kris Kennaway wrote: > > > Erm, is 3.4.4 already released, I couldn't find it on their > > > page: > > > > > > http://www.gnu.org/software/gcc/releases.html > > > > It's probably a snapshot then. See the patchset in > > www.freebsd.org/~kan > > Ah ok. It would be also interesting to know the differences > between 3.4.2 and 3.4.4 though. ChangeLog diff (GCC 3.4.2-20040728 vs. kan's patch): http://savannah.gnu.org/cgi-bin/viewcvs/gcc/gcc/gcc/ChangeLog.diff?r1=2.2326.2.839&r2=2.2326.2.569&diff_format=u Jung-uk Kim > -Kirill From owner-freebsd-current@FreeBSD.ORG Mon Apr 25 19:32: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 4F7BB16A4CE; Mon, 25 Apr 2005 19:32:31 +0000 (GMT) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id BE85843D3F; Mon, 25 Apr 2005 19:32:30 +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 j3PJWUoH094943; Mon, 25 Apr 2005 15:32:30 -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 j3PJWwIO084289; Mon, 25 Apr 2005 15:32:58 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 1FFCE7306E; Mon, 25 Apr 2005 15:32:30 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050425193230.1FFCE7306E@freebsd-current.sentex.ca> Date: Mon, 25 Apr 2005 15:32:30 -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 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: Mon, 25 Apr 2005 19:32:31 -0000 TB --- 2005-04-25 19:26:28 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-04-25 19:26:28 - starting CURRENT tinderbox run for i386/i386 TB --- 2005-04-25 19:26:28 - checking out the source tree TB --- 2005-04-25 19:26:28 - cd /home/tinderbox/CURRENT/i386/i386 TB --- 2005-04-25 19:26:28 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-04-25 19:31:21 - building world (CFLAGS=-O2 -pipe) TB --- 2005-04-25 19:31:21 - cd /home/tinderbox/CURRENT/i386/i386/src TB --- 2005-04-25 19:31: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 [...] ===> rescue/rescue/ipf/ippool (cleandir) rm -f ippool_y.c ippool_y.h ippool_l.c ippool_l.h y.tab.c y.tab.h ippool ippool_y.o ippool_l.o kmem.o ippool.o ippool.5.gz ippool.8.gz ippool.5.cat.gz ippool.8.cat.gz rm -f .depend GPATH GRTAGS GSYMS GTAGS ===> rescue/rescue/ipf/ipresend (cleandir) rm -f y.tab.c y.tab.h ipresend ipresend.o ip.o resend.o sbpf.o sock.o 44arp.o ipresend.1.gz ipresend.1.cat.gz rm -f .depend GPATH GRTAGS GSYMS GTAGS cd /tinderbox/CURRENT/i386/i386/src/rescue/rescue/../../sbin/ipfs && MAKEOBJDIRPREFIX=/home/tinderbox/CURRENT/i386/i386/obj/tinderbox/CURRENT/i386/i386/src/rescue/rescue /home/tinderbox/CURRENT/i386/i386/obj/tinderbox/CURRENT/i386/i386/src/make.i386/make DIRPRFX=rescue/rescue/ipfs/ cleandir cd: can't cd to /tinderbox/CURRENT/i386/i386/src/rescue/rescue/../../sbin/ipfs *** Error code 2 Stop in /tinderbox/CURRENT/i386/i386/src/rescue/rescue. *** Error code 1 Stop in /tinderbox/CURRENT/i386/i386/src/rescue. *** 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-25 19:32:30 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-04-25 19:32:30 - ERROR: failed to build world TB --- 2005-04-25 19:32:30 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Mon Apr 25 19:33: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 A493816A4CE for ; Mon, 25 Apr 2005 19:33:44 +0000 (GMT) Received: from fast.dnswatch.com (fast.dnswatch.com [216.177.243.43]) by mx1.FreeBSD.org (Postfix) with ESMTP id 211AF43D68 for ; Mon, 25 Apr 2005 19:33:44 +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 j3PJXZsm049474; Mon, 25 Apr 2005 12:33:36 -0700 (PDT) (envelope-from null@dnswatch.com) Received: (from www@localhost) by fast.dnswatch.com (8.12.6/8.12.6/Submit) id j3PJXX5Y049473; Mon, 25 Apr 2005 12:33:33 -0700 (PDT) (envelope-from null@dnswatch.com) X-Authentication-Warning: fast.dnswatch.com: www set sender to null@dnswatch.com using -f Received: from ns0.1command.com ([216.177.243.38]) (DNSwatch.com_WebMail authenticated user null) by webmail.dnswatch.com with HTTP; Mon, 25 Apr 2005 12:33:32 -0700 (PDT) Message-ID: <2323.216.177.243.38.1114457612.localmail@webmail.dnswatch.com> In-Reply-To: <20050425183733.GB24146@eeyore.local.dohd.org> References: <20050425183733.GB24146@eeyore.local.dohd.org> Date: Mon, 25 Apr 2005 12:33:32 -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: fxp0: device timeout X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 25 Apr 2005 19:33:44 -0000 I don't want to sound like a smart a$$, or know-it-all. But could this not also be a simple case of Induction? Is it possible that something has changed in the environment that might interfere with the NIC or cabling? I mean it wouldn't have to completely clobber the connection, but simply impeed it slightly, which would make it crap out under any type of load. Just thought I'd mention it FWIW. -Chris > My server in the attic was recently reinstalled from scratch with > FreeBSD 5.stable (actually: RC2, and now upgraded to 5-stable), see the > attached dmesg.boot for the dmesg info. > > This machine in the exact hardware configuration was running fine in its > 6-current days. The reason for 'down'grading was the fact that overtime > it seems that a subtle filesystem problem arose, that lead to random > crashes (well, random... take a lot of vm activity and at some point > vnlru would lead to a kernel panic), but the network was perfectly fine. > > Now, with the 5.x install, I have regular problems with fxp0. > > In /var/log/messages and dmesg I get this: > (The last line comes from ifconfig fxp0 link0, which I added yesterday > to see if it would solve problems, the same symptoms occur without that > option) > > Apr 25 18:15:08 eeyore kernel: fxp0: device timeout > Apr 25 18:15:08 eeyore kernel: fxp0: Microcode loaded, int_delay: 1000 > usec bundle_max: 0 > > The symptoms: > * network freezes for 30 seconds or something like that, after a while > pings start to work again and everything moves on. > > When: > * combinations of network activity and/or disk activity. Starting bacula > will guarantee device timeouts, as will browsing from a workstation > combined > with e.g. using a samba share > > The interface: > > fxp0: port 0xe000-0xe01f mem > 0xe3000000-0xe30fffff,0xe3101000-0xe3101fff irq 5 at device 17.0 on pci0 > miibus1: on fxp0 > > fxp0: flags=9843 mtu 1500 > options=8 > inet6 fe80::208:c7ff:fe25:7560%fxp0 prefixlen 64 scopeid 0x2 > ether 00:50:da:3d:d7:f6 > media: Ethernet autoselect (100baseTX ) > status: active > > There are 2 'special' things with this interface: > * the mac address is changed from /etc/start_if.fxp0 > * it is used with VLAN's (802.1q tagging) > > I looked in the mail archives, and of course it is clearly an interrupt > problem. I did the usual stuff: put the card in different PCI slots, > force it to different IRQ in the BIOS, but still no improvement. > Furthermore I don't believe that hardware should change that much just > by reinstalling FreeBSD, so I tend to believe that something is > different between 5.x and 6.x. > > Does anyone recognize these symptoms and have a nice solution for me? > Or if people decide I should PR this: what kind of info would make > debugging easy? vmstat 1 info would take a little work to collect for > these kind of outages, but I can do some scripting to fix that of course > :-) > > Greetings, > > Mark > -- > Nice testing in little China... > _______________________________________________ > 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 Mon Apr 25 19:36: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 CD99716A4CE; Mon, 25 Apr 2005 19:36:57 +0000 (GMT) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1947E43D5E; Mon, 25 Apr 2005 19:36:57 +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 j3PJauCd002803; Mon, 25 Apr 2005 15:36:56 -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 j3PJauAv015000; Mon, 25 Apr 2005 15:36:56 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 262E37306E; Mon, 25 Apr 2005 15:36:56 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050425193656.262E37306E@freebsd-current.sentex.ca> Date: Mon, 25 Apr 2005 15:36:56 -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 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: Mon, 25 Apr 2005 19:36:58 -0000 TB --- 2005-04-25 19:32:30 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-04-25 19:32:30 - starting CURRENT tinderbox run for i386/pc98 TB --- 2005-04-25 19:32:30 - checking out the source tree TB --- 2005-04-25 19:32:30 - cd /home/tinderbox/CURRENT/i386/pc98 TB --- 2005-04-25 19:32:30 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-04-25 19:35:43 - building world (CFLAGS=-O2 -pipe) TB --- 2005-04-25 19:35:43 - cd /home/tinderbox/CURRENT/i386/pc98/src TB --- 2005-04-25 19:35:43 - /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 [...] ===> rescue/rescue/ipf/ippool (cleandir) rm -f ippool_y.c ippool_y.h ippool_l.c ippool_l.h y.tab.c y.tab.h ippool ippool_y.o ippool_l.o kmem.o ippool.o ippool.5.gz ippool.8.gz ippool.5.cat.gz ippool.8.cat.gz rm -f .depend GPATH GRTAGS GSYMS GTAGS ===> rescue/rescue/ipf/ipresend (cleandir) rm -f y.tab.c y.tab.h ipresend ipresend.o ip.o resend.o sbpf.o sock.o 44arp.o ipresend.1.gz ipresend.1.cat.gz rm -f .depend GPATH GRTAGS GSYMS GTAGS cd /tinderbox/CURRENT/i386/pc98/src/rescue/rescue/../../sbin/ipfs && MAKEOBJDIRPREFIX=/home/tinderbox/CURRENT/i386/pc98/obj/pc98/tinderbox/CURRENT/i386/pc98/src/rescue/rescue /home/tinderbox/CURRENT/i386/pc98/obj/tinderbox/CURRENT/i386/pc98/src/make.i386/make DIRPRFX=rescue/rescue/ipfs/ cleandir cd: can't cd to /tinderbox/CURRENT/i386/pc98/src/rescue/rescue/../../sbin/ipfs *** Error code 2 Stop in /tinderbox/CURRENT/i386/pc98/src/rescue/rescue. *** Error code 1 Stop in /tinderbox/CURRENT/i386/pc98/src/rescue. *** 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-25 19:36:56 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-04-25 19:36:56 - ERROR: failed to build world TB --- 2005-04-25 19:36:56 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Mon Apr 25 19:42: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 018F516A4CE; Mon, 25 Apr 2005 19:42:02 +0000 (GMT) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7481343D4C; Mon, 25 Apr 2005 19:42:01 +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 j3PJg16q003188; Mon, 25 Apr 2005 15:42:01 -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 j3PJgTX4090051; Mon, 25 Apr 2005 15:42:29 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id AD8527306E; Mon, 25 Apr 2005 15:42:00 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050425194200.AD8527306E@freebsd-current.sentex.ca> Date: Mon, 25 Apr 2005 15:42: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 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: Mon, 25 Apr 2005 19:42:02 -0000 TB --- 2005-04-25 19:36:56 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-04-25 19:36:56 - starting CURRENT tinderbox run for ia64/ia64 TB --- 2005-04-25 19:36:56 - checking out the source tree TB --- 2005-04-25 19:36:56 - cd /home/tinderbox/CURRENT/ia64/ia64 TB --- 2005-04-25 19:36:56 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-04-25 19:40:49 - building world (CFLAGS=-O2 -pipe) TB --- 2005-04-25 19:40:49 - cd /home/tinderbox/CURRENT/ia64/ia64/src TB --- 2005-04-25 19:40:49 - /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 [...] ===> rescue/rescue/ipf/ippool (cleandir) rm -f ippool_y.c ippool_y.h ippool_l.c ippool_l.h y.tab.c y.tab.h ippool ippool_y.o ippool_l.o kmem.o ippool.o ippool.5.gz ippool.8.gz ippool.5.cat.gz ippool.8.cat.gz rm -f .depend GPATH GRTAGS GSYMS GTAGS ===> rescue/rescue/ipf/ipresend (cleandir) rm -f y.tab.c y.tab.h ipresend ipresend.o ip.o resend.o sbpf.o sock.o 44arp.o ipresend.1.gz ipresend.1.cat.gz rm -f .depend GPATH GRTAGS GSYMS GTAGS cd /tinderbox/CURRENT/ia64/ia64/src/rescue/rescue/../../sbin/ipfs && MAKEOBJDIRPREFIX=/home/tinderbox/CURRENT/ia64/ia64/obj/ia64/tinderbox/CURRENT/ia64/ia64/src/rescue/rescue /home/tinderbox/CURRENT/ia64/ia64/obj/tinderbox/CURRENT/ia64/ia64/src/make.i386/make DIRPRFX=rescue/rescue/ipfs/ cleandir cd: can't cd to /tinderbox/CURRENT/ia64/ia64/src/rescue/rescue/../../sbin/ipfs *** Error code 2 Stop in /tinderbox/CURRENT/ia64/ia64/src/rescue/rescue. *** Error code 1 Stop in /tinderbox/CURRENT/ia64/ia64/src/rescue. *** Error code 1 Stop in /tinderbox/CURRENT/ia64/ia64/src. *** Error code 1 Stop in /tinderbox/CURRENT/ia64/ia64/src. *** Error code 1 Stop in /tinderbox/CURRENT/ia64/ia64/src. TB --- 2005-04-25 19:42:00 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-04-25 19:42:00 - ERROR: failed to build world TB --- 2005-04-25 19:42:00 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Mon Apr 25 19:47: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 1C66416A4CE; Mon, 25 Apr 2005 19:47:18 +0000 (GMT) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7BC0C43D39; Mon, 25 Apr 2005 19:47:17 +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 j3PJlHYE003519; Mon, 25 Apr 2005 15:47: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 j3PJlj9F093082; Mon, 25 Apr 2005 15:47:45 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id D78587306E; Mon, 25 Apr 2005 15:47:16 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050425194716.D78587306E@freebsd-current.sentex.ca> Date: Mon, 25 Apr 2005 15:47:16 -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: Mon, 25 Apr 2005 19:47:18 -0000 TB --- 2005-04-25 19:42:00 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-04-25 19:42:00 - starting CURRENT tinderbox run for powerpc/powerpc TB --- 2005-04-25 19:42:00 - checking out the source tree TB --- 2005-04-25 19:42:00 - cd /home/tinderbox/CURRENT/powerpc/powerpc TB --- 2005-04-25 19:42:00 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-04-25 19:46:00 - building world (CFLAGS=-O2 -pipe) TB --- 2005-04-25 19:46:00 - cd /home/tinderbox/CURRENT/powerpc/powerpc/src TB --- 2005-04-25 19:46:00 - /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 [...] ===> rescue/rescue/ipf/ippool (cleandir) rm -f ippool_y.c ippool_y.h ippool_l.c ippool_l.h y.tab.c y.tab.h ippool ippool_y.o ippool_l.o kmem.o ippool.o ippool.5.gz ippool.8.gz ippool.5.cat.gz ippool.8.cat.gz rm -f .depend GPATH GRTAGS GSYMS GTAGS ===> rescue/rescue/ipf/ipresend (cleandir) rm -f y.tab.c y.tab.h ipresend ipresend.o ip.o resend.o sbpf.o sock.o 44arp.o ipresend.1.gz ipresend.1.cat.gz rm -f .depend GPATH GRTAGS GSYMS GTAGS cd /tinderbox/CURRENT/powerpc/powerpc/src/rescue/rescue/../../sbin/ipfs && MAKEOBJDIRPREFIX=/home/tinderbox/CURRENT/powerpc/powerpc/obj/powerpc/tinderbox/CURRENT/powerpc/powerpc/src/rescue/rescue /home/tinderbox/CURRENT/powerpc/powerpc/obj/tinderbox/CURRENT/powerpc/powerpc/src/make.i386/make DIRPRFX=rescue/rescue/ipfs/ cleandir cd: can't cd to /tinderbox/CURRENT/powerpc/powerpc/src/rescue/rescue/../../sbin/ipfs *** Error code 2 Stop in /tinderbox/CURRENT/powerpc/powerpc/src/rescue/rescue. *** Error code 1 Stop in /tinderbox/CURRENT/powerpc/powerpc/src/rescue. *** Error code 1 Stop in /tinderbox/CURRENT/powerpc/powerpc/src. *** Error code 1 Stop in /tinderbox/CURRENT/powerpc/powerpc/src. *** Error code 1 Stop in /tinderbox/CURRENT/powerpc/powerpc/src. TB --- 2005-04-25 19:47:16 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-04-25 19:47:16 - ERROR: failed to build world TB --- 2005-04-25 19:47:16 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Mon Apr 25 19:52: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 1FBAC16A4CE; Mon, 25 Apr 2005 19:52:20 +0000 (GMT) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9197743D39; Mon, 25 Apr 2005 19:52:19 +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 j3PJqEXg003875; Mon, 25 Apr 2005 15:52: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 j3PJqg3f095846; Mon, 25 Apr 2005 15:52:42 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id D002C7306E; Mon, 25 Apr 2005 15:52:13 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050425195213.D002C7306E@freebsd-current.sentex.ca> Date: Mon, 25 Apr 2005 15:52:13 -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 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, 25 Apr 2005 19:52:20 -0000 TB --- 2005-04-25 19:47:17 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-04-25 19:47:17 - starting CURRENT tinderbox run for sparc64/sparc64 TB --- 2005-04-25 19:47:17 - checking out the source tree TB --- 2005-04-25 19:47:17 - cd /home/tinderbox/CURRENT/sparc64/sparc64 TB --- 2005-04-25 19:47:17 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-04-25 19:51:01 - building world (CFLAGS=-O2 -pipe) TB --- 2005-04-25 19:51:01 - cd /home/tinderbox/CURRENT/sparc64/sparc64/src TB --- 2005-04-25 19:51:01 - /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 [...] ===> rescue/rescue/ipf/ippool (cleandir) rm -f ippool_y.c ippool_y.h ippool_l.c ippool_l.h y.tab.c y.tab.h ippool ippool_y.o ippool_l.o kmem.o ippool.o ippool.5.gz ippool.8.gz ippool.5.cat.gz ippool.8.cat.gz rm -f .depend GPATH GRTAGS GSYMS GTAGS ===> rescue/rescue/ipf/ipresend (cleandir) rm -f y.tab.c y.tab.h ipresend ipresend.o ip.o resend.o sbpf.o sock.o 44arp.o ipresend.1.gz ipresend.1.cat.gz rm -f .depend GPATH GRTAGS GSYMS GTAGS cd /tinderbox/CURRENT/sparc64/sparc64/src/rescue/rescue/../../sbin/ipfs && MAKEOBJDIRPREFIX=/home/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/tinderbox/CURRENT/sparc64/sparc64/src/rescue/rescue /home/tinderbox/CURRENT/sparc64/sparc64/obj/tinderbox/CURRENT/sparc64/sparc64/src/make.i386/make DIRPRFX=rescue/rescue/ipfs/ cleandir cd: can't cd to /tinderbox/CURRENT/sparc64/sparc64/src/rescue/rescue/../../sbin/ipfs *** Error code 2 Stop in /tinderbox/CURRENT/sparc64/sparc64/src/rescue/rescue. *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/src/rescue. *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/src. *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/src. *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/src. TB --- 2005-04-25 19:52:13 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-04-25 19:52:13 - ERROR: failed to build world TB --- 2005-04-25 19:52:13 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Mon Apr 25 19:56: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 BBA3516A4CE for ; Mon, 25 Apr 2005 19:56:05 +0000 (GMT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 7724D43D2F for ; Mon, 25 Apr 2005 19:56:04 +0000 (GMT) (envelope-from michaelnottebrock@gmx.net) Received: (qmail invoked by alias); 25 Apr 2005 19:56:02 -0000 Received: from p508BE399.dip.t-dialin.net (EHLO lofi.dyndns.org) [80.139.227.153] by mail.gmx.net (mp005) with SMTP; 25 Apr 2005 21:56:02 +0200 X-Authenticated: #443188 Received: from kiste.my.domain (lofi@kiste.my.domain [192.168.8.4]) (authenticated bits=0) by lofi.dyndns.org (8.13.3/8.12.10) with ESMTP id j3PJttTS029078 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Mon, 25 Apr 2005 21:55:56 +0200 (CEST) (envelope-from michaelnottebrock@gmx.net) From: Michael Nottebrock To: freebsd-current@freebsd.org Date: Mon, 25 Apr 2005 21:55:49 +0200 User-Agent: KMail/1.8 References: <20050425152648.GB25681@voodoo.oberon.net> <20050425161311.GA3008@troutmask.apl.washington.edu> In-Reply-To: <20050425161311.GA3008@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2140174.NYfJBjeOTH"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200504252155.53895.michaelnottebrock@gmx.net> X-Virus-Scanned: by amavisd-new X-Y-GMX-Trusted: 0 cc: Kirill Ponomarew cc: Steve Kargl cc: current@freebsd.org Subject: Re: FreeBSD 6 is coming too fast X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 25 Apr 2005 19:56:05 -0000 --nextPart2140174.NYfJBjeOTH Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Monday, 25. April 2005 18:13, Steve Kargl wrote: > On Mon, Apr 25, 2005 at 05:26:48PM +0200, Kirill Ponomarew wrote: > > Do not forget about pointyhat which compiles a tons of ports. Switching > > it to gcc-4.0 would decrease builds time, and it's not a bad idea IMHO. > > Any port that uses Fortran will be broken by a blanket switch > to gcc-4.0.0. g77 is no longer a GCC frontend. Gfortran, which > replaces g77, can handle somewhere around 95% of the Fortran 77 > language and around 90% of the Fortran 95 language. =46rom what I've heard and read, gcc 4.0.0's increased pickyness also raise= s the=20 bar for getting existing objective-c code to compile - by introducing folli= es=20 such as refusing to compile objective-c sources with a .c extension.=20 OTOH, people are pretty excited about gcc 4's new C++ features such as the= =20 visibility support - it seems the gap between C,C++ and the more marginal=20 languages supported by the gcc is increasing. =2D-=20 ,_, | Michael Nottebrock | lofi@freebsd.org (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org --nextPart2140174.NYfJBjeOTH Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQBCbUtJXhc68WspdLARApA1AJ4usEHOkDKkIafikpxm6z/qy5FbJwCfXGOZ F2b4mGSrRaz82uz4ZpiPDw4= =JdoM -----END PGP SIGNATURE----- --nextPart2140174.NYfJBjeOTH-- From owner-freebsd-current@FreeBSD.ORG Mon Apr 25 19:56: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 C20D016A4CF for ; Mon, 25 Apr 2005 19:56:05 +0000 (GMT) Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by mx1.FreeBSD.org (Postfix) with SMTP id A0BBD43D46 for ; Mon, 25 Apr 2005 19:56:04 +0000 (GMT) (envelope-from michaelnottebrock@gmx.net) Received: (qmail invoked by alias); 25 Apr 2005 19:56:02 -0000 Received: from p508BE399.dip.t-dialin.net (EHLO lofi.dyndns.org) [80.139.227.153] by mail.gmx.net (mp005) with SMTP; 25 Apr 2005 21:56:02 +0200 X-Authenticated: #443188 Received: from kiste.my.domain (lofi@kiste.my.domain [192.168.8.4]) (authenticated bits=0) by lofi.dyndns.org (8.13.3/8.12.10) with ESMTP id j3PJttTS029078 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Mon, 25 Apr 2005 21:55:56 +0200 (CEST) (envelope-from michaelnottebrock@gmx.net) From: Michael Nottebrock To: freebsd-current@freebsd.org Date: Mon, 25 Apr 2005 21:55:49 +0200 User-Agent: KMail/1.8 References: <20050425152648.GB25681@voodoo.oberon.net> <20050425161311.GA3008@troutmask.apl.washington.edu> In-Reply-To: <20050425161311.GA3008@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2140174.NYfJBjeOTH"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200504252155.53895.michaelnottebrock@gmx.net> X-Virus-Scanned: by amavisd-new X-Y-GMX-Trusted: 0 cc: Kirill Ponomarew cc: Steve Kargl cc: current@freebsd.org Subject: Re: FreeBSD 6 is coming too fast X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 25 Apr 2005 19:56:05 -0000 --nextPart2140174.NYfJBjeOTH Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Monday, 25. April 2005 18:13, Steve Kargl wrote: > On Mon, Apr 25, 2005 at 05:26:48PM +0200, Kirill Ponomarew wrote: > > Do not forget about pointyhat which compiles a tons of ports. Switching > > it to gcc-4.0 would decrease builds time, and it's not a bad idea IMHO. > > Any port that uses Fortran will be broken by a blanket switch > to gcc-4.0.0. g77 is no longer a GCC frontend. Gfortran, which > replaces g77, can handle somewhere around 95% of the Fortran 77 > language and around 90% of the Fortran 95 language. =46rom what I've heard and read, gcc 4.0.0's increased pickyness also raise= s the=20 bar for getting existing objective-c code to compile - by introducing folli= es=20 such as refusing to compile objective-c sources with a .c extension.=20 OTOH, people are pretty excited about gcc 4's new C++ features such as the= =20 visibility support - it seems the gap between C,C++ and the more marginal=20 languages supported by the gcc is increasing. =2D-=20 ,_, | Michael Nottebrock | lofi@freebsd.org (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org --nextPart2140174.NYfJBjeOTH Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQBCbUtJXhc68WspdLARApA1AJ4usEHOkDKkIafikpxm6z/qy5FbJwCfXGOZ F2b4mGSrRaz82uz4ZpiPDw4= =JdoM -----END PGP SIGNATURE----- --nextPart2140174.NYfJBjeOTH-- From owner-freebsd-current@FreeBSD.ORG Mon Apr 25 19:58: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 BF88216A4CE; Mon, 25 Apr 2005 19:58:57 +0000 (GMT) Received: from mallaury.noc.nerim.net (smtp-101-monday.noc.nerim.net [62.4.17.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id C0CE643D62; Mon, 25 Apr 2005 19:58:56 +0000 (GMT) (envelope-from e-masson@kisoft-services.com) Received: from srvbsdnanssv.interne.kisoft-services.com (kisoft.net1.nerim.net [62.212.107.51]) by mallaury.noc.nerim.net (Postfix) with ESMTP id 5548D62D31; Mon, 25 Apr 2005 21:58:52 +0200 (CEST) Received: from localhost (localhost [127.0.0.1])CE8F7C4E2; Mon, 25 Apr 2005 21:58:52 +0200 (CEST) Received: from srvbsdnanssv.interne.kisoft-services.com ([127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08514-08; Mon, 25 Apr 2005 21:58:52 +0200 (CEST) Received: by srvbsdnanssv.interne.kisoft-services.com (Postfix, from userid 1001) id 1FA91C4B9; Mon, 25 Apr 2005 21:58:52 +0200 (CEST) To: wpaul@FreeBSD.ORG (Bill Paul) From: Eric Masson In-Reply-To: <20050425171528.7EF8B16A4D3@hub.freebsd.org> (Bill Paul's message of "Mon, 25 Apr 2005 17:15:28 +0000 (GMT)") References: <20050425171528.7EF8B16A4D3@hub.freebsd.org> X-Operating-System: FreeBSD 5.4-RC3 i386 Date: Mon, 25 Apr 2005 21:58:52 +0200 Message-ID: <861x8ysk5f.fsf@srvbsdnanssv.interne.kisoft-services.com> User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through Obscurity, berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 8bit X-Virus-Scanned: amavisd-new at interne.kisoft-services.com cc: freebsd-current@freebsd.org cc: freebsd-hardware@freebsd.org Subject: Re: Too Evil, Too Furious X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 25 Apr 2005 19:58:57 -0000 wpaul@FreeBSD.ORG (Bill Paul) writes: Hi Bill, > The cards that I can't seem to get my hands on are: > > - Marvell wireless -- supposedly D-Link used this on a card called the > DWL-G510, but only on the first revision. The second board revision > uses an Atheros chipset, which is already supported. Unfortunately, aside > from this one PCI card, this chipset tends to only show up as a built-in > component on motherboards or laptops, which makes it hard for me to just > go out and get one. I fought with Marvell based cards recently (not mine, otherwise I would already have shipped one to you). They are made by Planet http://www.planet.com.tw/ and sold under part numbers : - WL-3563 - WL-8313 I've seen only one revision of the hardware, and available drivers from Planet web site are for Marvell chipsets. This is really El Cheapo solution, with crappy drivers, hope you can find recent ndis 5.1 drivers elsewhere. Éric Masson -- Toute non, seul une petite bande de macintoshiens résistent encore et toujours à l'envahisseur ouindoze. Leur force, ils la tirent de leur potion magique : MacOS, préparée par leur druide Steve Jobs. -+- SC in Guide du Macounet Pervers : Ils sont fous ces Beurkistes! -+- From owner-freebsd-current@FreeBSD.ORG Mon Apr 25 20:00: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 CA9E016A4CE for ; Mon, 25 Apr 2005 20:00:55 +0000 (GMT) Received: from nala.dohd.org (xaa.demon.nl [83.160.166.71]) by mx1.FreeBSD.org (Postfix) with ESMTP id C217E43D49 for ; Mon, 25 Apr 2005 20:00:54 +0000 (GMT) (envelope-from freebsd@dohd.org) Received: from localhost (localhost.local.dohd.org [127.0.0.1]) by nala.dohd.org (Postfix) with ESMTP id A005F117D1 for ; Mon, 25 Apr 2005 22:00:53 +0200 (CEST) Received: from nala.dohd.org ([127.0.0.1]) by localhost (eeyore.local.dohd.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 27195-02-5 for ; Mon, 25 Apr 2005 22:00:52 +0200 (CEST) Received: by nala.dohd.org (Postfix, from userid 1008) id 5A4E8117CF; Mon, 25 Apr 2005 22:00:52 +0200 (CEST) Date: Mon, 25 Apr 2005 22:00:52 +0200 From: Mark Huizer To: freebsd-current@freebsd.org Message-ID: <20050425200052.GC24146@eeyore.local.dohd.org> References: <20050425183733.GB24146@eeyore.local.dohd.org> <2323.216.177.243.38.1114457612.localmail@webmail.dnswatch.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2323.216.177.243.38.1114457612.localmail@webmail.dnswatch.com> User-Agent: Mutt/1.5.9i X-Virus-Scanned: amavisd-new at dohd.org Subject: Re: fxp0: device timeout X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 25 Apr 2005 20:00:55 -0000 On Mon, Apr 25, 2005 at 12:33:32PM -0700, /dev/null wrote: > I don't want to sound like a smart a$$, or know-it-all. But could this not > also be a simple case of Induction? Is it possible that something has > changed in the environment that might interfere with the NIC or cabling? > I mean it wouldn't have to completely clobber the connection, but simply > impeed it slightly, which would make it crap out under any type of load. > Just thought I'd mention it FWIW. Well, if such a simple reinstall can make such a big difference, I would sincerely start questioning computers ;-) But apart from a table in the attic moving 10 centimeter, nothing changed. Mark -- Nice testing in little China... From owner-freebsd-current@FreeBSD.ORG Mon Apr 25 20:14: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 CDB5E16A4CE for ; Mon, 25 Apr 2005 20:14:37 +0000 (GMT) Received: from sasami.jurai.net (sasami.jurai.net [69.17.104.113]) by mx1.FreeBSD.org (Postfix) with ESMTP id 69E6343D1D for ; Mon, 25 Apr 2005 20:14:37 +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 j3PKESLQ021833; Mon, 25 Apr 2005 16:14:30 -0400 (EDT) (envelope-from mdodd@FreeBSD.ORG) Date: Mon, 25 Apr 2005 16:14:28 -0400 (EDT) From: "Matthew N. Dodd" X-X-Sender: winter@sasami.jurai.net To: /dev/null In-Reply-To: <2308.216.177.243.38.1114456660.localmail@webmail.dnswatch.com> Message-ID: <20050425161211.X37447@sasami.jurai.net> References: <20050425171528.7EF8B16A4D3@hub.freebsd.org> <2308.216.177.243.38.1114456660.localmail@webmail.dnswatch.com> 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]); Mon, 25 Apr 2005 16:14:30 -0400 (EDT) cc: freebsd-current@FreeBSD.ORG Subject: Re: Too Evil, Too Furious X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 25 Apr 2005 20:14:37 -0000 On Mon, 25 Apr 2005, /dev/null wrote: > I was also wondering if Project Evil will support the Compaq 32-bit > NetFlex-2 controllers? The NetFlex-2 controllers use the TMS380 chip, which will run in token ring or ethernet mode depending on firmware and population options. I've got an old, rather incomplete driver for the token-ring boards that could be revived and modified to do ethernet stuff, if you're willing to do the work. -- 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 Mon Apr 25 20:15: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 AE33516A4CE for ; Mon, 25 Apr 2005 20:15:41 +0000 (GMT) Received: from fly.ebs.gr (fly.ebs.gr [62.103.84.177]) by mx1.FreeBSD.org (Postfix) with ESMTP id B509443D5D for ; Mon, 25 Apr 2005 20:15:39 +0000 (GMT) (envelope-from past@ebs.gr) Received: from ebs.gr (root@hal.ebs.gr [10.1.1.2]) by fly.ebs.gr (8.12.9p1/8.12.9) with ESMTP id j3PKFbTf021992; Mon, 25 Apr 2005 23:15:37 +0300 (EEST) (envelope-from past@ebs.gr) Received: from [10.1.1.200] (pptp.ebs.gr [10.1.1.200]) by ebs.gr (8.12.11/8.12.11) with ESMTP id j3PKFVdM083288; Mon, 25 Apr 2005 23:15:33 +0300 (EEST) (envelope-from past@ebs.gr) Received: from 127.0.0.1 (AVG SMTP 7.0.308 [266.10.2]); Mon, 25 Apr 2005 23:15:23 +0300 Message-ID: <426D4FDB.70000@ebs.gr> Date: Mon, 25 Apr 2005 23:15:23 +0300 From: Panagiotis Astithas Organization: EBS Ltd. User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael Nottebrock References: <20050425152648.GB25681@voodoo.oberon.net> <20050425161311.GA3008@troutmask.apl.washington.edu> <200504252155.53895.michaelnottebrock@gmx.net> In-Reply-To: <200504252155.53895.michaelnottebrock@gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-current@freebsd.org cc: Steve Kargl cc: Kirill Ponomarew Subject: Re: FreeBSD 6 is coming too fast X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 25 Apr 2005 20:15:41 -0000 Michael Nottebrock wrote: > On Monday, 25. April 2005 18:13, Steve Kargl wrote: > >>On Mon, Apr 25, 2005 at 05:26:48PM +0200, Kirill Ponomarew wrote: >> >>>Do not forget about pointyhat which compiles a tons of ports. Switching >>>it to gcc-4.0 would decrease builds time, and it's not a bad idea IMHO. >> >>Any port that uses Fortran will be broken by a blanket switch >>to gcc-4.0.0. g77 is no longer a GCC frontend. Gfortran, which >>replaces g77, can handle somewhere around 95% of the Fortran 77 >>language and around 90% of the Fortran 95 language. > > > From what I've heard and read, gcc 4.0.0's increased pickyness also raises the > bar for getting existing objective-c code to compile - by introducing follies > such as refusing to compile objective-c sources with a .c extension. > > OTOH, people are pretty excited about gcc 4's new C++ features such as the > visibility support - it seems the gap between C,C++ and the more marginal > languages supported by the gcc is increasing. > As another data point, java support is supposed to be vastly improved. Not that it would be an important factor for the system compiler, though. Cheers, Panagiotis From owner-freebsd-current@FreeBSD.ORG Mon Apr 25 20:28: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 2911916A4CE for ; Mon, 25 Apr 2005 20:28:46 +0000 (GMT) Received: from smtp4.server.rpi.edu (smtp4.server.rpi.edu [128.113.2.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id A611143D53 for ; Mon, 25 Apr 2005 20:28:45 +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 j3PKShhS015877 for ; Mon, 25 Apr 2005 16:28:44 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <20050425182033.GC40370@xor.obsecurity.org> References: <20050425010242.GA44110@xor.obsecurity.org> <6.2.1.2.0.20050424210422.03d22990@64.7.153.2> <20050425014453.GA59981@xor.obsecurity.org> <426C6B1D.3040704@elischer.org> <20050425061459.GA33247@xor.obsecurity.org> <20050425062106.GB91852@voodoo.oberon.net> <426CF3DE.4000409@samsco.org> <20050425160146.4795fe1b.flynn@energyhq.es.eu.org> <426CF91A.8060907@samsco.org> <20050425144259.GL91852@voodoo.oberon.net> <20050425182033.GC40370@xor.obsecurity.org> Date: Mon, 25 Apr 2005 16:28:42 -0400 To: current@freebsd.org From: Garance A Drosihn Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-CanItPRO-Stream: default X-RPI-SA-Score: undef - spam-scanning disabled X-Scanned-By: CanIt (www . canit . ca) on 128.113.2.4 Subject: Re: GCC 4.0 [Re: FreeBSD 6 is coming too fast] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 25 Apr 2005 20:28:46 -0000 For what it's worth: Some friends of mine are claiming that "Tiger" (MacOS 10.4) will be coming with gcc 4.0. And Tiger is already shipping, although the official release date isn't until this Friday. I'm not saying that we should switch to it because of that, but I'm just mentioning it as an interesting data point (assuming it is true!). -- 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 Mon Apr 25 20:34: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 EE3BF16A4CE; Mon, 25 Apr 2005 20:34:07 +0000 (GMT) Received: from fast.dnswatch.com (fast.dnswatch.com [216.177.243.43]) by mx1.FreeBSD.org (Postfix) with ESMTP id 163E843D5C; Mon, 25 Apr 2005 20:34:07 +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 j3PKY2sm050460; Mon, 25 Apr 2005 13:34:06 -0700 (PDT) (envelope-from null@dnswatch.com) Received: (from www@localhost) by fast.dnswatch.com (8.12.6/8.12.6/Submit) id j3PKY2KB050459; Mon, 25 Apr 2005 13:34:02 -0700 (PDT) (envelope-from null@dnswatch.com) X-Authentication-Warning: fast.dnswatch.com: www set sender to null@dnswatch.com using -f Received: from ns0.1command.com ([216.177.243.38]) (DNSwatch.com_WebMail authenticated user null) by webmail.dnswatch.com with HTTP; Mon, 25 Apr 2005 13:34:01 -0700 (PDT) Message-ID: <2439.216.177.243.38.1114461241.localmail@webmail.dnswatch.com> In-Reply-To: <20050425161211.X37447@sasami.jurai.net> References: <20050425171528.7EF8B16A4D3@hub.freebsd.org><2308.216.177.243.38.1114456660.localmail@webmail.dnswatch.com> <20050425161211.X37447@sasami.jurai.net> Date: Mon, 25 Apr 2005 13:34:01 -0700 (PDT) From: "/dev/null" To: "Matthew N. Dodd" 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 cc: freebsd-current@FreeBSD.ORG Subject: Re: Too Evil, Too Furious X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 25 Apr 2005 20:34:08 -0000 > On Mon, 25 Apr 2005, /dev/null wrote: >> I was also wondering if Project Evil will support the Compaq 32-bit >> NetFlex-2 controllers? > > The NetFlex-2 controllers use the TMS380 chip, which will run in token > ring or ethernet mode depending on firmware and population options. > Yes, it's the TI TMS380C26PQL in my case(s). I have the TR adapter board as well. But not installed. > I've got an old, rather incomplete driver for the token-ring boards that > could be revived and modified to do ethernet stuff, if you're willing to > do the work. Really?! I spent an entire week (I mean the whole week - 12hrs/ day) looking for something to get these boards to work. There was some indication that Compaq was sponsoring work on these cards for Linux. But that Compaq OpenSource sponsorship seems to have mostly vanished. :\ Sure! I'd love to give it a try. Thanks! -Chris > > -- > 10 40 80 C0 00 FF FF FF FF C0 00 00 00 00 10 AA AA 03 00 00 00 08 00 > //////////////////////////////////////////////////// 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 Mon Apr 25 20:42: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 3B6D416A4CE for ; Mon, 25 Apr 2005 20:42:11 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 826A543D48 for ; Mon, 25 Apr 2005 20:42:08 +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.3/8.13.3) with ESMTP id j3PKkoks006119; Mon, 25 Apr 2005 14:46:50 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <426D5551.4090707@samsco.org> Date: Mon, 25 Apr 2005 14:38:41 -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: Garance A Drosihn References: <20050425010242.GA44110@xor.obsecurity.org> <6.2.1.2.0.20050424210422.03d22990@64.7.153.2> <20050425014453.GA59981@xor.obsecurity.org> <426C6B1D.3040704@elischer.org> <20050425061459.GA33247@xor.obsecurity.org> <20050425062106.GB91852@voodoo.oberon.net> <426CF3DE.4000409@samsco.org> <20050425160146.4795fe1b.flynn@energyhq.es.eu.org> <426CF91A.8060907@samsco.org> <20050425144259.GL91852@voodoo.oberon.net> <20050425182033.GC40370@xor.obsecurity.org> 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: current@freebsd.org Subject: Re: GCC 4.0 [Re: FreeBSD 6 is coming too fast] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 25 Apr 2005 20:42:11 -0000 Garance A Drosihn wrote: > For what it's worth: Some friends of mine are claiming that "Tiger" > (MacOS 10.4) will be coming with gcc 4.0. And Tiger is already > shipping, although the official release date isn't until this Friday. Yes, it's public knowledge that the Tiger Dev tools are based on GCC 4.0. > > I'm not saying that we should switch to it because of that, but I'm > just mentioning it as an interesting data point (assuming it is true!). > This would be a good reason to switch if our primary platform was PowerPC and Objective C, since I'm sure that Apple has given those a very good workout. But for i386, amd64, and sparc64, there might not have been as much good exposure yet. Scott From owner-freebsd-current@FreeBSD.ORG Mon Apr 25 20:46: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 4095616A4CE for ; Mon, 25 Apr 2005 20:46:14 +0000 (GMT) Received: from 62-15-211-171.inversas.jazztel.es (62-15-211-171.inversas.jazztel.es [62.15.211.171]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6CD8643D5E for ; Mon, 25 Apr 2005 20:46:13 +0000 (GMT) (envelope-from josemi@freebsd.jazztel.es) Received: from redesjm.local (orion.redesjm.local [192.168.254.16]) j3PKkBp6066021; Mon, 25 Apr 2005 22:46:11 +0200 (CEST) (envelope-from josemi@redesjm.local) Received: from localhost (localhost [[UNIX: localhost]]) by redesjm.local (8.13.3/8.13.3/Submit) id j3PKk9mP001322; Mon, 25 Apr 2005 22:46:09 +0200 (CEST) (envelope-from josemi@redesjm.local) From: Jose M Rodriguez To: freebsd-current@freebsd.org Date: Mon, 25 Apr 2005 22:46:09 +0200 User-Agent: KMail/1.8 References: <20050425010242.GA44110@xor.obsecurity.org> <20050425182033.GC40370@xor.obsecurity.org> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200504252246.09603.josemi@redesjm.local> X-AntiVirus: checked by AntiVir Milter (version: 1.1.0-3; AVE: 6.30.0.7; VDF: 6.30.0.116; host: antares.redesjm.local) cc: Garance A Drosihn Subject: Re: GCC 4.0 [Re: FreeBSD 6 is coming too fast] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 25 Apr 2005 20:46:14 -0000 El Lunes, 25 de Abril de 2005 22:28, Garance A Drosihn escribi=F3: > For what it's worth: Some friends of mine are claiming that "Tiger" > (MacOS 10.4) will be coming with gcc 4.0. And Tiger is already > shipping, although the official release date isn't until this Friday. > This is also targeted as part of FC4. But I think ports it's the rigth palce for this (FC4 also ships a gcc3). I'll prefer merge lastest gcc34 branch before going to release oriented=20 works. =2D- josemi From owner-freebsd-current@FreeBSD.ORG Mon Apr 25 20:58: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 4826116A4CE for ; Mon, 25 Apr 2005 20:58:30 +0000 (GMT) Received: from mail.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id CC42143D54 for ; Mon, 25 Apr 2005 20:58:29 +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 8F2477A423; Mon, 25 Apr 2005 13:58:29 -0700 (PDT) Message-ID: <426D59F5.4070601@elischer.org> Date: Mon, 25 Apr 2005 13:58:29 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.7) Gecko/20050423 X-Accept-Language: en, hu MIME-Version: 1.0 To: Jeff Behl References: <426D4179.1020508@fastclick.com> In-Reply-To: <426D4179.1020508@fastclick.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: current@freebsd.org Subject: Re: serial/ether console & ramblings X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 25 Apr 2005 20:58:30 -0000 Jeff Behl wrote: >Danny Braniss wrote: > > > >>>Eric Anderson wrote: >>> >>> >>> >>> >>> >>>>Danny Braniss wrote: >>>> >>>> >>>> >>>> >>>> >>>>>hi, >>>>> I was about to plunge in and 'try' to cleanup the serial console >>>>>stuff, when it downed on me that newer machines are arriving without >>>>>serial >>>>>port! there goes that idea. So USB/serial dongle came to mind, might >>>>>work, but messy, FireWire is not universaly available. >>>>>So, why not serial over ethernet? IPMI 'was' to have solved >>>>>this, but it will (if at all) work on server class MB only, and im still >>>>>looking for a Unix Viewer. >>>>> >>>>> In my case, i have been using the serial console to debug stuff, but >>>>>being of the old school, i try to stay away from debuggers :-), so >>>>>printf and stack trace will do. >>>>> >>>>> So here are some of my quesions: >>>>> o - is there some standard? ok, refrase, are there some >>>>> standards? >>>>> o - any WIP?, i'm checking out Robert Watson's ethercons >>>>> o - any great ideas? >>>>> >>>>> >>>>> >>>>> >>>>There are a couple of ports that seem to try to use IPMI. I haven't >>>>tried them yet though. (sysutils/freeipmi and sysutils/ipmitool). >>>> >>>>I can tell you that being about to do serial over ethernet (and >>>>possibly power cycling) would be incredibly handy. >>>> >>>>Eric >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>NIC drivers have to be made aware of IPMI in order for it to function >>>when a shared NIC is used. This is not the case with the bge driver, at >>>the very least. See: >>> >>>http://lists.freebsd.org/mailman/htdig/freebsd-net/2005-March/thread.html#6725 >>> >>>This is also a very big issue for us and we're considering hiring a >>>contractor to get the relevant parts put into the driver... >>> >>> >>> >>> >>> >>i guess IPMI means different things to different people. >>if it's hardware (not a software emulation), then it has some nice things: >>1 - fiddling with the box from far away, without intervention >> of the OS, like >> 1.1 - turning off (sometimes on will work too :-), >> 1.2 - turning on/off the id light- cool if you have many boxes - i used >> to laugh at this, till i found out that on some u1 boxes there is >> no place to put a label in the back. >> 1.3- finding out all kind of stuff, like when was the box assembled, >> etc. >>2- SOL, serial over lan: if this would realy work, then no need for >> all the cables/kvm etc. >> >>point 1.1 and 1.2 is done, so we can via a cli do those things, but it only >>saves a trip to the computer room. 1.3 is for the nit-picky, i have some >>60 u1's, and knowing the status of the FRUs is not that helpful. >> >>point 2, on the other hand is exiting, not only because of the cabling, but >>being able to access the console when needed, without having to connect the >>serail port (which are disappearing). >> >>so is there a client for SOL that runs under FreeBSD? >>(either IPMI 1.5 or 2.0) >> >> I run the intel "dpccli" CLI in linux emulation.. (need to run "dpcproxy" as well on the machine). it gives you all of the functionality available in IPMI1.5 including the intel SOL extension (note not 2.0 SOL). I have also used "freeipmi" port running on the machines themselves. (it's a port). I believe the freeipmi people are working (if they don't already have it) teh 2.0 SOL stuff. >>danny >> >> >> >> >> >> >> >but my whole point is that nothing in 1) works remotely (out of band) >when the system and the BMC share the same ethernet controller, at least >with the bge driver. as i mentioned in the thread, i can power cycle >and see the serial console remotely (number 2 from above) all the way up >to the point where the kernel loads. as soon as it does, the bge driver >no longer shunts off RMCP packets (what IPMI uses) to the Baseboard >Management Controller, so no IPMI... > > the intel MBs allow you to share the 10/100 ethernet with the IPMI controller. >http://lists.freebsd.org/mailman/htdig/freebsd-net/2005-March/006725.html > >i'm by no means an expert on this, but i believe it is why IPMI doesn't >work in our situation (IBM e325/6 servers). > >jeff > >_______________________________________________ >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 25 21:08: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 530F316A4CE for ; Mon, 25 Apr 2005 21:08:06 +0000 (GMT) Received: from sb.santaba.com (sb.santaba.com [207.154.84.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0A5E943D55 for ; Mon, 25 Apr 2005 21:08:06 +0000 (GMT) (envelope-from jbehl@fastclick.com) Received: from [192.168.3.100] (unknown [205.180.85.193]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sb.santaba.com (Postfix) with ESMTP id 9BD662848C; Mon, 25 Apr 2005 14:08:05 -0700 (PDT) Message-ID: <426D5C93.4020802@fastclick.com> Date: Mon, 25 Apr 2005 14:09:39 -0700 From: Jeff Behl User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Julian Elischer References: <426D4179.1020508@fastclick.com> <426D59F5.4070601@elischer.org> In-Reply-To: <426D59F5.4070601@elischer.org> X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit cc: current@freebsd.org Subject: Re: serial/ether console & ramblings X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 25 Apr 2005 21:08:06 -0000 >> but my whole point is that nothing in 1) works remotely (out of band) >> when the system and the BMC share the same ethernet controller, at least >> with the bge driver. as i mentioned in the thread, i can power cycle >> and see the serial console remotely (number 2 from above) all the way up >> to the point where the kernel loads. as soon as it does, the bge driver >> no longer shunts off RMCP packets (what IPMI uses) to the Baseboard >> Management Controller, so no IPMI... >> >> > > the intel MBs allow you to share the 10/100 ethernet with the IPMI > controller. > as do the motherboards with the e325s. we can to everything out of band when running linux, but that's because the driver for the broadcom nics in linux are aware of the BMC... From owner-freebsd-current@FreeBSD.ORG Mon Apr 25 21:22: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 A61E216A4CE for ; Mon, 25 Apr 2005 21:22:29 +0000 (GMT) Received: from mail.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5EC0143D31 for ; Mon, 25 Apr 2005 21:22:29 +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 12B377A403; Mon, 25 Apr 2005 14:22:29 -0700 (PDT) Message-ID: <426D5F94.1000302@elischer.org> Date: Mon, 25 Apr 2005 14:22:28 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.7) Gecko/20050423 X-Accept-Language: en, hu MIME-Version: 1.0 To: Jeff Behl References: <426D4179.1020508@fastclick.com> <426D59F5.4070601@elischer.org> <426D5C93.4020802@fastclick.com> In-Reply-To: <426D5C93.4020802@fastclick.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: current@freebsd.org Subject: Re: serial/ether console & ramblings X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 25 Apr 2005 21:22:29 -0000 Jeff Behl wrote: >>>but my whole point is that nothing in 1) works remotely (out of band) >>>when the system and the BMC share the same ethernet controller, at least >>>with the bge driver. as i mentioned in the thread, i can power cycle >>>and see the serial console remotely (number 2 from above) all the way up >>>to the point where the kernel loads. as soon as it does, the bge driver >>>no longer shunts off RMCP packets (what IPMI uses) to the Baseboard >>>Management Controller, so no IPMI... >>> >>> >>> >>> >>the intel MBs allow you to share the 10/100 ethernet with the IPMI >>controller. >> >> >> > >as do the motherboards with the e325s. we can to everything out of band >when running linux, but that's because the driver for the broadcom nics >in linux are aware of the BMC... > > I run the intels with FreeBSD OOB without any problems. From owner-freebsd-current@FreeBSD.ORG Mon Apr 25 21:26: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 41AE616A4CE; Mon, 25 Apr 2005 21:26:40 +0000 (GMT) Received: from mail.sorbs.net (mail.sorbs.net [203.15.51.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id B6DF443D5D; Mon, 25 Apr 2005 21:26:39 +0000 (GMT) (envelope-from matthew@uq.edu.au) Received: from [10.200.254.98] by nemesis.sorbs.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0IFI0040DU92FB@nemesis.sorbs.net>; Tue, 26 Apr 2005 07:27:03 +1000 (EST) Date: Tue, 26 Apr 2005 07:25:21 +1000 From: Matthew Sullivan In-reply-to: <426D306B.7010000@freebsd.org> To: Andre Oppermann Message-id: <426D6041.6070103@uq.edu.au> MIME-version: 1.0 Content-type: multipart/signed; boundary=------------ms080505000801010306070906; micalg=sha1; protocol="application/x-pkcs7-signature" X-Accept-Language: en User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041231 References: <426426AE.2060406@uq.edu.au> <42663EA1.3020409@uq.edu.au> <20050424150211.GA87520@walton.maths.tcd.ie> <426BC78A.3E56D99B@freebsd.org> <426C1600.106@uq.edu.au> <426D2307.97D15253@freebsd.org> <426D306B.7010000@freebsd.org> cc: David Malone cc: qingli@freebsd.org cc: silby@freebsd.org cc: freebsd-current@freebsd.org Subject: Re: DF (Don't frag) issues X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 25 Apr 2005 21:26:40 -0000 This is a cryptographically signed message in MIME format. --------------ms080505000801010306070906 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Andre Oppermann wrote: > Andre Oppermann wrote: > >> Matthew Sullivan wrote: > > > > >>> 2/ The bug itself is also a problem, as it cannot be guarenteed that >>> the >>> host returning the ICMP 'need frag' will fill in a suggested mtu, so >>> that also needs to be looked at (but I guess you know that already ;-)) >> >> >> I'm testing a fix right now. Unfortunatly the whole situation is a lot >> more complex than thought at first. While stepping through the code >> I found some other incorrect assumptions. > > > Ok, I've put up a patch that should fix all issues: > > http://www.nrg4u.com/freebsd/icmp_df_pmtu-20050425.diff got no such file or directory. Assume you want me to patch the firewall (vpn terminator) with this....? Regards, -- Matthew Sullivan Specialist Systems Programmer Information Technology Services The University of Queensland --------------ms080505000801010306070906 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIG7DCC A3IwggJaoAMCAQICASowDQYJKoZIhvcNAQEEBQAwgaMxCzAJBgNVBAYTAkFVMRMwEQYDVQQI EwpRdWVlbnNsYW5kMREwDwYDVQQHEwhCcmlzYmFuZTElMCMGA1UEChMcVGhlIFVuaXZlcnNp dHkgb2YgUXVlZW5zbGFuZDEoMCYGA1UECxMfSW5mb3JtYXRpb24gVGVjaG5vbG9neSBTZXJ2 aWNlczEbMBkGA1UEAxMSQ2VydGlmaWNhdGUgU2VydmVyMB4XDTA0MDEyMTIzMzYyMVoXDTA2 MDEyMTIzMzYyMVowgbIxCzAJBgNVBAYTAkFVMSUwIwYDVQQKExxUaGUgVW5pdmVyc2l0eSBv ZiBRdWVlbnNsYW5kMScwJQYDVQQLEx5JbmZvcm1hdGlvbiBUZWNub2xvZ3kgU2VydmljZXMx FjAUBgoJkiaJk/IsZAEBEwZjY21hdHQxGTAXBgNVBAMTEE1hdHRoZXcgU3VsbGl2YW4xIDAe BgkqhkiG9w0BCQEWEW1hdHRoZXdAdXEuZWR1LmF1MFwwDQYJKoZIhvcNAQEBBQADSwAwSAJB AJsUfrw/QUqKIzDverWc2F4GFFRZmIeO+bAl+7BM6x/9frMzOtygx4QGb4oQwtOE8Sda1aIs v+yJF3Di9EuUyvMCAwEAAaNoMGYwDgYDVR0PAQH/BAQDAgXgMBEGCWCGSAGG+EIBAQQEAwIF oDAfBgNVHSMEGDAWgBQmqtoyueiWTYZBinvsnzeOWLtUuzAgBgNVHREEGTAXgRVtYXR0aGV3 QGl0cy51cS5lZHUuYXUwDQYJKoZIhvcNAQEEBQADggEBAF2gZrkqZsZlHd4K/+yBN6qrpD61 hctDf7/Eg4jk6DMknEs6nvHMFUMZ4SXvkqPLnHBygTARKAs7qBSLd7mUUBOOQEgk6ovQVY6S 1CDSt3P9O6wjG0K1igtk8v6u7lkQ8p2STXqrOePVINdaucUgBO/IpeUtt9ATl1qvPTWyM/fz oUZsIKeYjNQVEQsuimrZjdbIAFxdl1fggSngUv64wBn8wCssGrPZIZA2lpBBEW1wejoWrDOH IIr+SspGd0i8MovDTMRSvgTERLki17FU/ANilcrSXiODKeIvpXhnQqVScnsoMSZmBmN2QIoG SnBjNK5mYxx5E3v20VOwtP1hVdEwggNyMIICWqADAgECAgEqMA0GCSqGSIb3DQEBBAUAMIGj MQswCQYDVQQGEwJBVTETMBEGA1UECBMKUXVlZW5zbGFuZDERMA8GA1UEBxMIQnJpc2JhbmUx JTAjBgNVBAoTHFRoZSBVbml2ZXJzaXR5IG9mIFF1ZWVuc2xhbmQxKDAmBgNVBAsTH0luZm9y bWF0aW9uIFRlY2hub2xvZ3kgU2VydmljZXMxGzAZBgNVBAMTEkNlcnRpZmljYXRlIFNlcnZl cjAeFw0wNDAxMjEyMzM2MjFaFw0wNjAxMjEyMzM2MjFaMIGyMQswCQYDVQQGEwJBVTElMCMG A1UEChMcVGhlIFVuaXZlcnNpdHkgb2YgUXVlZW5zbGFuZDEnMCUGA1UECxMeSW5mb3JtYXRp b24gVGVjbm9sb2d5IFNlcnZpY2VzMRYwFAYKCZImiZPyLGQBARMGY2NtYXR0MRkwFwYDVQQD ExBNYXR0aGV3IFN1bGxpdmFuMSAwHgYJKoZIhvcNAQkBFhFtYXR0aGV3QHVxLmVkdS5hdTBc MA0GCSqGSIb3DQEBAQUAA0sAMEgCQQCbFH68P0FKiiMw73q1nNheBhRUWZiHjvmwJfuwTOsf /X6zMzrcoMeEBm+KEMLThPEnWtWiLL/siRdw4vRLlMrzAgMBAAGjaDBmMA4GA1UdDwEB/wQE AwIF4DARBglghkgBhvhCAQEEBAMCBaAwHwYDVR0jBBgwFoAUJqraMrnolk2GQYp77J83jli7 VLswIAYDVR0RBBkwF4EVbWF0dGhld0BpdHMudXEuZWR1LmF1MA0GCSqGSIb3DQEBBAUAA4IB AQBdoGa5KmbGZR3eCv/sgTeqq6Q+tYXLQ3+/xIOI5OgzJJxLOp7xzBVDGeEl75Kjy5xwcoEw ESgLO6gUi3e5lFATjkBIJOqL0FWOktQg0rdz/TusIxtCtYoLZPL+ru5ZEPKdkk16qznj1SDX WrnFIATvyKXlLbfQE5darz01sjP386FGbCCnmIzUFRELLopq2Y3WyABcXZdX4IEp4FL+uMAZ /MArLBqz2SGQNpaQQRFtcHo6FqwzhyCK/krKRndIvDKLw0zEUr4ExES5ItexVPwDYpXK0l4j gyniL6V4Z0KlUnJ7KDEmZgZjdkCKBkpwYzSuZmMceRN79tFTsLT9YVXRMYIDQDCCAzwCAQEw gakwgaMxCzAJBgNVBAYTAkFVMRMwEQYDVQQIEwpRdWVlbnNsYW5kMREwDwYDVQQHEwhCcmlz YmFuZTElMCMGA1UEChMcVGhlIFVuaXZlcnNpdHkgb2YgUXVlZW5zbGFuZDEoMCYGA1UECxMf SW5mb3JtYXRpb24gVGVjaG5vbG9neSBTZXJ2aWNlczEbMBkGA1UEAxMSQ2VydGlmaWNhdGUg U2VydmVyAgEqMAkGBSsOAwIaBQCgggItMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ KoZIhvcNAQkFMQ8XDTA1MDQyNTIxMjUyMVowIwYJKoZIhvcNAQkEMRYEFNBJrsK9RaM/Ci2c jfgSpq/DrQm/MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIG6BgkrBgEEAYI3EAQx gawwgakwgaMxCzAJBgNVBAYTAkFVMRMwEQYDVQQIEwpRdWVlbnNsYW5kMREwDwYDVQQHEwhC cmlzYmFuZTElMCMGA1UEChMcVGhlIFVuaXZlcnNpdHkgb2YgUXVlZW5zbGFuZDEoMCYGA1UE CxMfSW5mb3JtYXRpb24gVGVjaG5vbG9neSBTZXJ2aWNlczEbMBkGA1UEAxMSQ2VydGlmaWNh dGUgU2VydmVyAgEqMIG8BgsqhkiG9w0BCRACCzGBrKCBqTCBozELMAkGA1UEBhMCQVUxEzAR BgNVBAgTClF1ZWVuc2xhbmQxETAPBgNVBAcTCEJyaXNiYW5lMSUwIwYDVQQKExxUaGUgVW5p dmVyc2l0eSBvZiBRdWVlbnNsYW5kMSgwJgYDVQQLEx9JbmZvcm1hdGlvbiBUZWNobm9sb2d5 IFNlcnZpY2VzMRswGQYDVQQDExJDZXJ0aWZpY2F0ZSBTZXJ2ZXICASowDQYJKoZIhvcNAQEB BQAEQIrTfLMl+dJEVq8KX6i2KvVuPO14lIonWE5eAJadVUZ2sHcDh3y1zXuLDiUErFM/L1UZ tnZY5ipITXqednSmuzQAAAAAAAA= --------------ms080505000801010306070906-- From owner-freebsd-current@FreeBSD.ORG Mon Apr 25 21:31: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 179D916A4CE for ; Mon, 25 Apr 2005 21:31:03 +0000 (GMT) Received: from mail-in-05.arcor-online.net (mail-in-05.arcor-online.net [151.189.21.45]) by mx1.FreeBSD.org (Postfix) with ESMTP id 402CE43D41 for ; Mon, 25 Apr 2005 21:31:02 +0000 (GMT) (envelope-from mailnull@mips.inka.de) Received: from kemoauc.mips.inka.de (dsl-084-056-233-156.arcor-ip.net [84.56.233.156]) by mail-in-05.arcor-online.net (Postfix) with ESMTP id 08FD010CA66 for ; Mon, 25 Apr 2005 23:31:00 +0200 (CEST) Received: from kemoauc.mips.inka.de (localhost [127.0.0.1]) by kemoauc.mips.inka.de (8.13.3/8.12.10) with ESMTP id j3PLUxaN041769 for ; Mon, 25 Apr 2005 23:30:59 +0200 (CEST) (envelope-from mailnull@kemoauc.mips.inka.de) Received: (from mailnull@localhost) by kemoauc.mips.inka.de (8.13.3/8.13.1/Submit) id j3PLUxCM041768 for freebsd-current@freebsd.org; Mon, 25 Apr 2005 23:30:59 +0200 (CEST) (envelope-from mailnull) From: naddy@mips.inka.de (Christian Weisgerber) Date: Mon, 25 Apr 2005 21:30:58 +0000 (UTC) Message-ID: References: <20050425171528.7EF8B16A4D3@hub.freebsd.org> Originator: naddy@mips.inka.de (Christian Weisgerber) To: freebsd-current@freebsd.org Subject: Re: Too Evil, Too Furious X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 25 Apr 2005 21:31:03 -0000 Bill Paul wrote: > - RayLink RT2500 wireless -- this one shows up on some PCI cards, but > I haven't had any luck finding one locally yet The Ralink shows up on _many_ cards. And -CURRENT just grew a native driver for it, ral(4), a week ago. The man page lists numerous cards and also points to this: http://damien.bergamini.free.fr/ral/list.html -- Christian "naddy" Weisgerber naddy@mips.inka.de From owner-freebsd-current@FreeBSD.ORG Mon Apr 25 21:34:35 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 618) id 54ED416A4CF; Mon, 25 Apr 2005 21:34:35 +0000 (GMT) In-Reply-To: <2308.216.177.243.38.1114456660.localmail@webmail.dnswatch.com> from /dev/null at "Apr 25, 2005 12:17:40 pm" To: null@dnswatch.com (/dev/null) Date: Mon, 25 Apr 2005 21:34:35 +0000 (GMT) X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: <20050425213435.54ED416A4CF@hub.freebsd.org> From: wpaul@FreeBSD.ORG (Bill Paul) cc: freebsd-current@freebsd.org cc: freebsd-hardware@freebsd.org Subject: Re: Too Evil, Too Furious X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 25 Apr 2005 21:34:35 -0000 > I see there are about 50 D-Link DWL-G510 802.11g Wireless PCI Adapter Cards > available on Ebay. They aren't but about $16.00 US. I'd be willing to pick > one up and send it to you. What do I need to ask the seller to ensure that > I get the right one? I haven't tried looking for the other cards on your > list yet. But I got to thinking that most of the sellers on Ebay are pretty > helpful. So if one wanted to know about the card they are selling - where > they got it, what it looks like, etc... that might be an added resource > in helping you in your quest. Well, the problem, see, is I don't know exactly how to identify which cards I need, which is why I was asking people to describe to me the ones the had. :) I'm not interested in getting stuff off eBay anyway. eBay is the debbil. And not in a good way. It looks like I have an offer for a bunch of stuff, so for now it seems Project Evil's hardware needs will be met. > I was also wondering if Project Evil will > suport the Compaq 32-bit NetFlex-2 controllers? I got a Compaq EISA box > some time ago and a whole bunch of the Netflex-2 cards with the intention > of making a FreeBSD Switch out of it. But I wasn't thinking or I wouldn't > have *assumed* that FBSD supported the Netflex-2 card. > Anyway, still have all the eqpt. and think it would be a worthy project > that I'd love to complete. Oh, one more thing; if it would be of any help, > I can cough up an IP and a remote box that you can have *complete* control > of if you like. Project Evil only supports cardbus, PCI and (to some small extent) PCMCIA. I have plans to make it support USB. But EISA? Sorry, can't help you. Nobody makes Windows XP drivers for EISAbus devices. :/ -Bill -- ============================================================================= -Bill Paul (510) 749-2329 | Senior Engineer, Master of Unix-Fu wpaul@windriver.com | Wind River Systems ============================================================================= you're just BEGGING to face the moose ============================================================================= From owner-freebsd-current@FreeBSD.ORG Mon Apr 25 21:43: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 4D92716A4CE; Mon, 25 Apr 2005 21:43:08 +0000 (GMT) Received: from mail.sorbs.net (news.sorbs.net [203.15.51.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id C257343D2D; Mon, 25 Apr 2005 21:43:07 +0000 (GMT) (envelope-from matthew@uq.edu.au) Received: from [10.200.254.98] by nemesis.sorbs.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0IFI0040HV0LFB@nemesis.sorbs.net>; Tue, 26 Apr 2005 07:43:34 +1000 (EST) Date: Tue, 26 Apr 2005 07:41:57 +1000 From: Matthew Sullivan In-reply-to: <426D6041.6070103@uq.edu.au> Message-id: <426D6425.6080209@uq.edu.au> MIME-version: 1.0 Content-type: multipart/signed; boundary=------------ms040900010304090402040500; micalg=sha1; protocol="application/x-pkcs7-signature" X-Accept-Language: en User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041231 References: <426426AE.2060406@uq.edu.au> <42663EA1.3020409@uq.edu.au> <20050424150211.GA87520@walton.maths.tcd.ie> <426BC78A.3E56D99B@freebsd.org> <426C1600.106@uq.edu.au> <426D2307.97D15253@freebsd.org> <426D306B.7010000@freebsd.org> <426D6041.6070103@uq.edu.au> cc: David Malone cc: qingli@freebsd.org cc: silby@freebsd.org cc: Andre Oppermann cc: freebsd-current@freebsd.org Subject: Re: DF (Don't frag) issues X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 25 Apr 2005 21:43:08 -0000 This is a cryptographically signed message in MIME format. --------------ms040900010304090402040500 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Matthew Sullivan wrote: > Andre Oppermann wrote: > >> Andre Oppermann wrote: >> >>> Matthew Sullivan wrote: >> >> >> > >> >>>> 2/ The bug itself is also a problem, as it cannot be guarenteed >>>> that the >>>> host returning the ICMP 'need frag' will fill in a suggested mtu, so >>>> that also needs to be looked at (but I guess you know that already >>>> ;-)) >>> >>> >>> >>> I'm testing a fix right now. Unfortunatly the whole situation is a lot >>> more complex than thought at first. While stepping through the code >>> I found some other incorrect assumptions. >> >> >> >> Ok, I've put up a patch that should fix all issues: >> >> http://www.nrg4u.com/freebsd/icmp_df_pmtu-20050425.diff > > > > got no such file or directory. > odd went to the directory and found the file ... got it now... > Assume you want me to patch the firewall (vpn terminator) with this....? Regards, -- Matthew Sullivan Specialist Systems Programmer Information Technology Services The University of Queensland --------------ms040900010304090402040500 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIG7DCC A3IwggJaoAMCAQICASowDQYJKoZIhvcNAQEEBQAwgaMxCzAJBgNVBAYTAkFVMRMwEQYDVQQI EwpRdWVlbnNsYW5kMREwDwYDVQQHEwhCcmlzYmFuZTElMCMGA1UEChMcVGhlIFVuaXZlcnNp dHkgb2YgUXVlZW5zbGFuZDEoMCYGA1UECxMfSW5mb3JtYXRpb24gVGVjaG5vbG9neSBTZXJ2 aWNlczEbMBkGA1UEAxMSQ2VydGlmaWNhdGUgU2VydmVyMB4XDTA0MDEyMTIzMzYyMVoXDTA2 MDEyMTIzMzYyMVowgbIxCzAJBgNVBAYTAkFVMSUwIwYDVQQKExxUaGUgVW5pdmVyc2l0eSBv ZiBRdWVlbnNsYW5kMScwJQYDVQQLEx5JbmZvcm1hdGlvbiBUZWNub2xvZ3kgU2VydmljZXMx FjAUBgoJkiaJk/IsZAEBEwZjY21hdHQxGTAXBgNVBAMTEE1hdHRoZXcgU3VsbGl2YW4xIDAe BgkqhkiG9w0BCQEWEW1hdHRoZXdAdXEuZWR1LmF1MFwwDQYJKoZIhvcNAQEBBQADSwAwSAJB AJsUfrw/QUqKIzDverWc2F4GFFRZmIeO+bAl+7BM6x/9frMzOtygx4QGb4oQwtOE8Sda1aIs v+yJF3Di9EuUyvMCAwEAAaNoMGYwDgYDVR0PAQH/BAQDAgXgMBEGCWCGSAGG+EIBAQQEAwIF oDAfBgNVHSMEGDAWgBQmqtoyueiWTYZBinvsnzeOWLtUuzAgBgNVHREEGTAXgRVtYXR0aGV3 QGl0cy51cS5lZHUuYXUwDQYJKoZIhvcNAQEEBQADggEBAF2gZrkqZsZlHd4K/+yBN6qrpD61 hctDf7/Eg4jk6DMknEs6nvHMFUMZ4SXvkqPLnHBygTARKAs7qBSLd7mUUBOOQEgk6ovQVY6S 1CDSt3P9O6wjG0K1igtk8v6u7lkQ8p2STXqrOePVINdaucUgBO/IpeUtt9ATl1qvPTWyM/fz oUZsIKeYjNQVEQsuimrZjdbIAFxdl1fggSngUv64wBn8wCssGrPZIZA2lpBBEW1wejoWrDOH IIr+SspGd0i8MovDTMRSvgTERLki17FU/ANilcrSXiODKeIvpXhnQqVScnsoMSZmBmN2QIoG SnBjNK5mYxx5E3v20VOwtP1hVdEwggNyMIICWqADAgECAgEqMA0GCSqGSIb3DQEBBAUAMIGj MQswCQYDVQQGEwJBVTETMBEGA1UECBMKUXVlZW5zbGFuZDERMA8GA1UEBxMIQnJpc2JhbmUx JTAjBgNVBAoTHFRoZSBVbml2ZXJzaXR5IG9mIFF1ZWVuc2xhbmQxKDAmBgNVBAsTH0luZm9y bWF0aW9uIFRlY2hub2xvZ3kgU2VydmljZXMxGzAZBgNVBAMTEkNlcnRpZmljYXRlIFNlcnZl cjAeFw0wNDAxMjEyMzM2MjFaFw0wNjAxMjEyMzM2MjFaMIGyMQswCQYDVQQGEwJBVTElMCMG A1UEChMcVGhlIFVuaXZlcnNpdHkgb2YgUXVlZW5zbGFuZDEnMCUGA1UECxMeSW5mb3JtYXRp b24gVGVjbm9sb2d5IFNlcnZpY2VzMRYwFAYKCZImiZPyLGQBARMGY2NtYXR0MRkwFwYDVQQD ExBNYXR0aGV3IFN1bGxpdmFuMSAwHgYJKoZIhvcNAQkBFhFtYXR0aGV3QHVxLmVkdS5hdTBc MA0GCSqGSIb3DQEBAQUAA0sAMEgCQQCbFH68P0FKiiMw73q1nNheBhRUWZiHjvmwJfuwTOsf /X6zMzrcoMeEBm+KEMLThPEnWtWiLL/siRdw4vRLlMrzAgMBAAGjaDBmMA4GA1UdDwEB/wQE AwIF4DARBglghkgBhvhCAQEEBAMCBaAwHwYDVR0jBBgwFoAUJqraMrnolk2GQYp77J83jli7 VLswIAYDVR0RBBkwF4EVbWF0dGhld0BpdHMudXEuZWR1LmF1MA0GCSqGSIb3DQEBBAUAA4IB AQBdoGa5KmbGZR3eCv/sgTeqq6Q+tYXLQ3+/xIOI5OgzJJxLOp7xzBVDGeEl75Kjy5xwcoEw ESgLO6gUi3e5lFATjkBIJOqL0FWOktQg0rdz/TusIxtCtYoLZPL+ru5ZEPKdkk16qznj1SDX WrnFIATvyKXlLbfQE5darz01sjP386FGbCCnmIzUFRELLopq2Y3WyABcXZdX4IEp4FL+uMAZ /MArLBqz2SGQNpaQQRFtcHo6FqwzhyCK/krKRndIvDKLw0zEUr4ExES5ItexVPwDYpXK0l4j gyniL6V4Z0KlUnJ7KDEmZgZjdkCKBkpwYzSuZmMceRN79tFTsLT9YVXRMYIDQDCCAzwCAQEw gakwgaMxCzAJBgNVBAYTAkFVMRMwEQYDVQQIEwpRdWVlbnNsYW5kMREwDwYDVQQHEwhCcmlz YmFuZTElMCMGA1UEChMcVGhlIFVuaXZlcnNpdHkgb2YgUXVlZW5zbGFuZDEoMCYGA1UECxMf SW5mb3JtYXRpb24gVGVjaG5vbG9neSBTZXJ2aWNlczEbMBkGA1UEAxMSQ2VydGlmaWNhdGUg U2VydmVyAgEqMAkGBSsOAwIaBQCgggItMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ KoZIhvcNAQkFMQ8XDTA1MDQyNTIxNDE1N1owIwYJKoZIhvcNAQkEMRYEFAjpRuxyUHJaF5Zo Jre+JFEUu/xYMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIG6BgkrBgEEAYI3EAQx gawwgakwgaMxCzAJBgNVBAYTAkFVMRMwEQYDVQQIEwpRdWVlbnNsYW5kMREwDwYDVQQHEwhC cmlzYmFuZTElMCMGA1UEChMcVGhlIFVuaXZlcnNpdHkgb2YgUXVlZW5zbGFuZDEoMCYGA1UE CxMfSW5mb3JtYXRpb24gVGVjaG5vbG9neSBTZXJ2aWNlczEbMBkGA1UEAxMSQ2VydGlmaWNh dGUgU2VydmVyAgEqMIG8BgsqhkiG9w0BCRACCzGBrKCBqTCBozELMAkGA1UEBhMCQVUxEzAR BgNVBAgTClF1ZWVuc2xhbmQxETAPBgNVBAcTCEJyaXNiYW5lMSUwIwYDVQQKExxUaGUgVW5p dmVyc2l0eSBvZiBRdWVlbnNsYW5kMSgwJgYDVQQLEx9JbmZvcm1hdGlvbiBUZWNobm9sb2d5 IFNlcnZpY2VzMRswGQYDVQQDExJDZXJ0aWZpY2F0ZSBTZXJ2ZXICASowDQYJKoZIhvcNAQEB BQAEQElpxnCNVy8Mreb9iTNSCxas86RJUCfqAkDSAk40bYm5uZ/fc3Yn8WetEERsVQ4Pp75J 9qXzcKh/8A4olIvRrtAAAAAAAAA= --------------ms040900010304090402040500-- From owner-freebsd-current@FreeBSD.ORG Mon Apr 25 22:05:18 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 618) id 43BD616A4CF; Mon, 25 Apr 2005 22:05:18 +0000 (GMT) In-Reply-To: from "neuro@mail.fci.fsu.edu" at "Apr 25, 2005 02:05:18 pm" To: neuro@mail.fci.fsu.edu Date: Mon, 25 Apr 2005 22:05:18 +0000 (GMT) X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: <20050425220518.43BD616A4CF@hub.freebsd.org> From: wpaul@FreeBSD.ORG (Bill Paul) cc: freebsd-current@freebsd.org cc: freebsd-hardware@freebsd.org Subject: Re: Too Evil, Too Furious X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 25 Apr 2005 22:05:18 -0000 > Dear Bill Paul, > > I asked if you needed help earlier in programming project evil. I was > wondering if you have a CVS repository of the code. Also, if I partake in > this endeavour I will be able to supply you with the cards as I am doing > research for my university I can order these as extras and ship them to > you. We do a lot of opensource development. Hell I'll even purchase > these out of pocket. I would like to help tell me what you need done and > we'll figure something out... Ok, a couple of things here: 1) Project Evil isn't really a separate project. I gave it a silly name, but it's really just part of the FreeBSD kernel. 2) It doesn't have a separate CVS repository. Everything is in the FreeBSD CVS tree, except for anything I'm hacking on right at this second (which, at the moment, is nothing). 3) I don't really need volunteers to offer help. If someone finds something broken or deficient, decides on their own initiative to fix it, and then submits the fix, that's great. If you just ask me if you can help, then the answer is probably no. -Bill -- ============================================================================= -Bill Paul (510) 749-2329 | Senior Engineer, Master of Unix-Fu wpaul@windriver.com | Wind River Systems ============================================================================= you're just BEGGING to face the moose ============================================================================= From owner-freebsd-current@FreeBSD.ORG Mon Apr 25 22:08: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 ADC4D16A4CE; Mon, 25 Apr 2005 22:08:14 +0000 (GMT) Received: from mail.fci.fsu.edu (mail.fci.fsu.edu [128.186.195.169]) by mx1.FreeBSD.org (Postfix) with ESMTP id 78DA243D1D; Mon, 25 Apr 2005 22:08:14 +0000 (GMT) (envelope-from neuro@mail.fci.fsu.edu) Received: from mail.fci.fsu.edu (mail.fci.fsu.edu [127.0.0.1]) by mail.fci.fsu.edu (Postfix) with ESMTP id CAB9C352F; Mon, 25 Apr 2005 18:17:19 -0400 (EDT) Date: Mon, 25 Apr 2005 18:17:19 -0400 (EDT) From: neuro@mail.fci.fsu.edu To: Bill Paul In-Reply-To: <20050425220518.43BD616A4CF@hub.freebsd.org> Message-ID: References: <20050425220518.43BD616A4CF@hub.freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed cc: freebsd-current@freebsd.org cc: freebsd-hardware@freebsd.org Subject: Re: Too Evil, Too Furious X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 25 Apr 2005 22:08:14 -0000 yeah my assumption was incorrect about how the project was managed if it's a part of the kernel as such then i can see where you're coming from. thanks. On Mon, 25 Apr 2005, Bill Paul wrote: >> Dear Bill Paul, >> >> I asked if you needed help earlier in programming project evil. I was >> wondering if you have a CVS repository of the code. Also, if I partake in >> this endeavour I will be able to supply you with the cards as I am doing >> research for my university I can order these as extras and ship them to >> you. We do a lot of opensource development. Hell I'll even purchase >> these out of pocket. I would like to help tell me what you need done and >> we'll figure something out... > > Ok, a couple of things here: > > 1) Project Evil isn't really a separate project. I gave it a silly name, > but it's really just part of the FreeBSD kernel. > 2) It doesn't have a separate CVS repository. Everything is in the > FreeBSD CVS tree, except for anything I'm hacking on right at this > second (which, at the moment, is nothing). > 3) I don't really need volunteers to offer help. If someone finds > something broken or deficient, decides on their own initiative to > fix it, and then submits the fix, that's great. If you just ask > me if you can help, then the answer is probably no. > > -Bill > > -- > ============================================================================= > -Bill Paul (510) 749-2329 | Senior Engineer, Master of Unix-Fu > wpaul@windriver.com | Wind River Systems > ============================================================================= > you're just BEGGING to face the moose > ============================================================================= > From owner-freebsd-current@FreeBSD.ORG Mon Apr 25 22:46: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 83F4316A4CE for ; Mon, 25 Apr 2005 22:46:47 +0000 (GMT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 33E8C43D6E for ; Mon, 25 Apr 2005 22:46:47 +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 j3PMkkje006994; Mon, 25 Apr 2005 15:46:46 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id j3PMkkko006993; Mon, 25 Apr 2005 15:46:46 -0700 Date: Mon, 25 Apr 2005 15:46:46 -0700 From: Brooks Davis To: Brooks Davis Message-ID: <20050425224646.GA6848@odin.ac.hmc.edu> References: <17001.9557.627987.505930@roam.psg.com> <17001.16520.774703.612151@roam.psg.com> <20050422112246.A70611@xorpc.icir.org> <17001.16764.512962.411616@roam.psg.com> <20050422115518.C70611@xorpc.icir.org> <20050422214418.GB11806@odin.ac.hmc.edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="T4sUOijqQbZv57TR" Content-Disposition: inline In-Reply-To: <20050422214418.GB11806@odin.ac.hmc.edu> 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: Randy Bush cc: Luigi Rizzo cc: FreeBSD Current Subject: Re: significant increase in ipfw pullup failed X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 25 Apr 2005 22:46:47 -0000 --T4sUOijqQbZv57TR Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Apr 22, 2005 at 02:44:18PM -0700, Brooks Davis wrote: > On Fri, Apr 22, 2005 at 11:55:18AM -0700, Luigi Rizzo wrote: > > On Fri, Apr 22, 2005 at 08:25:00AM -1000, Randy Bush wrote: > > > > wonder if it is related to the recent import of ipfw v6 support... > > >=20 > > > could be, no idea really. but fwiw, ipv6 is not enabled here. > >=20 > > yes but there is some new code in the common path. > > anyways i have cc-ed Brooks who committed the code >=20 > I suspect this is due to over agressive pullups of icmp packets (at > least that's the most obvious place where the length changed) which are > caused by poor design of the icmp struct. We're pulling up the full > length and should instead be pulling up 4 bytes. I'm not sure what the > best fix it. Long term, creating a struct icmphdr is probably the right > answer. For now, the thing to do may be to add it and use it in ipfw, > but not modify struct icmp just yet. Here's a diff implementing that. Could someone who is experinceing thse extra warnings, please test it? -- Brooks Index: netinet/ip_fw2.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/cvs/src/sys/netinet/ip_fw2.c,v retrieving revision 1.95 diff -u -p -r1.95 ip_fw2.c --- netinet/ip_fw2.c 19 Apr 2005 10:04:38 -0000 1.95 +++ netinet/ip_fw2.c 25 Apr 2005 21:57:30 -0000 @@ -328,11 +328,11 @@ SYSCTL_INT(_net_inet_ip_fw, OID_AUTO, dy #define L3HDR(T, ip) ((T *)((u_int32_t *)(ip) + (ip)->ip_hl)) #define TCP(p) ((struct tcphdr *)(p)) #define UDP(p) ((struct udphdr *)(p)) -#define ICMP(p) ((struct icmp *)(p)) +#define ICMP(p) ((struct icmphdr *)(p)) #define ICMP6(p) ((struct icmp6_hdr *)(p)) =20 static __inline int -icmptype_match(struct icmp *icmp, ipfw_insn_u32 *cmd) +icmptype_match(struct icmphdr *icmp, ipfw_insn_u32 *cmd) { int type =3D icmp->icmp_type; =20 @@ -343,7 +343,7 @@ icmptype_match(struct icmp *icmp, ipfw_i (1 << ICMP_TSTAMP) | (1 << ICMP_IREQ) | (1 << ICMP_MASKREQ) ) =20 static int -is_icmp_query(struct icmp *icmp) +is_icmp_query(struct icmphdr *icmp) { int type =3D icmp->icmp_type; =20 @@ -760,7 +760,7 @@ ipfw_log(struct ip_fw *f, u_int hlen, st } else { struct ip *ip =3D mtod(m, struct ip *); /* these three are all aliases to the same thing */ - struct icmp *const icmp =3D L3HDR(struct icmp, ip); + struct icmphdr *const icmp =3D L3HDR(struct icmphdr, ip); struct tcphdr *const tcp =3D (struct tcphdr *)icmp; struct udphdr *const udp =3D (struct udphdr *)icmp; =20 @@ -2108,11 +2108,7 @@ do { \ break; =20 case IPPROTO_ICMP: - /* - * we only care for 4 bytes: type, code, - * checksum - */ - PULLUP_TO(hlen, ulp, struct icmp); + PULLUP_TO(hlen, ulp, struct icmphdr); args->f_id.flags =3D ICMP(ulp)->icmp_type; break; =20 Index: netinet/ip_icmp.h =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/cvs/src/sys/netinet/ip_icmp.h,v retrieving revision 1.24 diff -u -p -r1.24 ip_icmp.h --- netinet/ip_icmp.h 21 Apr 2005 14:29:34 -0000 1.24 +++ netinet/ip_icmp.h 25 Apr 2005 22:44:43 -0000 @@ -49,6 +49,17 @@ struct icmp_ra_addr { /* * Structure of an icmp header. */ +struct icmphdr { + u_char icmp_type; /* type of message, see below */ + u_char icmp_code; /* type sub code */ + u_short icmp_cksum; /* ones complement cksum of struct */ +}; + +/* + * Structure of an icmp packet. + * + * XXX: should start with a struct icmphdr. + */ struct icmp { u_char icmp_type; /* type of message, see below */ u_char icmp_code; /* type sub code */ --=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 --T4sUOijqQbZv57TR Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFCbXNVXY6L6fI4GtQRAghcAJ9FzZfOTx/++DpFe+CX4vwKOhC+hgCfaUJQ ddABVf5rR5j8IIIgFE05aGs= =Tpxu -----END PGP SIGNATURE----- --T4sUOijqQbZv57TR-- From owner-freebsd-current@FreeBSD.ORG Tue Apr 26 02:47: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 347B416A4CE for ; Tue, 26 Apr 2005 02:47:39 +0000 (GMT) Received: from carver.gumbysoft.com (carver.gumbysoft.com [66.220.23.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0193443D4C for ; Tue, 26 Apr 2005 02:47:39 +0000 (GMT) (envelope-from dwhite@gumbysoft.com) Received: by carver.gumbysoft.com (Postfix, from userid 1000) id D26E472DDF; Mon, 25 Apr 2005 19:47:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by carver.gumbysoft.com (Postfix) with ESMTP id CAA5B72DDB; Mon, 25 Apr 2005 19:47:38 -0700 (PDT) Date: Mon, 25 Apr 2005 19:47:38 -0700 (PDT) From: Doug White To: Danny Braniss In-Reply-To: Message-ID: <20050425194641.C42718@carver.gumbysoft.com> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: current@freebsd.org Subject: Re: diskless/unionfs 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: Tue, 26 Apr 2005 02:47:39 -0000 On Sat, 23 Apr 2005, Danny Braniss wrote: > > On Fri, 22 Apr 2005, Danny Braniss wrote: > > > > > hi, > > > after much debugging, it seems that the main problem with unionfs is > > > that if it's called early in the boot process it will panic the kernel: > > > > > > 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 = 0x8:0xffffffff8038e3f5 > > > stack pointer = 0x10:0xffffffffb1eac7b0 > > > frame pointer = 0x10:0xffffffffb1eac7e0 > > > code segment = base 0x0, limit 0xfffff, type 0x1b > > > = DPL 0, pres 1, long 1, def32 0, gran 1 > > > processor eflags = interrupt enabled, resume, IOPL = 0 > > > current process = 213 (sh) > > > [thread pid 213 tid 100066 ] > > > Stopped at _mtx_lock_flags+0x35: cmpq $0x80779d40,0(%rdi) > > > > unintialized mutex, probably, although it looks like it'd be the vm page > > queue mutex which should be init'd by then. > > > > Is this -CURRENT? > yes, cvs'ed a few days ago (but the problem is not new). > > > > > > db> tr > > > Tracing pid 213 tid 100066 td 0xffffff007b9b1000 > > > _mtx_lock_flags() at _mtx_lock_flags+0x35 > > > exec_map_first_page() at exec_map_first_page+0x60 > > > > If you have a debug kernel for this around, load it into gdb and 'disass > > exec_map_first_page' and look around offset 96 to see if its referencing a > > mutex (mtx) near there. > > arghh, gdb, is there a quick guide for this? im almost there, but > can't sync speed (the console is at 38400). Oh, don't bother trying to attach directly to the kernel, just look at the kernel.debug binary , if you've got one. If not, put makeoptions DEBUG=-g in your kernel config so you have one next time. > > > > > > kern_execve() at kern_execve+0x2a0 > > > execve() at execve+0x5d > > > syscall() at syscall+0x4ab > > > Xfast_syscall() at Xfast_syscall+0xa8 > > > --- syscall (59, FreeBSD ELF64, execve), rip = 0x80090630c, rsp = > > > 0x7fffffffcbf8, rbp = 0 --- > > > > > > doing the unionfs stuff sometime later - after the single user prompt - seems > > > do be ok. > > > > > > another thing, there are some LOR caused by the unionfs & md: > > > extarct of rc.d/initdiskless: > > > > > > if [ -e /conf/union ]; then > > > if ! sysctl vfs.uniondebug >/dev/null 2>&1; then > > > echo Loading unionfs > > > kldload unionfs > > > fi > > > echo Doing UNIONFS > > > mount_md 4096 /conf/etc > > > chmod 755 /conf/etc > > > mount_unionfs /conf/etc /etc > > > ls -R /etc > /dev/null > > > touch /etc/.sentinel > > > md_created_etc=created > > > fi > > > ... > > > > > > Loading unionfs > > > lock order reversal > > > 1st 0xffffff007c3b00f0 system map (system map) @ /r+d/6.0/src/sys/vm/vm_map.c: > > > 1100 > > > 2nd 0xffffff00623d8620 vm object (standard object) @ > > > /r+d/6.0/src/sys/vm/vm_map.c:897 > > > KDB: stack backtrace: > > > witness_checkorder() at witness_checkorder+0x5f1 > > > _mtx_lock_flags() at _mtx_lock_flags+0x4a > > > vm_map_insert() at vm_map_insert+0x115 > > > vm_map_find() at vm_map_find+0x9d > > > link_elf_load_file() at link_elf_load_file+0x811 > > > linker_load_module() at linker_load_module+0x50e > > > kldload() at kldload+0xc3 > > > syscall() at syscall+0x4ab > > > Xfast_syscall() at Xfast_syscall+0xa8 > > > --- syscall (304, FreeBSD ELF64, kldload), rip = 0x80067950c, rsp = > > > 0x7fffffffedf8, rbp = 0x7fffffffee68 --- > > > > > > Doing UNIONFS > > > lock order reversal > > > 1st 0xffffffff80892040 vm page queue mutex (vm page queue mutex) @ > > > /r+d/6.0/src/sys/kern/vfs_bio.c:1485 > > > 2nd 0xffffff0061dc98b0 vnode interlock (vnode interlock) @ > > > /r+d/6.0/src/sys/kern/vfs_subr.c:1992 > > > KDB: stack backtrace: > > > witness_checkorder() at witness_checkorder+0x5f1 > > > _mtx_lock_flags() at _mtx_lock_flags+0x4a > > > vdrop() at vdrop+0x31 > > > vm_page_remove() at vm_page_remove+0x126 > > > vm_page_free_toq() at vm_page_free_toq+0x61 > > > vm_page_free() at vm_page_free+0x1e > > > vfs_vmio_release() at vfs_vmio_release+0x18f > > > brelse() at brelse+0x792 > > > ffs_mount() at ffs_mount+0x121b > > > vfs_donmount() at vfs_donmount+0xaa3 > > > kernel_mount() at kernel_mount+0xaf > > > ffs_cmount() at ffs_cmount+0x92 > > > mount() at mount+0x132 > > > syscall() at syscall+0x1fb > > > Xfast_syscall() at Xfast_syscall+0xa8 > > > --- syscall (21, FreeBSD ELF64, mount), rip = 0x80067e68c, rsp = > > > 0x7fffffffdf98, rbp = 0x7fffffffea58 --- > > > > > > > > > _______________________________________________ > > > 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 > > -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Tue Apr 26 03:13: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 0AB1216A4CE for ; Tue, 26 Apr 2005 03:13:22 +0000 (GMT) Received: from carver.gumbysoft.com (carver.gumbysoft.com [66.220.23.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id BACCD43D46 for ; Tue, 26 Apr 2005 03:13:21 +0000 (GMT) (envelope-from dwhite@gumbysoft.com) Received: by carver.gumbysoft.com (Postfix, from userid 1000) id 3D81F72DE7; Mon, 25 Apr 2005 20:13:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by carver.gumbysoft.com (Postfix) with ESMTP id 38F4472DDB; Mon, 25 Apr 2005 20:13:21 -0700 (PDT) Date: Mon, 25 Apr 2005 20:13:21 -0700 (PDT) From: Doug White To: Matthew Sullivan In-Reply-To: <426CABD7.8010201@uq.edu.au> Message-ID: <20050425200601.I42718@carver.gumbysoft.com> References: <4267A1CF.3080903@uq.edu.au> <20050422190208.M68772@lexi.siliconlandmark.com> <426A20E5.5020604@uq.edu.au><426B06F5.3030506@uq.edu.au> <426C93AC.3030907@root.org> <426CABD7.8010201@uq.edu.au> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-current@freebsd.org cc: Nate Lawson Subject: Re: SMP on Compaq DL380 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 26 Apr 2005 03:13:22 -0000 On Mon, 25 Apr 2005, Matthew Sullivan wrote: > Nate Lawson wrote: > > > > > I'd like to see the acpidump -t -d > matthew.asl > > http://scorpion.sorbs.net/matthew.asl > > > > > There definitely is a problem when you have identical APIC ids. We > > already blacklist one version of this BIOS. > > > That's not something I wanted to here right now... :-( Are you __sure__ you're booting the right kernel? http://scorpion.sorbs.net/dmesg.txt shows a kernel that does not have SMP nor APIC enabled. I'm still seeing ISA interrupt routing rather than APIC mappings. And as noted previously the APIC IDs are not set which means they are not enabled. (APIC IDs are always >0.) What is the output of 'sysctl kern.smp'? Have you tried booting without ACPI? -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Tue Apr 26 03:30: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 0A93816A4CE for ; Tue, 26 Apr 2005 03:30:30 +0000 (GMT) Received: from mail.sorbs.net (mail.sorbs.net [203.15.51.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id 54A4D43D39 for ; Tue, 26 Apr 2005 03:30:29 +0000 (GMT) (envelope-from matthew@uq.edu.au) Received: from [130.102.152.118] (stealthd.its.uq.edu.au [130.102.152.118]) by nemesis.sorbs.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0IFJ0040UB3JFB@nemesis.sorbs.net> for freebsd-current@freebsd.org; Tue, 26 Apr 2005 13:30:55 +1000 (EST) Date: Tue, 26 Apr 2005 13:29:15 +1000 From: Matthew Sullivan In-reply-to: <20050425200601.I42718@carver.gumbysoft.com> To: Doug White Message-id: <426DB58B.5020608@uq.edu.au> MIME-version: 1.0 Content-type: multipart/signed; boundary=------------ms070500050104000400010807; micalg=sha1; protocol="application/x-pkcs7-signature" X-Accept-Language: en User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041231 References: <4267A1CF.3080903@uq.edu.au> <20050422190208.M68772@lexi.siliconlandmark.com> <426A20E5.5020604@uq.edu.au> <426B06F5.3030506@uq.edu.au> <426C93AC.3030907@root.org> <426CABD7.8010201@uq.edu.au> <20050425200601.I42718@carver.gumbysoft.com> cc: freebsd-current@freebsd.org cc: Nate Lawson Subject: Re: SMP on Compaq DL380 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 26 Apr 2005 03:30:30 -0000 This is a cryptographically signed message in MIME format. --------------ms070500050104000400010807 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Doug White wrote: >On Mon, 25 Apr 2005, Matthew Sullivan wrote: > > > >>Nate Lawson wrote: >> >> >> >>>I'd like to see the acpidump -t -d > matthew.asl >>> >>> >>http://scorpion.sorbs.net/matthew.asl >> >> >> >>>There definitely is a problem when you have identical APIC ids. We >>>already blacklist one version of this BIOS. >>> >>> >>> >>That's not something I wanted to here right now... :-( >> >> > >Are you __sure__ you're booting the right kernel? >http://scorpion.sorbs.net/dmesg.txt shows a kernel that does not have SMP >nor APIC enabled. I'm still seeing ISA interrupt routing rather than APIC >mappings. And as noted previously the APIC IDs are not set which means >they are not enabled. (APIC IDs are always >0.) > >What is the output of 'sysctl kern.smp'? > > kern.smp.maxcpus: 16 kern.smp.active: 0 kern.smp.disabled: 0 kern.smp.cpus: 1 kern.smp.forward_signal_enabled: 1 kern.smp.forward_roundrobin_enabled: 1 >Have you tried booting without ACPI? > > No, but I am doing now... Btw now I have remote console this is what the BIOS shows.... 1024 MB Detected COMPAQ System BIOS - P17 (12/18/2002) Copyright 1982,2002 Compaq Computer Corporation. All rights reserved. Processor 1 initialized at 866/133 MHz with 256 Kbyte Cache Processor 2 initialized at 866/133 MHz with 256 Kbyte Cache 1024 MB Detected COMPAQ System BIOS - P17 (12/18/2002) Copyright 1982,2002 Compaq Computer Corporation. All rights reserved. Processor 1 initialized at 866/133 MHz with 256 Kbyte Cache Processor 2 initialized at 866/133 MHz with 256 Kbyte Cache etc... Boot without ACPI is show at http://scorpion.sorbs.net/dmesg-noacpi.txt kern.smp.maxcpus: 16 kern.smp.active: 0 kern.smp.disabled: 0 kern.smp.cpus: 1 kern.smp.forward_signal_enabled: 1 kern.smp.forward_roundrobin_enabled: 1 I'm going to recompile the kernel again - with the current config - just to prove it's there... Regards, -- Matthew Sullivan Specialist Systems Programmer Information Technology Services The University of Queensland --------------ms070500050104000400010807 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIG7DCC A3IwggJaoAMCAQICASowDQYJKoZIhvcNAQEEBQAwgaMxCzAJBgNVBAYTAkFVMRMwEQYDVQQI EwpRdWVlbnNsYW5kMREwDwYDVQQHEwhCcmlzYmFuZTElMCMGA1UEChMcVGhlIFVuaXZlcnNp dHkgb2YgUXVlZW5zbGFuZDEoMCYGA1UECxMfSW5mb3JtYXRpb24gVGVjaG5vbG9neSBTZXJ2 aWNlczEbMBkGA1UEAxMSQ2VydGlmaWNhdGUgU2VydmVyMB4XDTA0MDEyMTIzMzYyMVoXDTA2 MDEyMTIzMzYyMVowgbIxCzAJBgNVBAYTAkFVMSUwIwYDVQQKExxUaGUgVW5pdmVyc2l0eSBv ZiBRdWVlbnNsYW5kMScwJQYDVQQLEx5JbmZvcm1hdGlvbiBUZWNub2xvZ3kgU2VydmljZXMx FjAUBgoJkiaJk/IsZAEBEwZjY21hdHQxGTAXBgNVBAMTEE1hdHRoZXcgU3VsbGl2YW4xIDAe BgkqhkiG9w0BCQEWEW1hdHRoZXdAdXEuZWR1LmF1MFwwDQYJKoZIhvcNAQEBBQADSwAwSAJB AJsUfrw/QUqKIzDverWc2F4GFFRZmIeO+bAl+7BM6x/9frMzOtygx4QGb4oQwtOE8Sda1aIs v+yJF3Di9EuUyvMCAwEAAaNoMGYwDgYDVR0PAQH/BAQDAgXgMBEGCWCGSAGG+EIBAQQEAwIF oDAfBgNVHSMEGDAWgBQmqtoyueiWTYZBinvsnzeOWLtUuzAgBgNVHREEGTAXgRVtYXR0aGV3 QGl0cy51cS5lZHUuYXUwDQYJKoZIhvcNAQEEBQADggEBAF2gZrkqZsZlHd4K/+yBN6qrpD61 hctDf7/Eg4jk6DMknEs6nvHMFUMZ4SXvkqPLnHBygTARKAs7qBSLd7mUUBOOQEgk6ovQVY6S 1CDSt3P9O6wjG0K1igtk8v6u7lkQ8p2STXqrOePVINdaucUgBO/IpeUtt9ATl1qvPTWyM/fz oUZsIKeYjNQVEQsuimrZjdbIAFxdl1fggSngUv64wBn8wCssGrPZIZA2lpBBEW1wejoWrDOH IIr+SspGd0i8MovDTMRSvgTERLki17FU/ANilcrSXiODKeIvpXhnQqVScnsoMSZmBmN2QIoG SnBjNK5mYxx5E3v20VOwtP1hVdEwggNyMIICWqADAgECAgEqMA0GCSqGSIb3DQEBBAUAMIGj MQswCQYDVQQGEwJBVTETMBEGA1UECBMKUXVlZW5zbGFuZDERMA8GA1UEBxMIQnJpc2JhbmUx JTAjBgNVBAoTHFRoZSBVbml2ZXJzaXR5IG9mIFF1ZWVuc2xhbmQxKDAmBgNVBAsTH0luZm9y bWF0aW9uIFRlY2hub2xvZ3kgU2VydmljZXMxGzAZBgNVBAMTEkNlcnRpZmljYXRlIFNlcnZl cjAeFw0wNDAxMjEyMzM2MjFaFw0wNjAxMjEyMzM2MjFaMIGyMQswCQYDVQQGEwJBVTElMCMG A1UEChMcVGhlIFVuaXZlcnNpdHkgb2YgUXVlZW5zbGFuZDEnMCUGA1UECxMeSW5mb3JtYXRp b24gVGVjbm9sb2d5IFNlcnZpY2VzMRYwFAYKCZImiZPyLGQBARMGY2NtYXR0MRkwFwYDVQQD ExBNYXR0aGV3IFN1bGxpdmFuMSAwHgYJKoZIhvcNAQkBFhFtYXR0aGV3QHVxLmVkdS5hdTBc MA0GCSqGSIb3DQEBAQUAA0sAMEgCQQCbFH68P0FKiiMw73q1nNheBhRUWZiHjvmwJfuwTOsf /X6zMzrcoMeEBm+KEMLThPEnWtWiLL/siRdw4vRLlMrzAgMBAAGjaDBmMA4GA1UdDwEB/wQE AwIF4DARBglghkgBhvhCAQEEBAMCBaAwHwYDVR0jBBgwFoAUJqraMrnolk2GQYp77J83jli7 VLswIAYDVR0RBBkwF4EVbWF0dGhld0BpdHMudXEuZWR1LmF1MA0GCSqGSIb3DQEBBAUAA4IB AQBdoGa5KmbGZR3eCv/sgTeqq6Q+tYXLQ3+/xIOI5OgzJJxLOp7xzBVDGeEl75Kjy5xwcoEw ESgLO6gUi3e5lFATjkBIJOqL0FWOktQg0rdz/TusIxtCtYoLZPL+ru5ZEPKdkk16qznj1SDX WrnFIATvyKXlLbfQE5darz01sjP386FGbCCnmIzUFRELLopq2Y3WyABcXZdX4IEp4FL+uMAZ /MArLBqz2SGQNpaQQRFtcHo6FqwzhyCK/krKRndIvDKLw0zEUr4ExES5ItexVPwDYpXK0l4j gyniL6V4Z0KlUnJ7KDEmZgZjdkCKBkpwYzSuZmMceRN79tFTsLT9YVXRMYIDQDCCAzwCAQEw gakwgaMxCzAJBgNVBAYTAkFVMRMwEQYDVQQIEwpRdWVlbnNsYW5kMREwDwYDVQQHEwhCcmlz YmFuZTElMCMGA1UEChMcVGhlIFVuaXZlcnNpdHkgb2YgUXVlZW5zbGFuZDEoMCYGA1UECxMf SW5mb3JtYXRpb24gVGVjaG5vbG9neSBTZXJ2aWNlczEbMBkGA1UEAxMSQ2VydGlmaWNhdGUg U2VydmVyAgEqMAkGBSsOAwIaBQCgggItMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ KoZIhvcNAQkFMQ8XDTA1MDQyNjAzMjkxNVowIwYJKoZIhvcNAQkEMRYEFDgs8Qm9XutUAQJM 0eUiPoUdtd9NMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIG6BgkrBgEEAYI3EAQx gawwgakwgaMxCzAJBgNVBAYTAkFVMRMwEQYDVQQIEwpRdWVlbnNsYW5kMREwDwYDVQQHEwhC cmlzYmFuZTElMCMGA1UEChMcVGhlIFVuaXZlcnNpdHkgb2YgUXVlZW5zbGFuZDEoMCYGA1UE CxMfSW5mb3JtYXRpb24gVGVjaG5vbG9neSBTZXJ2aWNlczEbMBkGA1UEAxMSQ2VydGlmaWNh dGUgU2VydmVyAgEqMIG8BgsqhkiG9w0BCRACCzGBrKCBqTCBozELMAkGA1UEBhMCQVUxEzAR BgNVBAgTClF1ZWVuc2xhbmQxETAPBgNVBAcTCEJyaXNiYW5lMSUwIwYDVQQKExxUaGUgVW5p dmVyc2l0eSBvZiBRdWVlbnNsYW5kMSgwJgYDVQQLEx9JbmZvcm1hdGlvbiBUZWNobm9sb2d5 IFNlcnZpY2VzMRswGQYDVQQDExJDZXJ0aWZpY2F0ZSBTZXJ2ZXICASowDQYJKoZIhvcNAQEB BQAEQBR5b7OWcB8TFlQROoZWWE75NqRGX+i/go4Lpm7xZUAGSg2dxAnqt+JO4orgFh6t1NwF RkWxXVi/MYGD69a0xQ0AAAAAAAA= --------------ms070500050104000400010807-- From owner-freebsd-current@FreeBSD.ORG Tue Apr 26 03:46: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 F3D1916A4CE for ; Tue, 26 Apr 2005 03:46:41 +0000 (GMT) Received: from carver.gumbysoft.com (carver.gumbysoft.com [66.220.23.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 921E243D48 for ; Tue, 26 Apr 2005 03:46:41 +0000 (GMT) (envelope-from dwhite@gumbysoft.com) Received: by carver.gumbysoft.com (Postfix, from userid 1000) id 84F9172DE5; Mon, 25 Apr 2005 20:46:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by carver.gumbysoft.com (Postfix) with ESMTP id 8032572DE4; Mon, 25 Apr 2005 20:46:41 -0700 (PDT) Date: Mon, 25 Apr 2005 20:46:41 -0700 (PDT) From: Doug White To: Matthew Sullivan In-Reply-To: <426DB58B.5020608@uq.edu.au> Message-ID: <20050425204148.H43358@carver.gumbysoft.com> References: <4267A1CF.3080903@uq.edu.au> <20050422190208.M68772@lexi.siliconlandmark.com> <426C93AC.3030907@root.org> <20050425200601.I42718@carver.gumbysoft.com> <426DB58B.5020608@uq.edu.au> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-current@freebsd.org cc: Nate Lawson Subject: Re: SMP on Compaq DL380 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 26 Apr 2005 03:46:42 -0000 On Tue, 26 Apr 2005, Matthew Sullivan wrote: > >>>There definitely is a problem when you have identical APIC ids. We > >>>already blacklist one version of this BIOS. > >>> > >>That's not something I wanted to here right now... :-( > > > >Are you __sure__ you're booting the right kernel? > >http://scorpion.sorbs.net/dmesg.txt shows a kernel that does not have SMP > >nor APIC enabled. I'm still seeing ISA interrupt routing rather than APIC > >mappings. And as noted previously the APIC IDs are not set which means > >they are not enabled. (APIC IDs are always >0.) > > > >What is the output of 'sysctl kern.smp'? > > > > > kern.smp.maxcpus: 16 > kern.smp.active: 0 > kern.smp.disabled: 0 > kern.smp.cpus: 1 > kern.smp.forward_signal_enabled: 1 > kern.smp.forward_roundrobin_enabled: 1 You're booting the wrong kernel. Do a buildkernel + installkernel now, reboot the system, and check that the kernel's build date has incremented. Also watch the loader output and make sure someone hasn't overridden the kernel name in loader.conf. > >Have you tried booting without ACPI? > > > > > No, but I am doing now... > > Btw now I have remote console this is what the BIOS shows.... > > 1024 MB Detected > > COMPAQ System BIOS - P17 (12/18/2002) > Copyright 1982,2002 Compaq Computer Corporation. All rights reserved. This appears to be the latest BIOS. Some Compaq systems are known to generate bogus MPTables and such when configured to run Windows. You might poke around the BIOS Setup and see if there is an "OS Type" field that can be set to "SCO UNIX" or "Other" (not in PnP setup probably). > Boot without ACPI is show at http://scorpion.sorbs.net/dmesg-noacpi.txt > > kern.smp.maxcpus: 16 > kern.smp.active: 0 > kern.smp.disabled: 0 > kern.smp.cpus: 1 > kern.smp.forward_signal_enabled: 1 > kern.smp.forward_roundrobin_enabled: 1 > > I'm going to recompile the kernel again - with the current config - just > to prove it's there... Good idea :) -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Tue Apr 26 03:55: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 1E77916A4CE for ; Tue, 26 Apr 2005 03:55:42 +0000 (GMT) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id BA7E443D48 for ; Tue, 26 Apr 2005 03:55:41 +0000 (GMT) (envelope-from fierykylin@gmail.com) Received: by zproxy.gmail.com with SMTP id 40so1798834nzk for ; Mon, 25 Apr 2005 20:55:41 -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=IT2KHc52p6X6MVXLY1KkjnR3Lx/fkjK40RTBxSzrnDOIYLHxPh9sOKXcQYIR+6YjX8AzY2rdRNinRmH6V+ZeQt0DljovZxhTUQneB7iWGnDqgOAhsMm2+Os5+pdI6L2uPZznkQ4thLREx86KqtOZlLTvUez/0NqDzMg7py4s5e8= Received: by 10.36.108.14 with SMTP id g14mr564135nzc; Mon, 25 Apr 2005 20:55:41 -0700 (PDT) Received: by 10.36.104.6 with HTTP; Mon, 25 Apr 2005 20:55:41 -0700 (PDT) Message-ID: <87ab37ab050425205527cecaf3@mail.gmail.com> Date: Tue, 26 Apr 2005 11:55:41 +0800 From: kylin 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: when will pci hotplug in Freebsd X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: kylin List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2005 03:55:42 -0000 hello,every one , just now i have read the FreeBSD status report of march and april ,also ,i have read the "plan for next 12 months"by o'Dell it is a pity that i do not see any thing about the pci hotplug which i am very interested in , so ,I wonder if the freebsd 5.4 or later version will support PCI hotplug, if there is long time enought before the official providing utility,i may develop it on my own, or i will just wait asn see :) welcom to give me some advice! thank u:) --=20 we who r about to die,salute u! From owner-freebsd-current@FreeBSD.ORG Tue Apr 26 04: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 D625316A4CE for ; Tue, 26 Apr 2005 04:15:49 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2B6F943D1D for ; Tue, 26 Apr 2005 04:15:49 +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.3/8.13.3) with ESMTP id j3Q4KSIn007952; Mon, 25 Apr 2005 22:20:28 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <426DBFA7.5020605@samsco.org> Date: Mon, 25 Apr 2005 22:12:23 -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: kylin References: <87ab37ab050425205527cecaf3@mail.gmail.com> In-Reply-To: <87ab37ab050425205527cecaf3@mail.gmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.8 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on pooker.samsco.org cc: freebsd-current@freebsd.org Subject: Re: when will pci hotplug 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, 26 Apr 2005 04:15:49 -0000 kylin wrote: > hello,every one , > just now i have read the FreeBSD status report of march and april > ,also ,i have read the "plan for next 12 months"by o'Dell > it is a pity that i do not see any thing about the pci hotplug which i > am very interested in , > so ,I wonder if the freebsd 5.4 or later version will support PCI > hotplug, if there is long time enought before the official providing > utility,i may develop it on my own, or i will just wait asn see :) > welcom to give me some advice! > thank u:) > > > Which PCI Hotplug do you want? Do you want the one ACPI version that in only supported on a few ia64 systems? Do you want the PCI-SIG version that's supported by no one? Or do you want the Compaq version that isn't documented except in Linux driver sources? What about the Dell version? Or IBM? Also, do you want storage and network devices to behave correctly when they are hot-pulled? The work here is far from trivial, but I'd happily accept volunteers that want to start on it =-) Scott From owner-freebsd-current@FreeBSD.ORG Tue Apr 26 05:03: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 2C72016A4CE; Tue, 26 Apr 2005 05:03:34 +0000 (GMT) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9609B43D39; Tue, 26 Apr 2005 05:03:33 +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 j3Q53XD8027611; Tue, 26 Apr 2005 01:03: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 j3Q53Xk9026361; Tue, 26 Apr 2005 01:03:33 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id CA8DA7306E; Tue, 26 Apr 2005 01:03:32 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050426050332.CA8DA7306E@freebsd-current.sentex.ca> Date: Tue, 26 Apr 2005 01:03:32 -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 alpha/alpha 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, 26 Apr 2005 05:03:34 -0000 TB --- 2005-04-26 04:45:01 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-04-26 04:45:01 - starting CURRENT tinderbox run for alpha/alpha TB --- 2005-04-26 04:45:01 - checking out the source tree TB --- 2005-04-26 04:45:01 - cd /home/tinderbox/CURRENT/alpha/alpha TB --- 2005-04-26 04:45:01 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-04-26 05:02:06 - building world (CFLAGS=-O2 -pipe) TB --- 2005-04-26 05:02:06 - cd /home/tinderbox/CURRENT/alpha/alpha/src TB --- 2005-04-26 05:02:06 - /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 [...] ===> rescue/rescue/ipf/ipnat (clean) rm -f ipnat_y.c ipnat_y.h ipnat_l.c ipnat_l.h y.tab.c y.tab.h ipnat ipnat.o ipnat_y.o ipnat_l.o ipnat.8.gz ipnat.4.gz ipnat.5.gz ipnat.8.cat.gz ipnat.4.cat.gz ipnat.5.cat.gz ===> rescue/rescue/ipf/ippool (clean) rm -f ippool_y.c ippool_y.h ippool_l.c ippool_l.h y.tab.c y.tab.h ippool ippool_y.o ippool_l.o kmem.o ippool.o ippool.5.gz ippool.8.gz ippool.5.cat.gz ippool.8.cat.gz ===> rescue/rescue/ipf/ipresend (clean) rm -f y.tab.c y.tab.h ipresend ipresend.o ip.o resend.o sbpf.o sock.o 44arp.o ipresend.1.gz ipresend.1.cat.gz cd /tinderbox/CURRENT/alpha/alpha/src/rescue/rescue/../../sbin/ipfs && MAKEOBJDIRPREFIX=/home/tinderbox/CURRENT/alpha/alpha/obj/alpha/tinderbox/CURRENT/alpha/alpha/src/rescue/rescue /home/tinderbox/CURRENT/alpha/alpha/obj/tinderbox/CURRENT/alpha/alpha/src/make.i386/make DIRPRFX=rescue/rescue/ipfs/ clean cd: can't cd to /tinderbox/CURRENT/alpha/alpha/src/rescue/rescue/../../sbin/ipfs *** Error code 2 Stop in /tinderbox/CURRENT/alpha/alpha/src/rescue/rescue. *** Error code 1 Stop in /tinderbox/CURRENT/alpha/alpha/src/rescue. *** Error code 1 Stop in /tinderbox/CURRENT/alpha/alpha/src. *** Error code 1 Stop in /tinderbox/CURRENT/alpha/alpha/src. *** Error code 1 Stop in /tinderbox/CURRENT/alpha/alpha/src. TB --- 2005-04-26 05:03:32 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-04-26 05:03:32 - ERROR: failed to build world TB --- 2005-04-26 05:03:32 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Tue Apr 26 05:06: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 DAAF716A4CE; Tue, 26 Apr 2005 05:06:14 +0000 (GMT) Received: from fast.dnswatch.com (fast.dnswatch.com [216.177.243.43]) by mx1.FreeBSD.org (Postfix) with ESMTP id 48FCD43D1F; Tue, 26 Apr 2005 05:06:14 +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 j3Q56Asm051997; Mon, 25 Apr 2005 22:06:14 -0700 (PDT) (envelope-from null@dnswatch.com) Received: (from www@localhost) by fast.dnswatch.com (8.12.6/8.12.6/Submit) id j3Q569km051996; Mon, 25 Apr 2005 22:06:09 -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; Mon, 25 Apr 2005 22:06:08 -0700 (PDT) Message-ID: <61277.216.177.243.35.1114491968.localmail@webmail.dnswatch.com> In-Reply-To: <20050425163830.D37447@sasami.jurai.net> References: <20050425171528.7EF8B16A4D3@hub.freebsd.org><2308.216.177.243.38.1114456660.localmail@webmail.dnswatch.com> <20050425161211.X37447@sasami.jurai.net><2439.216.177.243.38.1114461241.localmail@webmail.dnswatch.com> <20050425163830.D37447@sasami.jurai.net> Date: Mon, 25 Apr 2005 22:06:08 -0700 (PDT) From: "/dev/null" To: "Matthew N. Dodd" 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 cc: freebsd-current@FreeBSD.ORG Subject: Re: Too Evil, Too Furious X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 26 Apr 2005 05:06:15 -0000 Greatly appreciated! No matter *what* shape you consider it. I'll be glad to have the jump-start on it. Thanks, Chris > On Mon, 25 Apr 2005, /dev/null wrote: >> Really?! I spent an entire week (I mean the whole week - 12hrs/ day) >> looking for something to get these boards to work. There was some >> indication that Compaq was sponsoring work on these cards for Linux. >> But that Compaq OpenSource sponsorship seems to have mostly vanished. :\ >> >> Sure! I'd love to give it a try. > > http://www.jurai.net/~winter/tr/tms380.html > ftp://ftp.jurai.net/users/winter/tez.tar.gz > > Keep in mind that this is quite old and was some of my first driver code. > > - The locking is rather half-assed as I recall. > - No-BUSDMA. > - No real knowledge of ethernet. > > -- > 10 40 80 C0 00 FF FF FF FF C0 00 00 00 00 10 AA AA 03 00 00 00 08 00 > //////////////////////////////////////////////////// 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 Tue Apr 26 05:19: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 5D8A016A4CE; Tue, 26 Apr 2005 05:19:14 +0000 (GMT) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id CA4F643D31; Tue, 26 Apr 2005 05:19:13 +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 j3Q5JDYr028150; Tue, 26 Apr 2005 01:19:13 -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 j3Q5JfZp016207; Tue, 26 Apr 2005 01:19:42 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 673CD7306E; Tue, 26 Apr 2005 01:19:12 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050426051912.673CD7306E@freebsd-current.sentex.ca> Date: Tue, 26 Apr 2005 01:19:12 -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 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, 26 Apr 2005 05:19:14 -0000 TB --- 2005-04-26 05:03:32 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-04-26 05:03:32 - starting CURRENT tinderbox run for amd64/amd64 TB --- 2005-04-26 05:03:32 - checking out the source tree TB --- 2005-04-26 05:03:32 - cd /home/tinderbox/CURRENT/amd64/amd64 TB --- 2005-04-26 05:03:32 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-04-26 05:17:53 - building world (CFLAGS=-O2 -pipe) TB --- 2005-04-26 05:17:53 - cd /home/tinderbox/CURRENT/amd64/amd64/src TB --- 2005-04-26 05:17:53 - /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 [...] ===> rescue/rescue/ipf/ipnat (clean) rm -f ipnat_y.c ipnat_y.h ipnat_l.c ipnat_l.h y.tab.c y.tab.h ipnat ipnat.o ipnat_y.o ipnat_l.o ipnat.8.gz ipnat.4.gz ipnat.5.gz ipnat.8.cat.gz ipnat.4.cat.gz ipnat.5.cat.gz ===> rescue/rescue/ipf/ippool (clean) rm -f ippool_y.c ippool_y.h ippool_l.c ippool_l.h y.tab.c y.tab.h ippool ippool_y.o ippool_l.o kmem.o ippool.o ippool.5.gz ippool.8.gz ippool.5.cat.gz ippool.8.cat.gz ===> rescue/rescue/ipf/ipresend (clean) rm -f y.tab.c y.tab.h ipresend ipresend.o ip.o resend.o sbpf.o sock.o 44arp.o ipresend.1.gz ipresend.1.cat.gz cd /tinderbox/CURRENT/amd64/amd64/src/rescue/rescue/../../sbin/ipfs && MAKEOBJDIRPREFIX=/home/tinderbox/CURRENT/amd64/amd64/obj/amd64/tinderbox/CURRENT/amd64/amd64/src/rescue/rescue /home/tinderbox/CURRENT/amd64/amd64/obj/tinderbox/CURRENT/amd64/amd64/src/make.i386/make DIRPRFX=rescue/rescue/ipfs/ clean cd: can't cd to /tinderbox/CURRENT/amd64/amd64/src/rescue/rescue/../../sbin/ipfs *** Error code 2 Stop in /tinderbox/CURRENT/amd64/amd64/src/rescue/rescue. *** Error code 1 Stop in /tinderbox/CURRENT/amd64/amd64/src/rescue. *** 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-26 05:19:12 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-04-26 05:19:12 - ERROR: failed to build world TB --- 2005-04-26 05:19:12 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Tue Apr 26 05:27: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 5076916A4D2; Tue, 26 Apr 2005 05:27:36 +0000 (GMT) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 77C8D43D64; Tue, 26 Apr 2005 05:27:35 +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 j3Q5RZ50028335; Tue, 26 Apr 2005 01:27: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 j3Q5RZOd033790; Tue, 26 Apr 2005 01:27:35 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id C1DEC7306E; Tue, 26 Apr 2005 01:27:34 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050426052734.C1DEC7306E@freebsd-current.sentex.ca> Date: Tue, 26 Apr 2005 01:27: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 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: Tue, 26 Apr 2005 05:27:36 -0000 TB --- 2005-04-26 05:19:12 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-04-26 05:19:12 - starting CURRENT tinderbox run for i386/i386 TB --- 2005-04-26 05:19:12 - checking out the source tree TB --- 2005-04-26 05:19:12 - cd /home/tinderbox/CURRENT/i386/i386 TB --- 2005-04-26 05:19:12 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-04-26 05:26:11 - building world (CFLAGS=-O2 -pipe) TB --- 2005-04-26 05:26:11 - cd /home/tinderbox/CURRENT/i386/i386/src TB --- 2005-04-26 05:26:11 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree [...] ===> rescue/rescue/ipf/ipnat (clean) rm -f ipnat_y.c ipnat_y.h ipnat_l.c ipnat_l.h y.tab.c y.tab.h ipnat ipnat.o ipnat_y.o ipnat_l.o ipnat.8.gz ipnat.4.gz ipnat.5.gz ipnat.8.cat.gz ipnat.4.cat.gz ipnat.5.cat.gz ===> rescue/rescue/ipf/ippool (clean) rm -f ippool_y.c ippool_y.h ippool_l.c ippool_l.h y.tab.c y.tab.h ippool ippool_y.o ippool_l.o kmem.o ippool.o ippool.5.gz ippool.8.gz ippool.5.cat.gz ippool.8.cat.gz ===> rescue/rescue/ipf/ipresend (clean) rm -f y.tab.c y.tab.h ipresend ipresend.o ip.o resend.o sbpf.o sock.o 44arp.o ipresend.1.gz ipresend.1.cat.gz cd /tinderbox/CURRENT/i386/i386/src/rescue/rescue/../../sbin/ipfs && MAKEOBJDIRPREFIX=/home/tinderbox/CURRENT/i386/i386/obj/tinderbox/CURRENT/i386/i386/src/rescue/rescue /home/tinderbox/CURRENT/i386/i386/obj/tinderbox/CURRENT/i386/i386/src/make.i386/make DIRPRFX=rescue/rescue/ipfs/ clean cd: can't cd to /tinderbox/CURRENT/i386/i386/src/rescue/rescue/../../sbin/ipfs *** Error code 2 Stop in /tinderbox/CURRENT/i386/i386/src/rescue/rescue. *** Error code 1 Stop in /tinderbox/CURRENT/i386/i386/src/rescue. *** 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-26 05:27:34 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-04-26 05:27:34 - ERROR: failed to build world TB --- 2005-04-26 05:27:34 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Tue Apr 26 05:32: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 ECD3916A4CE for ; Tue, 26 Apr 2005 05:32:28 +0000 (GMT) Received: from sasami.jurai.net (sasami.jurai.net [69.17.104.113]) by mx1.FreeBSD.org (Postfix) with ESMTP id 720C443D39 for ; Tue, 26 Apr 2005 05:32:28 +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 j3Q5WGCs062911; Tue, 26 Apr 2005 01:32:18 -0400 (EDT) (envelope-from mdodd@FreeBSD.ORG) Date: Tue, 26 Apr 2005 01:32:16 -0400 (EDT) From: "Matthew N. Dodd" X-X-Sender: winter@sasami.jurai.net To: /dev/null In-Reply-To: <61277.216.177.243.35.1114491968.localmail@webmail.dnswatch.com> Message-ID: <20050426013150.N37447@sasami.jurai.net> References: <20050425171528.7EF8B16A4D3@hub.freebsd.org><2308.216.177.243.38.1114456660.localmail@webmail.dnswatch.com> <20050425161211.X37447@sasami.jurai.net><2439.216.177.243.38.1114461241.localmail@webmail.dnswatch.com> <20050425163830.D37447@sasami.jurai.net> <61277.216.177.243.35.1114491968.localmail@webmail.dnswatch.com> 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]); Tue, 26 Apr 2005 01:32:18 -0400 (EDT) cc: freebsd-current@FreeBSD.ORG Subject: Re: Too Evil, Too Furious X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 26 Apr 2005 05:32:29 -0000 On Mon, 25 Apr 2005, /dev/null wrote: > Greatly appreciated! No matter *what* shape you consider it. I'll be > glad to have the jump-start on it. Have fun. I just wish I had the time to rewrite it myself. -- 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 Tue Apr 26 05:35: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 90C5016A4CE for ; Tue, 26 Apr 2005 05:35:46 +0000 (GMT) Received: from fast.dnswatch.com (fast.dnswatch.com [216.177.243.43]) by mx1.FreeBSD.org (Postfix) with ESMTP id 05D1143D1F for ; Tue, 26 Apr 2005 05:35:46 +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 j3Q5Zjsm052507 for ; Mon, 25 Apr 2005 22:35:46 -0700 (PDT) (envelope-from null@dnswatch.com) Received: (from www@localhost) by fast.dnswatch.com (8.12.6/8.12.6/Submit) id j3Q5ZjTC052506; Mon, 25 Apr 2005 22:35:45 -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; Mon, 25 Apr 2005 22:35:44 -0700 (PDT) Message-ID: <55302.216.177.243.35.1114493744.localmail@webmail.dnswatch.com> In-Reply-To: <20050425213435.54ED416A4CF@hub.freebsd.org> References: <2308.216.177.243.38.1114456660.localmail@webmail.dnswatch.com> from /dev/null at "Apr 25, 2005 12:17:40 pm" <20050425213435.54ED416A4CF@hub.freebsd.org> Date: Mon, 25 Apr 2005 22:35:44 -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: Too Evil, Too Furious X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 26 Apr 2005 05:35:46 -0000 > >> I see there are about 50 D-Link DWL-G510 802.11g Wireless PCI Adapter >> Cards >> available on Ebay. They aren't but about $16.00 US. I'd be willing to >> pick >> one up and send it to you. What do I need to ask the seller to ensure >> that >> I get the right one? I haven't tried looking for the other cards on your >> list yet. But I got to thinking that most of the sellers on Ebay are >> pretty >> helpful. So if one wanted to know about the card they are selling - >> where >> they got it, what it looks like, etc... that might be an added resource >> in helping you in your quest. > > Well, the problem, see, is I don't know exactly how to identify which > cards I need, which is why I was asking people to describe to me the > ones the had. :) "- Marvell wireless -- supposedly D-Link used this on a card called the DWL-G510, but only on the first revision." So if I understood you correctly, all I needed to do was to ask if the one they are selling was "first revision". This was my understanding based on the info you provided above. Sorry, my mistake. > > I'm not interested in getting stuff off eBay anyway. eBay is the debbil. > And not in a good way. > > It looks like I have an offer for a bunch of stuff, so for now it seems > Project Evil's hardware needs will be met. > >> I was also wondering if Project Evil will >> suport the Compaq 32-bit NetFlex-2 controllers? I got a Compaq EISA box >> some time ago and a whole bunch of the Netflex-2 cards with the >> intention >> of making a FreeBSD Switch out of it. But I wasn't thinking or I >> wouldn't >> have *assumed* that FBSD supported the Netflex-2 card. >> Anyway, still have all the eqpt. and think it would be a worthy project >> that I'd love to complete. Oh, one more thing; if it would be of any >> help, >> I can cough up an IP and a remote box that you can have *complete* >> control >> of if you like. > > Project Evil only supports cardbus, PCI and (to some small extent) > PCMCIA. I have plans to make it support USB. But EISA? Sorry, can't help > you. Nobody makes Windows XP drivers for EISAbus devices. :/ Interesting, I'm running it on one of the 2 Compaq + Netflex-2 boxes as I speak. Looks as though I'll have to wait until you finish it. So that I can coerce it for my (others?) needs as well. P.S. The offer for the IP and remote box was not contingent on you doing the Netflex-2 card. But I suppose it wouldn't be of much use except to test a card in it. Just trying to help. Best wishes. -Chris > > -Bill > > -- > ============================================================================= > -Bill Paul (510) 749-2329 | Senior Engineer, Master of Unix-Fu > wpaul@windriver.com | Wind River Systems > ============================================================================= > you're just BEGGING to face the moose > ============================================================================= > //////////////////////////////////////////////////// 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 Tue Apr 26 05:36: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 3C64816A4CE; Tue, 26 Apr 2005 05:36:07 +0000 (GMT) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7BCDF43D2D; Tue, 26 Apr 2005 05:36:06 +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 j3Q5a6Dq021663; Tue, 26 Apr 2005 01:36:06 -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 j3Q5aZD4021850; Tue, 26 Apr 2005 01:36:35 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id C67A07306E; Tue, 26 Apr 2005 01:36:05 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050426053605.C67A07306E@freebsd-current.sentex.ca> Date: Tue, 26 Apr 2005 01:36:05 -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: Tue, 26 Apr 2005 05:36:07 -0000 TB --- 2005-04-26 05:27:35 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-04-26 05:27:35 - starting CURRENT tinderbox run for i386/pc98 TB --- 2005-04-26 05:27:35 - checking out the source tree TB --- 2005-04-26 05:27:35 - cd /home/tinderbox/CURRENT/i386/pc98 TB --- 2005-04-26 05:27:35 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-04-26 05:34:41 - building world (CFLAGS=-O2 -pipe) TB --- 2005-04-26 05:34:41 - cd /home/tinderbox/CURRENT/i386/pc98/src TB --- 2005-04-26 05:34:41 - /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 [...] ===> rescue/rescue/ipf/ipnat (clean) rm -f ipnat_y.c ipnat_y.h ipnat_l.c ipnat_l.h y.tab.c y.tab.h ipnat ipnat.o ipnat_y.o ipnat_l.o ipnat.8.gz ipnat.4.gz ipnat.5.gz ipnat.8.cat.gz ipnat.4.cat.gz ipnat.5.cat.gz ===> rescue/rescue/ipf/ippool (clean) rm -f ippool_y.c ippool_y.h ippool_l.c ippool_l.h y.tab.c y.tab.h ippool ippool_y.o ippool_l.o kmem.o ippool.o ippool.5.gz ippool.8.gz ippool.5.cat.gz ippool.8.cat.gz ===> rescue/rescue/ipf/ipresend (clean) rm -f y.tab.c y.tab.h ipresend ipresend.o ip.o resend.o sbpf.o sock.o 44arp.o ipresend.1.gz ipresend.1.cat.gz cd /tinderbox/CURRENT/i386/pc98/src/rescue/rescue/../../sbin/ipfs && MAKEOBJDIRPREFIX=/home/tinderbox/CURRENT/i386/pc98/obj/pc98/tinderbox/CURRENT/i386/pc98/src/rescue/rescue /home/tinderbox/CURRENT/i386/pc98/obj/tinderbox/CURRENT/i386/pc98/src/make.i386/make DIRPRFX=rescue/rescue/ipfs/ clean cd: can't cd to /tinderbox/CURRENT/i386/pc98/src/rescue/rescue/../../sbin/ipfs *** Error code 2 Stop in /tinderbox/CURRENT/i386/pc98/src/rescue/rescue. *** Error code 1 Stop in /tinderbox/CURRENT/i386/pc98/src/rescue. *** 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-26 05:36:05 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-04-26 05:36:05 - ERROR: failed to build world TB --- 2005-04-26 05:36:05 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Tue Apr 26 05:53: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 574C316A4CE; Tue, 26 Apr 2005 05:53:28 +0000 (GMT) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id C28D743D1D; Tue, 26 Apr 2005 05:53:27 +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 j3Q5rRin028904; Tue, 26 Apr 2005 01:53:27 -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 j3Q5rRcD045569; Tue, 26 Apr 2005 01:53:27 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 17F977306E; Tue, 26 Apr 2005 01:53:26 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050426055326.17F977306E@freebsd-current.sentex.ca> Date: Tue, 26 Apr 2005 01:53:26 -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 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, 26 Apr 2005 05:53:28 -0000 TB --- 2005-04-26 05:36:06 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-04-26 05:36:06 - starting CURRENT tinderbox run for ia64/ia64 TB --- 2005-04-26 05:36:06 - checking out the source tree TB --- 2005-04-26 05:36:06 - cd /home/tinderbox/CURRENT/ia64/ia64 TB --- 2005-04-26 05:36:06 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-04-26 05:51:58 - building world (CFLAGS=-O2 -pipe) TB --- 2005-04-26 05:51:58 - cd /home/tinderbox/CURRENT/ia64/ia64/src TB --- 2005-04-26 05:51:58 - /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 [...] ===> rescue/rescue/ipf/ipnat (clean) rm -f ipnat_y.c ipnat_y.h ipnat_l.c ipnat_l.h y.tab.c y.tab.h ipnat ipnat.o ipnat_y.o ipnat_l.o ipnat.8.gz ipnat.4.gz ipnat.5.gz ipnat.8.cat.gz ipnat.4.cat.gz ipnat.5.cat.gz ===> rescue/rescue/ipf/ippool (clean) rm -f ippool_y.c ippool_y.h ippool_l.c ippool_l.h y.tab.c y.tab.h ippool ippool_y.o ippool_l.o kmem.o ippool.o ippool.5.gz ippool.8.gz ippool.5.cat.gz ippool.8.cat.gz ===> rescue/rescue/ipf/ipresend (clean) rm -f y.tab.c y.tab.h ipresend ipresend.o ip.o resend.o sbpf.o sock.o 44arp.o ipresend.1.gz ipresend.1.cat.gz cd /tinderbox/CURRENT/ia64/ia64/src/rescue/rescue/../../sbin/ipfs && MAKEOBJDIRPREFIX=/home/tinderbox/CURRENT/ia64/ia64/obj/ia64/tinderbox/CURRENT/ia64/ia64/src/rescue/rescue /home/tinderbox/CURRENT/ia64/ia64/obj/tinderbox/CURRENT/ia64/ia64/src/make.i386/make DIRPRFX=rescue/rescue/ipfs/ clean cd: can't cd to /tinderbox/CURRENT/ia64/ia64/src/rescue/rescue/../../sbin/ipfs *** Error code 2 Stop in /tinderbox/CURRENT/ia64/ia64/src/rescue/rescue. *** Error code 1 Stop in /tinderbox/CURRENT/ia64/ia64/src/rescue. *** Error code 1 Stop in /tinderbox/CURRENT/ia64/ia64/src. *** Error code 1 Stop in /tinderbox/CURRENT/ia64/ia64/src. *** Error code 1 Stop in /tinderbox/CURRENT/ia64/ia64/src. TB --- 2005-04-26 05:53:26 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-04-26 05:53:26 - ERROR: failed to build world TB --- 2005-04-26 05:53:26 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Tue Apr 26 06:02: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 C871E16A4CE for ; Tue, 26 Apr 2005 06:02:10 +0000 (GMT) Received: from sb.santaba.com (sb.santaba.com [207.154.84.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9E21D43D1D for ; Tue, 26 Apr 2005 06:02:10 +0000 (GMT) (envelope-from jbehl@fastclick.com) Received: from [192.168.1.2] (ip68-6-38-163.sb.sd.cox.net [68.6.38.163]) by sb.santaba.com (Postfix) with ESMTP id 58C4F2848B; Mon, 25 Apr 2005 23:02:10 -0700 (PDT) Message-ID: <426DD965.4010106@fastclick.com> Date: Mon, 25 Apr 2005 23:02:13 -0700 From: Jeff Behl User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Julian Elischer References: <426D4179.1020508@fastclick.com> <426D59F5.4070601@elischer.org> <426D5C93.4020802@fastclick.com> <426D5F94.1000302@elischer.org> In-Reply-To: <426D5F94.1000302@elischer.org> X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: current@freebsd.org Subject: Re: serial/ether console & ramblings X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 26 Apr 2005 06:02:10 -0000 Julian Elischer wrote: > > > Jeff Behl wrote: > >>>> but my whole point is that nothing in 1) works remotely (out of band) >>>> when the system and the BMC share the same ethernet controller, at >>>> least >>>> with the bge driver. as i mentioned in the thread, i can power cycle >>>> and see the serial console remotely (number 2 from above) all the >>>> way up >>>> to the point where the kernel loads. as soon as it does, the bge >>>> driver >>>> no longer shunts off RMCP packets (what IPMI uses) to the Baseboard >>>> Management Controller, so no IPMI... >>>> >>>> >>>> >>> >>> the intel MBs allow you to share the 10/100 ethernet with the IPMI >>> controller. >>> >>> >> >> >> as do the motherboards with the e325s. we can to everything out of band >> when running linux, but that's because the driver for the broadcom nics >> in linux are aware of the BMC... >> >> > > I run the intels with FreeBSD OOB without any problems. what interface driver is being used? that'd be nifty if the motherboard had first dibs on a packet, but i didn't realize that was the way it could work. the linux bge driver certainly has code in it specifically for RMCP packets... From owner-freebsd-current@FreeBSD.ORG Tue Apr 26 06: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 33A5E16A4CE for ; Tue, 26 Apr 2005 06:09:10 +0000 (GMT) Received: from mail.sorbs.net (news.sorbs.net [203.15.51.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id 86C2043D4C for ; Tue, 26 Apr 2005 06:09:09 +0000 (GMT) (envelope-from matthew@uq.edu.au) Received: from [130.102.152.118] (stealthd.its.uq.edu.au [130.102.152.118]) by nemesis.sorbs.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0IFJ00I02IFZJF@nemesis.sorbs.net> for freebsd-current@freebsd.org; Tue, 26 Apr 2005 16:09:36 +1000 (EST) Date: Tue, 26 Apr 2005 16:07:59 +1000 From: Matthew Sullivan In-reply-to: <20050425204148.H43358@carver.gumbysoft.com> To: Doug White Message-id: <426DDABF.8050708@uq.edu.au> MIME-version: 1.0 Content-type: multipart/signed; boundary=------------ms030902050109060206060207; micalg=sha1; protocol="application/x-pkcs7-signature" X-Accept-Language: en User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041231 References: <4267A1CF.3080903@uq.edu.au> <20050422190208.M68772@lexi.siliconlandmark.com> <426C93AC.3030907@root.org> <20050425200601.I42718@carver.gumbysoft.com> <426DB58B.5020608@uq.edu.au> <20050425204148.H43358@carver.gumbysoft.com> cc: freebsd-current@freebsd.org cc: Nate Lawson Subject: Re: SMP on Compaq DL380 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 26 Apr 2005 06:09:10 -0000 This is a cryptographically signed message in MIME format. --------------ms030902050109060206060207 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Doug White wrote: >On Tue, 26 Apr 2005, Matthew Sullivan wrote: > > > >>>>>There definitely is a problem when you have identical APIC ids. We >>>>>already blacklist one version of this BIOS. >>>>> >>>>> >>>>> >>>>That's not something I wanted to here right now... :-( >>>> >>>> >>>Are you __sure__ you're booting the right kernel? >>>http://scorpion.sorbs.net/dmesg.txt shows a kernel that does not have SMP >>>nor APIC enabled. I'm still seeing ISA interrupt routing rather than APIC >>>mappings. And as noted previously the APIC IDs are not set which means >>>they are not enabled. (APIC IDs are always >0.) >>> >>>What is the output of 'sysctl kern.smp'? >>> >>> >>> >>> >>kern.smp.maxcpus: 16 >>kern.smp.active: 0 >>kern.smp.disabled: 0 >>kern.smp.cpus: 1 >>kern.smp.forward_signal_enabled: 1 >>kern.smp.forward_roundrobin_enabled: 1 >> >> > >You're booting the wrong kernel. Do a buildkernel + installkernel now, >reboot the system, and check that the kernel's build date has incremented. >Also watch the loader output and make sure someone hasn't overridden the >kernel name in loader.conf. > > > >>>Have you tried booting without ACPI? >>> >>> >>> >>> >>No, but I am doing now... >> >>Btw now I have remote console this is what the BIOS shows.... >> >> 1024 MB Detected >> >>COMPAQ System BIOS - P17 (12/18/2002) >>Copyright 1982,2002 Compaq Computer Corporation. All rights reserved. >> >> > >This appears to be the latest BIOS. Some Compaq systems are known to >generate bogus MPTables and such when configured to run Windows. You might >poke around the BIOS Setup and see if there is an "OS Type" field that can >be set to "SCO UNIX" or "Other" (not in PnP setup probably). > > > >>Boot without ACPI is show at http://scorpion.sorbs.net/dmesg-noacpi.txt >> >>kern.smp.maxcpus: 16 >>kern.smp.active: 0 >>kern.smp.disabled: 0 >>kern.smp.cpus: 1 >>kern.smp.forward_signal_enabled: 1 >>kern.smp.forward_roundrobin_enabled: 1 >> >>I'm going to recompile the kernel again - with the current config - just >>to prove it's there... >> >> > >Good idea :) > > > Ok, after building we have: root@scorpion:~# uname -a FreeBSD scorpion.sorbs.net 5.3-RELEASE-p9 FreeBSD 5.3-RELEASE-p9 #0: Tue Apr 26 14:35:20 EST 2005 root@scorpion.sorbs.net:/usr/obj/usr/src/sys/SCORPION i386 (why not #1..?) the build date is current, the config file is at: http://scorpion.sorbs.net/SMP/SCORPION dmesg from boot -v is at: http://scorpion.sorbs.net/SMP/dmesg-v.txt acpidump -t -d is at: http://scorpion.sorbs.net/SMP/acpidump-t-d.txt sysclt -a is at: http://scorpion.sorbs.net/SMP/sysctl-a.txt Have I forgotten anything? (I haven't done a non-acpi boot from this new kernel) Regards, -- Matthew Sullivan Specialist Systems Programmer Information Technology Services The University of Queensland --------------ms030902050109060206060207 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIG7DCC A3IwggJaoAMCAQICASowDQYJKoZIhvcNAQEEBQAwgaMxCzAJBgNVBAYTAkFVMRMwEQYDVQQI EwpRdWVlbnNsYW5kMREwDwYDVQQHEwhCcmlzYmFuZTElMCMGA1UEChMcVGhlIFVuaXZlcnNp dHkgb2YgUXVlZW5zbGFuZDEoMCYGA1UECxMfSW5mb3JtYXRpb24gVGVjaG5vbG9neSBTZXJ2 aWNlczEbMBkGA1UEAxMSQ2VydGlmaWNhdGUgU2VydmVyMB4XDTA0MDEyMTIzMzYyMVoXDTA2 MDEyMTIzMzYyMVowgbIxCzAJBgNVBAYTAkFVMSUwIwYDVQQKExxUaGUgVW5pdmVyc2l0eSBv ZiBRdWVlbnNsYW5kMScwJQYDVQQLEx5JbmZvcm1hdGlvbiBUZWNub2xvZ3kgU2VydmljZXMx FjAUBgoJkiaJk/IsZAEBEwZjY21hdHQxGTAXBgNVBAMTEE1hdHRoZXcgU3VsbGl2YW4xIDAe BgkqhkiG9w0BCQEWEW1hdHRoZXdAdXEuZWR1LmF1MFwwDQYJKoZIhvcNAQEBBQADSwAwSAJB AJsUfrw/QUqKIzDverWc2F4GFFRZmIeO+bAl+7BM6x/9frMzOtygx4QGb4oQwtOE8Sda1aIs v+yJF3Di9EuUyvMCAwEAAaNoMGYwDgYDVR0PAQH/BAQDAgXgMBEGCWCGSAGG+EIBAQQEAwIF oDAfBgNVHSMEGDAWgBQmqtoyueiWTYZBinvsnzeOWLtUuzAgBgNVHREEGTAXgRVtYXR0aGV3 QGl0cy51cS5lZHUuYXUwDQYJKoZIhvcNAQEEBQADggEBAF2gZrkqZsZlHd4K/+yBN6qrpD61 hctDf7/Eg4jk6DMknEs6nvHMFUMZ4SXvkqPLnHBygTARKAs7qBSLd7mUUBOOQEgk6ovQVY6S 1CDSt3P9O6wjG0K1igtk8v6u7lkQ8p2STXqrOePVINdaucUgBO/IpeUtt9ATl1qvPTWyM/fz oUZsIKeYjNQVEQsuimrZjdbIAFxdl1fggSngUv64wBn8wCssGrPZIZA2lpBBEW1wejoWrDOH IIr+SspGd0i8MovDTMRSvgTERLki17FU/ANilcrSXiODKeIvpXhnQqVScnsoMSZmBmN2QIoG SnBjNK5mYxx5E3v20VOwtP1hVdEwggNyMIICWqADAgECAgEqMA0GCSqGSIb3DQEBBAUAMIGj MQswCQYDVQQGEwJBVTETMBEGA1UECBMKUXVlZW5zbGFuZDERMA8GA1UEBxMIQnJpc2JhbmUx JTAjBgNVBAoTHFRoZSBVbml2ZXJzaXR5IG9mIFF1ZWVuc2xhbmQxKDAmBgNVBAsTH0luZm9y bWF0aW9uIFRlY2hub2xvZ3kgU2VydmljZXMxGzAZBgNVBAMTEkNlcnRpZmljYXRlIFNlcnZl cjAeFw0wNDAxMjEyMzM2MjFaFw0wNjAxMjEyMzM2MjFaMIGyMQswCQYDVQQGEwJBVTElMCMG A1UEChMcVGhlIFVuaXZlcnNpdHkgb2YgUXVlZW5zbGFuZDEnMCUGA1UECxMeSW5mb3JtYXRp b24gVGVjbm9sb2d5IFNlcnZpY2VzMRYwFAYKCZImiZPyLGQBARMGY2NtYXR0MRkwFwYDVQQD ExBNYXR0aGV3IFN1bGxpdmFuMSAwHgYJKoZIhvcNAQkBFhFtYXR0aGV3QHVxLmVkdS5hdTBc MA0GCSqGSIb3DQEBAQUAA0sAMEgCQQCbFH68P0FKiiMw73q1nNheBhRUWZiHjvmwJfuwTOsf /X6zMzrcoMeEBm+KEMLThPEnWtWiLL/siRdw4vRLlMrzAgMBAAGjaDBmMA4GA1UdDwEB/wQE AwIF4DARBglghkgBhvhCAQEEBAMCBaAwHwYDVR0jBBgwFoAUJqraMrnolk2GQYp77J83jli7 VLswIAYDVR0RBBkwF4EVbWF0dGhld0BpdHMudXEuZWR1LmF1MA0GCSqGSIb3DQEBBAUAA4IB AQBdoGa5KmbGZR3eCv/sgTeqq6Q+tYXLQ3+/xIOI5OgzJJxLOp7xzBVDGeEl75Kjy5xwcoEw ESgLO6gUi3e5lFATjkBIJOqL0FWOktQg0rdz/TusIxtCtYoLZPL+ru5ZEPKdkk16qznj1SDX WrnFIATvyKXlLbfQE5darz01sjP386FGbCCnmIzUFRELLopq2Y3WyABcXZdX4IEp4FL+uMAZ /MArLBqz2SGQNpaQQRFtcHo6FqwzhyCK/krKRndIvDKLw0zEUr4ExES5ItexVPwDYpXK0l4j gyniL6V4Z0KlUnJ7KDEmZgZjdkCKBkpwYzSuZmMceRN79tFTsLT9YVXRMYIDQDCCAzwCAQEw gakwgaMxCzAJBgNVBAYTAkFVMRMwEQYDVQQIEwpRdWVlbnNsYW5kMREwDwYDVQQHEwhCcmlz YmFuZTElMCMGA1UEChMcVGhlIFVuaXZlcnNpdHkgb2YgUXVlZW5zbGFuZDEoMCYGA1UECxMf SW5mb3JtYXRpb24gVGVjaG5vbG9neSBTZXJ2aWNlczEbMBkGA1UEAxMSQ2VydGlmaWNhdGUg U2VydmVyAgEqMAkGBSsOAwIaBQCgggItMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ KoZIhvcNAQkFMQ8XDTA1MDQyNjA2MDc1OVowIwYJKoZIhvcNAQkEMRYEFESM4jbA6IZui6+3 UUGfB995LbBSMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIG6BgkrBgEEAYI3EAQx gawwgakwgaMxCzAJBgNVBAYTAkFVMRMwEQYDVQQIEwpRdWVlbnNsYW5kMREwDwYDVQQHEwhC cmlzYmFuZTElMCMGA1UEChMcVGhlIFVuaXZlcnNpdHkgb2YgUXVlZW5zbGFuZDEoMCYGA1UE CxMfSW5mb3JtYXRpb24gVGVjaG5vbG9neSBTZXJ2aWNlczEbMBkGA1UEAxMSQ2VydGlmaWNh dGUgU2VydmVyAgEqMIG8BgsqhkiG9w0BCRACCzGBrKCBqTCBozELMAkGA1UEBhMCQVUxEzAR BgNVBAgTClF1ZWVuc2xhbmQxETAPBgNVBAcTCEJyaXNiYW5lMSUwIwYDVQQKExxUaGUgVW5p dmVyc2l0eSBvZiBRdWVlbnNsYW5kMSgwJgYDVQQLEx9JbmZvcm1hdGlvbiBUZWNobm9sb2d5 IFNlcnZpY2VzMRswGQYDVQQDExJDZXJ0aWZpY2F0ZSBTZXJ2ZXICASowDQYJKoZIhvcNAQEB BQAEQJQgzOZ/04zP4/lug/YjRxsquqexetB3Idw9YNPQLnQjUhiBsdbHjFmjarc0gPj05V5D aBF/BG/wMX/+CxY7JRcAAAAAAAA= --------------ms030902050109060206060207-- From owner-freebsd-current@FreeBSD.ORG Tue Apr 26 06: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 A23AF16A4CE; Tue, 26 Apr 2005 06:13:28 +0000 (GMT) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1518843D49; Tue, 26 Apr 2005 06:13:28 +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 j3Q6DRmV022456; Tue, 26 Apr 2005 02:13:27 -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 j3Q6DRZU032856; Tue, 26 Apr 2005 02:13:27 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 271CB7306E; Tue, 26 Apr 2005 02:13:27 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050426061327.271CB7306E@freebsd-current.sentex.ca> Date: Tue, 26 Apr 2005 02:13:27 -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 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, 26 Apr 2005 06:13:28 -0000 TB --- 2005-04-26 05:53:27 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-04-26 05:53:27 - starting CURRENT tinderbox run for powerpc/powerpc TB --- 2005-04-26 05:53:27 - checking out the source tree TB --- 2005-04-26 05:53:27 - cd /home/tinderbox/CURRENT/powerpc/powerpc TB --- 2005-04-26 05:53:27 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-04-26 06:11:59 - building world (CFLAGS=-O2 -pipe) TB --- 2005-04-26 06:11:59 - cd /home/tinderbox/CURRENT/powerpc/powerpc/src TB --- 2005-04-26 06:11: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 [...] ===> rescue/rescue/ipf/ipnat (clean) rm -f ipnat_y.c ipnat_y.h ipnat_l.c ipnat_l.h y.tab.c y.tab.h ipnat ipnat.o ipnat_y.o ipnat_l.o ipnat.8.gz ipnat.4.gz ipnat.5.gz ipnat.8.cat.gz ipnat.4.cat.gz ipnat.5.cat.gz ===> rescue/rescue/ipf/ippool (clean) rm -f ippool_y.c ippool_y.h ippool_l.c ippool_l.h y.tab.c y.tab.h ippool ippool_y.o ippool_l.o kmem.o ippool.o ippool.5.gz ippool.8.gz ippool.5.cat.gz ippool.8.cat.gz ===> rescue/rescue/ipf/ipresend (clean) rm -f y.tab.c y.tab.h ipresend ipresend.o ip.o resend.o sbpf.o sock.o 44arp.o ipresend.1.gz ipresend.1.cat.gz cd /tinderbox/CURRENT/powerpc/powerpc/src/rescue/rescue/../../sbin/ipfs && MAKEOBJDIRPREFIX=/home/tinderbox/CURRENT/powerpc/powerpc/obj/powerpc/tinderbox/CURRENT/powerpc/powerpc/src/rescue/rescue /home/tinderbox/CURRENT/powerpc/powerpc/obj/tinderbox/CURRENT/powerpc/powerpc/src/make.i386/make DIRPRFX=rescue/rescue/ipfs/ clean cd: can't cd to /tinderbox/CURRENT/powerpc/powerpc/src/rescue/rescue/../../sbin/ipfs *** Error code 2 Stop in /tinderbox/CURRENT/powerpc/powerpc/src/rescue/rescue. *** Error code 1 Stop in /tinderbox/CURRENT/powerpc/powerpc/src/rescue. *** Error code 1 Stop in /tinderbox/CURRENT/powerpc/powerpc/src. *** Error code 1 Stop in /tinderbox/CURRENT/powerpc/powerpc/src. *** Error code 1 Stop in /tinderbox/CURRENT/powerpc/powerpc/src. TB --- 2005-04-26 06:13:26 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-04-26 06:13:26 - ERROR: failed to build world TB --- 2005-04-26 06:13:26 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Tue Apr 26 06:32: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 0D07A16A4CE; Tue, 26 Apr 2005 06:32:40 +0000 (GMT) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 790AB43D39; Tue, 26 Apr 2005 06:32:39 +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 j3Q6WcW3030007; Tue, 26 Apr 2005 02:32:38 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.13.3/8.13.3) with ESMTP id j3Q6X7qs040500; Tue, 26 Apr 2005 02:33:08 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 81A867306E; Tue, 26 Apr 2005 02:32:38 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050426063238.81A867306E@freebsd-current.sentex.ca> Date: Tue, 26 Apr 2005 02:32:38 -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 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: Tue, 26 Apr 2005 06:32:40 -0000 TB --- 2005-04-26 06:13:27 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-04-26 06:13:27 - starting CURRENT tinderbox run for sparc64/sparc64 TB --- 2005-04-26 06:13:27 - checking out the source tree TB --- 2005-04-26 06:13:27 - cd /home/tinderbox/CURRENT/sparc64/sparc64 TB --- 2005-04-26 06:13:27 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-04-26 06:30:58 - building world (CFLAGS=-O2 -pipe) TB --- 2005-04-26 06:30:58 - cd /home/tinderbox/CURRENT/sparc64/sparc64/src TB --- 2005-04-26 06:30:58 - /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 [...] ===> rescue/rescue/ipf/ipnat (clean) rm -f ipnat_y.c ipnat_y.h ipnat_l.c ipnat_l.h y.tab.c y.tab.h ipnat ipnat.o ipnat_y.o ipnat_l.o ipnat.8.gz ipnat.4.gz ipnat.5.gz ipnat.8.cat.gz ipnat.4.cat.gz ipnat.5.cat.gz ===> rescue/rescue/ipf/ippool (clean) rm -f ippool_y.c ippool_y.h ippool_l.c ippool_l.h y.tab.c y.tab.h ippool ippool_y.o ippool_l.o kmem.o ippool.o ippool.5.gz ippool.8.gz ippool.5.cat.gz ippool.8.cat.gz ===> rescue/rescue/ipf/ipresend (clean) rm -f y.tab.c y.tab.h ipresend ipresend.o ip.o resend.o sbpf.o sock.o 44arp.o ipresend.1.gz ipresend.1.cat.gz cd /tinderbox/CURRENT/sparc64/sparc64/src/rescue/rescue/../../sbin/ipfs && MAKEOBJDIRPREFIX=/home/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/tinderbox/CURRENT/sparc64/sparc64/src/rescue/rescue /home/tinderbox/CURRENT/sparc64/sparc64/obj/tinderbox/CURRENT/sparc64/sparc64/src/make.i386/make DIRPRFX=rescue/rescue/ipfs/ clean cd: can't cd to /tinderbox/CURRENT/sparc64/sparc64/src/rescue/rescue/../../sbin/ipfs *** Error code 2 Stop in /tinderbox/CURRENT/sparc64/sparc64/src/rescue/rescue. *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/src/rescue. *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/src. *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/src. *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/src. TB --- 2005-04-26 06:32:38 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-04-26 06:32:38 - ERROR: failed to build world TB --- 2005-04-26 06:32:38 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Tue Apr 26 07:08: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 B7D3D16A4CE for ; Tue, 26 Apr 2005 07:08:17 +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 59F3443D45 for ; Tue, 26 Apr 2005 07:08:17 +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 1DQKB5-0006Qi-HC; Tue, 26 Apr 2005 10:08:15 +0300 X-Mailer: exmh version 2.7.0 06/18/2004 with nmh-1.0.4 To: Jeff Behl In-Reply-To: Message from Jeff Behl of "Mon, 25 Apr 2005 23:02:13 PDT." <426DD965.4010106@fastclick.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 26 Apr 2005 10:08:15 +0300 From: Danny Braniss Message-ID: cc: Julian Elischer cc: current@freebsd.org Subject: Re: serial/ether console & ramblings X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 26 Apr 2005 07:08:17 -0000 > Julian Elischer wrote: > > > > > > > Jeff Behl wrote: > > > >>>> but my whole point is that nothing in 1) works remotely (out of band) > >>>> when the system and the BMC share the same ethernet controller, at > >>>> least > >>>> with the bge driver. as i mentioned in the thread, i can power cycle > >>>> and see the serial console remotely (number 2 from above) all the > >>>> way up > >>>> to the point where the kernel loads. as soon as it does, the bge > >>>> driver > >>>> no longer shunts off RMCP packets (what IPMI uses) to the Baseboard > >>>> Management Controller, so no IPMI... > >>>> > >>>> > >>>> > >>> > >>> the intel MBs allow you to share the 10/100 ethernet with the IPMI > >>> controller. > >>> > >>> > >> > >> > >> as do the motherboards with the e325s. we can to everything out of band > >> when running linux, but that's because the driver for the broadcom nics > >> in linux are aware of the BMC... > >> > >> > > > > I run the intels with FreeBSD OOB without any problems. > > > what interface driver is being used? > > that'd be nifty if the motherboard had first dibs on a packet, but i > didn't realize that was the way it could work. the linux bge driver > certainly has code in it specifically for RMCP packets... just look at the amount of magic needed to run IPMI! ... BIOS+NIC+BMC+linux-emulation+cli+proxy ... Can we get back on track? this is becoming a IPMI bashing, and we are no where nearer in finding a decent repalcement for that good-old-serial-console. danny From owner-freebsd-current@FreeBSD.ORG Tue Apr 26 07:13: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 2A3F816A4CE for ; Tue, 26 Apr 2005 07:13:29 +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 A2F5043D54 for ; Tue, 26 Apr 2005 07:13:28 +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 1DQKG7-0006jl-QN; Tue, 26 Apr 2005 10:13:27 +0300 X-Mailer: exmh version 2.7.0 06/18/2004 with nmh-1.0.4 To: Doug White In-reply-to: Your message of Mon, 25 Apr 2005 19:47:38 -0700 (PDT) . Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 26 Apr 2005 10:13:27 +0300 From: Danny Braniss Message-ID: cc: current@freebsd.org Subject: Re: diskless/unionfs 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: Tue, 26 Apr 2005 07:13:29 -0000 > On Sat, 23 Apr 2005, Danny Braniss wrote: > > > > On Fri, 22 Apr 2005, Danny Braniss wrote: > > > > > > > hi, > > > > after much debugging, it seems that the main problem with unionfs is > > > > that if it's called early in the boot process it will panic the kernel: > > > > > > > > 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 = 0x8:0xffffffff8038e3f5 > > > > stack pointer = 0x10:0xffffffffb1eac7b0 > > > > frame pointer = 0x10:0xffffffffb1eac7e0 > > > > code segment = base 0x0, limit 0xfffff, type 0x1b > > > > = DPL 0, pres 1, long 1, def32 0, gran 1 > > > > processor eflags = interrupt enabled, resume, IOPL = 0 > > > > current process = 213 (sh) > > > > [thread pid 213 tid 100066 ] > > > > Stopped at _mtx_lock_flags+0x35: cmpq $0x80779d40,0(%rdi) > > > > > > unintialized mutex, probably, although it looks like it'd be the vm page > > > queue mutex which should be init'd by then. > > > > > > Is this -CURRENT? > > yes, cvs'ed a few days ago (but the problem is not new). > > > > > > > > > db> tr > > > > Tracing pid 213 tid 100066 td 0xffffff007b9b1000 > > > > _mtx_lock_flags() at _mtx_lock_flags+0x35 > > > > exec_map_first_page() at exec_map_first_page+0x60 > > > > > > If you have a debug kernel for this around, load it into gdb and 'disass > > > exec_map_first_page' and look around offset 96 to see if its referencing a > > > mutex (mtx) near there. > > > > arghh, gdb, is there a quick guide for this? im almost there, but > > can't sync speed (the console is at 38400). > > Oh, don't bother trying to attach directly to the kernel, just look at the > kernel.debug binary , if you've got one. If not, put > > makeoptions DEBUG=-g ok, here is the output: (gdb) disass exec_map_first_page Dump of assembler code for function exec_map_first_page: 0xc060c360 : push %ebp 0xc060c361 : mov %esp,%ebp 0xc060c363 : push %edi 0xc060c364 : push %esi 0xc060c365 : push %ebx 0xc060c366 : sub $0x44,%esp 0xc060c369 : mov 0x8(%ebp),%eax 0xc060c36c : cmpl $0x0,0x28(%eax) 0xc060c370 : je 0xc060c37c 0xc060c372 : push %eax 0xc060c373 : call 0xc060c6d8 0xc060c378 : add $0x4,%esp 0xc060c37b : nop 0xc060c37c : mov 0x8(%ebp),%edx 0xc060c37f : mov 0x8(%edx),%eax 0xc060c382 : mov 0xf8(%eax),%esi 0xc060c388 : mov %fs:0x0,%edx 0xc060c38f : mov $0x4,%eax 0xc060c394 : lock cmpxchg %edx,0x1c(%esi) 0xc060c399 : sete %al ---Type to continue, or q to quit--- 0xc060c39c : movzbl %al,%eax 0xc060c39f : test %eax,%eax 0xc060c3a1 : jne 0xc060c3b4 0xc060c3a3 : push $0x0 0xc060c3a5 : push $0x0 0xc060c3a7 : push $0x0 0xc060c3a9 : push %edx 0xc060c3aa : push %esi 0xc060c3ab : call 0xc061cfc4 <_mtx_lock_sleep> 0xc060c3b0 : add $0x14,%esp 0xc060c3b3 : nop 0xc060c3b4 : push $0x80 0xc060c3b9 : push $0x0 0xc060c3bb : push $0x0 0xc060c3bd : push %esi 0xc060c3be : call 0xc0795068 0xc060c3c3 : mov %eax,0xffffffb4(%ebp) 0xc060c3c6 : add $0x10,%esp 0xc060c3c9 : cmpb $0xff,0x44(%eax) 0xc060c3cd : je 0xc060c60c 0xc060c3d3 : movl $0x10,0xffffffb0(%ebp) ---Type to continue, or q to quit--- From owner-freebsd-current@FreeBSD.ORG Tue Apr 26 07:15:57 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 618) id 2650716A4CF; Tue, 26 Apr 2005 07:15:57 +0000 (GMT) In-Reply-To: <17005.52150.590534.365619@szamoca.krvarr.bc.ca> from Sandy Rutherford at "Apr 25, 2005 10:03:50 pm" To: sandy@krvarr.bc.ca (Sandy Rutherford) Date: Tue, 26 Apr 2005 07:15:57 +0000 (GMT) X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: <20050426071557.2650716A4CF@hub.freebsd.org> From: wpaul@FreeBSD.ORG (Bill Paul) cc: freebsd-current@freebsd.org cc: freebsd-hardware@freebsd.org Subject: Re: Too Evil, Too Furious X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 26 Apr 2005 07:15:57 -0000 > >>>>> On Mon, 25 Apr 2005 17:15:28 +0000 (GMT), > >>>>> wpaul@freebsd.org (Bill Paul) said: > > > - RayLink RT2500 wireless -- this one shows up on some PCI cards, but > > I haven't had any luck finding one locally yet > > I assume that you mean RaLink (no "y"). Have you tried contacting the > people at RaLink? I understand that they are very supportive of open > source development. As a result, there is a Linux driver for both the > rt2400 and rt2500. If they were really supportive of open source, there would be manuals for the RT2400 and RT2500 chipsets on their website that people could download. Then people could develop drivers for _any_ OS, not just Linux. "But Linux support means open source support, right?" No, it just means Linux support. I'm sure the marketing people would like you to think the two things are equal, but they really aren't. "But you can easily port the Linux driver, right?" Any given network chipset has a number of different features. A driver written for OS A will take advantage of those features that produce good performance on OS A. The chip might also have additional features that would benefit OS B, but if all you have as a reference is the driver for OS A, you might be completely unaware those features exist. That constitutes an unfair handicap, nevermind the time wasted trying to decipher someone else's code before you can write your own. Releasing the manuals insures a level playing field for everyone. > The project page is > http://sourceforge.net/projects/rt2400. BTW, this driver seems solid. > I flogged it hard with flood pings and it held up well. My rt2500 is > a Belkin model F5D7010.PCMCIA card, which I have stuck in a laptop > running Slackware. Unfort., I need it so I can't send it to you. I am > not aware of any PCI cards using the rt2500. You've just provided a perfect example of model number confusion. Your Belkin F5D7010 card has a RaLink chipset. But Belkin has another card also called the F5D7010 which has a Broadcom chipset. I found a Belkin F5D7010 card at CompUSA this past weekend, but I couldn't buy it since there was no way to tell which revision it was, and I didn't want to end up with yet another Broadcom cardbus card. > Given RaLink's willingness to work with the open source community, > wouldn't the rt2500 be a better candidate for a native driver, rather > than Project Evil? Right now my goal is to make Project Evil support the NDIS spec as well as possible, and for that I need to test as many NDIS drivers as possible. If someone else wants to create a native driver, then more power to them. I've written more than enough drivers for one lifetime. -Bill -- ============================================================================= -Bill Paul (510) 749-2329 | Senior Engineer, Master of Unix-Fu wpaul@windriver.com | Wind River Systems ============================================================================= you're just BEGGING to face the moose ============================================================================= From owner-freebsd-current@FreeBSD.ORG Tue Apr 26 08:02: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 AEBE516A4CE for ; Tue, 26 Apr 2005 08:02:06 +0000 (GMT) Received: from pegasus.freiberg-net.de (pegasus.freibergnet.de [80.243.43.9]) by mx1.FreeBSD.org (Postfix) with ESMTP id D8C5D43D48 for ; Tue, 26 Apr 2005 08:02:05 +0000 (GMT) (envelope-from holm@pegasus.freiberg-net.de) Received: from pegasus.freiberg-net.de (localhost.freiberg-net.de [127.0.0.1]) j3Q824Du002495 for ; Tue, 26 Apr 2005 10:02:04 +0200 (CEST) (envelope-from holm@pegasus.freiberg-net.de) Received: (from holm@localhost) by pegasus.freiberg-net.de (8.13.3/8.13.1/Submit) id j3Q824uh002494 for freebsd-current@freebsd.org; Tue, 26 Apr 2005 10:02:04 +0200 (CEST) (envelope-from holm) Date: Tue, 26 Apr 2005 10:02:04 +0200 From: Holm Tiffe To: freebsd-current@freebsd.org Message-ID: <20050426080203.GB1413@pegasus.freiberg-net.de> Mail-Followup-To: Holm Tiffe , freebsd-current@freebsd.org References: <20050420221903.GA738@bart.bsd-geek.de> <200504211606.j3LG6gbc007250@peedub.jennejohn.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200504211606.j3LG6gbc007250@peedub.jennejohn.org> User-Agent: Mutt/1.4.2.1i Organization: FreibergNet Internet Services Priority: normal X-Phone: +49-3731-419010 X-Fax: +49-3731-4196026 X-PGP-fingerprint: 86 EC A5 63 B5 28 78 13 8B FC E9 09 04 6E 86 FC Subject: Re: library problems with -CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: holm@freibergnet.de List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2005 08:02:06 -0000 Gary Jennejohn wrote: > > Lars Engels writes: > > Hi all! > > > > I just upgraded my 5.4-PRERELEASE notebook to -CURRENT. > > Compilation and installation went fine, but when I try to start firefox, > > gkrellm and even portupgrade I get the following error message: > > /libexec/ld-elf.so.1: /usr/lib/libpthread.so.1: Undefined symbol > > "i386_get_gsbase" > > > > Is there something i have not spotted in UPDATING? > > > > System: FreeBSD 6.0-CURRENT #5: Wed Apr 20 23:21:11 CEST 2005 > > > > It's not in UPDATING, but a change was recently made (can't say exactly > when) which affects %gs/%fs. If you're using -current then you really > should watch the commits, too! > Yes we should watch the commitlogs, but it's really bad behavior to brake that many of the installed Applications and not to mention this fact in UPDATING. That's what IMHO version numbers for. I'm reverting back to 04/13/2005 since I don't have the time now to recompile everything to get my work done .. :-( Holm -- L&P::Kommunikation GbR Holm Tiffe * Administration, Development FreibergNet.de Internet Systems phone +49 3731 419010 Bereich Server & Technik fax +49 3731 4196026 D-09599 Freiberg * Am St. Niclas Schacht 13 http://www.freibergnet.de From owner-freebsd-current@FreeBSD.ORG Tue Apr 26 08:29: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 76BF316A4CE for ; Tue, 26 Apr 2005 08:29:45 +0000 (GMT) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5662843D1F for ; Tue, 26 Apr 2005 08:29:45 +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 1DQLRw-0001RR-Ht; Tue, 26 Apr 2005 08:29:44 +0000 Received: from [127.0.0.1] (helo=roam.psg.com.psg.com) by roam.psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DQLRu-0000xK-Ei; Mon, 25 Apr 2005 22:29:42 -1000 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17005.64501.816490.740201@roam.psg.com> Date: Mon, 25 Apr 2005 22:29:41 -1000 To: Brooks Davis References: <17001.9557.627987.505930@roam.psg.com> <17001.16520.774703.612151@roam.psg.com> <20050422112246.A70611@xorpc.icir.org> <17001.16764.512962.411616@roam.psg.com> <20050422115518.C70611@xorpc.icir.org> <20050422214418.GB11806@odin.ac.hmc.edu> <20050425224646.GA6848@odin.ac.hmc.edu> cc: Luigi Rizzo cc: FreeBSD Current Subject: Re: significant increase in ipfw pullup failed X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 26 Apr 2005 08:29:45 -0000 patch seems to have fixed it! randy From owner-freebsd-current@FreeBSD.ORG Tue Apr 26 08:51: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 7648416A4CE; Tue, 26 Apr 2005 08:51:39 +0000 (GMT) Received: from kraid.nerim.net (smtp-102-tuesday.nerim.net [62.4.16.102]) by mx1.FreeBSD.org (Postfix) with ESMTP id A84D043D2D; Tue, 26 Apr 2005 08:51:38 +0000 (GMT) (envelope-from e-masson@kisoft-services.com) Received: from srvbsdnanssv.interne.kisoft-services.com (kisoft.net1.nerim.net [62.212.107.51]) by kraid.nerim.net (Postfix) with ESMTP id 69DC043C10; Tue, 26 Apr 2005 10:51:36 +0200 (CEST) Received: from localhost (localhost [127.0.0.1])9118DC325; Tue, 26 Apr 2005 10:51:34 +0200 (CEST) Received: from srvbsdnanssv.interne.kisoft-services.com ([127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25158-07; Tue, 26 Apr 2005 10:51:34 +0200 (CEST) Received: by srvbsdnanssv.interne.kisoft-services.com (Postfix, from userid 1001) id D96D7C30B; Tue, 26 Apr 2005 10:51:33 +0200 (CEST) To: Sandy Rutherford From: Eric Masson In-Reply-To: <17005.63479.96819.128347@szamoca.krvarr.bc.ca> (Sandy Rutherford's message of "Tue, 26 Apr 2005 01:12:39 -0700") References: <17005.52150.590534.365619@szamoca.krvarr.bc.ca> <20050426071557.2650716A4CF@hub.freebsd.org> <17005.63479.96819.128347@szamoca.krvarr.bc.ca> X-Operating-System: FreeBSD 5.4-RC3 i386 Date: Tue, 26 Apr 2005 10:51:33 +0200 Message-ID: <86acnlx6ne.fsf@srvbsdnanssv.interne.kisoft-services.com> User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through Obscurity, berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 8bit X-Virus-Scanned: amavisd-new at interne.kisoft-services.com cc: Bill Paul cc: freebsd-current@FreeBSD.ORG cc: freebsd-hardware@FreeBSD.ORG Subject: Re: Too Evil, Too Furious X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 26 Apr 2005 08:51:39 -0000 Sandy Rutherford writes: > If having the manuals would be helpful for Project Evil, then perhaps, > they could put you in contact the relevant person at RaLink. I don't think it could help Bill in any way as Project Evil goal is using Ndis drivers in FreeBSD. Iirc, Damien Bergamini got support from Ralink in writing ral(4) and ural(4) drivers. Éric Masson -- > Passe que moi, au départ, j'avais fait informatique comme études, pas > NT, et je voudrais revenir à mon métier premier. -+- BB in Guide du Linuxien pervers - Bien configurer son metier. From owner-freebsd-current@FreeBSD.ORG Tue Apr 26 09:43: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 CEDB816A4CE; Tue, 26 Apr 2005 09:43:40 +0000 (GMT) Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by mx1.FreeBSD.org (Postfix) with SMTP id 751B443D5D; Tue, 26 Apr 2005 09:43:39 +0000 (GMT) (envelope-from dwmalone@maths.tcd.ie) Received: from walton.maths.tcd.ie ([134.226.81.10] helo=walton.maths.tcd.ie) by salmon.maths.tcd.ie with SMTP id ; 26 Apr 2005 10:43:38 +0100 (BST) Date: Tue, 26 Apr 2005 10:43:37 +0100 From: David Malone To: Andre Oppermann Message-ID: <20050426094337.GA44893@walton.maths.tcd.ie> References: <20050424150211.GA87520@walton.maths.tcd.ie> <426BC78A.3E56D99B@freebsd.org> <426C1600.106@uq.edu.au> <426D2307.97D15253@freebsd.org> <426D306B.7010000@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <426D306B.7010000@freebsd.org> User-Agent: Mutt/1.5.6i Sender: dwmalone@maths.tcd.ie cc: silby@freebsd.org cc: qingli@freebsd.org cc: Matthew Sullivan cc: freebsd-current@freebsd.org Subject: Re: DF (Don't frag) issues X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 26 Apr 2005 09:43:40 -0000 On Mon, Apr 25, 2005 at 08:01:15PM +0200, Andre Oppermann wrote: > - Handling of received ICMP Needfrag messages. The logic was broken > for the cases where the ICMP didn't contain a suggested value. This > brokeness is in there since 5.2R and comes from my cleanup of the > routing table and introduction of TCP hostcache. However there is > no way to fix it at all. It was broken even before I broke it more. > The idea behind the old code was to step down the MTU when we got > a ICMP Needfrag by one step and try again. Unfortunatly it is very > likely that the tcp window was open by a few segments already when > we hit this. This gets us a number of those ICMP's in rapid succession > each stepping us one down. I wonder if we could look into the quoted IP header and extract the length of the IP packet that caused the needs-frag ICMP. That would stop us getting in knots when there are a few packets in flight and would give us a good idea about where we need to step down from. David. From owner-freebsd-current@FreeBSD.ORG Tue Apr 26 09:43: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 F070A16A4CE for ; Tue, 26 Apr 2005 09:43:57 +0000 (GMT) Received: from 62-15-211-171.inversas.jazztel.es (62-15-211-171.inversas.jazztel.es [62.15.211.171]) by mx1.FreeBSD.org (Postfix) with ESMTP id 24A9643D5C for ; Tue, 26 Apr 2005 09:43:57 +0000 (GMT) (envelope-from josemi@freebsd.jazztel.es) Received: from redesjm.local (orion.redesjm.local [192.168.254.16]) j3Q9hthR000825 for ; Tue, 26 Apr 2005 11:43:55 +0200 (CEST) (envelope-from josemi@redesjm.local) Received: from localhost (localhost [[UNIX: localhost]]) by redesjm.local (8.13.3/8.13.3/Submit) id j3Q9ht4Q014686 for freebsd-current@freebsd.org; Tue, 26 Apr 2005 11:43:55 +0200 (CEST) (envelope-from josemi@redesjm.local) From: Jose M Rodriguez To: freebsd-current@freebsd.org Date: Tue, 26 Apr 2005 11:43:54 +0200 User-Agent: KMail/1.8 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200504261143.55195.josemi@redesjm.local> X-AntiVirus: checked by AntiVir Milter (version: 1.1.0-3; AVE: 6.30.0.7; VDF: 6.30.0.116; host: antares.redesjm.local) Subject: rigth crc32 implementation X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 26 Apr 2005 09:43:58 -0000 Hi, Working on usb_adslsubr{.c,.h} About how to implement crc32 My first think was use the libkern based one, but I found: sys/linkern/crc32.c - the code may not be endian safe. - the code lacks support for processing chuncks. Add the functions for the second target may be easy (please, sugest names), but I found a latest problem: At last geom uses this to sign data structures. If the code is made endian safe, this will break geom. At the moment, I'll work this into usb_adslsubr{.c,.h}, but I'll glad to know if those targets will be wellcome. -- josemi From owner-freebsd-current@FreeBSD.ORG Tue Apr 26 09:52: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 1A95016A4CE for ; Tue, 26 Apr 2005 09:52:31 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id EFAC243D5F for ; Tue, 26 Apr 2005 09:52:29 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 17866 invoked from network); 26 Apr 2005 09:53:28 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.53]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 26 Apr 2005 09:53:28 -0000 Message-ID: <426E0F5C.3F157398@freebsd.org> Date: Tue, 26 Apr 2005 11:52:28 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: David Malone References: <20050424150211.GA87520@walton.maths.tcd.ie> <426BC78A.3E56D99B@freebsd.org> <426C1600.106@uq.edu.au> <426D2307.97D15253@freebsd.org> <426D306B.7010000@freebsd.org> <20050426094337.GA44893@walton.maths.tcd.ie> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: silby@freebsd.org cc: qingli@freebsd.org cc: Matthew Sullivan cc: freebsd-current@freebsd.org Subject: Re: DF (Don't frag) issues X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 26 Apr 2005 09:52:31 -0000 David Malone wrote: > > On Mon, Apr 25, 2005 at 08:01:15PM +0200, Andre Oppermann wrote: > > - Handling of received ICMP Needfrag messages. The logic was broken > > for the cases where the ICMP didn't contain a suggested value. This > > brokeness is in there since 5.2R and comes from my cleanup of the > > routing table and introduction of TCP hostcache. However there is > > no way to fix it at all. It was broken even before I broke it more. > > The idea behind the old code was to step down the MTU when we got > > a ICMP Needfrag by one step and try again. Unfortunatly it is very > > likely that the tcp window was open by a few segments already when > > we hit this. This gets us a number of those ICMP's in rapid succession > > each stepping us one down. > > I wonder if we could look into the quoted IP header and extract the > length of the IP packet that caused the needs-frag ICMP. That would > stop us getting in knots when there are a few packets in flight and > would give us a good idea about where we need to step down from. This is a really clever idea indeed. But it only works if part of the original packet is attached. Broken implementations are likely to omit that. But I'll implement your suggestion as well and post a new patch later this evening. -- Andre From owner-freebsd-current@FreeBSD.ORG Tue Apr 26 09:55: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 B587D16A4CE; Tue, 26 Apr 2005 09:55:33 +0000 (GMT) Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by mx1.FreeBSD.org (Postfix) with SMTP id 6603E43D39; Tue, 26 Apr 2005 09:55:32 +0000 (GMT) (envelope-from dwmalone@maths.tcd.ie) Received: from walton.maths.tcd.ie ([134.226.81.10] helo=maths.tcd.ie) by salmon.maths.tcd.ie with SMTP id ; 26 Apr 2005 10:55:31 +0100 (BST) To: Andre Oppermann In-reply-to: Your message of "Tue, 26 Apr 2005 11:52:28 +0200." <426E0F5C.3F157398@freebsd.org> X-Request-Do: Date: Tue, 26 Apr 2005 10:55:31 +0100 From: David Malone Message-ID: <200504261055.aa95182@salmon.maths.tcd.ie> cc: silby@freebsd.org cc: qingli@freebsd.org cc: Matthew Sullivan cc: freebsd-current@freebsd.org Subject: Re: DF (Don't frag) issues X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 26 Apr 2005 09:55:33 -0000 > > I wonder if we could look into the quoted IP header and extract the > > length of the IP packet that caused the needs-frag ICMP. That would > > stop us getting in knots when there are a few packets in flight and > > would give us a good idea about where we need to step down from. > This is a really clever idea indeed. But it only works if part of > the original packet is attached. Broken implementations are likely > to omit that. But I'll implement your suggestion as well and post > a new patch later this evening. In the case of TCP PMTU we should be OK because we to get as far as the TCP code I think we'll always have enough quoted packet? Of course, in the more general case we can't always do this, but it should help in a lot of cases. David. From owner-freebsd-current@FreeBSD.ORG Tue Apr 26 10:38: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 B5D6416A4CE for ; Tue, 26 Apr 2005 10:38:06 +0000 (GMT) Received: from hex.athame.co.uk (guru164.netsonic.fi [194.29.193.164]) by mx1.FreeBSD.org (Postfix) with ESMTP id 454C343D4C for ; Tue, 26 Apr 2005 10:38:06 +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 1DQNS8-0003jo-KQ for freebsd-current@freebsd.org; Tue, 26 Apr 2005 13:38:04 +0300 From: Andy Fawcett To: freebsd-current@freebsd.org Date: Tue, 26 Apr 2005 13:37:59 +0300 User-Agent: KMail/1.8 References: <20050425010242.GA44110@xor.obsecurity.org> <20050425182033.GC40370@xor.obsecurity.org> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200504261338.01026.andy@athame.co.uk> Subject: Re: GCC 4.0 [Re: FreeBSD 6 is coming too fast] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 26 Apr 2005 10:38:06 -0000 On Monday 25 April 2005 23:28, Garance A Drosihn wrote: > For what it's worth: Some friends of mine are claiming that "Tiger" > (MacOS 10.4) will be coming with gcc 4.0. And Tiger is already > shipping, although the official release date isn't until this Friday. > > I'm not saying that we should switch to it because of that, but I'm > just mentioning it as an interesting data point (assuming it is true!). FYI, the KDE project just blacklisted gcc 4.0.0, because "it is known to miscompile KDE. Please use a newer version, or if that is not yet available, choose an older version." No, I don't know what the exact problems are, but they are obviously severe enough for KDE to say "no thanks" to 4.0.0. A. From owner-freebsd-current@FreeBSD.ORG Tue Apr 26 10:44: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 35AAC16A4CE for ; Tue, 26 Apr 2005 10:44:18 +0000 (GMT) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.192]) by mx1.FreeBSD.org (Postfix) with ESMTP id B8E0943D4C for ; Tue, 26 Apr 2005 10:44:17 +0000 (GMT) (envelope-from fierykylin@gmail.com) Received: by zproxy.gmail.com with SMTP id 9so1434152nzo for ; Tue, 26 Apr 2005 03:44:16 -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=Pr1GZy1F+cSxseY+Pook97ID49IUGEZc9Ipz50FI/kcEmVef9RZH7ARQxXrdZ0DE8ZKWskuwt129CdyEKHJ8TjlNQtux9ZBTYMZzZ5YZ6xxQR5RctyqhpCoL3fwfRb2QHEBBi8xlJ3pPkVxno8Wg8KHdyA+mDk/ZT+hQGpuiq2s= Received: by 10.36.33.6 with SMTP id g6mr452782nzg; Tue, 26 Apr 2005 03:44:16 -0700 (PDT) Received: by 10.36.104.6 with HTTP; Tue, 26 Apr 2005 03:44:14 -0700 (PDT) Message-ID: <87ab37ab0504260344d23cb9a@mail.gmail.com> Date: Tue, 26 Apr 2005 18:44:14 +0800 From: kylin To: Scott Long In-Reply-To: <426DBFA7.5020605@samsco.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <87ab37ab050425205527cecaf3@mail.gmail.com> <426DBFA7.5020605@samsco.org> cc: freebsd-current@freebsd.org Subject: Re: when will pci hotplug in Freebsd X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: kylin List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2005 10:44:18 -0000 On 4/26/05, Scott Long wrote: > kylin wrote: > > hello,every one , > > just now i have read the FreeBSD status report of march and april > > ,also ,i have read the "plan for next 12 months"by o'Dell > > it is a pity that i do not see any thing about the pci hotplug which i > > am very interested in , > > so ,I wonder if the freebsd 5.4 or later version will support PCI > > hotplug, if there is long time enought before the official providing > > utility,i may develop it on my own, or i will just wait asn see :) > > welcom to give me some advice! > > thank u:) > > > > > > >=20 > Which PCI Hotplug do you want? Do you want the one ACPI version that > in only supported on a few ia64 systems? Do you want the PCI-SIG > version that's supported by no one? Or do you want the Compaq version > that isn't documented except in Linux driver sources? What about the > Dell version? Or IBM? Also, do you want storage and network devices > to behave correctly when they are hot-pulled? The work here is far > from trivial, but I'd happily accept volunteers that want to start on > it =3D-) >=20 > Scott >=20 --=20 we who r about to die,salute u! thank you for your opinions, that encourage me very much !since so broad a topic is , i would rather Devide and Quanqer:) that is:=20 1 i will start with the native hotplug of pci express ,which has a very standard hardware interface and usage model. And among so many IO devices , i would rather start first with the PCI Express SLOT hotplug,putting something like scsi a little later. 2 there are few mainboard that support pci express hotplug nowadays ,but i found one which maybe useful: that is the intel E7520AF2 server board using the E7520 chipset.now the Dell PowerEdge 2800 is said to support pci express hotplug ,but till now i doubt the bios of the 2800 do not support ACPI _OSC or OSHP method yet. i am contacting with dell now 3 according to linux and openbsd ,hotplug archtecture is rather clear , a thread waiting for the interrupt from the slot ,do the init and driver-attaching then leaves it to userspace 4 i am so small and fragile ,so any gentlemen would like help are warmly welcome!! --=20 we who r about to die,salute u! From owner-freebsd-current@FreeBSD.ORG Tue Apr 26 10:46: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 953AD16A4CE for ; Tue, 26 Apr 2005 10:46:42 +0000 (GMT) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 666CE43D45 for ; Tue, 26 Apr 2005 10:46:42 +0000 (GMT) (envelope-from mux@freebsd.org) Received: by elvis.mu.org (Postfix, from userid 1920) id 549EF5CA44; Tue, 26 Apr 2005 03:46:42 -0700 (PDT) Date: Tue, 26 Apr 2005 12:46:42 +0200 From: Maxime Henrion To: Doug White Message-ID: <20050426104642.GJ25563@elvis.mu.org> References: <4267A1CF.3080903@uq.edu.au> <20050422190208.M68772@lexi.siliconlandmark.com> <426C93AC.3030907@root.org> <20050425200601.I42718@carver.gumbysoft.com> <426DB58B.5020608@uq.edu.au> <20050425204148.H43358@carver.gumbysoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050425204148.H43358@carver.gumbysoft.com> User-Agent: Mutt/1.4.2.1i cc: Matthew Sullivan cc: Nate Lawson cc: freebsd-current@freebsd.org Subject: Re: SMP on Compaq DL380 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 26 Apr 2005 10:46:42 -0000 Doug White wrote: > On Tue, 26 Apr 2005, Matthew Sullivan wrote: > > > >>>There definitely is a problem when you have identical APIC ids. We > > >>>already blacklist one version of this BIOS. > > >>> > > >>That's not something I wanted to here right now... :-( > > > > > >Are you __sure__ you're booting the right kernel? > > >http://scorpion.sorbs.net/dmesg.txt shows a kernel that does not have SMP > > >nor APIC enabled. I'm still seeing ISA interrupt routing rather than APIC > > >mappings. And as noted previously the APIC IDs are not set which means > > >they are not enabled. (APIC IDs are always >0.) > > > > > >What is the output of 'sysctl kern.smp'? > > > > > > > > kern.smp.maxcpus: 16 > > kern.smp.active: 0 > > kern.smp.disabled: 0 > > kern.smp.cpus: 1 > > kern.smp.forward_signal_enabled: 1 > > kern.smp.forward_roundrobin_enabled: 1 > > You're booting the wrong kernel. Do a buildkernel + installkernel now, > reboot the system, and check that the kernel's build date has incremented. > Also watch the loader output and make sure someone hasn't overridden the > kernel name in loader.conf. > > > >Have you tried booting without ACPI? > > > > > > > > No, but I am doing now... > > > > Btw now I have remote console this is what the BIOS shows.... > > > > 1024 MB Detected > > > > COMPAQ System BIOS - P17 (12/18/2002) > > Copyright 1982,2002 Compaq Computer Corporation. All rights reserved. > > This appears to be the latest BIOS. Some Compaq systems are known to > generate bogus MPTables and such when configured to run Windows. You might > poke around the BIOS Setup and see if there is an "OS Type" field that can > be set to "SCO UNIX" or "Other" (not in PnP setup probably). Yeah, I've seen DL380 boxes that needed "Linux" as the OS type or the BIOS wouldn't generate an MPTable with both CPUs. Maxime From owner-freebsd-current@FreeBSD.ORG Tue Apr 26 11:09: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 2D20316A4CE for ; Tue, 26 Apr 2005 11:09:03 +0000 (GMT) Received: from peedub.jennejohn.org (J82a3.j.pppool.de [85.74.130.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5996243D58 for ; Tue, 26 Apr 2005 11:09:02 +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 j3QB90Hr003349; Tue, 26 Apr 2005 13:09:00 +0200 (CEST) (envelope-from garyj@jennejohn.org) Message-Id: <200504261109.j3QB90Hr003349@peedub.jennejohn.org> X-Mailer: exmh version 2.7.0 06/18/2004 with nmh-1.0.4 To: Holm Tiffe , freebsd-current@freebsd.org In-Reply-To: Message from Holm Tiffe <20050426080203.GB1413@pegasus.freiberg-net.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 26 Apr 2005 13:09:00 +0200 From: Gary Jennejohn Subject: Re: library problems with -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, 26 Apr 2005 11:09:03 -0000 Holm Tiffe writes: > Gary Jennejohn wrote: > > It's not in UPDATING, but a change was recently made (can't say exactly > > when) which affects %gs/%fs. If you're using -current then you really > > should watch the commits, too! > > > > Yes we should watch the commitlogs, but it's really bad behavior to brake > that many of the installed Applications and not to mention this fact in > UPDATING. That's what IMHO version numbers for. > If you'd been watching the commits then you would have seen that the problem has already been resolved in -CURRENT and RELENG_5. --- Gary Jennejohn / garyjATjennejohnDOTorg gjATfreebsdDOTorg garyjATdenxDOTde From owner-freebsd-current@FreeBSD.ORG Tue Apr 26 11:20: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 140CB16A4CE for ; Tue, 26 Apr 2005 11:20:57 +0000 (GMT) Received: from mh2.centtech.com (moat3.centtech.com [207.200.51.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2CC7143D55 for ; Tue, 26 Apr 2005 11:20:56 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from [10.177.171.220] (neutrino.centtech.com [10.177.171.220]) by mh2.centtech.com (8.13.1/8.13.1) with ESMTP id j3QBKtmu008919; Tue, 26 Apr 2005 06:20:55 -0500 (CDT) (envelope-from anderson@centtech.com) Message-ID: <426E23E3.3020404@centtech.com> Date: Tue, 26 Apr 2005 06:20:03 -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: Gary Jennejohn References: <200504261109.j3QB90Hr003349@peedub.jennejohn.org> In-Reply-To: <200504261109.j3QB90Hr003349@peedub.jennejohn.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-current@freebsd.org Subject: Re: library problems with -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, 26 Apr 2005 11:20:57 -0000 Gary Jennejohn wrote: > Holm Tiffe writes: > >>Gary Jennejohn wrote: >> >>>It's not in UPDATING, but a change was recently made (can't say exactly >>>when) which affects %gs/%fs. If you're using -current then you really >>>should watch the commits, too! >>> >> >>Yes we should watch the commitlogs, but it's really bad behavior to brake >>that many of the installed Applications and not to mention this fact in >>UPDATING. That's what IMHO version numbers for. >> > > > If you'd been watching the commits then you would have seen that the > problem has already been resolved in -CURRENT and RELENG_5. I hate to be negative, but the general rule I've always seen (and I believe it is even in the handbook) is that you should subscribe to -CURRENT, and read UPDATING, since that is where notes like this would be. I've never once heard anyone say that I should be watching the commits too. See, the thing is, that I'm running -CURRENT not because I can whip out C code in a snap or help write the newest Flux Capacitating Fligamabob, but because I can help test and find bugs, debug, etc. So I may subscribe to the commits, but I will have little to no idea what I see in my inbox unless someone explicitly puts a comment in there saying "this is gonna break some stuff - look out for XYZ", which obviously isn't going to happen (and I wouldn't expect it to). I saw a little chatter about this on -arch, but I didn't see anything in UPDATING or on this list mentioning the problem was fixed until just now. I never complained, but it might be good practice to keep our 'watch list' for -CURRENT users to a minimum to help keep the number of -CURRENTers up. Take everything I just said with a grain of salt, I'm just a 'user'. 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 Tue Apr 26 11:37: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 7E47A16A4CE for ; Tue, 26 Apr 2005 11:37:09 +0000 (GMT) Received: from mh1.centtech.com (moat3.centtech.com [207.200.51.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id DD60843D64 for ; Tue, 26 Apr 2005 11:37:08 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from [10.177.171.220] (neutrino.centtech.com [10.177.171.220]) by mh1.centtech.com (8.13.1/8.13.1) with ESMTP id j3QBb8TV039262 for ; Tue, 26 Apr 2005 06:37:08 -0500 (CDT) (envelope-from anderson@centtech.com) Message-ID: <426E27B0.2080109@centtech.com> Date: Tue, 26 Apr 2005 06:36:16 -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 X-Virus-Scanned: ClamAV 0.82/853/Mon Apr 25 14:22:22 2005 on mh1.centtech.com X-Virus-Status: Clean Subject: buildworld busted (rescue / ipfs) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 26 Apr 2005 11:37:09 -0000 cvsup from about 5 mins ago: ===> rescue/rescue/ipf/ipresend (clean) rm -f y.tab.c y.tab.h ipresend ipresend.o ip.o resend.o sbpf.o sock.o 44arp.o ipresend.1.gz ipresend.1.cat.gz cd /usr/src/rescue/rescue/../../sbin/ipfs && MAKEOBJDIRPREFIX=/usr/obj/usr/src/rescue/rescue make DIRPRFX=rescue/rescue/ipfs/ clean cd: can't cd to /usr/src/rescue/rescue/../../sbin/ipfs *** Error code 2 Stop in /usr/src/rescue/rescue. *** Error code 1 Stop in /usr/src/rescue. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. -- ------------------------------------------------------------------------ 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 Mon Apr 25 15:59: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 22B6D16A4CE for ; Mon, 25 Apr 2005 15:59:58 +0000 (GMT) Received: from web51608.mail.yahoo.com (web51608.mail.yahoo.com [206.190.38.213]) by mx1.FreeBSD.org (Postfix) with SMTP id 1AEF943D5D for ; Mon, 25 Apr 2005 15:59:57 +0000 (GMT) (envelope-from pfgshield-freebsd@yahoo.com) Received: (qmail 89496 invoked by uid 60001); 25 Apr 2005 15:59:56 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=HpBbNrZZeQYhV+QyMJm8aLx5y91vvEZWMba284vCEXWL9KxT1ctwrqX/hGOXuEyLGkE4+28eeKKTN3g+veC/B0JgwWh/gH9Lb2opq4xe/mmW/RCjMFl9BrSr232VDhpA34WSbA80d7teEx3hBUCOFUU11W1IdCqXKLXRlYkApVE= ; Message-ID: <20050425155955.89494.qmail@web51608.mail.yahoo.com> Received: from [200.119.73.50] by web51608.mail.yahoo.com via HTTP; Mon, 25 Apr 2005 17:59:55 CEST Date: Mon, 25 Apr 2005 17:59:55 +0200 (CEST) From: To: freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Tue, 26 Apr 2005 11:52:54 +0000 Subject: Re: FreeBSD 6 is coming too fast X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: pfgshield-freebsd@yahoo.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Apr 2005 15:59:58 -0000 FWIW; I tried 5.2.1, then 5.3 (briefly) and then I moved to 4.11 for the following reasons: - Bad press towards the 5.x series. - I expected 4.11 to be completely bug free and absolutely stable. - phk's axe broke one of my favorite ports and I didn't want to spend another 6 months "fixing" it. - I wanted to use XFree86-4 and building it on my own and figuring out the library mess later is not an option. - Although outdated, the downloadable java support package was available for 4.x only. In all honesty I recommend 5.x. In order to get real performance from 4.11 i had to rebuild the kernel with -Os -mcpu=pentium, and figure out how to get some poorly documented parameters right. 5.3 out-of-the-box was more responsive, it auto tunes better and is not at all slow as some irresponsible articles on the net had suggested. One thing I find extremely attractive in the 5.x series is the standards compliance.. many ports I use require patching to get working on 4.x. Also, if I can make a suggestion, installing the ports tree from the CD is a bad idea, by the time the CD is out the ports tree is already outdated. i either download the packages or build from an updated ports tree. I am convinced FreeBSD's core team is on the right track and our beloved FreeBSD will continue having a brilliant future. cheers, Pedro. ___________________________________ Nuovo Yahoo! Messenger: E' molto più divertente: Audibles, Avatar, Webcam, Giochi, Rubrica… Scaricalo ora! http://it.messenger.yahoo.it From owner-freebsd-current@FreeBSD.ORG Mon Apr 25 16:02: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 56F3816A4CE for ; Mon, 25 Apr 2005 16:02:58 +0000 (GMT) Received: from server.t-hosting.hu (server.t-hosting.hu [217.20.133.7]) by mx1.FreeBSD.org (Postfix) with ESMTP id F26D143D45 for ; Mon, 25 Apr 2005 16:02:57 +0000 (GMT) (envelope-from gabor.kovesdan@t-hosting.hu) Received: from localhost (localhost [127.0.0.1]) by server.t-hosting.hu (Postfix) with ESMTP id A28AD99758B; Mon, 25 Apr 2005 18:08:41 +0200 (CEST) Received: from server.t-hosting.hu ([127.0.0.1]) by localhost (server.t-hosting.hu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 00886-06; Mon, 25 Apr 2005 18:08:41 +0200 (CEST) Received: from [80.98.207.149] (catv-5062cf95.catv.broadband.hu [80.98.207.149]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by server.t-hosting.hu (Postfix) with ESMTP id 8C77A997504; Mon, 25 Apr 2005 18:08:40 +0200 (CEST) Message-ID: <426D14A1.9080707@t-hosting.hu> Date: Mon, 25 Apr 2005 18:02:41 +0200 From: =?ISO-8859-1?Q?K=F6vesd=E1n_G=E1bor?= User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Miguel Mendez References: <20050424175543.71041.qmail@web51805.mail.yahoo.com> <20050424151517.O68772@lexi.siliconlandmark.com> <3822.216.177.243.38.1114385370.localmail@webmail.dnswatch.com> <20050425000459.GA28667@xor.obsecurity.org> <6.2.1.2.0.20050424204611.072105a0@64.7.153.2> <20050425010242.GA44110@xor.obsecurity.org> <6.2.1.2.0.20050424210422.03d22990@64.7.153.2> <20050425014453.GA59981@xor.obsecurity.org> <426C6B1D.3040704@elischer.org> <20050425061459.GA33247@xor.obsecurity.org> <20050425062106.GB91852@voodoo.oberon.net> <426CF3DE.4000409@samsco.org> <20050425160146.4795fe1b.flynn@energyhq.es.eu.org> In-Reply-To: <20050425160146.4795fe1b.flynn@energyhq.es.eu.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at t-hosting.hu X-Mailman-Approved-At: Tue, 26 Apr 2005 11:52:54 +0000 cc: mike@sentex.net cc: freebsd-current@freebsd.org cc: julian@elischer.org cc: krion@voodoo.oberon.net cc: kris@obsecurity.org Subject: Re: FreeBSD 6 is coming too fast X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 25 Apr 2005 16:02:58 -0000 > >Definitely not for 6.0, and I usually avoid .0 releases on critical >software, but nonetheless it would interesting setting a tinderbox, >launch a buildworld process with gcc40 and see where/if it breaks. I >have a spare k6-2 box I could setup for that task. > > > What about installing gcc40 port to an alternative location and testing it with changing the CC, CFLAGS and CXXFLAGS macros so that make uses that version of gcc? I'm compiling the new gcc now, I'm interested in the result... From owner-freebsd-current@FreeBSD.ORG Mon Apr 25 16:22: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 2943A16A4CE for ; Mon, 25 Apr 2005 16:22:20 +0000 (GMT) Received: from mailtest.sd73.bc.ca (smtp.sd73.bc.ca [142.24.13.149]) by mx1.FreeBSD.org (Postfix) with ESMTP id AC79943D31 for ; Mon, 25 Apr 2005 16:22:19 +0000 (GMT) (envelope-from fcash-ml@sd73.bc.ca) Received: from localhost (localhost [127.0.0.1]) by localhost.sd73.bc.ca (Postfix) with ESMTP id B7F9AF3339 for ; Mon, 25 Apr 2005 09:22:17 -0700 (PDT) Received: from mailtest.sd73.bc.ca ([127.0.0.1]) by localhost (mailtest.sd73.bc.ca [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 81289-01-61 for ; Mon, 25 Apr 2005 09:22:15 -0700 (PDT) Received: from s9.sbo (s9.sbo [192.168.0.9]) by mailtest.sd73.bc.ca (Postfix) with ESMTP id 48B32F3221 for ; Mon, 25 Apr 2005 09:22:15 -0700 (PDT) From: Freddie Cash To: freebsd-current@freebsd.org Date: Mon, 25 Apr 2005 09:22:13 -0700 User-Agent: KMail/1.8 References: <20050425152648.GB25681@voodoo.oberon.net> <20050425161311.GA3008@troutmask.apl.washington.edu> In-Reply-To: <20050425161311.GA3008@troutmask.apl.washington.edu> Organization: School District 73 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200504250922.14394.fcash-ml@sd73.bc.ca> X-Virus-Scanned: by amavisd-new using ClamAV at sd73.bc.ca X-Mailman-Approved-At: Tue, 26 Apr 2005 11:52:54 +0000 Subject: Re: FreeBSD 6 is coming too fast X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 25 Apr 2005 16:22:20 -0000 On April 25, 2005 09:13 am, Steve Kargl wrote: > On Mon, Apr 25, 2005 at 05:26:48PM +0200, Kirill Ponomarew wrote: > > Do not forget about pointyhat which compiles a tons of ports. > > Switching it to gcc-4.0 would decrease builds time, and it's not a bad > > idea IMHO. > Any port that uses Fortran will be broken by a blanket switch > to gcc-4.0.0. g77 is no longer a GCC frontend. Gfortran, which > replaces g77, can handle somewhere around 95% of the Fortran 77 > language and around 90% of the Fortran 95 language. > If you want to try gcc-4.0.0, download the tar ball and do > configure --prefix=/usr/local --program-suffix=4 languages=c,c++ > Add CC=gcc4 to C++=g++4 to make.conf and try building a few ports. Why not just use the lang/gcc40 port? :) -- Freddie Cash, CLCP CNCP Network Support / Helpdesk School District 73 (250) 377-4357 fcash-ml@sd73.bc.ca From owner-freebsd-current@FreeBSD.ORG Mon Apr 25 19:09:22 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 680) id EA3C716A4CF; Mon, 25 Apr 2005 19:09:22 +0000 (GMT) Date: Mon, 25 Apr 2005 19:09:22 +0000 From: Darren Reed To: current@freebsd.org Message-ID: <20050425190922.GA78625@hub.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-Mailman-Approved-At: Tue, 26 Apr 2005 11:52:54 +0000 Subject: ipfilter 4.1.8 imported into 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: Mon, 25 Apr 2005 19:09:23 -0000 I've just finished importing IPFilter 4.1.8 into FreeBSD-current, in time for making 6.0. I'd appreciate any feedback about whether the changes work for you, break builds, etc. Oh, I'm going on holiday for a month in 6 hours... ;) Cheers, Darren From owner-freebsd-current@FreeBSD.ORG Mon Apr 25 22:52: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 407BE16A4CE; Mon, 25 Apr 2005 22:52:00 +0000 (GMT) Received: from Neo-Vortex.net (203-173-19-223.dyn.iinet.net.au [203.173.19.223]) by mx1.FreeBSD.org (Postfix) with ESMTP id 03DF143D58; Mon, 25 Apr 2005 22:51:59 +0000 (GMT) (envelope-from root@Neo-Vortex.net) Received: from localhost.Neo-Vortex.got-root.cc (Neo-Vortex@localhost.Neo-Vortex.got-root.cc [127.0.0.1]) by Neo-Vortex.net (8.13.1/8.12.10) with ESMTP id j3PMpuqb090594; Tue, 26 Apr 2005 08:51:57 +1000 (EST) (envelope-from root@Neo-Vortex.net) Date: Tue, 26 Apr 2005 08:51:56 +1000 (EST) From: Neo-Vortex To: Bill Paul In-Reply-To: <20050425171528.7EF8B16A4D3@hub.freebsd.org> Message-ID: <20050426084243.U87982@Neo-Vortex.net> References: <20050425171528.7EF8B16A4D3@hub.freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailman-Approved-At: Tue, 26 Apr 2005 11:52:54 +0000 cc: freebsd-current@freebsd.org cc: freebsd-hardware@freebsd.org Subject: Re: Too Evil, Too Furious X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 25 Apr 2005 22:52:00 -0000 On Mon, 25 Apr 2005, Bill Paul wrote: > The cards that I can't seem to get my hands on are: > > - Marvell wireless -- supposedly D-Link used this on a card called the > DWL-G510, but only on the first revision. The second board revision > uses an Atheros chipset, which is already supported. Unfortunately, aside > from this one PCI card, this chipset tends to only show up as a built-in > component on motherboards or laptops, which makes it hard for me to just > go out and get one. Also in Asus WL-138G (802.11g) cards - if you want i can take a few pictures of the box and card and/or give you exact chipset information from the card (its visible) - unfortunately as the card is not owned by me, i can not loan it to you. :( And no, it dosent have anything saying what HW revision, although only Marvell drivers exist for it... (on the asus website and cd anyway) Although... i might still be able to help (see below) > If you don't want > to part with your hardware, you can still help by giving me remote access > to a system with the card installed. Note that just giving me a shell > really doesn't help: in order to experiment, I need to be able to load, > test and unload kernel modules, which requires superuser access. The > ideal setup would be to use a serial console, since in some cases it > may be necessary to poke around with the kernel debugger. Don't consider > this unless you have a scratch box lying around that you can afford to > have bounced a few times, because I guarantee you I will crash the thing > a few times before I get it to work. I should be able to set up a shitty p1 test box and stick the card in it if you need... i'll be able to give you serial console access, ssh, etc, the box is yours to do as you wish :) I might need a week or so to get it set up as for i need to salvage a hdd from somewhere and either make up, or buy a nice pretty null-modem cable (to plug into another box - so you can actually access the serial console :P) > Lastly, if you can't do either of these things, you can still help by > providing some important information. If you have one of these cards, > tell me where you got it! Tell me what manufacturer and model number > it is, but also carefully inspect the box it came in and tell me _ANY_ > identifying markings on it that will help me distinguish it from all > the other cards out there. Very often, card distributors will sell two > different cards with the same part number. (I own no less than 4 cards > called the "LinkSys LNE100TX," all of which have different chipsets on > them.) D-Link and Linksys are some of the worst offenders in this area. > Even worse, most PCI cards now have metal RF shields on them that > cover up the chipsets, which makes it impossible to tell what you're > getting just by looking at the picture on the box. > > Look for hardware revision info. Look for firmware revision info. If > you can provide a URL to the exact card you got from the place you > ordered it, even better. Whatever you do, don't just tell "I have > a D-Link model so-and-so." Instead, tell me "I have a D-Link model > so-and-so that I ordered from the following URL, and the box has > a sticker that says HW rev: B3 FW rev: 2.0." If I have info like this, > I can grab a card off a store shelf when I find the right one. Otherwise, > I can't take the chance on paying for it only to find out later it > uses a chipset I already have. I can get a url from the place it was gotten from (i'll have to ask the man who brought it, but it shouldnt be a problem) - although im in Australia... wich might be a problem... the above idea might work a little better :) From owner-freebsd-current@FreeBSD.ORG Mon Apr 25 23:45: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 72AE916A4CE; Mon, 25 Apr 2005 23:45:30 +0000 (GMT) Received: from mail.soaustin.net (mail.soaustin.net [207.200.4.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 28C1143D49; Mon, 25 Apr 2005 23:45:30 +0000 (GMT) (envelope-from linimon@lonesome.com) Received: by mail.soaustin.net (Postfix, from userid 502) id 54F5C149DB; Mon, 25 Apr 2005 18:45:29 -0500 (CDT) Date: Mon, 25 Apr 2005 18:45:29 -0500 (CDT) From: Mark Linimon X-X-Sender: linimon@pancho To: Miguel Mendez In-Reply-To: <20050425160146.4795fe1b.flynn@energyhq.es.eu.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailman-Approved-At: Tue, 26 Apr 2005 11:52:54 +0000 cc: current@freebsd.org cc: mike@sentex.net cc: freebsd-current@freebsd.org cc: julian@elischer.org cc: krion@voodoo.oberon.net cc: kris@obsecurity.org Subject: Re: FreeBSD 6 is coming too fast X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 25 Apr 2005 23:45:30 -0000 On Mon, 25 Apr 2005, Miguel Mendez wrote: > According to http://gcc.gnu.org/gcc-4.0/changes.html, some of the > deprecated constructs are not even valid C, so I see this as an > opportunity to fix buggy code. You'll find that the ports tree will offer you a splendid number of opportunities, then :-) (Hint: the average age of a ports distfile is not weeks, it's months or years.) mcl From owner-freebsd-current@FreeBSD.ORG Mon Apr 25 23:45: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 72AE916A4CE; Mon, 25 Apr 2005 23:45:30 +0000 (GMT) Received: from mail.soaustin.net (mail.soaustin.net [207.200.4.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 28C1143D49; Mon, 25 Apr 2005 23:45:30 +0000 (GMT) (envelope-from linimon@lonesome.com) Received: by mail.soaustin.net (Postfix, from userid 502) id 54F5C149DB; Mon, 25 Apr 2005 18:45:29 -0500 (CDT) Date: Mon, 25 Apr 2005 18:45:29 -0500 (CDT) From: Mark Linimon X-X-Sender: linimon@pancho To: Miguel Mendez In-Reply-To: <20050425160146.4795fe1b.flynn@energyhq.es.eu.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailman-Approved-At: Tue, 26 Apr 2005 11:52:54 +0000 cc: current@freebsd.org cc: mike@sentex.net cc: freebsd-current@freebsd.org cc: julian@elischer.org cc: krion@voodoo.oberon.net cc: kris@obsecurity.org Subject: Re: FreeBSD 6 is coming too fast X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 25 Apr 2005 23:45:30 -0000 On Mon, 25 Apr 2005, Miguel Mendez wrote: > According to http://gcc.gnu.org/gcc-4.0/changes.html, some of the > deprecated constructs are not even valid C, so I see this as an > opportunity to fix buggy code. You'll find that the ports tree will offer you a splendid number of opportunities, then :-) (Hint: the average age of a ports distfile is not weeks, it's months or years.) mcl From owner-freebsd-current@FreeBSD.ORG Tue Apr 26 05:03: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 57C6116A4CE; Tue, 26 Apr 2005 05:03:55 +0000 (GMT) Received: from szamoca.krvarr.bc.ca (szamoca.krvarr.bc.ca [142.179.111.232]) by mx1.FreeBSD.org (Postfix) with ESMTP id EA06543D31; Tue, 26 Apr 2005 05:03:52 +0000 (GMT) (envelope-from sandy@krvarr.bc.ca) Received: from szamoca.krvarr.bc.ca (localhost [127.0.0.1]) by szamoca.krvarr.bc.ca (8.13.1/8.12.11) with ESMTP id j3Q53oYa043976; Mon, 25 Apr 2005 22:03:50 -0700 (PDT) (envelope-from sandy@szamoca.krvarr.bc.ca) Received: (from sandy@localhost) by szamoca.krvarr.bc.ca (8.13.1/8.12.11/Submit) id j3Q53ocg043973; Mon, 25 Apr 2005 22:03:50 -0700 (PDT) (envelope-from sandy) From: Sandy Rutherford MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17005.52150.590534.365619@szamoca.krvarr.bc.ca> Date: Mon, 25 Apr 2005 22:03:50 -0700 To: wpaul@freebsd.org (Bill Paul) In-Reply-To: <20050425171528.7EF8B16A4D3@hub.freebsd.org> References: <20050425171528.7EF8B16A4D3@hub.freebsd.org> X-Mailer: VM 7.07 under Emacs 21.3.1 X-krvarr.bc.ca-MailScanner-Information: Please contact postmaster@krvarr.bc.ca for more information. X-krvarr.bc.ca-MailScanner: Not scanned: please contact postmaster@krvarr.bc.ca for details. X-krvarr.bc.ca-MailScanner-From: sandy@szamoca.krvarr.bc.ca X-Mailman-Approved-At: Tue, 26 Apr 2005 11:52:54 +0000 cc: freebsd-current@freebsd.org cc: freebsd-hardware@freebsd.org Subject: Re: Too Evil, Too Furious X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 26 Apr 2005 05:03:55 -0000 >>>>> On Mon, 25 Apr 2005 17:15:28 +0000 (GMT), >>>>> wpaul@freebsd.org (Bill Paul) said: > - RayLink RT2500 wireless -- this one shows up on some PCI cards, but > I haven't had any luck finding one locally yet I assume that you mean RaLink (no "y"). Have you tried contacting the people at RaLink? I understand that they are very supportive of open source development. As a result, there is a Linux driver for both the rt2400 and rt2500. The project page is http://sourceforge.net/projects/rt2400. BTW, this driver seems solid. I flogged it hard with flood pings and it held up well. My rt2500 is a Belkin model F5D7010.PCMCIA card, which I have stuck in a laptop running Slackware. Unfort., I need it so I can't send it to you. I am not aware of any PCI cards using the rt2500. Given RaLink's willingness to work with the open source community, wouldn't the rt2500 be a better candidate for a native driver, rather than Project Evil? Sandy From owner-freebsd-current@FreeBSD.ORG Tue Apr 26 05:57: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 5CF9C16A4CE; Tue, 26 Apr 2005 05:57:23 +0000 (GMT) Received: from Neo-Vortex.net (203-173-19-223.dyn.iinet.net.au [203.173.19.223]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3F85943D1D; Tue, 26 Apr 2005 05:57:22 +0000 (GMT) (envelope-from root@Neo-Vortex.net) Received: from localhost.Neo-Vortex.got-root.cc (Neo-Vortex@localhost.Neo-Vortex.got-root.cc [127.0.0.1]) by Neo-Vortex.net (8.13.1/8.12.10) with ESMTP id j3Q5vKUM052887; Tue, 26 Apr 2005 15:57:20 +1000 (EST) (envelope-from root@Neo-Vortex.net) Date: Tue, 26 Apr 2005 15:57:20 +1000 (EST) From: Neo-Vortex To: Sandy Rutherford In-Reply-To: <17005.52150.590534.365619@szamoca.krvarr.bc.ca> Message-ID: <20050426155438.L52269@Neo-Vortex.net> References: <20050425171528.7EF8B16A4D3@hub.freebsd.org> <17005.52150.590534.365619@szamoca.krvarr.bc.ca> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailman-Approved-At: Tue, 26 Apr 2005 11:52:54 +0000 cc: Bill Paul cc: freebsd-current@freebsd.org cc: freebsd-hardware@freebsd.org Subject: Re: Too Evil, Too Furious X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 26 Apr 2005 05:57:23 -0000 On Mon, 25 Apr 2005, Sandy Rutherford wrote: > Given RaLink's willingness to work with the open source community, > wouldn't the rt2500 be a better candidate for a native driver, rather > than Project Evil? Of course... but if RaLink cards dont work with Project Evil, chances are some other cards might use the same kind of thing that RaLink uses in its w32 driver that dosen't work on Project Evil, so they would remain broken... but if it did work... then its more of a complete NDIS 'emulator' or whatever you want to call it... :) - although i think it would probobly be of less importance over the other cards where the manufacturer isn't that nice... ~Neo-Vortex From owner-freebsd-current@FreeBSD.ORG Tue Apr 26 09:34: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 1FA0316A4CE; Tue, 26 Apr 2005 09:34:52 +0000 (GMT) Received: from szamoca.krvarr.bc.ca (szamoca.krvarr.bc.ca [142.179.111.232]) by mx1.FreeBSD.org (Postfix) with ESMTP id C133A43D58; Tue, 26 Apr 2005 09:34:51 +0000 (GMT) (envelope-from sandy@krvarr.bc.ca) Received: from szamoca.krvarr.bc.ca (localhost [127.0.0.1]) by szamoca.krvarr.bc.ca (8.13.1/8.12.11) with ESMTP id j3Q9YlA2045534; Tue, 26 Apr 2005 02:34:47 -0700 (PDT) (envelope-from sandy@szamoca.krvarr.bc.ca) Received: (from sandy@localhost) by szamoca.krvarr.bc.ca (8.13.1/8.12.11/Submit) id j3Q9YlAZ045531; Tue, 26 Apr 2005 02:34:47 -0700 (PDT) (envelope-from sandy) From: Sandy Rutherford MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17006.2871.132904.797436@szamoca.krvarr.bc.ca> Date: Tue, 26 Apr 2005 02:34:47 -0700 To: Eric Masson , wpaul@FreeBSD.ORG (Bill Paul), freebsd-current@FreeBSD.ORG, freebsd-hardware@FreeBSD.ORG In-Reply-To: <17006.1503.797853.320224@szamoca.krvarr.bc.ca> References: <17005.52150.590534.365619@szamoca.krvarr.bc.ca> <20050426071557.2650716A4CF@hub.freebsd.org> <17005.63479.96819.128347@szamoca.krvarr.bc.ca> <86acnlx6ne.fsf@srvbsdnanssv.interne.kisoft-services.com> <17006.1503.797853.320224@szamoca.krvarr.bc.ca> X-Mailer: VM 7.07 under Emacs 21.3.1 X-krvarr.bc.ca-MailScanner-Information: Please contact postmaster@krvarr.bc.ca for more information. X-krvarr.bc.ca-MailScanner: Not scanned: please contact postmaster@krvarr.bc.ca for details. X-krvarr.bc.ca-MailScanner-From: sandy@szamoca.krvarr.bc.ca X-Mailman-Approved-At: Tue, 26 Apr 2005 11:52:54 +0000 Subject: Re: Too Evil, Too Furious X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 26 Apr 2005 09:34:52 -0000 >>>>> On Tue, 26 Apr 2005 02:11:59 -0700, >>>>> Sandy Rutherford said: >>>>> On Tue, 26 Apr 2005 10:51:33 +0200, >>>>> Eric Masson said: >> Iirc, Damien Bergamini got support from Ralink in writing ral(4) and >> ural(4) drivers. > I wasn't aware of ral(4). Is this in 6.0-current (I'm not on the > -current list). To answer my own post... ral(4) is a native rt2500 driver for *BSD. It was committed to CURRENT on April 19. See: http://damien.bergamini.free.fr/ral/. Bill, if you check the link "Supported Devices" on this page you will get a table of cards with the rt2500 chipset. I think that this is the same table that I pointed you to earlier. Sandy From owner-freebsd-current@FreeBSD.ORG Tue Apr 26 08:12: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 3AC4A16A4CE; Tue, 26 Apr 2005 08:12:49 +0000 (GMT) Received: from szamoca.krvarr.bc.ca (szamoca.krvarr.bc.ca [142.179.111.232]) by mx1.FreeBSD.org (Postfix) with ESMTP id C61CF43D39; Tue, 26 Apr 2005 08:12:48 +0000 (GMT) (envelope-from sandy@krvarr.bc.ca) Received: from szamoca.krvarr.bc.ca (localhost [127.0.0.1]) by szamoca.krvarr.bc.ca (8.13.1/8.12.11) with ESMTP id j3Q8Cd2b045068; Tue, 26 Apr 2005 01:12:39 -0700 (PDT) (envelope-from sandy@szamoca.krvarr.bc.ca) Received: (from sandy@localhost) by szamoca.krvarr.bc.ca (8.13.1/8.12.11/Submit) id j3Q8CdBp045065; Tue, 26 Apr 2005 01:12:39 -0700 (PDT) (envelope-from sandy) From: Sandy Rutherford MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17005.63479.96819.128347@szamoca.krvarr.bc.ca> Date: Tue, 26 Apr 2005 01:12:39 -0700 To: wpaul@FreeBSD.ORG (Bill Paul) In-Reply-To: <20050426071557.2650716A4CF@hub.freebsd.org> References: <17005.52150.590534.365619@szamoca.krvarr.bc.ca> <20050426071557.2650716A4CF@hub.freebsd.org> X-Mailer: VM 7.07 under Emacs 21.3.1 X-krvarr.bc.ca-MailScanner-Information: Please contact postmaster@krvarr.bc.ca for more information. X-krvarr.bc.ca-MailScanner: Not scanned: please contact postmaster@krvarr.bc.ca for details. X-krvarr.bc.ca-MailScanner-From: sandy@szamoca.krvarr.bc.ca X-Mailman-Approved-At: Tue, 26 Apr 2005 11:52:54 +0000 cc: freebsd-current@FreeBSD.ORG cc: freebsd-hardware@FreeBSD.ORG Subject: Re: Too Evil, Too Furious X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 26 Apr 2005 08:12:49 -0000 >>>>> On Tue, 26 Apr 2005 07:15:57 +0000 (GMT), >>>>> wpaul@FreeBSD.ORG (Bill Paul) said: >> >>>>> On Mon, 25 Apr 2005 17:15:28 +0000 (GMT), >> >>>>> wpaul@freebsd.org (Bill Paul) said: >> >> > - RayLink RT2500 wireless -- this one shows up on some PCI cards, but >> > I haven't had any luck finding one locally yet >> >> I assume that you mean RaLink (no "y"). Have you tried contacting the >> people at RaLink? I understand that they are very supportive of open >> source development. As a result, there is a Linux driver for both the >> rt2400 and rt2500. > If they were really supportive of open source, there would be manuals > for the RT2400 and RT2500 chipsets on their website that people could > download. ... Well, yes that would be ideal. However, it's worth asking them for the manuals, don't you think? > "But Linux support means open source support, right?" Of course not. I didn't say any such thing. > No, it just means Linux support. I know. > I'm sure the marketing people would like you to think > the two things are equal, but they really aren't. I neither know nor care what the marketing people would like me to believe. As you know, it has become relatively common for vendors to make binary drivers available for Linux. However, in RaLink's case they GPLed the source for their driver. This is not so common and leads me to believe that it is at least worth asking them for manuals. The project developers for the Linux rt2400/rt2500 driver are Ivo van Doorn , Luis Correia , and Mark Wallis . If having the manuals would be helpful for Project Evil, then perhaps, they could put you in contact the relevant person at RaLink. > "But you can easily port the Linux driver, right?" Would you please stop trying to putting words in my mouth. I know that this is neither trivial, nor the best way to go about writing a driver. > You've just provided a perfect example of model number confusion. Your > Belkin F5D7010 card has a RaLink chipset. But Belkin has another card > also called the F5D7010 which has a Broadcom chipset. I found a Belkin > F5D7010 card at CompUSA this past weekend, but I couldn't buy it since > there was no way to tell which revision it was, and I didn't want to > end up with yet another Broadcom cardbus card. I came across http://ralink.rapla.net/, which lists all cards with the rt2500 chipset. It looks like the F5D7010 vers. 2 has the rt2500, whereas presumably vers. 1 uses the Broadcom chipset. My card has vers. 3 on it, which isn't listed in the table. It seems that they stuck with the rt2500 for vers. 3. I agree with you that hardware manufacturers should do a complete model number change when they change chipsets, rather than just update the rev. number. > Right now my goal is to make Project Evil support the NDIS spec as > well as possible, and for that I need to test as many NDIS drivers as > possible. > If someone else wants to create a native driver, then more power to > them. I've written more than enough drivers for one lifetime. I know. [szamoca:38] grep "Bill Paul" /usr/src/sys/pci/* | wc -l 112 [szamoca:39] Thanks, by the way. Sandy From owner-freebsd-current@FreeBSD.ORG Tue Apr 26 09:12: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 5FA8B16A4D9; Tue, 26 Apr 2005 09:12:08 +0000 (GMT) Received: from szamoca.krvarr.bc.ca (szamoca.krvarr.bc.ca [142.179.111.232]) by mx1.FreeBSD.org (Postfix) with ESMTP id DBF7943D53; Tue, 26 Apr 2005 09:12:07 +0000 (GMT) (envelope-from sandy@krvarr.bc.ca) Received: from szamoca.krvarr.bc.ca (localhost [127.0.0.1]) by szamoca.krvarr.bc.ca (8.13.1/8.12.11) with ESMTP id j3Q9C0Au045426; Tue, 26 Apr 2005 02:12:00 -0700 (PDT) (envelope-from sandy@szamoca.krvarr.bc.ca) Received: (from sandy@localhost) by szamoca.krvarr.bc.ca (8.13.1/8.12.11/Submit) id j3Q9Bxtl045423; Tue, 26 Apr 2005 02:11:59 -0700 (PDT) (envelope-from sandy) From: Sandy Rutherford MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17006.1503.797853.320224@szamoca.krvarr.bc.ca> Date: Tue, 26 Apr 2005 02:11:59 -0700 To: Eric Masson In-Reply-To: <86acnlx6ne.fsf@srvbsdnanssv.interne.kisoft-services.com> References: <17005.52150.590534.365619@szamoca.krvarr.bc.ca> <20050426071557.2650716A4CF@hub.freebsd.org> <17005.63479.96819.128347@szamoca.krvarr.bc.ca> <86acnlx6ne.fsf@srvbsdnanssv.interne.kisoft-services.com> X-Mailer: VM 7.07 under Emacs 21.3.1 X-krvarr.bc.ca-MailScanner-Information: Please contact postmaster@krvarr.bc.ca for more information. X-krvarr.bc.ca-MailScanner: Not scanned: please contact postmaster@krvarr.bc.ca for details. X-krvarr.bc.ca-MailScanner-From: sandy@szamoca.krvarr.bc.ca X-Mailman-Approved-At: Tue, 26 Apr 2005 11:52:54 +0000 cc: Bill Paul cc: freebsd-current@FreeBSD.ORG cc: freebsd-hardware@FreeBSD.ORG Subject: Re: Too Evil, Too Furious X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 26 Apr 2005 09:12:09 -0000 >>>>> On Tue, 26 Apr 2005 10:51:33 +0200, >>>>> Eric Masson said: > Iirc, Damien Bergamini got support from Ralink in writing ral(4) and > ural(4) drivers. I wasn't aware of ral(4). Is this in 6.0-current (I'm not on the -current list). Sandy From owner-freebsd-current@FreeBSD.ORG Tue Apr 26 10:06: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 BF7E516A4D2 for ; Tue, 26 Apr 2005 10:06:16 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6AEFA43D4C for ; Tue, 26 Apr 2005 10:06:15 +0000 (GMT) (envelope-from oppermann@networx.ch) Received: (qmail 17989 invoked from network); 26 Apr 2005 10:07:13 -0000 Received: from unknown (HELO networx.ch) ([62.48.0.53]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 26 Apr 2005 10:07:13 -0000 Message-ID: <426E1296.DF6264EF@networx.ch> Date: Tue, 26 Apr 2005 12:06:14 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: David Malone References: <200504261055.aa95182@salmon.maths.tcd.ie> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 26 Apr 2005 11:52:54 +0000 cc: silby@freebsd.org cc: qingli@freebsd.org cc: Matthew Sullivan cc: Andre Oppermann cc: freebsd-current@freebsd.org Subject: Re: DF (Don't frag) issues X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 26 Apr 2005 10:06:16 -0000 David Malone wrote: > > > > I wonder if we could look into the quoted IP header and extract the > > > length of the IP packet that caused the needs-frag ICMP. That would > > > stop us getting in knots when there are a few packets in flight and > > > would give us a good idea about where we need to step down from. > > > This is a really clever idea indeed. But it only works if part of > > the original packet is attached. Broken implementations are likely > > to omit that. But I'll implement your suggestion as well and post > > a new patch later this evening. > > In the case of TCP PMTU we should be OK because we to get as far > as the TCP code I think we'll always have enough quoted packet? > Of course, in the more general case we can't always do this, but > it should help in a lot of cases. There is no general case anymore as we must ignore those packets. Otherwise we have open up the hole again. Which means we always have the IP header. On the other hand it means that it is very likely, if not certain, that we get a suggested MTU value. -- Andre From owner-freebsd-current@FreeBSD.ORG Tue Apr 26 12:13: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 560EA16A4CE for ; Tue, 26 Apr 2005 12:13:10 +0000 (GMT) Received: from pegasus.freiberg-net.de (pegasus.freibergnet.de [80.243.43.9]) by mx1.FreeBSD.org (Postfix) with ESMTP id 71ABA43D46 for ; Tue, 26 Apr 2005 12:13:09 +0000 (GMT) (envelope-from holm@pegasus.freiberg-net.de) Received: from pegasus.freiberg-net.de (localhost.freiberg-net.de [127.0.0.1]) j3QCD81Q040750 for ; Tue, 26 Apr 2005 14:13:08 +0200 (CEST) (envelope-from holm@pegasus.freiberg-net.de) Received: (from holm@localhost) by pegasus.freiberg-net.de (8.13.3/8.13.1/Submit) id j3QCD7eY040749 for freebsd-current@freebsd.org; Tue, 26 Apr 2005 14:13:07 +0200 (CEST) (envelope-from holm) Date: Tue, 26 Apr 2005 14:13:07 +0200 From: Holm Tiffe To: freebsd-current@freebsd.org Message-ID: <20050426121252.GC18078@pegasus.freiberg-net.de> Mail-Followup-To: Holm Tiffe , freebsd-current@freebsd.org References: <20050420221903.GA738@bart.bsd-geek.de> <200504211606.j3LG6gbc007250@peedub.jennejohn.org> <20050426080203.GB1413@pegasus.freiberg-net.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050426080203.GB1413@pegasus.freiberg-net.de> User-Agent: Mutt/1.4.2.1i Organization: FreibergNet Internet Services Priority: normal X-Phone: +49-3731-419010 X-Fax: +49-3731-4196026 X-PGP-fingerprint: 86 EC A5 63 B5 28 78 13 8B FC E9 09 04 6E 86 FC Subject: Re: library problems with -CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: holm@freibergnet.de List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2005 12:13:10 -0000 Holm Tiffe wrote: > Gary Jennejohn wrote: > > > > > Lars Engels writes: > > > Hi all! > > > > > > I just upgraded my 5.4-PRERELEASE notebook to -CURRENT. > > > Compilation and installation went fine, but when I try to start firefox, > > > gkrellm and even portupgrade I get the following error message: > > > /libexec/ld-elf.so.1: /usr/lib/libpthread.so.1: Undefined symbol > > > "i386_get_gsbase" > > > > > > Is there something i have not spotted in UPDATING? > > > > > > System: FreeBSD 6.0-CURRENT #5: Wed Apr 20 23:21:11 CEST 2005 > > > > > > > It's not in UPDATING, but a change was recently made (can't say exactly > > when) which affects %gs/%fs. If you're using -current then you really > > should watch the commits, too! > > > > Yes we should watch the commitlogs, but it's really bad behavior to brake > that many of the installed Applications and not to mention this fact in > UPDATING. That's what IMHO version numbers for. > > I'm reverting back to 04/13/2005 since I don't have the time now to > recompile everything to get my work done .. > After some investigation: davidxu has tried to fix this misbehavior trough adding i386_get_gsbase(void **addr) { return (sysarch(I386_GET_GSBASE, addr)); } int i386_set_gsbase(void *addr) { return (sysarch(I386_SET_GSBASE, &addr)); } to lib/libthr/arch/i386/i386/pthread_md.c (2005-04-23 02:14:38 UTC) but doesn not fix anything on my machine. I've added those functions to /usr/src/lib/libpthread/arch/i386/i386/pthread_md.c to, recompiled libpthread and installed it, now my galeon, mozilla etc. is running again. Someone should look at this. ... making world now... Holm -- L&P::Kommunikation GbR Holm Tiffe * Administration, Development FreibergNet.de Internet Systems phone +49 3731 419010 Bereich Server & Technik fax +49 3731 4196026 D-09599 Freiberg * Am St. Niclas Schacht 13 http://www.freibergnet.de From owner-freebsd-current@FreeBSD.ORG Tue Apr 26 12:23: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 C5B7616A4CE for ; Tue, 26 Apr 2005 12:23:49 +0000 (GMT) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 933EE43D6B for ; Tue, 26 Apr 2005 12:23:48 +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 j3QCRRxJ044996; Tue, 26 Apr 2005 15:27:27 +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 73042-15; Tue, 26 Apr 2005 15:23:35 +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 j3QCRQwV044992 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 Apr 2005 15:27:27 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.13.3/8.13.3) id j3QCNiNi093829; Tue, 26 Apr 2005 15:23:44 +0300 (EEST) (envelope-from ru) Date: Tue, 26 Apr 2005 15:23:44 +0300 From: Ruslan Ermilov To: Eric Anderson Message-ID: <20050426122343.GB93257@ip.net.ua> References: <426E27B0.2080109@centtech.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Bn2rw/3z4jIqBvZU" Content-Disposition: inline In-Reply-To: <426E27B0.2080109@centtech.com> User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new at ip.net.ua cc: FreeBSD Current Subject: Re: buildworld busted (rescue / ipfs) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 26 Apr 2005 12:23:49 -0000 --Bn2rw/3z4jIqBvZU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Apr 26, 2005 at 06:36:16AM -0500, Eric Anderson wrote: > cvsup from about 5 mins ago: >=20 > =3D=3D=3D> rescue/rescue/ipf/ipresend (clean) > rm -f y.tab.c y.tab.h ipresend ipresend.o ip.o resend.o sbpf.o sock.o=20 > 44arp.o ipresend.1.gz ipresend.1.cat.gz > cd /usr/src/rescue/rescue/../../sbin/ipfs &&=20 > MAKEOBJDIRPREFIX=3D/usr/obj/usr/src/rescue/rescue make=20 > DIRPRFX=3Drescue/rescue/ipfs/ clean > cd: can't cd to /usr/src/rescue/rescue/../../sbin/ipfs > *** Error code 2 >=20 I will commit a fix shortly, if nobody bites me. Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --Bn2rw/3z4jIqBvZU Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFCbjLPqRfpzJluFF4RAvSJAKCcxPgMyAXy9AJb6LzM4p4rb2c7OwCeKwdj 645Krcs3nTO262xFooGex/M= =JMQt -----END PGP SIGNATURE----- --Bn2rw/3z4jIqBvZU-- From owner-freebsd-current@FreeBSD.ORG Tue Apr 26 13:34: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 303D616A4CE for ; Tue, 26 Apr 2005 13:34:59 +0000 (GMT) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.204]) by mx1.FreeBSD.org (Postfix) with ESMTP id C970143D4C for ; Tue, 26 Apr 2005 13:34:58 +0000 (GMT) (envelope-from kometen@gmail.com) Received: by rproxy.gmail.com with SMTP id a41so1114654rng for ; Tue, 26 Apr 2005 06:34:58 -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=fsWWLaY6FUWdS2ZBVNhaUBDKxXwY7TWTSQq6GgrC2zzBr2ePWPDZFdOJ6+UQu1HDX23ddSM4Ig1fcjec8X9PH1w3478d8i53CX6LszeAoDPJmeXG6TECpXTv+9esjXCt5sFS9en5jz3iffPKdTI7OsRaWpM668W047nCGuREBs0= Received: by 10.38.9.64 with SMTP id 64mr7569512rni; Tue, 26 Apr 2005 06:34:58 -0700 (PDT) Received: by 10.38.149.53 with HTTP; Tue, 26 Apr 2005 06:34:58 -0700 (PDT) Message-ID: Date: Tue, 26 Apr 2005 15:34:58 +0200 From: Claus Guttesen To: Darren Reed In-Reply-To: <20050425190922.GA78625@hub.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <20050425190922.GA78625@hub.freebsd.org> cc: current@freebsd.org Subject: Re: ipfilter 4.1.8 imported into freebsd X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Claus Guttesen List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2005 13:34:59 -0000 > I've just finished importing IPFilter 4.1.8 into FreeBSD-current, in time > for making 6.0. I'd appreciate any feedback about whether the changes wo= rk > for you, break builds, etc. /usr/src/sbin/ipf/libipf/../../../contrib/ipfilter/lib/ipf_dotuning.c:4:17: ipl.h: No such file or directory mkdep: compile failed *** Error code 1 Stop in /usr/src/sbin/ipf/libipf. *** Error code 1 Stop in /usr/src/sbin/ipf. *** Error code 1 Stop in /usr/src/sbin. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. >From cvsup at 15.00 GMT +1. This workstation was cvsup'ed from 5.4 release to current. > Oh, I'm going on holiday for a month in 6 hours... Have a nice trip! regards Claus From owner-freebsd-current@FreeBSD.ORG Tue Apr 26 13:35: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 21B4A16A4CE for ; Tue, 26 Apr 2005 13:35:24 +0000 (GMT) Received: from aiolos.otenet.gr (aiolos.otenet.gr [195.170.0.23]) by mx1.FreeBSD.org (Postfix) with ESMTP id 75CE843D53 for ; Tue, 26 Apr 2005 13:35:20 +0000 (GMT) (envelope-from keramida@linux.gr) Received: from orion.daedalusnetworks.priv (aris.bedc.ondsl.gr [62.103.39.226])j3QDXxTd015316; Tue, 26 Apr 2005 16:34:00 +0300 Received: from orion.daedalusnetworks.priv (orion [127.0.0.1]) j3QDZEQw003157; Tue, 26 Apr 2005 16:35:14 +0300 (EEST) (envelope-from keramida@linux.gr) Received: (from keramida@localhost)j3QDZE5V003156; Tue, 26 Apr 2005 16:35:14 +0300 (EEST) (envelope-from keramida@linux.gr) Date: Tue, 26 Apr 2005 16:35:14 +0300 From: Giorgos Keramidas To: Eric Anderson Message-ID: <20050426133514.GA3032@orion.daedalusnetworks.priv> References: <426E27B0.2080109@centtech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <426E27B0.2080109@centtech.com> cc: freebsd-current@freebsd.org Subject: Re: buildworld busted (rescue / ipfs) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 26 Apr 2005 13:35:24 -0000 On 2005-04-26 06:36, Eric Anderson wrote: > cvsup from about 5 mins ago: > > ===> rescue/rescue/ipf/ipresend (clean) > rm -f y.tab.c y.tab.h ipresend ipresend.o ip.o resend.o sbpf.o sock.o > 44arp.o ipresend.1.gz ipresend.1.cat.gz > cd /usr/src/rescue/rescue/../../sbin/ipfs && MAKEOBJDIRPREFIX=/usr/obj/usr/src/rescue/rescue make DIRPRFX=rescue/rescue/ipfs/ clean > cd: can't cd to /usr/src/rescue/rescue/../../sbin/ipfs > *** Error code 2 > > Stop in /usr/src/rescue/rescue. > *** Error code 1 This is a well known issue already. The latest import of IP Filter seems to be the culprit. Update your sources to -D '2005/04/24 20:08:29 UTC' or earlier to avoid the huge mess this has created :-( From owner-freebsd-current@FreeBSD.ORG Tue Apr 26 13:44: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 CEFD716A4CE for ; Tue, 26 Apr 2005 13:44:44 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1158A43D2F for ; Tue, 26 Apr 2005 13:44: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.3/8.13.3) with ESMTP id j3QDnCov010506; Tue, 26 Apr 2005 07:49:12 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <426E44F6.5080601@samsco.org> Date: Tue, 26 Apr 2005 07:41:10 -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: Giorgos Keramidas References: <426E27B0.2080109@centtech.com> <20050426133514.GA3032@orion.daedalusnetworks.priv> In-Reply-To: <20050426133514.GA3032@orion.daedalusnetworks.priv> 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 cc: Eric Anderson Subject: Re: buildworld busted (rescue / ipfs) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 26 Apr 2005 13:44:44 -0000 Giorgos Keramidas wrote: > On 2005-04-26 06:36, Eric Anderson wrote: > >>cvsup from about 5 mins ago: >> >>===> rescue/rescue/ipf/ipresend (clean) >>rm -f y.tab.c y.tab.h ipresend ipresend.o ip.o resend.o sbpf.o sock.o >>44arp.o ipresend.1.gz ipresend.1.cat.gz >>cd /usr/src/rescue/rescue/../../sbin/ipfs && MAKEOBJDIRPREFIX=/usr/obj/usr/src/rescue/rescue make DIRPRFX=rescue/rescue/ipfs/ clean >>cd: can't cd to /usr/src/rescue/rescue/../../sbin/ipfs >>*** Error code 2 >> >>Stop in /usr/src/rescue/rescue. >>*** Error code 1 > > > This is a well known issue already. The latest import of IP Filter > seems to be the culprit. Update your sources to -D '2005/04/24 20:08:29 > UTC' or earlier to avoid the huge mess this has created :-( > Or put NO_IPFILTER into /etc/make.conf Scott From owner-freebsd-current@FreeBSD.ORG Tue Apr 26 13:46: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 3ED7516A4CE for ; Tue, 26 Apr 2005 13:46:31 +0000 (GMT) Received: from galilee.polands.org (CPE-24-208-53-189.new.res.rr.com [24.208.53.189]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5A0F843D4C for ; Tue, 26 Apr 2005 13:46:30 +0000 (GMT) (envelope-from djp@polands.org) Received: from jericho.polands.org ([172.16.1.35]) by galilee.polands.org (8.12.9/8.12.9) with ESMTP id j3QDkCJB025631; Tue, 26 Apr 2005 08:46:20 -0500 (CDT) (envelope-from djp@polands.org) Received: from jericho.polands.org (localhost [127.0.0.1]) by jericho.polands.org (8.13.3/8.13.1) with ESMTP id j3QDkCqu069522; Tue, 26 Apr 2005 08:46:12 -0500 (CDT) (envelope-from djp@jericho.polands.org) Received: (from djp@localhost) by jericho.polands.org (8.13.3/8.13.1/Submit) id j3QDkBX2069521; Tue, 26 Apr 2005 08:46:11 -0500 (CDT) (envelope-from djp) Date: Tue, 26 Apr 2005 08:46:11 -0500 From: Doug Poland To: Matthew Sullivan Message-ID: <20050426134611.GB69433@polands.org> References: <4267A1CF.3080903@uq.edu.au> <20050422190208.M68772@lexi.siliconlandmark.com> <426C93AC.3030907@root.org> <20050425200601.I42718@carver.gumbysoft.com> <426DB58B.5020608@uq.edu.au> <20050425204148.H43358@carver.gumbysoft.com> <426DDABF.8050708@uq.edu.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <426DDABF.8050708@uq.edu.au> User-Agent: Mutt/1.5.9i cc: freebsd-current@freebsd.org cc: Nate Lawson Subject: Re: SMP on Compaq DL380 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 26 Apr 2005 13:46:31 -0000 I realize this is the -CURRENT list, but, I've got a DL380 (2x700MHz) running nicely on 5.3-STABLE. I'd be happy to include any config/params for comparison. -- Regards, Doug From owner-freebsd-current@FreeBSD.ORG Tue Apr 26 13:56: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 4FF2E16A4CE for ; Tue, 26 Apr 2005 13:56:00 +0000 (GMT) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2209E43D3F for ; Tue, 26 Apr 2005 13:56:00 +0000 (GMT) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) j3QDtxgb088760; Tue, 26 Apr 2005 06:55:59 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost)j3QDtv3m088757; Tue, 26 Apr 2005 06:55:57 -0700 (PDT) (envelope-from sgk) Date: Tue, 26 Apr 2005 06:55:57 -0700 From: Steve Kargl To: Freddie Cash Message-ID: <20050426135557.GA88701@troutmask.apl.washington.edu> References: <20050425152648.GB25681@voodoo.oberon.net> <20050425161311.GA3008@troutmask.apl.washington.edu> <200504250922.14394.fcash-ml@sd73.bc.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200504250922.14394.fcash-ml@sd73.bc.ca> User-Agent: Mutt/1.4.2.1i cc: freebsd-current@freebsd.org Subject: Re: FreeBSD 6 is coming too fast X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 26 Apr 2005 13:56:00 -0000 On Mon, Apr 25, 2005 at 09:22:13AM -0700, Freddie Cash wrote: > On April 25, 2005 09:13 am, Steve Kargl wrote: > > On Mon, Apr 25, 2005 at 05:26:48PM +0200, Kirill Ponomarew wrote: > > > Do not forget about pointyhat which compiles a tons of ports. > > > Switching it to gcc-4.0 would decrease builds time, and it's not a bad > > > idea IMHO. > > Any port that uses Fortran will be broken by a blanket switch > > to gcc-4.0.0. g77 is no longer a GCC frontend. Gfortran, which > > replaces g77, can handle somewhere around 95% of the Fortran 77 > > language and around 90% of the Fortran 95 language. > > > If you want to try gcc-4.0.0, download the tar ball and do > > configure --prefix=/usr/local --program-suffix=4 languages=c,c++ > > Add CC=gcc4 to C++=g++4 to make.conf and try building a few ports. > > Why not just use the lang/gcc40 port? :) > Notice I wrote gcc-4.0.0. The lang/gcc40 port grabs a snapshot of the 4.0 branch. You will get a preview of gcc-4.0.1, which may not be a bad thing. -- Steve From owner-freebsd-current@FreeBSD.ORG Tue Apr 26 14:15: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 CE92F16A4CE for ; Tue, 26 Apr 2005 14:15:59 +0000 (GMT) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id B342443D39 for ; Tue, 26 Apr 2005 14:15:59 +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 1DQQr1-000BQC-DD for freebsd-current@freebsd.org; Tue, 26 Apr 2005 14:15:59 +0000 Received: from [127.0.0.1] (helo=roam.psg.com.psg.com) by roam.psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DQQqz-0001WJ-0V for freebsd-current@freebsd.org; Tue, 26 Apr 2005 04:15:57 -1000 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17006.19740.605509.984940@roam.psg.com> Date: Tue, 26 Apr 2005 04:15:56 -1000 To: FreeBSD Current Subject: ule+preempt? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 26 Apr 2005 14:15:59 -0000 having been seriously burned, i have avoided ule for some months. i am wondering if the waters have become relatively safe to go to ule with preemption? randy From owner-freebsd-current@FreeBSD.ORG Tue Apr 26 15:34: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 B996916A4CE for ; Tue, 26 Apr 2005 15:34:42 +0000 (GMT) Received: from crumpet.united-ware.com (ddsl-66-42-172-210.fuse.net [66.42.172.210]) by mx1.FreeBSD.org (Postfix) with ESMTP id EDA1C43D2D for ; Tue, 26 Apr 2005 15:34:41 +0000 (GMT) (envelope-from mistry.7@osu.edu) Received: from [192.168.1.100] (adsl-68-75-18-7.dsl.wotnoh.ameritech.net [68.75.18.7]) (authenticated bits=0)j3QF1wjO038667 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Tue, 26 Apr 2005 11:01:58 -0400 (EDT) (envelope-from mistry.7@osu.edu) From: Anish Mistry To: Randy Bush Date: Tue, 26 Apr 2005 11:34:53 -0400 User-Agent: KMail/1.8 References: <17006.19740.605509.984940@roam.psg.com> In-Reply-To: <17006.19740.605509.984940@roam.psg.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2109958.LX0zOsa3TK"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200504261135.07833.mistry.7@osu.edu> X-Spam-Status: No, hits=0.6 required=5.0 tests=J_CHICKENPOX_37 autolearn=no version=2.64 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on crumpet.united-ware.com cc: freebsd-current@freebsd.org Subject: Re: ule+preempt? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 26 Apr 2005 15:34:42 -0000 --nextPart2109958.LX0zOsa3TK Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Tuesday 26 April 2005 10:15 am, Randy Bush wrote: > having been seriously burned, i have avoided ule for some months. > i am wondering if the waters have become relatively safe to go > to ule with preemption? > I've been running it for few weeks and it seems to be fine for now,=20 but YMMV. =2D-=20 Anish Mistry --nextPart2109958.LX0zOsa3TK Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQBCbl+rxqA5ziudZT0RApJUAJsHmedRiAGoXrUr8DB3lnH9h7s8rQCgs2hP XEvnNyG+Dxyh7h8o3mE9Tak= =Z0JR -----END PGP SIGNATURE----- --nextPart2109958.LX0zOsa3TK-- From owner-freebsd-current@FreeBSD.ORG Tue Apr 26 15:47: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 F34E216A4CE; Tue, 26 Apr 2005 15:47:57 +0000 (GMT) Received: from rosebud.otenet.gr (rosebud.otenet.gr [195.170.0.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0CC0143D45; Tue, 26 Apr 2005 15:47:57 +0000 (GMT) (envelope-from keramida@freebsd.org) Received: from orion.daedalusnetworks.priv (aris.bedc.ondsl.gr [62.103.39.226])j3QFkgLC027763; Tue, 26 Apr 2005 18:46:42 +0300 Received: from orion.daedalusnetworks.priv (orion [127.0.0.1]) j3QFltKC088934; Tue, 26 Apr 2005 18:47:55 +0300 (EEST) (envelope-from keramida@freebsd.org) Received: (from keramida@localhost)j3QFlsdI088930; Tue, 26 Apr 2005 18:47:54 +0300 (EEST) (envelope-from keramida@freebsd.org) Date: Tue, 26 Apr 2005 18:47:54 +0300 From: Giorgos Keramidas To: Claus Guttesen , Darren Reed Message-ID: <20050426154754.GA83321@orion.daedalusnetworks.priv> References: <20050425190922.GA78625@hub.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: cc: freebsd-current@freebsd.org Subject: Re: ipfilter 4.1.8 imported into 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, 26 Apr 2005 15:47:58 -0000 On 2005-04-26 15:34, Claus Guttesen wrote: > > I've just finished importing IPFilter 4.1.8 into FreeBSD-current, in time > > for making 6.0. I'd appreciate any feedback about whether the changes work > > for you, break builds, etc. > > /usr/src/sbin/ipf/libipf/../../../contrib/ipfilter/lib/ipf_dotuning.c:4:17: > ipl.h: No such file or directory > mkdep: compile failed > *** Error code 1 I have a local fix for this, which I'm testing with buildworld cycles until I get one that completes without problems. Hang on, please :-) From owner-freebsd-current@FreeBSD.ORG Tue Apr 26 15: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 84E0016A4CE; Tue, 26 Apr 2005 15:56:04 +0000 (GMT) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id BF69043D54; Tue, 26 Apr 2005 15:56:02 +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 j3QFxrDG060191; Tue, 26 Apr 2005 18:59:53 +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 84286-04; Tue, 26 Apr 2005 18:56:00 +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 j3QFxqIk060187 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 Apr 2005 18:59:52 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.13.3/8.13.3) id j3QFu9v0095502; Tue, 26 Apr 2005 18:56:09 +0300 (EEST) (envelope-from ru) Date: Tue, 26 Apr 2005 18:56:08 +0300 From: Ruslan Ermilov To: Darren Reed Message-ID: <20050426155608.GF94543@ip.net.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="8bBEDOJVaa9YlTAt" Content-Disposition: inline User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new at ip.net.ua cc: current@FreeBSD.org Subject: Patchset to fix ipfilter build breakage X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 26 Apr 2005 15:56:04 -0000 --8bBEDOJVaa9YlTAt Content-Type: multipart/mixed; boundary="cz6wLo+OExbGG7q/" Content-Disposition: inline --cz6wLo+OExbGG7q/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Darren, Maybe I could save you some time by the attached patchset. I'm building with all of your latest changes, yet the following problems. Fixed by the patchset: - libipf is made a standard library; this allows to use ipfilter bits in rescue; also fixes "make checkdpadd", - removed lot of NetBSD'ism from sbin/ipf/ makefiles, - redefinition of "rcsid" in sys/contrib/ipfilter/. Not fixed by the patchset: - A lot of warnings when compiling on amd64 (see my other email); they are masked by NO_WERROR in this patchset but should be fixed of course - rescue is still broken: the libipf library is a culprit -- it has a lot of undefined symbols that consumers are expected to provide, thus preventing it to be used in rescue. When compiling a rescue binary, it fails with the following: : MAKEOBJDIRPREFIX=3D/usr/obj/usr/src/rescue/rescue make -f rescue.mk exe : cc -static -o rescue rescue.o cat.lo chflags.lo chio.lo chmod.lo cp.lo da= te.lo dd.lo df.lo echo.lo ed.lo expr.lo getfacl.lo hostname.lo kenv.lo kill= =2Elo ln.lo ls.lo mkdir.lo mv.lo pax.lo ps.lo pwd.lo realpath.lo rm.lo rmdi= r.lo setfacl.lo sh.lo stty.lo sync.lo test.lo rcp.lo csh.lo atacontrol.lo b= adsect.lo bsdlabel.lo camcontrol.lo ccdconfig.lo clri.lo devfs.lo dmesg.lo = dump.lo dumpfs.lo dumpon.lo fsck.lo fsck_ffs.lo fsck_msdosfs.lo fsdb.lo fsi= rand.lo gbde.lo ifconfig.lo init.lo kldconfig.lo kldload.lo kldstat.lo kldu= nload.lo ldconfig.lo md5.lo mdconfig.lo mdmfs.lo mknod.lo mount.lo mount_cd= 9660.lo mount_ext2fs.lo mount_msdosfs.lo mount_nfs.lo mount_ntfs.lo mount_n= ullfs.lo mount_std.lo mount_udf.lo mount_umapfs.lo mount_unionfs.lo newfs.l= o newfs_msdos.lo nos-tun.lo ping.lo reboot.lo restore.lo rcorder.lo route.l= o routed.lo rtquery.lo rtsol.lo savecore.lo slattach.lo spppcontrol.lo star= tslip.lo swapon.lo sysctl.lo tunefs.lo umount.lo atm.lo atmconfig.lo fore_d= nld.lo ilmid.lo ping6.lo ipf.lo ipfs.lo ipfstat.lo ipmon.lo ipnat.lo fdisk.= lo dhclient.lo bzip2.lo tar.lo vi.lo id.lo gzip.lo chroot.lo /usr/obj/usr/s= rc/rescue/rescue/../librescue/exec.o /usr/obj/usr/src/rescue/rescue/../libr= escue/getusershell.o /usr/obj/usr/src/rescue/rescue/../librescue/login_clas= s.o /usr/obj/usr/src/rescue/rescue/../librescue/popen.o /usr/obj/usr/src/re= scue/rescue/../librescue/rcmdsh.o /usr/obj/usr/src/rescue/rescue/../libresc= ue/sysctl.o /usr/obj/usr/src/rescue/rescue/../librescue/system.o -lcrypt -l= edit -lkvm -ll -lm -ltermcap -lutil -lcrypto -latm -lipf -lalias -lbsdxml -= lcam -lcurses -ldevstat -lipsec -lipx -lgeom -lkiconv -lmd -lreadline -lsbu= f -lufs -lz -lbz2 -larchive : /usr/obj/usr/src/tmp/usr/lib/libipf.a(print_toif.o)(.text+0x32): In funct= ion `print_toif': : : undefined reference to `use_inet6' : /usr/obj/usr/src/tmp/usr/lib/libipf.a(nametokva.o)(.text+0x2b): In functi= on `nametokva': : : undefined reference to `opts' : /usr/obj/usr/src/tmp/usr/lib/libipf.a(load_pool.o)(.text+0xa0): In functi= on `load_pool': : : undefined reference to `opts' : /usr/obj/usr/src/tmp/usr/lib/libipf.a(load_pool.o)(.text+0xe2): In functi= on `load_pool': : : undefined reference to `opts' : /usr/obj/usr/src/tmp/usr/lib/libipf.a(load_pool.o)(.text+0x111): In funct= ion `load_pool': : : undefined reference to `opts' : /usr/obj/usr/src/tmp/usr/lib/libipf.a(load_pool.o)(.text+0x132): In funct= ion `load_pool': : : undefined reference to `opts' : /usr/obj/usr/src/tmp/usr/lib/libipf.a(load_pool.o)(.text+0x13b): more und= efined references to `opts' follow : /usr/obj/usr/src/tmp/usr/lib/libipf.a(ntomask.o)(.text+0x24): In function= `ntomask': : : undefined reference to `use_inet6' : /usr/obj/usr/src/tmp/usr/lib/libipf.a(ntomask.o)(.text+0x3d): In function= `ntomask': : : undefined reference to `use_inet6' : /usr/obj/usr/src/tmp/usr/lib/libipf.a(load_poolnode.o)(.text+0xca): In fu= nction `load_poolnode': : : undefined reference to `opts' : /usr/obj/usr/src/tmp/usr/lib/libipf.a(load_poolnode.o)(.text+0xea): In fu= nction `load_poolnode': : : undefined reference to `opts' : /usr/obj/usr/src/tmp/usr/lib/libipf.a(load_poolnode.o)(.text+0x133): In f= unction `load_poolnode': : : undefined reference to `opts' : /usr/obj/usr/src/tmp/usr/lib/libipf.a(load_poolnode.o)(.text+0x13c): In f= unction `load_poolnode': : : undefined reference to `opts' : /usr/obj/usr/src/tmp/usr/lib/libipf.a(load_hashnode.o)(.text+0xbb): In fu= nction `load_hashnode': : : undefined reference to `opts' : /usr/obj/usr/src/tmp/usr/lib/libipf.a(load_hashnode.o)(.text+0xdb): more = undefined references to `opts' follow : /usr/obj/usr/src/tmp/usr/lib/libipf.a(printmask.o)(.text+0x2): In functio= n `printmask': : : undefined reference to `use_inet6' : *** Error code 1 :=20 : Stop in /usr/obj/usr/src/rescue/rescue. : *** Error code 1 Perhaps this is easy to fix, perhaps not. If not, this means that we won't ship rescue with ipfilter bits, which would be very unfortunate for some users. In this case, we can make the libipf an internal library, not installed under /usr/lib. (This can be done by adding INTERNALLIB=3D in sbin/ipf/libipf/Makefile, and tweaking sbin/Makefile.inc to define LIBIPF as ${.OBJDIR}/.../libipf.a, and using ${LIBIPF} both in DPADD and in LDADD.) Please let me know if I can help you some more... Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --cz6wLo+OExbGG7q/ Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=p Content-Transfer-Encoding: quoted-printable Index: Makefile.inc1 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/Makefile.inc1,v retrieving revision 1.492 diff -u -r1.492 Makefile.inc1 --- Makefile.inc1 6 Apr 2005 01:55:43 -0000 1.492 +++ Makefile.inc1 26 Apr 2005 15:40:05 -0000 @@ -998,6 +998,10 @@ _prebuild_libs+=3D lib/libypclnt .endif =20 +.if !defined(NO_IPFILTER) +_generic_libs+=3D sbin/ipf/libipf +.endif + _generic_libs+=3D usr.bin/lex/lib =20 .if ${MACHINE_ARCH} =3D=3D "i386" Index: share/mk/bsd.libnames.mk =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/share/mk/bsd.libnames.mk,v retrieving revision 1.94 diff -u -r1.94 bsd.libnames.mk --- share/mk/bsd.libnames.mk 19 Apr 2005 04:01:22 -0000 1.94 +++ share/mk/bsd.libnames.mk 26 Apr 2005 15:40:05 -0000 @@ -53,6 +53,9 @@ LIBHISTORY?=3D ${DESTDIR}${LIBDIR}/libhistory.a LIBIPSEC?=3D ${DESTDIR}${LIBDIR}/libipsec.a LIBIPX?=3D ${DESTDIR}${LIBDIR}/libipx.a +.if !defined(NO_IPFILTER) +LIBIPF?=3D ${DESTDIR}${LIBDIR}/libipf.a +.endif .if !defined(NO_BIND) && defined(WITH_BIND_LIBS) LIBISC?=3D ${DESTDIR}${LIBDIR}/libisc.a LIBISCCC?=3D ${DESTDIR}${LIBDIR}/libisccc.a Index: rescue/rescue/Makefile =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/rescue/rescue/Makefile,v retrieving revision 1.42 diff -u -r1.42 Makefile --- rescue/rescue/Makefile 18 Mar 2005 12:55:07 -0000 1.42 +++ rescue/rescue/Makefile 26 Apr 2005 15:40:06 -0000 @@ -125,6 +125,7 @@ =20 .if !defined(NO_IPFILTER) CRUNCH_PROGS_sbin+=3D ipf ipfs ipfstat ipmon ipnat +CRUNCH_LIBS+=3D -lipf .endif =20 # crunchgen does not like C++ programs; this should be fixed someday @@ -166,6 +167,11 @@ CRUNCH_SRCDIR_fore_dnld=3D $(.CURDIR)/../../sbin/atm/fore_dnld CRUNCH_SRCDIR_ilmid=3D $(.CURDIR)/../../sbin/atm/ilmid CRUNCH_SRCDIR_rtquery=3D $(.CURDIR)/../../sbin/routed/rtquery +CRUNCH_SRCDIR_ipf=3D $(.CURDIR)/../../sbin/ipf/ipf +CRUNCH_SRCDIR_ipfs=3D $(.CURDIR)/../../sbin/ipf/ipfs +CRUNCH_SRCDIR_ipfstat=3D $(.CURDIR)/../../sbin/ipf/ipfstat +CRUNCH_SRCDIR_ipmon=3D $(.CURDIR)/../../sbin/ipf/ipmon +CRUNCH_SRCDIR_ipnat=3D $(.CURDIR)/../../sbin/ipf/ipnat CRUNCH_ALIAS_reboot=3D fastboot halt fasthalt CRUNCH_ALIAS_restore=3D rrestore CRUNCH_ALIAS_dump=3D rdump Index: sbin/ipf/Makefile.inc =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/sbin/ipf/Makefile.inc,v retrieving revision 1.1 diff -u -r1.1 Makefile.inc --- sbin/ipf/Makefile.inc 25 Apr 2005 18:55:50 -0000 1.1 +++ sbin/ipf/Makefile.inc 26 Apr 2005 15:40:06 -0000 @@ -1,6 +1,4 @@ -# $FreeBSD: src/sbin/ipf/Makefile.inc,v 1.1 2005/04/25 18:55:50 darrenr Ex= p $ - -.include +# $FreeBSD: src/sbin/ipf/Makefile.inc,v 1.1 2005/04/25 18:55:50 darrenr Ex= p $ =20 CFLAGS+=3D -I${.CURDIR}/../../../contrib/ipfilter CFLAGS+=3D -I${.CURDIR}/../../../contrib/ipfilter/tools @@ -8,9 +6,8 @@ CFLAGS+=3D -I${.CURDIR}/../../../sys/contrib/ipfilter CFLAGS+=3D -DSTATETOP -D__UIO_EXPOSE =20 -IPFOBJDIR=3D ${.OBJDIR}/../libipf -DPADD+=3D ${IPFOBJDIR}/libipf.a ${LIBKVM} -LDADD+=3D -L${IPFOBJDIR} -lipf -lkvm +DPADD+=3D ${LIBIPF} ${LIBKVM} +LDADD+=3D -lipf -lkvm =20 CLEANFILES+=3D y.tab.c y.tab.h =20 @@ -19,6 +16,4 @@ ${.CURDIR}/../../../contrib/ipfilter/tools \ ${.CURDIR}/../../../contrib/ipfilter/man =20 -.if exists(${.CURDIR}/../../Makefile.inc) -.include "${.CURDIR}/../../Makefile.inc" -.endif +.include "../Makefile.inc" Index: sbin/ipf/ipf/Makefile =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/sbin/ipf/ipf/Makefile,v retrieving revision 1.1 diff -u -r1.1 Makefile --- sbin/ipf/ipf/Makefile 25 Apr 2005 18:55:50 -0000 1.1 +++ sbin/ipf/ipf/Makefile 26 Apr 2005 15:40:06 -0000 @@ -14,7 +14,6 @@ CLEANFILES+=3D ipf_l.c ipf_l.h =20 ipf_y.c: ipf_y.y - ${_MKTARGET_CREATE} ${YACC} -d ${.ALLSRC} sed -e 's/yy/ipf_yy/g' \ -e 's/"ipf_y.y"/"..\/tools\/ipf_y.y"/' \ @@ -25,20 +24,13 @@ ipf_y.h: ipf_y.c =20 ipf_l.c: lexer.c - ${_MKTARGET_CREATE} sed -e 's/yy/ipf_yy/g' \ -e 's/y.tab.h/ipf_y.h/' \ -e 's/lexer.h/ipf_l.h/' \ ${.ALLSRC} > ${.TARGET} =20 ipf_l.h: lexer.h - ${_MKTARGET_CREATE} sed -e 's/yy/ipf_yy/g' \ ${.ALLSRC} > ${.TARGET} =20 -BINDIR=3D /sbin -.if defined(NO_DYNAMICROOT) -LDSTATIC?=3D -static -.endif - .include Index: sbin/ipf/ipftest/Makefile =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/sbin/ipf/ipftest/Makefile,v retrieving revision 1.2 diff -u -r1.2 Makefile --- sbin/ipf/ipftest/Makefile 26 Apr 2005 15:35:50 -0000 1.2 +++ sbin/ipf/ipftest/Makefile 26 Apr 2005 15:40:11 -0000 @@ -1,6 +1,6 @@ # $FreeBSD: src/sbin/ipf/ipftest/Makefile,v 1.2 2005/04/26 15:35:50 darren= r Exp $ =20 -NOGCCERROR=3D # defined +NO_WERROR=3D # XXX =20 .include =20 @@ -30,7 +30,6 @@ CLEANFILES+=3D ippool.tab.c ippool.tab.h =20 ipnat_y.c: ipnat_y.y - ${_MKTARGET_CREATE} ${YACC} -b ipnat -d ${.ALLSRC} sed -e 's/yy/ipnat_yy/g' \ -e 's/y.tab.c/ipnat_y.c/' \ @@ -43,19 +42,16 @@ ipnat_y.h: ipnat_y.c =20 ipnat_l.c: lexer.c - ${_MKTARGET_CREATE} sed -e 's/yy/ipnat_yy/g' \ -e 's/y.tab.h/ipnat_y.h/' \ -e 's/lexer.h/ipnat_l.h/' \ ${.ALLSRC} > ${.TARGET} =20 ipnat_l.h: lexer.h - ${_MKTARGET_CREATE} sed -e 's/yy/ipnat_yy/g' \ ${.ALLSRC} > ${.TARGET} =20 ippool_y.c: ippool_y.y - ${_MKTARGET_CREATE} ${YACC} -b ippool -d ${.ALLSRC} sed -e 's/yy/ippool_yy/g' \ -e 's/"ippool_y.y"/"..\/tools\/ippool_y.y"/' \ @@ -66,19 +62,16 @@ ippool_y.h: ippool_y.c =20 ippool_l.c: lexer.c - ${_MKTARGET_CREATE} sed -e 's/yy/ippool_yy/g' \ -e 's/y.tab.h/ippool_y.h/' \ -e 's/lexer.h/ippool_l.h/' \ ${.ALLSRC} > ${.TARGET} =20 ippool_l.h: lexer.h - ${_MKTARGET_CREATE} sed -e 's/yy/ippool_yy/g' \ ${.ALLSRC} > ${.TARGET} =20 ipf_y.c: ipf_y.y - ${_MKTARGET_CREATE} ${YACC} -b ipf -d ${.ALLSRC} sed -e 's/yy/ipf_yy/g' \ -e 's/"ipf_y.y"/"..\/tools\/ipf_y.y"/' \ @@ -89,14 +82,12 @@ ipf_y.h: ipf_y.c =20 ipf_l.c: lexer.c - ${_MKTARGET_CREATE} sed -e 's/yy/ipf_yy/g' \ -e 's/y.tab.h/ipf_y.h/' \ -e 's/lexer.h/ipf_l.h/' \ ${.ALLSRC} > ${.TARGET} =20 ipf_l.h: lexer.h - ${_MKTARGET_CREATE} sed -e 's/yy/ipf_yy/g' \ ${.ALLSRC} > ${.TARGET} =20 Index: sbin/ipf/ipmon/Makefile =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/sbin/ipf/ipmon/Makefile,v retrieving revision 1.1 diff -u -r1.1 Makefile --- sbin/ipf/ipmon/Makefile 25 Apr 2005 18:55:51 -0000 1.1 +++ sbin/ipf/ipmon/Makefile 26 Apr 2005 15:40:11 -0000 @@ -3,6 +3,7 @@ PROG=3D ipmon SRCS=3D ipmon.c ipmon_y.c ipmon_l.c MAN=3D ipmon.8 +NO_WERROR=3D # XXX =20 CFLAGS+=3D -DLOGFAC=3DLOG_LOCAL0 -I. =20 @@ -12,7 +13,6 @@ CLEANFILES+=3D ipmon_l.c ipmon_l.h =20 ipmon_y.c: ipmon_y.y - ${_MKTARGET_CREATE} ${YACC} -d ${.ALLSRC} sed -e 's/yy/ipmon_yy/g' \ -e 's/"ipmon_y.y"/"..\/tools\/ipmon_y.y"/' \ @@ -23,14 +23,12 @@ ipmon_y.h: ipmon_y.c =20 ipmon_l.c: lexer.c - ${_MKTARGET_CREATE} sed -e 's/yy/ipmon_yy/g' \ -e 's/y.tab.h/ipmon_y.h/' \ -e 's/lexer.h/ipmon_l.h/' \ ${.ALLSRC} > ${.TARGET} =20 ipmon_l.h: lexer.h - ${_MKTARGET_CREATE} sed -e 's/yy/ipmon_yy/g' \ ${.ALLSRC} > ${.TARGET} =20 Index: sbin/ipf/ipnat/Makefile =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/sbin/ipf/ipnat/Makefile,v retrieving revision 1.1 diff -u -r1.1 Makefile --- sbin/ipf/ipnat/Makefile 25 Apr 2005 18:55:51 -0000 1.1 +++ sbin/ipf/ipnat/Makefile 26 Apr 2005 15:40:11 -0000 @@ -12,7 +12,6 @@ CLEANFILES+=3D ipnat_l.c ipnat_l.h =20 ipnat_y.c: ipnat_y.y - ${_MKTARGET_CREATE} ${YACC} -d ${.ALLSRC} sed -e 's/yy/ipnat_yy/g' \ -e 's/y.tab.c/ipnat_y.c/' \ @@ -25,14 +24,12 @@ ipnat_y.h: ipnat_y.c =20 ipnat_l.c: lexer.c - ${_MKTARGET_CREATE} sed -e 's/yy/ipnat_yy/g' \ -e 's/y.tab.h/ipnat_y.h/' \ -e 's/lexer.h/ipnat_l.h/' \ ${.ALLSRC} > ${.TARGET} =20 ipnat_l.h: lexer.h - ${_MKTARGET_CREATE} sed -e 's/yy/ipnat_yy/g' \ ${.ALLSRC} > ${.TARGET} =20 Index: sbin/ipf/ippool/Makefile =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/sbin/ipf/ippool/Makefile,v retrieving revision 1.1 diff -u -r1.1 Makefile --- sbin/ipf/ippool/Makefile 25 Apr 2005 18:55:51 -0000 1.1 +++ sbin/ipf/ippool/Makefile 26 Apr 2005 15:40:11 -0000 @@ -4,6 +4,7 @@ SRCS=3D ippool_y.c ippool_l.c kmem.c ippool.c MAN=3D ippool.5 ippool.8 CFLAGS+=3D -I. +NO_WERROR=3D # XXX =20 DPSRCS+=3D ippool_l.h ippool_y.h =20 @@ -11,7 +12,6 @@ CLEANFILES+=3D ippool_l.c ippool_l.h =20 ippool_y.c: ippool_y.y - ${_MKTARGET_CREATE} ${YACC} -d ${.ALLSRC} sed -e 's/yy/ippool_yy/g' \ -e 's/"ippool_y.y"/"..\/tools\/ippool_y.y"/' \ @@ -22,14 +22,12 @@ ippool_y.h: ippool_y.c =20 ippool_l.c: lexer.c - ${_MKTARGET_CREATE} sed -e 's/yy/ippool_yy/g' \ -e 's/y.tab.h/ippool_y.h/' \ -e 's/lexer.h/ippool_l.h/' \ ${.ALLSRC} > ${.TARGET} =20 ippool_l.h: lexer.h - ${_MKTARGET_CREATE} sed -e 's/yy/ippool_yy/g' \ ${.ALLSRC} > ${.TARGET} =20 Index: sbin/ipf/ipsend/Makefile =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/sbin/ipf/ipsend/Makefile,v retrieving revision 1.1 diff -u -r1.1 Makefile --- sbin/ipf/ipsend/Makefile 25 Apr 2005 18:55:51 -0000 1.1 +++ sbin/ipf/ipsend/Makefile 26 Apr 2005 15:40:11 -0000 @@ -23,7 +23,6 @@ ${NETBSDSRCDIR}/dist/ipf/iplang =20 iplang_y.c: iplang_y.y - ${_MKTARGET_CREATE} ${YACC} -d ${.ALLSRC} mv y.tab.c ${.TARGET} mv y.tab.h ${.TARGET:.c=3D.h} Index: sbin/ipf/libipf/Makefile =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/sbin/ipf/libipf/Makefile,v retrieving revision 1.1 diff -u -r1.1 Makefile --- sbin/ipf/libipf/Makefile 25 Apr 2005 18:55:52 -0000 1.1 +++ sbin/ipf/libipf/Makefile 26 Apr 2005 15:40:11 -0000 @@ -1,11 +1,7 @@ -# $FreeBSD: src/sbin/ipf/libipf/Makefile,v 1.1 2005/04/25 18:55:52 darrenr= Exp $ - -MKPRIVATELIB=3D yes -USE_SHLIBDIR=3D yes - -NOGCCERROR=3D # defined +# $FreeBSD: src/sbin/ipf/libipf/Makefile,v 1.1 2005/04/25 18:55:52 darrenr= Exp $ =20 LIB=3D ipf +NO_WERROR=3D # XXX =20 SRCS=3D addicmp.c addipopt.c addkeep.c bcopywrap.c binprint.c \ buildopts.c checkrev.c count6bits.c count4bits.c debug.c \ Index: sys/contrib/ipfilter/netinet/fil.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/sys/contrib/ipfilter/netinet/fil.c,v retrieving revision 1.44 diff -u -r1.44 fil.c --- sys/contrib/ipfilter/netinet/fil.c 25 Apr 2005 18:43:13 -0000 1.44 +++ sys/contrib/ipfilter/netinet/fil.c 26 Apr 2005 15:40:55 -0000 @@ -136,7 +136,7 @@ =20 #if !defined(lint) static const char sccsid[] =3D "@(#)fil.c 1.36 6/5/96 (C) 1993-2000 Darren= Reed"; -static const char rcsid[] =3D "@(#)$FreeBSD: src/sys/contrib/ipfilter/neti= net/fil.c,v 1.44 2005/04/25 18:43:13 darrenr Exp $"; +static const char fbsdid[] =3D "@(#)$FreeBSD: src/sys/contrib/ipfilter/net= inet/fil.c,v 1.44 2005/04/25 18:43:13 darrenr Exp $"; static const char rcsid[] =3D "@(#)Id: fil.c,v 2.243.2.57 2005/03/28 10:47= :50 darrenr Exp"; #endif =20 Index: sys/contrib/ipfilter/netinet/ip_auth.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/sys/contrib/ipfilter/netinet/ip_auth.c,v retrieving revision 1.39 diff -u -r1.39 ip_auth.c --- sys/contrib/ipfilter/netinet/ip_auth.c 25 Apr 2005 18:43:13 -0000 1.39 +++ sys/contrib/ipfilter/netinet/ip_auth.c 26 Apr 2005 15:40:58 -0000 @@ -119,7 +119,7 @@ /* END OF INCLUDES */ =20 #if !defined(lint) -static const char rcsid[] =3D "@(#)$FreeBSD: src/sys/contrib/ipfilter/neti= net/ip_auth.c,v 1.39 2005/04/25 18:43:13 darrenr Exp $"; +static const char fbsdid[] =3D "@(#)$FreeBSD: src/sys/contrib/ipfilter/net= inet/ip_auth.c,v 1.39 2005/04/25 18:43:13 darrenr Exp $"; static const char rcsid[] =3D "@(#)Id: ip_auth.c,v 2.73.2.3 2004/08/26 11:= 25:21 darrenr Exp"; #endif =20 Index: sys/contrib/ipfilter/netinet/ip_frag.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/sys/contrib/ipfilter/netinet/ip_frag.c,v retrieving revision 1.27 diff -u -r1.27 ip_frag.c --- sys/contrib/ipfilter/netinet/ip_frag.c 25 Apr 2005 18:43:14 -0000 1.27 +++ sys/contrib/ipfilter/netinet/ip_frag.c 26 Apr 2005 15:41:01 -0000 @@ -102,7 +102,7 @@ =20 #if !defined(lint) static const char sccsid[] =3D "@(#)ip_frag.c 1.11 3/24/96 (C) 1993-2000 D= arren Reed"; -static const char rcsid[] =3D "@(#)$FreeBSD: src/sys/contrib/ipfilter/neti= net/ip_frag.c,v 1.27 2005/04/25 18:43:14 darrenr Exp $"; +static const char fbsdid[] =3D "@(#)$FreeBSD: src/sys/contrib/ipfilter/net= inet/ip_frag.c,v 1.27 2005/04/25 18:43:14 darrenr Exp $"; static const char rcsid[] =3D "@(#)Id: ip_frag.c,v 2.77 2004/01/27 00:24:5= 4 darrenr Exp"; #endif =20 Index: sys/contrib/ipfilter/netinet/ip_nat.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/sys/contrib/ipfilter/netinet/ip_nat.c,v retrieving revision 1.38 diff -u -r1.38 ip_nat.c --- sys/contrib/ipfilter/netinet/ip_nat.c 25 Apr 2005 18:43:14 -0000 1.38 +++ sys/contrib/ipfilter/netinet/ip_nat.c 26 Apr 2005 15:41:59 -0000 @@ -107,7 +107,7 @@ =20 #if !defined(lint) static const char sccsid[] =3D "@(#)ip_nat.c 1.11 6/5/96 (C) 1995 Darren R= eed"; -static const char rcsid[] =3D "@(#)$FreeBSD: src/sys/contrib/ipfilter/neti= net/ip_nat.c,v 1.38 2005/04/25 18:43:14 darrenr Exp $"; +static const char fbsdid[] =3D "@(#)$FreeBSD: src/sys/contrib/ipfilter/net= inet/ip_nat.c,v 1.38 2005/04/25 18:43:14 darrenr Exp $"; static const char rcsid[] =3D "@(#)Id: ip_nat.c,v 2.195.2.38 2005/03/28 11= :09:54 darrenr Exp"; #endif =20 --cz6wLo+OExbGG7q/-- --8bBEDOJVaa9YlTAt Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFCbmSYqRfpzJluFF4RAoxtAJoD8eFq0GCOhYbXVJvrLQbmn9T11ACeKt90 7CpzAGbDeea0KrKav43fwYA= =uQX4 -----END PGP SIGNATURE----- --8bBEDOJVaa9YlTAt-- From owner-freebsd-current@FreeBSD.ORG Tue Apr 26 15:56: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 8035A16A4CE; Tue, 26 Apr 2005 15:56:54 +0000 (GMT) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6325243D53; Tue, 26 Apr 2005 15:56:53 +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 j3QG0i86060389; Tue, 26 Apr 2005 19:00:44 +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 84193-14; Tue, 26 Apr 2005 18:56:51 +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 j3QG0h7M060386 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 Apr 2005 19:00:44 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.13.3/8.13.3) id j3QFv0C6095518; Tue, 26 Apr 2005 18:57:00 +0300 (EEST) (envelope-from ru) Date: Tue, 26 Apr 2005 18:57:00 +0300 From: Ruslan Ermilov To: Giorgos Keramidas Message-ID: <20050426155700.GG94543@ip.net.ua> References: <20050425190922.GA78625@hub.freebsd.org> <20050426154754.GA83321@orion.daedalusnetworks.priv> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="e5bfZ/T2xnjpUIbw" Content-Disposition: inline In-Reply-To: <20050426154754.GA83321@orion.daedalusnetworks.priv> User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new at ip.net.ua cc: Darren Reed cc: freebsd-current@freebsd.org cc: Claus Guttesen Subject: Re: ipfilter 4.1.8 imported into 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, 26 Apr 2005 15:56:54 -0000 --e5bfZ/T2xnjpUIbw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Apr 26, 2005 at 06:47:54PM +0300, Giorgos Keramidas wrote: > On 2005-04-26 15:34, Claus Guttesen wrote: > > > I've just finished importing IPFilter 4.1.8 into FreeBSD-current, in = time > > > for making 6.0. I'd appreciate any feedback about whether the change= s work > > > for you, break builds, etc. > > > > /usr/src/sbin/ipf/libipf/../../../contrib/ipfilter/lib/ipf_dotuning.c:4= :17: > > ipl.h: No such file or directory > > mkdep: compile failed > > *** Error code 1 >=20 > I have a local fix for this, which I'm testing with buildworld cycles > until I get one that completes without problems. Hang on, please :-) >=20 This particular one Darren has fixed already. You need to catch up to your email. :-) Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --e5bfZ/T2xnjpUIbw Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFCbmTMqRfpzJluFF4RAmjQAKCP3k1Iy7v8/2uEhymrN/k3pjtdAgCfRRAr 8nRFZJoygnWiTk/N79VDt4I= =rcSQ -----END PGP SIGNATURE----- --e5bfZ/T2xnjpUIbw-- From owner-freebsd-current@FreeBSD.ORG Tue Apr 26 16:22: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 48BC716A4CE; Tue, 26 Apr 2005 16:22:47 +0000 (GMT) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id B6D0043D41; Tue, 26 Apr 2005 16:22:46 +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 j3QGMkGe061826; Tue, 26 Apr 2005 12:22:46 -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 j3QGMkS1062547; Tue, 26 Apr 2005 12:22:46 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id CF9A67306E; Tue, 26 Apr 2005 12:22:45 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050426162245.CF9A67306E@freebsd-current.sentex.ca> Date: Tue, 26 Apr 2005 12:22:45 -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 alpha/alpha 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, 26 Apr 2005 16:22:47 -0000 TB --- 2005-04-26 16:15:00 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-04-26 16:15:00 - starting CURRENT tinderbox run for alpha/alpha TB --- 2005-04-26 16:15:00 - checking out the source tree TB --- 2005-04-26 16:15:00 - cd /home/tinderbox/CURRENT/alpha/alpha TB --- 2005-04-26 16:15:00 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-04-26 16:21:48 - building world (CFLAGS=-O2 -pipe) TB --- 2005-04-26 16:21:48 - cd /home/tinderbox/CURRENT/alpha/alpha/src TB --- 2005-04-26 16:21:48 - /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 [...] ===> rescue/rescue/ipf/ipnat (clean) rm -f ipnat_y.c ipnat_y.h ipnat_l.c ipnat_l.h y.tab.c y.tab.h ipnat ipnat.o ipnat_y.o ipnat_l.o ipnat.8.gz ipnat.4.gz ipnat.5.gz ipnat.8.cat.gz ipnat.4.cat.gz ipnat.5.cat.gz ===> rescue/rescue/ipf/ippool (clean) rm -f ippool_y.c ippool_y.h ippool_l.c ippool_l.h y.tab.c y.tab.h ippool ippool_y.o ippool_l.o kmem.o ippool.o ippool.5.gz ippool.8.gz ippool.5.cat.gz ippool.8.cat.gz ===> rescue/rescue/ipf/ipresend (clean) rm -f y.tab.c y.tab.h ipresend ipresend.o ip.o resend.o sbpf.o sock.o 44arp.o ipresend.1.gz ipresend.1.cat.gz cd /tinderbox/CURRENT/alpha/alpha/src/rescue/rescue/../../sbin/ipfs && MAKEOBJDIRPREFIX=/home/tinderbox/CURRENT/alpha/alpha/obj/alpha/tinderbox/CURRENT/alpha/alpha/src/rescue/rescue /home/tinderbox/CURRENT/alpha/alpha/obj/tinderbox/CURRENT/alpha/alpha/src/make.i386/make DIRPRFX=rescue/rescue/ipfs/ clean cd: can't cd to /tinderbox/CURRENT/alpha/alpha/src/rescue/rescue/../../sbin/ipfs *** Error code 2 Stop in /tinderbox/CURRENT/alpha/alpha/src/rescue/rescue. *** Error code 1 Stop in /tinderbox/CURRENT/alpha/alpha/src/rescue. *** Error code 1 Stop in /tinderbox/CURRENT/alpha/alpha/src. *** Error code 1 Stop in /tinderbox/CURRENT/alpha/alpha/src. *** Error code 1 Stop in /tinderbox/CURRENT/alpha/alpha/src. TB --- 2005-04-26 16:22:45 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-04-26 16:22:45 - ERROR: failed to build world TB --- 2005-04-26 16:22:45 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Tue Apr 26 16:26: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 99E7016A4CE; Tue, 26 Apr 2005 16:26:12 +0000 (GMT) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1387B43D5F; Tue, 26 Apr 2005 16:26:12 +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 j3QGQBw8062047; Tue, 26 Apr 2005 12:26: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 j3QGQBvJ077960; Tue, 26 Apr 2005 12:26:11 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 75D267306E; Tue, 26 Apr 2005 12:26:11 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050426162611.75D267306E@freebsd-current.sentex.ca> Date: Tue, 26 Apr 2005 12:26:11 -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 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, 26 Apr 2005 16:26:12 -0000 TB --- 2005-04-26 16:22:46 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-04-26 16:22:46 - starting CURRENT tinderbox run for amd64/amd64 TB --- 2005-04-26 16:22:46 - checking out the source tree TB --- 2005-04-26 16:22:46 - cd /home/tinderbox/CURRENT/amd64/amd64 TB --- 2005-04-26 16:22:46 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-04-26 16:25:13 - building world (CFLAGS=-O2 -pipe) TB --- 2005-04-26 16:25:13 - cd /home/tinderbox/CURRENT/amd64/amd64/src TB --- 2005-04-26 16:25:13 - /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 [...] ===> rescue/rescue/ipf/ipnat (clean) rm -f ipnat_y.c ipnat_y.h ipnat_l.c ipnat_l.h y.tab.c y.tab.h ipnat ipnat.o ipnat_y.o ipnat_l.o ipnat.8.gz ipnat.4.gz ipnat.5.gz ipnat.8.cat.gz ipnat.4.cat.gz ipnat.5.cat.gz ===> rescue/rescue/ipf/ippool (clean) rm -f ippool_y.c ippool_y.h ippool_l.c ippool_l.h y.tab.c y.tab.h ippool ippool_y.o ippool_l.o kmem.o ippool.o ippool.5.gz ippool.8.gz ippool.5.cat.gz ippool.8.cat.gz ===> rescue/rescue/ipf/ipresend (clean) rm -f y.tab.c y.tab.h ipresend ipresend.o ip.o resend.o sbpf.o sock.o 44arp.o ipresend.1.gz ipresend.1.cat.gz cd /tinderbox/CURRENT/amd64/amd64/src/rescue/rescue/../../sbin/ipfs && MAKEOBJDIRPREFIX=/home/tinderbox/CURRENT/amd64/amd64/obj/amd64/tinderbox/CURRENT/amd64/amd64/src/rescue/rescue /home/tinderbox/CURRENT/amd64/amd64/obj/tinderbox/CURRENT/amd64/amd64/src/make.i386/make DIRPRFX=rescue/rescue/ipfs/ clean cd: can't cd to /tinderbox/CURRENT/amd64/amd64/src/rescue/rescue/../../sbin/ipfs *** Error code 2 Stop in /tinderbox/CURRENT/amd64/amd64/src/rescue/rescue. *** Error code 1 Stop in /tinderbox/CURRENT/amd64/amd64/src/rescue. *** 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-26 16:26:11 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-04-26 16:26:11 - ERROR: failed to build world TB --- 2005-04-26 16:26:11 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Tue Apr 26 16:31: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 5ACFD16A4CE; Tue, 26 Apr 2005 16:31:34 +0000 (GMT) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id CB88143D1F; Tue, 26 Apr 2005 16:31: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 j3QGVXq6062400; Tue, 26 Apr 2005 12:31: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 j3QGW39G098900; Tue, 26 Apr 2005 12:32:03 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 24DB37306E; Tue, 26 Apr 2005 12:31:33 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050426163133.24DB37306E@freebsd-current.sentex.ca> Date: Tue, 26 Apr 2005 12:31:33 -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: Tue, 26 Apr 2005 16:31:34 -0000 TB --- 2005-04-26 16:26:11 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-04-26 16:26:11 - starting CURRENT tinderbox run for i386/i386 TB --- 2005-04-26 16:26:11 - checking out the source tree TB --- 2005-04-26 16:26:11 - cd /home/tinderbox/CURRENT/i386/i386 TB --- 2005-04-26 16:26:11 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-04-26 16:30:36 - building world (CFLAGS=-O2 -pipe) TB --- 2005-04-26 16:30:36 - cd /home/tinderbox/CURRENT/i386/i386/src TB --- 2005-04-26 16:30:36 - /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 [...] ===> rescue/rescue/ipf/ipnat (clean) rm -f ipnat_y.c ipnat_y.h ipnat_l.c ipnat_l.h y.tab.c y.tab.h ipnat ipnat.o ipnat_y.o ipnat_l.o ipnat.8.gz ipnat.4.gz ipnat.5.gz ipnat.8.cat.gz ipnat.4.cat.gz ipnat.5.cat.gz ===> rescue/rescue/ipf/ippool (clean) rm -f ippool_y.c ippool_y.h ippool_l.c ippool_l.h y.tab.c y.tab.h ippool ippool_y.o ippool_l.o kmem.o ippool.o ippool.5.gz ippool.8.gz ippool.5.cat.gz ippool.8.cat.gz ===> rescue/rescue/ipf/ipresend (clean) rm -f y.tab.c y.tab.h ipresend ipresend.o ip.o resend.o sbpf.o sock.o 44arp.o ipresend.1.gz ipresend.1.cat.gz cd /tinderbox/CURRENT/i386/i386/src/rescue/rescue/../../sbin/ipfs && MAKEOBJDIRPREFIX=/home/tinderbox/CURRENT/i386/i386/obj/tinderbox/CURRENT/i386/i386/src/rescue/rescue /home/tinderbox/CURRENT/i386/i386/obj/tinderbox/CURRENT/i386/i386/src/make.i386/make DIRPRFX=rescue/rescue/ipfs/ clean cd: can't cd to /tinderbox/CURRENT/i386/i386/src/rescue/rescue/../../sbin/ipfs *** Error code 2 Stop in /tinderbox/CURRENT/i386/i386/src/rescue/rescue. *** Error code 1 Stop in /tinderbox/CURRENT/i386/i386/src/rescue. *** 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-26 16:31:33 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-04-26 16:31:33 - ERROR: failed to build world TB --- 2005-04-26 16:31:33 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Tue Apr 26 16:35: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 C256D16A4CE; Tue, 26 Apr 2005 16:35:35 +0000 (GMT) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 40E2C43D64; Tue, 26 Apr 2005 16:35:35 +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 j3QGZYpL062691; Tue, 26 Apr 2005 12:35:34 -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 j3QGZYpb022303; Tue, 26 Apr 2005 12:35:34 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 7775E7306E; Tue, 26 Apr 2005 12:35:34 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050426163534.7775E7306E@freebsd-current.sentex.ca> Date: Tue, 26 Apr 2005 12:35:34 -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 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: Tue, 26 Apr 2005 16:35:35 -0000 TB --- 2005-04-26 16:31:33 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-04-26 16:31:33 - starting CURRENT tinderbox run for i386/pc98 TB --- 2005-04-26 16:31:33 - checking out the source tree TB --- 2005-04-26 16:31:33 - cd /home/tinderbox/CURRENT/i386/pc98 TB --- 2005-04-26 16:31:33 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-04-26 16:34:36 - building world (CFLAGS=-O2 -pipe) TB --- 2005-04-26 16:34:36 - cd /home/tinderbox/CURRENT/i386/pc98/src TB --- 2005-04-26 16:34:36 - /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 [...] ===> rescue/rescue/ipf/ipnat (clean) rm -f ipnat_y.c ipnat_y.h ipnat_l.c ipnat_l.h y.tab.c y.tab.h ipnat ipnat.o ipnat_y.o ipnat_l.o ipnat.8.gz ipnat.4.gz ipnat.5.gz ipnat.8.cat.gz ipnat.4.cat.gz ipnat.5.cat.gz ===> rescue/rescue/ipf/ippool (clean) rm -f ippool_y.c ippool_y.h ippool_l.c ippool_l.h y.tab.c y.tab.h ippool ippool_y.o ippool_l.o kmem.o ippool.o ippool.5.gz ippool.8.gz ippool.5.cat.gz ippool.8.cat.gz ===> rescue/rescue/ipf/ipresend (clean) rm -f y.tab.c y.tab.h ipresend ipresend.o ip.o resend.o sbpf.o sock.o 44arp.o ipresend.1.gz ipresend.1.cat.gz cd /tinderbox/CURRENT/i386/pc98/src/rescue/rescue/../../sbin/ipfs && MAKEOBJDIRPREFIX=/home/tinderbox/CURRENT/i386/pc98/obj/pc98/tinderbox/CURRENT/i386/pc98/src/rescue/rescue /home/tinderbox/CURRENT/i386/pc98/obj/tinderbox/CURRENT/i386/pc98/src/make.i386/make DIRPRFX=rescue/rescue/ipfs/ clean cd: can't cd to /tinderbox/CURRENT/i386/pc98/src/rescue/rescue/../../sbin/ipfs *** Error code 2 Stop in /tinderbox/CURRENT/i386/pc98/src/rescue/rescue. *** Error code 1 Stop in /tinderbox/CURRENT/i386/pc98/src/rescue. *** 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-26 16:35:34 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-04-26 16:35:34 - ERROR: failed to build world TB --- 2005-04-26 16:35:34 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Tue Apr 26 16:40: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 0658B16A4CF; Tue, 26 Apr 2005 16:40:12 +0000 (GMT) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 72D5643D48; Tue, 26 Apr 2005 16:40:11 +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 j3QGeBR2054893; Tue, 26 Apr 2005 12:40:11 -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 j3QGeeju003218; Tue, 26 Apr 2005 12:40:40 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 06CF87306E; Tue, 26 Apr 2005 12:40:11 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050426164011.06CF87306E@freebsd-current.sentex.ca> Date: Tue, 26 Apr 2005 12:40:11 -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 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, 26 Apr 2005 16:40:12 -0000 TB --- 2005-04-26 16:35:34 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-04-26 16:35:34 - starting CURRENT tinderbox run for ia64/ia64 TB --- 2005-04-26 16:35:34 - checking out the source tree TB --- 2005-04-26 16:35:34 - cd /home/tinderbox/CURRENT/ia64/ia64 TB --- 2005-04-26 16:35:34 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-04-26 16:39:14 - building world (CFLAGS=-O2 -pipe) TB --- 2005-04-26 16:39:14 - cd /home/tinderbox/CURRENT/ia64/ia64/src TB --- 2005-04-26 16:39:14 - /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 [...] ===> rescue/rescue/ipf/ipnat (clean) rm -f ipnat_y.c ipnat_y.h ipnat_l.c ipnat_l.h y.tab.c y.tab.h ipnat ipnat.o ipnat_y.o ipnat_l.o ipnat.8.gz ipnat.4.gz ipnat.5.gz ipnat.8.cat.gz ipnat.4.cat.gz ipnat.5.cat.gz ===> rescue/rescue/ipf/ippool (clean) rm -f ippool_y.c ippool_y.h ippool_l.c ippool_l.h y.tab.c y.tab.h ippool ippool_y.o ippool_l.o kmem.o ippool.o ippool.5.gz ippool.8.gz ippool.5.cat.gz ippool.8.cat.gz ===> rescue/rescue/ipf/ipresend (clean) rm -f y.tab.c y.tab.h ipresend ipresend.o ip.o resend.o sbpf.o sock.o 44arp.o ipresend.1.gz ipresend.1.cat.gz cd /tinderbox/CURRENT/ia64/ia64/src/rescue/rescue/../../sbin/ipfs && MAKEOBJDIRPREFIX=/home/tinderbox/CURRENT/ia64/ia64/obj/ia64/tinderbox/CURRENT/ia64/ia64/src/rescue/rescue /home/tinderbox/CURRENT/ia64/ia64/obj/tinderbox/CURRENT/ia64/ia64/src/make.i386/make DIRPRFX=rescue/rescue/ipfs/ clean cd: can't cd to /tinderbox/CURRENT/ia64/ia64/src/rescue/rescue/../../sbin/ipfs *** Error code 2 Stop in /tinderbox/CURRENT/ia64/ia64/src/rescue/rescue. *** Error code 1 Stop in /tinderbox/CURRENT/ia64/ia64/src/rescue. *** Error code 1 Stop in /tinderbox/CURRENT/ia64/ia64/src. *** Error code 1 Stop in /tinderbox/CURRENT/ia64/ia64/src. *** Error code 1 Stop in /tinderbox/CURRENT/ia64/ia64/src. TB --- 2005-04-26 16:40:10 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-04-26 16:40:10 - ERROR: failed to build world TB --- 2005-04-26 16:40:10 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Tue Apr 26 16:44: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 9D87F16A4CE; Tue, 26 Apr 2005 16:44:52 +0000 (GMT) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1548243D39; Tue, 26 Apr 2005 16:44:52 +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 j3QGip4r063313; Tue, 26 Apr 2005 12:44:51 -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 j3QGipgF064735; Tue, 26 Apr 2005 12:44:51 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 3F9DB7306E; Tue, 26 Apr 2005 12:44:51 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050426164451.3F9DB7306E@freebsd-current.sentex.ca> Date: Tue, 26 Apr 2005 12:44:51 -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: Tue, 26 Apr 2005 16:44:52 -0000 TB --- 2005-04-26 16:40:11 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-04-26 16:40:11 - starting CURRENT tinderbox run for powerpc/powerpc TB --- 2005-04-26 16:40:11 - checking out the source tree TB --- 2005-04-26 16:40:11 - cd /home/tinderbox/CURRENT/powerpc/powerpc TB --- 2005-04-26 16:40:11 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-04-26 16:43:46 - building world (CFLAGS=-O2 -pipe) TB --- 2005-04-26 16:43:46 - cd /home/tinderbox/CURRENT/powerpc/powerpc/src TB --- 2005-04-26 16:43:46 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree [...] ===> rescue/rescue/ipf/ipnat (clean) rm -f ipnat_y.c ipnat_y.h ipnat_l.c ipnat_l.h y.tab.c y.tab.h ipnat ipnat.o ipnat_y.o ipnat_l.o ipnat.8.gz ipnat.4.gz ipnat.5.gz ipnat.8.cat.gz ipnat.4.cat.gz ipnat.5.cat.gz ===> rescue/rescue/ipf/ippool (clean) rm -f ippool_y.c ippool_y.h ippool_l.c ippool_l.h y.tab.c y.tab.h ippool ippool_y.o ippool_l.o kmem.o ippool.o ippool.5.gz ippool.8.gz ippool.5.cat.gz ippool.8.cat.gz ===> rescue/rescue/ipf/ipresend (clean) rm -f y.tab.c y.tab.h ipresend ipresend.o ip.o resend.o sbpf.o sock.o 44arp.o ipresend.1.gz ipresend.1.cat.gz cd /tinderbox/CURRENT/powerpc/powerpc/src/rescue/rescue/../../sbin/ipfs && MAKEOBJDIRPREFIX=/home/tinderbox/CURRENT/powerpc/powerpc/obj/powerpc/tinderbox/CURRENT/powerpc/powerpc/src/rescue/rescue /home/tinderbox/CURRENT/powerpc/powerpc/obj/tinderbox/CURRENT/powerpc/powerpc/src/make.i386/make DIRPRFX=rescue/rescue/ipfs/ clean cd: can't cd to /tinderbox/CURRENT/powerpc/powerpc/src/rescue/rescue/../../sbin/ipfs *** Error code 2 Stop in /tinderbox/CURRENT/powerpc/powerpc/src/rescue/rescue. *** Error code 1 Stop in /tinderbox/CURRENT/powerpc/powerpc/src/rescue. *** Error code 1 Stop in /tinderbox/CURRENT/powerpc/powerpc/src. *** Error code 1 Stop in /tinderbox/CURRENT/powerpc/powerpc/src. *** Error code 1 Stop in /tinderbox/CURRENT/powerpc/powerpc/src. TB --- 2005-04-26 16:44:51 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-04-26 16:44:51 - ERROR: failed to build world TB --- 2005-04-26 16:44:51 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Tue Apr 26 16:49: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 13AFA16A4D2; Tue, 26 Apr 2005 16:49:26 +0000 (GMT) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7EB5543D4C; Tue, 26 Apr 2005 16:49:25 +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 j3QGnPvn055469; Tue, 26 Apr 2005 12:49:25 -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 j3QGns72007669; Tue, 26 Apr 2005 12:49:54 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id F2D8A7306E; Tue, 26 Apr 2005 12:49:24 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050426164924.F2D8A7306E@freebsd-current.sentex.ca> Date: Tue, 26 Apr 2005 12:49:24 -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 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: Tue, 26 Apr 2005 16:49:26 -0000 TB --- 2005-04-26 16:44:51 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-04-26 16:44:51 - starting CURRENT tinderbox run for sparc64/sparc64 TB --- 2005-04-26 16:44:51 - checking out the source tree TB --- 2005-04-26 16:44:51 - cd /home/tinderbox/CURRENT/sparc64/sparc64 TB --- 2005-04-26 16:44:51 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-04-26 16:48:26 - building world (CFLAGS=-O2 -pipe) TB --- 2005-04-26 16:48:26 - cd /home/tinderbox/CURRENT/sparc64/sparc64/src TB --- 2005-04-26 16:48: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 [...] ===> rescue/rescue/ipf/ipnat (clean) rm -f ipnat_y.c ipnat_y.h ipnat_l.c ipnat_l.h y.tab.c y.tab.h ipnat ipnat.o ipnat_y.o ipnat_l.o ipnat.8.gz ipnat.4.gz ipnat.5.gz ipnat.8.cat.gz ipnat.4.cat.gz ipnat.5.cat.gz ===> rescue/rescue/ipf/ippool (clean) rm -f ippool_y.c ippool_y.h ippool_l.c ippool_l.h y.tab.c y.tab.h ippool ippool_y.o ippool_l.o kmem.o ippool.o ippool.5.gz ippool.8.gz ippool.5.cat.gz ippool.8.cat.gz ===> rescue/rescue/ipf/ipresend (clean) rm -f y.tab.c y.tab.h ipresend ipresend.o ip.o resend.o sbpf.o sock.o 44arp.o ipresend.1.gz ipresend.1.cat.gz cd /tinderbox/CURRENT/sparc64/sparc64/src/rescue/rescue/../../sbin/ipfs && MAKEOBJDIRPREFIX=/home/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/tinderbox/CURRENT/sparc64/sparc64/src/rescue/rescue /home/tinderbox/CURRENT/sparc64/sparc64/obj/tinderbox/CURRENT/sparc64/sparc64/src/make.i386/make DIRPRFX=rescue/rescue/ipfs/ clean cd: can't cd to /tinderbox/CURRENT/sparc64/sparc64/src/rescue/rescue/../../sbin/ipfs *** Error code 2 Stop in /tinderbox/CURRENT/sparc64/sparc64/src/rescue/rescue. *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/src/rescue. *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/src. *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/src. *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/src. TB --- 2005-04-26 16:49:24 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-04-26 16:49:24 - ERROR: failed to build world TB --- 2005-04-26 16:49:24 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Tue Apr 26 18:10: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 6B5F216A4CF for ; Tue, 26 Apr 2005 18:10:52 +0000 (GMT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 650C343D2D for ; Tue, 26 Apr 2005 18:10:51 +0000 (GMT) (envelope-from Emanuel.strobl@gmx.net) Received: (qmail invoked by alias); 26 Apr 2005 18:10:50 -0000 Received: from flb.schmalzbauer.de (EHLO cale.flintsbach.schmalzbauer.de) [62.245.232.135] by mail.gmx.net (mp004) with SMTP; 26 Apr 2005 20:10:50 +0200 X-Authenticated: #301138 From: Emanuel Strobl To: freebsd-questions@freebsd.org, freebsd-current@freebsd.org Date: Tue, 26 Apr 2005 20:10:41 +0200 User-Agent: KMail/1.8 X-Birthday: Oct. 6th 1972 X-CelPhone: +49 (0) 173 9967781 X-Tel: +49 (0) 89 18947781 X-Country: Germany X-Address: Munich, 80686 X-OS: FreeBSD MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3677596.j3orVY53Xm"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200504262010.49509@harrymail> X-Y-GMX-Trusted: 0 Subject: groff alternative? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 26 Apr 2005 18:10:52 -0000 --nextPart3677596.j3orVY53Xm Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hello, I'm using NO_CXX in my make.conf to strip down the base system to ~50MB=20 including man pages. The only problem is that groff is missing if I don't=20 build c++, and even if I build groff itself and the needed libstdc++ it cos= ts=20 me about 10MB. If I just skip NO_CXX it's only 500k more, so I moved my=20 patches to /dev/null. Now I wrote a port for GNU/groff, but this also consumes 9974k by default a= nd=20 I don't want to include patches into that port to strip down groff, if that= =20 was possible at all. Does anybody know any alternative for the groff part to view man pages simp= ly=20 with the man command? It's horrible that the filter needs more space than a= ll=20 the manpages itself! And of course, even if I decide to leave system man pages outside the flash= =20 card I still may want to read man pages of installed packages (which is=20 another mountpoint on my installation, so there may be no space limit,=20 depending on the card and additional drives) Thanks, =2DHarry --nextPart3677596.j3orVY53Xm Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQBCboQpBylq0S4AzzwRAv/OAJ9IaKsqhKfHdN0ppIh/6woMb07stQCePtag 5OsmtfYrKPaBtGKRKTX6cbo= =mOup -----END PGP SIGNATURE----- --nextPart3677596.j3orVY53Xm-- From owner-freebsd-current@FreeBSD.ORG Tue Apr 26 18:11: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 29C7416A4CE for ; Tue, 26 Apr 2005 18:11:01 +0000 (GMT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id D8C7743D1D for ; Tue, 26 Apr 2005 18:11:00 +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 j3QIB0bd023201; Tue, 26 Apr 2005 11:11:00 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id j3QIB02G023200; Tue, 26 Apr 2005 11:11:00 -0700 Date: Tue, 26 Apr 2005 11:11:00 -0700 From: Brooks Davis To: Randy Bush Message-ID: <20050426181100.GB5788@odin.ac.hmc.edu> References: <17001.9557.627987.505930@roam.psg.com> <17001.16520.774703.612151@roam.psg.com> <20050422112246.A70611@xorpc.icir.org> <17001.16764.512962.411616@roam.psg.com> <20050422115518.C70611@xorpc.icir.org> <20050422214418.GB11806@odin.ac.hmc.edu> <20050425224646.GA6848@odin.ac.hmc.edu> <17005.64501.816490.740201@roam.psg.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="jho1yZJdad60DJr+" Content-Disposition: inline In-Reply-To: <17005.64501.816490.740201@roam.psg.com> 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: Luigi Rizzo cc: FreeBSD Current Subject: Re: significant increase in ipfw pullup failed X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 26 Apr 2005 18:11:01 -0000 --jho1yZJdad60DJr+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Apr 25, 2005 at 10:29:41PM -1000, Randy Bush wrote: > patch seems to have fixed it! Thanks for the report. I've committed the patch. -- 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 --jho1yZJdad60DJr+ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFCboQzXY6L6fI4GtQRAkX/AKCoc9CuUjrV9YquXidoz+jvTSvXSwCgqD9W qnzbqN33oJr441pAM9pv548= =HxKg -----END PGP SIGNATURE----- --jho1yZJdad60DJr+-- From owner-freebsd-current@FreeBSD.ORG Tue Apr 26 18: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 3D14F16A4CE; Tue, 26 Apr 2005 18:26:32 +0000 (GMT) Received: from saltmine.radix.net (saltmine.radix.net [207.192.128.40]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9516843D5E; Tue, 26 Apr 2005 18:26:31 +0000 (GMT) (envelope-from dickey@saltmine.radix.net) Received: from saltmine.radix.net (localhost [127.0.0.1]) by saltmine.radix.net (8.12.2/8.12.2) with ESMTP id j3QIQTI4017470; Tue, 26 Apr 2005 14:26:30 -0400 (EDT) Received: (from dickey@localhost) by saltmine.radix.net (8.12.2/8.12.2/Submit) id j3QIQThY017469; Tue, 26 Apr 2005 14:26:29 -0400 (EDT) Date: Tue, 26 Apr 2005 14:26:29 -0400 From: Thomas Dickey To: Emanuel Strobl Message-ID: <20050426182629.GA16663@saltmine.radix.net> References: <200504262010.49509@harrymail> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="SLDf9lqlvOQaIe6s" Content-Disposition: inline In-Reply-To: <200504262010.49509@harrymail> User-Agent: Mutt/1.3.27i cc: freebsd-current@freebsd.org cc: freebsd-questions@freebsd.org Subject: Re: groff alternative? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 26 Apr 2005 18:26:32 -0000 --SLDf9lqlvOQaIe6s Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Apr 26, 2005 at 08:10:41PM +0200, Emanuel Strobl wrote: >=20 > Does anybody know any alternative for the groff part to view man pages si= mply=20 > with the man command? It's horrible that the filter needs more space than= all=20 > the manpages itself! perhaps "cawf" --=20 Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net --SLDf9lqlvOQaIe6s Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (SunOS) Comment: For info see http://www.gnupg.org iD8DBQFCbofGtIqByHxlDocRAsGIAJ9+ZRZ/pWKuvYd7KO4DS3ADGGw5agCaAgb6 GeysutGnH32CgXBecNZ1mV4= =Xi2s -----END PGP SIGNATURE----- --SLDf9lqlvOQaIe6s-- From owner-freebsd-current@FreeBSD.ORG Tue Apr 26 18:43: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 D049316A4CE; Tue, 26 Apr 2005 18:43:52 +0000 (GMT) Received: from mx-out-04.forthnet.gr (mx-out.forthnet.gr [193.92.150.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7F41743D53; Tue, 26 Apr 2005 18:43:49 +0000 (GMT) (envelope-from dds@aueb.gr) Received: from mx-av-03.forthnet.gr (mx-av.forthnet.gr [193.92.150.27]) j3QIhmTi030123; Tue, 26 Apr 2005 21:43:48 +0300 Received: from mx-as-02.forthnet.gr (mx-as.forthnet.gr [193.92.150.226]) j3QIhmg2022724; Tue, 26 Apr 2005 21:43:48 +0300 Received: from forthnet.gr (athmta05.forthnet.gr [193.92.150.26]) j3QIhmjv008112; Tue, 26 Apr 2005 21:43:48 +0300 Received: from [192.168.136.16] (dds.ath.forthnet.gr [213.16.179.162]) by forthnet.gr (8.12.11/8.12.11) with ESMTP id j3QIhkmH015225; Tue, 26 Apr 2005 21:43:47 +0300 Message-ID: <426E8BE6.7090800@aueb.gr> Date: Tue, 26 Apr 2005 22:43:50 +0400 From: Diomidis Spinellis User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en, el, de MIME-Version: 1.0 To: Emanuel Strobl References: <200504262010.49509@harrymail> In-Reply-To: <200504262010.49509@harrymail> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-current@FreeBSD.ORG cc: freebsd-questions@FreeBSD.ORG Subject: Re: groff alternative? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 26 Apr 2005 18:43:52 -0000 Emanuel Strobl wrote: > I'm using NO_CXX in my make.conf to strip down the base system to ~50MB > including man pages. The only problem is that groff is missing if I don't > build c++, and even if I build groff itself and the needed libstdc++ it costs > me about 10MB. If I just skip NO_CXX it's only 500k more, so I moved my > patches to /dev/null. > Does anybody know any alternative for the groff part to view man pages simply > with the man command? It's horrible that the filter needs more space than all > the manpages itself! Have you considered preformatting the manual pages on the development system, and copying over the pages into /usr/share/man/cat* of the shrinked-down system? > And of course, even if I decide to leave system man pages outside the flash > card I still may want to read man pages of installed packages (which is > another mountpoint on my installation, so there may be no space limit, > depending on the card and additional drives) Again, it appears your shrinked-down system has access to a more powerful machine. You could modify man to run groff on the remote machine. -- Diomidis - dds@ - http://www.spinellis.gr From owner-freebsd-current@FreeBSD.ORG Tue Apr 26 18:47: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 B247D16A4CE for ; Tue, 26 Apr 2005 18:47:11 +0000 (GMT) Received: from mail28.sea5.speakeasy.net (mail28.sea5.speakeasy.net [69.17.117.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id 70F6243D49 for ; Tue, 26 Apr 2005 18:47:11 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 4441 invoked from network); 26 Apr 2005 18:47:11 -0000 Received: from server.baldwin.cx ([216.27.160.63]) (envelope-sender )AES256-SHA encrypted SMTP for ; 26 Apr 2005 18:47:10 -0000 Received: from roboboy.corp.weather.com (gw1.twc.weather.com [216.133.140.1]) (authenticated bits=0) by server.baldwin.cx (8.13.1/8.13.1) with ESMTP id j3QIl4W1034470; Tue, 26 Apr 2005 14:47:05 -0400 (EDT) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: Divacky Roman Date: Tue, 26 Apr 2005 14:37:33 -0400 User-Agent: KMail/1.8 References: <20050418072639.GA4635@stud.fit.vutbr.cz> In-Reply-To: <20050418072639.GA4635@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: <200504261437.34435.jhb@FreeBSD.org> X-Spam-Status: No, score=-102.8 required=4.2 tests=ALL_TRUSTED, USER_IN_WHITELIST 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, 26 Apr 2005 18:47:11 -0000 On Monday 18 April 2005 03:26 am, Divacky Roman wrote: > hi, I sent you an-email about this... can you pls advice me? (where to > change that triggering).. I tried to put some debuging printfs into > /sys/amd64/amd64/intr_machdep.c:intr_config_inter() but nothing was printed > on boot, so I am lost ;( Hmm, that is the right place. I think it only did this in the ACPI + APIC case however. > thnx for info > > 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) > > > > -- > > John Baldwin <>< http://www.FreeBSD.org/~jhb/ > > "Power Users Use the Power to Serve" = http://www.FreeBSD.org -- 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 26 18:47: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 D2B8A16A544 for ; Tue, 26 Apr 2005 18:47:17 +0000 (GMT) Received: from mail21.sea5.speakeasy.net (mail21.sea5.speakeasy.net [69.17.117.23]) by mx1.FreeBSD.org (Postfix) with ESMTP id 72A5343D2D for ; Tue, 26 Apr 2005 18:47:17 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 21329 invoked from network); 26 Apr 2005 18:47:17 -0000 Received: from server.baldwin.cx ([216.27.160.63]) (envelope-sender )AES256-SHA encrypted SMTP for ; 26 Apr 2005 18:47:16 -0000 Received: from roboboy.corp.weather.com (gw1.twc.weather.com [216.133.140.1]) (authenticated bits=0) by server.baldwin.cx (8.13.1/8.13.1) with ESMTP id j3QIl4W2034470; Tue, 26 Apr 2005 14:47:09 -0400 (EDT) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: Andre Guibert de Bruet Date: Tue, 26 Apr 2005 14:41:13 -0400 User-Agent: KMail/1.8 References: <20050415063120.G93987@lexi.siliconlandmark.com> <200504161349.39693.doconnor@gsoft.com.au> <20050417025742.H93987@lexi.siliconlandmark.com> In-Reply-To: <20050417025742.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: <200504261441.14507.jhb@FreeBSD.org> X-Spam-Status: No, score=-102.8 required=4.2 tests=ALL_TRUSTED, USER_IN_WHITELIST 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: freebsd-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: Tue, 26 Apr 2005 18:47:18 -0000 On Sunday 17 April 2005 03:00 am, Andre Guibert de Bruet wrote: > On Sat, 16 Apr 2005, Daniel O'Connor wrote: > > 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? > > Locally, it works just fine. At the serial console, it yields the > "Inapproriate ioctl for device" message that one would expect. You can use 'vidcontrol -s X < /dev/ttyv0' as root I think. -- 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 26 18:48: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 E124B16A4CF for ; Tue, 26 Apr 2005 18:48:17 +0000 (GMT) Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by mx1.FreeBSD.org (Postfix) with SMTP id B080643D5F for ; Tue, 26 Apr 2005 18:48:16 +0000 (GMT) (envelope-from Emanuel.strobl@gmx.net) Received: (qmail invoked by alias); 26 Apr 2005 18:48:15 -0000 Received: from flb.schmalzbauer.de (EHLO cale.flintsbach.schmalzbauer.de) [62.245.232.135] by mail.gmx.net (mp026) with SMTP; 26 Apr 2005 20:48:15 +0200 X-Authenticated: #301138 From: Emanuel Strobl To: freebsd-questions@freebsd.org Date: Tue, 26 Apr 2005 20:48:05 +0200 User-Agent: KMail/1.8 References: <200504262010.49509@harrymail> <20050426182629.GA16663@saltmine.radix.net> In-Reply-To: <20050426182629.GA16663@saltmine.radix.net> X-Birthday: Oct. 6th 1972 X-CelPhone: +49 (0) 173 9967781 X-Tel: +49 (0) 89 18947781 X-Country: Germany X-Address: Munich, 80686 X-OS: FreeBSD MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1810279.KeyMkxDVFm"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200504262048.14758@harrymail> X-Y-GMX-Trusted: 0 cc: freebsd-current@freebsd.org cc: Thomas Dickey Subject: Re: groff alternative? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 26 Apr 2005 18:48:18 -0000 --nextPart1810279.KeyMkxDVFm Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Am Dienstag, 26. April 2005 20:26 schrieb Thomas Dickey: > On Tue, Apr 26, 2005 at 08:10:41PM +0200, Emanuel Strobl wrote: > > Does anybody know any alternative for the groff part to view man pages > > simply with the man command? It's horrible that the filter needs more > > space than all the manpages itself! > > perhaps "cawf" This is _very_ interesting. Thanks a lot! I found sources on http://www.tux.org/pub/sites/vic.cc.purdue.edu/ Is there additional work known? It's 8 years old and I'm not very familar w= ith=20 nroff at all, so I don't want to learn about outdated macros. Thank you, =2DHarry --nextPart1810279.KeyMkxDVFm Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQBCbozuBylq0S4AzzwRAo2QAKCL3Me/wHePZhazrav2zr/bCGqGOACeOYbE iiZkn5pkVq+C7sK90a1AXhA= =auR4 -----END PGP SIGNATURE----- --nextPart1810279.KeyMkxDVFm-- From owner-freebsd-current@FreeBSD.ORG Tue Apr 26 18:48: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 C1B2516A4E5 for ; Tue, 26 Apr 2005 18:48:22 +0000 (GMT) Received: from mail-in-01.arcor-online.net (mail-in-01.arcor-online.net [151.189.21.41]) by mx1.FreeBSD.org (Postfix) with ESMTP id DD65643D41 for ; Tue, 26 Apr 2005 18:48:21 +0000 (GMT) (envelope-from mailnull@mips.inka.de) Received: from kemoauc.mips.inka.de (dsl-084-056-232-048.arcor-ip.net [84.56.232.48]) by mail-in-01.arcor-online.net (Postfix) with ESMTP id 4A31023F9E for ; Tue, 26 Apr 2005 20:46:57 +0200 (CEST) Received: from kemoauc.mips.inka.de (localhost [127.0.0.1]) by kemoauc.mips.inka.de (8.13.3/8.12.10) with ESMTP id j3QImJl3074078 for ; Tue, 26 Apr 2005 20:48:19 +0200 (CEST) (envelope-from mailnull@kemoauc.mips.inka.de) Received: (from mailnull@localhost) by kemoauc.mips.inka.de (8.13.3/8.13.1/Submit) id j3QImJVd074077 for freebsd-current@freebsd.org; Tue, 26 Apr 2005 20:48:19 +0200 (CEST) (envelope-from mailnull) From: naddy@mips.inka.de (Christian Weisgerber) Date: Tue, 26 Apr 2005 18:48:18 +0000 (UTC) Message-ID: References: <200504261143.55195.josemi@redesjm.local> Originator: naddy@mips.inka.de (Christian Weisgerber) To: freebsd-current@freebsd.org Subject: Re: rigth crc32 implementation X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 26 Apr 2005 18:48:22 -0000 Jose M Rodriguez wrote: > Working on usb_adslsubr{.c,.h} > > About how to implement crc32 > > My first think was use the libkern based one, but I found: > sys/linkern/crc32.c Not sure what's required for usb_adsl, but just about all the ethernet drivers use ether_crc32_be() or ether_crc32_le() from sys/net/if_ethersubr.c. -- Christian "naddy" Weisgerber naddy@mips.inka.de From owner-freebsd-current@FreeBSD.ORG Tue Apr 26 18:51: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 9E7AB16A4CE for ; Tue, 26 Apr 2005 18:51:24 +0000 (GMT) Received: from mail.gmx.net (pop.gmx.net [213.165.64.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 7B02943D67 for ; Tue, 26 Apr 2005 18:51:23 +0000 (GMT) (envelope-from Emanuel.strobl@gmx.net) Received: (qmail invoked by alias); 26 Apr 2005 18:51:22 -0000 Received: from flb.schmalzbauer.de (EHLO cale.flintsbach.schmalzbauer.de) [62.245.232.135] by mail.gmx.net (mp004) with SMTP; 26 Apr 2005 20:51:22 +0200 X-Authenticated: #301138 From: Emanuel Strobl To: freebsd-questions@freebsd.org Date: Tue, 26 Apr 2005 20:51:14 +0200 User-Agent: KMail/1.8 References: <200504262010.49509@harrymail> <426E8BE6.7090800@aueb.gr> In-Reply-To: <426E8BE6.7090800@aueb.gr> X-Birthday: Oct. 6th 1972 X-CelPhone: +49 (0) 173 9967781 X-Tel: +49 (0) 89 18947781 X-Country: Germany X-Address: Munich, 80686 X-OS: FreeBSD MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3979307.R0PUZGRCoS"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200504262051.21729@harrymail> X-Y-GMX-Trusted: 0 cc: Diomidis Spinellis cc: freebsd-current@FreeBSD.ORG Subject: Re: groff alternative? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 26 Apr 2005 18:51:24 -0000 --nextPart3979307.R0PUZGRCoS Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Am Dienstag, 26. April 2005 20:43 schrieb Diomidis Spinellis: > Emanuel Strobl wrote: > > I'm using NO_CXX in my make.conf to strip down the base system to ~50MB > > including man pages. The only problem is that groff is missing if I don= 't > > build c++, and even if I build groff itself and the needed libstdc++ it > > costs me about 10MB. If I just skip NO_CXX it's only 500k more, so I > > moved my patches to /dev/null. > > Does anybody know any alternative for the groff part to view man pages > > simply with the man command? It's horrible that the filter needs more > > space than all the manpages itself! > > Have you considered preformatting the manual pages on the development > system, and copying over the pages into /usr/share/man/cat* of the > shrinked-down system? > > > And of course, even if I decide to leave system man pages outside the > > flash card I still may want to read man pages of installed packages > > (which is another mountpoint on my installation, so there may be no spa= ce > > limit, depending on the card and additional drives) > > Again, it appears your shrinked-down system has access to a more > powerful machine. You could modify man to run groff on the remote machin= e. That's a possible solution, but not the way I like it. If I once installed = one=20 of these embedded boxes and decide to add a small package it should be=20 possible to read the package's man page without any help of other machines.= =20 Also ordinary package-installation should work, so preformatting system man= =20 pages is a good idea but not applicable for the ports/packages. Thanks, =2DHarry --nextPart3979307.R0PUZGRCoS Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQBCbo2pBylq0S4AzzwRAo5rAKCB3wa7pxiz0HiV9DkFPihR4VttOACghDkY cC6z8VpZENh9Fm6ajp9ltB4= =qoBB -----END PGP SIGNATURE----- --nextPart3979307.R0PUZGRCoS-- From owner-freebsd-current@FreeBSD.ORG Tue Apr 26 18:51: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 2D25616A4CE for ; Tue, 26 Apr 2005 18:51:47 +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 E651243D48 for ; Tue, 26 Apr 2005 18:51:46 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 8BB7D516F2; Tue, 26 Apr 2005 11:51:44 -0700 (PDT) Date: Tue, 26 Apr 2005 11:51:44 -0700 From: Kris Kennaway To: Randy Bush Message-ID: <20050426185144.GA25420@xor.obsecurity.org> References: <17006.19740.605509.984940@roam.psg.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="M9NhX3UHpAaciwkO" Content-Disposition: inline In-Reply-To: <17006.19740.605509.984940@roam.psg.com> User-Agent: Mutt/1.4.2.1i cc: FreeBSD Current Subject: Re: ule+preempt? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 26 Apr 2005 18:51:47 -0000 --M9NhX3UHpAaciwkO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Apr 26, 2005 at 04:15:56AM -1000, Randy Bush wrote: > having been seriously burned, i have avoided ule for some months. > i am wondering if the waters have become relatively safe to go > to ule with preemption? No, it can cause panics and is not yet reliable in my testing. Kris --M9NhX3UHpAaciwkO Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFCbo3AWry0BWjoQKURAkpsAKDKCJSOR/3ohUrvM1EUMpe+EMrh3wCgglHu ReGd1rLmH0wheGZX6zSLhwk= =Y8X4 -----END PGP SIGNATURE----- --M9NhX3UHpAaciwkO-- From owner-freebsd-current@FreeBSD.ORG Tue Apr 26 19:13: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 B740B16A4CE for ; Tue, 26 Apr 2005 19:13:01 +0000 (GMT) Received: from 62-15-211-171.inversas.jazztel.es (62-15-211-171.inversas.jazztel.es [62.15.211.171]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8006B43D2F for ; Tue, 26 Apr 2005 19:13:00 +0000 (GMT) (envelope-from josemi@freebsd.jazztel.es) Received: from redesjm.local (orion.redesjm.local [192.168.254.16]) j3QJCuK7005124; Tue, 26 Apr 2005 21:12:56 +0200 (CEST) (envelope-from josemi@redesjm.local) Received: from localhost (localhost [[UNIX: localhost]]) by redesjm.local (8.13.3/8.13.3/Submit) id j3QJCtQ9068303; Tue, 26 Apr 2005 21:12:55 +0200 (CEST) (envelope-from josemi@redesjm.local) From: Jose M Rodriguez To: freebsd-current@freebsd.org Date: Tue, 26 Apr 2005 21:12:53 +0200 User-Agent: KMail/1.8 References: <200504261143.55195.josemi@redesjm.local> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-13" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200504262112.54889.josemi@redesjm.local> X-AntiVirus: checked by AntiVir Milter (version: 1.1.0-3; AVE: 6.30.0.7; VDF: 6.30.0.116; host: antares.redesjm.local) cc: Christian Weisgerber Subject: Re: rigth crc32 implementation X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 26 Apr 2005 19:13:01 -0000 El Martes, 26 de Abril de 2005 20:48, Christian Weisgerber escribi=F3: > Jose M Rodriguez wrote: > > Working on usb_adslsubr{.c,.h} > > > > About how to implement crc32 > > > > My first think was use the libkern based one, but I found: > > sys/linkern/crc32.c > > Not sure what's required for usb_adsl, but just about all the > ethernet drivers use ether_crc32_be() or ether_crc32_le() from > sys/net/if_ethersubr.c. =46or what I Know, this is used for unicast masking calculations. I think using sys/kern/crc32.c is more in the way, but the problem is=20 the same. Those functions are oriented to calculate the crc of a formed string,=20 while I need do this 'in transit', with the classical crc_init(&acum),=20 crc_do(&acum, &str, len), crc=3Dcrc_get(&acum) But I don't know if crc32.c will be right in non-i386 like endian=20 systems. I allways see this implemented with a previous crc table=20 generation. If (I Hope) there aren't endian problems with crc32.c (I doesn't have=20 the hard to test this), my plans are add those 2/3 functions to=20 sys/kern/crc32.c using the same table. Any comments on this are welcome. =2D- josemi From owner-freebsd-current@FreeBSD.ORG Tue Apr 26 19:20: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 F016B16A4CE for ; Tue, 26 Apr 2005 19:20:52 +0000 (GMT) Received: from mail.qconline.com (mail.qconline.com [204.176.110.250]) by mx1.FreeBSD.org (Postfix) with ESMTP id 57E3443D1F for ; Tue, 26 Apr 2005 19:20:52 +0000 (GMT) (envelope-from harrycoin@qconline.com) Received: from devoffice.qconline.com (unverified [64.4.171.82]) by mail.qconline.com for ; Tue, 26 Apr 2005 14:21:15 -0500 Message-Id: <4.3.2.7.2.20050426140849.01f33ff0@mail.qconline.com> X-Sender: harrycoin@mail.qconline.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 26 Apr 2005 14:20:40 -0500 To: freebsd-current@freebsd.org From: Harry Coin In-Reply-To: <20050426185200.D9D3B16A519@hub.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: 5.4 ACPI issue? psm irq unallocated on 5.4 RC3- no mouse. Same box works on 5.3 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 26 Apr 2005 19:20:53 -0000 Here's a boot -v dmesg showing that a working ps/2 mouse under 5.3 is ignored on the latest 5.4 as of today. Seems it can't allocate an interrupt. So, no mouse driver loads under 5.4. Go back to 5.3, and the mouse works (but atapicam generates an interrupt storm hang (not panic) on boot under 5.3. The atapicam issue is fixed in 5.4. Here are the few relevant lines, then the whole dmesg atkbdc0: port 0x64,0x60 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0065 atkbd: keyboard ID 0x41ab (2) kbd0 at atkbd0 kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 atkbd0: [GIANT-LOCKED] psm0: unable to allocate IRQ psmcpnp0: irq 12 on acpi0 psm0: current command byte:0065 psm0: failed to reset the aux device. Here's the whole dmesg -v pcib0: matched entry for 0.1.INTA pcib0: slot 1 INTA hardwired to IRQ 16 pcib1: slot 0 INTA is routed to irq 16 found-> vendor=0x10de, dev=0x0181, revid=0xa2 bus=1, slot=0, func=0 class=03-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x02b0, cachelnsz=0 (dwords) lattimer=0xc0 (5760 ns), mingnt=0x05 (1250 ns), maxlat=0x01 (250 ns) intpin=a, irq=16 powerspec 2 supports D0 D3 current D0 nvidia0: mem 0xe8000000-0xefffffff,0xfd000000-0xfdffffff irq 16 at device 0.0 on pci1 nvidia0: Reserved 0x1000000 bytes for rid 0x10 type 3 at 0xfd000000 nvidia0: Reserved 0x8000000 bytes for rid 0x14 type 3 at 0xe8000000 nvidia0: [GIANT-LOCKED] pcib2: at device 3.0 on pci0 pcib2: secondary bus 2 pcib2: subordinate bus 2 pcib2: I/O decode 0xc000-0xcfff pcib2: memory decode 0xfe900000-0xfe9fffff pcib2: prefetched decode 0xfff00000-0xfffff ACPI PCI link initial configuration: pci2: on pcib2 pci2: physical bus=2 map[10]: type 1, range 32, base fe9e0000, size 17, enabled pcib2: device (null) requested decoded memory range 0xfe9e0000-0xfe9fffff map[18]: type 4, range 32, base 0000cf80, size 5, enabled pcib2: device (null) requested decoded I/O range 0xcf80-0xcf9f pcib2: matched entry for 2.1.INTA pcib2: slot 1 INTA hardwired to IRQ 18 found-> vendor=0x8086, dev=0x1019, revid=0x00 bus=2, slot=1, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0238, cachelnsz=4 (dwords) lattimer=0x00 (0 ns), mingnt=0xff (63750 ns), maxlat=0x00 (0 ns) intpin=a, irq=18 powerspec 2 supports D0 D3 current D0 em0: port 0xcf80-0xcf9f mem 0xfe9e0000-0xfe9fffff irq 18 at device 1.0 on pci2 em0: Reserved 0x20000 bytes for rid 0x10 type 3 at 0xfe9e0000 em0: Reserved 0x20 bytes for rid 0x18 type 4 at 0xcf80 em0: [MPSAFE] em0: bpf attached em0: Ethernet address: 00:0c:6e:79:7a:bb em0: Speed:N/A Duplex:N/A uhci0: port 0xeec0-0xeedf irq 16 at device 29.0 on pci0 uhci0: Reserved 0x20 bytes for rid 0x20 type 4 at 0xeec0 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 0xef00-0xef1f irq 19 at device 29.1 on pci0 uhci1: Reserved 0x20 bytes for rid 0x20 type 4 at 0xef00 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 0xef20-0xef3f irq 18 at device 29.2 on pci0 uhci2: Reserved 0x20 bytes for rid 0x20 type 4 at 0xef20 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 0xef40-0xef5f irq 16 at device 29.3 on pci0 uhci3: Reserved 0x20 bytes for rid 0x20 type 4 at 0xef40 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 pci0: at device 29.7 (no driver attached) pcib3: at device 30.0 on pci0 pcib3: secondary bus 3 pcib3: subordinate bus 3 pcib3: I/O decode 0xd000-0xdfff pcib3: memory decode 0xfea00000-0xfeafffff pcib3: prefetched decode 0xfff00000-0xfffff pcib3: Subtractively decoded bridge. ACPI PCI link initial configuration: pci3: on pcib3 pci3: physical bus=3 map[10]: type 1, range 32, base feaff800, size 11, enabled pcib3: device (null) requested decoded memory range 0xfeaff800-0xfeafffff map[14]: type 4, range 32, base 0000dc00, size 7, enabled pcib3: device (null) requested decoded I/O range 0xdc00-0xdc7f pcib3: matched entry for 3.3.INTA pcib3: slot 3 INTA hardwired to IRQ 20 found-> vendor=0x1106, dev=0x3044, revid=0x80 bus=3, slot=3, func=0 class=0c-00-10, hdrtype=0x00, mfdev=0 cmdreg=0x0117, statreg=0x0210, cachelnsz=4 (dwords) lattimer=0xc0 (5760 ns), mingnt=0x00 (0 ns), maxlat=0x20 (8000 ns) intpin=a, irq=20 powerspec 2 supports D0 D2 D3 current D0 fwohci0: port 0xdc00-0xdc7f mem 0xfeaff800-0xfeafffff irq 20 at device 3.0 on pci3 fwohci0: Reserved 0x800 bytes for rid 0x10 type 3 at 0xfeaff800 fwohci0: [MPSAFE] fwohci0: OHCI version 1.0 (ROM=1) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 00:e0:18:00:00:28:47:f6 fwohci0: Phy 1394a available S400, 2 ports. fwohci0: Link S400, max_rec 2048 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) isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0xef90-0xef9f,0xefa8-0xefab,0xefa0-0xefa7,0xefac-0xefaf,0xefe0-0xefe7 irq 18 at device 31.1 on pci0 atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0xef90 atapci0: [MPSAFE] ata2: channel #0 on atapci0 atapci0: Reserved 0x8 bytes for rid 0x10 type 4 at 0xefe0 atapci0: Reserved 0x4 bytes for rid 0x14 type 4 at 0xefac ata2: reset tp1 mask=03 ostat0=50 ostat1=50 ata2-master: stat=0x50 err=0x01 lsb=0x00 msb=0x00 ata2-slave: stat=0x50 err=0x01 lsb=0x00 msb=0x00 ata2: reset tp2 stat0=50 stat1=50 devices=0x3 ata2: [MPSAFE] ata3: channel #1 on atapci0 atapci0: Reserved 0x8 bytes for rid 0x18 type 4 at 0xefa0 atapci0: Reserved 0x4 bytes for rid 0x1c type 4 at 0xefa8 ata3: reset tp1 mask=03 ostat0=00 ostat1=00 ata3-master: stat=0x6f err=0x6f lsb=0x6f msb=0x6f ata3-master: stat=0x6f err=0x6f lsb=0x6f msb=0x6f ata3-master: stat=0x6f err=0x6f lsb=0x6f msb=0x6f ata3-master: stat=0x6f err=0x6f lsb=0x6f msb=0x6f ata3: reset tp2 stat0=ef stat1=80 devices=0x0 ata3: [MPSAFE] pci0: at device 31.3 (no driver attached) pcm0: port 0xee80-0xeebf,0xe800-0xe8ff mem 0xfebff000-0xfebff0ff,0xfebff400-0xfebff5ff irq 17 at device 31.5 on pci0 pcm0: Reserved 0x200 bytes for rid 0x18 type 3 at 0xfebff400 pcm0: Reserved 0x100 bytes for rid 0x1c type 3 at 0xfebff000 pcm0: [GIANT-LOCKED] pcm0: pcm0: Codec features headphone, 20 bit DAC, 5 bit master volume, no 3D Stereo Enhancement pcm0: Primary codec extended features variable rate PCM, double rate PCM, reserved 1, center DAC, surround DAC, LFE DAC, AMAP pcm0: sndbuf_setmap 7d608000, 4000; 0xeac79000 -> 7d608000 pcm0: sndbuf_setmap 7d5ff000, 4000; 0xeac7d000 -> 7d5ff000 acpi_button0: on acpi0 atkbdc0: port 0x64,0x60 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0065 atkbd: keyboard ID 0x41ab (2) kbd0 at atkbd0 kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 atkbd0: [GIANT-LOCKED] psm0: unable to allocate IRQ psmcpnp0: irq 12 on acpi0 psm0: current command byte:0065 psm0: failed to reset the aux device. sio0: irq maps: 0x801 0x811 0x801 0x801 sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A sio1: irq maps: 0x801 0x809 0x801 0x801 sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A fdc0: port 0x3f7,0x3f0-0x3f5 irq 6 drq 2 on acpi0 fdc0: ic_type 90 part_id 80 fdc0: [MPSAFE] fdc0: [FAST] fd0: <1440-KB 3.5" drive> on fdc0 drive 0 ppc0: using extended I/O port range ppc0: ECP SPP ECP+EPP SPP ppc0: port 0x778-0x77b,0x378-0x37f irq 7 drq 3 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/9 bytes threshold ppbus0: on ppc0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 atkbdc: atkbdc0 already exists; skipping it fdc: fdc0 already exists; skipping it ppc: ppc0 already exists; skipping it sio: sio0 already exists; skipping it sio: sio1 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 0xc0000-0xce7ff on isa0 pmtimer0 on isa0 adv0: not probed (disabled) aha0: not probed (disabled) aic0: not probed (disabled) ata0 at port 0x3f6,0x1f0-0x1f7 irq 14 on isa0 ata0: reset tp1 mask=00 ostat0=ff ostat1=ff ata0: [MPSAFE] ata1 at port 0x376,0x170-0x177 irq 15 on isa0 ata1: reset tp1 mask=00 ostat0=ff ostat1=ff ata1: [MPSAFE] bt0: not probed (disabled) cs0: not probed (disabled) ed0: not probed (disabled) fe0: not probed (disabled) ie0: not probed (disabled) lnc0: not probed (disabled) pcic0 failed to probe at port 0x3e0 iomem 0xd0000 on isa0 pcic1: not probed (disabled) sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sc0: fb0, kbd0, terminal emulator: sc (syscons terminal) sio2: not probed (disabled) sio3: not probed (disabled) sn0: not probed (disabled) vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 fb0: vga0, vga, type:VGA (5), flags:0x7007f fb0: port:0x3c0-0x3df, crtc:0x3d4, mem:0xa0000 0x20000 fb0: init mode:24, bios mode:3, current mode:24 fb0: window:0xc00b8000 size:32k gran:32k, buf:0 size:32k VGA parameters upon power-up 50 18 10 00 00 00 03 00 02 67 5f 4f 50 82 54 80 bf 1f 00 4f 0d 0e 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 50 18 10 00 10 00 03 00 02 67 5f 4f 50 82 54 80 bf 1f 00 4f 0d 0e 00 00 00 00 9c 8e 8f 28 1f 96 b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff EGA/VGA parameters to be used for mode 24 50 18 10 00 10 00 03 00 02 67 5f 4f 50 82 54 80 bf 1f 00 4f 0d 0e 00 00 00 00 9c 8e 8f 28 1f 96 b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff vt0: not probed (disabled) isa_probe_children: probing PnP devices Device configuration finished. Reducing kern.maxvnodes 134066 -> 100000 procfs registered Timecounter "TSC" frequency 2806372688 Hz quality -100 Timecounters tick every 10.000 msec Linux ELF exec handler installed lo0: bpf attached em0: Link is up 1000 Mbps Full Duplex ata2-slave: pio=0x0c wdma=0x22 udma=0x45 cable=80pin ata2-master: pio=0x0c wdma=0x22 udma=0x45 cable=80pin ata2-master: setting PIO4 on Intel ICH5 chip ata2-master: setting UDMA100 on Intel ICH5 chip ata2-slave: setting PIO4 on Intel ICH5 chip ata2-slave: setting UDMA100 on Intel ICH5 chip ad4: ATA-6 disk at ata2-master ad4: 238475MB (488397168 sectors), 484521 C, 16 H, 63 S, 512 B ad4: 16 secs/int, 1 depth queue, UDMA100 ar: FreeBSD check1 failed ad5: ATA-6 disk at ata2-slave ad5: 238475MB (488397168 sectors), 484521 C, 16 H, 63 S, 512 B ad5: 16 secs/int, 1 depth queue, UDMA100 ar: FreeBSD check1 failed pcm0: measured ac97 link rate at 48004 Hz, will use 48000 Hz SMP: AP CPU #1 Launched! cpu1 AP: ID: 0x01000000 VER: 0x00050014 LDR: 0x02000000 DFR: 0x0fffffff lint0: 0x00010700 lint1: 0x00010400 TPR: 0x00000000 SVR: 0x000001ff ioapic0: routing intpin 1 (ISA IRQ 1) to cluster 0 ioapic0: routing intpin 3 (ISA IRQ 3) to cluster 0 ioapic0: routing intpin 4 (ISA IRQ 4) to cluster 0 ioapic0: routing intpin 6 (ISA IRQ 6) to cluster 0 ioapic0: routing intpin 7 (ISA IRQ 7) to cluster 0 ioapic0: routing intpin 8 (ISA IRQ 8) to cluster 0 ioapic0: routing intpin 9 (ISA IRQ 9) to cluster 0 ioapic0: routing intpin 13 (ISA IRQ 13) 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 17 (PCI IRQ 17) to cluster 0 ioapic0: routing intpin 18 (PCI IRQ 18) to cluster 0 ioapic0: routing intpin 19 (PCI IRQ 19) to cluster 0 ioapic0: routing intpin 20 (PCI IRQ 20) to cluster 0 GEOM: new disk ad4 GEOM: new disk ad5 [0] f:80 typ:165 s(CHS):0/1/1 e(CHS):168/15/63 s:63 l:488397105 [1] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [2] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [3] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 GEOM: Configure ad4s1, start 32256 length 250059317760 end 250059350015 [0] f:80 typ:165 s(CHS):0/1/1 e(CHS):168/15/63 s:63 l:488397105 [1] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [2] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [3] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 GEOM: Configure ad5s1, start 32256 length 250059317760 end 250059350015 [0] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [1] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [2] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [3] f:80 typ:165 s(CHS):0/0/1 e(CHS):1023/254/63 s:0 l:50000 GEOM: Configure ad4s1a, start 0 length 1073741824 end 1073741823 GEOM: Configure ad4s1b, start 1073741824 length 2147483648 end 3221225471 GEOM: Configure ad4s1c, start 0 length 250059317760 end 250059317759 GEOM: Configure ad4s1d, start 3221225472 length 1073741824 end 4294967295 GEOM: Configure ad4s1e, start 4294967296 length 4294967296 end 8589934591 GEOM: Configure ad4s1f, start 8589934592 length 241469383168 end 250059317759 GEOM: Configure ad5s1b, start 0 length 2147483648 end 2147483647 GEOM: Configure ad5s1c, start 0 length 250059317760 end 250059317759 GEOM: Configure ad5s1f, start 2147483648 length 247911834112 end 250059317759 [0] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [1] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [2] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [3] f:80 typ:165 s(CHS):0/0/1 e(CHS):1023/254/63 s:0 l:50000 [0] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [1] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [2] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [3] f:80 typ:165 s(CHS):0/0/1 e(CHS):1023/254/63 s:0 l:50000 Mounting root from ufs:/dev/ad4s1a start_init: trying /sbin/init splash: image decoder found: green_saver em0: Link is up 1000 Mbps Full Duplex From owner-freebsd-current@FreeBSD.ORG Tue Apr 26 19:34: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 0FB9B16A4CE for ; Tue, 26 Apr 2005 19:34:39 +0000 (GMT) Received: from www.cryptography.com (li-22.members.linode.com [64.5.53.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3D77743D31 for ; Tue, 26 Apr 2005 19:34:38 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.0.34] (adsl-64-171-185-67.dsl.snfc21.pacbell.net [64.171.185.67]) by www.cryptography.com (8.12.8/8.12.8) with ESMTP id j3QJYZLS013965 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 26 Apr 2005 12:34:36 -0700 Message-ID: <426E9791.1050305@root.org> Date: Tue, 26 Apr 2005 12:33:37 -0700 From: Nate Lawson User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Matthew Sullivan References: <4267A1CF.3080903@uq.edu.au> <20050422190208.M68772@lexi.siliconlandmark.com> <426C93AC.3030907@root.org> <20050425200601.I42718@carver.gumbysoft.com> <426DB58B.5020608@uq.edu.au> <20050425204148.H43358@carver.gumbysoft.com> <426DDABF.8050708@uq.edu.au> In-Reply-To: <426DDABF.8050708@uq.edu.au> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-current@freebsd.org Subject: Re: SMP on Compaq DL380 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 26 Apr 2005 19:34:39 -0000 Matthew Sullivan wrote: > Doug White wrote: > >> On Tue, 26 Apr 2005, Matthew Sullivan wrote: >> >> >> >>>>>> There definitely is a problem when you have identical APIC ids. We >>>>>> already blacklist one version of this BIOS. >>>>>> >>>>>> >>>>> >>>>> That's not something I wanted to here right now... :-( >>>>> >>>> >>>> Are you __sure__ you're booting the right kernel? >>>> http://scorpion.sorbs.net/dmesg.txt shows a kernel that does not >>>> have SMP >>>> nor APIC enabled. I'm still seeing ISA interrupt routing rather >>>> than APIC >>>> mappings. And as noted previously the APIC IDs are not set which means >>>> they are not enabled. (APIC IDs are always >0.) >>>> >>>> What is the output of 'sysctl kern.smp'? >>>> >>>> >>>> >>> >>> kern.smp.maxcpus: 16 >>> kern.smp.active: 0 >>> kern.smp.disabled: 0 >>> kern.smp.cpus: 1 >>> kern.smp.forward_signal_enabled: 1 >>> kern.smp.forward_roundrobin_enabled: 1 >>> >> >> >> You're booting the wrong kernel. Do a buildkernel + installkernel now, >> reboot the system, and check that the kernel's build date has >> incremented. >> Also watch the loader output and make sure someone hasn't overridden the >> kernel name in loader.conf. >> >> >> >>>> Have you tried booting without ACPI? >>>> >>>> >>>> >>> >>> No, but I am doing now... >>> >>> Btw now I have remote console this is what the BIOS shows.... >>> >>> 1024 MB Detected >>> >>> COMPAQ System BIOS - P17 (12/18/2002) >>> Copyright 1982,2002 Compaq Computer Corporation. All rights reserved. >>> >> >> >> This appears to be the latest BIOS. Some Compaq systems are known to >> generate bogus MPTables and such when configured to run Windows. You >> might >> poke around the BIOS Setup and see if there is an "OS Type" field that >> can >> be set to "SCO UNIX" or "Other" (not in PnP setup probably). >> >> >> >>> Boot without ACPI is show at http://scorpion.sorbs.net/dmesg-noacpi.txt >>> >>> kern.smp.maxcpus: 16 >>> kern.smp.active: 0 >>> kern.smp.disabled: 0 >>> kern.smp.cpus: 1 >>> kern.smp.forward_signal_enabled: 1 >>> kern.smp.forward_roundrobin_enabled: 1 >>> >>> I'm going to recompile the kernel again - with the current config - just >>> to prove it's there... >>> >> >> >> Good idea :) >> >> >> > Ok, after building we have: > root@scorpion:~# uname -a FreeBSD scorpion.sorbs.net > 5.3-RELEASE-p9 FreeBSD 5.3-RELEASE-p9 #0: Tue Apr 26 14:35:20 EST > 2005 root@scorpion.sorbs.net:/usr/obj/usr/src/sys/SCORPION i386 > > (why not #1..?) the build date is current, the config file is at: > http://scorpion.sorbs.net/SMP/SCORPION > > dmesg from boot -v is at: http://scorpion.sorbs.net/SMP/dmesg-v.txt > > acpidump -t -d is at: http://scorpion.sorbs.net/SMP/acpidump-t-d.txt > > sysclt -a is at: http://scorpion.sorbs.net/SMP/sysctl-a.txt > > Have I forgotten anything? (I haven't done a non-acpi boot from this new > kernel) I looked at your ASL and it looks fine. We don't blacklist this exact BIOS but it appears to be derived from one we do (Compaq Racebait). If you have a newer one you can update to, that may help. As far as the APIC tables, they're fine as well. The CPU ids match the Processor definitions in the ASL. However, ACPI is not the primary way FreeBSD enumerates CPUs. (You'll notice that the cpu announcements are printed before acpi0 is probed. The apic code is the real determinant of whether a CPU is used or not although it does reference the ACPI tables.) ACPI APIC Table: Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Pentium(R) 4 CPU 3.20GHz (3207.29-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf34 Stepping = 4 Features=0xbfebfbff Hyperthreading: 2 logical CPUs real memory = 2146631680 (2047 MB) avail memory = 2079891456 (1983 MB) FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0 irqs 0-23 on motherboard The reason only one ACPI cpu0 is announced is because the acpi cpu code only attaches to processors that have been added by the apic code (i.e. mp_maxid). The real fix as someone else said is to change a BIOS setting or something to get your BIOS to announce all the CPUs. -- Nate From owner-freebsd-current@FreeBSD.ORG Tue Apr 26 19:42: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 A2BF716A4CE for ; Tue, 26 Apr 2005 19:42:11 +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 596CA43D60 for ; Tue, 26 Apr 2005 19:42:11 +0000 (GMT) (envelope-from marcel@xcllnt.net) Received: from ns1.xcllnt.net (localhost [127.0.0.1]) by ns1.xcllnt.net (8.13.3/8.13.3) with ESMTP id j3QJg8en007960; Tue, 26 Apr 2005 12:42:09 -0700 (PDT) (envelope-from marcel@ns1.xcllnt.net) Received: (from marcel@localhost) by ns1.xcllnt.net (8.13.3/8.13.3/Submit) id j3QJg8Uf007959; Tue, 26 Apr 2005 12:42:08 -0700 (PDT) (envelope-from marcel) Date: Tue, 26 Apr 2005 12:42:08 -0700 From: Marcel Moolenaar To: Jose M Rodriguez Message-ID: <20050426194208.GB7773@ns1.xcllnt.net> References: <200504261143.55195.josemi@redesjm.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200504261143.55195.josemi@redesjm.local> User-Agent: Mutt/1.4.2.1i cc: freebsd-current@freebsd.org Subject: Re: rigth crc32 implementation X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 26 Apr 2005 19:42:11 -0000 On Tue, Apr 26, 2005 at 11:43:54AM +0200, Jose M Rodriguez wrote: > > My first think was use the libkern based one, but I found: > sys/linkern/crc32.c > > - the code may not be endian safe. It operates on bytes, so it's endian-safe. Note that the uint32_t that's returned is not subject to endianness issues: it's always in the native byte order. The caller of crc32 needs to byteswap if it needs to compare this integral with a CRC that's not in the native byte order. > - the code lacks support for processing chuncks. This should be easy enough to add. We could add an alternative version that also takes the initial CRC value. The initial CRC value can be the calculated CRC of a previous chunk. This also solves the problem that some CRC calculations start with a CRC of 0U, while others start with a CRC of ~0U. See also: http://www.repairfaq.org/filipg/LINK/F_crc_v34.html#CRCV_003 Roughly speaking (ok, not quite) this is what needs to happen: uint32_t crc32_raw(const void *buf, size_t size, uint32_t crc) { const uint8_t *p = buf; while (size--) crc = crc32_tab[(crc ^ *p++) & 0xFF] ^ (crc >> 8); return (crc); } uint32_t crc32(const void *buf, size_t size) { uint32_t crc; crc = crc32_raw(buf, size, ~0U); return (crc ^ ~0U); } Here, crc32_raw() allows the caller to specify the initial CRC value as well as allows the caller to handle the final XOR. Does the above solve your CRC problems? -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net From owner-freebsd-current@FreeBSD.ORG Tue Apr 26 20:01: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 65E1B16A4CE for ; Tue, 26 Apr 2005 20:01:35 +0000 (GMT) Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id 24C7E43D2D for ; Tue, 26 Apr 2005 20:01:35 +0000 (GMT) (envelope-from sam@errno.com) Received: from [10.10.18.98] (mail.atheros.com [65.212.155.130]) (authenticated bits=0) by ebb.errno.com (8.12.9/8.12.6) with ESMTP id j3QK1Ums071302 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 Apr 2005 13:01:31 -0700 (PDT) (envelope-from sam@errno.com) Message-ID: <426E9E1C.6020609@errno.com> Date: Tue, 26 Apr 2005 13:01:32 -0700 From: Sam Leffler Organization: Errno Consulting User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Marcel Moolenaar References: <200504261143.55195.josemi@redesjm.local> <20050426194208.GB7773@ns1.xcllnt.net> In-Reply-To: <20050426194208.GB7773@ns1.xcllnt.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-DCC-vtss-Metrics: ebb.errno.com 1018; Body=3 Fuz1=3 Fuz2=3 cc: freebsd-current@freebsd.org cc: Jose M Rodriguez Subject: Re: rigth crc32 implementation X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 26 Apr 2005 20:01:35 -0000 Marcel Moolenaar wrote: > On Tue, Apr 26, 2005 at 11:43:54AM +0200, Jose M Rodriguez wrote: > >>My first think was use the libkern based one, but I found: >>sys/linkern/crc32.c >> >>- the code may not be endian safe. > > > It operates on bytes, so it's endian-safe. Note that the uint32_t > that's returned is not subject to endianness issues: it's always > in the native byte order. The caller of crc32 needs to byteswap > if it needs to compare this integral with a CRC that's not in > the native byte order. > > >>- the code lacks support for processing chuncks. > > > This should be easy enough to add. We could add an alternative > version that also takes the initial CRC value. The initial CRC > value can be the calculated CRC of a previous chunk. This also > solves the problem that some CRC calculations start with a CRC > of 0U, while others start with a CRC of ~0U. See also: > http://www.repairfaq.org/filipg/LINK/F_crc_v34.html#CRCV_003 > > Roughly speaking (ok, not quite) this is what needs to happen: > > uint32_t > crc32_raw(const void *buf, size_t size, uint32_t crc) > { > const uint8_t *p = buf; > > while (size--) > crc = crc32_tab[(crc ^ *p++) & 0xFF] ^ (crc >> 8); > > return (crc); > } > > uint32_t > crc32(const void *buf, size_t size) > { > uint32_t crc; > > crc = crc32_raw(buf, size, ~0U); > return (crc ^ ~0U); > } > > Here, crc32_raw() allows the caller to specify the initial CRC value > as well as allows the caller to handle the final XOR. > > Does the above solve your CRC problems? > Note also there is CRC32 code of this sort in WEP and TKIP crypto modules in the net80211 support. Sam From owner-freebsd-current@FreeBSD.ORG Tue Apr 26 20:16: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 A350316A4CE for ; Tue, 26 Apr 2005 20:16:42 +0000 (GMT) Received: from 62-15-211-171.inversas.jazztel.es (62-15-211-171.inversas.jazztel.es [62.15.211.171]) by mx1.FreeBSD.org (Postfix) with ESMTP id 609A443D5D for ; Tue, 26 Apr 2005 20:16:41 +0000 (GMT) (envelope-from josemi@freebsd.jazztel.es) Received: from redesjm.local (orion.redesjm.local [192.168.254.16]) j3QKGMik022397; Tue, 26 Apr 2005 22:16:22 +0200 (CEST) (envelope-from josemi@redesjm.local) Received: from localhost (localhost [[UNIX: localhost]]) by redesjm.local (8.13.3/8.13.3/Submit) id j3QKGKA5003047; Tue, 26 Apr 2005 22:16:20 +0200 (CEST) (envelope-from josemi@redesjm.local) From: Jose M Rodriguez To: Sam Leffler Date: Tue, 26 Apr 2005 22:16:18 +0200 User-Agent: KMail/1.8 References: <200504261143.55195.josemi@redesjm.local> <20050426194208.GB7773@ns1.xcllnt.net> <426E9E1C.6020609@errno.com> In-Reply-To: <426E9E1C.6020609@errno.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200504262216.20170.josemi@redesjm.local> X-AntiVirus: checked by AntiVir Milter (version: 1.1.0-3; AVE: 6.30.0.7; VDF: 6.30.0.116; host: antares.redesjm.local) cc: freebsd-current@freebsd.org cc: Jose M Rodriguez cc: Marcel Moolenaar Subject: Re: rigth crc32 implementation X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 26 Apr 2005 20:16:42 -0000 El Martes, 26 de Abril de 2005 22:01, Sam Leffler escribi=F3: > Marcel Moolenaar wrote: > > On Tue, Apr 26, 2005 at 11:43:54AM +0200, Jose M Rodriguez wrote: > >>My first think was use the libkern based one, but I found: > >>sys/linkern/crc32.c > >> > > Note also there is CRC32 code of this sort in WEP and TKIP crypto > modules in the net80211 support. > > Sam Yes. I'm finding _really_ a lot of crc32 out there. I'll take a look in=20 this. Are this code safe tested in non-i386 arch (You know)? =2D- josemi From owner-freebsd-current@FreeBSD.ORG Tue Apr 26 20:22: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 BA06B16A4EE for ; Tue, 26 Apr 2005 20:22:44 +0000 (GMT) Received: from 62-15-211-171.inversas.jazztel.es (62-15-211-171.inversas.jazztel.es [62.15.211.171]) by mx1.FreeBSD.org (Postfix) with ESMTP id DCC8543D39 for ; Tue, 26 Apr 2005 20:22:43 +0000 (GMT) (envelope-from josemi@freebsd.jazztel.es) Received: from redesjm.local (orion.redesjm.local [192.168.254.16]) j3QKMgkb022418; Tue, 26 Apr 2005 22:22:42 +0200 (CEST) (envelope-from josemi@redesjm.local) Received: from localhost (localhost [[UNIX: localhost]]) by redesjm.local (8.13.3/8.13.3/Submit) id j3QKMfNV004144; Tue, 26 Apr 2005 22:22:41 +0200 (CEST) (envelope-from josemi@redesjm.local) From: Jose M Rodriguez To: Marcel Moolenaar Date: Tue, 26 Apr 2005 22:22:40 +0200 User-Agent: KMail/1.8 References: <200504261143.55195.josemi@redesjm.local> <20050426194208.GB7773@ns1.xcllnt.net> In-Reply-To: <20050426194208.GB7773@ns1.xcllnt.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200504262222.41463.josemi@redesjm.local> X-AntiVirus: checked by AntiVir Milter (version: 1.1.0-3; AVE: 6.30.0.7; VDF: 6.30.0.116; host: antares.redesjm.local) cc: freebsd-current@freebsd.org cc: Jose M Rodriguez Subject: Re: rigth crc32 implementation X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 26 Apr 2005 20:22:44 -0000 El Martes, 26 de Abril de 2005 21:42, Marcel Moolenaar escribi=F3: > On Tue, Apr 26, 2005 at 11:43:54AM +0200, Jose M Rodriguez wrote: > > My first think was use the libkern based one, but I found: > > sys/linkern/crc32.c > > > > - the code may not be endian safe. > > It operates on bytes, so it's endian-safe. Note that the uint32_t > that's returned is not subject to endianness issues: it's always > in the native byte order. The caller of crc32 needs to byteswap > if it needs to compare this integral with a CRC that's not in > the native byte order. > Yes, but this code come from a previous reduction: calculate the table=20 from a xor/shift bit oriented alg. Looking at sys/net/if_ethersubr.c ether_crc32_be() & ether_crc32_le(), I=20 became to doubt if we need two tables, with bitesex based #ifs. =2D- josemi From owner-freebsd-current@FreeBSD.ORG Tue Apr 26 20:22: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 95A0E16A5DD for ; Tue, 26 Apr 2005 20:22:51 +0000 (GMT) Received: from pi.codefab.com (pi.codefab.com [199.103.21.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5956F43D60 for ; Tue, 26 Apr 2005 20:22:51 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from localhost (localhost [127.0.0.1]) by pi.codefab.com (Postfix) with ESMTP id D19B35E64; Tue, 26 Apr 2005 16:22:48 -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 45489-03; Tue, 26 Apr 2005 16:22:48 -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 C04F05E16; Tue, 26 Apr 2005 16:22:47 -0400 (EDT) Message-ID: <426EA305.9010400@mac.com> Date: Tue, 26 Apr 2005 16:22:29 -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.7) Gecko/20050414 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andy Fawcett References: <20050425010242.GA44110@xor.obsecurity.org> <20050425182033.GC40370@xor.obsecurity.org> <200504261338.01026.andy@athame.co.uk> In-Reply-To: <200504261338.01026.andy@athame.co.uk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at codefab.com cc: freebsd-current@freebsd.org Subject: Re: GCC 4.0 [Re: FreeBSD 6 is coming too fast] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 26 Apr 2005 20:22:51 -0000 Andy Fawcett wrote: > On Monday 25 April 2005 23:28, Garance A Drosihn wrote: [ ... ] >> I'm not saying that we should switch to it because of that, but I'm >> just mentioning it as an interesting data point (assuming it is true!). > > FYI, the KDE project just blacklisted gcc 4.0.0, because "it is known to > miscompile KDE. Please use a newer version, or if that is not yet available, > choose an older version." > > No, I don't know what the exact problems are, but they are obviously severe > enough for KDE to say "no thanks" to 4.0.0. Note that the KDE project also says "no thanks" to organizing their software correctly enough that portupgrade works.... -- -Chuck From owner-freebsd-current@FreeBSD.ORG Tue Apr 26 21:28: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 3F53316A4CE for ; Tue, 26 Apr 2005 21:28:42 +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 A016243D5D for ; Tue, 26 Apr 2005 21:28:41 +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 j3QLSdhs008529; Tue, 26 Apr 2005 14:28:39 -0700 (PDT) (envelope-from marcel@xcllnt.net) In-Reply-To: <200504262222.41463.josemi@redesjm.local> References: <200504261143.55195.josemi@redesjm.local> <20050426194208.GB7773@ns1.xcllnt.net> <200504262222.41463.josemi@redesjm.local> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: Marcel Moolenaar Date: Tue, 26 Apr 2005 14:28:39 -0700 To: Jose M Rodriguez X-Mailer: Apple Mail (2.622) cc: freebsd-current@freebsd.org Subject: Re: rigth crc32 implementation X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 26 Apr 2005 21:28:42 -0000 On Apr 26, 2005, at 1:22 PM, Jose M Rodriguez wrote: > El Martes, 26 de Abril de 2005 21:42, Marcel Moolenaar escribi=F3: >> On Tue, Apr 26, 2005 at 11:43:54AM +0200, Jose M Rodriguez wrote: >>> My first think was use the libkern based one, but I found: >>> sys/linkern/crc32.c >>> >>> - the code may not be endian safe. >> >> It operates on bytes, so it's endian-safe. Note that the uint32_t >> that's returned is not subject to endianness issues: it's always >> in the native byte order. The caller of crc32 needs to byteswap >> if it needs to compare this integral with a CRC that's not in >> the native byte order. >> > > Yes, but this code come from a previous reduction: calculate the table > from a xor/shift bit oriented alg. True, but doesn't that imply that the reduction is endian-independent? There's no big end and/or little end to a bit, so to speak. The values in the table are the result of mathematical calculations, which by definition do not depend on the endianness of the machine that was used to compute them. Yes, the in-memory representation of those values do differ but that's not the issue. Or am I missing something (possibly very obvious)? > Looking at sys/net/if_ethersubr.c ether_crc32_be() & ether_crc32_le(),=20= > I > became to doubt if we need two tables, with bitesex based #ifs. I think those are =042 different algorithms altogether. As far as I can tell, there's no need for it. A shift-right on a little-endian box yields the same effect as a shift-right on a big-endian box. It effectively divides the value by two. That you won't achieve if the shift-right moves the bits towards the most-significant bit, right? So why does one do a shift-right when the other does a shift-left? Why does one define the carry as the least-significant bit and the other as the most-significant bit? Again: math has never been my strongest ability, so it's possible that I simply have a mathematical cross-wire in my head preventing me from thinking mathematically clearly :-) --=20 Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net From owner-freebsd-current@FreeBSD.ORG Tue Apr 26 21:47: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 2282E16A4CF for ; Tue, 26 Apr 2005 21:47:51 +0000 (GMT) Received: from 62-15-211-171.inversas.jazztel.es (62-15-211-171.inversas.jazztel.es [62.15.211.171]) by mx1.FreeBSD.org (Postfix) with ESMTP id 996C643D48 for ; Tue, 26 Apr 2005 21:47:49 +0000 (GMT) (envelope-from josemi@freebsd.jazztel.es) Received: from redesjm.local (orion.redesjm.local [192.168.254.16]) j3QLlfVg022606; Tue, 26 Apr 2005 23:47:42 +0200 (CEST) (envelope-from josemi@redesjm.local) Received: from localhost (localhost [[UNIX: localhost]]) by redesjm.local (8.13.3/8.13.3/Submit) id j3QLle4i081349; Tue, 26 Apr 2005 23:47:40 +0200 (CEST) (envelope-from josemi@redesjm.local) From: Jose M Rodriguez To: Marcel Moolenaar Date: Tue, 26 Apr 2005 23:47:38 +0200 User-Agent: KMail/1.8 References: <200504261143.55195.josemi@redesjm.local> <200504262222.41463.josemi@redesjm.local> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200504262347.39919.josemi@redesjm.local> X-AntiVirus: checked by AntiVir Milter (version: 1.1.0-3; AVE: 6.30.0.7; VDF: 6.30.0.116; host: antares.redesjm.local) cc: freebsd-current@freebsd.org cc: Jose M Rodriguez Subject: Re: rigth crc32 implementation X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 26 Apr 2005 21:47:51 -0000 El Martes, 26 de Abril de 2005 23:28, Marcel Moolenaar escribi=F3: > On Apr 26, 2005, at 1:22 PM, Jose M Rodriguez wrote: > > El Martes, 26 de Abril de 2005 21:42, Marcel Moolenaar escribi=F3: > >> On Tue, Apr 26, 2005 at 11:43:54AM +0200, Jose M Rodriguez wrote: > >>> My first think was use the libkern based one, but I found: > >>> sys/linkern/crc32.c > >>> > >>> - the code may not be endian safe. > >> > >> It operates on bytes, so it's endian-safe. Note that the uint32_t > >> that's returned is not subject to endianness issues: it's always > >> in the native byte order. The caller of crc32 needs to byteswap > >> if it needs to compare this integral with a CRC that's not in > >> the native byte order. > > > > Yes, but this code come from a previous reduction: calculate the > > table from a xor/shift bit oriented alg. > > True, but doesn't that imply that the reduction is > endian-independent? There's no big end and/or little end to a bit, so > to speak. The values in the table are the result of mathematical > calculations, which by definition do not depend on the endianness of > the machine that was used to compute them. Yes, the in-memory > representation of those values do differ but that's not the issue. > > Or am I missing something (possibly very obvious)? > > > Looking at sys/net/if_ethersubr.c ether_crc32_be() & > > ether_crc32_le(), I > > became to doubt if we need two tables, with bitesex based #ifs. > > I think those are =042 different algorithms altogether. As far as I can > tell, there's no need for it. A shift-right on a little-endian box > yields the same effect as a shift-right on a big-endian box. It > effectively divides the value by two. That you won't achieve if the > shift-right moves the bits towards the most-significant bit, right? > > So why does one do a shift-right when the other does a shift-left? > Why does one define the carry as the least-significant bit and the > other as the most-significant bit? > > Again: math has never been my strongest ability, so it's possible > that I simply have a mathematical cross-wire in my head preventing > me from thinking mathematically clearly :-) I think so. Also, I found no driver use both, and we have ether drivers=20 that works in all platforms. So this will cover diff between the=20 system and the chip. This make sense. So, what about add those 2/3 functions. I'll prefer this to carry=20 another private version of crc32. =2D- josemi From owner-freebsd-current@FreeBSD.ORG Tue Apr 26 22:00: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 4545516A4CE for ; Tue, 26 Apr 2005 22:00:22 +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 019C343D4C for ; Tue, 26 Apr 2005 22:00:22 +0000 (GMT) (envelope-from marcel@xcllnt.net) Received: from ns1.xcllnt.net (localhost [127.0.0.1]) by ns1.xcllnt.net (8.13.3/8.13.3) with ESMTP id j3QM0K1r008679; Tue, 26 Apr 2005 15:00:20 -0700 (PDT) (envelope-from marcel@ns1.xcllnt.net) Received: (from marcel@localhost) by ns1.xcllnt.net (8.13.3/8.13.3/Submit) id j3QM0Kmk008678; Tue, 26 Apr 2005 15:00:20 -0700 (PDT) (envelope-from marcel) Date: Tue, 26 Apr 2005 15:00:20 -0700 From: Marcel Moolenaar To: Jose M Rodriguez Message-ID: <20050426220020.GA8621@ns1.xcllnt.net> References: <200504261143.55195.josemi@redesjm.local> <200504262222.41463.josemi@redesjm.local> <200504262347.39919.josemi@redesjm.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200504262347.39919.josemi@redesjm.local> User-Agent: Mutt/1.4.2.1i cc: freebsd-current@freebsd.org Subject: Re: rigth crc32 implementation X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 26 Apr 2005 22:00:22 -0000 On Tue, Apr 26, 2005 at 11:47:38PM +0200, Jose M Rodriguez wrote: > > So, what about add those 2/3 functions. I'll prefer this to carry > another private version of crc32. I'll add crc32_raw() and rewrite the existing crc32() to use it. Give me a day or so. I'd like to have at least crc32() inlined. Maybe crc32_raw() as well. Both are trivial functions and there may be an advantage to have them inlined. If only to remove the performance argument against unification. FYI, -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net From owner-freebsd-current@FreeBSD.ORG Tue Apr 26 22:02: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 63DB216A4CE for ; Tue, 26 Apr 2005 22:02:55 +0000 (GMT) Received: from mail25.sea5.speakeasy.net (mail25.sea5.speakeasy.net [69.17.117.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1D79A43D4C for ; Tue, 26 Apr 2005 22:02:55 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 20451 invoked from network); 26 Apr 2005 22:02:54 -0000 Received: from server.baldwin.cx ([216.27.160.63]) (envelope-sender )AES256-SHA encrypted SMTP for ; 26 Apr 2005 22:02:54 -0000 Received: from roboboy.corp.weather.com (gw1.twc.weather.com [216.133.140.1]) (authenticated bits=0) by server.baldwin.cx (8.13.1/8.13.1) with ESMTP id j3QM2lHM035631; Tue, 26 Apr 2005 18:02:47 -0400 (EDT) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: freebsd-current@FreeBSD.org Date: Tue, 26 Apr 2005 17:37:33 -0400 User-Agent: KMail/1.8 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200504261737.34725.jhb@FreeBSD.org> X-Spam-Status: No, score=-102.8 required=4.2 tests=ALL_TRUSTED, USER_IN_WHITELIST autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on server.baldwin.cx cc: Daniel Eriksson 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: Tue, 26 Apr 2005 22:02:55 -0000 On Saturday 16 April 2005 06:11 pm, Daniel Eriksson wrote: > 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 Did Sam's recent fixes to taskqueues fix this panic for you? -- 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 26 22: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 CABEC16A4CE for ; Tue, 26 Apr 2005 22:06:03 +0000 (GMT) Received: from 62-15-211-171.inversas.jazztel.es (62-15-211-171.inversas.jazztel.es [62.15.211.171]) by mx1.FreeBSD.org (Postfix) with ESMTP id CB9BD43D2F for ; Tue, 26 Apr 2005 22:06:02 +0000 (GMT) (envelope-from josemi@freebsd.jazztel.es) Received: from redesjm.local (orion.redesjm.local [192.168.254.16]) j3QM5wED022664; Wed, 27 Apr 2005 00:05:58 +0200 (CEST) (envelope-from josemi@redesjm.local) Received: from localhost (localhost [[UNIX: localhost]]) by redesjm.local (8.13.3/8.13.3/Submit) id j3QM5uxN021047; Wed, 27 Apr 2005 00:05:56 +0200 (CEST) (envelope-from josemi@redesjm.local) From: Jose M Rodriguez To: Marcel Moolenaar Date: Wed, 27 Apr 2005 00:05:54 +0200 User-Agent: KMail/1.8 References: <200504261143.55195.josemi@redesjm.local> <200504262347.39919.josemi@redesjm.local> <20050426220020.GA8621@ns1.xcllnt.net> In-Reply-To: <20050426220020.GA8621@ns1.xcllnt.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200504270005.56024.josemi@redesjm.local> X-AntiVirus: checked by AntiVir Milter (version: 1.1.0-3; AVE: 6.30.0.7; VDF: 6.30.0.116; host: antares.redesjm.local) cc: freebsd-current@freebsd.org cc: Jose M Rodriguez Subject: Re: rigth crc32 implementation X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 26 Apr 2005 22:06:03 -0000 El Mi=E9rcoles, 27 de Abril de 2005 00:00, Marcel Moolenaar escribi=F3: > On Tue, Apr 26, 2005 at 11:47:38PM +0200, Jose M Rodriguez wrote: > > So, what about add those 2/3 functions. I'll prefer this to carry > > another private version of crc32. > > I'll add crc32_raw() and rewrite the existing crc32() to use it. > Give me a day or so. I'd like to have at least crc32() inlined. > Maybe crc32_raw() as well. Both are trivial functions and there > may be an advantage to have them inlined. If only to remove the > performance argument against unification. > > FYI, NOPE, I still have things in my TODO for a month or so. =2D- josemi From owner-freebsd-current@FreeBSD.ORG Tue Apr 26 22:16: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 878BB16A4CE for ; Tue, 26 Apr 2005 22:16:20 +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 55DB443D48 for ; Tue, 26 Apr 2005 22:16:20 +0000 (GMT) (envelope-from marcel@xcllnt.net) Received: from ns1.xcllnt.net (localhost [127.0.0.1]) by ns1.xcllnt.net (8.13.3/8.13.3) with ESMTP id j3QMGCdF008804; Tue, 26 Apr 2005 15:16:12 -0700 (PDT) (envelope-from marcel@ns1.xcllnt.net) Received: (from marcel@localhost) by ns1.xcllnt.net (8.13.3/8.13.3/Submit) id j3QMGCYv008803; Tue, 26 Apr 2005 15:16:12 -0700 (PDT) (envelope-from marcel) Date: Tue, 26 Apr 2005 15:16:12 -0700 From: Marcel Moolenaar To: Jose M Rodriguez Message-ID: <20050426221612.GC8621@ns1.xcllnt.net> References: <200504261143.55195.josemi@redesjm.local> <200504262347.39919.josemi@redesjm.local> <20050426220020.GA8621@ns1.xcllnt.net> <200504270005.56024.josemi@redesjm.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200504270005.56024.josemi@redesjm.local> User-Agent: Mutt/1.4.2.1i cc: freebsd-current@freebsd.org Subject: Re: rigth crc32 implementation X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 26 Apr 2005 22:16:20 -0000 On Wed, Apr 27, 2005 at 12:05:54AM +0200, Jose M Rodriguez wrote: > > > > I'll add crc32_raw() and rewrite the existing crc32() to use it. > > Give me a day or so. I'd like to have at least crc32() inlined. > > Maybe crc32_raw() as well. Both are trivial functions and there > > may be an advantage to have them inlined. If only to remove the > > performance argument against unification. > > > > NOPE, I still have things in my TODO for a month or so. Ok, we officially have a disconnect now. What do you mean with having things in your TODO list for a month and why does that result in you disagreeing with my proposal and the change I'll be making to FreeBSD on your behalf? Thanks, -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net From owner-freebsd-current@FreeBSD.ORG Tue Apr 26 22:19: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 3F61816A4CE for ; Tue, 26 Apr 2005 22:19:31 +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 000B743D46 for ; Tue, 26 Apr 2005 22:19:30 +0000 (GMT) (envelope-from marcel@xcllnt.net) Received: from ns1.xcllnt.net (localhost [127.0.0.1]) by ns1.xcllnt.net (8.13.3/8.13.3) with ESMTP id j3QMJMlm008817; Tue, 26 Apr 2005 15:19:22 -0700 (PDT) (envelope-from marcel@ns1.xcllnt.net) Received: (from marcel@localhost) by ns1.xcllnt.net (8.13.3/8.13.3/Submit) id j3QMJM5N008816; Tue, 26 Apr 2005 15:19:22 -0700 (PDT) (envelope-from marcel) Date: Tue, 26 Apr 2005 15:19:22 -0700 From: Marcel Moolenaar To: Sam Leffler Message-ID: <20050426221922.GD8621@ns1.xcllnt.net> References: <200504261143.55195.josemi@redesjm.local> <20050426194208.GB7773@ns1.xcllnt.net> <426E9E1C.6020609@errno.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <426E9E1C.6020609@errno.com> User-Agent: Mutt/1.4.2.1i cc: freebsd-current@freebsd.org cc: Jose M Rodriguez Subject: Re: rigth crc32 implementation X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 26 Apr 2005 22:19:31 -0000 On Tue, Apr 26, 2005 at 01:01:32PM -0700, Sam Leffler wrote: > > Note also there is CRC32 code of this sort in WEP and TKIP crypto > modules in the net80211 support. Sam, Given the seperation of crc32() into crc32_raw() and crc32(), with either crc32() only or otherwise both functions inlined, are there any obstacles preventing the 802.11 code from using the ones in src/sys/libkern? Thanks, -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net From owner-freebsd-current@FreeBSD.ORG Tue Apr 26 22:26: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 BDBC716A4CE for ; Tue, 26 Apr 2005 22:26:45 +0000 (GMT) Received: from 62-15-211-171.inversas.jazztel.es (62-15-211-171.inversas.jazztel.es [62.15.211.171]) by mx1.FreeBSD.org (Postfix) with ESMTP id DD62343D2F for ; Tue, 26 Apr 2005 22:26:44 +0000 (GMT) (envelope-from josemi@freebsd.jazztel.es) Received: from redesjm.local (orion.redesjm.local [192.168.254.16]) j3QMQgSJ022707; Wed, 27 Apr 2005 00:26:42 +0200 (CEST) (envelope-from josemi@redesjm.local) Received: from localhost (localhost [[UNIX: localhost]]) by redesjm.local (8.13.3/8.13.3/Submit) id j3QMQgpq049642; Wed, 27 Apr 2005 00:26:42 +0200 (CEST) (envelope-from josemi@redesjm.local) From: Jose M Rodriguez To: Marcel Moolenaar Date: Wed, 27 Apr 2005 00:26:40 +0200 User-Agent: KMail/1.8 References: <200504261143.55195.josemi@redesjm.local> <200504270005.56024.josemi@redesjm.local> <20050426221612.GC8621@ns1.xcllnt.net> In-Reply-To: <20050426221612.GC8621@ns1.xcllnt.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200504270026.41851.josemi@redesjm.local> X-AntiVirus: checked by AntiVir Milter (version: 1.1.0-3; AVE: 6.30.0.7; VDF: 6.30.0.116; host: antares.redesjm.local) cc: freebsd-current@freebsd.org cc: Jose M Rodriguez Subject: Re: rigth crc32 implementation X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 26 Apr 2005 22:26:45 -0000 El Mi=E9rcoles, 27 de Abril de 2005 00:16, Marcel Moolenaar escribi=F3: > On Wed, Apr 27, 2005 at 12:05:54AM +0200, Jose M Rodriguez wrote: > > > I'll add crc32_raw() and rewrite the existing crc32() to use it. > > > Give me a day or so. I'd like to have at least crc32() inlined. > > > Maybe crc32_raw() as well. Both are trivial functions and there > > > may be an advantage to have them inlined. If only to remove the > > > performance argument against unification. > > > > NOPE, I still have things in my TODO for a month or so. > > Ok, we officially have a disconnect now. What do you mean with having > things in your TODO list for a month and why does that result in you > disagreeing with my proposal and the change I'll be making to FreeBSD > on your behalf? > > Thanks, Sorry, I only point you have the time you need to make this. I'm still working in merge pppoe support to sppp and integrate all this=20 with atm frame processing. Or going to netgraph (and lost xBSD support). To me, this well be a moth. =2D- josemi From owner-freebsd-current@FreeBSD.ORG Tue Apr 26 22:37: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 60DE116A4CE; Tue, 26 Apr 2005 22:37:45 +0000 (GMT) Received: from pne-smtpout1-sn1.fre.skanova.net (pne-smtpout1-sn1.fre.skanova.net [81.228.11.98]) by mx1.FreeBSD.org (Postfix) with ESMTP id D974E43D54; Tue, 26 Apr 2005 22:37:44 +0000 (GMT) (envelope-from daniel_k_eriksson@telia.com) Received: from sentinel (195.198.193.104) by pne-smtpout1-sn1.fre.skanova.net (7.1.026.7) id 42650A3B001EB5DD; Wed, 27 Apr 2005 00:37:43 +0200 From: "Daniel Eriksson" To: Date: Wed, 27 Apr 2005 00:37:38 +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 In-Reply-To: <200504261737.34725.jhb@FreeBSD.org> Thread-Index: AcVKq7NszDdH1D1FT+aX/kMVs188lwAAHkUg cc: 'John Baldwin' 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: Tue, 26 Apr 2005 22:37:45 -0000 John Baldwin wrote: > Did Sam's recent fixes to taskqueues fix this panic for you? Possibly. Right after the streak of crashes between the 8th and 11th this month I reverted back to running CURRENT as of 2005.03.11.12.00.00. I went back to daily or bi-daily upgrades on the 18th (8 days ago), and so far I've had no panics or other problems. However, because of a space shortage the usage pattern of the server has been slightly different from what it usually is. The difference is that the amount of write accesses to nullfs mounts have been a lot lower than usual. A hardware upgrade later this week will bring back the old usage pattern, but hopefully that will just confirm that the bug is no longer present (or that it lost its sting). /Daniel Eriksson From owner-freebsd-current@FreeBSD.ORG Tue Apr 26 22:49: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 407EA16A4CE for ; Tue, 26 Apr 2005 22:49:06 +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 B4A7143D41 for ; Tue, 26 Apr 2005 22:49:05 +0000 (GMT) (envelope-from marcel@xcllnt.net) Received: from ns1.xcllnt.net (localhost [127.0.0.1]) by ns1.xcllnt.net (8.13.3/8.13.3) with ESMTP id j3QMn3BF037092; Tue, 26 Apr 2005 15:49:03 -0700 (PDT) (envelope-from marcel@ns1.xcllnt.net) Received: (from marcel@localhost) by ns1.xcllnt.net (8.13.3/8.13.3/Submit) id j3QMn3Bw037091; Tue, 26 Apr 2005 15:49:03 -0700 (PDT) (envelope-from marcel) Date: Tue, 26 Apr 2005 15:49:03 -0700 From: Marcel Moolenaar To: Jose M Rodriguez Message-ID: <20050426224903.GA37052@ns1.xcllnt.net> References: <200504261143.55195.josemi@redesjm.local> <200504270005.56024.josemi@redesjm.local> <20050426221612.GC8621@ns1.xcllnt.net> <200504270026.41851.josemi@redesjm.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200504270026.41851.josemi@redesjm.local> User-Agent: Mutt/1.4.2.1i cc: freebsd-current@freebsd.org Subject: Re: rigth crc32 implementation X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 26 Apr 2005 22:49:06 -0000 On Wed, Apr 27, 2005 at 12:26:40AM +0200, Jose M Rodriguez wrote: > El Mi?rcoles, 27 de Abril de 2005 00:16, Marcel Moolenaar escribi?: > > On Wed, Apr 27, 2005 at 12:05:54AM +0200, Jose M Rodriguez wrote: > > > > I'll add crc32_raw() and rewrite the existing crc32() to use it. > > > > Give me a day or so. I'd like to have at least crc32() inlined. > > > > Maybe crc32_raw() as well. Both are trivial functions and there > > > > may be an advantage to have them inlined. If only to remove the > > > > performance argument against unification. > > > > > > NOPE, I still have things in my TODO for a month or so. > > > > Ok, we officially have a disconnect now. What do you mean with having > > things in your TODO list for a month and why does that result in you > > disagreeing with my proposal and the change I'll be making to FreeBSD > > on your behalf? > > > > Thanks, > > Sorry, > > I only point you have the time you need to make this. Ok, I see. Thanks for your concern. The change is trivial and since the issue has come up, it's best to deal with it right away. It'll be forgotten otherwise and you have to raise the issue again when you're good and ready for it. Also, the sooner it's in -CURRENT, the better the chances someone picks takes this a step further and works on the unification of all crc32 implementations. There is awareness now and I don't expect it to stick in peoples mind for longer than a couple of days. -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net From owner-freebsd-current@FreeBSD.ORG Tue Apr 26 22:52: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 AF30B16A4CE for ; Tue, 26 Apr 2005 22:52:50 +0000 (GMT) Received: from 62-15-211-171.inversas.jazztel.es (62-15-211-171.inversas.jazztel.es [62.15.211.171]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7F92E43D1D for ; Tue, 26 Apr 2005 22:52:49 +0000 (GMT) (envelope-from josemi@freebsd.jazztel.es) Received: from redesjm.local (orion.redesjm.local [192.168.254.16]) j3QMqY9r022758; Wed, 27 Apr 2005 00:52:34 +0200 (CEST) (envelope-from josemi@redesjm.local) Received: from localhost (localhost [[UNIX: localhost]]) by redesjm.local (8.13.3/8.13.3/Submit) id j3QMqX4m058550; Wed, 27 Apr 2005 00:52:33 +0200 (CEST) (envelope-from josemi@redesjm.local) From: Jose M Rodriguez To: freebsd-current@freebsd.org Date: Wed, 27 Apr 2005 00:52:31 +0200 User-Agent: KMail/1.8 References: <200504261143.55195.josemi@redesjm.local> <426E9E1C.6020609@errno.com> <20050426221922.GD8621@ns1.xcllnt.net> In-Reply-To: <20050426221922.GD8621@ns1.xcllnt.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200504270052.33158.josemi@redesjm.local> X-AntiVirus: checked by AntiVir Milter (version: 1.1.0-3; AVE: 6.30.0.7; VDF: 6.30.0.116; host: antares.redesjm.local) cc: Sam Leffler cc: Jose M Rodriguez cc: Marcel Moolenaar Subject: Re: rigth crc32 implementation X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 26 Apr 2005 22:52:50 -0000 El Mi=E9rcoles, 27 de Abril de 2005 00:19, Marcel Moolenaar escribi=F3: > On Tue, Apr 26, 2005 at 01:01:32PM -0700, Sam Leffler wrote: > > Note also there is CRC32 code of this sort in WEP and TKIP crypto > > modules in the net80211 support. > > Sam, > > Given the seperation of crc32() into crc32_raw() and crc32(), with > either crc32() only or otherwise both functions inlined, are there > any obstacles preventing the 802.11 code from using the ones in > src/sys/libkern? > > Thanks, at last, sys/dev/if_sbni have another implementation of what seems to be=20 a crc32 alg. geom_gpt also uses this, but the libkern version. =2D- josemi =2D- josemi From owner-freebsd-current@FreeBSD.ORG Wed Apr 27 00:51: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 9A3E616A4CE; Wed, 27 Apr 2005 00:51:17 +0000 (GMT) Received: from mail.sorbs.net (news.sorbs.net [203.15.51.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id EA2F943D5D; Wed, 27 Apr 2005 00:51:16 +0000 (GMT) (envelope-from matthew@uq.edu.au) Received: from [130.102.152.118] (stealthd.its.uq.edu.au [130.102.152.118]) by nemesis.sorbs.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0IFK00I0DYE7JF@nemesis.sorbs.net>; Wed, 27 Apr 2005 10:51:43 +1000 (EST) Date: Wed, 27 Apr 2005 10:50:02 +1000 From: Matthew Sullivan In-reply-to: <20050426104642.GJ25563@elvis.mu.org> To: Maxime Henrion Message-id: <426EE1BA.5030700@uq.edu.au> MIME-version: 1.0 Content-type: multipart/signed; boundary=------------ms020706000209030902020409; micalg=sha1; protocol="application/x-pkcs7-signature" X-Accept-Language: en User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041231 References: <4267A1CF.3080903@uq.edu.au> <20050422190208.M68772@lexi.siliconlandmark.com> <426C93AC.3030907@root.org> <20050425200601.I42718@carver.gumbysoft.com> <426DB58B.5020608@uq.edu.au> <20050425204148.H43358@carver.gumbysoft.com> <20050426104642.GJ25563@elvis.mu.org> cc: freebsd-current@freebsd.org cc: Nate Lawson Subject: Re: SMP on Compaq DL380 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 27 Apr 2005 00:51:17 -0000 This is a cryptographically signed message in MIME format. --------------ms020706000209030902020409 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Maxime Henrion wrote: >Doug White wrote: > > >> >>This appears to be the latest BIOS. Some Compaq systems are known to >>generate bogus MPTables and such when configured to run Windows. You might >>poke around the BIOS Setup and see if there is an "OS Type" field that can >>be set to "SCO UNIX" or "Other" (not in PnP setup probably). >> >> > >Yeah, I've seen DL380 boxes that needed "Linux" as the OS type or the >BIOS wouldn't generate an MPTable with both CPUs. > > Apologies for any wasted time.... This was the answer.... In detail, this morning I went back into the Compaq BIOS configuration tool, and the OS's settable were (amongst others): OTHER UNIX I had set to 'UNIX'.... I changed to 'OTHER' rebooted and .. still the same. There was no mention of 'LINUX' ... frustrated (and sure I saw "LINUX" in the config previously) I did the following... 1/. Powered Down 2/ Undocked all SCSI drives (just popped them out of the connectors) 3/ Booted the Config utility 4/ Selected 'Erase System' 5/ Power cycled (as instructed) 6/ Booted back into the 'Smartstart' config utility. 7/ Followed the 'Manual Configuration and OS install' 8/ Selected "LINUX" (which was now on this menu. 9/ Went to the Smart Array Util, and exited immediately, which caused a spontaneous reboot. 10/ Powered Down 11/ Docked all the drives. 12/ Powered up, and booted back into the Smart Start util. 13/ Noticed the RAID 5 array and config was self configured by the controller. 14/ Checked all settings in the Configutil - noticed "LINUX" was still displayed as the OS type. 15/ Checked the Array config (very impressed that it worked out the config itself) 16/ Exited Util (no save, none necessary). 17/ Power cycled. 18/ Removed smart start CD. 19/ booted FreeBSD and saved the collected data in a similar place: http://scorpion.sorbs.net/SMP/after-erase/ ...and as you can see, I have 2 CPU's and this time they are detected correctly (including the 'odd' CPU type that was reported by the previous config).... For this I hope someone will create a FAQ for old Compaq's, and I'm posting this back to the list so that people having similar problems in the future can reference it. Thanks for all your help people. Regards, -- Matthew Sullivan Specialist Systems Programmer Information Technology Services The University of Queensland --------------ms020706000209030902020409 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIG7DCC A3IwggJaoAMCAQICASowDQYJKoZIhvcNAQEEBQAwgaMxCzAJBgNVBAYTAkFVMRMwEQYDVQQI EwpRdWVlbnNsYW5kMREwDwYDVQQHEwhCcmlzYmFuZTElMCMGA1UEChMcVGhlIFVuaXZlcnNp dHkgb2YgUXVlZW5zbGFuZDEoMCYGA1UECxMfSW5mb3JtYXRpb24gVGVjaG5vbG9neSBTZXJ2 aWNlczEbMBkGA1UEAxMSQ2VydGlmaWNhdGUgU2VydmVyMB4XDTA0MDEyMTIzMzYyMVoXDTA2 MDEyMTIzMzYyMVowgbIxCzAJBgNVBAYTAkFVMSUwIwYDVQQKExxUaGUgVW5pdmVyc2l0eSBv ZiBRdWVlbnNsYW5kMScwJQYDVQQLEx5JbmZvcm1hdGlvbiBUZWNub2xvZ3kgU2VydmljZXMx FjAUBgoJkiaJk/IsZAEBEwZjY21hdHQxGTAXBgNVBAMTEE1hdHRoZXcgU3VsbGl2YW4xIDAe BgkqhkiG9w0BCQEWEW1hdHRoZXdAdXEuZWR1LmF1MFwwDQYJKoZIhvcNAQEBBQADSwAwSAJB AJsUfrw/QUqKIzDverWc2F4GFFRZmIeO+bAl+7BM6x/9frMzOtygx4QGb4oQwtOE8Sda1aIs v+yJF3Di9EuUyvMCAwEAAaNoMGYwDgYDVR0PAQH/BAQDAgXgMBEGCWCGSAGG+EIBAQQEAwIF oDAfBgNVHSMEGDAWgBQmqtoyueiWTYZBinvsnzeOWLtUuzAgBgNVHREEGTAXgRVtYXR0aGV3 QGl0cy51cS5lZHUuYXUwDQYJKoZIhvcNAQEEBQADggEBAF2gZrkqZsZlHd4K/+yBN6qrpD61 hctDf7/Eg4jk6DMknEs6nvHMFUMZ4SXvkqPLnHBygTARKAs7qBSLd7mUUBOOQEgk6ovQVY6S 1CDSt3P9O6wjG0K1igtk8v6u7lkQ8p2STXqrOePVINdaucUgBO/IpeUtt9ATl1qvPTWyM/fz oUZsIKeYjNQVEQsuimrZjdbIAFxdl1fggSngUv64wBn8wCssGrPZIZA2lpBBEW1wejoWrDOH IIr+SspGd0i8MovDTMRSvgTERLki17FU/ANilcrSXiODKeIvpXhnQqVScnsoMSZmBmN2QIoG SnBjNK5mYxx5E3v20VOwtP1hVdEwggNyMIICWqADAgECAgEqMA0GCSqGSIb3DQEBBAUAMIGj MQswCQYDVQQGEwJBVTETMBEGA1UECBMKUXVlZW5zbGFuZDERMA8GA1UEBxMIQnJpc2JhbmUx JTAjBgNVBAoTHFRoZSBVbml2ZXJzaXR5IG9mIFF1ZWVuc2xhbmQxKDAmBgNVBAsTH0luZm9y bWF0aW9uIFRlY2hub2xvZ3kgU2VydmljZXMxGzAZBgNVBAMTEkNlcnRpZmljYXRlIFNlcnZl cjAeFw0wNDAxMjEyMzM2MjFaFw0wNjAxMjEyMzM2MjFaMIGyMQswCQYDVQQGEwJBVTElMCMG A1UEChMcVGhlIFVuaXZlcnNpdHkgb2YgUXVlZW5zbGFuZDEnMCUGA1UECxMeSW5mb3JtYXRp b24gVGVjbm9sb2d5IFNlcnZpY2VzMRYwFAYKCZImiZPyLGQBARMGY2NtYXR0MRkwFwYDVQQD ExBNYXR0aGV3IFN1bGxpdmFuMSAwHgYJKoZIhvcNAQkBFhFtYXR0aGV3QHVxLmVkdS5hdTBc MA0GCSqGSIb3DQEBAQUAA0sAMEgCQQCbFH68P0FKiiMw73q1nNheBhRUWZiHjvmwJfuwTOsf /X6zMzrcoMeEBm+KEMLThPEnWtWiLL/siRdw4vRLlMrzAgMBAAGjaDBmMA4GA1UdDwEB/wQE AwIF4DARBglghkgBhvhCAQEEBAMCBaAwHwYDVR0jBBgwFoAUJqraMrnolk2GQYp77J83jli7 VLswIAYDVR0RBBkwF4EVbWF0dGhld0BpdHMudXEuZWR1LmF1MA0GCSqGSIb3DQEBBAUAA4IB AQBdoGa5KmbGZR3eCv/sgTeqq6Q+tYXLQ3+/xIOI5OgzJJxLOp7xzBVDGeEl75Kjy5xwcoEw ESgLO6gUi3e5lFATjkBIJOqL0FWOktQg0rdz/TusIxtCtYoLZPL+ru5ZEPKdkk16qznj1SDX WrnFIATvyKXlLbfQE5darz01sjP386FGbCCnmIzUFRELLopq2Y3WyABcXZdX4IEp4FL+uMAZ /MArLBqz2SGQNpaQQRFtcHo6FqwzhyCK/krKRndIvDKLw0zEUr4ExES5ItexVPwDYpXK0l4j gyniL6V4Z0KlUnJ7KDEmZgZjdkCKBkpwYzSuZmMceRN79tFTsLT9YVXRMYIDQDCCAzwCAQEw gakwgaMxCzAJBgNVBAYTAkFVMRMwEQYDVQQIEwpRdWVlbnNsYW5kMREwDwYDVQQHEwhCcmlz YmFuZTElMCMGA1UEChMcVGhlIFVuaXZlcnNpdHkgb2YgUXVlZW5zbGFuZDEoMCYGA1UECxMf SW5mb3JtYXRpb24gVGVjaG5vbG9neSBTZXJ2aWNlczEbMBkGA1UEAxMSQ2VydGlmaWNhdGUg U2VydmVyAgEqMAkGBSsOAwIaBQCgggItMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ KoZIhvcNAQkFMQ8XDTA1MDQyNzAwNTAwMlowIwYJKoZIhvcNAQkEMRYEFClD+j0188LpWw01 MNF3T/EHcCJZMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIG6BgkrBgEEAYI3EAQx gawwgakwgaMxCzAJBgNVBAYTAkFVMRMwEQYDVQQIEwpRdWVlbnNsYW5kMREwDwYDVQQHEwhC cmlzYmFuZTElMCMGA1UEChMcVGhlIFVuaXZlcnNpdHkgb2YgUXVlZW5zbGFuZDEoMCYGA1UE CxMfSW5mb3JtYXRpb24gVGVjaG5vbG9neSBTZXJ2aWNlczEbMBkGA1UEAxMSQ2VydGlmaWNh dGUgU2VydmVyAgEqMIG8BgsqhkiG9w0BCRACCzGBrKCBqTCBozELMAkGA1UEBhMCQVUxEzAR BgNVBAgTClF1ZWVuc2xhbmQxETAPBgNVBAcTCEJyaXNiYW5lMSUwIwYDVQQKExxUaGUgVW5p dmVyc2l0eSBvZiBRdWVlbnNsYW5kMSgwJgYDVQQLEx9JbmZvcm1hdGlvbiBUZWNobm9sb2d5 IFNlcnZpY2VzMRswGQYDVQQDExJDZXJ0aWZpY2F0ZSBTZXJ2ZXICASowDQYJKoZIhvcNAQEB BQAEQHAA6HepCoJQmdBFemUyK/vP9komjX8y7RgVM3anuJds95WOen03Jd2CHQLLcUpta/UR pmi6yD4NvoO8qrumP/cAAAAAAAA= --------------ms020706000209030902020409-- From owner-freebsd-current@FreeBSD.ORG Wed Apr 27 01:52: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 B831116A4CE; Wed, 27 Apr 2005 01:52:38 +0000 (GMT) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2F5A243D55; Wed, 27 Apr 2005 01:52:38 +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 j3R1qb7X089714; Tue, 26 Apr 2005 21:52:37 -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 j3R1qbFg023591; Tue, 26 Apr 2005 21:52:37 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id D5A6E7306E; Tue, 26 Apr 2005 21:52:36 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050427015236.D5A6E7306E@freebsd-current.sentex.ca> Date: Tue, 26 Apr 2005 21:52:36 -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 alpha/alpha 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, 27 Apr 2005 01:52:38 -0000 TB --- 2005-04-27 01:45:01 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-04-27 01:45:01 - starting CURRENT tinderbox run for alpha/alpha TB --- 2005-04-27 01:45:01 - checking out the source tree TB --- 2005-04-27 01:45:01 - cd /home/tinderbox/CURRENT/alpha/alpha TB --- 2005-04-27 01:45:01 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-04-27 01:51:39 - building world (CFLAGS=-O2 -pipe) TB --- 2005-04-27 01:51:39 - cd /home/tinderbox/CURRENT/alpha/alpha/src TB --- 2005-04-27 01:51:39 - /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 [...] ===> rescue/rescue/ipf/ipnat (clean) rm -f ipnat_y.c ipnat_y.h ipnat_l.c ipnat_l.h y.tab.c y.tab.h ipnat ipnat.o ipnat_y.o ipnat_l.o ipnat.8.gz ipnat.4.gz ipnat.5.gz ipnat.8.cat.gz ipnat.4.cat.gz ipnat.5.cat.gz ===> rescue/rescue/ipf/ippool (clean) rm -f ippool_y.c ippool_y.h ippool_l.c ippool_l.h y.tab.c y.tab.h ippool ippool_y.o ippool_l.o kmem.o ippool.o ippool.5.gz ippool.8.gz ippool.5.cat.gz ippool.8.cat.gz ===> rescue/rescue/ipf/ipresend (clean) rm -f y.tab.c y.tab.h ipresend ipresend.o ip.o resend.o sbpf.o sock.o 44arp.o ipresend.1.gz ipresend.1.cat.gz cd /tinderbox/CURRENT/alpha/alpha/src/rescue/rescue/../../sbin/ipfs && MAKEOBJDIRPREFIX=/home/tinderbox/CURRENT/alpha/alpha/obj/alpha/tinderbox/CURRENT/alpha/alpha/src/rescue/rescue /home/tinderbox/CURRENT/alpha/alpha/obj/tinderbox/CURRENT/alpha/alpha/src/make.i386/make DIRPRFX=rescue/rescue/ipfs/ clean cd: can't cd to /tinderbox/CURRENT/alpha/alpha/src/rescue/rescue/../../sbin/ipfs *** Error code 2 Stop in /tinderbox/CURRENT/alpha/alpha/src/rescue/rescue. *** Error code 1 Stop in /tinderbox/CURRENT/alpha/alpha/src/rescue. *** Error code 1 Stop in /tinderbox/CURRENT/alpha/alpha/src. *** Error code 1 Stop in /tinderbox/CURRENT/alpha/alpha/src. *** Error code 1 Stop in /tinderbox/CURRENT/alpha/alpha/src. TB --- 2005-04-27 01:52:36 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-04-27 01:52:36 - ERROR: failed to build world TB --- 2005-04-27 01:52:36 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Wed Apr 27 01:56: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 203B816A4CE; Wed, 27 Apr 2005 01:56:17 +0000 (GMT) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8C3F743D53; Wed, 27 Apr 2005 01:56:16 +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 j3R1uG5x089906; Tue, 26 Apr 2005 21:56:16 -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 j3R1uGhA040129; Tue, 26 Apr 2005 21:56:16 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id D97987306E; Tue, 26 Apr 2005 21:56:15 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050427015615.D97987306E@freebsd-current.sentex.ca> Date: Tue, 26 Apr 2005 21:56:15 -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 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, 27 Apr 2005 01:56:17 -0000 TB --- 2005-04-27 01:52:37 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-04-27 01:52:37 - starting CURRENT tinderbox run for amd64/amd64 TB --- 2005-04-27 01:52:37 - checking out the source tree TB --- 2005-04-27 01:52:37 - cd /home/tinderbox/CURRENT/amd64/amd64 TB --- 2005-04-27 01:52:37 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-04-27 01:55:18 - building world (CFLAGS=-O2 -pipe) TB --- 2005-04-27 01:55:18 - cd /home/tinderbox/CURRENT/amd64/amd64/src TB --- 2005-04-27 01:55:18 - /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 [...] ===> rescue/rescue/ipf/ipnat (clean) rm -f ipnat_y.c ipnat_y.h ipnat_l.c ipnat_l.h y.tab.c y.tab.h ipnat ipnat.o ipnat_y.o ipnat_l.o ipnat.8.gz ipnat.4.gz ipnat.5.gz ipnat.8.cat.gz ipnat.4.cat.gz ipnat.5.cat.gz ===> rescue/rescue/ipf/ippool (clean) rm -f ippool_y.c ippool_y.h ippool_l.c ippool_l.h y.tab.c y.tab.h ippool ippool_y.o ippool_l.o kmem.o ippool.o ippool.5.gz ippool.8.gz ippool.5.cat.gz ippool.8.cat.gz ===> rescue/rescue/ipf/ipresend (clean) rm -f y.tab.c y.tab.h ipresend ipresend.o ip.o resend.o sbpf.o sock.o 44arp.o ipresend.1.gz ipresend.1.cat.gz cd /tinderbox/CURRENT/amd64/amd64/src/rescue/rescue/../../sbin/ipfs && MAKEOBJDIRPREFIX=/home/tinderbox/CURRENT/amd64/amd64/obj/amd64/tinderbox/CURRENT/amd64/amd64/src/rescue/rescue /home/tinderbox/CURRENT/amd64/amd64/obj/tinderbox/CURRENT/amd64/amd64/src/make.i386/make DIRPRFX=rescue/rescue/ipfs/ clean cd: can't cd to /tinderbox/CURRENT/amd64/amd64/src/rescue/rescue/../../sbin/ipfs *** Error code 2 Stop in /tinderbox/CURRENT/amd64/amd64/src/rescue/rescue. *** Error code 1 Stop in /tinderbox/CURRENT/amd64/amd64/src/rescue. *** 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-27 01:56:15 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-04-27 01:56:15 - ERROR: failed to build world TB --- 2005-04-27 01:56:15 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Wed Apr 27 01: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 0FCC216A4CE for ; Wed, 27 Apr 2005 01:59:50 +0000 (GMT) Received: from crumpet.united-ware.com (ddsl-66-42-172-210.fuse.net [66.42.172.210]) by mx1.FreeBSD.org (Postfix) with ESMTP id 87F3643D55 for ; Wed, 27 Apr 2005 01:59:49 +0000 (GMT) (envelope-from mistry.7@osu.edu) Received: from [192.168.1.100] (adsl-68-75-18-7.dsl.wotnoh.ameritech.net [68.75.18.7]) (authenticated bits=0)j3R1R3jO039396 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Tue, 26 Apr 2005 21:27:04 -0400 (EDT) (envelope-from mistry.7@osu.edu) From: Anish Mistry To: David Leimbach Date: Tue, 26 Apr 2005 22:00:17 -0400 User-Agent: KMail/1.8 References: <17006.19740.605509.984940@roam.psg.com> <200504261135.07833.mistry.7@osu.edu> <5bbfe7d405042618404e7a6521@mail.gmail.com> In-Reply-To: <5bbfe7d405042618404e7a6521@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200504262200.17379.mistry.7@osu.edu> X-Spam-Status: No, hits=0.6 required=5.0 tests=J_CHICKENPOX_37 autolearn=no version=2.64 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on crumpet.united-ware.com cc: Randy Bush cc: freebsd-current@freebsd.org Subject: Re: ule+preempt? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 27 Apr 2005 01:59:50 -0000 On Tuesday 26 April 2005 09:40 pm, David Leimbach wrote: > On 4/26/05, Anish Mistry wrote: > > On Tuesday 26 April 2005 10:15 am, Randy Bush wrote: > > > having been seriously burned, i have avoided ule for some > > > months. i am wondering if the waters have become relatively > > > safe to go to ule with preemption? > > > > I've been running it for few weeks and it seems to be fine for > > now, but YMMV. > > Are you on an SMP box? I have a feeling it's pretty good on a UP > machine > I'm on on UP. Running on SMP will probably reveal the squishy underbelly to which Kris was referring. -- Anish Mistry From owner-freebsd-current@FreeBSD.ORG Wed Apr 27 02:01: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 3B65D16A4CE; Wed, 27 Apr 2005 02:01:30 +0000 (GMT) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9052743D39; Wed, 27 Apr 2005 02:01:29 +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 j3R21Two090165; Tue, 26 Apr 2005 22:01:29 -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 j3R21xiU061220; Tue, 26 Apr 2005 22:01:59 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 1573C7306E; Tue, 26 Apr 2005 22:01:29 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050427020129.1573C7306E@freebsd-current.sentex.ca> Date: Tue, 26 Apr 2005 22:01:29 -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, 27 Apr 2005 02:01:30 -0000 TB --- 2005-04-27 01:56:16 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-04-27 01:56:16 - starting CURRENT tinderbox run for i386/i386 TB --- 2005-04-27 01:56:16 - checking out the source tree TB --- 2005-04-27 01:56:16 - cd /home/tinderbox/CURRENT/i386/i386 TB --- 2005-04-27 01:56:16 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-04-27 02:00:30 - building world (CFLAGS=-O2 -pipe) TB --- 2005-04-27 02:00:30 - cd /home/tinderbox/CURRENT/i386/i386/src TB --- 2005-04-27 02:00: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 [...] ===> rescue/rescue/ipf/ipnat (clean) rm -f ipnat_y.c ipnat_y.h ipnat_l.c ipnat_l.h y.tab.c y.tab.h ipnat ipnat.o ipnat_y.o ipnat_l.o ipnat.8.gz ipnat.4.gz ipnat.5.gz ipnat.8.cat.gz ipnat.4.cat.gz ipnat.5.cat.gz ===> rescue/rescue/ipf/ippool (clean) rm -f ippool_y.c ippool_y.h ippool_l.c ippool_l.h y.tab.c y.tab.h ippool ippool_y.o ippool_l.o kmem.o ippool.o ippool.5.gz ippool.8.gz ippool.5.cat.gz ippool.8.cat.gz ===> rescue/rescue/ipf/ipresend (clean) rm -f y.tab.c y.tab.h ipresend ipresend.o ip.o resend.o sbpf.o sock.o 44arp.o ipresend.1.gz ipresend.1.cat.gz cd /tinderbox/CURRENT/i386/i386/src/rescue/rescue/../../sbin/ipfs && MAKEOBJDIRPREFIX=/home/tinderbox/CURRENT/i386/i386/obj/tinderbox/CURRENT/i386/i386/src/rescue/rescue /home/tinderbox/CURRENT/i386/i386/obj/tinderbox/CURRENT/i386/i386/src/make.i386/make DIRPRFX=rescue/rescue/ipfs/ clean cd: can't cd to /tinderbox/CURRENT/i386/i386/src/rescue/rescue/../../sbin/ipfs *** Error code 2 Stop in /tinderbox/CURRENT/i386/i386/src/rescue/rescue. *** Error code 1 Stop in /tinderbox/CURRENT/i386/i386/src/rescue. *** 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-27 02:01:28 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-04-27 02:01:28 - ERROR: failed to build world TB --- 2005-04-27 02:01:28 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Wed Apr 27 02:05: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 82C2B16A4CE; Wed, 27 Apr 2005 02:05:59 +0000 (GMT) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id F057743D41; Wed, 27 Apr 2005 02:05:58 +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 j3R25w3b099335; Tue, 26 Apr 2005 22:05:58 -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 j3R25wgR085521; Tue, 26 Apr 2005 22:05:58 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 31F117306E; Tue, 26 Apr 2005 22:05:58 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050427020558.31F117306E@freebsd-current.sentex.ca> Date: Tue, 26 Apr 2005 22:05:58 -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 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: Wed, 27 Apr 2005 02:05:59 -0000 TB --- 2005-04-27 02:01:29 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-04-27 02:01:29 - starting CURRENT tinderbox run for i386/pc98 TB --- 2005-04-27 02:01:29 - checking out the source tree TB --- 2005-04-27 02:01:29 - cd /home/tinderbox/CURRENT/i386/pc98 TB --- 2005-04-27 02:01:29 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-04-27 02:04:58 - building world (CFLAGS=-O2 -pipe) TB --- 2005-04-27 02:04:58 - cd /home/tinderbox/CURRENT/i386/pc98/src TB --- 2005-04-27 02:04:58 - /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 [...] ===> rescue/rescue/ipf/ipnat (clean) rm -f ipnat_y.c ipnat_y.h ipnat_l.c ipnat_l.h y.tab.c y.tab.h ipnat ipnat.o ipnat_y.o ipnat_l.o ipnat.8.gz ipnat.4.gz ipnat.5.gz ipnat.8.cat.gz ipnat.4.cat.gz ipnat.5.cat.gz ===> rescue/rescue/ipf/ippool (clean) rm -f ippool_y.c ippool_y.h ippool_l.c ippool_l.h y.tab.c y.tab.h ippool ippool_y.o ippool_l.o kmem.o ippool.o ippool.5.gz ippool.8.gz ippool.5.cat.gz ippool.8.cat.gz ===> rescue/rescue/ipf/ipresend (clean) rm -f y.tab.c y.tab.h ipresend ipresend.o ip.o resend.o sbpf.o sock.o 44arp.o ipresend.1.gz ipresend.1.cat.gz cd /tinderbox/CURRENT/i386/pc98/src/rescue/rescue/../../sbin/ipfs && MAKEOBJDIRPREFIX=/home/tinderbox/CURRENT/i386/pc98/obj/pc98/tinderbox/CURRENT/i386/pc98/src/rescue/rescue /home/tinderbox/CURRENT/i386/pc98/obj/tinderbox/CURRENT/i386/pc98/src/make.i386/make DIRPRFX=rescue/rescue/ipfs/ clean cd: can't cd to /tinderbox/CURRENT/i386/pc98/src/rescue/rescue/../../sbin/ipfs *** Error code 2 Stop in /tinderbox/CURRENT/i386/pc98/src/rescue/rescue. *** Error code 1 Stop in /tinderbox/CURRENT/i386/pc98/src/rescue. *** 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-27 02:05:58 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-04-27 02:05:58 - ERROR: failed to build world TB --- 2005-04-27 02:05:58 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Wed Apr 27 02:10: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 174AE16A4CE; Wed, 27 Apr 2005 02:10:14 +0000 (GMT) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8425C43D41; Wed, 27 Apr 2005 02:10:13 +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 j3R2ACww099504; Tue, 26 Apr 2005 22:10:12 -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 j3R2ADoV006233; Tue, 26 Apr 2005 22:10:13 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id F17EB7306E; Tue, 26 Apr 2005 22:10:12 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050427021012.F17EB7306E@freebsd-current.sentex.ca> Date: Tue, 26 Apr 2005 22:10:12 -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: Wed, 27 Apr 2005 02:10:14 -0000 TB --- 2005-04-27 02:05:58 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-04-27 02:05:58 - starting CURRENT tinderbox run for ia64/ia64 TB --- 2005-04-27 02:05:58 - checking out the source tree TB --- 2005-04-27 02:05:58 - cd /home/tinderbox/CURRENT/ia64/ia64 TB --- 2005-04-27 02:05:58 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-04-27 02:09:14 - building world (CFLAGS=-O2 -pipe) TB --- 2005-04-27 02:09:14 - cd /home/tinderbox/CURRENT/ia64/ia64/src TB --- 2005-04-27 02:09:14 - /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 [...] ===> rescue/rescue/ipf/ipnat (clean) rm -f ipnat_y.c ipnat_y.h ipnat_l.c ipnat_l.h y.tab.c y.tab.h ipnat ipnat.o ipnat_y.o ipnat_l.o ipnat.8.gz ipnat.4.gz ipnat.5.gz ipnat.8.cat.gz ipnat.4.cat.gz ipnat.5.cat.gz ===> rescue/rescue/ipf/ippool (clean) rm -f ippool_y.c ippool_y.h ippool_l.c ippool_l.h y.tab.c y.tab.h ippool ippool_y.o ippool_l.o kmem.o ippool.o ippool.5.gz ippool.8.gz ippool.5.cat.gz ippool.8.cat.gz ===> rescue/rescue/ipf/ipresend (clean) rm -f y.tab.c y.tab.h ipresend ipresend.o ip.o resend.o sbpf.o sock.o 44arp.o ipresend.1.gz ipresend.1.cat.gz cd /tinderbox/CURRENT/ia64/ia64/src/rescue/rescue/../../sbin/ipfs && MAKEOBJDIRPREFIX=/home/tinderbox/CURRENT/ia64/ia64/obj/ia64/tinderbox/CURRENT/ia64/ia64/src/rescue/rescue /home/tinderbox/CURRENT/ia64/ia64/obj/tinderbox/CURRENT/ia64/ia64/src/make.i386/make DIRPRFX=rescue/rescue/ipfs/ clean cd: can't cd to /tinderbox/CURRENT/ia64/ia64/src/rescue/rescue/../../sbin/ipfs *** Error code 2 Stop in /tinderbox/CURRENT/ia64/ia64/src/rescue/rescue. *** Error code 1 Stop in /tinderbox/CURRENT/ia64/ia64/src/rescue. *** Error code 1 Stop in /tinderbox/CURRENT/ia64/ia64/src. *** Error code 1 Stop in /tinderbox/CURRENT/ia64/ia64/src. *** Error code 1 Stop in /tinderbox/CURRENT/ia64/ia64/src. TB --- 2005-04-27 02:10:12 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-04-27 02:10:12 - ERROR: failed to build world TB --- 2005-04-27 02:10:12 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Wed Apr 27 02:15: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 F053216A4CE; Wed, 27 Apr 2005 02:14:59 +0000 (GMT) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6364343D41; Wed, 27 Apr 2005 02:14:59 +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 j3R2ExQJ090655; Tue, 26 Apr 2005 22:14:59 -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 j3R2FTsQ068604; Tue, 26 Apr 2005 22:15:29 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id DAAA57306E; Tue, 26 Apr 2005 22:14:58 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050427021458.DAAA57306E@freebsd-current.sentex.ca> Date: Tue, 26 Apr 2005 22:14:58 -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: Wed, 27 Apr 2005 02:15:00 -0000 TB --- 2005-04-27 02:10:13 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-04-27 02:10:13 - starting CURRENT tinderbox run for powerpc/powerpc TB --- 2005-04-27 02:10:13 - checking out the source tree TB --- 2005-04-27 02:10:13 - cd /home/tinderbox/CURRENT/powerpc/powerpc TB --- 2005-04-27 02:10:13 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-04-27 02:14:02 - building world (CFLAGS=-O2 -pipe) TB --- 2005-04-27 02:14:02 - cd /home/tinderbox/CURRENT/powerpc/powerpc/src TB --- 2005-04-27 02:14: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 [...] ===> rescue/rescue/ipf/ipnat (clean) rm -f ipnat_y.c ipnat_y.h ipnat_l.c ipnat_l.h y.tab.c y.tab.h ipnat ipnat.o ipnat_y.o ipnat_l.o ipnat.8.gz ipnat.4.gz ipnat.5.gz ipnat.8.cat.gz ipnat.4.cat.gz ipnat.5.cat.gz ===> rescue/rescue/ipf/ippool (clean) rm -f ippool_y.c ippool_y.h ippool_l.c ippool_l.h y.tab.c y.tab.h ippool ippool_y.o ippool_l.o kmem.o ippool.o ippool.5.gz ippool.8.gz ippool.5.cat.gz ippool.8.cat.gz ===> rescue/rescue/ipf/ipresend (clean) rm -f y.tab.c y.tab.h ipresend ipresend.o ip.o resend.o sbpf.o sock.o 44arp.o ipresend.1.gz ipresend.1.cat.gz cd /tinderbox/CURRENT/powerpc/powerpc/src/rescue/rescue/../../sbin/ipfs && MAKEOBJDIRPREFIX=/home/tinderbox/CURRENT/powerpc/powerpc/obj/powerpc/tinderbox/CURRENT/powerpc/powerpc/src/rescue/rescue /home/tinderbox/CURRENT/powerpc/powerpc/obj/tinderbox/CURRENT/powerpc/powerpc/src/make.i386/make DIRPRFX=rescue/rescue/ipfs/ clean cd: can't cd to /tinderbox/CURRENT/powerpc/powerpc/src/rescue/rescue/../../sbin/ipfs *** Error code 2 Stop in /tinderbox/CURRENT/powerpc/powerpc/src/rescue/rescue. *** Error code 1 Stop in /tinderbox/CURRENT/powerpc/powerpc/src/rescue. *** Error code 1 Stop in /tinderbox/CURRENT/powerpc/powerpc/src. *** Error code 1 Stop in /tinderbox/CURRENT/powerpc/powerpc/src. *** Error code 1 Stop in /tinderbox/CURRENT/powerpc/powerpc/src. TB --- 2005-04-27 02:14:58 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-04-27 02:14:58 - ERROR: failed to build world TB --- 2005-04-27 02:14:58 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Wed Apr 27 02:19: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 76E8E16A4CE for ; Wed, 27 Apr 2005 02:19:42 +0000 (GMT) Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id F20F643D48 for ; Wed, 27 Apr 2005 02:19:41 +0000 (GMT) (envelope-from sam@errno.com) Received: from [66.127.85.92] ([66.127.85.92]) (authenticated bits=0) by ebb.errno.com (8.12.9/8.12.6) with ESMTP id j3R2JXms072698 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 Apr 2005 19:19:35 -0700 (PDT) (envelope-from sam@errno.com) Message-ID: <426EF6BD.6030207@errno.com> Date: Tue, 26 Apr 2005 19:19:41 -0700 From: Sam Leffler Organization: Errno Consulting User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Marcel Moolenaar References: <200504261143.55195.josemi@redesjm.local> <20050426194208.GB7773@ns1.xcllnt.net> <426E9E1C.6020609@errno.com> <20050426221922.GD8621@ns1.xcllnt.net> In-Reply-To: <20050426221922.GD8621@ns1.xcllnt.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-current@freebsd.org cc: Jose M Rodriguez Subject: Re: rigth crc32 implementation X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 27 Apr 2005 02:19:42 -0000 Marcel Moolenaar wrote: > On Tue, Apr 26, 2005 at 01:01:32PM -0700, Sam Leffler wrote: > >>Note also there is CRC32 code of this sort in WEP and TKIP crypto >>modules in the net80211 support. > > > Sam, > > Given the seperation of crc32() into crc32_raw() and crc32(), with > either crc32() only or otherwise both functions inlined, are there > any obstacles preventing the 802.11 code from using the ones in > src/sys/libkern? The wep+tkip usage is integral to the cipher so splitting it out would likely slow them and, more importantly, would also require revalidation (there are test vectors but they're pretty limited). These modules are self-contained for various reasons so I'm leary of switching. I'll think about adding it under an #ifdef for those that want to save 2Kbytes (the size of the crc tables). Sam From owner-freebsd-current@FreeBSD.ORG Wed Apr 27 02:19: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 8ABC716A4CF; Wed, 27 Apr 2005 02:19:42 +0000 (GMT) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id DF66D43D31; Wed, 27 Apr 2005 02:19:41 +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 j3R2Jf17090800; Tue, 26 Apr 2005 22:19:41 -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 j3R2KB3u070927; Tue, 26 Apr 2005 22:20:11 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 4821C7306E; Tue, 26 Apr 2005 22:19:41 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050427021941.4821C7306E@freebsd-current.sentex.ca> Date: Tue, 26 Apr 2005 22:19:41 -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 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: Wed, 27 Apr 2005 02:19:42 -0000 TB --- 2005-04-27 02:14:59 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-04-27 02:14:59 - starting CURRENT tinderbox run for sparc64/sparc64 TB --- 2005-04-27 02:14:59 - checking out the source tree TB --- 2005-04-27 02:14:59 - cd /home/tinderbox/CURRENT/sparc64/sparc64 TB --- 2005-04-27 02:14:59 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-04-27 02:18:37 - building world (CFLAGS=-O2 -pipe) TB --- 2005-04-27 02:18:37 - cd /home/tinderbox/CURRENT/sparc64/sparc64/src TB --- 2005-04-27 02:18:37 - /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 [...] ===> rescue/rescue/ipf/ipnat (clean) rm -f ipnat_y.c ipnat_y.h ipnat_l.c ipnat_l.h y.tab.c y.tab.h ipnat ipnat.o ipnat_y.o ipnat_l.o ipnat.8.gz ipnat.4.gz ipnat.5.gz ipnat.8.cat.gz ipnat.4.cat.gz ipnat.5.cat.gz ===> rescue/rescue/ipf/ippool (clean) rm -f ippool_y.c ippool_y.h ippool_l.c ippool_l.h y.tab.c y.tab.h ippool ippool_y.o ippool_l.o kmem.o ippool.o ippool.5.gz ippool.8.gz ippool.5.cat.gz ippool.8.cat.gz ===> rescue/rescue/ipf/ipresend (clean) rm -f y.tab.c y.tab.h ipresend ipresend.o ip.o resend.o sbpf.o sock.o 44arp.o ipresend.1.gz ipresend.1.cat.gz cd /tinderbox/CURRENT/sparc64/sparc64/src/rescue/rescue/../../sbin/ipfs && MAKEOBJDIRPREFIX=/home/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/tinderbox/CURRENT/sparc64/sparc64/src/rescue/rescue /home/tinderbox/CURRENT/sparc64/sparc64/obj/tinderbox/CURRENT/sparc64/sparc64/src/make.i386/make DIRPRFX=rescue/rescue/ipfs/ clean cd: can't cd to /tinderbox/CURRENT/sparc64/sparc64/src/rescue/rescue/../../sbin/ipfs *** Error code 2 Stop in /tinderbox/CURRENT/sparc64/sparc64/src/rescue/rescue. *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/src/rescue. *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/src. *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/src. *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/src. TB --- 2005-04-27 02:19:41 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-04-27 02:19:41 - ERROR: failed to build world TB --- 2005-04-27 02:19:41 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Wed Apr 27 02:22:53 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2A03A16A4CE for ; Wed, 27 Apr 2005 02:22:53 +0000 (GMT) Received: from smtp809.mail.sc5.yahoo.com (smtp809.mail.sc5.yahoo.com [66.163.168.188]) by mx1.FreeBSD.org (Postfix) with SMTP id 71AED43D39 for ; Wed, 27 Apr 2005 02:22:52 +0000 (GMT) (envelope-from noackjr@alumni.rice.edu) Received: from unknown (HELO optimator.noacks.org) (noacks@swbell.net@70.240.205.64 with login) by smtp809.mail.sc5.yahoo.com with SMTP; 27 Apr 2005 02:22:51 -0000 Received: from localhost (localhost [127.0.0.1]) by optimator.noacks.org (Postfix) with ESMTP id DFA5A612B; Tue, 26 Apr 2005 21:22:49 -0500 (CDT) Received: from optimator.noacks.org ([127.0.0.1]) by localhost (optimator.noacks.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 16110-06-3; Tue, 26 Apr 2005 21:22:47 -0500 (CDT) Received: from compgeek.noacks.org (compgeek [192.168.1.10]) by optimator.noacks.org (Postfix) with ESMTP id 3E54F60D5; Tue, 26 Apr 2005 21:22:47 -0500 (CDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by compgeek.noacks.org (8.13.3/8.13.3) with ESMTP id j3R2MkIc059630; Tue, 26 Apr 2005 21:22:46 -0500 (CDT) (envelope-from noackjr@alumni.rice.edu) Message-ID: <426EF776.8080007@alumni.rice.edu> Date: Tue, 26 Apr 2005 21:22:46 -0500 From: Jon Noack User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050406) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Matthew Sullivan References: <4267A1CF.3080903@uq.edu.au> <20050422190208.M68772@lexi.siliconlandmark.com> <426C93AC.3030907@root.org> <20050425200601.I42718@carver.gumbysoft.com> <426DB58B.5020608@uq.edu.au> <20050425204148.H43358@carver.gumbysoft.com> <20050426104642.GJ25563@elvis.mu.org> <426EE1BA.5030700@uq.edu.au> In-Reply-To: <426EE1BA.5030700@uq.edu.au> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at noacks.org cc: Maxime Henrion cc: freebsd-current@FreeBSD.org cc: Nate Lawson Subject: Re: SMP on Compaq DL380 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: noackjr@alumni.rice.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, 27 Apr 2005 02:22:53 -0000 On 04/26/05 19:50, Matthew Sullivan wrote: > Maxime Henrion wrote: >> Yeah, I've seen DL380 boxes that needed "Linux" as the OS type or the >> BIOS wouldn't generate an MPTable with both CPUs. > > Apologies for any wasted time.... > > This was the answer.... > > In detail, this morning I went back into the Compaq BIOS configuration > tool, and the OS's settable were (amongst others): > > OTHER > UNIX > > I had set to 'UNIX'.... I changed to 'OTHER' rebooted and .. still the > same. > > There was no mention of 'LINUX' ... frustrated (and sure I saw "LINUX" > in the config previously) I did the following... > > 1/. Powered Down > 2/ Undocked all SCSI drives (just popped them out of the connectors) > 3/ Booted the Config utility > 4/ Selected 'Erase System' > 5/ Power cycled (as instructed) > 6/ Booted back into the 'Smartstart' config utility. > 7/ Followed the 'Manual Configuration and OS install' > 8/ Selected "LINUX" (which was now on this menu. > 9/ Went to the Smart Array Util, and exited immediately, which caused a > spontaneous reboot. > 10/ Powered Down > 11/ Docked all the drives. > 12/ Powered up, and booted back into the Smart Start util. > 13/ Noticed the RAID 5 array and config was self configured by the > controller. > 14/ Checked all settings in the Configutil - noticed "LINUX" was still > displayed as the OS type. > 15/ Checked the Array config (very impressed that it worked out the > config itself) > 16/ Exited Util (no save, none necessary). > 17/ Power cycled. > 18/ Removed smart start CD. > 19/ booted FreeBSD and saved the collected data in a similar place: > > http://scorpion.sorbs.net/SMP/after-erase/ > > ...and as you can see, I have 2 CPU's and this time they are detected > correctly (including the 'odd' CPU type that was reported by the > previous config).... > > For this I hope someone will create a FAQ for old Compaq's, and I'm > posting this back to the list so that people having similar problems in > the future can reference it. I have a single-CPU DL360 and a quad-CPU 6400R. After flashing the BIOS to the latest version and erasing the system, both are running 5-STABLE flawlessly with the OS type set to "Windows 2000". Prior to installing FreeBSD, both were actually running Windows 2000. However, I was unable to get the 6400R to boot the FreeBSD install CD without panicking until I erased the system. I had tried almost every OS type without success. The "Erase System" seemed to be the critical step to get up-and-running. Jon From owner-freebsd-current@FreeBSD.ORG Wed Apr 27 02:33: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 9114E16A4CE for ; Wed, 27 Apr 2005 02:33: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 39A4E43D49 for ; Wed, 27 Apr 2005 02:33:45 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id ADBEB513B1; Tue, 26 Apr 2005 19:33:43 -0700 (PDT) Date: Tue, 26 Apr 2005 19:33:43 -0700 From: Kris Kennaway To: Anish Mistry Message-ID: <20050427023343.GA55926@xor.obsecurity.org> References: <17006.19740.605509.984940@roam.psg.com> <200504261135.07833.mistry.7@osu.edu> <5bbfe7d405042618404e7a6521@mail.gmail.com> <200504262200.17379.mistry.7@osu.edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="1yeeQ81UyVL57Vl7" Content-Disposition: inline In-Reply-To: <200504262200.17379.mistry.7@osu.edu> User-Agent: Mutt/1.4.2.1i cc: Randy Bush cc: David Leimbach cc: freebsd-current@freebsd.org Subject: Re: ule+preempt? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 27 Apr 2005 02:33:45 -0000 --1yeeQ81UyVL57Vl7 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Apr 26, 2005 at 10:00:17PM -0400, Anish Mistry wrote: > On Tuesday 26 April 2005 09:40 pm, David Leimbach wrote: > > On 4/26/05, Anish Mistry wrote: > > > On Tuesday 26 April 2005 10:15 am, Randy Bush wrote: > > > > having been seriously burned, i have avoided ule for some > > > > months. i am wondering if the waters have become relatively > > > > safe to go to ule with preemption? > > > > > > I've been running it for few weeks and it seems to be fine for > > > now, but YMMV. > > > > Are you on an SMP box? I have a feeling it's pretty good on a UP > > machine > > > I'm on on UP. Running on SMP will probably reveal the squishy=20 > underbelly to which Kris was referring. I'd expect the same problems to appear less frequently on UP, but with a non-zero probability. Kris --1yeeQ81UyVL57Vl7 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFCbvoHWry0BWjoQKURAhOfAJ9ZTDdz2iEgTTKf04ncteyTTYByNgCgzDPY v+vUR4fZrFIjiFucTvfUdNo= =0wVI -----END PGP SIGNATURE----- --1yeeQ81UyVL57Vl7-- From owner-freebsd-current@FreeBSD.ORG Wed Apr 27 02:57: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 60B2116A4CE for ; Wed, 27 Apr 2005 02:57:59 +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 EF3D543D5E for ; Wed, 27 Apr 2005 02:57:58 +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 j3R2vonT038033; Tue, 26 Apr 2005 19:57:50 -0700 (PDT) (envelope-from marcel@xcllnt.net) In-Reply-To: <426EF6BD.6030207@errno.com> References: <200504261143.55195.josemi@redesjm.local> <20050426194208.GB7773@ns1.xcllnt.net> <426E9E1C.6020609@errno.com> <20050426221922.GD8621@ns1.xcllnt.net> <426EF6BD.6030207@errno.com> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <05b71132f579685de0459a3b762b26b5@xcllnt.net> Content-Transfer-Encoding: 7bit From: Marcel Moolenaar Date: Tue, 26 Apr 2005 19:57:49 -0700 To: Sam Leffler X-Mailer: Apple Mail (2.622) cc: freebsd-current@freebsd.org cc: Jose M Rodriguez Subject: Re: rigth crc32 implementation X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 27 Apr 2005 02:57:59 -0000 On Apr 26, 2005, at 7:19 PM, Sam Leffler wrote: > Marcel Moolenaar wrote: >> On Tue, Apr 26, 2005 at 01:01:32PM -0700, Sam Leffler wrote: >>> Note also there is CRC32 code of this sort in WEP and TKIP crypto >>> modules in the net80211 support. >> Sam, >> Given the seperation of crc32() into crc32_raw() and crc32(), with >> either crc32() only or otherwise both functions inlined, are there >> any obstacles preventing the 802.11 code from using the ones in >> src/sys/libkern? > > The wep+tkip usage is integral to the cipher so splitting it out would > likely slow them and, more importantly, would also require > revalidation (there are test vectors but they're pretty limited). > These modules are self-contained for various reasons so I'm leary of > switching. Understood. Seems like a good reason to leave it as-is. > I'll think about adding it under an #ifdef for those that want to > save 2Kbytes (the size of the crc tables). In my book, 2K isn't worth the trouble. Thanks for the info, -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net From owner-freebsd-current@FreeBSD.ORG Wed Apr 27 03:35: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 060AD16A4CE for ; Wed, 27 Apr 2005 03:35:30 +0000 (GMT) Received: from mail.sorbs.net (news.sorbs.net [203.15.51.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7B53643D53 for ; Wed, 27 Apr 2005 03:35:29 +0000 (GMT) (envelope-from matthew@uq.edu.au) Received: from [130.102.152.118] (stealthd.its.uq.edu.au [130.102.152.118]) by nemesis.sorbs.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0IFL00I0U5ZUJF@nemesis.sorbs.net> for freebsd-current@freebsd.org; Wed, 27 Apr 2005 13:35:54 +1000 (EST) Date: Wed, 27 Apr 2005 13:34:13 +1000 From: Matthew Sullivan In-reply-to: <426D6425.6080209@uq.edu.au> To: freebsd-current@freebsd.org Message-id: <426F0835.1040608@uq.edu.au> MIME-version: 1.0 Content-type: multipart/signed; boundary=------------ms060509080703080709060902; micalg=sha1; protocol="application/x-pkcs7-signature" X-Accept-Language: en User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041231 References: <426426AE.2060406@uq.edu.au> <42663EA1.3020409@uq.edu.au> <20050424150211.GA87520@walton.maths.tcd.ie> <426BC78A.3E56D99B@freebsd.org> <426C1600.106@uq.edu.au> <426D2307.97D15253@freebsd.org> <426D306B.7010000@freebsd.org> <426D6041.6070103@uq.edu.au> <426D6425.6080209@uq.edu.au> Subject: Re: DF (Don't frag) issues X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 27 Apr 2005 03:35:30 -0000 This is a cryptographically signed message in MIME format. --------------ms060509080703080709060902 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit >>> >>> Ok, I've put up a patch that should fix all issues: >>> >>> http://www.nrg4u.com/freebsd/icmp_df_pmtu-20050425.diff >> Still trying to get a -CURRENT build... cc -O2 -fno-strict-aliasing -pipe -Wall -DFREEBSD_ELF -DIN_RTLD -I/usr/src/libexec/rtld-elf/i386 -I/usr/src/libexec/rtld-elf -elf -fpic -DPIC -Wformat=2 -Wno-format-extra-args -Werror -c /usr/src/libexec/rtld-elf/i386/reloc.c /usr/src/libexec/rtld-elf/i386/reloc.c: In function `allocate_initial_tls': /usr/src/libexec/rtld-elf/i386/reloc.c:339: warning: implicit declaration of function `alloca_tls' /usr/src/libexec/rtld-elf/i386/reloc.c:339: warning: assignment makes pointer from integer without a cast *** Error code 1 Stop in /usr/src/libexec/rtld-elf. *** Error code 1 :-( -- Matthew Sullivan Specialist Systems Programmer Information Technology Services The University of Queensland --------------ms060509080703080709060902 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIG7DCC A3IwggJaoAMCAQICASowDQYJKoZIhvcNAQEEBQAwgaMxCzAJBgNVBAYTAkFVMRMwEQYDVQQI EwpRdWVlbnNsYW5kMREwDwYDVQQHEwhCcmlzYmFuZTElMCMGA1UEChMcVGhlIFVuaXZlcnNp dHkgb2YgUXVlZW5zbGFuZDEoMCYGA1UECxMfSW5mb3JtYXRpb24gVGVjaG5vbG9neSBTZXJ2 aWNlczEbMBkGA1UEAxMSQ2VydGlmaWNhdGUgU2VydmVyMB4XDTA0MDEyMTIzMzYyMVoXDTA2 MDEyMTIzMzYyMVowgbIxCzAJBgNVBAYTAkFVMSUwIwYDVQQKExxUaGUgVW5pdmVyc2l0eSBv ZiBRdWVlbnNsYW5kMScwJQYDVQQLEx5JbmZvcm1hdGlvbiBUZWNub2xvZ3kgU2VydmljZXMx FjAUBgoJkiaJk/IsZAEBEwZjY21hdHQxGTAXBgNVBAMTEE1hdHRoZXcgU3VsbGl2YW4xIDAe BgkqhkiG9w0BCQEWEW1hdHRoZXdAdXEuZWR1LmF1MFwwDQYJKoZIhvcNAQEBBQADSwAwSAJB AJsUfrw/QUqKIzDverWc2F4GFFRZmIeO+bAl+7BM6x/9frMzOtygx4QGb4oQwtOE8Sda1aIs v+yJF3Di9EuUyvMCAwEAAaNoMGYwDgYDVR0PAQH/BAQDAgXgMBEGCWCGSAGG+EIBAQQEAwIF oDAfBgNVHSMEGDAWgBQmqtoyueiWTYZBinvsnzeOWLtUuzAgBgNVHREEGTAXgRVtYXR0aGV3 QGl0cy51cS5lZHUuYXUwDQYJKoZIhvcNAQEEBQADggEBAF2gZrkqZsZlHd4K/+yBN6qrpD61 hctDf7/Eg4jk6DMknEs6nvHMFUMZ4SXvkqPLnHBygTARKAs7qBSLd7mUUBOOQEgk6ovQVY6S 1CDSt3P9O6wjG0K1igtk8v6u7lkQ8p2STXqrOePVINdaucUgBO/IpeUtt9ATl1qvPTWyM/fz oUZsIKeYjNQVEQsuimrZjdbIAFxdl1fggSngUv64wBn8wCssGrPZIZA2lpBBEW1wejoWrDOH IIr+SspGd0i8MovDTMRSvgTERLki17FU/ANilcrSXiODKeIvpXhnQqVScnsoMSZmBmN2QIoG SnBjNK5mYxx5E3v20VOwtP1hVdEwggNyMIICWqADAgECAgEqMA0GCSqGSIb3DQEBBAUAMIGj MQswCQYDVQQGEwJBVTETMBEGA1UECBMKUXVlZW5zbGFuZDERMA8GA1UEBxMIQnJpc2JhbmUx JTAjBgNVBAoTHFRoZSBVbml2ZXJzaXR5IG9mIFF1ZWVuc2xhbmQxKDAmBgNVBAsTH0luZm9y bWF0aW9uIFRlY2hub2xvZ3kgU2VydmljZXMxGzAZBgNVBAMTEkNlcnRpZmljYXRlIFNlcnZl cjAeFw0wNDAxMjEyMzM2MjFaFw0wNjAxMjEyMzM2MjFaMIGyMQswCQYDVQQGEwJBVTElMCMG A1UEChMcVGhlIFVuaXZlcnNpdHkgb2YgUXVlZW5zbGFuZDEnMCUGA1UECxMeSW5mb3JtYXRp b24gVGVjbm9sb2d5IFNlcnZpY2VzMRYwFAYKCZImiZPyLGQBARMGY2NtYXR0MRkwFwYDVQQD ExBNYXR0aGV3IFN1bGxpdmFuMSAwHgYJKoZIhvcNAQkBFhFtYXR0aGV3QHVxLmVkdS5hdTBc MA0GCSqGSIb3DQEBAQUAA0sAMEgCQQCbFH68P0FKiiMw73q1nNheBhRUWZiHjvmwJfuwTOsf /X6zMzrcoMeEBm+KEMLThPEnWtWiLL/siRdw4vRLlMrzAgMBAAGjaDBmMA4GA1UdDwEB/wQE AwIF4DARBglghkgBhvhCAQEEBAMCBaAwHwYDVR0jBBgwFoAUJqraMrnolk2GQYp77J83jli7 VLswIAYDVR0RBBkwF4EVbWF0dGhld0BpdHMudXEuZWR1LmF1MA0GCSqGSIb3DQEBBAUAA4IB AQBdoGa5KmbGZR3eCv/sgTeqq6Q+tYXLQ3+/xIOI5OgzJJxLOp7xzBVDGeEl75Kjy5xwcoEw ESgLO6gUi3e5lFATjkBIJOqL0FWOktQg0rdz/TusIxtCtYoLZPL+ru5ZEPKdkk16qznj1SDX WrnFIATvyKXlLbfQE5darz01sjP386FGbCCnmIzUFRELLopq2Y3WyABcXZdX4IEp4FL+uMAZ /MArLBqz2SGQNpaQQRFtcHo6FqwzhyCK/krKRndIvDKLw0zEUr4ExES5ItexVPwDYpXK0l4j gyniL6V4Z0KlUnJ7KDEmZgZjdkCKBkpwYzSuZmMceRN79tFTsLT9YVXRMYIDQDCCAzwCAQEw gakwgaMxCzAJBgNVBAYTAkFVMRMwEQYDVQQIEwpRdWVlbnNsYW5kMREwDwYDVQQHEwhCcmlz YmFuZTElMCMGA1UEChMcVGhlIFVuaXZlcnNpdHkgb2YgUXVlZW5zbGFuZDEoMCYGA1UECxMf SW5mb3JtYXRpb24gVGVjaG5vbG9neSBTZXJ2aWNlczEbMBkGA1UEAxMSQ2VydGlmaWNhdGUg U2VydmVyAgEqMAkGBSsOAwIaBQCgggItMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ KoZIhvcNAQkFMQ8XDTA1MDQyNzAzMzQxM1owIwYJKoZIhvcNAQkEMRYEFNwmUCTByqt+Vv3+ 3kQV08kxMgKUMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIG6BgkrBgEEAYI3EAQx gawwgakwgaMxCzAJBgNVBAYTAkFVMRMwEQYDVQQIEwpRdWVlbnNsYW5kMREwDwYDVQQHEwhC cmlzYmFuZTElMCMGA1UEChMcVGhlIFVuaXZlcnNpdHkgb2YgUXVlZW5zbGFuZDEoMCYGA1UE CxMfSW5mb3JtYXRpb24gVGVjaG5vbG9neSBTZXJ2aWNlczEbMBkGA1UEAxMSQ2VydGlmaWNh dGUgU2VydmVyAgEqMIG8BgsqhkiG9w0BCRACCzGBrKCBqTCBozELMAkGA1UEBhMCQVUxEzAR BgNVBAgTClF1ZWVuc2xhbmQxETAPBgNVBAcTCEJyaXNiYW5lMSUwIwYDVQQKExxUaGUgVW5p dmVyc2l0eSBvZiBRdWVlbnNsYW5kMSgwJgYDVQQLEx9JbmZvcm1hdGlvbiBUZWNobm9sb2d5 IFNlcnZpY2VzMRswGQYDVQQDExJDZXJ0aWZpY2F0ZSBTZXJ2ZXICASowDQYJKoZIhvcNAQEB BQAEQCt4g9+CQgvz+qQo7cTLK2XI3Bk17R66IT9ywYSpZHtRP5uzuFkapvdEicxLYSaTNAij SQBkMRm+kx4Cy40wJ6sAAAAAAAA= --------------ms060509080703080709060902-- From owner-freebsd-current@FreeBSD.ORG Wed Apr 27 03:59: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 0510D16A4CE for ; Wed, 27 Apr 2005 03:59:54 +0000 (GMT) Received: from fast.dnswatch.com (fast.dnswatch.com [216.177.243.43]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4F22B43D5E for ; Wed, 27 Apr 2005 03:59:53 +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 j3R3xksm061378 for ; Tue, 26 Apr 2005 20:59:53 -0700 (PDT) (envelope-from null@dnswatch.com) Received: (from www@localhost) by fast.dnswatch.com (8.12.6/8.12.6/Submit) id j3R3xj55061377; Tue, 26 Apr 2005 20:59:46 -0700 (PDT) (envelope-from null@dnswatch.com) X-Authentication-Warning: fast.dnswatch.com: www set sender to null@dnswatch.com using -f Received: from demon.dnswatch.com ([216.177.243.42]) (DNSwatch.com_WebMail authenticated user null) by webmail.dnswatch.com with HTTP; Tue, 26 Apr 2005 20:59:44 -0700 (PDT) Message-ID: <52550.216.177.243.42.1114574385.localmail@webmail.dnswatch.com> Date: Tue, 26 Apr 2005 20:59:44 -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: can't build kernel X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 27 Apr 2005 03:59:54 -0000 Hello, Just got a new CPU today. Running 5.4-RC3 on GENERIC until the new CPU showed up. Installed the CPU drafted a new config for the kernel cd'd to /usr/src, typed "make buildkernel KERNCONF=DEMON01", build process went as expected. But before the build process completed the machine froze for no apparent reason at the sound driver part. Couldn't ssh into it from another box, so hit the reset button, chose 4 from the menu (single user mode). Performed a fsck -f. Rebooted and attempted to rebuild. But it barfed. So I performed an rm -fr /usr/src. Then /stand/sysinstall > install entire src tree and tried another "make buildkernel KERNCONF=DEMON01" in /usr/src. It barfed with the following: .... rm -f .depend GPATH GRTAGS GSYMS GTAGS ===> rp rm -f /usr/src/sys/modules/rp/export_syms rp.ko rp.kld rp.o rp_pci.o @ machine s ymb.tmp tmp.o opt_compat.h pci_if.h bus_if.h device_if.h rm -f .depend GPATH GRTAGS GSYMS GTAGS ===> rue ".depend", line 1: Need an operator ".depend", line 3: Need an operator ".depend", line 4: Need an operator ".depend", line 5: Need an operator ".depend", line 6: Need an operator ".depend", line 9: Need an operator ".depend", line 18: Need an operator ".depend", line 20: Need an operator ".depend", line 21: Need an operator ".depend", line 25: Need an operator ".depend", line 43: Need an operator make: fatal errors encountered -- cannot continue *** Error code 1 Stop in /usr/src/sys/modules. *** Error code 1 Stop in /usr/obj/usr/src/sys/DEMON01. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. /usr/src ... Please help and thank you. -Chris //////////////////////////////////////////////////// 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 Wed Apr 27 04:13: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 2C22A16A4CE for ; Wed, 27 Apr 2005 04:13:22 +0000 (GMT) Received: from fast.dnswatch.com (fast.dnswatch.com [216.177.243.43]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8043843D54 for ; Wed, 27 Apr 2005 04:13:21 +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 j3R4DJsm061494 for ; Tue, 26 Apr 2005 21:13:22 -0700 (PDT) (envelope-from null@dnswatch.com) Received: (from www@localhost) by fast.dnswatch.com (8.12.6/8.12.6/Submit) id j3R4DIfn061493; Tue, 26 Apr 2005 21:13:18 -0700 (PDT) (envelope-from null@dnswatch.com) X-Authentication-Warning: fast.dnswatch.com: www set sender to null@dnswatch.com using -f Received: from demon.dnswatch.com ([216.177.243.42]) (DNSwatch.com_WebMail authenticated user null) by webmail.dnswatch.com with HTTP; Tue, 26 Apr 2005 21:13:17 -0700 (PDT) Message-ID: <55677.216.177.243.42.1114575198.localmail@webmail.dnswatch.com> Date: Tue, 26 Apr 2005 21:13:17 -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: X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 27 Apr 2005 04:13:22 -0000 Hello, Just got a new CPU today. Running 5.4-RC3 on GENERIC until the new CPU showed up. Installed the CPU drafted a new config for the kernel cd'd to /usr/src, typed "make buildkernel KERNCONF=DEMON01", build process went as expected. But before the build process completed the machine froze for no apparent reason at the sound driver part. Couldn't ssh into it from another box, so hit the reset button, chose 4 from the menu (single user mode). Performed a fsck -f. Rebooted and attempted to rebuild. But it barfed. So I performed an rm -fr /usr/src. Then /stand/sysinstall > install entire src tree and tried another "make buildkernel KERNCONF=DEMON01" in /usr/src. It barfed with the following: .... rm -f .depend GPATH GRTAGS GSYMS GTAGS ===> rp rm -f /usr/src/sys/modules/rp/export_syms rp.ko rp.kld rp.o rp_pci.o @ machine s ymb.tmp tmp.o opt_compat.h pci_if.h bus_if.h device_if.h rm -f .depend GPATH GRTAGS GSYMS GTAGS ===> rue ".depend", line 1: Need an operator ".depend", line 3: Need an operator ".depend", line 4: Need an operator ".depend", line 5: Need an operator ".depend", line 6: Need an operator ".depend", line 9: Need an operator ".depend", line 18: Need an operator ".depend", line 20: Need an operator ".depend", line 21: Need an operator ".depend", line 25: Need an operator ".depend", line 43: Need an operator make: fatal errors encountered -- cannot continue *** Error code 1 Stop in /usr/src/sys/modules. *** Error code 1 Stop in /usr/obj/usr/src/sys/DEMON01. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. /usr/src ... ============================================================ dmesg -a is @: http://www.dnswatch.com/kern/dmesg#1 acpidump -t -d is @: http://www.dnswatch.com/kern/acpidump#1 sysctl -a is @: http://www.dnswatch.com/kern/sysctl#1 ============================================================= Please help and thank you. //////////////////////////////////////////////////// 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 Wed Apr 27 04:14: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 461EB16A4CE for ; Wed, 27 Apr 2005 04:14:52 +0000 (GMT) Received: from fast.dnswatch.com (fast.dnswatch.com [216.177.243.43]) by mx1.FreeBSD.org (Postfix) with ESMTP id 964FA43D2F for ; Wed, 27 Apr 2005 04:14:51 +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 j3R4Ensm061504 for ; Tue, 26 Apr 2005 21:14:52 -0700 (PDT) (envelope-from null@dnswatch.com) Received: (from www@localhost) by fast.dnswatch.com (8.12.6/8.12.6/Submit) id j3R4EmKY061503; Tue, 26 Apr 2005 21:14:48 -0700 (PDT) (envelope-from null@dnswatch.com) X-Authentication-Warning: fast.dnswatch.com: www set sender to null@dnswatch.com using -f Received: from demon.dnswatch.com ([216.177.243.42]) (DNSwatch.com_WebMail authenticated user null) by webmail.dnswatch.com with HTTP; Tue, 26 Apr 2005 21:14:48 -0700 (PDT) Message-ID: <63349.216.177.243.42.1114575288.localmail@webmail.dnswatch.com> Date: Tue, 26 Apr 2005 21:14:48 -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: can't build kernel [with CONFIG this time] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 27 Apr 2005 04:14:52 -0000 Hello, Just got a new CPU today. Running 5.4-RC3 on GENERIC until the new CPU showed up. Installed the CPU drafted a new config for the kernel cd'd to /usr/src, typed "make buildkernel KERNCONF=DEMON01", build process went as expected. But before the build process completed the machine froze for no apparent reason at the sound driver part. Couldn't ssh into it from another box, so hit the reset button, chose 4 from the menu (single user mode). Performed a fsck -f. Rebooted and attempted to rebuild. But it barfed. So I performed an rm -fr /usr/src. Then /stand/sysinstall > install entire src tree and tried another "make buildkernel KERNCONF=DEMON01" in /usr/src. It barfed with the following: .... rm -f .depend GPATH GRTAGS GSYMS GTAGS ===> rp rm -f /usr/src/sys/modules/rp/export_syms rp.ko rp.kld rp.o rp_pci.o @ machine s ymb.tmp tmp.o opt_compat.h pci_if.h bus_if.h device_if.h rm -f .depend GPATH GRTAGS GSYMS GTAGS ===> rue ".depend", line 1: Need an operator ".depend", line 3: Need an operator ".depend", line 4: Need an operator ".depend", line 5: Need an operator ".depend", line 6: Need an operator ".depend", line 9: Need an operator ".depend", line 18: Need an operator ".depend", line 20: Need an operator ".depend", line 21: Need an operator ".depend", line 25: Need an operator ".depend", line 43: Need an operator make: fatal errors encountered -- cannot continue *** Error code 1 Stop in /usr/src/sys/modules. *** Error code 1 Stop in /usr/obj/usr/src/sys/DEMON01. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. /usr/src ... ============================================================ dmesg -a is @: http://www.dnswatch.com/kern/dmesg#1 acpidump -t -d is @: http://www.dnswatch.com/kern/acpidump#1 sysctl -a is @: http://www.dnswatch.com/kern/sysctl#1 DEMON01 is @: http://www.dnswatch.com/kern/DEMON01 ============================================================= Please help and thank you. //////////////////////////////////////////////////// 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 Wed Apr 27 04:27: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 DE75F16A4CE for ; Wed, 27 Apr 2005 04:27:59 +0000 (GMT) Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [204.127.198.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id B078143D46 for ; Wed, 27 Apr 2005 04:27:52 +0000 (GMT) (envelope-from saturn@serv.net) Received: from armada.astral.realm (c-24-18-26-253.hsd1.wa.comcast.net[24.18.26.253]) by comcast.net (rwcrmhc13) with ESMTP id <20050427042752015004k88fe>; Wed, 27 Apr 2005 04:27:52 +0000 From: Jeff To: freebsd-current@freebsd.org Date: Tue, 26 Apr 2005 21:33:42 +0000 User-Agent: KMail/1.8 References: <20050425183733.GB24146@eeyore.local.dohd.org> <2323.216.177.243.38.1114457612.localmail@webmail.dnswatch.com> <20050425200052.GC24146@eeyore.local.dohd.org> In-Reply-To: <20050425200052.GC24146@eeyore.local.dohd.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200504262133.42669.saturn@serv.net> Subject: Re: fxp0: device timeout X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 27 Apr 2005 04:28:00 -0000 I am experiencing the fxp0: device timeout as well. uname -a FreeBSD 5.4-STABLE FreeBSD 5.4-STABLE #0: Sat Apr 23 19:52:42 UTC 2005 the kernel is the amd64 and I am running and amd64 processor - Jeff On Monday 25 April 2005 20:00, Mark Huizer wrote: > On Mon, Apr 25, 2005 at 12:33:32PM -0700, /dev/null wrote: > > I don't want to sound like a smart a$$, or know-it-all. But could this > > not also be a simple case of Induction? Is it possible that something has > > changed in the environment that might interfere with the NIC or cabling? > > I mean it wouldn't have to completely clobber the connection, but simply > > impeed it slightly, which would make it crap out under any type of load. > > Just thought I'd mention it FWIW. > > Well, if such a simple reinstall can make such a big difference, I would > sincerely start questioning computers ;-) > But apart from a table in the attic moving 10 centimeter, nothing > changed. > > Mark From owner-freebsd-current@FreeBSD.ORG Wed Apr 27 04:44: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 B832216A4CE for ; Wed, 27 Apr 2005 04:44:11 +0000 (GMT) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.200]) by mx1.FreeBSD.org (Postfix) with ESMTP id 62E1043D5F for ; Wed, 27 Apr 2005 04:44:11 +0000 (GMT) (envelope-from joseph.koshy@gmail.com) Received: by rproxy.gmail.com with SMTP id j1so87463rnf for ; Tue, 26 Apr 2005 21:44: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=OZzMgTRV3hRqW0trbK3KOUFOko806gr2Qfntak7t99oglcnX7q0iLkZ+0otHRE3gcfieyMIzeJg/2oSpfNenx2qfDIn5l8yWyFkMJA0NogHrc2t7knrE6yjVuhwl8yxhh2JzUnLOE2Z528jKusFiKCqa7wX2Jra0DCL7HBFmrgM= Received: by 10.38.11.30 with SMTP id 30mr617403rnk; Tue, 26 Apr 2005 21:44:10 -0700 (PDT) Received: by 10.38.209.22 with HTTP; Tue, 26 Apr 2005 21:44:10 -0700 (PDT) Message-ID: <84dead7205042621444578045@mail.gmail.com> Date: Wed, 27 Apr 2005 04:44:10 +0000 From: Joseph Koshy To: /dev/null In-Reply-To: <63349.216.177.243.42.1114575288.localmail@webmail.dnswatch.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <63349.216.177.243.42.1114575288.localmail@webmail.dnswatch.com> cc: freebsd-current@freebsd.org Subject: Re: can't build kernel [with CONFIG this time] 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: Wed, 27 Apr 2005 04:44:11 -0000 Does the machine get through a full 'make world' sequence? --=20 FreeBSD Volunteer, http://people.freebsd.org/~jkoshy From owner-freebsd-current@FreeBSD.ORG Wed Apr 27 04:49: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 B4DEF16A4CE for ; Wed, 27 Apr 2005 04:49:05 +0000 (GMT) Received: from fast.dnswatch.com (fast.dnswatch.com [216.177.243.43]) by mx1.FreeBSD.org (Postfix) with ESMTP id 02EBF43D5D for ; Wed, 27 Apr 2005 04:49:05 +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 j3R4n3sm061723; Tue, 26 Apr 2005 21:49:05 -0700 (PDT) (envelope-from null@dnswatch.com) Received: (from www@localhost) by fast.dnswatch.com (8.12.6/8.12.6/Submit) id j3R4n27b061722; Tue, 26 Apr 2005 21:49:02 -0700 (PDT) (envelope-from null@dnswatch.com) X-Authentication-Warning: fast.dnswatch.com: www set sender to null@dnswatch.com using -f Received: from demon.dnswatch.com ([216.177.243.42]) (DNSwatch.com_WebMail authenticated user null) by webmail.dnswatch.com with HTTP; Tue, 26 Apr 2005 21:49:01 -0700 (PDT) Message-ID: <54723.216.177.243.42.1114577341.localmail@webmail.dnswatch.com> In-Reply-To: <84dead7205042621444578045@mail.gmail.com> References: <63349.216.177.243.42.1114575288.localmail@webmail.dnswatch.com> <84dead7205042621444578045@mail.gmail.com> Date: Tue, 26 Apr 2005 21:49:01 -0700 (PDT) From: "/dev/null" To: freebsd-current@freebsd.org, "Joseph Koshy" 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: can't build kernel [with CONFIG this time] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 27 Apr 2005 04:49:05 -0000 Thanks for the reply. Yes, it did that fine. All I've done since that was to make this kernel. -Chris > Does the machine get through a full 'make world' sequence? > > -- > FreeBSD Volunteer, http://people.freebsd.org/~jkoshy > _______________________________________________ > 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 Wed Apr 27 05:38: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 23ABB16A4CE for ; Wed, 27 Apr 2005 05:38:54 +0000 (GMT) Received: from kientzle.com (h-66-166-149-50.snvacaid.covad.net [66.166.149.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5261C43D5F for ; Wed, 27 Apr 2005 05:38:53 +0000 (GMT) (envelope-from kientzle@freebsd.org) Received: from freebsd.org (p54.kientzle.com [66.166.149.54]) by kientzle.com (8.12.9/8.12.9) with ESMTP id j3R5cgOZ098961; Tue, 26 Apr 2005 22:38:43 -0700 (PDT) (envelope-from kientzle@freebsd.org) Message-ID: <426F2562.2090008@freebsd.org> Date: Tue, 26 Apr 2005 22:38:42 -0700 From: Tim Kientzle User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.4) Gecko/20031006 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jose M Rodriguez References: <200504261143.55195.josemi@redesjm.local> <426E9E1C.6020609@errno.com> <20050426221922.GD8621@ns1.xcllnt.net> <200504270052.33158.josemi@redesjm.local> In-Reply-To: <200504270052.33158.josemi@redesjm.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit cc: Sam Leffler cc: freebsd-current@freebsd.org cc: Marcel Moolenaar Subject: Re: rigth crc32 implementation X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 27 Apr 2005 05:38:54 -0000 Jose M Rodriguez wrote: > El Miércoles, 27 de Abril de 2005 00:19, Marcel Moolenaar escribió: >>On Tue, Apr 26, 2005 at 01:01:32PM -0700, Sam Leffler wrote: >> >>>Note also there is CRC32 code of this sort in WEP and TKIP crypto >>>modules in the net80211 support. >> >>Given the seperation of crc32() into crc32_raw() and crc32(), with >>either crc32() only or otherwise both functions inlined, are there >>any obstacles preventing the 802.11 code from using the ones in >>src/sys/libkern? > > at last, sys/dev/if_sbni have another implementation of what seems to be > a crc32 alg. Be a little careful, please. There are very many different, incompatible "32-bit CRCs." There are just a few popular ones, so you can often combine functions, but not always. Any CRC implementation should clearly document the generating polynomial and the preconditioning and postconditioning assumptions. Tim Kientzle From owner-freebsd-current@FreeBSD.ORG Wed Apr 27 05:55: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 0D38616A4CE for ; Wed, 27 Apr 2005 05:55:38 +0000 (GMT) Received: from ms-smtp-02-eri0.southeast.rr.com (ms-smtp-02-lbl.southeast.rr.com [24.25.9.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id A402343D46 for ; Wed, 27 Apr 2005 05:55:37 +0000 (GMT) (envelope-from jason@ec.rr.com) Received: from [192.168.1.101] (cpe-065-184-196-020.ec.res.rr.com [65.184.196.20])j3R5tY0V020824; Wed, 27 Apr 2005 01:55:35 -0400 (EDT) Message-ID: <426F2BF1.9010604@ec.rr.com> Date: Wed, 27 Apr 2005 02:06:41 -0400 From: jason henson User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050426) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Randy Bush References: <17006.19740.605509.984940@roam.psg.com> In-Reply-To: <17006.19740.605509.984940@roam.psg.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Symantec AntiVirus Scan Engine cc: FreeBSD Current Subject: Re: ule+preempt? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 27 Apr 2005 05:55:38 -0000 Randy Bush wrote: >having been seriously burned, i have avoided ule for some months. >i am wondering if the waters have become relatively safe to go >to ule with preemption? > >randy > >_______________________________________________ >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" > > > I have tried using that combination on a stable machine and have noticed 2 reboots when in x and once x turning off my monitor but leaving my system otherwise fine. This was over a week's time. I will be turning off preemption when soon. To elaborate, I have not had issues when not in xorg. I leave my machine on 24/7 doing f@h. The time my monitor got turned off I let my machine continue to run over night. After I rebooted the next morning I checked my logs and f@h continued to function normally and even started a new wu. I have only 1 computer so I can't login to my computer from another, which I would like to do to see what x and the rest of the system is doing. From owner-freebsd-current@FreeBSD.ORG Wed Apr 27 06:09: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 0899216A4CE for ; Wed, 27 Apr 2005 06:09:21 +0000 (GMT) Received: from fast.dnswatch.com (fast.dnswatch.com [216.177.243.43]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6D0BA43D5F for ; Wed, 27 Apr 2005 06:09:20 +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 j3R69Hsm062390 for ; Tue, 26 Apr 2005 23:09:21 -0700 (PDT) (envelope-from null@dnswatch.com) Received: (from www@localhost) by fast.dnswatch.com (8.12.6/8.12.6/Submit) id j3R69GV1062389; Tue, 26 Apr 2005 23:09:16 -0700 (PDT) (envelope-from null@dnswatch.com) X-Authentication-Warning: fast.dnswatch.com: www set sender to null@dnswatch.com using -f Received: from demon.dnswatch.com ([216.177.243.42]) (DNSwatch.com_WebMail authenticated user null) by webmail.dnswatch.com with HTTP; Tue, 26 Apr 2005 23:09:15 -0700 (PDT) Message-ID: <57436.216.177.243.42.1114582155.localmail@webmail.dnswatch.com> Date: Tue, 26 Apr 2005 23:09:15 -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: boot banner project X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 27 Apr 2005 06:09:21 -0000 Hello any & all, O.K. I feel I must preface this with an acknowledgment that I *know* this is a silly project *because* given the *incredibly* long uptimes that FreeBSD is known for. >>But<< for those *few* times when FreeBSDers see a boot screen, shouldn't it look really nice? Shouldn't also be able to reflect the Administrators tastes and personality? Well, this is the premise for my attempting this project. But before I start, I want to submit an RFC. So consider this an Request for comments. This is an attempt to create a Graphical boot screen that initially has the following layout: (a fixed width font required to view the layout correctly) -------------------------------------------------------- | some | | sort | | of | | graphic goes in this area | |-------------------------------------------------------- | boot | | | | messages | | | | seen | | | | here | | bla... | | bla... | | bla... | --------------------------------------------------------- -Chris //////////////////////////////////////////////////// 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 Wed Apr 27 06:14: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 E160516A4CE for ; Wed, 27 Apr 2005 06:14:47 +0000 (GMT) Received: from fast.dnswatch.com (fast.dnswatch.com [216.177.243.43]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4626743D55 for ; Wed, 27 Apr 2005 06:14:47 +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 j3R6Eksm062446; Tue, 26 Apr 2005 23:14:47 -0700 (PDT) (envelope-from null@dnswatch.com) Received: (from www@localhost) by fast.dnswatch.com (8.12.6/8.12.6/Submit) id j3R6Ejrw062445; Tue, 26 Apr 2005 23:14:45 -0700 (PDT) (envelope-from null@dnswatch.com) X-Authentication-Warning: fast.dnswatch.com: www set sender to null@dnswatch.com using -f Received: from demon.dnswatch.com ([216.177.243.42]) (DNSwatch.com_WebMail authenticated user null) by webmail.dnswatch.com with HTTP; Tue, 26 Apr 2005 23:14:45 -0700 (PDT) Message-ID: <59917.216.177.243.42.1114582485.localmail@webmail.dnswatch.com> In-Reply-To: <57d7100005042622465e45ffe0@mail.gmail.com> References: <63349.216.177.243.42.1114575288.localmail@webmail.dnswatch.com> <57d7100005042622465e45ffe0@mail.gmail.com> Date: Tue, 26 Apr 2005 23:14:45 -0700 (PDT) From: "/dev/null" To: freebsd-current@freebsd.org, "pete wright" 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: can't build kernel [with CONFIG this time] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 27 Apr 2005 06:14:48 -0000 Pete, Thanks for your reply. You're probably right, I should sup the src tree to get more current first. I'm a bit fuzzy upstairs from sleep deprivation (*way* too much work and *so* little time). I'll sup the src and report my experience. Thanks again. -Chris > On 4/26/05, /dev/null wrote: >> Hello, >> Just got a new CPU today. Running 5.4-RC3 on GENERIC until the new CPU >> showed up. Installed the CPU drafted a new config for the kernel cd'd to >> /usr/src, typed "make buildkernel KERNCONF=DEMON01", build process went >> as >> expected. But before the build process completed the machine froze for >> no >> apparent reason at the sound driver part. Couldn't ssh into it from >> another >> box, so hit the reset button, chose 4 from the menu (single user mode). >> Performed a fsck -f. Rebooted and attempted to rebuild. But it barfed. >> So I performed an rm -fr /usr/src. >> Then /stand/sysinstall > install entire src tree and tried another >> "make buildkernel KERNCONF=DEMON01" in /usr/src. >> It barfed with the following: > > Have you tried building a GENERIC kernel with this config? Also have > you cvsup'd your source tree. I know you re-downloaded the source > from /stand/sysinstall, but you may want to get it via cvsup. > Especially with the 5.4 RC's. If you are able to build a GENERIC > kernel, and the problem occurs after a cvsup then I would suspect > there is something broken in your custom config. > > HTH > -p > > > -- > ~~o0OO0o~~ > Pete Wright > www.nycbug.org > NYC's *BSD User Group > > //////////////////////////////////////////////////// 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 Wed Apr 27 06:27: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 C56B816A4CE for ; Wed, 27 Apr 2005 06:27:20 +0000 (GMT) Received: from fast.dnswatch.com (fast.dnswatch.com [216.177.243.43]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2277343D49 for ; Wed, 27 Apr 2005 06:27:20 +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 j3R6RGsm062549; Tue, 26 Apr 2005 23:27:19 -0700 (PDT) (envelope-from null@dnswatch.com) Received: (from www@localhost) by fast.dnswatch.com (8.12.6/8.12.6/Submit) id j3R6RFsc062548; Tue, 26 Apr 2005 23:27:16 -0700 (PDT) (envelope-from null@dnswatch.com) X-Authentication-Warning: fast.dnswatch.com: www set sender to null@dnswatch.com using -f Received: from demon.dnswatch.com ([216.177.243.42]) (DNSwatch.com_WebMail authenticated user null) by webmail.dnswatch.com with HTTP; Tue, 26 Apr 2005 23:27:14 -0700 (PDT) Message-ID: <55065.216.177.243.42.1114583234.localmail@webmail.dnswatch.com> In-Reply-To: <20050427060414.GA54657@ns2.wananchi.com> References: <63349.216.177.243.42.1114575288.localmail@webmail.dnswatch.com> <20050427060414.GA54657@ns2.wananchi.com> Date: Tue, 26 Apr 2005 23:27:14 -0700 (PDT) From: "/dev/null" To: "Odhiambo Washington" , 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: can't build kernel [with CONFIG this time] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 27 Apr 2005 06:27:20 -0000 Odhiambo Washington, Thank you for your thoughtful reply. According to the documentation located at: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig-building.html ... For example: # cd /usr/src/sys/i386/conf # mkdir /root/kernels # cp GENERIC /root/kernels/MYKERNEL # ln -s /root/kernels/MYKERNEL ... So, in case it is not yet apparent, DEMON01 is located in /root/krenels and the link is located in /usr/src/sys/i386/conf (yes I re-created it after re-installing src). Are we on the same page yet. ;) -Chris > Read the documentation again! > > You did rm -rf /usr/src. > So where the fuck is DEMON01 ;) > Anyway, b4 compiling a kernel, you must buildworld 1st. > > > cd /usr/src > make buildworld > make kernel KERNCONF=DEMON01 BTW, I think that unless something new has happened since I read the docs a couple of hrs. ago, the sequence you provide here is missing a couple of steps - make install, mergemaster, etc... > make installwolrd (only after you have booted the new kernel) > > > > > * /dev/null [20050427 08:28]: wrote: >> Hello, >> Just got a new CPU today. Running 5.4-RC3 on GENERIC until the new CPU >> showed up. Installed the CPU drafted a new config for the kernel cd'd to >> /usr/src, typed "make buildkernel KERNCONF=DEMON01", build process went >> as >> expected. But before the build process completed the machine froze for >> no >> apparent reason at the sound driver part. Couldn't ssh into it from >> another >> box, so hit the reset button, chose 4 from the menu (single user mode). >> Performed a fsck -f. Rebooted and attempted to rebuild. But it barfed. >> So I performed an rm -fr /usr/src. >> Then /stand/sysinstall > install entire src tree and tried another >> "make buildkernel KERNCONF=DEMON01" in /usr/src. >> It barfed with the following: >> .... >> rm -f .depend GPATH GRTAGS GSYMS GTAGS >> ===> rp >> rm -f /usr/src/sys/modules/rp/export_syms rp.ko rp.kld rp.o rp_pci.o @ >> machine s >> ymb.tmp tmp.o opt_compat.h pci_if.h bus_if.h device_if.h >> rm -f .depend GPATH GRTAGS GSYMS GTAGS >> ===> rue >> ".depend", line 1: Need an operator >> ".depend", line 3: Need an operator >> ".depend", line 4: Need an operator >> ".depend", line 5: Need an operator >> ".depend", line 6: Need an operator >> ".depend", line 9: Need an operator >> ".depend", line 18: Need an operator >> ".depend", line 20: Need an operator >> ".depend", line 21: Need an operator >> ".depend", line 25: Need an operator >> ".depend", line 43: Need an operator >> make: fatal errors encountered -- cannot continue >> *** Error code 1 >> >> Stop in /usr/src/sys/modules. >> *** Error code 1 >> >> Stop in /usr/obj/usr/src/sys/DEMON01. >> *** Error code 1 >> >> Stop in /usr/src. >> *** Error code 1 >> >> Stop in /usr/src. >> >> /usr/src >> >> ... >> ============================================================ >> >> dmesg -a is @: http://www.dnswatch.com/kern/dmesg#1 >> >> acpidump -t -d is @: http://www.dnswatch.com/kern/acpidump#1 >> >> sysctl -a is @: http://www.dnswatch.com/kern/sysctl#1 >> >> DEMON01 is @: http://www.dnswatch.com/kern/DEMON01 >> >> ============================================================= >> >> Please help and thank you. >> >> >> //////////////////////////////////////////////////// >> 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. >> //////////////////////////////////////////////////// >> _______________________________________________ >> 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" >> >> _______________________________________________ >> freebsd-questions@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-questions >> To unsubscribe, send any mail to >> "freebsd-questions-unsubscribe@freebsd.org" > > -Wash > > http://www.netmeister.org/news/learn2quote.html > > -- > +======================================================================+ > |\ _,,,---,,_ | Odhiambo Washington > Zzz /,`.-'`' -. ;-;;,_ | Wananchi Online Ltd. www.wananchi.com > |,4- ) )-,_. ,\ ( `'-'| Tel: +254 20 313985-9 +254 20 313922 > '---''(_/--' `-'\_) | GSM: +254 722 743223 +254 733 744121 > +======================================================================+ > I often quote myself; it adds spice to my conversation. > -- George Bernard Shaw > //////////////////////////////////////////////////// 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 Wed Apr 27 07:02: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 4573616A4CE; Wed, 27 Apr 2005 07:02:51 +0000 (GMT) Received: from 62-15-211-171.inversas.jazztel.es (62-15-211-171.inversas.jazztel.es [62.15.211.171]) by mx1.FreeBSD.org (Postfix) with ESMTP id EE50B43D60; Wed, 27 Apr 2005 07:02:49 +0000 (GMT) (envelope-from josemi@freebsd.jazztel.es) Received: from redesjm.local (orion.redesjm.local [192.168.254.16]) j3R72ZAp024098; Wed, 27 Apr 2005 09:02:35 +0200 (CEST) (envelope-from josemi@redesjm.local) Received: from localhost (localhost [[UNIX: localhost]]) by redesjm.local (8.13.3/8.13.3/Submit) id j3R72VuM001218; Wed, 27 Apr 2005 09:02:31 +0200 (CEST) (envelope-from josemi@redesjm.local) From: Jose M Rodriguez To: freebsd-current@freebsd.org Date: Wed, 27 Apr 2005 09:02:30 +0200 User-Agent: KMail/1.8 References: <200504261143.55195.josemi@redesjm.local> <200504270052.33158.josemi@redesjm.local> <426F2562.2090008@freebsd.org> In-Reply-To: <426F2562.2090008@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200504270902.31464.josemi@redesjm.local> X-AntiVirus: checked by AntiVir Milter (version: 1.1.0-3; AVE: 6.30.0.7; VDF: 6.30.0.116; host: antares.redesjm.local) cc: Sam Leffler cc: Tim Kientzle cc: Jose M Rodriguez cc: Marcel Moolenaar Subject: Re: rigth crc32 implementation X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 27 Apr 2005 07:02:51 -0000 El Mi=E9rcoles, 27 de Abril de 2005 07:38, Tim Kientzle escribi=F3: > Jose M Rodriguez wrote: > > El Mi=C3=A9rcoles, 27 de Abril de 2005 00:19, Marcel Moolenaar=20 escribi=C3=B3: > >>On Tue, Apr 26, 2005 at 01:01:32PM -0700, Sam Leffler wrote: > >>>Note also there is CRC32 code of this sort in WEP and TKIP crypto > >>>modules in the net80211 support. > >> > >>Given the seperation of crc32() into crc32_raw() and crc32(), with > >>either crc32() only or otherwise both functions inlined, are there > >>any obstacles preventing the 802.11 code from using the ones in > >>src/sys/libkern? > > > > at last, sys/dev/if_sbni have another implementation of what seems > > to be a crc32 alg. > > Be a little careful, please. There are very many > different, incompatible "32-bit CRCs." There are > just a few popular ones, so you can often combine > functions, but not always. > I'm getting this. I'll try to do some test and notes. I think that a regression test may show what is and what is not the=20 ether CRC-32. At the moment, I'll go private with =2D CRC_INIT, CRC_DO, CRC_GET macros =2D An implementation in the way of crc32(), crc32_raw(), but avoiding=20 symbol collission. And go to libkern through the macros if doable. =2D- josemi From owner-freebsd-current@FreeBSD.ORG Wed Apr 27 07:21: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 0F8F116A4CE for ; Wed, 27 Apr 2005 07:21:57 +0000 (GMT) Received: from fast.dnswatch.com (fast.dnswatch.com [216.177.243.43]) by mx1.FreeBSD.org (Postfix) with ESMTP id D1AF543D41 for ; Wed, 27 Apr 2005 07:21:55 +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 j3R7Lhsm063020; Wed, 27 Apr 2005 00:21:49 -0700 (PDT) (envelope-from null@dnswatch.com) Received: (from www@localhost) by fast.dnswatch.com (8.12.6/8.12.6/Submit) id j3R7Lgk2063019; Wed, 27 Apr 2005 00:21:42 -0700 (PDT) (envelope-from null@dnswatch.com) X-Authentication-Warning: fast.dnswatch.com: www set sender to null@dnswatch.com using -f Received: from demon.dnswatch.com ([216.177.243.42]) (DNSwatch.com_WebMail authenticated user null) by webmail.dnswatch.com with HTTP; Wed, 27 Apr 2005 00:21:41 -0700 (PDT) Message-ID: <52515.216.177.243.42.1114586501.localmail@webmail.dnswatch.com> In-Reply-To: <6.1.0.6.2.20050427001118.0327cd50@cobalt.antimatter.net> References: <57436.216.177.243.42.1114582155.localmail@webmail.dnswatch.com><6.1.0.6.2.20050426233321.084e9210@cobalt.antimatter.net><51899.216.177.243.42.1114584317.localmail@webmail.dnswatch.com> <6.1.0.6.2.20050427001118.0327cd50@cobalt.antimatter.net> Date: Wed, 27 Apr 2005 00:21:41 -0700 (PDT) From: "/dev/null" To: freebsd-current@freebsd.org, "Glenn Dawson" 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: boot banner project X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 27 Apr 2005 07:21:57 -0000 > At 11:45 PM 4/26/2005, /dev/null wrote: > >> > At 11:09 PM 4/26/2005, /dev/null wrote: >> >>Hello any & all, >> >> O.K. I feel I must preface this with an acknowledgment that I *know* >> >>this is a silly project *because* given the *incredibly* long uptimes >> >>that FreeBSD is known for. >>But<< for those *few* times when >> FreeBSDers >> >>see a boot screen, shouldn't it look really nice? Shouldn't also be >> able >> >>to reflect the Administrators tastes and personality? Well, this is >> the >> >>premise for my attempting this project. But before I start, I want to >> >>submit an RFC. So consider this an Request for comments. This is an >> >>attempt to create a Graphical boot screen that initially has the >> >>following layout: >> >>(a fixed width font required to view the layout correctly) >> >> -------------------------------------------------------- >> >>| some | >> >>| sort | >> >>| of | >> >>| graphic goes in this area | >> >>|-------------------------------------------------------- >> >>| boot | >> >>| | >> >>| messages | >> >>| | >> >>| seen | >> >>| | >> >>| here | >> >>| bla... | >> >>| bla... | >> >>| bla... | >> >>--------------------------------------------------------- >> > >> > Isn't this essentially what splash(4)is for? >> >>At first it may seem that way. But unless I'm mistaken, it will only >> allow >>a graphic that covers the entire screen. So seeing the boot messages are >>not an option except without the splash bitmap. I had hoped to provision >>"layout" options and to provide for resolutions, and..., and... >>Similar examples of what I am proposing are already available with Linux, >>the FreeBSD macintosh project, the NetBSD macintosh, and others. >> >>-Chris > > According to the man page, pressing a key will remove the bitmap and allow > boot messages to be seen. Additionally, if you specify -c or -v as a boot > option, the bitmap will not show. Maybe a patch to splash(4) that would > allow for such things as size and placement? > > Just my $.02 Well, that's what this is for. It's an RFC. -Chris > > -Glenn > > >> > >> > -Glenn >> > >> >>-Chris //////////////////////////////////////////////////// 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 Wed Apr 27 08:35: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 D0E0016A4CE for ; Wed, 27 Apr 2005 08:35:46 +0000 (GMT) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id A990943D5D for ; Wed, 27 Apr 2005 08:35:46 +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 1DQi1J-000HCZ-Eg; Wed, 27 Apr 2005 08:35:45 +0000 Received: from [127.0.0.1] (helo=roam.psg.com.psg.com) by roam.psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DQi1G-0002jR-Es; Tue, 26 Apr 2005 22:35:42 -1000 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17007.20189.955737.794871@roam.psg.com> Date: Tue, 26 Apr 2005 22:35:41 -1000 To: Kris Kennaway References: <17006.19740.605509.984940@roam.psg.com> <20050426185144.GA25420@xor.obsecurity.org> cc: FreeBSD Current Subject: Re: ule+preempt? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 27 Apr 2005 08:35:46 -0000 > On Tue, Apr 26, 2005 at 04:15:56AM -1000, Randy Bush wrote: >> having been seriously burned, i have avoided ule for some months. >> i am wondering if the waters have become relatively safe to go >> to ule with preemption? > No, it can cause panics and is not yet reliable in my testing. i think i'll stay superstitious. it's bleedin' edgy enough around here already, as i run production machines on -current (yes, i know). randy From owner-freebsd-current@FreeBSD.ORG Wed Apr 27 09:21: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 3842B16A4CE for ; Wed, 27 Apr 2005 09:21:33 +0000 (GMT) Received: from fast.dnswatch.com (fast.dnswatch.com [216.177.243.43]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8DF3843D5A for ; Wed, 27 Apr 2005 09:21:32 +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 j3R9LRsm063662; Wed, 27 Apr 2005 02:21:31 -0700 (PDT) (envelope-from null@dnswatch.com) Received: (from www@localhost) by fast.dnswatch.com (8.12.6/8.12.6/Submit) id j3R9LQSj063661; Wed, 27 Apr 2005 02:21:26 -0700 (PDT) (envelope-from null@dnswatch.com) X-Authentication-Warning: fast.dnswatch.com: www set sender to null@dnswatch.com using -f Received: from demon.dnswatch.com ([216.177.243.42]) (DNSwatch.com_WebMail authenticated user null) by webmail.dnswatch.com with HTTP; Wed, 27 Apr 2005 02:21:25 -0700 (PDT) Message-ID: <61364.216.177.243.42.1114593685.localmail@webmail.dnswatch.com> In-Reply-To: <20050427083649.GC6929@ns2.wananchi.com> References: <63349.216.177.243.42.1114575288.localmail@webmail.dnswatch.com> <20050427060414.GA54657@ns2.wananchi.com> <55065.216.177.243.42.1114583234.localmail@webmail.dnswatch.com> <20050427083649.GC6929@ns2.wananchi.com> Date: Wed, 27 Apr 2005 02:21:25 -0700 (PDT) From: "/dev/null" To: freebsd-current@freebsd.org, "Odhiambo Washington" 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: can't build kernel [with CONFIG this time] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 27 Apr 2005 09:21:33 -0000 Read on... > * /dev/null [20050427 09:27]: wrote: >> Odhiambo Washington, >> Thank you for your thoughtful reply. According to the documentation >> located at: >> http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig-building.html >> ... >> For example: >> >> # cd /usr/src/sys/i386/conf >> # mkdir /root/kernels >> # cp GENERIC /root/kernels/MYKERNEL >> # ln -s /root/kernels/MYKERNEL >> ... >> So, in case it is not yet apparent, DEMON01 is located in /root/krenels >> and the link is located in /usr/src/sys/i386/conf (yes I re-created it >> after re-installing src). >> >> Are we on the same page yet. ;) > > I have been compiling kernels for the last 8 years, so I am not gonna > read the documentation again about how to do it, but as sure as day > follows night, the "ln -s /root/kernels/MYKERNEL" is a useless step! O.K. I don't want to be argumentative here, or do I ;) But seriously, I just performed surgery on a P2B-AE motherboard. What I have done is simply provided support for the bus speeds that the boards timer is capable of providing, but that ASUS removed for SONY. This is a mobo that ASUS used for in-house R&D and later sold to SONY who sent it out as a VAIO. As it (the board) was the proto for the ASUS P3B-1394, I am using that BIOS image as opposed to the one that SONY provided. Of course this required some soldering and other witchcraft. ANYWAY, to the point; After all this voodoo I followed the instructions as described *verbatum* and it runs like a top. Built as expected, ran as expected. Now this one which required *no* voodoo won't build at all! SO, (not to discount the value of your shared wisdom, and years of experience) what I intend to do, is: cd /, rm -fr . Then with 5.4-RC3 in the CDROM, reboot, newfs, install, reboot and see what happens after a cvsup -g -L 2 , make buildworld, make buildkernel KERNCONF=CUSTKERN, make installkernel KERNCONF=CUSTKERN, reboot, boot -s, /etc/rc.d/preseedrandom, mergmaster -p, make installworld, mergemaster, reboot, boot kernel. Why you may ask? Because I performed a rm -fr /usr/src, downloaded/unpacked 5.4-RC3 src. cvsup -g -L2 , make buildworld. And it froze again before finishing. After rebooting to single user mode and performing: fsck -f and rebooting, then running make buildworld, it PANICED, then REBOOTED, and I SAID !!!ENOUGH!!! I hope I have been concise enough that there is no doubt or confusion on any of this. :) -Chris P.S. Thanks for taking the time to follow and assist on this. > > Better follow my step ;) > > What I normally do: > > 1. get the latest sources > 2. make buildworld > 3. make kernel KERNCONF=MYKERNEL > 4. Reboot > 5. cd /usr/src > 6. make installworld > 7. mergemaster > > You can split the "make kernel" into "make buildkernel and make > installkernel" but I always don't split them. However, (1) and (2) are > mandatory to me, and many others. It's from the handbook, no? > > > > -Wash > > http://www.netmeister.org/news/learn2quote.html > > -- > +======================================================================+ > |\ _,,,---,,_ | Odhiambo Washington > Zzz /,`.-'`' -. ;-;;,_ | Wananchi Online Ltd. www.wananchi.com > |,4- ) )-,_. ,\ ( `'-'| Tel: +254 20 313985-9 +254 20 313922 > '---''(_/--' `-'\_) | GSM: +254 722 743223 +254 733 744121 > +======================================================================+ > I'm a Lisp variable -- bind me! > //////////////////////////////////////////////////// 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 Wed Apr 27 09:30: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 4372A16A4CE for ; Wed, 27 Apr 2005 09:30:02 +0000 (GMT) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id B62F943D39 for ; Wed, 27 Apr 2005 09:30:01 +0000 (GMT) (envelope-from kometen@gmail.com) Received: by rproxy.gmail.com with SMTP id a41so118501rng for ; Wed, 27 Apr 2005 02:30:01 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=I/+wobZB0nvCmsWhHOsldPy2pmDCFWJRxsdsLnDORszmLN1AdEq32ZSE3qd0J7Uc1vrp2p6Qtf66CXCPYYt0/xp2GcDmg9IDjgory2BxLGLs68c+zU08U9lUrZsezdF7W9gJpFblcbalae72ane+QVEaBh8YDiAgAjFwwNW/W8E= Received: by 10.38.12.8 with SMTP id 8mr797194rnl; Wed, 27 Apr 2005 02:30:01 -0700 (PDT) Received: by 10.38.149.53 with HTTP; Wed, 27 Apr 2005 02:30:01 -0700 (PDT) Message-ID: Date: Wed, 27 Apr 2005 11:30:01 +0200 From: Claus Guttesen To: current@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Subject: error building libexec/rtld-elf X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Claus Guttesen List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2005 09:30:02 -0000 Did a buildworld from sources from Apr. 27'th at 11.00 GMT +1. =3D=3D=3D> libexec/rtld-elf (all) cc -O2 -pipe -funroll-loops -march=3Dpentium4 -Wall -DFREEBSD_ELF -DIN_RTLD -I/usr/src/libexec/rtld-elf/i386 -I/usr/src/libexec/rtld-elf -elf -fpic -DPIC -Wformat=3D2 -Wno-format-extra-args -Werror -c /usr/src/libexec/rtld-elf/i386/rtld_start.S cc -O2 -pipe -funroll-loops -march=3Dpentium4 -Wall -DFREEBSD_ELF -DIN_RTLD -I/usr/src/libexec/rtld-elf/i386 -I/usr/src/libexec/rtld-elf -elf -fpic -DPIC -Wformat=3D2 -Wno-format-extra-args -Werror -c /usr/src/libexec/rtld-elf/i386/reloc.c /usr/src/libexec/rtld-elf/i386/reloc.c: In function `allocate_initial_tls': /usr/src/libexec/rtld-elf/i386/reloc.c:339: warning: implicit declaration of function `alloca_tls' /usr/src/libexec/rtld-elf/i386/reloc.c:339: warning: assignment makes pointer from integer without a cast *** Error code 1 Stop in /usr/src/libexec/rtld-elf. *** Error code 1 regards Claus From owner-freebsd-current@FreeBSD.ORG Wed Apr 27 11:34: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 9DB8416A4CE for ; Wed, 27 Apr 2005 11:34:25 +0000 (GMT) Received: from arginine.spc.org (arginine.spc.org [83.167.185.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4600F43D53 for ; Wed, 27 Apr 2005 11:34:25 +0000 (GMT) (envelope-from bms@spc.org) Received: from localhost (localhost [127.0.0.1]) by arginine.spc.org (Postfix) with ESMTP id 511D36530A; Wed, 27 Apr 2005 12:33:35 +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 12053-02; Wed, 27 Apr 2005 12:33:34 +0100 (BST) Received: from empiric.dek.spc.org (82-35-116-62.cable.ubr07.dals.blueyonder.co.uk [82.35.116.62]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by arginine.spc.org (Postfix) with ESMTP id 3A4C6652FE; Wed, 27 Apr 2005 12:33:34 +0100 (BST) Received: by empiric.dek.spc.org (Postfix, from userid 1001) id 8FB20625F; Wed, 27 Apr 2005 12:34:18 +0100 (BST) Date: Wed, 27 Apr 2005 12:34:18 +0100 From: Bruce M Simpson To: kylin Message-ID: <20050427113418.GD5585@empiric.icir.org> Mail-Followup-To: kylin , freebsd-current@freebsd.org References: <87ab37ab050425205527cecaf3@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87ab37ab050425205527cecaf3@mail.gmail.com> cc: freebsd-current@freebsd.org Subject: Re: when will pci hotplug 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, 27 Apr 2005 11:34:25 -0000 On Tue, Apr 26, 2005 at 11:55:41AM +0800, kylin wrote: > so ,I wonder if the freebsd 5.4 or later version will support PCI > hotplug, if there is long time enought before the official providing > utility,i may develop it on my own, or i will just wait asn see :) I began doing some of the required work in order to support my Mobility Electronics EasiDock 5000, which is currently in storage in Berkeley after having moved back to London proper (hopefully picking up or shipping it next month). The EasiDock 5000 is a CardBus-to-PCI device. Whilst it doesn't conform to any of the other PCI Hotplug standards (it is just a hot-pluggable PCI bus) the code which needed to be written adds the necessary code paths to our PCI bus drivers to back out of bus resource allocations and detach instances cleanly. The patches to do this are currently in my p4 branch of 5.4-RC1. The thing we haven't worked out how to do just yet is how to divide the necessary resources in a strictly hierarchical way. Regards, BMS From owner-freebsd-current@FreeBSD.ORG Wed Apr 27 05:46: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 B253216A4CE for ; Wed, 27 Apr 2005 05:46:44 +0000 (GMT) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.202]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4BBC043D49 for ; Wed, 27 Apr 2005 05:46:44 +0000 (GMT) (envelope-from nomadlogic@gmail.com) Received: by wproxy.gmail.com with SMTP id 69so163619wra for ; Tue, 26 Apr 2005 22:46:43 -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=noXFiLLklV6A9q55+3mKiJHvMYxHREjFBPcimEgCo05taxQ1CDBJv+7a3HbRdICLgCWKeP7cr+tgqb8Z/iOzfRtZAs3rr/EUJw1qBz0t+xZqY4KSkoPx3rSp/7GDxG96yQm9HGFZ9D/JASfUfOJSQPVBy9ic+0hTBGm4oiBxF10= Received: by 10.54.112.7 with SMTP id k7mr349148wrc; Tue, 26 Apr 2005 22:46:43 -0700 (PDT) Received: by 10.54.102.12 with HTTP; Tue, 26 Apr 2005 22:46:43 -0700 (PDT) Message-ID: <57d7100005042622465e45ffe0@mail.gmail.com> Date: Tue, 26 Apr 2005 22:46:43 -0700 From: pete wright To: /dev/null In-Reply-To: <63349.216.177.243.42.1114575288.localmail@webmail.dnswatch.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <63349.216.177.243.42.1114575288.localmail@webmail.dnswatch.com> X-Mailman-Approved-At: Wed, 27 Apr 2005 12:02:52 +0000 cc: freebsd-current@freebsd.org Subject: Re: can't build kernel [with CONFIG this time] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: pete wright List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2005 05:46:45 -0000 On 4/26/05, /dev/null wrote: > Hello, > Just got a new CPU today. Running 5.4-RC3 on GENERIC until the new CPU > showed up. Installed the CPU drafted a new config for the kernel cd'd to > /usr/src, typed "make buildkernel KERNCONF=3DDEMON01", build process went= as > expected. But before the build process completed the machine froze for no > apparent reason at the sound driver part. Couldn't ssh into it from anoth= er > box, so hit the reset button, chose 4 from the menu (single user mode). > Performed a fsck -f. Rebooted and attempted to rebuild. But it barfed. > So I performed an rm -fr /usr/src. > Then /stand/sysinstall > install entire src tree and tried another > "make buildkernel KERNCONF=3DDEMON01" in /usr/src. > It barfed with the following: Have you tried building a GENERIC kernel with this config? Also have you cvsup'd your source tree. I know you re-downloaded the source from /stand/sysinstall, but you may want to get it via cvsup.=20 Especially with the 5.4 RC's. If you are able to build a GENERIC kernel, and the problem occurs after a cvsup then I would suspect there is something broken in your custom config. HTH -p --=20 ~~o0OO0o~~ Pete Wright www.nycbug.org NYC's *BSD User Group From owner-freebsd-current@FreeBSD.ORG Wed Apr 27 06:18: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 A67E616A4CE for ; Wed, 27 Apr 2005 06:18:11 +0000 (GMT) Received: from tower.berklix.org (bsd.bsn.com [194.221.32.7]) by mx1.FreeBSD.org (Postfix) with ESMTP id A0EFD43D2F for ; Wed, 27 Apr 2005 06:18:10 +0000 (GMT) (envelope-from jhs@flat.berklix.net) Received: from js.berklix.net (p549A758E.dip.t-dialin.net [84.154.117.142]) (authenticated bits=0) by tower.berklix.org (8.12.9p2/8.12.9) with ESMTP id j3R6I28o081096; Wed, 27 Apr 2005 08:18:03 +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 j3R6I0E7001031; Wed, 27 Apr 2005 08:18:01 +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 j3R6I0cT007044; Wed, 27 Apr 2005 08:18:00 +0200 (CEST) (envelope-from jhs@fire.jhs.private) Message-Id: <200504270618.j3R6I0cT007044@fire.jhs.private> To: Emanuel Strobl In-Reply-To: Message from Emanuel Strobl of "Tue, 26 Apr 2005 20:10:41 +0200." <200504262010.49509@harrymail> Date: Wed, 27 Apr 2005 08:18:00 +0200 From: "Julian H. Stacey" X-Mailman-Approved-At: Wed, 27 Apr 2005 12:02:52 +0000 cc: Phil Cockcroft cc: freebsd-current@freebsd.org Subject: Re: groff alternative? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 27 Apr 2005 06:18:11 -0000 > cc: freebsd-questions@freebsd.org, freebsd-current@freebsd.org I dropped freebsd-question@freebsd.org to avoid cross posting, deprecated on FreeBSD.org lists. Emanuel Strobl wrote: > --nextPart3677596.j3orVY53Xm > Content-Type: text/plain; > charset="us-ascii" > Content-Transfer-Encoding: quoted-printable > Content-Disposition: inline > > Hello, > > I'm using NO_CXX in my make.conf to strip down the base system to ~50MB=20 > including man pages. The only problem is that groff is missing if I don't=20 > build c++, and even if I build groff itself and the needed libstdc++ it cos= > ts=20 > me about 10MB. If I just skip NO_CXX it's only 500k more, so I moved my=20 > patches to /dev/null. > > Now I wrote a port for GNU/groff, but this also consumes 9974k by default a= > nd=20 > I don't want to include patches into that port to strip down groff, if that= > =20 > was possible at all. > > Does anybody know any alternative for the groff part to view man pages simp= > ly=20 > with the man command? It's horrible that the filter needs more space than a= > ll=20 > the manpages itself! > > And of course, even if I decide to leave system man pages outside the flash= > =20 > card I still may want to read man pages of installed packages (which is=20 > another mountpoint on my installation, so there may be no space limit,=20 > depending on the card and additional drives) > > Thanks, > > =2DHarry Years back "Phil Cockcroft" cc'd wrote a simple roff tool for ascii formatting .rof stuff eg Unix manuals. Ran under dos & Unix. Some files are dated 1994. http://berklix.com/~jhs/src/odds/c/unix4dos/nroff du: 110K, doesnt need C++, Might need a little macro faking/ tweaking to do modern BSD manuals. - 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 Wed Apr 27 06:35: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 B6E0A16A4CE for ; Wed, 27 Apr 2005 06:35:51 +0000 (GMT) Received: from cobalt.antimatter.net (cobalt.antimatter.net [69.55.224.239]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7FBE343D4C for ; Wed, 27 Apr 2005 06:35:51 +0000 (GMT) (envelope-from glenn@antimatter.net) Received: from glenn-mobile.antimatter.net (cpe-66-27-94-59.san.res.rr.com [66.27.94.59]) (authenticated bits=0)j3R6ZhmG011861 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NO); Tue, 26 Apr 2005 23:35:44 -0700 Message-Id: <6.1.0.6.2.20050426233321.084e9210@cobalt.antimatter.net> X-Sender: lists@cobalt.antimatter.net X-Mailer: QUALCOMM Windows Eudora Version 6.1.0.6 Date: Tue, 26 Apr 2005 23:35:14 -0700 To: "/dev/null" , freebsd-current@freebsd.org From: Glenn Dawson In-Reply-To: <57436.216.177.243.42.1114582155.localmail@webmail.dnswatch .com> References: <57436.216.177.243.42.1114582155.localmail@webmail.dnswatch.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Mailman-Approved-At: Wed, 27 Apr 2005 12:02:52 +0000 Subject: Re: boot banner project X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 27 Apr 2005 06:35:51 -0000 At 11:09 PM 4/26/2005, /dev/null wrote: >Hello any & all, > O.K. I feel I must preface this with an acknowledgment that I *know* >this is a silly project *because* given the *incredibly* long uptimes >that FreeBSD is known for. >>But<< for those *few* times when FreeBSDers >see a boot screen, shouldn't it look really nice? Shouldn't also be able >to reflect the Administrators tastes and personality? Well, this is the >premise for my attempting this project. But before I start, I want to >submit an RFC. So consider this an Request for comments. This is an >attempt to create a Graphical boot screen that initially has the >following layout: >(a fixed width font required to view the layout correctly) > -------------------------------------------------------- >| some | >| sort | >| of | >| graphic goes in this area | >|-------------------------------------------------------- >| boot | >| | >| messages | >| | >| seen | >| | >| here | >| bla... | >| bla... | >| bla... | >--------------------------------------------------------- Isn't this essentially what splash(4)is for? -Glenn >-Chris > >//////////////////////////////////////////////////// > 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. >//////////////////////////////////////////////////// >_______________________________________________ >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 27 09:02: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 4605816A4CF for ; Wed, 27 Apr 2005 09:02:21 +0000 (GMT) Received: from orb.pobox.com (orb.pobox.com [207.8.226.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3D80643D55 for ; Wed, 27 Apr 2005 09:02:20 +0000 (GMT) (envelope-from discussion-lists@linnet.org) Received: from orb (localhost [127.0.0.1]) by orb.pobox.com (Postfix) with ESMTP id C3C4E788 for ; Wed, 27 Apr 2005 05:02:16 -0400 (EDT) Received: from thinkdog.local.linnet.org (host217-40-157-153.in-addr.btopenworld.com [217.40.157.153]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by orb.sasl.smtp.pobox.com (Postfix) with ESMTP id 61EB287 for ; Wed, 27 Apr 2005 05:02:14 -0400 (EDT) Received: from lists by thinkdog.local.linnet.org with local (Exim 4.43 (FreeBSD)) id 1DQiQf-000MBw-GG for freebsd-current@freebsd.org; Wed, 27 Apr 2005 10:01:57 +0100 Date: Wed, 27 Apr 2005 10:01:57 +0100 From: Brian Candler To: freebsd-current@freebsd.org Message-ID: <20050427090157.GA85275@uk.tiscali.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-Mailman-Approved-At: Wed, 27 Apr 2005 12:02:52 +0000 Subject: ISDN kernel build fials X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 27 Apr 2005 09:02:21 -0000 FYI, building -CURRENT as of yesterday, with NO_IPFILTER=yes in make.conf make buildworld was successful. make buildkernel KERNCONF=FOO gave: cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/export/src/5.3-RELEASE/usr/src/sys -I/export/src/5.3-RELEASE/usr/src/sys/contrib/dev/acpica -I/export/src/5.3-RELEASE/usr/src/sys/contrib/altq -I/export/src/5.3-RELEASE/usr/src/sys/contrib/ipfilter -I/export/src/5.3-RELEASE/usr/src/sys/contrib/pf -I/export/src/5.3-RELEASE/usr/src/sys/contrib/dev/ath -I/export/src/5.3-RELEASE/usr/src/sys/contrib/dev/ath/freebsd -I/export/src/5.3-RELEASE/usr/src/sys/contrib/ngatm -I/export/src/5.3-RELEASE/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 /export/src/5.3-RELEASE/usr/src/sys/i4b/driver/i4b_trace.c /export/src/5.3-RELEASE/usr/src/sys/i4b/driver/i4b_trace.c:59: error: `NI4BTRC' undeclared here (not in a function) /export/src/5.3-RELEASE/usr/src/sys/i4b/driver/i4b_trace.c:59: error: storage size of `trace_queue' isn't known /export/src/5.3-RELEASE/usr/src/sys/i4b/driver/i4b_trace.c:61: error: storage size of `device_state' isn't known /export/src/5.3-RELEASE/usr/src/sys/i4b/driver/i4b_trace.c:59: warning: 'trace_queue' defined but not used /export/src/5.3-RELEASE/usr/src/sys/i4b/driver/i4b_trace.c:61: warning: 'device_state' defined but not used *** Error code 1 Stop in /usr/obj/export/src/5.3-RELEASE/usr/src/sys/FOO. *** Error code 1 Stop in /export/src/5.3-RELEASE/usr/src. *** Error code 1 Stop in /export/src/5.3-RELEASE/usr/src. The FOO kernel config is given below, as a diff against current's GENERIC. More or less the same config had worked on 5.3-RELEASE, except I had counts for some of the devices, e.g. device "i4btrc" 4 which I had to change to device "i4btrc" to get config to work with -CURRENT. Regards, Brian Candler. --- GENERIC Thu Mar 31 21:21:42 2005 +++ FOO Wed Apr 27 09:33:12 2005 @@ -19,10 +19,10 @@ # $FreeBSD: src/sys/i386/conf/GENERIC,v 1.428 2005/03/31 20:21:42 scottl Exp $ machine i386 -cpu I486_CPU +#cpu I486_CPU cpu I586_CPU cpu I686_CPU -ident GENERIC +ident FOO # To statically compile in device wiring instead of /boot/device.hints #hints "GENERIC.hints" # Default places to look for devices. @@ -291,3 +291,199 @@ device firewire # FireWire bus code device sbp # SCSI over FireWire (Requires scbus and da) device fwe # Ethernet over FireWire (non-standard!) + +#----- +# Added by Brian + +device pf +device pflog + +#--------------------------------------------------------------------------- +# ISDN4BSD +# +# See /usr/share/examples/isdn/ROADMAP for an introduction to isdn4bsd. +# +# i4b passive ISDN cards support contains the following hardware drivers: +# +# isic - Siemens/Infineon ISDN ISAC/HSCX/IPAC chipset driver +# iwic - Winbond W6692 PCI bus ISDN S/T interface controller +# ifpi - AVM Fritz!Card PCI driver +# ifpi2 - AVM Fritz!Card PCI version 2 driver +# ihfc - Cologne Chip HFC ISA/ISA-PnP chipset driver +# ifpnp - AVM Fritz!Card PnP driver +# itjc - Siemens ISAC / TJNet Tiger300/320 chipset +# +# i4b active ISDN cards support contains the following hardware drivers: +# +# iavc - AVM B1 PCI, AVM B1 ISA, AVM T1 +# +# Note that the ``options'' (if given) and ``device'' lines must BOTH +# be uncommented to enable support for a given card ! +# +# In addition to a hardware driver (and probably an option) the mandatory +# ISDN protocol stack devices and the mandatory support device must be +# enabled as well as one or more devices from the optional devices section. +# +#--------------------------------------------------------------------------- +# isic driver (Siemens/Infineon chipsets) +# +device isic +# +# ISA bus non-PnP Cards: +# ---------------------- +# +# Teles S0/8 or Niccy 1008 +options TEL_S0_8 +# +# Teles S0/16 or Creatix ISDN-S0 or Niccy 1016 +options TEL_S0_16 +# +# Teles S0/16.3 +options TEL_S0_16_3 +# +# AVM A1 or AVM Fritz!Card +options AVM_A1 +# +# USRobotics Sportster ISDN TA intern +options USR_STI +# +# ITK ix1 Micro ( < V.3, non-PnP version ) +options ITKIX1 +# +# ELSA PCC-16 +options ELSA_PCC16 +# +# ISA bus PnP Cards: +# ------------------ +# +# Teles S0/16.3 PnP +options TEL_S0_16_3_P +# +# Creatix ISDN-S0 P&P +options CRTX_S0_P +# +# Dr. Neuhaus Niccy Go@ +options DRN_NGO +# +# Sedlbauer Win Speed +options SEDLBAUER +# +# Dynalink IS64PH +options DYNALINK +# +# ELSA QuickStep 1000pro ISA +options ELSA_QS1ISA +# +# Siemens I-Surf 2.0 +options SIEMENS_ISURF2 +# +# Asuscom ISDNlink 128K ISA +options ASUSCOM_IPAC +# +# Eicon Diehl DIVA 2.0 and 2.02 +options EICON_DIVA +# +# Compaq Microcom 610 ISDN card (Compaq series PSB2222I) +options COMPAQ_M610 +# +# PCI bus Cards: +# -------------- +# +# ELSA MicroLink ISDN/PCI (same as ELSA QuickStep 1000pro PCI) +options ELSA_QS1PCI +# +#--------------------------------------------------------------------------- +# ifpnp driver for AVM Fritz!Card PnP +# +# AVM Fritz!Card PnP +device ifpnp +# +#--------------------------------------------------------------------------- +# ihfc driver for Cologne Chip ISA chipsets (experimental!) +# +# Teles 16.3c ISA PnP +# AcerISDN P10 ISA PnP +# TELEINT ISDN SPEED No.1 +device ihfc +# +#--------------------------------------------------------------------------- +# ifpi driver for AVM Fritz!Card PCI +# +# AVM Fritz!Card PCI +device ifpi +# +#--------------------------------------------------------------------------- +# ifpi2 driver for AVM Fritz!Card PCI version 2 +# +# AVM Fritz!Card PCI version 2 +device "ifpi2" +# +#--------------------------------------------------------------------------- +# iwic driver for Winbond W6692 chipset +# +# ASUSCOM P-IN100-ST-D (and other Winbond W6692 based cards) +device iwic +# +#--------------------------------------------------------------------------- +# itjc driver for Siemens ISAC / TJNet Tiger300/320 chipset +# +# Traverse Technologies NETjet-S +# Teles PCI-TJ +device itjc +# +#--------------------------------------------------------------------------- +# iavc driver (AVM active cards, needs i4bcapi driver!) +# +device iavc +# +# AVM B1 ISA bus (PnP mode not supported!) +# ---------------------------------------- +# +#--------------------------------------------------------------------------- +# ISDN Protocol Stack - mandatory for all hardware drivers +# +# Q.921 / layer 2 - i4b passive cards D channel handling +device "i4bq921" +# +# Q.931 / layer 3 - i4b passive cards D channel handling +device "i4bq931" +# +# layer 4 - i4b common passive and active card handling +device "i4b" +# +#--------------------------------------------------------------------------- +# ISDN devices - mandatory for all hardware drivers +# +# userland driver to do ISDN tracing (for passive cards only) +device "i4btrc" +# +# userland driver to control the whole thing +device "i4bctl" +# +#--------------------------------------------------------------------------- +# ISDN devices - optional +# +# userland driver for access to raw B channel +device "i4brbch" +# +# userland driver for telephony +device "i4btel" +# +# network driver for IP over raw HDLC ISDN +device "i4bipr" +# enable VJ header compression detection for ipr i/f +options IPR_VJ +# enable logging of the first n IP packets to isdnd (n=32 here) +options IPR_LOG=32 +# +# network driver for sync PPP over ISDN; requires an equivalent +# number of sppp device to be configured +device "i4bisppp" +# +# B-channel interface to the netgraph subsystem +#device "i4bing" +# +# CAPI driver needed for active ISDN cards (see iavc driver above) +#device "i4bcapi" +# +#--------------------------------------------------------------------------- From owner-freebsd-current@FreeBSD.ORG Wed Apr 27 12:06: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 474F416A4CE for ; Wed, 27 Apr 2005 12:06:18 +0000 (GMT) Received: from mh1.centtech.com (moat3.centtech.com [207.200.51.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8F01043D5F for ; Wed, 27 Apr 2005 12:06:17 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from [10.177.171.220] (neutrino.centtech.com [10.177.171.220]) by mh1.centtech.com (8.13.1/8.13.1) with ESMTP id j3RC6Bq1051638; Wed, 27 Apr 2005 07:06:12 -0500 (CDT) (envelope-from anderson@centtech.com) Message-ID: <426F7FFE.2030903@centtech.com> Date: Wed, 27 Apr 2005 07:05:18 -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: /dev/null References: <63349.216.177.243.42.1114575288.localmail@webmail.dnswatch.com> <57d7100005042622465e45ffe0@mail.gmail.com> In-Reply-To: <57d7100005042622465e45ffe0@mail.gmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.82/856/Wed Apr 27 02:00:37 2005 on mh1.centtech.com X-Virus-Status: Clean cc: freebsd-current@freebsd.org Subject: Re: can't build kernel [with CONFIG this time] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 27 Apr 2005 12:06:18 -0000 pete wright wrote: > On 4/26/05, /dev/null wrote: > >>Hello, >> Just got a new CPU today. Running 5.4-RC3 on GENERIC until the new CPU >>showed up. Installed the CPU drafted a new config for the kernel cd'd to >>/usr/src, typed "make buildkernel KERNCONF=DEMON01", build process went as >>expected. But before the build process completed the machine froze for no >>apparent reason at the sound driver part. Couldn't ssh into it from another >>box, so hit the reset button, chose 4 from the menu (single user mode). >>Performed a fsck -f. Rebooted and attempted to rebuild. But it barfed. >>So I performed an rm -fr /usr/src. >>Then /stand/sysinstall > install entire src tree and tried another >>"make buildkernel KERNCONF=DEMON01" in /usr/src. >>It barfed with the following: > > > Have you tried building a GENERIC kernel with this config? Also have > you cvsup'd your source tree. I know you re-downloaded the source > from /stand/sysinstall, but you may want to get it via cvsup. > Especially with the 5.4 RC's. If you are able to build a GENERIC > kernel, and the problem occurs after a cvsup then I would suspect > there is something broken in your custom config. Maybe rm -rf /usr/obj/ then retrying the build? I didn't see that you tried that, although it probably won't do anything different. 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 Wed Apr 27 12:37: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 F06D916A4CE; Wed, 27 Apr 2005 12:37:32 +0000 (GMT) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 674D943D53; Wed, 27 Apr 2005 12:37:32 +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 j3RCbVEH021901; Wed, 27 Apr 2005 08:37:31 -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 j3RCc2Xu008897; Wed, 27 Apr 2005 08:38:02 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 87A3F7306E; Wed, 27 Apr 2005 08:37:31 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050427123731.87A3F7306E@freebsd-current.sentex.ca> Date: Wed, 27 Apr 2005 08:37:31 -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 alpha/alpha 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, 27 Apr 2005 12:37:33 -0000 TB --- 2005-04-27 12:30:00 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-04-27 12:30:00 - starting CURRENT tinderbox run for alpha/alpha TB --- 2005-04-27 12:30:00 - checking out the source tree TB --- 2005-04-27 12:30:00 - cd /home/tinderbox/CURRENT/alpha/alpha TB --- 2005-04-27 12:30:00 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-04-27 12:36:34 - building world (CFLAGS=-O2 -pipe) TB --- 2005-04-27 12:36:34 - cd /home/tinderbox/CURRENT/alpha/alpha/src TB --- 2005-04-27 12:36: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 [...] ===> rescue/rescue/ipf/ipnat (clean) rm -f ipnat_y.c ipnat_y.h ipnat_l.c ipnat_l.h y.tab.c y.tab.h ipnat ipnat.o ipnat_y.o ipnat_l.o ipnat.8.gz ipnat.4.gz ipnat.5.gz ipnat.8.cat.gz ipnat.4.cat.gz ipnat.5.cat.gz ===> rescue/rescue/ipf/ippool (clean) rm -f ippool_y.c ippool_y.h ippool_l.c ippool_l.h y.tab.c y.tab.h ippool ippool_y.o ippool_l.o kmem.o ippool.o ippool.5.gz ippool.8.gz ippool.5.cat.gz ippool.8.cat.gz ===> rescue/rescue/ipf/ipresend (clean) rm -f y.tab.c y.tab.h ipresend ipresend.o ip.o resend.o sbpf.o sock.o 44arp.o ipresend.1.gz ipresend.1.cat.gz cd /tinderbox/CURRENT/alpha/alpha/src/rescue/rescue/../../sbin/ipfs && MAKEOBJDIRPREFIX=/home/tinderbox/CURRENT/alpha/alpha/obj/alpha/tinderbox/CURRENT/alpha/alpha/src/rescue/rescue /home/tinderbox/CURRENT/alpha/alpha/obj/tinderbox/CURRENT/alpha/alpha/src/make.i386/make DIRPRFX=rescue/rescue/ipfs/ clean cd: can't cd to /tinderbox/CURRENT/alpha/alpha/src/rescue/rescue/../../sbin/ipfs *** Error code 2 Stop in /tinderbox/CURRENT/alpha/alpha/src/rescue/rescue. *** Error code 1 Stop in /tinderbox/CURRENT/alpha/alpha/src/rescue. *** Error code 1 Stop in /tinderbox/CURRENT/alpha/alpha/src. *** Error code 1 Stop in /tinderbox/CURRENT/alpha/alpha/src. *** Error code 1 Stop in /tinderbox/CURRENT/alpha/alpha/src. TB --- 2005-04-27 12:37:31 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-04-27 12:37:31 - ERROR: failed to build world TB --- 2005-04-27 12:37:31 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Wed Apr 27 12:41: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 AEF4E16A4CE; Wed, 27 Apr 2005 12:41:14 +0000 (GMT) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2708943D53; Wed, 27 Apr 2005 12:41:14 +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 j3RCfDT8022233; Wed, 27 Apr 2005 08:41:13 -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 j3RCfiCt010929; Wed, 27 Apr 2005 08:41:44 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 7609A7306E; Wed, 27 Apr 2005 08:41:13 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050427124113.7609A7306E@freebsd-current.sentex.ca> Date: Wed, 27 Apr 2005 08:41:13 -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 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, 27 Apr 2005 12:41:14 -0000 TB --- 2005-04-27 12:37:31 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-04-27 12:37:31 - starting CURRENT tinderbox run for amd64/amd64 TB --- 2005-04-27 12:37:31 - checking out the source tree TB --- 2005-04-27 12:37:31 - cd /home/tinderbox/CURRENT/amd64/amd64 TB --- 2005-04-27 12:37:31 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-04-27 12:40:15 - building world (CFLAGS=-O2 -pipe) TB --- 2005-04-27 12:40:15 - cd /home/tinderbox/CURRENT/amd64/amd64/src TB --- 2005-04-27 12:40:15 - /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 [...] ===> rescue/rescue/ipf/ipnat (clean) rm -f ipnat_y.c ipnat_y.h ipnat_l.c ipnat_l.h y.tab.c y.tab.h ipnat ipnat.o ipnat_y.o ipnat_l.o ipnat.8.gz ipnat.4.gz ipnat.5.gz ipnat.8.cat.gz ipnat.4.cat.gz ipnat.5.cat.gz ===> rescue/rescue/ipf/ippool (clean) rm -f ippool_y.c ippool_y.h ippool_l.c ippool_l.h y.tab.c y.tab.h ippool ippool_y.o ippool_l.o kmem.o ippool.o ippool.5.gz ippool.8.gz ippool.5.cat.gz ippool.8.cat.gz ===> rescue/rescue/ipf/ipresend (clean) rm -f y.tab.c y.tab.h ipresend ipresend.o ip.o resend.o sbpf.o sock.o 44arp.o ipresend.1.gz ipresend.1.cat.gz cd /tinderbox/CURRENT/amd64/amd64/src/rescue/rescue/../../sbin/ipfs && MAKEOBJDIRPREFIX=/home/tinderbox/CURRENT/amd64/amd64/obj/amd64/tinderbox/CURRENT/amd64/amd64/src/rescue/rescue /home/tinderbox/CURRENT/amd64/amd64/obj/tinderbox/CURRENT/amd64/amd64/src/make.i386/make DIRPRFX=rescue/rescue/ipfs/ clean cd: can't cd to /tinderbox/CURRENT/amd64/amd64/src/rescue/rescue/../../sbin/ipfs *** Error code 2 Stop in /tinderbox/CURRENT/amd64/amd64/src/rescue/rescue. *** Error code 1 Stop in /tinderbox/CURRENT/amd64/amd64/src/rescue. *** 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-27 12:41:13 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-04-27 12:41:13 - ERROR: failed to build world TB --- 2005-04-27 12:41:13 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Wed Apr 27 12:46: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 8809916A4D8; Wed, 27 Apr 2005 12:46:39 +0000 (GMT) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 85F1743D2D; Wed, 27 Apr 2005 12:46:38 +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 j3RCkbV0022855; Wed, 27 Apr 2005 08:46:37 -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 j3RCl9de013804; Wed, 27 Apr 2005 08:47:09 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id B575C7306E; Wed, 27 Apr 2005 08:46:37 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050427124637.B575C7306E@freebsd-current.sentex.ca> Date: Wed, 27 Apr 2005 08:46:37 -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, 27 Apr 2005 12:46:39 -0000 TB --- 2005-04-27 12:41:13 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-04-27 12:41:13 - starting CURRENT tinderbox run for i386/i386 TB --- 2005-04-27 12:41:13 - checking out the source tree TB --- 2005-04-27 12:41:13 - cd /home/tinderbox/CURRENT/i386/i386 TB --- 2005-04-27 12:41:13 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-04-27 12:45:40 - building world (CFLAGS=-O2 -pipe) TB --- 2005-04-27 12:45:40 - cd /home/tinderbox/CURRENT/i386/i386/src TB --- 2005-04-27 12:45:40 - /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 [...] ===> rescue/rescue/ipf/ipnat (clean) rm -f ipnat_y.c ipnat_y.h ipnat_l.c ipnat_l.h y.tab.c y.tab.h ipnat ipnat.o ipnat_y.o ipnat_l.o ipnat.8.gz ipnat.4.gz ipnat.5.gz ipnat.8.cat.gz ipnat.4.cat.gz ipnat.5.cat.gz ===> rescue/rescue/ipf/ippool (clean) rm -f ippool_y.c ippool_y.h ippool_l.c ippool_l.h y.tab.c y.tab.h ippool ippool_y.o ippool_l.o kmem.o ippool.o ippool.5.gz ippool.8.gz ippool.5.cat.gz ippool.8.cat.gz ===> rescue/rescue/ipf/ipresend (clean) rm -f y.tab.c y.tab.h ipresend ipresend.o ip.o resend.o sbpf.o sock.o 44arp.o ipresend.1.gz ipresend.1.cat.gz cd /tinderbox/CURRENT/i386/i386/src/rescue/rescue/../../sbin/ipfs && MAKEOBJDIRPREFIX=/home/tinderbox/CURRENT/i386/i386/obj/tinderbox/CURRENT/i386/i386/src/rescue/rescue /home/tinderbox/CURRENT/i386/i386/obj/tinderbox/CURRENT/i386/i386/src/make.i386/make DIRPRFX=rescue/rescue/ipfs/ clean cd: can't cd to /tinderbox/CURRENT/i386/i386/src/rescue/rescue/../../sbin/ipfs *** Error code 2 Stop in /tinderbox/CURRENT/i386/i386/src/rescue/rescue. *** Error code 1 Stop in /tinderbox/CURRENT/i386/i386/src/rescue. *** 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-27 12:46:37 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-04-27 12:46:37 - ERROR: failed to build world TB --- 2005-04-27 12:46:37 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Wed Apr 27 12:50: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 65B7216A4CE; Wed, 27 Apr 2005 12:50:47 +0000 (GMT) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id CAE7A43D45; Wed, 27 Apr 2005 12:50:46 +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 j3RCokMT013876; Wed, 27 Apr 2005 08:50:46 -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 j3RCokWM055531; Wed, 27 Apr 2005 08:50:46 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 26B107306E; Wed, 27 Apr 2005 08:50:46 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050427125046.26B107306E@freebsd-current.sentex.ca> Date: Wed, 27 Apr 2005 08:50:46 -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 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: Wed, 27 Apr 2005 12:50:47 -0000 TB --- 2005-04-27 12:46:37 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-04-27 12:46:37 - starting CURRENT tinderbox run for i386/pc98 TB --- 2005-04-27 12:46:37 - checking out the source tree TB --- 2005-04-27 12:46:37 - cd /home/tinderbox/CURRENT/i386/pc98 TB --- 2005-04-27 12:46:37 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-04-27 12:49:39 - building world (CFLAGS=-O2 -pipe) TB --- 2005-04-27 12:49:39 - cd /home/tinderbox/CURRENT/i386/pc98/src TB --- 2005-04-27 12:49:39 - /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 [...] ===> rescue/rescue/ipf/ipnat (clean) rm -f ipnat_y.c ipnat_y.h ipnat_l.c ipnat_l.h y.tab.c y.tab.h ipnat ipnat.o ipnat_y.o ipnat_l.o ipnat.8.gz ipnat.4.gz ipnat.5.gz ipnat.8.cat.gz ipnat.4.cat.gz ipnat.5.cat.gz ===> rescue/rescue/ipf/ippool (clean) rm -f ippool_y.c ippool_y.h ippool_l.c ippool_l.h y.tab.c y.tab.h ippool ippool_y.o ippool_l.o kmem.o ippool.o ippool.5.gz ippool.8.gz ippool.5.cat.gz ippool.8.cat.gz ===> rescue/rescue/ipf/ipresend (clean) rm -f y.tab.c y.tab.h ipresend ipresend.o ip.o resend.o sbpf.o sock.o 44arp.o ipresend.1.gz ipresend.1.cat.gz cd /tinderbox/CURRENT/i386/pc98/src/rescue/rescue/../../sbin/ipfs && MAKEOBJDIRPREFIX=/home/tinderbox/CURRENT/i386/pc98/obj/pc98/tinderbox/CURRENT/i386/pc98/src/rescue/rescue /home/tinderbox/CURRENT/i386/pc98/obj/tinderbox/CURRENT/i386/pc98/src/make.i386/make DIRPRFX=rescue/rescue/ipfs/ clean cd: can't cd to /tinderbox/CURRENT/i386/pc98/src/rescue/rescue/../../sbin/ipfs *** Error code 2 Stop in /tinderbox/CURRENT/i386/pc98/src/rescue/rescue. *** Error code 1 Stop in /tinderbox/CURRENT/i386/pc98/src/rescue. *** 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-27 12:50:46 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-04-27 12:50:46 - ERROR: failed to build world TB --- 2005-04-27 12:50:46 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Wed Apr 27 12: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 290F216A4CE; Wed, 27 Apr 2005 12:55:37 +0000 (GMT) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 93A2E43D48; Wed, 27 Apr 2005 12:55:36 +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 j3RCtavm023600; Wed, 27 Apr 2005 08:55:36 -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 j3RCtawX075526; Wed, 27 Apr 2005 08:55:36 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id E59A97306E; Wed, 27 Apr 2005 08:55:35 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050427125535.E59A97306E@freebsd-current.sentex.ca> Date: Wed, 27 Apr 2005 08:55:35 -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: Wed, 27 Apr 2005 12:55:37 -0000 TB --- 2005-04-27 12:50:46 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-04-27 12:50:46 - starting CURRENT tinderbox run for ia64/ia64 TB --- 2005-04-27 12:50:46 - checking out the source tree TB --- 2005-04-27 12:50:46 - cd /home/tinderbox/CURRENT/ia64/ia64 TB --- 2005-04-27 12:50:46 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-04-27 12:54:38 - building world (CFLAGS=-O2 -pipe) TB --- 2005-04-27 12:54:38 - cd /home/tinderbox/CURRENT/ia64/ia64/src TB --- 2005-04-27 12:54:38 - /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 [...] ===> rescue/rescue/ipf/ipnat (clean) rm -f ipnat_y.c ipnat_y.h ipnat_l.c ipnat_l.h y.tab.c y.tab.h ipnat ipnat.o ipnat_y.o ipnat_l.o ipnat.8.gz ipnat.4.gz ipnat.5.gz ipnat.8.cat.gz ipnat.4.cat.gz ipnat.5.cat.gz ===> rescue/rescue/ipf/ippool (clean) rm -f ippool_y.c ippool_y.h ippool_l.c ippool_l.h y.tab.c y.tab.h ippool ippool_y.o ippool_l.o kmem.o ippool.o ippool.5.gz ippool.8.gz ippool.5.cat.gz ippool.8.cat.gz ===> rescue/rescue/ipf/ipresend (clean) rm -f y.tab.c y.tab.h ipresend ipresend.o ip.o resend.o sbpf.o sock.o 44arp.o ipresend.1.gz ipresend.1.cat.gz cd /tinderbox/CURRENT/ia64/ia64/src/rescue/rescue/../../sbin/ipfs && MAKEOBJDIRPREFIX=/home/tinderbox/CURRENT/ia64/ia64/obj/ia64/tinderbox/CURRENT/ia64/ia64/src/rescue/rescue /home/tinderbox/CURRENT/ia64/ia64/obj/tinderbox/CURRENT/ia64/ia64/src/make.i386/make DIRPRFX=rescue/rescue/ipfs/ clean cd: can't cd to /tinderbox/CURRENT/ia64/ia64/src/rescue/rescue/../../sbin/ipfs *** Error code 2 Stop in /tinderbox/CURRENT/ia64/ia64/src/rescue/rescue. *** Error code 1 Stop in /tinderbox/CURRENT/ia64/ia64/src/rescue. *** Error code 1 Stop in /tinderbox/CURRENT/ia64/ia64/src. *** Error code 1 Stop in /tinderbox/CURRENT/ia64/ia64/src. *** Error code 1 Stop in /tinderbox/CURRENT/ia64/ia64/src. TB --- 2005-04-27 12:55:35 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-04-27 12:55:35 - ERROR: failed to build world TB --- 2005-04-27 12:55:35 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Wed Apr 27 12:59: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 44F6D16A4CE; Wed, 27 Apr 2005 12:59:48 +0000 (GMT) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id A58D643D2D; Wed, 27 Apr 2005 12:59:47 +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 j3RCxlnl014750; Wed, 27 Apr 2005 08:59:47 -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 j3RD0IWL020361; Wed, 27 Apr 2005 09:00:18 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 2F86A7306E; Wed, 27 Apr 2005 08:59:47 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050427125947.2F86A7306E@freebsd-current.sentex.ca> Date: Wed, 27 Apr 2005 08:59:47 -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: Wed, 27 Apr 2005 12:59:48 -0000 TB --- 2005-04-27 12:55:36 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-04-27 12:55:36 - starting CURRENT tinderbox run for powerpc/powerpc TB --- 2005-04-27 12:55:36 - checking out the source tree TB --- 2005-04-27 12:55:36 - cd /home/tinderbox/CURRENT/powerpc/powerpc TB --- 2005-04-27 12:55:36 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-04-27 12:58:49 - building world (CFLAGS=-O2 -pipe) TB --- 2005-04-27 12:58:49 - cd /home/tinderbox/CURRENT/powerpc/powerpc/src TB --- 2005-04-27 12:58:49 - /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 [...] ===> rescue/rescue/ipf/ipnat (clean) rm -f ipnat_y.c ipnat_y.h ipnat_l.c ipnat_l.h y.tab.c y.tab.h ipnat ipnat.o ipnat_y.o ipnat_l.o ipnat.8.gz ipnat.4.gz ipnat.5.gz ipnat.8.cat.gz ipnat.4.cat.gz ipnat.5.cat.gz ===> rescue/rescue/ipf/ippool (clean) rm -f ippool_y.c ippool_y.h ippool_l.c ippool_l.h y.tab.c y.tab.h ippool ippool_y.o ippool_l.o kmem.o ippool.o ippool.5.gz ippool.8.gz ippool.5.cat.gz ippool.8.cat.gz ===> rescue/rescue/ipf/ipresend (clean) rm -f y.tab.c y.tab.h ipresend ipresend.o ip.o resend.o sbpf.o sock.o 44arp.o ipresend.1.gz ipresend.1.cat.gz cd /tinderbox/CURRENT/powerpc/powerpc/src/rescue/rescue/../../sbin/ipfs && MAKEOBJDIRPREFIX=/home/tinderbox/CURRENT/powerpc/powerpc/obj/powerpc/tinderbox/CURRENT/powerpc/powerpc/src/rescue/rescue /home/tinderbox/CURRENT/powerpc/powerpc/obj/tinderbox/CURRENT/powerpc/powerpc/src/make.i386/make DIRPRFX=rescue/rescue/ipfs/ clean cd: can't cd to /tinderbox/CURRENT/powerpc/powerpc/src/rescue/rescue/../../sbin/ipfs *** Error code 2 Stop in /tinderbox/CURRENT/powerpc/powerpc/src/rescue/rescue. *** Error code 1 Stop in /tinderbox/CURRENT/powerpc/powerpc/src/rescue. *** Error code 1 Stop in /tinderbox/CURRENT/powerpc/powerpc/src. *** Error code 1 Stop in /tinderbox/CURRENT/powerpc/powerpc/src. *** Error code 1 Stop in /tinderbox/CURRENT/powerpc/powerpc/src. TB --- 2005-04-27 12:59:47 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-04-27 12:59:47 - ERROR: failed to build world TB --- 2005-04-27 12:59:47 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Wed Apr 27 13:04: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 5582116A4CE; Wed, 27 Apr 2005 13:04:38 +0000 (GMT) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id BF96543D3F; Wed, 27 Apr 2005 13:04:37 +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 j3RD4bGB024623; Wed, 27 Apr 2005 09:04:37 -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 j3RD4b3a013116; Wed, 27 Apr 2005 09:04:37 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id D047D7306E; Wed, 27 Apr 2005 09:04:36 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050427130436.D047D7306E@freebsd-current.sentex.ca> Date: Wed, 27 Apr 2005 09:04:36 -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: Wed, 27 Apr 2005 13:04:38 -0000 TB --- 2005-04-27 12:59:47 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-04-27 12:59:47 - starting CURRENT tinderbox run for sparc64/sparc64 TB --- 2005-04-27 12:59:47 - checking out the source tree TB --- 2005-04-27 12:59:47 - cd /home/tinderbox/CURRENT/sparc64/sparc64 TB --- 2005-04-27 12:59:47 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-04-27 13:03:37 - building world (CFLAGS=-O2 -pipe) TB --- 2005-04-27 13:03:37 - cd /home/tinderbox/CURRENT/sparc64/sparc64/src TB --- 2005-04-27 13:03:37 - /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 [...] ===> rescue/rescue/ipf/ipnat (clean) rm -f ipnat_y.c ipnat_y.h ipnat_l.c ipnat_l.h y.tab.c y.tab.h ipnat ipnat.o ipnat_y.o ipnat_l.o ipnat.8.gz ipnat.4.gz ipnat.5.gz ipnat.8.cat.gz ipnat.4.cat.gz ipnat.5.cat.gz ===> rescue/rescue/ipf/ippool (clean) rm -f ippool_y.c ippool_y.h ippool_l.c ippool_l.h y.tab.c y.tab.h ippool ippool_y.o ippool_l.o kmem.o ippool.o ippool.5.gz ippool.8.gz ippool.5.cat.gz ippool.8.cat.gz ===> rescue/rescue/ipf/ipresend (clean) rm -f y.tab.c y.tab.h ipresend ipresend.o ip.o resend.o sbpf.o sock.o 44arp.o ipresend.1.gz ipresend.1.cat.gz cd /tinderbox/CURRENT/sparc64/sparc64/src/rescue/rescue/../../sbin/ipfs && MAKEOBJDIRPREFIX=/home/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/tinderbox/CURRENT/sparc64/sparc64/src/rescue/rescue /home/tinderbox/CURRENT/sparc64/sparc64/obj/tinderbox/CURRENT/sparc64/sparc64/src/make.i386/make DIRPRFX=rescue/rescue/ipfs/ clean cd: can't cd to /tinderbox/CURRENT/sparc64/sparc64/src/rescue/rescue/../../sbin/ipfs *** Error code 2 Stop in /tinderbox/CURRENT/sparc64/sparc64/src/rescue/rescue. *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/src/rescue. *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/src. *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/src. *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/src. TB --- 2005-04-27 13:04:36 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-04-27 13:04:36 - ERROR: failed to build world TB --- 2005-04-27 13:04:36 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Wed Apr 27 13:07: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 4C92F16A4CE for ; Wed, 27 Apr 2005 13:07:27 +0000 (GMT) Received: from mh1.centtech.com (moat3.centtech.com [207.200.51.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5999E43D6D for ; Wed, 27 Apr 2005 13:07:26 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from [10.177.171.220] (neutrino.centtech.com [10.177.171.220]) by mh1.centtech.com (8.13.1/8.13.1) with ESMTP id j3RD7PAt052035 for ; Wed, 27 Apr 2005 08:07:25 -0500 (CDT) (envelope-from anderson@centtech.com) Message-ID: <426F8E58.3020703@centtech.com> Date: Wed, 27 Apr 2005 08:06:32 -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 X-Virus-Scanned: ClamAV 0.82/856/Wed Apr 27 02:00:37 2005 on mh1.centtech.com X-Virus-Status: Clean Subject: libexec/rtld-elf breaks buildworld X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 27 Apr 2005 13:07:27 -0000 Now that I'm bypassing all the ipf annoyances, I see this after cvs-up from 5 mins ago: ... ===> libexec/rtld-elf (all) cc -O2 -pipe -march=pentiumpro -Wall -DFREEBSD_ELF -DIN_RTLD -I/usr/src/libexec/rtld-elf/i386 -I/usr/src/libexec/rtld-elf -el f -fpic -DPIC -Wformat=2 -Wno-format-extra-args -Werror -c /usr/src/libexec/rtld-elf/i386/rtld_start.S cc -O2 -pipe -march=pentiumpro -Wall -DFREEBSD_ELF -DIN_RTLD -I/usr/src/libexec/rtld-elf/i386 -I/usr/src/libexec/rtld-elf -el f -fpic -DPIC -Wformat=2 -Wno-format-extra-args -Werror -c /usr/src/libexec/rtld-elf/i386/reloc.c /usr/src/libexec/rtld-elf/i386/reloc.c: In function `allocate_initial_tls': /usr/src/libexec/rtld-elf/i386/reloc.c:339: warning: implicit declaration of function `alloca_tls' /usr/src/libexec/rtld-elf/i386/reloc.c:339: warning: assignment makes pointer from integer without a cast *** Error code 1 Stop in /usr/src/libexec/rtld-elf. *** Error code 1 Stop in /usr/src/libexec. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. -- ------------------------------------------------------------------------ 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 Wed Apr 27 13:09: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 0100E16A4CE for ; Wed, 27 Apr 2005 13:09:43 +0000 (GMT) Received: from mailserv1.neuroflux.com (ns2.neuroflux.com [204.228.228.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 79B4643D5C for ; Wed, 27 Apr 2005 13:09:42 +0000 (GMT) (envelope-from ryans@gamersimpact.com) Received: (qmail 6782 invoked by uid 1003); 27 Apr 2005 13:10:07 -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 2.182889 secs); 27 Apr 2005 13:10:07 -0000 Received: from unknown (HELO ?192.168.0.5?) (63.231.170.25) by mailserv1.neuroflux.com with SMTP; 27 Apr 2005 13:10:05 -0000 Message-ID: <426F8F21.1010100@gamersimpact.com> Date: Wed, 27 Apr 2005 08:09:53 -0500 From: Ryan Sommers User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: /dev/null References: <57436.216.177.243.42.1114582155.localmail@webmail.dnswatch.com> In-Reply-To: <57436.216.177.243.42.1114582155.localmail@webmail.dnswatch.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-current@freebsd.org Subject: Re: boot banner project X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 27 Apr 2005 13:09:43 -0000 /dev/null wrote: > Hello any & all, > O.K. I feel I must preface this with an acknowledgment that I *know* > this is a silly project *because* given the *incredibly* long uptimes > that FreeBSD is known for. >>But<< for those *few* times when FreeBSDers > see a boot screen, shouldn't it look really nice? Shouldn't also be able > to reflect the Administrators tastes and personality? Well, this is the > premise for my attempting this project. But before I start, I want to > submit an RFC. So consider this an Request for comments. This is an > attempt to create a Graphical boot screen that initially has the > following layout: If you want to pursue this project, more power to you! Personally, I always liked the non graphics/colors boot process. It's especially nice when you are running headless servers and monitor the boot process and console messages via serial links. Something you should take a look at though is the KGI for BSD projects. http://wiki.daemon.li/moin.cgi/KGI -- Ryan Sommers ryans@gamersimpact.com From owner-freebsd-current@FreeBSD.ORG Wed Apr 27 13:14: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 5F4BE16A4CE for ; Wed, 27 Apr 2005 13:14:44 +0000 (GMT) Received: from mortis.over-yonder.net (adsl-12-42-198.jan.bellsouth.net [65.12.42.198]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9146F43D1F for ; Wed, 27 Apr 2005 13:14:43 +0000 (GMT) (envelope-from fullermd@over-yonder.net) Received: by mortis.over-yonder.net (Postfix, from userid 100) id 447A220F1F; Wed, 27 Apr 2005 08:14:42 -0500 (CDT) Date: Wed, 27 Apr 2005 08:14:41 -0500 From: "Matthew D. Fuller" To: Jeff Message-ID: <20050427131441.GB98718@over-yonder.net> References: <20050425183733.GB24146@eeyore.local.dohd.org> <2323.216.177.243.38.1114457612.localmail@webmail.dnswatch.com> <20050425200052.GC24146@eeyore.local.dohd.org> <200504262133.42669.saturn@serv.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200504262133.42669.saturn@serv.net> X-Editor: vi X-OS: FreeBSD User-Agent: Mutt/1.5.9i-fullermd.2 cc: freebsd-current@freebsd.org Subject: Re: fxp0: device timeout X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 27 Apr 2005 13:14:44 -0000 On Tue, Apr 26, 2005 at 09:33:42PM +0000 I heard the voice of Jeff, and lo! it spake thus: > I am experiencing the fxp0: device timeout as well. > > uname -a > FreeBSD 5.4-STABLE FreeBSD 5.4-STABLE #0: Sat Apr 23 19:52:42 UTC 2005 > the kernel is the amd64 and I am running and amd64 processor I've also seen a couple (not many, but this is a low-traffic system anyway) lately, which is unusual. FreeBSD 5.3-STABLE #0: Sat Jan 29 00:29:15 CST 2005 -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. From owner-freebsd-current@FreeBSD.ORG Wed Apr 27 13:52: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 27DD616A4CE for ; Wed, 27 Apr 2005 13:52:11 +0000 (GMT) Received: from mail.sorbs.net (mail.sorbs.net [203.15.51.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id A3F7443D46 for ; Wed, 27 Apr 2005 13:52:10 +0000 (GMT) (envelope-from matthew@uq.edu.au) Received: from [10.200.254.98] by nemesis.sorbs.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0IFL0080NYJOGF@nemesis.sorbs.net> for current@freebsd.org; Wed, 27 Apr 2005 23:52:37 +1000 (EST) Date: Wed, 27 Apr 2005 23:51:00 +1000 From: Matthew Sullivan In-reply-to: <426F8E58.3020703@centtech.com> To: current@freebsd.org Message-id: <426F98C4.6060003@uq.edu.au> MIME-version: 1.0 Content-type: multipart/signed; boundary=------------ms010400080702060504080304; micalg=sha1; protocol="application/x-pkcs7-signature" X-Accept-Language: en User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041231 References: <426F8E58.3020703@centtech.com> Subject: Re: libexec/rtld-elf breaks buildworld X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 27 Apr 2005 13:52:11 -0000 This is a cryptographically signed message in MIME format. --------------ms010400080702060504080304 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Eric Anderson wrote: > ===> libexec/rtld-elf (all) > cc -O2 -pipe -march=pentiumpro -Wall -DFREEBSD_ELF -DIN_RTLD > -I/usr/src/libexec/rtld-elf/i386 -I/usr/src/libexec/rtld-elf -el > f -fpic -DPIC -Wformat=2 -Wno-format-extra-args -Werror -c > /usr/src/libexec/rtld-elf/i386/reloc.c > /usr/src/libexec/rtld-elf/i386/reloc.c: In function > `allocate_initial_tls': > /usr/src/libexec/rtld-elf/i386/reloc.c:339: warning: implicit > declaration of function `alloca_tls' > /usr/src/libexec/rtld-elf/i386/reloc.c:339: warning: assignment makes > pointer from integer without a cast > *** Error code 1 > > Stop in /usr/src/libexec/rtld-elf. > *** Error code 1 Same here (on i386 aswell) Noticed this afternoon local time (10 hours ago) -- Matthew Sullivan Specialist Systems Programmer Information Technology Services The University of Queensland --------------ms010400080702060504080304 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIG7DCC A3IwggJaoAMCAQICASowDQYJKoZIhvcNAQEEBQAwgaMxCzAJBgNVBAYTAkFVMRMwEQYDVQQI EwpRdWVlbnNsYW5kMREwDwYDVQQHEwhCcmlzYmFuZTElMCMGA1UEChMcVGhlIFVuaXZlcnNp dHkgb2YgUXVlZW5zbGFuZDEoMCYGA1UECxMfSW5mb3JtYXRpb24gVGVjaG5vbG9neSBTZXJ2 aWNlczEbMBkGA1UEAxMSQ2VydGlmaWNhdGUgU2VydmVyMB4XDTA0MDEyMTIzMzYyMVoXDTA2 MDEyMTIzMzYyMVowgbIxCzAJBgNVBAYTAkFVMSUwIwYDVQQKExxUaGUgVW5pdmVyc2l0eSBv ZiBRdWVlbnNsYW5kMScwJQYDVQQLEx5JbmZvcm1hdGlvbiBUZWNub2xvZ3kgU2VydmljZXMx FjAUBgoJkiaJk/IsZAEBEwZjY21hdHQxGTAXBgNVBAMTEE1hdHRoZXcgU3VsbGl2YW4xIDAe BgkqhkiG9w0BCQEWEW1hdHRoZXdAdXEuZWR1LmF1MFwwDQYJKoZIhvcNAQEBBQADSwAwSAJB AJsUfrw/QUqKIzDverWc2F4GFFRZmIeO+bAl+7BM6x/9frMzOtygx4QGb4oQwtOE8Sda1aIs v+yJF3Di9EuUyvMCAwEAAaNoMGYwDgYDVR0PAQH/BAQDAgXgMBEGCWCGSAGG+EIBAQQEAwIF oDAfBgNVHSMEGDAWgBQmqtoyueiWTYZBinvsnzeOWLtUuzAgBgNVHREEGTAXgRVtYXR0aGV3 QGl0cy51cS5lZHUuYXUwDQYJKoZIhvcNAQEEBQADggEBAF2gZrkqZsZlHd4K/+yBN6qrpD61 hctDf7/Eg4jk6DMknEs6nvHMFUMZ4SXvkqPLnHBygTARKAs7qBSLd7mUUBOOQEgk6ovQVY6S 1CDSt3P9O6wjG0K1igtk8v6u7lkQ8p2STXqrOePVINdaucUgBO/IpeUtt9ATl1qvPTWyM/fz oUZsIKeYjNQVEQsuimrZjdbIAFxdl1fggSngUv64wBn8wCssGrPZIZA2lpBBEW1wejoWrDOH IIr+SspGd0i8MovDTMRSvgTERLki17FU/ANilcrSXiODKeIvpXhnQqVScnsoMSZmBmN2QIoG SnBjNK5mYxx5E3v20VOwtP1hVdEwggNyMIICWqADAgECAgEqMA0GCSqGSIb3DQEBBAUAMIGj MQswCQYDVQQGEwJBVTETMBEGA1UECBMKUXVlZW5zbGFuZDERMA8GA1UEBxMIQnJpc2JhbmUx JTAjBgNVBAoTHFRoZSBVbml2ZXJzaXR5IG9mIFF1ZWVuc2xhbmQxKDAmBgNVBAsTH0luZm9y bWF0aW9uIFRlY2hub2xvZ3kgU2VydmljZXMxGzAZBgNVBAMTEkNlcnRpZmljYXRlIFNlcnZl cjAeFw0wNDAxMjEyMzM2MjFaFw0wNjAxMjEyMzM2MjFaMIGyMQswCQYDVQQGEwJBVTElMCMG A1UEChMcVGhlIFVuaXZlcnNpdHkgb2YgUXVlZW5zbGFuZDEnMCUGA1UECxMeSW5mb3JtYXRp b24gVGVjbm9sb2d5IFNlcnZpY2VzMRYwFAYKCZImiZPyLGQBARMGY2NtYXR0MRkwFwYDVQQD ExBNYXR0aGV3IFN1bGxpdmFuMSAwHgYJKoZIhvcNAQkBFhFtYXR0aGV3QHVxLmVkdS5hdTBc MA0GCSqGSIb3DQEBAQUAA0sAMEgCQQCbFH68P0FKiiMw73q1nNheBhRUWZiHjvmwJfuwTOsf /X6zMzrcoMeEBm+KEMLThPEnWtWiLL/siRdw4vRLlMrzAgMBAAGjaDBmMA4GA1UdDwEB/wQE AwIF4DARBglghkgBhvhCAQEEBAMCBaAwHwYDVR0jBBgwFoAUJqraMrnolk2GQYp77J83jli7 VLswIAYDVR0RBBkwF4EVbWF0dGhld0BpdHMudXEuZWR1LmF1MA0GCSqGSIb3DQEBBAUAA4IB AQBdoGa5KmbGZR3eCv/sgTeqq6Q+tYXLQ3+/xIOI5OgzJJxLOp7xzBVDGeEl75Kjy5xwcoEw ESgLO6gUi3e5lFATjkBIJOqL0FWOktQg0rdz/TusIxtCtYoLZPL+ru5ZEPKdkk16qznj1SDX WrnFIATvyKXlLbfQE5darz01sjP386FGbCCnmIzUFRELLopq2Y3WyABcXZdX4IEp4FL+uMAZ /MArLBqz2SGQNpaQQRFtcHo6FqwzhyCK/krKRndIvDKLw0zEUr4ExES5ItexVPwDYpXK0l4j gyniL6V4Z0KlUnJ7KDEmZgZjdkCKBkpwYzSuZmMceRN79tFTsLT9YVXRMYIDQDCCAzwCAQEw gakwgaMxCzAJBgNVBAYTAkFVMRMwEQYDVQQIEwpRdWVlbnNsYW5kMREwDwYDVQQHEwhCcmlz YmFuZTElMCMGA1UEChMcVGhlIFVuaXZlcnNpdHkgb2YgUXVlZW5zbGFuZDEoMCYGA1UECxMf SW5mb3JtYXRpb24gVGVjaG5vbG9neSBTZXJ2aWNlczEbMBkGA1UEAxMSQ2VydGlmaWNhdGUg U2VydmVyAgEqMAkGBSsOAwIaBQCgggItMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ KoZIhvcNAQkFMQ8XDTA1MDQyNzEzNTEwMFowIwYJKoZIhvcNAQkEMRYEFJG8zKlXGMbM2KWP UZQ9orR0JUoFMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIG6BgkrBgEEAYI3EAQx gawwgakwgaMxCzAJBgNVBAYTAkFVMRMwEQYDVQQIEwpRdWVlbnNsYW5kMREwDwYDVQQHEwhC cmlzYmFuZTElMCMGA1UEChMcVGhlIFVuaXZlcnNpdHkgb2YgUXVlZW5zbGFuZDEoMCYGA1UE CxMfSW5mb3JtYXRpb24gVGVjaG5vbG9neSBTZXJ2aWNlczEbMBkGA1UEAxMSQ2VydGlmaWNh dGUgU2VydmVyAgEqMIG8BgsqhkiG9w0BCRACCzGBrKCBqTCBozELMAkGA1UEBhMCQVUxEzAR BgNVBAgTClF1ZWVuc2xhbmQxETAPBgNVBAcTCEJyaXNiYW5lMSUwIwYDVQQKExxUaGUgVW5p dmVyc2l0eSBvZiBRdWVlbnNsYW5kMSgwJgYDVQQLEx9JbmZvcm1hdGlvbiBUZWNobm9sb2d5 IFNlcnZpY2VzMRswGQYDVQQDExJDZXJ0aWZpY2F0ZSBTZXJ2ZXICASowDQYJKoZIhvcNAQEB BQAEQJTuo2RWZaq7F1k4fdpo2iQez3SLXmPDi7hSJtul9BtEhPge/LCGE0La5ZUzWWaXqql3 AalQeVwzOdW95qx4z+MAAAAAAAA= --------------ms010400080702060504080304-- From owner-freebsd-current@FreeBSD.ORG Wed Apr 27 14:00: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 B2B7B16A4CE for ; Wed, 27 Apr 2005 14:00:51 +0000 (GMT) Received: from mailout03.sul.t-online.com (mailout03.sul.t-online.com [194.25.134.81]) by mx1.FreeBSD.org (Postfix) with ESMTP id 09FD643D2D for ; Wed, 27 Apr 2005 14:00:51 +0000 (GMT) (envelope-from Alexander@Leidinger.net) Received: from fwd27.aul.t-online.de by mailout03.sul.t-online.com with smtp id 1DQn5t-0006Xj-00; Wed, 27 Apr 2005 16:00:49 +0200 Received: from Andro-Beta.Leidinger.net (XGEKs0ZYZetz4dKpt9NhkHXG22pZ4MiCYK7ixkhzSkyftCGdYSyb4E@[84.128.202.167]) by fwd27.sul.t-online.de with esmtp id 1DQn5i-2EGZge0; Wed, 27 Apr 2005 16:00:38 +0200 Received: from localhost (localhost [127.0.0.1])j3RE0d8J081560; Wed, 27 Apr 2005 16:00:39 +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, 27 Apr 2005 16:00:39 +0200 Message-ID: <20050427160039.udg3gvwzi84840s4@netchild.homeip.net> X-Priority: 3 (Normal) Date: Wed, 27 Apr 2005 16:00:39 +0200 From: Alexander Leidinger To: pfgshield-freebsd@yahoo.com References: <20050425155955.89494.qmail@web51608.mail.yahoo.com> In-Reply-To: <20050425155955.89494.qmail@web51608.mail.yahoo.com> 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: XGEKs0ZYZetz4dKpt9NhkHXG22pZ4MiCYK7ixkhzSkyftCGdYSyb4E@t-dialin.net X-TOI-MSGID: e37d5831-50a5-4ac7-b3f0-04ea72e692d6 cc: freebsd-current@freebsd.org Subject: Re: FreeBSD 6 is coming too fast X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 27 Apr 2005 14:00:51 -0000 pfgshield-freebsd@yahoo.com wrote: > - Bad press towards the 5.x series. If it doesn't mentions 5.3 explicitely, it doesn't apply. > - phk's axe broke one of my favorite ports and I didn't want to spend > another 6 months "fixing" it. You failed to tell which port you are talking about. > - I wanted to use XFree86-4 and building it on my own and figuring out the > library mess later is not an option. We still have the XFree86-4 port, and AFAIK it still works (everything else is a bug). You just have to set a variable in make.conf to make it the default. > - Although outdated, the downloadable java support package was available > for 4.x only. It should work on 5.3-release too. At least there was an effort to get it working, and AFAIK they succeeded. The next time just remember: Everything is possible, you just have to ask if you don't know how to do it yourself. Bye, Alexander. -- http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 We are simple killers of people and destroyers of property. From owner-freebsd-current@FreeBSD.ORG Wed Apr 27 14:21: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 178C116A4CE for ; Wed, 27 Apr 2005 14:21:18 +0000 (GMT) Received: from fast.dnswatch.com (fast.dnswatch.com [216.177.243.43]) by mx1.FreeBSD.org (Postfix) with ESMTP id 451D343D31 for ; Wed, 27 Apr 2005 14:21:17 +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 j3RELCsm065059; Wed, 27 Apr 2005 07:21:17 -0700 (PDT) (envelope-from null@dnswatch.com) Received: (from www@localhost) by fast.dnswatch.com (8.12.6/8.12.6/Submit) id j3RELBZs065058; Wed, 27 Apr 2005 07:21:12 -0700 (PDT) (envelope-from null@dnswatch.com) X-Authentication-Warning: fast.dnswatch.com: www set sender to null@dnswatch.com using -f Received: from demon.dnswatch.com ([216.177.243.42]) (DNSwatch.com_WebMail authenticated user null) by webmail.dnswatch.com with HTTP; Wed, 27 Apr 2005 07:21:11 -0700 (PDT) Message-ID: <50839.216.177.243.42.1114611671.localmail@webmail.dnswatch.com> In-Reply-To: <20050427104300.GA25136@ns2.wananchi.com> References: <63349.216.177.243.42.1114575288.localmail@webmail.dnswatch.com> <20050427060414.GA54657@ns2.wananchi.com> <55065.216.177.243.42.1114583234.localmail@webmail.dnswatch.com> <20050427083649.GC6929@ns2.wananchi.com> <61364.216.177.243.42.1114593685.localmail@webmail.dnswatch.com> <20050427104300.GA25136@ns2.wananchi.com> Date: Wed, 27 Apr 2005 07:21:11 -0700 (PDT) From: "/dev/null" To: freebsd-current@freebsd.org, "Odhiambo Washington" 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: can't build kernel [with CONFIG this time] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 27 Apr 2005 14:21:18 -0000 > * /dev/null [20050427 12:22]: wrote: >> Read on... >> > * /dev/null [20050427 09:27]: wrote: >> >> Odhiambo Washington, >> >> Thank you for your thoughtful reply. According to the documentation >> >> located at: >> >> http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig-building.html >> >> ... >> >> For example: >> >> >> >> # cd /usr/src/sys/i386/conf >> >> # mkdir /root/kernels >> >> # cp GENERIC /root/kernels/MYKERNEL >> >> # ln -s /root/kernels/MYKERNEL >> >> ... >> >> So, in case it is not yet apparent, DEMON01 is located in >> /root/krenels >> >> and the link is located in /usr/src/sys/i386/conf (yes I re-created >> it >> >> after re-installing src). >> >> >> >> Are we on the same page yet. ;) >> > >> > I have been compiling kernels for the last 8 years, so I am not gonna >> > read the documentation again about how to do it, but as sure as day >> > follows night, the "ln -s /root/kernels/MYKERNEL" is a useless step! >> >> O.K. I don't want to be argumentative here, or do I ;) But seriously, I >> just performed surgery on a P2B-AE motherboard. What I have done is >> simply >> provided support for the bus speeds that the boards timer is capable of >> providing, but that ASUS removed for SONY. This is a mobo that ASUS used >> for in-house R&D and later sold to SONY who sent it out as a VAIO. As it >> (the board) was the proto for the ASUS P3B-1394, I am using that BIOS >> image as opposed to the one that SONY provided. Of course this required >> some soldering and other witchcraft. > > > I am not surprised you call yourself /dev/null ;-) Everything seems to > end with you. > > >> ANYWAY, to the point; After all this voodoo I followed the instructions >> as described *verbatum* and it runs like a top. Built as expected, ran >> as expected. Now this one which required *no* voodoo won't build at all! >> SO, >> (not to discount the value of your shared wisdom, and years of >> experience) >> what I intend to do, is: cd /, rm -fr . Then with 5.4-RC3 in the CDROM, >> reboot, newfs, install, reboot and see what happens after a cvsup -g -L >> 2 >> , make buildworld, make buildkernel KERNCONF=CUSTKERN, make >> installkernel KERNCONF=CUSTKERN, reboot, boot -s, >> /etc/rc.d/preseedrandom, >> mergmaster -p, make installworld, mergemaster, reboot, boot kernel. > > That sounds like a good decision, as it is bound to work unless > something weird happened with your witchcraft. > > >> Why you may ask? Because I performed a rm -fr /usr/src, >> downloaded/unpacked >> 5.4-RC3 src. cvsup -g -L2 , make buildworld. And it froze again >> before finishing. After rebooting to single user mode and performing: >> fsck >> -f and rebooting, then running make buildworld, it PANICED, then >> REBOOTED, >> and I SAID !!!ENOUGH!!! > > There is something wrong with that hardware, I think. This would be my suspicion as well. The _only_ difference is the processor. No jumper changes or anything else. Anyway, this may be a faulty processor. A re-install as noted above should tell the tale. Hopefully, it just turns out to be a faulty file or some such thing that the re-install cures. > But I keep install > CDs for 4.10 (4.11 sucks), Thank you for your review of 4.11. Hadn't had an opprotunity to check that out yet. Now I won't need to waste my time. :) > 5.2.1 and 5.3-REL. Whenever one behaves > badly, I try another. Agreed, this is my path as well. > If all fails, install Microshit Windows ;) Not here. FreeBSD _replaces_ Win* here. :) > > >> I hope I have been concise enough that there is no doubt or confusion on >> any of this. :) > > You were. Let me know what comes up! I will, and thanks again for following along here - agony loves company. ;) Best wishes, Chris > > > > > -Wash > > http://www.netmeister.org/news/learn2quote.html > > -- > +======================================================================+ > |\ _,,,---,,_ | Odhiambo Washington > Zzz /,`.-'`' -. ;-;;,_ | Wananchi Online Ltd. www.wananchi.com > |,4- ) )-,_. ,\ ( `'-'| Tel: +254 20 313985-9 +254 20 313922 > '---''(_/--' `-'\_) | GSM: +254 722 743223 +254 733 744121 > +======================================================================+ > " ... I told my doctor I got all the exercise I needed being a > pallbearer for all my friends who run and do exercises!" > -- Winston Churchill > //////////////////////////////////////////////////// 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 Wed Apr 27 14:33: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 AF1E916A4CE for ; Wed, 27 Apr 2005 14:33:23 +0000 (GMT) Received: from fast.dnswatch.com (fast.dnswatch.com [216.177.243.43]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1532443D5F for ; Wed, 27 Apr 2005 14:33:23 +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 j3REXKsm065376; Wed, 27 Apr 2005 07:33:21 -0700 (PDT) (envelope-from null@dnswatch.com) Received: (from www@localhost) by fast.dnswatch.com (8.12.6/8.12.6/Submit) id j3REXJn9065374; Wed, 27 Apr 2005 07:33:19 -0700 (PDT) (envelope-from null@dnswatch.com) X-Authentication-Warning: fast.dnswatch.com: www set sender to null@dnswatch.com using -f Received: from demon.dnswatch.com ([216.177.243.42]) (DNSwatch.com_WebMail authenticated user null) by webmail.dnswatch.com with HTTP; Wed, 27 Apr 2005 07:33:18 -0700 (PDT) Message-ID: <58497.216.177.243.42.1114612399.localmail@webmail.dnswatch.com> In-Reply-To: <426F7FFE.2030903@centtech.com> References: <63349.216.177.243.42.1114575288.localmail@webmail.dnswatch.com> <57d7100005042622465e45ffe0@mail.gmail.com> <426F7FFE.2030903@centtech.com> Date: Wed, 27 Apr 2005 07:33:18 -0700 (PDT) From: "/dev/null" To: "Eric Anderson" , 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: can't build kernel [with CONFIG this time] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 27 Apr 2005 14:33:23 -0000 > pete wright wrote: >> On 4/26/05, /dev/null wrote: >> >>>Hello, >>> Just got a new CPU today. Running 5.4-RC3 on GENERIC until the new CPU >>>showed up. Installed the CPU drafted a new config for the kernel cd'd to >>>/usr/src, typed "make buildkernel KERNCONF=DEMON01", build process went >>> as >>>expected. But before the build process completed the machine froze for >>> no >>>apparent reason at the sound driver part. Couldn't ssh into it from >>> another >>>box, so hit the reset button, chose 4 from the menu (single user mode). >>>Performed a fsck -f. Rebooted and attempted to rebuild. But it barfed. >>>So I performed an rm -fr /usr/src. >>>Then /stand/sysinstall > install entire src tree and tried another >>>"make buildkernel KERNCONF=DEMON01" in /usr/src. >>>It barfed with the following: >> >> >> Have you tried building a GENERIC kernel with this config? Also have >> you cvsup'd your source tree. I know you re-downloaded the source >> from /stand/sysinstall, but you may want to get it via cvsup. >> Especially with the 5.4 RC's. If you are able to build a GENERIC >> kernel, and the problem occurs after a cvsup then I would suspect >> there is something broken in your custom config. > > Maybe rm -rf /usr/obj/ then retrying the build? Good point! _Completely_ forgot. :/ -Chris > I didn't see that you > tried that, although it probably won't do anything different. > > Eric > > > > > -- > ------------------------------------------------------------------------ > Eric Anderson Sr. Systems Administrator Centaur Technology > A lost ounce of gold may be found, a lost moment of time never. > ------------------------------------------------------------------------ > //////////////////////////////////////////////////// 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 Wed Apr 27 14:44: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 30EBD16A4CE for ; Wed, 27 Apr 2005 14:44:26 +0000 (GMT) Received: from fast.dnswatch.com (fast.dnswatch.com [216.177.243.43]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7E53943D3F for ; Wed, 27 Apr 2005 14:44:25 +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 j3REiNsm065549; Wed, 27 Apr 2005 07:44:25 -0700 (PDT) (envelope-from null@dnswatch.com) Received: (from www@localhost) by fast.dnswatch.com (8.12.6/8.12.6/Submit) id j3REiMAW065548; Wed, 27 Apr 2005 07:44:22 -0700 (PDT) (envelope-from null@dnswatch.com) X-Authentication-Warning: fast.dnswatch.com: www set sender to null@dnswatch.com using -f Received: from demon.dnswatch.com ([216.177.243.42]) (DNSwatch.com_WebMail authenticated user null) by webmail.dnswatch.com with HTTP; Wed, 27 Apr 2005 07:44:22 -0700 (PDT) Message-ID: <51866.216.177.243.42.1114613062.localmail@webmail.dnswatch.com> In-Reply-To: <426F8F21.1010100@gamersimpact.com> References: <57436.216.177.243.42.1114582155.localmail@webmail.dnswatch.com> <426F8F21.1010100@gamersimpact.com> Date: Wed, 27 Apr 2005 07:44:22 -0700 (PDT) From: "/dev/null" To: freebsd-current@freebsd.org, "Ryan Sommers" 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: boot banner project X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 27 Apr 2005 14:44:26 -0000 > /dev/null wrote: >> Hello any & all, >> O.K. I feel I must preface this with an acknowledgment that I *know* >> this is a silly project *because* given the *incredibly* long uptimes >> that FreeBSD is known for. >>But<< for those *few* times when FreeBSDers >> see a boot screen, shouldn't it look really nice? Shouldn't also be able >> to reflect the Administrators tastes and personality? Well, this is the >> premise for my attempting this project. But before I start, I want to >> submit an RFC. So consider this an Request for comments. This is an >> attempt to create a Graphical boot screen that initially has the >> following layout: > > If you want to pursue this project, more power to you! Personally, I > always liked the non graphics/colors boot process. It's especially nice > when you are running headless servers and monitor the boot process and > console messages via serial links. With 30+ servers, I do alot of that as well. But it has always bothered me for some reason that Linux has always had their flashy boot screens. While FBSD has not. It was sort of like Linux thumbing it's nose at me. So, I felt like I'd like to start contributing to FBSD and this seemed like an easy place to start. Later, something more advanced (and useful). Thanks for the link! It should prove very useful. Best wishes, Chris > > Something you should take a look at though is the KGI for BSD projects. > > http://wiki.daemon.li/moin.cgi/KGI > > -- > Ryan Sommers > ryans@gamersimpact.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" > //////////////////////////////////////////////////// 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 Wed Apr 27 15:07: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 BD84D16A4CE for ; Wed, 27 Apr 2005 15:07:57 +0000 (GMT) Received: from fast.dnswatch.com (fast.dnswatch.com [216.177.243.43]) by mx1.FreeBSD.org (Postfix) with ESMTP id 22AC743D3F for ; Wed, 27 Apr 2005 15:07:57 +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 j3RF7tsm065752; Wed, 27 Apr 2005 08:07:57 -0700 (PDT) (envelope-from null@dnswatch.com) Received: (from www@localhost) by fast.dnswatch.com (8.12.6/8.12.6/Submit) id j3RF7rFL065751; Wed, 27 Apr 2005 08:07:54 -0700 (PDT) (envelope-from null@dnswatch.com) X-Authentication-Warning: fast.dnswatch.com: www set sender to null@dnswatch.com using -f Received: from demon.dnswatch.com ([216.177.243.42]) (DNSwatch.com_WebMail authenticated user null) by webmail.dnswatch.com with HTTP; Wed, 27 Apr 2005 08:07:52 -0700 (PDT) Message-ID: <61128.216.177.243.42.1114614472.localmail@webmail.dnswatch.com> In-Reply-To: <20050427160039.udg3gvwzi84840s4@netchild.homeip.net> References: <20050425155955.89494.qmail@web51608.mail.yahoo.com> <20050427160039.udg3gvwzi84840s4@netchild.homeip.net> Date: Wed, 27 Apr 2005 08:07:52 -0700 (PDT) From: "/dev/null" To: "Alexander Leidinger" , 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: FreeBSD 6 is coming too fast X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 27 Apr 2005 15:07:57 -0000 > pfgshield-freebsd@yahoo.com wrote: > >> - Bad press towards the 5.x series. > > If it doesn't mentions 5.3 explicitely, it doesn't apply. > >> - phk's axe broke one of my favorite ports and I didn't want to spend >> another 6 months "fixing" it. > > You failed to tell which port you are talking about. > >> - I wanted to use XFree86-4 and building it on my own and figuring out >> the >> library mess later is not an option. > > We still have the XFree86-4 port, and AFAIK it still works (everything > else > is a bug). You just have to set a variable in make.conf to make it the > default. Isn't this and most of the rest of what you mention here always mentioned in: /usr/src/UPDATING and /usr/ports/UPDATING which, in turn, is mentioned in many places in the (online)handbook? > >> - Although outdated, the downloadable java support package was available >> for 4.x only. > > It should work on 5.3-release too. At least there was an effort to get it > working, and AFAIK they succeeded. > > > The next time just remember: Everything is possible, you just have to ask > if > you don't know how to do it yourself. > > Bye, > Alexander. > > -- > http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 > http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 > We are simple killers of people and destroyers of property. > > > _______________________________________________ > 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" > -Chris //////////////////////////////////////////////////// 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 Wed Apr 27 15:10: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 03BDE16A4DA for ; Wed, 27 Apr 2005 15:10:40 +0000 (GMT) Received: from fast.dnswatch.com (fast.dnswatch.com [216.177.243.43]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7D1EC43D55 for ; Wed, 27 Apr 2005 15:10:37 +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 j3RFAbsm065839 for ; Wed, 27 Apr 2005 08:10:37 -0700 (PDT) (envelope-from null@dnswatch.com) Received: (from www@localhost) by fast.dnswatch.com (8.12.6/8.12.6/Submit) id j3RFAZMb065838; Wed, 27 Apr 2005 08:10:35 -0700 (PDT) (envelope-from null@dnswatch.com) X-Authentication-Warning: fast.dnswatch.com: www set sender to null@dnswatch.com using -f Received: from demon.dnswatch.com ([216.177.243.42]) (SquirrelMail authenticated user null); by webmail.dnswatch.com with HTTP; Wed, 27 Apr 2005 08:10:35 -0700 (PDT) X-Received: from demon.dnswatch.com ([216.177.243.42]) (DNSwatch.com_WebMail authenticated user null) by webmail.dnswatch.com with HTTP; Wed, 27 Apr 2005 08:00:54 -0700 (PDT) Message-ID: <53086.216.177.243.42.1114614054.localmail@webmail.dnswatch.com> In-Reply-To: <84dead7205042706554f32484@mail.gmail.com> References: <63349.216.177.243.42.1114575288.localmail@webmail.dnswatch.com> <20050427060414.GA54657@ns2.wananchi.com> <55065.216.177.243.42.1114583234.localmail@webmail.dnswatch.com> <20050427083649.GC6929@ns2.wananchi.com> <61364.216.177.243.42.1114593685.localmail@webmail.dnswatch.com> <84dead7205042706554f32484@mail.gmail.com> Date: Wed, 27 Apr 2005 08:00:54 -0700 (PDT) From: "/dev/null" To: "Joseph Koshy" User-Agent: DNSwatch.com_WebMail/1.4.2 MIME-Version: 1.0 Content-Type: multipart/mixed;boundary="----=_20050427080054_65826" X-Priority: 3 Importance: Normal ReSent-Date: Wed, 27 Apr 2005 08:10:35 -0700 (PDT) Resent-From: "/dev/null" Resent-To: freebsd-current@freebsd.org ReSent-Message-ID: <63514.216.177.243.42.1114614635.squirrel.bounce@216.177.243.42> Subject: Re: can't build kernel [with CONFIG this time] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 27 Apr 2005 15:10:40 -0000 ------=_20050427080054_65826 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit >> Now this one which required *no* voodoo won't build at all! > > Could you post the output of 'boot -v' on the troublesome > system (and please keep -current posted)? Gladly. But for the record, I did this in the first post with this title. This is dmesg -a http://www.dnswatch.com/kern/dmesg ( I'm attaching it as well ) Here's dmesg.today, which is -v http://www.dnswatch.com/kern/dmesg.today ( I'm attaching it as well ) -Chris > > -- > FreeBSD Volunteer, http://people.freebsd.org/~jkoshy > > //////////////////////////////////////////////////// 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. //////////////////////////////////////////////////// ------=_20050427080054_65826 Content-Type: application/octet-stream; name="dmesg" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="dmesg" Q29weXJpZ2h0IChjKSAxOTkyLTIwMDUgVGhlIEZyZWVCU0QgUHJvamVjdC4KQ29weXJpZ2h0IChj KSAxOTc5LCAxOTgwLCAxOTgzLCAxOTg2LCAxOTg4LCAxOTg5LCAxOTkxLCAxOTkyLCAxOTkzLCAx OTk0CglUaGUgUmVnZW50cyBvZiB0aGUgVW5pdmVyc2l0eSBvZiBDYWxpZm9ybmlhLiBBbGwgcmln aHRzIHJlc2VydmVkLgpGcmVlQlNEIDUuNC1SQzIgIzA6IFN1biBBcHIgMTAgMDk6MDg6MTQgVVRD IDIwMDUKICAgIHJvb3RAaGFybG93LmNzZS5idWZmYWxvLmVkdTovdXNyL29iai91c3Ivc3JjL3N5 cy9HRU5FUklDClByZWxvYWRlZCBlbGYga2VybmVsICIvYm9vdC9rZXJuZWwva2VybmVsIiBhdCAw eGMwYTM2MDAwLgpQcmVsb2FkZWQgZWxmIG1vZHVsZSAiL2Jvb3Qva2VybmVsL2FjcGkua28iIGF0 IDB4YzBhMzYxZjQuCkNhbGlicmF0aW5nIGNsb2NrKHMpIC4uLiBpODI1NCBjbG9jazogMTE5MzIy OSBIegpDTEtfVVNFX0k4MjU0X0NBTElCUkFUSU9OIG5vdCBzcGVjaWZpZWQgLSB1c2luZyBkZWZh dWx0IGZyZXF1ZW5jeQpUaW1lY291bnRlciAiaTgyNTQiIGZyZXF1ZW5jeSAxMTkzMTgyIEh6IHF1 YWxpdHkgMApDYWxpYnJhdGluZyBUU0MgY2xvY2sgLi4uIFRTQyBjbG9jazogNjAxMzY3MzA3IEh6 CkNQVTogUGVudGl1bSBJSUkvUGVudGl1bSBJSUkgWGVvbi9DZWxlcm9uICg2MDEuMzctTUh6IDY4 Ni1jbGFzcyBDUFUpCiAgT3JpZ2luID0gIkdlbnVpbmVJbnRlbCIgIElkID0gMHg2NzMgIFN0ZXBw aW5nID0gMwogIEZlYXR1cmVzPTB4Mzg3ZjlmZjxGUFUsVk1FLERFLFBTRSxUU0MsTVNSLFBBRSxN Q0UsQ1g4LFNFUCxNVFJSLFBHRSxNQ0EsQ01PVixQQVQsUFNFMzYsUE4sTU1YLEZYU1IsU1NFPgpy ZWFsIG1lbW9yeSAgPSAxMzMxMDM2MTYgKDEyNiBNQikKUGh5c2ljYWwgbWVtb3J5IGNodW5rKHMp OgoweDAwMDAwMDAwMDAwMDEwMDAgLSAweDAwMDAwMDAwMDAwOWVmZmYsIDY0NzE2OCBieXRlcyAo MTU4IHBhZ2VzKQoweDAwMDAwMDAwMDAxMDAwMDAgLSAweDAwMDAwMDAwMDAzZmZmZmYsIDMxNDU3 MjggYnl0ZXMgKDc2OCBwYWdlcykKMHgwMDAwMDAwMDAwYzI1MDAwIC0gMHgwMDAwMDAwMDA3Yzgz ZmZmLCAxMTc4Mjk2MzIgYnl0ZXMgKDI4NzY3IHBhZ2VzKQphdmFpbCBtZW1vcnkgPSAxMjA1OTg1 MjggKDExNSBNQikKYmlvczMyOiBGb3VuZCBCSU9TMzIgU2VydmljZSBEaXJlY3RvcnkgaGVhZGVy IGF0IDB4YzAwZmFlMjAKYmlvczMyOiBFbnRyeSA9IDB4ZmIyOTAgKGMwMGZiMjkwKSAgUmV2ID0g MCAgTGVuID0gMQpwY2liaW9zOiBQQ0kgQklPUyBlbnRyeSBhdCAweGYwMDAwKzB4YjJjMApwbnBi aW9zOiBGb3VuZCBQblAgQklPUyBkYXRhIGF0IDB4YzAwZmJjNDAKcG5wYmlvczogRW50cnkgPSBm MDAwMDpiYzcwICBSZXYgPSAxLjAKT3RoZXIgQklPUyBzaWduYXR1cmVzIGZvdW5kOgp3bGFuOiA8 ODAyLjExIExpbmsgTGF5ZXI+Cm51bGw6IDxudWxsIGRldmljZSwgemVybyBkZXZpY2U+CnJhbmRv bTogPGVudHJvcHkgc291cmNlLCBTb2Z0d2FyZSwgWWFycm93PgppbzogPEkvTz4KbWVtOiA8bWVt b3J5PgpQZW50aXVtIFBybyBNVFJSIHN1cHBvcnQgZW5hYmxlZApucHgwOiBbRkFTVF0KbnB4MDog PG1hdGggcHJvY2Vzc29yPiBvbiBtb3RoZXJib2FyZApucHgwOiBJTlQgMTYgaW50ZXJmYWNlCmFj cGkwOiA8SkVUV0FZIEFXUkRBQ1BJPiBvbiBtb3RoZXJib2FyZAphY3BpMDogW01QU0FGRV0KcGNp X29wZW4oMSk6CW1vZGUgMSBhZGRyIHBvcnQgKDB4MGNmOCkgaXMgMHg4MDAwMDA1MApwY2lfb3Bl bigxYSk6CW1vZGUxcmVzPTB4ODAwMDAwMDAgKDB4ODAwMDAwMDApCnBjaV9jZmdjaGVjazoJZGV2 aWNlIDAgW2NsYXNzPTA2MDAwMF0gW2hkcj0wMF0gaXMgdGhlcmUgKGlkPTcxMjA4MDg2KQpwY2li aW9zOiBCSU9TIHZlcnNpb24gMi4xMApGb3VuZCAkUElSIHRhYmxlLCA4IGVudHJpZXMgYXQgMHhj MDBmZGVmMApQQ0ktT25seSBJbnRlcnJ1cHRzOiA1IDkgMTAgMTEKTG9jYXRpb24gIEJ1cyBEZXZp Y2UgUGluICBMaW5rICBJUlFzCnNsb3QgMSAgICAgIDAgICAzMCAgICBBICAgMHg2MCAgMyA0IDUg NyA5IDEwIDExIDEyIDE0IDE1CnNsb3QgMSAgICAgIDAgICAzMCAgICBCICAgMHg2MSAgMyA0IDUg NyA5IDEwIDExIDEyIDE0IDE1CnNsb3QgMSAgICAgIDAgICAzMCAgICBDICAgMHg2MiAgMyA0IDUg NyA5IDEwIDExIDEyIDE0IDE1CnNsb3QgMSAgICAgIDAgICAzMCAgICBEICAgMHg2MyAgMyA0IDUg NyA5IDEwIDExIDEyIDE0IDE1CnNsb3QgMiAgICAgIDAgICAxNiAgICBBICAgMHg2MSAgMyA0IDUg NyA5IDEwIDExIDEyIDE0IDE1CnNsb3QgMiAgICAgIDAgICAxNiAgICBCICAgMHg2MiAgMyA0IDUg NyA5IDEwIDExIDEyIDE0IDE1CnNsb3QgMiAgICAgIDAgICAxNiAgICBDICAgMHg2MyAgMyA0IDUg NyA5IDEwIDExIDEyIDE0IDE1CnNsb3QgMiAgICAgIDAgICAxNiAgICBEICAgMHg2MCAgMyA0IDUg NyA5IDEwIDExIDEyIDE0IDE1CnNsb3QgMyAgICAgIDEgICAgOCAgICBBICAgMHg2MCAgMyA0IDUg NyA5IDEwIDExIDEyIDE0IDE1CnNsb3QgMyAgICAgIDEgICAgOCAgICBCICAgMHg2MSAgMyA0IDUg NyA5IDEwIDExIDEyIDE0IDE1CnNsb3QgMyAgICAgIDEgICAgOCAgICBDICAgMHg2MiAgMyA0IDUg NyA5IDEwIDExIDEyIDE0IDE1CnNsb3QgMyAgICAgIDEgICAgOCAgICBEICAgMHg2MyAgMyA0IDUg NyA5IDEwIDExIDEyIDE0IDE1CnNsb3QgNCAgICAgIDEgICAgOSAgICBBICAgMHg2MSAgMyA0IDUg NyA5IDEwIDExIDEyIDE0IDE1CnNsb3QgNCAgICAgIDEgICAgOSAgICBCICAgMHg2MiAgMyA0IDUg NyA5IDEwIDExIDEyIDE0IDE1CnNsb3QgNCAgICAgIDEgICAgOSAgICBDICAgMHg2MyAgMyA0IDUg NyA5IDEwIDExIDEyIDE0IDE1CnNsb3QgNCAgICAgIDEgICAgOSAgICBEICAgMHg2MCAgMyA0IDUg NyA5IDEwIDExIDEyIDE0IDE1CnNsb3QgNSAgICAgIDEgICAxMCAgICBBICAgMHg2MiAgMyA0IDUg NyA5IDEwIDExIDEyIDE0IDE1CnNsb3QgNSAgICAgIDEgICAxMCAgICBCICAgMHg2MyAgMyA0IDUg NyA5IDEwIDExIDEyIDE0IDE1CnNsb3QgNSAgICAgIDEgICAxMCAgICBDICAgMHg2MCAgMyA0IDUg NyA5IDEwIDExIDEyIDE0IDE1CnNsb3QgNSAgICAgIDEgICAxMCAgICBEICAgMHg2MSAgMyA0IDUg NyA5IDEwIDExIDEyIDE0IDE1CnNsb3QgNiAgICAgIDEgICAxMSAgICBBICAgMHg2MyAgMyA0IDUg NyA5IDEwIDExIDEyIDE0IDE1CnNsb3QgNiAgICAgIDEgICAxMSAgICBCICAgMHg2MCAgMyA0IDUg NyA5IDEwIDExIDEyIDE0IDE1CnNsb3QgNiAgICAgIDEgICAxMSAgICBDICAgMHg2MSAgMyA0IDUg NyA5IDEwIDExIDEyIDE0IDE1CnNsb3QgNiAgICAgIDEgICAxMSAgICBEICAgMHg2MiAgMyA0IDUg NyA5IDEwIDExIDEyIDE0IDE1CmVtYmVkZGVkICAgIDAgICAgMSAgICBBICAgMHg2MCAgMyA0IDUg NyA5IDEwIDExIDEyIDE0IDE1CmVtYmVkZGVkICAgIDAgICAgMSAgICBCICAgMHg2MSAgMyA0IDUg NyA5IDEwIDExIDEyIDE0IDE1CmVtYmVkZGVkICAgIDAgICAgMSAgICBDICAgMHg2MiAgMyA0IDUg NyA5IDEwIDExIDEyIDE0IDE1CmVtYmVkZGVkICAgIDAgICAgMSAgICBEICAgMHg2MyAgMyA0IDUg NyA5IDEwIDExIDEyIDE0IDE1CmVtYmVkZGVkICAgIDAgICAzMSAgICBBICAgMHg2MCAgMyA0IDUg NyA5IDEwIDExIDEyIDE0IDE1CmVtYmVkZGVkICAgIDAgICAzMSAgICBCICAgMHg2MSAgMyA0IDUg NyA5IDEwIDExIDEyIDE0IDE1CmVtYmVkZGVkICAgIDAgICAzMSAgICBDICAgMHg2MiAgMyA0IDUg NyA5IDEwIDExIDEyIDE0IDE1CmVtYmVkZGVkICAgIDAgICAzMSAgICBEICAgMHg2MyAgMyA0IDUg NyA5IDEwIDExIDEyIDE0IDE1CmFjcGlfYnVzX251bWJlcjogcm9vdCBidXMgaGFzIG5vIF9CQk4s IGFzc3VtaW5nIDAKQWNwaU9zRGVyaXZlUGNpSWQ6IGJ1cyAwIGRldiAzMSBmdW5jIDAKYWNwaTA6 IFBvd2VyIEJ1dHRvbiAoZml4ZWQpCmFjcGlfYnVzX251bWJlcjogcm9vdCBidXMgaGFzIG5vIF9C Qk4sIGFzc3VtaW5nIDAKQWNwaU9zRGVyaXZlUGNpSWQ6IGJ1cyAwIGRldiAzMSBmdW5jIDAKQUNQ SSB0aW1lcjogMS8xIDEvMCAxLzAgMS8wIDEvMCAxLzAgMS8wIDEvMCAxLzAgMS8wIC0+IDEwClRp bWVjb3VudGVyICJBQ1BJLWZhc3QiIGZyZXF1ZW5jeSAzNTc5NTQ1IEh6IHF1YWxpdHkgMTAwMAph Y3BpX3RpbWVyMDogPDI0LWJpdCB0aW1lciBhdCAzLjU3OTU0NU1Iej4gcG9ydCAweDQwMDgtMHg0 MDBiIG9uIGFjcGkwCmNwdTA6IDxBQ1BJIENQVSAoMyBDeCBzdGF0ZXMpPiBvbiBhY3BpMAphY3Bp X3Rocm90dGxlMDogPEFDUEkgQ1BVIFRocm90dGxpbmc+IG9uIGNwdTAKYWNwaV90aHJvdHRsZTA6 IFBfQ05UIGZyb20gUF9CTEsgMHg0MDEwCmFjcGlfYnV0dG9uMDogPFBvd2VyIEJ1dHRvbj4gb24g YWNwaTAKcGNpYjA6IDxBQ1BJIEhvc3QtUENJIGJyaWRnZT4gcG9ydCAweDQwMDAtMHg0MGY3LDB4 NTAwMC0weDUwMGYsMHhjZjgtMHhjZmYgb24gYWNwaTAKQUNQSSBQQ0kgbGluayBpbml0aWFsIGNv bmZpZ3VyYXRpb246ClxcX1NCXy5QQ0kwLklTQV8uTE5LQSBpcnEgIDA6IFsgMyAgNCAgNSAgNiAg NyAxMCAxMSAxMiAxNCAxNV0gMTArIGxvdyxsZXZlbCxzaGFyYWJsZSAwLjEuMApcXF9TQl8uUENJ MC5JU0FfLkxOS0IgaXJxICAwOiBbIDMgIDQgIDUgIDYgIDcgMTAgMTEgMTIgMTQgMTVdICA1KyBs b3csbGV2ZWwsc2hhcmFibGUgMC4xLjEKXFxfU0JfLlBDSTAuSVNBXy5MTktDIGlycSAgMDogWyAz ICA0ICA1ICA2ICA3IDEwIDExIDEyIDE0IDE1XSAxMSsgbG93LGxldmVsLHNoYXJhYmxlIDAuMS4y ClxcX1NCXy5QQ0kwLklTQV8uTE5LRCBpcnEgIDA6IFsgMyAgNCAgNSAgNiAgNyAxMCAxMSAxMiAx NCAxNV0gIDkrIGxvdyxsZXZlbCxzaGFyYWJsZSAwLjEuMwpcXF9TQl8uUENJMC5JU0FfLkxOS0Eg aXJxICAwOiBbIDMgIDQgIDUgIDYgIDcgMTAgMTEgMTIgMTQgMTVdIDEwKyBsb3csbGV2ZWwsc2hh cmFibGUgMC4zMC4wClxcX1NCXy5QQ0kwLklTQV8uTE5LQiBpcnEgIDA6IFsgMyAgNCAgNSAgNiAg NyAxMCAxMSAxMiAxNCAxNV0gIDUrIGxvdyxsZXZlbCxzaGFyYWJsZSAwLjMwLjEKXFxfU0JfLlBD STAuSVNBXy5MTktDIGlycSAgMDogWyAzICA0ICA1ICA2ICA3IDEwIDExIDEyIDE0IDE1XSAxMSsg bG93LGxldmVsLHNoYXJhYmxlIDAuMzAuMgpcXF9TQl8uUENJMC5JU0FfLkxOS0QgaXJxICAwOiBb IDMgIDQgIDUgIDYgIDcgMTAgMTEgMTIgMTQgMTVdICA5KyBsb3csbGV2ZWwsc2hhcmFibGUgMC4z MC4zClxcX1NCXy5QQ0kwLklTQV8uTE5LQiBpcnEgIDA6IFsgMyAgNCAgNSAgNiAgNyAxMCAxMSAx MiAxNCAxNV0gIDUrIGxvdyxsZXZlbCxzaGFyYWJsZSAwLjE2LjAKXFxfU0JfLlBDSTAuSVNBXy5M TktDIGlycSAgMDogWyAzICA0ICA1ICA2ICA3IDEwIDExIDEyIDE0IDE1XSAxMSsgbG93LGxldmVs LHNoYXJhYmxlIDAuMTYuMQpcXF9TQl8uUENJMC5JU0FfLkxOS0QgaXJxICAwOiBbIDMgIDQgIDUg IDYgIDcgMTAgMTEgMTIgMTQgMTVdICA5KyBsb3csbGV2ZWwsc2hhcmFibGUgMC4xNi4yClxcX1NC Xy5QQ0kwLklTQV8uTE5LQSBpcnEgIDA6IFsgMyAgNCAgNSAgNiAgNyAxMCAxMSAxMiAxNCAxNV0g MTArIGxvdyxsZXZlbCxzaGFyYWJsZSAwLjE2LjMKXFxfU0JfLlBDSTAuSVNBXy5MTktBIGlycSAg MDogWyAzICA0ICA1ICA2ICA3IDEwIDExIDEyIDE0IDE1XSAxMCsgbG93LGxldmVsLHNoYXJhYmxl IDAuMzEuMApcXF9TQl8uUENJMC5JU0FfLkxOS0IgaXJxICAwOiBbIDMgIDQgIDUgIDYgIDcgMTAg MTEgMTIgMTQgMTVdICA1KyBsb3csbGV2ZWwsc2hhcmFibGUgMC4zMS4xClxcX1NCXy5QQ0kwLklT QV8uTE5LQyBpcnEgIDA6IFsgMyAgNCAgNSAgNiAgNyAxMCAxMSAxMiAxNCAxNV0gMTErIGxvdyxs ZXZlbCxzaGFyYWJsZSAwLjMxLjIKXFxfU0JfLlBDSTAuSVNBXy5MTktEIGlycSAgMDogWyAzICA0 ICA1ICA2ICA3IDEwIDExIDEyIDE0IDE1XSAgOSsgbG93LGxldmVsLHNoYXJhYmxlIDAuMzEuMwpw Y2kwOiA8QUNQSSBQQ0kgYnVzPiBvbiBwY2liMApwY2kwOiBwaHlzaWNhbCBidXM9MApmb3VuZC0+ CXZlbmRvcj0weDgwODYsIGRldj0weDcxMjAsIHJldmlkPTB4MDMKCWJ1cz0wLCBzbG90PTAsIGZ1 bmM9MAoJY2xhc3M9MDYtMDAtMDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MAoJY21kcmVnPTB4MDAw Niwgc3RhdHJlZz0weDIwODAsIGNhY2hlbG5zej0wIChkd29yZHMpCglsYXR0aW1lcj0weDAwICgw IG5zKSwgbWluZ250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKCW1hcFsxMF06IHR5 cGUgMywgcmFuZ2UgMzIsIGJhc2UgZDAwMDAwMDAsIHNpemUgMjYsIGVuYWJsZWQKCW1hcFsxNF06 IHR5cGUgMSwgcmFuZ2UgMzIsIGJhc2UgZDQxMDAwMDAsIHNpemUgMTksIGVuYWJsZWQKcGNpYjA6 IG1hdGNoZWQgZW50cnkgZm9yIDAuMS5JTlRBIChzcmMgXFxfU0JfLlBDSTAuSVNBXy5MTktBKQpw Y2liMDogcG9zc2libGUgaW50ZXJydXB0czogIDMgIDQgIDUgIDYgIDcgMTAgMTEgMTIgMTQgMTUK QUNQSSBQQ0kgbGluayBhcmJpdHJhdGVkIHNldHRpbmdzOgpcXF9TQl8uUENJMC5JU0FfLkxOS0Eg KHJlZmVyZW5jZXMgNCwgcHJpb3JpdHkgNTA2NjApOgoJaW50ZXJydXB0czoJICAgIDExICAgIDEw ICAgICA1ICAgIDEyICAgICA3ICAgICA2ICAgICA0ICAgICAzICAgIDE1ICAgIDE0CglwZW5hbHR5 OgkgICAxNjAgICAxNjAgICAyMTAgIDUxNjAgIDUxNjAgIDUxNjAgIDUxNjAgIDUxNjAgNTAxNjAg NTAxNjAKXFxfU0JfLlBDSTAuSVNBXy5MTktCIChyZWZlcmVuY2VzIDQsIHByaW9yaXR5IDUwNjYw KToKCWludGVycnVwdHM6CSAgICAxMSAgICAxMCAgICAgNSAgICAxMiAgICAgNyAgICAgNiAgICAg NCAgICAgMyAgICAxNSAgICAxNAoJcGVuYWx0eToJICAgMTYwICAgMTYwICAgMjEwICA1MTYwICA1 MTYwICA1MTYwICA1MTYwICA1MTYwIDUwMTYwIDUwMTYwClxcX1NCXy5QQ0kwLklTQV8uTE5LQyAo cmVmZXJlbmNlcyA0LCBwcmlvcml0eSA1MDY2MCk6CglpbnRlcnJ1cHRzOgkgICAgMTEgICAgMTAg ICAgIDUgICAgMTIgICAgIDcgICAgIDYgICAgIDQgICAgIDMgICAgMTUgICAgMTQKCXBlbmFsdHk6 CSAgIDE2MCAgIDE2MCAgIDIxMCAgNTE2MCAgNTE2MCAgNTE2MCAgNTE2MCAgNTE2MCA1MDE2MCA1 MDE2MApcXF9TQl8uUENJMC5JU0FfLkxOS0QgKHJlZmVyZW5jZXMgNCwgcHJpb3JpdHkgNTA2NjAp OgoJaW50ZXJydXB0czoJICAgIDExICAgIDEwICAgICA1ICAgIDEyICAgICA3ICAgICA2ICAgICA0 ICAgICAzICAgIDE1ICAgIDE0CglwZW5hbHR5OgkgICAxNjAgICAxNjAgICAyMTAgIDUxNjAgIDUx NjAgIDUxNjAgIDUxNjAgIDUxNjAgNTAxNjAgNTAxNjAKcGNpYjA6IHNsb3QgMSBJTlRBIHJvdXRl ZCB0byBpcnEgMTAgdmlhIFxcX1NCXy5QQ0kwLklTQV8uTE5LQQpmb3VuZC0+CXZlbmRvcj0weDgw ODYsIGRldj0weDcxMjEsIHJldmlkPTB4MDMKCWJ1cz0wLCBzbG90PTEsIGZ1bmM9MAoJY2xhc3M9 MDMtMDAtMDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MAoJY21kcmVnPTB4MDAwNywgc3RhdHJlZz0w eDAyYjAsIGNhY2hlbG5zej0wIChkd29yZHMpCglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250 PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKCWludHBpbj1hLCBpcnE9MTAKCXBvd2Vy c3BlYyAxICBzdXBwb3J0cyBEMCBEMyAgY3VycmVudCBEMApmb3VuZC0+CXZlbmRvcj0weDgwODYs IGRldj0weDI0MTgsIHJldmlkPTB4MDIKCWJ1cz0wLCBzbG90PTMwLCBmdW5jPTAKCWNsYXNzPTA2 LTA0LTAwLCBoZHJ0eXBlPTB4MDEsIG1mZGV2PTAKCWNtZHJlZz0weDAxMDcsIHN0YXRyZWc9MHgw MDgwLCBjYWNoZWxuc3o9MCAoZHdvcmRzKQoJbGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0w eDA2ICgxNTAwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCmZvdW5kLT4JdmVuZG9yPTB4ODA4Niwg ZGV2PTB4MjQxMCwgcmV2aWQ9MHgwMgoJYnVzPTAsIHNsb3Q9MzEsIGZ1bmM9MAoJY2xhc3M9MDYt MDEtMDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MQoJY21kcmVnPTB4MDAwZiwgc3RhdHJlZz0weDAy ODAsIGNhY2hlbG5zej0wIChkd29yZHMpCglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4 MDAgKDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKCW1hcFsyMF06IHR5cGUgNCwgcmFuZ2UgMzIs IGJhc2UgMDAwMGYwMDAsIHNpemUgIDQsIGVuYWJsZWQKZm91bmQtPgl2ZW5kb3I9MHg4MDg2LCBk ZXY9MHgyNDExLCByZXZpZD0weDAyCglidXM9MCwgc2xvdD0zMSwgZnVuYz0xCgljbGFzcz0wMS0w MS04MCwgaGRydHlwZT0weDAwLCBtZmRldj0wCgljbWRyZWc9MHgwMDA1LCBzdGF0cmVnPTB4MDI4 MCwgY2FjaGVsbnN6PTAgKGR3b3JkcykKCWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9MHgw MCAoMCBucyksIG1heGxhdD0weDAwICgwIG5zKQoJbWFwWzIwXTogdHlwZSA0LCByYW5nZSAzMiwg YmFzZSAwMDAwZDAwMCwgc2l6ZSAgNSwgZW5hYmxlZApwY2liMDogbWF0Y2hlZCBlbnRyeSBmb3Ig MC4zMS5JTlREIChzcmMgXFxfU0JfLlBDSTAuSVNBXy5MTktEKQpwY2liMDogcG9zc2libGUgaW50 ZXJydXB0czogIDMgIDQgIDUgIDYgIDcgMTAgMTEgMTIgMTQgMTUKQUNQSSBQQ0kgbGluayBhcmJp dHJhdGVkIHNldHRpbmdzOgpcXF9TQl8uUENJMC5JU0FfLkxOS0IgKHJlZmVyZW5jZXMgNCwgcHJp b3JpdHkgNTEzMTYpOgoJaW50ZXJydXB0czoJICAgIDExICAgIDEwICAgICA1ICAgIDEyICAgICA3 ICAgICA2ICAgICA0ICAgICAzICAgIDE1ICAgIDE0CglwZW5hbHR5OgkgICAzMjAgICAzNjAgICAz NzAgIDUzMjAgIDUzMjAgIDUzMjAgIDUzMjAgIDUzMjAgNTAzMjAgNTAzMjAKXFxfU0JfLlBDSTAu SVNBXy5MTktDIChyZWZlcmVuY2VzIDQsIHByaW9yaXR5IDUxMzE2KToKCWludGVycnVwdHM6CSAg ICAxMSAgICAxMCAgICAgNSAgICAxMiAgICAgNyAgICAgNiAgICAgNCAgICAgMyAgICAxNSAgICAx NAoJcGVuYWx0eToJICAgMzIwICAgMzYwICAgMzcwICA1MzIwICA1MzIwICA1MzIwICA1MzIwICA1 MzIwIDUwMzIwIDUwMzIwClxcX1NCXy5QQ0kwLklTQV8uTE5LRCAocmVmZXJlbmNlcyA0LCBwcmlv cml0eSA1MTMxNik6CglpbnRlcnJ1cHRzOgkgICAgMTEgICAgMTAgICAgIDUgICAgMTIgICAgIDcg ICAgIDYgICAgIDQgICAgIDMgICAgMTUgICAgMTQKCXBlbmFsdHk6CSAgIDMyMCAgIDM2MCAgIDM3 MCAgNTMyMCAgNTMyMCAgNTMyMCAgNTMyMCAgNTMyMCA1MDMyMCA1MDMyMApwY2liMDogc2xvdCAz MSBJTlREIHJvdXRlZCB0byBpcnEgOSB2aWEgXFxfU0JfLlBDSTAuSVNBXy5MTktECmZvdW5kLT4J dmVuZG9yPTB4ODA4NiwgZGV2PTB4MjQxMiwgcmV2aWQ9MHgwMgoJYnVzPTAsIHNsb3Q9MzEsIGZ1 bmM9MgoJY2xhc3M9MGMtMDMtMDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MAoJY21kcmVnPTB4MDAw NSwgc3RhdHJlZz0weDAyODAsIGNhY2hlbG5zej0wIChkd29yZHMpCglsYXR0aW1lcj0weDAwICgw IG5zKSwgbWluZ250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKCWludHBpbj1kLCBp cnE9OQphZ3AwOiA8SW50ZWwgODI4MTAgKGk4MTAgR01DSCkgU1ZHQSBjb250cm9sbGVyPiBtZW0g MHhkNDEwMDAwMC0weGQ0MTdmZmZmLDB4ZDAwMDAwMDAtMHhkM2ZmZmZmZiBpcnEgMTAgYXQgZGV2 aWNlIDEuMCBvbiBwY2kwCmFncDA6IFJlc2VydmVkIDB4NDAwMDAwMCBieXRlcyBmb3IgcmlkIDB4 MTAgdHlwZSAzIGF0IDB4ZDAwMDAwMDAKYWdwMDogUmVzZXJ2ZWQgMHg4MDAwMCBieXRlcyBmb3Ig cmlkIDB4MTQgdHlwZSAzIGF0IDB4ZDQxMDAwMDAKcGNpYjE6IDxBQ1BJIFBDSS1QQ0kgYnJpZGdl PiBhdCBkZXZpY2UgMzAuMCBvbiBwY2kwCnBjaWIxOiAgIHNlY29uZGFyeSBidXMgICAgIDEKcGNp YjE6ICAgc3Vib3JkaW5hdGUgYnVzICAgMQpwY2liMTogICBJL08gZGVjb2RlICAgICAgICAweGMw MDAtMHhjZmZmCnBjaWIxOiAgIG1lbW9yeSBkZWNvZGUgICAgIDB4ZDQwMDAwMDAtMHhkNDBmZmZm ZgpwY2liMTogICBwcmVmZXRjaGVkIGRlY29kZSAweGZmZjAwMDAwLTB4ZmZmZmYKcGNpYjE6ICAg U3VidHJhY3RpdmVseSBkZWNvZGVkIGJyaWRnZS4KQUNQSSBQQ0kgbGluayBpbml0aWFsIGNvbmZp Z3VyYXRpb246ClxcX1NCXy5QQ0kwLklTQV8uTE5LQSBpcnEqMTA6IFsgMyAgNCAgNSAgNiAgNyAx MCAxMSAxMiAxNCAxNV0gMTArIGxvdyxsZXZlbCxzaGFyYWJsZSAxLjguMApcXF9TQl8uUENJMC5J U0FfLkxOS0IgaXJxICAwOiBbIDMgIDQgIDUgIDYgIDcgMTAgMTEgMTIgMTQgMTVdICA1KyBsb3cs bGV2ZWwsc2hhcmFibGUgMS44LjEKXFxfU0JfLlBDSTAuSVNBXy5MTktDIGlycSAgMDogWyAzICA0 ICA1ICA2ICA3IDEwIDExIDEyIDE0IDE1XSAxMSsgbG93LGxldmVsLHNoYXJhYmxlIDEuOC4yClxc X1NCXy5QQ0kwLklTQV8uTE5LRCBpcnEqIDk6IFsgMyAgNCAgNSAgNiAgNyAxMCAxMSAxMiAxNCAx NV0gIDkrIGxvdyxsZXZlbCxzaGFyYWJsZSAxLjguMwpcXF9TQl8uUENJMC5JU0FfLkxOS0IgaXJx ICAwOiBbIDMgIDQgIDUgIDYgIDcgMTAgMTEgMTIgMTQgMTVdICA1KyBsb3csbGV2ZWwsc2hhcmFi bGUgMS45LjAKXFxfU0JfLlBDSTAuSVNBXy5MTktDIGlycSAgMDogWyAzICA0ICA1ICA2ICA3IDEw IDExIDEyIDE0IDE1XSAxMSsgbG93LGxldmVsLHNoYXJhYmxlIDEuOS4xClxcX1NCXy5QQ0kwLklT QV8uTE5LRCBpcnEqIDk6IFsgMyAgNCAgNSAgNiAgNyAxMCAxMSAxMiAxNCAxNV0gIDkrIGxvdyxs ZXZlbCxzaGFyYWJsZSAxLjkuMgpcXF9TQl8uUENJMC5JU0FfLkxOS0EgaXJxKjEwOiBbIDMgIDQg IDUgIDYgIDcgMTAgMTEgMTIgMTQgMTVdIDEwKyBsb3csbGV2ZWwsc2hhcmFibGUgMS45LjMKXFxf U0JfLlBDSTAuSVNBXy5MTktDIGlycSAgMDogWyAzICA0ICA1ICA2ICA3IDEwIDExIDEyIDE0IDE1 XSAxMSsgbG93LGxldmVsLHNoYXJhYmxlIDEuMTAuMApcXF9TQl8uUENJMC5JU0FfLkxOS0QgaXJx KiA5OiBbIDMgIDQgIDUgIDYgIDcgMTAgMTEgMTIgMTQgMTVdICA5KyBsb3csbGV2ZWwsc2hhcmFi bGUgMS4xMC4xClxcX1NCXy5QQ0kwLklTQV8uTE5LQSBpcnEqMTA6IFsgMyAgNCAgNSAgNiAgNyAx MCAxMSAxMiAxNCAxNV0gMTArIGxvdyxsZXZlbCxzaGFyYWJsZSAxLjEwLjIKXFxfU0JfLlBDSTAu SVNBXy5MTktCIGlycSAgMDogWyAzICA0ICA1ICA2ICA3IDEwIDExIDEyIDE0IDE1XSAgNSsgbG93 LGxldmVsLHNoYXJhYmxlIDEuMTAuMwpcXF9TQl8uUENJMC5JU0FfLkxOS0QgaXJxKiA5OiBbIDMg IDQgIDUgIDYgIDcgMTAgMTEgMTIgMTQgMTVdICA5KyBsb3csbGV2ZWwsc2hhcmFibGUgMS4xMS4w ClxcX1NCXy5QQ0kwLklTQV8uTE5LQSBpcnEqMTA6IFsgMyAgNCAgNSAgNiAgNyAxMCAxMSAxMiAx NCAxNV0gMTArIGxvdyxsZXZlbCxzaGFyYWJsZSAxLjExLjEKXFxfU0JfLlBDSTAuSVNBXy5MTktC IGlycSAgMDogWyAzICA0ICA1ICA2ICA3IDEwIDExIDEyIDE0IDE1XSAgNSsgbG93LGxldmVsLHNo YXJhYmxlIDEuMTEuMgpcXF9TQl8uUENJMC5JU0FfLkxOS0MgaXJxICAwOiBbIDMgIDQgIDUgIDYg IDcgMTAgMTEgMTIgMTQgMTVdIDExKyBsb3csbGV2ZWwsc2hhcmFibGUgMS4xMS4zCnBjaTE6IDxB Q1BJIFBDSSBidXM+IG9uIHBjaWIxCnBjaTE6IHBoeXNpY2FsIGJ1cz0xCgltYXBbMTBdOiB0eXBl IDQsIHJhbmdlIDMyLCBiYXNlIDAwMDBjMDAwLCBzaXplICA3LCBlbmFibGVkCnBjaWIxOiBkZXZp Y2UgKG51bGwpIHJlcXVlc3RlZCBkZWNvZGVkIEkvTyByYW5nZSAweGMwMDAtMHhjMDdmCgltYXBb MTRdOiB0eXBlIDEsIHJhbmdlIDMyLCBiYXNlIGQ0MDAwMDAwLCBzaXplICA3LCBlbmFibGVkCnBj aWIxOiBkZXZpY2UgKG51bGwpIHJlcXVlc3RlZCBkZWNvZGVkIG1lbW9yeSByYW5nZSAweGQ0MDAw MDAwLTB4ZDQwMDAwN2YKcGNpYjE6IG1hdGNoZWQgZW50cnkgZm9yIDEuMTAuSU5UQSAoc3JjIFxc X1NCXy5QQ0kwLklTQV8uTE5LQykKcGNpYjE6IHBvc3NpYmxlIGludGVycnVwdHM6ICAzICA0ICA1 ICA2ICA3IDEwIDExIDEyIDE0IDE1CkFDUEkgUENJIGxpbmsgYXJiaXRyYXRlZCBzZXR0aW5nczoK XFxfU0JfLlBDSTAuSVNBXy5MTktCIChyZWZlcmVuY2VzIDgsIHByaW9yaXR5IDEwNTE5Mik6Cglp bnRlcnJ1cHRzOgkgICAgMTEgICAgMTAgICAgIDUgICAgMTIgICAgIDcgICAgIDYgICAgIDQgICAg IDMgICAgMTUgICAgMTQKCXBlbmFsdHk6CSAgIDY0MCAgIDY4MCAgIDY5MCAgNTY0MCAgNTY0MCAg NTY0MCAgNTY0MCAgNTY0MCA1MDY0MCA1MDY0MApcXF9TQl8uUENJMC5JU0FfLkxOS0MgKHJlZmVy ZW5jZXMgOCwgcHJpb3JpdHkgMTA1MTkyKToKCWludGVycnVwdHM6CSAgICAxMSAgICAxMCAgICAg NSAgICAxMiAgICAgNyAgICAgNiAgICAgNCAgICAgMyAgICAxNSAgICAxNAoJcGVuYWx0eToJICAg NjQwICAgNjgwICAgNjkwICA1NjQwICA1NjQwICA1NjQwICA1NjQwICA1NjQwIDUwNjQwIDUwNjQw CnBjaWIxOiBzbG90IDEwIElOVEEgcm91dGVkIHRvIGlycSAxMSB2aWEgXFxfU0JfLlBDSTAuSVNB Xy5MTktDCmZvdW5kLT4JdmVuZG9yPTB4MTAxMSwgZGV2PTB4MDAwOSwgcmV2aWQ9MHgxMgoJYnVz PTEsIHNsb3Q9MTAsIGZ1bmM9MAoJY2xhc3M9MDItMDAtMDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9 MAoJY21kcmVnPTB4MDAwNywgc3RhdHJlZz0weDAyODAsIGNhY2hlbG5zej0wIChkd29yZHMpCgls YXR0aW1lcj0weDIwICg5NjAgbnMpLCBtaW5nbnQ9MHgwMCAoMCBucyksIG1heGxhdD0weDAwICgw IG5zKQoJaW50cGluPWEsIGlycT0xMQpkZTA6IDxEaWdpdGFsIDIxMTQwIEZhc3QgRXRoZXJuZXQ+ IHBvcnQgMHhjMDAwLTB4YzA3ZiBtZW0gMHhkNDAwMDAwMC0weGQ0MDAwMDdmIGlycSAxMSBhdCBk ZXZpY2UgMTAuMCBvbiBwY2kxCmRlMDogUmVzZXJ2ZWQgMHg4MCBieXRlcyBmb3IgcmlkIDB4MTAg dHlwZSA0IGF0IDB4YzAwMApkZTA6IFtHSUFOVC1MT0NLRURdCmRlMDogU01DIDkzMzJEU1QgMjEx NDAgWzEwLTEwME1iL3NdIHBhc3MgMS4yCmRlMDogZW5hYmxpbmcgMTBiYXNlVCBwb3J0CmRlMDog YnBmIGF0dGFjaGVkCmRlMDogRXRoZXJuZXQgYWRkcmVzczogMDA6MDA6YzA6MzY6YmQ6ZWUKZGUw OiBpZl9zdGFydCBydW5uaW5nIGRlZmVycmVkIGZvciBHaWFudAppc2FiMDogPFBDSS1JU0EgYnJp ZGdlPiBhdCBkZXZpY2UgMzEuMCBvbiBwY2kwCmlzYTA6IDxJU0EgYnVzPiBvbiBpc2FiMAphdGFw Y2kwOiA8SW50ZWwgSUNIIFVETUE2NiBjb250cm9sbGVyPiBwb3J0IDB4ZjAwMC0weGYwMGYsMHgz NzYsMHgxNzAtMHgxNzcsMHgzZjYsMHgxZjAtMHgxZjcgYXQgZGV2aWNlIDMxLjEgb24gcGNpMAph dGFwY2kwOiBSZXNlcnZlZCAweDEwIGJ5dGVzIGZvciByaWQgMHgyMCB0eXBlIDQgYXQgMHhmMDAw CmF0YTA6IGNoYW5uZWwgIzAgb24gYXRhcGNpMAphdGFwY2kwOiBSZXNlcnZlZCAweDggYnl0ZXMg Zm9yIHJpZCAweDEwIHR5cGUgNCBhdCAweDFmMAphdGFwY2kwOiBSZXNlcnZlZCAweDEgYnl0ZXMg Zm9yIHJpZCAweDE0IHR5cGUgNCBhdCAweDNmNgphdGEwOiByZXNldCB0cDEgbWFzaz0wMyBvc3Rh dDA9NTAgb3N0YXQxPTAwCmF0YTAtbWFzdGVyOiBzdGF0PTB4NTAgZXJyPTB4MDEgbHNiPTB4MDAg bXNiPTB4MDAKYXRhMC1zbGF2ZTogIHN0YXQ9MHgwMCBlcnI9MHgwMSBsc2I9MHgwMCBtc2I9MHgw MAphdGEwOiByZXNldCB0cDIgc3RhdDA9NTAgc3RhdDE9MDAgZGV2aWNlcz0weDE8QVRBX01BU1RF Uj4KYXRhMDogW01QU0FGRV0KYXRhMTogY2hhbm5lbCAjMSBvbiBhdGFwY2kwCmF0YXBjaTA6IFJl c2VydmVkIDB4OCBieXRlcyBmb3IgcmlkIDB4MTggdHlwZSA0IGF0IDB4MTcwCmF0YXBjaTA6IFJl c2VydmVkIDB4MSBieXRlcyBmb3IgcmlkIDB4MWMgdHlwZSA0IGF0IDB4Mzc2CmF0YTE6IHJlc2V0 IHRwMSBtYXNrPTAzIG9zdGF0MD01MCBvc3RhdDE9MDAKYXRhMS1tYXN0ZXI6IHN0YXQ9MHgwMCBl cnI9MHgwMSBsc2I9MHgxNCBtc2I9MHhlYgphdGExLXNsYXZlOiAgc3RhdD0weDAxIGVycj0weDAx IGxzYj0weDAxIG1zYj0weDAxCmF0YTE6IHJlc2V0IHRwMiBzdGF0MD0wMCBzdGF0MT0wMSBkZXZp Y2VzPTB4NDxBVEFQSV9NQVNURVI+CmF0YTE6IFtNUFNBRkVdCnVoY2kwOiA8SW50ZWwgODI4MDFB QSAoSUNIKSBVU0IgY29udHJvbGxlcj4gcG9ydCAweGQwMDAtMHhkMDFmIGlycSA5IGF0IGRldmlj ZSAzMS4yIG9uIHBjaTAKdWhjaTA6IFJlc2VydmVkIDB4MjAgYnl0ZXMgZm9yIHJpZCAweDIwIHR5 cGUgNCBhdCAweGQwMDAKdWhjaTA6IFtHSUFOVC1MT0NLRURdCnVzYjA6IDxJbnRlbCA4MjgwMUFB IChJQ0gpIFVTQiBjb250cm9sbGVyPiBvbiB1aGNpMAp1c2IwOiBVU0IgcmV2aXNpb24gMS4wCnVo dWIwOiBJbnRlbCBVSENJIHJvb3QgaHViLCBjbGFzcyA5LzAsIHJldiAxLjAwLzEuMDAsIGFkZHIg MQp1aHViMDogMiBwb3J0cyB3aXRoIDIgcmVtb3ZhYmxlLCBzZWxmIHBvd2VyZWQKYWNwaV90ejA6 IDxUaGVybWFsIFpvbmU+IG9uIGFjcGkwCmZkYzA6IDxmbG9wcHkgZHJpdmUgY29udHJvbGxlcj4g cG9ydCAweDNmNywweDNmMi0weDNmNSBpcnEgNiBkcnEgMiBvbiBhY3BpMApmZGMwOiBpY190eXBl IDkwIHBhcnRfaWQgODAKZmRjMDogW01QU0FGRV0KZmRjMDogW0ZBU1RdCmZkMDogPDE0NDAtS0Ig My41IiBkcml2ZT4gb24gZmRjMCBkcml2ZSAwCnNpbzA6IGlycSBtYXBzOiAweDIxIDB4MzEgMHgy MSAweDIxCnNpbzA6IDwxNjU1MEEtY29tcGF0aWJsZSBDT00gcG9ydD4gcG9ydCAweDNmOC0weDNm ZiBpcnEgNCBmbGFncyAweDEwIG9uIGFjcGkwCnNpbzA6IHR5cGUgMTY1NTBBCnNpbzE6IGlycSBt YXBzOiAweDIxIDB4MjkgMHgyMSAweDIxCnNpbzE6IDwxNjU1MEEtY29tcGF0aWJsZSBDT00gcG9y dD4gcG9ydCAweDJmOC0weDJmZiBpcnEgMyBvbiBhY3BpMApzaW8xOiB0eXBlIDE2NTUwQQp1bmtu b3duOiBub3QgcHJvYmVkIChkaXNhYmxlZCkKdW5rbm93bjogbm90IHByb2JlZCAoZGlzYWJsZWQp CnBwYzA6IHVzaW5nIGV4dGVuZGVkIEkvTyBwb3J0IHJhbmdlCnBwYzA6IEVDUCBTUFAgRUNQK0VQ UCBTUFAKcHBjMDogPEVDUCBwYXJhbGxlbCBwcmludGVyIHBvcnQ+IHBvcnQgMHg3NzgtMHg3N2Is MHgzNzgtMHgzN2YgaXJxIDcgZHJxIDMgb24gYWNwaTAKcHBjMDogU01DLWxpa2UgY2hpcHNldCAo RUNQL0VQUC9QUzIvTklCQkxFKSBpbiBDT01QQVRJQkxFIG1vZGUKcHBjMDogRklGTyB3aXRoIDE2 LzE2LzE2IGJ5dGVzIHRocmVzaG9sZApwcGJ1czA6IDxQYXJhbGxlbCBwb3J0IGJ1cz4gb24gcHBj MApwbGlwMDogPFBMSVAgbmV0d29yayBpbnRlcmZhY2U+IG9uIHBwYnVzMApwbGlwMDogYnBmIGF0 dGFjaGVkCmxwdDA6IDxQcmludGVyPiBvbiBwcGJ1czAKbHB0MDogSW50ZXJydXB0LWRyaXZlbiBw b3J0CnBwaTA6IDxQYXJhbGxlbCBJL08+IG9uIHBwYnVzMApwc21jcG5wMDogPFBTLzIgbW91c2Ug cG9ydD4gaXJxIDEyIG9uIGFjcGkwCmF0a2JkYzA6IDxLZXlib2FyZCBjb250cm9sbGVyIChpODA0 Mik+IHBvcnQgMHg2NCwweDYwIGlycSAxIG9uIGFjcGkwCmF0a2JkMDogPEFUIEtleWJvYXJkPiBp cnEgMSBvbiBhdGtiZGMwCmF0a2JkOiB0aGUgY3VycmVudCBrYmQgY29udHJvbGxlciBjb21tYW5k IGJ5dGUgMDA0NwphdGtiZDoga2V5Ym9hcmQgSUQgMHg0MWFiICgyKQprYmQwIGF0IGF0a2JkMApr YmQwOiBhdGtiZDAsIEFUIDEwMS8xMDIgKDIpLCBjb25maWc6MHgwLCBmbGFnczoweDNkMDAwMAph dGtiZDA6IFtHSUFOVC1MT0NLRURdCnBzbTA6IGN1cnJlbnQgY29tbWFuZCBieXRlOjAwNDcKcHNt MDogPFBTLzIgTW91c2U+IGlycSAxMiBvbiBhdGtiZGMwCnBzbTA6IFtHSUFOVC1MT0NLRURdCnBz bTA6IG1vZGVsIEludGVsbGlNb3VzZSwgZGV2aWNlIElEIDMtMDAsIDMgYnV0dG9ucwpwc20wOiBj b25maWc6MDAwMDAwMDAsIGZsYWdzOjAwMDAwMDA4LCBwYWNrZXQgc2l6ZTo0CnBzbTA6IHN5bmNt YXNrOjA4LCBzeW5jYml0czowMAp1bmtub3duOiBub3QgcHJvYmVkIChkaXNhYmxlZCkKdW5rbm93 bjogbm90IHByb2JlZCAoZGlzYWJsZWQpCnVua25vd246IG5vdCBwcm9iZWQgKGRpc2FibGVkKQp1 bmtub3duOiBub3QgcHJvYmVkIChkaXNhYmxlZCkKdW5rbm93bjogbm90IHByb2JlZCAoZGlzYWJs ZWQpCnVua25vd246IG5vdCBwcm9iZWQgKGRpc2FibGVkKQphdGE6IGF0YTAgYWxyZWFkeSBleGlz dHM7IHNraXBwaW5nIGl0CmF0YTogYXRhMSBhbHJlYWR5IGV4aXN0czsgc2tpcHBpbmcgaXQKYXRr YmRjOiBhdGtiZGMwIGFscmVhZHkgZXhpc3RzOyBza2lwcGluZyBpdApmZGM6IGZkYzAgYWxyZWFk eSBleGlzdHM7IHNraXBwaW5nIGl0CnBwYzogcHBjMCBhbHJlYWR5IGV4aXN0czsgc2tpcHBpbmcg aXQKc2lvOiBzaW8wIGFscmVhZHkgZXhpc3RzOyBza2lwcGluZyBpdApzaW86IHNpbzEgYWxyZWFk eSBleGlzdHM7IHNraXBwaW5nIGl0ClRyeWluZyBSZWFkX1BvcnQgYXQgMjAzClRyeWluZyBSZWFk X1BvcnQgYXQgMjQzClRyeWluZyBSZWFkX1BvcnQgYXQgMjgzClRyeWluZyBSZWFkX1BvcnQgYXQg MmMzClRyeWluZyBSZWFkX1BvcnQgYXQgMzAzClRyeWluZyBSZWFkX1BvcnQgYXQgMzQzClRyeWlu ZyBSZWFkX1BvcnQgYXQgMzgzClRyeWluZyBSZWFkX1BvcnQgYXQgM2MzCmV4X2lzYV9pZGVudGlm eSgpCnVua25vd246IHN0YXR1cyByZWcgdGVzdCBmYWlsZWQgZmYKdW5rbm93bjogc3RhdHVzIHJl ZyB0ZXN0IGZhaWxlZCBmZgp1bmtub3duOiBzdGF0dXMgcmVnIHRlc3QgZmFpbGVkIGZmCnVua25v d246IHN0YXR1cyByZWcgdGVzdCBmYWlsZWQgZmYKdW5rbm93bjogc3RhdHVzIHJlZyB0ZXN0IGZh aWxlZCBmZgp1bmtub3duOiBzdGF0dXMgcmVnIHRlc3QgZmFpbGVkIGZmCnNjOiBzYzAgYWxyZWFk eSBleGlzdHM7IHNraXBwaW5nIGl0CnZnYTogdmdhMCBhbHJlYWR5IGV4aXN0czsgc2tpcHBpbmcg aXQKaXNhX3Byb2JlX2NoaWxkcmVuOiBkaXNhYmxpbmcgUG5QIGRldmljZXMKaXNhX3Byb2JlX2No aWxkcmVuOiBwcm9iaW5nIG5vbi1QblAgZGV2aWNlcwpvcm0wOiA8SVNBIE9wdGlvbiBST00+IGF0 IGlvbWVtIDB4YzAwMDAtMHhjOWZmZiBvbiBpc2EwCnBtdGltZXIwIG9uIGlzYTAKYWR2MDogbm90 IHByb2JlZCAoZGlzYWJsZWQpCmFoYTA6IG5vdCBwcm9iZWQgKGRpc2FibGVkKQphaWMwOiBub3Qg cHJvYmVkIChkaXNhYmxlZCkKYnQwOiBub3QgcHJvYmVkIChkaXNhYmxlZCkKY3MwOiBub3QgcHJv YmVkIChkaXNhYmxlZCkKZWQwOiBub3QgcHJvYmVkIChkaXNhYmxlZCkKZmUwOiBub3QgcHJvYmVk IChkaXNhYmxlZCkKaWUwOiBub3QgcHJvYmVkIChkaXNhYmxlZCkKbG5jMDogbm90IHByb2JlZCAo ZGlzYWJsZWQpCnBjaWMwIGZhaWxlZCB0byBwcm9iZSBhdCBwb3J0IDB4M2UwIGlvbWVtIDB4ZDAw MDAgb24gaXNhMApwY2ljMTogbm90IHByb2JlZCAoZGlzYWJsZWQpCnNjMDogPFN5c3RlbSBjb25z b2xlPiBhdCBmbGFncyAweDEwMCBvbiBpc2EwCnNjMDogVkdBIDwxNiB2aXJ0dWFsIGNvbnNvbGVz LCBmbGFncz0weDMwMD4Kc2MwOiBmYjAsIGtiZDAsIHRlcm1pbmFsIGVtdWxhdG9yOiBzYyAoc3lz Y29ucyB0ZXJtaW5hbCkKc2lvMjogbm90IHByb2JlZCAoZGlzYWJsZWQpCnNpbzM6IG5vdCBwcm9i ZWQgKGRpc2FibGVkKQpzbjA6IG5vdCBwcm9iZWQgKGRpc2FibGVkKQp2Z2EwOiA8R2VuZXJpYyBJ U0EgVkdBPiBhdCBwb3J0IDB4M2MwLTB4M2RmIGlvbWVtIDB4YTAwMDAtMHhiZmZmZiBvbiBpc2Ew CmZiMDogdmdhMCwgdmdhLCB0eXBlOlZHQSAoNSksIGZsYWdzOjB4NzAwN2YKZmIwOiBwb3J0OjB4 M2MwLTB4M2RmLCBjcnRjOjB4M2Q0LCBtZW06MHhhMDAwMCAweDIwMDAwCmZiMDogaW5pdCBtb2Rl OjI0LCBiaW9zIG1vZGU6MywgY3VycmVudCBtb2RlOjI0CmZiMDogd2luZG93OjB4YzAwYjgwMDAg c2l6ZTozMmsgZ3JhbjozMmssIGJ1ZjowIHNpemU6MzJrClZHQSBwYXJhbWV0ZXJzIHVwb24gcG93 ZXItdXAKNTAgMTggMTAgMDAgMDAgMDAgMDMgMDAgMDIgNjcgNWYgNGYgNTAgODIgNTUgODEgCmJm IDFmIDAwIDRmIDBlIDBmIDAwIDAwIDA3IDgwIDljIDhlIDhmIDI4IDFmIDk2IApiOSBhMyBmZiAw MCAwMSAwMiAwMyAwNCAwNSAxNCAwNyAzOCAzOSAzYSAzYiAzYyAKM2QgM2UgM2YgMGMgMDAgMGYg MDggMDAgMDAgMDAgMDAgMDAgMTAgMGUgMDAgZmYgClZHQSBwYXJhbWV0ZXJzIGluIEJJT1MgZm9y IG1vZGUgMjQKNTAgMTggMTAgMDAgMTAgMDAgMDMgMDAgMDIgNjcgNWYgNGYgNTAgODIgNTUgODEg CmJmIDFmIDAwIDRmIDBkIDBlIDAwIDAwIDAwIDAwIDljIDhlIDhmIDI4IDFmIDk2IApiOSBhMyBm ZiAwMCAwMSAwMiAwMyAwNCAwNSAxNCAwNyAzOCAzOSAzYSAzYiAzYyAKM2QgM2UgM2YgMGMgMDAg MGYgMDggMDAgMDAgMDAgMDAgMDAgMTAgMGUgMDAgZmYgCkVHQS9WR0EgcGFyYW1ldGVycyB0byBi ZSB1c2VkIGZvciBtb2RlIDI0CjUwIDE4IDEwIDAwIDEwIDAwIDAzIDAwIDAyIDY3IDVmIDRmIDUw IDgyIDU1IDgxIApiZiAxZiAwMCA0ZiAwZCAwZSAwMCAwMCAwMCAwMCA5YyA4ZSA4ZiAyOCAxZiA5 NiAKYjkgYTMgZmYgMDAgMDEgMDIgMDMgMDQgMDUgMTQgMDcgMzggMzkgM2EgM2IgM2MgCjNkIDNl IDNmIDBjIDAwIDBmIDA4IDAwIDAwIDAwIDAwIDAwIDEwIDBlIDAwIGZmIAp2dDA6IG5vdCBwcm9i ZWQgKGRpc2FibGVkKQppc2FfcHJvYmVfY2hpbGRyZW46IHByb2JpbmcgUG5QIGRldmljZXMKRGV2 aWNlIGNvbmZpZ3VyYXRpb24gZmluaXNoZWQuCnByb2NmcyByZWdpc3RlcmVkClRpbWVjb3VudGVy ICJUU0MiIGZyZXF1ZW5jeSA2MDEzNjczMDcgSHogcXVhbGl0eSA4MDAKVGltZWNvdW50ZXJzIHRp Y2sgZXZlcnkgMTAuMDAwIG1zZWMKbG8wOiBicGYgYXR0YWNoZWQKYXRhMC1tYXN0ZXI6IHBpbz0w eDBjIHdkbWE9MHgyMiB1ZG1hPTB4NDQgY2FibGU9ODBwaW4KYXRhMC1tYXN0ZXI6IHNldHRpbmcg UElPNCBvbiBJbnRlbCBJQ0ggY2hpcAphdGEwLW1hc3Rlcjogc2V0dGluZyBVRE1BNjYgb24gSW50 ZWwgSUNIIGNoaXAKYWQwOiA8RlVKSVRTVSBNUEQzMTA4QVQvREQtMDMtNDc+IEFUQS00IGRpc2sg YXQgYXRhMC1tYXN0ZXIKYWQwOiAxMDMwME1CICgyMTA5NTQyNCBzZWN0b3JzKSwgMjA5MjggQywg MTYgSCwgNjMgUywgNTEyIEIKYWQwOiAxNiBzZWNzL2ludCwgMSBkZXB0aCBxdWV1ZSwgVURNQTY2 CmFyOiBGcmVlQlNEIGNoZWNrMSBmYWlsZWQKYXRhMS1tYXN0ZXI6IHBpbz0weDBiIHdkbWE9MHhm ZmZmZmZmZiB1ZG1hPTB4ZmZmZmZmZmYgY2FibGU9NDBwaW4KYXRhMS1tYXN0ZXI6IHNldHRpbmcg UElPMyBvbiBJbnRlbCBJQ0ggY2hpcAphY2QwOiA8TUFUU0hJVEEgQ1ItNTgzL0FTMTA+IENEUk9N IGRyaXZlIGF0IGF0YTEgYXMgbWFzdGVyCmFjZDA6IHJlYWQgMTM3OEtCL3MgKDEzNzhLQi9zKSwg MTI4S0IgYnVmZmVyLCBQSU8zCmFjZDA6IFJlYWRzOiBDRFIsIENEREEKYWNkMDogV3JpdGVzOgph Y2QwOiBBdWRpbzogcGxheSwgMjU2IHZvbHVtZSBsZXZlbHMKYWNkMDogTWVjaGFuaXNtOiBlamVj dGFibGUgdHJheSwgdW5sb2NrZWQKYWNkMDogTWVkaXVtOiBuby9ibGFuayBkaXNjCkdFT006IG5l dyBkaXNrIGFkMApbMF0gZjo4MCB0eXA6MTY1IHMoQ0hTKTowLzAvMSBlKENIUyk6MTAyMy8zMi82 MyBzOjAgbDoyMTA5NTQyNApbMV0gZjowMCB0eXA6MCBzKENIUyk6MC8wLzAgZShDSFMpOjAvMC8w IHM6MCBsOjAKWzJdIGY6MDAgdHlwOjAgcyhDSFMpOjAvMC8wIGUoQ0hTKTowLzAvMCBzOjAgbDow ClszXSBmOjAwIHR5cDowIHMoQ0hTKTowLzAvMCBlKENIUyk6MC8wLzAgczowIGw6MApHRU9NOiBD b25maWd1cmUgYWQwczEsIHN0YXJ0IDAgbGVuZ3RoIDEwODAwODU3MDg4IGVuZCAxMDgwMDg1NzA4 NwpHRU9NOiBDb25maWd1cmUgYWQwYSwgc3RhcnQgMzgzNzc4ODE2IGxlbmd0aCAxMDQxNzA3ODI3 MiBlbmQgMTA4MDA4NTcwODcKR0VPTTogQ29uZmlndXJlIGFkMGIsIHN0YXJ0IDAgbGVuZ3RoIDM4 Mzc3ODgxNiBlbmQgMzgzNzc4ODE1CkdFT006IENvbmZpZ3VyZSBhZDBjLCBzdGFydCAwIGxlbmd0 aCAxMDgwMDg1NzA4OCBlbmQgMTA4MDA4NTcwODcKR0VPTTogQ29uZmlndXJlIGFkMHMxYSwgc3Rh cnQgMzgzNzc4ODE2IGxlbmd0aCAxMDQxNzA3ODI3MiBlbmQgMTA4MDA4NTcwODcKR0VPTTogQ29u ZmlndXJlIGFkMHMxYiwgc3RhcnQgMCBsZW5ndGggMzgzNzc4ODE2IGVuZCAzODM3Nzg4MTUKR0VP TTogQ29uZmlndXJlIGFkMHMxYywgc3RhcnQgMCBsZW5ndGggMTA4MDA4NTcwODggZW5kIDEwODAw ODU3MDg3ClswXSBmOjgwIHR5cDoxNjUgcyhDSFMpOjAvMC8xIGUoQ0hTKToxMDIzLzMyLzYzIHM6 MCBsOjIxMDk1NDI0ClsxXSBmOjAwIHR5cDowIHMoQ0hTKTowLzAvMCBlKENIUyk6MC8wLzAgczow IGw6MApbMl0gZjowMCB0eXA6MCBzKENIUyk6MC8wLzAgZShDSFMpOjAvMC8wIHM6MCBsOjAKWzNd IGY6MDAgdHlwOjAgcyhDSFMpOjAvMC8wIGUoQ0hTKTowLzAvMCBzOjAgbDowCkdFT006IENvbmZp Z3VyZSBhZDBiczEsIHN0YXJ0IDAgbGVuZ3RoIDEwODAwODU3MDg4IGVuZCAxMDgwMDg1NzA4Nwpb MF0gZjo4MCB0eXA6MTY1IHMoQ0hTKTowLzAvMSBlKENIUyk6MTAyMy8zMi82MyBzOjAgbDoyMTA5 NTQyNApbMV0gZjowMCB0eXA6MCBzKENIUyk6MC8wLzAgZShDSFMpOjAvMC8wIHM6MCBsOjAKWzJd IGY6MDAgdHlwOjAgcyhDSFMpOjAvMC8wIGUoQ0hTKTowLzAvMCBzOjAgbDowClszXSBmOjAwIHR5 cDowIHMoQ0hTKTowLzAvMCBlKENIUyk6MC8wLzAgczowIGw6MApHRU9NOiBDb25maWd1cmUgYWQw Y3MxLCBzdGFydCAwIGxlbmd0aCAxMDgwMDg1NzA4OCBlbmQgMTA4MDA4NTcwODcKTW91bnRpbmcg cm9vdCBmcm9tIHVmczovZGV2L2FkMHMxYQpzdGFydF9pbml0OiB0cnlpbmcgL3NiaW4vaW5pdApQ cmUtc2VlZGluZyBQUk5HOgoga2lja3N0YXJ0Ci4KTG9hZGluZyBjb25maWd1cmF0aW9uIGZpbGVz LgpFbnRyb3B5IGhhcnZlc3Rpbmc6CiBpbnRlcnJ1cHRzCiBldGhlcm5ldAogcG9pbnRfdG9fcG9p bnQKIGtpY2tzdGFydAouCnN3YXBvbjogYWRkaW5nIC9kZXYvYWQwczFiIGFzIHN3YXAgZGV2aWNl CgouLi4KCmxvZ2luOg== ------=_20050427080054_65826 Content-Type: application/octet-stream; name="dmesg.today" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="dmesg.today" Q29weXJpZ2h0IChjKSAxOTkyLTIwMDUgVGhlIEZyZWVCU0QgUHJvamVjdC4KQ29weXJpZ2h0IChj KSAxOTc5LCAxOTgwLCAxOTgzLCAxOTg2LCAxOTg4LCAxOTg5LCAxOTkxLCAxOTkyLCAxOTkzLCAx OTk0CglUaGUgUmVnZW50cyBvZiB0aGUgVW5pdmVyc2l0eSBvZiBDYWxpZm9ybmlhLiBBbGwgcmln aHRzIHJlc2VydmVkLgpGcmVlQlNEIDUuNC1SQzIgIzA6IFN1biBBcHIgMTAgMDk6MDg6MTQgVVRD IDIwMDUKICAgIHJvb3RAaGFybG93LmNzZS5idWZmYWxvLmVkdTovdXNyL29iai91c3Ivc3JjL3N5 cy9HRU5FUklDClByZWxvYWRlZCBlbGYga2VybmVsICIvYm9vdC9rZXJuZWwva2VybmVsIiBhdCAw eGMwYTM2MDAwLgpQcmVsb2FkZWQgZWxmIG1vZHVsZSAiL2Jvb3Qva2VybmVsL2FjcGkua28iIGF0 IDB4YzBhMzYxZjQuCkNhbGlicmF0aW5nIGNsb2NrKHMpIC4uLiBpODI1NCBjbG9jazogMTE5MzIy OSBIegpDTEtfVVNFX0k4MjU0X0NBTElCUkFUSU9OIG5vdCBzcGVjaWZpZWQgLSB1c2luZyBkZWZh dWx0IGZyZXF1ZW5jeQpUaW1lY291bnRlciAiaTgyNTQiIGZyZXF1ZW5jeSAxMTkzMTgyIEh6IHF1 YWxpdHkgMApDYWxpYnJhdGluZyBUU0MgY2xvY2sgLi4uIFRTQyBjbG9jazogNjAxMzY3MDA3IEh6 CkNQVTogUGVudGl1bSBJSUkvUGVudGl1bSBJSUkgWGVvbi9DZWxlcm9uICg2MDEuMzctTUh6IDY4 Ni1jbGFzcyBDUFUpCiAgT3JpZ2luID0gIkdlbnVpbmVJbnRlbCIgIElkID0gMHg2NzMgIFN0ZXBw aW5nID0gMwogIEZlYXR1cmVzPTB4Mzg3ZjlmZjxGUFUsVk1FLERFLFBTRSxUU0MsTVNSLFBBRSxN Q0UsQ1g4LFNFUCxNVFJSLFBHRSxNQ0EsQ01PVixQQVQsUFNFMzYsUE4sTU1YLEZYU1IsU1NFPgpy ZWFsIG1lbW9yeSAgPSAxMzMxMDM2MTYgKDEyNiBNQikKUGh5c2ljYWwgbWVtb3J5IGNodW5rKHMp OgoweDAwMDAwMDAwMDAwMDEwMDAgLSAweDAwMDAwMDAwMDAwOWVmZmYsIDY0NzE2OCBieXRlcyAo MTU4IHBhZ2VzKQoweDAwMDAwMDAwMDAxMDAwMDAgLSAweDAwMDAwMDAwMDAzZmZmZmYsIDMxNDU3 MjggYnl0ZXMgKDc2OCBwYWdlcykKMHgwMDAwMDAwMDAwYzI1MDAwIC0gMHgwMDAwMDAwMDA3Yzgz ZmZmLCAxMTc4Mjk2MzIgYnl0ZXMgKDI4NzY3IHBhZ2VzKQphdmFpbCBtZW1vcnkgPSAxMjA1OTg1 MjggKDExNSBNQikKYmlvczMyOiBGb3VuZCBCSU9TMzIgU2VydmljZSBEaXJlY3RvcnkgaGVhZGVy IGF0IDB4YzAwZmFlMjAKYmlvczMyOiBFbnRyeSA9IDB4ZmIyOTAgKGMwMGZiMjkwKSAgUmV2ID0g MCAgTGVuID0gMQpwY2liaW9zOiBQQ0kgQklPUyBlbnRyeSBhdCAweGYwMDAwKzB4YjJjMApwbnBi aW9zOiBGb3VuZCBQblAgQklPUyBkYXRhIGF0IDB4YzAwZmJjNDAKcG5wYmlvczogRW50cnkgPSBm MDAwMDpiYzcwICBSZXYgPSAxLjAKT3RoZXIgQklPUyBzaWduYXR1cmVzIGZvdW5kOgp3bGFuOiA8 ODAyLjExIExpbmsgTGF5ZXI+Cm51bGw6IDxudWxsIGRldmljZSwgemVybyBkZXZpY2U+CnJhbmRv bTogPGVudHJvcHkgc291cmNlLCBTb2Z0d2FyZSwgWWFycm93PgppbzogPEkvTz4KbWVtOiA8bWVt b3J5PgpQZW50aXVtIFBybyBNVFJSIHN1cHBvcnQgZW5hYmxlZApucHgwOiBbRkFTVF0KbnB4MDog PG1hdGggcHJvY2Vzc29yPiBvbiBtb3RoZXJib2FyZApucHgwOiBJTlQgMTYgaW50ZXJmYWNlCmFj cGkwOiA8SkVUV0FZIEFXUkRBQ1BJPiBvbiBtb3RoZXJib2FyZAphY3BpMDogW01QU0FGRV0KcGNp X29wZW4oMSk6CW1vZGUgMSBhZGRyIHBvcnQgKDB4MGNmOCkgaXMgMHg4MDAwMDA1MApwY2lfb3Bl bigxYSk6CW1vZGUxcmVzPTB4ODAwMDAwMDAgKDB4ODAwMDAwMDApCnBjaV9jZmdjaGVjazoJZGV2 aWNlIDAgW2NsYXNzPTA2MDAwMF0gW2hkcj0wMF0gaXMgdGhlcmUgKGlkPTcxMjA4MDg2KQpwY2li aW9zOiBCSU9TIHZlcnNpb24gMi4xMApGb3VuZCAkUElSIHRhYmxlLCA4IGVudHJpZXMgYXQgMHhj MDBmZGVmMApQQ0ktT25seSBJbnRlcnJ1cHRzOiA1IDkgMTAgMTEKTG9jYXRpb24gIEJ1cyBEZXZp Y2UgUGluICBMaW5rICBJUlFzCnNsb3QgMSAgICAgIDAgICAzMCAgICBBICAgMHg2MCAgMyA0IDUg NyA5IDEwIDExIDEyIDE0IDE1CnNsb3QgMSAgICAgIDAgICAzMCAgICBCICAgMHg2MSAgMyA0IDUg NyA5IDEwIDExIDEyIDE0IDE1CnNsb3QgMSAgICAgIDAgICAzMCAgICBDICAgMHg2MiAgMyA0IDUg NyA5IDEwIDExIDEyIDE0IDE1CnNsb3QgMSAgICAgIDAgICAzMCAgICBEICAgMHg2MyAgMyA0IDUg NyA5IDEwIDExIDEyIDE0IDE1CnNsb3QgMiAgICAgIDAgICAxNiAgICBBICAgMHg2MSAgMyA0IDUg NyA5IDEwIDExIDEyIDE0IDE1CnNsb3QgMiAgICAgIDAgICAxNiAgICBCICAgMHg2MiAgMyA0IDUg NyA5IDEwIDExIDEyIDE0IDE1CnNsb3QgMiAgICAgIDAgICAxNiAgICBDICAgMHg2MyAgMyA0IDUg NyA5IDEwIDExIDEyIDE0IDE1CnNsb3QgMiAgICAgIDAgICAxNiAgICBEICAgMHg2MCAgMyA0IDUg NyA5IDEwIDExIDEyIDE0IDE1CnNsb3QgMyAgICAgIDEgICAgOCAgICBBICAgMHg2MCAgMyA0IDUg NyA5IDEwIDExIDEyIDE0IDE1CnNsb3QgMyAgICAgIDEgICAgOCAgICBCICAgMHg2MSAgMyA0IDUg NyA5IDEwIDExIDEyIDE0IDE1CnNsb3QgMyAgICAgIDEgICAgOCAgICBDICAgMHg2MiAgMyA0IDUg NyA5IDEwIDExIDEyIDE0IDE1CnNsb3QgMyAgICAgIDEgICAgOCAgICBEICAgMHg2MyAgMyA0IDUg NyA5IDEwIDExIDEyIDE0IDE1CnNsb3QgNCAgICAgIDEgICAgOSAgICBBICAgMHg2MSAgMyA0IDUg NyA5IDEwIDExIDEyIDE0IDE1CnNsb3QgNCAgICAgIDEgICAgOSAgICBCICAgMHg2MiAgMyA0IDUg NyA5IDEwIDExIDEyIDE0IDE1CnNsb3QgNCAgICAgIDEgICAgOSAgICBDICAgMHg2MyAgMyA0IDUg NyA5IDEwIDExIDEyIDE0IDE1CnNsb3QgNCAgICAgIDEgICAgOSAgICBEICAgMHg2MCAgMyA0IDUg NyA5IDEwIDExIDEyIDE0IDE1CnNsb3QgNSAgICAgIDEgICAxMCAgICBBICAgMHg2MiAgMyA0IDUg NyA5IDEwIDExIDEyIDE0IDE1CnNsb3QgNSAgICAgIDEgICAxMCAgICBCICAgMHg2MyAgMyA0IDUg NyA5IDEwIDExIDEyIDE0IDE1CnNsb3QgNSAgICAgIDEgICAxMCAgICBDICAgMHg2MCAgMyA0IDUg NyA5IDEwIDExIDEyIDE0IDE1CnNsb3QgNSAgICAgIDEgICAxMCAgICBEICAgMHg2MSAgMyA0IDUg NyA5IDEwIDExIDEyIDE0IDE1CnNsb3QgNiAgICAgIDEgICAxMSAgICBBICAgMHg2MyAgMyA0IDUg NyA5IDEwIDExIDEyIDE0IDE1CnNsb3QgNiAgICAgIDEgICAxMSAgICBCICAgMHg2MCAgMyA0IDUg NyA5IDEwIDExIDEyIDE0IDE1CnNsb3QgNiAgICAgIDEgICAxMSAgICBDICAgMHg2MSAgMyA0IDUg NyA5IDEwIDExIDEyIDE0IDE1CnNsb3QgNiAgICAgIDEgICAxMSAgICBEICAgMHg2MiAgMyA0IDUg NyA5IDEwIDExIDEyIDE0IDE1CmVtYmVkZGVkICAgIDAgICAgMSAgICBBICAgMHg2MCAgMyA0IDUg NyA5IDEwIDExIDEyIDE0IDE1CmVtYmVkZGVkICAgIDAgICAgMSAgICBCICAgMHg2MSAgMyA0IDUg NyA5IDEwIDExIDEyIDE0IDE1CmVtYmVkZGVkICAgIDAgICAgMSAgICBDICAgMHg2MiAgMyA0IDUg NyA5IDEwIDExIDEyIDE0IDE1CmVtYmVkZGVkICAgIDAgICAgMSAgICBEICAgMHg2MyAgMyA0IDUg NyA5IDEwIDExIDEyIDE0IDE1CmVtYmVkZGVkICAgIDAgICAzMSAgICBBICAgMHg2MCAgMyA0IDUg NyA5IDEwIDExIDEyIDE0IDE1CmVtYmVkZGVkICAgIDAgICAzMSAgICBCICAgMHg2MSAgMyA0IDUg NyA5IDEwIDExIDEyIDE0IDE1CmVtYmVkZGVkICAgIDAgICAzMSAgICBDICAgMHg2MiAgMyA0IDUg NyA5IDEwIDExIDEyIDE0IDE1CmVtYmVkZGVkICAgIDAgICAzMSAgICBEICAgMHg2MyAgMyA0IDUg NyA5IDEwIDExIDEyIDE0IDE1CmFjcGlfYnVzX251bWJlcjogcm9vdCBidXMgaGFzIG5vIF9CQk4s IGFzc3VtaW5nIDAKQWNwaU9zRGVyaXZlUGNpSWQ6IGJ1cyAwIGRldiAzMSBmdW5jIDAKYWNwaTA6 IFBvd2VyIEJ1dHRvbiAoZml4ZWQpCmFjcGlfYnVzX251bWJlcjogcm9vdCBidXMgaGFzIG5vIF9C Qk4sIGFzc3VtaW5nIDAKQWNwaU9zRGVyaXZlUGNpSWQ6IGJ1cyAwIGRldiAzMSBmdW5jIDAKQUNQ SSB0aW1lcjogMS8xIDEvMCAxLzAgMS8wIDEvMCAxLzAgMS8wIDEvMCAxLzAgMS8wIC0+IDEwClRp bWVjb3VudGVyICJBQ1BJLWZhc3QiIGZyZXF1ZW5jeSAzNTc5NTQ1IEh6IHF1YWxpdHkgMTAwMAph Y3BpX3RpbWVyMDogPDI0LWJpdCB0aW1lciBhdCAzLjU3OTU0NU1Iej4gcG9ydCAweDQwMDgtMHg0 MDBiIG9uIGFjcGkwCmNwdTA6IDxBQ1BJIENQVSAoMyBDeCBzdGF0ZXMpPiBvbiBhY3BpMAphY3Bp X3Rocm90dGxlMDogPEFDUEkgQ1BVIFRocm90dGxpbmc+IG9uIGNwdTAKYWNwaV90aHJvdHRsZTA6 IFBfQ05UIGZyb20gUF9CTEsgMHg0MDEwCmFjcGlfYnV0dG9uMDogPFBvd2VyIEJ1dHRvbj4gb24g YWNwaTAKcGNpYjA6IDxBQ1BJIEhvc3QtUENJIGJyaWRnZT4gcG9ydCAweDQwMDAtMHg0MGY3LDB4 NTAwMC0weDUwMGYsMHhjZjgtMHhjZmYgb24gYWNwaTAKQUNQSSBQQ0kgbGluayBpbml0aWFsIGNv bmZpZ3VyYXRpb246ClxcX1NCXy5QQ0kwLklTQV8uTE5LQSBpcnEgIDA6IFsgMyAgNCAgNSAgNiAg NyAxMCAxMSAxMiAxNCAxNV0gMTArIGxvdyxsZXZlbCxzaGFyYWJsZSAwLjEuMApcXF9TQl8uUENJ MC5JU0FfLkxOS0IgaXJxICAwOiBbIDMgIDQgIDUgIDYgIDcgMTAgMTEgMTIgMTQgMTVdICA1KyBs b3csbGV2ZWwsc2hhcmFibGUgMC4xLjEKXFxfU0JfLlBDSTAuSVNBXy5MTktDIGlycSAgMDogWyAz ICA0ICA1ICA2ICA3IDEwIDExIDEyIDE0IDE1XSAxMSsgbG93LGxldmVsLHNoYXJhYmxlIDAuMS4y ClxcX1NCXy5QQ0kwLklTQV8uTE5LRCBpcnEgIDA6IFsgMyAgNCAgNSAgNiAgNyAxMCAxMSAxMiAx NCAxNV0gIDkrIGxvdyxsZXZlbCxzaGFyYWJsZSAwLjEuMwpcXF9TQl8uUENJMC5JU0FfLkxOS0Eg aXJxICAwOiBbIDMgIDQgIDUgIDYgIDcgMTAgMTEgMTIgMTQgMTVdIDEwKyBsb3csbGV2ZWwsc2hh cmFibGUgMC4zMC4wClxcX1NCXy5QQ0kwLklTQV8uTE5LQiBpcnEgIDA6IFsgMyAgNCAgNSAgNiAg NyAxMCAxMSAxMiAxNCAxNV0gIDUrIGxvdyxsZXZlbCxzaGFyYWJsZSAwLjMwLjEKXFxfU0JfLlBD STAuSVNBXy5MTktDIGlycSAgMDogWyAzICA0ICA1ICA2ICA3IDEwIDExIDEyIDE0IDE1XSAxMSsg bG93LGxldmVsLHNoYXJhYmxlIDAuMzAuMgpcXF9TQl8uUENJMC5JU0FfLkxOS0QgaXJxICAwOiBb IDMgIDQgIDUgIDYgIDcgMTAgMTEgMTIgMTQgMTVdICA5KyBsb3csbGV2ZWwsc2hhcmFibGUgMC4z MC4zClxcX1NCXy5QQ0kwLklTQV8uTE5LQiBpcnEgIDA6IFsgMyAgNCAgNSAgNiAgNyAxMCAxMSAx MiAxNCAxNV0gIDUrIGxvdyxsZXZlbCxzaGFyYWJsZSAwLjE2LjAKXFxfU0JfLlBDSTAuSVNBXy5M TktDIGlycSAgMDogWyAzICA0ICA1ICA2ICA3IDEwIDExIDEyIDE0IDE1XSAxMSsgbG93LGxldmVs LHNoYXJhYmxlIDAuMTYuMQpcXF9TQl8uUENJMC5JU0FfLkxOS0QgaXJxICAwOiBbIDMgIDQgIDUg IDYgIDcgMTAgMTEgMTIgMTQgMTVdICA5KyBsb3csbGV2ZWwsc2hhcmFibGUgMC4xNi4yClxcX1NC Xy5QQ0kwLklTQV8uTE5LQSBpcnEgIDA6IFsgMyAgNCAgNSAgNiAgNyAxMCAxMSAxMiAxNCAxNV0g MTArIGxvdyxsZXZlbCxzaGFyYWJsZSAwLjE2LjMKXFxfU0JfLlBDSTAuSVNBXy5MTktBIGlycSAg MDogWyAzICA0ICA1ICA2ICA3IDEwIDExIDEyIDE0IDE1XSAxMCsgbG93LGxldmVsLHNoYXJhYmxl IDAuMzEuMApcXF9TQl8uUENJMC5JU0FfLkxOS0IgaXJxICAwOiBbIDMgIDQgIDUgIDYgIDcgMTAg MTEgMTIgMTQgMTVdICA1KyBsb3csbGV2ZWwsc2hhcmFibGUgMC4zMS4xClxcX1NCXy5QQ0kwLklT QV8uTE5LQyBpcnEgIDA6IFsgMyAgNCAgNSAgNiAgNyAxMCAxMSAxMiAxNCAxNV0gMTErIGxvdyxs ZXZlbCxzaGFyYWJsZSAwLjMxLjIKXFxfU0JfLlBDSTAuSVNBXy5MTktEIGlycSAgMDogWyAzICA0 ICA1ICA2ICA3IDEwIDExIDEyIDE0IDE1XSAgOSsgbG93LGxldmVsLHNoYXJhYmxlIDAuMzEuMwpw Y2kwOiA8QUNQSSBQQ0kgYnVzPiBvbiBwY2liMApwY2kwOiBwaHlzaWNhbCBidXM9MApmb3VuZC0+ CXZlbmRvcj0weDgwODYsIGRldj0weDcxMjAsIHJldmlkPTB4MDMKCWJ1cz0wLCBzbG90PTAsIGZ1 bmM9MAoJY2xhc3M9MDYtMDAtMDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MAoJY21kcmVnPTB4MDAw Niwgc3RhdHJlZz0weDIwODAsIGNhY2hlbG5zej0wIChkd29yZHMpCglsYXR0aW1lcj0weDAwICgw IG5zKSwgbWluZ250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKCW1hcFsxMF06IHR5 cGUgMywgcmFuZ2UgMzIsIGJhc2UgZDAwMDAwMDAsIHNpemUgMjYsIGVuYWJsZWQKCW1hcFsxNF06 IHR5cGUgMSwgcmFuZ2UgMzIsIGJhc2UgZDQxMDAwMDAsIHNpemUgMTksIGVuYWJsZWQKcGNpYjA6 IG1hdGNoZWQgZW50cnkgZm9yIDAuMS5JTlRBIChzcmMgXFxfU0JfLlBDSTAuSVNBXy5MTktBKQpw Y2liMDogcG9zc2libGUgaW50ZXJydXB0czogIDMgIDQgIDUgIDYgIDcgMTAgMTEgMTIgMTQgMTUK QUNQSSBQQ0kgbGluayBhcmJpdHJhdGVkIHNldHRpbmdzOgpcXF9TQl8uUENJMC5JU0FfLkxOS0Eg KHJlZmVyZW5jZXMgNCwgcHJpb3JpdHkgNTA2NjApOgoJaW50ZXJydXB0czoJICAgIDExICAgIDEw ICAgICA1ICAgIDEyICAgICA3ICAgICA2ICAgICA0ICAgICAzICAgIDE1ICAgIDE0CglwZW5hbHR5 OgkgICAxNjAgICAxNjAgICAyMTAgIDUxNjAgIDUxNjAgIDUxNjAgIDUxNjAgIDUxNjAgNTAxNjAg NTAxNjAKXFxfU0JfLlBDSTAuSVNBXy5MTktCIChyZWZlcmVuY2VzIDQsIHByaW9yaXR5IDUwNjYw KToKCWludGVycnVwdHM6CSAgICAxMSAgICAxMCAgICAgNSAgICAxMiAgICAgNyAgICAgNiAgICAg NCAgICAgMyAgICAxNSAgICAxNAoJcGVuYWx0eToJICAgMTYwICAgMTYwICAgMjEwICA1MTYwICA1 MTYwICA1MTYwICA1MTYwICA1MTYwIDUwMTYwIDUwMTYwClxcX1NCXy5QQ0kwLklTQV8uTE5LQyAo cmVmZXJlbmNlcyA0LCBwcmlvcml0eSA1MDY2MCk6CglpbnRlcnJ1cHRzOgkgICAgMTEgICAgMTAg ICAgIDUgICAgMTIgICAgIDcgICAgIDYgICAgIDQgICAgIDMgICAgMTUgICAgMTQKCXBlbmFsdHk6 CSAgIDE2MCAgIDE2MCAgIDIxMCAgNTE2MCAgNTE2MCAgNTE2MCAgNTE2MCAgNTE2MCA1MDE2MCA1 MDE2MApcXF9TQl8uUENJMC5JU0FfLkxOS0QgKHJlZmVyZW5jZXMgNCwgcHJpb3JpdHkgNTA2NjAp OgoJaW50ZXJydXB0czoJICAgIDExICAgIDEwICAgICA1ICAgIDEyICAgICA3ICAgICA2ICAgICA0 ICAgICAzICAgIDE1ICAgIDE0CglwZW5hbHR5OgkgICAxNjAgICAxNjAgICAyMTAgIDUxNjAgIDUx NjAgIDUxNjAgIDUxNjAgIDUxNjAgNTAxNjAgNTAxNjAKcGNpYjA6IHNsb3QgMSBJTlRBIHJvdXRl ZCB0byBpcnEgMTAgdmlhIFxcX1NCXy5QQ0kwLklTQV8uTE5LQQpmb3VuZC0+CXZlbmRvcj0weDgw ODYsIGRldj0weDcxMjEsIHJldmlkPTB4MDMKCWJ1cz0wLCBzbG90PTEsIGZ1bmM9MAoJY2xhc3M9 MDMtMDAtMDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MAoJY21kcmVnPTB4MDAwNywgc3RhdHJlZz0w eDAyYjAsIGNhY2hlbG5zej0wIChkd29yZHMpCglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250 PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKCWludHBpbj1hLCBpcnE9MTAKCXBvd2Vy c3BlYyAxICBzdXBwb3J0cyBEMCBEMyAgY3VycmVudCBEMApmb3VuZC0+CXZlbmRvcj0weDgwODYs IGRldj0weDI0MTgsIHJldmlkPTB4MDIKCWJ1cz0wLCBzbG90PTMwLCBmdW5jPTAKCWNsYXNzPTA2 LTA0LTAwLCBoZHJ0eXBlPTB4MDEsIG1mZGV2PTAKCWNtZHJlZz0weDAxMDcsIHN0YXRyZWc9MHgw MDgwLCBjYWNoZWxuc3o9MCAoZHdvcmRzKQoJbGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0w eDA2ICgxNTAwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCmZvdW5kLT4JdmVuZG9yPTB4ODA4Niwg ZGV2PTB4MjQxMCwgcmV2aWQ9MHgwMgoJYnVzPTAsIHNsb3Q9MzEsIGZ1bmM9MAoJY2xhc3M9MDYt MDEtMDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MQoJY21kcmVnPTB4MDAwZiwgc3RhdHJlZz0weDAy ODAsIGNhY2hlbG5zej0wIChkd29yZHMpCglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4 MDAgKDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKCW1hcFsyMF06IHR5cGUgNCwgcmFuZ2UgMzIs IGJhc2UgMDAwMGYwMDAsIHNpemUgIDQsIGVuYWJsZWQKZm91bmQtPgl2ZW5kb3I9MHg4MDg2LCBk ZXY9MHgyNDExLCByZXZpZD0weDAyCglidXM9MCwgc2xvdD0zMSwgZnVuYz0xCgljbGFzcz0wMS0w MS04MCwgaGRydHlwZT0weDAwLCBtZmRldj0wCgljbWRyZWc9MHgwMDA1LCBzdGF0cmVnPTB4MDI4 MCwgY2FjaGVsbnN6PTAgKGR3b3JkcykKCWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9MHgw MCAoMCBucyksIG1heGxhdD0weDAwICgwIG5zKQoJbWFwWzIwXTogdHlwZSA0LCByYW5nZSAzMiwg YmFzZSAwMDAwZDAwMCwgc2l6ZSAgNSwgZW5hYmxlZApwY2liMDogbWF0Y2hlZCBlbnRyeSBmb3Ig MC4zMS5JTlREIChzcmMgXFxfU0JfLlBDSTAuSVNBXy5MTktEKQpwY2liMDogcG9zc2libGUgaW50 ZXJydXB0czogIDMgIDQgIDUgIDYgIDcgMTAgMTEgMTIgMTQgMTUKQUNQSSBQQ0kgbGluayBhcmJp dHJhdGVkIHNldHRpbmdzOgpcXF9TQl8uUENJMC5JU0FfLkxOS0IgKHJlZmVyZW5jZXMgNCwgcHJp b3JpdHkgNTEzMTYpOgoJaW50ZXJydXB0czoJICAgIDExICAgIDEwICAgICA1ICAgIDEyICAgICA3 ICAgICA2ICAgICA0ICAgICAzICAgIDE1ICAgIDE0CglwZW5hbHR5OgkgICAzMjAgICAzNjAgICAz NzAgIDUzMjAgIDUzMjAgIDUzMjAgIDUzMjAgIDUzMjAgNTAzMjAgNTAzMjAKXFxfU0JfLlBDSTAu SVNBXy5MTktDIChyZWZlcmVuY2VzIDQsIHByaW9yaXR5IDUxMzE2KToKCWludGVycnVwdHM6CSAg ICAxMSAgICAxMCAgICAgNSAgICAxMiAgICAgNyAgICAgNiAgICAgNCAgICAgMyAgICAxNSAgICAx NAoJcGVuYWx0eToJICAgMzIwICAgMzYwICAgMzcwICA1MzIwICA1MzIwICA1MzIwICA1MzIwICA1 MzIwIDUwMzIwIDUwMzIwClxcX1NCXy5QQ0kwLklTQV8uTE5LRCAocmVmZXJlbmNlcyA0LCBwcmlv cml0eSA1MTMxNik6CglpbnRlcnJ1cHRzOgkgICAgMTEgICAgMTAgICAgIDUgICAgMTIgICAgIDcg ICAgIDYgICAgIDQgICAgIDMgICAgMTUgICAgMTQKCXBlbmFsdHk6CSAgIDMyMCAgIDM2MCAgIDM3 MCAgNTMyMCAgNTMyMCAgNTMyMCAgNTMyMCAgNTMyMCA1MDMyMCA1MDMyMApwY2liMDogc2xvdCAz MSBJTlREIHJvdXRlZCB0byBpcnEgOSB2aWEgXFxfU0JfLlBDSTAuSVNBXy5MTktECmZvdW5kLT4J dmVuZG9yPTB4ODA4NiwgZGV2PTB4MjQxMiwgcmV2aWQ9MHgwMgoJYnVzPTAsIHNsb3Q9MzEsIGZ1 bmM9MgoJY2xhc3M9MGMtMDMtMDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MAoJY21kcmVnPTB4MDAw NSwgc3RhdHJlZz0weDAyODAsIGNhY2hlbG5zej0wIChkd29yZHMpCglsYXR0aW1lcj0weDAwICgw IG5zKSwgbWluZ250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKCWludHBpbj1kLCBp cnE9OQphZ3AwOiA8SW50ZWwgODI4MTAgKGk4MTAgR01DSCkgU1ZHQSBjb250cm9sbGVyPiBtZW0g MHhkNDEwMDAwMC0weGQ0MTdmZmZmLDB4ZDAwMDAwMDAtMHhkM2ZmZmZmZiBpcnEgMTAgYXQgZGV2 aWNlIDEuMCBvbiBwY2kwCmFncDA6IFJlc2VydmVkIDB4NDAwMDAwMCBieXRlcyBmb3IgcmlkIDB4 MTAgdHlwZSAzIGF0IDB4ZDAwMDAwMDAKYWdwMDogUmVzZXJ2ZWQgMHg4MDAwMCBieXRlcyBmb3Ig cmlkIDB4MTQgdHlwZSAzIGF0IDB4ZDQxMDAwMDAKcGNpYjE6IDxBQ1BJIFBDSS1QQ0kgYnJpZGdl PiBhdCBkZXZpY2UgMzAuMCBvbiBwY2kwCnBjaWIxOiAgIHNlY29uZGFyeSBidXMgICAgIDEKcGNp YjE6ICAgc3Vib3JkaW5hdGUgYnVzICAgMQpwY2liMTogICBJL08gZGVjb2RlICAgICAgICAweGMw MDAtMHhjZmZmCnBjaWIxOiAgIG1lbW9yeSBkZWNvZGUgICAgIDB4ZDQwMDAwMDAtMHhkNDBmZmZm ZgpwY2liMTogICBwcmVmZXRjaGVkIGRlY29kZSAweGZmZjAwMDAwLTB4ZmZmZmYKcGNpYjE6ICAg U3VidHJhY3RpdmVseSBkZWNvZGVkIGJyaWRnZS4KQUNQSSBQQ0kgbGluayBpbml0aWFsIGNvbmZp Z3VyYXRpb246ClxcX1NCXy5QQ0kwLklTQV8uTE5LQSBpcnEqMTA6IFsgMyAgNCAgNSAgNiAgNyAx MCAxMSAxMiAxNCAxNV0gMTArIGxvdyxsZXZlbCxzaGFyYWJsZSAxLjguMApcXF9TQl8uUENJMC5J U0FfLkxOS0IgaXJxICAwOiBbIDMgIDQgIDUgIDYgIDcgMTAgMTEgMTIgMTQgMTVdICA1KyBsb3cs bGV2ZWwsc2hhcmFibGUgMS44LjEKXFxfU0JfLlBDSTAuSVNBXy5MTktDIGlycSAgMDogWyAzICA0 ICA1ICA2ICA3IDEwIDExIDEyIDE0IDE1XSAxMSsgbG93LGxldmVsLHNoYXJhYmxlIDEuOC4yClxc X1NCXy5QQ0kwLklTQV8uTE5LRCBpcnEqIDk6IFsgMyAgNCAgNSAgNiAgNyAxMCAxMSAxMiAxNCAx NV0gIDkrIGxvdyxsZXZlbCxzaGFyYWJsZSAxLjguMwpcXF9TQl8uUENJMC5JU0FfLkxOS0IgaXJx ICAwOiBbIDMgIDQgIDUgIDYgIDcgMTAgMTEgMTIgMTQgMTVdICA1KyBsb3csbGV2ZWwsc2hhcmFi bGUgMS45LjAKXFxfU0JfLlBDSTAuSVNBXy5MTktDIGlycSAgMDogWyAzICA0ICA1ICA2ICA3IDEw IDExIDEyIDE0IDE1XSAxMSsgbG93LGxldmVsLHNoYXJhYmxlIDEuOS4xClxcX1NCXy5QQ0kwLklT QV8uTE5LRCBpcnEqIDk6IFsgMyAgNCAgNSAgNiAgNyAxMCAxMSAxMiAxNCAxNV0gIDkrIGxvdyxs ZXZlbCxzaGFyYWJsZSAxLjkuMgpcXF9TQl8uUENJMC5JU0FfLkxOS0EgaXJxKjEwOiBbIDMgIDQg IDUgIDYgIDcgMTAgMTEgMTIgMTQgMTVdIDEwKyBsb3csbGV2ZWwsc2hhcmFibGUgMS45LjMKXFxf U0JfLlBDSTAuSVNBXy5MTktDIGlycSAgMDogWyAzICA0ICA1ICA2ICA3IDEwIDExIDEyIDE0IDE1 XSAxMSsgbG93LGxldmVsLHNoYXJhYmxlIDEuMTAuMApcXF9TQl8uUENJMC5JU0FfLkxOS0QgaXJx KiA5OiBbIDMgIDQgIDUgIDYgIDcgMTAgMTEgMTIgMTQgMTVdICA5KyBsb3csbGV2ZWwsc2hhcmFi bGUgMS4xMC4xClxcX1NCXy5QQ0kwLklTQV8uTE5LQSBpcnEqMTA6IFsgMyAgNCAgNSAgNiAgNyAx MCAxMSAxMiAxNCAxNV0gMTArIGxvdyxsZXZlbCxzaGFyYWJsZSAxLjEwLjIKXFxfU0JfLlBDSTAu SVNBXy5MTktCIGlycSAgMDogWyAzICA0ICA1ICA2ICA3IDEwIDExIDEyIDE0IDE1XSAgNSsgbG93 LGxldmVsLHNoYXJhYmxlIDEuMTAuMwpcXF9TQl8uUENJMC5JU0FfLkxOS0QgaXJxKiA5OiBbIDMg IDQgIDUgIDYgIDcgMTAgMTEgMTIgMTQgMTVdICA5KyBsb3csbGV2ZWwsc2hhcmFibGUgMS4xMS4w ClxcX1NCXy5QQ0kwLklTQV8uTE5LQSBpcnEqMTA6IFsgMyAgNCAgNSAgNiAgNyAxMCAxMSAxMiAx NCAxNV0gMTArIGxvdyxsZXZlbCxzaGFyYWJsZSAxLjExLjEKXFxfU0JfLlBDSTAuSVNBXy5MTktC IGlycSAgMDogWyAzICA0ICA1ICA2ICA3IDEwIDExIDEyIDE0IDE1XSAgNSsgbG93LGxldmVsLHNo YXJhYmxlIDEuMTEuMgpcXF9TQl8uUENJMC5JU0FfLkxOS0MgaXJxICAwOiBbIDMgIDQgIDUgIDYg IDcgMTAgMTEgMTIgMTQgMTVdIDExKyBsb3csbGV2ZWwsc2hhcmFibGUgMS4xMS4zCnBjaTE6IDxB Q1BJIFBDSSBidXM+IG9uIHBjaWIxCnBjaTE6IHBoeXNpY2FsIGJ1cz0xCgltYXBbMTBdOiB0eXBl IDQsIHJhbmdlIDMyLCBiYXNlIDAwMDBjMDAwLCBzaXplICA3LCBlbmFibGVkCnBjaWIxOiBkZXZp Y2UgKG51bGwpIHJlcXVlc3RlZCBkZWNvZGVkIEkvTyByYW5nZSAweGMwMDAtMHhjMDdmCgltYXBb MTRdOiB0eXBlIDEsIHJhbmdlIDMyLCBiYXNlIGQ0MDAwMDAwLCBzaXplICA3LCBlbmFibGVkCnBj aWIxOiBkZXZpY2UgKG51bGwpIHJlcXVlc3RlZCBkZWNvZGVkIG1lbW9yeSByYW5nZSAweGQ0MDAw MDAwLTB4ZDQwMDAwN2YKcGNpYjE6IG1hdGNoZWQgZW50cnkgZm9yIDEuMTAuSU5UQSAoc3JjIFxc X1NCXy5QQ0kwLklTQV8uTE5LQykKcGNpYjE6IHBvc3NpYmxlIGludGVycnVwdHM6ICAzICA0ICA1 ICA2ICA3IDEwIDExIDEyIDE0IDE1CkFDUEkgUENJIGxpbmsgYXJiaXRyYXRlZCBzZXR0aW5nczoK XFxfU0JfLlBDSTAuSVNBXy5MTktCIChyZWZlcmVuY2VzIDgsIHByaW9yaXR5IDEwNTE5Mik6Cglp bnRlcnJ1cHRzOgkgICAgMTEgICAgMTAgICAgIDUgICAgMTIgICAgIDcgICAgIDYgICAgIDQgICAg IDMgICAgMTUgICAgMTQKCXBlbmFsdHk6CSAgIDY0MCAgIDY4MCAgIDY5MCAgNTY0MCAgNTY0MCAg NTY0MCAgNTY0MCAgNTY0MCA1MDY0MCA1MDY0MApcXF9TQl8uUENJMC5JU0FfLkxOS0MgKHJlZmVy ZW5jZXMgOCwgcHJpb3JpdHkgMTA1MTkyKToKCWludGVycnVwdHM6CSAgICAxMSAgICAxMCAgICAg NSAgICAxMiAgICAgNyAgICAgNiAgICAgNCAgICAgMyAgICAxNSAgICAxNAoJcGVuYWx0eToJICAg NjQwICAgNjgwICAgNjkwICA1NjQwICA1NjQwICA1NjQwICA1NjQwICA1NjQwIDUwNjQwIDUwNjQw CnBjaWIxOiBzbG90IDEwIElOVEEgcm91dGVkIHRvIGlycSAxMSB2aWEgXFxfU0JfLlBDSTAuSVNB Xy5MTktDCmZvdW5kLT4JdmVuZG9yPTB4MTAxMSwgZGV2PTB4MDAwOSwgcmV2aWQ9MHgxMgoJYnVz PTEsIHNsb3Q9MTAsIGZ1bmM9MAoJY2xhc3M9MDItMDAtMDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9 MAoJY21kcmVnPTB4MDAwNywgc3RhdHJlZz0weDAyODAsIGNhY2hlbG5zej0wIChkd29yZHMpCgls YXR0aW1lcj0weDIwICg5NjAgbnMpLCBtaW5nbnQ9MHgwMCAoMCBucyksIG1heGxhdD0weDAwICgw IG5zKQoJaW50cGluPWEsIGlycT0xMQpkZTA6IDxEaWdpdGFsIDIxMTQwIEZhc3QgRXRoZXJuZXQ+ IHBvcnQgMHhjMDAwLTB4YzA3ZiBtZW0gMHhkNDAwMDAwMC0weGQ0MDAwMDdmIGlycSAxMSBhdCBk ZXZpY2UgMTAuMCBvbiBwY2kxCmRlMDogUmVzZXJ2ZWQgMHg4MCBieXRlcyBmb3IgcmlkIDB4MTAg dHlwZSA0IGF0IDB4YzAwMApkZTA6IFtHSUFOVC1MT0NLRURdCmRlMDogU01DIDkzMzJEU1QgMjEx NDAgWzEwLTEwME1iL3NdIHBhc3MgMS4yCmRlMDogZW5hYmxpbmcgMTBiYXNlVCBwb3J0CmRlMDog YnBmIGF0dGFjaGVkCmRlMDogRXRoZXJuZXQgYWRkcmVzczogMDA6MDA6YzA6MzY6YmQ6ZWUKZGUw OiBpZl9zdGFydCBydW5uaW5nIGRlZmVycmVkIGZvciBHaWFudAppc2FiMDogPFBDSS1JU0EgYnJp ZGdlPiBhdCBkZXZpY2UgMzEuMCBvbiBwY2kwCmlzYTA6IDxJU0EgYnVzPiBvbiBpc2FiMAphdGFw Y2kwOiA8SW50ZWwgSUNIIFVETUE2NiBjb250cm9sbGVyPiBwb3J0IDB4ZjAwMC0weGYwMGYsMHgz NzYsMHgxNzAtMHgxNzcsMHgzZjYsMHgxZjAtMHgxZjcgYXQgZGV2aWNlIDMxLjEgb24gcGNpMAph dGFwY2kwOiBSZXNlcnZlZCAweDEwIGJ5dGVzIGZvciByaWQgMHgyMCB0eXBlIDQgYXQgMHhmMDAw CmF0YTA6IGNoYW5uZWwgIzAgb24gYXRhcGNpMAphdGFwY2kwOiBSZXNlcnZlZCAweDggYnl0ZXMg Zm9yIHJpZCAweDEwIHR5cGUgNCBhdCAweDFmMAphdGFwY2kwOiBSZXNlcnZlZCAweDEgYnl0ZXMg Zm9yIHJpZCAweDE0IHR5cGUgNCBhdCAweDNmNgphdGEwOiByZXNldCB0cDEgbWFzaz0wMyBvc3Rh dDA9NTAgb3N0YXQxPTAwCmF0YTAtbWFzdGVyOiBzdGF0PTB4NTAgZXJyPTB4MDEgbHNiPTB4MDAg bXNiPTB4MDAKYXRhMC1zbGF2ZTogIHN0YXQ9MHgwMCBlcnI9MHgwMSBsc2I9MHgwMCBtc2I9MHgw MAphdGEwOiByZXNldCB0cDIgc3RhdDA9NTAgc3RhdDE9MDAgZGV2aWNlcz0weDE8QVRBX01BU1RF Uj4KYXRhMDogW01QU0FGRV0KYXRhMTogY2hhbm5lbCAjMSBvbiBhdGFwY2kwCmF0YXBjaTA6IFJl c2VydmVkIDB4OCBieXRlcyBmb3IgcmlkIDB4MTggdHlwZSA0IGF0IDB4MTcwCmF0YXBjaTA6IFJl c2VydmVkIDB4MSBieXRlcyBmb3IgcmlkIDB4MWMgdHlwZSA0IGF0IDB4Mzc2CmF0YTE6IHJlc2V0 IHRwMSBtYXNrPTAzIG9zdGF0MD01MCBvc3RhdDE9MDAKYXRhMS1tYXN0ZXI6IHN0YXQ9MHgwMCBl cnI9MHgwMSBsc2I9MHgxNCBtc2I9MHhlYgphdGExLXNsYXZlOiAgc3RhdD0weDAxIGVycj0weDAx IGxzYj0weDAxIG1zYj0weDAxCmF0YTE6IHJlc2V0IHRwMiBzdGF0MD0wMCBzdGF0MT0wMSBkZXZp Y2VzPTB4NDxBVEFQSV9NQVNURVI+CmF0YTE6IFtNUFNBRkVdCnVoY2kwOiA8SW50ZWwgODI4MDFB QSAoSUNIKSBVU0IgY29udHJvbGxlcj4gcG9ydCAweGQwMDAtMHhkMDFmIGlycSA5IGF0IGRldmlj ZSAzMS4yIG9uIHBjaTAKdWhjaTA6IFJlc2VydmVkIDB4MjAgYnl0ZXMgZm9yIHJpZCAweDIwIHR5 cGUgNCBhdCAweGQwMDAKdWhjaTA6IFtHSUFOVC1MT0NLRURdCnVzYjA6IDxJbnRlbCA4MjgwMUFB IChJQ0gpIFVTQiBjb250cm9sbGVyPiBvbiB1aGNpMAp1c2IwOiBVU0IgcmV2aXNpb24gMS4wCnVo dWIwOiBJbnRlbCBVSENJIHJvb3QgaHViLCBjbGFzcyA5LzAsIHJldiAxLjAwLzEuMDAsIGFkZHIg MQp1aHViMDogMiBwb3J0cyB3aXRoIDIgcmVtb3ZhYmxlLCBzZWxmIHBvd2VyZWQKYWNwaV90ejA6 IDxUaGVybWFsIFpvbmU+IG9uIGFjcGkwCmZkYzA6IDxmbG9wcHkgZHJpdmUgY29udHJvbGxlcj4g cG9ydCAweDNmNywweDNmMi0weDNmNSBpcnEgNiBkcnEgMiBvbiBhY3BpMApmZGMwOiBpY190eXBl IDkwIHBhcnRfaWQgODAKZmRjMDogW01QU0FGRV0KZmRjMDogW0ZBU1RdCmZkMDogPDE0NDAtS0Ig My41IiBkcml2ZT4gb24gZmRjMCBkcml2ZSAwCnNpbzA6IGlycSBtYXBzOiAweDIxIDB4MzEgMHgy MSAweDIxCnNpbzA6IDwxNjU1MEEtY29tcGF0aWJsZSBDT00gcG9ydD4gcG9ydCAweDNmOC0weDNm ZiBpcnEgNCBmbGFncyAweDEwIG9uIGFjcGkwCnNpbzA6IHR5cGUgMTY1NTBBCnNpbzE6IGlycSBt YXBzOiAweDIxIDB4MjkgMHgyMSAweDIxCnNpbzE6IDwxNjU1MEEtY29tcGF0aWJsZSBDT00gcG9y dD4gcG9ydCAweDJmOC0weDJmZiBpcnEgMyBvbiBhY3BpMApzaW8xOiB0eXBlIDE2NTUwQQp1bmtu b3duOiBub3QgcHJvYmVkIChkaXNhYmxlZCkKdW5rbm93bjogbm90IHByb2JlZCAoZGlzYWJsZWQp CnBwYzA6IHVzaW5nIGV4dGVuZGVkIEkvTyBwb3J0IHJhbmdlCnBwYzA6IEVDUCBTUFAgRUNQK0VQ UCBTUFAKcHBjMDogPEVDUCBwYXJhbGxlbCBwcmludGVyIHBvcnQ+IHBvcnQgMHg3NzgtMHg3N2Is MHgzNzgtMHgzN2YgaXJxIDcgZHJxIDMgb24gYWNwaTAKcHBjMDogU01DLWxpa2UgY2hpcHNldCAo RUNQL0VQUC9QUzIvTklCQkxFKSBpbiBDT01QQVRJQkxFIG1vZGUKcHBjMDogRklGTyB3aXRoIDE2 LzE2LzE2IGJ5dGVzIHRocmVzaG9sZApwcGJ1czA6IDxQYXJhbGxlbCBwb3J0IGJ1cz4gb24gcHBj MApwbGlwMDogPFBMSVAgbmV0d29yayBpbnRlcmZhY2U+IG9uIHBwYnVzMApwbGlwMDogYnBmIGF0 dGFjaGVkCmxwdDA6IDxQcmludGVyPiBvbiBwcGJ1czAKbHB0MDogSW50ZXJydXB0LWRyaXZlbiBw b3J0CnBwaTA6IDxQYXJhbGxlbCBJL08+IG9uIHBwYnVzMApwc21jcG5wMDogPFBTLzIgbW91c2Ug cG9ydD4gaXJxIDEyIG9uIGFjcGkwCmF0a2JkYzA6IDxLZXlib2FyZCBjb250cm9sbGVyIChpODA0 Mik+IHBvcnQgMHg2NCwweDYwIGlycSAxIG9uIGFjcGkwCmF0a2JkMDogPEFUIEtleWJvYXJkPiBp cnEgMSBvbiBhdGtiZGMwCmF0a2JkOiB0aGUgY3VycmVudCBrYmQgY29udHJvbGxlciBjb21tYW5k IGJ5dGUgMDA0NwphdGtiZDoga2V5Ym9hcmQgSUQgMHg0MWFiICgyKQprYmQwIGF0IGF0a2JkMApr YmQwOiBhdGtiZDAsIEFUIDEwMS8xMDIgKDIpLCBjb25maWc6MHgwLCBmbGFnczoweDNkMDAwMAph dGtiZDA6IFtHSUFOVC1MT0NLRURdCnBzbTA6IGN1cnJlbnQgY29tbWFuZCBieXRlOjAwNDcKcHNt MDogPFBTLzIgTW91c2U+IGlycSAxMiBvbiBhdGtiZGMwCnBzbTA6IFtHSUFOVC1MT0NLRURdCnBz bTA6IG1vZGVsIEludGVsbGlNb3VzZSwgZGV2aWNlIElEIDMtMDAsIDMgYnV0dG9ucwpwc20wOiBj b25maWc6MDAwMDAwMDAsIGZsYWdzOjAwMDAwMDA4LCBwYWNrZXQgc2l6ZTo0CnBzbTA6IHN5bmNt YXNrOjA4LCBzeW5jYml0czowMAp1bmtub3duOiBub3QgcHJvYmVkIChkaXNhYmxlZCkKdW5rbm93 bjogbm90IHByb2JlZCAoZGlzYWJsZWQpCnVua25vd246IG5vdCBwcm9iZWQgKGRpc2FibGVkKQp1 bmtub3duOiBub3QgcHJvYmVkIChkaXNhYmxlZCkKdW5rbm93bjogbm90IHByb2JlZCAoZGlzYWJs ZWQpCnVua25vd246IG5vdCBwcm9iZWQgKGRpc2FibGVkKQphdGE6IGF0YTAgYWxyZWFkeSBleGlz dHM7IHNraXBwaW5nIGl0CmF0YTogYXRhMSBhbHJlYWR5IGV4aXN0czsgc2tpcHBpbmcgaXQKYXRr YmRjOiBhdGtiZGMwIGFscmVhZHkgZXhpc3RzOyBza2lwcGluZyBpdApmZGM6IGZkYzAgYWxyZWFk eSBleGlzdHM7IHNraXBwaW5nIGl0CnBwYzogcHBjMCBhbHJlYWR5IGV4aXN0czsgc2tpcHBpbmcg aXQKc2lvOiBzaW8wIGFscmVhZHkgZXhpc3RzOyBza2lwcGluZyBpdApzaW86IHNpbzEgYWxyZWFk eSBleGlzdHM7IHNraXBwaW5nIGl0ClRyeWluZyBSZWFkX1BvcnQgYXQgMjAzClRyeWluZyBSZWFk X1BvcnQgYXQgMjQzClRyeWluZyBSZWFkX1BvcnQgYXQgMjgzClRyeWluZyBSZWFkX1BvcnQgYXQg MmMzClRyeWluZyBSZWFkX1BvcnQgYXQgMzAzClRyeWluZyBSZWFkX1BvcnQgYXQgMzQzClRyeWlu ZyBSZWFkX1BvcnQgYXQgMzgzClRyeWluZyBSZWFkX1BvcnQgYXQgM2MzCmV4X2lzYV9pZGVudGlm eSgpCnVua25vd246IHN0YXR1cyByZWcgdGVzdCBmYWlsZWQgZmYKdW5rbm93bjogc3RhdHVzIHJl ZyB0ZXN0IGZhaWxlZCBmZgp1bmtub3duOiBzdGF0dXMgcmVnIHRlc3QgZmFpbGVkIGZmCnVua25v d246IHN0YXR1cyByZWcgdGVzdCBmYWlsZWQgZmYKdW5rbm93bjogc3RhdHVzIHJlZyB0ZXN0IGZh aWxlZCBmZgp1bmtub3duOiBzdGF0dXMgcmVnIHRlc3QgZmFpbGVkIGZmCnNjOiBzYzAgYWxyZWFk eSBleGlzdHM7IHNraXBwaW5nIGl0CnZnYTogdmdhMCBhbHJlYWR5IGV4aXN0czsgc2tpcHBpbmcg aXQKaXNhX3Byb2JlX2NoaWxkcmVuOiBkaXNhYmxpbmcgUG5QIGRldmljZXMKaXNhX3Byb2JlX2No aWxkcmVuOiBwcm9iaW5nIG5vbi1QblAgZGV2aWNlcwpvcm0wOiA8SVNBIE9wdGlvbiBST00+IGF0 IGlvbWVtIDB4YzAwMDAtMHhjOWZmZiBvbiBpc2EwCnBtdGltZXIwIG9uIGlzYTAKYWR2MDogbm90 IHByb2JlZCAoZGlzYWJsZWQpCmFoYTA6IG5vdCBwcm9iZWQgKGRpc2FibGVkKQphaWMwOiBub3Qg cHJvYmVkIChkaXNhYmxlZCkKYnQwOiBub3QgcHJvYmVkIChkaXNhYmxlZCkKY3MwOiBub3QgcHJv YmVkIChkaXNhYmxlZCkKZWQwOiBub3QgcHJvYmVkIChkaXNhYmxlZCkKZmUwOiBub3QgcHJvYmVk IChkaXNhYmxlZCkKaWUwOiBub3QgcHJvYmVkIChkaXNhYmxlZCkKbG5jMDogbm90IHByb2JlZCAo ZGlzYWJsZWQpCnBjaWMwIGZhaWxlZCB0byBwcm9iZSBhdCBwb3J0IDB4M2UwIGlvbWVtIDB4ZDAw MDAgb24gaXNhMApwY2ljMTogbm90IHByb2JlZCAoZGlzYWJsZWQpCnNjMDogPFN5c3RlbSBjb25z b2xlPiBhdCBmbGFncyAweDEwMCBvbiBpc2EwCnNjMDogVkdBIDwxNiB2aXJ0dWFsIGNvbnNvbGVz LCBmbGFncz0weDMwMD4Kc2MwOiBmYjAsIGtiZDAsIHRlcm1pbmFsIGVtdWxhdG9yOiBzYyAoc3lz Y29ucyB0ZXJtaW5hbCkKc2lvMjogbm90IHByb2JlZCAoZGlzYWJsZWQpCnNpbzM6IG5vdCBwcm9i ZWQgKGRpc2FibGVkKQpzbjA6IG5vdCBwcm9iZWQgKGRpc2FibGVkKQp2Z2EwOiA8R2VuZXJpYyBJ U0EgVkdBPiBhdCBwb3J0IDB4M2MwLTB4M2RmIGlvbWVtIDB4YTAwMDAtMHhiZmZmZiBvbiBpc2Ew CmZiMDogdmdhMCwgdmdhLCB0eXBlOlZHQSAoNSksIGZsYWdzOjB4NzAwN2YKZmIwOiBwb3J0OjB4 M2MwLTB4M2RmLCBjcnRjOjB4M2Q0LCBtZW06MHhhMDAwMCAweDIwMDAwCmZiMDogaW5pdCBtb2Rl OjI0LCBiaW9zIG1vZGU6MywgY3VycmVudCBtb2RlOjI0CmZiMDogd2luZG93OjB4YzAwYjgwMDAg c2l6ZTozMmsgZ3JhbjozMmssIGJ1ZjowIHNpemU6MzJrClZHQSBwYXJhbWV0ZXJzIHVwb24gcG93 ZXItdXAKNTAgMTggMTAgMDAgMDAgMDAgMDMgMDAgMDIgNjcgNWYgNGYgNTAgODIgNTUgODEgCmJm IDFmIDAwIDRmIDBlIDBmIDAwIDAwIDA3IDgwIDljIDhlIDhmIDI4IDFmIDk2IApiOSBhMyBmZiAw MCAwMSAwMiAwMyAwNCAwNSAxNCAwNyAzOCAzOSAzYSAzYiAzYyAKM2QgM2UgM2YgMGMgMDAgMGYg MDggMDAgMDAgMDAgMDAgMDAgMTAgMGUgMDAgZmYgClZHQSBwYXJhbWV0ZXJzIGluIEJJT1MgZm9y IG1vZGUgMjQKNTAgMTggMTAgMDAgMTAgMDAgMDMgMDAgMDIgNjcgNWYgNGYgNTAgODIgNTUgODEg CmJmIDFmIDAwIDRmIDBkIDBlIDAwIDAwIDAwIDAwIDljIDhlIDhmIDI4IDFmIDk2IApiOSBhMyBm ZiAwMCAwMSAwMiAwMyAwNCAwNSAxNCAwNyAzOCAzOSAzYSAzYiAzYyAKM2QgM2UgM2YgMGMgMDAg MGYgMDggMDAgMDAgMDAgMDAgMDAgMTAgMGUgMDAgZmYgCkVHQS9WR0EgcGFyYW1ldGVycyB0byBi ZSB1c2VkIGZvciBtb2RlIDI0CjUwIDE4IDEwIDAwIDEwIDAwIDAzIDAwIDAyIDY3IDVmIDRmIDUw IDgyIDU1IDgxIApiZiAxZiAwMCA0ZiAwZCAwZSAwMCAwMCAwMCAwMCA5YyA4ZSA4ZiAyOCAxZiA5 NiAKYjkgYTMgZmYgMDAgMDEgMDIgMDMgMDQgMDUgMTQgMDcgMzggMzkgM2EgM2IgM2MgCjNkIDNl IDNmIDBjIDAwIDBmIDA4IDAwIDAwIDAwIDAwIDAwIDEwIDBlIDAwIGZmIAp2dDA6IG5vdCBwcm9i ZWQgKGRpc2FibGVkKQppc2FfcHJvYmVfY2hpbGRyZW46IHByb2JpbmcgUG5QIGRldmljZXMKRGV2 aWNlIGNvbmZpZ3VyYXRpb24gZmluaXNoZWQuCnByb2NmcyByZWdpc3RlcmVkClRpbWVjb3VudGVy ICJUU0MiIGZyZXF1ZW5jeSA2MDEzNjcwMDcgSHogcXVhbGl0eSA4MDAKVGltZWNvdW50ZXJzIHRp Y2sgZXZlcnkgMTAuMDAwIG1zZWMKbG8wOiBicGYgYXR0YWNoZWQKYXRhMC1tYXN0ZXI6IHBpbz0w eDBjIHdkbWE9MHgyMiB1ZG1hPTB4NDQgY2FibGU9ODBwaW4KYXRhMC1tYXN0ZXI6IHNldHRpbmcg UElPNCBvbiBJbnRlbCBJQ0ggY2hpcAphdGEwLW1hc3Rlcjogc2V0dGluZyBVRE1BNjYgb24gSW50 ZWwgSUNIIGNoaXAKYWQwOiA8RlVKSVRTVSBNUEQzMTA4QVQvREQtMDMtNDc+IEFUQS00IGRpc2sg YXQgYXRhMC1tYXN0ZXIKYWQwOiAxMDMwME1CICgyMTA5NTQyNCBzZWN0b3JzKSwgMjA5MjggQywg MTYgSCwgNjMgUywgNTEyIEIKYWQwOiAxNiBzZWNzL2ludCwgMSBkZXB0aCBxdWV1ZSwgVURNQTY2 CmFyOiBGcmVlQlNEIGNoZWNrMSBmYWlsZWQKYXRhMS1tYXN0ZXI6IHBpbz0weDBiIHdkbWE9MHhm ZmZmZmZmZiB1ZG1hPTB4ZmZmZmZmZmYgY2FibGU9NDBwaW4KYXRhMS1tYXN0ZXI6IHNldHRpbmcg UElPMyBvbiBJbnRlbCBJQ0ggY2hpcAphY2QwOiA8TUFUU0hJVEEgQ1ItNTgzL0FTMTA+IENEUk9N IGRyaXZlIGF0IGF0YTEgYXMgbWFzdGVyCmFjZDA6IHJlYWQgMTM3OEtCL3MgKDEzNzhLQi9zKSwg MTI4S0IgYnVmZmVyLCBQSU8zCmFjZDA6IFJlYWRzOiBDRFIsIENEREEKYWNkMDogV3JpdGVzOgph Y2QwOiBBdWRpbzogcGxheSwgMjU2IHZvbHVtZSBsZXZlbHMKYWNkMDogTWVjaGFuaXNtOiBlamVj dGFibGUgdHJheSwgdW5sb2NrZWQKYWNkMDogTWVkaXVtOiBuby9ibGFuayBkaXNjCkdFT006IG5l dyBkaXNrIGFkMApbMF0gZjo4MCB0eXA6MTY1IHMoQ0hTKTowLzAvMSBlKENIUyk6MTAyMy8zMi82 MyBzOjAgbDoyMTA5NTQyNApbMV0gZjowMCB0eXA6MCBzKENIUyk6MC8wLzAgZShDSFMpOjAvMC8w IHM6MCBsOjAKWzJdIGY6MDAgdHlwOjAgcyhDSFMpOjAvMC8wIGUoQ0hTKTowLzAvMCBzOjAgbDow ClszXSBmOjAwIHR5cDowIHMoQ0hTKTowLzAvMCBlKENIUyk6MC8wLzAgczowIGw6MApHRU9NOiBD b25maWd1cmUgYWQwczEsIHN0YXJ0IDAgbGVuZ3RoIDEwODAwODU3MDg4IGVuZCAxMDgwMDg1NzA4 NwpHRU9NOiBDb25maWd1cmUgYWQwYSwgc3RhcnQgMzgzNzc4ODE2IGxlbmd0aCAxMDQxNzA3ODI3 MiBlbmQgMTA4MDA4NTcwODcKR0VPTTogQ29uZmlndXJlIGFkMGIsIHN0YXJ0IDAgbGVuZ3RoIDM4 Mzc3ODgxNiBlbmQgMzgzNzc4ODE1CkdFT006IENvbmZpZ3VyZSBhZDBjLCBzdGFydCAwIGxlbmd0 aCAxMDgwMDg1NzA4OCBlbmQgMTA4MDA4NTcwODcKR0VPTTogQ29uZmlndXJlIGFkMHMxYSwgc3Rh cnQgMzgzNzc4ODE2IGxlbmd0aCAxMDQxNzA3ODI3MiBlbmQgMTA4MDA4NTcwODcKR0VPTTogQ29u ZmlndXJlIGFkMHMxYiwgc3RhcnQgMCBsZW5ndGggMzgzNzc4ODE2IGVuZCAzODM3Nzg4MTUKR0VP TTogQ29uZmlndXJlIGFkMHMxYywgc3RhcnQgMCBsZW5ndGggMTA4MDA4NTcwODggZW5kIDEwODAw ODU3MDg3ClswXSBmOjgwIHR5cDoxNjUgcyhDSFMpOjAvMC8xIGUoQ0hTKToxMDIzLzMyLzYzIHM6 MCBsOjIxMDk1NDI0ClsxXSBmOjAwIHR5cDowIHMoQ0hTKTowLzAvMCBlKENIUyk6MC8wLzAgczow IGw6MApbMl0gZjowMCB0eXA6MCBzKENIUyk6MC8wLzAgZShDSFMpOjAvMC8wIHM6MCBsOjAKWzNd IGY6MDAgdHlwOjAgcyhDSFMpOjAvMC8wIGUoQ0hTKTowLzAvMCBzOjAgbDowCkdFT006IENvbmZp Z3VyZSBhZDBiczEsIHN0YXJ0IDAgbGVuZ3RoIDEwODAwODU3MDg4IGVuZCAxMDgwMDg1NzA4Nwpb MF0gZjo4MCB0eXA6MTY1IHMoQ0hTKTowLzAvMSBlKENIUyk6MTAyMy8zMi82MyBzOjAgbDoyMTA5 NTQyNApbMV0gZjowMCB0eXA6MCBzKENIUyk6MC8wLzAgZShDSFMpOjAvMC8wIHM6MCBsOjAKWzJd IGY6MDAgdHlwOjAgcyhDSFMpOjAvMC8wIGUoQ0hTKTowLzAvMCBzOjAgbDowClszXSBmOjAwIHR5 cDowIHMoQ0hTKTowLzAvMCBlKENIUyk6MC8wLzAgczowIGw6MApHRU9NOiBDb25maWd1cmUgYWQw Y3MxLCBzdGFydCAwIGxlbmd0aCAxMDgwMDg1NzA4OCBlbmQgMTA4MDA4NTcwODcKTW91bnRpbmcg cm9vdCBmcm9tIHVmczovZGV2L2FkMHMxYQpzdGFydF9pbml0OiB0cnlpbmcgL3NiaW4vaW5pdApM aW51eCBFTEYgZXhlYyBoYW5kbGVyIGluc3RhbGxlZAo= ------=_20050427080054_65826-- From owner-freebsd-current@FreeBSD.ORG Wed Apr 27 15:12: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 0BF1416A4CF for ; Wed, 27 Apr 2005 15:12:06 +0000 (GMT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id A63C043D2F for ; Wed, 27 Apr 2005 15:12:05 +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 j3RFC5em000990; Wed, 27 Apr 2005 08:12:05 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id j3RFC46l000989; Wed, 27 Apr 2005 08:12:04 -0700 Date: Wed, 27 Apr 2005 08:12:04 -0700 From: Brooks Davis To: Brian Candler Message-ID: <20050427151204.GB32309@odin.ac.hmc.edu> References: <20050427090157.GA85275@uk.tiscali.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="98e8jtXdkpgskNou" Content-Disposition: inline In-Reply-To: <20050427090157.GA85275@uk.tiscali.com> 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@freebsd.org Subject: Re: ISDN kernel build fials X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 27 Apr 2005 15:12:06 -0000 --98e8jtXdkpgskNou Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Apr 27, 2005 at 10:01:57AM +0100, Brian Candler wrote: > FYI, building -CURRENT as of yesterday, with NO_IPFILTER=3Dyes in make.co= nf >=20 > make buildworld was successful. make buildkernel KERNCONF=3DFOO gave: >=20 > cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototy= pes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-ex= tensions -std=3Dc99 -g -nostdinc -I- -I. -I/export/src/5.3-RELEASE/usr/src= /sys -I/export/src/5.3-RELEASE/usr/src/sys/contrib/dev/acpica -I/export/src= /5.3-RELEASE/usr/src/sys/contrib/altq -I/export/src/5.3-RELEASE/usr/src/sys= /contrib/ipfilter -I/export/src/5.3-RELEASE/usr/src/sys/contrib/pf -I/expor= t/src/5.3-RELEASE/usr/src/sys/contrib/dev/ath -I/export/src/5.3-RELEASE/usr= /src/sys/contrib/dev/ath/freebsd -I/export/src/5.3-RELEASE/usr/src/sys/cont= rib/ngatm -I/export/src/5.3-RELEASE/usr/src/sys/dev/twa -D_KERNEL -include = opt_global.h -fno-common -finline-limit=3D8000 --param inline-unit-growth= =3D100 --param large-function-growth=3D1000 -mno-align-long-strings -mpref= erred-stack-boundary=3D2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -ffreestan= ding -Werror /export/src/5.3-RELEASE/usr/src/sys/i4b/driver/i4b_trace.c > /export/src/5.3-RELEASE/usr/src/sys/i4b/driver/i4b_trace.c:59: error: `NI= 4BTRC' undeclared here (not in a function) > /export/src/5.3-RELEASE/usr/src/sys/i4b/driver/i4b_trace.c:59: error: sto= rage size of `trace_queue' isn't known > /export/src/5.3-RELEASE/usr/src/sys/i4b/driver/i4b_trace.c:61: error: sto= rage size of `device_state' isn't known > /export/src/5.3-RELEASE/usr/src/sys/i4b/driver/i4b_trace.c:59: warning: '= trace_queue' defined but not used > /export/src/5.3-RELEASE/usr/src/sys/i4b/driver/i4b_trace.c:61: warning: '= device_state' defined but not used > *** Error code 1 >=20 > Stop in /usr/obj/export/src/5.3-RELEASE/usr/src/sys/FOO. > *** Error code 1 >=20 > Stop in /export/src/5.3-RELEASE/usr/src. > *** Error code 1 >=20 > Stop in /export/src/5.3-RELEASE/usr/src. >=20 > The FOO kernel config is given below, as a diff against current's GENERIC. > More or less the same config had worked on 5.3-RELEASE, except I had coun= ts > for some of the devices, e.g. >=20 > device "i4btrc" 4 >=20 > which I had to change to >=20 > device "i4btrc" >=20 > to get config to work with -CURRENT. You want to copy the examples from NOTES that looks like: device i4btrc options NI4BTRC=3D4 When counts were removed from the config file, I4B and vcoda where the only pieces of code that still used them and I4B was to hard to fix given that no one seems to care enough to actually maintain it. Thus the counts were made into options. -- 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 --98e8jtXdkpgskNou Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFCb6vEXY6L6fI4GtQRAsOAAJ0dMQPL+YmHBJO+SZJ4BnT6xJbOOwCfRiYn SyAcpFEpy0D09y40JnZS1ZM= =wpa2 -----END PGP SIGNATURE----- --98e8jtXdkpgskNou-- From owner-freebsd-current@FreeBSD.ORG Wed Apr 27 15:50: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 16B2716A4CE for ; Wed, 27 Apr 2005 15:50:13 +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 8CB0F43D67 for ; Wed, 27 Apr 2005 15:50:12 +0000 (GMT) (envelope-from Alexander@Leidinger.net) Received: from fwd24.aul.t-online.de by mailout11.sul.t-online.com with smtp id 1DQoni-00077n-02; Wed, 27 Apr 2005 17:50:10 +0200 Received: from Andro-Beta.Leidinger.net (rfeyo0ZSQe0O04wc4zwFfmGi7-zwD6Wt9--9Fmiw2tuu83ugNSyqZ6@[84.128.202.167]) by fwd24.sul.t-online.de with esmtp id 1DQonR-1OC0Su0; Wed, 27 Apr 2005 17:49:53 +0200 Received: from localhost (localhost [127.0.0.1])j3RFnsjO097512; Wed, 27 Apr 2005 17:49:54 +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, 27 Apr 2005 17:49:54 +0200 Message-ID: <20050427174954.4czjrpbq8gw8csos@netchild.homeip.net> X-Priority: 3 (Normal) Date: Wed, 27 Apr 2005 17:49:54 +0200 From: Alexander Leidinger To: /dev/null References: <20050425155955.89494.qmail@web51608.mail.yahoo.com> <20050427160039.udg3gvwzi84840s4@netchild.homeip.net> <61128.216.177.243.42.1114614472.localmail@webmail.dnswatch.com> In-Reply-To: <61128.216.177.243.42.1114614472.localmail@webmail.dnswatch.com> 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: rfeyo0ZSQe0O04wc4zwFfmGi7-zwD6Wt9--9Fmiw2tuu83ugNSyqZ6@t-dialin.net X-TOI-MSGID: 9f3258e9-d37f-40cb-998b-624d23b6e016 cc: freebsd-current@freebsd.org Subject: Re: FreeBSD 6 is coming too fast X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 27 Apr 2005 15:50:13 -0000 /dev/null wrote: >>> - I wanted to use XFree86-4 and building it on my own and figuring out >>> the >>> library mess later is not an option. >> >> We still have the XFree86-4 port, and AFAIK it still works (everything >> else >> is a bug). You just have to set a variable in make.conf to make it the >> default. > > Isn't this and most of the rest of what you mention here always mentioned > in: /usr/src/UPDATING and /usr/ports/UPDATING which, in turn, is mentioned > in many places in the (online)handbook? The UPDATING content isn't mentioned in the handbook AFAIK, but yes, the switch to the other X11 implementation is mentioned in UPDATING and I think it's mentioned in the handbook. Bye, Alexander. -- http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 Everyone complains of his memory, no one of his judgement. From owner-freebsd-current@FreeBSD.ORG Wed Apr 27 17:50: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 4F07616A4CF; Wed, 27 Apr 2005 17:50:06 +0000 (GMT) Received: from bgo1smout1.broadpark.no (bgo1smout1.broadpark.no [217.13.4.94]) by mx1.FreeBSD.org (Postfix) with ESMTP id B97D143D5D; Wed, 27 Apr 2005 17:50:05 +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 <0IFM00MSH99WP1C0@bgo1smout1.broadpark.no>; Wed, 27 Apr 2005 19:44:20 +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 <0IFM003X89L36B30@bgo1sminn1.broadpark.no>; Wed, 27 Apr 2005 19:51:03 +0200 (CEST) Received: by dsa.des.no (Pony Express, from userid 666) id B62F645157; Wed, 27 Apr 2005 19:50:03 +0200 (CEST) Received: from xps.des.no (xps.des.no [10.0.0.12]) by dsa.des.no (Pony Express) with ESMTP id BCFE945171; Wed, 27 Apr 2005 19:49:57 +0200 (CEST) Received: by xps.des.no (Postfix, from userid 1001) id AF41033C09; Wed, 27 Apr 2005 19:49:57 +0200 (CEST) Date: Wed, 27 Apr 2005 19:49:57 +0200 From: des@des.no (=?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?=) In-reply-to: <20050425160146.4795fe1b.flynn@energyhq.es.eu.org> To: Miguel Mendez Message-id: <86sm1c154q.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: <20050424175543.71041.qmail@web51805.mail.yahoo.com> <20050424151517.O68772@lexi.siliconlandmark.com> <3822.216.177.243.38.1114385370.localmail@webmail.dnswatch.com> <20050425000459.GA28667@xor.obsecurity.org> <6.2.1.2.0.20050424204611.072105a0@64.7.153.2> <20050425010242.GA44110@xor.obsecurity.org> <6.2.1.2.0.20050424210422.03d22990@64.7.153.2> <20050425014453.GA59981@xor.obsecurity.org> <426C6B1D.3040704@elischer.org> <20050425061459.GA33247@xor.obsecurity.org> <20050425062106.GB91852@voodoo.oberon.net> <426CF3DE.4000409@samsco.org> <20050425160146.4795fe1b.flynn@energyhq.es.eu.org> 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: current@freebsd.org cc: mike@sentex.net cc: freebsd-current@freebsd.org cc: julian@elischer.org cc: krion@voodoo.oberon.net cc: kris@obsecurity.org Subject: Re: FreeBSD 6 is coming too fast X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 27 Apr 2005 17:50:06 -0000 Miguel Mendez writes: > Scott Long wrote: > > What about the deprecated language constructs in 4.0? > According to http://gcc.gnu.org/gcc-4.0/changes.html, some of the > deprecated constructs are not even valid C [...] *none* of the deprecated constructs are valid C. This does not mean they aren't in widespread use. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Wed Apr 27 17:50: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 4F07616A4CF; Wed, 27 Apr 2005 17:50:06 +0000 (GMT) Received: from bgo1smout1.broadpark.no (bgo1smout1.broadpark.no [217.13.4.94]) by mx1.FreeBSD.org (Postfix) with ESMTP id B97D143D5D; Wed, 27 Apr 2005 17:50:05 +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 <0IFM00MSH99WP1C0@bgo1smout1.broadpark.no>; Wed, 27 Apr 2005 19:44:20 +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 <0IFM003X89L36B30@bgo1sminn1.broadpark.no>; Wed, 27 Apr 2005 19:51:03 +0200 (CEST) Received: by dsa.des.no (Pony Express, from userid 666) id B62F645157; Wed, 27 Apr 2005 19:50:03 +0200 (CEST) Received: from xps.des.no (xps.des.no [10.0.0.12]) by dsa.des.no (Pony Express) with ESMTP id BCFE945171; Wed, 27 Apr 2005 19:49:57 +0200 (CEST) Received: by xps.des.no (Postfix, from userid 1001) id AF41033C09; Wed, 27 Apr 2005 19:49:57 +0200 (CEST) Date: Wed, 27 Apr 2005 19:49:57 +0200 From: des@des.no (=?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?=) In-reply-to: <20050425160146.4795fe1b.flynn@energyhq.es.eu.org> To: Miguel Mendez Message-id: <86sm1c154q.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: <20050424175543.71041.qmail@web51805.mail.yahoo.com> <20050424151517.O68772@lexi.siliconlandmark.com> <3822.216.177.243.38.1114385370.localmail@webmail.dnswatch.com> <20050425000459.GA28667@xor.obsecurity.org> <6.2.1.2.0.20050424204611.072105a0@64.7.153.2> <20050425010242.GA44110@xor.obsecurity.org> <6.2.1.2.0.20050424210422.03d22990@64.7.153.2> <20050425014453.GA59981@xor.obsecurity.org> <426C6B1D.3040704@elischer.org> <20050425061459.GA33247@xor.obsecurity.org> <20050425062106.GB91852@voodoo.oberon.net> <426CF3DE.4000409@samsco.org> <20050425160146.4795fe1b.flynn@energyhq.es.eu.org> 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: current@freebsd.org cc: mike@sentex.net cc: freebsd-current@freebsd.org cc: julian@elischer.org cc: krion@voodoo.oberon.net cc: kris@obsecurity.org Subject: Re: FreeBSD 6 is coming too fast X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 27 Apr 2005 17:50:06 -0000 Miguel Mendez writes: > Scott Long wrote: > > What about the deprecated language constructs in 4.0? > According to http://gcc.gnu.org/gcc-4.0/changes.html, some of the > deprecated constructs are not even valid C [...] *none* of the deprecated constructs are valid C. This does not mean they aren't in widespread use. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Wed Apr 27 17:50: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 3BEBC16A4D0 for ; Wed, 27 Apr 2005 17:50:46 +0000 (GMT) Received: from smtp101.rog.mail.re2.yahoo.com (smtp101.rog.mail.re2.yahoo.com [206.190.36.79]) by mx1.FreeBSD.org (Postfix) with SMTP id 8F98843D53 for ; Wed, 27 Apr 2005 17:50:45 +0000 (GMT) (envelope-from mikej@rogers.com) Received: from unknown (HELO 172.16.0.1) (mikej@69.193.222.195 with login) by smtp101.rog.mail.re2.yahoo.com with SMTP; 27 Apr 2005 17:50:44 -0000 Received: from 172.16.0.199 (SquirrelMail authenticated user mikej) by 172.16.0.1 with HTTP; Wed, 27 Apr 2005 13:50:39 -0400 (EDT) Message-ID: <1072.172.16.0.199.1114624239.squirrel@172.16.0.1> In-Reply-To: <51866.216.177.243.42.1114613062.localmail@webmail.dnswatch.com> References: <57436.216.177.243.42.1114582155.localmail@webmail.dnswatch.com> <426F8F21.1010100@gamersimpact.com> <51866.216.177.243.42.1114613062.localmail@webmail.dnswatch.com> Date: Wed, 27 Apr 2005 13:50:39 -0400 (EDT) From: "Mike Jakubik" To: "/dev/null" User-Agent: SquirrelMail/1.5.1 [CVS] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit cc: Ryan Sommers cc: freebsd-current@freebsd.org Subject: Re: boot banner project X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 27 Apr 2005 17:50:46 -0000 On Wed, April 27, 2005 10:44 am, /dev/null said: > With 30+ servers, I do alot of that as well. But it has always bothered > me for some reason that Linux has always had their flashy boot screens. > While FBSD has not. It was sort of like Linux thumbing it's nose at me. > So, I felt like I'd like to start contributing to FBSD and this seemed > like an easy place to start. Later, something more advanced (and useful). > > Thanks for the link! It should prove very useful. Personally, i prefer the current fbsd boot process over the linux flashy ones. Its useless bloat, that wont impress any serious audience. But if thats what you want, you can always use splash. From owner-freebsd-current@FreeBSD.ORG Wed Apr 27 18:29: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 31EBD16A4CE for ; Wed, 27 Apr 2005 18:29:36 +0000 (GMT) Received: from mailserv1.neuroflux.com (ns2.neuroflux.com [204.228.228.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id C917443D58 for ; Wed, 27 Apr 2005 18:29:35 +0000 (GMT) (envelope-from ryans@gamersimpact.com) Received: (qmail 18934 invoked by uid 89); 27 Apr 2005 18:30:01 -0000 Received: from unknown (HELO www2.neuroflux.com) (127.0.0.1) by localhost with SMTP; 27 Apr 2005 18:30:01 -0000 Received: from 66.166.104.222 (SquirrelMail authenticated user ryans@gamersimpact.com); by www2.neuroflux.com with HTTP; Wed, 27 Apr 2005 12:30:01 -0600 (MDT) Message-ID: <1076.66.166.104.222.1114626601.squirrel@66.166.104.222> In-Reply-To: <1072.172.16.0.199.1114624239.squirrel@172.16.0.1> References: <57436.216.177.243.42.1114582155.localmail@webmail.dnswatch.com> <426F8F21.1010100@gamersimpact.com> <51866.216.177.243.42.1114613062.localmail@webmail.dnswatch.com> <1072.172.16.0.199.1114624239.squirrel@172.16.0.1> Date: Wed, 27 Apr 2005 12:30:01 -0600 (MDT) From: "Ryan Sommers" To: "Mike Jakubik" User-Agent: SquirrelMail/1.4.3a X-Mailer: SquirrelMail/1.4.3a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal cc: Ryan Sommers cc: /dev/null cc: freebsd-current@freebsd.org Subject: Re: boot banner project X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 27 Apr 2005 18:29:36 -0000 Mike Jakubik said: >> Thanks for the link! It should prove very useful. > > Personally, i prefer the current fbsd boot process over the linux flashy > ones. Its useless bloat, that wont impress any serious audience. But if > thats what you want, you can always use splash. Those are my sentiments exactly. I viewed it as fluff. It's like having 5 cup holders in a 2 seat car that can't go over 50mph, downhill. Anytime I've seen the colorful graphics Linux boot it makes me scoff. To me it just looks like developers time that could have been better spent elsewhere. But, it's their time they can spend it how they want. I'd rather them add frivilous features to an open source package than charge outrageous prices for them. However, I DO think FreeBSD needs some more fluff in certain areas. While I don't want to see FreeBSD turn into a desktop OS that grandma can use, I do think the desktop market is a large niche for Open Source operating systems that need a little fluff and eye candy to turn heads. It's when those heads turn that corporate dollars flow toward the real development. Which, no matter what you say, without money open source developers would be living in boxes, someone has to pay the bill sometime. -- Ryan Sommers ryans@gamersimpact.com From owner-freebsd-current@FreeBSD.ORG Wed Apr 27 18:45: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 76F7616A4CE for ; Wed, 27 Apr 2005 18:45:33 +0000 (GMT) Received: from mail28.sea5.speakeasy.net (mail28.sea5.speakeasy.net [69.17.117.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id CB0D943D62 for ; Wed, 27 Apr 2005 18:45:32 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 3308 invoked from network); 27 Apr 2005 18:45:32 -0000 Received: from server.baldwin.cx ([216.27.160.63]) (envelope-sender )AES256-SHA encrypted SMTP for ; 27 Apr 2005 18:45:32 -0000 Received: from [10.50.41.242] (gw1.twc.weather.com [216.133.140.1]) (authenticated bits=0) by server.baldwin.cx (8.13.1/8.13.1) with ESMTP id j3RIiqae044824; Wed, 27 Apr 2005 14:45:26 -0400 (EDT) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: freebsd-current@FreeBSD.org Date: Wed, 27 Apr 2005 13:49:23 -0400 User-Agent: KMail/1.8 References: <20050414103154.GA11341@laptop.santcroos.net> <5e7c3d2084ff2460d6e48786defc8f33@xcllnt.net> <20050415173627.GQ4842@dan.emsphone.com> In-Reply-To: <20050415173627.GQ4842@dan.emsphone.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200504271349.24843.jhb@FreeBSD.org> X-Spam-Status: No, score=-101.7 required=4.2 tests=ALL_TRUSTED, SUBJ_HAS_UNIQ_ID,USER_IN_WHITELIST autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on server.baldwin.cx cc: freebsd-acpi@FreeBSD.org cc: Dan Nelson 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: Wed, 27 Apr 2005 18:45:33 -0000 On Friday 15 April 2005 01:36 pm, Dan Nelson wrote: > 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. Current doesn't use that version of the pci_link code anymore, so you should only see these delays on RELENG_5 now. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Wed Apr 27 18:45: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 8C6E116A4EF for ; Wed, 27 Apr 2005 18:45:41 +0000 (GMT) Received: from mail23.sea5.speakeasy.net (mail23.sea5.speakeasy.net [69.17.117.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4ED7143D70 for ; Wed, 27 Apr 2005 18:45:40 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 30827 invoked from network); 27 Apr 2005 18:45:40 -0000 Received: from server.baldwin.cx ([216.27.160.63]) (envelope-sender )AES256-SHA encrypted SMTP for ; 27 Apr 2005 18:45:40 -0000 Received: from [10.50.41.242] (gw1.twc.weather.com [216.133.140.1]) (authenticated bits=0) by server.baldwin.cx (8.13.1/8.13.1) with ESMTP id j3RIiqaf044824; Wed, 27 Apr 2005 14:45:31 -0400 (EDT) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: freebsd-current@FreeBSD.org Date: Wed, 27 Apr 2005 14:04:08 -0400 User-Agent: KMail/1.8 References: <200504191530.j3JFUvWD030545@energistic.com> <20050419165227.GA86651@energistic.com> <20050420005744.Y64858@lexi.siliconlandmark.com> In-Reply-To: <20050420005744.Y64858@lexi.siliconlandmark.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200504271404.10021.jhb@FreeBSD.org> X-Spam-Status: No, score=-102.8 required=4.2 tests=ALL_TRUSTED, USER_IN_WHITELIST autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on server.baldwin.cx Subject: Re: kernel.old not used any longer? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 27 Apr 2005 18:45:41 -0000 On Wednesday 20 April 2005 01:02 am, Andre Guibert de Bruet wrote: > On Tue, 19 Apr 2005, Steve Ames wrote: > > Hrm. Almost the same as you. On mine that first comparison is actually > > "!= //boot/kernel". Likely because I have "DESTDIR?=/" in /etc/make.conf. > > > > Hrm. Suddenly all makes sense. I defined DESTDIR so that 'make world' > > would continue to work normally (instead of doing > > buildworld/installworld) and that probably happened around August '04. > > > > So I guess if I get rid of DESTDIR and start doing > > buildworld/installworld then I get kernel.old functionality again... > > however this tastes like a bug to me. Perhaps that comparison should be: > > > > "!= ${DESTIR}/boot/kernel" ?? > > This is not a bug. You are looking for the functionality that is offered > by HISTORICAL_MAKE_WORLD. This isn't part of make world. I do think he has found a bug. ru@ is the person to ask. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Wed Apr 27 18:45: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 3452F16A4CE for ; Wed, 27 Apr 2005 18:45:52 +0000 (GMT) Received: from mail25.sea5.speakeasy.net (mail25.sea5.speakeasy.net [69.17.117.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id C990B43D5F for ; Wed, 27 Apr 2005 18:45:51 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 31847 invoked from network); 27 Apr 2005 18:45:51 -0000 Received: from server.baldwin.cx ([216.27.160.63]) (envelope-sender )AES256-SHA encrypted SMTP for ; 27 Apr 2005 18:45:50 -0000 Received: from [10.50.41.242] (gw1.twc.weather.com [216.133.140.1]) (authenticated bits=0) by server.baldwin.cx (8.13.1/8.13.1) with ESMTP id j3RIiqag044824; Wed, 27 Apr 2005 14:45:38 -0400 (EDT) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: freebsd-current@FreeBSD.org Date: Wed, 27 Apr 2005 14:10:00 -0400 User-Agent: KMail/1.8 References: <1114052573.1075.10.camel@dirk.no.domain> <20050422200102.G10333@carver.gumbysoft.com> <4269C309.30702@freebsd.org> In-Reply-To: <4269C309.30702@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200504271410.02151.jhb@FreeBSD.org> X-Spam-Status: No, score=-102.8 required=4.2 tests=ALL_TRUSTED, USER_IN_WHITELIST autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on server.baldwin.cx cc: David Xu cc: Sam Lawrance Subject: Re: kern/78474 for 5.4? (kernel stack swapout problem 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: Wed, 27 Apr 2005 18:45:52 -0000 On Friday 22 April 2005 11:37 pm, David Xu wrote: > Doug White wrote: > >On Thu, 21 Apr 2005, David Xu wrote: > >>Sam Lawrance wrote: > >>>Will this problem: > >>> > >>>Swapped out procs not brought in immediately after child exits > >>>http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/78474 > >>> > >>>be dealt with for the release of 5.4? > >>> > >>>Perhaps I'm the only FreeBSD user with swapped out processes ;-) > >>> > >>>-Sam > >> > >>I have noticed that current spinlock implementation no longer means that > >>CPU must be in critical region (critical_enter is called), even previous > >>hack TDP_WAKEPROC0 is no longer correct, :(, I think it is the time to > >>disable swapout. > > > >I'm sorry, I can't parse your double negative. On -CURRENT critical > >sections (entered with critical_enter()) no longer disable interrupts, but > >do inhibit preemption. But spinlocks still do critical_enter() (see > >spinlock_enter()). > > I will commit the patch provided in the PR, it should work. I am just > worrying > TDP_WAKEPROC0 will not work if spinlock does not entering critical region. Read what Doug wrote. spinlock_enter() still calls critical_enter(), so all spin locks still contain critical sections. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Wed Apr 27 18:51: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 2692F16A4CE for ; Wed, 27 Apr 2005 18:51:43 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9175E43D62 for ; Wed, 27 Apr 2005 18:51: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.3/8.13.3) with ESMTP id j3RItxKI018476; Wed, 27 Apr 2005 12:56:00 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <426FDE69.8090909@samsco.org> Date: Wed, 27 Apr 2005 12:48:09 -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: /dev/null References: <57436.216.177.243.42.1114582155.localmail@webmail.dnswatch.com> In-Reply-To: <57436.216.177.243.42.1114582155.localmail@webmail.dnswatch.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: boot banner project X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 27 Apr 2005 18:51:43 -0000 /dev/null wrote: > Hello any & all, > O.K. I feel I must preface this with an acknowledgment that I *know* > this is a silly project *because* given the *incredibly* long uptimes > that FreeBSD is known for. >>But<< for those *few* times when FreeBSDers > see a boot screen, shouldn't it look really nice? Shouldn't also be able > to reflect the Administrators tastes and personality? Well, this is the > premise for my attempting this project. But before I start, I want to > submit an RFC. So consider this an Request for comments. This is an > attempt to create a Graphical boot screen that initially has the > following layout: > (a fixed width font required to view the layout correctly) > -------------------------------------------------------- > | some | > | sort | > | of | > | graphic goes in this area | > |-------------------------------------------------------- > | boot | > | | > | messages | > | | > | seen | > | | > | here | > | bla... | > | bla... | > | bla... | > --------------------------------------------------------- > > -Chris Is it possible to do this without having to switch to an entirely raster-based console? Raster consoles (like what SuSE uses) have been discussed in the past, and the common thinking is that the loss in reliability and loss in speed is a significant issue to consider. Scott From owner-freebsd-current@FreeBSD.ORG Wed Apr 27 18:52: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 2DFF716A4CE for ; Wed, 27 Apr 2005 18:52:30 +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 D922D43D2F for ; Wed, 27 Apr 2005 18:52:29 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id B487B513A7; Wed, 27 Apr 2005 11:52:28 -0700 (PDT) Date: Wed, 27 Apr 2005 11:52:28 -0700 From: Kris Kennaway To: jroberson@chesapeake.net, current@FreeBSD.org Message-ID: <20050427185228.GA19289@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="bp/iNruPH9dso1Pn" Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Subject: ppanic: mutex lockbuilder mtxpool not owned at ../../../kern/kern_lock.c:129 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 27 Apr 2005 18:52:30 -0000 --bp/iNruPH9dso1Pn Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On 12-proc sparc64 E4500 running 6.0 with mpsafevfs. Note the 'ppanic'; this may mean that another CPU tried to panic and then this CPU panicked immediately with a secondary panic. ppanic: mutex lockbuilder mtxpool not owned at ../../../kern/kern_lock.c:129 cpuid = 1 KDB: enter: panic [thread pid 48 tid 100058 ] Stopped at kdb_enter+0x3c: ta %xcc, 1 db> wh Tracing pid 48 tid 100058 td 0xfffff800fed7b300 panic() at panic+0x16c _mtx_assert() at _mtx_assert+0x6c acquire() at acquire+0x138 lockmgr() at lockmgr+0x58c vop_stdlock() at vop_stdlock+0x14 VOP_LOCK_APV() at VOP_LOCK_APV+0xb4 ffs_lock() at ffs_lock+0xc VOP_LOCK_APV() at VOP_LOCK_APV+0xb4 vlrureclaim() at vlrureclaim+0x194 vnlru_proc() at vnlru_proc+0x16c fork_exit() at fork_exit+0x94 fork_trampoline() at fork_trampoline+0x8 db> show lockedvnods Locked vnodes panic: _mtx_lock_sleep: recursed on non-recursive mutex lockbuilder mtxpool @ ../../../kern/kern_lock.c:542 cpuid = 1 KDB: stack backtrace: sched_bind() at sched_bind+0x78 boot() at boot+0x24 panic() at panic+0x1c4 _mtx_lock_sleep() at _mtx_lock_sleep+0x40 _mtx_lock_flags() at _mtx_lock_flags+0x84 lockstatus() at lockstatus+0x18 vop_stdislocked() at vop_stdislocked+0xc VOP_ISLOCKED_APV() at VOP_ISLOCKED_APV+0xb4 lockedvnodes() at lockedvnodes+0x4c db_command() at db_command+0x2ac db_command_loop() at db_command_loop+0x70 db_trap() at db_trap+0xf0 kdb_trap() at kdb_trap+0xa0 trap() at trap+0x264 -- breakpoint %o7=0xc0189674 -- kdb_enter() at kdb_enter+0x3c panic() at panic+0x16c _mtx_assert() at _mtx_assert+0x6c acquire() at acquire+0x138 lockmgr() at lockmgr+0x58c vop_stdlock() at vop_stdlock+0x14 VOP_LOCK_APV() at VOP_LOCK_APV+0xb4 ffs_lock() at ffs_lock+0xc VOP_LOCK_APV() at VOP_LOCK_APV+0xb4 vlrureclaim() at vlrureclaim+0x194 vnlru_proc() at vnlru_proc+0x16c fork_exit() at fork_exit+0x94 fork_trampoline() at fork_trampoline+0x8 As usual on SMP I was unable to trace the processes running on the other CPUs. Kris --bp/iNruPH9dso1Pn Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFCb99sWry0BWjoQKURAmxlAJ442NvVTz4HwabKZALLq20QcA5V9ACgnTo/ h2MtHCB+hgvMPoTrZU+GeJo= =ew1F -----END PGP SIGNATURE----- --bp/iNruPH9dso1Pn-- From owner-freebsd-current@FreeBSD.ORG Wed Apr 27 19:03: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 90FDF16A4CE for ; Wed, 27 Apr 2005 19:03:10 +0000 (GMT) Received: from basement.kutulu.org (211.215.33.65.cfl.res.rr.com [65.33.215.211]) by mx1.FreeBSD.org (Postfix) with ESMTP id 081B543D1F for ; Wed, 27 Apr 2005 19:03:10 +0000 (GMT) (envelope-from kutulu@kutulu.org) Received: from [127.0.0.1] (localhost [127.0.0.1]) by basement.kutulu.org (Postfix) with ESMTP id 8FBF539 for ; Wed, 27 Apr 2005 15:03:08 -0400 (EDT) Message-ID: <426FE1EA.7020900@kutulu.org> Date: Wed, 27 Apr 2005 15:03:06 -0400 From: Mike Edenfield User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <57436.216.177.243.42.1114582155.localmail@webmail.dnswatch.com> <426FDE69.8090909@samsco.org> In-Reply-To: <426FDE69.8090909@samsco.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: boot banner project X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 27 Apr 2005 19:03:10 -0000 Scott Long wrote: > Is it possible to do this without having to switch to an entirely > raster-based console? Raster consoles (like what SuSE uses) have > been discussed in the past, and the common thinking is that the > loss in reliability and loss in speed is a significant issue to > consider. One possible alternative to an all-out graphics display would be a 'prettified' text console. I'm thinking of what Gentoo and older RedHat systems did (haven't used RH in years, dunno if this still applies) where about 80% of the system log messages are hidden behind a simple task list: Mounting File Systems ... [ok] Starting xl0 ... [ok] etc. With, of course, the obligatory cyan, magenta, and bright green colors. While partly eye candy, I find it much easier to deal with than the free-form scrolling you currently get on FreeBSD. There's definitely a different boot-message requirement between a headless server, headed (?) server, novice user desktop, advanced user desktop, etc. Currently FreeBSD only gives you three options: Static Graphic, Verbose Messages, or *REALLY* Verbose Messages. My only concern is that the console output, if I have any clue what I'm talking about, are not centralized anywhere that could be easily modified based on a setting. Is this correct? --Mike From owner-freebsd-current@FreeBSD.ORG Wed Apr 27 19:04: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 9AB6816A4CE for ; Wed, 27 Apr 2005 19:04:38 +0000 (GMT) Received: from mail-in-09.arcor-online.net (mail-in-09.arcor-online.net [151.189.21.49]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3D44943D31 for ; Wed, 27 Apr 2005 19:04:38 +0000 (GMT) (envelope-from lofi@freebsd.org) Received: from lofi.dyndns.org (dsl-213-023-193-017.arcor-ip.net [213.23.193.17]) by mail-in-09.arcor-online.net (Postfix) with ESMTP id 429645896E; Wed, 27 Apr 2005 21:04:36 +0200 (CEST) Received: from kiste.my.domain (lofi@kiste.my.domain [192.168.8.4]) (authenticated bits=0) by lofi.dyndns.org (8.13.3/8.13.3) with ESMTP id j3RJ4T3T073803 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Wed, 27 Apr 2005 21:04:31 +0200 (CEST) (envelope-from lofi@freebsd.org) From: Michael Nottebrock To: freebsd-current@freebsd.org Date: Wed, 27 Apr 2005 21:04:24 +0200 User-Agent: KMail/1.8 References: <57436.216.177.243.42.1114582155.localmail@webmail.dnswatch.com> <51866.216.177.243.42.1114613062.localmail@webmail.dnswatch.com> <1072.172.16.0.199.1114624239.squirrel@172.16.0.1> In-Reply-To: <1072.172.16.0.199.1114624239.squirrel@172.16.0.1> X-Face: &(V'^l=:*d7|\iZQZf^:4Pno1.8.ETkKo9kL3CtXal:; =*IW@TSRxh}@=?utf-8?q?*E=7Cj5VeXU=26iZ=5Fj=0A=09/uuW?=)iq#cTd?Q/zN^=C9&O7fUAReAFmJJy4DMW.yaVS9*Gmtv)4-Sn;71L?gCH.XN>=?utf-8?q?=5F=7E=5CI=0A=0989=3A?=><[=7|XpQN"qcChh}Y9l;f=fw>fcNC?j(iR6"WSWaPEF/gFc MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2064066.a9C9PmivLj"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200504272104.29245.lofi@freebsd.org> X-Virus-Scanned: by amavisd-new cc: Mike Jakubik cc: /dev/null cc: Ryan Sommers Subject: Re: boot banner project X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 27 Apr 2005 19:04:38 -0000 --nextPart2064066.a9C9PmivLj Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Wednesday, 27. April 2005 19:50, Mike Jakubik wrote: > On Wed, April 27, 2005 10:44 am, /dev/null said: > > With 30+ servers, I do alot of that as well. But it has always bothered > > me for some reason that Linux has always had their flashy boot screens. > > While FBSD has not. It was sort of like Linux thumbing it's nose at me. > > So, I felt like I'd like to start contributing to FBSD and this seemed > > like an easy place to start. Later, something more advanced (and useful= ). > > > > Thanks for the link! It should prove very useful. > > Personally, i prefer the current fbsd boot process over the linux flashy > ones. Its useless bloat, that wont impress any serious audience. The flashy linux boot splashs and related stuff are just byproducts of some= =20 very good, pretty versatile and, in the case of embedded appliances often=20 mission-critical framebuffer support. =2D-=20 ,_, | Michael Nottebrock | lofi@freebsd.org (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org --nextPart2064066.a9C9PmivLj Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQBCb+I9Xhc68WspdLARAhvvAKCRePramTb3Ce3FZ939fwEtfmKHmgCgj2vd +umgKAAdGrjWSYkiqB6sSUI= =EEvF -----END PGP SIGNATURE----- --nextPart2064066.a9C9PmivLj-- From owner-freebsd-current@FreeBSD.ORG Wed Apr 27 20:08: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 ED1D716A4CE for ; Wed, 27 Apr 2005 20:08:14 +0000 (GMT) Received: from bgo1smout1.broadpark.no (bgo1smout1.broadpark.no [217.13.4.94]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7043643D55 for ; Wed, 27 Apr 2005 20:08:14 +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 <0IFM00MSXFO4Z940@bgo1smout1.broadpark.no> for current@freebsd.org; Wed, 27 Apr 2005 22:02:28 +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 <0IFM003DUFZBD890@bgo1sminn1.broadpark.no> for current@freebsd.org; Wed, 27 Apr 2005 22:09:11 +0200 (CEST) Received: by dsa.des.no (Pony Express, from userid 666) id 6CD43452D2; Wed, 27 Apr 2005 22:08:12 +0200 (CEST) Received: from xps.des.no (xps.des.no [10.0.0.12]) by dsa.des.no (Pony Express) with ESMTP id 7C16B45171; Wed, 27 Apr 2005 22:08:06 +0200 (CEST) Received: by xps.des.no (Postfix, from userid 1001) id 6563F33C09; Wed, 27 Apr 2005 22:08:06 +0200 (CEST) Date: Wed, 27 Apr 2005 22:08:06 +0200 From: des@des.no (=?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?=) In-reply-to: <20050425161311.GA3008@troutmask.apl.washington.edu> To: Steve Kargl Message-id: <86oec00yqh.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: <20050425152648.GB25681@voodoo.oberon.net> <20050425161311.GA3008@troutmask.apl.washington.edu> 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: current@freebsd.org cc: Kirill Ponomarew Subject: Re: FreeBSD 6 is coming too fast X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 27 Apr 2005 20:08:15 -0000 Steve Kargl writes: > If you want to try gcc-4.0.0, download the tar ball and do > > configure --prefix=3D/usr/local --program-suffix=3D4 languages=3Dc,c++ that last bit should be --enable-languages=3Dc,c++ DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Wed Apr 27 20:16:53 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2882416A4CE for ; Wed, 27 Apr 2005 20:16:53 +0000 (GMT) Received: from fast.dnswatch.com (fast.dnswatch.com [216.177.243.43]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6778443D45 for ; Wed, 27 Apr 2005 20:16:52 +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 j3RKGnrt001393 for ; Wed, 27 Apr 2005 13:16:51 -0700 (PDT) (envelope-from null@dnswatch.com) Received: (from www@localhost) by fast.dnswatch.com (8.12.6/8.12.6/Submit) id j3RKGnnN001392; Wed, 27 Apr 2005 13:16:49 -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; Wed, 27 Apr 2005 13:16:49 -0700 (PDT) Message-ID: <57775.216.177.243.35.1114633009.localmail@webmail.dnswatch.com> In-Reply-To: <84dead7205042706554f32484@mail.gmail.com> References: <63349.216.177.243.42.1114575288.localmail@webmail.dnswatch.com> <20050427060414.GA54657@ns2.wananchi.com> <55065.216.177.243.42.1114583234.localmail@webmail.dnswatch.com> <20050427083649.GC6929@ns2.wananchi.com> <61364.216.177.243.42.1114593685.localmail@webmail.dnswatch.com> <84dead7205042706554f32484@mail.gmail.com> Date: Wed, 27 Apr 2005 13:16:49 -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: can't build kernel [with CONFIG this time] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 27 Apr 2005 20:16:53 -0000 O.K. here's the scoop; I newfs'd the "troublesome" machine. Then proceeded to boot to the 5.4-RC3 CD where I implimented a "standard" install. Upon finishing and rebooting. I chose to copy my backed-up kern config to /usr/src/sys/i386/conf as DEMON01. I then cd'd to /usr/src and typed: script /var/tmp/mbw.out . Then typed make buildworld. I chose not to cvsup first because of problems I had the last time and thought going a different route made more sense then using the same route expecting different results. Anyway, after a good while make barfed. I have attached the tar+gzipped mbw.out file that was the result of this attempt to build world (while this message is being moderated for size, you can download it @ http://www.dnswatch.com/kern/mbw.out.gz). The last few lines were: ... cc -O -pipe -I. -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\"/usr\" -I/usr/obj/usr/src/gnu/usr.bin/cc/cc_tools/../cc_tools -I/usr/src/gnu/usr.bin/cc/cc_tools/../cc_tools -I/usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc -I/usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/config -DGENERATOR_FILE -I/usr/obj/usr/src/i386/legacy/usr/include -c /usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/genrecog.c /usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/genrecog.c: In function `change_state': /usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/genrecog.c:1723: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. *** Error code 1 Stop in /usr/src/gnu/usr.bin/cc/cc_tools. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. demon# exit exit Script done on Wed Apr 27 11:05:51 2005 So it would appear that 5.4-RC3 world is _NOT_ buildable. :(( O.K. this box is an NS (Name Server) for quite a few domains. So it was really important that I build bind9.31... cd /usr/ports/dns/bind9, script /var/tmp/mb.out, make ... $HIT! make barfed again! >:( WTF! Was it not intended to allow building applications on FBSD-5.4-RC3?!? I'm a bit confused here. I have attached the tar+gzipped output to mb.out.gz (while this message is being moderated for size you can get the file @ http://www.dnswatch.com/kern/mb.out.gz. The last few lines are as follows: ... cc -pthread -O -pipe -I/usr/ports/dns/bind9/work/bind-9.3.1 -I. -Iinclude -I/usr/ports/dns/bind9/work/bind-9.3.1/lib/dns/include -I../../lib/dns/include -I/usr/ports/dns/bind9/work/bind-9.3.1/lib/isc/include -I../../lib/isc -I../../lib/isc/include -I../../lib/isc/unix/include -I../../lib/isc/pthreads/include -D_REENTRANT -DUSE_MD5 -DOPENSSL -D_THREAD_SAFE -W -Wall -Wmissing-prototypes -Wcast-qual -Wwrite-strings -Wformat -c dispatch.c dispatch.c: In function `dns_dispatch_detach': dispatch.c:1820: internal compiler error: in find_free_reg, at local-alloc.c:2140 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. *** Error code 1 Stop in /usr/ports/dns/bind9/work/bind-9.3.1/lib/dns. *** Error code 1 Stop in /usr/ports/dns/bind9/work/bind-9.3.1/lib. *** Error code 1 Stop in /usr/ports/dns/bind9/work/bind-9.3.1. *** Error code 1 Stop in /usr/ports/dns/bind9. demon# exit exit Script done on Wed Apr 27 11:19:00 2005 What gives??? Does anyone know? Is reverting to an "earlier model (version)" the only answer. Is FBSD progressing to uselessness - sorry, I'm pretty frustrated at this momment. Anyway, please, anyone please respond. Thanks, Chris P.S. I have also attached messages.gz (while this message is being moderated for size, you can get the file @ http://www.dnswatch.com/kern/messages.gz) which is a boot -v for this box. >> Now this one which required *no* voodoo won't build at all! > > Could you post the output of 'boot -v' on the troublesome > system (and please keep -current posted)? > > -- > FreeBSD Volunteer, http://people.freebsd.org/~jkoshy > > //////////////////////////////////////////////////// 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 Wed Apr 27 20:21: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 A085C16A4CF for ; Wed, 27 Apr 2005 20:21: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 AD38D43D5A for ; Wed, 27 Apr 2005 20:21:30 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 2E9B35133E; Wed, 27 Apr 2005 13:21:28 -0700 (PDT) Date: Wed, 27 Apr 2005 13:21:27 -0700 From: Kris Kennaway To: /dev/null Message-ID: <20050427202127.GA41246@xor.obsecurity.org> References: <63349.216.177.243.42.1114575288.localmail@webmail.dnswatch.com> <20050427060414.GA54657@ns2.wananchi.com> <55065.216.177.243.42.1114583234.localmail@webmail.dnswatch.com> <20050427083649.GC6929@ns2.wananchi.com> <61364.216.177.243.42.1114593685.localmail@webmail.dnswatch.com> <84dead7205042706554f32484@mail.gmail.com> <57775.216.177.243.35.1114633009.localmail@webmail.dnswatch.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="UugvWAfsgieZRqgk" Content-Disposition: inline In-Reply-To: <57775.216.177.243.35.1114633009.localmail@webmail.dnswatch.com> User-Agent: Mutt/1.4.2.1i cc: freebsd-current@freebsd.org Subject: Re: can't build kernel [with CONFIG this time] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 27 Apr 2005 20:21:31 -0000 --UugvWAfsgieZRqgk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Apr 27, 2005 at 01:16:49PM -0700, /dev/null wrote: > /usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/genrecog.c: In > function `change_state': >=20 > /usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/genrecog.c:1723: > internal compiler error: Segmentation fault >=20 > Please submit a full bug report, >=20 > with preprocessed source if appropriate. >=20 > See for instructions. >=20 > *** Error code 1 >=20 >=20 >=20 > Stop in /usr/src/gnu/usr.bin/cc/cc_tools. >=20 > *** Error code 1 >=20 >=20 >=20 > Stop in /usr/src. >=20 > *** Error code 1 >=20 >=20 >=20 > Stop in /usr/src. >=20 > *** Error code 1 >=20 >=20 >=20 > Stop in /usr/src. >=20 > demon# exit >=20 >=20 > exit >=20 >=20 > Script done on Wed Apr 27 11:05:51 2005 >=20 > So it would appear that 5.4-RC3 world is _NOT_ buildable. :(( No, you seem to have bad hardware. Check CPU cooling, power supply, RAM, cabling, etc. See the FAQ and the mailing list archives for extensive discussion. Kris --UugvWAfsgieZRqgk Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFCb/RGWry0BWjoQKURAo2mAKDV2sJQSxsOIWoAYD2q3hL13OGaHQCfV0SP HS6Js4wIhIZsNbg3HzTX8+Y= =Pwv+ -----END PGP SIGNATURE----- --UugvWAfsgieZRqgk-- From owner-freebsd-current@FreeBSD.ORG Wed Apr 27 20:32: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 563F216A4CE; Wed, 27 Apr 2005 20:32:18 +0000 (GMT) Received: from bgo1smout1.broadpark.no (bgo1smout1.broadpark.no [217.13.4.94]) by mx1.FreeBSD.org (Postfix) with ESMTP id 98DB643D48; Wed, 27 Apr 2005 20:32:17 +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 <0IFM00MRTGS3Z250@bgo1smout1.broadpark.no>; Wed, 27 Apr 2005 22:26:27 +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 <0IFM003DEH3AHW00@bgo1sminn1.broadpark.no>; Wed, 27 Apr 2005 22:33:10 +0200 (CEST) Received: by dsa.des.no (Pony Express, from userid 666) id CF607459C3; Wed, 27 Apr 2005 22:32:10 +0200 (CEST) Received: from xps.des.no (xps.des.no [10.0.0.12]) by dsa.des.no (Pony Express) with ESMTP id 6E7F9459C1; Wed, 27 Apr 2005 22:32:06 +0200 (CEST) Received: by xps.des.no (Postfix, from userid 1001) id 5D4E733C09; Wed, 27 Apr 2005 22:32:06 +0200 (CEST) Date: Wed, 27 Apr 2005 22:32:06 +0200 From: des@des.no (=?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?=) In-reply-to: <200504262010.49509@harrymail> To: Emanuel Strobl Message-id: <86k6mo0xmh.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: <200504262010.49509@harrymail> 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 cc: freebsd-questions@freebsd.org Subject: Re: groff alternative? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 27 Apr 2005 20:32:18 -0000 Emanuel Strobl writes: > I'm using NO_CXX in my make.conf to strip down the base system to > ~50MB including man pages. The only problem is that groff is missing > if I don't build c++, and even if I build groff itself and the > needed libstdc++ it costs me about 10MB. If I just skip NO_CXX it's > only 500k more, so I moved my patches to /dev/null. Install pre-rendered man pages instead of the mdoc source, and fake up a shell script that locates the appropriate page, decompresses it and pipes it to $PAGER. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Wed Apr 27 20:45: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 B74B016A4CE for ; Wed, 27 Apr 2005 20:45:59 +0000 (GMT) Received: from fast.dnswatch.com (fast.dnswatch.com [216.177.243.43]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1646043D6B for ; Wed, 27 Apr 2005 20:45:59 +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 j3RKjurt001714; Wed, 27 Apr 2005 13:45:58 -0700 (PDT) (envelope-from null@dnswatch.com) Received: (from www@localhost) by fast.dnswatch.com (8.12.6/8.12.6/Submit) id j3RKjts3001713; Wed, 27 Apr 2005 13:45:55 -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; Wed, 27 Apr 2005 13:45:55 -0700 (PDT) Message-ID: <52242.216.177.243.35.1114634755.localmail@webmail.dnswatch.com> In-Reply-To: <20050427202127.GA41246@xor.obsecurity.org> References: <63349.216.177.243.42.1114575288.localmail@webmail.dnswatch.com><20050427060414.GA54657@ns2.wananchi.com><55065.216.177.243.42.1114583234.localmail@webmail.dnswatch.com><20050427083649.GC6929@ns2.wananchi.com><61364.216.177.243.42.1114593685.localmail@webmail.dnswatch.com><84dead7205042706554f32484@mail.gmail.com><57775.216.177.243.35.1114633009.localmail@webmail.dnswatch.com> <20050427202127.GA41246@xor.obsecurity.org> Date: Wed, 27 Apr 2005 13:45:55 -0700 (PDT) From: "/dev/null" To: "Kris Kennaway" , 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: can't build kernel [with CONFIG this time] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 27 Apr 2005 20:45:59 -0000 Kris, Thank you for the reply and pointer(s). I have a question though. What do I need to grep for? Almost sounds like: if world won't build on your system you have bad hardware. Sorry, I've been at this problem for quite awhile now and my perspective is getting a bit blurred. Anyway, if you could throw me a small bone I'd appreciate it. Thanks again, Chris BTW Great name you have there, if you could just learn to spell it. ;) > On Wed, Apr 27, 2005 at 01:16:49PM -0700, /dev/null wrote: > >> /usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/genrecog.c: In >> function `change_state': >> >> /usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/genrecog.c:1723: >> internal compiler error: Segmentation fault >> >> Please submit a full bug report, >> >> with preprocessed source if appropriate. >> >> See for instructions. >> >> *** Error code 1 >> >> >> >> Stop in /usr/src/gnu/usr.bin/cc/cc_tools. >> >> *** Error code 1 >> --------8<---[snip]------8<----- >> >> >> Stop in /usr/src. >> >> demon# exit >> >> >> exit >> >> >> Script done on Wed Apr 27 11:05:51 2005 >> >> So it would appear that 5.4-RC3 world is _NOT_ buildable. :(( > > No, you seem to have bad hardware. Check CPU cooling, power supply, > RAM, cabling, etc. See the FAQ and the mailing list archives for > extensive discussion. > > Kris > //////////////////////////////////////////////////// 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 Wed Apr 27 20:48: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 4845816A4DC for ; Wed, 27 Apr 2005 20:48:08 +0000 (GMT) Received: from orb.pobox.com (orb.pobox.com [207.8.226.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id EE04743D2F for ; Wed, 27 Apr 2005 20:48:07 +0000 (GMT) (envelope-from discussion-lists@linnet.org) Received: from orb (localhost [127.0.0.1]) by orb.pobox.com (Postfix) with ESMTP id ADBF47D9; Wed, 27 Apr 2005 16:48:04 -0400 (EDT) Received: from billdog.local.linnet.org (dsl-212-74-113-65.access.uk.tiscali.com [212.74.113.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by orb.sasl.smtp.pobox.com (Postfix) with ESMTP id 6D5348C; Wed, 27 Apr 2005 16:48:03 -0400 (EDT) Received: from lists by billdog.local.linnet.org with local (Exim 4.43 (FreeBSD)) id 1DQtTX-0000D7-SN; Wed, 27 Apr 2005 21:49:39 +0100 Date: Wed, 27 Apr 2005 21:49:39 +0100 From: Brian Candler To: /dev/null Message-ID: <20050427204939.GA796@uk.tiscali.com> References: <63349.216.177.243.42.1114575288.localmail@webmail.dnswatch.com> <20050427060414.GA54657@ns2.wananchi.com> <55065.216.177.243.42.1114583234.localmail@webmail.dnswatch.com> <20050427083649.GC6929@ns2.wananchi.com> <61364.216.177.243.42.1114593685.localmail@webmail.dnswatch.com> <84dead7205042706554f32484@mail.gmail.com> <57775.216.177.243.35.1114633009.localmail@webmail.dnswatch.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <57775.216.177.243.35.1114633009.localmail@webmail.dnswatch.com> User-Agent: Mutt/1.4.2.1i cc: freebsd-current@freebsd.org Subject: Re: can't build kernel [with CONFIG this time] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 27 Apr 2005 20:48:08 -0000 On Wed, Apr 27, 2005 at 01:16:49PM -0700, /dev/null wrote: > /usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/genrecog.c:1723: > internal compiler error: Segmentation fault http://www.bitwizard.nl/sig11/ From owner-freebsd-current@FreeBSD.ORG Wed Apr 27 20: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 A52D816A4CE for ; Wed, 27 Apr 2005 20:51:07 +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 32D1B43D4C for ; Wed, 27 Apr 2005 20:51:07 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id D8B85514C9; Wed, 27 Apr 2005 13:51:05 -0700 (PDT) Date: Wed, 27 Apr 2005 13:51:05 -0700 From: Kris Kennaway To: /dev/null Message-ID: <20050427205105.GA52820@xor.obsecurity.org> References: <20050427202127.GA41246@xor.obsecurity.org> <52242.216.177.243.35.1114634755.localmail@webmail.dnswatch.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: <52242.216.177.243.35.1114634755.localmail@webmail.dnswatch.com> User-Agent: Mutt/1.4.2.1i cc: freebsd-current@freebsd.org cc: Kris Kennaway Subject: Re: can't build kernel [with CONFIG this time] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 27 Apr 2005 20:51:07 -0000 --ibTvN161/egqYuK8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wed, Apr 27, 2005 at 01:45:55PM -0700, /dev/null wrote: > Kris, > Thank you for the reply and pointer(s). I have a question though. What do > I need to grep for? Almost sounds like: if world won't build on your system > you have bad hardware. Sorry, I've been at this problem for quite awhile > now and my perspective is getting a bit blurred. Anyway, if you could throw > me a small bone I'd appreciate it. The key is the segmentation fault during compilation, which does not happen on a working system. You may find that other processes have receieved random signals as well. Kris --ibTvN161/egqYuK8 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFCb/s5Wry0BWjoQKURAo0bAJ9mTvtiYhGtCAdDTc+Hepq2ct7XLwCeIUe5 e2gDp4R0fYrXbMPolWVs+qo= =61SB -----END PGP SIGNATURE----- --ibTvN161/egqYuK8-- From owner-freebsd-current@FreeBSD.ORG Wed Apr 27 20: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 196F316A4CE for ; Wed, 27 Apr 2005 20:57:52 +0000 (GMT) Received: from fast.dnswatch.com (fast.dnswatch.com [216.177.243.43]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9D5ED43D2F for ; Wed, 27 Apr 2005 20:57:51 +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 j3RKvnrt001826; Wed, 27 Apr 2005 13:57:51 -0700 (PDT) (envelope-from null@dnswatch.com) Received: (from www@localhost) by fast.dnswatch.com (8.12.6/8.12.6/Submit) id j3RKvnNa001825; Wed, 27 Apr 2005 13:57:49 -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; Wed, 27 Apr 2005 13:57:49 -0700 (PDT) Message-ID: <50200.216.177.243.35.1114635469.localmail@webmail.dnswatch.com> In-Reply-To: <20050427205105.GA52820@xor.obsecurity.org> References: <20050427202127.GA41246@xor.obsecurity.org><52242.216.177.243.35.1114634755.localmail@webmail.dnswatch.com> <20050427205105.GA52820@xor.obsecurity.org> Date: Wed, 27 Apr 2005 13:57:49 -0700 (PDT) From: "/dev/null" To: "Kris Kennaway" , 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: can't build kernel [with CONFIG this time] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 27 Apr 2005 20:57:52 -0000 Kris, Thanks for the input. I haven't had any other segfaults or core dumps. But I'll be researching your suggestion. Much appreciated. -Chris > On Wed, Apr 27, 2005 at 01:45:55PM -0700, /dev/null wrote: >> Kris, >> Thank you for the reply and pointer(s). I have a question though. What >> do >> I need to grep for? Almost sounds like: if world won't build on your >> system >> you have bad hardware. Sorry, I've been at this problem for quite awhile >> now and my perspective is getting a bit blurred. Anyway, if you could >> throw >> me a small bone I'd appreciate it. > > The key is the segmentation fault during compilation, which does not > happen on a working system. You may find that other processes have > receieved random signals as well. > > Kris > //////////////////////////////////////////////////// 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 Wed Apr 27 21:00: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 73CD716A4CE for ; Wed, 27 Apr 2005 21:00:13 +0000 (GMT) Received: from fast.dnswatch.com (fast.dnswatch.com [216.177.243.43]) by mx1.FreeBSD.org (Postfix) with ESMTP id F06AA43D4C for ; Wed, 27 Apr 2005 21:00:12 +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 j3RL0Brt001880; Wed, 27 Apr 2005 14:00:12 -0700 (PDT) (envelope-from null@dnswatch.com) Received: (from www@localhost) by fast.dnswatch.com (8.12.6/8.12.6/Submit) id j3RL0BVJ001879; Wed, 27 Apr 2005 14:00:11 -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; Wed, 27 Apr 2005 14:00:11 -0700 (PDT) Message-ID: <53015.216.177.243.35.1114635611.localmail@webmail.dnswatch.com> In-Reply-To: <20050427204939.GA796@uk.tiscali.com> References: <63349.216.177.243.42.1114575288.localmail@webmail.dnswatch.com> <20050427060414.GA54657@ns2.wananchi.com> <55065.216.177.243.42.1114583234.localmail@webmail.dnswatch.com> <20050427083649.GC6929@ns2.wananchi.com> <61364.216.177.243.42.1114593685.localmail@webmail.dnswatch.com> <84dead7205042706554f32484@mail.gmail.com> <57775.216.177.243.35.1114633009.localmail@webmail.dnswatch.com> <20050427204939.GA796@uk.tiscali.com> Date: Wed, 27 Apr 2005 14:00:11 -0700 (PDT) From: "/dev/null" To: "Brian Candler" , 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: can't build kernel [with CONFIG this time] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 27 Apr 2005 21:00:13 -0000 Brian, Thank you for your reply. Thanks for the link. Looks like I have some reading to do. :) Wish me luck! -Chris > On Wed, Apr 27, 2005 at 01:16:49PM -0700, /dev/null wrote: >> /usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/genrecog.c:1723: >> internal compiler error: Segmentation fault > > http://www.bitwizard.nl/sig11/ > //////////////////////////////////////////////////// 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 Wed Apr 27 21:09: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 03C9916A4CE for ; Wed, 27 Apr 2005 21:09:26 +0000 (GMT) Received: from hq.sectorb.msk.ru (petaflop.b.gz.ru [217.67.124.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 909D843D49 for ; Wed, 27 Apr 2005 21:09:22 +0000 (GMT) (envelope-from chinhngt@sectorb.msk.ru) Received: from it.hackers (it.hackers [172.16.37.1]) by hq.sectorb.msk.ru (Postfix) with ESMTP id 374BE72FB; Thu, 28 Apr 2005 01:09:20 +0400 (MSD) Date: Thu, 28 Apr 2005 01:11:06 +0400 (MSD) From: Nguyen Tam Chinh X-X-Sender: chinhngt@it.hackers To: /dev/null In-Reply-To: <52242.216.177.243.35.1114634755.localmail@webmail.dnswatch.com> Message-ID: <20050428010348.Q2240@it.hackers> References: <63349.216.177.243.42.1114575288.localmail@webmail.dnswatch.com><20050427060414.GA54657@ns2.wananchi.com><55065.216.177.243.42.1114583234.localmail@webmail.dnswatch.com><20050427083649.GC6929@ns2.wananchi.com><61364.216.177.243.42.1114593685.localmail@webmail.dnswatch.com><84dead7205042706554f32484@mail.gmail.com><57775.216.177.243.35.1114633009.localmail@webmail.dnswatch.com> <20050427202127.GA41246@xor.obsecurity.org> <52242.216.177.243.35.1114634755.localmail@webmail.dnswatch.com> X-Operating-System: FreeBSD 5.3-STABLE Keywords: 216091683 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed cc: freebsd-current@freebsd.org cc: Kris Kennaway Subject: Re: can't build kernel [with CONFIG this time] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 27 Apr 2005 21:09:26 -0000 On Wed, 27 Apr 2005, /dev/null wrote: > Kris, > Thank you for the reply and pointer(s). I have a question though. What do > I need to grep for? Almost sounds like: if world won't build on your system > you have bad hardware. Sorry, I've been at this problem for quite awhile > now and my perspective is getting a bit blurred. Anyway, if you could throw > me a small bone I'd appreciate it. > >> No, you seem to have bad hardware. Check CPU cooling, power supply, >> RAM, cabling, etc. See the FAQ and the mailing list archives for >> extensive discussion. >> Just for information, I've a notebook with bad cooling system and the buildworld/kernel often fail with such error like "gcc: internal error ...". If I put that notebook in a cooler place, in most case the building process passed by flawlessly. NOTES: This's just my experience. I've never seen such errors on the old compaq desktop. ----- With best regards, | The Power to Serve Nguyen Tam Chinh | http://www.FreeBSD.org Loc: sp.cs.msu.ru | From owner-freebsd-current@FreeBSD.ORG Wed Apr 27 21:11: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 D4AB016A4CE for ; Wed, 27 Apr 2005 21:11: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 24F6D43D48 for ; Wed, 27 Apr 2005 21:11:17 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 447EF51F7B; Wed, 27 Apr 2005 14:11:14 -0700 (PDT) Date: Wed, 27 Apr 2005 14:11:14 -0700 From: Kris Kennaway To: jroberson@chesapeake.net, current@FreeBSD.org Message-ID: <20050427211113.GA55317@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="4Ckj6UjgE2iN1+kY" Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Subject: panic in ufs_remove() on 6.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 27 Apr 2005 21:11:23 -0000 --4Ckj6UjgE2iN1+kY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Actually, my last message was not from the e4500 but another SMP sparc64 running 6.0. Here's the panic from the e4500 overnight. Unfortunately no ktr is available but I have a dump. panic: trap: fast data access mmu miss cpuid =3D 10 KDB: enter: panic [thread pid 64968 tid 100313 ] Stopped at kdb_enter+0x3c: ta %xcc, 1 db> wh Tracing pid 64968 tid 100313 td 0xfffff800e70f3c80 panic() at panic+0x16c trap() at trap+0x3f0 -- fast data access mmu miss tar=3D0 %o7=3D0xc0162240 -- ufs_remove() at ufs_remove+0xc VOP_REMOVE_APV() at VOP_REMOVE_APV+0xb4 kern_unlink() at kern_unlink+0x174 unlink() at unlink+0xc syscall() at syscall+0x2b4 -- syscall (10, FreeBSD ELF64, unlink) %o7=3D0x101998 -- userland() at 0x403a2f68 user trace: trap %o7=3D0x101998 pc 0x403a2f68, sp 0x7fdffffd9f1 pc 0x101550, sp 0x7fdffffdab1 pc 0x1010d0, sp 0x7fdffffdb71 pc 0x4020add4, sp 0x7fdffffdc31 done db> show lockedvnods Locked vnodes 0xfffff800f8f23708: tag ufs, type VDIR usecount 0, writecount 0, refcount 3 mountedhere 0 flags () v_object 0xfffff800e2537b00 ref 0 pages 1 lock type ufs: EXCL (count 1) by thread 0xfffff80106018980 (pid 32175) ino 5613180, on dev stripe/data 0xfffff800f8adc218: tag ufs, type VDIR usecount 2, writecount 0, refcount 4 mountedhere 0 flags () v_object 0xfffff80003e8a800 ref 0 pages 1 lock type ufs: EXCL (count 1) by thread 0xfffff800b005ae40 (pid 65007) ino 4642216, on dev stripe/data 0xfffff800e570bb38: tag ufs, type VDIR usecount 1, writecount 0, refcount 4 mountedhere 0 flags () v_object 0xfffff800e99f2800 ref 0 pages 1 lock type ufs: EXCL (count 1) by thread 0xfffff80057a1c720 (pid 65257) ino 542874, on dev stripe/data 0xfffff800e1582430: tag ufs, type VDIR usecount 2, writecount 0, refcount 4 mountedhere 0 flags () v_object 0xfffff800e6537b00 ref 0 pages 1 lock type ufs: EXCL (count 1) by thread 0xfffff800b0c8e720 (pid 62865) ino 4666062, on dev stripe/data 0xfffff800f8b9d708: tag ufs, type VDIR usecount 1, writecount 0, refcount 3 mountedhere 0 flags () lock type ufs: EXCL (count 1) by thread 0xfffff800d2d89c80 (pid 62499) ino 6578148, on dev stripe/data 0xfffff800eb26d4f0: tag ufs, type VDIR usecount 1, writecount 0, refcount 3 mountedhere 0 flags () lock type ufs: EXCL (count 1) by thread 0xfffff800634dd560 (pid 55967) ino 897174, on dev stripe/data 0xfffff800ef532c90: tag ufs, type VDIR usecount 1, writecount 0, refcount 3 mountedhere 0 flags () lock type ufs: EXCL (count 1) by thread 0xfffff800a63fc000 (pid 65129) ino 242718, on dev stripe/data 0xfffff800e46a30c0: tag ufs, type VDIR usecount 2, writecount 0, refcount 3 mountedhere 0 flags () lock type ufs: EXCL (count 1) by thread 0xfffff80104d92be0 (pid 64286) ino 827990, on dev stripe/data 0xfffff800edcb0ea8: tag ufs, type VDIR usecount 1, writecount 0, refcount 3 mountedhere 0 flags () lock type ufs: EXCL (count 1) by thread 0xfffff800d4507c80 (pid 58926) ino 5613149, on dev stripe/data 0xfffff800f8df0ea8: tag ufs, type VDIR usecount 2, writecount 0, refcount 3 mountedhere 0 flags () lock type ufs: EXCL (count 1) by thread 0xfffff800a6e0d300 (pid 24296) ino 265342, on dev stripe/data 0xfffff800e7912a78: tag ufs, type VDIR usecount 1, writecount 0, refcount 3 mountedhere 0 flags () lock type ufs: EXCL (count 1) by thread 0xfffff800c8905c80 (pid 65408) ino 4664127, on dev stripe/data 0xfffff800f86e92d8: tag ufs, type VDIR usecount 1, writecount 0, refcount 3 mountedhere 0 flags () lock type ufs: EXCL (count 1) by thread 0xfffff8004581e000 (pid 62258) ino 755584, on dev stripe/data 0xfffff800ed8c8000: tag ufs, type VDIR usecount 1, writecount 0, refcount 3 mountedhere 0 flags () lock type ufs: EXCL (count 1) by thread 0xfffff800c4bac720 (pid 61710) ino 3534131, on dev stripe/data 0xfffff800f84790c0: tag ufs, type VDIR usecount 1, writecount 0, refcount 3 mountedhere 0 flags () lock type ufs: EXCL (count 1) by thread 0xfffff800c7ccabe0 (pid 58687) ino 754502, on dev stripe/data 0xfffff800f84e9920: tag ufs, type VDIR usecount 1, writecount 0, refcount 3 mountedhere 0 flags () v_object 0xfffff8009c5ce200 ref 0 pages 1 lock type ufs: EXCL (count 1) by thread 0xfffff800b005ae40 (pid 65007) ino 4642834, on dev stripe/data 0xfffff800f8f74000: tag ufs, type VDIR usecount 1, writecount 0, refcount 2 mountedhere 0 flags () lock type ufs: EXCL (count 1) by thread 0xfffff800e67bae40 (pid 58898) ino 898001, on dev stripe/data 0xfffff800f8ba8648: tag ufs, type VREG usecount 2, writecount 1, refcount 6 mountedhere 0 flags () v_object 0xfffff800e4d23400 ref 0 pages 6 lock type ufs: EXCL (count 1) by thread 0xfffff800e60750a0 (pid 53718) ino 898003, on dev stripe/data 0xfffff800f8c78000: tag ufs, type VDIR usecount 1, writecount 0, refcount 2 mountedhere 0 flags () lock type ufs: EXCL (count 1) by thread 0xfffff8004581e000 (pid 62258) ino 754513, on dev stripe/data 0xfffff800f15134f0: tag ufs, type VDIR usecount 1, writecount 0, refcount 2 mountedhere 0 flags () lock type ufs: EXCL (count 1) by thread 0xfffff800c4bac720 (pid 61710) ino 3534138, on dev stripe/data 0xfffff800e80f4218: tag ufs, type VREG usecount 1, writecount 0, refcount 1 mountedhere 0 flags () lock type ufs: EXCL (count 1) by thread 0xfffff800e67bae40 (pid 58898) ino 898004, on dev stripe/data 0xfffff800ec7cc000: tag ufs, type VREG usecount 1, writecount 0, refcount 1 mountedhere 0 flags () lock type ufs: EXCL (count 1) by thread 0xfffff800634dd560 (pid 55967) ino 898005, on dev stripe/data 0xfffff800eb405b38: tag ufs, type VDIR usecount 1, writecount 0, refcount 2 mountedhere 0 flags () lock type ufs: EXCL (count 1) by thread 0xfffff800d2d89c80 (pid 62499) ino 6649117, on dev stripe/data 0xfffff800f8f5cc90: tag ufs, type VREG usecount 1, writecount 0, refcount 1 mountedhere 0 flags () lock type ufs: EXCL (count 1) by thread 0xfffff800c7ccabe0 (pid 58687) ino 755630, on dev stripe/data 0xfffff800eb0ddb38: tag ufs, type VREG usecount 1, writecount 0, refcount 1 mountedhere 0 flags () lock type ufs: EXCL (count 1) by thread 0xfffff800a63fc000 (pid 65129) ino 242962, on dev stripe/data 0xfffff800f95394f0: tag ufs, type VREG usecount 1, writecount 0, refcount 1 mountedhere 0 flags () lock type ufs: EXCL (count 1) by thread 0xfffff800c8905c80 (pid 65408) ino 4664659, on dev stripe/data 0xfffff800e188f0c0: tag ufs, type VREG usecount 1, writecount 0, refcount 1 mountedhere 0 flags () lock type ufs: EXCL (count 1) by thread 0xfffff800d4507c80 (pid 58926) ino 5613190, on dev stripe/data 0xfffff800e51692d8: tag ufs, type VDIR usecount 2, writecount 0, refcount 4 mountedhere 0 flags () v_object 0xfffff800e174d800 ref 0 pages 2 lock type ufs: EXCL (count 1) by thread 0xfffff800e70f3c80 (pid 64968) ino 242716, on dev stripe/data 0xfffff800ee44b4f0: tag ufs, type VDIR usecount 1, writecount 0, refcount 3 mountedhere 0 flags () v_object 0xfffff800eef60d00 ref 0 pages 1 lock type ufs: EXCL (count 1) by thread 0xfffff800b0c8e720 (pid 62865) ino 4666271, on dev stripe/data db> wh 32175 Tracing pid 32175 tid 100822 td 0xfffff80106018980 mi_switch() at mi_switch+0x2b0 sleepq_switch() at sleepq_switch+0xf4 sleepq_wait() at sleepq_wait+0x3c db> wh 65007 Tracing pid 65007 tid 100687 td 0xfffff800b005ae40 mi_switch() at mi_switch+0x2b0 sleepq_switch() at sleepq_switch+0xf4 sleepq_wait() at sleepq_wait+0x3c msleep() at msleep+0x340 bwait() at bwait+0x48 bufwait() at bufwait+0x34 bufwrite() at bufwrite+0x1b8 ufs_dirremove() at ufs_dirremove+0x330 ufs_rmdir() at ufs_rmdir+0xdc VOP_RMDIR_APV() at VOP_RMDIR_APV+0xb4 kern_rmdir() at kern_rmdir+0x1ac rmdir() at rmdir+0xc syscall() at syscall+0x2b4 -- syscall (137, FreeBSD ELF64, rmdir) %o7=3D0x101894 -- userland() at 0x403a1b68 user trace: trap %o7=3D0x101894 pc 0x403a1b68, sp 0x7fdffffe091 pc 0x696c642f73706172, sp 0x612f706f72746275 db> wh 65257 Tracing pid 65257 tid 100179 td 0xfffff80057a1c720 --More-- mi_switch() at mi_switch+0x2b0 db> wh 62865 Tracing pid 62865 tid 100519 td 0xfffff800b0c8e720 mi_switch() at mi_switch+0x2b0 sleepq_switch() at sleepq_switch+0xf4 sleepq_wait() at sleepq_wait+0x3c msleep() at msleep+0x340 bwait() at bwait+0x48 bufwait() at bufwait+0x34 bufwrite() at bufwrite+0x1b8 ffs_bufwrite() at ffs_bufwrite+0x2e8 ffs_update() at ffs_update+0x2c4 ffs_truncate() at ffs_truncate+0x9b4 ufs_rmdir() at ufs_rmdir+0x224 VOP_RMDIR_APV() at VOP_RMDIR_APV+0xb4 kern_rmdir() at kern_rmdir+0x1ac rmdir() at rmdir+0xc syscall() at syscall+0x2b4 -- syscall (137, FreeBSD ELF64, rmdir) %o7=3D0x101894 -- userland() at 0x403a1b68 user trace: trap %o7=3D0x101894 pc 0x403a1b68, sp 0x7fdffffdb01 pc 0x3, sp 0x7fdffffe518 --More-- pc 0x3030005348454c4c, sp 0x494f4e3d35303431 db> wh 64=08 =082499 Tracing pid 62499 tid 100464 td 0xfffff800d2d89c80 mi_switch() at mi_switch+0x2b0 sleepq_switch() at sleepq_switch+0xf4 sleepq_wait() at sleepq_wait+0x3c msleep() at msleep+0x340 bwait() at bwait+0x48 bufwait() at bufwait+0x34 bufwrite() at bufwrite+0x1b8 ufs_direnter() at ufs_direnter+0x768 ufs_mkdir() at ufs_mkdir+0x780 VOP_MKDIR_APV() at VOP_MKDIR_APV+0xb4 kern_mkdir() at kern_mkdir+0x2f0 mkdir() at mkdir+0x10 syscall() at syscall+0x2b4 -- syscall (136, FreeBSD ELF64, mkdir) %o7=3D0x40343230 -- userland() at 0x406f1ba8 user trace: trap %o7=3D0x40343230 pc 0x406f1ba8, sp 0x7fdffffd561 pc 0x1000, sp 0x2003051800000004 db> wh 55967 Tracing pid 55967 tid 100255 td 0xfffff800634dd560 --More-- mi_switch() at mi_switch+0x2b0 sleepq_switch() at sleepq_switch+0xf4 sleepq_wait() at sleepq_wait+0x3c msleep() at msleep+0x340 bwait() at bwait+0x48 bufwait() at bufwait+0x34 bufwrite() at bufwrite+0x1b8 ffs_bufwrite() at ffs_bufwrite+0x2e8 ffs_update() at ffs_update+0x2c4 ufs_makeinode() at ufs_makeinode+0x38c ufs_create() at ufs_create+0x34 VOP_CREATE_APV() at VOP_CREATE_APV+0xb4 vn_open_cred() at vn_open_cred+0x188 vn_open() at vn_open+0x18 kern_open() at kern_open+0x8c open() at open+0x14 syscall() at syscall+0x2b4 -- syscall (5, FreeBSD ELF64, open) %o7=3D0x40342c38 -- userland() at 0x406f3068 user trace: trap %o7=3D0x40342c38 --More-- pc 0x406f3068, sp 0x7fdffffd871 pc 0x40398434, sp 0x7fdffffd931 pc 0x101a18, sp 0x7fdffffd9f1 pc 0x101550, sp 0x7fdffffdab1 pc 0x1010d0, sp 0x7fdffffdb71 pc 0x4020add4, sp 0x7fdffffdc31 done db> wh 65129 Tracing pid 65129 tid 100680 td 0xfffff800a63fc000 mi_switch() at mi_switch+0x2b0 sleepq_switch() at sleepq_switch+0xf4 sleepq_wait() at sleepq_wait+0x3c msleep() at msleep+0x340 bwait() at bwait+0x48 bufwait() at bufwait+0x34 bufwrite() at bufwrite+0x1b8 ufs_direnter() at ufs_direnter+0x768 ufs_makeinode() at ufs_makeinode+0x450 ufs_create() at ufs_create+0x34 VOP_CREATE_APV() at VOP_CREATE_APV+0xb4 vn_open_cred() at vn_open_cred+0x188 vn_open() at vn_open+0x18 kern_open() at kern_open+0x8c open() at open+0x14 syscall() at syscall+0x2b4 -- syscall (5, FreeBSD ELF64, open) %o7=3D0x40342c38 -- userland() at 0x406f3068 user trace: trap %o7=3D0x40342c38 pc 0x406f3068, sp 0x7fdffffd8e1 --More-- pc 0, sp 0x4400001202 db> wh 64286 Tracing pid 64286 tid 100790 td 0xfffff80104d92be0 mi_switch() at mi_switch+0x2b0 sleepq_switch() at sleepq_switch+0xf4 sleepq_wait() at sleepq_wait+0x3c msleep() at msleep+0x340 bwait() at bwait+0x48 bufwait() at bufwait+0x34 bufwrite() at bufwrite+0x1b8 ffs_bufwrite() at ffs_bufwrite+0x2e8 ffs_update() at ffs_update+0x2c4 ufs_direnter() at ufs_direnter+0x3c4 ufs_rename() at ufs_rename+0x5d0 VOP_RENAME_APV() at VOP_RENAME_APV+0xb4 kern_rename() at kern_rename+0x284 rename() at rename+0x10 syscall() at syscall+0x2b4 -- syscall (128, FreeBSD ELF64, rename) %o7=3D0x104c40 -- userland() at 0x40961c28 user trace: trap %o7=3D0x104c40 pc 0x40961c28, sp 0x7fdfffb91e1 db> =08 =08wh 58926 --More-- Tracing pid 58926 tid 100427 td 0xfffff800d4507c80 mi_switch() at mi_switch+0x2b0 sleepq_switch() at sleepq_switch+0xf4 sleepq_wait() at sleepq_wait+0x3c msleep() at msleep+0x340 bwait() at bwait+0x48 bufwait() at bufwait+0x34 bufwrite() at bufwrite+0x1b8 ffs_bufwrite() at ffs_bufwrite+0x2e8 ffs_update() at ffs_update+0x2c4 ufs_makeinode() at ufs_makeinode+0x38c ufs_create() at ufs_create+0x34 VOP_CREATE_APV() at VOP_CREATE_APV+0xb4 vn_open_cred() at vn_open_cred+0x188 vn_open() at vn_open+0x18 kern_open() at kern_open+0x8c open() at open+0x14 syscall() at syscall+0x2b4 -- syscall (5, FreeBSD ELF64, open) %o7=3D0x40342c20 -- userland() at 0x406f3068 user trace: trap %o7=3D0x40342c20 --More-- pc 0x406f3068, sp 0x7fdffffd841 pc 0, sp 0x215e00 pc 0x5d81a40001000000, sp 0x4510003b4 db> wh 24296 Tracing pid 24296 tid 100672 td 0xfffff800a6e0d300 mi_switch() at mi_switch+0x2b0 sleepq_switch() at sleepq_switch+0xf4 sleepq_wait() at sleepq_wait+0x3c msleep() at msleep+0x340 bwait() at bwait+0x48 bufwait() at bufwait+0x34 bufwrite() at bufwrite+0x1b8 ufs_direnter() at ufs_direnter+0x768 ufs_rename() at ufs_rename+0x5d0 VOP_RENAME_APV() at VOP_RENAME_APV+0xb4 kern_rename() at kern_rename+0x284 rename() at rename+0x10 syscall() at syscall+0x2b4 -- syscall (128, FreeBSD ELF64, rename) %o7=3D0x104c40 -- userland() at 0x40961c28 user trace: trap %o7=3D0x104c40 pc 0x40961c28, sp 0x7fdfffb9221 db> wh 65408 Tracing pid 65408 tid 100451 td 0xfffff800c8905c80 mi_switch() at mi_switch+0x2b0 sleepq_switch() at sleepq_switch+0xf4 sleepq_wait() at sleepq_wait+0x3c msleep() at msleep+0x340 bwait() at bwait+0x48 bufwait() at bufwait+0x34 bufwrite() at bufwrite+0x1b8 ufs_direnter() at ufs_direnter+0x768 ufs_makeinode() at ufs_makeinode+0x450 ufs_create() at ufs_create+0x34 VOP_CREATE_APV() at VOP_CREATE_APV+0xb4 vn_open_cred() at vn_open_cred+0x188 vn_open() at vn_open+0x18 kern_open() at kern_open+0x8c open() at open+0x14 syscall() at syscall+0x2b4 -- syscall (5, FreeBSD ELF64, open) %o7=3D0x403499ac -- userland() at 0x406eaf68 user trace: trap %o7=3D0x403499ac pc 0x406eaf68, sp 0x7fdffffd1c1 --More-- done db> wh 62257=08 =088 Tracing pid 62258 tid 100094 td 0xfffff8004581e000 mi_switch() at mi_switch+0x2b0 sleepq_switch() at sleepq_switch+0xf4 sleepq_wait() at sleepq_wait+0x3c msleep() at msleep+0x340 bwait() at bwait+0x48 bufwait() at bufwait+0x34 bufwrite() at bufwrite+0x1b8 ufs_direnter() at ufs_direnter+0x768 ufs_mkdir() at ufs_mkdir+0x780 VOP_MKDIR_APV() at VOP_MKDIR_APV+0xb4 kern_mkdir() at kern_mkdir+0x2f0 mkdir() at mkdir+0x10 syscall() at syscall+0x2b4 -- syscall (136, FreeBSD ELF64, mkdir) %o7=3D0x40348b7c -- userland() at 0x406e9aa8 user trace: trap %o7=3D0x40348b7c pc 0x406e9aa8, sp 0x7fdffffce61 done db> =08 =08wh 61707=08 =08=08 =0810 Tracing pid 61710 tid 100614 td 0xfffff800c4bac720 mi_switch() at mi_switch+0x2b0 sleepq_switch() at sleepq_switch+0xf4 sleepq_wait() at sleepq_wait+0x3c msleep() at msleep+0x340 bwait() at bwait+0x48 bufwait() at bufwait+0x34 bufwrite() at bufwrite+0x1b8 ufs_direnter() at ufs_direnter+0x768 ufs_mkdir() at ufs_mkdir+0x780 VOP_MKDIR_APV() at VOP_MKDIR_APV+0xb4 kern_mkdir() at kern_mkdir+0x2f0 mkdir() at mkdir+0x10 syscall() at syscall+0x2b4 -- syscall (136, FreeBSD ELF64, mkdir) %o7=3D0x40348b7c -- userland() at 0x406e9aa8 user trace: trap %o7=3D0x40348b7c pc 0x406e9aa8, sp 0x7fdffffcd71 done db> wh 58687 Tracing pid 58687 tid 100445 td 0xfffff800c7ccabe0 mi_switch() at mi_switch+0x2b0 sleepq_switch() at sleepq_switch+0xf4 sleepq_wait() at sleepq_wait+0x3c msleep() at msleep+0x340 bwait() at bwait+0x48 bufwait() at bufwait+0x34 bufwrite() at bufwrite+0x1b8 ufs_direnter() at ufs_direnter+0x768 ufs_makeinode() at ufs_makeinode+0x450 ufs_create() at ufs_create+0x34 VOP_CREATE_APV() at VOP_CREATE_APV+0xb4 vn_open_cred() at vn_open_cred+0x188 vn_open() at vn_open+0x18 kern_open() at kern_open+0x8c open() at open+0x14 syscall() at syscall+0x2b4 -- syscall (5, FreeBSD ELF64, open) %o7=3D0x40342c38 -- userland() at 0x406f3068 user trace: trap %o7=3D0x40342c38 pc 0x406f3068, sp 0x7fdffffd7c1 --More-- done db> wh 65007 Tracing pid 65007 tid 100687 td 0xfffff800b005ae40 mi_switch() at mi_switch+0x2b0 sleepq_switch() at sleepq_switch+0xf4 sleepq_wait() at sleepq_wait+0x3c msleep() at msleep+0x340 bwait() at bwait+0x48 bufwait() at bufwait+0x34 bufwrite() at bufwrite+0x1b8 ufs_dirremove() at ufs_dirremove+0x330 ufs_rmdir() at ufs_rmdir+0xdc VOP_RMDIR_APV() at VOP_RMDIR_APV+0xb4 kern_rmdir() at kern_rmdir+0x1ac rmdir() at rmdir+0xc syscall() at syscall+0x2b4 -- syscall (137, FreeBSD ELF64, rmdir) %o7=3D0x101894 -- userland() at 0x403a1b68 user trace: trap %o7=3D0x101894 pc 0x403a1b68, sp 0x7fdffffe091 pc 0x696c642f73706172, sp 0x612f706f72746275 db> =08 =08wh 58898 Tracing pid 58898 tid 100726 td 0xfffff800e67bae40 --More-- mi_switch() at mi_switch+0x2b0 sleepq_switch() at sleepq_switch+0xf4 sleepq_wait() at sleepq_wait+0x3c msleep() at msleep+0x340 bwait() at bwait+0x48 bufwait() at bufwait+0x34 bufwrite() at bufwrite+0x1b8 ufs_direnter() at ufs_direnter+0x768 ufs_makeinode() at ufs_makeinode+0x450 ufs_create() at ufs_create+0x34 VOP_CREATE_APV() at VOP_CREATE_APV+0xb4 vn_open_cred() at vn_open_cred+0x188 vn_open() at vn_open+0x18 kern_open() at kern_open+0x8c open() at open+0x14 syscall() at syscall+0x2b4 -- syscall (5, FreeBSD ELF64, open) %o7=3D0x40342c94 -- userland() at 0x406f3068 user trace: trap %o7=3D0x40342c94 pc 0x406f3068, sp 0x7fdffffd851 --More-- pc 0x403a2f64, sp 0xc02f1700 db> wh 53718 Tracing pid 53718 tid 100305 td 0xfffff800e60750a0 mi_switch() at mi_switch+0x2b0 sleepq_switch() at sleepq_switch+0xf4 sleepq_wait() at sleepq_wait+0x3c msleep() at msleep+0x340 acquire() at acquire+0x84 lockmgr() at lockmgr+0x5b4 getblk() at getblk+0x124 breadn() at breadn+0x24 bread() at bread+0x20 ffs_update() at ffs_update+0x158 ufs_setattr() at ufs_setattr+0x5ac VOP_SETATTR_APV() at VOP_SETATTR_APV+0xb4 setutimes() at setutimes+0x18c kern_lutimes() at kern_lutimes+0x78 lutimes() at lutimes+0x14 syscall() at syscall+0x2b4 -- syscall (276, FreeBSD ELF64, lutimes) %o7=3D0x40349258 -- userland() at 0x406e8c68 user trace: trap %o7=3D0x40349258 pc 0x406e8c68, sp 0x7fdffffd111 --More-- pc 0x7ab8a40, sp 0x212000 pc 0xc41ed0004000000, sp 0x45100061c db> wh 62258 Tracing pid 62258 tid 100094 td 0xfffff8004581e000 mi_switch() at mi_switch+0x2b0 sleepq_switch() at sleepq_switch+0xf4 sleepq_wait() at sleepq_wait+0x3c msleep() at msleep+0x340 bwait() at bwait+0x48 bufwait() at bufwait+0x34 bufwrite() at bufwrite+0x1b8 ufs_direnter() at ufs_direnter+0x768 ufs_mkdir() at ufs_mkdir+0x780 VOP_MKDIR_APV() at VOP_MKDIR_APV+0xb4 kern_mkdir() at kern_mkdir+0x2f0 mkdir() at mkdir+0x10 syscall() at syscall+0x2b4 -- syscall (136, FreeBSD ELF64, mkdir) %o7=3D0x40348b7c -- userland() at 0x406e9aa8 user trace: trap %o7=3D0x40348b7c pc 0x406e9aa8, sp 0x7fdffffce61 done db> wh 61710 Tracing pid 61710 tid 100614 td 0xfffff800c4bac720 mi_switch() at mi_switch+0x2b0 sleepq_switch() at sleepq_switch+0xf4 sleepq_wait() at sleepq_wait+0x3c msleep() at msleep+0x340 bwait() at bwait+0x48 bufwait() at bufwait+0x34 bufwrite() at bufwrite+0x1b8 ufs_direnter() at ufs_direnter+0x768 ufs_mkdir() at ufs_mkdir+0x780 VOP_MKDIR_APV() at VOP_MKDIR_APV+0xb4 kern_mkdir() at kern_mkdir+0x2f0 mkdir() at mkdir+0x10 syscall() at syscall+0x2b4 -- syscall (136, FreeBSD ELF64, mkdir) %o7=3D0x40348b7c -- userland() at 0x406e9aa8 user trace: trap %o7=3D0x40348b7c pc 0x406e9aa8, sp 0x7fdffffcd71 done db> wh 58898 Tracing pid 58898 tid 100726 td 0xfffff800e67bae40 mi_switch() at mi_switch+0x2b0 sleepq_switch() at sleepq_switch+0xf4 sleepq_wait() at sleepq_wait+0x3c msleep() at msleep+0x340 bwait() at bwait+0x48 bufwait() at bufwait+0x34 bufwrite() at bufwrite+0x1b8 ufs_direnter() at ufs_direnter+0x768 ufs_makeinode() at ufs_makeinode+0x450 ufs_create() at ufs_create+0x34 VOP_CREATE_APV() at VOP_CREATE_APV+0xb4 vn_open_cred() at vn_open_cred+0x188 vn_open() at vn_open+0x18 kern_open() at kern_open+0x8c open() at open+0x14 syscall() at syscall+0x2b4 -- syscall (5, FreeBSD ELF64, open) %o7=3D0x40342c94 -- userland() at 0x406f3068 user trace: trap %o7=3D0x40342c94 pc 0x406f3068, sp 0x7fdffffd851 --More-- pc 0x403a2f64, sp 0xc02f1700 db> wh 55967 Tracing pid 55967 tid 100255 td 0xfffff800634dd560 mi_switch() at mi_switch+0x2b0 sleepq_switch() at sleepq_switch+0xf4 sleepq_wait() at sleepq_wait+0x3c msleep() at msleep+0x340 bwait() at bwait+0x48 bufwait() at bufwait+0x34 bufwrite() at bufwrite+0x1b8 ffs_bufwrite() at ffs_bufwrite+0x2e8 ffs_update() at ffs_update+0x2c4 ufs_makeinode() at ufs_makeinode+0x38c ufs_create() at ufs_create+0x34 VOP_CREATE_APV() at VOP_CREATE_APV+0xb4 vn_open_cred() at vn_open_cred+0x188 vn_open() at vn_open+0x18 kern_open() at kern_open+0x8c open() at open+0x14 syscall() at syscall+0x2b4 -- syscall (5, FreeBSD ELF64, open) %o7=3D0x40342c38 -- userland() at 0x406f3068 user trace: trap %o7=3D0x40342c38 --More-- pc 0x406f3068, sp 0x7fdffffd871 pc 0x40398434, sp 0x7fdffffd931 pc 0x101a18, sp 0x7fdffffd9f1 pc 0x101550, sp 0x7fdffffdab1 pc 0x1010d0, sp 0x7fdffffdb71 pc 0x4020add4, sp 0x7fdffffdc31 done db> wh 62499 Tracing pid 62499 tid 100464 td 0xfffff800d2d89c80 mi_switch() at mi_switch+0x2b0 sleepq_switch() at sleepq_switch+0xf4 sleepq_wait() at sleepq_wait+0x3c msleep() at msleep+0x340 bwait() at bwait+0x48 bufwait() at bufwait+0x34 bufwrite() at bufwrite+0x1b8 ufs_direnter() at ufs_direnter+0x768 ufs_mkdir() at ufs_mkdir+0x780 VOP_MKDIR_APV() at VOP_MKDIR_APV+0xb4 kern_mkdir() at kern_mkdir+0x2f0 mkdir() at mkdir+0x10 syscall() at syscall+0x2b4 -- syscall (136, FreeBSD ELF64, mkdir) %o7=3D0x40343230 -- userland() at 0x406f1ba8 user trace: trap %o7=3D0x40343230 pc 0x406f1ba8, sp 0x7fdffffd561 pc 0x1000, sp 0x2003051800000004 db> =08 =08wh 58687 Tracing pid 58687 tid 100445 td 0xfffff800c7ccabe0 --More-- mi_switch() at mi_switch+0x2b0 sleepq_switch() at sleepq_switch+0xf4 sleepq_wait() at sleepq_wait+0x3c msleep() at msleep+0x340 bwait() at bwait+0x48 bufwait() at bufwait+0x34 bufwrite() at bufwrite+0x1b8 ufs_direnter() at ufs_direnter+0x768 ufs_makeinode() at ufs_makeinode+0x450 ufs_create() at ufs_create+0x34 VOP_CREATE_APV() at VOP_CREATE_APV+0xb4 vn_open_cred() at vn_open_cred+0x188 vn_open() at vn_open+0x18 kern_open() at kern_open+0x8c open() at open+0x14 syscall() at syscall+0x2b4 -- syscall (5, FreeBSD ELF64, open) %o7=3D0x40342c38 -- userland() at 0x406f3068 user trace: trap %o7=3D0x40342c38 pc 0x406f3068, sp 0x7fdffffd7c1 --More-- done db> wh 65129 Tracing pid 65129 tid 100680 td 0xfffff800a63fc000 mi_switch() at mi_switch+0x2b0 sleepq_switch() at sleepq_switch+0xf4 sleepq_wait() at sleepq_wait+0x3c msleep() at msleep+0x340 bwait() at bwait+0x48 bufwait() at bufwait+0x34 bufwrite() at bufwrite+0x1b8 ufs_direnter() at ufs_direnter+0x768 ufs_makeinode() at ufs_makeinode+0x450 ufs_create() at ufs_create+0x34 VOP_CREATE_APV() at VOP_CREATE_APV+0xb4 vn_open_cred() at vn_open_cred+0x188 vn_open() at vn_open+0x18 kern_open() at kern_open+0x8c open() at open+0x14 syscall() at syscall+0x2b4 -- syscall (5, FreeBSD ELF64, open) %o7=3D0x40342c38 -- userland() at 0x406f3068 user trace: trap %o7=3D0x40342c38 pc 0x406f3068, sp 0x7fdffffd8e1 --More-- pc 0, sp 0x4400001202 db> wh 65408 Tracing pid 65408 tid 100451 td 0xfffff800c8905c80 mi_switch() at mi_switch+0x2b0 sleepq_switch() at sleepq_switch+0xf4 sleepq_wait() at sleepq_wait+0x3c msleep() at msleep+0x340 bwait() at bwait+0x48 bufwait() at bufwait+0x34 bufwrite() at bufwrite+0x1b8 ufs_direnter() at ufs_direnter+0x768 ufs_makeinode() at ufs_makeinode+0x450 ufs_create() at ufs_create+0x34 VOP_CREATE_APV() at VOP_CREATE_APV+0xb4 vn_open_cred() at vn_open_cred+0x188 vn_open() at vn_open+0x18 kern_open() at kern_open+0x8c open() at open+0x14 syscall() at syscall+0x2b4 -- syscall (5, FreeBSD ELF64, open) %o7=3D0x403499ac -- userland() at 0x406eaf68 user trace: trap %o7=3D0x403499ac pc 0x406eaf68, sp 0x7fdffffd1c1 --More-- done db> wh 58926 Tracing pid 58926 tid 100427 td 0xfffff800d4507c80 mi_switch() at mi_switch+0x2b0 sleepq_switch() at sleepq_switch+0xf4 sleepq_wait() at sleepq_wait+0x3c msleep() at msleep+0x340 bwait() at bwait+0x48 bufwait() at bufwait+0x34 bufwrite() at bufwrite+0x1b8 ffs_bufwrite() at ffs_bufwrite+0x2e8 ffs_update() at ffs_update+0x2c4 ufs_makeinode() at ufs_makeinode+0x38c ufs_create() at ufs_create+0x34 VOP_CREATE_APV() at VOP_CREATE_APV+0xb4 vn_open_cred() at vn_open_cred+0x188 vn_open() at vn_open+0x18 kern_open() at kern_open+0x8c open() at open+0x14 syscall() at syscall+0x2b4 -- syscall (5, FreeBSD ELF64, open) %o7=3D0x40342c20 -- userland() at 0x406f3068 user trace: trap %o7=3D0x40342c20 --More-- pc 0x406f3068, sp 0x7fdffffd841 pc 0, sp 0x215e00 pc 0x5d81a40001000000, sp 0x4510003b4 db> wh 64968 Tracing pid 64968 tid 100313 td 0xfffff800e70f3c80 panic() at panic+0x16c trap() at trap+0x3f0 -- fast data access mmu miss tar=3D0 %o7=3D0xc0162240 -- ufs_remove() at ufs_remove+0xc VOP_REMOVE_APV() at VOP_REMOVE_APV+0xb4 kern_unlink() at kern_unlink+0x174 unlink() at unlink+0xc syscall() at syscall+0x2b4 -- syscall (10, FreeBSD ELF64, unlink) %o7=3D0x101998 -- userland() at 0x403a2f68 user trace: trap %o7=3D0x101998 pc 0x403a2f68, sp 0x7fdffffd9f1 pc 0x101550, sp 0x7fdffffdab1 pc 0x1010d0, sp 0x7fdffffdb71 pc 0x4020add4, sp 0x7fdffffdc31 done db> wh 62865 Tracing pid 62865 tid 100519 td 0xfffff800b0c8e720 mi_switch() at mi_switch+0x2b0 sleepq_switch() at sleepq_switch+0xf4 sleepq_wait() at sleepq_wait+0x3c msleep() at msleep+0x340 bwait() at bwait+0x48 bufwait() at bufwait+0x34 bufwrite() at bufwrite+0x1b8 ffs_bufwrite() at ffs_bufwrite+0x2e8 ffs_update() at ffs_update+0x2c4 ffs_truncate() at ffs_truncate+0x9b4 ufs_rmdir() at ufs_rmdir+0x224 VOP_RMDIR_APV() at VOP_RMDIR_APV+0xb4 kern_rmdir() at kern_rmdir+0x1ac rmdir() at rmdir+0xc syscall() at syscall+0x2b4 -- syscall (137, FreeBSD ELF64, rmdir) %o7=3D0x101894 -- userland() at 0x403a1b68 user trace: trap %o7=3D0x101894 pc 0x403a1b68, sp 0x7fdffffdb01 pc 0x3, sp 0x7fdffffe518 --More-- pc 0x3030005348454c4c, sp 0x494f4e3d35303431 db>=20 --4Ckj6UjgE2iN1+kY Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFCb//xWry0BWjoQKURApUaAJ9i9AISozqzPsTn2OvCbLu1LHtGvgCdFSHB R4XFqfbuk/LL1/LaJL5ivEk= =ulNR -----END PGP SIGNATURE----- --4Ckj6UjgE2iN1+kY-- From owner-freebsd-current@FreeBSD.ORG Wed Apr 27 21:26: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 2D18916A4CE for ; Wed, 27 Apr 2005 21:26:42 +0000 (GMT) Received: from mortis.over-yonder.net (adsl-12-42-198.jan.bellsouth.net [65.12.42.198]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6535D43D46 for ; Wed, 27 Apr 2005 21:26:39 +0000 (GMT) (envelope-from fullermd@over-yonder.net) Received: by mortis.over-yonder.net (Postfix, from userid 100) id 1219620F20; Wed, 27 Apr 2005 16:26:38 -0500 (CDT) Date: Wed, 27 Apr 2005 16:26:37 -0500 From: "Matthew D. Fuller" To: Mike Edenfield Message-ID: <20050427212637.GL98718@over-yonder.net> References: <57436.216.177.243.42.1114582155.localmail@webmail.dnswatch.com> <426FDE69.8090909@samsco.org> <426FE1EA.7020900@kutulu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <426FE1EA.7020900@kutulu.org> X-Editor: vi X-OS: FreeBSD User-Agent: Mutt/1.5.9i-fullermd.2 cc: freebsd-current@freebsd.org Subject: Re: boot banner project X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 27 Apr 2005 21:26:42 -0000 On Wed, Apr 27, 2005 at 03:03:06PM -0400 I heard the voice of Mike Edenfield, and lo! it spake thus: > > One possible alternative to an all-out graphics display would be a > 'prettified' text console. I'm thinking of what Gentoo and older RedHat > systems did (haven't used RH in years, dunno if this still applies) > where about 80% of the system log messages are hidden behind a simple > task list: > > Mounting File Systems ... [ok] > Starting xl0 ... [ok] This is something I've always found somewhat ironic, actually. I'm not really sure overall whether I like it or not, but it IS very structured and consistent. The irony is that I find the Linux kernel bootup messages to be an insane mishmash that I can never sort ANYTHING out of, relative to FreeBSD's very neat and structured kernel probes. So maybe an OS is only allowed to be neat in one of the two 8-} -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. From owner-freebsd-current@FreeBSD.ORG Wed Apr 27 21:26: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 E598216A4DF; Wed, 27 Apr 2005 21:26:46 +0000 (GMT) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id ECAC243D5C; Wed, 27 Apr 2005 21:26:45 +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 j3RLUkAO089549; Thu, 28 Apr 2005 00:30:46 +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 72993-01; Thu, 28 Apr 2005 00:26:42 +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 j3RLUhjE089531 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Apr 2005 00:30:43 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.13.3/8.13.3) id j3RLQoYS083819; Thu, 28 Apr 2005 00:26:50 +0300 (EEST) (envelope-from ru) Date: Thu, 28 Apr 2005 00:26:50 +0300 From: Ruslan Ermilov To: Darren Reed Message-ID: <20050427212650.GB53340@ip.net.ua> References: <20050426155608.GF94543@ip.net.ua> <20050427163206.GA7212@hub.freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="p4qYPpj5QlsIQJ0K" Content-Disposition: inline In-Reply-To: <20050427163206.GA7212@hub.freebsd.org> User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new at ip.net.ua cc: Darren Reed cc: current@FreeBSD.org Subject: Re: Patchset to fix ipfilter build breakage X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 27 Apr 2005 21:26:47 -0000 --p4qYPpj5QlsIQJ0K Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Apr 27, 2005 at 04:32:06PM +0000, Darren Reed wrote: > On Tue, Apr 26, 2005 at 06:56:08PM +0300, Ruslan Ermilov wrote: > > - rescue is still broken: the libipf library is a > > culprit -- it has a lot of undefined symbols that > > consumers are expected to provide, thus preventing > > it to be used in rescue. When compiling a rescue > > binary, it fails with the following: > ... >=20 > I've been thinking and discussing this. >=20 > Firstly, we don't need all the tools, just ipf should be ok. >=20 I'll take this as a data point. > So the trick then is to compile all of the libipf .o's into ipf.lo or > link libipf.a into ipf.lo >=20 Linking with libipf.a would mean that we provide the libipf.a library in /usr/lib, which you wanted to avoid. > How's that sound to you? Can you please supply patch to fix that ? O:-) >=20 I can provide a fix tomorrow after a sleep. It shouldn't be too hard to implement (we can easily differentiate when we're building for rescue). Hold on... Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --p4qYPpj5QlsIQJ0K Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFCcAOaqRfpzJluFF4RAmx/AJ9sqvLchBGTyQNVaMWp4x8F0l6bMACfWubs KPKQ5WZg+qLzeiCm3qEq5zg= =4bD0 -----END PGP SIGNATURE----- --p4qYPpj5QlsIQJ0K-- From owner-freebsd-current@FreeBSD.ORG Wed Apr 27 21:28: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 629F916A4CE for ; Wed, 27 Apr 2005 21:28:50 +0000 (GMT) Received: from orb.pobox.com (orb.pobox.com [207.8.226.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2C72A43D41 for ; Wed, 27 Apr 2005 21:28:50 +0000 (GMT) (envelope-from discussion-lists@linnet.org) Received: from orb (localhost [127.0.0.1]) by orb.pobox.com (Postfix) with ESMTP id D23C97D9; Wed, 27 Apr 2005 17:28:46 -0400 (EDT) Received: from thinkdog.local.linnet.org (dsl-212-74-113-65.access.uk.tiscali.com [212.74.113.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by orb.sasl.smtp.pobox.com (Postfix) with ESMTP id 89D7C87; Wed, 27 Apr 2005 17:28:45 -0400 (EDT) Received: from lists by thinkdog.local.linnet.org with local (Exim 4.43 (FreeBSD)) id 1DQu5D-000MoF-88; Wed, 27 Apr 2005 22:28:35 +0100 Date: Wed, 27 Apr 2005 22:28:35 +0100 From: Brian Candler To: /dev/null Message-ID: <20050427212835.GA87673@uk.tiscali.com> References: <63349.216.177.243.42.1114575288.localmail@webmail.dnswatch.com> <20050427060414.GA54657@ns2.wananchi.com> <55065.216.177.243.42.1114583234.localmail@webmail.dnswatch.com> <20050427083649.GC6929@ns2.wananchi.com> <61364.216.177.243.42.1114593685.localmail@webmail.dnswatch.com> <84dead7205042706554f32484@mail.gmail.com> <57775.216.177.243.35.1114633009.localmail@webmail.dnswatch.com> <20050427204939.GA796@uk.tiscali.com> <53015.216.177.243.35.1114635611.localmail@webmail.dnswatch.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53015.216.177.243.35.1114635611.localmail@webmail.dnswatch.com> User-Agent: Mutt/1.4.2.1i cc: freebsd-current@freebsd.org Subject: Re: can't build kernel [with CONFIG this time] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 27 Apr 2005 21:28:50 -0000 On Wed, Apr 27, 2005 at 02:00:11PM -0700, /dev/null wrote: > Thank you for your reply. Thanks for the link. > Looks like I have some reading to do. :) > Wish me luck! Good luck :-) I've had the same problem before in the past, and in my case it turned out to be a bad RAM SIMM. It may go unnoticed in normal operation, but a kernel compile (or buildworld) will exercise the system a lot more than when it's idling. Regards, Brian. From owner-freebsd-current@FreeBSD.ORG Wed Apr 27 21:29: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 9A16216A4CE; Wed, 27 Apr 2005 21:29:43 +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 2D3FE43D67; Wed, 27 Apr 2005 21:29:42 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 09C4D513A7; Wed, 27 Apr 2005 14:29:41 -0700 (PDT) Date: Wed, 27 Apr 2005 14:29:40 -0700 From: Kris Kennaway To: amd64@FreeBSD.org, current@FreeBSD.org Message-ID: <20050427212940.GA69185@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="mP3DRpeJDSE+ciuQ" Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Subject: panic: sleepq_broadcast: invalid NULL wait channel X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 27 Apr 2005 21:29:43 -0000 --mP3DRpeJDSE+ciuQ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 6.0 from a couple of days ago, panicked at reboot: Waiting (max 60 seconds) for system process `vnlru' to stop...done Waiting (max 60 seconds) for system process `bufdaemon' to stop...done Waiting (max 60 seconds) for system process `syncer' to stop... Syncing disks, vnodes remaining...6 4 3 1 1 0 0 done All buffers synced. unmount of /dev failed (BUSY) Uptime: 14m9s panic: sleepq_broadcast: invalid NULL wait channel cpuid = 0 KDB: enter: panic [thread pid 5125 tid 100145 ] Stopped at kdb_enter+0x31: leave db> wh Tracing pid 5125 tid 100145 td 0xffffff0045f67980 kdb_enter() at kdb_enter+0x31 panic() at panic+0x1e6 sleepq_broadcast() at sleepq_broadcast+0x41 wakeup() at wakeup+0x23 arcmsr_shutdown() at arcmsr_shutdown+0x19a device_shutdown() at device_shutdown+0x47 bus_generic_shutdown() at bus_generic_shutdown+0x1a device_shutdown() at device_shutdown+0x47 bus_generic_shutdown() at bus_generic_shutdown+0x1a device_shutdown() at device_shutdown+0x47 bus_generic_shutdown() at bus_generic_shutdown+0x1a device_shutdown() at device_shutdown+0x47 bus_generic_shutdown() at bus_generic_shutdown+0x1a device_shutdown() at device_shutdown+0x47 bus_generic_shutdown() at bus_generic_shutdown+0x1a device_shutdown() at device_shutdown+0x47 bus_generic_shutdown() at bus_generic_shutdown+0x1a device_shutdown() at device_shutdown+0x47 bus_generic_shutdown() at bus_generic_shutdown+0x1a acpi_shutdown() at acpi_shutdown+0x31 device_shutdown() at device_shutdown+0x47 bus_generic_shutdown() at bus_generic_shutdown+0x1a device_shutdown() at device_shutdown+0x47 bus_generic_shutdown() at bus_generic_shutdown+0x1a device_shutdown() at device_shutdown+0x47 root_bus_module_handler() at root_bus_module_handler+0xc2 module_shutdown() at module_shutdown+0x42 boot() at boot+0x6a3 reboot() at reboot+0x39 syscall() at syscall+0x320 Xfast_syscall() at Xfast_syscall+0xa8 --- syscall (55, FreeBSD ELF64, reboot), rip = 0x80076abcc, rsp = 0x7fffffffeb08, rbp = 0 --- db> --mP3DRpeJDSE+ciuQ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFCcAREWry0BWjoQKURAisrAJ9uKxv8efZlHMF581/B5/QPCd0WZQCeNhmt LebzDMhPnezAtBzS+mhEKJU= =bGPH -----END PGP SIGNATURE----- --mP3DRpeJDSE+ciuQ-- From owner-freebsd-current@FreeBSD.ORG Wed Apr 27 21:47: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 028DB16A4CE for ; Wed, 27 Apr 2005 21:47:50 +0000 (GMT) Received: from mail-in-04.arcor-online.net (mail-in-04.arcor-online.net [151.189.21.44]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9874443D1F for ; Wed, 27 Apr 2005 21:47:49 +0000 (GMT) (envelope-from lofi@freebsd.org) Received: from lofi.dyndns.org (dsl-213-023-193-017.arcor-ip.net [213.23.193.17]) by mail-in-04.arcor-online.net (Postfix) with ESMTP id 539C2104E81; Wed, 27 Apr 2005 23:47:47 +0200 (CEST) Received: from kiste.my.domain (lofi@kiste.my.domain [192.168.8.4]) (authenticated bits=0) by lofi.dyndns.org (8.13.3/8.13.3) with ESMTP id j3RLliw2075651 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Wed, 27 Apr 2005 23:47:44 +0200 (CEST) (envelope-from lofi@freebsd.org) From: Michael Nottebrock To: freebsd-current@freebsd.org Date: Wed, 27 Apr 2005 23:47:39 +0200 User-Agent: KMail/1.8 References: <57436.216.177.243.42.1114582155.localmail@webmail.dnswatch.com> <426FE1EA.7020900@kutulu.org> <20050427212637.GL98718@over-yonder.net> In-Reply-To: <20050427212637.GL98718@over-yonder.net> X-Face: =Ym$`&q\+S2X$4`X%x%6"L4>Y,$]<":'L%c9"#7#`2tb&E&wsN31on!N\)3BD[g<=?utf-8?q?=2EjnfV=5B=0A=093=23?=>XchLK,o;>bD>c:]^;:>0>vyZ.X[,63GW`&M>}nYnr]-Fp``,[[@lJ!QL|sfW!s)=?utf-8?q?A2!*=0A=09vNkB/=7CL-?=>&QdSbQg X-Virus-Scanned: by amavisd-new cc: "Matthew D. Fuller" Subject: Re: boot banner project X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 27 Apr 2005 21:47:50 -0000 --nextPart2578463.9CGsA4t2qK Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Wednesday, 27. April 2005 23:26, Matthew D. Fuller wrote: > On Wed, Apr 27, 2005 at 03:03:06PM -0400 I heard the voice of > > Mike Edenfield, and lo! it spake thus: > > One possible alternative to an all-out graphics display would be a > > 'prettified' text console. I'm thinking of what Gentoo and older RedHat > > systems did (haven't used RH in years, dunno if this still applies) > > where about 80% of the system log messages are hidden behind a simple > > task list: > > > > Mounting File Systems ... [ok] > > Starting xl0 ... [ok] > > This is something I've always found somewhat ironic, actually. I'm > not really sure overall whether I like it or not, but it IS very > structured and consistent. Yes, it consistently hides (or worse, discards) useful information - be it= =20 status messages, errors or otherwise. Most distros don't bother about the=20 possible return codes of each service in detail either, so every condition= =20 that could occur is reduced to [ok] or [failed]. Even the NT eventlog isn't= =20 that dumb. =2D-=20 ,_, | Michael Nottebrock | lofi@freebsd.org (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org --nextPart2578463.9CGsA4t2qK Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQBCcAh/Xhc68WspdLARAuExAJ4mh0xF/Y9pwXEkfEkdxqcymMrslgCeLtE+ AHeiPLK49UJDoNRsoLrJq1I= =cobL -----END PGP SIGNATURE----- --nextPart2578463.9CGsA4t2qK-- From owner-freebsd-current@FreeBSD.ORG Wed Apr 27 22:31: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 E900116A4CE for ; Wed, 27 Apr 2005 22:31:06 +0000 (GMT) Received: from fast.dnswatch.com (fast.dnswatch.com [216.177.243.43]) by mx1.FreeBSD.org (Postfix) with ESMTP id 722B343D31 for ; Wed, 27 Apr 2005 22:31:06 +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 j3RMV1rt002506 for ; Wed, 27 Apr 2005 15:31:05 -0700 (PDT) (envelope-from null@dnswatch.com) Received: (from www@localhost) by fast.dnswatch.com (8.12.6/8.12.6/Submit) id j3RMUvrZ002505; Wed, 27 Apr 2005 15:30:57 -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; Wed, 27 Apr 2005 15:30:57 -0700 (PDT) Message-ID: <64018.216.177.243.35.1114641057.localmail@webmail.dnswatch.com> In-Reply-To: <20050427212835.GA87673@uk.tiscali.com> References: <63349.216.177.243.42.1114575288.localmail@webmail.dnswatch.com> <20050427060414.GA54657@ns2.wananchi.com> <55065.216.177.243.42.1114583234.localmail@webmail.dnswatch.com> <20050427083649.GC6929@ns2.wananchi.com> <61364.216.177.243.42.1114593685.localmail@webmail.dnswatch.com> <84dead7205042706554f32484@mail.gmail.com> <57775.216.177.243.35.1114633009.localmail@webmail.dnswatch.com> <20050427204939.GA796@uk.tiscali.com> <53015.216.177.243.35.1114635611.localmail@webmail.dnswatch.com> <20050427212835.GA87673@uk.tiscali.com> Date: Wed, 27 Apr 2005 15:30:57 -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: can't build kernel [with CONFIG this time][[[FIXED]]] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 27 Apr 2005 22:31:07 -0000 Greetings, To anyone that was following this, or is interested. The problem turned out to be the fact that the new processor didn't play well with the RAM. A different stick of RAM solved it. :) Thanks to all your help and input! -Chris //////////////////////////////////////////////////// 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 Wed Apr 27 23:16: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 E0C1516A4CE for ; Wed, 27 Apr 2005 23:16:06 +0000 (GMT) Received: from toad.mtbrook.bozemanpass.com (toad.mtbrook.bozemanpass.com [69.145.82.195]) by mx1.FreeBSD.org (Postfix) with ESMTP id AEF2443D53 for ; Wed, 27 Apr 2005 23:16:06 +0000 (GMT) (envelope-from elliot.schlegelmilch@gmail.com) Received: from [69.145.82.223] (unknown [69.145.82.223]) by toad.mtbrook.bozemanpass.com (Postfix) with ESMTP id 90D831102E6; Wed, 27 Apr 2005 16:19:16 -0700 (PDT) Message-ID: <42701D35.6020307@gmail.com> Date: Wed, 27 Apr 2005 17:16:05 -0600 From: Elliot Schlegelmilch User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: /dev/null References: <63349.216.177.243.42.1114575288.localmail@webmail.dnswatch.com> <20050427060414.GA54657@ns2.wananchi.com> <55065.216.177.243.42.1114583234.localmail@webmail.dnswatch.com> <20050427083649.GC6929@ns2.wananchi.com> <61364.216.177.243.42.1114593685.localmail@webmail.dnswatch.com> <84dead7205042706554f32484@mail.gmail.com> <57775.216.177.243.35.1114633009.localmail@webmail.dnswatch.com> <20050427204939.GA796@uk.tiscali.com> <53015.216.177.243.35.1114635611.localmail@webmail.dnswatch.com> <20050427212835.GA87673@uk.tiscali.com> <64018.216.177.243.35.1114641057.localmail@webmail.dnswatch.com> In-Reply-To: <64018.216.177.243.35.1114641057.localmail@webmail.dnswatch.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-current@freebsd.org Subject: Re: can't build kernel [with CONFIG this time][[[FIXED]]] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 27 Apr 2005 23:16:07 -0000 /dev/null wrote: >Greetings, > To anyone that was following this, or is interested. The problem turned out >to be the fact that the new processor didn't play well with the RAM. A >different stick of RAM solved it. :) > > For future reference, if anything things 'weirdly', the memory tester at http://www.memtest86.com/ is one of the first things I try. From owner-freebsd-current@FreeBSD.ORG Wed Apr 27 23:29: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 61FAB16A4CF for ; Wed, 27 Apr 2005 23:29:05 +0000 (GMT) Received: from bloodwood.hunterlink.net.au (smtp-local.hunterlink.net.au [203.12.144.17]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7275D43D2D for ; Wed, 27 Apr 2005 23:29:04 +0000 (GMT) (envelope-from boris@brooknet.com.au) Received: from ppp2BE5.dyn.pacific.net.au (ppp2BE5.dyn.pacific.net.au [61.8.43.229])j3RNSRn0020451; Thu, 28 Apr 2005 09:28:37 +1000 From: Sam Lawrance To: Scott Long In-Reply-To: <426FDE69.8090909@samsco.org> References: <57436.216.177.243.42.1114582155.localmail@webmail.dnswatch.com> <426FDE69.8090909@samsco.org> Content-Type: text/plain Date: Thu, 28 Apr 2005 09:28:57 +1000 Message-Id: <1114644537.45212.74.camel@dirk.no.domain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.2 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit cc: /dev/null cc: freebsd-current@freebsd.org Subject: Re: boot banner project X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 27 Apr 2005 23:29:05 -0000 On Wed, 2005-04-27 at 12:48 -0600, Scott Long wrote: > /dev/null wrote: > > Hello any & all, > > O.K. I feel I must preface this with an acknowledgment that I *know* > > this is a silly project *because* given the *incredibly* long uptimes > > that FreeBSD is known for. >>But<< for those *few* times when FreeBSDers > > see a boot screen, shouldn't it look really nice? Shouldn't also be able > > to reflect the Administrators tastes and personality? Well, this is the > > premise for my attempting this project. But before I start, I want to > > submit an RFC. So consider this an Request for comments. This is an > > attempt to create a Graphical boot screen that initially has the > > following layout: > > (a fixed width font required to view the layout correctly) > > -------------------------------------------------------- > > | some | > > | sort | > > | of | > > | graphic goes in this area | > > |-------------------------------------------------------- > > | boot | > > | | > > | messages | > > | | > > | seen | > > | | > > | here | > > | bla... | > > | bla... | > > | bla... | > > --------------------------------------------------------- > > > > -Chris > > > Is it possible to do this without having to switch to an entirely > raster-based console? Raster consoles (like what SuSE uses) have > been discussed in the past, and the common thinking is that the > loss in reliability and loss in speed is a significant issue to > consider. For a small, non-flashy banner, grab a stack of unused characters and draw a logo into them. Much like what moused does to give us a nice pointer-shaped pointer rather than an ugly block. It'll be 1-bit, but you can pick the foreground and background color in each block from a selection of the most popular console text colours ever :) I think you could allocate the top two rows of text to this and get a nice effect without losing much. And no raster, either. From owner-freebsd-current@FreeBSD.ORG Wed Apr 27 23:42: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 4FFB816A4EE for ; Wed, 27 Apr 2005 23:42:33 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9C1CC43D31 for ; Wed, 27 Apr 2005 23:42: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.3/8.13.3) with ESMTP id j3RNkdvc019872; Wed, 27 Apr 2005 17:46:40 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <4270228B.5070407@samsco.org> Date: Wed, 27 Apr 2005 17:38: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: Sam Lawrance References: <57436.216.177.243.42.1114582155.localmail@webmail.dnswatch.com> <426FDE69.8090909@samsco.org> <1114644537.45212.74.camel@dirk.no.domain> In-Reply-To: <1114644537.45212.74.camel@dirk.no.domain> 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: /dev/null cc: freebsd-current@freebsd.org Subject: Re: boot banner project X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 27 Apr 2005 23:42:33 -0000 Sam Lawrance wrote: > On Wed, 2005-04-27 at 12:48 -0600, Scott Long wrote: > >>/dev/null wrote: >> >>>Hello any & all, >>> O.K. I feel I must preface this with an acknowledgment that I *know* >>>this is a silly project *because* given the *incredibly* long uptimes >>>that FreeBSD is known for. >>But<< for those *few* times when FreeBSDers >>>see a boot screen, shouldn't it look really nice? Shouldn't also be able >>>to reflect the Administrators tastes and personality? Well, this is the >>>premise for my attempting this project. But before I start, I want to >>>submit an RFC. So consider this an Request for comments. This is an >>>attempt to create a Graphical boot screen that initially has the >>>following layout: >>>(a fixed width font required to view the layout correctly) >>> -------------------------------------------------------- >>>| some | >>>| sort | >>>| of | >>>| graphic goes in this area | >>>|-------------------------------------------------------- >>>| boot | >>>| | >>>| messages | >>>| | >>>| seen | >>>| | >>>| here | >>>| bla... | >>>| bla... | >>>| bla... | >>>--------------------------------------------------------- >>> >>>-Chris >> >> >>Is it possible to do this without having to switch to an entirely >>raster-based console? Raster consoles (like what SuSE uses) have >>been discussed in the past, and the common thinking is that the >>loss in reliability and loss in speed is a significant issue to >>consider. > > > For a small, non-flashy banner, grab a stack of unused characters and > draw a logo into them. Much like what moused does to give us a nice > pointer-shaped pointer rather than an ugly block. > > It'll be 1-bit, but you can pick the foreground and background color in > each block from a selection of the most popular console text colours > ever :) > > I think you could allocate the top two rows of text to this and get a > nice effect without losing much. And no raster, either. > > ARGH! Bad memories of the TI-99/4A! Can we at least move up to Atari800 video technology? Scott From owner-freebsd-current@FreeBSD.ORG Wed Apr 27 23:43: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 6276316A4CE; Wed, 27 Apr 2005 23:43:27 +0000 (GMT) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id C5A3743D2F; Wed, 27 Apr 2005 23:43:26 +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 j3RNhQVm069156; Wed, 27 Apr 2005 19:43:26 -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 j3RNhwde067882; Wed, 27 Apr 2005 19:43:58 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 175937306E; Wed, 27 Apr 2005 19:43:26 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050427234326.175937306E@freebsd-current.sentex.ca> Date: Wed, 27 Apr 2005 19:43:26 -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 alpha/alpha 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, 27 Apr 2005 23:43:27 -0000 TB --- 2005-04-27 22:15:01 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-04-27 22:15:01 - starting CURRENT tinderbox run for alpha/alpha TB --- 2005-04-27 22:15:01 - checking out the source tree TB --- 2005-04-27 22:15:01 - cd /home/tinderbox/CURRENT/alpha/alpha TB --- 2005-04-27 22:15:01 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-04-27 22:21:38 - building world (CFLAGS=-O2 -pipe) TB --- 2005-04-27 22:21:38 - cd /home/tinderbox/CURRENT/alpha/alpha/src TB --- 2005-04-27 22:21:38 - /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-27 23:29:05 - building generic kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-04-27 23:29:05 - cd /home/tinderbox/CURRENT/alpha/alpha/src TB --- 2005-04-27 23:29:05 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Wed Apr 27 23:29:06 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 Wed Apr 27 23:42:55 UTC 2005 TB --- 2005-04-27 23:42:55 - generating LINT kernel config TB --- 2005-04-27 23:42:55 - cd /home/tinderbox/CURRENT/alpha/alpha/src/sys/alpha/conf TB --- 2005-04-27 23:42:55 - /usr/bin/make -B LINT TB --- 2005-04-27 23:42:55 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-04-27 23:42:55 - cd /home/tinderbox/CURRENT/alpha/alpha/src TB --- 2005-04-27 23:42:55 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Apr 27 23:42:55 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 [...] rpcgen -h -C /tinderbox/CURRENT/alpha/alpha/src/sys/netatm/spans/spans_xdr.x | grep -v rpc/rpc.h > spans_xdr.h rpcgen -c -C /tinderbox/CURRENT/alpha/alpha/src/sys/netatm/spans/spans_xdr.x | grep -v rpc/rpc.h > spans_xdr.c cc -O2 -pipe -fno-strict-aliasing -mcpu=ev4 -mtune=ev5 -mieee -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/CURRENT/alpha/alpha/src/sys -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/altq -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/pf -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/ngatm -I/tinderbox/CURRENT/alpha/alpha/src/sys/dev/twa -D_KERNEL -include opt_global.h -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -c /tinderbox/CURRENT/alpha/alpha/src/sys/alpha/linux/linux_genassym.c sh /tinderbox/CURRENT/alpha/alpha/src/sys/kern/genassym.sh linux_genassym.o > linux_assym.h uudecode < /usr/share/syscons/fonts/cp850-8x16.fnt && file2c 'static u_char dflt_font_16[16*256] = {' '};' < cp850-8x16 > font.h && uudecode < /usr/share/syscons/fonts/cp850-8x14.fnt && file2c 'static u_char dflt_font_14[14*256] = {' '};' < cp850-8x14 >> font.h && uudecode < /usr/share/syscons/fonts/cp850-8x8.fnt && file2c 'static u_char dflt_font_8[8*256] = {' '};' < cp850-8x8 >> font.h /usr/sbin/kbdcontrol -L jp.106 | sed -e 's/^static keymap_t.* = /static keymap_t key_map = /' -e 's/^static accentmap_t.* = /static accentmap_t accent_map = /' > atkbdmap.h /usr/sbin/kbdcontrol -L it.iso | sed -e 's/^static keymap_t.* = /static keymap_t key_map = /' -e 's/^static accentmap_t.* = /static accentmap_t accent_map = /' > ukbdmap.h make: don't know how to make /tinderbox/CURRENT/alpha/alpha/src/sys/contrib/ipfilter/netinet/ip_fil.c. Stop *** Error code 2 Stop in /tinderbox/CURRENT/alpha/alpha/src. *** Error code 1 Stop in /tinderbox/CURRENT/alpha/alpha/src. TB --- 2005-04-27 23:43:25 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-04-27 23:43:25 - ERROR: failed to build lint kernel TB --- 2005-04-27 23:43:25 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Wed Apr 27 23:49: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 2528E16A4CE for ; Wed, 27 Apr 2005 23:49:54 +0000 (GMT) Received: from bloodwood.hunterlink.net.au (smtp-local.hunterlink.net.au [203.12.144.17]) by mx1.FreeBSD.org (Postfix) with ESMTP id D779743D48 for ; Wed, 27 Apr 2005 23:49:52 +0000 (GMT) (envelope-from boris@brooknet.com.au) Received: from ppp2BE5.dyn.pacific.net.au (ppp2BE5.dyn.pacific.net.au [61.8.43.229])j3RNnEuc001577; Thu, 28 Apr 2005 09:49:15 +1000 From: Sam Lawrance To: Scott Long In-Reply-To: <4270228B.5070407@samsco.org> References: <57436.216.177.243.42.1114582155.localmail@webmail.dnswatch.com> <1114644537.45212.74.camel@dirk.no.domain> <4270228B.5070407@samsco.org> Content-Type: text/plain Date: Thu, 28 Apr 2005 09:49:44 +1000 Message-Id: <1114645784.45212.78.camel@dirk.no.domain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.2 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit cc: /dev/null cc: freebsd-current@freebsd.org Subject: Re: boot banner project X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 27 Apr 2005 23:49:54 -0000 On Wed, 2005-04-27 at 17:38 -0600, Scott Long wrote: > >> > >>Is it possible to do this without having to switch to an entirely > >>raster-based console? Raster consoles (like what SuSE uses) have > >>been discussed in the past, and the common thinking is that the > >>loss in reliability and loss in speed is a significant issue to > >>consider. > > > > > > For a small, non-flashy banner, grab a stack of unused characters and > > draw a logo into them. Much like what moused does to give us a nice > > pointer-shaped pointer rather than an ugly block. > > > > It'll be 1-bit, but you can pick the foreground and background color in > > each block from a selection of the most popular console text colours > > ever :) > > > > I think you could allocate the top two rows of text to this and get a > > nice effect without losing much. And no raster, either. > > > > > > ARGH! Bad memories of the TI-99/4A! Can we at least move up to > Atari800 video technology? > Haha! The TI-99/4A was the first computer I ever got my hands on :D From owner-freebsd-current@FreeBSD.ORG Thu Apr 28 00:09: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 4CCA116A4CE for ; Thu, 28 Apr 2005 00:09:08 +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 C464B43D5F for ; Thu, 28 Apr 2005 00:09:06 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 5E7DA513A7; Wed, 27 Apr 2005 17:09:04 -0700 (PDT) Date: Wed, 27 Apr 2005 17:09:04 -0700 From: Kris Kennaway To: Kris Kennaway Message-ID: <20050428000904.GA4396@xor.obsecurity.org> References: <20050427211113.GA55317@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="pWyiEgJYm5f9v55/" Content-Disposition: inline In-Reply-To: <20050427211113.GA55317@xor.obsecurity.org> User-Agent: Mutt/1.4.2.1i cc: jroberson@chesapeake.net cc: current@FreeBSD.org Subject: Re: panic in ufs_remove() on 6.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 28 Apr 2005 00:09:08 -0000 --pWyiEgJYm5f9v55/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Apr 27, 2005 at 02:11:14PM -0700, Kris Kennaway wrote: > Actually, my last message was not from the e4500 but another SMP > sparc64 running 6.0. Here's the panic from the e4500 overnight. > Unfortunately no ktr is available but I have a dump. >=20 > panic: trap: fast data access mmu miss > cpuid =3D 10 > KDB: enter: panic > [thread pid 64968 tid 100313 ] > Stopped at kdb_enter+0x3c: ta %xcc, 1 > db> wh > Tracing pid 64968 tid 100313 td 0xfffff800e70f3c80 > panic() at panic+0x16c > trap() at trap+0x3f0 > -- fast data access mmu miss tar=3D0 %o7=3D0xc0162240 -- > ufs_remove() at ufs_remove+0xc > VOP_REMOVE_APV() at VOP_REMOVE_APV+0xb4 > kern_unlink() at kern_unlink+0x174 > unlink() at unlink+0xc > syscall() at syscall+0x2b4 > -- syscall (10, FreeBSD ELF64, unlink) %o7=3D0x101998 -- #9 0x00000000c016bc0c in panic (fmt=3D0xc03bc778 "trap: %s") at /usr/src.6= /sys/kern/kern_shutdown.c:537 #10 0x00000000c02f1450 in trap (tf=3D0xf7b9b1c0) at /usr/src.6/sys/sparc64/= sparc64/trap.c:369 #11 0x00000000c02b070c in ufs_remove (ap=3D0xfffff800220a6c78) at /usr/src.= 6/sys/ufs/ufs/ufs_vnops.c:757 #12 0x00000000c0162240 in _mtx_unlock_flags (m=3D0xf7b9b500, opts=3D-106991= 5136, file=3D0xc03a7030 "/usr/src.6/sys/kern/vfs_vnops.c", line=3D919) at /us= r/src.6/sys/kern/kern_mutex.c:299 #13 0x00000000c02f3fb4 in VOP_REMOVE_APV (vop=3D0xc03fcf40, a=3D0xf7b9b500)= at vnode_if.c:1074 #14 0x00000000c01d9c54 in kern_unlink (td=3D0xfffff800e70f3c80, path=3D---C= an't read userspace from dump, or kernel process--- ) at vnode_if.h:563 #15 0x00000000c01d9acc in unlink (td=3D0xfffff800e70f3c80, uap=3D0xf7b9b8c0) at /usr/src.6/sys/kern/vfs_syscalls.c:1622 (kgdb) frame 11 #11 0x00000000c02b070c in ufs_remove (ap=3D0xfffff800220a6c78) at /usr/src.= 6/sys/ufs/ufs/ufs_vnops.c:757 757 ip =3D VTOI(vp); (kgdb) print *vp $2 =3D {v_type =3D 4294965248, v_tag =3D 0xfffff8013e7490a0 "[binary data d= eleted - KK]", v_op =3D 0x0, v_data =3D 0x0,=20 v_mount =3D 0xf7b9b980, v_nmntvnodes =3D {tqe_next =3D 0x61ef, tqe_prev = =3D 0x54450ffc704ddc62}, v_un =3D { vu_mount =3D 0x17e9f910000000a, vu_socket =3D 0x17e9f910000000a, vu_cde= v =3D 0x17e9f910000000a,=20 vu_fifoinfo =3D 0x17e9f910000000a}, v_hashlist =3D {le_next =3D 0x40000= 000bff, le_prev =3D 0xea5cda90}, v_hash =3D 0,=20 v_cache_src =3D {lh_first =3D 0x0}, v_cache_dst =3D {tqh_first =3D 0x0, t= qh_last =3D 0x0}, v_dd =3D 0x0,=20 v_cstart =3D 3931962088, v_lasta =3D 0, v_lastw =3D 0, v_clen =3D 0, v_lo= ck =3D {lk_interlock =3D 0xea5cfb08,=20 lk_flags =3D 0, lk_sharecount =3D 0, lk_waitcount =3D 0, lk_exclusiveco= unt =3D 0, lk_prio =3D 0, lk_wmesg =3D 0x0,=20 lk_timo =3D 0, lk_lockholder =3D 0x0, lk_newlock =3D 0x0}, v_interlock = =3D {mtx_object =3D {lo_class =3D 0x0,=20 lo_name =3D 0xea5cfb48 "", lo_type =3D 0x0, lo_flags =3D 0, lo_list = =3D {tqe_next =3D 0x0, tqe_prev =3D 0xea5cfb68},=20 lo_witness =3D 0x0}, mtx_lock =3D 0, mtx_recurse =3D 0, mtx_acqtime = =3D 3931962248, mtx_filename =3D 0x0,=20 mtx_lineno =3D 0, mtx_contest_holding =3D 0, mtx_contest_locking =3D 0}= , v_vnlock =3D 0xea5cfba8, v_holdcnt =3D 0,=20 v_usecount =3D 0, v_vxthread =3D 0x0, v_iflag =3D 0, v_vflag =3D 39319623= 12, v_writecount =3D 0, v_freelist =3D { tqe_next =3D 0x0, tqe_prev =3D 0x0}, v_bufobj =3D {bo_mtx =3D 0xea5cfbe= 8, bo_clean =3D {bv_hd =3D {tqh_first =3D 0x0,=20 tqh_last =3D 0x0}, bv_root =3D 0x0, bv_cnt =3D 0}, bo_dirty =3D {bv= _hd =3D {tqh_first =3D 0x0, tqh_last =3D 0x0},=20 bv_root =3D 0x0, bv_cnt =3D 0}, bo_numoutput =3D 0, bo_flag =3D 0, bo= _ops =3D 0x0, bo_bsize =3D 0, bo_object =3D 0x0,=20 bo_synclist =3D {le_next =3D 0x0, le_prev =3D 0x0}, bo_private =3D 0xea= 5cfc68, __bo_vnode =3D 0x0}, v_pollinfo =3D 0x0,=20 v_label =3D 0x0} (kgdb) frame 12 #12 0x00000000c0162240 in _mtx_unlock_flags (m=3D0xf7b9b500, opts=3D-106991= 5136, file=3D0xc03a7030 "/usr/src.6/sys/kern/vfs_vnops.c", line=3D919) at /us= r/src.6/sys/kern/kern_mutex.c:299 299 mtx_assert(m, MA_OWNED); (kgdb) frame 13 #13 0x00000000c02f3fb4 in VOP_REMOVE_APV (vop=3D0xc03fcf40, a=3D0xf7b9b500)= at vnode_if.c:1074 1074 if (vop->vop_remove !=3D NULL) (kgdb) frame 14 #14 0x00000000c01d9c54 in kern_unlink (td=3D0xfffff800e70f3c80, path=3D---C= an't read userspace from dump, or kernel process--- ) at vnode_if.h:563 563 vnode_if.h: No such file or directory. in vnode_if.h (kgdb) --pWyiEgJYm5f9v55/ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFCcCmfWry0BWjoQKURAsK+AJ9IPTzV/HmSaxcfJ5PM8IaNPDj2vQCfXXUY /n/KCim/6BtdY1FuWdXxTC4= =WNsC -----END PGP SIGNATURE----- --pWyiEgJYm5f9v55/-- From owner-freebsd-current@FreeBSD.ORG Thu Apr 28 00:22: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 93DFF16A4CE for ; Thu, 28 Apr 2005 00:22:44 +0000 (GMT) Received: from fast.dnswatch.com (fast.dnswatch.com [216.177.243.43]) by mx1.FreeBSD.org (Postfix) with ESMTP id A1DF843D5F for ; Thu, 28 Apr 2005 00:22:43 +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 j3S0MZrt003599; Wed, 27 Apr 2005 17:22:39 -0700 (PDT) (envelope-from null@dnswatch.com) Received: (from www@localhost) by fast.dnswatch.com (8.12.6/8.12.6/Submit) id j3S0MVYF003598; Wed, 27 Apr 2005 17:22:31 -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; Wed, 27 Apr 2005 17:22:31 -0700 (PDT) Message-ID: <58473.216.177.243.35.1114647751.localmail@webmail.dnswatch.com> In-Reply-To: <1114645784.45212.78.camel@dirk.no.domain> References: <57436.216.177.243.42.1114582155.localmail@webmail.dnswatch.com><1114644537.45212.74.camel@dirk.no.domain><4270228B.5070407@samsco.org> <1114645784.45212.78.camel@dirk.no.domain> Date: Wed, 27 Apr 2005 17:22:31 -0700 (PDT) From: "/dev/null" To: "Sam Lawrance" , 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: boot banner project X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 28 Apr 2005 00:22:44 -0000 > On Wed, 2005-04-27 at 17:38 -0600, Scott Long wrote: >> >> >> >>Is it possible to do this without having to switch to an entirely >> >>raster-based console? Raster consoles (like what SuSE uses) have >> >>been discussed in the past, and the common thinking is that the >> >>loss in reliability and loss in speed is a significant issue to >> >>consider. >> > >> > >> > For a small, non-flashy banner, grab a stack of unused characters and >> > draw a logo into them. Much like what moused does to give us a nice >> > pointer-shaped pointer rather than an ugly block. >> > >> > It'll be 1-bit, but you can pick the foreground and background color >> in >> > each block from a selection of the most popular console text colours >> > ever :) >> > >> > I think you could allocate the top two rows of text to this and get a >> > nice effect without losing much. And no raster, either. >> > >> > >> >> ARGH! Bad memories of the TI-99/4A! Can we at least move up to >> Atari800 video technology? >> > > Haha! The TI-99/4A was the first computer I ever got my hands on :D It was a Timex Sinclair for me. :) > > > > > _______________________________________________ > 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 Thu Apr 28 01:04: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 80ECC16A4CE for ; Thu, 28 Apr 2005 01:04:08 +0000 (GMT) Received: from plounts.uits.indiana.edu (plounts.uits.indiana.edu [129.79.1.73]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0D02D43D48 for ; Thu, 28 Apr 2005 01:04:08 +0000 (GMT) (envelope-from dmschei@attglobal.net) Received: from mail-relay.iu.edu (logchain.uits.indiana.edu [129.79.1.77]) j3S13jx5009779; Wed, 27 Apr 2005 20:03:45 -0500 (EST) Received: from [10.0.1.4] (scheidt-rout.canopy.nd.edu [129.74.98.169] (may be forged)) (authenticated bits=0)j3S13jsY012770; Wed, 27 Apr 2005 20:03:45 -0500 (EST) Message-ID: <42703671.8060707@attglobal.net> Date: Wed, 27 Apr 2005 20:03:45 -0500 From: David Scheidt User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050426) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Elliot Schlegelmilch References: <63349.216.177.243.42.1114575288.localmail@webmail.dnswatch.com> <20050427060414.GA54657@ns2.wananchi.com> <55065.216.177.243.42.1114583234.localmail@webmail.dnswatch.com> <20050427083649.GC6929@ns2.wananchi.com> <61364.216.177.243.42.1114593685.localmail@webmail.dnswatch.com> <84dead7205042706554f32484@mail.gmail.com> <57775.216.177.243.35.1114633009.localmail@webmail.dnswatch.com> <20050427204939.GA796@uk.tiscali.com> <53015.216.177.243.35.1114635611.localmail@webmail.dnswatch.com> <20050427212835.GA87673@uk.tiscali.com> <64018.216.177.243.35.1114641057.localmail@webmail.dnswatch.com> <42701D35.6020307@gmail.com> In-Reply-To: <42701D35.6020307@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: /dev/null cc: freebsd-current@freebsd.org Subject: Re: can't build kernel [with CONFIG this time][[[FIXED]]] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 28 Apr 2005 01:04:08 -0000 Elliot Schlegelmilch wrote: > /dev/null wrote: > >> Greetings, >> To anyone that was following this, or is interested. The problem >> turned out >> to be the fact that the new processor didn't play well with the RAM. A >> different stick of RAM solved it. :) >> >> > For future reference, if anything things 'weirdly', the memory tester at > http://www.memtest86.com/ is one of the first things I try. Remember that just because some random piece of software doesn't detect errors doesn't mean they don't exist. Memtest86 has never found an error on anything I've run it on. From owner-freebsd-current@FreeBSD.ORG Thu Apr 28 01:25: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 B0B1416A4CE; Thu, 28 Apr 2005 01:25:43 +0000 (GMT) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 11D9F43D41; Thu, 28 Apr 2005 01:25: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 j3S1PgVo084983; Wed, 27 Apr 2005 21:25:42 -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 j3S1PgkS004483; Wed, 27 Apr 2005 21:25:42 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 03F597306E; Wed, 27 Apr 2005 21:25:41 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050428012541.03F597306E@freebsd-current.sentex.ca> Date: Wed, 27 Apr 2005 21:25:41 -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 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, 28 Apr 2005 01:25:44 -0000 TB --- 2005-04-27 23:43:26 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-04-27 23:43:26 - starting CURRENT tinderbox run for amd64/amd64 TB --- 2005-04-27 23:43:26 - checking out the source tree TB --- 2005-04-27 23:43:26 - cd /home/tinderbox/CURRENT/amd64/amd64 TB --- 2005-04-27 23:43:26 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-04-27 23:50:07 - building world (CFLAGS=-O2 -pipe) TB --- 2005-04-27 23:50:07 - cd /home/tinderbox/CURRENT/amd64/amd64/src TB --- 2005-04-27 23:50:07 - /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-28 01:09:18 - building generic kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-04-28 01:09:18 - cd /home/tinderbox/CURRENT/amd64/amd64/src TB --- 2005-04-28 01:09:18 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Thu Apr 28 01:09:19 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 28 01:25:07 UTC 2005 TB --- 2005-04-28 01:25:07 - generating LINT kernel config TB --- 2005-04-28 01:25:07 - cd /home/tinderbox/CURRENT/amd64/amd64/src/sys/amd64/conf TB --- 2005-04-28 01:25:07 - /usr/bin/make -B LINT TB --- 2005-04-28 01:25:08 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-04-28 01:25:08 - cd /home/tinderbox/CURRENT/amd64/amd64/src TB --- 2005-04-28 01:25:08 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Apr 28 01:25: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 [...] cc -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/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 -I/tinderbox/CURRENT/amd64/amd64/src/sys/dev/twa -D_KERNEL -include opt_global.h -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -c /tinderbox/CURRENT/amd64/amd64/src/sys/amd64/linux32/linux32_genassym.c sh /tinderbox/CURRENT/amd64/amd64/src/sys/kern/genassym.sh linux32_genassym.o > linux32_assym.h cc -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/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 -I/tinderbox/CURRENT/amd64/amd64/src/sys/dev/twa -D_KERNEL -include opt_global.h -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -c /tinderbox/CURRENT/amd64/amd64/src/sys/compat/ia32/ia32_genassym.c env NM='nm' sh /tinderbox/CURRENT/amd64/amd64/src/sys/kern/genassym.sh ia32_genassym.o > ia32_assym.h uudecode < /usr/share/syscons/fonts/cp850-8x16.fnt && file2c 'static u_char dflt_font_16[16*256] = {' '};' < cp850-8x16 > font.h && uudecode < /usr/share/syscons/fonts/cp850-8x14.fnt && file2c 'static u_char dflt_font_14[14*256] = {' '};' < cp850-8x14 >> font.h && uudecode < /usr/share/syscons/fonts/cp850-8x8.fnt && file2c 'static u_char dflt_font_8[8*256] = {' '};' < cp850-8x8 >> font.h /usr/sbin/kbdcontrol -L jp.106 | sed -e 's/^static keymap_t.* = /static keymap_t key_map = /' -e 's/^static accentmap_t.* = /static accentmap_t accent_map = /' > atkbdmap.h /usr/sbin/kbdcontrol -L it.iso | sed -e 's/^static keymap_t.* = /static keymap_t key_map = /' -e 's/^static accentmap_t.* = /static accentmap_t accent_map = /' > ukbdmap.h make: don't know how to make /tinderbox/CURRENT/amd64/amd64/src/sys/contrib/ipfilter/netinet/ip_fil.c. Stop *** Error code 2 Stop in /tinderbox/CURRENT/amd64/amd64/src. *** Error code 1 Stop in /tinderbox/CURRENT/amd64/amd64/src. TB --- 2005-04-28 01:25:41 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-04-28 01:25:41 - ERROR: failed to build lint kernel TB --- 2005-04-28 01:25:41 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Thu Apr 28 02:27: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 D8A0116A4CE for ; Thu, 28 Apr 2005 02:27:31 +0000 (GMT) Received: from fast.dnswatch.com (fast.dnswatch.com [216.177.243.43]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3020F43D45 for ; Thu, 28 Apr 2005 02:27:31 +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 j3S2RPrt004149; Wed, 27 Apr 2005 19:27:29 -0700 (PDT) (envelope-from null@dnswatch.com) Received: (from www@localhost) by fast.dnswatch.com (8.12.6/8.12.6/Submit) id j3S2RL8h004148; Wed, 27 Apr 2005 19:27:21 -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; Wed, 27 Apr 2005 19:27:20 -0700 (PDT) Message-ID: <59642.216.177.243.35.1114655240.localmail@webmail.dnswatch.com> In-Reply-To: <42703671.8060707@attglobal.net> References: <20050427060414.GA54657@ns2.wananchi.com> <55065.216.177.243.42.1114583234.localmail@webmail.dnswatch.com> <20050427083649.GC6929@ns2.wananchi.com> <61364.216.177.243.42.1114593685.localmail@webmail.dnswatch.com> <84dead7205042706554f32484@mail.gmail.com> <57775.216.177.243.35.1114633009.localmail@webmail.dnswatch.com> <20050427204939.GA796@uk.tiscali.com> <53015.216.177.243.35.1114635611.localmail@webmail.dnswatch.com> <20050427212835.GA87673@uk.tiscali.com> <64018.216.177.243.35.1114641057.localmail@webmail.dnswatch.com> <42701D35.6020307@gmail.com> <42703671.8060707@attglobal.net> Date: Wed, 27 Apr 2005 19:27:20 -0700 (PDT) From: "/dev/null" To: freebsd-current@freebsd.org, "David Scheidt" 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: can't build kernel [with CONFIG this time][[[FIXED]]] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 28 Apr 2005 02:27:32 -0000 > Elliot Schlegelmilch wrote: >> /dev/null wrote: >> >>> Greetings, >>> To anyone that was following this, or is interested. The problem >>> turned out >>> to be the fact that the new processor didn't play well with the RAM. A >>> different stick of RAM solved it. :) >>> >>> >> For future reference, if anything things 'weirdly', the memory tester at >> http://www.memtest86.com/ is one of the first things I try. > > Remember that just because some random piece of software doesn't detect > errors doesn't mean they don't exist. Memtest86 has never found an > error on anything I've run it on. > In my case I think it was just "sync" issues between the CPU cache and the RAM. Although it could have been just that this processor drove the RAM stick hard enough to make it fail. No matter, the stick of RAM is working flawlessly in a different box. :) -Chris //////////////////////////////////////////////////// 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 Thu Apr 28 02: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 F331016A4CE for ; Thu, 28 Apr 2005 02:58:17 +0000 (GMT) Received: from smtp1.adl2.internode.on.net (smtp1.adl2.internode.on.net [203.16.214.181]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3D54C43D39 for ; Thu, 28 Apr 2005 02:58:17 +0000 (GMT) (envelope-from smckay@internode.on.net) Received: from dungeon.home (ppp112-89.lns1.bne3.internode.on.net [59.167.112.89])j3S2w53j008252; Thu, 28 Apr 2005 12:28:05 +0930 (CST) Received: from dungeon.home (localhost [127.0.0.1]) by dungeon.home (8.13.1/8.11.6) with ESMTP id j3S2vXEO007344; Thu, 28 Apr 2005 12:57:34 +1000 (EST) (envelope-from mckay) Message-Id: <200504280257.j3S2vXEO007344@dungeon.home> To: current@freebsd.org References: <57436.216.177.243.42.1114582155.localmail@webmail.dnswatch.com> <426F8F21.1010100@gamersimpact.com> <51866.216.177.243.42.1114613062.localmail@webmail.dnswatch.com> <1072.172.16.0.199.1114624239.squirrel@172.16.0.1> In-Reply-To: <1072.172.16.0.199.1114624239.squirrel@172.16.0.1> from "Mike Jakubik" at "Wed, 27 Apr 2005 17:50:39 +0000" Date: Thu, 28 Apr 2005 12:57:33 +1000 From: Stephen McKay cc: Mike Jakubik cc: null@dnswatch.com Subject: Re: boot banner project X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 28 Apr 2005 02:58:18 -0000 On Wednesday, 27th April 2005, Mike Jakubik wrote: >On Wed, April 27, 2005 10:44 am, /dev/null said: > >> With 30+ servers, I do alot of that as well. But it has always bothered >> me for some reason that Linux has always had their flashy boot screens. >> While FBSD has not. It was sort of like Linux thumbing its nose at me. >> So, I felt like I'd like to start contributing to FBSD and this seemed >> like an easy place to start. Later, something more advanced (and useful). > >Personally, I prefer the current fbsd boot process over the linux flashy >ones. It's useless bloat, that won't impress any serious audience. Put me in the flashiness hating camp also. I especially dislike the Linux 60Hz super-eye-destroying graphical boot, which I have to go to the trouble of defeating as it is the default. I hope you enjoy coding your new feature, but I also hope it will be easy to permanently disable as graphical booting is a step backwards in my view. Stephen. From owner-freebsd-current@FreeBSD.ORG Thu Apr 28 02:58: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 07D5416A4CE; Thu, 28 Apr 2005 02:58:38 +0000 (GMT) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 934A743D1D; Thu, 28 Apr 2005 02:58: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 j3S2wbFe076482; Wed, 27 Apr 2005 22:58:37 -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 j3S2x9Wm049726; Wed, 27 Apr 2005 22:59:09 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id E1ED67306E; Wed, 27 Apr 2005 22:58:36 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050428025836.E1ED67306E@freebsd-current.sentex.ca> Date: Wed, 27 Apr 2005 22:58:36 -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/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, 28 Apr 2005 02:58:38 -0000 TB --- 2005-04-28 01:25:42 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-04-28 01:25:42 - starting CURRENT tinderbox run for i386/i386 TB --- 2005-04-28 01:25:42 - checking out the source tree TB --- 2005-04-28 01:25:42 - cd /home/tinderbox/CURRENT/i386/i386 TB --- 2005-04-28 01:25:42 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-04-28 01:32:18 - building world (CFLAGS=-O2 -pipe) TB --- 2005-04-28 01:32:18 - cd /home/tinderbox/CURRENT/i386/i386/src TB --- 2005-04-28 01:32:18 - /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-28 02:39:27 - building generic kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-04-28 02:39:27 - cd /home/tinderbox/CURRENT/i386/i386/src TB --- 2005-04-28 02:39:27 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Thu Apr 28 02:39:27 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 28 02:57:55 UTC 2005 TB --- 2005-04-28 02:57:55 - generating LINT kernel config TB --- 2005-04-28 02:57:55 - cd /home/tinderbox/CURRENT/i386/i386/src/sys/i386/conf TB --- 2005-04-28 02:57:55 - /usr/bin/make -B LINT TB --- 2005-04-28 02:57:55 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-04-28 02:57:55 - cd /home/tinderbox/CURRENT/i386/i386/src TB --- 2005-04-28 02:57:55 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Apr 28 02:57:55 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 [...] /usr/sbin/kbdcontrol -L it.iso | sed -e 's/^static keymap_t.* = /static keymap_t key_map = /' -e 's/^static accentmap_t.* = /static accentmap_t accent_map = /' > ukbdmap.h cp /tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath/public/i386-elf.opt_ah.h opt_ah.h /home/tinderbox/CURRENT/i386/i386/obj/tinderbox/CURRENT/i386/i386/src/make.i386/make -f /tinderbox/CURRENT/i386/i386/src/sys/i386/acpica/Makefile MAKESRCPATH=/tinderbox/CURRENT/i386/i386/src/sys/i386/acpica cc -O2 -pipe -I. -I@ -c /tinderbox/CURRENT/i386/i386/src/sys/i386/acpica/acpi_wakecode.S objcopy -S -O binary acpi_wakecode.o acpi_wakecode.bin sh /tinderbox/CURRENT/i386/i386/src/sys/i386/acpica/genwakecode.sh > acpi_wakecode.h Warning: Object directory not changed from original /tinderbox/CURRENT/i386/i386/obj/tinderbox/CURRENT/i386/i386/src/sys/LINT make: don't know how to make /tinderbox/CURRENT/i386/i386/src/sys/contrib/ipfilter/netinet/ip_fil.c. Stop *** Error code 2 Stop in /tinderbox/CURRENT/i386/i386/src. *** Error code 1 Stop in /tinderbox/CURRENT/i386/i386/src. TB --- 2005-04-28 02:58:36 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-04-28 02:58:36 - ERROR: failed to build lint kernel TB --- 2005-04-28 02:58:36 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Thu Apr 28 03:08: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 131F016A4CE for ; Thu, 28 Apr 2005 03:08:08 +0000 (GMT) Received: from smtp1.adl2.internode.on.net (smtp1.adl2.internode.on.net [203.16.214.181]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4915043D4C for ; Thu, 28 Apr 2005 03:08:07 +0000 (GMT) (envelope-from smckay@internode.on.net) Received: from dungeon.home (ppp112-89.lns1.bne3.internode.on.net [59.167.112.89])j3S3853j012848; Thu, 28 Apr 2005 12:38:05 +0930 (CST) Received: from dungeon.home (localhost [127.0.0.1]) by dungeon.home (8.13.1/8.11.6) with ESMTP id j3S37BIh007502; Thu, 28 Apr 2005 13:07:11 +1000 (EST) (envelope-from mckay) Message-Id: <200504280307.j3S37BIh007502@dungeon.home> To: Mike Edenfield References: <57436.216.177.243.42.1114582155.localmail@webmail.dnswatch.com> <426FDE69.8090909@samsco.org> <426FE1EA.7020900@kutulu.org> In-Reply-To: <426FE1EA.7020900@kutulu.org> from Mike Edenfield at "Wed, 27 Apr 2005 19:03:06 +0000" Date: Thu, 28 Apr 2005 13:07:11 +1000 From: Stephen McKay cc: freebsd-current@freebsd.org cc: Stephen McKay Subject: Re: boot banner project X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 28 Apr 2005 03:08:08 -0000 On Wednesday, 27th April 2005, Mike Edenfield wrote: >One possible alternative to an all-out graphics display would be a >'prettified' text console. I'm thinking of what Gentoo and older RedHat >systems did (haven't used RH in years, dunno if this still applies) >where about 80% of the system log messages are hidden behind a simple >task list: > >Mounting File Systems ... [ok] >Starting xl0 ... [ok] > >etc. With, of course, the obligatory cyan, magenta, and bright green >colors. Interesting. I always found this aspect of Linux very annoying and certainly no advance over what FreeBSD provides already. Linux puts out at least as much verbiage as FreeBSD but in a less readable form. >There's definitely a different boot-message requirement between a headless >server, headed (?) server, novice user desktop, advanced user desktop, >etc. Definitely? I don't see the distinction you draw between these categories. At the very most, for a casual user you could cover up the booting phase with a picture of Beastie. The rest is fine. Stephen. From owner-freebsd-current@FreeBSD.ORG Thu Apr 28 03:49: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 AAAF516A4CE for ; Thu, 28 Apr 2005 03:49:17 +0000 (GMT) Received: from fast.dnswatch.com (fast.dnswatch.com [216.177.243.43]) by mx1.FreeBSD.org (Postfix) with ESMTP id DC8EA43D2F for ; Thu, 28 Apr 2005 03:49:16 +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 j3S3n1rt004637; Wed, 27 Apr 2005 20:49:16 -0700 (PDT) (envelope-from null@dnswatch.com) Received: (from www@localhost) by fast.dnswatch.com (8.12.6/8.12.6/Submit) id j3S3n0o7004636; Wed, 27 Apr 2005 20:49:00 -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; Wed, 27 Apr 2005 20:48:59 -0700 (PDT) Message-ID: <64691.216.177.243.35.1114660139.localmail@webmail.dnswatch.com> In-Reply-To: <200504280257.j3S2vXEO007344@dungeon.home> References: <57436.216.177.243.42.1114582155.localmail@webmail.dnswatch.com><426F8F21.1010100@gamersimpact.com><51866.216.177.243.42.1114613062.localmail@webmail.dnswatch.com><1072.172.16.0.199.1114624239.squirrel@172.16.0.1> <200504280257.j3S2vXEO007344@dungeon.home> Date: Wed, 27 Apr 2005 20:48:59 -0700 (PDT) From: "/dev/null" To: "Stephen McKay" , 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: boot banner project X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 28 Apr 2005 03:49:17 -0000 > On Wednesday, 27th April 2005, Mike Jakubik wrote: > >>On Wed, April 27, 2005 10:44 am, /dev/null said: >> >>> With 30+ servers, I do alot of that as well. But it has always bothered >>> me for some reason that Linux has always had their flashy boot screens. >>> While FBSD has not. It was sort of like Linux thumbing its nose at me. >>> So, I felt like I'd like to start contributing to FBSD and this seemed >>> like an easy place to start. Later, something more advanced (and >>> useful). >> >>Personally, I prefer the current fbsd boot process over the linux flashy >>ones. It's useless bloat, that won't impress any serious audience. > > Put me in the flashiness hating camp also. I especially dislike the > Linux 60Hz super-eye-destroying graphical boot, which I have to go to the > trouble of defeating as it is the default. > > I hope you enjoy coding your new feature, but I also hope it will be easy > to permanently disable as graphical booting is a step backwards in my > view. Hey, this is an RFC and this is what it's all about. Appreciate your comment(s). -Chris > > Stephen. > _______________________________________________ > 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 Thu Apr 28 04:35: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 88B0C16A4CE; Thu, 28 Apr 2005 04:35:34 +0000 (GMT) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id DBE3043D60; Thu, 28 Apr 2005 04:35: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 j3S4ZXa5079538; Thu, 28 Apr 2005 00:35: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 j3S4ZXsG048552; Thu, 28 Apr 2005 00:35:33 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id DC14F7306E; Thu, 28 Apr 2005 00:35:32 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050428043532.DC14F7306E@freebsd-current.sentex.ca> Date: Thu, 28 Apr 2005 00:35:32 -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 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, 28 Apr 2005 04:35:34 -0000 TB --- 2005-04-28 02:58:37 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-04-28 02:58:37 - starting CURRENT tinderbox run for i386/pc98 TB --- 2005-04-28 02:58:37 - checking out the source tree TB --- 2005-04-28 02:58:37 - cd /home/tinderbox/CURRENT/i386/pc98 TB --- 2005-04-28 02:58:37 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-04-28 03:05:18 - building world (CFLAGS=-O2 -pipe) TB --- 2005-04-28 03:05:18 - cd /home/tinderbox/CURRENT/i386/pc98/src TB --- 2005-04-28 03:05:18 - /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-28 04:15:03 - building generic kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-04-28 04:15:03 - cd /home/tinderbox/CURRENT/i386/pc98/src TB --- 2005-04-28 04:15:03 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Thu Apr 28 04:15:04 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 28 04:34:27 UTC 2005 TB --- 2005-04-28 04:34:27 - generating LINT kernel config TB --- 2005-04-28 04:34:27 - cd /home/tinderbox/CURRENT/i386/pc98/src/sys/pc98/conf TB --- 2005-04-28 04:34:27 - /usr/bin/make -B LINT TB --- 2005-04-28 04:34:28 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-04-28 04:34:28 - cd /home/tinderbox/CURRENT/i386/pc98/src TB --- 2005-04-28 04:34:28 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Apr 28 04:34:29 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 [...] rpcgen -h -C /tinderbox/CURRENT/i386/pc98/src/sys/netatm/spans/spans_xdr.x | grep -v rpc/rpc.h > spans_xdr.h rpcgen -c -C /tinderbox/CURRENT/i386/pc98/src/sys/netatm/spans/spans_xdr.x | grep -v rpc/rpc.h > spans_xdr.c cc -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/CURRENT/i386/pc98/src/sys -I/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/i386/pc98/src/sys/contrib/altq -I/tinderbox/CURRENT/i386/pc98/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/i386/pc98/src/sys/contrib/pf -I/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/i386/pc98/src/sys/contrib/ngatm -I/tinderbox/CURRENT/i386/pc98/src/sys/dev/twa -D_KERNEL -include opt_global.h -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -ffreestanding -c /tinderbox/CURRENT/i386/pc98/ src/sys/i386/linux/linux_genassym.c sh /tinderbox/CURRENT/i386/pc98/src/sys/kern/genassym.sh linux_genassym.o > linux_assym.h cc -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/CURRENT/i386/pc98/src/sys -I/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/i386/pc98/src/sys/contrib/altq -I/tinderbox/CURRENT/i386/pc98/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/i386/pc98/src/sys/contrib/pf -I/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/i386/pc98/src/sys/contrib/ngatm -I/tinderbox/CURRENT/i386/pc98/src/sys/dev/twa -D_KERNEL -include opt_global.h -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -ffreestanding -c /tinderbox/CURRENT/i386/pc98/ src/sys/i386/svr4/svr4_genassym.c sh /tinderbox/CURRENT/i386/pc98/src/sys/kern/genassym.sh svr4_genassym.o > svr4_assym.h /usr/sbin/kbdcontrol -L it.iso | sed -e 's/^static keymap_t.* = /static keymap_t key_map = /' -e 's/^static accentmap_t.* = /static accentmap_t accent_map = /' > ukbdmap.h make: don't know how to make /tinderbox/CURRENT/i386/pc98/src/sys/contrib/ipfilter/netinet/ip_fil.c. Stop *** Error code 2 Stop in /tinderbox/CURRENT/i386/pc98/src. *** Error code 1 Stop in /tinderbox/CURRENT/i386/pc98/src. TB --- 2005-04-28 04:35:32 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-04-28 04:35:32 - ERROR: failed to build lint kernel TB --- 2005-04-28 04:35:32 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Thu Apr 28 04:45: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 0921B16A4CE for ; Thu, 28 Apr 2005 04:45:24 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id 59EBB43D3F for ; Thu, 28 Apr 2005 04:45:23 +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 j3S4i2UR094166; Wed, 27 Apr 2005 22:44:12 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Wed, 27 Apr 2005 22:44:39 -0600 (MDT) Message-Id: <20050427.224439.91313267.imp@bsdimp.com> To: bms@spc.org From: "M. Warner Losh" In-Reply-To: <20050427113418.GD5585@empiric.icir.org> References: <87ab37ab050425205527cecaf3@mail.gmail.com> <20050427113418.GD5585@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: fierykylin@gmail.com cc: freebsd-current@freebsd.org Subject: Re: when will pci hotplug 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, 28 Apr 2005 04:45:24 -0000 In message: <20050427113418.GD5585@empiric.icir.org> Bruce M Simpson writes: : The thing we haven't worked out how to do just yet is how to divide the : necessary resources in a strictly hierarchical way. I have some ideas on this one... I'll try to implement them, but for -current. I'd also like to get some of the simpler parts of your patches into -current as well. Any objection to my merging some of them in? Warner From owner-freebsd-current@FreeBSD.ORG Thu Apr 28 04:56: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 6ABD416A4CE for ; Thu, 28 Apr 2005 04:56:09 +0000 (GMT) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.203]) by mx1.FreeBSD.org (Postfix) with ESMTP id 27DD643D55 for ; Thu, 28 Apr 2005 04:56:09 +0000 (GMT) (envelope-from fierykylin@gmail.com) Received: by zproxy.gmail.com with SMTP id 40so718005nzk for ; Wed, 27 Apr 2005 21:56:08 -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:mime-version:content-type:content-transfer-encoding:content-disposition; b=VxrS2txI65V+r7Q6HfDNI4MdExhoblNWnZdEpC1L+h23NhARytb0wLz5TY8IJT1objD/vivuKl9iy04J7lPajcAbq5psNZgnahL5ncz9g+ymdStyhD30RnGBkRpemAzScHm3EsYTZ8winfUJdh4MoL5nIN3UORhwhIOCc7K+EBo= Received: by 10.36.82.18 with SMTP id f18mr82501nzb; Wed, 27 Apr 2005 21:56:08 -0700 (PDT) Received: by 10.36.104.6 with HTTP; Wed, 27 Apr 2005 21:56:08 -0700 (PDT) Message-ID: <87ab37ab05042721567f5738e9@mail.gmail.com> Date: Thu, 28 Apr 2005 12:56:08 +0800 From: kylin To: 20050427113418.GD5585@empiric.icir.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline cc: freebsd-current@freebsd.org Subject: idea is good X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: kylin List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2005 04:56:09 -0000 >I have some ideas on this one... I'll try to implement them, >but for-current. I'd also like to get some of the simpler parts >of yourpatches into -current as well. Any objection to my >merging some of them in? where will you start ? on which platform shall you go? for slot is simpler,for pcie is the simplest:) so i wll have a loot at MR BMS's patches can not wait and see=20 --=20 we who r about to die,salute u! From owner-freebsd-current@FreeBSD.ORG Thu Apr 28 05:35: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 F202A16A4CE for ; Thu, 28 Apr 2005 05:35:46 +0000 (GMT) Received: from april.chuckr.org (april.chuckr.org [66.92.151.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id 661FE43D1D for ; Thu, 28 Apr 2005 05:35:46 +0000 (GMT) (envelope-from chuckr@chuckr.org) Received: from [66.92.151.195] (july.chuckr.org [66.92.151.195]) by april.chuckr.org (8.13.1/8.12.11) with ESMTP id j3S5VJO1000962 for ; Thu, 28 Apr 2005 01:31:20 -0400 (EDT) (envelope-from chuckr@chuckr.org) Message-ID: <4270762E.3050508@chuckr.org> Date: Thu, 28 Apr 2005 05:35:42 +0000 From: Chuck Robey User-Agent: Mozilla Thunderbird 1.0 (X11/20050316) X-Accept-Language: en-us, en MIME-Version: 1.0 To: current Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: junk after endif X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 28 Apr 2005 05:35:47 -0000 in making the environment for my new sparc box, I'm building a new buildworld for the sparc, that that's giving me REAMS of useless errors about "junk at the end of the line", you know what it is from watching the error come up from cpp listings...except that these come from make, not from C code... having this come up in the situation I'm in, with zero (besides merely a KERNCONF) in the /etc/make.conf, then having this error come up so often it obscures the real listing is egregiously crazy. So, the fix falls into one of these categories: 1) there is a magic incantation I don't know, and don't have time to hunt down, that kills this warning in make, and I need to know this, but that's not the fix ... the fix is (possibly) to make the default action that this is NOT a warning. 2) I know that many folks like to do this to endif's, but it's an warning in C, and we should tell the folks who like it "tough" and take them out. However it's decided, to squish the warning or to squish the tags, it's unacceptable to leave those semantically useless warnings laying about, hiding real problems. From owner-freebsd-current@FreeBSD.ORG Thu Apr 28 05:52: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 04D3416A4CE for ; Thu, 28 Apr 2005 05:52:23 +0000 (GMT) Received: from mail.sorbs.net (news.sorbs.net [203.15.51.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7C2B543D5C for ; Thu, 28 Apr 2005 05:52:22 +0000 (GMT) (envelope-from matthew@uq.edu.au) Received: from [130.102.152.118] (stealthd.its.uq.edu.au [130.102.152.118]) by nemesis.sorbs.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0IFN000026ZXIK@nemesis.sorbs.net> for FreeBSD-current@FreeBSD.org; Thu, 28 Apr 2005 15:52:46 +1000 (EST) Date: Thu, 28 Apr 2005 15:51:08 +1000 From: Matthew Sullivan In-reply-to: <4270762E.3050508@chuckr.org> To: Chuck Robey Message-id: <427079CC.1070302@uq.edu.au> MIME-version: 1.0 Content-type: multipart/signed; boundary=------------ms040809050604030402080808; micalg=sha1; protocol="application/x-pkcs7-signature" X-Accept-Language: en User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041231 References: <4270762E.3050508@chuckr.org> cc: current Subject: Re: junk after endif X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 28 Apr 2005 05:52:23 -0000 This is a cryptographically signed message in MIME format. --------------ms040809050604030402080808 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Chuck Robey wrote: > in making the environment for my new sparc box, I'm building a new > buildworld for the sparc, that that's giving me REAMS of useless > errors about "junk at the end of the line", you know what it is from > watching the error come up from cpp listings...except that these come > from make, not from C code... having this come up in the situation I'm > in, with zero (besides merely a KERNCONF) in the /etc/make.conf, then > having this error come up so often it obscures the real listing is > egregiously crazy. > > So, the fix falls into one of these categories: > > 1) there is a magic incantation I don't know, and don't have time to > hunt down, that kills this warning in make, and I need to know this, > but that's not the fix ... the fix is (possibly) to make the default > action that this is NOT a warning. > > 2) I know that many folks like to do this to endif's, but it's an > warning in C, and we should tell the folks who like it "tough" and > take them out. > > However it's decided, to squish the warning or to squish the tags, > it's unacceptable to leave those semantically useless warnings laying > about, hiding real problems. > I got them when going from HEAD to RELENG_5_3 ... rm -r /usr/obj fixed it. Regards, -- Matthew Sullivan Specialist Systems Programmer Information Technology Services The University of Queensland --------------ms040809050604030402080808 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIG7DCC A3IwggJaoAMCAQICASowDQYJKoZIhvcNAQEEBQAwgaMxCzAJBgNVBAYTAkFVMRMwEQYDVQQI EwpRdWVlbnNsYW5kMREwDwYDVQQHEwhCcmlzYmFuZTElMCMGA1UEChMcVGhlIFVuaXZlcnNp dHkgb2YgUXVlZW5zbGFuZDEoMCYGA1UECxMfSW5mb3JtYXRpb24gVGVjaG5vbG9neSBTZXJ2 aWNlczEbMBkGA1UEAxMSQ2VydGlmaWNhdGUgU2VydmVyMB4XDTA0MDEyMTIzMzYyMVoXDTA2 MDEyMTIzMzYyMVowgbIxCzAJBgNVBAYTAkFVMSUwIwYDVQQKExxUaGUgVW5pdmVyc2l0eSBv ZiBRdWVlbnNsYW5kMScwJQYDVQQLEx5JbmZvcm1hdGlvbiBUZWNub2xvZ3kgU2VydmljZXMx FjAUBgoJkiaJk/IsZAEBEwZjY21hdHQxGTAXBgNVBAMTEE1hdHRoZXcgU3VsbGl2YW4xIDAe BgkqhkiG9w0BCQEWEW1hdHRoZXdAdXEuZWR1LmF1MFwwDQYJKoZIhvcNAQEBBQADSwAwSAJB AJsUfrw/QUqKIzDverWc2F4GFFRZmIeO+bAl+7BM6x/9frMzOtygx4QGb4oQwtOE8Sda1aIs v+yJF3Di9EuUyvMCAwEAAaNoMGYwDgYDVR0PAQH/BAQDAgXgMBEGCWCGSAGG+EIBAQQEAwIF oDAfBgNVHSMEGDAWgBQmqtoyueiWTYZBinvsnzeOWLtUuzAgBgNVHREEGTAXgRVtYXR0aGV3 QGl0cy51cS5lZHUuYXUwDQYJKoZIhvcNAQEEBQADggEBAF2gZrkqZsZlHd4K/+yBN6qrpD61 hctDf7/Eg4jk6DMknEs6nvHMFUMZ4SXvkqPLnHBygTARKAs7qBSLd7mUUBOOQEgk6ovQVY6S 1CDSt3P9O6wjG0K1igtk8v6u7lkQ8p2STXqrOePVINdaucUgBO/IpeUtt9ATl1qvPTWyM/fz oUZsIKeYjNQVEQsuimrZjdbIAFxdl1fggSngUv64wBn8wCssGrPZIZA2lpBBEW1wejoWrDOH IIr+SspGd0i8MovDTMRSvgTERLki17FU/ANilcrSXiODKeIvpXhnQqVScnsoMSZmBmN2QIoG SnBjNK5mYxx5E3v20VOwtP1hVdEwggNyMIICWqADAgECAgEqMA0GCSqGSIb3DQEBBAUAMIGj MQswCQYDVQQGEwJBVTETMBEGA1UECBMKUXVlZW5zbGFuZDERMA8GA1UEBxMIQnJpc2JhbmUx JTAjBgNVBAoTHFRoZSBVbml2ZXJzaXR5IG9mIFF1ZWVuc2xhbmQxKDAmBgNVBAsTH0luZm9y bWF0aW9uIFRlY2hub2xvZ3kgU2VydmljZXMxGzAZBgNVBAMTEkNlcnRpZmljYXRlIFNlcnZl cjAeFw0wNDAxMjEyMzM2MjFaFw0wNjAxMjEyMzM2MjFaMIGyMQswCQYDVQQGEwJBVTElMCMG A1UEChMcVGhlIFVuaXZlcnNpdHkgb2YgUXVlZW5zbGFuZDEnMCUGA1UECxMeSW5mb3JtYXRp b24gVGVjbm9sb2d5IFNlcnZpY2VzMRYwFAYKCZImiZPyLGQBARMGY2NtYXR0MRkwFwYDVQQD ExBNYXR0aGV3IFN1bGxpdmFuMSAwHgYJKoZIhvcNAQkBFhFtYXR0aGV3QHVxLmVkdS5hdTBc MA0GCSqGSIb3DQEBAQUAA0sAMEgCQQCbFH68P0FKiiMw73q1nNheBhRUWZiHjvmwJfuwTOsf /X6zMzrcoMeEBm+KEMLThPEnWtWiLL/siRdw4vRLlMrzAgMBAAGjaDBmMA4GA1UdDwEB/wQE AwIF4DARBglghkgBhvhCAQEEBAMCBaAwHwYDVR0jBBgwFoAUJqraMrnolk2GQYp77J83jli7 VLswIAYDVR0RBBkwF4EVbWF0dGhld0BpdHMudXEuZWR1LmF1MA0GCSqGSIb3DQEBBAUAA4IB AQBdoGa5KmbGZR3eCv/sgTeqq6Q+tYXLQ3+/xIOI5OgzJJxLOp7xzBVDGeEl75Kjy5xwcoEw ESgLO6gUi3e5lFATjkBIJOqL0FWOktQg0rdz/TusIxtCtYoLZPL+ru5ZEPKdkk16qznj1SDX WrnFIATvyKXlLbfQE5darz01sjP386FGbCCnmIzUFRELLopq2Y3WyABcXZdX4IEp4FL+uMAZ /MArLBqz2SGQNpaQQRFtcHo6FqwzhyCK/krKRndIvDKLw0zEUr4ExES5ItexVPwDYpXK0l4j gyniL6V4Z0KlUnJ7KDEmZgZjdkCKBkpwYzSuZmMceRN79tFTsLT9YVXRMYIDQDCCAzwCAQEw gakwgaMxCzAJBgNVBAYTAkFVMRMwEQYDVQQIEwpRdWVlbnNsYW5kMREwDwYDVQQHEwhCcmlz YmFuZTElMCMGA1UEChMcVGhlIFVuaXZlcnNpdHkgb2YgUXVlZW5zbGFuZDEoMCYGA1UECxMf SW5mb3JtYXRpb24gVGVjaG5vbG9neSBTZXJ2aWNlczEbMBkGA1UEAxMSQ2VydGlmaWNhdGUg U2VydmVyAgEqMAkGBSsOAwIaBQCgggItMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ KoZIhvcNAQkFMQ8XDTA1MDQyODA1NTEwOFowIwYJKoZIhvcNAQkEMRYEFHkkY/jmfKkHUid9 8XXwnh8dVumcMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIG6BgkrBgEEAYI3EAQx gawwgakwgaMxCzAJBgNVBAYTAkFVMRMwEQYDVQQIEwpRdWVlbnNsYW5kMREwDwYDVQQHEwhC cmlzYmFuZTElMCMGA1UEChMcVGhlIFVuaXZlcnNpdHkgb2YgUXVlZW5zbGFuZDEoMCYGA1UE CxMfSW5mb3JtYXRpb24gVGVjaG5vbG9neSBTZXJ2aWNlczEbMBkGA1UEAxMSQ2VydGlmaWNh dGUgU2VydmVyAgEqMIG8BgsqhkiG9w0BCRACCzGBrKCBqTCBozELMAkGA1UEBhMCQVUxEzAR BgNVBAgTClF1ZWVuc2xhbmQxETAPBgNVBAcTCEJyaXNiYW5lMSUwIwYDVQQKExxUaGUgVW5p dmVyc2l0eSBvZiBRdWVlbnNsYW5kMSgwJgYDVQQLEx9JbmZvcm1hdGlvbiBUZWNobm9sb2d5 IFNlcnZpY2VzMRswGQYDVQQDExJDZXJ0aWZpY2F0ZSBTZXJ2ZXICASowDQYJKoZIhvcNAQEB BQAEQCycNO9/p4F/OIG4BgUCJbQBKPmI9s8YuMf+66cwkyJbM5DPyneDAYfDY7H+5T7kQbUX XD9ylT9QG/HT2O2Y7/AAAAAAAAA= --------------ms040809050604030402080808-- From owner-freebsd-current@FreeBSD.ORG Thu Apr 28 07:09: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 0C62816A4CE; Thu, 28 Apr 2005 07:09:27 +0000 (GMT) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8C4E943D39; Thu, 28 Apr 2005 07:09:26 +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 j3S79QuQ083556; Thu, 28 Apr 2005 03:09:26 -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 j3S79wXV038803; Thu, 28 Apr 2005 03:09:58 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 6F8F37306E; Thu, 28 Apr 2005 03:09:25 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050428070925.6F8F37306E@freebsd-current.sentex.ca> Date: Thu, 28 Apr 2005 03:09:25 -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: Thu, 28 Apr 2005 07:09:27 -0000 TB --- 2005-04-28 04:35:32 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-04-28 04:35:32 - starting CURRENT tinderbox run for ia64/ia64 TB --- 2005-04-28 04:35:33 - checking out the source tree TB --- 2005-04-28 04:35:33 - cd /home/tinderbox/CURRENT/ia64/ia64 TB --- 2005-04-28 04:35:33 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-04-28 04:52:56 - building world (CFLAGS=-O2 -pipe) TB --- 2005-04-28 04:52:56 - cd /home/tinderbox/CURRENT/ia64/ia64/src TB --- 2005-04-28 04:52:56 - /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-28 06:46:28 - building generic kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-04-28 06:46:28 - cd /home/tinderbox/CURRENT/ia64/ia64/src TB --- 2005-04-28 06:46:28 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Thu Apr 28 06:46:28 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 28 07:08:22 UTC 2005 TB --- 2005-04-28 07:08:22 - generating LINT kernel config TB --- 2005-04-28 07:08:22 - cd /home/tinderbox/CURRENT/ia64/ia64/src/sys/ia64/conf TB --- 2005-04-28 07:08:22 - /usr/bin/make -B LINT TB --- 2005-04-28 07:08:22 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-04-28 07:08:22 - cd /home/tinderbox/CURRENT/ia64/ia64/src TB --- 2005-04-28 07:08:22 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Apr 28 07:08:25 UTC 2005 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies [...] awk -f /tinderbox/CURRENT/ia64/ia64/src/sys/tools/usbdevs2h.awk /tinderbox/CURRENT/ia64/ia64/src/sys/dev/usb/usbdevs -h awk -f /tinderbox/CURRENT/ia64/ia64/src/sys/tools/usbdevs2h.awk /tinderbox/CURRENT/ia64/ia64/src/sys/dev/usb/usbdevs -d rpcgen -h -C /tinderbox/CURRENT/ia64/ia64/src/sys/netatm/spans/spans_xdr.x | grep -v rpc/rpc.h > spans_xdr.h rpcgen -c -C /tinderbox/CURRENT/ia64/ia64/src/sys/netatm/spans/spans_xdr.x | grep -v rpc/rpc.h > spans_xdr.c /usr/sbin/kbdcontrol -L jp.106 | sed -e 's/^static keymap_t.* = /static keymap_t key_map = /' -e 's/^static accentmap_t.* = /static accentmap_t accent_map = /' > atkbdmap.h uudecode < /usr/share/syscons/fonts/cp850-8x16.fnt && file2c 'static u_char dflt_font_16[16*256] = {' '};' < cp850-8x16 > font.h && uudecode < /usr/share/syscons/fonts/cp850-8x14.fnt && file2c 'static u_char dflt_font_14[14*256] = {' '};' < cp850-8x14 >> font.h && uudecode < /usr/share/syscons/fonts/cp850-8x8.fnt && file2c 'static u_char dflt_font_8[8*256] = {' '};' < cp850-8x8 >> font.h /usr/sbin/kbdcontrol -L it.iso | sed -e 's/^static keymap_t.* = /static keymap_t key_map = /' -e 's/^static accentmap_t.* = /static accentmap_t accent_map = /' > ukbdmap.h make: don't know how to make /tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ipfilter/netinet/ip_fil.c. Stop *** Error code 2 Stop in /tinderbox/CURRENT/ia64/ia64/src. *** Error code 1 Stop in /tinderbox/CURRENT/ia64/ia64/src. TB --- 2005-04-28 07:09:25 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-04-28 07:09:25 - ERROR: failed to build lint kernel TB --- 2005-04-28 07:09:25 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Thu Apr 28 08:06: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 F127916A4CE; Thu, 28 Apr 2005 08:06:39 +0000 (GMT) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5119643D2D; Thu, 28 Apr 2005 08:06:38 +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 j3S8Aemf032491; Thu, 28 Apr 2005 11:10:40 +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 96461-08; Thu, 28 Apr 2005 11:06:34 +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 j3S8AdZZ032481 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Apr 2005 11:10:39 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.13.3/8.13.3) id j3S86h2Y090730; Thu, 28 Apr 2005 11:06:43 +0300 (EEST) (envelope-from ru) Date: Thu, 28 Apr 2005 11:06:43 +0300 From: Ruslan Ermilov To: Darren Reed Message-ID: <20050428080643.GA90719@ip.net.ua> References: <20050426155608.GF94543@ip.net.ua> <20050427163206.GA7212@hub.freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="6sX45UoQRIJXqkqR" Content-Disposition: inline In-Reply-To: <20050427163206.GA7212@hub.freebsd.org> User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new at ip.net.ua cc: Darren Reed cc: current@FreeBSD.org Subject: Re: Patchset to fix ipfilter build breakage X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 28 Apr 2005 08:06:40 -0000 --6sX45UoQRIJXqkqR Content-Type: multipart/mixed; boundary="lrZ03NoBR/3+SXJZ" Content-Disposition: inline --lrZ03NoBR/3+SXJZ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Darren, On Wed, Apr 27, 2005 at 04:32:06PM +0000, Darren Reed wrote: > On Tue, Apr 26, 2005 at 06:56:08PM +0300, Ruslan Ermilov wrote: > > - rescue is still broken: the libipf library is a > > culprit -- it has a lot of undefined symbols that > > consumers are expected to provide, thus preventing > > it to be used in rescue. When compiling a rescue > > binary, it fails with the following: > ... >=20 > I've been thinking and discussing this. >=20 > Firstly, we don't need all the tools, just ipf should be ok. >=20 > So the trick then is to compile all of the libipf .o's into ipf.lo or > link libipf.a into ipf.lo >=20 > How's that sound to you? Can you please supply patch to fix that ? O:-) >=20 The attached patch does this, plus the following: - removes NetBSD'ism from makefiles, such as including bsd.own.mk, - fixes one of the compile warnings (easy one), - adds NO_WERROR to sbin/ipf/Makefile.inc as there's still some number of compile warnings, most of them are real bugs on 64-bit platforms (see below), - makes libipf an internal (compile-time only) library, The unfixed warnings (on amd64) are: : Script started on Thu Apr 28 10:24:07 2005 :=20 : -------------------------------------------------------------- : >>> stage 4.4: building everything : -------------------------------------------------------------- : =3D=3D=3D> sbin/ipf (all) : =3D=3D=3D> sbin/ipf/libipf (all) : /usr/src/sbin/ipf/libipf/../../../contrib/ipfilter/lib/printstate.c: In f= unction `printstate': : /usr/src/sbin/ipf/libipf/../../../contrib/ipfilter/lib/printstate.c:71: w= arning: long long int format, long unsigned int arg (arg 2) : /usr/src/sbin/ipf/libipf/../../../contrib/ipfilter/lib/printstate.c:71: w= arning: long long int format, long unsigned int arg (arg 3) : /usr/src/sbin/ipf/libipf/../../../contrib/ipfilter/lib/printstate.c:71: w= arning: long long int format, long unsigned int arg (arg 4) : /usr/src/sbin/ipf/libipf/../../../contrib/ipfilter/lib/printstate.c:71: w= arning: long long int format, long unsigned int arg (arg 5) : /usr/src/sbin/ipf/libipf/../../../contrib/ipfilter/lib/printstate.c:71: w= arning: long long int format, long unsigned int arg (arg 6) : /usr/src/sbin/ipf/libipf/../../../contrib/ipfilter/lib/printstate.c:71: w= arning: long long int format, long unsigned int arg (arg 7) : /usr/src/sbin/ipf/libipf/../../../contrib/ipfilter/lib/printstate.c:71: w= arning: long long int format, long unsigned int arg (arg 8) : /usr/src/sbin/ipf/libipf/../../../contrib/ipfilter/lib/printstate.c:71: w= arning: long long int format, long unsigned int arg (arg 9) Fixing the format specifiers to %qu doesn't work, I don't know if this is a= bug or not that %qu produces a warning when supplied a u_quad_t argument, but I se= e a deprecation warning. I think uint64_t should be used explicitly. : =3D=3D=3D> sbin/ipf/ipf (all) : =3D=3D=3D> sbin/ipf/ipfs (all) : =3D=3D=3D> sbin/ipf/ipfstat (all) : =3D=3D=3D> sbin/ipf/ipftest (all) : /usr/src/sbin/ipf/ipftest/../../../sys/contrib/ipfilter/netinet/ip_frag.c= : In function `fr_ipid_newfrag': : /usr/src/sbin/ipf/ipftest/../../../sys/contrib/ipfilter/netinet/ip_frag.c= :397: warning: cast to pointer from integer of different size : /usr/src/sbin/ipf/ipftest/../../../sys/contrib/ipfilter/netinet/ip_frag.c= : In function `fr_ipid_knownfrag': : /usr/src/sbin/ipf/ipftest/../../../sys/contrib/ipfilter/netinet/ip_frag.c= :582: warning: cast from pointer to integer of different size This should be easy to fix. These same (and only these) warnings also prev= ent the ipf.ko from being compiled on amd64. : =3D=3D=3D> sbin/ipf/ipmon (all) : /usr/src/sbin/ipf/ipmon/../../../contrib/ipfilter/tools/ipmon.c: In funct= ion `print_statelog': : /usr/src/sbin/ipf/ipmon/../../../contrib/ipfilter/tools/ipmon.c:887: warn= ing: long long int format, long unsigned int arg (arg 3) : /usr/src/sbin/ipf/ipmon/../../../contrib/ipfilter/tools/ipmon.c:887: warn= ing: long long int format, long unsigned int arg (arg 4) : /usr/src/sbin/ipf/ipmon/../../../contrib/ipfilter/tools/ipmon.c:887: warn= ing: long long int format, long unsigned int arg (arg 5) : /usr/src/sbin/ipf/ipmon/../../../contrib/ipfilter/tools/ipmon.c:887: warn= ing: long long int format, long unsigned int arg (arg 6) : /usr/src/sbin/ipf/ipmon/../../../contrib/ipfilter/tools/ipmon.c:887: warn= ing: long long int format, long unsigned int arg (arg 7) : /usr/src/sbin/ipf/ipmon/../../../contrib/ipfilter/tools/ipmon.c:887: warn= ing: long long int format, long unsigned int arg (arg 8) : /usr/src/sbin/ipf/ipmon/../../../contrib/ipfilter/tools/ipmon.c:887: warn= ing: long long int format, long unsigned int arg (arg 9) : /usr/src/sbin/ipf/ipmon/../../../contrib/ipfilter/tools/ipmon.c:887: warn= ing: long long int format, long unsigned int arg (arg 10) This is like the above warning. : =3D=3D=3D> sbin/ipf/ipnat (all) : =3D=3D=3D> sbin/ipf/ippool (all) : =3D=3D=3D> sbin/ipf/ipresend (all) :=20 : Script done on Thu Apr 28 10:24:56 2005 Hope this helps, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --lrZ03NoBR/3+SXJZ Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=p Content-Transfer-Encoding: quoted-printable Index: share/mk/sys.mk =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/share/mk/sys.mk,v retrieving revision 1.84 diff -u -r1.84 sys.mk --- share/mk/sys.mk 27 Apr 2005 14:13:55 -0000 1.84 +++ share/mk/sys.mk 28 Apr 2005 06:50:05 -0000 @@ -265,11 +265,6 @@ .include "${__MAKE_CONF}" .endif =20 -# XXX Hack until IPFILTER is buildable again. -.if !defined(WANT_IPFILTER) -NO_IPFILTER=3D -.endif - # Default executable format # XXX hint for bsd.port.mk OBJFORMAT?=3D elf Index: contrib/ipfilter/tools/ippool.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/contrib/ipfilter/tools/ippool.c,v retrieving revision 1.2 diff -u -r1.2 ippool.c --- contrib/ipfilter/tools/ippool.c 25 Apr 2005 18:20:15 -0000 1.2 +++ contrib/ipfilter/tools/ippool.c 28 Apr 2005 07:23:18 -0000 @@ -639,7 +639,7 @@ } =20 } - printf("%u object%s flushed\n", flush.iplf_count, + printf("%zd object%s flushed\n", flush.iplf_count, (flush.iplf_count =3D=3D 1) ? "" : "s"); =20 return 0; Index: sbin/ipf/Makefile.inc =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/sbin/ipf/Makefile.inc,v retrieving revision 1.1 diff -u -r1.1 Makefile.inc --- sbin/ipf/Makefile.inc 25 Apr 2005 18:55:50 -0000 1.1 +++ sbin/ipf/Makefile.inc 28 Apr 2005 07:52:49 -0000 @@ -1,6 +1,6 @@ # $FreeBSD: src/sbin/ipf/Makefile.inc,v 1.1 2005/04/25 18:55:50 darrenr Ex= p $ =20 -.include +NO_WERROR=3D # XXX =20 CFLAGS+=3D -I${.CURDIR}/../../../contrib/ipfilter CFLAGS+=3D -I${.CURDIR}/../../../contrib/ipfilter/tools @@ -8,9 +8,9 @@ CFLAGS+=3D -I${.CURDIR}/../../../sys/contrib/ipfilter CFLAGS+=3D -DSTATETOP -D__UIO_EXPOSE =20 -IPFOBJDIR=3D ${.OBJDIR}/../libipf -DPADD+=3D ${IPFOBJDIR}/libipf.a ${LIBKVM} -LDADD+=3D -L${IPFOBJDIR} -lipf -lkvm +LIBIPF=3D ${.OBJDIR}/../libipf/libipf.a +DPADD+=3D ${LIBIPF} ${LIBKVM} +LDADD+=3D ${LIBIPF} -lkvm =20 CLEANFILES+=3D y.tab.c y.tab.h =20 @@ -19,6 +19,4 @@ ${.CURDIR}/../../../contrib/ipfilter/tools \ ${.CURDIR}/../../../contrib/ipfilter/man =20 -.if exists(${.CURDIR}/../../Makefile.inc) -.include "${.CURDIR}/../../Makefile.inc" -.endif +.include "../Makefile.inc" Index: sbin/ipf/ipf/Makefile =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/sbin/ipf/ipf/Makefile,v retrieving revision 1.1 diff -u -r1.1 Makefile --- sbin/ipf/ipf/Makefile 25 Apr 2005 18:55:50 -0000 1.1 +++ sbin/ipf/ipf/Makefile 28 Apr 2005 07:18:42 -0000 @@ -1,7 +1,5 @@ # $FreeBSD: src/sbin/ipf/ipf/Makefile,v 1.1 2005/04/25 18:55:50 darrenr Ex= p $ =20 -.include # for MKDYNAMICROOT definition - PROG=3D ipf SRCS=3D ipf.c ipfcomp.c ipf_y.c ipf_l.c MAN=3D ipf.8 ipf.4 ipf.5 ipl.4 @@ -14,7 +12,6 @@ CLEANFILES+=3D ipf_l.c ipf_l.h =20 ipf_y.c: ipf_y.y - ${_MKTARGET_CREATE} ${YACC} -d ${.ALLSRC} sed -e 's/yy/ipf_yy/g' \ -e 's/"ipf_y.y"/"..\/tools\/ipf_y.y"/' \ @@ -25,20 +22,18 @@ ipf_y.h: ipf_y.c =20 ipf_l.c: lexer.c - ${_MKTARGET_CREATE} sed -e 's/yy/ipf_yy/g' \ -e 's/y.tab.h/ipf_y.h/' \ -e 's/lexer.h/ipf_l.h/' \ ${.ALLSRC} > ${.TARGET} =20 ipf_l.h: lexer.h - ${_MKTARGET_CREATE} sed -e 's/yy/ipf_yy/g' \ ${.ALLSRC} > ${.TARGET} =20 -BINDIR=3D /sbin -.if defined(NO_DYNAMICROOT) -LDSTATIC?=3D -static +.if defined(RESCUE) +LIBIPF_SRCS!=3D cd ${.CURDIR}/../libipf && ${MAKE} -V SRCS +SRCS+=3D ${LIBIPF_SRCS} .endif =20 .include Index: sbin/ipf/ipftest/Makefile =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/sbin/ipf/ipftest/Makefile,v retrieving revision 1.2 diff -u -r1.2 Makefile --- sbin/ipf/ipftest/Makefile 26 Apr 2005 15:35:50 -0000 1.2 +++ sbin/ipf/ipftest/Makefile 28 Apr 2005 07:53:05 -0000 @@ -1,9 +1,5 @@ # $FreeBSD: src/sbin/ipf/ipftest/Makefile,v 1.2 2005/04/26 15:35:50 darren= r Exp $ =20 -NOGCCERROR=3D # defined - -.include - PROG=3D ipftest SRCS=3D ipftest.c fil.c ip_frag.c ip_state.c ip_nat.c \ ip_proxy.c ip_auth.c ip_htable.c ip_lookup.c \ @@ -30,7 +26,6 @@ CLEANFILES+=3D ippool.tab.c ippool.tab.h =20 ipnat_y.c: ipnat_y.y - ${_MKTARGET_CREATE} ${YACC} -b ipnat -d ${.ALLSRC} sed -e 's/yy/ipnat_yy/g' \ -e 's/y.tab.c/ipnat_y.c/' \ @@ -43,19 +38,16 @@ ipnat_y.h: ipnat_y.c =20 ipnat_l.c: lexer.c - ${_MKTARGET_CREATE} sed -e 's/yy/ipnat_yy/g' \ -e 's/y.tab.h/ipnat_y.h/' \ -e 's/lexer.h/ipnat_l.h/' \ ${.ALLSRC} > ${.TARGET} =20 ipnat_l.h: lexer.h - ${_MKTARGET_CREATE} sed -e 's/yy/ipnat_yy/g' \ ${.ALLSRC} > ${.TARGET} =20 ippool_y.c: ippool_y.y - ${_MKTARGET_CREATE} ${YACC} -b ippool -d ${.ALLSRC} sed -e 's/yy/ippool_yy/g' \ -e 's/"ippool_y.y"/"..\/tools\/ippool_y.y"/' \ @@ -66,19 +58,16 @@ ippool_y.h: ippool_y.c =20 ippool_l.c: lexer.c - ${_MKTARGET_CREATE} sed -e 's/yy/ippool_yy/g' \ -e 's/y.tab.h/ippool_y.h/' \ -e 's/lexer.h/ippool_l.h/' \ ${.ALLSRC} > ${.TARGET} =20 ippool_l.h: lexer.h - ${_MKTARGET_CREATE} sed -e 's/yy/ippool_yy/g' \ ${.ALLSRC} > ${.TARGET} =20 ipf_y.c: ipf_y.y - ${_MKTARGET_CREATE} ${YACC} -b ipf -d ${.ALLSRC} sed -e 's/yy/ipf_yy/g' \ -e 's/"ipf_y.y"/"..\/tools\/ipf_y.y"/' \ @@ -89,14 +78,12 @@ ipf_y.h: ipf_y.c =20 ipf_l.c: lexer.c - ${_MKTARGET_CREATE} sed -e 's/yy/ipf_yy/g' \ -e 's/y.tab.h/ipf_y.h/' \ -e 's/lexer.h/ipf_l.h/' \ ${.ALLSRC} > ${.TARGET} =20 ipf_l.h: lexer.h - ${_MKTARGET_CREATE} sed -e 's/yy/ipf_yy/g' \ ${.ALLSRC} > ${.TARGET} =20 Index: sbin/ipf/ipmon/Makefile =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/sbin/ipf/ipmon/Makefile,v retrieving revision 1.1 diff -u -r1.1 Makefile --- sbin/ipf/ipmon/Makefile 25 Apr 2005 18:55:51 -0000 1.1 +++ sbin/ipf/ipmon/Makefile 28 Apr 2005 07:18:46 -0000 @@ -12,7 +12,6 @@ CLEANFILES+=3D ipmon_l.c ipmon_l.h =20 ipmon_y.c: ipmon_y.y - ${_MKTARGET_CREATE} ${YACC} -d ${.ALLSRC} sed -e 's/yy/ipmon_yy/g' \ -e 's/"ipmon_y.y"/"..\/tools\/ipmon_y.y"/' \ @@ -23,14 +22,12 @@ ipmon_y.h: ipmon_y.c =20 ipmon_l.c: lexer.c - ${_MKTARGET_CREATE} sed -e 's/yy/ipmon_yy/g' \ -e 's/y.tab.h/ipmon_y.h/' \ -e 's/lexer.h/ipmon_l.h/' \ ${.ALLSRC} > ${.TARGET} =20 ipmon_l.h: lexer.h - ${_MKTARGET_CREATE} sed -e 's/yy/ipmon_yy/g' \ ${.ALLSRC} > ${.TARGET} =20 Index: sbin/ipf/ipnat/Makefile =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/sbin/ipf/ipnat/Makefile,v retrieving revision 1.1 diff -u -r1.1 Makefile --- sbin/ipf/ipnat/Makefile 25 Apr 2005 18:55:51 -0000 1.1 +++ sbin/ipf/ipnat/Makefile 26 Apr 2005 14:52:06 -0000 @@ -12,7 +12,6 @@ CLEANFILES+=3D ipnat_l.c ipnat_l.h =20 ipnat_y.c: ipnat_y.y - ${_MKTARGET_CREATE} ${YACC} -d ${.ALLSRC} sed -e 's/yy/ipnat_yy/g' \ -e 's/y.tab.c/ipnat_y.c/' \ @@ -25,14 +24,12 @@ ipnat_y.h: ipnat_y.c =20 ipnat_l.c: lexer.c - ${_MKTARGET_CREATE} sed -e 's/yy/ipnat_yy/g' \ -e 's/y.tab.h/ipnat_y.h/' \ -e 's/lexer.h/ipnat_l.h/' \ ${.ALLSRC} > ${.TARGET} =20 ipnat_l.h: lexer.h - ${_MKTARGET_CREATE} sed -e 's/yy/ipnat_yy/g' \ ${.ALLSRC} > ${.TARGET} =20 Index: sbin/ipf/ippool/Makefile =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/sbin/ipf/ippool/Makefile,v retrieving revision 1.1 diff -u -r1.1 Makefile --- sbin/ipf/ippool/Makefile 25 Apr 2005 18:55:51 -0000 1.1 +++ sbin/ipf/ippool/Makefile 28 Apr 2005 07:18:48 -0000 @@ -11,7 +11,6 @@ CLEANFILES+=3D ippool_l.c ippool_l.h =20 ippool_y.c: ippool_y.y - ${_MKTARGET_CREATE} ${YACC} -d ${.ALLSRC} sed -e 's/yy/ippool_yy/g' \ -e 's/"ippool_y.y"/"..\/tools\/ippool_y.y"/' \ @@ -22,14 +21,12 @@ ippool_y.h: ippool_y.c =20 ippool_l.c: lexer.c - ${_MKTARGET_CREATE} sed -e 's/yy/ippool_yy/g' \ -e 's/y.tab.h/ippool_y.h/' \ -e 's/lexer.h/ippool_l.h/' \ ${.ALLSRC} > ${.TARGET} =20 ippool_l.h: lexer.h - ${_MKTARGET_CREATE} sed -e 's/yy/ippool_yy/g' \ ${.ALLSRC} > ${.TARGET} =20 Index: sbin/ipf/ipresend/Makefile =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/sbin/ipf/ipresend/Makefile,v retrieving revision 1.1 diff -u -r1.1 Makefile --- sbin/ipf/ipresend/Makefile 25 Apr 2005 18:55:51 -0000 1.1 +++ sbin/ipf/ipresend/Makefile 28 Apr 2005 07:52:26 -0000 @@ -1,7 +1,5 @@ # $FreeBSD: src/sbin/ipf/ipresend/Makefile,v 1.1 2005/04/25 18:55:51 darre= nr Exp $ =20 -.include - PROG=3D ipresend SRCS=3D ipresend.c ip.c resend.c sbpf.c sock.c 44arp.c MAN=3D ipresend.1 Index: sbin/ipf/ipsend/Makefile =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/sbin/ipf/ipsend/Makefile,v retrieving revision 1.1 diff -u -r1.1 Makefile --- sbin/ipf/ipsend/Makefile 25 Apr 2005 18:55:51 -0000 1.1 +++ sbin/ipf/ipsend/Makefile 26 Apr 2005 14:52:13 -0000 @@ -23,7 +23,6 @@ ${NETBSDSRCDIR}/dist/ipf/iplang =20 iplang_y.c: iplang_y.y - ${_MKTARGET_CREATE} ${YACC} -d ${.ALLSRC} mv y.tab.c ${.TARGET} mv y.tab.h ${.TARGET:.c=3D.h} Index: sbin/ipf/libipf/Makefile =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/sbin/ipf/libipf/Makefile,v retrieving revision 1.1 diff -u -r1.1 Makefile --- sbin/ipf/libipf/Makefile 25 Apr 2005 18:55:52 -0000 1.1 +++ sbin/ipf/libipf/Makefile 28 Apr 2005 07:53:22 -0000 @@ -1,11 +1,7 @@ # $FreeBSD: src/sbin/ipf/libipf/Makefile,v 1.1 2005/04/25 18:55:52 darrenr= Exp $ =20 -MKPRIVATELIB=3D yes -USE_SHLIBDIR=3D yes - -NOGCCERROR=3D # defined - LIB=3D ipf +INTERNALLIB=3D =20 SRCS=3D addicmp.c addipopt.c addkeep.c bcopywrap.c binprint.c \ buildopts.c checkrev.c count6bits.c count4bits.c debug.c \ Index: rescue/rescue/Makefile =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/rescue/rescue/Makefile,v retrieving revision 1.42 diff -u -r1.42 Makefile --- rescue/rescue/Makefile 18 Mar 2005 12:55:07 -0000 1.42 +++ rescue/rescue/Makefile 28 Apr 2005 07:08:01 -0000 @@ -124,7 +124,7 @@ .endif =20 .if !defined(NO_IPFILTER) -CRUNCH_PROGS_sbin+=3D ipf ipfs ipfstat ipmon ipnat +CRUNCH_PROGS_sbin+=3D ipf .endif =20 # crunchgen does not like C++ programs; this should be fixed someday @@ -166,6 +166,7 @@ CRUNCH_SRCDIR_fore_dnld=3D $(.CURDIR)/../../sbin/atm/fore_dnld CRUNCH_SRCDIR_ilmid=3D $(.CURDIR)/../../sbin/atm/ilmid CRUNCH_SRCDIR_rtquery=3D $(.CURDIR)/../../sbin/routed/rtquery +CRUNCH_SRCDIR_ipf=3D $(.CURDIR)/../../sbin/ipf/ipf CRUNCH_ALIAS_reboot=3D fastboot halt fasthalt CRUNCH_ALIAS_restore=3D rrestore CRUNCH_ALIAS_dump=3D rdump --lrZ03NoBR/3+SXJZ-- --6sX45UoQRIJXqkqR Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFCcJmTqRfpzJluFF4RAgv8AKCdEh+f9InsQS2CzKvHp9wQAr7iggCaA2ud 02h4+zU0SIrRaGiIARoff+E= =vA6z -----END PGP SIGNATURE----- --6sX45UoQRIJXqkqR-- From owner-freebsd-current@FreeBSD.ORG Thu Apr 28 08:19: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 7E66216A4CE; Thu, 28 Apr 2005 08:19:49 +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 20C9B43D45; Thu, 28 Apr 2005 08:19:49 +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 1DR4FP-0003oy-Rv; Thu, 28 Apr 2005 11:19:47 +0300 X-Mailer: exmh version 2.7.0 06/18/2004 with nmh-1.0.4 To: freebsd-current@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 28 Apr 2005 11:19:47 +0300 From: Danny Braniss Message-ID: cc: freebsd-hackers@freebsd.org Subject: how to set dumpdev X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 28 Apr 2005 08:19:49 -0000 hi, i can't use dumpon, since the kernel is panicking on boot, so tried in loader.conf: dumpdev="/dev/ar0s1b" but getting: db> call doadump Cannot dump. No dump device defined. 0x25 i need this is for current 6.0 thanks, danny From owner-freebsd-current@FreeBSD.ORG Thu Apr 28 08:29: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 3BF5716A4CE for ; Thu, 28 Apr 2005 08:29:44 +0000 (GMT) Received: from mail23.syd.optusnet.com.au (mail23.syd.optusnet.com.au [211.29.133.164]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6534F43D54 for ; Thu, 28 Apr 2005 08:29:43 +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]) j3S8TX1D004309 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 28 Apr 2005 18:29:34 +1000 Received: from cirb503493.alcatel.com.au (localhost.alcatel.com.au [127.0.0.1])j3S8TXXw001655; Thu, 28 Apr 2005 18:29:33 +1000 (EST) (envelope-from pjeremy@cirb503493.alcatel.com.au) Received: (from pjeremy@localhost)j3S8TWna001654; Thu, 28 Apr 2005 18:29:32 +1000 (EST) (envelope-from pjeremy) Date: Thu, 28 Apr 2005 18:29:31 +1000 From: Peter Jeremy To: /dev/null Message-ID: <20050428082931.GA232@cirb503493.alcatel.com.au> References: <61364.216.177.243.42.1114593685.localmail@webmail.dnswatch.com> <84dead7205042706554f32484@mail.gmail.com> <57775.216.177.243.35.1114633009.localmail@webmail.dnswatch.com> <20050427204939.GA796@uk.tiscali.com> <53015.216.177.243.35.1114635611.localmail@webmail.dnswatch.com> <20050427212835.GA87673@uk.tiscali.com> <64018.216.177.243.35.1114641057.localmail@webmail.dnswatch.com> <42701D35.6020307@gmail.com> <42703671.8060707@attglobal.net> <59642.216.177.243.35.1114655240.localmail@webmail.dnswatch.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <59642.216.177.243.35.1114655240.localmail@webmail.dnswatch.com> User-Agent: Mutt/1.4.2i cc: freebsd-current@freebsd.org Subject: Re: can't build kernel [with CONFIG this time][[[FIXED]]] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 28 Apr 2005 08:29:44 -0000 On Wed, 2005-Apr-27 19:27:20 -0700, /dev/null wrote: >In my case I think it was just "sync" issues between the CPU cache and >the RAM. Although it could have been just that this processor drove >the RAM stick hard enough to make it fail. No matter, the stick of RAM is >working flawlessly in a different box. :) Modern hardware is pushed very close to the limits. Maybe the RAM has some pattern sensitivity that just happens to be hit by buildkernel or buildworld. Maybe a combination of marginal bypass capacitors, marginal memory bus drivers means that the logic transition is a few picoseconds longer than desirable if a large number of bits change state simultaneously so that the transition isn't seen by the marginal receiver. -- Peter Jeremy From owner-freebsd-current@FreeBSD.ORG Thu Apr 28 08:47: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 BC2FC16A4CE for ; Thu, 28 Apr 2005 08:47:39 +0000 (GMT) Received: from mailout07.sul.t-online.com (mailout07.sul.t-online.com [194.25.134.83]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2519343D46 for ; Thu, 28 Apr 2005 08:47:39 +0000 (GMT) (envelope-from Alexander@Leidinger.net) Received: from fwd34.aul.t-online.de by mailout07.sul.t-online.com with smtp id 1DR4gL-0000DC-05; Thu, 28 Apr 2005 10:47:37 +0200 Received: from Andro-Beta.Leidinger.net (SmaaDeZcQepIdzyNdIe03pNPSswDYBwEDuAbUsVHgNtPl2VKxBoa8b@[84.128.204.245]) by fwd34.sul.t-online.de with esmtp id 1DR4gB-19O7DE0; Thu, 28 Apr 2005 10:47:27 +0200 Received: from localhost (localhost [127.0.0.1])j3S8lTZN042184; Thu, 28 Apr 2005 10:47:29 +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 ; Thu, 28 Apr 2005 10:47:29 +0200 Message-ID: <20050428104729.rpldz1rkeo8c8cs8@netchild.homeip.net> X-Priority: 3 (Normal) Date: Thu, 28 Apr 2005 10:47:29 +0200 From: Alexander Leidinger To: pfgshield-freebsd@yahoo.com References: <20050427165701.38699.qmail@web51605.mail.yahoo.com> In-Reply-To: <20050427165701.38699.qmail@web51605.mail.yahoo.com> 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: SmaaDeZcQepIdzyNdIe03pNPSswDYBwEDuAbUsVHgNtPl2VKxBoa8b@t-dialin.net X-TOI-MSGID: f17d3d2b-6f5c-418e-9579-4cdc4ed730c3 cc: freebsd-current@freebsd.org Subject: Re: FreeBSD 6 is coming too fast X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 28 Apr 2005 08:47:39 -0000 pfgshield-freebsd@yahoo.com wrote: > > --- Alexander Leidinger wrote: >> pfgshield-freebsd@yahoo.com wrote: >> >> > - Bad press towards the 5.x series. >> >> If it doesn't mentions 5.3 explicitely, it doesn't apply. >> > It was an article that appeared on osnews.com, it mention 5.3 explicitly > evreything I read there turned to be false. That's sad. >> > - phk's axe broke one of my favorite ports and I didn't want to spend >> > another 6 months "fixing" it. >> >> You failed to tell which port you are talking about. >> > Well.. I emailed phk about it and was ignored, the problem was PR'd, and even > when I have an ugly workaround for it, the specific port (x11-toolkits/xview) > was further broken by make changes. I fixed that port before (not much fun), > and while I can accept that things may break, I find the "what I broke is not > my problem" attitude unacceptable. I agree. >> > - I wanted to use XFree86-4 and building it on my own and figuring out the >> > library mess later is not an option. >> >> We still have the XFree86-4 port, and AFAIK it still works (everything else >> is a bug). You just have to set a variable in make.conf to make it the >> default. >> > Well.. while updating from 5.2.1 to 5.3 I esentially had to remove > all packages > and install XFree86-4 (which is not in the ISO). I decided it was easier to > move to 4.11. From 5.2.1 to 4.11 you had to deinstall all packages too. And XF86-4 should ba available as a package, so no time needed to compile it. And the package is smaller than the source too... I think. >> > - Although outdated, the downloadable java support package was available >> > for 4.x only. >> >> It should work on 5.3-release too. At least there was an effort to get it >> working, and AFAIK they succeeded. >> > hmm the diablo-jdk13 port says: > > .if ${OSVERSION} >= 502112 > ECHO_MSG= ${ECHO_CMD} > IGNORE= does not run on FreeBSD >= 5.x > .endif Strange... I thought the libm issue was resolved. The linux JDKs work just fine BTW... Bye, Alexander. -- http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 The days are all empty and the nights are unreal. From owner-freebsd-current@FreeBSD.ORG Thu Apr 28 09:37: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 5105D16A4CE; Thu, 28 Apr 2005 09:37:30 +0000 (GMT) Received: from lexi.siliconlandmark.com (lexi.siliconlandmark.com [209.69.98.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id CC45743D41; Thu, 28 Apr 2005 09:37:29 +0000 (GMT) (envelope-from andy@siliconlandmark.com) Received: from lexi.siliconlandmark.com (localhost [127.0.0.1]) j3S9bHt0077738; Thu, 28 Apr 2005 05:37:17 -0400 (EDT) (envelope-from andy@siliconlandmark.com) Received: from localhost (andy@localhost)j3S9bGd8077735; Thu, 28 Apr 2005 05:37:16 -0400 (EDT) (envelope-from andy@siliconlandmark.com) X-Authentication-Warning: lexi.siliconlandmark.com: andy owned process doing -bs Date: Thu, 28 Apr 2005 05:37:16 -0400 (EDT) From: Andre Guibert de Bruet To: Danny Braniss In-Reply-To: Message-ID: <20050428053528.G59099@lexi.siliconlandmark.com> References: 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.551, required 6, autolearn=not spam, AWL 0.05, BAYES_00 -2.60) X-MailScanner-From: andy@siliconlandmark.com cc: freebsd-hackers@freebsd.org cc: freebsd-current@freebsd.org Subject: Re: how to set dumpdev X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 28 Apr 2005 09:37:30 -0000 On Thu, 28 Apr 2005, Danny Braniss wrote: > i can't use dumpon, since the kernel is panicking on boot, so > tried in loader.conf: > dumpdev="/dev/ar0s1b" > but getting: > db> call doadump > Cannot dump. No dump device defined. > 0x25 > > i need this is for current 6.0 > thanks, > danny > That directive, along with dumpdir, would be set in /etc/rc.conf. Andy | Andre Guibert de Bruet | Enterprise Software Consultant > | Silicon Landmark, LLC. | http://siliconlandmark.com/ > From owner-freebsd-current@FreeBSD.ORG Thu Apr 28 09: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 B9B8C16A4CE for ; Thu, 28 Apr 2005 09:53:12 +0000 (GMT) Received: from mailout04.sul.t-online.com (mailout04.sul.t-online.com [194.25.134.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id D35B743D2F for ; Thu, 28 Apr 2005 09:53:11 +0000 (GMT) (envelope-from Alexander@Leidinger.net) Received: from fwd16.aul.t-online.de by mailout04.sul.t-online.com with smtp id 1DR5hl-0004ah-04; Thu, 28 Apr 2005 11:53:09 +0200 Received: from Andro-Beta.Leidinger.net (ZY7CoaZV8eAtsUbGe7hMgzq9QfW2JenLKiPZocix7nijB6UPU0RSrT@[84.128.204.245]) by fwd16.sul.t-online.de with esmtp id 1DR5hc-1vC9Nw0; Thu, 28 Apr 2005 11:53:00 +0200 Received: from localhost (localhost [127.0.0.1])j3S9qwFu051738; Thu, 28 Apr 2005 11:52:59 +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 ; Thu, 28 Apr 2005 11:52:58 +0200 Message-ID: <20050428115258.rpvu466t68so80w4@netchild.homeip.net> X-Priority: 3 (Normal) Date: Thu, 28 Apr 2005 11:52:58 +0200 From: Alexander Leidinger To: "Matthew D. Fuller" References: <57436.216.177.243.42.1114582155.localmail@webmail.dnswatch.com> <426FDE69.8090909@samsco.org> <426FE1EA.7020900@kutulu.org> <20050427212637.GL98718@over-yonder.net> In-Reply-To: <20050427212637.GL98718@over-yonder.net> 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: ZY7CoaZV8eAtsUbGe7hMgzq9QfW2JenLKiPZocix7nijB6UPU0RSrT@t-dialin.net X-TOI-MSGID: 76ad41ef-95d7-4516-84a7-570f1e79917b cc: freebsd-current@freebsd.org Subject: Re: boot banner project X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 28 Apr 2005 09:53:12 -0000 "Matthew D. Fuller" wrote: >> Mounting File Systems ... [ok] >> Starting xl0 ... [ok] > > This is something I've always found somewhat ironic, actually. I'm > not really sure overall whether I like it or not, but it IS very > structured and consistent. The irony is that I find the Linux kernel > bootup messages to be an insane mishmash that I can never sort > ANYTHING out of, relative to FreeBSD's very neat and structured kernel > probes. So maybe an OS is only allowed to be neat in one of the two > 8-} I think restructuring our userland boot message would be a good start. I'm not talking about the above proposal, even if I think it's nice (but a little bit too terse for me), I'm talking about rethinking the actual (since the new rc system) clutter. The 4.x startup looks structured (it could be improved to be more eye friendly, but the beauty lies in the eye of the beholder), while the 5+ one is neither fish nor meat. It's a mixture of the 4.x one with the "Starting xyz" messages from the new system. Since we don't try to keep the new system diff friendly with the NetBSD source anymore, I think we could change it to fit our needs. Bye, Alexander. -- http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 Big book, big bore. -- Callimachus From owner-freebsd-current@FreeBSD.ORG Thu Apr 28 10:09: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 2DA2116A4CE; Thu, 28 Apr 2005 10:09:18 +0000 (GMT) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id B523343D1D; Thu, 28 Apr 2005 10:09:17 +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 j3SA9HqG099628; Thu, 28 Apr 2005 06:09: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 j3SA9nmw004817; Thu, 28 Apr 2005 06:09:49 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id DF1C07306E; Thu, 28 Apr 2005 06:09:16 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050428100916.DF1C07306E@freebsd-current.sentex.ca> Date: Thu, 28 Apr 2005 06:09:16 -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 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: Thu, 28 Apr 2005 10:09:18 -0000 TB --- 2005-04-28 08:43:43 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-04-28 08:43:43 - starting CURRENT tinderbox run for sparc64/sparc64 TB --- 2005-04-28 08:43:43 - checking out the source tree TB --- 2005-04-28 08:43:43 - cd /home/tinderbox/CURRENT/sparc64/sparc64 TB --- 2005-04-28 08:43:43 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-04-28 08:50:27 - building world (CFLAGS=-O2 -pipe) TB --- 2005-04-28 08:50:27 - cd /home/tinderbox/CURRENT/sparc64/sparc64/src TB --- 2005-04-28 08:50:27 - /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-28 09:56:52 - building generic kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-04-28 09:56:52 - cd /home/tinderbox/CURRENT/sparc64/sparc64/src TB --- 2005-04-28 09:56:52 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Thu Apr 28 09:56:52 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 28 10:08:50 UTC 2005 TB --- 2005-04-28 10:08:50 - generating LINT kernel config TB --- 2005-04-28 10:08:50 - cd /home/tinderbox/CURRENT/sparc64/sparc64/src/sys/sparc64/conf TB --- 2005-04-28 10:08:50 - /usr/bin/make -B LINT TB --- 2005-04-28 10:08:51 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-04-28 10:08:51 - cd /home/tinderbox/CURRENT/sparc64/sparc64/src TB --- 2005-04-28 10:08:51 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Apr 28 10:08:51 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 [...] awk -f /tinderbox/CURRENT/sparc64/sparc64/src/sys/tools/miidevs2h.awk /tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/mii/miidevs awk -f /tinderbox/CURRENT/sparc64/sparc64/src/sys/tools/pccarddevs2h.awk /tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/pccard/pccarddevs awk -f /tinderbox/CURRENT/sparc64/sparc64/src/sys/tools/usbdevs2h.awk /tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/usb/usbdevs -h awk -f /tinderbox/CURRENT/sparc64/sparc64/src/sys/tools/usbdevs2h.awk /tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/usb/usbdevs -d rpcgen -h -C /tinderbox/CURRENT/sparc64/sparc64/src/sys/netatm/spans/spans_xdr.x | grep -v rpc/rpc.h > spans_xdr.h rpcgen -c -C /tinderbox/CURRENT/sparc64/sparc64/src/sys/netatm/spans/spans_xdr.x | grep -v rpc/rpc.h > spans_xdr.c /usr/sbin/kbdcontrol -L it.iso | sed -e 's/^static keymap_t.* = /static keymap_t key_map = /' -e 's/^static accentmap_t.* = /static accentmap_t accent_map = /' > ukbdmap.h make: don't know how to make /tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ipfilter/netinet/ip_fil.c. Stop *** Error code 2 Stop in /tinderbox/CURRENT/sparc64/sparc64/src. *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/src. TB --- 2005-04-28 10:09:16 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-04-28 10:09:16 - ERROR: failed to build lint kernel TB --- 2005-04-28 10:09:16 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Thu Apr 28 10:10: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 7CEC416A4CE for ; Thu, 28 Apr 2005 10:10:10 +0000 (GMT) Received: from postfix4-2.free.fr (postfix4-2.free.fr [213.228.0.176]) by mx1.FreeBSD.org (Postfix) with ESMTP id EED8D43D48 for ; Thu, 28 Apr 2005 10:10:09 +0000 (GMT) (envelope-from thierry@herbelot.com) Received: from herbelot.dyndns.org (bne75-4-82-227-159-103.fbx.proxad.net [82.227.159.103]) by postfix4-2.free.fr (Postfix) with ESMTP id 463B3319239 for ; Thu, 28 Apr 2005 12:10:09 +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 j3SA9sw7006187; Thu, 28 Apr 2005 12:10:00 +0200 (CEST) From: Thierry Herbelot To: freebsd-current@freebsd.org Date: Thu, 28 Apr 2005 12:09:44 +0200 User-Agent: KMail/1.8 References: <20050428053528.G59099@lexi.siliconlandmark.com> In-Reply-To: <20050428053528.G59099@lexi.siliconlandmark.com> 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="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200504281209.46273.thierry@herbelot.com> Subject: Re: how to set dumpdev 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: Thu, 28 Apr 2005 10:10:10 -0000 > On Thu, 28 Apr 2005, Danny Braniss wrote: > > i can't use dumpon, since the kernel is panicking on boot, so Hello, There used to be a "dump" directive in the kernel config file (config root on XXX swap on YYY dump on ZZZ), but I can't find any trace in our kernel or in current config file of NetBSD or OpenBSD (time to resurrect the option ?). In your case, this kind of hardwired configuration knob would certainly be handy (I've looked at the code in dumpon.c : the dump device is selected via an IOCTL and not a loader-tunable sysctl flag : too bad). TfH From owner-freebsd-current@FreeBSD.ORG Thu Apr 28 10:10: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 D8B0E16A4CE for ; Thu, 28 Apr 2005 10:10:38 +0000 (GMT) Received: from smtp816.mail.sc5.yahoo.com (smtp816.mail.sc5.yahoo.com [66.163.170.2]) by mx1.FreeBSD.org (Postfix) with SMTP id 8974F43D39 for ; Thu, 28 Apr 2005 10:10:38 +0000 (GMT) (envelope-from noackjr@alumni.rice.edu) Received: from unknown (HELO optimator.noacks.org) (noacks@swbell.net@70.240.205.64 with login) by smtp816.mail.sc5.yahoo.com with SMTP; 28 Apr 2005 10:10:37 -0000 Received: from localhost (localhost [127.0.0.1]) by optimator.noacks.org (Postfix) with ESMTP id 0B3CD60D2; Thu, 28 Apr 2005 05:10:37 -0500 (CDT) Received: from optimator.noacks.org ([127.0.0.1]) by localhost (optimator.noacks.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 00607-12-4; Thu, 28 Apr 2005 05:10:32 -0500 (CDT) Received: from compgeek.noacks.org (compgeek [192.168.1.10]) by optimator.noacks.org (Postfix) with ESMTP id 803A060D5; Thu, 28 Apr 2005 05:10:32 -0500 (CDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by compgeek.noacks.org (8.13.3/8.13.3) with ESMTP id j3SAAVGf044132; Thu, 28 Apr 2005 05:10:32 -0500 (CDT) (envelope-from noackjr@alumni.rice.edu) Message-ID: <4270B697.1070809@alumni.rice.edu> Date: Thu, 28 Apr 2005 05:10:31 -0500 From: Jonathan Noack User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050406) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alexander Leidinger References: <20050427165701.38699.qmail@web51605.mail.yahoo.com> <20050428104729.rpldz1rkeo8c8cs8@netchild.homeip.net> In-Reply-To: <20050428104729.rpldz1rkeo8c8cs8@netchild.homeip.net> X-Enigmail-Version: 0.91.0.0 OpenPGP: id=991D8195; url=http://www.noacks.org/cert/noackjr.asc Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at noacks.org cc: pfgshield-freebsd@yahoo.com cc: freebsd-current@freebsd.org Subject: Re: FreeBSD 6 is coming too fast X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: noackjr@alumni.rice.edu List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2005 10:10:39 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/28/05 03:47, Alexander Leidinger wrote: > pfgshield-freebsd@yahoo.com wrote: >> --- Alexander Leidinger wrote: >>> pfgshield-freebsd@yahoo.com wrote: >>>> - phk's axe broke one of my favorite ports and I didn't want to >>>> spend another 6 months "fixing" it. >>> >>> You failed to tell which port you are talking about. >> >> Well.. I emailed phk about it and was ignored, the problem was >> PR'd, and even when I have an ugly workaround for it, the specific >> port (x11-toolkits/xview) was further broken by make changes. I >> fixed that port before (not much fun), and while I can accept that >> things may break, I find the "what I broke is not my problem" >> attitude unacceptable. > > I agree. I take it the PR is ports/75416. x11-toolkits/xview does not have a maintainer. Pedro, why don't you take the maintainership? It seems you've already done the work; why not share it? OS development is a very dynamic process; in order to take 2 steps forward we often have to take 1 step back. Working through this requires patience and teamwork. Until you start contributing to the team, you may not receive the attention you desire. In any case, this issue appears to have never been resolved. phk, back in December you said you were investigating these ports (http://lists.freebsd.org/pipermail/freebsd-ports/2004-December/019038.html)? How goes it? >>>> - I wanted to use XFree86-4 and building it on my own and >>>> figuring out the library mess later is not an option. >>> >>> We still have the XFree86-4 port, and AFAIK it still works >>> (everything else is a bug). You just have to set a variable in >>> make.conf to make it the default. >> >> Well.. while updating from 5.2.1 to 5.3 I esentially had to remove >> all packages and install XFree86-4 (which is not in the ISO). I >> decided it was easier to move to 4.11. > > From 5.2.1 to 4.11 you had to deinstall all packages too. And XF86-4 should > ba available as a package, so no time needed to compile it. And the package > is smaller than the source too... I think. Yep, it is completely normal to have to reinstall all ports/packages when updating from 5.2.1 to 5.3. 5.2.1 was not a STABLE release. The ABI was not frozen so compatibility-breaking changes were not unexpected. This was bullet 2 of the "Drawbacks to Early Adoption" section of the "Early Adopter's Guide to FreeBSD 5.2.1-RELEASE" (http://www.freebsd.org/releases/5.2.1R/early-adopter.html#DRAWBACKS). To keep XFree86-4, put "X_WINDOW_SYSTEM=xfree86-4" in /etc/make.conf and everything will automagically use XFree86 instead of Xorg. >>>> - Although outdated, the downloadable java support package was >>>> available for 4.x only. >>> >>> It should work on 5.3-release too. At least there was an effort >>> to get it working, and AFAIK they succeeded. >> >> hmm the diablo-jdk13 port says: >> >> .if ${OSVERSION} >= 502112 >> ECHO_MSG= ${ECHO_CMD} >> IGNORE= does not run on FreeBSD >= 5.x >> .endif > > Strange... I thought the libm issue was resolved. > > The linux JDKs work just fine BTW... I was under the impression that the diablo-jdk13 port was just a tested, binary version of the jdk13 port. Perhaps I am wrong on that. In any case, I'm using both linux and native JDKs in production with no issues. - -- Jonathan Noack | noackjr@alumni.rice.edu | OpenPGP: 0x991D8195 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFCcLaXUFz01pkdgZURApLAAKCDkem6f4WXPRUOConP4567AyXmGgCg24M1 F3yN6JldM+nLaKFeLJdOUqk= =GDI5 -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Thu Apr 28 10:13: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 06FCE16A4CE; Thu, 28 Apr 2005 10:13:04 +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 ADE8343D2F; Thu, 28 Apr 2005 10:13:03 +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 1DR610-0005gJ-RZ; Thu, 28 Apr 2005 13:13:02 +0300 X-Mailer: exmh version 2.7.0 06/18/2004 with nmh-1.0.4 To: Andre Guibert de Bruet In-Reply-To: Message from Andre Guibert de Bruet <20050428053528.G59099@lexi.siliconlandmark.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 28 Apr 2005 13:13:02 +0300 From: Danny Braniss Message-ID: cc: freebsd-hackers@freebsd.org cc: freebsd-current@freebsd.org Subject: Re: how to set dumpdev X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 28 Apr 2005 10:13:04 -0000 > > On Thu, 28 Apr 2005, Danny Braniss wrote: > > > i can't use dumpon, since the kernel is panicking on boot, so > > tried in loader.conf: > > dumpdev="/dev/ar0s1b" > > but getting: > > db> call doadump > > Cannot dump. No dump device defined. > > 0x25 > > > > i need this is for current 6.0 > > thanks, > > danny > > > > That directive, along with dumpdir, would be set in /etc/rc.conf. no cookies, i can't, since the kernel panics before it can call /sbin/init From owner-freebsd-current@FreeBSD.ORG Thu Apr 28 10:18: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 ED71E16A4CE for ; Thu, 28 Apr 2005 10:18:04 +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 A01EA43D3F for ; Thu, 28 Apr 2005 10:18:04 +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 1DR65r-0005l2-Ow; Thu, 28 Apr 2005 13:18:03 +0300 X-Mailer: exmh version 2.7.0 06/18/2004 with nmh-1.0.4 To: thierry@herbelot.com In-Reply-To: Message from Thierry Herbelot <200504281209.46273.thierry@herbelot.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 28 Apr 2005 13:18:03 +0300 From: Danny Braniss Message-ID: cc: freebsd-current@freebsd.org Subject: Re: how to set dumpdev X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 28 Apr 2005 10:18:05 -0000 > > On Thu, 28 Apr 2005, Danny Braniss wrote: > > > i can't use dumpon, since the kernel is panicking on boot, so > > Hello, > > There used to be a "dump" directive in the kernel config file (config root on > XXX swap on YYY dump on ZZZ), but I can't find any trace in our kernel or in > current config file of NetBSD or OpenBSD (time to resurrect the option ?). > > In your case, this kind of hardwired configuration knob would certainly be > handy (I've looked at the code in dumpon.c : the dump device is selected via > an IOCTL and not a loader-tunable sysctl flag : too bad). > > TfH not so quick, i have many different machines sharing the same kernel, so a hardwire option is not good in general. but at the moment anything will do. danny From owner-freebsd-current@FreeBSD.ORG Thu Apr 28 10:29: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 D523F16A4CE; Thu, 28 Apr 2005 10:29:56 +0000 (GMT) Received: from orb.pobox.com (orb.pobox.com [207.8.226.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 909EA43D39; Thu, 28 Apr 2005 10:29:56 +0000 (GMT) (envelope-from discussion-lists@linnet.org) Received: from orb (localhost [127.0.0.1]) by orb.pobox.com (Postfix) with ESMTP id EA4F173F; Thu, 28 Apr 2005 06:29:52 -0400 (EDT) Received: from thinkdog.local.linnet.org (host217-40-157-153.in-addr.btopenworld.com [217.40.157.153]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by orb.sasl.smtp.pobox.com (Postfix) with ESMTP id 87D8987; Thu, 28 Apr 2005 06:29:49 -0400 (EDT) Received: from lists by thinkdog.local.linnet.org with local (Exim 4.43 (FreeBSD)) id 1DR6H2-000NPN-8k; Thu, 28 Apr 2005 11:29:36 +0100 Date: Thu, 28 Apr 2005 11:29:36 +0100 From: Brian Candler To: Andre Guibert de Bruet Message-ID: <20050428102936.GA89935@uk.tiscali.com> References: <20050428053528.G59099@lexi.siliconlandmark.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050428053528.G59099@lexi.siliconlandmark.com> User-Agent: Mutt/1.4.2.1i cc: freebsd-hackers@freebsd.org cc: freebsd-current@freebsd.org Subject: Re: how to set dumpdev X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 28 Apr 2005 10:29:57 -0000 On Thu, Apr 28, 2005 at 05:37:16AM -0400, Andre Guibert de Bruet wrote: > > i can't use dumpon, since the kernel is panicking on boot, so > >tried in loader.conf: > > dumpdev="/dev/ar0s1b" > >but getting: > >db> call doadump > >Cannot dump. No dump device defined. > >0x25 > > > >i need this is for current 6.0 > >thanks, > > danny > > > > That directive, along with dumpdir, would be set in /etc/rc.conf. According to `man dumpon` (on a 5-STABLE system): Since dumpon cannot be used during kernel initialization, the dumpdev variable of loader(8) must be used to enable dumps for system panics which occur during kernel initialization. But I don't find 'dumpdev' referenced anywhere under /usr/src/sys/boot/. Is the documentation wrong? Regards, Brian. From owner-freebsd-current@FreeBSD.ORG Thu Apr 28 10:52: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 0E07816A4CE for ; Thu, 28 Apr 2005 10:52:10 +0000 (GMT) Received: from orb.pobox.com (orb.pobox.com [207.8.226.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 22BE643D54 for ; Thu, 28 Apr 2005 10:52:09 +0000 (GMT) (envelope-from discussion-lists@linnet.org) Received: from orb (localhost [127.0.0.1]) by orb.pobox.com (Postfix) with ESMTP id AFA61733; Thu, 28 Apr 2005 06:52:05 -0400 (EDT) Received: from thinkdog.local.linnet.org (host217-40-157-153.in-addr.btopenworld.com [217.40.157.153]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by orb.sasl.smtp.pobox.com (Postfix) with ESMTP id E1B4E8C; Thu, 28 Apr 2005 06:52:03 -0400 (EDT) Received: from lists by thinkdog.local.linnet.org with local (Exim 4.43 (FreeBSD)) id 1DR6cU-000NR5-9h; Thu, 28 Apr 2005 11:51:46 +0100 Date: Thu, 28 Apr 2005 11:51:46 +0100 From: Brian Candler To: Brooks Davis Message-ID: <20050428105146.GA90073@uk.tiscali.com> References: <20050427090157.GA85275@uk.tiscali.com> <20050427151204.GB32309@odin.ac.hmc.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050427151204.GB32309@odin.ac.hmc.edu> User-Agent: Mutt/1.4.2.1i cc: freebsd-current@freebsd.org Subject: Re: ISDN kernel build fials X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 28 Apr 2005 10:52:10 -0000 On Wed, Apr 27, 2005 at 08:12:04AM -0700, Brooks Davis wrote: > You want to copy the examples from NOTES that looks like: > > device i4btrc > options NI4BTRC=4 Thank you. Using the full set of ISDN configs from NOTES, I get a failure on i4bing (see below). However, commenting out device i4bing makes it compile. Regards, Brian. ... cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/export/src/usr/src/sys -I/export/src/usr/src/sys/contrib/dev/acpica -I/export/src/usr/src/sys/contrib/altq -I/export/src/usr/src/sys/contrib/ipfilter -I/export/src/usr/src/sys/contrib/pf -I/export/src/usr/src/sys/contrib/dev/ath -I/export/src/usr/src/sys/contrib/dev/ath/freebsd -I/export/src/usr/src/sys/contrib/ngatm -I/export/src/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 vnode_if.c touch hack.c cc -shared -nostdlib hack.c -o hack.So rm -f hack.c MAKE=/usr/obj/export/src/usr/src/make.i386/make sh /export/src/usr/src/sys/conf/newvers.sh FOO cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/export/src/usr/src/sys -I/export/src/usr/src/sys/contrib/dev/acpica -I/export/src/usr/src/sys/contrib/altq -I/export/src/usr/src/sys/contrib/ipfilter -I/export/src/usr/src/sys/contrib/pf -I/export/src/usr/src/sys/contrib/dev/ath -I/export/src/usr/src/sys/contrib/dev/ath/freebsd -I/export/src/usr/src/sys/contrib/ngatm -I/export/src/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 vers.c linking kernel.debug i4b_ing.o(.text+0x11e): In function `i4bingattach': /export/src/usr/src/sys/i4b/driver/i4b_ing.c:265: undefined reference to `ng_make_node_common' i4b_ing.o(.text+0x158):/export/src/usr/src/sys/i4b/driver/i4b_ing.c:273: undefined reference to `ng_name_node' i4b_ing.o(.text+0x19d): In function `i4bingattach': /export/src/usr/src/sys/netgraph/netgraph.h:430: undefined reference to `dumpnode' i4b_ing.o(.text+0x1ba):/export/src/usr/src/sys/netgraph/netgraph.h:468: undefined reference to `ng_unref_node' i4b_ing.o(.text+0x1f7):/export/src/usr/src/sys/netgraph/netgraph.h:430: undefined reference to `dumpnode' i4b_ing.o(.text+0x55b): In function `ing_rx_data_rdy': /export/src/usr/src/sys/i4b/driver/i4b_ing.c:474: undefined reference to `ng_package_data' i4b_ing.o(.text+0x574):/export/src/usr/src/sys/i4b/driver/i4b_ing.c:474: undefined reference to `ng_address_hook' i4b_ing.o(.text+0x591):/export/src/usr/src/sys/i4b/driver/i4b_ing.c:474: undefined reference to `ng_snd_item' i4b_ing.o(.text+0x7e9): In function `ng_ing_newhook': /export/src/usr/src/sys/netgraph/netgraph.h:430: undefined reference to `dumpnode' i4b_ing.o(.text+0x841):/export/src/usr/src/sys/netgraph/netgraph.h:180: undefined reference to `dumphook' i4b_ing.o(.text+0x8b2):/export/src/usr/src/sys/netgraph/netgraph.h:180: undefined reference to `dumphook' i4b_ing.o(.text+0x91f): In function `ng_ing_rcvmsg': /export/src/usr/src/sys/netgraph/netgraph.h:430: undefined reference to `dumpnode' i4b_ing.o(.text+0x95d):/export/src/usr/src/sys/netgraph/netgraph.h:668: undefined reference to `dumpitem' i4b_ing.o(.text+0x9a8): In function `ng_ing_rcvmsg': /export/src/usr/src/sys/i4b/driver/i4b_ing.c:638: undefined reference to `M_NETGRAPH_MSG' i4b_ing.o(.text+0xac8):/export/src/usr/src/sys/i4b/driver/i4b_ing.c:686: undefined reference to `M_NETGRAPH_MSG' i4b_ing.o(.text+0xb78): In function `ng_ing_rcvmsg': /export/src/usr/src/sys/netgraph/netgraph.h:668: undefined reference to `dumpitem' i4b_ing.o(.text+0xbae):/export/src/usr/src/sys/netgraph/netgraph.h:668: undefined reference to `dumpitem' i4b_ing.o(.text+0xbe6):/export/src/usr/src/sys/netgraph/netgraph.h:668: undefined reference to `dumpitem' i4b_ing.o(.text+0xc11): In function `ng_ing_rcvmsg': /export/src/usr/src/sys/i4b/driver/i4b_ing.c:720: undefined reference to `ng_address_ID' i4b_ing.o(.text+0xc2e):/export/src/usr/src/sys/i4b/driver/i4b_ing.c:720: undefined reference to `ng_snd_item' i4b_ing.o(.text+0xc51): In function `ng_ing_rcvmsg': /export/src/usr/src/sys/netgraph/netgraph.h:668: undefined reference to `dumpitem' i4b_ing.o(.text+0xc74): In function `ng_ing_rcvmsg': /export/src/usr/src/sys/i4b/driver/i4b_ing.c:720: undefined reference to `ng_free_item' i4b_ing.o(.text+0xc95): In function `ng_ing_rcvmsg': /export/src/usr/src/sys/netgraph/netgraph.h:668: undefined reference to `dumpitem' i4b_ing.o(.text+0xcb8): In function `ng_ing_rcvmsg': /export/src/usr/src/sys/i4b/driver/i4b_ing.c:720: undefined reference to `ng_free_item' i4b_ing.o(.text+0xcc5):/export/src/usr/src/sys/i4b/driver/i4b_ing.c:722: undefined reference to `M_NETGRAPH_MSG' i4b_ing.o(.text+0xd14): In function `ng_ing_rcvdata': /export/src/usr/src/sys/netgraph/netgraph.h:180: undefined reference to `dumphook' i4b_ing.o(.text+0xd52):/export/src/usr/src/sys/netgraph/netgraph.h:430: undefined reference to `dumpnode' i4b_ing.o(.text+0xd81):/export/src/usr/src/sys/netgraph/netgraph.h:668: undefined reference to `dumpitem' i4b_ing.o(.text+0xdc0):/export/src/usr/src/sys/netgraph/netgraph.h:668: undefined reference to `dumpitem' i4b_ing.o(.text+0xde4): In function `ng_ing_rcvdata': /export/src/usr/src/sys/i4b/driver/i4b_ing.c:739: undefined reference to `ng_free_item' i4b_ing.o(.text+0xe11): In function `ng_ing_rcvdata': /export/src/usr/src/sys/netgraph/netgraph.h:180: undefined reference to `dumphook' i4b_ing.o(.text+0xf65): In function `ng_ing_shutdown': /export/src/usr/src/sys/netgraph/netgraph.h:430: undefined reference to `dumpnode' i4b_ing.o(.text+0xfa9):/export/src/usr/src/sys/netgraph/netgraph.h:430: undefined reference to `dumpnode' i4b_ing.o(.text+0xfc6):/export/src/usr/src/sys/netgraph/netgraph.h:468: undefined reference to `ng_unref_node' i4b_ing.o(.text+0xfed): In function `ng_ing_shutdown': /export/src/usr/src/sys/i4b/driver/i4b_ing.c:801: undefined reference to `ng_make_node_common' i4b_ing.o(.text+0x1028):/export/src/usr/src/sys/i4b/driver/i4b_ing.c:808: undefined reference to `ng_name_node' i4b_ing.o(.text+0x106d): In function `ng_ing_shutdown': /export/src/usr/src/sys/netgraph/netgraph.h:430: undefined reference to `dumpnode' i4b_ing.o(.text+0x108a):/export/src/usr/src/sys/netgraph/netgraph.h:468: undefined reference to `ng_unref_node' i4b_ing.o(.text+0x10c6):/export/src/usr/src/sys/netgraph/netgraph.h:430: undefined reference to `dumpnode' i4b_ing.o(.text+0x111f): In function `ng_ing_connect': /export/src/usr/src/sys/netgraph/netgraph.h:180: undefined reference to `dumphook' i4b_ing.o(.text+0x115a):/export/src/usr/src/sys/netgraph/netgraph.h:180: undefined reference to `dumphook' i4b_ing.o(.text+0x11b1): In function `ng_ing_disconnect': /export/src/usr/src/sys/netgraph/netgraph.h:180: undefined reference to `dumphook' i4b_ing.o(.text+0x11ef):/export/src/usr/src/sys/netgraph/netgraph.h:430: undefined reference to `dumpnode' i4b_ing.o(.text+0x1235):/export/src/usr/src/sys/netgraph/netgraph.h:180: undefined reference to `dumphook' i4b_ing.o(.data+0x84): In function `i4bingattach': /export/src/usr/src/sys/i4b/driver/i4b_ing.c:236: undefined reference to `ng_mod_event' i4b_ing.o(.rodata+0x4): In function `i4b_ing_modevent': /export/src/usr/src/sys/i4b/driver/i4b_ing.c:116: undefined reference to `ng_parse_int32_type' i4b_ing.o(.rodata+0x10):/export/src/usr/src/sys/i4b/driver/i4b_ing.c:116: undefined reference to `ng_parse_int32_type' i4b_ing.o(.rodata+0x24):/export/src/usr/src/sys/i4b/driver/i4b_ing.c:116: undefined reference to `ng_parse_struct_type' i4b_ing.o(.rodata+0x60): In function `i4bingattach': /export/src/usr/src/sys/i4b/driver/i4b_ing.c:232: undefined reference to `ng_parse_int32_type' *** Error code 1 Stop in /export/obj/export/src/usr/src/sys/FOO+ISDN. *** Error code 1 Stop in /export/src/usr/src. *** Error code 1 Stop in /export/src/usr/src. From owner-freebsd-current@FreeBSD.ORG Thu Apr 28 10:54: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 28CF316A4CE for ; Thu, 28 Apr 2005 10:54:01 +0000 (GMT) Received: from mx.toxahost.ru (ns.toxahost.ru [62.89.204.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4796143D49 for ; Thu, 28 Apr 2005 10:54:00 +0000 (GMT) (envelope-from toxa@toxahost.ru) Received: from localhost (laptoxa.toxa.lan [192.168.1.3]) by mx.toxahost.ru (Toxa) with ESMTP id 3AEF852 for ; Thu, 28 Apr 2005 14:53:58 +0400 (MSD) Date: Thu, 28 Apr 2005 14:53:48 +0400 From: Toxa To: freebsd-current@freebsd.org X-Comment-To: "Anton A. Karpov" Message-ID: <20050428105348.GA8056@laptoxa.toxa.lan> Mail-Followup-To: freebsd-current@freebsd.org References: <57436.216.177.243.42.1114582155.localmail@webmail.dnswatch.com> <426FDE69.8090909@samsco.org> <426FE1EA.7020900@kutulu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <426FE1EA.7020900@kutulu.org> User-Agent: Outluck Express 1.5.6i for MS-DOS 6.22-SMP X-Mailer: See User-Agent above :) X-Operating-System: MS-DOS 6.22-CURRENT on Sony VAIO laptop X-PGP-Public-Key: http://toxahost.ru/gpg/pubkey.asc X-Useless-Header: Do Androids Dream of Electric Sheep? Subject: Re: boot banner project X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 28 Apr 2005 10:54:01 -0000 On Wed, Apr 27, 2005 at 03:03:06PM -0400, Mike Edenfield wrote: > Scott Long wrote: > > >Is it possible to do this without having to switch to an entirely > >raster-based console? Raster consoles (like what SuSE uses) have > >been discussed in the past, and the common thinking is that the > >loss in reliability and loss in speed is a significant issue to > >consider. > > One possible alternative to an all-out graphics display would be a > 'prettified' text console. I'm thinking of what Gentoo and older RedHat > systems did (haven't used RH in years, dunno if this still applies) > where about 80% of the system log messages are hidden behind a simple > task list: > > Mounting File Systems ... [ok] > Starting xl0 ... [ok] > > etc. With, of course, the obligatory cyan, magenta, and bright green > colors. While partly eye candy, I find it much easier to deal with than This is the most stupid idea I've ever head. Please, PLEASE, don't waste your time turning FreeBSD into pink lolypop. Is it already super-perfect-mega-stable-with-all-desired-features-implemeted? IMHO if somebody wants to spare his time and skills working on freebsd, he should choose more useful direction for his mights and power. For example, take a look at all these PRs... From owner-freebsd-current@FreeBSD.ORG Thu Apr 28 11:45: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 2E5C116A4CE for ; Thu, 28 Apr 2005 11:45:02 +0000 (GMT) Received: from mh2.centtech.com (moat3.centtech.com [207.200.51.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 42C1843D2D for ; Thu, 28 Apr 2005 11:45:01 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from [10.177.171.220] (neutrino.centtech.com [10.177.171.220]) by mh2.centtech.com (8.13.1/8.13.1) with ESMTP id j3SBixXq032860; Thu, 28 Apr 2005 06:45:00 -0500 (CDT) (envelope-from anderson@centtech.com) Message-ID: <4270CC84.8060904@centtech.com> Date: Thu, 28 Apr 2005 06:44:04 -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: Toxa References: <57436.216.177.243.42.1114582155.localmail@webmail.dnswatch.com> <426FDE69.8090909@samsco.org> <426FE1EA.7020900@kutulu.org> <20050428105348.GA8056@laptoxa.toxa.lan> In-Reply-To: <20050428105348.GA8056@laptoxa.toxa.lan> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-current@freebsd.org Subject: Re: boot banner project X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 28 Apr 2005 11:45:02 -0000 Toxa wrote: > On Wed, Apr 27, 2005 at 03:03:06PM -0400, Mike Edenfield wrote: > >>Scott Long wrote: >> >> >>>Is it possible to do this without having to switch to an entirely >>>raster-based console? Raster consoles (like what SuSE uses) have >>>been discussed in the past, and the common thinking is that the >>>loss in reliability and loss in speed is a significant issue to >>>consider. >> >>One possible alternative to an all-out graphics display would be a >>'prettified' text console. I'm thinking of what Gentoo and older RedHat >>systems did (haven't used RH in years, dunno if this still applies) >>where about 80% of the system log messages are hidden behind a simple >>task list: >> >>Mounting File Systems ... [ok] >>Starting xl0 ... [ok] >> >>etc. With, of course, the obligatory cyan, magenta, and bright green >>colors. While partly eye candy, I find it much easier to deal with than > > > This is the most stupid idea I've ever head. Please, PLEASE, don't waste > your time turning FreeBSD into pink lolypop. Is it already > super-perfect-mega-stable-with-all-desired-features-implemeted? IMHO if > somebody wants to spare his time and skills working on freebsd, he should choose > more useful direction for his mights and power. For example, take a look > at all these PRs... Stop and think that maybe some people can help in the areas that aren't C coding, or kernel debugging. We still need ideas like this (even if we choose not to use them), and calling them stupid I think isn't very constructive for anyone. Ok, so you don't like the idea, we got it. On the PRs - there are tons of PRs with patches, waiting to be committed. All it takes is for a committer to grab it, compile, test, and commit, but regular old FreeBSD supporters like myself can't commit the code, so what would you like us to do? (That's a rhetorical question, I don't need an answer). I, myself, am used to the FreeBSD blast-a-bunch-of-text-at-me bootup message, and I don't mind it. However, that doesn't mean it couldn't use some cleaning up. It would be nice if it was a *little* more organized so you could easily glance at the screen and see whats happening. The little [OK] messages have been around for quite some time, and I don't think Redhat invented them - I've seen them on older HP-UX boxes too, and I have to say, it's a lot easier to tell what is going on than our current ascii-spray we have now. I've even had people ask if my machine just crashed when they see it boot. This could easily be an rc.conf option I'm sure.. 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 Thu Apr 28 11:49: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 AA8E116A4CE for ; Thu, 28 Apr 2005 11:49:25 +0000 (GMT) Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id BE69D43D2F for ; Thu, 28 Apr 2005 11:49:24 +0000 (GMT) (envelope-from ticso@cicely12.cicely.de) Received: from cicely5.cicely.de (cicely5.cicely.de [10.1.1.7]) (authenticated bits=0)j3SBnJnp013643 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Thu, 28 Apr 2005 13:49:21 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (cicely12.cicely.de [IPv6:3ffe:400:8d0:301::12]) by cicely5.cicely.de (8.12.10/8.12.10) with ESMTP id j3SBmHhs050243 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Apr 2005 13:48:17 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (localhost [127.0.0.1]) by cicely12.cicely.de (8.12.11/8.12.11) with ESMTP id j3SBmGav065781; Thu, 28 Apr 2005 13:48:16 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: (from ticso@localhost) by cicely12.cicely.de (8.12.11/8.12.11/Submit) id j3SBmCYL065780; Thu, 28 Apr 2005 13:48:12 +0200 (CEST) (envelope-from ticso) Date: Thu, 28 Apr 2005 13:48:12 +0200 From: Bernd Walter To: Brian Candler Message-ID: <20050428114812.GZ57299@cicely12.cicely.de> References: <20050427090157.GA85275@uk.tiscali.com> <20050427151204.GB32309@odin.ac.hmc.edu> <20050428105146.GA90073@uk.tiscali.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050428105146.GA90073@uk.tiscali.com> X-Operating-System: FreeBSD cicely12.cicely.de 5.2-CURRENT alpha User-Agent: Mutt/1.5.6i X-Spam-Status: No, hits=-4.9 required=3.0 tests=BAYES_00 autolearn=no version=2.64 X-Spam-Report: * -4.9 BAYES_00 BODY: Bayesian spam probability is 0 to 1% * [score: 0.0000] X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on cicely12.cicely.de cc: freebsd-current@freebsd.org Subject: Re: ISDN kernel build fials X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: ticso@cicely.de List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2005 11:49:25 -0000 On Thu, Apr 28, 2005 at 11:51:46AM +0100, Brian Candler wrote: > On Wed, Apr 27, 2005 at 08:12:04AM -0700, Brooks Davis wrote: > > You want to copy the examples from NOTES that looks like: > > > > device i4btrc > > options NI4BTRC=4 > > Thank you. > > Using the full set of ISDN configs from NOTES, I get a failure on i4bing > (see below). However, commenting out device i4bing makes it compile. > You need NETGRAPH for I4B netgraph support. -- B.Walter BWCT http://www.bwct.de bernd@bwct.de info@bwct.de From owner-freebsd-current@FreeBSD.ORG Wed Apr 27 16:32:06 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 680) id 7394116A4D0; Wed, 27 Apr 2005 16:32:06 +0000 (GMT) Date: Wed, 27 Apr 2005 16:32:06 +0000 From: Darren Reed To: Ruslan Ermilov Message-ID: <20050427163206.GA7212@hub.freebsd.org> References: <20050426155608.GF94543@ip.net.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050426155608.GF94543@ip.net.ua> User-Agent: Mutt/1.4.2.1i X-Mailman-Approved-At: Thu, 28 Apr 2005 12:05:09 +0000 cc: Darren Reed cc: current@FreeBSD.org Subject: Re: Patchset to fix ipfilter build breakage X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 27 Apr 2005 16:32:06 -0000 On Tue, Apr 26, 2005 at 06:56:08PM +0300, Ruslan Ermilov wrote: > - rescue is still broken: the libipf library is a > culprit -- it has a lot of undefined symbols that > consumers are expected to provide, thus preventing > it to be used in rescue. When compiling a rescue > binary, it fails with the following: ... I've been thinking and discussing this. Firstly, we don't need all the tools, just ipf should be ok. So the trick then is to compile all of the libipf .o's into ipf.lo or link libipf.a into ipf.lo How's that sound to you? Can you please supply patch to fix that ? O:-) Darren From owner-freebsd-current@FreeBSD.ORG Wed Apr 27 16:57: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 F2C8616A4CE for ; Wed, 27 Apr 2005 16:57:02 +0000 (GMT) Received: from web51605.mail.yahoo.com (web51605.mail.yahoo.com [206.190.38.210]) by mx1.FreeBSD.org (Postfix) with SMTP id 6777743D1F for ; Wed, 27 Apr 2005 16:57:02 +0000 (GMT) (envelope-from pfgshield-freebsd@yahoo.com) Received: (qmail 38701 invoked by uid 60001); 27 Apr 2005 16:57:01 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=f8TNC0Qib6F1JCcb+r6mzyxShxBSd1W/MYuenzcz/sqxlHTngRoTVExKx6AYqj/XItOP0XrEUZeaI920bKc0dXVHSn1xHMIMCbcT2BpfQg2POjLSuqh+a5TvvsIpPAHgWY85YdVvD9Rjujy5Zo1sHQuJ+YYgFtvMpE3rzTIZXBA= ; Message-ID: <20050427165701.38699.qmail@web51605.mail.yahoo.com> Received: from [200.119.103.202] by web51605.mail.yahoo.com via HTTP; Wed, 27 Apr 2005 18:57:01 CEST Date: Wed, 27 Apr 2005 18:57:01 +0200 (CEST) From: To: Alexander Leidinger In-Reply-To: 6667 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Thu, 28 Apr 2005 12:05:09 +0000 cc: freebsd-current@freebsd.org Subject: Re: FreeBSD 6 is coming too fast X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: pfgshield-freebsd@yahoo.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2005 16:57:03 -0000 --- Alexander Leidinger wrote: > pfgshield-freebsd@yahoo.com wrote: > > > - Bad press towards the 5.x series. > > If it doesn't mentions 5.3 explicitely, it doesn't apply. > It was an article that appeared on osnews.com, it mention 5.3 explicitly evreything I read there turned to be false. > > - phk's axe broke one of my favorite ports and I didn't want to spend > > another 6 months "fixing" it. > > You failed to tell which port you are talking about. > Well.. I emailed phk about it and was ignored, the problem was PR'd, and even when I have an ugly workaround for it, the specific port (x11-toolkits/xview) was further broken by make changes. I fixed that port before (not much fun), and while I can accept that things may break, I find the "what I broke is not my problem" attitude unacceptable. > > - I wanted to use XFree86-4 and building it on my own and figuring out the > > library mess later is not an option. > > We still have the XFree86-4 port, and AFAIK it still works (everything else > is a bug). You just have to set a variable in make.conf to make it the > default. > Well.. while updating from 5.2.1 to 5.3 I esentially had to remove all packages and install XFree86-4 (which is not in the ISO). I decided it was easier to move to 4.11. > > - Although outdated, the downloadable java support package was available > > for 4.x only. > > It should work on 5.3-release too. At least there was an effort to get it > working, and AFAIK they succeeded. > hmm the diablo-jdk13 port says: .if ${OSVERSION} >= 502112 ECHO_MSG= ${ECHO_CMD} IGNORE= does not run on FreeBSD >= 5.x .endif > > The next time just remember: Everything is possible, you just have to ask if > you don't know how to do it yourself. > Well..sometimes you just want a stable development environment and to avoid pain if at all possible. I have no use for SMP support (or GEOM) and FreeBSD 4.x has given me so much satisfaction all these years that it was a temptation difficult to resist. Anyway after going to 4.11, the point is.. I do recommend 5.x, it's better than 4.x. While here, let me mention what I think about gcc4.0 and FreeBSD 6.0: FreeBSD 6.0 should be able to be built with gcc 4.x even when it's not a good idea to have it as the default compiler. cheers, Pedro. ___________________________________ Nuovo Yahoo! Messenger: E' molto più divertente: Audibles, Avatar, Webcam, Giochi, Rubrica… Scaricalo ora! http://it.messenger.yahoo.it From owner-freebsd-current@FreeBSD.ORG Wed Apr 27 19:21: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 E65F816A4CE for ; Wed, 27 Apr 2005 19:21:46 +0000 (GMT) Received: from fast.dnswatch.com (fast.dnswatch.com [216.177.243.43]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8A19B43D58 for ; Wed, 27 Apr 2005 19:21:36 +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 j3RJLUrt000762; Wed, 27 Apr 2005 12:21:35 -0700 (PDT) (envelope-from null@dnswatch.com) Received: (from www@localhost) by fast.dnswatch.com (8.12.6/8.12.6/Submit) id j3RJLSp7000761; Wed, 27 Apr 2005 12:21:28 -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; Wed, 27 Apr 2005 12:21:28 -0700 (PDT) Message-ID: <55670.216.177.243.35.1114629688.localmail@webmail.dnswatch.com> In-Reply-To: <84dead7205042706554f32484@mail.gmail.com> References: <63349.216.177.243.42.1114575288.localmail@webmail.dnswatch.com> <20050427060414.GA54657@ns2.wananchi.com> <55065.216.177.243.42.1114583234.localmail@webmail.dnswatch.com> <20050427083649.GC6929@ns2.wananchi.com> <61364.216.177.243.42.1114593685.localmail@webmail.dnswatch.com> <84dead7205042706554f32484@mail.gmail.com> Date: Wed, 27 Apr 2005 12:21:28 -0700 (PDT) From: "/dev/null" To: "Joseph Koshy" User-Agent: DNSwatch.com_WebMail/1.4.2 MIME-Version: 1.0 Content-Type: multipart/mixed;boundary="----=_20050427122128_39494" X-Priority: 3 Importance: Normal X-Mailman-Approved-At: Thu, 28 Apr 2005 12:05:09 +0000 X-Content-Filtered-By: Mailman/MimeDel 2.1.1 cc: freebsd-current@freebsd.org Subject: Re: can't build kernel [with CONFIG this time] - PART 2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 27 Apr 2005 19:21:47 -0000 ------=_20050427122128_39494 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit O.K. here's the scoop; I newfs'd the "troublesome" machine. Then proceeded to boot to the 5.4-RC3 CD where I implimented a "standard" install. Upon finishing and rebooting. I chose to copy my backed-up kern config to /usr/src/sys/i386/conf as DEMON01. I then cd'd to /usr/src and typed: script /var/tmp/mbw.out . Then typed make buildworld. I chose not to cvsup first because of problems I had the last time and thought going a different route made more sense then using the same route expecting different results. Anyway, after a good while make barfed. I have attached the tar+gzipped mbw.out file that was the result of this attempt to build world. The last few lines were: ... cc -O -pipe -I. -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\"/usr\" -I/usr/obj/usr/src/gnu/usr.bin/cc/cc_tools/../cc_tools -I/usr/src/gnu/usr.bin/cc/cc_tools/../cc_tools -I/usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc -I/usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/config -DGENERATOR_FILE -I/usr/obj/usr/src/i386/legacy/usr/include -c /usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/genrecog.c /usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/genrecog.c: In function `change_state': /usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/genrecog.c:1723: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. *** Error code 1 Stop in /usr/src/gnu/usr.bin/cc/cc_tools. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. demon# exit exit Script done on Wed Apr 27 11:05:51 2005 So it would appear that 5.4-RC3 world is _NOT_ buildable. :(( O.K. this box is an NS (Name Server) for quite a few domains. So it was really important that I build bind9.31... cd /usr/ports/dns/bind9, script /var/tmp/mb.out, make ... $HIT! make barfed again! >:( WTF! Was it not intended to allow building applications on FBSD-5.4-RC3?!? I'm a bit confused here. I have attached the tar+gzipped output to mb.out.gz. The last few lines are as follows: ... cc -pthread -O -pipe -I/usr/ports/dns/bind9/work/bind-9.3.1 -I. -Iinclude -I/usr/ports/dns/bind9/work/bind-9.3.1/lib/dns/include -I../../lib/dns/include -I/usr/ports/dns/bind9/work/bind-9.3.1/lib/isc/include -I../../lib/isc -I../../lib/isc/include -I../../lib/isc/unix/include -I../../lib/isc/pthreads/include -D_REENTRANT -DUSE_MD5 -DOPENSSL -D_THREAD_SAFE -W -Wall -Wmissing-prototypes -Wcast-qual -Wwrite-strings -Wformat -c dispatch.c dispatch.c: In function `dns_dispatch_detach': dispatch.c:1820: internal compiler error: in find_free_reg, at local-alloc.c:2140 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. *** Error code 1 Stop in /usr/ports/dns/bind9/work/bind-9.3.1/lib/dns. *** Error code 1 Stop in /usr/ports/dns/bind9/work/bind-9.3.1/lib. *** Error code 1 Stop in /usr/ports/dns/bind9/work/bind-9.3.1. *** Error code 1 Stop in /usr/ports/dns/bind9. demon# exit exit Script done on Wed Apr 27 11:19:00 2005 What gives??? Does anyone know? Is reverting to an "earlier model (version)" the only answer. Is FBSD progressing to uselessness - sorry, I'm pretty frustrated at this momment. Anyway, please, anyone please respond. Thanks, Chris P.S. I have also attached messages.gz which is a boot -v for this box. >> Now this one which required *no* voodoo won't build at all! > > Could you post the output of 'boot -v' on the troublesome > system (and please keep -current posted)? > > -- > FreeBSD Volunteer, http://people.freebsd.org/~jkoshy > > //////////////////////////////////////////////////// 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. //////////////////////////////////////////////////// ------=_20050427122128_39494-- From owner-freebsd-current@FreeBSD.ORG Thu Apr 28 10:13: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 483B916A4EB for ; Thu, 28 Apr 2005 10:13:11 +0000 (GMT) Received: from sanne.nlnetlabs.nl (sanne.nlnetlabs.nl [213.154.224.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id A406F43D60 for ; Thu, 28 Apr 2005 10:13:10 +0000 (GMT) (envelope-from ted@sanne.nlnetlabs.nl) Received: from sanne.nlnetlabs.nl (localhost [127.0.0.1]) by sanne.nlnetlabs.nl (8.13.3/8.13.3) with ESMTP id j3SAD8iU001499 for ; Thu, 28 Apr 2005 12:13:08 +0200 (CEST) (envelope-from ted@sanne.nlnetlabs.nl) Received: (from ted@localhost) by sanne.nlnetlabs.nl (8.13.3/8.13.3/Submit) id j3SAD7Qr001498 for freebsd-current@freebsd.org; Thu, 28 Apr 2005 12:13:07 +0200 (CEST) (envelope-from ted) Date: Thu, 28 Apr 2005 12:13:07 +0200 (CEST) From: Ted Lindgreen Message-Id: <200504281013.j3SAD7Qr001498@sanne.nlnetlabs.nl> To: freebsd-current@freebsd.org X-Spam-Status: No, score=-2.8 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on sanne.nlnetlabs.nl X-Mailman-Approved-At: Thu, 28 Apr 2005 12:05:09 +0000 Subject: user experience with ural for Ralink RT2500-USB X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 28 Apr 2005 10:13:11 -0000 Hi, I was happy to see support for the Ralink chipset just added. I bought an E-Tech wireless USB adaptor, with a Ralink 2500 chip to try it out. (I plan to dismantle the thing and connect it directly to a bi-quad antenne to get rid of the cable and connector loss I'm currently seeing on my boat). First experiences, non-serious, just to mention it: 1. You have to "kld_load if_ural", but that's documented 2. "ifconfig ural0 station blabla" does not work: SIOCS80211: Invalid argument 3. "ural" must be added to devd.conf, if you want it to get recognized on plugging into a running system A little serious: It did not work with dhclient, although it does work when configuring by hand. My dhclient.conf tries a number of accesspoints in succession. It turns out that "/sbin/dhclient-script" runs ifconfig twice in a row to set the media-configs: if [ x$reason = xMEDIUM ]; then eval "ifconfig $interface $medium" eval "ifconfig $interface inet -alias 0.0.0.0 $medium" >/dev/null 2>&1 sleep 1 exit_with_hooks 0 fi The ural-driver seems not to like this, and commenting out one of the ifconfig's fixes the problem. Not sure though whether fixing /sbin/dhclient-script or the ural-driver is the best approach here. More serious: With several accesspoints, 11g and 11b types, it works, but it will not associate with Apple Airports (the old flying soucer model, with a wavelan-pcmcia card in it). Debugging with net.wlan.debug, learns that beacons are coming in, and the wep-setting is OK: Apr 28 09:20:07 petje kernel: - 00:02:2d:2a:41:5e 00:02:2d:2a:41:5e 10 110 11M ess no! "Omval Airport"! Apr 28 09:20:07 petje kernel: - 00:0d:65:48:6d:08 00:0d:65:48:6d:08 6 10 11M ess no! 0x0000000000000000! Apr 28 09:20:07 petje kernel: + 00:02:2d:1f:57:41 00:02:2d:1f:57:41 9 110 11M ess wep "NLnet Labs @ Matrix" (both "Omval Airport" and ""NLnet Labs @ Matrix" are airports, the former without wep, the latter with; with wepmode off, the former gets a + and the latter a minus). However, ural0 never gets a "probe" from the airports. I'll append some more logging info. Regards, -- ted Some more logging of the failing association with airport and a succesful one with a linksys: Apr 28 09:20:07 petje kernel: ural0: received beacon from 00:02:2d:1f:57:41 rssi 110 Apr 28 09:20:07 petje kernel: [00:02:2d:1f:57:41] discard unhandled information element, id 128, len 6 Apr 28 09:20:07 petje kernel: [00:02:2d:1f:57:41] new beacon on chan 9 (bss chan 9) "NLnet Labs @ Matrix" Apr 28 09:20:07 petje kernel: [00:02:2d:1f:57:41] caps 0x11 bintval 100 erp 0x0 Apr 28 09:20:07 petje kernel: ieee80211_setup_node 0xc1502c00<00:02:2d:1f:57:41> in scan table Apr 28 09:20:07 petje kernel: rx done Apr 28 09:20:07 petje kernel: ural0: received beacon from 00:02:2d:1f:57:41 rssi 110 Apr 28 09:20:07 petje kernel: [00:02:2d:1f:57:41] discard unhandled information element, id 128, len 6 Apr 28 09:20:07 petje kernel: rx done Apr 28 09:20:07 petje kernel: ieee80211_cancel_scan: end active scan Apr 28 09:20:07 petje kernel: ural0: notify scan done Apr 28 09:20:07 petje kernel: macaddr bssid chan rssi rate flag wep essid Apr 28 09:20:07 petje kernel: - 00:02:2d:2a:41:5e 00:02:2d:2a:41:5e 10 110 11M ess no! "Omval Airport"! Apr 28 09:20:07 petje kernel: - 00:0d:65:48:6d:08 00:0d:65:48:6d:08 6 10 11M ess no! 0x0000000000000000! Apr 28 09:20:07 petje kernel: + 00:02:2d:1f:57:41 00:02:2d:1f:57:41 9 110 11M ess wep "NLnet Labs @ Matrix" Apr 28 09:20:07 petje kernel: _ieee80211_free_node 0xc1525000<00:02:2d:1f:57:41> in table Apr 28 09:20:07 petje kernel: _ieee80211_crypto_delkey: NONE keyix 65535 flags 0x3 rsc 0 tsc 0 len 0 Apr 28 09:20:07 petje kernel: setting channel to 9, txpower to 27 With a linksys accesspoint it works: Apr 27 17:41:48 petje kernel: ieee80211_cancel_scan: end active scan Apr 27 17:41:48 petje kernel: ural0: notify scan done Apr 27 17:41:48 petje kernel: macaddr bssid chan rssi rate flag wep essid Apr 27 17:41:48 petje kernel: + 00:0c:41:18:5f:b5 00:0c:41:18:5f:b5 8 10 11M ess wep "Omval Linksys" Apr 27 17:41:48 petje kernel: - 00:12:17:60:87:95 00:12:17:60:87:95 11 10 54M ess wep "wifihome"! Apr 27 17:41:48 petje kernel: _ieee80211_free_node 0xc14da400<00:06:f4:0a:7a:4e> in table Apr 27 17:41:48 petje kernel: _ieee80211_crypto_delkey: NONE keyix 65535 flags 0x3 rsc 0 tsc 0 len 0 Apr 27 17:41:48 petje kernel: ieee80211_newstate: SCAN -> AUTH Apr 27 17:41:48 petje kernel: ieee80211_ref_node (ieee80211_send_mgmt:936) 0xc15bdc00<00:0c:41:18:5f:b5> refcnt 3 Apr 27 17:41:48 petje kernel: [00:0c:41:18:5f:b5] send auth on channel 8 Apr 27 17:41:48 petje kernel: ural0: received auth from 00:0c:41:18:5f:b5 rssi 10 Apr 27 17:41:48 petje kernel: [00:0c:41:18:5f:b5] recv auth frame with algorithm 0 seq 2 Apr 27 17:41:48 petje kernel: ieee80211_newstate: AUTH -> ASSOC Apr 27 17:41:48 petje kernel: ieee80211_ref_node (ieee80211_send_mgmt:936) 0xc15bdc00<00:0c:41:18:5f:b5> refcnt 3 Apr 27 17:41:48 petje kernel: [00:0c:41:18:5f:b5] send assoc_req on channel 8 Apr 27 17:41:48 petje kernel: ural0: received beacon from 00:0c:41:18:5f:b5 rssi 10 Apr 27 17:41:48 petje kernel: ural0: received assoc_resp from 00:0c:41:18:5f:b5 rssi 10 Apr 27 17:41:48 petje kernel: [00:0c:41:18:5f:b5] assoc success: long preamble, long slot time Apr 27 17:41:48 petje kernel: ieee80211_newstate: ASSOC -> RUN Apr 27 17:41:48 petje kernel: ural0: associated with 00:0c:41:18:5f:b5 ssid "Omval Linksys" channel 8 start 1Mb Apr 27 17:41:48 petje kernel: ural0: link state changed to UP --- . From owner-freebsd-current@FreeBSD.ORG Thu Apr 28 12:15: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 EFE9E16A4CE for ; Thu, 28 Apr 2005 12:15:03 +0000 (GMT) Received: from orb.pobox.com (orb.pobox.com [207.8.226.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9A91F43D2D for ; Thu, 28 Apr 2005 12:15:03 +0000 (GMT) (envelope-from discussion-lists@linnet.org) Received: from orb (localhost [127.0.0.1]) by orb.pobox.com (Postfix) with ESMTP id 3145E7D7 for ; Thu, 28 Apr 2005 08:15:00 -0400 (EDT) Received: from thinkdog.local.linnet.org (host217-40-157-153.in-addr.btopenworld.com [217.40.157.153]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by orb.sasl.smtp.pobox.com (Postfix) with ESMTP id 017E391 for ; Thu, 28 Apr 2005 08:14:59 -0400 (EDT) Received: from lists by thinkdog.local.linnet.org with local (Exim 4.43 (FreeBSD)) id 1DR7up-000NXc-6g for freebsd-current@freebsd.org; Thu, 28 Apr 2005 13:14:47 +0100 Date: Thu, 28 Apr 2005 13:14:47 +0100 From: Brian Candler To: freebsd-current@freebsd.org Message-ID: <20050428121447.GA90430@uk.tiscali.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Subject: wpa_supplicant causes panic in ieee80211_newstate X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 28 Apr 2005 12:15:04 -0000 -CURRENT supped as of yesterday. Old-ish Dell PIII-600MHz system. I have put in a Buffalo PCI-PCCard adaptor with WLI-PCM-L11 wireless card, detected as if_wi. Now I'm trying to see if I can get it to join a WPA network. I installed security/wpa_supplicant from ports, and ran it as wpa_supplicant -iwi0 -c/usr/local/etc/wpa_supplicant.conf -d # based closely on wpa_suppicant.conf.sample It generated some screens of debug information, ending with Starting AP scan (broadcast SSID) Added BSSID 00:00:00:00:00:00 into blacklist EAPOL: External notification - portEnabled=0 EAPOL: External notification - portValid=0 Disconnect event - remove keys wpa_driver_bsd_dsl_key: keyidx=0 wpa_driver_bsd_dsl_key: keyidx=1 wpa_driver_bsd_dsl_key: keyidx=2 wpa_driver_bsd_dsl_key: keyidx=3 wpa_driver_bsd_dsl_key: keyidx=0 At this point, a panic occured on the first virtual console: panic: ieee80211_newstate: bogus xmit rate 0 setup cpuid = 0 KDB: enter: panic [thread pid 22 tid 100014 ] Stopped at kdb_enter+0x2b: nop db> trace Tracing pid 22 tid 100014 td 0xc1521d80 kdb_enter(c08a88ab) at kdb_enter+0x2b panic(c08b6a4a,c085bbdf,0,c16ae400,c1770000) at panic+0x127 ieee80211_netstate(c177025c,4,ffffffff,c16ae400,782af) at ieee80211_newstate+0x50e wi_newstate(c1777025c,4,ffffffff) at wi_newstate+0x1bf wi_info_intr(c17770000) at wi_info_intr+0x107 wi_intr(c17770000) at wi_intr+0x17e pccard_intr(c1544680,c1775080,cbffed0c,c064622c,c164f880) at pccard_intr+0x60 cbb_func_intr(c164f880) at cbb_func_intr+0x45 ithread_loop(c1544c00,cbffed38,c1544c00,c064610c,0) at ithread_loop+0x120 fork_exit(c064610c,c1544c00,cbffed38) at fork_exit+0xa0 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xcbffed6c, edp = 0 --- db> ps ... 22 c1524c00 0 0 0 0000204 [CPU 0] irq11: cbb0 ifpi0+* Unfortunately I didn't have a dumpdev enabled. I don't know if the above is much use by itself. Regards, Brian. From owner-freebsd-current@FreeBSD.ORG Thu Apr 28 12:39: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 25AC116A4CE for ; Thu, 28 Apr 2005 12:39:24 +0000 (GMT) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.203]) by mx1.FreeBSD.org (Postfix) with ESMTP id A744C43D1F for ; Thu, 28 Apr 2005 12:39:23 +0000 (GMT) (envelope-from robbak@gmail.com) Received: by wproxy.gmail.com with SMTP id 69so563498wri for ; Thu, 28 Apr 2005 05:39:21 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=q5SVqZ2cfLDRFlEGhr0I0bKsVh4u9ZRDxf7RYHxUQ/8V3Qai24qF5k7sSGrvyrWHPo9eLTVttsjvx1SbGiB6Z/JaLTXTm8yBjFsC7/EutTZ/BSoIhdx4uslKCywF0zEDDprKytmQnfJd0cvOZ8hKI6D1MaZsWZHg/AOYFiz2Db8= Received: by 10.54.124.1 with SMTP id w1mr703419wrc; Thu, 28 Apr 2005 05:39:21 -0700 (PDT) Received: by 10.54.14.15 with HTTP; Thu, 28 Apr 2005 05:39:21 -0700 (PDT) Message-ID: Date: Thu, 28 Apr 2005 22:39:21 +1000 From: Robert Backhaus To: pfgshield-freebsd@yahoo.com In-Reply-To: <20050427165701.38699.qmail@web51605.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <20050427165701.38699.qmail@web51605.mail.yahoo.com> cc: freebsd-current@freebsd.org Subject: Re: FreeBSD 6 is coming too fast 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: Thu, 28 Apr 2005 12:39:24 -0000 On 4/28/05, pfgshield-freebsd@yahoo.com wrote= : > I find the "what I broke is not my problem" attitude unacceptable. To some extent, yes, although ports changes will occour, and with it some ports faulres. These will be picked up by bentoo and fixed by the maintainer, or someone interested in the port. That may be you. Changes to the ports system to improve maintainabiliy are essential to it's survival. > Well.. while updating from 5.2.1 to 5.3 I esentially had to remove all pa= ckages > and install XFree86-4 (which is not in the ISO). I decided it was easier = to > move to 4.11. We all would reccomend the same path: Move to Xorg, like everyone else. We have shifted to Xorg for good reason - XFree86 will die soon. Great things are happening in Xorg. Oh, you probably won't need to recompile your X clients when you do. Merely fix the dependencies to keep portupgrade happy. I think I used portupgrade -o... when I Xorged my 4.x box. > > > - Although outdated, the downloadable java support package was availa= ble > > > for 4.x only. Sorry, we'd really like to do something about that. But Sun won't let us. Java 1.4 is nice an mature, but the only way to get a binary is to have a friend. Complain in the right direction, please. > While here, let me mention what I think about gcc4.0 and FreeBSD 6.0: Fre= eBSD > 6.0 should be able to be built with gcc 4.x even when it's not a good ide= a to > have it as the default compiler. Remember that 6.0 will be a new technology release, just like 5.[012] were. That was a great idea that woked well. I think they are planning 6.1 in August to be .STABLE, but I think that's overly optomistic. Look for 6.2, around December. From owner-freebsd-current@FreeBSD.ORG Thu Apr 28 12:42: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 958CC16A4CF for ; Thu, 28 Apr 2005 12:42:48 +0000 (GMT) Received: from mortis.over-yonder.net (adsl-12-42-198.jan.bellsouth.net [65.12.42.198]) by mx1.FreeBSD.org (Postfix) with ESMTP id D519743D45 for ; Thu, 28 Apr 2005 12:42:47 +0000 (GMT) (envelope-from fullermd@over-yonder.net) Received: by mortis.over-yonder.net (Postfix, from userid 100) id 2CFB320F21; Thu, 28 Apr 2005 07:42:46 -0500 (CDT) Date: Thu, 28 Apr 2005 07:42:45 -0500 From: "Matthew D. Fuller" To: Robert Backhaus Message-ID: <20050428124245.GA88294@over-yonder.net> References: <20050427165701.38699.qmail@web51605.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Editor: vi X-OS: FreeBSD User-Agent: Mutt/1.5.9i-fullermd.2 cc: pfgshield-freebsd@yahoo.com cc: freebsd-current@freebsd.org Subject: Re: FreeBSD 6 is coming too fast X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 28 Apr 2005 12:42:48 -0000 On Thu, Apr 28, 2005 at 10:39:21PM +1000 I heard the voice of Robert Backhaus, and lo! it spake thus: > > Oh, you probably won't need to recompile your X clients when you do. > Merely fix the dependencies to keep portupgrade happy. I think I > used portupgrade -o... when I Xorged my 4.x box. I moved from XFree86 3.3.x to Xorg and didn't have to recompile anything (I think; I upgraded some other things at the same time, but nothing that I didn't upgrade broke). -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. From owner-freebsd-current@FreeBSD.ORG Thu Apr 28 13:41: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 CC96B16A4CE for ; Thu, 28 Apr 2005 13:41:08 +0000 (GMT) Received: from basement.kutulu.org (211.215.33.65.cfl.res.rr.com [65.33.215.211]) by mx1.FreeBSD.org (Postfix) with ESMTP id 89BEA43D39 for ; Thu, 28 Apr 2005 13:41:08 +0000 (GMT) (envelope-from kutulu@kutulu.org) Received: from [127.0.0.1] (localhost [127.0.0.1]) by basement.kutulu.org (Postfix) with ESMTP id 5AD7C53; Thu, 28 Apr 2005 09:41:07 -0400 (EDT) Message-ID: <4270E7F1.9010502@kutulu.org> Date: Thu, 28 Apr 2005 09:41:05 -0400 From: Mike Edenfield User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Toxa References: <57436.216.177.243.42.1114582155.localmail@webmail.dnswatch.com> <426FDE69.8090909@samsco.org> <426FE1EA.7020900@kutulu.org> <20050428105348.GA8056@laptoxa.toxa.lan> In-Reply-To: <20050428105348.GA8056@laptoxa.toxa.lan> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-current@freebsd.org Subject: Re: boot banner project X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 28 Apr 2005 13:41:08 -0000 Toxa wrote: > On Wed, Apr 27, 2005 at 03:03:06PM -0400, Mike Edenfield wrote: >> >>One possible alternative to an all-out graphics display would be a >>'prettified' text console. I'm thinking of what Gentoo and older RedHat >>systems did (haven't used RH in years, dunno if this still applies) >>where about 80% of the system log messages are hidden behind a simple >>task list: >> >>Mounting File Systems ... [ok] >>Starting xl0 ... [ok] >> >>etc. With, of course, the obligatory cyan, magenta, and bright green >>colors. While partly eye candy, I find it much easier to deal with than > > > This is the most stupid idea I've ever head. Please, PLEASE, don't waste > your time turning FreeBSD into pink lolypop. Is it already > super-perfect-mega-stable-with-all-desired-features-implemeted? IMHO if > somebody wants to spare his time and skills working on freebsd, he should choose > more useful direction for his mights and power. For example, take a look > at all these PRs... 1) It is far from a stupid idea if even one person honestly feels it would be a benefit. No need to be abusive about it. 2) If I were to choose to work on FreeBSD, I would be free to work on whatever I felt was lacking. That's how it works. Especially given that I have nowhere near enough skill in C to work on more complex system-level issues. 3) I was merely making suggestions as to what alternatives were available. Since almost every Linux distro does something similar to this proposal, there is obviously SOME merit to it; the benefit may be miniscule, or irrelevant to many people, but it still exists. --Mike From owner-freebsd-current@FreeBSD.ORG Thu Apr 28 14:54: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 AAFED16A4CE for ; Thu, 28 Apr 2005 14:54:19 +0000 (GMT) Received: from smtp-1.dlr.de (smtp-1.dlr.de [195.37.61.185]) by mx1.FreeBSD.org (Postfix) with ESMTP id 63BF343D4C for ; Thu, 28 Apr 2005 14:54:18 +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, 28 Apr 2005 16:54:16 +0200 Date: Thu, 28 Apr 2005 16:54:16 +0200 (CEST) From: Harti Brandt X-X-Sender: brandt_h@beagle.kn.op.dlr.de To: Chuck Robey In-Reply-To: <4270762E.3050508@chuckr.org> Message-ID: <20050428164808.X821@beagle.kn.op.dlr.de> References: <4270762E.3050508@chuckr.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 28 Apr 2005 14:54:16.0627 (UTC) FILETIME=[264EC830:01C54C02] cc: current Subject: Re: junk after endif 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, 28 Apr 2005 14:54:19 -0000 On Thu, 28 Apr 2005, Chuck Robey wrote: CR>in making the environment for my new sparc box, I'm building a new buildworld CR>for the sparc, that that's giving me REAMS of useless errors about "junk at CR>the end of the line", you know what it is from watching the error come up CR>from cpp listings...except that these come from make, not from C code... CR>having this come up in the situation I'm in, with zero (besides merely a CR>KERNCONF) in the /etc/make.conf, then having this error come up so often it CR>obscures the real listing is egregiously crazy. CR> CR>So, the fix falls into one of these categories: CR> CR>1) there is a magic incantation I don't know, and don't have time to hunt CR>down, that kills this warning in make, and I need to know this, but that's CR>not the fix ... the fix is (possibly) to make the default action that this is CR>NOT a warning. CR> CR>2) I know that many folks like to do this to endif's, but it's an warning in CR>C, and we should tell the folks who like it "tough" and take them out. CR> CR>However it's decided, to squish the warning or to squish the tags, it's CR>unacceptable to leave those semantically useless warnings laying about, CR>hiding real problems. These warnings come only if you build with a /usr/share/mk which is not up-to-date and an up-to-date make. (It may also be that you slipped with your sources into the small window between the two commits). As far as I can see this can legally happen only when building 5.4 or earlier on a current box (I have committed the fix to /usr/share/mk in RELENG_5, but cannot do this because this doesn't seem to fall under the committable categories for RELENG_5_*). harti From owner-freebsd-current@FreeBSD.ORG Thu Apr 28 14: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 159CC16A4CF; Thu, 28 Apr 2005 14:55:13 +0000 (GMT) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id BEFEA43D45; Thu, 28 Apr 2005 14:55:11 +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 j3SExHMD062309; Thu, 28 Apr 2005 17:59:17 +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 22869-02; Thu, 28 Apr 2005 17:55:10 +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 j3SExGYw062306 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Apr 2005 17:59:16 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.13.3/8.13.3) id j3SEtJYo092954; Thu, 28 Apr 2005 17:55:19 +0300 (EEST) (envelope-from ru) Date: Thu, 28 Apr 2005 17:55:19 +0300 From: Ruslan Ermilov To: Darren Reed Message-ID: <20050428145519.GB92579@ip.net.ua> References: <20050428025836.E1ED67306E@freebsd-current.sentex.ca> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="DBIVS5p969aUjpLe" Content-Disposition: inline In-Reply-To: <20050428025836.E1ED67306E@freebsd-current.sentex.ca> User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new at ip.net.ua cc: current@FreeBSD.org Subject: LINT broken due to ipfilter (was: Re: [current tinderbox] failure on i386/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: Thu, 28 Apr 2005 14:55:13 -0000 --DBIVS5p969aUjpLe Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Apr 27, 2005 at 10:58:36PM -0400, FreeBSD Tinderbox wrote: > TB --- 2005-04-28 01:25:42 - starting CURRENT tinderbox run for i386/i386 > TB --- 2005-04-28 02:57:55 - /usr/bin/make buildkernel KERNCONF=3DLINT > >>> Kernel build for LINT started on Thu Apr 28 02:57:55 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 > [...] > /usr/sbin/kbdcontrol -L it.iso | sed -e 's/^static keymap_t.* =3D /static= keymap_t key_map =3D /' -e 's/^static accentmap_t.* =3D /static accentmap_= t accent_map =3D /' > ukbdmap.h > cp /tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath/public/i386-elf.o= pt_ah.h opt_ah.h > /home/tinderbox/CURRENT/i386/i386/obj/tinderbox/CURRENT/i386/i386/src/mak= e.i386/make -f /tinderbox/CURRENT/i386/i386/src/sys/i386/acpica/Makefile MA= KESRCPATH=3D/tinderbox/CURRENT/i386/i386/src/sys/i386/acpica > cc -O2 -pipe -I. -I@ -c /tinderbox/CURRENT/i386/i386/src/sys/i386/acpic= a/acpi_wakecode.S > objcopy -S -O binary acpi_wakecode.o acpi_wakecode.bin > sh /tinderbox/CURRENT/i386/i386/src/sys/i386/acpica/genwakecode.sh > acpi= _wakecode.h > Warning: Object directory not changed from original /tinderbox/CURRENT/i3= 86/i386/obj/tinderbox/CURRENT/i386/i386/src/sys/LINT > make: don't know how to make /tinderbox/CURRENT/i386/i386/src/sys/contrib= /ipfilter/netinet/ip_fil.c. Stop > *** Error code 2 >=20 > Stop in /tinderbox/CURRENT/i386/i386/src. > *** Error code 1 >=20 > Stop in /tinderbox/CURRENT/i386/i386/src. > TB --- 2005-04-28 02:58:36 - WARNING: /usr/bin/make returned exit code 1= =20 > TB --- 2005-04-28 02:58:36 - ERROR: failed to build lint kernel > TB --- 2005-04-28 02:58:36 - tinderbox aborted >=20 The changes from sys/modules/ipfilter/Makefile,v 1.17 should be propagated to sys/conf/{files,options,NOTES}. Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --DBIVS5p969aUjpLe Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFCcPlXqRfpzJluFF4RAjsvAJ4wU+JJm7eyCMensT+g6ZRTp22NZwCeOil7 4wHJr8jIyvdwWw8QLMimGmg= =qVDt -----END PGP SIGNATURE----- --DBIVS5p969aUjpLe-- From owner-freebsd-current@FreeBSD.ORG Thu Apr 28 15:03: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 7280716A4CE; Thu, 28 Apr 2005 15:03:43 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 83E4943D49; Thu, 28 Apr 2005 15:03:40 +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.3/8.13.3) with ESMTP id j3SF7oa1023557; Thu, 28 Apr 2005 09:07:51 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <4270FA78.6030406@samsco.org> Date: Thu, 28 Apr 2005 09:00:08 -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: Harti Brandt References: <4270762E.3050508@chuckr.org> <20050428164808.X821@beagle.kn.op.dlr.de> In-Reply-To: <20050428164808.X821@beagle.kn.op.dlr.de> 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: Chuck Robey cc: current Subject: Re: junk after endif X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 28 Apr 2005 15:03:43 -0000 Harti Brandt wrote: > On Thu, 28 Apr 2005, Chuck Robey wrote: > > CR>in making the environment for my new sparc box, I'm building a new buildworld > CR>for the sparc, that that's giving me REAMS of useless errors about "junk at > CR>the end of the line", you know what it is from watching the error come up > CR>from cpp listings...except that these come from make, not from C code... > CR>having this come up in the situation I'm in, with zero (besides merely a > CR>KERNCONF) in the /etc/make.conf, then having this error come up so often it > CR>obscures the real listing is egregiously crazy. > CR> > CR>So, the fix falls into one of these categories: > CR> > CR>1) there is a magic incantation I don't know, and don't have time to hunt > CR>down, that kills this warning in make, and I need to know this, but that's > CR>not the fix ... the fix is (possibly) to make the default action that this is > CR>NOT a warning. > CR> > CR>2) I know that many folks like to do this to endif's, but it's an warning in > CR>C, and we should tell the folks who like it "tough" and take them out. > CR> > CR>However it's decided, to squish the warning or to squish the tags, it's > CR>unacceptable to leave those semantically useless warnings laying about, > CR>hiding real problems. > > These warnings come only if you build with a /usr/share/mk which is not > up-to-date and an up-to-date make. (It may also be that you slipped with > your sources into the small window between the two commits). > > As far as I can see this can legally happen only when building 5.4 or > earlier on a current box (I have committed the fix to /usr/share/mk in > RELENG_5, but cannot do this because this doesn't seem to fall under the > committable categories for RELENG_5_*). > > harti In general, I think that this warning is a bad idea. It (along with the NO_FOO wanrings that are also a bad idea) make it very hard to build prior releases and snapshots from 6-current. I really cannot see how this warning benefits anyone or solves a problem; all it does it create an unneccesary mess. Yes, building things like I've described here isn't "supported", but putting up needless roadblocks and making the definition of "supported" be very narrow makes using FreeBSD very hard. Please eliminate this warning, or put it under a 'pendatic' flag only. Scott From owner-freebsd-current@FreeBSD.ORG Thu Apr 28 15:06: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 DFF6C16A4CE; Thu, 28 Apr 2005 15:06:31 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 273F043D2F; Thu, 28 Apr 2005 15:06:31 +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.3/8.13.3) with ESMTP id j3SFAjvv023574; Thu, 28 Apr 2005 09:10:45 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <4270FB26.50805@samsco.org> Date: Thu, 28 Apr 2005 09:03:02 -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: Ruslan Ermilov References: <20050428025836.E1ED67306E@freebsd-current.sentex.ca> <20050428145519.GB92579@ip.net.ua> In-Reply-To: <20050428145519.GB92579@ip.net.ua> 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: Darren Reed cc: current@freebsd.org Subject: Re: LINT broken due to ipfilter X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 28 Apr 2005 15:06:32 -0000 Ruslan Ermilov wrote: > On Wed, Apr 27, 2005 at 10:58:36PM -0400, FreeBSD Tinderbox wrote: > >>TB --- 2005-04-28 01:25:42 - starting CURRENT tinderbox run for i386/i386 >>TB --- 2005-04-28 02:57:55 - /usr/bin/make buildkernel KERNCONF=LINT >> >>>>>Kernel build for LINT started on Thu Apr 28 02:57:55 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 >> >>[...] >>/usr/sbin/kbdcontrol -L it.iso | sed -e 's/^static keymap_t.* = /static keymap_t key_map = /' -e 's/^static accentmap_t.* = /static accentmap_t accent_map = /' > ukbdmap.h >>cp /tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath/public/i386-elf.opt_ah.h opt_ah.h >>/home/tinderbox/CURRENT/i386/i386/obj/tinderbox/CURRENT/i386/i386/src/make.i386/make -f /tinderbox/CURRENT/i386/i386/src/sys/i386/acpica/Makefile MAKESRCPATH=/tinderbox/CURRENT/i386/i386/src/sys/i386/acpica >>cc -O2 -pipe -I. -I@ -c /tinderbox/CURRENT/i386/i386/src/sys/i386/acpica/acpi_wakecode.S >>objcopy -S -O binary acpi_wakecode.o acpi_wakecode.bin >>sh /tinderbox/CURRENT/i386/i386/src/sys/i386/acpica/genwakecode.sh > acpi_wakecode.h >>Warning: Object directory not changed from original /tinderbox/CURRENT/i386/i386/obj/tinderbox/CURRENT/i386/i386/src/sys/LINT >>make: don't know how to make /tinderbox/CURRENT/i386/i386/src/sys/contrib/ipfilter/netinet/ip_fil.c. Stop >>*** Error code 2 >> >>Stop in /tinderbox/CURRENT/i386/i386/src. >>*** Error code 1 >> >>Stop in /tinderbox/CURRENT/i386/i386/src. >>TB --- 2005-04-28 02:58:36 - WARNING: /usr/bin/make returned exit code 1 >>TB --- 2005-04-28 02:58:36 - ERROR: failed to build lint kernel >>TB --- 2005-04-28 02:58:36 - tinderbox aborted >> > > The changes from sys/modules/ipfilter/Makefile,v 1.17 should be propagated > to sys/conf/{files,options,NOTES}. > > > Cheers, Please feel free to do this. Scott From owner-freebsd-current@FreeBSD.ORG Thu Apr 28 15:16: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 2FDD016A4CE for ; Thu, 28 Apr 2005 15:16:28 +0000 (GMT) Received: from smtp-1.dlr.de (smtp-1.dlr.de [195.37.61.185]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5A2BD43D39 for ; Thu, 28 Apr 2005 15:16:27 +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, 28 Apr 2005 17:16:26 +0200 Date: Thu, 28 Apr 2005 17:16:27 +0200 (CEST) From: Harti Brandt X-X-Sender: brandt_h@beagle.kn.op.dlr.de To: Scott Long In-Reply-To: <4270FA78.6030406@samsco.org> Message-ID: <20050428170600.L821@beagle.kn.op.dlr.de> References: <4270762E.3050508@chuckr.org> <20050428164808.X821@beagle.kn.op.dlr.de> <4270FA78.6030406@samsco.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 28 Apr 2005 15:16:26.0387 (UTC) FILETIME=[3EE80E30:01C54C05] cc: Chuck Robey cc: current Subject: Re: junk after endif 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, 28 Apr 2005 15:16:28 -0000 On Thu, 28 Apr 2005, Scott Long wrote: SL>Harti Brandt wrote: SL>> On Thu, 28 Apr 2005, Chuck Robey wrote: SL>> SL>> CR>in making the environment for my new sparc box, I'm building a new SL>> buildworld SL>> CR>for the sparc, that that's giving me REAMS of useless errors about "junk SL>> at SL>> CR>the end of the line", you know what it is from watching the error come SL>> up SL>> CR>from cpp listings...except that these come from make, not from C code... SL>> CR>having this come up in the situation I'm in, with zero (besides merely a SL>> CR>KERNCONF) in the /etc/make.conf, then having this error come up so often SL>> it SL>> CR>obscures the real listing is egregiously crazy. SL>> CR> SL>> CR>So, the fix falls into one of these categories: SL>> CR> SL>> CR>1) there is a magic incantation I don't know, and don't have time to SL>> hunt SL>> CR>down, that kills this warning in make, and I need to know this, but SL>> that's SL>> CR>not the fix ... the fix is (possibly) to make the default action that SL>> this is SL>> CR>NOT a warning. SL>> CR> SL>> CR>2) I know that many folks like to do this to endif's, but it's an SL>> warning in SL>> CR>C, and we should tell the folks who like it "tough" and take them out. SL>> CR> SL>> CR>However it's decided, to squish the warning or to squish the tags, it's SL>> CR>unacceptable to leave those semantically useless warnings laying about, SL>> CR>hiding real problems. SL>> SL>> These warnings come only if you build with a /usr/share/mk which is not SL>> up-to-date and an up-to-date make. (It may also be that you slipped with SL>> your sources into the small window between the two commits). SL>> SL>> As far as I can see this can legally happen only when building 5.4 or SL>> earlier on a current box (I have committed the fix to /usr/share/mk in SL>> RELENG_5, but cannot do this because this doesn't seem to fall under the SL>> committable categories for RELENG_5_*). SL>> SL>> harti SL> SL>In general, I think that this warning is a bad idea. It (along with the SL>NO_FOO wanrings that are also a bad idea) make it very hard to build SL>prior releases and snapshots from 6-current. I really cannot see how SL>this warning benefits anyone or solves a problem; all it does it create SL>an unneccesary mess. Yes, building things like I've described here SL>isn't "supported", but putting up needless roadblocks and making the SL>definition of "supported" be very narrow makes using FreeBSD very hard. SL>Please eliminate this warning, or put it under a 'pendatic' flag only. I found at least one incarnation of an expression after an .else in a port Makefile where the writer obviously expected the expression to be processed. The problem was that the author wrote .else instead of .elif. We found also a number of incarnations of .elseif statements that make silently happend to process as .else. Makefiles are inherently hard to debug (because of the crufty syntax and the sloppiness of our make), so every warning maybe helpful. I agree that this should be under the control of an option and, in fact, I was going to implement just that - its just not that high on my list. But as you ask so nicely about it I can move it up the list and do it in the next days. Regards, harti From owner-freebsd-current@FreeBSD.ORG Thu Apr 28 15: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 09F0716A4CE; Thu, 28 Apr 2005 15:26:16 +0000 (GMT) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2632743D2F; Thu, 28 Apr 2005 15:26:15 +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 j3SFULqL064946; Thu, 28 Apr 2005 18:30:21 +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 24350-02; Thu, 28 Apr 2005 18:26:13 +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 j3SFUKaC064943 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Apr 2005 18:30:20 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.13.3/8.13.3) id j3SFQNiM093250; Thu, 28 Apr 2005 18:26:23 +0300 (EEST) (envelope-from ru) Date: Thu, 28 Apr 2005 18:26:22 +0300 From: Ruslan Ermilov To: Scott Long Message-ID: <20050428152622.GC92579@ip.net.ua> References: <20050428025836.E1ED67306E@freebsd-current.sentex.ca> <20050428145519.GB92579@ip.net.ua> <4270FB26.50805@samsco.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="bjuZg6miEcdLYP6q" Content-Disposition: inline In-Reply-To: <4270FB26.50805@samsco.org> User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new at ip.net.ua cc: Darren Reed cc: current@freebsd.org Subject: Re: LINT broken due to ipfilter X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 28 Apr 2005 15:26:16 -0000 --bjuZg6miEcdLYP6q Content-Type: multipart/mixed; boundary="7gGkHNMELEOhSGF6" Content-Disposition: inline --7gGkHNMELEOhSGF6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Scott, On Thu, Apr 28, 2005 at 09:03:02AM -0600, Scott Long wrote: > Ruslan Ermilov wrote: > >The changes from sys/modules/ipfilter/Makefile,v 1.17 should be propagat= ed > >to sys/conf/{files,options,NOTES}. > > > > > >Cheers, >=20 > Please feel free to do this. >=20 Well, the attached patch should do it, though I have near zero experience with ipfilter, so I won't commit it myself. Darren probably will. :-) Even after committing this, there's stil a number of compile-time warnings on 64-bit platforms that should be fixed before this can be compiled. Before this, it probably makes sense to comment out IPFILTER in LINT, and let Darren finish polishing his import. Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --7gGkHNMELEOhSGF6 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=p Index: NOTES =================================================================== RCS file: /home/ncvs/src/sys/conf/NOTES,v retrieving revision 1.1313 diff -u -r1.1313 NOTES --- NOTES 25 Apr 2005 07:07:49 -0000 1.1313 +++ NOTES 28 Apr 2005 15:22:45 -0000 @@ -719,6 +719,7 @@ options IPDIVERT #divert sockets options IPFILTER #ipfilter support options IPFILTER_LOG #ipfilter logging +options IPFILTER_LOOKUP #ipfilter pools options IPFILTER_DEFAULT_BLOCK #block all packets by default options IPSTEALTH #support for stealth forwarding options TCPDEBUG Index: files =================================================================== RCS file: /home/ncvs/src/sys/conf/files,v retrieving revision 1.1017 diff -u -r1.1017 files --- files 25 Apr 2005 07:07:50 -0000 1.1017 +++ files 28 Apr 2005 15:18:01 -0000 @@ -243,12 +243,16 @@ contrib/dev/ath/freebsd/ah_osdep.c optional ath_hal contrib/ipfilter/netinet/fil.c optional ipfilter inet contrib/ipfilter/netinet/ip_auth.c optional ipfilter inet -contrib/ipfilter/netinet/ip_fil.c optional ipfilter inet +contrib/ipfilter/netinet/ip_fil_freebsd.c optional ipfilter inet contrib/ipfilter/netinet/ip_frag.c optional ipfilter inet contrib/ipfilter/netinet/ip_log.c optional ipfilter inet contrib/ipfilter/netinet/ip_nat.c optional ipfilter inet contrib/ipfilter/netinet/ip_proxy.c optional ipfilter inet contrib/ipfilter/netinet/ip_state.c optional ipfilter inet +contrib/ipfilter/netinet/ip_lookup.c optional ipfilter inet +contrib/ipfilter/netinet/ip_pool.c optional ipfilter inet +contrib/ipfilter/netinet/ip_htable.c optional ipfilter inet +contrib/ipfilter/netinet/ip_sync.c optional ipfilter inet contrib/ipfilter/netinet/mlfk_ipl.c optional ipfilter inet contrib/ngatm/netnatm/api/cc_conn.c optional ngatm_ccatm contrib/ngatm/netnatm/api/cc_data.c optional ngatm_ccatm Index: options =================================================================== RCS file: /home/ncvs/src/sys/conf/options,v retrieving revision 1.499 diff -u -r1.499 options --- options 19 Apr 2005 04:01:23 -0000 1.499 +++ options 28 Apr 2005 15:22:12 -0000 @@ -342,6 +342,7 @@ DUMMYNET opt_ipdn.h IPFILTER opt_ipfilter.h IPFILTER_LOG opt_ipfilter.h +IPFILTER_LOOKUP opt_ipfilter.h IPFILTER_DEFAULT_BLOCK opt_ipfilter.h IPFIREWALL opt_ipfw.h IPFIREWALL_VERBOSE opt_ipfw.h --7gGkHNMELEOhSGF6-- --bjuZg6miEcdLYP6q Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFCcQCeqRfpzJluFF4RAqzUAJ9lXX3aPETYa0dYVC/VCgNd11zIZACeOtAz jo3RwDlXRkYSD3f9gIyEnUI= =LQLY -----END PGP SIGNATURE----- --bjuZg6miEcdLYP6q-- From owner-freebsd-current@FreeBSD.ORG Thu Apr 28 15:30: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 AD33816A4CE; Thu, 28 Apr 2005 15:30:37 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2CDB443D5C; Thu, 28 Apr 2005 15:30:37 +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.3/8.13.3) with ESMTP id j3SFYpts023727; Thu, 28 Apr 2005 09:34:51 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <427100CC.8080604@samsco.org> Date: Thu, 28 Apr 2005 09:27:08 -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: Ruslan Ermilov References: <20050428025836.E1ED67306E@freebsd-current.sentex.ca> <20050428145519.GB92579@ip.net.ua> <4270FB26.50805@samsco.org> <20050428152622.GC92579@ip.net.ua> In-Reply-To: <20050428152622.GC92579@ip.net.ua> 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: Darren Reed cc: current@freebsd.org Subject: Re: LINT broken due to ipfilter X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 28 Apr 2005 15:30:37 -0000 Ruslan Ermilov wrote: > Hi Scott, > > On Thu, Apr 28, 2005 at 09:03:02AM -0600, Scott Long wrote: > >>Ruslan Ermilov wrote: >> >>>The changes from sys/modules/ipfilter/Makefile,v 1.17 should be propagated >>>to sys/conf/{files,options,NOTES}. >>> >>> >>>Cheers, >> >>Please feel free to do this. >> > > Well, the attached patch should do it, though I have near zero experience > with ipfilter, so I won't commit it myself. Darren probably will. :-) > > Even after committing this, there's stil a number of compile-time warnings > on 64-bit platforms that should be fixed before this can be compiled. > Before this, it probably makes sense to comment out IPFILTER in LINT, > and let Darren finish polishing his import. > It's been three days, I think that we've all been patient enough. I meant to fix it yesterday, but forgot to check LINT. Please either commit what you have or comment IPFILTER out of LINT. Either way, it's been more than long enough and you should not be afraid of stepping on any toes or being yelled at. Leaving the tree unbuildable for 3 days is unacceptable. I doubt that any other active OSS project would tolerate it, and I'm sure that Sun wouldn't tolerate it either. Scott From owner-freebsd-current@FreeBSD.ORG Thu Apr 28 15:49: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 AE06016A4CE for ; Thu, 28 Apr 2005 15:49:03 +0000 (GMT) Received: from mail.netspace.net.au (thunder.netspace.net.au [203.10.110.71]) by mx1.FreeBSD.org (Postfix) with ESMTP id 62F7E43D60 for ; Thu, 28 Apr 2005 15:49:01 +0000 (GMT) (envelope-from jsg@goblin.cx) Received: from carla.home (dsl-210-15-216-215.VIC.netspace.net.au [210.15.216.215]) by mail.netspace.net.au (Postfix) with ESMTP id 957D84325A for ; Fri, 29 Apr 2005 01:49:00 +1000 (EST) Received: from carla.home (jsg@localhost.home [127.0.0.1]) by carla.home (8.13.4/8.13.1) with ESMTP id j3SFn0aw001764 for ; Fri, 29 Apr 2005 01:49:00 +1000 (EST) Received: (from jsg@localhost) by carla.home (8.13.4/8.13.1/Submit) id j3SFn0fN023009 for freebsd-current@freebsd.org; Fri, 29 Apr 2005 01:49:00 +1000 (EST) Date: Fri, 29 Apr 2005 01:48:59 +1000 From: Jonathan Gray To: freebsd-current@freebsd.org Message-ID: <20050428154859.GA16433@mail.netspace.net.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.8i Subject: incorrect statement on www page X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 28 Apr 2005 15:49:03 -0000 I came across the following incorrect statement when browsing http://www.freebsd.org "FreeBSD is available free of charge and comes with full source code" Sadly I do not think this has been true for some time. Perhaps this might be more appropriate wording: --- index.xsl.old Fri Apr 29 01:19:15 2005 +++ index.xsl Fri Apr 29 01:21:22 2005 @@ -191,7 +191,7 @@

While you might expect an operating system with these features to sell for a high price, FreeBSD is available free of charge - and comes with full source code. If you would like to + and comes with partial source code. If you would like to purchase or download a copy to try out, more information is available.

From owner-freebsd-current@FreeBSD.ORG Thu Apr 28 15: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 2ECAE16A4CE for ; Thu, 28 Apr 2005 15:53:49 +0000 (GMT) Received: from arginine.spc.org (arginine.spc.org [83.167.185.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8D9F743D54 for ; Thu, 28 Apr 2005 15:53:48 +0000 (GMT) (envelope-from bms@spc.org) Received: from localhost (localhost [127.0.0.1]) by arginine.spc.org (Postfix) with ESMTP id 43190651FC; Thu, 28 Apr 2005 16:52:59 +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 27331-02-12; Thu, 28 Apr 2005 16:52:58 +0100 (BST) Received: from empiric.dek.spc.org (host81-134-198-100.in-addr.btopenworld.com [81.134.198.100]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by arginine.spc.org (Postfix) with ESMTP id 56F98651FA; Thu, 28 Apr 2005 16:52:56 +0100 (BST) Received: by empiric.dek.spc.org (Postfix, from userid 1001) id 090B5623B; Thu, 28 Apr 2005 16:53:42 +0100 (BST) Date: Thu, 28 Apr 2005 16:53:42 +0100 From: Bruce M Simpson To: "M. Warner Losh" Message-ID: <20050428155342.GB747@empiric.icir.org> Mail-Followup-To: "M. Warner Losh" , fierykylin@gmail.com, freebsd-current@freebsd.org References: <87ab37ab050425205527cecaf3@mail.gmail.com> <20050427113418.GD5585@empiric.icir.org> <20050427.224439.91313267.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050427.224439.91313267.imp@bsdimp.com> cc: fierykylin@gmail.com cc: freebsd-current@freebsd.org Subject: Re: when will pci hotplug 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, 28 Apr 2005 15:53:49 -0000 On Wed, Apr 27, 2005 at 10:44:39PM -0600, M. Warner Losh wrote: > I have some ideas on this one... I'll try to implement them, but for > -current. I'd also like to get some of the simpler parts of your > patches into -current as well. Any objection to my merging some of > them in? Not at all, please feel free to do so as I may not get around to it; #include Regards, BMS From owner-freebsd-current@FreeBSD.ORG Thu Apr 28 16:03: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 32ACF16A4CE for ; Thu, 28 Apr 2005 16:03:51 +0000 (GMT) Received: from outcold.yadt.co.uk (outcold.yadt.co.uk [81.187.204.178]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9603A43D1F for ; Thu, 28 Apr 2005 16:03:49 +0000 (GMT) (envelope-from davidt@yadt.co.uk) Received: from localhost (localhost [127.0.0.1]) by outcold.yadt.co.uk (Postfix) with ESMTP id A6C261DD59C; Thu, 28 Apr 2005 17:04:20 +0100 (BST) Received: from outcold.yadt.co.uk ([127.0.0.1]) by localhost (outcold.yadt.co.uk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01466-14; Thu, 28 Apr 2005 17:04:14 +0100 (BST) Received: by outcold.yadt.co.uk (Postfix, from userid 1001) id 27C251DD58F; Thu, 28 Apr 2005 17:04:14 +0100 (BST) Date: Thu, 28 Apr 2005 17:04:14 +0100 From: David Taylor To: Jonathan Gray Message-ID: <20050428160414.GA21634@outcold.yadt.co.uk> Mail-Followup-To: Jonathan Gray , freebsd-current@freebsd.org References: <20050428154859.GA16433@mail.netspace.net.au> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: <20050428154859.GA16433@mail.netspace.net.au> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at yadt.co.uk cc: freebsd-current@freebsd.org Subject: Re: incorrect statement on www page X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 28 Apr 2005 16:03:51 -0000 On Fri, 29 Apr 2005, Jonathan Gray wrote: > I came across the following incorrect statement when > browsing http://www.freebsd.org > > "FreeBSD is available free of charge and comes with full source code" > > Sadly I do not think this has been true for some time. > > Perhaps this might be more appropriate wording: > > - and comes with full source code. If you would like to > + and comes with partial source code. If you would like to Perhaps you could explain to those of us that have no idea what you're talking about. What parts of the source code are missing? -- David Taylor From owner-freebsd-current@FreeBSD.ORG Thu Apr 28 16:05: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 5BF2116A4CE; Thu, 28 Apr 2005 16:05:15 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6FF6243D4C; Thu, 28 Apr 2005 16:05:12 +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.3/8.13.3) with ESMTP id j3SG9PZU023879; Thu, 28 Apr 2005 10:09:26 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <427108E6.4010202@samsco.org> Date: Thu, 28 Apr 2005 10:01:42 -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: Darren Reed References: <20050428025836.E1ED67306E@freebsd-current.sentex.ca> <20050428145519.GB92579@ip.net.ua> <4270FB26.50805@samsco.org> <20050428152622.GC92579@ip.net.ua> <427100CC.8080604@samsco.org> <20050428155451.GA2192@hub.freebsd.org> In-Reply-To: <20050428155451.GA2192@hub.freebsd.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: Darren Reed cc: Ruslan Ermilov cc: current@FreeBSD.ORG Subject: Re: LINT broken due to ipfilter X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 28 Apr 2005 16:05:15 -0000 Darren Reed wrote: > On Thu, Apr 28, 2005 at 09:27:08AM -0600, Scott Long wrote: > >>Leaving the tree unbuildable for 3 days is unacceptable. I doubt that >>any other active OSS project would tolerate it, and I'm sure that Sun >>wouldn't tolerate it either. > > > Well, FreeBSD seems to have a history of allowing this...I seem to recall > some other part of the build being broken when I did the initial commit > for ipf...not to mention there being many times in the past when I've seen > comments about the build being broken in one way or another. Blaming this botch on someone else isn't acceptable either. To my recollection, you have not done a successfull ipfilter import in at least two years. Yes, we all appreciate your contribution with IPFilter, but it's also disruptive, this time especially. > > ...and to compare it with Sun...there's one build command (equivalent of > building userland + kernel bits) that you have to submit with your request > to integrate. But to compare the effort I can spend there vs here, well, > this gets whatever time I have available, which maybe 1 or 4 or any number > of hours or minutes inbetween, plus it is upto me to provide my own > resources. You can't compare doing development work that you get paid for > with that you do in your own free time, at your own expense. Anyone who > thinks you can is sadly mistaken. All of us have varying levels of time > we can put into the project and I'm sure we all put it as much effort as > we can, given all the other constraints and requirements. > > My single biggest issue remains the number of boxes needed to keep things > compiling on FreeBSD. 4.11, 5.4, -current. That is a really tough ask > on anyone and last I checked, there's only a ref4 and a ref5. > > So....if you want to make it easier for people like me to make sure they > haven't broken the build, put a target in src/Makefile that achieves this. > That is, buildworld and buildkernel and build LINT and whatever else for > a single platform. Or at least I think buildworld and buildkernel are > required, seperately. "universe" is too much. 'make universe' is the command. And given that you still have build problems on 64-bit machines, this command is not 'too much'. There are fast freebsd.org machines that can run this. If you don't know, then please ask. > > Having said all that, I appreciate any assistance others can give, > especially clues on what to do with rescue. Ruslan already replied with a patch several hours ago. But yes, many thanks to Ruslan and Giorgos for working on this. Scott From owner-freebsd-current@FreeBSD.ORG Thu Apr 28 16:07: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 1518F16A4CE for ; Thu, 28 Apr 2005 16:07:09 +0000 (GMT) Received: from mail.netspace.net.au (cumulus.netspace.net.au [203.10.110.72]) by mx1.FreeBSD.org (Postfix) with ESMTP id BA3EB43D55 for ; Thu, 28 Apr 2005 16:07:08 +0000 (GMT) (envelope-from jsg@goblin.cx) Received: from carla.home (dsl-210-15-216-215.VIC.netspace.net.au [210.15.216.215]) by mail.netspace.net.au (Postfix) with ESMTP id 31D1F71D4C for ; Fri, 29 Apr 2005 02:07:07 +1000 (EST) Received: from carla.home (jsg@localhost.home [127.0.0.1]) by carla.home (8.13.4/8.13.1) with ESMTP id j3SG76DC017137 for ; Fri, 29 Apr 2005 02:07:06 +1000 (EST) Received: (from jsg@localhost) by carla.home (8.13.4/8.13.1/Submit) id j3SG76Cq015911 for freebsd-current@freebsd.org; Fri, 29 Apr 2005 02:07:06 +1000 (EST) Date: Fri, 29 Apr 2005 02:07:06 +1000 From: Jonathan Gray To: freebsd-current@freebsd.org Message-ID: <20050428160706.GA2033@mail.netspace.net.au> References: <20050428154859.GA16433@mail.netspace.net.au> <20050428160414.GA21634@outcold.yadt.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050428160414.GA21634@outcold.yadt.co.uk> User-Agent: Mutt/1.5.8i Subject: Re: incorrect statement on www page X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 28 Apr 2005 16:07:09 -0000 On Thu, Apr 28, 2005 at 05:04:14PM +0100, David Taylor wrote: > On Fri, 29 Apr 2005, Jonathan Gray wrote: > > I came across the following incorrect statement when > > browsing http://www.freebsd.org > > > > "FreeBSD is available free of charge and comes with full source code" > > > > Sadly I do not think this has been true for some time. > > > > Perhaps this might be more appropriate wording: > > > > - and comes with full source code. If you would like to > > + and comes with partial source code. If you would like to > > Perhaps you could explain to those of us that have no idea what you're > talking about. What parts of the source code are missing? At least the following, perhaps more: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/contrib/dev/ath/public/ (lot of stuff) http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/hptmv/i386-elf.raid.o.uu http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/contrib/dev/nve/i386/nvenetlib.o.bz2.uu http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/contrib/dev/nve/amd64/nvenetlib.o.bz2.uu From owner-freebsd-current@FreeBSD.ORG Thu Apr 28 16:10: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 8848816A4CE; Thu, 28 Apr 2005 16:10:33 +0000 (GMT) Received: from mail-in-07.arcor-online.net (mail-in-07.arcor-online.net [151.189.21.47]) by mx1.FreeBSD.org (Postfix) with ESMTP id F3DF543D54; Thu, 28 Apr 2005 16:10:32 +0000 (GMT) (envelope-from lofi@freebsd.org) Received: from mail-in-09-z2.arcor-online.net (mail-in-09-z2.arcor-online.net [151.189.8.21]) by mail-in-07.arcor-online.net (Postfix) with ESMTP id 1A0B123B9; Thu, 28 Apr 2005 18:10:31 +0200 (CEST) Received: from mail-in-06.arcor-online.net (mail-in-06.arcor-online.net [151.189.21.46]) by mail-in-09-z2.arcor-online.net (Postfix) with ESMTP id 4C2DB5C662; Thu, 28 Apr 2005 09:20:49 +0200 (CEST) Received: from lofi.dyndns.org (dsl-213-023-208-012.arcor-ip.net [213.23.208.12]) by mail-in-06.arcor-online.net (Postfix) with ESMTP id 02E4610FB; Thu, 28 Apr 2005 09:20:47 +0200 (CEST) Received: from kiste.my.domain (lofi@kiste.my.domain [192.168.8.4]) (authenticated bits=0) by lofi.dyndns.org (8.13.3/8.13.3) with ESMTP id j3S46k2U089149 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Thu, 28 Apr 2005 06:06:46 +0200 (CEST) (envelope-from lofi@freebsd.org) From: Michael Nottebrock To: freebsd-current@freebsd.org Date: Thu, 28 Apr 2005 06:06:43 +0200 User-Agent: KMail/1.8 References: <57436.216.177.243.42.1114582155.localmail@webmail.dnswatch.com> <1072.172.16.0.199.1114624239.squirrel@172.16.0.1> <200504280257.j3S2vXEO007344@dungeon.home> In-Reply-To: <200504280257.j3S2vXEO007344@dungeon.home> X-Face: =Ym$`&q\+S2X$4`X%x%6"L4>Y,$]<":'L%c9"#7#`2tb&E&wsN31on!N\)3BD[g<=?utf-8?q?=2EjnfV=5B=0A=093=23?=>XchLK,o;>bD>c:]^;:>0>vyZ.X[,63GW`&M>}nYnr]-Fp``,[[@lJ!QL|sfW!s)=?utf-8?q?A2!*=0A=09vNkB/=7CL-?=>&QdSbQg X-Virus-Scanned: by amavisd-new cc: Mike Jakubik cc: null@dnswatch.com cc: current@freebsd.org cc: Stephen McKay Subject: Re: boot banner project X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 28 Apr 2005 16:10:33 -0000 --nextPart1993315.XmoHUQV54L Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Thursday, 28. April 2005 04:57, Stephen McKay wrote: > Put me in the flashiness hating camp also. I especially dislike the > Linux 60Hz super-eye-destroying graphical boot, which I have to go to the > trouble of defeating as it is the default. With CRTs on the retreat though, less and less people care about refresh=20 rates ... you'll probably join that camp at some point as well. :-) =2D-=20 ,_, | Michael Nottebrock | lofi@freebsd.org (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org --nextPart1993315.XmoHUQV54L Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQBCcGFVXhc68WspdLARAv2iAJ0b2aw6rZrBgT6lgXMPZ+Ua+i7CkQCcDhYT vgBDHnvrITCL+TQd4p1Cbrc= =+Z1M -----END PGP SIGNATURE----- --nextPart1993315.XmoHUQV54L-- From owner-freebsd-current@FreeBSD.ORG Thu Apr 28 16:10: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 8848816A4CE; Thu, 28 Apr 2005 16:10:33 +0000 (GMT) Received: from mail-in-07.arcor-online.net (mail-in-07.arcor-online.net [151.189.21.47]) by mx1.FreeBSD.org (Postfix) with ESMTP id F3DF543D54; Thu, 28 Apr 2005 16:10:32 +0000 (GMT) (envelope-from lofi@freebsd.org) Received: from mail-in-09-z2.arcor-online.net (mail-in-09-z2.arcor-online.net [151.189.8.21]) by mail-in-07.arcor-online.net (Postfix) with ESMTP id 1A0B123B9; Thu, 28 Apr 2005 18:10:31 +0200 (CEST) Received: from mail-in-06.arcor-online.net (mail-in-06.arcor-online.net [151.189.21.46]) by mail-in-09-z2.arcor-online.net (Postfix) with ESMTP id 4C2DB5C662; Thu, 28 Apr 2005 09:20:49 +0200 (CEST) Received: from lofi.dyndns.org (dsl-213-023-208-012.arcor-ip.net [213.23.208.12]) by mail-in-06.arcor-online.net (Postfix) with ESMTP id 02E4610FB; Thu, 28 Apr 2005 09:20:47 +0200 (CEST) Received: from kiste.my.domain (lofi@kiste.my.domain [192.168.8.4]) (authenticated bits=0) by lofi.dyndns.org (8.13.3/8.13.3) with ESMTP id j3S46k2U089149 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Thu, 28 Apr 2005 06:06:46 +0200 (CEST) (envelope-from lofi@freebsd.org) From: Michael Nottebrock To: freebsd-current@freebsd.org Date: Thu, 28 Apr 2005 06:06:43 +0200 User-Agent: KMail/1.8 References: <57436.216.177.243.42.1114582155.localmail@webmail.dnswatch.com> <1072.172.16.0.199.1114624239.squirrel@172.16.0.1> <200504280257.j3S2vXEO007344@dungeon.home> In-Reply-To: <200504280257.j3S2vXEO007344@dungeon.home> X-Face: =Ym$`&q\+S2X$4`X%x%6"L4>Y,$]<":'L%c9"#7#`2tb&E&wsN31on!N\)3BD[g<=?utf-8?q?=2EjnfV=5B=0A=093=23?=>XchLK,o;>bD>c:]^;:>0>vyZ.X[,63GW`&M>}nYnr]-Fp``,[[@lJ!QL|sfW!s)=?utf-8?q?A2!*=0A=09vNkB/=7CL-?=>&QdSbQg X-Virus-Scanned: by amavisd-new cc: Mike Jakubik cc: null@dnswatch.com cc: current@freebsd.org cc: Stephen McKay Subject: Re: boot banner project X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 28 Apr 2005 16:10:33 -0000 --nextPart1993315.XmoHUQV54L Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Thursday, 28. April 2005 04:57, Stephen McKay wrote: > Put me in the flashiness hating camp also. I especially dislike the > Linux 60Hz super-eye-destroying graphical boot, which I have to go to the > trouble of defeating as it is the default. With CRTs on the retreat though, less and less people care about refresh=20 rates ... you'll probably join that camp at some point as well. :-) =2D-=20 ,_, | Michael Nottebrock | lofi@freebsd.org (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org --nextPart1993315.XmoHUQV54L Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQBCcGFVXhc68WspdLARAv2iAJ0b2aw6rZrBgT6lgXMPZ+Ua+i7CkQCcDhYT vgBDHnvrITCL+TQd4p1Cbrc= =+Z1M -----END PGP SIGNATURE----- --nextPart1993315.XmoHUQV54L-- From owner-freebsd-current@FreeBSD.ORG Thu Apr 28 16: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 0C50416A4CF; Thu, 28 Apr 2005 16:13:24 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6BAFD43D3F; Thu, 28 Apr 2005 16:13:23 +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.3/8.13.3) with ESMTP id j3SGHZEH023934; Thu, 28 Apr 2005 10:17:36 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <42710AD1.9010602@samsco.org> Date: Thu, 28 Apr 2005 10:09:53 -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: Harti Brandt References: <4270762E.3050508@chuckr.org> <20050428164808.X821@beagle.kn.op.dlr.de> <4270FA78.6030406@samsco.org> <20050428170600.L821@beagle.kn.op.dlr.de> In-Reply-To: <20050428170600.L821@beagle.kn.op.dlr.de> 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: Chuck Robey cc: current Subject: Re: junk after endif X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 28 Apr 2005 16:13:24 -0000 Harti Brandt wrote: > On Thu, 28 Apr 2005, Scott Long wrote: > > SL>Harti Brandt wrote: > SL>> On Thu, 28 Apr 2005, Chuck Robey wrote: > SL>> > SL>> CR>in making the environment for my new sparc box, I'm building a new > SL>> buildworld > SL>> CR>for the sparc, that that's giving me REAMS of useless errors about "junk > SL>> at > SL>> CR>the end of the line", you know what it is from watching the error come > SL>> up > SL>> CR>from cpp listings...except that these come from make, not from C code... > SL>> CR>having this come up in the situation I'm in, with zero (besides merely a > SL>> CR>KERNCONF) in the /etc/make.conf, then having this error come up so often > SL>> it > SL>> CR>obscures the real listing is egregiously crazy. > SL>> CR> > SL>> CR>So, the fix falls into one of these categories: > SL>> CR> > SL>> CR>1) there is a magic incantation I don't know, and don't have time to > SL>> hunt > SL>> CR>down, that kills this warning in make, and I need to know this, but > SL>> that's > SL>> CR>not the fix ... the fix is (possibly) to make the default action that > SL>> this is > SL>> CR>NOT a warning. > SL>> CR> > SL>> CR>2) I know that many folks like to do this to endif's, but it's an > SL>> warning in > SL>> CR>C, and we should tell the folks who like it "tough" and take them out. > SL>> CR> > SL>> CR>However it's decided, to squish the warning or to squish the tags, it's > SL>> CR>unacceptable to leave those semantically useless warnings laying about, > SL>> CR>hiding real problems. > SL>> > SL>> These warnings come only if you build with a /usr/share/mk which is not > SL>> up-to-date and an up-to-date make. (It may also be that you slipped with > SL>> your sources into the small window between the two commits). > SL>> > SL>> As far as I can see this can legally happen only when building 5.4 or > SL>> earlier on a current box (I have committed the fix to /usr/share/mk in > SL>> RELENG_5, but cannot do this because this doesn't seem to fall under the > SL>> committable categories for RELENG_5_*). > SL>> > SL>> harti > SL> > SL>In general, I think that this warning is a bad idea. It (along with the > SL>NO_FOO wanrings that are also a bad idea) make it very hard to build > SL>prior releases and snapshots from 6-current. I really cannot see how > SL>this warning benefits anyone or solves a problem; all it does it create > SL>an unneccesary mess. Yes, building things like I've described here > SL>isn't "supported", but putting up needless roadblocks and making the > SL>definition of "supported" be very narrow makes using FreeBSD very hard. > SL>Please eliminate this warning, or put it under a 'pendatic' flag only. > > I found at least one incarnation of an expression after an .else in a port > Makefile where the writer obviously expected the expression to be > processed. The problem was that the author wrote .else instead of .elif. > We found also a number of incarnations of .elseif statements that make > silently happend to process as .else. Makefiles are inherently hard to > debug (because of the crufty syntax and the sloppiness of our make), so > every warning maybe helpful. I agree that this should be under the control > of an option and, in fact, I was going to implement just that - its just > not that high on my list. But as you ask so nicely about it I can move it > up the list and do it in the next days. > > Regards, > harti Thanks a lot! Scott From owner-freebsd-current@FreeBSD.ORG Thu Apr 28 16:23: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 1890416A4CE for ; Thu, 28 Apr 2005 16:23:26 +0000 (GMT) Received: from arginine.spc.org (arginine.spc.org [83.167.185.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id A624643D39 for ; Thu, 28 Apr 2005 16:23:25 +0000 (GMT) (envelope-from bms@spc.org) Received: from localhost (localhost [127.0.0.1]) by arginine.spc.org (Postfix) with ESMTP id D461F65339; Thu, 28 Apr 2005 17:22:36 +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 27595-02-3; Thu, 28 Apr 2005 17:22:36 +0100 (BST) Received: from empiric.dek.spc.org (host81-134-198-100.in-addr.btopenworld.com [81.134.198.100]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by arginine.spc.org (Postfix) with ESMTP id 04DB465219; Thu, 28 Apr 2005 17:22:36 +0100 (BST) Received: by empiric.dek.spc.org (Postfix, from userid 1001) id CE1F0623B; Thu, 28 Apr 2005 17:23:22 +0100 (BST) Date: Thu, 28 Apr 2005 17:23:22 +0100 From: Bruce M Simpson To: Jonathan Gray Message-ID: <20050428162322.GE747@empiric.icir.org> Mail-Followup-To: Jonathan Gray , freebsd-current@freebsd.org References: <20050428154859.GA16433@mail.netspace.net.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050428154859.GA16433@mail.netspace.net.au> cc: freebsd-current@freebsd.org Subject: Re: incorrect statement on www page X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 28 Apr 2005 16:23:26 -0000 On Fri, Apr 29, 2005 at 01:48:59AM +1000, Jonathan Gray wrote: > I came across the following incorrect statement when > browsing http://www.freebsd.org > > "FreeBSD is available free of charge and comes with full source code" > > Sadly I do not think this has been true for some time. I disagree; the wording isn't misleading. However, to address such concerns, it might be better worded as "comes with full source code, and also ships with some binary driver components". Regards, BMS From owner-freebsd-current@FreeBSD.ORG Thu Apr 28 16:47: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 C2C4916A4CE for ; Thu, 28 Apr 2005 16:47:30 +0000 (GMT) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8419343D5E for ; Thu, 28 Apr 2005 16:47:30 +0000 (GMT) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) j3SGlUfI042228; Thu, 28 Apr 2005 09:47:30 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost)j3SGlUx4042227; Thu, 28 Apr 2005 09:47:30 -0700 (PDT) (envelope-from sgk) Date: Thu, 28 Apr 2005 09:47:30 -0700 From: Steve Kargl To: Jonathan Gray Message-ID: <20050428164730.GB34380@troutmask.apl.washington.edu> References: <20050428154859.GA16433@mail.netspace.net.au> <20050428160414.GA21634@outcold.yadt.co.uk> <20050428160706.GA2033@mail.netspace.net.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050428160706.GA2033@mail.netspace.net.au> User-Agent: Mutt/1.4.2.1i cc: freebsd-current@freebsd.org Subject: Re: incorrect statement on www page X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 28 Apr 2005 16:47:30 -0000 On Fri, Apr 29, 2005 at 02:07:06AM +1000, Jonathan Gray wrote: > On Thu, Apr 28, 2005 at 05:04:14PM +0100, David Taylor wrote: > > On Fri, 29 Apr 2005, Jonathan Gray wrote: > > > I came across the following incorrect statement when > > > browsing http://www.freebsd.org > > > > > > "FreeBSD is available free of charge and comes with full source code" > > > > > > Sadly I do not think this has been true for some time. > > > > > > Perhaps this might be more appropriate wording: > > > > > > - and comes with full source code. If you would like to > > > + and comes with partial source code. If you would like to > > > > Perhaps you could explain to those of us that have no idea what you're > > talking about. What parts of the source code are missing? > > At least the following, perhaps more: > > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/contrib/dev/ath/public/ (lot of stuff) You need to specify the (lots of stuff) better. Because the following are found on my system. > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/hptmv/i386-elf.raid.o.uu > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/contrib/dev/nve/i386/nvenetlib.o.bz2.uu > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" -- Steve From owner-freebsd-current@FreeBSD.ORG Thu Apr 28 16:57: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 9F34C16A4CE for ; Thu, 28 Apr 2005 16:57:12 +0000 (GMT) Received: from energistic.com (mail.energistic.com [216.54.148.60]) by mx1.FreeBSD.org (Postfix) with ESMTP id 46FDD43D5C for ; Thu, 28 Apr 2005 16:57:12 +0000 (GMT) (envelope-from steve@energistic.com) Received: from energistic.com (steve@localhost.energistic.com [127.0.0.1]) by energistic.com (8.13.3/8.13.3) with ESMTP id j3SGvAcC005867; Thu, 28 Apr 2005 11:57:10 -0500 (EST) (envelope-from steve@energistic.com) Received: (from steve@localhost) by energistic.com (8.13.3/8.13.3/Submit) id j3SGvAZg005841; Thu, 28 Apr 2005 11:57:10 -0500 (EST) (envelope-from steve) Date: Thu, 28 Apr 2005 11:57:10 -0500 From: Steve Ames To: Steve Kargl Message-ID: <20050428165709.GA76059@energistic.com> References: <20050428154859.GA16433@mail.netspace.net.au> <20050428160414.GA21634@outcold.yadt.co.uk> <20050428160706.GA2033@mail.netspace.net.au> <20050428164730.GB34380@troutmask.apl.washington.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050428164730.GB34380@troutmask.apl.washington.edu> User-Agent: Mutt/1.5.9i X-Spam-Status: No, score=-7.9 required=5.0 tests=AWL,BAYES_20,SPF_HELO_PASS, SPF_PASS,USER_IN_WHITELIST_TO autolearn=ham version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on energistic.com cc: freebsd-current@freebsd.org cc: Jonathan Gray Subject: Re: incorrect statement on www page X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 28 Apr 2005 16:57:12 -0000 On Thu, Apr 28, 2005 at 09:47:30AM -0700, Steve Kargl wrote: > You need to specify the (lots of stuff) better. > > Because the following are found on my system. > > > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/hptmv/i386-elf.raid.o.uu > > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/contrib/dev/nve/i386/nvenetlib.o.bz2.uu Sure. But they aren't source. This is rather a sad discussion as 3rd party drivers really aren't part of the OS. -Steve From owner-freebsd-current@FreeBSD.ORG Thu Apr 28 17:54: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 27C9616A4CF; Thu, 28 Apr 2005 17:54:56 +0000 (GMT) Received: from april.chuckr.org (april.chuckr.org [66.92.151.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id C31A243D48; Thu, 28 Apr 2005 17:54: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 1994F1213F; Thu, 28 Apr 2005 13:50:20 -0400 (EDT) Message-ID: <4271235F.1070609@chuckr.org> Date: Thu, 28 Apr 2005 17:54:39 +0000 From: Chuck Robey User-Agent: Mozilla Thunderbird 1.0 (X11/20050316) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Scott Long References: <4270762E.3050508@chuckr.org> <20050428164808.X821@beagle.kn.op.dlr.de> <4270FA78.6030406@samsco.org> <20050428170600.L821@beagle.kn.op.dlr.de> <42710AD1.9010602@samsco.org> In-Reply-To: <42710AD1.9010602@samsco.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: current cc: Harti Brandt Subject: Re: junk after endif X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 28 Apr 2005 17:54:56 -0000 Scott Long wrote: > Harti Brandt wrote: > >> On Thu, 28 Apr 2005, Scott Long wrote: >> >> SL>Harti Brandt wrote: >> SL>> On Thu, 28 Apr 2005, Chuck Robey wrote: >> SL>> SL>> CR>in making the environment for my new sparc box, I'm >> building a new >> SL>> buildworld >> SL>> CR>for the sparc, that that's giving me REAMS of useless errors >> about "junk >> SL>> at >> SL>> CR>the end of the line", you know what it is from watching the >> error come >> SL>> up >> SL>> CR>from cpp listings...except that these come from make, not from >> C code... >> SL>> CR>having this come up in the situation I'm in, with zero >> (besides merely a >> SL>> CR>KERNCONF) in the /etc/make.conf, then having this error come >> up so often >> SL>> it >> SL>> CR>obscures the real listing is egregiously crazy. >> SL>> CR> >> SL>> CR>So, the fix falls into one of these categories: >> SL>> CR> >> SL>> CR>1) there is a magic incantation I don't know, and don't have >> time to >> SL>> hunt >> SL>> CR>down, that kills this warning in make, and I need to know >> this, but >> SL>> that's >> SL>> CR>not the fix ... the fix is (possibly) to make the default >> action that >> SL>> this is >> SL>> CR>NOT a warning. >> SL>> CR> >> SL>> CR>2) I know that many folks like to do this to endif's, but it's an >> SL>> warning in >> SL>> CR>C, and we should tell the folks who like it "tough" and take >> them out. >> SL>> CR> >> SL>> CR>However it's decided, to squish the warning or to squish the >> tags, it's >> SL>> CR>unacceptable to leave those semantically useless warnings >> laying about, >> SL>> CR>hiding real problems. >> SL>> SL>> These warnings come only if you build with a /usr/share/mk >> which is not >> SL>> up-to-date and an up-to-date make. (It may also be that you >> slipped with >> SL>> your sources into the small window between the two commits). >> SL>> SL>> As far as I can see this can legally happen only when >> building 5.4 or >> SL>> earlier on a current box (I have committed the fix to >> /usr/share/mk in >> SL>> RELENG_5, but cannot do this because this doesn't seem to fall >> under the >> SL>> committable categories for RELENG_5_*). >> SL>> SL>> harti How did it happen? I used the most recent 5.3 cdrom images to install from, then used RELENG_5_4 as a -r to cvs when I pulled out sources to rebuild from. This is NOT an odd combination, rather it's going to be a pretty common one pretty soon. >> SL> >> SL>In general, I think that this warning is a bad idea. It (along >> with the >> SL>NO_FOO wanrings that are also a bad idea) make it very hard to build >> SL>prior releases and snapshots from 6-current. I really cannot see how >> SL>this warning benefits anyone or solves a problem; all it does it >> create >> SL>an unneccesary mess. Yes, building things like I've described here >> SL>isn't "supported", but putting up needless roadblocks and making the >> SL>definition of "supported" be very narrow makes using FreeBSD very >> hard. >> SL>Please eliminate this warning, or put it under a 'pendatic' flag only. >> >> I found at least one incarnation of an expression after an .else in a >> port Makefile where the writer obviously expected the expression to be >> processed. The problem was that the author wrote .else instead of >> .elif. We found also a number of incarnations of .elseif statements >> that make silently happend to process as .else. Makefiles are >> inherently hard to debug (because of the crufty syntax and the >> sloppiness of our make), so every warning maybe helpful. I agree that >> this should be under the control of an option and, in fact, I was >> going to implement just that - its just not that high on my list. But >> as you ask so nicely about it I can move it up the list and do it in >> the next days. Good, I personally believe the warning has very little value. >> >> Regards, >> harti > > > Thanks a lot! > > Scott > _______________________________________________ > 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 28 18:08: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 9A66616A4CE; Thu, 28 Apr 2005 18:08:58 +0000 (GMT) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 86A7B43D1F; Thu, 28 Apr 2005 18:08:57 +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 j3SIC0A0075334; Thu, 28 Apr 2005 21:12:00 +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 31307-10; Thu, 28 Apr 2005 21:07:51 +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 j3SIBxe0075331 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Apr 2005 21:11:59 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.13.3/8.13.3) id j3SI7piB093955; Thu, 28 Apr 2005 21:07:51 +0300 (EEST) (envelope-from ru) Date: Thu, 28 Apr 2005 21:07:46 +0300 From: Ruslan Ermilov To: Darren Reed Message-ID: <20050428180746.GA93281@ip.net.ua> References: <20050428025836.E1ED67306E@freebsd-current.sentex.ca> <20050428145519.GB92579@ip.net.ua> <4270FB26.50805@samsco.org> <20050428152622.GC92579@ip.net.ua> <427100CC.8080604@samsco.org> <20050428155451.GA2192@hub.freebsd.org> <427108E6.4010202@samsco.org> <20050428162755.GA5668@hub.freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="PNTmBPCT7hxwcZjr" Content-Disposition: inline In-Reply-To: <20050428162755.GA5668@hub.freebsd.org> User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new at ip.net.ua cc: Darren Reed cc: current@FreeBSD.org Subject: Re: LINT broken due to ipfilter X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 28 Apr 2005 18:08:58 -0000 --PNTmBPCT7hxwcZjr Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Apr 28, 2005 at 04:27:55PM +0000, Darren Reed wrote: [...] > Hmmm, well the impression I got from reading the Makfile was that it'd > build sparc/arm/x86/everything. I don't have the diskspace, never mind > CPU for that...could we sittle for a galactic build target that builds > everything required (user + kernel + LINT) for a single platform? >=20 > Is sledge.freebsd.org the build box you're referring to here? Or is there > another that's available for us? >=20 If you have a fast 5.x i386 box, the command to build 6.x world and kernel for amd64 is (given that /usr/src is populated by 6.x sources): cd /usr/src make buildworld buildkernel TARGET_ARCH=3Damd64 It's documented in the build(7) manpage, to some extent. I've put enough effort into making it really produce bits that are installable and runnable on the target platform (only "mkmagic" tool has endianness issues at the moment). Note: this only works on relatively recent 6.x. Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --PNTmBPCT7hxwcZjr Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFCcSZyqRfpzJluFF4RAlxfAKCZRXlEt41Us/6jmwFHymCtbIsaRACgjQL4 zYdtH6tRfmJNR/+jg4uof5E= =4m/9 -----END PGP SIGNATURE----- --PNTmBPCT7hxwcZjr-- From owner-freebsd-current@FreeBSD.ORG Thu Apr 28 19:38: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 43B2B16A4CE for ; Thu, 28 Apr 2005 19:38:59 +0000 (GMT) Received: from mailserv1.neuroflux.com (ns2.neuroflux.com [204.228.228.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id C94CD43D31 for ; Thu, 28 Apr 2005 19:38:58 +0000 (GMT) (envelope-from ryans@gamersimpact.com) Received: (qmail 75790 invoked by uid 89); 28 Apr 2005 19:39:26 -0000 Received: from unknown (HELO www2.neuroflux.com) (127.0.0.1) by localhost with SMTP; 28 Apr 2005 19:39:26 -0000 Received: from 66.166.104.222 (SquirrelMail authenticated user ryans@gamersimpact.com); by www2.neuroflux.com with HTTP; Thu, 28 Apr 2005 13:39:26 -0600 (MDT) Message-ID: <1587.66.166.104.222.1114717166.squirrel@66.166.104.222> In-Reply-To: <200504280606.45379.lofi@freebsd.org> References: <57436.216.177.243.42.1114582155.localmail@webmail.dnswatch.com> <1072.172.16.0.199.1114624239.squirrel@172.16.0.1> <200504280257.j3S2vXEO007344@dungeon.home> <200504280606.45379.lofi@freebsd.org> Date: Thu, 28 Apr 2005 13:39:26 -0600 (MDT) From: "Ryan Sommers" To: "Michael Nottebrock" User-Agent: SquirrelMail/1.4.3a X-Mailer: SquirrelMail/1.4.3a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal cc: freebsd-current@freebsd.org cc: Stephen McKay Subject: Re: boot banner project X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 28 Apr 2005 19:38:59 -0000 Michael Nottebrock said: > With CRTs on the retreat though, less and less people care about refresh > rates ... you'll probably join that camp at some point as well. :-) > I wouldn't count them out just yet! I still have a 7 year old 19" Sony Trinitron that is kicking butt, despite the fact that it has about 10 battle scars from rolling around in a truck bed (don't ask). I haven't switched it with an LCD just because it still has better clarity and color quality than any LCD I've seen. -- Ryan Sommers ryans@gamersimpact.com From owner-freebsd-current@FreeBSD.ORG Thu Apr 28 19:39: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 C6FE916A4CE; Thu, 28 Apr 2005 19:39:19 +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 8A62843D41; Thu, 28 Apr 2005 19:39:16 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 08ED551F7B; Thu, 28 Apr 2005 12:39:16 -0700 (PDT) Date: Thu, 28 Apr 2005 12:39:15 -0700 From: Kris Kennaway To: Kris Kennaway Message-ID: <20050428193915.GA29513@xor.obsecurity.org> References: <20050428193442.GA29477@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="qMm9M+Fa2AknHoGS" Content-Disposition: inline In-Reply-To: <20050428193442.GA29477@xor.obsecurity.org> User-Agent: Mutt/1.4.2.1i cc: current@FreeBSD.org cc: jroberson@FreeBSD.org Subject: Re: panic in ffs_valloc() X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 28 Apr 2005 19:39:19 -0000 --qMm9M+Fa2AknHoGS Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Apr 28, 2005 at 12:34:42PM -0700, Kris Kennaway wrote: > e4500 running HEAD with mpsafevfs: >=20 > panic: trap: fast data access mmu miss > cpuid =3D 6 > KDB: enter: panic > [thread pid 15719 tid 100451 ] > Stopped at kdb_enter+0x3c: ta %xcc, 1 > db> wh > Tracing pid 15719 tid 100451 td 0xfffff800ae29e000 > panic() at panic+0x16c > trap() at trap+0x45c > -- fast data access mmu miss tar=3D0 %o7=3D0xc02914f0 -- > ffs_valloc() at ffs_valloc+0x144 > ufs_makeinode() at ufs_makeinode+0x3c > ufs_create() at ufs_create+0x34 > VOP_CREATE_APV() at VOP_CREATE_APV+0xb4 > vn_open_cred() at vn_open_cred+0x188 > vn_open() at vn_open+0x18 > kern_open() at kern_open+0x8c > open() at open+0x14 > syscall() at syscall+0x2fc > -- syscall (5, FreeBSD ELF64, open) %o7=3D0x403499ac -- Another one (gdb53 analysis below): db> wh Tracing pid 3175 tid 100328 td 0xfffff800d3c06000 panic() at panic+0x16c trap() at trap+0x45c -- fast data access mmu miss tar=3D0 %o7=3D0xc02914f0 -- ffs_valloc() at ffs_valloc+0x144 ufs_makeinode() at ufs_makeinode+0x3c ufs_create() at ufs_create+0x34 VOP_CREATE_APV() at VOP_CREATE_APV+0xb4 vn_open_cred() at vn_open_cred+0x188 vn_open() at vn_open+0x18 kern_open() at kern_open+0x8c open() at open+0x14 syscall() at syscall+0x2fc -- syscall (5, FreeBSD ELF64, open) %o7=3D0x40342c20 -- userland() at 0x406f3068 user trace: trap %o7=3D0x40342c20 pc 0x406f3068, sp 0x7fdffffd7f1 pc 0x40342888, sp 0x7fdffffd8b1 pc 0x104364, sp 0x7fdffffd971 pc 0x103fc8, sp 0x7fdffffda41 pc 0x103444, sp 0x7fdffffdb01 --More-- pc 0x1027f0, sp 0x7fdffffdc91 pc 0x40212dd4, sp 0x7fdffffdd51 done db> set $lines=3D0 db> show ktr 446: cpu15 lockmgr(): lkp =3D=3D 0xc142e070 (lk_wmesg =3D=3D "getblk"), own= er =3D=3D 0xfffff800d3c06720, exclusivecount =3D=3D 1, flags =3D=3D 0x6, td= =3D=3D 0xfffff800d3c06720 445: cpu15 UNLOCK (sleep mutex) buf queue lock r =3D 0 at ../../../kern/vfs= _bio.c:1458 444: cpu9 LOCK (spin mutex) sched lock r =3D 0 at ../../../kern/kern_idle.c= :117 443: cpu10 UNLOCK (sleep mutex) system map r =3D 0 at ../../../vm/vm_map.c:= 3018 442: cpu15 bremfreel(0xc142dfd8) vp 0xfffff800368adad0 flags a00200a0 441: cpu9 _mtx_lock_spin: 0xc042edd0 spin done 440: cpu15 LOCK (sleep mutex) buf queue lock r =3D 0 at ../../../kern/vfs_b= io.c:1423 439: cpu0 UNLOCK (spin mutex) sched lock r =3D 0 at ../../../kern/kern_idle= .c:125 438: cpu15 bqrelse(0xc142dfd8) vp 0xfffff800368adad0 flags a00200a0 437: cpu10 LOCK (sleep mutex) system map r =3D 0 at ../../../vm/vm_map.c:29= 98 436: cpu15 UNLOCK (sleep mutex) vm object r =3D 0 at ../../../kern/vfs_bio.= c:3427 435: cpu15 UNLOCK (sleep mutex) vm page queue mutex r =3D 0 at ../../../ker= n/vfs_bio.c:3426 434: cpu0 LOCK (spin mutex) sched lock r =3D 0 at ../../../kern/kern_idle.c= :117 433: cpu0 _mtx_lock_spin: 0xc042edd0 spin done 432: cpu15 LOCK (sleep mutex) vm page queue mutex r =3D 0 at ../../../kern/= vfs_bio.c:3414 431: cpu15 LOCK (sleep mutex) vm object r =3D 0 at ../../../kern/vfs_bio.c:= 3413 430: cpu4 UNLOCK (spin mutex) sched lock r =3D 0 at ../../../kern/kern_idle= .c:125 429: cpu15 UNLOCK (sleep mutex) vm object r =3D 0 at ../../../kern/vfs_bio.= c:2295 428: cpu15 LOCK (sleep mutex) vm object r =3D 0 at ../../../kern/vfs_bio.c:= 2239 427: cpu15 bdirty(0xc142dfd8) vp 0xfffff800368adad0 flags a00200a0 426: cpu15 UNLOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vf= s_bio.c:937 425: cpu4 LOCK (spin mutex) sched lock r =3D 0 at ../../../kern/kern_idle.c= :117 424: cpu10 UNLOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vf= s_subr.c:1822 423: cpu15 LOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vfs_= bio.c:902 422: cpu4 _mtx_lock_spin: 0xc042edd0 spin done 421: cpu10 LOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vfs_= subr.c:1819 420: cpu15 bdwrite(0xc142dfd8) vp 0xfffff800368adad0 flags a00200a0 419: cpu1 UNLOCK (spin mutex) sched lock r =3D 0 at ../../../kern/kern_idle= .c:125 418: cpu15 getblk(0xfffff800368adad0, 59072448, 16384) =3D 0xc142dfd8 417: cpu15 bremfree(0xc142dfd8) vp 0xfffff800368adad0 flags 200200a0 416: cpu1 LOCK (spin mutex) sched lock r =3D 0 at ../../../kern/kern_idle.c= :117 415: cpu1 _mtx_lock_spin: 0xc042edd0 spin done 414: cpu15 acquire(): lkp =3D=3D 0xc142e070, extflags =3D=3D 0x120, wanted = =3D=3D 0x1050000 413: cpu15 acquire(): lkp =3D=3D 0xc142e070, extflags =3D=3D 0x120, wanted = =3D=3D 0x60000 412: cpu10 acquire(): lkp =3D=3D 0xfffff800cd18d958, extflags =3D=3D 0x40, = wanted =3D=3D 0x1050000 411: cpu5 UNLOCK (spin mutex) sched lock r =3D 0 at ../../../kern/kern_idle= .c:125 410: cpu15 UNLOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/ke= rn_lock.c:181 409: cpu15 lockmgr(): lkp =3D=3D 0xc142e070 (lk_wmesg =3D=3D "getblk"), own= er =3D=3D 0xffffffffffffffff, exclusivecount =3D=3D 0, flags =3D=3D 0x20212= 2, td =3D=3D 0xfffff800d3c06720 408: cpu5 LOCK (spin mutex) sched lock r =3D 0 at ../../../kern/kern_idle.c= :117 407: cpu5 _mtx_lock_spin: 0xc042edd0 spin done 406: cpu15 LOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vfs_= bio.c:2369 405: cpu10 UNLOCK (spin mutex) sched lock r =3D 0 at ../../../kern/subr_sle= epqueue.c:540 404: cpu15 getblk(0xfffff800368adad0, 59072448, 16384) 403: cpu15 breadn(0xfffff800368adad0, 59072448, 16384) 402: cpu15 UNLOCK (sleep mutex) struct mount mtx r =3D 0 at ../../../kern/v= fs_vnops.c:951 401: cpu15 LOCK (sleep mutex) struct mount mtx r =3D 0 at ../../../kern/vfs= _vnops.c:949 400: cpu15 UNLOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vf= s_subr.c:2020 399: cpu15 LOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vfs_= subr.c:1927 398: cpu15 UNLOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vf= s_subr.c:1962 397: cpu10 LOCK (spin mutex) sched lock r =3D 0 at ../../../kern/kern_idle.= c:117 396: cpu10 _mtx_lock_spin: 0xc042edd0 spin done 395: cpu15 UNLOCK (spin mutex) sleepq chain r =3D 0 at ../../../kern/subr_s= leepqueue.c:250 394: cpu8 _mtx_lock_spin: 0xc042edd0 spinning 393: cpu4 _mtx_lock_spin: 0xc042edd0 spinning 392: cpu11 _mtx_lock_spin: 0xc042edd0 spinning 391: cpu15 UNLOCK (spin mutex) sched lock r =3D 0 at ../../../kern/subr_sle= epqueue.c:709 390: cpu9 _mtx_lock_spin: 0xc042edd0 spinning 389: cpu1 _mtx_lock_spin: 0xc042edd0 spinning 388: cpu14 _mtx_lock_spin: 0xc042edd0 spinning 387: cpu5 _mtx_lock_spin: 0xc042edd0 spinning 386: cpu0 _mtx_lock_spin: 0xc042edd0 spinning 385: cpu6 _mtx_lock_spin: 0xc042edd0 spinning 384: cpu10 _mtx_lock_spin: 0xc042edd0 spinning 383: cpu7 _mtx_lock_spin: 0xc042edd0 spinning 382: cpu15 LOCK (spin mutex) sched lock r =3D 0 at ../../../kern/subr_sleep= queue.c:706 381: cpu15 LOCK (spin mutex) sleepq chain r =3D 0 at ../../../kern/subr_sle= epqueue.c:218 380: cpu15 lockmgr(): lkp =3D=3D 0xfffff800cd18d958 (lk_wmesg =3D=3D "ufs")= , owner =3D=3D 0xfffff800d3c06720, exclusivecount =3D=3D 1, flags =3D=3D 0x= 6, td =3D=3D 0xfffff800d3c06720 379: cpu15 LOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vfs_= subr.c:2022 378: cpu15 UNLOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vf= s_subr.c:2331 377: cpu15 LOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vfs_= subr.c:2296 376: cpu15 UNLOCK (sleep mutex) Name Cache r =3D 0 at ../../../kern/vfs_cac= he.c:587 375: cpu15 LOCK (sleep mutex) Name Cache r =3D 0 at ../../../kern/vfs_cache= .c:571 374: cpu15 UNLOCK (sleep mutex) struct mount mtx r =3D 0 at ../../../kern/v= fs_subr.c:901 373: cpu15 LOCK (sleep mutex) struct mount mtx r =3D 0 at ../../../kern/vfs= _subr.c:895 372: cpu15 UNLOCK (sleep mutex) UMA pcpu r =3D 0 at ../../../vm/uma_core.c:= 2283 371: cpu15 UNLOCK (sleep mutex) FFS inode r =3D 0 at ../../../vm/uma_core.c= :2281 370: cpu15 LOCK (sleep mutex) FFS inode r =3D 0 at ../../../vm/uma_core.c:2= 276 369: cpu15 LOCK (sleep mutex) UMA pcpu r =3D 0 at ../../../vm/uma_core.c:22= 58 368: cpu15 UNLOCK (sleep mutex) UMA pcpu r =3D 0 at ../../../vm/uma_core.c:= 2283 367: cpu15 UNLOCK (sleep mutex) FFS2 dinode r =3D 0 at ../../../vm/uma_core= .c:2281 366: cpu15 LOCK (sleep mutex) FFS2 dinode r =3D 0 at ../../../vm/uma_core.c= :2276 365: cpu15 LOCK (sleep mutex) UMA pcpu r =3D 0 at ../../../vm/uma_core.c:22= 58 364: cpu15 UNLOCK (sleep mutex) vnode interlock r =3D 0 at ../../../ufs/ufs= /ufs_inode.c:183 363: cpu15 LOCK (sleep mutex) vnode interlock r =3D 0 at ../../../ufs/ufs/u= fs_inode.c:181 362: cpu15 UNLOCK (sleep mutex) vfs hash r =3D 0 at ../../../kern/vfs_hash.= c:103 361: cpu1 UNLOCK (spin mutex) sched lock r =3D 0 at ../../../kern/kern_idle= .c:125 360: cpu15 LOCK (sleep mutex) vfs hash r =3D 0 at ../../../kern/vfs_hash.c:= 101 359: cpu15 UNLOCK (sleep mutex) UMA pcpu r =3D 0 at ../../../vm/uma_core.c:= 2283 358: cpu15 UNLOCK (sleep mutex) VM OBJECT r =3D 0 at ../../../vm/uma_core.c= :2281 357: cpu15 LOCK (sleep mutex) VM OBJECT r =3D 0 at ../../../vm/uma_core.c:2= 276 356: cpu15 LOCK (sleep mutex) UMA pcpu r =3D 0 at ../../../vm/uma_core.c:22= 58 355: cpu15 UNLOCK (sleep mutex) vm object_list r =3D 0 at ../../../vm/vm_ob= ject.c:645 354: cpu15 LOCK (sleep mutex) vm object_list r =3D 0 at ../../../vm/vm_obje= ct.c:643 353: cpu15 UNLOCK (sleep mutex) vm object r =3D 0 at ../../../vm/vm_object.= c:638 352: cpu1 UNLOCK (spin mutex) sleepq chain r =3D 0 at ../../../kern/subr_sl= eepqueue.c:423 351: cpu1 LOCK (spin mutex) sched lock r =3D 0 at ../../../kern/subr_sleepq= ueue.c:422 350: cpu15 UNLOCK (sleep mutex) vm page queue mutex r =3D 0 at ../../../vm/= vm_object.c:632 349: cpu15 LOCK (sleep mutex) vm page queue mutex r =3D 0 at ../../../vm/vm= _object.c:620 348: cpu15 LOCK (sleep mutex) vm object r =3D 0 at ../../../vm/vm_object.c:= 608 347: cpu1 UNLOCK (spin mutex) sched lock r =3D 0 at ../../../kern/kern_sync= h.c:218 346: cpu15 UNLOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vf= s_subr.c:997 345: cpu1 LOCK (spin mutex) sched lock r =3D 0 at ../../../kern/kern_synch.= c:216 344: cpu15 LOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vfs_= subr.c:993 343: cpu15 UNLOCK (sleep mutex) vm object r =3D 0 at ../../../kern/vfs_subr= .c:989 342: cpu1 UNLOCK (spin mutex) sched lock r =3D 0 at ../../../kern/subr_slee= pqueue.c:314 341: cpu15 LOCK (sleep mutex) vm object r =3D 0 at ../../../kern/vfs_subr.c= :986 340: cpu1 LOCK (spin mutex) sched lock r =3D 0 at ../../../kern/subr_sleepq= ueue.c:309 339: cpu15 UNLOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vf= s_subr.c:980 338: cpu15 LOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vfs_= subr.c:978 337: cpu15 UNLOCK (sleep mutex) vm object r =3D 0 at ../../../kern/vfs_subr= .c:976 336: cpu1 LOCK (spin mutex) sleepq chain r =3D 0 at ../../../kern/subr_slee= pqueue.c:218 335: cpu15 LOCK (sleep mutex) vm object r =3D 0 at ../../../kern/vfs_subr.c= :974 334: cpu15 UNLOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vf= s_subr.c:972 333: cpu1 acquire(): lkp =3D=3D 0xfffff800cd18d958, lk_flags =3D=3D 0x40040= sleeping 332: cpu1 acquire(): lkp =3D=3D 0xfffff800cd18d958, extflags =3D=3D 0x40, w= anted =3D=3D 0x60000 331: cpu15 LOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vfs_= subr.c:928 330: cpu1 UNLOCK (spin mutex) turnstile chain r =3D 0 at ../../../kern/subr= _turnstile.c:490 329: cpu1 _mtx_unlock_sleep: 0xfffff800cd18d990 no sleepers 328: cpu1 _mtx_unlock_sleep: 0xfffff800cd18d990 contested 327: cpu1 LOCK (spin mutex) turnstile chain r =3D 0 at ../../../kern/subr_t= urnstile.c:459 326: cpu1 UNLOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/ker= n_lock.c:181 325: cpu1 lockmgr(): lkp =3D=3D 0xfffff800cd18d958 (lk_wmesg =3D=3D "ufs"),= owner =3D=3D 0xfffff800d3c06720, exclusivecount =3D=3D 1, flags =3D=3D 0x2= 002, td =3D=3D 0xfffff800d3c06000 324: cpu1 UNLOCK (sleep mutex) vnode_free_list r =3D 0 at ../../../kern/vfs= _subr.c:2770 323: cpu1 LOCK (sleep mutex) vnode_free_list r =3D 0 at ../../../kern/vfs_s= ubr.c:2767 322: cpu15 UNLOCK (spin mutex) turnstile chain r =3D 0 at ../../../kern/sub= r_turnstile.c:490 321: cpu15 LOCK (spin mutex) turnstile chain r =3D 0 at ../../../kern/subr_= turnstile.c:459 320: cpu1 UNLOCK (sleep mutex) vfs hash r =3D 0 at ../../../kern/vfs_hash.c= :80 319: cpu15 _mtx_lock_sleep: vnode interlock contested (lock=3D0xfffff800d3c= 06000) at ../../../kern/vfs_subr.c:928 318: cpu1 LOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vfs_h= ash.c:79 317: cpu15 UNLOCK (sleep mutex) vm object r =3D 0 at ../../../vm/vm_object.= c:604 316: cpu1 UNLOCK (spin mutex) turnstile chain r =3D 0 at ../../../kern/subr= _turnstile.c:490 315: cpu1 LOCK (spin mutex) turnstile chain r =3D 0 at ../../../kern/subr_t= urnstile.c:459 314: cpu15 LOCK (sleep mutex) vm object r =3D 0 at ../../../vm/vnode_pager.= c:162 313: cpu15 UNLOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vf= s_subr.c:2280 312: cpu0 UNLOCK (spin mutex) sched lock r =3D 0 at ../../../kern/kern_idle= .c:125 311: cpu15 LOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vfs_= subr.c:2277 310: cpu1 _mtx_lock_sleep: vnode interlock contested (lock=3D0xfffff800d3c0= 6720) at ../../../kern/vfs_hash.c:79 309: cpu15 UNLOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vf= s_subr.c:997 308: cpu15 LOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vfs_= subr.c:993 307: cpu15 UNLOCK (sleep mutex) vm object r =3D 0 at ../../../kern/vfs_subr= .c:989 306: cpu1 LOCK (sleep mutex) vfs hash r =3D 0 at ../../../kern/vfs_hash.c:71 305: cpu0 LOCK (spin mutex) sched lock r =3D 0 at ../../../kern/kern_idle.c= :117 304: cpu15 UNLOCK (sleep mutex) vm page queue mutex r =3D 0 at ../../../vm/= vm_object.c:1794 303: cpu0 _mtx_lock_spin: 0xc042edd0 spin done 302: cpu15 UNLOCK (spin mutex) vm page queue free mutex r =3D 0 at ../../..= /vm/vm_page.c:1078 301: cpu15 LOCK (spin mutex) vm page queue free mutex r =3D 0 at ../../../v= m/vm_page.c:1064 300: cpu4 UNLOCK (spin mutex) sched lock r =3D 0 at ../../../kern/kern_idle= .c:125 299: cpu1 UNLOCK (sleep mutex) buffer daemon lock r =3D 0 at ../../../kern/= vfs_bio.c:422 298: cpu15 UNLOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vf= s_subr.c:1996 297: cpu1 LOCK (sleep mutex) buffer daemon lock r =3D 0 at ../../../kern/vf= s_bio.c:417 296: cpu15 UNLOCK (sleep mutex) vnode_free_list r =3D 0 at ../../../kern/vf= s_subr.c:2752 295: cpu1 lockmgr(): lkp =3D=3D 0xc141b530 (lk_wmesg =3D=3D "getblk"), owne= r =3D=3D 0xfffff800d3c06000, exclusivecount =3D=3D 1, flags =3D=3D 0x6, td = =3D=3D 0xfffff800d3c06000 294: cpu15 LOCK (sleep mutex) vnode_free_list r =3D 0 at ../../../kern/vfs_= subr.c:2743 293: cpu4 LOCK (spin mutex) sched lock r =3D 0 at ../../../kern/kern_idle.c= :117 292: cpu4 _mtx_lock_spin: 0xc042edd0 spin done 291: cpu1 UNLOCK (sleep mutex) buf queue lock r =3D 0 at ../../../kern/vfs_= bio.c:1458 290: cpu15 LOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vfs_= subr.c:1994 289: cpu5 UNLOCK (spin mutex) sched lock r =3D 0 at ../../../kern/kern_idle= .c:125 288: cpu1 bremfreel(0xc141b498) vp 0xfffff800368adad0 flags a00000a0 287: cpu1 LOCK (sleep mutex) buf queue lock r =3D 0 at ../../../kern/vfs_bi= o.c:1423 286: cpu15 LOCK (sleep mutex) vm page queue mutex r =3D 0 at ../../../vm/vm= _object.c:1760 285: cpu1 bqrelse(0xc141b498) vp 0xfffff800368adad0 flags a00000a0 284: cpu15 UNLOCK (spin mutex) turnstile chain r =3D 0 at ../../../kern/sub= r_turnstile.c:490 283: cpu5 LOCK (spin mutex) sched lock r =3D 0 at ../../../kern/kern_idle.c= :117 282: cpu1 UNLOCK (sleep mutex) vm object r =3D 0 at ../../../kern/vfs_bio.c= :3427 281: cpu5 _mtx_lock_spin: 0xc042edd0 spin done 280: cpu15 LOCK (spin mutex) turnstile chain r =3D 0 at ../../../kern/subr_= turnstile.c:459 279: cpu1 UNLOCK (sleep mutex) vm page queue mutex r =3D 0 at ../../../kern= /vfs_bio.c:3426 278: cpu10 UNLOCK (spin mutex) sched lock r =3D 0 at ../../../kern/kern_idl= e.c:125 277: cpu15 _mtx_lock_sleep: vm page queue mutex contested (lock=3D0xfffff80= 0d3c06000) at ../../../vm/vm_object.c:1760 276: cpu1 LOCK (sleep mutex) vm page queue mutex r =3D 0 at ../../../kern/v= fs_bio.c:3414 275: cpu15 LOCK (sleep mutex) vm object r =3D 0 at ../../../kern/vfs_subr.c= :986 274: cpu15 UNLOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vf= s_subr.c:980 273: cpu1 LOCK (sleep mutex) vm object r =3D 0 at ../../../kern/vfs_bio.c:3= 413 272: cpu10 LOCK (spin mutex) sched lock r =3D 0 at ../../../kern/kern_idle.= c:117 271: cpu15 LOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vfs_= subr.c:978 270: cpu1 UNLOCK (sleep mutex) vm object r =3D 0 at ../../../kern/vfs_bio.c= :2295 269: cpu10 _mtx_lock_spin: 0xc042edd0 spin done 268: cpu15 UNLOCK (sleep mutex) vm object r =3D 0 at ../../../kern/vfs_subr= .c:976 267: cpu15 LOCK (sleep mutex) vm object r =3D 0 at ../../../kern/vfs_subr.c= :974 266: cpu1 LOCK (sleep mutex) vm object r =3D 0 at ../../../kern/vfs_bio.c:2= 239 265: cpu6 UNLOCK (spin mutex) sched lock r =3D 0 at ../../../kern/kern_idle= .c:125 264: cpu15 UNLOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vf= s_subr.c:972 263: cpu15 LOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vfs_= subr.c:928 262: cpu15 UNLOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vf= s_subr.c:2259 261: cpu1 bdirty(0xc141b498) vp 0xfffff800368adad0 flags a00000a0 260: cpu15 LOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vfs_= subr.c:2201 259: cpu1 UNLOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vfs= _bio.c:937 258: cpu6 LOCK (spin mutex) sched lock r =3D 0 at ../../../kern/kern_idle.c= :117 257: cpu15 UNLOCK (sleep mutex) buffer daemon lock r =3D 0 at ../../../kern= /vfs_bio.c:422 256: cpu6 _mtx_lock_spin: 0xc042edd0 spin done 255: cpu1 LOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vfs_b= io.c:902 254: cpu15 LOCK (sleep mutex) buffer daemon lock r =3D 0 at ../../../kern/v= fs_bio.c:417 253: cpu8 UNLOCK (spin mutex) sched lock r =3D 0 at ../../../kern/kern_idle= .c:125 252: cpu1 bdwrite(0xc141b498) vp 0xfffff800368adad0 flags a00000a0 251: cpu15 lockmgr(): lkp =3D=3D 0xc143f9e0 (lk_wmesg =3D=3D "getblk"), own= er =3D=3D 0xfffff800d3c06720, exclusivecount =3D=3D 1, flags =3D=3D 0x6, td= =3D=3D 0xfffff800d3c06720 250: cpu15 UNLOCK (sleep mutex) buf queue lock r =3D 0 at ../../../kern/vfs= _bio.c:1458 249: cpu1 UNLOCK (sleep mutex) FFS r =3D 0 at ../../../ufs/ffs/ffs_alloc.c:= 1738 248: cpu15 bremfreel(0xc143f948) vp 0xfffff800368adad0 flags a00200a0 247: cpu8 LOCK (spin mutex) sched lock r =3D 0 at ../../../kern/kern_idle.c= :117 246: cpu15 LOCK (sleep mutex) buf queue lock r =3D 0 at ../../../kern/vfs_b= io.c:1423 245: cpu1 LOCK (sleep mutex) FFS r =3D 0 at ../../../ufs/ffs/ffs_alloc.c:17= 26 244: cpu8 _mtx_lock_spin: 0xc042edd0 spin done 243: cpu15 bqrelse(0xc143f948) vp 0xfffff800368adad0 flags a00200a0 242: cpu15 UNLOCK (sleep mutex) vm object r =3D 0 at ../../../kern/vfs_bio.= c:3427 241: cpu7 UNLOCK (spin mutex) sched lock r =3D 0 at ../../../kern/kern_idle= .c:125 240: cpu15 UNLOCK (sleep mutex) vm page queue mutex r =3D 0 at ../../../ker= n/vfs_bio.c:3426 239: cpu15 LOCK (sleep mutex) vm page queue mutex r =3D 0 at ../../../kern/= vfs_bio.c:3414 238: cpu1 getblk(0xfffff800368adad0, 59072384, 16384) =3D 0xc141b498 237: cpu15 LOCK (sleep mutex) vm object r =3D 0 at ../../../kern/vfs_bio.c:= 3413 236: cpu7 LOCK (spin mutex) sched lock r =3D 0 at ../../../kern/kern_idle.c= :117 235: cpu15 UNLOCK (sleep mutex) vm object r =3D 0 at ../../../kern/vfs_bio.= c:2295 234: cpu7 _mtx_lock_spin: 0xc042edd0 spin done 233: cpu15 LOCK (sleep mutex) vm object r =3D 0 at ../../../kern/vfs_bio.c:= 2239 232: cpu1 bremfree(0xc141b498) vp 0xfffff800368adad0 flags 200000a0 231: cpu15 bdirty(0xc143f948) vp 0xfffff800368adad0 flags a00200a0 230: cpu9 UNLOCK (spin mutex) sched lock r =3D 0 at ../../../kern/kern_idle= .c:125 229: cpu1 acquire(): lkp =3D=3D 0xc141b530, extflags =3D=3D 0x120, wanted = =3D=3D 0x1050000 228: cpu15 UNLOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vf= s_bio.c:937 227: cpu1 acquire(): lkp =3D=3D 0xc141b530, extflags =3D=3D 0x120, wanted = =3D=3D 0x60000 226: cpu15 LOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vfs_= bio.c:902 225: cpu1 UNLOCK (spin mutex) turnstile chain r =3D 0 at ../../../kern/subr= _turnstile.c:490 224: cpu1 _mtx_unlock_sleep: 0xfffff800368adba0 no sleepers 223: cpu1 _mtx_unlock_sleep: 0xfffff800368adba0 contested 222: cpu9 LOCK (spin mutex) sched lock r =3D 0 at ../../../kern/kern_idle.c= :117 221: cpu9 _mtx_lock_spin: 0xc042edd0 spin done 220: cpu1 LOCK (spin mutex) turnstile chain r =3D 0 at ../../../kern/subr_t= urnstile.c:459 219: cpu11 UNLOCK (spin mutex) sched lock r =3D 0 at ../../../kern/kern_idl= e.c:125 218: cpu1 UNLOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/ker= n_lock.c:181 217: cpu1 lockmgr(): lkp =3D=3D 0xc141b530 (lk_wmesg =3D=3D "getblk"), owne= r =3D=3D 0xffffffffffffffff, exclusivecount =3D=3D 0, flags =3D=3D 0x202122= , td =3D=3D 0xfffff800d3c06000 216: cpu15 UNLOCK (spin mutex) turnstile chain r =3D 0 at ../../../kern/sub= r_turnstile.c:490 215: cpu15 LOCK (spin mutex) turnstile chain r =3D 0 at ../../../kern/subr_= turnstile.c:459 214: cpu11 LOCK (spin mutex) sched lock r =3D 0 at ../../../kern/kern_idle.= c:117 213: cpu11 _mtx_lock_spin: 0xc042edd0 spin done 212: cpu15 _mtx_lock_sleep: vnode interlock contested (lock=3D0xfffff800d3c= 06000) at ../../../kern/vfs_bio.c:902 211: cpu1 LOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vfs_b= io.c:2369 210: cpu14 UNLOCK (spin mutex) sched lock r =3D 0 at ../../../kern/kern_idl= e.c:125 209: cpu15 bdwrite(0xc143f948) vp 0xfffff800368adad0 flags a00200a0 208: cpu15 getblk(0xfffff800368adad0, 59072480, 16384) =3D 0xc143f948 207: cpu14 LOCK (spin mutex) sched lock r =3D 0 at ../../../kern/kern_idle.= c:117 206: cpu15 bremfree(0xc143f948) vp 0xfffff800368adad0 flags 200200a0 205: cpu15 acquire(): lkp =3D=3D 0xc143f9e0, extflags =3D=3D 0x120, wanted = =3D=3D 0x1050000 204: cpu14 _mtx_lock_spin: 0xc042edd0 spin done 203: cpu15 acquire(): lkp =3D=3D 0xc143f9e0, extflags =3D=3D 0x120, wanted = =3D=3D 0x60000 202: cpu15 UNLOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/ke= rn_lock.c:181 201: cpu1 UNLOCK (spin mutex) sched lock r =3D 0 at ../../../kern/subr_slee= pqueue.c:540 200: cpu15 lockmgr(): lkp =3D=3D 0xc143f9e0 (lk_wmesg =3D=3D "getblk"), own= er =3D=3D 0xffffffffffffffff, exclusivecount =3D=3D 0, flags =3D=3D 0x20212= 2, td =3D=3D 0xfffff800d3c06720 199: cpu15 LOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vfs_= bio.c:2369 198: cpu15 getblk(0xfffff800368adad0, 59072480, 16384) 197: cpu15 breadn(0xfffff800368adad0, 59072480, 16384) 196: cpu15 UNLOCK (sleep mutex) struct mount mtx r =3D 0 at ../../../kern/v= fs_vnops.c:951 195: cpu15 LOCK (sleep mutex) struct mount mtx r =3D 0 at ../../../kern/vfs= _vnops.c:949 194: cpu15 UNLOCK (sleep mutex) buffer daemon lock r =3D 0 at ../../../kern= /vfs_bio.c:422 193: cpu15 LOCK (sleep mutex) buffer daemon lock r =3D 0 at ../../../kern/v= fs_bio.c:417 192: cpu15 UNLOCK (spin mutex) sleepq chain r =3D 0 at ../../../kern/subr_s= leepqueue.c:250 191: cpu1 LOCK (spin mutex) sched lock r =3D 0 at ../../../kern/kern_idle.c= :117 190: cpu14 _mtx_lock_spin: 0xc042edd0 spinning 189: cpu5 _mtx_lock_spin: 0xc042edd0 spinning 188: cpu6 _mtx_lock_spin: 0xc042edd0 spinning 187: cpu7 _mtx_lock_spin: 0xc042edd0 spinning 186: cpu0 _mtx_lock_spin: 0xc042edd0 spinning 185: cpu1 _mtx_lock_spin: 0xc042edd0 spin done 184: cpu9 _mtx_lock_spin: 0xc042edd0 spinning 183: cpu11 _mtx_lock_spin: 0xc042edd0 spinning 182: cpu8 _mtx_lock_spin: 0xc042edd0 spinning 181: cpu10 _mtx_lock_spin: 0xc042edd0 spinning 180: cpu1 _mtx_lock_spin: 0xc042edd0 spinning 179: cpu4 _mtx_lock_spin: 0xc042edd0 spinning 178: cpu15 UNLOCK (spin mutex) sched lock r =3D 0 at ../../../kern/subr_sle= epqueue.c:709 177: cpu15 LOCK (spin mutex) sched lock r =3D 0 at ../../../kern/subr_sleep= queue.c:706 176: cpu15 _mtx_lock_spin: 0xc042edd0 spin done 175: cpu5 UNLOCK (spin mutex) sched lock r =3D 0 at ../../../kern/kern_idle= .c:125 174: cpu15 _mtx_lock_spin: 0xc042edd0 spinning 173: cpu15 LOCK (spin mutex) sleepq chain r =3D 0 at ../../../kern/subr_sle= epqueue.c:218 172: cpu15 _mtx_lock_spin: 0xc044dff8 spin done 171: cpu5 UNLOCK (spin mutex) sleepq chain r =3D 0 at ../../../kern/subr_sl= eepqueue.c:423 170: cpu5 LOCK (spin mutex) sched lock r =3D 0 at ../../../kern/subr_sleepq= ueue.c:422 169: cpu15 _mtx_lock_spin: 0xc044dff8 spinning 168: cpu5 UNLOCK (spin mutex) sched lock r =3D 0 at ../../../kern/kern_sync= h.c:218 167: cpu5 LOCK (spin mutex) sched lock r =3D 0 at ../../../kern/kern_synch.= c:216 166: cpu15 lockmgr(): lkp =3D=3D 0xc141b530 (lk_wmesg =3D=3D "getblk"), own= er =3D=3D 0xfffff800d3c06720, exclusivecount =3D=3D 1, flags =3D=3D 0x6, td= =3D=3D 0xfffff800d3c06720 165: cpu5 UNLOCK (spin mutex) sched lock r =3D 0 at ../../../kern/subr_slee= pqueue.c:314 164: cpu5 LOCK (spin mutex) sched lock r =3D 0 at ../../../kern/subr_sleepq= ueue.c:309 163: cpu15 UNLOCK (sleep mutex) buf queue lock r =3D 0 at ../../../kern/vfs= _bio.c:1458 162: cpu5 UNLOCK (spin mutex) turnstile chain r =3D 0 at ../../../kern/subr= _turnstile.c:490 161: cpu5 LOCK (spin mutex) turnstile chain r =3D 0 at ../../../kern/subr_t= urnstile.c:459 160: cpu5 LOCK (spin mutex) sleepq chain r =3D 0 at ../../../kern/subr_slee= pqueue.c:218 159: cpu15 UNLOCK (spin mutex) turnstile chain r =3D 0 at ../../../kern/sub= r_turnstile.c:490 158: cpu15 LOCK (spin mutex) turnstile chain r =3D 0 at ../../../kern/subr_= turnstile.c:459 157: cpu5 acquire(): lkp =3D=3D 0xc141b530, lk_flags =3D=3D 0x40000 sleeping 156: cpu5 acquire(): lkp =3D=3D 0xc141b530, extflags =3D=3D 0x120, wanted = =3D=3D 0x60000 155: cpu5 UNLOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/ker= n_lock.c:181 154: cpu5 lockmgr(): lkp =3D=3D 0xc141b530 (lk_wmesg =3D=3D "getblk"), owne= r =3D=3D 0xfffff800d3c06720, exclusivecount =3D=3D 1, flags =3D=3D 0x202122= , td =3D=3D 0xfffff800d3c06000 153: cpu15 bremfreel(0xc141b498) vp 0xfffff800368adad0 flags a00000a0 152: cpu15 LOCK (sleep mutex) buf queue lock r =3D 0 at ../../../kern/vfs_b= io.c:1423 151: cpu5 LOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vfs_b= io.c:2369 150: cpu15 bqrelse(0xc141b498) vp 0xfffff800368adad0 flags a00000a0 149: cpu15 UNLOCK (sleep mutex) vm object r =3D 0 at ../../../kern/vfs_bio.= c:3427 148: cpu5 getblk(0xfffff800368adad0, 59072384, 16384) 147: cpu5 breadn(0xfffff800368adad0, 59072384, 16384) 146: cpu15 UNLOCK (sleep mutex) vm page queue mutex r =3D 0 at ../../../ker= n/vfs_bio.c:3426 145: cpu5 UNLOCK (sleep mutex) FFS r =3D 0 at ../../../ufs/ffs/ffs_alloc.c:= 1659 144: cpu15 LOCK (sleep mutex) vm page queue mutex r =3D 0 at ../../../kern/= vfs_bio.c:3414 143: cpu15 LOCK (sleep mutex) vm object r =3D 0 at ../../../kern/vfs_bio.c:= 3413 142: cpu15 UNLOCK (sleep mutex) vm object r =3D 0 at ../../../kern/vfs_bio.= c:2295 141: cpu5 LOCK (sleep mutex) FFS r =3D 0 at ../../../ufs/ffs/ffs_alloc.c:898 140: cpu15 LOCK (sleep mutex) vm object r =3D 0 at ../../../kern/vfs_bio.c:= 2239 139: cpu15 bdirty(0xc141b498) vp 0xfffff800368adad0 flags a00000a0 138: cpu5 UNLOCK (sleep mutex) struct mount mtx r =3D 0 at ../../../kern/vf= s_vnops.c:917 137: cpu15 UNLOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vf= s_bio.c:937 136: cpu5 LOCK (sleep mutex) struct mount mtx r =3D 0 at ../../../kern/vfs_= vnops.c:899 135: cpu15 LOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vfs_= bio.c:902 134: cpu15 bdwrite(0xc141b498) vp 0xfffff800368adad0 flags a00000a0 133: cpu15 UNLOCK (sleep mutex) FFS r =3D 0 at ../../../ufs/ffs/ffs_alloc.c= :2037 132: cpu15 LOCK (sleep mutex) FFS r =3D 0 at ../../../ufs/ffs/ffs_alloc.c:2= 027 131: cpu5 UNLOCK (sleep mutex) dirhash r =3D 0 at ../../../ufs/ufs/ufs_dirh= ash.c:473 130: cpu15 getblk(0xfffff800368adad0, 59072384, 16384) =3D 0xc141b498 129: cpu5 UNLOCK (sleep mutex) dirhash list r =3D 0 at ../../../ufs/ufs/ufs= _dirhash.c:364 128: cpu5 LOCK (sleep mutex) dirhash r =3D 0 at ../../../ufs/ufs/ufs_dirhas= h.c:349 127: cpu15 bremfree(0xc141b498) vp 0xfffff800368adad0 flags 200000a0 126: cpu5 LOCK (sleep mutex) dirhash list r =3D 0 at ../../../ufs/ufs/ufs_d= irhash.c:348 125: cpu15 acquire(): lkp =3D=3D 0xc141b530, extflags =3D=3D 0x120, wanted = =3D=3D 0x1050000 124: cpu5 UNLOCK (sleep mutex) dirhash r =3D 0 at ../../../ufs/ufs/ufs_dirh= ash.c:594 123: cpu15 acquire(): lkp =3D=3D 0xc141b530, extflags =3D=3D 0x120, wanted = =3D=3D 0x60000 122: cpu15 UNLOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/ke= rn_lock.c:181 121: cpu5 LOCK (sleep mutex) dirhash r =3D 0 at ../../../ufs/ufs/ufs_dirhas= h.c:586 120: cpu15 lockmgr(): lkp =3D=3D 0xc141b530 (lk_wmesg =3D=3D "getblk"), own= er =3D=3D 0xffffffffffffffff, exclusivecount =3D=3D 0, flags =3D=3D 0x20212= 2, td =3D=3D 0xfffff800d3c06720 119: cpu5 lockmgr(): lkp =3D=3D 0xc144a4e0 (lk_wmesg =3D=3D "getblk"), owne= r =3D=3D 0xfffff800d3c06000, exclusivecount =3D=3D 1, flags =3D=3D 0x6, td = =3D=3D 0xfffff800d3c06000 118: cpu15 LOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vfs_= bio.c:2369 117: cpu5 UNLOCK (sleep mutex) needsbuffer lock r =3D 0 at ../../../kern/vf= s_bio.c:314 116: cpu5 LOCK (sleep mutex) needsbuffer lock r =3D 0 at ../../../kern/vfs_= bio.c:309 115: cpu15 getblk(0xfffff800368adad0, 59072384, 16384) 114: cpu5 UNLOCK (sleep mutex) needsbuffer lock r =3D 0 at ../../../kern/vf= s_bio.c:358 113: cpu15 breadn(0xfffff800368adad0, 59072384, 16384) 112: cpu5 LOCK (sleep mutex) needsbuffer lock r =3D 0 at ../../../kern/vfs_= bio.c:351 111: cpu5 UNLOCK (sleep mutex) buf queue lock r =3D 0 at ../../../kern/vfs_= bio.c:1356 110: cpu15 UNLOCK (sleep mutex) buffer daemon lock r =3D 0 at ../../../kern= /vfs_bio.c:422 109: cpu5 bremfreel(0xc144a448) vp 0xfffff800c1322420 flags 80000020 108: cpu15 LOCK (sleep mutex) buffer daemon lock r =3D 0 at ../../../kern/v= fs_bio.c:417 107: cpu5 LOCK (sleep mutex) buf queue lock r =3D 0 at ../../../kern/vfs_bi= o.c:1317 106: cpu15 lockmgr(): lkp =3D=3D 0xc141b530 (lk_wmesg =3D=3D "getblk"), own= er =3D=3D 0xfffff800d3c06720, exclusivecount =3D=3D 1, flags =3D=3D 0x6, td= =3D=3D 0xfffff800d3c06720 105: cpu5 _mtx_lock_sleep: buf queue lock contested (lock=3D0xfffff800d3c06= 720) at ../../../kern/vfs_bio.c:1317 104: cpu15 UNLOCK (sleep mutex) buf queue lock r =3D 0 at ../../../kern/vfs= _bio.c:1458 103: cpu15 bremfreel(0xc141b498) vp 0xfffff800368adad0 flags a00000a0 102: cpu5 brelse(0xc144a448) vp 0xfffff800c1322420 flags 80000020 101: cpu15 LOCK (sleep mutex) buf queue lock r =3D 0 at ../../../kern/vfs_b= io.c:1423 100: cpu15 bqrelse(0xc141b498) vp 0xfffff800368adad0 flags a00000a0 99: cpu15 UNLOCK (sleep mutex) vm object r =3D 0 at ../../../kern/vfs_bio.c= :3427 98: cpu15 UNLOCK (sleep mutex) vm page queue mutex r =3D 0 at ../../../kern= /vfs_bio.c:3426 97: cpu5 getblk(0xfffff800c1322420, 0, 4096) =3D 0xc144a448 96: cpu15 LOCK (sleep mutex) vm page queue mutex r =3D 0 at ../../../kern/v= fs_bio.c:3414 95: cpu15 LOCK (sleep mutex) vm object r =3D 0 at ../../../kern/vfs_bio.c:3= 413 94: cpu15 UNLOCK (sleep mutex) vm object r =3D 0 at ../../../kern/vfs_bio.c= :2295 93: cpu5 bremfree(0xc144a448) vp 0xfffff800c1322420 flags 20 92: cpu15 LOCK (sleep mutex) vm object r =3D 0 at ../../../kern/vfs_bio.c:2= 239 91: cpu5 acquire(): lkp =3D=3D 0xc144a4e0, extflags =3D=3D 0x120, wanted = =3D=3D 0x1050000 90: cpu5 acquire(): lkp =3D=3D 0xc144a4e0, extflags =3D=3D 0x120, wanted = =3D=3D 0x60000 89: cpu15 bdirty(0xc141b498) vp 0xfffff800368adad0 flags a00000a0 88: cpu15 UNLOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vfs= _bio.c:937 87: cpu5 UNLOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/kern= _lock.c:181 86: cpu15 LOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vfs_b= io.c:902 85: cpu5 lockmgr(): lkp =3D=3D 0xc144a4e0 (lk_wmesg =3D=3D "getblk"), owner= =3D=3D 0xffffffffffffffff, exclusivecount =3D=3D 0, flags =3D=3D 0x202122,= td =3D=3D 0xfffff800d3c06000 84: cpu15 bdwrite(0xc141b498) vp 0xfffff800368adad0 flags a00000a0 83: cpu5 LOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vfs_bi= o.c:2369 82: cpu15 UNLOCK (sleep mutex) FFS r =3D 0 at ../../../ufs/ffs/ffs_alloc.c:= 1898 81: cpu5 getblk(0xfffff800c1322420, 0, 4096) 80: cpu15 LOCK (sleep mutex) FFS r =3D 0 at ../../../ufs/ffs/ffs_alloc.c:18= 35 79: cpu5 breadn(0xfffff800c1322420, 0, 4096) 78: cpu5 UNLOCK (sleep mutex) dirhash r =3D 0 at ../../../ufs/ufs/ufs_dirha= sh.c:526 77: cpu15 getblk(0xfffff800368adad0, 59072384, 16384) =3D 0xc141b498 76: cpu15 bremfree(0xc141b498) vp 0xfffff800368adad0 flags 200000a0 75: cpu5 LOCK (sleep mutex) dirhash r =3D 0 at ../../../ufs/ufs/ufs_dirhash= .c:506 74: cpu15 acquire(): lkp =3D=3D 0xc141b530, extflags =3D=3D 0x120, wanted = =3D=3D 0x1050000 73: cpu15 acquire(): lkp =3D=3D 0xc141b530, extflags =3D=3D 0x120, wanted = =3D=3D 0x60000 72: cpu5 UNLOCK (sleep mutex) Name Cache r =3D 0 at ../../../kern/vfs_cache= .c:418 71: cpu15 UNLOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/ker= n_lock.c:181 70: cpu5 UNLOCK (sleep mutex) UMA pcpu r =3D 0 at ../../../vm/uma_core.c:22= 83 69: cpu15 lockmgr(): lkp =3D=3D 0xc141b530 (lk_wmesg =3D=3D "getblk"), owne= r =3D=3D 0xffffffffffffffff, exclusivecount =3D=3D 0, flags =3D=3D 0x202122= , td =3D=3D 0xfffff800d3c06720 68: cpu5 UNLOCK (sleep mutex) S VFS Cache r =3D 0 at ../../../vm/uma_core.c= :2281 67: cpu15 LOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vfs_b= io.c:2369 66: cpu5 LOCK (sleep mutex) S VFS Cache r =3D 0 at ../../../vm/uma_core.c:2= 276 65: cpu15 getblk(0xfffff800368adad0, 59072384, 16384) 64: cpu15 breadn(0xfffff800368adad0, 59072384, 16384) 63: cpu5 LOCK (sleep mutex) UMA pcpu r =3D 0 at ../../../vm/uma_core.c:2258 62: cpu15 UNLOCK (sleep mutex) buffer daemon lock r =3D 0 at ../../../kern/= vfs_bio.c:422 61: cpu15 LOCK (sleep mutex) buffer daemon lock r =3D 0 at ../../../kern/vf= s_bio.c:417 60: cpu5 LOCK (sleep mutex) Name Cache r =3D 0 at ../../../kern/vfs_cache.c= :354 59: cpu15 lockmgr(): lkp =3D=3D 0xc141b530 (lk_wmesg =3D=3D "getblk"), owne= r =3D=3D 0xfffff800d3c06720, exclusivecount =3D=3D 1, flags =3D=3D 0x6, td = =3D=3D 0xfffff800d3c06720 58: cpu15 UNLOCK (sleep mutex) buf queue lock r =3D 0 at ../../../kern/vfs_= bio.c:1458 57: cpu5 UNLOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vfs_= subr.c:1962 56: cpu15 bremfreel(0xc141b498) vp 0xfffff800368adad0 flags a00000a0 55: cpu5 lockmgr(): lkp =3D=3D 0xfffff800c63e1748 (lk_wmesg =3D=3D "ufs"), = owner =3D=3D 0xfffff800d3c06000, exclusivecount =3D=3D 1, flags =3D=3D 0x6,= td =3D=3D 0xfffff800d3c06000 54: cpu15 LOCK (sleep mutex) buf queue lock r =3D 0 at ../../../kern/vfs_bi= o.c:1423 53: cpu5 LOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vfs_su= br.c:2022 52: cpu15 bqrelse(0xc141b498) vp 0xfffff800368adad0 flags a00000a0 51: cpu5 UNLOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vfs_= subr.c:2020 50: cpu15 UNLOCK (sleep mutex) vm object r =3D 0 at ../../../kern/vfs_bio.c= :3427 49: cpu15 UNLOCK (sleep mutex) vm page queue mutex r =3D 0 at ../../../kern= /vfs_bio.c:3426 48: cpu5 LOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vfs_su= br.c:1927 47: cpu15 LOCK (sleep mutex) vm page queue mutex r =3D 0 at ../../../kern/v= fs_bio.c:3414 46: cpu15 LOCK (sleep mutex) vm object r =3D 0 at ../../../kern/vfs_bio.c:3= 413 45: cpu5 acquire(): lkp =3D=3D 0xfffff800c13224b8, extflags =3D=3D 0x40, wa= nted =3D=3D 0x1050000 44: cpu15 UNLOCK (sleep mutex) vm object r =3D 0 at ../../../kern/vfs_bio.c= :2295 43: cpu5 acquire(): lkp =3D=3D 0xfffff800c13224b8, extflags =3D=3D 0x40, wa= nted =3D=3D 0x60000 42: cpu15 LOCK (sleep mutex) vm object r =3D 0 at ../../../kern/vfs_bio.c:2= 239 41: cpu5 UNLOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/kern= _lock.c:181 40: cpu5 lockmgr(): lkp =3D=3D 0xfffff800c13224b8 (lk_wmesg =3D=3D "ufs"), = owner =3D=3D 0xffffffffffffffff, exclusivecount =3D=3D 0, flags =3D=3D 0x20= 02, td =3D=3D 0xfffff800d3c06000 39: cpu15 bdirty(0xc141b498) vp 0xfffff800368adad0 flags a00000a0 38: cpu15 UNLOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vfs= _bio.c:937 37: cpu5 UNLOCK (sleep mutex) Name Cache r =3D 0 at ../../../kern/vfs_cache= .c:450 36: cpu15 LOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vfs_b= io.c:902 35: cpu5 LOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vfs_ca= che.c:449 34: cpu15 bdwrite(0xc141b498) vp 0xfffff800368adad0 flags a00000a0 33: cpu15 UNLOCK (sleep mutex) FFS r =3D 0 at ../../../ufs/ffs/ffs_alloc.c:= 1898 32: cpu5 LOCK (sleep mutex) Name Cache r =3D 0 at ../../../kern/vfs_cache.c= :354 31: cpu15 LOCK (sleep mutex) FFS r =3D 0 at ../../../ufs/ffs/ffs_alloc.c:18= 35 30: cpu15 getblk(0xfffff800368adad0, 59072384, 16384) =3D 0xc141b498 29: cpu5 UNLOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vfs_= subr.c:1962 28: cpu5 lockmgr(): lkp =3D=3D 0xfffff800c5adc6c8 (lk_wmesg =3D=3D "ufs"), = owner =3D=3D 0xfffff800d3c06000, exclusivecount =3D=3D 1, flags =3D=3D 0x6,= td =3D=3D 0xfffff800d3c06000 27: cpu15 bremfree(0xc141b498) vp 0xfffff800368adad0 flags 200000a0 26: cpu5 LOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vfs_su= br.c:2022 25: cpu15 acquire(): lkp =3D=3D 0xc141b530, extflags =3D=3D 0x120, wanted = =3D=3D 0x1050000 24: cpu15 acquire(): lkp =3D=3D 0xc141b530, extflags =3D=3D 0x120, wanted = =3D=3D 0x60000 23: cpu5 UNLOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vfs_= subr.c:2020 22: cpu15 UNLOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/ker= n_lock.c:181 21: cpu15 lockmgr(): lkp =3D=3D 0xc141b530 (lk_wmesg =3D=3D "getblk"), owne= r =3D=3D 0xffffffffffffffff, exclusivecount =3D=3D 0, flags =3D=3D 0x202122= , td =3D=3D 0xfffff800d3c06720 20: cpu5 LOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vfs_su= br.c:1927 19: cpu15 LOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vfs_b= io.c:2369 18: cpu15 getblk(0xfffff800368adad0, 59072384, 16384) 17: cpu15 breadn(0xfffff800368adad0, 59072384, 16384) 16: cpu5 acquire(): lkp =3D=3D 0xfffff800c63e1748, extflags =3D=3D 0x40, wa= nted =3D=3D 0x1050000 15: cpu5 acquire(): lkp =3D=3D 0xfffff800c63e1748, extflags =3D=3D 0x40, wa= nted =3D=3D 0x60000 14: cpu15 UNLOCK (sleep mutex) buffer daemon lock r =3D 0 at ../../../kern/= vfs_bio.c:422 13: cpu5 UNLOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/kern= _lock.c:181 12: cpu15 LOCK (sleep mutex) buffer daemon lock r =3D 0 at ../../../kern/vf= s_bio.c:417 11: cpu5 lockmgr(): lkp =3D=3D 0xfffff800c63e1748 (lk_wmesg =3D=3D "ufs"), = owner =3D=3D 0xffffffffffffffff, exclusivecount =3D=3D 0, flags =3D=3D 0x20= 02, td =3D=3D 0xfffff800d3c06000 10: cpu15 lockmgr(): lkp =3D=3D 0xc141b530 (lk_wmesg =3D=3D "getblk"), owne= r =3D=3D 0xfffff800d3c06720, exclusivecount =3D=3D 1, flags =3D=3D 0x6, td = =3D=3D 0xfffff800d3c06720 9: cpu15 UNLOCK (sleep mutex) buf queue lock r =3D 0 at ../../../kern/vfs_b= io.c:1458 8: cpu5 UNLOCK (sleep mutex) Name Cache r =3D 0 at ../../../kern/vfs_cache.= c:450 7: cpu5 LOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vfs_cac= he.c:449 6: cpu15 bremfreel(0xc141b498) vp 0xfffff800368adad0 flags a00000a0 5: cpu15 LOCK (sleep mutex) buf queue lock r =3D 0 at ../../../kern/vfs_bio= .c:1423 4: cpu5 LOCK (sleep mutex) Name Cache r =3D 0 at ../../../kern/vfs_cache.c:= 354 3: cpu15 bqrelse(0xc141b498) vp 0xfffff800368adad0 flags a00000a0 2: cpu15 UNLOCK (sleep mutex) vm object r =3D 0 at ../../../kern/vfs_bio.c:= 3427 1: cpu15 UNLOCK (sleep mutex) vm page queue mutex r =3D 0 at ../../../kern/= vfs_bio.c:3426 0: cpu5 UNLOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vfs_s= ubr.c:1962 1023: cpu5 lockmgr(): lkp =3D=3D 0xfffff800f2aa0cf8 (lk_wmesg =3D=3D "ufs")= , owner =3D=3D 0xfffff800d3c06000, exclusivecount =3D=3D 1, flags =3D=3D 0x= 6, td =3D=3D 0xfffff800d3c06000 1022: cpu15 LOCK (sleep mutex) vm page queue mutex r =3D 0 at ../../../kern= /vfs_bio.c:3414 1021: cpu15 LOCK (sleep mutex) vm object r =3D 0 at ../../../kern/vfs_bio.c= :3413 1020: cpu5 LOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vfs_= subr.c:2022 1019: cpu15 UNLOCK (sleep mutex) vm object r =3D 0 at ../../../kern/vfs_bio= .c:2295 1018: cpu5 UNLOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vf= s_subr.c:2020 1017: cpu15 LOCK (sleep mutex) vm object r =3D 0 at ../../../kern/vfs_bio.c= :2239 1016: cpu15 bdirty(0xc141b498) vp 0xfffff800368adad0 flags a00000a0 1015: cpu5 LOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vfs_= subr.c:1927 1014: cpu15 UNLOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/v= fs_bio.c:937 1013: cpu15 LOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vfs= _bio.c:902 1012: cpu5 acquire(): lkp =3D=3D 0xfffff800c5adc6c8, extflags =3D=3D 0x40, = wanted =3D=3D 0x1050000 1011: cpu15 bdwrite(0xc141b498) vp 0xfffff800368adad0 flags a00000a0 1010: cpu5 acquire(): lkp =3D=3D 0xfffff800c5adc6c8, extflags =3D=3D 0x40, = wanted =3D=3D 0x60000 1009: cpu15 UNLOCK (sleep mutex) FFS r =3D 0 at ../../../ufs/ffs/ffs_alloc.= c:1898 1008: cpu5 UNLOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/ke= rn_lock.c:181 1007: cpu5 lockmgr(): lkp =3D=3D 0xfffff800c5adc6c8 (lk_wmesg =3D=3D "ufs")= , owner =3D=3D 0xffffffffffffffff, exclusivecount =3D=3D 0, flags =3D=3D 0x= 2002, td =3D=3D 0xfffff800d3c06000 1006: cpu15 LOCK (sleep mutex) FFS r =3D 0 at ../../../ufs/ffs/ffs_alloc.c:= 1835 1005: cpu5 UNLOCK (sleep mutex) Name Cache r =3D 0 at ../../../kern/vfs_cac= he.c:450 1004: cpu15 getblk(0xfffff800368adad0, 59072384, 16384) =3D 0xc141b498 1003: cpu5 LOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vfs_= cache.c:449 1002: cpu15 bremfree(0xc141b498) vp 0xfffff800368adad0 flags 200000a0 1001: cpu5 LOCK (sleep mutex) Name Cache r =3D 0 at ../../../kern/vfs_cache= .c:354 1000: cpu15 acquire(): lkp =3D=3D 0xc141b530, extflags =3D=3D 0x120, wanted= =3D=3D 0x1050000 999: cpu15 acquire(): lkp =3D=3D 0xc141b530, extflags =3D=3D 0x120, wanted = =3D=3D 0x60000 998: cpu15 UNLOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/ke= rn_lock.c:181 997: cpu5 UNLOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/ker= n_lock.c:181 996: cpu15 lockmgr(): lkp =3D=3D 0xc141b530 (lk_wmesg =3D=3D "getblk"), own= er =3D=3D 0xffffffffffffffff, exclusivecount =3D=3D 0, flags =3D=3D 0x20212= 2, td =3D=3D 0xfffff800d3c06720 995: cpu5 lockmgr(): lkp =3D=3D 0xfffff800f278b118 (lk_wmesg =3D=3D "ufs"),= owner =3D=3D 0xfffff800d3c06000, exclusivecount =3D=3D 1, flags =3D=3D 0x2= 006, td =3D=3D 0xfffff800d3c06000 994: cpu15 LOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vfs_= bio.c:2369 993: cpu5 LOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vfs_s= ubr.c:1927 992: cpu15 getblk(0xfffff800368adad0, 59072384, 16384) 991: cpu15 breadn(0xfffff800368adad0, 59072384, 16384) 990: cpu15 UNLOCK (sleep mutex) buffer daemon lock r =3D 0 at ../../../kern= /vfs_bio.c:422 989: cpu5 acquire(): lkp =3D=3D 0xfffff800f2aa0cf8, extflags =3D=3D 0x40, w= anted =3D=3D 0x1050000 988: cpu5 acquire(): lkp =3D=3D 0xfffff800f2aa0cf8, extflags =3D=3D 0x40, w= anted =3D=3D 0x60000 987: cpu15 LOCK (sleep mutex) buffer daemon lock r =3D 0 at ../../../kern/v= fs_bio.c:417 986: cpu5 UNLOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/ker= n_lock.c:181 985: cpu15 lockmgr(): lkp =3D=3D 0xc141b530 (lk_wmesg =3D=3D "getblk"), own= er =3D=3D 0xfffff800d3c06720, exclusivecount =3D=3D 1, flags =3D=3D 0x6, td= =3D=3D 0xfffff800d3c06720 984: cpu5 lockmgr(): lkp =3D=3D 0xfffff800f2aa0cf8 (lk_wmesg =3D=3D "ufs"),= owner =3D=3D 0xffffffffffffffff, exclusivecount =3D=3D 0, flags =3D=3D 0x2= 002, td =3D=3D 0xfffff800d3c06000 983: cpu15 UNLOCK (sleep mutex) buf queue lock r =3D 0 at ../../../kern/vfs= _bio.c:1458 982: cpu15 bremfreel(0xc141b498) vp 0xfffff800368adad0 flags a00000a0 981: cpu5 UNLOCK (sleep mutex) Name Cache r =3D 0 at ../../../kern/vfs_cach= e.c:450 980: cpu15 LOCK (sleep mutex) buf queue lock r =3D 0 at ../../../kern/vfs_b= io.c:1423 979: cpu5 LOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vfs_c= ache.c:449 978: cpu15 bqrelse(0xc141b498) vp 0xfffff800368adad0 flags a00000a0 977: cpu5 LOCK (sleep mutex) Name Cache r =3D 0 at ../../../kern/vfs_cache.= c:354 976: cpu15 UNLOCK (sleep mutex) vm object r =3D 0 at ../../../kern/vfs_bio.= c:3427 975: cpu15 UNLOCK (sleep mutex) vm page queue mutex r =3D 0 at ../../../ker= n/vfs_bio.c:3426 974: cpu15 LOCK (sleep mutex) vm page queue mutex r =3D 0 at ../../../kern/= vfs_bio.c:3414 973: cpu15 LOCK (sleep mutex) vm object r =3D 0 at ../../../kern/vfs_bio.c:= 3413 972: cpu15 UNLOCK (sleep mutex) vm object r =3D 0 at ../../../kern/vfs_bio.= c:2295 971: cpu5 acquire(): lkp =3D=3D 0xfffff800f278b118, extflags =3D=3D 0x40, w= anted =3D=3D 0x1050000 970: cpu5 acquire(): lkp =3D=3D 0xfffff800f278b118, extflags =3D=3D 0x40, w= anted =3D=3D 0x60000 969: cpu15 LOCK (sleep mutex) vm object r =3D 0 at ../../../kern/vfs_bio.c:= 2239 968: cpu5 UNLOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/ker= n_lock.c:181 967: cpu5 lockmgr(): lkp =3D=3D 0xfffff800f278b118 (lk_wmesg =3D=3D "ufs"),= owner =3D=3D 0xffffffffffffffff, exclusivecount =3D=3D 0, flags =3D=3D 0x3= 002, td =3D=3D 0xfffff800d3c06000 966: cpu15 bdirty(0xc141b498) vp 0xfffff800368adad0 flags a00000a0 965: cpu15 UNLOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vf= s_bio.c:937 964: cpu15 LOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vfs_= bio.c:902 963: cpu5 LOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vfs_v= nops.c:801 962: cpu5 UNLOCK (sleep mutex) filedesc structure r =3D 0 at ../../../kern/= vfs_lookup.c:180 961: cpu15 bdwrite(0xc141b498) vp 0xfffff800368adad0 flags a00000a0 960: cpu5 LOCK (sleep mutex) filedesc structure r =3D 0 at ../../../kern/vf= s_lookup.c:180 959: cpu5 UNLOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vfs= _subr.c:1838 958: cpu15 UNLOCK (sleep mutex) FFS r =3D 0 at ../../../ufs/ffs/ffs_alloc.c= :1898 957: cpu5 LOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vfs_s= ubr.c:1836 956: cpu15 LOCK (sleep mutex) FFS r =3D 0 at ../../../ufs/ffs/ffs_alloc.c:1= 835 955: cpu5 UNLOCK (sleep mutex) filedesc structure r =3D 0 at ../../../kern/= vfs_lookup.c:173 954: cpu5 LOCK (sleep mutex) filedesc structure r =3D 0 at ../../../kern/vf= s_lookup.c:173 953: cpu15 getblk(0xfffff800368adad0, 59072384, 16384) =3D 0xc141b498 952: cpu5 UNLOCK (sleep mutex) UMA pcpu r =3D 0 at ../../../vm/uma_core.c:1= 853 951: cpu15 bremfree(0xc141b498) vp 0xfffff800368adad0 flags 200000a0 950: cpu5 UNLOCK (sleep mutex) NAMEI r =3D 0 at ../../../vm/uma_core.c:1851 949: cpu15 acquire(): lkp =3D=3D 0xc141b530, extflags =3D=3D 0x120, wanted = =3D=3D 0x1050000 948: cpu5 LOCK (sleep mutex) NAMEI r =3D 0 at ../../../vm/uma_core.c:1849 947: cpu15 acquire(): lkp =3D=3D 0xc141b530, extflags =3D=3D 0x120, wanted = =3D=3D 0x60000 946: cpu5 LOCK (sleep mutex) UMA pcpu r =3D 0 at ../../../vm/uma_core.c:1832 945: cpu15 UNLOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/ke= rn_lock.c:181 944: cpu15 lockmgr(): lkp =3D=3D 0xc141b530 (lk_wmesg =3D=3D "getblk"), own= er =3D=3D 0xffffffffffffffff, exclusivecount =3D=3D 0, flags =3D=3D 0x20212= 2, td =3D=3D 0xfffff800d3c06720 943: cpu5 UNLOCK (sleep mutex) filedesc structure r =3D 0 at ../../../kern/= kern_descrip.c:1363 942: cpu15 LOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vfs_= bio.c:2369 941: cpu5 LOCK (sleep mutex) filedesc structure r =3D 0 at ../../../kern/ke= rn_descrip.c:1363 940: cpu15 getblk(0xfffff800368adad0, 59072384, 16384) 939: cpu15 breadn(0xfffff800368adad0, 59072384, 16384) 938: cpu5 UNLOCK (sleep mutex) process lock r =3D 0 at ../../../kern/kern_d= escrip.c:1243 937: cpu15 UNLOCK (sleep mutex) buffer daemon lock r =3D 0 at ../../../kern= /vfs_bio.c:422 936: cpu5 LOCK (sleep mutex) process lock r =3D 0 at ../../../kern/kern_des= crip.c:1241 935: cpu15 LOCK (sleep mutex) buffer daemon lock r =3D 0 at ../../../kern/v= fs_bio.c:417 934: cpu5 XUNLOCK (sx) filelist lock r =3D 0 at ../../../kern/kern_descrip.= c:1354 933: cpu15 lockmgr(): lkp =3D=3D 0xc141b530 (lk_wmesg =3D=3D "getblk"), own= er =3D=3D 0xfffff800d3c06720, exclusivecount =3D=3D 1, flags =3D=3D 0x6, td= =3D=3D 0xfffff800d3c06720 932: cpu15 UNLOCK (sleep mutex) buf queue lock r =3D 0 at ../../../kern/vfs= _bio.c:1458 931: cpu5 UNLOCK (sleep mutex) filedesc structure r =3D 0 at ../../../kern/= kern_descrip.c:1348 930: cpu5 LOCK (sleep mutex) filedesc structure r =3D 0 at ../../../kern/ke= rn_descrip.c:1348 929: cpu15 bremfreel(0xc141b498) vp 0xfffff800368adad0 flags a00000a0 928: cpu5 UNLOCK (sleep mutex) sleep mtxpool r =3D 0 at ../../../kern/kern_= prot.c:1862 927: cpu15 LOCK (sleep mutex) buf queue lock r =3D 0 at ../../../kern/vfs_b= io.c:1423 926: cpu5 LOCK (sleep mutex) sleep mtxpool r =3D 0 at ../../../kern/kern_pr= ot.c:1860 925: cpu15 bqrelse(0xc141b498) vp 0xfffff800368adad0 flags a00000a0 924: cpu5 XLOCK (sx) filelist lock r =3D 0 at ../../../kern/kern_descrip.c:= 1322 923: cpu15 UNLOCK (sleep mutex) vm object r =3D 0 at ../../../kern/vfs_bio.= c:3427 922: cpu15 UNLOCK (sleep mutex) vm page queue mutex r =3D 0 at ../../../ker= n/vfs_bio.c:3426 921: cpu5 UNLOCK (sleep mutex) UMA pcpu r =3D 0 at ../../../vm/uma_core.c:1= 853 920: cpu15 LOCK (sleep mutex) vm page queue mutex r =3D 0 at ../../../kern/= vfs_bio.c:3414 919: cpu5 UNLOCK (sleep mutex) Files r =3D 0 at ../../../vm/uma_core.c:1851 918: cpu15 LOCK (sleep mutex) vm object r =3D 0 at ../../../kern/vfs_bio.c:= 3413 917: cpu5 LOCK (sleep mutex) Files r =3D 0 at ../../../vm/uma_core.c:1849 916: cpu15 UNLOCK (sleep mutex) vm object r =3D 0 at ../../../kern/vfs_bio.= c:2295 915: cpu5 LOCK (sleep mutex) UMA pcpu r =3D 0 at ../../../vm/uma_core.c:1832 914: cpu15 LOCK (sleep mutex) vm object r =3D 0 at ../../../kern/vfs_bio.c:= 2239 913: cpu15 bdirty(0xc141b498) vp 0xfffff800368adad0 flags a00000a0 912: cpu15 UNLOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vf= s_bio.c:937 911: cpu15 LOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vfs_= bio.c:902 910: cpu15 bdwrite(0xc141b498) vp 0xfffff800368adad0 flags a00000a0 909: cpu15 UNLOCK (sleep mutex) FFS r =3D 0 at ../../../ufs/ffs/ffs_alloc.c= :1898 908: cpu15 LOCK (sleep mutex) FFS r =3D 0 at ../../../ufs/ffs/ffs_alloc.c:1= 835 907: cpu5 UNLOCK (sleep mutex) UMA pcpu r =3D 0 at ../../../vm/uma_core.c:2= 283 906: cpu5 UNLOCK (sleep mutex) NAMEI r =3D 0 at ../../../vm/uma_core.c:2281 905: cpu15 getblk(0xfffff800368adad0, 59072384, 16384) =3D 0xc141b498 904: cpu5 LOCK (sleep mutex) NAMEI r =3D 0 at ../../../vm/uma_core.c:2276 903: cpu5 LOCK (sleep mutex) UMA pcpu r =3D 0 at ../../../vm/uma_core.c:2258 902: cpu15 bremfree(0xc141b498) vp 0xfffff800368adad0 flags 200000a0 901: cpu5 UNLOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vfs= _subr.c:1962 900: cpu15 acquire(): lkp =3D=3D 0xc141b530, extflags =3D=3D 0x120, wanted = =3D=3D 0x1050000 899: cpu5 lockmgr(): lkp =3D=3D 0xfffff800c13224b8 (lk_wmesg =3D=3D "ufs"),= owner =3D=3D 0xfffff800d3c06000, exclusivecount =3D=3D 1, flags =3D=3D 0x6= , td =3D=3D 0xfffff800d3c06000 898: cpu15 acquire(): lkp =3D=3D 0xc141b530, extflags =3D=3D 0x120, wanted = =3D=3D 0x60000 897: cpu15 UNLOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/ke= rn_lock.c:181 896: cpu5 LOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vfs_s= ubr.c:2022 895: cpu15 lockmgr(): lkp =3D=3D 0xc141b530 (lk_wmesg =3D=3D "getblk"), own= er =3D=3D 0xffffffffffffffff, exclusivecount =3D=3D 0, flags =3D=3D 0x20212= 2, td =3D=3D 0xfffff800d3c06720 894: cpu5 UNLOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vfs= _subr.c:2020 893: cpu15 LOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vfs_= bio.c:2369 892: cpu5 LOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vfs_s= ubr.c:1927 891: cpu15 getblk(0xfffff800368adad0, 59072384, 16384) 890: cpu15 breadn(0xfffff800368adad0, 59072384, 16384) 889: cpu5 UNLOCK (sleep mutex) Name Cache r =3D 0 at ../../../kern/vfs_cach= e.c:434 888: cpu15 UNLOCK (sleep mutex) buffer daemon lock r =3D 0 at ../../../kern= /vfs_bio.c:422 887: cpu15 LOCK (sleep mutex) buffer daemon lock r =3D 0 at ../../../kern/v= fs_bio.c:417 886: cpu5 LOCK (sleep mutex) Name Cache r =3D 0 at ../../../kern/vfs_cache.= c:354 885: cpu15 lockmgr(): lkp =3D=3D 0xc141b530 (lk_wmesg =3D=3D "getblk"), own= er =3D=3D 0xfffff800d3c06720, exclusivecount =3D=3D 1, flags =3D=3D 0x6, td= =3D=3D 0xfffff800d3c06720 884: cpu15 UNLOCK (sleep mutex) buf queue lock r =3D 0 at ../../../kern/vfs= _bio.c:1458 883: cpu5 UNLOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vfs= _subr.c:1962 882: cpu5 lockmgr(): lkp =3D=3D 0xfffff800c63e1748 (lk_wmesg =3D=3D "ufs"),= owner =3D=3D 0xfffff800d3c06000, exclusivecount =3D=3D 1, flags =3D=3D 0x6= , td =3D=3D 0xfffff800d3c06000 881: cpu5 LOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vfs_s= ubr.c:2022 880: cpu5 UNLOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vfs= _subr.c:2020 879: cpu5 LOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vfs_s= ubr.c:1927 878: cpu5 acquire(): lkp =3D=3D 0xfffff800c13224b8, extflags =3D=3D 0x40, w= anted =3D=3D 0x1050000 877: cpu5 acquire(): lkp =3D=3D 0xfffff800c13224b8, extflags =3D=3D 0x40, w= anted =3D=3D 0x60000 876: cpu5 UNLOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/ker= n_lock.c:181 875: cpu15 bremfreel(0xc141b498) vp 0xfffff800368adad0 flags a00000a0 874: cpu5 lockmgr(): lkp =3D=3D 0xfffff800c13224b8 (lk_wmesg =3D=3D "ufs"),= owner =3D=3D 0xffffffffffffffff, exclusivecount =3D=3D 0, flags =3D=3D 0x2= 002, td =3D=3D 0xfffff800d3c06000 873: cpu15 LOCK (sleep mutex) buf queue lock r =3D 0 at ../../../kern/vfs_b= io.c:1423 872: cpu15 bqrelse(0xc141b498) vp 0xfffff800368adad0 flags a00000a0 871: cpu5 UNLOCK (sleep mutex) Name Cache r =3D 0 at ../../../kern/vfs_cach= e.c:450 870: cpu15 UNLOCK (sleep mutex) vm object r =3D 0 at ../../../kern/vfs_bio.= c:3427 869: cpu5 LOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vfs_c= ache.c:449 868: cpu15 UNLOCK (sleep mutex) vm page queue mutex r =3D 0 at ../../../ker= n/vfs_bio.c:3426 867: cpu5 LOCK (sleep mutex) Name Cache r =3D 0 at ../../../kern/vfs_cache.= c:354 866: cpu15 LOCK (sleep mutex) vm page queue mutex r =3D 0 at ../../../kern/= vfs_bio.c:3414 865: cpu15 LOCK (sleep mutex) vm object r =3D 0 at ../../../kern/vfs_bio.c:= 3413 864: cpu15 UNLOCK (sleep mutex) vm object r =3D 0 at ../../../kern/vfs_bio.= c:2295 863: cpu15 LOCK (sleep mutex) vm object r =3D 0 at ../../../kern/vfs_bio.c:= 2239 862: cpu5 UNLOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vfs= _subr.c:1962 861: cpu5 lockmgr(): lkp =3D=3D 0xfffff800c5adc6c8 (lk_wmesg =3D=3D "ufs"),= owner =3D=3D 0xfffff800d3c06000, exclusivecount =3D=3D 1, flags =3D=3D 0x6= , td =3D=3D 0xfffff800d3c06000 860: cpu15 bdirty(0xc141b498) vp 0xfffff800368adad0 flags a00000a0 859: cpu15 UNLOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vf= s_bio.c:937 858: cpu5 LOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vfs_s= ubr.c:2022 857: cpu15 LOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vfs_= bio.c:902 856: cpu5 UNLOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vfs= _subr.c:2020 855: cpu15 bdwrite(0xc141b498) vp 0xfffff800368adad0 flags a00000a0 854: cpu5 LOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vfs_s= ubr.c:1927 853: cpu15 UNLOCK (sleep mutex) FFS r =3D 0 at ../../../ufs/ffs/ffs_alloc.c= :1898 852: cpu15 LOCK (sleep mutex) FFS r =3D 0 at ../../../ufs/ffs/ffs_alloc.c:1= 835 851: cpu5 acquire(): lkp =3D=3D 0xfffff800c63e1748, extflags =3D=3D 0x40, w= anted =3D=3D 0x1050000 850: cpu5 acquire(): lkp =3D=3D 0xfffff800c63e1748, extflags =3D=3D 0x40, w= anted =3D=3D 0x60000 849: cpu15 getblk(0xfffff800368adad0, 59072384, 16384) =3D 0xc141b498 848: cpu5 UNLOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/ker= n_lock.c:181 847: cpu5 lockmgr(): lkp =3D=3D 0xfffff800c63e1748 (lk_wmesg =3D=3D "ufs"),= owner =3D=3D 0xffffffffffffffff, exclusivecount =3D=3D 0, flags =3D=3D 0x2= 002, td =3D=3D 0xfffff800d3c06000 846: cpu15 bremfree(0xc141b498) vp 0xfffff800368adad0 flags 200000a0 845: cpu15 acquire(): lkp =3D=3D 0xc141b530, extflags =3D=3D 0x120, wanted = =3D=3D 0x1050000 844: cpu15 acquire(): lkp =3D=3D 0xc141b530, extflags =3D=3D 0x120, wanted = =3D=3D 0x60000 843: cpu5 UNLOCK (sleep mutex) Name Cache r =3D 0 at ../../../kern/vfs_cach= e.c:450 842: cpu5 LOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vfs_c= ache.c:449 841: cpu15 UNLOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/ke= rn_lock.c:181 840: cpu15 lockmgr(): lkp =3D=3D 0xc141b530 (lk_wmesg =3D=3D "getblk"), own= er =3D=3D 0xffffffffffffffff, exclusivecount =3D=3D 0, flags =3D=3D 0x20212= 2, td =3D=3D 0xfffff800d3c06720 839: cpu5 LOCK (sleep mutex) Name Cache r =3D 0 at ../../../kern/vfs_cache.= c:354 838: cpu15 LOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vfs_= bio.c:2369 837: cpu15 getblk(0xfffff800368adad0, 59072384, 16384) 836: cpu15 breadn(0xfffff800368adad0, 59072384, 16384) 835: cpu15 UNLOCK (sleep mutex) buffer daemon lock r =3D 0 at ../../../kern= /vfs_bio.c:422 834: cpu15 LOCK (sleep mutex) buffer daemon lock r =3D 0 at ../../../kern/v= fs_bio.c:417 833: cpu15 lockmgr(): lkp =3D=3D 0xc141b530 (lk_wmesg =3D=3D "getblk"), own= er =3D=3D 0xfffff800d3c06720, exclusivecount =3D=3D 1, flags =3D=3D 0x6, td= =3D=3D 0xfffff800d3c06720 832: cpu15 UNLOCK (sleep mutex) buf queue lock r =3D 0 at ../../../kern/vfs= _bio.c:1458 831: cpu15 bremfreel(0xc141b498) vp 0xfffff800368adad0 flags a00000a0 830: cpu5 UNLOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vfs= _subr.c:1962 829: cpu15 LOCK (sleep mutex) buf queue lock r =3D 0 at ../../../kern/vfs_b= io.c:1423 828: cpu5 lockmgr(): lkp =3D=3D 0xfffff800f2aa0cf8 (lk_wmesg =3D=3D "ufs"),= owner =3D=3D 0xfffff800d3c06000, exclusivecount =3D=3D 1, flags =3D=3D 0x6= , td =3D=3D 0xfffff800d3c06000 827: cpu5 LOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vfs_s= ubr.c:2022 826: cpu15 bqrelse(0xc141b498) vp 0xfffff800368adad0 flags a00000a0 825: cpu15 UNLOCK (sleep mutex) vm object r =3D 0 at ../../../kern/vfs_bio.= c:3427 824: cpu5 UNLOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vfs= _subr.c:2020 823: cpu15 UNLOCK (sleep mutex) vm page queue mutex r =3D 0 at ../../../ker= n/vfs_bio.c:3426 822: cpu5 LOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vfs_s= ubr.c:1927 821: cpu15 LOCK (sleep mutex) vm page queue mutex r =3D 0 at ../../../kern/= vfs_bio.c:3414 820: cpu15 LOCK (sleep mutex) vm object r =3D 0 at ../../../kern/vfs_bio.c:= 3413 819: cpu15 UNLOCK (sleep mutex) vm object r =3D 0 at ../../../kern/vfs_bio.= c:2295 818: cpu5 acquire(): lkp =3D=3D 0xfffff800c5adc6c8, extflags =3D=3D 0x40, w= anted =3D=3D 0x1050000 817: cpu5 acquire(): lkp =3D=3D 0xfffff800c5adc6c8, extflags =3D=3D 0x40, w= anted =3D=3D 0x60000 816: cpu15 LOCK (sleep mutex) vm object r =3D 0 at ../../../kern/vfs_bio.c:= 2239 815: cpu5 UNLOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/ker= n_lock.c:181 814: cpu5 lockmgr(): lkp =3D=3D 0xfffff800c5adc6c8 (lk_wmesg =3D=3D "ufs"),= owner =3D=3D 0xffffffffffffffff, exclusivecount =3D=3D 0, flags =3D=3D 0x2= 002, td =3D=3D 0xfffff800d3c06000 813: cpu15 bdirty(0xc141b498) vp 0xfffff800368adad0 flags a00000a0 812: cpu15 UNLOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vf= s_bio.c:937 811: cpu15 LOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vfs_= bio.c:902 810: cpu5 UNLOCK (sleep mutex) Name Cache r =3D 0 at ../../../kern/vfs_cach= e.c:450 809: cpu15 bdwrite(0xc141b498) vp 0xfffff800368adad0 flags a00000a0 808: cpu5 LOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vfs_c= ache.c:449 807: cpu15 UNLOCK (sleep mutex) FFS r =3D 0 at ../../../ufs/ffs/ffs_alloc.c= :1898 806: cpu15 LOCK (sleep mutex) FFS r =3D 0 at ../../../ufs/ffs/ffs_alloc.c:1= 835 805: cpu5 LOCK (sleep mutex) Name Cache r =3D 0 at ../../../kern/vfs_cache.= c:354 804: cpu15 getblk(0xfffff800368adad0, 59072384, 16384) =3D 0xc141b498 803: cpu5 UNLOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/ker= n_lock.c:181 802: cpu15 bremfree(0xc141b498) vp 0xfffff800368adad0 flags 200000a0 801: cpu5 lockmgr(): lkp =3D=3D 0xfffff800f278b118 (lk_wmesg =3D=3D "ufs"),= owner =3D=3D 0xfffff800d3c06000, exclusivecount =3D=3D 1, flags =3D=3D 0x2= 006, td =3D=3D 0xfffff800d3c06000 800: cpu15 acquire(): lkp =3D=3D 0xc141b530, extflags =3D=3D 0x120, wanted = =3D=3D 0x1050000 799: cpu5 LOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vfs_s= ubr.c:1927 798: cpu15 acquire(): lkp =3D=3D 0xc141b530, extflags =3D=3D 0x120, wanted = =3D=3D 0x60000 797: cpu15 UNLOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/ke= rn_lock.c:181 796: cpu15 lockmgr(): lkp =3D=3D 0xc141b530 (lk_wmesg =3D=3D "getblk"), own= er =3D=3D 0xffffffffffffffff, exclusivecount =3D=3D 0, flags =3D=3D 0x20212= 2, td =3D=3D 0xfffff800d3c06720 795: cpu5 acquire(): lkp =3D=3D 0xfffff800f2aa0cf8, extflags =3D=3D 0x40, w= anted =3D=3D 0x1050000 794: cpu5 acquire(): lkp =3D=3D 0xfffff800f2aa0cf8, extflags =3D=3D 0x40, w= anted =3D=3D 0x60000 793: cpu15 LOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vfs_= bio.c:2369 792: cpu5 UNLOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/ker= n_lock.c:181 791: cpu15 getblk(0xfffff800368adad0, 59072384, 16384) 790: cpu15 breadn(0xfffff800368adad0, 59072384, 16384) 789: cpu5 lockmgr(): lkp =3D=3D 0xfffff800f2aa0cf8 (lk_wmesg =3D=3D "ufs"),= owner =3D=3D 0xffffffffffffffff, exclusivecount =3D=3D 0, flags =3D=3D 0x2= 002, td =3D=3D 0xfffff800d3c06000 788: cpu15 UNLOCK (sleep mutex) buffer daemon lock r =3D 0 at ../../../kern= /vfs_bio.c:422 787: cpu15 LOCK (sleep mutex) buffer daemon lock r =3D 0 at ../../../kern/v= fs_bio.c:417 786: cpu5 UNLOCK (sleep mutex) Name Cache r =3D 0 at ../../../kern/vfs_cach= e.c:450 785: cpu15 lockmgr(): lkp =3D=3D 0xc141b530 (lk_wmesg =3D=3D "getblk"), own= er =3D=3D 0xfffff800d3c06720, exclusivecount =3D=3D 1, flags =3D=3D 0x6, td= =3D=3D 0xfffff800d3c06720 784: cpu5 LOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vfs_c= ache.c:449 783: cpu15 UNLOCK (sleep mutex) buf queue lock r =3D 0 at ../../../kern/vfs= _bio.c:1458 782: cpu5 LOCK (sleep mutex) Name Cache r =3D 0 at ../../../kern/vfs_cache.= c:354 781: cpu15 bremfreel(0xc141b498) vp 0xfffff800368adad0 flags a00000a0 780: cpu15 LOCK (sleep mutex) buf queue lock r =3D 0 at ../../../kern/vfs_b= io.c:1423 779: cpu15 bqrelse(0xc141b498) vp 0xfffff800368adad0 flags a00000a0 778: cpu15 UNLOCK (sleep mutex) vm object r =3D 0 at ../../../kern/vfs_bio.= c:3427 777: cpu5 acquire(): lkp =3D=3D 0xfffff800f278b118, extflags =3D=3D 0x40, w= anted =3D=3D 0x1050000 776: cpu15 UNLOCK (sleep mutex) vm page queue mutex r =3D 0 at ../../../ker= n/vfs_bio.c:3426 775: cpu5 acquire(): lkp =3D=3D 0xfffff800f278b118, extflags =3D=3D 0x40, w= anted =3D=3D 0x60000 774: cpu5 UNLOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/ker= n_lock.c:181 773: cpu15 LOCK (sleep mutex) vm page queue mutex r =3D 0 at ../../../kern/= vfs_bio.c:3414 772: cpu5 lockmgr(): lkp =3D=3D 0xfffff800f278b118 (lk_wmesg =3D=3D "ufs"),= owner =3D=3D 0xffffffffffffffff, exclusivecount =3D=3D 0, flags =3D=3D 0x3= 002, td =3D=3D 0xfffff800d3c06000 771: cpu15 LOCK (sleep mutex) vm object r =3D 0 at ../../../kern/vfs_bio.c:= 3413 770: cpu15 UNLOCK (sleep mutex) vm object r =3D 0 at ../../../kern/vfs_bio.= c:2295 769: cpu5 LOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vfs_v= nops.c:801 768: cpu15 LOCK (sleep mutex) vm object r =3D 0 at ../../../kern/vfs_bio.c:= 2239 767: cpu5 UNLOCK (sleep mutex) filedesc structure r =3D 0 at ../../../kern/= vfs_lookup.c:180 766: cpu15 bdirty(0xc141b498) vp 0xfffff800368adad0 flags a00000a0 765: cpu5 LOCK (sleep mutex) filedesc structure r =3D 0 at ../../../kern/vf= s_lookup.c:180 764: cpu15 UNLOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vf= s_bio.c:937 763: cpu5 UNLOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vfs= _subr.c:1838 762: cpu15 LOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vfs_= bio.c:902 761: cpu5 LOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vfs_s= ubr.c:1836 760: cpu5 UNLOCK (sleep mutex) filedesc structure r =3D 0 at ../../../kern/= vfs_lookup.c:173 759: cpu15 bdwrite(0xc141b498) vp 0xfffff800368adad0 flags a00000a0 758: cpu15 UNLOCK (sleep mutex) FFS r =3D 0 at ../../../ufs/ffs/ffs_alloc.c= :1898 757: cpu5 LOCK (sleep mutex) filedesc structure r =3D 0 at ../../../kern/vf= s_lookup.c:173 756: cpu15 LOCK (sleep mutex) FFS r =3D 0 at ../../../ufs/ffs/ffs_alloc.c:1= 835 755: cpu5 UNLOCK (sleep mutex) UMA pcpu r =3D 0 at ../../../vm/uma_core.c:1= 853 754: cpu5 UNLOCK (sleep mutex) NAMEI r =3D 0 at ../../../vm/uma_core.c:1851 753: cpu15 getblk(0xfffff800368adad0, 59072384, 16384) =3D 0xc141b498 752: cpu5 LOCK (sleep mutex) NAMEI r =3D 0 at ../../../vm/uma_core.c:1849 751: cpu15 bremfree(0xc141b498) vp 0xfffff800368adad0 flags 200000a0 750: cpu5 LOCK (sleep mutex) UMA pcpu r =3D 0 at ../../../vm/uma_core.c:1832 749: cpu15 acquire(): lkp =3D=3D 0xc141b530, extflags =3D=3D 0x120, wanted = =3D=3D 0x1050000 748: cpu15 acquire(): lkp =3D=3D 0xc141b530, extflags =3D=3D 0x120, wanted = =3D=3D 0x60000 747: cpu15 UNLOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/ke= rn_lock.c:181 746: cpu15 lockmgr(): lkp =3D=3D 0xc141b530 (lk_wmesg =3D=3D "getblk"), own= er =3D=3D 0xffffffffffffffff, exclusivecount =3D=3D 0, flags =3D=3D 0x20212= 2, td =3D=3D 0xfffff800d3c06720 745: cpu5 UNLOCK (sleep mutex) filedesc structure r =3D 0 at ../../../kern/= vfs_syscalls.c:3769 744: cpu15 LOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vfs_= bio.c:2369 743: cpu15 getblk(0xfffff800368adad0, 59072384, 16384) 742: cpu5 LOCK (sleep mutex) filedesc structure r =3D 0 at ../../../kern/vf= s_syscalls.c:3765 741: cpu15 breadn(0xfffff800368adad0, 59072384, 16384) 740: cpu15 UNLOCK (sleep mutex) buffer daemon lock r =3D 0 at ../../../kern= /vfs_bio.c:422 739: cpu15 LOCK (sleep mutex) buffer daemon lock r =3D 0 at ../../../kern/v= fs_bio.c:417 738: cpu5 UNLOCK (sleep mutex) filedesc structure r =3D 0 at ../../../kern/= vfs_syscalls.c:3769 737: cpu15 lockmgr(): lkp =3D=3D 0xc141b530 (lk_wmesg =3D=3D "getblk"), own= er =3D=3D 0xfffff800d3c06720, exclusivecount =3D=3D 1, flags =3D=3D 0x6, td= =3D=3D 0xfffff800d3c06720 736: cpu5 LOCK (sleep mutex) filedesc structure r =3D 0 at ../../../kern/vf= s_syscalls.c:3765 735: cpu15 UNLOCK (sleep mutex) buf queue lock r =3D 0 at ../../../kern/vfs= _bio.c:1458 734: cpu15 bremfreel(0xc141b498) vp 0xfffff800368adad0 flags a00000a0 733: cpu15 LOCK (sleep mutex) buf queue lock r =3D 0 at ../../../kern/vfs_b= io.c:1423 732: cpu15 bqrelse(0xc141b498) vp 0xfffff800368adad0 flags a00000a0 731: cpu15 UNLOCK (sleep mutex) vm object r =3D 0 at ../../../kern/vfs_bio.= c:3427 730: cpu15 UNLOCK (sleep mutex) vm page queue mutex r =3D 0 at ../../../ker= n/vfs_bio.c:3426 729: cpu15 LOCK (sleep mutex) vm page queue mutex r =3D 0 at ../../../kern/= vfs_bio.c:3414 728: cpu5 UNLOCK (sleep mutex) UMA pcpu r =3D 0 at ../../../vm/uma_core.c:2= 283 727: cpu5 UNLOCK (sleep mutex) NAMEI r =3D 0 at ../../../vm/uma_core.c:2281 726: cpu15 LOCK (sleep mutex) vm object r =3D 0 at ../../../kern/vfs_bio.c:= 3413 725: cpu15 UNLOCK (sleep mutex) vm object r =3D 0 at ../../../kern/vfs_bio.= c:2295 724: cpu5 LOCK (sleep mutex) NAMEI r =3D 0 at ../../../vm/uma_core.c:2276 723: cpu15 LOCK (sleep mutex) vm object r =3D 0 at ../../../kern/vfs_bio.c:= 2239 722: cpu5 LOCK (sleep mutex) UMA pcpu r =3D 0 at ../../../vm/uma_core.c:2258 721: cpu15 bdirty(0xc141b498) vp 0xfffff800368adad0 flags a00000a0 720: cpu5 UNLOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vfs= _subr.c:1962 719: cpu15 UNLOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vf= s_bio.c:937 718: cpu5 lockmgr(): lkp =3D=3D 0xfffff800c13224b8 (lk_wmesg =3D=3D "ufs"),= owner =3D=3D 0xfffff800d3c06000, exclusivecount =3D=3D 1, flags =3D=3D 0x6= , td =3D=3D 0xfffff800d3c06000 717: cpu15 LOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vfs_= bio.c:902 716: cpu5 LOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vfs_s= ubr.c:2022 715: cpu15 bdwrite(0xc141b498) vp 0xfffff800368adad0 flags a00000a0 714: cpu5 UNLOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vfs= _subr.c:2020 713: cpu15 UNLOCK (sleep mutex) FFS r =3D 0 at ../../../ufs/ffs/ffs_alloc.c= :1898 712: cpu15 LOCK (sleep mutex) FFS r =3D 0 at ../../../ufs/ffs/ffs_alloc.c:1= 835 711: cpu5 LOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vfs_s= ubr.c:1927 710: cpu15 getblk(0xfffff800368adad0, 59072384, 16384) =3D 0xc141b498 709: cpu5 UNLOCK (sleep mutex) Name Cache r =3D 0 at ../../../kern/vfs_cach= e.c:540 708: cpu15 bremfree(0xc141b498) vp 0xfffff800368adad0 flags 200000a0 707: cpu15 acquire(): lkp =3D=3D 0xc141b530, extflags =3D=3D 0x120, wanted = =3D=3D 0x1050000 706: cpu5 LOCK (sleep mutex) Name Cache r =3D 0 at ../../../kern/vfs_cache.= c:493 705: cpu15 acquire(): lkp =3D=3D 0xc141b530, extflags =3D=3D 0x120, wanted = =3D=3D 0x60000 704: cpu5 UNLOCK (sleep mutex) UMA pcpu r =3D 0 at ../../../vm/uma_core.c:1= 853 703: cpu15 UNLOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/ke= rn_lock.c:181 702: cpu5 UNLOCK (sleep mutex) S VFS Cache r =3D 0 at ../../../vm/uma_core.= c:1851 701: cpu15 lockmgr(): lkp =3D=3D 0xc141b530 (lk_wmesg =3D=3D "getblk"), own= er =3D=3D 0xffffffffffffffff, exclusivecount =3D=3D 0, flags =3D=3D 0x20212= 2, td =3D=3D 0xfffff800d3c06720 700: cpu5 LOCK (sleep mutex) S VFS Cache r =3D 0 at ../../../vm/uma_core.c:= 1849 699: cpu15 LOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vfs_= bio.c:2369 698: cpu5 LOCK (sleep mutex) UMA pcpu r =3D 0 at ../../../vm/uma_core.c:1832 697: cpu15 getblk(0xfffff800368adad0, 59072384, 16384) 696: cpu15 breadn(0xfffff800368adad0, 59072384, 16384) 695: cpu5 UNLOCK (sleep mutex) dirhash r =3D 0 at ../../../ufs/ufs/ufs_dirh= ash.c:473 694: cpu15 UNLOCK (sleep mutex) buffer daemon lock r =3D 0 at ../../../kern= /vfs_bio.c:422 693: cpu15 LOCK (sleep mutex) buffer daemon lock r =3D 0 at ../../../kern/v= fs_bio.c:417 692: cpu15 lockmgr(): lkp =3D=3D 0xc141b530 (lk_wmesg =3D=3D "getblk"), own= er =3D=3D 0xfffff800d3c06720, exclusivecount =3D=3D 1, flags =3D=3D 0x6, td= =3D=3D 0xfffff800d3c06720 691: cpu5 UNLOCK (sleep mutex) dirhash list r =3D 0 at ../../../ufs/ufs/ufs= _dirhash.c:364 690: cpu15 UNLOCK (sleep mutex) buf queue lock r =3D 0 at ../../../kern/vfs= _bio.c:1458 689: cpu5 LOCK (sleep mutex) dirhash r =3D 0 at ../../../ufs/ufs/ufs_dirhas= h.c:349 688: cpu5 LOCK (sleep mutex) dirhash list r =3D 0 at ../../../ufs/ufs/ufs_d= irhash.c:348 687: cpu15 bremfreel(0xc141b498) vp 0xfffff800368adad0 flags a00000a0 686: cpu15 LOCK (sleep mutex) buf queue lock r =3D 0 at ../../../kern/vfs_b= io.c:1423 685: cpu5 UNLOCK (sleep mutex) Name Cache r =3D 0 at ../../../kern/vfs_cach= e.c:392 684: cpu15 bqrelse(0xc141b498) vp 0xfffff800368adad0 flags a00000a0 683: cpu15 UNLOCK (sleep mutex) vm object r =3D 0 at ../../../kern/vfs_bio.= c:3427 682: cpu15 UNLOCK (sleep mutex) vm page queue mutex r =3D 0 at ../../../ker= n/vfs_bio.c:3426 681: cpu5 LOCK (sleep mutex) Name Cache r =3D 0 at ../../../kern/vfs_cache.= c:354 680: cpu15 LOCK (sleep mutex) vm page queue mutex r =3D 0 at ../../../kern/= vfs_bio.c:3414 679: cpu15 LOCK (sleep mutex) vm object r =3D 0 at ../../../kern/vfs_bio.c:= 3413 678: cpu5 UNLOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vfs= _subr.c:1962 677: cpu15 UNLOCK (sleep mutex) vm object r =3D 0 at ../../../kern/vfs_bio.= c:2295 676: cpu5 lockmgr(): lkp =3D=3D 0xfffff800c63e1748 (lk_wmesg =3D=3D "ufs"),= owner =3D=3D 0xfffff800d3c06000, exclusivecount =3D=3D 1, flags =3D=3D 0x6= , td =3D=3D 0xfffff800d3c06000 675: cpu15 LOCK (sleep mutex) vm object r =3D 0 at ../../../kern/vfs_bio.c:= 2239 674: cpu5 LOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vfs_s= ubr.c:2022 673: cpu15 bdirty(0xc141b498) vp 0xfffff800368adad0 flags a00000a0 672: cpu15 UNLOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vf= s_bio.c:937 671: cpu5 UNLOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vfs= _subr.c:2020 670: cpu15 LOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vfs_= bio.c:902 669: cpu5 LOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vfs_s= ubr.c:1927 668: cpu15 bdwrite(0xc141b498) vp 0xfffff800368adad0 flags a00000a0 667: cpu15 UNLOCK (sleep mutex) FFS r =3D 0 at ../../../ufs/ffs/ffs_alloc.c= :1898 666: cpu5 acquire(): lkp =3D=3D 0xfffff800c13224b8, extflags =3D=3D 0x40, w= anted =3D=3D 0x1050000 665: cpu15 LOCK (sleep mutex) FFS r =3D 0 at ../../../ufs/ffs/ffs_alloc.c:1= 835 664: cpu5 acquire(): lkp =3D=3D 0xfffff800c13224b8, extflags =3D=3D 0x40, w= anted =3D=3D 0x60000 663: cpu5 UNLOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/ker= n_lock.c:181 662: cpu15 getblk(0xfffff800368adad0, 59072384, 16384) =3D 0xc141b498 661: cpu5 lockmgr(): lkp =3D=3D 0xfffff800c13224b8 (lk_wmesg =3D=3D "ufs"),= owner =3D=3D 0xffffffffffffffff, exclusivecount =3D=3D 0, flags =3D=3D 0x2= 002, td =3D=3D 0xfffff800d3c06000 660: cpu15 bremfree(0xc141b498) vp 0xfffff800368adad0 flags 200000a0 659: cpu5 UNLOCK (sleep mutex) Name Cache r =3D 0 at ../../../kern/vfs_cach= e.c:450 658: cpu15 acquire(): lkp =3D=3D 0xc141b530, extflags =3D=3D 0x120, wanted = =3D=3D 0x1050000 657: cpu5 LOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vfs_c= ache.c:449 656: cpu15 acquire(): lkp =3D=3D 0xc141b530, extflags =3D=3D 0x120, wanted = =3D=3D 0x60000 655: cpu15 UNLOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/ke= rn_lock.c:181 654: cpu5 LOCK (sleep mutex) Name Cache r =3D 0 at ../../../kern/vfs_cache.= c:354 653: cpu15 lockmgr(): lkp =3D=3D 0xc141b530 (lk_wmesg =3D=3D "getblk"), own= er =3D=3D 0xffffffffffffffff, exclusivecount =3D=3D 0, flags =3D=3D 0x20212= 2, td =3D=3D 0xfffff800d3c06720 652: cpu15 LOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vfs_= bio.c:2369 651: cpu15 getblk(0xfffff800368adad0, 59072384, 16384) 650: cpu15 breadn(0xfffff800368adad0, 59072384, 16384) 649: cpu5 UNLOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vfs= _subr.c:1962 648: cpu5 lockmgr(): lkp =3D=3D 0xfffff800c5adc6c8 (lk_wmesg =3D=3D "ufs"),= owner =3D=3D 0xfffff800d3c06000, exclusivecount =3D=3D 1, flags =3D=3D 0x6= , td =3D=3D 0xfffff800d3c06000 647: cpu15 UNLOCK (sleep mutex) buffer daemon lock r =3D 0 at ../../../kern= /vfs_bio.c:422 646: cpu15 LOCK (sleep mutex) buffer daemon lock r =3D 0 at ../../../kern/v= fs_bio.c:417 645: cpu5 LOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vfs_s= ubr.c:2022 644: cpu15 lockmgr(): lkp =3D=3D 0xc141b530 (lk_wmesg =3D=3D "getblk"), own= er =3D=3D 0xfffff800d3c06720, exclusivecount =3D=3D 1, flags =3D=3D 0x6, td= =3D=3D 0xfffff800d3c06720 643: cpu5 UNLOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vfs= _subr.c:2020 642: cpu15 UNLOCK (sleep mutex) buf queue lock r =3D 0 at ../../../kern/vfs= _bio.c:1458 641: cpu5 LOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vfs_s= ubr.c:1927 640: cpu15 bremfreel(0xc141b498) vp 0xfffff800368adad0 flags a00000a0 639: cpu15 LOCK (sleep mutex) buf queue lock r =3D 0 at ../../../kern/vfs_b= io.c:1423 638: cpu5 acquire(): lkp =3D=3D 0xfffff800c63e1748, extflags =3D=3D 0x40, w= anted =3D=3D 0x1050000 637: cpu5 acquire(): lkp =3D=3D 0xfffff800c63e1748, extflags =3D=3D 0x40, w= anted =3D=3D 0x60000 636: cpu15 bqrelse(0xc141b498) vp 0xfffff800368adad0 flags a00000a0 635: cpu5 UNLOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/ker= n_lock.c:181 634: cpu15 UNLOCK (sleep mutex) vm object r =3D 0 at ../../../kern/vfs_bio.= c:3427 633: cpu5 lockmgr(): lkp =3D=3D 0xfffff800c63e1748 (lk_wmesg =3D=3D "ufs"),= owner =3D=3D 0xffffffffffffffff, exclusivecount =3D=3D 0, flags =3D=3D 0x2= 002, td =3D=3D 0xfffff800d3c06000 632: cpu15 UNLOCK (sleep mutex) vm page queue mutex r =3D 0 at ../../../ker= n/vfs_bio.c:3426 631: cpu15 LOCK (sleep mutex) vm page queue mutex r =3D 0 at ../../../kern/= vfs_bio.c:3414 630: cpu5 UNLOCK (sleep mutex) Name Cache r =3D 0 at ../../../kern/vfs_cach= e.c:450 629: cpu15 LOCK (sleep mutex) vm object r =3D 0 at ../../../kern/vfs_bio.c:= 3413 628: cpu5 LOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vfs_c= ache.c:449 627: cpu15 UNLOCK (sleep mutex) vm object r =3D 0 at ../../../kern/vfs_bio.= c:2295 626: cpu15 LOCK (sleep mutex) vm object r =3D 0 at ../../../kern/vfs_bio.c:= 2239 625: cpu5 LOCK (sleep mutex) Name Cache r =3D 0 at ../../../kern/vfs_cache.= c:354 624: cpu15 bdirty(0xc141b498) vp 0xfffff800368adad0 flags a00000a0 623: cpu15 UNLOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vf= s_bio.c:937 622: cpu15 LOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vfs_= bio.c:902 621: cpu5 UNLOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vfs= _subr.c:1962 620: cpu5 lockmgr(): lkp =3D=3D 0xfffff800f2aa0cf8 (lk_wmesg =3D=3D "ufs"),= owner =3D=3D 0xfffff800d3c06000, exclusivecount =3D=3D 1, flags =3D=3D 0x6= , td =3D=3D 0xfffff800d3c06000 619: cpu15 bdwrite(0xc141b498) vp 0xfffff800368adad0 flags a00000a0 618: cpu15 UNLOCK (sleep mutex) FFS r =3D 0 at ../../../ufs/ffs/ffs_alloc.c= :1898 617: cpu5 LOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vfs_s= ubr.c:2022 616: cpu15 LOCK (sleep mutex) FFS r =3D 0 at ../../../ufs/ffs/ffs_alloc.c:1= 835 615: cpu5 UNLOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vfs= _subr.c:2020 614: cpu15 getblk(0xfffff800368adad0, 59072384, 16384) =3D 0xc141b498 613: cpu5 LOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vfs_s= ubr.c:1927 612: cpu15 bremfree(0xc141b498) vp 0xfffff800368adad0 flags 200000a0 611: cpu15 acquire(): lkp =3D=3D 0xc141b530, extflags =3D=3D 0x120, wanted = =3D=3D 0x1050000 610: cpu5 acquire(): lkp =3D=3D 0xfffff800c5adc6c8, extflags =3D=3D 0x40, w= anted =3D=3D 0x1050000 609: cpu15 acquire(): lkp =3D=3D 0xc141b530, extflags =3D=3D 0x120, wanted = =3D=3D 0x60000 608: cpu5 acquire(): lkp =3D=3D 0xfffff800c5adc6c8, extflags =3D=3D 0x40, w= anted =3D=3D 0x60000 607: cpu5 UNLOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/ker= n_lock.c:181 606: cpu15 UNLOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/ke= rn_lock.c:181 605: cpu5 lockmgr(): lkp =3D=3D 0xfffff800c5adc6c8 (lk_wmesg =3D=3D "ufs"),= owner =3D=3D 0xffffffffffffffff, exclusivecount =3D=3D 0, flags =3D=3D 0x2= 002, td =3D=3D 0xfffff800d3c06000 604: cpu15 lockmgr(): lkp =3D=3D 0xc141b530 (lk_wmesg =3D=3D "getblk"), own= er =3D=3D 0xffffffffffffffff, exclusivecount =3D=3D 0, flags =3D=3D 0x20212= 2, td =3D=3D 0xfffff800d3c06720 603: cpu15 LOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vfs_= bio.c:2369 602: cpu5 UNLOCK (sleep mutex) Name Cache r =3D 0 at ../../../kern/vfs_cach= e.c:450 601: cpu15 getblk(0xfffff800368adad0, 59072384, 16384) 600: cpu5 LOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vfs_c= ache.c:449 599: cpu15 breadn(0xfffff800368adad0, 59072384, 16384) 598: cpu5 LOCK (sleep mutex) Name Cache r =3D 0 at ../../../kern/vfs_cache.= c:354 597: cpu15 UNLOCK (sleep mutex) buffer daemon lock r =3D 0 at ../../../kern= /vfs_bio.c:422 596: cpu15 LOCK (sleep mutex) buffer daemon lock r =3D 0 at ../../../kern/v= fs_bio.c:417 595: cpu15 lockmgr(): lkp =3D=3D 0xc141b530 (lk_wmesg =3D=3D "getblk"), own= er =3D=3D 0xfffff800d3c06720, exclusivecount =3D=3D 1, flags =3D=3D 0x6, td= =3D=3D 0xfffff800d3c06720 594: cpu5 UNLOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/ker= n_lock.c:181 593: cpu5 lockmgr(): lkp =3D=3D 0xfffff800f278b118 (lk_wmesg =3D=3D "ufs"),= owner =3D=3D 0xfffff800d3c06000, exclusivecount =3D=3D 1, flags =3D=3D 0x2= 006, td =3D=3D 0xfffff800d3c06000 592: cpu15 UNLOCK (sleep mutex) buf queue lock r =3D 0 at ../../../kern/vfs= _bio.c:1458 591: cpu5 LOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vfs_s= ubr.c:1927 590: cpu15 bremfreel(0xc141b498) vp 0xfffff800368adad0 flags a00000a0 589: cpu15 LOCK (sleep mutex) buf queue lock r =3D 0 at ../../../kern/vfs_b= io.c:1423 588: cpu15 bqrelse(0xc141b498) vp 0xfffff800368adad0 flags a00000a0 587: cpu5 acquire(): lkp =3D=3D 0xfffff800f2aa0cf8, extflags =3D=3D 0x40, w= anted =3D=3D 0x1050000 586: cpu15 UNLOCK (sleep mutex) vm object r =3D 0 at ../../../kern/vfs_bio.= c:3427 585: cpu5 acquire(): lkp =3D=3D 0xfffff800f2aa0cf8, extflags =3D=3D 0x40, w= anted =3D=3D 0x60000 584: cpu5 UNLOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/ker= n_lock.c:181 583: cpu15 UNLOCK (sleep mutex) vm page queue mutex r =3D 0 at ../../../ker= n/vfs_bio.c:3426 582: cpu5 lockmgr(): lkp =3D=3D 0xfffff800f2aa0cf8 (lk_wmesg =3D=3D "ufs"),= owner =3D=3D 0xffffffffffffffff, exclusivecount =3D=3D 0, flags =3D=3D 0x2= 002, td =3D=3D 0xfffff800d3c06000 581: cpu15 LOCK (sleep mutex) vm page queue mutex r =3D 0 at ../../../kern/= vfs_bio.c:3414 580: cpu15 LOCK (sleep mutex) vm object r =3D 0 at ../../../kern/vfs_bio.c:= 3413 579: cpu5 UNLOCK (sleep mutex) Name Cache r =3D 0 at ../../../kern/vfs_cach= e.c:450 578: cpu15 UNLOCK (sleep mutex) vm object r =3D 0 at ../../../kern/vfs_bio.= c:2295 577: cpu5 LOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vfs_c= ache.c:449 576: cpu15 LOCK (sleep mutex) vm object r =3D 0 at ../../../kern/vfs_bio.c:= 2239 575: cpu5 LOCK (sleep mutex) Name Cache r =3D 0 at ../../../kern/vfs_cache.= c:354 574: cpu15 bdirty(0xc141b498) vp 0xfffff800368adad0 flags a00000a0 573: cpu15 UNLOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vf= s_bio.c:937 572: cpu15 LOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vfs_= bio.c:902 571: cpu15 bdwrite(0xc141b498) vp 0xfffff800368adad0 flags a00000a0 570: cpu5 acquire(): lkp =3D=3D 0xfffff800f278b118, extflags =3D=3D 0x40, w= anted =3D=3D 0x1050000 569: cpu15 UNLOCK (sleep mutex) FFS r =3D 0 at ../../../ufs/ffs/ffs_alloc.c= :1898 568: cpu5 acquire(): lkp =3D=3D 0xfffff800f278b118, extflags =3D=3D 0x40, w= anted =3D=3D 0x60000 567: cpu5 UNLOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/ker= n_lock.c:181 566: cpu15 LOCK (sleep mutex) FFS r =3D 0 at ../../../ufs/ffs/ffs_alloc.c:1= 835 565: cpu5 lockmgr(): lkp =3D=3D 0xfffff800f278b118 (lk_wmesg =3D=3D "ufs"),= owner =3D=3D 0xffffffffffffffff, exclusivecount =3D=3D 0, flags =3D=3D 0x3= 002, td =3D=3D 0xfffff800d3c06000 564: cpu15 getblk(0xfffff800368adad0, 59072384, 16384) =3D 0xc141b498 563: cpu5 LOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vfs_v= nops.c:801 562: cpu15 bremfree(0xc141b498) vp 0xfffff800368adad0 flags 200000a0 561: cpu5 UNLOCK (sleep mutex) filedesc structure r =3D 0 at ../../../kern/= vfs_lookup.c:180 560: cpu15 acquire(): lkp =3D=3D 0xc141b530, extflags =3D=3D 0x120, wanted = =3D=3D 0x1050000 559: cpu15 acquire(): lkp =3D=3D 0xc141b530, extflags =3D=3D 0x120, wanted = =3D=3D 0x60000 558: cpu5 LOCK (sleep mutex) filedesc structure r =3D 0 at ../../../kern/vf= s_lookup.c:180 557: cpu15 UNLOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/ke= rn_lock.c:181 556: cpu5 UNLOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vfs= _subr.c:1838 555: cpu15 lockmgr(): lkp =3D=3D 0xc141b530 (lk_wmesg =3D=3D "getblk"), own= er =3D=3D 0xffffffffffffffff, exclusivecount =3D=3D 0, flags =3D=3D 0x20212= 2, td =3D=3D 0xfffff800d3c06720 554: cpu5 LOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vfs_s= ubr.c:1836 553: cpu5 UNLOCK (sleep mutex) filedesc structure r =3D 0 at ../../../kern/= vfs_lookup.c:173 552: cpu15 LOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vfs_= bio.c:2369 551: cpu15 getblk(0xfffff800368adad0, 59072384, 16384) 550: cpu5 LOCK (sleep mutex) filedesc structure r =3D 0 at ../../../kern/vf= s_lookup.c:173 549: cpu15 breadn(0xfffff800368adad0, 59072384, 16384) 548: cpu5 UNLOCK (sleep mutex) UMA pcpu r =3D 0 at ../../../vm/uma_core.c:1= 853 547: cpu15 UNLOCK (sleep mutex) buffer daemon lock r =3D 0 at ../../../kern= /vfs_bio.c:422 546: cpu5 UNLOCK (sleep mutex) NAMEI r =3D 0 at ../../../vm/uma_core.c:1851 545: cpu15 LOCK (sleep mutex) buffer daemon lock r =3D 0 at ../../../kern/v= fs_bio.c:417 544: cpu5 LOCK (sleep mutex) NAMEI r =3D 0 at ../../../vm/uma_core.c:1849 543: cpu15 lockmgr(): lkp =3D=3D 0xc141b530 (lk_wmesg =3D=3D "getblk"), own= er =3D=3D 0xfffff800d3c06720, exclusivecount =3D=3D 1, flags =3D=3D 0x6, td= =3D=3D 0xfffff800d3c06720 542: cpu5 LOCK (sleep mutex) UMA pcpu r =3D 0 at ../../../vm/uma_core.c:1832 541: cpu15 UNLOCK (sleep mutex) buf queue lock r =3D 0 at ../../../kern/vfs= _bio.c:1458 540: cpu15 bremfreel(0xc141b498) vp 0xfffff800368adad0 flags a00000a0 539: cpu15 LOCK (sleep mutex) buf queue lock r =3D 0 at ../../../kern/vfs_b= io.c:1423 538: cpu15 bqrelse(0xc141b498) vp 0xfffff800368adad0 flags a00000a0 537: cpu5 UNLOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vfs= _subr.c:1962 536: cpu15 UNLOCK (sleep mutex) vm object r =3D 0 at ../../../kern/vfs_bio.= c:3427 535: cpu15 UNLOCK (sleep mutex) vm page queue mutex r =3D 0 at ../../../ker= n/vfs_bio.c:3426 534: cpu5 lockmgr(): lkp =3D=3D 0xfffff800c13224b8 (lk_wmesg =3D=3D "ufs"),= owner =3D=3D 0xfffff800d3c06000, exclusivecount =3D=3D 1, flags =3D=3D 0x6= , td =3D=3D 0xfffff800d3c06000 533: cpu5 LOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vfs_s= ubr.c:2022 532: cpu15 LOCK (sleep mutex) vm page queue mutex r =3D 0 at ../../../kern/= vfs_bio.c:3414 531: cpu5 UNLOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vfs= _subr.c:2020 530: cpu15 LOCK (sleep mutex) vm object r =3D 0 at ../../../kern/vfs_bio.c:= 3413 529: cpu15 UNLOCK (sleep mutex) vm object r =3D 0 at ../../../kern/vfs_bio.= c:2295 528: cpu5 LOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vfs_s= ubr.c:1927 527: cpu15 LOCK (sleep mutex) vm object r =3D 0 at ../../../kern/vfs_bio.c:= 2239 526: cpu15 bdirty(0xc141b498) vp 0xfffff800368adad0 flags a00000a0 525: cpu15 UNLOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vf= s_bio.c:937 524: cpu5 UNLOCK (sleep mutex) UMA pcpu r =3D 0 at ../../../vm/uma_core.c:2= 283 523: cpu15 LOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vfs_= bio.c:902 522: cpu5 UNLOCK (sleep mutex) NAMEI r =3D 0 at ../../../vm/uma_core.c:2281 521: cpu5 LOCK (sleep mutex) NAMEI r =3D 0 at ../../../vm/uma_core.c:2276 520: cpu15 bdwrite(0xc141b498) vp 0xfffff800368adad0 flags a00000a0 519: cpu5 LOCK (sleep mutex) UMA pcpu r =3D 0 at ../../../vm/uma_core.c:2258 518: cpu15 UNLOCK (sleep mutex) FFS r =3D 0 at ../../../ufs/ffs/ffs_alloc.c= :1898 517: cpu5 UNLOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vfs= _subr.c:1962 516: cpu5 lockmgr(): lkp =3D=3D 0xfffff800c63e1748 (lk_wmesg =3D=3D "ufs"),= owner =3D=3D 0xfffff800d3c06000, exclusivecount =3D=3D 1, flags =3D=3D 0x6= , td =3D=3D 0xfffff800d3c06000 515: cpu15 LOCK (sleep mutex) FFS r =3D 0 at ../../../ufs/ffs/ffs_alloc.c:1= 835 514: cpu5 LOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vfs_s= ubr.c:2022 513: cpu15 getblk(0xfffff800368adad0, 59072384, 16384) =3D 0xc141b498 512: cpu5 UNLOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vfs= _subr.c:2020 511: cpu15 bremfree(0xc141b498) vp 0xfffff800368adad0 flags 200000a0 510: cpu5 LOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vfs_s= ubr.c:1927 509: cpu15 acquire(): lkp =3D=3D 0xc141b530, extflags =3D=3D 0x120, wanted = =3D=3D 0x1050000 508: cpu15 acquire(): lkp =3D=3D 0xc141b530, extflags =3D=3D 0x120, wanted = =3D=3D 0x60000 507: cpu5 acquire(): lkp =3D=3D 0xfffff800c13224b8, extflags =3D=3D 0x40, w= anted =3D=3D 0x1050000 506: cpu15 UNLOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/ke= rn_lock.c:181 505: cpu5 acquire(): lkp =3D=3D 0xfffff800c13224b8, extflags =3D=3D 0x40, w= anted =3D=3D 0x60000 504: cpu15 lockmgr(): lkp =3D=3D 0xc141b530 (lk_wmesg =3D=3D "getblk"), own= er =3D=3D 0xffffffffffffffff, exclusivecount =3D=3D 0, flags =3D=3D 0x20212= 2, td =3D=3D 0xfffff800d3c06720 503: cpu5 UNLOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/ker= n_lock.c:181 502: cpu5 lockmgr(): lkp =3D=3D 0xfffff800c13224b8 (lk_wmesg =3D=3D "ufs"),= owner =3D=3D 0xffffffffffffffff, exclusivecount =3D=3D 0, flags =3D=3D 0x2= 002, td =3D=3D 0xfffff800d3c06000 501: cpu15 LOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vfs_= bio.c:2369 500: cpu15 getblk(0xfffff800368adad0, 59072384, 16384) 499: cpu5 UNLOCK (sleep mutex) Name Cache r =3D 0 at ../../../kern/vfs_cach= e.c:450 498: cpu15 breadn(0xfffff800368adad0, 59072384, 16384) 497: cpu5 LOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vfs_c= ache.c:449 496: cpu15 lockmgr(): lkp =3D=3D 0xc146b258 (lk_wmesg =3D=3D "getblk"), own= er =3D=3D 0xfffff800d3c06720, exclusivecount =3D=3D 1, flags =3D=3D 0x6, td= =3D=3D 0xfffff800d3c06720 495: cpu5 LOCK (sleep mutex) Name Cache r =3D 0 at ../../../kern/vfs_cache.= c:354 494: cpu15 UNLOCK (sleep mutex) needsbuffer lock r =3D 0 at ../../../kern/v= fs_bio.c:314 493: cpu15 LOCK (sleep mutex) needsbuffer lock r =3D 0 at ../../../kern/vfs= _bio.c:309 492: cpu15 UNLOCK (sleep mutex) needsbuffer lock r =3D 0 at ../../../kern/v= fs_bio.c:358 491: cpu5 UNLOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vfs= _subr.c:1962 490: cpu15 LOCK (sleep mutex) needsbuffer lock r =3D 0 at ../../../kern/vfs= _bio.c:351 489: cpu5 lockmgr(): lkp =3D=3D 0xfffff800c5adc6c8 (lk_wmesg =3D=3D "ufs"),= owner =3D=3D 0xfffff800d3c06000, exclusivecount =3D=3D 1, flags =3D=3D 0x6= , td =3D=3D 0xfffff800d3c06000 488: cpu15 UNLOCK (sleep mutex) buf queue lock r =3D 0 at ../../../kern/vfs= _bio.c:1356 487: cpu5 LOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vfs_s= ubr.c:2022 486: cpu5 UNLOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vfs= _subr.c:2020 485: cpu15 bremfreel(0xc146b1c0) vp 0 flags 8002a000 484: cpu15 LOCK (sleep mutex) buf queue lock r =3D 0 at ../../../kern/vfs_b= io.c:1317 483: cpu5 LOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vfs_s= ubr.c:1927 482: cpu15 UNLOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vf= s_subr.c:1403 481: cpu15 LOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vfs_= subr.c:1390 480: cpu5 acquire(): lkp =3D=3D 0xfffff800c63e1748, extflags =3D=3D 0x40, w= anted =3D=3D 0x1050000 479: cpu5 acquire(): lkp =3D=3D 0xfffff800c63e1748, extflags =3D=3D 0x40, w= anted =3D=3D 0x60000 478: cpu15 brelvp(0xc146b1c0) vp 0xfffff800cd18d8c0 flags 8002a000 477: cpu15 UNLOCK (sleep mutex) needsbuffer lock r =3D 0 at ../../../kern/v= fs_bio.c:314 476: cpu5 UNLOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/ker= n_lock.c:181 475: cpu5 lockmgr(): lkp =3D=3D 0xfffff800c63e1748 (lk_wmesg =3D=3D "ufs"),= owner =3D=3D 0xffffffffffffffff, exclusivecount =3D=3D 0, flags =3D=3D 0x2= 002, td =3D=3D 0xfffff800d3c06000 474: cpu15 LOCK (sleep mutex) needsbuffer lock r =3D 0 at ../../../kern/vfs= _bio.c:309 473: cpu15 UNLOCK (spin mutex) ipi r =3D 0 at ./machine/smp.h:209 472: cpu5 UNLOCK (sleep mutex) Name Cache r =3D 0 at ../../../kern/vfs_cach= e.c:450 471: cpu5 LOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vfs_c= ache.c:449 470: cpu5 LOCK (sleep mutex) Name Cache r =3D 0 at ../../../kern/vfs_cache.= c:354 469: cpu5 UNLOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vfs= _subr.c:1962 468: cpu5 lockmgr(): lkp =3D=3D 0xfffff800f2aa0cf8 (lk_wmesg =3D=3D "ufs"),= owner =3D=3D 0xfffff800d3c06000, exclusivecount =3D=3D 1, flags =3D=3D 0x6= , td =3D=3D 0xfffff800d3c06000 467: cpu5 LOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vfs_s= ubr.c:2022 466: cpu5 UNLOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vfs= _subr.c:2020 465: cpu15 LOCK (spin mutex) ipi r =3D 0 at ./machine/smp.h:191 464: cpu15 UNLOCK (sleep mutex) vm page queue mutex r =3D 0 at ../../../spa= rc64/sparc64/pmap.c:975 463: cpu5 LOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vfs_s= ubr.c:1927 462: cpu15 LOCK (sleep mutex) vm page queue mutex r =3D 0 at ../../../sparc= 64/sparc64/pmap.c:969 461: cpu5 acquire(): lkp =3D=3D 0xfffff800c5adc6c8, extflags =3D=3D 0x40, w= anted =3D=3D 0x1050000 460: cpu5 acquire(): lkp =3D=3D 0xfffff800c5adc6c8, extflags =3D=3D 0x40, w= anted =3D=3D 0x60000 459: cpu15 UNLOCK (sleep mutex) vm object r =3D 0 at ../../../kern/vfs_bio.= c:1520 458: cpu5 UNLOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/ker= n_lock.c:181 457: cpu15 UNLOCK (sleep mutex) vm page queue mutex r =3D 0 at ../../../ker= n/vfs_bio.c:1519 456: cpu5 lockmgr(): lkp =3D=3D 0xfffff800c5adc6c8 (lk_wmesg =3D=3D "ufs"),= owner =3D=3D 0xffffffffffffffff, exclusivecount =3D=3D 0, flags =3D=3D 0x2= 002, td =3D=3D 0xfffff800d3c06000 455: cpu15 UNLOCK (spin mutex) vm page queue free mutex r =3D 0 at ../../..= /vm/vm_page.c:1078 454: cpu15 LOCK (spin mutex) vm page queue free mutex r =3D 0 at ../../../v= m/vm_page.c:1064 453: cpu5 UNLOCK (sleep mutex) Name Cache r =3D 0 at ../../../kern/vfs_cach= e.c:450 452: cpu5 LOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/vfs_c= ache.c:449 451: cpu5 LOCK (sleep mutex) Name Cache r =3D 0 at ../../../kern/vfs_cache.= c:354 450: cpu15 UNLOCK (spin mutex) vm page queue free mutex r =3D 0 at ../../..= /vm/vm_page.c:1078 449: cpu15 LOCK (spin mutex) vm page queue free mutex r =3D 0 at ../../../v= m/vm_page.c:1064 448: cpu5 UNLOCK (sleep mutex) vnode interlock r =3D 0 at ../../../kern/ker= n_lock.c:181 447: cpu5 lockmgr(): lkp =3D=3D 0xfffff800f278b118 (lk_wmesg =3D=3D "ufs"),= owner =3D=3D 0xfffff800d3c06000, exclusivecount =3D=3D 1, flags =3D=3D 0x2= 006, td =3D=3D 0xfffff800d3c06000 --- End of trace buffer --- db> ps pid proc uid ppid pgrp flag stat wmesg wchan cmd 3248 fffff800d6b08358 0 3247 508 0004000 [CPU 11] pkg_delete 3247 fffff800e232ca08 0 3245 508 0004000 [SLPQ wait 0xfffff800e232ca= 08][SLP] xargs 3245 fffff80046499768 0 860 508 0000000 [SLPQ wait 0xfffff800464997= 68][SLP] sh 3175 fffff800d6b08d60 0 3173 506 0004000 [CPU 8] bsdtar 3174 fffff800ea2d6358 0 3173 506 0004000 [SLPQ pipdwt 0xfffff8003f72= d110][SLP] bsdtar 3173 fffff800eaf20d60 0 2567 506 0004000 [SLPQ wait 0xfffff800eaf20d= 60][SLP] sh 2567 fffff800d1dac000 0 680 506 0004000 [SLPQ wait 0xfffff800d1dac0= 00][SLP] pkg_add 860 fffff8005f646a08 0 509 508 0004000 [SLPQ wait 0xfffff8005f646a= 08][SLP] sh 680 fffff800f59c7ac0 0 507 506 0004000 [SLPQ wait 0xfffff800f59c7a= c0][SLP] sh 509 fffff8005fc90d60 0 508 508 0004000 [SLPQ wait 0xfffff8005fc90d= 60][SLP] sh 508 fffff80060c310b8 30015 505 508 0004000 [SLPQ pause 0xfffff80060c3= 1120][SLP] tcsh 507 fffff8004f24c358 0 506 506 0004000 [SLPQ wait 0xfffff8004f24c3= 58][SLP] sh 506 fffff8005f646000 30015 504 506 0004000 [SLPQ pause 0xfffff8005f64= 6068][SLP] tcsh 505 fffff800463cc000 30015 500 500 0000100 [SLPQ select 0xc04d0720][S= LP] sshd 504 fffff80046498d60 30015 501 501 0000100 [SLPQ select 0xc04d0720][S= LP] sshd 501 fffff800f59c7410 0 390 501 0000100 [SLPQ sbwait 0xfffff800f7b3= d010][SLP] sshd 500 fffff8005b8e50b8 0 390 500 0000100 [SLPQ sbwait 0xfffff800f77f= dc68][SLP] sshd 474 fffff80037cc50b8 0 1 1 0004000 [SLPQ ttydcd 0xfffff8000170= 0000][SLP] getty 473 fffff8003e24e000 0 1 473 0004002 [SLPQ ttyin 0xfffff80001700= 810][SLP] getty 466 fffff8005f53a6b0 0 1 466 0000000 [SLPQ select 0xc04d0720][SL= P] inetd 454 fffff800464990b8 100 445 454 0004000 [SLPQ piperd 0xfffff800f7f3= cea0][SLP] unlinkd 445 fffff8005f904358 100 443 443 0004000 [SLPQ select 0xc04d0720][SL= P] squid 443 fffff8004ef83ac0 100 1 443 0000000 [SLPQ wait 0xfffff8004ef83a= c0][SLP] squid 416 fffff800f54d8000 0 1 416 0000000 [SLPQ nanslp 0xc0443850][SL= P] cron 401 fffff80060de5ac0 25 1 401 0000100 [SLPQ pause 0xfffff80060de5= b28][SLP] sendmail 395 fffff8003f7b6d60 0 1 395 0000100 [SLPQ select 0xc04d0720][SL= P] sendmail 390 fffff8005ff9a358 0 1 390 0000100 [SLPQ select 0xc04d0720][SL= P] sshd 377 fffff8005b76c358 0 1 377 0000000 [SLPQ select 0xc04d0720][SL= P] ntpd 272 fffff80060c30d60 0 1 272 0000000 [SLPQ select 0xc04d0720][SL= P] syslogd 251 fffff8003d4f6d60 0 1 251 0000000 [SLPQ select 0xc04d0720][SL= P] devd 46 fffff8013e433410 0 0 0 0000204 [SLPQ - 0xeea9f6cc][SLP] sc= hedcpu 45 fffff8013e433768 0 0 0 0000204 [SLPQ - 0xc04da7c0][SLP] nf= siod 3 44 fffff8013e433ac0 0 0 0 0000204 [SLPQ - 0xc04da7b8][SLP] nf= siod 2 43 fffff80138696000 0 0 0 0000204 [SLPQ - 0xc04da7b0][SLP] nf= siod 1 42 fffff80138696358 0 0 0 0000204 [SLPQ - 0xc04da7a8][SLP] nf= siod 0 41 fffff801386966b0 0 0 0 0000204 [SLPQ vlruwt 0xfffff8013869= 66b0][SLP] vnlru 40 fffff80138696a08 0 0 0 0000204 [SLPQ syncer 0xc0443488][SL= P] syncer 39 fffff80138696d60 0 0 0 0000204 [SLPQ psleep 0xc04d0f5c][SL= P] bufdaemon 9 fffff801386970b8 0 0 0 000020c [SLPQ pgzero 0xc04e2fd8][SL= P] pagezero 8 fffff80138697410 0 0 0 0000204 [SLPQ psleep 0xc04e26ac][SL= P] vmdaemon 7 fffff80138697768 0 0 0 0000204 [SLPQ psleep 0xc04e2694][SL= P] pagedaemon 38 fffff80138697ac0 0 0 0 0000204 [IWAIT] vec219: esp0 37 fffff8013869a000 0 0 0 0000204 [IWAIT] vec220: hme0 36 fffff8013e42aa08 0 0 0 0000204 [IWAIT] vec229: sbus1 35 fffff8013e42ad60 0 0 0 0000204 [IWAIT] vec234: sbus1 34 fffff8013e42b0b8 0 0 0 0000204 [IWAIT] vec165: sbus0 33 fffff8013e42b410 0 0 0 0000204 [IWAIT] vec170: sbus0 32 fffff8013e42b768 0 0 0 0000204 [IWAIT] swi0: uart uart++ 31 fffff8013e42bac0 0 0 0 0000204 [RUNQ] vec185: puc0 puc1 30 fffff8013e432000 0 0 0 0000204 [IWAIT] swi6: task queue 29 fffff8013e432358 0 0 0 0000204 [IWAIT] swi2: cambio 6 fffff8013e4326b0 0 0 0 0000204 [SLPQ - 0xfffff8000142c400]= [SLP] kqueue taskq 28 fffff8013e432a08 0 0 0 0000204 [IWAIT] swi5:+ 5 fffff8013e432d60 0 0 0 0000204 [SLPQ - 0xfffff8000142c700]= [SLP] thread taskq 27 fffff8013e4330b8 0 0 0 0000204 [IWAIT] swi6:+ 26 fffff8013e712358 0 0 0 0000204 [SLPQ - 0xc0411e68][SLP] ya= rrow 4 fffff8013e7126b0 0 0 0 0000204 [SLPQ - 0xc04160d0][SLP] g_= down 3 fffff8013e712a08 0 0 0 0000204 [SLPQ - 0xc04160c8][SLP] g_= up 2 fffff8013e712d60 0 0 0 0000204 [SLPQ - 0xc04160b8][SLP] g_= event 25 fffff8013e7130b8 0 0 0 0000204 [IWAIT] swi3: vm 24 fffff8013e713410 0 0 0 000020c [RUNQ] swi4: clock 23 fffff8013e713768 0 0 0 0000204 [IWAIT] swi1: net 22 fffff8013e713ac0 0 0 0 000020c [CPU 0] idle: cpu0 21 fffff8013e42a000 0 0 0 000020c [CPU 1] idle: cpu1 20 fffff8013e42a358 0 0 0 000020c [CPU 2] idle: cpu2 19 fffff8013e42a6b0 0 0 0 000020c [CPU 3] idle: cpu3 18 fffff8013e746000 0 0 0 000020c [CPU 4] idle: cpu4 17 fffff8013e746358 0 0 0 000020c [CPU 5] idle: cpu5 16 fffff8013e7466b0 0 0 0 000020c [CPU 6] idle: cpu6 15 fffff8013e746a08 0 0 0 000020c [CPU 7] idle: cpu7 14 fffff8013e746d60 0 0 0 000020c [Can run] idle: cpu8 13 fffff8013e7470b8 0 0 0 000020c [CPU 9] idle: cpu9 12 fffff8013e747410 0 0 0 000020c [CPU 10] idle: cpu10 11 fffff8013e747768 0 0 0 000020c [Can run] idle: cpu11 1 fffff8013e747ac0 0 0 1 0004200 [SLPQ wait 0xfffff8013e747a= c0][SLP] init 10 fffff8013e712000 0 0 0 0000204 [SLPQ ktrace 0xc042b238][SL= P] ktrace 0 c0416210 0 0 0 0000200 [SLPQ sched 0xc0416210][SLP] swapper db> wh 3248 Tracing pid 3248 tid 100325 td 0xfffff800d3c06720 mi_switch() at mi_switch+0x3d4 Analysis from gdb: #11 0x00000000c0291524 in ffs_valloc (pvp=3D0x0, mode=3D3697846, cred=3D0x2= , vpp=3D0xf7c2cd58) at ../../../ufs/ffs/ffs_alloc.c:929 #12 0x00000000c02914f0 in ffs_valloc (pvp=3D0xfffff800c1322420, mode=3D3318= 8, cred=3D0xfffff80022d51400, vpp=3D0x0) at ../../../ufs/ffs/ffs_alloc.c:924 #13 0x00000000c02b68fc in ufs_makeinode (mode=3D33188, dvp=3D0xfffff800c132= 2420, vpp=3D0xf7c2d488, cnp=3D0xf7c2d4b0) at ../../../ufs/ufs/ufs_vnops.c:2177 #14 0x00000000c02b3674 in ufs_create (ap=3D0xf7c2d110) at ../../../ufs/ufs/= ufs_vnops.c:177 #15 0x00000000c02f7a54 in VOP_CREATE_APV (vop=3D0xc0405380, a=3D0xf7c2d110)= at vnode_if.c:206 #16 0x00000000c01e2808 in vn_open_cred (ndp=3D0xf7c2d460, flagp=3D0xf7c2d67= 8, cmode=3D420, cred=3D0xfffff80022d51400, fdidx=3D3) at vnode_if.h:111 #17 0x00000000c01e2658 in vn_open (ndp=3D0xf7c2d460, flagp=3D0xf7c2d678, cm= ode=3D420, fdidx=3D3) at ../../../kern/vfs_vnops.c:91 #18 0x00000000c01dbcec in kern_open (td=3D0xfffff800d3c06000, path=3D---Can= 't read userspace from dump, or kernel process--- (kgdb) frame 11 #11 0x00000000c0291524 in ffs_valloc (pvp=3D0x0, mode=3D3697846, cred=3D0x2= , vpp=3D0xf7c2cd58) at ../../../ufs/ffs/ffs_alloc.c:929 929 ip =3D VTOI(*vpp); (kgdb) print **vpp $2 =3D {v_type =3D VBAD, v_tag =3D 0xc0395510 "none", v_op =3D 0xc03df680, = v_data =3D 0x0, v_mount =3D 0x0, v_nmntvnodes =3D { tqe_next =3D 0xfffff800cdd9d6b0, tqe_prev =3D 0xfffff800ce000238}, v_un= =3D {vu_mount =3D 0x0, vu_socket =3D 0x0, vu_cdev =3D 0x0, vu_fifoinfo =3D 0x0}, v_hashlist =3D {le_next =3D 0x0,= le_prev =3D 0x100047ec0}, v_hash =3D 3697846, v_cache_src =3D {lh_first =3D 0x0}, v_cache_dst =3D {tqh_first =3D 0x0, t= qh_last =3D 0xfffff800cd18d920}, v_dd =3D 0x0, v_cstart =3D 0, v_lasta =3D 0, v_lastw =3D 0, v_clen =3D 0, v_lock =3D {l= k_interlock =3D 0xc042d360, lk_flags =3D 262208, lk_sharecount =3D 0, lk_waitcount =3D 0, lk_exclusivecount =3D 1, lk_pr= io =3D 80, lk_wmesg =3D 0xc03ace70 "ufs", lk_timo =3D 51, lk_lockholder =3D 0xfffff800d3c06000, lk_newlock =3D 0x= 0}, v_interlock =3D {mtx_object =3D { lo_class =3D 0xc03ea418, lo_name =3D 0xc03a6c68 "vnode interlock", lo= _type =3D 0xc03a6c68 "vnode interlock", lo_flags =3D 196608, lo_list =3D {tqe_next =3D 0xfffff800cdd9d780, tq= e_prev =3D 0xfffff800cdcc5170}, lo_witness =3D 0x0}, mtx_lock =3D 4, mtx_recurse =3D 0, mtx_acqtime = =3D 0, mtx_filename =3D 0xc03ad870 "../../../kern/vfs_subr.c", mtx_lineno =3D = 1819, mtx_contest_holding =3D 0, mtx_contest_locking =3D 2}, v_vnlock =3D 0xfffff800cd18d958, v_holdcnt = =3D 1, v_usecount =3D 1, v_iflag =3D 0, v_vflag =3D 4, v_writecount =3D 0, v_freelist =3D {tqe_next =3D 0xfffff80= 0ce000420, tqe_prev =3D 0xc04d1548}, v_bufobj =3D {bo_mtx =3D 0xfffff800cd18d990, bo_clean =3D {bv_hd =3D {tqh= _first =3D 0x0, tqh_last =3D 0xfffff800cd18da38}, bv_root =3D 0x0, bv_cnt =3D 0}, b= o_dirty =3D {bv_hd =3D {tqh_first =3D 0x0, tqh_last =3D 0xfffff800cd18da58}, bv_root =3D 0x0, bv_cnt =3D 0}, b= o_numoutput =3D 0, bo_flag =3D 0, bo_ops =3D 0xc03f4850, bo_bsize =3D 16384, bo_object =3D 0x0, bo_syncli= st =3D {le_next =3D 0x0, le_prev =3D 0xfffff800cd18d890}, bo_private =3D 0xfffff800cd18d8c0, _= _bo_vnode =3D 0xfffff800cd18d8c0}, v_pollinfo =3D 0x0, v_label =3D 0x0} (kgdb) frame 12 #12 0x00000000c02914f0 in ffs_valloc (pvp=3D0xfffff800c1322420, mode=3D3318= 8, cred=3D0xfffff80022d51400, vpp=3D0x0) at ../../../ufs/ffs/ffs_alloc.c:924 924 error =3D ffs_vget(pvp->v_mount, ino, LK_EXCLUSIVE, vpp); (kgdb) print *pvp->v_mount $4 =3D {mnt_list =3D {tqe_next =3D 0xfffff8001c8d1400, tqe_prev =3D 0xfffff= 8001ffcec00}, mnt_op =3D 0xc0404588, mnt_vfc =3D 0xc0404600, mnt_vnodecovered =3D 0xfffff80044984e70, mnt_sync= er =3D 0xfffff800384f74a0, mnt_nvnodelist =3D {tqh_first =3D 0xfffff80044900e70, tqh_last =3D 0xffff= f800bc15e658}, mnt_lock =3D { lk_interlock =3D 0xc042b9c8, lk_flags =3D 0, lk_sharecount =3D 0, lk_wa= itcount =3D 0, lk_exclusivecount =3D 0, lk_prio =3D 80, lk_wmesg =3D 0xc03ad240 "vfslock", lk_timo =3D 0, lk_lo= ckholder =3D 0xffffffffffffffff, lk_newlock =3D 0x0}, mnt_mtx =3D {mtx_object =3D {lo_class =3D 0xc03ea4= 18, lo_name =3D 0xc03ad228 "struct mount mtx", lo_type =3D 0xc03ad228 "struct mount mtx", lo_flags =3D 196608, lo_li= st =3D {tqe_next =3D 0xfffff8001d0b04a0, tqe_prev =3D 0xfffff80038575dd0}, lo_witness =3D 0x0}, mtx_lock =3D= 4, mtx_recurse =3D 0, mtx_acqtime =3D 0, mtx_filename =3D 0xc03ae1a0 "../../../kern/vfs_vnops.c", mtx_lineno =3D= 949, mtx_contest_holding =3D 0, mtx_contest_locking =3D 704}, mnt_writeopcount =3D 1, mnt_flag =3D 4096= , mnt_opt =3D 0xfffff800019e4240, mnt_optnew =3D 0x0, mnt_kern_flag =3D 536870912, mnt_maxsymlinklen =3D 12= 0, mnt_stat =3D {f_version =3D 537068824, f_type =3D 4, f_flags =3D 4096, f_bsize =3D 2048, f_iosize =3D 16384, f= _blocks =3D 25833109, f_bfree =3D 24054101, f_bavail =3D 21987453, f_files =3D 6688766, f_ffree =3D 6175722, f_sync= writes =3D 0, f_asyncwrites =3D 0, f_syncreads =3D 0, f_asyncreads =3D 0, f_spare =3D {0, 0, 0, 0, 0, 0, 0= , 0, 0, 0}, f_namemax =3D 255, f_owner =3D 0, f_fsid =3D {val =3D {1114482418, -542806556}}, f_charspare =3D '\0' , f_fstypename =3D "ufs", '\0' , f_mntfromname =3D "/de= v/stripe/data", '\0' , f_mntonname =3D "/data", '\0' }, mnt_cred =3D 0xfffff= 80022d92b00, mnt_data =3D 0xfffff8001d0b0400, mnt_time =3D 0, mnt_iosize_max =3D 13107= 2, mnt_export =3D 0x0, mnt_mntlabel =3D 0x0, mnt_fslabel =3D 0x0, mnt_nvnodelistsize =3D 16322, mnt_hashseed =3D 21339= 73794} (kgdb) print ino $5 =3D 3697846 (kgdb) print vpp $6 =3D (struct vnode **) 0x0 (kgdb) frame 13 #13 0x00000000c02b68fc in ufs_makeinode (mode=3D33188, dvp=3D0xfffff800c132= 2420, vpp=3D0xf7c2d488, cnp=3D0xf7c2d4b0) at ../../../ufs/ufs/ufs_vnops.c:2177 2177 error =3D UFS_VALLOC(dvp, mode, cnp->cn_cred, &tvp); (kgdb) print *dvp $7 =3D {v_type =3D VDIR, v_tag =3D 0xc03ace70 "ufs", v_op =3D 0xc0404ac8, v= _data =3D 0xfffff800ed723a40, v_mount =3D 0xfffff800019c0000, v_nmntvnodes =3D {tqe_next =3D 0xfffff800= be3d16b0, tqe_prev =3D 0xfffff800bfb0d8e8}, v_un =3D {vu_mount =3D 0x0, vu_socket =3D 0x0, vu_cdev =3D 0x0, vu_fifoin= fo =3D 0x0}, v_hashlist =3D {le_next =3D 0x0, le_prev =3D 0x10004a5c0}, v_hash =3D 3699094, v_cache_src =3D {lh_first= =3D 0xfffff800efb8ee38}, v_cache_dst =3D { tqh_first =3D 0xfffff800ee5ec138, tqh_last =3D 0xfffff800ee5ec158}, v_d= d =3D 0xfffff800c63e16b0, v_cstart =3D 0, v_lasta =3D 0, v_lastw =3D 0, v_clen =3D 0, v_lock =3D {lk_interlock =3D = 0xc042ddf0, lk_flags =3D 262208, lk_sharecount =3D 0, lk_waitcount =3D 0, lk_exclusivecount =3D 1, lk_pr= io =3D 80, lk_wmesg =3D 0xc03ace70 "ufs", lk_timo =3D 51, lk_lockholder =3D 0xfffff800d3c06000, lk_newlock =3D 0x= 0}, v_interlock =3D {mtx_object =3D { lo_class =3D 0xc03ea418, lo_name =3D 0xc03a6c68 "vnode interlock", lo= _type =3D 0xc03a6c68 "vnode interlock", lo_flags =3D 196608, lo_list =3D {tqe_next =3D 0xfffff800be3d1780, tq= e_prev =3D 0xfffff800bfb0d9b0}, lo_witness =3D 0x0}, mtx_lock =3D 4, mtx_recurse =3D 0, mtx_acqtime = =3D 0, mtx_filename =3D 0xc03ab900 "../../../kern/vfs_bio.c", mtx_lineno =3D 2= 369, mtx_contest_holding =3D 0, mtx_contest_locking =3D 0}, v_vnlock =3D 0xfffff800c13224b8, v_holdcnt = =3D 3, v_usecount =3D 1, v_iflag =3D 0, v_vflag =3D 0, v_writecount =3D 0, v_freelist =3D {tqe_next =3D 0x0, tqe_= prev =3D 0x0}, v_bufobj =3D { bo_mtx =3D 0xfffff800c13224f0, bo_clean =3D {bv_hd =3D {tqh_first =3D 0= xc144a448, tqh_last =3D 0xc144a498}, bv_root =3D 0xc144a448, bv_cnt =3D 1}, bo_dirty =3D {bv_hd =3D {tqh_f= irst =3D 0x0, tqh_last =3D 0xfffff800c13225b8}, bv_root =3D 0x0, bv_cnt =3D 0}, bo_numoutput =3D 0, bo_flag =3D 0, bo= _ops =3D 0xc03f4850, bo_bsize =3D 16384, bo_object =3D 0x0, bo_synclist =3D {le_next =3D 0x0, le_prev =3D 0x0}, = bo_private =3D 0xfffff800c1322420, __bo_vnode =3D 0xfffff800c1322420}, v_pollinfo =3D 0x0, v_label =3D 0x0} (kgdb) print mode $8 =3D 33188 (kgdb) print *cnp->cn_cred $9 =3D {cr_ref =3D 20, cr_uid =3D 0, cr_ruid =3D 0, cr_svuid =3D 0, cr_ngro= ups =3D 3, cr_groups =3D {0, 0, 5, 0 }, cr_rgid =3D 0, cr_svgid =3D 0, cr_uidinfo =3D 0x= fffff800014231c0, cr_ruidinfo =3D 0xfffff800014231c0, cr_prison =3D 0x0, cr_label =3D 0x0, = cr_mtxp =3D 0xffff2f98} (kgdb) print *tvp $11 =3D {v_type =3D VBAD, v_tag =3D 0xc0395510 "none", v_op =3D 0xc03df680,= v_data =3D 0x0, v_mount =3D 0x0, v_nmntvnodes =3D {tqe_next =3D 0xfffff800cdd9d6b0, tqe_prev =3D 0xfffff80= 0ce000238}, v_un =3D {vu_mount =3D 0x0, vu_socket =3D 0x0, vu_cdev =3D 0x0, vu_fifoinfo =3D 0x0}, v_hashlist = =3D {le_next =3D 0x0, le_prev =3D 0x100047ec0}, v_hash =3D 3697846, v_cache_src =3D {lh_first =3D 0x0}, v_cache_dst =3D {= tqh_first =3D 0x0, tqh_last =3D 0xfffff800cd18d920}, v_dd =3D 0x0, v_cstart =3D 0, v_lasta= =3D 0, v_lastw =3D 0, v_clen =3D 0, v_lock =3D { lk_interlock =3D 0xc042d360, lk_flags =3D 262208, lk_sharecount =3D 0, = lk_waitcount =3D 0, lk_exclusivecount =3D 1, lk_prio =3D 80, lk_wmesg =3D 0xc03ace70 "ufs", lk_timo =3D 51, lk_lockh= older =3D 0xfffff800d3c06000, lk_newlock =3D 0x0}, v_interlock =3D {mtx_object =3D {lo_class =3D 0xc0= 3ea418, lo_name =3D 0xc03a6c68 "vnode interlock", lo_type =3D 0xc03a6c68 "vno= de interlock", lo_flags =3D 196608, lo_list =3D {tqe_next =3D 0xfffff800cdd9d780, tqe_prev =3D 0xfffff800= cdcc5170}, lo_witness =3D 0x0}, mtx_lock =3D 4, mtx_recurse =3D 0, mtx_acqtime =3D 0, mtx_filename =3D = 0xc03ad870 "../../../kern/vfs_subr.c", mtx_lineno =3D 1819, mtx_contest_holding =3D 0, mtx_contest_locking =3D= 2}, v_vnlock =3D 0xfffff800cd18d958, v_holdcnt =3D 1, v_usecount =3D 1, v_iflag =3D 0, v_vflag =3D 4, v_writec= ount =3D 0, v_freelist =3D { tqe_next =3D 0xfffff800ce000420, tqe_prev =3D 0xc04d1548}, v_bufobj =3D= {bo_mtx =3D 0xfffff800cd18d990, bo_clean =3D { bv_hd =3D {tqh_first =3D 0x0, tqh_last =3D 0xfffff800cd18da38}, bv_ro= ot =3D 0x0, bv_cnt =3D 0}, bo_dirty =3D { bv_hd =3D {tqh_first =3D 0x0, tqh_last =3D 0xfffff800cd18da58}, bv_ro= ot =3D 0x0, bv_cnt =3D 0}, bo_numoutput =3D 0, bo_flag =3D 0, bo_ops =3D 0xc03f4850, bo_bsize =3D 16384, bo_object =3D= 0x0, bo_synclist =3D {le_next =3D 0x0, le_prev =3D 0xfffff800cd18d890}, bo_private =3D 0xfffff800cd18d8c0, _= _bo_vnode =3D 0xfffff800cd18d8c0}, v_pollinfo =3D 0x0, v_label =3D 0x0} (kgdb) --qMm9M+Fa2AknHoGS Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD4DBQFCcTvjWry0BWjoQKURAvQpAKCYQML6HSGq54fFy4BWPQvUrIHgjwCXQcs6 ygJ2VIZG4evTiPBfBgt/YQ== =sI5F -----END PGP SIGNATURE----- --qMm9M+Fa2AknHoGS-- From owner-freebsd-current@FreeBSD.ORG Thu Apr 28 19:44: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 5BACE16A4CE for ; Thu, 28 Apr 2005 19:44:49 +0000 (GMT) Received: from fast.dnswatch.com (fast.dnswatch.com [216.177.243.43]) by mx1.FreeBSD.org (Postfix) with ESMTP id AD7EF43D41 for ; Thu, 28 Apr 2005 19:44:48 +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 j3SJiirt008410; Thu, 28 Apr 2005 12:44:47 -0700 (PDT) (envelope-from null@dnswatch.com) Received: (from www@localhost) by fast.dnswatch.com (8.12.6/8.12.6/Submit) id j3SJihBQ008409; Thu, 28 Apr 2005 12:44:43 -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; Thu, 28 Apr 2005 12:44:42 -0700 (PDT) Message-ID: <54623.216.177.243.35.1114717482.localmail@webmail.dnswatch.com> In-Reply-To: <20050428082931.GA232@cirb503493.alcatel.com.au> References: <61364.216.177.243.42.1114593685.localmail@webmail.dnswatch.com> <84dead7205042706554f32484@mail.gmail.com> <57775.216.177.243.35.1114633009.localmail@webmail.dnswatch.com> <20050427204939.GA796@uk.tiscali.com> <53015.216.177.243.35.1114635611.localmail@webmail.dnswatch.com> <20050427212835.GA87673@uk.tiscali.com> <64018.216.177.243.35.1114641057.localmail@webmail.dnswatch.com> <42701D35.6020307@gmail.com> <42703671.8060707@attglobal.net> <59642.216.177.243.35.1114655240.localmail@webmail.dnswatch.com> <20050428082931.GA232@cirb503493.alcatel.com.au> Date: Thu, 28 Apr 2005 12:44:42 -0700 (PDT) From: "/dev/null" To: "Peter Jeremy" 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 cc: freebsd-current@freebsd.org Subject: Re: can't build kernel [with CONFIG this time][[[FIXED]]] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 28 Apr 2005 19:44:49 -0000 > On Wed, 2005-Apr-27 19:27:20 -0700, /dev/null wrote: >>In my case I think it was just "sync" issues between the CPU cache and >>the RAM. Although it could have been just that this processor drove >>the RAM stick hard enough to make it fail. No matter, the stick of RAM is >>working flawlessly in a different box. :) > > Modern hardware is pushed very close to the limits. Maybe the RAM has > some pattern sensitivity that just happens to be hit by buildkernel or > buildworld. Maybe a combination of marginal bypass capacitors, > marginal memory bus drivers means that the logic transition is a few > picoseconds longer than desirable if a large number of bits change > state simultaneously so that the transition isn't seen by the marginal > receiver. > Good point(s). I sure wish I could just use 1 giant can capacitor that simply fills as required and releases as necessary. It would be so much simpler. On a sad note, after a long period of usage it still fails. So it seems that the new CPU is the culprit (CPU's cache?). Anyway, I might disable the CPU's cache in the bios settings and see what happens, while I wait for another CPU. Best wishes, Chris > -- > Peter Jeremy > //////////////////////////////////////////////////// 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 Thu Apr 28 20:29: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 ED35C16A4CE for ; Thu, 28 Apr 2005 20:29:06 +0000 (GMT) Received: from fast.dnswatch.com (fast.dnswatch.com [216.177.243.43]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3190D43D55 for ; Thu, 28 Apr 2005 20:29:06 +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 j3SKT1rt008713; Thu, 28 Apr 2005 13:29:05 -0700 (PDT) (envelope-from null@dnswatch.com) Received: (from www@localhost) by fast.dnswatch.com (8.12.6/8.12.6/Submit) id j3SKT0lv008712; Thu, 28 Apr 2005 13:29:00 -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; Thu, 28 Apr 2005 13:28:59 -0700 (PDT) Message-ID: <53801.216.177.243.35.1114720139.localmail@webmail.dnswatch.com> In-Reply-To: <20050428115258.rpvu466t68so80w4@netchild.homeip.net> References: <57436.216.177.243.42.1114582155.localmail@webmail.dnswatch.com><426FDE69.8090909@samsco.org> <426FE1EA.7020900@kutulu.org><20050427212637.GL98718@over-yonder.net> <20050428115258.rpvu466t68so80w4@netchild.homeip.net> Date: Thu, 28 Apr 2005 13:28:59 -0700 (PDT) From: "/dev/null" To: "Alexander Leidinger" 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 cc: freebsd-current@freebsd.org Subject: Re: boot banner project X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 28 Apr 2005 20:29:07 -0000 > "Matthew D. Fuller" wrote: > >>> Mounting File Systems ... [ok] >>> Starting xl0 ... [ok] >> >> This is something I've always found somewhat ironic, actually. I'm >> not really sure overall whether I like it or not, but it IS very >> structured and consistent. The irony is that I find the Linux kernel >> bootup messages to be an insane mishmash that I can never sort >> ANYTHING out of, relative to FreeBSD's very neat and structured kernel >> probes. So maybe an OS is only allowed to be neat in one of the two >> 8-} > > I think restructuring our userland boot message would be a good start. I'm > not talking about the above proposal, even if I think it's nice (but a > little bit too terse for me), I'm talking about rethinking the actual > (since > the new rc system) clutter. > > The 4.x startup looks structured (it could be improved to be more eye > friendly, but the beauty lies in the eye of the beholder), while the 5+ > one > is neither fish nor meat. It's a mixture of the 4.x one with the "Starting > xyz" messages from the new system. Since we don't try to keep the new > system > diff friendly with the NetBSD source anymore, I think we could change it > to > fit our needs. Maybe this would be a better place for me to start (assuming no objection(s)). I mean, it may turn out the large majority of opinion is: boot-banner SUX! So in either case; making what already exists more desirable/ funcional; seems the best place to start something. As opposed to adding to something that might me better polished up. What's more, I was thinking; what if the current settings ( verbose/ terse ) were expanded and prettified(stylized). Example: 3 settings; 1) no output: black, or blank screen until the prompt/ login. 2) terse: a) only dumps warnings b) dumps item at succesful load, or else failure message as returned by failed object. 3) verbose: a) raw (pretty much the way it is now but unify/ sanitize the messages returned - (4.x ify?)) b) prettified (example(s): mysql or mysql ) both or *could* be colorized. Anyway, it seems like this would be an opprotunity to unify/ bring the current proccess up to date _and_ provide for a manner of display that has something for everybody. Am I crazy? Probably, but that's not the real question here. ;) -Chris > > Bye, > Alexander. > > -- > http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 > http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 > Big book, big bore. > -- Callimachus > > > _______________________________________________ > 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 Thu Apr 28 20:43: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 8B0C116A4CE; Thu, 28 Apr 2005 20:43:20 +0000 (GMT) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 03E1243D3F; Thu, 28 Apr 2005 20:43:20 +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 j3SKhJba046609; Thu, 28 Apr 2005 16:43:19 -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 j3SKhJID009736; Thu, 28 Apr 2005 16:43:19 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 699657306E; Thu, 28 Apr 2005 16:43:18 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050428204318.699657306E@freebsd-current.sentex.ca> Date: Thu, 28 Apr 2005 16:43:18 -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 alpha/alpha 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, 28 Apr 2005 20:43:20 -0000 TB --- 2005-04-28 19:15:01 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-04-28 19:15:01 - starting CURRENT tinderbox run for alpha/alpha TB --- 2005-04-28 19:15:01 - checking out the source tree TB --- 2005-04-28 19:15:01 - cd /home/tinderbox/CURRENT/alpha/alpha TB --- 2005-04-28 19:15:01 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-04-28 19:22:00 - building world (CFLAGS=-O2 -pipe) TB --- 2005-04-28 19:22:00 - cd /home/tinderbox/CURRENT/alpha/alpha/src TB --- 2005-04-28 19:22:00 - /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-28 20:29:05 - building generic kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-04-28 20:29:05 - cd /home/tinderbox/CURRENT/alpha/alpha/src TB --- 2005-04-28 20:29:05 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Thu Apr 28 20:29:05 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 28 20:42:52 UTC 2005 TB --- 2005-04-28 20:42:52 - generating LINT kernel config TB --- 2005-04-28 20:42:52 - cd /home/tinderbox/CURRENT/alpha/alpha/src/sys/alpha/conf TB --- 2005-04-28 20:42:52 - /usr/bin/make -B LINT TB --- 2005-04-28 20:42:52 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-04-28 20:42:52 - cd /home/tinderbox/CURRENT/alpha/alpha/src TB --- 2005-04-28 20:42:52 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Apr 28 20:42:52 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 [...] rpcgen -h -C /tinderbox/CURRENT/alpha/alpha/src/sys/netatm/spans/spans_xdr.x | grep -v rpc/rpc.h > spans_xdr.h rpcgen -c -C /tinderbox/CURRENT/alpha/alpha/src/sys/netatm/spans/spans_xdr.x | grep -v rpc/rpc.h > spans_xdr.c cc -O2 -pipe -fno-strict-aliasing -mcpu=ev4 -mtune=ev5 -mieee -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/CURRENT/alpha/alpha/src/sys -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/altq -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/pf -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/ngatm -I/tinderbox/CURRENT/alpha/alpha/src/sys/dev/twa -D_KERNEL -include opt_global.h -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -c /tinderbox/CURRENT/alpha/alpha/src/sys/alpha/linux/linux_genassym.c sh /tinderbox/CURRENT/alpha/alpha/src/sys/kern/genassym.sh linux_genassym.o > linux_assym.h uudecode < /usr/share/syscons/fonts/cp850-8x16.fnt && file2c 'static u_char dflt_font_16[16*256] = {' '};' < cp850-8x16 > font.h && uudecode < /usr/share/syscons/fonts/cp850-8x14.fnt && file2c 'static u_char dflt_font_14[14*256] = {' '};' < cp850-8x14 >> font.h && uudecode < /usr/share/syscons/fonts/cp850-8x8.fnt && file2c 'static u_char dflt_font_8[8*256] = {' '};' < cp850-8x8 >> font.h /usr/sbin/kbdcontrol -L jp.106 | sed -e 's/^static keymap_t.* = /static keymap_t key_map = /' -e 's/^static accentmap_t.* = /static accentmap_t accent_map = /' > atkbdmap.h /usr/sbin/kbdcontrol -L it.iso | sed -e 's/^static keymap_t.* = /static keymap_t key_map = /' -e 's/^static accentmap_t.* = /static accentmap_t accent_map = /' > ukbdmap.h make: don't know how to make /tinderbox/CURRENT/alpha/alpha/src/sys/hwpmc/hwpmc_mod.c. Stop *** Error code 2 Stop in /tinderbox/CURRENT/alpha/alpha/src. *** Error code 1 Stop in /tinderbox/CURRENT/alpha/alpha/src. TB --- 2005-04-28 20:43:18 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-04-28 20:43:18 - ERROR: failed to build lint kernel TB --- 2005-04-28 20:43:18 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Thu Apr 28 21:08: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 E5A2216A4CE for ; Thu, 28 Apr 2005 21:08:11 +0000 (GMT) Received: from fast.dnswatch.com (fast.dnswatch.com [216.177.243.43]) by mx1.FreeBSD.org (Postfix) with ESMTP id 79BBC43D2F for ; Thu, 28 Apr 2005 21:08:11 +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 j3SL83rt009567; Thu, 28 Apr 2005 14:08:11 -0700 (PDT) (envelope-from null@dnswatch.com) Received: (from www@localhost) by fast.dnswatch.com (8.12.6/8.12.6/Submit) id j3SL82XE009566; Thu, 28 Apr 2005 14:08:02 -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; Thu, 28 Apr 2005 14:08:00 -0700 (PDT) Message-ID: <61359.216.177.243.35.1114722481.localmail@webmail.dnswatch.com> In-Reply-To: References: <57436.216.177.243.42.1114582155.localmail@webmail.dnswatch.com> <6.1.0.6.2.20050426233321.084e9210@cobalt.antimatter.net> <51899.216.177.243.42.1114584317.localmail@webmail.dnswatch.com> <6.1.0.6.2.20050427001118.0327cd50@cobalt.antimatter.net> <52515.216.177.243.42.1114586501.localmail@webmail.dnswatch.com> Date: Thu, 28 Apr 2005 14:08:00 -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 cc: John Sconiers Subject: Re: boot banner project X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 28 Apr 2005 21:08:12 -0000 Hello, As this is an RFC (I'm sure you already know that). Long answer: I'm not quite sure. It will depend on the amount and content of the comments. Technically, it may not start ever (because everyone/ or nearly everyone says it SUX). Short answer: Too early for me to say. _Chris > When are you starting the project? > > //////////////////////////////////////////////////// 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 Thu Apr 28 21:19: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 A23F216A4CE for ; Thu, 28 Apr 2005 21:19:47 +0000 (GMT) Received: from tinker.exit.com (tinker.exit.com [206.223.0.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5C46043D4C for ; Thu, 28 Apr 2005 21:19:47 +0000 (GMT) (envelope-from frank@exit.com) Received: from realtime.exit.com (realtime [206.223.0.5]) by tinker.exit.com (8.13.3/8.13.3) with ESMTP id j3SLJTcg054637; Thu, 28 Apr 2005 14:19:29 -0700 (PDT) (envelope-from frank@exit.com) Received: from realtime.exit.com (localhost [127.0.0.1]) by realtime.exit.com (8.13.3/8.13.3) with ESMTP id j3SLJS0q048320; Thu, 28 Apr 2005 14:19:28 -0700 (PDT) (envelope-from frank@realtime.exit.com) Received: (from frank@localhost) by realtime.exit.com (8.13.3/8.12.9/Submit) id j3SLJSlw048319; Thu, 28 Apr 2005 14:19:28 -0700 (PDT) (envelope-from frank) From: Frank Mayhar Message-Id: <200504282119.j3SLJSlw048319@realtime.exit.com> In-Reply-To: <61359.216.177.243.35.1114722481.localmail@webmail.dnswatch.com> To: "/dev/null" Date: Thu, 28 Apr 2005 14:19:28 -0700 (PDT) X-Copyright0: Copyright 2005 Frank Mayhar. All Rights Reserved. X-Copyright1: Permission granted for electronic reproduction as Usenet News or email only. X-Mailer: ELM [version 2.4ME+ PL119 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII cc: freebsd-current@freebsd.org cc: John Sconiers Subject: Re: boot banner project X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: frank@exit.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2005 21:19:47 -0000 "Beige. I'll paint the bikeshed beige." -- Frank Mayhar frank@exit.com http://www.exit.com/ Exit Consulting http://www.gpsclock.com/ http://www.exit.com/blog/frank/ From owner-freebsd-current@FreeBSD.ORG Thu Apr 28 21:38: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 935D916A4CE; Thu, 28 Apr 2005 21:38:34 +0000 (GMT) Received: from pi.codefab.com (pi.codefab.com [199.103.21.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5DEA143D5F; Thu, 28 Apr 2005 21:38:34 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from localhost (localhost [127.0.0.1]) by pi.codefab.com (Postfix) with ESMTP id D61955E88; Thu, 28 Apr 2005 17:38:33 -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 64204-06; Thu, 28 Apr 2005 17:38:33 -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 E92455C32; Thu, 28 Apr 2005 17:38:32 -0400 (EDT) Message-ID: <427157B7.6040203@mac.com> Date: Thu, 28 Apr 2005 17:37:59 -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.7) Gecko/20050414 X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?= References: <200504262010.49509@harrymail> <86k6mo0xmh.fsf@xps.des.no> In-Reply-To: <86k6mo0xmh.fsf@xps.des.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: amavisd-new at codefab.com cc: Emanuel Strobl cc: freebsd-current@freebsd.org cc: freebsd-questions@freebsd.org Subject: Re: groff alternative? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 28 Apr 2005 21:38:34 -0000 Dag-Erling Smørgrav wrote: [ ... ] > Install pre-rendered man pages instead of the mdoc source, and fake up > a shell script that locates the appropriate page, decompresses it and > pipes it to $PAGER. At least some flavors of the "man" program will show cat pages even if the original NROFF version isn't present. Does the one in FreeBSD not do this? -- -Chuck From owner-freebsd-current@FreeBSD.ORG Thu Apr 28 21:38: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 BDE6416A4F9 for ; Thu, 28 Apr 2005 21:38:40 +0000 (GMT) Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3A8C043D39 for ; Thu, 28 Apr 2005 21:38:40 +0000 (GMT) (envelope-from sam@errno.com) Received: from [66.127.85.91] (sam@[66.127.85.91]) (authenticated bits=0) by ebb.errno.com (8.12.9/8.12.6) with ESMTP id j3SLccms085485 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Apr 2005 14:38:39 -0700 (PDT) (envelope-from sam@errno.com) Message-ID: <42715889.7070202@errno.com> Date: Thu, 28 Apr 2005 14:41:29 -0700 From: Sam Leffler User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050327) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian Candler References: <20050428121447.GA90430@uk.tiscali.com> In-Reply-To: <20050428121447.GA90430@uk.tiscali.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-current@freebsd.org Subject: Re: wpa_supplicant causes panic in ieee80211_newstate X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 28 Apr 2005 21:38:40 -0000 Brian Candler wrote: > -CURRENT supped as of yesterday. Old-ish Dell PIII-600MHz system. I have put > in a Buffalo PCI-PCCard adaptor with WLI-PCM-L11 wireless card, detected as > if_wi. > > Now I'm trying to see if I can get it to join a WPA network. I installed > security/wpa_supplicant from ports, and ran it as > > wpa_supplicant -iwi0 -c/usr/local/etc/wpa_supplicant.conf -d > # based closely on wpa_suppicant.conf.sample > > It generated some screens of debug information, ending with > > Starting AP scan (broadcast SSID) > Added BSSID 00:00:00:00:00:00 into blacklist > EAPOL: External notification - portEnabled=0 > EAPOL: External notification - portValid=0 > Disconnect event - remove keys > wpa_driver_bsd_dsl_key: keyidx=0 > wpa_driver_bsd_dsl_key: keyidx=1 > wpa_driver_bsd_dsl_key: keyidx=2 > wpa_driver_bsd_dsl_key: keyidx=3 > wpa_driver_bsd_dsl_key: keyidx=0 > > At this point, a panic occured on the first virtual console: > > panic: ieee80211_newstate: bogus xmit rate 0 setup > > cpuid = 0 > KDB: enter: panic > [thread pid 22 tid 100014 ] > Stopped at kdb_enter+0x2b: nop > db> trace > Tracing pid 22 tid 100014 td 0xc1521d80 > kdb_enter(c08a88ab) at kdb_enter+0x2b > panic(c08b6a4a,c085bbdf,0,c16ae400,c1770000) at panic+0x127 > ieee80211_netstate(c177025c,4,ffffffff,c16ae400,782af) at ieee80211_newstate+0x50e > wi_newstate(c1777025c,4,ffffffff) at wi_newstate+0x1bf > wi_info_intr(c17770000) at wi_info_intr+0x107 > wi_intr(c17770000) at wi_intr+0x17e > pccard_intr(c1544680,c1775080,cbffed0c,c064622c,c164f880) at pccard_intr+0x60 > cbb_func_intr(c164f880) at cbb_func_intr+0x45 > ithread_loop(c1544c00,cbffed38,c1544c00,c064610c,0) at ithread_loop+0x120 > fork_exit(c064610c,c1544c00,cbffed38) at fork_exit+0xa0 > fork_trampoline() at fork_trampoline+0x8 > --- trap 0x1, eip = 0, esp = 0xcbffed6c, edp = 0 --- > db> ps > ... > 22 c1524c00 0 0 0 0000204 [CPU 0] irq11: cbb0 ifpi0+* > > Unfortunately I didn't have a dumpdev enabled. I don't know if the above is > much use by itself. wi does not support wpa but you shouldn't get a panic. I'll check out the panic. Sam From owner-freebsd-current@FreeBSD.ORG Thu Apr 28 21:46: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 7632216A4CE for ; Thu, 28 Apr 2005 21:46:25 +0000 (GMT) Received: from pun.isi.edu (pun.isi.edu [128.9.160.150]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0D7A143D2D for ; Thu, 28 Apr 2005 21:46:25 +0000 (GMT) (envelope-from faber@pun.isi.edu) Received: from pun.isi.edu (localhost [127.0.0.1]) by pun.isi.edu (8.13.3/8.13.1) with ESMTP id j3SLkOtb001317 for ; Thu, 28 Apr 2005 14:46:24 -0700 (PDT) (envelope-from faber@pun.isi.edu) Received: (from faber@localhost) by pun.isi.edu (8.13.3/8.13.1/Submit) id j3SLkOD9001316 for freebsd-current@freebsd.org; Thu, 28 Apr 2005 14:46:24 -0700 (PDT) (envelope-from faber) Date: Thu, 28 Apr 2005 14:46:24 -0700 From: Ted Faber To: FreeBSD Current Message-ID: <20050428214624.GA1197@pun.isi.edu> References: <17001.42481.325920.113852@roam.psg.com> <20050425151443.GA1523@pun.isi.edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="7AUc2qLy4jB3hD7Z" Content-Disposition: inline In-Reply-To: <20050425151443.GA1523@pun.isi.edu> User-Agent: Mutt/1.4.2.1i X-url: http://www.isi.edu/~faber Subject: Re: disk freeze? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 28 Apr 2005 21:46:25 -0000 --7AUc2qLy4jB3hD7Z Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Mon, Apr 25, 2005 at 08:14:43AM -0700, Ted Faber wrote: > This seems to be my week for "me,too" ing Randy, but I'm seeing similar > hard lockups. The machine locks to the point where it won't hear the > soft power switch - I have to yank the plug out to reboot it. > > Needless to say, this is really annoying. > > I did come in this morning, cvsup a new kernel and make & install it (no > lockups yet, but it's only been running a few minutes). When I rebooted > after make kernel, I got a lockup on reboot (!) and a message indicating > that one thread was not a sole owner of a lock. (Sorry, I didn't copy > the text verbatim). And again a hard lock up to the pull the plug out of > the machine stage, though there was a panic and an attempt to rebbot > the machine. > > It seems to happen more frequently on my desktop which NFS mounts most > of its filesystems (with -L). > > All kinds of configs, etc, available on request. I'm not set up for > dumps or debugging, but I can get set up if it helps. These lockups are continuing. I am effectively a Windows user. pun:/var/crash$ uname -a FreeBSD pun.isi.edu 6.0-CURRENT FreeBSD 6.0-CURRENT #12: Wed Apr 27 18:28:51 PDT 2005 root@pun.isi.edu:/usr/src/sys/i386/compile/PUN i386 The kernel was compiled immediately after cvsup. I've built a debug kernel and on the last lockup was able to get into the debugger and try to force a panic, but it never dumped me a core to /var/crash - locked up and rebooted. I did get a file in /var/crash called bounds that's only 2 bytes long, an ASCII "2" and a newline. I suspect that the file system is deadlocking somewhere, but I don't know how to go about ruling that in or out. I can get to the debugger, so any clues what to look for on the next lockup, given that a crash dump is unlikely? I'm happy to provide any info I can. -- Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG --7AUc2qLy4jB3hD7Z Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFCcVmwaUz3f+Zf+XsRAkwhAKCSwTjLuOD4AtkaRQapKBEPYVq2uwCfarPG 2gHJ+KqIlx1bURMtGZd8G2k= =QAga -----END PGP SIGNATURE----- --7AUc2qLy4jB3hD7Z-- From owner-freebsd-current@FreeBSD.ORG Thu Apr 28 21:48: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 E25EC16A4CE; Thu, 28 Apr 2005 21:48:16 +0000 (GMT) Received: from fast.dnswatch.com (fast.dnswatch.com [216.177.243.43]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6888443D1F; Thu, 28 Apr 2005 21:48:16 +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 j3SLmErt010374; Thu, 28 Apr 2005 14:48:16 -0700 (PDT) (envelope-from null@dnswatch.com) Received: (from www@localhost) by fast.dnswatch.com (8.12.6/8.12.6/Submit) id j3SLmDti010373; Thu, 28 Apr 2005 14:48:14 -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; Thu, 28 Apr 2005 14:48:12 -0700 (PDT) Message-ID: <61818.216.177.243.35.1114724893.localmail@webmail.dnswatch.com> In-Reply-To: <200504280606.45379.lofi@freebsd.org> References: <57436.216.177.243.42.1114582155.localmail@webmail.dnswatch.com><1072.172.16.0.199.1114624239.squirrel@172.16.0.1><200504280257.j3S2vXEO007344@dungeon.home> <200504280606.45379.lofi@freebsd.org> Date: Thu, 28 Apr 2005 14:48:12 -0700 (PDT) From: "/dev/null" To: "Michael Nottebrock" 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 cc: freebsd-current@freebsd.org Subject: Re: boot banner project X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 28 Apr 2005 21:48:17 -0000 > On Thursday, 28. April 2005 04:57, Stephen McKay wrote: > >> Put me in the flashiness hating camp also. I especially dislike the >> Linux 60Hz super-eye-destroying graphical boot, which I have to go to >> the >> trouble of defeating as it is the default. > > With CRTs on the retreat though, less and less people care about refresh > rates ... you'll probably join that camp at some point as well. :-) > WOOT! sorry Stephen, this one really caught me by suprise and i found myself on the floor with tears of laughter. Seriously Stephen, this is an RFC and your comment as important as all of the comments recieved. Regardless. BTW - I've been running 30+ servers thru a kvm to an NEC Multisync XL for about 5 years now? A little investigation into this model may be of interest to you. -Chris > -- > ,_, | Michael Nottebrock | lofi@freebsd.org > (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org > \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.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 Thu Apr 28 22:14: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 EA8A916A4CE for ; Thu, 28 Apr 2005 22:14:43 +0000 (GMT) Received: from pi.codefab.com (pi.codefab.com [199.103.21.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id A59AC43D5E for ; Thu, 28 Apr 2005 22:14:43 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from localhost (localhost [127.0.0.1]) by pi.codefab.com (Postfix) with ESMTP id 1B3AA5E8A; Thu, 28 Apr 2005 18:14:43 -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 64354-05; Thu, 28 Apr 2005 18:14:40 -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 B1D6F5CDF; Thu, 28 Apr 2005 18:14:39 -0400 (EDT) Message-ID: <4271602E.5030707@mac.com> Date: Thu, 28 Apr 2005 18:14:06 -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.7) Gecko/20050414 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Steve Ames References: <20050428154859.GA16433@mail.netspace.net.au> <20050428160414.GA21634@outcold.yadt.co.uk> <20050428160706.GA2033@mail.netspace.net.au> <20050428164730.GB34380@troutmask.apl.washington.edu> <20050428165709.GA76059@energistic.com> In-Reply-To: <20050428165709.GA76059@energistic.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at codefab.com cc: freebsd-current@freebsd.org cc: Jonathan Gray Subject: Re: incorrect statement on www page X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 28 Apr 2005 22:14:44 -0000 Steve Ames wrote: > On Thu, Apr 28, 2005 at 09:47:30AM -0700, Steve Kargl wrote: >> You need to specify the (lots of stuff) better. >> Because the following are found on my system. >> >>>http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/hptmv/i386-elf.raid.o.uu >>>http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/contrib/dev/nve/i386/nvenetlib.o.bz2.uu > > Sure. But they aren't source. This is rather a sad discussion as 3rd party > drivers really aren't part of the OS. Agreed. Third-party drivers under a proprietary license are not really part of FreeBSD, although, if the license permits, FreeBSD can include the binary objects into CVS and/or put them into the .ISO images for CDs. Other proprietary drivers have more onerous restrictions, and are handled via ports. The current approach is more convenient for users, and I don't suggest changing that. However, I would not be unhappy if the documentation was clarified, or if the HPT RAID driver was moved from src/sys/dev/ to src/sys/contrib/dev/ to clearly indicate that it is contributed by a third party. -- -Chuck From owner-freebsd-current@FreeBSD.ORG Thu Apr 28 22:17: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 5C21216A4CE for ; Thu, 28 Apr 2005 22:17:27 +0000 (GMT) Received: from fast.dnswatch.com (fast.dnswatch.com [216.177.243.43]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1513243D48 for ; Thu, 28 Apr 2005 22:17:26 +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 j3SMHJrt011144; Thu, 28 Apr 2005 15:17:25 -0700 (PDT) (envelope-from null@dnswatch.com) Received: (from www@localhost) by fast.dnswatch.com (8.12.6/8.12.6/Submit) id j3SMHHF8011143; Thu, 28 Apr 2005 15:17:18 -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; Thu, 28 Apr 2005 15:17:16 -0700 (PDT) Message-ID: <60716.216.177.243.35.1114726636.localmail@webmail.dnswatch.com> In-Reply-To: <1587.66.166.104.222.1114717166.squirrel@66.166.104.222> References: <57436.216.177.243.42.1114582155.localmail@webmail.dnswatch.com> <1072.172.16.0.199.1114624239.squirrel@172.16.0.1> <200504280257.j3S2vXEO007344@dungeon.home> <200504280606.45379.lofi@freebsd.org> <1587.66.166.104.222.1114717166.squirrel@66.166.104.222> Date: Thu, 28 Apr 2005 15:17:16 -0700 (PDT) From: "/dev/null" To: "Ryan Sommers" 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 cc: freebsd-current@freebsd.org Subject: Re: boot banner project X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 28 Apr 2005 22:17:27 -0000 > Michael Nottebrock said: >> With CRTs on the retreat though, less and less people care about refresh >> rates ... you'll probably join that camp at some point as well. :-) >> > > I wouldn't count them out just yet! I still have a 7 year old 19" Sony > Trinitron that is kicking butt, despite the fact that it has about 10 > battle scars from rolling around in a truck bed (don't ask). I haven't > switched it with an LCD just because it still has better clarity and color > quality than any LCD I've seen. > Yes! I couldn't agree more. I've been *enjoying* a 20" NEC Multisync XL (is trinitron too) that inspite of being a 60Hz fixed freq. is *still* clearer and provides more brilliant color than any LCD I've seen. -Chris > -- > Ryan Sommers > ryans@gamersimpact.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" > //////////////////////////////////////////////////// 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 Thu Apr 28 22:18: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 7A1E516A4CE; Thu, 28 Apr 2005 22:18:47 +0000 (GMT) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id CF46F43D31; Thu, 28 Apr 2005 22:18:46 +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 j3SMIkhj039425; Thu, 28 Apr 2005 18:18:46 -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 j3SMIkwW040669; Thu, 28 Apr 2005 18:18:46 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 56D8F7306E; Thu, 28 Apr 2005 18:18:46 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050428221846.56D8F7306E@freebsd-current.sentex.ca> Date: Thu, 28 Apr 2005 18:18:46 -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, 28 Apr 2005 22:18:47 -0000 TB --- 2005-04-28 20:43:19 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-04-28 20:43:19 - starting CURRENT tinderbox run for amd64/amd64 TB --- 2005-04-28 20:43:19 - checking out the source tree TB --- 2005-04-28 20:43:19 - cd /home/tinderbox/CURRENT/amd64/amd64 TB --- 2005-04-28 20:43:19 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-04-28 20:50:02 - building world (CFLAGS=-O2 -pipe) TB --- 2005-04-28 20:50:02 - cd /home/tinderbox/CURRENT/amd64/amd64/src TB --- 2005-04-28 20:50: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 TB --- 2005-04-28 22:02:18 - building generic kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-04-28 22:02:18 - cd /home/tinderbox/CURRENT/amd64/amd64/src TB --- 2005-04-28 22:02:18 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Thu Apr 28 22:02:19 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 28 22:18:15 UTC 2005 TB --- 2005-04-28 22:18:15 - generating LINT kernel config TB --- 2005-04-28 22:18:15 - cd /home/tinderbox/CURRENT/amd64/amd64/src/sys/amd64/conf TB --- 2005-04-28 22:18:15 - /usr/bin/make -B LINT TB --- 2005-04-28 22:18:15 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-04-28 22:18:15 - cd /home/tinderbox/CURRENT/amd64/amd64/src TB --- 2005-04-28 22:18:15 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Apr 28 22:18:15 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 [...] cc -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/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 -I/tinderbox/CURRENT/amd64/amd64/src/sys/dev/twa -D_KERNEL -include opt_global.h -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -c /tinderbox/CURRENT/amd64/amd64/src/sys/amd64/linux32/linux32_genassym.c sh /tinderbox/CURRENT/amd64/amd64/src/sys/kern/genassym.sh linux32_genassym.o > linux32_assym.h cc -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/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 -I/tinderbox/CURRENT/amd64/amd64/src/sys/dev/twa -D_KERNEL -include opt_global.h -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -c /tinderbox/CURRENT/amd64/amd64/src/sys/compat/ia32/ia32_genassym.c env NM='nm' sh /tinderbox/CURRENT/amd64/amd64/src/sys/kern/genassym.sh ia32_genassym.o > ia32_assym.h uudecode < /usr/share/syscons/fonts/cp850-8x16.fnt && file2c 'static u_char dflt_font_16[16*256] = {' '};' < cp850-8x16 > font.h && uudecode < /usr/share/syscons/fonts/cp850-8x14.fnt && file2c 'static u_char dflt_font_14[14*256] = {' '};' < cp850-8x14 >> font.h && uudecode < /usr/share/syscons/fonts/cp850-8x8.fnt && file2c 'static u_char dflt_font_8[8*256] = {' '};' < cp850-8x8 >> font.h /usr/sbin/kbdcontrol -L jp.106 | sed -e 's/^static keymap_t.* = /static keymap_t key_map = /' -e 's/^static accentmap_t.* = /static accentmap_t accent_map = /' > atkbdmap.h /usr/sbin/kbdcontrol -L it.iso | sed -e 's/^static keymap_t.* = /static keymap_t key_map = /' -e 's/^static accentmap_t.* = /static accentmap_t accent_map = /' > ukbdmap.h make: don't know how to make /tinderbox/CURRENT/amd64/amd64/src/sys/hwpmc/hwpmc_mod.c. Stop *** Error code 2 Stop in /tinderbox/CURRENT/amd64/amd64/src. *** Error code 1 Stop in /tinderbox/CURRENT/amd64/amd64/src. TB --- 2005-04-28 22:18:46 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-04-28 22:18:46 - ERROR: failed to build lint kernel TB --- 2005-04-28 22:18:46 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Thu Apr 28 22:26: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 0880B16A4CE for ; Thu, 28 Apr 2005 22:26:57 +0000 (GMT) Received: from orb.pobox.com (orb.pobox.com [207.8.226.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id BA82A43D5C for ; Thu, 28 Apr 2005 22:26:56 +0000 (GMT) (envelope-from b.candler@pobox.com) Received: from orb (localhost [127.0.0.1]) by orb.pobox.com (Postfix) with ESMTP id E36F580A; Thu, 28 Apr 2005 18:26:52 -0400 (EDT) Received: from billdog.local.linnet.org (dsl-212-74-113-65.access.uk.tiscali.com [212.74.113.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by orb.sasl.smtp.pobox.com (Postfix) with ESMTP id AB56A8F; Thu, 28 Apr 2005 18:26:51 -0400 (EDT) Received: from brian by billdog.local.linnet.org with local (Exim 4.43 (FreeBSD)) id 1DRHUl-0000M4-Mn; Thu, 28 Apr 2005 23:28:31 +0100 Date: Thu, 28 Apr 2005 23:28:31 +0100 From: Brian Candler To: Sam Leffler Message-ID: <20050428222831.GB1308@uk.tiscali.com> References: <20050428121447.GA90430@uk.tiscali.com> <42715889.7070202@errno.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42715889.7070202@errno.com> User-Agent: Mutt/1.4.2.1i cc: freebsd-current@freebsd.org Subject: Re: wpa_supplicant causes panic in ieee80211_newstate X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 28 Apr 2005 22:26:57 -0000 On Thu, Apr 28, 2005 at 02:41:29PM -0700, Sam Leffler wrote: > wi does not support wpa but you shouldn't get a panic. I'll check out > the panic. Cheers. Is there a canonical list of cards which *do* support WPA? I was guessing (probably wrongly) that anything under the 80211 layer would. Regards, Brian. From owner-freebsd-current@FreeBSD.ORG Thu Apr 28 22:35: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 B7DD016A4CE for ; Thu, 28 Apr 2005 22:35:57 +0000 (GMT) Received: from fast.dnswatch.com (fast.dnswatch.com [216.177.243.43]) by mx1.FreeBSD.org (Postfix) with ESMTP id 538E743D64 for ; Thu, 28 Apr 2005 22:35:57 +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 j3SMZrrt011601; Thu, 28 Apr 2005 15:35:55 -0700 (PDT) (envelope-from null@dnswatch.com) Received: (from www@localhost) by fast.dnswatch.com (8.12.6/8.12.6/Submit) id j3SMZr8s011600; Thu, 28 Apr 2005 15:35:53 -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; Thu, 28 Apr 2005 15:35:52 -0700 (PDT) Message-ID: <59460.216.177.243.35.1114727752.localmail@webmail.dnswatch.com> In-Reply-To: <200504282119.j3SLJSlw048319@realtime.exit.com> References: <61359.216.177.243.35.1114722481.localmail@webmail.dnswatch.com> <200504282119.j3SLJSlw048319@realtime.exit.com> Date: Thu, 28 Apr 2005 15:35:52 -0700 (PDT) From: "/dev/null" To: frank@exit.com 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 cc: freebsd-current@freebsd.org Subject: Re: boot banner project X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 28 Apr 2005 22:35:57 -0000 > "Beige. I'll paint the bikeshed beige." I'll take that as a vote cast for inverse output. -Chris > -- > Frank Mayhar frank@exit.com http://www.exit.com/ > Exit Consulting http://www.gpsclock.com/ > http://www.exit.com/blog/frank/ > //////////////////////////////////////////////////// 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 Thu Apr 28 22:40: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 E208616A4CE for ; Thu, 28 Apr 2005 22:40:24 +0000 (GMT) Received: from lexi.siliconlandmark.com (lexi.siliconlandmark.com [209.69.98.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5F82243D2D for ; Thu, 28 Apr 2005 22:40:24 +0000 (GMT) (envelope-from andy@siliconlandmark.com) Received: from lexi.siliconlandmark.com (localhost [127.0.0.1]) j3SMeFIK095429; Thu, 28 Apr 2005 18:40:15 -0400 (EDT) (envelope-from andy@siliconlandmark.com) Received: from localhost (andy@localhost)j3SMeFwo095426; Thu, 28 Apr 2005 18:40:15 -0400 (EDT) (envelope-from andy@siliconlandmark.com) X-Authentication-Warning: lexi.siliconlandmark.com: andy owned process doing -bs Date: Thu, 28 Apr 2005 18:40:15 -0400 (EDT) From: Andre Guibert de Bruet To: /dev/null In-Reply-To: <61359.216.177.243.35.1114722481.localmail@webmail.dnswatch.com> Message-ID: <20050428183303.E59099@lexi.siliconlandmark.com> References: <57436.216.177.243.42.1114582155.localmail@webmail.dnswatch.com> <6.1.0.6.2.20050426233321.084e9210@cobalt.antimatter.net> <51899.216.177.243.42.1114584317.localmail@webmail.dnswatch.com> <6.1.0.6.2.20050427001118.0327cd50@cobalt.antimatter.net> <52515.216.177.243.42.1114586501.localmail@webmail.dnswatch.com> <61359.216.177.243.35.1114722481.localmail@webmail.dnswatch.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.548, required 6, autolearn=not spam, AWL 0.05, BAYES_00 -2.60) X-MailScanner-From: andy@siliconlandmark.com cc: freebsd-current@freebsd.org Subject: Re: boot banner project X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 28 Apr 2005 22:40:25 -0000 On Thu, 28 Apr 2005, /dev/null wrote: > Hello, > As this is an RFC (I'm sure you already know that). > > Long answer: > I'm not quite sure. It will depend on the amount and content > of the comments. Technically, it may not start ever (because > everyone/ or nearly everyone says it SUX). > > Short answer: > Too early for me to say. I am not in favor of flashy boot screens and pretty ascii boot screens on the simple basis that they violate POLA. They add complexity and no functionality. I am of the opinion that the color beastie took things too far already... ;-) My $0.10, Andy PS: This email has been adjusted for inflation. | Andre Guibert de Bruet | Enterprise Software Consultant > | Silicon Landmark, LLC. | http://siliconlandmark.com/ > From owner-freebsd-current@FreeBSD.ORG Thu Apr 28 22:53: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 3A10A16A4CE for ; Thu, 28 Apr 2005 22:53:56 +0000 (GMT) Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by mx1.FreeBSD.org (Postfix) with SMTP id B58F643D58 for ; Thu, 28 Apr 2005 22:53:54 +0000 (GMT) (envelope-from Emanuel.strobl@gmx.net) Received: (qmail invoked by alias); 28 Apr 2005 22:53:53 -0000 Received: from flb.schmalzbauer.de (EHLO cale.flintsbach.schmalzbauer.de) [62.245.232.135] by mail.gmx.net (mp019) with SMTP; 29 Apr 2005 00:53:53 +0200 X-Authenticated: #301138 From: Emanuel Strobl To: freebsd-current@freebsd.org Date: Fri, 29 Apr 2005 00:53:41 +0200 User-Agent: KMail/1.8 References: <200504262010.49509@harrymail> <86k6mo0xmh.fsf@xps.des.no> <427157B7.6040203@mac.com> In-Reply-To: <427157B7.6040203@mac.com> X-Birthday: Oct. 6th 1972 X-CelPhone: +49 (0) 173 9967781 X-Tel: +49 (0) 89 18947781 X-Country: Germany X-Address: Munich, 80686 X-OS: FreeBSD MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart6010015.sX9MGfhvpq"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200504290053.51912@harrymail> X-Y-GMX-Trusted: 0 cc: Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?= cc: freebsd-questions@freebsd.org Subject: Re: groff alternative? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 28 Apr 2005 22:53:56 -0000 --nextPart6010015.sX9MGfhvpq Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Am Donnerstag, 28. April 2005 23:37 schrieb Chuck Swiger: > Dag-Erling Sm=F8rgrav wrote: > [ ... ] > > > Install pre-rendered man pages instead of the mdoc source, and fake up > > a shell script that locates the appropriate page, decompresses it and > > pipes it to $PAGER. > > At least some flavors of the "man" program will show cat pages even if the > original NROFF version isn't present. Does the one in FreeBSD not do thi= s? In case of cat pages it does, but like I wrote I want to be able to add=20 packages and read their man pages without having to involve any other=20 machine. So there's no way arround a lean *roff... Bit it's on ice for the moment, I'm about XP-ipsec(dynamicIP) <-> FreeBSD=20 problems.... (and racoon was the man page I wanted to read on my embedded=20 box) Thanks, =2DHarry --nextPart6010015.sX9MGfhvpq Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQBCcWl/Bylq0S4AzzwRAmPGAJ9AHbwYC9SvmrZ9SFWKVZwHVec9bACeIHub qNuc+AerGtSdf8AUFy1ImOE= =sHvW -----END PGP SIGNATURE----- --nextPart6010015.sX9MGfhvpq-- From owner-freebsd-current@FreeBSD.ORG Thu Apr 28 23: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 8291316A4CE for ; Thu, 28 Apr 2005 23:02:56 +0000 (GMT) Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id 42A0243D53 for ; Thu, 28 Apr 2005 23:02:56 +0000 (GMT) (envelope-from sam@errno.com) Received: from [66.127.85.91] (sam@[66.127.85.91]) (authenticated bits=0) by ebb.errno.com (8.12.9/8.12.6) with ESMTP id j3SN2sms085978 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Apr 2005 16:02:54 -0700 (PDT) (envelope-from sam@errno.com) Message-ID: <42716C48.9070206@errno.com> Date: Thu, 28 Apr 2005 16:05:44 -0700 From: Sam Leffler User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050327) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian Candler References: <20050428121447.GA90430@uk.tiscali.com> <42715889.7070202@errno.com> <20050428222831.GB1308@uk.tiscali.com> In-Reply-To: <20050428222831.GB1308@uk.tiscali.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-current@freebsd.org Subject: Re: wpa_supplicant causes panic in ieee80211_newstate X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 28 Apr 2005 23:02:56 -0000 Brian Candler wrote: > On Thu, Apr 28, 2005 at 02:41:29PM -0700, Sam Leffler wrote: > >>wi does not support wpa but you shouldn't get a panic. I'll check out >>the panic. > > > Cheers. > > Is there a canonical list of cards which *do* support WPA? I was guessing > (probably wrongly) that anything under the 80211 layer would. ath supports it. ndis recently grew wpa-psk support which may do what you want. other drivers are waiting someone to pitch in--it's not real hard for a driver that uses the net80211 layer properly. Sam From owner-freebsd-current@FreeBSD.ORG Thu Apr 28 23: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 1ADD616A4CE for ; Thu, 28 Apr 2005 23:05:44 +0000 (GMT) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 80B7943D5A for ; Thu, 28 Apr 2005 23:05:43 +0000 (GMT) (envelope-from fierykylin@gmail.com) Received: by zproxy.gmail.com with SMTP id 40so1101938nzk for ; Thu, 28 Apr 2005 16:05:43 -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=TZCDLsWX/ppXNdPqk9cmRtvOSF/Fu4vSuPk3u8IsJXxoQtIIxc9TboXacZYpL1Tp2WBEpEp978Pb8Hif7UeQWlgTx0QMJZm3FVyg9uVus/WGooIwLWF9Mch7J3P5V94H/krxK2siW1YufdCd3C2S7zwyACTNyynU6Pbfxz1W5E8= Received: by 10.36.88.3 with SMTP id l3mr130243nzb; Thu, 28 Apr 2005 16:05:43 -0700 (PDT) Received: by 10.36.104.6 with HTTP; Thu, 28 Apr 2005 16:05:43 -0700 (PDT) Message-ID: <87ab37ab05042816056854d803@mail.gmail.com> Date: Fri, 29 Apr 2005 07:05:43 +0800 From: kylin To: "M. Warner Losh" In-Reply-To: <20050427.224439.91313267.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <87ab37ab050425205527cecaf3@mail.gmail.com> <20050427113418.GD5585@empiric.icir.org> <20050427.224439.91313267.imp@bsdimp.com> cc: freebsd-current@freebsd.org Subject: Re: when will pci hotplug in Freebsd X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: kylin List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2005 23:05:44 -0000 On 4/28/05, M. Warner Losh wrote: > In message: <20050427113418.GD5585@empiric.icir.org> > Bruce M Simpson writes: > : The thing we haven't worked out how to do just yet is how to divide the > : necessary resources in a strictly hierarchical way. >=20 > I have some ideas on this one... I'll try to implement them, but for > -current. I'd also like to get some of the simpler parts of your > patches into -current as well. Any objection to my merging some of > them in? >=20 > Warner >=20 have you seen the linux 2.6 way and the open bsd's? --=20 we who r about to die,salute u! From owner-freebsd-current@FreeBSD.ORG Thu Apr 28 23:06: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 5CBA016A4CE for ; Thu, 28 Apr 2005 23:06:15 +0000 (GMT) Received: from fast.dnswatch.com (fast.dnswatch.com [216.177.243.43]) by mx1.FreeBSD.org (Postfix) with ESMTP id AB5FF43D4C for ; Thu, 28 Apr 2005 23:06:14 +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 j3SN6Art012109; Thu, 28 Apr 2005 16:06:14 -0700 (PDT) (envelope-from null@dnswatch.com) Received: (from www@localhost) by fast.dnswatch.com (8.12.6/8.12.6/Submit) id j3SN69W8012108; Thu, 28 Apr 2005 16:06:09 -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; Thu, 28 Apr 2005 16:06:08 -0700 (PDT) Message-ID: <53955.216.177.243.35.1114729568.localmail@webmail.dnswatch.com> In-Reply-To: <20050428183303.E59099@lexi.siliconlandmark.com> References: <57436.216.177.243.42.1114582155.localmail@webmail.dnswatch.com> <6.1.0.6.2.20050426233321.084e9210@cobalt.antimatter.net> <51899.216.177.243.42.1114584317.localmail@webmail.dnswatch.com> <6.1.0.6.2.20050427001118.0327cd50@cobalt.antimatter.net> <52515.216.177.243.42.1114586501.localmail@webmail.dnswatch.com> <61359.216.177.243.35.1114722481.localmail@webmail.dnswatch.com> <20050428183303.E59099@lexi.siliconlandmark.com> Date: Thu, 28 Apr 2005 16:06:08 -0700 (PDT) From: "/dev/null" To: "Andre Guibert de Bruet" 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 cc: freebsd-current@freebsd.org Subject: Re: boot banner project X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 28 Apr 2005 23:06:15 -0000 > > On Thu, 28 Apr 2005, /dev/null wrote: > >> Hello, >> As this is an RFC (I'm sure you already know that). >> >> Long answer: >> I'm not quite sure. It will depend on the amount and content >> of the comments. Technically, it may not start ever (because >> everyone/ or nearly everyone says it SUX). >> >> Short answer: >> Too early for me to say. > > I am not in favor of flashy boot screens and pretty ascii boot screens on > the simple basis that they violate POLA. They add complexity and no > functionality. I am of the opinion that the color beastie took things too > far already... ;-) You have a color one?! Where do you get it? I only have a white ASCII one. Seriously tho, in the event there is any doubt. I firmly believe that it should *always* be a matter of choice. One should always be able to enable/ disable, add or remove. So, should there be any doubt, I intend this - whatever it should become - to be something that can be added to (or removed from) whatever is current. nuf said. ;) -Chris > > My $0.10, > Andy > > PS: This email has been adjusted for inflation. > > | 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" > //////////////////////////////////////////////////// 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 Thu Apr 28 23:22: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 6EFF716A4CE for ; Thu, 28 Apr 2005 23:22:44 +0000 (GMT) Received: from mail.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 435F943D3F for ; Thu, 28 Apr 2005 23:22:44 +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 EFFA57A403; Thu, 28 Apr 2005 16:22:43 -0700 (PDT) Message-ID: <42717043.6030209@elischer.org> Date: Thu, 28 Apr 2005 16:22:43 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.7) Gecko/20050423 X-Accept-Language: en, hu MIME-Version: 1.0 To: kylin References: <87ab37ab050425205527cecaf3@mail.gmail.com> <20050427113418.GD5585@empiric.icir.org> <20050427.224439.91313267.imp@bsdimp.com> <87ab37ab05042816056854d803@mail.gmail.com> In-Reply-To: <87ab37ab05042816056854d803@mail.gmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-current@freebsd.org cc: "M. Warner Losh" Subject: Re: when will pci hotplug 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, 28 Apr 2005 23:22:44 -0000 are you kylin.org.cn? From owner-freebsd-current@FreeBSD.ORG Thu Apr 28 23:27: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 AD43816A4CE for ; Thu, 28 Apr 2005 23:27:42 +0000 (GMT) Received: from zircon.seattle.wa.us (dsl231-043-165.sea1.dsl.speakeasy.net [216.231.43.165]) by mx1.FreeBSD.org (Postfix) with SMTP id 831DF43D45 for ; Thu, 28 Apr 2005 23:27:30 +0000 (GMT) (envelope-from joe@zircon.seattle.wa.us) Received: (qmail 37264 invoked from network); 28 Apr 2005 23:28:22 -0000 Received: from localhost (HELO localhost.zircon.seattle.wa.us) (127.0.0.1) by localhost with SMTP; 28 Apr 2005 23:28:22 -0000 From: Joe Kelsey To: /dev/null In-Reply-To: <60716.216.177.243.35.1114726636.localmail@webmail.dnswatch.com> References: <57436.216.177.243.42.1114582155.localmail@webmail.dnswatch.com> <1072.172.16.0.199.1114624239.squirrel@172.16.0.1> <200504280257.j3S2vXEO007344@dungeon.home> <200504280606.45379.lofi@freebsd.org> <1587.66.166.104.222.1114717166.squirrel@66.166.104.222> <60716.216.177.243.35.1114726636.localmail@webmail.dnswatch.com> Content-Type: text/plain Date: Thu, 28 Apr 2005 16:28:19 -0700 Message-Id: <1114730899.712.60.camel@zircon.zircon.seattle.wa.us> Mime-Version: 1.0 X-Mailer: Evolution 2.2.2 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit cc: Ryan Sommers cc: freebsd-current@freebsd.org Subject: Re: boot banner project X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 28 Apr 2005 23:27:42 -0000 On Thu, 2005-04-28 at 15:17 -0700, /dev/null wrote: > > Michael Nottebrock said: > >> With CRTs on the retreat though, less and less people care about refresh > >> rates ... you'll probably join that camp at some point as well. :-) > >> > > > > I wouldn't count them out just yet! I still have a 7 year old 19" Sony > > Trinitron that is kicking butt, despite the fact that it has about 10 > > battle scars from rolling around in a truck bed (don't ask). I haven't > > switched it with an LCD just because it still has better clarity and color > > quality than any LCD I've seen. > > > > Yes! I couldn't agree more. I've been *enjoying* a 20" NEC Multisync XL > (is trinitron too) that inspite of being a 60Hz fixed freq. is *still* > clearer and provides more brilliant color than any LCD I've seen. The only reason you *think* your CRT looks better than the LCD is due to the misaligned LCD's on display at most stores. In order to really appreciate the clarity and sharpness of an LCD you must either plug it into a DVI interface, in which case no alignment is necessary, or spend a significant amount of time adjusting it to work correctly on an analog interface. Since most stores do not bother to hook up DVI interfaces, you must spend a significant amount of time adjusting each monitor to make sure that it matches the analog signal exactly with the dots on the screen. If the signal does not match the dots, you get an ugly, blurry image. You must also make sure that your screen resolution matches the LCD resolution *exactly*. Do not ever run an 1280x1024 LCD at 1024x768 or even at 800x600. You will hate the results. Recently, a friend and I went to the Seattle Frye's and spent almost 2 hours in front of the row of 19" LCD monitors very carefully going through each one's setup menu and finding the hidden control which adjusted the analog signal with the monitor dots. None of them called the signal the same thing (not even two different Viewsonic monitors!), but they all had a signal which essentially worked to align the input signal with the dot mask of the monitor. Once we got them all aligned, it was very tough to tell the difference between the monitors. We ended up buying the ViewSonic V910 fir $400. As soon as I got it home and plugged into my Matrox MGA 550 (which has two interfaces, one analog and one digital) it worked instantly with no adjustment other than the brightness (backlight intensity). If you buy a LCD, please make sure you have a card with digital I/O. I recommend that you stay as far away as possible from anything recent as none of those idiotic NVIDIA cards do anything reasonable. Buy an old Matrox, at least a MGA 400 with the dual monitor plugs on it. /Joe From owner-freebsd-current@FreeBSD.ORG Thu Apr 28 23: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 61F4316A4CE for ; Thu, 28 Apr 2005 23:49:12 +0000 (GMT) Received: from dglawrence.com (dsl-230-156.ipns.com [209.210.230.156]) by mx1.FreeBSD.org (Postfix) with ESMTP id C10BC43D3F for ; Thu, 28 Apr 2005 23:49:11 +0000 (GMT) (envelope-from dg@dglawrence.com) Received: from opteron.dglawrence.com (localhost [127.0.0.1]) by dglawrence.com (8.13.3/8.13.1) with ESMTP id j3SNmoLd062637; Thu, 28 Apr 2005 16:48:50 -0700 (PDT) (envelope-from dg@dglawrence.com) Received: (from dg@localhost) by opteron.dglawrence.com (8.13.3/8.13.1/Submit) id j3SNmbR1062636; Thu, 28 Apr 2005 16:48:37 -0700 (PDT) (envelope-from dg@dglawrence.com) Date: Thu, 28 Apr 2005 16:48:37 -0700 From: "David G. Lawrence" To: Joe Kelsey Message-ID: <20050428234837.GK15846@opteron.dglawrence.com> References: <57436.216.177.243.42.1114582155.localmail@webmail.dnswatch.com> <1072.172.16.0.199.1114624239.squirrel@172.16.0.1> <200504280257.j3S2vXEO007344@dungeon.home> <200504280606.45379.lofi@freebsd.org> <1587.66.166.104.222.1114717166.squirrel@66.166.104.222> <60716.216.177.243.35.1114726636.localmail@webmail.dnswatch.com> <1114730899.712.60.camel@zircon.zircon.seattle.wa.us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1114730899.712.60.camel@zircon.zircon.seattle.wa.us> cc: Ryan Sommers cc: /dev/null cc: freebsd-current@freebsd.org Subject: Re: boot banner project X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 28 Apr 2005 23:49:12 -0000 > > > I wouldn't count them out just yet! I still have a 7 year old 19" Sony > > > Trinitron that is kicking butt, despite the fact that it has about 10 > > > battle scars from rolling around in a truck bed (don't ask). I haven't > > > switched it with an LCD just because it still has better clarity and color > > > quality than any LCD I've seen. > > > > > > > Yes! I couldn't agree more. I've been *enjoying* a 20" NEC Multisync XL > > (is trinitron too) that inspite of being a 60Hz fixed freq. is *still* > > clearer and provides more brilliant color than any LCD I've seen. > > The only reason you *think* your CRT looks better than the LCD is due to > the misaligned LCD's on display at most stores. Actually, while it is true that most LCD panels are not adjusted correctly, there are technology deficiencies in LCD as well. For one thing, LCD has comparatively poor black level due to backlight leakage. Also, while it is true that LCDs should always be connected using DVI at the native resolution to avoid scaling and analog signal artifacts, it is not true that this will make the color perfect. In addition to the CIE colorspace (i.e. the color spectrum of the red, green, and blue primaries) needing to be correct, the color of white/gray is also critical. Most LCD panels don't have the necessary controls to adjust this properly - they usually only have an adjustment for RGB gain, but lack RGB offset and gamma controls. On the other hand, most CRTs also lack user accessible controls for these settings. Personally, I haven't owned a CRT for nearly a decade. For computer use, nothing beats the sharpness of a DVI-connected LCD. For television, DLP projection is a better choice for black level and color accuracy. But what does any of this have to do with FreeBSD? :-) -DG David G. Lawrence President Download Technologies, Inc. - http://www.downloadtech.com - (866) 399 8500 TeraSolutions, Inc. - http://www.terasolutions.com - (888) 346 7175 The FreeBSD Project - http://www.freebsd.org Pave the road of life with opportunities. From owner-freebsd-current@FreeBSD.ORG Thu Apr 28 23:51: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 76F3C16A4CE; Thu, 28 Apr 2005 23:51:10 +0000 (GMT) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1035A43D2F; Thu, 28 Apr 2005 23:51:10 +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 j3SNp9TY054481; Thu, 28 Apr 2005 19:51:09 -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 j3SNpg3f020493; Thu, 28 Apr 2005 19:51:42 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 5D8E67306E; Thu, 28 Apr 2005 19:51:09 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050428235109.5D8E67306E@freebsd-current.sentex.ca> Date: Thu, 28 Apr 2005 19:51:09 -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, 28 Apr 2005 23:51:10 -0000 TB --- 2005-04-28 22:18:46 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-04-28 22:18:46 - starting CURRENT tinderbox run for i386/i386 TB --- 2005-04-28 22:18:46 - checking out the source tree TB --- 2005-04-28 22:18:46 - cd /home/tinderbox/CURRENT/i386/i386 TB --- 2005-04-28 22:18:46 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-04-28 22:25:24 - building world (CFLAGS=-O2 -pipe) TB --- 2005-04-28 22:25:24 - cd /home/tinderbox/CURRENT/i386/i386/src TB --- 2005-04-28 22:25:24 - /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-28 23:32:23 - building generic kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-04-28 23:32:23 - cd /home/tinderbox/CURRENT/i386/i386/src TB --- 2005-04-28 23:32:23 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Thu Apr 28 23:32:24 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 28 23:50:34 UTC 2005 TB --- 2005-04-28 23:50:34 - generating LINT kernel config TB --- 2005-04-28 23:50:34 - cd /home/tinderbox/CURRENT/i386/i386/src/sys/i386/conf TB --- 2005-04-28 23:50:34 - /usr/bin/make -B LINT TB --- 2005-04-28 23:50:34 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-04-28 23:50:34 - cd /home/tinderbox/CURRENT/i386/i386/src TB --- 2005-04-28 23:50:34 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Apr 28 23:50:34 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 [...] /usr/sbin/kbdcontrol -L it.iso | sed -e 's/^static keymap_t.* = /static keymap_t key_map = /' -e 's/^static accentmap_t.* = /static accentmap_t accent_map = /' > ukbdmap.h cp /tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath/public/i386-elf.opt_ah.h opt_ah.h /home/tinderbox/CURRENT/i386/i386/obj/tinderbox/CURRENT/i386/i386/src/make.i386/make -f /tinderbox/CURRENT/i386/i386/src/sys/i386/acpica/Makefile MAKESRCPATH=/tinderbox/CURRENT/i386/i386/src/sys/i386/acpica cc -O2 -pipe -I. -I@ -c /tinderbox/CURRENT/i386/i386/src/sys/i386/acpica/acpi_wakecode.S objcopy -S -O binary acpi_wakecode.o acpi_wakecode.bin sh /tinderbox/CURRENT/i386/i386/src/sys/i386/acpica/genwakecode.sh > acpi_wakecode.h Warning: Object directory not changed from original /tinderbox/CURRENT/i386/i386/obj/tinderbox/CURRENT/i386/i386/src/sys/LINT make: don't know how to make /tinderbox/CURRENT/i386/i386/src/sys/hwpmc/hwpmc_mod.c. Stop *** Error code 2 Stop in /tinderbox/CURRENT/i386/i386/src. *** Error code 1 Stop in /tinderbox/CURRENT/i386/i386/src. TB --- 2005-04-28 23:51:09 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-04-28 23:51:09 - ERROR: failed to build lint kernel TB --- 2005-04-28 23:51:09 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Thu Apr 28 23:59: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 1C91016A4CE; Thu, 28 Apr 2005 23:59:02 +0000 (GMT) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id B07B743D41; Thu, 28 Apr 2005 23:59:01 +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 j3SNx14p042903; Thu, 28 Apr 2005 19:59:01 -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 j3SNx12R091632; Thu, 28 Apr 2005 19:59:01 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 209007306E; Thu, 28 Apr 2005 19:59:01 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050428235901.209007306E@freebsd-current.sentex.ca> Date: Thu, 28 Apr 2005 19:59:01 -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 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, 28 Apr 2005 23:59:02 -0000 TB --- 2005-04-28 23:51:09 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-04-28 23:51:09 - starting CURRENT tinderbox run for i386/pc98 TB --- 2005-04-28 23:51:09 - checking out the source tree TB --- 2005-04-28 23:51:09 - cd /home/tinderbox/CURRENT/i386/pc98 TB --- 2005-04-28 23:51:09 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-04-28 23:57:47 - building world (CFLAGS=-O2 -pipe) TB --- 2005-04-28 23:57:47 - cd /home/tinderbox/CURRENT/i386/pc98/src TB --- 2005-04-28 23:57: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 [...] ===> sbin/growfs (cleandir) ===> sbin/gvinum (cleandir) ===> sbin/ifconfig (cleandir) ===> sbin/init (cleandir) ===> sbin/ip6fw (cleandir) ===> sbin/ipf (cleandir) ".depend", line 299: Inconsistent operator for ipf make: fatal errors encountered -- cannot continue *** Error code 1 Stop in /tinderbox/CURRENT/i386/pc98/src/sbin. *** 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-28 23:59:01 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-04-28 23:59:01 - ERROR: failed to build world TB --- 2005-04-28 23:59:01 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Fri Apr 29 00:02: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 2B25E16A4CE; Fri, 29 Apr 2005 00:02:35 +0000 (GMT) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id AE91F43D3F; Fri, 29 Apr 2005 00:02:34 +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 j3T02YDE043095; Thu, 28 Apr 2005 20:02:34 -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 j3T037qb025673; Thu, 28 Apr 2005 20:03:07 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 2A0FF7306E; Thu, 28 Apr 2005 20:02:34 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050429000234.2A0FF7306E@freebsd-current.sentex.ca> Date: Thu, 28 Apr 2005 20:02:34 -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: Fri, 29 Apr 2005 00:02:35 -0000 TB --- 2005-04-28 23:59:01 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-04-28 23:59:01 - starting CURRENT tinderbox run for ia64/ia64 TB --- 2005-04-28 23:59:01 - checking out the source tree TB --- 2005-04-28 23:59:01 - cd /home/tinderbox/CURRENT/ia64/ia64 TB --- 2005-04-28 23:59:01 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-04-29 00:01:16 - building world (CFLAGS=-O2 -pipe) TB --- 2005-04-29 00:01:16 - cd /home/tinderbox/CURRENT/ia64/ia64/src TB --- 2005-04-29 00:01:16 - /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 [...] ===> sbin/growfs (cleandir) ===> sbin/gvinum (cleandir) ===> sbin/ifconfig (cleandir) ===> sbin/init (cleandir) ===> sbin/ip6fw (cleandir) ===> sbin/ipf (cleandir) ".depend", line 269: Inconsistent operator for ipf make: fatal errors encountered -- cannot continue *** Error code 1 Stop in /tinderbox/CURRENT/ia64/ia64/src/sbin. *** Error code 1 Stop in /tinderbox/CURRENT/ia64/ia64/src. *** Error code 1 Stop in /tinderbox/CURRENT/ia64/ia64/src. *** Error code 1 Stop in /tinderbox/CURRENT/ia64/ia64/src. TB --- 2005-04-29 00:02:34 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-04-29 00:02:34 - ERROR: failed to build world TB --- 2005-04-29 00:02:34 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Fri Apr 29 00: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 1F68A16A4CE; Fri, 29 Apr 2005 00:08:27 +0000 (GMT) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id B3C5943D3F; Fri, 29 Apr 2005 00:08:26 +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 j3T08Qom043246; Thu, 28 Apr 2005 20:08:26 -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 j3T08Q7P034589; Thu, 28 Apr 2005 20:08:26 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 404627306E; Thu, 28 Apr 2005 20:08:26 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050429000826.404627306E@freebsd-current.sentex.ca> Date: Thu, 28 Apr 2005 20:08:26 -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 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: Fri, 29 Apr 2005 00:08:27 -0000 TB --- 2005-04-29 00:02:34 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-04-29 00:02:34 - starting CURRENT tinderbox run for powerpc/powerpc TB --- 2005-04-29 00:02:34 - checking out the source tree TB --- 2005-04-29 00:02:34 - cd /home/tinderbox/CURRENT/powerpc/powerpc TB --- 2005-04-29 00:02:34 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-04-29 00:07:09 - building world (CFLAGS=-O2 -pipe) TB --- 2005-04-29 00:07:09 - cd /home/tinderbox/CURRENT/powerpc/powerpc/src TB --- 2005-04-29 00:07: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 [...] ===> sbin/growfs (cleandir) ===> sbin/gvinum (cleandir) ===> sbin/ifconfig (cleandir) ===> sbin/init (cleandir) ===> sbin/ip6fw (cleandir) ===> sbin/ipf (cleandir) ".depend", line 272: Inconsistent operator for ipf make: fatal errors encountered -- cannot continue *** Error code 1 Stop in /tinderbox/CURRENT/powerpc/powerpc/src/sbin. *** Error code 1 Stop in /tinderbox/CURRENT/powerpc/powerpc/src. *** Error code 1 Stop in /tinderbox/CURRENT/powerpc/powerpc/src. *** Error code 1 Stop in /tinderbox/CURRENT/powerpc/powerpc/src. TB --- 2005-04-29 00:08:26 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-04-29 00:08:26 - ERROR: failed to build world TB --- 2005-04-29 00:08:26 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Fri Apr 29 00:12: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 335EB16A4CE; Fri, 29 Apr 2005 00:12:52 +0000 (GMT) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id A1E7B43D45; Fri, 29 Apr 2005 00:12:51 +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 j3T0Cp4S043412; Thu, 28 Apr 2005 20:12:51 -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 j3T0CpkB055303; Thu, 28 Apr 2005 20:12:51 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id D444C7306E; Thu, 28 Apr 2005 20:12:50 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050429001250.D444C7306E@freebsd-current.sentex.ca> Date: Thu, 28 Apr 2005 20:12:50 -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 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: Fri, 29 Apr 2005 00:12:52 -0000 TB --- 2005-04-29 00:08:26 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-04-29 00:08:26 - starting CURRENT tinderbox run for sparc64/sparc64 TB --- 2005-04-29 00:08:26 - checking out the source tree TB --- 2005-04-29 00:08:26 - cd /home/tinderbox/CURRENT/sparc64/sparc64 TB --- 2005-04-29 00:08:26 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-04-29 00:11:37 - building world (CFLAGS=-O2 -pipe) TB --- 2005-04-29 00:11:37 - cd /home/tinderbox/CURRENT/sparc64/sparc64/src TB --- 2005-04-29 00:11:37 - /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 [...] ===> sbin/growfs (cleandir) ===> sbin/gvinum (cleandir) ===> sbin/ifconfig (cleandir) ===> sbin/init (cleandir) ===> sbin/ip6fw (cleandir) ===> sbin/ipf (cleandir) ".depend", line 275: Inconsistent operator for ipf make: fatal errors encountered -- cannot continue *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/src/sbin. *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/src. *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/src. *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/src. TB --- 2005-04-29 00:12:50 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-04-29 00:12:50 - ERROR: failed to build world TB --- 2005-04-29 00:12:50 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Fri Apr 29 00:27: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 B35E816A4CE for ; Fri, 29 Apr 2005 00:27:45 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0BFF843D45 for ; Fri, 29 Apr 2005 00:27:45 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1]) by harmony.village.org (8.13.3/8.13.1) with ESMTP id j3T0QmoM013279; Thu, 28 Apr 2005 18:26:48 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Thu, 28 Apr 2005 18:26:48 -0600 (MDT) Message-Id: <20050428.182648.74737522.imp@bsdimp.com> To: fierykylin@gmail.com From: Warner Losh In-Reply-To: <87ab37ab05042816056854d803@mail.gmail.com> References: <20050427113418.GD5585@empiric.icir.org> <20050427.224439.91313267.imp@bsdimp.com> <87ab37ab05042816056854d803@mail.gmail.com> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-current@freebsd.org Subject: Re: when will pci hotplug 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, 29 Apr 2005 00:27:45 -0000 > have you seen the linux 2.6 way and the open bsd's? Don't confuse Hot Plug interfaces with pci hot plug. The stuff OpenBSD has is basically the same as FreeBSD's devd. FreeBSD does implement a subset of the pci hot=plug stuff, it is called CardBus and works. Have you looked at FreeBSD's devd? Warner From owner-freebsd-current@FreeBSD.ORG Fri Apr 29 00:53: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 2378716A4CE for ; Fri, 29 Apr 2005 00:53:32 +0000 (GMT) Received: from mx.toxahost.ru (ns.toxahost.ru [62.89.204.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id B133A43D2D for ; Fri, 29 Apr 2005 00:53:31 +0000 (GMT) (envelope-from toxa@toxahost.ru) Received: from localhost (laptoxa.toxa.lan [192.168.1.3]) by mx.toxahost.ru (Toxa) with ESMTP id 6A56DF4 for ; Fri, 29 Apr 2005 04:53:30 +0400 (MSD) Date: Fri, 29 Apr 2005 04:53:19 +0400 From: Toxa To: freebsd-current@freebsd.org X-Comment-To: "Anton A. Karpov" Message-ID: <20050429005319.GA17799@laptoxa.toxa.lan> Mail-Followup-To: freebsd-current@freebsd.org References: <57436.216.177.243.42.1114582155.localmail@webmail.dnswatch.com> <426FDE69.8090909@samsco.org> <426FE1EA.7020900@kutulu.org> <20050428105348.GA8056@laptoxa.toxa.lan> <4270E7F1.9010502@kutulu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <4270E7F1.9010502@kutulu.org> User-Agent: Outluck Express 1.5.6i for MS-DOS 6.22-SMP X-Mailer: See User-Agent above :) X-Operating-System: MS-DOS 6.22-CURRENT on Sony VAIO laptop X-PGP-Public-Key: http://toxahost.ru/gpg/pubkey.asc X-Useless-Header: Do Androids Dream of Electric Sheep? Subject: Re: boot banner project X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 29 Apr 2005 00:53:32 -0000 On Thu, Apr 28, 2005 at 09:41:05AM -0400, Mike Edenfield wrote: > > 1) It is far from a stupid idea if even one person honestly feels it > would be a benefit. No need to be abusive about it. Yes, I have to mention this was only my humble opinion. > > 2) If I were to choose to work on FreeBSD, I would be free to work on > whatever I felt was lacking. That's how it works. Especially given > that I have nowhere near enough skill in C to work on more complex > system-level issues. Yes, you can do whatewer you want. But what about the result? I think several hundreds lines of lolypop-boot-related code will definitively NOT bring FreeBSD more cleaness and design simpleness. And that's everyone likes in BSDs! > > 3) I was merely making suggestions as to what alternatives were > available. Since almost every Linux distro does something similar to > this proposal, there is obviously SOME merit to it; the benefit may be > miniscule, or irrelevant to many people, but it still exists. > See my opinion above. It's a bad, BAD style, to add features till then they're really necessary and desirable. IMHO. From owner-freebsd-current@FreeBSD.ORG Fri Apr 29 01: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 5350A16A4CE; Fri, 29 Apr 2005 01:01:38 +0000 (GMT) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id DE28B43D2F; Fri, 29 Apr 2005 01:01:37 +0000 (GMT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.13.1/8.13.3) id j3T11bv2074654; Thu, 28 Apr 2005 20:01:37 -0500 (CDT) (envelope-from dan) Date: Thu, 28 Apr 2005 20:01:37 -0500 From: Dan Nelson To: John Baldwin Message-ID: <20050429010136.GA22365@dan.emsphone.com> References: <20050414103154.GA11341@laptop.santcroos.net> <5e7c3d2084ff2460d6e48786defc8f33@xcllnt.net> <20050415173627.GQ4842@dan.emsphone.com> <200504271349.24843.jhb@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200504271349.24843.jhb@FreeBSD.org> X-OS: FreeBSD 5.4-STABLE 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, 29 Apr 2005 01:01:38 -0000 In the last episode (Apr 27), John Baldwin said: > On Friday 15 April 2005 01:36 pm, Dan Nelson wrote: > > 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 > > Current doesn't use that version of the pci_link code anymore, so you > should only see these delays on RELENG_5 now. I built a test -current kernel and it definitely boots a lot faster! -- Dan Nelson dnelson@allantgroup.com From owner-freebsd-current@FreeBSD.ORG Fri Apr 29 01:03: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 20DA316A4CE for ; Fri, 29 Apr 2005 01:03:30 +0000 (GMT) Received: from mx.toxahost.ru (ns.toxahost.ru [62.89.204.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id B514143D5F for ; Fri, 29 Apr 2005 01:03:29 +0000 (GMT) (envelope-from toxa@toxahost.ru) Received: from localhost (laptoxa.toxa.lan [192.168.1.3]) by mx.toxahost.ru (Toxa) with ESMTP id DC28479 for ; Fri, 29 Apr 2005 05:03:28 +0400 (MSD) Date: Fri, 29 Apr 2005 05:03:18 +0400 From: Toxa To: freebsd-current@freebsd.org X-Comment-To: "Anton A. Karpov" Message-ID: <20050429010318.GB17799@laptoxa.toxa.lan> Mail-Followup-To: freebsd-current@freebsd.org References: <57436.216.177.243.42.1114582155.localmail@webmail.dnswatch.com> <426FDE69.8090909@samsco.org> <426FE1EA.7020900@kutulu.org> <20050428105348.GA8056@laptoxa.toxa.lan> <4270CC84.8060904@centtech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <4270CC84.8060904@centtech.com> User-Agent: Outluck Express 1.5.6i for MS-DOS 6.22-SMP X-Mailer: See User-Agent above :) X-Operating-System: MS-DOS 6.22-CURRENT on Sony VAIO laptop X-PGP-Public-Key: http://toxahost.ru/gpg/pubkey.asc X-Useless-Header: Do Androids Dream of Electric Sheep? Subject: Re: boot banner project X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 29 Apr 2005 01:03:30 -0000 On Thu, Apr 28, 2005 at 06:44:04AM -0500, Eric Anderson wrote: > HP-UX boxes too, and I have to say, it's a lot easier to tell what is > going on than our current ascii-spray we have now. I've even had > people ask if my machine just crashed when they see it boot. > > This could easily be an rc.conf option I'm sure.. > > Eric As I've told before, I personally strictly dislike idea to add something till then it's really necessary and desirable. In my humble opinion, polishing representaton of a boot process is generally bad idea. It brings nothing useful into boot process, adds more code into system (We all don't want freebsd to be bloated, do we?), and don't makes such users as you described above more clever. From owner-freebsd-current@FreeBSD.ORG Fri Apr 29 01:09: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 84A2016A4CE for ; Fri, 29 Apr 2005 01:09:05 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id C6ACC43D46 for ; Fri, 29 Apr 2005 01:09:02 +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.3/8.13.3) with ESMTP id j3T1DB8q026464; Thu, 28 Apr 2005 19:13:12 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <4271885C.3000606@samsco.org> Date: Thu, 28 Apr 2005 19:05: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: Toxa References: <57436.216.177.243.42.1114582155.localmail@webmail.dnswatch.com> <426FDE69.8090909@samsco.org> <426FE1EA.7020900@kutulu.org> <20050428105348.GA8056@laptoxa.toxa.lan> <4270CC84.8060904@centtech.com> <20050429010318.GB17799@laptoxa.toxa.lan> In-Reply-To: <20050429010318.GB17799@laptoxa.toxa.lan> 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: boot banner project X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 29 Apr 2005 01:09:05 -0000 Toxa wrote: > On Thu, Apr 28, 2005 at 06:44:04AM -0500, Eric Anderson wrote: > >>HP-UX boxes too, and I have to say, it's a lot easier to tell what is >>going on than our current ascii-spray we have now. I've even had >>people ask if my machine just crashed when they see it boot. >> >>This could easily be an rc.conf option I'm sure.. >> >>Eric > > > As I've told before, I personally strictly dislike idea to add something > till then it's really necessary and desirable. In my humble opinion, > polishing representaton of a boot process is generally bad idea. It > brings nothing useful into boot process, adds more code into system (We > all don't want freebsd to be bloated, do we?), and don't makes such users as > you described above more clever. > Are you the gatekeeper for the 'necessary and desirable' standard? I'd prefer to keep the debate technical and see what can be produced rather than inject personal opinion as if it represents everyone. Scott From owner-freebsd-current@FreeBSD.ORG Fri Apr 29 01:17: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 0040716A4CE for ; Fri, 29 Apr 2005 01:17:38 +0000 (GMT) Received: from smtp-relay.tamu.edu (smtp-relay.tamu.edu [165.91.143.199]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7AD2E43D31 for ; Fri, 29 Apr 2005 01:17:37 +0000 (GMT) (envelope-from tyler@tamu.edu) Received: from [128.194.150.12] (vpn-12.cs.tamu.edu [128.194.150.12]) by smtp-relay.tamu.edu (8.12.10/8.12.10) with ESMTP id j3T1HUrX018540; Thu, 28 Apr 2005 20:17:31 -0500 (CDT) In-Reply-To: <20050429010318.GB17799@laptoxa.toxa.lan> References: <57436.216.177.243.42.1114582155.localmail@webmail.dnswatch.com> <426FDE69.8090909@samsco.org> <426FE1EA.7020900@kutulu.org> <20050428105348.GA8056@laptoxa.toxa.lan> <4270CC84.8060904@centtech.com> <20050429010318.GB17799@laptoxa.toxa.lan> Mime-Version: 1.0 (Apple Message framework v728) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: "R. Tyler Ballance" Date: Thu, 28 Apr 2005 20:17:30 -0500 To: Toxa X-Mailer: Apple Mail (2.728) cc: freebsd-current@freebsd.org Subject: Re: boot banner project X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 29 Apr 2005 01:17:38 -0000 > > As I've told before, I personally strictly dislike idea to add > something > till then it's really necessary and desirable. In my humble opinion, > polishing representaton of a boot process is generally bad idea. It > brings nothing useful into boot process, adds more code into system > (We > all don't want freebsd to be bloated, do we?), and don't makes such > users as > you described above more clever. > I think you're mistaking convenience for bloat...someone mentioned the old redhat boot process earlier, and I can agree with them, that that was, convenient, easy to read, and in no way seemed to add any bloat to the ASCII output. Now, a pretty image, a la FreeSBIE, _is_ bloat, but I don't think that's what is being mentioned or suggested here. Toxa, you make Window Managers, and a lot of GUI apps that make things like, using MacOS X sound terribly bloated, don't discount aesthetics right off the bat, they're not always "evil bloat" -R. Tyler Ballance From owner-freebsd-current@FreeBSD.ORG Fri Apr 29 02:07: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 BE2F616A4CE for ; Fri, 29 Apr 2005 02:07:19 +0000 (GMT) Received: from april.chuckr.org (april.chuckr.org [66.92.151.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id 86F4F43D48 for ; Fri, 29 Apr 2005 02:07:19 +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 2A71912123 for ; Thu, 28 Apr 2005 22:02:39 -0400 (EDT) Message-ID: <427196C0.5040506@chuckr.org> Date: Fri, 29 Apr 2005 02:06:56 +0000 From: Chuck Robey User-Agent: Mozilla Thunderbird 1.0 (X11/20050316) X-Accept-Language: en-us, en MIME-Version: 1.0 To: current Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: tcsh X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 29 Apr 2005 02:07:19 -0000 The first thing I do, after I've installed a new system (just before I copy over the ssh data) is to copy my .cshrc to my home dir. What's so important? I really like the two statements, which I show below, which give me my prompt: set prompt="%m:%{^[[34m%}`id -nu`%{^[[0m%}:%~:%{^[[31m#%h^[[0m%}%#" alias cd 'cd \!*;set prompt="%m%{^[[32m%}:`id -nu`%{^[[0m%}:%~:%{^[[31m#%h^[[0m%}%#"' My mailer is adding carriage returns to the cd line, maybe even to the prompt line, live with it. Any chance that something so basic as this, that improves things so awfully much, could be added to the .tcshrc? If the idea is liked well enough, I will edit it enough so that the special use of prompt strings that are specific to tcsh is made conditional. From owner-freebsd-current@FreeBSD.ORG Fri Apr 29 02:31: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 56A1616A4CE for ; Fri, 29 Apr 2005 02:31:18 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9E6F643D1D for ; Fri, 29 Apr 2005 02:31:15 +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.3/8.13.3) with ESMTP id j3T2ZMNd026744; Thu, 28 Apr 2005 20:35:22 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <42719BA0.5030901@samsco.org> Date: Thu, 28 Apr 2005 20:27:44 -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: Chuck Robey References: <427196C0.5040506@chuckr.org> In-Reply-To: <427196C0.5040506@chuckr.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: current Subject: Re: tcsh X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 29 Apr 2005 02:31:18 -0000 Chuck Robey wrote: > The first thing I do, after I've installed a new system (just before I > copy over the ssh data) is to copy my .cshrc to my home dir. What's so > important? I really like the two statements, which I show below, which > give me my prompt: > > set prompt="%m:%{^[[34m%}`id -nu`%{^[[0m%}:%~:%{^[[31m#%h^[[0m%}%#" > alias cd 'cd \!*;set prompt="%m%{^[[32m%}:`id > -nu`%{^[[0m%}:%~:%{^[[31m#%h^[[0m%}%#"' > > My mailer is adding carriage returns to the cd line, maybe even to the > prompt line, live with it. > > Any chance that something so basic as this, that improves things so > awfully much, could be added to the .tcshrc? If the idea is liked well > enough, I will edit it enough so that the special use of prompt strings > that are specific to tcsh is made conditional. Why does 'cd' have to be aliased? Doesn't 'prompt' act as a magic variable that gets re-evaluated every time it's printed? Anyways, a less colorful version that I use (can't even remember where I got it) is: set prompt = '[%B%m%b] %B%~%b%# ' Has the advantage of changing from a > to a # if you are the superuser, so it gives approximately the same info as printing the username, but in less space and without having to spawn a process every time. For extra credit, there are variations that change the xterm title bar and icon, too. Scott From owner-freebsd-current@FreeBSD.ORG Fri Apr 29 03:28: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 E4B0116A4CE for ; Fri, 29 Apr 2005 03:28:00 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id 64DD443D48 for ; Fri, 29 Apr 2005 03:28:00 +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 j3T3ROww015012; Thu, 28 Apr 2005 21:27:24 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Thu, 28 Apr 2005 21:28:03 -0600 (MDT) Message-Id: <20050428.212803.78072573.imp@bsdimp.com> To: scottl@samsco.org From: "M. Warner Losh" In-Reply-To: <42719BA0.5030901@samsco.org> References: <427196C0.5040506@chuckr.org> <42719BA0.5030901@samsco.org> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: chuckr@chuckr.org cc: FreeBSD-current@freebsd.org Subject: Re: tcsh X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 29 Apr 2005 03:28:01 -0000 In message: <42719BA0.5030901@samsco.org> Scott Long writes: : Why does 'cd' have to be aliased? It doesn't. In historical csh implementations (eg, sunos 4, 4.2 or 4.3 BSD) needed to alias cd to get the prompt set, but tcsh has indeed obviated that need, with all the benefits that you describe. Warner From owner-freebsd-current@FreeBSD.ORG Fri Apr 29 03:28: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 3DCAB16A4CE for ; Fri, 29 Apr 2005 03:28:10 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0BB3143D2F for ; Fri, 29 Apr 2005 03:28:09 +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 j3T3Olbl014977; Thu, 28 Apr 2005 21:24:48 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Thu, 28 Apr 2005 21:25:26 -0600 (MDT) Message-Id: <20050428.212526.49142590.imp@bsdimp.com> To: fierykylin@gmail.com From: "M. Warner Losh" In-Reply-To: <87ab37ab05042721567f5738e9@mail.gmail.com> References: <87ab37ab05042721567f5738e9@mail.gmail.com> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: 20050427113418.GD5585@empiric.icir.org cc: freebsd-current@freebsd.org Subject: Re: idea is good X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 29 Apr 2005 03:28:10 -0000 In message: <87ab37ab05042721567f5738e9@mail.gmail.com> kylin writes: : where will you start ? on which platform shall you go? : for slot is simpler,for pcie is the simplest:) : so i wll have a loot at MR BMS's patches : can not wait and see I'll start with what I have. A cardbus port expander. Warner From owner-freebsd-current@FreeBSD.ORG Fri Apr 29 03:50: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 E68AB16A4CE; Fri, 29 Apr 2005 03:50:52 +0000 (GMT) Received: from hadar.amcc.com (hadar.amcc.com [192.195.69.168]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4A4AE43D53; Fri, 29 Apr 2005 03:50:52 +0000 (GMT) (envelope-from vkashyap@amcc.com) Received: from mailhost01.amcc.com ([192.195.69.30]) by hadar.amcc.com (Netscape Messaging Server 4.15) with SMTP id IFOW0R00.O4F; Thu, 28 Apr 2005 20:50:51 -0700 Received: (from vkashyap-pc [10.66.13.13]) by mailhost01.amcc.com (SMSSMTP 4.0.0.59) with SMTP id M2005042820510429180 ; Thu, 28 Apr 2005 20:51:04 -0700 From: "Vinod Kashyap" To: "Bjoern A. Zeeb" Date: Thu, 28 Apr 2005 20:50:47 -0700 X-Sent-Folder-Path: Sent Items X-Mailer: Oracle Connector for Outlook 9.0.4 51114 (9.0.6627) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-ID: cc: freebsd-current@freebsd.org cc: scottl@freebsd.org Subject: RE: Problem with twa in HEAD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 29 Apr 2005 03:50:53 -0000 > -----Original Message----- > From: Bjoern A. Zeeb [mailto:bz@FreeBSD.org] > Sent: Tuesday, April 26, 2005 3:26 AM > To: Vinod Kashyap > Subject: RE: Problem with twa in HEAD > = > = > On Mon, 25 Apr 2005, Vinod Kashyap wrote: > = > Hi, > = > > > -----Original Message----- > > > From: Bjoern A. Zeeb [mailto:bz@FreeBSD.org] > > > Sent: Monday, April 25, 2005 6:45 AM > > > To: Vinod Kashyap > > > Subject: Re: Problem with twa in HEAD > > > > > > > > > On Fri, 22 Apr 2005, Bjoern A. Zeeb wrote: > > > > > > Hi, > > > > > > > scottl redirected me to you. > > > > > > > > I am currently debugging "hangs" on reboot and shutdown on a > > > > SMP machine with 12 discs at a > > > > > > > > 3ware device driver for 9000 series storage controllers, > > > version: 3.60.00.016 > > > > twa0: <3ware 9000 series Storage Controller> port > > > 0x9800-0x98ff mem 0xfe8ffc00-0xfe8ffcff,0xfb800000-0xfbffffff > > > irq 28 at device 6.0 on pci3 > > > > twa0: [FAST] > > > > twa0: INFO: (0x15: 0x1300): Controller details:: 12 ports, > > > Firmware FE9X 2.06.00.009, BIOS BE9X 2.03.01.051 > > > > > > > > > > > > What I know so far is that Giant is held by sync. > > > > > > > > Things a "spinning" in cam/cam_xpt.c around: > > > > > > > > --- cam_xpt.c 31 Mar 2005 21:42:49 -0000 1.152 > > > > +++ cam_xpt.c 22 Apr 2005 18:42:43 -0000 > > > > @@ -3643,6 +3643,7 @@ xpt_polled_action(union ccb *start_ccb) > > > > !=3D CAM_REQ_INPROG) > > > > break; > > > > DELAY(1000); > > > > printf("XXX status=3D%02x\n", > > > start_ccb->ccb_h.status); > > > > } > > > > if (timeout =3D=3D 0) { > > > > /* > > > > > > > > > > > > with status being 0x200. > > > > > > > > Seems the twa has a command stuck in it. > > > > > > > > I have seen the comment in dev/twa/tw_osl_cam.c ~ line 253 about > > > > queuing and CAM_SIM_QUEUED but I don't know enough about cam. > > > > I seems no all patchs out of this functions seem to = > clear that from > > > > status? > > > > > > > > Any help apreaciated ;) I can try patches; as long as I = > can break > > > > to db> to reboot. > > > > > > further debugging shows that is seems to be spinning in twa_poll. > > > see debug output from TWA_DEBUG 3. The problem is that at = > this point > > > I am no longer able to break to debugger. > > > > > > twa0: tw_osli_execute_scsi: XPT_SCSI_IO: Single virtual address! > > > twa0: tw_osli_execute_scsi: XPT_SCSI_IO: Single virtual address! > > > unmount of /dev failed (BUSY) > > > twa0: tw_osli_execute_scsi: XPT_SCSI_IO: Single virtual address! > > > twa0: tw_osli_execute_scsi: XPT_SCSI_IO: Single virtual address! > > > Uptime: 2m57s > > > twa0: tw_osli_execute_scsi: XPT_SCSI_IO: Single virtual address! > > > twa0: twa_poll: entering; sc =3D 0xc57bb200 > > > twa0: twa_poll: exiting; sc =3D 0xc57bb200 > > > twa0: twa_poll: entering; sc =3D 0xc57bb200 > > > twa0: twa_poll: exiting; sc =3D 0xc57bb200 > > > twa0: twa_poll: entering; sc =3D 0xc57bb200 > > > twa0: twa_poll: exiting; sc =3D 0xc57bb200 > > > twa0: twa_poll: entering; sc =3D 0xc57bb200 > > > twa0: twa_poll: exiting; sc =3D 0xc57bb200 > > > twa0: twa_poll: entering; sc =3D 0xc57bb200 > > > twa0: twa_poll: exiting; sc =3D 0xc57bb200 > > > twa0: twa_poll: entering; sc =3D 0xc57bb200 > > > twa0: twa_poll: exiting; sc =3D 0xc57bb200 > > > twa0: twa_poll: entering; sc =3D 0xc57bb200 > > > twa0: twa_poll: exiting; sc =3D 0xc57bb200 > > > ... > > > > > > > I am in the middle of an office move right now. > > I will get back to you once I have some time to look into this. > = > = > thanks for the information; I'll be able to test at least until end of > this week and hopefully next week too. > = I looked into this, and this is what is happening: On reboot/halt, the following function calling sequence happens: ... --> dashutdown --> xpt_polled_action --> twa_poll. But, the interrupt handler in twa is still active at this time, since twa_detach/twa_shutdown hasn't been called yet. Before twa_poll can fetch the response for the posted command, the ISR gets called when the firmware posts the response. The ISR clears the interrupt bit on the controller, registers a taskqueue handler like it always does, and exits. Meanwhile, xpt_polled_action continues to call twa_poll, which cannot determine that the command has completed, since the interrupt bit on the controller is already cleared. So, we get into a (near) never-ending loop (the timeout for scsi_synchronize_ca= che, which is what is being tried here, is, for whatever reason, 60 minutes, and so, the system is as good as hung). Now, does anyone know why xpt_polled_action is being called from dashutdown, even before the ISR has been unregistered (via twa_detach)? Bjoern, this patch should work-around your problem, although it's not the fix. Also, it still leaves a window for the race condition described above. diff -u -r ../twa.cur/tw_osl.h ./tw_osl.h --- ../twa.cur/tw_osl.h Fri Apr 8 12:43:45 2005 +++ ./tw_osl.h Thu Apr 28 20:28:40 2005 @@ -71,6 +71,7 @@ /* Possible values of sc->state. */ #define TW_OSLI_CTLR_STATE_OPEN (1<<0) /* control device is open */ #define TW_OSLI_CTLR_STATE_SIMQ_FROZEN (1<<1) /* simq frozen */ +#define TW_OSLI_CTLR_STATE_POLLING (1<<2) /* polling for ctlr response */ = = #ifdef TW_OSL_DEBUG diff -u -r ../twa.cur/tw_osl_cam.c ./tw_osl_cam.c --- ../twa.cur/tw_osl_cam.c Fri Apr 8 12:43:57 2005 +++ ./tw_osl_cam.c Thu Apr 28 20:29:22 2005 @@ -482,6 +482,7 @@ struct twa_softc *sc =3D (struct twa_softc *)(cam_sim_softc(sim)); = tw_osli_dbg_dprintf(3, sc, "entering; sc =3D %p", sc); + sc->state |=3D TW_OSLI_CTLR_STATE_POLLING; if (tw_cl_interrupt(&(sc->ctlr_handle))) tw_cl_deferred_interrupt(&(sc->ctlr_handle)); tw_osli_dbg_dprintf(3, sc, "exiting; sc =3D %p", sc); diff -u -r ../twa.cur/tw_osl_freebsd.c ./tw_osl_freebsd.c --- ../twa.cur/tw_osl_freebsd.c Fri Apr 8 12:44:12 2005 +++ ./tw_osl_freebsd.c Thu Apr 28 20:31:25 2005 @@ -964,6 +964,8 @@ struct twa_softc *sc =3D (struct twa_softc *)arg; = tw_osli_dbg_dprintf(10, sc, "entered"); + if (sc->state & TW_OSLI_CTLR_STATE_POLLING) + return; if (tw_cl_interrupt(&(sc->ctlr_handle))) taskqueue_enqueue_fast(taskqueue_fast, &(sc->deferred_intr_callback)); From owner-freebsd-current@FreeBSD.ORG Fri Apr 29 04:13: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 D026116A4CE for ; Fri, 29 Apr 2005 04:13:25 +0000 (GMT) Received: from seven.Alameda.net (seven.alameda.net [64.81.53.71]) by mx1.FreeBSD.org (Postfix) with ESMTP id 28FDA43D54 for ; Fri, 29 Apr 2005 04:13:25 +0000 (GMT) (envelope-from ulf@Alameda.net) Received: by seven.Alameda.net (Postfix, from userid 1000) id 3C72E3A201; Thu, 28 Apr 2005 21:13:24 -0700 (PDT) Date: Thu, 28 Apr 2005 21:13:24 -0700 From: Ulf Zimmermann To: "M. Warner Losh" Message-ID: <20050429041323.GE24555@seven.alameda.net> References: <427196C0.5040506@chuckr.org> <42719BA0.5030901@samsco.org> <20050428.212803.78072573.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050428.212803.78072573.imp@bsdimp.com> Organization: Alameda Networks, Inc. X-Operating-System: FreeBSD 4.10-RELEASE-p2 User-Agent: Mutt/1.5.6i cc: chuckr@chuckr.org cc: FreeBSD-current@freebsd.org Subject: Re: tcsh X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: ulf@Alameda.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Apr 2005 04:13:26 -0000 On Thu, Apr 28, 2005 at 09:28:03PM -0600, M. Warner Losh wrote: > In message: <42719BA0.5030901@samsco.org> > Scott Long writes: > : Why does 'cd' have to be aliased? > > It doesn't. In historical csh implementations (eg, sunos 4, 4.2 or > 4.3 BSD) needed to alias cd to get the prompt set, but tcsh has indeed > obviated that need, with all the benefits that you describe. > > Warner I got two standard settings for tcsh: Depended on the TERM set: alias precmd 'echo -n "^[]2;$HOST^G"' And prompt: set prompt = '%B%m%b %n %C3 %# ' I do put the user in because of using more then myself and root. -- Regards, Ulf. --------------------------------------------------------------------- Ulf Zimmermann, 1525 Pacific Ave., Alameda, CA-94501, #: 510-865-0204 You can find my resume at: http://seven.Alameda.net/~ulf/resume.html From owner-freebsd-current@FreeBSD.ORG Fri Apr 29 06:01: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 DAB8316A4CF; Fri, 29 Apr 2005 06:01:35 +0000 (GMT) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0410B43D58; Fri, 29 Apr 2005 06:01:35 +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 j3T65jwP014889; Fri, 29 Apr 2005 09:05:45 +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 52902-09; Fri, 29 Apr 2005 09:01: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 j3T65iAN014886 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 Apr 2005 09:05:44 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.13.3/8.13.3) id j3T61hdS039570; Fri, 29 Apr 2005 09:01:43 +0300 (EEST) (envelope-from ru) Date: Fri, 29 Apr 2005 09:01:42 +0300 From: Ruslan Ermilov To: FreeBSD Tinderbox Message-ID: <20050429060142.GB39446@ip.net.ua> References: <20050428235901.209007306E@freebsd-current.sentex.ca> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="lEGEL1/lMxI0MVQ2" Content-Disposition: inline In-Reply-To: <20050428235901.209007306E@freebsd-current.sentex.ca> User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new at ip.net.ua cc: current@FreeBSD.ORG cc: i386@FreeBSD.ORG Subject: Re: [current tinderbox] failure on i386/pc98 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 29 Apr 2005 06:01:36 -0000 --lEGEL1/lMxI0MVQ2 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Apr 28, 2005 at 07:59:01PM -0400, FreeBSD Tinderbox wrote: > TB --- 2005-04-28 23:51:09 - tinderbox 2.3 running on freebsd-current.sen= tex.ca > TB --- 2005-04-28 23:51:09 - starting CURRENT tinderbox run for i386/pc98 > TB --- 2005-04-28 23:51:09 - checking out the source tree > TB --- 2005-04-28 23:51:09 - cd /home/tinderbox/CURRENT/i386/pc98 > TB --- 2005-04-28 23:51:09 - /usr/bin/cvs -f -R -q -d/home/ncvs update -P= d -A src > TB --- 2005-04-28 23:57:47 - building world (CFLAGS=3D-O2 -pipe) > TB --- 2005-04-28 23:57:47 - cd /home/tinderbox/CURRENT/i386/pc98/src > TB --- 2005-04-28 23:57: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 > [...] > =3D=3D=3D> sbin/growfs (cleandir) > =3D=3D=3D> sbin/gvinum (cleandir) > =3D=3D=3D> sbin/ifconfig (cleandir) > =3D=3D=3D> sbin/init (cleandir) > =3D=3D=3D> sbin/ip6fw (cleandir) > =3D=3D=3D> sbin/ipf (cleandir) > ".depend", line 299: Inconsistent operator for ipf > make: fatal errors encountered -- cannot continue > *** Error code 1 >=20 > Stop in /tinderbox/CURRENT/i386/pc98/src/sbin. > *** Error code 1 >=20 When what previously was a file (sbin/ipf/ipf) becomes a directory, the old .depend file gets in the way (SUBDIR's use the :: operator). Someone needs to remove the stale .depend file, or wipe out the obj directory completely, or this particular tinderbox will fail forever. Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --lEGEL1/lMxI0MVQ2 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFCcc3GqRfpzJluFF4RAguhAJ9dKMvRPRFOHM5sI4omeuvEceBYSgCbBAwb bo9t7djrEATba4fM6EeRSOU= =ZoZ4 -----END PGP SIGNATURE----- --lEGEL1/lMxI0MVQ2-- From owner-freebsd-current@FreeBSD.ORG Fri Apr 29 06:39: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 A993116A4CE; Fri, 29 Apr 2005 06:39:38 +0000 (GMT) Received: from www.mmlab.cse.yzu.edu.tw (www.mmlab.cse.yzu.edu.tw [140.138.150.166]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5E68643D53; Fri, 29 Apr 2005 06:39:38 +0000 (GMT) (envelope-from avatar@mmlab.cse.yzu.edu.tw) Received: by www.mmlab.cse.yzu.edu.tw (qmail, from userid 1000) id 9488E4EFCF4; Fri, 29 Apr 2005 14:39:36 +0800 (CST) Received: from localhost (localhost [127.0.0.1]) by www.mmlab.cse.yzu.edu.tw (qmail) with ESMTP id 8F8984EFCF3; Fri, 29 Apr 2005 14:39:36 +0800 (CST) Date: Fri, 29 Apr 2005 14:39:36 +0800 (CST) From: Tai-hwa Liang To: Ruslan Ermilov In-Reply-To: <20050429060142.GB39446@ip.net.ua> Message-ID: <05042914353210.37244@www.mmlab.cse.yzu.edu.tw> References: <20050428235901.209007306E@freebsd-current.sentex.ca> <20050429060142.GB39446@ip.net.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed cc: i386@FreeBSD.ORG cc: FreeBSD Tinderbox cc: current@FreeBSD.ORG Subject: Re: [current tinderbox] failure on i386/pc98 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 29 Apr 2005 06:39:38 -0000 On Fri, 29 Apr 2005, Ruslan Ermilov wrote: > On Thu, Apr 28, 2005 at 07:59:01PM -0400, FreeBSD Tinderbox wrote: >> TB --- 2005-04-28 23:51:09 - tinderbox 2.3 running on freebsd-current.sentex.ca >> TB --- 2005-04-28 23:51:09 - starting CURRENT tinderbox run for i386/pc98 >> TB --- 2005-04-28 23:51:09 - checking out the source tree >> TB --- 2005-04-28 23:51:09 - cd /home/tinderbox/CURRENT/i386/pc98 >> TB --- 2005-04-28 23:51:09 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src >> TB --- 2005-04-28 23:57:47 - building world (CFLAGS=-O2 -pipe) >> TB --- 2005-04-28 23:57:47 - cd /home/tinderbox/CURRENT/i386/pc98/src >> TB --- 2005-04-28 23:57: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 >> [...] >> ===> sbin/growfs (cleandir) >> ===> sbin/gvinum (cleandir) >> ===> sbin/ifconfig (cleandir) >> ===> sbin/init (cleandir) >> ===> sbin/ip6fw (cleandir) >> ===> sbin/ipf (cleandir) >> ".depend", line 299: Inconsistent operator for ipf >> make: fatal errors encountered -- cannot continue >> *** Error code 1 >> >> Stop in /tinderbox/CURRENT/i386/pc98/src/sbin. >> *** Error code 1 >> > When what previously was a file (sbin/ipf/ipf) becomes a directory, > the old .depend file gets in the way (SUBDIR's use the :: operator). > Someone needs to remove the stale .depend file, or wipe out the > obj directory completely, or this particular tinderbox will fail FWIW, removing the ipf directory under /usr/obj such like "rm -r /usr/obj/usr/src/sbin/ipf" did the trick for me. > forever. -- Cheers, Tai-hwa Liang From owner-freebsd-current@FreeBSD.ORG Fri Apr 29 06:57: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 326A116A4CE; Fri, 29 Apr 2005 06:57:41 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id A2E8E43D49; Fri, 29 Apr 2005 06:57:40 +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.3/8.13.3) with ESMTP id j3T71hrc027751; Fri, 29 Apr 2005 01:01:43 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <4271DAD6.3000904@samsco.org> Date: Fri, 29 Apr 2005 00:57:26 -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: Vinod Kashyap 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 cc: "Bjoern A. Zeeb" Subject: Re: Problem with twa in HEAD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 29 Apr 2005 06:57:41 -0000 Vinod Kashyap wrote: > >>-----Original Message----- >>From: Bjoern A. Zeeb [mailto:bz@FreeBSD.org] >>Sent: Tuesday, April 26, 2005 3:26 AM >>To: Vinod Kashyap >>Subject: RE: Problem with twa in HEAD >> >> >>On Mon, 25 Apr 2005, Vinod Kashyap wrote: >> >>Hi, >> >> >>>>-----Original Message----- >>>>From: Bjoern A. Zeeb [mailto:bz@FreeBSD.org] >>>>Sent: Monday, April 25, 2005 6:45 AM >>>>To: Vinod Kashyap >>>>Subject: Re: Problem with twa in HEAD >>>> >>>> >>>>On Fri, 22 Apr 2005, Bjoern A. Zeeb wrote: >>>> >>>>Hi, >>>> >>>> >>>>>scottl redirected me to you. >>>>> >>>>>I am currently debugging "hangs" on reboot and shutdown on a >>>>>SMP machine with 12 discs at a >>>>> >>>>>3ware device driver for 9000 series storage controllers, >>>> >>>>version: 3.60.00.016 >>>> >>>>>twa0: <3ware 9000 series Storage Controller> port >>>> >>>>0x9800-0x98ff mem 0xfe8ffc00-0xfe8ffcff,0xfb800000-0xfbffffff >>>>irq 28 at device 6.0 on pci3 >>>> >>>>>twa0: [FAST] >>>>>twa0: INFO: (0x15: 0x1300): Controller details:: 12 ports, >>>> >>>>Firmware FE9X 2.06.00.009, BIOS BE9X 2.03.01.051 >>>> >>>>> >>>>>What I know so far is that Giant is held by sync. >>>>> >>>>>Things a "spinning" in cam/cam_xpt.c around: >>>>> >>>>>--- cam_xpt.c 31 Mar 2005 21:42:49 -0000 1.152 >>>>>+++ cam_xpt.c 22 Apr 2005 18:42:43 -0000 >>>>>@@ -3643,6 +3643,7 @@ xpt_polled_action(union ccb *start_ccb) >>>>> != CAM_REQ_INPROG) >>>>> break; >>>>> DELAY(1000); >>>>> printf("XXX status=%02x\n", >>>> >>>>start_ccb->ccb_h.status); >>>> >>>>> } >>>>> if (timeout == 0) { >>>>> /* >>>>> >>>>> >>>>>with status being 0x200. >>>>> >>>>>Seems the twa has a command stuck in it. >>>>> >>>>>I have seen the comment in dev/twa/tw_osl_cam.c ~ line 253 about >>>>>queuing and CAM_SIM_QUEUED but I don't know enough about cam. >>>>>I seems no all patchs out of this functions seem to >> >>clear that from >> >>>>>status? >>>>> >>>>>Any help apreaciated ;) I can try patches; as long as I >> >>can break >> >>>>>to db> to reboot. >>>> >>>>further debugging shows that is seems to be spinning in twa_poll. >>>>see debug output from TWA_DEBUG 3. The problem is that at >> >>this point >> >>>>I am no longer able to break to debugger. >>>> >>>>twa0: tw_osli_execute_scsi: XPT_SCSI_IO: Single virtual address! >>>>twa0: tw_osli_execute_scsi: XPT_SCSI_IO: Single virtual address! >>>>unmount of /dev failed (BUSY) >>>>twa0: tw_osli_execute_scsi: XPT_SCSI_IO: Single virtual address! >>>>twa0: tw_osli_execute_scsi: XPT_SCSI_IO: Single virtual address! >>>>Uptime: 2m57s >>>>twa0: tw_osli_execute_scsi: XPT_SCSI_IO: Single virtual address! >>>>twa0: twa_poll: entering; sc = 0xc57bb200 >>>>twa0: twa_poll: exiting; sc = 0xc57bb200 >>>>twa0: twa_poll: entering; sc = 0xc57bb200 >>>>twa0: twa_poll: exiting; sc = 0xc57bb200 >>>>twa0: twa_poll: entering; sc = 0xc57bb200 >>>>twa0: twa_poll: exiting; sc = 0xc57bb200 >>>>twa0: twa_poll: entering; sc = 0xc57bb200 >>>>twa0: twa_poll: exiting; sc = 0xc57bb200 >>>>twa0: twa_poll: entering; sc = 0xc57bb200 >>>>twa0: twa_poll: exiting; sc = 0xc57bb200 >>>>twa0: twa_poll: entering; sc = 0xc57bb200 >>>>twa0: twa_poll: exiting; sc = 0xc57bb200 >>>>twa0: twa_poll: entering; sc = 0xc57bb200 >>>>twa0: twa_poll: exiting; sc = 0xc57bb200 >>>>... >>>> >>> >>>I am in the middle of an office move right now. >>>I will get back to you once I have some time to look into this. >> >> >>thanks for the information; I'll be able to test at least until end of >>this week and hopefully next week too. >> > > > I looked into this, and this is what is happening: > On reboot/halt, the following function calling sequence happens: > ... --> dashutdown --> xpt_polled_action --> twa_poll. > But, the interrupt handler in twa is still active at this time, > since twa_detach/twa_shutdown hasn't been called yet. Before > twa_poll can fetch the response for the posted command, the ISR > gets called when the firmware posts the response. The ISR clears > the interrupt bit on the controller, registers a taskqueue handler like > it always does, and exits. Meanwhile, xpt_polled_action continues > to call twa_poll, which cannot determine that the command has completed, > since the interrupt bit on the controller is already cleared. So, > we get into a (near) never-ending loop (the timeout for scsi_synchronize_cache, > which is what is being tried here, is, for whatever reason, 60 minutes, > and so, the system is as good as hung). > > Now, does anyone know why xpt_polled_action is being called from > dashutdown, even before the ISR has been unregistered (via twa_detach)? > > Bjoern, this patch should work-around your problem, although it's not > the fix. Also, it still leaves a window for the race condition described > above. > xpt_polled_action() expects that it can simulate interrupts by calling the driver poll vector, and that by calling it enough times the driver will eventually complete all the outstanding I/O it has. As you note, it'll repeat this for a very long time. So the question is then why the twa driver isn't completing the outstanding I/O. If I were you I'd remove the call to tw_cl_interrupt() in twa_poll() and just unconditionally call tw_cl_deferred_interrupt() and have it check everything. The locking here (and in twa_pci_intr()) is flawed anyways, you have a race between when tw_cl_interrupt() drops its lock right before return and when you check it's return value. I'd like say that it's harmless, except that you expect to pass state from one function to the next, so the race is a real one. It's likely why this case is failing. An ideal FAST handler should only clear the hardware interrupt register and launch the appropriate handlers, it shouldn't try to pass state to the handlers. Look at aac for an example here, but also please recall that I've already discouraged you from using a a fast handler plus taskqueue for this driver. If your taskqueue handlers need state from when the interrupt was cleared, then they simply aren't a good candidate for this model. Scott From owner-freebsd-current@FreeBSD.ORG Fri Apr 29 07:01: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 B28A016A4CE; Fri, 29 Apr 2005 07:01:00 +0000 (GMT) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7687743D2F; Fri, 29 Apr 2005 07:00:59 +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 j3T759NJ018147; Fri, 29 Apr 2005 10:05:09 +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 55080-17; Fri, 29 Apr 2005 10:00:57 +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 j3T759n2018144 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 Apr 2005 10:05:09 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.13.3/8.13.3) id j3T7177k039968; Fri, 29 Apr 2005 10:01:07 +0300 (EEST) (envelope-from ru) Date: Fri, 29 Apr 2005 10:01:07 +0300 From: Ruslan Ermilov To: Tai-hwa Liang Message-ID: <20050429070107.GB39886@ip.net.ua> References: <20050428235901.209007306E@freebsd-current.sentex.ca> <20050429060142.GB39446@ip.net.ua> <05042914353210.37244@www.mmlab.cse.yzu.edu.tw> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="6sX45UoQRIJXqkqR" Content-Disposition: inline In-Reply-To: <05042914353210.37244@www.mmlab.cse.yzu.edu.tw> User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new at ip.net.ua cc: i386@FreeBSD.ORG cc: FreeBSD Tinderbox cc: current@FreeBSD.ORG Subject: Re: [current tinderbox] failure on i386/pc98 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 29 Apr 2005 07:01:00 -0000 --6sX45UoQRIJXqkqR Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Apr 29, 2005 at 02:39:36PM +0800, Tai-hwa Liang wrote: [...] > >When what previously was a file (sbin/ipf/ipf) becomes a directory, > >the old .depend file gets in the way (SUBDIR's use the :: operator). > >Someone needs to remove the stale .depend file, or wipe out the > >obj directory completely, or this particular tinderbox will fail >=20 > FWIW, removing the ipf directory under /usr/obj such like > "rm -r /usr/obj/usr/src/sbin/ipf" did the trick for me. >=20 Yes, this is the way to go, just removing .depend won't do it (as there will still be "ipf" file under objdir for what should now be a directory). Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --6sX45UoQRIJXqkqR Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFCcduzqRfpzJluFF4RAsEAAJ9aJGapwtV0ih017WLLkURAABr5VACcCgNQ K0VlvP1RokkzYd6HsJBfriM= =fwB/ -----END PGP SIGNATURE----- --6sX45UoQRIJXqkqR-- From owner-freebsd-current@FreeBSD.ORG Fri Apr 29 07:01: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 959A816A4CE for ; Fri, 29 Apr 2005 07:01:24 +0000 (GMT) Received: from blackwater.lemis.com (wantadilla.lemis.com [192.109.197.135]) by mx1.FreeBSD.org (Postfix) with ESMTP id 97F7143D48 for ; Fri, 29 Apr 2005 07:01:23 +0000 (GMT) (envelope-from grog@lemis.com) Received: by blackwater.lemis.com (Postfix, from userid 1004) id 5FE6485A9A; Fri, 29 Apr 2005 16:31:22 +0930 (CST) Date: Fri, 29 Apr 2005 16:31:22 +0930 From: Greg 'groggy' Lehey To: Jonathan Gray , freebsd-current@freebsd.org Message-ID: <20050429070122.GN70593@wantadilla.lemis.com> References: <20050428154859.GA16433@mail.netspace.net.au> <20050428162322.GE747@empiric.icir.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="e890kymSckUvwzhr" Content-Disposition: inline In-Reply-To: <20050428162322.GE747@empiric.icir.org> User-Agent: Mutt/1.4.2.1i Organization: The FreeBSD Project Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.FreeBSD.org/ X-PGP-Fingerprint: 9A1B 8202 BCCE B846 F92F 09AC 22E6 F290 507A 4223 Subject: Re: incorrect statement on www page X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 29 Apr 2005 07:01:24 -0000 --e890kymSckUvwzhr Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thursday, 28 April 2005 at 17:23:22 +0100, Bruce M Simpson wrote: > On Fri, Apr 29, 2005 at 01:48:59AM +1000, Jonathan Gray wrote: >> I came across the following incorrect statement when >> browsing http://www.freebsd.org >> >> "FreeBSD is available free of charge and comes with full source code" >> >> Sadly I do not think this has been true for some time. > > I disagree; the wording isn't misleading. However, to address such concerns, > it might be better worded as "comes with full source code, and also ships > with some binary driver components". A more accurate statement might be: "FreeBSD is available free of charge and comes with full source code. In addition, many third-party drivers are available, some in source, others in binary-only format". The important thing is that the FreeBSD project is not withholding *any* source code. The only binary-only components are from other people who don't allow distribution of *their* source. Greg -- See complete headers for address and phone numbers. --e890kymSckUvwzhr Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFCcdvCIubykFB6QiMRAkngAJ9KOequ/1E0Jum2gwiQr8WVq2aRyQCeMDMQ 5BIqRDPzQwacTz4rTh3Oqf8= =FPbM -----END PGP SIGNATURE----- --e890kymSckUvwzhr-- From owner-freebsd-current@FreeBSD.ORG Fri Apr 29 07:13: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 3262E16A4CE for ; Fri, 29 Apr 2005 07:13:18 +0000 (GMT) Received: from ferengi.borderworlds.dk (ferengi.borderworlds.dk [80.166.152.7]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6810343D1F for ; Fri, 29 Apr 2005 07:13:17 +0000 (GMT) (envelope-from xi@borderworlds.dk) Received: from borg.borderworlds.dk (localhost [127.0.0.1]) by ferengi.borderworlds.dk (Postfix) with ESMTP id 8415FB841 for ; Fri, 29 Apr 2005 09:13:15 +0200 (CEST) Received: by borg.borderworlds.dk (Postfix, from userid 1001) id 5031711431; Fri, 29 Apr 2005 09:13:15 +0200 (CEST) Sender: xi@borderworlds.dk To: freebsd-current@freebsd.org References: <57436.216.177.243.42.1114582155.localmail@webmail.dnswatch.com> <6.1.0.6.2.20050426233321.084e9210@cobalt.antimatter.net> <51899.216.177.243.42.1114584317.localmail@webmail.dnswatch.com> <6.1.0.6.2.20050427001118.0327cd50@cobalt.antimatter.net> <52515.216.177.243.42.1114586501.localmail@webmail.dnswatch.com> <61359.216.177.243.35.1114722481.localmail@webmail.dnswatch.com> <20050428183303.E59099@lexi.siliconlandmark.com> <53955.216.177.243.35.1114729568.localmail@webmail.dnswatch.com> From: Christian Laursen Date: 29 Apr 2005 09:13:15 +0200 In-Reply-To: <53955.216.177.243.35.1114729568.localmail@webmail.dnswatch.com> Message-ID: <863btam4xg.fsf@borg.borderworlds.dk> Lines: 12 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: boot banner project 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: Fri, 29 Apr 2005 07:13:18 -0000 "/dev/null" writes: > You have a color one?! Where do you get it? I only have a white ASCII one. Put loader_color="YES" in /boot/loader.conf. :) -- Christian Laursen From owner-freebsd-current@FreeBSD.ORG Fri Apr 29 07:19: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 3ACFF16A4CE; Fri, 29 Apr 2005 07:19:11 +0000 (GMT) Received: from mail.netspace.net.au (whirlwind.netspace.net.au [203.10.110.76]) by mx1.FreeBSD.org (Postfix) with ESMTP id B1D1843D48; Fri, 29 Apr 2005 07:19:10 +0000 (GMT) (envelope-from jsg@goblin.cx) Received: from carla.home (dsl-210-15-216-215.VIC.netspace.net.au [210.15.216.215]) by mail.netspace.net.au (Postfix) with ESMTP id 0A37D10FF24; Fri, 29 Apr 2005 17:19:09 +1000 (EST) Received: from carla.home (jsg@localhost.home [127.0.0.1]) by carla.home (8.13.4/8.13.1) with ESMTP id j3T7J8Rw017036; Fri, 29 Apr 2005 17:19:08 +1000 (EST) Received: (from jsg@localhost) by carla.home (8.13.4/8.13.1/Submit) id j3T7J7Ts024891; Fri, 29 Apr 2005 17:19:07 +1000 (EST) Date: Fri, 29 Apr 2005 17:19:07 +1000 From: Jonathan Gray To: "Greg 'groggy' Lehey" Message-ID: <20050429071907.GA13459@mail.netspace.net.au> References: <20050428154859.GA16433@mail.netspace.net.au> <20050428162322.GE747@empiric.icir.org> <20050429070122.GN70593@wantadilla.lemis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050429070122.GN70593@wantadilla.lemis.com> User-Agent: Mutt/1.5.8i cc: freebsd-current@FreeBSD.org Subject: Re: incorrect statement on www page X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 29 Apr 2005 07:19:11 -0000 On Fri, Apr 29, 2005 at 04:31:22PM +0930, Greg 'groggy' Lehey wrote: > On Thursday, 28 April 2005 at 17:23:22 +0100, Bruce M Simpson wrote: > > On Fri, Apr 29, 2005 at 01:48:59AM +1000, Jonathan Gray wrote: > >> I came across the following incorrect statement when > >> browsing http://www.freebsd.org > >> > >> "FreeBSD is available free of charge and comes with full source code" > >> > >> Sadly I do not think this has been true for some time. > > > > I disagree; the wording isn't misleading. However, to address such concerns, > > it might be better worded as "comes with full source code, and also ships > > with some binary driver components". > > A more accurate statement might be: > > "FreeBSD is available free of charge and comes with full source > code. In addition, many third-party drivers are available, some in > source, others in binary-only format". > > The important thing is that the FreeBSD project is not withholding > *any* source code. The only binary-only components are from other > people who don't allow distribution of *their* source. If these binary only components come with FreeBSD they are part of FreeBSD as far as most people are concerned. There are binary components with no publically available source code in FreeBSD, so it is not full source code. Additionally supporting such things hinders progress on acceptable alternatives be they drivers with full source or use of other vendors. From owner-freebsd-current@FreeBSD.ORG Fri Apr 29 07:32: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 02E1916A4CE for ; Fri, 29 Apr 2005 07:32:51 +0000 (GMT) Received: from mx01.stofanet.dk (mx01.stofanet.dk [212.10.10.11]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1202B43D55 for ; Fri, 29 Apr 2005 07:32:50 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from d40a2021.rev.stofanet.dk ([212.10.32.33] helo=critter.freebsd.dk) by mx01.stofanet.dk (envelope-from ) with esmtp id 1DRPzT-0005Um-0F for freebsd-current@freebsd.org; Fri, 29 Apr 2005 09:32:48 +0200 Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.3/8.13.3) with ESMTP id j3T7Wj6Y004938 for ; Fri, 29 Apr 2005 09:32:46 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: freebsd-current@freebsd.org From: "Poul-Henning Kamp" In-Reply-To: Your message of "Fri, 29 Apr 2005 17:19:07 +1000." <20050429071907.GA13459@mail.netspace.net.au> Date: Fri, 29 Apr 2005 09:32:45 +0200 Message-ID: <4937.1114759965@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Subject: Re: incorrect statement on www page X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 29 Apr 2005 07:32:51 -0000 One can't help the feeling that the projects resources could be used wiser than for a thread like this nor indeed if the instigator of this particular nitpicking has an agenda different from the advancement of FreeBSD. If we really should enforce the proposed level of "truth in advertising" then no operating system since Brink-Hansens RC4000 monitor could ever dare use the word "stable" about themselves since they have not been stringently proven to be free from deadlocks. Or how about the word "complete" ? We cannot possibly call FreeBSD "complete" when it doesn't support X.400 email exchange over X.75 transport on X.21 connection based service can we ? And there is no bolted on browser, something the US courts have ruled is a legitimate and necessary part of an operating system. And are we really "an operating system" if we look through the due diligence microscope ? Don't we run the risk of deceiving the unsuspecting user when we ship with /usr/games ? That is not really part of an operating system, that is part of an home entertainment system, isn't it ? I guess need to make the description somewhat like this: FreeBSD is the best[1] damn[2] UNIX[3] on the planet[4].[5][6][7]. [1] Your perception may be different if it is different from ours. [2] Void where prohibited. [3] Only we can't pay for the protection money to call ourselves that. [4] Nothing in this statement should be read or construed to mean that FreeBSD is not also superior outside this biosphere of the third planet from the star "Sol". [5] This statement contains forward and backward looking projections and we can't be bothered to state that this obviously means that it may not be true everywhere and forever. [6] The use of the word "planet" should not be seen as a position in fiercely heated argument about the flat vs. round Earth theories. [7] God[8] This is silly, isn't it ? [8] Pick one, anyone, or none, we don't care. -- 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 Fri Apr 29 07:56: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 90A2516A4CE for ; Fri, 29 Apr 2005 07:56:51 +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 E5A9B43D46 for ; Fri, 29 Apr 2005 07:56:50 +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]) j3T7ufnm001516 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 29 Apr 2005 17:56:42 +1000 Received: from cirb503493.alcatel.com.au (localhost.alcatel.com.au [127.0.0.1])j3T7ufXw003170; Fri, 29 Apr 2005 17:56:41 +1000 (EST) (envelope-from pjeremy@cirb503493.alcatel.com.au) Received: (from pjeremy@localhost)j3T7ueAe003169; Fri, 29 Apr 2005 17:56:40 +1000 (EST) (envelope-from pjeremy) Date: Fri, 29 Apr 2005 17:56:40 +1000 From: Peter Jeremy To: /dev/null Message-ID: <20050429075640.GB232@cirb503493.alcatel.com.au> References: <57775.216.177.243.35.1114633009.localmail@webmail.dnswatch.com> <20050427204939.GA796@uk.tiscali.com> <53015.216.177.243.35.1114635611.localmail@webmail.dnswatch.com> <20050427212835.GA87673@uk.tiscali.com> <64018.216.177.243.35.1114641057.localmail@webmail.dnswatch.com> <42701D35.6020307@gmail.com> <42703671.8060707@attglobal.net> <59642.216.177.243.35.1114655240.localmail@webmail.dnswatch.com> <20050428082931.GA232@cirb503493.alcatel.com.au> <54623.216.177.243.35.1114717482.localmail@webmail.dnswatch.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54623.216.177.243.35.1114717482.localmail@webmail.dnswatch.com> User-Agent: Mutt/1.4.2i cc: freebsd-current@freebsd.org Subject: Re: can't build kernel [with CONFIG this time][[[FIXED]]] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 29 Apr 2005 07:56:51 -0000 On Thu, 2005-Apr-28 12:44:42 -0700, /dev/null wrote: >Good point(s). I sure wish I could just use 1 giant can capacitor that >simply fills as required and releases as necessary. That won't work - there's too much inductance between (and inside) the giant can capacitor and the electronics. The bypasses that matter for logic transitions are the surface-mount chip ceramics that are on the RAM stick, on the CPU carrier and next to (under) the northbridge. >simpler. On a sad note, after a long period of usage it still fails. So >it seems that the new CPU is the culprit (CPU's cache?). Anyway, I might >disable the CPU's cache in the bios settings and see what happens, while >I wait for another CPU. Try under-clocking a bit, or using more conservative memory timings (especially if you've set you motherboard to "aggressive" timings). -- Peter Jeremy From owner-freebsd-current@FreeBSD.ORG Fri Apr 29 08:02: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 C826416A4CE for ; Fri, 29 Apr 2005 08:02:09 +0000 (GMT) Received: from fast.dnswatch.com (fast.dnswatch.com [216.177.243.43]) by mx1.FreeBSD.org (Postfix) with ESMTP id E0AE943D46 for ; Fri, 29 Apr 2005 08:02:08 +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 j3T823rt013897; Fri, 29 Apr 2005 01:02:08 -0700 (PDT) (envelope-from null@dnswatch.com) Received: (from www@localhost) by fast.dnswatch.com (8.12.6/8.12.6/Submit) id j3T821U0013896; Fri, 29 Apr 2005 01:02:01 -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; Fri, 29 Apr 2005 01:02:01 -0700 (PDT) Message-ID: <60093.216.177.243.35.1114761721.localmail@webmail.dnswatch.com> In-Reply-To: <20050429005319.GA17799@laptoxa.toxa.lan> References: <57436.216.177.243.42.1114582155.localmail@webmail.dnswatch.com><426FDE69.8090909@samsco.org> <426FE1EA.7020900@kutulu.org><20050428105348.GA8056@laptoxa.toxa.lan> <4270E7F1.9010502@kutulu.org> <20050429005319.GA17799@laptoxa.toxa.lan> Date: Fri, 29 Apr 2005 01:02:01 -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 cc: Toxa Subject: Re: boot banner project X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 29 Apr 2005 08:02:09 -0000 > On Thu, Apr 28, 2005 at 09:41:05AM -0400, Mike Edenfield wrote: >> >> 1) It is far from a stupid idea if even one person honestly feels it >> would be a benefit. No need to be abusive about it. > > Yes, I have to mention this was only my humble opinion. > >> >> 2) If I were to choose to work on FreeBSD, I would be free to work on >> whatever I felt was lacking. That's how it works. Especially given >> that I have nowhere near enough skill in C to work on more complex >> system-level issues. > > Yes, you can do whatewer you want. But what about the result? I think > several hundreds lines of lolypop-boot-related code will definitively > NOT bring FreeBSD more cleaness and design simpleness. And that's > everyone likes in > BSDs! "And that's everyone likes in BSD's" WOW! Were you elected Official Spokesperson for everyone? ;) >> >> 3) I was merely making suggestions as to what alternatives were >> available. Since almost every Linux distro does something similar to >> this proposal, there is obviously SOME merit to it; the benefit may be >> miniscule, or irrelevant to many people, but it still exists. >> > > See my opinion above. It's a bad, BAD style, to add features till > then they're really necessary and desirable. IMHO. See my opinion of your deciding to decide my opinion above. ;) I might also add that if it is *your* opinion that it should not be added. Then I would suggest to you that you simply *not* add it to your own installation. In short; an addon is simply that - an addon. You don't like it? don't add it. :) No "sour grapes" here. Just felt the need to chime in. -Chris > > _______________________________________________ > 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 Fri Apr 29 08:19: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 75ACE16A4CE for ; Fri, 29 Apr 2005 08:19:59 +0000 (GMT) Received: from fast.dnswatch.com (fast.dnswatch.com [216.177.243.43]) by mx1.FreeBSD.org (Postfix) with ESMTP id 03C1143D39 for ; Fri, 29 Apr 2005 08:19:59 +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 j3T8Jrrt014135; Fri, 29 Apr 2005 01:19:57 -0700 (PDT) (envelope-from null@dnswatch.com) Received: (from www@localhost) by fast.dnswatch.com (8.12.6/8.12.6/Submit) id j3T8JqCE014134; Fri, 29 Apr 2005 01:19:53 -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; Fri, 29 Apr 2005 01:19:51 -0700 (PDT) Message-ID: <52053.216.177.243.35.1114762792.localmail@webmail.dnswatch.com> In-Reply-To: <427196C0.5040506@chuckr.org> References: <427196C0.5040506@chuckr.org> Date: Fri, 29 Apr 2005 01:19:51 -0700 (PDT) From: "/dev/null" To: "Chuck Robey" , 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: tcsh X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 29 Apr 2005 08:19:59 -0000 > The first thing I do, after I've installed a new system (just before I > copy over the ssh data) is to copy my .cshrc to my home dir. What's so > important? I really like the two statements, which I show below, which > give me my prompt: > > set prompt="%m:%{^[[34m%}`id -nu`%{^[[0m%}:%~:%{^[[31m#%h^[[0m%}%#" > alias cd 'cd \!*;set prompt="%m%{^[[32m%}:`id > -nu`%{^[[0m%}:%~:%{^[[31m#%h^[[0m%}%#"' > FWIW here's mine: set prompt = "\n%~\n%t\n%d, %D `/bin/hostname -s`# " Short and sweet. As you can see it leaves little doubt as to where I am or what day and time it is. -Chris > My mailer is adding carriage returns to the cd line, maybe even to the > prompt line, live with it. > > Any chance that something so basic as this, that improves things so > awfully much, could be added to the .tcshrc? If the idea is liked well > enough, I will edit it enough so that the special use of prompt strings > that are specific to tcsh is made conditional. > _______________________________________________ > 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 Fri Apr 29 08:35: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 5124816A4CE for ; Fri, 29 Apr 2005 08:35:00 +0000 (GMT) Received: from fast.dnswatch.com (fast.dnswatch.com [216.177.243.43]) by mx1.FreeBSD.org (Postfix) with ESMTP id A455143D53 for ; Fri, 29 Apr 2005 08:34:59 +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 j3T8Yurt014234; Fri, 29 Apr 2005 01:34:59 -0700 (PDT) (envelope-from null@dnswatch.com) Received: (from www@localhost) by fast.dnswatch.com (8.12.6/8.12.6/Submit) id j3T8YtxM014233; Fri, 29 Apr 2005 01:34:55 -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; Fri, 29 Apr 2005 01:34:55 -0700 (PDT) Message-ID: <55682.216.177.243.35.1114763695.localmail@webmail.dnswatch.com> In-Reply-To: References: <57436.216.177.243.42.1114582155.localmail@webmail.dnswatch.com> <6.1.0.6.2.20050426233321.084e9210@cobalt.antimatter.net> <51899.216.177.243.42.1114584317.localmail@webmail.dnswatch.com> <6.1.0.6.2.20050427001118.0327cd50@cobalt.antimatter.net> <52515.216.177.243.42.1114586501.localmail@webmail.dnswatch.com> <61359.216.177.243.35.1114722481.localmail@webmail.dnswatch.com> Date: Fri, 29 Apr 2005 01:34:55 -0700 (PDT) From: "/dev/null" To: "John Sconiers" , 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: boot banner project X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 29 Apr 2005 08:35:00 -0000 > Well I don't believe it sucks. It's a good project. I'm also working > on a few projects that hopefully will add a few frills like linux. I > for enjoy Red Hat's boot: > > mounting file systems ok > network ok > Mysql failed > > etc etc. The one thing you should keep in mind is that a lot of > people who use freebsd don't care about the "frills" that linux has > added. However what they fail to realize is that it attracts and > keeps users. I have been around FreeBSD for a long time > ...almost....10 years...started as an admin. I had to install some > linux servers for work. I was impressed. The last time I used linux > was redhat 6.x. Until we start adding the "frills" especially ones > that are realatively easy (or seem easy) to do as well as disable we > will never have the user base. I'm actually about to star work on > these linux "frils" projects: > > 1. Adding full read/write / nfs support for reiserfs 4 > 2. Total rewrite of sysinstall to be like Red Hat's Anaconda (graphical) For ppl that have never installed FBSD b4 I think a GUI installer is a must. But personally, the *only* thing I would change in the current installer is better cursor handling. OK maybe I would also add a refresh button - I hate it when the screen gets trashed from some console message. > 3. FreeBSD Update (ala Red hat update / Windows update) It's already available in the 5x series (and late 4?). It's called portaudit and is the *BEST* implimentation for any OS I have ever used. A "must have" for any FBSD user. Look in the ports/security section of your local installation. > 4. GUI Kernel configurator > 5. GUI port manager (add / delete ports) There are a few incarnations of this(ese) already available depending of your windowmanager/ console choice. > 6. Other Small System enhancements > > If you want maybe we could create a group who's purpose is to create > system enhancements......let's come up with some projects work on them > and see if they are willing to commit them ........ think about it. Not to sound as if I'm shunning you, but I think we're already in one - this group, no? :) I'll give it some thought. -Chris > > > On 4/28/05, /dev/null wrote: >> Hello, >> As this is an RFC (I'm sure you already know that). >> >> Long answer: >> I'm not quite sure. It will depend on the amount and content >> of the comments. Technically, it may not start ever (because >> everyone/ or nearly everyone says it SUX). >> >> Short answer: >> Too early for me to say. >> >> _Chris >> >> > When are you starting the project? >> > //////////////////////////////////////////////////// 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 Fri Apr 29 08: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 A773516A4CE for ; Fri, 29 Apr 2005 08:51:20 +0000 (GMT) Received: from arginine.spc.org (arginine.spc.org [83.167.185.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 122A743D64 for ; Fri, 29 Apr 2005 08:51:20 +0000 (GMT) (envelope-from bms@spc.org) Received: from localhost (localhost [127.0.0.1]) by arginine.spc.org (Postfix) with ESMTP id CD2FC6520E; Fri, 29 Apr 2005 09:50: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 35632-03-2; Fri, 29 Apr 2005 09:50:25 +0100 (BST) Received: from empiric.dek.spc.org (82-35-116-62.cable.ubr07.dals.blueyonder.co.uk [82.35.116.62]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by arginine.spc.org (Postfix) with ESMTP id 5DC596520C; Fri, 29 Apr 2005 09:50:24 +0100 (BST) Received: by empiric.dek.spc.org (Postfix, from userid 1001) id 4938E623B; Fri, 29 Apr 2005 09:51:13 +0100 (BST) Date: Fri, 29 Apr 2005 09:51:13 +0100 From: Bruce M Simpson To: Chuck Robey Message-ID: <20050429085113.GF789@empiric.icir.org> Mail-Followup-To: Chuck Robey , current References: <427196C0.5040506@chuckr.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <427196C0.5040506@chuckr.org> cc: current Subject: Re: tcsh X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 29 Apr 2005 08:51:20 -0000 On Fri, Apr 29, 2005 at 02:06:56AM +0000, Chuck Robey wrote: > Any chance that something so basic as this, that improves things so > awfully much, could be added to the .tcshrc? If the idea is liked well > enough, I will edit it enough so that the special use of prompt strings > that are specific to tcsh is made conditional. Might be better to use cwdcmd: (from bms .tcshrc) %%% # Update rxvt title bar and icon when changing directory alias cwdcmd 'echo -n "\033]2;${HOST}:$cwd - tcsh\007\033]1;tcsh\007"' cwdcmd # Force update upon ~/.tcshrc # reload. set promptchars='%#' # [un]privileged user shell prompt characters set prompt="%B%m:%.06%b %# " # host:cwd with bold and relative to $HOME set ellipsis # ellipsize after depth of 6 elements %%% I tried to do the same with jobcmd once (update title bar when running foreground jobs) but had problems with the shell trying to tell when it was back in interactive mode. Also, to update the title bar after an ssh session running in the foreground terminates, some additional work (and possibly patches) would be needed. Regards, BMS From owner-freebsd-current@FreeBSD.ORG Fri Apr 29 09:09: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 0D24516A4CE for ; Fri, 29 Apr 2005 09:09:43 +0000 (GMT) Received: from orb.pobox.com (orb.pobox.com [207.8.226.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 82B0A43D41 for ; Fri, 29 Apr 2005 09:09:42 +0000 (GMT) (envelope-from discussion-lists@linnet.org) Received: from orb (localhost [127.0.0.1]) by orb.pobox.com (Postfix) with ESMTP id EBD6D890; Fri, 29 Apr 2005 05:09:38 -0400 (EDT) Received: from thinkdog.local.linnet.org (host217-40-157-153.in-addr.btopenworld.com [217.40.157.153]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by orb.sasl.smtp.pobox.com (Postfix) with ESMTP id 853C08F; Fri, 29 Apr 2005 05:09:36 -0400 (EDT) Received: from lists by thinkdog.local.linnet.org with local (Exim 4.43 (FreeBSD)) id 1DRRUt-000Nzq-Cn; Fri, 29 Apr 2005 10:09:19 +0100 Date: Fri, 29 Apr 2005 10:09:19 +0100 From: Brian Candler To: /dev/null Message-ID: <20050429090919.GA92159@uk.tiscali.com> References: <57436.216.177.243.42.1114582155.localmail@webmail.dnswatch.com> <6.1.0.6.2.20050426233321.084e9210@cobalt.antimatter.net> <51899.216.177.243.42.1114584317.localmail@webmail.dnswatch.com> <6.1.0.6.2.20050427001118.0327cd50@cobalt.antimatter.net> <52515.216.177.243.42.1114586501.localmail@webmail.dnswatch.com> <61359.216.177.243.35.1114722481.localmail@webmail.dnswatch.com> <55682.216.177.243.35.1114763695.localmail@webmail.dnswatch.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55682.216.177.243.35.1114763695.localmail@webmail.dnswatch.com> User-Agent: Mutt/1.4.2.1i cc: freebsd-current@freebsd.org cc: John Sconiers Subject: Re: boot banner project X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 29 Apr 2005 09:09:43 -0000 On Fri, Apr 29, 2005 at 01:34:55AM -0700, /dev/null wrote: > > 2. Total rewrite of sysinstall to be like Red Hat's Anaconda (graphical) > For ppl that have never installed FBSD b4 I think a GUI installer is a > must. But personally, the *only* thing I would change in the current > installer is better cursor handling. OK maybe I would also add a refresh > button - I hate it when the screen gets trashed from some console message. Have you looked at http://www.bsdinstaller.org/ ? I've only looked at the web site, haven't tried it. But it looks like a cool idea: separating out the installer functionality from the user interface, so that you can easily plug in new interfaces (they have a CGI frontend already). It might save re-inventing the wheel. > > 3. FreeBSD Update (ala Red hat update / Windows update) > It's already available in the 5x series (and late 4?). It's called > portaudit and is the *BEST* implimentation for any OS I have ever used. > A "must have" for any FBSD user. Look in the ports/security section of > your local installation. According to pkg-descr: "portaudit provides a system to check if installed ports are listed in a database of published security vulnerabilities. After installation it will update this security database automatically and include its reports in the output of the daily security run." This doesn't sound like an updater of any sort. There's "portupgrade", but of course that only handles software in the ports collection, not the O/S itself. I would like to be able to do a safe binary-only upgrade of the base FreeBSD O/S. For it to be safe, it has to be able to *remove* things which were in the old distribution but not in the new one. The current upgrade process just untars the new distribution on top of whatever you have, and usually leaves a mess behind to clean up. This works with RPM-based O/Ses because each part of the O/S is itself a package, and thus the package database records which files it contians. Making the whole FreeBSD base system consist of 'packages' rather than just plain tarballs might be one approach. It would also usefully record which distribution sets you chose to install originally, which is information that is also lost currently. Oh, and I want the 'mergemaster' functionality to be available in a binary upgrade too. > > 4. GUI Kernel configurator That wouldn't add any value for me. I moved from Linux to FreeBSD several years ago, and one of the things I prefer about FreeBSD is that the kernel configuration and build process is *so* straightforward. Single text file to edit; that's it. > > 5. GUI port manager (add / delete ports) > There are a few incarnations of this(ese) already available depending of > your windowmanager/ console choice. As I'm sure you know, sysinstall has this functionality already. sysinstall isn't pretty, but it kind-of works. The biggest problem I find when newbie FreeBSD users are trying it is having to remember to hit "Tab" to get to the right places. Especially screens like this: [_X_] Selection 1 [ X ] Selection 2 [ ] Selection 3 [ OK ] [ Cancel ] People think they can just hit Enter to select 'OK', but actually it toggles Selection 1 off. Maybe that's the same point you made about "improved cursor handling". > > 6. Other Small System enhancements > > > > If you want maybe we could create a group who's purpose is to create > > system enhancements......let's come up with some projects work on them > > and see if they are willing to commit them ........ think about it. I remember reading an article by Jordan Hubbard a couple of years ago explaining the deficiencies of the current installation/upgrade system, and suggesting what features a next generation system should have. Anybody remember where it was? Regards, Brian. From owner-freebsd-current@FreeBSD.ORG Fri Apr 29 09:14: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 0828216A4CE for ; Fri, 29 Apr 2005 09:14:38 +0000 (GMT) Received: from orb.pobox.com (orb.pobox.com [207.8.226.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id CEEFA43D2D for ; Fri, 29 Apr 2005 09:14:37 +0000 (GMT) (envelope-from discussion-lists@linnet.org) Received: from orb (localhost [127.0.0.1]) by orb.pobox.com (Postfix) with ESMTP id 69CF880A; Fri, 29 Apr 2005 05:14:34 -0400 (EDT) Received: from thinkdog.local.linnet.org (host217-40-157-153.in-addr.btopenworld.com [217.40.157.153]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by orb.sasl.smtp.pobox.com (Postfix) with ESMTP id 8A4B18B; Fri, 29 Apr 2005 05:14:32 -0400 (EDT) Received: from lists by thinkdog.local.linnet.org with local (Exim 4.43 (FreeBSD)) id 1DRRZa-000O0C-Hf; Fri, 29 Apr 2005 10:14:10 +0100 Date: Fri, 29 Apr 2005 10:14:10 +0100 From: Brian Candler To: Chuck Robey Message-ID: <20050429091410.GB92159@uk.tiscali.com> References: <427196C0.5040506@chuckr.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <427196C0.5040506@chuckr.org> User-Agent: Mutt/1.4.2.1i cc: current Subject: Re: tcsh X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 29 Apr 2005 09:14:38 -0000 On Fri, Apr 29, 2005 at 02:06:56AM +0000, Chuck Robey wrote: > The first thing I do, after I've installed a new system (just before I > copy over the ssh data) is to copy my .cshrc to my home dir. What's so > important? I really like the two statements, which I show below, which > give me my prompt: > > set prompt="%m:%{^[[34m%}`id -nu`%{^[[0m%}:%~:%{^[[31m#%h^[[0m%}%#" > alias cd 'cd \!*;set prompt="%m%{^[[32m%}:`id > -nu`%{^[[0m%}:%~:%{^[[31m#%h^[[0m%}%#"' If this is up for grabs, could I add a vote for: set autolist The lack of this setting is the one thing which bugs people familiar with bash; I didn't even realise it was possible to fix it until I dug deep through man pages. Now I always have to add it to .cshrc ! Regards, Brian. From owner-freebsd-current@FreeBSD.ORG Fri Apr 29 09:15: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 5C4EF16A4CF for ; Fri, 29 Apr 2005 09:15:26 +0000 (GMT) Received: from mailout01.sul.t-online.com (mailout01.sul.t-online.com [194.25.134.80]) by mx1.FreeBSD.org (Postfix) with ESMTP id BD03843D53 for ; Fri, 29 Apr 2005 09:15:25 +0000 (GMT) (envelope-from Alexander@Leidinger.net) Received: from fwd26.aul.t-online.de by mailout01.sul.t-online.com with smtp id 1DRRam-0004HR-00; Fri, 29 Apr 2005 11:15:24 +0200 Received: from Andro-Beta.Leidinger.net (GEhF2rZrwexiEHEc3-MyLgfdRdCCoJy0o5XpmhGay8PlknCFZ+-scG@[217.229.217.78]) by fwd26.sul.t-online.de with esmtp id 1DRRad-0REfL60; Fri, 29 Apr 2005 11:15:15 +0200 Received: from localhost (localhost [127.0.0.1])j3T9FEOD052221; Fri, 29 Apr 2005 11:15:14 +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 ; Fri, 29 Apr 2005 11:15:14 +0200 Message-ID: <20050429111514.je0mg399kos00ooo@netchild.homeip.net> X-Priority: 3 (Normal) Date: Fri, 29 Apr 2005 11:15:14 +0200 From: Alexander Leidinger To: /dev/null References: <57436.216.177.243.42.1114582155.localmail@webmail.dnswatch.com><426FDE69.8090909@samsco.org> <426FE1EA.7020900@kutulu.org><20050427212637.GL98718@over-yonder.net> <20050428115258.rpvu466t68so80w4@netchild.homeip.net> <53801.216.177.243.35.1114720139.localmail@webmail.dnswatch.com> In-Reply-To: <53801.216.177.243.35.1114720139.localmail@webmail.dnswatch.com> 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: GEhF2rZrwexiEHEc3-MyLgfdRdCCoJy0o5XpmhGay8PlknCFZ+-scG@t-dialin.net X-TOI-MSGID: 480422eb-d8ac-408d-a4a4-b905f5bc6d41 cc: freebsd-current@freebsd.org Subject: Re: boot banner project X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 29 Apr 2005 09:15:26 -0000 /dev/null wrote: >> I think restructuring our userland boot message would be a good start. I'm >> not talking about the above proposal, even if I think it's nice (but a >> little bit too terse for me), I'm talking about rethinking the actual >> (since >> the new rc system) clutter. >> >> The 4.x startup looks structured (it could be improved to be more eye >> friendly, but the beauty lies in the eye of the beholder), while the 5+ >> one >> is neither fish nor meat. It's a mixture of the 4.x one with the "Starting >> xyz" messages from the new system. Since we don't try to keep the new >> system >> diff friendly with the NetBSD source anymore, I think we could change it >> to >> fit our needs. > > Maybe this would be a better place for me to start > (assuming no objection(s)). I mean, it may turn out > the large majority of opinion is: boot-banner SUX! So If root is able to switch the boot-banner on/off, and as long as headless and serial-console enabled systems behave as usual, nothing should stop you from doing this project. > in either case; making what already exists more desirable/ > funcional; seems the best place to start something. As > opposed to adding to something that might me better polished > up. What's more, I was thinking; what if the current settings > ( verbose/ terse ) were expanded and prettified(stylized). > Example: 3 settings; > > 1) no output: black, or blank screen until the prompt/ login. That's not a good option (from an usability point of view). You need at least some progress indicator, else an user will ask if the system freezed or not. > 2) terse: > a) only dumps warnings > b) dumps item at succesful load, or else failure message as returned by > failed object. > > 3) verbose: > a) raw (pretty much the way it is now but unify/ sanitize the messages > returned - (4.x ify?)) > b) prettified > (example(s): > > mysql > > or > > mysql ) > > both or *could* be colorized. That's too much options IMHO ("less" is "more", you know? ;-) ). You need a progress indicator in 2), and you need the possibility to report errors in 1), so I think you can reduce it to a) progress indicator + error output b) raw (as is, or polished up) c) nice But since we don't have an option to shut up the kernel messages on boot, I think we don't need a). If you want to proceeed with this, you should move over to the freebsd rc mailinglist. Bye, Alexander. -- http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 If sex is such a natural phenomenon, how come there are so many books on how to? -- Bette Midler From owner-freebsd-current@FreeBSD.ORG Fri Apr 29 09:22: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 796B316A4CE for ; Fri, 29 Apr 2005 09:22:17 +0000 (GMT) Received: from mx.toxahost.ru (ns.toxahost.ru [62.89.204.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1B28C43D60 for ; Fri, 29 Apr 2005 09:22:17 +0000 (GMT) (envelope-from toxa@toxahost.ru) Received: from localhost (laptoxa.toxa.lan [192.168.1.3]) by mx.toxahost.ru (Toxa) with ESMTP id C28204C for ; Fri, 29 Apr 2005 13:22:15 +0400 (MSD) Date: Fri, 29 Apr 2005 13:22:04 +0400 From: Toxa To: freebsd-current@freebsd.org X-Comment-To: "Anton A. Karpov" Message-ID: <20050429092204.GA43752@laptoxa.toxa.lan> Mail-Followup-To: freebsd-current@freebsd.org References: <57436.216.177.243.42.1114582155.localmail@webmail.dnswatch.com> <426FDE69.8090909@samsco.org> <426FE1EA.7020900@kutulu.org> <20050428105348.GA8056@laptoxa.toxa.lan> <4270CC84.8060904@centtech.com> <20050429010318.GB17799@laptoxa.toxa.lan> <4271885C.3000606@samsco.org> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <4271885C.3000606@samsco.org> User-Agent: Outluck Express 1.5.6i for MS-DOS 6.22-SMP X-Mailer: See User-Agent above :) X-Operating-System: MS-DOS 6.22-CURRENT on Sony VAIO laptop X-PGP-Public-Key: http://toxahost.ru/gpg/pubkey.asc X-Useless-Header: Do Androids Dream of Electric Sheep? Subject: Re: boot banner project X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 29 Apr 2005 09:22:17 -0000 On Thu, Apr 28, 2005 at 07:05:32PM -0600, Scott Long wrote: > Are you the gatekeeper for the 'necessary and desirable' standard? I'd > prefer to keep the debate technical and see what can be produced rather > than inject personal opinion as if it represents everyone. > > Scott No. That's why I've told my opinion: boot banner is not the feature everyone want to see in FreeBSD right now, am I right? Just dont' think about it as a "good thing which may brings more eye-candy look". I prefer to sit down and estimate all pros and contras of this feature. That's all. From owner-freebsd-current@FreeBSD.ORG Fri Apr 29 09:25: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 836C116A4CE for ; Fri, 29 Apr 2005 09:25:14 +0000 (GMT) Received: from mx.toxahost.ru (ns.toxahost.ru [62.89.204.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id 262F743D2D for ; Fri, 29 Apr 2005 09:25:14 +0000 (GMT) (envelope-from toxa@toxahost.ru) Received: from localhost (laptoxa.toxa.lan [192.168.1.3]) by mx.toxahost.ru (Toxa) with ESMTP id 3E6A44C for ; Fri, 29 Apr 2005 13:25:13 +0400 (MSD) Date: Fri, 29 Apr 2005 13:25:01 +0400 From: Toxa To: freebsd-current@freebsd.org X-Comment-To: "Anton A. Karpov" Message-ID: <20050429092501.GB43752@laptoxa.toxa.lan> Mail-Followup-To: freebsd-current@freebsd.org References: <57436.216.177.243.42.1114582155.localmail@webmail.dnswatch.com> <426FDE69.8090909@samsco.org> <426FE1EA.7020900@kutulu.org> <20050428105348.GA8056@laptoxa.toxa.lan> <4270CC84.8060904@centtech.com> <20050429010318.GB17799@laptoxa.toxa.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: User-Agent: Outluck Express 1.5.6i for MS-DOS 6.22-SMP X-Mailer: See User-Agent above :) X-Operating-System: MS-DOS 6.22-CURRENT on Sony VAIO laptop X-PGP-Public-Key: http://toxahost.ru/gpg/pubkey.asc X-Useless-Header: Do Androids Dream of Electric Sheep? Subject: Re: boot banner project X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 29 Apr 2005 09:25:14 -0000 On Thu, Apr 28, 2005 at 08:17:30PM -0500, R. Tyler Ballance wrote: > I think you're mistaking convenience for bloat...someone mentioned > the old redhat boot process earlier, and I can agree with them, that > that was, convenient, easy to read, and in no way seemed to add any > bloat to the ASCII output. > > Now, a pretty image, a la FreeSBIE, _is_ bloat, but I don't think > that's what is being mentioned or suggested here. > > Toxa, you make Window Managers, and a lot of GUI apps that make > things like, using MacOS X sound terribly bloated, don't discount > aesthetics right off the bat, they're not always "evil bloat" > I'm afraid of tendency. A little this, a little that, and at the end of it we'll get pretty nifty OS full of "cool but really unnecessary" features :-) From owner-freebsd-current@FreeBSD.ORG Fri Apr 29 09:27: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 E716C16A4CE for ; Fri, 29 Apr 2005 09:27:46 +0000 (GMT) Received: from mx.toxahost.ru (ns.toxahost.ru [62.89.204.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8C3C743D1F for ; Fri, 29 Apr 2005 09:27:46 +0000 (GMT) (envelope-from toxa@toxahost.ru) Received: from localhost (laptoxa.toxa.lan [192.168.1.3]) by mx.toxahost.ru (Toxa) with ESMTP id A80F54C for ; Fri, 29 Apr 2005 13:27:45 +0400 (MSD) Date: Fri, 29 Apr 2005 13:27:34 +0400 From: Toxa To: freebsd-current@freebsd.org X-Comment-To: "Anton A. Karpov" Message-ID: <20050429092734.GC43752@laptoxa.toxa.lan> Mail-Followup-To: freebsd-current@freebsd.org References: <4270E7F1.9010502@kutulu.org> <20050429005319.GA17799@laptoxa.toxa.lan> <60093.216.177.243.35.1114761721.localmail@webmail.dnswatch.com> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <60093.216.177.243.35.1114761721.localmail@webmail.dnswatch.com> User-Agent: Outluck Express 1.5.6i for MS-DOS 6.22-SMP X-Mailer: See User-Agent above :) X-Operating-System: MS-DOS 6.22-CURRENT on Sony VAIO laptop X-PGP-Public-Key: http://toxahost.ru/gpg/pubkey.asc X-Useless-Header: Do Androids Dream of Electric Sheep? Subject: Re: boot banner project X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 29 Apr 2005 09:27:47 -0000 On Fri, Apr 29, 2005 at 01:02:01AM -0700, /dev/null wrote: > "And that's everyone likes in BSD's" > WOW! Were you elected Official Spokesperson for everyone? ;) What's wrong? Do you dislike BSD for it's simpleness and cleareness and prefer to walk with mouse through thousands of windows configureing MS Server 2003? ;-)))) -- Anton A. Karpov WWW: http://www.toxahost.ru PGP Key ID: A21386F2 You can finger toxa@weirdzone.org for my current status =~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~= Hi! I am a .signature virus! Copy me into your ~/.signature to help me spread! =~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~= From owner-freebsd-current@FreeBSD.ORG Fri Apr 29 09:32: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 45A7B16A4CF for ; Fri, 29 Apr 2005 09:32:48 +0000 (GMT) Received: from 62-15-215-183.inversas.jazztel.es (62-15-215-183.inversas.jazztel.es [62.15.215.183]) by mx1.FreeBSD.org (Postfix) with ESMTP id AD1B743D4C for ; Fri, 29 Apr 2005 09:32:46 +0000 (GMT) (envelope-from josemi@freebsd.jazztel.es) Received: from redesjm.local (orion.redesjm.local [192.168.254.16]) j3T9WiwH001152 for ; Fri, 29 Apr 2005 11:32:44 +0200 (CEST) (envelope-from josemi@redesjm.local) Received: from localhost (localhost [[UNIX: localhost]]) by redesjm.local (8.13.3/8.13.3/Submit) id j3T9WhPt022014 for freebsd-current@freebsd.org; Fri, 29 Apr 2005 11:32:43 +0200 (CEST) (envelope-from josemi@redesjm.local) From: Jose M Rodriguez To: freebsd-current@freebsd.org Date: Fri, 29 Apr 2005 11:32:43 +0200 User-Agent: KMail/1.8 References: <427196C0.5040506@chuckr.org> <20050429091410.GB92159@uk.tiscali.com> In-Reply-To: <20050429091410.GB92159@uk.tiscali.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200504291132.43454.josemi@redesjm.local> X-AntiVirus: checked by AntiVir Milter (version: 1.1.0-3; AVE: 6.30.0.7; VDF: 6.30.0.116; host: antares.redesjm.local) Subject: Re: tcsh X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 29 Apr 2005 09:32:48 -0000 El Viernes, 29 de Abril de 2005 11:14, Brian Candler escribi=F3: > On Fri, Apr 29, 2005 at 02:06:56AM +0000, Chuck Robey wrote: > > The first thing I do, after I've installed a new system (just > > before I copy over the ssh data) is to copy my .cshrc to my home > > dir. What's so important? I really like the two statements, which > > I show below, which give me my prompt: > > > > set prompt=3D"%m:%{^[[34m%}`id > > -nu`%{^[[0m%}:%~:%{^[[31m#%h^[[0m%}%#" alias cd 'cd \!*;set > > prompt=3D"%m%{^[[32m%}:`id > > -nu`%{^[[0m%}:%~:%{^[[31m#%h^[[0m%}%#"' > > If this is up for grabs, could I add a vote for: > > set autolist > > The lack of this setting is the one thing which bugs people familiar > with bash; I didn't even realise it was possible to fix it until I > dug deep through man pages. Now I always have to add it to .cshrc ! > > Regards, > > Brian. > I think I see near this thread before. I remember do a PR about make some changes in skel dir But I think this will be a better approach: add support to sysutils for use /usr/local/share/skel if populated (as=20 part of the mtree file, this is allways present). So, you can install this kind of changes from a port before going to=20 populate users. This will not be so difficult to implement. =2D- josemi From owner-freebsd-current@FreeBSD.ORG Fri Apr 29 09:44: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 9484016A4CE for ; Fri, 29 Apr 2005 09:44:59 +0000 (GMT) Received: from smtp-vbr1.xs4all.nl (smtp-vbr1.xs4all.nl [194.109.24.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id CE60643D45 for ; Fri, 29 Apr 2005 09:44:58 +0000 (GMT) (envelope-from wb@freebie.xs4all.nl) Received: from freebie.xs4all.nl (freebie.xs4all.nl [213.84.32.253]) by smtp-vbr1.xs4all.nl (8.12.11/8.12.11) with ESMTP id j3T9iv5S008620; Fri, 29 Apr 2005 11:44:57 +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.13.1) with ESMTP id j3T9iuU0072636; Fri, 29 Apr 2005 11:44:56 +0200 (CEST) (envelope-from wb@freebie.xs4all.nl) Received: (from wb@localhost) by freebie.xs4all.nl (8.13.3/8.13.1/Submit) id j3T9iu2t072635; Fri, 29 Apr 2005 11:44:56 +0200 (CEST) (envelope-from wb) Date: Fri, 29 Apr 2005 11:44:56 +0200 From: Wilko Bulte To: Poul-Henning Kamp Message-ID: <20050429094456.GG26747@freebie.xs4all.nl> References: <20050429071907.GA13459@mail.netspace.net.au> <4937.1114759965@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4937.1114759965@critter.freebsd.dk> X-OS: FreeBSD 5.4-STABLE User-Agent: Mutt/1.5.9i X-Virus-Scanned: by XS4ALL Virus Scanner cc: freebsd-current@freebsd.org Subject: Re: incorrect statement on www page X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 29 Apr 2005 09:44:59 -0000 On Fri, Apr 29, 2005 at 09:32:45AM +0200, Poul-Henning Kamp wrote.. > > One can't help the feeling that the projects resources could be > used wiser than for a thread like this nor indeed if the instigator > of this particular nitpicking has an agenda different from the > advancement of FreeBSD. > > If we really should enforce the proposed level of "truth in > advertising" then no operating system since Brink-Hansens RC4000 For the Regnecentralen hardware? > planet from the star "Sol". > [5] This statement contains forward and backward looking projections > and we can't be bothered to state that this obviously means that > it may not be true everywhere and forever. > [6] The use of the word "planet" should not be seen as a position in > fiercely heated argument about the flat vs. round Earth theories. > [7] God[8] This is silly, isn't it ? > [8] Pick one, anyone, or none, we don't care. My thoughts exactly. ETOOMANYLAWYERS / ETOOMUCHLAWYERING -- Wilko Bulte wilko@FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Fri Apr 29 09:59: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 3017716A4CE for ; Fri, 29 Apr 2005 09:59:46 +0000 (GMT) Received: from mx01.stofanet.dk (mx01.stofanet.dk [212.10.10.11]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8A3A243D1D for ; Fri, 29 Apr 2005 09:59:45 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from d40a2021.rev.stofanet.dk ([212.10.32.33] helo=critter.freebsd.dk) by mx01.stofanet.dk (envelope-from ) with esmtp id 1DRSHf-0005aD-0Z for freebsd-current@freebsd.org; Fri, 29 Apr 2005 11:59:44 +0200 Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.3/8.13.3) with ESMTP id j3T9xcTC006004; Fri, 29 Apr 2005 11:59:38 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Wilko Bulte From: "Poul-Henning Kamp" In-Reply-To: Your message of "Fri, 29 Apr 2005 11:44:56 +0200." <20050429094456.GG26747@freebie.xs4all.nl> Date: Fri, 29 Apr 2005 11:59:38 +0200 Message-ID: <6003.1114768778@critter.freebsd.dk> Sender: phk@critter.freebsd.dk cc: freebsd-current@freebsd.org Subject: Re: incorrect statement on www page X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 29 Apr 2005 09:59:46 -0000 In message <20050429094456.GG26747@freebie.xs4all.nl>, Wilko Bulte writes: >On Fri, Apr 29, 2005 at 09:32:45AM +0200, Poul-Henning Kamp wrote.. >> >> One can't help the feeling that the projects resources could be >> used wiser than for a thread like this nor indeed if the instigator >> of this particular nitpicking has an agenda different from the >> advancement of FreeBSD. >> >> If we really should enforce the proposed level of "truth in >> advertising" then no operating system since Brink-Hansens RC4000 > >For the Regnecentralen hardware? yes :-) -- 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 Fri Apr 29 10:22: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 40FC716A4CE; Fri, 29 Apr 2005 10:22:54 +0000 (GMT) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id D647143D4C; Fri, 29 Apr 2005 10:22:53 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.13.3/8.13.3) with ESMTP id j3TAMrmJ062845; Fri, 29 Apr 2005 06:22:53 -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 j3TANRnQ089888; Fri, 29 Apr 2005 06:23:27 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 05CD47306E; Fri, 29 Apr 2005 06:22:52 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050429102252.05CD47306E@freebsd-current.sentex.ca> Date: Fri, 29 Apr 2005 06:22:52 -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 alpha/alpha 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: Fri, 29 Apr 2005 10:22:54 -0000 TB --- 2005-04-29 10:15:01 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-04-29 10:15:01 - starting CURRENT tinderbox run for alpha/alpha TB --- 2005-04-29 10:15:01 - checking out the source tree TB --- 2005-04-29 10:15:01 - cd /home/tinderbox/CURRENT/alpha/alpha TB --- 2005-04-29 10:15:01 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-04-29 10:21:36 - building world (CFLAGS=-O2 -pipe) TB --- 2005-04-29 10:21:36 - cd /home/tinderbox/CURRENT/alpha/alpha/src TB --- 2005-04-29 10:21:36 - /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 [...] ===> sbin/growfs (cleandir) ===> sbin/gvinum (cleandir) ===> sbin/ifconfig (cleandir) ===> sbin/init (cleandir) ===> sbin/ip6fw (cleandir) ===> sbin/ipf (cleandir) ".depend", line 275: Inconsistent operator for ipf make: fatal errors encountered -- cannot continue *** Error code 1 Stop in /tinderbox/CURRENT/alpha/alpha/src/sbin. *** Error code 1 Stop in /tinderbox/CURRENT/alpha/alpha/src. *** Error code 1 Stop in /tinderbox/CURRENT/alpha/alpha/src. *** Error code 1 Stop in /tinderbox/CURRENT/alpha/alpha/src. TB --- 2005-04-29 10:22:52 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-04-29 10:22:52 - ERROR: failed to build world TB --- 2005-04-29 10:22:52 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Fri Apr 29 10:26: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 755D416A4CE; Fri, 29 Apr 2005 10:26:28 +0000 (GMT) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1685643D55; Fri, 29 Apr 2005 10:26:28 +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 j3TAQRcI062935; Fri, 29 Apr 2005 06:26:27 -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 j3TAR1sp091581; Fri, 29 Apr 2005 06:27:01 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 9B5BA7306E; Fri, 29 Apr 2005 06:26:27 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050429102627.9B5BA7306E@freebsd-current.sentex.ca> Date: Fri, 29 Apr 2005 06:26:27 -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 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: Fri, 29 Apr 2005 10:26:28 -0000 TB --- 2005-04-29 10:22:53 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-04-29 10:22:53 - starting CURRENT tinderbox run for amd64/amd64 TB --- 2005-04-29 10:22:53 - checking out the source tree TB --- 2005-04-29 10:22:53 - cd /home/tinderbox/CURRENT/amd64/amd64 TB --- 2005-04-29 10:22:53 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-04-29 10:25:15 - building world (CFLAGS=-O2 -pipe) TB --- 2005-04-29 10:25:15 - cd /home/tinderbox/CURRENT/amd64/amd64/src TB --- 2005-04-29 10:25:15 - /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 [...] ===> sbin/growfs (cleandir) ===> sbin/gvinum (cleandir) ===> sbin/ifconfig (cleandir) ===> sbin/init (cleandir) ===> sbin/ip6fw (cleandir) ===> sbin/ipf (cleandir) ".depend", line 269: Inconsistent operator for ipf make: fatal errors encountered -- cannot continue *** Error code 1 Stop in /tinderbox/CURRENT/amd64/amd64/src/sbin. *** 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-29 10:26:27 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-04-29 10:26:27 - ERROR: failed to build world TB --- 2005-04-29 10:26:27 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Fri Apr 29 10:32: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 AB81C16A4D0; Fri, 29 Apr 2005 10:32:18 +0000 (GMT) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id CE7D243D4C; Fri, 29 Apr 2005 10:32:17 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.13.3/8.13.3) with ESMTP id j3TAWHAI063080; Fri, 29 Apr 2005 06:32: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 j3TAWpWT094026; Fri, 29 Apr 2005 06:32:51 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 4C39A7306E; Fri, 29 Apr 2005 06:32:17 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050429103217.4C39A7306E@freebsd-current.sentex.ca> Date: Fri, 29 Apr 2005 06:32:17 -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/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: Fri, 29 Apr 2005 10:32:19 -0000 TB --- 2005-04-29 10:26:27 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-04-29 10:26:27 - starting CURRENT tinderbox run for i386/i386 TB --- 2005-04-29 10:26:27 - checking out the source tree TB --- 2005-04-29 10:26:27 - cd /home/tinderbox/CURRENT/i386/i386 TB --- 2005-04-29 10:26:27 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-04-29 10:31:05 - building world (CFLAGS=-O2 -pipe) TB --- 2005-04-29 10:31:05 - cd /home/tinderbox/CURRENT/i386/i386/src TB --- 2005-04-29 10:31: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 [...] ===> sbin/growfs (cleandir) ===> sbin/gvinum (cleandir) ===> sbin/ifconfig (cleandir) ===> sbin/init (cleandir) ===> sbin/ip6fw (cleandir) ===> sbin/ipf (cleandir) ".depend", line 269: Inconsistent operator for ipf make: fatal errors encountered -- cannot continue *** Error code 1 Stop in /tinderbox/CURRENT/i386/i386/src/sbin. *** 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-29 10:32:17 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-04-29 10:32:17 - ERROR: failed to build world TB --- 2005-04-29 10:32:17 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Fri Apr 29 10: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 7ECD216A4CE; Fri, 29 Apr 2005 10:36:30 +0000 (GMT) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 20C3343D2D; Fri, 29 Apr 2005 10:36:30 +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 j3TAaTOb075545; Fri, 29 Apr 2005 06:36:29 -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 j3TAb3jb095648; Fri, 29 Apr 2005 06:37:03 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 83D237306E; Fri, 29 Apr 2005 06:36:29 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050429103629.83D237306E@freebsd-current.sentex.ca> Date: Fri, 29 Apr 2005 06:36:29 -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/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: Fri, 29 Apr 2005 10:36:30 -0000 TB --- 2005-04-29 10:32:17 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-04-29 10:32:17 - starting CURRENT tinderbox run for i386/pc98 TB --- 2005-04-29 10:32:17 - checking out the source tree TB --- 2005-04-29 10:32:17 - cd /home/tinderbox/CURRENT/i386/pc98 TB --- 2005-04-29 10:32:17 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-04-29 10:35:22 - building world (CFLAGS=-O2 -pipe) TB --- 2005-04-29 10:35:22 - cd /home/tinderbox/CURRENT/i386/pc98/src TB --- 2005-04-29 10:35:22 - /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 [...] rm -f init init.o init.8.gz init.8.cat.gz rm -f .depend GPATH GRTAGS GSYMS GTAGS ===> sbin/ip6fw (cleandir) rm -f ip6fw ip6fw.o ip6fw.8.gz ip6fw.8.cat.gz rm -f .depend GPATH GRTAGS GSYMS GTAGS ===> sbin/ipf (cleandir) ".depend", line 299: Inconsistent operator for ipf make: fatal errors encountered -- cannot continue *** Error code 1 Stop in /tinderbox/CURRENT/i386/pc98/src/sbin. *** 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-29 10:36:29 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-04-29 10:36:29 - ERROR: failed to build world TB --- 2005-04-29 10:36:29 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Fri Apr 29 10: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 8E8C516A4CE; Fri, 29 Apr 2005 10:41:18 +0000 (GMT) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3147043D5A; Fri, 29 Apr 2005 10:41:18 +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 j3TAfHA9075741; Fri, 29 Apr 2005 06:41:17 -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 j3TAfHkG065202; Fri, 29 Apr 2005 06:41:17 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 8A7167306E; Fri, 29 Apr 2005 06:41:17 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050429104117.8A7167306E@freebsd-current.sentex.ca> Date: Fri, 29 Apr 2005 06:41:17 -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: Fri, 29 Apr 2005 10:41:18 -0000 TB --- 2005-04-29 10:36:29 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-04-29 10:36:29 - starting CURRENT tinderbox run for ia64/ia64 TB --- 2005-04-29 10:36:29 - checking out the source tree TB --- 2005-04-29 10:36:29 - cd /home/tinderbox/CURRENT/ia64/ia64 TB --- 2005-04-29 10:36:29 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-04-29 10:40:11 - building world (CFLAGS=-O2 -pipe) TB --- 2005-04-29 10:40:11 - cd /home/tinderbox/CURRENT/ia64/ia64/src TB --- 2005-04-29 10:40:11 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree [...] rm -f init init.o init.8.gz init.8.cat.gz rm -f .depend GPATH GRTAGS GSYMS GTAGS ===> sbin/ip6fw (cleandir) rm -f ip6fw ip6fw.o ip6fw.8.gz ip6fw.8.cat.gz rm -f .depend GPATH GRTAGS GSYMS GTAGS ===> sbin/ipf (cleandir) ".depend", line 269: Inconsistent operator for ipf make: fatal errors encountered -- cannot continue *** Error code 1 Stop in /tinderbox/CURRENT/ia64/ia64/src/sbin. *** Error code 1 Stop in /tinderbox/CURRENT/ia64/ia64/src. *** Error code 1 Stop in /tinderbox/CURRENT/ia64/ia64/src. *** Error code 1 Stop in /tinderbox/CURRENT/ia64/ia64/src. TB --- 2005-04-29 10:41:17 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-04-29 10:41:17 - ERROR: failed to build world TB --- 2005-04-29 10:41:17 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Fri Apr 29 10:46: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 CF12F16A4CE; Fri, 29 Apr 2005 10:46:15 +0000 (GMT) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6BD0C43D31; Fri, 29 Apr 2005 10:46:15 +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 j3TAkF3F075905; Fri, 29 Apr 2005 06:46:15 -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 j3TAknrg099334; Fri, 29 Apr 2005 06:46:49 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id B324A7306E; Fri, 29 Apr 2005 06:46:14 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050429104614.B324A7306E@freebsd-current.sentex.ca> Date: Fri, 29 Apr 2005 06:46:14 -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: Fri, 29 Apr 2005 10:46:16 -0000 TB --- 2005-04-29 10:41:17 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-04-29 10:41:17 - starting CURRENT tinderbox run for powerpc/powerpc TB --- 2005-04-29 10:41:17 - checking out the source tree TB --- 2005-04-29 10:41:17 - cd /home/tinderbox/CURRENT/powerpc/powerpc TB --- 2005-04-29 10:41:17 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-04-29 10:45:05 - building world (CFLAGS=-O2 -pipe) TB --- 2005-04-29 10:45:05 - cd /home/tinderbox/CURRENT/powerpc/powerpc/src TB --- 2005-04-29 10:45: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 [...] rm -f init init.o init.8.gz init.8.cat.gz rm -f .depend GPATH GRTAGS GSYMS GTAGS ===> sbin/ip6fw (cleandir) rm -f ip6fw ip6fw.o ip6fw.8.gz ip6fw.8.cat.gz rm -f .depend GPATH GRTAGS GSYMS GTAGS ===> sbin/ipf (cleandir) ".depend", line 272: Inconsistent operator for ipf make: fatal errors encountered -- cannot continue *** Error code 1 Stop in /tinderbox/CURRENT/powerpc/powerpc/src/sbin. *** Error code 1 Stop in /tinderbox/CURRENT/powerpc/powerpc/src. *** Error code 1 Stop in /tinderbox/CURRENT/powerpc/powerpc/src. *** Error code 1 Stop in /tinderbox/CURRENT/powerpc/powerpc/src. TB --- 2005-04-29 10:46:14 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-04-29 10:46:14 - ERROR: failed to build world TB --- 2005-04-29 10:46:14 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Fri Apr 29 10:51: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 DB2A816A4CE; Fri, 29 Apr 2005 10:51:25 +0000 (GMT) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5A93943D46; Fri, 29 Apr 2005 10:51:25 +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 j3TApOs7063700; Fri, 29 Apr 2005 06:51:24 -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 j3TApOxM009830; Fri, 29 Apr 2005 06:51:24 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id AC2517306E; Fri, 29 Apr 2005 06:51:24 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050429105124.AC2517306E@freebsd-current.sentex.ca> Date: Fri, 29 Apr 2005 06:51:24 -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 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: Fri, 29 Apr 2005 10:51:26 -0000 TB --- 2005-04-29 10:46:14 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-04-29 10:46:14 - starting CURRENT tinderbox run for sparc64/sparc64 TB --- 2005-04-29 10:46:14 - checking out the source tree TB --- 2005-04-29 10:46:14 - cd /home/tinderbox/CURRENT/sparc64/sparc64 TB --- 2005-04-29 10:46:14 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-04-29 10:50:06 - building world (CFLAGS=-O2 -pipe) TB --- 2005-04-29 10:50:06 - cd /home/tinderbox/CURRENT/sparc64/sparc64/src TB --- 2005-04-29 10:50:06 - /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 [...] rm -f init init.o init.8.gz init.8.cat.gz rm -f .depend GPATH GRTAGS GSYMS GTAGS ===> sbin/ip6fw (cleandir) rm -f ip6fw ip6fw.o ip6fw.8.gz ip6fw.8.cat.gz rm -f .depend GPATH GRTAGS GSYMS GTAGS ===> sbin/ipf (cleandir) ".depend", line 275: Inconsistent operator for ipf make: fatal errors encountered -- cannot continue *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/src/sbin. *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/src. *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/src. *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/src. TB --- 2005-04-29 10:51:24 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-04-29 10:51:24 - ERROR: failed to build world TB --- 2005-04-29 10:51:24 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Fri Apr 29 10:54: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 78EDA16A4CE for ; Fri, 29 Apr 2005 10:54:22 +0000 (GMT) Received: from madpilot.net (dadovago8197.dada.it [195.110.114.197]) by mx1.FreeBSD.org (Postfix) with SMTP id F0C1F43D45 for ; Fri, 29 Apr 2005 10:54:20 +0000 (GMT) (envelope-from mad@madpilot.net) Received: (qmail 18182 invoked from network); 29 Apr 2005 10:54:19 -0000 Received: from wedge.madpilot.net (192.168.13.11) by 0 with SMTP; 29 Apr 2005 10:54:19 -0000 Received: from wedge.madpilot.net (localhost.madpilot.net [127.0.0.1]) by wedge.madpilot.net (8.13.3/8.13.3) with ESMTP id j3TAsHI7094763; Fri, 29 Apr 2005 12:54:17 +0200 (CEST) (envelope-from mad@wedge.madpilot.net) Received: (from mad@localhost) by wedge.madpilot.net (8.13.3/8.13.3/Submit) id j3TAsGxc094762; Fri, 29 Apr 2005 12:54:16 +0200 (CEST) (envelope-from mad) Date: Fri, 29 Apr 2005 12:54:16 +0200 From: Guido Falsi To: /dev/null Message-ID: <20050429105416.GA94049@wedge.madpilot.net> References: <57436.216.177.243.42.1114582155.localmail@webmail.dnswatch.com> <6.1.0.6.2.20050426233321.084e9210@cobalt.antimatter.net> <51899.216.177.243.42.1114584317.localmail@webmail.dnswatch.com> <6.1.0.6.2.20050427001118.0327cd50@cobalt.antimatter.net> <52515.216.177.243.42.1114586501.localmail@webmail.dnswatch.com> <61359.216.177.243.35.1114722481.localmail@webmail.dnswatch.com> Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="X1bOJ3K7DJ5YkBrT" Content-Disposition: inline In-Reply-To: <61359.216.177.243.35.1114722481.localmail@webmail.dnswatch.com> X-Operating-System: FreeBSD 5.4-STABLE X-PGP-Key: http://www.madpilot.net/~mad/PGP-public-key.asc User-Agent: Mutt/1.5.9i cc: freebsd-current@freebsd.org cc: John Sconiers Subject: Re: boot banner project X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 29 Apr 2005 10:54:22 -0000 --X1bOJ3K7DJ5YkBrT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Apr 28, 2005 at 02:08:00PM -0700, /dev/null wrote: > Hello, > As this is an RFC (I'm sure you already know that). >=20 > Long answer: > I'm not quite sure. It will depend on the amount and content > of the comments. Technically, it may not start ever (because > everyone/ or nearly everyone says it SUX). >=20 > Short answer: > Too early for me to say. On this proposal, I think that some graphic banner while booting could be beautiful to the eye, but quite void in usefullness. I'm not against it, but can't see any real advantage. Anyway if someone feels like spending some time on this feature and the results does not bring any regression to the system I don't see why it should not be offered as an option. On the other hand I think some tidying up in the rc sctripts boot messages would really REALLY be a good idea. I don't mean anything drastic, just that in 5.x(as was altready pointed out) the output is a bit messy, and even if I can sort it out uite clearly out of habit, it would be better if it was a bit more structured and ordered. My 2 cents...nothing more, nothing less. --=20 Guido Falsi --X1bOJ3K7DJ5YkBrT Content-Type: application/x-pkcs7-signature Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIIIpQYJKoZIhvcNAQcCoIIIljCCCJICAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BikwggLiMIICS6ADAgECAgMOV4MwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UEBhMCWkExJTAj BgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA1MDMyNDE5MDIzNVoXDTA2MDMyNDE5 MDIzNVowVzEOMAwGA1UEBBMFRmFsc2kxDjAMBgNVBCoTBUd1aWRvMRQwEgYDVQQDEwtHdWlk byBGYWxzaTEfMB0GCSqGSIb3DQEJARYQbWFkQG1hZHBpbG90Lm5ldDCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBALZgXEBokuuMpCmSoKs60tUtpuI6I84Wlm2jxR2/P5Yny+uh pYCzR3aNtFo+6lhQKlCM/IqbA+Ok2xKkFfAyVWRXdhn4IIeKikOSfyEbG98Q7uVAFamecdrO 9BdHIWOKgKib1a1MUIDKL9zVPb+b45PriUV9mq5cciUud5KlgGtbb3jNxrLQvAk0Y1/qB0MT +fNbCxPQ3qucSLgAp1gCp3iLRwvnjIim7K9DJPWW4D0LrO/5oRP1beJED7J0C0nABT8utKjt TFfAbQ2BMbC4tRNgEK4V6mom6mS9Wft1ZhKGGgzFCBDu059edMeyAtxoF/Zwobjk/b4gzktK Z/YbsO8CAwEAAaMtMCswGwYDVR0RBBQwEoEQbWFkQG1hZHBpbG90Lm5ldDAMBgNVHRMBAf8E AjAAMA0GCSqGSIb3DQEBBAUAA4GBABbm3GWyPMehQ9HJJF7DzxYIlGjRHQEKPOVu7oPaZiLz 1CrKd7mPy5xyATkunj7lMfgF2jeZB9O33nS+vr440jh9cWwBnHp0p6PK5DlGUGn2ndXBhvA4 FFZPV4CVed8mw6B2NRS1Ul/7ailHpbeEP3pxTqx23Fth2hE0QZXtNaQMMIIDPzCCAqigAwIB AgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4g Q2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEo MCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVl bWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkG A1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEB AQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9R zgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4H v0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB /wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1Ro YXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAc MRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oL LswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsA xRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwh GTXeJLHTHUb/XV9lTzGCAkQwggJAAgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBG cmVlbWFpbCBJc3N1aW5nIENBAgMOV4MwCQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNTA0MjkxMDU0MTZaMCMGCSqGSIb3DQEJBDEW BBRqCvJEPb69bMORAuSeJg9Psm3I9DBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4G CCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAN BgkqhkiG9w0BAQEFAASCAQARcDsyd3n98Qzx/CqBvf0hKuE68JHVIC1X7TsvTshHPo7fwYbg 8kPBdtXTOMyX3qwJ3BkbPTo4TfX0sIXgHGFEuNMIspygYZKnOUXKzb1/TTo5AsQ+mdF60jyX BP60jeTDPFLNuhjCiPr3IGpGGMRPE0+Zb3LnThqtHUEcPXCM/c3M1NZgYtQyVbUfMoT7qLtF GzHAAFoI/5+KN5jmzTSrfyHvJhYMmEeUscTVCD+Z1yJHtMbpgIq5aJDQTt/aJNaiHnArJm6q +paqbTj8GBZ7a7opnqWd/UGIrDM0VBZ9u6Wd9FaOJymuVzP7osqWneJWTTr53SeYPirckT3o gyZl --X1bOJ3K7DJ5YkBrT-- From owner-freebsd-current@FreeBSD.ORG Fri Apr 29 10:56: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 6B39B16A4CE for ; Fri, 29 Apr 2005 10:56:11 +0000 (GMT) Received: from blackwater.lemis.com (wantadilla.lemis.com [192.109.197.135]) by mx1.FreeBSD.org (Postfix) with ESMTP id DBD6A43D41 for ; Fri, 29 Apr 2005 10:56:09 +0000 (GMT) (envelope-from grog@lemis.com) Received: by blackwater.lemis.com (Postfix, from userid 1004) id 2271785843; Fri, 29 Apr 2005 20:26:08 +0930 (CST) Date: Fri, 29 Apr 2005 20:26:08 +0930 From: Greg 'groggy' Lehey To: Jonathan Gray Message-ID: <20050429105608.GQ70593@wantadilla.lemis.com> References: <20050428154859.GA16433@mail.netspace.net.au> <20050428162322.GE747@empiric.icir.org> <20050429070122.GN70593@wantadilla.lemis.com> <20050429071907.GA13459@mail.netspace.net.au> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="YzytRCpZNWCht94M" Content-Disposition: inline In-Reply-To: <20050429071907.GA13459@mail.netspace.net.au> User-Agent: Mutt/1.4.2.1i Organization: The FreeBSD Project Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.FreeBSD.org/ X-PGP-Fingerprint: 9A1B 8202 BCCE B846 F92F 09AC 22E6 F290 507A 4223 cc: freebsd-current@FreeBSD.org Subject: Re: incorrect statement on www page X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 29 Apr 2005 10:56:11 -0000 --YzytRCpZNWCht94M Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Friday, 29 April 2005 at 17:19:07 +1000, Jonathan Gray wrote: > On Fri, Apr 29, 2005 at 04:31:22PM +0930, Greg 'groggy' Lehey wrote: >> On Thursday, 28 April 2005 at 17:23:22 +0100, Bruce M Simpson wrote: >>> On Fri, Apr 29, 2005 at 01:48:59AM +1000, Jonathan Gray wrote: >>>> I came across the following incorrect statement when >>>> browsing http://www.freebsd.org >>>> >>>> "FreeBSD is available free of charge and comes with full source code" >>>> >>>> Sadly I do not think this has been true for some time. >>> >>> I disagree; the wording isn't misleading. However, to address such concerns, >>> it might be better worded as "comes with full source code, and also ships >>> with some binary driver components". >> >> A more accurate statement might be: >> >> "FreeBSD is available free of charge and comes with full source >> code. In addition, many third-party drivers are available, some in >> source, others in binary-only format". >> >> The important thing is that the FreeBSD project is not withholding >> *any* source code. The only binary-only components are from other >> people who don't allow distribution of *their* source. > > If these binary only components come with FreeBSD they are part > of FreeBSD as far as most people are concerned. I suppose that depends on their intellect. How would you describe this distinction? > There are binary components with no publically available source code > in FreeBSD, so it is not full source code. For some definition of "in". Are you trying to imply that we withhold source code to base FreeBSD? Would it be a better product if we were to suppress distribution of those third party components which are available only in binary? > Additionally supporting such things hinders progress on acceptable > alternatives be they drivers with full source or use of other > vendors. How? Greg -- See complete headers for address and phone numbers. --YzytRCpZNWCht94M Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFCchLIIubykFB6QiMRAnfTAKCWscWUW9PO8/YzZPcS1H3ipZggkgCfREkS rD2PmFRzchnpFsY9H+ntoj8= =bubi -----END PGP SIGNATURE----- --YzytRCpZNWCht94M-- From owner-freebsd-current@FreeBSD.ORG Fri Apr 29 11:04: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 2002916A4CE for ; Fri, 29 Apr 2005 11:04:06 +0000 (GMT) Received: from smtp.dkm.cz (smtp.dkm.cz [62.24.64.34]) by mx1.FreeBSD.org (Postfix) with SMTP id C44FA43D39 for ; Fri, 29 Apr 2005 11:04:04 +0000 (GMT) (envelope-from varga@stonehenge.sk) Received: (qmail 9596 invoked by uid 0); 29 Apr 2005 11:04:03 -0000 Received: from r4w254.chello.upc.cz (84.42.150.254) by smtp.dkm.cz with SMTP; 29 Apr 2005 11:04:02 -0000 From: Michal Varga To: freebsd-current@freebsd.org Content-Type: text/plain Organization: Stonehenge Date: Fri, 29 Apr 2005 13:04:59 +0200 Message-Id: <1114772699.22525.5.camel@xenon.stonehenge.sk> Mime-Version: 1.0 X-Mailer: Evolution 2.2.2 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Subject: typo in man ps(1) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 29 Apr 2005 11:04:06 -0000 Hi folks, there is a typo in manual page for ps, the option -a has a word "teminal" instead of "terminal". Present in 5.3 and recent -current. m. -- Michal Varga Stonehenge From owner-freebsd-current@FreeBSD.ORG Fri Apr 29 11:10: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 08F8F16A4CE for ; Fri, 29 Apr 2005 11:10:42 +0000 (GMT) Received: from mp2.macomnet.net (mp2.macomnet.net [195.128.64.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id E8E7343D41 for ; Fri, 29 Apr 2005 11:10:40 +0000 (GMT) (envelope-from maxim@macomnet.ru) Received-SPF: pass (mp2.macomnet.net: domain of maxim@macomnet.ru designates 127.0.0.1 as permitted sender) receiver=mp2.macomnet.net; client_ip=127.0.0.1; envelope-from=maxim@macomnet.ru; Received: from localhost (localhost [127.0.0.1]) by mp2.macomnet.net (8.12.11/8.12.11) with ESMTP id j3TBAd4i071117; Fri, 29 Apr 2005 15:10:39 +0400 (MSD) (envelope-from maxim@macomnet.ru) Date: Fri, 29 Apr 2005 15:10:39 +0400 (MSD) From: Maxim Konovalov To: Michal Varga In-Reply-To: <1114772699.22525.5.camel@xenon.stonehenge.sk> Message-ID: <20050429151031.I70988@mp2.macomnet.net> References: <1114772699.22525.5.camel@xenon.stonehenge.sk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-current@freebsd.org Subject: Re: typo in man ps(1) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 29 Apr 2005 11:10:42 -0000 On Fri, 29 Apr 2005, 13:04+0200, Michal Varga wrote: > Hi folks, > there is a typo in manual page for ps, the option -a has a word > "teminal" instead of "terminal". Present in 5.3 and recent -current. Fixed, thanks. -- Maxim Konovalov From owner-freebsd-current@FreeBSD.ORG Fri Apr 29 11:46: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 6FC2716A4CE for ; Fri, 29 Apr 2005 11:46:37 +0000 (GMT) Received: from mx01.stofanet.dk (mx01.stofanet.dk [212.10.10.11]) by mx1.FreeBSD.org (Postfix) with ESMTP id B09E443D31 for ; Fri, 29 Apr 2005 11:46:36 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from d40a2021.rev.stofanet.dk ([212.10.32.33] helo=critter.freebsd.dk) by mx01.stofanet.dk (envelope-from ) with esmtp id 1DRTx4-0001uA-32 for current@freebsd.org; Fri, 29 Apr 2005 13:46:35 +0200 Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.3/8.13.3) with ESMTP id j3TBkYIA007252 for ; Fri, 29 Apr 2005 13:46:34 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: current@freebsd.org From: Poul-Henning Kamp Date: Fri, 29 Apr 2005 13:46:34 +0200 Message-ID: <7251.1114775194@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Subject: does bridging work in -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, 29 Apr 2005 11:46:37 -0000 I tried to enable bridging to test a multiport ethernet card (www.napatech.com) and I can see packets going into the bridge code when I enable debugging but nothing seems to get sent out. Anyone know if bridging actually works these days ? hex-i386# sysctl net.link.ether.bridge net.link.ether.bridge.version: 031224 net.link.ether.bridge.debug: 2 net.link.ether.bridge.ipf: 0 net.link.ether.bridge.ipfw: 0 net.link.ether.bridge.copy: 0 net.link.ether.bridge.ipfw_drop: 0 net.link.ether.bridge.ipfw_collisions: 0 net.link.ether.bridge.packets: 301 net.link.ether.bridge.dropped: 0 net.link.ether.bridge.predict: 0 net.link.ether.bridge.enable: 1 net.link.ether.bridge.config: nt3,nt7 bdg_timeout: flushing stale entry 7212 bridge_in: 00.00.24.c3.4c.7b ->ff.ff.ff.ff.ff.ff ty 0x0806 dst BDG_BCAST bridge_in: 00.00.24.c3.4c.7b ->ff.ff.ff.ff.ff.ff ty 0x0806 dst BDG_BCAST bridge_in: new addr 00.e0.81.01.9d.2d at 7212 for nt3 bridge_in: 00.e0.81.01.9d.2d ->ff.ff.ff.ff.ff.ff ty 0x0806 dst BDG_BCAST bdg_timeout: flushing stale entry 2232 bridge_in: 00.e0.81.01.9d.2d ->ff.ff.ff.ff.ff.ff ty 0x0806 dst BDG_BCAST bridge_in: 00.e0.81.01.9d.2d ->ff.ff.ff.ff.ff.ff ty 0x0806 dst BDG_BCAST bridge_in: 00.e0.81.01.9d.2d ->ff.ff.ff.ff.ff.ff ty 0x0806 dst BDG_BCAST bridge_in: 00.e0.81.01.9d.2d ->ff.ff.ff.ff.ff.ff ty 0x0806 dst BDG_BCAST bridge_in: new addr 00.00.24.c3.4c.7b at 2232 for nt7 bridge_in: 00.00.24.c3.4c.7b ->ff.ff.ff.ff.ff.ff ty 0x0806 dst BDG_BCAST bridge_in: 00.00.24.c3.4c.7b ->ff.ff.ff.ff.ff.ff ty 0x0806 dst BDG_BCAST bdg_timeout: flushing stale entry 7212 bridge_in: 00.00.24.c3.4c.7b ->ff.ff.ff.ff.ff.ff ty 0x0806 dst BDG_BCAST bridge_in: 00.00.24.c3.4c.7b ->ff.ff.ff.ff.ff.ff ty 0x0806 dst BDG_BCAST bridge_in: 00.00.24.c3.4c.7b ->ff.ff.ff.ff.ff.ff ty 0x0806 dst BDG_BCAST bdg_timeout: flushing stale entry 2232 bridge_in: new addr 00.e0.81.01.9d.2d at 7212 for nt3 bridge_in: 00.e0.81.01.9d.2d ->ff.ff.ff.ff.ff.ff ty 0x0806 dst BDG_BCAST Expensive timeout(9) function: 0xc067dfb8(0) 0.213431874 s bdg_timeout: flushing stale entry 7212 nt0: flags=8803 mtu 1500 ether 00:0d:e9:01:01:c0 nt1: flags=8803 mtu 1500 ether 00:0d:e9:01:01:c1 nt2: flags=8803 mtu 1500 ether 00:0d:e9:01:01:c2 nt3: flags=8903 mtu 1500 ether 00:0d:e9:01:01:c3 nt4: flags=8803 mtu 1500 ether 00:0d:e9:01:01:c4 nt5: flags=8803 mtu 1500 ether 00:0d:e9:01:01:c5 nt6: flags=8803 mtu 1500 ether 00:0d:e9:01:01:c6 nt7: flags=8903 mtu 1500 ether 00:0d:e9:01:01:c7 -- 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 Fri Apr 29 12:11: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 D362616A4CE for ; Fri, 29 Apr 2005 12:11:52 +0000 (GMT) Received: from orb.pobox.com (orb.pobox.com [207.8.226.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8617E43D41 for ; Fri, 29 Apr 2005 12:11:52 +0000 (GMT) (envelope-from discussion-lists@linnet.org) Received: from orb (localhost [127.0.0.1]) by orb.pobox.com (Postfix) with ESMTP id C949D823; Fri, 29 Apr 2005 08:11:48 -0400 (EDT) Received: from thinkdog.local.linnet.org (host217-40-157-153.in-addr.btopenworld.com [217.40.157.153]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by orb.sasl.smtp.pobox.com (Postfix) with ESMTP id 86CBF91; Fri, 29 Apr 2005 08:11:47 -0400 (EDT) Received: from lists by thinkdog.local.linnet.org with local (Exim 4.43 (FreeBSD)) id 1DRULB-000OCH-Un; Fri, 29 Apr 2005 13:11:29 +0100 Date: Fri, 29 Apr 2005 13:11:29 +0100 From: Brian Candler To: Sam Leffler Message-ID: <20050429121129.GA92888@uk.tiscali.com> References: <20050428121447.GA90430@uk.tiscali.com> <42715889.7070202@errno.com> <20050428222831.GB1308@uk.tiscali.com> <42716C48.9070206@errno.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42716C48.9070206@errno.com> User-Agent: Mutt/1.4.2.1i cc: freebsd-current@freebsd.org Subject: Re: wpa_supplicant causes panic in ieee80211_newstate X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 29 Apr 2005 12:11:52 -0000 On Thu, Apr 28, 2005 at 04:05:44PM -0700, Sam Leffler wrote: > >Is there a canonical list of cards which *do* support WPA? I was guessing > >(probably wrongly) that anything under the 80211 layer would. > > ath supports it. Thanks. Unfortunately, it seems that the list of supported cards in ath(4) could do with updating. I just went out and bought a Netgear WG311 - that's exactly what it says on the box. However it's not recognised by the generic kernel, nor by `kldload ath`. According to `pciconf -l -v`, it is: none2@pci2:11:0: class=0x028000 card=0x4c001385 chip=0x9066104c rev=0x00 hdr=0x00 vendor = 'Texas Instruments (TI)' device = 'TNETW1130(ACX111) 802.11b/g Wireless Cardbus/PCI Adapter' class = network Hmm, and now I know this, I find http://lists.freebsd.org/pipermail/freebsd-current/2004-August/033976.html Short of messing with Windoze NDIS drivers, it seems like I have bought myself an expensive blanking plate :-( Regards, Brian. From owner-freebsd-current@FreeBSD.ORG Thu Apr 28 14:19: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 7362F16A4CE; Thu, 28 Apr 2005 14:19:23 +0000 (GMT) Received: from multiplay.co.uk (www1.multiplay.co.uk [212.42.16.7]) by mx1.FreeBSD.org (Postfix) with ESMTP id 64EA343D5D; Thu, 28 Apr 2005 14:19:22 +0000 (GMT) (envelope-from killing@multiplay.co.uk) Received: from stevenp4 ([193.123.241.40]) by multiplay.co.uk (multiplay.co.uk [212.42.16.7]) (MDaemon.PRO.v8.0.1.R) with ESMTP id md50001366620.msg; Thu, 28 Apr 2005 15:15:08 +0100 Message-ID: <069901c54bfd$2967ba40$7f06000a@int.mediasurface.com> From: "Steven Hartland" To: , Date: Thu, 28 Apr 2005 15:18:33 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="Windows-1252"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2527 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 X-Spam-Processed: multiplay.co.uk, Thu, 28 Apr 2005 15:15:08 +0100 (not processed: message from valid local sender) X-MDRemoteIP: 193.123.241.40 X-Return-Path: killing@multiplay.co.uk X-MDAV-Processed: multiplay.co.uk, Thu, 28 Apr 2005 15:15:08 +0100 X-Mailman-Approved-At: Fri, 29 Apr 2005 12:21:47 +0000 Subject: Very low disk performance Highpoint 1820a X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 28 Apr 2005 14:19:23 -0000 I've just finished putting together a new server box spec: Dual AMD 244, 2GB ram, 5 * Seagate SATA 400GB on a Highpoint 1820a RAID 5 array. The machine is currently running 5.4-STABLE ( from the weekend ) After install I did some basic tests and the disk is return very poor performance low in fact than a single disk on a bog standard ATA 100 controller: 5.4-STABLE Highpoint 1820a RAID 5 ( 5 disk ) dd if=/dev/da0 of=/dev/null bs=64k count=10000 10000+0 records in 10000+0 records out 655360000 bytes transferred in 13.348032 secs (49097875 bytes/sec) 5.3-RELEASE Highpoint 454 RAID 5 ( 4 disk ) dd if=/dev/da0 of=/dev/null bs=64k count=10000 10000+0 records in 10000+0 records out 655360000 bytes transferred in 20.410034 secs (32109697 bytes/sec) 5.2.1-RELEASE Intel ICH3 UDMA100 ( 1 disk ) dd if=/dev/ad0 of=/dev/null bs=64k count=10000 10000+0 records in 10000+0 records out 655360000 bytes transferred in 11.142405 secs (58816745 bytes/sec) Obviously something is seriously a miss here somewhere as both the RAID 5 arrays a producing less throughput than a single disk. Where do I start looking? Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone (023) 8024 3137 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-current@FreeBSD.ORG Thu Apr 28 15:33: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 A0DB716A4CF for ; Thu, 28 Apr 2005 15:33:07 +0000 (GMT) Received: from web51602.mail.yahoo.com (web51602.mail.yahoo.com [206.190.38.207]) by mx1.FreeBSD.org (Postfix) with SMTP id 2B3E743D2F for ; Thu, 28 Apr 2005 15:33:07 +0000 (GMT) (envelope-from pfgshield-freebsd@yahoo.com) Received: (qmail 40907 invoked by uid 60001); 28 Apr 2005 15:33:06 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=YFEytW3Rlh9KezjJOisYhXcmnha7Mko27qM/evGMlG6tLdWNzKGt/emlWjUcoIjGrqAcurxfro3i/zPCvhZ+pHRCyOrdL7Kf/HLqgNo53W22hQ8UcUUUH2iBIKKm2V72LWgGE56UQjUgZKrZV4ZStEJJzsD7c3Zepw6XYhtgb10= ; Message-ID: <20050428153306.40902.qmail@web51602.mail.yahoo.com> Received: from [200.119.73.47] by web51602.mail.yahoo.com via HTTP; Thu, 28 Apr 2005 17:33:06 CEST Date: Thu, 28 Apr 2005 17:33:06 +0200 (CEST) From: To: noackjr@alumni.rice.edu, Alexander Leidinger In-Reply-To: 6667 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Fri, 29 Apr 2005 12:21:47 +0000 cc: freebsd-current@freebsd.org Subject: Re: FreeBSD 6 is coming too fast X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: pfgshield-freebsd@yahoo.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2005 15:33:07 -0000 --- Jonathan Noack wrote: ... > > I take it the PR is ports/75416. x11-toolkits/xview does not have a > maintainer. Pedro, why don't you take the maintainership? It seems > you've already done the work; why not share it? OS development is a > very dynamic process; in order to take 2 steps forward we often have to > take 1 step back. Working through this requires patience and teamwork. > Until you start contributing to the team, you may not receive the > attention you desire. > Hmm.. I've contributed a LOT to the ports tree over the years, I don't see any lack of respect from the ports guys, but I have found it more confortable to contribute without taking the full responsability of maintaining the ports. The problem here is in the OS, not the port. Solaris and Linux both have the call and the xview code doesn't make any provision for OSs without it, commenting it out (my workaround) will probably break some applications and send out the wrong signal that removing legacy stuff is a good idea. > > I was under the impression that the diablo-jdk13 port was just a tested, > binary version of the jdk13 port. Perhaps I am wrong on that. In any > case, I'm using both linux and native JDKs in production with no issues. > Java works great on FreeBSD 5.x, the distribution issues are SUN's and only SUN's fault. Nevertheless, they are real issues for people with slow computers :(. Pedro. ___________________________________ Nuovo Yahoo! Messenger: E' molto più divertente: Audibles, Avatar, Webcam, Giochi, Rubrica… Scaricalo ora! http://it.messenger.yahoo.it From owner-freebsd-current@FreeBSD.ORG Thu Apr 28 15:54:51 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 680) id 3D10816A4CF; Thu, 28 Apr 2005 15:54:51 +0000 (GMT) Date: Thu, 28 Apr 2005 15:54:51 +0000 From: Darren Reed To: Scott Long Message-ID: <20050428155451.GA2192@hub.freebsd.org> References: <20050428025836.E1ED67306E@freebsd-current.sentex.ca> <20050428145519.GB92579@ip.net.ua> <4270FB26.50805@samsco.org> <20050428152622.GC92579@ip.net.ua> <427100CC.8080604@samsco.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <427100CC.8080604@samsco.org> User-Agent: Mutt/1.4.2.1i X-Mailman-Approved-At: Fri, 29 Apr 2005 12:21:47 +0000 cc: Darren Reed cc: current@freebsd.org Subject: Re: LINT broken due to ipfilter X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 28 Apr 2005 15:54:51 -0000 On Thu, Apr 28, 2005 at 09:27:08AM -0600, Scott Long wrote: > Leaving the tree unbuildable for 3 days is unacceptable. I doubt that > any other active OSS project would tolerate it, and I'm sure that Sun > wouldn't tolerate it either. Well, FreeBSD seems to have a history of allowing this...I seem to recall some other part of the build being broken when I did the initial commit for ipf...not to mention there being many times in the past when I've seen comments about the build being broken in one way or another. ...and to compare it with Sun...there's one build command (equivalent of building userland + kernel bits) that you have to submit with your request to integrate. But to compare the effort I can spend there vs here, well, this gets whatever time I have available, which maybe 1 or 4 or any number of hours or minutes inbetween, plus it is upto me to provide my own resources. You can't compare doing development work that you get paid for with that you do in your own free time, at your own expense. Anyone who thinks you can is sadly mistaken. All of us have varying levels of time we can put into the project and I'm sure we all put it as much effort as we can, given all the other constraints and requirements. My single biggest issue remains the number of boxes needed to keep things compiling on FreeBSD. 4.11, 5.4, -current. That is a really tough ask on anyone and last I checked, there's only a ref4 and a ref5. So....if you want to make it easier for people like me to make sure they haven't broken the build, put a target in src/Makefile that achieves this. That is, buildworld and buildkernel and build LINT and whatever else for a single platform. Or at least I think buildworld and buildkernel are required, seperately. "universe" is too much. Having said all that, I appreciate any assistance others can give, especially clues on what to do with rescue. Darren From owner-freebsd-current@FreeBSD.ORG Thu Apr 28 16:27:55 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 680) id 7EB4A16A4CF; Thu, 28 Apr 2005 16:27:55 +0000 (GMT) Date: Thu, 28 Apr 2005 16:27:55 +0000 From: Darren Reed To: Scott Long Message-ID: <20050428162755.GA5668@hub.freebsd.org> References: <20050428025836.E1ED67306E@freebsd-current.sentex.ca> <20050428145519.GB92579@ip.net.ua> <4270FB26.50805@samsco.org> <20050428152622.GC92579@ip.net.ua> <427100CC.8080604@samsco.org> <20050428155451.GA2192@hub.freebsd.org> <427108E6.4010202@samsco.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <427108E6.4010202@samsco.org> User-Agent: Mutt/1.4.2.1i X-Mailman-Approved-At: Fri, 29 Apr 2005 12:21:47 +0000 cc: Darren Reed cc: Ruslan Ermilov cc: current@FreeBSD.ORG Subject: Re: LINT broken due to ipfilter X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 28 Apr 2005 16:27:55 -0000 On Thu, Apr 28, 2005 at 10:01:42AM -0600, Scott Long wrote: .... > To my > recollection, you have not done a successfull ipfilter import in at > least two years. Yes, we all appreciate your contribution with > IPFilter, but it's also disruptive, this time especially. And given that it is usually disruptive I've tried to get it done ahead of it being "the last minute", although it's close to 11th hourish. I only realised my error earlier in the day in what I did for thinking I was ready to do a commit/import - I'd done a "make -k buildworld" to get all of the error output, subsequently forgot about the -k the next morning, looked at the bottom of the make log and saw it finished ok. :/ > >So....if you want to make it easier for people like me to make sure they > >haven't broken the build, put a target in src/Makefile that achieves this. > >That is, buildworld and buildkernel and build LINT and whatever else for > >a single platform. Or at least I think buildworld and buildkernel are > >required, seperately. "universe" is too much. > > 'make universe' is the command. And given that you still have build > problems on 64-bit machines, this command is not 'too much'. There are > fast freebsd.org machines that can run this. If you don't know, then > please ask. Hmmm, well the impression I got from reading the Makfile was that it'd build sparc/arm/x86/everything. I don't have the diskspace, never mind CPU for that...could we sittle for a galactic build target that builds everything required (user + kernel + LINT) for a single platform? Is sledge.freebsd.org the build box you're referring to here? Or is there another that's available for us? Thanks, Darren From owner-freebsd-current@FreeBSD.ORG Thu Apr 28 23:55: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 992B316A4CE for ; Thu, 28 Apr 2005 23:55:44 +0000 (GMT) Received: from smtp-out6.blueyonder.co.uk (smtp-out6.blueyonder.co.uk [195.188.213.9]) by mx1.FreeBSD.org (Postfix) with ESMTP id 58B2543D3F for ; Thu, 28 Apr 2005 23:55:43 +0000 (GMT) (envelope-from xfb52@dial.pipex.com) Received: from [82.41.37.55] ([82.41.37.55]) by smtp-out6.blueyonder.co.uk with Microsoft SMTPSVC(5.0.2195.6713); Fri, 29 Apr 2005 00:56:21 +0100 Message-ID: <427177FD.50809@dial.pipex.com> Date: Fri, 29 Apr 2005 00:55:41 +0100 From: Alex Zbyslaw User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-GB; rv:1.7) Gecko/20040627 X-Accept-Language: en, en-us MIME-Version: 1.0 To: Emanuel Strobl References: <200504262010.49509@harrymail> <86k6mo0xmh.fsf@xps.des.no> <427157B7.6040203@mac.com> <200504290053.51912@harrymail> In-Reply-To: <200504290053.51912@harrymail> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Apr 2005 23:56:21.0371 (UTC) FILETIME=[E090DCB0:01C54C4D] X-Mailman-Approved-At: Fri, 29 Apr 2005 12:21:47 +0000 cc: freebsd-current@freebsd.org Subject: Re: groff alternative? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 28 Apr 2005 23:55:44 -0000 Emanuel Strobl wrote: >In case of cat pages it does, but like I wrote I want to be able to add >packages and read their man pages without having to involve any other >machine. So there's no way arround a lean *roff... > > Since no-one had a sensible answer, why not try a version of original nroff from say 4.3BSD. Hunting around, I found this: http://www.tuhs.org/. Hopefully the most used macros will have stayed the same. You'd need to grab usr.src and I'm sure it would need some tweaking... depends just how much you care, I guess. --Alex From owner-freebsd-current@FreeBSD.ORG Fri Apr 29 05:48: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 7326D16A4CE for ; Fri, 29 Apr 2005 05:48:40 +0000 (GMT) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.205]) by mx1.FreeBSD.org (Postfix) with ESMTP id EC75943D5F for ; Fri, 29 Apr 2005 05:48:39 +0000 (GMT) (envelope-from k3rn3lpanic@gmail.com) Received: by wproxy.gmail.com with SMTP id 69so749305wra for ; Thu, 28 Apr 2005 22:48:39 -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=OvnDTtYU0+8gT2jkZX6+OVYrthqwBZHlGCNjufmIQk/Y/uutWpHfzUOeG6K0LywMxrNIJAuX0GpTE7O/AIrPVMp/GP5aMZx4Cz4pDWsc3r09b/Nmg47/o5PsNdnnAP/tJunGgHY1dh3B3Y6anFNZqH1Wkwq1TL+zoA5B1IuUigk= Received: by 10.54.33.39 with SMTP id g39mr1546826wrg; Thu, 28 Apr 2005 22:48:39 -0700 (PDT) Received: by 10.54.72.15 with HTTP; Thu, 28 Apr 2005 22:48:39 -0700 (PDT) Message-ID: <87f5270b05042822487e8f0ae@mail.gmail.com> Date: Fri, 29 Apr 2005 07:48:39 +0200 From: =?ISO-8859-1?Q?Ulrik_G=FCnther?= To: Chuck Swiger In-Reply-To: <4271602E.5030707@mac.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <20050428154859.GA16433@mail.netspace.net.au> <20050428160414.GA21634@outcold.yadt.co.uk> <20050428160706.GA2033@mail.netspace.net.au> <20050428164730.GB34380@troutmask.apl.washington.edu> <20050428165709.GA76059@energistic.com> <4271602E.5030707@mac.com> X-Mailman-Approved-At: Fri, 29 Apr 2005 12:21:47 +0000 cc: Jonathan Gray cc: freebsd-current@freebsd.org Subject: Re: incorrect statement on www page X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: =?ISO-8859-1?Q?Ulrik_G=FCnther?= List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Apr 2005 05:48:40 -0000 I agree with that as well. The components named above can be considered as third-party software and have, as such, nothing to do with the "real" operating system. If you want to be really specific, write something like "FreeBSD comes with complete sourcecode, but the files xyz.c, abc.h, ahs.o,... are missing ;) Why does anyone have a problem with those binary components? I think it is okay if vendors invested lots of money into developing their products and do not want anyone to know how the stuff really works... Of course, Open Source drivers would be better, but this is a good consent. Have a nice day anyway, Ulrik On 4/29/05, Chuck Swiger wrote: > Steve Ames wrote: > > On Thu, Apr 28, 2005 at 09:47:30AM -0700, Steve Kargl wrote: > >> You need to specify the (lots of stuff) better. > >> Because the following are found on my system. > >> > >>>http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/hptmv/i386-elf.raid.= o.uu > >>>http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/contrib/dev/nve/i386/nve= netlib.o.bz2.uu > > > > Sure. But they aren't source. This is rather a sad discussion as 3rd pa= rty > > drivers really aren't part of the OS. >=20 > Agreed. Third-party drivers under a proprietary license are not really p= art > of FreeBSD, although, if the license permits, FreeBSD can include the bin= ary > objects into CVS and/or put them into the .ISO images for CDs. Other > proprietary drivers have more onerous restrictions, and are handled via p= orts. >=20 > The current approach is more convenient for users, and I don't suggest > changing that. However, I would not be unhappy if the documentation was > clarified, or if the HPT RAID driver was moved from src/sys/dev/ to > src/sys/contrib/dev/ to clearly indicate that it is contributed by a thir= d party. >=20 > -- > -Chuck >=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.org= " > From owner-freebsd-current@FreeBSD.ORG Fri Apr 29 12:28: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 0130F16A4CE; Fri, 29 Apr 2005 12:28:50 +0000 (GMT) Received: from ash25e.internode.on.net (ash25e.adl2.internode.on.net [203.16.214.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3A07943D55; Fri, 29 Apr 2005 12:28:49 +0000 (GMT) (envelope-from smckay@internode.on.net) Received: from dungeon.home (ppp112-89.lns1.bne3.internode.on.net [59.167.112.89])j3TCSkQC049622; Fri, 29 Apr 2005 21:58:47 +0930 (CST) (envelope-from smckay@internode.on.net) Received: from dungeon.home (localhost [127.0.0.1]) by dungeon.home (8.13.1/8.11.6) with ESMTP id j3TCPx5O011151; Fri, 29 Apr 2005 22:26:59 +1000 (EST) (envelope-from mckay) Message-Id: <200504291226.j3TCPx5O011151@dungeon.home> To: Ryan Sommers References: <57436.216.177.243.42.1114582155.localmail@webmail.dnswatch.com> <1072.172.16.0.199.1114624239.squirrel@172.16.0.1> <200504280257.j3S2vXEO007344@dungeon.home> <200504280606.45379.lofi@freebsd.org> <1587.66.166.104.222.1114717166.squirrel@66.166.104.222> In-Reply-To: <1587.66.166.104.222.1114717166.squirrel@66.166.104.222> from "Ryan Sommers" at "Thu, 28 Apr 2005 13:39:26 -0600" Date: Fri, 29 Apr 2005 22:25:59 +1000 From: Stephen McKay cc: freebsd-current@freebsd.org cc: Michael Nottebrock cc: Stephen McKay Subject: Re: boot banner project X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 29 Apr 2005 12:28:50 -0000 On Thursday, 28th April 2005, "Ryan Sommers" wrote: >Michael Nottebrock said: >> With CRTs on the retreat though, less and less people care about refresh >> rates ... you'll probably join that camp at some point as well. :-) > >I wouldn't count them out just yet! I still have a 7 year old 19" Sony >Trinitron that is kicking butt, despite the fact that it has about 10 >battle scars from rolling around in a truck bed (don't ask). I haven't >switched it with an LCD just because it still has better clarity and color >quality than any LCD I've seen. Indeed! I haven't found an LCD I can stand to look at. I expect the screen to look the same from any angle, and no LCD does that yet. And the colour reproduction. Yuck! Let's not even talk about stuck pixels... Ahem. So, if anyone is fiddling with graphical boots, please bear in mind that VESA refresh rates of at least 75Hz (preferably 85Hz to 100Hz) are still necessary. Stephen. PS My personal guess is that LCDs will be "good enough" in about 5 years. Let's see if I'm still a CRT curmudgeon in 2010, picking through landfill looking for working CRTs. :-) From owner-freebsd-current@FreeBSD.ORG Fri Apr 29 12:46: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 1EDA316A4CE for ; Fri, 29 Apr 2005 12:46:52 +0000 (GMT) Received: from gwmail1.grupos.com.br (gwmail1.grupos.com.br [66.90.64.125]) by mx1.FreeBSD.org (Postfix) with ESMTP id D5B8543D1F for ; Fri, 29 Apr 2005 12:46:51 +0000 (GMT) (envelope-from marcus@corp.grupos.com.br) Received: from corp.grupos.com.br (unknown [150.162.166.55]) by gwmail1.grupos.com.br (Postfix) with ESMTP id EA3FD3D3CE for ; Fri, 29 Apr 2005 09:46:50 -0300 (BRT) Received: from [150.162.166.51] (unknown [150.162.166.51]) by corp.grupos.com.br (Postfix) with ESMTP id 283D8562D for ; Fri, 29 Apr 2005 09:46:50 -0300 (BRT) Message-ID: <42722CB9.7050702@corp.grupos.com.br> Date: Fri, 29 Apr 2005 09:46:49 -0300 From: Marcus Grando User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <069901c54bfd$2967ba40$7f06000a@int.mediasurface.com> In-Reply-To: <069901c54bfd$2967ba40$7f06000a@int.mediasurface.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Very low disk performance Highpoint 1820a X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 29 Apr 2005 12:46:52 -0000 You try with iozone (benchmarks/iozone)? Regards Steven Hartland wrote: > I've just finished putting together a new server box spec: > Dual AMD 244, 2GB ram, 5 * Seagate SATA 400GB on a > Highpoint 1820a RAID 5 array. > The machine is currently running 5.4-STABLE ( from the > weekend ) After install I did some basic tests and the > disk is return very poor performance low in fact than a > single disk on a bog standard ATA 100 controller: > > 5.4-STABLE Highpoint 1820a RAID 5 ( 5 disk ) > dd if=/dev/da0 of=/dev/null bs=64k count=10000 > 10000+0 records in > 10000+0 records out > 655360000 bytes transferred in 13.348032 secs (49097875 bytes/sec) > > 5.3-RELEASE Highpoint 454 RAID 5 ( 4 disk ) > dd if=/dev/da0 of=/dev/null bs=64k count=10000 > 10000+0 records in > 10000+0 records out > 655360000 bytes transferred in 20.410034 secs (32109697 bytes/sec) > > 5.2.1-RELEASE Intel ICH3 UDMA100 ( 1 disk ) > dd if=/dev/ad0 of=/dev/null bs=64k count=10000 > 10000+0 records in > 10000+0 records out > 655360000 bytes transferred in 11.142405 secs (58816745 bytes/sec) > > Obviously something is seriously a miss here somewhere as > both the RAID 5 arrays a producing less throughput than > a single disk. > > Where do I start looking? > > Steve -- Marcus Grando Grupos Internet S/A marcus(at)corp.grupos.com.br From owner-freebsd-current@FreeBSD.ORG Fri Apr 29 12: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 600E216A4CE for ; Fri, 29 Apr 2005 12:50:11 +0000 (GMT) Received: from multiplay.co.uk (www1.multiplay.co.uk [212.42.16.7]) by mx1.FreeBSD.org (Postfix) with ESMTP id B41E943D2F for ; Fri, 29 Apr 2005 12:50:10 +0000 (GMT) (envelope-from killing@multiplay.co.uk) Received: from stevenp4 ([193.123.241.40]) by multiplay.co.uk (multiplay.co.uk [212.42.16.7]) (MDaemon.PRO.v8.0.1.R) with ESMTP id md50001369128.msg for ; Fri, 29 Apr 2005 13:46:30 +0100 Message-ID: <099601c54cb9$f27d8420$7f06000a@int.mediasurface.com> From: "Steven Hartland" To: "Marcus Grando" , References: <069901c54bfd$2967ba40$7f06000a@int.mediasurface.com> <42722CB9.7050702@corp.grupos.com.br> Date: Fri, 29 Apr 2005 13:49:56 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="Windows-1252"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2527 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 X-Spam-Processed: multiplay.co.uk, Fri, 29 Apr 2005 13:46:30 +0100 (not processed: message from valid local sender) X-MDRemoteIP: 193.123.241.40 X-Return-Path: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-current@freebsd.org X-MDAV-Processed: multiplay.co.uk, Fri, 29 Apr 2005 13:46:32 +0100 Subject: Re: Very low disk performance Highpoint 1820a X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 29 Apr 2005 12:50:11 -0000 Yep shows similar results. ----- Original Message ----- From: "Marcus Grando" > You try with iozone (benchmarks/iozone)? ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone (023) 8024 3137 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-current@FreeBSD.ORG Fri Apr 29 13:11: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 64DD816A4CE for ; Fri, 29 Apr 2005 13:11:39 +0000 (GMT) Received: from basement.kutulu.org (211.215.33.65.cfl.res.rr.com [65.33.215.211]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0AF5043D45 for ; Fri, 29 Apr 2005 13:11:39 +0000 (GMT) (envelope-from kutulu@kutulu.org) Received: from [127.0.0.1] (localhost [127.0.0.1]) by basement.kutulu.org (Postfix) with ESMTP id 5FF0539; Fri, 29 Apr 2005 09:11:37 -0400 (EDT) Message-ID: <42723287.3050806@kutulu.org> Date: Fri, 29 Apr 2005 09:11:35 -0400 From: Mike Edenfield User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <427196C0.5040506@chuckr.org> <20050429085113.GF789@empiric.icir.org> In-Reply-To: <20050429085113.GF789@empiric.icir.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: Chuck Robey cc: current Subject: Re: tcsh X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 29 Apr 2005 13:11:39 -0000 On Fri, Apr 29, 2005 at 02:06:56AM +0000, Chuck Robey wrote: >Any chance that something so basic as this, that improves things so >awfully much, could be added to the .tcshrc? If the idea is liked well >enough, I will edit it enough so that the special use of prompt strings >that are specific to tcsh is made conditional. Just an FYI -- there is a port that installs a must souped-up tcshrc: /usr/ports/shells/tcshrc You might look to see if that includes the changes you want. --Mike From owner-freebsd-current@FreeBSD.ORG Fri Apr 29 13:33: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 1209516A4CE for ; Fri, 29 Apr 2005 13:33:03 +0000 (GMT) Received: from ms1.as.pvp.se (dns.pvp.se [213.64.187.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id BA20F43D41 for ; Fri, 29 Apr 2005 13:33:02 +0000 (GMT) (envelope-from kama@pvp.se) Received: by ms1.as.pvp.se (Postfix, from userid 1001) id E2232A7; Fri, 29 Apr 2005 15:32:58 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by ms1.as.pvp.se (Postfix) with ESMTP id DDE51A6; Fri, 29 Apr 2005 15:32:58 +0200 (CEST) Date: Fri, 29 Apr 2005 15:32:58 +0200 (CEST) From: kama X-X-Sender: kama@ns1.as.pvp.se To: Steven Hartland In-Reply-To: <099601c54cb9$f27d8420$7f06000a@int.mediasurface.com> Message-ID: <20050429153131.D22614@ns1.as.pvp.se> References: <069901c54bfd$2967ba40$7f06000a@int.mediasurface.com> <099601c54cb9$f27d8420$7f06000a@int.mediasurface.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Marcus Grando cc: freebsd-current@freebsd.org Subject: Re: Very low disk performance Highpoint 1820a X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 29 Apr 2005 13:33:03 -0000 NOTE: this problem does not only occur on that controller. I have the same problems on my Compaq Smart Array 6404's (ciss). /Bjorn On Fri, 29 Apr 2005, Steven Hartland wrote: > Yep shows similar results. > > ----- Original Message ----- > From: "Marcus Grando" > > > > You try with iozone (benchmarks/iozone)? > > > > ================================================ > This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. > > In the event of misdirection, illegible or incomplete transmission please telephone (023) 8024 3137 > or return the E.mail to postmaster@multiplay.co.uk. > > _______________________________________________ > 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 29 13:38: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 3C03F16A4CE for ; Fri, 29 Apr 2005 13:38:23 +0000 (GMT) Received: from mortis.over-yonder.net (adsl-12-42-198.jan.bellsouth.net [65.12.42.198]) by mx1.FreeBSD.org (Postfix) with ESMTP id 19CFA43D53 for ; Fri, 29 Apr 2005 13:38:22 +0000 (GMT) (envelope-from fullermd@over-yonder.net) Received: by mortis.over-yonder.net (Postfix, from userid 100) id CB1FC20F21; Fri, 29 Apr 2005 08:38:20 -0500 (CDT) Date: Fri, 29 Apr 2005 08:38:20 -0500 From: "Matthew D. Fuller" To: /dev/null Message-ID: <20050429133820.GJ81486@over-yonder.net> References: <427196C0.5040506@chuckr.org> <52053.216.177.243.35.1114762792.localmail@webmail.dnswatch.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <52053.216.177.243.35.1114762792.localmail@webmail.dnswatch.com> X-Editor: vi X-OS: FreeBSD User-Agent: Mutt/1.5.9i-fullermd.2 cc: Chuck Robey cc: freebsd-current@freebsd.org Subject: Re: tcsh X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 29 Apr 2005 13:38:23 -0000 On Fri, Apr 29, 2005 at 01:19:51AM -0700 I heard the voice of /dev/null, and lo! it spake thus: > > > > set prompt="%m:%{^[[34m%}`id -nu`%{^[[0m%}:%~:%{^[[31m#%h^[[0m%}%#" > > alias cd 'cd \!*;set prompt="%m%{^[[32m%}:`id > > -nu`%{^[[0m%}:%~:%{^[[31m#%h^[[0m%}%#"' > > > > FWIW here's mine: > set prompt = "\n%~\n%t\n%d, %D `/bin/hostname -s`# " > Short and sweet. As you can see it leaves little doubt as to where I am or > what day and time it is. As long as we're comparing, mine varies depending on what's in the config file (see ): ---------------------------------- # Test: should we use full domain, or just hostname? if( "$DOMAIN_PROMPT" == "YES" ) then setenv DP '%M' else setenv DP '%m' endif # Username? if( "$USER_PROMPT" == "YES" ) then setenv UP '%n@' else setenv UP '' endif if( "$CUSTOM_PROMPT_ENABLE" == "YES" ) then set prompt="$CUSTOM_PROMPT" else if( "$ROOT_PROMPT_TEST" == "YES" && $EUID == 0 ) then #set prompt="{%~} root@${DP}: %%" set prompt="${DP}:%/\n%Broot%%%b " else # This yields [time] hostname:cwd \n(tty):{line#}% set prompt="%B[%P]%b ${UP}${DP}:%~\n(%l):{%h}%% " endif endif ---------------------------------- On most systems, I turn $DOMAIN_PROMPT and $USER_PROMPT on to remind me, but on my box I leave both off. The result for me as a normal user is: [8:35:10] mortis:~ (ttypd):{1573}% and as root mortis:/root root% Note that the time on the former, and the 'root%' on the latter, are bolded. It IS, as well, intentional that my normal prompt uses %~, which displays the current dir with appropriate ~'s for homedirs, while roots prompt uses %/ which does not. Avoids confusion, IMO... -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. From owner-freebsd-current@FreeBSD.ORG Fri Apr 29 13:53: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 3167116A4CE for ; Fri, 29 Apr 2005 13:53:21 +0000 (GMT) Received: from csa.cs.okstate.edu (a.cs.okstate.edu [139.78.113.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8B8EF43D3F for ; Fri, 29 Apr 2005 13:53:20 +0000 (GMT) (envelope-from lreid@cs.okstate.edu) Received: by csa.cs.okstate.edu (Postfix, from userid 601) id 21B9BA0643; Fri, 29 Apr 2005 08:53:19 -0500 (CDT) To: phk@phk.freebsd.dk, current@freebsd.org Received: from 164.58.79.196 (auth. user lreid@a.cs.okstate.edu) by cs.okstate.edu with HTTP; Fri, 29 Apr 2005 07:53:19 -0600 X-IlohaMail-Blah: lreid@a.cs.okstate.edu X-IlohaMail-Method: mail() [mem] X-IlohaMail-Dummy: moo X-Mailer: IlohaMail/0.8.12 (On: cs.okstate.edu) In-Reply-To: <7251.1114775194@critter.freebsd.dk> From: "Reid Linnemann" Bounce-To: "Reid Linnemann" Errors-To: "Reid Linnemann" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-Id: <20050429135319.21B9BA0643@csa.cs.okstate.edu> Date: Fri, 29 Apr 2005 08:53:19 -0500 (CDT) Subject: Re: does bridging work in -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, 29 Apr 2005 13:53:21 -0000 I hade used the kernel bridge interface in -current several months ago, and it did work - though it took some fiddling. IIRC, the config sysctl parsing didn't exactly match what was described in the manpage - try 'sysctl net.link.ether.bridge.config="nt3 nt7"'. Again, IIRC this solved my problems. -Reid On 4/29/2005, "Poul-Henning Kamp" wrote: > >I tried to enable bridging to test a multiport ethernet card (www.napatech.com) >and I can see packets going into the bridge code when I enable debugging >but nothing seems to get sent out. > >Anyone know if bridging actually works these days ? > > hex-i386# sysctl net.link.ether.bridge > net.link.ether.bridge.version: 031224 > net.link.ether.bridge.debug: 2 > net.link.ether.bridge.ipf: 0 > net.link.ether.bridge.ipfw: 0 > net.link.ether.bridge.copy: 0 > net.link.ether.bridge.ipfw_drop: 0 > net.link.ether.bridge.ipfw_collisions: 0 > net.link.ether.bridge.packets: 301 > net.link.ether.bridge.dropped: 0 > net.link.ether.bridge.predict: 0 > net.link.ether.bridge.enable: 1 > net.link.ether.bridge.config: nt3,nt7 > >bdg_timeout: flushing stale entry 7212 >bridge_in: 00.00.24.c3.4c.7b ->ff.ff.ff.ff.ff.ff ty 0x0806 dst BDG_BCAST >bridge_in: 00.00.24.c3.4c.7b ->ff.ff.ff.ff.ff.ff ty 0x0806 dst BDG_BCAST >bridge_in: new addr 00.e0.81.01.9d.2d at 7212 for nt3 >bridge_in: 00.e0.81.01.9d.2d ->ff.ff.ff.ff.ff.ff ty 0x0806 dst BDG_BCAST >bdg_timeout: flushing stale entry 2232 >bridge_in: 00.e0.81.01.9d.2d ->ff.ff.ff.ff.ff.ff ty 0x0806 dst BDG_BCAST >bridge_in: 00.e0.81.01.9d.2d ->ff.ff.ff.ff.ff.ff ty 0x0806 dst BDG_BCAST >bridge_in: 00.e0.81.01.9d.2d ->ff.ff.ff.ff.ff.ff ty 0x0806 dst BDG_BCAST >bridge_in: 00.e0.81.01.9d.2d ->ff.ff.ff.ff.ff.ff ty 0x0806 dst BDG_BCAST >bridge_in: new addr 00.00.24.c3.4c.7b at 2232 for nt7 >bridge_in: 00.00.24.c3.4c.7b ->ff.ff.ff.ff.ff.ff ty 0x0806 dst BDG_BCAST >bridge_in: 00.00.24.c3.4c.7b ->ff.ff.ff.ff.ff.ff ty 0x0806 dst BDG_BCAST >bdg_timeout: flushing stale entry 7212 >bridge_in: 00.00.24.c3.4c.7b ->ff.ff.ff.ff.ff.ff ty 0x0806 dst BDG_BCAST >bridge_in: 00.00.24.c3.4c.7b ->ff.ff.ff.ff.ff.ff ty 0x0806 dst BDG_BCAST >bridge_in: 00.00.24.c3.4c.7b ->ff.ff.ff.ff.ff.ff ty 0x0806 dst BDG_BCAST >bdg_timeout: flushing stale entry 2232 >bridge_in: new addr 00.e0.81.01.9d.2d at 7212 for nt3 >bridge_in: 00.e0.81.01.9d.2d ->ff.ff.ff.ff.ff.ff ty 0x0806 dst BDG_BCAST >Expensive timeout(9) function: 0xc067dfb8(0) 0.213431874 s >bdg_timeout: flushing stale entry 7212 > >nt0: flags=8803 mtu 1500 > ether 00:0d:e9:01:01:c0 >nt1: flags=8803 mtu 1500 > ether 00:0d:e9:01:01:c1 >nt2: flags=8803 mtu 1500 > ether 00:0d:e9:01:01:c2 >nt3: flags=8903 mtu 1500 > ether 00:0d:e9:01:01:c3 >nt4: flags=8803 mtu 1500 > ether 00:0d:e9:01:01:c4 >nt5: flags=8803 mtu 1500 > ether 00:0d:e9:01:01:c5 >nt6: flags=8803 mtu 1500 > ether 00:0d:e9:01:01:c6 >nt7: flags=8903 mtu 1500 > ether 00:0d:e9:01:01:c7 > > > > >-- >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 Fri Apr 29 14:20: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 4DDDD16A4CE for ; Fri, 29 Apr 2005 14:20:44 +0000 (GMT) Received: from www.mmlab.cse.yzu.edu.tw (www.mmlab.cse.yzu.edu.tw [140.138.150.166]) by mx1.FreeBSD.org (Postfix) with ESMTP id AA45E43D1F for ; Fri, 29 Apr 2005 14:20:41 +0000 (GMT) (envelope-from avatar@mmlab.cse.yzu.edu.tw) Received: by www.mmlab.cse.yzu.edu.tw (qmail, from userid 1000) id A047E4EFCDA; Fri, 29 Apr 2005 22:20:40 +0800 (CST) Received: from localhost (localhost [127.0.0.1]) by www.mmlab.cse.yzu.edu.tw (qmail) with ESMTP id 9BC654EFCD7; Fri, 29 Apr 2005 22:20:40 +0800 (CST) Date: Fri, 29 Apr 2005 22:20:40 +0800 (CST) From: Tai-hwa Liang To: Brian Candler In-Reply-To: <20050429121129.GA92888@uk.tiscali.com> Message-ID: <05042922184316.40144@www.mmlab.cse.yzu.edu.tw> References: <20050428121447.GA90430@uk.tiscali.com> <42715889.7070202@errno.com> <20050428222831.GB1308@uk.tiscali.com> <42716C48.9070206@errno.com> <20050429121129.GA92888@uk.tiscali.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed cc: Sam Leffler cc: freebsd-current@freebsd.org Subject: Re: wpa_supplicant causes panic in ieee80211_newstate X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 29 Apr 2005 14:20:44 -0000 On Fri, 29 Apr 2005, Brian Candler wrote: > On Thu, Apr 28, 2005 at 04:05:44PM -0700, Sam Leffler wrote: >>> Is there a canonical list of cards which *do* support WPA? I was guessing >>> (probably wrongly) that anything under the 80211 layer would. >> >> ath supports it. > > Thanks. Unfortunately, it seems that the list of supported cards in ath(4) > could do with updating. > > I just went out and bought a Netgear WG311 - that's exactly what it says on > the box. However it's not recognised by the generic kernel, nor by > `kldload ath`. According to `pciconf -l -v`, it is: > > none2@pci2:11:0: class=0x028000 card=0x4c001385 chip=0x9066104c rev=0x00 hdr=0x00 > vendor = 'Texas Instruments (TI)' > device = 'TNETW1130(ACX111) 802.11b/g Wireless Cardbus/PCI Adapter' > class = network > > Hmm, and now I know this, I find > http://lists.freebsd.org/pipermail/freebsd-current/2004-August/033976.html > > Short of messing with Windoze NDIS drivers, it seems like I have bought > myself an expensive blanking plate :-( Looks like yet another revision trick performed by vendor: http://hd.blogdns.org:3000/cgi-bin/wifi.cgi?Adaptors#311 http://www.leenooks.com/112 Perhaps we should document the extra "v1" in the man page? Cheers, Tai-hwa Liang From owner-freebsd-current@FreeBSD.ORG Fri Apr 29 14:29: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 343A216A4CE for ; Fri, 29 Apr 2005 14:29:38 +0000 (GMT) Received: from mail-in-06.arcor-online.net (mail-in-06.arcor-online.net [151.189.21.46]) by mx1.FreeBSD.org (Postfix) with ESMTP id ACC2643D2D for ; Fri, 29 Apr 2005 14:29:37 +0000 (GMT) (envelope-from lofi@freebsd.org) Received: from mail-in-03-z2.arcor-online.net (mail-in-03-z2.arcor-online.net [151.189.8.15]) by mail-in-06.arcor-online.net (Postfix) with ESMTP id 8865E297D; Fri, 29 Apr 2005 16:29:33 +0200 (CEST) Received: from mail-in-03.arcor-online.net (mail-in-03.arcor-online.net [151.189.21.43]) by mail-in-03-z2.arcor-online.net (Postfix) with ESMTP id 1F38F164E05; Fri, 29 Apr 2005 16:29:36 +0200 (CEST) Received: from lofi.dyndns.org (dsl-213-023-208-099.arcor-ip.net [213.23.208.99]) by mail-in-03.arcor-online.net (Postfix) with ESMTP id 341168A4E; Fri, 29 Apr 2005 16:29:33 +0200 (CEST) Received: from kiste.my.domain (lofi@kiste.my.domain [192.168.8.4]) (authenticated bits=0) by lofi.dyndns.org (8.13.3/8.13.3) with ESMTP id j3TETRui017629 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Fri, 29 Apr 2005 16:29:28 +0200 (CEST) (envelope-from lofi@freebsd.org) From: Michael Nottebrock To: freebsd-current@freebsd.org Date: Fri, 29 Apr 2005 16:29:22 +0200 User-Agent: KMail/1.8 References: <57436.216.177.243.42.1114582155.localmail@webmail.dnswatch.com> <20050429005319.GA17799@laptoxa.toxa.lan> <60093.216.177.243.35.1114761721.localmail@webmail.dnswatch.com> In-Reply-To: <60093.216.177.243.35.1114761721.localmail@webmail.dnswatch.com> X-Face: =Ym$`&q\+S2X$4`X%x%6"L4>Y,$]<":'L%c9"#7#`2tb&E&wsN31on!N\)3BD[g<=?utf-8?q?=2EjnfV=5B=0A=093=23?=>XchLK,o;>bD>c:]^;:>0>vyZ.X[,63GW`&M>}nYnr]-Fp``,[[@lJ!QL|sfW!s)=?utf-8?q?A2!*=0A=09vNkB/=7CL-?=>&QdSbQg X-Virus-Scanned: by amavisd-new cc: /dev/null cc: Toxa Subject: Re: boot banner project X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 29 Apr 2005 14:29:38 -0000 --nextPart1456448.A4gffKK8sR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Friday, 29. April 2005 10:02, /dev/null wrote: > > "And that's everyone likes in BSD's" > WOW! Were you elected Official Spokesperson for everyone? ;) Everybody has an expert opinion on painting bikesheds. =2D-=20 ,_, | Michael Nottebrock | lofi@freebsd.org (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org --nextPart1456448.A4gffKK8sR Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQBCckTGXhc68WspdLARAirIAJ9Dk5wN1KjRn39d0J7aqBYQYgEmXQCgir1h wIeMo3b6QN+obl8meyva+z4= =sQWi -----END PGP SIGNATURE----- --nextPart1456448.A4gffKK8sR-- From owner-freebsd-current@FreeBSD.ORG Fri Apr 29 14:35: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 5787F16A4CE for ; Fri, 29 Apr 2005 14:35:36 +0000 (GMT) Received: from ion.gank.org (ion.gank.org [69.55.238.164]) by mx1.FreeBSD.org (Postfix) with ESMTP id 225EA43D3F for ; Fri, 29 Apr 2005 14:35:34 +0000 (GMT) (envelope-from craig@xfoil.gank.org) Received: by ion.gank.org (mail, from userid 1001) id AF83A2AB24; Fri, 29 Apr 2005 09:35:33 -0500 (CDT) Date: Fri, 29 Apr 2005 09:35:30 -0500 From: Craig Boston To: Kevin Oberman Message-ID: <20050429143529.GA88104@nowhere> Mail-Followup-To: Craig Boston , Kevin Oberman , Steve Kargl , freebsd-current@freebsd.org References: <20050421202042.GA82753@troutmask.apl.washington.edu> <20050421205902.6F3E75D07@ptavv.es.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050421205902.6F3E75D07@ptavv.es.net> User-Agent: Mutt/1.4.2.1i cc: freebsd-current@freebsd.org cc: Steve Kargl Subject: Re: firefox stuck in libthr or kserel! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 29 Apr 2005 14:35:36 -0000 On Thu, Apr 21, 2005 at 01:59:02PM -0700, Kevin Oberman wrote: > This is a problem that has been brought up on gnome@, ports@ and > current@ from time to time. There are many, many sites, all heavily > flash based, that exhibit this problem with any native browser to use > the linux flash6 plugin. As the flash code is the linux binary, it is > not likely to be there. (These sites don't hang on linux systems.) FWIW, I use linux-mozilla-1.7.5 and linux-flashplugin-7.0r25_1 to access flash based sites with no problem. The flash6/7 problems seem to be related to using the pluginwrapper to get it to work with native browsers. Most sites that I actually want to see the flash content on I already know ahead of time so it's not a big deal for me to use a different browser. And the rest of the web is nice and flash-free in native konqueror/firefox :p The only problem I've noticed is the audio lag on sites like homestarrunner, but I think the same thing happens on Linux. Craig From owner-freebsd-current@FreeBSD.ORG Fri Apr 29 15:01: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 C2F6616A4CE for ; Fri, 29 Apr 2005 15:01:19 +0000 (GMT) Received: from orb.pobox.com (orb.pobox.com [207.8.226.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6589D43D39 for ; Fri, 29 Apr 2005 15:01:19 +0000 (GMT) (envelope-from discussion-lists@linnet.org) Received: from orb (localhost [127.0.0.1]) by orb.pobox.com (Postfix) with ESMTP id AB47E933; Fri, 29 Apr 2005 11:01:15 -0400 (EDT) Received: from thinkdog.local.linnet.org (host217-40-157-153.in-addr.btopenworld.com [217.40.157.153]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by orb.sasl.smtp.pobox.com (Postfix) with ESMTP id 50CCE8C; Fri, 29 Apr 2005 11:01:14 -0400 (EDT) Received: from lists by thinkdog.local.linnet.org with local (Exim 4.43 (FreeBSD)) id 1DRWzB-000OO2-4m; Fri, 29 Apr 2005 16:00:57 +0100 Date: Fri, 29 Apr 2005 16:00:57 +0100 From: Brian Candler To: killing@multiplay.co.uk Message-ID: <20050429150057.GA93707@uk.tiscali.com> References: <069901c54bfd$2967ba40$7f06000a@int.mediasurface.com> <42722CB9.7050702@corp.grupos.com.br> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42722CB9.7050702@corp.grupos.com.br> User-Agent: Mutt/1.4.2.1i cc: freebsd-current@freebsd.org Subject: Re: Very low disk performance Highpoint 1820a X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 29 Apr 2005 15:01:19 -0000 > >5.4-STABLE Highpoint 1820a RAID 5 ( 5 disk ) > >dd if=/dev/da0 of=/dev/null bs=64k count=10000 > >10000+0 records in > >10000+0 records out > >655360000 bytes transferred in 13.348032 secs (49097875 bytes/sec) > > > >5.3-RELEASE Highpoint 454 RAID 5 ( 4 disk ) > >dd if=/dev/da0 of=/dev/null bs=64k count=10000 > >10000+0 records in > >10000+0 records out > >655360000 bytes transferred in 20.410034 secs (32109697 bytes/sec) > > > >5.2.1-RELEASE Intel ICH3 UDMA100 ( 1 disk ) > >dd if=/dev/ad0 of=/dev/null bs=64k count=10000 > >10000+0 records in > >10000+0 records out > >655360000 bytes transferred in 11.142405 secs (58816745 bytes/sec) > > > >Obviously something is seriously a miss here somewhere as > >both the RAID 5 arrays a producing less throughput than > >a single disk. > > > >Where do I start looking? Just some ideas: - try reconfiguring your array as 5 separate disks, and dd from a single disk. If it's still slower than your ATA disk, then it's probably SCSI transfers or controller I/O bandwidth which are slowing things down. If you get equal or better performance than your ATA disk, then it becomes likely that the RAID configuration is the bottleneck. - try reconfiguring your array as two mirrored pairs, and do the same test again. RAID5 isn't necessarily a good choice for high-performance applications; a single block write requires two reads and two writes (to the target data disk and the parity disk), and therefore write access to the array is likely to be *slower* than to a single disk. You might be better off with mirroring. It handles random writes better, and you may get double the random read performance since there are two copies of all the data. RAID5 is acceptable if your application is mostly read-only though (which your dd test is, of course) Brian. From owner-freebsd-current@FreeBSD.ORG Fri Apr 29 15:09: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 E1E3816A4D0 for ; Fri, 29 Apr 2005 15:09:04 +0000 (GMT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7807943D39 for ; Fri, 29 Apr 2005 15:09:04 +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 j3TF92nQ021206; Fri, 29 Apr 2005 08:09:02 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id j3TF910F021205; Fri, 29 Apr 2005 08:09:01 -0700 Date: Fri, 29 Apr 2005 08:09:01 -0700 From: Brooks Davis To: Tai-hwa Liang Message-ID: <20050429150901.GA18010@odin.ac.hmc.edu> References: <20050428121447.GA90430@uk.tiscali.com> <42715889.7070202@errno.com> <20050428222831.GB1308@uk.tiscali.com> <42716C48.9070206@errno.com> <20050429121129.GA92888@uk.tiscali.com> <05042922184316.40144@www.mmlab.cse.yzu.edu.tw> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="1yeeQ81UyVL57Vl7" Content-Disposition: inline In-Reply-To: <05042922184316.40144@www.mmlab.cse.yzu.edu.tw> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=1.9 required=8.0 tests=WEIRD_PORT autolearn=no version=2.63 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu cc: Sam Leffler cc: freebsd-current@freebsd.org cc: Brian Candler Subject: Re: wpa_supplicant causes panic in ieee80211_newstate X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 29 Apr 2005 15:09:05 -0000 --1yeeQ81UyVL57Vl7 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Apr 29, 2005 at 10:20:40PM +0800, Tai-hwa Liang wrote: > On Fri, 29 Apr 2005, Brian Candler wrote: > >On Thu, Apr 28, 2005 at 04:05:44PM -0700, Sam Leffler wrote: > >>>Is there a canonical list of cards which *do* support WPA? I was guess= ing > >>>(probably wrongly) that anything under the 80211 layer would. > >> > >>ath supports it. > > > >Thanks. Unfortunately, it seems that the list of supported cards in ath(= 4) > >could do with updating. > > > >I just went out and bought a Netgear WG311 - that's exactly what it says= on > >the box. However it's not recognised by the generic kernel, nor by > >`kldload ath`. According to `pciconf -l -v`, it is: > > > >none2@pci2:11:0: class=3D0x028000 card=3D0x4c001385 chip=3D0x9066= 104c=20 > >rev=3D0x00 hdr=3D0x00 > > vendor =3D 'Texas Instruments (TI)' > > device =3D 'TNETW1130(ACX111) 802.11b/g Wireless Cardbus/PCI Adapte= r' > > class =3D network > > > >Hmm, and now I know this, I find > >http://lists.freebsd.org/pipermail/freebsd-current/2004-August/033976.ht= ml > > > >Short of messing with Windoze NDIS drivers, it seems like I have bought > >myself an expensive blanking plate :-( >=20 > Looks like yet another revision trick performed by vendor: >=20 > http://hd.blogdns.org:3000/cgi-bin/wifi.cgi?Adaptors#311 > http://www.leenooks.com/112 >=20 > Perhaps we should document the extra "v1" in the man page? Since we're not attempting to keep the list complete, I've removed in in HEAD and will do so in stable. The v1's are probably unobtainable at this point anyway so it's just asking for confusion to leave it in. -- 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 --1yeeQ81UyVL57Vl7 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFCck4NXY6L6fI4GtQRAhS9AJ9vcrmLMD7Tslcicm5OnnXwGoitagCg5+5Q 9tzrVOJrNzwrmqWj2rPnjVk= =4ws4 -----END PGP SIGNATURE----- --1yeeQ81UyVL57Vl7-- From owner-freebsd-current@FreeBSD.ORG Fri Apr 29 15:10: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 7E8D016A4D1 for ; Fri, 29 Apr 2005 15:10:03 +0000 (GMT) Received: from multiplay.co.uk (www1.multiplay.co.uk [212.42.16.7]) by mx1.FreeBSD.org (Postfix) with ESMTP id D007443D54 for ; Fri, 29 Apr 2005 15:10:02 +0000 (GMT) (envelope-from killing@multiplay.co.uk) Received: from stevenp4 ([193.123.241.40]) by multiplay.co.uk (multiplay.co.uk [212.42.16.7]) (MDaemon.PRO.v8.0.1.R) with ESMTP id md50001369628.msg for ; Fri, 29 Apr 2005 16:05:59 +0100 Message-ID: <0a8401c54ccd$6f346ac0$7f06000a@int.mediasurface.com> From: "Steven Hartland" To: "Brian Candler" References: <069901c54bfd$2967ba40$7f06000a@int.mediasurface.com> <42722CB9.7050702@corp.grupos.com.br> <20050429150057.GA93707@uk.tiscali.com> Date: Fri, 29 Apr 2005 16:09:26 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2527 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 X-Spam-Processed: multiplay.co.uk, Fri, 29 Apr 2005 16:05:59 +0100 (not processed: message from valid local sender) X-MDRemoteIP: 193.123.241.40 X-Return-Path: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-current@freebsd.org X-MDAV-Processed: multiplay.co.uk, Fri, 29 Apr 2005 16:06:01 +0100 cc: freebsd-current@freebsd.org Subject: Re: Very low disk performance Highpoint 1820a X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 29 Apr 2005 15:10:03 -0000 ----- Original Message ----- From: "Brian Candler" > - try reconfiguring your array as 5 separate disks, and dd from a single > disk. If it's still slower than your ATA disk, then it's probably SCSI > transfers or controller I/O bandwidth which are slowing things down. Was gonna try pulling one of the disks and seeing what the indiviual disk performance was but considering 3 other controllers from different manufacturers are all showing the same on 5.x but not on 4.x ( from one report ) It suggests something more sinister in 5.x > If you get equal or better performance than your ATA disk, then it becomes > likely that the RAID configuration is the bottleneck. Inlikely considering it has 8 SATA 150 channels on 64bit PCI-X @ 133Mhz > - try reconfiguring your array as two mirrored pairs, and do the same test > again. > RAID5 isn't necessarily a good choice for high-performance applications; a > single block write requires two reads and two writes (to the target data > disk and the parity disk), and therefore write access to the array is likely > to be *slower* than to a single disk. You might be better off with > mirroring. It handles random writes better, and you may get double the > random read performance since there are two copies of all the data. Primarly interested in read and considering write performance us 140MB/s compared with 40MB/s read not really worried about that atm > RAID5 is acceptable if your application is mostly read-only though (which > your dd test is, of course) Thanks for the ideas though :) Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone (023) 8024 3137 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-current@FreeBSD.ORG Fri Apr 29 15:16: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 E855E16A4CE for ; Fri, 29 Apr 2005 15:16:36 +0000 (GMT) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.207]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7C84443D1F for ; Fri, 29 Apr 2005 15:16:36 +0000 (GMT) (envelope-from lihong.chen@gmail.com) Received: by wproxy.gmail.com with SMTP id 69so943635wri for ; Fri, 29 Apr 2005 08:16: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:mime-version:content-type:content-transfer-encoding:content-disposition; b=hs7s6FQRu8LyYF0wMafAzNZ3ahiJC7Qn3GLOENg6P2L2qmgAvchwILgX97qg2O8DxGWy3ZzqXS6gOWjstt8dTSd08y/D801kodKPZK03ukWwITlJWNe5Hggh6DhcePONMqDJXPCAt5A6u5S2pXq6Kg9szzUMrejhU9ya2jZuEpY= Received: by 10.54.79.5 with SMTP id c5mr1408025wrb; Fri, 29 Apr 2005 08:16:33 -0700 (PDT) Received: by 10.54.2.75 with HTTP; Fri, 29 Apr 2005 08:16:33 -0700 (PDT) Message-ID: Date: Fri, 29 Apr 2005 23:16:33 +0800 From: Lihong Chen To: current@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Subject: buildworld failed with '-O3' in 6-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Lihong Chen List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Apr 2005 15:16:37 -0000 Hi! I try to buildworld using gcc -O3, but some file will failed. they are using fuctions not consist with declared, like these: --- /usr/src/lib/libc/rpc/getpublickey.c.orig=09Fri Apr 29 02:10:53 2005 +++ /usr/src/lib/libc/rpc/getpublickey.c=09Fri Apr 29 02:13:02 2005 @@ -175,5 +175,5 @@ =09if (__getpublickey_LOCAL !=3D NULL) =09=09return(__getpublickey_LOCAL(netname, publickey)); =09else -=09=09return(__getpublickey_real(netname, publickey)); +=09=09return(__getpublickey_real((char*)netname, publickey)); } --- /usr/src/sbin/ip6fw/ip6fw.c.orig=09Fri Apr 29 07:24:33 2005 +++ /usr/src/sbin/ip6fw/ip6fw.c=09Fri Apr 29 07:25:47 2005 @@ -1112,7 +1112,7 @@ =09=09=09=09if (!ac) =09=09=09=09=09show_usage("missing argument" =09=09=09=09=09 " for ``icmptypes''"); -=09=09=09=09fill_icmptypes(rule.fw_icmp6types, +=09=09=09=09fill_icmptypes((u_long*)rule.fw_icmp6types, =09=09=09=09 av, &rule.fw_flg); =09=09=09=09av++; ac--; continue; =09=09=09} --- /usr/src/lib/libc/net/res_debug.c.orig=09Fri Apr 29 02:00:24 2005 +++ /usr/src/lib/libc/net/res_debug.c=09Fri Apr 29 02:01:53 2005 @@ -783,7 +783,7 @@ =09if (cp >=3D maxcp) =09=09goto defaults; =20 -=09siz =3D precsize_aton(&cp); +=09siz =3D precsize_aton((char**)&cp); =09 =09while (!isspace((unsigned char)*cp) && (cp < maxcp)) /* if trailing garbage or m */ =09=09cp++; @@ -794,7 +794,7 @@ =09if (cp >=3D maxcp) =09=09goto defaults; =20 -=09hp =3D precsize_aton(&cp); +=09hp =3D precsize_aton((char**)&cp); =20 =09while (!isspace((unsigned char)*cp) && (cp < maxcp)) /* if trailing garbage or m */ =09=09cp++; @@ -805,7 +805,7 @@ =09if (cp >=3D maxcp) =09=09goto defaults; =20 -=09vp =3D precsize_aton(&cp); +=09vp =3D precsize_aton((char**)&cp); =20 defaults: From owner-freebsd-current@FreeBSD.ORG Fri Apr 29 15:18: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 4559816A4CE for ; Fri, 29 Apr 2005 15:18:34 +0000 (GMT) Received: from orb.pobox.com (orb.pobox.com [207.8.226.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id C77A843D49 for ; Fri, 29 Apr 2005 15:18:33 +0000 (GMT) (envelope-from discussion-lists@linnet.org) Received: from orb (localhost [127.0.0.1]) by orb.pobox.com (Postfix) with ESMTP id 30D097D7; Fri, 29 Apr 2005 11:18:30 -0400 (EDT) Received: from thinkdog.local.linnet.org (host217-40-157-153.in-addr.btopenworld.com [217.40.157.153]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by orb.sasl.smtp.pobox.com (Postfix) with ESMTP id C72938B; Fri, 29 Apr 2005 11:18:28 -0400 (EDT) Received: from lists by thinkdog.local.linnet.org with local (Exim 4.43 (FreeBSD)) id 1DRXFs-000OOo-2H; Fri, 29 Apr 2005 16:18:12 +0100 Date: Fri, 29 Apr 2005 16:18:12 +0100 From: Brian Candler To: Sam Leffler Message-ID: <20050429151811.GB93707@uk.tiscali.com> References: <20050428121447.GA90430@uk.tiscali.com> <42715889.7070202@errno.com> <20050428222831.GB1308@uk.tiscali.com> <42716C48.9070206@errno.com> <20050429121129.GA92888@uk.tiscali.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050429121129.GA92888@uk.tiscali.com> User-Agent: Mutt/1.4.2.1i cc: freebsd-current@freebsd.org Subject: Re: wpa_supplicant causes panic in ieee80211_newstate X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 29 Apr 2005 15:18:34 -0000 On Fri, Apr 29, 2005 at 01:11:29PM +0100, Brian Candler wrote: > Short of messing with Windoze NDIS drivers, it seems like I have bought > myself an expensive blanking plate :-( I have given the NDIS driver a try, but haven't been able to make it work. Firstly, following steps at http://dannyman.toldme.com/2005/01/05/freebsd-howto-ndisulate-windows-drivers/ - copied the XP .inf and .sys files into /usr/src/sys/modules/if_ndis - ran ndiscvt to generate ndis_driver_data.h - make && make install - kldload if_ndis Nothing new in ifconfig, nothing shown in kernel messages. Unloaded modules, tried again using the Win2K drivers. Same. This time also copied *.bin and *.BIN to /compat/ndis/ in case these are firmware files, but this didn't help. The filenames are FW1130.BIN FwRad16.bin FwRad17.bin I can see FwRad{16,17}.bin referenced from the .inf file, but not FW1130.BIN Next tried ndisgen on the Win2K drivers. The module that this produced manages to detect the card but immediately panic the kernel: # kldload ./netwg311_2K_sys.ko ndis0: mem 0xfaffc000-0xfaffdfff,0xfafc0000-0xfafdffff irq 11 at device 11.0 on pci2 ndis0: [GIANT-LOCKED] ndis0: NDIS API version: 5.0 Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x4 fault code = supervisor write, page not present instruction pointer = 0x20:0xc07fe94c stack pointer = 0x28:0xcbffec9c frame pointer = 0x28:0xcbffecb0 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resum, IOPL = 0 current process = 22 (irq11: ifpi0 xl0++) [thread pid 22 tid 100014 ] Stopped at atomic_cmpset_int+0xc: lock cmpxchgl %ecx,0(%edx) db> trace Tracing pid 22 tid 100014 td 0xc1521d80 atomic_cmpset_int(4,2,c18f1000,cbffece4,c19009c9) at atomic_cmpset_int+0xc KfAcquireSpinLock(4,0,0,c1925c40,c1544c00) at KfAcquireSpinLock+0x21 ndis_intr(c18f1000) at ndis_intr+0x3d ithread_loop(c1544c00,cbffed38,c1544c00,c064610c,0) at ithread_loop+0x120 fork_exit(c064610c,c1544c00,cbffed38) at fork_exit+0xa0 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xcbffed6c, ebp = 0 --- db > (this was the second attempt; a background fsck was going on at the time, I don't know if this affects things). Interestingly, pid 22 was the same IRQ process which caused a panic when I was messing with my if_wi card. However that card was removed when I put the netgear in. Finally I tried rebuilding the whole kernel, this time with device ndis options NDISAPI (device wlan was already present), remembering that the Win2K ndis_driver_data.h is still in /usr/src/sys/modules/if_ndis This doesn't detect or report anything ndis-related at bootup, and ifconfig shows nothing. However I'm at a loss to work out how it is supposed to function in the first place; I've grepped across the whole of /usr/src/sys for "ndis_driver_data" and don't find it anywhere. However, the ndis(4) manpage insists that "ndis_driver_data.h" is what this file needs to be called. Any clues? Final note: with my new ndis-integrated kernel running, I tried again # kldload ./netwg311_2K_sys.ko and got a different panic: ndis0: mem 0xfaffc000-0xfaffdfff,0xfafc0000-0xfafdffff irq 11 at device 11.0 on pci2 ndis0: [GIANT-LOCKED] ndis0: NDIS API version: 5.0 Slab at 0xc2108cb8, freei 89 = 0 panic: Duplicate free of item 0xc2108590 from zone 0xc10522c0(16) cpuid = 0 KDB: enter: panic [thread pid 538 tid 100064 ] Stopped at kbd_enter+0x2b: nop db> pid 538 is the "kldload" process. There is a very long backtrace which I'd prefer not to type in full, but omitting the hex arguments and most of the offsets you get: kdb_enter(...) at kdb_enter+0x2b panic(...) at panic+0x127 uma_dbg_free(...) uma_zfree_arg(...) free(...) ExFreePool(...) NdisCloseFile(...) _end(...) at 0xc15b5761 netwg311_2K_sys_drv_data_start(...) at 0xc20fadb1 x86_stdcall_call(...) ndis_attach(...) ndis_attach_pci(...) device_attach(...) device_probe_and_attach(...) pci_driver_added(...) devclass_add_driver(...) driver_module_handler(...) module_register_init(...) linker_file_sysinit(...) linker_load_file(...) linker_load_module(...) kldload(...) syscall(...) Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (304, FreeBSD ELF32, kldload), eip = 0x280b61af, esp=0xbfbfec7c, ebp = 0xbfbfecbc --- db > Hope that's of some use to someone. Regards, Brian. P.S. the ndis(4) manpage has a reference to ndisapi(9), but that page doesn't seem to exist. From owner-freebsd-current@FreeBSD.ORG Fri Apr 29 15: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 C4CEE16A4CE for ; Fri, 29 Apr 2005 15:28:28 +0000 (GMT) Received: from orb.pobox.com (orb.pobox.com [207.8.226.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8D16B43D49 for ; Fri, 29 Apr 2005 15:28:28 +0000 (GMT) (envelope-from discussion-lists@linnet.org) Received: from orb (localhost [127.0.0.1]) by orb.pobox.com (Postfix) with ESMTP id 3370990B; Fri, 29 Apr 2005 11:28:25 -0400 (EDT) Received: from thinkdog.local.linnet.org (host217-40-157-153.in-addr.btopenworld.com [217.40.157.153]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by orb.sasl.smtp.pobox.com (Postfix) with ESMTP id DE66E8D; Fri, 29 Apr 2005 11:28:22 -0400 (EDT) Received: from lists by thinkdog.local.linnet.org with local (Exim 4.43 (FreeBSD)) id 1DRXPH-000OPr-SY; Fri, 29 Apr 2005 16:27:55 +0100 Date: Fri, 29 Apr 2005 16:27:55 +0100 From: Brian Candler To: Lihong Chen Message-ID: <20050429152755.GA93843@uk.tiscali.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i cc: current@freebsd.org Subject: Re: buildworld failed with '-O3' in 6-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, 29 Apr 2005 15:28:28 -0000 On Fri, Apr 29, 2005 at 11:16:33PM +0800, Lihong Chen wrote: > Hi! > I try to buildworld using gcc -O3, but some file will failed. > they are using fuctions not consist with declared, like these: > --- /usr/src/lib/libc/rpc/getpublickey.c.orig Fri Apr 29 02:10:53 2005 > +++ /usr/src/lib/libc/rpc/getpublickey.c Fri Apr 29 02:13:02 2005 > @@ -175,5 +175,5 @@ > if (__getpublickey_LOCAL != NULL) > return(__getpublickey_LOCAL(netname, publickey)); > else > - return(__getpublickey_real(netname, publickey)); > + return(__getpublickey_real((char*)netname, publickey)); > } Surely better to avoid casts, which will hide errors later on. Instead just make things consistent, either by __getpublickey_real(netname, publickey) - char *netname; + const char *netname; or by int getpublickey(netname, publickey) - const char *netname; + char *netname; as appropriate semantically. From owner-freebsd-current@FreeBSD.ORG Fri Apr 29 16: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 7CC6816A4CE for ; Fri, 29 Apr 2005 16:02:24 +0000 (GMT) Received: from dragon.NUXI.org (trang.nuxi.com [66.93.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 93B5243D46 for ; Fri, 29 Apr 2005 16:02:23 +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 j3TG2MAj002493 for ; Fri, 29 Apr 2005 09:02:22 -0700 (PDT) (envelope-from obrien@dragon.NUXI.org) Received: (from obrien@localhost) by dragon.NUXI.org (8.13.3/8.13.1/Submit) id j3TG2Mu7002492 for freebsd-current@freebsd.org; Fri, 29 Apr 2005 09:02:22 -0700 (PDT) (envelope-from obrien) Date: Fri, 29 Apr 2005 09:02:22 -0700 From: "David O'Brien" To: freebsd-current@freebsd.org Message-ID: <20050429160222.GA2264@dragon.NUXI.org> Mail-Followup-To: obrien@freebsd.org, freebsd-current@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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] ufs_dirbad: bad dir 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: Fri, 29 Apr 2005 16:02:24 -0000 FreeBSD 6.0-CURRENT FreeBSD 6.0-CURRENT #486: Mon Apr 25 09:41:31 PDT 2005 [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"] GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd". #0 doadump () at pcpu.h:165 165 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); (kgdb) where #0 doadump () at pcpu.h:165 #1 0xc04dd3b2 in boot (howto=260) at ../../../kern/kern_shutdown.c:397 #2 0xc04dd763 in panic (fmt=0xc067b7f4 "ufs_dirbad: bad dir") at ../../../kern/kern_shutdown.c:553 #3 0xc05d913d in ufs_dirbad (ip=0x0, offset=0, how=0x0) at ../../../ufs/ufs/ufs_lookup.c:598 #4 0xc05d88bd in ufs_lookup (ap=0xf123c8f4) at ../../../ufs/ufs/ufs_lookup.c:286 #5 0xc064b16e in VOP_CACHEDLOOKUP_APV (vop=0x0, a=0xf123c8f4) at vnode_if.c:153 #6 0xc053459d in vfs_cache_lookup (ap=0x0) at vnode_if.h:82 #7 0xc064b08e in VOP_LOOKUP_APV (vop=0x0, a=0xf123c998) at vnode_if.c:100 #8 0xc05390de in lookup (ndp=0xf123cbc4) at vnode_if.h:56 #9 0xc053899f in namei (ndp=0xf123cbc4) at ../../../kern/vfs_lookup.c:201 #10 0xc054c13f in vn_open_cred (ndp=0xf123cbc4, flagp=0xf123ccc4, cmode=384, cred=0xc9176980, fdidx=7) at ../../../kern/vfs_vnops.c:184 #11 0xc054be83 in vn_open (ndp=0x0, flagp=0x0, cmode=0, fdidx=0) at ../../../kern/vfs_vnops.c:91 #12 0xc0544578 in kern_open (td=0xc8c02d80, path=0x0, pathseg=UIO_USERSPACE, flags=1, mode=438) at ../../../kern/vfs_syscalls.c:972 #13 0xc0544476 in open (td=0x0, uap=0xf123cd04) at ../../../kern/vfs_syscalls.c:938 #14 0xc063ad22 in syscall (frame= {tf_fs = 59, tf_es = 59, tf_ds = 59, tf_edi = 4, tf_esi = 673883752, tf_ebp = -1077945272, tf_isp = -249311900, tf_ebx = 673801428, tf_edx = 0, tf_ecx = 0, tf_eax = 5, tf_trapno = 22, tf_err = 2, tf_eip = 673231535, tf_cs = 51, tf_eflags = 514, tf_esp = -1077945316, tf_ss = 59}) at ../../../i386/i386/trap.c:951 #15 0xc0626baf in Xint0x80_syscall () at ../../../i386/i386/exception.s:200 #16 0x0000003b in ?? () #17 0x0000003b in ?? () #18 0x0000003b in ?? () #19 0x00000004 in ?? () #20 0x282aa668 in ?? () #21 0xbfbfdc48 in ?? () #22 0xf123cd64 in ?? () #23 0x282964d4 in ?? () #24 0x00000000 in ?? () #25 0x00000000 in ?? () #26 0x00000005 in ?? () #27 0x00000016 in ?? () #28 0x00000002 in ?? () #29 0x2820b2af in ?? () #30 0x00000033 in ?? () #31 0x00000202 in ?? () #32 0xbfbfdc1c in ?? () #33 0x0000003b in ?? () #34 0x00000000 in ?? () #35 0x00000000 in ?? () #36 0x00000000 in ?? () #37 0x00000000 in ?? () #38 0x45f2a000 in ?? () #39 0xc6391400 in ?? () #40 0xc8c02d80 in ?? () #41 0xf123c6fc in ?? () #42 0xf123c6dc in ?? () #43 0xc2bc0600 in ?? () #44 0xc04f1200 in sched_switch (td=0x282aa668, newtd=0x282964d4, flags=Cannot access memory at address 0xbfbfdc58 ) at ../../../kern/sched_4bsd.c:971 Previous frame inner to this frame (corrupt stack?) From owner-freebsd-current@FreeBSD.ORG Fri Apr 29 16:23: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 4E9A516A4CF for ; Fri, 29 Apr 2005 16:23:28 +0000 (GMT) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id CFE7443D54 for ; Fri, 29 Apr 2005 16:23:27 +0000 (GMT) (envelope-from jameskamlyn@gmail.com) Received: by zproxy.gmail.com with SMTP id 40so1423994nzk for ; Fri, 29 Apr 2005 09:23:27 -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=Q0pFYTQa/agkLuvJSrxJkSLW4OyvAfkdjMWIMuUQe5lXy9MTEEg5XNnSQqhACvZJvXlVHrckaF0tVU8ymUVAzcy2LWd6eoRbWSJI0XmXw0oZ9arvAfTtnNRKi8VejWdv8tOyMmj2kD1GdprhF6XwPKyOTcieqHn5SGhPhia9oDE= Received: by 10.36.41.14 with SMTP id o14mr213386nzo; Fri, 29 Apr 2005 09:23:27 -0700 (PDT) Received: by 10.36.41.8 with HTTP; Fri, 29 Apr 2005 09:23:27 -0700 (PDT) Message-ID: Date: Fri, 29 Apr 2005 17:23:27 +0100 From: James Kamlyn 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: Fatal trap 1: privileged instruction fault while in kernel mode X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: James Kamlyn List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Apr 2005 16:23:28 -0000 Hi, Dies on boot just after reaching the login prompt, running 5.4-STABLE as of yesterday. Motherboard is a Abit VH6, dmesg included below. kernel trap 1 with interrupts disabled Fatal trap 1: privileged instruction fault while in kernel mode instruction pointer =3D 0x8:0xc07a9a87 stack pointer =3D 0x10:0xdc6d8b0c frame pointer =3D 0x10:0xdc6d8b94 code segment =3D base 0x0, limit 0xfffff, type 0x1b =3D DPL 0, pres 1, def32 1, gran 1 processor eflags =3D resume, IOPL =3D 0 current process =3D 11 (idle) [thread pid 11 tid 100003 ] Stopped at __qdivrem+0x2f7: subl %esi,%edx db> wh Tracing pid 11 tid 100003 td 0xc1dff480 __qdivrem(0,80000000,369e99,0,0) at __qdivrem+0x2f7 __udivdi3(0,80000000,369e99,0) at __udivdi3+0x16 tc_windup(dc6d8c34,c05eb1dc,dc6d8c88,dc6d8c88,c1dfcc80) at tc_windup+0x255 tc_ticktock(dc6d8c88) at tc_ticktock+0x25 hardclock(dc6d8c88) at hardclock+0x18 clkintr(dc6d8c88) at clkintr+0x87 intr_execute_handlers(c08a53a0,dc6d8c88,0,c1f11700,c1f11718) at intr_execute_handlers+0x71 atpic_handle_intr(0) at atpic_handle_intr+0x7e Xatpic_intr0() at Xatpic_intr0+0x20 --- interrupt, eip =3D 0xc0a26635, esp =3D 0xdc6d8ccc, ebp =3D 0xdc6d8ccc -= -- acpi_cpu_c1(c08c5b00,0,c0803f53,0,c1dfec5c) at acpi_cpu_c1+0x5 acpi_cpu_idle(dc6d8cfc,c05fafa1,dc6d8d24,c05fae12,0) at acpi_cpu_idle+0xcf cpu_idle(dc6d8d24,c05fae12,0,dc6d8d38,c08c5b00) at cpu_idle+0x1f idle_proc(0,dc6d8d38,c08c5b00,0,c0803e63) at idle_proc+0x11 fork_exit(c05faf90,0,dc6d8d38) at fork_exit+0x66 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip =3D 0, esp =3D 0xdc6d8d6c, ebp =3D 0 --- db> 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 5.4-STABLE #0: Thu Apr 28 16:53:32 UTC 2005 root@ignite:/usr/obj/usr/src/sys/DEBUG WARNING: WITNESS option enabled, expect reduced performance. Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel Pentium III (935.46-MHz 686-class CPU) Origin =3D "GenuineIntel" Id =3D 0x686 Stepping =3D 6 Features=3D0x383f9ff real memory =3D 805240832 (767 MB) avail memory =3D 778235904 (742 MB) npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard acpi0: Power Button (fixed) Timecounter "ACPI-safe" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x4008-0x400b on acpi0 cpu0: on acpi0 acpi_throttle0: on cpu0 acpi_button0: on acpi0 acpi_button1: on acpi0 pcib0: port 0x6000-0x607f,0x5000-0x500f,0x4080-0x40ff,0x4000-0x407f,0xcf8-0xcff on acpi0 pci0: on pcib0 agp0: mem 0xd0000000-0xd3ffffff at device 0.0 on pci0 pcib1: at device 1.0 on pci0 pci1: on pcib1 pci1: at device 0.0 (no driver attached) isab0: at device 7.0 on pci0 isa0: on isab0 atapci0: port 0xe000-0xe00f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 7.1 on pci0 ata0: channel #0 on atapci0 ata1: channel #1 on atapci0 fxp0: port 0xec00-0xec1f mem 0xda000000-0xda0fffff,0xda100000-0xda100fff irq 11 at device 15.0 on pci0 miibus0: on fxp0 inphy0: on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp0: Ethernet address: [removed] fdc0: port 0x3f7,0x3f0-0x3f5 irq 6 drq 2 on acpi0 fd0: <1440-KB 3.5" drive> on fdc0 drive 0 sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acp= i0 sio0: type 16550A, console sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A ppc0: port 0x378-0x37f irq 7 on acpi0 ppc0: Generic chipset (EPP/NIBBLE) in COMPATIBLE mode ppbus0: on ppc0 plip0: on ppbus0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 orm0: at iomem 0xc8000-0xc87ff,0xc0000-0xc7fff on isa0 pmtimer0 on isa0 atkbdc0: at port 0x64,0x60 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=3D0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Timecounter "TSC" frequency 935463590 Hz quality 800 Timecounters tick every 10.000 msec witness_get: witness exhausted ad0: 114473MB [232581/16/63] at ata0-master UDMA66 acd0: CDROM at ata1-master PIO4 From owner-freebsd-current@FreeBSD.ORG Fri Apr 29 17:15: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 1DEBE16A4CE; Fri, 29 Apr 2005 17:15:14 +0000 (GMT) Received: from hadar.amcc.com (hadar.amcc.com [192.195.69.168]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8860543D2F; Fri, 29 Apr 2005 17:15:11 +0000 (GMT) (envelope-from vkashyap@amcc.com) Received: from mailhost01.amcc.com ([192.195.69.30]) by hadar.amcc.com (Netscape Messaging Server 4.15) with SMTP id IFPX9B02.15W; Fri, 29 Apr 2005 10:15:11 -0700 Received: (from vkashyap-pc [10.66.13.13]) by mailhost01.amcc.com (SMSSMTP 4.0.0.59) with SMTP id M2005042910162513518 ; Fri, 29 Apr 2005 10:16:25 -0700 From: "Vinod Kashyap" To: Scott Long Date: Fri, 29 Apr 2005 10:15:09 -0700 X-Sent-Folder-Path: Sent Items X-Mailer: Oracle Connector for Outlook 9.0.4 51114 (9.0.6627) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-ID: cc: freebsd-current@FreeBSD.org cc: "Bjoern A. Zeeb" Subject: RE: Problem with twa in HEAD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 29 Apr 2005 17:15:14 -0000 > -----Original Message----- > From: Scott Long [mailto:scottl@samsco.org] > Sent: Thursday, April 28, 2005 11:57 PM > To: Vinod Kashyap > Cc: Bjoern A. Zeeb; freebsd-current@FreeBSD.org > Subject: Re: Problem with twa in HEAD > = > = > Vinod Kashyap wrote: > > > >>-----Original Message----- > >>From: Bjoern A. Zeeb [mailto:bz@FreeBSD.org] > >>Sent: Tuesday, April 26, 2005 3:26 AM > >>To: Vinod Kashyap > >>Subject: RE: Problem with twa in HEAD > >> > >> > >>On Mon, 25 Apr 2005, Vinod Kashyap wrote: > >> > >>Hi, > >> > >> > >>>>-----Original Message----- > >>>>From: Bjoern A. Zeeb [mailto:bz@FreeBSD.org] > >>>>Sent: Monday, April 25, 2005 6:45 AM > >>>>To: Vinod Kashyap > >>>>Subject: Re: Problem with twa in HEAD > >>>> > >>>> > >>>>On Fri, 22 Apr 2005, Bjoern A. Zeeb wrote: > >>>> > >>>>Hi, > >>>> > >>>> > >>>>>scottl redirected me to you. > >>>>> > >>>>>I am currently debugging "hangs" on reboot and shutdown on a > >>>>>SMP machine with 12 discs at a > >>>>> > >>>>>3ware device driver for 9000 series storage controllers, > >>>> > >>>>version: 3.60.00.016 > >>>> > >>>>>twa0: <3ware 9000 series Storage Controller> port > >>>> > >>>>0x9800-0x98ff mem 0xfe8ffc00-0xfe8ffcff,0xfb800000-0xfbffffff > >>>>irq 28 at device 6.0 on pci3 > >>>> > >>>>>twa0: [FAST] > >>>>>twa0: INFO: (0x15: 0x1300): Controller details:: 12 ports, > >>>> > >>>>Firmware FE9X 2.06.00.009, BIOS BE9X 2.03.01.051 > >>>> > >>>>> > >>>>>What I know so far is that Giant is held by sync. > >>>>> > >>>>>Things a "spinning" in cam/cam_xpt.c around: > >>>>> > >>>>>--- cam_xpt.c 31 Mar 2005 21:42:49 -0000 1.152 > >>>>>+++ cam_xpt.c 22 Apr 2005 18:42:43 -0000 > >>>>>@@ -3643,6 +3643,7 @@ xpt_polled_action(union ccb *start_ccb) > >>>>> !=3D CAM_REQ_INPROG) > >>>>> break; > >>>>> DELAY(1000); > >>>>> printf("XXX status=3D%02x\n", > >>>> > >>>>start_ccb->ccb_h.status); > >>>> > >>>>> } > >>>>> if (timeout =3D=3D 0) { > >>>>> /* > >>>>> > >>>>> > >>>>>with status being 0x200. > >>>>> > >>>>>Seems the twa has a command stuck in it. > >>>>> > >>>>>I have seen the comment in dev/twa/tw_osl_cam.c ~ line 253 about > >>>>>queuing and CAM_SIM_QUEUED but I don't know enough about cam. > >>>>>I seems no all patchs out of this functions seem to > >> > >>clear that from > >> > >>>>>status? > >>>>> > >>>>>Any help apreaciated ;) I can try patches; as long as I > >> > >>can break > >> > >>>>>to db> to reboot. > >>>> > >>>>further debugging shows that is seems to be spinning in twa_poll. > >>>>see debug output from TWA_DEBUG 3. The problem is that at > >> > >>this point > >> > >>>>I am no longer able to break to debugger. > >>>> > >>>>twa0: tw_osli_execute_scsi: XPT_SCSI_IO: Single virtual address! > >>>>twa0: tw_osli_execute_scsi: XPT_SCSI_IO: Single virtual address! > >>>>unmount of /dev failed (BUSY) > >>>>twa0: tw_osli_execute_scsi: XPT_SCSI_IO: Single virtual address! > >>>>twa0: tw_osli_execute_scsi: XPT_SCSI_IO: Single virtual address! > >>>>Uptime: 2m57s > >>>>twa0: tw_osli_execute_scsi: XPT_SCSI_IO: Single virtual address! > >>>>twa0: twa_poll: entering; sc =3D 0xc57bb200 > >>>>twa0: twa_poll: exiting; sc =3D 0xc57bb200 > >>>>twa0: twa_poll: entering; sc =3D 0xc57bb200 > >>>>twa0: twa_poll: exiting; sc =3D 0xc57bb200 > >>>>twa0: twa_poll: entering; sc =3D 0xc57bb200 > >>>>twa0: twa_poll: exiting; sc =3D 0xc57bb200 > >>>>twa0: twa_poll: entering; sc =3D 0xc57bb200 > >>>>twa0: twa_poll: exiting; sc =3D 0xc57bb200 > >>>>twa0: twa_poll: entering; sc =3D 0xc57bb200 > >>>>twa0: twa_poll: exiting; sc =3D 0xc57bb200 > >>>>twa0: twa_poll: entering; sc =3D 0xc57bb200 > >>>>twa0: twa_poll: exiting; sc =3D 0xc57bb200 > >>>>twa0: twa_poll: entering; sc =3D 0xc57bb200 > >>>>twa0: twa_poll: exiting; sc =3D 0xc57bb200 > >>>>... > >>>> > >>> > >>>I am in the middle of an office move right now. > >>>I will get back to you once I have some time to look into this. > >> > >> > >>thanks for the information; I'll be able to test at least = > until end of > >>this week and hopefully next week too. > >> > > > > > > I looked into this, and this is what is happening: > > On reboot/halt, the following function calling sequence happens: > > ... --> dashutdown --> xpt_polled_action --> twa_poll. > > But, the interrupt handler in twa is still active at this time, > > since twa_detach/twa_shutdown hasn't been called yet. Before > > twa_poll can fetch the response for the posted command, the ISR > > gets called when the firmware posts the response. The ISR clears > > the interrupt bit on the controller, registers a taskqueue = > handler like > > it always does, and exits. Meanwhile, xpt_polled_action continues > > to call twa_poll, which cannot determine that the command = > has completed, > > since the interrupt bit on the controller is already cleared. So, > > we get into a (near) never-ending loop (the timeout for = > scsi_synchronize_cache, > > which is what is being tried here, is, for whatever reason, = > 60 minutes, > > and so, the system is as good as hung). > > > > Now, does anyone know why xpt_polled_action is being called from > > dashutdown, even before the ISR has been unregistered (via = > twa_detach)? > > > > Bjoern, this patch should work-around your problem, = > although it's not > > the fix. Also, it still leaves a window for the race = > condition described > > above. > > > = > xpt_polled_action() expects that it can simulate interrupts by calling > the driver poll vector, and that by calling it enough times the driver > will eventually complete all the outstanding I/O it has. As you note, > it'll repeat this for a very long time. So the question is = > then why the > twa driver isn't completing the outstanding I/O. If I were you I'd > remove the call to tw_cl_interrupt() in twa_poll() and just > unconditionally call tw_cl_deferred_interrupt() and have it check > everything. The call to tw_cl_interrupt cannot be removed as that's where the interrupt= is cleared. However, the call to tw_cl_deferred_interrupt can be made not conditional to the return value from tw_cl_interrupt. Whatever that is, my question is why polling is being resorted to, when interrupts are available? > The locking here (and in twa_pci_intr()) is = > flawed anyways, > you have a race between when tw_cl_interrupt() drops its lock right > before return and when you check it's return value. I'd like say that > it's harmless, except that you expect to pass state from one = > function to > the next, so the race is a real one. It's likely why this case is If the state passed to the second function is invalid when the second function executes, it just does nothing. So, this is pretty harmless. > failing. An ideal FAST handler should only clear the = > hardware interrupt > register and launch the appropriate handlers, it shouldn't try to pass > state to the handlers. Look at aac for an example here, but = > also please > recall that I've already discouraged you from using a a fast handler > plus taskqueue for this driver. If your taskqueue handlers need state > from when the interrupt was cleared, then they simply aren't a good > candidate for this model. > = In twa, state will need to be passed to the taskqueue handlers since the ISR clears the state on the controller. From owner-freebsd-current@FreeBSD.ORG Fri Apr 29 17:36: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 8628416A4CE; Fri, 29 Apr 2005 17:36:25 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 873D443D46; Fri, 29 Apr 2005 17:36:22 +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.3/8.13.3) with ESMTP id j3THe5im032060; Fri, 29 Apr 2005 11:40:06 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <42727078.8090307@samsco.org> Date: Fri, 29 Apr 2005 11:35:52 -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: Vinod Kashyap 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 cc: "Bjoern A. Zeeb" Subject: Re: Problem with twa in HEAD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 29 Apr 2005 17:36:25 -0000 Vinod Kashyap wrote: > >>-----Original Message----- >>From: Scott Long [mailto:scottl@samsco.org] >>Sent: Thursday, April 28, 2005 11:57 PM >>To: Vinod Kashyap >>Cc: Bjoern A. Zeeb; freebsd-current@FreeBSD.org >>Subject: Re: Problem with twa in HEAD >> >> >>Vinod Kashyap wrote: >> >>>>-----Original Message----- >>>>From: Bjoern A. Zeeb [mailto:bz@FreeBSD.org] >>>>Sent: Tuesday, April 26, 2005 3:26 AM >>>>To: Vinod Kashyap >>>>Subject: RE: Problem with twa in HEAD >>>> >>>> >>>>On Mon, 25 Apr 2005, Vinod Kashyap wrote: >>>> >>>>Hi, >>>> >>>> >>>> >>>>>>-----Original Message----- >>>>>>From: Bjoern A. Zeeb [mailto:bz@FreeBSD.org] >>>>>>Sent: Monday, April 25, 2005 6:45 AM >>>>>>To: Vinod Kashyap >>>>>>Subject: Re: Problem with twa in HEAD >>>>>> >>>>>> >>>>>>On Fri, 22 Apr 2005, Bjoern A. Zeeb wrote: >>>>>> >>>>>>Hi, >>>>>> >>>>>> >>>>>> >>>>>>>scottl redirected me to you. >>>>>>> >>>>>>>I am currently debugging "hangs" on reboot and shutdown on a >>>>>>>SMP machine with 12 discs at a >>>>>>> >>>>>>>3ware device driver for 9000 series storage controllers, >>>>>> >>>>>>version: 3.60.00.016 >>>>>> >>>>>> >>>>>>>twa0: <3ware 9000 series Storage Controller> port >>>>>> >>>>>>0x9800-0x98ff mem 0xfe8ffc00-0xfe8ffcff,0xfb800000-0xfbffffff >>>>>>irq 28 at device 6.0 on pci3 >>>>>> >>>>>> >>>>>>>twa0: [FAST] >>>>>>>twa0: INFO: (0x15: 0x1300): Controller details:: 12 ports, >>>>>> >>>>>>Firmware FE9X 2.06.00.009, BIOS BE9X 2.03.01.051 >>>>>> >>>>>> >>>>>>>What I know so far is that Giant is held by sync. >>>>>>> >>>>>>>Things a "spinning" in cam/cam_xpt.c around: >>>>>>> >>>>>>>--- cam_xpt.c 31 Mar 2005 21:42:49 -0000 1.152 >>>>>>>+++ cam_xpt.c 22 Apr 2005 18:42:43 -0000 >>>>>>>@@ -3643,6 +3643,7 @@ xpt_polled_action(union ccb *start_ccb) >>>>>>> != CAM_REQ_INPROG) >>>>>>> break; >>>>>>> DELAY(1000); >>>>>>> printf("XXX status=%02x\n", >>>>>> >>>>>>start_ccb->ccb_h.status); >>>>>> >>>>>> >>>>>>> } >>>>>>> if (timeout == 0) { >>>>>>> /* >>>>>>> >>>>>>> >>>>>>>with status being 0x200. >>>>>>> >>>>>>>Seems the twa has a command stuck in it. >>>>>>> >>>>>>>I have seen the comment in dev/twa/tw_osl_cam.c ~ line 253 about >>>>>>>queuing and CAM_SIM_QUEUED but I don't know enough about cam. >>>>>>>I seems no all patchs out of this functions seem to >>>> >>>>clear that from >>>> >>>> >>>>>>>status? >>>>>>> >>>>>>>Any help apreaciated ;) I can try patches; as long as I >>>> >>>>can break >>>> >>>> >>>>>>>to db> to reboot. >>>>>> >>>>>>further debugging shows that is seems to be spinning in twa_poll. >>>>>>see debug output from TWA_DEBUG 3. The problem is that at >>>> >>>>this point >>>> >>>> >>>>>>I am no longer able to break to debugger. >>>>>> >>>>>>twa0: tw_osli_execute_scsi: XPT_SCSI_IO: Single virtual address! >>>>>>twa0: tw_osli_execute_scsi: XPT_SCSI_IO: Single virtual address! >>>>>>unmount of /dev failed (BUSY) >>>>>>twa0: tw_osli_execute_scsi: XPT_SCSI_IO: Single virtual address! >>>>>>twa0: tw_osli_execute_scsi: XPT_SCSI_IO: Single virtual address! >>>>>>Uptime: 2m57s >>>>>>twa0: tw_osli_execute_scsi: XPT_SCSI_IO: Single virtual address! >>>>>>twa0: twa_poll: entering; sc = 0xc57bb200 >>>>>>twa0: twa_poll: exiting; sc = 0xc57bb200 >>>>>>twa0: twa_poll: entering; sc = 0xc57bb200 >>>>>>twa0: twa_poll: exiting; sc = 0xc57bb200 >>>>>>twa0: twa_poll: entering; sc = 0xc57bb200 >>>>>>twa0: twa_poll: exiting; sc = 0xc57bb200 >>>>>>twa0: twa_poll: entering; sc = 0xc57bb200 >>>>>>twa0: twa_poll: exiting; sc = 0xc57bb200 >>>>>>twa0: twa_poll: entering; sc = 0xc57bb200 >>>>>>twa0: twa_poll: exiting; sc = 0xc57bb200 >>>>>>twa0: twa_poll: entering; sc = 0xc57bb200 >>>>>>twa0: twa_poll: exiting; sc = 0xc57bb200 >>>>>>twa0: twa_poll: entering; sc = 0xc57bb200 >>>>>>twa0: twa_poll: exiting; sc = 0xc57bb200 >>>>>>... >>>>>> >>>>> >>>>>I am in the middle of an office move right now. >>>>>I will get back to you once I have some time to look into this. >>>> >>>> >>>>thanks for the information; I'll be able to test at least >> >>until end of >> >>>>this week and hopefully next week too. >>>> >>> >>> >>>I looked into this, and this is what is happening: >>>On reboot/halt, the following function calling sequence happens: >>>... --> dashutdown --> xpt_polled_action --> twa_poll. >>>But, the interrupt handler in twa is still active at this time, >>>since twa_detach/twa_shutdown hasn't been called yet. Before >>>twa_poll can fetch the response for the posted command, the ISR >>>gets called when the firmware posts the response. The ISR clears >>>the interrupt bit on the controller, registers a taskqueue >> >>handler like >> >>>it always does, and exits. Meanwhile, xpt_polled_action continues >>>to call twa_poll, which cannot determine that the command >> >>has completed, >> >>>since the interrupt bit on the controller is already cleared. So, >>>we get into a (near) never-ending loop (the timeout for >> >>scsi_synchronize_cache, >> >>>which is what is being tried here, is, for whatever reason, >> >>60 minutes, >> >>>and so, the system is as good as hung). >>> >>>Now, does anyone know why xpt_polled_action is being called from >>>dashutdown, even before the ISR has been unregistered (via >> >>twa_detach)? >> >>>Bjoern, this patch should work-around your problem, >> >>although it's not >> >>>the fix. Also, it still leaves a window for the race >> >>condition described >> >>>above. >>> >> >>xpt_polled_action() expects that it can simulate interrupts by calling >>the driver poll vector, and that by calling it enough times the driver >>will eventually complete all the outstanding I/O it has. As you note, >>it'll repeat this for a very long time. So the question is >>then why the >>twa driver isn't completing the outstanding I/O. If I were you I'd >>remove the call to tw_cl_interrupt() in twa_poll() and just >>unconditionally call tw_cl_deferred_interrupt() and have it check >>everything. > > > The call to tw_cl_interrupt cannot be removed as that's where the interrupt > is cleared. However, the call to tw_cl_deferred_interrupt can be made > not conditional to the return value from tw_cl_interrupt. > Whatever that is, my question is why polling is being resorted to, when > interrupts are available? > > >> The locking here (and in twa_pci_intr()) is >>flawed anyways, >>you have a race between when tw_cl_interrupt() drops its lock right >>before return and when you check it's return value. I'd like say that >>it's harmless, except that you expect to pass state from one >>function to >>the next, so the race is a real one. It's likely why this case is > > > If the state passed to the second function is invalid when the second > function executes, it just does nothing. So, this is pretty harmless. > > >>failing. An ideal FAST handler should only clear the >>hardware interrupt >>register and launch the appropriate handlers, it shouldn't try to pass >>state to the handlers. Look at aac for an example here, but >>also please >>recall that I've already discouraged you from using a a fast handler >>plus taskqueue for this driver. If your taskqueue handlers need state >>from when the interrupt was cleared, then they simply aren't a good >>candidate for this model. >> > > > In twa, state will need to be passed to the taskqueue handlers since the > ISR clears the state on the controller. > > Have it your way then, I'm frankly very weary of arguing with you. Scott From owner-freebsd-current@FreeBSD.ORG Fri Apr 29 17:43: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 2E0D716A4CE for ; Fri, 29 Apr 2005 17:43:42 +0000 (GMT) Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id B254443D5A for ; Fri, 29 Apr 2005 17:43:41 +0000 (GMT) (envelope-from sam@errno.com) Received: from [66.127.85.91] (sam@[66.127.85.91]) (authenticated bits=0) by ebb.errno.com (8.12.9/8.12.6) with ESMTP id j3THhems090656 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 Apr 2005 10:43:41 -0700 (PDT) (envelope-from sam@errno.com) Message-ID: <427272F7.7010604@errno.com> Date: Fri, 29 Apr 2005 10:46:31 -0700 From: Sam Leffler User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050327) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brooks Davis References: <20050428121447.GA90430@uk.tiscali.com> <42715889.7070202@errno.com> <20050428222831.GB1308@uk.tiscali.com> <42716C48.9070206@errno.com> <20050429121129.GA92888@uk.tiscali.com> <05042922184316.40144@www.mmlab.cse.yzu.edu.tw> <20050429150901.GA18010@odin.ac.hmc.edu> In-Reply-To: <20050429150901.GA18010@odin.ac.hmc.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: Tai-hwa Liang cc: freebsd-current@freebsd.org cc: Brian Candler Subject: Re: wpa_supplicant causes panic in ieee80211_newstate X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 29 Apr 2005 17:43:42 -0000 Brooks Davis wrote: > On Fri, Apr 29, 2005 at 10:20:40PM +0800, Tai-hwa Liang wrote: > >>On Fri, 29 Apr 2005, Brian Candler wrote: >> >>>On Thu, Apr 28, 2005 at 04:05:44PM -0700, Sam Leffler wrote: >>> >>>>>Is there a canonical list of cards which *do* support WPA? I was guessing >>>>>(probably wrongly) that anything under the 80211 layer would. >>>> >>>>ath supports it. >>> >>>Thanks. Unfortunately, it seems that the list of supported cards in ath(4) >>>could do with updating. >>> >>>I just went out and bought a Netgear WG311 - that's exactly what it says on >>>the box. However it's not recognised by the generic kernel, nor by >>>`kldload ath`. According to `pciconf -l -v`, it is: >>> >>>none2@pci2:11:0: class=0x028000 card=0x4c001385 chip=0x9066104c >>>rev=0x00 hdr=0x00 >>> vendor = 'Texas Instruments (TI)' >>> device = 'TNETW1130(ACX111) 802.11b/g Wireless Cardbus/PCI Adapter' >>> class = network >>> >>>Hmm, and now I know this, I find >>>http://lists.freebsd.org/pipermail/freebsd-current/2004-August/033976.html >>> >>>Short of messing with Windoze NDIS drivers, it seems like I have bought >>>myself an expensive blanking plate :-( >> >> Looks like yet another revision trick performed by vendor: >> >> http://hd.blogdns.org:3000/cgi-bin/wifi.cgi?Adaptors#311 >> http://www.leenooks.com/112 >> >> Perhaps we should document the extra "v1" in the man page? > > > Since we're not attempting to keep the list complete, I've removed in in > HEAD and will do so in stable. The v1's are probably unobtainable at > this point anyway so it's just asking for confusion to leave it in. The ath man page has a url that points to a page at the Atheros web site where all products using their chips are listed (or at least all those publicly disclosed). That is the definitive list and any attempt to maintain one in the driver is pointless. The only issue with that info is that Atheros marks usage by their chip id's which we don't track; we only classify use according to the programming api (5210, 5211, 5212). However given the scarcity of 5210 and 5211 parts folks can pretty much assume everything is a 5212. Sam From owner-freebsd-current@FreeBSD.ORG Fri Apr 29 18:04: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 2220F16A4CE; Fri, 29 Apr 2005 18:04:16 +0000 (GMT) Received: from hadar.amcc.com (hadar.amcc.com [192.195.69.168]) by mx1.FreeBSD.org (Postfix) with ESMTP id CCB6B43D46; Fri, 29 Apr 2005 18:04:15 +0000 (GMT) (envelope-from vkashyap@amcc.com) Received: from mailhost01.amcc.com ([192.195.69.30]) by hadar.amcc.com (Netscape Messaging Server 4.15) with SMTP id IFPZJ303.D68; Fri, 29 Apr 2005 11:04:15 -0700 Received: (from vkashyap-pc [10.66.13.13]) by mailhost01.amcc.com (SMSSMTP 4.0.0.59) with SMTP id M2005042911042814747 ; Fri, 29 Apr 2005 11:04:28 -0700 From: "Vinod Kashyap" To: Scott Long Date: Fri, 29 Apr 2005 11:04:13 -0700 X-Sent-Folder-Path: Sent Items X-Mailer: Oracle Connector for Outlook 9.0.4 51114 (9.0.6627) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-ID: cc: freebsd-current@FreeBSD.org cc: "Bjoern A. Zeeb" Subject: RE: Problem with twa in HEAD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 29 Apr 2005 18:04:16 -0000 > > > > > > In twa, state will need to be passed to the taskqueue = > handlers since the > > ISR clears the state on the controller. > > > > > = > Have it your way then, I'm frankly very weary of arguing with you. > = I thought it was more of a discussion. If you think it's arguing, I can't help it! From owner-freebsd-current@FreeBSD.ORG Fri Apr 29 18:38: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 78E4116A4CE; Fri, 29 Apr 2005 18:38: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 3C3F043D2D; Fri, 29 Apr 2005 18:38:22 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id AF4F2514C9; Fri, 29 Apr 2005 11:38:21 -0700 (PDT) Date: Fri, 29 Apr 2005 11:38:21 -0700 From: Kris Kennaway To: obrien@freebsd.org, freebsd-current@freebsd.org Message-ID: <20050429183821.GA7659@xor.obsecurity.org> References: <20050429160222.GA2264@dragon.NUXI.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="AqsLC8rIMeq19msA" Content-Disposition: inline In-Reply-To: <20050429160222.GA2264@dragon.NUXI.org> User-Agent: Mutt/1.4.2.1i Subject: Re: [PANIC] ufs_dirbad: bad dir X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 29 Apr 2005 18:38:22 -0000 --AqsLC8rIMeq19msA Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Apr 29, 2005 at 09:02:22AM -0700, David O'Brien wrote: > FreeBSD 6.0-CURRENT FreeBSD 6.0-CURRENT #486: Mon Apr 25 09:41:31 PDT 200= 5=20 >=20 > [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.s= o: Undefined symbol "ps_pglobal_lookup"] > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you = are > welcome to change it and/or distribute copies of it under certain 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-marcel-freebsd". > #0 doadump () at pcpu.h:165 > 165 __asm __volatile("movl %%fs:0,%0" : "=3Dr" (td)); > (kgdb) where > #0 doadump () at pcpu.h:165 > #1 0xc04dd3b2 in boot (howto=3D260) at ../../../kern/kern_shutdown.c:397 > #2 0xc04dd763 in panic (fmt=3D0xc067b7f4 "ufs_dirbad: bad dir") > at ../../../kern/kern_shutdown.c:553 > #3 0xc05d913d in ufs_dirbad (ip=3D0x0, offset=3D0, how=3D0x0) > at ../../../ufs/ufs/ufs_lookup.c:598 This one is believed to be a long-standing bug in ufs to do with use of data when it is not protected by an exclusive lock. Kris --AqsLC8rIMeq19msA Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFCcn8dWry0BWjoQKURAnK+AJ4jMiN7j8R10BnX1mWKN4slLVqjrQCfUDTg 6AY5ZH9xbMe5mRPo63li5zw= =7WUx -----END PGP SIGNATURE----- --AqsLC8rIMeq19msA-- From owner-freebsd-current@FreeBSD.ORG Fri Apr 29 19:08: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 E2C7616A4CE for ; Fri, 29 Apr 2005 19:08:48 +0000 (GMT) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.206]) by mx1.FreeBSD.org (Postfix) with ESMTP id 759AB43D3F for ; Fri, 29 Apr 2005 19:08:48 +0000 (GMT) (envelope-from jsconiers@gmail.com) Received: by wproxy.gmail.com with SMTP id 69so903793wra for ; Fri, 29 Apr 2005 12:08:44 -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=rzpQtG0VkMiyFUJ64VSfy4dGbCTEYnboOjj5QAsySoAMW3/XE0AkyLVuyNYAI5LpekITFE2rUDQ7MVNqw63dw9b+YfjzcTMMwN1UM09OSr8zTzZThYjsUZ6hgWFqstN7b9yj9VpHMDvDA1qk51BXR7dF5+xeGWTJHo+6uLxItEI= Received: by 10.54.121.18 with SMTP id t18mr1011094wrc; Fri, 29 Apr 2005 12:08:44 -0700 (PDT) Received: by 10.54.5.75 with HTTP; Fri, 29 Apr 2005 12:08:44 -0700 (PDT) Message-ID: Date: Fri, 29 Apr 2005 14:08:44 -0500 From: John Sconiers To: Michael Nottebrock In-Reply-To: <200504291629.26564.lofi@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <57436.216.177.243.42.1114582155.localmail@webmail.dnswatch.com> <20050429005319.GA17799@laptoxa.toxa.lan> <60093.216.177.243.35.1114761721.localmail@webmail.dnswatch.com> <200504291629.26564.lofi@freebsd.org> cc: freebsd-current@freebsd.org Subject: Re: boot banner project X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: John Sconiers List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Apr 2005 19:08:49 -0000 Is there a reason why we haven't adopted the bsdinstaller?=20 (www.bsdinstaller.org) On 4/29/05, Michael Nottebrock wrote: > On Friday, 29. April 2005 10:02, /dev/null wrote: > > > > "And that's everyone likes in BSD's" > > WOW! Were you elected Official Spokesperson for everyone? ;) >=20 > Everybody has an expert opinion on painting bikesheds. >=20 > -- > ,_, | Michael Nottebrock | lofi@freebsd.org > (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org > \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org >=20 >=20 > From owner-freebsd-current@FreeBSD.ORG Fri Apr 29 19:34: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 00FDC16A4CE for ; Fri, 29 Apr 2005 19:34:45 +0000 (GMT) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.197]) by mx1.FreeBSD.org (Postfix) with ESMTP id 854E643D1D for ; Fri, 29 Apr 2005 19:34:44 +0000 (GMT) (envelope-from jsconiers@gmail.com) Received: by wproxy.gmail.com with SMTP id 69so910270wra for ; Fri, 29 Apr 2005 12:34:41 -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=EBLbNz926X3Ned8+Bbn+1Y9yCbR5w/UQo8jW6Quyh6jK+ehgFZFEyIOaybcpb27GUHKroxW0edI4DvjWQc3uf4M9UDwkl+TA8K7q+XzGCbjd4EzZhNBSp9D8XihHrMFe4rXntDK8ciZ7iubHGZNCoZZw2yDAnEXKV7NETGdE7vE= Received: by 10.54.121.14 with SMTP id t14mr1524775wrc; Fri, 29 Apr 2005 12:34:40 -0700 (PDT) Received: by 10.54.5.75 with HTTP; Fri, 29 Apr 2005 12:34:40 -0700 (PDT) Message-ID: Date: Fri, 29 Apr 2005 14:34:40 -0500 From: John Sconiers To: Guido Falsi In-Reply-To: <20050429105416.GA94049@wedge.madpilot.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <57436.216.177.243.42.1114582155.localmail@webmail.dnswatch.com> <6.1.0.6.2.20050426233321.084e9210@cobalt.antimatter.net> <51899.216.177.243.42.1114584317.localmail@webmail.dnswatch.com> <6.1.0.6.2.20050427001118.0327cd50@cobalt.antimatter.net> <52515.216.177.243.42.1114586501.localmail@webmail.dnswatch.com> <61359.216.177.243.35.1114722481.localmail@webmail.dnswatch.com> <20050429105416.GA94049@wedge.madpilot.net> cc: /dev/null cc: freebsd-current@freebsd.org Subject: Re: boot banner project X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: John Sconiers List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Apr 2005 19:34:45 -0000 What is the goal of FreeBSD, it's user community, it's developer and it's supporting companies / businesses , etc? FreeBSD offers advanced networking, performance, security and compatibility features today ....or at least that's whats on the web page but is one of the goals to increase it's user and developer base? Is this happening? Several years ago after being a FreeBSD fan / contributor since ~1995 I left FreeBSD because I didn't have the time with kids and all. During that time I was a unix / storage ps guy for two fortune 500 companies (One was a vendor of another Unix OS). I was also "forced" to work with Linux in production settings. I come back ~three years later and on the surface things haven't changed. The boot banner, installation program, etc, etc, hasn't changed. I know there have been many updates and advanced features added to FreeBSD. Plainly put we need to include items such as the boot banner not only becasue it can be done but because it can attract and keep more users. Adding less then a meg here or there is not bloat. Unless of course the goal is to create an advanced operating system unable to get / keep users. My $.02 On 4/29/05, Guido Falsi wrote: > On Thu, Apr 28, 2005 at 02:08:00PM -0700, /dev/null wrote: > > Hello, > > As this is an RFC (I'm sure you already know that). > > > > Long answer: > > I'm not quite sure. It will depend on the amount and content > > of the comments. Technically, it may not start ever (because > > everyone/ or nearly everyone says it SUX). > > > > Short answer: > > Too early for me to say. >=20 > On this proposal, I think that some graphic banner while booting could > be beautiful to the eye, but quite void in usefullness. I'm not against > it, but can't see any real advantage. Anyway if someone feels like > spending some time on this feature and the results does not bring any > regression to the system I don't see why it should not be offered as an > option. >=20 > On the other hand I think some tidying up in the rc sctripts boot > messages would really REALLY be a good idea. I don't mean anything > drastic, just that in 5.x(as was altready pointed out) the output is a > bit messy, and even if I can sort it out uite clearly out of habit, it > would be better if it was a bit more structured and ordered. >=20 > My 2 cents...nothing more, nothing less. >=20 > -- > Guido Falsi >=20 >=20 > From owner-freebsd-current@FreeBSD.ORG Fri Apr 29 19:41: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 9045F16A4CE for ; Fri, 29 Apr 2005 19:41:44 +0000 (GMT) Received: from makeworld.com (makeworld.com [216.201.118.142]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3560C43D53 for ; Fri, 29 Apr 2005 19:41:44 +0000 (GMT) (envelope-from racerx@makeworld.com) Received: from localhost (localhost.com [127.0.0.1]) by makeworld.com (Postfix) with ESMTP id 53DAA60E3; Fri, 29 Apr 2005 14:41:43 -0500 (CDT) Received: from makeworld.com ([127.0.0.1]) by localhost (makeworld.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 47738-08; Fri, 29 Apr 2005 14:41:41 -0500 (CDT) Received: from [216.201.118.138] (racerx.makeworld.com [216.201.118.138]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by makeworld.com (Postfix) with ESMTP id 0ACF660D4; Fri, 29 Apr 2005 14:41:37 -0500 (CDT) Message-ID: <42728DF1.9040908@makeworld.com> Date: Fri, 29 Apr 2005 14:41:37 -0500 From: Chris User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050414) X-Accept-Language: en-us, en MIME-Version: 1.0 To: John Sconiers References: <57436.216.177.243.42.1114582155.localmail@webmail.dnswatch.com> <6.1.0.6.2.20050426233321.084e9210@cobalt.antimatter.net> <51899.216.177.243.42.1114584317.localmail@webmail.dnswatch.com> <6.1.0.6.2.20050427001118.0327cd50@cobalt.antimatter.net> <52515.216.177.243.42.1114586501.localmail@webmail.dnswatch.com> <61359.216.177.243.35.1114722481.localmail@webmail.dnswatch.com> <20050429105416.GA94049@wedge.madpilot.net> In-Reply-To: X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by ClamAV 0.75.1/amavisd-new-2.2.1 (20041222) at makeworld.com - Isn't it ironic cc: /dev/null cc: Guido Falsi cc: freebsd-current@freebsd.org Subject: Re: boot banner project X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: racerx@makeworld.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Apr 2005 19:41:44 -0000 John Sconiers wrote: ... > Adding less then a meg here or there is not bloat. Unless of course the goal is to > create an advanced operating system unable to get / keep users. > > My $.02 The problem is this; if everyone keeps adding "less then a meg here or there" then you DO end up with bloat. Where to you draw the line? How much is too much? To me, I would rather add that less then a meg here and there to the core OS ... Not to something that (to me) does not need to look perdy. ... and my .02 -- Best regards, Chris If reproducibility may be a problem conduct the test only once. From owner-freebsd-current@FreeBSD.ORG Fri Apr 29 19:51: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 AA8F116A4CE for ; Fri, 29 Apr 2005 19:51:08 +0000 (GMT) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 414C243D1D for ; Fri, 29 Apr 2005 19:51:08 +0000 (GMT) (envelope-from jsconiers@gmail.com) Received: by wproxy.gmail.com with SMTP id 69so914208wra for ; Fri, 29 Apr 2005 12:51:07 -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=nBek14iPmfb8fDP0V17MSsZY25/ri5P/irpK318p5jm0jcrUI2DrJ1iKgeq9zKgeDqvhJcXBlqpbdXLnGuhfsftCS9JOjlk8vFPAhuvbVkd+r6EAyQynN7ooFGpnPPRaqvB6DjJ/IXyuWp0kAV0LMb/p1ZzlLXq0qaT3bfwKkgA= Received: by 10.54.121.19 with SMTP id t19mr1532578wrc; Fri, 29 Apr 2005 12:51:07 -0700 (PDT) Received: by 10.54.5.75 with HTTP; Fri, 29 Apr 2005 12:51:07 -0700 (PDT) Message-ID: Date: Fri, 29 Apr 2005 14:51:07 -0500 From: John Sconiers To: racerx@makeworld.com In-Reply-To: <42728DF1.9040908@makeworld.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <57436.216.177.243.42.1114582155.localmail@webmail.dnswatch.com> <6.1.0.6.2.20050426233321.084e9210@cobalt.antimatter.net> <51899.216.177.243.42.1114584317.localmail@webmail.dnswatch.com> <6.1.0.6.2.20050427001118.0327cd50@cobalt.antimatter.net> <52515.216.177.243.42.1114586501.localmail@webmail.dnswatch.com> <61359.216.177.243.35.1114722481.localmail@webmail.dnswatch.com> <20050429105416.GA94049@wedge.madpilot.net> <42728DF1.9040908@makeworld.com> cc: /dev/null cc: Guido Falsi cc: freebsd-current@freebsd.org Subject: Re: boot banner project X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: John Sconiers List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Apr 2005 19:51:08 -0000 Do you want to get / keep new users, compete wth other operating systems, etc.... On 4/29/05, Chris wrote: > John Sconiers wrote: > ... > > Adding less then a meg here or there is not bloat. Unless of course th= e goal is to > > create an advanced operating system unable to get / keep users. > > > > My $.02 >=20 > The problem is this; if everyone keeps adding "less then a meg here or > there" then you DO end up with bloat. >=20 > Where to you draw the line? How much is too much? To me, I would rather > add that less then a meg here and there to the core OS ... Not to > something that (to me) does not need to look perdy. >=20 > ... and my .02 >=20 > -- > Best regards, > Chris >=20 > If reproducibility may be a problem conduct the > test only once. > From owner-freebsd-current@FreeBSD.ORG Fri Apr 29 19:55: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 D1BAA16A4CE; Fri, 29 Apr 2005 19:55:08 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id A044543D48; Fri, 29 Apr 2005 19:55:05 +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.3/8.13.3) with ESMTP id j3TJx4oj032658; Fri, 29 Apr 2005 13:59:05 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <4272910C.5020002@samsco.org> Date: Fri, 29 Apr 2005 13:54:52 -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: John Sconiers References: <57436.216.177.243.42.1114582155.localmail@webmail.dnswatch.com> <20050429005319.GA17799@laptoxa.toxa.lan> <60093.216.177.243.35.1114761721.localmail@webmail.dnswatch.com> <200504291629.26564.lofi@freebsd.org> 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 cc: Michael Nottebrock Subject: Re: boot banner project X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 29 Apr 2005 19:55:08 -0000 Several reasons. The first is the most important: No one has stepped forward and 'done it'. Now, I personally have a lot of reservations about it. I fundamentally don't like the architecture; their claim of divorcing the UI from the model isn't really true. What they've done is create a lowest-common-denominator UI framework that must be invoked directly from the model. Well, I guess that 'directly' isn't quite right, since it's redirected through an RPC mechanism. But anyways, instead of having the UI (and thus the User) direct the flow and control the model, the model directs the flow and periodically exchanges input with the user. In other words, it still has much of the architectural limitations of sysinstall, but with generic UI elements instead of just ncurses. They also haven't shown how to solve the hard problems, mainly partitioning the disk, working in a multi-boot environment, divorcing the 'install the bits' phase from the 'configure the bits' phase, etc. So, it's a nice proof of concept at this point, and it works well for very simple situations, but I don't consider it a sysinstall replacement yet. If the point of having a new installer is to improve the existing state of the art and attract new users, not having multi-boot and partitioning is a serious limitation. Every time I evagelise FreeBSD to someone new, the second question they ask me is whether they can dual boot with it. It is, however, good at exactly what it was designed for, mainly taking your existing FreeBSD installation and morphing it into DFly ;-) Scott John Sconiers wrote: > Is there a reason why we haven't adopted the bsdinstaller? > (www.bsdinstaller.org) > > On 4/29/05, Michael Nottebrock wrote: > >>On Friday, 29. April 2005 10:02, /dev/null wrote: >> >>>"And that's everyone likes in BSD's" >>> WOW! Were you elected Official Spokesperson for everyone? ;) >> >>Everybody has an expert opinion on painting bikesheds. >> >>-- >> ,_, | Michael Nottebrock | lofi@freebsd.org >> (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org >> \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.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 Fri Apr 29 19:58: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 D043F16A4CF for ; Fri, 29 Apr 2005 19:58:44 +0000 (GMT) Received: from makeworld.com (makeworld.com [216.201.118.142]) by mx1.FreeBSD.org (Postfix) with ESMTP id 611D043D2D for ; Fri, 29 Apr 2005 19:58:44 +0000 (GMT) (envelope-from racerx@makeworld.com) Received: from localhost (localhost.com [127.0.0.1]) by makeworld.com (Postfix) with ESMTP id 9683B60E3; Fri, 29 Apr 2005 14:58:43 -0500 (CDT) Received: from makeworld.com ([127.0.0.1]) by localhost (makeworld.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 47950-02; Fri, 29 Apr 2005 14:58:39 -0500 (CDT) Received: from [216.201.118.138] (racerx.makeworld.com [216.201.118.138]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by makeworld.com (Postfix) with ESMTP id 8FC6560D4; Fri, 29 Apr 2005 14:58:39 -0500 (CDT) Message-ID: <427291EE.4080809@makeworld.com> Date: Fri, 29 Apr 2005 14:58:38 -0500 From: Chris User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050414) X-Accept-Language: en-us, en MIME-Version: 1.0 To: John Sconiers References: <57436.216.177.243.42.1114582155.localmail@webmail.dnswatch.com> <6.1.0.6.2.20050426233321.084e9210@cobalt.antimatter.net> <51899.216.177.243.42.1114584317.localmail@webmail.dnswatch.com> <6.1.0.6.2.20050427001118.0327cd50@cobalt.antimatter.net> <52515.216.177.243.42.1114586501.localmail@webmail.dnswatch.com> <61359.216.177.243.35.1114722481.localmail@webmail.dnswatch.com> <20050429105416.GA94049@wedge.madpilot.net> <42728DF1.9040908@makeworld.com> In-Reply-To: X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by ClamAV 0.75.1/amavisd-new-2.2.1 (20041222) at makeworld.com - Isn't it ironic cc: /dev/null cc: Guido Falsi cc: freebsd-current@freebsd.org Subject: Re: boot banner project X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: racerx@makeworld.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Apr 2005 19:58:45 -0000 John Sconiers wrote: > On 4/29/05, Chris wrote: > >>John Sconiers wrote: >>... >> >>>Adding less then a meg here or there is not bloat. Unless of course the goal is to >>>create an advanced operating system unable to get / keep users. >>> >>>My $.02 >> >>The problem is this; if everyone keeps adding "less then a meg here or >>there" then you DO end up with bloat. >> >>Where to you draw the line? How much is too much? To me, I would rather >>add that less then a meg here and there to the core OS ... Not to >>something that (to me) does not need to look perdy. >> >>... and my .02 >> >>-- >>Best regards, >>Chris >> >>If reproducibility may be a problem conduct the >>test only once. >> John Sconiers wrote: > Do you want to get / keep new users, compete wth other operating > systems, etc.... > Of course - but NOT at the expense for the OS itself. The banner is only seen once. It does not have to be perdy to attract users. If that's the case, if it needs to be perdy to attract users - then (speaking for myself) do you want that flavor of user? Are you not at that point trying to emulate a Windows-ee look? As I said, I care more about the quality of the OS. -- Best regards, Chris The spot you are scrubbing on glassware is always on the other side. From owner-freebsd-current@FreeBSD.ORG Fri Apr 29 20:00: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 3A32116A4CE for ; Fri, 29 Apr 2005 20:00:41 +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 66C4043D58 for ; Fri, 29 Apr 2005 20:00:40 +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]) j3TK0WLe032439 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sat, 30 Apr 2005 06:00:34 +1000 Received: from cirb503493.alcatel.com.au (localhost.alcatel.com.au [127.0.0.1])j3TK0WXw006751; Sat, 30 Apr 2005 06:00:32 +1000 (EST) (envelope-from pjeremy@cirb503493.alcatel.com.au) Received: (from pjeremy@localhost)j3TK0U2f006750; Sat, 30 Apr 2005 06:00:30 +1000 (EST) (envelope-from pjeremy) Date: Sat, 30 Apr 2005 06:00:30 +1000 From: Peter Jeremy To: Alex Zbyslaw Message-ID: <20050429200029.GC232@cirb503493.alcatel.com.au> References: <200504262010.49509@harrymail> <86k6mo0xmh.fsf@xps.des.no> <427157B7.6040203@mac.com> <200504290053.51912@harrymail> <427177FD.50809@dial.pipex.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <427177FD.50809@dial.pipex.com> User-Agent: Mutt/1.4.2i cc: Emanuel Strobl cc: freebsd-current@freebsd.org Subject: Re: groff alternative? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 29 Apr 2005 20:00:41 -0000 On Fri, 2005-Apr-29 00:55:41 +0100, Alex Zbyslaw wrote: >Since no-one had a sensible answer, why not try a version of original >nroff from say 4.3BSD. Hunting around, I found this: >http://www.tuhs.org/. Hopefully the most used macros will have stayed >the same. Actually, they haven't. The FreeBSD man pages are written using mdoc(7), not man(7). The current version of mdoc(7) in FreeBSD needs long names - which are supported by ditroff and groff but not the older nroff. I don't believe the nroff in either 4.3BSD or 2.11BSD can support long names and neither include a mdoc(7) implementation. 4.4BSD includes mdoc(7) but also GNU groff - though a quick look at the tmac.mdoc* files suggests that it might work with an old (4.3 or 2.11) nroff. If you're only worried about ports, most of those will use man(7), not mdoc(7) - though there are probably a few that use mdoc(7). -- Peter Jeremy From owner-freebsd-current@FreeBSD.ORG Fri Apr 29 20:07: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 CEE3216A4CE; Fri, 29 Apr 2005 20:07:41 +0000 (GMT) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5961643D3F; Fri, 29 Apr 2005 20:07:41 +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 j3TK7eEH014687; Fri, 29 Apr 2005 16:07:40 -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 j3TK7eHL046110; Fri, 29 Apr 2005 16:07:40 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 8E4067306E; Fri, 29 Apr 2005 16:07:38 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050429200738.8E4067306E@freebsd-current.sentex.ca> Date: Fri, 29 Apr 2005 16:07:38 -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 alpha/alpha 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: Fri, 29 Apr 2005 20:07:42 -0000 TB --- 2005-04-29 20:00:00 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-04-29 20:00:00 - starting CURRENT tinderbox run for alpha/alpha TB --- 2005-04-29 20:00:01 - checking out the source tree TB --- 2005-04-29 20:00:01 - cd /home/tinderbox/CURRENT/alpha/alpha TB --- 2005-04-29 20:00:01 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-04-29 20:06:32 - building world (CFLAGS=-O2 -pipe) TB --- 2005-04-29 20:06:32 - cd /home/tinderbox/CURRENT/alpha/alpha/src TB --- 2005-04-29 20:06:32 - /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 [...] rm -f init init.o init.8.gz init.8.cat.gz rm -f .depend GPATH GRTAGS GSYMS GTAGS ===> sbin/ip6fw (cleandir) rm -f ip6fw ip6fw.o ip6fw.8.gz ip6fw.8.cat.gz rm -f .depend GPATH GRTAGS GSYMS GTAGS ===> sbin/ipf (cleandir) ".depend", line 275: Inconsistent operator for ipf make: fatal errors encountered -- cannot continue *** Error code 1 Stop in /tinderbox/CURRENT/alpha/alpha/src/sbin. *** Error code 1 Stop in /tinderbox/CURRENT/alpha/alpha/src. *** Error code 1 Stop in /tinderbox/CURRENT/alpha/alpha/src. *** Error code 1 Stop in /tinderbox/CURRENT/alpha/alpha/src. TB --- 2005-04-29 20:07:38 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-04-29 20:07:38 - ERROR: failed to build world TB --- 2005-04-29 20:07:38 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Fri Apr 29 20:10: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 C47C116A4CE; Fri, 29 Apr 2005 20:10:33 +0000 (GMT) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 66F4F43D5D; Fri, 29 Apr 2005 20:10: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 j3TKAXfn014895; Fri, 29 Apr 2005 16:10: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 j3TKB7qO003575; Fri, 29 Apr 2005 16:11:07 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id D25B87306E; Fri, 29 Apr 2005 16:10:32 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050429201032.D25B87306E@freebsd-current.sentex.ca> Date: Fri, 29 Apr 2005 16:10:32 -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: Fri, 29 Apr 2005 20:10:34 -0000 TB --- 2005-04-29 20:07:40 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-04-29 20:07:40 - starting CURRENT tinderbox run for amd64/amd64 TB --- 2005-04-29 20:07:40 - checking out the source tree TB --- 2005-04-29 20:07:40 - cd /home/tinderbox/CURRENT/amd64/amd64 TB --- 2005-04-29 20:07:40 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-04-29 20:09:26 - building world (CFLAGS=-O2 -pipe) TB --- 2005-04-29 20:09:26 - cd /home/tinderbox/CURRENT/amd64/amd64/src TB --- 2005-04-29 20:09: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 [...] rm -f init init.o init.8.gz init.8.cat.gz rm -f .depend GPATH GRTAGS GSYMS GTAGS ===> sbin/ip6fw (cleandir) rm -f ip6fw ip6fw.o ip6fw.8.gz ip6fw.8.cat.gz rm -f .depend GPATH GRTAGS GSYMS GTAGS ===> sbin/ipf (cleandir) ".depend", line 269: Inconsistent operator for ipf make: fatal errors encountered -- cannot continue *** Error code 1 Stop in /tinderbox/CURRENT/amd64/amd64/src/sbin. *** 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-29 20:10:32 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-04-29 20:10:32 - ERROR: failed to build world TB --- 2005-04-29 20:10:32 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Fri Apr 29 20:16: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 9238B16A4CE; Fri, 29 Apr 2005 20:16:49 +0000 (GMT) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 30B2A43D41; Fri, 29 Apr 2005 20:16:49 +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 j3TKGmtq001431; Fri, 29 Apr 2005 16:16:48 -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 j3TKHNG2006900; Fri, 29 Apr 2005 16:17:23 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 914017306E; Fri, 29 Apr 2005 16:16:48 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050429201648.914017306E@freebsd-current.sentex.ca> Date: Fri, 29 Apr 2005 16:16:48 -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 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: Fri, 29 Apr 2005 20:16:49 -0000 TB --- 2005-04-29 20:10:33 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-04-29 20:10:33 - starting CURRENT tinderbox run for i386/i386 TB --- 2005-04-29 20:10:33 - checking out the source tree TB --- 2005-04-29 20:10:33 - cd /home/tinderbox/CURRENT/i386/i386 TB --- 2005-04-29 20:10:33 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-04-29 20:15:43 - building world (CFLAGS=-O2 -pipe) TB --- 2005-04-29 20:15:43 - cd /home/tinderbox/CURRENT/i386/i386/src TB --- 2005-04-29 20:15:43 - /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 [...] rm -f init init.o init.8.gz init.8.cat.gz rm -f .depend GPATH GRTAGS GSYMS GTAGS ===> sbin/ip6fw (cleandir) rm -f ip6fw ip6fw.o ip6fw.8.gz ip6fw.8.cat.gz rm -f .depend GPATH GRTAGS GSYMS GTAGS ===> sbin/ipf (cleandir) ".depend", line 269: Inconsistent operator for ipf make: fatal errors encountered -- cannot continue *** Error code 1 Stop in /tinderbox/CURRENT/i386/i386/src/sbin. *** 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-29 20:16:48 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-04-29 20:16:48 - ERROR: failed to build world TB --- 2005-04-29 20:16:48 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Fri Apr 29 20:17: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 3916616A4CE; Fri, 29 Apr 2005 20:17:52 +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 91AAF43D3F; Fri, 29 Apr 2005 20:17:51 +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]) j3TKHoCG016291 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sat, 30 Apr 2005 06:17:50 +1000 Received: from cirb503493.alcatel.com.au (localhost.alcatel.com.au [127.0.0.1])j3TKHnXw006777; Sat, 30 Apr 2005 06:17:49 +1000 (EST) (envelope-from pjeremy@cirb503493.alcatel.com.au) Received: (from pjeremy@localhost)j3TKHn03006776; Sat, 30 Apr 2005 06:17:49 +1000 (EST) (envelope-from pjeremy) Date: Sat, 30 Apr 2005 06:17:49 +1000 From: Peter Jeremy To: John Sconiers Message-ID: <20050429201749.GD232@cirb503493.alcatel.com.au> References: <57436.216.177.243.42.1114582155.localmail@webmail.dnswatch.com> <20050429005319.GA17799@laptoxa.toxa.lan> <60093.216.177.243.35.1114761721.localmail@webmail.dnswatch.com> <200504291629.26564.lofi@freebsd.org> 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 cc: Michael Nottebrock Subject: Re: boot banner project X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 29 Apr 2005 20:17:52 -0000 On Fri, 2005-Apr-29 14:08:44 -0500, John Sconiers wrote: >Is there a reason why we haven't adopted the bsdinstaller? >(www.bsdinstaller.org) The most likely reason is that no-one has done the work to either turn it into a port or integrate it into FreeBSD. -- Peter Jeremy From owner-freebsd-current@FreeBSD.ORG Fri Apr 29 20:20: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 E10D816A4CE; Fri, 29 Apr 2005 20:20:36 +0000 (GMT) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8263743D31; Fri, 29 Apr 2005 20:20:36 +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 j3TKKac3015655; Fri, 29 Apr 2005 16:20: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 j3TKLAKf009162; Fri, 29 Apr 2005 16:21:10 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 156F57306E; Fri, 29 Apr 2005 16:20:36 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050429202036.156F57306E@freebsd-current.sentex.ca> Date: Fri, 29 Apr 2005 16:20: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/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: Fri, 29 Apr 2005 20:20:37 -0000 TB --- 2005-04-29 20:16:48 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-04-29 20:16:48 - starting CURRENT tinderbox run for i386/pc98 TB --- 2005-04-29 20:16:48 - checking out the source tree TB --- 2005-04-29 20:16:48 - cd /home/tinderbox/CURRENT/i386/pc98 TB --- 2005-04-29 20:16:48 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-04-29 20:19:29 - building world (CFLAGS=-O2 -pipe) TB --- 2005-04-29 20:19:29 - cd /home/tinderbox/CURRENT/i386/pc98/src TB --- 2005-04-29 20:19:29 - /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 [...] rm -f init init.o init.8.gz init.8.cat.gz rm -f .depend GPATH GRTAGS GSYMS GTAGS ===> sbin/ip6fw (cleandir) rm -f ip6fw ip6fw.o ip6fw.8.gz ip6fw.8.cat.gz rm -f .depend GPATH GRTAGS GSYMS GTAGS ===> sbin/ipf (cleandir) ".depend", line 299: Inconsistent operator for ipf make: fatal errors encountered -- cannot continue *** Error code 1 Stop in /tinderbox/CURRENT/i386/pc98/src/sbin. *** 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-29 20:20:36 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-04-29 20:20:36 - ERROR: failed to build world TB --- 2005-04-29 20:20:36 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Fri Apr 29 20:21: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 9DC2716A4CE for ; Fri, 29 Apr 2005 20:21:03 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id F32A943D1D for ; Fri, 29 Apr 2005 20:21:02 +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.3/8.13.3) with ESMTP id j3TKOv0D032797; Fri, 29 Apr 2005 14:24:57 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <4272971C.70307@samsco.org> Date: Fri, 29 Apr 2005 14:20:44 -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: racerx@makeworld.com References: <57436.216.177.243.42.1114582155.localmail@webmail.dnswatch.com> <6.1.0.6.2.20050426233321.084e9210@cobalt.antimatter.net> <51899.216.177.243.42.1114584317.localmail@webmail.dnswatch.com> <6.1.0.6.2.20050427001118.0327cd50@cobalt.antimatter.net> <52515.216.177.243.42.1114586501.localmail@webmail.dnswatch.com> <61359.216.177.243.35.1114722481.localmail@webmail.dnswatch.com> <20050429105416.GA94049@wedge.madpilot.net> <42728DF1.9040908@makeworld.com> <427291EE.4080809@makeworld.com> In-Reply-To: <427291EE.4080809@makeworld.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: /dev/null cc: John Sconiers cc: Guido Falsi cc: freebsd-current@freebsd.org Subject: Re: boot banner project X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 29 Apr 2005 20:21:04 -0000 Chris wrote: > John Sconiers wrote: > > >>On 4/29/05, Chris wrote: >> >> >>>John Sconiers wrote: >>>... >>> >>> >>>>Adding less then a meg here or there is not bloat. Unless of course the goal is to >>>>create an advanced operating system unable to get / keep users. >>>> >>>>My $.02 >>> >>>The problem is this; if everyone keeps adding "less then a meg here or >>>there" then you DO end up with bloat. >>> >>>Where to you draw the line? How much is too much? To me, I would rather >>>add that less then a meg here and there to the core OS ... Not to >>>something that (to me) does not need to look perdy. >>> >>>... and my .02 >>> >>>-- >>>Best regards, >>>Chris >>> >>>If reproducibility may be a problem conduct the >>>test only once. >>> > > > John Sconiers wrote: > >>Do you want to get / keep new users, compete wth other operating >>systems, etc.... >> > > > Of course - but NOT at the expense for the OS itself. The banner is only > seen once. It does not have to be perdy to attract users. > > If that's the case, if it needs to be perdy to attract users - then > (speaking for myself) do you want that flavor of user? > > Are you not at that point trying to emulate a Windows-ee look? As I > said, I care more about the quality of the OS. > > It's pretty lame to make technical decisions based on schoolyard politics of who is and isn't cool enough to play with our to toys. Software projects with conceited attitudes rarely survive. Scott From owner-freebsd-current@FreeBSD.ORG Fri Apr 29 20:26: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 395F816A4CE; Fri, 29 Apr 2005 20:26:00 +0000 (GMT) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id CDD8343D3F; Fri, 29 Apr 2005 20:25:59 +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 j3TKPxL0016120; Fri, 29 Apr 2005 16:25:59 -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 j3TKPxJn032395; Fri, 29 Apr 2005 16:25:59 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 49A587306E; Fri, 29 Apr 2005 16:25:59 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050429202559.49A587306E@freebsd-current.sentex.ca> Date: Fri, 29 Apr 2005 16:25:59 -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 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: Fri, 29 Apr 2005 20:26:00 -0000 TB --- 2005-04-29 20:20:36 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-04-29 20:20:36 - starting CURRENT tinderbox run for ia64/ia64 TB --- 2005-04-29 20:20:36 - checking out the source tree TB --- 2005-04-29 20:20:36 - cd /home/tinderbox/CURRENT/ia64/ia64 TB --- 2005-04-29 20:20:36 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-04-29 20:24:53 - building world (CFLAGS=-O2 -pipe) TB --- 2005-04-29 20:24:53 - cd /home/tinderbox/CURRENT/ia64/ia64/src TB --- 2005-04-29 20:24:53 - /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 [...] rm -f init init.o init.8.gz init.8.cat.gz rm -f .depend GPATH GRTAGS GSYMS GTAGS ===> sbin/ip6fw (cleandir) rm -f ip6fw ip6fw.o ip6fw.8.gz ip6fw.8.cat.gz rm -f .depend GPATH GRTAGS GSYMS GTAGS ===> sbin/ipf (cleandir) ".depend", line 269: Inconsistent operator for ipf make: fatal errors encountered -- cannot continue *** Error code 1 Stop in /tinderbox/CURRENT/ia64/ia64/src/sbin. *** Error code 1 Stop in /tinderbox/CURRENT/ia64/ia64/src. *** Error code 1 Stop in /tinderbox/CURRENT/ia64/ia64/src. *** Error code 1 Stop in /tinderbox/CURRENT/ia64/ia64/src. TB --- 2005-04-29 20:25:59 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-04-29 20:25:59 - ERROR: failed to build world TB --- 2005-04-29 20:25:59 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Fri Apr 29 20:30: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 4071B16A4CE; Fri, 29 Apr 2005 20:30:04 +0000 (GMT) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id D195943D58; Fri, 29 Apr 2005 20:30:03 +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 j3TKU3K4016350; Fri, 29 Apr 2005 16:30:03 -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 j3TKU3Zq015154; Fri, 29 Apr 2005 16:30:03 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 3E9797306E; Fri, 29 Apr 2005 16:30:03 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050429203003.3E9797306E@freebsd-current.sentex.ca> Date: Fri, 29 Apr 2005 16:30:03 -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 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: Fri, 29 Apr 2005 20:30:04 -0000 TB --- 2005-04-29 20:25:59 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-04-29 20:25:59 - starting CURRENT tinderbox run for powerpc/powerpc TB --- 2005-04-29 20:25:59 - checking out the source tree TB --- 2005-04-29 20:25:59 - cd /home/tinderbox/CURRENT/powerpc/powerpc TB --- 2005-04-29 20:25:59 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-04-29 20:28:59 - building world (CFLAGS=-O2 -pipe) TB --- 2005-04-29 20:28:59 - cd /home/tinderbox/CURRENT/powerpc/powerpc/src TB --- 2005-04-29 20:28: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 [...] rm -f init init.o init.8.gz init.8.cat.gz rm -f .depend GPATH GRTAGS GSYMS GTAGS ===> sbin/ip6fw (cleandir) rm -f ip6fw ip6fw.o ip6fw.8.gz ip6fw.8.cat.gz rm -f .depend GPATH GRTAGS GSYMS GTAGS ===> sbin/ipf (cleandir) ".depend", line 272: Inconsistent operator for ipf make: fatal errors encountered -- cannot continue *** Error code 1 Stop in /tinderbox/CURRENT/powerpc/powerpc/src/sbin. *** Error code 1 Stop in /tinderbox/CURRENT/powerpc/powerpc/src. *** Error code 1 Stop in /tinderbox/CURRENT/powerpc/powerpc/src. *** Error code 1 Stop in /tinderbox/CURRENT/powerpc/powerpc/src. TB --- 2005-04-29 20:30:03 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-04-29 20:30:03 - ERROR: failed to build world TB --- 2005-04-29 20:30:03 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Fri Apr 29 20: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 9993616A4CE; Fri, 29 Apr 2005 20:31:17 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id F2A0943D5D; Fri, 29 Apr 2005 20:31:16 +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 j3TKSxNm027529; Fri, 29 Apr 2005 14:29:02 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Fri, 29 Apr 2005 14:29:40 -0600 (MDT) Message-Id: <20050429.142940.43005573.imp@bsdimp.com> To: darrenr@hub.freebsd.org From: "M. Warner Losh" In-Reply-To: <20050428155451.GA2192@hub.freebsd.org> References: <20050428152622.GC92579@ip.net.ua> <427100CC.8080604@samsco.org> <20050428155451.GA2192@hub.freebsd.org> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: darrenr@freebsd.org cc: current@freebsd.org Subject: Re: LINT broken due to ipfilter X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 29 Apr 2005 20:31:17 -0000 In message: <20050428155451.GA2192@hub.freebsd.org> Darren Reed writes: : On Thu, Apr 28, 2005 at 09:27:08AM -0600, Scott Long wrote: : > Leaving the tree unbuildable for 3 days is unacceptable. I doubt that : > any other active OSS project would tolerate it, and I'm sure that Sun : > wouldn't tolerate it either. : : Well, FreeBSD seems to have a history of allowing this...I seem to recall : some other part of the build being broken when I did the initial commit : for ipf...not to mention there being many times in the past when I've seen : comments about the build being broken in one way or another. No. FreeBSD does not have a history of allowing things to be broken for 3 days. While things are sometims broken for this long, it is not considered acceptable or OK by any means. The tree must be buildable at all times, and any breakage longer than a couple of hours is not considered acceptable and the folks that have broken the tree are usually remonstrated in privated multiple times for such breakage. Given then this breakage was 10x longer than the usual threshold for private complaints, I think that the public complaint is completely justified. : My single biggest issue remains the number of boxes needed to keep things : compiling on FreeBSD. 4.11, 5.4, -current. That is a really tough ask : on anyone and last I checked, there's only a ref4 and a ref5. You only need one box to build universe for -current, since that's what you broek. : So....if you want to make it easier for people like me to make sure they : haven't broken the build, put a target in src/Makefile that achieves this. : That is, buildworld and buildkernel and build LINT and whatever else for : a single platform. Or at least I think buildworld and buildkernel are : required, seperately. "universe" is too much. "universe" can even be built using project resources. freefall usually has enough disk space. However, even if you don't do a universe, the bare minimum is buildworld, and your import didn't pass that, and the subsequent delay in fixing it was longer than is reasonable. I think you are complaining too loudly here. The fact remains that you committed the imported sources to the tree before your integration with FreeBSD sources was complete. It took several days to resolve these integration problems. That's not acceptable. Esepcailly when no heads up was given. : Having said all that, I appreciate any assistance others can give, : especially clues on what to do with rescue. Yes. That was a good thing. The community really pulled together here. Warner From owner-freebsd-current@FreeBSD.ORG Fri Apr 29 20:35: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 C179B16A4CE; Fri, 29 Apr 2005 20:35:31 +0000 (GMT) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5F63B43D46; Fri, 29 Apr 2005 20:35:31 +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 j3TKZV5g003014; Fri, 29 Apr 2005 16:35:31 -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 j3TKZVLD018776; Fri, 29 Apr 2005 16:35:31 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id DB11C7306E; Fri, 29 Apr 2005 16:35:30 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050429203530.DB11C7306E@freebsd-current.sentex.ca> Date: Fri, 29 Apr 2005 16:35:30 -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 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: Fri, 29 Apr 2005 20:35:32 -0000 TB --- 2005-04-29 20:30:03 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-04-29 20:30:03 - starting CURRENT tinderbox run for sparc64/sparc64 TB --- 2005-04-29 20:30:03 - checking out the source tree TB --- 2005-04-29 20:30:03 - cd /home/tinderbox/CURRENT/sparc64/sparc64 TB --- 2005-04-29 20:30:03 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-04-29 20:34:24 - building world (CFLAGS=-O2 -pipe) TB --- 2005-04-29 20:34:24 - cd /home/tinderbox/CURRENT/sparc64/sparc64/src TB --- 2005-04-29 20:34:24 - /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 [...] rm -f init init.o init.8.gz init.8.cat.gz rm -f .depend GPATH GRTAGS GSYMS GTAGS ===> sbin/ip6fw (cleandir) rm -f ip6fw ip6fw.o ip6fw.8.gz ip6fw.8.cat.gz rm -f .depend GPATH GRTAGS GSYMS GTAGS ===> sbin/ipf (cleandir) ".depend", line 275: Inconsistent operator for ipf make: fatal errors encountered -- cannot continue *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/src/sbin. *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/src. *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/src. *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/src. TB --- 2005-04-29 20:35:30 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-04-29 20:35:30 - ERROR: failed to build world TB --- 2005-04-29 20:35:30 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Fri Apr 29 20:55: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 9885316A4CE for ; Fri, 29 Apr 2005 20:55:52 +0000 (GMT) Received: from fw.farid-hajji.net (fw.farid-hajji.net [213.146.115.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 00B0443D45 for ; Fri, 29 Apr 2005 20:55:52 +0000 (GMT) (envelope-from cpghost@cordula.ws) Received: from [192.168.254.11] (epia-2 [192.168.254.11]) by fw.farid-hajji.net (Postfix) with ESMTP id 49E2D4B3FB; Fri, 29 Apr 2005 22:53:16 +0200 (CEST) Message-ID: <42729FBF.8010800@cordula.ws> Date: Fri, 29 Apr 2005 22:57:35 +0200 From: cpghost User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050428) X-Accept-Language: en-us, en MIME-Version: 1.0 To: John Sconiers References: <57436.216.177.243.42.1114582155.localmail@webmail.dnswatch.com> <6.1.0.6.2.20050426233321.084e9210@cobalt.antimatter.net> <51899.216.177.243.42.1114584317.localmail@webmail.dnswatch.com> <6.1.0.6.2.20050427001118.0327cd50@cobalt.antimatter.net> <52515.216.177.243.42.1114586501.localmail@webmail.dnswatch.com> <61359.216.177.243.35.1114722481.localmail@webmail.dnswatch.com> <20050429105416.GA94049@wedge.madpilot.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: /dev/null cc: Guido Falsi cc: freebsd-current@freebsd.org Subject: Re: boot banner project X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 29 Apr 2005 20:55:52 -0000 John Sconiers wrote: >Adding less then a meg here or there is not bloat. > It is a mistake to assume that memory is cheap and always easily available and/or upgradable. There are quite a lot of embedded systems out there, that run FreeBSD out-of-the-box, without the need to tweak or manually remove all that unnecessary eye candy. Such systems come with RAM soldered on-board, so they are impossible to upgrade. If you really want a GUIfied installer (and please remember that some hardware like Soekris boxes don't even have VGA circuitery!), then please only as a port (that would create a custom boot image), or as an optional add-on. The default install should still be possible over serial line and on striped down hardware. The same holds true for boot banners: not every hardware out there has hires graphics capabilities. Regards, -cpghost. -- Cordula's Web. http://www.cordula.ws/ From owner-freebsd-current@FreeBSD.ORG Fri Apr 29 21:01: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 4205D16A4CE for ; Fri, 29 Apr 2005 21:01:24 +0000 (GMT) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id BF11743D45 for ; Fri, 29 Apr 2005 21:01:23 +0000 (GMT) (envelope-from jsconiers@gmail.com) Received: by wproxy.gmail.com with SMTP id 69so929405wra for ; Fri, 29 Apr 2005 14:01: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=icZbVoKlSg18gJKkHK8uoynfVzPD3DTH7IPJAShgt6GARZGHxzCvhiuQIO9BXj5oKvFOu3c6e5HYb3rVs5mww6GqhsozoLwijNgWEBk/ttSJwRHINs4+bJqUASfrSouzB9TUpUcjNETIG6xtDKg0FMjapJo+GxURIbHpQ9UD8ho= Received: by 10.54.33.39 with SMTP id g39mr1929371wrg; Fri, 29 Apr 2005 14:01:23 -0700 (PDT) Received: by 10.54.5.75 with HTTP; Fri, 29 Apr 2005 14:01:23 -0700 (PDT) Message-ID: Date: Fri, 29 Apr 2005 16:01:23 -0500 From: John Sconiers To: cpghost In-Reply-To: <42729FBF.8010800@cordula.ws> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <57436.216.177.243.42.1114582155.localmail@webmail.dnswatch.com> <6.1.0.6.2.20050426233321.084e9210@cobalt.antimatter.net> <51899.216.177.243.42.1114584317.localmail@webmail.dnswatch.com> <6.1.0.6.2.20050427001118.0327cd50@cobalt.antimatter.net> <52515.216.177.243.42.1114586501.localmail@webmail.dnswatch.com> <61359.216.177.243.35.1114722481.localmail@webmail.dnswatch.com> <20050429105416.GA94049@wedge.madpilot.net> <42729FBF.8010800@cordula.ws> cc: /dev/null cc: Guido Falsi cc: freebsd-current@freebsd.org Subject: Re: boot banner project X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: John Sconiers List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Apr 2005 21:01:24 -0000 We should be able to have both in a unified installer / banner. The same way Mac OS X, Solaris, Linux, Novell, etc.....have both.....or am I missing something........ JOHN On 4/29/05, cpghost wrote: > John Sconiers wrote: >=20 > >Adding less then a meg here or there is not bloat. > > > It is a mistake to assume that memory is cheap and always easily > available and/or upgradable. There are quite a lot of embedded > systems out there, that run FreeBSD out-of-the-box, without the > need to tweak or manually remove all that unnecessary eye candy. > Such systems come with RAM soldered on-board, so they are > impossible to upgrade. >=20 > If you really want a GUIfied installer (and please remember that > some hardware like Soekris boxes don't even have VGA circuitery!), > then please only as a port (that would create a custom boot image), > or as an optional add-on. The default install should still be possible > over serial line and on striped down hardware. >=20 > The same holds true for boot banners: not every hardware out there > has hires graphics capabilities. >=20 > Regards, > -cpghost. >=20 > -- > Cordula's Web. http://www.cordula.ws/ >=20 > From owner-freebsd-current@FreeBSD.ORG Fri Apr 29 21:24: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 4ECF016A4CE; Fri, 29 Apr 2005 21:24:59 +0000 (GMT) Received: from april.chuckr.org (april.chuckr.org [66.92.151.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id 13B4E43D45; Fri, 29 Apr 2005 21:24:59 +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 4658C12123; Fri, 29 Apr 2005 17:20:05 -0400 (EDT) Message-ID: <4272A5FF.5090703@chuckr.org> Date: Fri, 29 Apr 2005 21:24:15 +0000 From: Chuck Robey User-Agent: Mozilla Thunderbird 1.0 (X11/20050316) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Peter Jeremy References: <57436.216.177.243.42.1114582155.localmail@webmail.dnswatch.com> <20050429005319.GA17799@laptoxa.toxa.lan> <60093.216.177.243.35.1114761721.localmail@webmail.dnswatch.com> <200504291629.26564.lofi@freebsd.org> <20050429201749.GD232@cirb503493.alcatel.com.au> In-Reply-To: <20050429201749.GD232@cirb503493.alcatel.com.au> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-current@freebsd.org cc: John Sconiers cc: Michael Nottebrock Subject: Re: boot banner project X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 29 Apr 2005 21:24:59 -0000 Peter Jeremy wrote: > On Fri, 2005-Apr-29 14:08:44 -0500, John Sconiers wrote: > >>Is there a reason why we haven't adopted the bsdinstaller? >>(www.bsdinstaller.org) > > > The most likely reason is that no-one has done the work to either turn > it into a port or integrate it into FreeBSD. My own take on this, is when I want something, I propose it. If I get a bunch of suggestions, I respond by going off and coding it, If I get a bunch of complaints, I let it die. But what most often happens, someone who is less upset by the political arguing than I am goes off and codes it, and litens to the flack until it gets accepted. I don't do very well, listening to flack. > From owner-freebsd-current@FreeBSD.ORG Fri Apr 29 21:35:53 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7479E16A4CE for ; Fri, 29 Apr 2005 21:35:53 +0000 (GMT) Received: from postfix3-2.free.fr (postfix3-2.free.fr [213.228.0.169]) by mx1.FreeBSD.org (Postfix) with ESMTP id 37B6D43D41 for ; Fri, 29 Apr 2005 21:35:53 +0000 (GMT) (envelope-from aymeric.muntz@free.fr) Received: from serveur.thrruss.org (unknown [81.56.231.36]) by postfix3-2.free.fr (Postfix) with ESMTP id 555C7C04B for ; Fri, 29 Apr 2005 23:35:52 +0200 (CEST) Received: from artemis (artemis [192.168.2.2]) by serveur.thrruss.org (8.13.0/8.13.0) with SMTP id j3TMRShr025484 for ; Sat, 30 Apr 2005 00:27:28 +0200 From: "Aymeric MUNTZ" To: Date: Fri, 29 Apr 2005 23:36:00 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Subject: Iso modification X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 29 Apr 2005 21:35:53 -0000 Hi all, I am actually working on an iso modification (install ISO). I would like to modify the original ISO freebsd release to add some custom files. When I modify the iso and burn it, the dvd (I added a few files) doesn't go very far in the boot process. Does anyone know how to make a clean modification of the iso? Thanks Aymeric From owner-freebsd-current@FreeBSD.ORG Fri Apr 29 21:51: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 E6C9C16A4CE for ; Fri, 29 Apr 2005 21:51:21 +0000 (GMT) Received: from rdsmtp.iglou.com (rdsmtp.iglou.com [192.107.41.63]) by mx1.FreeBSD.org (Postfix) with ESMTP id B92D143D54 for ; Fri, 29 Apr 2005 21:51:21 +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 1DRdOL-0005im-DR for freebsd-current@freebsd.org; Fri, 29 Apr 2005 17:51:21 -0400 Received: from [192.107.41.17] (helo=shell1) by iglou2.iglou.com with esmtp (8.12.5/8.12.5) id 1DRdOL-00021Z-3E; Fri, 29 Apr 2005 17:51:21 -0400 Date: Fri, 29 Apr 2005 17:51:21 -0400 (EDT) From: Darrel X-X-Sender: dlevitch@shell1 To: John Sconiers In-Reply-To: Message-ID: References: <57436.216.177.243.42.1114582155.localmail@webmail.dnswatch.com> <6.1.0.6.2.20050426233321.084e9210@cobalt.antimatter.net> <51899.216.177.243.42.1114584317.localmail@webmail.dnswatch.com> <6.1.0.6.2.20050427001118.0327cd50@cobalt.antimatter.net> <52515.216.177.243.42.1114586501.localmail@webmail.dnswatch.com> <61359.216.177.243.35.1114722481.localmail@webmail.dnswatch.com> 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 Subject: Re: boot banner project X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 29 Apr 2005 21:51:22 -0000 On Fri, 29 Apr 2005, John Sconiers wrote: > We should be able to have both in a unified installer / banner. The > same way Mac OS X, Solaris, Linux, Novell, etc.....have both.....or am > I missing something........ > > JOHN > I installed Mac OS X a few minutes ago. Although I found FreeBSD install to be unintuitive at first, I prefer it to the current Apple install. Darrel From owner-freebsd-current@FreeBSD.ORG Fri Apr 29 22:02: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 9D59116A4CE for ; Fri, 29 Apr 2005 22:02:58 +0000 (GMT) Received: from basement.kutulu.org (211.215.33.65.cfl.res.rr.com [65.33.215.211]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5145A43D45 for ; Fri, 29 Apr 2005 22:02:58 +0000 (GMT) (envelope-from kutulu@kutulu.org) Received: from [127.0.0.1] (platypus.jungle [192.168.69.2]) by basement.kutulu.org (Postfix) with ESMTP id 8BCF59A; Fri, 29 Apr 2005 18:02:57 -0400 (EDT) Message-ID: <4272AFD8.3070708@kutulu.org> Date: Fri, 29 Apr 2005 18:06:16 -0400 From: Mike Edenfield Organization: KutuluWare Software Services User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <57436.216.177.243.42.1114582155.localmail@webmail.dnswatch.com> <6.1.0.6.2.20050426233321.084e9210@cobalt.antimatter.net> <51899.216.177.243.42.1114584317.localmail@webmail.dnswatch.com> <6.1.0.6.2.20050427001118.0327cd50@cobalt.antimatter.net> <52515.216.177.243.42.1114586501.localmail@webmail.dnswatch.com> <61359.216.177.243.35.1114722481.localmail@webmail.dnswatch.com> In-Reply-To: X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-current@freebsd.org cc: John Sconiers Subject: Re: boot banner project X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 29 Apr 2005 22:02:58 -0000 Darrel wrote: > On Fri, 29 Apr 2005, John Sconiers wrote: > >> We should be able to have both in a unified installer / banner. The >> same way Mac OS X, Solaris, Linux, Novell, etc.....have both.....or am >> I missing something........ >> >> JOHN >> > > I installed Mac OS X a few minutes ago. > > Although I found FreeBSD install to be unintuitive at first, I prefer it > to the current Apple install. And it could be worse... it could be Gentoo. -- -- Mike Still using IE? Get Firefox! http://www.spreadfirefox.com/?q=affiliates&id=6492&t=1 From owner-freebsd-current@FreeBSD.ORG Fri Apr 29 22:05: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 E68C516A4CE; Fri, 29 Apr 2005 22:05:05 +0000 (GMT) Received: from mail.sorbs.net (mail.sorbs.net [203.15.51.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id 140E243D3F; Fri, 29 Apr 2005 22:05:05 +0000 (GMT) (envelope-from matthew@uq.edu.au) Received: from [10.200.254.98] by nemesis.sorbs.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0IFQ00G0HAP718@nemesis.sorbs.net>; Sat, 30 Apr 2005 08:05:32 +1000 (EST) Date: Sat, 30 Apr 2005 08:03:53 +1000 From: Matthew Sullivan In-reply-to: <426E0F5C.3F157398@freebsd.org> To: Andre Oppermann Message-id: <4272AF49.1090400@uq.edu.au> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041231 References: <20050424150211.GA87520@walton.maths.tcd.ie> <426BC78A.3E56D99B@freebsd.org> <426C1600.106@uq.edu.au> <426D2307.97D15253@freebsd.org> <426D306B.7010000@freebsd.org> <20050426094337.GA44893@walton.maths.tcd.ie> <426E0F5C.3F157398@freebsd.org> cc: David Malone cc: qingli@freebsd.org cc: silby@freebsd.org cc: freebsd-current@freebsd.org Subject: Re: DF (Don't frag) issues X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 29 Apr 2005 22:05:06 -0000 Andre Oppermann wrote: >David Malone wrote: > > >>On Mon, Apr 25, 2005 at 08:01:15PM +0200, Andre Oppermann wrote: >> >> >>> - Handling of received ICMP Needfrag messages. The logic was broken >>> for the cases where the ICMP didn't contain a suggested value. This >>> brokeness is in there since 5.2R and comes from my cleanup of the >>> routing table and introduction of TCP hostcache. However there is >>> no way to fix it at all. It was broken even before I broke it more. >>> The idea behind the old code was to step down the MTU when we got >>> a ICMP Needfrag by one step and try again. Unfortunatly it is very >>> likely that the tcp window was open by a few segments already when >>> we hit this. This gets us a number of those ICMP's in rapid succession >>> each stepping us one down. >>> >>> >>I wonder if we could look into the quoted IP header and extract the >>length of the IP packet that caused the needs-frag ICMP. That would >>stop us getting in knots when there are a few packets in flight and >>would give us a good idea about where we need to step down from. >> >> > >This is a really clever idea indeed. But it only works if part of >the original packet is attached. Broken implementations are likely >to omit that. But I'll implement your suggestion as well and post >a new patch later this evening. > > > Did you ever do this second patch....? Yesturday I got the first patch installed and compiled (well I got the patch in long before that, but it took until yesturday to get a kernel compiled thanks to the ipf (and others) issues). Results are at: http://scorpion.sorbs.net/ICMP/ It seems to have worked to the point it actually works and the problems go away. However, looking at the dump it appears to have set the MTU to 552, which as the tunnel is 1280 (unencrypted) seems a little inefficient... Comments...? Regards, Mat -- Matthew Sullivan Specialist Systems Programmer Information Technology Services The University of Queensland From owner-freebsd-current@FreeBSD.ORG Fri Apr 29 22: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 E19CD16A4CF for ; Fri, 29 Apr 2005 22:06:00 +0000 (GMT) Received: from mail.mercenarylabs.com (ns1.mercenarylabs.com [12.158.191.94]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1E99343D4C for ; Fri, 29 Apr 2005 22:06:00 +0000 (GMT) (envelope-from jondoor@udor.net) Received: from [127.0.0.1] (wilson [12.158.191.94]) by mail.mercenarylabs.com (Postfix) with ESMTP id 2AF39AD17 for ; Fri, 29 Apr 2005 17:06:00 -0500 (CDT) Message-ID: <4272AFC6.2040907@udor.net> Date: Fri, 29 Apr 2005 18:05:58 -0400 From: Jon Door User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050326) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-current@freebsd.org X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: ATA RAID -- Promise SATA150 vanished /dev/ar0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: jondoor@udor.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Apr 2005 22:06:01 -0000 I have a Promise Fastrak SATA RAID controller (PDC20371). Running a stripe between two 120GB drives. Running under a generic RELENG_5 the controller, its drives, and the stripe where all detect without problem. /dev/ar0 was generated without any special changes. Today I upgraded to 6.0-CURRENT. Now the Promise controller and its drives are recognized but no /dev/ar0, and no evidence of the stripe. Booting back to a RELENG_5 system show the stripe data to still be intact. I've beem reading through all the ATA mkIII posts and haven't seen this specific issue, am I missing a step here or is this possibly an issue between the new ATA code and my RAID card? Are there more up to date patches for the ATA code that I might have missed? Thank You. I do have the following devices in my kernel config and have tried both a custom config and a totally generic kernel: # $FreeBSD: src/sys/i386/conf/GENERIC,v 1.428 2005/03/31 20:21:42 scottl Exp $ device ata device atadisk # ATA disk drives device ataraid # ATA RAID drives dmesg devices found: atapci1: port 0xa000-0xa03f,0x9800-0x980f,0x9400-0x947f mem 0xe0800000-0xe0800fff,0xe0000000-0xe001ffff irq 17 at device 11.0 on pci0 ata2: on atapci1 ata2: SATA connect ready time=0ms ata3: on atapci1 ata3: SATA connect ready time=0ms ata4: on atapci1 acd0: DVDROM at ata1-master UDMA66 acd1: CDRW at ata1-slave UDMA33 ad4: 114440MB at ata2-master SATA150 ad6: 114440MB at ata3-master SATA150 ATA PseudoRAID loaded The full dmesg output: 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: Fri Apr 29 15:15:49 EDT 2005 root@tower.en.udor.net:/usr/obj/usr/src/sys/KERNEL ACPI APIC Table: Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel Pentium III (937.55-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x68a Stepping = 10 Features=0x383fbff real memory = 671072256 (639 MB) avail memory = 647434240 (617 MB) FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 3 cpu1 (AP): APIC ID: 0 ioapic0 irqs 0-23 on motherboard netsmb_dev: loaded npx0: [FAST] npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard acpi0: Power Button (fixed) pci_link0: irq 11 on acpi0 pci_link1: irq 10 on acpi0 pci_link2: irq 12 on acpi0 pci_link3: irq 3 on acpi0 Timecounter "ACPI-safe" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0xe408-0xe40b on acpi0 cpu0: on acpi0 cpu1: on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 agp0: mem 0xf0000000-0xf7ffffff at device 0.0 on pci0 pcib1: at device 1.0 on pci0 pci1: on pcib1 pci1: at device 0.0 (no driver attached) isab0: at device 4.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xd800-0xd80f at device 4.1 on pci0 ata0: on atapci0 ata1: on atapci0 uhci0: port 0xd400-0xd41f irq 12 at device 4.2 on pci0 uhci0: [GIANT-LOCKED] usb0: on uhci0 usb0: USB revision 1.0 uhub0: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1: port 0xd000-0xd01f irq 12 at device 4.3 on pci0 uhci1: [GIANT-LOCKED] usb1: on uhci1 usb1: USB revision 1.0 uhub1: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered fxp0: port 0xb800-0xb83f mem 0xe4800000-0xe4800fff,0xe4000000-0xe40fffff at device 7.0 on pci0 miibus0: on fxp0 inphy0: on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp0: Ethernet address: 00:00:00:00:00:00 sym0: <1010-33> port 0xb400-0xb4ff mem 0xe3800000-0xe38003ff,0xe3000000-0xe3001fff irq 19 at device 8.0 on pci0 sym0: Symbios NVRAM, ID 7, Fast-80, LVD, parity checking sym0: open drain IRQ line driver, using on-chip SRAM sym0: using LOAD/STORE-based firmware. sym0: handling phase mismatch from SCRIPTS. sym0: [GIANT-LOCKED] sym1: <1010-33> port 0xb000-0xb0ff mem 0xe2800000-0xe28003ff,0xe2000000-0xe2001fff irq 16 at device 8.1 on pci0 sym1: Symbios NVRAM, ID 7, Fast-80, LVD, parity checking sym1: open drain IRQ line driver, using on-chip SRAM sym1: using LOAD/STORE-based firmware. sym1: handling phase mismatch from SCRIPTS. sym1: [GIANT-LOCKED] pcm0: port 0xa800-0xa81f at device 9.0 on pci0 pcm0: fwohci0: <1394 Open Host Controller Interface> mem 0xe1800000-0xe18007ff,0xe1000000-0xe1003fff at device 9.2 on pci0 fwohci0: OHCI version 1.10 (ROM=0) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 00:00:00:00:00:00:00:00 fwohci0: Phy 1394a available S400, 2 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 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) atapci1: port 0xa000-0xa03f,0x9800-0x980f,0x9400-0x947f mem 0xe0800000-0xe0800fff,0xe0000000-0xe001ffff irq 17 at device 11.0 on pci0 ata2: on atapci1 ata2: SATA connect ready time=0ms ata3: on atapci1 ata3: SATA connect ready time=0ms ata4: on atapci1 bktr0: mem 0xe7000000-0xe7000fff at device 13.0 on pci0 bktr0: [GIANT-LOCKED] bktr0: Hauppauge Model 44811 D123 bktr0: Hauppauge WinCast/TV, Philips FR1236 NTSC FM tuner. pci0: at device 13.1 (no driver attached) speaker0: port 0x61 on acpi0 sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] pmtimer0 on isa0 orm0: at iomem 0xc0000-0xcefff,0xd0000-0xd3fff,0xd4000-0xd7fff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> 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 ugen0: vendor 0x046d product 0x0810, rev 1.00/1.00, addr 2 ums0: Logitech USB-PS/2 Optical Mouse, rev 2.00/13.00, addr 3, iclass 3/1 ums0: 4 buttons and Z dir. Timecounters tick every 1.000 msec (noperiph:sym0:0:-1:-1): SCSI BUS reset delivered. (noperiph:sym1:0:-1:-1): SCSI BUS reset delivered. pid 27: corrected slot count (0->1) acd0: DVDROM at ata1-master UDMA66 acd1: CDRW at ata1-slave UDMA33 ad4: 114440MB at ata2-master SATA150 ad6: 114440MB at ata3-master SATA150 ATA PseudoRAID loaded SMP: AP CPU #1 Launched! da0 at sym0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-3 device da0: 160.000MB/s transfers (80.000MHz, offset 62, 16bit), Tagged Queueing Enabled da0: 35003MB (71687340 512 byte sectors: 255H 63S/T 4462C) Trying to mount root from ufs:/dev/da0s1a fxp0: Microcode loaded, int_delay: 1000 usec bundle_max: 6 fxp0: Microcode loaded, int_delay: 1000 usec bundle_max: 6 ipfw2 (+ipv6) initialized, divert loadable, rule-based forwarding disabled, default to deny, logging disabled pflog0: promiscuous mode enabled nvidia0: mem 0xe5000000-0xe5ffffff,0xe8000000-0xefffffff irq 16 at device 0.0 on pci1 nvidia0: [GIANT-LOCKED] From owner-freebsd-current@FreeBSD.ORG Fri Apr 29 22:11: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 63F9216A4CE; Fri, 29 Apr 2005 22:11:19 +0000 (GMT) Received: from april.chuckr.org (april.chuckr.org [66.92.151.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2395C43D54; Fri, 29 Apr 2005 22:11:19 +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 9F75C114FC; Fri, 29 Apr 2005 18:06:24 -0400 (EDT) Message-ID: <4272B0DB.50706@chuckr.org> Date: Fri, 29 Apr 2005 22:10:35 +0000 From: Chuck Robey User-Agent: Mozilla Thunderbird 1.0 (X11/20050316) X-Accept-Language: en-us, en MIME-Version: 1.0 To: sparc64@freebsd.org, current Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: useless make warnings X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 29 Apr 2005 22:11:19 -0000 I don't know if this is a current problem or a sparc problem, so I will change my cc'ing just as soon as I determine which. I wrote before about the useless make wornings, there was a fair amount of discussion about it, including much saying that it was a very limited thing. Well, I can tell you that that assertion is pure bunk. I've finished the make buildworld, done even a reboot, and I have still got those errors. they're a major PITA. I guess I could see if they're common to other architectures, i have checked that, and I could do that, sure as heck. figure out why it isn't , if it's not. I would happily offer anyone with commit privs a set of diffs, if you want someone else to do it. I don't mind, and I happen to know enough about makefiles not to cause a disaster, thank you very much. Or, gimme back the commit privs I ised to have. I went awat for a while, combination of work wanting me to become a Linux expert, and all the huge amount of BSD coding I had to do, left me with no time for FreeBSD work anyhow. I have the time again. But I don't care, I will happily offer the diffs, just the same, I'm quite hard to insult, I won't take it that way. Someone would really, really have to convince me to get me to go off in a huff. From owner-freebsd-current@FreeBSD.ORG Fri Apr 29 22:13: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 17DA916A4CE for ; Fri, 29 Apr 2005 22:13:07 +0000 (GMT) Received: from april.chuckr.org (april.chuckr.org [66.92.151.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id CC54043D48 for ; Fri, 29 Apr 2005 22:13:06 +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 74EF5114FC; Fri, 29 Apr 2005 18:08:12 -0400 (EDT) Message-ID: <4272B146.1000806@chuckr.org> Date: Fri, 29 Apr 2005 22:12:22 +0000 From: Chuck Robey User-Agent: Mozilla Thunderbird 1.0 (X11/20050316) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mike Edenfield References: <57436.216.177.243.42.1114582155.localmail@webmail.dnswatch.com> <6.1.0.6.2.20050426233321.084e9210@cobalt.antimatter.net> <51899.216.177.243.42.1114584317.localmail@webmail.dnswatch.com> <6.1.0.6.2.20050427001118.0327cd50@cobalt.antimatter.net> <52515.216.177.243.42.1114586501.localmail@webmail.dnswatch.com> <61359.216.177.243.35.1114722481.localmail@webmail.dnswatch.com> <4272AFD8.3070708@kutulu.org> In-Reply-To: <4272AFD8.3070708@kutulu.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-current@freebsd.org cc: John Sconiers Subject: Re: boot banner project X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 29 Apr 2005 22:13:07 -0000 Mike Edenfield wrote: > Darrel wrote: > >> On Fri, 29 Apr 2005, John Sconiers wrote: >> >>> We should be able to have both in a unified installer / banner. The >>> same way Mac OS X, Solaris, Linux, Novell, etc.....have both.....or am >>> I missing something........ >>> >>> JOHN >>> >> >> I installed Mac OS X a few minutes ago. >> >> Although I found FreeBSD install to be unintuitive at first, I prefer >> it to the current Apple install. > > > And it could be worse... it could be Gentoo. Gentoo is bad, but believe me, in Linux, there's much worse. I just don't like folks jumping on Gentoo, 'cause I so much like their /etc stuff. > From owner-freebsd-current@FreeBSD.ORG Fri Apr 29 22:13: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 0D2CB16A4CE; Fri, 29 Apr 2005 22:13:47 +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 B2A7A43D66; Fri, 29 Apr 2005 22:13:46 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 4AC535133E; Fri, 29 Apr 2005 15:13:45 -0700 (PDT) Date: Fri, 29 Apr 2005 15:13:44 -0700 From: Kris Kennaway To: Chuck Robey Message-ID: <20050429221344.GA66161@xor.obsecurity.org> References: <4272B0DB.50706@chuckr.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="CE+1k2dSO48ffgeK" Content-Disposition: inline In-Reply-To: <4272B0DB.50706@chuckr.org> User-Agent: Mutt/1.4.2.1i cc: current cc: sparc64@freebsd.org Subject: Re: useless make warnings X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 29 Apr 2005 22:13:47 -0000 --CE+1k2dSO48ffgeK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Apr 29, 2005 at 10:10:35PM +0000, Chuck Robey wrote: > I don't know if this is a current problem or a sparc problem, so I will= =20 > change my cc'ing just as soon as I determine which. I wrote before=20 > about the useless make wornings, there was a fair amount of discussion=20 > about it, including much saying that it was a very limited thing. Well,= =20 > I can tell you that that assertion is pure bunk. I've finished the make= =20 > buildworld, done even a reboot, and I have still got those errors.=20 > they're a major PITA. Since the code in question is not in RELENG_5, you must have part of a 6.0 world on your system. Kris --CE+1k2dSO48ffgeK Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFCcrGYWry0BWjoQKURAkdpAKCC/RuqThgm3cwTvC+fBfydOFxCXACgoqs0 bWr0F3Iyi8UQRE6Yge851Uo= =JwQx -----END PGP SIGNATURE----- --CE+1k2dSO48ffgeK-- From owner-freebsd-current@FreeBSD.ORG Fri Apr 29 22:50: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 F37E516A4CE for ; Fri, 29 Apr 2005 22:50:50 +0000 (GMT) Received: from fast.dnswatch.com (fast.dnswatch.com [216.177.243.43]) by mx1.FreeBSD.org (Postfix) with ESMTP id 07FFF43D5D for ; Fri, 29 Apr 2005 22:50:50 +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 j3TMocrt017568; Fri, 29 Apr 2005 15:50:49 -0700 (PDT) (envelope-from null@dnswatch.com) Received: (from www@localhost) by fast.dnswatch.com (8.12.6/8.12.6/Submit) id j3TMoaBW017567; Fri, 29 Apr 2005 15:50:36 -0700 (PDT) (envelope-from null@dnswatch.com) X-Authentication-Warning: fast.dnswatch.com: www set sender to null@dnswatch.com using -f Received: from ns0.1command.com ([216.177.243.38]) (DNSwatch.com_WebMail authenticated user null) by webmail.dnswatch.com with HTTP; Fri, 29 Apr 2005 15:50:35 -0700 (PDT) Message-ID: <1151.216.177.243.38.1114815035.localmail@webmail.dnswatch.com> In-Reply-To: <20050429092734.GC43752@laptoxa.toxa.lan> References: <4270E7F1.9010502@kutulu.org><20050429005319.GA17799@laptoxa.toxa.lan><60093.216.177.243.35.1114761721.localmail@webmail.dnswatch.com> <20050429092734.GC43752@laptoxa.toxa.lan> Date: Fri, 29 Apr 2005 15:50:35 -0700 (PDT) From: "/dev/null" To: "Toxa" 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 cc: freebsd-current@freebsd.org Subject: Re: boot banner project X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 29 Apr 2005 22:50:51 -0000 > On Fri, Apr 29, 2005 at 01:02:01AM -0700, /dev/null wrote: >> "And that's everyone likes in BSD's" >> WOW! Were you elected Official Spokesperson for everyone? ;) > > What's wrong? Do you dislike BSD for it's simpleness and cleareness and > prefer to walk with mouse through thousands of windows configureing MS > Server 2003? ;-)))) Fair enough. Just so you can better appreciate *my* personal preference(s). I have 30+ servers. All of which originally were running some sort of M$ product. It may interest you to know that only *2* of them have M$ on them now. Their days are numbered. ;) Now, I do find that "clicking around" *can* be the most effecient way to accomplish some things. *IF* the path to the destination is the shortest. Unfortunately for M$ products, the newer the product, the *longer* the path - getting things done w/ a mouse in M$ requires taking the scenic route. So, having found that FreeBSD is by far and away the most *effeciently* functioning OS available. I naturally chose it for those servers. The fact that I chose it should say something for character, no? While what I propose for the boot scrn does potentially add some more bits to ones install image. It is *optional* meaning it is not a requirement. Remember, alot of FBSD installs are workstations (a place for computer enthusiasts and the likes) that simply provide a place to hold their digital toys and eye candy - provide some sort of visual stimuli. While this is not "my cup of tea" it is to a large number of ppl. I realize this was a l o n g reply. But I had hopped that we might have a better understanding now and not turn this "opinion" into a *huge* thread. :) -Chris P.S. My favorite place is still at the prompt. > > -- > Anton A. Karpov > > WWW: http://www.toxahost.ru > PGP Key ID: A21386F2 > You can finger toxa@weirdzone.org for my current status > =~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~= > Hi! I am a .signature virus! > Copy me into your ~/.signature to help me spread! > =~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~= > _______________________________________________ > 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 Fri Apr 29 22:57: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 1061816A4CE for ; Fri, 29 Apr 2005 22:57:51 +0000 (GMT) Received: from fast.dnswatch.com (fast.dnswatch.com [216.177.243.43]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6BC6E43D3F for ; Fri, 29 Apr 2005 22:57:50 +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 j3TMvlrt017755; Fri, 29 Apr 2005 15:57:50 -0700 (PDT) (envelope-from null@dnswatch.com) Received: (from www@localhost) by fast.dnswatch.com (8.12.6/8.12.6/Submit) id j3TMvjEd017754; Fri, 29 Apr 2005 15:57:46 -0700 (PDT) (envelope-from null@dnswatch.com) X-Authentication-Warning: fast.dnswatch.com: www set sender to null@dnswatch.com using -f Received: from ns0.1command.com ([216.177.243.38]) (DNSwatch.com_WebMail authenticated user null) by webmail.dnswatch.com with HTTP; Fri, 29 Apr 2005 15:57:44 -0700 (PDT) Message-ID: <1166.216.177.243.38.1114815464.localmail@webmail.dnswatch.com> In-Reply-To: <20050429105416.GA94049@wedge.madpilot.net> References: <57436.216.177.243.42.1114582155.localmail@webmail.dnswatch.com> <6.1.0.6.2.20050426233321.084e9210@cobalt.antimatter.net> <51899.216.177.243.42.1114584317.localmail@webmail.dnswatch.com> <6.1.0.6.2.20050427001118.0327cd50@cobalt.antimatter.net> <52515.216.177.243.42.1114586501.localmail@webmail.dnswatch.com> <61359.216.177.243.35.1114722481.localmail@webmail.dnswatch.com> <20050429105416.GA94049@wedge.madpilot.net> Date: Fri, 29 Apr 2005 15:57:44 -0700 (PDT) From: "/dev/null" To: "Guido Falsi" 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 cc: freebsd-current@freebsd.org Subject: Re: boot banner project X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 29 Apr 2005 22:57:51 -0000 > On Thu, Apr 28, 2005 at 02:08:00PM -0700, /dev/null wrote: >> Hello, >> As this is an RFC (I'm sure you already know that). >> >> Long answer: >> I'm not quite sure. It will depend on the amount and content >> of the comments. Technically, it may not start ever (because >> everyone/ or nearly everyone says it SUX). >> >> Short answer: >> Too early for me to say. > > On this proposal, I think that some graphic banner while booting could > be beautiful to the eye, but quite void in usefullness. I'm not against > it, but can't see any real advantage. Anyway if someone feels like > spending some time on this feature and the results does not bring any > regression to the system I don't see why it should not be offered as an > option. > > On the other hand I think some tidying up in the rc sctripts boot > messages would really REALLY be a good idea. Indeed, this was brought up before and I would be *more* than happy to concentrate my efforts there first (instead?). Maybe I'll start a new RFC for it. Good idea? > I don't mean anything > drastic, just that in 5.x(as was altready pointed out) the output is a > bit messy, and even if I can sort it out uite clearly out of habit, it > would be better if it was a bit more structured and ordered. > > My 2 cents...nothing more, nothing less. > > -- > Guido Falsi > -Chris //////////////////////////////////////////////////// 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 Fri Apr 29 23:07: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 D9E7C16A4CE; Fri, 29 Apr 2005 23:07:15 +0000 (GMT) Received: from vsmtp2.tin.it (vsmtp2alice.tin.it [212.216.176.142]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2616143D1D; Fri, 29 Apr 2005 23:07:15 +0000 (GMT) (envelope-from rionda@gufi.org) Received: from kaiser.sig11.org (82.48.159.55) by vsmtp2.tin.it (7.0.027) id 4272A050000086E3; Sat, 30 Apr 2005 01:07:13 +0200 Received: by kaiser.sig11.org (Postfix, from userid 1000) id 196B56134; Sat, 30 Apr 2005 01:07:13 +0200 (CEST) Date: Sat, 30 Apr 2005 01:07:13 +0200 From: Matteo Riondato To: Scott Long Message-ID: <20050429230713.GA2611@kaiser.sig11.org> Mail-Followup-To: Matteo Riondato , Scott Long , John Sconiers , freebsd-current@freebsd.org, Michael Nottebrock References: <57436.216.177.243.42.1114582155.localmail@webmail.dnswatch.com> <20050429005319.GA17799@laptoxa.toxa.lan> <60093.216.177.243.35.1114761721.localmail@webmail.dnswatch.com> <200504291629.26564.lofi@freebsd.org> <4272910C.5020002@samsco.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="W/nzBZO5zC0uMSeA" Content-Disposition: inline In-Reply-To: <4272910C.5020002@samsco.org> User-Agent: Mutt/1.4.2.1i cc: freebsd-current@freebsd.org cc: John Sconiers cc: Michael Nottebrock Subject: Re: boot banner project X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 29 Apr 2005 23:07:16 -0000 --W/nzBZO5zC0uMSeA Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Apr 29, 2005 at 01:54:52PM -0600, Scott Long wrote: > ask me is whether they can dual boot with it. It is, however, > good at exactly what it was designed for, mainly taking your > existing FreeBSD installation and morphing it into DFly ;-) Or installing FreeSBIE on your hard disk.. =3D) Best Regards --=20 Rionda aka Matteo Riondato Disinformato per default G.U.F.I. Staff Member (http://www.gufi.org) FreeSBIE Developer (http://www.freesbie.org) --W/nzBZO5zC0uMSeA Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFCcr4h2Mp4pR7Fa+wRAtOGAKCoU237Tv0if+sY3PX6zsaGC/5AdACdE6k+ OqPV8RH/JQnVfRzYrr1VV78= =3gNj -----END PGP SIGNATURE----- --W/nzBZO5zC0uMSeA-- From owner-freebsd-current@FreeBSD.ORG Fri Apr 29 23:09: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 A2CDD16A4CE for ; Fri, 29 Apr 2005 23:09:11 +0000 (GMT) Received: from vsmtp2.tin.it (vsmtp2alice.tin.it [212.216.176.142]) by mx1.FreeBSD.org (Postfix) with ESMTP id 58F9943D54 for ; Fri, 29 Apr 2005 23:09:11 +0000 (GMT) (envelope-from rionda@gufi.org) Received: from kaiser.sig11.org (82.48.159.55) by vsmtp2.tin.it (7.0.027) id 4272A050000088BC for freebsd-current@freebsd.org; Sat, 30 Apr 2005 01:09:10 +0200 Received: by kaiser.sig11.org (Postfix, from userid 1000) id 4CAA26134; Sat, 30 Apr 2005 01:09:10 +0200 (CEST) Date: Sat, 30 Apr 2005 01:09:10 +0200 From: Matteo Riondato To: Aymeric MUNTZ Message-ID: <20050429230910.GB2611@kaiser.sig11.org> Mail-Followup-To: Matteo Riondato , Aymeric MUNTZ , freebsd-current@freebsd.org References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="MfFXiAuoTsnnDAfZ" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i cc: freebsd-current@freebsd.org Subject: Re: Iso modification X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 29 Apr 2005 23:09:11 -0000 --MfFXiAuoTsnnDAfZ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Apr 29, 2005 at 11:36:00PM +0200, Aymeric MUNTZ wrote: > Does anyone know how to make a clean modification of the iso? Take a look at FreeSBIE, http://www.freesbie.org=20 Best Regards --=20 Rionda aka Matteo Riondato Disinformato per default G.U.F.I. Staff Member (http://www.gufi.org) FreeSBIE Developer (http://www.freesbie.org) --MfFXiAuoTsnnDAfZ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFCcr6W2Mp4pR7Fa+wRAkTqAJ9quUt6Bm/2UH3svZ6+3O3QEdyX3gCg2F/l vxCRSaVSMn64NEnXnzwdQDw= =FGdC -----END PGP SIGNATURE----- --MfFXiAuoTsnnDAfZ-- From owner-freebsd-current@FreeBSD.ORG Fri Apr 29 23:13: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 DA08E16A4CE; Fri, 29 Apr 2005 23:13:00 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4F8AF43D3F; Fri, 29 Apr 2005 23:13:00 +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.3/8.13.3) with ESMTP id j3TNH0rO033571; Fri, 29 Apr 2005 17:17:00 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <4272BF71.7000307@samsco.org> Date: Fri, 29 Apr 2005 17:12:49 -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: Matteo Riondato References: <57436.216.177.243.42.1114582155.localmail@webmail.dnswatch.com> <20050429005319.GA17799@laptoxa.toxa.lan> <60093.216.177.243.35.1114761721.localmail@webmail.dnswatch.com> <200504291629.26564.lofi@freebsd.org> <4272910C.5020002@samsco.org> <20050429230713.GA2611@kaiser.sig11.org> In-Reply-To: <20050429230713.GA2611@kaiser.sig11.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: freebsd-current@freebsd.org cc: John Sconiers cc: Michael Nottebrock Subject: Re: boot banner project X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 29 Apr 2005 23:13:01 -0000 Matteo Riondato wrote: > On Fri, Apr 29, 2005 at 01:54:52PM -0600, Scott Long wrote: > >>ask me is whether they can dual boot with it. It is, however, >>good at exactly what it was designed for, mainly taking your >>existing FreeBSD installation and morphing it into DFly ;-) > > > Or installing FreeSBIE on your hard disk.. =) > Best Regards Ah yes, I forgot about FreeSBIE. No offense intended =-) Scott From owner-freebsd-current@FreeBSD.ORG Fri Apr 29 23:22: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 7375416A4CE for ; Fri, 29 Apr 2005 23:22:42 +0000 (GMT) Received: from fast.dnswatch.com (fast.dnswatch.com [216.177.243.43]) by mx1.FreeBSD.org (Postfix) with ESMTP id 025DB43D4C for ; Fri, 29 Apr 2005 23:22:42 +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 j3TNMbrt018386; Fri, 29 Apr 2005 16:22:39 -0700 (PDT) (envelope-from null@dnswatch.com) Received: (from www@localhost) by fast.dnswatch.com (8.12.6/8.12.6/Submit) id j3TNMa1O018385; Fri, 29 Apr 2005 16:22:36 -0700 (PDT) (envelope-from null@dnswatch.com) X-Authentication-Warning: fast.dnswatch.com: www set sender to null@dnswatch.com using -f Received: from ns0.1command.com ([216.177.243.38]) (DNSwatch.com_WebMail authenticated user null) by webmail.dnswatch.com with HTTP; Fri, 29 Apr 2005 16:22:35 -0700 (PDT) Message-ID: <1240.216.177.243.38.1114816956.localmail@webmail.dnswatch.com> In-Reply-To: <448y31lpbo.fsf@be-well.ilk.org> References: <63349.216.177.243.42.1114575288.localmail@webmail.dnswatch.com><44is27m6bd.fsf@be-well.ilk.org><54861.216.177.243.35.1114721730.localmail@webmail.dnswatch.com><44zmvi8tl9.fsf@be-well.ilk.org><65221.216.177.243.35.1114728304.localmail@webmail.dnswatch.com> <448y31lpbo.fsf@be-well.ilk.org> Date: Fri, 29 Apr 2005 16:22:35 -0700 (PDT) From: "/dev/null" To: "Lowell Gilbert" 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 cc: freebsd-current@freebsd.org Subject: Re: can't build kernel [with CONFIG this time] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 29 Apr 2005 23:22:42 -0000 Thanks! I'll take your advise. -Chris > "/dev/null" writes: > >> Doesn't "make buildworld" run an rm -r(f) to cleanse any previous >> attempts to build world? > > No, it doesn't. It cleans a lot of objects to avoid the limitations > of not knowing whether you need to rebuild based on a new compiler > (rather than a new source file), but it doesn't do anything that > widespread. > >> or did you mean the message I got suggesting a "rm -fr /usr/obj? > > I think that was /usr/obj/*, but yes. > That message came from the guy who manages the FreeBSD ports system, > and unlike me, he virtually never makes guesses on the mailing lists... > //////////////////////////////////////////////////// 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 Fri Apr 29 23:34: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 0ADF416A4CE for ; Fri, 29 Apr 2005 23:34:23 +0000 (GMT) Received: from smtp-out3.blueyonder.co.uk (smtp-out3.blueyonder.co.uk [195.188.213.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id ABA2C43D54 for ; Fri, 29 Apr 2005 23:34:21 +0000 (GMT) (envelope-from peterj@qubesoft.com) Received: from pete10 ([82.38.181.179]) by smtp-out3.blueyonder.co.uk with Microsoft SMTPSVC(5.0.2195.6713); Sat, 30 Apr 2005 00:35:00 +0100 Message-ID: <045a01c54d13$f7f3baf0$fd64a8c0@pete10> From: "Peter Jeffery" To: "/dev/null" References: <4270E7F1.9010502@kutulu.org><20050429005319.GA17799@laptoxa.toxa.lan><60093.216.177.243.35.1114761721.localmail@webmail.dnswatch.com><20050429092734.GC43752@laptoxa.toxa.lan> <1151.216.177.243.38.1114815035.localmail@webmail.dnswatch.com> Date: Sat, 30 Apr 2005 00:34:20 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2527 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 X-OriginalArrivalTime: 29 Apr 2005 23:35:00.0280 (UTC) FILETIME=[0F63A380:01C54D14] cc: freebsd-current@freebsd.org Subject: Re: boot banner project X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 29 Apr 2005 23:34:23 -0000 ----- Original Message ----- From: "/dev/null" To: "Toxa" Cc: Sent: Friday, April 29, 2005 11:50 PM Subject: Re: boot banner project > Fair enough. Just so you can better appreciate *my* personal > preference(s). > I have 30+ servers. All of which originally were running some sort of > M$ > product. It may interest you to know that only *2* of them have M$ on > them > now. Their days are numbered. ;) Now, I do find that "clicking around" > *can* be the most effecient way to accomplish some things. *IF* the > path > to the destination is the shortest. Unfortunately for M$ products, the > newer the product, the *longer* the path - getting things done w/ a > mouse > in M$ requires taking the scenic route. So, having found that FreeBSD > is > by far and away the most *effeciently* functioning OS available. I > naturally chose it for those servers. The fact that I chose it should > say > something for character, no? While what I propose for the boot scrn > does > potentially add some more bits to ones install image. It is *optional* > meaning it is not a requirement. Remember, alot of FBSD installs are > workstations (a place for computer enthusiasts and the likes) that > simply > provide a place to hold their digital toys and eye candy - provide > some > sort of visual stimuli. While this is not "my cup of tea" it is to a > large > number of ppl. > I realize this was a l o n g reply. But I had hopped that we might > have > a better understanding now and not turn this "opinion" into a *huge* > thread. :) If you have a systems room with a good collection of different OS's this gets me thinking about PR for your OS. Do you not want a way to show off to people that the servers are running FreeBSD, obviously the console screen savers do some of this for you, but if somebody sees a server rebooting and it's just a bunch of text scrolling past until you get to a login prompt, then you get nothing. Even just some ASCII art, indicating that it's 'Powered by FreeBSD' gets you PR for the OS for pretty much nothing. There are a lot of people out there, that might use FreeBSD, that use Linux, because they haven't even heard of FreeBSD and I would imagine that a PC that people see booting into something that is not windows will always be assumed to be Linux too, unless it is clearly stated somewhere during boot. Just a mad midnight thought. > -Chris > > P.S. My favorite place is still at the prompt. > From owner-freebsd-current@FreeBSD.ORG Sat Apr 30 00:13: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 4C8D616A4CE for ; Sat, 30 Apr 2005 00:13:25 +0000 (GMT) Received: from fast.dnswatch.com (fast.dnswatch.com [216.177.243.43]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6D03043D46 for ; Sat, 30 Apr 2005 00:13:24 +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 j3U0DIrt019685; Fri, 29 Apr 2005 17:13:24 -0700 (PDT) (envelope-from null@dnswatch.com) Received: (from www@localhost) by fast.dnswatch.com (8.12.6/8.12.6/Submit) id j3U0DGJY019684; Fri, 29 Apr 2005 17:13:17 -0700 (PDT) (envelope-from null@dnswatch.com) X-Authentication-Warning: fast.dnswatch.com: www set sender to null@dnswatch.com using -f Received: from ns0.1command.com ([216.177.243.38]) (DNSwatch.com_WebMail authenticated user null) by webmail.dnswatch.com with HTTP; Fri, 29 Apr 2005 17:13:16 -0700 (PDT) Message-ID: <1332.216.177.243.38.1114819996.localmail@webmail.dnswatch.com> In-Reply-To: <427291EE.4080809@makeworld.com> References: <57436.216.177.243.42.1114582155.localmail@webmail.dnswatch.com> <6.1.0.6.2.20050426233321.084e9210@cobalt.antimatter.net> <51899.216.177.243.42.1114584317.localmail@webmail.dnswatch.com> <6.1.0.6.2.20050427001118.0327cd50@cobalt.antimatter.net> <52515.216.177.243.42.1114586501.localmail@webmail.dnswatch.com> <61359.216.177.243.35.1114722481.localmail@webmail.dnswatch.com> <20050429105416.GA94049@wedge.madpilot.net> <42728DF1.9040908@makeworld.com> <427291EE.4080809@makeworld.com> Date: Fri, 29 Apr 2005 17:13:16 -0700 (PDT) From: "/dev/null" To: racerx@makeworld.com 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 cc: freebsd-current@freebsd.org Subject: Re: boot banner project X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 30 Apr 2005 00:13:25 -0000 First, I'd like to say; It's great to see so much passion regarding an OS. It reminds me of the olden days when Mac vs. PeeCee camps were so prevelent. ... > John Sconiers wrote: > >> On 4/29/05, Chris wrote: >> >>>John Sconiers wrote: >>>... >>> >>>>Adding less then a meg here or there is not bloat. Unless of course >>>> the goal is to >>>>create an advanced operating system unable to get / keep users. >>>> >>>>My $.02 >>> >>>The problem is this; if everyone keeps adding "less then a meg here or >>>there" then you DO end up with bloat. >>> >>>Where to you draw the line? How much is too much? To me, I would rather >>>add that less then a meg here and there to the core OS ... Not to >>>something that (to me) does not need to look perdy. >>> >>>... and my .02 >>> >>>-- >>>Best regards, >>>Chris >>> >>>If reproducibility may be a problem conduct the >>>test only once. >>> > > John Sconiers wrote: >> Do you want to get / keep new users, compete wth other operating >> systems, etc.... >> > > Of course - but NOT at the expense for the OS itself. The banner is only > seen once. It does not have to be perdy to attract users. > > If that's the case, if it needs to be perdy to attract users - then > (speaking for myself) do you want that flavor of user? Is this bigotry, or racism? I can never remember which one means which. Anyway, WTFAY to decide whom is allowed to use FBSD anyway?! > > Are you not at that point trying to emulate a Windows-ee look? As I > said, I care more about the quality of the OS. You know, when you live at the console as long as I do every day. A little "eye candy" can go a l o n g way. -Chris (H.) > > > -- > Best regards, > Chris > > The spot you are scrubbing on glassware is always on > the other side. > //////////////////////////////////////////////////// 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 30 00:32: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 1474516A4CE for ; Sat, 30 Apr 2005 00:32:11 +0000 (GMT) Received: from fast.dnswatch.com (fast.dnswatch.com [216.177.243.43]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7386843D1F for ; Sat, 30 Apr 2005 00:32:10 +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 j3U0Vqrt020065; Fri, 29 Apr 2005 17:31:54 -0700 (PDT) (envelope-from null@dnswatch.com) Received: (from www@localhost) by fast.dnswatch.com (8.12.6/8.12.6/Submit) id j3U0VopH020064; Fri, 29 Apr 2005 17:31:51 -0700 (PDT) (envelope-from null@dnswatch.com) X-Authentication-Warning: fast.dnswatch.com: www set sender to null@dnswatch.com using -f Received: from ns0.1command.com ([216.177.243.38]) (DNSwatch.com_WebMail authenticated user null) by webmail.dnswatch.com with HTTP; Fri, 29 Apr 2005 17:31:49 -0700 (PDT) Message-ID: <1359.216.177.243.38.1114821110.localmail@webmail.dnswatch.com> In-Reply-To: <42729FBF.8010800@cordula.ws> References: <57436.216.177.243.42.1114582155.localmail@webmail.dnswatch.com> <6.1.0.6.2.20050426233321.084e9210@cobalt.antimatter.net> <51899.216.177.243.42.1114584317.localmail@webmail.dnswatch.com> <6.1.0.6.2.20050427001118.0327cd50@cobalt.antimatter.net> <52515.216.177.243.42.1114586501.localmail@webmail.dnswatch.com> <61359.216.177.243.35.1114722481.localmail@webmail.dnswatch.com> <20050429105416.GA94049@wedge.madpilot.net> <42729FBF.8010800@cordula.ws> Date: Fri, 29 Apr 2005 17:31:49 -0700 (PDT) From: "/dev/null" To: "cpghost" 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 cc: freebsd-current@freebsd.org Subject: Re: boot banner project X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 30 Apr 2005 00:32:11 -0000 FWIW, the project *intends* to make itself an *option*, not something that that needs to be disabled - which I think would be irresponsible in this case. -Chris H. > John Sconiers wrote: > >>Adding less then a meg here or there is not bloat. >> > It is a mistake to assume that memory is cheap and always easily > available and/or upgradable. There are quite a lot of embedded > systems out there, that run FreeBSD out-of-the-box, without the > need to tweak or manually remove all that unnecessary eye candy. > Such systems come with RAM soldered on-board, so they are > impossible to upgrade. > > If you really want a GUIfied installer (and please remember that > some hardware like Soekris boxes don't even have VGA circuitery!), > then please only as a port (that would create a custom boot image), > or as an optional add-on. The default install should still be possible > over serial line and on striped down hardware. > > The same holds true for boot banners: not every hardware out there > has hires graphics capabilities. > > Regards, > -cpghost. > > -- > Cordula's Web. http://www.cordula.ws/ > > //////////////////////////////////////////////////// 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 30 00:37: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 93CAE16A4CF for ; Sat, 30 Apr 2005 00:37:02 +0000 (GMT) Received: from makeworld.com (makeworld.com [216.201.118.142]) by mx1.FreeBSD.org (Postfix) with ESMTP id BBB2243D31 for ; Sat, 30 Apr 2005 00:37:01 +0000 (GMT) (envelope-from racerx@makeworld.com) Received: from localhost (localhost.com [127.0.0.1]) by makeworld.com (Postfix) with ESMTP id F311D60E3; Fri, 29 Apr 2005 19:37:00 -0500 (CDT) Received: from makeworld.com ([127.0.0.1]) by localhost (makeworld.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 49111-04; Fri, 29 Apr 2005 19:36:56 -0500 (CDT) Received: from [216.201.118.138] (racerx.makeworld.com [216.201.118.138]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by makeworld.com (Postfix) with ESMTP id 5B87960D4; Fri, 29 Apr 2005 19:36:52 -0500 (CDT) Message-ID: <4272D324.7030302@makeworld.com> Date: Fri, 29 Apr 2005 19:36:52 -0500 From: Chris User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050414) X-Accept-Language: en-us, en MIME-Version: 1.0 To: /dev/null References: <57436.216.177.243.42.1114582155.localmail@webmail.dnswatch.com> <6.1.0.6.2.20050426233321.084e9210@cobalt.antimatter.net> <51899.216.177.243.42.1114584317.localmail@webmail.dnswatch.com> <6.1.0.6.2.20050427001118.0327cd50@cobalt.antimatter.net> <52515.216.177.243.42.1114586501.localmail@webmail.dnswatch.com> <61359.216.177.243.35.1114722481.localmail@webmail.dnswatch.com> <20050429105416.GA94049@wedge.madpilot.net> <42728DF1.9040908@makeworld.com> <427291EE.4080809@makeworld.com> <1332.216.177.243.38.1114819996.localmail@webmail.dnswatch.com> In-Reply-To: <1332.216.177.243.38.1114819996.localmail@webmail.dnswatch.com> X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by ClamAV 0.75.1/amavisd-new-2.2.1 (20041222) at makeworld.com - Isn't it ironic cc: freebsd-current@freebsd.org Subject: Re: boot banner project X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: racerx@makeworld.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Apr 2005 00:37:02 -0000 /dev/null wrote: > First, I'd like to say; It's great to see so much passion regarding an OS. > It reminds me of the olden days when Mac vs. PeeCee camps were so > prevelent. > ... Yes. It's presenting ideas, reasons, suggestions. Thus far tho - I have gotten far worse replies via email then what has made it here on the list. Sorta reminds me of the NetBSD "discussion" on the new *cough* mascot *cough* >>John Sconiers wrote: >> >> >>>On 4/29/05, Chris wrote: >>> >>> >>>>John Sconiers wrote: >>>>... >>>> >>>> >>>>>Adding less then a meg here or there is not bloat. Unless of course >>>>>the goal is to >>>>>create an advanced operating system unable to get / keep users. >>>>> >>>>>My $.02 >>>> >>>>The problem is this; if everyone keeps adding "less then a meg here or >>>>there" then you DO end up with bloat. >>>> >>>>Where to you draw the line? How much is too much? To me, I would rather >>>>add that less then a meg here and there to the core OS ... Not to >>>>something that (to me) does not need to look perdy. >>>> >>>>... and my .02 >>>> >>>>-- >>>>Best regards, >>>>Chris >>>> >>>>If reproducibility may be a problem conduct the >>>>test only once. >>>> >> >>John Sconiers wrote: >> >>>Do you want to get / keep new users, compete wth other operating >>>systems, etc.... >>> >> >>Of course - but NOT at the expense for the OS itself. The banner is only >>seen once. It does not have to be perdy to attract users. >> >>If that's the case, if it needs to be perdy to attract users - then >>(speaking for myself) do you want that flavor of user? > > > > Is this bigotry, or racism? I can never remember which one means which. > Anyway, WTFAY to decide whom is allowed to use FBSD anyway?! I'm not - Read betwix the () - "Speaking for myself". That means, it's my opinion. People seem to miss that point. Either that or they read what they want it to say. *Shrug* > >>Are you not at that point trying to emulate a Windows-ee look? As I >>said, I care more about the quality of the OS. > > > You know, when you live at the console as long as I do every day. A little > "eye candy" can go a l o n g way. > > -Chris (H.) As long as it's not needed bloat. I rather like what one user stated. Make it an option, or a port. To me, (read that again, to me) I would prefer a choice. -- Best regards, Chris In case of doubt, make it sound convincing. From owner-freebsd-current@FreeBSD.ORG Sat Apr 30 00:37: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 0419216A4CE for ; Sat, 30 Apr 2005 00:37:03 +0000 (GMT) Received: from fast.dnswatch.com (fast.dnswatch.com [216.177.243.43]) by mx1.FreeBSD.org (Postfix) with ESMTP id 88A6243D48 for ; Sat, 30 Apr 2005 00:37:02 +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 j3U0aurt020209; Fri, 29 Apr 2005 17:36:58 -0700 (PDT) (envelope-from null@dnswatch.com) Received: (from www@localhost) by fast.dnswatch.com (8.12.6/8.12.6/Submit) id j3U0auZG020208; Fri, 29 Apr 2005 17:36:56 -0700 (PDT) (envelope-from null@dnswatch.com) X-Authentication-Warning: fast.dnswatch.com: www set sender to null@dnswatch.com using -f Received: from ns0.1command.com ([216.177.243.38]) (DNSwatch.com_WebMail authenticated user null) by webmail.dnswatch.com with HTTP; Fri, 29 Apr 2005 17:36:55 -0700 (PDT) Message-ID: <1366.216.177.243.38.1114821415.localmail@webmail.dnswatch.com> In-Reply-To: <200504292121.j3TLLG4W010628@realtime.exit.com> References: <200504292121.j3TLLG4W010628@realtime.exit.com> Date: Fri, 29 Apr 2005 17:36:55 -0700 (PDT) From: "/dev/null" To: frank@exit.com 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 cc: freebsd-current@freebsd.org Subject: Re: boot banner project X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 30 Apr 2005 00:37:03 -0000 > You know, all this chatter is moot without code. Those of you who feel > so strongly about this, go and write your interface. Then let the best > one take over the world. > > Until then, you're just debating the color of a bikeshed that you'll > never get around to actually building. (Which is why I haven't taken > part, This would be the second time you haven't "taken part". If memory serves me correctly. -Chris H. > that and I really couldn't care less about this particular subject; the > current installation interface is just fine as far as I'm concerned.) > -- > Frank Mayhar frank@exit.com http://www.exit.com/ > Exit Consulting http://www.gpsclock.com/ > http://www.exit.com/blog/frank/ > //////////////////////////////////////////////////// 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 30 01:07: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 081A416A4CE for ; Sat, 30 Apr 2005 01:07:17 +0000 (GMT) Received: from fast.dnswatch.com (fast.dnswatch.com [216.177.243.43]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6E2E743D55 for ; Sat, 30 Apr 2005 01:07:16 +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 j3U178rt020718; Fri, 29 Apr 2005 18:07:16 -0700 (PDT) (envelope-from null@dnswatch.com) Received: (from www@localhost) by fast.dnswatch.com (8.12.6/8.12.6/Submit) id j3U177uZ020717; Fri, 29 Apr 2005 18:07:07 -0700 (PDT) (envelope-from null@dnswatch.com) X-Authentication-Warning: fast.dnswatch.com: www set sender to null@dnswatch.com using -f Received: from ns0.1command.com ([216.177.243.38]) (DNSwatch.com_WebMail authenticated user null) by webmail.dnswatch.com with HTTP; Fri, 29 Apr 2005 18:07:06 -0700 (PDT) Message-ID: <1441.216.177.243.38.1114823226.localmail@webmail.dnswatch.com> In-Reply-To: <045a01c54d13$f7f3baf0$fd64a8c0@pete10> References: <4270E7F1.9010502@kutulu.org><20050429005319.GA17799@laptoxa.toxa.lan><60093.216.177.243.35.1114761721.localmail@webmail.dnswatch.com><20050429092734.GC43752@laptoxa.toxa.lan> <1151.216.177.243.38.1114815035.localmail@webmail.dnswatch.com> <045a01c54d13$f7f3baf0$fd64a8c0@pete10> Date: Fri, 29 Apr 2005 18:07:06 -0700 (PDT) From: "/dev/null" To: "Peter Jeffery" 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 cc: freebsd-current@freebsd.org Subject: Re: boot banner project X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 30 Apr 2005 01:07:17 -0000 > > ----- Original Message ----- > From: "/dev/null" > To: "Toxa" > Cc: > Sent: Friday, April 29, 2005 11:50 PM > Subject: Re: boot banner project > >> Fair enough. Just so you can better appreciate *my* personal >> preference(s). >> I have 30+ servers. All of which originally were running some sort of >> M$ >> product. It may interest you to know that only *2* of them have M$ on >> them >> now. Their days are numbered. ;) Now, I do find that "clicking around" >> *can* be the most effecient way to accomplish some things. *IF* the >> path >> to the destination is the shortest. Unfortunately for M$ products, the >> newer the product, the *longer* the path - getting things done w/ a >> mouse >> in M$ requires taking the scenic route. So, having found that FreeBSD >> is >> by far and away the most *effeciently* functioning OS available. I >> naturally chose it for those servers. The fact that I chose it should >> say >> something for character, no? While what I propose for the boot scrn >> does >> potentially add some more bits to ones install image. It is *optional* >> meaning it is not a requirement. Remember, alot of FBSD installs are >> workstations (a place for computer enthusiasts and the likes) that >> simply >> provide a place to hold their digital toys and eye candy - provide >> some >> sort of visual stimuli. While this is not "my cup of tea" it is to a >> large >> number of ppl. >> I realize this was a l o n g reply. But I had hopped that we might >> have >> a better understanding now and not turn this "opinion" into a *huge* >> thread. :) > > If you have a systems room with a good collection of different OS's this > gets me thinking about PR for your OS. Do you not want a way to show off > to people that the servers are running FreeBSD, obviously the console > screen savers do some of this for you, but if somebody sees a server > rebooting and it's just a bunch of text scrolling past until you get to > a login prompt, then you get nothing. > > Even just some ASCII art, indicating that it's 'Powered by FreeBSD' gets > you PR for the OS for pretty much nothing. There are a lot of people out > there, that might use FreeBSD, that use Linux, because they haven't even > heard of FreeBSD and I would imagine that a PC that people see booting > into something that is not windows will always be assumed to be Linux > too, unless it is clearly stated somewhere during boot. Or put perhaps another way - There is *nothing hotter* than a beautiful empty headed blond. Or, nothing will get someones attention than a beautiful empty headed blond. Except perhaps a green eyed red head. ;) > > > Just a mad midnight thought. > >> -Chris >> >> P.S. My favorite place is still at the prompt. >> > > -Chris H. P.S. This was not to insinuate FBSD was a useless OS, but rather, that looks are everything (at first). //////////////////////////////////////////////////// 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 30 02:18: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 3F47D16A4CE; Sat, 30 Apr 2005 02:18:07 +0000 (GMT) Received: from carver.gumbysoft.com (carver.gumbysoft.com [66.220.23.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 145D843D3F; Sat, 30 Apr 2005 02:18:07 +0000 (GMT) (envelope-from dwhite@gumbysoft.com) Received: by carver.gumbysoft.com (Postfix, from userid 1000) id 05D0472DEB; Fri, 29 Apr 2005 19:18:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by carver.gumbysoft.com (Postfix) with ESMTP id 000DA72DEA; Fri, 29 Apr 2005 19:18:06 -0700 (PDT) Date: Fri, 29 Apr 2005 19:18:06 -0700 (PDT) From: Doug White To: Brian Candler In-Reply-To: <20050428102936.GA89935@uk.tiscali.com> Message-ID: <20050429190711.P85282@carver.gumbysoft.com> References: <20050428053528.G59099@lexi.siliconlandmark.com> <20050428102936.GA89935@uk.tiscali.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-hackers@freebsd.org cc: freebsd-current@freebsd.org Subject: Re: how to set dumpdev X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 30 Apr 2005 02:18:09 -0000 On Thu, 28 Apr 2005, Brian Candler wrote: > On Thu, Apr 28, 2005 at 05:37:16AM -0400, Andre Guibert de Bruet wrote: > > > i can't use dumpon, since the kernel is panicking on boot, so > > >tried in loader.conf: > > > dumpdev="/dev/ar0s1b" > > >but getting: > > >db> call doadump > > >Cannot dump. No dump device defined. > > >0x25 > > > > > >i need this is for current 6.0 > > >thanks, > > > danny > > > > > > > That directive, along with dumpdir, would be set in /etc/rc.conf. > > According to `man dumpon` (on a 5-STABLE system): > > Since dumpon cannot be used during kernel initialization, the dumpdev > variable of loader(8) must be used to enable dumps for system panics > which occur during kernel initialization. > > But I don't find 'dumpdev' referenced anywhere under /usr/src/sys/boot/. Is > the documentation wrong? It wouldn't be there, but it alos loks like that tunable has gone away when GEOM took over definign the dump device. Now it needs a struct to specify the target, and you wouldn't be able to set it until way late in the boot anyway (when GEOM attaches the disks). -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Sat Apr 30 02:26: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 5605916A4CE for ; Sat, 30 Apr 2005 02:26:51 +0000 (GMT) Received: from fw.farid-hajji.net (fw.farid-hajji.net [213.146.115.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id BB13C43D3F for ; Sat, 30 Apr 2005 02:26:50 +0000 (GMT) (envelope-from cpghost@cordula.ws) Received: from epia2.farid-hajji.net (epia-2 [192.168.254.11]) by fw.farid-hajji.net (Postfix) with ESMTP id 3FEAB4BCF0; Sat, 30 Apr 2005 04:24:14 +0200 (CEST) Date: Sat, 30 Apr 2005 04:28:33 +0200 From: cpghost@cordula.ws To: /dev/null Message-ID: <20050430022833.GA54886@epia2.farid-hajji.net> References: <6.1.0.6.2.20050426233321.084e9210@cobalt.antimatter.net> <51899.216.177.243.42.1114584317.localmail@webmail.dnswatch.com> <6.1.0.6.2.20050427001118.0327cd50@cobalt.antimatter.net> <52515.216.177.243.42.1114586501.localmail@webmail.dnswatch.com> <61359.216.177.243.35.1114722481.localmail@webmail.dnswatch.com> <20050429105416.GA94049@wedge.madpilot.net> <42729FBF.8010800@cordula.ws> <1359.216.177.243.38.1114821110.localmail@webmail.dnswatch.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1359.216.177.243.38.1114821110.localmail@webmail.dnswatch.com> User-Agent: Mutt/1.5.9i cc: freebsd-current@freebsd.org Subject: Re: boot banner project X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 30 Apr 2005 02:26:51 -0000 On Fri, Apr 29, 2005 at 05:31:49PM -0700, /dev/null wrote: > > The same holds true for boot banners: not every hardware out there > > has hires graphics capabilities. > FWIW, the project *intends* to make itself an *option*, not something that > that needs to be disabled - which I think would be irresponsible in this > case. Please don't top post. Yes, there's nothing wrong with that. As long as the default still installs over PXE, serial etc... (think rack mounted U1/U2 headless servers as yet another typical platform that a lot of us manage by the hundreds). However, there's no reason why this should be part of the official source tree. Use a port for optional kernel or bootloader stuff. IMHO, the easiest way to achieve this, would be to write a port that creates a custom ISO, with that (hypothetical) bells and whistles GUI installer/boot prompt and a custom kernel with your extension. Something like sysutils/freesbie port... sysutils/eyecandy perhaps? ;) Happy hacking. Cheers, -cpghost. -- Cordula's Web. http://www.cordula.ws/ From owner-freebsd-current@FreeBSD.ORG Sat Apr 30 06:37: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 8F5F116A4CE; Sat, 30 Apr 2005 06:37:35 +0000 (GMT) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2F2A643D46; Sat, 30 Apr 2005 06:37:35 +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 j3U6bYll039302; Sat, 30 Apr 2005 02:37:34 -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 j3U6bYo3030359; Sat, 30 Apr 2005 02:37:34 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 757327306E; Sat, 30 Apr 2005 02:37:34 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050430063734.757327306E@freebsd-current.sentex.ca> Date: Sat, 30 Apr 2005 02:37:34 -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 alpha/alpha 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, 30 Apr 2005 06:37:35 -0000 TB --- 2005-04-30 06:30:00 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-04-30 06:30:00 - starting CURRENT tinderbox run for alpha/alpha TB --- 2005-04-30 06:30:00 - checking out the source tree TB --- 2005-04-30 06:30:00 - cd /home/tinderbox/CURRENT/alpha/alpha TB --- 2005-04-30 06:30:00 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-04-30 06:36:27 - building world (CFLAGS=-O2 -pipe) TB --- 2005-04-30 06:36:27 - cd /home/tinderbox/CURRENT/alpha/alpha/src TB --- 2005-04-30 06:36:27 - /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 [...] rm -f init init.o init.8.gz init.8.cat.gz rm -f .depend GPATH GRTAGS GSYMS GTAGS ===> sbin/ip6fw (cleandir) rm -f ip6fw ip6fw.o ip6fw.8.gz ip6fw.8.cat.gz rm -f .depend GPATH GRTAGS GSYMS GTAGS ===> sbin/ipf (cleandir) ".depend", line 275: Inconsistent operator for ipf make: fatal errors encountered -- cannot continue *** Error code 1 Stop in /tinderbox/CURRENT/alpha/alpha/src/sbin. *** Error code 1 Stop in /tinderbox/CURRENT/alpha/alpha/src. *** Error code 1 Stop in /tinderbox/CURRENT/alpha/alpha/src. *** Error code 1 Stop in /tinderbox/CURRENT/alpha/alpha/src. TB --- 2005-04-30 06:37:34 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-04-30 06:37:34 - ERROR: failed to build world TB --- 2005-04-30 06:37:34 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Sat Apr 30 06:40: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 67F3C16A4CE; Sat, 30 Apr 2005 06:40:26 +0000 (GMT) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 086E543D45; Sat, 30 Apr 2005 06:40:26 +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 j3U6eP1M025196; Sat, 30 Apr 2005 02:40:25 -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 j3U6ePkj031264; Sat, 30 Apr 2005 02:40:25 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 7E2D47306E; Sat, 30 Apr 2005 02:40:25 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050430064025.7E2D47306E@freebsd-current.sentex.ca> Date: Sat, 30 Apr 2005 02:40:25 -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 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: Sat, 30 Apr 2005 06:40:26 -0000 TB --- 2005-04-30 06:37:34 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-04-30 06:37:34 - starting CURRENT tinderbox run for amd64/amd64 TB --- 2005-04-30 06:37:34 - checking out the source tree TB --- 2005-04-30 06:37:34 - cd /home/tinderbox/CURRENT/amd64/amd64 TB --- 2005-04-30 06:37:34 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-04-30 06:39:18 - building world (CFLAGS=-O2 -pipe) TB --- 2005-04-30 06:39:18 - cd /home/tinderbox/CURRENT/amd64/amd64/src TB --- 2005-04-30 06:39:18 - /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 [...] rm -f init init.o init.8.gz init.8.cat.gz rm -f .depend GPATH GRTAGS GSYMS GTAGS ===> sbin/ip6fw (cleandir) rm -f ip6fw ip6fw.o ip6fw.8.gz ip6fw.8.cat.gz rm -f .depend GPATH GRTAGS GSYMS GTAGS ===> sbin/ipf (cleandir) ".depend", line 269: Inconsistent operator for ipf make: fatal errors encountered -- cannot continue *** Error code 1 Stop in /tinderbox/CURRENT/amd64/amd64/src/sbin. *** 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-30 06:40:25 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-04-30 06:40:25 - ERROR: failed to build world TB --- 2005-04-30 06:40:25 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Sat Apr 30 06:47: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 3AA2816A4CE; Sat, 30 Apr 2005 06:47:59 +0000 (GMT) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 919F143D39; Sat, 30 Apr 2005 06:47:57 +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 j3U6lvc4025299; Sat, 30 Apr 2005 02:47:57 -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 j3U6lv2Z033244; Sat, 30 Apr 2005 02:47:57 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 1FAE47306E; Sat, 30 Apr 2005 02:47:57 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050430064757.1FAE47306E@freebsd-current.sentex.ca> Date: Sat, 30 Apr 2005 02:47:57 -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: Sat, 30 Apr 2005 06:47:59 -0000 TB --- 2005-04-30 06:40:25 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-04-30 06:40:25 - starting CURRENT tinderbox run for i386/i386 TB --- 2005-04-30 06:40:25 - checking out the source tree TB --- 2005-04-30 06:40:25 - cd /home/tinderbox/CURRENT/i386/i386 TB --- 2005-04-30 06:40:25 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-04-30 06:46:49 - building world (CFLAGS=-O2 -pipe) TB --- 2005-04-30 06:46:49 - cd /home/tinderbox/CURRENT/i386/i386/src TB --- 2005-04-30 06:46:49 - /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 [...] rm -f init init.o init.8.gz init.8.cat.gz rm -f .depend GPATH GRTAGS GSYMS GTAGS ===> sbin/ip6fw (cleandir) rm -f ip6fw ip6fw.o ip6fw.8.gz ip6fw.8.cat.gz rm -f .depend GPATH GRTAGS GSYMS GTAGS ===> sbin/ipf (cleandir) ".depend", line 269: Inconsistent operator for ipf make: fatal errors encountered -- cannot continue *** Error code 1 Stop in /tinderbox/CURRENT/i386/i386/src/sbin. *** 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-30 06:47:57 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-04-30 06:47:57 - ERROR: failed to build world TB --- 2005-04-30 06:47:57 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Sat Apr 30 06:55: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 D7B1C16A4CE; Sat, 30 Apr 2005 06:55:51 +0000 (GMT) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7AF9F43D46; Sat, 30 Apr 2005 06:55:51 +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 j3U6toOq039595; Sat, 30 Apr 2005 02:55:50 -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 j3U6tplV035366; Sat, 30 Apr 2005 02:55:51 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id D70AF7306E; Sat, 30 Apr 2005 02:55:50 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050430065550.D70AF7306E@freebsd-current.sentex.ca> Date: Sat, 30 Apr 2005 02:55:50 -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/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, 30 Apr 2005 06:55:52 -0000 TB --- 2005-04-30 06:47:57 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-04-30 06:47:57 - starting CURRENT tinderbox run for i386/pc98 TB --- 2005-04-30 06:47:57 - checking out the source tree TB --- 2005-04-30 06:47:57 - cd /home/tinderbox/CURRENT/i386/pc98 TB --- 2005-04-30 06:47:57 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-04-30 06:54:42 - building world (CFLAGS=-O2 -pipe) TB --- 2005-04-30 06:54:42 - cd /home/tinderbox/CURRENT/i386/pc98/src TB --- 2005-04-30 06:54:42 - /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 [...] rm -f init init.o init.8.gz init.8.cat.gz rm -f .depend GPATH GRTAGS GSYMS GTAGS ===> sbin/ip6fw (cleandir) rm -f ip6fw ip6fw.o ip6fw.8.gz ip6fw.8.cat.gz rm -f .depend GPATH GRTAGS GSYMS GTAGS ===> sbin/ipf (cleandir) ".depend", line 299: Inconsistent operator for ipf make: fatal errors encountered -- cannot continue *** Error code 1 Stop in /tinderbox/CURRENT/i386/pc98/src/sbin. *** 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-30 06:55:50 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-04-30 06:55:50 - ERROR: failed to build world TB --- 2005-04-30 06:55:50 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Sat Apr 30 07:00: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 70E1016A4CF; Sat, 30 Apr 2005 07:00:56 +0000 (GMT) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id F125443D1F; Sat, 30 Apr 2005 07:00:55 +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 j3U70tsi025464; Sat, 30 Apr 2005 03:00:55 -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 j3U70t0i023296; Sat, 30 Apr 2005 03:00:55 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 6C6277306E; Sat, 30 Apr 2005 03:00:55 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050430070055.6C6277306E@freebsd-current.sentex.ca> Date: Sat, 30 Apr 2005 03:00:55 -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: Sat, 30 Apr 2005 07:00:56 -0000 TB --- 2005-04-30 06:55:51 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-04-30 06:55:51 - starting CURRENT tinderbox run for ia64/ia64 TB --- 2005-04-30 06:55:51 - checking out the source tree TB --- 2005-04-30 06:55:51 - cd /home/tinderbox/CURRENT/ia64/ia64 TB --- 2005-04-30 06:55:51 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-04-30 06:59:48 - building world (CFLAGS=-O2 -pipe) TB --- 2005-04-30 06:59:48 - cd /home/tinderbox/CURRENT/ia64/ia64/src TB --- 2005-04-30 06:59:48 - /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 [...] rm -f init init.o init.8.gz init.8.cat.gz rm -f .depend GPATH GRTAGS GSYMS GTAGS ===> sbin/ip6fw (cleandir) rm -f ip6fw ip6fw.o ip6fw.8.gz ip6fw.8.cat.gz rm -f .depend GPATH GRTAGS GSYMS GTAGS ===> sbin/ipf (cleandir) ".depend", line 269: Inconsistent operator for ipf make: fatal errors encountered -- cannot continue *** Error code 1 Stop in /tinderbox/CURRENT/ia64/ia64/src/sbin. *** Error code 1 Stop in /tinderbox/CURRENT/ia64/ia64/src. *** Error code 1 Stop in /tinderbox/CURRENT/ia64/ia64/src. *** Error code 1 Stop in /tinderbox/CURRENT/ia64/ia64/src. TB --- 2005-04-30 07:00:55 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-04-30 07:00:55 - ERROR: failed to build world TB --- 2005-04-30 07:00:55 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Sat Apr 30 07:11: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 4AB6616A4CE; Sat, 30 Apr 2005 07:11:46 +0000 (GMT) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id DC89743D2F; Sat, 30 Apr 2005 07:11:45 +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 j3U7BjnS040135; Sat, 30 Apr 2005 03:11:45 -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 j3U7BjQp040004; Sat, 30 Apr 2005 03:11:45 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 065197306E; Sat, 30 Apr 2005 03:11:45 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050430071145.065197306E@freebsd-current.sentex.ca> Date: Sat, 30 Apr 2005 03:11: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 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: Sat, 30 Apr 2005 07:11:46 -0000 TB --- 2005-04-30 07:00:55 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-04-30 07:00:55 - starting CURRENT tinderbox run for powerpc/powerpc TB --- 2005-04-30 07:00:55 - checking out the source tree TB --- 2005-04-30 07:00:55 - cd /home/tinderbox/CURRENT/powerpc/powerpc TB --- 2005-04-30 07:00:55 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-04-30 07:10:08 - building world (CFLAGS=-O2 -pipe) TB --- 2005-04-30 07:10:08 - cd /home/tinderbox/CURRENT/powerpc/powerpc/src TB --- 2005-04-30 07:10:08 - /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 [...] rm -f init init.o init.8.gz init.8.cat.gz rm -f .depend GPATH GRTAGS GSYMS GTAGS ===> sbin/ip6fw (cleandir) rm -f ip6fw ip6fw.o ip6fw.8.gz ip6fw.8.cat.gz rm -f .depend GPATH GRTAGS GSYMS GTAGS ===> sbin/ipf (cleandir) ".depend", line 272: Inconsistent operator for ipf make: fatal errors encountered -- cannot continue *** Error code 1 Stop in /tinderbox/CURRENT/powerpc/powerpc/src/sbin. *** Error code 1 Stop in /tinderbox/CURRENT/powerpc/powerpc/src. *** Error code 1 Stop in /tinderbox/CURRENT/powerpc/powerpc/src. *** Error code 1 Stop in /tinderbox/CURRENT/powerpc/powerpc/src. TB --- 2005-04-30 07:11:44 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-04-30 07:11:44 - ERROR: failed to build world TB --- 2005-04-30 07:11:44 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Sat Apr 30 07:29: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 4AADF16A4CE; Sat, 30 Apr 2005 07:29:34 +0000 (GMT) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id B79A243D39; Sat, 30 Apr 2005 07:29:33 +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 j3U7TXFY026151; Sat, 30 Apr 2005 03:29: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 j3U7TXcj044417; Sat, 30 Apr 2005 03:29:33 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id B29567306E; Sat, 30 Apr 2005 03:29:32 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050430072932.B29567306E@freebsd-current.sentex.ca> Date: Sat, 30 Apr 2005 03:29:32 -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 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, 30 Apr 2005 07:29:34 -0000 TB --- 2005-04-30 07:11:45 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-04-30 07:11:45 - starting CURRENT tinderbox run for sparc64/sparc64 TB --- 2005-04-30 07:11:45 - checking out the source tree TB --- 2005-04-30 07:11:45 - cd /home/tinderbox/CURRENT/sparc64/sparc64 TB --- 2005-04-30 07:11:45 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-04-30 07:27:50 - building world (CFLAGS=-O2 -pipe) TB --- 2005-04-30 07:27:50 - cd /home/tinderbox/CURRENT/sparc64/sparc64/src TB --- 2005-04-30 07:27: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 [...] rm -f init init.o init.8.gz init.8.cat.gz rm -f .depend GPATH GRTAGS GSYMS GTAGS ===> sbin/ip6fw (cleandir) rm -f ip6fw ip6fw.o ip6fw.8.gz ip6fw.8.cat.gz rm -f .depend GPATH GRTAGS GSYMS GTAGS ===> sbin/ipf (cleandir) ".depend", line 275: Inconsistent operator for ipf make: fatal errors encountered -- cannot continue *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/src/sbin. *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/src. *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/src. *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/src. TB --- 2005-04-30 07:29:32 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-04-30 07:29:32 - ERROR: failed to build world TB --- 2005-04-30 07:29:32 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Sat Apr 30 08:40: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 3DDA816A4CE for ; Sat, 30 Apr 2005 08:40:57 +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 751B843D54 for ; Sat, 30 Apr 2005 08:40:56 +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 j3U8dD3x045784; Sat, 30 Apr 2005 10:39:13 +0200 (CEST) (envelope-from sos@DeepCore.dk) Message-ID: <4273441E.5000609@DeepCore.dk> Date: Sat, 30 Apr 2005 10:38:54 +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: jondoor@udor.net References: <4272AFC6.2040907@udor.net> In-Reply-To: <4272AFC6.2040907@udor.net> 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: ATA RAID -- Promise SATA150 vanished /dev/ar0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 30 Apr 2005 08:40:57 -0000 Jon Door wrote: > I have a Promise Fastrak SATA RAID controller (PDC20371). Running a >=20 > stripe between two 120GB drives. Running under a generic RELENG_5 the=20 > controller, its drives, and the stripe where all detect without problem= =2E=20 > /dev/ar0 was generated without any special changes. Today I upgraded to= =20 > 6.0-CURRENT. Now the Promise controller and its drives are recognized=20 > but no /dev/ar0, and no evidence of the stripe. Booting back to a=20 > RELENG_5 system show the stripe data to still be intact. I've beem read= ing > through all the ATA mkIII posts and haven't seen this specific issue, a= m=20 > I missing a step here or is this possibly an issue between the new ATA = > code and my RAID card? Are there more up to date patches for the ATA=20 > code that > I might have missed? > Thank You. >=20 > I do have the following devices in my kernel config and have tried both= =20 > a custom config and a totally generic kernel: > # $FreeBSD: src/sys/i386/conf/GENERIC,v 1.428 2005/03/31 20:21:42 scott= l=20 > Exp $ > device ata > device atadisk # ATA disk drives > device ataraid # ATA RAID drives How did you define the array originally ? using the BIOS or atacontrol ? Does the Fasttrak BIOS see the array ? Please provide the dmesg from a verbose booted system as that will tell=20 what metadata it looks for and eventually finds. --=20 -S=F8ren From owner-freebsd-current@FreeBSD.ORG Sat Apr 30 10: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 C77E316A4CE for ; Sat, 30 Apr 2005 10:28:25 +0000 (GMT) Received: from fast.dnswatch.com (fast.dnswatch.com [216.177.243.43]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0212343D58 for ; Sat, 30 Apr 2005 10:28:25 +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 j3UASJrt023355 for ; Sat, 30 Apr 2005 03:28:22 -0700 (PDT) (envelope-from null@dnswatch.com) Received: (from www@localhost) by fast.dnswatch.com (8.12.6/8.12.6/Submit) id j3UAS4Fk023354; Sat, 30 Apr 2005 03:28:04 -0700 (PDT) (envelope-from null@dnswatch.com) X-Authentication-Warning: fast.dnswatch.com: www set sender to null@dnswatch.com using -f Received: from ns0.1command.com ([216.177.243.38]) (DNSwatch.com_WebMail authenticated user null) by webmail.dnswatch.com with HTTP; Sat, 30 Apr 2005 03:27:53 -0700 (PDT) Message-ID: <3121.216.177.243.38.1114856874.localmail@webmail.dnswatch.com> Date: Sat, 30 Apr 2005 03:27:53 -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: cleanup-boot.messages+overhaul-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: Sat, 30 Apr 2005 10:28:26 -0000 Greetings All, Now that I have your attention. ;) There seems to be some "clean-up" work that could be done in the boot messaging area. I would like to apply for the job. I've made some mention of thoughts I had on it in other messages. So I'll reiterate them here. I think the ASCII spray could be unified somewhat and that an additional "knob" could be added that would effectively act as a Volume knob. Technically, it would be a 3 position switch/ knob with: OFF/ NORMAL/ LOUD. It could probably accommodate additional fine tuning, like subsettings. But initially, the 3 shouldn't freak too many ppl out. ;) Also, upon completion of that. I would like to tackle the installer. Yes, I know about bsdinstaller. But they don't seem to have, or going to get very deep, very soon. What I propose is replace ncurses with large beautiful PNG images. Because, as everyone knows, if it's eye-candy, ppl will install it. HAH! I bet that got the hair on the back of your neck to stand straight out. ;) Seriously, having become so accustomed to it the way it is. I wouldn't want to change a thing. BUT. For those of you who remember your first installation. You'll probably remember that the intuitive factor was !> -1. Really, for the not-so-technically-inclined the installer would seem an impossible hurdle. For those who are more familliar, I think you'll agree that there is certainly room for improvement(s). For example, if a message is shot to the installer con it destroys it. The equivilant of a "refresh button" might be nice. Also, making the whole process more intuitive for the "novice" user is needed with some "help/ information blurbs". Another thing I *really* hate, is not knowing that installing this Word Proccessor will start this chain that ultimately installs an additional 750MB of Gnome $#it that I have absolutely no use for, and additionally installs another 350MB of Multimedia and related Sound servers, daemons on my system, when there isn't even a PC speaker hooked up to the thing. SO, I'd really like to figure out a better way to handle ports - both through Sysinstall and *hopefully* through ports as well. O.K. I've probably said enough for the time being. In closing I'd really like to do this and would appreciate knowing if there are any objections to my taking these things on. If there are no objections, I'd appreciate a little "hand holding" at first so I can become familiar with the process(s) of doing things around here. Thanks for listening, Chris //////////////////////////////////////////////////// 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 30 10:51: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 F17FC16A4CE for ; Sat, 30 Apr 2005 10:51:12 +0000 (GMT) Received: from fast.dnswatch.com (fast.dnswatch.com [216.177.243.43]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8408E43D31 for ; Sat, 30 Apr 2005 10:51:12 +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 j3UAourt023468 for ; Sat, 30 Apr 2005 03:51:12 -0700 (PDT) (envelope-from null@dnswatch.com) Received: (from www@localhost) by fast.dnswatch.com (8.12.6/8.12.6/Submit) id j3UAotto023467; Sat, 30 Apr 2005 03:50:55 -0700 (PDT) (envelope-from null@dnswatch.com) X-Authentication-Warning: fast.dnswatch.com: www set sender to null@dnswatch.com using -f Received: from ns0.1command.com ([216.177.243.38]) (DNSwatch.com_WebMail authenticated user null) by webmail.dnswatch.com with HTTP; Sat, 30 Apr 2005 03:50:54 -0700 (PDT) Message-ID: <3148.216.177.243.38.1114858254.localmail@webmail.dnswatch.com> Date: Sat, 30 Apr 2005 03:50:54 -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: X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 30 Apr 2005 10:51:13 -0000 Hello All, Greatly appreciate all the input you've provided. Since the majority of feedback was of a negative nature. I've decided to *definitive* pursue this project - just to spite you. ;) Seriously, I can see where there is a place for this and I think I have enough feedback to know the approach. But upon reflecting on all the input I've received on all this and so many other things. It occurs to me that I can/ should kill a couple of "peevs" I've had w/ the current system and in doing so make alot of others happy as well. So in short, while I'd really like to put the pretty sticker on the box. I think I'd be better of in the long run if I re-paint the box first. Make any sense? So, if you're remotely curious about any of this, have a look @ "cleanup-boot.messages+overhaul-install". Thanks for all your input - both positive and negative. -Chris H. //////////////////////////////////////////////////// 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 30 10:55: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 2097616A4CE for ; Sat, 30 Apr 2005 10:55:46 +0000 (GMT) Received: from fast.dnswatch.com (fast.dnswatch.com [216.177.243.43]) by mx1.FreeBSD.org (Postfix) with ESMTP id 925BC43D1F for ; Sat, 30 Apr 2005 10:55:45 +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 j3UAtirt023540 for ; Sat, 30 Apr 2005 03:55:45 -0700 (PDT) (envelope-from null@dnswatch.com) Received: (from www@localhost) by fast.dnswatch.com (8.12.6/8.12.6/Submit) id j3UAtiAg023539; Sat, 30 Apr 2005 03:55:44 -0700 (PDT) (envelope-from null@dnswatch.com) X-Authentication-Warning: fast.dnswatch.com: www set sender to null@dnswatch.com using -f Received: from ns0.1command.com ([216.177.243.38]) (DNSwatch.com_WebMail authenticated user null) by webmail.dnswatch.com with HTTP; Sat, 30 Apr 2005 03:55:44 -0700 (PDT) Message-ID: <3156.216.177.243.38.1114858544.localmail@webmail.dnswatch.com> In-Reply-To: <3155.216.177.243.38.1114858457.localmail@webmail.dnswatch.com> References: <3148.216.177.243.38.1114858272.localmail@webmail.dnswatch.com> <3155.216.177.243.38.1114858457.localmail@webmail.dnswatch.com> Date: Sat, 30 Apr 2005 03:55:44 -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: bikeshed - was [boot banner project] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 30 Apr 2005 10:55:46 -0000 Hello All, Greatly appreciate all the input you've provided. Since the majority of feedback was of a negative nature. I've decided to *definitive* pursue this project - just to spite you. ;) Seriously, I can see where there is a place for this and I think I have enough feedback to know the approach. But upon reflecting on all the input I've received on all this and so many other things. It occurs to me that I can/ should kill a couple of "peevs" I've had w/ the current system and in doing so make alot of others happy as well. So in short, while I'd really like to put the pretty sticker on the box. I think I'd be better of in the long run if I re-paint the box first. Make any sense? So, if you're remotely curious about any of this, have a look @ "cleanup-boot.messages+overhaul-install". Thanks for all your input - both positive and negative. -Chris H. //////////////////////////////////////////////////// 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 30 11:26: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 DD21016A4CE for ; Sat, 30 Apr 2005 11:26:09 +0000 (GMT) Received: from smtp811.mail.sc5.yahoo.com (smtp811.mail.sc5.yahoo.com [66.163.170.81]) by mx1.FreeBSD.org (Postfix) with SMTP id 2A12343D48 for ; Sat, 30 Apr 2005 11:26:09 +0000 (GMT) (envelope-from krinklyfig@spymac.com) Received: from unknown (HELO smogmonster.com) (jtinnin@pacbell.net@64.173.27.15 with plain) by smtp811.mail.sc5.yahoo.com with SMTP; 30 Apr 2005 11:26:08 -0000 From: Joshua Tinnin To: freebsd-current@freebsd.org Date: Sat, 30 Apr 2005 04:26:05 -0700 User-Agent: KMail/1.8 References: <3121.216.177.243.38.1114856874.localmail@webmail.dnswatch.com> In-Reply-To: <3121.216.177.243.38.1114856874.localmail@webmail.dnswatch.com> X-Face: "u-%.52Z_uQCP'Vdj{95/n*(sgAAm`F/p'b0zo%-DuBTdZ*qW!!/idDBRjkFfJD[Qe&>=?utf-8?q?=5F2=0A=09?=<}OGsEY~)n?NywZRi9xm-jH_VPg"8nTSzo:r8;U3oTQz|@z)|>%i+MRY2Y#>s~X`sV$&t"=?utf-8?q?=0A=09AkQ=5EU3rJIFCU=3F=5DcC=27F=26fY4=23Jf-=7D=3F7x?= MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200504300426.06174.krinklyfig@spymac.com> cc: /dev/null Subject: Re: cleanup-boot.messages+overhaul-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: Sat, 30 Apr 2005 11:26:10 -0000 On Sat 30 Apr 05 03:27, "/dev/null" wrote: > Another thing I *really* hate, is > not knowing that installing this Word Proccessor will start this > chain that ultimately installs an additional 750MB of Gnome $#it that > I have absolutely no use for, and additionally installs another 350MB > of Multimedia and related Sound servers, daemons on my system, when > there isn't even a PC speaker hooked up to the thing. SO, I'd really > like to figure out a better way to handle ports - both through > Sysinstall and *hopefully* through ports as well. I empathize with your frustration, but this is not an issue with FreeBSD, it's an issue with the way large desktop suites like Gnome handle dependencies. It's the same with KDE, and it's true whether or not you're installing it on FreeBSD, Slackware, Solaris or what have you. The concept behind these suites is that it should provide everything a "typical" desktop user would need, and everything is more or less bundled together - true, this concept originates with the Mac/Windows approach (more the latter), and I understand why people are loathe to accept such a concept on a *nix system, but in truth these desktops have accomplished higher adoption rates than would be possible otherwise, and they do contain many useful tools. And, honestly, that concept is also what's driving your proposal. I'm not sure if you'd ever be able to change this, as the concept is driven by the respective projects' overarching philosophies. Personally, I'd *love* to be able to install KMail without having to install kdebase and kdelibs, not to mention the rest of kdepim, but trying to convince the KDE project to uncouple it from the rest of the project is rather like tilting at windmills. That being said, it would be helpful in some circumstances to know exactly what will be pulled in by installing a part of one of these suites (i.e., most of the rest of the suite, or at least its base and libraries), but that is already possible, if not readily apparent to a new user. There are dependencies which are pulled in by large ports which sometimes do not need to be there to install the original needed port (dependencies recursing in odd directions), but in general ports does work very well for the large number of projects within it, and it does so without being needlessly complicated, though it does contain a lot of complexity. It does have some flaws, but the fact that it simplifies recursive dependencies (as much as it's allowed), and the ability to tailor individual aspects of it to my own needs through changing Makefiles and patches locally, is what keeps me using it. Local compilation allows for so much, but it can be needlessly complex, and ports makes all the parts come together, most of the time without issue, but if there is an issue it usually can be fixed. Plus, I plain like to compile apps locally ... call me crazy (wouldn't be the first time ;) Just give me the tools and don't put a hood over the engine, I can handle the rest, which seems to be what drives FreeBSD and attracts people to it, and it's why I keep using it. - jt From owner-freebsd-current@FreeBSD.ORG Sat Apr 30 12:37: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 E7CB416A4CE for ; Sat, 30 Apr 2005 12:37:35 +0000 (GMT) Received: from mailout02.sul.t-online.com (mailout02.sul.t-online.com [194.25.134.17]) by mx1.FreeBSD.org (Postfix) with ESMTP id 669B743D2D for ; Sat, 30 Apr 2005 12:37:35 +0000 (GMT) (envelope-from Alexander@Leidinger.net) Received: from fwd18.aul.t-online.de by mailout02.sul.t-online.com with smtp id 1DRrDx-00041b-03; Sat, 30 Apr 2005 14:37:33 +0200 Received: from Andro-Beta.Leidinger.net (Z2KawoZe8eK+T5pdUOhAbjkXH5G4DPvjfngim-RfBPTC-6fAZrC+sL@[84.128.192.194]) by fwd18.sul.t-online.de with esmtp id 1DRrDp-1LDlhI0; Sat, 30 Apr 2005 14:37:25 +0200 Received: from Magellan.Leidinger.net (Magellan.Leidinger.net [192.168.1.1]) j3UCbOuW094633; Sat, 30 Apr 2005 14:37:24 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Date: Sat, 30 Apr 2005 14:38:09 +0200 From: Alexander Leidinger To: "/dev/null" Message-ID: <20050430143809.168e46e0@Magellan.Leidinger.net> In-Reply-To: <3121.216.177.243.38.1114856874.localmail@webmail.dnswatch.com> References: <3121.216.177.243.38.1114856874.localmail@webmail.dnswatch.com> X-Mailer: Sylpheed-Claws 1.0.4 (GTK+ 1.2.10; i386-portbld-freebsd6.0) Importance: high X-Priority: 1 (Highest) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-ID: Z2KawoZe8eK+T5pdUOhAbjkXH5G4DPvjfngim-RfBPTC-6fAZrC+sL@t-dialin.net X-TOI-MSGID: 3ccfb7b6-7909-4ef0-b7da-436da009a1ae cc: freebsd-current@freebsd.org Subject: Re: cleanup-boot.messages+overhaul-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: Sat, 30 Apr 2005 12:37:36 -0000 On Sat, 30 Apr 2005 03:27:53 -0700 (PDT) "/dev/null" wrote: > Greetings All, > Now that I have your attention. ;) There seems to be some "clean-up" work > that could be done in the boot messaging area. I would like to apply for I suggest to add more "spaces" to your postings (e.g. start a new paragraph where a new context begins). They look like one large blob of text. This isn't easy to read. > the job. I've made some mention of thoughts I had on it in other messages. > So I'll reiterate them here. I think the ASCII spray could be unified > somewhat and that an additional "knob" could be added that would > effectively act as a Volume knob. Technically, it would be a 3 > position switch/ knob with: OFF/ NORMAL/ LOUD. It could probably > accommodate additional fine tuning, like subsettings. But initially, the > 3 shouldn't freak too many ppl out. ;) I suggest to start with a cleanup of the actual way of displaying things. When the actual startup shows a consistent behavior, a refactoring into the possibility to show n ways of status displays can start. "Step by step progress"... you know? Bye, Alexander. -- I believe the technical term is "Oops!" http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 From owner-freebsd-current@FreeBSD.ORG Fri Apr 29 19:33: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 BA82416A4CE; Fri, 29 Apr 2005 19:33:49 +0000 (GMT) Received: from mail.soaustin.net (mail.soaustin.net [207.200.4.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6DD6E43D46; Fri, 29 Apr 2005 19:33:49 +0000 (GMT) (envelope-from linimon@lonesome.com) Received: by mail.soaustin.net (Postfix, from userid 502) id C97C5149E8; Fri, 29 Apr 2005 14:33:48 -0500 (CDT) Date: Fri, 29 Apr 2005 14:33:48 -0500 (CDT) From: Mark Linimon X-X-Sender: linimon@pancho To: Jonathan Gray In-Reply-To: <20050429071907.GA13459@mail.netspace.net.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailman-Approved-At: Sat, 30 Apr 2005 12:50:29 +0000 cc: Greg 'groggy' Lehey cc: freebsd-current@FreeBSD.org Subject: Re: incorrect statement on www page X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 29 Apr 2005 19:33:49 -0000 On Fri, 29 Apr 2005, Jonathan Gray wrote: > If these binary only components come with FreeBSD they are part > of FreeBSD as far as most people are concerned. There are binary > components with no publically available source code in FreeBSD, > so it is not full source code. > > Additionally supporting such things hinders progress on acceptable > alternatives be they drivers with full source or use of other vendors. There are two ways I can see to proceed on this. 1. The project can change the offending text to be a link to a separate page that contains a paragraph, or paragraphs, about what is included in source vs binary form and the philosophical reasons that we have chosen to include the binaries (e.g. that otherwise some hardware that people have already purchased will not operate). This text could include an explanation of why no one in open source feels that this development is optimal, and a disclaimer that sometimes expedience dictates such things. 2. The project could leave the offending text as it is and get on doing what it does best, e.g. writing software and fixing bugs, instead of writing philosophical treatises. I think everyone reading this can figure out which I think is the better solution. And if that means that we lose a few users who can't deal with the binary blobs being there to, for instance, Debian or OpenBSD (who seem more concerned with such philosophical deliberations), well, fine. In the meantime there are plenty of substantive problems to work on that we stand a chance of resolving to everyone's satisfaction. IMHO this isn't one of them. mcl From owner-freebsd-current@FreeBSD.ORG Sat Apr 30 02:30: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 AA76F16A4D1 for ; Sat, 30 Apr 2005 02:30:40 +0000 (GMT) Received: from mail26.sea5.speakeasy.net (mail26.sea5.speakeasy.net [69.17.117.28]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3ADFA43D54 for ; Sat, 30 Apr 2005 02:30:40 +0000 (GMT) (envelope-from qingli@speakeasy.net) Received: (qmail 24464 invoked from network); 30 Apr 2005 02:30:39 -0000 Received: from dsl081-051-141.sfo1.dsl.speakeasy.net (HELO SAINTS) ([64.81.51.141]) (envelope-sender ) by mail26.sea5.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 30 Apr 2005 02:30:39 -0000 From: "Qing Li" To: Date: Fri, 29 Apr 2005 19:30:51 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcVMU3bbl0cH9+hATQ+t3VDXC6/DrwA2Qg7g X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 Message-Id: <20050430023040.3ADFA43D54@mx1.FreeBSD.org> X-Mailman-Approved-At: Sat, 30 Apr 2005 12:50:29 +0000 cc: 'David Malone' cc: qingli@freebsd.org cc: silby@freebsd.org cc: andre@freebsd.org cc: freebsd-current@freebsd.org Subject: FW: pmtu patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 30 Apr 2005 02:30:40 -0000 -----Original Message----- From: Qing Li [mailto:qingli@FreeBSD.org] Sent: Thursday, April 28, 2005 5:36 PM To: andre@freebsd.org Cc: qingli@freebsd.org Subject: pmtu patch Hi Andre, I was thinking whether we could add another variable in "hc_metrics" called "u_long rmx_mtu_lastupdate" and perhaps a new function called "tcp_hc_getmtu_update" When we get the ICMP PRC_MSGSIZE notification, we do if (((time_second() - tcp_hc_getmtu_update(&inc)) < PMTU_MIN) do_nothing; else { ... } If there is no suggested mtu value, instead of immediately falling back to the default, or rely on the original packet fragment, can we just use the mtu value in the host cache as the basis for the next try as in: else { mtu = ip_next_mtu(tcp_hc_getmtu(&inc), 1); } -- Qing From owner-freebsd-current@FreeBSD.ORG Sat Apr 30 13:27: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 8256816A4CE for ; Sat, 30 Apr 2005 13:27:36 +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 CF66D43D2D for ; Sat, 30 Apr 2005 13:27:35 +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 1DRs0M-0006E4-9a; Sat, 30 Apr 2005 16:27:34 +0300 X-Mailer: exmh version 2.7.0 06/18/2004 with nmh-1.0.4 To: Oleg Sharoiko In-Reply-To: Message from Oleg Sharoiko of "Sat, 30 Apr 2005 12:30:22 +0400." <20050430114225.E654@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 30 Apr 2005 16:27:34 +0300 From: Danny Braniss Message-ID: cc: freebsd-current@freebsd.org Subject: Re: diskless/unionfs 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, 30 Apr 2005 13:27:36 -0000 > Hello! > > I've read your recent discussion about unionfs panics on current. I have some > additional information which can probably help solving this panic. > Unfortunately I know absolutely nothing about internal details of vfs > implementation and so I suppose, you'd know better what to do with the > information I've learned. > > 1. I can easily reproduce the panic at any time with the following commands > (no matter how early in the boot process it happens): > > # mount -t unionfs /rescue /mnt > # /mnt/ls > > 2. Panic happens in sys/kern/kern_exec.c line 794 > > --- > int > exec_map_first_page(imgp) > struct image_params *imgp; > { > int rv, i; > int initial_pagein; > vm_page_t ma[VM_INITIAL_PAGEIN]; > vm_object_t object; > > GIANT_REQUIRED; > > if (imgp->firstpage != NULL) > exec_unmap_first_page(imgp); > > object = imgp->vp->v_object; > VM_OBJECT_LOCK(object); // !!! line 794 > --- > > kernel panics because imgp->vp->v_object is NULL > > Before it were the facts, further go my assumptions: > > 1. imgp->vp->v_tag is "union" (or "unionfs" don't remember exactly but it > doesn't matter) so I suppose this vnode was created (? or at least returned) > by unionfs. > > 2. I compared unionfs and nullfs (which seems to be the most close to unionfs > and doesn't panic on exec). I'll skip the description of comparison process > and provide the results: > > In nullfs the method null_open() (which implements vop_open()) returns vnode > with v_object not being NULL. This is how it's done (sys/fs/nullfs_vnops.c, > lines 378-390): > > --- > static int > null_open(struct vop_open_args *ap) > { > int retval; > struct vnode *vp, *ldvp; > > vp = ap->a_vp; > ldvp = NULLVPTOLOWERVP(vp); > retval = null_bypass(&ap->a_gen); > if (retval == 0) > vp->v_object = ldvp->v_object; > return (retval); > } > --- > > As far as I understand v_object is simply copied from vnode of the lower > level fs. > > I added some debugging printf's into union_vnops.c and it looks like > union_open() leaves v_object unset. Indeed on return from union_open it's > NULL and it's NULL for exactly that vnode which later panics in > exec_map_first_page() > > I made a very simple patch based on the way nullfs is implemented: > ----- > --- union_vnops.c.orig Sat Apr 30 11:36:00 2005 > +++ union_vnops.c Sat Apr 30 11:36:48 2005 > @@ -748,6 +748,9 @@ > if (error == 0) > error = VOP_OPEN(tvp, mode, cred, td, -1); > > + if (error == 0) > + ap->a_vp->v_object = tvp->v_object; > + > /* > * Release any locks held. > */ > ----- > > With this patch unionfs doesn't panic on exec. I absolutely not sure about > this patch. I understand that this may be a wrong patch because as I've > already said I know nothing about FreeBSD's vm and vfs and relations of their > objects. But at least this can probably help you solving the problem. > it did! im now make'ing buildword, and all seems 'back to normal' > And just a note: I'd also say that unfortunately unionfs still stays very > unstable. It can easily panic kernel in other parts. I've seen 'locking > against myself' and other locking panics with and without my patch. That's > too bad as it's a very nice feature for jails. It if goes this way I'd say it > would be better to disable it in 6.0 I'd be happy to spend some time fixing it we use it to mount ro /etc with an md, then populate it with private stuff, so for that it seems to fit the bill. > but I don't have it now. BTW: could you please suggest anything to read about > this vnodes, v_objects and other vfs/vm related objects so that I could > understand their relations and try to dig unionfs in case I have time? > apart for sending you to look at the source :-), i guess i'll let others chip in. thanks! danny > -- > Oleg Sharoiko. > Software and Network Engineer > Computer Center of Rostov State University. From owner-freebsd-current@FreeBSD.ORG Sat Apr 30 13:51: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 56DB216A4CE for ; Sat, 30 Apr 2005 13:51:40 +0000 (GMT) Received: from fast.dnswatch.com (fast.dnswatch.com [216.177.243.43]) by mx1.FreeBSD.org (Postfix) with ESMTP id A6E8D43D2F for ; Sat, 30 Apr 2005 13:51:39 +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 j3UDpRrt024288; Sat, 30 Apr 2005 06:51:39 -0700 (PDT) (envelope-from null@dnswatch.com) Received: (from www@localhost) by fast.dnswatch.com (8.12.6/8.12.6/Submit) id j3UDpPGv024287; Sat, 30 Apr 2005 06:51:25 -0700 (PDT) (envelope-from null@dnswatch.com) X-Authentication-Warning: fast.dnswatch.com: www set sender to null@dnswatch.com using -f Received: from ns0.1command.com ([216.177.243.38]) (DNSwatch.com_WebMail authenticated user null) by webmail.dnswatch.com with HTTP; Sat, 30 Apr 2005 06:51:24 -0700 (PDT) Message-ID: <4125.216.177.243.38.1114869084.localmail@webmail.dnswatch.com> In-Reply-To: <20050430143809.168e46e0@Magellan.Leidinger.net> References: <3121.216.177.243.38.1114856874.localmail@webmail.dnswatch.com> <20050430143809.168e46e0@Magellan.Leidinger.net> Date: Sat, 30 Apr 2005 06:51:24 -0700 (PDT) From: "/dev/null" To: "Alexander Leidinger" 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 cc: freebsd-current@freebsd.org Subject: Re: cleanup-boot.messages+overhaul-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: Sat, 30 Apr 2005 13:51:40 -0000 > On Sat, 30 Apr 2005 03:27:53 -0700 (PDT) > "/dev/null" wrote: > >> Greetings All, >> Now that I have your attention. ;) There seems to be some "clean-up" >> work >> that could be done in the boot messaging area. I would like to apply for > > I suggest to add more "spaces" to your postings (e.g. start a new > paragraph where a new context begins). They look like one large blob of > text. This isn't easy to read. Sorry about the big blob. I get to thinking and typing and don't pay enough attention. I'll try to watch that in the future. :) > >> the job. I've made some mention of thoughts I had on it in other >> messages. >> So I'll reiterate them here. I think the ASCII spray could be unified >> somewhat and that an additional "knob" could be added that would >> effectively act as a Volume knob. Technically, it would be a 3 >> position switch/ knob with: OFF/ NORMAL/ LOUD. It could probably >> accommodate additional fine tuning, like subsettings. But initially, the >> 3 shouldn't freak too many ppl out. ;) > > I suggest to start with a cleanup of the actual way of displaying > things. > > When the actual startup shows a consistent behavior, a refactoring into > the possibility to show n ways of status displays can start. > > "Step by step progress"... you know? Wouldn't have handled it any other way. :) Geuss I'll start in /etc/rc.d. Then start plowing through all the ports trolling for the rc scripts that get generated by so many of the ports. -Chris > > Bye, > Alexander. > > -- > I believe the technical term is "Oops!" > > http://www.Leidinger.net Alexander @ Leidinger.net > GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 > _______________________________________________ > 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 30 14:05: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 B9E7116A4CE for ; Sat, 30 Apr 2005 14:05:15 +0000 (GMT) Received: from mailout04.sul.t-online.com (mailout04.sul.t-online.com [194.25.134.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3097543D3F for ; Sat, 30 Apr 2005 14:05:15 +0000 (GMT) (envelope-from Alexander@Leidinger.net) Received: from fwd27.aul.t-online.de by mailout04.sul.t-online.com with smtp id 1DRsan-0007mg-02; Sat, 30 Apr 2005 16:05:13 +0200 Received: from Andro-Beta.Leidinger.net (ZY4EdaZEQeqoAsH07S+ipcymG91vNcMl62Zyj8-FQMlBwmbOShNBEy@[84.128.192.194]) by fwd27.sul.t-online.de with esmtp id 1DRsaa-0H6bdQ0; Sat, 30 Apr 2005 16:05:00 +0200 Received: from Magellan.Leidinger.net (Magellan.Leidinger.net [192.168.1.1]) j3UE4tZ1054070; Sat, 30 Apr 2005 16:04:55 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Date: Sat, 30 Apr 2005 16:05:40 +0200 From: Alexander Leidinger To: "/dev/null" Message-ID: <20050430160540.45628032@Magellan.Leidinger.net> In-Reply-To: <4125.216.177.243.38.1114869084.localmail@webmail.dnswatch.com> References: <3121.216.177.243.38.1114856874.localmail@webmail.dnswatch.com> <20050430143809.168e46e0@Magellan.Leidinger.net> <4125.216.177.243.38.1114869084.localmail@webmail.dnswatch.com> 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-ID: ZY4EdaZEQeqoAsH07S+ipcymG91vNcMl62Zyj8-FQMlBwmbOShNBEy@t-dialin.net X-TOI-MSGID: 44949251-f32c-4f5d-8bbe-baa149c6046f cc: freebsd-current@freebsd.org Subject: Re: cleanup-boot.messages+overhaul-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: Sat, 30 Apr 2005 14:05:15 -0000 On Sat, 30 Apr 2005 06:51:24 -0700 (PDT) "/dev/null" wrote: > > I suggest to add more "spaces" to your postings (e.g. start a new > > paragraph where a new context begins). They look like one large blob of > > text. This isn't easy to read. > > Sorry about the big blob. I get to thinking and typing and don't pay > enough attention. I'll try to watch that in the future. :) Writting text needs time, writting short and easy to understand text needs more time. :-) > Geuss I'll start in /etc/rc.d. Then start plowing through all the ports > trolling for the rc scripts that get generated by so many of the ports. You should discuss/coordinate on/with the freebsd-rc mailinglist. Bye, Alexander. -- "One world, one web, one program" -- Microsoft promotional ad "Ein Volk, ein Reich, ein Fuehrer" -- Adolf Hitler http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 From owner-freebsd-current@FreeBSD.ORG Sat Apr 30 14:10: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 AF75A16A4CE for ; Sat, 30 Apr 2005 14:10:23 +0000 (GMT) Received: from fast.dnswatch.com (fast.dnswatch.com [216.177.243.43]) by mx1.FreeBSD.org (Postfix) with ESMTP id 207D843D1F for ; Sat, 30 Apr 2005 14:10:23 +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 j3UEALrt024558; Sat, 30 Apr 2005 07:10:23 -0700 (PDT) (envelope-from null@dnswatch.com) Received: (from www@localhost) by fast.dnswatch.com (8.12.6/8.12.6/Submit) id j3UEALwU024557; Sat, 30 Apr 2005 07:10:21 -0700 (PDT) (envelope-from null@dnswatch.com) X-Authentication-Warning: fast.dnswatch.com: www set sender to null@dnswatch.com using -f Received: from ns0.1command.com ([216.177.243.38]) (DNSwatch.com_WebMail authenticated user null) by webmail.dnswatch.com with HTTP; Sat, 30 Apr 2005 07:10:20 -0700 (PDT) Message-ID: <4151.216.177.243.38.1114870220.localmail@webmail.dnswatch.com> In-Reply-To: <20050429111514.je0mg399kos00ooo@netchild.homeip.net> References: <57436.216.177.243.42.1114582155.localmail@webmail.dnswatch.com><426FDE69.8090909@samsco.org><426FE1EA.7020900@kutulu.org><20050427212637.GL98718@over-yonder.net><20050428115258.rpvu466t68so80w4@netchild.homeip.net><53801.216.177.243.35.1114720139.localmail@webmail.dnswatch.com> <20050429111514.je0mg399kos00ooo@netchild.homeip.net> Date: Sat, 30 Apr 2005 07:10:20 -0700 (PDT) From: "/dev/null" To: "Alexander Leidinger" 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 cc: freebsd-current@freebsd.org Subject: Re: boot banner project X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 30 Apr 2005 14:10:23 -0000 > /dev/null wrote: > >>> I think restructuring our userland boot message would be a good start. >>> I'm >>> not talking about the above proposal, even if I think it's nice (but a >>> little bit too terse for me), I'm talking about rethinking the actual >>> (since >>> the new rc system) clutter. >>> >>> The 4.x startup looks structured (it could be improved to be more eye >>> friendly, but the beauty lies in the eye of the beholder), while the 5+ >>> one >>> is neither fish nor meat. It's a mixture of the 4.x one with the >>> "Starting >>> xyz" messages from the new system. Since we don't try to keep the new >>> system >>> diff friendly with the NetBSD source anymore, I think we could change >>> it >>> to >>> fit our needs. >> >> Maybe this would be a better place for me to start >> (assuming no objection(s)). I mean, it may turn out >> the large majority of opinion is: boot-banner SUX! So > > If root is able to switch the boot-banner on/off, and as long as headless > and > serial-console enabled systems behave as usual, nothing should stop you > from > doing this project. > >> in either case; making what already exists more desirable/ >> funcional; seems the best place to start something. As >> opposed to adding to something that might me better polished >> up. What's more, I was thinking; what if the current settings >> ( verbose/ terse ) were expanded and prettified(stylized). >> Example: 3 settings; >> >> 1) no output: black, or blank screen until the prompt/ login. > > That's not a good option (from an usability point of view). You need at > least > some progress indicator, else an user will ask if the system freezed or > not. > >> 2) terse: >> a) only dumps warnings >> b) dumps item at succesful load, or else failure message as returned by >> failed object. >> >> 3) verbose: >> a) raw (pretty much the way it is now but unify/ sanitize the messages >> returned - (4.x ify?)) >> b) prettified >> (example(s): >> >> mysql >> >> or >> >> mysql ) >> >> both or *could* be colorized. > > That's too much options IMHO ("less" is "more", you know? ;-) ). You need > a > progress indicator in 2), and you need the possibility to report errors in > 1), so I think you can reduce it to > a) progress indicator + error output > b) raw (as is, or polished up) > c) nice > > But since we don't have an option to shut up the kernel messages on boot, > I > think we don't need a). > I can see all your points. I'm just forming these concepts. So it's great to hear others perspectives on this. It's easy to overlook details sometimes. > If you want to proceeed with this, > you should move over to the freebsd rc mailinglist. Could you expand on this? I don't know sbout that list. Or you just attempting to get rid of me? > > Bye, > Alexander. > > -- > http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 > http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 > If sex is such a natural phenomenon, how come there are so many > books on how to? > -- Bette Midler > > > _______________________________________________ > 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" > -Chris H. //////////////////////////////////////////////////// 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 30 14:40: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 1354D16A4CE for ; Sat, 30 Apr 2005 14:40:31 +0000 (GMT) Received: from cyrus.watson.org (cyrus.watson.org [204.156.12.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id C0D5543D41 for ; Sat, 30 Apr 2005 14:40:30 +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 35DAC46B3C for ; Sat, 30 Apr 2005 10:40:30 -0400 (EDT) Date: Sat, 30 Apr 2005 15:43:21 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: current@FreeBSD.org Message-ID: <20050430154103.L31768@fledge.watson.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Kernel memory allocator change (cvs commit: src/sys/vm uma_core.c uma_int.h (fwd) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 30 Apr 2005 14:40:31 -0000 I've finally committed the UMA critical section per-cpu cache synchronization change to the CVS HEAD. Two notes: - This is intended to make things slightly faster. If you notice a consistent slow-down, ideally characterizable with a highly reproduceable benchmark, I'd like to hear about it. "Yes, it did get faster" is also good, as is "it didn't get slower". - We've done quite a bit of testing with these patches in place. However, that doesn't preclude a stability proble. For those running regular stability testing on HEAD, running with this change would be a good thing. Thanks, Robert N M Watson ---------- Forwarded message ---------- Date: Fri, 29 Apr 2005 18:56:36 +0000 (UTC) From: Robert Watson To: src-committers@FreeBSD.org, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org Subject: cvs commit: src/sys/vm uma_core.c uma_int.h rwatson 2005-04-29 18:56:36 UTC FreeBSD src repository Modified files: sys/vm uma_core.c uma_int.h Log: Modify UMA to use critical sections to protect per-CPU caches, rather than mutexes, which offers lower overhead on both UP and SMP. When allocating from or freeing to the per-cpu cache, without INVARIANTS enabled, we now no longer perform any mutex operations, which offers a 1%-3% performance improvement in a variety of micro-benchmarks. We rely on critical sections to prevent (a) preemption resulting in reentrant access to UMA on a single CPU, and (b) migration of the thread during access. In the event we need to go back to the zone for a new bucket, we release the critical section to acquire the global zone mutex, and must re-acquire the critical section and re-evaluate which cache we are accessing in case migration has occured, or circumstances have changed in the current cache. Per-CPU cache statistics are now gathered lock-free by the sysctl, which can result in small races in statistics reporting for caches. Reviewed by: bmilekic, jeff (somewhat) Tested by: rwatson, kris, gnn, scottl, mike at sentex dot net, others Revision Changes Path 1.119 +120 -103 src/sys/vm/uma_core.c 1.30 +0 -10 src/sys/vm/uma_int.h From owner-freebsd-current@FreeBSD.ORG Sat Apr 30 15:09: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 BA1DD16A4CE for ; Sat, 30 Apr 2005 15:09:17 +0000 (GMT) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.203]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4AF6A43D41 for ; Sat, 30 Apr 2005 15:09:17 +0000 (GMT) (envelope-from lihong.chen@gmail.com) Received: by wproxy.gmail.com with SMTP id 69so1158470wri for ; Sat, 30 Apr 2005 08:09:16 -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=mc7+I7UMFZ9oHRpqeci8lXZtIuVfeFwRbdtyBFWriiGf4ptDFMauLBGzXEymb6MOiyrCIRoqNd4wG4DV/7qxjNe0eW8aPPVmiyg4wTc8zFK0hUKzWU9xVk9fQpEhlrUZUNtbq9WuC2nBEx1fgc18vfCuqlT0PRlEfmgjMLkxTdM= Received: by 10.54.125.20 with SMTP id x20mr1845933wrc; Sat, 30 Apr 2005 08:09:16 -0700 (PDT) Received: by 10.54.2.75 with HTTP; Sat, 30 Apr 2005 08:09:16 -0700 (PDT) Message-ID: Date: Sat, 30 Apr 2005 23:09:16 +0800 From: Lihong Chen To: Brian Candler In-Reply-To: <20050429152755.GA93843@uk.tiscali.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <20050429152755.GA93843@uk.tiscali.com> cc: current@freebsd.org Subject: Re: buildworld failed with '-O3' in 6-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Lihong Chen List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Apr 2005 15:09:17 -0000 Yes, I agree! On 4/29/05, Brian Candler wrote: > On Fri, Apr 29, 2005 at 11:16:33PM +0800, Lihong Chen wrote: > > Hi! > > I try to buildworld using gcc -O3, but some file will failed. > > they are using fuctions not consist with declared, like these: > > --- /usr/src/lib/libc/rpc/getpublickey.c.orig Fri Apr 29 02:10:53 2005 > > +++ /usr/src/lib/libc/rpc/getpublickey.c Fri Apr 29 02:13:02 2005 > > @@ -175,5 +175,5 @@ > > if (__getpublickey_LOCAL !=3D NULL) > > return(__getpublickey_LOCAL(netname, publickey)); > > else > > - return(__getpublickey_real(netname, publickey)); > > + return(__getpublickey_real((char*)netname, publickey)); > > } >=20 > Surely better to avoid casts, which will hide errors later on. Instead ju= st > make things consistent, either by >=20 > __getpublickey_real(netname, publickey) > - char *netname; > + const char *netname; >=20 > or by >=20 > int getpublickey(netname, publickey) > - const char *netname; > + char *netname; >=20 > as appropriate semantically. > From owner-freebsd-current@FreeBSD.ORG Sat Apr 30 16:28: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 2BD1816A4CE for ; Sat, 30 Apr 2005 16:28:40 +0000 (GMT) Received: from mail.mercenarylabs.com (wilson.mercenarylabs.com [12.158.191.94]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9111C43D3F for ; Sat, 30 Apr 2005 16:28:39 +0000 (GMT) (envelope-from jondoor@udor.net) Received: from [127.0.0.1] (wilson [12.158.191.94]) by mail.mercenarylabs.com (Postfix) with ESMTP id C7F2CAD17; Sat, 30 Apr 2005 11:28:39 -0500 (CDT) Message-ID: <4273B234.8070808@udor.net> Date: Sat, 30 Apr 2005 12:28:36 -0400 From: Jon Door User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050326) X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?S=F8ren_Schmidt?= , freebsd-current@freebsd.org References: <4272AFC6.2040907@udor.net> <4273441E.5000609@DeepCore.dk> In-Reply-To: <4273441E.5000609@DeepCore.dk> X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: ATA RAID -- Promise SATA150 vanished /dev/ar0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: jondoor@udor.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Apr 2005 16:28:40 -0000 Søren Schmidt wrote: > Jon Door wrote: > >> I have a Promise Fastrak SATA RAID controller (PDC20371). Running a >> >> stripe between two 120GB drives. Running under a generic RELENG_5 the >> controller, its drives, and the stripe where all detect without >> problem. /dev/ar0 was generated without any special changes. Today I >> upgraded to 6.0-CURRENT. Now the Promise controller and its drives >> are recognized but no /dev/ar0, and no evidence of the stripe. >> Booting back to a RELENG_5 system show the stripe data to still be >> intact. I've beem reading >> through all the ATA mkIII posts and haven't seen this specific issue, >> am I missing a step here or is this possibly an issue between the new >> ATA code and my RAID card? Are there more up to date patches for the >> ATA code that >> I might have missed? >> Thank You. >> >> I do have the following devices in my kernel config and have tried >> both a custom config and a totally generic kernel: >> # $FreeBSD: src/sys/i386/conf/GENERIC,v 1.428 2005/03/31 20:21:42 >> scottl Exp $ >> device ata >> device atadisk # ATA disk drives >> device ataraid # ATA RAID drives > > > How did you define the array originally ? using the BIOS or atacontrol ? > Does the Fasttrak BIOS see the array ? > Please provide the dmesg from a verbose booted system as that will > tell what metadata it looks for and eventually finds. > Using the BIOS. The Fasttrak reports the array as functional during boot, and returning to a 5.4 kernel allows me to mount the volume without incident. Thanks! It looks like its not getting any metadata persiod, cut from the dmesg: ata0-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire ad4: 114440MB at ata2-master SATA150 ad4: 234375000 sectors [232514C/16H/63S] 16 sectors/interrupt 1 depth queue ad4: Promise check1 failed ad4: Adaptec check1 failed ad4: LSI (v3) check1 failed ad4: LSI (v2) check1 failed ad4: FreeBSD check1 failed ata1-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire ad6: 114440MB at ata3-master SATA150 ad6: 234375000 sectors [232514C/16H/63S] 16 sectors/interrupt 1 depth queue ad6: Promise check1 failed ad6: Adaptec check1 failed ad6: LSI (v3) check1 failed ad6: LSI (v2) check1 failed ad6: FreeBSD check1 failed Full Verbose dmesg from dmesg.boot log: null: npx0: [FAST] npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard acpi0: [MPSAFE] pci_open(1): mode 1 addr port (0x0cf8) is 0x80000060 pci_open(1a): mode1res=0x80000000 (0x80000000) pci_cfgcheck: device 0 [class=060000] [hdr=00] is there (id=06911106) pcibios: BIOS version 2.10 Found $PIR table, 9 entries at 0xc00f1310 PCI-Only Interrupts: none Location Bus Device Pin Link IRQs embedded 0 4 A 0x05 3 4 5 7 9 10 11 12 embedded 0 4 B 0x01 3 4 5 7 9 10 11 12 embedded 0 4 C 0x02 3 4 5 7 9 10 11 12 embedded 0 4 D 0x03 3 4 5 7 9 10 11 12 slot 1 0 12 A 0x01 3 4 5 7 9 10 11 12 slot 1 0 12 B 0x02 3 4 5 7 9 10 11 12 slot 1 0 12 C 0x03 3 4 5 7 9 10 11 12 slot 1 0 12 D 0x05 3 4 5 7 9 10 11 12 slot 2 0 11 A 0x02 3 4 5 7 9 10 11 12 slot 2 0 11 B 0x03 3 4 5 7 9 10 11 12 slot 2 0 11 C 0x05 3 4 5 7 9 10 11 12 slot 2 0 11 D 0x01 3 4 5 7 9 10 11 12 slot 3 0 10 A 0x03 3 4 5 7 9 10 11 12 slot 3 0 10 B 0x05 3 4 5 7 9 10 11 12 slot 3 0 10 C 0x01 3 4 5 7 9 10 11 12 slot 3 0 10 D 0x02 3 4 5 7 9 10 11 12 slot 4 0 9 A 0x05 3 4 5 7 9 10 11 12 slot 4 0 9 B 0x01 3 4 5 7 9 10 11 12 slot 4 0 9 C 0x02 3 4 5 7 9 10 11 12 slot 4 0 9 D 0x03 3 4 5 7 9 10 11 12 slot 5 0 13 A 0x05 3 4 5 7 9 10 11 12 slot 5 0 13 B 0x01 3 4 5 7 9 10 11 12 slot 5 0 13 C 0x02 3 4 5 7 9 10 11 12 slot 5 0 13 D 0x03 3 4 5 7 9 10 11 12 embedded 0 7 A 0x02 3 4 5 7 9 10 11 12 embedded 0 8 A 0x05 3 4 5 7 9 10 11 12 embedded 0 8 B 0x01 3 4 5 7 9 10 11 12 slot 6 1 0 A 0x01 3 4 5 7 9 10 11 12 slot 6 1 0 B 0x02 3 4 5 7 9 10 11 12 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: bus 0 dev 4 func 0 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: bus 0 dev 4 func 0 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: bus 0 dev 4 func 0 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: bus 0 dev 4 func 0 acpi0: Power Button (fixed) pci_link0: irq 11 on acpi0 pci_link0: Links after initial probe: Index IRQ Rtd Ref IRQs 0 11 N 0 3 4 5 6 7 9 10 11 12 14 15 pci_link0: Links after initial validation: Index IRQ Rtd Ref IRQs 0 11 N 0 3 4 5 6 7 9 10 11 12 14 15 pci_link0: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 6 7 9 10 11 12 14 15 pci_link1: irq 10 on acpi0 pci_link1: Links after initial probe: Index IRQ Rtd Ref IRQs 0 10 N 0 3 4 5 6 7 9 10 11 12 14 15 pci_link1: Links after initial validation: Index IRQ Rtd Ref IRQs 0 10 N 0 3 4 5 6 7 9 10 11 12 14 15 pci_link1: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 6 7 9 10 11 12 14 15 pci_link2: irq 12 on acpi0 pci_link2: Links after initial probe: Index IRQ Rtd Ref IRQs 0 12 N 0 3 4 5 6 7 9 10 11 12 14 15 pci_link2: Links after initial validation: Index IRQ Rtd Ref IRQs 0 12 N 0 3 4 5 6 7 9 10 11 12 14 15 pci_link2: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 6 7 9 10 11 12 14 15 pci_link3: irq 3 on acpi0 pci_link3: Links after initial probe: Index IRQ Rtd Ref IRQs 0 3 N 0 3 4 5 6 7 9 10 11 12 14 15 pci_link3: Links after initial validation: Index IRQ Rtd Ref IRQs 0 3 N 0 3 4 5 6 7 9 10 11 12 14 15 pci_link3: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 6 7 9 10 11 12 14 15 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: bus 0 dev 4 func 0 ACPI timer: 0/3 0/3 1/1 0/3 0/3 0/3 0/3 0/3 0/3 1/1 -> 2 Timecounter "ACPI-safe" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0xe408-0xe40b on acpi0 cpu0: on acpi0 cpu1: on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: physical bus=0 found-> vendor=0x1106, dev=0x0691, revid=0xc4 bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x2210, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) powerspec 2 supports D0 D3 current D0 map[10]: type 3, range 32, base f0000000, size 27, enabled found-> vendor=0x1106, dev=0x8598, revid=0x00 bus=0, slot=1, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0007, statreg=0x2230, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x08 (2000 ns), maxlat=0x00 (0 ns) found-> vendor=0x1106, dev=0x0686, revid=0x40 bus=0, slot=4, func=0 class=06-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x0087, statreg=0x0210, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) powerspec 2 supports D0 D3 current D0 found-> vendor=0x1106, dev=0x0571, revid=0x06 bus=0, slot=4, func=1 class=01-01-8a, hdrtype=0x00, mfdev=0 cmdreg=0x0087, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) powerspec 2 supports D0 D3 current D0 map[20]: type 4, range 32, base 0000d800, size 4, enabled found-> vendor=0x1106, dev=0x3038, revid=0x16 bus=0, slot=4, func=2 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0017, statreg=0x0210, cachelnsz=8 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=d, irq=12 powerspec 2 supports D0 D3 current D0 map[20]: type 4, range 32, base 0000d400, size 5, enabled pcib0: matched entry for 0.4.INTD (src \\_SB_.LNKC:0) ioapic0: Changing trigger for pin 12 to level ioapic0: Changing polarity for pin 12 to low pcib0: slot 4 INTD routed to irq 12 via \\_SB_.LNKC found-> vendor=0x1106, dev=0x3038, revid=0x16 bus=0, slot=4, func=3 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0017, statreg=0x0210, cachelnsz=8 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=d, irq=12 powerspec 2 supports D0 D3 current D0 map[20]: type 4, range 32, base 0000d000, size 5, enabled pcib0: matched entry for 0.4.INTD (src \\_SB_.LNKC:0) pcib0: slot 4 INTD routed to irq 12 via \\_SB_.LNKC found-> vendor=0x1106, dev=0x3057, revid=0x40 bus=0, slot=4, func=4 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0000, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) powerspec 2 supports D0 D3 current D0 found-> vendor=0x8086, dev=0x1229, revid=0x08 bus=0, slot=7, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0014, statreg=0x0290, cachelnsz=8 (dwords) lattimer=0x20 (960 ns), mingnt=0x08 (2000 ns), maxlat=0x38 (14000 ns) intpin=a, irq=255 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 1, range 32, base e4800000, size 12, memory disabled map[14]: type 4, range 32, base 0000b800, size 6, port disabled map[18]: type 1, range 32, base e4000000, size 20, enabled found-> vendor=0x1000, dev=0x0020, revid=0x01 bus=0, slot=8, func=0 class=01-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0017, statreg=0x0210, cachelnsz=8 (dwords) lattimer=0x48 (2160 ns), mingnt=0x11 (4250 ns), maxlat=0x12 (4500 ns) intpin=a, irq=3 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 4, range 32, base 0000b400, size 8, enabled map[14]: type 1, range 64, base e3800000, size 10, enabled map[1c]: type 1, range 64, base e3000000, size 13, enabled pcib0: matched entry for 0.8.INTA pcib0: slot 8 INTA hardwired to IRQ 19 found-> vendor=0x1000, dev=0x0020, revid=0x01 bus=0, slot=8, func=1 class=01-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0017, statreg=0x0210, cachelnsz=8 (dwords) lattimer=0x48 (2160 ns), mingnt=0x11 (4250 ns), maxlat=0x12 (4500 ns) intpin=b, irq=11 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 4, range 32, base 0000b000, size 8, enabled map[14]: type 1, range 64, base e2800000, size 10, enabled map[1c]: type 1, range 64, base e2000000, size 13, enabled pcib0: matched entry for 0.8.INTB pcib0: slot 8 INTB hardwired to IRQ 16 found-> vendor=0x1102, dev=0x0004, revid=0x03 bus=0, slot=9, func=0 class=04-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x0004, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x02 (500 ns), maxlat=0x14 (5000 ns) intpin=a, irq=255 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 4, range 32, base 0000a800, size 5, port disabled found-> vendor=0x1102, dev=0x7003, revid=0x03 bus=0, slot=9, func=1 class=09-80-00, hdrtype=0x00, mfdev=1 cmdreg=0x0004, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 4, range 32, base 0000a400, size 3, port disabled found-> vendor=0x1102, dev=0x4001, revid=0x00 bus=0, slot=9, func=2 class=0c-00-10, hdrtype=0x00, mfdev=1 cmdreg=0x0014, statreg=0x0210, cachelnsz=8 (dwords) lattimer=0x20 (960 ns), mingnt=0x02 (500 ns), maxlat=0x04 (1000 ns) intpin=b, irq=255 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 1, range 32, base e1800000, size 11, memory disabled map[14]: type 1, range 32, base e1000000, size 14, enabled found-> vendor=0x105a, dev=0x3371, revid=0x02 bus=0, slot=11, func=0 class=01-04-00, hdrtype=0x00, mfdev=0 cmdreg=0x0017, statreg=0x0230, cachelnsz=144 (dwords) lattimer=0x60 (2880 ns), mingnt=0x04 (1000 ns), maxlat=0x12 (4500 ns) intpin=a, irq=10 powerspec 2 supports D0 D1 D3 current D0 map[10]: type 4, range 32, base 0000a000, size 6, enabled map[14]: type 4, range 32, base 00009800, size 4, enabled map[18]: type 4, range 32, base 00009400, size 7, enabled map[1c]: type 1, range 32, base e0800000, size 12, enabled map[20]: type 1, range 32, base e0000000, size 17, enabled pcib0: matched entry for 0.11.INTA pcib0: slot 11 INTA hardwired to IRQ 17 found-> vendor=0x109e, dev=0x036e, revid=0x11 bus=0, slot=13, func=0 class=04-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0004, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x10 (4000 ns), maxlat=0x28 (10000 ns) intpin=a, irq=255 powerspec 2 supports D0 D3 current D0 map[10]: type 3, range 32, base e7000000, size 12, memory disabled found-> vendor=0x109e, dev=0x0878, revid=0x11 bus=0, slot=13, func=1 class=04-80-00, hdrtype=0x00, mfdev=1 cmdreg=0x0004, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x04 (1000 ns), maxlat=0xff (63750 ns) intpin=a, irq=255 powerspec 2 supports D0 D3 current D0 map[10]: type 3, range 32, base e6800000, size 12, memory disabled agp0: mem 0xf0000000-0xf7ffffff at device 0.0 on pci0 agp0: Reserved 0x8000000 bytes for rid 0x10 type 3 at 0xf0000000 agp0: allocating GATT for aperture of size 256M pcib1: at device 1.0 on pci0 pcib1: secondary bus 1 pcib1: subordinate bus 1 pcib1: I/O decode 0xe000-0xdfff pcib1: memory decode 0xe5000000-0xe67fffff pcib1: prefetched decode 0xe7f00000-0xefffffff pci1: on pcib1 pci1: physical bus=1 found-> vendor=0x10de, dev=0x0322, revid=0xa1 bus=1, slot=0, func=0 class=03-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x02b0, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x05 (1250 ns), maxlat=0x01 (250 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 map[10]: type 1, range 32, base e5000000, size 24, enabled pcib1: (null) requested memory range 0xe5000000-0xe5ffffff: good map[14]: type 3, range 32, base e8000000, size 27, enabled pcib1: (null) requested memory range 0xe8000000-0xefffffff: good pcib1: matched entry for 1.0.INTA pcib1: slot 0 INTA hardwired to IRQ 16 nvidia0: mem 0xe5000000-0xe5ffffff,0xe8000000-0xefffffff irq 16 at device 0.0 on pci1 nvidia0: Reserved 0x1000000 bytes for rid 0x10 type 3 at 0xe5000000 nvidia0: Reserved 0x8000000 bytes for rid 0x14 type 3 at 0xe8000000 nvidia0: [GIANT-LOCKED] isab0: at device 4.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xd800-0xd80f at device 4.1 on pci0 atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0xd800 ata0: on atapci0 atapci0: Reserved 0x8 bytes for rid 0x10 type 4 at 0x1f0 atapci0: Reserved 0x1 bytes for rid 0x14 type 4 at 0x3f6 ata0: reset tp1 mask=03 ostat0=e0 ostat1=f0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat1=0xb0 err=0xb0 lsb=0xb0 msb=0xb0 ata0: reset tp2 stat0=a0 stat1=b0 devices=0x0 ata0: [MPSAFE] ata1: on atapci0 atapci0: Reserved 0x8 bytes for rid 0x18 type 4 at 0x170 atapci0: Reserved 0x1 bytes for rid 0x1c type 4 at 0x376 ata1: reset tp1 mask=03 ostat0=50 ostat1=50 ata1: stat0=0x80 err=0x80 lsb=0x80 msb=0x80 ata1: stat0=0x80 err=0x80 lsb=0x80 msb=0x80 ata1: stat0=0x00 err=0x01 lsb=0x14 msb=0xeb ata1: stat1=0x00 err=0x01 lsb=0x14 msb=0xeb ata1: reset tp2 stat0=00 stat1=00 devices=0xc ata1: [MPSAFE] uhci0: port 0xd400-0xd41f irq 12 at device 4.2 on pci0 uhci0: Reserved 0x20 bytes for rid 0x20 type 4 at 0xd400 uhci0: [GIANT-LOCKED] usb0: on uhci0 usb0: USB revision 1.0 uhub0: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1: port 0xd000-0xd01f irq 12 at device 4.3 on pci0 uhci1: Reserved 0x20 bytes for rid 0x20 type 4 at 0xd000 uhci1: [GIANT-LOCKED] usb1: on uhci1 usb1: USB revision 1.0 uhub1: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered fxp0: port 0xb800-0xb83f mem 0xe4800000-0xe4800fff,0xe4000000-0xe40fffff at device 7.0 on pci0 fxp0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xe4800000 fxp0: using memory space register mapping pcib0: matched entry for 0.7.INTA pcib0: slot 7 INTA hardwired to IRQ 17 fxp0: PCI IDs: 8086 1229 8086 000c 0008 fxp0: Dynamic Standby mode is disabled miibus0: on fxp0 inphy0: on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp0: bpf attached fxp0: Ethernet address: 00:00:00:00:00:00 fxp0: [MPSAFE] sym0: <1010-33> port 0xb400-0xb4ff mem 0xe3800000-0xe38003ff,0xe3000000-0xe3001fff irq 19 at device 8.0 on pci0 sym0: Reserved 0x400 bytes for rid 0x14 type 3 at 0xe3800000 sym0: Reserved 0x2000 bytes for rid 0x1c type 3 at 0xe3000000 sym0: Symbios NVRAM, ID 7, Fast-80, LVD, parity checking sym0: open drain IRQ line driver, using on-chip SRAM sym0: using LOAD/STORE-based firmware. sym0: handling phase mismatch from SCRIPTS. sym0: initial SCNTL3/DMODE/DCNTL/CTEST3/4/5 = (hex) 00/4e/a0/01/00/04 sym0: final SCNTL3/DMODE/DCNTL/CTEST3/4/5 = (hex) 00/4e/80/01/08/04 sym0: [GIANT-LOCKED] sym0: enabling clock multiplier sym0: Downloading SCSI SCRIPTS. sym1: <1010-33> port 0xb000-0xb0ff mem 0xe2800000-0xe28003ff,0xe2000000-0xe2001fff irq 16 at device 8.1 on pci0 sym1: Reserved 0x400 bytes for rid 0x14 type 3 at 0xe2800000 sym1: Reserved 0x2000 bytes for rid 0x1c type 3 at 0xe2000000 sym1: Symbios NVRAM, ID 7, Fast-80, LVD, parity checking sym1: open drain IRQ line driver, using on-chip SRAM sym1: using LOAD/STORE-based firmware. sym1: handling phase mismatch from SCRIPTS. sym1: initial SCNTL3/DMODE/DCNTL/CTEST3/4/5 = (hex) 00/4e/a0/01/00/04 sym1: final SCNTL3/DMODE/DCNTL/CTEST3/4/5 = (hex) 00/4e/80/01/08/04 sym1: [GIANT-LOCKED] sym1: enabling clock multiplier sym1: Downloading SCSI SCRIPTS. pcm0: port 0xa800-0xa81f at device 9.0 on pci0 pcm0: Reserved 0x20 bytes for rid 0x10 type 4 at 0xa800 emu: setmap (269000, 800), nseg=1, error=0 emu: setmap (26f28000, 1000), nseg=1, error=0 pcm0: pcm0: Codec features 5 bit master volume, no 3D Stereo Enhancement pcib0: matched entry for 0.9.INTA pcib0: slot 9 INTA hardwired to IRQ 19 pcm0: [MPSAFE] emu: setmap (26f06000, 1000), nseg=1, error=0 emu: setmap (26f04000, 1000), nseg=1, error=0 emu: setmap (26f02000, 1000), nseg=1, error=0 emu: setmap (24c000, 1000), nseg=1, error=0 emu: setmap (26e000, 1000), nseg=1, error=0 emu: setmap (26f22000, 1000), nseg=1, error=0 emu: setmap (2c0000, 1000), nseg=1, error=0 emu: setmap (2de000, 1000), nseg=1, error=0 pcm0: sndbuf_setmap 29c000, 1000; 0xc2188000 -> 29c000 pcm0: sndbuf_setmap 29a000, 1000; 0xc2186000 -> 29a000 fwohci0: vendor=1102, dev=4001 fwohci0: vendor=1102, dev=4001 fwohci0: <1394 Open Host Controller Interface> mem 0xe1800000-0xe18007ff,0xe1000000-0xe1003fff at device 9.2 on pci0 fwohci0: Reserved 0x800 bytes for rid 0x10 type 3 at 0xe1800000 pcib0: matched entry for 0.9.INTB pcib0: slot 9 INTB hardwired to IRQ 16 fwohci0: [MPSAFE] fwohci0: OHCI version 1.10 (ROM=0) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 00:02:3c:00:21:04:f5:d7 fwohci0: Phy 1394a available S400, 2 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 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) atapci1: port 0xa000-0xa03f,0x9800-0x980f,0x9400-0x947f mem 0xe0800000-0xe0800fff,0xe0000000-0xe001ffff irq 17 at device 11.0 on pci0 atapci1: rid 0x20 is memory, requested 4 atapci1: Reserved 0x20000 bytes for rid 0x20 type 3 at 0xe0000000 atapci1: Reserved 0x1000 bytes for rid 0x1c type 3 at 0xe0800000 atapci1: [MPSAFE] ata2: on atapci1 ata2: SATA connect ready time=0ms ata2: [MPSAFE] ata3: on atapci1 ata3: SATA connect ready time=0ms ata3: [MPSAFE] ata4: on atapci1 ata4: reset tp1 mask=03 ostat0=60 ostat1=70 ata4: stat0=0x20 err=0x20 lsb=0x20 msb=0x20 ata4: stat1=0x30 err=0x30 lsb=0x30 msb=0x30 ata4: reset tp2 stat0=20 stat1=30 devices=0x0 ata4: [MPSAFE] bktr0: mem 0xe7000000-0xe7000fff at device 13.0 on pci0 bktr0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xe7000000 pcib0: matched entry for 0.13.INTA pcib0: slot 13 INTA hardwired to IRQ 19 bktr0: [GIANT-LOCKED] brooktree0: PCI bus latency is 32. bktr0: buffer size 3555328, addr 0x22000000 bktr0: GPIO is 0x00ffffdb bktr0: subsystem 0x0070 0x13eb bktr0: Hauppauge Model 44811 D123 bktr0: Hauppauge WinCast/TV, Philips FR1236 NTSC FM tuner. pci0: at device 13.1 (no driver attached) pci0:13:1: Transition from D0 to D3 speaker0: port 0x61 on acpi0 sio0: irq maps: 0x8001 0x8011 0x8001 0x8001 sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0067 atkbd: keyboard ID 0x41ab (2) kbd0 at atkbd0 kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 atkbd0: [GIANT-LOCKED] psm0: unable to allocate IRQ ata: ata0 already exists; skipping it ata: ata1 already exists; skipping it atkbdc: atkbdc0 already exists; skipping it sc: sc0 already exists; skipping it sio: sio0 already exists; skipping it vga: vga0 already exists; skipping it pnp_identify: Trying Read_Port at 203 pnp_identify: Trying Read_Port at 243 pnp_identify: Trying Read_Port at 283 pnp_identify: Trying Read_Port at 2c3 pnp_identify: Trying Read_Port at 303 pnp_identify: Trying Read_Port at 343 pnp_identify: Trying Read_Port at 383 pnp_identify: Trying Read_Port at 3c3 PNP Identify complete isa_probe_children: disabling PnP devices isa_probe_children: probing non-PnP devices pmtimer0 on isa0 orm0: at iomem 0xc0000-0xcefff,0xd0000-0xd3fff,0xd4000-0xd7fff on isa0 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 adv0: not probed (disabled) aha0: not probed (disabled) aic0: not probed (disabled) bt0: not probed (disabled) cs0: not probed (disabled) ed0: not probed (disabled) fdc0 failed to probe at port 0x3f0 irq 6 drq 2 on isa0 fe0: not probed (disabled) ie0: not probed (disabled) lnc0: not probed (disabled) ppc0 failed to probe at irq 7 on isa0 sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled sio1: irq maps: 0x8001 0x8001 0x8001 0x8001 sio1: probe failed test(s): 0 1 2 4 6 7 9 sio1 failed to probe at port 0x2f8-0x2ff irq 3 on isa0 sio2: not probed (disabled) sio3: not probed (disabled) sn0: not probed (disabled) vt0: not probed (disabled) isa_probe_children: probing PnP devices ugen0: vendor 0x046d product 0x0810, rev 1.00/1.00, addr 2 ums0: Logitech USB-PS/2 Optical Mouse, rev 2.00/13.00, addr 3, iclass 3/1 ums0: 4 buttons and Z dir. Device configuration finished. linprocfs registered procfs registered lapic: Divisor 2, Frequency 66967568 hz Timecounter "TSC" frequency 937547509 Hz quality -100 Timecounters tick every 1.000 msec Linux ELF exec handler installed pflog0: bpf attached lo0: bpf attached pfsync0: bpf attached (noperiph:sym0:0:-1:-1): SCSI BUS reset delivered. sym0: enabling clock multiplier sym0: Downloading SCSI SCRIPTS. (noperiph:sym1:0:-1:-1): SCSI BUS reset delivered. sym1: enabling clock multiplier sym1: Downloading SCSI SCRIPTS. ata1-slave: pio=PIO4 wdma=WDMA2 udma=UDMA33 cable=40 wire pid 27: corrected slot count (0->1) ata1-master: pio=PIO4 wdma=WDMA2 udma=UDMA66 cable=80 wire acd0: setting PIO4 on VIA 82C686B chip acd0: setting UDMA66 on VIA 82C686B chip acd0: DVDROM drive at ata1 as master acd0: read 6875KB/s (6875KB/s), 256KB buffer, UDMA66 acd0: Reads: CDR, CDRW, CDDA stream, DVDROM, DVDR, packet acd0: Writes: acd0: Audio: play, 256 volume levels acd0: Mechanism: ejectable tray, unlocked acd0: Medium: no/blank disc acd1: setting PIO4 on VIA 82C686B chip acd1: setting UDMA33 on VIA 82C686B chip acd1: CDRW drive at ata1 as slave acd1: read 8250KB/s (8250KB/s) write 172KB/s (8937KB/s), 2048KB buffer, UDMA33 acd1: Reads: CDR, CDRW, CDDA stream, packet acd1: Writes: CDR, CDRW, test write, burnproof acd1: Audio: play, 255 volume levels acd1: Mechanism: ejectable tray, unlocked acd1: Medium: no/blank disc ata0-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire ad4: 114440MB at ata2-master SATA150 ad4: 234375000 sectors [232514C/16H/63S] 16 sectors/interrupt 1 depth queue ad4: Promise check1 failed ad4: Adaptec check1 failed ad4: LSI (v3) check1 failed ad4: LSI (v2) check1 failed ad4: FreeBSD check1 failed ata1-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire ad6: 114440MB at ata3-master SATA150 ad6: 234375000 sectors [232514C/16H/63S] 16 sectors/interrupt 1 depth queue ad6: Promise check1 failed ad6: Adaptec check1 failed ad6: LSI (v3) check1 failed ad6: LSI (v2) check1 failed ad6: FreeBSD check1 failed GEOM: new disk ad4 GEOM: new disk ad6 (probe30:sbp0:0:0:0): error 22 (probe30:sbp0:0:0:0): Unretryable Error (probe32:sbp0:0:2:0): error 22 (probe32:sbp0:0:2:0): Unretryable Error (probe33:sbp0:0:3:0): error 22 (probe33:sbp0:0:3:0): Unretryable Error (probe35:sbp0:0:5:0): error 22 (probe35:sbp0:0:5:0): Unretryable Error (probe31:sbp0:0:1:0): error 22 (probe31:sbp0:0:1:0): Unretryable Error (probe34:sbp0:0:4:0): error 22 (probe34:sbp0:0:4:0): Unretryable Error (probe36:sbp0:0:6:0): error 22 (probe36:sbp0:0:6:0): Unretryable Error (probe0:sym0:0:0:0): Retrying Command pass0 at sym0 bus 0 target 0 lun 0 pass0: Fixed Direct Access SCSI-3 device pass0: Serial Number PVY1T569 pass0: 160.000MB/s transfers (80.000MHz, offset 62, 16bit), Tagged Queueing Enabled GEOM: new disk da0 ATA PseudoRAID loaded SMP: AP CPU #1 Launched! cpu1 AP: ID: 0x00000000 VER: 0x00040011 LDR: 0x01000000 DFR: 0x0fffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000200ef therm: 0x00000000 err: 0x00010000 pcm: 0x00010000 ioapic0: routing intpin 1 (ISA IRQ 1) to cluster 0 ioapic0: routing intpin 4 (ISA IRQ 4) to cluster 0 ioapic0: routing intpin 9 (ISA IRQ 9) to cluster 0 ioapic0: routing intpin 12 (ISA IRQ 12) to cluster 0 ioapic0: routing intpin 13 (ISA IRQ 13) 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 17 (PCI IRQ 17) to cluster 0 ioapic0: routing intpin 19 (PCI IRQ 19) to cluster 0 da0 at sym0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-3 device da0: Serial Number PVY1T569 da0: 160.000MB/s transfers (80.000MHz, offset 62, 16bit), Tagged Queueing Enabled da0: 35003MB (71687340 512 byte sectors: 255H 63S/T 4462C) Trying to mount root from ufs:/dev/da0s1a start_init: trying /sbin/init fxp0: Microcode loaded, int_delay: 1000 usec bundle_max: 6 fxp0: Microcode loaded, int_delay: 1000 usec bundle_max: 6 ipfw2 (+ipv6) initialized, divert loadable, rule-based forwarding disabled, default to deny, logging disabled From owner-freebsd-current@FreeBSD.ORG Sat Apr 30 16:28:50 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 D45C316A4EF; Sat, 30 Apr 2005 16:28:49 +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 j3UGSk7x063267; Sat, 30 Apr 2005 12:28:46 -0400 (EDT) (envelope-from green@green.homeunix.org) Received: (from green@localhost) by green.homeunix.org (8.13.3/8.13.1/Submit) id j3UGSjO5063266; Sat, 30 Apr 2005 12:28:45 -0400 (EDT) (envelope-from green) Date: Sat, 30 Apr 2005 12:28:45 -0400 From: Brian Fundakowski Feldman To: Doug White Message-ID: <20050430162845.GJ39270@green.homeunix.org> References: <20050428053528.G59099@lexi.siliconlandmark.com> <20050428102936.GA89935@uk.tiscali.com> <20050429190711.P85282@carver.gumbysoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050429190711.P85282@carver.gumbysoft.com> User-Agent: Mutt/1.5.6i cc: freebsd-hackers@freebsd.org cc: freebsd-current@freebsd.org cc: Brian Candler Subject: Re: how to set dumpdev X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 30 Apr 2005 16:28:50 -0000 On Fri, Apr 29, 2005 at 07:18:06PM -0700, Doug White wrote: > On Thu, 28 Apr 2005, Brian Candler wrote: > > > On Thu, Apr 28, 2005 at 05:37:16AM -0400, Andre Guibert de Bruet wrote: > > > > i can't use dumpon, since the kernel is panicking on boot, so > > > >tried in loader.conf: > > > > dumpdev="/dev/ar0s1b" > > > >but getting: > > > >db> call doadump > > > >Cannot dump. No dump device defined. > > > >0x25 > > > > > > > >i need this is for current 6.0 > > > >thanks, > > > > danny > > > > > > > > > > That directive, along with dumpdir, would be set in /etc/rc.conf. > > > > According to `man dumpon` (on a 5-STABLE system): > > > > Since dumpon cannot be used during kernel initialization, the dumpdev > > variable of loader(8) must be used to enable dumps for system panics > > which occur during kernel initialization. > > > > But I don't find 'dumpdev' referenced anywhere under /usr/src/sys/boot/. Is > > the documentation wrong? > > It wouldn't be there, but it alos loks like that tunable has gone away > when GEOM took over definign the dump device. Now it needs a struct to > specify the target, and you wouldn't be able to set it until way late in > the boot anyway (when GEOM attaches the disks). Once that point has been reached there's little technical reason that it couldn't automagically pick up a loader environment variable, or by adjustable by a DDB command. Way back when, you could, after having reached the appropriate part of the boot sequence, do something much like: db> show disk/ad0s1b struct cdev *=0xc2f00000 db> w dumpdev In this case, you would presumably be able to do this by booting into DDB early and setting "break execve" to stop right before init is executed. Of course, this method wouldn't be particularly useful if the problem is occurring even before that. The easiest potential location I can think of to stick a tunable would be just before the vfs_mountroot() in start_init(), but then after moving the g_waitidle() from vfs_mountroot() to just before this check in start_init(). -- Brian Fundakowski Feldman \'[ FreeBSD ]''''''''''\ <> green@FreeBSD.org \ The Power to Serve! \ Opinions expressed are my own. \,,,,,,,,,,,,,,,,,,,,,,\ From owner-freebsd-current@FreeBSD.ORG Sat Apr 30 17:22: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 DEAF016A4CE; Sat, 30 Apr 2005 17:22:40 +0000 (GMT) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7A29543D53; Sat, 30 Apr 2005 17:22:40 +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 j3UHMdRF054575; Sat, 30 Apr 2005 13:22:39 -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 j3UHMdt9033575; Sat, 30 Apr 2005 13:22:39 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 77F157306E; Sat, 30 Apr 2005 13:22:39 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050430172239.77F157306E@freebsd-current.sentex.ca> Date: Sat, 30 Apr 2005 13:22:39 -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 alpha/alpha 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, 30 Apr 2005 17:22:41 -0000 TB --- 2005-04-30 17:15:01 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-04-30 17:15:01 - starting CURRENT tinderbox run for alpha/alpha TB --- 2005-04-30 17:15:01 - checking out the source tree TB --- 2005-04-30 17:15:01 - cd /home/tinderbox/CURRENT/alpha/alpha TB --- 2005-04-30 17:15:01 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-04-30 17:21:33 - building world (CFLAGS=-O2 -pipe) TB --- 2005-04-30 17:21:33 - cd /home/tinderbox/CURRENT/alpha/alpha/src TB --- 2005-04-30 17:21:33 - /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 [...] rm -f init init.o init.8.gz init.8.cat.gz rm -f .depend GPATH GRTAGS GSYMS GTAGS ===> sbin/ip6fw (cleandir) rm -f ip6fw ip6fw.o ip6fw.8.gz ip6fw.8.cat.gz rm -f .depend GPATH GRTAGS GSYMS GTAGS ===> sbin/ipf (cleandir) ".depend", line 275: Inconsistent operator for ipf make: fatal errors encountered -- cannot continue *** Error code 1 Stop in /tinderbox/CURRENT/alpha/alpha/src/sbin. *** Error code 1 Stop in /tinderbox/CURRENT/alpha/alpha/src. *** Error code 1 Stop in /tinderbox/CURRENT/alpha/alpha/src. *** Error code 1 Stop in /tinderbox/CURRENT/alpha/alpha/src. TB --- 2005-04-30 17:22:39 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-04-30 17:22:39 - ERROR: failed to build world TB --- 2005-04-30 17:22:39 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Sat Apr 30 17:26: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 62BDF16A4CE; Sat, 30 Apr 2005 17:26:19 +0000 (GMT) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id F29CC43D41; Sat, 30 Apr 2005 17:26:18 +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 j3UHQISC054694; Sat, 30 Apr 2005 13:26: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 j3UHQI1Q050359; Sat, 30 Apr 2005 13:26:18 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 6E98E7306E; Sat, 30 Apr 2005 13:26:18 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050430172618.6E98E7306E@freebsd-current.sentex.ca> Date: Sat, 30 Apr 2005 13:26:18 -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: Sat, 30 Apr 2005 17:26:19 -0000 TB --- 2005-04-30 17:22:39 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-04-30 17:22:39 - starting CURRENT tinderbox run for amd64/amd64 TB --- 2005-04-30 17:22:39 - checking out the source tree TB --- 2005-04-30 17:22:39 - cd /home/tinderbox/CURRENT/amd64/amd64 TB --- 2005-04-30 17:22:39 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-04-30 17:25:11 - building world (CFLAGS=-O2 -pipe) TB --- 2005-04-30 17:25:11 - cd /home/tinderbox/CURRENT/amd64/amd64/src TB --- 2005-04-30 17:25:11 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree [...] rm -f init init.o init.8.gz init.8.cat.gz rm -f .depend GPATH GRTAGS GSYMS GTAGS ===> sbin/ip6fw (cleandir) rm -f ip6fw ip6fw.o ip6fw.8.gz ip6fw.8.cat.gz rm -f .depend GPATH GRTAGS GSYMS GTAGS ===> sbin/ipf (cleandir) ".depend", line 269: Inconsistent operator for ipf make: fatal errors encountered -- cannot continue *** Error code 1 Stop in /tinderbox/CURRENT/amd64/amd64/src/sbin. *** 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-30 17:26:18 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-04-30 17:26:18 - ERROR: failed to build world TB --- 2005-04-30 17:26:18 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Sat Apr 30 18:18: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 5039316A4CE for ; Sat, 30 Apr 2005 18:18: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 52CBC43D6B for ; Sat, 30 Apr 2005 18:18:40 +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 j3UIGs1F051710; Sat, 30 Apr 2005 20:16:54 +0200 (CEST) (envelope-from sos@DeepCore.dk) Message-ID: <4273CB88.9000808@DeepCore.dk> Date: Sat, 30 Apr 2005 20:16:40 +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: jondoor@udor.net References: <4272AFC6.2040907@udor.net> <4273441E.5000609@DeepCore.dk> <4273B234.8070808@udor.net> In-Reply-To: <4273B234.8070808@udor.net> Content-Type: multipart/mixed; boundary="------------060807050509090409010303" X-mail-scanned: by DeepCore Virus & Spam killer v1.12 cc: freebsd-current@freebsd.org Subject: Re: ATA RAID -- Promise SATA150 vanished /dev/ar0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 30 Apr 2005 18:18:41 -0000 This is a multi-part message in MIME format. --------------060807050509090409010303 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Jon Door wrote: > Using the BIOS. The Fasttrak reports the array as functional during=20 > boot, and returning to a 5.4 kernel allows me to mount the volume=20 > without incident. > Thanks! >=20 > It looks like its not getting any metadata persiod, cut from the dmesg:= >=20 > ata0-master: pio=3DPIO4 wdma=3DWDMA2 udma=3DUDMA133 cable=3D40 wire > ad4: 114440MB at ata2-master SATA150 > ad4: 234375000 sectors [232514C/16H/63S] 16 sectors/interrupt 1 depth q= ueue > ad4: Promise check1 failed > ad4: Adaptec check1 failed > ad4: LSI (v3) check1 failed > ad4: LSI (v2) check1 failed > ad4: FreeBSD check1 failed > ata1-master: pio=3DPIO4 wdma=3DWDMA2 udma=3DUDMA133 cable=3D40 wire > ad6: 114440MB at ata3-master SATA150 > ad6: 234375000 sectors [232514C/16H/63S] 16 sectors/interrupt 1 depth q= ueue > ad6: Promise check1 failed > ad6: Adaptec check1 failed > ad6: LSI (v3) check1 failed > ad6: LSI (v2) check1 failed > ad6: FreeBSD check1 failed OK, I think we are looking at the wrong place for the metadata, I think=20 I messed up and made the calculation too simple :) Try this patch: --=20 -S=F8ren --------------060807050509090409010303 Content-Type: text/plain; name="jon-p1" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="jon-p1" Index: ata-raid.h =================================================================== RCS file: /home/ncvs/src/sys/dev/ata/ata-raid.h,v retrieving revision 1.32 diff -u -r1.32 ata-raid.h --- ata-raid.h 30 Apr 2005 16:22:07 -0000 1.32 +++ ata-raid.h 30 Apr 2005 18:16:22 -0000 @@ -521,8 +521,13 @@ /* Promise FastTrak Metadata */ +#if 0 #define PR_LBA(dev) \ (((struct ad_softc *)device_get_ivars(dev))->total_secs - 63) +#else +#define PR_LBA(dev) \ + (((((struct ad_softc *)device_get_ivars(dev))->total_secs / (((struct ad_softc *)device_get_ivars(dev))->heads * ((struct ad_softc *)device_get_ivars(dev))->sectors)) * ((struct ad_softc *)device_get_ivars(dev))->heads * ((struct ad_softc *)device_get_ivars(dev))->sectors) - ((struct ad_softc *)device_get_ivars(dev))->sectors) +#endif struct promise_raid_conf { char promise_id[24]; --------------060807050509090409010303-- From owner-freebsd-current@FreeBSD.ORG Sat Apr 30 19:55: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 5F9DD16A4CE for ; Sat, 30 Apr 2005 19:55:35 +0000 (GMT) Received: from mail.mercenarylabs.com (ns1.mercenarylabs.com [12.158.191.94]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9BAD643D2D for ; Sat, 30 Apr 2005 19:55:34 +0000 (GMT) (envelope-from jondoor@udor.net) Received: from [127.0.0.1] (wilson [12.158.191.94]) by mail.mercenarylabs.com (Postfix) with ESMTP id 01366AD17; Sat, 30 Apr 2005 14:55:19 -0500 (CDT) Message-ID: <4273E2A3.5080300@udor.net> Date: Sat, 30 Apr 2005 15:55:15 -0400 From: Jon Door User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050326) X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?S=F8ren_Schmidt?= , freebsd-current@freebsd.org References: <4272AFC6.2040907@udor.net> <4273441E.5000609@DeepCore.dk> <4273B234.8070808@udor.net> <4273CB88.9000808@DeepCore.dk> In-Reply-To: <4273CB88.9000808@DeepCore.dk> X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: ATA RAID -- Promise SATA150 vanished /dev/ar0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: jondoor@udor.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Apr 2005 19:55:35 -0000 Søren Schmidt wrote: > Jon Door wrote: > >> Using the BIOS. The Fasttrak reports the array as functional during >> boot, and returning to a 5.4 kernel allows me to mount the volume >> without incident. >> Thanks! >> >> It looks like its not getting any metadata persiod, cut from the dmesg: >> >> ata0-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire >> ad4: 114440MB at ata2-master SATA150 >> ad4: 234375000 sectors [232514C/16H/63S] 16 sectors/interrupt 1 depth >> queue >> ad4: Promise check1 failed >> ad4: Adaptec check1 failed >> ad4: LSI (v3) check1 failed >> ad4: LSI (v2) check1 failed >> ad4: FreeBSD check1 failed >> ata1-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire >> ad6: 114440MB at ata3-master SATA150 >> ad6: 234375000 sectors [232514C/16H/63S] 16 sectors/interrupt 1 depth >> queue >> ad6: Promise check1 failed >> ad6: Adaptec check1 failed >> ad6: LSI (v3) check1 failed >> ad6: LSI (v2) check1 failed >> ad6: FreeBSD check1 failed > > > OK, I think we are looking at the wrong place for the metadata, I > think I messed up and made the calculation too simple :) > > Try this patch: > >------------------------------------------------------------------------ > >Index: ata-raid.h >=================================================================== >RCS file: /home/ncvs/src/sys/dev/ata/ata-raid.h,v >retrieving revision 1.32 >diff -u -r1.32 ata-raid.h >--- ata-raid.h 30 Apr 2005 16:22:07 -0000 1.32 >+++ ata-raid.h 30 Apr 2005 18:16:22 -0000 >@@ -521,8 +521,13 @@ > > > /* Promise FastTrak Metadata */ >+#if 0 > #define PR_LBA(dev) \ > (((struct ad_softc *)device_get_ivars(dev))->total_secs - 63) >+#else >+#define PR_LBA(dev) \ >+ (((((struct ad_softc *)device_get_ivars(dev))->total_secs / (((struct ad_softc *)device_get_ivars(dev))->heads * ((struct ad_softc *)device_get_ivars(dev))->sectors)) * ((struct ad_softc *)device_get_ivars(dev))->heads * ((struct ad_softc *)device_get_ivars(dev))->sectors) - ((struct ad_softc *)device_get_ivars(dev))->sectors) >+#endif > > struct promise_raid_conf { > char promise_id[24]; > > That seems to have worked perfectly. Thank You. Here is the new dmesg in case you are interested to see the affect the patch had: pci_link2: irq 12 on acpi0 pci_link2: Links after initial probe: Index IRQ Rtd Ref IRQs 0 12 N 0 3 4 5 6 7 9 10 11 12 14 15 pci_link2: Links after initial validation: Index IRQ Rtd Ref IRQs 0 12 N 0 3 4 5 6 7 9 10 11 12 14 15 pci_link2: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 6 7 9 10 11 12 14 15 pci_link3: irq 3 on acpi0 pci_link3: Links after initial probe: Index IRQ Rtd Ref IRQs 0 3 N 0 3 4 5 6 7 9 10 11 12 14 15 pci_link3: Links after initial validation: Index IRQ Rtd Ref IRQs 0 3 N 0 3 4 5 6 7 9 10 11 12 14 15 pci_link3: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 6 7 9 10 11 12 14 15 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: bus 0 dev 4 func 0 ACPI timer: 0/3 1/2 0/3 1/2 0/3 1/1 0/3 1/2 1/2 1/2 -> 6 Timecounter "ACPI-safe" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0xe408-0xe40b on acpi0 cpu0: on acpi0 cpu1: on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: physical bus=0 found-> vendor=0x1106, dev=0x0691, revid=0xc4 bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x2210, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) powerspec 2 supports D0 D3 current D0 map[10]: type 3, range 32, base f0000000, size 27, enabled found-> vendor=0x1106, dev=0x8598, revid=0x00 bus=0, slot=1, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0007, statreg=0x2230, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x08 (2000 ns), maxlat=0x00 (0 ns) found-> vendor=0x1106, dev=0x0686, revid=0x40 bus=0, slot=4, func=0 class=06-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x0087, statreg=0x0210, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) powerspec 2 supports D0 D3 current D0 found-> vendor=0x1106, dev=0x0571, revid=0x06 bus=0, slot=4, func=1 class=01-01-8a, hdrtype=0x00, mfdev=0 cmdreg=0x0087, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) powerspec 2 supports D0 D3 current D0 map[20]: type 4, range 32, base 0000d800, size 4, enabled found-> vendor=0x1106, dev=0x3038, revid=0x16 bus=0, slot=4, func=2 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0017, statreg=0x0210, cachelnsz=8 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=d, irq=12 powerspec 2 supports D0 D3 current D0 map[20]: type 4, range 32, base 0000d400, size 5, enabled pcib0: matched entry for 0.4.INTD (src \\_SB_.LNKC:0) ioapic0: Changing trigger for pin 12 to level ioapic0: Changing polarity for pin 12 to low pcib0: slot 4 INTD routed to irq 12 via \\_SB_.LNKC found-> vendor=0x1106, dev=0x3038, revid=0x16 bus=0, slot=4, func=3 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0017, statreg=0x0210, cachelnsz=8 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=d, irq=12 powerspec 2 supports D0 D3 current D0 map[20]: type 4, range 32, base 0000d000, size 5, enabled pcib0: matched entry for 0.4.INTD (src \\_SB_.LNKC:0) pcib0: slot 4 INTD routed to irq 12 via \\_SB_.LNKC found-> vendor=0x1106, dev=0x3057, revid=0x40 bus=0, slot=4, func=4 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0000, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) powerspec 2 supports D0 D3 current D0 found-> vendor=0x8086, dev=0x1229, revid=0x08 bus=0, slot=7, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0014, statreg=0x0290, cachelnsz=8 (dwords) lattimer=0x20 (960 ns), mingnt=0x08 (2000 ns), maxlat=0x38 (14000 ns) intpin=a, irq=255 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 1, range 32, base e4800000, size 12, memory disabled map[14]: type 4, range 32, base 0000b800, size 6, port disabled map[18]: type 1, range 32, base e4000000, size 20, enabled found-> vendor=0x1000, dev=0x0020, revid=0x01 bus=0, slot=8, func=0 class=01-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0017, statreg=0x0210, cachelnsz=8 (dwords) lattimer=0x48 (2160 ns), mingnt=0x11 (4250 ns), maxlat=0x12 (4500 ns) intpin=a, irq=3 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 4, range 32, base 0000b400, size 8, enabled map[14]: type 1, range 64, base e3800000, size 10, enabled map[1c]: type 1, range 64, base e3000000, size 13, enabled pcib0: matched entry for 0.8.INTA pcib0: slot 8 INTA hardwired to IRQ 19 found-> vendor=0x1000, dev=0x0020, revid=0x01 bus=0, slot=8, func=1 class=01-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0017, statreg=0x0210, cachelnsz=8 (dwords) lattimer=0x48 (2160 ns), mingnt=0x11 (4250 ns), maxlat=0x12 (4500 ns) intpin=b, irq=11 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 4, range 32, base 0000b000, size 8, enabled map[14]: type 1, range 64, base e2800000, size 10, enabled map[1c]: type 1, range 64, base e2000000, size 13, enabled pcib0: matched entry for 0.8.INTB pcib0: slot 8 INTB hardwired to IRQ 16 found-> vendor=0x1102, dev=0x0004, revid=0x03 bus=0, slot=9, func=0 class=04-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x0004, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x02 (500 ns), maxlat=0x14 (5000 ns) intpin=a, irq=255 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 4, range 32, base 0000a800, size 5, port disabled found-> vendor=0x1102, dev=0x7003, revid=0x03 bus=0, slot=9, func=1 class=09-80-00, hdrtype=0x00, mfdev=1 cmdreg=0x0004, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 4, range 32, base 0000a400, size 3, port disabled found-> vendor=0x1102, dev=0x4001, revid=0x00 bus=0, slot=9, func=2 class=0c-00-10, hdrtype=0x00, mfdev=1 cmdreg=0x0014, statreg=0x0210, cachelnsz=8 (dwords) lattimer=0x20 (960 ns), mingnt=0x02 (500 ns), maxlat=0x04 (1000 ns) intpin=b, irq=255 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 1, range 32, base e1800000, size 11, memory disabled map[14]: type 1, range 32, base e1000000, size 14, enabled found-> vendor=0x105a, dev=0x3371, revid=0x02 bus=0, slot=11, func=0 class=01-04-00, hdrtype=0x00, mfdev=0 cmdreg=0x0017, statreg=0x0230, cachelnsz=144 (dwords) lattimer=0x60 (2880 ns), mingnt=0x04 (1000 ns), maxlat=0x12 (4500 ns) intpin=a, irq=10 powerspec 2 supports D0 D1 D3 current D0 map[10]: type 4, range 32, base 0000a000, size 6, enabled map[14]: type 4, range 32, base 00009800, size 4, enabled map[18]: type 4, range 32, base 00009400, size 7, enabled map[1c]: type 1, range 32, base e0800000, size 12, enabled map[20]: type 1, range 32, base e0000000, size 17, enabled pcib0: matched entry for 0.11.INTA pcib0: slot 11 INTA hardwired to IRQ 17 found-> vendor=0x109e, dev=0x036e, revid=0x11 bus=0, slot=13, func=0 class=04-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0004, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x10 (4000 ns), maxlat=0x28 (10000 ns) intpin=a, irq=255 powerspec 2 supports D0 D3 current D0 map[10]: type 3, range 32, base e7000000, size 12, memory disabled found-> vendor=0x109e, dev=0x0878, revid=0x11 bus=0, slot=13, func=1 class=04-80-00, hdrtype=0x00, mfdev=1 cmdreg=0x0004, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x04 (1000 ns), maxlat=0xff (63750 ns) intpin=a, irq=255 powerspec 2 supports D0 D3 current D0 map[10]: type 3, range 32, base e6800000, size 12, memory disabled agp0: mem 0xf0000000-0xf7ffffff at device 0.0 on pci0 agp0: Reserved 0x8000000 bytes for rid 0x10 type 3 at 0xf0000000 agp0: allocating GATT for aperture of size 256M pcib1: at device 1.0 on pci0 pcib1: secondary bus 1 pcib1: subordinate bus 1 pcib1: I/O decode 0xe000-0xdfff pcib1: memory decode 0xe5000000-0xe67fffff pcib1: prefetched decode 0xe7f00000-0xefffffff pci1: on pcib1 pci1: physical bus=1 found-> vendor=0x10de, dev=0x0322, revid=0xa1 bus=1, slot=0, func=0 class=03-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x02b0, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x05 (1250 ns), maxlat=0x01 (250 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 map[10]: type 1, range 32, base e5000000, size 24, enabled pcib1: (null) requested memory range 0xe5000000-0xe5ffffff: good map[14]: type 3, range 32, base e8000000, size 27, enabled pcib1: (null) requested memory range 0xe8000000-0xefffffff: good pcib1: matched entry for 1.0.INTA pcib1: slot 0 INTA hardwired to IRQ 16 nvidia0: mem 0xe5000000-0xe5ffffff,0xe8000000-0xefffffff irq 16 at device 0.0 on pci1 nvidia0: Reserved 0x1000000 bytes for rid 0x10 type 3 at 0xe5000000 nvidia0: Reserved 0x8000000 bytes for rid 0x14 type 3 at 0xe8000000 nvidia0: [GIANT-LOCKED] isab0: at device 4.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xd800-0xd80f at device 4.1 on pci0 atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0xd800 ata0: on atapci0 atapci0: Reserved 0x8 bytes for rid 0x10 type 4 at 0x1f0 atapci0: Reserved 0x1 bytes for rid 0x14 type 4 at 0x3f6 ata0: reset tp1 mask=03 ostat0=e0 ostat1=f0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata0: stat1=0xb0 err=0xb0 lsb=0xb0 msb=0xb0 ata0: reset tp2 stat0=a0 stat1=b0 devices=0x0 ata0: [MPSAFE] ata1: on atapci0 atapci0: Reserved 0x8 bytes for rid 0x18 type 4 at 0x170 atapci0: Reserved 0x1 bytes for rid 0x1c type 4 at 0x376 ata1: reset tp1 mask=03 ostat0=50 ostat1=50 ata1: stat0=0x80 err=0x80 lsb=0x80 msb=0x80 ata1: stat0=0x80 err=0x80 lsb=0x80 msb=0x80 ata1: stat0=0x00 err=0x01 lsb=0x14 msb=0xeb ata1: stat1=0x00 err=0x01 lsb=0x14 msb=0xeb ata1: reset tp2 stat0=00 stat1=00 devices=0xc ata1: [MPSAFE] uhci0: port 0xd400-0xd41f irq 12 at device 4.2 on pci0 uhci0: Reserved 0x20 bytes for rid 0x20 type 4 at 0xd400 uhci0: [GIANT-LOCKED] usb0: on uhci0 usb0: USB revision 1.0 uhub0: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1: port 0xd000-0xd01f irq 12 at device 4.3 on pci0 uhci1: Reserved 0x20 bytes for rid 0x20 type 4 at 0xd000 uhci1: [GIANT-LOCKED] usb1: on uhci1 usb1: USB revision 1.0 uhub1: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered fxp0: port 0xb800-0xb83f mem 0xe4800000-0xe4800fff,0xe4000000-0xe40fffff at device 7.0 on pci0 fxp0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xe4800000 fxp0: using memory space register mapping pcib0: matched entry for 0.7.INTA pcib0: slot 7 INTA hardwired to IRQ 17 fxp0: PCI IDs: 8086 1229 8086 000c 0008 fxp0: Dynamic Standby mode is disabled miibus0: on fxp0 inphy0: on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp0: bpf attached fxp0: Ethernet address: 00:00:00:00:00:00 fxp0: [MPSAFE] sym0: <1010-33> port 0xb400-0xb4ff mem 0xe3800000-0xe38003ff,0xe3000000-0xe3001fff irq 19 at device 8.0 on pci0 sym0: Reserved 0x400 bytes for rid 0x14 type 3 at 0xe3800000 sym0: Reserved 0x2000 bytes for rid 0x1c type 3 at 0xe3000000 sym0: Symbios NVRAM, ID 7, Fast-80, LVD, parity checking sym0: open drain IRQ line driver, using on-chip SRAM sym0: using LOAD/STORE-based firmware. sym0: handling phase mismatch from SCRIPTS. sym0: initial SCNTL3/DMODE/DCNTL/CTEST3/4/5 = (hex) 00/4e/a0/01/00/04 sym0: final SCNTL3/DMODE/DCNTL/CTEST3/4/5 = (hex) 00/4e/80/01/08/04 sym0: [GIANT-LOCKED] sym0: enabling clock multiplier sym0: Downloading SCSI SCRIPTS. sym1: <1010-33> port 0xb000-0xb0ff mem 0xe2800000-0xe28003ff,0xe2000000-0xe2001fff irq 16 at device 8.1 on pci0 sym1: Reserved 0x400 bytes for rid 0x14 type 3 at 0xe2800000 sym1: Reserved 0x2000 bytes for rid 0x1c type 3 at 0xe2000000 sym1: Symbios NVRAM, ID 7, Fast-80, LVD, parity checking sym1: open drain IRQ line driver, using on-chip SRAM sym1: using LOAD/STORE-based firmware. sym1: handling phase mismatch from SCRIPTS. sym1: initial SCNTL3/DMODE/DCNTL/CTEST3/4/5 = (hex) 00/4e/a0/01/00/04 sym1: final SCNTL3/DMODE/DCNTL/CTEST3/4/5 = (hex) 00/4e/80/01/08/04 sym1: [GIANT-LOCKED] sym1: enabling clock multiplier sym1: Downloading SCSI SCRIPTS. pcm0: port 0xa800-0xa81f at device 9.0 on pci0 pcm0: Reserved 0x20 bytes for rid 0x10 type 4 at 0xa800 emu: setmap (249000, 800), nseg=1, error=0 emu: setmap (24b000, 1000), nseg=1, error=0 pcm0: pcm0: Codec features 5 bit master volume, no 3D Stereo Enhancement pcib0: matched entry for 0.9.INTA pcib0: slot 9 INTA hardwired to IRQ 19 pcm0: [MPSAFE] emu: setmap (2dd000, 1000), nseg=1, error=0 emu: setmap (29b000, 1000), nseg=1, error=0 emu: setmap (219000, 1000), nseg=1, error=0 emu: setmap (26ed7000, 1000), nseg=1, error=0 emu: setmap (26ed5000, 1000), nseg=1, error=0 emu: setmap (26ed3000, 1000), nseg=1, error=0 emu: setmap (26e91000, 1000), nseg=1, error=0 emu: setmap (2b0000, 1000), nseg=1, error=0 pcm0: sndbuf_setmap 2ae000, 1000; 0xc21da000 -> 2ae000 pcm0: sndbuf_setmap 26c000, 1000; 0xc21d8000 -> 26c000 fwohci0: vendor=1102, dev=4001 fwohci0: vendor=1102, dev=4001 fwohci0: <1394 Open Host Controller Interface> mem 0xe1800000-0xe18007ff,0xe1000000-0xe1003fff at device 9.2 on pci0 fwohci0: Reserved 0x800 bytes for rid 0x10 type 3 at 0xe1800000 pcib0: matched entry for 0.9.INTB pcib0: slot 9 INTB hardwired to IRQ 16 fwohci0: [MPSAFE] fwohci0: OHCI version 1.10 (ROM=0) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 00:02:3c:00:21:04:f5:d7 fwohci0: Phy 1394a available S400, 2 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 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) atapci1: port 0xa000-0xa03f,0x9800-0x980f,0x9400-0x947f mem 0xe0800000-0xe0800fff,0xe0000000-0xe001ffff irq 17 at device 11.0 on pci0 atapci1: rid 0x20 is memory, requested 4 atapci1: Reserved 0x20000 bytes for rid 0x20 type 3 at 0xe0000000 atapci1: Reserved 0x1000 bytes for rid 0x1c type 3 at 0xe0800000 atapci1: [MPSAFE] ata2: on atapci1 ata2: SATA connect ready time=0ms ata2: [MPSAFE] ata3: on atapci1 ata3: SATA connect ready time=0ms ata3: [MPSAFE] ata4: on atapci1 ata4: reset tp1 mask=03 ostat0=60 ostat1=70 ata4: stat0=0x20 err=0x20 lsb=0x20 msb=0x20 ata4: stat1=0x30 err=0x30 lsb=0x30 msb=0x30 ata4: reset tp2 stat0=20 stat1=30 devices=0x0 ata4: [MPSAFE] bktr0: mem 0xe7000000-0xe7000fff at device 13.0 on pci0 bktr0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xe7000000 pcib0: matched entry for 0.13.INTA pcib0: slot 13 INTA hardwired to IRQ 19 bktr0: [GIANT-LOCKED] brooktree0: PCI bus latency is 32. bktr0: buffer size 3555328, addr 0x22000000 bktr0: GPIO is 0x00ffffdb bktr0: subsystem 0x0070 0x13eb bktr0: Hauppauge Model 44811 D123 bktr0: Hauppauge WinCast/TV, Philips FR1236 NTSC FM tuner. pci0: at device 13.1 (no driver attached) pci0:13:1: Transition from D0 to D3 speaker0: port 0x61 on acpi0 sio0: irq maps: 0x8001 0x8011 0x8001 0x8001 sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0067 atkbd: keyboard ID 0x41ab (2) kbd0 at atkbd0 kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 atkbd0: [GIANT-LOCKED] psm0: unable to allocate IRQ ata: ata0 already exists; skipping it ata: ata1 already exists; skipping it atkbdc: atkbdc0 already exists; skipping it sc: sc0 already exists; skipping it sio: sio0 already exists; skipping it vga: vga0 already exists; skipping it pnp_identify: Trying Read_Port at 203 pnp_identify: Trying Read_Port at 243 pnp_identify: Trying Read_Port at 283 pnp_identify: Trying Read_Port at 2c3 pnp_identify: Trying Read_Port at 303 pnp_identify: Trying Read_Port at 343 pnp_identify: Trying Read_Port at 383 pnp_identify: Trying Read_Port at 3c3 PNP Identify complete isa_probe_children: disabling PnP devices isa_probe_children: probing non-PnP devices pmtimer0 on isa0 orm0: at iomem 0xc0000-0xcefff,0xd0000-0xd3fff,0xd4000-0xd7fff on isa0 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 adv0: not probed (disabled) aha0: not probed (disabled) aic0: not probed (disabled) bt0: not probed (disabled) cs0: not probed (disabled) ed0: not probed (disabled) fdc0 failed to probe at port 0x3f0 irq 6 drq 2 on isa0 fe0: not probed (disabled) ie0: not probed (disabled) lnc0: not probed (disabled) ppc0 failed to probe at irq 7 on isa0 sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled sio1: irq maps: 0x8001 0x8001 0x8001 0x8001 sio1: probe failed test(s): 0 1 2 4 6 7 9 sio1 failed to probe at port 0x2f8-0x2ff irq 3 on isa0 sio2: not probed (disabled) sio3: not probed (disabled) sn0: not probed (disabled) vt0: not probed (disabled) isa_probe_children: probing PnP devices ugen0: vendor 0x047e product 0x1001, rev 1.00/1.04, addr 2 ums0: Logitech USB-PS/2 Optical Mouse, rev 2.00/13.00, addr 3, iclass 3/1 ums0: 4 buttons and Z dir. Device configuration finished. linprocfs registered procfs registered lapic: Divisor 2, Frequency 66967643 hz Timecounter "TSC" frequency 937549760 Hz quality -100 Timecounters tick every 1.000 msec Linux ELF exec handler installed lo0: bpf attached (noperiph:sym0:0:-1:-1): SCSI BUS reset delivered. sym0: enabling clock multiplier sym0: Downloading SCSI SCRIPTS. (noperiph:sym1:0:-1:-1): SCSI BUS reset delivered. sym1: enabling clock multiplier sym1: Downloading SCSI SCRIPTS. ata1-slave: pio=PIO4 wdma=WDMA2 udma=UDMA33 cable=40 wire pid 27: corrected slot count (0->1) ata1-master: pio=PIO4 wdma=WDMA2 udma=UDMA66 cable=80 wire acd0: setting PIO4 on VIA 82C686B chip acd0: setting UDMA66 on VIA 82C686B chip acd0: DVDROM drive at ata1 as master acd0: read 6875KB/s (6875KB/s), 256KB buffer, UDMA66 acd0: Reads: CDR, CDRW, CDDA stream, DVDROM, DVDR, packet acd0: Writes: acd0: Audio: play, 256 volume levels acd0: Mechanism: ejectable tray, unlocked acd0: Medium: no/blank disc acd1: setting PIO4 on VIA 82C686B chip acd1: setting UDMA33 on VIA 82C686B chip acd1: CDRW drive at ata1 as slave acd1: read 8250KB/s (8250KB/s) write 172KB/s (8937KB/s), 2048KB buffer, UDMA33 acd1: Reads: CDR, CDRW, CDDA stream, packet acd1: Writes: CDR, CDRW, test write, burnproof acd1: Audio: play, 255 volume levels acd1: Mechanism: ejectable tray, unlocked acd1: Medium: no/blank disc ata0-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire ad4: 114440MB at ata2-master SATA150 ad4: 234375000 sectors [232514C/16H/63S] 16 sectors/interrupt 1 depth queue ********* ATA Promise FastTrak Metadata ********* promise_id dummy_0 0x00020000 magic_0 0x0000000000900101 magic_1 0x1102 magic_2 0x000005a5 integrity 0x00000080 80 flags 0x07 7 disk_number 0 channel 0x00 device 0x00 magic_0 0x0000000000900101 disk_offset 3991859184 disk_sectors 234374049 rebuild_lba 0xffffffff generation 0x0002 status 0x0f f type RAID0 total_disks 2 stripe_shift 7 array_width 2 array_number 0 total_sectors 468748032 cylinders 29177 heads 254 sectors 63 magic_1 0x0000000005a51102 DISK# flags dummy_0 channel device magic_0 0 7 0x00 0x00 0x00 0x0000000000900101 1 7 0x00 0x01 0x00 0x0001000000910101 2 0 0x00 0x00 0x00 0x0000000000000000 3 0 0x00 0x00 0x00 0x0000000000000000 4 0 0x00 0x00 0x00 0x0000000000000000 5 0 0x00 0x00 0x00 0x0000000000000000 6 0 0x00 0x00 0x00 0x0000000000000000 7 0 0x00 0x00 0x00 0x0000000000000000 checksum 0xb974aa08 ================================================= ata1-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire ad6: 114440MB at ata3-master SATA150 ad6: 234375000 sectors [232514C/16H/63S] 16 sectors/interrupt 1 depth queue ********* ATA Promise FastTrak Metadata ********* promise_id dummy_0 0x00020000 magic_0 0x0001000000910101 magic_1 0x1102 magic_2 0x000005a5 integrity 0x00000080 80 flags 0x07 7 disk_number 1 channel 0x01 device 0x00 magic_0 0x0001000000910101 disk_offset 3991859184 disk_sectors 234374049 rebuild_lba 0xffffffff generation 0x0002 status 0x0f f type RAID0 total_disks 2 stripe_shift 7 array_width 2 array_number 0 total_sectors 468748032 cylinders 29177 heads 254 sectors 63 magic_1 0x0000000005a51102 DISK# flags dummy_0 channel device magic_0 0 7 0x00 0x00 0x00 0x0000000000900101 1 7 0x00 0x01 0x00 0x0001000000910101 2 0 0x00 0x00 0x00 0x0000000000000000 3 0 0x00 0x00 0x00 0x0000000000000000 4 0 0x00 0x00 0x00 0x0000000000000000 5 0 0x00 0x00 0x00 0x0000000000000000 6 0 0x00 0x00 0x00 0x0000000000000000 7 0 0x00 0x00 0x00 0x0000000000000000 checksum 0xb979ab08 ================================================= GEOM: new disk ad4 GEOM: new disk ad6 (probe32:sbp0:0:2:0): error 22 (probe32:sbp0:0:2:0): Unretryable Error (probe34:sbp0:0:4:0): error 22 (probe34:sbp0:0:4:0): Unretryable Error (probe30:sbp0:0:0:0): error 22 (probe30:sbp0:0:0:0): Unretryable Error (probe31:sbp0:0:1:0): error 22 (probe31:sbp0:0:1:0): Unretryable Error (probe33:sbp0:0:3:0): error 22 (probe33:sbp0:0:3:0): Unretryable Error (probe35:sbp0:0:5:0): error 22 (probe35:sbp0:0:5:0): Unretryable Error (probe36:sbp0:0:6:0): error 22 (probe36:sbp0:0:6:0): Unretryable Error (probe0:sym0:0:0:0): Retrying Command pass0 at sym0 bus 0 target 0 lun 0 pass0: Fixed Direct Access SCSI-3 device pass0: Serial Number PVY1T569 pass0: 160.000MB/s transfers (80.000MHz, offset 62, 16bit), Tagged Queueing Enabled GEOM: new disk da0 ATA PseudoRAID loaded ********** ATA PseudoRAID ar0 Metadata ********** ================================================= format Promise Fasttrak type RAID0 flags 0x01 1 magic_0 0x0000000000000000 magic_1 0x0000000005a51102 generation 2 total_sectors 468748032 offset_sectors 0 heads 255 sectors 63 cylinders 29178 width 2 interleave 128 total_disks 2 disk 0: flags = 0x0b b ad4: sectors 234374049 disk 1: flags = 0x0b b ad6: sectors 234374049 ================================================= ar0: 228880MB status: READY ar0: 468748032 sectors [29178C/255H/63S] <> subdisks defined as: ar0: disk0 READY using ad4 at ata2-master ar0: disk1 READY using ad6 at ata3-master SMP: AP CPU #1 Launched! cpu1 AP: ID: 0x00000000 VER: 0x00040011 LDR: 0x01000000 DFR: 0x0fffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000200ef therm: 0x00000000 err: 0x00010000 pcm: 0x00010000 ioapic0: routing intpin 1 (ISA IRQ 1) to cluster 0 ioapic0: routing intpin 4 (ISA IRQ 4) to cluster 0 ioapic0: routing intpin 9 (ISA IRQ 9) to cluster 0 ioapic0: routing intpin 12 (ISA IRQ 12) to cluster 0 ioapic0: routing intpin 13 (ISA IRQ 13) 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 17 (PCI IRQ 17) to cluster 0 ioapic0: routing intpin 19 (PCI IRQ 19) to cluster 0 da0 at sym0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-3 device da0: Serial Number PVY1T569 da0: 160.000MB/s transfers (80.000MHz, offset 62, 16bit), Tagged Queueing Enabled da0: 35003MB (71687340 512 byte sectors: 255H 63S/T 4462C) GEOM: new disk ar0 Trying to mount root from ufs:/dev/da0s1a start_init: trying /sbin/init fxp0: Microcode loaded, int_delay: 1000 usec bundle_max: 6 fxp0: Microcode loaded, int_delay: 1000 usec bundle_max: 6 ipfw2 (+ipv6) initialized, divert loadable, rule-based forwarding disabled, default to deny, logging disabled From owner-freebsd-current@FreeBSD.ORG Sat Apr 30 20:11: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 6F69A16A4CE for ; Sat, 30 Apr 2005 20:11:07 +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 335A943D31 for ; Sat, 30 Apr 2005 20:11:07 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 567ED5148A; Sat, 30 Apr 2005 13:11:06 -0700 (PDT) Date: Sat, 30 Apr 2005 13:11:06 -0700 From: Kris Kennaway To: Danny Braniss Message-ID: <20050430201106.GB21340@xor.obsecurity.org> References: <20050430114225.E654@localhost> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="QKdGvSO+nmPlgiQ/" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i cc: freebsd-current@freebsd.org cc: Oleg Sharoiko Subject: Re: diskless/unionfs 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, 30 Apr 2005 20:11:07 -0000 --QKdGvSO+nmPlgiQ/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Did Jeff's fixes committed the other day help with this? Kris --QKdGvSO+nmPlgiQ/ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFCc+ZZWry0BWjoQKURApuZAKDLUNgUR6qpzLB3Uw3+8HWoCjtBVwCfR5dr Ag/emE0CgRDa598MFe5WP7M= =0eli -----END PGP SIGNATURE----- --QKdGvSO+nmPlgiQ/-- From owner-freebsd-current@FreeBSD.ORG Sat Apr 30 20:40: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 5550F16A4CF for ; Sat, 30 Apr 2005 20:40:02 +0000 (GMT) Received: from smtp.vzavenue.net (smtp.vzavenue.net [66.171.59.140]) by mx1.FreeBSD.org (Postfix) with ESMTP id BDB6243D48 for ; Sat, 30 Apr 2005 20:40:01 +0000 (GMT) (envelope-from jr@opal.com) Received: from linwhf.opal.com (112.79.171.66.subscriber.vzavenue.net [66.171.79.112]) by smtp.vzavenue.net (MOS 3.4.8-GR) with ESMTP id CDN13751; Sat, 30 Apr 2005 16:38:44 -0400 (EDT) Received: from linwhf.opal.com (localhost [127.0.0.1]) by linwhf.opal.com (8.13.3/8.13.1) with ESMTP id j3UKcic8024279 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO) for ; Sat, 30 Apr 2005 16:38:44 -0400 (EDT) (envelope-from jr@linwhf.opal.com) Received: (from jr@localhost) by linwhf.opal.com (8.13.3/8.13.1/Submit) id j3UKciA2024278 for freebsd-current@freebsd.org; Sat, 30 Apr 2005 16:38:44 -0400 (EDT) (envelope-from jr) Date: Sat, 30 Apr 2005 16:38:44 -0400 From: "J.R. Oldroyd" To: freebsd-current@freebsd.org Message-ID: <20050430203844.GA24205@linwhf.opal.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-Junkmail-Status: score=0/50, host=smtp.vzavenue.net Subject: FS prob? df prob? or Infinite Improbability Drive? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 30 Apr 2005 20:40:02 -0000 I've seen stats like this several times recently in the last few months on different filesystems. System is -current of 4/17 and has been up continuously for the 13 days since then. World is also 4/17. Everything was fine until this morning, when: # df /home Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/ad0s1a 253678 220128 13256 94% / devfs 1 1 0 100% /dev /dev/ad0s1d 253678 808 232576 0% /tmp /dev/ad0s1e 507630 74440 392580 16% /var /dev/ad0s1f 253678 42 233342 0% /var/mail /dev/ad0s1g 253678 74 233310 0% /var/spool /dev/ad2s1d 5077038 1356322 3314554 29% /var/www /dev/ad0s1h 32300804 7715462 22001278 26% /usr /dev/ad2s1e 26908468 -54043195503950556 54043195528706348 -218305257630% /home /dev/ad1s1 236514290 191066106 26527042 88% /home/opal procfs 4 4 0 100% /proc Umount/mount clears this and returns the stats to normal. But system is a bit busy at the moment so I can't umount/mount. So I thought I'd try a bg fsck, but no change: # fsck -B /dev/ad2s1e ** /home/.snap/fsck_snapshot ** Last Mounted on /home ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts ** Phase 5 - Check Cyl groups 121770 files, 12247696 used, 1206538 free (55994 frags, 143818 blocks, 0.4% fragmentation) ***** FILE SYSTEM MARKED CLEAN ***** # df /home Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/ad2s1e 26908468 -54043195503950556 54043195528706348 -218305257630% /home Despite this, system seems to be running normally; there are no unusual messages in the log. Any ideas? -jr From owner-freebsd-current@FreeBSD.ORG Sat Apr 30 22:30: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 CD4D916A4D2; Sat, 30 Apr 2005 22:30:08 +0000 (GMT) Received: from mail.chesapeake.net (chesapeake.net [208.142.252.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id 46FE443D2D; Sat, 30 Apr 2005 22:30:08 +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 j3UMTx1h072273; Sat, 30 Apr 2005 18:29:59 -0400 (EDT) (envelope-from jroberson@chesapeake.net) Received: from localhost (jroberson@localhost)j3UMTwfZ072256; Sat, 30 Apr 2005 18:29:58 -0400 (EDT) (envelope-from jroberson@chesapeake.net) X-Authentication-Warning: mail.chesapeake.net: jroberson owned process doing -bs Date: Sat, 30 Apr 2005 18:29:57 -0400 (EDT) From: Jeff Roberson To: Danny Braniss In-Reply-To: Message-ID: <20050430182926.K71837@mail.chesapeake.net> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-current@freebsd.org cc: Oleg Sharoiko Subject: Re: diskless/unionfs 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, 30 Apr 2005 22:30:09 -0000 On Sat, 30 Apr 2005, Danny Braniss wrote: > > Hello! > > > > I've read your recent discussion about unionfs panics on current. I have some > > additional information which can probably help solving this panic. > > Unfortunately I know absolutely nothing about internal details of vfs > > implementation and so I suppose, you'd know better what to do with the > > information I've learned. > > > > 1. I can easily reproduce the panic at any time with the following commands > > (no matter how early in the boot process it happens): > > > > # mount -t unionfs /rescue /mnt > > # /mnt/ls > > > > 2. Panic happens in sys/kern/kern_exec.c line 794 > > > > --- > > int > > exec_map_first_page(imgp) > > struct image_params *imgp; > > { > > int rv, i; > > int initial_pagein; > > vm_page_t ma[VM_INITIAL_PAGEIN]; > > vm_object_t object; > > > > GIANT_REQUIRED; > > > > if (imgp->firstpage != NULL) > > exec_unmap_first_page(imgp); > > > > object = imgp->vp->v_object; > > VM_OBJECT_LOCK(object); // !!! line 794 > > --- > > > > kernel panics because imgp->vp->v_object is NULL Thanks, NULL object is certainly from phk's object rework. I'll fix it though as he seems to be very busy lately. > > > > Before it were the facts, further go my assumptions: > > > > 1. imgp->vp->v_tag is "union" (or "unionfs" don't remember exactly but it > > doesn't matter) so I suppose this vnode was created (? or at least returned) > > by unionfs. > > > > 2. I compared unionfs and nullfs (which seems to be the most close to unionfs > > and doesn't panic on exec). I'll skip the description of comparison process > > and provide the results: > > > > In nullfs the method null_open() (which implements vop_open()) returns vnode > > with v_object not being NULL. This is how it's done (sys/fs/nullfs_vnops.c, > > lines 378-390): > > > > --- > > static int > > null_open(struct vop_open_args *ap) > > { > > int retval; > > struct vnode *vp, *ldvp; > > > > vp = ap->a_vp; > > ldvp = NULLVPTOLOWERVP(vp); > > retval = null_bypass(&ap->a_gen); > > if (retval == 0) > > vp->v_object = ldvp->v_object; > > return (retval); > > } > > --- > > > > As far as I understand v_object is simply copied from vnode of the lower > > level fs. > > > > I added some debugging printf's into union_vnops.c and it looks like > > union_open() leaves v_object unset. Indeed on return from union_open it's > > NULL and it's NULL for exactly that vnode which later panics in > > exec_map_first_page() > > > > I made a very simple patch based on the way nullfs is implemented: > > ----- > > --- union_vnops.c.orig Sat Apr 30 11:36:00 2005 > > +++ union_vnops.c Sat Apr 30 11:36:48 2005 > > @@ -748,6 +748,9 @@ > > if (error == 0) > > error = VOP_OPEN(tvp, mode, cred, td, -1); > > > > + if (error == 0) > > + ap->a_vp->v_object = tvp->v_object; > > + > > /* > > * Release any locks held. > > */ > > ----- > > > > With this patch unionfs doesn't panic on exec. I absolutely not sure about > > this patch. I understand that this may be a wrong patch because as I've > > already said I know nothing about FreeBSD's vm and vfs and relations of their > > objects. But at least this can probably help you solving the problem. > > > > it did! > im now make'ing buildword, and all seems 'back to normal' > > > > > And just a note: I'd also say that unfortunately unionfs still stays very > > unstable. It can easily panic kernel in other parts. I've seen 'locking > > against myself' and other locking panics with and without my patch. That's > > too bad as it's a very nice feature for jails. It if goes this way I'd say it > > would be better to disable it in 6.0 I'd be happy to spend some time fixing it > > we use it to mount ro /etc with an md, then populate it with private stuff, so > for that it seems to fit the bill. > > > but I don't have it now. BTW: could you please suggest anything to read about > > this vnodes, v_objects and other vfs/vm related objects so that I could > > understand their relations and try to dig unionfs in case I have time? > > > apart for sending you to look at the source :-), i guess i'll let others > chip in. > > thanks! > > danny > > > -- > > Oleg Sharoiko. > > Software and Network Engineer > > Computer Center of Rostov State University. > > > _______________________________________________ > 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 Sat Apr 30 23:52: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 A1E4C16A4CE for ; Sat, 30 Apr 2005 23:52:12 +0000 (GMT) Received: from mail-in-03.arcor-online.net (mail-in-03.arcor-online.net [151.189.21.43]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2095243D31 for ; Sat, 30 Apr 2005 23:52:12 +0000 (GMT) (envelope-from lofi@freebsd.org) Received: from mail-in-05-z2.arcor-online.net (mail-in-05-z2.arcor-online.net [151.189.8.17]) by mail-in-03.arcor-online.net (Postfix) with ESMTP id 343546743; Sun, 1 May 2005 01:52:06 +0200 (CEST) Received: from mail-in-03.arcor-online.net (mail-in-03.arcor-online.net [151.189.21.43]) by mail-in-05-z2.arcor-online.net (Postfix) with ESMTP id D242C10921B; Sun, 1 May 2005 01:52:10 +0200 (CEST) Received: from lofi.dyndns.org (dsl-213-023-204-182.arcor-ip.net [213.23.204.182]) by mail-in-03.arcor-online.net (Postfix) with ESMTP id CBA9C6743; Sun, 1 May 2005 01:52:05 +0200 (CEST) Received: from kiste.my.domain (lofi@kiste.my.domain [192.168.8.4]) (authenticated bits=0) by lofi.dyndns.org (8.13.3/8.13.3) with ESMTP id j3UNq6CD043829 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Sun, 1 May 2005 01:52:07 +0200 (CEST) (envelope-from lofi@freebsd.org) From: Michael Nottebrock To: freebsd-current@freebsd.org Date: Sun, 1 May 2005 01:52:04 +0200 User-Agent: KMail/1.8 References: <3121.216.177.243.38.1114856874.localmail@webmail.dnswatch.com> <200504300426.06174.krinklyfig@spymac.com> In-Reply-To: <200504300426.06174.krinklyfig@spymac.com> X-Face: =Ym$`&q\+S2X$4`X%x%6"L4>Y,$]<":'L%c9"#7#`2tb&E&wsN31on!N\)3BD[g<=?utf-8?q?=2EjnfV=5B=0A=093=23?=>XchLK,o;>bD>c:]^;:>0>vyZ.X[,63GW`&M>}nYnr]-Fp``,[[@lJ!QL|sfW!s)=?utf-8?q?A2!*=0A=09vNkB/=7CL-?=>&QdSbQg X-Virus-Scanned: by amavisd-new cc: Joshua Tinnin cc: /dev/null Subject: Re: cleanup-boot.messages+overhaul-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: Sat, 30 Apr 2005 23:52:12 -0000 --nextPart3281398.YVzxxdM7jo Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Saturday, 30. April 2005 13:26, Joshua Tinnin wrote: > Personally, I'd *love* to be able to install KMail without having to > install kdebase and kdelibs, just kdelibs, in fact > not to mention the rest of kdepim, but=20 > trying to convince the KDE project to uncouple it from the rest of the > project is rather like tilting at windmills. It's important to keep in mind that such a KMail would be a different progr= am=20 than it is today, with a different (considerably smaller) feature set. =2D-=20 ,_, | Michael Nottebrock | lofi@freebsd.org (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org --nextPart3281398.YVzxxdM7jo Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQBCdBolXhc68WspdLARAplnAJ4uXj1rWj+OqufU7kc8+rliQfaUKACeJJUh TszFvM2By3f/lpqsTmlNsqM= =ikaZ -----END PGP SIGNATURE----- --nextPart3281398.YVzxxdM7jo--