From owner-freebsd-stable@FreeBSD.ORG Sun Jan 23 02:00:51 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 217B1106564A; Sun, 23 Jan 2011 02:00:51 +0000 (UTC) (envelope-from perryh@pluto.rain.com) Received: from agora.rdrop.com (agora.rdrop.com [IPv6:2607:f678:1010::34]) by mx1.freebsd.org (Postfix) with ESMTP id F08FD8FC16; Sun, 23 Jan 2011 02:00:50 +0000 (UTC) Received: from agora.rdrop.com (66@localhost [127.0.0.1]) by agora.rdrop.com (8.13.1/8.12.7) with ESMTP id p0N20oPp098473 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 22 Jan 2011 18:00:50 -0800 (PST) (envelope-from perryh@pluto.rain.com) Received: (from uucp@localhost) by agora.rdrop.com (8.13.1/8.12.9/Submit) with UUCP id p0N20n39098472; Sat, 22 Jan 2011 18:00:49 -0800 (PST) Received: from fbsd61 by pluto.rain.com (4.1/SMI-4.1-pluto-M2060407) id AA17438; Sat, 22 Jan 11 17:59:00 PST Date: Sat, 22 Jan 2011 17:58:04 -0800 From: perryh@pluto.rain.com To: pluknet@gmail.com, jhb@freebsd.org Message-Id: <4d3b8b2c.K91aOxrW5s+w9Bml%perryh@pluto.rain.com> References: <4cfc72a5.3nAjkv8mdrO/NrKQ%perryh@pluto.rain.com> <4d3261bc.dcI6EuBnzRqvyRnz%perryh@pluto.rain.com> <201101181119.42053.jhb@freebsd.org> In-Reply-To: User-Agent: nail 11.25 7/29/05 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org, avg@freebsd.org Subject: Re: Could MSGBUF_SIZE be made a loader tunable? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jan 2011 02:00:51 -0000 Sergey Kandaurov wrote: > Committed in r217688. Thanks! Will this be eligible for MFC? (Not for 8.2 or 7.4 I suppose -- presumably they are only accepting bug-fixes at this point -- but I'd expect it to be compatible with 8-CURRENT.) From owner-freebsd-stable@FreeBSD.ORG Sun Jan 23 03:20:27 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5C4061065694 for ; Sun, 23 Jan 2011 03:20:27 +0000 (UTC) (envelope-from kensmith@buffalo.edu) Received: from localmailA.acsu.buffalo.edu (localmailA.acsu.buffalo.edu [128.205.5.196]) by mx1.freebsd.org (Postfix) with ESMTP id 1DEE08FC08 for ; Sun, 23 Jan 2011 03:20:26 +0000 (UTC) Received: from localmailA.acsu.buffalo.edu (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id AEE1CAF32 for ; Sat, 22 Jan 2011 22:20:15 -0500 (EST) Received: from localmailA.acsu.buffalo.edu (localhost [127.0.0.1]) by localmailA.acsu.buffalo.edu (Postfix) with ESMTP id 3C579AFD7 for ; Sat, 22 Jan 2011 22:20:14 -0500 (EST) Received: from mweb1.acsu.buffalo.edu (mweb1.acsu.buffalo.edu [128.205.5.238]) by localmailA.acsu.buffalo.edu (Prefixe) with ESMTP id 35A27AF32 for ; Sat, 22 Jan 2011 22:20:14 -0500 (EST) Received: from [192.168.1.101] (cpe-76-180-182-44.buffalo.res.rr.com [76.180.182.44]) by mweb1.acsu.buffalo.edu (Postfix) with ESMTP id D90C85B003D for ; Sat, 22 Jan 2011 22:20:10 -0500 (EST) From: Ken Smith To: freebsd-stable Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-Cj0diUaDp4r1yKQgZhi3" Organization: U. Buffalo Date: Sat, 22 Jan 2011 22:20:02 -0500 Message-ID: <1295752802.39623.14.camel@neo.cse.buffalo.edu> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 FreeBSD GNOME Team Port X-PM-EL-Spam-Prob: XX: 27% Subject: FreeBSD 7.4-RC2 Available... X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jan 2011 03:20:27 -0000 --=-Cj0diUaDp4r1yKQgZhi3 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The second Release Candidate for the FreeBSD 7.4 release cycle is now available. For this build only the amd64, i386, pc98, and sparc64 architectures are available. An initial set of pre-build packages are available on the DVD and CDROM images for the amd64 architecture. At the time the i386 images were created the two large meta-packages that are the bulk of what we normally provide (Gnome and KDE) were not available so there are some packages on the i386 images but what is there is not a reflection of what we expect to include with the final release. Several bugs we feel are critical enough to warrant fixing before the 8.2/7.4 releases are finalized, so the release will be delayed and we will be providing a third Release Candidate about a week from now. The Web pages have not been updated with a new schedule yet but we should get that done shortly. The wiki page tracking the release is here: http://wiki.freebsd.org/Releng/7.4TODO If you find problems you can report them through the normal Gnats based PR system or here on the mailing list. If you are updating an already running machine the CVS branch tag for 7.4-RC2 is RELENG_7_4. If you prefer SVN use "releng/7.4". The freebsd-update(8) utility supports binary upgrades of i386 and amd64 systems running earlier FreeBSD releases. Systems running 7.0-RELEASE, 7.1-RELEASE, 7.2-RELEASE, 7.3-RELEASE, 7.4-BETA1, or 7.4-RC1 can upgrade as follows: # freebsd-update upgrade -r 7.4-RC2 During this process, FreeBSD Update may ask the user to help by merging some configuration files or by confirming that the automatically performed merging was done correctly. # freebsd-update install The system must be rebooted with the newly installed kernel before continuing. # shutdown -r now After rebooting, freebsd-update needs to be run again to install the new userland components, and the system needs to be rebooted again: # freebsd-update install # shutdown -r now Users of earlier FreeBSD releases (FreeBSD 6.x) can also use freebsd-update to upgrade to FreeBSD 7.4-RC2, but will be prompted to rebuild all third-party applications (e.g., anything installed from the ports tree) after the second invocation of "freebsd-update install", in order to handle differences in the system libraries between FreeBSD 6.x and FreeBSD 7.x. Checksums: MD5 (FreeBSD-7.4-RC2-amd64-bootonly.iso) =3D bc44b0c6842dbac2a95d995e4571e5= 49 MD5 (FreeBSD-7.4-RC2-amd64-disc1.iso) =3D e5aabe0ad1ca8c4ccd3019b5fd974230 MD5 (FreeBSD-7.4-RC2-amd64-disc2.iso) =3D 88f0babf7d53d756625165e0e0e35fe0 MD5 (FreeBSD-7.4-RC2-amd64-disc3.iso) =3D 1d55f0fbdef270ea2686672ee4751eae MD5 (FreeBSD-7.4-RC2-amd64-docs.iso) =3D e69e8b9c4f5284d95c75bb06c27535d2 MD5 (FreeBSD-7.4-RC2-amd64-dvd1.iso) =3D df54b24909fa3fde2bccb42a76743da3 MD5 (FreeBSD-7.4-RC2-amd64-livefs.iso) =3D 5a7c047b8c5e072bfb30af6dc57696cd MD5 (FreeBSD-7.4-RC2-amd64-dvd1.iso.gz) =3D cb3925352f8c04a4d4786dfd0c3b3e2= f MD5 (FreeBSD-7.4-RC2-i386-bootonly.iso) =3D ffed2d071c779d80897619e3c3f35cf= a MD5 (FreeBSD-7.4-RC2-i386-disc1.iso) =3D aacd17bc727849abb613f08f462c8259 MD5 (FreeBSD-7.4-RC2-i386-disc2.iso) =3D 184d90227987097e936a07e33c22b5d0 MD5 (FreeBSD-7.4-RC2-i386-disc3.iso) =3D 5a4ae6980fc2280cde1949bd08ea40b7 MD5 (FreeBSD-7.4-RC2-i386-docs.iso) =3D 0822872236fb00b137bba081cdfef31c MD5 (FreeBSD-7.4-RC2-i386-dvd1.iso) =3D ed991433dc0975816703b1fd0c03a825 MD5 (FreeBSD-7.4-RC2-i386-livefs.iso) =3D b3eab22f88d75ec5c4b5ef1df0c93d5f MD5 (FreeBSD-7.4-RC2-pc98-bootonly.iso) =3D 5a41ff99d2bf4a2d9351b4af5b80997= 0 MD5 (FreeBSD-7.4-RC2-pc98-disc1.iso) =3D 59ae0dbda2a107f4464d626a59affd33 MD5 (FreeBSD-7.4-RC2-pc98-livefs.iso) =3D ab2b9da449d580eeb6356ea9522309ca MD5 (FreeBSD-7.4-RC2-sparc64-bootonly.iso) =3D 0728d9d58cc4325b03e2ce939cba= 15e3 MD5 (FreeBSD-7.4-RC2-sparc64-disc1.iso) =3D 0c799e1b9536c8b480cfbc1b48a096a= c MD5 (FreeBSD-7.4-RC2-sparc64-disc2.iso) =3D 26e9597dfb31fcae95c57d2ed7f98c5= 7 MD5 (FreeBSD-7.4-RC2-sparc64-disc3.iso) =3D 70e9c18f11df581f2cbcd10c72801c6= f MD5 (FreeBSD-7.4-RC2-sparc64-docs.iso) =3D a93d0c2bf38745527f35b850159ed25f SHA256 (FreeBSD-7.4-RC2-amd64-bootonly.iso) =3D b023f8d6057c0489b9eca602572= 5cd8ae8c77ddc2c5c97a8f3b0e9e40c3ef4eb SHA256 (FreeBSD-7.4-RC2-amd64-disc1.iso) =3D 8966b31db58f327ac173a26bcc9de9= 14e85a3cefe645f108aa8ce0b7e27cfe79 SHA256 (FreeBSD-7.4-RC2-amd64-disc2.iso) =3D ba57a5d52a80ab33fd9c143b2be885= d71ddb8bd4c824416df4a47e512032c830 SHA256 (FreeBSD-7.4-RC2-amd64-disc3.iso) =3D 10697e2fbeb11da1cad50d0765270c= b851f9f4fce2340dd4e43cc9d3cd63fb32 SHA256 (FreeBSD-7.4-RC2-amd64-docs.iso) =3D 63f8c3c9a9a67e0343a3973f47a7a21= f9f1e519840a3895c4913f7c5f41975f3 SHA256 (FreeBSD-7.4-RC2-amd64-dvd1.iso) =3D d3bcb035886d2d5058937da25961fc6= 7fa9bdf2117fe79f68e3304916d8312fc SHA256 (FreeBSD-7.4-RC2-amd64-livefs.iso) =3D 33180aff76c1b91a47c969a02932c= c63729eeee9d0eaf9e4951d0636dc9dba87 SHA256 (FreeBSD-7.4-RC2-amd64-dvd1.iso.gz) =3D 8dd332a6ae87afcef263971141a1= aceeb3ee1572431bc7f130500ee097cd12f7 SHA256 (FreeBSD-7.4-RC2-i386-bootonly.iso) =3D 29251bd67b1689d780ba071da74d= 425a401853570c738c5652281f28d3c4945d SHA256 (FreeBSD-7.4-RC2-i386-disc1.iso) =3D c9a5b8feced4198f7b99b1e649d8e3e= 8e1581a26ee8080b1da91fd72b1564396 SHA256 (FreeBSD-7.4-RC2-i386-disc2.iso) =3D 754f05d4d59caa64a136839f070c504= eee8d50a25e1f953fbaaff2c4ba04cd0f SHA256 (FreeBSD-7.4-RC2-i386-disc3.iso) =3D d8ab9eff61ae178a169a8d584ceaa93= a82cc68382f380095581a77127a575fa4 SHA256 (FreeBSD-7.4-RC2-i386-docs.iso) =3D e67a7f590ae6a14309510786bebd7b40= 961809eab2e01bc8f2caec47a15858ba SHA256 (FreeBSD-7.4-RC2-i386-dvd1.iso) =3D 6e51df8d55370a0d4c65a3ae67aa7955= a1c4da419f0d16ff1cf6e102dfa3efd3 SHA256 (FreeBSD-7.4-RC2-i386-livefs.iso) =3D 523a37fd3df04e39c72edf969d5196= 89c8c3231452a2e9b24384837638ee2ead SHA256 (FreeBSD-7.4-RC2-pc98-bootonly.iso) =3D 617509694de1f06f40de0e6ad321= 9b5b8ac5949487b927fd21724ada755f3066 SHA256 (FreeBSD-7.4-RC2-pc98-disc1.iso) =3D 11109af6b06020f48f51c5d217aeb56= e10b195028ac894345cabd3aeba5b3bc6 SHA256 (FreeBSD-7.4-RC2-pc98-livefs.iso) =3D 0a9101f14dab2600aa1ef25dbb3a44= b428fa8e19246521c29d44fb4035506557 SHA256 (FreeBSD-7.4-RC2-sparc64-bootonly.iso) =3D c2755e19b1d7cd410ad499d79= 721f9300ecda13119c88edc5210c86a47af0ed9 SHA256 (FreeBSD-7.4-RC2-sparc64-disc1.iso) =3D 6e6aea09f0da95ba198fdc883968= 12ce82ecad0746f268da1e907542bf188923 SHA256 (FreeBSD-7.4-RC2-sparc64-disc2.iso) =3D e2628df0ced05d9b9ac0cd7bed2c= 1d1c6ddb3c80fd275ec7a32ebf74f7fc3d04 SHA256 (FreeBSD-7.4-RC2-sparc64-disc3.iso) =3D e6598c5306db67a689d568d05b7c= 0df0e41fa275f6cf27e4392c02c1c5df8f5b SHA256 (FreeBSD-7.4-RC2-sparc64-docs.iso) =3D a0d6018fe5cbf97f55ae0e963ae00= c2cd4e37f46b17fdcd85a8b509ce0dcb267 --=20 Ken Smith - From there to here, from here to | kensmith@buffalo.edu there, funny things are everywhere. | - Theodore Geisel | --=-Cj0diUaDp4r1yKQgZhi3 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEABECAAYFAk07nloACgkQ/G14VSmup/bdvwCffs/tQzw619xofO91uO2DJTY6 swYAni/nQbC7iSG2IevEOF/sFWAjgVAs =+Mi4 -----END PGP SIGNATURE----- --=-Cj0diUaDp4r1yKQgZhi3-- From owner-freebsd-stable@FreeBSD.ORG Sun Jan 23 10:50:38 2011 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D3D72106564A for ; Sun, 23 Jan 2011 10:50:38 +0000 (UTC) (envelope-from dalroi@solfertje.student.utwente.nl) Received: from solfertje.student.utwente.nl (solfertje.student.utwente.nl [130.89.167.40]) by mx1.freebsd.org (Postfix) with ESMTP id 5E59E8FC12 for ; Sun, 23 Jan 2011 10:50:38 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by solfertje.student.utwente.nl (Postfix) with SMTP id AB8338063 for ; Sun, 23 Jan 2011 11:33:08 +0100 (CET) Received: from hollewijn.internal (hollewijn.internal [10.236.150.4]) by solfertje.student.utwente.nl (Postfix) with ESMTP id 13C8B8053 for ; Sun, 23 Jan 2011 11:32:56 +0100 (CET) From: Alban Hertroys Content-Type: multipart/mixed; boundary=Apple-Mail-11--356003971 Date: Sun, 23 Jan 2011 11:32:55 +0100 Message-Id: <652E5569-2566-4D3C-BC8B-C8B00F3B61EA@solfertje.student.utwente.nl> To: stable@freebsd.org Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) X-DSPAM-Result: Innocent X-DSPAM-Processed: Sun Jan 23 11:33:08 2011 X-DSPAM-Confidence: 1.0000 X-DSPAM-Probability: 0.0023 X-DSPAM-Signature: 363,4d3c03e411733364220958 X-DSPAM-Factors: 27, Address+0x162933f0, 0.40000, could, 0.40000, but, 0.40000, Content-Type*application/octet+stream, 0.40000, From*Alban, 0.40000, that+case, 0.40000, Mime-Version*Message, 0.40000, Global+Cap, 0.40000, DRD, 0.40000, number+=, 0.40000, or, 0.40000, provider+mirror/home, 0.40000, an, 0.40000, an, 0.40000, 0x33+0x8086bd0, 0.40000, trees, 0.40000, trees, 0.40000, the+terminal, 0.40000, is+something, 0.40000, is+something, 0.40000, normally, 0.40000, to+go, 0.40000, via, 0.40000, cut, 0.40000, that+L1, 0.40000, GEOM_MIRROR, 0.40000, of, 0.40000 Cc: Subject: Machine check errors X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jan 2011 10:50:38 -0000 --Apple-Mail-11--356003971 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=us-ascii Ever since installing 7.4-PRERELEASE I'm seeing MCA machine check errors on my home-server. They usually occur during my Sunday-night level1 dump via ssh to a disk connected to a different machine, although that's probably not relevant. Today I finally managed to catch it on the terminal, here's a hand-transcribed copy: MCA: Bank 0, Status 0xb622000000000135 MCA: Global Cap 0x0000000000000104, Status 0x0000000000000004 MCA: Vendor "AuthenticAMD". ID 0x662, APIC ID 1 MCA: CPU 0 UNCOR PCC DCACHE L1 DRD error MCA: Address 0x162933f0 Fatal trap 20: Machine check trap while in user mode cpuid = 0; apic id = 01 instruction pointer = 0x33:0x8086bd0 stack pointer = 0x3b:0xbfbfd390 frame pointer = 0x3b:0xbfbfd3e8 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 3, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, IOPL = 0 current process = 18119 (postgres) trap number = 20 panic: machine check trap cpuid = 0 GEOM_MIRROR: Device home: provider mirror/home destroyed. Dmesg is also attached. !DSPAM:363,4d3c03e411733364220958! --Apple-Mail-11--356003971 Content-Disposition: attachment; filename=dmesg_20110123 Content-Type: application/octet-stream; name="dmesg_20110123" Content-Transfer-Encoding: 7bit Copyright (c) 1992-2010 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 is a registered trademark of The FreeBSD Foundation. FreeBSD 7.4-PRERELEASE #7: Mon Dec 6 19:30:23 CET 2010 dalroi@solfertje.student.utwente.nl:/usr/obj/usr/src/sys/ERGOPROXY i386 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD Athlon(tm) XP 2000+ (1666.73-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x662 Family = 6 Model = 6 Stepping = 2 Features=0x383fbff AMD Features=0xc0400800 real memory = 1610088448 (1535 MB) avail memory = 1568038912 (1495 MB) ACPI APIC Table: MADT: Forcing active-low polarity and level trigger for SCI ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: Sleep Button (fixed) acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, 5ff00000 (3) failed Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x8008-0x800b on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff,0x8000-0x807f,0x8080-0x80ff iomem 0xd8000-0xdbfff on acpi0 pci0: on pcib0 agp0: on hostb0 device_attach: agp0 attach returned 12 pcib1: at device 1.0 on pci0 pci1: on pcib1 isab0: at device 7.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xf000-0xf00f at device 7.1 on pci0 ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] pci0: at device 7.3 (no driver attached) 3ware device driver for 9000 series storage controllers, version: 3.70.05.010 twa0: <3ware 9000 series Storage Controller> port 0x1000-0x103f mem 0xfc000000-0xfdffffff,0xfa000000-0xfa000fff irq 21 at device 9.0 on pci0 twa0: [ITHREAD] twa0: INFO: (0x15: 0x1300): Controller details:: Model 9550SXU-4LP, 4 ports, Firmware FE9X 3.08.02.005, BIOS BE9X 3.08.00.002 pcib2: at device 16.0 on pci0 pci2: on pcib2 ohci0: mem 0xfa104000-0xfa104fff irq 19 at device 0.0 on pci2 ohci0: [GIANT-LOCKED] ohci0: [ITHREAD] usb0: OHCI version 1.0, legacy support usb0: SMM does not respond, resetting usb0: on ohci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 4 ports with 4 removable, self powered vgapci0: mem 0xfa100000-0xfa103fff,0xfa800000-0xfaffffff irq 18 at device 6.0 on pci2 xl0: <3Com 3c905C-TX Fast Etherlink XL> port 0x2000-0x207f mem 0xfa105000-0xfa10507f irq 19 at device 7.0 on pci2 miibus0: on xl0 xlphy0: <3c905C 10/100 internal PHY> PHY 24 on miibus0 xlphy0: 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100baseTX-FDX, 100baseTX-FDX-flow, auto, auto-flow xl0: Ethernet address: 00:04:76:0f:59:7a xl0: [ITHREAD] xl1: <3Com 3c905C-TX Fast Etherlink XL> port 0x2080-0x20ff mem 0xfa105400-0xfa10547f irq 19 at device 8.0 on pci2 miibus1: on xl1 ukphy0: PHY 24 on miibus1 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto, auto-flow xl1: Ethernet address: 00:e0:81:27:1b:4b xl1: [ITHREAD] atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: does not respond device_attach: fdc0 attach returned 6 cpu0: on acpi0 fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: does not respond device_attach: fdc0 attach returned 6 pmtimer0 on isa0 orm0: at iomem 0xc0000-0xc7fff,0xc8000-0xc87ff,0xc8800-0xc8fff,0xc9000-0xc97ff,0xe0000-0xe3fff pnpid ORM0000 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 ppc0: parallel port not found. uart0: <16550 or compatible> at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 uart0: [FILTER] uart0: console (19200,n,8,1) uart1: <16550 or compatible> at port 0x2f8-0x2ff irq 3 on isa0 uart1: [FILTER] Timecounter "TSC" frequency 1666733145 Hz quality 800 Timecounters tick every 1.000 msec ad0: 190782MB at ata0-master UDMA100 ad1: 190782MB at ata0-slave UDMA100 acd0: DVDROM at ata1-master UDMA66 GEOM_STRIPE: Device tmp created (id=1982480573). GEOM_STRIPE: Disk ad0s1e attached to tmp. GEOM_STRIPE: Device usr created (id=1752489598). GEOM_STRIPE: Disk ad0s1f attached to usr. GEOM_MIRROR: Device mirror/root launched (2/2). GEOM_MIRROR: Device mirror/var launched (2/2). GEOM_STRIPE: Disk ad1s1e attached to tmp. GEOM_STRIPE: Device tmp activated. GEOM_STRIPE: Disk ad1s1f attached to usr. GEOM_STRIPE: Device usr activated. GEOM_MIRROR: Device mirror/home launched (2/2). WARNING: Expected rawoffset 0, found 63 WARNING: Expected rawoffset 0, found 63 da0 at twa0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-5 device da0: 100.000MB/s transfers da0: 476827MB (976541696 512 byte sectors: 255H 63S/T 60786C) da1 at twa0 bus 0 target 1 lun 0 da1: Fixed Direct Access SCSI-5 device da1: 100.000MB/s transfers da1: 953664MB (1953103872 512 byte sectors: 255H 63S/T 121575C) Trying to mount root from ufs:/dev/mirror/root WARNING: / was not properly dismounted WARNING: Expected rawoffset 0, found 63 WARNING: Expected rawoffset 0, found 63 twa0: INFO: (0x04: 0x0029): Verify started: unit=0 twa0: INFO: (0x04: 0x0029): Verify started: unit=1 --Apple-Mail-11--356003971 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=us-ascii >From searching the archives I found claims that L1 cache errors would cause far more troubles than I'm seeing. The user in that case however was using an Intel-based Thinkpad laptop, while I'm seeing them on an AthlonXP-based server (Tyan Tiger board, 3Ware RAID-controller, the works). Now there is something unusual about my server that could be related to these MCA errors: It's a dual-CPU motherboard that normally would host two AthlonMP's, but is instead hosting a single AthlonXP. So one of the CPU sockets has no CPU in it. So, what's my situation? Do I need to go looking for a replacement CPU or is something wrong with the machine-check itself? Alban Hertroys -- If you can't see the forest for the trees, cut the trees and you'll see there is no forest. !DSPAM:363,4d3c03e411733364220958! --Apple-Mail-11--356003971-- From owner-freebsd-stable@FreeBSD.ORG Sun Jan 23 13:07:57 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9BDD1106564A for ; Sun, 23 Jan 2011 13:07:57 +0000 (UTC) (envelope-from ml@my.gd) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 3B16B8FC0C for ; Sun, 23 Jan 2011 13:07:55 +0000 (UTC) Received: by wwf26 with SMTP id 26so3116743wwf.31 for ; Sun, 23 Jan 2011 05:07:54 -0800 (PST) Received: by 10.227.132.70 with SMTP id a6mr3067356wbt.193.1295788074371; Sun, 23 Jan 2011 05:07:54 -0800 (PST) Received: from dfleuriot.local (did75-17-88-165-130-96.fbx.proxad.net [88.165.130.96]) by mx.google.com with ESMTPS id f35sm8466702wbf.8.2011.01.23.05.07.52 (version=SSLv3 cipher=RC4-MD5); Sun, 23 Jan 2011 05:07:53 -0800 (PST) Message-ID: <4D3C2827.2000704@my.gd> Date: Sun, 23 Jan 2011 14:07:51 +0100 From: Damien Fleuriot User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: uqs@freebsd.org References: <20110120201740.GE24444@acme.spoerlein.net> <20110121222008.GB65811@acme.spoerlein.net> In-Reply-To: <20110121222008.GB65811@acme.spoerlein.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: freebsd-stable@freebsd.org Subject: Re: RFC vgrind in base (and buildworld) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jan 2011 13:07:57 -0000 On 1/21/11 11:20 PM, Ulrich Spörlein wrote: > On Thu, 20.01.2011 at 21:17:40 +0100, Ulrich Spörlein wrote: >> Hello, >> >> Currently our buildworld relies on groff(1) and vgrind(1) being present >> in the host system. I have a patch ready that at least makes sure these >> are built during bootstrap-tools and completes the WITHOUT_GROFF flag. >> >> vgrind(1) is only used for two papers under share/doc and we could >> easily expand the results and commit them to svn directly, alleviating >> the need to run vgrind(1) during buildworld. >> >> OTOH, there are much more useful tools to vgrind(1) for source code >> formatting. So do we still have vgrind(1) users out there? >> >> Regards, >> Uli > > [trying to get this thread back on track] > > Does anyone actually care about vgrind in base? Will people be angry if > I unroll the 2 cases where it is used under share/doc? > > Regards, > Uli > Hi Ulrich, I think I'm speaking for a reasonable amount of people when I say: I have no idea what vgrind is used for to begin with. If you can safely and easily get us rid of a binary that's only used for 2 small things when building the world, I'm all for it. The less clutter, the better :) Regards, -- Dam From owner-freebsd-stable@FreeBSD.ORG Sun Jan 23 14:59:45 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 87AE5106564A for ; Sun, 23 Jan 2011 14:59:45 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id 3A35A8FC08 for ; Sun, 23 Jan 2011 14:59:44 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1Ph1Pq-0004uV-9p for freebsd-stable@freebsd.org; Sun, 23 Jan 2011 15:59:42 +0100 Received: from 200.41.broadband11.iol.cz ([90.178.41.200]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 23 Jan 2011 15:59:42 +0100 Received: from gamato by 200.41.broadband11.iol.cz with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 23 Jan 2011 15:59:42 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: martinko Date: Sun, 23 Jan 2011 15:00:55 +0100 Lines: 21 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: 200.41.broadband11.iol.cz User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.11) Gecko/20100822 SeaMonkey/2.0.6 In-Reply-To: Subject: Re: After 7.3->8.1, moused on serial mouse draws 100% CPU X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jan 2011 14:59:45 -0000 Michael Sperber wrote: > > After upgrading from 7.3 to 8.1, moused has started drawing 100% CPU > (even when the mouse is not used). moused -d -f doesn't output anything > suspicious - in particular, it does not display anything when the mouse > is not moved. > > root 10833 100.0 0.1 1732 1100 v0 R+ 10:51AM 8:47.62 /usr/sbin/moused -d -F 200 -A 1.5 -a 0.5 -p /dev/cuau0 -t auto -d -f > > FWIW, I was using the uart serial driver even on 7.3. (Maybe this is > also the time to mention that mouse movement got much slower after the > move to uart - that's why the -F -A -a settings are in there.) > > Any help would be much appreciated! > I sent an email describing similar regression on 16/1/2010 but no one replied. The thing is that since moving to 8.x moused in console consumes way too much CPU as soon as mouse starts moving. :-/ M. From owner-freebsd-stable@FreeBSD.ORG Sun Jan 23 16:50:38 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D64F3106566B for ; Sun, 23 Jan 2011 16:50:38 +0000 (UTC) (envelope-from talon@lpthe.jussieu.fr) Received: from shiva.jussieu.fr (shiva.jussieu.fr [134.157.0.129]) by mx1.freebsd.org (Postfix) with ESMTP id 72A4D8FC12 for ; Sun, 23 Jan 2011 16:50:38 +0000 (UTC) Received: from parthe.lpthe.jussieu.fr (parthe.lpthe.jussieu.fr [134.157.10.1]) by shiva.jussieu.fr (8.14.4/jtpda-5.4) with ESMTP id p0NGSHdm024823 for ; Sun, 23 Jan 2011 17:28:30 +0100 (CET) X-Ids: 168 Received: from niobe.lpthe.jussieu.fr (niobe.lpthe.jussieu.fr [134.157.10.41]) by parthe.lpthe.jussieu.fr (Postfix) with ESMTP id C4C2820619 for ; Sun, 23 Jan 2011 17:28:16 +0100 (CET) Received: by niobe.lpthe.jussieu.fr (Postfix, from userid 2005) id 6D0E340E8; Sun, 23 Jan 2011 17:28:19 +0100 (CET) Date: Sun, 23 Jan 2011 17:28:19 +0100 From: Michel Talon To: freebsd-stable@freebsd.org Message-ID: <20110123162819.GA4074@lpthe.jussieu.fr> Mail-Followup-To: Michel Talon , freebsd-stable@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i X-Miltered: at jchkmail.jussieu.fr with ID 4D3C5721.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 4D3C5721.000/134.157.10.1/parthe.lpthe.jussieu.fr/parthe.lpthe.jussieu.fr/ Subject: Re: RFC vgrind in base (and buildworld) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jan 2011 16:50:38 -0000 Damien Fleuriot wrote: > I think I'm speaking for a reasonable amount of people when I say: I > have no idea what vgrind is used for to begin with. Anyways, there is also a reasonable number of people who know what vgrind is about: pretty printing various source codes through troff particularly C code. Another tool doing the same through TeX is tgrind. > The less clutter, the better :) Except perhaps not two people have the same idea of "clutter". For example many people think that half of the content of the so-called "base system" is clutter. -- Michel TALON From owner-freebsd-stable@FreeBSD.ORG Sun Jan 23 19:19:02 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A4AE8106566C; Sun, 23 Jan 2011 19:19:02 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 33EF68FC0C; Sun, 23 Jan 2011 19:19:01 +0000 (UTC) Received: by qwj9 with SMTP id 9so3229903qwj.13 for ; Sun, 23 Jan 2011 11:19:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=ZYqPgAZUwuhOMhqMVRgkgcwigK1dxo8LaxREkhkI/j0=; b=TehHsmOCKaY8wT9eMfzzFiWBFUaPNBbTw87bvC0c/nRXGKbOkTAvsJNYgk8PZ7i3Ns 4p0kN78enx9dUNgXcDi105Mv+M775b7PIauTsWjrQvodAquDx9eaeD2TWT2KlpzcLI0n gDdRQlr6UGo99szsdfY9UB0J0SdH4L9BQeVWw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=anE1Ai8KwEZSgS5Uom4b0oV2l7Ejj1Uktl6JA70wE9mdjOkpSKFxgRsbh23HgNcOYi GMxjTD1iglvq7zpAYeISNC0JucTIa6reGQll3DhSF0HLhfCgNN/40Qa0om3/r9r7vFFw aSO7ll5QXr0u5R1j+AORdnlRGemDqsCULn+Yg= MIME-Version: 1.0 Received: by 10.229.185.1 with SMTP id cm1mr3104952qcb.81.1295810341408; Sun, 23 Jan 2011 11:19:01 -0800 (PST) Received: by 10.229.102.87 with HTTP; Sun, 23 Jan 2011 11:19:01 -0800 (PST) In-Reply-To: <4d3b8b2c.K91aOxrW5s+w9Bml%perryh@pluto.rain.com> References: <4cfc72a5.3nAjkv8mdrO/NrKQ%perryh@pluto.rain.com> <4d3261bc.dcI6EuBnzRqvyRnz%perryh@pluto.rain.com> <201101181119.42053.jhb@freebsd.org> <4d3b8b2c.K91aOxrW5s+w9Bml%perryh@pluto.rain.com> Date: Sun, 23 Jan 2011 22:19:01 +0300 Message-ID: From: Sergey Kandaurov To: perryh@pluto.rain.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org, avg@freebsd.org, jhb@freebsd.org Subject: Re: Could MSGBUF_SIZE be made a loader tunable? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jan 2011 19:19:02 -0000 On 23 January 2011 04:58, wrote: > Sergey Kandaurov wrote: > >> Committed in r217688. > > Thanks! > > Will this be eligible for MFC? =A0(Not for 8.2 or 7.4 I suppose -- > presumably they are only accepting bug-fixes at this point -- but > I'd expect it to be compatible with 8-CURRENT.) > I hope I'll be able to MFC this somewhere after 8.2 is out. --=20 wbr, pluknet From owner-freebsd-stable@FreeBSD.ORG Mon Jan 24 05:13:11 2011 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D1E6B106564A for ; Mon, 24 Jan 2011 05:13:11 +0000 (UTC) (envelope-from perryh@pluto.rain.com) Received: from agora.rdrop.com (agora.rdrop.com [IPv6:2607:f678:1010::34]) by mx1.freebsd.org (Postfix) with ESMTP id AFFF38FC23 for ; Mon, 24 Jan 2011 05:13:11 +0000 (UTC) Received: from agora.rdrop.com (66@localhost [127.0.0.1]) by agora.rdrop.com (8.13.1/8.12.7) with ESMTP id p0O5DA8a060804 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 23 Jan 2011 21:13:10 -0800 (PST) (envelope-from perryh@pluto.rain.com) Received: (from uucp@localhost) by agora.rdrop.com (8.13.1/8.12.9/Submit) with UUCP id p0O5DAmx060803; Sun, 23 Jan 2011 21:13:10 -0800 (PST) Received: from fbsd61 by pluto.rain.com (4.1/SMI-4.1-pluto-M2060407) id AA21781; Sun, 23 Jan 11 21:03:20 PST Date: Sun, 23 Jan 2011 21:02:22 -0800 From: perryh@pluto.rain.com To: dalroi@solfertje.student.utwente.nl Message-Id: <4d3d07de.Zks2QhWq07V8ucNL%perryh@pluto.rain.com> References: <652E5569-2566-4D3C-BC8B-C8B00F3B61EA@solfertje.student.utwente.nl> In-Reply-To: <652E5569-2566-4D3C-BC8B-C8B00F3B61EA@solfertje.student.utwente.nl> User-Agent: nail 11.25 7/29/05 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: stable@freebsd.org Subject: Re: Machine check errors X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jan 2011 05:13:11 -0000 Alban Hertroys wrote: > Ever since installing 7.4-PRERELEASE I'm seeing MCA machine check > errors on my home-server ... > > MCA: Bank 0, Status 0xb622000000000135 > MCA: Global Cap 0x0000000000000104, Status 0x0000000000000004 > MCA: Vendor "AuthenticAMD". ID 0x662, APIC ID 1 > MCA: CPU 0 UNCOR PCC DCACHE L1 DRD error ^^^^^^^^^ > MCA: Address 0x162933f0 That's an error in the on-chip data cache. The first thing I would check is cooling. Maybe one of the fans has quit working, or the air filter (if the box has one) has gotten clogged up with dust, so that the CPU is running hotter than it should. From owner-freebsd-stable@FreeBSD.ORG Mon Jan 24 07:36:34 2011 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8E7B11065670 for ; Mon, 24 Jan 2011 07:36:34 +0000 (UTC) (envelope-from dalroi@solfertje.student.utwente.nl) Received: from solfertje.student.utwente.nl (solfertje.student.utwente.nl [130.89.167.40]) by mx1.freebsd.org (Postfix) with ESMTP id 47F2C8FC1A for ; Mon, 24 Jan 2011 07:36:33 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by solfertje.student.utwente.nl (Postfix) with SMTP id B243A8063 for ; Mon, 24 Jan 2011 08:36:32 +0100 (CET) Received: from hollewijn.internal (hollewijn.internal [10.236.150.4]) by solfertje.student.utwente.nl (Postfix) with ESMTP id 7B6748053; Mon, 24 Jan 2011 08:36:13 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Alban Hertroys In-Reply-To: <4d3d07de.Zks2QhWq07V8ucNL%perryh@pluto.rain.com> Date: Mon, 24 Jan 2011 08:36:13 +0100 Content-Transfer-Encoding: 8bit Message-Id: <24866F34-E715-49DE-B9BB-BECF9EFF7772@solfertje.student.utwente.nl> References: <652E5569-2566-4D3C-BC8B-C8B00F3B61EA@solfertje.student.utwente.nl> <4d3d07de.Zks2QhWq07V8ucNL%perryh@pluto.rain.com> To: perryh@pluto.rain.com X-Mailer: Apple Mail (2.1082) X-DSPAM-Result: Innocent X-DSPAM-Processed: Mon Jan 24 08:36:32 2011 X-DSPAM-Confidence: 1.0000 X-DSPAM-Probability: 0.0023 X-DSPAM-Signature: 363,4d3d2c0011731311418875 X-DSPAM-Factors: 27, Address+0x162933f0, 0.40000, From*Alban, 0.40000, clogged, 0.40000, hotter+than, 0.40000, solfertje+student, 0.40000, amazing+how, 0.40000, Mime-Version*Message, 0.40000, student, 0.40000, Message-Id*49DE+B9BB, 0.40000, acceptable+temperature, 0.40000, one)+has, 0.40000, Global+Cap, 0.40000, DRD, 0.40000, or, 0.40000, an, 0.40000, an, 0.40000, already+), 0.40000, 10, 0.40000, from, 0.40000, amazing, 0.40000, >>+errors, 0.40000, gotten, 0.40000, rain+com, 0.40000, of, 0.40000, of, 0.40000, >+Alban, 0.40000, quit, 0.40000 Cc: stable@freebsd.org Subject: Re: Machine check errors X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jan 2011 07:36:34 -0000 On 24 Jan 2011, at 6:02, perryh@pluto.rain.com wrote: > Alban Hertroys wrote: > >> Ever since installing 7.4-PRERELEASE I'm seeing MCA machine check >> errors on my home-server ... >> >> MCA: Bank 0, Status 0xb622000000000135 >> MCA: Global Cap 0x0000000000000104, Status 0x0000000000000004 >> MCA: Vendor "AuthenticAMD". ID 0x662, APIC ID 1 >> MCA: CPU 0 UNCOR PCC DCACHE L1 DRD error > ^^^^^^^^^ >> MCA: Address 0x162933f0 > > That's an error in the on-chip data cache. It is, I saw that too. > The first thing I would check is cooling. Maybe one of the fans > has quit working, or the air filter (if the box has one) has gotten > clogged up with dust, so that the CPU is running hotter than it > should. It's amazing how your perception of acceptable temperature ranges rises with the actual average temperature. Turns out the last time I unclogged the dust filter on the case was longer ago than I thought it was. Good call! Temperature went down from 55C to 46C over the last 10 minutes already... I think I'm starting to appreciate the MCA feature already :) Alban Hertroys -- Screwing up is an excellent way to attach something to the ceiling. !DSPAM:363,4d3d2c0011731311418875! From owner-freebsd-stable@FreeBSD.ORG Mon Jan 24 20:20:04 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 163EA1065670 for ; Mon, 24 Jan 2011 20:20:04 +0000 (UTC) (envelope-from demelier.david@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id D13898FC0C for ; Mon, 24 Jan 2011 20:20:03 +0000 (UTC) Received: by iyb26 with SMTP id 26so4498193iyb.13 for ; Mon, 24 Jan 2011 12:20:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=Ky9a8nUyLQkPRuf/VGIy1dn0LWWOhxVjzreprVrc0SA=; b=gP9IV3u9bT/+l+Sag5j9gg++IoT/WZhK4YpH14GWEtN7AKLXH5noOuE5i6OKoNcQ15 Mvo3jLHPJRgO434XEoikzP9xgFPrpuaItXfovIHeWlRFTYIfpyMciIFLtRzvt6Fy0PnK AkKg2k/oQw7+/CLOXn9igREnbHh1NJxLtFD/0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=F/7iobzWGzpZZ1pteIUh5T0PVyUjOFmroqH1hFpgGHoXGLiS8WkLBFo9kHr1+MiMTV D4YSzHkPtuZ4JxeRwQ6JuKhm5SSix2WoBXyvCVjbMYZi6wEHM+oTivlJKBZSYBvHNjyk sxfgpkQYmn/HZx6w/dIxDf+CpQ07gdICNsLu0= MIME-Version: 1.0 Received: by 10.42.170.131 with SMTP id f3mr4074754icz.397.1295900402559; Mon, 24 Jan 2011 12:20:02 -0800 (PST) Received: by 10.42.180.136 with HTTP; Mon, 24 Jan 2011 12:20:02 -0800 (PST) Date: Mon, 24 Jan 2011 21:20:02 +0100 Message-ID: From: David DEMELIER To: freebsd-stable Content-Type: text/plain; charset=UTF-8 Subject: ALPS GlidePoint not detected on dell inspiron X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jan 2011 20:20:04 -0000 Hello, A friend has a DELL Inspiron 1525 with an ALPS GlidePoint touchpad. We have added hw.psm.synaptics_support=1 in his /boot/loader.conf but it still detected as a standard ps2 mouse. Looking at sys/dev/atkbdc/psm.c : 461 { MOUSE_MODEL_GLIDEPOINT, /* ALPS GlidePoint */ 462 0xc0, MOUSE_PS2_PACKETSIZE, enable_aglide }, I'm guessing if his touchpad has 0xc0 as model, how can I check this? For the moment there is this in his dmesg: psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model GlidePoint, device ID 0 Cheers, -- Demelier David From owner-freebsd-stable@FreeBSD.ORG Mon Jan 24 22:58:58 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2ED1A106564A for ; Mon, 24 Jan 2011 22:58:58 +0000 (UTC) (envelope-from stephen@missouri.edu) Received: from mxnip01-missouri-out.um.umsystem.edu (mxnip01-missouri-out.um.umsystem.edu [209.106.229.53]) by mx1.freebsd.org (Postfix) with ESMTP id DDE6F8FC17 for ; Mon, 24 Jan 2011 22:58:57 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAH+MPU3RauUo/2dsb2JhbACEE6BYc4gnol6HXYhogSSBVwiBWXQEhHCJVQaIUw Received: from um-tsmtpout1.um.umsystem.edu ([209.106.229.40]) by mxnip01-mizzou-out.um.umsystem.edu with ESMTP; 24 Jan 2011 16:29:52 -0600 Received: from um-tsmtpout1.um.umsystem.edu ([209.106.229.35]) by um-tsmtpout1.um.umsystem.edu with Microsoft SMTPSVC(6.0.3790.4675); Mon, 24 Jan 2011 16:29:52 -0600 Received: from [192.168.1.69] ([173.202.227.194]) by um-tsmtpout1.um.umsystem.edu with Microsoft SMTPSVC(6.0.3790.4675); Mon, 24 Jan 2011 16:29:52 -0600 Message-ID: <4D3DFD5F.7050602@missouri.edu> Date: Mon, 24 Jan 2011 16:29:51 -0600 From: Stephen Montgomery-Smith User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.16) Gecko/20101206 SeaMonkey/2.0.11 MIME-Version: 1.0 To: David DEMELIER References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Jan 2011 22:29:52.0563 (UTC) FILETIME=[38095830:01CBBC16] Cc: freebsd-stable Subject: Re: ALPS GlidePoint not detected on dell inspiron X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jan 2011 22:58:58 -0000 David DEMELIER wrote: > Hello, > > A friend has a DELL Inspiron 1525 with an ALPS GlidePoint touchpad. We > have added hw.psm.synaptics_support=1 in his /boot/loader.conf but it > still detected as a standard ps2 mouse. > > Looking at sys/dev/atkbdc/psm.c : > 461 { MOUSE_MODEL_GLIDEPOINT, /* ALPS GlidePoint */ > 462 0xc0, MOUSE_PS2_PACKETSIZE, enable_aglide }, > > I'm guessing if his touchpad has 0xc0 as model, how can I check this? > > For the moment there is this in his dmesg: > > psm0: irq 12 on atkbdc0 > > psm0: [GIANT-LOCKED] > > psm0: [ITHREAD] > > psm0: model GlidePoint, device ID 0 > > Cheers, I had the same issues with an ALPS glidepoint on a Dell Inspiron 1525. I think it is different than a synaptics. I don't know what problem you are trying to solve, but if you are trying to switch off the "tapping the touchpad" feature, I found an unusual solution two years ago: look at http://www.mavetju.org/mail/view_message.php?list=freebsd-mobile&id=2760915 From owner-freebsd-stable@FreeBSD.ORG Tue Jan 25 07:21:02 2011 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8DD5C106564A for ; Tue, 25 Jan 2011 07:21:02 +0000 (UTC) (envelope-from egrosbein@rdtc.ru) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [62.231.161.221]) by mx1.freebsd.org (Postfix) with ESMTP id CF9278FC17 for ; Tue, 25 Jan 2011 07:21:01 +0000 (UTC) Received: from eg.sd.rdtc.ru (localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.14.4/8.14.4) with ESMTP id p0P7KwPM081088 for ; Tue, 25 Jan 2011 13:20:58 +0600 (NOVT) (envelope-from egrosbein@rdtc.ru) Message-ID: <4D3E79D5.7050800@rdtc.ru> Date: Tue, 25 Jan 2011 13:20:53 +0600 From: Eugene Grosbein User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; ru-RU; rv:1.9.2.13) Gecko/20110112 Thunderbird/3.1.7 MIME-Version: 1.0 To: stable@freebsd.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Subject: Living on gmirror: need to reincarnate /etc/rc.early X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2011 07:21:02 -0000 Hi! In RELENG_8, gmirror is good enough to keep whole HDD pair withing the mirror. Its performance, stability any pretty ease of maintainance allows to use it widely. With wide deployment of gmirror in production I've faced inability of RELENG_8 to store kernel crashdumps out-of-the-box. gmirror manual page documents a way to setup FreeBSD so that it would store crashdumps again but that way involves /etc/rc.early removed from RELENG_8. I've read about intentions - it was unsafe etc. But we still need working crashdump support. Easiest way is to reincarnate /etc/rc.d/early support making it better and safer and it should support gmirror's mechanics for crashdumps out-of-the-box. Comments? Eugene Grosbein From owner-freebsd-stable@FreeBSD.ORG Tue Jan 25 07:49:38 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 76A12106564A for ; Tue, 25 Jan 2011 07:49:37 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe03.c2i.net [212.247.154.66]) by mx1.freebsd.org (Postfix) with ESMTP id DFBFB8FC0C for ; Tue, 25 Jan 2011 07:49:36 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.1 cv=0KkIQGagYCvnrzE3Z2Lmid87OPdbX6VLcZYwAuLMZ50= c=1 sm=1 a=cvYaY9RErdMA:10 a=8nJEP1OIZ-IA:10 a=CL8lFSKtTFcA:10 a=i9M/sDlu2rpZ9XS819oYzg==:17 a=pGLkceISAAAA:8 a=6I5d2MoRAAAA:8 a=8kQB0OdkAAAA:8 a=KfirBqrERvXtFrv6GZ0A:9 a=UJoiIJX_dnzIXkdzcpkA:7 a=38BS3ROkzdKPq1hgKPHD63mgl08A:4 a=wPNLvfGTeEIA:10 a=MSl-tDqOz04A:10 a=SV7veod9ZcQA:10 a=9aOQ2cSd83gA:10 a=qYDcRaK6MV9EvN17:21 a=Be63cI64rluiqreZ:21 a=i9M/sDlu2rpZ9XS819oYzg==:117 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe03.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 78614952 for freebsd-stable@freebsd.org; Tue, 25 Jan 2011 08:49:34 +0100 From: Hans Petter Selasky To: "freebsd-stable" Date: Tue, 25 Jan 2011 08:49:41 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.2-PRERELEASE; KDE/4.4.5; amd64; ; ) X-Face: *nPdTl_}RuAI6^PVpA02T?$%Xa^>@hE0uyUIoiha$pC:9TVgl.Oq, NwSZ4V"|LR.+tj}g5 %V,x^qOs~mnU3]Gn; cQLv&.N>TrxmSFf+p6(30a/{)KUU!s}w\IhQBj}[g}bj0I3^glmC( :AuzV9:.hESm-x4h240C`9=w MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201101250849.41095.hselasky@c2i.net> Subject: Fwd: Re: System lockups caused by USB external HDD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2011 07:49:38 -0000 ---------- Forwarded Message ---------- Subject: Re: System lockups caused by USB external HDD Date: Tuesday 25 January 2011, 01:48:03 From: CDP To: freebsd-usb@freebsd.org CC: Hans Petter Selasky , mav@freebsd.org On 01/24/11 13:27, Hans Petter Selasky wrote: > On Monday 24 January 2011 12:08:47 CDP wrote: >> On 01/24/11 11:34, Hans Petter Selasky wrote: >>> On Monday 24 January 2011 10:00:53 CDP wrote: >>>> On 01/24/11 01:56, Daniel O'Connor wrote: >>>>> On 24/01/2011, at 9:10, CDP wrote: >>>>>> g_vfs_done():da0s2[WRITE(offset=xxxxxxxxxxxx, length=16384)]error = 5 >>>>>> [several more lines similar to the above] >>>>>> panic: softdep_move_dependencies: need merge code >>>>>> cpuid = 0 >>>>>> KDB: stack backtrace: >>>>>> #0 0x... at kdb_backtrace+0x5e >>>>>> #1 0x... at panic+0x182 >>>>> >>>>> It looks like the disk is dying, or the FS is corrupt (the former might >>>>> cause the later). >>>>> >>>>> Can you run smartctl on the disk? Unfortunately a lot of enclosures >>>>> reject SMART commands so you might not be able to :( >>>> >>>> I have attached the output of smartctl -d sat -a /dev/da0. I didn't yet >>>> run a SMART long test for the simple reason that the disk is going into >>>> sleep mode and interrupts it. Haven't bothered to keep it alive for a >>>> long test but I might just do that. >>>> >>>> Although, I doubt it's a disk failure, since I do backups on it without >>>> problems by using FreeBSD 7.3, on the same space where FreeBSD 8.x >>>> fails. And I am talking about over 150GB of data in one run, while >>>> 8.2-RC2 crashes after 5-10GB. I have experienced disk failure in the >>>> past, on SATA, and a few read/write errors never caused a system lockup. >>>> >>>> My feeling is that enough traffic on USB causes the problem, and that >>>> this problem is only present in the new USB stack. >>>> Unfortunately downgrading to 7.x is not an option because there are >>>> things that won't work on this notebook. >>> >>> If you run a simple test like this: >>> >>> dd if=/dev/da0 of=/dev/null bs=65536 >>> dd if=/dev/da0 of=/dev/null bs=16384 >>> >>> Do you then see any errors? >>> >>> Do you have a spare USB memory stick which you could run similar write >>> tests on? >> >> Both reads fail with I/O error, while writes to an unused partition seem >> to be fine (I interrupted the writes after a while): >> >> % dd if=/dev/da0 of=/dev/null bs=65536 >> dd: /dev/da0: Input/output error >> 191732+0 records in >> 191732+0 records out >> 12565348352 bytes transferred in 429.999272 secs (29221790 bytes/sec) >> >> % dd if=/dev/da0 of=/dev/null bs=16384 >> dd: /dev/da0: Input/output error >> 126427+0 records in >> 126427+0 records out >> 2071379968 bytes transferred in 169.431766 secs (12225452 bytes/sec) >> >> # dd if=/dev/random of=/dev/da0s3 bs=65536 >> ^C329378+0 records in >> 329377+0 records out >> 21586051072 bytes transferred in 1003.020293 secs (21521051 bytes/sec) >> >> # dd if=/dev/random of=/dev/da0s3 bs=16384 >> ^C679571+0 records in >> 679571+0 records out >> 11134091264 bytes transferred in 690.135793 secs (16133189 bytes/sec) >> >> This is what I get in /var/log/messages when the I/O error occurs: >> (da0:umass-sim0:0:0:0): AutoSense failed >> >> However, I experience no lockup. Maybe this situation is not handled >> correctly at another level ? > > I haven't looked into the code of CAM or GEOM that much so I won't say too > much about that. I believe the USB/umass is not to blame. What you could do is > to add a conditional error printout in "umass_t_bbb_status_callback()" in > /sys/dev/usb/storage/umass.c when the error happens. If that error is not a > USB transport error, then we are most likely seeing a SCSI issue in layers > above umass. Or if you have access to USB analyser use that. There is now also > the option to trace USB from the kernel itself, but the feature is in its > early development. The panics I was able to catch/inspect (latest from add_to_worklist() / ffs_softdep.c) indicated they were thrown by ffs/softupdates code, therefore I tried disabling softupdates. The system doesn't panic anymore. The operations on the USB HDD still stop, but after several tens of seconds the system logs the 'autosense failed' error, a bunch of write errors, and the copy operation resumes. md5 shows the copied files are identical to the source files. In 7.x I don't recall having any kind of errors, neither temporary locks in disk operations, so I'm guessing the 'autosense failed' situation is handled differently in 8.x, compared to 7.x. Claudiu. ----------------------------------------- From owner-freebsd-stable@FreeBSD.ORG Tue Jan 25 09:50:35 2011 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B38D61065673; Tue, 25 Jan 2011 09:50:35 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 37BED8FC16; Tue, 25 Jan 2011 09:50:34 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id p0P9Sw8F092088 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Jan 2011 11:28:58 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id p0P9Swca033554; Tue, 25 Jan 2011 11:28:58 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id p0P9SwbO033553; Tue, 25 Jan 2011 11:28:58 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 25 Jan 2011 11:28:58 +0200 From: Kostik Belousov To: Eugene Grosbein Message-ID: <20110125092858.GJ2518@deviant.kiev.zoral.com.ua> References: <4D3E79D5.7050800@rdtc.ru> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="koElQQqmLVmRs57w" Content-Disposition: inline In-Reply-To: <4D3E79D5.7050800@rdtc.ru> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: stable@freebsd.org, rc@freebsd.org Subject: Re: Living on gmirror: need to reincarnate /etc/rc.early X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2011 09:50:35 -0000 --koElQQqmLVmRs57w Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jan 25, 2011 at 01:20:53PM +0600, Eugene Grosbein wrote: > Hi! >=20 > In RELENG_8, gmirror is good enough to keep whole HDD pair withing the mi= rror. > Its performance, stability any pretty ease of maintainance allows > to use it widely. >=20 > With wide deployment of gmirror in production I've faced inability > of RELENG_8 to store kernel crashdumps out-of-the-box. > gmirror manual page documents a way to setup FreeBSD so that > it would store crashdumps again but that way involves /etc/rc.early > removed from RELENG_8. I've read about intentions - it was unsafe etc. > But we still need working crashdump support. >=20 > Easiest way is to reincarnate /etc/rc.d/early support making it better an= d safer > and it should support gmirror's mechanics for crashdumps out-of-the-box. >=20 > Comments? Yes, I have this change for eons. Actually, from the moment rc.early was booted out. diff --git a/etc/rc.d/Makefile b/etc/rc.d/Makefile index 6f80b87..7981ce0 100755 --- a/etc/rc.d/Makefile +++ b/etc/rc.d/Makefile @@ -9,7 +9,7 @@ FILES=3D DAEMON FILESYSTEMS LOGIN NETWORKING SERVERS \ ccd cleanvar cleartmp cron \ ddb defaultroute devd devfs dhclient \ dmesg dumpon \ - encswap \ + early encswap \ faith fsck ftp-proxy ftpd \ gbde geli geli2 gptboot gssd \ hastd hcsecd \ diff --git a/etc/rc.d/early b/etc/rc.d/early new file mode 100755 index 0000000..8a863d0 --- /dev/null +++ b/etc/rc.d/early @@ -0,0 +1,29 @@ +#!/bin/sh +# +# $FreeBSD$ +# + +# PROVIDE: early +# REQUIRE: disks localswap +# BEFORE: fsck + +# +# Support for legacy /etc/rc.early script +# +. /etc/rc.subr + +name=3D"early" +start_cmd=3D"early_start" +stop_cmd=3D":" + +early_start() +{ + if [ -r /etc/rc.early ]; then + echo -n 'Executing rc.early script:' + . /etc/rc.early + echo '.' + fi +} + +load_rc_config $name +run_rc_command "$1" --koElQQqmLVmRs57w Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk0+l9oACgkQC3+MBN1Mb4jvYwCeOKqmWAMgZUD4CeclJeJziina mDIAoNURz8odYmmDyrKEqvRbhCR/SAL7 =4Qyo -----END PGP SIGNATURE----- --koElQQqmLVmRs57w-- From owner-freebsd-stable@FreeBSD.ORG Tue Jan 25 13:20:16 2011 Return-Path: Delivered-To: stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 436DD1065670; Tue, 25 Jan 2011 13:20:16 +0000 (UTC) (envelope-from danger@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 162A58FC08; Tue, 25 Jan 2011 13:20:16 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p0PDKFFi002927; Tue, 25 Jan 2011 13:20:15 GMT (envelope-from danger@freefall.freebsd.org) Received: (from danger@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p0PDKFdI002918; Tue, 25 Jan 2011 13:20:15 GMT (envelope-from danger) Date: Tue, 25 Jan 2011 13:20:15 +0000 From: Daniel Gerzo To: hackers@FreeBSD.org Message-ID: <20110125132015.GA1789@freefall.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.4.2.3i Cc: stable@FreeBSD.org, current@FreeBSD.org Subject: FreeBSD Status Report - 4Q/2010 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2011 13:20:16 -0000 FreeBSD Quarterly Status Report Introduction This report covers FreeBSD-related projects between October and December 2010. It is the last of the four reports planned for 2010. The work on the new minor versions of FreeBSD, 7.4 and 8.2, has been progressing well and they should be released around the end of this month. Thanks to all the reporters for the excellent work! This report contains 37 entries and we hope you enjoy reading it. Please note that the deadline for submissions covering the period between January and March 2011 is April 15th, 2011. __________________________________________________________________ Projects * BSDInstall * Non-executable Stacks * Webcamd * xz Compression for Packages and Log Files * ZFS pool version 28 FreeBSD Team Reports * FreeBSD Bugbusting Team Status Report * Release Engineering Team Status Report * The FreeBSD Foundation Status Report Network Infrastructure * DIstributed Firewall and Flow-shaper Using Statistical Evidence (DIFFUSE) * Ethernet Switch Framework * Five New TCP Congestion Control Algorithms for FreeBSD * FreeBSD 802.11n * FreeBSD VirtIO Network Driver * Generic IEEE 802.3 annex 31B full duplex flow control support for Ethernet in mii(4) * IPv6 and VIMAGE * TCP SMP scalability project Kernel * Resource Containers * SYSCTL Type Safety * TRIM support for UFS Documentation * mdocml Replacing groff For manpage Rendering * The FreeBSD German Documentation Project Status Report * The FreeBSD Japanese Documentation Project Userland Programs * FreeBSD Services Control (fsc) * GEOM-based ataraid(4) Replacement -- geom_raid * gpart Improvements Architectures * Bringing up OMAP3 * FreeBSD on the Playstation 3 * FreeBSD/EC2 * FreeBSD/sparc64 Ports * Chromium * FreeBSD as Home Theater PC * Port-Sandbox * Portmaster * Ports Additions * Ports Collection * Robot Operating System Miscellaneous * FOSDEM 2011 __________________________________________________________________ Bringing up OMAP3 URL: http://people.FreeBSD.org/~raj/patches/arm/dove_v6.diff Contact: Warner Losh Contact: Mohammed Farrag The attached file is an old patch for ARM. We are developing new patch and then we are going toward Porting OMAP3. __________________________________________________________________ BSDInstall URL: http://wiki.FreeBSD.org/BSDInstall Contact: Nathan Whitehorn BSDInstall is a replacement for the venerable sysinstall installer. It is designed to be modular and easily extensible, while being fully scriptable and streamlining the installation process. It is mostly complete, and installs working systems on i386, amd64, sparc64, powerpc, and powerpc64, with untested PC98 support. New Features: * Allows installation onto GPT disks on x86 systems * Can do installations spanning multiple disks * Allows installation into jails * Eases PXE installation * Virtualization friendly: can install from a live system onto disk images * Works on PowerPC * Streamlined system installation * More flexible scripting * Easily tweakable * All install CDs are live CDs Open tasks: 1. Wireless networking configuration wizard. 2. ZFS installation support. 3. Itanium disk setup. __________________________________________________________________ Chromium URL: http://www.chromium.org/Home URL: http://people.FreeBSD.org/~bapt/chrome9-fbsd.png Contact: Ren Ladan We are working on updating the Chromium web browser in our ports to stay up to date with the latest supported release. We currently have the Chromium 9 beta running, but not all features are fully implemented and the port still needs some polish before it can be committed to the Ports Collection. We have also been making arrangements with Google to merge our work with their upstream, which should ease the number of features and fixes we have to maintain for ourselves in the future. Our first release should be in a few weeks and coincide with the official release of Chromium 9. __________________________________________________________________ DIstributed Firewall and Flow-shaper Using Statistical Evidence (DIFFUSE) URL: http://caia.swin.edu.au/urp/diffuse/ URL: http://caia.swin.edu.au/urp/diffuse/downloads.html Contact: Sebastian Zander Contact: Grenville Armitage DIFFUSE is a system enabling FreeBSD's IPFW firewall subsystem to classify IP traffic based on statistical traffic properties. With DIFFUSE, IPFW computes statistics (such as packet lengths or inter-packet time intervals) for observed flows, and uses ML (machine learning) techniques to assign flows into classes. In addition to traditional packet inspection rules, IPFW rules may now also be expressed in terms of traffic statistics or classes identified by ML classification. This can be helpful when direct packet inspection is problematic (perhaps for administrative reasons, or because port numbers do not reliably identify applications). DIFFUSE also enables one instance of IPFW to send flow information and classes to other IPFW instances, which then can act on such traffic (e.g. prioritise, accept, deny, etc) according to its class. This allows for distributed architectures, where classification at one location in your network is used to control fire-walling or rate-shaping actions at other locations. In December 2010 we released DIFFUSE v0.1, a set of patches for FreeBSD-CURRENT. It can be downloaded from the project's web site. The web site also contains a more comprehensive introduction, including application examples, links to related work and documentation describing the software design. We hope to release DIFFUSE v0.2 soon. Keep an eye on the freebsd-ipfw and freebsd-net mailing lists for project-related announcements. __________________________________________________________________ Ethernet Switch Framework URL: http://loos.no-ip.org/rspro/switch-1.diff Contact: Luiz Otavio O. Souza Implementation of a framework for ethernet switch control (directly connected to the ethernet MAC controller) usually found on embedded systems. Currently based on ifconfig keywords, adds the vlan control (filter/pass) on each switch port and adds the possibility for the management of media state on interfaces with multiple PHYs. Currently, the code supports the IP175D (from some mikrotik routerboards) and AR8316 (from Ubiquiti RSPRO) switches. Open tasks: 1. Finish the IP175C driver (and maybe IP178x). 2. Better integration with miibus (rewrite of switchbus). 3. Fix (some) ifconfig keywords (better keywords, better usage compatibility). 4. Export the ports statistics through SNMP (if available on switch chip). 5. Add a swctl tool (?) for global settings management. 6. Write usage examples and the man page information about the new ifconfig(8) keywords. __________________________________________________________________ Five New TCP Congestion Control Algorithms for FreeBSD URL: http://caia.swin.edu.au/freebsd/5cc/ URL: http://caia.swin.edu.au/urp/newtcp/ URL: http://www.FreeBSDFoundation.org/projects.shtml URL: http://people.FreeBSD.org/~lstewart/patches/5cc/ Contact: David Hayes Contact: Lawrence Stewart Contact: Grenville Armitage Contact: Rui Paulo Contact: Bjoern Zeeb The project is nearing completion, with the following code already available in the svn head branch: * Modular congestion control framework. * Modularised implementations of NewReno, CUBIC and HTCP congestion control algorithms. * Khelp (Kernel Helper) and Hhook (Helper Hook) frameworks. * Basic Khelp/Hhook integration with the TCP stack. The ERTT (Enhanced Round Trip Time) Khelp module is days away from being imported, which will then pave the way for the delay based congestion control algorithms to follow. Finally, a large documentation dump will be committed in the form of new and updated man pages. We anticipate the project will conclude around the end of January 2011. Open tasks: 1. Import the ERTT Khelp module. 2. Import the VEGAS, HD and CHD delay based congestion control algorithm modules. 3. Import the documentation dump for all the code contributed/developed as part of the project. __________________________________________________________________ FOSDEM 2011 URL: http://www.FOSDEM.org Contact: Marius Nuennerich Contact: Daniel Seuffert FOSDEM 2011 will be held from Saturday, February 5th to Sunday February 6th in Brussels, Belgium. We will have a FreeBSD booth and a developers room. At the booth there will be friendly supporters and a FreeBSD Foundation member answering questions. The devroom will have 6 1-hour long talks about different topics, technical and social. FOSDEM is one of the biggest open-source events in Europe. It is completly free and no registration is required. Open tasks: 1. Get more people involved as helpers for the booth and the devroom are still needed. Please contact Daniel or Marius if you want to help out. __________________________________________________________________ FreeBSD 802.11n URL: http://wiki.FreeBSD.org/AdrianChadd/AtherosStuff Contact: Adrian Chadd * Net80211 station mode works in 2.4ghz HT/20 mode. HT/40 and 5ghz do not currently work. * Basic 802.11 TX and RX on the AR9160 works, from MCS0 to MCS15 * TX A-MPDU and A-MSDU do not currently implemented - so no aggregate TX will happen * RX A-MPDU and A-MSDU is implemented and is supposed to work but does not -- this needs to be debugged * 802.11n RTS/CTS protection for legacy packets does not currently work. There is some magic required to fix the TX packet length. This is in progress. * WPA2 now works - a commit which enabled the hardware multicast broke AES-CCMP encryption on at least the AR9160. Further investigation is needed to fix this (and any other hardware encryption bugs that are lurking. __________________________________________________________________ FreeBSD as Home Theater PC URL: http://wiki.FreeBSD.org/HTPC Contact: Bernhard Froehlich Contact: Juergen Lock FreeBSD could be a much better platform for a Home Theater PC than it currently is. We are focusing on improving support for media center applications. Extending the major ports (MythTV, VDR, XBMC) and create some documentation to guide interested people. Open tasks: 1. Improve remote control support in webcamd and with lirc. 2. Port more Media Center applications (Enna, me-tv, ...). 3. Create a small guide on how to build a great FreeBSD Home Theater PC. __________________________________________________________________ FreeBSD Bugbusting Team Status Report URL: http://www.FreeBSD.org/support.html#gnats URL: http://wiki.FreeBSD.org/BugBusting URL: http://people.FreeBSD.org/~linimon/studies/prs/ Contact: Gavin Atkinson Contact: Mark Linimon Contact: Remko Lodder Contact: Volker Werth The number of non-ports PRs has held relatively steady over the last three months, with a slightly improved resolution rate being offset by a slightly increased rate of new arrivals. Ports PRs have increased slightly in numbers, due in part to the ports freeze in the lead up to the release of FreeBSD 7.4 and FreeBSD 8.2. The numbers traditionally drop quickly again once the freeze is lifted. In October, Gavin Atkinson and Mark Linimon held a session at the FreeBSD Developers' Summit at EuroBSDCon, which led to some productive discussions, and a number of people expressing interest in becoming more involved with PR triaging and resolution. The bugbusting team continue work on trying to make the contents of the GNATS PR database cleaner, more accessible and easier for committers to find and resolve PRs, by tagging PRs to indicate the areas involved, and by ensuring that there is sufficient info within each PR to resolve each issue. Reports continue to be produced from the PR database, all of which can be found from the links above. Committers interested in custom reports are encouraged to discuss requirements with bugmeister@ - we are happy to create new reports where needs are identified. As always, anybody interested in helping out with the PR queue is encouraged to do so, the easiest way being to join us on IRC in #freebsd-bugbusters on EFnet. We are always looking for additional help, whether your interests lie in triaging incoming PRs, generating patches to resolve existing problems, or simply helping with the database housekeeping (identifying duplicate PRs, ones that have already been resolved, etc). This is a great way of getting more involved with FreeBSD! Open tasks: 1. Try to find ways to get more committers helping us with closing PRs that the team has already analyzed. 2. Try to get more non-committers involved with the triaging of PRs as they come in, and generating patches to fix reported problems. __________________________________________________________________ FreeBSD on the Playstation 3 Contact: Nathan Whitehorn On January 5, support for the Playstation 3 was imported into FreeBSD 9.0-CURRENT. This port is still somewhat raw (only netbooting is supported, no access to the SPUs, etc.), but hardware support should be more fleshed out by the time FreeBSD 9.0 is released. The port uses the OtherOS mechanism, and so requires a "fat" console with firmware earlier than 3.21. Open tasks: 1. SATA driver. 2. Sound support. 3. SPU driver. __________________________________________________________________ FreeBSD Services Control (fsc) Contact: Tom Rhodes FreeBSD Services Control is a mix of binaries which integrate into the rc.d system and provide for service (daemon) monitoring. It knows about signals, pidfiles, and uses very little resources. The fscd utilities will be set up as a port and, hopefully, dropped into the ports collection in the coming weeks. This will allow easier testing by everyone and it should make migration into -CURRENT much easier. __________________________________________________________________ FreeBSD VirtIO Network Driver URL: http://www.linux-kvm.org/page/Virtio URL: http://lists.FreeBSD.org/pipermail/freebsd-current/2011-January/022036. html Contact: Bryan V. VirtIO is a device framework offered by KVM/Qemu and Virtualbox to allow guests to achieve better I/O performance. A beta network driver was made available earlier this month, and work continues on completing the block device and refinements the existing network driver. __________________________________________________________________ FreeBSD/EC2 URL: http://www.daemonology.net/freebsd-on-ec2/ Contact: Colin Percival FreeBSD is now able to run on t1.micro instances in the Amazon EC2 cloud. FreeBSD 9.0 is not very stable, but it seems likely that FreeBSD 8.2-RELEASE will approach the stability normally expected of FreeBSD. A list of available FreeBSD AMIs (EC2 machine images) appears on the FreeBSD/EC2 status page. Open tasks: 1. Bring FreeBSD to a wider range of EC2 instance types. 2. Completely rework the locking in head/sys/i386/xen/pmap.c to eliminate races and make 9.0-CURRENT stable under paravirtualization. 3. Track down several possibly-related problems with scheduling and timekeeping. 4. Fix other issues shown on the FreeBSD/EC2 status page. __________________________________________________________________ FreeBSD/sparc64 Contact: Marius Strobl CPUTYPE support for sparc64 has been added to CURRENT in r216820. The three flavors currently supported are "ultrasparc", "ultrasparc3" and "v9". So it is now possible to let the compiler produce code optimize for the family of UltraSPARC-III CPUs by setting CPUTYPE to "ultrasparc3". Setting it to "ultrasparc" as well as omitting it completely optimizes for UltraSPARC-I/II family CPUs as before. Support for generating generic 64-bit V9 code was mainly added for reference purposes. As it turned out, at least for SPARC64-V CPUs running code optimized for UltraSPARC-III CPUs does not perform measurably better than UltraSPARC-I/II one though so the default is just fine for these. This change was merged into 7-STABLE in r217005 and into 8-STABLE in r217004 respectively, neither 7.4-RELEASE nor 8.2-RELEASE will include it though. Support for a certain feature available with UltraSPARC-III+ and greater, i.e. with all sun4u CPUs following the original UltraSPARC-III, has been added to CURRENT in r216803. The net effect of this change is that we now can use a kernel TSB and thus a kernel address space of virtually any size up to the full 64-bit address space on machines equipped with these CPUs, apart from the fact that 1GB of address space still takes up 4MB worth of data structures. Before, the theoretical limit was 16GB due to the fact that the MMUs of these UltraSPARC CPUs only have 16 lockable TLB slots (UltraSPARC-I/II have 64 and SPARC64 CPUs again have at least 32), with the actual limit being several GB below that because we need some of these slots also for mapping the PROM, the kernel itself and in MP-systems the per-CPU page. Currently, the kernel TSB and thus the kernel virtual address space is now always sized one time the physical memory present in these machines with the plan being to actually allow to it extend beyond the size of the RAM as this helps especially ZFS. Most of this is implemented by patching the instructions used to access the kernel TSB based on the CPU present, so the run-time overhead of this change is rather low. Once it is also enabled and successfully tested with SPARC64 CPUs this change will be merged back into the supported stable branch(es). Theoretically it should be also possible to use the same approach for the user TSB, which already is not locked into the TLB but can cause nested traps. However, for reasons I do not understand yet, OpenSolaris only does this with SPARC64 CPUs. On the other hand I think that also using it for the user TSB and thus avoiding nested traps would get us closer to running the FreeBSD/sparc64 code on machines equipped with sun4v CPUs, which only supports trap level 0 and 1, too, so eventually we could have a single kernel which runs on both sun4u and sun4v machines (as does Linux and OpenBSD). Work on adding support for Sun Fire 3800 and similar models has begun but still is in its early stages. __________________________________________________________________ Generic IEEE 802.3 annex 31B full duplex flow control support for Ethernet in mii(4) URL: http://en.wikipedia.org/wiki/Ethernet_flow_control Contact: Marius Strobl In r213878 a NetBSD-compatible mii_attach() was added to mii(4) as an replacement for mii_phy_probe() and subsequently all Ethernet device drivers in the tree which use this framework were converted to take advantage of the former. This allowed to considerably clean up mii(4) as well as the converted MAC and PHY drivers and get rid of quite a few hacks, amongst others the infamous "EVIL HACK". However, the main motivation of this change was to allow the addition of generic IEEE 802.3 annex 31B full duplex flow control support to mii(4), which was ported from NetBSD but also enhanced and fixed quite a bit and committed in r215297. Along with this bge(4), bce(4), msk(4), nfe(4) and stge(4) as well as brgphy(4), e1000phy(4) and ip1000phy(4), which previously all implemented their own flow control support based on mostly undocumented special media flags separately, were converted to take advantage of the generic support. At least for CURRENT this means that these drivers now no longer unconditionally advertise support for flow control but only do so if flow control was selected as media option. The reason for implementing the generic flow control support that way was to allow it to be switched on and off via ifconfig(8) with the PHY specific default to typically being off in order to protect from unwanted effects. Subsequently support for flow control based on the generic support was added to alc(4), fxp(4), cas(4), gem(4), jme(4), re(4) and xl(4) as well as atphy(4), bmtphy(4), gentbi(4), inphy(4), jmphy(4), nsgphy(4), nsphyter(4) and rgephy(4). For several of the remaining Ethernet drivers it also would only require minor changes to enable flow control support if supported by the respective MAC. Due to the fact that each implementation should be thoroughly tested and tuned this was only done for drivers were hardware was available though. An example for identifying support for flow control based on the generic implementation in the dmesg-output for a certain MAC-PHY-combination would be: bge0: mem 0 xfe010000-0xfe01ffff,0xfe000000-0xfe00ffff irq 25 at device 2.0 on pci2 bge0: CHIP ID 0x00002003; ASIC REV 0x02; CHIP REV 0x20; PCI-X miibus0: on bge0 brgphy0: PHY 1 on miibus0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow or in the output of ifconfig -m for a given device: supported media: media autoselect mediaopt flowcontrol The latter also is what one would use to enable flow control for such a device, i.e.: ifconfig bge0 media autoselect mediaopt flowcontrol or in order to turn it off again: ifconfig bge0 media autoselect -mediaopt flowcontrol Note that some PHY drivers, currently only rgephy(4) though, also support enabling flow control support when using manual media configuration like in the following example: ifconfig re0 media autoselect mediaopt full-fuplex,flowcontrol In CURRENT this can also be further abbreviated (support for this will eventually be merged back into the supported stable branch(es) but not be present in 7.4-RELEASE or 8.2-RELEASE) as: ifconfig re0 media auto mediaopt fdx,flow For a device which has successfully negotiated flow control support with its link partner will report it in the output of ifconfig along with the available directions like in the following example: media: Ethernet autoselect (100baseTX ) Another thing that was introduced with r215297 was generic support for setting 1000baseT master mode via a media option when using manual media configuration. Consequently, brgphy(4), ciphy(4), e1000phy(4) as well as ip1000phy(4) have been converted to take advantage of this generic support. At least for CURRENT this means that these drivers now no longer take the link0 parameter for selecting master mode but the master media option has to be used instead like in the following example: ifconfig bge0 media 1000baseT mediaopt full-duplex,master Selection of master mode now is also available with all other PHY drivers supporting 1000baseT. With the exception of the media option abbreviations all of the above mentioned changes were merged into 7-STABLE in r215879 and into 8-STABLE in r215881 respectively. This means that they will be part of 7.4-RELEASE and 8.2-RELEASE. In order to no break POLA, unlike as in CURRENT bge(4), bce(4), msk(4), nfe(4) and stge(4) were changed to continue to always advertise support of flow control to their link partners in these stable branches with no way to turn that off as they also did before with their custom implementations. Additionally, brgphy(4), ciphy(4), e1000phy(4) as well as ip1000phy(4) were changed to still also accept the link0 parameter in addition to the master media option for setting master mode. Open tasks: 1. We actually miserably fail to properly document the available media types and options in manual pages. For example several of the media lists in manual pages of MAC drivers like bge(4) already were outdated and with the addition of generic flow control and 1000baseT master mode support these are now even more outdated. Yet worse is the fact that for MAC drivers which use the mii(4) framework it is technically just plain wrong to include these lists in their manual page as the PHY drivers actually are responsible for handling the media types and options. However, given that the PHY drivers determine the available media types and options mostly dynamically at run-time it generally makes no sense to have static documentation of these in their manual pages (apart from the fact that we currently have no manual pages for PHY drivers). One good way out of this should be to replace the media lists in MAC drivers using mii(4) with just a note to check the output of ifconfig -m to get a list of the media types and options actually supported by a given device and to add a generic ifmedia(4) manual page which provides some general background information about media types and options similar to what NetBSD and OpenBSD also have. __________________________________________________________________ GEOM-based ataraid(4) Replacement -- geom_raid URL: http://people.FreeBSD.org/~mav/graid_design.h URL: http://svn.FreeBSD.org/viewvc/base/projects/graid/ Contact: Alexander Motin Contact: M. Warner Losh New project started to create GEOM-based replacement for ataraid(4) -- software RAID, that will be obsoleted by migration to the new CAM-based ATA implementation. This implementation planned with accent to modular design, that includes common core and two sets of modules, handling data transformations (RAID levels) and on-disk metadata formats specifics. Such design should make further extension easier. At this moment work focused around RAID0/RAID1 transformations and Intel metadata format. Module is now able to read, write and create Intel volumes. Error recovery and rebuild work is now in progress. Support for other RAID levels and metadata formats, supported by ataraid(4), planned later. This project is sponsored by Cisco Systems, Inc. Open tasks: 1. Complete error recovery/rebuild work and stabilize modules API. 2. Implement metadata modules for other formats. 3. Implement transformation modules for other RAID levels. __________________________________________________________________ gpart Improvements Contact: Andrey V. Elsukov GEOM class PART is the default disk partitioning class since FreeBSD 8.0. Compared to 8.1 now it does have several new features: Partition resizing. New "gpart resize" subcommand was implemented for all partitioning schemes but EBR. GPT recovering. Guid Partition Table does have redundant metadata and it can be recovered when some of them is damaged. New "gpart recover" subcommand was implemented for that purpose. Ability to backup/restore of partition table. New "gpart backup" and "gpart restore" subcommands were implemented. __________________________________________________________________ IPv6 and VIMAGE URL: http://ecdysis.viagenie.ca/ Contact: Bjoern A. Zeeb During the last quarter a lot of work was spent on quality time hunting down and fixing open bugs and races in the network stack, mostly IPv6, as well as testing and getting virtualized network stack parts more stable. Tests for the pf(4) firewall update were started with VIMAGE. In addition Viagenie's NAT64 patch was ported over. __________________________________________________________________ mdocml Replacing groff For manpage Rendering URL: http://mdocml.bsd.lv/ URL: https://www.spoerlein.net/cgit/cgit.cgi/freebsd.work/log/?h=mdocml Contact: Ulrich Sprlein Kristaps' groff-replacement (only for rendering manual pages) is already available in NetBSD and OpenBSD, and used to render the base system manpages for the latter. This project aims to do similar things for FreeBSD. Since the last status report, mdocml has grown rudimentary tbl(1) support and a whole lot of bugfixes have gone in. A groff port has been created and needs some more testing before it can be committed to the tree. Also the WITHOUT_GROFF support in base has been fleshed out and is awaiting review before commit. Open tasks: 1. Get ru@ to review WITHOUT_GROFF changes. 2. Get textproc/groff tested and committed. 3. Push more mdoc fixes into the tree. 4. Import mandoc(1), switch to catpages for base. Discuss future of groff in base wrt. share/doc. 5. Supply necessary ports infrastructure to opt-in to mandoc(1). __________________________________________________________________ Non-executable Stacks Contact: Konstantin Belousov The support for non-executable stacks, using the approach identical to one used by GNU toolchain and Linux'es, is implemented for amd64 and PowerPC. The support is already committed to HEAD. For now, non-executable stacks are turned off by default. I plan to provide a detailed information to ports@ and switch the knob after port tree is unfrozed for 7.4/8.2 releases. __________________________________________________________________ Port-Sandbox URL: http://www.arjmobile.com/Marcelo_Araujo/Blog/Entries/2010/11/22_Port-sa ndbox.html URL: http://gitorious.org/port-sandbox/port-sandbox/trees/master URL: http://www.arjmobile.com/Marcelo_Araujo/My_Albums/Pages/Port-Sandbox.ht ml Contact: Marcelo Araujo Port-Sandbox now works properly and it is able to run by itself through an embedded web server and bring a lot of information about the port build process and all dependencies related. Currently Port-Sandbox is in the final stage and needs only only a few code changes, more tests and should also be included in the ports tree. Open tasks: 1. Change the way how it connects to database, fix it to maintain a persistent connection. 2. Remove any kind of internal configuration from source code to an external file configuration. 3. Create a Port-Sandbox port with all dependencies related to it and test it in a clean system. 4. Create some documentation to let other people to keep helping Port-Sandbox to grow up. 5. Finally, release it. __________________________________________________________________ Portmaster URL: http://dougbarton.us/portmaster-proposal.html Contact: Doug Barton Portmaster version 3.6.1 is now in the ports tree, and the emphasis in the last year has been on improving the stability and performance of existing features, with a few new features sprinkled in. A lot of work has gone into error handling, both for unexpected states in the ports system and for user input. For example, all prompts are now wrapped in code to verify that what was entered was one of the valid options. Perhaps the most interesting new element is that for the features -e, -s, --clean-distfiles, --clean-packages, --check-depends and --check-port-dbdir you can now specify either -y or -n to automatically provide the corresponding answer to the yes/no questions. The -o, -r, and --index-only options have received major overhauls, and now either work better or at least as advertised. There has also been a lot of work put into reducing the memory footprint, especially in the environment variables that are shared between the parent and child processes. And for those operating without a local ports tree (--index-only/--packages-only) all of the features that can work without the ports tree now do. Significant support for the upgrading of operating without a ports tree was provided by GridFury, LLC. Their support, as well as the support received from other members of the community continues to be greatly appreciated. Open tasks: 1. There are still interesting features that have been suggested by users listed on the page above that I have not been able to work on, but would like to be able to. __________________________________________________________________ Ports Additions URL: http://bigbluebutton.org URL: http://smb4k.berlios.de/ URL: http://www.freeswitch.org/ Contact: Josh Paetzel Bigbluebutton has joined the list of ready to run applications in the ports tree. Dru Lavigne has been instrumental on getting it to run, as well as offering suggestions for improvements to the port. smb4k was updated to the latest release version, which requires kde4. This was enough of a change that a new port was created, net/smb4k-kde4. the initial port went through a number of quick changes, including a patch to the source code to fix a FreeBSD source code submitted by PC-BSD's Kris Moore. This application greatly eases the task of working with samba shares in a FreeBSD environment. Freeswitch is the result of 3 Asterisk developers working on a VoIP package that fulfills their goals. They have switched away from a release model to a "just run latest SVN checkout" model. With the help of Richard Neese and Eric Crist, static snapshots of their SVN repo have been taken, the port has been modified to use the newer version, and extensive build and run testing has been done. __________________________________________________________________ Ports Collection URL: http://www.FreeBSD.org/ports/ URL: http://www.FreeBSD.org/doc/en_US.ISO8859-1/articles/contributing-ports/ URL: http://portsmon.FreeBSD.org/index.html URL: http://www.FreeBSD.org/portmgr/index.html URL: http://blogs.FreeBSDish.org/portmgr/ URL: http://www.twitter.com/freebsd_portmgr/ URL: http://www.facebook.com/group.php?gid=135441496471197 URL: http://tinderbox.marcuscom.com/ Contact: Thomas Abthorpe Contact: Port Management Team The ports tree slowly moves up closer to 23,000. The PR count still remains at about 1000. In Q4 we added 2 new committers, took in 2 commit bit for safe keeping, and welcomed back 4 returning committers. The Ports Management team bid farewell to Kris Kennaway in November 2010. Kris was the root of krismail, the mail we all got from time to time when ports broke on pointyhat. Kris did a lot of work benchmarking and testing FreeBSD for stability, scalability and usability. Mark Linimon has put a lot of effort into refactoring and refining the code that runs the 'pointyhat' package build dispatch system. In 2010, the FreeBSD Foundation purchased for portmgr a pair of new machines, pointyhat-west and pointyhat-east, to take over from the existing machine. (The new machines have much greater RAM, CPU, and disk capacity.) However, to properly utilize them, the existing code needed to be generalized. Persistent bugs, and some hardware troubles, have delayed the rollout far beyond what was originally planned, but there appears to be light at the end of the tunnel. (And, this time, it does not appear to be an oncoming train.) A document entitled "Mentoring Guidelines" as been circulated among ports developers, and has been greeted with a lot of positive feedback, and updates have been included. In the short term, updated copies will be maintained at http://people.FreeBSD.org/~portmgr/mentor_guidelines.txt.asc. The Ports Management team have been running -exp runs on an ongoing basis, verifying how base system updates may affect the ports tree, as well as providing QA runs for major ports updates. Of note, -exp runs were done for: * ade: multiple runs for autotools refactoring * ed: test to replace libgcc.a with libcompiler_rt.a * jiles: test sh(1) against r212508 * kde: Qt 4.7.0 update * kde: KDE 4.5.4 updte * kwm: Gnome 2.32 update * ports/144164: ensure package-noinstall target include rc.d scripts * ports/145598: include etc/devd in mtree * ports/145955: silence make fetch-required-list * ports/147701: perform DESKTOP_ENTRIES sanity check * ports/149657: removal of MD5 checksums * ports/149670: remove checks in _OPTIONSFILE * ports/150303: for INSTALL_LIBS * ports/150337: for PLIST_DIRSTRY * ports/151047: pass CPP to CONFIGURE/MAKE_ENV * ports/151799: fix PLIST_DIRSTRY * ports/151806: remove 2004 legacy hack * ports/152055 and ports/152059: for pear infrastructure * ports/152558: boost update * ports/152626: fix pkg-message display if installed from package * ports/152964: embed LICENSE name for STDOUT * ports/153018: implement variables in Mozilla dependencies * ports/153033: fix un-escaped shell metacharacters * ports/153041: clean up ruby plists * ports/153132: autotools cleanup * ports/153318: set PGSQL default to 8.4 Open tasks: 1. Looking for help fixing ports broken on CURRENT. 2. Looking for help with Tier-2 architectures. 3. Most ports PRs are assigned, we now need to focus on testing, committing and closing. __________________________________________________________________ Release Engineering Team Status Report URL: http://www.FreeBSD.org/releng/ Contact: Release Engineering Team The Release Engineering Team reports the joint release of FreeBSD 7.4 and 8.2 has been delayed slightly but should be completed within a week or two of the original schedule: http://www.FreeBSD.org/releases/7.4R/schedule.html http://www.FreeBSD.org/releases/8.2R/schedule.html __________________________________________________________________ Resource Containers Contact: Edward Tomasz Napierala The goal of this project is to implement resource containers and a per-jail resource limits mechanism, so that system administrators can partition resources like memory or CPU between jails and prevent users from DoS-ing the whole system. Project is close to completion. One big item that needs to be fixed before releasing a patch for people to test is %CPU accounting; initial idea of just using %CPU calculated by the scheduler turned out to be useless. Implementing it cleanly will also make it easier to support other similar resources (e.g. writes-per-second) in the future. __________________________________________________________________ Robot Operating System URL: http://www.ros.org/wiki/ URL: ftp://rene-ladan.nl/pub/ros-freebsd.pdf Contact: Ren Ladan Porting ROS to FreeBSD started in March 2010. In May 2010, it was possible to build devel/ros without needing to apply patches, but some more changes were necessary to be able to write a port for it. Currently this and several other ports related to ROS are available, most notably devel/ros-tutorials to get up and running with ROS and devel/ros-nxt to use LEGO Mindstorms NXT robots with ROS and FreeBSD. Open tasks: 1. Port the software required for nxt-rviz-plugin, which is part of devel/ros-nxt but currently excluded from the build. __________________________________________________________________ SYSCTL Type Safety Contact: Matthew Fleming I started upstreaming a patch from Isilon that adds type-checking to the various SYSCTL_FOO and SYSCTL_ADD_FOO macros for various scalar types, which has turned into quite the discussion on the src mailing list. The type-checking macros are committed to sys/sysctl.h but under #if 0. Open tasks: 1. As of right now, it looks like I will be rolling a new sysctl macro for the kernel that detects they type at compile time and does the Right Thing. Existing uses of the legacy SYSCTL_FOO and SYSCTL_ADD_FOO for scalar types can be replaced, and will probably turn into invocations of the new interface via preprocessor macro. __________________________________________________________________ TCP SMP scalability project Contact: Robert Watson A long-running TCP SMP scalability project is beginning to wrap up, with the goal of committing a large outstanding patch to the FreeBSD 9.x tree in the next month. This work implements a derivative of Willman, Rixner, and Cox's TCP connection group model, blended with support for hardware load distribution features in contemporary NICs (including RSS). Additional software distribution support can do work redistribution based on new notions of CPU affinity for individual TCP connections. On-going work is refining performance on non-RSS supporting configurations, and adding APIs to allow socket affinity to be queried (and where supported) set by applications. These changes significantly improve network scalability by reducing global lock contention, encouraging CPU affinity for connections, and avoiding cache line contention. The goal is to allow steady-state TCP connections to use only CPU-local cache lines, with work distributed to all CPUs. Current performance results are extremely promising. This project has been sponsored by Juniper Networks. Open tasks: 1. Allow the hash model to be selected at boot-time or run-time rather than compile-time; currently "options RSS" enables RSS support unconditionally -- for systems without RSS NICs, this leads to a small one-time performance penalty at the creation of each call to bind() or connect(). 2. Add missing socket options to query (and override) default CPU affinity for connections, which is derived from the active software or hardware hash model. 3. Teach the network stack and appropriate NIC drivers to propagate software-overridden connection affinity to hardware using new device driver ioctls for managing TCAMs and hardware hash tables. 4. Refine software redistribution of work in the event that there are fewer hardware queues than available CPU threads in which to process packets; the current prototype is able to do this with significant performance benefits, but the model requires refining. 5. Experiment with (and measure) software work redistribution at run-time based on RSS bucket rearrangement. This will require a new event notification to device drivers so that they can update hardware caches of the network stack's authoritative table. 6. Commit. __________________________________________________________________ The FreeBSD Foundation Status Report URL: http://www.FreeBSDFoundation.org Contact: Deb Goodkin We raised $325,000 towards our goal of $350,000 for 2010! This will allow us to increase our project development and equipment spending for 2011. We were proud to be a sponsor for EuroBSDCon 2010, BSDDay Argentina 2010, MeetBSD California 2010, and NYBSDCon 2010. Completed the Foundation funded projects: DAHDI Project by Max Khon and BSNMP Improvements by Shteryana Sotirova. We kicked off a new project by the University of Melbourne called Feed-Forward Clock Synchronization Algorithms Project. The Five New TCP Congestion Control Algorithms for FreeBSD Project by Swinburne University also officially started. We continued our work on infrastructure projects to beef up hardware for package-building, network-testing, etc. This includes purchasing equipment as well as managing equipment donations. Stop by and visit with us at FOSDEM (Feb 5-6), SCALE (Feb 26), AsiaBSDCon (March 17-20), and Indiana Linuxfest (March 26). Read more about how we supported the project and community by reading our end-of-year newsletter at: http://www.FreeBSDFoundation.org/press/2010Dec-newsletter.shtml. We are fund-raising for 2011 now! Find out more at http://www.FreeBSDFoundation.org/donate/. __________________________________________________________________ The FreeBSD German Documentation Project Status Report URL: http://doc.bsdgroup.de Contact: Johann Kois Contact: Benedict Reuschling The committers to the German Documentation Project managed to update the German documentation just in time to get the changes included into the next FreeBSD releases. The website translations were also kept in sync with the ones on FreeBSD.org. We tried to re-activate committers who did not contribute for some time but most of them are currently unable to free up enough time. We hope to gain fresh contributor blood as we are getting occasional reports about bugs and grammar in the german translation. Open tasks: 1. Submit grammar, spelling or other errors you find in the german documents and the website. 2. Translate more articles and other open handbook sections. __________________________________________________________________ The FreeBSD Japanese Documentation Project URL: http://www.FreeBSD.org/ja/ URL: http://www.jp.FreeBSD.org/doc-jp/ Contact: Hiroki Sato Contact: Ryusuke Suzuki Although there is no radical change in this effort since the last report, the www/ja and doc/ja_JP.eucJP/books/handbook have constantly been updated. During this period, generating translated RSS feed for newsflash was started and links to the manual pages were fixed in the Books and Articles documentation. Some more progress has been made in the Porter's Handbook and Contributing to FreeBSD as well. Open tasks: 1. Further translation of the FreeBSD Handbook and contents of the www.FreeBSD.org website to the Japanese language. 2. Pre-/post-commit review of the translation. __________________________________________________________________ TRIM support for UFS Contact: Kirk McKusick Contact: Konstantin Belousov TRIM support for UFS is implemented in HEAD. Potentially, this may increase the steady speed and longevity of SSDs. Due to concerns with the speed of TRIM operations on many SSDs, and not a lot of experience with the real-world behaviour, the support is off by default, and should be enabled on the per-filesystem basis. __________________________________________________________________ Webcamd URL: http://www.selasky.org/hans_petter/video4bsd URL: http://www.freshports.org/multimedia/webcamd/ Contact: Hans Petter Selasky Webcamd is a small daemon that enables about 1500 different USB based webcam, DVB and remote control USB devices under the FreeBSD-8.0 and later operating system. The webcam daemon is basically an application which is a port of Video4Linux USB drivers into userspace on FreeBSD. The daemon currently depends on libc, pthreads, libusb and libcuse4bsd. During Q3 2010 webcamd got manpages thanks to Dru Lavigne. Open tasks: 1. I hope to get a Google summer of code project this year building the default Linux Kernel 2.6.37+ and allowing use of relevant Linux USB device drivers under FreeBSD. Webcamd is not a replacement for native FreeBSD kernel drivers and will only be used when no existing FreeBSD drivers exist for a given device staying clear of any GPLv2 issues. If you are a student and/or is interested in participating in such a project feel free to send an e-mail to hselasky@FreeBSD.org. __________________________________________________________________ xz Compression for Packages and Log Files Contact: Martin Matuska Creating and processing xz-compressed packages is now supported by pkg_create(1), pkg_add(1) and bsdtar(1) in both 9-CURRENT and 8-STABLE. Users can test working with .txz packages by adding "PKG_SUFX=.txz" into /etc/make.conf. The ports-mgmt/portupgrade utility supports .txz packages from version 2.4.8 and a patch for ports-mgmt/portmaster has been submitted but not yet accepted by the author. A patch for newsyslog(8) with a rewrite of the use of compression tools supporting xz compression is under maintainer review. Open tasks: 1. Import xz(1) compression support into newsyslog(8). 2. Add .txz package support to ports-mgmt/portmaster. 3. Add .txz package support to the FreeBSD port building cluster (pointyhat). 4. Test building all packages in .txz format and compare results with .tbz. __________________________________________________________________ ZFS pool version 28 URL: http://lists.freebsd.org/pipermail/freebsd-fs/2010-December/010292.html URL: http://lists.freebsd.org/pipermail/freebsd-fs/2010-December/010321.html Contact: Pawel Jakub Dawidek Contact: Martin Matuska A new version of the ZFS pool v28 patch was released for testing, this time for 9-CURRENT and 8-STABLE. Compared to the previous patch it does include updated boot support, improved sendfile(2) handling, a compatibility layer with older ZFS and several other bugfixes. If there are no major issues we can expect ZFS v28 imported into the FreeBSD-CURRENT after 8.2 is released. Open tasks: 1. Import of ZFS v28 into FreeBSD-CURRENT. __________________________________________________________________ 2011 The FreeBSD Project. All rights reserved. From owner-freebsd-stable@FreeBSD.ORG Tue Jan 25 16:24:33 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 67A6D1065675 for ; Tue, 25 Jan 2011 16:24:33 +0000 (UTC) (envelope-from ml@my.gd) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 0763A8FC1C for ; Tue, 25 Jan 2011 16:24:30 +0000 (UTC) Received: by fxm16 with SMTP id 16so5820638fxm.13 for ; Tue, 25 Jan 2011 08:24:29 -0800 (PST) Received: by 10.223.103.4 with SMTP id i4mr5922589fao.123.1295972669629; Tue, 25 Jan 2011 08:24:29 -0800 (PST) Received: from dfleuriot.local ([83.167.62.196]) by mx.google.com with ESMTPS id c11sm5119587fav.2.2011.01.25.08.24.27 (version=SSLv3 cipher=RC4-MD5); Tue, 25 Jan 2011 08:24:28 -0800 (PST) Message-ID: <4D3EF93B.2030606@my.gd> Date: Tue, 25 Jan 2011 17:24:27 +0100 From: Damien Fleuriot User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "freebsd-stable@freebsd.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: PORTS : jpeg checksum mismatch X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2011 16:24:33 -0000 Hello list, I'm getting nervous here, I seem to get a checksum mismatch for port graphics/jpeg , whether I'm using a mirror or the master sites. See below: # make ===> Vulnerability check disabled, database not found ===> License check disabled, port has not defined LICENSE ===> Extracting for jpeg-8_3 => SHA256 Checksum OK for jpeg8b/jpegsrc.v8b.tar.gz. => SHA256 Checksum mismatch for jpeg8b/jpegexiforient.c. => SHA256 Checksum OK for jpeg8b/exifautotran.txt. ===> Refetch for 1 more times files: jpeg8b/jpegexiforient.c ===> Vulnerability check disabled, database not found ===> License check disabled, port has not defined LICENSE => jpegexiforient.c doesn't seem to exist in /usr/ports/distfiles/jpeg8b. => Attempting to fetch from http://sylvana.net/jpegcrop/. ===> Vulnerability check disabled, database not found ===> License check disabled, port has not defined LICENSE => SHA256 Checksum OK for jpeg8b/jpegsrc.v8b.tar.gz. => SHA256 Checksum mismatch for jpeg8b/jpegexiforient.c. => SHA256 Checksum OK for jpeg8b/exifautotran.txt. ===> Giving up on fetching files: jpeg8b/jpegexiforient.c Make sure the Makefile and distinfo file (/usr/ports/graphics/jpeg/distinfo) are up to date. If you are absolutely sure you want to override this check, type "make NO_CHECKSUM=yes [other args]". *** Error code 1 Stop in /usr/ports/graphics/jpeg. *** Error code 1 Stop in /usr/ports/graphics/jpeg. Apparently the port hasn't been updated since 06/01/11. http://www.freshports.org/graphics/jpeg/ Anyone else encountering the same problem on 8.1-RELEASE ? I sync'ed the ports tree just today. Regards, dfl From owner-freebsd-stable@FreeBSD.ORG Tue Jan 25 16:28:06 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 644621065670 for ; Tue, 25 Jan 2011 16:28:06 +0000 (UTC) (envelope-from spawk@acm.poly.edu) Received: from acm.poly.edu (acm.poly.edu [128.238.9.200]) by mx1.freebsd.org (Postfix) with ESMTP id 02E148FC15 for ; Tue, 25 Jan 2011 16:28:05 +0000 (UTC) Received: (qmail 2854 invoked from network); 25 Jan 2011 16:28:05 -0000 Received: from unknown (HELO ?10.0.0.179?) (spawk@128.238.64.31) by acm.poly.edu with CAMELLIA256-SHA encrypted SMTP; 25 Jan 2011 16:28:05 -0000 Message-ID: <4D3EFA1E.5020405@acm.poly.edu> Date: Tue, 25 Jan 2011 11:28:14 -0500 From: Boris Kochergin User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.12) Gecko/20101106 Thunderbird/3.1.6 MIME-Version: 1.0 To: Damien Fleuriot References: <4D3EF93B.2030606@my.gd> In-Reply-To: <4D3EF93B.2030606@my.gd> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-stable@freebsd.org" Subject: Re: PORTS : jpeg checksum mismatch X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2011 16:28:06 -0000 On 01/25/11 11:24, Damien Fleuriot wrote: > Hello list, > > > > I'm getting nervous here, I seem to get a checksum mismatch for port > graphics/jpeg , whether I'm using a mirror or the master sites. > > See below: > > # make > ===> Vulnerability check disabled, database not found > ===> License check disabled, port has not defined LICENSE > ===> Extracting for jpeg-8_3 > => SHA256 Checksum OK for jpeg8b/jpegsrc.v8b.tar.gz. > => SHA256 Checksum mismatch for jpeg8b/jpegexiforient.c. > => SHA256 Checksum OK for jpeg8b/exifautotran.txt. > ===> Refetch for 1 more times files: jpeg8b/jpegexiforient.c > ===> Vulnerability check disabled, database not found > ===> License check disabled, port has not defined LICENSE > => jpegexiforient.c doesn't seem to exist in /usr/ports/distfiles/jpeg8b. > => Attempting to fetch from http://sylvana.net/jpegcrop/. > ===> Vulnerability check disabled, database not found > ===> License check disabled, port has not defined LICENSE > => SHA256 Checksum OK for jpeg8b/jpegsrc.v8b.tar.gz. > => SHA256 Checksum mismatch for jpeg8b/jpegexiforient.c. > => SHA256 Checksum OK for jpeg8b/exifautotran.txt. > ===> Giving up on fetching files: jpeg8b/jpegexiforient.c > Make sure the Makefile and distinfo file (/usr/ports/graphics/jpeg/distinfo) > are up to date. If you are absolutely sure you want to override this > check, type "make NO_CHECKSUM=yes [other args]". > *** Error code 1 > > Stop in /usr/ports/graphics/jpeg. > *** Error code 1 > > Stop in /usr/ports/graphics/jpeg. > > > > > Apparently the port hasn't been updated since 06/01/11. > http://www.freshports.org/graphics/jpeg/ > > > Anyone else encountering the same problem on 8.1-RELEASE ? > I sync'ed the ports tree just today. > > > Regards, > > dfl > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" Works here, but with a ports tree from about six hours ago: root@staging /usr/ports/graphics/jpeg # make ===> Vulnerability check disabled, database not found ===> License check disabled, port has not defined LICENSE => jpegsrc.v8b.tar.gz doesn't seem to exist in /tmp/ports/distfiles/jpeg8b. => Attempting to fetch from http://www.ijg.org/files/. jpegsrc.v8b.tar.gz 100% of 942 kB 1368 kBps => jpegexiforient.c doesn't seem to exist in /tmp/ports/distfiles/jpeg8b. => Attempting to fetch from http://sylvana.net/jpegcrop/. jpegexiforient.c 100% of 8192 B 45 kBps => exifautotran.txt doesn't seem to exist in /tmp/ports/distfiles/jpeg8b. => Attempting to fetch from http://sylvana.net/jpegcrop/. exifautotran.txt 100% of 684 B 2807 kBps ===> Extracting for jpeg-8_3 => SHA256 Checksum OK for jpeg8b/jpegsrc.v8b.tar.gz. => SHA256 Checksum OK for jpeg8b/jpegexiforient.c. => SHA256 Checksum OK for jpeg8b/exifautotran.txt. ... # uname -a FreeBSD staging.poly.edu 8.1-RELEASE-p1 FreeBSD 8.1-RELEASE-p1 #2: Fri Oct 8 17:53:40 EDT 2010 spawk@staging.poly.edu:/usr/obj/usr/src/sys/STAGING amd64 -Boris From owner-freebsd-stable@FreeBSD.ORG Tue Jan 25 16:30:45 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1CA2D106566C for ; Tue, 25 Jan 2011 16:30:45 +0000 (UTC) (envelope-from ml@my.gd) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id ACF8D8FC20 for ; Tue, 25 Jan 2011 16:30:44 +0000 (UTC) Received: by fxm16 with SMTP id 16so5827891fxm.13 for ; Tue, 25 Jan 2011 08:30:43 -0800 (PST) Received: by 10.223.100.15 with SMTP id w15mr1843613fan.121.1295973043195; Tue, 25 Jan 2011 08:30:43 -0800 (PST) Received: from dfleuriot.local ([83.167.62.196]) by mx.google.com with ESMTPS id a2sm5128197faw.46.2011.01.25.08.30.41 (version=SSLv3 cipher=RC4-MD5); Tue, 25 Jan 2011 08:30:41 -0800 (PST) Message-ID: <4D3EFAB0.9020307@my.gd> Date: Tue, 25 Jan 2011 17:30:40 +0100 From: Damien Fleuriot User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Boris Kochergin References: <4D3EF93B.2030606@my.gd> <4D3EFA1E.5020405@acm.poly.edu> In-Reply-To: <4D3EFA1E.5020405@acm.poly.edu> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "freebsd-stable@freebsd.org" Subject: Re: PORTS : jpeg checksum mismatch X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2011 16:30:45 -0000 On 1/25/11 5:28 PM, Boris Kochergin wrote: > On 01/25/11 11:24, Damien Fleuriot wrote: >> Hello list, >> >> >> >> I'm getting nervous here, I seem to get a checksum mismatch for port >> graphics/jpeg , whether I'm using a mirror or the master sites. >> >> See below: >> >> # make >> ===> Vulnerability check disabled, database not found >> ===> License check disabled, port has not defined LICENSE >> ===> Extracting for jpeg-8_3 >> => SHA256 Checksum OK for jpeg8b/jpegsrc.v8b.tar.gz. >> => SHA256 Checksum mismatch for jpeg8b/jpegexiforient.c. >> => SHA256 Checksum OK for jpeg8b/exifautotran.txt. >> ===> Refetch for 1 more times files: jpeg8b/jpegexiforient.c >> ===> Vulnerability check disabled, database not found >> ===> License check disabled, port has not defined LICENSE >> => jpegexiforient.c doesn't seem to exist in >> /usr/ports/distfiles/jpeg8b. >> => Attempting to fetch from http://sylvana.net/jpegcrop/. >> ===> Vulnerability check disabled, database not found >> ===> License check disabled, port has not defined LICENSE >> => SHA256 Checksum OK for jpeg8b/jpegsrc.v8b.tar.gz. >> => SHA256 Checksum mismatch for jpeg8b/jpegexiforient.c. >> => SHA256 Checksum OK for jpeg8b/exifautotran.txt. >> ===> Giving up on fetching files: jpeg8b/jpegexiforient.c >> Make sure the Makefile and distinfo file >> (/usr/ports/graphics/jpeg/distinfo) >> are up to date. If you are absolutely sure you want to override this >> check, type "make NO_CHECKSUM=yes [other args]". >> *** Error code 1 >> >> Stop in /usr/ports/graphics/jpeg. >> *** Error code 1 >> >> Stop in /usr/ports/graphics/jpeg. >> >> >> >> >> Apparently the port hasn't been updated since 06/01/11. >> http://www.freshports.org/graphics/jpeg/ >> >> >> Anyone else encountering the same problem on 8.1-RELEASE ? >> I sync'ed the ports tree just today. >> >> >> Regards, >> >> dfl >> _______________________________________________ >> freebsd-stable@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > > Works here, but with a ports tree from about six hours ago: > > root@staging /usr/ports/graphics/jpeg # make > ===> Vulnerability check disabled, database not found > ===> License check disabled, port has not defined LICENSE > => jpegsrc.v8b.tar.gz doesn't seem to exist in /tmp/ports/distfiles/jpeg8b. > => Attempting to fetch from http://www.ijg.org/files/. > jpegsrc.v8b.tar.gz 100% of 942 kB 1368 kBps > => jpegexiforient.c doesn't seem to exist in /tmp/ports/distfiles/jpeg8b. > => Attempting to fetch from http://sylvana.net/jpegcrop/. > jpegexiforient.c 100% of 8192 B 45 kBps > => exifautotran.txt doesn't seem to exist in /tmp/ports/distfiles/jpeg8b. > => Attempting to fetch from http://sylvana.net/jpegcrop/. > exifautotran.txt 100% of 684 B 2807 kBps > ===> Extracting for jpeg-8_3 > => SHA256 Checksum OK for jpeg8b/jpegsrc.v8b.tar.gz. > => SHA256 Checksum OK for jpeg8b/jpegexiforient.c. > => SHA256 Checksum OK for jpeg8b/exifautotran.txt. > ... > > # uname -a > FreeBSD staging.poly.edu 8.1-RELEASE-p1 FreeBSD 8.1-RELEASE-p1 #2: Fri > Oct 8 17:53:40 EDT 2010 > spawk@staging.poly.edu:/usr/obj/usr/src/sys/STAGING amd64 > > -Boris Would you kindly post your file details ? Here are mine: DISTINFO: SHA256 (jpeg8b/jpegexiforient.c) = 2e81f7309d3bb78e3f0c64b1557b7e2d49097e769df859aaa916c00290a8ff56 SIZE (jpeg8b/jpegexiforient.c) = 8192 FILE SIZE: 8192 Feb 17 2002 jpegexiforient.c FILE MD5: MD5 (jpegexiforient.c) = ff4657764cb885b9aec06449507bf29d FILE SHA256: SHA256 (jpegexiforient.c) = bca1bc35bb53d3c189775e0ef4ecbd9be7660d636c7e044f964bde8697273b83 From owner-freebsd-stable@FreeBSD.ORG Tue Jan 25 16:35:14 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 06FF5106566C for ; Tue, 25 Jan 2011 16:35:14 +0000 (UTC) (envelope-from spawk@acm.poly.edu) Received: from acm.poly.edu (acm.poly.edu [128.238.9.200]) by mx1.freebsd.org (Postfix) with ESMTP id B329D8FC14 for ; Tue, 25 Jan 2011 16:35:13 +0000 (UTC) Received: (qmail 3034 invoked from network); 25 Jan 2011 16:35:12 -0000 Received: from unknown (HELO ?10.0.0.179?) (spawk@128.238.64.31) by acm.poly.edu with CAMELLIA256-SHA encrypted SMTP; 25 Jan 2011 16:35:12 -0000 Message-ID: <4D3EFBC9.70106@acm.poly.edu> Date: Tue, 25 Jan 2011 11:35:21 -0500 From: Boris Kochergin User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.12) Gecko/20101106 Thunderbird/3.1.6 MIME-Version: 1.0 To: Damien Fleuriot References: <4D3EF93B.2030606@my.gd> <4D3EFA1E.5020405@acm.poly.edu> <4D3EFAB0.9020307@my.gd> In-Reply-To: <4D3EFAB0.9020307@my.gd> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-stable@freebsd.org" Subject: Re: PORTS : jpeg checksum mismatch X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2011 16:35:14 -0000 On 01/25/11 11:30, Damien Fleuriot wrote: > On 1/25/11 5:28 PM, Boris Kochergin wrote: >> On 01/25/11 11:24, Damien Fleuriot wrote: >>> Hello list, >>> >>> >>> >>> I'm getting nervous here, I seem to get a checksum mismatch for port >>> graphics/jpeg , whether I'm using a mirror or the master sites. >>> >>> See below: >>> >>> # make >>> ===> Vulnerability check disabled, database not found >>> ===> License check disabled, port has not defined LICENSE >>> ===> Extracting for jpeg-8_3 >>> => SHA256 Checksum OK for jpeg8b/jpegsrc.v8b.tar.gz. >>> => SHA256 Checksum mismatch for jpeg8b/jpegexiforient.c. >>> => SHA256 Checksum OK for jpeg8b/exifautotran.txt. >>> ===> Refetch for 1 more times files: jpeg8b/jpegexiforient.c >>> ===> Vulnerability check disabled, database not found >>> ===> License check disabled, port has not defined LICENSE >>> => jpegexiforient.c doesn't seem to exist in >>> /usr/ports/distfiles/jpeg8b. >>> => Attempting to fetch from http://sylvana.net/jpegcrop/. >>> ===> Vulnerability check disabled, database not found >>> ===> License check disabled, port has not defined LICENSE >>> => SHA256 Checksum OK for jpeg8b/jpegsrc.v8b.tar.gz. >>> => SHA256 Checksum mismatch for jpeg8b/jpegexiforient.c. >>> => SHA256 Checksum OK for jpeg8b/exifautotran.txt. >>> ===> Giving up on fetching files: jpeg8b/jpegexiforient.c >>> Make sure the Makefile and distinfo file >>> (/usr/ports/graphics/jpeg/distinfo) >>> are up to date. If you are absolutely sure you want to override this >>> check, type "make NO_CHECKSUM=yes [other args]". >>> *** Error code 1 >>> >>> Stop in /usr/ports/graphics/jpeg. >>> *** Error code 1 >>> >>> Stop in /usr/ports/graphics/jpeg. >>> >>> >>> >>> >>> Apparently the port hasn't been updated since 06/01/11. >>> http://www.freshports.org/graphics/jpeg/ >>> >>> >>> Anyone else encountering the same problem on 8.1-RELEASE ? >>> I sync'ed the ports tree just today. >>> >>> >>> Regards, >>> >>> dfl >>> _______________________________________________ >>> freebsd-stable@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >>> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" >> Works here, but with a ports tree from about six hours ago: >> >> root@staging /usr/ports/graphics/jpeg # make >> ===> Vulnerability check disabled, database not found >> ===> License check disabled, port has not defined LICENSE >> => jpegsrc.v8b.tar.gz doesn't seem to exist in /tmp/ports/distfiles/jpeg8b. >> => Attempting to fetch from http://www.ijg.org/files/. >> jpegsrc.v8b.tar.gz 100% of 942 kB 1368 kBps >> => jpegexiforient.c doesn't seem to exist in /tmp/ports/distfiles/jpeg8b. >> => Attempting to fetch from http://sylvana.net/jpegcrop/. >> jpegexiforient.c 100% of 8192 B 45 kBps >> => exifautotran.txt doesn't seem to exist in /tmp/ports/distfiles/jpeg8b. >> => Attempting to fetch from http://sylvana.net/jpegcrop/. >> exifautotran.txt 100% of 684 B 2807 kBps >> ===> Extracting for jpeg-8_3 >> => SHA256 Checksum OK for jpeg8b/jpegsrc.v8b.tar.gz. >> => SHA256 Checksum OK for jpeg8b/jpegexiforient.c. >> => SHA256 Checksum OK for jpeg8b/exifautotran.txt. >> ... >> >> # uname -a >> FreeBSD staging.poly.edu 8.1-RELEASE-p1 FreeBSD 8.1-RELEASE-p1 #2: Fri >> Oct 8 17:53:40 EDT 2010 >> spawk@staging.poly.edu:/usr/obj/usr/src/sys/STAGING amd64 >> >> -Boris > > > Would you kindly post your file details ? > > Here are mine: > > DISTINFO: > SHA256 (jpeg8b/jpegexiforient.c) = > 2e81f7309d3bb78e3f0c64b1557b7e2d49097e769df859aaa916c00290a8ff56 > SIZE (jpeg8b/jpegexiforient.c) = 8192 > > FILE SIZE: > 8192 Feb 17 2002 jpegexiforient.c > > FILE MD5: > MD5 (jpegexiforient.c) = ff4657764cb885b9aec06449507bf29d > > FILE SHA256: > SHA256 (jpegexiforient.c) = > bca1bc35bb53d3c189775e0ef4ecbd9be7660d636c7e044f964bde8697273b83 > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" # cat /usr/ports/graphics/jpeg/distinfo SHA256 (jpeg8b/jpegsrc.v8b.tar.gz) = 36e6208edec591bae8f2fc370ea4f991447badb6377a125c211ffa7b503174a7 SIZE (jpeg8b/jpegsrc.v8b.tar.gz) = 965125 SHA256 (jpeg8b/jpegexiforient.c) = 2e81f7309d3bb78e3f0c64b1557b7e2d49097e769df859aaa916c00290a8ff56 SIZE (jpeg8b/jpegexiforient.c) = 8192 SHA256 (jpeg8b/exifautotran.txt) = d1d8302e4a76f83c725d65027ff5dfd788447cc245d387a91f01737e9f245c4c SIZE (jpeg8b/exifautotran.txt) = 684 All are consistent with the files fetched to the filesystem. -Boris From owner-freebsd-stable@FreeBSD.ORG Tue Jan 25 16:37:03 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3059A106566B for ; Tue, 25 Jan 2011 16:37:03 +0000 (UTC) (envelope-from ml@my.gd) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id C11FB8FC21 for ; Tue, 25 Jan 2011 16:37:02 +0000 (UTC) Received: by fxm16 with SMTP id 16so5835043fxm.13 for ; Tue, 25 Jan 2011 08:37:01 -0800 (PST) Received: by 10.223.89.143 with SMTP id e15mr5959012fam.100.1295973421543; Tue, 25 Jan 2011 08:37:01 -0800 (PST) Received: from dfleuriot.local ([83.167.62.196]) by mx.google.com with ESMTPS id n1sm5125306fam.40.2011.01.25.08.37.00 (version=SSLv3 cipher=RC4-MD5); Tue, 25 Jan 2011 08:37:00 -0800 (PST) Message-ID: <4D3EFC2A.7090205@my.gd> Date: Tue, 25 Jan 2011 17:36:58 +0100 From: Damien Fleuriot User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Boris Kochergin References: <4D3EF93B.2030606@my.gd> <4D3EFA1E.5020405@acm.poly.edu> <4D3EFAB0.9020307@my.gd> <4D3EFBC9.70106@acm.poly.edu> In-Reply-To: <4D3EFBC9.70106@acm.poly.edu> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "freebsd-stable@freebsd.org" Subject: Re: PORTS : jpeg checksum mismatch X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2011 16:37:03 -0000 On 1/25/11 5:35 PM, Boris Kochergin wrote: > On 01/25/11 11:30, Damien Fleuriot wrote: >> On 1/25/11 5:28 PM, Boris Kochergin wrote: >>> On 01/25/11 11:24, Damien Fleuriot wrote: >>>> Hello list, >>>> >>>> >>>> >>>> I'm getting nervous here, I seem to get a checksum mismatch for port >>>> graphics/jpeg , whether I'm using a mirror or the master sites. >>>> >>>> See below: >>>> >>>> # make >>>> ===> Vulnerability check disabled, database not found >>>> ===> License check disabled, port has not defined LICENSE >>>> ===> Extracting for jpeg-8_3 >>>> => SHA256 Checksum OK for jpeg8b/jpegsrc.v8b.tar.gz. >>>> => SHA256 Checksum mismatch for jpeg8b/jpegexiforient.c. >>>> => SHA256 Checksum OK for jpeg8b/exifautotran.txt. >>>> ===> Refetch for 1 more times files: jpeg8b/jpegexiforient.c >>>> ===> Vulnerability check disabled, database not found >>>> ===> License check disabled, port has not defined LICENSE >>>> => jpegexiforient.c doesn't seem to exist in >>>> /usr/ports/distfiles/jpeg8b. >>>> => Attempting to fetch from http://sylvana.net/jpegcrop/. >>>> ===> Vulnerability check disabled, database not found >>>> ===> License check disabled, port has not defined LICENSE >>>> => SHA256 Checksum OK for jpeg8b/jpegsrc.v8b.tar.gz. >>>> => SHA256 Checksum mismatch for jpeg8b/jpegexiforient.c. >>>> => SHA256 Checksum OK for jpeg8b/exifautotran.txt. >>>> ===> Giving up on fetching files: jpeg8b/jpegexiforient.c >>>> Make sure the Makefile and distinfo file >>>> (/usr/ports/graphics/jpeg/distinfo) >>>> are up to date. If you are absolutely sure you want to override this >>>> check, type "make NO_CHECKSUM=yes [other args]". >>>> *** Error code 1 >>>> >>>> Stop in /usr/ports/graphics/jpeg. >>>> *** Error code 1 >>>> >>>> Stop in /usr/ports/graphics/jpeg. >>>> >>>> >>>> >>>> >>>> Apparently the port hasn't been updated since 06/01/11. >>>> http://www.freshports.org/graphics/jpeg/ >>>> >>>> >>>> Anyone else encountering the same problem on 8.1-RELEASE ? >>>> I sync'ed the ports tree just today. >>>> >>>> >>>> Regards, >>>> >>>> dfl >>>> _______________________________________________ >>>> freebsd-stable@freebsd.org mailing list >>>> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >>>> To unsubscribe, send any mail to >>>> "freebsd-stable-unsubscribe@freebsd.org" >>> Works here, but with a ports tree from about six hours ago: >>> >>> root@staging /usr/ports/graphics/jpeg # make >>> ===> Vulnerability check disabled, database not found >>> ===> License check disabled, port has not defined LICENSE >>> => jpegsrc.v8b.tar.gz doesn't seem to exist in >>> /tmp/ports/distfiles/jpeg8b. >>> => Attempting to fetch from http://www.ijg.org/files/. >>> jpegsrc.v8b.tar.gz 100% of 942 kB 1368 kBps >>> => jpegexiforient.c doesn't seem to exist in >>> /tmp/ports/distfiles/jpeg8b. >>> => Attempting to fetch from http://sylvana.net/jpegcrop/. >>> jpegexiforient.c 100% of 8192 B 45 kBps >>> => exifautotran.txt doesn't seem to exist in >>> /tmp/ports/distfiles/jpeg8b. >>> => Attempting to fetch from http://sylvana.net/jpegcrop/. >>> exifautotran.txt 100% of 684 B 2807 kBps >>> ===> Extracting for jpeg-8_3 >>> => SHA256 Checksum OK for jpeg8b/jpegsrc.v8b.tar.gz. >>> => SHA256 Checksum OK for jpeg8b/jpegexiforient.c. >>> => SHA256 Checksum OK for jpeg8b/exifautotran.txt. >>> ... >>> >>> # uname -a >>> FreeBSD staging.poly.edu 8.1-RELEASE-p1 FreeBSD 8.1-RELEASE-p1 #2: Fri >>> Oct 8 17:53:40 EDT 2010 >>> spawk@staging.poly.edu:/usr/obj/usr/src/sys/STAGING amd64 >>> >>> -Boris >> >> >> Would you kindly post your file details ? >> >> Here are mine: >> >> DISTINFO: >> SHA256 (jpeg8b/jpegexiforient.c) = >> 2e81f7309d3bb78e3f0c64b1557b7e2d49097e769df859aaa916c00290a8ff56 >> SIZE (jpeg8b/jpegexiforient.c) = 8192 >> >> FILE SIZE: >> 8192 Feb 17 2002 jpegexiforient.c >> >> FILE MD5: >> MD5 (jpegexiforient.c) = ff4657764cb885b9aec06449507bf29d >> >> FILE SHA256: >> SHA256 (jpegexiforient.c) = >> bca1bc35bb53d3c189775e0ef4ecbd9be7660d636c7e044f964bde8697273b83 >> >> _______________________________________________ >> freebsd-stable@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > > # cat /usr/ports/graphics/jpeg/distinfo > SHA256 (jpeg8b/jpegsrc.v8b.tar.gz) = > 36e6208edec591bae8f2fc370ea4f991447badb6377a125c211ffa7b503174a7 > SIZE (jpeg8b/jpegsrc.v8b.tar.gz) = 965125 > SHA256 (jpeg8b/jpegexiforient.c) = > 2e81f7309d3bb78e3f0c64b1557b7e2d49097e769df859aaa916c00290a8ff56 > SIZE (jpeg8b/jpegexiforient.c) = 8192 > SHA256 (jpeg8b/exifautotran.txt) = > d1d8302e4a76f83c725d65027ff5dfd788447cc245d387a91f01737e9f245c4c > SIZE (jpeg8b/exifautotran.txt) = 684 > > All are consistent with the files fetched to the filesystem. > > -Boris I've removed the existing distfiles for jpeg8b and fetched again from the master site (as opposed to the mirror my hosting provider runs) and it checked just fine. I'll contact them, they might have a problem there... Thanks for your help :) From owner-freebsd-stable@FreeBSD.ORG Tue Jan 25 16:54:16 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3198B1065672 for ; Tue, 25 Jan 2011 16:54:16 +0000 (UTC) (envelope-from telbizov@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id D7A278FC1C for ; Tue, 25 Jan 2011 16:54:15 +0000 (UTC) Received: by qwj9 with SMTP id 9so5311983qwj.13 for ; Tue, 25 Jan 2011 08:54:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=9o+dGzOfaonqd5IwSx5ZcVpTJgaWZuORm/0a/KnwAyg=; b=t/nenTQQHkZ/mH4EKR82Lt7NDBAkCCzlg8U7LVPtHFiW19jfHGb+JbrZ81gCnThP03 qRNL7ZvaJjKJr/9md50n+CCKk0/F7PKPh4pxaRGvSl98WbXhtDBHmPeV3lWBOvhIocM+ X7b8K4Ks/2qPKs0E6Wt5ETRXlbsp1VI0rJY8g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=tqYGQlwIHlMW5xwkdSr07kz7UIw9PZnAsO6jB8PY1MCvi6H93btpBzt+juNEBshAD0 swg0yuG3I/+TlJkFQP5PkE2E8b97Jj1Byx1sKdr3Xy7ljOBZk2zs0DUiguG1Eq6Grlea CtZ8Vb2DZs8AOzV24p73by3R94Oxzvf0aquyI= MIME-Version: 1.0 Received: by 10.229.248.6 with SMTP id me6mr5025018qcb.54.1295972772850; Tue, 25 Jan 2011 08:26:12 -0800 (PST) Received: by 10.229.0.207 with HTTP; Tue, 25 Jan 2011 08:26:12 -0800 (PST) Date: Tue, 25 Jan 2011 08:26:12 -0800 Message-ID: From: Rumen Telbizov To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: LSI 9211-8i driver support for 8.2 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2011 16:54:16 -0000 Hello everyone, I saw a discussion not far back ago ( http://old.nabble.com/LSI-9211-driver-td30221120.html) regarding a driver for LSI 9211-8i HBA and it seems like there is a driver coming soon (mps). I also see that Scott Long suggested that it might make it for the release of 8.2. Is this still the case? Do you think we'll have this driver in 8.2? Thank you, -- Rumen Telbizov http://telbizov.com From owner-freebsd-stable@FreeBSD.ORG Tue Jan 25 18:21:06 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0595D106566C for ; Tue, 25 Jan 2011 18:21:06 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id C9BCC8FC1E for ; Tue, 25 Jan 2011 18:21:05 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 612B846B85; Tue, 25 Jan 2011 13:21:05 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 68DA18A027; Tue, 25 Jan 2011 13:21:04 -0500 (EST) From: John Baldwin To: freebsd-stable@freebsd.org Date: Tue, 25 Jan 2011 13:17:33 -0500 User-Agent: KMail/1.13.5 (FreeBSD/7.4-CBSD-20110107; KDE/4.4.5; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201101251317.33773.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Tue, 25 Jan 2011 13:21:04 -0500 (EST) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.9 required=4.2 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: Rumen Telbizov Subject: Re: LSI 9211-8i driver support for 8.2 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2011 18:21:06 -0000 On Tuesday, January 25, 2011 11:26:12 am Rumen Telbizov wrote: > Hello everyone, > > I saw a discussion not far back ago ( > http://old.nabble.com/LSI-9211-driver-td30221120.html) regarding a driver > for LSI 9211-8i HBA > and it seems like there is a driver coming soon (mps). I also see that Scott > Long suggested that it might make it for the release of 8.2. > Is this still the case? Do you think we'll have this driver in 8.2? It was not merged to 8 in time for 8.2. It will hopefully be present in 8.3. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Tue Jan 25 18:24:28 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EE599106564A for ; Tue, 25 Jan 2011 18:24:27 +0000 (UTC) (envelope-from telbizov@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 8BB9D8FC16 for ; Tue, 25 Jan 2011 18:24:27 +0000 (UTC) Received: by vws9 with SMTP id 9so59460vws.13 for ; Tue, 25 Jan 2011 10:24:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=RA6Mj4gPcrWnCEcsX1O9/AHhnEKBWJZch14F48CbWUw=; b=OzSdKvj0WjjtDyiN00HdFjEeZAoMsiFUZu2wbxuV3+QMmtshUVWEA3f3yIH8TP60tO jUfndIVFQdsScwVZdm0797t0GxNPupx7EohA8LfjPIArnfESzn6hDoTOKXBvhooFIkOr iQIjBQVtt3pn744jXbJIw91rmfZjoH9WbEK+g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=FPwaPO0PRUy9bYeeWFvnWgRQ0whFjj8MCKOoQ4aaXX+pQ82JhIa6loX8irMUQCuJB3 xQwUNV4UtLDkBDpaNGJwd9vAj7VT3KGa0P2bfAks3hxjq6PbCzzZ8jPavoF6/LTGMDX/ IiXqseywff1RbmWBQeMbBBzUA9uIc6OeV3GZ8= MIME-Version: 1.0 Received: by 10.229.186.212 with SMTP id ct20mr5071145qcb.92.1295979866198; Tue, 25 Jan 2011 10:24:26 -0800 (PST) Received: by 10.229.0.207 with HTTP; Tue, 25 Jan 2011 10:24:26 -0800 (PST) In-Reply-To: <201101251317.33773.jhb@freebsd.org> References: <201101251317.33773.jhb@freebsd.org> Date: Tue, 25 Jan 2011 10:24:26 -0800 Message-ID: From: Rumen Telbizov To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org Subject: Re: LSI 9211-8i driver support for 8.2 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2011 18:24:28 -0000 John: Thanks for the information. Do you think there's any chance for this to happen sonner than 8.3 release? Sometime during 8.2-STABLE lifespan? Cheers, Rumen Telbizov On Tue, Jan 25, 2011 at 10:17 AM, John Baldwin wrote: > On Tuesday, January 25, 2011 11:26:12 am Rumen Telbizov wrote: > > Hello everyone, > > > > I saw a discussion not far back ago ( > > http://old.nabble.com/LSI-9211-driver-td30221120.html) regarding a > driver > > for LSI 9211-8i HBA > > and it seems like there is a driver coming soon (mps). I also see that > Scott > > Long suggested that it might make it for the release of 8.2. > > Is this still the case? Do you think we'll have this driver in 8.2? > > It was not merged to 8 in time for 8.2. It will hopefully be present in > 8.3. > > -- > John Baldwin > -- Rumen Telbizov http://telbizov.com From owner-freebsd-stable@FreeBSD.ORG Tue Jan 25 18:57:23 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4CD26106566B for ; Tue, 25 Jan 2011 18:57:23 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 1B7E38FC0C for ; Tue, 25 Jan 2011 18:57:23 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id BF5CE46B17; Tue, 25 Jan 2011 13:57:22 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 914998A009; Tue, 25 Jan 2011 13:57:21 -0500 (EST) From: John Baldwin To: freebsd-stable@freebsd.org Date: Tue, 25 Jan 2011 13:57:11 -0500 User-Agent: KMail/1.13.5 (FreeBSD/7.4-CBSD-20110107; KDE/4.4.5; amd64; ; ) References: <201101251317.33773.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201101251357.11906.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Tue, 25 Jan 2011 13:57:21 -0500 (EST) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.9 required=4.2 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: Rumen Telbizov Subject: Re: LSI 9211-8i driver support for 8.2 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2011 18:57:23 -0000 On Tuesday, January 25, 2011 1:24:26 pm Rumen Telbizov wrote: > John: > > Thanks for the information. > Do you think there's any chance for this to happen sonner than 8.3 release? > Sometime during 8.2-STABLE lifespan? I certainly hope it is merged soon so that it can be tested before 8.3 is released. > Cheers, > Rumen Telbizov > > On Tue, Jan 25, 2011 at 10:17 AM, John Baldwin wrote: > > > On Tuesday, January 25, 2011 11:26:12 am Rumen Telbizov wrote: > > > Hello everyone, > > > > > > I saw a discussion not far back ago ( > > > http://old.nabble.com/LSI-9211-driver-td30221120.html) regarding a > > driver > > > for LSI 9211-8i HBA > > > and it seems like there is a driver coming soon (mps). I also see that > > Scott > > > Long suggested that it might make it for the release of 8.2. > > > Is this still the case? Do you think we'll have this driver in 8.2? > > > > It was not merged to 8 in time for 8.2. It will hopefully be present in > > 8.3. > > > > -- > > John Baldwin > > > > > > -- > Rumen Telbizov > http://telbizov.com > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Tue Jan 25 19:56:49 2011 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4DF5F1065670 for ; Tue, 25 Jan 2011 19:56:49 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by mx1.freebsd.org (Postfix) with ESMTP id D5A998FC0A for ; Tue, 25 Jan 2011 19:56:48 +0000 (UTC) Received: (qmail 18958 invoked by uid 399); 25 Jan 2011 19:30:08 -0000 Received: from localhost (HELO doug-optiplex.ka9q.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 25 Jan 2011 19:30:08 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4D3F24BE.1070206@FreeBSD.org> Date: Tue, 25 Jan 2011 11:30:06 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.13) Gecko/20101210 Thunderbird/3.1.7 MIME-Version: 1.0 To: Eugene Grosbein References: <4D3E79D5.7050800@rdtc.ru> In-Reply-To: <4D3E79D5.7050800@rdtc.ru> X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: stable@freebsd.org Subject: Re: Living on gmirror: need to reincarnate /etc/rc.early X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2011 19:56:49 -0000 On 01/24/2011 23:20, Eugene Grosbein wrote: > Hi! > > In RELENG_8, gmirror is good enough to keep whole HDD pair withing the mirror. > Its performance, stability any pretty ease of maintainance allows > to use it widely. > > With wide deployment of gmirror in production I've faced inability > of RELENG_8 to store kernel crashdumps out-of-the-box. > gmirror manual page documents a way to setup FreeBSD so that > it would store crashdumps again but that way involves /etc/rc.early > removed from RELENG_8. I've read about intentions - it was unsafe etc. > But we still need working crashdump support. > > Easiest way is to reincarnate /etc/rc.d/early support making it better and safer > and it should support gmirror's mechanics for crashdumps out-of-the-box. I'll tell you the same thing I told Kostik way back when I removed it. This is the only thing that anyone has ever suggested a use for in /etc/rc.early, and the "solution" in the man page is a hack. :) If this is something that is necessary to do then I'd prefer to do it properly and add an /etc/rc.d/gmirror that runs in the proper (early) position, and then figure out the proper location in rc.d to handle the second half of the configuration. I'm happy to review patches. :) Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-stable@FreeBSD.ORG Tue Jan 25 20:28:08 2011 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4EEF9106564A for ; Tue, 25 Jan 2011 20:28:08 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 4A2448FC08 for ; Tue, 25 Jan 2011 20:28:06 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id p0PKS3jW045306 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Jan 2011 22:28:03 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id p0PKS2OU055502; Tue, 25 Jan 2011 22:28:02 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id p0PKS2q2055501; Tue, 25 Jan 2011 22:28:02 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 25 Jan 2011 22:28:02 +0200 From: Kostik Belousov To: Doug Barton Message-ID: <20110125202802.GU2518@deviant.kiev.zoral.com.ua> References: <4D3E79D5.7050800@rdtc.ru> <4D3F24BE.1070206@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="OwXA+KufQS8ol7Xv" Content-Disposition: inline In-Reply-To: <4D3F24BE.1070206@FreeBSD.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_05, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: stable@freebsd.org, Eugene Grosbein Subject: Re: Living on gmirror: need to reincarnate /etc/rc.early X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2011 20:28:08 -0000 --OwXA+KufQS8ol7Xv Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jan 25, 2011 at 11:30:06AM -0800, Doug Barton wrote: > On 01/24/2011 23:20, Eugene Grosbein wrote: > >Hi! > > > >In RELENG_8, gmirror is good enough to keep whole HDD pair withing the= =20 > >mirror. > >Its performance, stability any pretty ease of maintainance allows > >to use it widely. > > > >With wide deployment of gmirror in production I've faced inability > >of RELENG_8 to store kernel crashdumps out-of-the-box. > >gmirror manual page documents a way to setup FreeBSD so that > >it would store crashdumps again but that way involves /etc/rc.early > >removed from RELENG_8. I've read about intentions - it was unsafe etc. > >But we still need working crashdump support. > > > >Easiest way is to reincarnate /etc/rc.d/early support making it better a= nd=20 > >safer > >and it should support gmirror's mechanics for crashdumps out-of-the-box. >=20 > I'll tell you the same thing I told Kostik way back when I removed it.=20 > This is the only thing that anyone has ever suggested a use for in=20 > /etc/rc.early, and the "solution" in the man page is a hack. :) >=20 > If this is something that is necessary to do then I'd prefer to do it=20 > properly and add an /etc/rc.d/gmirror that runs in the proper (early)=20 > position, and then figure out the proper location in rc.d to handle the= =20 > second half of the configuration. >=20 No, my use for rc.early is different. I use it to load modules before filesystems are mounted. > I'm happy to review patches. :) >=20 >=20 > Doug >=20 > --=20 >=20 > Nothin' ever doesn't change, but nothin' changes much. > -- OK Go >=20 > Breadth of IT experience, and depth of knowledge in the DNS. > Yours for the right price. :) http://SupersetSolutions.com/ >=20 > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" --OwXA+KufQS8ol7Xv Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk0/MlIACgkQC3+MBN1Mb4hCIACggXMjAHkVh0oOGLCwGzKHghST XfUAn1XiWnZGPo5EZVZf1NoN9vXzg0Ty =BBTD -----END PGP SIGNATURE----- --OwXA+KufQS8ol7Xv-- From owner-freebsd-stable@FreeBSD.ORG Tue Jan 25 20:30:39 2011 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 95D76106564A for ; Tue, 25 Jan 2011 20:30:39 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by mx1.freebsd.org (Postfix) with ESMTP id 26F098FC0C for ; Tue, 25 Jan 2011 20:30:38 +0000 (UTC) Received: (qmail 8756 invoked by uid 399); 25 Jan 2011 20:30:38 -0000 Received: from localhost (HELO doug-optiplex.ka9q.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 25 Jan 2011 20:30:38 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4D3F32ED.7080509@FreeBSD.org> Date: Tue, 25 Jan 2011 12:30:37 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.13) Gecko/20101210 Thunderbird/3.1.7 MIME-Version: 1.0 To: Kostik Belousov References: <4D3E79D5.7050800@rdtc.ru> <4D3F24BE.1070206@FreeBSD.org> <20110125202802.GU2518@deviant.kiev.zoral.com.ua> In-Reply-To: <20110125202802.GU2518@deviant.kiev.zoral.com.ua> X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: stable@freebsd.org, Eugene Grosbein Subject: Re: Living on gmirror: need to reincarnate /etc/rc.early X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2011 20:30:39 -0000 On 01/25/2011 12:28, Kostik Belousov wrote: > No, my use for rc.early is different. I use it to load modules > before filesystems are mounted. Ok, I'll bite ... what is deficient about doing this in /boot/loader.conf? Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-stable@FreeBSD.ORG Tue Jan 25 20:51:03 2011 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 765361065672; Tue, 25 Jan 2011 20:51:03 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id DDB918FC19; Tue, 25 Jan 2011 20:51:02 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id p0PKouGV046682 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Jan 2011 22:50:56 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id p0PKotOV055617; Tue, 25 Jan 2011 22:50:55 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id p0PKot0C055616; Tue, 25 Jan 2011 22:50:55 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 25 Jan 2011 22:50:55 +0200 From: Kostik Belousov To: Doug Barton Message-ID: <20110125205055.GV2518@deviant.kiev.zoral.com.ua> References: <4D3E79D5.7050800@rdtc.ru> <4D3F24BE.1070206@FreeBSD.org> <20110125202802.GU2518@deviant.kiev.zoral.com.ua> <4D3F32ED.7080509@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="fVqowPMy9d9Ku1/g" Content-Disposition: inline In-Reply-To: <4D3F32ED.7080509@FreeBSD.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: stable@freebsd.org, Eugene Grosbein Subject: Re: Living on gmirror: need to reincarnate /etc/rc.early X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2011 20:51:03 -0000 --fVqowPMy9d9Ku1/g Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jan 25, 2011 at 12:30:37PM -0800, Doug Barton wrote: > On 01/25/2011 12:28, Kostik Belousov wrote: > >No, my use for rc.early is different. I use it to load modules > >before filesystems are mounted. >=20 > Ok, I'll bite ... what is deficient about doing this in /boot/loader.conf? The fact that for failing driver, I can still get to single-user reliably with boot -s without doing loader command line magic under the stress. Or, not having to describe that magic over the phone to somebody who would prefer to play^H^H^H do something else instead. --fVqowPMy9d9Ku1/g Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk0/N68ACgkQC3+MBN1Mb4hNHACgvV/wWW62Ox/1pz1Rr3bJrCPE A5YAoNNq62li/s/SgcShOOEvtl5l7GVu =ualM -----END PGP SIGNATURE----- --fVqowPMy9d9Ku1/g-- From owner-freebsd-stable@FreeBSD.ORG Tue Jan 25 21:00:30 2011 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D722D106566B for ; Tue, 25 Jan 2011 21:00:30 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-gw0-f54.google.com (mail-gw0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id 93B388FC0A for ; Tue, 25 Jan 2011 21:00:30 +0000 (UTC) Received: by gwj21 with SMTP id 21so1979822gwj.13 for ; Tue, 25 Jan 2011 13:00:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=QiCwtwk2Be4sil7+D7MBtgRiu61Mg9pQkmS6Ocxmkh0=; b=qNx6KUJKB7D4m4A3w2/fmrBLyfgAbI6/VS9DUA2K/IZunAaXBFoQghHbiEjrGWvJWD IsgxW6EbrcA18AsUyLgTNq7+SD6ZdiAWcbBdU/0rZbic4yn8rnze04qI/sCdUbqLuf+w esVcocI+36V7vZSwGL77jz1fb6sMSZ4W5N7gc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=uSS9XqLNnkndqlk2gvFj5W0mpyG7d8f6jP3586QZg0n3et+kqc8/PSB2ow9Vwf3Wlx S9HAVZyytZDo5yvRDEqBl3sg3neR3EH6qFaNzOfqyFpMXH42IGEb4geqo413W92Aufo3 V0MorUzGP820CYYbbV7xluqfng7ATZ9iZQyZY= MIME-Version: 1.0 Received: by 10.91.153.10 with SMTP id f10mr93608ago.172.1295989229689; Tue, 25 Jan 2011 13:00:29 -0800 (PST) Received: by 10.91.111.10 with HTTP; Tue, 25 Jan 2011 13:00:29 -0800 (PST) In-Reply-To: <20110125205055.GV2518@deviant.kiev.zoral.com.ua> References: <4D3E79D5.7050800@rdtc.ru> <4D3F24BE.1070206@FreeBSD.org> <20110125202802.GU2518@deviant.kiev.zoral.com.ua> <4D3F32ED.7080509@FreeBSD.org> <20110125205055.GV2518@deviant.kiev.zoral.com.ua> Date: Tue, 25 Jan 2011 13:00:29 -0800 Message-ID: From: Freddie Cash To: stable@freebsd.org Content-Type: text/plain; charset=UTF-8 Cc: Subject: Re: Living on gmirror: need to reincarnate /etc/rc.early X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2011 21:00:30 -0000 On Tue, Jan 25, 2011 at 12:50 PM, Kostik Belousov wrote: > On Tue, Jan 25, 2011 at 12:30:37PM -0800, Doug Barton wrote: >> On 01/25/2011 12:28, Kostik Belousov wrote: >> >No, my use for rc.early is different. I use it to load modules >> >before filesystems are mounted. >> >> Ok, I'll bite ... what is deficient about doing this in /boot/loader.conf? > The fact that for failing driver, I can still get to single-user reliably > with boot -s without doing loader command line magic under the stress. > Or, not having to describe that magic over the phone to somebody who > would prefer to play^H^H^H do something else instead. Hrm, sounds like a need for an /etc/rc.d/modules, configured to run at a suitably early time in the rcorder. :) -- Freddie Cash fjwcash@gmail.com From owner-freebsd-stable@FreeBSD.ORG Wed Jan 26 07:31:20 2011 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AF91D106566C; Wed, 26 Jan 2011 07:31:20 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.16.84]) by mx1.freebsd.org (Postfix) with ESMTP id 636058FC1C; Wed, 26 Jan 2011 07:31:20 +0000 (UTC) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1PhzFg-000J0p-4G; Wed, 26 Jan 2011 08:53:12 +0200 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: Doug Barton In-reply-to: <4D3F32ED.7080509@FreeBSD.org> References: <4D3E79D5.7050800@rdtc.ru> <4D3F24BE.1070206@FreeBSD.org> <20110125202802.GU2518@deviant.kiev.zoral.com.ua> <4D3F32ED.7080509@FreeBSD.org> Comments: In-reply-to Doug Barton message dated "Tue, 25 Jan 2011 12:30:37 -0800." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 26 Jan 2011 08:53:12 +0200 From: Daniel Braniss Message-ID: Cc: Kostik Belousov , stable@freebsd.org, Eugene Grosbein Subject: Re: Living on gmirror: need to reincarnate /etc/rc.early X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jan 2011 07:31:20 -0000 > On 01/25/2011 12:28, Kostik Belousov wrote: > > No, my use for rc.early is different. I use it to load modules > > before filesystems are mounted. > > Ok, I'll bite ... what is deficient about doing this in /boot/loader.conf? > in case if diskless, where the root (/boot/loader.conf) is shared, it's nice to be able to configure clients via rc.conf. danny From owner-freebsd-stable@FreeBSD.ORG Wed Jan 26 12:58:33 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 22DCF106566C for ; Wed, 26 Jan 2011 12:58:33 +0000 (UTC) (envelope-from bartosz.stec@it4pro.pl) Received: from mainframe.kkip.pl (kkip.pl [87.105.164.78]) by mx1.freebsd.org (Postfix) with ESMTP id C7A848FC14 for ; Wed, 26 Jan 2011 12:58:32 +0000 (UTC) Received: from static-78-8-144-74.ssp.dialog.net.pl ([78.8.144.74] helo=[192.168.0.2]) by mainframe.kkip.pl with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.73 (FreeBSD)) (envelope-from ) id 1Pi4Mj-0006pK-3y for freebsd-stable@freebsd.org; Wed, 26 Jan 2011 13:20:56 +0100 Message-ID: <4D401192.3030400@it4pro.pl> Date: Wed, 26 Jan 2011 13:20:34 +0100 From: Bartosz Stec Organization: IT4Pro User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; pl; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: FreeBSD Stable X-Authenticated-User: bartosz.stec@it4pro.pl X-Authenticator: plain X-Sender-Verify: SUCCEEDED (sender exists & accepts mail) X-Spam-Score: -8.0 X-Spam-Score-Int: -79 X-Exim-Version: 4.73 (build at 10-Jan-2011 16:29:01) X-Date: 2011-01-26 13:20:56 X-Connected-IP: 78.8.144.74:57623 X-Message-Linecount: 75 X-Body-Linecount: 64 X-Message-Size: 2093 X-Body-Size: 1636 X-Received-Count: 1 X-Recipient-Count: 1 X-Local-Recipient-Count: 1 X-Local-Recipient-Defer-Count: 0 X-Local-Recipient-Fail-Count: 0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: top shows only half of realmem? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jan 2011 12:58:33 -0000 Guys, could someone explain me this? # sysctl hw.realmem hw.realmem: 2139029504 top line shows: Mem: 32M Active, 35M Inact, 899M Wired, 8392K Cache, 199M Buf, 58M Free 32+35+899+8+199+58 = 1231MB Shouldn't that sum to all available ram? Or maybe I'm reading it wrong? This machine has indeed 2GB of ram on board and showed in BIOS. i386 FreeBSD 8.2-PRERELEASE #16: Mon Jan 17 22:28:53 CET 2011 Cheers. -- Bartosz Stec From owner-freebsd-stable@FreeBSD.ORG Wed Jan 26 13:07:45 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2D224106566B for ; Wed, 26 Jan 2011 13:07:45 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 012F18FC19 for ; Wed, 26 Jan 2011 13:07:45 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id AD15F46B0D; Wed, 26 Jan 2011 08:07:44 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id D0C4B8A01D; Wed, 26 Jan 2011 08:07:43 -0500 (EST) From: John Baldwin To: freebsd-stable@freebsd.org Date: Wed, 26 Jan 2011 08:06:09 -0500 User-Agent: KMail/1.13.5 (FreeBSD/7.4-CBSD-20110107; KDE/4.4.5; amd64; ; ) References: <4D401192.3030400@it4pro.pl> In-Reply-To: <4D401192.3030400@it4pro.pl> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201101260806.10084.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Wed, 26 Jan 2011 08:07:43 -0500 (EST) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.9 required=4.2 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: Bartosz Stec Subject: Re: top shows only half of realmem? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jan 2011 13:07:45 -0000 On Wednesday, January 26, 2011 7:20:34 am Bartosz Stec wrote: > Guys, > > could someone explain me this? > > # sysctl hw.realmem > hw.realmem: 2139029504 > > top line shows: > > Mem: 32M Active, 35M Inact, 899M Wired, 8392K Cache, 199M Buf, 58M Free > > 32+35+899+8+199+58 = 1231MB > > Shouldn't that sum to all available ram? Or maybe I'm reading it wrong? > This machine has indeed 2GB of ram on board and showed in BIOS. > i386 FreeBSD 8.2-PRERELEASE #16: Mon Jan 17 22:28:53 CET 2011 > Cheers. First, don't include 'buf' as isn't a separate set of RAM, it is only a range of the virtual address space in the kernel. It used to be relevant when the buffer cache was separate from the VM page cache, but now it is mostly irrelevant (arguably it should just be dropped from top output). However, look at what hw.physmem says (and the realmem and availmem lines in dmesg). realmem is actually not that useful as it is not a count of the amount of memory, but the address of the highest memory page available. There can be less memory available than that due to "holes" in the address space for PCI memory BARs, etc. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Wed Jan 26 13:20:52 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0ACD21065672 for ; Wed, 26 Jan 2011 13:20:52 +0000 (UTC) (envelope-from bartosz.stec@it4pro.pl) Received: from mainframe.kkip.pl (kkip.pl [87.105.164.78]) by mx1.freebsd.org (Postfix) with ESMTP id 984F68FC18 for ; Wed, 26 Jan 2011 13:20:51 +0000 (UTC) Received: from static-78-8-144-74.ssp.dialog.net.pl ([78.8.144.74] helo=[192.168.0.2]) by mainframe.kkip.pl with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.73 (FreeBSD)) (envelope-from ) id 1Pi5Ig-00076O-KB; Wed, 26 Jan 2011 14:20:50 +0100 Message-ID: <4D401F9C.6050402@it4pro.pl> Date: Wed, 26 Jan 2011 14:20:28 +0100 From: Bartosz Stec Organization: IT4Pro User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; pl; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: John Baldwin References: <4D401192.3030400@it4pro.pl> <201101260806.10084.jhb@freebsd.org> In-Reply-To: <201101260806.10084.jhb@freebsd.org> X-Authenticated-User: bartosz.stec@it4pro.pl X-Authenticator: plain X-Sender-Verify: SUCCEEDED (sender exists & accepts mail) X-Spam-Score: -8.1 X-Spam-Score-Int: -80 X-Exim-Version: 4.73 (build at 10-Jan-2011 16:29:01) X-Date: 2011-01-26 14:20:50 X-Connected-IP: 78.8.144.74:51423 X-Message-Linecount: 153 X-Body-Linecount: 139 X-Message-Size: 5080 X-Body-Size: 4456 X-Received-Count: 1 X-Recipient-Count: 2 X-Local-Recipient-Count: 2 X-Local-Recipient-Defer-Count: 0 X-Local-Recipient-Fail-Count: 0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: FreeBSD Stable Subject: Re: top shows only half of realmem? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jan 2011 13:20:52 -0000 W dniu 2011-01-26 14:06, John Baldwin pisze: > On Wednesday, January 26, 2011 7:20:34 am Bartosz Stec wrote: >> Guys, >> >> could someone explain me this? >> >> # sysctl hw.realmem >> hw.realmem: 2139029504 >> >> top line shows: >> >> Mem: 32M Active, 35M Inact, 899M Wired, 8392K Cache, 199M Buf, 58M Free >> >> 32+35+899+8+199+58 = 1231MB >> >> Shouldn't that sum to all available ram? Or maybe I'm reading it wrong? >> This machine has indeed 2GB of ram on board and showed in BIOS. >> i386 FreeBSD 8.2-PRERELEASE #16: Mon Jan 17 22:28:53 CET 2011 >> Cheers. > First, don't include 'buf' as isn't a separate set of RAM, it is only a range > of the virtual address space in the kernel. It used to be relevant when the > buffer cache was separate from the VM page cache, but now it is mostly > irrelevant (arguably it should just be dropped from top output). Thanks for the explanation. So 1231MB - 199MB Buf and we got about 1GB of memory instead of 2B. > However, look at what hw.physmem says (and the realmem and availmem lines in > dmesg). realmem is actually not that useful as it is not a count of the > amount of memory, but the address of the highest memory page available. There > can be less memory available than that due to "holes" in the address space for > PCI memory BARs, etc. > OK, here you go: # sysctl hw | grep mem hw.physmem: 2125893632 hw.usermem: 1212100608 hw.realmem: 2139029504 hw.pci.host_mem_start: 2147483648 And here's the part of /boot/loader.conf for ZFS tuning which may (or probably may not) connected to this issue: vm.kmem_size="1536M" vm.kmem_size_max="1536M" vfs.zfs.arc_max="1280M" -- Bartosz Stec From owner-freebsd-stable@FreeBSD.ORG Wed Jan 26 14:35:03 2011 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DF7291065674; Wed, 26 Jan 2011 14:35:02 +0000 (UTC) (envelope-from bartsch@dssgmbh.de) Received: from mail.incore.de (dss.incore.de [195.145.1.138]) by mx1.freebsd.org (Postfix) with ESMTP id 999588FC12; Wed, 26 Jan 2011 14:35:02 +0000 (UTC) Received: from inetmail.dmz (inetmail.dmz [10.3.0.3]) by mail.incore.de (Postfix) with ESMTP id 71BD65C864; Wed, 26 Jan 2011 15:17:32 +0100 (CET) X-Virus-Scanned: amavisd-new at incore.de Received: from mail.incore.de ([10.3.0.3]) by inetmail.dmz (inetmail.dmz [10.3.0.3]) (amavisd-new, port 10024) with LMTP id vkqRua2iGD+4; Wed, 26 Jan 2011 15:17:30 +0100 (CET) Received: from mail.incore (fwintern.dmz [10.0.0.253]) by mail.incore.de (Postfix) with ESMTP id C38875C866; Wed, 26 Jan 2011 15:17:30 +0100 (CET) Received: from pcbart.incore (pcbart.incore [192.168.0.57]) by mail.incore (Postfix) with ESMTPSA id B5BFA4509C; Wed, 26 Jan 2011 15:17:30 +0100 (CET) Message-ID: <4D402CFA.40501@dssgmbh.de> Date: Wed, 26 Jan 2011 15:17:30 +0100 From: Alfred Bartsch User-Agent: Thunderbird 2.0.0.19 (X11/20090113) MIME-Version: 1.0 To: Doug Barton References: <4D3E79D5.7050800@rdtc.ru> <4D3F24BE.1070206@FreeBSD.org> In-Reply-To: <4D3F24BE.1070206@FreeBSD.org> X-Enigmail-Version: 0.95.7 OpenPGP: id=97557F78 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Cc: stable@freebsd.org, Eugene Grosbein Subject: Re: Living on gmirror: need to reincarnate /etc/rc.early X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jan 2011 14:35:03 -0000 Doug Barton schrieb: > On 01/24/2011 23:20, Eugene Grosbein wrote: >> Hi! >> >> In RELENG_8, gmirror is good enough to keep whole HDD pair withing the >> mirror. >> Its performance, stability any pretty ease of maintainance allows >> to use it widely. >> >> With wide deployment of gmirror in production I've faced inability >> of RELENG_8 to store kernel crashdumps out-of-the-box. >> gmirror manual page documents a way to setup FreeBSD so that >> it would store crashdumps again but that way involves /etc/rc.early >> removed from RELENG_8. I've read about intentions - it was unsafe etc. >> But we still need working crashdump support. >> >> Easiest way is to reincarnate /etc/rc.d/early support making it better >> and safer >> and it should support gmirror's mechanics for crashdumps out-of-the-box. > > I'll tell you the same thing I told Kostik way back when I removed it. > This is the only thing that anyone has ever suggested a use for in > /etc/rc.early, and the "solution" in the man page is a hack. :) > > If this is something that is necessary to do then I'd prefer to do it > properly and add an /etc/rc.d/gmirror that runs in the proper (early) > position, and then figure out the proper location in rc.d to handle the > second half of the configuration. > > I'm happy to review patches. :) > > > Doug > Hi Doug, at our site we are using the following scripts in /etc/rc.d to deal with gmirror "specials": First part (/etc/rc.d/gmirror1): ================================ #!/bin/sh # PROVIDE: gmirror1 # BEFORE: fsck # KEYWORD: nojail . /etc/rc.subr name="gmirror1" start_cmd="gmirror1_start" stop_cmd=":" gmirror1_start() { echo "gmirror configure -b prefer gm0" gmirror configure -b prefer gm0 } load_rc_config $name run_rc_command "$1" # run only if provider /dev/mirror/gm0 exists test -r /dev/mirror/gm0 || exit 0 --------------------------------- Second part (/etc/rc.d/gmirror2): ================================ #!/bin/sh # PROVIDE: gmirror2 # REQUIRE: DAEMON # BEFORE: LOGIN # KEYWORD: nojail . /etc/rc.subr name="gmirror2" start_cmd="gmirror2_start" stop_cmd=":" gmirror2_start() { echo "gmirror configure -b round-robin gm0" gmirror configure -b round-robin gm0 } load_rc_config $name run_rc_command "$1" # run only if provider /dev/mirror/gm0 exists test -r /dev/mirror/gm0 || exit 0 --------------------------------- In our environment, the name of the gmirror provider is always "mirror/gm0". Variable naming of the provider should be added, eventually extracted from "gmirror list" command. -- Alfred Bartsch From owner-freebsd-stable@FreeBSD.ORG Wed Jan 26 17:37:38 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6DD1D106564A for ; Wed, 26 Jan 2011 17:37:38 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 3E1998FC1B for ; Wed, 26 Jan 2011 17:37:38 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id C5CB446B03; Wed, 26 Jan 2011 12:37:37 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id CA94C8A009; Wed, 26 Jan 2011 12:37:36 -0500 (EST) From: John Baldwin To: freebsd-stable@freebsd.org Date: Wed, 26 Jan 2011 12:35:56 -0500 User-Agent: KMail/1.13.5 (FreeBSD/7.4-CBSD-20110107; KDE/4.4.5; amd64; ; ) References: <4D401192.3030400@it4pro.pl> <201101260806.10084.jhb@freebsd.org> <4D401F9C.6050402@it4pro.pl> In-Reply-To: <4D401F9C.6050402@it4pro.pl> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201101261235.56856.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Wed, 26 Jan 2011 12:37:36 -0500 (EST) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.9 required=4.2 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: Bartosz Stec Subject: Re: top shows only half of realmem? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jan 2011 17:37:38 -0000 On Wednesday, January 26, 2011 8:20:28 am Bartosz Stec wrote: > W dniu 2011-01-26 14:06, John Baldwin pisze: > > On Wednesday, January 26, 2011 7:20:34 am Bartosz Stec wrote: > >> Guys, > >> > >> could someone explain me this? > >> > >> # sysctl hw.realmem > >> hw.realmem: 2139029504 > >> > >> top line shows: > >> > >> Mem: 32M Active, 35M Inact, 899M Wired, 8392K Cache, 199M Buf, 58M Free > >> > >> 32+35+899+8+199+58 = 1231MB > >> > >> Shouldn't that sum to all available ram? Or maybe I'm reading it wrong? > >> This machine has indeed 2GB of ram on board and showed in BIOS. > >> i386 FreeBSD 8.2-PRERELEASE #16: Mon Jan 17 22:28:53 CET 2011 > >> Cheers. > > First, don't include 'buf' as isn't a separate set of RAM, it is only a range > > of the virtual address space in the kernel. It used to be relevant when the > > buffer cache was separate from the VM page cache, but now it is mostly > > irrelevant (arguably it should just be dropped from top output). > > Thanks for the explanation. So 1231MB - 199MB Buf and we got about 1GB > of memory instead of 2B. > > > However, look at what hw.physmem says (and the realmem and availmem lines in > > dmesg). realmem is actually not that useful as it is not a count of the > > amount of memory, but the address of the highest memory page available. There > > can be less memory available than that due to "holes" in the address space for > > PCI memory BARs, etc. > > > OK, here you go: > # sysctl hw | grep mem > > hw.physmem: 2125893632 > hw.usermem: 1212100608 > hw.realmem: 2139029504 > hw.pci.host_mem_start: 2147483648 Humm, you should still have 2GB of RAM then. All the memory you set aside for ARC should be counted in the 'wired' count, so I'm not sure why you see 1GB of RAM rather than 2GB. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Wed Jan 26 18:04:06 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C7C11106566C for ; Wed, 26 Jan 2011 18:04:06 +0000 (UTC) (envelope-from marco@tolstoy.tols.org) Received: from tolstoy.tols.org (tolstoy.tols.org [IPv6:2a02:898:0:20::57:1]) by mx1.freebsd.org (Postfix) with ESMTP id 5B4A38FC0A for ; Wed, 26 Jan 2011 18:04:06 +0000 (UTC) Received: from tolstoy.tols.org (localhost [127.0.0.1]) by tolstoy.tols.org (8.14.4/8.14.4) with ESMTP id p0QI42Q2017354 for ; Wed, 26 Jan 2011 18:04:02 GMT (envelope-from marco@tolstoy.tols.org) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.96.5 at tolstoy.tols.org Received: (from marco@localhost) by tolstoy.tols.org (8.14.4/8.14.4/Submit) id p0QI42bG017353 for freebsd-stable@freebsd.org; Wed, 26 Jan 2011 19:04:02 +0100 (CET) (envelope-from marco) Date: Wed, 26 Jan 2011 19:04:02 +0100 From: Marco van Tol To: freebsd-stable@freebsd.org Message-ID: <20110126180402.GA17271@tolstoy.tols.org> Mail-Followup-To: freebsd-stable@freebsd.org References: <4D401192.3030400@it4pro.pl> <201101260806.10084.jhb@freebsd.org> <4D401F9C.6050402@it4pro.pl> <201101261235.56856.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201101261235.56856.jhb@freebsd.org> User-Agent: Mutt/1.4.2.3i X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on tolstoy.tols.org Subject: Re: top shows only half of realmem? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jan 2011 18:04:06 -0000 On Wed, Jan 26, 2011 at 12:35:56PM -0500, John Baldwin wrote: > On Wednesday, January 26, 2011 8:20:28 am Bartosz Stec wrote: > > W dniu 2011-01-26 14:06, John Baldwin pisze: > > > On Wednesday, January 26, 2011 7:20:34 am Bartosz Stec wrote: > > >> Guys, > > >> > > >> could someone explain me this? > > >> > > >> # sysctl hw.realmem > > >> hw.realmem: 2139029504 > > >> > > >> top line shows: > > >> > > >> Mem: 32M Active, 35M Inact, 899M Wired, 8392K Cache, 199M Buf, 58M Free > > >> > > >> 32+35+899+8+199+58 = 1231MB > > >> > > >> Shouldn't that sum to all available ram? Or maybe I'm reading it wrong? > > >> This machine has indeed 2GB of ram on board and showed in BIOS. > > >> i386 FreeBSD 8.2-PRERELEASE #16: Mon Jan 17 22:28:53 CET 2011 > > >> Cheers. > > > First, don't include 'buf' as isn't a separate set of RAM, it is only a range > > > of the virtual address space in the kernel. It used to be relevant when the > > > buffer cache was separate from the VM page cache, but now it is mostly > > > irrelevant (arguably it should just be dropped from top output). > > > > Thanks for the explanation. So 1231MB - 199MB Buf and we got about 1GB > > of memory instead of 2B. > > > > > However, look at what hw.physmem says (and the realmem and availmem lines in > > > dmesg). realmem is actually not that useful as it is not a count of the > > > amount of memory, but the address of the highest memory page available. There > > > can be less memory available than that due to "holes" in the address space for > > > PCI memory BARs, etc. > > > > > OK, here you go: > > # sysctl hw | grep mem > > > > hw.physmem: 2125893632 > > hw.usermem: 1212100608 > > hw.realmem: 2139029504 > > hw.pci.host_mem_start: 2147483648 > > Humm, you should still have 2GB of RAM then. All the memory you set aside > for ARC should be counted in the 'wired' count, so I'm not sure why you see > 1GB of RAM rather than 2GB. For what its worth (seems to be the same values top shows), the sysctl's I use to make cacti graphs of memory usage are: (Counts are in pages) vm.stats.vm.v_page_size vm.stats.vm.v_wire_count vm.stats.vm.v_active_count vm.stats.vm.v_inactive_count vm.stats.vm.v_cache_count vm.stats.vm.v_free_count Using the output of those sysctls I allways get a cacti graph which at least very much seems to account for all memory, and has a flat surface in a stacked graph. HTH, Marco van Tol -- Wanneer je in de afgrond kijkt, kijkt de afgrond ook in jou. - Friedrich Nietzsche From owner-freebsd-stable@FreeBSD.ORG Wed Jan 26 18:44:59 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2A073106566B for ; Wed, 26 Jan 2011 18:44:59 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id DAA6C8FC14 for ; Wed, 26 Jan 2011 18:44:58 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 7AB3A46B2C; Wed, 26 Jan 2011 13:44:58 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 603218A009; Wed, 26 Jan 2011 13:44:57 -0500 (EST) From: John Baldwin To: freebsd-stable@freebsd.org Date: Wed, 26 Jan 2011 13:44:50 -0500 User-Agent: KMail/1.13.5 (FreeBSD/7.4-CBSD-20110107; KDE/4.4.5; amd64; ; ) References: <4D401192.3030400@it4pro.pl> <201101261235.56856.jhb@freebsd.org> <20110126180402.GA17271@tolstoy.tols.org> In-Reply-To: <20110126180402.GA17271@tolstoy.tols.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201101261344.50756.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Wed, 26 Jan 2011 13:44:57 -0500 (EST) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.9 required=4.2 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: Marco van Tol Subject: Re: top shows only half of realmem? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jan 2011 18:44:59 -0000 On Wednesday, January 26, 2011 1:04:02 pm Marco van Tol wrote: > On Wed, Jan 26, 2011 at 12:35:56PM -0500, John Baldwin wrote: > > On Wednesday, January 26, 2011 8:20:28 am Bartosz Stec wrote: > > > W dniu 2011-01-26 14:06, John Baldwin pisze: > > > > On Wednesday, January 26, 2011 7:20:34 am Bartosz Stec wrote: > > > >> Guys, > > > >> > > > >> could someone explain me this? > > > >> > > > >> # sysctl hw.realmem > > > >> hw.realmem: 2139029504 > > > >> > > > >> top line shows: > > > >> > > > >> Mem: 32M Active, 35M Inact, 899M Wired, 8392K Cache, 199M Buf, 58M Free > > > >> > > > >> 32+35+899+8+199+58 = 1231MB > > > >> > > > >> Shouldn't that sum to all available ram? Or maybe I'm reading it wrong? > > > >> This machine has indeed 2GB of ram on board and showed in BIOS. > > > >> i386 FreeBSD 8.2-PRERELEASE #16: Mon Jan 17 22:28:53 CET 2011 > > > >> Cheers. > > > > First, don't include 'buf' as isn't a separate set of RAM, it is only a range > > > > of the virtual address space in the kernel. It used to be relevant when the > > > > buffer cache was separate from the VM page cache, but now it is mostly > > > > irrelevant (arguably it should just be dropped from top output). > > > > > > Thanks for the explanation. So 1231MB - 199MB Buf and we got about 1GB > > > of memory instead of 2B. > > > > > > > However, look at what hw.physmem says (and the realmem and availmem lines in > > > > dmesg). realmem is actually not that useful as it is not a count of the > > > > amount of memory, but the address of the highest memory page available. There > > > > can be less memory available than that due to "holes" in the address space for > > > > PCI memory BARs, etc. > > > > > > > OK, here you go: > > > # sysctl hw | grep mem > > > > > > hw.physmem: 2125893632 > > > hw.usermem: 1212100608 > > > hw.realmem: 2139029504 > > > hw.pci.host_mem_start: 2147483648 > > > > Humm, you should still have 2GB of RAM then. All the memory you set aside > > for ARC should be counted in the 'wired' count, so I'm not sure why you see > > 1GB of RAM rather than 2GB. > > For what its worth (seems to be the same values top shows), the sysctl's > I use to make cacti graphs of memory usage are: (Counts are in pages) > > vm.stats.vm.v_page_size > > vm.stats.vm.v_wire_count > vm.stats.vm.v_active_count > vm.stats.vm.v_inactive_count > vm.stats.vm.v_cache_count > vm.stats.vm.v_free_count > > Using the output of those sysctls I allways get a cacti graph which at > least very much seems to account for all memory, and has a flat surface > in a stacked graph. These sysctls are exactly what top uses. There is also a 'v_page_count' which is a total count of pages. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Wed Jan 26 18:56:26 2011 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F3631106566C for ; Wed, 26 Jan 2011 18:56:25 +0000 (UTC) (envelope-from nonesuch@longcount.org) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id BBBDA8FC13 for ; Wed, 26 Jan 2011 18:56:25 +0000 (UTC) Received: by gyf3 with SMTP id 3so292215gyf.13 for ; Wed, 26 Jan 2011 10:56:25 -0800 (PST) MIME-Version: 1.0 Received: by 10.42.230.134 with SMTP id jm6mr907236icb.375.1296068184533; Wed, 26 Jan 2011 10:56:24 -0800 (PST) Received: by 10.42.8.147 with HTTP; Wed, 26 Jan 2011 10:56:24 -0800 (PST) X-Originating-IP: [216.223.13.183] In-Reply-To: <4D402CFA.40501@dssgmbh.de> References: <4D3E79D5.7050800@rdtc.ru> <4D3F24BE.1070206@FreeBSD.org> <4D402CFA.40501@dssgmbh.de> Date: Wed, 26 Jan 2011 13:56:24 -0500 Message-ID: From: Mark Saad To: stable@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Subject: Re: Living on gmirror: need to reincarnate /etc/rc.early X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jan 2011 18:56:26 -0000 On Wed, Jan 26, 2011 at 9:17 AM, Alfred Bartsch wrote: > Doug Barton schrieb: >> On 01/24/2011 23:20, Eugene Grosbein wrote: >>> Hi! >>> >>> In RELENG_8, gmirror is good enough to keep whole HDD pair withing the >>> mirror. >>> Its performance, stability any pretty ease of maintainance allows >>> to use it widely. >>> >>> With wide deployment of gmirror in production I've faced inability >>> of RELENG_8 to store kernel crashdumps out-of-the-box. >>> gmirror manual page documents a way to setup FreeBSD so that >>> it would store crashdumps again but that way involves /etc/rc.early >>> removed from RELENG_8. I've read about intentions - it was unsafe etc. >>> But we still need working crashdump support. >>> >>> Easiest way is to reincarnate /etc/rc.d/early support making it better >>> and safer >>> and it should support gmirror's mechanics for crashdumps out-of-the-box= . >> >> I'll tell you the same thing I told Kostik way back when I removed it. >> This is the only thing that anyone has ever suggested a use for in >> /etc/rc.early, and the "solution" in the man page is a hack. :) >> >> If this is something that is necessary to do then I'd prefer to do it >> properly and add an /etc/rc.d/gmirror that runs in the proper (early) >> position, and then figure out the proper location in rc.d to handle the >> second half of the configuration. >> >> I'm happy to review patches. =C2=A0:) >> >> >> Doug >> > Hi Doug, > at our site we are using the following scripts in /etc/rc.d to deal with > gmirror "specials": > > First part (/etc/rc.d/gmirror1): > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D > #!/bin/sh > > # PROVIDE: gmirror1 > # BEFORE: =C2=A0fsck > # KEYWORD: nojail > > . /etc/rc.subr > > name=3D"gmirror1" > start_cmd=3D"gmirror1_start" > stop_cmd=3D":" > > > gmirror1_start() > { > =C2=A0 echo "gmirror configure -b prefer gm0" > =C2=A0 gmirror configure -b prefer gm0 > } > > load_rc_config $name > run_rc_command "$1" > > # run only if provider /dev/mirror/gm0 exists > test -r /dev/mirror/gm0 || exit 0 > --------------------------------- > Second part (/etc/rc.d/gmirror2): > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D > #!/bin/sh > > # PROVIDE: gmirror2 > # REQUIRE: DAEMON > # BEFORE: =C2=A0LOGIN > # KEYWORD: nojail > > . /etc/rc.subr > > name=3D"gmirror2" > start_cmd=3D"gmirror2_start" > stop_cmd=3D":" > > gmirror2_start() > { > =C2=A0 echo "gmirror configure -b round-robin gm0" > =C2=A0 gmirror configure -b round-robin gm0 > } > > load_rc_config $name > run_rc_command "$1" > > # run only if provider /dev/mirror/gm0 exists > test -r /dev/mirror/gm0 || exit 0 > --------------------------------- > > In our environment, the name of the gmirror provider is always > "mirror/gm0". Variable naming of the provider should be added, > eventually extracted from "gmirror list" command. > > -- > Alfred Bartsch > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > On a side note without /etc/rc.early how would someone do the following tas= ks ? 1. On bootup relabel /dev/da2s1d to /dev/label/var where da2s1d is the var for this box. 2. Convert /usr from gjournal to su+j Not each task is exactly the same from server to server do to how each installer / admin decided to layout each disk. As you may know you cant relabel via glabel label, tunefs -J disable, gjournal off .. on a disk that was mounted read / write . The old /etc/rc.early allowed users to shoot quick scripts in there to fix systems on a reboot, which is very useful for systems you do not have direct console access to . So are we supposed to make a rcng script for each task, is there another way I am missing ? --=20 mark saad | nonesuch@longcount.org From owner-freebsd-stable@FreeBSD.ORG Thu Jan 27 00:59:29 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A121E106564A for ; Thu, 27 Jan 2011 00:59:29 +0000 (UTC) (envelope-from bartosz.stec@it4pro.pl) Received: from mainframe.kkip.pl (kkip.pl [87.105.164.78]) by mx1.freebsd.org (Postfix) with ESMTP id 080208FC08 for ; Thu, 27 Jan 2011 00:59:28 +0000 (UTC) Received: from static-78-8-144-74.ssp.dialog.net.pl ([78.8.144.74] helo=[192.168.0.2]) by mainframe.kkip.pl with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.73 (FreeBSD)) (envelope-from ) id 1PiGCi-0009jj-Ah for freebsd-stable@freebsd.org; Thu, 27 Jan 2011 01:59:27 +0100 Message-ID: <4D40C355.6070306@it4pro.pl> Date: Thu, 27 Jan 2011 01:59:01 +0100 From: Bartosz Stec Organization: IT4Pro User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; pl; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <4D401192.3030400@it4pro.pl> <201101261235.56856.jhb@freebsd.org> <20110126180402.GA17271@tolstoy.tols.org> <201101261344.50756.jhb@freebsd.org> In-Reply-To: <201101261344.50756.jhb@freebsd.org> X-Authenticated-User: bartosz.stec@it4pro.pl X-Authenticator: plain X-Sender-Verify: SUCCEEDED (sender exists & accepts mail) X-Spam-Score: -8.1 X-Spam-Score-Int: -80 X-Exim-Version: 4.73 (build at 10-Jan-2011 16:29:01) X-Date: 2011-01-27 01:59:27 X-Connected-IP: 78.8.144.74:64347 X-Message-Linecount: 353 X-Body-Linecount: 340 X-Message-Size: 13242 X-Body-Size: 12582 X-Received-Count: 1 X-Recipient-Count: 1 X-Local-Recipient-Count: 1 X-Local-Recipient-Defer-Count: 0 X-Local-Recipient-Fail-Count: 0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: top shows only part of available physmem X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 00:59:29 -0000 W dniu 2011-01-26 19:44, John Baldwin pisze: > On Wednesday, January 26, 2011 1:04:02 pm Marco van Tol wrote: >> On Wed, Jan 26, 2011 at 12:35:56PM -0500, John Baldwin wrote: >>> On Wednesday, January 26, 2011 8:20:28 am Bartosz Stec wrote: >>>> W dniu 2011-01-26 14:06, John Baldwin pisze: >>>>> On Wednesday, January 26, 2011 7:20:34 am Bartosz Stec wrote: >>>>>> Guys, >>>>>> >>>>>> could someone explain me this? >>>>>> >>>>>> # sysctl hw.realmem >>>>>> hw.realmem: 2139029504 >>>>>> >>>>>> top line shows: >>>>>> >>>>>> Mem: 32M Active, 35M Inact, 899M Wired, 8392K Cache, 199M Buf, 58M Free >>>>>> >>>>>> 32+35+899+8+199+58 = 1231MB >>>>>> >>>>>> Shouldn't that sum to all available ram? Or maybe I'm reading it wrong? >>>>>> This machine has indeed 2GB of ram on board and showed in BIOS. >>>>>> i386 FreeBSD 8.2-PRERELEASE #16: Mon Jan 17 22:28:53 CET 2011 >>>>>> Cheers. >>>>> First, don't include 'buf' as isn't a separate set of RAM, it is only a range >>>>> of the virtual address space in the kernel. It used to be relevant when the >>>>> buffer cache was separate from the VM page cache, but now it is mostly >>>>> irrelevant (arguably it should just be dropped from top output). >>>> Thanks for the explanation. So 1231MB - 199MB Buf and we got about 1GB >>>> of memory instead of 2B. >>>> >>>>> However, look at what hw.physmem says (and the realmem and availmem lines in >>>>> dmesg). realmem is actually not that useful as it is not a count of the >>>>> amount of memory, but the address of the highest memory page available. There >>>>> can be less memory available than that due to "holes" in the address space for >>>>> PCI memory BARs, etc. >>>>> >>>> OK, here you go: >>>> # sysctl hw | grep mem >>>> >>>> hw.physmem: 2125893632 >>>> hw.usermem: 1212100608 >>>> hw.realmem: 2139029504 >>>> hw.pci.host_mem_start: 2147483648 >>> Humm, you should still have 2GB of RAM then. All the memory you set aside >>> for ARC should be counted in the 'wired' count, so I'm not sure why you see >>> 1GB of RAM rather than 2GB. >> For what its worth (seems to be the same values top shows), the sysctl's >> I use to make cacti graphs of memory usage are: (Counts are in pages) >> >> vm.stats.vm.v_page_size >> >> vm.stats.vm.v_wire_count >> vm.stats.vm.v_active_count >> vm.stats.vm.v_inactive_count >> vm.stats.vm.v_cache_count >> vm.stats.vm.v_free_count >> >> Using the output of those sysctls I allways get a cacti graph which at >> least very much seems to account for all memory, and has a flat surface >> in a stacked graph. > These sysctls are exactly what top uses. There is also a 'v_page_count' > which is a total count of pages. > So here's additional sysctl output from now: fbsd# sysctl hw | grep mem hw.physmem: 2125893632 hw.usermem: 1392594944 hw.realmem: 2139029504 hw.pci.host_mem_start: 2147483648 fbsd# sysctl vm.stats.vm vm.stats.vm.v_kthreadpages: 0 vm.stats.vm.v_rforkpages: 0 vm.stats.vm.v_vforkpages: 1422927 vm.stats.vm.v_forkpages: 4606557 vm.stats.vm.v_kthreads: 40 vm.stats.vm.v_rforks: 0 vm.stats.vm.v_vforks: 9917 vm.stats.vm.v_forks: 30429 vm.stats.vm.v_interrupt_free_min: 2 vm.stats.vm.v_pageout_free_min: 34 vm.stats.vm.v_cache_max: 27506 vm.stats.vm.v_cache_min: 13753 vm.stats.vm.v_cache_count: 20312 vm.stats.vm.v_inactive_count: 18591 vm.stats.vm.v_inactive_target: 20629 vm.stats.vm.v_active_count: 1096 vm.stats.vm.v_wire_count: 179027 vm.stats.vm.v_free_count: 6193 vm.stats.vm.v_free_min: 3260 vm.stats.vm.v_free_target: 13753 vm.stats.vm.v_free_reserved: 713 vm.stats.vm.v_page_count: 509752 vm.stats.vm.v_page_size: 4096 vm.stats.vm.v_tfree: 196418851 vm.stats.vm.v_pfree: 2837177 vm.stats.vm.v_dfree: 0 vm.stats.vm.v_tcached: 1305893 vm.stats.vm.v_pdpages: 3527455 vm.stats.vm.v_pdwakeups: 187 vm.stats.vm.v_reactivated: 83786 vm.stats.vm.v_intrans: 3053 vm.stats.vm.v_vnodepgsout: 134384 vm.stats.vm.v_vnodepgsin: 29213 vm.stats.vm.v_vnodeout: 96249 vm.stats.vm.v_vnodein: 29213 vm.stats.vm.v_swappgsout: 19730 vm.stats.vm.v_swappgsin: 8573 vm.stats.vm.v_swapout: 5287 vm.stats.vm.v_swapin: 2975 vm.stats.vm.v_ozfod: 83338 vm.stats.vm.v_zfod: 2462557 vm.stats.vm.v_cow_optim: 330 vm.stats.vm.v_cow_faults: 1239253 vm.stats.vm.v_vm_faults: 5898471 fbsd# sysctl vm.vmtotal vm.vmtotal: System wide totals computed every five seconds: (values in kilobytes) =============================================== Processes: (RUNQ: 1 Disk Wait: 0 Page Wait: 0 Sleep: 60) Virtual Memory: (Total: 4971660K Active: 699312K) Real Memory: (Total: 540776K Active: 29756K) Shared Virtual Memory: (Total: 41148K Active: 19468K) Shared Real Memory: (Total: 4964K Active: 3048K) Free Memory Pages: 105308K /usr/bin/top line: Mem: 4664K Active, 73M Inact, 700M Wired, 79M Cache, 199M Buf, 23M Free Sum (Without Buf): 879,5 MB So what are we looking at? Wrong sysctls/top output or maybe actually FreeBSD doesn't use all available RAM for some reason? Could it be hardware problem? Maybe I should provide some additional data? -- Bartosz Stec From owner-freebsd-stable@FreeBSD.ORG Thu Jan 27 03:21:44 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DE51E106564A for ; Thu, 27 Jan 2011 03:21:44 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta08.emeryville.ca.mail.comcast.net (qmta08.emeryville.ca.mail.comcast.net [76.96.30.80]) by mx1.freebsd.org (Postfix) with ESMTP id BDF558FC0A for ; Thu, 27 Jan 2011 03:21:44 +0000 (UTC) Received: from omta22.emeryville.ca.mail.comcast.net ([76.96.30.89]) by qmta08.emeryville.ca.mail.comcast.net with comcast id 0T8S1g0021vN32cA8TMkdU; Thu, 27 Jan 2011 03:21:44 +0000 Received: from koitsu.dyndns.org ([98.248.34.134]) by omta22.emeryville.ca.mail.comcast.net with comcast id 0TMi1g00s2tehsa8iTMjnd; Thu, 27 Jan 2011 03:21:43 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 93E509B422; Wed, 26 Jan 2011 19:21:42 -0800 (PST) Date: Wed, 26 Jan 2011 19:21:42 -0800 From: Jeremy Chadwick To: Bartosz Stec Message-ID: <20110127032142.GA19946@icarus.home.lan> References: <4D401192.3030400@it4pro.pl> <201101261235.56856.jhb@freebsd.org> <20110126180402.GA17271@tolstoy.tols.org> <201101261344.50756.jhb@freebsd.org> <4D40C355.6070306@it4pro.pl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D40C355.6070306@it4pro.pl> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-stable@freebsd.org Subject: Re: top shows only part of available physmem X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 03:21:44 -0000 On Thu, Jan 27, 2011 at 01:59:01AM +0100, Bartosz Stec wrote: > W dniu 2011-01-26 19:44, John Baldwin pisze: > >On Wednesday, January 26, 2011 1:04:02 pm Marco van Tol wrote: > >>On Wed, Jan 26, 2011 at 12:35:56PM -0500, John Baldwin wrote: > >>>On Wednesday, January 26, 2011 8:20:28 am Bartosz Stec wrote: > >>>>W dniu 2011-01-26 14:06, John Baldwin pisze: > >>>>>On Wednesday, January 26, 2011 7:20:34 am Bartosz Stec wrote: > >>>>>>Guys, > >>>>>> > >>>>>>could someone explain me this? > >>>>>> > >>>>>> # sysctl hw.realmem > >>>>>> hw.realmem: 2139029504 > >>>>>> > >>>>>>top line shows: > >>>>>> > >>>>>> Mem: 32M Active, 35M Inact, 899M Wired, 8392K Cache, 199M Buf, 58M Free > >>>>>> > >>>>>>32+35+899+8+199+58 = 1231MB > >>>>>> > >>>>>>Shouldn't that sum to all available ram? Or maybe I'm reading it wrong? > >>>>>>This machine has indeed 2GB of ram on board and showed in BIOS. > >>>>>>i386 FreeBSD 8.2-PRERELEASE #16: Mon Jan 17 22:28:53 CET 2011 > >>>>>>Cheers. > >>>>>First, don't include 'buf' as isn't a separate set of RAM, it is only a range > >>>>>of the virtual address space in the kernel. It used to be relevant when the > >>>>>buffer cache was separate from the VM page cache, but now it is mostly > >>>>>irrelevant (arguably it should just be dropped from top output). > >>>>Thanks for the explanation. So 1231MB - 199MB Buf and we got about 1GB > >>>>of memory instead of 2B. > >>>> > >>>>>However, look at what hw.physmem says (and the realmem and availmem lines in > >>>>>dmesg). realmem is actually not that useful as it is not a count of the > >>>>>amount of memory, but the address of the highest memory page available. There > >>>>>can be less memory available than that due to "holes" in the address space for > >>>>>PCI memory BARs, etc. > >>>>> > >>>>OK, here you go: > >>>># sysctl hw | grep mem > >>>> > >>>> hw.physmem: 2125893632 > >>>> hw.usermem: 1212100608 > >>>> hw.realmem: 2139029504 > >>>> hw.pci.host_mem_start: 2147483648 > >>>Humm, you should still have 2GB of RAM then. All the memory you set aside > >>>for ARC should be counted in the 'wired' count, so I'm not sure why you see > >>>1GB of RAM rather than 2GB. > >>For what its worth (seems to be the same values top shows), the sysctl's > >>I use to make cacti graphs of memory usage are: (Counts are in pages) > >> > >>vm.stats.vm.v_page_size > >> > >>vm.stats.vm.v_wire_count > >>vm.stats.vm.v_active_count > >>vm.stats.vm.v_inactive_count > >>vm.stats.vm.v_cache_count > >>vm.stats.vm.v_free_count > >> > >>Using the output of those sysctls I allways get a cacti graph which at > >>least very much seems to account for all memory, and has a flat surface > >>in a stacked graph. > >These sysctls are exactly what top uses. There is also a 'v_page_count' > >which is a total count of pages. > > > So here's additional sysctl output from now: > > fbsd# sysctl hw | grep mem > hw.physmem: 2125893632 > hw.usermem: 1392594944 > hw.realmem: 2139029504 > hw.pci.host_mem_start: 2147483648 > > fbsd# sysctl vm.stats.vm > vm.stats.vm.v_kthreadpages: 0 > vm.stats.vm.v_rforkpages: 0 > vm.stats.vm.v_vforkpages: 1422927 > vm.stats.vm.v_forkpages: 4606557 > vm.stats.vm.v_kthreads: 40 > vm.stats.vm.v_rforks: 0 > vm.stats.vm.v_vforks: 9917 > vm.stats.vm.v_forks: 30429 > vm.stats.vm.v_interrupt_free_min: 2 > vm.stats.vm.v_pageout_free_min: 34 > vm.stats.vm.v_cache_max: 27506 > vm.stats.vm.v_cache_min: 13753 > vm.stats.vm.v_cache_count: 20312 > vm.stats.vm.v_inactive_count: 18591 > vm.stats.vm.v_inactive_target: 20629 > vm.stats.vm.v_active_count: 1096 > vm.stats.vm.v_wire_count: 179027 > vm.stats.vm.v_free_count: 6193 > vm.stats.vm.v_free_min: 3260 > vm.stats.vm.v_free_target: 13753 > vm.stats.vm.v_free_reserved: 713 > vm.stats.vm.v_page_count: 509752 > vm.stats.vm.v_page_size: 4096 > vm.stats.vm.v_tfree: 196418851 > vm.stats.vm.v_pfree: 2837177 > vm.stats.vm.v_dfree: 0 > vm.stats.vm.v_tcached: 1305893 > vm.stats.vm.v_pdpages: 3527455 > vm.stats.vm.v_pdwakeups: 187 > vm.stats.vm.v_reactivated: 83786 > vm.stats.vm.v_intrans: 3053 > vm.stats.vm.v_vnodepgsout: 134384 > vm.stats.vm.v_vnodepgsin: 29213 > vm.stats.vm.v_vnodeout: 96249 > vm.stats.vm.v_vnodein: 29213 > vm.stats.vm.v_swappgsout: 19730 > vm.stats.vm.v_swappgsin: 8573 > vm.stats.vm.v_swapout: 5287 > vm.stats.vm.v_swapin: 2975 > vm.stats.vm.v_ozfod: 83338 > vm.stats.vm.v_zfod: 2462557 > vm.stats.vm.v_cow_optim: 330 > vm.stats.vm.v_cow_faults: 1239253 > vm.stats.vm.v_vm_faults: 5898471 > > fbsd# sysctl vm.vmtotal > vm.vmtotal: > System wide totals computed every five seconds: (values in kilobytes) > =============================================== > Processes: (RUNQ: 1 Disk Wait: 0 Page Wait: 0 Sleep: 60) > Virtual Memory: (Total: 4971660K Active: 699312K) > Real Memory: (Total: 540776K Active: 29756K) > Shared Virtual Memory: (Total: 41148K Active: 19468K) > Shared Real Memory: (Total: 4964K Active: 3048K) > Free Memory Pages: 105308K > > > /usr/bin/top line: Mem: 4664K Active, 73M Inact, 700M Wired, 79M > Cache, 199M Buf, 23M Free > Sum (Without Buf): 879,5 MB > > So what are we looking at? Wrong sysctls/top output or maybe > actually FreeBSD doesn't use all available RAM for some reason? > Could it be hardware problem? Maybe I should provide some additional > data? Does the behaviour become more expected if you remove ZFS from the picture? Please try this (yes really). -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Thu Jan 27 09:57:26 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AAAEE1065673; Thu, 27 Jan 2011 09:57:26 +0000 (UTC) (envelope-from ml@my.gd) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 02DD88FC0C; Thu, 27 Jan 2011 09:57:24 +0000 (UTC) Received: by bwz12 with SMTP id 12so2249634bwz.13 for ; Thu, 27 Jan 2011 01:57:23 -0800 (PST) Received: by 10.204.56.3 with SMTP id w3mr1368730bkg.60.1296122242330; Thu, 27 Jan 2011 01:57:22 -0800 (PST) Received: from dfleuriot.technique-admin.paris.hi-media-techno.com ([83.167.62.196]) by mx.google.com with ESMTPS id 12sm7986486bki.19.2011.01.27.01.57.16 (version=SSLv3 cipher=RC4-MD5); Thu, 27 Jan 2011 01:57:18 -0800 (PST) Message-ID: <4D41417A.20904@my.gd> Date: Thu, 27 Jan 2011 10:57:14 +0100 From: Damien Fleuriot User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "freebsd-stable@freebsd.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-pf@freebsd.org Subject: High interrupt rate on a PF box + performance X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 09:57:26 -0000 Hello list, I have a problem with interrupts, network cards, and PF performance. We have 2 firewalls running FreeBSD 8.0 for the current master and FreeBSD 8.1 for the backup host, which I upgraded just yesterday. The servers use CARP for redundancy. These are rather busy boxes which run PF and nginx as a reverse proxy. As you will see below, we're getting a "high" %interrupt CPU usage, which seems to come mostly from the NICs. I'm wondering if there is any way to optimize the box's performance and reduce the interrupts rate or the CPU usage ? Also, we've noticed a sharp drop in CPU usage since we've disabled pfsync, but we'd rather keep it now wouldn't we ? Last, we seem to get input errors on the NICs, although the switch ports report not a single layer 2 error in over a year. I'm wondering what counts as a NIC input error ? Hardware is as follows: CPU -- CPU: Intel(R) Xeon(R) CPU E5420 @ 2.50GHz (2496.25-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x10676 Stepping = 6 Features=0xbfebfbff Features2=0xce3bd AMD Features=0x20100800 AMD Features2=0x1 TSC: P-state invariant ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 package(s) x 4 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 MEM -- real memory = 2147483648 (2048 MB) avail memory = 2057293824 (1961 MB) NICs -- bce0: mem 0xf4000000-0xf5ffffff irq 16 at device 0.0 on pci7 bce1: mem 0xf8000000-0xf9ffffff irq 16 at device 0.0 on pci3 igb0: port 0xdce0-0xdcff mem 0xfd0e0000-0xfd0fffff,0xfce00000-0xfcffffff,0xfd0dc000-0xfd0dffff irq 18 at device 0.0 on pci14 igb0: Using MSIX interrupts with 3 vectors Find below different outputs from the current master running FreeBSD 8.0-RELEASE-p2 systat -v --- 3 users Load 0.41 0.31 0.29 Jan 26 18:59 Mem:KB REAL VIRTUAL VN PAGER SWAP PAGER Tot Share Tot Share Free in out in out Act 143036 8152 836392 11188 1262556 count All 168224 10420 1074653k 31172 pages Proc: Interrupts r p d s w Csw Trp Sys Int Sof Flt cow 36163 total 47 105k 76 2077 28k 223 zfod ata0 irq14 ozfod mfi0 irq16 4.3%Sys 28.1%Intr 3.0%User 0.0%Nice 64.7%Idle %ozfod uhci0 uhci | | | | | | | | | | | daefr 1998 cpu0: time ==++++++++++++++>> prcfr 9428 bce0 256 33 dtbuf totfr 12931 igb0 257 Namei Name-cache Dir-cache 100000 desvn react 5791 igb0 258 Calls hits % hits % 70448 numvn pdwak igb0 259 24988 frevn pdpgs igb1 260 intrn 1 igb1 261 Disks mfid0 372392 wire igb1 262 KB/t 0.00 62336 act 20 bce1 269 tps 0 323720 inact 1998 cpu1: time MB/s 0.00 292 cache 1998 cpu2: time %busy 0 1262264 free 1998 cpu3: time 218272 buf vmstat -i --- interrupt total rate irq14: ata0 36 0 irq16: mfi0 353244 1 irq21: uhci0 uhci+ 461504 1 cpu0: timer 615183815 1996 irq256: bce0 1015412475 3295 irq257: igb0 1067318584 3464 irq258: igb0 695648752 2258 irq259: igb0 2 0 irq260: igb1 11503857 37 irq261: igb1 506598 1 irq262: igb1 69 0 irq269: bce1 790820 2 cpu1: timer 615183757 1996 cpu2: timer 615197165 1996 cpu3: timer 615197165 1996 Total 5252757843 17050 pf status (159 filter rules, 17 nat/rdr rules) --- # pfctl -si Status: Enabled for 3 days 13:34:56 Debug: Urgent Interface Stats for igb0 IPv4 IPv6 Bytes In 487209136643 384 Bytes Out 687158173727 0 Packets In Passed 1967249106 0 Blocked 6183860 6 Packets Out Passed 2018192359 0 Blocked 686901 0 State Table Total Rate current entries 25428 searches 9006187476 29231.8/s inserts 679746853 2206.3/s removals 679721425 2206.2/s Counters match 686988143 2229.8/s bad-offset 0 0.0/s fragment 56 0.0/s short 0 0.0/s normalize 171 0.0/s memory 0 0.0/s bad-timestamp 0 0.0/s congestion 0 0.0/s ip-option 1 0.0/s proto-cksum 13916 0.0/s state-mismatch 220169 0.7/s state-insert 0 0.0/s state-limit 0 0.0/s src-limit 1812 0.0/s synproxy 0 0.0/s Regards, -- dfl From owner-freebsd-stable@FreeBSD.ORG Thu Jan 27 10:04:12 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 26AF61065670 for ; Thu, 27 Jan 2011 10:04:12 +0000 (UTC) (envelope-from bartosz.stec@it4pro.pl) Received: from mainframe.kkip.pl (kkip.pl [87.105.164.78]) by mx1.freebsd.org (Postfix) with ESMTP id CC8018FC14 for ; Thu, 27 Jan 2011 10:04:11 +0000 (UTC) Received: from static-78-8-144-74.ssp.dialog.net.pl ([78.8.144.74] helo=[192.168.0.2]) by mainframe.kkip.pl with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.73 (FreeBSD)) (envelope-from ) id 1PiOhv-000BZ8-2q; Thu, 27 Jan 2011 11:04:10 +0100 Message-ID: <4D414304.3090905@it4pro.pl> Date: Thu, 27 Jan 2011 11:03:48 +0100 From: Bartosz Stec Organization: IT4Pro User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; pl; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Damien Fleuriot References: <4D41417A.20904@my.gd> In-Reply-To: <4D41417A.20904@my.gd> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated-User: bartosz.stec@it4pro.pl X-Authenticator: plain X-Sender-Verify: SUCCEEDED (sender exists & accepts mail) X-Spam-Score: -8.1 X-Spam-Score-Int: -80 X-Exim-Version: 4.73 (build at 10-Jan-2011 16:29:01) X-Date: 2011-01-27 11:04:10 X-Connected-IP: 78.8.144.74:63193 X-Message-Linecount: 27 X-Body-Linecount: 12 X-Message-Size: 877 X-Body-Size: 254 X-Received-Count: 1 X-Recipient-Count: 3 X-Local-Recipient-Count: 3 X-Local-Recipient-Defer-Count: 0 X-Local-Recipient-Fail-Count: 0 Cc: "freebsd-stable@freebsd.org" , freebsd-pf@freebsd.org Subject: Re: High interrupt rate on a PF box + performance X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 10:04:12 -0000 W dniu 2011-01-27 10:57, Damien Fleuriot pisze: > Hello list, > > I have a problem with interrupts, network cards, and PF performance. > I think you should try with polling(4) enabled and probably increase kernel.hz i sysctl.conf :) -- Bartosz Stec From owner-freebsd-stable@FreeBSD.ORG Thu Jan 27 10:48:38 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6DD17106564A; Thu, 27 Jan 2011 10:48:38 +0000 (UTC) (envelope-from ml@my.gd) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 1E15A8FC0A; Thu, 27 Jan 2011 10:48:37 +0000 (UTC) Received: by gxk8 with SMTP id 8so578466gxk.13 for ; Thu, 27 Jan 2011 02:48:37 -0800 (PST) Received: by 10.100.105.16 with SMTP id d16mr461544anc.219.1296125316863; Thu, 27 Jan 2011 02:48:36 -0800 (PST) Received: from dfleuriot.technique-admin.paris.hi-media-techno.com ([83.167.62.196]) by mx.google.com with ESMTPS id f10sm20287328anh.5.2011.01.27.02.48.34 (version=SSLv3 cipher=RC4-MD5); Thu, 27 Jan 2011 02:48:35 -0800 (PST) Message-ID: <4D414D80.3060706@my.gd> Date: Thu, 27 Jan 2011 11:48:32 +0100 From: Damien Fleuriot User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Bartosz Stec References: <4D41417A.20904@my.gd> <4D414304.3090905@it4pro.pl> In-Reply-To: <4D414304.3090905@it4pro.pl> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "freebsd-stable@freebsd.org" , freebsd-pf@freebsd.org Subject: Re: High interrupt rate on a PF box + performance X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 10:48:38 -0000 On 1/27/11 11:03 AM, Bartosz Stec wrote: > W dniu 2011-01-27 10:57, Damien Fleuriot pisze: >> Hello list, >> >> I have a problem with interrupts, network cards, and PF performance. >> > I think you should try with polling(4) enabled and probably increase > kernel.hz i sysctl.conf :) > As a matter of fact, we tried polling on the backup firewall yesterday with the following kernel options: options DEVICE_POLLING options HZ=1000 This had disastrous results. First, our LAN and DMZ interfaces (bce0 and 1) do not support polling, so no change here. Second, the WAN interface (igb0) supports polling but that caused problems with carp0 and the physical interface resetting itself for god knows what reason: carp0: link state changed to DOWN carp0: INIT -> BACKUP igb0: link state changed to UP carp0: link state changed to DOWN carp0: link state changed to UP carp0: MASTER -> BACKUP (more frequent advertisement received) carp0: link state changed to DOWN carp0: link state changed to UP igb0: Watchdog timeout -- resetting igb0: Queue(1) tdh = 57, hw tdt = 57 igb0: TX(1) desc avail = 967,Next TX to Clean = 0 igb0: link state changed to DOWN carp0: link state changed to DOWN carp0: INIT -> BACKUP igb0: link state changed to UP carp0: link state changed to DOWN carp0: link state changed to UP carp0: link state changed to DOWN igb0: Watchdog timeout -- resetting igb0: Queue(3) tdh = 5, hw tdt = 5 igb0: TX(3) desc avail = 1019,Next TX to Clean = 0 igb0: link state changed to DOWN igb0: link state changed to UP igb0: Watchdog timeout -- resetting igb0: Queue(2) tdh = 53, hw tdt = 53 igb0: TX(2) desc avail = 971,Next TX to Clean = 0 igb0: link state changed to DOWN igb0: link state changed to UP igb0: Watchdog timeout -- resetting igb0: Queue(2) tdh = 19, hw tdt = 19 igb0: TX(2) desc avail = 1005,Next TX to Clean = 0 igb0: link state changed to DOWN igb0: link state changed to UP From owner-freebsd-stable@FreeBSD.ORG Thu Jan 27 13:56:35 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 61AB5106564A for ; Thu, 27 Jan 2011 13:56:35 +0000 (UTC) (envelope-from bartosz.stec@it4pro.pl) Received: from mainframe.kkip.pl (kkip.pl [87.105.164.78]) by mx1.freebsd.org (Postfix) with ESMTP id EE6038FC0A for ; Thu, 27 Jan 2011 13:56:34 +0000 (UTC) Received: from gkp139.internetdsl.tpnet.pl ([83.3.15.139] helo=[192.168.219.130]) by mainframe.kkip.pl with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.73 (FreeBSD)) (envelope-from ) id 1PiSJb-000JkY-On; Thu, 27 Jan 2011 14:56:31 +0100 Message-ID: <4D417931.1060009@it4pro.pl> Date: Thu, 27 Jan 2011 14:54:57 +0100 From: Bartosz Stec Organization: IT4Pro User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; pl; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Jeremy Chadwick References: <4D401192.3030400@it4pro.pl> <201101261235.56856.jhb@freebsd.org> <20110126180402.GA17271@tolstoy.tols.org> <201101261344.50756.jhb@freebsd.org> <4D40C355.6070306@it4pro.pl> <20110127032142.GA19946@icarus.home.lan> In-Reply-To: <20110127032142.GA19946@icarus.home.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated-User: bartosz.stec@it4pro.pl X-Authenticator: plain X-Sender-Verify: SUCCEEDED (sender exists & accepts mail) X-Spam-Score: -8.1 X-Spam-Score-Int: -80 X-Exim-Version: 4.73 (build at 10-Jan-2011 16:29:01) X-Date: 2011-01-27 14:56:31 X-Connected-IP: 83.3.15.139:2435 X-Message-Linecount: 175 X-Body-Linecount: 160 X-Message-Size: 7481 X-Body-Size: 6627 X-Received-Count: 1 X-Recipient-Count: 2 X-Local-Recipient-Count: 2 X-Local-Recipient-Defer-Count: 0 X-Local-Recipient-Fail-Count: 0 Cc: freebsd-stable@freebsd.org Subject: Re: top shows only part of available physmem X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 13:56:35 -0000 W dniu 2011-01-27 04:21, Jeremy Chadwick pisze: > On Thu, Jan 27, 2011 at 01:59:01AM +0100, Bartosz Stec wrote: >> W dniu 2011-01-26 19:44, John Baldwin pisze: >>> On Wednesday, January 26, 2011 1:04:02 pm Marco van Tol wrote: >>>> On Wed, Jan 26, 2011 at 12:35:56PM -0500, John Baldwin wrote: >>>>> On Wednesday, January 26, 2011 8:20:28 am Bartosz Stec wrote: >>>>>> W dniu 2011-01-26 14:06, John Baldwin pisze: >>>>>>> On Wednesday, January 26, 2011 7:20:34 am Bartosz Stec wrote: >>>>>>>> Guys, >>>>>>>> >>>>>>>> could someone explain me this? >>>>>>>> >>>>>>>> # sysctl hw.realmem >>>>>>>> hw.realmem: 2139029504 >>>>>>>> >>>>>>>> top line shows: >>>>>>>> >>>>>>>> Mem: 32M Active, 35M Inact, 899M Wired, 8392K Cache, 199M Buf, 58M Free >>>>>>>> >>>>>>>> 32+35+899+8+199+58 = 1231MB >>>>>>>> >>>>>>>> Shouldn't that sum to all available ram? Or maybe I'm reading it wrong? >>>>>>>> This machine has indeed 2GB of ram on board and showed in BIOS. >>>>>>>> i386 FreeBSD 8.2-PRERELEASE #16: Mon Jan 17 22:28:53 CET 2011 >>>>>>>> Cheers. >>>>>>> First, don't include 'buf' as isn't a separate set of RAM, it is only a range >>>>>>> of the virtual address space in the kernel. It used to be relevant when the >>>>>>> buffer cache was separate from the VM page cache, but now it is mostly >>>>>>> irrelevant (arguably it should just be dropped from top output). >>>>>> Thanks for the explanation. So 1231MB - 199MB Buf and we got about 1GB >>>>>> of memory instead of 2B. >>>>>> >>>>>>> However, look at what hw.physmem says (and the realmem and availmem lines in >>>>>>> dmesg). realmem is actually not that useful as it is not a count of the >>>>>>> amount of memory, but the address of the highest memory page available. There >>>>>>> can be less memory available than that due to "holes" in the address space for >>>>>>> PCI memory BARs, etc. >>>>>>> >>>>>> OK, here you go: >>>>>> # sysctl hw | grep mem >>>>>> >>>>>> hw.physmem: 2125893632 >>>>>> hw.usermem: 1212100608 >>>>>> hw.realmem: 2139029504 >>>>>> hw.pci.host_mem_start: 2147483648 >>>>> Humm, you should still have 2GB of RAM then. All the memory you set aside >>>>> for ARC should be counted in the 'wired' count, so I'm not sure why you see >>>>> 1GB of RAM rather than 2GB. >>>> For what its worth (seems to be the same values top shows), the sysctl's >>>> I use to make cacti graphs of memory usage are: (Counts are in pages) >>>> >>>> vm.stats.vm.v_page_size >>>> >>>> vm.stats.vm.v_wire_count >>>> vm.stats.vm.v_active_count >>>> vm.stats.vm.v_inactive_count >>>> vm.stats.vm.v_cache_count >>>> vm.stats.vm.v_free_count >>>> >>>> Using the output of those sysctls I allways get a cacti graph which at >>>> least very much seems to account for all memory, and has a flat surface >>>> in a stacked graph. >>> These sysctls are exactly what top uses. There is also a 'v_page_count' >>> which is a total count of pages. >>> >> So here's additional sysctl output from now: >> >> fbsd# sysctl hw | grep mem >> hw.physmem: 2125893632 >> hw.usermem: 1392594944 >> hw.realmem: 2139029504 >> hw.pci.host_mem_start: 2147483648 >> >> fbsd# sysctl vm.stats.vm >> vm.stats.vm.v_kthreadpages: 0 >> vm.stats.vm.v_rforkpages: 0 >> vm.stats.vm.v_vforkpages: 1422927 >> vm.stats.vm.v_forkpages: 4606557 >> vm.stats.vm.v_kthreads: 40 >> vm.stats.vm.v_rforks: 0 >> vm.stats.vm.v_vforks: 9917 >> vm.stats.vm.v_forks: 30429 >> vm.stats.vm.v_interrupt_free_min: 2 >> vm.stats.vm.v_pageout_free_min: 34 >> vm.stats.vm.v_cache_max: 27506 >> vm.stats.vm.v_cache_min: 13753 >> vm.stats.vm.v_cache_count: 20312 >> vm.stats.vm.v_inactive_count: 18591 >> vm.stats.vm.v_inactive_target: 20629 >> vm.stats.vm.v_active_count: 1096 >> vm.stats.vm.v_wire_count: 179027 >> vm.stats.vm.v_free_count: 6193 >> vm.stats.vm.v_free_min: 3260 >> vm.stats.vm.v_free_target: 13753 >> vm.stats.vm.v_free_reserved: 713 >> vm.stats.vm.v_page_count: 509752 >> vm.stats.vm.v_page_size: 4096 >> vm.stats.vm.v_tfree: 196418851 >> vm.stats.vm.v_pfree: 2837177 >> vm.stats.vm.v_dfree: 0 >> vm.stats.vm.v_tcached: 1305893 >> vm.stats.vm.v_pdpages: 3527455 >> vm.stats.vm.v_pdwakeups: 187 >> vm.stats.vm.v_reactivated: 83786 >> vm.stats.vm.v_intrans: 3053 >> vm.stats.vm.v_vnodepgsout: 134384 >> vm.stats.vm.v_vnodepgsin: 29213 >> vm.stats.vm.v_vnodeout: 96249 >> vm.stats.vm.v_vnodein: 29213 >> vm.stats.vm.v_swappgsout: 19730 >> vm.stats.vm.v_swappgsin: 8573 >> vm.stats.vm.v_swapout: 5287 >> vm.stats.vm.v_swapin: 2975 >> vm.stats.vm.v_ozfod: 83338 >> vm.stats.vm.v_zfod: 2462557 >> vm.stats.vm.v_cow_optim: 330 >> vm.stats.vm.v_cow_faults: 1239253 >> vm.stats.vm.v_vm_faults: 5898471 >> >> fbsd# sysctl vm.vmtotal >> vm.vmtotal: >> System wide totals computed every five seconds: (values in kilobytes) >> =============================================== >> Processes: (RUNQ: 1 Disk Wait: 0 Page Wait: 0 Sleep: 60) >> Virtual Memory: (Total: 4971660K Active: 699312K) >> Real Memory: (Total: 540776K Active: 29756K) >> Shared Virtual Memory: (Total: 41148K Active: 19468K) >> Shared Real Memory: (Total: 4964K Active: 3048K) >> Free Memory Pages: 105308K >> >> >> /usr/bin/top line: Mem: 4664K Active, 73M Inact, 700M Wired, 79M >> Cache, 199M Buf, 23M Free >> Sum (Without Buf): 879,5 MB >> >> So what are we looking at? Wrong sysctls/top output or maybe >> actually FreeBSD doesn't use all available RAM for some reason? >> Could it be hardware problem? Maybe I should provide some additional >> data? > Does the behaviour become more expected if you remove ZFS from the > picture? Please try this (yes really). > About an hour ago I had to hard reset this machine because it stopped responding (bu still gived ping response) after massive slowdown seen by SAMBA users. Now top shows following: Mem: 78M Active, 83M Inact, 639M Wired, 120K Cache, 199M Buf, 1139M Free. What I am afraid is that this PC slowly eats own memory and finally starved itself to death, because it happened second time in 2 weeks, and it seems that rebuilding world+kernel Mon Jan 17 22:28:53 CET 2011 could be the cause. For some strange reason I believe that Jeremy Chadwick could be right pointing ZFS. Way this machine stops responding without any info in logs makes me believe that it has simply lost ability to I/O to HDD (system is ZFS-only). -- Bartosz Stec From owner-freebsd-stable@FreeBSD.ORG Thu Jan 27 17:27:27 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8C159106564A for ; Thu, 27 Jan 2011 17:27:27 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta08.emeryville.ca.mail.comcast.net (qmta08.emeryville.ca.mail.comcast.net [76.96.30.80]) by mx1.freebsd.org (Postfix) with ESMTP id 6E5CA8FC0C for ; Thu, 27 Jan 2011 17:27:26 +0000 (UTC) Received: from omta05.emeryville.ca.mail.comcast.net ([76.96.30.43]) by qmta08.emeryville.ca.mail.comcast.net with comcast id 0hFN1g0060vp7WLA8hTSh9; Thu, 27 Jan 2011 17:27:26 +0000 Received: from koitsu.dyndns.org ([98.248.34.134]) by omta05.emeryville.ca.mail.comcast.net with comcast id 0hTQ1g00K2tehsa8RhTQJ3; Thu, 27 Jan 2011 17:27:26 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 3E4DB9B422; Thu, 27 Jan 2011 09:27:24 -0800 (PST) Date: Thu, 27 Jan 2011 09:27:24 -0800 From: Jeremy Chadwick To: Damien Fleuriot Message-ID: <20110127172724.GA36587@icarus.home.lan> References: <4D41417A.20904@my.gd> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D41417A.20904@my.gd> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-stable@freebsd.org, "Vogel, Jack" , freebsd-pf@freebsd.org Subject: Re: High interrupt rate on a PF box + performance X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 17:27:27 -0000 On Thu, Jan 27, 2011 at 10:57:14AM +0100, Damien Fleuriot wrote: > Hello list, > > I have a problem with interrupts, network cards, and PF performance. > > We have 2 firewalls running FreeBSD 8.0 for the current master and > FreeBSD 8.1 for the backup host, which I upgraded just yesterday. > > [...] > > vmstat -i > --- > interrupt total rate > irq14: ata0 36 0 > irq16: mfi0 353244 1 > irq21: uhci0 uhci+ 461504 1 > cpu0: timer 615183815 1996 > irq256: bce0 1015412475 3295 > irq257: igb0 1067318584 3464 > irq258: igb0 695648752 2258 > irq259: igb0 2 0 > irq260: igb1 11503857 37 > irq261: igb1 506598 1 > irq262: igb1 69 0 > irq269: bce1 790820 2 > cpu1: timer 615183757 1996 > cpu2: timer 615197165 1996 > cpu3: timer 615197165 1996 > Total 5252757843 17050 There are changes to the igb(4) driver which are in RELENG_8 (8-STABLE), and some which will be in the upcoming 8.2-RELEASE, which may address this. Jack Vogel of Intel would be able to confirm for sure; CC'ing him here. Could you please provide output from the following commands? * pciconf -lvcb (only include igbX entries, thanks) * sysctl -a | grep msi Thanks. I can't help with the CARP-related issues or other stuff you're experiencing. These issues may all be separate problems, hard to say. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Thu Jan 27 17:31:57 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 52A1C1065670; Thu, 27 Jan 2011 17:31:57 +0000 (UTC) (envelope-from ml@my.gd) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id BCBEE8FC17; Thu, 27 Jan 2011 17:31:56 +0000 (UTC) Received: by fxm16 with SMTP id 16so2505281fxm.13 for ; Thu, 27 Jan 2011 09:31:55 -0800 (PST) Received: by 10.223.73.206 with SMTP id r14mr1169451faj.126.1296149492773; Thu, 27 Jan 2011 09:31:32 -0800 (PST) Received: from dfleuriot.local ([83.167.62.196]) by mx.google.com with ESMTPS id r24sm6084315fax.27.2011.01.27.09.31.30 (version=SSLv3 cipher=RC4-MD5); Thu, 27 Jan 2011 09:31:31 -0800 (PST) Message-ID: <4D41ABF1.1010405@my.gd> Date: Thu, 27 Jan 2011 18:31:29 +0100 From: Damien Fleuriot User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Jeremy Chadwick References: <4D41417A.20904@my.gd> <20110127172724.GA36587@icarus.home.lan> In-Reply-To: <20110127172724.GA36587@icarus.home.lan> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org, "Vogel, Jack" , freebsd-pf@freebsd.org Subject: Re: High interrupt rate on a PF box + performance X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 17:31:57 -0000 On 1/27/11 6:27 PM, Jeremy Chadwick wrote: > On Thu, Jan 27, 2011 at 10:57:14AM +0100, Damien Fleuriot wrote: >> Hello list, >> >> I have a problem with interrupts, network cards, and PF performance. >> >> We have 2 firewalls running FreeBSD 8.0 for the current master and >> FreeBSD 8.1 for the backup host, which I upgraded just yesterday. >> >> [...] >> >> vmstat -i >> --- >> interrupt total rate >> irq14: ata0 36 0 >> irq16: mfi0 353244 1 >> irq21: uhci0 uhci+ 461504 1 >> cpu0: timer 615183815 1996 >> irq256: bce0 1015412475 3295 >> irq257: igb0 1067318584 3464 >> irq258: igb0 695648752 2258 >> irq259: igb0 2 0 >> irq260: igb1 11503857 37 >> irq261: igb1 506598 1 >> irq262: igb1 69 0 >> irq269: bce1 790820 2 >> cpu1: timer 615183757 1996 >> cpu2: timer 615197165 1996 >> cpu3: timer 615197165 1996 >> Total 5252757843 17050 > > There are changes to the igb(4) driver which are in RELENG_8 (8-STABLE), > and some which will be in the upcoming 8.2-RELEASE, which may address > this. Jack Vogel of Intel would be able to confirm for sure; CC'ing him > here. > > Could you please provide output from the following commands? > > * pciconf -lvcb (only include igbX entries, thanks) > * sysctl -a | grep msi > > Thanks. > > I can't help with the CARP-related issues or other stuff you're > experiencing. These issues may all be separate problems, hard to say. > igb0@pci0:14:0:0: class=0x020000 card=0x145a8086 chip=0x10d68086 rev=0x02 hdr=0x00 igb1@pci0:14:0:1: class=0x020000 card=0x145a8086 chip=0x10d68086 rev=0x02 hdr=0x00 igb2@pci0:15:0:0: class=0x020000 card=0x145a8086 chip=0x10d68086 rev=0x02 hdr=0x00 igb3@pci0:15:0:1: class=0x020000 card=0x145a8086 chip=0x10d68086 rev=0x02 hdr=0x00 hw.bce.msi_enable: 1 hw.pci.honor_msi_blacklist: 1 hw.pci.enable_msix: 1 hw.pci.enable_msi: 1 igb0: flags=8943 metric 0 mtu 1500 options=13b ether 00:1b:21:12:ec:38 inet [snip] netmask 0xffffffc0 broadcast [snip] media: Ethernet autoselect (1000baseT ) status: active igb1: flags=8843 metric 0 mtu 1500 options=13b ether 00:1b:21:12:ec:39 inet 10.0.0.252 netmask 0xffffff00 broadcast 10.0.0.255 media: Ethernet autoselect (1000baseT ) status: active Here you go :) Note that the igb2 and 3 interfaces are unused, unplugged, unconfigured From owner-freebsd-stable@FreeBSD.ORG Thu Jan 27 17:37:50 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6873C1065679 for ; Thu, 27 Jan 2011 17:37:50 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [76.96.62.64]) by mx1.freebsd.org (Postfix) with ESMTP id 142918FC08 for ; Thu, 27 Jan 2011 17:37:49 +0000 (UTC) Received: from omta03.westchester.pa.mail.comcast.net ([76.96.62.27]) by qmta07.westchester.pa.mail.comcast.net with comcast id 0hbD1g0080bG4ec57hdqlh; Thu, 27 Jan 2011 17:37:50 +0000 Received: from koitsu.dyndns.org ([98.248.34.134]) by omta03.westchester.pa.mail.comcast.net with comcast id 0hdS1g01s2tehsa3PhdVHT; Thu, 27 Jan 2011 17:37:45 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 28F6C9B422; Thu, 27 Jan 2011 09:37:23 -0800 (PST) Date: Thu, 27 Jan 2011 09:37:23 -0800 From: Jeremy Chadwick To: Damien Fleuriot Message-ID: <20110127173723.GA36846@icarus.home.lan> References: <4D41417A.20904@my.gd> <20110127172724.GA36587@icarus.home.lan> <4D41ABF1.1010405@my.gd> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D41ABF1.1010405@my.gd> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-stable@freebsd.org, "Vogel, Jack" , freebsd-pf@freebsd.org Subject: Re: High interrupt rate on a PF box + performance X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 17:37:50 -0000 On Thu, Jan 27, 2011 at 06:31:29PM +0100, Damien Fleuriot wrote: > > > On 1/27/11 6:27 PM, Jeremy Chadwick wrote: > > On Thu, Jan 27, 2011 at 10:57:14AM +0100, Damien Fleuriot wrote: > >> Hello list, > >> > >> I have a problem with interrupts, network cards, and PF performance. > >> > >> We have 2 firewalls running FreeBSD 8.0 for the current master and > >> FreeBSD 8.1 for the backup host, which I upgraded just yesterday. > >> > >> [...] > >> > >> vmstat -i > >> --- > >> interrupt total rate > >> irq14: ata0 36 0 > >> irq16: mfi0 353244 1 > >> irq21: uhci0 uhci+ 461504 1 > >> cpu0: timer 615183815 1996 > >> irq256: bce0 1015412475 3295 > >> irq257: igb0 1067318584 3464 > >> irq258: igb0 695648752 2258 > >> irq259: igb0 2 0 > >> irq260: igb1 11503857 37 > >> irq261: igb1 506598 1 > >> irq262: igb1 69 0 > >> irq269: bce1 790820 2 > >> cpu1: timer 615183757 1996 > >> cpu2: timer 615197165 1996 > >> cpu3: timer 615197165 1996 > >> Total 5252757843 17050 > > > > There are changes to the igb(4) driver which are in RELENG_8 (8-STABLE), > > and some which will be in the upcoming 8.2-RELEASE, which may address > > this. Jack Vogel of Intel would be able to confirm for sure; CC'ing him > > here. > > > > Could you please provide output from the following commands? > > > > * pciconf -lvcb (only include igbX entries, thanks) > > * sysctl -a | grep msi > > > > Thanks. > > > > I can't help with the CARP-related issues or other stuff you're > > experiencing. These issues may all be separate problems, hard to say. > > > > > igb0@pci0:14:0:0: class=0x020000 card=0x145a8086 chip=0x10d68086 > rev=0x02 hdr=0x00 > igb1@pci0:14:0:1: class=0x020000 card=0x145a8086 chip=0x10d68086 > rev=0x02 hdr=0x00 > igb2@pci0:15:0:0: class=0x020000 card=0x145a8086 chip=0x10d68086 > rev=0x02 hdr=0x00 > igb3@pci0:15:0:1: class=0x020000 card=0x145a8086 chip=0x10d68086 > rev=0x02 hdr=0x00 What you did here was "pciconf -lvcb | grep igb", or something equivalent. There is output after each of these entries which is highly relevant. Example for an emX device: em1@pci0:15:0:0: class=0x020000 card=0x109a15d9 chip=0x109a8086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = 'Intel PRO/1000 PL Network Adaptor (82573L)' class = network subclass = ethernet bar [10] = type Memory, range 32, base 0xdc300000, size 131072, enabled bar [18] = type I/O Port, range 32, base 0x3000, size 32, enabled cap 01[c8] = powerspec 2 supports D0 D3 current D0 cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message cap 10[e0] = PCI-Express 1 endpoint max data 128(256) link x1(x1) This is the sort of output we're looking for. > hw.bce.msi_enable: 1 > hw.pci.honor_msi_blacklist: 1 > hw.pci.enable_msix: 1 > hw.pci.enable_msi: 1 > > > igb0: flags=8943 metric > 0 mtu 1500 > options=13b > ether 00:1b:21:12:ec:38 > inet [snip] netmask 0xffffffc0 broadcast [snip] > media: Ethernet autoselect (1000baseT ) > status: active > > igb1: flags=8843 metric 0 mtu 1500 > options=13b > ether 00:1b:21:12:ec:39 > inet 10.0.0.252 netmask 0xffffff00 broadcast 10.0.0.255 > media: Ethernet autoselect (1000baseT ) > status: active > > > Here you go :) > > Note that the igb2 and 3 interfaces are unused, unplugged, unconfigured -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Thu Jan 27 17:39:50 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A4217106566C; Thu, 27 Jan 2011 17:39:50 +0000 (UTC) (envelope-from ml@my.gd) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 1AC4E8FC0C; Thu, 27 Jan 2011 17:39:49 +0000 (UTC) Received: by wwf26 with SMTP id 26so2264259wwf.31 for ; Thu, 27 Jan 2011 09:39:48 -0800 (PST) Received: by 10.227.182.68 with SMTP id cb4mr1369901wbb.218.1296149988825; Thu, 27 Jan 2011 09:39:48 -0800 (PST) Received: from dfleuriot.local ([83.167.62.196]) by mx.google.com with ESMTPS id y29sm6835608wbd.16.2011.01.27.09.39.36 (version=SSLv3 cipher=RC4-MD5); Thu, 27 Jan 2011 09:39:38 -0800 (PST) Message-ID: <4D41ADD4.6050507@my.gd> Date: Thu, 27 Jan 2011 18:39:32 +0100 From: Damien Fleuriot User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Jeremy Chadwick References: <4D41417A.20904@my.gd> <20110127172724.GA36587@icarus.home.lan> <4D41ABF1.1010405@my.gd> <20110127173723.GA36846@icarus.home.lan> In-Reply-To: <20110127173723.GA36846@icarus.home.lan> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org, "Vogel, Jack" , freebsd-pf@freebsd.org Subject: Re: High interrupt rate on a PF box + performance X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 17:39:50 -0000 On 1/27/11 6:37 PM, Jeremy Chadwick wrote: > On Thu, Jan 27, 2011 at 06:31:29PM +0100, Damien Fleuriot wrote: >> >> >> On 1/27/11 6:27 PM, Jeremy Chadwick wrote: >>> On Thu, Jan 27, 2011 at 10:57:14AM +0100, Damien Fleuriot wrote: >>>> Hello list, >>>> >>>> I have a problem with interrupts, network cards, and PF performance. >>>> >>>> We have 2 firewalls running FreeBSD 8.0 for the current master and >>>> FreeBSD 8.1 for the backup host, which I upgraded just yesterday. >>>> >>>> [...] >>>> >>>> vmstat -i >>>> --- >>>> interrupt total rate >>>> irq14: ata0 36 0 >>>> irq16: mfi0 353244 1 >>>> irq21: uhci0 uhci+ 461504 1 >>>> cpu0: timer 615183815 1996 >>>> irq256: bce0 1015412475 3295 >>>> irq257: igb0 1067318584 3464 >>>> irq258: igb0 695648752 2258 >>>> irq259: igb0 2 0 >>>> irq260: igb1 11503857 37 >>>> irq261: igb1 506598 1 >>>> irq262: igb1 69 0 >>>> irq269: bce1 790820 2 >>>> cpu1: timer 615183757 1996 >>>> cpu2: timer 615197165 1996 >>>> cpu3: timer 615197165 1996 >>>> Total 5252757843 17050 >>> >>> There are changes to the igb(4) driver which are in RELENG_8 (8-STABLE), >>> and some which will be in the upcoming 8.2-RELEASE, which may address >>> this. Jack Vogel of Intel would be able to confirm for sure; CC'ing him >>> here. >>> >>> Could you please provide output from the following commands? >>> >>> * pciconf -lvcb (only include igbX entries, thanks) >>> * sysctl -a | grep msi >>> >>> Thanks. >>> >>> I can't help with the CARP-related issues or other stuff you're >>> experiencing. These issues may all be separate problems, hard to say. >>> >> > > What you did here was "pciconf -lvcb | grep igb", or something > equivalent. Indeed, my bad. igb0@pci0:14:0:0: class=0x020000 card=0x145a8086 chip=0x10d68086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82575GB Gigabit Network Connection' class = network subclass = ethernet bar [10] = type Memory, range 32, base 0xfd0e0000, size 131072, enabled bar [14] = type Memory, range 32, base 0xfce00000, size 2097152, enabled bar [18] = type I/O Port, range 32, base 0xdce0, size 32, enabled bar [1c] = type Memory, range 32, base 0xfd0dc000, size 16384, enabled cap 01[40] = powerspec 2 supports D0 D3 current D0 cap 05[50] = MSI supports 1 message, 64 bit cap 11[60] = MSI-X supports 10 messages in map 0x1c enabled cap 10[a0] = PCI-Express 2 endpoint max data 256(256) link x4(x4) igb1@pci0:14:0:1: class=0x020000 card=0x145a8086 chip=0x10d68086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82575GB Gigabit Network Connection' class = network subclass = ethernet bar [10] = type Memory, range 32, base 0xfd0a0000, size 131072, enabled bar [14] = type Memory, range 32, base 0xfcc00000, size 2097152, enabled bar [18] = type I/O Port, range 32, base 0xdcc0, size 32, enabled bar [1c] = type Memory, range 32, base 0xfd0d8000, size 16384, enabled cap 01[40] = powerspec 2 supports D0 D3 current D0 cap 05[50] = MSI supports 1 message, 64 bit cap 11[60] = MSI-X supports 10 messages in map 0x1c enabled cap 10[a0] = PCI-Express 2 endpoint max data 256(256) link x4(x4) From owner-freebsd-stable@FreeBSD.ORG Thu Jan 27 17:41:52 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 111FD10656A4 for ; Thu, 27 Jan 2011 17:41:52 +0000 (UTC) (envelope-from jack.vogel@intel.com) Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by mx1.freebsd.org (Postfix) with ESMTP id DEABB8FC25 for ; Thu, 27 Jan 2011 17:41:51 +0000 (UTC) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga102.fm.intel.com with ESMTP; 27 Jan 2011 09:41:51 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.60,386,1291622400"; d="scan'208";a="881583920" Received: from orsmsx603.amr.corp.intel.com ([10.22.226.49]) by fmsmga001.fm.intel.com with ESMTP; 27 Jan 2011 09:41:49 -0800 Received: from orsmsx601.amr.corp.intel.com (10.22.226.213) by orsmsx603.amr.corp.intel.com (10.22.226.49) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 27 Jan 2011 09:41:49 -0800 Received: from orsmsx508.amr.corp.intel.com ([10.22.226.46]) by orsmsx601.amr.corp.intel.com ([10.22.226.213]) with mapi; Thu, 27 Jan 2011 09:41:49 -0800 From: "Vogel, Jack" To: Damien Fleuriot , Jeremy Chadwick Date: Thu, 27 Jan 2011 09:41:48 -0800 Thread-Topic: High interrupt rate on a PF box + performance Thread-Index: Acu+SBzCXp13vjqUT1K7RqlhPscCTAAAJ4FA Message-ID: <1DB50624F8348F48840F2E2CF6040A9D014BEB8833@orsmsx508.amr.corp.intel.com> References: <4D41417A.20904@my.gd> <20110127172724.GA36587@icarus.home.lan> <4D41ABF1.1010405@my.gd> In-Reply-To: <4D41ABF1.1010405@my.gd> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "freebsd-stable@freebsd.org" , "freebsd-pf@freebsd.org" Subject: RE: High interrupt rate on a PF box + performance X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 17:41:52 -0000 Jeremy is right, if you have a problem the first step is to try the latest = code. However, when I look at the interrupts below I don't see what the problem i= s? The Broadcom seems to have about the same rate, it just doesn't have MSIX (= multiple vectors). Jack -----Original Message----- From: Damien Fleuriot [mailto:ml@my.gd]=20 Sent: Thursday, January 27, 2011 9:31 AM To: Jeremy Chadwick Cc: freebsd-stable@freebsd.org; freebsd-pf@freebsd.org; Vogel, Jack Subject: Re: High interrupt rate on a PF box + performance On 1/27/11 6:27 PM, Jeremy Chadwick wrote: > On Thu, Jan 27, 2011 at 10:57:14AM +0100, Damien Fleuriot wrote: >> Hello list, >> >> I have a problem with interrupts, network cards, and PF performance. >> >> We have 2 firewalls running FreeBSD 8.0 for the current master and >> FreeBSD 8.1 for the backup host, which I upgraded just yesterday. >> >> [...] >> >> vmstat -i >> --- >> interrupt total rate >> irq14: ata0 36 0 >> irq16: mfi0 353244 1 >> irq21: uhci0 uhci+ 461504 1 >> cpu0: timer 615183815 1996 >> irq256: bce0 1015412475 3295 >> irq257: igb0 1067318584 3464 >> irq258: igb0 695648752 2258 >> irq259: igb0 2 0 >> irq260: igb1 11503857 37 >> irq261: igb1 506598 1 >> irq262: igb1 69 0 >> irq269: bce1 790820 2 >> cpu1: timer 615183757 1996 >> cpu2: timer 615197165 1996 >> cpu3: timer 615197165 1996 >> Total 5252757843 17050 >=20 > There are changes to the igb(4) driver which are in RELENG_8 (8-STABLE), > and some which will be in the upcoming 8.2-RELEASE, which may address > this. Jack Vogel of Intel would be able to confirm for sure; CC'ing him > here. >=20 > Could you please provide output from the following commands? >=20 > * pciconf -lvcb (only include igbX entries, thanks) > * sysctl -a | grep msi >=20 > Thanks. >=20 > I can't help with the CARP-related issues or other stuff you're > experiencing. These issues may all be separate problems, hard to say. >=20 igb0@pci0:14:0:0: class=3D0x020000 card=3D0x145a8086 chip=3D0x10d68086 rev=3D0x02 hdr=3D0x00 igb1@pci0:14:0:1: class=3D0x020000 card=3D0x145a8086 chip=3D0x10d68086 rev=3D0x02 hdr=3D0x00 igb2@pci0:15:0:0: class=3D0x020000 card=3D0x145a8086 chip=3D0x10d68086 rev=3D0x02 hdr=3D0x00 igb3@pci0:15:0:1: class=3D0x020000 card=3D0x145a8086 chip=3D0x10d68086 rev=3D0x02 hdr=3D0x00 hw.bce.msi_enable: 1 hw.pci.honor_msi_blacklist: 1 hw.pci.enable_msix: 1 hw.pci.enable_msi: 1 igb0: flags=3D8943 metric 0 mtu 1500 options=3D13b ether 00:1b:21:12:ec:38 inet [snip] netmask 0xffffffc0 broadcast [snip] media: Ethernet autoselect (1000baseT ) status: active igb1: flags=3D8843 metric 0 mtu 150= 0 options=3D13b ether 00:1b:21:12:ec:39 inet 10.0.0.252 netmask 0xffffff00 broadcast 10.0.0.255 media: Ethernet autoselect (1000baseT ) status: active Here you go :) Note that the igb2 and 3 interfaces are unused, unplugged, unconfigured From owner-freebsd-stable@FreeBSD.ORG Thu Jan 27 17:55:53 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DE795106566B; Thu, 27 Jan 2011 17:55:53 +0000 (UTC) (envelope-from ml@my.gd) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 52D388FC18; Thu, 27 Jan 2011 17:55:52 +0000 (UTC) Received: by wwf26 with SMTP id 26so2279257wwf.31 for ; Thu, 27 Jan 2011 09:55:52 -0800 (PST) Received: by 10.227.128.21 with SMTP id i21mr1404334wbs.219.1296150952014; Thu, 27 Jan 2011 09:55:52 -0800 (PST) Received: from dfleuriot.local ([83.167.62.196]) by mx.google.com with ESMTPS id f35sm11983913wbf.14.2011.01.27.09.55.39 (version=SSLv3 cipher=RC4-MD5); Thu, 27 Jan 2011 09:55:41 -0800 (PST) Message-ID: <4D41B197.6070308@my.gd> Date: Thu, 27 Jan 2011 18:55:35 +0100 From: Damien Fleuriot User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "Vogel, Jack" References: <4D41417A.20904@my.gd> <20110127172724.GA36587@icarus.home.lan> <4D41ABF1.1010405@my.gd> <1DB50624F8348F48840F2E2CF6040A9D014BEB8833@orsmsx508.amr.corp.intel.com> In-Reply-To: <1DB50624F8348F48840F2E2CF6040A9D014BEB8833@orsmsx508.amr.corp.intel.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "freebsd-stable@freebsd.org" , Jeremy Chadwick , "freebsd-pf@freebsd.org" Subject: Re: High interrupt rate on a PF box + performance X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 17:55:54 -0000 On 1/27/11 6:41 PM, Vogel, Jack wrote: > Jeremy is right, if you have a problem the first step is to try the latest code. > > However, when I look at the interrupts below I don't see what the problem is? > The Broadcom seems to have about the same rate, it just doesn't have MSIX (multiple vectors). > > Jack > > My main concern is that the CPU %interrupt is quite high, also, we seem to be experiencing input errors on the interfaces. See for yourself the following munin graphs: http://my.gd/fw_graphs/ igb0 = WAN interf bce0 = LAN Obviously we've had quite a traffic increase since the beginning of the year, as shown by the PF statistics. But jeez, the CPU %interrupt doubled or tripled... You'll notice a drop in graphs between 23 and 25 january, this is when we switched the CARP master to the backup firewall. From owner-freebsd-stable@FreeBSD.ORG Thu Jan 27 19:39:49 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C87F3106564A; Thu, 27 Jan 2011 19:39:49 +0000 (UTC) (envelope-from ml@my.gd) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 4139D8FC0A; Thu, 27 Jan 2011 19:39:46 +0000 (UTC) Received: by wwf26 with SMTP id 26so2388332wwf.31 for ; Thu, 27 Jan 2011 11:39:46 -0800 (PST) Received: by 10.227.11.143 with SMTP id t15mr1612016wbt.27.1296157186115; Thu, 27 Jan 2011 11:39:46 -0800 (PST) Received: from dfleuriot.local ([83.167.62.196]) by mx.google.com with ESMTPS id u9sm1966078wbg.0.2011.01.27.11.39.42 (version=SSLv3 cipher=RC4-MD5); Thu, 27 Jan 2011 11:39:43 -0800 (PST) Message-ID: <4D41C9FC.10503@my.gd> Date: Thu, 27 Jan 2011 20:39:40 +0100 From: Damien Fleuriot User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Sergey Lobanov References: <4D41417A.20904@my.gd> <1DB50624F8348F48840F2E2CF6040A9D014BEB8833@orsmsx508.amr.corp.intel.com> <4D41B197.6070308@my.gd> <201101280146.57028.wmn@siberianet.ru> In-Reply-To: <201101280146.57028.wmn@siberianet.ru> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: "freebsd-stable@freebsd.org" , "freebsd-pf@freebsd.org" Subject: Re: High interrupt rate on a PF box + performance X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 19:39:49 -0000 On 1/27/11 7:46 PM, Sergey Lobanov wrote: > В сообщении от Пятница 28 января 2011 00:55:35 автор Damien Fleuriot написал: >> On 1/27/11 6:41 PM, Vogel, Jack wrote: >>> Jeremy is right, if you have a problem the first step is to try the >>> latest code. >>> >>> However, when I look at the interrupts below I don't see what the problem >>> is? The Broadcom seems to have about the same rate, it just doesn't have >>> MSIX (multiple vectors). >>> >>> Jack >> >> My main concern is that the CPU %interrupt is quite high, also, we seem >> to be experiencing input errors on the interfaces. > Would you show igb tuning which is done in loader.conf and output of sysctl > dev.igb.0? > Did you rise number of igb descriptors such as: > hw.igb.rxd=4096 > hw.igb.txd=4096 ? There is no tuning at all on our part in the loader's conf. Find below the sysctls: # sysctl -a |grep igb dev.igb.0.%desc: Intel(R) PRO/1000 Network Connection version - 1.7.3 dev.igb.0.%driver: igb dev.igb.0.%location: slot=0 function=0 dev.igb.0.%pnpinfo: vendor=0x8086 device=0x10d6 subvendor=0x8086 subdevice=0x145a class=0x020000 dev.igb.0.%parent: pci14 dev.igb.0.debug: -1 dev.igb.0.stats: -1 dev.igb.0.flow_control: 3 dev.igb.0.enable_aim: 1 dev.igb.0.low_latency: 128 dev.igb.0.ave_latency: 450 dev.igb.0.bulk_latency: 1200 dev.igb.0.rx_processing_limit: 100 dev.igb.1.%desc: Intel(R) PRO/1000 Network Connection version - 1.7.3 dev.igb.1.%driver: igb dev.igb.1.%location: slot=0 function=1 dev.igb.1.%pnpinfo: vendor=0x8086 device=0x10d6 subvendor=0x8086 subdevice=0x145a class=0x020000 dev.igb.1.%parent: pci14 dev.igb.1.debug: -1 dev.igb.1.stats: -1 dev.igb.1.flow_control: 3 dev.igb.1.enable_aim: 1 dev.igb.1.low_latency: 128 dev.igb.1.ave_latency: 450 dev.igb.1.bulk_latency: 1200 dev.igb.1.rx_processing_limit: 100 From owner-freebsd-stable@FreeBSD.ORG Thu Jan 27 19:57:44 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9AB701065672 for ; Thu, 27 Jan 2011 19:57:44 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta10.emeryville.ca.mail.comcast.net (qmta10.emeryville.ca.mail.comcast.net [76.96.30.17]) by mx1.freebsd.org (Postfix) with ESMTP id 78FB48FC23 for ; Thu, 27 Jan 2011 19:57:44 +0000 (UTC) Received: from omta04.emeryville.ca.mail.comcast.net ([76.96.30.35]) by qmta10.emeryville.ca.mail.comcast.net with comcast id 0jvo1g0020lTkoCAAjxjCa; Thu, 27 Jan 2011 19:57:43 +0000 Received: from koitsu.dyndns.org ([98.248.34.134]) by omta04.emeryville.ca.mail.comcast.net with comcast id 0jxi1g0062tehsa8Qjxi5v; Thu, 27 Jan 2011 19:57:43 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id CD2A09B422; Thu, 27 Jan 2011 11:57:41 -0800 (PST) Date: Thu, 27 Jan 2011 11:57:41 -0800 From: Jeremy Chadwick To: Damien Fleuriot Message-ID: <20110127195741.GA40449@icarus.home.lan> References: <4D41417A.20904@my.gd> <1DB50624F8348F48840F2E2CF6040A9D014BEB8833@orsmsx508.amr.corp.intel.com> <4D41B197.6070308@my.gd> <201101280146.57028.wmn@siberianet.ru> <4D41C9FC.10503@my.gd> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4D41C9FC.10503@my.gd> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Sergey Lobanov , "freebsd-stable@freebsd.org" , "freebsd-pf@freebsd.org" Subject: Re: High interrupt rate on a PF box + performance X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 19:57:44 -0000 On Thu, Jan 27, 2011 at 08:39:40PM +0100, Damien Fleuriot wrote: > > > On 1/27/11 7:46 PM, Sergey Lobanov wrote: > > В сообщении от Пятница 28 января 2011 00:55:35 автор Damien Fleuriot написал: > >> On 1/27/11 6:41 PM, Vogel, Jack wrote: > >>> Jeremy is right, if you have a problem the first step is to try the > >>> latest code. > >>> > >>> However, when I look at the interrupts below I don't see what the problem > >>> is? The Broadcom seems to have about the same rate, it just doesn't have > >>> MSIX (multiple vectors). > >>> > >>> Jack > >> > >> My main concern is that the CPU %interrupt is quite high, also, we seem > >> to be experiencing input errors on the interfaces. > > Would you show igb tuning which is done in loader.conf and output of sysctl > > dev.igb.0? > > Did you rise number of igb descriptors such as: > > hw.igb.rxd=4096 > > hw.igb.txd=4096 ? > > There is no tuning at all on our part in the loader's conf. > > Find below the sysctls: > > # sysctl -a |grep igb > dev.igb.0.%desc: Intel(R) PRO/1000 Network Connection version - 1.7.3 > dev.igb.0.%driver: igb > dev.igb.0.%location: slot=0 function=0 > dev.igb.0.%pnpinfo: vendor=0x8086 device=0x10d6 subvendor=0x8086 > subdevice=0x145a class=0x020000 > dev.igb.0.%parent: pci14 > dev.igb.0.debug: -1 > dev.igb.0.stats: -1 > dev.igb.0.flow_control: 3 > dev.igb.0.enable_aim: 1 > dev.igb.0.low_latency: 128 > dev.igb.0.ave_latency: 450 > dev.igb.0.bulk_latency: 1200 > dev.igb.0.rx_processing_limit: 100 > dev.igb.1.%desc: Intel(R) PRO/1000 Network Connection version - 1.7.3 > dev.igb.1.%driver: igb > dev.igb.1.%location: slot=0 function=1 > dev.igb.1.%pnpinfo: vendor=0x8086 device=0x10d6 subvendor=0x8086 > subdevice=0x145a class=0x020000 > dev.igb.1.%parent: pci14 > dev.igb.1.debug: -1 > dev.igb.1.stats: -1 > dev.igb.1.flow_control: 3 > dev.igb.1.enable_aim: 1 > dev.igb.1.low_latency: 128 > dev.igb.1.ave_latency: 450 > dev.igb.1.bulk_latency: 1200 > dev.igb.1.rx_processing_limit: 100 I'm not aware of how to tune igb(4), so the advice Sergey gave you may be applicable. You'll need to schedule downtime to adjust those tunables however (since a reboot will be requried). I also reviewed the munin graphs. I don't see anything necessarily wrong. However, you omitted yearly graphs for the network interfaces. Why I care about that: The pf state table (yearly) graph basically correlates with the CPU usage (yearly) graph, and I expect that the yearly network graphs would show a similar trend: an increase in your overall traffic over the course of a year. What I'm trying to figure out is what you're concerned about. You are in fact pushing anywhere between 60-120MBytes/sec across these interfaces. Given those numbers, I'm not surprised by the ""high"" interrupt usage. Graphs of this nature usually indicate that you're hitting a "bottleneck" (for lack of better word) where you're simply doing "too much" with a single machine (given its network throughput). The machine is spending a tremendous amount of CPU time handling network traffic, and equally as much with regards to the pf usage. If you want my opinion based on the information I have so far, it's this: you need to scale your infrastructure. You can no longer rely on a single machine to handle this amount of traffic. As for the network errors you see -- to get low-level NIC and driver statistics, you'll need to run "sysctl dev.igb.X.stats=1" then run "dmesg" and look at the numbers shown (the sysctl command won't output anything itself). This may help indicate where the packets are being lost. You should also check the interface counters on the switch which these interfaces are connected to. I sure hope it's a managed switch which can give you those statistics. Hope this helps, or at least acts as food for thought. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Thu Jan 27 20:03:03 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 46284106566C for ; Thu, 27 Jan 2011 20:03:03 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-gw0-f54.google.com (mail-gw0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id EDF918FC19 for ; Thu, 27 Jan 2011 20:03:02 +0000 (UTC) Received: by gwj21 with SMTP id 21so824713gwj.13 for ; Thu, 27 Jan 2011 12:03:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=pGeSt05Fm5mPVvgFYr5VNoHugJlyM+K8wOkLiefnLCs=; b=HH5wfaqQYg8qNgTignRT/wE5LAACJ+O4OZ4hjec+J1kZaqyXp7XELyoo+ENCM5VSXR WZWCvIWVs//dTlNMeEowVK6CyB69yYiBes0DQsoXGmSBsT7SOQOlPrykAOW9wNjFaoYB lFLWMcHTghEhxKHWIX85iOhqKxP2WN3dkBdTg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=xAEfzd//q+dPNZLx3hqnxWEivdJCV1jtbRfG+f7cXxOFZN66srwbFnDO9qxPoE5nXx sGvGETFUEeQejyDOCmtQc2wAPh7FWVJz/U2l1y7RudDlTa10KKSCn+mS2AF4QUJw9Wx8 PozhWhRbw6VUawzRp77O44SChLnvV1aArsYNQ= MIME-Version: 1.0 Received: by 10.236.108.177 with SMTP id q37mr3091801yhg.11.1296158538636; Thu, 27 Jan 2011 12:02:18 -0800 (PST) Received: by 10.147.171.17 with HTTP; Thu, 27 Jan 2011 12:02:18 -0800 (PST) In-Reply-To: <20110127195741.GA40449@icarus.home.lan> References: <4D41417A.20904@my.gd> <1DB50624F8348F48840F2E2CF6040A9D014BEB8833@orsmsx508.amr.corp.intel.com> <4D41B197.6070308@my.gd> <201101280146.57028.wmn@siberianet.ru> <4D41C9FC.10503@my.gd> <20110127195741.GA40449@icarus.home.lan> Date: Thu, 27 Jan 2011 12:02:18 -0800 Message-ID: From: Jack Vogel To: Jeremy Chadwick Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Sergey Lobanov , "freebsd-stable@freebsd.org" , "freebsd-pf@freebsd.org" Subject: Re: High interrupt rate on a PF box + performance X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 20:03:03 -0000 If you go to 8.2 and the latest driver you will get better stats also, ahem... Jack On Thu, Jan 27, 2011 at 11:57 AM, Jeremy Chadwick wrote: > On Thu, Jan 27, 2011 at 08:39:40PM +0100, Damien Fleuriot wrote: > > > > > > On 1/27/11 7:46 PM, Sergey Lobanov wrote: > > > =F7 =D3=CF=CF=C2=DD=C5=CE=C9=C9 =CF=D4 =F0=D1=D4=CE=C9=C3=C1 28 =D1= =CE=D7=C1=D2=D1 2011 00:55:35 =C1=D7=D4=CF=D2 Damien Fleuriot > =CE=C1=D0=C9=D3=C1=CC: > > >> On 1/27/11 6:41 PM, Vogel, Jack wrote: > > >>> Jeremy is right, if you have a problem the first step is to try the > > >>> latest code. > > >>> > > >>> However, when I look at the interrupts below I don't see what the > problem > > >>> is? The Broadcom seems to have about the same rate, it just doesn't > have > > >>> MSIX (multiple vectors). > > >>> > > >>> Jack > > >> > > >> My main concern is that the CPU %interrupt is quite high, also, we > seem > > >> to be experiencing input errors on the interfaces. > > > Would you show igb tuning which is done in loader.conf and output of > sysctl > > > dev.igb.0? > > > Did you rise number of igb descriptors such as: > > > hw.igb.rxd=3D4096 > > > hw.igb.txd=3D4096 ? > > > > There is no tuning at all on our part in the loader's conf. > > > > Find below the sysctls: > > > > # sysctl -a |grep igb > > dev.igb.0.%desc: Intel(R) PRO/1000 Network Connection version - 1.7.3 > > dev.igb.0.%driver: igb > > dev.igb.0.%location: slot=3D0 function=3D0 > > dev.igb.0.%pnpinfo: vendor=3D0x8086 device=3D0x10d6 subvendor=3D0x8086 > > subdevice=3D0x145a class=3D0x020000 > > dev.igb.0.%parent: pci14 > > dev.igb.0.debug: -1 > > dev.igb.0.stats: -1 > > dev.igb.0.flow_control: 3 > > dev.igb.0.enable_aim: 1 > > dev.igb.0.low_latency: 128 > > dev.igb.0.ave_latency: 450 > > dev.igb.0.bulk_latency: 1200 > > dev.igb.0.rx_processing_limit: 100 > > dev.igb.1.%desc: Intel(R) PRO/1000 Network Connection version - 1.7.3 > > dev.igb.1.%driver: igb > > dev.igb.1.%location: slot=3D0 function=3D1 > > dev.igb.1.%pnpinfo: vendor=3D0x8086 device=3D0x10d6 subvendor=3D0x8086 > > subdevice=3D0x145a class=3D0x020000 > > dev.igb.1.%parent: pci14 > > dev.igb.1.debug: -1 > > dev.igb.1.stats: -1 > > dev.igb.1.flow_control: 3 > > dev.igb.1.enable_aim: 1 > > dev.igb.1.low_latency: 128 > > dev.igb.1.ave_latency: 450 > > dev.igb.1.bulk_latency: 1200 > > dev.igb.1.rx_processing_limit: 100 > > I'm not aware of how to tune igb(4), so the advice Sergey gave you may > be applicable. You'll need to schedule downtime to adjust those > tunables however (since a reboot will be requried). > > I also reviewed the munin graphs. I don't see anything necessarily > wrong. However, you omitted yearly graphs for the network interfaces. > Why I care about that: > > The pf state table (yearly) graph basically correlates with the CPU > usage (yearly) graph, and I expect that the yearly network graphs would > show a similar trend: an increase in your overall traffic over the > course of a year. > > What I'm trying to figure out is what you're concerned about. You are > in fact pushing anywhere between 60-120MBytes/sec across these > interfaces. Given those numbers, I'm not surprised by the ""high"" > interrupt usage. > > Graphs of this nature usually indicate that you're hitting a > "bottleneck" (for lack of better word) where you're simply doing "too > much" with a single machine (given its network throughput). The machine > is spending a tremendous amount of CPU time handling network traffic, > and equally as much with regards to the pf usage. > > If you want my opinion based on the information I have so far, it's > this: you need to scale your infrastructure. You can no longer rely on > a single machine to handle this amount of traffic. > > As for the network errors you see -- to get low-level NIC and driver > statistics, you'll need to run "sysctl dev.igb.X.stats=3D1" then run > "dmesg" and look at the numbers shown (the sysctl command won't output > anything itself). This may help indicate where the packets are being > lost. You should also check the interface counters on the switch which > these interfaces are connected to. I sure hope it's a managed switch > which can give you those statistics. > > Hope this helps, or at least acts as food for thought. > > -- > | Jeremy Chadwick jdc@parodius.com | > | Parodius Networking http://www.parodius.com/ | > | UNIX Systems Administrator Mountain View, CA, USA | > | Making life hard for others since 1977. PGP 4BD6C0CB | > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From owner-freebsd-stable@FreeBSD.ORG Thu Jan 27 20:38:25 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B3B751065670; Thu, 27 Jan 2011 20:38:25 +0000 (UTC) (envelope-from ml@my.gd) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 24BF08FC0C; Thu, 27 Jan 2011 20:38:24 +0000 (UTC) Received: by wwf26 with SMTP id 26so2444071wwf.31 for ; Thu, 27 Jan 2011 12:38:24 -0800 (PST) Received: by 10.227.144.12 with SMTP id x12mr1662478wbu.102.1296160703918; Thu, 27 Jan 2011 12:38:23 -0800 (PST) Received: from dfleuriot.local ([83.167.62.196]) by mx.google.com with ESMTPS id o6sm441232wbo.15.2011.01.27.12.38.22 (version=SSLv3 cipher=RC4-MD5); Thu, 27 Jan 2011 12:38:23 -0800 (PST) Message-ID: <4D41D7BE.3030208@my.gd> Date: Thu, 27 Jan 2011 21:38:22 +0100 From: Damien Fleuriot User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Jeremy Chadwick References: <4D41417A.20904@my.gd> <1DB50624F8348F48840F2E2CF6040A9D014BEB8833@orsmsx508.amr.corp.intel.com> <4D41B197.6070308@my.gd> <201101280146.57028.wmn@siberianet.ru> <4D41C9FC.10503@my.gd> <20110127195741.GA40449@icarus.home.lan> In-Reply-To: <20110127195741.GA40449@icarus.home.lan> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: Sergey Lobanov , "freebsd-stable@freebsd.org" , "freebsd-pf@freebsd.org" Subject: Re: High interrupt rate on a PF box + performance X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 20:38:25 -0000 On 1/27/11 8:57 PM, Jeremy Chadwick wrote: > On Thu, Jan 27, 2011 at 08:39:40PM +0100, Damien Fleuriot wrote: >> >> >> On 1/27/11 7:46 PM, Sergey Lobanov wrote: >>> В сообщении от Пятница 28 января 2011 00:55:35 автор Damien Fleuriot написал: >>>> On 1/27/11 6:41 PM, Vogel, Jack wrote: >>>>> Jeremy is right, if you have a problem the first step is to try the >>>>> latest code. >>>>> >>>>> However, when I look at the interrupts below I don't see what the problem >>>>> is? The Broadcom seems to have about the same rate, it just doesn't have >>>>> MSIX (multiple vectors). >>>>> >>>>> Jack >>>> >>>> My main concern is that the CPU %interrupt is quite high, also, we seem >>>> to be experiencing input errors on the interfaces. >>> Would you show igb tuning which is done in loader.conf and output of sysctl >>> dev.igb.0? >>> Did you rise number of igb descriptors such as: >>> hw.igb.rxd=4096 >>> hw.igb.txd=4096 ? >> >> There is no tuning at all on our part in the loader's conf. >> >> Find below the sysctls: >> >> # sysctl -a |grep igb >> dev.igb.0.%desc: Intel(R) PRO/1000 Network Connection version - 1.7.3 >> dev.igb.0.%driver: igb >> dev.igb.0.%location: slot=0 function=0 >> dev.igb.0.%pnpinfo: vendor=0x8086 device=0x10d6 subvendor=0x8086 >> subdevice=0x145a class=0x020000 >> dev.igb.0.%parent: pci14 >> dev.igb.0.debug: -1 >> dev.igb.0.stats: -1 >> dev.igb.0.flow_control: 3 >> dev.igb.0.enable_aim: 1 >> dev.igb.0.low_latency: 128 >> dev.igb.0.ave_latency: 450 >> dev.igb.0.bulk_latency: 1200 >> dev.igb.0.rx_processing_limit: 100 >> dev.igb.1.%desc: Intel(R) PRO/1000 Network Connection version - 1.7.3 >> dev.igb.1.%driver: igb >> dev.igb.1.%location: slot=0 function=1 >> dev.igb.1.%pnpinfo: vendor=0x8086 device=0x10d6 subvendor=0x8086 >> subdevice=0x145a class=0x020000 >> dev.igb.1.%parent: pci14 >> dev.igb.1.debug: -1 >> dev.igb.1.stats: -1 >> dev.igb.1.flow_control: 3 >> dev.igb.1.enable_aim: 1 >> dev.igb.1.low_latency: 128 >> dev.igb.1.ave_latency: 450 >> dev.igb.1.bulk_latency: 1200 >> dev.igb.1.rx_processing_limit: 100 > > I'm not aware of how to tune igb(4), so the advice Sergey gave you may > be applicable. You'll need to schedule downtime to adjust those > tunables however (since a reboot will be requried). > > I also reviewed the munin graphs. I don't see anything necessarily > wrong. However, you omitted yearly graphs for the network interfaces. Indeed I have, the reason is because the yearly graphs are fucked up, for some reason that eludes me munin recorded a 2petabyte spike sometime during september or so. So this makes the whole graph flatlined for the year -.- However, we clearly have an increase in traffic, as we may also see from our nginx requests graphs. > Why I care about that: > > The pf state table (yearly) graph basically correlates with the CPU > usage (yearly) graph, and I expect that the yearly network graphs would > show a similar trend: an increase in your overall traffic over the > course of a year. > > What I'm trying to figure out is what you're concerned about. You are > in fact pushing anywhere between 60-120MBytes/sec across these > interfaces. Given those numbers, I'm not surprised by the ""high"" > interrupt usage. > I'm worried we may hit a bottleneck soon. I was also hoping for some kind of magical way to diminish the interrupts so we could get more performance from the machines. > Graphs of this nature usually indicate that you're hitting a > "bottleneck" (for lack of better word) where you're simply doing "too > much" with a single machine (given its network throughput). The machine > is spending a tremendous amount of CPU time handling network traffic, > and equally as much with regards to the pf usage. > We've indeed been thinking about moving to an active-active setup for some time already, guess it'll have to happen sooner rather than later :) > If you want my opinion based on the information I have so far, it's > this: you need to scale your infrastructure. You can no longer rely on > a single machine to handle this amount of traffic. > > As for the network errors you see -- to get low-level NIC and driver > statistics, you'll need to run "sysctl dev.igb.X.stats=1" then run > "dmesg" and look at the numbers shown (the sysctl command won't output > anything itself). This may help indicate where the packets are being > lost. You should also check the interface counters on the switch which > these interfaces are connected to. I sure hope it's a managed switch > which can give you those statistics. > > Hope this helps, or at least acts as food for thought. > Aye, will try that. We're also considering moving to faster machines but I don't think that will help much with our problem. I suppose additional CPU cores will be of no help at all, considering the kernel is single threaded and runs on cpu0 only ? Actually, I assume it might even be detrimental to us to add more cores, since they'll spend more time interrupting each other ? Thanks for sharing your thoughts :) From owner-freebsd-stable@FreeBSD.ORG Thu Jan 27 20:39:54 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0100010656C0; Thu, 27 Jan 2011 20:39:54 +0000 (UTC) (envelope-from ml@my.gd) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 6A87E8FC29; Thu, 27 Jan 2011 20:39:50 +0000 (UTC) Received: by wyf19 with SMTP id 19so2525180wyf.13 for ; Thu, 27 Jan 2011 12:39:50 -0800 (PST) Received: by 10.227.134.206 with SMTP id k14mr1733548wbt.5.1296160790088; Thu, 27 Jan 2011 12:39:50 -0800 (PST) Received: from dfleuriot.local ([83.167.62.196]) by mx.google.com with ESMTPS id w25sm1044533wbd.5.2011.01.27.12.39.49 (version=SSLv3 cipher=RC4-MD5); Thu, 27 Jan 2011 12:39:49 -0800 (PST) Message-ID: <4D41D814.90305@my.gd> Date: Thu, 27 Jan 2011 21:39:48 +0100 From: Damien Fleuriot User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Jack Vogel References: <4D41417A.20904@my.gd> <1DB50624F8348F48840F2E2CF6040A9D014BEB8833@orsmsx508.amr.corp.intel.com> <4D41B197.6070308@my.gd> <201101280146.57028.wmn@siberianet.ru> <4D41C9FC.10503@my.gd> <20110127195741.GA40449@icarus.home.lan> In-Reply-To: Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit Cc: Sergey Lobanov , "freebsd-stable@freebsd.org" , Jeremy Chadwick , "freebsd-pf@freebsd.org" Subject: Re: High interrupt rate on a PF box + performance X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 20:39:54 -0000 On 1/27/11 9:02 PM, Jack Vogel wrote: > If you go to 8.2 and the latest driver you will get better stats also, > ahem... > > Jack > We'll be doing that as soon as 8.2 hits release, as opposed to prerelease/rc. Can never be too careful with this one project, outtages would be costly -.- From owner-freebsd-stable@FreeBSD.ORG Thu Jan 27 20:58:47 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6D04A1065672 for ; Thu, 27 Jan 2011 20:58:47 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta09.emeryville.ca.mail.comcast.net (qmta09.emeryville.ca.mail.comcast.net [76.96.30.96]) by mx1.freebsd.org (Postfix) with ESMTP id 4B5E78FC0A for ; Thu, 27 Jan 2011 20:58:46 +0000 (UTC) Received: from omta10.emeryville.ca.mail.comcast.net ([76.96.30.28]) by qmta09.emeryville.ca.mail.comcast.net with comcast id 0kut1g0040cQ2SLA9kymcP; Thu, 27 Jan 2011 20:58:46 +0000 Received: from koitsu.dyndns.org ([98.248.34.134]) by omta10.emeryville.ca.mail.comcast.net with comcast id 0kyl1g00d2tehsa8WkylyL; Thu, 27 Jan 2011 20:58:46 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 44AB09B422; Thu, 27 Jan 2011 12:58:45 -0800 (PST) Date: Thu, 27 Jan 2011 12:58:45 -0800 From: Jeremy Chadwick To: Damien Fleuriot Message-ID: <20110127205845.GA41537@icarus.home.lan> References: <4D41417A.20904@my.gd> <1DB50624F8348F48840F2E2CF6040A9D014BEB8833@orsmsx508.amr.corp.intel.com> <4D41B197.6070308@my.gd> <201101280146.57028.wmn@siberianet.ru> <4D41C9FC.10503@my.gd> <20110127195741.GA40449@icarus.home.lan> <4D41D7BE.3030208@my.gd> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D41D7BE.3030208@my.gd> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Sergey Lobanov , "freebsd-stable@freebsd.org" , "freebsd-pf@freebsd.org" Subject: Re: High interrupt rate on a PF box + performance X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 20:58:47 -0000 On Thu, Jan 27, 2011 at 09:38:22PM +0100, Damien Fleuriot wrote: > On 1/27/11 8:57 PM, Jeremy Chadwick wrote: > <...snipping out stuff...> > We're also considering moving to faster machines but I don't think that > will help much with our problem. > > I suppose additional CPU cores will be of no help at all, considering > the kernel is single threaded and runs on cpu0 only ? Kernel folks should be able to talk about this in detail, but my understanding is that the kernel itself supports multiple threads, but the question is whether or not the drivers or relevant "pieces" (e.g. igb(4) driver, pf, TCP stack, etc.) support SMP (multi-core/threading) or not. I think this is referred to as something being "MPSAFE" or not. The things you see during boot -- [ITHREAD], [FILTER], and [GIANT-LOCKED] play a role as well, but I think those indicate what style of locking is used (since some drivers/features might not work properly in a multiprocessor environment). I'm trying to avoid correlating "multiprocessor safe" with "makes use of multiple processors". I'm an old 65xxx CPU guy, this SMP stuff is still "new technology" to me when it comes to actual operations/mechanics. Regarding TCP and SMP, this is regularly touched on in the FreeBSD Status Reports that go out (always worth reading). See "TCP SMP scalability project": http://www.freebsd.org/news/status/report-2010-10-2010-12.html I know all this information is technical of course and doesn't answer your question directly. I wish there was something more authoritative when it came to this question. > Actually, I assume it might even be detrimental to us to add more cores, > since they'll spend more time interrupting each other ? > > Thanks for sharing your thoughts :) -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Thu Jan 27 21:44:15 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F20531065670; Thu, 27 Jan 2011 21:44:15 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 9555C8FC14; Thu, 27 Jan 2011 21:44:15 +0000 (UTC) Received: by gxk8 with SMTP id 8so866560gxk.13 for ; Thu, 27 Jan 2011 13:44:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=v9F2tGocRlB8Nz3Py3RzDC7SNAJqwFYdvTlJ3U5vm8Q=; b=W+hZEEFw3vdqULowdQindVfqPVNpxLVT/3JeRCH1WxAaA3VnG6xnyq2+vJTTigqEYf vy9sqb4XP+4Yz6C6DmAlu7ye9ohNidR/6TNToIKgGkgVs/c/vieCOFxWgH4fz7S8C0Ud 1oiG/CDiYDNXrm6URcUsY+vHDn9C5gOUXILSI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=dXwWKi6/Ec7oq2H4Zmm7fwK+Ov6y9e1uuG1Osyqtr/GpvQIBB7op5WPNt18rV6BpRm b+4pHERg9pDST3Rc3NQC3QsYpnpO2v+SHFz/MWqoQngPxvCZSJ/qXBBEXH3yRkVlxIK8 wdjPdowJPRbg5roD8HLeOHljSKzQuMjovwJp0= MIME-Version: 1.0 Received: by 10.151.46.10 with SMTP id y10mr3432226ybj.22.1296164654437; Thu, 27 Jan 2011 13:44:14 -0800 (PST) Received: by 10.147.171.17 with HTTP; Thu, 27 Jan 2011 13:44:14 -0800 (PST) In-Reply-To: <20110127205845.GA41537@icarus.home.lan> References: <4D41417A.20904@my.gd> <1DB50624F8348F48840F2E2CF6040A9D014BEB8833@orsmsx508.amr.corp.intel.com> <4D41B197.6070308@my.gd> <201101280146.57028.wmn@siberianet.ru> <4D41C9FC.10503@my.gd> <20110127195741.GA40449@icarus.home.lan> <4D41D7BE.3030208@my.gd> <20110127205845.GA41537@icarus.home.lan> Date: Thu, 27 Jan 2011 13:44:14 -0800 Message-ID: From: Jack Vogel To: Jeremy Chadwick Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Sergey Lobanov , "freebsd-stable@freebsd.org" , "freebsd-pf@freebsd.org" Subject: Re: High interrupt rate on a PF box + performance X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 21:44:16 -0000 On Thu, Jan 27, 2011 at 12:58 PM, Jeremy Chadwick wrote: > > On Thu, Jan 27, 2011 at 09:38:22PM +0100, Damien Fleuriot wrote: > > On 1/27/11 8:57 PM, Jeremy Chadwick wrote: > > > > <...snipping out stuff...> > > > We're also considering moving to faster machines but I don't think that > > will help much with our problem. > > > > I suppose additional CPU cores will be of no help at all, considering > > the kernel is single threaded and runs on cpu0 only ? > > Kernel folks should be able to talk about this in detail, but my > understanding is that the kernel itself supports multiple threads, but > the question is whether or not the drivers or relevant "pieces" (e.g. > igb(4) driver, pf, TCP stack, etc.) support SMP (multi-core/threading) > or not. I think this is referred to as something being "MPSAFE" or not. > > The 8.X kernel is NOT single-threaded. Anything but. And the stack has also been improved, I believe there are still bottlenecks but its far better than the old days. The igb driver in 8.2 creates up to 8 queues on the right hardware, they are each auto-bound to a particular CPU. The older version you are running had issues and hence multiqueue was not enabled. So, do upgrade once 8.2 is finalized :) Cheers, Jack From owner-freebsd-stable@FreeBSD.ORG Fri Jan 28 10:29:58 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 48940106564A; Fri, 28 Jan 2011 10:29:58 +0000 (UTC) (envelope-from ml@my.gd) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 72DDF8FC15; Fri, 28 Jan 2011 10:29:55 +0000 (UTC) Received: by fxm16 with SMTP id 16so3295231fxm.13 for ; Fri, 28 Jan 2011 02:29:54 -0800 (PST) Received: by 10.223.70.142 with SMTP id d14mr2163596faj.110.1296210594389; Fri, 28 Jan 2011 02:29:54 -0800 (PST) Received: from dfleuriot.local ([83.167.62.196]) by mx.google.com with ESMTPS id 11sm1556061faw.44.2011.01.28.02.29.52 (version=SSLv3 cipher=RC4-MD5); Fri, 28 Jan 2011 02:29:52 -0800 (PST) Message-ID: <4D429A9F.8040307@my.gd> Date: Fri, 28 Jan 2011 11:29:51 +0100 From: Damien Fleuriot User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Jack Vogel References: <4D41417A.20904@my.gd> <1DB50624F8348F48840F2E2CF6040A9D014BEB8833@orsmsx508.amr.corp.intel.com> <4D41B197.6070308@my.gd> <201101280146.57028.wmn@siberianet.ru> <4D41C9FC.10503@my.gd> <20110127195741.GA40449@icarus.home.lan> <4D41D7BE.3030208@my.gd> <20110127205845.GA41537@icarus.home.lan> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Sergey Lobanov , "freebsd-stable@freebsd.org" , Jeremy Chadwick , "freebsd-pf@freebsd.org" Subject: Re: High interrupt rate on a PF box + performance X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jan 2011 10:29:58 -0000 On 1/27/11 10:44 PM, Jack Vogel wrote: > > The 8.X kernel is NOT single-threaded. Anything but. And the stack has > also been improved, I believe there are still bottlenecks but its far better > than the old days. > > The igb driver in 8.2 creates up to 8 queues on the right hardware, they > are each auto-bound to a particular CPU. > > The older version you are running had issues and hence multiqueue was > not enabled. So, do upgrade once 8.2 is finalized :) > > Cheers, > > Jack > Going to push for us to install 8.2 as soon as the release hits, thanks for your feedback Jack :) From owner-freebsd-stable@FreeBSD.ORG Fri Jan 28 10:32:22 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C2B0F106566B; Fri, 28 Jan 2011 10:32:22 +0000 (UTC) (envelope-from ml@my.gd) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 2EB648FC0A; Fri, 28 Jan 2011 10:32:21 +0000 (UTC) Received: by fxm16 with SMTP id 16so3297475fxm.13 for ; Fri, 28 Jan 2011 02:32:21 -0800 (PST) Received: by 10.223.87.5 with SMTP id u5mr411048fal.48.1296210741264; Fri, 28 Jan 2011 02:32:21 -0800 (PST) Received: from dfleuriot.local ([83.167.62.196]) by mx.google.com with ESMTPS id o17sm6355535fal.25.2011.01.28.02.32.20 (version=SSLv3 cipher=RC4-MD5); Fri, 28 Jan 2011 02:32:20 -0800 (PST) Message-ID: <4D429B33.2010402@my.gd> Date: Fri, 28 Jan 2011 11:32:19 +0100 From: Damien Fleuriot User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Jeremy Chadwick References: <4D41417A.20904@my.gd> <1DB50624F8348F48840F2E2CF6040A9D014BEB8833@orsmsx508.amr.corp.intel.com> <4D41B197.6070308@my.gd> <201101280146.57028.wmn@siberianet.ru> <4D41C9FC.10503@my.gd> <20110127195741.GA40449@icarus.home.lan> <4D41D7BE.3030208@my.gd> <20110127205845.GA41537@icarus.home.lan> In-Reply-To: <20110127205845.GA41537@icarus.home.lan> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Sergey Lobanov , "freebsd-stable@freebsd.org" , "freebsd-pf@freebsd.org" Subject: Re: High interrupt rate on a PF box + performance X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jan 2011 10:32:22 -0000 On 1/27/11 9:58 PM, Jeremy Chadwick wrote: > > Kernel folks should be able to talk about this in detail, but my > understanding is that the kernel itself supports multiple threads, but > the question is whether or not the drivers or relevant "pieces" (e.g. > igb(4) driver, pf, TCP stack, etc.) support SMP (multi-core/threading) > or not. I think this is referred to as something being "MPSAFE" or not. > > The things you see during boot -- [ITHREAD], [FILTER], and > [GIANT-LOCKED] play a role as well, but I think those indicate what > style of locking is used (since some drivers/features might not work > properly in a multiprocessor environment). > > I'm trying to avoid correlating "multiprocessor safe" with "makes use of > multiple processors". I'm an old 65xxx CPU guy, this SMP stuff is still > "new technology" to me when it comes to actual operations/mechanics. > > Regarding TCP and SMP, this is regularly touched on in the FreeBSD > Status Reports that go out (always worth reading). See "TCP SMP > scalability project": > > http://www.freebsd.org/news/status/report-2010-10-2010-12.html > > I know all this information is technical of course and doesn't answer > your question directly. I wish there was something more authoritative > when it came to this question. > Thanks for your time explaining all this, I'll have a look at your link, even if it may or may not apply directly to our case, it'll still be interesting material. I'll have to poke around for information about the kernel and how it works with multithreading :) From owner-freebsd-stable@FreeBSD.ORG Fri Jan 28 10:38:03 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 58B54106566C for ; Fri, 28 Jan 2011 10:38:03 +0000 (UTC) (envelope-from bartosz.stec@it4pro.pl) Received: from mainframe.kkip.pl (kkip.pl [87.105.164.78]) by mx1.freebsd.org (Postfix) with ESMTP id E44348FC16 for ; Fri, 28 Jan 2011 10:38:02 +0000 (UTC) Received: from static-78-8-144-74.ssp.dialog.net.pl ([78.8.144.74] helo=[192.168.0.2]) by mainframe.kkip.pl with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.73 (FreeBSD)) (envelope-from ) id 1PiliD-000Nlx-5I for freebsd-stable@freebsd.org; Fri, 28 Jan 2011 11:38:01 +0100 Message-ID: <4D429C71.6000100@it4pro.pl> Date: Fri, 28 Jan 2011 11:37:37 +0100 From: Bartosz Stec Organization: IT4Pro User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; pl; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 CC: freebsd-stable@freebsd.org References: <4D401192.3030400@it4pro.pl> <201101261235.56856.jhb@freebsd.org> <20110126180402.GA17271@tolstoy.tols.org> <201101261344.50756.jhb@freebsd.org> <4D40C355.6070306@it4pro.pl> <20110127032142.GA19946@icarus.home.lan> <4D417931.1060009@it4pro.pl> In-Reply-To: <4D417931.1060009@it4pro.pl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated-User: bartosz.stec@it4pro.pl X-Authenticator: plain X-Sender-Verify: SUCCEEDED (sender exists & accepts mail) X-Spam-Score: -7.6 X-Spam-Score-Int: -75 X-Exim-Version: 4.73 (build at 10-Jan-2011 16:29:01) X-Date: 2011-01-28 11:38:01 X-Connected-IP: 78.8.144.74:56041 X-Message-Linecount: 192 X-Body-Linecount: 179 X-Message-Size: 7498 X-Body-Size: 6741 X-Received-Count: 1 X-Recipient-Count: 1 X-Local-Recipient-Count: 1 X-Local-Recipient-Defer-Count: 0 X-Local-Recipient-Fail-Count: 0 Subject: Re: top shows only part of available physmem X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jan 2011 10:38:03 -0000 >>>>>>>>> Guys, >>>>>>>>> >>>>>>>>> could someone explain me this? >>>>>>>>> >>>>>>>>> # sysctl hw.realmem >>>>>>>>> hw.realmem: 2139029504 >>>>>>>>> >>>>>>>>> top line shows: >>>>>>>>> >>>>>>>>> Mem: 32M Active, 35M Inact, 899M Wired, 8392K Cache, >>>>>>>>> 199M Buf, 58M Free >>>>>>>>> >>>>>>>>> 32+35+899+8+199+58 = 1231MB >>>>>>>>> >>>>>>>>> Shouldn't that sum to all available ram? Or maybe I'm reading >>>>>>>>> it wrong? >>>>>>>>> This machine has indeed 2GB of ram on board and showed in BIOS. >>>>>>>>> i386 FreeBSD 8.2-PRERELEASE #16: Mon Jan 17 22:28:53 CET 2011 >>>>>>>>> Cheers. >>>>>>>> First, don't include 'buf' as isn't a separate set of RAM, it >>>>>>>> is only a range >>>>>>>> of the virtual address space in the kernel. It used to be >>>>>>>> relevant when the >>>>>>>> buffer cache was separate from the VM page cache, but now it is >>>>>>>> mostly >>>>>>>> irrelevant (arguably it should just be dropped from top output). >>>>>>> Thanks for the explanation. So 1231MB - 199MB Buf and we got >>>>>>> about 1GB >>>>>>> of memory instead of 2B. >>>>>>> >>>>>>>> However, look at what hw.physmem says (and the realmem and >>>>>>>> availmem lines in >>>>>>>> dmesg). realmem is actually not that useful as it is not a >>>>>>>> count of the >>>>>>>> amount of memory, but the address of the highest memory page >>>>>>>> available. There >>>>>>>> can be less memory available than that due to "holes" in the >>>>>>>> address space for >>>>>>>> PCI memory BARs, etc. >>>>>>>> >>>>>>> OK, here you go: >>>>>>> # sysctl hw | grep mem >>>>>>> >>>>>>> hw.physmem: 2125893632 >>>>>>> hw.usermem: 1212100608 >>>>>>> hw.realmem: 2139029504 >>>>>>> hw.pci.host_mem_start: 2147483648 >>>>>> Humm, you should still have 2GB of RAM then. All the memory you >>>>>> set aside >>>>>> for ARC should be counted in the 'wired' count, so I'm not sure >>>>>> why you see >>>>>> 1GB of RAM rather than 2GB. >>>>> For what its worth (seems to be the same values top shows), the >>>>> sysctl's >>>>> I use to make cacti graphs of memory usage are: (Counts are in pages) >>>>> >>>>> vm.stats.vm.v_page_size >>>>> >>>>> vm.stats.vm.v_wire_count >>>>> vm.stats.vm.v_active_count >>>>> vm.stats.vm.v_inactive_count >>>>> vm.stats.vm.v_cache_count >>>>> vm.stats.vm.v_free_count >>>>> >>>>> Using the output of those sysctls I allways get a cacti graph >>>>> which at >>>>> least very much seems to account for all memory, and has a flat >>>>> surface >>>>> in a stacked graph. >>>> These sysctls are exactly what top uses. There is also a >>>> 'v_page_count' >>>> which is a total count of pages. >>>> >>> So here's additional sysctl output from now: >>> >>> fbsd# sysctl hw | grep mem >>> hw.physmem: 2125893632 >>> hw.usermem: 1392594944 >>> hw.realmem: 2139029504 >>> hw.pci.host_mem_start: 2147483648 >>> >>> fbsd# sysctl vm.stats.vm >>> vm.stats.vm.v_kthreadpages: 0 >>> vm.stats.vm.v_rforkpages: 0 >>> vm.stats.vm.v_vforkpages: 1422927 >>> vm.stats.vm.v_forkpages: 4606557 >>> vm.stats.vm.v_kthreads: 40 >>> vm.stats.vm.v_rforks: 0 >>> vm.stats.vm.v_vforks: 9917 >>> vm.stats.vm.v_forks: 30429 >>> vm.stats.vm.v_interrupt_free_min: 2 >>> vm.stats.vm.v_pageout_free_min: 34 >>> vm.stats.vm.v_cache_max: 27506 >>> vm.stats.vm.v_cache_min: 13753 >>> vm.stats.vm.v_cache_count: 20312 >>> vm.stats.vm.v_inactive_count: 18591 >>> vm.stats.vm.v_inactive_target: 20629 >>> vm.stats.vm.v_active_count: 1096 >>> vm.stats.vm.v_wire_count: 179027 >>> vm.stats.vm.v_free_count: 6193 >>> vm.stats.vm.v_free_min: 3260 >>> vm.stats.vm.v_free_target: 13753 >>> vm.stats.vm.v_free_reserved: 713 >>> vm.stats.vm.v_page_count: 509752 >>> vm.stats.vm.v_page_size: 4096 >>> vm.stats.vm.v_tfree: 196418851 >>> vm.stats.vm.v_pfree: 2837177 >>> vm.stats.vm.v_dfree: 0 >>> vm.stats.vm.v_tcached: 1305893 >>> vm.stats.vm.v_pdpages: 3527455 >>> vm.stats.vm.v_pdwakeups: 187 >>> vm.stats.vm.v_reactivated: 83786 >>> vm.stats.vm.v_intrans: 3053 >>> vm.stats.vm.v_vnodepgsout: 134384 >>> vm.stats.vm.v_vnodepgsin: 29213 >>> vm.stats.vm.v_vnodeout: 96249 >>> vm.stats.vm.v_vnodein: 29213 >>> vm.stats.vm.v_swappgsout: 19730 >>> vm.stats.vm.v_swappgsin: 8573 >>> vm.stats.vm.v_swapout: 5287 >>> vm.stats.vm.v_swapin: 2975 >>> vm.stats.vm.v_ozfod: 83338 >>> vm.stats.vm.v_zfod: 2462557 >>> vm.stats.vm.v_cow_optim: 330 >>> vm.stats.vm.v_cow_faults: 1239253 >>> vm.stats.vm.v_vm_faults: 5898471 >>> >>> fbsd# sysctl vm.vmtotal >>> vm.vmtotal: >>> System wide totals computed every five seconds: (values in >>> kilobytes) >>> =============================================== >>> Processes: (RUNQ: 1 Disk Wait: 0 Page Wait: 0 >>> Sleep: 60) >>> Virtual Memory: (Total: 4971660K Active: 699312K) >>> Real Memory: (Total: 540776K Active: 29756K) >>> Shared Virtual Memory: (Total: 41148K Active: 19468K) >>> Shared Real Memory: (Total: 4964K Active: 3048K) >>> Free Memory Pages: 105308K >>> >>> >>> /usr/bin/top line: Mem: 4664K Active, 73M Inact, 700M Wired, 79M >>> Cache, 199M Buf, 23M Free >>> Sum (Without Buf): 879,5 MB >>> >>> So what are we looking at? Wrong sysctls/top output or maybe >>> actually FreeBSD doesn't use all available RAM for some reason? >>> Could it be hardware problem? Maybe I should provide some >>> additional >>> data? >> Does the behaviour become more expected if you remove ZFS from the >> picture? Please try this (yes really). >> > About an hour ago I had to hard reset this machine because it stopped > responding (bu still gived ping response) after massive slowdown seen > by SAMBA users. > Now top shows following: > Mem: 78M Active, 83M Inact, 639M Wired, 120K Cache, 199M Buf, 1139M Free. > > What I am afraid is that this PC slowly eats own memory and finally > starved itself to death, because it happened second time in 2 weeks, > and it seems that rebuilding world+kernel Mon Jan 17 22:28:53 CET 2011 > could be the cause. For some strange reason I believe that Jeremy > Chadwick could be right pointing ZFS. Way this machine stops > responding without any info in logs makes me believe that it has > simply lost ability to I/O to HDD (system is ZFS-only). > Day 2 after reboot: Mem: 100M Active, 415M Inact, 969M Wired, 83M Cache, 199M Buf, 21M Free Sum: 1588MB 1/4 of total RAM disappeared already. Anyone knows what possibly happening here or maybe I should hire some voodoo shaman to expel memory-eating-ghost from the machine ;)? -- Bartosz Stec From owner-freebsd-stable@FreeBSD.ORG Fri Jan 28 11:31:00 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B66EE1065674 for ; Fri, 28 Jan 2011 11:31:00 +0000 (UTC) (envelope-from ml@my.gd) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 427948FC0A for ; Fri, 28 Jan 2011 11:30:59 +0000 (UTC) Received: by fxm16 with SMTP id 16so3351207fxm.13 for ; Fri, 28 Jan 2011 03:30:58 -0800 (PST) Received: by 10.223.114.65 with SMTP id d1mr2258395faq.88.1296214257702; Fri, 28 Jan 2011 03:30:57 -0800 (PST) Received: from dfleuriot.local ([83.167.62.196]) by mx.google.com with ESMTPS id n15sm6378880fam.12.2011.01.28.03.30.55 (version=SSLv3 cipher=RC4-MD5); Fri, 28 Jan 2011 03:30:55 -0800 (PST) Message-ID: <4D42A8EF.7060302@my.gd> Date: Fri, 28 Jan 2011 12:30:55 +0100 From: Damien Fleuriot User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Bartosz Stec References: <4D401192.3030400@it4pro.pl> <201101261235.56856.jhb@freebsd.org> <20110126180402.GA17271@tolstoy.tols.org> <201101261344.50756.jhb@freebsd.org> <4D40C355.6070306@it4pro.pl> <20110127032142.GA19946@icarus.home.lan> <4D417931.1060009@it4pro.pl> <4D429C71.6000100@it4pro.pl> In-Reply-To: <4D429C71.6000100@it4pro.pl> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: top shows only part of available physmem X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jan 2011 11:31:00 -0000 On 1/28/11 11:37 AM, Bartosz Stec wrote: > >>>>>>>>>> Guys, >>>>>>>>>> >>>>>>>>>> could someone explain me this? >>>>>>>>>> >>>>>>>>>> # sysctl hw.realmem >>>>>>>>>> hw.realmem: 2139029504 >>>>>>>>>> >>>>>>>>>> top line shows: >>>>>>>>>> >>>>>>>>>> Mem: 32M Active, 35M Inact, 899M Wired, 8392K Cache, >>>>>>>>>> 199M Buf, 58M Free >>>>>>>>>> >>>>>>>>>> 32+35+899+8+199+58 = 1231MB >>>>>>>>>> >>>>>>>>>> Shouldn't that sum to all available ram? Or maybe I'm reading >>>>>>>>>> it wrong? >>>>>>>>>> This machine has indeed 2GB of ram on board and showed in BIOS. >>>>>>>>>> i386 FreeBSD 8.2-PRERELEASE #16: Mon Jan 17 22:28:53 CET 2011 >>>>>>>>>> Cheers. >>>>>>>>> First, don't include 'buf' as isn't a separate set of RAM, it >>>>>>>>> is only a range >>>>>>>>> of the virtual address space in the kernel. It used to be >>>>>>>>> relevant when the >>>>>>>>> buffer cache was separate from the VM page cache, but now it is >>>>>>>>> mostly >>>>>>>>> irrelevant (arguably it should just be dropped from top output). >>>>>>>> Thanks for the explanation. So 1231MB - 199MB Buf and we got >>>>>>>> about 1GB >>>>>>>> of memory instead of 2B. >>>>>>>> >>>>>>>>> However, look at what hw.physmem says (and the realmem and >>>>>>>>> availmem lines in >>>>>>>>> dmesg). realmem is actually not that useful as it is not a >>>>>>>>> count of the >>>>>>>>> amount of memory, but the address of the highest memory page >>>>>>>>> available. There >>>>>>>>> can be less memory available than that due to "holes" in the >>>>>>>>> address space for >>>>>>>>> PCI memory BARs, etc. >>>>>>>>> >>>>>>>> OK, here you go: >>>>>>>> # sysctl hw | grep mem >>>>>>>> >>>>>>>> hw.physmem: 2125893632 >>>>>>>> hw.usermem: 1212100608 >>>>>>>> hw.realmem: 2139029504 >>>>>>>> hw.pci.host_mem_start: 2147483648 >>>>>>> Humm, you should still have 2GB of RAM then. All the memory you >>>>>>> set aside >>>>>>> for ARC should be counted in the 'wired' count, so I'm not sure >>>>>>> why you see >>>>>>> 1GB of RAM rather than 2GB. >>>>>> For what its worth (seems to be the same values top shows), the >>>>>> sysctl's >>>>>> I use to make cacti graphs of memory usage are: (Counts are in pages) >>>>>> >>>>>> vm.stats.vm.v_page_size >>>>>> >>>>>> vm.stats.vm.v_wire_count >>>>>> vm.stats.vm.v_active_count >>>>>> vm.stats.vm.v_inactive_count >>>>>> vm.stats.vm.v_cache_count >>>>>> vm.stats.vm.v_free_count >>>>>> >>>>>> Using the output of those sysctls I allways get a cacti graph >>>>>> which at >>>>>> least very much seems to account for all memory, and has a flat >>>>>> surface >>>>>> in a stacked graph. >>>>> These sysctls are exactly what top uses. There is also a >>>>> 'v_page_count' >>>>> which is a total count of pages. >>>>> >>>> So here's additional sysctl output from now: >>>> >>>> fbsd# sysctl hw | grep mem >>>> hw.physmem: 2125893632 >>>> hw.usermem: 1392594944 >>>> hw.realmem: 2139029504 >>>> hw.pci.host_mem_start: 2147483648 >>>> >>>> fbsd# sysctl vm.stats.vm >>>> vm.stats.vm.v_kthreadpages: 0 >>>> vm.stats.vm.v_rforkpages: 0 >>>> vm.stats.vm.v_vforkpages: 1422927 >>>> vm.stats.vm.v_forkpages: 4606557 >>>> vm.stats.vm.v_kthreads: 40 >>>> vm.stats.vm.v_rforks: 0 >>>> vm.stats.vm.v_vforks: 9917 >>>> vm.stats.vm.v_forks: 30429 >>>> vm.stats.vm.v_interrupt_free_min: 2 >>>> vm.stats.vm.v_pageout_free_min: 34 >>>> vm.stats.vm.v_cache_max: 27506 >>>> vm.stats.vm.v_cache_min: 13753 >>>> vm.stats.vm.v_cache_count: 20312 >>>> vm.stats.vm.v_inactive_count: 18591 >>>> vm.stats.vm.v_inactive_target: 20629 >>>> vm.stats.vm.v_active_count: 1096 >>>> vm.stats.vm.v_wire_count: 179027 >>>> vm.stats.vm.v_free_count: 6193 >>>> vm.stats.vm.v_free_min: 3260 >>>> vm.stats.vm.v_free_target: 13753 >>>> vm.stats.vm.v_free_reserved: 713 >>>> vm.stats.vm.v_page_count: 509752 >>>> vm.stats.vm.v_page_size: 4096 >>>> vm.stats.vm.v_tfree: 196418851 >>>> vm.stats.vm.v_pfree: 2837177 >>>> vm.stats.vm.v_dfree: 0 >>>> vm.stats.vm.v_tcached: 1305893 >>>> vm.stats.vm.v_pdpages: 3527455 >>>> vm.stats.vm.v_pdwakeups: 187 >>>> vm.stats.vm.v_reactivated: 83786 >>>> vm.stats.vm.v_intrans: 3053 >>>> vm.stats.vm.v_vnodepgsout: 134384 >>>> vm.stats.vm.v_vnodepgsin: 29213 >>>> vm.stats.vm.v_vnodeout: 96249 >>>> vm.stats.vm.v_vnodein: 29213 >>>> vm.stats.vm.v_swappgsout: 19730 >>>> vm.stats.vm.v_swappgsin: 8573 >>>> vm.stats.vm.v_swapout: 5287 >>>> vm.stats.vm.v_swapin: 2975 >>>> vm.stats.vm.v_ozfod: 83338 >>>> vm.stats.vm.v_zfod: 2462557 >>>> vm.stats.vm.v_cow_optim: 330 >>>> vm.stats.vm.v_cow_faults: 1239253 >>>> vm.stats.vm.v_vm_faults: 5898471 >>>> >>>> fbsd# sysctl vm.vmtotal >>>> vm.vmtotal: >>>> System wide totals computed every five seconds: (values in >>>> kilobytes) >>>> =============================================== >>>> Processes: (RUNQ: 1 Disk Wait: 0 Page Wait: 0 >>>> Sleep: 60) >>>> Virtual Memory: (Total: 4971660K Active: 699312K) >>>> Real Memory: (Total: 540776K Active: 29756K) >>>> Shared Virtual Memory: (Total: 41148K Active: 19468K) >>>> Shared Real Memory: (Total: 4964K Active: 3048K) >>>> Free Memory Pages: 105308K >>>> >>>> >>>> /usr/bin/top line: Mem: 4664K Active, 73M Inact, 700M Wired, 79M >>>> Cache, 199M Buf, 23M Free >>>> Sum (Without Buf): 879,5 MB >>>> >>>> So what are we looking at? Wrong sysctls/top output or maybe >>>> actually FreeBSD doesn't use all available RAM for some reason? >>>> Could it be hardware problem? Maybe I should provide some >>>> additional >>>> data? >>> Does the behaviour become more expected if you remove ZFS from the >>> picture? Please try this (yes really). >>> >> About an hour ago I had to hard reset this machine because it stopped >> responding (bu still gived ping response) after massive slowdown seen >> by SAMBA users. >> Now top shows following: >> Mem: 78M Active, 83M Inact, 639M Wired, 120K Cache, 199M Buf, 1139M Free. >> >> What I am afraid is that this PC slowly eats own memory and finally >> starved itself to death, because it happened second time in 2 weeks, >> and it seems that rebuilding world+kernel Mon Jan 17 22:28:53 CET 2011 >> could be the cause. For some strange reason I believe that Jeremy >> Chadwick could be right pointing ZFS. Way this machine stops >> responding without any info in logs makes me believe that it has >> simply lost ability to I/O to HDD (system is ZFS-only). >> > Day 2 after reboot: > Mem: 100M Active, 415M Inact, 969M Wired, 83M Cache, 199M Buf, 21M Free > Sum: 1588MB > 1/4 of total RAM disappeared already. > Anyone knows what possibly happening here or maybe I should hire some > voodoo shaman to expel memory-eating-ghost from the machine ;)? > Can you provide the following sysctls (ignore my values obviously) again, now that some of your memory magicked itself away ? hw.physmem: 4243976192 hw.usermem: 3417485312 hw.realmem: 5100273664 vfs.zfs.arc_min: 134217728 vfs.zfs.arc_max: 2147483648 And check out the ZFS ARC stats script here: http://bitbucket.org/koie/arc_summary/changeset/dbe14d2cf52b/ Run it and see what results you get concerning your ZFS used memory. What's of interest is the current size of your ZFS ARC cache. It might account for the memory you're missing, with a bit of luck. From owner-freebsd-stable@FreeBSD.ORG Fri Jan 28 12:41:30 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DA517106566B for ; Fri, 28 Jan 2011 12:41:30 +0000 (UTC) (envelope-from bartosz.stec@it4pro.pl) Received: from mainframe.kkip.pl (kkip.pl [87.105.164.78]) by mx1.freebsd.org (Postfix) with ESMTP id 3030B8FC1A for ; Fri, 28 Jan 2011 12:41:29 +0000 (UTC) Received: from static-78-8-144-74.ssp.dialog.net.pl ([78.8.144.74] helo=[192.168.0.2]) by mainframe.kkip.pl with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.73 (FreeBSD)) (envelope-from ) id 1Pindd-000KcF-2B; Fri, 28 Jan 2011 13:41:27 +0100 Message-ID: <4D42B95D.6020503@it4pro.pl> Date: Fri, 28 Jan 2011 13:41:01 +0100 From: Bartosz Stec Organization: IT4Pro User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; pl; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Damien Fleuriot References: <4D401192.3030400@it4pro.pl> <201101261235.56856.jhb@freebsd.org> <20110126180402.GA17271@tolstoy.tols.org> <201101261344.50756.jhb@freebsd.org> <4D40C355.6070306@it4pro.pl> <20110127032142.GA19946@icarus.home.lan> <4D417931.1060009@it4pro.pl> <4D429C71.6000100@it4pro.pl> <4D42A8EF.7060302@my.gd> In-Reply-To: <4D42A8EF.7060302@my.gd> X-Authenticated-User: bartosz.stec@it4pro.pl X-Authenticator: plain X-Sender-Verify: SUCCEEDED (sender exists & accepts mail) X-Spam-Score: -8.1 X-Spam-Score-Int: -80 X-Exim-Version: 4.73 (build at 10-Jan-2011 16:29:01) X-Date: 2011-01-28 13:41:27 X-Connected-IP: 78.8.144.74:60714 X-Message-Linecount: 625 X-Body-Linecount: 611 X-Message-Size: 26211 X-Body-Size: 25379 X-Received-Count: 1 X-Recipient-Count: 2 X-Local-Recipient-Count: 2 X-Local-Recipient-Defer-Count: 0 X-Local-Recipient-Fail-Count: 0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org Subject: Re: top shows only part of available physmem X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jan 2011 12:41:30 -0000 W dniu 2011-01-28 12:30, Damien Fleuriot pisze: > > On 1/28/11 11:37 AM, Bartosz Stec wrote: >>>>>>>>>>> Guys, >>>>>>>>>>> >>>>>>>>>>> could someone explain me this? >>>>>>>>>>> >>>>>>>>>>> # sysctl hw.realmem >>>>>>>>>>> hw.realmem: 2139029504 >>>>>>>>>>> >>>>>>>>>>> top line shows: >>>>>>>>>>> >>>>>>>>>>> Mem: 32M Active, 35M Inact, 899M Wired, 8392K Cache, >>>>>>>>>>> 199M Buf, 58M Free >>>>>>>>>>> >>>>>>>>>>> 32+35+899+8+199+58 = 1231MB >>>>>>>>>>> >>>>>>>>>>> Shouldn't that sum to all available ram? Or maybe I'm reading >>>>>>>>>>> it wrong? >>>>>>>>>>> This machine has indeed 2GB of ram on board and showed in BIOS. >>>>>>>>>>> i386 FreeBSD 8.2-PRERELEASE #16: Mon Jan 17 22:28:53 CET 2011 >>>>>>>>>>> Cheers. >>>>>>>>>> First, don't include 'buf' as isn't a separate set of RAM, it >>>>>>>>>> is only a range >>>>>>>>>> of the virtual address space in the kernel. It used to be >>>>>>>>>> relevant when the >>>>>>>>>> buffer cache was separate from the VM page cache, but now it is >>>>>>>>>> mostly >>>>>>>>>> irrelevant (arguably it should just be dropped from top output). >>>>>>>>> Thanks for the explanation. So 1231MB - 199MB Buf and we got >>>>>>>>> about 1GB >>>>>>>>> of memory instead of 2B. >>>>>>>>> >>>>>>>>>> However, look at what hw.physmem says (and the realmem and >>>>>>>>>> availmem lines in >>>>>>>>>> dmesg). realmem is actually not that useful as it is not a >>>>>>>>>> count of the >>>>>>>>>> amount of memory, but the address of the highest memory page >>>>>>>>>> available. There >>>>>>>>>> can be less memory available than that due to "holes" in the >>>>>>>>>> address space for >>>>>>>>>> PCI memory BARs, etc. >>>>>>>>>> >>>>>>>>> OK, here you go: >>>>>>>>> # sysctl hw | grep mem >>>>>>>>> >>>>>>>>> hw.physmem: 2125893632 >>>>>>>>> hw.usermem: 1212100608 >>>>>>>>> hw.realmem: 2139029504 >>>>>>>>> hw.pci.host_mem_start: 2147483648 >>>>>>>> Humm, you should still have 2GB of RAM then. All the memory you >>>>>>>> set aside >>>>>>>> for ARC should be counted in the 'wired' count, so I'm not sure >>>>>>>> why you see >>>>>>>> 1GB of RAM rather than 2GB. >>>>>>> For what its worth (seems to be the same values top shows), the >>>>>>> sysctl's >>>>>>> I use to make cacti graphs of memory usage are: (Counts are in pages) >>>>>>> >>>>>>> vm.stats.vm.v_page_size >>>>>>> >>>>>>> vm.stats.vm.v_wire_count >>>>>>> vm.stats.vm.v_active_count >>>>>>> vm.stats.vm.v_inactive_count >>>>>>> vm.stats.vm.v_cache_count >>>>>>> vm.stats.vm.v_free_count >>>>>>> >>>>>>> Using the output of those sysctls I allways get a cacti graph >>>>>>> which at >>>>>>> least very much seems to account for all memory, and has a flat >>>>>>> surface >>>>>>> in a stacked graph. >>>>>> These sysctls are exactly what top uses. There is also a >>>>>> 'v_page_count' >>>>>> which is a total count of pages. >>>>>> >>>>> So here's additional sysctl output from now: >>>>> >>>>> fbsd# sysctl hw | grep mem >>>>> hw.physmem: 2125893632 >>>>> hw.usermem: 1392594944 >>>>> hw.realmem: 2139029504 >>>>> hw.pci.host_mem_start: 2147483648 >>>>> >>>>> fbsd# sysctl vm.stats.vm >>>>> vm.stats.vm.v_kthreadpages: 0 >>>>> vm.stats.vm.v_rforkpages: 0 >>>>> vm.stats.vm.v_vforkpages: 1422927 >>>>> vm.stats.vm.v_forkpages: 4606557 >>>>> vm.stats.vm.v_kthreads: 40 >>>>> vm.stats.vm.v_rforks: 0 >>>>> vm.stats.vm.v_vforks: 9917 >>>>> vm.stats.vm.v_forks: 30429 >>>>> vm.stats.vm.v_interrupt_free_min: 2 >>>>> vm.stats.vm.v_pageout_free_min: 34 >>>>> vm.stats.vm.v_cache_max: 27506 >>>>> vm.stats.vm.v_cache_min: 13753 >>>>> vm.stats.vm.v_cache_count: 20312 >>>>> vm.stats.vm.v_inactive_count: 18591 >>>>> vm.stats.vm.v_inactive_target: 20629 >>>>> vm.stats.vm.v_active_count: 1096 >>>>> vm.stats.vm.v_wire_count: 179027 >>>>> vm.stats.vm.v_free_count: 6193 >>>>> vm.stats.vm.v_free_min: 3260 >>>>> vm.stats.vm.v_free_target: 13753 >>>>> vm.stats.vm.v_free_reserved: 713 >>>>> vm.stats.vm.v_page_count: 509752 >>>>> vm.stats.vm.v_page_size: 4096 >>>>> vm.stats.vm.v_tfree: 196418851 >>>>> vm.stats.vm.v_pfree: 2837177 >>>>> vm.stats.vm.v_dfree: 0 >>>>> vm.stats.vm.v_tcached: 1305893 >>>>> vm.stats.vm.v_pdpages: 3527455 >>>>> vm.stats.vm.v_pdwakeups: 187 >>>>> vm.stats.vm.v_reactivated: 83786 >>>>> vm.stats.vm.v_intrans: 3053 >>>>> vm.stats.vm.v_vnodepgsout: 134384 >>>>> vm.stats.vm.v_vnodepgsin: 29213 >>>>> vm.stats.vm.v_vnodeout: 96249 >>>>> vm.stats.vm.v_vnodein: 29213 >>>>> vm.stats.vm.v_swappgsout: 19730 >>>>> vm.stats.vm.v_swappgsin: 8573 >>>>> vm.stats.vm.v_swapout: 5287 >>>>> vm.stats.vm.v_swapin: 2975 >>>>> vm.stats.vm.v_ozfod: 83338 >>>>> vm.stats.vm.v_zfod: 2462557 >>>>> vm.stats.vm.v_cow_optim: 330 >>>>> vm.stats.vm.v_cow_faults: 1239253 >>>>> vm.stats.vm.v_vm_faults: 5898471 >>>>> >>>>> fbsd# sysctl vm.vmtotal >>>>> vm.vmtotal: >>>>> System wide totals computed every five seconds: (values in >>>>> kilobytes) >>>>> =============================================== >>>>> Processes: (RUNQ: 1 Disk Wait: 0 Page Wait: 0 >>>>> Sleep: 60) >>>>> Virtual Memory: (Total: 4971660K Active: 699312K) >>>>> Real Memory: (Total: 540776K Active: 29756K) >>>>> Shared Virtual Memory: (Total: 41148K Active: 19468K) >>>>> Shared Real Memory: (Total: 4964K Active: 3048K) >>>>> Free Memory Pages: 105308K >>>>> >>>>> >>>>> /usr/bin/top line: Mem: 4664K Active, 73M Inact, 700M Wired, 79M >>>>> Cache, 199M Buf, 23M Free >>>>> Sum (Without Buf): 879,5 MB >>>>> >>>>> So what are we looking at? Wrong sysctls/top output or maybe >>>>> actually FreeBSD doesn't use all available RAM for some reason? >>>>> Could it be hardware problem? Maybe I should provide some >>>>> additional >>>>> data? >>>> Does the behaviour become more expected if you remove ZFS from the >>>> picture? Please try this (yes really). >>>> >>> About an hour ago I had to hard reset this machine because it stopped >>> responding (bu still gived ping response) after massive slowdown seen >>> by SAMBA users. >>> Now top shows following: >>> Mem: 78M Active, 83M Inact, 639M Wired, 120K Cache, 199M Buf, 1139M Free. >>> >>> What I am afraid is that this PC slowly eats own memory and finally >>> starved itself to death, because it happened second time in 2 weeks, >>> and it seems that rebuilding world+kernel Mon Jan 17 22:28:53 CET 2011 >>> could be the cause. For some strange reason I believe that Jeremy >>> Chadwick could be right pointing ZFS. Way this machine stops >>> responding without any info in logs makes me believe that it has >>> simply lost ability to I/O to HDD (system is ZFS-only). >>> >> Day 2 after reboot: >> Mem: 100M Active, 415M Inact, 969M Wired, 83M Cache, 199M Buf, 21M Free >> Sum: 1588MB >> 1/4 of total RAM disappeared already. >> Anyone knows what possibly happening here or maybe I should hire some >> voodoo shaman to expel memory-eating-ghost from the machine ;)? >> > > Can you provide the following sysctls (ignore my values obviously) > again, now that some of your memory magicked itself away ? > > hw.physmem: 4243976192 > hw.usermem: 3417485312 > hw.realmem: 5100273664 > vfs.zfs.arc_min: 134217728 > vfs.zfs.arc_max: 2147483648 > > > And check out the ZFS ARC stats script here: > http://bitbucket.org/koie/arc_summary/changeset/dbe14d2cf52b/ > > Run it and see what results you get concerning your ZFS used memory. > What's of interest is the current size of your ZFS ARC cache. > It might account for the memory you're missing, with a bit of luck. Sure: hw.physmem: 2125893632 hw.usermem: 898928640 hw.realmem: 2139029504 vfs.zfs.arc_min: 167772160 vfs.zfs.arc_max: 1342177280 Actual top stats: 53M Active, 145M Inact, 1175M Wired, 68M Cache, 199M Buf, 7716K Free Sum: 1448MB (without Buf) About 150MB less than 2 hours ago ;) # ./arc_summary.sh System Memory: Physical RAM: 2027 MB Free Memory : 7 MB ARC Size: Current Size: 796 MB (arcsize) Target Size (Adaptive): 797 MB (c) Min Size (Hard Limit): 160 MB (zfs_arc_min) Max Size (Hard Limit): 1280 MB (zfs_arc_max) ARC Size Breakdown: Most Recently Used Cache Size: 52% 415 MB (p) Most Frequently Used Cache Size: 47% 382 MB (c-p) ARC Efficency: Cache Access Total: 5931999 Cache Hit Ratio: 89% 5323807 [Defined State for buffer] Cache Miss Ratio: 10% 608192 [Undefined State for Buffer] REAL Hit Ratio: 89% 5317666 [MRU/MFU Hits Only] Data Demand Efficiency: 95% Data Prefetch Efficiency: 1% CACHE HITS BY CACHE LIST: Anon: --% Counter Rolled. Most Recently Used: 39% 2121911 (mru) [ Return Customer ] Most Frequently Used: 60% 3195755 (mfu) [ Frequent Customer ] Most Recently Used Ghost: 1% 56946 (mru_ghost) [ Return Customer Evicted, Now Back ] Most Frequently Used Ghost: 3% 175154 (mfu_ghost) [ Frequent Customer Evicted, Now Back ] CACHE HITS BY DATA TYPE: Demand Data: 21% 1164556 Prefetch Data: 0% 188 Demand Metadata: 77% 4151758 Prefetch Metadata: 0% 7305 CACHE MISSES BY DATA TYPE: Demand Data: 9% 59296 Prefetch Data: 2% 15143 Demand Metadata: 85% 518463 Prefetch Metadata: 2% 15290 --------------------------------------------- Tunables in loader.conf: vm.kmem_size="1536M" vm.kmem_size_max="1536M" vfs.zfs.arc_max="1280M" It seems that about 579MB is now "missing" while ARC size is 796 MB so it's rather not the case. -- Bartosz Stec From owner-freebsd-stable@FreeBSD.ORG Sat Jan 29 01:26:30 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 110C0106564A for ; Sat, 29 Jan 2011 01:26:30 +0000 (UTC) (envelope-from jjh@deterlab.net) Received: from tardis.deterlab.net (tardis.deterlab.net [206.117.25.63]) by mx1.freebsd.org (Postfix) with ESMTP id 003D18FC0C for ; Sat, 29 Jan 2011 01:26:29 +0000 (UTC) Received: from [10.0.2.23] (pod.isi.edu [128.9.168.186]) by tardis.deterlab.net (Postfix) with ESMTPSA id 8459B3C01A3 for ; Fri, 28 Jan 2011 17:10:41 -0800 (PST) From: John Hickey Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 28 Jan 2011 17:10:41 -0800 Message-Id: To: freebsd-stable@freebsd.org Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Subject: nfsd hung on ufs vnode lock X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Jan 2011 01:26:30 -0000 There was a previous thread about this, but it doesn't look like there = was any resolution: http://lists.freebsd.org/pipermail/freebsd-stable/2010-May/056986.html I run a fileserver for an Emulab (www.emulab.net) system. As such, the = exports table is constantly modified as experiments are swapped in and = out. We also get a lot of researchers using NFS for strange things. In = this case, the exclusive lock was for a cache directory shared by about = 36 machines running Ubuntu 8.04 and mounting with NFSv2. Eventually, = all our nfsd processes get stuck since the exclusive lock for the = directory is never released. I could use any and all pointers on = getting this fixed. What I am running: jjh@users: ~$ uname -a FreeBSD users.isi.deterlab.net 7.3-RELEASE-p2 FreeBSD 7.3-RELEASE-p2 #9: = Tue Sep 14 16:24:57 PDT 2010 = root@users.isi.deterlab.net:/usr/obj/usr/src/sys/USERS7 i386 Here are the sleepchains for my system (note that 0xd1f72678 appears = twice): 0xce089cf0: tag syncer, type VNON usecount 1, writecount 0, refcount 2 mountedhere 0 flags () lock type syncer: EXCL (count 1) by thread 0xcdb4b000 (pid 46) 0xd1f72678: tag ufs, type VDIR usecount 2, writecount 0, refcount 67 mountedhere 0 flags () v_object 0xd1e90e80 ref 0 pages 1 lock type ufs: EXCL (count 1) by thread 0xce1146c0 (pid 866) with 62 = pending ino 143173560, on dev mfid0s1f 0xd1e6f228: tag ufs, type VDIR usecount 1, writecount 0, refcount 3 mountedhere 0 flags () v_object 0xd180f480 ref 0 pages 1 lock type ufs: SHARED (count 1) ino 19268907, on dev mfid0s1f 0xd1a37564: tag ufs, type VNON usecount 1, writecount 0, refcount 1 mountedhere 0 flags () lock type ufs: EXCL (count 1) by thread 0xcdb4c240 (pid 871) ino 115689129, on dev mfid1s1d 0xce089cf0: tag syncer, type VNON usecount 1, writecount 0, refcount 2 mountedhere 0 flags () lock type syncer: EXCL (count 1) by thread 0xcdb4b000 (pid 46) 0xd1f72678: tag ufs, type VDIR usecount 2, writecount 0, refcount 67 mountedhere 0 flags () v_object 0xd1e90e80 ref 0 pages 1 lock type ufs: EXCL (count 1) by thread 0xce1146c0 (pid 866) with 62 = pending ino 143173560, on dev mfid0s1f 0xd1e6f228: tag ufs, type VDIR usecount 1, writecount 0, refcount 3 mountedhere 0 flags () v_object 0xd180f480 ref 0 pages 1 lock type ufs: SHARED (count 1) ino 19268907, on dev mfid0s1f 0xd1a37564: tag ufs, type VNON usecount 1, writecount 0, refcount 1 mountedhere 0 flags () lock type ufs: EXCL (count 1) by thread 0xcdb4c240 (pid 871) ino 115689129, on dev mfid1s1d Here is process 866: (kgdb) proc 866 [Switching to thread 66 (Thread 100104)]#0 sched_switch (td=3D0xce1146c0,= newtd=3DVariable "newtd" is not available. ) at /usr/src/sys/kern/sched_ule.c:1936 1936 =20 (kgdb) bt #0 sched_switch (td=3D0xce1146c0, newtd=3DVariable "newtd" is not = available. ) at /usr/src/sys/kern/sched_ule.c:1936 #1 0xc080a4a6 in mi_switch (flags=3DVariable "flags" is not available. ) at /usr/src/sys/kern/kern_synch.c:444 #2 0xc0837aab in sleepq_switch (wchan=3DVariable "wchan" is not = available. ) at /usr/src/sys/kern/subr_sleepqueue.c:497 #3 0xc08380f6 in sleepq_wait (wchan=3D0xd4176394) at = /usr/src/sys/kern/subr_sleepqueue.c:580 #4 0xc080a92a in _sleep (ident=3D0xd4176394, lock=3D0xc0ceb498, = priority=3D80, wmesg=3D0xc0bb656e "ufs", timo=3D0) at = /usr/src/sys/kern/kern_synch.c:230 #5 0xc07ea9fa in acquire (lkpp=3D0xcd7375a0, extflags=3DVariable = "extflags" is not available. ) at /usr/src/sys/kern/kern_lock.c:151 #6 0xc07eb2ec in _lockmgr (lkp=3D0xd4176394, flags=3D8194, = interlkp=3D0xd41763c4, td=3D0xce1146c0, file=3D0xc0bc20c8 = "/usr/src/sys/kern/vfs_subr.c", line=3D2062) at /usr/src/sys/kern/kern_lock.c:384 #7 0xc0a24765 in ffs_lock (ap=3D0xcd737608) at = /usr/src/sys/ufs/ffs/ffs_vnops.c:377 #8 0xc0b26876 in VOP_LOCK1_APV (vop=3D0xc0ca4740, a=3D0xcd737608) at = vnode_if.c:1618 #9 0xc0896d76 in _vn_lock (vp=3D0xd417633c, flags=3D8194, = td=3D0xce1146c0, file=3D0xc0bc20c8 "/usr/src/sys/kern/vfs_subr.c", = line=3D2062) at vnode_if.h:851 #10 0xc0889da4 in vget (vp=3D0xd417633c, flags=3D8194, td=3D0xce1146c0) = at /usr/src/sys/kern/vfs_subr.c:2062 #11 0xc087bd23 in vfs_hash_get (mp=3D0xce0962d0, hash=3D143173100, = flags=3DVariable "flags" is not available. ) at /usr/src/sys/kern/vfs_hash.c:81 #12 0xc0a1e429 in ffs_vgetf (mp=3D0xce0962d0, ino=3D143173100, flags=3D2, = vpp=3D0xcd737800, ffs_flags=3D0) at = /usr/src/sys/ufs/ffs/ffs_vfsops.c:1400 #13 0xc0a1e95e in ffs_vget (mp=3D0xce0962d0, ino=3D143173100, flags=3D2, = vpp=3D0xcd737800) at /usr/src/sys/ufs/ffs/ffs_vfsops.c:1380 #14 0xc0a00765 in ffs_valloc (pvp=3D0xd1f72678, mode=3D33152, = cred=3D0xcf024700, vpp=3D0xcd737800) at = /usr/src/sys/ufs/ffs/ffs_alloc.c:970 #15 0xc0a30945 in ufs_makeinode (mode=3D33152, dvp=3D0xd1f72678, = vpp=3D0xcd737a64, cnp=3D0xcd737a78) at = /usr/src/sys/ufs/ufs/ufs_vnops.c:2254 #16 0xc0a310c0 in ufs_create (ap=3D0xcd73799c) at = /usr/src/sys/ufs/ufs/ufs_vnops.c:193 #17 0xc0b26ed2 in VOP_CREATE_APV (vop=3D0xc0ca4740, a=3D0xcd73799c) at = vnode_if.c:206 #18 0xc09c02ad in nfsrv_create (nfsd=3D0xcde57500, slp=3D0xcde37000, = td=3D0xce1146c0, mrq=3D0xcd737c58) at vnode_if.h:112 #19 0xc09c7a61 in nfssvc (td=3D0xce1146c0, uap=3D0xcd737cfc) at = /usr/src/sys/nfsserver/nfs_syscalls.c:456 #20 0xc0b108e5 in syscall (frame=3D0xcd737d38) at = /usr/src/sys/i386/i386/trap.c:1101 #21 0xc0af4290 in Xint0x80_syscall () at = /usr/src/sys/i386/i386/exception.s:262 #22 0x00000033 in ?? () Previous frame inner to this frame (corrupt stack?) John Hickey jjh@deterlab.net From owner-freebsd-stable@FreeBSD.ORG Sat Jan 29 17:20:17 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 95F4B1065670 for ; Sat, 29 Jan 2011 17:20:17 +0000 (UTC) (envelope-from ml@my.gd) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 37FE08FC17 for ; Sat, 29 Jan 2011 17:20:15 +0000 (UTC) Received: by fxm16 with SMTP id 16so4541030fxm.13 for ; Sat, 29 Jan 2011 09:20:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.111.137 with SMTP id s9mr209870fap.98.1296321615184; Sat, 29 Jan 2011 09:20:15 -0800 (PST) Received: by 10.223.118.84 with HTTP; Sat, 29 Jan 2011 09:20:15 -0800 (PST) Date: Sat, 29 Jan 2011 18:20:15 +0100 Message-ID: From: Damien Fleuriot To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org Subject: KERN - mfi driver for Dell raid h200 on r210 servers X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Jan 2011 17:20:17 -0000 Hello lists, I'm trying to get FreeBSD 8.0 or 8.1 to run on a Dell poweredge r210 server. It ships with a SATA/SAS h200 RAID controller. Sadly, the MFI driver doesn't seem to register for this card... Find below the pciconf -lcvb -- none6@pci0:1:0:0: class=0x010700 card=0x1f1d1028 chip=0x00721000 rev=0x02 hdr=0x00 vendor = 'LSI Logic (Was: Symbios Logic, NCR)' class = mass storage subclass = SAS bar [10] = type I/O Port, range 32, base 0xfc00, size 256, enabled bar [14] = type Memory, range 64, base 0xdf2b0000, size 65536, enabled bar [1c] = type Memory, range 64, base 0xdf2c0000, size 262144, enabled cap 01[50] = powerspec 3 supports D0 D1 D2 D3 current D0 cap 10[68] = PCI-Express 2 endpoint max data 256(4096) link x8(x8) cap 03[d0] = VPD cap 05[a8] = MSI supports 1 message, 64 bit cap 11[c0] = MSI-X supports 15 messages in map 0x14 -- I have added the following to /usr/src/sys/dev/mfi/mfi_pci.c at line 119: -- {0x1000, 0x0072, 0x1028, 0x1f1e, MFI_FLAGS_GEN2, "Dell PERC H200 Integrated"}, -- Rebuilt the kernel, tried it on the server, still no luck recognizing the RAID card. As a last resort I'll be setting the drives to passthrough and using a software RAID, but I'd much rather this worked out. Note that mfi actually recognizes Dell's h700 and h800 cards. Anyone managed to get the h200 card working yet ? @hackers: please keep me cc'd, I'm not subscribed to this list. Regards, -- dfl From owner-freebsd-stable@FreeBSD.ORG Sat Jan 29 17:26:16 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 92558106564A for ; Sat, 29 Jan 2011 17:26:16 +0000 (UTC) (envelope-from jhelfman@experts-exchange.com) Received: from mail.experts-exchange.com (mail.experts-exchange.com [72.29.183.251]) by mx1.freebsd.org (Postfix) with ESMTP id 6E35F8FC16 for ; Sat, 29 Jan 2011 17:26:16 +0000 (UTC) Received: from mail.experts-exchange.com (localhost [127.0.0.1]) by mail.experts-exchange.com (Postfix) with ESMTP id 288F51DE8D00; Sat, 29 Jan 2011 09:26:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d= experts-exchange.com; h=content-transfer-encoding:content-type :content-type:mime-version:user-agent:from:from:subject:subject :date:date:references:in-reply-to:message-id:received:received :received; s=ee; t=1296321976; x=1298136376; bh=Uc+ATltU541tlnNk oJbfMXG5rcq2efexJb+LoCiV6+A=; b=E3YtswSdSfUvChC8hT7kHSlQWna8RdIw EFP4rkm17Q2CMyxnES7RNh1uvjBQ/HrYnPiV6qh0puSB9Di8wEEWt2gX9DfdBpla BCuOWf++MkKGgmWl6DW0wuarOjM0xEefLnFAVhLSSN0j7DfTMCG7G+L+ERrDyoBW gdv8627tIm4= X-Virus-Scanned: amavisd-new at experts-exchange.com Received: from mail.experts-exchange.com ([127.0.0.1]) by mail.experts-exchange.com (mail.experts-exchange.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q1e7B1fiDPHg; Sat, 29 Jan 2011 09:26:16 -0800 (PST) Received: from mail.experts-exchange.com (localhost [127.0.0.1]) by mail.experts-exchange.com (Postfix) with ESMTP id DDC621DE8D01; Sat, 29 Jan 2011 09:26:15 -0800 (PST) Received: from 76.209.222.14 (SquirrelMail authenticated user jhelfman) by mail.experts-exchange.com with HTTP; Sat, 29 Jan 2011 09:26:15 -0800 Message-ID: <201e000932a85037838dde4d13f6e2dc.squirrel@mail.experts-exchange.com> In-Reply-To: References: Date: Sat, 29 Jan 2011 09:26:15 -0800 From: jhelfman@experts-exchange.com To: "Damien Fleuriot" User-Agent: SquirrelMail/1.4.20 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: freebsd-hackers@freebsd.org, freebsd-stable@freebsd.org Subject: Re: KERN - mfi driver for Dell raid h200 on r210 servers X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Jan 2011 17:26:16 -0000 > Hello lists, > > > > I'm trying to get FreeBSD 8.0 or 8.1 to run on a Dell poweredge r210 > server. > > It ships with a SATA/SAS h200 RAID controller. > > > Sadly, the MFI driver doesn't seem to register for this card... > > > Find below the pciconf -lcvb > > -- > none6@pci0:1:0:0: class=0x010700 card=0x1f1d1028 chip=0x00721000 > rev=0x02 hdr=0x00 > vendor = 'LSI Logic (Was: Symbios Logic, NCR)' > class = mass storage > subclass = SAS > bar [10] = type I/O Port, range 32, base 0xfc00, size 256, enabled > bar [14] = type Memory, range 64, base 0xdf2b0000, size 65536, > enabled > bar [1c] = type Memory, range 64, base 0xdf2c0000, size 262144, > enabled > cap 01[50] = powerspec 3 supports D0 D1 D2 D3 current D0 > cap 10[68] = PCI-Express 2 endpoint max data 256(4096) link x8(x8) > cap 03[d0] = VPD > cap 05[a8] = MSI supports 1 message, 64 bit > cap 11[c0] = MSI-X supports 15 messages in map 0x14 > -- > > > I have added the following to /usr/src/sys/dev/mfi/mfi_pci.c at line 119: > -- > {0x1000, 0x0072, 0x1028, 0x1f1e, MFI_FLAGS_GEN2, "Dell PERC H200 > Integrated"}, > -- > > > Rebuilt the kernel, tried it on the server, still no luck recognizing > the RAID card. > > As a last resort I'll be setting the drives to passthrough and using a > software RAID, but I'd much rather this worked out. > > Note that mfi actually recognizes Dell's h700 and h800 cards. > > > > > Anyone managed to get the h200 card working yet ? > > > > > @hackers: please keep me cc'd, I'm not subscribed to this list. > > > > Regards, > > -- > dfl > _______________________________________________ Hi Damien, I would suspect that you would need to compile the 'mpt' driver to get this to work. I found the same issue in the r310, however I already had mpt compiled in my kernel for another hardware platform. Good Luck! Jason From owner-freebsd-stable@FreeBSD.ORG Sat Jan 29 18:15:21 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 093EC1065672; Sat, 29 Jan 2011 18:15:21 +0000 (UTC) (envelope-from jhelfman@e-e.com) Received: from mail.experts-exchange.com (mail.experts-exchange.com [72.29.183.251]) by mx1.freebsd.org (Postfix) with ESMTP id D98458FC0A; Sat, 29 Jan 2011 18:15:20 +0000 (UTC) Received: from mail.experts-exchange.com (localhost [127.0.0.1]) by mail.experts-exchange.com (Postfix) with ESMTP id DDD6A1DE8D21; Sat, 29 Jan 2011 10:00:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=e-e.com; h= content-transfer-encoding:content-type:content-type:mime-version :user-agent:from:from:subject:subject:date:date:references :in-reply-to:message-id:received:received:received; s=ee; t= 1296324012; x=1298138412; bh=ugNVhmCnGcvtt5LzkVhmJBgkRsro2ajAw7e yO9nkvxA=; b=JiZc1Nq1V2zrtV5eNd2DAAy3IDGC/Nbzmt1jCSByJ6HpafTnL5T s7z3TUY9E7zIR6YmUQb43mOKMVAaJtD+v6fhap1gHhsEapdJm7EXQm8DKdjHgUuJ opvp1lTUVgTgyTpB7usb/E/ahfTOwTwQ1SB+D6vREXuKOfIH4EAZhUxQ= X-Virus-Scanned: amavisd-new at experts-exchange.com Received: from mail.experts-exchange.com ([127.0.0.1]) by mail.experts-exchange.com (mail.experts-exchange.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i1ycnmm63HZF; Sat, 29 Jan 2011 10:00:12 -0800 (PST) Received: from mail.experts-exchange.com (localhost [127.0.0.1]) by mail.experts-exchange.com (Postfix) with ESMTP id 9D9A11DE8D16; Sat, 29 Jan 2011 10:00:12 -0800 (PST) Received: from 76.209.222.14 (SquirrelMail authenticated user jhelfman) by mail.experts-exchange.com with HTTP; Sat, 29 Jan 2011 10:00:12 -0800 Message-ID: <74e2d52b6ce67708a1bb42955b6370fb.squirrel@mail.experts-exchange.com> In-Reply-To: References: Date: Sat, 29 Jan 2011 10:00:12 -0800 From: jhelfman@e-e.com To: "Damien Fleuriot" User-Agent: SquirrelMail/1.4.20 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: freebsd-hackers@freebsd.org, freebsd-stable@freebsd.org Subject: Re: KERN - mfi driver for Dell raid h200 on r210 servers X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Jan 2011 18:15:21 -0000 > Hello lists, > > > > I'm trying to get FreeBSD 8.0 or 8.1 to run on a Dell poweredge r210 > server. > > It ships with a SATA/SAS h200 RAID controller. > > > Sadly, the MFI driver doesn't seem to register for this card... > > > Find below the pciconf -lcvb > > -- > none6@pci0:1:0:0: class=0x010700 card=0x1f1d1028 chip=0x00721000 > rev=0x02 hdr=0x00 > vendor = 'LSI Logic (Was: Symbios Logic, NCR)' > class = mass storage > subclass = SAS > bar [10] = type I/O Port, range 32, base 0xfc00, size 256, enabled > bar [14] = type Memory, range 64, base 0xdf2b0000, size 65536, > enabled > bar [1c] = type Memory, range 64, base 0xdf2c0000, size 262144, > enabled > cap 01[50] = powerspec 3 supports D0 D1 D2 D3 current D0 > cap 10[68] = PCI-Express 2 endpoint max data 256(4096) link x8(x8) > cap 03[d0] = VPD > cap 05[a8] = MSI supports 1 message, 64 bit > cap 11[c0] = MSI-X supports 15 messages in map 0x14 > -- > > > I have added the following to /usr/src/sys/dev/mfi/mfi_pci.c at line 119: > -- > {0x1000, 0x0072, 0x1028, 0x1f1e, MFI_FLAGS_GEN2, "Dell PERC H200 > Integrated"}, > -- > > > Rebuilt the kernel, tried it on the server, still no luck recognizing > the RAID card. > > As a last resort I'll be setting the drives to passthrough and using a > software RAID, but I'd much rather this worked out. > > Note that mfi actually recognizes Dell's h700 and h800 cards. > > > > > Anyone managed to get the h200 card working yet ? > > > > > @hackers: please keep me cc'd, I'm not subscribed to this list. > > > > Regards, > > -- > dfl > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > > Hi Damien, I would suspect that you would need to compile the 'mpt' driver to get this to work. I found the same issue in the r310, however I already had mpt compiled in my kernel for another hardware platform. Good Luck! Jason From owner-freebsd-stable@FreeBSD.ORG Sat Jan 29 19:26:19 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DECCD106564A for ; Sat, 29 Jan 2011 19:26:19 +0000 (UTC) (envelope-from andy@fud.org.nz) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 82ACA8FC08 for ; Sat, 29 Jan 2011 19:26:18 +0000 (UTC) Received: by wwf26 with SMTP id 26so4296834wwf.31 for ; Sat, 29 Jan 2011 11:26:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.227.128.82 with SMTP id j18mr4332696wbs.138.1296329178050; Sat, 29 Jan 2011 11:26:18 -0800 (PST) Sender: andy@fud.org.nz Received: by 10.227.156.149 with HTTP; Sat, 29 Jan 2011 11:26:18 -0800 (PST) In-Reply-To: References: Date: Sun, 30 Jan 2011 08:26:18 +1300 X-Google-Sender-Auth: 9nrRBfE_NtE4SscBE4kn7VsfNbo Message-ID: From: Andrew Thompson To: Damien Fleuriot Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org, freebsd-stable@freebsd.org Subject: Re: KERN - mfi driver for Dell raid h200 on r210 servers X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Jan 2011 19:26:19 -0000 On 30 January 2011 06:20, Damien Fleuriot wrote: > Hello lists, > > > > I'm trying to get FreeBSD 8.0 or 8.1 to run on a Dell poweredge r210 server. > > It ships with a SATA/SAS h200 RAID controller. > This card may need the mps(4) driver which is only in HEAD at the moment. Andrew From owner-freebsd-stable@FreeBSD.ORG Sat Jan 29 22:25:08 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 80DBB106566C; Sat, 29 Jan 2011 22:25:08 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [IPv6:2001:4068:10::3]) by mx1.freebsd.org (Postfix) with ESMTP id 137DB8FC0C; Sat, 29 Jan 2011 22:25:08 +0000 (UTC) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id 16A0241C65E; Sat, 29 Jan 2011 23:25:07 +0100 (CET) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([192.168.74.103]) by localhost (amavis.fra.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id nZwaXOgphtGP; Sat, 29 Jan 2011 23:25:06 +0100 (CET) Received: by mail.cksoft.de (Postfix, from userid 66) id 0833041C677; Sat, 29 Jan 2011 23:25:06 +0100 (CET) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 45E4B4448F3; Sat, 29 Jan 2011 22:24:56 +0000 (UTC) Date: Sat, 29 Jan 2011 22:24:56 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Damien Fleuriot In-Reply-To: Message-ID: <20110129222400.R39951@maildrop.int.zabbadoz.net> References: X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-hackers@freebsd.org, freebsd-stable@freebsd.org Subject: Re: KERN - mfi driver for Dell raid h200 on r210 servers X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Jan 2011 22:25:08 -0000 On Sat, 29 Jan 2011, Damien Fleuriot wrote: > Hello lists, > > > > I'm trying to get FreeBSD 8.0 or 8.1 to run on a Dell poweredge r210 server. > > It ships with a SATA/SAS h200 RAID controller. > > > Sadly, the MFI driver doesn't seem to register for this card... > > > Find below the pciconf -lcvb > > -- > none6@pci0:1:0:0: class=0x010700 card=0x1f1d1028 chip=0x00721000 > rev=0x02 hdr=0x00 > vendor = 'LSI Logic (Was: Symbios Logic, NCR)' > class = mass storage > subclass = SAS > bar [10] = type I/O Port, range 32, base 0xfc00, size 256, enabled > bar [14] = type Memory, range 64, base 0xdf2b0000, size 65536, enabled > bar [1c] = type Memory, range 64, base 0xdf2c0000, size 262144, enabled > cap 01[50] = powerspec 3 supports D0 D1 D2 D3 current D0 > cap 10[68] = PCI-Express 2 endpoint max data 256(4096) link x8(x8) > cap 03[d0] = VPD > cap 05[a8] = MSI supports 1 message, 64 bit > cap 11[c0] = MSI-X supports 15 messages in map 0x14 > -- > > > I have added the following to /usr/src/sys/dev/mfi/mfi_pci.c at line 119: > -- > {0x1000, 0x0072, 0x1028, 0x1f1e, MFI_FLAGS_GEN2, "Dell PERC H200 Integrated"}, > -- It's 1f1d not 1f1e. I hope it was only a paste problem into email? > > Rebuilt the kernel, tried it on the server, still no luck recognizing > the RAID card. > > As a last resort I'll be setting the drives to passthrough and using a > software RAID, but I'd much rather this worked out. > > Note that mfi actually recognizes Dell's h700 and h800 cards. > > > > > Anyone managed to get the h200 card working yet ? > > > > > @hackers: please keep me cc'd, I'm not subscribed to this list. > > > > Regards, > > -- > dfl > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > -- Bjoern A. Zeeb You have to have visions! Going to jail sucks -- All my daemons like it! http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/jails.html From owner-freebsd-stable@FreeBSD.ORG Sat Jan 29 23:45:21 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C97BD10657E9 for ; Sat, 29 Jan 2011 23:45:21 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id C6F728FC13 for ; Sat, 29 Jan 2011 23:45:20 +0000 (UTC) Received: by wyf19 with SMTP id 19so4556868wyf.13 for ; Sat, 29 Jan 2011 15:45:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=JaO5Kz+/HHiSb1sbUsZmtzx1WLGg8aXrp54NgDjNczE=; b=FJz2ihJtHhnkBx/qRiRyldehHbe9ysa12NpWKjfiNw3B/RpnUeXP9VmA04JzdqgxOc KL3s7ewcDi86BwgB7sD6uArdUZfRbHy7SHswFJ+86qBWitem2WPEelXorrWELbg73hYI G3XH6db5ZN302rqlyzzWMyEZ5YuASB1EixxpI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=SyWD/5BWrB2BTucAgWrvtXC7iyBgjowUXKzhltyEfUgUteYBZ9vJvcgWit9S5vtpJ1 FGVTblWZsfUxuA8mdR9mmBIxECts1x8RSBae/AXZSw+D5UGmp4B3FPhvRezOVlw39yal BH+Uy/7SXFY7RCs2VhYMwwQJuR2M6XSBOuiNg= MIME-Version: 1.0 Received: by 10.216.220.219 with SMTP id o69mr4649469wep.57.1296343166565; Sat, 29 Jan 2011 15:19:26 -0800 (PST) Sender: yanegomi@gmail.com Received: by 10.216.71.200 with HTTP; Sat, 29 Jan 2011 15:19:26 -0800 (PST) In-Reply-To: <20110129222400.R39951@maildrop.int.zabbadoz.net> References: <20110129222400.R39951@maildrop.int.zabbadoz.net> Date: Sat, 29 Jan 2011 15:19:26 -0800 X-Google-Sender-Auth: so6EqY1CeKrE4HqV9BbnNajFT0Q Message-ID: From: Garrett Cooper To: "Bjoern A. Zeeb" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org, freebsd-stable@freebsd.org Subject: Re: KERN - mfi driver for Dell raid h200 on r210 servers X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Jan 2011 23:45:21 -0000 On Sat, Jan 29, 2011 at 2:24 PM, Bjoern A. Zeeb wrote: > On Sat, 29 Jan 2011, Damien Fleuriot wrote: > >> Hello lists, >> >> >> >> I'm trying to get FreeBSD 8.0 or 8.1 to run on a Dell poweredge r210 >> server. >> >> It ships with a SATA/SAS h200 RAID controller. >> >> >> Sadly, the MFI driver doesn't seem to register for this card... >> >> >> Find below the pciconf -lcvb >> >> -- >> none6@pci0:1:0:0: =A0 =A0 =A0 class=3D0x010700 card=3D0x1f1d1028 chip=3D= 0x00721000 >> rev=3D0x02 hdr=3D0x00 >> =A0 vendor =A0 =A0 =3D 'LSI Logic (Was: Symbios Logic, NCR)' >> =A0 class =A0 =A0 =A0=3D mass storage >> =A0 subclass =A0 =3D SAS >> =A0 bar =A0 [10] =3D type I/O Port, range 32, base 0xfc00, size 256, ena= bled >> =A0 bar =A0 [14] =3D type Memory, range 64, base 0xdf2b0000, size 65536,= enabled >> =A0 bar =A0 [1c] =3D type Memory, range 64, base 0xdf2c0000, size 262144= , >> enabled >> =A0 cap 01[50] =3D powerspec 3 =A0supports D0 D1 D2 D3 =A0current D0 >> =A0 cap 10[68] =3D PCI-Express 2 endpoint max data 256(4096) link x8(x8) >> =A0 cap 03[d0] =3D VPD >> =A0 cap 05[a8] =3D MSI supports 1 message, 64 bit >> =A0 cap 11[c0] =3D MSI-X supports 15 messages in map 0x14 >> -- >> >> >> I have added the following to /usr/src/sys/dev/mfi/mfi_pci.c at line 119= : >> -- >> {0x1000, 0x0072, 0x1028, 0x1f1e, MFI_FLAGS_GEN2, =A0"Dell PERC H200 >> Integrated"}, >> -- > > It's 1f1d not 1f1e. =A0I hope it was only a paste problem into email? +1. PERC7 should be supported by mfi(4) (required bits may need to be added to mfi(4) though as you've pointed out, but additional details may need to be obtained from Dell). Thanks, -Garrett