From owner-freebsd-stable@FreeBSD.ORG Sun Oct 21 04:17:53 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 41A78F77; Sun, 21 Oct 2012 04:17:53 +0000 (UTC) (envelope-from takeda@takeda.tk) Received: from chinatsu.takeda.tk (mail.takeda.tk [74.0.89.210]) by mx1.freebsd.org (Postfix) with ESMTP id 0D8938FC0A; Sun, 21 Oct 2012 04:17:52 +0000 (UTC) Received: from takeda-ws.lan (takeda-ws.lan [10.0.0.3]) (authenticated bits=0) by chinatsu.takeda.tk (8.14.5/8.14.5) with ESMTP id q9L4Hkfm004186 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Sat, 20 Oct 2012 21:17:46 -0700 (PDT) (envelope-from takeda@takeda.tk) Date: Sat, 20 Oct 2012 21:17:40 -0700 From: Derek Kulinski X-Priority: 3 (Normal) Message-ID: <44148675.20121020211740@takeda.tk> To: Andriy Gapon Subject: Re: Problem reading vitals from Gigabyte H77-DH3H In-Reply-To: <50832112.7050604@FreeBSD.org> References: <1286515493.20121017131543@takeda.tk> <507F1761.1010202@FreeBSD.org> <20121017205147.GB36106@chinatsu.takeda.tk> <5081552F.2050303@FreeBSD.org> <771658188.20121019205010@takeda.tk> <508254AF.7040709@FreeBSD.org> <994545137.20121020010809@takeda.tk> <50826040.6010106@FreeBSD.org> <55342693.20121020103732@takeda.tk> <5082EEC8.2080307@FreeBSD.org> <198684285.20121020122034@takeda.tk> <5082FEA8.3050600@FreeBSD.org> <508304E6.6020202@FreeBSD.org> <1183222788.20121020141700@takeda.tk> <50832112.7050604@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Cc: freebsd-stable@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 21 Oct 2012 04:17:53 -0000 Hello Andriy, Saturday, October 20, 2012, 3:09:22 PM, you wrote: >> Looks like the the temperatures are messed up. Looks like 2 last >> voltage values is the temperature. > Oops, right. I've updated the patch at the same URL. Seems like it is still wrong: hw.sensors.it0.fan0: 1005 RPM hw.sensors.it0.fan1: invalid hw.sensors.it0.fan2: 1300 RPM hw.sensors.it0.fan3: 1157 RPM hw.sensors.it0.fan4: invalid hw.sensors.it0.volt0: 1,42 VDC (VCORE_A) hw.sensors.it0.volt1: 2,72 VDC (VCORE_B) hw.sensors.it0.volt2: 2,70 VDC (+3.3V) hw.sensors.it0.volt3: 4,60 VDC (+5V) hw.sensors.it0.volt4: 0,06 VDC (+12V) hw.sensors.it0.volt5: -5,08 VDC (Unused) hw.sensors.it0.volt6: -6,53 VDC (-12V) hw.sensors.it0.volt7: 3,74 VDC (+5VSB) hw.sensors.it0.volt8: 2,14 VDC (VBAT) hw.sensors.it0.temp0: -271,73 degC hw.sensors.it0.temp1: -270,43 degC hw.sensors.it0.temp2: -270,45 degC > Unfortunately, I don't have familiarity with Linux distros either... Will look try something. -- Best regards, Derek mailto:takeda@takeda.tk -- Backup not found: (A)bort (R)etry (T)hrowup From owner-freebsd-stable@FreeBSD.ORG Sun Oct 21 07:11:03 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 19889F10; Sun, 21 Oct 2012 07:11:03 +0000 (UTC) (envelope-from swhetzel@gmail.com) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 69F958FC08; Sun, 21 Oct 2012 07:11:01 +0000 (UTC) Received: by mail-wg0-f50.google.com with SMTP id 16so1400373wgi.31 for ; Sun, 21 Oct 2012 00:11:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=7Dn0BKNvbMJnNRDEnghqyqIDg19NslCf4hI7E/BVmVM=; b=qNEKBd183BY4CA+ehyoOyYCVWHDFTUDEdtIlXalEiz4PsxtUNaU/iM9M42de9sR3Q3 3wMF+I3JsJYUMg72lZaFWYa60YcgByYwoIf63ktEdbJsuWd1PRQX7G7AgyXz0YTP8VVW RSHac0VTrKcpEpZzJRp0kBpfQLPaY0oaug3sYofJUaDoxl3eLrojejSBG92RtUn6QPU/ Ae5OaZX2EbWH8/EQwJEWdGdyMczyV5U0u50Bn/yyzMc2WBFBR0MSoEzuRfKWiR8IWMO5 UEGo9hp7Ce77x79B6wKeG6OcHGaouv/F7m2R+QiXV+pND4pj7klctrtxPKaX5lgtNQJa QJcw== MIME-Version: 1.0 Received: by 10.180.80.33 with SMTP id o1mr13319727wix.14.1350803460736; Sun, 21 Oct 2012 00:11:00 -0700 (PDT) Received: by 10.223.87.2 with HTTP; Sun, 21 Oct 2012 00:11:00 -0700 (PDT) In-Reply-To: <508304E6.6020202@FreeBSD.org> References: <1286515493.20121017131543@takeda.tk> <507F1761.1010202@FreeBSD.org> <20121017205147.GB36106@chinatsu.takeda.tk> <5081552F.2050303@FreeBSD.org> <771658188.20121019205010@takeda.tk> <508254AF.7040709@FreeBSD.org> <994545137.20121020010809@takeda.tk> <50826040.6010106@FreeBSD.org> <55342693.20121020103732@takeda.tk> <5082EEC8.2080307@FreeBSD.org> <198684285.20121020122034@takeda.tk> <5082FEA8.3050600@FreeBSD.org> <508304E6.6020202@FreeBSD.org> Date: Sun, 21 Oct 2012 02:11:00 -0500 Message-ID: Subject: Re: Problem reading vitals from Gigabyte H77-DH3H From: Scot Hetzel To: Andriy Gapon Content-Type: text/plain; charset=ISO-8859-1 Cc: Derek Kulinski , freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 21 Oct 2012 07:11:03 -0000 On Sat, Oct 20, 2012 at 3:09 PM, Andriy Gapon wrote: > on 20/10/2012 22:42 Andriy Gapon said the following: >> on 20/10/2012 22:20 Derek Kulinski said the following: >>> I have three questions though: >>> 1. The motherboard has 4 fan sockets (as far as I can tell), CPU_FAN, >>> and SYS_FAN[1-3]. SYS_FAN1 currently is not connected. >>> Seems like: >>> fan0 -> CPU_FAN (did not try to disconnect it to check :) >>> fan1 -> SYS_FAN1 >>> fan2 -> SYS_FAN2 >>> There is no entry for SYS_FAN3. I disconnected it temporarily but >>> it did not seem to affect the output. Is it possible to get that >>> information from the motherboard? >> >> The driver would have to be updated for that. >> Unfortunately ITE does not provide public datasheets. >> We could pick up some new bits from the Linux driver though. >> http://lxr.linux.no/#linux+v3.6.2/drivers/hwmon/it87.c > > In fact, here is a completely untested patch: > http://people.freebsd.org/~avg/it-fans-0x80.diff > @@ -354,12 +372,15 @@ static void it_refresh_sensor_data(struct it_softc *sc) { /* Refresh our stored data for every sensor */ - it_generic_stemp(sc, &sc->sensors[12]); - it_generic_svolt(sc, &sc->sensors[3]); - if (sc->fan16bit) + if (sc->fan16bit) { it_16bit_fanrpm(sc, &sc->sensors[0]); - else + it_generic_svolt(sc, &sc->sensors[5]); + it_generic_svolt(sc, &sc->sensors[14]); <- Looks to be a copy/paste bug ;-) + } else { it_generic_fanrpm(sc, &sc->sensors[0]); + it_generic_svolt(sc, &sc->sensors[3]); + it_generic_stemp(sc, &sc->sensors[12]); + } } From owner-freebsd-stable@FreeBSD.ORG Sun Oct 21 08:54:01 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 37B1437A for ; Sun, 21 Oct 2012 08:54:01 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 773018FC0A for ; Sun, 21 Oct 2012 08:53:59 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id LAA14981; Sun, 21 Oct 2012 11:53:54 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1TPrI9-000CXD-It; Sun, 21 Oct 2012 11:53:53 +0300 Message-ID: <5083B81F.2080909@FreeBSD.org> Date: Sun, 21 Oct 2012 11:53:51 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:16.0) Gecko/20121013 Thunderbird/16.0.1 MIME-Version: 1.0 To: Scot Hetzel Subject: Re: Problem reading vitals from Gigabyte H77-DH3H References: <1286515493.20121017131543@takeda.tk> <507F1761.1010202@FreeBSD.org> <20121017205147.GB36106@chinatsu.takeda.tk> <5081552F.2050303@FreeBSD.org> <771658188.20121019205010@takeda.tk> <508254AF.7040709@FreeBSD.org> <994545137.20121020010809@takeda.tk> <50826040.6010106@FreeBSD.org> <55342693.20121020103732@takeda.tk> <5082EEC8.2080307@FreeBSD.org> <198684285.20121020122034@takeda.tk> <5082FEA8.3050600@FreeBSD.org> <508304E6.6020202@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Derek Kulinski , freebsd-stable@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 21 Oct 2012 08:54:01 -0000 on 21/10/2012 10:11 Scot Hetzel said the following: > On Sat, Oct 20, 2012 at 3:09 PM, Andriy Gapon wrote: >> on 20/10/2012 22:42 Andriy Gapon said the following: >>> on 20/10/2012 22:20 Derek Kulinski said the following: >>>> I have three questions though: >>>> 1. The motherboard has 4 fan sockets (as far as I can tell), CPU_FAN, >>>> and SYS_FAN[1-3]. SYS_FAN1 currently is not connected. >>>> Seems like: >>>> fan0 -> CPU_FAN (did not try to disconnect it to check :) >>>> fan1 -> SYS_FAN1 >>>> fan2 -> SYS_FAN2 >>>> There is no entry for SYS_FAN3. I disconnected it temporarily but >>>> it did not seem to affect the output. Is it possible to get that >>>> information from the motherboard? >>> >>> The driver would have to be updated for that. >>> Unfortunately ITE does not provide public datasheets. >>> We could pick up some new bits from the Linux driver though. >>> http://lxr.linux.no/#linux+v3.6.2/drivers/hwmon/it87.c >> >> In fact, here is a completely untested patch: >> http://people.freebsd.org/~avg/it-fans-0x80.diff >> > > @@ -354,12 +372,15 @@ static void > it_refresh_sensor_data(struct it_softc *sc) > { > /* Refresh our stored data for every sensor */ > - it_generic_stemp(sc, &sc->sensors[12]); > - it_generic_svolt(sc, &sc->sensors[3]); > - if (sc->fan16bit) > + if (sc->fan16bit) { > it_16bit_fanrpm(sc, &sc->sensors[0]); > - else > + it_generic_svolt(sc, &sc->sensors[5]); > + it_generic_svolt(sc, &sc->sensors[14]); <- Looks to be a copy/paste bug ;-) Indeed. Should be "stemp" of course. Thank you! > + } else { > it_generic_fanrpm(sc, &sc->sensors[0]); > + it_generic_svolt(sc, &sc->sensors[3]); > + it_generic_stemp(sc, &sc->sensors[12]); > + } > } > -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Sun Oct 21 09:11:00 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DB48DB4E for ; Sun, 21 Oct 2012 09:11:00 +0000 (UTC) (envelope-from mueller23@insightbb.com) Received: from mail.insightbb.com (smtp1.insight.synacor.com [208.47.185.23]) by mx1.freebsd.org (Postfix) with ESMTP id 981F08FC0A for ; Sun, 21 Oct 2012 09:10:59 +0000 (UTC) X_CMAE_Category: 0,0 Undefined,Undefined X-CNFS-Analysis: v=2.0 cv=f43K9ZOM c=1 sm=0 a=Dm9TOXL4taQ+Gy1KovpL+A==:17 a=jLN7EqiLvroA:10 a=9YQ-1ebCAAAA:8 a=Hz0Dtrm5_sgA:10 a=ST0XkMQ9GubENzj--dQA:9 a=Dm9TOXL4taQ+Gy1KovpL+A==:117 X-CM-Score: 0 X-Scanned-by: Cloudmark Authority Engine Authentication-Results: smtp01.insight.synacor.com header.from=mueller23@insightbb.com; sender-id=softfail Authentication-Results: smtp01.insight.synacor.com smtp.mail=mueller23@insightbb.com; spf=softfail; sender-id=softfail Received-SPF: softfail (smtp01.insight.synacor.com: transitional domain insightbb.com does not designate 74.130.198.7 as permitted sender) Received: from [74.130.198.7] ([74.130.198.7:43902] helo=localhost) by mail.insightbb.com (envelope-from ) (ecelerity 2.2.3.49 r(42060/42061)) with ESMTP id 19/B4-17144-D1CB3805; Sun, 21 Oct 2012 05:10:53 -0400 Date: Sun, 21 Oct 2012 05:10:53 -0400 Message-ID: <19.B4.17144.D1CB3805@smtp01.insight.synacor.com> From: "Thomas Mueller" To: freebsd-stable@freebsd.org Subject: Re: 9.1 and intel graphics X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 21 Oct 2012 09:11:01 -0000 Normally I start X by startx which may be followed by an initialization file, so I don't get the default spartan default twm all the time. In Linux and FreeBSD, I generally use X as nonroot. So I don't really know how to start a program such as xterm as another user or how to have both root and nonroot windows in X. On trying to exit X with the KMS driver in FreeBSD, I never got that far, however I'm having snags in updating my ports, am at an impasse now, got Error 70 in the latest case and don't know what that means. But I have experience typing in the dark in NetBSD, not all X-related, and have successfully typed "shutdown -r now" with nothing showing on the screen. Tom From owner-freebsd-stable@FreeBSD.ORG Sun Oct 21 12:14:08 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4BD9F900 for ; Sun, 21 Oct 2012 12:14: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 D5F868FC08 for ; Sun, 21 Oct 2012 12:14:07 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q9LCE8G4090657; Sun, 21 Oct 2012 15:14:08 +0300 (EEST) (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.5/8.14.5) with ESMTP id q9LCDu78032654; Sun, 21 Oct 2012 15:13:56 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q9LCDuPd032652; Sun, 21 Oct 2012 15:13:56 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 21 Oct 2012 15:13:56 +0300 From: Konstantin Belousov To: David Wolfskill Subject: Re: stable/9 @r241776 panic: REDZONE: Buffer underflow detected... Message-ID: <20121021121356.GJ35915@deviant.kiev.zoral.com.ua> References: <20121020141019.GW1817@albert.catwhisker.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="oKQo6H1tQBaoPMj5" Content-Disposition: inline In-Reply-To: <20121020141019.GW1817@albert.catwhisker.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham 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 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 21 Oct 2012 12:14:08 -0000 --oKQo6H1tQBaoPMj5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Oct 20, 2012 at 07:10:19AM -0700, David Wolfskill wrote: > This seems ... fairly weird to me. >=20 > Yesterday, I built & booted: >=20 > FreeBSD g1-227.catwhisker.org 9.1-PRERELEASE FreeBSD 9.1-PRERELEASE #274 = 241726M: Fri Oct 19 05:40:05 PDT 2012 root@g1-227.catwhisker.org:/usr/o= bj/usr/src/sys/CANARY i386 >=20 > and used the machine all day; nothing unusual (including various > reboots (e.g. when I disembarked the train for the final leg of my > commute home, so I powered the laptop off). >=20 > This morning, I built: >=20 > FreeBSD g1-227.catwhisker.org 9.1-PRERELEASE FreeBSD 9.1-PRERELEASE #275 = 241776M: Sat Oct 20 04:34:45 PDT 2012 root@g1-227.catwhisker.org:/usr/o= bj/usr/src/sys/CANARY i386 >=20 > and on first reboot, I got a panic. >=20 > After a bit of experimentation, it appears that I get a panic @r241776 > if I attempt a normal boot into multi-user mode, but if I first boot to > single-user mode, then exit single-user mode, it comes up without a > problem. >=20 > I don't have a serial console, so I started to write down some of the > panic information, but my patience ran a bit short. Here's whet I > recorded (warning: hand-transcripted -- twice!): >=20 > ... > Starting devd. > REDZONE: Buffer underflow detected. 1 byte corrupted before 0xced40080 (= 4294966796 bytes allocated). > Allocation backtrace: > #0 0xc0ceac8f at redzone_setup+0xcf > #1 0xc0a5d5c9 at malloc+0x1d9 > ...[about 20 more such lines I didn't record]... >=20 > > bt > Tracing pid 901 tid 100106 td 0xd2b99000 > kdb_enter(...) > panic(...) > free(...) > devread(ce8c2d00,f7274c0c,0,c0b1e4f0,d279e380,...) at devread+0x1a6 > giant_read(...) at giant_read+0x87 > devfs_read(...) at devfs_read+0xc6 > dofileread(...) at dofileread+0x99 > sys_read(...) at sys_read+0x98 > syscall(f7274d08) at syscall+0x387 >=20 > Within the bounds described above, this appears to be quite reproducible > -- on my laptop. My build machine (updated in parallel, at the same > GRNs) does not exhibit the panic. >=20 > I was unable to get a crash dump; I have >=20 > dumpdev=3D"AUTO" >=20 > in /etc/rc.conf, and the panic was occurring well after swap was > enabled. (Yes, I know I have swap over-allocated. I plan to do > something about it at some point.) >=20 > I've attached a copy of dmesg.boot. >=20 > Anyone else seeing this? Any ideas how to diagnose it? devread is the method of devctl(4) which passes devd notifications from the kernel to userland (to devd, specifically). There were no changes to devctl(4) for quite a time. The corruption is, most likely, in some unrelated piece of code. Could you try to bisect the stable to catch the offender ? The bisect is not guaranteed to work, obviously, since the random corruption effects are unpredictable. --oKQo6H1tQBaoPMj5 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAlCD5wMACgkQC3+MBN1Mb4hYTQCfXTxexn6qLhv3U/5jttWNkMuh mO8AoKLn8GJLomWs4Zqg0YpmPYIpQSAt =cp/P -----END PGP SIGNATURE----- --oKQo6H1tQBaoPMj5-- From owner-freebsd-stable@FreeBSD.ORG Sun Oct 21 12:24:43 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F004C14B for ; Sun, 21 Oct 2012 12:24:43 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (m209-73.dsl.rawbw.com [198.144.209.73]) by mx1.freebsd.org (Postfix) with ESMTP id A3D648FC12 for ; Sun, 21 Oct 2012 12:24:43 +0000 (UTC) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.5/8.14.5) with ESMTP id q9LCObSo039359; Sun, 21 Oct 2012 05:24:37 -0700 (PDT) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.5/8.14.5/Submit) id q9LCObQM039358; Sun, 21 Oct 2012 05:24:37 -0700 (PDT) (envelope-from david) Date: Sun, 21 Oct 2012 05:24:37 -0700 From: David Wolfskill To: Konstantin Belousov Subject: Re: stable/9 @r241776 panic: REDZONE: Buffer underflow detected... Message-ID: <20121021122437.GE1817@albert.catwhisker.org> References: <20121020141019.GW1817@albert.catwhisker.org> <20121021121356.GJ35915@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="GkyPMzQoklWKZOV/" Content-Disposition: inline In-Reply-To: <20121021121356.GJ35915@deviant.kiev.zoral.com.ua> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 21 Oct 2012 12:24:44 -0000 --GkyPMzQoklWKZOV/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Oct 21, 2012 at 03:13:56PM +0300, Konstantin Belousov wrote: > ... > > Anyone else seeing this? Any ideas how to diagnose it? >=20 > devread is the method of devctl(4) which passes devd notifications from > the kernel to userland (to devd, specifically). There were no changes to > devctl(4) for quite a time. I noticed that none of the changes in the last update seemed at all relevant, yes. And thank you for the background (devread()). > The corruption is, most likely, in some unrelated piece of code. Could > you try to bisect the stable to catch the offender ? The bisect is not > guaranteed to work, obviously, since the random corruption effects are > unpredictable. I'll try -- but before I do, I've just removed a couple of custom stanzas from /etc/devd.conf (after noting that updating to r241776 does not appear to have affected the reported symptoms). So if the removal avoids the problem, that may reduce the searching a fair bit. :-) (I'm also informed by my spouse that I'm to help her prepare for some expected rain today; this may reduce the amount of time I am able to spend on it.) Adding the above-cited stanzas to devd.conf is one of the few things that I did on the laptop that I haven't done elsewhere -- and while I only track stable/9 daily on a couple of machines, I have 3 more that I update Sunday mornings .... which would be now. We shall see. :-} Peace, david --=20 David H. Wolfskill david@catwhisker.org Taliban: Evil men with guns afraid of truth from a 14-year old girl. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --GkyPMzQoklWKZOV/ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlCD6YMACgkQmprOCmdXAD1uiQCfdaowMw3P3u5lX5FxP4upc/59 8RYAn330XWfbM8gLAt/Ixt8fyB/rB4f5 =88VF -----END PGP SIGNATURE----- --GkyPMzQoklWKZOV/-- From owner-freebsd-stable@FreeBSD.ORG Sun Oct 21 12:26:10 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1ADCF250 for ; Sun, 21 Oct 2012 12:26:10 +0000 (UTC) (envelope-from torfinn.ingolfsen@getmail.no) Received: from smtp.getmail.no (smtp.getmail.no [84.208.15.66]) by mx1.freebsd.org (Postfix) with ESMTP id BED2C8FC08 for ; Sun, 21 Oct 2012 12:26:09 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII Received: from get-mta-scan04.get.basefarm.net ([10.5.16.4]) by get-mta-out01.get.basefarm.net (Sun Java(tm) System Messaging Server 7.0-0.04 64bit (built Jun 20 2008)) with ESMTP id <0MC800HG7QFD3R80@get-mta-out01.get.basefarm.net> for freebsd-stable@freebsd.org; Sun, 21 Oct 2012 13:26:01 +0200 (MEST) Received: from get-mta-scan04.get.basefarm.net (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id AB4CE1EF8CA0_83DF3BB for ; Sun, 21 Oct 2012 11:40:43 +0000 (GMT) Received: from kg-v2.kg4.no (cm-84.215.134.159.getinternet.no [84.215.134.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by get-mta-scan04.get.basefarm.net (Sophos Email Appliance) with ESMTPSA id 709101EF8CA8_83DF3BF for ; Sun, 21 Oct 2012 11:40:43 +0000 (GMT) Date: Sun, 21 Oct 2012 13:26:00 +0200 From: Torfinn Ingolfsen To: freebsd-stable@freebsd.org Subject: Re: 9.1 and intel graphics Message-id: <20121021132600.a24018a1efc416fb068c50f5@getmail.no> In-reply-to: <19.B4.17144.D1CB3805@smtp01.insight.synacor.com> References: <19.B4.17144.D1CB3805@smtp01.insight.synacor.com> X-Mailer: Sylpheed 3.2.0 (GTK+ 2.24.6; amd64-portbld-freebsd8.3) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 21 Oct 2012 12:26:10 -0000 Hello, On Sun, 21 Oct 2012 05:10:53 -0400 Thomas Mueller wrote: > Normally I start X by startx which may be followed by an initialization file, > so I don't get the default spartan default twm all the time. In Linux and > FreeBSD, I generally use X as nonroot. Which is the "normal" and correct way, IMHO. > So I don't really know how to start a program such as xterm as another user > or how to have both root and nonroot windows in X. Is there any reason why you don't make use of su(1) or sudo (/usr/ports/security/sudo)? That way you can just launch a xterm as your normal user, and become root when you want / need. HTH -- Torfinn Ingolfsen From owner-freebsd-stable@FreeBSD.ORG Sun Oct 21 12:45:34 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 34B6E640 for ; Sun, 21 Oct 2012 12:45:34 +0000 (UTC) (envelope-from bsam@passap.ru) Received: from forward2h.mail.yandex.net (forward2h.mail.yandex.net [IPv6:2a02:6b8:0:f05::2]) by mx1.freebsd.org (Postfix) with ESMTP id A435F8FC0A for ; Sun, 21 Oct 2012 12:45:33 +0000 (UTC) Received: from smtp4h.mail.yandex.net (smtp4h.mail.yandex.net [84.201.186.21]) by forward2h.mail.yandex.net (Yandex) with ESMTP id 72338700A79 for ; Sun, 21 Oct 2012 16:45:31 +0400 (MSK) Received: from smtp4h.mail.yandex.net (localhost [127.0.0.1]) by smtp4h.mail.yandex.net (Yandex) with ESMTP id 3D9BF2C00F8 for ; Sun, 21 Oct 2012 16:45:31 +0400 (MSK) Received: from 93.91.0.153.tel.ru (93.91.0.153.tel.ru [93.91.0.153]) by smtp4h.mail.yandex.net (nwsmtp/Yandex) with ESMTP id jUHaBCZw-jVHmPZkF; Sun, 21 Oct 2012 16:45:31 +0400 Message-ID: <5083EE68.9020807@passap.ru> Date: Sun, 21 Oct 2012 16:45:28 +0400 From: Boris Samorodov Organization: =?UTF-8?B?0JfQkNCeICLQktCQ0KDQoiI=?= User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:16.0) Gecko/20121012 Thunderbird/16.0.1 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: 9.1 and intel graphics References: <19.B4.17144.D1CB3805@smtp01.insight.synacor.com> In-Reply-To: <19.B4.17144.D1CB3805@smtp01.insight.synacor.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 21 Oct 2012 12:45:34 -0000 Hi Thomas, 21.10.2012 13:10, Thomas Mueller пишет: > So I don't really know how to start a program such as xterm as another user > or how to have both root and nonroot windows in X. AFAIC Matthew Seaman already gave you a wonderful suggestion to add yourself to the group "operator" and just use the command "shutdown" with your own rights only. Did you try this suggestion? -- WBR, Boris Samorodov (bsam) FreeBSD Committer, http://www.FreeBSD.org The Power To Serve From owner-freebsd-stable@FreeBSD.ORG Sun Oct 21 14:42:05 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AB5E02B1 for ; Sun, 21 Oct 2012 14:42:05 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (wonkity.com [67.158.26.137]) by mx1.freebsd.org (Postfix) with ESMTP id 659338FC0A for ; Sun, 21 Oct 2012 14:42:05 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.5/8.14.5) with ESMTP id q9LEg4KA070376; Sun, 21 Oct 2012 08:42:04 -0600 (MDT) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.5/8.14.5/Submit) with ESMTP id q9LEg4YJ070373; Sun, 21 Oct 2012 08:42:04 -0600 (MDT) (envelope-from wblock@wonkity.com) Date: Sun, 21 Oct 2012 08:42:04 -0600 (MDT) From: Warren Block To: Thomas Mueller Subject: Re: 9.1 and intel graphics In-Reply-To: <19.B4.17144.D1CB3805@smtp01.insight.synacor.com> Message-ID: References: <19.B4.17144.D1CB3805@smtp01.insight.synacor.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (wonkity.com [127.0.0.1]); Sun, 21 Oct 2012 08:42:04 -0600 (MDT) Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 21 Oct 2012 14:42:05 -0000 On Sun, 21 Oct 2012, Thomas Mueller wrote: > Normally I start X by startx which may be followed by an initialization file, > so I don't get the default spartan default twm all the time. In Linux and > FreeBSD, I generally use X as nonroot. > > So I don't really know how to start a program such as xterm as another user > or how to have both root and nonroot windows in X. Open a terminal, su - to root in it. In the exceptionally rare case of needing to run a graphic program as root, also set the DISPLAY variable to match the normal user's value, then run that program in the terminal. From owner-freebsd-stable@FreeBSD.ORG Sun Oct 21 14:52:58 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 05337436 for ; Sun, 21 Oct 2012 14:52:58 +0000 (UTC) (envelope-from zkolic@sbb.rs) Received: from smtp2.sbb.rs (smtp2.sbb.rs [89.216.2.34]) by mx1.freebsd.org (Postfix) with ESMTP id 6BD478FC0A for ; Sun, 21 Oct 2012 14:52:56 +0000 (UTC) Received: from mycenae (cable-178-148-99-173.dynamic.sbb.rs [178.148.99.173]) by smtp2.sbb.rs (8.14.0/8.14.0) with ESMTP id q9LEldMK006522 for ; Sun, 21 Oct 2012 16:47:44 +0200 Received: by mycenae (Postfix, from userid 1001) id 4A99F5C23; Sun, 21 Oct 2012 16:48:45 +0200 (CEST) Date: Sun, 21 Oct 2012 16:48:45 +0200 From: Zoran Kolic To: freebsd-stable@freebsd.org Subject: Re: 9.1 and intel graphics Message-ID: <20121021144845.GA1139@mycenae.sbb.rs> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-SMTP-Vilter-Version: 1.3.2 X-SBB-Virus-Status: clean X-SBB-Spam-Score: -0.8 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 21 Oct 2012 14:52:58 -0000 > AFAIC Matthew Seaman already gave you a wonderful suggestion to add > yourself to the group "operator" and just use the command "shutdown" > with your own rights only. Did you try this suggestion? Actually, it is wheel group. To me it is "normal" to read mail and do something mundane in console, to startx for browsing things that cannot be seen pro- perly in lynx, to go back to console when done. I found no harm su-ing in graphics and doing root work, like write to usb stick or else. Eye catching is to use console in public, but... Best regards Zoran From owner-freebsd-stable@FreeBSD.ORG Sun Oct 21 16:02:25 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7A392AA8 for ; Sun, 21 Oct 2012 16:02:25 +0000 (UTC) (envelope-from nealie@kobudo.homeunix.net) Received: from nicandneal.net (nicandneal.net [194.231.42.198]) by mx1.freebsd.org (Postfix) with ESMTP id CE5618FC0C for ; Sun, 21 Oct 2012 16:02:24 +0000 (UTC) Received: from [10.0.0.10] ([194.231.42.198]) (AUTH: PLAIN nealie, TLS: TLSv1/SSLv3,128bits,AES128-SHA) by nicandneal.net with ESMTPSA; Sun, 21 Oct 2012 17:57:21 +0200 id 0000B847.0000000050841B61.000172F3 Subject: Re: 9.1 and intel graphics Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Neal Nelson In-Reply-To: Date: Sun, 21 Oct 2012 17:57:14 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <14C15BD0-8E83-46BD-9693-D15D045300B5@kobudo.homeunix.net> References: <20121020041408.GA1218@mycenae.sbb.rs> To: freebsd-stable@freebsd.org X-Mailer: Apple Mail (2.1283) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 21 Oct 2012 16:02:25 -0000 On 2012-Oct-20, at 08:29 , Kevin Oberman wrote: > On Fri, Oct 19, 2012 at 9:14 PM, Zoran Kolic wrote: >> Yesterday I have gotten lenovo e320 laptop, with core i3 2350 >> and HD3000 integrated. Gonna wait few days till 9.1 release. >> I never used anything aside "intel" on my old laptop. Kostik >> Belousov made a port of kms and I found patches from june and >> jule on the net. What should I do after 9.1 install in this >> case? I assume kms is in xorg. Do I have to find and install >> some driver from intel? Do I need to change xorg.conf after >> configure flag, that will make conf file? >=20 > Full support for the HD3000 is in 9-stable and 9.1-Beta and all RCs. > To use it you need to build X drivers and drm and the kernel with: > WITH_NEW_XORG=3DYES > WITH_KMS=3DYES > in /etc/make.conf. >=20 > Specifically, the kernel and a few ports. graphics/drm and your > org-drivers: xf86-video-intel, xf86-input-synaptics, xf86-input-mouse, > and xf86-input-keyboard. Then just start X. Don't try loading the > kernel module. It will be loaded by the startx. >=20 >> Finally, what happens when I leave x and want to go back to >> console mode? >=20 > You don't If you try, your system will lock up. You need to shutdown > from a window in X. Hopefully someone will implement switching back to > console mode some day, but it has not happened, yet. >=20 >> I tried out live RC2 from usb stick. Few acpi errors, intel >> 1000 wifi found. After some time "sysctl hw.acpi" gave me the >> cpu temperature of 50C. Fan was on. Probably temp gonna go >> down when I add powerd and cx_lowest to rc.conf on hdd. Is >> it normal temp for this cpu? >=20 > Pretty reasonable. Be sure to set both cx_lowest to "Cmax". It is new > to 9.1 and fixes some serious issues with C-states on many newer > platforms. Specifically that some platforms skip some C-states and > FreeBSD never used the ones saving more power than hte one skipped. >=20 > I always remind folks to blow out the heat sink on laptops about one a > year. Dust is a great insulator and laptops often collect a lot more > dust than office systems, though my office system started dying during > buildworld last week and blowing out the CPU heat sink fixed it up, > but it had been sitting around for almost three years collecting dust. I'm trying to do something similar, except with an HD4000 (i5-3570K) on = 9.1-RC2. The problem I'm having, after setting the make variables as above, is = that xorg-drivers port doesn't show the intel driver. In fact, there's = the specific part of the Makefile: .if (${ARCH} =3D=3D "amd64" || ${ARCH} =3D=3D "i386") && = !defined(WITH_NEW_XORG) VIDEO_ON+=3D intel .endif So what driver should I be using? Thanks, Neal.= From owner-freebsd-stable@FreeBSD.ORG Sun Oct 21 16:33:24 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 15765E99 for ; Sun, 21 Oct 2012 16:33:24 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (m209-73.dsl.rawbw.com [198.144.209.73]) by mx1.freebsd.org (Postfix) with ESMTP id CC34B8FC08 for ; Sun, 21 Oct 2012 16:33:23 +0000 (UTC) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.5/8.14.5) with ESMTP id q9LGXNNl002802; Sun, 21 Oct 2012 09:33:23 -0700 (PDT) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.5/8.14.5/Submit) id q9LGXMlA002801; Sun, 21 Oct 2012 09:33:22 -0700 (PDT) (envelope-from david) Date: Sun, 21 Oct 2012 09:33:22 -0700 From: David Wolfskill To: Konstantin Belousov Subject: Re: stable/9 @r241776 panic: REDZONE: Buffer underflow detected... Message-ID: <20121021163322.GB1730@albert.catwhisker.org> References: <20121020141019.GW1817@albert.catwhisker.org> <20121021121356.GJ35915@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="St7VIuEGZ6dlpu13" Content-Disposition: inline In-Reply-To: <20121021121356.GJ35915@deviant.kiev.zoral.com.ua> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 21 Oct 2012 16:33:24 -0000 --St7VIuEGZ6dlpu13 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Oct 21, 2012 at 03:13:56PM +0300, Konstantin Belousov wrote: > On Sat, Oct 20, 2012 at 07:10:19AM -0700, David Wolfskill wrote: > > This seems ... fairly weird to me. > >=20 > > Yesterday, I built & booted: > >=20 > > FreeBSD g1-227.catwhisker.org 9.1-PRERELEASE FreeBSD 9.1-PRERELEASE #27= 4 241726M: Fri Oct 19 05:40:05 PDT 2012 root@g1-227.catwhisker.org:/usr= /obj/usr/src/sys/CANARY i386 > >=20 > > and used the machine all day; nothing unusual (including various > > reboots (e.g. when I disembarked the train for the final leg of my > > commute home, so I powered the laptop off). > >=20 > > This morning, I built: > >=20 > > FreeBSD g1-227.catwhisker.org 9.1-PRERELEASE FreeBSD 9.1-PRERELEASE #27= 5 241776M: Sat Oct 20 04:34:45 PDT 2012 root@g1-227.catwhisker.org:/usr= /obj/usr/src/sys/CANARY i386 > >=20 > > and on first reboot, I got a panic. > >=20 > > After a bit of experimentation, it appears that I get a panic @r241776 > > if I attempt a normal boot into multi-user mode, but if I first boot to > > single-user mode, then exit single-user mode, it comes up without a > > problem. > >=20 > > I don't have a serial console, so I started to write down some of the > > panic information, but my patience ran a bit short. Here's whet I > > recorded (warning: hand-transcripted -- twice!): > >=20 > > ... > > Starting devd. > > REDZONE: Buffer underflow detected. 1 byte corrupted before 0xced40080= (4294966796 bytes allocated). > > Allocation backtrace: > > #0 0xc0ceac8f at redzone_setup+0xcf > > #1 0xc0a5d5c9 at malloc+0x1d9 > > ...[about 20 more such lines I didn't record]... > >=20 > > > bt > > Tracing pid 901 tid 100106 td 0xd2b99000 > > kdb_enter(...) > > panic(...) > > free(...) > > devread(ce8c2d00,f7274c0c,0,c0b1e4f0,d279e380,...) at devread+0x1a6 > > giant_read(...) at giant_read+0x87 > > devfs_read(...) at devfs_read+0xc6 > > dofileread(...) at dofileread+0x99 > > sys_read(...) at sys_read+0x98 > > syscall(f7274d08) at syscall+0x387 > >=20 > > Within the bounds described above, this appears to be quite reproducible > > -- on my laptop. My build machine (updated in parallel, at the same > > GRNs) does not exhibit the panic. > >=20 > > I was unable to get a crash dump; I have > >=20 > > dumpdev=3D"AUTO" > >=20 > > in /etc/rc.conf, and the panic was occurring well after swap was > > enabled. (Yes, I know I have swap over-allocated. I plan to do > > something about it at some point.) > >=20 > > I've attached a copy of dmesg.boot. > >=20 > > Anyone else seeing this? Any ideas how to diagnose it? >=20 > devread is the method of devctl(4) which passes devd notifications from > the kernel to userland (to devd, specifically). There were no changes to > devctl(4) for quite a time. >=20 > The corruption is, most likely, in some unrelated piece of code. Could > you try to bisect the stable to catch the offender ? The bisect is not > guaranteed to work, obviously, since the random corruption effects are > unpredictable. [Lack of trimming is deliberate, in this case, as I found a reversion that appears to address the issue, and I wanted folks looking at this to have the bulk of the symptoms readily at hand. -- dhw] The range of GRNs in question is 241726 - 241776, only 5 of which appliy to stable/9. Here's a list, with the affected files listed: 241742 sys/dev/sound/pci/hda/hdaa_patches.c 241749 sys/cam/cam_queue.c 241762 sys/dev/tws/tws.c sys/dev/tws/tws.h sys/dev/tws/tws_cam.c sys/dev/tws/tws_hdm.h sys/dev/tws/tws_user.c 241767 usr.bin/make/var.c 241769 sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zvol.c I had actually tried reverting 241742 yesterday, to no effect. I don't use ZFS, and I have a pretty hard time understanding how 241767 would break one machine and leave 4 others unscathed. (Yes, I completed my weekly updates, as well, by now.) I don't have tws(4) devices -- certainly not on the laptop. So I tried reverting 241749 ... and I failed to reproduce the problem. Well, one boot out of one, at least. I'll try a few more reality checks, and report back if a correction is in order. But (for now, at least), it looks to me as if 241749 is presenting a problem on this laptop. For folks investigating, I attached a dmesg.boot to the initial post in the thread; I'll be happy to provide more information, should it be requested (& specified). Peace, david --=20 David H. Wolfskill david@catwhisker.org Taliban: Evil men with guns afraid of truth from a 14-year old girl. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --St7VIuEGZ6dlpu13 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlCEI9EACgkQmprOCmdXAD0w+QCfTT7c0aL8L76liKKa/bP8/VO8 gXcAnjz+0l68d21fkp7ewnmXco86jd+2 =gn7W -----END PGP SIGNATURE----- --St7VIuEGZ6dlpu13-- From owner-freebsd-stable@FreeBSD.ORG Sun Oct 21 16:46:35 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7345AB6 for ; Sun, 21 Oct 2012 16:46:35 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (m209-73.dsl.rawbw.com [198.144.209.73]) by mx1.freebsd.org (Postfix) with ESMTP id 45A838FC08 for ; Sun, 21 Oct 2012 16:46:34 +0000 (UTC) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.5/8.14.5) with ESMTP id q9LGkY8E003109; Sun, 21 Oct 2012 09:46:34 -0700 (PDT) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.5/8.14.5/Submit) id q9LGkYVM003108; Sun, 21 Oct 2012 09:46:34 -0700 (PDT) (envelope-from david) Date: Sun, 21 Oct 2012 09:46:34 -0700 From: David Wolfskill To: Konstantin Belousov Subject: Re: stable/9 @r241776 panic: REDZONE: Buffer underflow detected... Message-ID: <20121021164634.GC1730@albert.catwhisker.org> References: <20121020141019.GW1817@albert.catwhisker.org> <20121021121356.GJ35915@deviant.kiev.zoral.com.ua> <20121021163322.GB1730@albert.catwhisker.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="qtZFehHsKgwS5rPz" Content-Disposition: inline In-Reply-To: <20121021163322.GB1730@albert.catwhisker.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 21 Oct 2012 16:46:35 -0000 --qtZFehHsKgwS5rPz Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Oct 21, 2012 at 09:33:22AM -0700, David Wolfskill wrote: > ... > So I tried reverting 241749 ... and I failed to reproduce the problem. >=20 > Well, one boot out of one, at least. I'll try a few more reality > checks, and report back if a correction is in order. But (for now, at > least), it looks to me as if 241749 is presenting a problem on this > laptop. > ... 5 for 5. I'm convinced that 241749 causes problems on this laptop for attempts to boot without a stop is single-user mode first. (So that sounds like a timing issue, somehow.) And thanks again, Konstantin! Peace, david --=20 David H. Wolfskill david@catwhisker.org Taliban: Evil men with guns afraid of truth from a 14-year old girl. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --qtZFehHsKgwS5rPz Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlCEJuoACgkQmprOCmdXAD3IDgCcCn7mxIVwfgOed6WqksUhGMbQ KWQAn0/JrHfVcFHZZt0ib1ihK6mWXnEY =aCky -----END PGP SIGNATURE----- --qtZFehHsKgwS5rPz-- From owner-freebsd-stable@FreeBSD.ORG Sun Oct 21 17:11:47 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C55E5493; Sun, 21 Oct 2012 17:11:47 +0000 (UTC) (envelope-from takeda@takeda.tk) Received: from chinatsu.takeda.tk (mail.takeda.tk [74.0.89.210]) by mx1.freebsd.org (Postfix) with ESMTP id 8FD118FC08; Sun, 21 Oct 2012 17:11:46 +0000 (UTC) Received: from takeda-ws.lan (takeda-ws.lan [10.0.0.3]) (authenticated bits=0) by chinatsu.takeda.tk (8.14.5/8.14.5) with ESMTP id q9LHBiAw008630 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Sun, 21 Oct 2012 10:11:45 -0700 (PDT) (envelope-from takeda@takeda.tk) Date: Sun, 21 Oct 2012 10:11:38 -0700 From: Derek Kulinski X-Priority: 3 (Normal) Message-ID: <1855874068.20121021101138@takeda.tk> To: Andriy Gapon Subject: Re: Problem reading vitals from Gigabyte H77-DH3H In-Reply-To: <5083B81F.2080909@FreeBSD.org> References: <1286515493.20121017131543@takeda.tk> <507F1761.1010202@FreeBSD.org> <20121017205147.GB36106@chinatsu.takeda.tk> <5081552F.2050303@FreeBSD.org> <771658188.20121019205010@takeda.tk> <508254AF.7040709@FreeBSD.org> <994545137.20121020010809@takeda.tk> <50826040.6010106@FreeBSD.org> <55342693.20121020103732@takeda.tk> <5082EEC8.2080307@FreeBSD.org> <198684285.20121020122034@takeda.tk> <5082FEA8.3050600@FreeBSD.org> <508304E6.6020202@FreeBSD.org> <5083B81F.2080909@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: Scot Hetzel , freebsd-stable@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 21 Oct 2012 17:11:47 -0000 Hello Andriy, Sunday, October 21, 2012, 1:53:51 AM, you wrote: >> it_16bit_fanrpm(sc, &sc->sensors[0]); >> - else >> + it_generic_svolt(sc, &sc->sensors[5]); >> + it_generic_svolt(sc, &sc->sensors[14]); <- Looks to be a copy/paste bug ;-) > Indeed. Should be "stemp" of course. > Thank you! I just fixed the code and looks better now: hw.sensors.it0.fan0: 997 RPM hw.sensors.it0.fan1: invalid hw.sensors.it0.fan2: 1303 RPM hw.sensors.it0.fan3: 1149 RPM hw.sensors.it0.fan4: invalid hw.sensors.it0.volt0: 1,42 VDC (VCORE_A) hw.sensors.it0.volt1: 2,72 VDC (VCORE_B) hw.sensors.it0.volt2: 2,70 VDC (+3.3V) hw.sensors.it0.volt3: 4,60 VDC (+5V) hw.sensors.it0.volt4: 0,06 VDC (+12V) hw.sensors.it0.volt5: -5,08 VDC (Unused) hw.sensors.it0.volt6: -6,53 VDC (-12V) hw.sensors.it0.volt7: 3,74 VDC (+5VSB) hw.sensors.it0.volt8: 2,14 VDC (VBAT) hw.sensors.it0.temp0: 30,00 degC hw.sensors.it0.temp1: 25,00 degC hw.sensors.it0.temp2: 25,00 degC -- Best regards, Derek mailto:takeda@takeda.tk -- DEFINITION: Computer - A device designed to speed and automate errors. From owner-freebsd-stable@FreeBSD.ORG Sun Oct 21 17:41:07 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 25C84A4B; Sun, 21 Oct 2012 17:41:07 +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 61BF68FC16; Sun, 21 Oct 2012 17:41:06 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q9LHf6GI014592; Sun, 21 Oct 2012 20:41:06 +0300 (EEST) (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.5/8.14.5) with ESMTP id q9LHetLd034017; Sun, 21 Oct 2012 20:40:55 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q9LHetGN034016; Sun, 21 Oct 2012 20:40:55 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 21 Oct 2012 20:40:55 +0300 From: Konstantin Belousov To: David Wolfskill Subject: Re: stable/9 @r241776 panic: REDZONE: Buffer underflow detected... Message-ID: <20121021174054.GM35915@deviant.kiev.zoral.com.ua> References: <20121020141019.GW1817@albert.catwhisker.org> <20121021121356.GJ35915@deviant.kiev.zoral.com.ua> <20121021163322.GB1730@albert.catwhisker.org> <20121021164634.GC1730@albert.catwhisker.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="+6uHKC0olnQzmrFy" Content-Disposition: inline In-Reply-To: <20121021164634.GC1730@albert.catwhisker.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham 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, mav@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 21 Oct 2012 17:41:07 -0000 --+6uHKC0olnQzmrFy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Oct 21, 2012 at 09:46:34AM -0700, David Wolfskill wrote: > On Sun, Oct 21, 2012 at 09:33:22AM -0700, David Wolfskill wrote: > > ... > > So I tried reverting 241749 ... and I failed to reproduce the problem. > >=20 > > Well, one boot out of one, at least. I'll try a few more reality > > checks, and report back if a correction is in order. But (for now, at > > least), it looks to me as if 241749 is presenting a problem on this > > laptop. > > ... >=20 > 5 for 5. I'm convinced that 241749 causes problems on this laptop for > attempts to boot without a stop is single-user mode first. >=20 > (So that sounds like a timing issue, somehow.) >=20 > And thanks again, Konstantin! I do not know/do not understand the CAM code, the question shall be addressed to Alexander. It still might be a false positive. --+6uHKC0olnQzmrFy Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAlCEM6YACgkQC3+MBN1Mb4hAnQCeN6gtsqghpFCOjIB8RGwcy0nH ZSIAoL2vnI5JMy6i/UpZRetgMkXTrLqi =MZAh -----END PGP SIGNATURE----- --+6uHKC0olnQzmrFy-- From owner-freebsd-stable@FreeBSD.ORG Sun Oct 21 18:28:11 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E90BECBA for ; Sun, 21 Oct 2012 18:28:11 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id 60E238FC18 for ; Sun, 21 Oct 2012 18:28:11 +0000 (UTC) Received: by mail-lb0-f182.google.com with SMTP id b5so1585817lbd.13 for ; Sun, 21 Oct 2012 11:28:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=X0IeLJGbdcLrmnvWIpmKAcdvZGApZL13ucKwTVgFb28=; b=AimzoKvg4EyLFexvUpH7f+EoJgIMyLtC0LZqBeUdjY/sNWYbBC/AwZbx9ZjG0BgqFY TAEFlww0/Jq+uv0zoRKwzMBlxd1HpUzERs7gj+Y9YHP2xivkIxF3NNeH4sZo+TCAdGC5 k01+YD7M1LKkJI3yw7wtbstS7Tl3qfN9KrSi6hH+QoCOt6iz11q8uwiNdpwIApREUUN+ t5rxdvR99Ty6Q1zXTrjOvskGR1g0sm65BQghVxPzdKMtcP9wBtjD9A+Lj7wJQoWksw4U I2X5llqU4DnmHVKlWi7KiNFKfieRfE5CY2LcliqaYFkiHIyiOeczlOf/CS4Id+XNAghn 2beQ== Received: by 10.152.47.79 with SMTP id b15mr6166749lan.57.1350844089927; Sun, 21 Oct 2012 11:28:09 -0700 (PDT) Received: from mavbook.mavhome.dp.ua (mavhome.mavhome.dp.ua. [213.227.240.37]) by mx.google.com with ESMTPS id gt17sm2314430lab.6.2012.10.21.11.28.08 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 21 Oct 2012 11:28:08 -0700 (PDT) Sender: Alexander Motin Message-ID: <50843EB6.8030407@FreeBSD.org> Date: Sun, 21 Oct 2012 21:28:06 +0300 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120628 Thunderbird/13.0.1 MIME-Version: 1.0 To: David Wolfskill Subject: Re: stable/9 @r241776 panic: REDZONE: Buffer underflow detected... References: <20121020141019.GW1817@albert.catwhisker.org> <20121021121356.GJ35915@deviant.kiev.zoral.com.ua> <20121021163322.GB1730@albert.catwhisker.org> <20121021164634.GC1730@albert.catwhisker.org> <20121021174054.GM35915@deviant.kiev.zoral.com.ua> In-Reply-To: <20121021174054.GM35915@deviant.kiev.zoral.com.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Konstantin Belousov , stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 21 Oct 2012 18:28:12 -0000 On 21.10.2012 20:40, Konstantin Belousov wrote: > On Sun, Oct 21, 2012 at 09:46:34AM -0700, David Wolfskill wrote: >> On Sun, Oct 21, 2012 at 09:33:22AM -0700, David Wolfskill wrote: >>> ... >>> So I tried reverting 241749 ... and I failed to reproduce the problem. >>> >>> Well, one boot out of one, at least. I'll try a few more reality >>> checks, and report back if a correction is in order. But (for now, at >>> least), it looks to me as if 241749 is presenting a problem on this >>> laptop. >>> ... >> >> 5 for 5. I'm convinced that 241749 causes problems on this laptop for >> attempts to boot without a stop is single-user mode first. >> >> (So that sounds like a timing issue, somehow.) >> >> And thanks again, Konstantin! > > I do not know/do not understand the CAM code, the question shall > be addressed to Alexander. It still might be a false positive. I don't see how increasing buffer size by few bytes in mentioned change may cause memory corruption in some other place. I guess change can be just innocent witness that affected some memory placement, moving some existing corruption from one area to another where it was noticed. I am curious, how to interpret phrase "42=94966796 bytes allocated" in log. May be it is just corrupted output, but the number still seems quite big, especially for i386 system, making me think about some integer overflow. David, could you write down that part once more? Having few more lines of "Allocation backtrace:" could also be useful. Could you show your kernel config? I can try to run it on my tests system, hoping to reproduce the problem. -- Alexander Motin From owner-freebsd-stable@FreeBSD.ORG Sun Oct 21 19:40:46 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A2D7AAFC; Sun, 21 Oct 2012 19:40:46 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (m209-73.dsl.rawbw.com [198.144.209.73]) by mx1.freebsd.org (Postfix) with ESMTP id A80E88FC1C; Sun, 21 Oct 2012 19:40:45 +0000 (UTC) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.5/8.14.5) with ESMTP id q9LJejr3001745; Sun, 21 Oct 2012 12:40:45 -0700 (PDT) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.5/8.14.5/Submit) id q9LJej8r001744; Sun, 21 Oct 2012 12:40:45 -0700 (PDT) (envelope-from david) Date: Sun, 21 Oct 2012 12:40:45 -0700 From: David Wolfskill To: Alexander Motin Subject: Re: stable/9 @r241776 panic: REDZONE: Buffer underflow detected... Message-ID: <20121021194045.GA1609@albert.catwhisker.org> References: <20121020141019.GW1817@albert.catwhisker.org> <20121021121356.GJ35915@deviant.kiev.zoral.com.ua> <20121021163322.GB1730@albert.catwhisker.org> <20121021164634.GC1730@albert.catwhisker.org> <20121021174054.GM35915@deviant.kiev.zoral.com.ua> <50843EB6.8030407@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="dc+cDN39EJAMEtIO" Content-Disposition: inline In-Reply-To: <50843EB6.8030407@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: stantin Belousov , stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 21 Oct 2012 19:40:46 -0000 --dc+cDN39EJAMEtIO Content-Type: multipart/mixed; boundary="n8g4imXOkfNTN/H1" Content-Disposition: inline --n8g4imXOkfNTN/H1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Oct 21, 2012 at 09:28:06PM +0300, Alexander Motin wrote: > ... > I am curious, how to interpret phrase "42=3D94966796 bytes allocated" in= =20 > log. May be it is just corrupted output, but the number still seems=20 > quite big, especially for i386 system, making me think about some=20 > integer overflow. David, could you write down that part once more? >=20 > Having few more lines of "Allocation backtrace:" could also be useful. I'll try connecting a USB<=3D>serial dongle & see if that's good enough to capture the ddb output. =20 > Could you show your kernel config? I can try to run it on my tests=20 > system, hoping to reproduce the problem. Attached (file "CANARY"); also attached output of "pciconf -lv". Peace, david --=20 David H. Wolfskill david@catwhisker.org Taliban: Evil men with guns afraid of truth from a 14-year old girl. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --n8g4imXOkfNTN/H1 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=CANARY Content-Transfer-Encoding: quoted-printable # # CANARY -- David's laptop kernel (based on one for the Compal 30W2/ # Dell i5000e) # include GENERIC # nocpu I486_CPU # nocpu I586_CPU ident "CANARY" maxusers 0 nodevice ataraid # ATA RAID drives nodevice atapist # ATAPI tape drives # device atapicam # emulate ATAPI devices as SCSI ditto via CAM options ATA_CAM # FDC_DEBUG enables floppy debugging. Since the debug output is huge, you # gotta turn it actually on by setting the variable fd_debug with DDB, # however. options FDC_DEBUG nodevice asr # DPT SmartRAID V, VI and Adaptec SCSI RAID nodevice dpt # DPT Smartcache III, IV - See NOTES for options! nodevice mly # Mylex AcceleRAID/eXtremeRAID nodevice amr # AMI MegaRAID nodevice arcmsr # Areca SATA II RAID nodevice asr # DPT SmartRAID V, VI and Adaptec SCSI RAID nodevice ciss # Compaq Smart RAID 5* nodevice dpt # DPT Smartcache III, IV - See NOTES for options nodevice hptmv # Highpoint RocketRAID 182x nodevice iir # Intel Integrated RAID nodevice ips # IBM (Adaptec) ServeRAID nodevice mly # Mylex AcceleRAID/eXtremeRAID nodevice twa # 3ware 9000 series PATA/SATA RAID nodevice aac # Adaptec FSA RAID nodevice aacp # SCSI passthrough for aac (requires CAM) nodevice ida # Compaq Smart RAID nodevice mlx # Mylex DAC960 family nodevice pst # Promise Supertrak SX6000 nodevice twe # 3ware ATA RAID nodevice aac # Adaptec FSA RAID, Dell PERC2/PERC3 nodevice amr # AMI MegaRAID nodevice ida # Compaq Smart RAID nodevice mlx # Mylex DAC960 family nodevice twe # 3ware Escalade nodevice zyd # Whatever it is, I don't have it nodevice an # I want to use the module, for hacking nodevice wi # I want to use the module, for hacking # # MMC/SD # # mmc MMC/SD bus # mmcsd MMC/SD memory card # sdhci Generic PCI SD Host Controller # device mmc device mmcsd device sdhci # # SMB bus # # System Management Bus support is provided by the 'smbus' device. # Access to the SMBus device is via the 'smb' device (/dev/smb*), # which is a child of the 'smbus' device. # # Supported devices: # smb standard I/O through /dev/smb* # # Supported SMB interfaces: # iicsmb I2C to SMB bridge with any iicbus interface # bktr brooktree848 I2C hardware interface # intpm Intel PIIX4 (82371AB, 82443MX) Power Management Unit # alpm Acer Aladdin-IV/V/Pro2 Power Management Unit # ichsmb Intel ICH SMBus controller chips (82801AA, 82801AB, 82801BA) # viapm VIA VT82C586B/596B/686A and VT8233 Power Management Unit # amdpm AMD 756 Power Management Unit # amdsmb AMD 8111 SMBus 2.0 Controller # nfpm NVIDIA nForce Power Management Unit # nfsmb NVIDIA nForce2/3/4 MCP SMBus 2.0 Controller # device smbus # Bus support, required for smb below. # # SMB bus # # System Management Bus support is provided by the 'smbus' device. # Access to the SMBus device is via the 'smb' device (/dev/smb*), # which is a child of the 'smbus' device. # # Supported devices: # smb standard io through /dev/smb* # # Supported SMB interfaces: # iicsmb I2C to SMB bridge with any iicbus interface # bktr brooktree848 I2C hardware interface # intpm Intel PIIX4 (82371AB, 82443MX) Power Management Unit # alpm Acer Aladdin-IV/V/Pro2 Power Management Unit # ichsmb Intel ICH SMBus controller chips (82801AA, 82801AB, 82801BA) # viapm VIA VT82C586B/596B/686A and VT8233 Power Management Unit=20 # device smbus # Bus support, required for smb below. device intpm # device alpm device ichsmb # device viapm device smb # # I2C Bus # # Philips i2c bus support is provided by the `iicbus' device. # # Supported devices: # ic i2c network interface # iic i2c standard io # iicsmb i2c to smb bridge. Allow i2c i/o with smb commands. # # Supported interfaces: # pcf Philips PCF8584 ISA-bus controller # bktr brooktree848 I2C software interface # # Other: # iicbb generic I2C bit-banging code (needed by lpbb, bktr) # device iicbus # Bus support, required for ic/iic/iicsmb below. device iicbb device ic device iic device iicsmb # smb over i2c bridge device pcf device speaker # Play IBM BASIC-style noises out your speaker # # Internet family options: # # MROUTING enables the kernel multicast packet forwarder, which works # with mrouted(8). # # IPFIREWALL enables support for IP firewall construction, in # conjunction with the `ipfw' program. IPFIREWALL_VERBOSE sends # logged packets to the system logger. IPFIREWALL_VERBOSE_LIMIT # limits the number of times a matching entry can be logged. # # WARNING: IPFIREWALL defaults to a policy of "deny ip from any to any" # and if you do not add other rules during startup to allow access, # YOU WILL LOCK YOURSELF OUT. It is suggested that you set firewall_type= =3Dopen # in /etc/rc.conf when first enabling this feature, then refining the # firewall rules in /etc/rc.firewall after you've tested that the new kernel # feature works properly. # # IPFIREWALL_DEFAULT_TO_ACCEPT causes the default rule (at boot) to # allow everything. Use with care, if a cracker can crash your # firewall machine, they can get to your protected machines. However, # if you are using it as an as-needed filter for specific problems as # they arise, then this may be for you. Changing the default to 'allow' # means that you won't get stuck if the kernel and /sbin/ipfw binary get # out of sync. # # IPDIVERT enables the divert IP sockets, used by ``ipfw divert''. It # depends on IPFIREWALL if compiled into the kernel. # # IPFIREWALL_FORWARD enables changing of the packet destination either # to do some sort of policy routing or transparent proxying. Used by # ``ipfw forward''. # # IPSTEALTH enables code to support stealth forwarding (i.e., forwarding # packets without touching the ttl). This can be useful to hide firewalls # from traceroute and similar tools. # # TCPDEBUG enables code which keeps traces of the TCP state machine # for sockets with the SO_DEBUG option set, which can then be examined # using the trpt(8) utility. # #options MROUTING # Multicast routing options IPFIREWALL #firewall options IPFIREWALL_VERBOSE #enable logging to syslogd(8) options IPFIREWALL_VERBOSE_LIMIT=3D0 #do not limit verbosity #options IPFIREWALL_DEFAULT_TO_ACCEPT #allow everything by default options IPFIREWALL_FORWARD #packet destination changes options IPDIVERT #divert sockets #options IPFILTER #ipfilter support #options IPFILTER_LOG #ipfilter logging #options IPFILTER_LOOKUP #ipfilter pools #options IPFILTER_DEFAULT_BLOCK #block all packets by default #options IPSTEALTH #support for stealth forwarding #options TCPDEBUG options LIBALIAS # The MBUF_STRESS_TEST option enables options which create # various random failures / extreme cases related to mbuf # functions. See mbuf(9) for a list of available test cases. #options MBUF_STRESS_TEST # Statically Link in accept filters options ACCEPT_FILTER_DATA options ACCEPT_FILTER_HTTP # TCP_SIGNATURE adds support for RFC 2385 (TCP-MD5) digests. These are # carried in TCP option 19. This option is commonly used to protect # TCP sessions (e.g. BGP) where IPSEC is not available nor desirable. # This is enabled on a per-socket basis using the TCP_MD5SIG socket option. # This requires the use of 'device crypto', 'options FAST_IPSEC' or 'options # IPSEC', and 'device cryptodev'. #options TCP_SIGNATURE #include support for RFC 2385 # DUMMYNET enables the "dummynet" bandwidth limiter. You need IPFIREWALL # as well. See dummynet(4) and ipfw(8) for more info. When you run # DUMMYNET it is advisable to also have "options HZ=3D1000" to achieve a # smoother scheduling of the traffic. options DUMMYNET # Zero copy sockets support. This enables "zero copy" for sending and # receiving data via a socket. The send side works for any type of NIC, # the receive side only works for NICs that support MTUs greater than the # page size of your architecture and that support header splitting. See # zero_copy(9) for more details. options ZERO_COPY_SOCKETS # # Sound drivers # # sound: The generic sound driver. # device sound # # snd_*: Device-specific drivers. # # The flags of the device tells the device a bit more info about the # device that normally is obtained through the PnP interface. # bit 2..0 secondary DMA channel; # bit 4 set if the board uses two dma channels; # bit 15..8 board type, overrides autodetection; leave it # zero if don't know what to put in (and you don't, # since this is unsupported at the moment...). # # snd_als4000: Avance Logic ALS4000 PCI. # snd_ad1816: Analog Devices AD1816 ISA PnP/non-PnP. # snd_cmi: CMedia CMI8338/CMI8738 PCI. # snd_cs4281: Crystal Semiconductor CS4281 PCI. # snd_csa: Crystal Semiconductor CS461x/428x PCI. (except # 4281) # snd_ds1: Yamaha DS-1 PCI. # snd_emu10k1: Creative EMU10K1 PCI and EMU10K2 (Audigy) PCI. # snd_es137x: Ensoniq AudioPCI ES137x PCI. # snd_ess: Ensoniq ESS ISA PnP/non-PnP. # snd_fm801: Forte Media FM801 PCI. # snd_gusc: Gravis UltraSound ISA PnP/non-PnP. # snd_ich: Intel ICH PCI and some more audio controllers # embedded in a chipset. # snd_maestro: ESS Technology Maestro-1/2x PCI. # snd_maestro3: ESS Technology Maestro-3/Allegro PCI. # snd_mss: Microsoft Sound System ISA PnP/non-PnP. # snd_neomagic: Neomagic 256 AV/ZX PCI. # snd_sb16: Creative SoundBlaster16, to be used in # conjuction with snd_sbc. # snd_sb8: Creative SoundBlaster (pre-16), to be used in # conjuction with snd_sbc. # snd_sbc: Creative SoundBlaster ISA PnP/non-PnP. # Supports ESS and Avance ISA chips as well. # snd_solo: ESS Solo-1x PCI. # snd_t4dwave: Trident 4DWave PCI, Sis 7018 PCI and Acer Labs # M5451 PCI. # snd_via8233: VIA VT8233x PCI. # snd_via82c686: VIA VT82C686A PCI. # snd_vibes: S3 Sonicvibes PCI. # snd_uaudio: USB audio. #device "snd_ad1816" #device "snd_als4000" #device "snd_au88x0" #device snd_cmi #device "snd_cs4281" #device snd_csa #device "snd_ds1" #device "snd_emu10k1" #device "snd_es137x" #device snd_ess #device "snd_fm801" #device snd_gusc device snd_ich device snd_hda #device snd_maestro #device "snd_maestro3" #device snd_mss #device snd_neomagic #device "snd_sb16" #device "snd_sb8" #device snd_sbc #device snd_solo #device "snd_t4dwave" #device "snd_via8233" #device "snd_via82c686" #device snd_vibes #device "snd_vortex1" #device snd_uaudio =0C ##################################################################### # DEBUGGING OPTIONS # # Compile with kernel debugger related code. # options KDB # # Print a stack trace of the current thread on the console for a panic. # options KDB_TRACE # # Don't enter the debugger for a panic. Intended for unattended operation # where you may want to enter the debugger from the console, but still want # the machine to recover from a panic. # # options KDB_UNATTENDED # # Enable the ddb debugger backend. # options DDB # # Print the numerical value of symbols in addition to the symbolic # representation. # options DDB_NUMSYM # # Enable the remote gdb debugger backend. # # options GDB # # Enable the kernel DTrace hooks which are required to load the DTrace # kernel modules. # # options KDTRACE_HOOKS # # SYSCTL_DEBUG enables a 'sysctl' debug tree that can be used to dump the # contents of the registered sysctl nodes on the console. It is disabled by # default because it generates excessively verbose console output that can # interfere with serial console operation. # # options SYSCTL_DEBUG # # DEBUG_MEMGUARD builds and enables memguard(9), a replacement allocator # for the kernel used to detect modify-after-free scenarios. See the # memguard(9) man page for more information on usage. # options DEBUG_MEMGUARD # # DEBUG_REDZONE enables buffer underflows and buffer overflows detection for # malloc(9). # options DEBUG_REDZONE # # KTRACE enables the system-call tracing facility ktrace(2). To be more # SMP-friendly, KTRACE uses a worker thread to process most trace events # asynchronously to the thread generating the event. This requires a # pre-allocated store of objects representing trace events. The # KTRACE_REQUEST_POOL option specifies the initial size of this store. # The size of the pool can be adjusted both at boottime and runtime via # the kern.ktrace_request_pool tunable and sysctl. # # options KTRACE #kernel tracing # options KTRACE_REQUEST_POOL=3D101 # # KTR is a kernel tracing mechanism imported from BSD/OS. Currently # it has no userland interface aside from a few sysctl's. It is # enabled with the KTR option. KTR_ENTRIES defines the number of # entries in the circular trace buffer; it must be a power of two. # KTR_COMPILE defines the mask of events to compile into the kernel as # defined by the KTR_* constants in . KTR_MASK defines the # initial value of the ktr_mask variable which determines at runtime # what events to trace. KTR_CPUMASK determines which CPU's log # events, with bit X corresponding to CPU X. KTR_VERBOSE enables # dumping of KTR events to the console by default. This functionality # can be toggled via the debug.ktr_verbose sysctl and defaults to off # if KTR_VERBOSE is not defined. # # options KTR # options KTR_ENTRIES=3D1024 # options KTR_COMPILE=3D(KTR_INTR|KTR_PROC) # options KTR_MASK=3DKTR_INTR # options KTR_CPUMASK=3D0x3 # options KTR_VERBOSE # # ALQ(9) is a facility for the asynchronous queuing of records from the ker= nel # to a vnode, and is employed by services such as KTR(4) to produce trace # files based on a kernel event stream. Records are written asynchronously # in a worker thread. # # options ALQ # options KTR_ALQ # # The INVARIANTS option is used in a number of source files to enable # extra sanity checking of internal structures. This support is not # enabled by default because of the extra time it would take to check # for these conditions, which can only occur as a result of # programming errors. # # options INVARIANTS # # The INVARIANT_SUPPORT option makes us compile in support for # verifying some of the internal structures. It is a prerequisite for # 'INVARIANTS', as enabling 'INVARIANTS' will make these functions be # called. The intent is that you can set 'INVARIANTS' for single # source files (by changing the source file or specifying it on the # command line) if you have 'INVARIANT_SUPPORT' enabled. Also, if you # wish to build a kernel module with 'INVARIANTS', then adding # 'INVARIANT_SUPPORT' to your kernel will provide all the necessary # infrastructure without the added overhead. # # options INVARIANT_SUPPORT # # The DIAGNOSTIC option is used to enable extra debugging information # from some parts of the kernel. As this makes everything more noisy, # it is disabled by default. # options DIAGNOSTIC # # REGRESSION causes optional kernel interfaces necessary only for regression # testing to be enabled. These interfaces may constitute security risks # when enabled, as they permit processes to easily modify aspects of the # run-time environment to reproduce unlikely or unusual (possibly normally # impossible) scenarios. # # options REGRESSION # # RESTARTABLE_PANICS allows one to continue from a panic as if it were # a call to the debugger to continue from a panic as instead. It is only # useful if a kernel debugger is present. To restart from a panic, reset # the panicstr variable to NULL and continue execution. This option is # for development use only and should NOT be used in production systems # to "workaround" a panic. # #options RESTARTABLE_PANICS # # This option let some drivers co-exist that can't co-exist in a running # system. This is used to be able to compile all kernel code in one go for # quality assurance purposes (like this file, which the option takes it name # from.) # # options COMPILING_LINT # # STACK enables the stack(9) facility, allowing the capture of kernel stack # for the purpose of procinfo(1), etc. stack(9) will also be compiled in # automatically if DDB(4) is compiled into the kernel. # # options STACK # # uart: newbusified driver for serial interfaces. It consolidates the sio(= 4), # sab(4) and zs(4) drivers. # # device uart # Options for uart(4) # options UART_PPS_ON_CTS # Do time pulse capturing using CTS # instead of DCD. # The following hint should only be used for pure ISA devices. It is not # needed otherwise. Use of hints is strongly discouraged. # hint.uart.0.at=3D"isa" # The following 3 hints are used when the UART is a system device (i.e., a # console or debug port), but only on platforms that don't have any other # means to pass the information to the kernel. The unit number of the hint # is only used to bundle the hints together. There is no relation to the # unit number of the probed UART. # hint.uart.0.port=3D"0x3f8" # hint.uart.0.flags=3D"0x10" # hint.uart.0.baud=3D"115200" # `flags' for serial drivers that support consoles like sio(4) and uart(4): # 0x10 enable console support for this unit. Other console flags # (if applicable) are ignored unless this is set. Enabling # console support does not make the unit the preferred console. # Boot with -h or set boot_serial=3DYES in the loader. For sio(4) # specifically, the 0x20 flag can also be set (see above). # Currently, at most one unit can have console support; the # first one (in config file order) with this flag set is # preferred. Setting this flag for sio0 gives the old behaviour. # 0x80 use this port for serial line gdb support in ddb. Also known # as debug port. # # Options for serial drivers that support consoles: options BREAK_TO_DEBUGGER # A BREAK on a serial console goes to # ddb, if available. # Solaris implements a new BREAK which is initiated by a character # sequence CR ~ ^b which is similar to a familiar pattern used on # Sun servers by the Remote Console. There are FreeBSD extentions: # CR ~ ^p requests force panic and CR ~ ^r requests a clean reboot. options ALT_BREAK_TO_DEBUGGER # For demo # options VIMAGE --n8g4imXOkfNTN/H1 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=pciconf hostb0@pci0:0:0:0: class=0x060000 card=0x02501028 chip=0x2a408086 rev=0x07 hdr=0x00 vendor = 'Intel Corporation' device = 'Mobile 4 Series Chipset Memory Controller Hub' class = bridge subclass = HOST-PCI pcib1@pci0:0:1:0: class=0x060400 card=0x02501028 chip=0x2a418086 rev=0x07 hdr=0x01 vendor = 'Intel Corporation' device = 'Mobile 4 Series Chipset PCI Express Graphics Port' class = bridge subclass = PCI-PCI none0@pci0:0:3:0: class=0x078000 card=0x02501028 chip=0x2a448086 rev=0x07 hdr=0x00 vendor = 'Intel Corporation' device = 'Mobile 4 Series Chipset MEI Controller' class = simple comms atapci0@pci0:0:3:2: class=0x010185 card=0x02501028 chip=0x2a468086 rev=0x07 hdr=0x00 vendor = 'Intel Corporation' device = 'Mobile 4 Series Chipset PT IDER Controller' class = mass storage subclass = ATA none1@pci0:0:3:3: class=0x070002 card=0x02501028 chip=0x2a478086 rev=0x07 hdr=0x00 vendor = 'Intel Corporation' device = 'Mobile 4 Series Chipset AMT SOL Redirection' class = simple comms subclass = UART em0@pci0:0:25:0: class=0x020000 card=0x02501028 chip=0x10f58086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '82567LM Gigabit Network Connection' class = network subclass = ethernet uhci0@pci0:0:26:0: class=0x0c0300 card=0x02501028 chip=0x29378086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '82801I (ICH9 Family) USB UHCI Controller' class = serial bus subclass = USB uhci1@pci0:0:26:1: class=0x0c0300 card=0x02501028 chip=0x29388086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '82801I (ICH9 Family) USB UHCI Controller' class = serial bus subclass = USB uhci2@pci0:0:26:2: class=0x0c0300 card=0x02501028 chip=0x29398086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '82801I (ICH9 Family) USB UHCI Controller' class = serial bus subclass = USB ehci0@pci0:0:26:7: class=0x0c0320 card=0x02501028 chip=0x293c8086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '82801I (ICH9 Family) USB2 EHCI Controller' class = serial bus subclass = USB hdac0@pci0:0:27:0: class=0x040300 card=0x02501028 chip=0x293e8086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '82801I (ICH9 Family) HD Audio Controller' class = multimedia subclass = HDA pcib2@pci0:0:28:0: class=0x060400 card=0x02501028 chip=0x29408086 rev=0x03 hdr=0x01 vendor = 'Intel Corporation' device = '82801I (ICH9 Family) PCI Express Port 1' class = bridge subclass = PCI-PCI pcib3@pci0:0:28:1: class=0x060400 card=0x02501028 chip=0x29428086 rev=0x03 hdr=0x01 vendor = 'Intel Corporation' device = '82801I (ICH9 Family) PCI Express Port 2' class = bridge subclass = PCI-PCI pcib4@pci0:0:28:2: class=0x060400 card=0x02501028 chip=0x29448086 rev=0x03 hdr=0x01 vendor = 'Intel Corporation' device = '82801I (ICH9 Family) PCI Express Port 3' class = bridge subclass = PCI-PCI pcib5@pci0:0:28:3: class=0x060400 card=0x02501028 chip=0x29468086 rev=0x03 hdr=0x01 vendor = 'Intel Corporation' device = '82801I (ICH9 Family) PCI Express Port 4' class = bridge subclass = PCI-PCI uhci3@pci0:0:29:0: class=0x0c0300 card=0x02501028 chip=0x29348086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '82801I (ICH9 Family) USB UHCI Controller' class = serial bus subclass = USB uhci4@pci0:0:29:1: class=0x0c0300 card=0x02501028 chip=0x29358086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '82801I (ICH9 Family) USB UHCI Controller' class = serial bus subclass = USB uhci5@pci0:0:29:2: class=0x0c0300 card=0x02501028 chip=0x29368086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '82801I (ICH9 Family) USB UHCI Controller' class = serial bus subclass = USB ehci1@pci0:0:29:7: class=0x0c0320 card=0x02501028 chip=0x293a8086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '82801I (ICH9 Family) USB2 EHCI Controller' class = serial bus subclass = USB pcib6@pci0:0:30:0: class=0x060401 card=0x02501028 chip=0x24488086 rev=0x93 hdr=0x01 vendor = 'Intel Corporation' device = '82801 Mobile PCI Bridge' class = bridge subclass = PCI-PCI isab0@pci0:0:31:0: class=0x060100 card=0x02501028 chip=0x29178086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = 'ICH9M-E LPC Interface Controller' class = bridge subclass = PCI-ISA ahci0@pci0:0:31:2: class=0x010601 card=0x02501028 chip=0x29298086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = 'ICH9M/M-E SATA AHCI Controller' class = mass storage subclass = SATA ichsmb0@pci0:0:31:3: class=0x0c0500 card=0x02501028 chip=0x29308086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '82801I (ICH9 Family) SMBus Controller' class = serial bus subclass = SMBus vgapci0@pci0:1:0:0: class=0x030000 card=0x02501028 chip=0x065c10de rev=0xa1 hdr=0x00 vendor = 'nVidia Corporation' device = 'G96M [Quadro FX 770M]' class = display subclass = VGA iwn0@pci0:12:0:0: class=0x028000 card=0x11218086 chip=0x42358086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = 'Ultimate N WiFi Link 5300' class = network cbb0@pci0:3:1:0: class=0x060700 card=0x02501028 chip=0x04761180 rev=0xba hdr=0x02 vendor = 'Ricoh Co Ltd' device = 'RL5c476 II' class = bridge subclass = PCI-CardBus fwohci0@pci0:3:1:1: class=0x0c0010 card=0x02501028 chip=0x08321180 rev=0x04 hdr=0x00 vendor = 'Ricoh Co Ltd' device = 'R5C832 IEEE 1394 Controller' class = serial bus subclass = FireWire sdhci0@pci0:3:1:2: class=0x080501 card=0x02501028 chip=0x08221180 rev=0x21 hdr=0x00 vendor = 'Ricoh Co Ltd' device = 'R5C822 SD/SDIO/MMC/MS/MSPro Host Adapter' class = base peripheral subclass = SD host controller none2@pci0:3:1:3: class=0x088000 card=0x02501028 chip=0x08431180 rev=0x11 hdr=0x00 vendor = 'Ricoh Co Ltd' device = 'R5C843 MMC Host Controller' class = base peripheral --n8g4imXOkfNTN/H1-- --dc+cDN39EJAMEtIO Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlCET7wACgkQmprOCmdXAD1htwCfSoEWCJx9rXz8jkH0TjoXfK4p wXEAnRdDvYPOaa0OyRaYLtXhMj0f5WaZ =kSe5 -----END PGP SIGNATURE----- --dc+cDN39EJAMEtIO-- From owner-freebsd-stable@FreeBSD.ORG Sun Oct 21 20:23:47 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7F069AD; Sun, 21 Oct 2012 20:23:47 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (m209-73.dsl.rawbw.com [198.144.209.73]) by mx1.freebsd.org (Postfix) with ESMTP id 10D848FC0C; Sun, 21 Oct 2012 20:23:47 +0000 (UTC) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.5/8.14.5) with ESMTP id q9LKNki1002197; Sun, 21 Oct 2012 13:23:46 -0700 (PDT) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.5/8.14.5/Submit) id q9LKNk0H002196; Sun, 21 Oct 2012 13:23:46 -0700 (PDT) (envelope-from david) Date: Sun, 21 Oct 2012 13:23:46 -0700 From: David Wolfskill To: Alexander Motin Subject: Re: stable/9 @r241776 panic: REDZONE: Buffer underflow detected... Message-ID: <20121021202346.GB1609@albert.catwhisker.org> References: <20121020141019.GW1817@albert.catwhisker.org> <20121021121356.GJ35915@deviant.kiev.zoral.com.ua> <20121021163322.GB1730@albert.catwhisker.org> <20121021164634.GC1730@albert.catwhisker.org> <20121021174054.GM35915@deviant.kiev.zoral.com.ua> <50843EB6.8030407@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="1ccMZA6j1vT5UqiK" Content-Disposition: inline In-Reply-To: <50843EB6.8030407@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 21 Oct 2012 20:23:47 -0000 --1ccMZA6j1vT5UqiK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Oct 21, 2012 at 09:28:06PM +0300, Alexander Motin wrote: > ... > I am curious, how to interpret phrase "42=3D94966796 bytes allocated" in= =20 > log. May be it is just corrupted output, but the number still seems=20 > quite big, especially for i386 system, making me think about some=20 > integer overflow. David, could you write down that part once more? >=20 > Having few more lines of "Allocation backtrace:" could also be useful. >=20 > Could you show your kernel config? I can try to run it on my tests=20 > system, hoping to reproduce the problem. > ... I was unable to get serial console to work, even with the USB<=3D>serial dongle. However, I did find that the ddb "dump" command appears to have operated appropriately, and so I now have a dump. That, as well as the core.txt and additinal copies of the kernel config ("CANARY") and dmesg.boot have been copied, and are now accessible from . For a quick reality check, here's the stuff (cut/pasted from core.txt.4) that I had hand-written in my initial message: <118>Starting devd. REDZONE: Buffer underflow detected. 1 byte corrupted before 0xced40080 (429= 4966796 bytes allocated). Allocation backtrace: #0 0xc0ceaa8f at redzone_setup+0xcf #1 0xc0a5d5c9 at malloc+0x1d9 #2 0xc0a9ead0 at devctl_queue_data_f+0x40 #3 0xc0aa3fba at devaddq+0x20a #4 0xc0aa098d at device_probe+0xad #5 0xc0aa1c9f at bus_generic_attach+0x1f #6 0xc07bcb1a at vga_pci_attach+0x4a #7 0xc0aa0de4 at device_attach+0x3b4 #8 0xc0aa1cab at bus_generic_attach+0x2b #9 0xc0531865 at acpi_pci_attach+0x185 #10 0xc0aa0de4 at device_attach+0x3b4 #11 0xc0aa1cab at bus_generic_attach+0x2b #12 0xc05339c2 at acpi_pcib_attach+0x262 #13 0xc0534cbf at acpi_pcib_pci_attach+0x9f #14 0xc0aa0de4 at device_attach+0x3b4 #15 0xc0aa1cab at bus_generic_attach+0x2b #16 0xc0531865 at acpi_pci_attach+0x185 #17 0xc0aa0de4 at device_attach+0x3b4 Free backtrace: #0 0xc0cead4a at redzone_check+0x1ca #1 0xc0a5d618 at free+0x38 #2 0xc0a9e956 at devread+0x1a6 #3 0xc0a28807 at giant_read+0x87 #4 0xc09710c6 at devfs_read_f+0xc6 #5 0xc0aba8d9 at dofileread+0x99 #6 0xc0aba4f8 at sys_read+0x98 #7 0xc0ddf977 at syscall+0x387 #8 0xc0dc87d1 at Xint0x80_syscall+0x21 REDZONE: Buffer overflow detected. 16 bytes corrupted after 0xced3fe8c (429= 4966796 bytes allocated). Allocation backtrace: #0 0xc0ceaa8f at redzone_setup+0xcf #1 0xc0a5d5c9 at malloc+0x1d9 #2 0xc0a9ead0 at devctl_queue_data_f+0x40 #3 0xc0aa3fba at devaddq+0x20a #4 0xc0aa098d at device_probe+0xad #5 0xc0aa1c9f at bus_generic_attach+0x1f #6 0xc07bcb1a at vga_pci_attach+0x4a #7 0xc0aa0de4 at device_attach+0x3b4 #8 0xc0aa1cab at bus_generic_attach+0x2b #9 0xc0531865 at acpi_pci_attach+0x185 #10 0xc0aa0de4 at device_attach+0x3b4 #11 0xc0aa1cab at bus_generic_attach+0x2b #12 0xc05339c2 at acpi_pcib_attach+0x262 #13 0xc0534cbf at acpi_pcib_pci_attach+0x9f #14 0xc0aa0de4 at device_attach+0x3b4 #15 0xc0aa1cab at bus_generic_attach+0x2b #16 0xc0531865 at acpi_pci_attach+0x185 #17 0xc0aa0de4 at device_attach+0x3b4 Free backtrace: #0 0xc0ceae92 at redzone_check+0x312 #1 0xc0a5d618 at free+0x38 #2 0xc0a9e956 at devread+0x1a6 #3 0xc0a28807 at giant_read+0x87 #4 0xc09710c6 at devfs_read_f+0xc6 #5 0xc0aba8d9 at dofileread+0x99 #6 0xc0aba4f8 at sys_read+0x98 #7 0xc0ddf977 at syscall+0x387 #8 0xc0dc87d1 at Xint0x80_syscall+0x21 panic: free: address 0xced3f080(0xced3f000) has not been allocated. cpuid =3D 1 KDB: stack backtrace: db_trace_self_wrapper(c0f99230,c09710c6,c0aba8d9,c0734d37,c1131d40,...) at = 0xc051d25e =3D db_trace_self_wrapper+0x2e kdb_backtrace(c0fd3355,1,c0f94756,f7231ae8,c0aa1cab,...) at 0xc0aa7eda =3D = kdb_backtrace+0x2a panic(c0f94756,ced3f080,ced3f000,cebe4400,ced40080,...) at 0xc0a73bd4 =3D p= anic+0x1a4 free(ced40080,c10c3660,f7231c0c,c0b1e30d,ce7ef000,...) at 0xc0a5d6f9 =3D fr= ee+0x119 devread(ce8c2d00,f7231c0c,0,c0b1e4f0,d279ca48,...) at 0xc0a9e956 =3D devrea= d+0x1a6 giant_read(ce8c2d00,f7231c0c,0,400,0,...) at 0xc0a28807 =3D giant_read+0x87 devfs_read_f(d279ca48,f7231c0c,ce84b680,0,d2797000,...) at 0xc09710c6 =3D d= evfs_read_f+0xc6 dofileread(d279ca48,f7231c0c,ffffffff,ffffffff,0,...) at 0xc0aba8d9 =3D dof= ileread+0x99 sys_read(d2797000,f7231ccc,c0a7c784,d2797000,0,...) at 0xc0aba4f8 =3D sys_r= ead+0x98 syscall(f7231d08) at 0xc0ddf977 =3D syscall+0x387 Xint0x80_syscall() at 0xc0dc87d1 =3D Xint0x80_syscall+0x21 --- syscall (3, FreeBSD ELF32, sys_read), eip =3D 0x808f14b, esp =3D 0xbfbf= d92c, ebp =3D 0xbfbfde58 --- KDB: enter: panic =2E.. (kgdb) #0 doadump (textdump=3DVariable "textdump" is not available. ) at pcpu.h:249 #1 0xc051b353 in db_dump (dummy=3D-148694992, dummy2=3D-148694992,=20 dummy3=3D-148694992, dummy4=3D0xf7231830 "") at /usr/src/sys/ddb/db_command.c:538 #2 0xc051ae45 in db_command (cmd_table=3DVariable "cmd_table" is not avail= able. ) at /usr/src/sys/ddb/db_command.c:449 #3 0xc051abd0 in db_command_loop () at /usr/src/sys/ddb/db_command.c:502 #4 0xc051d3be in db_trap (type=3DUnhandled dwarf expression opcode 0xc0 ) at /usr/src/sys/ddb/db_main.c:231 #5 0xc0aa8464 in kdb_trap (tf=3DUnhandled dwarf expression opcode 0xc0 ) at /usr/src/sys/kern/subr_kdb.c:649 #6 0xc0ddebde in trap (frame=3DVariable "frame" is not available. ) at /usr/src/sys/i386/i386/trap.c:715 #7 0xc0dc876c in calltrap () at /tmp/exception-ceSooo.s:94 #8 0xc0aa7cdd in kdb_enter (why=3DVariable "why" is not available. ) at cpufunc.h:71 #9 0xc0a73bf4 in panic (fmt=3DUnhandled dwarf expression opcode 0xc0 ) at /usr/src/sys/kern/kern_shutdown.c:627 #10 0xc0a5d6f9 in free (addr=3DUnhandled dwarf expression opcode 0xc0 ) at /usr/src/sys/kern/kern_malloc.c:545 #11 0xc0a9e956 in devread (dev=3D0xf7231b14, uio=3DVariable "uio" is not av= ailable. ) at /usr/src/sys/kern/subr_bus.c:473 #12 0xc0a28807 in giant_read (dev=3DVariable "dev" is not available. ) at /usr/src/sys/kern/kern_conf.c:443 #13 0xc09710c6 in devfs_read_f (fp=3DVariable "fp" is not available. ) at /usr/src/sys/fs/devfs/devfs_vnops.c:1177 #14 0xc0aba8d9 in dofileread (td=3DVariable "td" is not available. ) at file.h:286 #15 0xc0aba4f8 in sys_read (td=3DVariable "td" is not available. ) at /usr/src/sys/kern/sys_generic.c:250 #16 0xc0ddf977 in syscall (frame=3DVariable "frame" is not available. ) at subr_syscall.c:135 #17 0xc0dc87d1 in Xint0x80_syscall () at /tmp/exception-ceSooo.s:134 #18 0x00000033 in ?? () Previous frame inner to this frame (corrupt stack?) Current language: auto; currently minimal (kgdb)=20 Anyway: all that (and more!) is available from ; I cite the above mostly as evidence that I might not have been hallucinating. :-} Peace, david --=20 David H. Wolfskill david@catwhisker.org Taliban: Evil men with guns afraid of truth from a 14-year old girl. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --1ccMZA6j1vT5UqiK Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlCEWRIACgkQmprOCmdXAD3P9QCfThfe0nA/m+gJ9z+xubDJXt8k P4UAn3zC+nndA4Vv7g3/o5PK7IJDsbgY =sj2x -----END PGP SIGNATURE----- --1ccMZA6j1vT5UqiK-- From owner-freebsd-stable@FreeBSD.ORG Sun Oct 21 22:03:49 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B47BD5A5 for ; Sun, 21 Oct 2012 22:03:49 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id 296408FC12 for ; Sun, 21 Oct 2012 22:03:48 +0000 (UTC) Received: by mail-lb0-f182.google.com with SMTP id b5so1652737lbd.13 for ; Sun, 21 Oct 2012 15:03:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=YueX42wNGQa3nDyJ5wdfurYDIxVF2da8Iw7XIhRVLZs=; b=HkQ7gyI31yAqs0rtUDRISYemPc99PpyiEQVmBTrTy3NnRu0m/O0P+7qw7tRIWE72/H sGw3LbDYOXcF3Sgdp/2oSMD70vwtExjpzi1fCFiU1G6sZ/alZezZYEjeNfCnYuTloJJ3 /1DoVSDc8MUNIDnAEwnrVBlOYYoXoohihxFEi31VtFzYNrMlnzWi8TF9PMi+tY6SSyLM Loe0Y5RL/r5T32r7GbsJGLRZLmFkXnmerX/WPKfFG4mHwS+F6Q50dTXbdoDxaz+2171w xR1E6HWrgTmnLUte7PzSJw68r0cMCFJGN0eYtTutMnYgWV/yhQ91dtxilTNZdSIVxJZo dMkQ== Received: by 10.112.88.39 with SMTP id bd7mr2893547lbb.119.1350857027150; Sun, 21 Oct 2012 15:03:47 -0700 (PDT) Received: from mavbook.mavhome.dp.ua (mavhome.mavhome.dp.ua. [213.227.240.37]) by mx.google.com with ESMTPS id p9sm2514389lbc.3.2012.10.21.15.03.45 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 21 Oct 2012 15:03:46 -0700 (PDT) Sender: Alexander Motin Message-ID: <5084713A.1050200@FreeBSD.org> Date: Mon, 22 Oct 2012 01:03:38 +0300 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120628 Thunderbird/13.0.1 MIME-Version: 1.0 To: David Wolfskill Subject: Re: stable/9 @r241776 panic: REDZONE: Buffer underflow detected... References: <20121020141019.GW1817@albert.catwhisker.org> <20121021121356.GJ35915@deviant.kiev.zoral.com.ua> <20121021163322.GB1730@albert.catwhisker.org> <20121021164634.GC1730@albert.catwhisker.org> <20121021174054.GM35915@deviant.kiev.zoral.com.ua> <50843EB6.8030407@FreeBSD.org> <20121021202346.GB1609@albert.catwhisker.org> In-Reply-To: <20121021202346.GB1609@albert.catwhisker.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 21 Oct 2012 22:03:49 -0000 On 21.10.2012 23:23, David Wolfskill wrote: > On Sun, Oct 21, 2012 at 09:28:06PM +0300, Alexander Motin wrote: >> ... >> I am curious, how to interpret phrase "42=94966796 bytes allocated" in >> log. May be it is just corrupted output, but the number still seems >> quite big, especially for i386 system, making me think about some >> integer overflow. David, could you write down that part once more? >> >> Having few more lines of "Allocation backtrace:" could also be useful. >> >> Could you show your kernel config? I can try to run it on my tests >> system, hoping to reproduce the problem. >> ... I've used your kernel config and my test system was unable to boot from NFS, while GENERIC kernel boots fine. I haven't got panic, but boot just stopped on root mounting. You have so many options specified there so I can't predict which of them could cause this. Now I am trying to binary search for the problematic one(s). -- Alexander Motin From owner-freebsd-stable@FreeBSD.ORG Sun Oct 21 22:09:19 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EC5C375E for ; Sun, 21 Oct 2012 22:09:19 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by mx1.freebsd.org (Postfix) with ESMTP id 71BF38FC17 for ; Sun, 21 Oct 2012 22:09:19 +0000 (UTC) Received: by mail-wi0-f178.google.com with SMTP id hr7so1549528wib.13 for ; Sun, 21 Oct 2012 15:09:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=ReOsBTDD6AxaIhe2dO3ZC5zwm2x1QqnUaQS3hrWbN54=; b=XoAH+isrK9j7QzzpSO6Gwbey2a0Mi6duLTapZ6RvEbweQtmJndJ0VYF/Hf6Dyt0Z1B hnrmyY09dHeexCDdiQH+g45kPcdau9malLfgqsUpcXZv5y7V1TfUVeqbVpDuJ/+zJ86v IDDWEjrSMhxPsOhdMJYSupEJ9CHN69Mp05BbmZV41L1yCpDDP2tmu0P9cpdV5XU87Ikj UqDcnJLKnwzWLkh0h+pM7duf/xdGJpj3Y8751uTYVHI0d1zZtySFX1QaIvVp8dt8/4LS +w5WGUyWzBTsllDuL//O4j4qDC8cvqqK6xev/t9UFNxJIv72JUovWA92OuLH4X/85Xei iz5w== Received: by 10.180.79.202 with SMTP id l10mr16756637wix.9.1350857358212; Sun, 21 Oct 2012 15:09:18 -0700 (PDT) Received: from dft-labs.eu (n1x0n-1-pt.tunnel.tserv5.lon1.ipv6.he.net. [2001:470:1f08:1f7::2]) by mx.google.com with ESMTPS id ay10sm18345452wib.2.2012.10.21.15.09.17 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 21 Oct 2012 15:09:17 -0700 (PDT) Date: Mon, 22 Oct 2012 00:09:08 +0200 From: Mateusz Guzik To: David Wolfskill Subject: Re: stable/9 @r241776 panic: REDZONE: Buffer underflow detected... Message-ID: <20121021220908.GA20958@dft-labs.eu> References: <20121020141019.GW1817@albert.catwhisker.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20121020141019.GW1817@albert.catwhisker.org> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 21 Oct 2012 22:09:20 -0000 On Sat, Oct 20, 2012 at 07:10:19AM -0700, David Wolfskill wrote: > This seems ... fairly weird to me. > > Yesterday, I built & booted: > > FreeBSD g1-227.catwhisker.org 9.1-PRERELEASE FreeBSD 9.1-PRERELEASE #274 241726M: Fri Oct 19 05:40:05 PDT 2012 root@g1-227.catwhisker.org:/usr/obj/usr/src/sys/CANARY i386 > > and used the machine all day; nothing unusual (including various > reboots (e.g. when I disembarked the train for the final leg of my > commute home, so I powered the laptop off). > > This morning, I built: > > FreeBSD g1-227.catwhisker.org 9.1-PRERELEASE FreeBSD 9.1-PRERELEASE #275 241776M: Sat Oct 20 04:34:45 PDT 2012 root@g1-227.catwhisker.org:/usr/obj/usr/src/sys/CANARY i386 > > and on first reboot, I got a panic. > [..] > > ... > Starting devd. > REDZONE: Buffer underflow detected. 1 byte corrupted before 0xced40080 (4294966796 bytes allocated). > Allocation backtrace: > #0 0xc0ceac8f at redzone_setup+0xcf > #1 0xc0a5d5c9 at malloc+0x1d9 > ...[about 20 more such lines I didn't record]... > > > bt > Tracing pid 901 tid 100106 td 0xd2b99000 > kdb_enter(...) > panic(...) > free(...) > devread(ce8c2d00,f7274c0c,0,c0b1e4f0,d279e380,...) at devread+0x1a6 > giant_read(...) at giant_read+0x87 > devfs_read(...) at devfs_read+0xc6 > dofileread(...) at dofileread+0x99 > sys_read(...) at sys_read+0x98 > syscall(f7274d08) at syscall+0x387 > This looks a lot like issue you reported a couple of months earlier, even affected buffer address matches. At least part of REDZONE metadata placed directly before the buffer is corrupted. So the idea is to set a watchpoint at a place that is known to contain wrong data (in this case allocation size) and wait for some code to try to modify it. I hacked up the following (really ugly, but should do the job): http://people.freebsd.org/~mjg/patches/watchpoint-hack.diff Note: this assumes that address of affected buffer is always the same. Assuming I didn't mess anything up, instructions are simple: Just try to reproduce the issue, at some point you should be dropped to the debugger. If that happens when dumpdevice is configured, please get a core. Otherwise just a backtrace ("bt" command). Note 2: this code does no clear the watchpoint, so if it fails to catch the offending case, it may catch completely legitimate code later. From owner-freebsd-stable@FreeBSD.ORG Sun Oct 21 22:31:10 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6F19B7C for ; Sun, 21 Oct 2012 22:31:10 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id C52538FC0A for ; Sun, 21 Oct 2012 22:31:09 +0000 (UTC) Received: by mail-lb0-f182.google.com with SMTP id b5so1661197lbd.13 for ; Sun, 21 Oct 2012 15:31:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=G0Upl6jjlZDJ8S1SM6jWhCrhAHxmr7rkIn+rQOnCzyU=; b=SGDmUzRRNMyojJ/jqdh3vvSAblOK6SmvJXkmHk9Palo+Xn3keHjnX9WT219zCGik+g 7s21ZIxAH6+EExD9edLEvRIPno35c3yd4tunJnYdT9AxsHEbXnWyLqD5p5fEnmH8wyay NwJThnvKIY3+aQTl/zVMfh7mInEIJkJPIUEEVxEB+7nA27L/tH2QX5Y4TA/IefrlwqDg Zp7Nm37I+5xQzZPKkgz88X/nhGU87NohDKnP3NLXiqaLWBeN84SEKmt/RxFQ5WjYl9OK 35hAqWR1n+7Y5/OFiNfJOhvs3SDtYxijQ6Al1Sg1YJFySakFqczvt07Fujz+/6TaYDZh /6ow== Received: by 10.152.105.135 with SMTP id gm7mr6600415lab.22.1350858668278; Sun, 21 Oct 2012 15:31:08 -0700 (PDT) Received: from mavbook.mavhome.dp.ua (mavhome.mavhome.dp.ua. [213.227.240.37]) by mx.google.com with ESMTPS id y10sm2525799lbg.4.2012.10.21.15.31.06 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 21 Oct 2012 15:31:07 -0700 (PDT) Sender: Alexander Motin Message-ID: <508477A8.2040609@FreeBSD.org> Date: Mon, 22 Oct 2012 01:31:04 +0300 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120628 Thunderbird/13.0.1 MIME-Version: 1.0 To: David Wolfskill Subject: Re: stable/9 @r241776 panic: REDZONE: Buffer underflow detected... References: <20121020141019.GW1817@albert.catwhisker.org> <20121021121356.GJ35915@deviant.kiev.zoral.com.ua> <20121021163322.GB1730@albert.catwhisker.org> <20121021164634.GC1730@albert.catwhisker.org> <20121021174054.GM35915@deviant.kiev.zoral.com.ua> <50843EB6.8030407@FreeBSD.org> <20121021202346.GB1609@albert.catwhisker.org> <5084713A.1050200@FreeBSD.org> In-Reply-To: <5084713A.1050200@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 21 Oct 2012 22:31:10 -0000 On 22.10.2012 01:03, Alexander Motin wrote: > On 21.10.2012 23:23, David Wolfskill wrote: >> On Sun, Oct 21, 2012 at 09:28:06PM +0300, Alexander Motin wrote: >>> ... >>> I am curious, how to interpret phrase "42=94966796 bytes allocated" in >>> log. May be it is just corrupted output, but the number still seems >>> quite big, especially for i386 system, making me think about some >>> integer overflow. David, could you write down that part once more? >>> >>> Having few more lines of "Allocation backtrace:" could also be useful. >>> >>> Could you show your kernel config? I can try to run it on my tests >>> system, hoping to reproduce the problem. >>> ... > > I've used your kernel config and my test system was unable to boot from > NFS, while GENERIC kernel boots fine. I haven't got panic, but boot just > stopped on root mounting. You have so many options specified there so I > can't predict which of them could cause this. Now I am trying to binary > search for the problematic one(s). Sorry. false alarm. I was just closed firewall in your kernel config. Without it my test system boots your kernel without any problem. -- Alexander Motin From owner-freebsd-stable@FreeBSD.ORG Sun Oct 21 22:32:48 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4891B19D for ; Sun, 21 Oct 2012 22:32:48 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (m209-73.dsl.rawbw.com [198.144.209.73]) by mx1.freebsd.org (Postfix) with ESMTP id F3D808FC0C for ; Sun, 21 Oct 2012 22:32:46 +0000 (UTC) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.5/8.14.5) with ESMTP id q9LMWkuL002967; Sun, 21 Oct 2012 15:32:46 -0700 (PDT) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.5/8.14.5/Submit) id q9LMWkv2002966; Sun, 21 Oct 2012 15:32:46 -0700 (PDT) (envelope-from david) Date: Sun, 21 Oct 2012 15:32:46 -0700 From: David Wolfskill To: Mateusz Guzik Subject: Re: stable/9 @r241776 panic: REDZONE: Buffer underflow detected... Message-ID: <20121021223246.GD1609@albert.catwhisker.org> References: <20121020141019.GW1817@albert.catwhisker.org> <20121021220908.GA20958@dft-labs.eu> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="DqhR8hV3EnoxUkKN" Content-Disposition: inline In-Reply-To: <20121021220908.GA20958@dft-labs.eu> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 21 Oct 2012 22:32:48 -0000 --DqhR8hV3EnoxUkKN Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Oct 22, 2012 at 12:09:08AM +0200, Mateusz Guzik wrote: > ... > This looks a lot like issue you reported a couple of months earlier, > even affected buffer address matches. It's a tad scary that someone else notices that sort of thing before I do. :-} > At least part of REDZONE metadata placed directly before the buffer is > corrupted. So the idea is to set a watchpoint at a place that is known > to contain wrong data (in this case allocation size) and wait for some > code to try to modify it. >=20 > I hacked up the following (really ugly, but should do the job): > http://people.freebsd.org/~mjg/patches/watchpoint-hack.diff >=20 > Note: this assumes that address of affected buffer is always the same. >=20 > Assuming I didn't mess anything up, instructions are simple: > Just try to reproduce the issue, at some point you should be dropped to > the debugger. If that happens when dumpdevice is configured, please get a > core. Otherwise just a backtrace ("bt" command). Well, the problem was occurring (only, and reproducibly) during the transition from single-user mode to multi-user mode. Perhaps more frustrating: after building & installing the kernel with that patch, apparently locations of things were adjusted in such a way that the panic did not recur. > Note 2: this code does no clear the watchpoint, so if it fails to catch > the offending case, it may catch completely legitimate code later. Fun! :-) Thanks! Peace, david --=20 David H. Wolfskill david@catwhisker.org Taliban: Evil men with guns afraid of truth from a 14-year old girl. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --DqhR8hV3EnoxUkKN Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlCEeA0ACgkQmprOCmdXAD1ZEgCeOo7C/DWaG/HnaNw/aKr/trgx MK0Anj5PEp0uPEgSWA2lxrXaZF42tS1e =xU/f -----END PGP SIGNATURE----- --DqhR8hV3EnoxUkKN-- From owner-freebsd-stable@FreeBSD.ORG Sun Oct 21 22:46:49 2012 Return-Path: Delivered-To: stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5CC403B9; Sun, 21 Oct 2012 22:46:49 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (m209-73.dsl.rawbw.com [198.144.209.73]) by mx1.freebsd.org (Postfix) with ESMTP id B3A7A8FC08; Sun, 21 Oct 2012 22:46:48 +0000 (UTC) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.5/8.14.5) with ESMTP id q9LMkmwb003133; Sun, 21 Oct 2012 15:46:48 -0700 (PDT) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.5/8.14.5/Submit) id q9LMkmMJ003132; Sun, 21 Oct 2012 15:46:48 -0700 (PDT) (envelope-from david) Date: Sun, 21 Oct 2012 15:46:48 -0700 From: David Wolfskill To: Alexander Motin Subject: Re: stable/9 @r241776 panic: REDZONE: Buffer underflow detected... Message-ID: <20121021224648.GE1609@albert.catwhisker.org> References: <20121020141019.GW1817@albert.catwhisker.org> <20121021121356.GJ35915@deviant.kiev.zoral.com.ua> <20121021163322.GB1730@albert.catwhisker.org> <20121021164634.GC1730@albert.catwhisker.org> <20121021174054.GM35915@deviant.kiev.zoral.com.ua> <50843EB6.8030407@FreeBSD.org> <20121021202346.GB1609@albert.catwhisker.org> <5084713A.1050200@FreeBSD.org> <508477A8.2040609@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ni93GHxFvA+th69W" Content-Disposition: inline In-Reply-To: <508477A8.2040609@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: stable@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 21 Oct 2012 22:46:49 -0000 --ni93GHxFvA+th69W Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Oct 22, 2012 at 01:31:04AM +0300, Alexander Motin wrote: > ... > > I've used your kernel config and my test system was unable to boot from > > NFS, while GENERIC kernel boots fine. I haven't got panic, but boot just > > stopped on root mounting. You have so many options specified there so I > > can't predict which of them could cause this. Now I am trying to binary > > search for the problematic one(s). >=20 > Sorry. false alarm. I was just closed firewall in your kernel config.=20 > Without it my test system boots your kernel without any problem. > ... OK. I tried the watchpoint patch mjg@ sent; as noted in my response to him, I did not see the problem recur when I booted the resulting kernel. And given your observation, as well as that I've updated 4 other stable/9 systems (sources at r241801 for 3 of them; at r241786 for the other), none of which exhibited the problem, I suspect that something is remarkably sensitive to the storage layout. Hmmm... Peace, david --=20 David H. Wolfskill david@catwhisker.org Taliban: Evil men with guns afraid of truth from a 14-year old girl. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --ni93GHxFvA+th69W Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlCEe1cACgkQmprOCmdXAD3u4wCdHcUodAPaeSMDz6Dm2qUBciqO roIAn1tyuNSO+Ovd9OQ2B1E/EZajognY =K1UT -----END PGP SIGNATURE----- --ni93GHxFvA+th69W-- From owner-freebsd-stable@FreeBSD.ORG Mon Oct 22 00:25:35 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2D0D21A3 for ; Mon, 22 Oct 2012 00:25:35 +0000 (UTC) (envelope-from mailer-daemon@vniz.net) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id 93F848FC0A for ; Mon, 22 Oct 2012 00:25:34 +0000 (UTC) Received: by mail-lb0-f182.google.com with SMTP id b5so1696417lbd.13 for ; Sun, 21 Oct 2012 17:25:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:disposition-notification-to:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to:openpgp :content-type:content-transfer-encoding:x-gm-message-state; bh=LbF33pDGW5UNUeaV93OK4sS4W9I4EnSyErqaaIlLTV4=; b=b80yqcatINcAxFldzeqHQIhyjhHBmbM9FU+LiQPYZa7yzBxSxveADcRYrYHL//ma3f 9s+V88ELAik0vkQPU1xw8fsabNwl5VgnO8Q8SEZgRo2j0cg3/R+NHWVQUTbNdCEbz34u 4anYql7guR26Kz+DzsFJnlQ9tLHlSIWv2UY+D1K6lT25fbLzYsOtUejKo/z2+ZNWum8W lRX1GwO7N2mGA7rujnBDNlhqCp86gPwA7UZssGxP9X1VNeUoNfzAGomNX7xWLus0f7+H xMtuEsOtkeTQbvwWS/ni/tyR2/BMCMmah4VveUb9DlRHiKsvzdcuHt3ysH5iab1pTivm nfMw== Received: by 10.152.108.42 with SMTP id hh10mr6649539lab.4.1350865533371; Sun, 21 Oct 2012 17:25:33 -0700 (PDT) Received: from [192.168.1.2] ([89.169.140.97]) by mx.google.com with ESMTPS id p9sm2568270lbc.3.2012.10.21.17.25.32 (version=SSLv3 cipher=OTHER); Sun, 21 Oct 2012 17:25:32 -0700 (PDT) Message-ID: <5084927C.1070101@freebsd.org> Date: Mon, 22 Oct 2012 04:25:32 +0400 From: Andrey Chernov User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: John Baldwin Subject: Re: ${CTFCONVERT_CMD} expands to empty string References: <5081F92F.8040004@freebsd.org> <201210200838.18297.jhb@freebsd.org> <508317A4.2060800@freebsd.org> In-Reply-To: <508317A4.2060800@freebsd.org> OpenPGP: id=964474DD Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQlPcwNq55ujjz6m6E2WYp1UCFnUs0kT2hpAreUUVtHSaU72xrxeY7G43vFzmgVOJ2+ZMZSa Cc: stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 22 Oct 2012 00:25:35 -0000 Those lines cause this error: .if ${MK_CTF} != "no" CTFCONVERT_CMD= ${CTFCONVERT} ${CTFFLAGS} ${.TARGET} .elif ${MAKE_VERSION} >= 5201111300 CTFCONVERT_CMD= .else CTFCONVERT_CMD= @: .endif My make version is 9201206140 So, either the check for >= 5201111300 is incorrect or change for empty make variables expansion is not merged into stable-9 On 21.10.2012 1:29, Andrey Chernov wrote: > On 20.10.2012 16:38, John Baldwin wrote: >> On Friday, October 19, 2012 09:06:55 PM Andrey Chernov wrote: >>> On recent -stable I got a lots of (see subj) now due to CTF changes in >>> *.mk files. >>> I have >>> WITHOUT_CDDL=yes >>> in my /etc/src.conf and WITHOUT_CDDL have wider scope than WITHOUT_CTF >>> suggested, but WITHOUT_CDDL is not checked in recent CTF changes. >>> Please fix this thing. >> >> Which stable? > > stable-9 > From owner-freebsd-stable@FreeBSD.ORG Mon Oct 22 00:28:51 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 42B952B1; Mon, 22 Oct 2012 00:28:51 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 9A40A8FC0C; Mon, 22 Oct 2012 00:28:50 +0000 (UTC) Received: by mail-wg0-f50.google.com with SMTP id 16so1788085wgi.31 for ; Sun, 21 Oct 2012 17:28:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=PcBbXYiOSAeHcvzo73ngGzzpYItHBgYWh+Ie0q7rY0w=; b=FqtPi9MI0RcrevlhxX595lRcqmnesgOx1Gbs6+EmerHkZZjMOurdpX/L43qc+7depg 66wZVgymUlQeI5srn1g9U9k2kVnSJKGY6btnp08mZdW8a53d/ihY7NL/Mk5IWsXgdXwf vPV5D+BYmZcuCxRNQ1lSdTZNzAmzHV6bcsCHFpIxWoonRIyEz4Ya/Wx46z9GSh6OLwl+ rIu6LSz5lCln02laPKOJ9EvIE4keSaV+y979youRyXI/NDs0Fgw5lDBspdPUbkFgNpk0 lAiPd27L4t6Pog1stakkbvU2z6tj1McgYrwTFUuI2i//QsLLWQojcQklY0udr3gChSin EUJQ== MIME-Version: 1.0 Received: by 10.180.87.132 with SMTP id ay4mr17252121wib.5.1350865729431; Sun, 21 Oct 2012 17:28:49 -0700 (PDT) Received: by 10.223.66.194 with HTTP; Sun, 21 Oct 2012 17:28:49 -0700 (PDT) In-Reply-To: <20121021224648.GE1609@albert.catwhisker.org> References: <20121020141019.GW1817@albert.catwhisker.org> <20121021121356.GJ35915@deviant.kiev.zoral.com.ua> <20121021163322.GB1730@albert.catwhisker.org> <20121021164634.GC1730@albert.catwhisker.org> <20121021174054.GM35915@deviant.kiev.zoral.com.ua> <50843EB6.8030407@FreeBSD.org> <20121021202346.GB1609@albert.catwhisker.org> <5084713A.1050200@FreeBSD.org> <508477A8.2040609@FreeBSD.org> <20121021224648.GE1609@albert.catwhisker.org> Date: Sun, 21 Oct 2012 17:28:49 -0700 Message-ID: Subject: Re: stable/9 @r241776 panic: REDZONE: Buffer underflow detected... From: Kevin Oberman To: David Wolfskill Content-Type: text/plain; charset=UTF-8 Cc: Alexander Motin , stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 22 Oct 2012 00:28:51 -0000 On Sun, Oct 21, 2012 at 3:46 PM, David Wolfskill wrote: > On Mon, Oct 22, 2012 at 01:31:04AM +0300, Alexander Motin wrote: >> ... >> > I've used your kernel config and my test system was unable to boot from >> > NFS, while GENERIC kernel boots fine. I haven't got panic, but boot just >> > stopped on root mounting. You have so many options specified there so I >> > can't predict which of them could cause this. Now I am trying to binary >> > search for the problematic one(s). >> >> Sorry. false alarm. I was just closed firewall in your kernel config. >> Without it my test system boots your kernel without any problem. >> ... > > OK. > > I tried the watchpoint patch mjg@ sent; as noted in my response to him, > I did not see the problem recur when I booted the resulting kernel. > > And given your observation, as well as that I've updated 4 other > stable/9 systems (sources at r241801 for 3 of them; at r241786 for the > other), none of which exhibited the problem, I suspect that something is > remarkably sensitive to the storage layout. > > Hmmm... This is starting to smell a bit like it may be tied to hardware. If you have two memory cards, you might want to try swapping them. If not, maybe let memtest86 run overnight. Yes, this is a total shot in the dark, but this one is really weird and when I see really weird, I start too look at hardware, especially memory and power supply. (And this really does not sound like power supply to me.) -- R. Kevin Oberman, Network Engineer E-mail: kob6558@gmail.com From owner-freebsd-stable@FreeBSD.ORG Mon Oct 22 00:59:03 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AD7A8539; Mon, 22 Oct 2012 00:59:03 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (m209-73.dsl.rawbw.com [198.144.209.73]) by mx1.freebsd.org (Postfix) with ESMTP id F160E8FC0A; Mon, 22 Oct 2012 00:59:02 +0000 (UTC) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.5/8.14.5) with ESMTP id q9M0x2uK003691; Sun, 21 Oct 2012 17:59:02 -0700 (PDT) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.5/8.14.5/Submit) id q9M0x2G7003690; Sun, 21 Oct 2012 17:59:02 -0700 (PDT) (envelope-from david) Date: Sun, 21 Oct 2012 17:59:02 -0700 From: David Wolfskill To: Kevin Oberman Subject: Re: stable/9 @r241776 panic: REDZONE: Buffer underflow detected... Message-ID: <20121022005902.GF1609@albert.catwhisker.org> References: <20121021121356.GJ35915@deviant.kiev.zoral.com.ua> <20121021163322.GB1730@albert.catwhisker.org> <20121021164634.GC1730@albert.catwhisker.org> <20121021174054.GM35915@deviant.kiev.zoral.com.ua> <50843EB6.8030407@FreeBSD.org> <20121021202346.GB1609@albert.catwhisker.org> <5084713A.1050200@FreeBSD.org> <508477A8.2040609@FreeBSD.org> <20121021224648.GE1609@albert.catwhisker.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="HKEL+t8MFpg/ASTE" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Alexander Motin , stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 22 Oct 2012 00:59:04 -0000 --HKEL+t8MFpg/ASTE Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Oct 21, 2012 at 05:28:49PM -0700, Kevin Oberman wrote: > ... > This is starting to smell a bit like it may be tied to hardware. If > you have two memory cards, you might want to try swapping them. If > not, maybe let memtest86 run overnight. There are 2 SODIMMS, yes. So I reverted mjg@'s sys/kern/subr_bus.c patch, rebuilt the kernel, and rebooted ... without issue: I was unable to reproduce the problem. Despite my inability to reproduce it, I went ahead & powered down, swapped the SODIMMs, and rebooted. Still no recurrence. > Yes, this is a total shot in the dark, but this one is really weird > and when I see really weird, I start too look at hardware, especially > memory and power supply. (And this really does not sound like power > supply to me.) > ... The machine is a Dell Precision M4400, and I have extended to hardware warranty. So if I can actually demonstrate a real hardware issue -- in a way that Dell will accept -- I should be able to get it fixed. (I've had a fair bit of practice at that, as the warranty includes accidental damage -- and the time I got flipped off my bicycle while the machine was in a (padded) rucksack qualified.) That said, overnight is when the machine updates its local private mirrors of the FreeBSD SVN repositories, so I can start my daily rebuilds of stable/9 & head fairly early in the morning. (I prefer to get those -- as well as the port-updating -- completed before I get in to work, as I use the laptop to access all of the other machines I use. And I exercise the just-built stable/9 for the rest of the day....) Peace, david --=20 David H. Wolfskill david@catwhisker.org Taliban: Evil men with guns afraid of truth from a 14-year old girl. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --HKEL+t8MFpg/ASTE Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlCEmlUACgkQmprOCmdXAD3M/ACeI/6T2k/UFDjraQDObwG5MmtB cm4AoIFG/oHqlzUafAyrAUKzuEj4NUa1 =5KRG -----END PGP SIGNATURE----- --HKEL+t8MFpg/ASTE-- From owner-freebsd-stable@FreeBSD.ORG Mon Oct 22 13:55:43 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7D17285A for ; Mon, 22 Oct 2012 13:55:43 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id D167A8FC1D for ; Mon, 22 Oct 2012 13:55:42 +0000 (UTC) Received: (qmail 72954 invoked from network); 22 Oct 2012 15:33:53 -0000 Received: from unknown (HELO [62.48.0.94]) ([62.48.0.94]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 22 Oct 2012 15:33:53 -0000 Message-ID: <508550AA.5080106@freebsd.org> Date: Mon, 22 Oct 2012 15:56:58 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Vladislav Prodan Subject: Re: [ZFS] Server periodically become unavailable References: <86879.1350738692.82582785788739584@ffe8.ukr.net> In-Reply-To: <86879.1350738692.82582785788739584@ffe8.ukr.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 22 Oct 2012 13:55:43 -0000 On 20.10.2012 15:11, Vladislav Prodan wrote: > >> FreeBSD 9.1-PRERELEASE #0: Wed Jul 25 01:40:56 EEST 2012 > > I have the server: 8 cores AMD, 16GB RAM, 4x3TB HDD in RAID10 for ZFS. > Sometime wheels fall off the server and the network. > Can this clean-up memory for ZFS cache? > I enclose a picture with the monitoring system at the time lags. > > http://imageshack.us/a/img341/9643/memoryusage.png > http://imageshack.us/a/img22/6935/nginxclientstat.png > http://imageshack.us/a/img19/8817/realmemory.png > > #cat /etc/sysctl.conf > kern.ipc.somaxconn=65535 Remove this. It doesn't do what you think it does. > kern.ipc.maxsockets=204800 > net.inet.ip.portrange.first=1024 > net.inet.ip.portrange.last=65535 > kern.ipc.shmmax=67108864 > kern.ipc.shmall=67108864 > net.inet.tcp.rfc3465=0 Any particular reason why you turn this off? > net.graph.maxdgram=8388608 > net.graph.recvspace=8388608 > net.route.netisr_maxqlen=4096 > kern.ipc.nmbclusters=400000 > kern.ipc.maxsockbuf=83886080 83MB for a socket buffer is too much unless you're doing some HPC stuff. The default should be fine. > net.inet.tcp.recvbuf_inc=524288 Again, this should be left at default unless you have a very specific reason to increment it. > net.inet.tcp.recvbuf_max=16777216 ditto. > net.inet.tcp.sendbuf_inc=524288 ditto. > net.inet.tcp.sendbuf_max=16777216 ditto. > net.inet.tcp.sendspace=65536 This is the default setting. > net.inet.tcp.keepidle=300000 > net.inet.tcp.keepintvl=60000 > net.inet.ip.fw.dyn_max=65535 > net.inet.ip.fw.dyn_buckets=65536 > net.inet.ip.fw.dyn_ack_lifetime=120 > net.inet.ip.fw.dyn_syn_lifetime=10 > net.inet.tcp.nolocaltimewait=1 > security.bsd.hardlink_check_uid=1 > security.bsd.hardlink_check_gid=1 > security.bsd.see_other_uids=0 > security.bsd.see_other_gids=0 -- Andre From owner-freebsd-stable@FreeBSD.ORG Mon Oct 22 15:38:24 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C8696FFD; Mon, 22 Oct 2012 15:38:24 +0000 (UTC) (envelope-from takeda@takeda.tk) Received: from chinatsu.takeda.tk (mail.takeda.tk [74.0.89.210]) by mx1.freebsd.org (Postfix) with ESMTP id 906388FC14; Mon, 22 Oct 2012 15:38:24 +0000 (UTC) Received: from takeda-ws.lan (takeda-ws.lan [10.0.0.3]) (authenticated bits=0) by chinatsu.takeda.tk (8.14.5/8.14.5) with ESMTP id q9MFcHo4016455 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 22 Oct 2012 08:38:18 -0700 (PDT) (envelope-from takeda@takeda.tk) Date: Mon, 22 Oct 2012 08:38:11 -0700 From: Derek Kulinski X-Priority: 3 (Normal) Message-ID: <35578786.20121022083811@takeda.tk> To: Jeremy Chadwick Subject: Re: Problem reading vitals from Gigabyte H77-DH3H In-Reply-To: <20121022130348.GA28302@icarus.home.lan> References: <20121022130348.GA28302@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Cc: freebsd-stable@FreeBSD.org, avg@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 22 Oct 2012 15:38:24 -0000 Hello Jeremy, Monday, October 22, 2012, 6:03:49 AM, you wrote: > I'm not subscribed to the FreeBSD lists any longer, but I did come > across this thread via the web: > http://lists.freebsd.org/pipermail/freebsd-stable/2012-October/070169.html > Either (or both) of you are free to bounce a copy of my Email here to > the list if you feel it'd benefit others. > I have a lot of familiarity with hardware monitoring chips and > interfacing with them (as the author of ports/sysutils/bsdhwmon). > The H/W monitoring chip on that Gigabyte motherboard is **not** the same > or has resistors/pullups that differ from what the OpenBSD sensors > framework code expects. That is quite evident from the below. There > are also very likely labels that are wrong. I'll get to explaining how > to fix that properly further down. > Let me explain in detail one section at a time: >> hw.sensors.it0.volt0: 1,42 VDC (VCORE_A) >> hw.sensors.it0.volt1: 2,72 VDC (VCORE_B) > The term "Vcore" refers to the CPU core voltage. This is a > per-physical-CPU basis. This software is assuming there's 2 physical > CPUs (not cores, I'm talking about physical processors). > VCORE_A may be correct (meaning 1.42V), however it depends on the CPU > model. Derek did not disclose this so I cannot tell you if 1.42V is > considered "correct" or not. Some models run at 1.2V, others 1.5V, > others vary. It is i5-3470 3.2GHz quad core (The entire component list I used to build is here: http://pcpartpicker.com/p/koz3). The CPU is not overclocked, I set "auto" for all this kind of settings in the BIOS. > VCORE_B is probably not VCORE_B at all. However, worse: 2.72V does not > look to be a correct/valid voltage no matter what (even if for an MCH or > a southbridge). So probably a calculation error or its reading the > wrong bits from the chip. >> hw.sensors.it0.volt2: 2,70 VDC (+3.3V) > This is also wrong -- either the voltage or the label. There is no way > your system would be stable if a +3.3V line was at +2.7V. So another > calculation error or reading wrong bits from the chip. >> hw.sensors.it0.volt3: 4,60 VDC (+5V) > This is probably also wrong, but it's hard to say. +5V is relied on > heavily throughout the entire system, so a 0.4V drop is pretty damn > major. So probably another calculation error or reading wrong bits from > the chip. >> hw.sensors.it0.volt4: 0,06 VDC (+12V) > This is flat out completely wrong on numerous levels. >> hw.sensors.it0.volt5: -5,08 VDC (Unused) > No idea. This could be -5V monitoring, but it depends. Only Gigabyte > would know. >> hw.sensors.it0.volt6: -6,53 VDC (-12V) > Also totally wrong (voltage and label). So another calculation error or > reading wrong bits from the chip. >> hw.sensors.it0.volt7: 3,74 VDC (+5VSB) > Also totally wrong (voltage and/or label). "+5Vsb" stands for "+5V > standby"; it's the +5V line that comes off the PSU and is *always on*, > even when the motherboard is off. It's what allows systems to power > back up from sleep state. So another calculation error or reading wrong > bits from the chip. >> hw.sensors.it0.volt8: 2,14 VDC (VBAT) > Also totally wrong (voltage and/or label). "VBAT" refers to the voltage > of the CMOS battery, which should be +3.3V. So another calculation > error or reading wrong bits from the chip. > Here is what proper labels and a proper system should show, as an > example: > # bsdhwmon > CPU1 Temperature 31 C > System Temperature 35 C > FAN1 0 RPM > FAN2 0 RPM > FAN3 0 RPM > FAN4 2042 RPM > FAN5 0 RPM > FAN6 1875 RPM > VcoreA 1.106 V > MCH Core 1.522 V > -12V -12.288 V > V_DIMM 1.712 V > +3.3V 3.392 V > +12V 12.096 V > 5Vsb 5.070 V > 5VDD 5.118 V > P_VTT 1.142 V > Vbat 3.328 V > The bottom line here is this: the problem with the sensors framework is > that it has no concept of per-motherboard engineering (to my knowledge). > Again, that is why I designed bsdhwmon the way I did -- I key off of > SMBIOS string data because it's the only way to do things as reliable as > possible. Each motherboard model requires unique support. Without > that, voltage calculations are either wrong, or labels are completely > wrong, or both. > If I could get within the bowels of Gigabyte and actually talk to a > **real engineer** and not tech support, I could find out if their > GA-H77-DS3H motherboard has SMBus tie-ins for their H/W monitoring chip. > If it does, I **absolutely** could add PROPER support for it to > bsdhwmon. > However, regardless of that, it also requires the owner of the > motherboard to be able to run the monitoring software provided by the > vendor for the board (usually Windows software) as a "baseline" > comparison -- or -- take a screenshot of the hardware monitoring details > in the BIOS (or UEFI system) for comparison. Sometimes a VERY HIGH > RESOLUTION photo of the motherboard is helpful -- though sometimes this > isn't useful because motherboard vendors actually use "emulation modes" > of their Super I/O chips (e.g. Chip Z is installed on the board, but > it's configured to emulate Chip X which the Chip company made 2 years > ago). I've found this on many Supermicro boards actually -- what's > silkscreened on the chips says one thing but how the chip *behaves* is > another. Not exactly a screenshot but I wrote down values given by BIOS: CPU Vcore 1.044V DRAM Voltage 1.524V +3.3V 3.363V +12V 12.168V CPU Temp 33C System Temp 30C Please let me know if this is enough. As for the picture of the motherboard, this one (http://www.nix.ru/autocatalog/motherboards_gigabyte/135869_2245_draft.jpg) looks way better than any of my picture. It is revision 1.0. Gigabyte seems to have also rev 1.1, but 1.0 is the one I use. > But sometimes even WITH proper documentation from the vendor there are > unexplained issues. Two examples taken from bsdhwmon's doc/BUGS: > Winbond W83792D: +5V Vcc is incorrect > ======================================= > Currently, boards which use the Winbond W83792D H/W monitoring IC will > have their +5V voltage shown incorrectly. > I've mailed Supermicro to try and find out why the calculation formula > is wrong (since what I'm following comes from Winbond), but as of this > writing have received no response. > I have also looked at the Linux lm-sensors project, but the code is > quite "spaghetti" -- it's hard to discern what the calculation values > are, and if they're the same for all W83792D systems. > Winbond W83792D: FAN3 RPMs may be inaccurate/high > =================================================== > I've received a single (isolated) report involving a Supermicro P8SCi > board reporting absurdly high values for FAN3. Example: > FAN1 0 RPM > FAN2 2909 RPM > FAN3 84375 RPM > FAN4 0 RPM > FAN5 0 RPM > Further executions of bsdhwmon did not exhibit this problem. However, > I take the report seriously, as it could indicate a strange bug in > bsdhwmon, or possibly a bug in the Winbond W83792D chipset. At this > time I have not been able to determine the root cause, however the > user had his fan RPM configuration in the system BIOS set to > "3-pin Server" rather than "Disabled" (which runs the fans at full > speed). This could be a bug in the Winbond chipset, but I simply > don't know. > ------------ > I refuse to interface with Super I/O or H/W monitoring chips that use > the classic ISA interface (/dev/io) because it's an extremely risky > interface. You can crash and lock up a system very very easily with > this model. The wrong I/O port or wrong bit set in the wrong sub-reg > and pow, the system is in a weird state. It's a lot more difficult with > SMBus given the unique assignment of a slave device address per-device. > Don't get me started on what Linux lm-sensors looks like either. Good > god what a mess. Does it work? Yeah, it works. But it's just such a > garbled mess of code and "configs" and some abstract strangeness. It > really doesn't read well, and is not commented good to boot. > I wish I could help solve this in some way for you guys (without using > sensors). I've spent way too many years doing H/W monitoring "stuff", > and concluded long ago that on FreeBSD H/W monitoring is absolutely > doable but we need support from vendors on a per-motherboard basis. > Supermicro happens to be one of the few vendors who is quite good about > this, barring the Winbond W83792D +5V Vcc problem. > The biggest problem: this kind of support/effort is quite literally a > full-time job. Finding/getting in contact with engineers deep within > the bowels of companies is the hardest part. > P.S. -- Question for Andriy: I thought it was established long ago that > none of this monitoring should be done in the kernel? Were you around > when someone took the time to port the OpenBSD sensors framework to > FreeBSD, and it resulted in a *massive* discussion and backlash from > FreeBSD kernel committers stating "this should not go in the kernel?" > Now I see this, and mention of an it(4) driver...? What exactly is > going on? To put it in California-style: "dude. This REALLY pisses me > off. WTF is going on over there?" -- Best regards, Derek mailto:takeda@takeda.tk Always remember you're unique, just like everyone else. From owner-freebsd-stable@FreeBSD.ORG Mon Oct 22 15:42:16 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 79A951C5; Mon, 22 Oct 2012 15:42:16 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 4ACA58FC0A; Mon, 22 Oct 2012 15:42:16 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id B0CB4B91A; Mon, 22 Oct 2012 11:42:15 -0400 (EDT) From: John Baldwin To: freebsd-stable@freebsd.org Subject: Re: ${CTFCONVERT_CMD} expands to empty string Date: Mon, 22 Oct 2012 11:42:06 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p20; KDE/4.5.5; amd64; ; ) References: <5081F92F.8040004@freebsd.org> <508317A4.2060800@freebsd.org> <5084927C.1070101@freebsd.org> In-Reply-To: <5084927C.1070101@freebsd.org> MIME-Version: 1.0 Message-Id: <201210221142.06889.jhb@freebsd.org> Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 22 Oct 2012 11:42:15 -0400 (EDT) Cc: stable@freebsd.org, Andrey Chernov X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 22 Oct 2012 15:42:16 -0000 On Sunday, October 21, 2012 8:25:32 pm Andrey Chernov wrote: > Those lines cause this error: > .if ${MK_CTF} != "no" > CTFCONVERT_CMD= ${CTFCONVERT} ${CTFFLAGS} ${.TARGET} > .elif ${MAKE_VERSION} >= 5201111300 > CTFCONVERT_CMD= > .else > CTFCONVERT_CMD= @: > .endif > > My make version is 9201206140 > So, either the check for >= 5201111300 is incorrect or change for empty > make variables expansion is not merged into stable-9 I can't reproduce this doing a buildworld of a stable/9 checkout on a 9.0- stable machine btw. What exact contents of /etc/src.conf and commands are you using to reproduce this? I also can't find the string "empty string" in the output of my stable/9 'make universe' build before I committed this. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Mon Oct 22 15:42:16 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 79A951C5; Mon, 22 Oct 2012 15:42:16 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 4ACA58FC0A; Mon, 22 Oct 2012 15:42:16 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id B0CB4B91A; Mon, 22 Oct 2012 11:42:15 -0400 (EDT) From: John Baldwin To: freebsd-stable@freebsd.org Subject: Re: ${CTFCONVERT_CMD} expands to empty string Date: Mon, 22 Oct 2012 11:42:06 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p20; KDE/4.5.5; amd64; ; ) References: <5081F92F.8040004@freebsd.org> <508317A4.2060800@freebsd.org> <5084927C.1070101@freebsd.org> In-Reply-To: <5084927C.1070101@freebsd.org> MIME-Version: 1.0 Message-Id: <201210221142.06889.jhb@freebsd.org> Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 22 Oct 2012 11:42:15 -0400 (EDT) Cc: stable@freebsd.org, Andrey Chernov X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 22 Oct 2012 15:42:16 -0000 On Sunday, October 21, 2012 8:25:32 pm Andrey Chernov wrote: > Those lines cause this error: > .if ${MK_CTF} != "no" > CTFCONVERT_CMD= ${CTFCONVERT} ${CTFFLAGS} ${.TARGET} > .elif ${MAKE_VERSION} >= 5201111300 > CTFCONVERT_CMD= > .else > CTFCONVERT_CMD= @: > .endif > > My make version is 9201206140 > So, either the check for >= 5201111300 is incorrect or change for empty > make variables expansion is not merged into stable-9 I can't reproduce this doing a buildworld of a stable/9 checkout on a 9.0- stable machine btw. What exact contents of /etc/src.conf and commands are you using to reproduce this? I also can't find the string "empty string" in the output of my stable/9 'make universe' build before I committed this. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Mon Oct 22 16:08:18 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 03862D31 for ; Mon, 22 Oct 2012 16:08:18 +0000 (UTC) (envelope-from mailer-daemon@vniz.net) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 791438FC0C for ; Mon, 22 Oct 2012 16:08:16 +0000 (UTC) Received: by mail-bk0-f54.google.com with SMTP id jf20so1103252bkc.13 for ; Mon, 22 Oct 2012 09:08:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:disposition-notification-to:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to:openpgp :content-type:content-transfer-encoding:x-gm-message-state; bh=VGfYlTy2kXWn1e1MvOHHAXaw037XHRh9JW0mQC6oM4o=; b=J0Qg9wIzzR4KfntTYzcgZ1Kb8sKVcGQw3xMKMdW5v5n704FSrG5P0RdvySYfTonSKG aoMamtoZHOpr7fubb+TO5eja+xToMckwaFuBiapwdjVwux4KvB2gF5FUbE8D8YBU16h2 xIBTk6Ude/4l4DlkJgZVeX+kyfSgZys3/Iz03gsp38iVq9G+FZxDOsmQA6ZdC0bGGOC0 qxrudfrI4aRDyw+eK1uwJm4qgLT4ju6bWwhPSHbPdK7dkuqrGnfY24akdDpe80LkzUlx KR7/2IskKJRVeQjPQSqJXOPQlwf+8m2cy2mHsI/zp4EvKLxfItRE0xC9UeEd0vQV8VcC uv6w== Received: by 10.204.130.73 with SMTP id r9mr756029bks.131.1350922096147; Mon, 22 Oct 2012 09:08:16 -0700 (PDT) Received: from [192.168.1.2] ([89.169.140.97]) by mx.google.com with ESMTPS id v14sm4097541bkv.10.2012.10.22.09.08.15 (version=SSLv3 cipher=OTHER); Mon, 22 Oct 2012 09:08:15 -0700 (PDT) Message-ID: <50856F6F.40204@freebsd.org> Date: Mon, 22 Oct 2012 20:08:15 +0400 From: Andrey Chernov User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: John Baldwin Subject: Re: ${CTFCONVERT_CMD} expands to empty string References: <5081F92F.8040004@freebsd.org> <508317A4.2060800@freebsd.org> <5084927C.1070101@freebsd.org> <201210221142.06889.jhb@freebsd.org> In-Reply-To: <201210221142.06889.jhb@freebsd.org> OpenPGP: id=964474DD Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQmKzW7J/hIAqdTyk85s77LkBlBURoTSdQj+UwYSOXIGsfiHRzAI/m/Zo57/617G0wyxomG4 Cc: stable@freebsd.org, freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 22 Oct 2012 16:08:18 -0000 On 22.10.2012 19:42, John Baldwin wrote: > On Sunday, October 21, 2012 8:25:32 pm Andrey Chernov wrote: >> Those lines cause this error: >> .if ${MK_CTF} != "no" >> CTFCONVERT_CMD= ${CTFCONVERT} ${CTFFLAGS} ${.TARGET} >> .elif ${MAKE_VERSION} >= 5201111300 >> CTFCONVERT_CMD= >> .else >> CTFCONVERT_CMD= @: >> .endif >> >> My make version is 9201206140 >> So, either the check for >= 5201111300 is incorrect or change for empty >> make variables expansion is not merged into stable-9 > > I can't reproduce this doing a buildworld of a stable/9 checkout on a 9.0- > stable machine btw. What exact contents of /etc/src.conf and commands are you > using to reproduce this? > > I also can't find the string "empty string" in the output of my stable/9 > 'make universe' build before I committed this. > /etc/src.conf: WITHOUT_AMD=yes WITHOUT_APM=yes WITHOUT_ATM=yes WITHOUT_AUDIT=yes WITH_BSD_GREP=yes WITHOUT_BLUETOOTH=yes WITHOUT_BSNMP=yes WITHOUT_CDDL=yes WITHOUT_CLANG=yes WITHOUT_CTM=yes WITHOUT_FORTRAN=yes WITHOUT_GPIB=yes WITHOUT_GPIO=yes WITHOUT_GSSAPI=yes WITHOUT_I4B=yes WITH_IDEA=yes WITHOUT_IPFILTER=yes WITHOUT_IPX=yes WITHOUT_NCP=yes WITHOUT_NIS=yes WITHOUT_KERBEROS=yes WITHOUT_MAILWRAPPER=yes WITHOUT_PF=yes WITHOUT_PMC=yes WITHOUT_PROFILE=yes WITHOUT_RCMDS=yes WITHOUT_SLIP=yes WITHOUT_WIRELESS=yes I got that useless line _each_ .c file compiles. Example commands: cd /usr/src/usr.bin/make make clean make I got: cc -O2 -pipe -march=pentium4 -I/usr/src/usr.bin/make -DMAKE_VERSION=\"9201206140\" -DDEFSHELLNAME=\"sh\" -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /usr/src/usr.bin/make/arch.c ${CTFCONVERT_CMD} expands to empty string ...etc... on each file. From owner-freebsd-stable@FreeBSD.ORG Mon Oct 22 16:08:18 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0B1E8D32 for ; Mon, 22 Oct 2012 16:08:18 +0000 (UTC) (envelope-from mailer-daemon@vniz.net) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 791708FC12 for ; Mon, 22 Oct 2012 16:08:17 +0000 (UTC) Received: by mail-bk0-f54.google.com with SMTP id jf20so1103250bkc.13 for ; Mon, 22 Oct 2012 09:08:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:disposition-notification-to:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to:openpgp :content-type:content-transfer-encoding:x-gm-message-state; bh=VGfYlTy2kXWn1e1MvOHHAXaw037XHRh9JW0mQC6oM4o=; b=hQkE7mao4G8uyJaqQxtcdvI5qNvanSgVBwSnzm91P7xMByljBBZ0wUBm+9Ufql3fut 7GcuH5GerX/6wdgwILEtXRax6937Q2XkTvcIHe6zU4AS+8CSnb8IUoSksXfTQIBCajnq MP4R3GpHKgjdbEY6imDxxYfQALGidK9NGYBJWtOuzHrMi9y0wmvvKbtkGpPgMRlNj12Y jN3F/urPNVa2+ZmmI80Ij4vnFbIPNGkWrVpOmcs9ca6NYvBiEhE91dYT1nkVA3czXr8w wX5afjOutQ685047tdfRJIbIPBFNTB/4c39EdPJmPGPzhrdjrqoKNn1GTlaNBQUJwzRe 2iiw== Received: by 10.204.130.73 with SMTP id r9mr756029bks.131.1350922096147; Mon, 22 Oct 2012 09:08:16 -0700 (PDT) Received: from [192.168.1.2] ([89.169.140.97]) by mx.google.com with ESMTPS id v14sm4097541bkv.10.2012.10.22.09.08.15 (version=SSLv3 cipher=OTHER); Mon, 22 Oct 2012 09:08:15 -0700 (PDT) Message-ID: <50856F6F.40204@freebsd.org> Date: Mon, 22 Oct 2012 20:08:15 +0400 From: Andrey Chernov User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: John Baldwin Subject: Re: ${CTFCONVERT_CMD} expands to empty string References: <5081F92F.8040004@freebsd.org> <508317A4.2060800@freebsd.org> <5084927C.1070101@freebsd.org> <201210221142.06889.jhb@freebsd.org> In-Reply-To: <201210221142.06889.jhb@freebsd.org> OpenPGP: id=964474DD Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQkzV0Q4xYursW6o62K1/Y3S2R/4r/Hn+i4vC8VoNdrvGKKfUeeqkhAqZ+mvDwtKLEmJsnTF Cc: stable@freebsd.org, freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 22 Oct 2012 16:08:18 -0000 On 22.10.2012 19:42, John Baldwin wrote: > On Sunday, October 21, 2012 8:25:32 pm Andrey Chernov wrote: >> Those lines cause this error: >> .if ${MK_CTF} != "no" >> CTFCONVERT_CMD= ${CTFCONVERT} ${CTFFLAGS} ${.TARGET} >> .elif ${MAKE_VERSION} >= 5201111300 >> CTFCONVERT_CMD= >> .else >> CTFCONVERT_CMD= @: >> .endif >> >> My make version is 9201206140 >> So, either the check for >= 5201111300 is incorrect or change for empty >> make variables expansion is not merged into stable-9 > > I can't reproduce this doing a buildworld of a stable/9 checkout on a 9.0- > stable machine btw. What exact contents of /etc/src.conf and commands are you > using to reproduce this? > > I also can't find the string "empty string" in the output of my stable/9 > 'make universe' build before I committed this. > /etc/src.conf: WITHOUT_AMD=yes WITHOUT_APM=yes WITHOUT_ATM=yes WITHOUT_AUDIT=yes WITH_BSD_GREP=yes WITHOUT_BLUETOOTH=yes WITHOUT_BSNMP=yes WITHOUT_CDDL=yes WITHOUT_CLANG=yes WITHOUT_CTM=yes WITHOUT_FORTRAN=yes WITHOUT_GPIB=yes WITHOUT_GPIO=yes WITHOUT_GSSAPI=yes WITHOUT_I4B=yes WITH_IDEA=yes WITHOUT_IPFILTER=yes WITHOUT_IPX=yes WITHOUT_NCP=yes WITHOUT_NIS=yes WITHOUT_KERBEROS=yes WITHOUT_MAILWRAPPER=yes WITHOUT_PF=yes WITHOUT_PMC=yes WITHOUT_PROFILE=yes WITHOUT_RCMDS=yes WITHOUT_SLIP=yes WITHOUT_WIRELESS=yes I got that useless line _each_ .c file compiles. Example commands: cd /usr/src/usr.bin/make make clean make I got: cc -O2 -pipe -march=pentium4 -I/usr/src/usr.bin/make -DMAKE_VERSION=\"9201206140\" -DDEFSHELLNAME=\"sh\" -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /usr/src/usr.bin/make/arch.c ${CTFCONVERT_CMD} expands to empty string ...etc... on each file. From owner-freebsd-stable@FreeBSD.ORG Mon Oct 22 16:15:31 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9D9DA373 for ; Mon, 22 Oct 2012 16:15:31 +0000 (UTC) (envelope-from jdc@koitsu.strangled.net) Received: from qmta09.emeryville.ca.mail.comcast.net (qmta09.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:96]) by mx1.freebsd.org (Postfix) with ESMTP id 76A418FC0C for ; Mon, 22 Oct 2012 16:15:31 +0000 (UTC) Received: from omta12.emeryville.ca.mail.comcast.net ([76.96.30.44]) by qmta09.emeryville.ca.mail.comcast.net with comcast id EFRu1k0090x6nqcA9GFXKU; Mon, 22 Oct 2012 16:15:31 +0000 Received: from koitsu.strangled.net ([67.180.84.87]) by omta12.emeryville.ca.mail.comcast.net with comcast id EGFW1k0031t3BNj8YGFWW4; Mon, 22 Oct 2012 16:15:30 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id F25E873A1A; Mon, 22 Oct 2012 09:15:29 -0700 (PDT) Date: Mon, 22 Oct 2012 09:15:29 -0700 From: Jeremy Chadwick To: Derek Kulinski Subject: Re: Problem reading vitals from Gigabyte H77-DH3H Message-ID: <20121022161529.GA31919@icarus.home.lan> References: <20121022130348.GA28302@icarus.home.lan> <35578786.20121022083811@takeda.tk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <35578786.20121022083811@takeda.tk> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-stable@FreeBSD.org, avg@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 22 Oct 2012 16:15:31 -0000 On Mon, Oct 22, 2012 at 08:38:11AM -0700, Derek Kulinski wrote: > Hello Jeremy, > > Monday, October 22, 2012, 6:03:49 AM, you wrote: > {snipping} > > Let me explain in detail one section at a time: > > >> hw.sensors.it0.volt0: 1,42 VDC (VCORE_A) > >> hw.sensors.it0.volt1: 2,72 VDC (VCORE_B) > > > The term "Vcore" refers to the CPU core voltage. This is a > > per-physical-CPU basis. This software is assuming there's 2 physical > > CPUs (not cores, I'm talking about physical processors). > > > VCORE_A may be correct (meaning 1.42V), however it depends on the CPU > > model. Derek did not disclose this so I cannot tell you if 1.42V is > > considered "correct" or not. Some models run at 1.2V, others 1.5V, > > others vary. > > It is i5-3470 3.2GHz quad core (The entire component list I used to > build is here: http://pcpartpicker.com/p/koz3). > The CPU is not overclocked, I set "auto" for all this kind of settings > in the BIOS. Then it's simple: the voltage shown is wrong. The Core i5-3470 runs at a stock Vcore of 1.1V, and with some CPU features will downthrottle to around 1.0V. Thus, 1.42V is too high (thus wrong), and is just further indication that the calculation is wrong or the data being obtained is wrong. If your CPU was really running at 1.42V, it'd have crashed by the time you got into the BIOS. (The highest I've seen people overclock Vcore on this chip is 1.25V, so 1.42V is obviously a calculation error) {snipping} > > If I could get within the bowels of Gigabyte and actually talk to a > > **real engineer** and not tech support, I could find out if their > > GA-H77-DS3H motherboard has SMBus tie-ins for their H/W monitoring chip. > > If it does, I **absolutely** could add PROPER support for it to > > bsdhwmon. > > > However, regardless of that, it also requires the owner of the > > motherboard to be able to run the monitoring software provided by the > > vendor for the board (usually Windows software) as a "baseline" > > comparison -- or -- take a screenshot of the hardware monitoring details > > in the BIOS (or UEFI system) for comparison. Sometimes a VERY HIGH > > RESOLUTION photo of the motherboard is helpful -- though sometimes this > > isn't useful because motherboard vendors actually use "emulation modes" > > of their Super I/O chips (e.g. Chip Z is installed on the board, but > > it's configured to emulate Chip X which the Chip company made 2 years > > ago). I've found this on many Supermicro boards actually -- what's > > silkscreened on the chips says one thing but how the chip *behaves* is > > another. > > Not exactly a screenshot but I wrote down values given by BIOS: > CPU Vcore 1.044V > DRAM Voltage 1.524V > +3.3V 3.363V > +12V 12.168V > CPU Temp 33C > System Temp 30C And here we have proof that the sensor data you're seeing in FreeBSD is wrong, so I rest my case. > Please let me know if this is enough. I'll repeat what I wrote: If I could get within the bowels of Gigabyte and actually talk to a **real engineer** and not tech support, I could find out if their GA-H77-DS3H motherboard has SMBus tie-ins for their H/W monitoring chip. If it does, I **absolutely** could add PROPER support for it to bsdhwmon. > As for the picture of the motherboard, this one > (http://www.nix.ru/autocatalog/motherboards_gigabyte/135869_2245_draft.jpg) > looks way better than any of my picture. The H/W monitoring and Super I/O chip on this board is from iTE, but I cannot read the silkscreening. The chip model matters. But furthermore, as I said above, the silkscreening is not always an indicator of how the chip operates. The official site only says "iTE I/O Controller", which is also too vague. This is why getting full documentation from the board vendor is needed. Getting this is like pulling teeth. Given that Gigabyte is a workstation and consumer-focused company (not server-focused), the likelihood of them understanding this question is very low: "Hello. I am a developer of H/W monitoring software for FreeBSD, and I'm looking to get technical documentation about the H/W monitoring and Super I/O chip used on the Gigabyte GA-H77-DS3H (revision 1.0) motherboard. I need to know what chip is used that provides voltages, fan RPMs, and temperatures, and I need to know if that chip has SMBus tie-ins. If it does, I need to know what the SMBus slave address is, and what the register offsets are + full descriptions of the registers. If you have calculation formulas (for in-line resistor offsets and so on) that would be quite helpful. Thank you." Supermicro Technical Support, comparatively, understands the above question and will give full documentation for each board you ask for. I've asked them for 10-12 boards "in bulk" once, and they provided all the documentation for every board. It takes them about 2 weeks to get it to you -- because they have to get it from an actual engineer. But getting this from consumer-focused manufacturers (ex. Asus, Gigabyte, MSI, and even Intel) is difficult. Don't ask me why. bsdhwmon has no support for iTE chips at this time. It only works with Supermicro motherboards which (so far) have been (mostly) Winbond chips (now known as Nuvoton). Some Supermicro boards are also very unique and strange, such as some of their higher-end blade-based boards, where things are done very uniquely (in some cases, *2* H/W monitoring chips are used on the same board, with multiple SMBus slave addresses). Anyway, more abstract: this is why you will find software such as the free "Motherboard Monitor" application for Windows reporting wrong voltages, temperatures, and fan RPMs -- because the software simply probes busses looking for chips, and if it finds one, ***assumes*** they're all the same. That assumption is what causes these types of problems, and is why official documentation and support **per board** is needed. That is why I designed bsdhwmon the way I did -- I test each and every board *individually*. It's the only way, sadly. > It is revision 1.0. Gigabyte seems to have also rev 1.1, but 1.0 is > the one I use. Gigabyte board revisions are interesting -- some change very little (optimising some circuitry, changing location of some components), while others change dramatically (changing NIC/PHY vendors, changing USB 3.0 chip vendors, changing Firewire or Super I/O chip vendors). It varies greatly. I use Gigabyte boards for my workstations, but do not use them for FreeBSD-related things. I use Supermicro for that. -- | Jeremy Chadwick jdc@koitsu.org | | UNIX Systems Administrator http://jdc.koitsu.org/ | | Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Mon Oct 22 16:45:42 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8F20DD5 for ; Mon, 22 Oct 2012 16:45:42 +0000 (UTC) (envelope-from mailer-daemon@vniz.net) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 0D1268FC16 for ; Mon, 22 Oct 2012 16:45:41 +0000 (UTC) Received: by mail-bk0-f54.google.com with SMTP id jf20so1123683bkc.13 for ; Mon, 22 Oct 2012 09:45:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:disposition-notification-to:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to:openpgp :content-type:content-transfer-encoding:x-gm-message-state; bh=/mnUrDi0K/rx1TAzG5B28zS2Blj/Rxf8rSnCO6fZpf0=; b=XuVZ4nwsvwSs1QaKf3g43vCsTLKKQONvzehT4Epu+d+U5Hi2xir4evkZKRQYkxhedt EVxGBpg9C8aglq/XrQz/Lm2RjuIcbfkS1lJ2ZV+vcBGCtTx9ZAqhHa68mdytTvblEP5P 91TxcuNL01wmaVpMGW7H2SkXjeRxdzYAQxISNxc3LE1WEccEOuIgzpVm7BycqyG9s8rw 9hMeh33qKVTP27+QocSpLHOaw53QZzl/faKWIlmo81NBEbCTqGmDRoLN8V/KWylfG48l hfSa95IrJ49VBT4Hsa71nibhtoT+bYvP5fDTrB+HpMWLhDYz8sDLhQA1rWbikkkjydN9 jKBg== Received: by 10.204.156.74 with SMTP id v10mr2933989bkw.39.1350924340802; Mon, 22 Oct 2012 09:45:40 -0700 (PDT) Received: from [192.168.1.2] ([89.169.140.97]) by mx.google.com with ESMTPS id ia2sm4196791bkc.11.2012.10.22.09.45.36 (version=SSLv3 cipher=OTHER); Mon, 22 Oct 2012 09:45:37 -0700 (PDT) Message-ID: <50857831.1070603@freebsd.org> Date: Mon, 22 Oct 2012 20:45:37 +0400 From: Andrey Chernov User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: John Baldwin Subject: Re: ${CTFCONVERT_CMD} expands to empty string References: <5081F92F.8040004@freebsd.org> <508317A4.2060800@freebsd.org> <5084927C.1070101@freebsd.org> <201210221142.06889.jhb@freebsd.org> <50856F6F.40204@freebsd.org> In-Reply-To: <50856F6F.40204@freebsd.org> OpenPGP: id=964474DD Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQnUhNnjXszxYLvR4HeblpzspxrGotC4ihVON1JxgSMefwvRzv2VwmnsUEIafCfNqvCDgQ6S Cc: stable@freebsd.org, freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 22 Oct 2012 16:45:42 -0000 And simple test case proving that make v9201206140 dislike empty commands. Makefile: ------------------------------------------------ CTFCONVERT_CMD= all: echo ${MAKE_VERSION} ${CTFCONVERT_CMD} echo b ------------------------------------------------ > make echo 9201206140 9201206140 ${CTFCONVERT_CMD} expands to empty string echo b b On 22.10.2012 20:08, Andrey Chernov wrote: > On 22.10.2012 19:42, John Baldwin wrote: >> On Sunday, October 21, 2012 8:25:32 pm Andrey Chernov wrote: >>> Those lines cause this error: >>> .if ${MK_CTF} != "no" >>> CTFCONVERT_CMD= ${CTFCONVERT} ${CTFFLAGS} ${.TARGET} >>> .elif ${MAKE_VERSION} >= 5201111300 >>> CTFCONVERT_CMD= >>> .else >>> CTFCONVERT_CMD= @: >>> .endif >>> >>> My make version is 9201206140 >>> So, either the check for >= 5201111300 is incorrect or change for empty >>> make variables expansion is not merged into stable-9 >> >> I can't reproduce this doing a buildworld of a stable/9 checkout on a 9.0- >> stable machine btw. What exact contents of /etc/src.conf and commands are you >> using to reproduce this? >> >> I also can't find the string "empty string" in the output of my stable/9 >> 'make universe' build before I committed this. >> > > /etc/src.conf: > WITHOUT_AMD=yes > WITHOUT_APM=yes > WITHOUT_ATM=yes > WITHOUT_AUDIT=yes > WITH_BSD_GREP=yes > WITHOUT_BLUETOOTH=yes > WITHOUT_BSNMP=yes > WITHOUT_CDDL=yes > WITHOUT_CLANG=yes > WITHOUT_CTM=yes > WITHOUT_FORTRAN=yes > WITHOUT_GPIB=yes > WITHOUT_GPIO=yes > WITHOUT_GSSAPI=yes > WITHOUT_I4B=yes > WITH_IDEA=yes > WITHOUT_IPFILTER=yes > WITHOUT_IPX=yes > WITHOUT_NCP=yes > WITHOUT_NIS=yes > WITHOUT_KERBEROS=yes > WITHOUT_MAILWRAPPER=yes > WITHOUT_PF=yes > WITHOUT_PMC=yes > WITHOUT_PROFILE=yes > WITHOUT_RCMDS=yes > WITHOUT_SLIP=yes > WITHOUT_WIRELESS=yes > > I got that useless line _each_ .c file compiles. Example commands: > cd /usr/src/usr.bin/make > make clean > make > I got: > cc -O2 -pipe -march=pentium4 -I/usr/src/usr.bin/make > -DMAKE_VERSION=\"9201206140\" -DDEFSHELLNAME=\"sh\" -std=gnu99 > -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W > -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes > -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch > -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline > -Wnested-externs -Wredundant-decls -Wold-style-definition > -Wno-pointer-sign -c /usr/src/usr.bin/make/arch.c > ${CTFCONVERT_CMD} expands to empty string > ...etc... on each file. > From owner-freebsd-stable@FreeBSD.ORG Mon Oct 22 16:45:42 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id ADB2CD7 for ; Mon, 22 Oct 2012 16:45:42 +0000 (UTC) (envelope-from mailer-daemon@vniz.net) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 17BB48FC17 for ; Mon, 22 Oct 2012 16:45:41 +0000 (UTC) Received: by mail-bk0-f54.google.com with SMTP id jf20so1123682bkc.13 for ; Mon, 22 Oct 2012 09:45:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:disposition-notification-to:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to:openpgp :content-type:content-transfer-encoding:x-gm-message-state; bh=/mnUrDi0K/rx1TAzG5B28zS2Blj/Rxf8rSnCO6fZpf0=; b=gWTgLQZZ3Mg7igol/7DOpQgmaUAPVVxskmtdzWn+WtIQFqkM2emc8+HZtVaNBLlIAT msGvubqHQmYbmapDZnu4zRkjPQQ0i4WNu+9s8NT1RtVyVY0dgJCi/ENiB9SRJeEUQ348 60N7+WgOAOeKcc2oKpW5LU5xN9CTn6Tsh2ilPj7vgNvnMXDq+ocbQ2JmZ873cwH1eRLm duwojm3+t5KzPpPiymeUh9hPL0ce0FcdTZsyQkM5D3aK6rSoXtU/QvRYX60xlcYg2WW+ GO7/lMnc335gGLFIobGOHnm9uZ4idtNkZGPwXNF8gweNwH42slGaxr2vnA6Pkg0LwZDd 5swA== Received: by 10.204.156.74 with SMTP id v10mr2933989bkw.39.1350924340802; Mon, 22 Oct 2012 09:45:40 -0700 (PDT) Received: from [192.168.1.2] ([89.169.140.97]) by mx.google.com with ESMTPS id ia2sm4196791bkc.11.2012.10.22.09.45.36 (version=SSLv3 cipher=OTHER); Mon, 22 Oct 2012 09:45:37 -0700 (PDT) Message-ID: <50857831.1070603@freebsd.org> Date: Mon, 22 Oct 2012 20:45:37 +0400 From: Andrey Chernov User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: John Baldwin Subject: Re: ${CTFCONVERT_CMD} expands to empty string References: <5081F92F.8040004@freebsd.org> <508317A4.2060800@freebsd.org> <5084927C.1070101@freebsd.org> <201210221142.06889.jhb@freebsd.org> <50856F6F.40204@freebsd.org> In-Reply-To: <50856F6F.40204@freebsd.org> OpenPGP: id=964474DD Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQlK3kgmIZ0izrfg9apIQae8RmcIMEmIYcOkUx7ztpps8dKha8Gzg3VEi+a4K0syNXRL/bYm Cc: stable@freebsd.org, freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 22 Oct 2012 16:45:42 -0000 And simple test case proving that make v9201206140 dislike empty commands. Makefile: ------------------------------------------------ CTFCONVERT_CMD= all: echo ${MAKE_VERSION} ${CTFCONVERT_CMD} echo b ------------------------------------------------ > make echo 9201206140 9201206140 ${CTFCONVERT_CMD} expands to empty string echo b b On 22.10.2012 20:08, Andrey Chernov wrote: > On 22.10.2012 19:42, John Baldwin wrote: >> On Sunday, October 21, 2012 8:25:32 pm Andrey Chernov wrote: >>> Those lines cause this error: >>> .if ${MK_CTF} != "no" >>> CTFCONVERT_CMD= ${CTFCONVERT} ${CTFFLAGS} ${.TARGET} >>> .elif ${MAKE_VERSION} >= 5201111300 >>> CTFCONVERT_CMD= >>> .else >>> CTFCONVERT_CMD= @: >>> .endif >>> >>> My make version is 9201206140 >>> So, either the check for >= 5201111300 is incorrect or change for empty >>> make variables expansion is not merged into stable-9 >> >> I can't reproduce this doing a buildworld of a stable/9 checkout on a 9.0- >> stable machine btw. What exact contents of /etc/src.conf and commands are you >> using to reproduce this? >> >> I also can't find the string "empty string" in the output of my stable/9 >> 'make universe' build before I committed this. >> > > /etc/src.conf: > WITHOUT_AMD=yes > WITHOUT_APM=yes > WITHOUT_ATM=yes > WITHOUT_AUDIT=yes > WITH_BSD_GREP=yes > WITHOUT_BLUETOOTH=yes > WITHOUT_BSNMP=yes > WITHOUT_CDDL=yes > WITHOUT_CLANG=yes > WITHOUT_CTM=yes > WITHOUT_FORTRAN=yes > WITHOUT_GPIB=yes > WITHOUT_GPIO=yes > WITHOUT_GSSAPI=yes > WITHOUT_I4B=yes > WITH_IDEA=yes > WITHOUT_IPFILTER=yes > WITHOUT_IPX=yes > WITHOUT_NCP=yes > WITHOUT_NIS=yes > WITHOUT_KERBEROS=yes > WITHOUT_MAILWRAPPER=yes > WITHOUT_PF=yes > WITHOUT_PMC=yes > WITHOUT_PROFILE=yes > WITHOUT_RCMDS=yes > WITHOUT_SLIP=yes > WITHOUT_WIRELESS=yes > > I got that useless line _each_ .c file compiles. Example commands: > cd /usr/src/usr.bin/make > make clean > make > I got: > cc -O2 -pipe -march=pentium4 -I/usr/src/usr.bin/make > -DMAKE_VERSION=\"9201206140\" -DDEFSHELLNAME=\"sh\" -std=gnu99 > -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W > -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes > -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch > -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline > -Wnested-externs -Wredundant-decls -Wold-style-definition > -Wno-pointer-sign -c /usr/src/usr.bin/make/arch.c > ${CTFCONVERT_CMD} expands to empty string > ...etc... on each file. > From owner-freebsd-stable@FreeBSD.ORG Mon Oct 22 17:01:56 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 31013564 for ; Mon, 22 Oct 2012 17:01:56 +0000 (UTC) (envelope-from mailer-daemon@vniz.net) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id A5E878FC12 for ; Mon, 22 Oct 2012 17:01:55 +0000 (UTC) Received: by mail-bk0-f54.google.com with SMTP id jf20so1131346bkc.13 for ; Mon, 22 Oct 2012 10:01:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:disposition-notification-to:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to:openpgp :content-type:content-transfer-encoding:x-gm-message-state; bh=K1ISnGEgtumL0hoDmxLIGlMpVAgesoHBa7LQZpWXS1M=; b=XmepvsW8DWktWuHRTCRsp/IzspXngV5tvqjtO53JKGpbtDMB3stbV+/somNXHvorA1 s6O0X7VQIdNCc79PiBvhTTicBVcoRZWUFSjyfMr+vqco7qYzHhJ8w5k7HuPaXgPogHuc yDCiOkqHG5VmgDrxHMM0TeLcOlkJwg/5kqu6bi5hQvi09f552SgQIHt6UOUjXLddtM6A VOvRSHExPBo9VnazjfKJpzllYZH0GtHbXR8r4SpohyJPulfVKhncNiop6RQBY6SWjy3s 2XQlOMyP4WcA7HludyQNHqeuhGDh2rDmgNqslKN6+tAg2CzEIgt8LpmLvLA787E29DmT eHwg== Received: by 10.204.147.139 with SMTP id l11mr2947412bkv.100.1350925314318; Mon, 22 Oct 2012 10:01:54 -0700 (PDT) Received: from [192.168.1.2] ([89.169.140.97]) by mx.google.com with ESMTPS id 9sm4238998bkq.13.2012.10.22.10.01.52 (version=SSLv3 cipher=OTHER); Mon, 22 Oct 2012 10:01:53 -0700 (PDT) Message-ID: <50857C01.8050500@freebsd.org> Date: Mon, 22 Oct 2012 21:01:53 +0400 From: Andrey Chernov User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: John Baldwin Subject: Re: ${CTFCONVERT_CMD} expands to empty string References: <5081F92F.8040004@freebsd.org> <508317A4.2060800@freebsd.org> <5084927C.1070101@freebsd.org> <201210221142.06889.jhb@freebsd.org> <50856F6F.40204@freebsd.org> <50857831.1070603@freebsd.org> In-Reply-To: <50857831.1070603@freebsd.org> OpenPGP: id=964474DD Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 8bit X-Gm-Message-State: ALoCoQnRb/OU8+uFroHh7SP/uG6cZq0kxDKImBi4TFRSq/pWUOUOjWYB36RtP+JCUoahiHb8fL29 Cc: stable@freebsd.org, freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 22 Oct 2012 17:01:56 -0000 All that happens because this commit is not merged into stable-9. Do you plan to mere it by yourself? r228157 | fjoe | 2011-11-30 22:07:38 +0400 (ÓÒ, 30 ÎÏÑ 2011) | 10 lines - Fix segmentation fault when running "+command" when run with -jX -n due to Compat_RunCommand() being called with `cmd' that is not on the node->commands list - Make ellipsis ("..." command) handling consistent: check for "..." command in job make after variables expansion to match compat make behavior - Fix empty command handling (after variables expansion and @+- modifiers are processed): now empty commands are ignored in compat make and are not printed in job make case - Bump MAKE_VERSION to 5-2011-11-30-0 On 22.10.2012 20:45, Andrey Chernov wrote: > And simple test case proving that make v9201206140 dislike empty commands. > Makefile: > ------------------------------------------------ > CTFCONVERT_CMD= > all: > echo ${MAKE_VERSION} > ${CTFCONVERT_CMD} > echo b > ------------------------------------------------ >> make > echo 9201206140 > 9201206140 > ${CTFCONVERT_CMD} expands to empty string > echo b > b > > On 22.10.2012 20:08, Andrey Chernov wrote: >> On 22.10.2012 19:42, John Baldwin wrote: >>> On Sunday, October 21, 2012 8:25:32 pm Andrey Chernov wrote: >>>> Those lines cause this error: >>>> .if ${MK_CTF} != "no" >>>> CTFCONVERT_CMD= ${CTFCONVERT} ${CTFFLAGS} ${.TARGET} >>>> .elif ${MAKE_VERSION} >= 5201111300 >>>> CTFCONVERT_CMD= >>>> .else >>>> CTFCONVERT_CMD= @: >>>> .endif >>>> >>>> My make version is 9201206140 >>>> So, either the check for >= 5201111300 is incorrect or change for empty >>>> make variables expansion is not merged into stable-9 >>> >>> I can't reproduce this doing a buildworld of a stable/9 checkout on a 9.0- >>> stable machine btw. What exact contents of /etc/src.conf and commands are you >>> using to reproduce this? >>> >>> I also can't find the string "empty string" in the output of my stable/9 >>> 'make universe' build before I committed this. >>> >> >> /etc/src.conf: >> WITHOUT_AMD=yes >> WITHOUT_APM=yes >> WITHOUT_ATM=yes >> WITHOUT_AUDIT=yes >> WITH_BSD_GREP=yes >> WITHOUT_BLUETOOTH=yes >> WITHOUT_BSNMP=yes >> WITHOUT_CDDL=yes >> WITHOUT_CLANG=yes >> WITHOUT_CTM=yes >> WITHOUT_FORTRAN=yes >> WITHOUT_GPIB=yes >> WITHOUT_GPIO=yes >> WITHOUT_GSSAPI=yes >> WITHOUT_I4B=yes >> WITH_IDEA=yes >> WITHOUT_IPFILTER=yes >> WITHOUT_IPX=yes >> WITHOUT_NCP=yes >> WITHOUT_NIS=yes >> WITHOUT_KERBEROS=yes >> WITHOUT_MAILWRAPPER=yes >> WITHOUT_PF=yes >> WITHOUT_PMC=yes >> WITHOUT_PROFILE=yes >> WITHOUT_RCMDS=yes >> WITHOUT_SLIP=yes >> WITHOUT_WIRELESS=yes >> >> I got that useless line _each_ .c file compiles. Example commands: >> cd /usr/src/usr.bin/make >> make clean >> make >> I got: >> cc -O2 -pipe -march=pentium4 -I/usr/src/usr.bin/make >> -DMAKE_VERSION=\"9201206140\" -DDEFSHELLNAME=\"sh\" -std=gnu99 >> -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W >> -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes >> -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch >> -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline >> -Wnested-externs -Wredundant-decls -Wold-style-definition >> -Wno-pointer-sign -c /usr/src/usr.bin/make/arch.c >> ${CTFCONVERT_CMD} expands to empty string >> ...etc... on each file. >> > From owner-freebsd-stable@FreeBSD.ORG Mon Oct 22 17:01:56 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 40C33567 for ; Mon, 22 Oct 2012 17:01:56 +0000 (UTC) (envelope-from mailer-daemon@vniz.net) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id AD3118FC16 for ; Mon, 22 Oct 2012 17:01:55 +0000 (UTC) Received: by mail-bk0-f54.google.com with SMTP id jf20so1131347bkc.13 for ; Mon, 22 Oct 2012 10:01:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:disposition-notification-to:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to:openpgp :content-type:content-transfer-encoding:x-gm-message-state; bh=K1ISnGEgtumL0hoDmxLIGlMpVAgesoHBa7LQZpWXS1M=; b=NMmleQ4UGiQVSJrDZl3SKhiN9jNsY2C0oitcsIGUG1iYVWl4lZS57GuyXy8vGq032H r3GCKrRCFUoXpQnNxdoKnVRtDyEofWfutJ4b3trM9VKulP0HxwKkzeCdt/HViVq/N6jp W2wN9fHiPpure1BRnXHaLP1mrNVxCTmA49KuJh45UQEG2V9mRBvvOf09qNlFGjNnDS2W Bl5K03nQiTWhQ+JxjSkn1UcMhP2wPQhZUKyXhRaCuq5W0nCdiU5LB8wtA/w2dmcJBeuR WTSOV9OLbJ+nV+Y7ctMC0+s2nHguZzKphL71RLTA8LQgxs8eSZ1WZ4JoSD2vc9EDzyXY KjEA== Received: by 10.204.147.139 with SMTP id l11mr2947412bkv.100.1350925314318; Mon, 22 Oct 2012 10:01:54 -0700 (PDT) Received: from [192.168.1.2] ([89.169.140.97]) by mx.google.com with ESMTPS id 9sm4238998bkq.13.2012.10.22.10.01.52 (version=SSLv3 cipher=OTHER); Mon, 22 Oct 2012 10:01:53 -0700 (PDT) Message-ID: <50857C01.8050500@freebsd.org> Date: Mon, 22 Oct 2012 21:01:53 +0400 From: Andrey Chernov User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: John Baldwin Subject: Re: ${CTFCONVERT_CMD} expands to empty string References: <5081F92F.8040004@freebsd.org> <508317A4.2060800@freebsd.org> <5084927C.1070101@freebsd.org> <201210221142.06889.jhb@freebsd.org> <50856F6F.40204@freebsd.org> <50857831.1070603@freebsd.org> In-Reply-To: <50857831.1070603@freebsd.org> OpenPGP: id=964474DD Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 8bit X-Gm-Message-State: ALoCoQnyy7mN+f6KKCPGyR9mUi5nNxI9uzVyqNuWo/ObAOb6Km0m+IkdfNPDhwXVfBb86GNfwimo Cc: stable@freebsd.org, freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 22 Oct 2012 17:01:56 -0000 All that happens because this commit is not merged into stable-9. Do you plan to mere it by yourself? r228157 | fjoe | 2011-11-30 22:07:38 +0400 (ÓÒ, 30 ÎÏÑ 2011) | 10 lines - Fix segmentation fault when running "+command" when run with -jX -n due to Compat_RunCommand() being called with `cmd' that is not on the node->commands list - Make ellipsis ("..." command) handling consistent: check for "..." command in job make after variables expansion to match compat make behavior - Fix empty command handling (after variables expansion and @+- modifiers are processed): now empty commands are ignored in compat make and are not printed in job make case - Bump MAKE_VERSION to 5-2011-11-30-0 On 22.10.2012 20:45, Andrey Chernov wrote: > And simple test case proving that make v9201206140 dislike empty commands. > Makefile: > ------------------------------------------------ > CTFCONVERT_CMD= > all: > echo ${MAKE_VERSION} > ${CTFCONVERT_CMD} > echo b > ------------------------------------------------ >> make > echo 9201206140 > 9201206140 > ${CTFCONVERT_CMD} expands to empty string > echo b > b > > On 22.10.2012 20:08, Andrey Chernov wrote: >> On 22.10.2012 19:42, John Baldwin wrote: >>> On Sunday, October 21, 2012 8:25:32 pm Andrey Chernov wrote: >>>> Those lines cause this error: >>>> .if ${MK_CTF} != "no" >>>> CTFCONVERT_CMD= ${CTFCONVERT} ${CTFFLAGS} ${.TARGET} >>>> .elif ${MAKE_VERSION} >= 5201111300 >>>> CTFCONVERT_CMD= >>>> .else >>>> CTFCONVERT_CMD= @: >>>> .endif >>>> >>>> My make version is 9201206140 >>>> So, either the check for >= 5201111300 is incorrect or change for empty >>>> make variables expansion is not merged into stable-9 >>> >>> I can't reproduce this doing a buildworld of a stable/9 checkout on a 9.0- >>> stable machine btw. What exact contents of /etc/src.conf and commands are you >>> using to reproduce this? >>> >>> I also can't find the string "empty string" in the output of my stable/9 >>> 'make universe' build before I committed this. >>> >> >> /etc/src.conf: >> WITHOUT_AMD=yes >> WITHOUT_APM=yes >> WITHOUT_ATM=yes >> WITHOUT_AUDIT=yes >> WITH_BSD_GREP=yes >> WITHOUT_BLUETOOTH=yes >> WITHOUT_BSNMP=yes >> WITHOUT_CDDL=yes >> WITHOUT_CLANG=yes >> WITHOUT_CTM=yes >> WITHOUT_FORTRAN=yes >> WITHOUT_GPIB=yes >> WITHOUT_GPIO=yes >> WITHOUT_GSSAPI=yes >> WITHOUT_I4B=yes >> WITH_IDEA=yes >> WITHOUT_IPFILTER=yes >> WITHOUT_IPX=yes >> WITHOUT_NCP=yes >> WITHOUT_NIS=yes >> WITHOUT_KERBEROS=yes >> WITHOUT_MAILWRAPPER=yes >> WITHOUT_PF=yes >> WITHOUT_PMC=yes >> WITHOUT_PROFILE=yes >> WITHOUT_RCMDS=yes >> WITHOUT_SLIP=yes >> WITHOUT_WIRELESS=yes >> >> I got that useless line _each_ .c file compiles. Example commands: >> cd /usr/src/usr.bin/make >> make clean >> make >> I got: >> cc -O2 -pipe -march=pentium4 -I/usr/src/usr.bin/make >> -DMAKE_VERSION=\"9201206140\" -DDEFSHELLNAME=\"sh\" -std=gnu99 >> -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W >> -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes >> -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch >> -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline >> -Wnested-externs -Wredundant-decls -Wold-style-definition >> -Wno-pointer-sign -c /usr/src/usr.bin/make/arch.c >> ${CTFCONVERT_CMD} expands to empty string >> ...etc... on each file. >> > From owner-freebsd-stable@FreeBSD.ORG Mon Oct 22 17:54:57 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D607F343; Mon, 22 Oct 2012 17:54:57 +0000 (UTC) (envelope-from wkoszek@freebsd.czest.pl) Received: from freebsd.czest.pl (freebsd.czest.pl [212.87.224.105]) by mx1.freebsd.org (Postfix) with ESMTP id 570458FC0C; Mon, 22 Oct 2012 17:54:57 +0000 (UTC) Received: from freebsd.czest.pl (freebsd.czest.pl [212.87.224.105]) by freebsd.czest.pl (8.14.5/8.14.5) with ESMTP id q9MHivel059974; Mon, 22 Oct 2012 17:44:57 GMT (envelope-from wkoszek@freebsd.czest.pl) Received: (from wkoszek@localhost) by freebsd.czest.pl (8.14.5/8.14.5/Submit) id q9MHiv7I059973; Mon, 22 Oct 2012 17:44:57 GMT (envelope-from wkoszek) Date: Mon, 22 Oct 2012 17:44:57 +0000 From: "Wojciech A. Koszek" To: freebsd-current@freebsd.org, freebsd-stable@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: FreeBSD in Google Code-In 2012? You can help too! Message-ID: <20121022174457.GB59689@FreeBSD.org> References: <20121016101957.GB53800@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline In-Reply-To: <20121016101957.GB53800@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (freebsd.czest.pl [212.87.224.105]); Mon, 22 Oct 2012 17:44:57 +0000 (UTC) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 22 Oct 2012 17:54:57 -0000 On Tue, Oct 16, 2012 at 10:19:57AM +0000, Wojciech A. Koszek wrote: > (cross-posted message; please keep discussion on freebsd-hackers@) > > Hello, > > Last year FreeBSD qualified for Google Code-In 2011 event--contest for > youngest open-source hackers in 13-17yr age range: > > http://www.google-melange.com/gci/homepage/google/gci2012 > > It was successful. We gained one more FreeBSD developer thanks to that > (Isabell Long) We're pondering participating in the contest this year as > well. > > For now we only have 25 ideas. We need at least 100. > > I felt all members of the FreeBSD community should help, so please submit > your own Google Code-In 2012 ideas here: > > http://www.emailmeform.com/builder/form/4aU93Obxo4NYdVAgb1 > > Examples of previously completed tasks: > > http://wiki.freebsd.org/GoogleCodeIn/2011Tasks > > Those of you who have Wiki access, please spent 2 more minutes and submit > straight to Wiki: > > http://wiki.freebsd.org/GoogleCodeIn/2012Tasks > > I plan to send out next e-mail if there's any progress on this project. > > Help will be appreciated. > Update: It looks pretty bad so far. Page: http://wiki.freebsd.org/GoogleCodeIn/2012Tasks Has 38 tasks so far out of which: ~30 would qualify. Consider this e-mail to be the last call for action. Otherwise we'll have to pull back and concentrate our efforts on GSOC instead. -- Wojciech A. Koszek wkoszek@FreeBSD.czest.pl http://FreeBSD.czest.pl/~wkoszek/ From owner-freebsd-stable@FreeBSD.ORG Mon Oct 22 18:41:03 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A191ABDC; Mon, 22 Oct 2012 18:41:03 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 759128FC1A; Mon, 22 Oct 2012 18:41:03 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id C95E3B94F; Mon, 22 Oct 2012 14:41:02 -0400 (EDT) From: John Baldwin To: Andrey Chernov Subject: Re: ${CTFCONVERT_CMD} expands to empty string Date: Mon, 22 Oct 2012 13:47:04 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p20; KDE/4.5.5; amd64; ; ) References: <5081F92F.8040004@freebsd.org> <50857831.1070603@freebsd.org> <50857C01.8050500@freebsd.org> In-Reply-To: <50857C01.8050500@freebsd.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable Message-Id: <201210221347.04727.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 22 Oct 2012 14:41:02 -0400 (EDT) Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 22 Oct 2012 18:41:03 -0000 On Monday, October 22, 2012 1:01:53 pm Andrey Chernov wrote: > All that happens because this commit is not merged into stable-9. > Do you plan to mere it by yourself? >=20 > r228157 | fjoe | 2011-11-30 22:07:38 +0400 (=D3=D2, 30 =CE=CF=D1 2011) | = 10 lines >=20 > - Fix segmentation fault when running "+command" when run with -jX -n due > to Compat_RunCommand() being called with `cmd' that is not on the node- >commands > list > - Make ellipsis ("..." command) handling consistent: check for "..." comm= and > in job make after variables expansion to match compat make behavior > - Fix empty command handling (after variables expansion and @+- modifiers > are processed): now empty commands are ignored in compat make and are not > printed in job make case > - Bump MAKE_VERSION to 5-2011-11-30-0 As soon as I can reproduce something that tests it, sure (I want to have a= =20 test case I can reproduce so that I can also check for 8). Your test Makefile does break on 8 and 9, want to do some more tests. > On 22.10.2012 20:45, Andrey Chernov wrote: > > And simple test case proving that make v9201206140 dislike empty comman= ds. > > Makefile: > > ------------------------------------------------ > > CTFCONVERT_CMD=3D > > all: > > echo ${MAKE_VERSION} > > ${CTFCONVERT_CMD} > > echo b > > ------------------------------------------------ > >> make > > echo 9201206140 > > 9201206140 > > ${CTFCONVERT_CMD} expands to empty string > > echo b > > b =2D-=20 John Baldwin From owner-freebsd-stable@FreeBSD.ORG Mon Oct 22 18:46:22 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 75E70E42; Mon, 22 Oct 2012 18:46:22 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-oa0-f54.google.com (mail-oa0-f54.google.com [209.85.219.54]) by mx1.freebsd.org (Postfix) with ESMTP id 01C478FC12; Mon, 22 Oct 2012 18:46:21 +0000 (UTC) Received: by mail-oa0-f54.google.com with SMTP id n9so3720399oag.13 for ; Mon, 22 Oct 2012 11:46:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=OrDNV42VjjwIvF2vmoqlJW9oy8GXdCtVleAjndrxpDQ=; b=cOExex4S0509o5qE4yKR1wFntuVsU3KDFYDj98Z/8C0yqdpqPgMicvk9wpSoiJCoeI +Nzud9wwYHRfHjwIihFLhfwkmu/T+cSmsINUgxV2LGwzzbXel+mNcBM1IYsL55kFpsYq UwFZ/0sdhqbHFJRYpQd8rBnW8xjbo8hr5dnc5/yDZDIyAK2/bsmkCDQrwaMUdGbN90DL veq42y0zz4BiH3Y8AFjleHicFGUDRI5nAQhZO5MQwe60awRbnGdwh/SINDKzT2h2HC43 LXjySvXY//EbCFRDR5f01kD1xj8AQQ0ivTvy5L36TRUFyy5CurFOB/WhdmiptqQul9kh 24jQ== MIME-Version: 1.0 Received: by 10.182.69.36 with SMTP id b4mr7771465obu.96.1350931581200; Mon, 22 Oct 2012 11:46:21 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.76.75.69 with HTTP; Mon, 22 Oct 2012 11:46:21 -0700 (PDT) In-Reply-To: <20121022174457.GB59689@FreeBSD.org> References: <20121016101957.GB53800@FreeBSD.org> <20121022174457.GB59689@FreeBSD.org> Date: Mon, 22 Oct 2012 11:46:21 -0700 X-Google-Sender-Auth: 8TTiWl9ralx-A2R1FP2Vkuuxkvs Message-ID: Subject: Re: FreeBSD in Google Code-In 2012? You can help too! From: Adrian Chadd To: "Wojciech A. Koszek" Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org, freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 22 Oct 2012 18:46:22 -0000 That wiki site has a distinct lack of help about: * what is required from us; * what the target is (kids, right?) * some examples of good and bad projects. Right now I have absolutely no idea what would constitute a good or bad coding project. :/ adrian From owner-freebsd-stable@FreeBSD.ORG Mon Oct 22 19:33:42 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 49F61899 for ; Mon, 22 Oct 2012 19:33:42 +0000 (UTC) (envelope-from h.schmalzbauer@omnilan.de) Received: from host.omnilan.net (s1.omnilan.net [62.245.232.135]) by mx1.freebsd.org (Postfix) with ESMTP id 9EFC48FC0C for ; Mon, 22 Oct 2012 19:33:41 +0000 (UTC) Received: from titan.inop.wdn.omnilan.net (titan.inop.wdn.omnilan.net [172.21.3.1]) (authenticated bits=0) by host.omnilan.net (8.13.8/8.13.8) with ESMTP id q9MJYtTB026222 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Oct 2012 21:34:55 +0200 (CEST) (envelope-from h.schmalzbauer@omnilan.de) Message-ID: <50859F7F.2080308@omnilan.de> Date: Mon, 22 Oct 2012 21:33:19 +0200 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: kldload if_igb twice needed to bring nic into operation X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig84DFA6B662A38E92936D6554" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 22 Oct 2012 19:33:42 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig84DFA6B662A38E92936D6554 Content-Type: multipart/mixed; boundary="------------060302090301060401030102" This is a multi-part message in MIME format. --------------060302090301060401030102 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Hello, when using igb as module, no packet is received. If I send out anything, I see the packet with tcpdump, also the switch learns the MAC address, but nothing comes back in - total silenc, no boradcasts, nothing. If I unload the module and load it again, everything works as expected! No matter if I load it by 4th loader, or later, I always have tio unload first then load it again. I'ts late here, I'll see tomorrow if things change when compieled into kernel. Maby somebody has an idea what the source of the problem could be. Please find atteched some info, the OS is 9-RC2-amd64 on ESXi5.1 and nics are pci-passthrough. --------------060302090301060401030102 Content-Type: text/plain; name="igb-info.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="igb-info.txt" dmesg from first kldload: igb0: port 0x6000-= 0x601f mem 0xd6620000-0xd663ffff,0xd6800000-0xd6bfffff,0xd6600000-0xd6603= fff irq 16 at device 0.0 on pci5 igb0: Using MSIX interrupts with 3 vectors igb0: Ethernet address: 90:e2:ba:18:f8:85 igb0: Bound queue 0 to cpu 0 igb0: Bound queue 1 to cpu 1 igb1: port 0x7000-= 0x701f mem 0xd6c20000-0xd6c3ffff,0xd7000000-0xd73fffff,0xd6c00000-0xd6c03= fff irq 17 at device 0.0 on pci6 igb1: Using MSIX interrupts with 3 vectors igb1: Ethernet address: 90:e2:ba:28:0a:47 igb1: Bound queue 0 to cpu 2 igb1: Bound queue 1 to cpu 3 igb0: link state changed to UP tcpdump -n -i igb0 -> absolute silence.......... After some attemtions to connect to this host, sysctl dev.igb.0: dev.igb.0.%desc: Intel(R) PRO/1000 Network Connection version - 2.3.4 dev.igb.0.%driver: igb dev.igb.0.%location: slot=3D0 function=3D0 handle=3D\_SB_.PCI0.PE60.S1F0 dev.igb.0.%pnpinfo: vendor=3D0x8086 device=3D0x10c9 subvendor=3D0x8086 su= bdevice=3D0xa03c class=3D0x020000 dev.igb.0.%parent: pci5 dev.igb.0.nvm: -1 dev.igb.0.enable_aim: 1 dev.igb.0.fc: 3 dev.igb.0.rx_processing_limit: 100 dev.igb.0.link_irq: 0 dev.igb.0.dropped: 0 dev.igb.0.tx_dma_fail: 0 dev.igb.0.rx_overruns: 0 dev.igb.0.watchdog_timeouts: 0 dev.igb.0.device_control: 1488978497 dev.igb.0.rx_control: 67272738 dev.igb.0.interrupt_mask: 4 dev.igb.0.extended_int_mask: 2147483648 dev.igb.0.tx_buf_alloc: 0 dev.igb.0.rx_buf_alloc: 0 dev.igb.0.fc_high_water: 47488 dev.igb.0.fc_low_water: 47472 dev.igb.0.queue0.no_desc_avail: 0 dev.igb.0.queue0.tx_packets: 1 dev.igb.0.queue0.rx_packets: 0 dev.igb.0.queue0.rx_bytes: 0 dev.igb.0.queue0.lro_queued: 0 dev.igb.0.queue0.lro_flushed: 0 dev.igb.0.queue1.no_desc_avail: 0 dev.igb.0.queue1.tx_packets: 0 dev.igb.0.queue1.rx_packets: 0 dev.igb.0.queue1.rx_bytes: 0 dev.igb.0.queue1.lro_queued: 0 dev.igb.0.queue1.lro_flushed: 0 dev.igb.0.mac_stats.excess_coll: 0 dev.igb.0.mac_stats.single_coll: 0 dev.igb.0.mac_stats.multiple_coll: 0 dev.igb.0.mac_stats.late_coll: 0 dev.igb.0.mac_stats.collision_count: 0 dev.igb.0.mac_stats.symbol_errors: 0 dev.igb.0.mac_stats.sequence_errors: 0 dev.igb.0.mac_stats.defer_count: 0 dev.igb.0.mac_stats.missed_packets: 0 dev.igb.0.mac_stats.recv_no_buff: 0 dev.igb.0.mac_stats.recv_undersize: 0 dev.igb.0.mac_stats.recv_fragmented: 0 dev.igb.0.mac_stats.recv_oversize: 0 dev.igb.0.mac_stats.recv_jabber: 0 dev.igb.0.mac_stats.recv_errs: 0 dev.igb.0.mac_stats.crc_errs: 0 dev.igb.0.mac_stats.alignment_errs: 0 dev.igb.0.mac_stats.coll_ext_errs: 0 dev.igb.0.mac_stats.xon_recvd: 0 dev.igb.0.mac_stats.xon_txd: 0 dev.igb.0.mac_stats.xoff_recvd: 0 dev.igb.0.mac_stats.xoff_txd: 0 dev.igb.0.mac_stats.total_pkts_recvd: 122 dev.igb.0.mac_stats.good_pkts_recvd: 20 dev.igb.0.mac_stats.bcast_pkts_recvd: 6 dev.igb.0.mac_stats.mcast_pkts_recvd: 9 dev.igb.0.mac_stats.rx_frames_64: 8 dev.igb.0.mac_stats.rx_frames_65_127: 10 dev.igb.0.mac_stats.rx_frames_128_255: 1 dev.igb.0.mac_stats.rx_frames_256_511: 1 dev.igb.0.mac_stats.rx_frames_512_1023: 0 dev.igb.0.mac_stats.rx_frames_1024_1522: 0 dev.igb.0.mac_stats.good_octets_recvd: 1878 dev.igb.0.mac_stats.good_octets_txd: 64 dev.igb.0.mac_stats.total_pkts_txd: 1 dev.igb.0.mac_stats.good_pkts_txd: 1 dev.igb.0.mac_stats.bcast_pkts_txd: 1 dev.igb.0.mac_stats.mcast_pkts_txd: 0 dev.igb.0.mac_stats.tx_frames_64: 1 dev.igb.0.mac_stats.tx_frames_65_127: 0 dev.igb.0.mac_stats.tx_frames_128_255: 0 dev.igb.0.mac_stats.tx_frames_256_511: 0 dev.igb.0.mac_stats.tx_frames_512_1023: 0 dev.igb.0.mac_stats.tx_frames_1024_1522: 0 dev.igb.0.mac_stats.tso_txd: 0 dev.igb.0.mac_stats.tso_ctx_fail: 0 dev.igb.0.interrupts.asserts: 239 dev.igb.0.interrupts.rx_pkt_timer: 20 dev.igb.0.interrupts.rx_abs_timer: 0 dev.igb.0.interrupts.tx_pkt_timer: 0 dev.igb.0.interrupts.tx_abs_timer: 20 dev.igb.0.interrupts.tx_queue_empty: 1 dev.igb.0.interrupts.tx_queue_min_thresh: 0 dev.igb.0.interrupts.rx_desc_min_thresh: 0 dev.igb.0.interrupts.rx_overrun: 0 dev.igb.0.host.breaker_tx_pkt: 0 dev.igb.0.host.host_tx_pkt_discard: 0 dev.igb.0.host.rx_pkt: 0 dev.igb.0.host.breaker_rx_pkts: 0 dev.igb.0.host.breaker_rx_pkt_drop: 0 dev.igb.0.host.tx_good_pkt: 0 dev.igb.0.host.breaker_tx_pkt_drop: 0 dev.igb.0.host.rx_good_bytes: 1878 dev.igb.0.host.tx_good_bytes: 64 dev.igb.0.host.length_errors: 0 dev.igb.0.host.serdes_violation_pkt: 0 dev.igb.0.host.header_redir_missed: 0 --- dmesg from unloading if_igb and loading again: --- igb0: promiscuous mode disabled igb0: detached pci5: at device 0.0 (no driver attached) igb1: detached pci6: at device 0.0 (no driver attached) igb0: port 0x6000-= 0x601f mem 0xd6620000-0xd663ffff,0xd6800000-0xd6bfffff,0xd6600000-0xd6603= fff irq 16 at device 0.0 on pci5 igb0: Using MSIX interrupts with 3 vectors igb0: Ethernet address: 90:e2:ba:18:f8:85 igb0: Bound queue 0 to cpu 0 igb0: Bound queue 1 to cpu 1 igb1: port 0x7000-= 0x701f mem 0xd6c20000-0xd6c3ffff,0xd7000000-0xd73fffff,0xd6c00000-0xd6c03= fff irq 17 at device 0.0 on pci6 igb1: Using MSIX interrupts with 3 vectors igb1: Ethernet address: 90:e2:ba:28:0a:47 igb1: Bound queue 0 to cpu 2 igb1: Bound queue 1 to cpu 3 igb0: link state changed to UP --- Voila, tcpdump -n -i igb0 after second kldload: 19:26:24.901333 STP 802.1w, Rapid STP, Flags [Forward], bridge-id 8000.d0= :7e:28:09:f0:a9.8004, length 47 19:26:26.083915 IP 172.21.1.9.1049 > 229.111.112.12.3071: UDP, length 4 19:26:26.980663 STP 802.1w, Rapid STP, Flags [Forward], bridge-id 8000.d0= :7e:28:09:f0:a9.8004, length 47 19:26:27.925346 d0:7e:28:09:f0:ae > 01:80:c2:00:00:0a, ethertype Unknown = (0x88a7), length 167:=20 0x0000: 0003 0000 01b4 be4c 0001 000e 0000 0000 .......L.......= =2E 0x0010: d07e 2809 f0a9 0007 0017 4850 2056 3139 .~(.......HP.V1= 9 0x0020: 3130 2d31 3647 2053 7769 7463 6800 0e00 10-16G.Switch..= =2E 0x0030: 1352 656c 6561 7365 2031 3531 3250 3130 .Release.1512P1= 0 0x0040: 0011 0013 5631 3030 5230 3035 4230 3944 ....V100R005B09= D 0x0050: 3031 3300 1000 0731 3538 000c 0014 1000 013....158.....= =2E 0x0060: 0000 0000 0000 0000 0000 0000 0000 0003 ...............= =2E 0x0070: 000d 6870 7377 6974 6368 3100 0200 1847 ..hpswitch1....= G 0x0080: 6967 6162 6974 4574 6865 726e 6574 312f igabitEthernet1= / 0x0090: 302f 3400 0b00 0600 03 0/4...... 19:26:28.457955 IP 172.21.1.30.1048 > 229.111.112.12.3071: UDP, length 4 19:26:28.939911 STP 802.1w, Rapid STP, Flags [Forward], bridge-id 8000.d0= :7e:28:09:f0:a9.8004, length 47 19:26:30.900036 STP 802.1w, Rapid STP, Flags [Forward], bridge-id 8000.d0= :7e:28:09:f0:a9.8004, length 47 19:26:31.100442 IP 172.21.1.9.1049 > 229.111.112.12.3071: UDP, length 4 19:26:32.900543 STP 802.1w, Rapid STP, Flags [Forward], bridge-id 8000.d0= :7e:28:09:f0:a9.8004, length 47 19:26:33.457873 IP 172.21.1.30.1048 > 229.111.112.12.3071: UDP, length 4 19:26:34.899814 STP 802.1w, Rapid STP, Flags [Forward], bridge-id 8000.d0= :7e:28:09:f0:a9.8004, length 47 19:26:35.016611 IP 172.21.3.1 > 172.21.3.97: ICMP echo request, id 39989,= seq 0, length 64 19:26:36.019143 IP 172.21.3.1 > 172.21.3.97: ICMP echo request, id 39989,= seq 1, length 64 19:26:36.114576 IP 172.21.1.9.1049 > 229.111.112.12.3071: UDP, length 4 19:26:36.900648 STP 802.1w, Rapid STP, Flags [Forward], bridge-id 8000.d0= :7e:28:09:f0:a9.8004, length 47 --------------060302090301060401030102-- --------------enig84DFA6B662A38E92936D6554 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAlCFn40ACgkQLDqVQ9VXb8gKvACgqFvRT5aRwJXgVEKt64TjuiEN QdMAn2kDwFcPnZlmeS5Jq4mubuRoLrUo =8beb -----END PGP SIGNATURE----- --------------enig84DFA6B662A38E92936D6554-- From owner-freebsd-stable@FreeBSD.ORG Mon Oct 22 19:48:53 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 96815390 for ; Mon, 22 Oct 2012 19:48:53 +0000 (UTC) (envelope-from h.schmalzbauer@omnilan.de) Received: from host.omnilan.net (s1.omnilan.net [62.245.232.135]) by mx1.freebsd.org (Postfix) with ESMTP id 0BA398FC0A for ; Mon, 22 Oct 2012 19:48:52 +0000 (UTC) Received: from titan.inop.wdn.omnilan.net (titan.inop.wdn.omnilan.net [172.21.3.1]) (authenticated bits=0) by host.omnilan.net (8.13.8/8.13.8) with ESMTP id q9MJoC00026454 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Oct 2012 21:50:13 +0200 (CEST) (envelope-from h.schmalzbauer@omnilan.de) Message-ID: <5085A323.8030501@omnilan.de> Date: Mon, 22 Oct 2012 21:48:51 +0200 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: kldload if_igb twice needed to bring nic into operation References: <50859F7F.2080308@omnilan.de> In-Reply-To: <50859F7F.2080308@omnilan.de> X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig5DE1F5107FC2D9F71E323B49" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 22 Oct 2012 19:48:53 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig5DE1F5107FC2D9F71E323B49 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable schrieb Harald Schmalzbauer am 22.10.2012 21:33 (localtime): > Hello, > > when using igb as module, no packet is received. > If I send out anything, I see the packet with tcpdump, also the switch= > learns the MAC address, but nothing comes back in - total silenc, no > boradcasts, nothing. > If I unload the module and load it again, everything works as expected!= > No matter if I load it by 4th loader, or later, I always have tio unloa= d > first then load it again. > I'ts late here, I'll see tomorrow if things change when compieled into > kernel. > Maby somebody has an idea what the source of the problem could be. > Please find atteched some info, the OS is 9-RC2-amd64 on ESXi5.1 and > nics are pci-passthrough. I found one possibly relevant difference: Non-Working state: dev.igb.0.link_irq: 0 Working state: dev.igb.0.link_irq: 2 Seems to be reproducable. If I power up the machine and load if_igb for the first time, dev.igb.0.link_irq is always "0" and after unloading and loading again, it's always "2". And tcpdump only captures anything when dev.igb.0.link_irq=3D2. That's also true for reboot. When I don't power off the machine, just rebooting, packets are passing right from the first kldload!!! Here's the complete dev.igb sysctl after second kldload: dev.igb.0.%desc: Intel(R) PRO/1000 Network Connection version - 2.3.4 dev.igb.0.%driver: igb dev.igb.0.%location: slot=3D0 function=3D0 handle=3D\_SB_.PCI0.PE60.S1F0 dev.igb.0.%pnpinfo: vendor=3D0x8086 device=3D0x10c9 subvendor=3D0x8086 subdevice=3D0xa03c class=3D0x020000 dev.igb.0.%parent: pci5 dev.igb.0.nvm: -1 dev.igb.0.enable_aim: 1 dev.igb.0.fc: 3 dev.igb.0.rx_processing_limit: 100 dev.igb.0.link_irq: 2 dev.igb.0.dropped: 0 dev.igb.0.tx_dma_fail: 0 dev.igb.0.rx_overruns: 0 dev.igb.0.watchdog_timeouts: 0 dev.igb.0.device_control: 1488978497 dev.igb.0.rx_control: 67272738 dev.igb.0.interrupt_mask: 4 dev.igb.0.extended_int_mask: 2147483655 dev.igb.0.tx_buf_alloc: 0 dev.igb.0.rx_buf_alloc: 0 dev.igb.0.fc_high_water: 47488 dev.igb.0.fc_low_water: 47472 dev.igb.0.queue0.no_desc_avail: 0 dev.igb.0.queue0.tx_packets: 9 dev.igb.0.queue0.rx_packets: 66 dev.igb.0.queue0.rx_bytes: 5992 dev.igb.0.queue0.lro_queued: 0 dev.igb.0.queue0.lro_flushed: 0 dev.igb.0.queue1.no_desc_avail: 0 dev.igb.0.queue1.tx_packets: 97 dev.igb.0.queue1.rx_packets: 133 dev.igb.0.queue1.rx_bytes: 14907 dev.igb.0.queue1.lro_queued: 0 dev.igb.0.queue1.lro_flushed: 0 dev.igb.0.mac_stats.excess_coll: 0 dev.igb.0.mac_stats.single_coll: 0 dev.igb.0.mac_stats.multiple_coll: 0 dev.igb.0.mac_stats.late_coll: 0 dev.igb.0.mac_stats.collision_count: 0 dev.igb.0.mac_stats.symbol_errors: 0 dev.igb.0.mac_stats.sequence_errors: 0 dev.igb.0.mac_stats.defer_count: 0 dev.igb.0.mac_stats.missed_packets: 0 dev.igb.0.mac_stats.recv_no_buff: 0 dev.igb.0.mac_stats.recv_undersize: 0 dev.igb.0.mac_stats.recv_fragmented: 0 dev.igb.0.mac_stats.recv_oversize: 0 dev.igb.0.mac_stats.recv_jabber: 0 dev.igb.0.mac_stats.recv_errs: 0 dev.igb.0.mac_stats.crc_errs: 0 dev.igb.0.mac_stats.alignment_errs: 0 dev.igb.0.mac_stats.coll_ext_errs: 0 dev.igb.0.mac_stats.xon_recvd: 0 dev.igb.0.mac_stats.xon_txd: 0 dev.igb.0.mac_stats.xoff_recvd: 0 dev.igb.0.mac_stats.xoff_txd: 0 dev.igb.0.mac_stats.total_pkts_recvd: 770 dev.igb.0.mac_stats.good_pkts_recvd: 191 dev.igb.0.mac_stats.bcast_pkts_recvd: 44 dev.igb.0.mac_stats.mcast_pkts_recvd: 19 dev.igb.0.mac_stats.rx_frames_64: 95 dev.igb.0.mac_stats.rx_frames_65_127: 74 dev.igb.0.mac_stats.rx_frames_128_255: 14 dev.igb.0.mac_stats.rx_frames_256_511: 5 dev.igb.0.mac_stats.rx_frames_512_1023: 3 dev.igb.0.mac_stats.rx_frames_1024_1522: 0 dev.igb.0.mac_stats.good_octets_recvd: 21099 dev.igb.0.mac_stats.good_octets_txd: 24521 dev.igb.0.mac_stats.total_pkts_txd: 101 dev.igb.0.mac_stats.good_pkts_txd: 101 dev.igb.0.mac_stats.bcast_pkts_txd: 3 dev.igb.0.mac_stats.mcast_pkts_txd: 0 dev.igb.0.mac_stats.tx_frames_64: 6 dev.igb.0.mac_stats.tx_frames_65_127: 24 dev.igb.0.mac_stats.tx_frames_128_255: 57 dev.igb.0.mac_stats.tx_frames_256_511: 3 dev.igb.0.mac_stats.tx_frames_512_1023: 7 dev.igb.0.mac_stats.tx_frames_1024_1522: 4 dev.igb.0.mac_stats.tso_txd: 4 dev.igb.0.mac_stats.tso_ctx_fail: 0 dev.igb.0.interrupts.asserts: 1653 dev.igb.0.interrupts.rx_pkt_timer: 191 dev.igb.0.interrupts.rx_abs_timer: 0 dev.igb.0.interrupts.tx_pkt_timer: 0 dev.igb.0.interrupts.tx_abs_timer: 191 dev.igb.0.interrupts.tx_queue_empty: 101 dev.igb.0.interrupts.tx_queue_min_thresh: 0 dev.igb.0.interrupts.rx_desc_min_thresh: 0 dev.igb.0.interrupts.rx_overrun: 0 dev.igb.0.host.breaker_tx_pkt: 0 dev.igb.0.host.host_tx_pkt_discard: 0 dev.igb.0.host.rx_pkt: 0 dev.igb.0.host.breaker_rx_pkts: 0 dev.igb.0.host.breaker_rx_pkt_drop: 0 dev.igb.0.host.tx_good_pkt: 0 dev.igb.0.host.breaker_tx_pkt_drop: 0 dev.igb.0.host.rx_good_bytes: 21099 dev.igb.0.host.tx_good_bytes: 24521 dev.igb.0.host.length_errors: 0 dev.igb.0.host.serdes_violation_pkt: 0 dev.igb.0.host.header_redir_missed: 0 --------------enig5DE1F5107FC2D9F71E323B49 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAlCFoyMACgkQLDqVQ9VXb8jYRwCdFAYRSC6bwSGSjJF4Dkb/flaF 3YsAn1OL2szcu+yAvp4Ax1fb04blOSOY =MRrr -----END PGP SIGNATURE----- --------------enig5DE1F5107FC2D9F71E323B49-- From owner-freebsd-stable@FreeBSD.ORG Mon Oct 22 21:42:30 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A7758D9F; Mon, 22 Oct 2012 21:42:30 +0000 (UTC) (envelope-from wkoszek@freebsd.czest.pl) Received: from freebsd.czest.pl (freebsd.czest.pl [212.87.224.105]) by mx1.freebsd.org (Postfix) with ESMTP id 294148FC08; Mon, 22 Oct 2012 21:42:28 +0000 (UTC) Received: from freebsd.czest.pl (freebsd.czest.pl [212.87.224.105]) by freebsd.czest.pl (8.14.5/8.14.5) with ESMTP id q9MLWTIv061430; Mon, 22 Oct 2012 21:32:29 GMT (envelope-from wkoszek@freebsd.czest.pl) Received: (from wkoszek@localhost) by freebsd.czest.pl (8.14.5/8.14.5/Submit) id q9MLWTfc061429; Mon, 22 Oct 2012 21:32:29 GMT (envelope-from wkoszek) Date: Mon, 22 Oct 2012 21:32:29 +0000 From: "Wojciech A. Koszek" To: Adrian Chadd Subject: Re: FreeBSD in Google Code-In 2012? You can help too! Message-ID: <20121022213229.GD59689@FreeBSD.org> References: <20121016101957.GB53800@FreeBSD.org> <20121022174457.GB59689@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (freebsd.czest.pl [212.87.224.105]); Mon, 22 Oct 2012 21:32:29 +0000 (UTC) Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org, freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 22 Oct 2012 21:42:30 -0000 On Mon, Oct 22, 2012 at 11:46:21AM -0700, Adrian Chadd wrote: > That wiki site has a distinct lack of help about: > > * what is required from us; > * what the target is (kids, right?) > * some examples of good and bad projects. > > Right now I have absolutely no idea what would constitute a good or > bad coding project. :/ > I updated the Wiki with "Sample ideas" section: http://wiki.freebsd.org/GoogleCodeIn/2012Tasks -- Wojciech A. Koszek wkoszek@FreeBSD.czest.pl http://FreeBSD.czest.pl/~wkoszek/ From owner-freebsd-stable@FreeBSD.ORG Tue Oct 23 06:50:17 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AD346382; Tue, 23 Oct 2012 06:50:17 +0000 (UTC) (envelope-from takeda@takeda.tk) Received: from chinatsu.takeda.tk (mail.takeda.tk [74.0.89.210]) by mx1.freebsd.org (Postfix) with ESMTP id 626758FC08; Tue, 23 Oct 2012 06:50:16 +0000 (UTC) Received: from takeda-ws.lan (takeda-ws.lan [10.0.0.3]) (authenticated bits=0) by chinatsu.takeda.tk (8.14.5/8.14.5) with ESMTP id q9N6oFsY003757 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 22 Oct 2012 23:50:16 -0700 (PDT) (envelope-from takeda@takeda.tk) Date: Mon, 22 Oct 2012 23:50:06 -0700 From: Derek Kulinski X-Priority: 3 (Normal) Message-ID: <335088014.20121022235006@takeda.tk> To: Jeremy Chadwick Subject: Re: Problem reading vitals from Gigabyte H77-DH3H In-Reply-To: <20121022161529.GA31919@icarus.home.lan> References: <20121022130348.GA28302@icarus.home.lan> <35578786.20121022083811@takeda.tk> <20121022161529.GA31919@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Cc: freebsd-stable@FreeBSD.org, avg@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 23 Oct 2012 06:50:17 -0000 Hello Jeremy, Monday, October 22, 2012, 9:15:29 AM, you wrote: >> Please let me know if this is enough. > I'll repeat what I wrote: > If I could get within the bowels of Gigabyte and actually talk to a > **real engineer** and not tech support, I could find out if their > GA-H77-DS3H motherboard has SMBus tie-ins for their H/W monitoring chip. > If it does, I **absolutely** could add PROPER support for it to > bsdhwmon. Ok, I guess I won't be much of help here. Do you think trying to find developers through linked-in could work? >> As for the picture of the motherboard, this one >> (http://www.nix.ru/autocatalog/motherboards_gigabyte/135869_2245_draft.jpg) >> looks way better than any of my picture. > The H/W monitoring and Super I/O chip on this board is from iTE, but I > cannot read the silkscreening. The chip model matters. It says: IT8892E 1216-FXS ZC0FYB [snip] > Supermicro Technical Support, comparatively, understands the above > question and will give full documentation for each board you ask for. > I've asked them for 10-12 boards "in bulk" once, and they provided all > the documentation for every board. It takes them about 2 weeks to get > it to you -- because they have to get it from an actual engineer. But > getting this from consumer-focused manufacturers (ex. Asus, Gigabyte, > MSI, and even Intel) is difficult. Don't ask me why. Is there somewhere a list of recommended computer components (or companies) that are helpful, so people who are building computers could take that into account? If I had something like that I would use it when building the box, since its function is to run FreeBSD. > bsdhwmon has no support for iTE chips at this time. It only works with > Supermicro motherboards which (so far) have been (mostly) Winbond chips > (now known as Nuvoton). Some Supermicro boards are also very unique > and strange, such as some of their higher-end blade-based boards, where > things are done very uniquely (in some cases, *2* H/W monitoring chips > are used on the same board, with multiple SMBus slave addresses). Any plans to add support in the future? Otherwise I guess I'll have to live with Andriy's solution. While it's not "kosher" at least provides temperature and fan speed (hopefully the values are correct). The primary reason for starting the thread was discovering that values in hw.acpi.thermal are not real. I though all devices were cool until my computer started freezing after 3 weeks of operation. -- Best regards, Derek mailto:takeda@takeda.tk There are two ways to construct a software design. Make it so simple that there are obviously no deficiencies; or make it so complicated that there are no obvious deficiencies. From owner-freebsd-stable@FreeBSD.ORG Tue Oct 23 09:49:55 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D2C89DC2 for ; Tue, 23 Oct 2012 09:49:55 +0000 (UTC) (envelope-from h.schmalzbauer@omnilan.de) Received: from host.omnilan.net (s1.omnilan.net [62.245.232.135]) by mx1.freebsd.org (Postfix) with ESMTP id 237A38FC18 for ; Tue, 23 Oct 2012 09:49:54 +0000 (UTC) Received: from titan.inop.wdn.omnilan.net (titan.inop.wdn.omnilan.net [172.21.3.1]) (authenticated bits=0) by host.omnilan.net (8.13.8/8.13.8) with ESMTP id q9N9pCdd041413 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Oct 2012 11:51:14 +0200 (CEST) (envelope-from h.schmalzbauer@omnilan.de) Message-ID: <50866839.5090204@omnilan.de> Date: Tue, 23 Oct 2012 11:49:45 +0200 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: msi-x enabled igb works only if module loaded twice [Was: Re: kldload if_igb twice needed to bring nic into operation] References: <50859F7F.2080308@omnilan.de> <5085A323.8030501@omnilan.de> In-Reply-To: <5085A323.8030501@omnilan.de> X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig6E93DD9F60145D847A8DB415" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 23 Oct 2012 09:49:55 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig6E93DD9F60145D847A8DB415 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable schrieb Harald Schmalzbauer am 22.10.2012 21:48 (localtime): > schrieb Harald Schmalzbauer am 22.10.2012 21:33 (localtime): >> Hello, >> >> when using igb as module, no packet is received. >> If I send out anything, I see the packet with tcpdump, also the switc= h >> learns the MAC address, but nothing comes back in - total silenc, no >> boradcasts, nothing. >> If I unload the module and load it again, everything works as expected= ! >> No matter if I load it by 4th loader, or later, I always have tio unlo= ad >> first then load it again. >> I'ts late here, I'll see tomorrow if things change when compieled into= >> kernel. It doesn't matter if igb is loaded as module or compiled into kernel. >> Maby somebody has an idea what the source of the problem could be. >> Please find atteched some info, the OS is 9-RC2-amd64 on ESXi5.1 and >> nics are pci-passthrough. > I found one possibly relevant difference: > > Non-Working state: dev.igb.0.link_irq: 0 > Working state: dev.igb.0.link_irq: 2 This is only true with msi-x!!! If I disable mis-x, the problem itself vanishes. igb just works fine from the initial loading (with dev.igb.0.link_irq=3D0!). So dev.igb.0.link_irq is only relevant with msi-x. But what makes me curious is why it also works mith mis-x enabled after the second kldload!?! Here's the verbose comparison: 1st attaching with msi-x enabled (non-operational): Oct 23 09:27:20 flint kernel: pci5: driver added Oct 23 09:27:20 flint kernel: found-> vendor=3D0x8086, dev=3D0x10c9, revid=3D0x01 Oct 23 09:27:20 flint kernel: domain=3D0, bus=3D5, slot=3D0, func=3D0 Oct 23 09:27:20 flint kernel: class=3D02-00-00, hdrtype=3D0x00, mfdev=3D0= Oct 23 09:27:20 flint kernel: cmdreg=3D0x0003, statreg=3D0x0010, cachelnsz=3D16 (dwords) Oct 23 09:27:20 flint kernel: lattimer=3D0x40 (1920 ns), mingnt=3D0x00 (0= ns), maxlat=3D0x00 (0 ns) Oct 23 09:27:20 flint kernel: intpin=3Da, irq=3D16 Oct 23 09:27:20 flint kernel: powerspec 3 supports D0 D3 current D0 Oct 23 09:27:20 flint kernel: MSI supports 1 message, 64 bit, vector mask= s Oct 23 09:27:20 flint kernel: MSI-X supports 10 messages in map 0x1c Oct 23 09:27:20 flint kernel: pci0:5:0:0: reprobing on driver added 00-0x601f mem 0xd6620000-0xd663ffff,0xd6800000-0xd6bfffff,0xd6600000-0xd6603fff irq 16 at device 0.0 on pci5 Oct 23 09:27:20 flint kernel: igb0: attempting to allocate 3 MSI-X vectors (10 supported) Oct 23 09:27:20 flint kernel: msi: routing MSI-X IRQ 257 to local APIC 1 vector 50 Oct 23 09:27:20 flint kernel: msi: routing MSI-X IRQ 258 to local APIC 2 vector 50 Oct 23 09:27:20 flint kernel: msi: routing MSI-X IRQ 259 to local APIC 3 vector 50 Oct 23 09:27:20 flint kernel: igb0: using IRQs 257-259 for MSI-X Oct 23 09:27:20 flint kernel: igb0: Using MSIX interrupts with 3 vectors Oct 23 09:27:20 flint kernel: igb0: bpf attached Oct 23 09:27:20 flint kernel: igb0: Ethernet address: 90:e2:ba:18:f8:85 Oct 23 09:27:20 flint kernel: msi: Assigning MSI-X IRQ 257 to local APIC 0 vector 51 Oct 23 09:27:20 flint kernel: igb0: Bound queue 0 to cpu 0 Oct 23 09:27:20 flint kernel: msi: Assigning MSI-X IRQ 258 to local APIC 1 vector 50 Oct 23 09:27:20 flint kernel: igb0: Bound queue 1 to cpu 2nd attaching with mis-x enabled (working): Oct 23 09:28:12 flint kernel: pci5: driver added Oct 23 09:28:12 flint kernel: found-> vendor=3D0x8086, dev=3D0x10c9, revid=3D0x01 Oct 23 09:28:12 flint kernel: domain=3D0, bus=3D5, slot=3D0, func=3D0 Oct 23 09:28:12 flint kernel: class=3D02-00-00, hdrtype=3D0x00, mfdev=3D0= Oct 23 09:28:12 flint kernel: cmdreg=3D0x0407, statreg=3D0x0010, cachelnsz=3D16 (dwords) Oct 23 09:28:12 flint kernel: lattimer=3D0x40 (1920 ns), mingnt=3D0x00 (0= ns), maxlat=3D0x00 (0 ns) Oct 23 09:28:12 flint kernel: intpin=3Da, irq=3D16 Oct 23 09:28:12 flint kernel: powerspec 3 supports D0 D3 current D0 Oct 23 09:28:12 flint kernel: MSI supports 1 message, 64 bit, vector mask= s Oct 23 09:28:12 flint kernel: MSI-X supports 10 messages in map 0x1c Oct 23 09:28:12 flint kernel: pci0:5:0:0: reprobing on driver added Oct 23 09:28:12 flint kernel: igb0: port 0x6000-0x601f mem 0xd6620000-0xd663ffff,0xd6800000-0xd6bfffff,0xd6600000-0xd6603fff irq 16 at device 0.0 on pci5 Oct 23 09:28:12 flint kernel: igb0: attempting to allocate 3 MSI-X vectors (10 supported) Oct 23 09:28:12 flint kernel: msi: routing MSI-X IRQ 257 to local APIC 3 vector 50 Oct 23 09:28:12 flint kernel: msi: routing MSI-X IRQ 258 to local APIC 0 vector 51 Oct 23 09:28:12 flint kernel: msi: routing MSI-X IRQ 259 to local APIC 1 vector 50 Oct 23 09:28:12 flint kernel: igb0: using IRQs 257-259 for MSI-X Oct 23 09:28:12 flint kernel: igb0: Using MSIX interrupts with 3 vectors Oct 23 09:28:12 flint kernel: igb0: bpf attached Oct 23 09:28:12 flint kernel: igb0: Ethernet address: 90:e2:ba:18:f8:85 Oct 23 09:28:12 flint kernel: msi: Assigning MSI-X IRQ 257 to local APIC 0 vector 52 Oct 23 09:28:12 flint kernel: igb0: Bound queue 0 to cpu 0 Oct 23 09:28:12 flint kernel: msi: Assigning MSI-X IRQ 258 to local APIC 1 vector 51 Oct 23 09:28:12 flint kernel: igb0: Bound queue 1 to cpu 1 Since I have no idea how drivers use MSI(X), I have no idea what the problem for this strange behaviour is. As workarround I can disable MSI-X for the driver, or better for the whole system, since also mps doesn't work with MSI-X enabled in my setup.= But I'd highly appreciate any help understanding what's going wrong. It likely has something todo with my (VT-d) passthrough setup. Thaks in advance, -Harry --------------enig6E93DD9F60145D847A8DB415 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAlCGaD4ACgkQLDqVQ9VXb8iq0wCgoHxrnXQZi6m8A6AYBC5pttXu DxcAoKUncJU03dIBdUGWlu0pDVB65gkq =J0Ra -----END PGP SIGNATURE----- --------------enig6E93DD9F60145D847A8DB415-- From owner-freebsd-stable@FreeBSD.ORG Tue Oct 23 10:21:29 2012 Return-Path: Delivered-To: FreeBSD-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CB6CD6A3 for ; Tue, 23 Oct 2012 10:21:29 +0000 (UTC) (envelope-from paul.lkw@mfun.org) Received: from mx.mfun.org (ez04.ezhosthk.com [210.17.248.117]) by mx1.freebsd.org (Postfix) with ESMTP id 86FC58FC08 for ; Tue, 23 Oct 2012 10:21:28 +0000 (UTC) Received: from mx.mfun.org (localhost [127.0.0.1]) by mx.mfun.org (Postfix) with ESMTP id 979C787D8BE for ; Tue, 23 Oct 2012 18:11:47 +0800 (HKT) Received: by mx.mfun.org (Postfix, from userid 58) id 7CB6787D8D1; Tue, 23 Oct 2012 18:11:47 +0800 (HKT) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on MFUN.ORG X-Spam-Level: X-Spam-Status: No, score=-2.9 required=6.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.3.1 Received: from [10.10.100.112] (unknown [101.78.193.98]) (Authenticated sender: paul.lkw@mfun.org) by mx.mfun.org (Postfix) with ESMTPA id 3692987D8BE for ; Tue, 23 Oct 2012 18:11:44 +0800 (HKT) Message-ID: <50866D60.5070603@mfun.org> Date: Tue, 23 Oct 2012 18:11:44 +0800 From: "Paul.LKW" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: FreeBSD-stable@FreeBSD.org Subject: Request to add Adaptec 6805 Driver on future source base Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 23 Oct 2012 10:21:29 -0000 Dear all developer of FreeBSD: I have a band new Adaptec RAID 6805, but after the buy I find FreeBSD still not embed the driver into the kernel base (Adaptec had the 8.2 driver included but not the 9.0 and further) that make hard to take great version upgrade, eg. 8.2 to 9.0. so hope you would consider this important migration for this. Best Regards, Paul.LKW From owner-freebsd-stable@FreeBSD.ORG Tue Oct 23 12:40:47 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 43E5CB86 for ; Tue, 23 Oct 2012 12:40:47 +0000 (UTC) (envelope-from h.schmalzbauer@omnilan.de) Received: from host.omnilan.net (s1.omnilan.net [62.245.232.135]) by mx1.freebsd.org (Postfix) with ESMTP id BA1D08FC0C for ; Tue, 23 Oct 2012 12:40:46 +0000 (UTC) Received: from titan.inop.wdn.omnilan.net (titan.inop.wdn.omnilan.net [172.21.3.1]) (authenticated bits=0) by host.omnilan.net (8.13.8/8.13.8) with ESMTP id q9NCg6is044318 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Oct 2012 14:42:06 +0200 (CEST) (envelope-from h.schmalzbauer@omnilan.de) Message-ID: <5086904C.3020409@omnilan.de> Date: Tue, 23 Oct 2012 14:40:44 +0200 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Possible to reset PCI device at boot? [Was: Re: msi-x enabled igb works only if module loaded twice] References: <50859F7F.2080308@omnilan.de> <5085A323.8030501@omnilan.de> <50866839.5090204@omnilan.de> In-Reply-To: <50866839.5090204@omnilan.de> X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigEE634B028EB53CF4C392AB55" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 23 Oct 2012 12:40:47 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigEE634B028EB53CF4C392AB55 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable schrieb Harald Schmalzbauer am 23.10.2012 11:49 (localtime): > schrieb Harald Schmalzbauer am 22.10.2012 21:48 (localtime): >> schrieb Harald Schmalzbauer am 22.10.2012 21:33 (localtime): >>> Hello, >>> >>> when using igb as module, no packet is received. >>> If I send out anything, I see the packet with tcpdump, also the swit= ch >>> learns the MAC address, but nothing comes back in - total silenc, no >>> boradcasts, nothing. >>> If I unload the module and load it again, everything works as expecte= d! >>> No matter if I load it by 4th loader, or later, I always have tio unl= oad >>> first then load it again. >>> I'ts late here, I'll see tomorrow if things change when compieled int= o >>> kernel. > It doesn't matter if igb is loaded as module or compiled into kernel. > >>> Maby somebody has an idea what the source of the problem could be. >>> Please find atteched some info, the OS is 9-RC2-amd64 on ESXi5.1 and >>> nics are pci-passthrough. >> I found one possibly relevant difference: >> >> Non-Working state: dev.igb.0.link_irq: 0 >> Working state: dev.igb.0.link_irq: 2 > This is only true with msi-x!!! > If I disable mis-x, the problem itself vanishes. igb just works fine > from the initial loading (with dev.igb.0.link_irq=3D0!). > So dev.igb.0.link_irq is only relevant with msi-x. > But what makes me curious is why it also works mith mis-x enabled after= > the second kldload!?! =20 I think I found the root cause: When ESXi powers up the guest, the passthru-devices are intialized with: VMKPCIPassthru: 2565: BDF =3D 02:00.1 intrType =3D 2 numVectors: 1 intrType=3D2 seems to mean MSI. I guess, IOMMUIntel is instructed to remap one irq-vector for the device. But igb uses MSI-X and wants 3 vectors. If I unload if_igb and reload again, the ESXi-log shows the following: VMKPCIPassthru: 2565: BDF =3D 02:00.1 intrType =3D 4 numVectors: 3 intrType=3D4 seems to mean MSI-X. After that initialization, if_igb works fine and saves 25kIRQ/s! I haven't found a way to change the power-up behaviour for the guest with ESXi. Is it possible to re-init a pci device from userland? Thanks, -Harry --------------enigEE634B028EB53CF4C392AB55 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAlCGkEwACgkQLDqVQ9VXb8hw1QCaAwgB2JrUv1VbvfkC+Wk1HpIc YDQAoMuhBJqde3gHrF8prBxmSK3o2C31 =8FRZ -----END PGP SIGNATURE----- --------------enigEE634B028EB53CF4C392AB55-- From owner-freebsd-stable@FreeBSD.ORG Tue Oct 23 14:18:52 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6E416D78 for ; Tue, 23 Oct 2012 14:18:52 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 3F7A58FC0A for ; Tue, 23 Oct 2012 14:18:52 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 93054B98F; Tue, 23 Oct 2012 10:18:51 -0400 (EDT) From: John Baldwin To: freebsd-stable@freebsd.org Subject: Re: Possible to reset PCI device at boot? [Was: Re: msi-x enabled igb works only if module loaded twice] Date: Tue, 23 Oct 2012 10:12:06 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p20; KDE/4.5.5; amd64; ; ) References: <50859F7F.2080308@omnilan.de> <50866839.5090204@omnilan.de> <5086904C.3020409@omnilan.de> In-Reply-To: <5086904C.3020409@omnilan.de> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201210231012.06641.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 23 Oct 2012 10:18:51 -0400 (EDT) Cc: Harald Schmalzbauer X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 23 Oct 2012 14:18:52 -0000 On Tuesday, October 23, 2012 8:40:44 am Harald Schmalzbauer wrote: > schrieb Harald Schmalzbauer am 23.10.2012 11:49 (localtime): > > schrieb Harald Schmalzbauer am 22.10.2012 21:48 (localtime): > >> schrieb Harald Schmalzbauer am 22.10.2012 21:33 (localtime): > >>> Hello, > >>> > >>> when using igb as module, no packet is received. > >>> If I send out anything, I see the packet with tcpdump, also the switch > >>> learns the MAC address, but nothing comes back in - total silenc, no > >>> boradcasts, nothing. > >>> If I unload the module and load it again, everything works as expected! > >>> No matter if I load it by 4th loader, or later, I always have tio unload > >>> first then load it again. > >>> I'ts late here, I'll see tomorrow if things change when compieled into > >>> kernel. > > It doesn't matter if igb is loaded as module or compiled into kernel. > > > >>> Maby somebody has an idea what the source of the problem could be. > >>> Please find atteched some info, the OS is 9-RC2-amd64 on ESXi5.1 and > >>> nics are pci-passthrough. > >> I found one possibly relevant difference: > >> > >> Non-Working state: dev.igb.0.link_irq: 0 > >> Working state: dev.igb.0.link_irq: 2 > > This is only true with msi-x!!! > > If I disable mis-x, the problem itself vanishes. igb just works fine > > from the initial loading (with dev.igb.0.link_irq=0!). > > So dev.igb.0.link_irq is only relevant with msi-x. > > But what makes me curious is why it also works mith mis-x enabled after > > the second kldload!?! > > I think I found the root cause: > When ESXi powers up the guest, the passthru-devices are intialized with: > VMKPCIPassthru: 2565: BDF = 02:00.1 intrType = 2 numVectors: 1 > intrType=2 seems to mean MSI. > I guess, IOMMUIntel is instructed to remap one irq-vector for the > device. But igb uses MSI-X and wants 3 vectors. > If I unload if_igb and reload again, the ESXi-log shows the following: > VMKPCIPassthru: 2565: BDF = 02:00.1 intrType = 4 numVectors: 3 > intrType=4 seems to mean MSI-X. > After that initialization, if_igb works fine and saves 25kIRQ/s! > > I haven't found a way to change the power-up behaviour for the guest > with ESXi. > > Is it possible to re-init a pci device from userland? The problem is you want the igb driver to retry MSI-X even after a re-init and that basically requires a full detach/attach, so your existing workaround is actually the "best" way to do this. :( Alternatively, you could try forcing igb to not use MSI, only use either MSI-X or INTx. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Tue Oct 23 14:27:04 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B82305C4 for ; Tue, 23 Oct 2012 14:27:04 +0000 (UTC) (envelope-from jdc@koitsu.strangled.net) Received: from qmta01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:16]) by mx1.freebsd.org (Postfix) with ESMTP id 9808B8FC14 for ; Tue, 23 Oct 2012 14:27:04 +0000 (UTC) Received: from omta12.emeryville.ca.mail.comcast.net ([76.96.30.44]) by qmta01.emeryville.ca.mail.comcast.net with comcast id EcTs1k0070x6nqcA1eT4Z3; Tue, 23 Oct 2012 14:27:04 +0000 Received: from koitsu.strangled.net ([67.180.84.87]) by omta12.emeryville.ca.mail.comcast.net with comcast id EeT31k0071t3BNj8YeT3lm; Tue, 23 Oct 2012 14:27:03 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 1960173A1A; Tue, 23 Oct 2012 07:27:03 -0700 (PDT) Date: Tue, 23 Oct 2012 07:27:03 -0700 From: Jeremy Chadwick To: freebsd-stable@freebsd.org Subject: pty/tty or signal strangeness, or grep/bsdgrep bug? Message-ID: <20121023142703.GA79098@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Cc: kib@freebsd.org, ed@freebsd.org, jhb@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 23 Oct 2012 14:27:04 -0000 Please keep me CC'd as I'm not subscribed to the list. Something "fun" today. First off: yes, I should have been using 'bsdgrep -r -- "-2011" .', and yes that works fine, but that's besides the point. Here we go: % bsdgrep -r "-2011" . ^Z Suspended % bg [1] bsdgrep -r -2011 . & % qqqqqqqqqqq % % fg(standard input):qqqqqqqqqfgfg bsdgrep -r -2011 . ^C % Let me explain what transpired from an input perspective: 1. Ran bsdgrep -r "-2011" . 2. Pressed Ctrl-Z 3. Typed bg 4. Typed "q" 20 times in a row exactly 5. Pressed Ctrl-C 6. Typed "fg" and pressed Enter 7. Typed "ffgg" and pressed Enter 8. Pressed Ctrl-Z and Enter 9. Pressed Ctrl-C What's going on here? Where is the famous "Suspended (tty input)"? It gets more interesting. Here's another one: % bsdgrep -r "-2011" . ^Z Suspended % bg [1] bsdgrep -r -2011 . & % g(standard input):f fg gfg: Command not found. [1] + Suspended (tty input) bsdgrep -r -2011 . % jobs [1] + Suspended (tty input) bsdgrep -r -2011 . % fg bsdgrep -r -2011 . % And what transpired input-wise: 1. Ran bsdgrep -r "-2011" . 2. Pressed Ctrl-Z 3. Typed bg 4. Typed "fg" and Enter 5. Typed "fg" again and pressed Enter 6. Typed "jobs" and pressed Enter 7. Typed "fg" and pressed Enter 8. Pressed Ctrl-D Some facts: - Fully 100% reproducible - Tested only on RELENG_9 (source from 2012/10/21) - Happens regardless of shell (bash and csh tested; csh w/out dot files) - Similar behaviour happens with our base system grep (GNU grep) but sometimes it manifests itself in a weirder way - bsdgrep and GNU grep are both in state "ttyin" when this happens CC'ing some folks who might have some ideas or can explain how to troubleshoot this one. For the signal part, I believe this would be SIGTTIN. -- | Jeremy Chadwick jdc@koitsu.org | | UNIX Systems Administrator http://jdc.koitsu.org/ | | Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Tue Oct 23 14:39:12 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0A62E8AC; Tue, 23 Oct 2012 14:39:11 +0000 (UTC) (envelope-from fbsd8@a1poweruser.com) Received: from mail-03.name-services.com (mail-03.name-services.com [69.64.155.195]) by mx1.freebsd.org (Postfix) with ESMTP id A62DD8FC16; Tue, 23 Oct 2012 14:39:11 +0000 (UTC) Received: from [10.0.10.3] ([173.88.209.200]) by mail-03.name-services.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 23 Oct 2012 07:39:02 -0700 Message-ID: <5086AC06.5070405@a1poweruser.com> Date: Tue, 23 Oct 2012 10:39:02 -0400 From: Fbsd8 User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: "Wojciech A. Koszek" Subject: Re: FreeBSD in Google Code-In 2012? You can help too! References: <20121016101957.GB53800@FreeBSD.org> <20121022174457.GB59689@FreeBSD.org> In-Reply-To: <20121022174457.GB59689@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Oct 2012 14:39:02.0467 (UTC) FILETIME=[25374930:01CDB12C] X-Sender: fbsd8@a1poweruser.com X-Authenticated-Sender: fbsd8@a1poweruser.com X-EchoSenderHash: [fbsd8]-[a1poweruser*com] Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org, freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 23 Oct 2012 14:39:12 -0000 Wojciech A. Koszek wrote: > On Tue, Oct 16, 2012 at 10:19:57AM +0000, Wojciech A. Koszek wrote: >> (cross-posted message; please keep discussion on freebsd-hackers@) >> >> Hello, >> >> Last year FreeBSD qualified for Google Code-In 2011 event--contest for >> youngest open-source hackers in 13-17yr age range: >> >> http://www.google-melange.com/gci/homepage/google/gci2012 >> >> It was successful. We gained one more FreeBSD developer thanks to that >> (Isabell Long) We're pondering participating in the contest this year as >> well. >> >> For now we only have 25 ideas. We need at least 100. >> >> I felt all members of the FreeBSD community should help, so please submit >> your own Google Code-In 2012 ideas here: >> >> http://www.emailmeform.com/builder/form/4aU93Obxo4NYdVAgb1 >> >> Examples of previously completed tasks: >> >> http://wiki.freebsd.org/GoogleCodeIn/2011Tasks >> >> Those of you who have Wiki access, please spent 2 more minutes and submit >> straight to Wiki: >> >> http://wiki.freebsd.org/GoogleCodeIn/2012Tasks >> >> I plan to send out next e-mail if there's any progress on this project. >> >> Help will be appreciated. >> > > Update: > > It looks pretty bad so far. Page: > > http://wiki.freebsd.org/GoogleCodeIn/2012Tasks > > Has 38 tasks so far out of which: > > ~30 would qualify. > > Consider this e-mail to be the last call for action. Otherwise we'll have to > pull back and concentrate our efforts on GSOC instead. > The subject is Google Code-In and all the posted tasks are directed at creating documentation. Not one deals with coding any programs. If I was 15-17 years old I sure would not be interested in writing documentation. I would want to use and develop my coding skills. To that end there a lot of simple PR's waiting for attention. This is an target area that young coders would find more interesting. Such as kern/170090 or replacing the Freebsd Ipfilter v4.1.28 version with the current Ipfilter version 5.1.2. This is just reusing the tools used last time ipfilter was ported over. Just my 2 cents. From owner-freebsd-stable@FreeBSD.ORG Tue Oct 23 16:05:20 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 70D99178 for ; Tue, 23 Oct 2012 16:05:20 +0000 (UTC) (envelope-from l.pizzamiglio@bally-wulff.de) Received: from mail.bally-wulff.de (mail.bally-wulff.de [212.144.118.8]) by mx1.freebsd.org (Postfix) with ESMTP id CC6128FC17 for ; Tue, 23 Oct 2012 16:05:19 +0000 (UTC) Received: from bwex.bally-wulff.de (bwex.bally-wulff.de [192.168.204.106]) by mail.bally-wulff.de (Postfix) with ESMTP id AC5664E080; Tue, 23 Oct 2012 17:58:50 +0200 (CEST) Received: from pizzamig.bally.de ([192.168.205.30]) by bwex.bally-wulff.de with Microsoft SMTPSVC(6.0.3790.4675); Tue, 23 Oct 2012 17:59:22 +0200 Message-ID: <5086BEDA.8000502@bally-wulff.de> Date: Tue, 23 Oct 2012 17:59:22 +0200 From: Luca Pizzamiglio User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:16.0) Gecko/20121015 Thunderbird/16.0.1 MIME-Version: 1.0 To: Neal Nelson Subject: Re: 9.1 and intel graphics References: <20121020041408.GA1218@mycenae.sbb.rs> <14C15BD0-8E83-46BD-9693-D15D045300B5@kobudo.homeunix.net> In-Reply-To: <14C15BD0-8E83-46BD-9693-D15D045300B5@kobudo.homeunix.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Oct 2012 15:59:22.0022 (UTC) FILETIME=[5DE50460:01CDB137] Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 23 Oct 2012 16:05:20 -0000 Hi Neal, I made some test with 9 stable on SandyBridge and IvyBridge CPU. With Sandybridge, I compiled everything without problem, openGL correctly detected, configured and accelerated, KDE with compisition up and running. With Ivybridge, I compiled everything without problem, openGL correctly detected and configured, but not accelerated, swrast was used instead. Problem detected using simple test like glxgears or engine. You could compile the intel driver manually. But I'm using the xorg-dev repository to obtain the last version of drivers and library. best regards, Luca On 10/21/12 17:57, Neal Nelson wrote: > > On 2012-Oct-20, at 08:29 , Kevin Oberman wrote: > >> On Fri, Oct 19, 2012 at 9:14 PM, Zoran Kolic wrote: >>> Yesterday I have gotten lenovo e320 laptop, with core i3 2350 >>> and HD3000 integrated. Gonna wait few days till 9.1 release. >>> I never used anything aside "intel" on my old laptop. Kostik >>> Belousov made a port of kms and I found patches from june and >>> jule on the net. What should I do after 9.1 install in this >>> case? I assume kms is in xorg. Do I have to find and install >>> some driver from intel? Do I need to change xorg.conf after >>> configure flag, that will make conf file? >> >> Full support for the HD3000 is in 9-stable and 9.1-Beta and all RCs. >> To use it you need to build X drivers and drm and the kernel with: >> WITH_NEW_XORG=YES >> WITH_KMS=YES >> in /etc/make.conf. >> >> Specifically, the kernel and a few ports. graphics/drm and your >> org-drivers: xf86-video-intel, xf86-input-synaptics, xf86-input-mouse, >> and xf86-input-keyboard. Then just start X. Don't try loading the >> kernel module. It will be loaded by the startx. >> >>> Finally, what happens when I leave x and want to go back to >>> console mode? >> >> You don't If you try, your system will lock up. You need to shutdown >> from a window in X. Hopefully someone will implement switching back to >> console mode some day, but it has not happened, yet. >> >>> I tried out live RC2 from usb stick. Few acpi errors, intel >>> 1000 wifi found. After some time "sysctl hw.acpi" gave me the >>> cpu temperature of 50C. Fan was on. Probably temp gonna go >>> down when I add powerd and cx_lowest to rc.conf on hdd. Is >>> it normal temp for this cpu? >> >> Pretty reasonable. Be sure to set both cx_lowest to "Cmax". It is new >> to 9.1 and fixes some serious issues with C-states on many newer >> platforms. Specifically that some platforms skip some C-states and >> FreeBSD never used the ones saving more power than hte one skipped. >> >> I always remind folks to blow out the heat sink on laptops about one a >> year. Dust is a great insulator and laptops often collect a lot more >> dust than office systems, though my office system started dying during >> buildworld last week and blowing out the CPU heat sink fixed it up, >> but it had been sitting around for almost three years collecting dust. > > I'm trying to do something similar, except with an HD4000 (i5-3570K) on 9.1-RC2. > > The problem I'm having, after setting the make variables as above, is that xorg-drivers port doesn't show the intel driver. In fact, there's the specific part of the Makefile: > > .if (${ARCH} == "amd64" || ${ARCH} == "i386") && !defined(WITH_NEW_XORG) > VIDEO_ON+= intel > .endif > > So what driver should I be using? > > Thanks, > > Neal. > _______________________________________________ > 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 Tue Oct 23 17:09:48 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9E90DE73 for ; Tue, 23 Oct 2012 17:09:48 +0000 (UTC) (envelope-from peo@intersonic.se) Received: from neonpark.inter-sonic.com (neonpark.inter-sonic.com [212.247.8.98]) by mx1.freebsd.org (Postfix) with ESMTP id 4C3C08FC12 for ; Tue, 23 Oct 2012 17:09:47 +0000 (UTC) X-Virus-Scanned: amavisd-new at BSDLabs AB Message-ID: <5086CD71.7020006@intersonic.se> Date: Tue, 23 Oct 2012 19:01:37 +0200 From: Per olof Ljungmark Organization: Intersonic AB User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:16.0) Gecko/20121015 Thunderbird/16.0.1 MIME-Version: 1.0 To: "freebsd-stable@freebsd.org" Subject: The shutdown bug? Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 23 Oct 2012 17:09:48 -0000 As described in earlier reports, 9-STABLE sometimes cannot halt or reboot properly. FreeBSD 9.1-PRERELEASE #0 r241866: Mon Oct 22 16:28:47 CEST 2012 All ZFS file system, no NFS mounts. The problem occurs after updating sources and rebuilding world for some reason the I suspect is connected to the file system. "shutdown -r now" or "halt -p" will stop after "Syncing discs" forever. It is seen here on various HP boxes, DL360 G4, G5, XW6600 are examples. Issuing a "shutdown -n -o -r now" works however and I assume this is not too harmful with ZFS? Setting sysctl hw.usb.no_shutdown_wait=1 does NOT fix the problem as described in http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/167685 Should I file another bug or add to the existing? Would it be useful to build a debug kernel, if yes, including what? Thanks! //per From owner-freebsd-stable@FreeBSD.ORG Tue Oct 23 17:11:23 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BC7C5FB5; Tue, 23 Oct 2012 17:11:23 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pa0-f54.google.com (mail-pa0-f54.google.com [209.85.220.54]) by mx1.freebsd.org (Postfix) with ESMTP id 760828FC1C; Tue, 23 Oct 2012 17:11:23 +0000 (UTC) Received: by mail-pa0-f54.google.com with SMTP id bi1so3042487pad.13 for ; Tue, 23 Oct 2012 10:11:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=RKNEsUFxwb68ngcI2xczI3T6Vga9DI6cHrbcLkzgLKM=; b=VxEvbrqEm6H6xT+TOBWh/7tqUWo7A3g+u7DqacrGnbHZKkeoF+I+VAshtA4ARzXi7H tablQpFOGv/sl7T2QgOmfVQFWcKQ4RZNZPLJZcLqU6lnqpksCr3OJjxOiIjRYMuFXEjW g7aJP9LDh431f3ufZWVvSg819ssA/dNndbfgds+9KOnwO1uMS9lVeUNnpB5aYP+sgPUr +T5mvvhh/c6LqNXTRLBK8y6tzsKMY4keD0T/+VfO2dfc6uh4tSeviNYnzpT4WqFoTX8Y FL3Js0V8e9/jL7+TdfGtbLA4lGo2mloOyrIJOEWF8KInrErZM2nghnmE7cj8oE1fxmVF fB+w== MIME-Version: 1.0 Received: by 10.66.79.166 with SMTP id k6mr36946336pax.25.1351012282625; Tue, 23 Oct 2012 10:11:22 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.68.146.233 with HTTP; Tue, 23 Oct 2012 10:11:21 -0700 (PDT) In-Reply-To: <5086AC06.5070405@a1poweruser.com> References: <20121016101957.GB53800@FreeBSD.org> <20121022174457.GB59689@FreeBSD.org> <5086AC06.5070405@a1poweruser.com> Date: Tue, 23 Oct 2012 10:11:21 -0700 X-Google-Sender-Auth: 6JnWfZpTm_HfKi9hBayVIwUvsMA Message-ID: Subject: Re: FreeBSD in Google Code-In 2012? You can help too! From: Adrian Chadd To: Fbsd8 Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org, "Wojciech A. Koszek" , freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 23 Oct 2012 17:11:23 -0000 On 23 October 2012 07:39, Fbsd8 wrote: > The subject is Google Code-In and all the posted tasks are directed at > creating documentation. Not one deals with coding any programs. If I was > 15-17 years old I sure would not be interested in writing documentation. I > would want to use and develop my coding skills. To that end there a lot of > simple PR's waiting for attention. This is an target area that young coders > would find more interesting. > > Such as kern/170090 > or > replacing the Freebsd Ipfilter v4.1.28 version with the current Ipfilter > version 5.1.2. This is just reusing the tools used last time ipfilter was > ported over. > > Just my 2 cents. So where are examples of what other successful open source projects have done? Adrian From owner-freebsd-stable@FreeBSD.ORG Tue Oct 23 17:23:26 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D6770575; Tue, 23 Oct 2012 17:23:26 +0000 (UTC) (envelope-from dmagda@ee.ryerson.ca) Received: from eccles.ee.ryerson.ca (eccles.ee.ryerson.ca [141.117.1.2]) by mx1.freebsd.org (Postfix) with ESMTP id 8D02E8FC08; Tue, 23 Oct 2012 17:23:26 +0000 (UTC) Received: from webmail.ee.ryerson.ca (eccles [172.16.1.2]) by eccles.ee.ryerson.ca (8.14.4/8.14.4) with ESMTP id q9NGsGph011571; Tue, 23 Oct 2012 12:54:17 -0400 (EDT) (envelope-from dmagda@ee.ryerson.ca) Received: from 206.108.127.2 (SquirrelMail authenticated user dmagda) by webmail.ee.ryerson.ca with HTTP; Tue, 23 Oct 2012 12:54:17 -0400 Message-ID: <5214043c002ef030f59c2045344b8725.squirrel@webmail.ee.ryerson.ca> In-Reply-To: <5086AC06.5070405@a1poweruser.com> References: <20121016101957.GB53800@FreeBSD.org> <20121022174457.GB59689@FreeBSD.org> <5086AC06.5070405@a1poweruser.com> Date: Tue, 23 Oct 2012 12:54:17 -0400 Subject: Re: FreeBSD in Google Code-In 2012? You can help too! From: "David Magda" To: "Fbsd8" User-Agent: SquirrelMail/1.4.22 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org, "Wojciech A. Koszek" , freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 23 Oct 2012 17:23:27 -0000 On Tue, October 23, 2012 10:39, Fbsd8 wrote: > > The subject is Google Code-In and all the posted tasks are directed at > creating documentation. Not one deals with coding any programs. If I was > 15-17 years old I sure would not be interested in writing documentation. > I would want to use and develop my coding skills. To that end there a > lot of simple PR's waiting for attention. This is an target area that > young coders would find more interesting. It would depend on what one's interests were. I've known a few technical writers over the years, and even if that is not one's long-term career objective, being paid to simply write is something a lot of people wouldn't mind doing. It's just that most writers don't hang out on Unix mailing lists. :) From owner-freebsd-stable@FreeBSD.ORG Tue Oct 23 17:41:47 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5707FCBA for ; Tue, 23 Oct 2012 17:41:47 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) by mx1.freebsd.org (Postfix) with ESMTP id 0E4728FC19 for ; Tue, 23 Oct 2012 17:41:46 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1TQiU3-00034Y-TJ for freebsd-stable@freebsd.org; Tue, 23 Oct 2012 19:41:44 +0200 Received: from 79-139-19-75.prenet.pl ([79.139.19.75]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 23 Oct 2012 19:41:43 +0200 Received: from jb.1234abcd by 79-139-19-75.prenet.pl with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 23 Oct 2012 19:41:43 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: jb Subject: Re: The shutdown bug? Date: Tue, 23 Oct 2012 17:41:26 +0000 (UTC) Lines: 16 Message-ID: References: <5086CD71.7020006@intersonic.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: sea.gmane.org User-Agent: Loom/3.14 (http://gmane.org/) X-Loom-IP: 79.139.19.75 (Mozilla/5.0 (X11; FreeBSD i386; rv:16.0) Gecko/20100101 Firefox/16.0) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 23 Oct 2012 17:41:47 -0000 Per olof Ljungmark intersonic.se> writes: > ... > Setting sysctl hw.usb.no_shutdown_wait=1 does NOT fix the problem as > described in > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/167685 > ... There is another one: http://www.freebsd.org/cgi/query-pr.cgi?pr=172952&cat= jb From owner-freebsd-stable@FreeBSD.ORG Tue Oct 23 18:38:59 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 574E3221 for ; Tue, 23 Oct 2012 18:38:59 +0000 (UTC) (envelope-from peo@intersonic.se) Received: from neonpark.inter-sonic.com (neonpark.inter-sonic.com [212.247.8.98]) by mx1.freebsd.org (Postfix) with ESMTP id 00D998FC08 for ; Tue, 23 Oct 2012 18:38:58 +0000 (UTC) X-Virus-Scanned: amavisd-new at BSDLabs AB Message-ID: <5086E43D.1010702@intersonic.se> Date: Tue, 23 Oct 2012 20:38:53 +0200 From: Per olof Ljungmark Organization: Intersonic AB User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:16.0) Gecko/20121015 Thunderbird/16.0.1 MIME-Version: 1.0 To: jb Subject: Re: The shutdown bug? References: <5086CD71.7020006@intersonic.se> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 23 Oct 2012 18:38:59 -0000 On 2012-10-23 19:41, jb wrote: > Per olof Ljungmark intersonic.se> writes: > >> ... >> Setting sysctl hw.usb.no_shutdown_wait=1 does NOT fix the problem as >> described in >> http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/167685 >> ... > > There is another one: > http://www.freebsd.org/cgi/query-pr.cgi?pr=172952&cat= > jb Thanks, I'll add my experiences to that one. From owner-freebsd-stable@FreeBSD.ORG Tue Oct 23 19:44:38 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 74C5CCB4 for ; Tue, 23 Oct 2012 19:44:38 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id BC7E88FC19 for ; Tue, 23 Oct 2012 19:44:37 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id WAA16341; Tue, 23 Oct 2012 22:44:31 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1TQkOt-000H0H-GM; Tue, 23 Oct 2012 22:44:31 +0300 Message-ID: <5086F39E.7050708@FreeBSD.org> Date: Tue, 23 Oct 2012 22:44:30 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:16.0) Gecko/20121013 Thunderbird/16.0.1 MIME-Version: 1.0 To: Per olof Ljungmark Subject: Re: The shutdown bug? References: <5086CD71.7020006@intersonic.se> <5086E43D.1010702@intersonic.se> In-Reply-To: <5086E43D.1010702@intersonic.se> X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@FreeBSD.org, jb X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 23 Oct 2012 19:44:38 -0000 on 23/10/2012 21:38 Per olof Ljungmark said the following: > On 2012-10-23 19:41, jb wrote: >> Per olof Ljungmark intersonic.se> writes: >> >>> ... >>> Setting sysctl hw.usb.no_shutdown_wait=1 does NOT fix the problem as >>> described in >>> http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/167685 >>> ... >> >> There is another one: >> http://www.freebsd.org/cgi/query-pr.cgi?pr=172952&cat= >> jb > > Thanks, I'll add my experiences to that one. I've just posted another followup to that PR. If you could do some debugging that would be great. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Tue Oct 23 19:59:44 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 65DB029C for ; Tue, 23 Oct 2012 19:59:44 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: from mail-da0-f54.google.com (mail-da0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id 2AED18FC19 for ; Tue, 23 Oct 2012 19:59:44 +0000 (UTC) Received: by mail-da0-f54.google.com with SMTP id z9so2175212dad.13 for ; Tue, 23 Oct 2012 12:59:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Jb8y8Rxjm+91YSll3JXK0JhP/OeLIn6Hsy1pmtBRBq0=; b=LGj0y8THFCz/idRSROOpgVAiTpe8rSWa8eessMdFKKxH9ZpXXlENffmi+EPbhWD18J qk3YE2jgGgDqH83MiqPkXW+91QPpgISC9Z4xEL21WmfRaiBTrPxWfZXWl7atCH3FBlPl i9lacSU0GHPPCfMYt7zJBFYCRa41IViF7mhhQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=Jb8y8Rxjm+91YSll3JXK0JhP/OeLIn6Hsy1pmtBRBq0=; b=WrhX/99ZDqhF+bCy5cw/UBjM9K8NaCeK8YTHl3CzllycQmsOmGe0kpGLMxnXJEhELv eI+k7UBDklsPgg64fGBWc+W/fJUMXY7cX+uhCDm1+/p/UPVZ+dAvkl7ID5RG6CBrvKa6 WD5Ios4A7LJYoYb3KD4FVm75P1a6qX8fm5Mq7/bJaBtvQdgJzRsf+XZB4caFlsdjeoEU UTwvRsHbPeIRYXa6uI2M0iUR+D5Fr6TchKcqp8nvIqErfxr9404mJUi26SPGdbcAAqN4 J6HRg2O/3FBbaLn+We4ugIeINdNfeaIJDexH39bg9eIyePB/8bi7A6Z2D2dCXt9jlSIu Zc+g== Received: by 10.66.76.231 with SMTP id n7mr37905916paw.68.1351022377922; Tue, 23 Oct 2012 12:59:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.161.163 with HTTP; Tue, 23 Oct 2012 12:59:07 -0700 (PDT) In-Reply-To: <5214043c002ef030f59c2045344b8725.squirrel@webmail.ee.ryerson.ca> References: <20121016101957.GB53800@FreeBSD.org> <20121022174457.GB59689@FreeBSD.org> <5086AC06.5070405@a1poweruser.com> <5214043c002ef030f59c2045344b8725.squirrel@webmail.ee.ryerson.ca> From: Eitan Adler Date: Tue, 23 Oct 2012 15:59:07 -0400 Message-ID: Subject: Re: FreeBSD in Google Code-In 2012? You can help too! To: David Magda Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQm8+SfJJSRAEJx8CJIScU1yOAv29pwrth8IQ64juZ6OhSMTdb6jkWcJ87sR9KcQfCmSkHEe Cc: freebsd-hackers@freebsd.org, Fbsd8 , "Wojciech A. Koszek" , freebsd-stable@freebsd.org, freebsd-current@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 23 Oct 2012 19:59:44 -0000 On 23 October 2012 12:54, David Magda wrote: > On Tue, October 23, 2012 10:39, Fbsd8 wrote: >> >> The subject is Google Code-In and all the posted tasks are directed at >> creating documentation. Not one deals with coding any programs. If I was >> 15-17 years old I sure would not be interested in writing documentation. >> I would want to use and develop my coding skills. To that end there a >> lot of simple PR's waiting for attention. This is an target area that >> young coders would find more interesting. > > It would depend on what one's interests were. Google code-in is aimed at *coders* and there is an expectation of people writing *code*. The biggest complaint for GCI last year was "not enough coding tasks" -- Eitan Adler From owner-freebsd-stable@FreeBSD.ORG Tue Oct 23 20:03:57 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E7A63615 for ; Tue, 23 Oct 2012 20:03:57 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 9908E8FC12 for ; Tue, 23 Oct 2012 20:03:57 +0000 (UTC) Received: by mail-pb0-f54.google.com with SMTP id rp8so741593pbb.13 for ; Tue, 23 Oct 2012 13:03:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=WvSuWz46DZVyK1kELi49uwZ1Ea9rT6GpyvAoO47Y7mU=; b=Rw6sYe8jq127bW/5gMRt3X3vjDjPswGpyyvGz/MtlLdqc1cwBHym6AAv5Qc/2VAkwa EdrvPyZwMn45JIK+icganQgYHDeEMhlw/H+xl5sbwkhjbsi6R/baBE6BwsPDdyR/vUdQ eYG9DjFTUGb5+RizdnZxSVuK8WR1qVObGvchc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=WvSuWz46DZVyK1kELi49uwZ1Ea9rT6GpyvAoO47Y7mU=; b=oq6xUKipCvfPmzH+gDWAmonWLhAcwZsXiIXo5pxZc/lJ0GVNw9tQQw3yqUze6RwN1w j/IE8e1OIJr794R3cLEKNMj9fe3F/hFkOiBmWSTC2J/D+79nZ24XvKduhwtKGJvSRy9U Lt6wCbn+iZFFsmrQ5CaCMam/4M0o8KR3V+S6ZMLOW0AUlTYcyE9URA2apNEJhkMnK8+2 NVzxliLRKSLCxeJs+Fi4MfKlVh2rn5alE3q2MU8yLaipGRDRTjt3zSezAJXoK8eI7ErQ PMXO6joB0dhkc39CCnmNodAPUiez/rlzeo8yVf3yfqHExlJ4OhpgKRh+IeO1k8mH1Coj SCCg== Received: by 10.66.90.65 with SMTP id bu1mr38137869pab.31.1351022637203; Tue, 23 Oct 2012 13:03:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.161.163 with HTTP; Tue, 23 Oct 2012 13:03:27 -0700 (PDT) In-Reply-To: References: <20121016101957.GB53800@FreeBSD.org> <20121022174457.GB59689@FreeBSD.org> <5086AC06.5070405@a1poweruser.com> From: Eitan Adler Date: Tue, 23 Oct 2012 16:03:27 -0400 Message-ID: Subject: Re: FreeBSD in Google Code-In 2012? You can help too! To: Adrian Chadd Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQnqqNojjkaBdTTujEwp+Ba7iOWNh7IEReZ3Ype08RVLzXcO6H38jValoK1AQQUiXkDFzv3V Cc: freebsd-hackers@freebsd.org, Fbsd8 , "Wojciech A. Koszek" , freebsd-stable@freebsd.org, freebsd-current@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 23 Oct 2012 20:03:58 -0000 On 23 October 2012 13:11, Adrian Chadd wrote: > So where are examples of what other successful open source projects have done? There are tasks done by the winner last year: https://www.google-melange.com/gci/student_tasks/google/gci2011/dragooon Here are all the tasks last year: https://www.google-melange.com/gci/tasks/google/gci2011 -- Eitan Adler From owner-freebsd-stable@FreeBSD.ORG Tue Oct 23 20:31:49 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EA0426B7; Tue, 23 Oct 2012 20:31:49 +0000 (UTC) (envelope-from peo@intersonic.se) Received: from neonpark.inter-sonic.com (neonpark.inter-sonic.com [212.247.8.98]) by mx1.freebsd.org (Postfix) with ESMTP id A42C38FC08; Tue, 23 Oct 2012 20:31:49 +0000 (UTC) X-Virus-Scanned: amavisd-new at BSDLabs AB Message-ID: <5086FEB1.2000701@intersonic.se> Date: Tue, 23 Oct 2012 22:31:45 +0200 From: Per olof Ljungmark Organization: Intersonic AB User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:16.0) Gecko/20121015 Thunderbird/16.0.1 MIME-Version: 1.0 To: Andriy Gapon Subject: Re: The shutdown bug? References: <5086CD71.7020006@intersonic.se> <5086E43D.1010702@intersonic.se> <5086F39E.7050708@FreeBSD.org> In-Reply-To: <5086F39E.7050708@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@FreeBSD.org, jb X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 23 Oct 2012 20:31:50 -0000 On 10/23/12 21:44, Andriy Gapon wrote: > on 23/10/2012 21:38 Per olof Ljungmark said the following: >> On 2012-10-23 19:41, jb wrote: >>> Per olof Ljungmark intersonic.se> writes: >>> >>>> ... >>>> Setting sysctl hw.usb.no_shutdown_wait=1 does NOT fix the problem as >>>> described in >>>> http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/167685 >>>> ... >>> >>> There is another one: >>> http://www.freebsd.org/cgi/query-pr.cgi?pr=172952&cat= >>> jb >> >> Thanks, I'll add my experiences to that one. > > I've just posted another followup to that PR. If you could do some debugging > that would be great. Building a debugging kernel now, we'll see tomorrow if it works out. Tested an updated HP DL380 G5 all ZFS before leaving work and it was the same, no reboot. From owner-freebsd-stable@FreeBSD.ORG Tue Oct 23 20:39:35 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6DE20AE0; Tue, 23 Oct 2012 20:39: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 B0BBA8FC0A; Tue, 23 Oct 2012 20:39:33 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q9NKde5L084415; Tue, 23 Oct 2012 23:39:40 +0300 (EEST) (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.5/8.14.5) with ESMTP id q9NKdSwq025998; Tue, 23 Oct 2012 23:39:28 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q9NKdSNM025997; Tue, 23 Oct 2012 23:39:28 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 23 Oct 2012 23:39:28 +0300 From: Konstantin Belousov To: Jeremy Chadwick Subject: Re: pty/tty or signal strangeness, or grep/bsdgrep bug? Message-ID: <20121023203928.GZ35915@deviant.kiev.zoral.com.ua> References: <20121023142703.GA79098@icarus.home.lan> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="vF5oyOIHWRbsqp7A" Content-Disposition: inline In-Reply-To: <20121023142703.GA79098@icarus.home.lan> User-Agent: Mutt/1.5.21 (2010-09-15) X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: ed@freebsd.org, freebsd-stable@freebsd.org, jhb@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 23 Oct 2012 20:39:35 -0000 --vF5oyOIHWRbsqp7A Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Oct 23, 2012 at 07:27:03AM -0700, Jeremy Chadwick wrote: > Please keep me CC'd as I'm not subscribed to the list. >=20 > Something "fun" today. First off: yes, I should have been using > 'bsdgrep -r -- "-2011" .', and yes that works fine, but that's besides > the point. Here we go: >=20 > % bsdgrep -r "-2011" . > ^Z > Suspended > % bg > [1] bsdgrep -r -2011 . & > % qqqqqqqqqqq > % > % fg(standard input):qqqqqqqqqfgfg >=20 > bsdgrep -r -2011 . > ^C > % >=20 > Let me explain what transpired from an input perspective: >=20 > 1. Ran bsdgrep -r "-2011" . > 2. Pressed Ctrl-Z > 3. Typed bg > 4. Typed "q" 20 times in a row exactly > 5. Pressed Ctrl-C > 6. Typed "fg" and pressed Enter > 7. Typed "ffgg" and pressed Enter > 8. Pressed Ctrl-Z and Enter > 9. Pressed Ctrl-C >=20 > What's going on here? Where is the famous "Suspended (tty input)"? It > gets more interesting. Here's another one: >=20 > % bsdgrep -r "-2011" . > ^Z > Suspended > % bg > [1] bsdgrep -r -2011 . & > % g(standard input):f > fg > gfg: Command not found. > [1] + Suspended (tty input) bsdgrep -r -2011 . > % jobs > [1] + Suspended (tty input) bsdgrep -r -2011 . > % fg > bsdgrep -r -2011 . > % >=20 > And what transpired input-wise: >=20 > 1. Ran bsdgrep -r "-2011" . > 2. Pressed Ctrl-Z > 3. Typed bg > 4. Typed "fg" and Enter > 5. Typed "fg" again and pressed Enter > 6. Typed "jobs" and pressed Enter > 7. Typed "fg" and pressed Enter > 8. Pressed Ctrl-D >=20 > Some facts: >=20 > - Fully 100% reproducible > - Tested only on RELENG_9 (source from 2012/10/21) > - Happens regardless of shell (bash and csh tested; csh w/out dot files) > - Similar behaviour happens with our base system grep (GNU grep) but > sometimes it manifests itself in a weirder way > - bsdgrep and GNU grep are both in state "ttyin" when this happens >=20 > CC'ing some folks who might have some ideas or can explain how to > troubleshoot this one. For the signal part, I believe this would be > SIGTTIN. This is reproducable with the cat(1) as well. The telling part is that the backgrounded process stays on the "ttyin" cv. The code for e.g. tty read currently is structured as follows: check for background process reading from CTTY, send SIGTTYIN loop { sleep waiting for input process input } The problem is that the SIGCONT does not remove the sleeping process from the sleep queue, so the sleep is not interrupted with error. Instead, the process is woken up later when input is available. Old tty code did the recheck for background state inside the loop after the sleep. Below is the hacky change that seemingly helped for exactly your case. New code is structured so that the fix requires big movements of blocks, e.g. even if keeping my patch, the for (;;) loops in tty_ttydisc.c no longer have any use. Hope Ed will comment. diff --git a/sys/kern/tty.c b/sys/kern/tty.c index e9c0fb6..3785e81 100644 --- a/sys/kern/tty.c +++ b/sys/kern/tty.c @@ -434,6 +434,7 @@ ttydev_read(struct cdev *dev, struct uio *uio, int iofl= ag) if (error) goto done; =20 +check_bg: error =3D tty_wait_background(tp, curthread, SIGTTIN); if (error) { tty_unlock(tp); @@ -441,6 +442,8 @@ ttydev_read(struct cdev *dev, struct uio *uio, int iofl= ag) } =20 error =3D ttydisc_read(tp, uio, ioflag); + if (error =3D=3D EJUSTRETURN) + goto check_bg; tty_unlock(tp); =20 /* @@ -462,6 +465,7 @@ ttydev_write(struct cdev *dev, struct uio *uio, int iof= lag) if (error) return (error); =20 +check_bg: if (tp->t_termios.c_lflag & TOSTOP) { error =3D tty_wait_background(tp, curthread, SIGTTOU); if (error) @@ -484,6 +488,8 @@ ttydev_write(struct cdev *dev, struct uio *uio, int iof= lag) tp->t_flags &=3D ~TF_BUSY_OUT; cv_signal(&tp->t_outserwait); } + if (error =3D=3D EJUSTRETURN) + goto check_bg; =20 done: tty_unlock(tp); return (error); diff --git a/sys/kern/tty_ttydisc.c b/sys/kern/tty_ttydisc.c index 52a5df2..d8b8f53 100644 --- a/sys/kern/tty_ttydisc.c +++ b/sys/kern/tty_ttydisc.c @@ -157,7 +157,7 @@ ttydisc_read_canonical(struct tty *tp, struct uio *uio,= int ioflag) error =3D tty_wait(tp, &tp->t_inwait); if (error) return (error); - continue; + return (EJUSTRETURN); } =20 /* Don't send the EOF char back to userspace. */ @@ -208,6 +208,7 @@ ttydisc_read_raw_no_timer(struct tty *tp, struct uio *u= io, int ioflag) error =3D tty_wait(tp, &tp->t_inwait); if (error) return (error); + return (EJUSTRETURN); } } =20 @@ -256,6 +257,7 @@ ttydisc_read_raw_read_timer(struct tty *tp, struct uio = *uio, int ioflag, error =3D tty_timedwait(tp, &tp->t_inwait, hz); if (error) return (error =3D=3D EWOULDBLOCK ? 0 : error); + return (EJUSTRETURN); } =20 return (0); @@ -301,6 +303,7 @@ ttydisc_read_raw_interbyte_timer(struct tty *tp, struct= uio *uio, int ioflag) error =3D tty_wait(tp, &tp->t_inwait); if (error) return (error); + return (EJUSTRETURN); } =20 return ttydisc_read_raw_read_timer(tp, uio, ioflag, oresid); @@ -539,6 +542,9 @@ ttydisc_write(struct tty *tp, struct uio *uio, int iofl= ag) error =3D EIO; goto done; } + + error =3D EJUSTRETURN; + goto done; } while (oblen > 0); } =20 --vF5oyOIHWRbsqp7A Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAlCHAIAACgkQC3+MBN1Mb4jhPQCg2DoFg/SNC9ztV1XujxdlThpy IK0AoLjFEDVKMpv87BKNDPxrSKHw8jmn =YBtk -----END PGP SIGNATURE----- --vF5oyOIHWRbsqp7A-- From owner-freebsd-stable@FreeBSD.ORG Tue Oct 23 20:42:48 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A7BEDC24; Tue, 23 Oct 2012 20:42:48 +0000 (UTC) (envelope-from edschouten@gmail.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 45E8F8FC0A; Tue, 23 Oct 2012 20:42:47 +0000 (UTC) Received: by mail-ob0-f182.google.com with SMTP id wc20so5283871obb.13 for ; Tue, 23 Oct 2012 13:42:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=RO5XRzZRnmrtBTiqXgVfG3IIYKIgl8uoRrcTnmge4uw=; b=A57sjVZMch9ahI2ECdeWYi8PTSAWBNXvc2g0CMm/NhwdflKoJjkEn1zyQVqJHV6nsX XU9jPytcvuyW1jPzxDQZozjYzjHgTdE1MBb5DyXg5Rw7LcOzcTM1TungSa2QWbizj+P9 xAtpLJQom/RzLSYg4yWmY3UncA0W36KmvSinikemr4w0Wwqb0bC4NLSim6ldpjHzgmo8 83EyNb5h9mBaIDkb3iaseJARUSdHuDAP5t3rREBSTzQwS7wqV+IvTCjHNkDgM8sSgC1Y NPoXlDurvhnyodsuy8Kc6MKvE2QTt+gUJ22B9xRoEvAkeATS+Huk5AtzqJEwNEjgr4ax v2JQ== MIME-Version: 1.0 Received: by 10.182.1.72 with SMTP id 8mr10955898obk.61.1351024967256; Tue, 23 Oct 2012 13:42:47 -0700 (PDT) Sender: edschouten@gmail.com Received: by 10.76.151.39 with HTTP; Tue, 23 Oct 2012 13:42:47 -0700 (PDT) In-Reply-To: <20121023203928.GZ35915@deviant.kiev.zoral.com.ua> References: <20121023142703.GA79098@icarus.home.lan> <20121023203928.GZ35915@deviant.kiev.zoral.com.ua> Date: Tue, 23 Oct 2012 22:42:47 +0200 X-Google-Sender-Auth: Bn8vWRtmRs-cpmQ7qPiQyyStcn4 Message-ID: Subject: Re: pty/tty or signal strangeness, or grep/bsdgrep bug? From: Ed Schouten To: Konstantin Belousov Content-Type: text/plain; charset=UTF-8 Cc: Jeremy Chadwick , freebsd-stable@freebsd.org, jhb@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 23 Oct 2012 20:42:49 -0000 Hi Kostik, 2012/10/23 Konstantin Belousov : > This is reproducable with the cat(1) as well. The telling part is that > the backgrounded process stays on the "ttyin" cv. The code for e.g. > tty read currently is structured as follows: > check for background process reading from CTTY, send SIGTTYIN > loop { > sleep waiting for input > process input > } > The problem is that the SIGCONT does not remove the sleeping process from > the sleep queue, so the sleep is not interrupted with error. Instead, the > process is woken up later when input is available. > > Old tty code did the recheck for background state inside the loop after > the sleep. Exactly. Was just debugging this as well and came to the same conclusion. Will try to come up with a decent patch tomorrow evening. Thanks for reporting the issue! -- Ed Schouten From owner-freebsd-stable@FreeBSD.ORG Tue Oct 23 21:05:45 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 155F03F9; Tue, 23 Oct 2012 21:05:45 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id BE9D08FC17; Tue, 23 Oct 2012 21:05:44 +0000 (UTC) Received: by mail-pb0-f54.google.com with SMTP id rp8so778166pbb.13 for ; Tue, 23 Oct 2012 14:05:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=tWT4Fq7BCZfm61VUKr5tlUQWv1/zpniNF5v1dRKOtTk=; b=faw2CQkBXZtuFtUw9y5dHptJqEcrDUU469UwC34MCUzhUhqIQNq7DdbLuMdYXidij0 muSvpLtRjOBaSW0OhzSCaxUkI2gzx1DdAxRlWfy2yvEL8jdcJthWZR6c7vh59cHEzjsp l5GFcNux+XJV+BFBG5dKvOQjgOGu4JEu77mE5efJpKBb+3qT+oOGpQPdlfiebczX8ClI Ll41PP99ElNUHcrSJ/WJSdd5QkjyJtnrw7Z/v/wd39rKtmG6uT3IyS3Zk3slQYW9t8KA /G52c2tjPnc1CX5f+pe6cttkr8wW3mHbEp2u30V6bbJyfWJez3zTRs9TiwfkzAuKPZxg 2EDw== MIME-Version: 1.0 Received: by 10.66.74.65 with SMTP id r1mr38318525pav.75.1351026344021; Tue, 23 Oct 2012 14:05:44 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.68.146.233 with HTTP; Tue, 23 Oct 2012 14:05:43 -0700 (PDT) In-Reply-To: References: <20121016101957.GB53800@FreeBSD.org> <20121022174457.GB59689@FreeBSD.org> <5086AC06.5070405@a1poweruser.com> Date: Tue, 23 Oct 2012 14:05:43 -0700 X-Google-Sender-Auth: Gr4FTM2HIi-UwRSOKbIwXZW-9tI Message-ID: Subject: Re: FreeBSD in Google Code-In 2012? You can help too! From: Adrian Chadd To: Eitan Adler Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org, Fbsd8 , "Wojciech A. Koszek" , freebsd-stable@freebsd.org, freebsd-current@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 23 Oct 2012 21:05:45 -0000 Right, lots of PHP coding. Attractive to a student. Adrian From owner-freebsd-stable@FreeBSD.ORG Tue Oct 23 21:12:13 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A96EE865 for ; Tue, 23 Oct 2012 21:12:13 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id 366C28FC0A for ; Tue, 23 Oct 2012 21:12:12 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.4/8.14.4/ALCHEMY.FRANKEN.DE) with ESMTP id q9NLC57s021345; Tue, 23 Oct 2012 23:12:05 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.4/8.14.4/Submit) id q9NLC5Q9021344; Tue, 23 Oct 2012 23:12:05 +0200 (CEST) (envelope-from marius) Date: Tue, 23 Oct 2012 23:12:05 +0200 From: Marius Strobl To: Harald Schmalzbauer Subject: Re: msi-x enabled igb works only if module loaded twice [Was: Re: kldload if_igb twice needed to bring nic into operation] Message-ID: <20121023211205.GA21019@alchemy.franken.de> References: <50859F7F.2080308@omnilan.de> <5085A323.8030501@omnilan.de> <50866839.5090204@omnilan.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50866839.5090204@omnilan.de> User-Agent: Mutt/1.4.2.3i Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 23 Oct 2012 21:12:13 -0000 On Tue, Oct 23, 2012 at 11:49:45AM +0200, Harald Schmalzbauer wrote: > schrieb Harald Schmalzbauer am 22.10.2012 21:48 (localtime): > > schrieb Harald Schmalzbauer am 22.10.2012 21:33 (localtime): > >> Hello, > >> > >> when using igb as module, no packet is received. > >> If I send out anything, I see the packet with tcpdump, also the switch > >> learns the MAC address, but nothing comes back in - total silenc, no > >> boradcasts, nothing. > >> If I unload the module and load it again, everything works as expected! > >> No matter if I load it by 4th loader, or later, I always have tio unload > >> first then load it again. > >> I'ts late here, I'll see tomorrow if things change when compieled into > >> kernel. > > It doesn't matter if igb is loaded as module or compiled into kernel. > > >> Maby somebody has an idea what the source of the problem could be. > >> Please find atteched some info, the OS is 9-RC2-amd64 on ESXi5.1 and > >> nics are pci-passthrough. > > I found one possibly relevant difference: > > > > Non-Working state: dev.igb.0.link_irq: 0 > > Working state: dev.igb.0.link_irq: 2 > > This is only true with msi-x!!! > If I disable mis-x, the problem itself vanishes. igb just works fine > from the initial loading (with dev.igb.0.link_irq=0!). > So dev.igb.0.link_irq is only relevant with msi-x. > But what makes me curious is why it also works mith mis-x enabled after > the second kldload!?! Hrm, this is strange; in r231621 (MFC'ed to stable/9 in r232092, so it's part of 9.1-RC2) I've blacklisted the fictitious PCI-PCI bridge VMware uses in case of PCI pass-through for MSI/MSI-X (as in the cases observed it didn't even work with a single MSI-X message). So unless they've changed the ID of the fictitious bridge, igb(4) should fail to allocate a MSI/MSI-X in the first place. Could you please provide the output of `pciconf -lv` on that "system"? Marius From owner-freebsd-stable@FreeBSD.ORG Tue Oct 23 21:26:00 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 53282189 for ; Tue, 23 Oct 2012 21:26:00 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-vb0-f54.google.com (mail-vb0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id F36BD8FC12 for ; Tue, 23 Oct 2012 21:25:59 +0000 (UTC) Received: by mail-vb0-f54.google.com with SMTP id v11so6029784vbm.13 for ; Tue, 23 Oct 2012 14:25:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=TkZ0UHgDMH6a8YtO7+J+w4/jHVikZ63+sf1mVT1qcqM=; b=D7QzV0/ILmx139V5d6oiEv1gHYJqruWldGGrH30aNW0FnyyVO6x7+/5il+7bkCgyx+ 8LH7pJLgEFIgB/twEe6mqRpix9ih/DrTmRkTrcyAPES0hn+7PoBQsGGp1xwYZgBEef6C GnYc/BLYvplwB7gIWvukKxvHG53vaeYKyUsBQIPAuRj8OhcEGIwEz8Dza5rHItVFm5LO yUj0mi+9PTypjqN5LI04CLVTpdd6PfNNenwgesuOilScyvIsTCjq4e5mXbH8GTsDpYjK jL+N6+Fo875WuEPUXFkPczzZPvyLN/ZIvAAAY7BO1o7LxC008Gk7H8mON1AaznlWs0S2 e3Sg== MIME-Version: 1.0 Received: by 10.220.119.196 with SMTP id a4mr4654566vcr.19.1351027558976; Tue, 23 Oct 2012 14:25:58 -0700 (PDT) Received: by 10.58.68.8 with HTTP; Tue, 23 Oct 2012 14:25:58 -0700 (PDT) In-Reply-To: <20121023211205.GA21019@alchemy.franken.de> References: <50859F7F.2080308@omnilan.de> <5085A323.8030501@omnilan.de> <50866839.5090204@omnilan.de> <20121023211205.GA21019@alchemy.franken.de> Date: Tue, 23 Oct 2012 14:25:58 -0700 Message-ID: Subject: Re: msi-x enabled igb works only if module loaded twice [Was: Re: kldload if_igb twice needed to bring nic into operation] From: Jack Vogel To: Marius Strobl Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Harald Schmalzbauer , freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 23 Oct 2012 21:26:00 -0000 LOL, wow this is interesting. When I first was developing the VF support, and using Linux KVM as the host I had exactly this problem, turned out it was because of the way in which MSIX was handled in the Linux side. When my driver would first attempt to get some vectors the Linux code would go look at the vector table, but the way the PCI code in FreeBSD works that table is not set up yet, so Linux would see no legitimate vectors in the table, and decide the guest was ineligible for MSIX :(, but by this time the FreeBSD code actually DID write some vectors into the table, and thus when you load the driver the SECOND time Linux would see the table populated and TADA!! would enable the guest to use MSIX. Now, I went thru a bunch of efforts via our Linux team here to have the KVM code fixed, its design was bogus, and I believe it has been, but it sounds like maybe VMWare has the same broken design?? There is nothing you can do about this because the issue is in the host, not the guest, well getting the host code fixed is the solution :) Hope this helps, Jack On Tue, Oct 23, 2012 at 2:12 PM, Marius Strobl wrote: > On Tue, Oct 23, 2012 at 11:49:45AM +0200, Harald Schmalzbauer wrote: > > schrieb Harald Schmalzbauer am 22.10.2012 21:48 (localtime): > > > schrieb Harald Schmalzbauer am 22.10.2012 21:33 (localtime): > > >> Hello, > > >> > > >> when using igb as module, no packet is received. > > >> If I send out anything, I see the packet with tcpdump, also the > switch > > >> learns the MAC address, but nothing comes back in - total silenc, no > > >> boradcasts, nothing. > > >> If I unload the module and load it again, everything works as > expected! > > >> No matter if I load it by 4th loader, or later, I always have tio > unload > > >> first then load it again. > > >> I'ts late here, I'll see tomorrow if things change when compieled into > > >> kernel. > > > > It doesn't matter if igb is loaded as module or compiled into kernel. > > > > >> Maby somebody has an idea what the source of the problem could be. > > >> Please find atteched some info, the OS is 9-RC2-amd64 on ESXi5.1 and > > >> nics are pci-passthrough. > > > I found one possibly relevant difference: > > > > > > Non-Working state: dev.igb.0.link_irq: 0 > > > Working state: dev.igb.0.link_irq: 2 > > > > This is only true with msi-x!!! > > If I disable mis-x, the problem itself vanishes. igb just works fine > > from the initial loading (with dev.igb.0.link_irq=0!). > > So dev.igb.0.link_irq is only relevant with msi-x. > > But what makes me curious is why it also works mith mis-x enabled after > > the second kldload!?! > > Hrm, this is strange; in r231621 (MFC'ed to stable/9 in r232092, so > it's part of 9.1-RC2) I've blacklisted the fictitious PCI-PCI bridge > VMware uses in case of PCI pass-through for MSI/MSI-X (as in the cases > observed it didn't even work with a single MSI-X message). So unless > they've changed the ID of the fictitious bridge, igb(4) should fail > to allocate a MSI/MSI-X in the first place. Could you please provide > the output of `pciconf -lv` on that "system"? > > Marius > > _______________________________________________ > 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 Tue Oct 23 23:38:24 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C9262996; Tue, 23 Oct 2012 23:38:24 +0000 (UTC) (envelope-from bofh@terranova.net) Received: from tog.net (tog.net [IPv6:2605:5a00::5]) by mx1.freebsd.org (Postfix) with ESMTP id 8397A8FC08; Tue, 23 Oct 2012 23:38:24 +0000 (UTC) Received: from [IPv6:2605:5a00:ffff::face] (unknown [IPv6:2605:5a00:ffff::face]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tog.net (Postfix) with ESMTPSA id 3XmWHz3bwnzKPT; Tue, 23 Oct 2012 19:38:23 -0400 (EDT) Message-ID: <50872A68.5040100@terranova.net> Date: Tue, 23 Oct 2012 19:38:16 -0400 From: Travis Mikalson Organization: TerraNovaNet Internet Services User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Andriy Gapon Subject: Re: The shutdown bug? References: <5086CD71.7020006@intersonic.se> <5086E43D.1010702@intersonic.se> <5086F39E.7050708@FreeBSD.org> In-Reply-To: <5086F39E.7050708@FreeBSD.org> X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.terranova.net/pgp/bofh Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: jb , freebsd-stable@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 23 Oct 2012 23:38:24 -0000 Andriy Gapon wrote: > on 23/10/2012 21:38 Per olof Ljungmark said the following: >> On 2012-10-23 19:41, jb wrote: >>> Per olof Ljungmark intersonic.se> writes: >>> >>>> ... >>>> Setting sysctl hw.usb.no_shutdown_wait=1 does NOT fix the problem as >>>> described in >>>> http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/167685 >>>> ... >>> There is another one: >>> http://www.freebsd.org/cgi/query-pr.cgi?pr=172952&cat= >>> jb >> Thanks, I'll add my experiences to that one. > > I've just posted another followup to that PR. If you could do some debugging > that would be great. Thank you for the followup, I will respond later when I am able. I will have to build DDB into my kernel and see what I can find out about where it's stuck. I also intend to remove the SAS controllers and disable USB and various things I can do to see if it stops being 100% reproducible on this particular system. I just patched in the following as a MFC and this also did not affect this issue: http://svnweb.freebsd.org/base/head/sys/geom/geom_disk.c?r1=240629&r2=241022&view=patch That is 240822 and 241022 combined: http://svnweb.freebsd.org/base/head/sys/geom/geom_disk.c?r1=240629&view=log From owner-freebsd-stable@FreeBSD.ORG Wed Oct 24 02:40:29 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B81A780B for ; Wed, 24 Oct 2012 02:40:29 +0000 (UTC) (envelope-from jdc@koitsu.strangled.net) Received: from qmta13.emeryville.ca.mail.comcast.net (qmta13.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:44:76:96:27:243]) by mx1.freebsd.org (Postfix) with ESMTP id 84B428FC14 for ; Wed, 24 Oct 2012 02:40:29 +0000 (UTC) Received: from omta14.emeryville.ca.mail.comcast.net ([76.96.30.60]) by qmta13.emeryville.ca.mail.comcast.net with comcast id Epvk1k0051HpZEsADqgV9r; Wed, 24 Oct 2012 02:40:29 +0000 Received: from koitsu.strangled.net ([67.180.84.87]) by omta14.emeryville.ca.mail.comcast.net with comcast id EqgU1k00F1t3BNj8aqgUud; Wed, 24 Oct 2012 02:40:29 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 15E9673A1A; Tue, 23 Oct 2012 19:40:28 -0700 (PDT) Date: Tue, 23 Oct 2012 19:40:28 -0700 From: Jeremy Chadwick To: Ed Schouten Subject: Re: pty/tty or signal strangeness, or grep/bsdgrep bug? Message-ID: <20121024024028.GA90747@icarus.home.lan> References: <20121023142703.GA79098@icarus.home.lan> <20121023203928.GZ35915@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Konstantin Belousov , freebsd-stable@freebsd.org, jhb@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 24 Oct 2012 02:40:30 -0000 On Tue, Oct 23, 2012 at 10:42:47PM +0200, Ed Schouten wrote: > Hi Kostik, > > 2012/10/23 Konstantin Belousov : > > This is reproducable with the cat(1) as well. The telling part is that > > the backgrounded process stays on the "ttyin" cv. The code for e.g. > > tty read currently is structured as follows: > > check for background process reading from CTTY, send SIGTTYIN > > loop { > > sleep waiting for input > > process input > > } > > The problem is that the SIGCONT does not remove the sleeping process from > > the sleep queue, so the sleep is not interrupted with error. Instead, the > > process is woken up later when input is available. > > > > Old tty code did the recheck for background state inside the loop after > > the sleep. > > Exactly. Was just debugging this as well and came to the same > conclusion. Will try to come up with a decent patch tomorrow evening. > > Thanks for reporting the issue! No problem folks. Would you like me to file a PR for this so we can track it/for historical purposes? -- | Jeremy Chadwick jdc@koitsu.org | | UNIX Systems Administrator http://jdc.koitsu.org/ | | Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Wed Oct 24 03:08:28 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 83746E1C for ; Wed, 24 Oct 2012 03:08:28 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: from mail-pa0-f54.google.com (mail-pa0-f54.google.com [209.85.220.54]) by mx1.freebsd.org (Postfix) with ESMTP id 4AD6B8FC0A for ; Wed, 24 Oct 2012 03:08:28 +0000 (UTC) Received: by mail-pa0-f54.google.com with SMTP id bi1so52309pad.13 for ; Tue, 23 Oct 2012 20:08:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=AlvuWzy9oBMsWYAiuGPx7j6uIyy3MA2qAss5vfNhk7c=; b=n7sqQQT1L1QKRrJb94a0W/MI9Uv9I+damHkTsUTaLO8TGsdbwyaFKhJ0uHKBweNbj7 OqLymGdAtBoXV/m9PtBmeZ74M66QZaBHzJKz8MANFzGFxs/fZVzkXQ+YA5VzTCyyDBgw 1t5C42DF7PB1A/VIhLvI/05OVwQXDR84XV4sM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=AlvuWzy9oBMsWYAiuGPx7j6uIyy3MA2qAss5vfNhk7c=; b=HB1f9aJsCFvZuLzh8bg2w4AW2grXp+9gV2ilv63QPJ9vbHAx+Da1wIspMGQrC/FogA vmIieo5QeFLUoIzD0WkfePs+mFvQuyAPaBsG/Mhsczj3wSFVtSi+wiFZrApSmpTQQYpQ HrsdPUHfgSRMVf1tIEhxRmQw4q7adRypV/q+UJCp3tM0hT61ZaCy8DSnJ9vKLJDASjoZ NmUo952L5ErCUuwx/nnXMnUden8WGFuxzRAuMDtSDJnbLYaPRpI29yjrUwN98W2evOCy Vwbw4k2ewVLAwH11hzGEkqv7PRjEyWYjmr2ifaPUhIRqKiryTD8lBxO/1He6Ecxps1JT e1qg== Received: by 10.66.76.231 with SMTP id n7mr40393828paw.68.1351048107728; Tue, 23 Oct 2012 20:08:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.161.163 with HTTP; Tue, 23 Oct 2012 20:07:56 -0700 (PDT) In-Reply-To: <20121024024028.GA90747@icarus.home.lan> References: <20121023142703.GA79098@icarus.home.lan> <20121023203928.GZ35915@deviant.kiev.zoral.com.ua> <20121024024028.GA90747@icarus.home.lan> From: Eitan Adler Date: Tue, 23 Oct 2012 23:07:56 -0400 Message-ID: Subject: Re: pty/tty or signal strangeness, or grep/bsdgrep bug? To: Jeremy Chadwick Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQnfnAZz152UOtFfjqPjjwl97bsHQAtRu9dygSK6fBkbBCdboQuZGhhTXbhs0z4/zOsGAlJi Cc: Konstantin Belousov , Ed Schouten , freebsd-stable@freebsd.org, jhb@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 24 Oct 2012 03:08:28 -0000 On 23 October 2012 22:40, Jeremy Chadwick wrote: > No problem folks. Would you like me to file a PR for this so we can > track it/for historical purposes? yes please -- Eitan Adler From owner-freebsd-stable@FreeBSD.ORG Wed Oct 24 03:13:57 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 09253F9E for ; Wed, 24 Oct 2012 03:13:57 +0000 (UTC) (envelope-from jdc@koitsu.strangled.net) Received: from qmta09.emeryville.ca.mail.comcast.net (qmta09.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:96]) by mx1.freebsd.org (Postfix) with ESMTP id D97BB8FC12 for ; Wed, 24 Oct 2012 03:13:56 +0000 (UTC) Received: from omta07.emeryville.ca.mail.comcast.net ([76.96.30.59]) by qmta09.emeryville.ca.mail.comcast.net with comcast id Eqt31k0031GXsucA9rDwKc; Wed, 24 Oct 2012 03:13:56 +0000 Received: from koitsu.strangled.net ([67.180.84.87]) by omta07.emeryville.ca.mail.comcast.net with comcast id ErDv1k00U1t3BNj8UrDwCc; Wed, 24 Oct 2012 03:13:56 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id AD62F73A1A; Tue, 23 Oct 2012 20:13:55 -0700 (PDT) Date: Tue, 23 Oct 2012 20:13:55 -0700 From: Jeremy Chadwick To: Eitan Adler Subject: Re: pty/tty or signal strangeness, or grep/bsdgrep bug? Message-ID: <20121024031355.GA91326@icarus.home.lan> References: <20121023142703.GA79098@icarus.home.lan> <20121023203928.GZ35915@deviant.kiev.zoral.com.ua> <20121024024028.GA90747@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Konstantin Belousov , Ed Schouten , freebsd-stable@freebsd.org, jhb@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 24 Oct 2012 03:13:57 -0000 On Tue, Oct 23, 2012 at 11:07:56PM -0400, Eitan Adler wrote: > On 23 October 2012 22:40, Jeremy Chadwick wrote: > > > No problem folks. Would you like me to file a PR for this so we can > > track it/for historical purposes? > > yes please Thanks Eitan -- will do! -- | Jeremy Chadwick jdc@koitsu.org | | UNIX Systems Administrator http://jdc.koitsu.org/ | | Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Wed Oct 24 03:53:19 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CCB1148E for ; Wed, 24 Oct 2012 03:53:19 +0000 (UTC) (envelope-from jdc@koitsu.strangled.net) Received: from qmta04.emeryville.ca.mail.comcast.net (qmta04.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:40]) by mx1.freebsd.org (Postfix) with ESMTP id A9DB58FC12 for ; Wed, 24 Oct 2012 03:53:19 +0000 (UTC) Received: from omta15.emeryville.ca.mail.comcast.net ([76.96.30.71]) by qmta04.emeryville.ca.mail.comcast.net with comcast id Eri81k0011Y3wxoA4rtKyF; Wed, 24 Oct 2012 03:53:19 +0000 Received: from koitsu.strangled.net ([67.180.84.87]) by omta15.emeryville.ca.mail.comcast.net with comcast id ErtJ1k00H1t3BNj8brtJvq; Wed, 24 Oct 2012 03:53:19 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 7870E73A1A; Tue, 23 Oct 2012 20:53:18 -0700 (PDT) Date: Tue, 23 Oct 2012 20:53:18 -0700 From: Jeremy Chadwick To: Eitan Adler Subject: Re: pty/tty or signal strangeness, or grep/bsdgrep bug? Message-ID: <20121024035318.GA92037@icarus.home.lan> References: <20121023142703.GA79098@icarus.home.lan> <20121023203928.GZ35915@deviant.kiev.zoral.com.ua> <20121024024028.GA90747@icarus.home.lan> <20121024031355.GA91326@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20121024031355.GA91326@icarus.home.lan> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Konstantin Belousov , Ed Schouten , freebsd-stable@freebsd.org, jhb@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 24 Oct 2012 03:53:19 -0000 On Tue, Oct 23, 2012 at 08:13:55PM -0700, Jeremy Chadwick wrote: > On Tue, Oct 23, 2012 at 11:07:56PM -0400, Eitan Adler wrote: > > On 23 October 2012 22:40, Jeremy Chadwick wrote: > > > > > No problem folks. Would you like me to file a PR for this so we can > > > track it/for historical purposes? > > > > yes please > > Thanks Eitan -- will do! kern/173010 -- | Jeremy Chadwick jdc@koitsu.org | | UNIX Systems Administrator http://jdc.koitsu.org/ | | Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Wed Oct 24 04:03:09 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5D551643; Wed, 24 Oct 2012 04:03:09 +0000 (UTC) (envelope-from wkoszek@freebsd.czest.pl) Received: from freebsd.czest.pl (freebsd.czest.pl [212.87.224.105]) by mx1.freebsd.org (Postfix) with ESMTP id CCC098FC14; Wed, 24 Oct 2012 04:03:08 +0000 (UTC) Received: from wkoszek-thinkpad-t410 (freebsd.czest.pl [212.87.224.105]) by freebsd.czest.pl (8.14.5/8.14.5) with ESMTP id q9O3qn1g072406; Wed, 24 Oct 2012 03:52:50 GMT (envelope-from wkoszek@freebsd.czest.pl) Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: "Eitan Adler" , "Adrian Chadd" Subject: Re: FreeBSD in Google Code-In 2012? You can help too! References: <20121016101957.GB53800@FreeBSD.org> <20121022174457.GB59689@FreeBSD.org> <5086AC06.5070405@a1poweruser.com> Date: Tue, 23 Oct 2012 21:02:50 -0700 MIME-Version: 1.0 Content-Transfer-Encoding: Quoted-Printable From: "Wojciech A. Koszek" Organization: FreeBSD.czest.pl Message-ID: In-Reply-To: User-Agent: Opera Mail/12.10 (Linux) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (freebsd.czest.pl [127.0.0.2]); Wed, 24 Oct 2012 03:52:53 +0000 (UTC) Cc: freebsd-hackers@freebsd.org, Fbsd8 , "Wojciech A. Koszek" , freebsd-stable@freebsd.org, freebsd-current@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 24 Oct 2012 04:03:09 -0000 Dnia 23-10-2012 o 14:05:43 Adrian Chadd napisa=C5=82= (a): > Right, lots of PHP coding. Attractive to a student. > Nobody prevents students from serving FreeBSD by writing stuff in attrac= tive, well documented (books, translations) technologies. We just need t= o craft a task list around things which people consider attractive. -- = Wojciech A. Koszek wkoszek@freebsd.czest.pl http://FreeBSD.czest.pl/~wkoszek/ From owner-freebsd-stable@FreeBSD.ORG Wed Oct 24 07:50:02 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D171BA72 for ; Wed, 24 Oct 2012 07:50:02 +0000 (UTC) (envelope-from h.schmalzbauer@omnilan.de) Received: from host.omnilan.net (s1.omnilan.net [62.245.232.135]) by mx1.freebsd.org (Postfix) with ESMTP id 51BB08FC12 for ; Wed, 24 Oct 2012 07:50:01 +0000 (UTC) Received: from titan.inop.wdn.omnilan.net (titan.inop.wdn.omnilan.net [172.21.3.1]) (authenticated bits=0) by host.omnilan.net (8.13.8/8.13.8) with ESMTP id q9O7pCNV063902 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 24 Oct 2012 09:51:16 +0200 (CEST) (envelope-from h.schmalzbauer@omnilan.de) Message-ID: <50879D98.40006@omnilan.de> Date: Wed, 24 Oct 2012 09:49:44 +0200 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Jack Vogel Subject: Re: msi-x enabled igb works only if module loaded twice [Was: Re: kldload if_igb twice needed to bring nic into operation] References: <50859F7F.2080308@omnilan.de> <5085A323.8030501@omnilan.de> <50866839.5090204@omnilan.de> <20121023211205.GA21019@alchemy.franken.de> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig494CE36577E2065D27EAD157" Cc: FreeBSD Stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 24 Oct 2012 07:50:03 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig494CE36577E2065D27EAD157 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable schrieb Jack Vogel am 23.10.2012 23:25 (localtime): > LOL, wow this is interesting. When I first was developing the VF suppor= t, Well, in fact I choose 'kawela' (82576) because I originally wanted to use VFs. But I can't get SR-IOV working with ESXi5.1. I'm using async-drivers, and I have option "max_vfs" available and enabled, also at boot time ESXi detects SR-IOV: cpu0:4096)PCI: 5327: 00:02:00.0: Found Single Root I/O Virtualization support But later on, I get this error: cpu0:4573)<6>igb: : igb_validate_option: max_vfs - SR-IOV VF devices set to 4 cpu0:4573)<4>igb 0000:02:00.0: Failed to initialize SR-IOV virtualization Since I have no VMware support contract and found absoluetly no documentation, I gave up and plugged in a second kawela for passing through into my iSCSI-target-guest. I found some hints that SR-IOV needs additional BIOS features besides VT-x and VT-d, because SR-IOV cards need to allocate additional address space. But that's beyond my PCI knowledge, and my BearTooth board doesn't have such SR-IOV switches, so I'm trying to forget that I've ever heard of SR-IOV :-( Btw, are there plans to support IPSec offload for kawela? =2E.. > There is nothing you can do about this because the issue is in the host= , > not the guest, > well getting the host code fixed is the solution :) > > Hope this helps, Thanks a lot, VMware has to fix more passthrough issues, since 5.1 crashes easily with passthrough-setups and many people report PODs (pink screen of death; I've first seen that with 5.1) But unfortunately there's no way for me to get in contact with VMWare to raise this MSI-X-passthrough topic. This would porbably also fix the mps-msix-problems, but disabling MSI-X for mps doesn't cost that much interrupts. With igb I see 25k irq/s difference between MSI and MSI-X. I don't understand why, but it's too expensive for my single-socket system.= Thanks a lot, -Harry --------------enig494CE36577E2065D27EAD157 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAlCHnZ4ACgkQLDqVQ9VXb8i0/gCffArtvym6VL2JDh1Qey5yLQ9u PggAoKe6Z+WqXaAydtPL7m3/AC9Olm1R =llqr -----END PGP SIGNATURE----- --------------enig494CE36577E2065D27EAD157-- From owner-freebsd-stable@FreeBSD.ORG Wed Oct 24 07:57:26 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 19D74C58 for ; Wed, 24 Oct 2012 07:57:26 +0000 (UTC) (envelope-from c.kworr@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id DBD058FC0C for ; Wed, 24 Oct 2012 07:57:25 +0000 (UTC) Received: by mail-pb0-f54.google.com with SMTP id rp8so1107859pbb.13 for ; Wed, 24 Oct 2012 00:57:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=Ud+IX1ens0nRSH6+yns0QDMmgSlFplsh1O3ldVLjHnI=; b=bEn7jHJT9C1AAm3wdVQOjtj4Fw6OLZnfn/PmdJBy2AP82WL5ICOmehRqMN/NOrTcNS 8IPa28rK74SFQ908//lxHnhCP6TAQ6KFhOiPcPVy9qmOcVscDHWmCOPD+6z+j1rt2W2y 0Wex9ke4koYUHAY9dkjMkVDIj/iN7rhN/e9n+27AxC3f4rbHoa9UzZbIljs8AiUmqXL5 vhWE+spwtoaq0DyY1RP1MI4uj2ur3t9fHYBvFKd7eX9JOANWzqDnvtSwesC3Akc9Qx5k a4KHFofecR2x4vC+Rx2SId0EjjgNOQ1WQJJyR3/bfires2dH++tp7IiXWdMHlY9UFwck rsDQ== Received: by 10.68.209.170 with SMTP id mn10mr48038815pbc.11.1351065445708; Wed, 24 Oct 2012 00:57:25 -0700 (PDT) Received: from [192.168.1.131] (mau.donbass.com. [92.242.127.250]) by mx.google.com with ESMTPS id nt7sm9074771pbb.33.2012.10.24.00.57.24 (version=SSLv3 cipher=OTHER); Wed, 24 Oct 2012 00:57:25 -0700 (PDT) Message-ID: <50879F62.2010004@gmail.com> Date: Wed, 24 Oct 2012 10:57:22 +0300 From: Volodymyr Kostyrko User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:16.0) Gecko/20121015 Thunderbird/16.0.1 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: wine, gcc and clang with CPUTYPE Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 24 Oct 2012 07:57:26 -0000 Hi all. I just have taken some time to inspect CPUTYPE support for clang. It seems to me that clang generates incorrect code in some cases. The first failure point I discovered was inability to build gcc from sources or compile something with gcc. Code produced by gcc seem to fail whether this was gcc compiled from bootstrap or anything else: http://lists.freebsd.org/pipermail/freebsd-multimedia/2012-October/013469.html I started testing by commenting out CPUTYPE in make.conf. After first rebuild I also updated the ports and installed new version of wine-devel. And to my surprise it works like a charm. Rolling back to the world built with CPUTYPE=native makes wine break again. To my surprise CPUTYPE was not the cause of wine failure per se. Wine continues to work for k6, k6-3, athlon and athlon-tbird. But it completely fails when the world was built with athlon-4 and athlon-xp. Trying to recompile gcc I also found that everything works and yet again up to the athlon-tbird. My conclusion is: clang incorrectly produces code within one of core libraries (I haven't tested which one yet, but I suspect libgcc_s.so) when optimizing for athlon-4 or athlon-xp. -- Sphinx of black quartz, judge my vow. From owner-freebsd-stable@FreeBSD.ORG Wed Oct 24 08:12:42 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3F5611DA for ; Wed, 24 Oct 2012 08:12:42 +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 9316F8FC08 for ; Wed, 24 Oct 2012 08:12:39 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q9O8Ci4P046370; Wed, 24 Oct 2012 11:12:44 +0300 (EEST) (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.5/8.14.5) with ESMTP id q9O8CWsD030034; Wed, 24 Oct 2012 11:12:32 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q9O8CWio030033; Wed, 24 Oct 2012 11:12:32 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 24 Oct 2012 11:12:32 +0300 From: Konstantin Belousov To: Volodymyr Kostyrko Subject: Re: wine, gcc and clang with CPUTYPE Message-ID: <20121024081232.GA35915@deviant.kiev.zoral.com.ua> References: <50879F62.2010004@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="OgaV/uj8Af8zlSb7" Content-Disposition: inline In-Reply-To: <50879F62.2010004@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 24 Oct 2012 08:12:42 -0000 --OgaV/uj8Af8zlSb7 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Oct 24, 2012 at 10:57:22AM +0300, Volodymyr Kostyrko wrote: > Hi all. >=20 > I just have taken some time to inspect CPUTYPE support for clang. It=20 > seems to me that clang generates incorrect code in some cases. >=20 > The first failure point I discovered was inability to build gcc from=20 > sources or compile something with gcc. Code produced by gcc seem to fail= =20 > whether this was gcc compiled from bootstrap or anything else: >=20 > http://lists.freebsd.org/pipermail/freebsd-multimedia/2012-October/013469= =2Ehtml >=20 > I started testing by commenting out CPUTYPE in make.conf. After first=20 > rebuild I also updated the ports and installed new version of=20 > wine-devel. And to my surprise it works like a charm. Rolling back to=20 > the world built with CPUTYPE=3Dnative makes wine break again. >=20 > To my surprise CPUTYPE was not the cause of wine failure per se. Wine=20 > continues to work for k6, k6-3, athlon and athlon-tbird. But it=20 > completely fails when the world was built with athlon-4 and athlon-xp. >=20 > Trying to recompile gcc I also found that everything works and yet again= =20 > up to the athlon-tbird. >=20 > My conclusion is: clang incorrectly produces code within one of core=20 > libraries (I haven't tested which one yet, but I suspect libgcc_s.so)=20 > when optimizing for athlon-4 or athlon-xp. I am not versed in the AMD marketing monikers. I guess that athlon-{4,xp} turns on SSE and might be SSE2, while previous selections turn it off. Can you confirm/deny this ? BTW, did you tested on i386 or amd64 ? --OgaV/uj8Af8zlSb7 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAlCHovAACgkQC3+MBN1Mb4hpBwCgmay2k/V/xNJeenBdNbV7mAlC pa8An2MqI9+nk1HAbKaTFr3ni/twtcDm =DfKs -----END PGP SIGNATURE----- --OgaV/uj8Af8zlSb7-- From owner-freebsd-stable@FreeBSD.ORG Wed Oct 24 08:39:57 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 76315565 for ; Wed, 24 Oct 2012 08:39:57 +0000 (UTC) (envelope-from c.kworr@gmail.com) Received: from mail-pa0-f54.google.com (mail-pa0-f54.google.com [209.85.220.54]) by mx1.freebsd.org (Postfix) with ESMTP id 422AC8FC14 for ; Wed, 24 Oct 2012 08:39:56 +0000 (UTC) Received: by mail-pa0-f54.google.com with SMTP id bi1so223745pad.13 for ; Wed, 24 Oct 2012 01:39:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=4nPTquNP0eU2peJT+MPs0A2cID2P7sqh+6Ly5sD4xlM=; b=CUk/2hp0cSIrfk7kbnvSlFCwUhRVCOrnPGnsRVFa8Y/Lsx+kThINBTMm7akRjWc0lh OeCMZQv4l05eezhP1xyLWFUSpwJ3JmRGczf9uUTvsANFKwQ90wS6qqyi30enCCmEyfZY 670B8EOSkVNQ+0KkorTUkloERlx+LiXNM6n8s3f1eKWh1WVkWg+jN2wnUBCXpSWpeKqR BYKfHwVeB+/qpTssI/E8pvO2jZ0iwKbXYqwq2a/f6eLNOXHXzSQzP32xDObRnQqj7htd k7suY+AAxPamDvbV35hS1d0wuh6QnoSRPnmoOp0xBTxnJl84AYCm+Y0dctlH+DSGwbEW NzrA== Received: by 10.66.78.104 with SMTP id a8mr42217948pax.38.1351067989964; Wed, 24 Oct 2012 01:39:49 -0700 (PDT) Received: from [192.168.1.131] (mau.donbass.com. [92.242.127.250]) by mx.google.com with ESMTPS id v9sm9170504paz.6.2012.10.24.01.39.48 (version=SSLv3 cipher=OTHER); Wed, 24 Oct 2012 01:39:49 -0700 (PDT) Message-ID: <5087A952.2090608@gmail.com> Date: Wed, 24 Oct 2012 11:39:46 +0300 From: Volodymyr Kostyrko User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:16.0) Gecko/20121015 Thunderbird/16.0.1 MIME-Version: 1.0 To: Konstantin Belousov Subject: Re: wine, gcc and clang with CPUTYPE References: <50879F62.2010004@gmail.com> <20121024081232.GA35915@deviant.kiev.zoral.com.ua> In-Reply-To: <20121024081232.GA35915@deviant.kiev.zoral.com.ua> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 24 Oct 2012 08:39:57 -0000 24.10.2012 11:12, Konstantin Belousov wrote: >> My conclusion is: clang incorrectly produces code within one of core >> libraries (I haven't tested which one yet, but I suspect libgcc_s.so) >> when optimizing for athlon-4 or athlon-xp. > > I am not versed in the AMD marketing monikers. I guess that athlon-{4,xp} > turns on SSE and might be SSE2, while previous selections turn it off. > Can you confirm/deny this ? As http://en.wikipedia.org/wiki/Athlon states athlon-xp was first to include SSE support. I don't know whether athlon-xp actually differs from athlon-4. None of them include SSE2 support. > BTW, did you tested on i386 or amd64 ? i386 -- Sphinx of black quartz, judge my vow. From owner-freebsd-stable@FreeBSD.ORG Wed Oct 24 10:05:40 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0F4EDD1F for ; Wed, 24 Oct 2012 10:05:40 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) by mx1.freebsd.org (Postfix) with ESMTP id BB1D28FC16 for ; Wed, 24 Oct 2012 10:05:39 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:b489:24:8697:7e27] (unknown [IPv6:2001:7b8:3a7:0:b489:24:8697:7e27]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id EFD625C59; Wed, 24 Oct 2012 12:05:37 +0200 (CEST) Message-ID: <5087BD71.9090002@FreeBSD.org> Date: Wed, 24 Oct 2012 12:05:37 +0200 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Volodymyr Kostyrko Subject: Re: wine, gcc and clang with CPUTYPE References: <50879F62.2010004@gmail.com> In-Reply-To: <50879F62.2010004@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 24 Oct 2012 10:05:40 -0000 On 2012-10-24 09:57, Volodymyr Kostyrko wrote: > I just have taken some time to inspect CPUTYPE support for clang. It > seems to me that clang generates incorrect code in some cases. > > The first failure point I discovered was inability to build gcc from > sources or compile something with gcc. Code produced by gcc seem to fail > whether this was gcc compiled from bootstrap or anything else: > > http://lists.freebsd.org/pipermail/freebsd-multimedia/2012-October/013469.html Can you attempt to figure out what the illegal instruction was, in that case? > I started testing by commenting out CPUTYPE in make.conf. After first > rebuild I also updated the ports and installed new version of > wine-devel. And to my surprise it works like a charm. Rolling back to > the world built with CPUTYPE=native makes wine break again. > > To my surprise CPUTYPE was not the cause of wine failure per se. Wine > continues to work for k6, k6-3, athlon and athlon-tbird. But it > completely fails when the world was built with athlon-4 and athlon-xp. > > Trying to recompile gcc I also found that everything works and yet again > up to the athlon-tbird. > > My conclusion is: clang incorrectly produces code within one of core > libraries (I haven't tested which one yet, but I suspect libgcc_s.so) > when optimizing for athlon-4 or athlon-xp. On the problematic athlons, can you please post the exact CPUIDs from dmesg? If you have WITH_CLANG_EXTRAS enabled, please also post the output of "opt -version". From owner-freebsd-stable@FreeBSD.ORG Wed Oct 24 10:34:20 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9ADC85DD; Wed, 24 Oct 2012 10:34:20 +0000 (UTC) (envelope-from c.kworr@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 635E08FC0C; Wed, 24 Oct 2012 10:34:20 +0000 (UTC) Received: by mail-pb0-f54.google.com with SMTP id rp8so1196159pbb.13 for ; Wed, 24 Oct 2012 03:34:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=ekMsCL+codhhVE0DfD4eEfoWLo7KmxMrSPF2K76R7B0=; b=vdBYzvOp45t3f8bkbFWMuhrtoTMUvlLEVbmp28Vh5Aa2ZGQQtpWwpySrMSFWqHmbLi 1TlpozSvq9JMsSq8uzUbLSGXsE4GOVh4dSf/Ex5C/h3ySaZYfHe+PikqryGRYKS/PRu3 Z37YHRLPwd5ZsKVkcP3teP9fhWnsSNTXSrhvUhcqQMxDhFa4+GG+1kZ7SUqJT67StXej nElSAtIGh70u35RwAXTSOLdjzEzXIkdDgH8egqobiBkoDMS4EpMl8gayR7EcePVa3yzD 9eFvFsS8XnAkcxPoyoyHA/R98GItSTasbZC5x8TGN6RIlyLzWA/qhPjRN8nE8NocCVHf BHMg== Received: by 10.68.220.42 with SMTP id pt10mr49117474pbc.84.1351074860174; Wed, 24 Oct 2012 03:34:20 -0700 (PDT) Received: from [192.168.1.131] (mau.donbass.com. [92.242.127.250]) by mx.google.com with ESMTPS id ix9sm9268349pbc.7.2012.10.24.03.34.18 (version=SSLv3 cipher=OTHER); Wed, 24 Oct 2012 03:34:19 -0700 (PDT) Message-ID: <5087C428.2020908@gmail.com> Date: Wed, 24 Oct 2012 13:34:16 +0300 From: Volodymyr Kostyrko User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:16.0) Gecko/20121015 Thunderbird/16.0.1 MIME-Version: 1.0 To: Dimitry Andric Subject: Re: wine, gcc and clang with CPUTYPE References: <50879F62.2010004@gmail.com> <5087BD71.9090002@FreeBSD.org> In-Reply-To: <5087BD71.9090002@FreeBSD.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 24 Oct 2012 10:34:20 -0000 24.10.2012 13:05, Dimitry Andric wrote: >> I just have taken some time to inspect CPUTYPE support for clang. It >> seems to me that clang generates incorrect code in some cases. >> >> The first failure point I discovered was inability to build gcc from >> sources or compile something with gcc. Code produced by gcc seem to fail >> whether this was gcc compiled from bootstrap or anything else: >> >> http://lists.freebsd.org/pipermail/freebsd-multimedia/2012-October/013469.html > > Can you attempt to figure out what the illegal instruction was, in that > case? How can I do that? I'm not very familiar with gdb. >> I started testing by commenting out CPUTYPE in make.conf. After first >> rebuild I also updated the ports and installed new version of >> wine-devel. And to my surprise it works like a charm. Rolling back to >> the world built with CPUTYPE=native makes wine break again. >> >> To my surprise CPUTYPE was not the cause of wine failure per se. Wine >> continues to work for k6, k6-3, athlon and athlon-tbird. But it >> completely fails when the world was built with athlon-4 and athlon-xp. >> >> Trying to recompile gcc I also found that everything works and yet again >> up to the athlon-tbird. >> >> My conclusion is: clang incorrectly produces code within one of core >> libraries (I haven't tested which one yet, but I suspect libgcc_s.so) >> when optimizing for athlon-4 or athlon-xp. > > On the problematic athlons, can you please post the exact CPUIDs from > dmesg? If you have WITH_CLANG_EXTRAS enabled, please also post the > output of "opt -version". Oct 24 01:47:20 limbo kernel: CPU: AMD Athlon(tm) XP 2500+ (1833.95-MHz 686-class CPU) Oct 24 01:47:20 limbo kernel: Origin = "AuthenticAMD" Id = 0x6a0 Family = 0x6 Model = 0xa Stepping = 0 Oct 24 01:47:20 limbo kernel: Features=0x383fbff Oct 24 01:47:20 limbo kernel: AMD Features=0xc0400800 I will rebuild WITH_CLANG_EXTRAS. -- Sphinx of black quartz, judge my vow. From owner-freebsd-stable@FreeBSD.ORG Wed Oct 24 11:00:36 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 66E21D28 for ; Wed, 24 Oct 2012 11:00:36 +0000 (UTC) (envelope-from h.schmalzbauer@omnilan.de) Received: from host.omnilan.net (s1.omnilan.net [62.245.232.135]) by mx1.freebsd.org (Postfix) with ESMTP id AE6D88FC16 for ; Wed, 24 Oct 2012 11:00:35 +0000 (UTC) Received: from titan.inop.wdn.omnilan.net (titan.inop.wdn.omnilan.net [172.21.3.1]) (authenticated bits=0) by host.omnilan.net (8.13.8/8.13.8) with ESMTP id q9OB1tkR067256 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 24 Oct 2012 13:01:56 +0200 (CEST) (envelope-from h.schmalzbauer@omnilan.de) Message-ID: <5087CA50.6090102@omnilan.de> Date: Wed, 24 Oct 2012 13:00:32 +0200 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Marius Strobl Subject: Re: msi-x enabled igb works only if module loaded twice [Was: Re: kldload if_igb twice needed to bring nic into operation] References: <50859F7F.2080308@omnilan.de> <5085A323.8030501@omnilan.de> <50866839.5090204@omnilan.de> <20121023211205.GA21019@alchemy.franken.de> In-Reply-To: <20121023211205.GA21019@alchemy.franken.de> X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigB0B54448E64B4896BB34B3BC" Cc: FreeBSD Stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 24 Oct 2012 11:00:36 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigB0B54448E64B4896BB34B3BC Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable schrieb Marius Strobl am 23.10.2012 23:12 (localtime): > On Tue, Oct 23, 2012 at 11:49:45AM +0200, Harald Schmalzbauer wrote: >> schrieb Harald Schmalzbauer am 22.10.2012 21:48 (localtime): >>> schrieb Harald Schmalzbauer am 22.10.2012 21:33 (localtime): >>>> Hello, >>>> >>>> when using igb as module, no packet is received. >>>> If I send out anything, I see the packet with tcpdump, also the swi= tch >>>> learns the MAC address, but nothing comes back in - total silenc, no= >>>> boradcasts, nothing. >>>> If I unload the module and load it again, everything works as expect= ed! >>>> No matter if I load it by 4th loader, or later, I always have tio un= load >>>> first then load it again. >>>> I'ts late here, I'll see tomorrow if things change when compieled in= to >>>> kernel. >> It doesn't matter if igb is loaded as module or compiled into kernel. >> >>>> Maby somebody has an idea what the source of the problem could be. >>>> Please find atteched some info, the OS is 9-RC2-amd64 on ESXi5.1 and= >>>> nics are pci-passthrough. >>> I found one possibly relevant difference: >>> >>> Non-Working state: dev.igb.0.link_irq: 0 >>> Working state: dev.igb.0.link_irq: 2 >> This is only true with msi-x!!! >> If I disable mis-x, the problem itself vanishes. igb just works fine >> from the initial loading (with dev.igb.0.link_irq=3D0!). >> So dev.igb.0.link_irq is only relevant with msi-x. >> But what makes me curious is why it also works mith mis-x enabled afte= r >> the second kldload!?! > Hrm, this is strange; in r231621 (MFC'ed to stable/9 in r232092, so > it's part of 9.1-RC2) I've blacklisted the fictitious PCI-PCI bridge > VMware uses in case of PCI pass-through for MSI/MSI-X (as in the cases > observed it didn't even work with a single MSI-X message). So unless > they've changed the ID of the fictitious bridge, igb(4) should fail > to allocate a MSI/MSI-X in the first place. Could you please provide > the output of `pciconf -lv` on that "system"? Hello, here's the output: hostb0@pci0:0:0:0: class=3D0x060000 card=3D0x197615ad chip=3D0x71908= 086 rev=3D0x01 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '440BX/ZX/DX - 82443BX/ZX/DX Host bridge' class =3D bridge subclass =3D HOST-PCI pcib1@pci0:0:1:0: class=3D0x060400 card=3D0x00000000 chip=3D0x71918= 086 rev=3D0x01 hdr=3D0x01 vendor =3D 'Intel Corporation' device =3D '440BX/ZX/DX - 82443BX/ZX/DX AGP bridge' class =3D bridge subclass =3D PCI-PCI isab0@pci0:0:7:0: class=3D0x060100 card=3D0x197615ad chip=3D0x71108= 086 rev=3D0x08 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '82371AB/EB/MB PIIX4 ISA' class =3D bridge subclass =3D PCI-ISA atapci0@pci0:0:7:1: class=3D0x01018e card=3D0x197615ad chip=3D0x71118= 086 rev=3D0x01 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '82371AB/EB/MB PIIX4 IDE' class =3D mass storage subclass =3D ATA intsmb0@pci0:0:7:3: class=3D0x068000 card=3D0x197615ad chip=3D0x71138= 086 rev=3D0x08 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '82371AB/EB/MB PIIX4 ACPI' class =3D bridge none0@pci0:0:7:7: class=3D0x088000 card=3D0x074015ad chip=3D0x07401= 5ad rev=3D0x10 hdr=3D0x00 vendor =3D 'VMware' device =3D 'Virtual Machine Communication Interface' class =3D base peripheral vgapci0@pci0:0:15:0: class=3D0x030000 card=3D0x040515ad chip=3D0x04051= 5ad rev=3D0x00 hdr=3D0x00 vendor =3D 'VMware' device =3D 'SVGA II Adapter' class =3D display subclass =3D VGA pcib2@pci0:0:17:0: class=3D0x060401 card=3D0x079015ad chip=3D0x07901= 5ad rev=3D0x02 hdr=3D0x01 vendor =3D 'VMware' device =3D 'PCI bridge' class =3D bridge subclass =3D PCI-PCI pcib3@pci0:0:21:0: class=3D0x060400 card=3D0x07a015ad chip=3D0x07a01= 5ad rev=3D0x01 hdr=3D0x01 vendor =3D 'VMware' device =3D 'PCI Express Root Port' class =3D bridge subclass =3D PCI-PCI pcib4@pci0:0:22:0: class=3D0x060400 card=3D0x07a015ad chip=3D0x07a01= 5ad rev=3D0x01 hdr=3D0x01 vendor =3D 'VMware' device =3D 'PCI Express Root Port' class =3D bridge subclass =3D PCI-PCI pcib5@pci0:0:23:0: class=3D0x060400 card=3D0x07a015ad chip=3D0x07a01= 5ad rev=3D0x01 hdr=3D0x01 vendor =3D 'VMware' device =3D 'PCI Express Root Port' class =3D bridge subclass =3D PCI-PCI pcib6@pci0:0:24:0: class=3D0x060400 card=3D0x07a015ad chip=3D0x07a01= 5ad rev=3D0x01 hdr=3D0x01 vendor =3D 'VMware' device =3D 'PCI Express Root Port' class =3D bridge subclass =3D PCI-PCI mpt0@pci0:3:0:0: class=3D0x010700 card=3D0x197615ad chip=3D0x00541= 000 rev=3D0x01 hdr=3D0x00 vendor =3D 'LSI Logic / Symbios Logic' device =3D 'SAS1068 PCI-X Fusion-MPT SAS' class =3D mass storage subclass =3D SAS mps0@pci0:4:0:0: class=3D0x010700 card=3D0x30201000 chip=3D0x00721= 000 rev=3D0x03 hdr=3D0x00 vendor =3D 'LSI Logic / Symbios Logic' device =3D 'SAS2008 PCI-Express Fusion-MPT SAS-2 [Falcon]' class =3D mass storage subclass =3D SAS igb0@pci0:5:0:0: class=3D0x020000 card=3D0xa03c8086 chip=3D0x10c98= 086 rev=3D0x01 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '82576 Gigabit Network Connection' class =3D network subclass =3D ethernet igb1@pci0:6:0:0: class=3D0x020000 card=3D0xa03c8086 chip=3D0x10c98= 086 rev=3D0x01 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '82576 Gigabit Network Connection' class =3D network subclass =3D ethernet 0x079015ad is used for PCI-devices afaik, no matter if they're passthrough or virtual. PCIe devices gets a 0x07a015ad slot, again no matter if they're passtrhough or virtual. I limited the number of functions on each slot, to have control over irq assigning. Usually all devices would be found on pcib3, where the virtual mpt sits. In my setup, each PCIe device gets it's own slot to avoid forced irq sharing. Thanks, -Harry --------------enigB0B54448E64B4896BB34B3BC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAlCHylAACgkQLDqVQ9VXb8iwhwCeIHAUhaEBopKS0Ufol+fSuKv+ bywAn2qAIe4sqvbvZlwU78jqbJ2FK2xI =wRxJ -----END PGP SIGNATURE----- --------------enigB0B54448E64B4896BB34B3BC-- From owner-freebsd-stable@FreeBSD.ORG Wed Oct 24 11:00:46 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6A90DE1D for ; Wed, 24 Oct 2012 11:00:46 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) by mx1.freebsd.org (Postfix) with ESMTP id ADD3D8FC08 for ; Wed, 24 Oct 2012 11:00:45 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:b489:24:8697:7e27] (unknown [IPv6:2001:7b8:3a7:0:b489:24:8697:7e27]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 8D11D5C59; Wed, 24 Oct 2012 13:00:44 +0200 (CEST) Message-ID: <5087CA5D.2090407@FreeBSD.org> Date: Wed, 24 Oct 2012 13:00:45 +0200 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Volodymyr Kostyrko Subject: Re: wine, gcc and clang with CPUTYPE References: <50879F62.2010004@gmail.com> <5087BD71.9090002@FreeBSD.org> <5087C428.2020908@gmail.com> In-Reply-To: <5087C428.2020908@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 24 Oct 2012 11:00:46 -0000 On 2012-10-24 12:34, Volodymyr Kostyrko wrote: ... >> Can you attempt to figure out what the illegal instruction was, in that >> case? > How can I do that? I'm not very familiar with gdb. Try the following: $ gdb /path/to/crashed-program /path/to/crashed-program.core GNU gdb (GDB) 7.5 [GDB v7.5 for FreeBSD] Copyright (C) 2012 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "i386-portbld-freebsd10.0". For bug reporting instructions, please see: ... Reading symbols from /path/to/crashed-program...(no debugging symbols found)...done. [New process 100137] Core was generated by `crashed-program'. Program terminated with signal 4, Illegal instruction. #0 0x08048632 in main () (gdb) disassemble Dump of assembler code for function main: 0x08048600 <+0>: push %ebp 0x08048601 <+1>: mov %esp,%ebp 0x08048603 <+3>: sub $0x18,%esp 0x08048606 <+6>: lea 0x80486b0,%eax 0x0804860c <+12>: movl $0x0,-0x4(%ebp) 0x08048613 <+19>: mov %eax,(%esp) 0x08048616 <+22>: call 0x8048390 0x0804861b <+27>: mov 0x8049868,%ecx 0x08048621 <+33>: mov %ecx,(%esp) 0x08048624 <+36>: mov %eax,-0x8(%ebp) 0x08048627 <+39>: call 0x80483c0 0x0804862c <+44>: lea 0x80486ce,%ecx => 0x08048632 <+50>: (bad) 0x08048633 <+51>: (bad) 0x08048634 <+52>: (bad) 0x08048635 <+53>: (bad) 0x08048636 <+54>: (bad) 0x08048637 <+55>: (bad) 0x08048638 <+56>: (bad) 0x08048639 <+57>: decl 0x4589240c(%ecx) 0x0804863f <+63>: hlt 0x08048640 <+64>: call 0x8048390 0x08048645 <+69>: mov 0x8049868,%ecx 0x0804864b <+75>: mov %ecx,(%esp) 0x0804864e <+78>: mov %eax,-0x10(%ebp) 0x08048651 <+81>: call 0x80483c0 0x08048656 <+86>: mov $0x0,%ecx 0x0804865b <+91>: mov %eax,-0x14(%ebp) 0x0804865e <+94>: mov %ecx,%eax 0x08048660 <+96>: add $0x18,%esp 0x08048663 <+99>: pop %ebp 0x08048664 <+100>: ret End of assembler dump. (gdb) info registers eax 0x0 0 ecx 0x80486ce 134514382 edx 0x2819a8d4 672770260 ebx 0xbfbfd650 -1077946800 esp 0xbfbfd5e0 0xbfbfd5e0 ebp 0xbfbfd5f8 0xbfbfd5f8 esi 0xbfbfd64c -1077946804 edi 0x0 0 eip 0x8048632 0x8048632 eflags 0x10286 [ PF SF IF RF ] cs 0x33 51 ss 0x3b 59 ds 0x3b 59 es 0x3b 59 fs 0x3b 59 gs 0x1b 27 It should highlight the illegal instruction with the => arrow. Just copy/paste the whole piece of assembly, and the registers info. ... >> On the problematic athlons, can you please post the exact CPUIDs from >> dmesg? If you have WITH_CLANG_EXTRAS enabled, please also post the >> output of "opt -version". > > Oct 24 01:47:20 limbo kernel: CPU: AMD Athlon(tm) XP 2500+ (1833.95-MHz > 686-class CPU) > Oct 24 01:47:20 limbo kernel: Origin = "AuthenticAMD" Id = 0x6a0 > Family = 0x6 Model = 0xa Stepping = 0 Ok, this CPU should be recognized by llvm as "athlon-xp". There is in fact no need to compile all the WITH_CLANG_EXTRAS programs, I just remembered. If you compile a sample program with -march=native -v, it should show you the detected CPU in the verbose command line output, e.g.: $ clang -v -march=native -c /home/dim/src/example.c FreeBSD clang version 3.2 (trunk 162107) 20120817 Target: i386-unknown-freebsd10.0 Thread model: posix "/usr/bin/clang" -cc1 -triple i386-unknown-freebsd10.0 -emit-obj -mrelax-all -disable-free -main-file-name example.c -mrelocation-model static -mdisable-fp-elim -masm-verbose -mconstructor-aliases -target-cpu core2 -momit-leaf-frame-pointer -v -coverage-file hw.o -resource-dir /usr/bin/../lib/clang/3.2 -fmodule-cache-path /home/dim/tmp/clang-module-cache -fdebug-compilation-dir /home/dim/src -ferror-limit 19 -fmessage-length 265 -mstackrealign -fobjc-runtime=gnustep -fdiagnostics-show-option -fcolor-diagnostics -o hw.o -x c /home/dim/src/example.c clang -cc1 version 3.2 based upon LLVM 3.2svn default target i386-unknown-freebsd10.0 ignoring nonexistent directory "/usr/bin/../lib/clang/3.2/include" #include "..." search starts here: #include <...> search starts here: /usr/include/clang/3.2 /usr/include End of search list. In my case, it uses "-target-cpu core2", as you can see. From owner-freebsd-stable@FreeBSD.ORG Wed Oct 24 11:02:51 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 73204FC7; Wed, 24 Oct 2012 11:02:51 +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 C2BFC8FC0A; Wed, 24 Oct 2012 11:02:50 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q9OB2bIr065380; Wed, 24 Oct 2012 14:02:37 +0300 (EEST) (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.5/8.14.5) with ESMTP id q9OB2PaO030735; Wed, 24 Oct 2012 14:02:25 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q9OB2PFX030734; Wed, 24 Oct 2012 14:02:25 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 24 Oct 2012 14:02:25 +0300 From: Konstantin Belousov To: Volodymyr Kostyrko Subject: Re: wine, gcc and clang with CPUTYPE Message-ID: <20121024110225.GB35915@deviant.kiev.zoral.com.ua> References: <50879F62.2010004@gmail.com> <5087BD71.9090002@FreeBSD.org> <5087C428.2020908@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="/dCIfOYSJNmJ3drl" Content-Disposition: inline In-Reply-To: <5087C428.2020908@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-stable@freebsd.org, Dimitry Andric X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 24 Oct 2012 11:02:51 -0000 --/dCIfOYSJNmJ3drl Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Oct 24, 2012 at 01:34:16PM +0300, Volodymyr Kostyrko wrote: > 24.10.2012 13:05, Dimitry Andric wrote: > >> I just have taken some time to inspect CPUTYPE support for clang. It > >> seems to me that clang generates incorrect code in some cases. > >> > >> The first failure point I discovered was inability to build gcc from > >> sources or compile something with gcc. Code produced by gcc seem to fa= il > >> whether this was gcc compiled from bootstrap or anything else: > >> > >> http://lists.freebsd.org/pipermail/freebsd-multimedia/2012-October/013= 469.html > > > > Can you attempt to figure out what the illegal instruction was, in that > > case? >=20 > How can I do that? I'm not very familiar with gdb. Load the coredump in gdb, like gdb /path/to/the/binary binary.core then, at the gdb prompt, do info registers disassemble (if the later command emited an error, do disassemble x,x+10 where x is the content of the %eip register). Post the verbatim results of the whole gdb session. --/dCIfOYSJNmJ3drl Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAlCHysEACgkQC3+MBN1Mb4iSjwCfU3T2QEo1XeMVPuF1iYO/tsSQ 2lcAoIDxmkSOY2J17AJUBs7YKTvrqGok =0cvR -----END PGP SIGNATURE----- --/dCIfOYSJNmJ3drl-- From owner-freebsd-stable@FreeBSD.ORG Wed Oct 24 11:07:17 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D1978195 for ; Wed, 24 Oct 2012 11:07:17 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) by mx1.freebsd.org (Postfix) with ESMTP id 88BD98FC0A for ; Wed, 24 Oct 2012 11:07:17 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:b489:24:8697:7e27] (unknown [IPv6:2001:7b8:3a7:0:b489:24:8697:7e27]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 0CC215C59; Wed, 24 Oct 2012 13:07:16 +0200 (CEST) Message-ID: <5087CBE4.5040002@andric.com> Date: Wed, 24 Oct 2012 13:07:16 +0200 From: Dimitry Andric User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Volodymyr Kostyrko Subject: Re: wine, gcc and clang with CPUTYPE References: <50879F62.2010004@gmail.com> <5087BD71.9090002@FreeBSD.org> <5087C428.2020908@gmail.com> <5087CA5D.2090407@FreeBSD.org> In-Reply-To: <5087CA5D.2090407@FreeBSD.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 24 Oct 2012 11:07:17 -0000 On 2012-10-24 13:00, Dimitry Andric wrote: .. > Try the following: > > $ gdb /path/to/crashed-program /path/to/crashed-program.core > GNU gdb (GDB) 7.5 [GDB v7.5 for FreeBSD] > Copyright (C) 2012 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. Type "show copying" > and "show warranty" for details. > This GDB was configured as "i386-portbld-freebsd10.0". > For bug reporting instructions, please see: > ... > Reading symbols from /path/to/crashed-program...(no debugging symbols found)...done. > [New process 100137] > Core was generated by `crashed-program'. > Program terminated with signal 4, Illegal instruction. > #0 0x08048632 in main () > (gdb) disassemble In fact, please use "disassemble/r", otherwise the actual opcodes won't be shown. From owner-freebsd-stable@FreeBSD.ORG Wed Oct 24 11:11:48 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 590D92D6; Wed, 24 Oct 2012 11:11:48 +0000 (UTC) (envelope-from lars@e-new.0x20.net) Received: from mail.0x20.net (mail.0x20.net [217.69.76.211]) by mx1.freebsd.org (Postfix) with ESMTP id 06B988FC12; Wed, 24 Oct 2012 11:11:47 +0000 (UTC) Received: from e-new.0x20.net (mail.0x20.net [IPv6:2001:aa8:fffb:1::3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.0x20.net (Postfix) with ESMTPS id E64746A6001; Wed, 24 Oct 2012 13:11:45 +0200 (CEST) Received: from e-new.0x20.net (localhost [127.0.0.1]) by e-new.0x20.net (8.14.5/8.14.5) with ESMTP id q9OBBjCx020554; Wed, 24 Oct 2012 13:11:45 +0200 (CEST) (envelope-from lars@e-new.0x20.net) Received: (from lars@localhost) by e-new.0x20.net (8.14.5/8.14.5/Submit) id q9OBBiep019936; Wed, 24 Oct 2012 13:11:44 +0200 (CEST) (envelope-from lars) Date: Wed, 24 Oct 2012 13:11:44 +0200 From: Lars Engels To: Eitan Adler Subject: Re: FreeBSD in Google Code-In 2012? You can help too! Message-ID: <20121024111144.GF82606@e-new.0x20.net> References: <20121016101957.GB53800@FreeBSD.org> <20121022174457.GB59689@FreeBSD.org> <5086AC06.5070405@a1poweruser.com> <5214043c002ef030f59c2045344b8725.squirrel@webmail.ee.ryerson.ca> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Ls2Gy6y7jbHLe9Od" Content-Disposition: inline In-Reply-To: X-Editor: VIM - Vi IMproved 7.3 X-Operation-System: FreeBSD 8.3-RELEASE-p4 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: David Magda , freebsd-hackers@freebsd.org, Fbsd8 , "Wojciech A. Koszek" , freebsd-current@freebsd.org, freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 24 Oct 2012 11:11:48 -0000 --Ls2Gy6y7jbHLe9Od Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Oct 23, 2012 at 03:59:07PM -0400, Eitan Adler wrote: > On 23 October 2012 12:54, David Magda wrote: > > On Tue, October 23, 2012 10:39, Fbsd8 wrote: > >> > >> The subject is Google Code-In and all the posted tasks are directed at > >> creating documentation. Not one deals with coding any programs. If I w= as > >> 15-17 years old I sure would not be interested in writing documentatio= n. > >> I would want to use and develop my coding skills. To that end there a > >> lot of simple PR's waiting for attention. This is an target area that > >> young coders would find more interesting. > > > > It would depend on what one's interests were. >=20 > Google code-in is aimed at *coders* and there is an expectation of > people writing *code*. >=20 > The biggest complaint for GCI last year was "not enough coding tasks" What about creating a new port? That is some kind of coding. If we can find some software that isn't ported, yet and not too hard to port (e.g. the wanted ports page in the wiki) we could make a task proposal of it. And one generic "create a port for a piece of software that hasn't been ported, yet". Feel free to add me as a mentor for such a task. --Ls2Gy6y7jbHLe9Od Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlCHzPAACgkQKc512sD3afgtpgCeM+yMheOK1Xe0GbytCD+m653V o04An1vUco/9u4png/UGCuWexgIiWWbz =0W5K -----END PGP SIGNATURE----- --Ls2Gy6y7jbHLe9Od-- From owner-freebsd-stable@FreeBSD.ORG Wed Oct 24 11:26:38 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9BB0760C; Wed, 24 Oct 2012 11:26:38 +0000 (UTC) (envelope-from c.kworr@gmail.com) Received: from mail-pa0-f54.google.com (mail-pa0-f54.google.com [209.85.220.54]) by mx1.freebsd.org (Postfix) with ESMTP id 61CD38FC12; Wed, 24 Oct 2012 11:26:38 +0000 (UTC) Received: by mail-pa0-f54.google.com with SMTP id bi1so313960pad.13 for ; Wed, 24 Oct 2012 04:26:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=6DxKy3ofAclhqGOKizeXkanS3EeE2YzFToOmNPg0p8s=; b=NwY109/xRwMmjyktfm2ad1DaH34s4HPOZRIgWgLq/7IxN72u3f3q327sFtBr6iQ8yE ORh+DP3IX5ZH9JPlwo+48iDurxwebGx66arWM9TzXYMKwgfreL4d8kf8cFiu173y+mxN Bk7Cta6DdY88sWuX8FMN2BcKuCcZGsnvkN3gUCVQGzPfYwhYhS/a3nnQLDyUf7amTArG WTev0c3M1o685G+iKeY1E0Pbr9UMburdHVKAHPZkm0aKh2Dg8tN7dtP7IwQ96ht5ngXv ugYZIlojilXwgx9MiK6kCPtMEcw69ATSZr+g7tPviNDvsoMwj6bvSks0Cl6TrVhbU0nZ ZbIQ== Received: by 10.68.233.230 with SMTP id tz6mr48946314pbc.36.1351077997780; Wed, 24 Oct 2012 04:26:37 -0700 (PDT) Received: from [192.168.1.131] (mau.donbass.com. [92.242.127.250]) by mx.google.com with ESMTPS id uh7sm9323446pbc.35.2012.10.24.04.26.35 (version=SSLv3 cipher=OTHER); Wed, 24 Oct 2012 04:26:37 -0700 (PDT) Message-ID: <5087D069.7040700@gmail.com> Date: Wed, 24 Oct 2012 14:26:33 +0300 From: Volodymyr Kostyrko User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:16.0) Gecko/20121015 Thunderbird/16.0.1 MIME-Version: 1.0 To: Dimitry Andric Subject: Re: wine, gcc and clang with CPUTYPE References: <50879F62.2010004@gmail.com> <5087BD71.9090002@FreeBSD.org> <5087C428.2020908@gmail.com> <5087CA5D.2090407@FreeBSD.org> In-Reply-To: <5087CA5D.2090407@FreeBSD.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 24 Oct 2012 11:26:38 -0000 24.10.2012 14:00, Dimitry Andric wrote: >>> On the problematic athlons, can you please post the exact CPUIDs from >>> dmesg? If you have WITH_CLANG_EXTRAS enabled, please also post the >>> output of "opt -version". >> >> Oct 24 01:47:20 limbo kernel: CPU: AMD Athlon(tm) XP 2500+ (1833.95-MHz >> 686-class CPU) >> Oct 24 01:47:20 limbo kernel: Origin = "AuthenticAMD" Id = 0x6a0 >> Family = 0x6 Model = 0xa Stepping = 0 > > Ok, this CPU should be recognized by llvm as "athlon-xp". There is in > fact no need to compile all the WITH_CLANG_EXTRAS programs, I just > remembered. > > If you compile a sample program with -march=native -v, it should show > you the detected CPU in the verbose command line output, e.g.: > > $ clang -v -march=native -c /home/dim/src/example.c > FreeBSD clang version 3.2 (trunk 162107) 20120817 > Target: i386-unknown-freebsd10.0 > Thread model: posix > "/usr/bin/clang" -cc1 -triple i386-unknown-freebsd10.0 -emit-obj > -mrelax-all -disable-free -main-file-name example.c -mrelocation-model > static -mdisable-fp-elim -masm-verbose -mconstructor-aliases -target-cpu > core2 -momit-leaf-frame-pointer -v -coverage-file hw.o -resource-dir > /usr/bin/../lib/clang/3.2 -fmodule-cache-path > /home/dim/tmp/clang-module-cache -fdebug-compilation-dir /home/dim/src > -ferror-limit 19 -fmessage-length 265 -mstackrealign > -fobjc-runtime=gnustep -fdiagnostics-show-option -fcolor-diagnostics -o > hw.o -x c /home/dim/src/example.c > clang -cc1 version 3.2 based upon LLVM 3.2svn default target > i386-unknown-freebsd10.0 > ignoring nonexistent directory "/usr/bin/../lib/clang/3.2/include" > #include "..." search starts here: > #include <...> search starts here: > /usr/include/clang/3.2 > /usr/include > End of search list. > > In my case, it uses "-target-cpu core2", as you can see. Yes, my CPU is detected as athlon-xp by clang: # : | clang -v -E -march=native - FreeBSD clang version 3.1 (branches/release_31 156863) 20120523 Target: i386-unknown-freebsd9.0 Thread model: posix "/usr/bin/clang" -cc1 -triple i386-unknown-freebsd9.0 -E -disable-free -main-file-name - -mrelocation-model static -mdisable-fp-elim -masm-verbose -mconstructor-aliases -target-cpu athlon-xp -momit-leaf-frame-pointer -v -resource-dir /usr/bin/../lib/clang/3.1 -fmodule-cache-path /var/tmp/clang-module-cache -fdebug-compilation-dir /usr/src -ferror-limit 19 -fmessage-length 186 -mstackrealign -fgnu-runtime -fobjc-runtime-has-arc -fobjc-runtime-has-weak -fobjc-dispatch-method=non-legacy -fdiagnostics-show-option -fcolor-diagnostics -o - -x c - clang -cc1 version 3.1 based upon LLVM 3.1 default target i386-unknown-freebsd9.0 ignoring nonexistent directory "/usr/bin/../lib/clang/3.1/include" #include "..." search starts here: #include <...> search starts here: /usr/include/clang/3.1 /usr/include End of search list. # 1 "" # 1 "" 1 # 1 "" 1 # 1 "" 3 # 147 "" 3 # 1 "" 1 # 1 "" 2 # 1 "" 2 And as athlon-4 by gcc: # : | gcc -v -E -march=native - Using built-in specs. Target: i386-undermydesk-freebsd Configured with: FreeBSD/i386 system compiler Thread model: posix gcc version 4.2.1 20070831 patched [FreeBSD] /usr/libexec/cc1 -E -quiet -v -D_LONGLONG - -march=athlon-4 -mtune=athlon-4 #include "..." search starts here: #include <...> search starts here: /usr/include/gcc/4.2 /usr/include End of search list. # 1 "" # 1 "" # 1 "" # 1 "" # : | gcc46 -v -E -march=native - Using built-in specs. COLLECT_GCC=/usr/local/bin/gcc46 COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc46/gcc/i386-portbld-freebsd9.1/4.6.3/lto-wrapper Target: i386-portbld-freebsd9.1 Configured with: ./../gcc-4.6.3/configure --disable-bootstrap --disable-nls --libdir=/usr/local/lib/gcc46 --libexecdir=/usr/local/libexec/gcc46 --program-suffix=46 --with-as=/usr/local/bin/as --with-gmp=/usr/local --with-gxx-include-dir=/usr/local/lib/gcc46/include/c++/ --with-ld=/usr/local/bin/ld --with-libiconv-prefix=/usr/local --with-pkgversion='FreeBSD Ports Collection' --with-system-zlib --disable-libgcj --enable-languages=c,c++,objc,fortran --prefix=/usr/local --mandir=/usr/local/man --infodir=/usr/local/info/gcc46 --build=i386-portbld-freebsd9.1 Thread model: posix gcc version 4.6.3 (FreeBSD Ports Collection) COLLECT_GCC_OPTIONS='-v' '-E' '-march=native' /usr/local/libexec/gcc46/gcc/i386-portbld-freebsd9.1/4.6.3/cc1 -E -quiet -v - -march=athlon-4 -mno-cx16 -mno-sahf -mno-movbe -mno-aes -mno-pclmul -mno-popcnt -mno-abm -mno-lwp -mno-fma -mno-fma4 -mno-xop -mno-bmi -mno-tbm -mno-avx -mno-sse4.2 -mno-sse4.1 --param l1-cache-size=64 --param l1-cache-line-size=64 --param l2-cache-size=512 -mtune=athlon ignoring nonexistent directory "/usr/local/lib/gcc46/gcc/i386-portbld-freebsd9.1/4.6.3/../../../../../i386-portbld-freebsd9.1/include" #include "..." search starts here: #include <...> search starts here: /usr/local/lib/gcc46/gcc/i386-portbld-freebsd9.1/4.6.3/include /usr/local/include /usr/local/lib/gcc46/gcc/i386-portbld-freebsd9.1/4.6.3/include-fixed /usr/include End of search list. # 1 "" # 1 "" # 1 "" # 1 "" COMPILER_PATH=/usr/local/libexec/gcc46/gcc/i386-portbld-freebsd9.1/4.6.3/:/usr/local/libexec/gcc46/gcc/i386-portbld-freebsd9.1/4.6.3/:/usr/local/libexec/gcc46/gcc/i386-portbld-freebsd9.1/:/usr/local/lib/gcc46/gcc/i386-portbld-freebsd9.1/4.6.3/:/usr/local/lib/gcc46/gcc/i386-portbld-freebsd9.1/:/usr/local/lib/gcc46/gcc/i386-portbld-freebsd9.1/4.6.3/../../../../../i386-portbld-freebsd9.1/bin/ LIBRARY_PATH=/usr/local/lib/gcc46/gcc/i386-portbld-freebsd9.1/4.6.3/:/usr/local/lib/gcc46/gcc/i386-portbld-freebsd9.1/4.6.3/../../../../../i386-portbld-freebsd9.1/lib/:/usr/local/lib/gcc46/gcc/i386-portbld-freebsd9.1/4.6.3/../../../:/lib/:/usr/lib/ COLLECT_GCC_OPTIONS='-v' '-E' '-march=native' So I'll proceed to reproducing gcc errors. -- Sphinx of black quartz, judge my vow. From owner-freebsd-stable@FreeBSD.ORG Wed Oct 24 12:31:32 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CA5DF3B3 for ; Wed, 24 Oct 2012 12:31:32 +0000 (UTC) (envelope-from h.schmalzbauer@omnilan.de) Received: from host.omnilan.net (s1.omnilan.net [62.245.232.135]) by mx1.freebsd.org (Postfix) with ESMTP id 5444B8FC08 for ; Wed, 24 Oct 2012 12:31:31 +0000 (UTC) Received: from titan.inop.wdn.omnilan.net (titan.inop.wdn.omnilan.net [172.21.3.1]) (authenticated bits=0) by host.omnilan.net (8.13.8/8.13.8) with ESMTP id q9OCWqqx068658 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 24 Oct 2012 14:32:52 +0200 (CEST) (envelope-from h.schmalzbauer@omnilan.de) Message-ID: <5087DFA1.7090001@omnilan.de> Date: Wed, 24 Oct 2012 14:31:29 +0200 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: FreeBSD Stable Subject: every 2nd echo-request malformed when ping -s >4067 X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigE123D7F3AAE59B77986FB575" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 24 Oct 2012 12:31:32 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigE123D7F3AAE59B77986FB575 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Hello, while checking new mtu9k-setup, I discovered that ping has some odd behaviour. If I use payloadsize > 4067, every 2nd icmp-echo-request seems to be malformed: ping -s 4068 -D 10.5.49.65 1st: 12:21:09.048447 IP 10.5.49.126 > 10.5.49.65: ICMP echo request, id 46597, seq 0, length 4076 0x0000: 4500 1000 0f2d 4000 4001 a507 0a05 317e 2nd: 12:21:10.052891 IP 10.5.49.126 > 10.5.49.65: icmp 0x0000: 4500 1000 0f2d 0040 4001 e4c7 0a05 317e 3rd: 12:21:11.062900 IP 10.5.49.126 > 10.5.49.65: ICMP echo request, id 46597, seq 2, length 4076 0x0000: 4500 1000 0f2d 4000 4001 a507 0a05 317e 4th: 12:21:12.072915 IP 10.5.49.126 > 10.5.49.65: icmp 0x0000: 4500 1000 0f2d 0040 4001 e4c7 0a05 317e 5th: 12:21:13.082900 IP 10.5.49.126 > 10.5.49.65: ICMP echo request, id 46597, seq 4, length 4076 0x0000: 4500 1000 0f2d 4000 4001 a507 0a05 317e When payload is 4076, outgoing _every_ outgoing request begins with 4500 xxxx xxxx 4000 4001, while above we see every second request starting with 4500 xxxx xxxx 0040 4001. Does anybody know header composing off pat? Haven't seen these bits for quiet some time... Thanks, -Harry --------------enigE123D7F3AAE59B77986FB575 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAlCH36EACgkQLDqVQ9VXb8gqywCgjo7J0HbTeyd66wdPv+d9gKMo jXEAoMQv3EQFeyCgDThAy8wcxbM7V9Vr =xLJf -----END PGP SIGNATURE----- --------------enigE123D7F3AAE59B77986FB575-- From owner-freebsd-stable@FreeBSD.ORG Wed Oct 24 13:48:38 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7021236D for ; Wed, 24 Oct 2012 13:48:38 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 40BB88FC08 for ; Wed, 24 Oct 2012 13:48:38 +0000 (UTC) Received: by mail-pb0-f54.google.com with SMTP id rp8so1304495pbb.13 for ; Wed, 24 Oct 2012 06:48:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=TOwvJT6GSJJL3qZX5aHCC60xmiJOjg90EKbZeOlaILQ=; b=Q+K8X7aMjLn3GiEC1ERS69gUefV7en/ZAW9qdTbs2iqnDcVuSsq6gFPCHCS/5GbNxK 0Odia/2TEa6s/QgHq2L2oxHEuNxggdbKqFSx6Ee30bNsBBJR7s1qBpEYfz54Vc9p4ja1 zIj03GOrHVldtaL6s8PLSlWSvkUjE689GlyC6aDj165HucpHDSmczDABeptS7P6pkFp2 txqFz69k6FLgQP42CtjkYfB8Y6VJ1u/7yXlkOg7ouCtSGtxzReaDUg1KHKx5w9V9KJRK Mgx0q8TShQ+616agsVDu4UWx5z3uzWUnGGhlRVIPsPZeyG6OUK062XCLcg3FSiBQX72B 9ghw== MIME-Version: 1.0 Received: by 10.66.74.65 with SMTP id r1mr44086968pav.75.1351086517535; Wed, 24 Oct 2012 06:48:37 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.68.146.233 with HTTP; Wed, 24 Oct 2012 06:48:37 -0700 (PDT) In-Reply-To: <5087DFA1.7090001@omnilan.de> References: <5087DFA1.7090001@omnilan.de> Date: Wed, 24 Oct 2012 06:48:37 -0700 X-Google-Sender-Auth: rtHq_jKJ8E2EA8EN7HwSfTOfG2U Message-ID: Subject: Re: every 2nd echo-request malformed when ping -s >4067 From: Adrian Chadd To: Harald Schmalzbauer Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 24 Oct 2012 13:48:38 -0000 On 24 October 2012 05:31, Harald Schmalzbauer wrote: > Hello, > > while checking new mtu9k-setup, I discovered that ping has some odd > behaviour. > If I use payloadsize > 4067, every 2nd icmp-echo-request seems to be > malformed: Is this on -HEAD? > ping -s 4068 -D 10.5.49.65 > > 1st: 12:21:09.048447 IP 10.5.49.126 > 10.5.49.65: ICMP echo request, id > 46597, seq 0, length 4076 > 0x0000: 4500 1000 0f2d 4000 4001 a507 0a05 317e > > 2nd: 12:21:10.052891 IP 10.5.49.126 > 10.5.49.65: icmp > 0x0000: 4500 1000 0f2d 0040 4001 e4c7 0a05 317e > > 3rd: 12:21:11.062900 IP 10.5.49.126 > 10.5.49.65: ICMP echo request, id > 46597, seq 2, length 4076 > 0x0000: 4500 1000 0f2d 4000 4001 a507 0a05 317e > > 4th: 12:21:12.072915 IP 10.5.49.126 > 10.5.49.65: icmp > 0x0000: 4500 1000 0f2d 0040 4001 e4c7 0a05 317e > > 5th: 12:21:13.082900 IP 10.5.49.126 > 10.5.49.65: ICMP echo request, id > 46597, seq 4, length 4076 > 0x0000: 4500 1000 0f2d 4000 4001 a507 0a05 317e > > When payload is 4076, outgoing _every_ outgoing request begins with > 4500 xxxx xxxx 4000 4001, > while above we see every second request starting with > 4500 xxxx xxxx 0040 4001. > Does anybody know header composing off pat? Haven't seen these bits for > quiet some time... Glebius was recently in the networking stack in -HEAD, fiddling with how IP headers are treated. Maybe this is some corner case fallout from that? adrian From owner-freebsd-stable@FreeBSD.ORG Wed Oct 24 14:00:30 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7247C55D; Wed, 24 Oct 2012 14:00:30 +0000 (UTC) (envelope-from h.schmalzbauer@omnilan.de) Received: from host.omnilan.net (s1.omnilan.net [62.245.232.135]) by mx1.freebsd.org (Postfix) with ESMTP id EC2978FC16; Wed, 24 Oct 2012 14:00:29 +0000 (UTC) Received: from titan.inop.wdn.omnilan.net (titan.inop.wdn.omnilan.net [172.21.3.1]) (authenticated bits=0) by host.omnilan.net (8.13.8/8.13.8) with ESMTP id q9OE1ou0070215 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 24 Oct 2012 16:01:50 +0200 (CEST) (envelope-from h.schmalzbauer@omnilan.de) Message-ID: <5087F47B.50708@omnilan.de> Date: Wed, 24 Oct 2012 16:00:27 +0200 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Adrian Chadd Subject: Re: every 2nd echo-request malformed when ping -s >4067 References: <5087DFA1.7090001@omnilan.de> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigDD6813D284F7FDEDC8272985" Cc: FreeBSD Stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 24 Oct 2012 14:00:30 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigDD6813D284F7FDEDC8272985 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable schrieb Adrian Chadd am 24.10.2012 15:48 (localtime): > On 24 October 2012 05:31, Harald Schmalzbauer wrote: >> Hello, >> >> while checking new mtu9k-setup, I discovered that ping has some odd >> behaviour. >> If I use payloadsize > 4067, every 2nd icmp-echo-request seems to be >> malformed: > Is this on -HEAD? > Sorry, forgot to mention that it's with 9.1-RC2. But I've seen this also with 8.x long time ago. That time I had some nics not j9k-frame capable, so I never had a look at the wire what's really going on... Thanks, -Harry --------------enigDD6813D284F7FDEDC8272985 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAlCH9HsACgkQLDqVQ9VXb8hUAQCgjtWfyRNXimjsC5YIPIeDBbci 7gwAoIGLxWnQfO5UaLo/HJzOgLIu18Mo =q1s9 -----END PGP SIGNATURE----- --------------enigDD6813D284F7FDEDC8272985-- From owner-freebsd-stable@FreeBSD.ORG Wed Oct 24 14:33:25 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5496BE4D for ; Wed, 24 Oct 2012 14:33:25 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pa0-f54.google.com (mail-pa0-f54.google.com [209.85.220.54]) by mx1.freebsd.org (Postfix) with ESMTP id 030828FC14 for ; Wed, 24 Oct 2012 14:33:24 +0000 (UTC) Received: by mail-pa0-f54.google.com with SMTP id bi1so430327pad.13 for ; Wed, 24 Oct 2012 07:33:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=ZWHwe1fKjPyf31t0vGtSm0EmlaNevpTnIsbTX16wfZ8=; b=jByInx16rUaM7Y/vMWXMm+u9+u1bUieHyWEyRCpxFiJGkjJQOIPTMZF5+NDSSoGg8I G+1/A8oBzdD40SJp/eo9Swl0eq+1nj8ALjOJNzaifO8RMbt6SjJNm1lLdZW8jAMIgC8w q7XzvN6wAhRIHi+OmZSrFtkhM7Wn7wZozEQAOE3KfEVkgNJx3cjhd+y+1doOPu7VVXMM epqhsLlzZtmcsYbtVj1BYsh1vmsp5j1hlA5pDnyyzd+HpGOWD+9NkTw52NRylQCxt/jG EdDDxo0kL4FEhH6lap17o42YeCUWAfaWEU+Gol6OmhdfHxaMz/EwCasHNLEEkvw9+ItQ QCZg== MIME-Version: 1.0 Received: by 10.68.135.168 with SMTP id pt8mr51365514pbb.24.1351089204358; Wed, 24 Oct 2012 07:33:24 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.68.146.233 with HTTP; Wed, 24 Oct 2012 07:33:24 -0700 (PDT) In-Reply-To: <5087F47B.50708@omnilan.de> References: <5087DFA1.7090001@omnilan.de> <5087F47B.50708@omnilan.de> Date: Wed, 24 Oct 2012 07:33:24 -0700 X-Google-Sender-Auth: BbZ_xLJ7GP9f5xGsN21zr2ZtRbY Message-ID: Subject: Re: every 2nd echo-request malformed when ping -s >4067 From: Adrian Chadd To: Harald Schmalzbauer Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 24 Oct 2012 14:33:25 -0000 On 24 October 2012 07:00, Harald Schmalzbauer wrote: > Sorry, forgot to mention that it's with 9.1-RC2. But I've seen this also > with 8.x long time ago. That time I had some nics not j9k-frame capable, > so I never had a look at the wire what's really going on... Ah, good. Not -HEAD. Phew. :-) Yeah, I'd fire off a PR. Which field is that? Fragment offset? Adrian From owner-freebsd-stable@FreeBSD.ORG Wed Oct 24 15:40:18 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A9DAFD16 for ; Wed, 24 Oct 2012 15:40:18 +0000 (UTC) (envelope-from jdc@koitsu.strangled.net) Received: from qmta14.emeryville.ca.mail.comcast.net (qmta14.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:44:76:96:27:212]) by mx1.freebsd.org (Postfix) with ESMTP id 8C9208FC1C for ; Wed, 24 Oct 2012 15:40:18 +0000 (UTC) Received: from omta01.emeryville.ca.mail.comcast.net ([76.96.30.11]) by qmta14.emeryville.ca.mail.comcast.net with comcast id F1jp1k0060EPchoAE3gJG8; Wed, 24 Oct 2012 15:40:18 +0000 Received: from koitsu.strangled.net ([67.180.84.87]) by omta01.emeryville.ca.mail.comcast.net with comcast id F3gH1k00A1t3BNj8M3gHxU; Wed, 24 Oct 2012 15:40:18 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 0D4C273A1A; Wed, 24 Oct 2012 08:40:17 -0700 (PDT) Date: Wed, 24 Oct 2012 08:40:17 -0700 From: Jeremy Chadwick To: h.schmalzbauer@omnilan.de Subject: Re: every 2nd echo-request malformed when ping -s >4067 Message-ID: <20121024154017.GA3167@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Cc: adrian@freebsd.org, freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 24 Oct 2012 15:40:18 -0000 (Please keep me CC'd as I'm not subscribed) Regarding: http://lists.freebsd.org/pipermail/freebsd-stable/2012-October/070239.html tcpdump -x is not helpful here. tcpdump -xx would be. tcpdump -x dumps the *payload* portion of the packet, while -xx dumps everything (all headers/protocol data included). The reason I say -xx would be helpful is because of this: > 2nd: 12:21:10.052891 IP 10.5.49.126 > 10.5.49.65: icmp > 0x0000: 4500 1000 0f2d 0040 4001 e4c7 0a05 317e The ICMP code/type and related header data is not being decoded correctly, or is being *encoded* incorrectly. I can't tell because all that's shown there is the payload! But the preceding line (with src/dst IPs) only indicates "it's icmp". It SHOULD be indicating type 8 (ECHO), etc... Regarding the payload itself: I couldn't care less what's in it. All that's stated per RFC 792 is: "The data received in the echo message must be returned in the echo reply message." If I remember right, the payload portion is 100% "vendor-specific", meaning you can put whatever you want there. Let's see... http://www.networksorcery.com/enp/protocol/icmp/msg8.htm "Data. Variable length. Implementation specific data." I've looked at src/sys/netinet/ip_icmp.c but it's not entirely clear what the payload consists of/is generated from. But like I said, I couldn't care less about the payload. What needs to be focused on is what's in the IP and ICMP header portion. -- | Jeremy Chadwick jdc@koitsu.org | | UNIX Systems Administrator http://jdc.koitsu.org/ | | Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Wed Oct 24 16:24:33 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8B4724FC; Wed, 24 Oct 2012 16:24:33 +0000 (UTC) (envelope-from h.schmalzbauer@omnilan.de) Received: from host.omnilan.net (s1.omnilan.net [62.245.232.135]) by mx1.freebsd.org (Postfix) with ESMTP id D96A08FC0A; Wed, 24 Oct 2012 16:24:32 +0000 (UTC) Received: from titan.inop.wdn.omnilan.net (titan.inop.wdn.omnilan.net [172.21.3.1]) (authenticated bits=0) by host.omnilan.net (8.13.8/8.13.8) with ESMTP id q9OGPrSm072583 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 24 Oct 2012 18:25:53 +0200 (CEST) (envelope-from h.schmalzbauer@omnilan.de) Message-ID: <5088163E.2090506@omnilan.de> Date: Wed, 24 Oct 2012 18:24:30 +0200 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Jeremy Chadwick Subject: Re: every 2nd echo-request malformed when ping -s >4067 References: <20121024154017.GA3167@icarus.home.lan> In-Reply-To: <20121024154017.GA3167@icarus.home.lan> X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig3B546E6D0DDE8702202A5B74" Cc: adrian@freebsd.org, freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 24 Oct 2012 16:24:33 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig3B546E6D0DDE8702202A5B74 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable schrieb Jeremy Chadwick am 24.10.2012 17:40 (localtime): > (Please keep me CC'd as I'm not subscribed) > > Regarding: > > http://lists.freebsd.org/pipermail/freebsd-stable/2012-October/070239.h= tml > > tcpdump -x is not helpful here. tcpdump -xx would be. > > tcpdump -x dumps the *payload* portion of the packet, while -xx dumps > everything (all headers/protocol data included). > > The reason I say -xx would be helpful is because of this: > >> 2nd: 12:21:10.052891 IP 10.5.49.126 > 10.5.49.65: icmp >> 0x0000: 4500 1000 0f2d 0040 4001 e4c7 0a05 317e > The ICMP code/type and related header data is not being decoded > correctly, or is being *encoded* incorrectly. I can't tell because all= > that's shown there is the payload!=20 Hmm, if I understand things right, there's only the link-level-header missing, meaning the ethernet adresses. Not the IP-header. Verified that: 1st: 16:03:08.963292 IP 10.5.49.126 > 10.5.49.65: ICMP echo request, id 30477, seq 0, length 4076 000c 29f1 8424 90e2 ba18 f885 0800 2nd: 16:03:09.968454 IP 10.5.49.126 > 10.5.49.65: icmp 000c 29f1 8424 90e2 ba18 f885 0800 Since the link-level-header is identical, the problem must be later and the former dump should be valid. That's easily reproducable everywhere, since lo0 has mtu 16384, so just ' ping -D -s 4068 127.0.0.1 '. Thanks, -Harry --------------enig3B546E6D0DDE8702202A5B74 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAlCIFj4ACgkQLDqVQ9VXb8hWnwCfcfDpTztBpewIDY3io5zTsidS q/8AoJCYPjPCnDPmThmjfLYZKa+/7f7r =aPBZ -----END PGP SIGNATURE----- --------------enig3B546E6D0DDE8702202A5B74-- From owner-freebsd-stable@FreeBSD.ORG Wed Oct 24 16:51:49 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BECB6E4 for ; Wed, 24 Oct 2012 16:51:49 +0000 (UTC) (envelope-from jdc@koitsu.strangled.net) Received: from qmta11.emeryville.ca.mail.comcast.net (qmta11.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:44:76:96:27:211]) by mx1.freebsd.org (Postfix) with ESMTP id 9B9788FC17 for ; Wed, 24 Oct 2012 16:51:49 +0000 (UTC) Received: from omta21.emeryville.ca.mail.comcast.net ([76.96.30.88]) by qmta11.emeryville.ca.mail.comcast.net with comcast id F2Dr1k0021u4NiLAB4rppY; Wed, 24 Oct 2012 16:51:49 +0000 Received: from koitsu.strangled.net ([67.180.84.87]) by omta21.emeryville.ca.mail.comcast.net with comcast id F4ro1k00C1t3BNj8h4rovX; Wed, 24 Oct 2012 16:51:49 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 0C3EF73A1C; Wed, 24 Oct 2012 09:51:48 -0700 (PDT) Date: Wed, 24 Oct 2012 09:51:48 -0700 From: Jeremy Chadwick To: Harald Schmalzbauer Subject: Re: every 2nd echo-request malformed when ping -s >4067 Message-ID: <20121024165148.GA4250@icarus.home.lan> References: <20121024154017.GA3167@icarus.home.lan> <5088163E.2090506@omnilan.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5088163E.2090506@omnilan.de> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: adrian@freebsd.org, freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 24 Oct 2012 16:51:49 -0000 On Wed, Oct 24, 2012 at 06:24:30PM +0200, Harald Schmalzbauer wrote: > schrieb Jeremy Chadwick am 24.10.2012 17:40 (localtime): > > (Please keep me CC'd as I'm not subscribed) > > > > Regarding: > > > > http://lists.freebsd.org/pipermail/freebsd-stable/2012-October/070239.html > > > > tcpdump -x is not helpful here. tcpdump -xx would be. > > > > tcpdump -x dumps the *payload* portion of the packet, while -xx dumps > > everything (all headers/protocol data included). > > > > The reason I say -xx would be helpful is because of this: > > > >> 2nd: 12:21:10.052891 IP 10.5.49.126 > 10.5.49.65: icmp > >> 0x0000: 4500 1000 0f2d 0040 4001 e4c7 0a05 317e > > The ICMP code/type and related header data is not being decoded > > correctly, or is being *encoded* incorrectly. I can't tell because all > > that's shown there is the payload! > > Hmm, if I understand things right, there's only the link-level-header > missing, meaning the ethernet adresses. Not the IP-header. > Verified that: > > 1st: 16:03:08.963292 IP 10.5.49.126 > 10.5.49.65: ICMP echo request, id > 30477, seq 0, length 4076 > 000c 29f1 8424 90e2 ba18 f885 0800 > > 2nd: 16:03:09.968454 IP 10.5.49.126 > 10.5.49.65: icmp > 000c 29f1 8424 90e2 ba18 f885 0800 > > Since the link-level-header is identical, the problem must be later and > the former dump should be valid. > That's easily reproducable everywhere, since lo0 has mtu 16384, so just > ' ping -D -s 4068 127.0.0.1 '. I'm a little confused by your statement. What concerns me is that tcpdump isn't able to decode the ICMP type, ID number, sequence number, or length of the 2nd packet in your example. Those fields are kept within the ICMP header itself, not the ICMP payload. What you should be seeing is this (using 4.2.2.1 as a test host): # tcpdump -p -i em0 -l -n -s 0 -xx "icmp and dst host 4.2.2.1" tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on em0, link-type EN10MB (Ethernet), capture size 65535 bytes 09:45:22.725137 IP 192.168.1.51 > 4.2.2.1: ICMP echo request, id 6417, seq 0, length 64 0x0000: e0cb 4ec0 00c4 0030 48d2 22d0 0800 4500 0x0010: 0054 2f29 0000 4001 83a2 c0a8 0133 0402 0x0020: 0201 0800 77b0 1911 0000 5088 1b22 000b 0x0030: 1086 0809 0a0b 0c0d 0e0f 1011 1213 1415 0x0040: 1617 1819 1a1b 1c1d 1e1f 2021 2223 2425 0x0050: 2627 2829 2a2b 2c2d 2e2f 3031 3233 3435 0x0060: 3637 09:45:23.726143 IP 192.168.1.51 > 4.2.2.1: ICMP echo request, id 6417, seq 1, length 64 0x0000: e0cb 4ec0 00c4 0030 48d2 22d0 0800 4500 0x0010: 0054 2f37 0000 4001 8394 c0a8 0133 0402 0x0020: 0201 0800 73be 1911 0001 5088 1b23 000b 0x0030: 1476 0809 0a0b 0c0d 0e0f 1011 1213 1415 0x0040: 1617 1819 1a1b 1c1d 1e1f 2021 2223 2425 0x0050: 2627 2829 2a2b 2c2d 2e2f 3031 3233 3435 0x0060: 3637 Note that in both cases (both outbound ICMP ECHO packets), tcpdump is able to decode the type (type 8), id number, sequence number, length, etc.. Said differently, look at this: 09:45:22.725137 IP 192.168.1.51 > 4.2.2.1: ICMP echo request, id 6417, seq 0, length 64 09:45:23.726143 IP 192.168.1.51 > 4.2.2.1: ICMP echo request, id 6417, seq 1, length 64 And compare this to what you're seeing (look closely at the 2nd line): 16:03:08.963292 IP 10.5.49.126 > 10.5.49.65: ICMP echo request, id 30477, seq 0, length 4076 16:03:09.968454 IP 10.5.49.126 > 10.5.49.65: icmp And that is what worries me -- it's like the actual packet contents (specifically the ICMP header portions) of the 2nd packet are getting mangled, thus tcpdump doesn't know the ICMP type, etc... This is why I said I want to see output from -xx and not -x. What I want to see is the *full packet contents* (IP header, ICMP header, and any ICMP payload). Please use the tcpdump command I showed above, with -i adjusted for your interface and/or a different destination IP, then use "ping -c 2 {destination IP}". Please don't edit the output in any way. Thanks. -- | Jeremy Chadwick jdc@koitsu.org | | UNIX Systems Administrator http://jdc.koitsu.org/ | | Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Wed Oct 24 17:00:57 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6F9F8709; Wed, 24 Oct 2012 17:00:57 +0000 (UTC) (envelope-from h.schmalzbauer@omnilan.de) Received: from host.omnilan.net (s1.omnilan.net [62.245.232.135]) by mx1.freebsd.org (Postfix) with ESMTP id D0B7B8FC14; Wed, 24 Oct 2012 17:00:56 +0000 (UTC) Received: from titan.inop.wdn.omnilan.net (titan.inop.wdn.omnilan.net [172.21.3.1]) (authenticated bits=0) by host.omnilan.net (8.13.8/8.13.8) with ESMTP id q9OH2I4A073293 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 24 Oct 2012 19:02:18 +0200 (CEST) (envelope-from h.schmalzbauer@omnilan.de) Message-ID: <50881EC7.9030400@omnilan.de> Date: Wed, 24 Oct 2012 19:00:55 +0200 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Jeremy Chadwick Subject: Re: every 2nd echo-request malformed when ping -s >4067 References: <20121024154017.GA3167@icarus.home.lan> <5088163E.2090506@omnilan.de> <20121024165148.GA4250@icarus.home.lan> In-Reply-To: <20121024165148.GA4250@icarus.home.lan> X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig71CB79B20954948157274845" Cc: Adrian Chadd , FreeBSD Stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 24 Oct 2012 17:00:57 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig71CB79B20954948157274845 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable schrieb Jeremy Chadwick am 24.10.2012 18:51 (localtime): > ... > # tcpdump -p -i em0 -l -n -s 0 -xx "icmp and dst host 4.2.2.1" > tcpdump: verbose output suppressed, use -v or -vv for full protocol dec= ode > listening on em0, link-type EN10MB (Ethernet), capture size 65535 bytes= > 09:45:22.725137 IP 192.168.1.51 > 4.2.2.1: ICMP echo request, id 6417, = seq 0, length 64 > 0x0000: e0cb 4ec0 00c4 0030 48d2 22d0=20 Have you ever seen "e0:cb:4e:c0:00:c4" and "00:30:48:d2:22:d0" ? These are your mac addresses, which -xx shows. =2E.. > And compare this to what you're seeing (look closely at the 2nd line): > > 16:03:08.963292 IP 10.5.49.126 > 10.5.49.65: ICMP echo request, id 3047= 7, seq 0, length 4076 > 16:03:09.968454 IP 10.5.49.126 > 10.5.49.65: icmp Of course, I saw that. That's why I claim the 2nd outgoing request to be malformed ;-) > ... > > This is why I said I want to see output from -xx and not -x. What I > want to see is the *full packet contents* (IP header, ICMP header, and > any ICMP payload). =20 -x gives everything above link-layer, so IP and ICMP are in my last dump.= Thanks, -Harry --------------enig71CB79B20954948157274845 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAlCIHscACgkQLDqVQ9VXb8h8LACglPxcdcQgiwaiI8Em3enHKObH zAkAoIlkaatp6or05i8PlZN8x3lCHmlP =XtMY -----END PGP SIGNATURE----- --------------enig71CB79B20954948157274845-- From owner-freebsd-stable@FreeBSD.ORG Wed Oct 24 17:24:13 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D2417F82; Wed, 24 Oct 2012 17:24:13 +0000 (UTC) (envelope-from fernando.apesteguia@gmail.com) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id 9E86C8FC08; Wed, 24 Oct 2012 17:24:12 +0000 (UTC) Received: by mail-lb0-f182.google.com with SMTP id b5so1579434lbd.13 for ; Wed, 24 Oct 2012 10:24:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=HOzwriNDMu+P+uMcqIMey6HRuzC0/Gt0jOJwjuka1fA=; b=ZPlCYlBjn9Dj6eLIePWLXJG/wb6BGTOvuAAb54CQo1IW9oJQAr+/HHC3k87N3tVFJs vJJp0E/S5GMUOlH/0w4+LiHqprQRF78K6f3/af+Q43EXHwqgb/t9sECvIACTfyn8ypDv JxmPreBCKg7/IzI+fDtrX8IJpc7dTpoIL57hkqsxeFjx7YbnAl5zqSpW8OYQbShqkEaE VxnAG2sa0asD+xcMK2trPQ8meajogDPTrRWmFiMcI4YttfW7Jkblre4KrE3yypEqUGHS 0Ez+2uJIP0/SZO8zjXW9X/Gtuwn2rzcI+D7t00OZThSwj8blYStHLZmJBgMAk1r83y3j A8Rw== MIME-Version: 1.0 Received: by 10.152.104.115 with SMTP id gd19mr15216952lab.13.1351099451004; Wed, 24 Oct 2012 10:24:11 -0700 (PDT) Received: by 10.152.1.193 with HTTP; Wed, 24 Oct 2012 10:24:10 -0700 (PDT) In-Reply-To: <20121024111144.GF82606@e-new.0x20.net> References: <20121016101957.GB53800@FreeBSD.org> <20121022174457.GB59689@FreeBSD.org> <5086AC06.5070405@a1poweruser.com> <5214043c002ef030f59c2045344b8725.squirrel@webmail.ee.ryerson.ca> <20121024111144.GF82606@e-new.0x20.net> Date: Wed, 24 Oct 2012 19:24:10 +0200 Message-ID: Subject: Re: FreeBSD in Google Code-In 2012? You can help too! From: =?ISO-8859-1?Q?Fernando_Apestegu=EDa?= To: Lars Engels Content-Type: text/plain; charset=ISO-8859-1 Cc: David Magda , freebsd-hackers@freebsd.org, Fbsd8 , "Wojciech A. Koszek" , Eitan Adler , freebsd-current@freebsd.org, freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 24 Oct 2012 17:24:13 -0000 On Wed, Oct 24, 2012 at 1:11 PM, Lars Engels wrote: > On Tue, Oct 23, 2012 at 03:59:07PM -0400, Eitan Adler wrote: >> On 23 October 2012 12:54, David Magda wrote: >> > On Tue, October 23, 2012 10:39, Fbsd8 wrote: >> >> >> >> The subject is Google Code-In and all the posted tasks are directed at >> >> creating documentation. Not one deals with coding any programs. If I was >> >> 15-17 years old I sure would not be interested in writing documentation. >> >> I would want to use and develop my coding skills. To that end there a >> >> lot of simple PR's waiting for attention. This is an target area that >> >> young coders would find more interesting. >> > >> > It would depend on what one's interests were. >> >> Google code-in is aimed at *coders* and there is an expectation of >> people writing *code*. >> >> The biggest complaint for GCI last year was "not enough coding tasks" > > What about creating a new port? That is some kind of coding. If we can > find some software that isn't ported, yet and not too hard to port (e.g. > the wanted ports page in the wiki) we could make a task proposal of it. > And one generic "create a port for a piece of software that hasn't been > ported, yet". > Feel free to add me as a mentor for such a task. Also related to that, what about writing a section about redports[1] in the porter's handbook[2]? And as a side question, shouldn't some (or all) of these tasks be listed also in JuniorTasks[3]? Just my two cents. [1] https://redports.org/ [2] http://www.freebsd.org/doc/en/books/porters-handbook/book.html [3] http://wiki.freebsd.org/JuniorJobs From owner-freebsd-stable@FreeBSD.ORG Wed Oct 24 17:37:22 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5CE91488 for ; Wed, 24 Oct 2012 17:37:22 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 0DF438FC16 for ; Wed, 24 Oct 2012 17:37:21 +0000 (UTC) Received: by mail-pb0-f54.google.com with SMTP id rp8so1470085pbb.13 for ; Wed, 24 Oct 2012 10:37:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=KrdJDo+pcjYR6/5ryVsuPYk+hCvdInek3KDVYgkK6p4=; b=OsBjSNj/w5LyPl5GLAmgvZzK5M/9OZp63yLEgoPzcMGd2TdmyIQvWnSDJdpR0zXfan OXTDaeDQ0xu+S0wGgX84S/Xj2XAKj5OymjPLSkKL2nkMLQYgxzBgKEHeq6EMwPCVZ5R8 vVq7iFD/+jUXCCnaQJgt4yJ+WtL5nc2wPsnIc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=KrdJDo+pcjYR6/5ryVsuPYk+hCvdInek3KDVYgkK6p4=; b=KE29ipWmxdbYQ5ZNFfLnkhZPT9UVgVqOqubL3eSzYkFFksH6wsVCK6L3dz++ykL4eu i4JLk86izTC1zdizKHGkZRoY3lhr41K3qATE67yhpw7Hxg+6wJS2zAmxqZr72qfG6F1H hGudcXbqFVA6LCzJWB3eSS74bxKgOa4I3Zl8LneZmDkwuCUvQOXb7u9b+5gqTXwzhjuV sZshFtEWbcqDzhHpKSXK0F6BrJz1WWy35Lxusem7qGPNM1Qg2QSYpdq0E0p/2u170xEG K63rE0Y5vpN2k7hFHgidyRJlmKz+2SYV08WahIIxlsrcCKhLLzO56h3RcARUdSRu4ZG8 UNSw== Received: by 10.68.200.72 with SMTP id jq8mr51724169pbc.38.1351100241489; Wed, 24 Oct 2012 10:37:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.161.163 with HTTP; Wed, 24 Oct 2012 10:36:51 -0700 (PDT) In-Reply-To: References: <20121016101957.GB53800@FreeBSD.org> <20121022174457.GB59689@FreeBSD.org> <5086AC06.5070405@a1poweruser.com> <5214043c002ef030f59c2045344b8725.squirrel@webmail.ee.ryerson.ca> <20121024111144.GF82606@e-new.0x20.net> From: Eitan Adler Date: Wed, 24 Oct 2012 13:36:51 -0400 Message-ID: Subject: Re: FreeBSD in Google Code-In 2012? You can help too! To: =?UTF-8?Q?Fernando_Apestegu=C3=ADa?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkNeh14+NnE0WCIZHfuUPhxeDJD6AQqSBHSsYnPCgUEx9cmtHV1H5Qr755qwVhwVQdyVkrk Cc: David Magda , Lars Engels , freebsd-hackers@freebsd.org, Fbsd8 , "Wojciech A. Koszek" , freebsd-current@freebsd.org, freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 24 Oct 2012 17:37:22 -0000 On 24 October 2012 13:24, Fernando Apestegu=C3=ADa wrote: > Also related to that, what about writing a section about redports[1] > in the porter's handbook[2]? This is a good documentation task... but we need more *coding* tasks as wel= l. > And as a side question, shouldn't some (or all) of these tasks be > listed also in JuniorTasks[3]? I'll link the page: good point. --=20 Eitan Adler From owner-freebsd-stable@FreeBSD.ORG Wed Oct 24 17:41:00 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 517477E2 for ; Wed, 24 Oct 2012 17:41:00 +0000 (UTC) (envelope-from sulfurfff@gmail.com) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by mx1.freebsd.org (Postfix) with ESMTP id D79D48FC12 for ; Wed, 24 Oct 2012 17:40:59 +0000 (UTC) Received: by mail-wi0-f178.google.com with SMTP id hr7so658008wib.13 for ; Wed, 24 Oct 2012 10:40:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=gTLtPf2hh6rL84p42ysjGV98may8kiWnOCAOFtNSOhs=; b=SIbpWWKSnRjVUqCWHIjCOuvyhPU8V9KQkWHV6gVCkkjMJoC9UkjKg+jLslqoeUpszl 3f1DF7Ddam9EcADs16lrqGTb8P9Hj6BknliEMyHnLYnitAi6r0SVvJWzM/QTI8kSMjOj He1jUKCi5W7BGciM3uEywDxKOiX+5UFnX0OmrmSykKYeWOeEkO/imhqeKPNG54taU5cg MxYWdplNiUx1OZO5l0H1rEcsbJKjj40V64SwLBaRH4sffux8uFdngz06r7LgBkmLQeNn uomSQMSr9bi8yl1iDe85clw438E7uQsYM3tuVeP5/e37eZPgrwM47vcwRpt4lRSC/wDe nZxg== MIME-Version: 1.0 Received: by 10.180.105.168 with SMTP id gn8mr7520693wib.10.1351100458802; Wed, 24 Oct 2012 10:40:58 -0700 (PDT) Received: by 10.194.109.226 with HTTP; Wed, 24 Oct 2012 10:40:58 -0700 (PDT) Date: Wed, 24 Oct 2012 12:40:58 -0500 Message-ID: Subject: cvsup + PAC proxy? From: =?UTF-8?Q?Ismael_Farf=C3=A1n?= To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 24 Oct 2012 17:41:00 -0000 Hello list Is it possible to use a proxy auto-config stript with cvsup? That would save me testing one by one which is the one used to access the cvsup servers. Does any of the CLI tools supports PAC? Regards Ismael -- Do not let me induce you to satisfy my curiosity, from an expectation, that I shall gratify yours. What I may judge proper to conceal, does not concern myself alone. From owner-freebsd-stable@FreeBSD.ORG Wed Oct 24 17:44:26 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A49E5A98 for ; Wed, 24 Oct 2012 17:44:26 +0000 (UTC) (envelope-from jdc@koitsu.strangled.net) Received: from qmta11.emeryville.ca.mail.comcast.net (qmta11.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:44:76:96:27:211]) by mx1.freebsd.org (Postfix) with ESMTP id 83B418FC12 for ; Wed, 24 Oct 2012 17:44:26 +0000 (UTC) Received: from omta05.emeryville.ca.mail.comcast.net ([76.96.30.43]) by qmta11.emeryville.ca.mail.comcast.net with comcast id F5221k00A0vp7WLAB5kSrC; Wed, 24 Oct 2012 17:44:26 +0000 Received: from koitsu.strangled.net ([67.180.84.87]) by omta05.emeryville.ca.mail.comcast.net with comcast id F5kR1k00H1t3BNj8R5kR2B; Wed, 24 Oct 2012 17:44:26 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 4F69673A1A; Wed, 24 Oct 2012 10:44:25 -0700 (PDT) Date: Wed, 24 Oct 2012 10:44:25 -0700 From: Jeremy Chadwick To: Harald Schmalzbauer Subject: Re: every 2nd echo-request malformed when ping -s >4067 Message-ID: <20121024174425.GA4699@icarus.home.lan> References: <20121024154017.GA3167@icarus.home.lan> <5088163E.2090506@omnilan.de> <20121024165148.GA4250@icarus.home.lan> <50881EC7.9030400@omnilan.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50881EC7.9030400@omnilan.de> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Adrian Chadd , FreeBSD Stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 24 Oct 2012 17:44:26 -0000 On Wed, Oct 24, 2012 at 07:00:55PM +0200, Harald Schmalzbauer wrote: > schrieb Jeremy Chadwick am 24.10.2012 18:51 (localtime): > > ... > > # tcpdump -p -i em0 -l -n -s 0 -xx "icmp and dst host 4.2.2.1" > > tcpdump: verbose output suppressed, use -v or -vv for full protocol decode > > listening on em0, link-type EN10MB (Ethernet), capture size 65535 bytes > > 09:45:22.725137 IP 192.168.1.51 > 4.2.2.1: ICMP echo request, id 6417, seq 0, length 64 > > 0x0000: e0cb 4ec0 00c4 0030 48d2 22d0 > Have you ever seen "e0:cb:4e:c0:00:c4" and "00:30:48:d2:22:d0" ? > These are your mac addresses, which -xx shows. > > ... > > And compare this to what you're seeing (look closely at the 2nd line): > > > > 16:03:08.963292 IP 10.5.49.126 > 10.5.49.65: ICMP echo request, id 30477, seq 0, length 4076 > > 16:03:09.968454 IP 10.5.49.126 > 10.5.49.65: icmp > > Of course, I saw that. That's why I claim the 2nd outgoing request to be > malformed ;-) > > > ... > > > > This is why I said I want to see output from -xx and not -x. What I > > want to see is the *full packet contents* (IP header, ICMP header, and > > any ICMP payload). > > -x gives everything above link-layer, so IP and ICMP are in my last dump. You're right -- sorry, *I* misread the tcpdump man page! :-) Here I am telling you what to do yet...... *laugh* Sorry about that. So I can tell from your original output that you're using "-x" by itself, so what we're seeing should be the IP header and related bits. Okay, so let's decode what you got. Too bad we don't have snoop-like output, since it can decode all of this and output it in a human-friendly way. Gotta do this by hand... 12:21:09.048447 IP 10.5.49.126 > 10.5.49.65: ICMP echo request, id 46597, seq 0, length 4076 0x0000: 4500 1000 0f2d 4000 4001 a507 0a05 317e 0x45 = bits 7-4: IPv4 protocol = bits 3-0: header length: 20 bytes 0x00 = DSF / RFC 2474 stuff (don't ask me :-) ) 0x1000 = datagram length: 4096 bytes 0x0f2d = fragment id 0x4000 = bits 15-13: %010 = reserved bit (0), DF bit (1), MF bit (0) = bits 12-0: fragment offset: 0 0x40 = TTL: 64 0x01 = protocol: 1 (ICMP) 0xe4c7 = header checksum 0x0a05317e = source IP Now for the malformed/wonky packet: 12:21:10.052891 IP 10.5.49.126 > 10.5.49.65: icmp 0x0000: 4500 1000 0f2d 0040 4001 e4c7 0a05 317e 0x45 = bits 7-4: IPv4 protocol = bits 3-0: header length: 20 bytes 0x00 = DSF / RFC 2474 stuff (don't ask me :-) ) 0x1000 = datagram length: 4096 bytes 0x0f2d = fragment id 0x0040 = bits 15-13: %000 = reserved bit (0), DF bit (0), MF bit (0) = bits 12-0: fragment offset: 64 0x40 = TTL: 64 0x01 = protocol: 1 (ICMP) 0xe4c7 = header checksum 0x0a05317e = source IP So from this we can tell that the working packets have the DF (dont-fragment) bit set and have a fragment offset of zero, and the "broken" packet has the DF bit cleared and a fragment offset of 64. Can you please re-run your tests with the following tcpdump arguments and provide full, non-edited output? Even WITHOUT "-s 0" to tcpdump you should be getting back multiple lines (0x0000, 0x0010, 0x0020, etc.), yet you've omitted the information I need to see. -- | Jeremy Chadwick jdc@koitsu.org | | UNIX Systems Administrator http://jdc.koitsu.org/ | | Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Wed Oct 24 17:49:40 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 56BE6C52 for ; Wed, 24 Oct 2012 17:49:40 +0000 (UTC) (envelope-from jdc@koitsu.strangled.net) Received: from qmta07.emeryville.ca.mail.comcast.net (qmta07.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:64]) by mx1.freebsd.org (Postfix) with ESMTP id 2E1398FC12 for ; Wed, 24 Oct 2012 17:49:40 +0000 (UTC) Received: from omta22.emeryville.ca.mail.comcast.net ([76.96.30.89]) by qmta07.emeryville.ca.mail.comcast.net with comcast id F4tc1k0021vN32cA75pgTK; Wed, 24 Oct 2012 17:49:40 +0000 Received: from koitsu.strangled.net ([67.180.84.87]) by omta22.emeryville.ca.mail.comcast.net with comcast id F5pf1k0051t3BNj8i5pfP9; Wed, 24 Oct 2012 17:49:39 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 2022B73A1A; Wed, 24 Oct 2012 10:49:39 -0700 (PDT) Date: Wed, 24 Oct 2012 10:49:39 -0700 From: Jeremy Chadwick To: Harald Schmalzbauer Subject: Re: every 2nd echo-request malformed when ping -s >4067 Message-ID: <20121024174939.GA5473@icarus.home.lan> References: <20121024154017.GA3167@icarus.home.lan> <5088163E.2090506@omnilan.de> <20121024165148.GA4250@icarus.home.lan> <50881EC7.9030400@omnilan.de> <20121024174425.GA4699@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20121024174425.GA4699@icarus.home.lan> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Adrian Chadd , FreeBSD Stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 24 Oct 2012 17:49:40 -0000 On Wed, Oct 24, 2012 at 10:44:25AM -0700, Jeremy Chadwick wrote: > On Wed, Oct 24, 2012 at 07:00:55PM +0200, Harald Schmalzbauer wrote: > > schrieb Jeremy Chadwick am 24.10.2012 18:51 (localtime): > > > ... > > > # tcpdump -p -i em0 -l -n -s 0 -xx "icmp and dst host 4.2.2.1" > > > tcpdump: verbose output suppressed, use -v or -vv for full protocol decode > > > listening on em0, link-type EN10MB (Ethernet), capture size 65535 bytes > > > 09:45:22.725137 IP 192.168.1.51 > 4.2.2.1: ICMP echo request, id 6417, seq 0, length 64 > > > 0x0000: e0cb 4ec0 00c4 0030 48d2 22d0 > > Have you ever seen "e0:cb:4e:c0:00:c4" and "00:30:48:d2:22:d0" ? > > These are your mac addresses, which -xx shows. > > > > ... > > > And compare this to what you're seeing (look closely at the 2nd line): > > > > > > 16:03:08.963292 IP 10.5.49.126 > 10.5.49.65: ICMP echo request, id 30477, seq 0, length 4076 > > > 16:03:09.968454 IP 10.5.49.126 > 10.5.49.65: icmp > > > > Of course, I saw that. That's why I claim the 2nd outgoing request to be > > malformed ;-) > > > > > ... > > > > > > This is why I said I want to see output from -xx and not -x. What I > > > want to see is the *full packet contents* (IP header, ICMP header, and > > > any ICMP payload). > > > > -x gives everything above link-layer, so IP and ICMP are in my last dump. > > You're right -- sorry, *I* misread the tcpdump man page! :-) Here I am > telling you what to do yet...... *laugh* Sorry about that. > > So I can tell from your original output that you're using "-x" by > itself, so what we're seeing should be the IP header and related bits. > > Okay, so let's decode what you got. Too bad we don't have snoop-like > output, since it can decode all of this and output it in a > human-friendly way. Gotta do this by hand... > > > 12:21:09.048447 IP 10.5.49.126 > 10.5.49.65: ICMP echo request, id 46597, seq 0, length 4076 > 0x0000: 4500 1000 0f2d 4000 4001 a507 0a05 317e > > 0x45 = bits 7-4: IPv4 protocol > = bits 3-0: header length: 20 bytes > 0x00 = DSF / RFC 2474 stuff (don't ask me :-) ) > 0x1000 = datagram length: 4096 bytes > 0x0f2d = fragment id > 0x4000 = bits 15-13: %010 = reserved bit (0), DF bit (1), MF bit (0) > = bits 12-0: fragment offset: 0 > 0x40 = TTL: 64 > 0x01 = protocol: 1 (ICMP) > 0xe4c7 = header checksum > 0x0a05317e = source IP > > Now for the malformed/wonky packet: > > 12:21:10.052891 IP 10.5.49.126 > 10.5.49.65: icmp > 0x0000: 4500 1000 0f2d 0040 4001 e4c7 0a05 317e > > 0x45 = bits 7-4: IPv4 protocol > = bits 3-0: header length: 20 bytes > 0x00 = DSF / RFC 2474 stuff (don't ask me :-) ) > 0x1000 = datagram length: 4096 bytes > 0x0f2d = fragment id > 0x0040 = bits 15-13: %000 = reserved bit (0), DF bit (0), MF bit (0) > = bits 12-0: fragment offset: 64 > 0x40 = TTL: 64 > 0x01 = protocol: 1 (ICMP) > 0xe4c7 = header checksum > 0x0a05317e = source IP > > So from this we can tell that the working packets have the DF > (dont-fragment) bit set and have a fragment offset of zero, and the > "broken" packet has the DF bit cleared and a fragment offset of 64. > > Can you please re-run your tests with the following tcpdump arguments > and provide full, non-edited output? > > Even WITHOUT "-s 0" to tcpdump you should be getting back multiple > lines (0x0000, 0x0010, 0x0020, etc.), yet you've omitted the information > I need to see. And an accidental vi/vim mistake on my part deleted the paragraph specifying the arguments. Doh! tcpdump -p -i {iface} -l -n -s 0 -x "{filter string}" -- | Jeremy Chadwick jdc@koitsu.org | | UNIX Systems Administrator http://jdc.koitsu.org/ | | Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Wed Oct 24 18:02:39 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2BF46F20; Wed, 24 Oct 2012 18:02:39 +0000 (UTC) (envelope-from h.schmalzbauer@omnilan.de) Received: from host.omnilan.net (s1.omnilan.net [62.245.232.135]) by mx1.freebsd.org (Postfix) with ESMTP id 8E7D18FC12; Wed, 24 Oct 2012 18:02:36 +0000 (UTC) Received: from titan.inop.wdn.omnilan.net (titan.inop.wdn.omnilan.net [172.21.3.1]) (authenticated bits=0) by host.omnilan.net (8.13.8/8.13.8) with ESMTP id q9OI3wxv074299 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 24 Oct 2012 20:03:58 +0200 (CEST) (envelope-from h.schmalzbauer@omnilan.de) Message-ID: <50882D3B.5050704@omnilan.de> Date: Wed, 24 Oct 2012 20:02:35 +0200 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Jeremy Chadwick Subject: Re: every 2nd echo-request malformed when ping -s >4067 References: <20121024154017.GA3167@icarus.home.lan> <5088163E.2090506@omnilan.de> <20121024165148.GA4250@icarus.home.lan> <50881EC7.9030400@omnilan.de> <20121024174425.GA4699@icarus.home.lan> In-Reply-To: <20121024174425.GA4699@icarus.home.lan> X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigD952E552B0EAA8F76A21B506" Cc: Adrian Chadd , FreeBSD Stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 24 Oct 2012 18:02:39 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigD952E552B0EAA8F76A21B506 Content-Type: multipart/mixed; boundary="------------040509080900070302010203" This is a multi-part message in MIME format. --------------040509080900070302010203 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable schrieb Jeremy Chadwick am 24.10.2012 19:44 (localtime): > ... > Okay, so let's decode what you got. Too bad we don't have snoop-like > output, since it can decode all of this and output it in a > human-friendly way. Gotta do this by hand... > > > 12:21:09.048447 IP 10.5.49.126 > 10.5.49.65: ICMP echo request, id 4659= 7, seq 0, length 4076 > 0x0000: 4500 1000 0f2d 4000 4001 a507 0a05 317e > > 0x45 =3D bits 7-4: IPv4 protocol > =3D bits 3-0: header length: 20 bytes > 0x00 =3D DSF / RFC 2474 stuff (don't ask me :-) ) > 0x1000 =3D datagram length: 4096 bytes > 0x0f2d =3D fragment id > 0x4000 =3D bits 15-13: %010 =3D reserved bit (0), DF bit (1), MF bi= t (0) > =3D bits 12-0: fragment offset: 0 > 0x40 =3D TTL: 64 > 0x01 =3D protocol: 1 (ICMP) > 0xe4c7 =3D header checksum > 0x0a05317e =3D source IP > > Now for the malformed/wonky packet: > > 12:21:10.052891 IP 10.5.49.126 > 10.5.49.65: icmp > 0x0000: 4500 1000 0f2d 0040 4001 e4c7 0a05 317e > > 0x45 =3D bits 7-4: IPv4 protocol > =3D bits 3-0: header length: 20 bytes > 0x00 =3D DSF / RFC 2474 stuff (don't ask me :-) ) > 0x1000 =3D datagram length: 4096 bytes > 0x0f2d =3D fragment id > 0x0040 =3D bits 15-13: %000 =3D reserved bit (0), DF bit (0), MF bi= t (0) > =3D bits 12-0: fragment offset: 64 > 0x40 =3D TTL: 64 > 0x01 =3D protocol: 1 (ICMP) > 0xe4c7 =3D header checksum > 0x0a05317e =3D source IP Thanks a lot for your effort! What do you use for decoding? Please find attached the requested info. Can you reproduce this oddity via your lo0? Or is 'ping -D -s 4068 127.0.0.1' working on your machine? Thanks, -Harry --------------040509080900070302010203 Content-Type: text/plain; name="4068paylod_icmp_echo-req.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="4068paylod_icmp_echo-req.txt" 17:58:08.481888 IP 10.5.49.126 > 10.5.49.65: ICMP echo request, id 49423,= seq 0, length 4076 0x0000: 4500 1000 1fff 4000 4001 9435 0a05 317e 0x0010: 0a05 3141 0800 a352 c10f 0000 5088 2c30 0x0020: 0007 5a3b 0809 0a0b 0c0d 0e0f 1011 1213 0x0030: 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 0x0040: 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 0x0050: 3435 3637 3839 3a3b 3c3d 3e3f 4041 4243 0x0060: 4445 4647 4849 4a4b 4c4d 4e4f 5051 5253 0x0070: 5455 5657 5859 5a5b 5c5d 5e5f 6061 6263 0x0080: 6465 6667 6869 6a6b 6c6d 6e6f 7071 7273 0x0090: 7475 7677 7879 7a7b 7c7d 7e7f 8081 8283 0x00a0: 8485 8687 8889 8a8b 8c8d 8e8f 9091 9293 0x00b0: 9495 9697 9899 9a9b 9c9d 9e9f a0a1 a2a3 0x00c0: a4a5 a6a7 a8a9 aaab acad aeaf b0b1 b2b3 0x00d0: b4b5 b6b7 b8b9 babb bcbd bebf c0c1 c2c3 0x00e0: c4c5 c6c7 c8c9 cacb cccd cecf d0d1 d2d3 0x00f0: d4d5 d6d7 d8d9 dadb dcdd dedf e0e1 e2e3 0x0100: e4e5 e6e7 e8e9 eaeb eced eeef f0f1 f2f3 0x0110: f4f5 f6f7 f8f9 fafb fcfd feff 0001 0203 0x0120: 0405 0607 0809 0a0b 0c0d 0e0f 1011 1213 0x0130: 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 0x0140: 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 0x0150: 3435 3637 3839 3a3b 3c3d 3e3f 4041 4243 0x0160: 4445 4647 4849 4a4b 4c4d 4e4f 5051 5253 0x0170: 5455 5657 5859 5a5b 5c5d 5e5f 6061 6263 0x0180: 6465 6667 6869 6a6b 6c6d 6e6f 7071 7273 0x0190: 7475 7677 7879 7a7b 7c7d 7e7f 8081 8283 0x01a0: 8485 8687 8889 8a8b 8c8d 8e8f 9091 9293 0x01b0: 9495 9697 9899 9a9b 9c9d 9e9f a0a1 a2a3 0x01c0: a4a5 a6a7 a8a9 aaab acad aeaf b0b1 b2b3 0x01d0: b4b5 b6b7 b8b9 babb bcbd bebf c0c1 c2c3 0x01e0: c4c5 c6c7 c8c9 cacb cccd cecf d0d1 d2d3 0x01f0: d4d5 d6d7 d8d9 dadb dcdd dedf e0e1 e2e3 0x0200: e4e5 e6e7 e8e9 eaeb eced eeef f0f1 f2f3 0x0210: f4f5 f6f7 f8f9 fafb fcfd feff 0001 0203 0x0220: 0405 0607 0809 0a0b 0c0d 0e0f 1011 1213 0x0230: 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 0x0240: 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 0x0250: 3435 3637 3839 3a3b 3c3d 3e3f 4041 4243 0x0260: 4445 4647 4849 4a4b 4c4d 4e4f 5051 5253 0x0270: 5455 5657 5859 5a5b 5c5d 5e5f 6061 6263 0x0280: 6465 6667 6869 6a6b 6c6d 6e6f 7071 7273 0x0290: 7475 7677 7879 7a7b 7c7d 7e7f 8081 8283 0x02a0: 8485 8687 8889 8a8b 8c8d 8e8f 9091 9293 0x02b0: 9495 9697 9899 9a9b 9c9d 9e9f a0a1 a2a3 0x02c0: a4a5 a6a7 a8a9 aaab acad aeaf b0b1 b2b3 0x02d0: b4b5 b6b7 b8b9 babb bcbd bebf c0c1 c2c3 0x02e0: c4c5 c6c7 c8c9 cacb cccd cecf d0d1 d2d3 0x02f0: d4d5 d6d7 d8d9 dadb dcdd dedf e0e1 e2e3 0x0300: e4e5 e6e7 e8e9 eaeb eced eeef f0f1 f2f3 0x0310: f4f5 f6f7 f8f9 fafb fcfd feff 0001 0203 0x0320: 0405 0607 0809 0a0b 0c0d 0e0f 1011 1213 0x0330: 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 0x0340: 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 0x0350: 3435 3637 3839 3a3b 3c3d 3e3f 4041 4243 0x0360: 4445 4647 4849 4a4b 4c4d 4e4f 5051 5253 0x0370: 5455 5657 5859 5a5b 5c5d 5e5f 6061 6263 0x0380: 6465 6667 6869 6a6b 6c6d 6e6f 7071 7273 0x0390: 7475 7677 7879 7a7b 7c7d 7e7f 8081 8283 0x03a0: 8485 8687 8889 8a8b 8c8d 8e8f 9091 9293 0x03b0: 9495 9697 9899 9a9b 9c9d 9e9f a0a1 a2a3 0x03c0: a4a5 a6a7 a8a9 aaab acad aeaf b0b1 b2b3 0x03d0: b4b5 b6b7 b8b9 babb bcbd bebf c0c1 c2c3 0x03e0: c4c5 c6c7 c8c9 cacb cccd cecf d0d1 d2d3 0x03f0: d4d5 d6d7 d8d9 dadb dcdd dedf e0e1 e2e3 0x0400: e4e5 e6e7 e8e9 eaeb eced eeef f0f1 f2f3 0x0410: f4f5 f6f7 f8f9 fafb fcfd feff 0001 0203 0x0420: 0405 0607 0809 0a0b 0c0d 0e0f 1011 1213 0x0430: 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 0x0440: 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 0x0450: 3435 3637 3839 3a3b 3c3d 3e3f 4041 4243 0x0460: 4445 4647 4849 4a4b 4c4d 4e4f 5051 5253 0x0470: 5455 5657 5859 5a5b 5c5d 5e5f 6061 6263 0x0480: 6465 6667 6869 6a6b 6c6d 6e6f 7071 7273 0x0490: 7475 7677 7879 7a7b 7c7d 7e7f 8081 8283 0x04a0: 8485 8687 8889 8a8b 8c8d 8e8f 9091 9293 0x04b0: 9495 9697 9899 9a9b 9c9d 9e9f a0a1 a2a3 0x04c0: a4a5 a6a7 a8a9 aaab acad aeaf b0b1 b2b3 0x04d0: b4b5 b6b7 b8b9 babb bcbd bebf c0c1 c2c3 0x04e0: c4c5 c6c7 c8c9 cacb cccd cecf d0d1 d2d3 0x04f0: d4d5 d6d7 d8d9 dadb dcdd dedf e0e1 e2e3 0x0500: e4e5 e6e7 e8e9 eaeb eced eeef f0f1 f2f3 0x0510: f4f5 f6f7 f8f9 fafb fcfd feff 0001 0203 0x0520: 0405 0607 0809 0a0b 0c0d 0e0f 1011 1213 0x0530: 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 0x0540: 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 0x0550: 3435 3637 3839 3a3b 3c3d 3e3f 4041 4243 0x0560: 4445 4647 4849 4a4b 4c4d 4e4f 5051 5253 0x0570: 5455 5657 5859 5a5b 5c5d 5e5f 6061 6263 0x0580: 6465 6667 6869 6a6b 6c6d 6e6f 7071 7273 0x0590: 7475 7677 7879 7a7b 7c7d 7e7f 8081 8283 0x05a0: 8485 8687 8889 8a8b 8c8d 8e8f 9091 9293 0x05b0: 9495 9697 9899 9a9b 9c9d 9e9f a0a1 a2a3 0x05c0: a4a5 a6a7 a8a9 aaab acad aeaf b0b1 b2b3 0x05d0: b4b5 b6b7 b8b9 babb bcbd bebf c0c1 c2c3 0x05e0: c4c5 c6c7 c8c9 cacb cccd cecf d0d1 d2d3 0x05f0: d4d5 d6d7 d8d9 dadb dcdd dedf e0e1 e2e3 0x0600: e4e5 e6e7 e8e9 eaeb eced eeef f0f1 f2f3 0x0610: f4f5 f6f7 f8f9 fafb fcfd feff 0001 0203 0x0620: 0405 0607 0809 0a0b 0c0d 0e0f 1011 1213 0x0630: 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 0x0640: 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 0x0650: 3435 3637 3839 3a3b 3c3d 3e3f 4041 4243 0x0660: 4445 4647 4849 4a4b 4c4d 4e4f 5051 5253 0x0670: 5455 5657 5859 5a5b 5c5d 5e5f 6061 6263 0x0680: 6465 6667 6869 6a6b 6c6d 6e6f 7071 7273 0x0690: 7475 7677 7879 7a7b 7c7d 7e7f 8081 8283 0x06a0: 8485 8687 8889 8a8b 8c8d 8e8f 9091 9293 0x06b0: 9495 9697 9899 9a9b 9c9d 9e9f a0a1 a2a3 0x06c0: a4a5 a6a7 a8a9 aaab acad aeaf b0b1 b2b3 0x06d0: b4b5 b6b7 b8b9 babb bcbd bebf c0c1 c2c3 0x06e0: c4c5 c6c7 c8c9 cacb cccd cecf d0d1 d2d3 0x06f0: d4d5 d6d7 d8d9 dadb dcdd dedf e0e1 e2e3 0x0700: e4e5 e6e7 e8e9 eaeb eced eeef f0f1 f2f3 0x0710: f4f5 f6f7 f8f9 fafb fcfd feff 0001 0203 0x0720: 0405 0607 0809 0a0b 0c0d 0e0f 1011 1213 0x0730: 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 0x0740: 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 0x0750: 3435 3637 3839 3a3b 3c3d 3e3f 4041 4243 0x0760: 4445 4647 4849 4a4b 4c4d 4e4f 5051 5253 0x0770: 5455 5657 5859 5a5b 5c5d 5e5f 6061 6263 0x0780: 6465 6667 6869 6a6b 6c6d 6e6f 7071 7273 0x0790: 7475 7677 7879 7a7b 7c7d 7e7f 8081 8283 0x07a0: 8485 8687 8889 8a8b 8c8d 8e8f 9091 9293 0x07b0: 9495 9697 9899 9a9b 9c9d 9e9f a0a1 a2a3 0x07c0: a4a5 a6a7 a8a9 aaab acad aeaf b0b1 b2b3 0x07d0: b4b5 b6b7 b8b9 babb bcbd bebf c0c1 c2c3 0x07e0: c4c5 c6c7 c8c9 cacb cccd cecf d0d1 d2d3 0x07f0: d4d5 d6d7 d8d9 dadb dcdd dedf e0e1 e2e3 0x0800: e4e5 e6e7 e8e9 eaeb eced eeef f0f1 f2f3 0x0810: f4f5 f6f7 f8f9 fafb fcfd feff 0001 0203 0x0820: 0405 0607 0809 0a0b 0c0d 0e0f 1011 1213 0x0830: 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 0x0840: 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 0x0850: 3435 3637 3839 3a3b 3c3d 3e3f 4041 4243 0x0860: 4445 4647 4849 4a4b 4c4d 4e4f 5051 5253 0x0870: 5455 5657 5859 5a5b 5c5d 5e5f 6061 6263 0x0880: 6465 6667 6869 6a6b 6c6d 6e6f 7071 7273 0x0890: 7475 7677 7879 7a7b 7c7d 7e7f 8081 8283 0x08a0: 8485 8687 8889 8a8b 8c8d 8e8f 9091 9293 0x08b0: 9495 9697 9899 9a9b 9c9d 9e9f a0a1 a2a3 0x08c0: a4a5 a6a7 a8a9 aaab acad aeaf b0b1 b2b3 0x08d0: b4b5 b6b7 b8b9 babb bcbd bebf c0c1 c2c3 0x08e0: c4c5 c6c7 c8c9 cacb cccd cecf d0d1 d2d3 0x08f0: d4d5 d6d7 d8d9 dadb dcdd dedf e0e1 e2e3 0x0900: e4e5 e6e7 e8e9 eaeb eced eeef f0f1 f2f3 0x0910: f4f5 f6f7 f8f9 fafb fcfd feff 0001 0203 0x0920: 0405 0607 0809 0a0b 0c0d 0e0f 1011 1213 0x0930: 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 0x0940: 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 0x0950: 3435 3637 3839 3a3b 3c3d 3e3f 4041 4243 0x0960: 4445 4647 4849 4a4b 4c4d 4e4f 5051 5253 0x0970: 5455 5657 5859 5a5b 5c5d 5e5f 6061 6263 0x0980: 6465 6667 6869 6a6b 6c6d 6e6f 7071 7273 0x0990: 7475 7677 7879 7a7b 7c7d 7e7f 8081 8283 0x09a0: 8485 8687 8889 8a8b 8c8d 8e8f 9091 9293 0x09b0: 9495 9697 9899 9a9b 9c9d 9e9f a0a1 a2a3 0x09c0: a4a5 a6a7 a8a9 aaab acad aeaf b0b1 b2b3 0x09d0: b4b5 b6b7 b8b9 babb bcbd bebf c0c1 c2c3 0x09e0: c4c5 c6c7 c8c9 cacb cccd cecf d0d1 d2d3 0x09f0: d4d5 d6d7 d8d9 dadb dcdd dedf e0e1 e2e3 0x0a00: e4e5 e6e7 e8e9 eaeb eced eeef f0f1 f2f3 0x0a10: f4f5 f6f7 f8f9 fafb fcfd feff 0001 0203 0x0a20: 0405 0607 0809 0a0b 0c0d 0e0f 1011 1213 0x0a30: 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 0x0a40: 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 0x0a50: 3435 3637 3839 3a3b 3c3d 3e3f 4041 4243 0x0a60: 4445 4647 4849 4a4b 4c4d 4e4f 5051 5253 0x0a70: 5455 5657 5859 5a5b 5c5d 5e5f 6061 6263 0x0a80: 6465 6667 6869 6a6b 6c6d 6e6f 7071 7273 0x0a90: 7475 7677 7879 7a7b 7c7d 7e7f 8081 8283 0x0aa0: 8485 8687 8889 8a8b 8c8d 8e8f 9091 9293 0x0ab0: 9495 9697 9899 9a9b 9c9d 9e9f a0a1 a2a3 0x0ac0: a4a5 a6a7 a8a9 aaab acad aeaf b0b1 b2b3 0x0ad0: b4b5 b6b7 b8b9 babb bcbd bebf c0c1 c2c3 0x0ae0: c4c5 c6c7 c8c9 cacb cccd cecf d0d1 d2d3 0x0af0: d4d5 d6d7 d8d9 dadb dcdd dedf e0e1 e2e3 0x0b00: e4e5 e6e7 e8e9 eaeb eced eeef f0f1 f2f3 0x0b10: f4f5 f6f7 f8f9 fafb fcfd feff 0001 0203 0x0b20: 0405 0607 0809 0a0b 0c0d 0e0f 1011 1213 0x0b30: 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 0x0b40: 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 0x0b50: 3435 3637 3839 3a3b 3c3d 3e3f 4041 4243 0x0b60: 4445 4647 4849 4a4b 4c4d 4e4f 5051 5253 0x0b70: 5455 5657 5859 5a5b 5c5d 5e5f 6061 6263 0x0b80: 6465 6667 6869 6a6b 6c6d 6e6f 7071 7273 0x0b90: 7475 7677 7879 7a7b 7c7d 7e7f 8081 8283 0x0ba0: 8485 8687 8889 8a8b 8c8d 8e8f 9091 9293 0x0bb0: 9495 9697 9899 9a9b 9c9d 9e9f a0a1 a2a3 0x0bc0: a4a5 a6a7 a8a9 aaab acad aeaf b0b1 b2b3 0x0bd0: b4b5 b6b7 b8b9 babb bcbd bebf c0c1 c2c3 0x0be0: c4c5 c6c7 c8c9 cacb cccd cecf d0d1 d2d3 0x0bf0: d4d5 d6d7 d8d9 dadb dcdd dedf e0e1 e2e3 0x0c00: e4e5 e6e7 e8e9 eaeb eced eeef f0f1 f2f3 0x0c10: f4f5 f6f7 f8f9 fafb fcfd feff 0001 0203 0x0c20: 0405 0607 0809 0a0b 0c0d 0e0f 1011 1213 0x0c30: 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 0x0c40: 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 0x0c50: 3435 3637 3839 3a3b 3c3d 3e3f 4041 4243 0x0c60: 4445 4647 4849 4a4b 4c4d 4e4f 5051 5253 0x0c70: 5455 5657 5859 5a5b 5c5d 5e5f 6061 6263 0x0c80: 6465 6667 6869 6a6b 6c6d 6e6f 7071 7273 0x0c90: 7475 7677 7879 7a7b 7c7d 7e7f 8081 8283 0x0ca0: 8485 8687 8889 8a8b 8c8d 8e8f 9091 9293 0x0cb0: 9495 9697 9899 9a9b 9c9d 9e9f a0a1 a2a3 0x0cc0: a4a5 a6a7 a8a9 aaab acad aeaf b0b1 b2b3 0x0cd0: b4b5 b6b7 b8b9 babb bcbd bebf c0c1 c2c3 0x0ce0: c4c5 c6c7 c8c9 cacb cccd cecf d0d1 d2d3 0x0cf0: d4d5 d6d7 d8d9 dadb dcdd dedf e0e1 e2e3 0x0d00: e4e5 e6e7 e8e9 eaeb eced eeef f0f1 f2f3 0x0d10: f4f5 f6f7 f8f9 fafb fcfd feff 0001 0203 0x0d20: 0405 0607 0809 0a0b 0c0d 0e0f 1011 1213 0x0d30: 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 0x0d40: 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 0x0d50: 3435 3637 3839 3a3b 3c3d 3e3f 4041 4243 0x0d60: 4445 4647 4849 4a4b 4c4d 4e4f 5051 5253 0x0d70: 5455 5657 5859 5a5b 5c5d 5e5f 6061 6263 0x0d80: 6465 6667 6869 6a6b 6c6d 6e6f 7071 7273 0x0d90: 7475 7677 7879 7a7b 7c7d 7e7f 8081 8283 0x0da0: 8485 8687 8889 8a8b 8c8d 8e8f 9091 9293 0x0db0: 9495 9697 9899 9a9b 9c9d 9e9f a0a1 a2a3 0x0dc0: a4a5 a6a7 a8a9 aaab acad aeaf b0b1 b2b3 0x0dd0: b4b5 b6b7 b8b9 babb bcbd bebf c0c1 c2c3 0x0de0: c4c5 c6c7 c8c9 cacb cccd cecf d0d1 d2d3 0x0df0: d4d5 d6d7 d8d9 dadb dcdd dedf e0e1 e2e3 0x0e00: e4e5 e6e7 e8e9 eaeb eced eeef f0f1 f2f3 0x0e10: f4f5 f6f7 f8f9 fafb fcfd feff 0001 0203 0x0e20: 0405 0607 0809 0a0b 0c0d 0e0f 1011 1213 0x0e30: 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 0x0e40: 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 0x0e50: 3435 3637 3839 3a3b 3c3d 3e3f 4041 4243 0x0e60: 4445 4647 4849 4a4b 4c4d 4e4f 5051 5253 0x0e70: 5455 5657 5859 5a5b 5c5d 5e5f 6061 6263 0x0e80: 6465 6667 6869 6a6b 6c6d 6e6f 7071 7273 0x0e90: 7475 7677 7879 7a7b 7c7d 7e7f 8081 8283 0x0ea0: 8485 8687 8889 8a8b 8c8d 8e8f 9091 9293 0x0eb0: 9495 9697 9899 9a9b 9c9d 9e9f a0a1 a2a3 0x0ec0: a4a5 a6a7 a8a9 aaab acad aeaf b0b1 b2b3 0x0ed0: b4b5 b6b7 b8b9 babb bcbd bebf c0c1 c2c3 0x0ee0: c4c5 c6c7 c8c9 cacb cccd cecf d0d1 d2d3 0x0ef0: d4d5 d6d7 d8d9 dadb dcdd dedf e0e1 e2e3 0x0f00: e4e5 e6e7 e8e9 eaeb eced eeef f0f1 f2f3 0x0f10: f4f5 f6f7 f8f9 fafb fcfd feff 0001 0203 0x0f20: 0405 0607 0809 0a0b 0c0d 0e0f 1011 1213 0x0f30: 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 0x0f40: 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 0x0f50: 3435 3637 3839 3a3b 3c3d 3e3f 4041 4243 0x0f60: 4445 4647 4849 4a4b 4c4d 4e4f 5051 5253 0x0f70: 5455 5657 5859 5a5b 5c5d 5e5f 6061 6263 0x0f80: 6465 6667 6869 6a6b 6c6d 6e6f 7071 7273 0x0f90: 7475 7677 7879 7a7b 7c7d 7e7f 8081 8283 0x0fa0: 8485 8687 8889 8a8b 8c8d 8e8f 9091 9293 0x0fb0: 9495 9697 9899 9a9b 9c9d 9e9f a0a1 a2a3 0x0fc0: a4a5 a6a7 a8a9 aaab acad aeaf b0b1 b2b3 0x0fd0: b4b5 b6b7 b8b9 babb bcbd bebf c0c1 c2c3 0x0fe0: c4c5 c6c7 c8c9 cacb cccd cecf d0d1 d2d3 0x0ff0: d4d5 d6d7 d8d9 dadb dcdd dedf e0e1 e2e3 17:58:09.488461 IP 10.5.49.126 > 10.5.49.65: icmp 0x0000: 4500 1000 1fff 0040 4001 d3f5 0a05 317e 0x0010: 0a05 3141 0800 8998 c10f 0001 5088 2c31 0x0020: 0007 73f3 0809 0a0b 0c0d 0e0f 1011 1213 0x0030: 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 0x0040: 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 0x0050: 3435 3637 3839 3a3b 3c3d 3e3f 4041 4243 0x0060: 4445 4647 4849 4a4b 4c4d 4e4f 5051 5253 0x0070: 5455 5657 5859 5a5b 5c5d 5e5f 6061 6263 0x0080: 6465 6667 6869 6a6b 6c6d 6e6f 7071 7273 0x0090: 7475 7677 7879 7a7b 7c7d 7e7f 8081 8283 0x00a0: 8485 8687 8889 8a8b 8c8d 8e8f 9091 9293 0x00b0: 9495 9697 9899 9a9b 9c9d 9e9f a0a1 a2a3 0x00c0: a4a5 a6a7 a8a9 aaab acad aeaf b0b1 b2b3 0x00d0: b4b5 b6b7 b8b9 babb bcbd bebf c0c1 c2c3 0x00e0: c4c5 c6c7 c8c9 cacb cccd cecf d0d1 d2d3 0x00f0: d4d5 d6d7 d8d9 dadb dcdd dedf e0e1 e2e3 0x0100: e4e5 e6e7 e8e9 eaeb eced eeef f0f1 f2f3 0x0110: f4f5 f6f7 f8f9 fafb fcfd feff 0001 0203 0x0120: 0405 0607 0809 0a0b 0c0d 0e0f 1011 1213 0x0130: 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 0x0140: 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 0x0150: 3435 3637 3839 3a3b 3c3d 3e3f 4041 4243 0x0160: 4445 4647 4849 4a4b 4c4d 4e4f 5051 5253 0x0170: 5455 5657 5859 5a5b 5c5d 5e5f 6061 6263 0x0180: 6465 6667 6869 6a6b 6c6d 6e6f 7071 7273 0x0190: 7475 7677 7879 7a7b 7c7d 7e7f 8081 8283 0x01a0: 8485 8687 8889 8a8b 8c8d 8e8f 9091 9293 0x01b0: 9495 9697 9899 9a9b 9c9d 9e9f a0a1 a2a3 0x01c0: a4a5 a6a7 a8a9 aaab acad aeaf b0b1 b2b3 0x01d0: b4b5 b6b7 b8b9 babb bcbd bebf c0c1 c2c3 0x01e0: c4c5 c6c7 c8c9 cacb cccd cecf d0d1 d2d3 0x01f0: d4d5 d6d7 d8d9 dadb dcdd dedf e0e1 e2e3 0x0200: e4e5 e6e7 e8e9 eaeb eced eeef f0f1 f2f3 0x0210: f4f5 f6f7 f8f9 fafb fcfd feff 0001 0203 0x0220: 0405 0607 0809 0a0b 0c0d 0e0f 1011 1213 0x0230: 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 0x0240: 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 0x0250: 3435 3637 3839 3a3b 3c3d 3e3f 4041 4243 0x0260: 4445 4647 4849 4a4b 4c4d 4e4f 5051 5253 0x0270: 5455 5657 5859 5a5b 5c5d 5e5f 6061 6263 0x0280: 6465 6667 6869 6a6b 6c6d 6e6f 7071 7273 0x0290: 7475 7677 7879 7a7b 7c7d 7e7f 8081 8283 0x02a0: 8485 8687 8889 8a8b 8c8d 8e8f 9091 9293 0x02b0: 9495 9697 9899 9a9b 9c9d 9e9f a0a1 a2a3 0x02c0: a4a5 a6a7 a8a9 aaab acad aeaf b0b1 b2b3 0x02d0: b4b5 b6b7 b8b9 babb bcbd bebf c0c1 c2c3 0x02e0: c4c5 c6c7 c8c9 cacb cccd cecf d0d1 d2d3 0x02f0: d4d5 d6d7 d8d9 dadb dcdd dedf e0e1 e2e3 0x0300: e4e5 e6e7 e8e9 eaeb eced eeef f0f1 f2f3 0x0310: f4f5 f6f7 f8f9 fafb fcfd feff 0001 0203 0x0320: 0405 0607 0809 0a0b 0c0d 0e0f 1011 1213 0x0330: 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 0x0340: 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 0x0350: 3435 3637 3839 3a3b 3c3d 3e3f 4041 4243 0x0360: 4445 4647 4849 4a4b 4c4d 4e4f 5051 5253 0x0370: 5455 5657 5859 5a5b 5c5d 5e5f 6061 6263 0x0380: 6465 6667 6869 6a6b 6c6d 6e6f 7071 7273 0x0390: 7475 7677 7879 7a7b 7c7d 7e7f 8081 8283 0x03a0: 8485 8687 8889 8a8b 8c8d 8e8f 9091 9293 0x03b0: 9495 9697 9899 9a9b 9c9d 9e9f a0a1 a2a3 0x03c0: a4a5 a6a7 a8a9 aaab acad aeaf b0b1 b2b3 0x03d0: b4b5 b6b7 b8b9 babb bcbd bebf c0c1 c2c3 0x03e0: c4c5 c6c7 c8c9 cacb cccd cecf d0d1 d2d3 0x03f0: d4d5 d6d7 d8d9 dadb dcdd dedf e0e1 e2e3 0x0400: e4e5 e6e7 e8e9 eaeb eced eeef f0f1 f2f3 0x0410: f4f5 f6f7 f8f9 fafb fcfd feff 0001 0203 0x0420: 0405 0607 0809 0a0b 0c0d 0e0f 1011 1213 0x0430: 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 0x0440: 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 0x0450: 3435 3637 3839 3a3b 3c3d 3e3f 4041 4243 0x0460: 4445 4647 4849 4a4b 4c4d 4e4f 5051 5253 0x0470: 5455 5657 5859 5a5b 5c5d 5e5f 6061 6263 0x0480: 6465 6667 6869 6a6b 6c6d 6e6f 7071 7273 0x0490: 7475 7677 7879 7a7b 7c7d 7e7f 8081 8283 0x04a0: 8485 8687 8889 8a8b 8c8d 8e8f 9091 9293 0x04b0: 9495 9697 9899 9a9b 9c9d 9e9f a0a1 a2a3 0x04c0: a4a5 a6a7 a8a9 aaab acad aeaf b0b1 b2b3 0x04d0: b4b5 b6b7 b8b9 babb bcbd bebf c0c1 c2c3 0x04e0: c4c5 c6c7 c8c9 cacb cccd cecf d0d1 d2d3 0x04f0: d4d5 d6d7 d8d9 dadb dcdd dedf e0e1 e2e3 0x0500: e4e5 e6e7 e8e9 eaeb eced eeef f0f1 f2f3 0x0510: f4f5 f6f7 f8f9 fafb fcfd feff 0001 0203 0x0520: 0405 0607 0809 0a0b 0c0d 0e0f 1011 1213 0x0530: 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 0x0540: 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 0x0550: 3435 3637 3839 3a3b 3c3d 3e3f 4041 4243 0x0560: 4445 4647 4849 4a4b 4c4d 4e4f 5051 5253 0x0570: 5455 5657 5859 5a5b 5c5d 5e5f 6061 6263 0x0580: 6465 6667 6869 6a6b 6c6d 6e6f 7071 7273 0x0590: 7475 7677 7879 7a7b 7c7d 7e7f 8081 8283 0x05a0: 8485 8687 8889 8a8b 8c8d 8e8f 9091 9293 0x05b0: 9495 9697 9899 9a9b 9c9d 9e9f a0a1 a2a3 0x05c0: a4a5 a6a7 a8a9 aaab acad aeaf b0b1 b2b3 0x05d0: b4b5 b6b7 b8b9 babb bcbd bebf c0c1 c2c3 0x05e0: c4c5 c6c7 c8c9 cacb cccd cecf d0d1 d2d3 0x05f0: d4d5 d6d7 d8d9 dadb dcdd dedf e0e1 e2e3 0x0600: e4e5 e6e7 e8e9 eaeb eced eeef f0f1 f2f3 0x0610: f4f5 f6f7 f8f9 fafb fcfd feff 0001 0203 0x0620: 0405 0607 0809 0a0b 0c0d 0e0f 1011 1213 0x0630: 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 0x0640: 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 0x0650: 3435 3637 3839 3a3b 3c3d 3e3f 4041 4243 0x0660: 4445 4647 4849 4a4b 4c4d 4e4f 5051 5253 0x0670: 5455 5657 5859 5a5b 5c5d 5e5f 6061 6263 0x0680: 6465 6667 6869 6a6b 6c6d 6e6f 7071 7273 0x0690: 7475 7677 7879 7a7b 7c7d 7e7f 8081 8283 0x06a0: 8485 8687 8889 8a8b 8c8d 8e8f 9091 9293 0x06b0: 9495 9697 9899 9a9b 9c9d 9e9f a0a1 a2a3 0x06c0: a4a5 a6a7 a8a9 aaab acad aeaf b0b1 b2b3 0x06d0: b4b5 b6b7 b8b9 babb bcbd bebf c0c1 c2c3 0x06e0: c4c5 c6c7 c8c9 cacb cccd cecf d0d1 d2d3 0x06f0: d4d5 d6d7 d8d9 dadb dcdd dedf e0e1 e2e3 0x0700: e4e5 e6e7 e8e9 eaeb eced eeef f0f1 f2f3 0x0710: f4f5 f6f7 f8f9 fafb fcfd feff 0001 0203 0x0720: 0405 0607 0809 0a0b 0c0d 0e0f 1011 1213 0x0730: 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 0x0740: 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 0x0750: 3435 3637 3839 3a3b 3c3d 3e3f 4041 4243 0x0760: 4445 4647 4849 4a4b 4c4d 4e4f 5051 5253 0x0770: 5455 5657 5859 5a5b 5c5d 5e5f 6061 6263 0x0780: 6465 6667 6869 6a6b 6c6d 6e6f 7071 7273 0x0790: 7475 7677 7879 7a7b 7c7d 7e7f 8081 8283 0x07a0: 8485 8687 8889 8a8b 8c8d 8e8f 9091 9293 0x07b0: 9495 9697 9899 9a9b 9c9d 9e9f a0a1 a2a3 0x07c0: a4a5 a6a7 a8a9 aaab acad aeaf b0b1 b2b3 0x07d0: b4b5 b6b7 b8b9 babb bcbd bebf c0c1 c2c3 0x07e0: c4c5 c6c7 c8c9 cacb cccd cecf d0d1 d2d3 0x07f0: d4d5 d6d7 d8d9 dadb dcdd dedf e0e1 e2e3 0x0800: e4e5 e6e7 e8e9 eaeb eced eeef f0f1 f2f3 0x0810: f4f5 f6f7 f8f9 fafb fcfd feff 0001 0203 0x0820: 0405 0607 0809 0a0b 0c0d 0e0f 1011 1213 0x0830: 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 0x0840: 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 0x0850: 3435 3637 3839 3a3b 3c3d 3e3f 4041 4243 0x0860: 4445 4647 4849 4a4b 4c4d 4e4f 5051 5253 0x0870: 5455 5657 5859 5a5b 5c5d 5e5f 6061 6263 0x0880: 6465 6667 6869 6a6b 6c6d 6e6f 7071 7273 0x0890: 7475 7677 7879 7a7b 7c7d 7e7f 8081 8283 0x08a0: 8485 8687 8889 8a8b 8c8d 8e8f 9091 9293 0x08b0: 9495 9697 9899 9a9b 9c9d 9e9f a0a1 a2a3 0x08c0: a4a5 a6a7 a8a9 aaab acad aeaf b0b1 b2b3 0x08d0: b4b5 b6b7 b8b9 babb bcbd bebf c0c1 c2c3 0x08e0: c4c5 c6c7 c8c9 cacb cccd cecf d0d1 d2d3 0x08f0: d4d5 d6d7 d8d9 dadb dcdd dedf e0e1 e2e3 0x0900: e4e5 e6e7 e8e9 eaeb eced eeef f0f1 f2f3 0x0910: f4f5 f6f7 f8f9 fafb fcfd feff 0001 0203 0x0920: 0405 0607 0809 0a0b 0c0d 0e0f 1011 1213 0x0930: 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 0x0940: 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 0x0950: 3435 3637 3839 3a3b 3c3d 3e3f 4041 4243 0x0960: 4445 4647 4849 4a4b 4c4d 4e4f 5051 5253 0x0970: 5455 5657 5859 5a5b 5c5d 5e5f 6061 6263 0x0980: 6465 6667 6869 6a6b 6c6d 6e6f 7071 7273 0x0990: 7475 7677 7879 7a7b 7c7d 7e7f 8081 8283 0x09a0: 8485 8687 8889 8a8b 8c8d 8e8f 9091 9293 0x09b0: 9495 9697 9899 9a9b 9c9d 9e9f a0a1 a2a3 0x09c0: a4a5 a6a7 a8a9 aaab acad aeaf b0b1 b2b3 0x09d0: b4b5 b6b7 b8b9 babb bcbd bebf c0c1 c2c3 0x09e0: c4c5 c6c7 c8c9 cacb cccd cecf d0d1 d2d3 0x09f0: d4d5 d6d7 d8d9 dadb dcdd dedf e0e1 e2e3 0x0a00: e4e5 e6e7 e8e9 eaeb eced eeef f0f1 f2f3 0x0a10: f4f5 f6f7 f8f9 fafb fcfd feff 0001 0203 0x0a20: 0405 0607 0809 0a0b 0c0d 0e0f 1011 1213 0x0a30: 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 0x0a40: 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 0x0a50: 3435 3637 3839 3a3b 3c3d 3e3f 4041 4243 0x0a60: 4445 4647 4849 4a4b 4c4d 4e4f 5051 5253 0x0a70: 5455 5657 5859 5a5b 5c5d 5e5f 6061 6263 0x0a80: 6465 6667 6869 6a6b 6c6d 6e6f 7071 7273 0x0a90: 7475 7677 7879 7a7b 7c7d 7e7f 8081 8283 0x0aa0: 8485 8687 8889 8a8b 8c8d 8e8f 9091 9293 0x0ab0: 9495 9697 9899 9a9b 9c9d 9e9f a0a1 a2a3 0x0ac0: a4a5 a6a7 a8a9 aaab acad aeaf b0b1 b2b3 0x0ad0: b4b5 b6b7 b8b9 babb bcbd bebf c0c1 c2c3 0x0ae0: c4c5 c6c7 c8c9 cacb cccd cecf d0d1 d2d3 0x0af0: d4d5 d6d7 d8d9 dadb dcdd dedf e0e1 e2e3 0x0b00: e4e5 e6e7 e8e9 eaeb eced eeef f0f1 f2f3 0x0b10: f4f5 f6f7 f8f9 fafb fcfd feff 0001 0203 0x0b20: 0405 0607 0809 0a0b 0c0d 0e0f 1011 1213 0x0b30: 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 0x0b40: 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 0x0b50: 3435 3637 3839 3a3b 3c3d 3e3f 4041 4243 0x0b60: 4445 4647 4849 4a4b 4c4d 4e4f 5051 5253 0x0b70: 5455 5657 5859 5a5b 5c5d 5e5f 6061 6263 0x0b80: 6465 6667 6869 6a6b 6c6d 6e6f 7071 7273 0x0b90: 7475 7677 7879 7a7b 7c7d 7e7f 8081 8283 0x0ba0: 8485 8687 8889 8a8b 8c8d 8e8f 9091 9293 0x0bb0: 9495 9697 9899 9a9b 9c9d 9e9f a0a1 a2a3 0x0bc0: a4a5 a6a7 a8a9 aaab acad aeaf b0b1 b2b3 0x0bd0: b4b5 b6b7 b8b9 babb bcbd bebf c0c1 c2c3 0x0be0: c4c5 c6c7 c8c9 cacb cccd cecf d0d1 d2d3 0x0bf0: d4d5 d6d7 d8d9 dadb dcdd dedf e0e1 e2e3 0x0c00: e4e5 e6e7 e8e9 eaeb eced eeef f0f1 f2f3 0x0c10: f4f5 f6f7 f8f9 fafb fcfd feff 0001 0203 0x0c20: 0405 0607 0809 0a0b 0c0d 0e0f 1011 1213 0x0c30: 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 0x0c40: 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 0x0c50: 3435 3637 3839 3a3b 3c3d 3e3f 4041 4243 0x0c60: 4445 4647 4849 4a4b 4c4d 4e4f 5051 5253 0x0c70: 5455 5657 5859 5a5b 5c5d 5e5f 6061 6263 0x0c80: 6465 6667 6869 6a6b 6c6d 6e6f 7071 7273 0x0c90: 7475 7677 7879 7a7b 7c7d 7e7f 8081 8283 0x0ca0: 8485 8687 8889 8a8b 8c8d 8e8f 9091 9293 0x0cb0: 9495 9697 9899 9a9b 9c9d 9e9f a0a1 a2a3 0x0cc0: a4a5 a6a7 a8a9 aaab acad aeaf b0b1 b2b3 0x0cd0: b4b5 b6b7 b8b9 babb bcbd bebf c0c1 c2c3 0x0ce0: c4c5 c6c7 c8c9 cacb cccd cecf d0d1 d2d3 0x0cf0: d4d5 d6d7 d8d9 dadb dcdd dedf e0e1 e2e3 0x0d00: e4e5 e6e7 e8e9 eaeb eced eeef f0f1 f2f3 0x0d10: f4f5 f6f7 f8f9 fafb fcfd feff 0001 0203 0x0d20: 0405 0607 0809 0a0b 0c0d 0e0f 1011 1213 0x0d30: 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 0x0d40: 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 0x0d50: 3435 3637 3839 3a3b 3c3d 3e3f 4041 4243 0x0d60: 4445 4647 4849 4a4b 4c4d 4e4f 5051 5253 0x0d70: 5455 5657 5859 5a5b 5c5d 5e5f 6061 6263 0x0d80: 6465 6667 6869 6a6b 6c6d 6e6f 7071 7273 0x0d90: 7475 7677 7879 7a7b 7c7d 7e7f 8081 8283 0x0da0: 8485 8687 8889 8a8b 8c8d 8e8f 9091 9293 0x0db0: 9495 9697 9899 9a9b 9c9d 9e9f a0a1 a2a3 0x0dc0: a4a5 a6a7 a8a9 aaab acad aeaf b0b1 b2b3 0x0dd0: b4b5 b6b7 b8b9 babb bcbd bebf c0c1 c2c3 0x0de0: c4c5 c6c7 c8c9 cacb cccd cecf d0d1 d2d3 0x0df0: d4d5 d6d7 d8d9 dadb dcdd dedf e0e1 e2e3 0x0e00: e4e5 e6e7 e8e9 eaeb eced eeef f0f1 f2f3 0x0e10: f4f5 f6f7 f8f9 fafb fcfd feff 0001 0203 0x0e20: 0405 0607 0809 0a0b 0c0d 0e0f 1011 1213 0x0e30: 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 0x0e40: 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 0x0e50: 3435 3637 3839 3a3b 3c3d 3e3f 4041 4243 0x0e60: 4445 4647 4849 4a4b 4c4d 4e4f 5051 5253 0x0e70: 5455 5657 5859 5a5b 5c5d 5e5f 6061 6263 0x0e80: 6465 6667 6869 6a6b 6c6d 6e6f 7071 7273 0x0e90: 7475 7677 7879 7a7b 7c7d 7e7f 8081 8283 0x0ea0: 8485 8687 8889 8a8b 8c8d 8e8f 9091 9293 0x0eb0: 9495 9697 9899 9a9b 9c9d 9e9f a0a1 a2a3 0x0ec0: a4a5 a6a7 a8a9 aaab acad aeaf b0b1 b2b3 0x0ed0: b4b5 b6b7 b8b9 babb bcbd bebf c0c1 c2c3 0x0ee0: c4c5 c6c7 c8c9 cacb cccd cecf d0d1 d2d3 0x0ef0: d4d5 d6d7 d8d9 dadb dcdd dedf e0e1 e2e3 0x0f00: e4e5 e6e7 e8e9 eaeb eced eeef f0f1 f2f3 0x0f10: f4f5 f6f7 f8f9 fafb fcfd feff 0001 0203 0x0f20: 0405 0607 0809 0a0b 0c0d 0e0f 1011 1213 0x0f30: 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 0x0f40: 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 0x0f50: 3435 3637 3839 3a3b 3c3d 3e3f 4041 4243 0x0f60: 4445 4647 4849 4a4b 4c4d 4e4f 5051 5253 0x0f70: 5455 5657 5859 5a5b 5c5d 5e5f 6061 6263 0x0f80: 6465 6667 6869 6a6b 6c6d 6e6f 7071 7273 0x0f90: 7475 7677 7879 7a7b 7c7d 7e7f 8081 8283 0x0fa0: 8485 8687 8889 8a8b 8c8d 8e8f 9091 9293 0x0fb0: 9495 9697 9899 9a9b 9c9d 9e9f a0a1 a2a3 0x0fc0: a4a5 a6a7 a8a9 aaab acad aeaf b0b1 b2b3 0x0fd0: b4b5 b6b7 b8b9 babb bcbd bebf c0c1 c2c3 0x0fe0: c4c5 c6c7 c8c9 cacb cccd cecf d0d1 d2d3 0x0ff0: d4d5 d6d7 d8d9 dadb dcdd dedf e0e1 e2e3 17:58:10.498465 IP 10.5.49.126 > 10.5.49.65: ICMP echo request, id 49423,= seq 2, length 4076 0x0000: 4500 1000 1fff 4000 4001 9435 0a05 317e 0x0010: 0a05 3141 0800 6288 c10f 0002 5088 2c32 0x0020: 0007 9b01 0809 0a0b 0c0d 0e0f 1011 1213 0x0030: 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 0x0040: 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 0x0050: 3435 3637 3839 3a3b 3c3d 3e3f 4041 4243 0x0060: 4445 4647 4849 4a4b 4c4d 4e4f 5051 5253 0x0070: 5455 5657 5859 5a5b 5c5d 5e5f 6061 6263 0x0080: 6465 6667 6869 6a6b 6c6d 6e6f 7071 7273 0x0090: 7475 7677 7879 7a7b 7c7d 7e7f 8081 8283 0x00a0: 8485 8687 8889 8a8b 8c8d 8e8f 9091 9293 0x00b0: 9495 9697 9899 9a9b 9c9d 9e9f a0a1 a2a3 0x00c0: a4a5 a6a7 a8a9 aaab acad aeaf b0b1 b2b3 0x00d0: b4b5 b6b7 b8b9 babb bcbd bebf c0c1 c2c3 0x00e0: c4c5 c6c7 c8c9 cacb cccd cecf d0d1 d2d3 0x00f0: d4d5 d6d7 d8d9 dadb dcdd dedf e0e1 e2e3 0x0100: e4e5 e6e7 e8e9 eaeb eced eeef f0f1 f2f3 0x0110: f4f5 f6f7 f8f9 fafb fcfd feff 0001 0203 0x0120: 0405 0607 0809 0a0b 0c0d 0e0f 1011 1213 0x0130: 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 0x0140: 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 0x0150: 3435 3637 3839 3a3b 3c3d 3e3f 4041 4243 0x0160: 4445 4647 4849 4a4b 4c4d 4e4f 5051 5253 0x0170: 5455 5657 5859 5a5b 5c5d 5e5f 6061 6263 0x0180: 6465 6667 6869 6a6b 6c6d 6e6f 7071 7273 0x0190: 7475 7677 7879 7a7b 7c7d 7e7f 8081 8283 0x01a0: 8485 8687 8889 8a8b 8c8d 8e8f 9091 9293 0x01b0: 9495 9697 9899 9a9b 9c9d 9e9f a0a1 a2a3 0x01c0: a4a5 a6a7 a8a9 aaab acad aeaf b0b1 b2b3 0x01d0: b4b5 b6b7 b8b9 babb bcbd bebf c0c1 c2c3 0x01e0: c4c5 c6c7 c8c9 cacb cccd cecf d0d1 d2d3 0x01f0: d4d5 d6d7 d8d9 dadb dcdd dedf e0e1 e2e3 0x0200: e4e5 e6e7 e8e9 eaeb eced eeef f0f1 f2f3 0x0210: f4f5 f6f7 f8f9 fafb fcfd feff 0001 0203 0x0220: 0405 0607 0809 0a0b 0c0d 0e0f 1011 1213 0x0230: 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 0x0240: 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 0x0250: 3435 3637 3839 3a3b 3c3d 3e3f 4041 4243 0x0260: 4445 4647 4849 4a4b 4c4d 4e4f 5051 5253 0x0270: 5455 5657 5859 5a5b 5c5d 5e5f 6061 6263 0x0280: 6465 6667 6869 6a6b 6c6d 6e6f 7071 7273 0x0290: 7475 7677 7879 7a7b 7c7d 7e7f 8081 8283 0x02a0: 8485 8687 8889 8a8b 8c8d 8e8f 9091 9293 0x02b0: 9495 9697 9899 9a9b 9c9d 9e9f a0a1 a2a3 0x02c0: a4a5 a6a7 a8a9 aaab acad aeaf b0b1 b2b3 0x02d0: b4b5 b6b7 b8b9 babb bcbd bebf c0c1 c2c3 0x02e0: c4c5 c6c7 c8c9 cacb cccd cecf d0d1 d2d3 0x02f0: d4d5 d6d7 d8d9 dadb dcdd dedf e0e1 e2e3 0x0300: e4e5 e6e7 e8e9 eaeb eced eeef f0f1 f2f3 0x0310: f4f5 f6f7 f8f9 fafb fcfd feff 0001 0203 0x0320: 0405 0607 0809 0a0b 0c0d 0e0f 1011 1213 0x0330: 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 0x0340: 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 0x0350: 3435 3637 3839 3a3b 3c3d 3e3f 4041 4243 0x0360: 4445 4647 4849 4a4b 4c4d 4e4f 5051 5253 0x0370: 5455 5657 5859 5a5b 5c5d 5e5f 6061 6263 0x0380: 6465 6667 6869 6a6b 6c6d 6e6f 7071 7273 0x0390: 7475 7677 7879 7a7b 7c7d 7e7f 8081 8283 0x03a0: 8485 8687 8889 8a8b 8c8d 8e8f 9091 9293 0x03b0: 9495 9697 9899 9a9b 9c9d 9e9f a0a1 a2a3 0x03c0: a4a5 a6a7 a8a9 aaab acad aeaf b0b1 b2b3 0x03d0: b4b5 b6b7 b8b9 babb bcbd bebf c0c1 c2c3 0x03e0: c4c5 c6c7 c8c9 cacb cccd cecf d0d1 d2d3 0x03f0: d4d5 d6d7 d8d9 dadb dcdd dedf e0e1 e2e3 0x0400: e4e5 e6e7 e8e9 eaeb eced eeef f0f1 f2f3 0x0410: f4f5 f6f7 f8f9 fafb fcfd feff 0001 0203 0x0420: 0405 0607 0809 0a0b 0c0d 0e0f 1011 1213 0x0430: 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 0x0440: 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 0x0450: 3435 3637 3839 3a3b 3c3d 3e3f 4041 4243 0x0460: 4445 4647 4849 4a4b 4c4d 4e4f 5051 5253 0x0470: 5455 5657 5859 5a5b 5c5d 5e5f 6061 6263 0x0480: 6465 6667 6869 6a6b 6c6d 6e6f 7071 7273 0x0490: 7475 7677 7879 7a7b 7c7d 7e7f 8081 8283 0x04a0: 8485 8687 8889 8a8b 8c8d 8e8f 9091 9293 0x04b0: 9495 9697 9899 9a9b 9c9d 9e9f a0a1 a2a3 0x04c0: a4a5 a6a7 a8a9 aaab acad aeaf b0b1 b2b3 0x04d0: b4b5 b6b7 b8b9 babb bcbd bebf c0c1 c2c3 0x04e0: c4c5 c6c7 c8c9 cacb cccd cecf d0d1 d2d3 0x04f0: d4d5 d6d7 d8d9 dadb dcdd dedf e0e1 e2e3 0x0500: e4e5 e6e7 e8e9 eaeb eced eeef f0f1 f2f3 0x0510: f4f5 f6f7 f8f9 fafb fcfd feff 0001 0203 0x0520: 0405 0607 0809 0a0b 0c0d 0e0f 1011 1213 0x0530: 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 0x0540: 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 0x0550: 3435 3637 3839 3a3b 3c3d 3e3f 4041 4243 0x0560: 4445 4647 4849 4a4b 4c4d 4e4f 5051 5253 0x0570: 5455 5657 5859 5a5b 5c5d 5e5f 6061 6263 0x0580: 6465 6667 6869 6a6b 6c6d 6e6f 7071 7273 0x0590: 7475 7677 7879 7a7b 7c7d 7e7f 8081 8283 0x05a0: 8485 8687 8889 8a8b 8c8d 8e8f 9091 9293 0x05b0: 9495 9697 9899 9a9b 9c9d 9e9f a0a1 a2a3 0x05c0: a4a5 a6a7 a8a9 aaab acad aeaf b0b1 b2b3 0x05d0: b4b5 b6b7 b8b9 babb bcbd bebf c0c1 c2c3 0x05e0: c4c5 c6c7 c8c9 cacb cccd cecf d0d1 d2d3 0x05f0: d4d5 d6d7 d8d9 dadb dcdd dedf e0e1 e2e3 0x0600: e4e5 e6e7 e8e9 eaeb eced eeef f0f1 f2f3 0x0610: f4f5 f6f7 f8f9 fafb fcfd feff 0001 0203 0x0620: 0405 0607 0809 0a0b 0c0d 0e0f 1011 1213 0x0630: 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 0x0640: 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 0x0650: 3435 3637 3839 3a3b 3c3d 3e3f 4041 4243 0x0660: 4445 4647 4849 4a4b 4c4d 4e4f 5051 5253 0x0670: 5455 5657 5859 5a5b 5c5d 5e5f 6061 6263 0x0680: 6465 6667 6869 6a6b 6c6d 6e6f 7071 7273 0x0690: 7475 7677 7879 7a7b 7c7d 7e7f 8081 8283 0x06a0: 8485 8687 8889 8a8b 8c8d 8e8f 9091 9293 0x06b0: 9495 9697 9899 9a9b 9c9d 9e9f a0a1 a2a3 0x06c0: a4a5 a6a7 a8a9 aaab acad aeaf b0b1 b2b3 0x06d0: b4b5 b6b7 b8b9 babb bcbd bebf c0c1 c2c3 0x06e0: c4c5 c6c7 c8c9 cacb cccd cecf d0d1 d2d3 0x06f0: d4d5 d6d7 d8d9 dadb dcdd dedf e0e1 e2e3 0x0700: e4e5 e6e7 e8e9 eaeb eced eeef f0f1 f2f3 0x0710: f4f5 f6f7 f8f9 fafb fcfd feff 0001 0203 0x0720: 0405 0607 0809 0a0b 0c0d 0e0f 1011 1213 0x0730: 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 0x0740: 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 0x0750: 3435 3637 3839 3a3b 3c3d 3e3f 4041 4243 0x0760: 4445 4647 4849 4a4b 4c4d 4e4f 5051 5253 0x0770: 5455 5657 5859 5a5b 5c5d 5e5f 6061 6263 0x0780: 6465 6667 6869 6a6b 6c6d 6e6f 7071 7273 0x0790: 7475 7677 7879 7a7b 7c7d 7e7f 8081 8283 0x07a0: 8485 8687 8889 8a8b 8c8d 8e8f 9091 9293 0x07b0: 9495 9697 9899 9a9b 9c9d 9e9f a0a1 a2a3 0x07c0: a4a5 a6a7 a8a9 aaab acad aeaf b0b1 b2b3 0x07d0: b4b5 b6b7 b8b9 babb bcbd bebf c0c1 c2c3 0x07e0: c4c5 c6c7 c8c9 cacb cccd cecf d0d1 d2d3 0x07f0: d4d5 d6d7 d8d9 dadb dcdd dedf e0e1 e2e3 0x0800: e4e5 e6e7 e8e9 eaeb eced eeef f0f1 f2f3 0x0810: f4f5 f6f7 f8f9 fafb fcfd feff 0001 0203 0x0820: 0405 0607 0809 0a0b 0c0d 0e0f 1011 1213 0x0830: 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 0x0840: 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 0x0850: 3435 3637 3839 3a3b 3c3d 3e3f 4041 4243 0x0860: 4445 4647 4849 4a4b 4c4d 4e4f 5051 5253 0x0870: 5455 5657 5859 5a5b 5c5d 5e5f 6061 6263 0x0880: 6465 6667 6869 6a6b 6c6d 6e6f 7071 7273 0x0890: 7475 7677 7879 7a7b 7c7d 7e7f 8081 8283 0x08a0: 8485 8687 8889 8a8b 8c8d 8e8f 9091 9293 0x08b0: 9495 9697 9899 9a9b 9c9d 9e9f a0a1 a2a3 0x08c0: a4a5 a6a7 a8a9 aaab acad aeaf b0b1 b2b3 0x08d0: b4b5 b6b7 b8b9 babb bcbd bebf c0c1 c2c3 0x08e0: c4c5 c6c7 c8c9 cacb cccd cecf d0d1 d2d3 0x08f0: d4d5 d6d7 d8d9 dadb dcdd dedf e0e1 e2e3 0x0900: e4e5 e6e7 e8e9 eaeb eced eeef f0f1 f2f3 0x0910: f4f5 f6f7 f8f9 fafb fcfd feff 0001 0203 0x0920: 0405 0607 0809 0a0b 0c0d 0e0f 1011 1213 0x0930: 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 0x0940: 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 0x0950: 3435 3637 3839 3a3b 3c3d 3e3f 4041 4243 0x0960: 4445 4647 4849 4a4b 4c4d 4e4f 5051 5253 0x0970: 5455 5657 5859 5a5b 5c5d 5e5f 6061 6263 0x0980: 6465 6667 6869 6a6b 6c6d 6e6f 7071 7273 0x0990: 7475 7677 7879 7a7b 7c7d 7e7f 8081 8283 0x09a0: 8485 8687 8889 8a8b 8c8d 8e8f 9091 9293 0x09b0: 9495 9697 9899 9a9b 9c9d 9e9f a0a1 a2a3 0x09c0: a4a5 a6a7 a8a9 aaab acad aeaf b0b1 b2b3 0x09d0: b4b5 b6b7 b8b9 babb bcbd bebf c0c1 c2c3 0x09e0: c4c5 c6c7 c8c9 cacb cccd cecf d0d1 d2d3 0x09f0: d4d5 d6d7 d8d9 dadb dcdd dedf e0e1 e2e3 0x0a00: e4e5 e6e7 e8e9 eaeb eced eeef f0f1 f2f3 0x0a10: f4f5 f6f7 f8f9 fafb fcfd feff 0001 0203 0x0a20: 0405 0607 0809 0a0b 0c0d 0e0f 1011 1213 0x0a30: 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 0x0a40: 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 0x0a50: 3435 3637 3839 3a3b 3c3d 3e3f 4041 4243 0x0a60: 4445 4647 4849 4a4b 4c4d 4e4f 5051 5253 0x0a70: 5455 5657 5859 5a5b 5c5d 5e5f 6061 6263 0x0a80: 6465 6667 6869 6a6b 6c6d 6e6f 7071 7273 0x0a90: 7475 7677 7879 7a7b 7c7d 7e7f 8081 8283 0x0aa0: 8485 8687 8889 8a8b 8c8d 8e8f 9091 9293 0x0ab0: 9495 9697 9899 9a9b 9c9d 9e9f a0a1 a2a3 0x0ac0: a4a5 a6a7 a8a9 aaab acad aeaf b0b1 b2b3 0x0ad0: b4b5 b6b7 b8b9 babb bcbd bebf c0c1 c2c3 0x0ae0: c4c5 c6c7 c8c9 cacb cccd cecf d0d1 d2d3 0x0af0: d4d5 d6d7 d8d9 dadb dcdd dedf e0e1 e2e3 0x0b00: e4e5 e6e7 e8e9 eaeb eced eeef f0f1 f2f3 0x0b10: f4f5 f6f7 f8f9 fafb fcfd feff 0001 0203 0x0b20: 0405 0607 0809 0a0b 0c0d 0e0f 1011 1213 0x0b30: 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 0x0b40: 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 0x0b50: 3435 3637 3839 3a3b 3c3d 3e3f 4041 4243 0x0b60: 4445 4647 4849 4a4b 4c4d 4e4f 5051 5253 0x0b70: 5455 5657 5859 5a5b 5c5d 5e5f 6061 6263 0x0b80: 6465 6667 6869 6a6b 6c6d 6e6f 7071 7273 0x0b90: 7475 7677 7879 7a7b 7c7d 7e7f 8081 8283 0x0ba0: 8485 8687 8889 8a8b 8c8d 8e8f 9091 9293 0x0bb0: 9495 9697 9899 9a9b 9c9d 9e9f a0a1 a2a3 0x0bc0: a4a5 a6a7 a8a9 aaab acad aeaf b0b1 b2b3 0x0bd0: b4b5 b6b7 b8b9 babb bcbd bebf c0c1 c2c3 0x0be0: c4c5 c6c7 c8c9 cacb cccd cecf d0d1 d2d3 0x0bf0: d4d5 d6d7 d8d9 dadb dcdd dedf e0e1 e2e3 0x0c00: e4e5 e6e7 e8e9 eaeb eced eeef f0f1 f2f3 0x0c10: f4f5 f6f7 f8f9 fafb fcfd feff 0001 0203 0x0c20: 0405 0607 0809 0a0b 0c0d 0e0f 1011 1213 0x0c30: 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 0x0c40: 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 0x0c50: 3435 3637 3839 3a3b 3c3d 3e3f 4041 4243 0x0c60: 4445 4647 4849 4a4b 4c4d 4e4f 5051 5253 0x0c70: 5455 5657 5859 5a5b 5c5d 5e5f 6061 6263 0x0c80: 6465 6667 6869 6a6b 6c6d 6e6f 7071 7273 0x0c90: 7475 7677 7879 7a7b 7c7d 7e7f 8081 8283 0x0ca0: 8485 8687 8889 8a8b 8c8d 8e8f 9091 9293 0x0cb0: 9495 9697 9899 9a9b 9c9d 9e9f a0a1 a2a3 0x0cc0: a4a5 a6a7 a8a9 aaab acad aeaf b0b1 b2b3 0x0cd0: b4b5 b6b7 b8b9 babb bcbd bebf c0c1 c2c3 0x0ce0: c4c5 c6c7 c8c9 cacb cccd cecf d0d1 d2d3 0x0cf0: d4d5 d6d7 d8d9 dadb dcdd dedf e0e1 e2e3 0x0d00: e4e5 e6e7 e8e9 eaeb eced eeef f0f1 f2f3 0x0d10: f4f5 f6f7 f8f9 fafb fcfd feff 0001 0203 0x0d20: 0405 0607 0809 0a0b 0c0d 0e0f 1011 1213 0x0d30: 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 0x0d40: 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 0x0d50: 3435 3637 3839 3a3b 3c3d 3e3f 4041 4243 0x0d60: 4445 4647 4849 4a4b 4c4d 4e4f 5051 5253 0x0d70: 5455 5657 5859 5a5b 5c5d 5e5f 6061 6263 0x0d80: 6465 6667 6869 6a6b 6c6d 6e6f 7071 7273 0x0d90: 7475 7677 7879 7a7b 7c7d 7e7f 8081 8283 0x0da0: 8485 8687 8889 8a8b 8c8d 8e8f 9091 9293 0x0db0: 9495 9697 9899 9a9b 9c9d 9e9f a0a1 a2a3 0x0dc0: a4a5 a6a7 a8a9 aaab acad aeaf b0b1 b2b3 0x0dd0: b4b5 b6b7 b8b9 babb bcbd bebf c0c1 c2c3 0x0de0: c4c5 c6c7 c8c9 cacb cccd cecf d0d1 d2d3 0x0df0: d4d5 d6d7 d8d9 dadb dcdd dedf e0e1 e2e3 0x0e00: e4e5 e6e7 e8e9 eaeb eced eeef f0f1 f2f3 0x0e10: f4f5 f6f7 f8f9 fafb fcfd feff 0001 0203 0x0e20: 0405 0607 0809 0a0b 0c0d 0e0f 1011 1213 0x0e30: 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 0x0e40: 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 0x0e50: 3435 3637 3839 3a3b 3c3d 3e3f 4041 4243 0x0e60: 4445 4647 4849 4a4b 4c4d 4e4f 5051 5253 0x0e70: 5455 5657 5859 5a5b 5c5d 5e5f 6061 6263 0x0e80: 6465 6667 6869 6a6b 6c6d 6e6f 7071 7273 0x0e90: 7475 7677 7879 7a7b 7c7d 7e7f 8081 8283 0x0ea0: 8485 8687 8889 8a8b 8c8d 8e8f 9091 9293 0x0eb0: 9495 9697 9899 9a9b 9c9d 9e9f a0a1 a2a3 0x0ec0: a4a5 a6a7 a8a9 aaab acad aeaf b0b1 b2b3 0x0ed0: b4b5 b6b7 b8b9 babb bcbd bebf c0c1 c2c3 0x0ee0: c4c5 c6c7 c8c9 cacb cccd cecf d0d1 d2d3 0x0ef0: d4d5 d6d7 d8d9 dadb dcdd dedf e0e1 e2e3 0x0f00: e4e5 e6e7 e8e9 eaeb eced eeef f0f1 f2f3 0x0f10: f4f5 f6f7 f8f9 fafb fcfd feff 0001 0203 0x0f20: 0405 0607 0809 0a0b 0c0d 0e0f 1011 1213 0x0f30: 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 0x0f40: 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 0x0f50: 3435 3637 3839 3a3b 3c3d 3e3f 4041 4243 0x0f60: 4445 4647 4849 4a4b 4c4d 4e4f 5051 5253 0x0f70: 5455 5657 5859 5a5b 5c5d 5e5f 6061 6263 0x0f80: 6465 6667 6869 6a6b 6c6d 6e6f 7071 7273 0x0f90: 7475 7677 7879 7a7b 7c7d 7e7f 8081 8283 0x0fa0: 8485 8687 8889 8a8b 8c8d 8e8f 9091 9293 0x0fb0: 9495 9697 9899 9a9b 9c9d 9e9f a0a1 a2a3 0x0fc0: a4a5 a6a7 a8a9 aaab acad aeaf b0b1 b2b3 0x0fd0: b4b5 b6b7 b8b9 babb bcbd bebf c0c1 c2c3 0x0fe0: c4c5 c6c7 c8c9 cacb cccd cecf d0d1 d2d3 0x0ff0: d4d5 d6d7 d8d9 dadb dcdd dedf e0e1 e2e3 --------------040509080900070302010203-- --------------enigD952E552B0EAA8F76A21B506 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAlCILTsACgkQLDqVQ9VXb8iALQCgmx24dtQ9gJ88G9fU9J1LzJKo P9oAoJyzdyMAG4+tOHigFiUZK2YloN2o =jZHZ -----END PGP SIGNATURE----- --------------enigD952E552B0EAA8F76A21B506-- From owner-freebsd-stable@FreeBSD.ORG Wed Oct 24 18:12:40 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A331022B for ; Wed, 24 Oct 2012 18:12:40 +0000 (UTC) (envelope-from jdc@koitsu.strangled.net) Received: from qmta01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:16]) by mx1.freebsd.org (Postfix) with ESMTP id 7ECDE8FC0A for ; Wed, 24 Oct 2012 18:12:40 +0000 (UTC) Received: from omta15.emeryville.ca.mail.comcast.net ([76.96.30.71]) by qmta01.emeryville.ca.mail.comcast.net with comcast id F2E51k0081Y3wxoA16Cgyq; Wed, 24 Oct 2012 18:12:40 +0000 Received: from koitsu.strangled.net ([67.180.84.87]) by omta15.emeryville.ca.mail.comcast.net with comcast id F6Cf1k00R1t3BNj8b6CfCf; Wed, 24 Oct 2012 18:12:40 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 4680D73A1A; Wed, 24 Oct 2012 11:12:39 -0700 (PDT) Date: Wed, 24 Oct 2012 11:12:39 -0700 From: Jeremy Chadwick To: Harald Schmalzbauer Subject: Re: every 2nd echo-request malformed when ping -s >4067 Message-ID: <20121024181239.GA5755@icarus.home.lan> References: <20121024154017.GA3167@icarus.home.lan> <5088163E.2090506@omnilan.de> <20121024165148.GA4250@icarus.home.lan> <50881EC7.9030400@omnilan.de> <20121024174425.GA4699@icarus.home.lan> <50882D3B.5050704@omnilan.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50882D3B.5050704@omnilan.de> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Adrian Chadd , FreeBSD Stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 24 Oct 2012 18:12:40 -0000 On Wed, Oct 24, 2012 at 08:02:35PM +0200, Harald Schmalzbauer wrote: > schrieb Jeremy Chadwick am 24.10.2012 19:44 (localtime): > > ... > > Okay, so let's decode what you got. Too bad we don't have snoop-like > > output, since it can decode all of this and output it in a > > human-friendly way. Gotta do this by hand... > > > > > > 12:21:09.048447 IP 10.5.49.126 > 10.5.49.65: ICMP echo request, id 46597, seq 0, length 4076 > > 0x0000: 4500 1000 0f2d 4000 4001 a507 0a05 317e > > > > 0x45 = bits 7-4: IPv4 protocol > > = bits 3-0: header length: 20 bytes > > 0x00 = DSF / RFC 2474 stuff (don't ask me :-) ) > > 0x1000 = datagram length: 4096 bytes > > 0x0f2d = fragment id > > 0x4000 = bits 15-13: %010 = reserved bit (0), DF bit (1), MF bit (0) > > = bits 12-0: fragment offset: 0 > > 0x40 = TTL: 64 > > 0x01 = protocol: 1 (ICMP) > > 0xe4c7 = header checksum > > 0x0a05317e = source IP > > > > Now for the malformed/wonky packet: > > > > 12:21:10.052891 IP 10.5.49.126 > 10.5.49.65: icmp > > 0x0000: 4500 1000 0f2d 0040 4001 e4c7 0a05 317e > > > > 0x45 = bits 7-4: IPv4 protocol > > = bits 3-0: header length: 20 bytes > > 0x00 = DSF / RFC 2474 stuff (don't ask me :-) ) > > 0x1000 = datagram length: 4096 bytes > > 0x0f2d = fragment id > > 0x0040 = bits 15-13: %000 = reserved bit (0), DF bit (0), MF bit (0) > > = bits 12-0: fragment offset: 64 > > 0x40 = TTL: 64 > > 0x01 = protocol: 1 (ICMP) > > 0xe4c7 = header checksum > > 0x0a05317e = source IP > > Thanks a lot for your effort! > What do you use for decoding? I do it all manually -- honest. For some of the portions I had to bust out Wireshark and correlate bytes in my own captures to the ASCII output from tcpdump -x. A quick Google search turned up this, which is pretty helpful too: http://www.networksorcery.com/enp/protocol/ip.htm > Please find attached the requested info. Thanks, got 'em! I'll reply in a follow-up mail with the decoded results. > Can you reproduce this oddity via your lo0? Or is 'ping -D -s 4068 > 127.0.0.1' working on your machine? Sorry I forgot to do that when you asked before; got sidetracked staring at bytes. :-) Let me give it a try. root@icarus:/root # ping -D -s 4068 127.0.0.1 PING 127.0.0.1 (127.0.0.1): 4068 data bytes 4076 bytes from 127.0.0.1: icmp_seq=0 ttl=64 time=0.030 ms 4076 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.032 ms 4076 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.024 ms ^C --- 127.0.0.1 ping statistics --- 3 packets transmitted, 3 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 0.024/0.029/0.032/0.003 ms I also ran tcpdump for this too; no anomalies -- all 3 packets showed up correctly (decoded correctly). My uname -a is below, with csup run about 20 minutes before the kernel build date. FreeBSD icarus.home.lan 9.1-PRERELEASE FreeBSD 9.1-PRERELEASE #0: Sun Oct 21 05:24:09 PDT 2012 root@icarus.home.lan:/usr/obj/usr/src/sys/X7SBA_RELENG_9_amd64 amd64 This is on bare-metal hardware, BTW. I mention that because I've seen some of your other threads talking about NIC driver ordeals under VMs (I think). -- | Jeremy Chadwick jdc@koitsu.org | | UNIX Systems Administrator http://jdc.koitsu.org/ | | Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Wed Oct 24 18:18:59 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 02E20643 for ; Wed, 24 Oct 2012 18:18:59 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) by mx1.freebsd.org (Postfix) with ESMTP id ACC738FC08 for ; Wed, 24 Oct 2012 18:18:58 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1TR5Xc-0000MQ-3D for freebsd-stable@freebsd.org; Wed, 24 Oct 2012 20:18:56 +0200 Received: from cpc3-walt15-2-0-cust148.13-2.cable.virginmedia.com ([86.21.186.149]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 24 Oct 2012 20:18:56 +0200 Received: from walterhurry by cpc3-walt15-2-0-cust148.13-2.cable.virginmedia.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 24 Oct 2012 20:18:56 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: Walter Hurry Subject: Re: cvsup + PAC proxy? Date: Wed, 24 Oct 2012 18:18:35 +0000 (UTC) Lines: 12 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: cpc3-walt15-2-0-cust148.13-2.cable.virginmedia.com User-Agent: Pan/0.135 (Tomorrow I'll Wake Up and Scald Myself with Tea; GIT 30dc37b master) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 24 Oct 2012 18:18:59 -0000 On Wed, 24 Oct 2012 12:40:58 -0500, Ismael Farfán wrote: > Hello list > > Is it possible to use a proxy auto-config stript with cvsup? > > That would save me testing one by one which is the one used to access > the cvsup servers. > > Does any of the CLI tools supports PAC? cvsup is on the way out. Better switch to svn. From owner-freebsd-stable@FreeBSD.ORG Wed Oct 24 18:28:21 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 933DFC4E; Wed, 24 Oct 2012 18:28:21 +0000 (UTC) (envelope-from barney@pit.databus.com) Received: from out.smtp-auth.no-ip.com (out.smtp-auth.no-ip.com [8.23.224.60]) by mx1.freebsd.org (Postfix) with ESMTP id 672B88FC0C; Wed, 24 Oct 2012 18:28:21 +0000 (UTC) X-No-IP: databus.com@noip-smtp X-Report-Spam-To: abuse@no-ip.com Received: from pit.databus.com (unknown [96.232.182.254]) (Authenticated sender: databus.com@noip-smtp) by smtp-auth.no-ip.com (Postfix) with ESMTPA id B457D9B0BFD; Wed, 24 Oct 2012 11:28:15 -0700 (PDT) Received: from pit.databus.com (localhost [127.0.0.1]) by pit.databus.com (8.14.5/8.14.5) with ESMTP id q9OISDSN081687 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 24 Oct 2012 14:28:13 -0400 (EDT) (envelope-from barney@pit.databus.com) X-DKIM: OpenDKIM Filter v2.5.2 pit.databus.com q9OISDSN081687 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=databus.com; s=20091218; t=1351103294; bh=6NeMMUCID3LaNBn4nz0iofenTLQt6mYXz/ig0sRbppY=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=lfA5JFTat4uABEAOY56JRn+JBj53XRJKyqBPwYtsOnEOhmkKW7NS1ebf8RunotOuW hHSKSh7SOgajLNJFSbn5kjwf7PF81zPXEMtqjDTkDHjQTMivUnRYJPOhbnCdOwpAdl KvECt+QhfSfnQEwqn0e8ZU1hocpWQaMRAkfL8ZJs= Received: (from barney@localhost) by pit.databus.com (8.14.5/8.14.5/Submit) id q9OISDIN081686; Wed, 24 Oct 2012 14:28:13 -0400 (EDT) (envelope-from barney) Date: Wed, 24 Oct 2012 14:28:13 -0400 From: Barney Wolff To: Jeremy Chadwick Subject: Re: every 2nd echo-request malformed when ping -s >4067 Message-ID: <20121024182813.GA81641@pit.databus.com> References: <20121024154017.GA3167@icarus.home.lan> <5088163E.2090506@omnilan.de> <20121024165148.GA4250@icarus.home.lan> <50881EC7.9030400@omnilan.de> <20121024174425.GA4699@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20121024174425.GA4699@icarus.home.lan> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Harald Schmalzbauer , Adrian Chadd , FreeBSD Stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 24 Oct 2012 18:28:21 -0000 0040 -> 4000 looks like a network byte order issue, perhaps. I have a faint memory of issues of when tcpdump looks at packets, determining whether UDP checksums are shown, for example. Possibly this is some artefact of outboarding? From owner-freebsd-stable@FreeBSD.ORG Wed Oct 24 18:39:59 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DCB15384; Wed, 24 Oct 2012 18:39:59 +0000 (UTC) (envelope-from h.schmalzbauer@omnilan.de) Received: from host.omnilan.net (s1.omnilan.net [62.245.232.135]) by mx1.freebsd.org (Postfix) with ESMTP id 46CE08FC0A; Wed, 24 Oct 2012 18:39:58 +0000 (UTC) Received: from titan.inop.wdn.omnilan.net (titan.inop.wdn.omnilan.net [172.21.3.1]) (authenticated bits=0) by host.omnilan.net (8.13.8/8.13.8) with ESMTP id q9OIfKe8074843 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 24 Oct 2012 20:41:20 +0200 (CEST) (envelope-from h.schmalzbauer@omnilan.de) Message-ID: <508835FD.4000709@omnilan.de> Date: Wed, 24 Oct 2012 20:39:57 +0200 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Jeremy Chadwick Subject: Re: every 2nd echo-request malformed when ping -s >4067 References: <20121024154017.GA3167@icarus.home.lan> <5088163E.2090506@omnilan.de> <20121024165148.GA4250@icarus.home.lan> <50881EC7.9030400@omnilan.de> <20121024174425.GA4699@icarus.home.lan> <50882D3B.5050704@omnilan.de> <20121024181239.GA5755@icarus.home.lan> In-Reply-To: <20121024181239.GA5755@icarus.home.lan> X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigD90B50DFA0FCDCBFB765950B" Cc: Adrian Chadd , FreeBSD Stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 24 Oct 2012 18:39:59 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigD90B50DFA0FCDCBFB765950B Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable schrieb Jeremy Chadwick am 24.10.2012 20:12 (localtime): > ... > root@icarus:/root # ping -D -s 4068 127.0.0.1 > PING 127.0.0.1 (127.0.0.1): 4068 data bytes > 4076 bytes from 127.0.0.1: icmp_seq=3D0 ttl=3D64 time=3D0.030 ms > 4076 bytes from 127.0.0.1: icmp_seq=3D1 ttl=3D64 time=3D0.032 ms > 4076 bytes from 127.0.0.1: icmp_seq=3D2 ttl=3D64 time=3D0.024 ms > ^C > --- 127.0.0.1 ping statistics --- > 3 packets transmitted, 3 packets received, 0.0% packet loss > round-trip min/avg/max/stddev =3D 0.024/0.029/0.032/0.003 ms > > I also ran tcpdump for this too; no anomalies -- all 3 packets showed u= p > correctly (decoded correctly). My uname -a is below, with csup run > about 20 minutes before the kernel build date. > > FreeBSD icarus.home.lan 9.1-PRERELEASE FreeBSD 9.1-PRERELEASE #0: Sun O= ct 21 05:24:09 PDT 2012 root@icarus.home.lan:/usr/obj/usr/src/sys/X7S= BA_RELENG_9_amd64 amd64 > > This is on bare-metal hardware, BTW. I mention that because I've seen > some of your other threads talking about NIC driver ordeals under VMs (= I > think). Oh, I thought it's not specific to my system because I remembered this issue well on a completely different HW; real HW in that case. A quick test showed that the big-ping to localhost works on all my other machines... Should have checked that before, sorry. I have zero_copy_sockets in all my kernels, so I think that can't be the cause. But I don't have another machine where real nics have MTU > 1500. I'll try to find out why this only affects one machine here at the moment, but tonight's time to have dinner->sleep. Thanks a lot! -Harry --------------enigD90B50DFA0FCDCBFB765950B Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAlCINf0ACgkQLDqVQ9VXb8jaIwCfS4YOetKal6gWd1ux55Yt+MZo zj0AoKQOM7BJvmUV5E25jYz1Z+6eVeav =508h -----END PGP SIGNATURE----- --------------enigD90B50DFA0FCDCBFB765950B-- From owner-freebsd-stable@FreeBSD.ORG Wed Oct 24 18:44:26 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 09CB5678 for ; Wed, 24 Oct 2012 18:44:26 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-oa0-f54.google.com (mail-oa0-f54.google.com [209.85.219.54]) by mx1.freebsd.org (Postfix) with ESMTP id B94F98FC19 for ; Wed, 24 Oct 2012 18:44:25 +0000 (UTC) Received: by mail-oa0-f54.google.com with SMTP id n9so1011214oag.13 for ; Wed, 24 Oct 2012 11:44:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=L3Q9oIVRMNeqm1JwN6o7NBNZJMFI2RYt5Pe7t4zGROc=; b=S+et0mLs2KLyWLTY0LElmFZHInEQIpajyVhLvuGy/PyC8BtXu55BdsLLNBitRa7k6R oUfzXjAGRLqOo2h5jL+k+aaE9NOyG9xg+S+Zu/AOQvQVyB8NSyqRPIXJ//OzwyMGegXD N4uX1xUF6woYu12cuTPcDsqfIdeU9EQlTbeE/ygK+sKsF+3C1zuhaGJOc72hW/tc6hva 5v96qdjPNF4a+RvUmDb98p+P9GLiuf8qoobzr9opKa4Q5syHB2+YkVQWUw3lqZGMtKhS sRo7KCpBYzHVJ3EIGWRbH2w5pdd3TSZigkwyiq6XI47qv9phi2cw6II55rQ7VTLosYHJ 4FXw== MIME-Version: 1.0 Received: by 10.182.31.43 with SMTP id x11mr13152534obh.68.1351104265139; Wed, 24 Oct 2012 11:44:25 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.76.75.69 with HTTP; Wed, 24 Oct 2012 11:44:24 -0700 (PDT) In-Reply-To: <508835FD.4000709@omnilan.de> References: <20121024154017.GA3167@icarus.home.lan> <5088163E.2090506@omnilan.de> <20121024165148.GA4250@icarus.home.lan> <50881EC7.9030400@omnilan.de> <20121024174425.GA4699@icarus.home.lan> <50882D3B.5050704@omnilan.de> <20121024181239.GA5755@icarus.home.lan> <508835FD.4000709@omnilan.de> Date: Wed, 24 Oct 2012 11:44:24 -0700 X-Google-Sender-Auth: TJkXvvktEx4x1Mb9vIVtIkLl06c Message-ID: Subject: Re: every 2nd echo-request malformed when ping -s >4067 From: Adrian Chadd To: Harald Schmalzbauer Content-Type: text/plain; charset=ISO-8859-1 Cc: Jeremy Chadwick , FreeBSD Stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 24 Oct 2012 18:44:26 -0000 oh lord, please disable zero_copy_sockets. :-) Adrian From owner-freebsd-stable@FreeBSD.ORG Wed Oct 24 18:55:26 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 94B01B37 for ; Wed, 24 Oct 2012 18:55:26 +0000 (UTC) (envelope-from jdc@koitsu.strangled.net) Received: from qmta02.emeryville.ca.mail.comcast.net (qmta02.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:24]) by mx1.freebsd.org (Postfix) with ESMTP id 6EA228FC08 for ; Wed, 24 Oct 2012 18:55:26 +0000 (UTC) Received: from omta18.emeryville.ca.mail.comcast.net ([76.96.30.74]) by qmta02.emeryville.ca.mail.comcast.net with comcast id F3qn1k0021bwxycA26vSRC; Wed, 24 Oct 2012 18:55:26 +0000 Received: from koitsu.strangled.net ([67.180.84.87]) by omta18.emeryville.ca.mail.comcast.net with comcast id F6vR1k0051t3BNj8e6vRiK; Wed, 24 Oct 2012 18:55:26 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 2CFE173A1A; Wed, 24 Oct 2012 11:55:25 -0700 (PDT) Date: Wed, 24 Oct 2012 11:55:25 -0700 From: Jeremy Chadwick To: Harald Schmalzbauer Subject: Re: every 2nd echo-request malformed when ping -s >4067 Message-ID: <20121024185525.GA6426@icarus.home.lan> References: <20121024154017.GA3167@icarus.home.lan> <5088163E.2090506@omnilan.de> <20121024165148.GA4250@icarus.home.lan> <50881EC7.9030400@omnilan.de> <20121024174425.GA4699@icarus.home.lan> <50882D3B.5050704@omnilan.de> <20121024181239.GA5755@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20121024181239.GA5755@icarus.home.lan> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Adrian Chadd , FreeBSD Stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 24 Oct 2012 18:55:26 -0000 On Wed, Oct 24, 2012 at 11:12:39AM -0700, Jeremy Chadwick wrote: > On Wed, Oct 24, 2012 at 08:02:35PM +0200, Harald Schmalzbauer wrote: > > Please find attached the requested info. > > Thanks, got 'em! I'll reply in a follow-up mail with the decoded > results. As promised, here are the decoded results. Took me longer than I expected since I started going down the road of IP options and then was like, "no, wait a minute, this is ICMP gah!". Opinions are at the bottom. Gosh I hope I didn't botch a copy-paste on this one... 17:58:08.481888 IP 10.5.49.126 > 10.5.49.65: ICMP echo request, id 49423, seq 0, length 4076 0x0000: 4500 1000 1fff 4000 4001 9435 0a05 317e 0x0010: 0a05 3141 0800 a352 c10f 0000 5088 2c30 0x0020: 0007 5a3b {...snip...} 0x45 = bits 7-4: IPv4 protocol = bits 3-0: header length: 20 bytes 0x00 = DSF / RFC 2474 stuff 0x1000 = datagram length: 4096 bytes 0x1fff = fragment id 0x4000 = bits 15-13: %010 = reserved bit (0), DF bit (1), MF bit (0) = bits 12-0: fragment offset: 0 0x40 = TTL: 64 0x01 = protocol: 1 (ICMP) 0x9435 = header checksum 0x0a05317e = source IP 0x0a053141 = destination IP 0x08 = ICMP type: 8 = Echo Request 0x00 = ICMP code: 0 = always zero for ICMP type 8 0xa352 = ICMP header checksum 0xc10f = ICMP identifier 0x0000 = ICMP sequence number 0x5088 = timestamp from ICMP data 0x2c30 = timestamp from ICMP data 0x0007 = timestamp from ICMP data 0x5a3b = timestamp from ICMP data 17:58:09.488461 IP 10.5.49.126 > 10.5.49.65: icmp 0x0000: 4500 1000 1fff 0040 4001 d3f5 0a05 317e 0x0010: 0a05 3141 0800 8998 c10f 0001 5088 2c31 0x0020: 0007 73f3 {...snip...} 0x45 = bits 7-4: IPv4 protocol = bits 3-0: header length: 20 bytes 0x00 = DSF / RFC 2474 stuff 0x1000 = datagram length: 4096 bytes 0x1fff = fragment id 0x0040 = bits 15-13: %000 = reserved bit (0), DF bit (0), MF bit (0) = bits 12-0: fragment offset: 64 0x40 = TTL: 64 0x01 = protocol: 1 (ICMP) 0xd3f5 = header checksum 0x0a05317e = source IP 0x0a053141 = destination IP 0x08 = ICMP type: 8 = Echo Request 0x00 = ICMP code: 0 = always zero for ICMP type 8 0x8998 = ICMP header checksum 0xc10f = ICMP identifier 0x0001 = ICMP sequence number 0x5088 = timestamp from ICMP data 0x2c31 = timestamp from ICMP data 0x0007 = timestamp from ICMP data 0x73f3 = timestamp from ICMP data Summary: I don't see anything anomalous EXCEPT the ordeal regarding the fragment offset going from 0->64 and the DF bit going from 1->0. Possibly this makes tcpdump throw a fit in some way, I'm not sure. If I had to take a guess? I'd say some code somewhere is incorrectly shifting bits (I'm thinking along the lines of a hardware latch counter) or possibly has a byte-ordering problem. I'd love to say "big vs. little endian issue" except I'd expect that to manifest itself constantly time and not just every other packet. But heck if I know what NIC drivers and their IP stack tie-ins are doing under the hood. The good part is that you can reproduce this reliably. P.S. -- Just saw the mail from Barney -- I think he's referring to IP, TCP, and UDP checksums (you can disable that calculation check using tcpdump -K), but that's only in tcpdump. There is also the checksum offloading features on NICs (see ifconfig). I have not the slightest idea if these NIC features could cause this problem / make it manifest in this way. P.P.S. -- Just saw Adrian's comment about zero copy sockets. No idea if it's relevant or not, but disable it anyway because it's going to bite you in the butt come FreeBSD 10.x anyway: http://www.freshbsd.org/commit/freebsd/r241955 http://lists.freebsd.org/pipermail/freebsd-current/2012-October/037354.html -- | Jeremy Chadwick jdc@koitsu.org | | UNIX Systems Administrator http://jdc.koitsu.org/ | | Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Wed Oct 24 19:12:07 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A0229AC5 for ; Wed, 24 Oct 2012 19:12:07 +0000 (UTC) (envelope-from jdc@koitsu.strangled.net) Received: from qmta01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:16]) by mx1.freebsd.org (Postfix) with ESMTP id 7D65B8FC0C for ; Wed, 24 Oct 2012 19:12:07 +0000 (UTC) Received: from omta05.emeryville.ca.mail.comcast.net ([76.96.30.43]) by qmta01.emeryville.ca.mail.comcast.net with comcast id F0vY1k00F0vp7WLA17C76q; Wed, 24 Oct 2012 19:12:07 +0000 Received: from koitsu.strangled.net ([67.180.84.87]) by omta05.emeryville.ca.mail.comcast.net with comcast id F7C61k00J1t3BNj8R7C6FN; Wed, 24 Oct 2012 19:12:06 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 38BC273A1C; Wed, 24 Oct 2012 12:12:06 -0700 (PDT) Date: Wed, 24 Oct 2012 12:12:06 -0700 From: Jeremy Chadwick To: Harald Schmalzbauer Subject: Re: every 2nd echo-request malformed when ping -s >4067 Message-ID: <20121024191206.GA6704@icarus.home.lan> References: <20121024154017.GA3167@icarus.home.lan> <5088163E.2090506@omnilan.de> <20121024165148.GA4250@icarus.home.lan> <50881EC7.9030400@omnilan.de> <20121024174425.GA4699@icarus.home.lan> <50882D3B.5050704@omnilan.de> <20121024181239.GA5755@icarus.home.lan> <20121024185525.GA6426@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20121024185525.GA6426@icarus.home.lan> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Adrian Chadd , FreeBSD Stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 24 Oct 2012 19:12:07 -0000 On Wed, Oct 24, 2012 at 11:55:25AM -0700, Jeremy Chadwick wrote: > On Wed, Oct 24, 2012 at 11:12:39AM -0700, Jeremy Chadwick wrote: > > On Wed, Oct 24, 2012 at 08:02:35PM +0200, Harald Schmalzbauer wrote: > > > Please find attached the requested info. > > > > Thanks, got 'em! I'll reply in a follow-up mail with the decoded > > results. > > As promised, here are the decoded results. Took me longer than I > expected since I started going down the road of IP options and then was > like, "no, wait a minute, this is ICMP gah!". Opinions are at the > bottom. Gosh I hope I didn't botch a copy-paste on this one... > > 17:58:08.481888 IP 10.5.49.126 > 10.5.49.65: ICMP echo request, id 49423, seq 0, length 4076 > 0x0000: 4500 1000 1fff 4000 4001 9435 0a05 317e > 0x0010: 0a05 3141 0800 a352 c10f 0000 5088 2c30 > 0x0020: 0007 5a3b {...snip...} > > 0x45 = bits 7-4: IPv4 protocol > = bits 3-0: header length: 20 bytes > 0x00 = DSF / RFC 2474 stuff > 0x1000 = datagram length: 4096 bytes > 0x1fff = fragment id > 0x4000 = bits 15-13: %010 = reserved bit (0), DF bit (1), MF bit (0) > = bits 12-0: fragment offset: 0 > 0x40 = TTL: 64 > 0x01 = protocol: 1 (ICMP) > 0x9435 = header checksum > 0x0a05317e = source IP > 0x0a053141 = destination IP > 0x08 = ICMP type: 8 = Echo Request > 0x00 = ICMP code: 0 = always zero for ICMP type 8 > 0xa352 = ICMP header checksum > 0xc10f = ICMP identifier > 0x0000 = ICMP sequence number > 0x5088 = timestamp from ICMP data > 0x2c30 = timestamp from ICMP data > 0x0007 = timestamp from ICMP data > 0x5a3b = timestamp from ICMP data > > > 17:58:09.488461 IP 10.5.49.126 > 10.5.49.65: icmp > 0x0000: 4500 1000 1fff 0040 4001 d3f5 0a05 317e > 0x0010: 0a05 3141 0800 8998 c10f 0001 5088 2c31 > 0x0020: 0007 73f3 {...snip...} > > 0x45 = bits 7-4: IPv4 protocol > = bits 3-0: header length: 20 bytes > 0x00 = DSF / RFC 2474 stuff > 0x1000 = datagram length: 4096 bytes > 0x1fff = fragment id > 0x0040 = bits 15-13: %000 = reserved bit (0), DF bit (0), MF bit (0) > = bits 12-0: fragment offset: 64 > 0x40 = TTL: 64 > 0x01 = protocol: 1 (ICMP) > 0xd3f5 = header checksum > 0x0a05317e = source IP > 0x0a053141 = destination IP > 0x08 = ICMP type: 8 = Echo Request > 0x00 = ICMP code: 0 = always zero for ICMP type 8 > 0x8998 = ICMP header checksum > 0xc10f = ICMP identifier > 0x0001 = ICMP sequence number > 0x5088 = timestamp from ICMP data > 0x2c31 = timestamp from ICMP data > 0x0007 = timestamp from ICMP data > 0x73f3 = timestamp from ICMP data > > > Summary: I don't see anything anomalous EXCEPT the ordeal regarding the > fragment offset going from 0->64 and the DF bit going from 1->0. > Possibly this makes tcpdump throw a fit in some way, I'm not sure. Hmm, question: are you using pf, ipfilter, or ipfw on the machines where you can reproduce this problem? On the machine I tested from earlier, I don't use them. I also don't use jumbo frames (I use stock 1500 bytes). All my ICMP echo packets look like your 1st one: df=0 and fragoffset=0. I do have a 9.1-PREREL box that does use pf where I can test from though. I hate having to ask this question, but pf.conf(5) and the no-df flag always come to mind whenever I hear the term fragmentation or DF. -- | Jeremy Chadwick jdc@koitsu.org | | UNIX Systems Administrator http://jdc.koitsu.org/ | | Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Wed Oct 24 20:28:24 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EC957F3D for ; Wed, 24 Oct 2012 20:28:24 +0000 (UTC) (envelope-from sulfurfff@gmail.com) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by mx1.freebsd.org (Postfix) with ESMTP id 76BC68FC14 for ; Wed, 24 Oct 2012 20:28:23 +0000 (UTC) Received: by mail-wi0-f172.google.com with SMTP id hq12so4400441wib.13 for ; Wed, 24 Oct 2012 13:28:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Qf5M1avdRU0G6JFaLEVyFHdCc7w8XciJ8cD2T87oboQ=; b=LdXJTG60q6dtHZBxtcdTWHyXPVnRma6ytqyjaTBOBU5JgZecMA3A0JVhLsxNwZKxUd UbRZMFw788B7VuPG/+0XX68a1sx7fEOADChEUMUWcjT9GgeW8t0QmF+mT8UfklJpCzCL Zeun7Da3WgDKqGeIM/X63G4zc/VOH6tPsmmpA8/gGapLEGrdX0bMjISq74Sw1Vma55J0 5n6pln5fbJe/Hwq2zYM8nyUT0GULbxuTneOhmDXIicP8DysucXrkJP+JL1TQenCAGv7R yfyiDMho7OE4b6TgmPAnRNLUl5Aq+3x3l7+ljt9XUVUMC9xUZ7NSOSrlw2xwx7V+XCuS XuDA== MIME-Version: 1.0 Received: by 10.180.100.35 with SMTP id ev3mr5072388wib.7.1351110503269; Wed, 24 Oct 2012 13:28:23 -0700 (PDT) Received: by 10.194.109.226 with HTTP; Wed, 24 Oct 2012 13:28:23 -0700 (PDT) In-Reply-To: References: Date: Wed, 24 Oct 2012 15:28:23 -0500 Message-ID: Subject: Re: cvsup + PAC proxy? From: =?UTF-8?Q?Ismael_Farf=C3=A1n?= To: Walter Hurry Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 24 Oct 2012 20:28:25 -0000 2012/10/24 Walter Hurry : > On Wed, 24 Oct 2012 12:40:58 -0500, Ismael Farf=C3=A1n wrote: > >> Hello list >> >> Is it possible to use a proxy auto-config stript with cvsup? >> >> That would save me testing one by one which is the one used to access >> the cvsup servers. >> >> Does any of the CLI tools supports PAC? > > cvsup is on the way out. Better switch to svn. > Interesting... probably someone should update the handbook then: """ 2 Grab the sources from a FreeBSD mirror site. You can do this in one of two ways: a Use the **cvsup** program with the supfile named standard-supfile available from /usr/share/examples/cvsup. This **is the most recommended method**, since it allows you to grab the entire collection once and then only what has changed from then on... """ Does anyone knows if this is in sync with CURRENT/bleeding-edge svn freebsd= ? https://github.com/freebsd/freebsd-head I don't have anything against svn, but I don't need 100 old copies of each file in the tree and git has a very handy --depth option. Regards Ismael > _______________________________________________ > 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" --=20 Do not let me induce you to satisfy my curiosity, from an expectation, that I shall gratify yours. What I may judge proper to conceal, does not concern myself alone. From owner-freebsd-stable@FreeBSD.ORG Wed Oct 24 21:31:01 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 71E7942C for ; Wed, 24 Oct 2012 21:31:01 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-da0-f54.google.com (mail-da0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id 3E9958FC0C for ; Wed, 24 Oct 2012 21:31:01 +0000 (UTC) Received: by mail-da0-f54.google.com with SMTP id z9so475010dad.13 for ; Wed, 24 Oct 2012 14:31:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=cIVSHVP7rmuPB7BGkGJ5Ib5ljd/VXCD+JL+OmIM0pck=; b=zoaJxptbRR/WosFUSU+U3o0bpaHVVyp9sadAZxBz3E1nV7Iq1hqIjhzJpD+Y46ejPo fLx+6G58LWqqJcH29hzBOta4yOYwS8R5gdJjEaa00aZ2t9va9503tUW0uHeMugrZfkhD sIpQlL4qy461sOrUI7ZFLYMnZUR3kicSMrqrBhS+FWGNkDNmNoBKCCcS54xjEANVi2a8 eZgchXVjLR1e/ThED2rk3CmzV9qiBhkwoVfNNHkmy0pMBhSjZXJEkg41pAZWSibkbCIS lIK/p8v0sDg5gHSmV8J0ans794wlyOKIR+T9ikOWulQH8G3ILlJcsbgL618cbQd2igVb /WRQ== MIME-Version: 1.0 Received: by 10.68.223.37 with SMTP id qr5mr53803331pbc.101.1351114260702; Wed, 24 Oct 2012 14:31:00 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.68.146.233 with HTTP; Wed, 24 Oct 2012 14:31:00 -0700 (PDT) In-Reply-To: References: Date: Wed, 24 Oct 2012 14:31:00 -0700 X-Google-Sender-Auth: 9x4eouUqGx9P7TW3O_osPCXTh6I Message-ID: Subject: Re: cvsup + PAC proxy? From: Adrian Chadd To: =?ISO-8859-1?Q?Ismael_Farf=E1n?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 24 Oct 2012 21:31:01 -0000 On 24 October 2012 10:40, Ismael Farf=E1n wrote: > Hello list > > Is it possible to use a proxy auto-config stript with cvsup? > > That would save me testing one by one which is the one used > to access the cvsup servers. > > Does any of the CLI tools supports PAC? A proxy-pac library would be useful to implement. Just please keep in mind that proxy-pac requires a javascript execution environment as well as a bunch of extra stuff to implement the .pac bits (mostly things like host matching, host lookup fucntions, setting up the right variables with the host name, client IP, destination IP, etc.) It would be nice to have a single library to do this with though. Adrian From owner-freebsd-stable@FreeBSD.ORG Thu Oct 25 04:29:15 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 347C277C; Thu, 25 Oct 2012 04:29:15 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 84D838FC08; Thu, 25 Oct 2012 04:29:13 +0000 (UTC) Received: by mail-we0-f182.google.com with SMTP id x43so799669wey.13 for ; Wed, 24 Oct 2012 21:29:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Z7DsMV2raeIW4XPsrzkqw2NB4teJAOYVhpF6rexZEjw=; b=SMNqm19FcN5ogoNcfO5llBqT7kiTDvVvLNVAggua1ger8P+qg/9V1F0d2WVQfvtg3p cl+3L3iEgmYzjtq6JW+qK08sDzx+i9FDVFpcSBKQ+dHU9K+Io6eWvNHGcY0qsEAy7Ti4 Sk/+SBHRg1WbaqcLygnz3uMeV0aYSEUGreBa91U2V/PZKjHHcyOIyverZNRaFVAjDitU +bal5PvAhBzvGHLXB4AdRZx41smT8JhLIn1xgZaI/iFTUrODRs+7Qqao+WIw12l1BNo0 yRHlqM3T9+AXxRoveKRPBbLoR3+H7cpX9+hjAoHl/Rge5m9E4Mah4nAOvXoKSUCQM684 L2bA== MIME-Version: 1.0 Received: by 10.180.87.34 with SMTP id u2mr7331107wiz.3.1351139352962; Wed, 24 Oct 2012 21:29:12 -0700 (PDT) Received: by 10.223.66.194 with HTTP; Wed, 24 Oct 2012 21:29:12 -0700 (PDT) In-Reply-To: <20121024191206.GA6704@icarus.home.lan> References: <20121024154017.GA3167@icarus.home.lan> <5088163E.2090506@omnilan.de> <20121024165148.GA4250@icarus.home.lan> <50881EC7.9030400@omnilan.de> <20121024174425.GA4699@icarus.home.lan> <50882D3B.5050704@omnilan.de> <20121024181239.GA5755@icarus.home.lan> <20121024185525.GA6426@icarus.home.lan> <20121024191206.GA6704@icarus.home.lan> Date: Wed, 24 Oct 2012 21:29:12 -0700 Message-ID: Subject: Re: every 2nd echo-request malformed when ping -s >4067 From: Kevin Oberman To: Jeremy Chadwick Content-Type: text/plain; charset=UTF-8 Cc: Harald Schmalzbauer , Adrian Chadd , FreeBSD Stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 25 Oct 2012 04:29:15 -0000 On Wed, Oct 24, 2012 at 12:12 PM, Jeremy Chadwick wrote: > On Wed, Oct 24, 2012 at 11:55:25AM -0700, Jeremy Chadwick wrote: >> On Wed, Oct 24, 2012 at 11:12:39AM -0700, Jeremy Chadwick wrote: >> > On Wed, Oct 24, 2012 at 08:02:35PM +0200, Harald Schmalzbauer wrote: >> > > Please find attached the requested info. >> > >> > Thanks, got 'em! I'll reply in a follow-up mail with the decoded >> > results. >> >> As promised, here are the decoded results. Took me longer than I >> expected since I started going down the road of IP options and then was >> like, "no, wait a minute, this is ICMP gah!". Opinions are at the >> bottom. Gosh I hope I didn't botch a copy-paste on this one... >> >> 17:58:08.481888 IP 10.5.49.126 > 10.5.49.65: ICMP echo request, id 49423, seq 0, length 4076 >> 0x0000: 4500 1000 1fff 4000 4001 9435 0a05 317e >> 0x0010: 0a05 3141 0800 a352 c10f 0000 5088 2c30 >> 0x0020: 0007 5a3b {...snip...} >> >> 0x45 = bits 7-4: IPv4 protocol >> = bits 3-0: header length: 20 bytes >> 0x00 = DSF / RFC 2474 stuff >> 0x1000 = datagram length: 4096 bytes >> 0x1fff = fragment id >> 0x4000 = bits 15-13: %010 = reserved bit (0), DF bit (1), MF bit (0) >> = bits 12-0: fragment offset: 0 >> 0x40 = TTL: 64 >> 0x01 = protocol: 1 (ICMP) >> 0x9435 = header checksum >> 0x0a05317e = source IP >> 0x0a053141 = destination IP >> 0x08 = ICMP type: 8 = Echo Request >> 0x00 = ICMP code: 0 = always zero for ICMP type 8 >> 0xa352 = ICMP header checksum >> 0xc10f = ICMP identifier >> 0x0000 = ICMP sequence number >> 0x5088 = timestamp from ICMP data >> 0x2c30 = timestamp from ICMP data >> 0x0007 = timestamp from ICMP data >> 0x5a3b = timestamp from ICMP data >> >> >> 17:58:09.488461 IP 10.5.49.126 > 10.5.49.65: icmp >> 0x0000: 4500 1000 1fff 0040 4001 d3f5 0a05 317e >> 0x0010: 0a05 3141 0800 8998 c10f 0001 5088 2c31 >> 0x0020: 0007 73f3 {...snip...} >> >> 0x45 = bits 7-4: IPv4 protocol >> = bits 3-0: header length: 20 bytes >> 0x00 = DSF / RFC 2474 stuff >> 0x1000 = datagram length: 4096 bytes >> 0x1fff = fragment id >> 0x0040 = bits 15-13: %000 = reserved bit (0), DF bit (0), MF bit (0) >> = bits 12-0: fragment offset: 64 >> 0x40 = TTL: 64 >> 0x01 = protocol: 1 (ICMP) >> 0xd3f5 = header checksum >> 0x0a05317e = source IP >> 0x0a053141 = destination IP >> 0x08 = ICMP type: 8 = Echo Request >> 0x00 = ICMP code: 0 = always zero for ICMP type 8 >> 0x8998 = ICMP header checksum >> 0xc10f = ICMP identifier >> 0x0001 = ICMP sequence number >> 0x5088 = timestamp from ICMP data >> 0x2c31 = timestamp from ICMP data >> 0x0007 = timestamp from ICMP data >> 0x73f3 = timestamp from ICMP data >> >> >> Summary: I don't see anything anomalous EXCEPT the ordeal regarding the >> fragment offset going from 0->64 and the DF bit going from 1->0. >> Possibly this makes tcpdump throw a fit in some way, I'm not sure. > > Hmm, question: are you using pf, ipfilter, or ipfw on the machines where > you can reproduce this problem? > > On the machine I tested from earlier, I don't use them. I also don't > use jumbo frames (I use stock 1500 bytes). All my ICMP echo packets > look like your 1st one: df=0 and fragoffset=0. I do have a 9.1-PREREL > box that does use pf where I can test from though. > > I hate having to ask this question, but pf.conf(5) and the no-df flag > always come to mind whenever I hear the term fragmentation or DF. > > -- > | Jeremy Chadwick jdc@koitsu.org | > | UNIX Systems Administrator http://jdc.koitsu.org/ | > | Mountain View, CA, US | > | Making life hard for others since 1977. PGP 4BD6C0CB | Just a quick suggestion. You could have saved a lot of time and effort if you would capture the data using the -w option and feeding the BPF file to net/wireshark. It does a first rate job of protocol decode and even flags errors and inconsistencies. Of course, it requires a GUI, but the captured data can be copied to a system that runs one. -- R. Kevin Oberman, Network Engineer E-mail: kob6558@gmail.com From owner-freebsd-stable@FreeBSD.ORG Thu Oct 25 05:52:42 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 36C79EC1; Thu, 25 Oct 2012 05:52:42 +0000 (UTC) (envelope-from fernando.apesteguia@gmail.com) Received: from mail-la0-f54.google.com (mail-la0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 0F0D18FC0A; Thu, 25 Oct 2012 05:52:40 +0000 (UTC) Received: by mail-la0-f54.google.com with SMTP id e12so1233626lag.13 for ; Wed, 24 Oct 2012 22:52:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=50fP0DyJB7Hr/pCXRfopT9lY/79dFex9tRYmF/Cf+UA=; b=HwgEa9T1KBd7IhRAXiBuaUOUO7EQgYLL7cPnCUXU5BLS3NSvWK/Lxj6W7uZj4OS3D7 RfdP0UrPIv+Oxuq1nMLlhDLUx+cuSOgQT3Xf8AEJvUX7eqbGLa7RBsjWtQv5UBLTO96Y TRhUhIMwf6EsDnrcNxLAd+XwkCYx+rFdPGBpF81gCMjmcwOBFznBJTuQpLpMChFQtoVX CS+BiLb7io6KEySGiWuVevu71PL6TNoRoHEqKGXD5IXWgsI/iVJgxa1O2tL4fFA/aS/w vxGWQS3ZhR3jmk6o6wd+aQhdCGs/ZwOje8p8JC/sYWLQ4EIwzQRjbnZbV6izjmGpnfWr 4BiA== MIME-Version: 1.0 Received: by 10.112.26.131 with SMTP id l3mr866140lbg.26.1351144359574; Wed, 24 Oct 2012 22:52:39 -0700 (PDT) Received: by 10.152.1.193 with HTTP; Wed, 24 Oct 2012 22:52:39 -0700 (PDT) In-Reply-To: References: <20121016101957.GB53800@FreeBSD.org> <20121022174457.GB59689@FreeBSD.org> <5086AC06.5070405@a1poweruser.com> <5214043c002ef030f59c2045344b8725.squirrel@webmail.ee.ryerson.ca> <20121024111144.GF82606@e-new.0x20.net> Date: Thu, 25 Oct 2012 07:52:39 +0200 Message-ID: Subject: Re: FreeBSD in Google Code-In 2012? You can help too! From: =?ISO-8859-1?Q?Fernando_Apestegu=EDa?= To: Eitan Adler Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: David Magda , Lars Engels , freebsd-hackers@freebsd.org, Fbsd8 , "Wojciech A. Koszek" , freebsd-current@freebsd.org, freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 25 Oct 2012 05:52:42 -0000 On Wed, Oct 24, 2012 at 7:36 PM, Eitan Adler wrote: > On 24 October 2012 13:24, Fernando Apestegu=EDa > wrote: >> Also related to that, what about writing a section about redports[1] >> in the porter's handbook[2]? > > This is a good documentation task... but we need more *coding* tasks as w= ell. What about improving bsd ctags by adding a recursive mode like in GNU ctags= ? > >> And as a side question, shouldn't some (or all) of these tasks be >> listed also in JuniorTasks[3]? > > I'll link the page: good point. > -- > Eitan Adler From owner-freebsd-stable@FreeBSD.ORG Thu Oct 25 07:45:13 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9B39EC6; Thu, 25 Oct 2012 07:45:13 +0000 (UTC) (envelope-from edschouten@gmail.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 478348FC14; Thu, 25 Oct 2012 07:45:12 +0000 (UTC) Received: by mail-ob0-f182.google.com with SMTP id wc20so1671861obb.13 for ; Thu, 25 Oct 2012 00:45:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=jXEpe7KOj3g/pmeBQpTZ2OkGRltjDYScm9rvbskhEAI=; b=txKbqjGnmG0ZDxSg0Z6HWC+6lenVCLd5MW0Zwyl+SpdWBP74EDQnuKV9An06xNAqKb G9kuMQmFfHpQyEDTCXsc2SIgXBOy8mauuvGaNBrrLOhsB9ne/95F/D6zM13r5qap1S9q NVj3ZE5OBzEx9JBErst067jtkvPlyOLEo2V1hjDxj59TcZXX5vZMLlDvt+zupMheFidJ qLq4nh/qcRGIX9Oj0hQMV0mV/E4M9QTPcJcUrW7vN/g8NOHVv3eE+eS3T+9U76QJ107Z hZhGa61zi5XGVR7v5rGnqzFu1FwEbXq/3tJnlrQD5OMv6Zw8zbxKwEOxpJOwoe2n9gTK LRtQ== MIME-Version: 1.0 Received: by 10.60.171.10 with SMTP id aq10mr15358844oec.131.1351151111547; Thu, 25 Oct 2012 00:45:11 -0700 (PDT) Sender: edschouten@gmail.com Received: by 10.76.151.39 with HTTP; Thu, 25 Oct 2012 00:45:11 -0700 (PDT) In-Reply-To: References: <20121023142703.GA79098@icarus.home.lan> <20121023203928.GZ35915@deviant.kiev.zoral.com.ua> Date: Thu, 25 Oct 2012 09:45:11 +0200 X-Google-Sender-Auth: GhFMA-b27N5IrAUpu2sz42LL2n0 Message-ID: Subject: Re: pty/tty or signal strangeness, or grep/bsdgrep bug? From: Ed Schouten To: Konstantin Belousov Content-Type: text/plain; charset=UTF-8 Cc: Jeremy Chadwick , freebsd-stable@freebsd.org, jhb@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 25 Oct 2012 07:45:13 -0000 Hi all, 2012/10/23 Ed Schouten : > Will try to come up with a decent patch tomorrow evening. Ahem; the day after tomorrow. Jeremy, could you please try the following patch? http://80386.nl/pub/tty-bg-read.txt I decomposed the TTY read routine into four separate functions to improve clarity. While this was initially true, I think it's a pity the four functions are constantly becoming a bit more complex. The same issue is also present on the output path, but I have no idea how realistic/hard it is to fix this issue. Also, it might not really be an issue in practice. If you do a large write and become a non-foreground process group, you might be able to circumvent TOSTOP while the write() is in transit. Fixing this might be tedious, because we currently enforce that writes to a TTY are serialized. Blocking inside the write() might then cause a deadlock. But in my opinion, I would prefer the serialization over the enforcing of TOSTOP. Thanks again for reporting the issue! -- Ed Schouten From owner-freebsd-stable@FreeBSD.ORG Thu Oct 25 08:46:05 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F065D4A7 for ; Thu, 25 Oct 2012 08:46:05 +0000 (UTC) (envelope-from jdc@koitsu.strangled.net) Received: from qmta01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:16]) by mx1.freebsd.org (Postfix) with ESMTP id CB3BA8FC12 for ; Thu, 25 Oct 2012 08:46:05 +0000 (UTC) Received: from omta22.emeryville.ca.mail.comcast.net ([76.96.30.89]) by qmta01.emeryville.ca.mail.comcast.net with comcast id FLgg1k0051vN32cA1Lm59V; Thu, 25 Oct 2012 08:46:05 +0000 Received: from koitsu.strangled.net ([67.180.84.87]) by omta22.emeryville.ca.mail.comcast.net with comcast id FLm41k00C1t3BNj8iLm40V; Thu, 25 Oct 2012 08:46:05 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id F19D973A31; Thu, 25 Oct 2012 01:46:03 -0700 (PDT) Date: Thu, 25 Oct 2012 01:46:03 -0700 From: Jeremy Chadwick To: Ed Schouten Subject: Re: pty/tty or signal strangeness, or grep/bsdgrep bug? Message-ID: <20121025084603.GA1937@icarus.home.lan> References: <20121023142703.GA79098@icarus.home.lan> <20121023203928.GZ35915@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Konstantin Belousov , freebsd-stable@freebsd.org, jhb@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 25 Oct 2012 08:46:06 -0000 On Thu, Oct 25, 2012 at 09:45:11AM +0200, Ed Schouten wrote: > 2012/10/23 Ed Schouten : > > Will try to come up with a decent patch tomorrow evening. > > Ahem; the day after tomorrow. Jeremy, could you please try the following patch? > > http://80386.nl/pub/tty-bg-read.txt > > I decomposed the TTY read routine into four separate functions to > improve clarity. While this was initially true, I think it's a pity > the four functions are constantly becoming a bit more complex. > > The same issue is also present on the output path, but I have no idea > how realistic/hard it is to fix this issue. Also, it might not really > be an issue in practice. If you do a large write and become a > non-foreground process group, you might be able to circumvent TOSTOP > while the write() is in transit. > > Fixing this might be tedious, because we currently enforce that writes > to a TTY are serialized. Blocking inside the write() might then cause > a deadlock. But in my opinion, I would prefer the serialization over > the enforcing of TOSTOP. After the patch, testing with grep and cat, and checking cv/state for the latter case: (01:30:39 jdc@icarus) ~ $ csh % grep -r "-2011" . & [1] 1964 % jobs [1] + Suspended (tty input) grep -r -2011 . % fg grep -r -2011 . ^C % jobs % grep -r "-2011" . ^Z Suspended % bg [1] grep -r -2011 . & [1] + Suspended (tty input) grep -r -2011 . % fg grep -r -2011 . ^C % cat & [1] 2042 % jobs [1] + Suspended (tty input) cat % ps -auxwU jdc | grep cat jdc 2042 0.0 0.0 9908 1496 1 T 1:34AM 0:00.00 cat jdc 2044 0.0 0.0 16268 1864 1 S+ 1:34AM 0:00.00 grep cat % top -b -U jdc | grep cat 2042 jdc 1 20 0 9908K 1496K STOP 0 0:00 0.00% cat 2047 jdc 1 20 0 16268K 1864K piperd 0 0:00 0.00% grep cat % fg cat ^C % exit I do not get dropped characters or witness any other anomalies. I tested behaviour with /bin/sh, as well as bash. All seems good. > Thanks again for reporting the issue! No, thank *you* and others for looking + fixing it! :-) I assume a commit to HEAD + MFC in 2 weeks is in order? I'll update the PR with this part of our mail thread. -- | Jeremy Chadwick jdc@koitsu.org | | UNIX Systems Administrator http://jdc.koitsu.org/ | | Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Thu Oct 25 09:06:10 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7A87327F; Thu, 25 Oct 2012 09:06:10 +0000 (UTC) (envelope-from edschouten@gmail.com) Received: from mail-oa0-f54.google.com (mail-oa0-f54.google.com [209.85.219.54]) by mx1.freebsd.org (Postfix) with ESMTP id 282658FC18; Thu, 25 Oct 2012 09:06:09 +0000 (UTC) Received: by mail-oa0-f54.google.com with SMTP id n9so1758622oag.13 for ; Thu, 25 Oct 2012 02:06:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=4hDOC5d99v8c8rB1HgQhmn7kxCliRbeB8uX6vOqBWZg=; b=lxVnKlMWp0LAnxuOnwJQZXvOPVOs6EsqcZCfXscYcdSsYgt12eIy8RjyPN6V3oauSN Xwhd6zt0Co/ldYa78jOQADRQ14yKqav7pPTu4zNGOu6q36ls6JLBxVtvgo5qjdofI429 qJofUmJIRpXvQl4oq2BOLy+1o/6eFKNHp76N3ispfEP/Nozt/ORwBHe8nDOrDAtID3rS 67x+N/DBi1+dt1gZVJNgVJqA3DOq9/WBrBePq56Mo1i5y2DqMs8W95Tyqq1c/X4dJaib U1A/ecvzpfDGXCmw/F9vz8UqP3MIfW8EDPioHYN4YcZ5WJkbhdHbyNvwfPMRLNQTyhzn 7Ccg== MIME-Version: 1.0 Received: by 10.60.8.65 with SMTP id p1mr8989544oea.92.1351155969465; Thu, 25 Oct 2012 02:06:09 -0700 (PDT) Sender: edschouten@gmail.com Received: by 10.76.151.39 with HTTP; Thu, 25 Oct 2012 02:06:09 -0700 (PDT) In-Reply-To: <20121025084603.GA1937@icarus.home.lan> References: <20121023142703.GA79098@icarus.home.lan> <20121023203928.GZ35915@deviant.kiev.zoral.com.ua> <20121025084603.GA1937@icarus.home.lan> Date: Thu, 25 Oct 2012 11:06:09 +0200 X-Google-Sender-Auth: MPbFveQ0CtpRUocQ8ArhzRP_DOM Message-ID: Subject: Re: pty/tty or signal strangeness, or grep/bsdgrep bug? From: Ed Schouten To: Jeremy Chadwick Content-Type: text/plain; charset=UTF-8 Cc: Konstantin Belousov , freebsd-stable@freebsd.org, jhb@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 25 Oct 2012 09:06:10 -0000 2012/10/25 Jeremy Chadwick : > I assume a commit to HEAD + MFC in 2 weeks is in order? Yes. We're far too late to get this into 9.1, so I'll MFC it after the release. Patch committed as r242078! -- Ed Schouten From owner-freebsd-stable@FreeBSD.ORG Thu Oct 25 09:16:24 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 482CA785; Thu, 25 Oct 2012 09:16:24 +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 A7EE38FC08; Thu, 25 Oct 2012 09:16:23 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q9P9GKhB037284; Thu, 25 Oct 2012 12:16:20 +0300 (EEST) (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.5/8.14.5) with ESMTP id q9P9G870039447; Thu, 25 Oct 2012 12:16:08 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q9P9G8AA039446; Thu, 25 Oct 2012 12:16:08 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 25 Oct 2012 12:16:08 +0300 From: Konstantin Belousov To: Ed Schouten Subject: Re: pty/tty or signal strangeness, or grep/bsdgrep bug? Message-ID: <20121025091608.GH35915@deviant.kiev.zoral.com.ua> References: <20121023142703.GA79098@icarus.home.lan> <20121023203928.GZ35915@deviant.kiev.zoral.com.ua> <20121025084603.GA1937@icarus.home.lan> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="wLhpgGXSLEOCOdbs" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: Jeremy Chadwick , freebsd-stable@freebsd.org, jhb@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 25 Oct 2012 09:16:24 -0000 --wLhpgGXSLEOCOdbs Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Oct 25, 2012 at 11:06:09AM +0200, Ed Schouten wrote: > 2012/10/25 Jeremy Chadwick : > > I assume a commit to HEAD + MFC in 2 weeks is in order? >=20 > Yes. We're far too late to get this into 9.1, so I'll MFC it after the re= lease. >=20 > Patch committed as r242078! Release is performed on the separate branch, which has currently nothing to do with stable/9. The laster is open for normal MFC procedures, so I do not see how the merge of bugfix to stable is related to the release. --wLhpgGXSLEOCOdbs Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAlCJA1gACgkQC3+MBN1Mb4hzhgCfaNunx+lZGq+CKNLLHO/mggA6 B28AnjnCoUVTrmnVv7iepvkvp6AvlINF =0KET -----END PGP SIGNATURE----- --wLhpgGXSLEOCOdbs-- From owner-freebsd-stable@FreeBSD.ORG Thu Oct 25 09:37:37 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8026ED10; Thu, 25 Oct 2012 09:37:37 +0000 (UTC) (envelope-from edschouten@gmail.com) Received: from mail-oa0-f54.google.com (mail-oa0-f54.google.com [209.85.219.54]) by mx1.freebsd.org (Postfix) with ESMTP id 2A38B8FC0C; Thu, 25 Oct 2012 09:37:36 +0000 (UTC) Received: by mail-oa0-f54.google.com with SMTP id n9so1788559oag.13 for ; Thu, 25 Oct 2012 02:37:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=cFmqJU+BXsbANG5EyCqVnuzb29fAxhHJjXDwf5WszFA=; b=nXvKJHqSa8+Xh4A+wWDEK//nBFGb9jcfogz6NE7RNV1k2NOHHUrfksG27af4TAlXeA 9CJBpoAsuYSqpHKvgi0GUAP03yoGd34jJxkuSmcRhQepNgdhKQeF7RpT2cAkbFp8EdS2 bHopqxeG0m8za0Dr6SYJS3C8/WWOB35j6glD6DU8s+iSBxHH2QfAaBk55I3paPINyp4v g2AUDSVP8fSU3zGcM00MTzfCj1rFQkhhQgyHodQsFzszfrqDz/sar6PUyBpjQf/NUHEA N4WGpcjHCkwFR/lyaiCVhyfJHLaDdweaHpE42BN/lLZZWed62pm4K1TAAJZlKhkiwNqP bB6Q== MIME-Version: 1.0 Received: by 10.60.8.65 with SMTP id p1mr9047870oea.92.1351157856342; Thu, 25 Oct 2012 02:37:36 -0700 (PDT) Sender: edschouten@gmail.com Received: by 10.76.151.39 with HTTP; Thu, 25 Oct 2012 02:37:36 -0700 (PDT) In-Reply-To: <20121025091608.GH35915@deviant.kiev.zoral.com.ua> References: <20121023142703.GA79098@icarus.home.lan> <20121023203928.GZ35915@deviant.kiev.zoral.com.ua> <20121025084603.GA1937@icarus.home.lan> <20121025091608.GH35915@deviant.kiev.zoral.com.ua> Date: Thu, 25 Oct 2012 11:37:36 +0200 X-Google-Sender-Auth: 4jpon81WpdZ1nDgp9Eeq3OKYmns Message-ID: Subject: Re: pty/tty or signal strangeness, or grep/bsdgrep bug? From: Ed Schouten To: Konstantin Belousov Content-Type: text/plain; charset=UTF-8 Cc: Jeremy Chadwick , freebsd-stable@freebsd.org, jhb@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 25 Oct 2012 09:37:37 -0000 2012/10/25 Konstantin Belousov : > Release is performed on the separate branch, which has currently nothing > to do with stable/9. The laster is open for normal MFC procedures, so I > do not see how the merge of bugfix to stable is related to the release. I wasn't sure whether there still was some kind of freeze in effect or not. Thanks for clarifying. -- Ed Schouten From owner-freebsd-stable@FreeBSD.ORG Thu Oct 25 11:02:41 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EDD36DD8 for ; Thu, 25 Oct 2012 11:02:41 +0000 (UTC) (envelope-from lars@e-new.0x20.net) Received: from mail.0x20.net (mail.0x20.net [IPv6:2001:aa8:fffb:1::3]) by mx1.freebsd.org (Postfix) with ESMTP id 72CC28FC14 for ; Thu, 25 Oct 2012 11:02:41 +0000 (UTC) Received: from e-new.0x20.net (mail.0x20.net [IPv6:2001:aa8:fffb:1::3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.0x20.net (Postfix) with ESMTPS id DE2776A6001; Thu, 25 Oct 2012 13:02:39 +0200 (CEST) Received: from e-new.0x20.net (localhost [127.0.0.1]) by e-new.0x20.net (8.14.5/8.14.5) with ESMTP id q9PB2d79080648; Thu, 25 Oct 2012 13:02:39 +0200 (CEST) (envelope-from lars@e-new.0x20.net) Received: (from lars@localhost) by e-new.0x20.net (8.14.5/8.14.5/Submit) id q9PB2dun080579; Thu, 25 Oct 2012 13:02:39 +0200 (CEST) (envelope-from lars) Date: Thu, 25 Oct 2012 13:02:39 +0200 From: Lars Engels To: Zoran Kolic Subject: Re: 9.1 and intel graphics Message-ID: <20121025110239.GN82606@e-new.0x20.net> References: <20121021144845.GA1139@mycenae.sbb.rs> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="1HuzLmPZrG5RH6bG" Content-Disposition: inline In-Reply-To: <20121021144845.GA1139@mycenae.sbb.rs> X-Editor: VIM - Vi IMproved 7.3 X-Operation-System: FreeBSD 8.3-RELEASE-p4 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 25 Oct 2012 11:02:42 -0000 --1HuzLmPZrG5RH6bG Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Oct 21, 2012 at 04:48:45PM +0200, Zoran Kolic wrote: > > AFAIC Matthew Seaman already gave you a wonderful suggestion to add > > yourself to the group "operator" and just use the command "shutdown" > > with your own rights only. Did you try this suggestion? >=20 > Actually, it is wheel group. > To me it is "normal" to read mail and do something mundane in > console, to startx for browsing things that cannot be seen pro- > perly in lynx, to go back to console when done. I found no harm > su-ing in graphics and doing root work, like write to usb stick > or else. Eye catching is to use console in public, but... Nope, wheel let's you use su(1) but not shutdown(8). You need to be in the operator group for that. --1HuzLmPZrG5RH6bG Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlCJHE8ACgkQKc512sD3afgibgCgnzEaRr6rmV8Cam7RGB6m1AW2 Lv4Ani1putFYq3PEznDGXdeboTzWkE3c =Dxe5 -----END PGP SIGNATURE----- --1HuzLmPZrG5RH6bG-- From owner-freebsd-stable@FreeBSD.ORG Fri Oct 26 09:51:49 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 40CD6F0A for ; Fri, 26 Oct 2012 09:51:49 +0000 (UTC) (envelope-from serguey-grigoriev@yandex.ru) Received: from forward1h.mail.yandex.net (forward1h.mail.yandex.net [IPv6:2a02:6b8:0:f05::10]) by mx1.freebsd.org (Postfix) with ESMTP id E63058FC08 for ; Fri, 26 Oct 2012 09:51:47 +0000 (UTC) Received: from web18h.yandex.ru (web18h.yandex.ru [84.201.186.47]) by forward1h.mail.yandex.net (Yandex) with ESMTP id 4074D9E3608 for ; Fri, 26 Oct 2012 13:51:46 +0400 (MSK) Received: from 127.0.0.1 (localhost.localdomain [127.0.0.1]) by web18h.yandex.ru (Yandex) with ESMTP id E6A716B00127; Fri, 26 Oct 2012 13:51:45 +0400 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1351245106; bh=THeZxSAilNpwn05YzkA5XqbboFXtqlOs980uc01dk0o=; h=From:To:Subject:Date; b=ZI1LYHbD9gXXk9epdFYcKUz2scUFCQNq/eJIduNn/QSXVgPEqwDMcfiCiBHH2/Prf ZTl9v1UAlR/1Ozhnnwdp5ICGQeNh0iXc1Q+fP+7s6TqNR0LFmIDlPuYcdU88J0q5vv mf6u+fCM3cDZlHVeUMwv4TP0EmJ0p2yeu3HZeiaU= Received: from office-gw.skytel.spb.ru (office-gw.skytel.spb.ru [193.110.239.168]) by web18h.yandex.ru with HTTP; Fri, 26 Oct 2012 13:51:45 +0400 From: S.N.Grigoriev To: FreeBSD Stable Subject: HP Smart Array B120i MIME-Version: 1.0 Message-Id: <736871351245105@web18h.yandex.ru> Date: Fri, 26 Oct 2012 13:51:45 +0400 X-Mailer: Yamail [ http://yandex.ru ] 5.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 26 Oct 2012 09:51:49 -0000 Hi list, who can say does FreeBSD 8.x/9.x support HP Smart Array B120i controller? Thanks, Serguey. From owner-freebsd-stable@FreeBSD.ORG Fri Oct 26 12:33:51 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DBD41B87 for ; Fri, 26 Oct 2012 12:33:51 +0000 (UTC) (envelope-from nonesuch@longcount.org) Received: from mail-qc0-f182.google.com (mail-qc0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id 84B418FC08 for ; Fri, 26 Oct 2012 12:33:50 +0000 (UTC) Received: by mail-qc0-f182.google.com with SMTP id k19so1265198qcs.13 for ; Fri, 26 Oct 2012 05:33:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to :x-gm-message-state; bh=ucCwj57gKPoa72hnI9h1tbEpu9MEjsfmiABTmZFTHKY=; b=WsBjDIluFqkRFw3wYMuRkDVkAJQ20HbLNNxALqGDSD7UW8suO/rJ8oi+Ebi7TmPlt8 6I2f3LPgrtDgVNPh4Xa/cS5oZ/+6L2IKAslrdVG6i48Zdqg11/k4nuj/UqfC9RUtVbgM IPIpW6cMuVSMwvuGUK7tYMGNEK2oNDkO77Vj0ssOtKTcPS3FdzihcM+oqS4Q2jULgG5Q Ry946eQT16b7r0njc60fGJ4G2NxFbO0EZBYr9Wj3/RO+vxiuB82OgS8i83k4YjlAepKf G2mKQugnfubAR9cr+GYnnlCj+p4vDYnR+/yZabKHfOgAF8V1dYjynUWL4iBEgG+DGxrc PYEw== Received: by 10.224.60.18 with SMTP id n18mr3011372qah.36.1351254828748; Fri, 26 Oct 2012 05:33:48 -0700 (PDT) Received: from [192.168.11.108] (ool-4351fc48.dyn.optonline.net. [67.81.252.72]) by mx.google.com with ESMTPS id j9sm951453qac.15.2012.10.26.05.33.46 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 26 Oct 2012 05:33:46 -0700 (PDT) References: <736871351245105@web18h.yandex.ru> In-Reply-To: <736871351245105@web18h.yandex.ru> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <7427ED01-4E37-4BB6-B4A4-58A0BC7176AD@longcount.org> X-Mailer: iPhone Mail (9B206) From: Mark Saad Subject: Re: HP Smart Array B120i Date: Fri, 26 Oct 2012 08:33:44 -0400 To: "S.N.Grigoriev" X-Gm-Message-State: ALoCoQkxb+R1Mtr59CX8+ZO/W/3uz2TtGpPZ0Ddl/DTbV57oswJ4CP0SAqu3mGFekC3wd0ml6y/y Cc: FreeBSD Stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 26 Oct 2012 12:33:52 -0000 > Serguey I believe it's supported with geom_raid . I had a similar b1xx card in a h= p dl165 and using graid was the only solution to setup raid 1 or 1+0. it's a= hardware accelerated software raid , not a true smart array controller.=20 --- On Oct 26, 2012, at 5:51 AM, S.N.Grigoriev wro= te: > Hi list, >=20 > who can say does FreeBSD 8.x/9.x support HP Smart Array B120i controller? >=20 > Thanks, > Serguey. > _______________________________________________ > 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 Fri Oct 26 14:38:21 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AB3F9591 for ; Fri, 26 Oct 2012 14:38:21 +0000 (UTC) (envelope-from bounce-mc.us4_7045985.294733-stable=freebsd.org@mail51.us2.mcsv.net) Received: from mail51.us2.mcsv.net (mail51.us2.mcsv.net [173.231.139.51]) by mx1.freebsd.org (Postfix) with ESMTP id EB1718FC1A for ; Fri, 26 Oct 2012 14:38:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; s=k1; d=mail51.us2.mcsv.net; h=Subject:From:Reply-To:To:Date:Message-ID:List-Unsubscribe:Sender:Content-Type:Content-Transfer-Encoding; i=info=3Dshenaniganbooks.com@mail51.us2.mcsv.net; bh=doBQIIueYuhMrlm+KIDgPBp5q44=; b=ZP20fj+IP3U5r0/4rrL0uEu3cRx5bzr/JnBS1zTBQon9oqZuoYZhB7BKuBckTzZEeweT7DjbC6DD g6qqoZ7Eax+MDQvk/QP5RSOPPz8NLS3mtsRSLVK+Ad8hZJa1UBxGZ/nWGv5aJdOtqB7iBos9MA/c Th+opYalJwEZn3H49Fk= DomainKey-Signature: a=rsa-sha1; c=nofws; q=dns; s=k1; d=mail51.us2.mcsv.net; b=XNuBd6CblU7nmZ6ft2gB6AGwVCPCZkU44r8TPv3YYfBTfphRjR/xhmPVNYGBcNTV7rVtQ4jol2Ls tBV9W1k+Z9c0O4ZHN8v24l0GEl7mwKTF/Ep/ni8szNabFI4Ld/RnO6+HJGTbMIANs17qw8spFZIi 3d1x82q0U1P2EKqQBbg=; Received: from (127.0.0.1) by mail51.us2.mcsv.net (PowerMTA(TM) v3.5r16) id hhag5q0ik18a for ; Fri, 26 Oct 2012 14:35:06 +0000 (envelope-from ) Subject: =?utf-8?Q?Wisteria=27s=20Show=20and=20Tell=20Spectacular?= From: =?utf-8?Q?Shenanigan=20Books?= To: =?utf-8?Q??= Date: Fri, 26 Oct 2012 14:35:06 +0000 Message-ID: X-Mailer: MailChimp Mailer - **CID453b89552832d9181556** X-Campaign: mailchimpe10dd949afed747ef4f28a427.453b895528 X-campaignid: mailchimpe10dd949afed747ef4f28a427.453b895528 X-Report-Abuse: Please report abuse for this campaign here: http://www.mailchimp.com/abuse/abuse.phtml?u=e10dd949afed747ef4f28a427&id=453b895528&e=32d9181556 x-accounttype: pd Sender: "Shenanigan Books" x-mcda: FALSE MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: =?utf-8?Q?Shenanigan=20Books?= List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2012 14:38:21 -0000 [1]Shenanigan Books [2]Shenanigan Books Share the Wonder! Hot Off The Press! [3]Like us on Facebook twitter [4]Like us on Twitter twitter [5]Wisteria's Show and Tell Spectacular Wisteria's Show and Tell Spectacular: Older than the Dinosaurs How old is old? Wisteria just had to know because this week theme for Show and Tell was Something Really Old. [6]Susan Grigsby Illustrated by [7] Wisteria's something sweet [8]Alexandra Miller Ages 4-8 Hardcover 32 Pages ISBN 978-1-934860-12-0 Wisteria thinks she's the queen of Show & Tell. But her quest to delight and amuse her classmates usually ends in disaster. When asked to bring in something very old, Wisteria searches high and low for a spectacular idea.Wisteria thinks she's the queen of Show & Tell. But her quest to delight and amuse her classmates usually ends in disaster. ___________________ [9]Young Henry and the Dragon Young Henry and the Dragon [10]Jeanne Kaufman Illustrated by [11]Daria Tessler Ages 4-8 Hardcover 32 Pages ISBN 978-1934860113 Dimensions: 9.2 " x 11 " Lost in the woods, young Henry can't get his campfire started. His toes are cold and he can't even make a cup of tea. But when he tries to trick a very disagreeable dragon into snorting out a flame by making the dragon laugh, the dragon gets the last laugh. [12]Don't Let the Bedbugs Bite! Don't Let the Bedbugs Bite! [13]Niki Masse Schoenfeldt Illustrated by [14]Wes Thomas Ages 4-8 Hardcover 32 Pages ISBN 978-1-934860-13-7 Dimensions: 8.5 " x 11.25 " Price: $15.95 One wintery eve a ladybug decides to come in from the cold and warm herself in a little girl's bed. The girl thinks the visitor is a bedbug and reaches for a can of bug spray, but the ladybug stands her ground and convinces her that not all bugs are bad. [15]The Ballad of Booster Bogg The Ballad of Booster Bogg [16]Ellen Jackson Illustrated by [17]Christine Mannone Carolan Ages 4-8 Hardcover 32 Pages ISBN 978-1-934860-07-6 Dimensions: 8.25 " x 11.25 " Price: $15.95 How do you keep a free spirit like Booster Bogg at home? Many townfolks have tried and failed... but they all agree that theres something lovable about this wandering dog. Copyright © 2012 Shenanigan Books All rights reserved. Our mailing address is: Shenanigan Books o 84 River Road o Summit o New Jersey o 07901 [18]www.shenaniganbooks.com Sent to stable@freebsd.org -- [19]why did I get this? [20]unsubscribe from this list | [21]update subscription preferences Shenanigan Books · 84 River Road · Summit, NJ 07901 [open.php?u=e10dd949afed747ef4f28a427&id=453b895528&e=32d9181556] References 1. http://shenaniganbooks.us4.list-manage1.com/track/click?u=e10dd949afed747ef4f28a427&id=bbde390b65&e=32d9181556 2. http://shenaniganbooks.us4.list-manage2.com/track/click?u=e10dd949afed747ef4f28a427&id=b587318e98&e=32d9181556 3. http://shenaniganbooks.us4.list-manage1.com/track/click?u=e10dd949afed747ef4f28a427&id=c3945624b5&e=32d9181556 4. http://shenaniganbooks.us4.list-manage.com/track/click?u=e10dd949afed747ef4f28a427&id=83c087db38&e=32d9181556 5. http://shenaniganbooks.us4.list-manage1.com/track/click?u=e10dd949afed747ef4f28a427&id=a465dc45b5&e=32d9181556 6. http://shenaniganbooks.us4.list-manage.com/track/click?u=e10dd949afed747ef4f28a427&id=673ace7321&e=32d9181556 7. http://shenaniganbooks.us4.list-manage.com/track/click?u=e10dd949afed747ef4f28a427&id=acc560f9a2&e=32d9181556 8. http://shenaniganbooks.us4.list-manage1.com/track/click?u=e10dd949afed747ef4f28a427&id=c39f6c7be3&e=32d9181556 9. http://shenaniganbooks.us4.list-manage1.com/track/click?u=e10dd949afed747ef4f28a427&id=33316cb1a8&e=32d9181556 10. http://shenaniganbooks.us4.list-manage.com/track/click?u=e10dd949afed747ef4f28a427&id=f96ff27d4a&e=32d9181556 11. http://shenaniganbooks.us4.list-manage1.com/track/click?u=e10dd949afed747ef4f28a427&id=856b5a4bb0&e=32d9181556 12. http://shenaniganbooks.us4.list-manage1.com/track/click?u=e10dd949afed747ef4f28a427&id=77c54e9733&e=32d9181556 13. http://shenaniganbooks.us4.list-manage1.com/track/click?u=e10dd949afed747ef4f28a427&id=dfdeb80c58&e=32d9181556 14. http://shenaniganbooks.us4.list-manage1.com/track/click?u=e10dd949afed747ef4f28a427&id=5276bf6196&e=32d9181556 15. http://shenaniganbooks.us4.list-manage.com/track/click?u=e10dd949afed747ef4f28a427&id=21ca639f20&e=32d9181556 16. http://shenaniganbooks.us4.list-manage1.com/track/click?u=e10dd949afed747ef4f28a427&id=b926b1de8c&e=32d9181556 17. http://shenaniganbooks.us4.list-manage.com/track/click?u=e10dd949afed747ef4f28a427&id=c4e4c27cf6&e=32d9181556 18. http://shenaniganbooks.us4.list-manage1.com/track/click?u=e10dd949afed747ef4f28a427&id=f37772773b&e=32d9181556 19. http://shenaniganbooks.us4.list-manage.com/about?u=e10dd949afed747ef4f28a427&id=7bc10e82c7&e=32d9181556&c=453b895528 20. http://shenaniganbooks.us4.list-manage.com/unsubscribe?u=e10dd949afed747ef4f28a427&id=7bc10e82c7&e=32d9181556&c=453b895528 21. http://shenaniganbooks.us4.list-manage2.com/profile?u=e10dd949afed747ef4f28a427&id=7bc10e82c7&e=32d9181556 From owner-freebsd-stable@FreeBSD.ORG Fri Oct 26 20:19:11 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2F10FC8D; Fri, 26 Oct 2012 20:19:11 +0000 (UTC) (envelope-from jmg@h2.funkthat.com) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) by mx1.freebsd.org (Postfix) with ESMTP id 009378FC08; Fri, 26 Oct 2012 20:19:10 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id q9QKIKix039106 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 26 Oct 2012 13:18:20 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id q9QKIKgM039104; Fri, 26 Oct 2012 13:18:20 -0700 (PDT) (envelope-from jmg) Date: Fri, 26 Oct 2012 13:18:19 -0700 From: John-Mark Gurney To: Jim Harris Subject: Re: tws bug ? (LSI SAS 9750) Message-ID: <20121026201819.GF1563@funkthat.com> Mail-Followup-To: Jim Harris , Mike Tancsa , FreeBSD-STABLE Mailing List , delphij@freebsd.org References: <505CC8EC.4030608@sentex.net> <505CE601.4070106@sentex.net> <505D0846.8050108@sentex.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Fri, 26 Oct 2012 13:18:20 -0700 (PDT) Cc: delphij@freebsd.org, FreeBSD-STABLE Mailing List X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 26 Oct 2012 20:19:11 -0000 Jim Harris wrote this message on Fri, Sep 21, 2012 at 20:17 -0700: > On Fri, Sep 21, 2012 at 5:37 PM, Mike Tancsa wrote: > > On 9/21/2012 8:03 PM, Jim Harris wrote: > >>> . > >>> then a lot of > >>> . > >>> (probe65:tws0:0:65:0): INQUIRY. CDB: 12 0 0 0 24 0 > >>> (probe65:tws0:0:65:0): CAM status: Invalid Target ID > >>> (probe65:tws0:0:65:0): Error 22, Unretryable error > >>> (probe1:tws0:0:1:0): INQUIRY. CDB: 12 0 0 0 24 0 > >>> (probe1:tws0:0:1:0): CAM status: Invalid Target ID > >>> (probe1:tws0:0:1:0): Error 22, Unretryable error > >>> (probe2:tws0:0:2:0): INQUIRY. CDB: 12 0 0 0 24 0 > >>> (probe2:tws0:0:2:0): CAM status: Invalid Target ID > >>> . > >>> . > >>> . > >>> (probe63:tws0:0:63:0): INQUIRY. CDB: 12 0 0 0 24 0 > >>> (probe63:tws0:0:63:0): CAM status: Invalid Target ID > >>> (probe63:tws0:0:63:0): Error 22, Unretryable error > >>> (probe64:tws0:0:64:0): INQUIRY. CDB: 12 0 0 0 24 0 > >>> (probe64:tws0:0:64:0): CAM status: Invalid Target ID > >>> (probe64:tws0:0:64:0): Error 22, Unretryable error > >> > >> These can be ignored. CAM is just telling you that there are no > >> devices attached at these target IDs. > > > > What about a change similar to what Alexander Motin did in > > > > http://lists.freebsd.org/pipermail/svn-src-head/2012-June/038196.html > > Ah, yes. I was thinking you had CAM_DEBUG enabled which is why you > were seeing this spew - but that's not the case. This indeed should > be fixed and not just ignored. > > Seeing the attributions on Alexander's commit, you certainly seem to > have a monopoly on controllers that exhibit this problem on FreeBSD. > :) > > I believe the CAM_LUN_INVALID here should be fixed as well, similar to > the twa commit. If you send me a revised patch I will commit it. I'm seeing similar stuff on the hpt27xx driver: (probe18:hpt27xx0:0:18:0): INQUIRY. CDB: 12 0 0 0 24 0 (probe18:hpt27xx0:0:18:0): CAM status: Invalid Target ID (probe18:hpt27xx0:0:18:0): Error 22, Unretryable error Should I make a similar change in sys/dev/hpt27xx/osm_bsd.c? Looks like there are two CAM_TID_INVALID lines, but from reading the comments, only the second one should change... Correct? If so, I'll try making the change and make sure everything works well. Thanks. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-stable@FreeBSD.ORG Fri Oct 26 20:24:10 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F15EF6E; Fri, 26 Oct 2012 20:24:10 +0000 (UTC) (envelope-from jim.harris@gmail.com) Received: from mail-vb0-f54.google.com (mail-vb0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 79A348FC14; Fri, 26 Oct 2012 20:24:10 +0000 (UTC) Received: by mail-vb0-f54.google.com with SMTP id v11so4383522vbm.13 for ; Fri, 26 Oct 2012 13:24:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=97R75LAU4i46//ZOv1pOt7wKXo6tBqaBrvyDYttbfL8=; b=pkMNB2dZI2JzKMMRoqcD71xxCPwWiOpnch26UyOVq+nj5UhA94AhBe4YJ/3vTItCNn 3RQe18YCaqRgNzfvK48stqp4YdMyoT6ejjkmlg0I4ICYXPP23dqgHmzavsG8plEaTAKL Um2TwabIJRPJLcvPvDXNjDvmHIQ2H48cAouxmKP7Sw3Gxct0ErpQ+nXb8YXIeRarRB3l D9xd7I2JJwBMFY06BV06NM9BnUgR4DlkeDSXvIppn52Fm66BgO5bfnGRJKelbT3rBHZA 287TCFuN6LL/iZg8FE9L2yqCytiSzaY8gX8RgR1NeX83GutkSn3+pzyoGcUTnSLJxuWL UCTw== MIME-Version: 1.0 Received: by 10.52.75.70 with SMTP id a6mr31659323vdw.5.1351283049579; Fri, 26 Oct 2012 13:24:09 -0700 (PDT) Received: by 10.58.225.2 with HTTP; Fri, 26 Oct 2012 13:24:09 -0700 (PDT) In-Reply-To: <20121026201819.GF1563@funkthat.com> References: <505CC8EC.4030608@sentex.net> <505CE601.4070106@sentex.net> <505D0846.8050108@sentex.net> <20121026201819.GF1563@funkthat.com> Date: Fri, 26 Oct 2012 13:24:09 -0700 Message-ID: Subject: Re: tws bug ? (LSI SAS 9750) From: Jim Harris To: Jim Harris , Mike Tancsa , FreeBSD-STABLE Mailing List , delphij@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 26 Oct 2012 20:24:11 -0000 On Fri, Oct 26, 2012 at 1:18 PM, John-Mark Gurney wrote: > > I'm seeing similar stuff on the hpt27xx driver: > (probe18:hpt27xx0:0:18:0): INQUIRY. CDB: 12 0 0 0 24 0 > (probe18:hpt27xx0:0:18:0): CAM status: Invalid Target ID > (probe18:hpt27xx0:0:18:0): Error 22, Unretryable error > > Should I make a similar change in sys/dev/hpt27xx/osm_bsd.c? Looks like > there are two CAM_TID_INVALID lines, but from reading the comments, only > the second one should change... > > Correct? If so, I'll try making the change and make sure everything > works well. > Yes - I agree that a similar change is needed, and only to the second one in that file. From owner-freebsd-stable@FreeBSD.ORG Fri Oct 26 23:10:02 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EAA6FE6C for ; Fri, 26 Oct 2012 23:10:02 +0000 (UTC) (envelope-from signup-mc.us4_7045985.90281-stable=freebsd.org@mail2.mcsignup.com) Received: from mail2.mcsignup.com (mail2.mcsignup.com [72.26.195.73]) by mx1.freebsd.org (Postfix) with ESMTP id A4A6C8FC08 for ; Fri, 26 Oct 2012 23:10:02 +0000 (UTC) Received: by mail2.mcsignup.com (PowerMTA(TM) v3.5r16) id hhcc4k0ik18v for ; Fri, 26 Oct 2012 22:54:54 +0000 (envelope-from ) Sender: =?utf-8?Q?Shenanigan=20Books?= From: =?utf-8?Q?Shenanigan=20Books?= To: stable@freebsd.org Subject: Homeschool: You are now unsubscribed Date: Fri, 26 Oct 2012 22:54:53 +0000 Content-Type: multipart/mixed; boundary="=_784116859c16f269e85a9c645f54ba92" MIME-Version: 1.0 Message-ID: <0.2.9.187.1CDB3CCE9DC0788.0@mail2.mcsignup.com> X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 26 Oct 2012 23:10:03 -0000 This is a message in Mime Format. If you see this, your mail reader does not support this format. --=_784116859c16f269e85a9c645f54ba92 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit ** We have removed your email address from our list. ------------------------------------------------------------ We're sorry to see you go. Was this a mistake? Did you forward one of our emails to a friend, and they clicked the unsubscribe link not realizing they were in fact unsubscribing you from this list? If this was a mistake, you can re-subscribe at: Subscribe (http://shenaniganbooks.us4.list-manage1.com/subscribe?u=e10dd949afed747ef4f28a427&id=7bc10e82c7) For questions or comments, please contact us at: artisanpub@comcast.net (mailto:artisanpub@comcast.net) --=_784116859c16f269e85a9c645f54ba92-- From owner-freebsd-stable@FreeBSD.ORG Sat Oct 27 13:00:51 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 14F7330A for ; Sat, 27 Oct 2012 13:00:51 +0000 (UTC) (envelope-from prvs=16475b8f6d=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id 921328FC08 for ; Sat, 27 Oct 2012 13:00:50 +0000 (UTC) Received: from r2d2 ([188.220.16.49]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50000846718.msg for ; Sat, 27 Oct 2012 14:00:48 +0100 X-Spam-Processed: mail1.multiplay.co.uk, Sat, 27 Oct 2012 14:00:48 +0100 (not processed: message from valid local sender) X-MDRemoteIP: 188.220.16.49 X-Return-Path: prvs=16475b8f6d=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-stable@freebsd.org Message-ID: <2DC1C56CFFF24FE0B17C34AD21A7DFAA@multiplay.co.uk> From: "Steven Hartland" To: Subject: mfi panic on recused on non-recusive mutex MFI I/O lock Date: Sat, 27 Oct 2012 14:00:41 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 27 Oct 2012 13:00:51 -0000 Testing a new machine which is based on 8.3-RELEASE with the mfi driver from 8-STABLE and just got a panic. The below is translation of the hand copied from console:- mfi0: sense error 0, sense_key 0, asc 0, ascq 0 mfisyspd5: hard error cmd=write 90827650-90827905 mfi0: I/O error, status= 46 scsi_status= 240 mfi0: sense error 0, sense_key 0, asc 0, ascq 0 mfisyspd5: hard error cmd=write 90827394-90827649 mfi0: I/O error, status= 46 scsi_status= 240 mfi0: sense error 0, sense_key 0, asc 0, ascq 0 mfisyspd5: hard error cmd=write 90827138-90827393 mfi0: I/O error, status= 46 scsi_status= 240 mfi0: sense error 0, sense_key 0, asc 0, ascq 0 mfisyspd5: hard error cmd=write 90826882-90827137 mfi0: I/O error, status= 2 scsi_status= 2 mfi0: sense error 112, sense_key 6, asc 41, ascq 0 mfisyspd4: hard error cmd=write 90830466-90830721 mfi0: I/O error, status= 2 scsi_status= 2 mfi0: sense error 112, sense_key 6, asc 41, ascq 0 mfisyspd5: hard error cmd=write 90830722-90830977 mfi0: Adapter RESET condition detected mfi0: First state FW reset initiated... mfi0: ADP_RESET_TBOLT: HostDiag=a0 mfi0: first state of reset complete, second state initiated... mfi0: Second state FW reset initiated... panic: _mtx_lock_sleep: recursed on non-recusive mutex MFI I/O lock @ /usr/src/sys/dev/mfi/mfi_tbolt:346 cpuid = 6 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a kdb_backtrace() at kdb_backtrace+0x37 panic() at panic+0x178 _mtx_lock_sleep() at _mtx_lock_sleep+0x152 _mtx_lock_flags() at _mtx_lock_flags+0x80 mfi_tbolt_init_MFI_queue() at mfi_tbolt_init_MFI_queue+0x72 mfi_timeout() at mfi_timeout+0x27 softclock() at softclock+0x2aa intr_event_execute_handlers() at intr_event_execute_handlers+0x66 ithread_loop() at ithread_loop+0xb2 fork_exit() at fork_exit+0x135 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff80005ccd00, rbp = 0 --- KDB: enter panic [thread pid 12 tid 100020 ] Stopperd at kdb_enter+0x3b: movq $0,0x51cb32(%rip) db> So questions:- 1. What are the "hard error" errors? The machine was testing IO with dd but due to the panic I cant tell if that was the cause. 2. Looking at the code this seems like the reset was tripped by firmware bug, is that the case? 3. Is the fix the panic a simple one we cat test? Regards Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-stable@FreeBSD.ORG Sat Oct 27 20:46:56 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 403DF524; Sat, 27 Oct 2012 20:46:56 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-la0-f54.google.com (mail-la0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 7665A8FC0A; Sat, 27 Oct 2012 20:46:55 +0000 (UTC) Received: by mail-la0-f54.google.com with SMTP id e12so3868801lag.13 for ; Sat, 27 Oct 2012 13:46:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=DjIENDFgGyXEh8Clk8GL7SthpRi8J2NZKdSizlEo4jY=; b=vSrMBISN3/KXeLsZJl9KcfX4E7bRg7RRMabRTMrx5WrZpK+xqRrhCQ353xnSrl/6Dr NrytOvWs0slBQgpBFXNQnF0Xrn2sVibZ95oofVN5FRHK0FJavNCkIXDdqluf8vWT/2V+ EmYq80xewrxqdvduVRvxGFrY4icAoonE9u6Y35+L00dnB0cRtVmj3hAYfWAG8eoVoOHg fIjszpy5xAi8N9cIrsVF+NXvt5qbTp90tgGtlfc8zPITuNKw0B4y44sxPPxxE4WOYIkY rR4kChdCBzyUeg/2ObQzMgKLNbqkXxNjwz0q7ryxS2TQKn4hNS94IxlDZgSOwEApbAfu ODRg== MIME-Version: 1.0 Received: by 10.152.132.3 with SMTP id oq3mr23150138lab.18.1351370813789; Sat, 27 Oct 2012 13:46:53 -0700 (PDT) Sender: asmrookie@gmail.com Received: by 10.112.30.37 with HTTP; Sat, 27 Oct 2012 13:46:53 -0700 (PDT) In-Reply-To: References: <5022840B.3060708@omnilan.de> <5048C6D1.8020007@omnilan.de> Date: Sat, 27 Oct 2012 21:46:53 +0100 X-Google-Sender-Auth: q43k9p_yS0mpXCrqUN8hSyviGr4 Message-ID: Subject: Re: lock violation in unionfs (9.0-STABLE r230270) From: Attilio Rao To: Harald Schmalzbauer Content-Type: text/plain; charset=UTF-8 Cc: stable@freebsd.org, daichi@freebsd.org, Pavel Polyakov X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: attilio@FreeBSD.org List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Oct 2012 20:46:56 -0000 On Sat, Sep 8, 2012 at 12:48 AM, Attilio Rao wrote: > On Thu, Sep 6, 2012 at 4:52 PM, Harald Schmalzbauer > wrote: >> schrieb Attilio Rao am 09.08.2012 20:26 (localtime): >>> On 8/8/12, Harald Schmalzbauer wrote: >>>> schrieb Pavel Polyakov am 06.03.2012 11:20 (localtime): >>>>>>> mount -t unionfs -o noatime /usr /mnt >>>>>>> >>>>>>> insmntque: mp-safe fs and non-locked vp: 0xfffffe01d96704f0 is not >>>>>>> exclusive locked but should be >>>>>>> KDB: enter: lock violation >>>>>> Pavel, >>>>>> can you give a spin to this patch?: >>>>>> http://www.freebsd.org/~attilio/unionfs_missing_insmntque_lock.patch >>>>>> >>>>>> I think that the unlocking is due at that point as the vnode lock can >>>>>> be switch later on. >>>>>> >>>>>> Let me know what you think about it and what the test does. >>>>> Thanks! >>>>> This patch fixes the problem with lock violation. Sorry I've tested it so >>>>> late. >>>> Hello, >>>> >>>> this patch still applies cleanly to RELENG_9_1. Was there another fix >>>> for the issue or has it just not been PR-sent and thus forgotten? >>> Can you and Pavel try the attached patch? Unfortunately I had no time >>> to test it, I just made in 5 free mins from a non-FreeBSD workstation, >> >> Sorry, couldn't test earlier, but now I did: >> With this patch applied the machine hangs without debug kernel and the >> latter gives the following panic: >> System call nmount returning with the following locks held: >> exclusive lockmgr ufs (ufs) r = 0 (0xc5438278) locked @ >> src/sys/fs/unionfs/union_vnops.c:1938 >> panic: witness_warn >> cpuid = 0 >> KDB: stack backtrace: >> db_trace_self_wrapper(c0a04f7f,c0c112c4,d1de3bb4,c097aa8c,fc,...) at >> db_trace_self_wrapper+0x26 >> kdb_backtrace(c0a4965f,0,c09c2ede3c1c,0,...) at kdb_backtrace+0x2a >> witness_warn(2,0,c0a4ac34,c0a0990a,286,...) at witness_warn+0x1e4 >> syscall(d1de3d08) ar syscall+0x415 >> Xint0x80_syscall() at Xint0x80_syscall+0x21 >> --- syscall (0, FreeBSD ELF32, nosys), eip = 0x280b883f,esp = >> 0xbfbfe46c, ebp = 0xbfbfede8 --- >> KDB: enter: panic >> [ thread pid 86 tid 100054 ] >> Stopped ad kdb_enter+0x3a: movl $0,kdb_why >> db> bt >> Tracing pid 86 tid 100054 td 0xc541b000 >> kdb_enter(c0a00d16,c0a09130,0,0,0,...) at panix+0x190 >> witness_warn(2,0,x0a4ac34,c0a0990a,286,...) at witness_warn+0x1e4 >> syscall(d1de3d08) at syscall+0x415 >> Xint0x80_syscall() at Xint0x80_syscall+0x21 >> >> Hmm, I guess I forgot to install kernel debug symbols... >> Coming back if I have more > > Unfortunately unionfs does very wrong things with the insmntque() locking. > It basically expects the vnode to return locked in the same way > requested by the precedent namei() (when that happens) but when you do > insmntque() you can only have an LK_EXCLUSIVE lock on the vnode. Hello, the following patch should workout the issues around unionfs_nodeget() a bit: http://www.freebsd.org/~attilio/unionfs_nodeget2.patch Unfortunately unionfs code is rather messy in the lookup path about locking requirements so follow what it needs to be done there is a bit difficult. I have no way to test this patch, so it is just test-compiled at the moment, but I would need that you also test lookup path (so directory "ls", find(1) on the whole unionfs volume, etc.) to validate it someway. If it panics again, please provide the kernel.debug and the vmcore.X file. Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-stable@FreeBSD.ORG Sat Oct 27 21:07:51 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5FBFFA97; Sat, 27 Oct 2012 21:07:51 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-la0-f54.google.com (mail-la0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 9DA7D8FC14; Sat, 27 Oct 2012 21:07:50 +0000 (UTC) Received: by mail-la0-f54.google.com with SMTP id e12so3875186lag.13 for ; Sat, 27 Oct 2012 14:07:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=fJpPlXpVuxUiK8L40K3oZf9vE5jFjuJupdTkvHVOUbk=; b=mHPYB2V13B6MLcs5MFbUbhv08aFOzlVSTdQNMsencTyMRSje3pYH5B9e7eYAzAfPZy uYwm8pc/3Mxl4L50OdiWl1uF9w321wEuuetWpPK3I+faDCc7j0OFnwqzTTQFqE1w2dVM DeL+RomPUnxduRjyVsFekifzOTmHDHcluaimTdbH1uaycJEEyHhHHMhyxtFiZdX3tFx4 B5xzEzUvceXgMAmk0RNr6+zEqSe6evm/WJXPZTbRYZo6SvxqenyBdvc3Gi6WCpbtjQCv cnpubSnM0ZatwVTndQzzkIoZR5l8tpDP6zQoVc1VtRV9uOMWGNGsHDo8iEoPv+tyN/OV sbvQ== MIME-Version: 1.0 Received: by 10.152.123.103 with SMTP id lz7mr23348684lab.21.1351372069237; Sat, 27 Oct 2012 14:07:49 -0700 (PDT) Sender: asmrookie@gmail.com Received: by 10.112.30.37 with HTTP; Sat, 27 Oct 2012 14:07:49 -0700 (PDT) In-Reply-To: References: <5022840B.3060708@omnilan.de> <5048C6D1.8020007@omnilan.de> Date: Sat, 27 Oct 2012 22:07:49 +0100 X-Google-Sender-Auth: NNv21HsIrAxkHRxk2IkZmS-fXeI Message-ID: Subject: Re: lock violation in unionfs (9.0-STABLE r230270) From: Attilio Rao To: Harald Schmalzbauer Content-Type: text/plain; charset=UTF-8 Cc: stable@freebsd.org, daichi@freebsd.org, Pavel Polyakov X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: attilio@FreeBSD.org List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Oct 2012 21:07:51 -0000 On Sat, Oct 27, 2012 at 9:46 PM, Attilio Rao wrote: > On Sat, Sep 8, 2012 at 12:48 AM, Attilio Rao wrote: >> On Thu, Sep 6, 2012 at 4:52 PM, Harald Schmalzbauer >> wrote: >>> schrieb Attilio Rao am 09.08.2012 20:26 (localtime): >>>> On 8/8/12, Harald Schmalzbauer wrote: >>>>> schrieb Pavel Polyakov am 06.03.2012 11:20 (localtime): >>>>>>>> mount -t unionfs -o noatime /usr /mnt >>>>>>>> >>>>>>>> insmntque: mp-safe fs and non-locked vp: 0xfffffe01d96704f0 is not >>>>>>>> exclusive locked but should be >>>>>>>> KDB: enter: lock violation >>>>>>> Pavel, >>>>>>> can you give a spin to this patch?: >>>>>>> http://www.freebsd.org/~attilio/unionfs_missing_insmntque_lock.patch >>>>>>> >>>>>>> I think that the unlocking is due at that point as the vnode lock can >>>>>>> be switch later on. >>>>>>> >>>>>>> Let me know what you think about it and what the test does. >>>>>> Thanks! >>>>>> This patch fixes the problem with lock violation. Sorry I've tested it so >>>>>> late. >>>>> Hello, >>>>> >>>>> this patch still applies cleanly to RELENG_9_1. Was there another fix >>>>> for the issue or has it just not been PR-sent and thus forgotten? >>>> Can you and Pavel try the attached patch? Unfortunately I had no time >>>> to test it, I just made in 5 free mins from a non-FreeBSD workstation, >>> >>> Sorry, couldn't test earlier, but now I did: >>> With this patch applied the machine hangs without debug kernel and the >>> latter gives the following panic: >>> System call nmount returning with the following locks held: >>> exclusive lockmgr ufs (ufs) r = 0 (0xc5438278) locked @ >>> src/sys/fs/unionfs/union_vnops.c:1938 >>> panic: witness_warn >>> cpuid = 0 >>> KDB: stack backtrace: >>> db_trace_self_wrapper(c0a04f7f,c0c112c4,d1de3bb4,c097aa8c,fc,...) at >>> db_trace_self_wrapper+0x26 >>> kdb_backtrace(c0a4965f,0,c09c2ede3c1c,0,...) at kdb_backtrace+0x2a >>> witness_warn(2,0,c0a4ac34,c0a0990a,286,...) at witness_warn+0x1e4 >>> syscall(d1de3d08) ar syscall+0x415 >>> Xint0x80_syscall() at Xint0x80_syscall+0x21 >>> --- syscall (0, FreeBSD ELF32, nosys), eip = 0x280b883f,esp = >>> 0xbfbfe46c, ebp = 0xbfbfede8 --- >>> KDB: enter: panic >>> [ thread pid 86 tid 100054 ] >>> Stopped ad kdb_enter+0x3a: movl $0,kdb_why >>> db> bt >>> Tracing pid 86 tid 100054 td 0xc541b000 >>> kdb_enter(c0a00d16,c0a09130,0,0,0,...) at panix+0x190 >>> witness_warn(2,0,x0a4ac34,c0a0990a,286,...) at witness_warn+0x1e4 >>> syscall(d1de3d08) at syscall+0x415 >>> Xint0x80_syscall() at Xint0x80_syscall+0x21 >>> >>> Hmm, I guess I forgot to install kernel debug symbols... >>> Coming back if I have more >> >> Unfortunately unionfs does very wrong things with the insmntque() locking. >> It basically expects the vnode to return locked in the same way >> requested by the precedent namei() (when that happens) but when you do >> insmntque() you can only have an LK_EXCLUSIVE lock on the vnode. > > Hello, > the following patch should workout the issues around unionfs_nodeget() a bit: > http://www.freebsd.org/~attilio/unionfs_nodeget2.patch > > Unfortunately unionfs code is rather messy in the lookup path about > locking requirements so follow what it needs to be done there is a bit > difficult. > I have no way to test this patch, so it is just test-compiled at the > moment, but I would need that you also test lookup path (so directory > "ls", find(1) on the whole unionfs volume, etc.) to validate it > someway. On a second thought, I think that locking in lookup (and also other operations) is so fragile and difficult to follow that it makes all vnops real locking landmines. I think that the following patch fixes the insmntque insertion and follows the old approach well enough to be committed separately: http://www.freebsd.org/~attilio/unionfs_nodeget3.patch However I strongly suggest that someone does review & sweep all the locking from nodeget and related functions removing the tedious lkflags conditional, reinforcing and expliciting locking rules within functions, checking out for races (which I'm sure are quite a few by the fact that vn lock gets dropped indiscriminately in many points) and possibly review the highly proficient usage of LK_RETRY that I'm sure is not always safe. All these steps should really be carried out separately. Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein