From owner-freebsd-stable@FreeBSD.ORG Sun Jun 30 01:19:23 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 4703AC7B for ; Sun, 30 Jun 2013 01:19:23 +0000 (UTC) (envelope-from steven@multiplay.co.uk) Received: from mail-wi0-f181.google.com (mail-wi0-f181.google.com [209.85.212.181]) by mx1.freebsd.org (Postfix) with ESMTP id D58051C2F for ; Sun, 30 Jun 2013 01:19:22 +0000 (UTC) Received: by mail-wi0-f181.google.com with SMTP id hq4so2032774wib.2 for ; Sat, 29 Jun 2013 18:19:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:from:to:subject:date:mime-version:content-type :content-transfer-encoding:x-priority:x-msmail-priority:x-mailer :x-mimeole:x-gm-message-state; bh=DYCmh//tDvrGX6DWGLHD1BzpIa+UMUWW6NfA1SM5j+c=; b=Lg1woeP2FowTqTXvpxn9XCHRRr5pkjOMO/l8s01gXlX32FSwSeawV1UywpcFjsx3VB mmeB4ppoTjZMxvpGrIobQ3UPbX27ZUnW6Ku62CE2CjOct5VcHVJbgCvvbLg6gQtqjTs6 bmEnMqYVN4pF5/SmAKWNRPoCzFTFG79vm0FLIJKB3qFVlbdZ3an+MDxnnvdiQ1OYAMVX r09CeYPyJGvVARNTD3Pu/vA8ji2xR77Swt7sadIOyku9nOIkTyFI+U98kTJhamP47mPG K5HFM1ndCMFxJwTrQMPD81aGFvZxvkJJMRfWKL9xKoq5zn5HOdj6KawXuxtm94zmLqxO dCFA== X-Received: by 10.180.160.203 with SMTP id xm11mr8198311wib.58.1372555156058; Sat, 29 Jun 2013 18:19:16 -0700 (PDT) Received: from r2d2 (82-69-141-170.dsl.in-addr.zen.co.uk. [82.69.141.170]) by mx.google.com with ESMTPSA id b20sm7197616wiw.4.2013.06.29.18.19.14 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Sat, 29 Jun 2013 18:19:15 -0700 (PDT) Message-ID: <77F3F7FC35D843ADA82D54EF37249ED0@multiplay.co.uk> From: "Steven Hartland" To: Subject: locks under printf(9) and WITNESS = panic? Date: Sun, 30 Jun 2013 02:19:24 +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-Gm-Message-State: ALoCoQn6Df3NGpd0WurXrk2a1vud/KjlbwEQ5wpvVTrACjKoCXTBPV9YWq9TXiRfDxtTB4ijGomc 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, 30 Jun 2013 01:19:23 -0000 when booting stable/9 under a debug kernel with WITNESS enabled and verbose I get the following panic.. It seems very much like the discussion from a year back on current: http://lists.freebsd.org/pipermail/freebsd-current/2012-January/031375.html Any ideas? uhub1: on usbus1 uhub0: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered panic: mtx_lock_spin: recursed on non-recursive mutex cnputs_mtx @ /usr/src/sys/kern/kern_cons.c:500 cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a/frame 0xffffff9185023940 kdb_backtrace() at kdb_backtrace+0x37/frame 0xffffff9185023a00 panic() at panic+0x1d8/frame 0xffffff9185023b00 _mtx_lock_spin_flags() at _mtx_lock_spin_flags+0x123/frame 0xffffff9185023b40 cnputs() at cnputs+0x7a/frame 0xffffff9185023b60 putbuf() at putbuf+0xbf/frame 0xffffff9185023be0 kvprintf() at kvprintf+0x83/frame 0xffffff9185023d20 vprintf() at vprintf+0x85/frame 0xffffff9185024580 printf() at printf+0x67/frame 0xffffff9185024660 witness_checkorder() at witness_checkorder+0x794/frame 0xffffff9185024720 _mtx_lock_spin_flags() at _mtx_lock_spin_flags+0x94/frame 0xffffff9185024760 uart_cnputc() at uart_cnputc+0x3e/frame 0xffffff9185024780 cnputc() at cnputc+0x4c/frame 0xffffff91850247b0 cnputs() at cnputs+0x26/frame 0xffffff91850247d0 putbuf() at putbuf+0xbf/frame 0xffffff9185024850 kvprintf() at kvprintf+0x83/frame 0xffffff9185024990 vprintf() at vprintf+0x85/frame 0xffffff91850251f0 printf() at printf+0x67/frame 0xffffff91850252d0 witness_checkorder() at witness_checkorder+0x794/frame 0xffffff9185025390 _mtx_lock_spin_flags() at _mtx_lock_spin_flags+0x94/frame 0xffffff91850253d0 cpu_new_callout() at cpu_new_callout+0x4f/frame 0xffffff9185025400 callout_reset_on() at callout_reset_on+0xde/frame 0xffffff9185025450 sleepq_set_timeout() at sleepq_set_timeout+0x8b/frame 0xffffff9185025490 _sleep() at _sleep+0x3c1/frame 0xffffff9185025520 usb_pause_mtx() at usb_pause_mtx+0x40/frame 0xffffff9185025540 usbd_transfer_unsetup_sub() at usbd_transfer_unsetup_sub+0x134/frame 0xffffff9185025560 usbd_transfer_unsetup() at usbd_transfer_unsetup+0x19b/frame 0xffffff91850255a0 usbd_ctrl_transfer_setup() at usbd_ctrl_transfer_setup+0x89/frame 0xffffff91850255f0 usbd_do_request_flags() at usbd_do_request_flags+0x327/frame 0xffffff91850256a0 usbd_req_get_desc() at usbd_req_get_desc+0xe4/frame 0xffffff9185025730 usbd_req_get_config_desc() at usbd_req_get_config_desc+0x64/frame 0xffffff9185025780 usbd_req_get_config_desc_full() at usbd_req_get_config_desc_full+0x5a/frame 0xffffff9185025810 usbd_set_config_index() at usbd_set_config_index+0x77/frame 0xffffff91850258b0 usb_alloc_device() at usb_alloc_device+0x6e7/frame 0xffffff91850259d0 uhub_explore() at uhub_explore+0x59b/frame 0xffffff9185025a40 usb_bus_explore() at usb_bus_explore+0xd2/frame 0xffffff9185025a70 usb_process() at usb_process+0xc3/frame 0xffffff9185025aa0 fork_exit() at fork_exit+0x135/frame 0xffffff9185025af0 fork_trampoline() at fork_trampoline+0xe/frame 0xffffff9185025af0 --- trap 0, rip = 0, rsp = 0xffffff9185025bb0, rbp = 0 --- KDB: enter: panic [ thread pid 15 tid 100106 ] Stopped at kdb_enter+0x3b: movq $0,0x7cb632(%rip) From owner-freebsd-stable@FreeBSD.ORG Sun Jun 30 14:22:21 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 6D6D041E; Sun, 30 Jun 2013 14:22:21 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) by mx1.freebsd.org (Postfix) with ESMTP id ABA821FE2; Sun, 30 Jun 2013 14:22:19 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id r5UEM9O2027295; Mon, 1 Jul 2013 00:22:10 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Mon, 1 Jul 2013 00:22:09 +1000 (EST) From: Ian Smith To: Adrian Chadd Subject: Re: USB ports on Lenovo T400 do not work after a suspend/resume In-Reply-To: Message-ID: <20130630233640.Y23789@sola.nimnet.asn.au> References: <20130621220013.X55167@sola.nimnet.asn.au> <20130626152833.M78748@sola.nimnet.asn.au> <20130626195154.GK88288@e-new.0x20.net> <20130627213331.W26984@sola.nimnet.asn.au> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-acpi@freebsd.org, freebsd-stable@freebsd.org, Lars Engels , freebsd-usb@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, 30 Jun 2013 14:22:21 -0000 On Sat, 29 Jun 2013, Adrian Chadd wrote: > On 27 June 2013 04:58, Ian Smith wrote: > > We don't yet know if this is a bus, ACPI &/or USB issue. Home yet? :) > > Yup: > > http://people.freebsd.org/~adrian/usb/ > > dmesg.boot = dmesg at startup > > 1 - after powerup, usb device in > 2 - after acpiconf -s3 suspend/resume, w/ a USB device plugged in > 3 - after acpiconf -s3 suspend/resume, with a USB device removed > before suspend/resume After removing [numbers] (for WITNESS?), diff started making sense. The below is between the first and second suspend/resume cycles in dmesg-3.txt, encompassing the others. Nothing of note that I can see, if that usb hub-to-bus remapping is normal. As you said, 'CPU0: local APIC error 0x40' looks maybe sus. Maybe someone who knows might comment on that? Just checking: you've tried other USB devices apart from uftdi0? Out of ideas, and my depth, Ian ======= --- dm3.a 2013-06-30 21:49:48.000000000 +1000 +++ dm3.b 2013-06-30 21:50:30.000000000 +1000 @@ -1,23 +1,21 @@ -ugen3.2: at usbus3 -[] uftdi0: on usbus3 +ugen3.2: at usbus3 (disconnected) +[] uftdi0: at uhub4, port 2, addr 2 (disconnected) (ada0:ahcich0:0:0:0): spin-down [] acpi_lid0: wake_prep enabled for \134_SB_.LID_ (S3) [] acpi_button0: wake_prep enabled for \134_SB_.SLPB (S3) -[] uhub0: at usbus0, port 1, addr 1 (disconnected) -[] uhub1: at usbus1, port 1, addr 1 (disconnected) +[] uhub2: at usbus0, port 1, addr 1 (disconnected) +[] uhub0: at usbus1, port 1, addr 1 (disconnected) ugen1.2: at usbus1 (disconnected) ugen1.3: at usbus1 (disconnected) -[] ubt0: at uhub1, port 2, addr 3 (disconnected) -[] uhub2: at usbus2, port 1, addr 1 (disconnected) +[] ubt0: at uhub0, port 2, addr 3 (disconnected) +[] uhub1: at usbus2, port 1, addr 1 (disconnected) ugen2.2: at usbus2 (disconnected) pci0:0:28:0: Transition from D0 to D3 pci0:0:28:1: Transition from D0 to D3 pci0:0:28:3: Transition from D0 to D3 pci0:0:28:4: Transition from D0 to D3 -[] uhub3: at usbus3, port 1, addr 1 (disconnected) -ugen3.2: at usbus3 (disconnected) -[] uftdi0: at uhub3, port 2, addr 2 (disconnected) -[] uhub4: at usbus4, port 1, addr 1 (disconnected) +[] uhub4: at usbus3, port 1, addr 1 (disconnected) +[] uhub3: at usbus4, port 1, addr 1 (disconnected) [] uhub5: at usbus5, port 1, addr 1 (disconnected) pci0:21:0:0: Transition from D0 to D2 [] pci21: failed to set ACPI power state D2 on \134_SB_.PCI0.PCI1.CDBS: AE_BAD_PARAMETER @@ -73,12 +71,12 @@ kbdc: RESET_AUX ID:0000 [] battery0: battery initialization start [] ahcich0: AHCI reset: device ready after 100ms -[] uhub0: on usbus1 -[] uhub1: on usbus2 -[] uhub2: on usbus0 -[] uhub3: on usbus4 -[] uhub4: on usbus3 -[] uhub5: on usbus5 +[] uhub0: on usbus0 +[] uhub1: on usbus1 +[] uhub2: on usbus3 +[] uhub3: on usbus2 +[] uhub4: on usbus5 +[] uhub5: on usbus4 CPU0: local APIC error 0x40 [] battery0: battery initialization done, tried 1 times (ada0:ahcich0:0:0:0): resume @@ -92,15 +90,13 @@ intpin=a, irq=16 powerspec 2 supports D0 D3 current D0 [] cardbus0: at device 0.0 (no driver attached) -[] uhub0: 2 ports with 2 removable, self powered [] uhub1: 2 ports with 2 removable, self powered [] uhub2: 2 ports with 2 removable, self powered +[] uhub0: 2 ports with 2 removable, self powered [] uhub3: 2 ports with 2 removable, self powered -[] uhub5: 2 ports with 2 removable, self powered [] uhub4: 2 ports with 2 removable, self powered +[] uhub5: 2 ports with 2 removable, self powered ugen1.2: at usbus1 -ugen3.2: at usbus3 -[] uftdi0: on usbus3 ugen2.2: at usbus2 ugen1.3: at usbus1 [] ubt0: on usbus1 ======= From owner-freebsd-stable@FreeBSD.ORG Sun Jun 30 18:20:27 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id DB41FC19 for ; Sun, 30 Jun 2013 18:20:27 +0000 (UTC) (envelope-from jhellenthal@dataix.net) Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::231]) by mx1.freebsd.org (Postfix) with ESMTP id A61781785 for ; Sun, 30 Jun 2013 18:20:27 +0000 (UTC) Received: by mail-ie0-f177.google.com with SMTP id aq17so7564702iec.22 for ; Sun, 30 Jun 2013 11:20:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dataix.net; s=rsa; h=subject:mime-version:from:content-type:x-mailer:message-id:date:cc :content-transfer-encoding:to; bh=eXhPx/Wv2wh63XkjrFmfxRQP31BkLBDNS4/5gnwkmck=; b=LHWHOGqsra3rg9/8MFAcLAffk6LFpls5uchOY+Ee9Fh5QDqguVoOpma45KmBX02Qlk qE0zr3E3IkcWc2iy2IBo3FIOAUzYHXGPUobzDU+e40D1fkySBMNFJfTqwbWhSPHqNxSr uCN+zUIfJVVs2Hka3DSKaOuRN2MkBhfZJ+2Q0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:from:content-type:x-mailer:message-id:date:cc :content-transfer-encoding:to:x-gm-message-state; bh=eXhPx/Wv2wh63XkjrFmfxRQP31BkLBDNS4/5gnwkmck=; b=dIgYxOib+NF5RolMkBCoj6g6UYd2zmgTI7wiOz9CSqeR+zzVKKDt91jmmi3UFBk01U lSasAtLuPgzzffAX4gj7oBgPolwWB5L/1GiGoG9tiniPQDf2sQ8/vErOMrX8U4bhoJXL e/nU/xhf2AZgcZsbaSR31s99LG1IuH5IzIO0koeugEOmrbeCPrWPyANgIr6dLsTiIYj0 3sMD2DXR+hSsyXi2m0tNUByWmNMb49dD/e4yCNEFYJPYA5zLjnhFRrMkFtkKFt7KLpxK 11jpbpQ9i5Ff7I85Up62i1lzXy3/G5u3ZkcnQ2a3Hzc22TO5u5nH36Ol7p0gw2qyXign iL1Q== X-Received: by 10.50.82.104 with SMTP id h8mr12399138igy.17.1372616427343; Sun, 30 Jun 2013 11:20:27 -0700 (PDT) Received: from [192.168.31.77] (24-236-152-143.dhcp.aldl.mi.charter.com. [24.236.152.143]) by mx.google.com with ESMTPSA id ff19sm9433007igb.0.2013.06.30.11.20.24 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 30 Jun 2013 11:20:25 -0700 (PDT) Subject: Subversion 1.8 / FreeBSD 8 x86 STABLE Symlinks Mime-Version: 1.0 (1.0) From: Jason Hellenthal Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-9321D415-851B-46AD-A3D7-DAD1651CC4B1; protocol="application/pkcs7-signature" X-Mailer: iPhone Mail (10B329) Message-Id: <0641AF26-52A1-4D2D-9956-A3439D53CA42@dataix.net> Date: Sun, 30 Jun 2013 14:20:21 -0400 Content-Transfer-Encoding: 7bit To: "[FreeBSD Stable]" X-Gm-Message-State: ALoCoQkTK4z4P3O6fJ8nB58oXZaTfhAWU65fwHeJ6rosL+i+ebYJzZwlm5ke8pLDeHqCrL7En1Ah X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "\[FreeBSD Ports\]" 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, 30 Jun 2013 18:20:27 -0000 --Apple-Mail-9321D415-851B-46AD-A3D7-DAD1651CC4B1 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable When using svn 1.8 I have come across a situation where when it is used poin= ting to a symlink that refers to a working directory that a update will eith= er segfault or exit prematurely and leave a lock held on the working directo= ry that the symlink points to. This leaves you with one choice but to run cleanup on the referenced actual w= orking directory which was AFAIK never the case for any version below 1.8. Not sure if this is a problem with svn or FreeBSD itself but thought I would= report the characteristics in case it's noticed elsewhere. Details: Using UFS FreeBSD 8-STABLE i386 as of this date. In the directory... cd /exports/usr ln -s src8 src svn up /exports/usr/src --=20 Jason Hellenthal Inbox: jhellenthal@DataIX.net Voice: +1 (616) 953-0176 JJH48-ARIN --Apple-Mail-9321D415-851B-46AD-A3D7-DAD1651CC4B1 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGNDCCBjAw ggUYoAMCAQICAwaijjANBgkqhkiG9w0BAQsFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0 YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENB MB4XDTEzMDUxODA4NTA0OFoXDTE0MDUxOTIyMDk0N1owSDEfMB0GA1UEAwwWamhlbGxlbnRoYWxA ZGF0YWl4Lm5ldDElMCMGCSqGSIb3DQEJARYWamhlbGxlbnRoYWxAZGF0YWl4Lm5ldDCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBALgnYFS1bWZr3KhKBzWAdRwrY+En+RRV8nCaYubqrMG+ YJbuenaIKSbIuFiDWipW4RHYTpE28pKaSnaVTG9WtAZvsWj0gYN9g2fYCnCOUceES2Yvi3RavxpB hsuzKIfsHb8iNNSEuczLu6gn4mQyaHwE4x6xSUKmbK8njR+YoF522F60wjsnq5dlOJdTrhDfObE5 5P23279WbRp8azgZX1VRB66wdKRDuSI1vBts4Nsha2paXd6HUUduHrPACBQREJTGXN8XtEKVwo63 aKUhRgtUwHNEuSWck/xwVl7PBUWH2dORAWTCqHjNuCKNOQ1/0LMiyMj7FdsBjN4dgL4YZpsCAwEA AaOCAtwwggLYMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDAdBgNVHQ4EFgQU29qUrmZtgQ7ZVoDKogfpJOSfk+YwHwYDVR0jBBgwFoAUU3Ltkpzg 2ssBXHx+ljVO8tS4UYIwIQYDVR0RBBowGIEWamhlbGxlbnRoYWxAZGF0YWl4Lm5ldDCCAUwGA1Ud IASCAUMwggE/MIIBOwYLKwYBBAGBtTcBAgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0 YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eTADAgEBGoG+VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29y ZGluZyB0byB0aGUgQ2xhc3MgMSBWYWxpZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRD b20gQ0EgcG9saWN5LCByZWxpYW5jZSBvbmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBj b21wbGlhbmNlIG9mIHRoZSByZWx5aW5nIHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCug KaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3JsMIGOBggrBgEFBQcBAQSB gTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMS9jbGll bnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFz czEuY2xpZW50LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJ KoZIhvcNAQELBQADggEBAHsw8/Hw07gsNTKYnld74NBFtHnQOPkXYuccWx3j0PGQe9nqNxeingBf 2yvx+xBQzBoi4J1u84Jbrbe8Ii3+LLD/QMW9cN0SBIgRStPQLVee4STdjeabGmpXQa7omC02wYYO 83qh6CgJEIbmrsBSZH8ZSVrjkC4UmZS8wAQMS3qTWAPF0ZQGWx2+Gks2fXuacyt2LpNR+p9ogjAZ 1/rmUKjNhQZLswytaLRUdwAwSfQ3+TNs68h6Kv1LC3bNGBT3NEtr2q/nzzb5MzuFcDE6f9exroAC 4BHmokAprhna/vZdb6BrPjpXgRAlWAh3wEMxw75M9S/Nbzj/jNp+I+lvUJYxggNvMIIDawIBATCB lDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3Vy ZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEg UHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMGoo4wCQYFKw4DAhoFAKCCAa8wGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwNjMwMTgyMDI0WjAjBgkqhkiG 9w0BCQQxFgQUu96NCGhJJfYoPSqqK7ltqWU63u4wgaUGCSsGAQQBgjcQBDGBlzCBlDCBjDELMAkG A1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJ bnRlcm1lZGlhdGUgQ2xpZW50IENBAgMGoo4wgacGCyqGSIb3DQEJEAILMYGXoIGUMIGMMQswCQYD VQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwg Q2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IElu dGVybWVkaWF0ZSBDbGllbnQgQ0ECAwaijjANBgkqhkiG9w0BAQEFAASCAQBx4u8+ZP87QBSIEkdw 3ERYfuWCMR0j6SUbOuwte3km/HreJ6Gh1RnVYA3GINxioXFj4i92gU921qNOp9PEYvpqjclYCqcZ ehmkqxU43kGJdBBBlYdmsdsJBERfbjW4E1VkugAxngrrESRXAwYDsUvvLgziN1+IFWkDCB0tJ4U0 CGV+K6WYf2qaZHBU3brSQfij4uE8HdmZk5coVElhV3UDXeNy9XiGeBajAa8OCXe8wwQmkm9z2D5P iKqfMVFtlaKGJpQkAPcxNAui+N2Xazc8hccVWuD5+a7ETwz2VqJutY5znr2jq75MQ5zwjXnBe2Pr qPYNqhPEBnmpC66tLcoGAAAAAAAA --Apple-Mail-9321D415-851B-46AD-A3D7-DAD1651CC4B1-- From owner-freebsd-stable@FreeBSD.ORG Sun Jun 30 18:29:44 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 99600F5A; Sun, 30 Jun 2013 18:29:44 +0000 (UTC) (envelope-from jdc@koitsu.org) Received: from relay5-d.mail.gandi.net (relay5-d.mail.gandi.net [217.70.183.197]) by mx1.freebsd.org (Postfix) with ESMTP id 5848217DF; Sun, 30 Jun 2013 18:29:44 +0000 (UTC) Received: from mfilter22-d.gandi.net (mfilter22-d.gandi.net [217.70.178.150]) by relay5-d.mail.gandi.net (Postfix) with ESMTP id 636B241C05A; Sun, 30 Jun 2013 20:29:33 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter22-d.gandi.net Received: from relay5-d.mail.gandi.net ([217.70.183.197]) by mfilter22-d.gandi.net (mfilter22-d.gandi.net [10.0.15.180]) (amavisd-new, port 10024) with ESMTP id iSY9brdsXTlX; Sun, 30 Jun 2013 20:29:31 +0200 (CEST) X-Originating-IP: 76.102.14.35 Received: from jdc.koitsu.org (c-76-102-14-35.hsd1.ca.comcast.net [76.102.14.35]) (Authenticated sender: jdc@koitsu.org) by relay5-d.mail.gandi.net (Postfix) with ESMTPSA id 74DBD41C064; Sun, 30 Jun 2013 20:29:29 +0200 (CEST) Received: by icarus.home.lan (Postfix, from userid 1000) id A8CD473A1C; Sun, 30 Jun 2013 11:29:27 -0700 (PDT) Date: Sun, 30 Jun 2013 11:29:27 -0700 From: Jeremy Chadwick To: Jason Hellenthal Subject: Re: Subversion 1.8 / FreeBSD 8 x86 STABLE Symlinks Message-ID: <20130630182927.GA43312@icarus.home.lan> References: <0641AF26-52A1-4D2D-9956-A3439D53CA42@dataix.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0641AF26-52A1-4D2D-9956-A3439D53CA42@dataix.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "\[FreeBSD Stable\]" , "\[FreeBSD Ports\]" 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, 30 Jun 2013 18:29:44 -0000 On Sun, Jun 30, 2013 at 02:20:21PM -0400, Jason Hellenthal wrote: > When using svn 1.8 I have come across a situation where when it is used pointing to a symlink that refers to a working directory that a update will either segfault or exit prematurely and leave a lock held on the working directory that the symlink points to. > > This leaves you with one choice but to run cleanup on the referenced actual working directory which was AFAIK never the case for any version below 1.8. > > Not sure if this is a problem with svn or FreeBSD itself but thought I would report the characteristics in case it's noticed elsewhere. > > Details: > Using UFS > FreeBSD 8-STABLE i386 as of this date. > > In the directory... > cd /exports/usr > ln -s src8 src > svn up /exports/usr/src Known bug/problem in Subversion, not FreeBSD: http://svn.apache.org/viewvc?view=revision&revision=r1496007 Previous discussion: http://lists.freebsd.org/pipermail/freebsd-questions/2013-June/251842.html -- | Jeremy Chadwick jdc@koitsu.org | | UNIX Systems Administrator http://jdc.koitsu.org/ | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Sun Jun 30 22:02:58 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id CA9D865A; Sun, 30 Jun 2013 22:02:58 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-qa0-x230.google.com (mail-qa0-x230.google.com [IPv6:2607:f8b0:400d:c00::230]) by mx1.freebsd.org (Postfix) with ESMTP id 69A6E1D8F; Sun, 30 Jun 2013 22:02:58 +0000 (UTC) Received: by mail-qa0-f48.google.com with SMTP id cm16so1683943qab.14 for ; Sun, 30 Jun 2013 15:02:57 -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=RJdUV8rwkvE5t6AFUwjOG0lq8zpFGTnw8dKR53O6p6A=; b=fzSP5YaXZUPV4pkQM39gVBRdZfcyYrHZKDbStsrDO69o/EFb3P1QFpqwgRiZO2Zp1T +oH4J52Go+Y/Pij6qoa0xujhBcVFlAiTMEzI+lKEeXbEjrqqd+ErxYK5DzTxhOesW2x4 3H1UTH0Xeofxtqpj8XRy6t3abM5mHFcx1EOpsAqeOvWPCCJ/8cX6yfAdY/UXSJDW6jvn vM/XdJMw8OFQMXC5a988aFzYT5xzMRVBvaA/8AvYgx5RkM5kNsNrcJ2EKaMNQsJVavPg rW6lrr6XsElMPnW7Kos5ItM1M5JZMO6AErCaPSpfcjE+TrV/7bugoQBmjwFC5xtY+sUS 7gzQ== MIME-Version: 1.0 X-Received: by 10.229.160.9 with SMTP id l9mr6721504qcx.100.1372629777640; Sun, 30 Jun 2013 15:02:57 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.101.134 with HTTP; Sun, 30 Jun 2013 15:02:57 -0700 (PDT) In-Reply-To: <20130630233640.Y23789@sola.nimnet.asn.au> References: <20130621220013.X55167@sola.nimnet.asn.au> <20130626152833.M78748@sola.nimnet.asn.au> <20130626195154.GK88288@e-new.0x20.net> <20130627213331.W26984@sola.nimnet.asn.au> <20130630233640.Y23789@sola.nimnet.asn.au> Date: Sun, 30 Jun 2013 15:02:57 -0700 X-Google-Sender-Auth: zN3vNri3nT8fGv7WysGP1kwtPDQ Message-ID: Subject: Re: USB ports on Lenovo T400 do not work after a suspend/resume From: Adrian Chadd To: Ian Smith Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-acpi@freebsd.org, freebsd-stable@freebsd.org, Lars Engels , freebsd-usb@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, 30 Jun 2013 22:02:58 -0000 On 30 June 2013 07:22, Ian Smith wrote: > After removing [numbers] (for WITNESS?), diff started making sense. > The below is between the first and second suspend/resume cycles in > dmesg-3.txt, encompassing the others. Cool! > Nothing of note that I can see, if that usb hub-to-bus remapping is > normal. As you said, 'CPU0: local APIC error 0x40' looks maybe sus. > Maybe someone who knows might comment on that? > > Just checking: you've tried other USB devices apart from uftdi0? Yup, there's no 5v on the port. -adrian From owner-freebsd-stable@FreeBSD.ORG Mon Jul 1 11:06:55 2013 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 1D58065E for ; Mon, 1 Jul 2013 11:06:55 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id CD84310EC for ; Mon, 1 Jul 2013 11:06:54 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r61B6sGh085929 for ; Mon, 1 Jul 2013 11:06:54 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r61B6sVg085927 for freebsd-stable@FreeBSD.org; Mon, 1 Jul 2013 11:06:54 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 1 Jul 2013 11:06:54 GMT Message-Id: <201307011106.r61B6sVg085927@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-stable@FreeBSD.org Subject: Current problem reports assigned to 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, 01 Jul 2013 11:06:55 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o i386/179112 stable 9.1 installer panics with a kmem_malloc() failure on i 1 problem total. From owner-freebsd-stable@FreeBSD.ORG Mon Jul 1 12:59:57 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id A7D5E1F8 for ; Mon, 1 Jul 2013 12:59:57 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) by mx1.freebsd.org (Postfix) with ESMTP id 01AD91A3D for ; Mon, 1 Jul 2013 12:59:56 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id r61Cxlwx077143; Mon, 1 Jul 2013 22:59:48 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Mon, 1 Jul 2013 22:59:47 +1000 (EST) From: Ian Smith To: Jeremy Chadwick Subject: Re: FREEBSD_INSTALL failed with error 19 during booting installer In-Reply-To: <20130629215652.GA86720@icarus.home.lan> Message-ID: <20130701005056.T23789@sola.nimnet.asn.au> References: <51CDD465.90706@wp.pl> <20130628182615.GA52467@icarus.home.lan> <20130630020255.J81017@sola.nimnet.asn.au> <20130629215652.GA86720@icarus.home.lan> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Marek Salwerowicz , "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, 01 Jul 2013 12:59:57 -0000 On Sat, 29 Jun 2013 14:56:52 -0700, Jeremy Chadwick wrote: > On Sun, Jun 30, 2013 at 02:09:36AM +1000, Ian Smith wrote: > > On Fri, 28 Jun 2013 11:26:15 -0700, Jeremy Chadwick wrote: > > > On Fri, Jun 28, 2013 at 08:22:29PM +0200, Marek Salwerowicz wrote: > > > > Hi list, > > > > > > > > I am trying to install FreeBSD 9.1-Release amd64 on a Supermicro server: > > > > > > > > SuperStorage Server 6027R-E1R12N > > > > > > > > with Intel Xeon E5-2640 CPU and 32 GB (4 x 8 ) KVR16R11D4/8HC installed > > > > > > > > Currently I have only 2 SSD Kingston drives (working in mirror) > > > > installed on that server. > > > > > > > > during booting installer from the ISO CD (amd64), the boot process > > > > fails with message: > > > > > > > > Mounting from cd9660:/dev/iso9660/FREEBSD_INSTALL failed with error 19. > > > > > > > > As I found here: http://forums.freebsd.org/showthread.php?t=36579 , > > > > probably this could be issue with ACPI, but setting option in > > > > loader: > > > > > > > > # set debug.acpi.disabled ="hostres" > > > > # boot > > > > > > > > made nothing for me. > > > > > > > > > > > > > > > > Any ideas? > > > > > > Try using a USB flash drive + memstick image instead of CD-based media. > > > > Last time I tried - 9.1-release i386 - the memstick boot gave no option > > to drop to loader; I had to burn a disc1 CD so I could drop to loader to > > turn cam.ctl off to succeed installing in 128MB. Did I miss something? > > I've used memstick images exclusively for years and have never seen > this. Quite right Jeremy, thanks for that and sorry for the noise. I'd misremembered the problem with the memstick install in 128MB, which was that even with kern.cam.ctl.disable=1 (saving ~35MB), there wasn't enough memory to complete installation successfully. The CD install (also with kern.cam.ctl.disable=1) works fine, apparently because after booting, selecting 'Live CD' rather than 'Install' shows 58MB free in top, rather than 44MB with the memstick; it's that close a thing, as verified by a series of test installs this afternoon. No idea why booting from memstick rather than CD would cost ~14MB, but I'm sure most people wouldn't much care .. cheers, Ian From owner-freebsd-stable@FreeBSD.ORG Mon Jul 1 15:25:12 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 3009F97 for ; Mon, 1 Jul 2013 15:25:12 +0000 (UTC) (envelope-from cscotts@gmail.com) Received: from mail-la0-x236.google.com (mail-la0-x236.google.com [IPv6:2a00:1450:4010:c03::236]) by mx1.freebsd.org (Postfix) with ESMTP id B0DD4109F for ; Mon, 1 Jul 2013 15:25:11 +0000 (UTC) Received: by mail-la0-f54.google.com with SMTP id ec20so4533360lab.13 for ; Mon, 01 Jul 2013 08:25:10 -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=pJH3BR5dfFgnPulf2nnOsdlsjA31NIaGKqabSQXj35s=; b=Mu9tq8+I4JNA+GhHGuo5rD49+7qa+fR1cZcDA3Q4ptVBaGZ1FzNdRxuDlawbebiWA5 XnxVf9IlJN/PABpmFzJIqb2JlaEI7R9wt5i2x1mUZkhkyaUbVjZBa4WPG+w1lbCNLjyp BQGzAeAhwD7Ei1kJESGRgqOj0Yh1eWV9C169PiFpYjAF23teUFZJrDVa5OjhGeUHZFQt /QHGLw6w/HjzzOwmW8j+fVdGJTulJpPYFW/JcNx7n/OTqY+A10UmJUwAv5sL1HMk4vpX wpSPmmN/a8my0iDdvrkT5grPiLqzXAGsKz7LfjfTNjx6KlvB+y12yE0KdJLiYQFuVh8M t7OQ== MIME-Version: 1.0 X-Received: by 10.112.198.164 with SMTP id jd4mr12112617lbc.74.1372692310462; Mon, 01 Jul 2013 08:25:10 -0700 (PDT) Received: by 10.152.112.195 with HTTP; Mon, 1 Jul 2013 08:25:10 -0700 (PDT) Date: Mon, 1 Jul 2013 11:25:10 -0400 Message-ID: Subject: ZFS Panic after freebsd-update From: Scott Sipe To: freebsd-stable List Content-Type: text/plain; charset=ISO-8859-1 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: Mon, 01 Jul 2013 15:25:12 -0000 Hello, I have not had much time to research this problem yet, so please let me know what further information I might be able to provide. This weekend I attempted to upgrade a computer from 8.2-RELEASE-p3 to 8.4 using freebsd-update. After I rebooted to test the new kernel, I got a panic. I had to take a picture of the screen. Here's a condensed version: panic: page fault cpuid = 1 KDB: stack backtrace: #0 #1 #2 #3 #4 #5 #6 #6 #6 #6 #6 #6 FreeBSD xeon.cap-press.com 8.2-RELEASE-p3 FreeBSD 8.2-RELEASE-p3 #0: Tue Sep 27 18:45:57 UTC 2011 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 From owner-freebsd-stable@FreeBSD.ORG Mon Jul 1 15:35:32 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 4586728C for ; Mon, 1 Jul 2013 15:35:32 +0000 (UTC) (envelope-from cscotts@gmail.com) Received: from mail-la0-x229.google.com (mail-la0-x229.google.com [IPv6:2a00:1450:4010:c03::229]) by mx1.freebsd.org (Postfix) with ESMTP id A78031105 for ; Mon, 1 Jul 2013 15:35:31 +0000 (UTC) Received: by mail-la0-f41.google.com with SMTP id fn20so4565620lab.0 for ; Mon, 01 Jul 2013 08:35:30 -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=SxiwjjpM7JqtSlJDGJcz90W1uPa1y1BJUCzy1tve/qY=; b=UK/IR4Kewt9tR30lti52UgVqp7rirVSFcAvDMa6Pf8m7DGHGRbGXqcEVYTNT7L+I/v g0t1lYD1FHOnwMr7UT3KjJO+796fRZZ0Zq5Zu10Nfrvp311x9vrJu/+/UCixbkbnTpGz 7cchtsCfzOO4fI1UXkgzonUMxfp6wvCCi0gz+2hOBj7T80jEC6sHGvW/JSHW+fGCvhii nGvMoQ1564fvLuDJ7+rxVVgsKxd7679GyzOe2v3MX34qblRoq/t8gI0LMy1sRX+zN4t1 ZSo/lXbp0xG3lT25+6dwVFIy805e86noOeednACaLLMSqq1DGvO3ZEH6yg5KCPyP8suZ WB/Q== MIME-Version: 1.0 X-Received: by 10.112.218.68 with SMTP id pe4mr11811864lbc.40.1372692930393; Mon, 01 Jul 2013 08:35:30 -0700 (PDT) Received: by 10.152.112.195 with HTTP; Mon, 1 Jul 2013 08:35:30 -0700 (PDT) Date: Mon, 1 Jul 2013 11:35:30 -0400 Message-ID: Subject: ZFS Panic after freebsd-update From: Scott Sipe To: freebsd-stable List Content-Type: multipart/mixed; boundary=001a11c3d14a807a9c04e074fa2f 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: Mon, 01 Jul 2013 15:35:32 -0000 --001a11c3d14a807a9c04e074fa2f Content-Type: text/plain; charset=ISO-8859-1 *** Sorry for partial first message! (gmail sent after multiple returns apparently?) *** Hello, I have not had much time to research this problem yet, so please let me know what further information I might be able to provide. This weekend I attempted to upgrade a computer from 8.2-RELEASE-p3 to 8.4 using freebsd-update. After I rebooted to test the new kernel, I got a panic. I had to take a picture of the screen. Here's a condensed version: panic: page fault cpuid = 1 KDB: stack backtrace: #0 kdb_backtrace #1 panic #2 trap_fatal #3 trap_pfault #4 trap #5 calltrap #6 vdev_mirror_child_select #7 ved_mirror_io_start #8 zio_vdev_io_start #9 zio_execute #10 arc_read #11 dbuf_read #12 dbuf_findbp #13 dbuf_hold_impl #14 dbuf_hold #15 dnode_hold_impl #16 dnu_buf_hold #17 zap_lockdir Uptime: 5s Cannot dump. Device not defined or unavailable. Automatic reboot in 15 seconds - press a key on the console to abort uname -a from before (and after) the reboot: FreeBSD xeon 8.2-RELEASE-p3 FreeBSD 8.2-RELEASE-p3 #0: Tue Sep 27 18:45:57 UTC 2011 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 dmesg is attached. I was able to reboot to the old kernel and am up and running back on 8.2 right now. Any thoughts? Thanks, Scott --001a11c3d14a807a9c04e074fa2f Content-Type: text/plain; charset=US-ASCII; name="dmesg.2013.txt" Content-Disposition: attachment; filename="dmesg.2013.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_hiltw88o0 Q29weXJpZ2h0IChjKSAxOTkyLTIwMTEgVGhlIEZyZWVCU0QgUHJvamVjdC4KQ29weXJpZ2h0IChj KSAxOTc5LCAxOTgwLCAxOTgzLCAxOTg2LCAxOTg4LCAxOTg5LCAxOTkxLCAxOTkyLCAxOTkzLCAx OTk0CglUaGUgUmVnZW50cyBvZiB0aGUgVW5pdmVyc2l0eSBvZiBDYWxpZm9ybmlhLiBBbGwgcmln aHRzIHJlc2VydmVkLgpGcmVlQlNEIGlzIGEgcmVnaXN0ZXJlZCB0cmFkZW1hcmsgb2YgVGhlIEZy ZWVCU0QgRm91bmRhdGlvbi4KRnJlZUJTRCA4LjItUkVMRUFTRS1wMyAjMDogVHVlIFNlcCAyNyAx ODo0NTo1NyBVVEMgMjAxMQogICAgcm9vdEBhbWQ2NC1idWlsZGVyLmRhZW1vbm9sb2d5Lm5ldDov dXNyL29iai91c3Ivc3JjL3N5cy9HRU5FUklDIGFtZDY0ClRpbWVjb3VudGVyICJpODI1NCIgZnJl cXVlbmN5IDExOTMxODIgSHogcXVhbGl0eSAwCkNQVTogSW50ZWwoUikgWGVvbihSKSBDUFUgICAg ICAgICAgIEU1NTIwICBAIDIuMjdHSHogKDIyNjYuNzYtTUh6IEs4LWNsYXNzIENQVSkKICBPcmln aW4gPSAiR2VudWluZUludGVsIiAgSWQgPSAweDEwNmE1ICBGYW1pbHkgPSA2ICBNb2RlbCA9IDFh ICBTdGVwcGluZyA9IDUKICBGZWF0dXJlcz0weGJmZWJmYmZmPEZQVSxWTUUsREUsUFNFLFRTQyxN U1IsUEFFLE1DRSxDWDgsQVBJQyxTRVAsTVRSUixQR0UsTUNBLENNT1YsUEFULFBTRTM2LENMRkxV U0gsRFRTLEFDUEksTU1YLEZYU1IsU1NFLFNTRTIsU1MsSFRULFRNLFBCRT4KICBGZWF0dXJlczI9 MHg5Y2UzYmQ8U1NFMyxEVEVTNjQsTU9OLERTX0NQTCxWTVgsRVNULFRNMixTU1NFMyxDWDE2LHhU UFIsUERDTSxEQ0EsU1NFNC4xLFNTRTQuMixQT1BDTlQ+CiAgQU1EIEZlYXR1cmVzPTB4MjgxMDA4 MDA8U1lTQ0FMTCxOWCxSRFRTQ1AsTE0+CiAgQU1EIEZlYXR1cmVzMj0weDE8TEFIRj4KICBUU0M6 IFAtc3RhdGUgaW52YXJpYW50CnJlYWwgbWVtb3J5ICA9IDE4MjUzNjExMDA4ICgxNzQwOCBNQikK YXZhaWwgbWVtb3J5ID0gMTY1MTMzNDc1ODQgKDE1NzQ4IE1CKQpBQ1BJIEFQSUMgVGFibGU6IDww MzE3MTAgQVBJQzE2MTc+CkZyZWVCU0QvU01QOiBNdWx0aXByb2Nlc3NvciBTeXN0ZW0gRGV0ZWN0 ZWQ6IDE2IENQVXMKRnJlZUJTRC9TTVA6IDIgcGFja2FnZShzKSB4IDQgY29yZShzKSB4IDIgU01U IHRocmVhZHMKIGNwdTAgKEJTUCk6IEFQSUMgSUQ6ICAwCiBjcHUxIChBUCk6IEFQSUMgSUQ6ICAx CiBjcHUyIChBUCk6IEFQSUMgSUQ6ICAyCiBjcHUzIChBUCk6IEFQSUMgSUQ6ICAzCiBjcHU0IChB UCk6IEFQSUMgSUQ6ICA0CiBjcHU1IChBUCk6IEFQSUMgSUQ6ICA1CiBjcHU2IChBUCk6IEFQSUMg SUQ6ICA2CiBjcHU3IChBUCk6IEFQSUMgSUQ6ICA3CiBjcHU4IChBUCk6IEFQSUMgSUQ6IDE2CiBj cHU5IChBUCk6IEFQSUMgSUQ6IDE3CiBjcHUxMCAoQVApOiBBUElDIElEOiAxOAogY3B1MTEgKEFQ KTogQVBJQyBJRDogMTkKIGNwdTEyIChBUCk6IEFQSUMgSUQ6IDIwCiBjcHUxMyAoQVApOiBBUElD IElEOiAyMQogY3B1MTQgKEFQKTogQVBJQyBJRDogMjIKIGNwdTE1IChBUCk6IEFQSUMgSUQ6IDIz CmlvYXBpYzAgPFZlcnNpb24gMi4wPiBpcnFzIDAtMjMgb24gbW90aGVyYm9hcmQKaW9hcGljMSA8 VmVyc2lvbiAyLjA+IGlycXMgMjQtNDcgb24gbW90aGVyYm9hcmQKa2JkMSBhdCBrYmRtdXgwCmFj cGkwOiA8MDMxNzEwIFhTRFQxNjE3PiBvbiBtb3RoZXJib2FyZAphY3BpMDogW0lUSFJFQURdCmFj cGkwOiBQb3dlciBCdXR0b24gKGZpeGVkKQphY3BpMDogcmVzZXJ2YXRpb24gb2YgMCwgYTAwMDAg KDMpIGZhaWxlZAphY3BpMDogcmVzZXJ2YXRpb24gb2YgMTAwMDAwLCBiZmYwMDAwMCAoMykgZmFp bGVkClRpbWVjb3VudGVyICJBQ1BJLWZhc3QiIGZyZXF1ZW5jeSAzNTc5NTQ1IEh6IHF1YWxpdHkg MTAwMAphY3BpX3RpbWVyMDogPDI0LWJpdCB0aW1lciBhdCAzLjU3OTU0NU1Iej4gcG9ydCAweDgw OC0weDgwYiBvbiBhY3BpMApjcHUwOiA8QUNQSSBDUFU+IG9uIGFjcGkwCkFDUEkgV2FybmluZzog SW5jb3JyZWN0IGNoZWNrc3VtIGluIHRhYmxlIFtPRU1CXSAtIDB4QUQsIHNob3VsZCBiZSAweEFB ICgyMDEwMTAxMy90YnV0aWxzLTM1NCkKY3B1MTogPEFDUEkgQ1BVPiBvbiBhY3BpMApjcHUyOiA8 QUNQSSBDUFU+IG9uIGFjcGkwCmNwdTM6IDxBQ1BJIENQVT4gb24gYWNwaTAKY3B1NDogPEFDUEkg Q1BVPiBvbiBhY3BpMApjcHU1OiA8QUNQSSBDUFU+IG9uIGFjcGkwCmNwdTY6IDxBQ1BJIENQVT4g b24gYWNwaTAKY3B1NzogPEFDUEkgQ1BVPiBvbiBhY3BpMApjcHU4OiA8QUNQSSBDUFU+IG9uIGFj cGkwCmNwdTk6IDxBQ1BJIENQVT4gb24gYWNwaTAKY3B1MTA6IDxBQ1BJIENQVT4gb24gYWNwaTAK Y3B1MTE6IDxBQ1BJIENQVT4gb24gYWNwaTAKY3B1MTI6IDxBQ1BJIENQVT4gb24gYWNwaTAKY3B1 MTM6IDxBQ1BJIENQVT4gb24gYWNwaTAKY3B1MTQ6IDxBQ1BJIENQVT4gb24gYWNwaTAKY3B1MTU6 IDxBQ1BJIENQVT4gb24gYWNwaTAKcGNpYjA6IDxBQ1BJIEhvc3QtUENJIGJyaWRnZT4gcG9ydCAw eGNmOC0weGNmZiBvbiBhY3BpMApwY2kwOiA8QUNQSSBQQ0kgYnVzPiBvbiBwY2liMApwY2liMTog PEFDUEkgUENJLVBDSSBicmlkZ2U+IGF0IGRldmljZSAxLjAgb24gcGNpMApwY2kxMDogPEFDUEkg UENJIGJ1cz4gb24gcGNpYjEKcGNpYjI6IDxBQ1BJIFBDSS1QQ0kgYnJpZGdlPiBhdCBkZXZpY2Ug My4wIG9uIHBjaTAKcGNpOTogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjIKcGNpYjM6IDxBQ1BJIFBD SS1QQ0kgYnJpZGdlPiBhdCBkZXZpY2UgNy4wIG9uIHBjaTAKcGNpODogPEFDUEkgUENJIGJ1cz4g b24gcGNpYjMKcGNpYjQ6IDxQQ0ktUENJIGJyaWRnZT4gYXQgZGV2aWNlIDguMCBvbiBwY2kwCnBj aTc6IDxQQ0kgYnVzPiBvbiBwY2liNApwY2liNTogPFBDSS1QQ0kgYnJpZGdlPiBhdCBkZXZpY2Ug OS4wIG9uIHBjaTAKcGNpNjogPFBDSSBidXM+IG9uIHBjaWI1CnBjaWI2OiA8UENJLVBDSSBicmlk Z2U+IGF0IGRldmljZSAxMC4wIG9uIHBjaTAKcGNpNTogPFBDSSBidXM+IG9uIHBjaWI2CnBjaTA6 IDxiYXNlIHBlcmlwaGVyYWwsIGludGVycnVwdCBjb250cm9sbGVyPiBhdCBkZXZpY2UgMjAuMCAo bm8gZHJpdmVyIGF0dGFjaGVkKQpwY2kwOiA8YmFzZSBwZXJpcGhlcmFsLCBpbnRlcnJ1cHQgY29u dHJvbGxlcj4gYXQgZGV2aWNlIDIwLjEgKG5vIGRyaXZlciBhdHRhY2hlZCkKcGNpMDogPGJhc2Ug cGVyaXBoZXJhbCwgaW50ZXJydXB0IGNvbnRyb2xsZXI+IGF0IGRldmljZSAyMC4yIChubyBkcml2 ZXIgYXR0YWNoZWQpCnBjaTA6IDxiYXNlIHBlcmlwaGVyYWwsIGludGVycnVwdCBjb250cm9sbGVy PiBhdCBkZXZpY2UgMjAuMyAobm8gZHJpdmVyIGF0dGFjaGVkKQpwY2kwOiA8YmFzZSBwZXJpcGhl cmFsPiBhdCBkZXZpY2UgMjIuMCAobm8gZHJpdmVyIGF0dGFjaGVkKQpwY2kwOiA8YmFzZSBwZXJp cGhlcmFsPiBhdCBkZXZpY2UgMjIuMSAobm8gZHJpdmVyIGF0dGFjaGVkKQpwY2kwOiA8YmFzZSBw ZXJpcGhlcmFsPiBhdCBkZXZpY2UgMjIuMiAobm8gZHJpdmVyIGF0dGFjaGVkKQpwY2kwOiA8YmFz ZSBwZXJpcGhlcmFsPiBhdCBkZXZpY2UgMjIuMyAobm8gZHJpdmVyIGF0dGFjaGVkKQpwY2kwOiA8 YmFzZSBwZXJpcGhlcmFsPiBhdCBkZXZpY2UgMjIuNCAobm8gZHJpdmVyIGF0dGFjaGVkKQpwY2kw OiA8YmFzZSBwZXJpcGhlcmFsPiBhdCBkZXZpY2UgMjIuNSAobm8gZHJpdmVyIGF0dGFjaGVkKQpw Y2kwOiA8YmFzZSBwZXJpcGhlcmFsPiBhdCBkZXZpY2UgMjIuNiAobm8gZHJpdmVyIGF0dGFjaGVk KQpwY2kwOiA8YmFzZSBwZXJpcGhlcmFsPiBhdCBkZXZpY2UgMjIuNyAobm8gZHJpdmVyIGF0dGFj aGVkKQp1aGNpMDogPEludGVsIDgyODAxSkkgKElDSDEwKSBVU0IgY29udHJvbGxlciBVU0ItRD4g cG9ydCAweGE0MDAtMHhhNDFmIGlycSAxNiBhdCBkZXZpY2UgMjYuMCBvbiBwY2kwCnVoY2kwOiBb SVRIUkVBRF0KdWhjaTA6IExlZ1N1cCA9IDB4MmYwMAp1c2J1czA6IDxJbnRlbCA4MjgwMUpJIChJ Q0gxMCkgVVNCIGNvbnRyb2xsZXIgVVNCLUQ+IG9uIHVoY2kwCnVoY2kxOiA8SW50ZWwgODI4MDFK SSAoSUNIMTApIFVTQiBjb250cm9sbGVyIFVTQi1FPiBwb3J0IDB4YTQ4MC0weGE0OWYgaXJxIDIx IGF0IGRldmljZSAyNi4xIG9uIHBjaTAKdWhjaTE6IFtJVEhSRUFEXQp1aGNpMTogTGVnU3VwID0g MHgyZjAwCnVzYnVzMTogPEludGVsIDgyODAxSkkgKElDSDEwKSBVU0IgY29udHJvbGxlciBVU0It RT4gb24gdWhjaTEKdWhjaTI6IDxJbnRlbCA4MjgwMUpJIChJQ0gxMCkgVVNCIGNvbnRyb2xsZXIg VVNCLUY+IHBvcnQgMHhhODAwLTB4YTgxZiBpcnEgMTkgYXQgZGV2aWNlIDI2LjIgb24gcGNpMAp1 aGNpMjogW0lUSFJFQURdCnVoY2kyOiBMZWdTdXAgPSAweDJmMDAKdXNidXMyOiA8SW50ZWwgODI4 MDFKSSAoSUNIMTApIFVTQiBjb250cm9sbGVyIFVTQi1GPiBvbiB1aGNpMgplaGNpMDogPEludGVs IDgyODAxSkkgKElDSDEwKSBVU0IgMi4wIGNvbnRyb2xsZXIgVVNCLUI+IG1lbSAweGZiY2Y0MDAw LTB4ZmJjZjQzZmYgaXJxIDE4IGF0IGRldmljZSAyNi43IG9uIHBjaTAKZWhjaTA6IFtJVEhSRUFE XQp1c2J1czM6IEVIQ0kgdmVyc2lvbiAxLjAKdXNidXMzOiA8SW50ZWwgODI4MDFKSSAoSUNIMTAp IFVTQiAyLjAgY29udHJvbGxlciBVU0ItQj4gb24gZWhjaTAKcGNpYjc6IDxBQ1BJIFBDSS1QQ0kg YnJpZGdlPiBpcnEgMTcgYXQgZGV2aWNlIDI4LjAgb24gcGNpMApwY2k0OiA8QUNQSSBQQ0kgYnVz PiBvbiBwY2liNwpwY2liODogPEFDUEkgUENJLVBDSSBicmlkZ2U+IGlycSAxNyBhdCBkZXZpY2Ug MjguNCBvbiBwY2kwCnBjaTM6IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWI4CmVtMDogPEludGVsKFIp IFBSTy8xMDAwIE5ldHdvcmsgQ29ubmVjdGlvbiA3LjEuOT4gcG9ydCAweGVjMDAtMHhlYzFmIG1l bSAweGZiZWUwMDAwLTB4ZmJlZmZmZmYsMHhmYmVkYzAwMC0weGZiZWRmZmZmIGlycSAxNiBhdCBk ZXZpY2UgMC4wIG9uIHBjaTMKZW0wOiBVc2luZyBNU0lYIGludGVycnVwdHMgd2l0aCAzIHZlY3Rv cnMKZW0wOiBbSVRIUkVBRF0KZW0wOiBbSVRIUkVBRF0KZW0wOiBbSVRIUkVBRF0KZW0wOiBFdGhl cm5ldCBhZGRyZXNzOiAqKioKcGNpYjk6IDxBQ1BJIFBDSS1QQ0kgYnJpZGdlPiBpcnEgMTYgYXQg ZGV2aWNlIDI4LjUgb24gcGNpMApwY2kyOiA8QUNQSSBQQ0kgYnVzPiBvbiBwY2liOQplbTE6IDxJ bnRlbChSKSBQUk8vMTAwMCBOZXR3b3JrIENvbm5lY3Rpb24gNy4xLjk+IHBvcnQgMHhkYzAwLTB4 ZGMxZiBtZW0gMHhmYmRlMDAwMC0weGZiZGZmZmZmLDB4ZmJkZGMwMDAtMHhmYmRkZmZmZiBpcnEg MTcgYXQgZGV2aWNlIDAuMCBvbiBwY2kyCmVtMTogVXNpbmcgTVNJWCBpbnRlcnJ1cHRzIHdpdGgg MyB2ZWN0b3JzCmVtMTogW0lUSFJFQURdCmVtMTogW0lUSFJFQURdCmVtMTogW0lUSFJFQURdCmVt MTogRXRoZXJuZXQgYWRkcmVzczogKioqCnVoY2kzOiA8SW50ZWwgODI4MDFKSSAoSUNIMTApIFVT QiBjb250cm9sbGVyIFVTQi1BPiBwb3J0IDB4YTg4MC0weGE4OWYgaXJxIDIzIGF0IGRldmljZSAy OS4wIG9uIHBjaTAKdWhjaTM6IFtJVEhSRUFEXQp1aGNpMzogTGVnU3VwID0gMHgyZjAwCnVzYnVz NDogPEludGVsIDgyODAxSkkgKElDSDEwKSBVU0IgY29udHJvbGxlciBVU0ItQT4gb24gdWhjaTMK dWhjaTQ6IDxJbnRlbCA4MjgwMUpJIChJQ0gxMCkgVVNCIGNvbnRyb2xsZXIgVVNCLUI+IHBvcnQg MHhhYzAwLTB4YWMxZiBpcnEgMTkgYXQgZGV2aWNlIDI5LjEgb24gcGNpMAp1aGNpNDogW0lUSFJF QURdCnVoY2k0OiBMZWdTdXAgPSAweDJmMDAKdXNidXM1OiA8SW50ZWwgODI4MDFKSSAoSUNIMTAp IFVTQiBjb250cm9sbGVyIFVTQi1CPiBvbiB1aGNpNAp1aGNpNTogPEludGVsIDgyODAxSkkgKElD SDEwKSBVU0IgY29udHJvbGxlciBVU0ItQz4gcG9ydCAweGIwMDAtMHhiMDFmIGlycSAxOCBhdCBk ZXZpY2UgMjkuMiBvbiBwY2kwCnVoY2k1OiBbSVRIUkVBRF0KdWhjaTU6IExlZ1N1cCA9IDB4MmYw MAp1c2J1czY6IDxJbnRlbCA4MjgwMUpJIChJQ0gxMCkgVVNCIGNvbnRyb2xsZXIgVVNCLUM+IG9u IHVoY2k1CmVoY2kxOiA8SW50ZWwgODI4MDFKSSAoSUNIMTApIFVTQiAyLjAgY29udHJvbGxlciBV U0ItQT4gbWVtIDB4ZmJjZjYwMDAtMHhmYmNmNjNmZiBpcnEgMjMgYXQgZGV2aWNlIDI5Ljcgb24g cGNpMAplaGNpMTogW0lUSFJFQURdCnVzYnVzNzogRUhDSSB2ZXJzaW9uIDEuMAp1c2J1czc6IDxJ bnRlbCA4MjgwMUpJIChJQ0gxMCkgVVNCIDIuMCBjb250cm9sbGVyIFVTQi1BPiBvbiBlaGNpMQpw Y2liMTA6IDxBQ1BJIFBDSS1QQ0kgYnJpZGdlPiBhdCBkZXZpY2UgMzAuMCBvbiBwY2kwCnBjaTE6 IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWIxMAp2Z2FwY2kwOiA8VkdBLWNvbXBhdGlibGUgZGlzcGxh eT4gcG9ydCAweGNjMDAtMHhjYzdmIG1lbSAweGZiMDAwMDAwLTB4ZmI3ZmZmZmYsMHhmYWZlMDAw MC0weGZhZmZmZmZmIGlycSAxNiBhdCBkZXZpY2UgMC4wIG9uIHBjaTEKaXNhYjA6IDxQQ0ktSVNB IGJyaWRnZT4gYXQgZGV2aWNlIDMxLjAgb24gcGNpMAppc2EwOiA8SVNBIGJ1cz4gb24gaXNhYjAK YWhjaTA6IDxJbnRlbCBJQ0gxMCBBSENJIFNBVEEgY29udHJvbGxlcj4gcG9ydCAweGI4ODAtMHhi ODg3LDB4YjgwMC0weGI4MDMsMHhiNDgwLTB4YjQ4NywweGI0MDAtMHhiNDAzLDB4YjA4MC0weGIw OWYgbWVtIDB4ZmJjZjgwMDAtMHhmYmNmODdmZiBpcnEgMTkgYXQgZGV2aWNlIDMxLjIgb24gcGNp MAphaGNpMDogW0lUSFJFQURdCmFoY2kwOiBBSENJIHYxLjIwIHdpdGggNiAzR2JwcyBwb3J0cywg UG9ydCBNdWx0aXBsaWVyIG5vdCBzdXBwb3J0ZWQKYWhjaWNoMDogPEFIQ0kgY2hhbm5lbD4gYXQg Y2hhbm5lbCAwIG9uIGFoY2kwCmFoY2ljaDA6IFtJVEhSRUFEXQphaGNpY2gxOiA8QUhDSSBjaGFu bmVsPiBhdCBjaGFubmVsIDEgb24gYWhjaTAKYWhjaWNoMTogW0lUSFJFQURdCmFoY2ljaDI6IDxB SENJIGNoYW5uZWw+IGF0IGNoYW5uZWwgMiBvbiBhaGNpMAphaGNpY2gyOiBbSVRIUkVBRF0KYWhj aWNoMzogPEFIQ0kgY2hhbm5lbD4gYXQgY2hhbm5lbCAzIG9uIGFoY2kwCmFoY2ljaDM6IFtJVEhS RUFEXQphaGNpY2g0OiA8QUhDSSBjaGFubmVsPiBhdCBjaGFubmVsIDQgb24gYWhjaTAKYWhjaWNo NDogW0lUSFJFQURdCmFoY2ljaDU6IDxBSENJIGNoYW5uZWw+IGF0IGNoYW5uZWwgNSBvbiBhaGNp MAphaGNpY2g1OiBbSVRIUkVBRF0KcGNpMDogPHNlcmlhbCBidXMsIFNNQnVzPiBhdCBkZXZpY2Ug MzEuMyAobm8gZHJpdmVyIGF0dGFjaGVkKQphY3BpX2J1dHRvbjA6IDxQb3dlciBCdXR0b24+IG9u IGFjcGkwCmF0cnRjMDogPEFUIHJlYWx0aW1lIGNsb2NrPiBwb3J0IDB4NzAtMHg3MSBpcnEgOCBv biBhY3BpMAp1YXJ0MDogPDE2NTUwIG9yIGNvbXBhdGlibGU+IHBvcnQgMHgzZjgtMHgzZmYgaXJx IDQgZmxhZ3MgMHgxMCBvbiBhY3BpMAp1YXJ0MDogW0ZJTFRFUl0KdWFydDE6IDwxNjU1MCBvciBj b21wYXRpYmxlPiBwb3J0IDB4MmY4LTB4MmZmIGlycSAzIG9uIGFjcGkwCnVhcnQxOiBbRklMVEVS XQphY3BpX2hwZXQwOiA8SGlnaCBQcmVjaXNpb24gRXZlbnQgVGltZXI+IGlvbWVtIDB4ZmVkMDAw MDAtMHhmZWQwMDNmZiBvbiBhY3BpMApUaW1lY291bnRlciAiSFBFVCIgZnJlcXVlbmN5IDE0MzE4 MTgwIEh6IHF1YWxpdHkgOTAwCnFwaTA6IDxRUEkgc3lzdGVtIGJ1cz4gb24gbW90aGVyYm9hcmQK cGNpYjExOiA8UVBJIEhvc3QtUENJIGJyaWRnZT4gcGNpYnVzIDI1NSBvbiBxcGkwCnBjaTI1NTog PFBDSSBidXM+IG9uIHBjaWIxMQpwY2liMTI6IDxRUEkgSG9zdC1QQ0kgYnJpZGdlPiBwY2lidXMg MjU0IG9uIHFwaTAKcGNpMjU0OiA8UENJIGJ1cz4gb24gcGNpYjEyCm9ybTA6IDxJU0EgT3B0aW9u IFJPTT4gYXQgaW9tZW0gMHhjMDAwMC0weGM3ZmZmIG9uIGlzYTAKc2MwOiA8U3lzdGVtIGNvbnNv bGU+IGF0IGZsYWdzIDB4MTAwIG9uIGlzYTAKc2MwOiBDR0EgPDE2IHZpcnR1YWwgY29uc29sZXMs IGZsYWdzPTB4MzAwPgp2Z2EwOiA8R2VuZXJpYyBJU0EgVkdBPiBhdCBwb3J0IDB4M2QwLTB4M2Ri IGlvbWVtIDB4YjgwMDAtMHhiZmZmZiBvbiBpc2EwCmF0a2JkYzA6IDxLZXlib2FyZCBjb250cm9s bGVyIChpODA0Mik+IGF0IHBvcnQgMHg2MCwweDY0IG9uIGlzYTAKYXRrYmQwOiA8QVQgS2V5Ym9h cmQ+IGlycSAxIG9uIGF0a2JkYzAKa2JkMCBhdCBhdGtiZDAKYXRrYmQwOiBbR0lBTlQtTE9DS0VE XQphdGtiZDA6IFtJVEhSRUFEXQpwcGMwOiBjYW5ub3QgcmVzZXJ2ZSBJL08gcG9ydCByYW5nZQpj b3JldGVtcDA6IDxDUFUgT24tRGllIFRoZXJtYWwgU2Vuc29ycz4gb24gY3B1MAplc3QwOiA8RW5o YW5jZWQgU3BlZWRTdGVwIEZyZXF1ZW5jeSBDb250cm9sPiBvbiBjcHUwCnA0dGNjMDogPENQVSBG cmVxdWVuY3kgVGhlcm1hbCBDb250cm9sPiBvbiBjcHUwCmNvcmV0ZW1wMTogPENQVSBPbi1EaWUg VGhlcm1hbCBTZW5zb3JzPiBvbiBjcHUxCmVzdDE6IDxFbmhhbmNlZCBTcGVlZFN0ZXAgRnJlcXVl bmN5IENvbnRyb2w+IG9uIGNwdTEKcDR0Y2MxOiA8Q1BVIEZyZXF1ZW5jeSBUaGVybWFsIENvbnRy b2w+IG9uIGNwdTEKY29yZXRlbXAyOiA8Q1BVIE9uLURpZSBUaGVybWFsIFNlbnNvcnM+IG9uIGNw dTIKZXN0MjogPEVuaGFuY2VkIFNwZWVkU3RlcCBGcmVxdWVuY3kgQ29udHJvbD4gb24gY3B1Mgpw NHRjYzI6IDxDUFUgRnJlcXVlbmN5IFRoZXJtYWwgQ29udHJvbD4gb24gY3B1Mgpjb3JldGVtcDM6 IDxDUFUgT24tRGllIFRoZXJtYWwgU2Vuc29ycz4gb24gY3B1Mwplc3QzOiA8RW5oYW5jZWQgU3Bl ZWRTdGVwIEZyZXF1ZW5jeSBDb250cm9sPiBvbiBjcHUzCnA0dGNjMzogPENQVSBGcmVxdWVuY3kg VGhlcm1hbCBDb250cm9sPiBvbiBjcHUzCmNvcmV0ZW1wNDogPENQVSBPbi1EaWUgVGhlcm1hbCBT ZW5zb3JzPiBvbiBjcHU0CmVzdDQ6IDxFbmhhbmNlZCBTcGVlZFN0ZXAgRnJlcXVlbmN5IENvbnRy b2w+IG9uIGNwdTQKcDR0Y2M0OiA8Q1BVIEZyZXF1ZW5jeSBUaGVybWFsIENvbnRyb2w+IG9uIGNw dTQKY29yZXRlbXA1OiA8Q1BVIE9uLURpZSBUaGVybWFsIFNlbnNvcnM+IG9uIGNwdTUKZXN0NTog PEVuaGFuY2VkIFNwZWVkU3RlcCBGcmVxdWVuY3kgQ29udHJvbD4gb24gY3B1NQpwNHRjYzU6IDxD UFUgRnJlcXVlbmN5IFRoZXJtYWwgQ29udHJvbD4gb24gY3B1NQpjb3JldGVtcDY6IDxDUFUgT24t RGllIFRoZXJtYWwgU2Vuc29ycz4gb24gY3B1Ngplc3Q2OiA8RW5oYW5jZWQgU3BlZWRTdGVwIEZy ZXF1ZW5jeSBDb250cm9sPiBvbiBjcHU2CnA0dGNjNjogPENQVSBGcmVxdWVuY3kgVGhlcm1hbCBD b250cm9sPiBvbiBjcHU2CmNvcmV0ZW1wNzogPENQVSBPbi1EaWUgVGhlcm1hbCBTZW5zb3JzPiBv biBjcHU3CmVzdDc6IDxFbmhhbmNlZCBTcGVlZFN0ZXAgRnJlcXVlbmN5IENvbnRyb2w+IG9uIGNw dTcKcDR0Y2M3OiA8Q1BVIEZyZXF1ZW5jeSBUaGVybWFsIENvbnRyb2w+IG9uIGNwdTcKY29yZXRl bXA4OiA8Q1BVIE9uLURpZSBUaGVybWFsIFNlbnNvcnM+IG9uIGNwdTgKZXN0ODogPEVuaGFuY2Vk IFNwZWVkU3RlcCBGcmVxdWVuY3kgQ29udHJvbD4gb24gY3B1OApwNHRjYzg6IDxDUFUgRnJlcXVl bmN5IFRoZXJtYWwgQ29udHJvbD4gb24gY3B1OApjb3JldGVtcDk6IDxDUFUgT24tRGllIFRoZXJt YWwgU2Vuc29ycz4gb24gY3B1OQplc3Q5OiA8RW5oYW5jZWQgU3BlZWRTdGVwIEZyZXF1ZW5jeSBD b250cm9sPiBvbiBjcHU5CnA0dGNjOTogPENQVSBGcmVxdWVuY3kgVGhlcm1hbCBDb250cm9sPiBv biBjcHU5CmNvcmV0ZW1wMTA6IDxDUFUgT24tRGllIFRoZXJtYWwgU2Vuc29ycz4gb24gY3B1MTAK ZXN0MTA6IDxFbmhhbmNlZCBTcGVlZFN0ZXAgRnJlcXVlbmN5IENvbnRyb2w+IG9uIGNwdTEwCnA0 dGNjMTA6IDxDUFUgRnJlcXVlbmN5IFRoZXJtYWwgQ29udHJvbD4gb24gY3B1MTAKY29yZXRlbXAx MTogPENQVSBPbi1EaWUgVGhlcm1hbCBTZW5zb3JzPiBvbiBjcHUxMQplc3QxMTogPEVuaGFuY2Vk IFNwZWVkU3RlcCBGcmVxdWVuY3kgQ29udHJvbD4gb24gY3B1MTEKcDR0Y2MxMTogPENQVSBGcmVx dWVuY3kgVGhlcm1hbCBDb250cm9sPiBvbiBjcHUxMQpjb3JldGVtcDEyOiA8Q1BVIE9uLURpZSBU aGVybWFsIFNlbnNvcnM+IG9uIGNwdTEyCmVzdDEyOiA8RW5oYW5jZWQgU3BlZWRTdGVwIEZyZXF1 ZW5jeSBDb250cm9sPiBvbiBjcHUxMgpwNHRjYzEyOiA8Q1BVIEZyZXF1ZW5jeSBUaGVybWFsIENv bnRyb2w+IG9uIGNwdTEyCmNvcmV0ZW1wMTM6IDxDUFUgT24tRGllIFRoZXJtYWwgU2Vuc29ycz4g b24gY3B1MTMKZXN0MTM6IDxFbmhhbmNlZCBTcGVlZFN0ZXAgRnJlcXVlbmN5IENvbnRyb2w+IG9u IGNwdTEzCnA0dGNjMTM6IDxDUFUgRnJlcXVlbmN5IFRoZXJtYWwgQ29udHJvbD4gb24gY3B1MTMK Y29yZXRlbXAxNDogPENQVSBPbi1EaWUgVGhlcm1hbCBTZW5zb3JzPiBvbiBjcHUxNAplc3QxNDog PEVuaGFuY2VkIFNwZWVkU3RlcCBGcmVxdWVuY3kgQ29udHJvbD4gb24gY3B1MTQKcDR0Y2MxNDog PENQVSBGcmVxdWVuY3kgVGhlcm1hbCBDb250cm9sPiBvbiBjcHUxNApjb3JldGVtcDE1OiA8Q1BV IE9uLURpZSBUaGVybWFsIFNlbnNvcnM+IG9uIGNwdTE1CmVzdDE1OiA8RW5oYW5jZWQgU3BlZWRT dGVwIEZyZXF1ZW5jeSBDb250cm9sPiBvbiBjcHUxNQpwNHRjYzE1OiA8Q1BVIEZyZXF1ZW5jeSBU aGVybWFsIENvbnRyb2w+IG9uIGNwdTE1ClpGUyBmaWxlc3lzdGVtIHZlcnNpb24gNApaRlMgc3Rv cmFnZSBwb29sIHZlcnNpb24gMTUKVGltZWNvdW50ZXJzIHRpY2sgZXZlcnkgMS4wMDAgbXNlYwp2 Ym94ZHJ2OiBmQXN5bmM9MCBvZmZNaW49MHg3MzQgb2ZmTWF4PTB4OGM4CnVzYnVzMDogMTJNYnBz IEZ1bGwgU3BlZWQgVVNCIHYxLjAKdXNidXMxOiAxMk1icHMgRnVsbCBTcGVlZCBVU0IgdjEuMAp1 c2J1czI6IDEyTWJwcyBGdWxsIFNwZWVkIFVTQiB2MS4wCnVzYnVzMzogNDgwTWJwcyBIaWdoIFNw ZWVkIFVTQiB2Mi4wCnVzYnVzNDogMTJNYnBzIEZ1bGwgU3BlZWQgVVNCIHYxLjAKdXNidXM1OiAx Mk1icHMgRnVsbCBTcGVlZCBVU0IgdjEuMAp1c2J1czY6IDEyTWJwcyBGdWxsIFNwZWVkIFVTQiB2 MS4wCnVzYnVzNzogNDgwTWJwcyBIaWdoIFNwZWVkIFVTQiB2Mi4wCnVnZW4wLjE6IDxJbnRlbD4g YXQgdXNidXMwCnVodWIwOiA8SW50ZWwgVUhDSSByb290IEhVQiwgY2xhc3MgOS8wLCByZXYgMS4w MC8xLjAwLCBhZGRyIDE+IG9uIHVzYnVzMAp1Z2VuMS4xOiA8SW50ZWw+IGF0IHVzYnVzMQp1aHVi MTogPEludGVsIFVIQ0kgcm9vdCBIVUIsIGNsYXNzIDkvMCwgcmV2IDEuMDAvMS4wMCwgYWRkciAx PiBvbiB1c2J1czEKdWdlbjIuMTogPEludGVsPiBhdCB1c2J1czIKdWh1YjI6IDxJbnRlbCBVSENJ IHJvb3QgSFVCLCBjbGFzcyA5LzAsIHJldiAxLjAwLzEuMDAsIGFkZHIgMT4gb24gdXNidXMyCnVn ZW4zLjE6IDxJbnRlbD4gYXQgdXNidXMzCnVodWIzOiA8SW50ZWwgRUhDSSByb290IEhVQiwgY2xh c3MgOS8wLCByZXYgMi4wMC8xLjAwLCBhZGRyIDE+IG9uIHVzYnVzMwp1Z2VuNC4xOiA8SW50ZWw+ IGF0IHVzYnVzNAp1aHViNDogPEludGVsIFVIQ0kgcm9vdCBIVUIsIGNsYXNzIDkvMCwgcmV2IDEu MDAvMS4wMCwgYWRkciAxPiBvbiB1c2J1czQKdWdlbjUuMTogPEludGVsPiBhdCB1c2J1czUKdWh1 YjU6IDxJbnRlbCBVSENJIHJvb3QgSFVCLCBjbGFzcyA5LzAsIHJldiAxLjAwLzEuMDAsIGFkZHIg MT4gb24gdXNidXM1CnVnZW42LjE6IDxJbnRlbD4gYXQgdXNidXM2CnVodWI2OiA8SW50ZWwgVUhD SSByb290IEhVQiwgY2xhc3MgOS8wLCByZXYgMS4wMC8xLjAwLCBhZGRyIDE+IG9uIHVzYnVzNgp1 Z2VuNy4xOiA8SW50ZWw+IGF0IHVzYnVzNwp1aHViNzogPEludGVsIEVIQ0kgcm9vdCBIVUIsIGNs YXNzIDkvMCwgcmV2IDIuMDAvMS4wMCwgYWRkciAxPiBvbiB1c2J1czcKYWRhMCBhdCBhaGNpY2gw IGJ1cyAwIHNjYnVzMCB0YXJnZXQgMCBsdW4gMAphZGEwOiA8V0RDIFdEMjAwM0ZZWVMtMDJXMEIw IDAxLjAxRDAxPiBBVEEtOCBTQVRBIDIueCBkZXZpY2UKYWRhMDogMzAwLjAwME1CL3MgdHJhbnNm ZXJzIChTQVRBIDIueCwgVURNQTYsIFBJTyA4MTkyYnl0ZXMpCmFkYTA6IENvbW1hbmQgUXVldWVp bmcgZW5hYmxlZAphZGEwOiAxOTA3NzI5TUIgKDM5MDcwMjkxNjggNTEyIGJ5dGUgc2VjdG9yczog MTZIIDYzUy9UIDE2MzgzQykKYWRhMSBhdCBhaGNpY2gxIGJ1cyAwIHNjYnVzMSB0YXJnZXQgMCBs dW4gMAphZGExOiA8V0RDIFdEMjAwM0ZZWVMtMDJXMEIwIDAxLjAxRDAxPiBBVEEtOCBTQVRBIDIu eCBkZXZpY2UKYWRhMTogMzAwLjAwME1CL3MgdHJhbnNmZXJzIChTQVRBIDIueCwgVURNQTYsIFBJ TyA4MTkyYnl0ZXMpCmFkYTE6IENvbW1hbmQgUXVldWVpbmcgZW5hYmxlZAphZGExOiAxOTA3NzI5 TUIgKDM5MDcwMjkxNjggNTEyIGJ5dGUgc2VjdG9yczogMTZIIDYzUy9UIDE2MzgzQykKYWRhMiBh dCBhaGNpY2gyIGJ1cyAwIHNjYnVzMiB0YXJnZXQgMCBsdW4gMAphZGEyOiA8V0RDIFdEMjAwMkZZ UFMtMDJXM0IxIDA0LjAxRzAyPiBBVEEtOCBTQVRBIDIueCBkZXZpY2UKYWRhMjogMzAwLjAwME1C L3MgdHJhbnNmZXJzIChTQVRBIDIueCwgVURNQTYsIFBJTyA4MTkyYnl0ZXMpCmFkYTI6IENvbW1h bmQgUXVldWVpbmcgZW5hYmxlZAphZGEyOiAxOTA3NzI5TUIgKDM5MDcwMjkxNjggNTEyIGJ5dGUg c2VjdG9yczogMTZIIDYzUy9UIDE2MzgzQykKYWRhMyBhdCBhaGNpY2gzIGJ1cyAwIHNjYnVzMyB0 YXJnZXQgMCBsdW4gMAphZGEzOiA8V0RDIFdEMjAwMkZZUFMtMDJXM0IxIDA0LjAxRzAyPiBBVEEt OCBTQVRBIDIueCBkZXZpY2UKYWRhMzogMzAwLjAwME1CL3MgdHJhbnNmZXJzIChTQVRBIDIueCwg VURNQTYsIFBJTyA4MTkyYnl0ZXMpCmFkYTM6IENvbW1hbmQgUXVldWVpbmcgZW5hYmxlZAphZGEz OiAxOTA3NzI5TUIgKDM5MDcwMjkxNjggNTEyIGJ5dGUgc2VjdG9yczogMTZIIDYzUy9UIDE2Mzgz QykKU01QOiBBUCBDUFUgIzEgTGF1bmNoZWQhClNNUDogQVAgQ1BVICMxNCBMYXVuY2hlZCEKU01Q OiBBUCBDUFUgIzUgTGF1bmNoZWQhClNNUDogQVAgQ1BVICMxMyBMYXVuY2hlZCEKU01QOiBBUCBD UFUgIzIgTGF1bmNoZWQhClNNUDogQVAgQ1BVICMxMiBMYXVuY2hlZCEKU01QOiBBUCBDUFUgIzQg TGF1bmNoZWQhClNNUDogQVAgQ1BVICM4IExhdW5jaGVkIQpTTVA6IEFQIENQVSAjNiBMYXVuY2hl ZCEKU01QOiBBUCBDUFUgIzExIExhdW5jaGVkIQpTTVA6IEFQIENQVSAjMyBMYXVuY2hlZCEKU01Q OiBBUCBDUFUgIzE1IExhdW5jaGVkIQpTTVA6IEFQIENQVSAjNyBMYXVuY2hlZCEKU01QOiBBUCBD UFUgIzEwIExhdW5jaGVkIQpTTVA6IEFQIENQVSAjOSBMYXVuY2hlZCEKdWh1YjA6IDIgcG9ydHMg d2l0aCAyIHJlbW92YWJsZSwgc2VsZiBwb3dlcmVkCnVodWIxOiAyIHBvcnRzIHdpdGggMiByZW1v dmFibGUsIHNlbGYgcG93ZXJlZAp1aHViMjogMiBwb3J0cyB3aXRoIDIgcmVtb3ZhYmxlLCBzZWxm IHBvd2VyZWQKdWh1YjQ6IDIgcG9ydHMgd2l0aCAyIHJlbW92YWJsZSwgc2VsZiBwb3dlcmVkCnVo dWI1OiAyIHBvcnRzIHdpdGggMiByZW1vdmFibGUsIHNlbGYgcG93ZXJlZAp1aHViNjogMiBwb3J0 cyB3aXRoIDIgcmVtb3ZhYmxlLCBzZWxmIHBvd2VyZWQKUm9vdCBtb3VudCB3YWl0aW5nIGZvcjog dXNidXM3IHVzYnVzMwpSb290IG1vdW50IHdhaXRpbmcgZm9yOiB1c2J1czcgdXNidXMzCnVodWIz OiA2IHBvcnRzIHdpdGggNiByZW1vdmFibGUsIHNlbGYgcG93ZXJlZAp1aHViNzogNiBwb3J0cyB3 aXRoIDYgcmVtb3ZhYmxlLCBzZWxmIHBvd2VyZWQKUm9vdCBtb3VudCB3YWl0aW5nIGZvcjogdXNi dXM3CnVnZW43LjI6IDxBbWVyaWNhbiBNZWdhdHJlbmRzIEluYy4+IGF0IHVzYnVzNwpUcnlpbmcg dG8gbW91bnQgcm9vdCBmcm9tIHpmczp6cm9vdAp1Z2VuNC4yOiA8RGVsbD4gYXQgdXNidXM0CnVr YmQwOiA8RVAxIEludGVycnVwdD4gb24gdXNidXM0CmtiZDIgYXQgdWtiZDAKdWdlbjAuMjogPEFt ZXJpY2FuIFBvd2VyIENvbnZlcnNpb24+IGF0IHVzYnVzMAplbTE6IGxpbmsgc3RhdGUgY2hhbmdl ZCB0byBVUApXQVJOSU5HOiBhdHRlbXB0IHRvIGRvbWFpbl9hZGQobmV0Z3JhcGgpIGFmdGVyIGRv bWFpbmZpbmFsaXplKCkKZW0xOiBwcm9taXNjdW91cyBtb2RlIGVuYWJsZWQK --001a11c3d14a807a9c04e074fa2f-- From owner-freebsd-stable@FreeBSD.ORG Mon Jul 1 15:49:42 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 2C2754C3 for ; Mon, 1 Jul 2013 15:49:42 +0000 (UTC) (envelope-from jdc@koitsu.org) Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net [217.70.183.195]) by mx1.freebsd.org (Postfix) with ESMTP id AAB91119F for ; Mon, 1 Jul 2013 15:49:41 +0000 (UTC) Received: from mfilter27-d.gandi.net (mfilter27-d.gandi.net [217.70.178.155]) by relay3-d.mail.gandi.net (Postfix) with ESMTP id CC3B0A8104; Mon, 1 Jul 2013 17:49:28 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter27-d.gandi.net Received: from relay3-d.mail.gandi.net ([217.70.183.195]) by mfilter27-d.gandi.net (mfilter27-d.gandi.net [10.0.15.180]) (amavisd-new, port 10024) with ESMTP id sbPbhQ6peUVV; Mon, 1 Jul 2013 17:49:27 +0200 (CEST) X-Originating-IP: 76.102.14.35 Received: from jdc.koitsu.org (c-76-102-14-35.hsd1.ca.comcast.net [76.102.14.35]) (Authenticated sender: jdc@koitsu.org) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id 113C1A810E; Mon, 1 Jul 2013 17:49:27 +0200 (CEST) Received: by icarus.home.lan (Postfix, from userid 1000) id 2CAED73A1C; Mon, 1 Jul 2013 08:49:25 -0700 (PDT) Date: Mon, 1 Jul 2013 08:49:25 -0700 From: Jeremy Chadwick To: Scott Sipe Subject: Re: ZFS Panic after freebsd-update Message-ID: <20130701154925.GA64899@icarus.home.lan> References: 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: freebsd-stable 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: Mon, 01 Jul 2013 15:49:42 -0000 On Mon, Jul 01, 2013 at 11:35:30AM -0400, Scott Sipe wrote: > *** Sorry for partial first message! (gmail sent after multiple returns > apparently?) *** > > Hello, > > I have not had much time to research this problem yet, so please let me > know what further information I might be able to provide. > > This weekend I attempted to upgrade a computer from 8.2-RELEASE-p3 to 8.4 > using freebsd-update. After I rebooted to test the new kernel, I got a > panic. I had to take a picture of the screen. Here's a condensed version: > > panic: page fault > cpuid = 1 > KDB: stack backtrace: > #0 kdb_backtrace > #1 panic > #2 trap_fatal > #3 trap_pfault > #4 trap > #5 calltrap > #6 vdev_mirror_child_select > #7 ved_mirror_io_start > #8 zio_vdev_io_start > #9 zio_execute > #10 arc_read > #11 dbuf_read > #12 dbuf_findbp > #13 dbuf_hold_impl > #14 dbuf_hold > #15 dnode_hold_impl > #16 dnu_buf_hold > #17 zap_lockdir > Uptime: 5s > Cannot dump. Device not defined or unavailable. > Automatic reboot in 15 seconds - press a key on the console to abort > > uname -a from before (and after) the reboot: > > FreeBSD xeon 8.2-RELEASE-p3 FreeBSD 8.2-RELEASE-p3 #0: Tue Sep 27 18:45:57 > UTC 2011 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC > amd64 > > dmesg is attached. > > I was able to reboot to the old kernel and am up and running back on 8.2 > right now. > > Any thoughts? Thoughts: - All I see is an amd64 system with 16GB RAM and 4 disks driven by an ICH10 in AHCI mode. - Output from: zpool status - Output from: zpool get all - Output from: zfs get all - Output from: "gpart show -p" for every disk on the system - Output from: cat /etc/sysctl.conf - Output from: cat /boot/loader.conf - Is there a reason you do not have dumpdev defined in /etc/rc.conf (or alternately, no swap device defined in /etc/fstab (which will get used/honoured by the dumpdev="auto" (the default)) ? Taking photos of the console and manually typing backtraces in is borderline worthless. Of course when I see lines like this: Trying to mount root from zfs:zroot ...this greatly diminishes any chances of "live debugging" on the system. It amazes me how often I see this come up on the lists -- people who have ZFS problems but use ZFS for their root/var/tmp/usr. I wish that behaviour would stop, as it makes debugging ZFS a serious PITA. This comes up on the list almost constantly, sad panda. - Get yourself stable/9 and try that: https://pub.allbsd.org/FreeBSD-snapshots/ - freebsd-fs is a better place for this discussion, especially since you're running a -RELEASE build, not a -STABLE build. -- | Jeremy Chadwick jdc@koitsu.org | | UNIX Systems Administrator http://jdc.koitsu.org/ | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Mon Jul 1 15:52:48 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 4FD285EF for ; Mon, 1 Jul 2013 15:52:48 +0000 (UTC) (envelope-from jdc@koitsu.org) Received: from relay4-d.mail.gandi.net (relay4-d.mail.gandi.net [217.70.183.196]) by mx1.freebsd.org (Postfix) with ESMTP id 0E27E11C6 for ; Mon, 1 Jul 2013 15:52:47 +0000 (UTC) Received: from mfilter23-d.gandi.net (mfilter23-d.gandi.net [217.70.178.151]) by relay4-d.mail.gandi.net (Postfix) with ESMTP id BB44C172085; Mon, 1 Jul 2013 17:52:30 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter23-d.gandi.net Received: from relay4-d.mail.gandi.net ([217.70.183.196]) by mfilter23-d.gandi.net (mfilter23-d.gandi.net [10.0.15.180]) (amavisd-new, port 10024) with ESMTP id NnvNbyKERXgm; Mon, 1 Jul 2013 17:52:29 +0200 (CEST) X-Originating-IP: 76.102.14.35 Received: from jdc.koitsu.org (c-76-102-14-35.hsd1.ca.comcast.net [76.102.14.35]) (Authenticated sender: jdc@koitsu.org) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id C87371720BA; Mon, 1 Jul 2013 17:52:28 +0200 (CEST) Received: by icarus.home.lan (Postfix, from userid 1000) id E1F6A73A1C; Mon, 1 Jul 2013 08:52:26 -0700 (PDT) Date: Mon, 1 Jul 2013 08:52:26 -0700 From: Jeremy Chadwick To: Scott Sipe Subject: Re: ZFS Panic after freebsd-update Message-ID: <20130701155226.GA65177@icarus.home.lan> References: <20130701154925.GA64899@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130701154925.GA64899@icarus.home.lan> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-stable 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: Mon, 01 Jul 2013 15:52:48 -0000 On Mon, Jul 01, 2013 at 08:49:25AM -0700, Jeremy Chadwick wrote: > - Is there a reason you do not have dumpdev defined in /etc/rc.conf (or > alternately, no swap device defined in /etc/fstab (which will get > used/honoured by the dumpdev="auto" (the default)) ? This should have read "or alternately, ***A*** swap device defined in /etc/fstab ..." -- | Jeremy Chadwick jdc@koitsu.org | | UNIX Systems Administrator http://jdc.koitsu.org/ | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Mon Jul 1 16:10:53 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 3B8B5993 for ; Mon, 1 Jul 2013 16:10:53 +0000 (UTC) (envelope-from prvs=1894c479ef=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 D35F012B0 for ; Mon, 1 Jul 2013 16:10:52 +0000 (UTC) Received: from r2d2 ([82.69.141.170]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50004659809.msg for ; Mon, 01 Jul 2013 17:10:50 +0100 X-Spam-Processed: mail1.multiplay.co.uk, Mon, 01 Jul 2013 17:10:50 +0100 (not processed: message from valid local sender) X-MDDKIM-Result: neutral (mail1.multiplay.co.uk) X-MDRemoteIP: 82.69.141.170 X-Return-Path: prvs=1894c479ef=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-stable@freebsd.org Message-ID: <12C043DE8CE8455D8F0324509D3A245F@multiplay.co.uk> From: "Steven Hartland" To: "Jeremy Chadwick" , "Scott Sipe" References: <20130701154925.GA64899@icarus.home.lan> Subject: Re: ZFS Panic after freebsd-update Date: Mon, 1 Jul 2013 17:10:57 +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 Cc: freebsd-stable 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: Mon, 01 Jul 2013 16:10:53 -0000 ----- Original Message ----- From: "Jeremy Chadwick" To: "Scott Sipe" Cc: "freebsd-stable List" Sent: Monday, July 01, 2013 4:49 PM Subject: Re: ZFS Panic after freebsd-update > On Mon, Jul 01, 2013 at 11:35:30AM -0400, Scott Sipe wrote: >> *** Sorry for partial first message! (gmail sent after multiple returns >> apparently?) *** >> >> Hello, >> >> I have not had much time to research this problem yet, so please let me >> know what further information I might be able to provide. >> >> This weekend I attempted to upgrade a computer from 8.2-RELEASE-p3 to 8.4 >> using freebsd-update. After I rebooted to test the new kernel, I got a >> panic. I had to take a picture of the screen. Here's a condensed version: >> >> panic: page fault >> cpuid = 1 >> KDB: stack backtrace: >> #0 kdb_backtrace >> #1 panic >> #2 trap_fatal >> #3 trap_pfault >> #4 trap >> #5 calltrap >> #6 vdev_mirror_child_select >> #7 ved_mirror_io_start >> #8 zio_vdev_io_start >> #9 zio_execute >> #10 arc_read >> #11 dbuf_read >> #12 dbuf_findbp >> #13 dbuf_hold_impl >> #14 dbuf_hold >> #15 dnode_hold_impl >> #16 dnu_buf_hold >> #17 zap_lockdir >> Uptime: 5s >> Cannot dump. Device not defined or unavailable. >> Automatic reboot in 15 seconds - press a key on the console to abort >> >> uname -a from before (and after) the reboot: >> >> FreeBSD xeon 8.2-RELEASE-p3 FreeBSD 8.2-RELEASE-p3 #0: Tue Sep 27 18:45:57 >> UTC 2011 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC >> amd64 >> >> dmesg is attached. >> >> I was able to reboot to the old kernel and am up and running back on 8.2 >> right now. >> >> Any thoughts? This says your running a 8.2-RELEASE-p3 kernel not an 8.4-RELEASE kernel. Did the upgrade fail or is that dmesg / uname from your old kernel? 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 Mon Jul 1 16:24:22 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id DCEFABFD for ; Mon, 1 Jul 2013 16:24:22 +0000 (UTC) (envelope-from pmather@vt.edu) Received: from lennier.cc.vt.edu (lennier.cc.vt.edu [198.82.162.213]) by mx1.freebsd.org (Postfix) with ESMTP id A01F3134E for ; Mon, 1 Jul 2013 16:24:22 +0000 (UTC) Received: from dagger.cc.vt.edu (dagger.cc.vt.edu [198.82.163.114]) by lennier.cc.vt.edu (8.13.8/8.13.8) with ESMTP id r61GNkmH027143; Mon, 1 Jul 2013 12:23:46 -0400 Received: from auth3.smtp.vt.edu (auth3.smtp.vt.edu [198.82.161.152]) by dagger.cc.vt.edu (MOS 4.3.3-GA) with ESMTP id CDU06844; Mon, 1 Jul 2013 12:23:46 -0400 X-Mirapoint-Received-SPF: 198.82.161.152 auth3.smtp.vt.edu 0 pass X-Mirapoint-Received-SPF: 198.82.161.152 auth3.smtp.vt.edu 0 pass X-Mirapoint-Received-SPF: 198.82.161.152 auth3.smtp.vt.edu 0 pass Received: from pmather.tower.lib.vt.edu (pmather.tower.lib.vt.edu [128.173.51.28]) (authenticated bits=0) by auth3.smtp.vt.edu (8.13.8/8.13.8) with ESMTP id r61GNkI6022635 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 1 Jul 2013 12:23:46 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: ZFS Panic after freebsd-update From: Paul Mather In-Reply-To: <20130701154925.GA64899@icarus.home.lan> Date: Mon, 1 Jul 2013 12:23:45 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130701154925.GA64899@icarus.home.lan> To: Jeremy Chadwick X-Mailer: Apple Mail (2.1508) Cc: freebsd-stable List , Scott Sipe 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, 01 Jul 2013 16:24:22 -0000 On Jul 1, 2013, at 11:49 AM, Jeremy Chadwick wrote: > On Mon, Jul 01, 2013 at 11:35:30AM -0400, Scott Sipe wrote: >> *** Sorry for partial first message! (gmail sent after multiple = returns >> apparently?) *** >>=20 >> Hello, >>=20 >> I have not had much time to research this problem yet, so please let = me >> know what further information I might be able to provide. >> [[...]] >> Any thoughts? >=20 > Thoughts: >=20 > [[..]] > Of course when I see lines like this: >=20 > Trying to mount root from zfs:zroot >=20 > ...this greatly diminishes any chances of "live debugging" on the > system. It amazes me how often I see this come up on the lists -- = people > who have ZFS problems but use ZFS for their root/var/tmp/usr. I wish > that behaviour would stop, as it makes debugging ZFS a serious PITA. > This comes up on the list almost constantly, sad panda. I'm not sure why it amazes you that people are making widespread use of = ZFS. You could make the same argument that people shouldn't use UFS2 = journaling on their file systems because bugs in the implementation = might make debugging journaled UFS2 file systems "a serious PITA." The = point is that there are VERY compelling reasons why people might want to = use ZFS for root/var/tmp/usr/etc. (pooled storage; easy snapshots; etc.) = and there should come a time when a given file system is "generally = regarded as safe." I'd say the time for ZFS came when they removed the = big disclaimer from the boot messages. If ZFS is dangerous, they should = reinstate the "not ready for production" warning. Until they do, I = think it's unfair to castigate people for using ZFS universally. Isn't it a recurring theme on freebsd-current and freebsd-stable that = more people need to use features so they can be debugged in realistic = environments? If you're telling them, "don't use that because it makes = debugging harder," how are they supposed to get debugged and hence = improved? :-) Cheers, Paul.= From owner-freebsd-stable@FreeBSD.ORG Mon Jul 1 17:04:45 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 985424D3 for ; Mon, 1 Jul 2013 17:04:45 +0000 (UTC) (envelope-from jdc@koitsu.org) Received: from relay5-d.mail.gandi.net (relay5-d.mail.gandi.net [217.70.183.197]) by mx1.freebsd.org (Postfix) with ESMTP id 21F371674 for ; Mon, 1 Jul 2013 17:04:44 +0000 (UTC) Received: from mfilter27-d.gandi.net (mfilter27-d.gandi.net [217.70.178.155]) by relay5-d.mail.gandi.net (Postfix) with ESMTP id ABA5141C076; Mon, 1 Jul 2013 19:04:27 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter27-d.gandi.net Received: from relay5-d.mail.gandi.net ([217.70.183.197]) by mfilter27-d.gandi.net (mfilter27-d.gandi.net [10.0.15.180]) (amavisd-new, port 10024) with ESMTP id 0Cd7kxlN1jzR; Mon, 1 Jul 2013 19:04:26 +0200 (CEST) X-Originating-IP: 76.102.14.35 Received: from jdc.koitsu.org (c-76-102-14-35.hsd1.ca.comcast.net [76.102.14.35]) (Authenticated sender: jdc@koitsu.org) by relay5-d.mail.gandi.net (Postfix) with ESMTPSA id 524F841C07F; Mon, 1 Jul 2013 19:04:24 +0200 (CEST) Received: by icarus.home.lan (Postfix, from userid 1000) id 70CD973A1C; Mon, 1 Jul 2013 10:04:22 -0700 (PDT) Date: Mon, 1 Jul 2013 10:04:22 -0700 From: Jeremy Chadwick To: Paul Mather Subject: Re: ZFS Panic after freebsd-update Message-ID: <20130701170422.GA65858@icarus.home.lan> References: <20130701154925.GA64899@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: freebsd-stable List , Scott Sipe 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, 01 Jul 2013 17:04:45 -0000 On Mon, Jul 01, 2013 at 12:23:45PM -0400, Paul Mather wrote: > On Jul 1, 2013, at 11:49 AM, Jeremy Chadwick wrote: > > > On Mon, Jul 01, 2013 at 11:35:30AM -0400, Scott Sipe wrote: > >> *** Sorry for partial first message! (gmail sent after multiple returns > >> apparently?) *** > >> > >> Hello, > >> > >> I have not had much time to research this problem yet, so please let me > >> know what further information I might be able to provide. > >> [[...]] > >> Any thoughts? > > > > Thoughts: > > > > [[..]] > > Of course when I see lines like this: > > > > Trying to mount root from zfs:zroot > > > > ...this greatly diminishes any chances of "live debugging" on the > > system. It amazes me how often I see this come up on the lists -- people > > who have ZFS problems but use ZFS for their root/var/tmp/usr. I wish > > that behaviour would stop, as it makes debugging ZFS a serious PITA. > > This comes up on the list almost constantly, sad panda. > > > I'm not sure why it amazes you that people are making widespread use of ZFS. It's not widespread use of ZFS. It's widespread use of ZFS as their sole filesystem (specifically root/var/tmp/usr, or more specifically just root/usr). People are operating with the belief that "ZFS just works", when reality shows "it works until it doesn't". The mentality seems to be "it's so rock solid it'll never break" along with "it can't happen to me". I tend to err on the side of caution, hence avoidance of ZFS for critical things like the aforementioned. It's different if you have a UFS root/var/tmp/usr and ZFS for everything else. You then have a system you can boot/use without issue even if ZFS is crapping the bed. > You could make the same argument that people shouldn't use UFS2 > journaling on their file systems because bugs in the implementation > might make debugging journaled UFS2 file systems "a serious PITA." Yup, and I do make that argument, quite regularly at that. There is even some evidence at this point in time that softupdates are broken: http://lists.freebsd.org/pipermail/freebsd-fs/2013-June/017424.html > The point is that there are VERY compelling reasons why people might > want to use ZFS for root/var/tmp/usr/etc. (pooled storage; easy > snapshots; etc.) and there should come a time when a given file system > is "generally regarded as safe." While there may be compelling reasons, those reasons quickly get shot down when they realise they have a system they can't easily do troubleshooting with when the issue is with ZFS. > I'd say the time for ZFS came when they removed the big disclaimer > from the boot messages. If ZFS is dangerous, they should reinstate > the "not ready for production" warning. Until they do, I think it's > unfair to castigate people for using ZFS universally. The warning meant absolutely nothing at the time (it did not keep people away from it), and would mean nothing now if brought back. A single kernel printf() is not the right choice of action. Are we better off today than we were when ZFS was originally ported over? Yes, by far. Lots of improvements, in many great/good ways. No argument there. But there is no way I'd risk putting my root filesystem (or other key filesystems) on it -- still too new, still too many bugs, and users don't know about those problems until it's too late. > Isn't it a recurring theme on freebsd-current and freebsd-stable that > more people need to use features so they can be debugged in realistic > environments? If you're telling them, "don't use that because it > makes debugging harder," how are they supposed to get debugged and > hence improved? :-) 95% of FreeBSD users cannot debug kernel problems**. To debug a kernel problem, you need: a crash dump, a usable system with the exact kernel/world where the crash happened (i.e. you cannot crash 8.4 ZFS and boot into 8.2 and reliably debug it using that), and (most important of all) a developer who is familiar with kernel debugging *and* familiar with the bits which are crashing. Those who say what you're quoting are often the latter. Part of the "need people to try this" process you refer to is what stable/X is about, *without* the extra chaos of head. I'm one of those who for the past 15 years has advocated stable/X usage for a lot of reasons; I'll save the diatribe for some other time. But the OP is running -RELEASE, and chooses to run that, along with use of freebsd-update for binary updates. Their choices are limited: stick with 8.2, switch to stable/X, cease use of ZFS, or change OSes entirely. But even stable/X doesn't provide enough coverage at times (the recent fxp(4)/dhclient issue is proof of that). It's just too bad so many people have this broken mindset of what "stability" means on FreeBSD. ** = This number is probably more like 99%, especially when you consider what FreeNAS is catering to/trying to accomplish. -- | Jeremy Chadwick jdc@koitsu.org | | UNIX Systems Administrator http://jdc.koitsu.org/ | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Mon Jul 1 18:04:26 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 7CE42681 for ; Mon, 1 Jul 2013 18:04:26 +0000 (UTC) (envelope-from cscotts@gmail.com) Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::229]) by mx1.freebsd.org (Postfix) with ESMTP id 06CE61912 for ; Mon, 1 Jul 2013 18:04:25 +0000 (UTC) Received: by mail-lb0-f169.google.com with SMTP id d10so2691448lbj.0 for ; Mon, 01 Jul 2013 11:04:25 -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=KZG2Cf4XTgSqP6lCFzaXpjCnx0b6dsOf7/ITfYpiR6E=; b=F+J57ka2d6VDx4xbpREMF3ROM3onKB4qqjAPpQ3DqdZkw2Wsw2+z6g9F0LUKHfe3rp XFCcb/Zd73vCCDlU8IFR973aPNM0hjCw+z7la4/5aFGihnSJ3hT4DQXVI3SnHQUX5X1Q jrcjaCG9d44Uu441EYbl32fCXZ/NV5ivxaHcCKUn5x7bxffPFFzonvjYAL5iKIiyynpa HIn/0RPuKaa0QpV/FdzetDqajzdhKBEafS1im+ffRoExqo3Y0fSWocnz7zDNzEqnuEab VBezcKmPCK5QEiHIaq7nu8cB8QGzfp1OgVNPrAC4O9jrwYJnlotAfRx06M1ly78bISHy 6gdg== MIME-Version: 1.0 X-Received: by 10.112.198.164 with SMTP id jd4mr12406636lbc.74.1372701864983; Mon, 01 Jul 2013 11:04:24 -0700 (PDT) Received: by 10.152.112.195 with HTTP; Mon, 1 Jul 2013 11:04:24 -0700 (PDT) In-Reply-To: <20130701170422.GA65858@icarus.home.lan> References: <20130701154925.GA64899@icarus.home.lan> <20130701170422.GA65858@icarus.home.lan> Date: Mon, 1 Jul 2013 14:04:24 -0400 Message-ID: Subject: Re: ZFS Panic after freebsd-update From: Scott Sipe To: Jeremy Chadwick Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-stable List , Paul Mather 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, 01 Jul 2013 18:04:26 -0000 On Mon, Jul 1, 2013 at 1:04 PM, Jeremy Chadwick wrote: > On Mon, Jul 01, 2013 at 12:23:45PM -0400, Paul Mather wrote: > > On Jul 1, 2013, at 11:49 AM, Jeremy Chadwick wrote: > > > > > Of course when I see lines like this: > > > > > > Trying to mount root from zfs:zroot > > > > > > ...this greatly diminishes any chances of "live debugging" on the > > > system. It amazes me how often I see this come up on the lists -- > people > > > who have ZFS problems but use ZFS for their root/var/tmp/usr. I wish > > > that behaviour would stop, as it makes debugging ZFS a serious PITA. > > > This comes up on the list almost constantly, sad panda. > > > > > > I'm not sure why it amazes you that people are making widespread use of > ZFS. > > It's not widespread use of ZFS. It's widespread use of ZFS as their > sole filesystem (specifically root/var/tmp/usr, or more specifically > just root/usr). People are operating with the belief that "ZFS just > works", when reality shows "it works until it doesn't". The mentality > seems to be "it's so rock solid it'll never break" along with "it can't > happen to me". I tend to err on the side of caution, hence avoidance of > ZFS for critical things like the aforementioned. > > It's different if you have a UFS root/var/tmp/usr and ZFS for everything > else. You then have a system you can boot/use without issue even if ZFS > is crapping the bed. > > ... > > 95% of FreeBSD users cannot debug kernel problems**. To debug a kernel > problem, you need: a crash dump, a usable system with the exact > kernel/world where the crash happened (i.e. you cannot crash 8.4 ZFS and > boot into 8.2 and reliably debug it using that), and (most important of > all) a developer who is familiar with kernel debugging *and* familiar > with the bits which are crashing. Those who say what you're quoting are > often the latter. > > ... > > But the OP is running -RELEASE, and chooses to run that, along with use > of freebsd-update for binary updates. Their choices are limited: stick > with 8.2, switch to stable/X, cease use of ZFS, or change OSes entirely. > So I realize that neither 8.2-RELEASE or 8.4-RELEASE are stable, but I ultimately wasn't sure where the right place to go for discuss 8.4 is? Beyond the FS mailing list, was there a better place for my question? I'll provide the other requested information (zfs outputs, etc) to wherever would be best. This is a production machine (has been since late 2010) and after tweaking some ZFS settings initially has been totally stable. I wasn't incredibly closely involved in the initial configuration, but I've done at least one binary freebsd-update previously. Before this computer I had always done source upgrades. ZFS (and the thought of a panic like the one I saw this weekend!) made me leery of doing that. We're a small business--we have this server, an offsite backup server, and a firewall box. I understand that issues like this are are going to happen when I don't have a dedicated testing box, I just like to try to minimize them and keep them to weekends! It sounds like my best bet might be to add a new UFS disk, do a clean install of 9.1 onto that disk, and then import my existing ZFS pool? Thanks, Scott From owner-freebsd-stable@FreeBSD.ORG Mon Jul 1 18:15:54 2013 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 4D2E39FB for ; Mon, 1 Jul 2013 18:15:54 +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 92CDF19B5 for ; Mon, 1 Jul 2013 18:15:53 +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 VAA28897; Mon, 01 Jul 2013 21:11:42 +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 1UtiZh-0000Mv-Lr; Mon, 01 Jul 2013 21:11:41 +0300 Message-ID: <51D1C625.1030401@FreeBSD.org> Date: Mon, 01 Jul 2013 21:10:45 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130405 Thunderbird/17.0.5 MIME-Version: 1.0 To: Jeremy Chadwick Subject: Re: ZFS Panic after freebsd-update References: <20130701154925.GA64899@icarus.home.lan> <20130701170422.GA65858@icarus.home.lan> In-Reply-To: <20130701170422.GA65858@icarus.home.lan> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable List , Scott Sipe , Paul Mather 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, 01 Jul 2013 18:15:54 -0000 on 01/07/2013 20:04 Jeremy Chadwick said the following: > People are operating with the belief that "ZFS just > works", when reality shows "it works until it doesn't" That reality applies to everything that a man creates with a purpose to work. I am not sure why you are so over-focused on ZFS. Please stop spreading FUD. Thank you. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Mon Jul 1 18:24:04 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id E2BAECE3 for ; Mon, 1 Jul 2013 18:24:04 +0000 (UTC) (envelope-from jdc@koitsu.org) Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net [217.70.183.195]) by mx1.freebsd.org (Postfix) with ESMTP id 83B781A21 for ; Mon, 1 Jul 2013 18:24:04 +0000 (UTC) Received: from mfilter5-d.gandi.net (mfilter5-d.gandi.net [217.70.178.132]) by relay3-d.mail.gandi.net (Postfix) with ESMTP id AE16EA80D2; Mon, 1 Jul 2013 20:23:47 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter5-d.gandi.net Received: from relay3-d.mail.gandi.net ([217.70.183.195]) by mfilter5-d.gandi.net (mfilter5-d.gandi.net [10.0.15.180]) (amavisd-new, port 10024) with ESMTP id MI2c0zCkPUK3; Mon, 1 Jul 2013 20:23:46 +0200 (CEST) X-Originating-IP: 76.102.14.35 Received: from jdc.koitsu.org (c-76-102-14-35.hsd1.ca.comcast.net [76.102.14.35]) (Authenticated sender: jdc@koitsu.org) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id 21421A80CE; Mon, 1 Jul 2013 20:23:45 +0200 (CEST) Received: by icarus.home.lan (Postfix, from userid 1000) id 325BA73A1C; Mon, 1 Jul 2013 11:23:43 -0700 (PDT) Date: Mon, 1 Jul 2013 11:23:43 -0700 From: Jeremy Chadwick To: Scott Sipe Subject: Re: ZFS Panic after freebsd-update Message-ID: <20130701182343.GA67450@icarus.home.lan> References: <20130701154925.GA64899@icarus.home.lan> <20130701170422.GA65858@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: freebsd-stable List , Paul Mather 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, 01 Jul 2013 18:24:05 -0000 On Mon, Jul 01, 2013 at 02:04:24PM -0400, Scott Sipe wrote: > On Mon, Jul 1, 2013 at 1:04 PM, Jeremy Chadwick wrote: > > > On Mon, Jul 01, 2013 at 12:23:45PM -0400, Paul Mather wrote: > > > On Jul 1, 2013, at 11:49 AM, Jeremy Chadwick wrote: > > > > > > > Of course when I see lines like this: > > > > > > > > Trying to mount root from zfs:zroot > > > > > > > > ...this greatly diminishes any chances of "live debugging" on the > > > > system. It amazes me how often I see this come up on the lists -- > > people > > > > who have ZFS problems but use ZFS for their root/var/tmp/usr. I wish > > > > that behaviour would stop, as it makes debugging ZFS a serious PITA. > > > > This comes up on the list almost constantly, sad panda. > > > > > > > > > I'm not sure why it amazes you that people are making widespread use of > > ZFS. > > > > It's not widespread use of ZFS. It's widespread use of ZFS as their > > sole filesystem (specifically root/var/tmp/usr, or more specifically > > just root/usr). People are operating with the belief that "ZFS just > > works", when reality shows "it works until it doesn't". The mentality > > seems to be "it's so rock solid it'll never break" along with "it can't > > happen to me". I tend to err on the side of caution, hence avoidance of > > ZFS for critical things like the aforementioned. > > > > It's different if you have a UFS root/var/tmp/usr and ZFS for everything > > else. You then have a system you can boot/use without issue even if ZFS > > is crapping the bed. > > > > > > ... > > > > > > 95% of FreeBSD users cannot debug kernel problems**. To debug a kernel > > problem, you need: a crash dump, a usable system with the exact > > kernel/world where the crash happened (i.e. you cannot crash 8.4 ZFS and > > boot into 8.2 and reliably debug it using that), and (most important of > > all) a developer who is familiar with kernel debugging *and* familiar > > with the bits which are crashing. Those who say what you're quoting are > > often the latter. > > > > > > ... > > > > > > But the OP is running -RELEASE, and chooses to run that, along with use > > of freebsd-update for binary updates. Their choices are limited: stick > > with 8.2, switch to stable/X, cease use of ZFS, or change OSes entirely. > > > > So I realize that neither 8.2-RELEASE or 8.4-RELEASE are stable, but I > ultimately wasn't sure where the right place to go for discuss 8.4 is? For filesystem issues, freebsd-fs@ is usually the best choice, because it discusses filesystem-related thing (regardless of stable vs. release, but knowing what version you have of course is mandatory). freebsd-stable@ is mainly for stable/X related discussions. Sorry to add pedanticism to an already difficult situation for you (and I sympathise, particularly since the purpose of the lists is often difficult to discern, even with their terse descriptions in mailman). > Beyond the FS mailing list, was there a better place for my question? I'll > provide the other requested information (zfs outputs, etc) to wherever > would be best. Nope, not as far as I know. The only other place is send-pr(1), once you have an issue that can be reproduced. Keep in mind, however, that none of these options (mailing lists, send-pr, etc.) mandate a response from anyone. You/your business (see below) should be aware that there is always the possibility no one can help solve the actual problem; as such it's important that companies have proper upgrade/migration paths, rollback plans, and so on. > This is a production machine (has been since late 2010) and after tweaking > some ZFS settings initially has been totally stable. I wasn't incredibly > closely involved in the initial configuration, but I've done at least one > binary freebsd-update previously. Well regardless it sounds like moving from 8.2-RELEASE to 8.4-RELEASE causes ZFS to break for you, so that would classify as a regression. What the root cause is, however, is still unknown. Point: 8.2-RELEASE came out in February 2011, and 8.4-RELEASE came out in June 2013 -- that's almost 2.5 years of changes between versions. The number of changes between these two is major -- hundreds, maybe thousands. ZFS got worked on heavily during this time as well. I tend to tell anyone using ZFS that they should be running a stable/X (particularly stable/9) branch. I can expand on that justification if needed, as it's well-founded for a lot of reasons. > Before this computer I had always done source upgrades. ZFS (and the > thought of a panic like the one I saw this weekend!) made me leery of doing > that. We're a small business--we have this server, an offsite backup > server, and a firewall box. I understand that issues like this are are > going to happen when I don't have a dedicated testing box, I just like to > try to minimize them and keep them to weekends! Understood. > It sounds like my best bet might be to add a new UFS disk, do a clean > install of 9.1 onto that disk, and then import my existing ZFS pool? I would suggest starting with this: Get stable/9 from the place I mentioned, burn an ISO or dd a memstick image to a USB flash drive, and then drop to the Fixit shell (or whatever it's called now, I forget), then try to import your pool. If it works, then you know migrating to stable/9 should work for you (i.e. that the bug/issue/whatever is likely fixed in stable/9), or that some settings/stuff you've configured (probably /boot/loader.conf -- yes I am quite aware of the screwing about required there for ZFS on 8.2) on 8.2 is no longer needed or causing problems on 8.4. If it doesn't work, then you/your company need to work out what your next choice of action should be. -- | Jeremy Chadwick jdc@koitsu.org | | UNIX Systems Administrator http://jdc.koitsu.org/ | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Mon Jul 1 18:49:42 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id AD2C06FE; Mon, 1 Jul 2013 18:49:42 +0000 (UTC) (envelope-from cross+freebsd@distal.com) Received: from mail.distal.com (mail.distal.com [IPv6:2001:470:e24c:200::ae25]) by mx1.freebsd.org (Postfix) with ESMTP id 786011B58; Mon, 1 Jul 2013 18:49:42 +0000 (UTC) Received: from zalamar.mm-corp.net (static-66-16-13-46.dsl.cavtel.net [66.16.13.46]) (authenticated bits=0) by mail.distal.com (8.14.3/8.14.3) with ESMTP id r61IneOT011845 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 1 Jul 2013 14:49:41 -0400 (EDT) From: Chris Ross Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Problems booting into ZFS on recent stable/9 Date: Mon, 1 Jul 2013 14:49:35 -0400 Message-Id: <951F81F6-5301-4DF4-8822-0567FDABA4DB@distal.com> To: freebsd-stable@freebsd.org Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) Cc: freebsd-sparc64@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, 01 Jul 2013 18:49:42 -0000 I had a sparc64 (Netra X1) running a stable/9 from late March 2013. = Actually, the kernel may've been a bit newer than that as I was working = with folks to diagnose and repair some Netra-X1 specific issues. But, = ZFS worked fine. I have two pools, zroot as a RAID1 (using equally = sized partitions at the front of two large disks), and a zdata that is a = large pool of the remaining space of both disks concatenated together. After installing a kernel from a build of [yesterday's] stable/9 = today, I now get a failure when trying to boot, which can be seen at the = end of this clip from the end of the boot messages below. Is anyone aware of a change in recent months that might've caused = this, or have any idea what I may've done wrong? In google'ing I've = seen a few posts talking about ways to import the zfs pool to adjust the = cache file, but I'm not sure if that is or isn't my problem. I don't = think I did anything specific with configuring cache files for either = pool. Thoughts are welcome. I don't have physical access to the machine for = quite a few more hours, but when I do should be able to net-boot into = the earlier freebsd stable/9 that I originally installed onto this host, = and can try a few more things. - Chris atapci0: port = 0x10200-0x10207,0x10218-0x1021b,0x10210-0x10217,0x10208-0x1020b,0x10220-0x= 1022f at device 13.0 on pci0 atapci0: using PIO transfers above 137GB as workaround for 48bit DMA = access bug, expect reduced performance ata2: at channel 0 on atapci0 ata3: at channel 1 on atapci0 rtc0: at port 0x70-0x71 on isa0 uart0: <16550 or compatible> at port 0x3f8-0x3ff irq 43 on isa0 uart0: console (9600,n,8,1) uart1: <16550 or compatible> at port 0x2e8-0x2ef irq 43 on isa0 ZFS NOTICE: Prefetch is disabled by default if less than 4GB of RAM is = present; to enable, add "vfs.zfs.prefetch_disable=3D0" to = /boot/loader.conf. ZFS filesystem version: 5 ZFS storage pool version: features support (5000) Timecounter "tick" frequency 500000000 Hz quality 1000 Event timer "tick" frequency 500000000 Hz quality 1000 Timecounters tick every 1.000 msec usbus0: 12Mbps Full Speed USB v1.0 Root mount waiting for: usbus0 ugen0.1: at usbus0 uhub0: on = usbus0 uhub0: 2 ports with 2 removable, self powered Trying to mount root from zfs:zroot []... Mounting from zfs:zroot failed with error 2. Loader variables: vfs.root.mountfrom=3Dzfs:zroot From owner-freebsd-stable@FreeBSD.ORG Mon Jul 1 18:50:48 2013 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id C72C188B; Mon, 1 Jul 2013 18:50:48 +0000 (UTC) (envelope-from jdc@koitsu.org) Received: from relay5-d.mail.gandi.net (relay5-d.mail.gandi.net [217.70.183.197]) by mx1.freebsd.org (Postfix) with ESMTP id 861E91B91; Mon, 1 Jul 2013 18:50:48 +0000 (UTC) Received: from mfilter20-d.gandi.net (mfilter20-d.gandi.net [217.70.178.148]) by relay5-d.mail.gandi.net (Postfix) with ESMTP id 7FE8941C05A; Mon, 1 Jul 2013 20:50:37 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter20-d.gandi.net Received: from relay5-d.mail.gandi.net ([217.70.183.197]) by mfilter20-d.gandi.net (mfilter20-d.gandi.net [10.0.15.180]) (amavisd-new, port 10024) with ESMTP id jfai2Gwm7y91; Mon, 1 Jul 2013 20:50:35 +0200 (CEST) X-Originating-IP: 76.102.14.35 Received: from jdc.koitsu.org (c-76-102-14-35.hsd1.ca.comcast.net [76.102.14.35]) (Authenticated sender: jdc@koitsu.org) by relay5-d.mail.gandi.net (Postfix) with ESMTPSA id 7BDD041C054; Mon, 1 Jul 2013 20:50:35 +0200 (CEST) Received: by icarus.home.lan (Postfix, from userid 1000) id A376773A1D; Mon, 1 Jul 2013 11:50:33 -0700 (PDT) Date: Mon, 1 Jul 2013 11:50:33 -0700 From: Jeremy Chadwick To: Andriy Gapon Subject: Re: ZFS Panic after freebsd-update Message-ID: <20130701185033.GB67450@icarus.home.lan> References: <20130701154925.GA64899@icarus.home.lan> <20130701170422.GA65858@icarus.home.lan> <51D1C625.1030401@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51D1C625.1030401@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-stable List , Scott Sipe , Paul Mather 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, 01 Jul 2013 18:50:48 -0000 On Mon, Jul 01, 2013 at 09:10:45PM +0300, Andriy Gapon wrote: > on 01/07/2013 20:04 Jeremy Chadwick said the following: > > People are operating with the belief that "ZFS just > > works", when reality shows "it works until it doesn't" > > That reality applies to everything that a man creates with a purpose to work. > I am not sure why you are so over-focused on ZFS. > Please stop spreading FUD. Thank you. The issue is that ZFS on FreeBSD is still young compared to other filesystems (specifically UFS). Nothing is perfect, but FFS/UFS tends to have a significantly larger number of bugs worked out of it to the point where people can use it without losing sleep (barring the SUJ stuff, don't get me started). I have the same concerns over other things, like ext2fs and fusefs for that matter -- but this thread is about a ZFS-related crash, and that's why I'm "over-focused" on it. A heterogeneous (UFS+ZFS) setup, rather than homogeneous (ZFS-only), results in a system where an admin can upgrade + boot into single-user and perform some tasks to test/troubleshoot; if the ZFS layer is broken, it doesn't mean an essentially useless box. That isn't FUD, that's just the stage we're at right now. I'm aware lots of people have working ZFS-exclusive setups; like I said, "works great until it doesn't". So, how do you kernel guys debug a problem in this environment: - ZFS-only - Running -RELEASE (i.e. no source, thus a kernel cannot be rebuilt with added debugging features, etc.) - No swap configured - No serial console -- | Jeremy Chadwick jdc@koitsu.org | | UNIX Systems Administrator http://jdc.koitsu.org/ | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Mon Jul 1 18:57:22 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 1D7A5A65 for ; Mon, 1 Jul 2013 18:57:22 +0000 (UTC) (envelope-from prvs=1894c479ef=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 985F61BF8 for ; Mon, 1 Jul 2013 18:57:21 +0000 (UTC) Received: from r2d2 ([82.69.141.170]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50004664328.msg for ; Mon, 01 Jul 2013 19:57:18 +0100 X-Spam-Processed: mail1.multiplay.co.uk, Mon, 01 Jul 2013 19:57:18 +0100 (not processed: message from valid local sender) X-MDDKIM-Result: neutral (mail1.multiplay.co.uk) X-MDRemoteIP: 82.69.141.170 X-Return-Path: prvs=1894c479ef=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-stable@freebsd.org Message-ID: From: "Steven Hartland" To: "Scott Sipe" , "Jeremy Chadwick" References: <20130701154925.GA64899@icarus.home.lan> <20130701170422.GA65858@icarus.home.lan> Subject: Re: ZFS Panic after freebsd-update Date: Mon, 1 Jul 2013 19:56:07 +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 Cc: freebsd-stable List , Paul Mather 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, 01 Jul 2013 18:57:22 -0000 ----- Original Message ----- From: "Scott Sipe" > So I realize that neither 8.2-RELEASE or 8.4-RELEASE are stable, but I > ultimately wasn't sure where the right place to go for discuss 8.4 is? > Beyond the FS mailing list, was there a better place for my question? I'll > provide the other requested information (zfs outputs, etc) to wherever > would be best. > > This is a production machine (has been since late 2010) and after tweaking > some ZFS settings initially has been totally stable. I wasn't incredibly > closely involved in the initial configuration, but I've done at least one > binary freebsd-update previously. > > Before this computer I had always done source upgrades. ZFS (and the > thought of a panic like the one I saw this weekend!) made me leery of doing > that. We're a small business--we have this server, an offsite backup > server, and a firewall box. I understand that issues like this are are > going to happen when I don't have a dedicated testing box, I just like to > try to minimize them and keep them to weekends! > > It sounds like my best bet might be to add a new UFS disk, do a clean > install of 9.1 onto that disk, and then import my existing ZFS pool? There should be no reason why 8.4-RELEASE shouldn't work fine. Yes ZFS is continuously improving and these fixes / enhancements first hit head / current and are then MFC'ed back to stable/9 & stable/8, but that doesn't mean the release branches should be avoided. If you can I would try booting from a 8.4-RELEASE cdrom / iso to see if it can successfully read the pool as this could eliminate out of sync kernel / world issues. 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 Mon Jul 1 19:10:13 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 6CBA2EAA for ; Mon, 1 Jul 2013 19:10:13 +0000 (UTC) (envelope-from rainer@ultra-secure.de) Received: from mail.ultra-secure.de (mail.ultra-secure.de [78.47.114.122]) by mx1.freebsd.org (Postfix) with ESMTP id CA05C1C9A for ; Mon, 1 Jul 2013 19:10:12 +0000 (UTC) Received: (qmail 73754 invoked by uid 89); 1 Jul 2013 19:08:13 -0000 Received: from unknown (HELO ?192.168.1.201?) (rainer@ultra-secure.de@217.71.83.52) by mail.ultra-secure.de with ESMTPA; 1 Jul 2013 19:08:13 -0000 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: ZFS Panic after freebsd-update From: Rainer Duffner X-Priority: 3 In-Reply-To: Date: Mon, 1 Jul 2013 21:08:12 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130701154925.GA64899@icarus.home.lan> <20130701170422.GA65858@icarus.home.lan> To: freebsd-stable List X-Mailer: Apple Mail (2.1508) 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, 01 Jul 2013 19:10:13 -0000 Am 01.07.2013 um 20:56 schrieb "Steven Hartland" = : > ----- Original Message ----- From: "Scott Sipe" >> So I realize that neither 8.2-RELEASE or 8.4-RELEASE are stable, but = I >> ultimately wasn't sure where the right place to go for discuss 8.4 = is? >> Beyond the FS mailing list, was there a better place for my question? = I'll >> provide the other requested information (zfs outputs, etc) to = wherever >> would be best. >> This is a production machine (has been since late 2010) and after = tweaking >> some ZFS settings initially has been totally stable. I wasn't = incredibly >> closely involved in the initial configuration, but I've done at least = one >> binary freebsd-update previously. >> Before this computer I had always done source upgrades. ZFS (and the >> thought of a panic like the one I saw this weekend!) made me leery of = doing >> that. We're a small business--we have this server, an offsite backup >> server, and a firewall box. I understand that issues like this are = are >> going to happen when I don't have a dedicated testing box, I just = like to >> try to minimize them and keep them to weekends! >> It sounds like my best bet might be to add a new UFS disk, do a clean >> install of 9.1 onto that disk, and then import my existing ZFS pool? >=20 > There should be no reason why 8.4-RELEASE shouldn't work fine. >=20 > Yes ZFS is continuously improving and these fixes / enhancements first = hit > head / current and are then MFC'ed back to stable/9 & stable/8, but = that > doesn't mean the release branches should be avoided. >=20 > If you can I would try booting from a 8.4-RELEASE cdrom / iso to see > if it can successfully read the pool as this could eliminate out of = sync > kernel / world issues. Personally, I find mfsbsd much more practical for booting up a = "rescue-environment". Also, if 8.4 does not work for some reason - maybe try 8.3? I have quite a lot of systems running 8.3 (and even more with 9.1) but = none of them do zfsroot and none of them stresses ZFS very much. I've so far resisted the urge to update to 8.4. The reason why I would be interested to run zfs-root is that sometimes, = you only have two hard drives and still want to do ZFS on it. Ideally, though, FreeBSD would be able to do something like SmartOS (one = of the few features I kind of like about it=85), where you boot from an = USB-image (or ideally, via (i)PXE) but use all the available space for = data and (3rd-party) software. That way, you always have something to = boot from, but can maximize the usage of spindles and space. A basic FreeBSD install is, I think, less than 0.5G these days - I = really hate wasting two 300 (or even 600) GB SAS hard disks just for = that. From owner-freebsd-stable@FreeBSD.ORG Mon Jul 1 19:51:45 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 51E9C8A8; Mon, 1 Jul 2013 19:51:45 +0000 (UTC) (envelope-from gpalmer@freebsd.org) Received: from mail.in-addr.com (unknown [IPv6:2001:470:8:162::1]) by mx1.freebsd.org (Postfix) with ESMTP id 284711E37; Mon, 1 Jul 2013 19:51:45 +0000 (UTC) Received: from gjp by mail.in-addr.com with local (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1Utk8S-000HNm-Gs; Mon, 01 Jul 2013 15:51:40 -0400 Date: Mon, 1 Jul 2013 15:51:40 -0400 From: Gary Palmer To: Chris Ross Subject: Re: Problems booting into ZFS on recent stable/9 Message-ID: <20130701195140.GA60515@in-addr.com> References: <951F81F6-5301-4DF4-8822-0567FDABA4DB@distal.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <951F81F6-5301-4DF4-8822-0567FDABA4DB@distal.com> X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: gpalmer@freebsd.org X-SA-Exim-Scanned: No (on mail.in-addr.com); SAEximRunCond expanded to false Cc: freebsd-stable@freebsd.org, freebsd-sparc64@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, 01 Jul 2013 19:51:45 -0000 On Mon, Jul 01, 2013 at 02:49:35PM -0400, Chris Ross wrote: > > I had a sparc64 (Netra X1) running a stable/9 from late March 2013. Actually, the kernel may've been a bit newer than that as I was working with folks to diagnose and repair some Netra-X1 specific issues. But, ZFS worked fine. I have two pools, zroot as a RAID1 (using equally sized partitions at the front of two large disks), and a zdata that is a large pool of the remaining space of both disks concatenated together. > > After installing a kernel from a build of [yesterday's] stable/9 today, I now get a failure when trying to boot, which can be seen at the end of this clip from the end of the boot messages below. > > Is anyone aware of a change in recent months that might've caused this, or have any idea what I may've done wrong? In google'ing I've seen a few posts talking about ways to import the zfs pool to adjust the cache file, but I'm not sure if that is or isn't my problem. I don't think I did anything specific with configuring cache files for either pool. > > Thoughts are welcome. I don't have physical access to the machine for quite a few more hours, but when I do should be able to net-boot into the earlier freebsd stable/9 that I originally installed onto this host, and can try a few more things. > > - Chris > > > atapci0: port 0x10200-0x10207,0x10218-0x1021b,0x10210-0x10217,0x10208-0x1020b,0x10220-0x1022f at device 13.0 on pci0 > atapci0: using PIO transfers above 137GB as workaround for 48bit DMA access bug, expect reduced performance > ata2: at channel 0 on atapci0 > ata3: at channel 1 on atapci0 > rtc0: at port 0x70-0x71 on isa0 > uart0: <16550 or compatible> at port 0x3f8-0x3ff irq 43 on isa0 > uart0: console (9600,n,8,1) > uart1: <16550 or compatible> at port 0x2e8-0x2ef irq 43 on isa0 > ZFS NOTICE: Prefetch is disabled by default if less than 4GB of RAM is present; > to enable, add "vfs.zfs.prefetch_disable=0" to /boot/loader.conf. > ZFS filesystem version: 5 > ZFS storage pool version: features support (5000) > Timecounter "tick" frequency 500000000 Hz quality 1000 > Event timer "tick" frequency 500000000 Hz quality 1000 > Timecounters tick every 1.000 msec > usbus0: 12Mbps Full Speed USB v1.0 > Root mount waiting for: usbus0 > ugen0.1: at usbus0 > uhub0: on usbus0 > uhub0: 2 ports with 2 removable, self powered > Trying to mount root from zfs:zroot []... > Mounting from zfs:zroot failed with error 2. > > Loader variables: > vfs.root.mountfrom=zfs:zroot What is the interface that the disk(s) that ZFS are on? If it's the AcerLabs ATA controller, then there are no disks found. There is an earlier ATA bus (at a guess from the fact ata2 and ata3 are shown above), however I don't see any disks detected. Normally ATA and SCSI/SAS disks are probed asynchronously near the end of the boot and that appears to be missing Gary From owner-freebsd-stable@FreeBSD.ORG Mon Jul 1 21:03:54 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 858B41AB for ; Mon, 1 Jul 2013 21:03:54 +0000 (UTC) (envelope-from haramrae@gmail.com) Received: from mail-ee0-x230.google.com (mail-ee0-x230.google.com [IPv6:2a00:1450:4013:c00::230]) by mx1.freebsd.org (Postfix) with ESMTP id 1B3DF11D5 for ; Mon, 1 Jul 2013 21:03:53 +0000 (UTC) Received: by mail-ee0-f48.google.com with SMTP id b47so2275556eek.21 for ; Mon, 01 Jul 2013 14:03:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=g2LSHSfAG1NNSzGl4tqMlmBb9R/1655aaTFI27Z7Kck=; b=RYlTCzkZPR8Rcm8wusqokj1dva97XXYtK0VUA5sVzXgojfwu6K8HYgpWDJowGLRD42 J02aTGeoP6xLX8OO2Pv7X5vTr3OZplAgXQ1/xqQVh8a+e/EIlOO9qYikFh5joLbAkj+P asoH/L4gwCoHzNkUKLxoVp7IQ1wNv4yeaA5bMJfyGtXLDKQHcKSRUetycqZ3CxF1L0Rj QA1sJnV3JPbrfPGKZWQPWPslAsG7IGYv/Q7scRPLtgZ2xgKa8Rn/nt9yCHK0DCdnfrcS 3zM+KIGOXpU7a07bpNrNQ3LSQtNkyCgaDOMOmGIh+zXLqgF5gOR3vgJDfDpkNdut0z/m uV1Q== X-Received: by 10.15.109.200 with SMTP id cf48mr23079464eeb.46.1372712633291; Mon, 01 Jul 2013 14:03:53 -0700 (PDT) Received: from hollewijn.internal (8d690a59.ftth.concepts.nl. [141.105.10.89]) by mx.google.com with ESMTPSA id bj46sm32161596eeb.13.2013.07.01.14.03.51 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 01 Jul 2013 14:03:51 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Subject: Re: ZFS Panic after freebsd-update From: Alban Hertroys In-Reply-To: <20130701170422.GA65858@icarus.home.lan> Date: Mon, 1 Jul 2013 23:03:50 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <6A61BF65-B96D-49DD-A343-79ED68463505@gmail.com> References: <20130701154925.GA64899@icarus.home.lan> <20130701170422.GA65858@icarus.home.lan> To: Jeremy Chadwick X-Mailer: Apple Mail (2.1503) Cc: freebsd-stable List , Scott Sipe , Paul Mather 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, 01 Jul 2013 21:03:54 -0000 On Jul 1, 2013, at 19:04, Jeremy Chadwick wrote: > But even stable/X doesn't provide enough coverage at times (the recent > fxp(4)/dhclient issue is proof of that). It's just too bad so many > people have this broken mindset of what "stability" means on FreeBSD. As one of the few persons who have run into that issue I feel like I = should speak up here and add that this issue was fixed within a very = reasonable time span after raising the matter here on freebsd-stable@. = You've personally been a great help in getting that fixed, so thank you = for that. Apparently there was one earlier report of the issue very late in the = pre-release process, which does imply that fxp hardware is fairly rarely = in use among FreeBSD users these days (which was the excuse for how the = issue passed testing for 8.4/9.1 RELEASE). I don't think the release = engineering team can really be blamed for not catching bugs that go = unreported that far into the release cycle; they have to make a decision = when to release at some point and the later it gets into the cycle the = harder it is to turn that decision around. I can completely understand = that. That this happened was inconvenient, but it happens in stable. ISTR that = "stable" doesn't mean stable in the sense that it won't crash, but = rather that the API's won't change until the next release. I wish other = OS companies were as reliable; both MS and Apple let a lot more slip by = and they take a lot longer to release fixes as well. Of course nobody likes when their system behaves erratically due to some = error outside their control, but until that point FreeBSD has been = rock-solid for me for years. And even with this issue, the system was = usable. To get back to the ZFS issue... ZFS has always seen a fairly large fraction of raised issues on this = list. Often those were user mistakes, ranging from putting not enough = memory into the system to not assigning enough to the ZIL (once that = became usable). ZFS on FreeBSD has come a long way since then. I don't = think it's in quite as usable a state on, for example, Linux. Yes, people are taking a risk when using ZFS for everything. The same = goes for any FS. No matter which file system you use, if it breaks = you're between a rock and a hard place. Depending on how badly broken it = is, you may end up not being able to access your data and with some data = that's not an option. That's what we have backups and test environments = for, don't we? File system code can break. It shouldn't, and I think it's safe to say = that in FreeBSD's history it has been very rare indeed, but it does = happen. The problem is probably more that it's so rare that people don't = take measures for the few times it does happen; like how many of us have = an atomic shelter available to them? Or a rubber boat? How many nuclear = incidents have there been versus how many serious file-system breakages = in FreeBSD? How many of us first test an update to STABLE on an = identical test system before upgrading our production servers? Jeremy, I know for a fact that you're a lot more on this list than I am = and probably longer than I have been (I'm pretty sure you were around = already back in the days when I started using FreeBSD 2.2.8), but in = this case, as much respect as I have for you, I think you're = overreacting a bit. And finally, we're having this whole discussion about how problematic = FreeBSD's been (or not) recently WHILE THE OP HASN"T EVEN GOTTEN BACK TO = ANSWER DETAILS ABOUT HIS ISSUE YET. Perhaps it's a bit early for that? = It's entirely possible that we're looking at some hardware issue here or = a user error that triggered a corner case that wasn't handled or = something like that. P.S: Personally, I don't use ZFS because I'm a bit of a database nut and = feel like log-based file-systems aren't a good match for database write = loads, but that's mostly just me being pedantic. Cheers, Alban Hertroys -- If you can't see the forest for the trees, cut the trees and you'll find there is no forest. From owner-freebsd-stable@FreeBSD.ORG Mon Jul 1 21:07:03 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 74C732F0 for ; Mon, 1 Jul 2013 21:07:03 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from anubis.delphij.net (anubis.delphij.net [IPv6:2001:470:1:117::25]) by mx1.freebsd.org (Postfix) with ESMTP id 57836120D for ; Mon, 1 Jul 2013 21:07:03 +0000 (UTC) Received: from zeta.ixsystems.com (drawbridge.ixsystems.com [206.40.55.65]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by anubis.delphij.net (Postfix) with ESMTPSA id B7DE51E11B; Mon, 1 Jul 2013 14:07:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=delphij.net; s=anubis; t=1372712823; bh=EN3bclHD3JnU41wQU7qYa/S3tVojw4PCsGPXuWDpAZU=; h=Date:From:Reply-To:To:CC:Subject:References:In-Reply-To; b=1s9ppiNnmrbAx/1I+NFlD/JSlXDqHQxdhqu3up6j7WGCELjdb3tM+x57LxsXSTPKM nEHAZXPF2XRe5ZPgAigD7eIStglG1/OQFkSYyoh9adoFKdVUfZWo99UX/LW+Fq5Bl2 rV/EhQrQEfak6KxS9oPmAx03r2ZrLLp1AzWeN5Ro= Message-ID: <51D1EF75.7080309@delphij.net> Date: Mon, 01 Jul 2013 14:07:01 -0700 From: Xin Li Organization: The FreeBSD Project MIME-Version: 1.0 To: Steven Hartland Subject: Re: ZFS Panic after freebsd-update References: <20130701154925.GA64899@icarus.home.lan> <12C043DE8CE8455D8F0324509D3A245F@multiplay.co.uk> In-Reply-To: <12C043DE8CE8455D8F0324509D3A245F@multiplay.co.uk> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable List , Scott Sipe X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: d@delphij.net List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jul 2013 21:07:03 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 07/01/13 09:10, Steven Hartland wrote: [...] > This says your running a 8.2-RELEASE-p3 kernel not an 8.4-RELEASE > kernel. > > Did the upgrade fail or is that dmesg / uname from your old > kernel? Looking at the context, he used freebsd-update to update 8.2-RELEASE to 8.4-RELEASE (which, the first step would be updating the kernel) and booted with that panic, and reverted to old kernel. It would be helpful if we have address of stack frame #6 as well as the tuning you he have done (in loader.conf), plus the actual panic message (looks like a kernel trap 12, but a glance at the code I didn't find a candidate line where this happens). Cheers, - -- Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJR0e91AAoJEG80Jeu8UPuz05MIAK21VdKOkVNISzrd9ZDKTpml EjKtrOUhXreI21XyuoVxGboIjNfBxbfPxu07Tj6ocY8LwwneMot9nW5d3xtsS71A ap9Ho3KFUKGv5RTHWO7mhbKhSXnKBl/SmyIeLx//I7vCfxQb0MWUT7bdRF56Eojj lUz6dnLDXt6q3p3TGC17mwETHbdvdrr4ptBANAXFaY763WFSW6pLWUr5KIxZ7f7i DqNKpShTC4LsVr6OZjq70E+1XFCM7E//ZKVbJWBNrGJd7kmk7raq7ERx8tJqcWu6 sdxWcjbG6bOlCmONcozohNsqRvpTKu1VK6JsWVBUq9Et2nY/2rKvu5lKyIvxPBg= =NmTM -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Tue Jul 2 02:30:25 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 17499633; Tue, 2 Jul 2013 02:30:25 +0000 (UTC) (envelope-from cross+freebsd@distal.com) Received: from mail.distal.com (mail.distal.com [IPv6:2001:470:e24c:200::ae25]) by mx1.freebsd.org (Postfix) with ESMTP id DD9181ECF; Tue, 2 Jul 2013 02:30:24 +0000 (UTC) Received: from magrathea.distal.com (magrathea.distal.com [IPv6:2001:470:e24c:200:ea06:88ff:feca:960e]) (authenticated bits=0) by mail.distal.com (8.14.3/8.14.3) with ESMTP id r622ULQ2013277 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 1 Jul 2013 22:30:23 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: Problems booting into ZFS on recent stable/9 From: Chris Ross In-Reply-To: <951F81F6-5301-4DF4-8822-0567FDABA4DB@distal.com> Date: Mon, 1 Jul 2013 22:30:21 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <951F81F6-5301-4DF4-8822-0567FDABA4DB@distal.com> To: gpalmer@freebsd.org X-Mailer: Apple Mail (2.1508) Cc: "freebsd-stable@freebsd.org" , freebsd-sparc64@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, 02 Jul 2013 02:30:25 -0000 On Mon Jul 1 19:51:45 UTC 2013, Gary Palmer = wrote: > What is the interface that the disk(s) that ZFS are on? If it's the > AcerLabs ATA controller, then there are no disks found. There is an > earlier ATA bus (at a guess from the fact ata2 and ata3 are shown = above), > however I don't see any disks detected. Normally ATA and SCSI/SAS = disks > are probed asynchronously near the end of the boot and that appears > to be missing Right you are. That's likely the core of the problem, then. On my = netboot of an older kernel, I see more at the end as you describe: atapci0: port = 0x10200-0x10207,0x10218-0x1021b,0x10210-0x10217,0x10208-0x1020b,0x10220-0x= 1022f at device 13.0 on pci0 atapci0: using PIO transfers above 137GB as workaround for 48bit DMA = access bug, expect reduced performance ata2: at channel 0 on atapci0 ata3: at channel 1 on atapci0 nexus0: type unknown (no driver attached) rtc0: at port 0x70-0x71 on isa0 uart0: <16550 or compatible> at port 0x3f8-0x3ff irq 43 on isa0 uart0: console (9600,n,8,1) uart1: <16550 or compatible> at port 0x2e8-0x2ef irq 43 on isa0 ZFS NOTICE: Prefetch is disabled by default if less than 4GB of RAM is = present; to enable, add "vfs.zfs.prefetch_disable=3D0" to = /boot/loader.conf. ZFS filesystem version: 5 ZFS storage pool version: features support (5000) Timecounter "tick" frequency 500000000 Hz quality 1000 Event timer "tick" frequency 500000000 Hz quality 1000 Timecounters tick every 1.000 msec usbus0: 12Mbps Full Speed USB v1.0 ugen0.1: at usbus0 uhub0: on = usbus0 ada0 at ata2 bus 0 scbus0 target 0 lun 0 ada0: ATA-7 device ada0: 66.700MB/s transfers (UDMA4, PIO 8192bytesuhub0: 2 ports with 2 = removable, self powered) ada0: 308921MB (632672208 512 byte sectors: 16H 63S/T 16383C) ada0: Previously was known as ad0 ada1 at ata3 bus 0 scbus1 target 0 lun 0 ada1: ATA-7 device ada1: 66.700MB/s transfers (UDMA4, PIO 8192bytes) ada1: 308921MB (632672208 512 byte sectors: 16H 63S/T 16383C) ada1: Previously was known as ad1 GEOM_MIRROR: Device mirror/gswap launched (2/2). Trying to mount root from nfs: []... dc0: link state changed to UP Maybe I messed something up in the kernel I was building. Let me drop = back to a GENERIC from the same stable/9 and see if that will boot. I just have to figure = out how to get it onto the disks. :-) - Chris From owner-freebsd-stable@FreeBSD.ORG Tue Jul 2 02:50:29 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C05428A1; Tue, 2 Jul 2013 02:50:29 +0000 (UTC) (envelope-from cross+freebsd@distal.com) Received: from mail.distal.com (mail.distal.com [IPv6:2001:470:e24c:200::ae25]) by mx1.freebsd.org (Postfix) with ESMTP id 972AD1F8E; Tue, 2 Jul 2013 02:50:29 +0000 (UTC) Received: from magrathea.distal.com (magrathea.distal.com [IPv6:2001:470:e24c:200:ea06:88ff:feca:960e]) (authenticated bits=0) by mail.distal.com (8.14.3/8.14.3) with ESMTP id r622oSFL016426 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 1 Jul 2013 22:50:28 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: Problems booting into ZFS on recent stable/9 From: Chris Ross In-Reply-To: Date: Mon, 1 Jul 2013 22:50:28 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <9C05FE90-22AC-46B3-B29E-7AD81BA4AF34@distal.com> References: <951F81F6-5301-4DF4-8822-0567FDABA4DB@distal.com> To: gpalmer@freebsd.org X-Mailer: Apple Mail (2.1508) Cc: "freebsd-stable@freebsd.org" , freebsd-sparc64@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, 02 Jul 2013 02:50:29 -0000 On Jul 1, 2013, at 22:30 , Chris Ross wrote: > Maybe I messed something up in the kernel I was building. Let me = drop back to a GENERIC > from the same stable/9 and see if that will boot. I just have to = figure out how to get it onto the > disks. :-) User error. Thanks, Gary. I took too many things out of my kernel, = I'm sure. I loaded a GENERIC from the same sources and it came up fine. I'll = adjust my kernel config and try again, but it's definitely not a FreeBSD = problem. Sorry for the noise. - Chris From owner-freebsd-stable@FreeBSD.ORG Tue Jul 2 06:00:39 2013 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 1137CA46 for ; Tue, 2 Jul 2013 06:00:39 +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 5633917C5 for ; Tue, 2 Jul 2013 06:00: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 JAA11095; Tue, 02 Jul 2013 09:00:33 +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 1Uttdg-0004DF-JX; Tue, 02 Jul 2013 09:00:32 +0300 Message-ID: <51D26C5C.4000107@FreeBSD.org> Date: Tue, 02 Jul 2013 08:59:56 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130405 Thunderbird/17.0.5 MIME-Version: 1.0 To: Jeremy Chadwick Subject: Re: ZFS Panic after freebsd-update References: <20130701154925.GA64899@icarus.home.lan> <20130701170422.GA65858@icarus.home.lan> <51D1C625.1030401@FreeBSD.org> <20130701185033.GB67450@icarus.home.lan> In-Reply-To: <20130701185033.GB67450@icarus.home.lan> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable List , Scott Sipe , Paul Mather 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, 02 Jul 2013 06:00:39 -0000 on 01/07/2013 21:50 Jeremy Chadwick said the following: > The issue is that ZFS on FreeBSD is still young compared to other > filesystems (specifically UFS). That's a fact. > Nothing is perfect, but FFS/UFS tends > to have a significantly larger number of bugs worked out of it to the > point where people can use it without losing sleep (barring the SUJ > stuff, don't get me started). That's subjective. > I have the same concerns over other > things, like ext2fs and fusefs for that matter -- but this thread is > about a ZFS-related crash, and that's why I'm "over-focused" on it. I have an impression that you seem to state your (negative) opinion of ZFS in every other thread about ZFS problems. > A heterogeneous (UFS+ZFS) setup, rather than homogeneous (ZFS-only), > results in a system where an admin can upgrade + boot into single-user > and perform some tasks to test/troubleshoot; if the ZFS layer is > broken, it doesn't mean an essentially useless box. That isn't FUD, > that's just the stage we're at right now. I'm aware lots of people have > working ZFS-exclusive setups; like I said, "works great until it > doesn't". Yeah, a heterogeneous setup can have its benefits, but it can have its drawbacks too. This is true for heterogeneous vs monoculture in general. But the sword cuts both ways: what if something is broken in "UFS layer" or god forbid in VFS layer and you have only UFS? Besides, without mentioning specific classes of problems "ZFS layer is broken" is too vague. > So, how do you kernel guys debug a problem in this environment: > > - ZFS-only > - Running -RELEASE (i.e. no source, thus a kernel cannot be rebuilt > with added debugging features, etc.) > - No swap configured > - No serial console I use boot environments and boot to a previous / known-good environment if I hit a loader bug, a kernel bug or a major userland problem in a new environment. I also use a mirrored setup and keep two copies of earlier boot chains. I am also not shy of live media in the case everything else fails. Now I wonder how you deal with the same kind of UFS-only environment. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Tue Jul 2 07:57:33 2013 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id CEA383F2; Tue, 2 Jul 2013 07:57:33 +0000 (UTC) (envelope-from jdc@koitsu.org) Received: from relay5-d.mail.gandi.net (relay5-d.mail.gandi.net [217.70.183.197]) by mx1.freebsd.org (Postfix) with ESMTP id EAEA01BDC; Tue, 2 Jul 2013 07:57:32 +0000 (UTC) Received: from mfilter26-d.gandi.net (mfilter26-d.gandi.net [217.70.178.154]) by relay5-d.mail.gandi.net (Postfix) with ESMTP id 47FF141C0A4; Tue, 2 Jul 2013 09:57:21 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter26-d.gandi.net Received: from relay5-d.mail.gandi.net ([217.70.183.197]) by mfilter26-d.gandi.net (mfilter26-d.gandi.net [10.0.15.180]) (amavisd-new, port 10024) with ESMTP id 7KXV2EVJlzIy; Tue, 2 Jul 2013 09:57:19 +0200 (CEST) X-Originating-IP: 76.102.14.35 Received: from jdc.koitsu.org (c-76-102-14-35.hsd1.ca.comcast.net [76.102.14.35]) (Authenticated sender: jdc@koitsu.org) by relay5-d.mail.gandi.net (Postfix) with ESMTPSA id D7D5D41C091; Tue, 2 Jul 2013 09:57:18 +0200 (CEST) Received: by icarus.home.lan (Postfix, from userid 1000) id EA97273A1C; Tue, 2 Jul 2013 00:57:16 -0700 (PDT) Date: Tue, 2 Jul 2013 00:57:16 -0700 From: Jeremy Chadwick To: Andriy Gapon Subject: Re: ZFS Panic after freebsd-update Message-ID: <20130702075716.GA79876@icarus.home.lan> References: <20130701154925.GA64899@icarus.home.lan> <20130701170422.GA65858@icarus.home.lan> <51D1C625.1030401@FreeBSD.org> <20130701185033.GB67450@icarus.home.lan> <51D26C5C.4000107@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51D26C5C.4000107@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-stable List , Scott Sipe , Paul Mather 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, 02 Jul 2013 07:57:33 -0000 On Tue, Jul 02, 2013 at 08:59:56AM +0300, Andriy Gapon wrote: > on 01/07/2013 21:50 Jeremy Chadwick said the following: > > The issue is that ZFS on FreeBSD is still young compared to other > > filesystems (specifically UFS). > > That's a fact. > > > Nothing is perfect, but FFS/UFS tends > > to have a significantly larger number of bugs worked out of it to the > > point where people can use it without losing sleep (barring the SUJ > > stuff, don't get me started). > > That's subjective. > > > I have the same concerns over other > > things, like ext2fs and fusefs for that matter -- but this thread is > > about a ZFS-related crash, and that's why I'm "over-focused" on it. > > I have an impression that you seem to state your (negative) opinion of ZFS in > every other thread about ZFS problems. The OP in question ended his post with the line "Thoughts?", and I have given those thoughts. My thoughts/opinions/experience may differ from that of others. Diversity of thoughts/opinions/experiences is good. I'm not some kind of "authoritative ZFS guru" -- far from it. If I misunderstood what "Thoughts?" meant/implied, then draw and quarter me for it; my actions/words = my responsibility. I do not feel I have a "negative opinion" of ZFS. I still use it today on FreeBSD, donated money to Pawel when the project was originally announced (because I wanted to see something new and useful thrive on FreeBSD), and try my best to assist with issues pertaining to it where applicable. These are not the actions of someone with a negative opinion, these are the actions of someone who is supportive while simultaneously very cautious. Is ZFS better today than it was when it was introduced? By a long shot. For example, on my stable/9 system here I don't tune /boot/loader.conf any longer. But that doesn't change my viewpoint when it comes to using ZFS exclusively on a FreeBSD box. > > A heterogeneous (UFS+ZFS) setup, rather than homogeneous (ZFS-only), > > results in a system where an admin can upgrade + boot into single-user > > and perform some tasks to test/troubleshoot; if the ZFS layer is > > broken, it doesn't mean an essentially useless box. That isn't FUD, > > that's just the stage we're at right now. I'm aware lots of people have > > working ZFS-exclusive setups; like I said, "works great until it > > doesn't". > > Yeah, a heterogeneous setup can have its benefits, but it can have its drawbacks > too. This is true for heterogeneous vs monoculture in general. > But the sword cuts both ways: what if something is broken in "UFS layer" or god > forbid in VFS layer and you have only UFS? > Besides, without mentioning specific classes of problems "ZFS layer is broken" > is too vague. The likelihood of something being broken in UFS is significantly lower given its established history. I have to go off of experience, both personal and professional -- in my years of dealing with FreeBSD (1997-present), I have only encountered issues with UFS a few times (I can count them on one, maybe two hands), and I'm choosing to exclude SU+J from the picture for what should be obvious reasons. With ZFS, well... just look at the mailing lists and PR count. I don't want to be a jerk about it, but you really have to look at the quantity. It doesn't mean ZFS is crap, it just means that for me, I don't think we're quite "there" yet. And I will gladly admit -- because you are the one who taught me this -- that every incident need be treated unique. But one can't deny that a substantial percentage (I would say majority) of -fs and -stable posts relate somehow to ZFS; I'm often thrilled when it turns out to be something else. Playing a strange devil's advocate, let me give you an interesting example: softupdates. When SU was introduced to FreeBSD back in the late 90s, there were issues and concerns -- lots. As such, SU was chosen to be disabled by default on root filesystems given the importance of that filesystem (re: "we do not want to risk losing as much data in the case of a crash" -- see the official FAQ, section 8.3). All other filesystems defaulted to SU enabled. It's been like that up until 9.x where it now defaults to enabled. So that's what, 15 years? You could say that my example could also apply to ZFS, i.e. the reports are a part of its growth and maturity, and I'd agree. But I don't feel it's reached the point where I'm willing to risk going ZFS-only. Down the road, sure, but not now. That's just my take on it. Please make sure to also consider, politely, that a lot of people who have issues with ZFS have not been subscribed to the lists for long periods of time. They sign up/post when they have a problem. Meaning: they do not necessarily know of the history. If they did, I (again politely) believe they're likely to use a UFS+ZFS mix, or maybe a gmirror+UFS+ZFS mix (though the GPT/gmirror thing is... never mind...). > > So, how do you kernel guys debug a problem in this environment: > > > > - ZFS-only > > - Running -RELEASE (i.e. no source, thus a kernel cannot be rebuilt > > with added debugging features, etc.) > > - No swap configured > > - No serial console > > I use boot environments and boot to a previous / known-good environment if I hit > a loader bug, a kernel bug or a major userland problem in a new environment. > I also use a mirrored setup and keep two copies of earlier boot chains. > I am also not shy of live media in the case everything else fails. > > Now I wonder how you deal with the same kind of UFS-only environment. The very few times I have had to deal with a system with "filesystem oddities" with UFS, the disk was removed from the system and put into a separate system (running the same kernel/world bits) which was then booted into single-user and things manually dealt with. The points were that the other system 1) was dedicated to this task, 2) had swap set up, and 3) had serial console set up. That system could be rebuilt (from source) to include kernel adjustments/etc. if further debugging data was needed (kernel compile-time features, mainly). All of these could apply to ZFS too, obviously. But in the OP's case, the situation sounds dire given the limitations -- limitations that someone (apparently not him) chose, which greatly hinder debugging/troubleshooting. Had a heterogeneous setup been chosen, the debugging/troubleshooting pains are less (IMO). When I see this, it makes me step back and ponder the decisions that lead to the ZFS-only setup. I work under the model that ZFS is young and therefore will break/cause chaos for me in some way. It's a safety net stemming from actual experiences, in addition to what I see on the lists. I operate under the same pretense when it comes to things like HAMMER on DragonflyBSD and Btrfs on Linux. I do not operate this way when it comes to UFS, just like I do not operate this way when it comes to ext2/ext3 on Linux. I choose to use UFS for root/var/tmp/usr and ZFS for "other stuff" because it allows me to debugging assistance without having to boot alternate media, play around with ISO/memstick images, set up a PXE boot environment, worry about bootloaders, or other whatnots. I just boot the system in single-user and go from there. What about the fact that you do work on ZFS and have familiarity with its code? Would you say your familiarity makes you more comfortable with a ZFS-only setup than others who do not have this familiarity? So with regards to "spreading FUD": - Fear: I'm not afraid of ZFS, I am simply not willing to accept the present-day risks given the alternatives that have been solid for me historically and given my skill set, - Uncertainty: true, I am always uncertain of youthful filesystems, - Doubt: I have no doubts regarding ZFS and its capabilities, potential, usefulness (see above, re: my experience), nor the fact it can (in the binary (yes/no) sense) be used for a root filesystem and/or other critical filesystems. "Spreading FUD" to me conjures the impact of someone running around trying to make people dislike or become afraid of something (I consider this a form of trolling) -- the polar and extreme opposite of advocacy. Such is not my intent, nor has it ever been. While I do have "problems" with FreeBSD (as a whole, the direction it's going, etc.), and would be silly to deny that doesn't influence the tone I use in my mails, it is something quite separate and would rather not go into that. My intent is to make people think about their setup decisions given what they've now experienced, and (hopefully) to get indirect answers as to why they chose the path they did (not quite relevant in this case, since the OP was not the one who deployed this setup). If you feel that's FUD, one might say *that's* subjective, and understandably so -- and I respect that. -- | Jeremy Chadwick jdc@koitsu.org | | UNIX Systems Administrator http://jdc.koitsu.org/ | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Tue Jul 2 12:53:39 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id DDD57472; Tue, 2 Jul 2013 12:53:39 +0000 (UTC) (envelope-from Ivailo.Tanusheff@skrill.com) Received: from db9outboundpool.messaging.microsoft.com (mail-db9lp0251.outbound.messaging.microsoft.com [213.199.154.251]) by mx1.freebsd.org (Postfix) with ESMTP id 3EB331B91; Tue, 2 Jul 2013 12:53:38 +0000 (UTC) Received: from mail72-db9-R.bigfish.com (10.174.16.253) by DB9EHSOBE025.bigfish.com (10.174.14.88) with Microsoft SMTP Server id 14.1.225.23; Tue, 2 Jul 2013 12:38:30 +0000 Received: from mail72-db9 (localhost [127.0.0.1]) by mail72-db9-R.bigfish.com (Postfix) with ESMTP id 1E8187400A7; Tue, 2 Jul 2013 12:38:30 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.249.213; KIP:(null); UIP:(null); IPV:NLI; H:AM2PRD0710HT003.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: 0 X-BigFish: PS0(zz9371I542Izz1f42h1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz17326ah8275dhz2fh2a8h668h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh9a9j1155h) Received-SPF: pass (mail72-db9: domain of skrill.com designates 157.56.249.213 as permitted sender) client-ip=157.56.249.213; envelope-from=Ivailo.Tanusheff@skrill.com; helo=AM2PRD0710HT003.eurprd07.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(377454003)(199002)(189002)(13464003)(81342001)(31966008)(33646001)(4396001)(74366001)(51856001)(81542001)(49866001)(47976001)(46102001)(74876001)(54316002)(80022001)(47736001)(59766001)(47446002)(83072001)(74502001)(50986001)(74706001)(56776001)(74662001)(79102001)(69226001)(56816003)(77982001)(54356001)(76576001)(16406001)(53806001)(76786001)(76796001)(15202345003)(66066001)(63696002)(77096001)(76482001)(74316001)(65816001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:DB3PR07MB057; H:DB3PR07MB059.eurprd07.prod.outlook.com; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail72-db9 (localhost.localdomain [127.0.0.1]) by mail72-db9 (MessageSwitch) id 1372768707571145_20139; Tue, 2 Jul 2013 12:38:27 +0000 (UTC) Received: from DB9EHSMHS022.bigfish.com (unknown [10.174.16.247]) by mail72-db9.bigfish.com (Postfix) with ESMTP id 8733519C004B; Tue, 2 Jul 2013 12:38:27 +0000 (UTC) Received: from AM2PRD0710HT003.eurprd07.prod.outlook.com (157.56.249.213) by DB9EHSMHS022.bigfish.com (10.174.14.32) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 2 Jul 2013 12:38:27 +0000 Received: from DB3PR07MB057.eurprd07.prod.outlook.com (10.242.137.144) by AM2PRD0710HT003.eurprd07.prod.outlook.com (10.255.165.38) with Microsoft SMTP Server (TLS) id 14.16.324.0; Tue, 2 Jul 2013 12:38:26 +0000 Received: from DB3PR07MB059.eurprd07.prod.outlook.com (10.242.137.149) by DB3PR07MB057.eurprd07.prod.outlook.com (10.242.137.144) with Microsoft SMTP Server (TLS) id 15.0.702.21; Tue, 2 Jul 2013 12:38:25 +0000 Received: from DB3PR07MB059.eurprd07.prod.outlook.com ([169.254.2.80]) by DB3PR07MB059.eurprd07.prod.outlook.com ([169.254.2.80]) with mapi id 15.00.0702.005; Tue, 2 Jul 2013 12:38:25 +0000 From: Ivailo Tanusheff To: Chris Ross , "freebsd-stable@freebsd.org" Subject: RE: Problems booting into ZFS on recent stable/9 Thread-Topic: Problems booting into ZFS on recent stable/9 Thread-Index: AQHOdovU6rK4flAwckmF9gN6Tbbs15lRVDeA Date: Tue, 2 Jul 2013 12:38:25 +0000 Message-ID: References: <951F81F6-5301-4DF4-8822-0567FDABA4DB@distal.com> In-Reply-To: <951F81F6-5301-4DF4-8822-0567FDABA4DB@distal.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [217.18.249.148] x-forefront-prvs: 0895DF8FFD Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: skrill.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "freebsd-sparc64@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, 02 Jul 2013 12:53:39 -0000 Hi Cris, Do you still have the following file: /boot/zfs/zpool.cache ? I guess that with the kernel upgrade you have just replaced that :)=20 This is the file that you can create with: zpool set cachefile=3D/boot/zfs/zpool.cache Regards,=20 Ivailo Tanusheff -----Original Message----- From: owner-freebsd-stable@freebsd.org [mailto:owner-freebsd-stable@freebsd= .org] On Behalf Of Chris Ross Sent: Monday, July 01, 2013 9:50 PM To: freebsd-stable@freebsd.org Cc: freebsd-sparc64@freebsd.org Subject: Problems booting into ZFS on recent stable/9 I had a sparc64 (Netra X1) running a stable/9 from late March 2013. Actu= ally, the kernel may've been a bit newer than that as I was working with fo= lks to diagnose and repair some Netra-X1 specific issues. But, ZFS worked = fine. I have two pools, zroot as a RAID1 (using equally sized partitions a= t the front of two large disks), and a zdata that is a large pool of the re= maining space of both disks concatenated together. After installing a kernel from a build of [yesterday's] stable/9 today, I= now get a failure when trying to boot, which can be seen at the end of thi= s clip from the end of the boot messages below. Is anyone aware of a change in recent months that might've caused this, o= r have any idea what I may've done wrong? In google'ing I've seen a few po= sts talking about ways to import the zfs pool to adjust the cache file, but= I'm not sure if that is or isn't my problem. I don't think I did anything= specific with configuring cache files for either pool. Thoughts are welcome. I don't have physical access to the machine for qu= ite a few more hours, but when I do should be able to net-boot into the ear= lier freebsd stable/9 that I originally installed onto this host, and can t= ry a few more things. - Chris atapci0: port 0x10200-0x10207,0x10218-0x= 1021b,0x10210-0x10217,0x10208-0x1020b,0x10220-0x1022f at device 13.0 on pci= 0 atapci0: using PIO transfers above 137GB as workaround for 48bit DMA access= bug, expect reduced performance ata2: at channel 0 on atapci0 ata3: at channel 1 on atapci0 rtc0: at port 0x70-0x71 on isa0 uart0: <16550 or compatible> at port 0x3f8-0x3ff irq 43 on isa0 uart0: console (9600,n,8,1) uart1: <16550 or compatible> at port 0x2e8-0x2ef irq 43 on isa0 ZFS NOTICE:= Prefetch is disabled by default if less than 4GB of RAM is present; to enable, add "vfs.zfs.prefetch_disable=3D0" to /boot/loader.c= onf. ZFS filesystem version: 5 ZFS storage pool version: features support (5000) Timecounter "tick" freque= ncy 500000000 Hz quality 1000 Event timer "tick" frequency 500000000 Hz qua= lity 1000 Timecounters tick every 1.000 msec usbus0: 12Mbps Full Speed USB v1.0 Root mount waiting for: usbus0 ugen0.1: at usbus0 uhub0: on usbus0 uhub0: 2 ports with 2 removable, self powered Trying to mount root from zfs= :zroot []... Mounting from zfs:zroot failed with error 2. Loader variables: vfs.root.mountfrom=3Dzfs:zroot _______________________________________________ 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 Jul 2 16:04:50 2013 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 0FAF4E6; Tue, 2 Jul 2013 16:04:50 +0000 (UTC) (envelope-from byshenknet@byshenk.net) Received: from portland1.byshenk.net (portland1.byshenk.net [69.168.54.16]) by mx1.freebsd.org (Postfix) with ESMTP id E53571778; Tue, 2 Jul 2013 16:04:49 +0000 (UTC) Received: from portland1.byshenk.net (localhost [127.0.0.1]) by portland1.byshenk.net (8.14.7/8.14.7) with ESMTP id r62FeCGu067205; Tue, 2 Jul 2013 08:40:12 -0700 (PDT) (envelope-from byshenknet@portland1.byshenk.net) Received: (from byshenknet@localhost) by portland1.byshenk.net (8.14.7/8.14.7/Submit) id r62FeCso067203; Tue, 2 Jul 2013 08:40:12 -0700 (PDT) (envelope-from byshenknet) Date: Tue, 2 Jul 2013 08:40:12 -0700 From: Greg Byshenk To: freebsd-stable List Subject: Re: ZFS Panic after freebsd-update Message-ID: <20130702154012.GL1134@portland1.byshenk.net> References: <20130701154925.GA64899@icarus.home.lan> <20130701170422.GA65858@icarus.home.lan> <51D1C625.1030401@FreeBSD.org> <20130701185033.GB67450@icarus.home.lan> <51D26C5C.4000107@FreeBSD.org> <20130702075716.GA79876@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130702075716.GA79876@icarus.home.lan> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=unavailable version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on portland1.byshenk.net Cc: Jeremy Chadwick , Andriy Gapon 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, 02 Jul 2013 16:04:50 -0000 On Tue, Jul 02, 2013 at 12:57:16AM -0700, Jeremy Chadwick wrote: > But in the OP's case, the situation sounds dire given the limitations -- > limitations that someone (apparently not him) chose, which greatly > hinder debugging/troubleshooting. Had a heterogeneous setup been > chosen, the debugging/troubleshooting pains are less (IMO). When I see > this, it makes me step back and ponder the decisions that lead to the > ZFS-only setup. As an observer (though one who has used ZFS for some time, now), I might suggest that this can at least -seem- like FUD about ZFS because the "limitations" don't necessarily have anything to do with ZFS. That is, a situation in which one cannot recover, nor even effectively troubleshoot, if there is a problem, will be a "dire" one, regardless of what the problem might be or where its source might lie. -- greg byshenk - gbyshenk@byshenk.net - Leiden, NL - Portland, OR USA From owner-freebsd-stable@FreeBSD.ORG Wed Jul 3 12:31:36 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 1A9004DE; Wed, 3 Jul 2013 12:31:36 +0000 (UTC) (envelope-from marck@rinet.ru) Received: from woozle.rinet.ru (woozle.rinet.ru [195.54.192.68]) by mx1.freebsd.org (Postfix) with ESMTP id 9E10E1883; Wed, 3 Jul 2013 12:31:35 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by woozle.rinet.ru (8.14.5/8.14.5) with ESMTP id r63CVYw9088280; Wed, 3 Jul 2013 16:31:34 +0400 (MSK) (envelope-from marck@rinet.ru) Date: Wed, 3 Jul 2013 16:31:34 +0400 (MSK) From: Dmitry Morozovsky To: Pete French Subject: HEADSUP [MFC to hastctl: compact 'status' and introduce 'list' command In-Reply-To: Message-ID: References: <20130524111945.GB12310@gmail.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-NCC-RegID: ru.rinet X-OpenPGP-Key-ID: 6B691B03 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (woozle.rinet.ru [0.0.0.0]); Wed, 03 Jul 2013 16:31:34 +0400 (MSK) Cc: trociny@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, 03 Jul 2013 12:31:36 -0000 Dear colleagues, > > > > > http://svnweb.freebsd.org/changeset/base/248291 > > > > ... > > > > > The reason I'm asking is that it could lead to changes in hast-related scripts > > > > > which one use in production. > > > > > > > > > > > > Any chance we could do this is 2 stages - first being to add 'list' to give us a chnace > > > > ti change scripts over, then make the chnages to 'status'. I have scripts > > > > which try and parse the outut from 'status' which will need changing, > > > > and I sspect I am not the only one... > > > > > > I see no problem with this, as it is one-lite patch (modulo usage/manual page > > > changes); it would be direct commit to -stable, but as it is temporary, I see > > > no problem there too. > > > > > > Mikolaj, your opinion? > > > > It looks like a very good idea. > > Done for stable/9 and stable/8 as r251025 and r251026 > > I hope 6 weeks planned before cleanup will be enough for you and other current > `hastctl list' consumers. Just a quick headsup: I'm planning to finalize merging at July 5th. -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck@FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From owner-freebsd-stable@FreeBSD.ORG Wed Jul 3 15:12:53 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id C6DC2A77 for ; Wed, 3 Jul 2013 15:12:53 +0000 (UTC) (envelope-from rdeiriar@spock.cl) Received: from mail.spock.cl (enteljoven2.enteljoven.cl [164.77.63.23]) by mx1.freebsd.org (Postfix) with ESMTP id 6D56311F1 for ; Wed, 3 Jul 2013 15:12:52 +0000 (UTC) Received: from [10.0.0.110] (200-28-231-70.baf.movistar.cl [200.28.231.70]) (AUTH: PLAIN rdeiriar@spock.cl, TLS: TLSv1/SSLv3,256bits,CAMELLIA256-SHA) by mail.spock.cl with ESMTPSA; Wed, 03 Jul 2013 12:12:23 -0300 id 00000468.0000000051D43F57.0000B379 Message-ID: <51D43E20.5020400@spock.cl> Date: Wed, 03 Jul 2013 11:07:12 -0400 From: Roberto de Iriarte User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130601 Thunderbird/17.0.6 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: 9.1-STABLE zfsloader failure Content-Type: text/plain; charset=ISO-8859-1; 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, 03 Jul 2013 15:12:53 -0000 Yesterday, i updated /usr/src and proceeded to rebuild world + kernel as usual on a zfs root install (single disk) After installing the machine refused to boot with the following error ZFS: can't find pool by guid After booting from CD, i first tried to reinstall gptzfsboot, which worked but did not solve the problem I had to revert to the (thankfully existing!) zfsloader.old in order to be able to boot My disk layout is as follows Geom name: ada0 modified: false state: OK fwheads: 16 fwsectors: 63 last: 625142414 first: 34 entries: 128 scheme: GPT Providers: 1. Name: ada0p1 Mediasize: 65536 (64k) Sectorsize: 512 Stripesize: 0 Stripeoffset: 17408 Mode: r0w0e0 rawuuid: 400762ff-df42-11e2-95a9-001cb3c56dfb rawtype: 83bd6b9d-7f41-11dc-be0b-001560b84f0f label: (null) length: 65536 offset: 17408 type: freebsd-boot index: 1 end: 161 start: 34 2. Name: ada0p2 Mediasize: 8589934592 (8.0G) Sectorsize: 512 Stripesize: 0 Stripeoffset: 86016 Mode: r1w1e1 rawuuid: 517ea784-df42-11e2-95a9-001cb3c56dfb rawtype: 516e7cb5-6ecf-11d6-8ff8-00022d09712b label: swap0 length: 8589934592 offset: 86016 type: freebsd-swap index: 2 end: 16777383 start: 168 3. Name: ada0p3 Mediasize: 311482892288 (290G) Sectorsize: 512 Stripesize: 0 Stripeoffset: 86016 Mode: r1w1e2 rawuuid: 5b9f74d2-df42-11e2-95a9-001cb3c56dfb rawtype: 516e7cba-6ecf-11d6-8ff8-00022d09712b label: disk0 length: 311482892288 offset: 8590020608 type: freebsd-zfs index: 3 end: 625142407 start: 16777384 Consumers: 1. Name: ada0 Mediasize: 320072933376 (298G) Sectorsize: 512 Mode: r2w2e5 The new kernel works ok so far FreeBSD mbp 9.1-STABLE FreeBSD 9.1-STABLE #0 r252531: Wed Jul 3 00:14:13 CLT 2013 root@mbp:/usr/obj/usr/src/sys/GENERIC amd64 Is there anything i can do to help debug the problem? Best regards, Roberto From owner-freebsd-stable@FreeBSD.ORG Wed Jul 3 18:18:06 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E7C5825E; Wed, 3 Jul 2013 18:18:06 +0000 (UTC) (envelope-from Andre.Albsmeier@siemens.com) Received: from david.siemens.de (david.siemens.de [192.35.17.14]) by mx1.freebsd.org (Postfix) with ESMTP id 81BA31D20; Wed, 3 Jul 2013 18:18:06 +0000 (UTC) Received: from mail2.siemens.de (localhost [127.0.0.1]) by david.siemens.de (8.13.6/8.13.6) with ESMTP id r63I9Uq8002434; Wed, 3 Jul 2013 20:09:30 +0200 Received: from curry.mchp.siemens.de (curry.mchp.siemens.de [139.25.40.130]) by mail2.siemens.de (8.13.6/8.13.6) with ESMTP id r63I9U88003765; Wed, 3 Jul 2013 20:09:30 +0200 Received: (from localhost) by curry.mchp.siemens.de (8.14.7/8.14.7) id r63I9U8Z012475; Date: Wed, 3 Jul 2013 20:09:29 +0200 From: Andre Albsmeier To: John Baldwin Subject: Re: FreeBSD-9.1: machine reboots during snapshot creation, LORs found Message-ID: <20130703180929.GA19664@bali> References: <20130531122611.GA6607@bali> <201305311051.03157.jhb@freebsd.org> <20130616063942.GA72803@bali> <201306171530.31208.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201306171530.31208.jhb@freebsd.org> X-Echelon: X-Advice: Drop that crappy M$-Outlook, I'm tired of your viruses! 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: Wed, 03 Jul 2013 18:18:07 -0000 On Mon, 17-Jun-2013 at 21:30:31 +0200, John Baldwin wrote: > On Sunday, June 16, 2013 2:39:42 am Andre Albsmeier wrote: > > On Fri, 31-May-2013 at 16:51:03 +0200, John Baldwin wrote: > > > On Friday, May 31, 2013 8:26:11 am Andre Albsmeier wrote: > > > > Each day at 5:15 we are generating snapshots on various machines. > > > > This used to work perfectly under 7-STABLE for years but since > > > > we started to use 9.1-STABLE the machine reboots in about 10% > > > > of all cases. > > > > > > > > After rebooting we find a new snapshot file which is a bit > > > > smaller than the good ones and with different permissions > > > > It does not succeed a fsck. In this example it is the one > > > > whose name is beginning with s3: > > > > > > > > -r--r----- 1 root operator snapshot 72802894528 29 May 05:15 s2-2013.05.28-03.15.04 > > > > -r-------- 1 root operator snapshot 72802893824 29 May 05:15 s3-2013.05.29-03.15.03 > > > > -r--r----- 1 root operator snapshot 72802894528 28 May 14:22 s4-2013.05.23-06.38.44 > > > > -r--r----- 1 root operator snapshot 72802894528 28 May 14:22 s5-2013.05.24-03.15.03 > > > > -r--r----- 1 root operator snapshot 72802894528 28 May 14:22 s6-2013.05.25-03.15.03 > > > > > > > > After enabling DIAGNOSTIC, WITNESS and INVARIANTS in the kernel > > > > I see the following LORs (mksnap_ffs starts exactly at 5:15): > > > > > > > > May 29 05:15:00 palveli kernel: lock order reversal: > > > > May 29 05:15:00 palveli kernel: 1st 0xc2371da8 ufs (ufs) @ /src/src-9/sys/kern/vfs_mount.c:1240 > > > > May 29 05:15:00 palveli kernel: 2nd 0xc2371ec4 devfs (devfs) @ /src/src-9/sys/ufs/ffs/ffs_vfsops.c:1414 > > > > May 29 05:15:04 palveli kernel: lock order reversal: > > > > May 29 05:15:04 palveli kernel: 1st 0xc228471c snaplk (snaplk) @ /src/src-9/sys/ufs/ufs/ufs_vnops.c:976 > > > > May 29 05:15:04 palveli kernel: 2nd 0xc22f25e4 ufs (ufs) @ /src/src-9/sys/ufs/ffs/ffs_snapshot.c:1626 > > > > > > > > Unfortunatley no corefiles are being generated ;-(. > > > > > > > > I have checked and even rebuilt the (UFS1) fs in question > > > > from scratch. I have also seen this happen on an UFS2 on > > > > another machine and on a third one when running "dump -L" > > > > on a root fs. > > > > > > > > Any hints of how to proceed? > > > > > > Would it be possible to setup a serial console that is logged on this machine > > > to see if it is panic'ing but failing to write out a crashdump? > > > > Couldn't attach the serial console yet ;-(. But I had people > > attach a KVMoverIP switch and enabled the various KDB options > > in the kernel. Now we can see a bit more (see below) -- no > > crashdump is being generated though. > > :( Unfortunately these LORs don't really help with discerning the cause of > the reboot. If you have remote power access (and still wanted to test this) > one option would be to change KDB to drop into the debugger on a panic. > Then you could connect over the KVM and take images of the original panic > along with a stack trace. After making core dumps work actually (dump device was stopped and FreeBSD-9 doesn't start it automatically) and upgrading to a recent version of 9.1-STABLE it _seems_ that the troubles are gone. In case the problem reappears I'll come back ;-). Thanks, -Andre > > -- > John Baldwin -- FreeBSD is the most powerful OS. NetBSD is the most portable OS. OpenBSD is the most secure OS. Windoze is the most popular OS. Linux is no OS. From owner-freebsd-stable@FreeBSD.ORG Wed Jul 3 21:55:01 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id D1F90A8B for ; Wed, 3 Jul 2013 21:55:01 +0000 (UTC) (envelope-from jim.harris@gmail.com) Received: from mail-ee0-x231.google.com (mail-ee0-x231.google.com [IPv6:2a00:1450:4013:c00::231]) by mx1.freebsd.org (Postfix) with ESMTP id 6C0EE1AB9 for ; Wed, 3 Jul 2013 21:55:01 +0000 (UTC) Received: by mail-ee0-f49.google.com with SMTP id b57so364805eek.36 for ; Wed, 03 Jul 2013 14:55: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=EQ0iniZCLcgns7IGyeEbPGugp44zA3TmCrXnw5fS/Cc=; b=xhsxOu5/eHAUdlQLryFjQ0aQbv9AUvgURhBCILf4GF2PDHIBrAld9Ch1E3LOgqXiVU pX0JgmboxsMMBvUUZ988hvs1UVhivdf9do3rdfFbZPw0LEZxu+y+bNFc7msK2lm6fgXG izwnCUShUQPBYHD6tG8lU/ALeUShKJpBqUCaDgGM/2gAbMhreDR6W75EZDXIkBN67sFQ qW12wiAcNxd/IX6uhKl4B+wj+hbyxLinTH8+OrCnZDr/BXWCi+Nqj/oQvAr/d+eseBdL 7Rv1byNyB7Gr67WLKnqznIbChBuBXktODaTPgu60wNirf78nPFqtkP/UULWZcSuCsiis Qpwg== MIME-Version: 1.0 X-Received: by 10.14.205.72 with SMTP id i48mr2774571eeo.139.1372888500527; Wed, 03 Jul 2013 14:55:00 -0700 (PDT) Received: by 10.15.25.7 with HTTP; Wed, 3 Jul 2013 14:55:00 -0700 (PDT) In-Reply-To: <20130628013827.GB28137@icarus.home.lan> References: <51CCACF5.5020901@jetcafe.org> <20130628013827.GB28137@icarus.home.lan> Date: Wed, 3 Jul 2013 14:55:00 -0700 Message-ID: Subject: Re: AHCI Patsburg SATA controller and slow transfer speed From: Jim Harris To: Jeremy Chadwick Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: 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: Wed, 03 Jul 2013 21:55:01 -0000 On Thu, Jun 27, 2013 at 6:38 PM, Jeremy Chadwick wrote: > > Intel Patsburg is otherwise known as Intel X79. The X79 > chipset/southbridge offers 6 SATA ports, 2 of which are SATA600, and the > remaining 4 are SATA300: > > http://en.wikipedia.org/wiki/Intel_X79 > > While Wikipedia correctly says Intel X79 is codenamed Patsburg, most Patsburgs are actually known as the C60x family of chipsets. X79 pairs with a Core i7 while the C60x pairs with a Xeon E5. ark.intel.com is a very good decoder ring for all of the Intel code names. http://ark.intel.com/products/codename/29968/Patsburg -Jim From owner-freebsd-stable@FreeBSD.ORG Thu Jul 4 02:43:19 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 84A4E333 for ; Thu, 4 Jul 2013 02:43:19 +0000 (UTC) (envelope-from jdavidlists@gmail.com) Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) by mx1.freebsd.org (Postfix) with ESMTP id 5CC091657 for ; Thu, 4 Jul 2013 02:43:19 +0000 (UTC) Received: by mail-ie0-f173.google.com with SMTP id k13so2192353iea.18 for ; Wed, 03 Jul 2013 19:43:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=G7DFczcXiP0Uhu/9dwkhBUFrsxvRezMu8fmZoZhPrfs=; b=S8DSOw4/uNdrvnrxgZ57mheTlR+pXvGn4j7HdijtTWf3bYbTScwi7KZJEpoPabUz/x F8BWAeY0NsrfWDkZiElezxvt03gQQcnvSGyzTQoRcJ79ySKHSEAdrf8bxaOjz2LcIOb/ N7Tt6ehXnt5C4fSyC5n6rmDjD30tUsFJLqNfoV9z7yPDBs5D62IDUki8mB1nIzLlL5K9 Ww5TeezY0b9YJ01+9fj85H0o3aohjePNX2LKRyM7pl+DOy5PFhAHIgDl0KsmRjIqPdXk iEQiJar5StFYz9uzk1QXAa0hFWhseYvn7BbaNsmAHfeFuQQ/xtQtSDmcG60c+FID6QqH KGxA== MIME-Version: 1.0 X-Received: by 10.50.109.134 with SMTP id hs6mr2083403igb.35.1372905799061; Wed, 03 Jul 2013 19:43:19 -0700 (PDT) Sender: jdavidlists@gmail.com Received: by 10.42.114.73 with HTTP; Wed, 3 Jul 2013 19:43:18 -0700 (PDT) Date: Wed, 3 Jul 2013 22:43:18 -0400 X-Google-Sender-Auth: DeSSSlApIC7qLazbufB0GiwigmE Message-ID: Subject: Phantom nulls in usbdevs.h during 9-STABLE kernel build From: J David To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 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: Thu, 04 Jul 2013 02:43:19 -0000 We are seeing strange problems building the kernel on 9-STABLE. The problem is intermittent and will go away if we build enough times in a row without making any changes. The problem seems to be that the usbdevs.h file (which appears to be automatically generated) gets random NULL bytes in it. This occurs on multiple servers with ECC RAM and ZFS filesystems (sometimes mounted over NFS from separate machines that also have ECC/ZFS), always only in this one file, so it's not faulty RAM or anything like that. We do build with clang and libc++ but we have seen this without those enabled as well. I've enclosed the tail end of two failed build output below. The null interloper appears at a different place in usbdevs.h and while building a different module each time. On the second failure posted below I took a hex dump of the usbdevs.h file. I don't see any NULLs at the target location, which is an empty line. (Just 0a 0a for the empty line.) In fact there are no nulls anywhere in the file. Does anyone have any idea what's going on here? This is an i386 build on 9.1-STABLE r249745, but this problem has existed for us for quite awhile in the 9-STABLE series. Thanks for any advice! First build fails: clang -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mno-aes -mno-avx -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror /usr/src/sys/dev/sound/usb/uaudio.c In file included from /usr/src/sys/dev/sound/usb/uaudio.c:70: ./usbdevs.h:3567:65: error: null character ignored [-Werror,-Wnull-character] #define USB_PRODUCT_SAMSUNG_YP_U4 0x5092 /* YP-U4 MP3 Player */ ^ 1 error generated. *** [uaudio.o] Error code 1 Stop in /usr/obj/usr/src/sys/MYKERN. *** [buildkernel] Error code 1 Stop in /usr/src. *** [buildkernel] Error code 1 Stop in /usr/src. Second build fails in a different spot, nothing changed, just up-arrowed "make buildkernel" : ===> usb/cue (all) clang -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj/usr/src/sys/MYKERN/opt_global.h -I. -I@ -I@/contrib/altq -fno-common -g -I/usr/obj/usr/src/sys/MYKERN -mno-aes -mno-avx -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -std=iso9899:1999 -Qunused-arguments -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -c /usr/src/sys/modules/usb/cue/../../../dev/usb/net/if_cue.c In file included from /usr/src/sys/modules/usb/cue/../../../dev/usb/net/if_cue.c:76: ./usbdevs.h:3549:1: error: null character ignored [-Werror,-Wnull-character] ^ 1 error generated. *** [if_cue.o] Error code 1 Stop in /usr/src/sys/modules/usb/cue. *** [all] Error code 1 Stop in /usr/src/sys/modules/usb. *** [all] Error code 1 Stop in /usr/src/sys/modules. *** [modules-all] Error code 1 Stop in /usr/obj/usr/src/sys/MYKERN. *** [buildkernel] Error code 1 Stop in /usr/src. *** [buildkernel] Error code 1 Stop in /usr/src. Hexdump of relevant section of usbdevs.h for second failure: 00030310 65 66 69 6e 65 09 55 53 42 5f 50 52 4f 44 55 43 |efine.USB_PRODUC| 00030320 54 5f 52 4f 43 4b 46 49 52 45 5f 47 41 4d 45 50 |T_ROCKFIRE_GAMEP| 00030330 41 44 09 30 78 32 30 33 33 09 09 2f 2a 20 67 61 |AD.0x2033../* ga| 00030340 6d 65 70 61 64 20 32 30 33 55 53 42 20 2a 2f 0a |mepad 203USB */.| 00030350 0a 2f 2a 20 52 41 54 4f 43 20 53 79 73 74 65 6d |./* RATOC System| 00030360 73 20 70 72 6f 64 75 63 74 73 20 2a 2f 0a 23 64 |s products */.#d| 00030370 65 66 69 6e 65 09 55 53 42 5f 50 52 4f 44 55 43 |efine.USB_PRODUC| 00030380 54 5f 52 41 54 4f 43 5f 52 45 58 55 53 42 36 30 |T_RATOC_REXUSB60| From owner-freebsd-stable@FreeBSD.ORG Thu Jul 4 05:14:17 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id B01DC2D6; Thu, 4 Jul 2013 05:14:17 +0000 (UTC) (envelope-from Andre.Albsmeier@siemens.com) Received: from thoth.sbs.de (thoth.sbs.de [192.35.17.2]) by mx1.freebsd.org (Postfix) with ESMTP id 480331E4D; Thu, 4 Jul 2013 05:14:16 +0000 (UTC) Received: from mail3.siemens.de (localhost [127.0.0.1]) by thoth.sbs.de (8.13.6/8.13.6) with ESMTP id r645E92u004544; Thu, 4 Jul 2013 07:14:09 +0200 Received: from curry.mchp.siemens.de (curry.mchp.siemens.de [139.25.40.130]) by mail3.siemens.de (8.13.6/8.13.6) with ESMTP id r645E9gZ021165; Thu, 4 Jul 2013 07:14:09 +0200 Received: (from localhost) by curry.mchp.siemens.de (8.14.7/8.14.7) id r645E90B014575; Date: Thu, 4 Jul 2013 07:14:09 +0200 From: Andre Albsmeier To: John Baldwin Subject: Re: FreeBSD-9.1: machine reboots during snapshot creation, LORs found Message-ID: <20130704051409.GA22021@bali> References: <20130531122611.GA6607@bali> <201305311051.03157.jhb@freebsd.org> <20130616063942.GA72803@bali> <201306171530.31208.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201306171530.31208.jhb@freebsd.org> X-Echelon: X-Advice: Drop that crappy M$-Outlook, I'm tired of your viruses! 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, 04 Jul 2013 05:14:17 -0000 On Mon, 17-Jun-2013 at 21:30:31 +0200, John Baldwin wrote: > On Sunday, June 16, 2013 2:39:42 am Andre Albsmeier wrote: > > On Fri, 31-May-2013 at 16:51:03 +0200, John Baldwin wrote: > > > On Friday, May 31, 2013 8:26:11 am Andre Albsmeier wrote: > > > > Each day at 5:15 we are generating snapshots on various machines. > > > > This used to work perfectly under 7-STABLE for years but since > > > > we started to use 9.1-STABLE the machine reboots in about 10% > > > > of all cases. > > > > > > > > After rebooting we find a new snapshot file which is a bit > > > > smaller than the good ones and with different permissions > > > > It does not succeed a fsck. In this example it is the one > > > > whose name is beginning with s3: > > > > > > > > -r--r----- 1 root operator snapshot 72802894528 29 May 05:15 s2-2013.05.28-03.15.04 > > > > -r-------- 1 root operator snapshot 72802893824 29 May 05:15 s3-2013.05.29-03.15.03 > > > > -r--r----- 1 root operator snapshot 72802894528 28 May 14:22 s4-2013.05.23-06.38.44 > > > > -r--r----- 1 root operator snapshot 72802894528 28 May 14:22 s5-2013.05.24-03.15.03 > > > > -r--r----- 1 root operator snapshot 72802894528 28 May 14:22 s6-2013.05.25-03.15.03 > > > > > > > > After enabling DIAGNOSTIC, WITNESS and INVARIANTS in the kernel > > > > I see the following LORs (mksnap_ffs starts exactly at 5:15): > > > > > > > > May 29 05:15:00 palveli kernel: lock order reversal: > > > > May 29 05:15:00 palveli kernel: 1st 0xc2371da8 ufs (ufs) @ /src/src-9/sys/kern/vfs_mount.c:1240 > > > > May 29 05:15:00 palveli kernel: 2nd 0xc2371ec4 devfs (devfs) @ /src/src-9/sys/ufs/ffs/ffs_vfsops.c:1414 > > > > May 29 05:15:04 palveli kernel: lock order reversal: > > > > May 29 05:15:04 palveli kernel: 1st 0xc228471c snaplk (snaplk) @ /src/src-9/sys/ufs/ufs/ufs_vnops.c:976 > > > > May 29 05:15:04 palveli kernel: 2nd 0xc22f25e4 ufs (ufs) @ /src/src-9/sys/ufs/ffs/ffs_snapshot.c:1626 > > > > > > > > Unfortunatley no corefiles are being generated ;-(. > > > > > > > > I have checked and even rebuilt the (UFS1) fs in question > > > > from scratch. I have also seen this happen on an UFS2 on > > > > another machine and on a third one when running "dump -L" > > > > on a root fs. > > > > > > > > Any hints of how to proceed? > > > > > > Would it be possible to setup a serial console that is logged on this machine > > > to see if it is panic'ing but failing to write out a crashdump? > > > > Couldn't attach the serial console yet ;-(. But I had people > > attach a KVMoverIP switch and enabled the various KDB options > > in the kernel. Now we can see a bit more (see below) -- no > > crashdump is being generated though. > > :( Unfortunately these LORs don't really help with discerning the cause of > the reboot. If you have remote power access (and still wanted to test this) > one option would be to change KDB to drop into the debugger on a panic. > Then you could connect over the KVM and take images of the original panic > along with a stack trace. After a few days of no problems, the box decided to crash during mksnap_ffs today ;-(. But now I have a crashdump, see below. Unfortunatley, I cannot upload the dump somewhere but if you ask me check whatever things I'll be happy to help. kgdb /usr/obj/src/src-9/sys/palveli/kernel.debug vmcore.4 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd"... Unread portion of the kernel message buffer: Fatal trap 12: page fault while in kernel mode fault virtual address = 0xcfb5e000 fault code = supervisor write, page not present instruction pointer = 0x20:0xc07cb2fe stack pointer = 0x28:0xd83545d0 frame pointer = 0x28:0xd835490c code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 12929 (mksnap_ffs) trap number = 12 panic: page fault KDB: stack backtrace: db_trace_self_wrapper(c08207eb,d835441c,c05fdfc9,c081df13,c08a82e0,...) at db_trace_self_wrapper+0x26/frame 0xd83543ec kdb_backtrace(c081df13,c08a82e0,c0801bfa,d8354428,d8354428,...) at kdb_backtrace+0x29/frame 0xd83543f8 panic(c0801bfa,c0845a01,c2bafae4,1,1,...) at panic+0xc9/frame 0xd835441c trap_fatal(c0ff6000,cfb5e000,2,0,265abf,...) at trap_fatal+0x353/frame 0xd835445c trap_pfault(140da,0,c2baf930,c08b6a40,c282145c,...) at trap_pfault+0x2d7/frame 0xd83544a4 trap(d8354590) at trap+0x41a/frame 0xd8354584 calltrap() at calltrap+0x6/frame 0xd8354584 --- trap 0xc, eip = 0xc07cb2fe, esp = 0xd83545d0, ebp = 0xd835490c --- bcopy(c2b36548,c2f194e0,0,0,0,...) at bcopy+0x1a/frame 0xd835490c ffs_mount(c2b36548,c2db9000,ff,d8354c08,c2b665e4,...) at ffs_mount+0x15ee/frame 0xd8354a3c vfs_donmount(c2baf930,10313108,0,c2b8ba80,c2b8ba80,...) at vfs_donmount+0x196b/frame 0xd8354c2c sys_nmount(c2baf930,d8354ccc,c2bafc18,d8354c6c,c0605015,...) at sys_nmount+0x63/frame 0xd8354c50 syscall(d8354d08) at syscall+0x2ce/frame 0xd8354cfc Xint0x80_syscall() at Xint0x80_syscall+0x21/frame 0xd8354cfc --- syscall (378, FreeBSD ELF32, sys_nmount), eip = 0x180bdf37, esp = 0xbfbfd65c, ebp = 0xbfbfddd8 --- Uptime: 2d21h49m21s Physical memory: 503 MB Dumping 108 MB: 93 77 61 45 29 13 No symbol "stopped_cpus" in current context. No symbol "stoppcbs" in current context. #0 doadump (textdump=1) at pcpu.h:249 249 pcpu.h: No such file or directory. in pcpu.h (kgdb) where #0 doadump (textdump=1) at pcpu.h:249 #1 0xc05fdddd in kern_reboot (howto=260) at /src/src-9/sys/kern/kern_shutdown.c:449 #2 0xc05fe028 in panic (fmt=) at /src/src-9/sys/kern/kern_shutdown.c:637 #3 0xc07cd1d3 in trap_fatal (frame=0xd8354590, eva=3484803072) at /src/src-9/sys/i386/i386/trap.c:1044 #4 0xc07cd4b7 in trap_pfault (frame=0xd8354590, usermode=0, eva=3484803072) at /src/src-9/sys/i386/i386/trap.c:957 #5 0xc07ce05a in trap (frame=0xd8354590) at /src/src-9/sys/i386/i386/trap.c:555 #6 0xc07ba88c in calltrap () at /src/src-9/sys/i386/i386/exception.s:170 #7 0xc07cb2fe in bcopy () at /src/src-9/sys/i386/i386/support.s:196 Previous frame inner to this frame (corrupt stack?) (kgdb) -Andre From owner-freebsd-stable@FreeBSD.ORG Thu Jul 4 05:24:49 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 1804E45C; Thu, 4 Jul 2013 05:24:49 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 4D4661E9B; Thu, 4 Jul 2013 05:24:48 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id r645Oeb9049135; Thu, 4 Jul 2013 08:24:40 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua r645Oeb9049135 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id r645OeeG049134; Thu, 4 Jul 2013 08:24:40 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 4 Jul 2013 08:24:40 +0300 From: Konstantin Belousov To: Andre Albsmeier Subject: Re: FreeBSD-9.1: machine reboots during snapshot creation, LORs found Message-ID: <20130704052440.GG91021@kib.kiev.ua> References: <20130531122611.GA6607@bali> <201305311051.03157.jhb@freebsd.org> <20130616063942.GA72803@bali> <201306171530.31208.jhb@freebsd.org> <20130704051409.GA22021@bali> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="vDF0KQD20bz5pO0G" Content-Disposition: inline In-Reply-To: <20130704051409.GA22021@bali> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: "freebsd-stable@freebsd.org" , John Baldwin 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, 04 Jul 2013 05:24:49 -0000 --vDF0KQD20bz5pO0G Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jul 04, 2013 at 07:14:09AM +0200, Andre Albsmeier wrote: > On Mon, 17-Jun-2013 at 21:30:31 +0200, John Baldwin wrote: > > On Sunday, June 16, 2013 2:39:42 am Andre Albsmeier wrote: > > > On Fri, 31-May-2013 at 16:51:03 +0200, John Baldwin wrote: > > > > On Friday, May 31, 2013 8:26:11 am Andre Albsmeier wrote: > > > > > Each day at 5:15 we are generating snapshots on various machines. > > > > > This used to work perfectly under 7-STABLE for years but since > > > > > we started to use 9.1-STABLE the machine reboots in about 10% > > > > > of all cases. > > > > >=20 > > > > > After rebooting we find a new snapshot file which is a bit > > > > > smaller than the good ones and with different permissions > > > > > It does not succeed a fsck. In this example it is the one > > > > > whose name is beginning with s3: > > > > >=20 > > > > > -r--r----- 1 root operator snapshot 72802894528 29 May 05:15 = s2-2013.05.28-03.15.04 > > > > > -r-------- 1 root operator snapshot 72802893824 29 May 05:15 = s3-2013.05.29-03.15.03 > > > > > -r--r----- 1 root operator snapshot 72802894528 28 May 14:22 = s4-2013.05.23-06.38.44 > > > > > -r--r----- 1 root operator snapshot 72802894528 28 May 14:22 = s5-2013.05.24-03.15.03 > > > > > -r--r----- 1 root operator snapshot 72802894528 28 May 14:22 = s6-2013.05.25-03.15.03 > > > > >=20 > > > > > After enabling DIAGNOSTIC, WITNESS and INVARIANTS in the kernel > > > > > I see the following LORs (mksnap_ffs starts exactly at 5:15): > > > > >=20 > > > > > May 29 05:15:00 palveli kernel: lock order reversal: > > > > > May 29 05:15:00 palveli kernel: 1st 0xc2371da8 ufs (u= fs) @ /src/src-9/sys/kern/vfs_mount.c:1240 > > > > > May 29 05:15:00 palveli kernel: 2nd 0xc2371ec4 devfs = (devfs) @ /src/src-9/sys/ufs/ffs/ffs_vfsops.c:1414 > > > > > May 29 05:15:04 palveli kernel: lock order reversal: > > > > > May 29 05:15:04 palveli kernel: 1st 0xc228471c snaplk= (snaplk) @ /src/src-9/sys/ufs/ufs/ufs_vnops.c:976 > > > > > May 29 05:15:04 palveli kernel: 2nd 0xc22f25e4 ufs (u= fs) @ /src/src-9/sys/ufs/ffs/ffs_snapshot.c:1626 > > > > >=20 > > > > > Unfortunatley no corefiles are being generated ;-(. > > > > >=20 > > > > > I have checked and even rebuilt the (UFS1) fs in question > > > > > from scratch. I have also seen this happen on an UFS2 on > > > > > another machine and on a third one when running "dump -L" > > > > > on a root fs. > > > > >=20 > > > > > Any hints of how to proceed? > > > >=20 > > > > Would it be possible to setup a serial console that is logged on th= is machine > > > > to see if it is panic'ing but failing to write out a crashdump? > > >=20 > > > Couldn't attach the serial console yet ;-(. But I had people > > > attach a KVMoverIP switch and enabled the various KDB options > > > in the kernel. Now we can see a bit more (see below) -- no > > > crashdump is being generated though. > >=20 > > :( Unfortunately these LORs don't really help with discerning the caus= e of > > the reboot. If you have remote power access (and still wanted to test = this) > > one option would be to change KDB to drop into the debugger on a panic. > > Then you could connect over the KVM and take images of the original pan= ic > > along with a stack trace. >=20 > After a few days of no problems, the box decided to crash > during mksnap_ffs today ;-(. But now I have a crashdump, > see below. Unfortunatley, I cannot upload the dump somewhere > but if you ask me check whatever things I'll be happy to help. >=20 > kgdb /usr/obj/src/src-9/sys/palveli/kernel.debug vmcore.4 > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you = are > welcome to change it and/or distribute copies of it under certain conditi= ons. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for detail= s. > This GDB was configured as "i386-marcel-freebsd"... >=20 > Unread portion of the kernel message buffer: >=20 >=20 > Fatal trap 12: page fault while in kernel mode > fault virtual address =3D 0xcfb5e000 > fault code =3D supervisor write, page not present > instruction pointer =3D 0x20:0xc07cb2fe > stack pointer =3D 0x28:0xd83545d0 > frame pointer =3D 0x28:0xd835490c > code segment =3D base 0x0, limit 0xfffff, type 0x1b > =3D DPL 0, pres 1, def32 1, gran 1 > processor eflags =3D interrupt enabled, resume, IOPL =3D 0 > current process =3D 12929 (mksnap_ffs) > trap number =3D 12 > panic: page fault > KDB: stack backtrace: > db_trace_self_wrapper(c08207eb,d835441c,c05fdfc9,c081df13,c08a82e0,...) a= t db_trace_self_wrapper+0x26/frame 0xd83543ec > kdb_backtrace(c081df13,c08a82e0,c0801bfa,d8354428,d8354428,...) at kdb_ba= cktrace+0x29/frame 0xd83543f8 > panic(c0801bfa,c0845a01,c2bafae4,1,1,...) at panic+0xc9/frame 0xd835441c > trap_fatal(c0ff6000,cfb5e000,2,0,265abf,...) at trap_fatal+0x353/frame 0x= d835445c > trap_pfault(140da,0,c2baf930,c08b6a40,c282145c,...) at trap_pfault+0x2d7/= frame 0xd83544a4 > trap(d8354590) at trap+0x41a/frame 0xd8354584 > calltrap() at calltrap+0x6/frame 0xd8354584 > --- trap 0xc, eip =3D 0xc07cb2fe, esp =3D 0xd83545d0, ebp =3D 0xd835490c = --- > bcopy(c2b36548,c2f194e0,0,0,0,...) at bcopy+0x1a/frame 0xd835490c > ffs_mount(c2b36548,c2db9000,ff,d8354c08,c2b665e4,...) at ffs_mount+0x15ee= /frame 0xd8354a3c =46rom the crash dump in kgdb, do list *ffs_mount+0x15ee > vfs_donmount(c2baf930,10313108,0,c2b8ba80,c2b8ba80,...) at vfs_donmount+0= x196b/frame 0xd8354c2c > sys_nmount(c2baf930,d8354ccc,c2bafc18,d8354c6c,c0605015,...) at sys_nmoun= t+0x63/frame 0xd8354c50 > syscall(d8354d08) at syscall+0x2ce/frame 0xd8354cfc > Xint0x80_syscall() at Xint0x80_syscall+0x21/frame 0xd8354cfc > --- syscall (378, FreeBSD ELF32, sys_nmount), eip =3D 0x180bdf37, esp =3D= 0xbfbfd65c, ebp =3D 0xbfbfddd8 --- > Uptime: 2d21h49m21s > Physical memory: 503 MB > Dumping 108 MB: 93 77 61 45 29 13 >=20 > No symbol "stopped_cpus" in current context. > No symbol "stoppcbs" in current context. > #0 doadump (textdump=3D1) at pcpu.h:249 > 249 pcpu.h: No such file or directory. > in pcpu.h > (kgdb) where > #0 doadump (textdump=3D1) at pcpu.h:249 > #1 0xc05fdddd in kern_reboot (howto=3D260) at /src/src-9/sys/kern/kern_s= hutdown.c:449 > #2 0xc05fe028 in panic (fmt=3D) at /src/src-9/sys/k= ern/kern_shutdown.c:637 > #3 0xc07cd1d3 in trap_fatal (frame=3D0xd8354590, eva=3D3484803072) > at /src/src-9/sys/i386/i386/trap.c:1044 > #4 0xc07cd4b7 in trap_pfault (frame=3D0xd8354590, usermode=3D0, eva=3D34= 84803072) > at /src/src-9/sys/i386/i386/trap.c:957 > #5 0xc07ce05a in trap (frame=3D0xd8354590) at /src/src-9/sys/i386/i386/t= rap.c:555 > #6 0xc07ba88c in calltrap () at /src/src-9/sys/i386/i386/exception.s:170 > #7 0xc07cb2fe in bcopy () at /src/src-9/sys/i386/i386/support.s:196 > Previous frame inner to this frame (corrupt stack?) > (kgdb)=20 >=20 > -Andre > _______________________________________________ > 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" --vDF0KQD20bz5pO0G Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iQIcBAEBAgAGBQJR1QcXAAoJEJDCuSvBvK1BzdoP+gPvfkqV1v+ae8dg+8WWgSWo L5nAKmrtRsj+teXXhmqS8pf5W536Uizs6rbA0WcPYBbBvcKcmd2o14aDt9NPgw/1 L8zi3ejMUthSsjcAxNI+/O8ZOpt3Ntw37t4RPuokKusqZBuca7D6xq+ZnKZyV0Y1 ge8NFOQ6YLCb4cOSrmxV/hgzpiOLfsG48YDov6WydUrfVYSagxNyF3sgWIKhvUda qz7ps/Y9YmLQv1Z0WvD4ybaywM/3SLP1vl3WWuOT0GKK7GdZqkS80yHEDudoFFEq N1LG34dNncXSE58wuBor003Pa2agReRJHHtqRZeRSaDi5sOs891weyEKgg7mUZhx DcnKXZ+Ovaxw0rxqw0U/u9wQnmzeSNz83QHax22mkjrh2KPivVEE1XuaBRs92VI8 U4TdFUK6yViZfZI0z0uCM+C1jIp3PHpQh1BnnUZMAQ6A3NABIsCl/AIiABQeGKYx gr3oOj7PXBXSWHbNJHGsOKTeXODKTBlVuEgO9wiPTVRW5iz9kMvG4YZq/xUenjtP z2jgdYU9CoALAT0gVUPp0dzMFVzWuO8GDSWZf33fBK6JK82G5+LraH5uahH9mbjF ItRKRZ6BuPfYOmokv5khR+ZposFwBBfbzNREiD44UpKfUp3/b1TCQG1PJboMZAft KvnTtCrqTJHSNVZ/nyqG =2DSj -----END PGP SIGNATURE----- --vDF0KQD20bz5pO0G-- From owner-freebsd-stable@FreeBSD.ORG Thu Jul 4 05:27:02 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 43FD256B; Thu, 4 Jul 2013 05:27:02 +0000 (UTC) (envelope-from Andre.Albsmeier@siemens.com) Received: from thoth.sbs.de (thoth.sbs.de [192.35.17.2]) by mx1.freebsd.org (Postfix) with ESMTP id C6C1B1EB9; Thu, 4 Jul 2013 05:27:01 +0000 (UTC) Received: from mail1.siemens.de (localhost [127.0.0.1]) by thoth.sbs.de (8.13.6/8.13.6) with ESMTP id r645R0Fs026963; Thu, 4 Jul 2013 07:27:00 +0200 Received: from curry.mchp.siemens.de (curry.mchp.siemens.de [139.25.40.130]) by mail1.siemens.de (8.13.6/8.13.6) with ESMTP id r645R0tO017978; Thu, 4 Jul 2013 07:27:00 +0200 Received: (from localhost) by curry.mchp.siemens.de (8.14.7/8.14.7) id r645R0RQ014604; Date: Thu, 4 Jul 2013 07:27:00 +0200 From: Andre Albsmeier To: Konstantin Belousov Subject: Re: FreeBSD-9.1: machine reboots during snapshot creation, LORs found Message-ID: <20130704052659.GA23398@bali> References: <20130531122611.GA6607@bali> <201305311051.03157.jhb@freebsd.org> <20130616063942.GA72803@bali> <201306171530.31208.jhb@freebsd.org> <20130704051409.GA22021@bali> <20130704052440.GG91021@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130704052440.GG91021@kib.kiev.ua> X-Echelon: X-Advice: Drop that crappy M$-Outlook, I'm tired of your viruses! User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "freebsd-stable@freebsd.org" , John Baldwin 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, 04 Jul 2013 05:27:02 -0000 On Thu, 04-Jul-2013 at 07:24:40 +0200, Konstantin Belousov wrote: > On Thu, Jul 04, 2013 at 07:14:09AM +0200, Andre Albsmeier wrote: > > On Mon, 17-Jun-2013 at 21:30:31 +0200, John Baldwin wrote: > > > On Sunday, June 16, 2013 2:39:42 am Andre Albsmeier wrote: > > > > On Fri, 31-May-2013 at 16:51:03 +0200, John Baldwin wrote: > > > > > On Friday, May 31, 2013 8:26:11 am Andre Albsmeier wrote: > > > > > > Each day at 5:15 we are generating snapshots on various machines. > > > > > > This used to work perfectly under 7-STABLE for years but since > > > > > > we started to use 9.1-STABLE the machine reboots in about 10% > > > > > > of all cases. > > > > > > > > > > > > After rebooting we find a new snapshot file which is a bit > > > > > > smaller than the good ones and with different permissions > > > > > > It does not succeed a fsck. In this example it is the one > > > > > > whose name is beginning with s3: > > > > > > > > > > > > -r--r----- 1 root operator snapshot 72802894528 29 May 05:15 s2-2013.05.28-03.15.04 > > > > > > -r-------- 1 root operator snapshot 72802893824 29 May 05:15 s3-2013.05.29-03.15.03 > > > > > > -r--r----- 1 root operator snapshot 72802894528 28 May 14:22 s4-2013.05.23-06.38.44 > > > > > > -r--r----- 1 root operator snapshot 72802894528 28 May 14:22 s5-2013.05.24-03.15.03 > > > > > > -r--r----- 1 root operator snapshot 72802894528 28 May 14:22 s6-2013.05.25-03.15.03 > > > > > > > > > > > > After enabling DIAGNOSTIC, WITNESS and INVARIANTS in the kernel > > > > > > I see the following LORs (mksnap_ffs starts exactly at 5:15): > > > > > > > > > > > > May 29 05:15:00 palveli kernel: lock order reversal: > > > > > > May 29 05:15:00 palveli kernel: 1st 0xc2371da8 ufs (ufs) @ /src/src-9/sys/kern/vfs_mount.c:1240 > > > > > > May 29 05:15:00 palveli kernel: 2nd 0xc2371ec4 devfs (devfs) @ /src/src-9/sys/ufs/ffs/ffs_vfsops.c:1414 > > > > > > May 29 05:15:04 palveli kernel: lock order reversal: > > > > > > May 29 05:15:04 palveli kernel: 1st 0xc228471c snaplk (snaplk) @ /src/src-9/sys/ufs/ufs/ufs_vnops.c:976 > > > > > > May 29 05:15:04 palveli kernel: 2nd 0xc22f25e4 ufs (ufs) @ /src/src-9/sys/ufs/ffs/ffs_snapshot.c:1626 > > > > > > > > > > > > Unfortunatley no corefiles are being generated ;-(. > > > > > > > > > > > > I have checked and even rebuilt the (UFS1) fs in question > > > > > > from scratch. I have also seen this happen on an UFS2 on > > > > > > another machine and on a third one when running "dump -L" > > > > > > on a root fs. > > > > > > > > > > > > Any hints of how to proceed? > > > > > > > > > > Would it be possible to setup a serial console that is logged on this machine > > > > > to see if it is panic'ing but failing to write out a crashdump? > > > > > > > > Couldn't attach the serial console yet ;-(. But I had people > > > > attach a KVMoverIP switch and enabled the various KDB options > > > > in the kernel. Now we can see a bit more (see below) -- no > > > > crashdump is being generated though. > > > > > > :( Unfortunately these LORs don't really help with discerning the cause of > > > the reboot. If you have remote power access (and still wanted to test this) > > > one option would be to change KDB to drop into the debugger on a panic. > > > Then you could connect over the KVM and take images of the original panic > > > along with a stack trace. > > > > After a few days of no problems, the box decided to crash > > during mksnap_ffs today ;-(. But now I have a crashdump, > > see below. Unfortunatley, I cannot upload the dump somewhere > > but if you ask me check whatever things I'll be happy to help. > > > > kgdb /usr/obj/src/src-9/sys/palveli/kernel.debug vmcore.4 > > GNU gdb 6.1.1 [FreeBSD] > > Copyright 2004 Free Software Foundation, Inc. > > GDB is free software, covered by the GNU General Public License, and you are > > welcome to change it and/or distribute copies of it under certain conditions. > > Type "show copying" to see the conditions. > > There is absolutely no warranty for GDB. Type "show warranty" for details. > > This GDB was configured as "i386-marcel-freebsd"... > > > > Unread portion of the kernel message buffer: > > > > > > Fatal trap 12: page fault while in kernel mode > > fault virtual address = 0xcfb5e000 > > fault code = supervisor write, page not present > > instruction pointer = 0x20:0xc07cb2fe > > stack pointer = 0x28:0xd83545d0 > > frame pointer = 0x28:0xd835490c > > code segment = base 0x0, limit 0xfffff, type 0x1b > > = DPL 0, pres 1, def32 1, gran 1 > > processor eflags = interrupt enabled, resume, IOPL = 0 > > current process = 12929 (mksnap_ffs) > > trap number = 12 > > panic: page fault > > KDB: stack backtrace: > > db_trace_self_wrapper(c08207eb,d835441c,c05fdfc9,c081df13,c08a82e0,...) at db_trace_self_wrapper+0x26/frame 0xd83543ec > > kdb_backtrace(c081df13,c08a82e0,c0801bfa,d8354428,d8354428,...) at kdb_backtrace+0x29/frame 0xd83543f8 > > panic(c0801bfa,c0845a01,c2bafae4,1,1,...) at panic+0xc9/frame 0xd835441c > > trap_fatal(c0ff6000,cfb5e000,2,0,265abf,...) at trap_fatal+0x353/frame 0xd835445c > > trap_pfault(140da,0,c2baf930,c08b6a40,c282145c,...) at trap_pfault+0x2d7/frame 0xd83544a4 > > trap(d8354590) at trap+0x41a/frame 0xd8354584 > > calltrap() at calltrap+0x6/frame 0xd8354584 > > --- trap 0xc, eip = 0xc07cb2fe, esp = 0xd83545d0, ebp = 0xd835490c --- > > bcopy(c2b36548,c2f194e0,0,0,0,...) at bcopy+0x1a/frame 0xd835490c > > ffs_mount(c2b36548,c2db9000,ff,d8354c08,c2b665e4,...) at ffs_mount+0x15ee/frame 0xd8354a3c > > From the crash dump in kgdb, do > list *ffs_mount+0x15ee (kgdb) list *ffs_mount+0x15ee 0xc0748e8e is in ffs_mount (/src/src-9/sys/ufs/ffs/ffs_vfsops.c:483). 478 479 /* 480 * If this is a snapshot request, take the snapshot. 481 */ 482 if (mp->mnt_flag & MNT_SNAPSHOT) 483 return (ffs_snapshot(mp, fspec)); 484 } 485 486 /* 487 * Not an update, or updating the name: look up the name -Andre > > > vfs_donmount(c2baf930,10313108,0,c2b8ba80,c2b8ba80,...) at vfs_donmount+0x196b/frame 0xd8354c2c > > sys_nmount(c2baf930,d8354ccc,c2bafc18,d8354c6c,c0605015,...) at sys_nmount+0x63/frame 0xd8354c50 > > syscall(d8354d08) at syscall+0x2ce/frame 0xd8354cfc > > Xint0x80_syscall() at Xint0x80_syscall+0x21/frame 0xd8354cfc > > --- syscall (378, FreeBSD ELF32, sys_nmount), eip = 0x180bdf37, esp = 0xbfbfd65c, ebp = 0xbfbfddd8 --- > > Uptime: 2d21h49m21s > > Physical memory: 503 MB > > Dumping 108 MB: 93 77 61 45 29 13 > > > > No symbol "stopped_cpus" in current context. > > No symbol "stoppcbs" in current context. > > #0 doadump (textdump=1) at pcpu.h:249 > > 249 pcpu.h: No such file or directory. > > in pcpu.h > > (kgdb) where > > #0 doadump (textdump=1) at pcpu.h:249 > > #1 0xc05fdddd in kern_reboot (howto=260) at /src/src-9/sys/kern/kern_shutdown.c:449 > > #2 0xc05fe028 in panic (fmt=) at /src/src-9/sys/kern/kern_shutdown.c:637 > > #3 0xc07cd1d3 in trap_fatal (frame=0xd8354590, eva=3484803072) > > at /src/src-9/sys/i386/i386/trap.c:1044 > > #4 0xc07cd4b7 in trap_pfault (frame=0xd8354590, usermode=0, eva=3484803072) > > at /src/src-9/sys/i386/i386/trap.c:957 > > #5 0xc07ce05a in trap (frame=0xd8354590) at /src/src-9/sys/i386/i386/trap.c:555 > > #6 0xc07ba88c in calltrap () at /src/src-9/sys/i386/i386/exception.s:170 > > #7 0xc07cb2fe in bcopy () at /src/src-9/sys/i386/i386/support.s:196 > > Previous frame inner to this frame (corrupt stack?) > > (kgdb) > > > > -Andre > > _______________________________________________ > > 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" -- Linux is no OS. It's a core dump which boots by accident. From owner-freebsd-stable@FreeBSD.ORG Thu Jul 4 06:16:00 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 59BEE239; Thu, 4 Jul 2013 06:16:00 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id A74B2105B; Thu, 4 Jul 2013 06:15:59 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id r646Foot060469; Thu, 4 Jul 2013 09:15:50 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua r646Foot060469 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id r646FoQv060467; Thu, 4 Jul 2013 09:15:50 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 4 Jul 2013 09:15:50 +0300 From: Konstantin Belousov To: Andre Albsmeier Subject: Re: FreeBSD-9.1: machine reboots during snapshot creation, LORs found Message-ID: <20130704061550.GI91021@kib.kiev.ua> References: <20130531122611.GA6607@bali> <201305311051.03157.jhb@freebsd.org> <20130616063942.GA72803@bali> <201306171530.31208.jhb@freebsd.org> <20130704051409.GA22021@bali> <20130704052440.GG91021@kib.kiev.ua> <20130704052659.GA23398@bali> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Q1ykKx60OEcPG/sP" Content-Disposition: inline In-Reply-To: <20130704052659.GA23398@bali> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: "freebsd-stable@freebsd.org" , John Baldwin 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, 04 Jul 2013 06:16:00 -0000 --Q1ykKx60OEcPG/sP Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jul 04, 2013 at 07:27:00AM +0200, Andre Albsmeier wrote: > On Thu, 04-Jul-2013 at 07:24:40 +0200, Konstantin Belousov wrote: > > On Thu, Jul 04, 2013 at 07:14:09AM +0200, Andre Albsmeier wrote: > > > On Mon, 17-Jun-2013 at 21:30:31 +0200, John Baldwin wrote: > > > > On Sunday, June 16, 2013 2:39:42 am Andre Albsmeier wrote: > > > > > On Fri, 31-May-2013 at 16:51:03 +0200, John Baldwin wrote: > > > > > > On Friday, May 31, 2013 8:26:11 am Andre Albsmeier wrote: > > > > > > > Each day at 5:15 we are generating snapshots on various machi= nes. > > > > > > > This used to work perfectly under 7-STABLE for years but since > > > > > > > we started to use 9.1-STABLE the machine reboots in about 10% > > > > > > > of all cases. > > > > > > >=20 > > > > > > > After rebooting we find a new snapshot file which is a bit > > > > > > > smaller than the good ones and with different permissions > > > > > > > It does not succeed a fsck. In this example it is the one > > > > > > > whose name is beginning with s3: > > > > > > >=20 > > > > > > > -r--r----- 1 root operator snapshot 72802894528 29 May 05= :15 s2-2013.05.28-03.15.04 > > > > > > > -r-------- 1 root operator snapshot 72802893824 29 May 05= :15 s3-2013.05.29-03.15.03 > > > > > > > -r--r----- 1 root operator snapshot 72802894528 28 May 14= :22 s4-2013.05.23-06.38.44 > > > > > > > -r--r----- 1 root operator snapshot 72802894528 28 May 14= :22 s5-2013.05.24-03.15.03 > > > > > > > -r--r----- 1 root operator snapshot 72802894528 28 May 14= :22 s6-2013.05.25-03.15.03 > > > > > > >=20 > > > > > > > After enabling DIAGNOSTIC, WITNESS and INVARIANTS in the kern= el > > > > > > > I see the following LORs (mksnap_ffs starts exactly at 5:15): > > > > > > >=20 > > > > > > > May 29 05:15:00 palveli kernel: lock order revers= al: > > > > > > > May 29 05:15:00 palveli kernel: 1st 0xc2371da8 uf= s (ufs) @ /src/src-9/sys/kern/vfs_mount.c:1240 > > > > > > > May 29 05:15:00 palveli kernel: 2nd 0xc2371ec4 de= vfs (devfs) @ /src/src-9/sys/ufs/ffs/ffs_vfsops.c:1414 > > > > > > > May 29 05:15:04 palveli kernel: lock order revers= al: > > > > > > > May 29 05:15:04 palveli kernel: 1st 0xc228471c sn= aplk (snaplk) @ /src/src-9/sys/ufs/ufs/ufs_vnops.c:976 > > > > > > > May 29 05:15:04 palveli kernel: 2nd 0xc22f25e4 uf= s (ufs) @ /src/src-9/sys/ufs/ffs/ffs_snapshot.c:1626 > > > > > > >=20 > > > > > > > Unfortunatley no corefiles are being generated ;-(. > > > > > > >=20 > > > > > > > I have checked and even rebuilt the (UFS1) fs in question > > > > > > > from scratch. I have also seen this happen on an UFS2 on > > > > > > > another machine and on a third one when running "dump -L" > > > > > > > on a root fs. > > > > > > >=20 > > > > > > > Any hints of how to proceed? > > > > > >=20 > > > > > > Would it be possible to setup a serial console that is logged o= n this machine > > > > > > to see if it is panic'ing but failing to write out a crashdump? > > > > >=20 > > > > > Couldn't attach the serial console yet ;-(. But I had people > > > > > attach a KVMoverIP switch and enabled the various KDB options > > > > > in the kernel. Now we can see a bit more (see below) -- no > > > > > crashdump is being generated though. > > > >=20 > > > > :( Unfortunately these LORs don't really help with discerning the = cause of > > > > the reboot. If you have remote power access (and still wanted to t= est this) > > > > one option would be to change KDB to drop into the debugger on a pa= nic. > > > > Then you could connect over the KVM and take images of the original= panic > > > > along with a stack trace. > > >=20 > > > After a few days of no problems, the box decided to crash > > > during mksnap_ffs today ;-(. But now I have a crashdump, > > > see below. Unfortunatley, I cannot upload the dump somewhere > > > but if you ask me check whatever things I'll be happy to help. > > >=20 > > > kgdb /usr/obj/src/src-9/sys/palveli/kernel.debug vmcore.4 > > > GNU gdb 6.1.1 [FreeBSD] > > > Copyright 2004 Free Software Foundation, Inc. > > > GDB is free software, covered by the GNU General Public License, and = you are > > > welcome to change it and/or distribute copies of it under certain con= ditions. > > > Type "show copying" to see the conditions. > > > There is absolutely no warranty for GDB. Type "show warranty" for de= tails. > > > This GDB was configured as "i386-marcel-freebsd"... > > >=20 > > > Unread portion of the kernel message buffer: > > >=20 > > >=20 > > > Fatal trap 12: page fault while in kernel mode > > > fault virtual address =3D 0xcfb5e000 > > > fault code =3D supervisor write, page not present > > > instruction pointer =3D 0x20:0xc07cb2fe > > > stack pointer =3D 0x28:0xd83545d0 > > > frame pointer =3D 0x28:0xd835490c > > > code segment =3D base 0x0, limit 0xfffff, type 0x1b > > > =3D DPL 0, pres 1, def32 1, gran 1 > > > processor eflags =3D interrupt enabled, resume, IOPL =3D 0 > > > current process =3D 12929 (mksnap_ffs) > > > trap number =3D 12 > > > panic: page fault > > > KDB: stack backtrace: > > > db_trace_self_wrapper(c08207eb,d835441c,c05fdfc9,c081df13,c08a82e0,..= =2E) at db_trace_self_wrapper+0x26/frame 0xd83543ec > > > kdb_backtrace(c081df13,c08a82e0,c0801bfa,d8354428,d8354428,...) at kd= b_backtrace+0x29/frame 0xd83543f8 > > > panic(c0801bfa,c0845a01,c2bafae4,1,1,...) at panic+0xc9/frame 0xd8354= 41c > > > trap_fatal(c0ff6000,cfb5e000,2,0,265abf,...) at trap_fatal+0x353/fram= e 0xd835445c > > > trap_pfault(140da,0,c2baf930,c08b6a40,c282145c,...) at trap_pfault+0x= 2d7/frame 0xd83544a4 > > > trap(d8354590) at trap+0x41a/frame 0xd8354584 > > > calltrap() at calltrap+0x6/frame 0xd8354584 > > > --- trap 0xc, eip =3D 0xc07cb2fe, esp =3D 0xd83545d0, ebp =3D 0xd8354= 90c --- > > > bcopy(c2b36548,c2f194e0,0,0,0,...) at bcopy+0x1a/frame 0xd835490c > > > ffs_mount(c2b36548,c2db9000,ff,d8354c08,c2b665e4,...) at ffs_mount+0x= 15ee/frame 0xd8354a3c > >=20 > > From the crash dump in kgdb, do > > list *ffs_mount+0x15ee >=20 > (kgdb) list *ffs_mount+0x15ee > 0xc0748e8e is in ffs_mount (/src/src-9/sys/ufs/ffs/ffs_vfsops.c:483). > 478 > 479 /* > 480 * If this is a snapshot request, take the snapsh= ot. > 481 */ > 482 if (mp->mnt_flag & MNT_SNAPSHOT) > 483 return (ffs_snapshot(mp, fspec)); > 484 } > 485 > 486 /* > 487 * Not an update, or updating the name: look up the name It is not useful, bcopy does not create a frame, so the real caller of the failing bcopy gets lost. It could be uncovered with some stack digging, but I believe it would be easier just fix bcopy. Please apply this patch and reproduce the panic again, then the kgdb backtrace should be more useful. diff --git a/sys/i386/i386/support.s b/sys/i386/i386/support.s index 967a09e..779fa38 100644 --- a/sys/i386/i386/support.s +++ b/sys/i386/i386/support.s @@ -181,11 +181,13 @@ END(bcopyb) * ws@tools.de (Wolfgang Solfrank, TooLs GmbH) +49-228-985800 */ ENTRY(bcopy) + pushl %ebp + movl %esp,%ebp pushl %esi pushl %edi - movl 12(%esp),%esi - movl 16(%esp),%edi - movl 20(%esp),%ecx + movl 8(%ebp),%esi + movl 12(%ebp),%edi + movl 16(%ebp),%ecx =20 movl %edi,%eax subl %esi,%eax @@ -196,12 +198,13 @@ ENTRY(bcopy) cld /* nope, copy forwards */ rep movsl - movl 20(%esp),%ecx + movl 16(%ebp),%ecx andl $3,%ecx /* any bytes left? */ rep movsb popl %edi popl %esi + popl %ebp ret =20 ALIGN_TEXT @@ -214,7 +217,7 @@ ENTRY(bcopy) std rep movsb - movl 20(%esp),%ecx /* copy remainder by 32-bit words */ + movl 16(%ebp),%ecx /* copy remainder by 32-bit words */ shrl $2,%ecx subl $3,%esi subl $3,%edi @@ -223,6 +226,7 @@ ENTRY(bcopy) popl %edi popl %esi cld + popl %ebp ret END(bcopy) =20 --Q1ykKx60OEcPG/sP Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iQIcBAEBAgAGBQJR1RMVAAoJEJDCuSvBvK1B8AoQAJFjo/vCKR561LcJcSqI9UFf nwsWeOPOa6uXNoTQrV4S+vC2PDiT4MRLbSOIrT+gEVpnSg8W62Z1lSQBb+/VsrSS OYAhbPjsrtmMSS1Lk2A/3Crq9E05Oiq9hl9EVgvtlMKZRabckHAc/3pKmrzsnxUg Ft56OCEQiK0pI1czbglb3PGMP0vrHXi1OimQ+P5LKZCnmykuHEdKw3vdfZ2Fz9BO Vwbs8P4CJRMV5OKu/hlA5teZ1JrI/7XihGSYxlQ6csoa8I5NtWHf38h8Di7FbtwI vh8NEVnHzNc6W+mBFJjMl8Wi0oFsH1iJQxVas0tHQuguIA8EKi/6CxAhViFL44Qe 04jNXZJDf5uJLeUmor2Vce7ytNp7uY2ZhtgEgCTHZeyuayJ09tzXIj+GYeRx1O9Z KcEfxhPDSQI3IFAU+Ep9ibqgBVjLBiLhjesPbrg58W2/OIakvoSJcAWNUwfYHh9u 3sdhSfnrjfGULXvKK9VuWQX1dqGyPf7VVGZ+4lBjBwWbp3ziGAHqbpmGzLqXU54/ 4pMHIT2vdK1/40pbqHW2S8k3lg8qmB4PnqGN5UtrMEwqu82hXflpEuVEbr2YWgXp H+SjJUXm6ZZkhz6dRcSXrsppeXpsnxzipyX5tOZk+EuacVPiQ2xqlGSD5wmXU6Jo lOUP7CCWcrjgWSnr4Pgp =O1v/ -----END PGP SIGNATURE----- --Q1ykKx60OEcPG/sP-- From owner-freebsd-stable@FreeBSD.ORG Thu Jul 4 08:00:42 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 07810899; Thu, 4 Jul 2013 08:00:42 +0000 (UTC) (envelope-from bsd-lists@1command.com) Received: from udns.ultimateDNS.NET (ultimatedns.net [209.180.214.225]) by mx1.freebsd.org (Postfix) with ESMTP id CF4941561; Thu, 4 Jul 2013 08:00:41 +0000 (UTC) Received: from udns.ultimateDNS.NET (localhost [127.0.0.1]) by udns.ultimateDNS.NET (8.14.5/8.14.5) with ESMTP id r6480U23067433; Thu, 4 Jul 2013 01:00:36 -0700 (PDT) (envelope-from bsd-lists@1command.com) Received: (from www@localhost) by udns.ultimateDNS.NET (8.14.5/8.14.5/Submit) id r6480PHp067432; Thu, 4 Jul 2013 01:00:25 -0700 (PDT) (envelope-from bsd-lists@1command.com) Received: from udns.ultimatedns.net ([209.180.214.225]) (UDNSMS authenticated user chrish) by ultimatedns.net with HTTP; Thu, 4 Jul 2013 01:00:25 -0700 (PDT) Message-ID: Date: Thu, 4 Jul 2013 01:00:25 -0700 (PDT) Subject: Where's the docs for FreeBSD maintenance with Subversion? From: "Chris H" To: "freebsd-stable" , "svn-src-stable-8" User-Agent: UDNSMS/2.0.3 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal 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, 04 Jul 2013 08:00:42 -0000 Greetings, I've _finally_ managed to get a break in my work schedule that coincides with a period where pointyhat isn't barfing on my ARCH. So I was able to (cv)sup src && ports. Update the kernel successfully, and (after hours of work), managed to upgrade ports. But as (cv)sup was discontinued ~3 months ago, the ports aren't well synced, and I'm now working on a fairly wobbly system. I'm on RELENG_8 (8.4), and would like to sync my src && ports via the (now defacto) subversion method. My previous experience is with the client meerly for the sake of obtaining the src, and building -- _not_ maintaining a tree. I've read what little is available in the handbook, and much of the Subversion book. But there are clearly different procedures/nuances where FreeBSD maintenance is concerned, both in the building of Subversion, and it's usage, where FreeBSD is concerned. The biggest questions in this regard, is; 1) what to do with my current INDEX-8 && INDEX-8.db files? 2) what of the "distfiles" directory Do I simply copy them over, and "check them in"? Surely I'm not the only one that still has questions in this regard. Thank you for all your time, and consideration. --chris From owner-freebsd-stable@FreeBSD.ORG Thu Jul 4 09:21:38 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id CB6F040D for ; Thu, 4 Jul 2013 09:21:38 +0000 (UTC) (envelope-from njm@njm.me.uk) Received: from smtp004.apm-internet.net (smtp004.apm-internet.net [85.119.248.54]) by mx1.freebsd.org (Postfix) with ESMTP id 4A01219D9 for ; Thu, 4 Jul 2013 09:21:37 +0000 (UTC) Received: (qmail 46199 invoked from network); 4 Jul 2013 09:14:55 -0000 Received: from unknown (HELO meld.njm.me.uk) (109.148.231.82) by smtp004.apm-internet.net with SMTP; 4 Jul 2013 09:14:55 -0000 Received: from titania.njm.me.uk (titania.njm.me.uk [192.168.144.130]) by meld.njm.me.uk (8.14.7/8.14.7) with ESMTP id r649EtRL017804; Thu, 4 Jul 2013 10:14:55 +0100 (BST) (envelope-from njm@njm.me.uk) Received: from titania.njm.me.uk (localhost [127.0.0.1]) by titania.njm.me.uk (8.14.7/8.14.7) with ESMTP id r649Et8a061298; Thu, 4 Jul 2013 10:14:55 +0100 (BST) (envelope-from njm@njm.me.uk) Received: (from njm@localhost) by titania.njm.me.uk (8.14.7/8.14.7/Submit) id r649Esai061297; Thu, 4 Jul 2013 10:14:54 +0100 (BST) (envelope-from njm@njm.me.uk) Date: Thu, 4 Jul 2013 10:14:54 +0100 From: "N.J. Mann" To: Chris H Subject: Re: Where's the docs for FreeBSD maintenance with Subversion? Message-ID: <20130704091454.GA61237@titania.njm.me.uk> Mail-Followup-To: Chris H , freebsd-stable , svn-src-stable-8 References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD 8.4-STABLE User-Agent: mutt-NJM (2010-10-31) Cc: svn-src-stable-8 , 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, 04 Jul 2013 09:21:38 -0000 In message , Chris H (bsd-lists@1command.com) wrote: > Greetings, > I've _finally_ managed to get a break in my work schedule that coincides with > a period where pointyhat isn't barfing on my ARCH. So I was able to (cv)sup src && ports. > Update the kernel successfully, and (after hours of work), managed to upgrade ports. But > as (cv)sup was discontinued ~3 months ago, the ports aren't well synced, and I'm now > working on a fairly wobbly system. I'm on RELENG_8 (8.4), and would like to sync my src && > ports via the (now defacto) subversion method. My previous experience is with the client > meerly for the sake of obtaining the src, and building -- _not_ maintaining a tree. I've > read what little is available in the handbook, and much of the Subversion book. But there are > clearly different procedures/nuances where FreeBSD maintenance is concerned, both in the > building of Subversion, and it's usage, where FreeBSD is concerned. The biggest questions > in this regard, is; > 1) what to do with my current INDEX-8 && INDEX-8.db files? > 2) what of the "distfiles" directory > Do I simply copy them over, and "check them in"? When I converted from csup to svn I did the following - which seems to work. :-) 1. mv /usr/ports /usr/ports.old 2. mkdir /usr/ports 3. svn checkout into /usr/ports 4. mv /usr/ports.old/distfiles /usr/ports When I do a svn update it ignores distfiles. I hope this terse reply helps. Cheers, Nick. -- From owner-freebsd-stable@FreeBSD.ORG Thu Jul 4 09:26:52 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id CAB49561; Thu, 4 Jul 2013 09:26:52 +0000 (UTC) (envelope-from bsd-lists@1command.com) Received: from udns.ultimateDNS.NET (ultimatedns.net [209.180.214.225]) by mx1.freebsd.org (Postfix) with ESMTP id 7F3721A14; Thu, 4 Jul 2013 09:26:52 +0000 (UTC) Received: from udns.ultimateDNS.NET (localhost [127.0.0.1]) by udns.ultimateDNS.NET (8.14.5/8.14.5) with ESMTP id r649QjSV072435; Thu, 4 Jul 2013 02:26:51 -0700 (PDT) (envelope-from bsd-lists@1command.com) Received: (from www@localhost) by udns.ultimateDNS.NET (8.14.5/8.14.5/Submit) id r649QeY8072432; Thu, 4 Jul 2013 02:26:40 -0700 (PDT) (envelope-from bsd-lists@1command.com) Received: from udns.ultimatedns.net ([209.180.214.225]) (UDNSMS authenticated user chrish) by ultimatedns.net with HTTP; Thu, 4 Jul 2013 02:26:40 -0700 (PDT) Message-ID: <953a43cc7f49927cdfdfc7f1b697bb19.authenticated@ultimatedns.net> In-Reply-To: <20130704091454.GA61237@titania.njm.me.uk> References: <20130704091454.GA61237@titania.njm.me.uk> Date: Thu, 4 Jul 2013 02:26:40 -0700 (PDT) Subject: Re: Where's the docs for FreeBSD maintenance with Subversion? From: "Chris H" To: "freebsd-stable" , "svn-src-stable-8" User-Agent: UDNSMS/2.0.3 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal 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, 04 Jul 2013 09:26:52 -0000 > In message , > Chris H (bsd-lists@1command.com) wrote: >> Greetings, >> I've _finally_ managed to get a break in my work schedule that coincides with >> a period where pointyhat isn't barfing on my ARCH. So I was able to (cv)sup src && ports. >> Update the kernel successfully, and (after hours of work), managed to upgrade ports. But >> as (cv)sup was discontinued ~3 months ago, the ports aren't well synced, and I'm now >> working on a fairly wobbly system. I'm on RELENG_8 (8.4), and would like to sync my src && >> ports via the (now defacto) subversion method. My previous experience is with the client >> meerly for the sake of obtaining the src, and building -- _not_ maintaining a tree. I've >> read what little is available in the handbook, and much of the Subversion book. But there >> are >> clearly different procedures/nuances where FreeBSD maintenance is concerned, both in the >> building of Subversion, and it's usage, where FreeBSD is concerned. The biggest questions >> in this regard, is; >> 1) what to do with my current INDEX-8 && INDEX-8.db files? >> 2) what of the "distfiles" directory >> Do I simply copy them over, and "check them in"? > > When I converted from csup to svn I did the following - which seems to > work. :-) > > 1. mv /usr/ports /usr/ports.old > 2. mkdir /usr/ports > 3. svn checkout into /usr/ports > 4. mv /usr/ports.old/distfiles /usr/ports > > When I do a svn update it ignores distfiles. > > I hope this terse reply helps. Perfect! Thanks. --chris > > > Cheers, > Nick. > -- > > > _______________________________________________ > svn-src-stable-8@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/svn-src-stable-8 > To unsubscribe, send any mail to "svn-src-stable-8-unsubscribe@freebsd.org" > From owner-freebsd-stable@FreeBSD.ORG Thu Jul 4 12:46:00 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 379CA59B for ; Thu, 4 Jul 2013 12:46:00 +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 E242212D0 for ; Thu, 4 Jul 2013 12:45:59 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.7/8.14.7) with ESMTP id r64Cjkla004375; Thu, 4 Jul 2013 06:45:46 -0600 (MDT) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.7/8.14.7/Submit) with ESMTP id r64Cjkdp004372; Thu, 4 Jul 2013 06:45:46 -0600 (MDT) (envelope-from wblock@wonkity.com) Date: Thu, 4 Jul 2013 06:45:46 -0600 (MDT) From: Warren Block To: "N.J. Mann" Subject: Re: Where's the docs for FreeBSD maintenance with Subversion? In-Reply-To: <20130704091454.GA61237@titania.njm.me.uk> Message-ID: References: <20130704091454.GA61237@titania.njm.me.uk> 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.4.3 (wonkity.com [127.0.0.1]); Thu, 04 Jul 2013 06:45:46 -0600 (MDT) Cc: Chris H , 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, 04 Jul 2013 12:46:00 -0000 On Thu, 4 Jul 2013, N.J. Mann wrote: > In message , > Chris H (bsd-lists@1command.com) wrote: >> Greetings, >> I've _finally_ managed to get a break in my work schedule that coincides with >> a period where pointyhat isn't barfing on my ARCH. So I was able to (cv)sup src && ports. >> Update the kernel successfully, and (after hours of work), managed to upgrade ports. But >> as (cv)sup was discontinued ~3 months ago, the ports aren't well synced, and I'm now >> working on a fairly wobbly system. I'm on RELENG_8 (8.4), and would like to sync my src && >> ports via the (now defacto) subversion method. My previous experience is with the client >> meerly for the sake of obtaining the src, and building -- _not_ maintaining a tree. I've >> read what little is available in the handbook, and much of the Subversion book. But there are >> clearly different procedures/nuances where FreeBSD maintenance is concerned, both in the >> building of Subversion, and it's usage, where FreeBSD is concerned. The biggest questions >> in this regard, is; >> 1) what to do with my current INDEX-8 && INDEX-8.db files? >> 2) what of the "distfiles" directory >> Do I simply copy them over, and "check them in"? > > When I converted from csup to svn I did the following - which seems to > work. :-) > > 1. mv /usr/ports /usr/ports.old > 2. mkdir /usr/ports > 3. svn checkout into /usr/ports > 4. mv /usr/ports.old/distfiles /usr/ports > > When I do a svn update it ignores distfiles. The index files, too. They can be (slowly) built with 'make index', or downloaded with 'make fetchindex', or portmaster will fetch it automatically. From owner-freebsd-stable@FreeBSD.ORG Thu Jul 4 13:09:06 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 81407E68 for ; Thu, 4 Jul 2013 13:09:06 +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 467AD1482 for ; Thu, 4 Jul 2013 13:09:06 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7::199c:6fe6:9d79:6781] (unknown [IPv6:2001:7b8:3a7:0:199c:6fe6:9d79:6781]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id C03A75C43; Thu, 4 Jul 2013 15:08:57 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: Phantom nulls in usbdevs.h during 9-STABLE kernel build From: Dimitry Andric In-Reply-To: Date: Thu, 4 Jul 2013 15:08:57 +0200 Content-Transfer-Encoding: 7bit Message-Id: <2D61560D-E3D9-4558-8715-8215DBBF21D9@FreeBSD.org> References: To: J David X-Mailer: Apple Mail (2.1508) 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, 04 Jul 2013 13:09:06 -0000 On Jul 4, 2013, at 04:43, J David wrote: > We are seeing strange problems building the kernel on 9-STABLE. The > problem is intermittent and will go away if we build enough times in a row > without making any changes. > > > The problem seems to be that the usbdevs.h file (which appears to be > automatically generated) gets random NULL bytes in it. ... > On the second failure posted below I took a hex dump of the usbdevs.h file. > I don't see any NULLs at the target location, which is an empty line. > (Just 0a 0a for the empty line.) In fact there are no nulls anywhere in > the file. So the actual file does *not* have any NUL characters in it? What happens if you run e.g. sha1(1) over it a million times? If there are NUL characters, there might be a bug in the awk script that generates usbdevs.h. If there are no NUL characters, and you get a random failure each time, there might be a bug in clang. But did you mean you also saw it with gcc? -Dimitry From owner-freebsd-stable@FreeBSD.ORG Thu Jul 4 14:29:22 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 228262E4; Thu, 4 Jul 2013 14:29:22 +0000 (UTC) (envelope-from Andre.Albsmeier@siemens.com) Received: from thoth.sbs.de (thoth.sbs.de [192.35.17.2]) by mx1.freebsd.org (Postfix) with ESMTP id A21F018F5; Thu, 4 Jul 2013 14:29:21 +0000 (UTC) Received: from mail1.siemens.de (localhost [127.0.0.1]) by thoth.sbs.de (8.13.6/8.13.6) with ESMTP id r64ETJ41008408; Thu, 4 Jul 2013 16:29:19 +0200 Received: from curry.mchp.siemens.de (curry.mchp.siemens.de [139.25.40.130]) by mail1.siemens.de (8.13.6/8.13.6) with ESMTP id r64ETJD8011971; Thu, 4 Jul 2013 16:29:19 +0200 Received: (from localhost) by curry.mchp.siemens.de (8.14.7/8.14.7) id r64ETJHD016405; Date: Thu, 4 Jul 2013 16:29:19 +0200 From: Andre Albsmeier To: Konstantin Belousov Subject: Re: FreeBSD-9.1: machine reboots during snapshot creation, LORs found Message-ID: <20130704142919.GA1798@bali> References: <20130531122611.GA6607@bali> <201305311051.03157.jhb@freebsd.org> <20130616063942.GA72803@bali> <201306171530.31208.jhb@freebsd.org> <20130704051409.GA22021@bali> <20130704052440.GG91021@kib.kiev.ua> <20130704052659.GA23398@bali> <20130704061550.GI91021@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130704061550.GI91021@kib.kiev.ua> X-Echelon: X-Advice: Drop that crappy M$-Outlook, I'm tired of your viruses! User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "freebsd-stable@freebsd.org" , John Baldwin 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, 04 Jul 2013 14:29:22 -0000 On Thu, 04-Jul-2013 at 08:15:50 +0200, Konstantin Belousov wrote: > On Thu, Jul 04, 2013 at 07:27:00AM +0200, Andre Albsmeier wrote: > > On Thu, 04-Jul-2013 at 07:24:40 +0200, Konstantin Belousov wrote: > > > On Thu, Jul 04, 2013 at 07:14:09AM +0200, Andre Albsmeier wrote: > > > > On Mon, 17-Jun-2013 at 21:30:31 +0200, John Baldwin wrote: > > > > > On Sunday, June 16, 2013 2:39:42 am Andre Albsmeier wrote: > > > > > > On Fri, 31-May-2013 at 16:51:03 +0200, John Baldwin wrote: > > > > > > > On Friday, May 31, 2013 8:26:11 am Andre Albsmeier wrote: > > > > > > > > Each day at 5:15 we are generating snapshots on various machines. > > > > > > > > This used to work perfectly under 7-STABLE for years but since > > > > > > > > we started to use 9.1-STABLE the machine reboots in about 10% > > > > > > > > of all cases. > > > > > > > > > > > > > > > > After rebooting we find a new snapshot file which is a bit > > > > > > > > smaller than the good ones and with different permissions > > > > > > > > It does not succeed a fsck. In this example it is the one > > > > > > > > whose name is beginning with s3: > > > > > > > > > > > > > > > > -r--r----- 1 root operator snapshot 72802894528 29 May 05:15 s2-2013.05.28-03.15.04 > > > > > > > > -r-------- 1 root operator snapshot 72802893824 29 May 05:15 s3-2013.05.29-03.15.03 > > > > > > > > -r--r----- 1 root operator snapshot 72802894528 28 May 14:22 s4-2013.05.23-06.38.44 > > > > > > > > -r--r----- 1 root operator snapshot 72802894528 28 May 14:22 s5-2013.05.24-03.15.03 > > > > > > > > -r--r----- 1 root operator snapshot 72802894528 28 May 14:22 s6-2013.05.25-03.15.03 > > > > > > > > > > > > > > > > After enabling DIAGNOSTIC, WITNESS and INVARIANTS in the kernel > > > > > > > > I see the following LORs (mksnap_ffs starts exactly at 5:15): > > > > > > > > > > > > > > > > May 29 05:15:00 palveli kernel: lock order reversal: > > > > > > > > May 29 05:15:00 palveli kernel: 1st 0xc2371da8 ufs (ufs) @ /src/src-9/sys/kern/vfs_mount.c:1240 > > > > > > > > May 29 05:15:00 palveli kernel: 2nd 0xc2371ec4 devfs (devfs) @ /src/src-9/sys/ufs/ffs/ffs_vfsops.c:1414 > > > > > > > > May 29 05:15:04 palveli kernel: lock order reversal: > > > > > > > > May 29 05:15:04 palveli kernel: 1st 0xc228471c snaplk (snaplk) @ /src/src-9/sys/ufs/ufs/ufs_vnops.c:976 > > > > > > > > May 29 05:15:04 palveli kernel: 2nd 0xc22f25e4 ufs (ufs) @ /src/src-9/sys/ufs/ffs/ffs_snapshot.c:1626 > > > > > > > > > > > > > > > > Unfortunatley no corefiles are being generated ;-(. > > > > > > > > > > > > > > > > I have checked and even rebuilt the (UFS1) fs in question > > > > > > > > from scratch. I have also seen this happen on an UFS2 on > > > > > > > > another machine and on a third one when running "dump -L" > > > > > > > > on a root fs. > > > > > > > > > > > > > > > > Any hints of how to proceed? > > > > > > > > > > > > > > Would it be possible to setup a serial console that is logged on this machine > > > > > > > to see if it is panic'ing but failing to write out a crashdump? > > > > > > > > > > > > Couldn't attach the serial console yet ;-(. But I had people > > > > > > attach a KVMoverIP switch and enabled the various KDB options > > > > > > in the kernel. Now we can see a bit more (see below) -- no > > > > > > crashdump is being generated though. > > > > > > > > > > :( Unfortunately these LORs don't really help with discerning the cause of > > > > > the reboot. If you have remote power access (and still wanted to test this) > > > > > one option would be to change KDB to drop into the debugger on a panic. > > > > > Then you could connect over the KVM and take images of the original panic > > > > > along with a stack trace. > > > > > > > > After a few days of no problems, the box decided to crash > > > > during mksnap_ffs today ;-(. But now I have a crashdump, > > > > see below. Unfortunatley, I cannot upload the dump somewhere > > > > but if you ask me check whatever things I'll be happy to help. > > > > > > > > kgdb /usr/obj/src/src-9/sys/palveli/kernel.debug vmcore.4 > > > > GNU gdb 6.1.1 [FreeBSD] > > > > Copyright 2004 Free Software Foundation, Inc. > > > > GDB is free software, covered by the GNU General Public License, and you are > > > > welcome to change it and/or distribute copies of it under certain conditions. > > > > Type "show copying" to see the conditions. > > > > There is absolutely no warranty for GDB. Type "show warranty" for details. > > > > This GDB was configured as "i386-marcel-freebsd"... > > > > > > > > Unread portion of the kernel message buffer: > > > > > > > > > > > > Fatal trap 12: page fault while in kernel mode > > > > fault virtual address = 0xcfb5e000 > > > > fault code = supervisor write, page not present > > > > instruction pointer = 0x20:0xc07cb2fe > > > > stack pointer = 0x28:0xd83545d0 > > > > frame pointer = 0x28:0xd835490c > > > > code segment = base 0x0, limit 0xfffff, type 0x1b > > > > = DPL 0, pres 1, def32 1, gran 1 > > > > processor eflags = interrupt enabled, resume, IOPL = 0 > > > > current process = 12929 (mksnap_ffs) > > > > trap number = 12 > > > > panic: page fault > > > > KDB: stack backtrace: > > > > db_trace_self_wrapper(c08207eb,d835441c,c05fdfc9,c081df13,c08a82e0,...) at db_trace_self_wrapper+0x26/frame 0xd83543ec > > > > kdb_backtrace(c081df13,c08a82e0,c0801bfa,d8354428,d8354428,...) at kdb_backtrace+0x29/frame 0xd83543f8 > > > > panic(c0801bfa,c0845a01,c2bafae4,1,1,...) at panic+0xc9/frame 0xd835441c > > > > trap_fatal(c0ff6000,cfb5e000,2,0,265abf,...) at trap_fatal+0x353/frame 0xd835445c > > > > trap_pfault(140da,0,c2baf930,c08b6a40,c282145c,...) at trap_pfault+0x2d7/frame 0xd83544a4 > > > > trap(d8354590) at trap+0x41a/frame 0xd8354584 > > > > calltrap() at calltrap+0x6/frame 0xd8354584 > > > > --- trap 0xc, eip = 0xc07cb2fe, esp = 0xd83545d0, ebp = 0xd835490c --- > > > > bcopy(c2b36548,c2f194e0,0,0,0,...) at bcopy+0x1a/frame 0xd835490c > > > > ffs_mount(c2b36548,c2db9000,ff,d8354c08,c2b665e4,...) at ffs_mount+0x15ee/frame 0xd8354a3c > > > > > > From the crash dump in kgdb, do > > > list *ffs_mount+0x15ee > > > > (kgdb) list *ffs_mount+0x15ee > > 0xc0748e8e is in ffs_mount (/src/src-9/sys/ufs/ffs/ffs_vfsops.c:483). > > 478 > > 479 /* > > 480 * If this is a snapshot request, take the snapshot. > > 481 */ > > 482 if (mp->mnt_flag & MNT_SNAPSHOT) > > 483 return (ffs_snapshot(mp, fspec)); > > 484 } > > 485 > > 486 /* > > 487 * Not an update, or updating the name: look up the name > > It is not useful, bcopy does not create a frame, so the real caller > of the failing bcopy gets lost. It could be uncovered with some > stack digging, but I believe it would be easier just fix bcopy. > > Please apply this patch and reproduce the panic again, then the kgdb > backtrace should be more useful. OK, patch is applied. I will reboot the machine later and see what happens tomorrow in the morning. However, it might take a few days since the last 2 weeks all was fine. BTW, should this patch be used in general or is it just for debugging? My understanding is that it is something which could stay in the code... Thanks, -Andre > > diff --git a/sys/i386/i386/support.s b/sys/i386/i386/support.s > index 967a09e..779fa38 100644 > --- a/sys/i386/i386/support.s > +++ b/sys/i386/i386/support.s > @@ -181,11 +181,13 @@ END(bcopyb) > * ws@tools.de (Wolfgang Solfrank, TooLs GmbH) +49-228-985800 > */ > ENTRY(bcopy) > + pushl %ebp > + movl %esp,%ebp > pushl %esi > pushl %edi > - movl 12(%esp),%esi > - movl 16(%esp),%edi > - movl 20(%esp),%ecx > + movl 8(%ebp),%esi > + movl 12(%ebp),%edi > + movl 16(%ebp),%ecx > > movl %edi,%eax > subl %esi,%eax > @@ -196,12 +198,13 @@ ENTRY(bcopy) > cld /* nope, copy forwards */ > rep > movsl > - movl 20(%esp),%ecx > + movl 16(%ebp),%ecx > andl $3,%ecx /* any bytes left? */ > rep > movsb > popl %edi > popl %esi > + popl %ebp > ret > > ALIGN_TEXT > @@ -214,7 +217,7 @@ ENTRY(bcopy) > std > rep > movsb > - movl 20(%esp),%ecx /* copy remainder by 32-bit words */ > + movl 16(%ebp),%ecx /* copy remainder by 32-bit words */ > shrl $2,%ecx > subl $3,%esi > subl $3,%edi > @@ -223,6 +226,7 @@ ENTRY(bcopy) > popl %edi > popl %esi > cld > + popl %ebp > ret > END(bcopy) > From owner-freebsd-stable@FreeBSD.ORG Thu Jul 4 15:32:02 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id CFD129A1 for ; Thu, 4 Jul 2013 15:32:02 +0000 (UTC) (envelope-from fabian@wenks.ch) Received: from batman.home4u.ch (batman.home4u.ch [IPv6:2001:8a8:1005:1::2]) by mx1.freebsd.org (Postfix) with ESMTP id 47DFC1CDB for ; Thu, 4 Jul 2013 15:32:01 +0000 (UTC) X-Virus-Scanned: amavisd-new at home4u.ch Received: from flashback.wenks.ch (fabian@flashback.wenks.ch [IPv6:2001:8a8:1005:1:223:dfff:fedf:13c9]) (authenticated bits=0) by batman.home4u.ch (8.14.5/8.14.5) with ESMTP id r64FVwpR006843 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Thu, 4 Jul 2013 17:31:59 +0200 (CEST) (envelope-from fabian@wenks.ch) Message-ID: <51D5956E.8090400@wenks.ch> Date: Thu, 04 Jul 2013 17:31:58 +0200 From: Fabian Wenk User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: Where's the docs for FreeBSD maintenance with Subversion? References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; 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: Thu, 04 Jul 2013 15:32:02 -0000 Hello Chris On 04.07.2013 10:00, Chris H wrote: > working on a fairly wobbly system. I'm on RELENG_8 (8.4), and would like to sync my src && > ports via the (now defacto) subversion method. My previous experience is with the client For /usr/src/ I did the following steps: Adjust the variables in /etc/make.conf (remove the "old" SUP* variables and add): SVN_UPDATE=yes SVN=/usr/local/bin/svn Then do the following steps: Backup your custom kernel config file and anything else you have customized in /usr/src/, or if you have the space, use: mv /usr/src /usr/src-old rm -rf /usr/src # only if you did not 'mv ...' svn checkout svn://svn.freebsd.org/base/releng/8.4 /usr/src Restore your custom kernel config file cd /usr/src make update # should not sync anything, just for testing Everything else is "almost" identical as before with csup/cvsup. The only drawback with the subversion method is, that when you would like to upgrade to e.g. RELENG_8_5, you need to redo the above steps with removing /usr/src and checkout. This was more easier with the csup/cvsup method with just adjusting the version in the supfile. If there is an easier solution to upgrade an existing svn checkout from e.g. 8.4 to 8.5, please tell me. With the above created svn checkout and then doing the 'make update' you will get the updates from any Security Advisory affecting your current RELEASE, as it was with csup/cvsup. The checkout with subversion uses significant more disk space than it was with csup/cvsup before. With subversion 1.8 I have ~720 MB (was ~770 MB with svn 1.7) in /usr/src/.svn (RELEASE-9.1) and ~670 MB (was ~830 MB with svn 1.7) in /usr/ports/.svn. A fresh install of a FreeBSD system is also an interesting challenge. In the past I did the install without Ports, then fetched a newer ports.tar.gz from the mirror and extracted it into /usr/ports/ and did use csup to get it up-to-date. With subversion this is a little bit more complicated, as subversion is also in the Ports and not in the FreeBSD base. You could install subversion and all the dependencies from packages and then do the svn checkout of /usr/ports/ and then upgrading the installed packages. Or you install the Ports and use portsnap to upgrade, build subversion and dependencies, remove /usr/ports/ again (probably preserve /usr/ports/distfiles/) and do the svn checkout of /usr/ports/. bye Fabian From owner-freebsd-stable@FreeBSD.ORG Thu Jul 4 15:52:50 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 540EDF65 for ; Thu, 4 Jul 2013 15:52:50 +0000 (UTC) (envelope-from tevans.uk@googlemail.com) Received: from mail-la0-x233.google.com (mail-la0-x233.google.com [IPv6:2a00:1450:4010:c03::233]) by mx1.freebsd.org (Postfix) with ESMTP id D55DE1DF3 for ; Thu, 4 Jul 2013 15:52:49 +0000 (UTC) Received: by mail-la0-f51.google.com with SMTP id fq12so1337130lab.24 for ; Thu, 04 Jul 2013 08:52:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=PvviR0Vwsqbg/Mso2vNU2cOq21CcnZh3zL2CpK+Sp7o=; b=YzCf7Qf1JzIH9Fz9m7FfreK2C4QT8dBPh1FM5xPebd/mCs1bfxP3xFerHTL4FpmLzM Os1V4BsgOwjpUhijYX6TKg22YChZuVtE9mKjAA2eObftqMbobLxzlioSBi0FSEX9NB0G U4AMji9E3e67aCvyHBPkG4zGCFOFHHqRq+YrXBB4xEarogF1ymEALtCr0uezDUl3bSXd P+H+gxqW3OMLEpw7Ho5eVl2Bz3YPoqUQA/U4SrXrnwm8QRGAmF5f1wKs6wtDEo618otR OdOoaaSyoi6FmX9sMPvWZ8Gup1Wn97lMj+GI1GQlijT1lxzKyZr5PDpf2KRK38fqVYLt Tqjw== MIME-Version: 1.0 X-Received: by 10.112.170.166 with SMTP id an6mr3853195lbc.22.1372953168732; Thu, 04 Jul 2013 08:52:48 -0700 (PDT) Received: by 10.112.201.41 with HTTP; Thu, 4 Jul 2013 08:52:48 -0700 (PDT) In-Reply-To: <51D5956E.8090400@wenks.ch> References: <51D5956E.8090400@wenks.ch> Date: Thu, 4 Jul 2013 16:52:48 +0100 Message-ID: Subject: Re: Where's the docs for FreeBSD maintenance with Subversion? From: Tom Evans To: Fabian Wenk Content-Type: text/plain; charset=UTF-8 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, 04 Jul 2013 15:52:50 -0000 On Thu, Jul 4, 2013 at 4:31 PM, Fabian Wenk wrote: > If there is an easier solution to > upgrade an existing svn checkout from e.g. 8.4 to 8.5, please tell me. cd /usr/src ; svn switch http://svn.freebsd.org/base/releng/8.5 Cheers Tom From owner-freebsd-stable@FreeBSD.ORG Thu Jul 4 16:02:13 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 5AEBD653; Thu, 4 Jul 2013 16:02:13 +0000 (UTC) (envelope-from jdavidlists@gmail.com) Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) by mx1.freebsd.org (Postfix) with ESMTP id 257CA1E92; Thu, 4 Jul 2013 16:02:13 +0000 (UTC) Received: by mail-ie0-f171.google.com with SMTP id qd12so3425169ieb.2 for ; Thu, 04 Jul 2013 09:02:12 -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=xEpH+nYtExEq0jXKcBSH6POh7mLAiwCJqbltMaIBppg=; b=hIPc8Ii1FzhhVbGJl4fzi8W8ZAWJpO8zuNW3R7DCxxtepW/+q9EbKe3IXb13UekaKA gFRh3snn340uCVDeRZ86ovYvEa5C5FlaL1Toiv8+lD0K5dF6wkzSkxpfmDRs9XKX1H+k gW9fyYDBWlys+29EFvb3lYsAmub5hCOt40cQjW25pPQCWPXe4PmrrJPS3LBHXz5NRF5F Bhv2XUIx5w7AQwk1/vPtPwGFS2gXgs9fuVudek4Z2Xzrm7msRXtv//tqdyhDSdb+s0v6 xXHbfPWRp+jilwByE2JJDyP7IPB6jyqlpQZyZU9OBcjAEY9/xGlVtR+gu6r6yZhjEeSb +fsQ== MIME-Version: 1.0 X-Received: by 10.42.199.5 with SMTP id eq5mr2654829icb.1.1372953732749; Thu, 04 Jul 2013 09:02:12 -0700 (PDT) Sender: jdavidlists@gmail.com Received: by 10.42.114.73 with HTTP; Thu, 4 Jul 2013 09:02:12 -0700 (PDT) In-Reply-To: <2D61560D-E3D9-4558-8715-8215DBBF21D9@FreeBSD.org> References: <2D61560D-E3D9-4558-8715-8215DBBF21D9@FreeBSD.org> Date: Thu, 4 Jul 2013 12:02:12 -0400 X-Google-Sender-Auth: dTbwYcLC0YbhM01pu_F2DmANfNI Message-ID: Subject: Re: Phantom nulls in usbdevs.h during 9-STABLE kernel build From: J David To: Dimitry Andric Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 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, 04 Jul 2013 16:02:13 -0000 On Thu, Jul 4, 2013 at 9:08 AM, Dimitry Andric wrote: > So the actual file does *not* have any NUL characters in it? What > happens if you run e.g. sha1(1) over it a million times? > Based on this suggestion, I wrote a script to sha256 usbdevs.h every 0.25 seconds and did another buildworld. (Note: I did a third buildworld last night, between the two I sent yesterday and this one. It was fine.) It died with this: In file included from /usr/src/sys/modules/usb/quirk/../../../dev/usb/quirk/usb_quirk.c:51: ./usbdevs.h:2487:64: error: null character ignored [-Werror,-Wnull-character] #define USB_PRODUCT_LOGITECH_UN53B 0xc032 /* iFeel MouseMan */ ^ /usr/src/sys/modules/usb/quirk/../../../dev/usb/quirk/usb_quirk.c:95:2: error: expected ')' USB_QUIRK(LOGITECH, UN53B, 0x0000, 0xffff, UQ_NO_STRINGS), ^ /usr/src/sys/modules/usb/quirk/../../../dev/usb/quirk/usb_quirk.c:79:32: note: expanded from macro 'USB_QUIRK' USB_QUIRK_VP(USB_VENDOR_##v, USB_PRODUCT_##v##_##p, l, h, __VA_ARGS__) ^ :29:1: note: expanded from macro 'USB_PRODUCT_' USB_PRODUCT_LOGITECH_UN53B ^ ./usbdevs.h:2487:65: note: expanded from macro 'USB_PRODUCT_LOGITECH_UN53B' .../* iFeel MouseMan */#define USB_PRODUCT_LOGITECH_WMPAD... ^ /usr/src/sys/modules/usb/quirk/../../../dev/usb/quirk/usb_quirk.c:76:25: note: expanded from macro 'USB_QUIRK_VP' { .vid = (v), .pid = (p), .lo_rev = (l), .hi_rev = (h), \ ^ /usr/src/sys/modules/usb/quirk/../../../dev/usb/quirk/usb_quirk.c:95:2: note: to match this '(' USB_QUIRK(LOGITECH, UN53B, 0x0000, 0xffff, UQ_NO_STRINGS), ^ /usr/src/sys/modules/usb/quirk/../../../dev/usb/quirk/usb_quirk.c:79:3: note: expanded from macro 'USB_QUIRK' USB_QUIRK_VP(USB_VENDOR_##v, USB_PRODUCT_##v##_##p, l, h, __VA_ARGS__) ^ /usr/src/sys/modules/usb/quirk/../../../dev/usb/quirk/usb_quirk.c:76:24: note: expanded from macro 'USB_QUIRK_VP' { .vid = (v), .pid = (p), .lo_rev = (l), .hi_rev = (h), \ ^ 2 errors generated. *** [usb_quirk.o] Error code 1 My script says usbdevs.h was generated early on in the build process (with the same SHA256 value as the one that previously worked) and did not report any subsequent changes during the build and failure. If there are NUL characters, there might be a bug in the awk script that > generates usbdevs.h. If there are no NUL characters, and you get a > random failure each time, there might be a bug in clang. As before, I don't see any nulls in the actual file: 00000070 6f 75 73 65 20 2a 2f 0a 23 64 65 66 69 6e 65 09 |ouse */.#define.| 00000080 55 53 42 5f 50 52 4f 44 55 43 54 5f 4c 4f 47 49 |USB_PRODUCT_LOGI| 00000090 54 45 43 48 5f 55 4e 35 33 42 09 30 78 63 30 33 |TECH_UN53B.0xc03| 000000a0 32 09 09 2f 2a 20 69 46 65 65 6c 20 4d 6f 75 73 |2../* iFeel Mous| 000000b0 65 4d 61 6e 20 2a 2f 0a 23 64 65 66 69 6e 65 09 |eMan */.#define.| 000000c0 55 53 42 5f 50 52 4f 44 55 43 54 5f 4c 4f 47 49 |USB_PRODUCT_LOGI| 000000d0 54 45 43 48 5f 57 4d 50 41 44 09 30 78 63 32 30 |TECH_WMPAD.0xc20| > But did you > mean you also saw it with gcc? > Yes, I am pretty sure we have seen this with gcc as well because one of the first machines that started doing this doesn't have the CLANG options in make.conf. I will try to reproduce that to be absolutely sure, but that may take several hours. Thanks! From owner-freebsd-stable@FreeBSD.ORG Thu Jul 4 16:16:04 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 009C5B05 for ; Thu, 4 Jul 2013 16:16:03 +0000 (UTC) (envelope-from dim@freebsd.org) Received: from tensor.andric.com (tensor.andric.com [IPv6:2001:7b8:3a7:1:2d0:b7ff:fea0:8c26]) by mx1.freebsd.org (Postfix) with ESMTP id B8F6F1F55 for ; Thu, 4 Jul 2013 16:16:03 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7::199c:6fe6:9d79:6781] (unknown [IPv6:2001:7b8:3a7:0:199c:6fe6:9d79:6781]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id ADA4B5C43; Thu, 4 Jul 2013 18:16:00 +0200 (CEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: Phantom nulls in usbdevs.h during 9-STABLE kernel build From: Dimitry Andric In-Reply-To: Date: Thu, 4 Jul 2013 18:15:59 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2D61560D-E3D9-4558-8715-8215DBBF21D9@FreeBSD.org> To: J David X-Mailer: Apple Mail (2.1508) 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, 04 Jul 2013 16:16:04 -0000 On Jul 4, 2013, at 18:02, J David wrote: ... > Yes, I am pretty sure we have seen this with gcc as well because one = of the first machines that started doing this doesn't have the CLANG = options in make.conf. I will try to reproduce that to be absolutely = sure, but that may take several hours. One other thing: which type of file system are you using for /usr/obj, = or wherever you pointed $MAKEOBJDIRPREFIX? -Dimitry From owner-freebsd-stable@FreeBSD.ORG Thu Jul 4 17:10:09 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id D8519AC8 for ; Thu, 4 Jul 2013 17:10:09 +0000 (UTC) (envelope-from fabian@wenks.ch) Received: from batman.home4u.ch (batman.home4u.ch [IPv6:2001:8a8:1005:1::2]) by mx1.freebsd.org (Postfix) with ESMTP id 69E8111F2 for ; Thu, 4 Jul 2013 17:10:08 +0000 (UTC) X-Virus-Scanned: amavisd-new at home4u.ch Received: from flashback.wenks.ch (fabian@flashback.wenks.ch [IPv6:2001:8a8:1005:1:223:dfff:fedf:13c9]) (authenticated bits=0) by batman.home4u.ch (8.14.5/8.14.5) with ESMTP id r64HA67T016556 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Thu, 4 Jul 2013 19:10:06 +0200 (CEST) (envelope-from fabian@wenks.ch) Message-ID: <51D5AC6E.8070209@wenks.ch> Date: Thu, 04 Jul 2013 19:10:06 +0200 From: Fabian Wenk User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: Where's the docs for FreeBSD maintenance with Subversion? References: <51D5956E.8090400@wenks.ch> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; 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: Thu, 04 Jul 2013 17:10:09 -0000 Hello Tom On 04.07.2013 17:52, Tom Evans wrote: > On Thu, Jul 4, 2013 at 4:31 PM, Fabian Wenk wrote: >> If there is an easier solution to >> upgrade an existing svn checkout from e.g. 8.4 to 8.5, please tell me. > > cd /usr/src ; svn switch http://svn.freebsd.org/base/releng/8.5 Thank you, this is very helpful. It would probably be a good idea if this could be added to "A.5. Using Subversion" [1] in the handbook. [1] http://www.freebsd.org/doc/handbook/svn.html bye Fabian From owner-freebsd-stable@FreeBSD.ORG Thu Jul 4 17:25:37 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id AB9EED63; Thu, 4 Jul 2013 17:25:37 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 1E63C1295; Thu, 4 Jul 2013 17:25:36 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id r64HPSXT097022; Thu, 4 Jul 2013 20:25:28 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua r64HPSXT097022 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id r64HPSlu096994; Thu, 4 Jul 2013 20:25:28 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 4 Jul 2013 20:25:28 +0300 From: Konstantin Belousov To: Andre Albsmeier Subject: Re: FreeBSD-9.1: machine reboots during snapshot creation, LORs found Message-ID: <20130704172528.GL91021@kib.kiev.ua> References: <20130531122611.GA6607@bali> <201305311051.03157.jhb@freebsd.org> <20130616063942.GA72803@bali> <201306171530.31208.jhb@freebsd.org> <20130704051409.GA22021@bali> <20130704052440.GG91021@kib.kiev.ua> <20130704052659.GA23398@bali> <20130704061550.GI91021@kib.kiev.ua> <20130704142919.GA1798@bali> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="+odIVbikbWChO5Pj" Content-Disposition: inline In-Reply-To: <20130704142919.GA1798@bali> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: "freebsd-stable@freebsd.org" , John Baldwin 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, 04 Jul 2013 17:25:37 -0000 --+odIVbikbWChO5Pj Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jul 04, 2013 at 04:29:19PM +0200, Andre Albsmeier wrote: > OK, patch is applied. I will reboot the machine later > and see what happens tomorrow in the morning. However, > it might take a few days since the last 2 weeks all was > fine. >=20 > BTW, should this patch be used in general or is it just > for debugging? My understanding is that it is something > which could stay in the code... Patch is to improve debugging. I probably commit it after the issue is closed. Arguments against the commit is that the change imposes small performance penalty due to save and restore of the %ebp (I doubt that this is measureable by any means). Also, arguably, such change should be done for all functions in support.s, but bcopy() is the hot spot. --+odIVbikbWChO5Pj Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iQIcBAEBAgAGBQJR1bAHAAoJEJDCuSvBvK1BIGoQAIMnJE9nUDY0qixM7EHG/A8Q q+hiwDtOqUyBfEsmrC/+hQMGZJYmyTpI+pgsnI1VWwZgeUaqswv9a+h2qvHqTDCu 8IGJZRtDpTS+tGnDAAxxiEVJ+NGJ3gSDYx2qtSty7eQVQls7eB4q87FA6I+6cZex djinQtLJGo2oesUzojvrVdkFS8GgvO5wm4aveoWAXGCx1otPR+bswjLSBFpToDm4 KE5lFtRYVsBSggaw8TzDJrUIpDqhXYY3dObgAtpz0sCINwGaKvSGTIQxJFpN1cW+ JnMmzPF0SePm7IJd0jRzmkC2X/5aNaziw0P6cgWCnY5Qjs16jr3HRroU0tzJVM3L Vq3m84xrQCZlkhg2hsE5YMMuVv+mEeyL77ev69oFVuplIj/oifsQvv6wXkaVKc06 3Wte4XcR1w3l9qRgI2Nj5sp1KTX2dVJ0b+Cw914HygeQlZ5eAiU/XucVmPe6pnCq ReLUyFJVjVFjbG4x2PhHGNGdJ17hVsfLumREanaZUxhUDQ+KQ1BPeU7OKtBcezlS Nm2gNtaHBCSY0yQgAjbbd33j5WhEYeqAFM28Vzz/DCj09pWM9RisNpzfsFabjW0v OnBpKyAzmPyo2SL8Y9X32B34p42GNXy4/UVQq9JziiyNIvReza+EtnXDSjOnWEtk Eka18BFj4vrFmd75N9Uf =2GFI -----END PGP SIGNATURE----- --+odIVbikbWChO5Pj-- From owner-freebsd-stable@FreeBSD.ORG Thu Jul 4 17:34:04 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 9A3D3F09; Thu, 4 Jul 2013 17:34:04 +0000 (UTC) (envelope-from Andre.Albsmeier@siemens.com) Received: from david.siemens.de (david.siemens.de [192.35.17.14]) by mx1.freebsd.org (Postfix) with ESMTP id 3010B12E3; Thu, 4 Jul 2013 17:34:03 +0000 (UTC) Received: from mail3.siemens.de (localhost [127.0.0.1]) by david.siemens.de (8.13.6/8.13.6) with ESMTP id r64HY1HA022004; Thu, 4 Jul 2013 19:34:02 +0200 Received: from curry.mchp.siemens.de (curry.mchp.siemens.de [139.25.40.130]) by mail3.siemens.de (8.13.6/8.13.6) with ESMTP id r64HY13L017321; Thu, 4 Jul 2013 19:34:01 +0200 Received: (from localhost) by curry.mchp.siemens.de (8.14.7/8.14.7) id r64HY1bp016957; Date: Thu, 4 Jul 2013 19:34:01 +0200 From: Andre Albsmeier To: Konstantin Belousov Subject: Re: FreeBSD-9.1: machine reboots during snapshot creation, LORs found Message-ID: <20130704173401.GA3297@bali> References: <20130531122611.GA6607@bali> <201305311051.03157.jhb@freebsd.org> <20130616063942.GA72803@bali> <201306171530.31208.jhb@freebsd.org> <20130704051409.GA22021@bali> <20130704052440.GG91021@kib.kiev.ua> <20130704052659.GA23398@bali> <20130704061550.GI91021@kib.kiev.ua> <20130704142919.GA1798@bali> <20130704172528.GL91021@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130704172528.GL91021@kib.kiev.ua> X-Echelon: X-Advice: Drop that crappy M$-Outlook, I'm tired of your viruses! User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "freebsd-stable@freebsd.org" , John Baldwin 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, 04 Jul 2013 17:34:04 -0000 On Thu, 04-Jul-2013 at 19:25:28 +0200, Konstantin Belousov wrote: > On Thu, Jul 04, 2013 at 04:29:19PM +0200, Andre Albsmeier wrote: > > OK, patch is applied. I will reboot the machine later > > and see what happens tomorrow in the morning. However, > > it might take a few days since the last 2 weeks all was > > fine. > > > > BTW, should this patch be used in general or is it just > > for debugging? My understanding is that it is something > > which could stay in the code... > > Patch is to improve debugging. That's what I suspected. > > I probably commit it after the issue is closed. Arguments against > the commit is that the change imposes small performance penalty > due to save and restore of the %ebp (I doubt that this is measureable > by any means). Also, arguably, such change should be done for all > functions in support.s, but bcopy() is the hot spot. Hmm, maybe it could simply get enabled conditionally through some kernel compile option which is off by default... -Andre From owner-freebsd-stable@FreeBSD.ORG Thu Jul 4 18:58:31 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id C5B354A4; Thu, 4 Jul 2013 18:58:31 +0000 (UTC) (envelope-from bsd.gaijin@gmail.com) Received: from mail-yh0-x22d.google.com (mail-yh0-x22d.google.com [IPv6:2607:f8b0:4002:c01::22d]) by mx1.freebsd.org (Postfix) with ESMTP id 7DF8B1911; Thu, 4 Jul 2013 18:58:31 +0000 (UTC) Received: by mail-yh0-f45.google.com with SMTP id b20so586137yha.18 for ; Thu, 04 Jul 2013 11:58:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:subject:date:message-id:cc:to:mime-version :x-mailer; bh=Xa2Cq9i8XmW8iCiQMoHSDPkhluFAHQkuoxJCml/vcT8=; b=Kk7A1sTG9vt7yVrCsql+X08n6/jHWfjEjg0Vz4vE1X5HRg7hx44vWvlVjjJ91PLMdK Lrvvrfsr2IigWrFS8EgbDV4vv7fIWXp20VMUzwE2Fr/vhgCJJP5U0NC7LixPUeaVQGdV vnEW3m1SH+D4OTpVnGhmBPST6o1MAX9Jauz/Lb1LYWaxrfou0/qAUHpbqB9XI8nciDeL nXafMvIq1sM+cnoeT8/Oh5P536g51WdVdUpSZewFgizGLwD4yzbEplWppO5wkCKLvXre CzHLwSA286zkuOf9BmKvtKmMlglqjMHHcPS3ajEgLsXTkBoYZsnXilxdEyFNc/FFIZa3 6zuQ== X-Received: by 10.236.207.2 with SMTP id m2mr3804459yho.214.1372964311049; Thu, 04 Jul 2013 11:58:31 -0700 (PDT) Received: from [10.0.3.5] (pool-96-242-215-113.nwrknj.fios.verizon.net. [96.242.215.113]) by mx.google.com with ESMTPSA id s29sm6729097yhf.6.2013.07.04.11.58.29 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 04 Jul 2013 11:58:30 -0700 (PDT) From: Alexandre Kovalenko Subject: XHCI umass support breaks between r248085 and r252560 on 9-STABLE Date: Thu, 4 Jul 2013 14:58:30 -0400 Message-Id: <94A3DD2E-F2E2-4302-8197-BAB213641E2F@gmail.com> To: freebsd-usb@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 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, 04 Jul 2013 18:58:31 -0000 Three different external hard drives (Seagate, Western Digital and = noname USB 3.0 enclosure) refused to be recognized as the umass devices. = Reverting /usr/src/sys/dev/bsd/controller to r248085, building and = loading just xhci module makes drives appear again. Below are snippets = from the log in both cases: Non working: Jul 4 14:35:17 twinhead kernel: xhci0: mem 0xfddfe000-0xfddfffff irq 16 at device 0.0 on pci2 Jul 4 14:35:17 twinhead kernel: xhci0: 64 byte context size. Jul 4 14:35:17 twinhead kernel: usbus0 on xhci0 Jul 4 14:35:17 twinhead kernel: usbus0: 5.0Gbps Super Speed USB v3.0 Jul 4 14:35:17 twinhead kernel: ugen0.1: <0x1912> at usbus0 Jul 4 14:35:17 twinhead kernel: uhub0: <0x1912 XHCI root HUB, class = 9/0, rev 3.00/1.00, addr 1> on usbus0 Jul 4 14:35:17 twinhead kernel: uhub0: 8 ports with 8 removable, self = powered Jul 4 14:35:24 twinhead kernel: ugen0.2: at usbus0 Jul 4 14:35:24 twinhead kernel: umass0: on usbus0 Jul 4 14:35:29 twinhead kernel: (probe0:umass-sim0:0:0:0): INQUIRY. = CDB: 12 00 00 00 24 00=20 Jul 4 14:35:29 twinhead kernel: (probe0:umass-sim0:0:0:0): CAM status: = CCB request completed with an error Jul 4 14:35:29 twinhead kernel: (probe0:umass-sim0:0:0:0): Retrying = command Jul 4 14:35:30 twinhead kernel: (probe0:umass-sim0:0:0:0): INQUIRY. = CDB: 12 00 00 00 24 00=20 Jul 4 14:35:30 twinhead kernel: (probe0:umass-sim0:0:0:0): CAM status: = CCB request completed with an error Jul 4 14:35:30 twinhead kernel: (probe0:umass-sim0:0:0:0): Retrying = command Jul 4 14:35:35 twinhead kernel: (probe0:umass-sim0:0:0:0): INQUIRY. = CDB: 12 00 00 00 24 00=20 Jul 4 14:35:35 twinhead kernel: (probe0:umass-sim0:0:0:0): CAM status: = CCB request completed with an error Jul 4 14:35:35 twinhead kernel: (probe0:umass-sim0:0:0:0): Retrying = command Jul 4 14:35:36 twinhead kernel: (probe0:umass-sim0:0:0:0): INQUIRY. = CDB: 12 00 00 00 24 00=20 Jul 4 14:35:36 twinhead kernel: (probe0:umass-sim0:0:0:0): CAM status: = CCB request completed with an error Jul 4 14:35:36 twinhead kernel: (probe0:umass-sim0:0:0:0): Retrying = command Jul 4 14:35:41 twinhead kernel: (probe0:umass-sim0:0:0:0): INQUIRY. = CDB: 12 00 00 00 24 00=20 Jul 4 14:35:41 twinhead kernel: (probe0:umass-sim0:0:0:0): CAM status: = CCB request completed with an error Jul 4 14:35:41 twinhead kernel: (probe0:umass-sim0:0:0:0): Error 5, = Retries exhausted Working: Jul 4 14:40:20 twinhead kernel: ugen0.2: at usbus0 = (disconnected) Jul 4 14:40:20 twinhead kernel: umass0: at uhub0, port 2, addr 1 = (disconnected) Jul 4 14:40:27 twinhead kernel: ugen0.2: at usbus0 Jul 4 14:40:27 twinhead kernel: umass0: on usbus0 Jul 4 14:40:27 twinhead kernel: (probe0:umass-sim0:0:0:0): REPORT LUNS. = CDB: a0 00 00 00 00 00 00 00 00 10 00 00=20 Jul 4 14:40:27 twinhead kernel: (probe0:umass-sim0:0:0:0): CAM status: = SCSI Status Error Jul 4 14:40:27 twinhead kernel: (probe0:umass-sim0:0:0:0): SCSI status: = Check Condition Jul 4 14:40:27 twinhead kernel: (probe0:umass-sim0:0:0:0): SCSI sense: = ILLEGAL REQUEST asc:20,0 (Invalid command operation code) Jul 4 14:40:27 twinhead kernel: (probe0:umass-sim0:0:0:0): Error 22, = Unretryable error Jul 4 14:40:27 twinhead kernel: da0 at umass-sim0 bus 0 scbus4 target 0 = lun 0 Jul 4 14:40:27 twinhead kernel: da0: = Fixed Direct Access SCSI-5 device=20 Jul 4 14:40:27 twinhead kernel: da0: 400.000MB/s transfers Jul 4 14:40:27 twinhead kernel: da0: 190782MB (390721968 512 byte = sectors: 255H 63S/T 24321C) Jul 4 14:40:27 twinhead kernel: da0: quirks=3D0x2 I can provide additional information or try patches as necessary. Alexandre "Sunny" Kovalenko (=D0=9E=D0=BB=D0=B5=D0=BA=D1=81=D0=B0=D0=BD=D0= =B4=D1=80 =D0=9A=D0=BE=D0=B2=D0=B0=D0=BB=D0=B5=D0=BD=D0=BA=D0=BE) From owner-freebsd-stable@FreeBSD.ORG Thu Jul 4 19:37:31 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 90325422 for ; Thu, 4 Jul 2013 19:37:31 +0000 (UTC) (envelope-from mike.jakubik@intertainservices.com) Received: from mail.intertainservices.com (mail.intertainservices.com [69.77.177.114]) by mx1.freebsd.org (Postfix) with ESMTP id 6E6171B4F for ; Thu, 4 Jul 2013 19:37:31 +0000 (UTC) Received: from freebsd.local (unknown [172.16.10.114]) by mail.intertainservices.com (Postfix) with ESMTPSA id BC4765645C for ; Thu, 4 Jul 2013 15:37:28 -0400 (EDT) Message-ID: <51D5CEF8.9000504@intertainservices.com> Date: Thu, 04 Jul 2013 15:37:28 -0400 From: Mike Jakubik User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130703 Thunderbird/17.0.7 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: UFS Trim wont stay set Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-intertainservices-MailScanner-Information: Please contact the ISP for more information X-intertainservices-MailScanner-ID: BC4765645C.A1086 X-intertainservices-MailScanner: Found to be clean X-intertainservices-MailScanner-From: mike.jakubik@intertainservices.com X-Spam-Status: No 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, 04 Jul 2013 19:37:31 -0000 Hello, I've just installed a stable snapshot on a new machine with a SSD drive, after installing i booted single user mode and ran # tunefs -t enable /dev/ada0p2 tunefs: issue TRIM to the disk set Great, back to multiuser mode, i check the partition # tunefs -p /dev/ada0p2 tunefs: POSIX.1e ACLs: (-a) disabled tunefs: NFSv4 ACLs: (-N) disabled tunefs: MAC multilabel: (-l) disabled tunefs: soft updates: (-n) enabled tunefs: soft update journaling: (-j) enabled tunefs: gjournal: (-J) disabled tunefs: trim: (-t) disabled What the heck.. did i miss something? Back to single user mode and # tunefs -t enable /dev/ada0p2 tunefs: issue TRIM to the disk remains unchanged as enabled I check again in multiuser mode and it says disabled, any ideas what is going on here? Thanks. From owner-freebsd-stable@FreeBSD.ORG Thu Jul 4 20:33:58 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 9A503AEE for ; Thu, 4 Jul 2013 20:33:58 +0000 (UTC) (envelope-from jdc@koitsu.org) Received: from relay4-d.mail.gandi.net (relay4-d.mail.gandi.net [217.70.183.196]) by mx1.freebsd.org (Postfix) with ESMTP id 57F311D7E for ; Thu, 4 Jul 2013 20:33:58 +0000 (UTC) Received: from mfilter6-d.gandi.net (mfilter6-d.gandi.net [217.70.178.135]) by relay4-d.mail.gandi.net (Postfix) with ESMTP id 393FC172092; Thu, 4 Jul 2013 22:33:47 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter6-d.gandi.net Received: from relay4-d.mail.gandi.net ([217.70.183.196]) by mfilter6-d.gandi.net (mfilter6-d.gandi.net [10.0.15.180]) (amavisd-new, port 10024) with ESMTP id 39Mm8ttJyur2; Thu, 4 Jul 2013 22:33:45 +0200 (CEST) X-Originating-IP: 76.102.14.35 Received: from jdc.koitsu.org (c-76-102-14-35.hsd1.ca.comcast.net [76.102.14.35]) (Authenticated sender: jdc@koitsu.org) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id 3EB04172085; Thu, 4 Jul 2013 22:33:44 +0200 (CEST) Received: by icarus.home.lan (Postfix, from userid 1000) id 6330C73A1C; Thu, 4 Jul 2013 13:33:42 -0700 (PDT) Date: Thu, 4 Jul 2013 13:33:42 -0700 From: Jeremy Chadwick To: Mike Jakubik Subject: Re: UFS Trim wont stay set Message-ID: <20130704203342.GA98181@icarus.home.lan> References: <51D5CEF8.9000504@intertainservices.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51D5CEF8.9000504@intertainservices.com> 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, 04 Jul 2013 20:33:58 -0000 On Thu, Jul 04, 2013 at 03:37:28PM -0400, Mike Jakubik wrote: > Hello, > > I've just installed a stable snapshot on a new machine with a SSD > drive, after installing i booted single user mode and ran > > # tunefs -t enable /dev/ada0p2 > tunefs: issue TRIM to the disk set > > Great, back to multiuser mode, i check the partition > > # tunefs -p /dev/ada0p2 > tunefs: POSIX.1e ACLs: (-a) disabled > tunefs: NFSv4 ACLs: (-N) disabled > tunefs: MAC multilabel: (-l) disabled > tunefs: soft updates: (-n) enabled > tunefs: soft update journaling: (-j) enabled > tunefs: gjournal: (-J) disabled > tunefs: trim: (-t) disabled > > What the heck.. did i miss something? Back to single user mode and > > # tunefs -t enable /dev/ada0p2 > tunefs: issue TRIM to the disk remains unchanged as enabled > > I check again in multiuser mode and it says disabled, any ideas what > is going on here? Yup, experienced this myself many times over. The reasons are understood (it's not limited to just the TRIM bits, it's related to anything adjusting the superblock -- it gets cached in memory in certain situations and not flushed back to disk). Hint: are you booting into single user and then issuing a "mount" command before doing your tunefs stuff? If so, this is probably what's causing it (at least it was in my case). Instead just boot into single-user, do not mount anything, and use /sbin/tunefs (if available -- depends on your filesystem setup) or /rescue/tunefs. -- | Jeremy Chadwick jdc@koitsu.org | | UNIX Systems Administrator http://jdc.koitsu.org/ | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Thu Jul 4 20:48:41 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 0390721B for ; Thu, 4 Jul 2013 20:48:41 +0000 (UTC) (envelope-from mike.jakubik@intertainservices.com) Received: from mail.intertainservices.com (mail.intertainservices.com [69.77.177.114]) by mx1.freebsd.org (Postfix) with ESMTP id D31401E2B for ; Thu, 4 Jul 2013 20:48:40 +0000 (UTC) Received: from freebsd.local (unknown [172.16.10.114]) by mail.intertainservices.com (Postfix) with ESMTPSA id C52525643A for ; Thu, 4 Jul 2013 16:48:38 -0400 (EDT) Message-ID: <51D5DFA6.6010202@intertainservices.com> Date: Thu, 04 Jul 2013 16:48:38 -0400 From: Mike Jakubik User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130703 Thunderbird/17.0.7 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: UFS Trim wont stay set References: <51D5CEF8.9000504@intertainservices.com> <20130704203342.GA98181@icarus.home.lan> In-Reply-To: <20130704203342.GA98181@icarus.home.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-intertainservices-MailScanner-Information: Please contact the ISP for more information X-intertainservices-MailScanner-ID: C52525643A.AED7D X-intertainservices-MailScanner: Found to be clean X-intertainservices-MailScanner-From: mike.jakubik@intertainservices.com X-Spam-Status: No 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, 04 Jul 2013 20:48:41 -0000 On 07/04/13 16:33, Jeremy Chadwick wrote: > Yup, experienced this myself many times over. The reasons are > understood (it's not limited to just the TRIM bits, it's related to > anything adjusting the superblock -- it gets cached in memory in > certain situations and not flushed back to disk). Hint: are you > booting into single user and then issuing a "mount" command before > doing your tunefs stuff? If so, this is probably what's causing it (at > least it was in my case). Instead just boot into single-user, do not > mount anything, and use /sbin/tunefs (if available -- depends on your > filesystem setup) or /rescue/tunefs. I booted in to single user mode and the system mounted the only file system there, which is mounted at /. What i did now however is boot off a Live CD and run tunefs, this did the trick! Thank You! From owner-freebsd-stable@FreeBSD.ORG Thu Jul 4 21:01:30 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 0DD2C63A for ; Thu, 4 Jul 2013 21:01:30 +0000 (UTC) (envelope-from jdc@koitsu.org) Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net [217.70.183.195]) by mx1.freebsd.org (Postfix) with ESMTP id BFF711EA2 for ; Thu, 4 Jul 2013 21:01:29 +0000 (UTC) Received: from mfilter19-d.gandi.net (mfilter19-d.gandi.net [217.70.178.147]) by relay3-d.mail.gandi.net (Postfix) with ESMTP id B79EEA80B8; Thu, 4 Jul 2013 23:01:18 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter19-d.gandi.net Received: from relay3-d.mail.gandi.net ([217.70.183.195]) by mfilter19-d.gandi.net (mfilter19-d.gandi.net [10.0.15.180]) (amavisd-new, port 10024) with ESMTP id sudaUjCF6J0S; Thu, 4 Jul 2013 23:01:16 +0200 (CEST) X-Originating-IP: 76.102.14.35 Received: from jdc.koitsu.org (c-76-102-14-35.hsd1.ca.comcast.net [76.102.14.35]) (Authenticated sender: jdc@koitsu.org) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id 4501BA80B0; Thu, 4 Jul 2013 23:01:16 +0200 (CEST) Received: by icarus.home.lan (Postfix, from userid 1000) id 6E83473A1C; Thu, 4 Jul 2013 14:01:14 -0700 (PDT) Date: Thu, 4 Jul 2013 14:01:14 -0700 From: Jeremy Chadwick To: Mike Jakubik Subject: Re: UFS Trim wont stay set Message-ID: <20130704210114.GA98690@icarus.home.lan> References: <51D5CEF8.9000504@intertainservices.com> <20130704203342.GA98181@icarus.home.lan> <51D5DFA6.6010202@intertainservices.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51D5DFA6.6010202@intertainservices.com> 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, 04 Jul 2013 21:01:30 -0000 On Thu, Jul 04, 2013 at 04:48:38PM -0400, Mike Jakubik wrote: > On 07/04/13 16:33, Jeremy Chadwick wrote: > >Yup, experienced this myself many times over. The reasons are > >understood (it's not limited to just the TRIM bits, it's related > >to anything adjusting the superblock -- it gets cached in memory > >in certain situations and not flushed back to disk). Hint: are you > >booting into single user and then issuing a "mount" command before > >doing your tunefs stuff? If so, this is probably what's causing it > >(at least it was in my case). Instead just boot into single-user, > >do not mount anything, and use /sbin/tunefs (if available -- > >depends on your filesystem setup) or /rescue/tunefs. > > I booted in to single user mode and the system mounted the only file > system there, which is mounted at /. What i did now however is boot > off a Live CD and run tunefs, this did the trick! I talked with Andriy Gapon a couple years ago about this, actually. I had to dig up the thread. Here are the relevant parts (read in order): http://lists.freebsd.org/pipermail/freebsd-stable/2011-June/062921.html http://lists.freebsd.org/pipermail/freebsd-stable/2011-June/062922.html http://lists.freebsd.org/pipermail/freebsd-stable/2011-June/062923.html http://lists.freebsd.org/pipermail/freebsd-stable/2011-June/062924.html Make sure you read Andriy's comments (2nd URL) in full. My follow-up (4th URL) confirms that the "mount -a" (which is what made / read-write since /etc/fstab obviously has / as rw) was causing the issue. He explains the reason. -- | Jeremy Chadwick jdc@koitsu.org | | UNIX Systems Administrator http://jdc.koitsu.org/ | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Thu Jul 4 22:01:40 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id C8225A5E for ; Thu, 4 Jul 2013 22:01:40 +0000 (UTC) (envelope-from marek_sal@wp.pl) Received: from mx3.wp.pl (mx3.wp.pl [212.77.101.7]) by mx1.freebsd.org (Postfix) with ESMTP id 516831122 for ; Thu, 4 Jul 2013 22:01:39 +0000 (UTC) Received: (wp-smtpd smtp.wp.pl 1860 invoked from network); 5 Jul 2013 00:01:38 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wp.pl; s=1024a; t=1372975298; bh=uJ0GPhPTvcZ9St9xecSzegPv8XXyo7xt1kzfAFqcXSc=; h=From:To:CC:Subject; b=b1plesOYSHzEpdxwcytvdILhHgAMoPLnWx6yXuqGjP9+AnbtC+0NfJeyrCNFNbQLM dPkdI0miBA47b7U4jj9rwgyIY/ejMp4wB2cidFKaYYHZlkp7Q1WrBfHb9XZgfb+JHD uH7Qrk2bgzAa5365PvG6H+NszuYIZipIWLMB7l5I= Received: from nat.misal.pl (HELO [127.0.0.1]) (marek_sal@[83.19.131.171]) (envelope-sender ) by smtp.wp.pl (WP-SMTPD) with AES256-SHA encrypted SMTP for ; 5 Jul 2013 00:01:38 +0200 Message-ID: <51D5F0A7.3030206@wp.pl> Date: Fri, 05 Jul 2013 00:01:11 +0200 From: Marek Salwerowicz User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Jeremy Chadwick Subject: Re: FREEBSD_INSTALL failed with error 19 during booting installer References: <51CDD465.90706@wp.pl> <20130628182615.GA52467@icarus.home.lan> In-Reply-To: <20130628182615.GA52467@icarus.home.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 130704-1, 2013-07-04), Outbound message X-Antivirus-Status: Clean X-WP-DKIM-Status: good (id: wp.pl) X-WP-AV: skaner antywirusowy poczty Wirtualnej Polski S. A. X-WP-SPAM: NO 0000000 [cfN0] Cc: Marek Salwerowicz , "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, 04 Jul 2013 22:01:40 -0000 W dniu 2013-06-28 20:26, Jeremy Chadwick pisze: > Try using a USB flash drive + memstick image instead of CD-based media. Hi, it worked ;) thanks for help. What's interesting, after upgrading the IPMI software I was even able to Boot CD Image via IPMI virtual DVD and installer worked also. Regards, -- Marek Salwerowicz From owner-freebsd-stable@FreeBSD.ORG Thu Jul 4 23:38:24 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id E4AA5822; Thu, 4 Jul 2013 23:38:24 +0000 (UTC) (envelope-from jdavidlists@gmail.com) Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com [IPv6:2607:f8b0:4001:c03::235]) by mx1.freebsd.org (Postfix) with ESMTP id AF9BE146B; Thu, 4 Jul 2013 23:38:24 +0000 (UTC) Received: by mail-ie0-f181.google.com with SMTP id x12so4167200ief.12 for ; Thu, 04 Jul 2013 16:38: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=IQSkC6IaaIGnuZZi78Ol7EC+grFdWOJoW6D+iXEV3yk=; b=PiZkbioe+LLgkyVZWKAPGGcsgnwSJ4r+9+DQ07v4wCR2IkESO23Ka6PqOog1c30Wwz V5fVhNe9XKudKb7qubhnRwtVbpqpkC+mEbYdjbcY6/du/y3WGAhFPB54pHWezMguSp+T Qqy9zDPaDriKX7XmUyt/WnSPE7jAwDON8lrqZUKaaLkwNMHGx5X8y4WNV6H6xZ1fKwAo debnFLMBSnvMFxxBJ1UlKxEPjDK3C0AIdG1l44KAKOsdGNuMMSO27MU31nZQqaNfP+Br rIBJXQIz5a6ymGnDUefik99qDEO/ttZl5dj/ZdlWyDK1QN3yEbluwwN1WxI/vnWJG5Vk C5yg== MIME-Version: 1.0 X-Received: by 10.50.109.134 with SMTP id hs6mr3620078igb.35.1372981104405; Thu, 04 Jul 2013 16:38:24 -0700 (PDT) Sender: jdavidlists@gmail.com Received: by 10.42.114.73 with HTTP; Thu, 4 Jul 2013 16:38:24 -0700 (PDT) In-Reply-To: References: <2D61560D-E3D9-4558-8715-8215DBBF21D9@FreeBSD.org> Date: Thu, 4 Jul 2013 19:38:24 -0400 X-Google-Sender-Auth: K50Rmo3nGWiecb1zSgLQSJVFWIk Message-ID: Subject: Re: Phantom nulls in usbdevs.h during 9-STABLE kernel build From: J David To: Dimitry Andric Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 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, 04 Jul 2013 23:38:25 -0000 On Thu, Jul 4, 2013 at 12:15 PM, Dimitry Andric wrote: > One other thing: which type of file system are you using for /usr/obj, or > wherever you pointed $MAKEOBJDIRPREFIX? > Also ZFS-over-NFS. The goal is to build on one machine and install on many. I was able to reproduce this with gcc: ===> usb/u3g (all) cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj/usr/src/sys/NFSN32/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -I/usr/obj/usr/src/sys/NFSN32 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /usr/src/sys/modules/usb/u3g/../../../dev/usb/serial/u3g.c In file included from /usr/src/sys/modules/usb/u3g/../../../dev/usb/serial/u3g.c:57: ./usbdevs.h:1362:1: error: null character(s) ignored *** [u3g.o] Error code 1 Thanks! From owner-freebsd-stable@FreeBSD.ORG Fri Jul 5 03:28:34 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 44DE584D; Fri, 5 Jul 2013 03:28:34 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id DC8C51DFC; Fri, 5 Jul 2013 03:28:33 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id r653RsFU021556; Fri, 5 Jul 2013 06:27:54 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua r653RsFU021556 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id r653RsL1021555; Fri, 5 Jul 2013 06:27:54 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 5 Jul 2013 06:27:54 +0300 From: Konstantin Belousov To: J David Subject: Re: Phantom nulls in usbdevs.h during 9-STABLE kernel build Message-ID: <20130705032754.GO91021@kib.kiev.ua> References: <2D61560D-E3D9-4558-8715-8215DBBF21D9@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="PhlAjAiEmthiGzXl" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home 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: Fri, 05 Jul 2013 03:28:34 -0000 --PhlAjAiEmthiGzXl Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jul 04, 2013 at 07:38:24PM -0400, J David wrote: > On Thu, Jul 4, 2013 at 12:15 PM, Dimitry Andric wrote: >=20 > > One other thing: which type of file system are you using for /usr/obj, = or > > wherever you pointed $MAKEOBJDIRPREFIX? > > >=20 > Also ZFS-over-NFS. The goal is to build on one machine and install on ma= ny. >=20 > I was able to reproduce this with gcc: >=20 > =3D=3D=3D> usb/u3g (all) > cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc > -DHAVE_KERNEL_OPTION_HEADERS -include > /usr/obj/usr/src/sys/NFSN32/opt_global.h -I. -I@ -I@/contrib/altq > -finline-limit=3D8000 --param inline-unit-growth=3D100 --param > large-function-growth=3D1000 -fno-common -g -I/usr/obj/usr/src/sys/NFSN32 > -mno-align-long-strings -mpreferred-stack-boundary=3D2 -mno-mmx -mno-sse > -msoft-float -ffreestanding -fstack-protector -std=3Diso9899:1999 > -fstack-protector -Wall -Wredundant-decls -Wnested-externs > -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline > -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions > -Wmissing-include-dirs -fdiagnostics-show-option -c > /usr/src/sys/modules/usb/u3g/../../../dev/usb/serial/u3g.c > In file included from > /usr/src/sys/modules/usb/u3g/../../../dev/usb/serial/u3g.c:57: > ./usbdevs.h:1362:1: error: null character(s) ignored > *** [u3g.o] Error code 1 Try to apply r252528 and see if it helps. --PhlAjAiEmthiGzXl Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iQIcBAEBAgAGBQJR1j06AAoJEJDCuSvBvK1BqS8P/3i4FkFpSVodtwioAvVCEi2K QMWBNWJyMMZJhcwtHRxejP6VSmJD59ygETotNOc6e/n+OA8IVVE/OsHSpGubBPQX socPmuTH5AWAuxUNLZGLR1eHT+1ouV0XrW1ifqONkrEHlMJy5vllL7HzSmUSH2sG 2BANqPOTkxYFU75lJop0v5aw2mQQp77WiuOwumDQ1Mr0w7Uz6/oTrrQjbDS7Gc8E 788szd9/wIAAtW75CrRdGvuTziyAb6XlImI7pXh+6qaD11N+xu5TZaOgUtyPksOK yh4CfRjEFW6SlbRgZcAvOfM/Wyu5RX14Rxgeo2bAfdaLoc99fQ68lEXVm69Mfpvw Fmso4Tk/45mOeB2WMyY7WKjkl7kMwY2xr6CC1xyzhLL6xRubwlAc9Szwv/vmr2IK y32XMevp+lyGPGEMKmorHQyX+G6Ol/fxaQN9SxowZgcRE4N67Qagf7H7hh4qOVIq VlZS6VcN+DKpkjDHFzFbjf753UCs8ZSBV5lR5xvMiabPbTv22mzzurehoaPaXh+B 80PMgmAfjxtepzKN3t4HkK51cm6u4pagpaNc5rTZ1zXMBaoHODi8ePimBKjI3SC3 hcFSTuq+q7lBWGaySMH9O1N5o+jIayJOVRasXgb4X15GW1+b2KiIi4E9eqjSDbgc YCOxIKLOabTCOExk0I6H =2hUN -----END PGP SIGNATURE----- --PhlAjAiEmthiGzXl-- From owner-freebsd-stable@FreeBSD.ORG Fri Jul 5 12:39:05 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id CF278963 for ; Fri, 5 Jul 2013 12:39:05 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [IPv6:2001:7b8:3a7:1:2d0:b7ff:fea0:8c26]) by mx1.freebsd.org (Postfix) with ESMTP id 985811ABC for ; Fri, 5 Jul 2013 12:39:05 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7::55fe:86b3:1ee:6af5] (unknown [IPv6:2001:7b8:3a7:0:55fe:86b3:1ee:6af5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 84CA05C43; Fri, 5 Jul 2013 14:39:03 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: make buildworld is now 50% slower From: Dimitry Andric In-Reply-To: Date: Fri, 5 Jul 2013 14:39:00 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Daniel Braniss X-Mailer: Apple Mail (2.1508) Cc: "freebsd-stable@freebsd.org 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, 05 Jul 2013 12:39:05 -0000 [redirecting to the correct mailing list, freebsd-stable@ ...] On Jul 5, 2013, at 10:53, Daniel Braniss wrote: > after today's update of 9.1-STABLE I noticed that make = build[world|kernel] are > taking conciderable more time, is it because the upgrade of clang? > and if so, is the code produced any better? >=20 > before: > buildwordl: 26m4.52s real 2h28m32.12s user 36m6.27s sys > buildkernel: 7m29.42s real 23m22.22s user 4m26.26s sys >=20 > today: > buildwordl: 34m29.80s real 2h38m9.37s user 37m7.61s sys > buildkernel: 15m31.52s real 22m59.40s user 4m33.06s sys Ehm, your user and sys times are not that much different at all, they add up to about 5% slower for buildworld, and 1% faster for build = kernel. Are you sure nothing else is running on that machine, eating up CPU time while you are building? :) But yes, clang 3.3 is of course somewhat larger than 3.2. You might especially notice that, if you are using gcc, which is very slow at compiling C++. In any case, if you do not care about clang, just set WITHOUT_CLANG=3D = in your /etc/src.conf, and you can shave off some build time. -Dimitry From owner-freebsd-stable@FreeBSD.ORG Fri Jul 5 14:58:55 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 43FCF195; Fri, 5 Jul 2013 14:58:55 +0000 (UTC) (envelope-from jdc@koitsu.org) Received: from relay5-d.mail.gandi.net (relay5-d.mail.gandi.net [217.70.183.197]) by mx1.freebsd.org (Postfix) with ESMTP id 01ADB1105; Fri, 5 Jul 2013 14:58:54 +0000 (UTC) Received: from mfilter24-d.gandi.net (mfilter24-d.gandi.net [217.70.178.152]) by relay5-d.mail.gandi.net (Postfix) with ESMTP id 26C5741C064; Fri, 5 Jul 2013 16:58:44 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter24-d.gandi.net Received: from relay5-d.mail.gandi.net ([217.70.183.197]) by mfilter24-d.gandi.net (mfilter24-d.gandi.net [10.0.15.180]) (amavisd-new, port 10024) with ESMTP id vW1ozTIi4iMK; Fri, 5 Jul 2013 16:58:42 +0200 (CEST) X-Originating-IP: 76.102.14.35 Received: from jdc.koitsu.org (c-76-102-14-35.hsd1.ca.comcast.net [76.102.14.35]) (Authenticated sender: jdc@koitsu.org) by relay5-d.mail.gandi.net (Postfix) with ESMTPSA id 46D9941C06D; Fri, 5 Jul 2013 16:58:41 +0200 (CEST) Received: by icarus.home.lan (Postfix, from userid 1000) id 88A5773A31; Fri, 5 Jul 2013 07:58:39 -0700 (PDT) Date: Fri, 5 Jul 2013 07:58:39 -0700 From: Jeremy Chadwick To: Dimitry Andric Subject: Re: make buildworld is now 50% slower Message-ID: <20130705145839.GB5449@icarus.home.lan> References: 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: "freebsd-stable@freebsd.org 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, 05 Jul 2013 14:58:55 -0000 On Fri, Jul 05, 2013 at 02:39:00PM +0200, Dimitry Andric wrote: > [redirecting to the correct mailing list, freebsd-stable@ ...] > > On Jul 5, 2013, at 10:53, Daniel Braniss wrote: > > after today's update of 9.1-STABLE I noticed that make build[world|kernel] are > > taking conciderable more time, is it because the upgrade of clang? > > and if so, is the code produced any better? > > > > before: > > buildwordl: 26m4.52s real 2h28m32.12s user 36m6.27s sys > > buildkernel: 7m29.42s real 23m22.22s user 4m26.26s sys > > > > today: > > buildwordl: 34m29.80s real 2h38m9.37s user 37m7.61s sys > > buildkernel: 15m31.52s real 22m59.40s user 4m33.06s sys > > Ehm, your user and sys times are not that much different at all, they > add up to about 5% slower for buildworld, and 1% faster for build kernel. > Are you sure nothing else is running on that machine, eating up CPU time > while you are building? :) > > But yes, clang 3.3 is of course somewhat larger than 3.2. You might > especially notice that, if you are using gcc, which is very slow at > compiling C++. > > In any case, if you do not care about clang, just set WITHOUT_CLANG= in > your /etc/src.conf, and you can shave off some build time. I just built world/kernel (stable/9 r252769) 5 hours ago. Results: time make -j4 buildworld = roughly 21 minutes on my hardware time make -j4 buildkernel = roughly 8 minutes on my hardware These numbers are about the norm for me, meaning I do not see a substantial increase in build times. Key point: I do not use/build/grok clang, i.e. WITHOUT_CLANG=true is in my src.conf. But I am aware of the big clang change in r252723. If hardware details are wanted, ask, but I don't think it's relevant to what the root cause is. -- | Jeremy Chadwick jdc@koitsu.org | | UNIX Systems Administrator http://jdc.koitsu.org/ | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Fri Jul 5 20:30:21 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 627E29C5 for ; Fri, 5 Jul 2013 20:30:21 +0000 (UTC) (envelope-from rdeiriar@spock.cl) Received: from mail.spock.cl (enteljoven2.enteljoven.cl [164.77.63.23]) by mx1.freebsd.org (Postfix) with ESMTP id 05DB1115B for ; Fri, 5 Jul 2013 20:30:20 +0000 (UTC) Received: from [10.0.0.110] (190-21-110-26.baf.movistar.cl [190.21.110.26]) (AUTH: PLAIN rdeiriar@spock.cl, TLS: TLSv1/SSLv3,256bits,CAMELLIA256-SHA) by mail.spock.cl with ESMTPSA; Fri, 05 Jul 2013 17:34:54 -0300 id 00000A8E.0000000051D72DEE.0000D3AF Message-ID: <51D72CB4.90108@spock.cl> Date: Fri, 05 Jul 2013 16:29:40 -0400 From: Roberto de Iriarte User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130601 Thunderbird/17.0.6 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: 9.1-STABLE zfsloader failure References: <51D43E20.5020400@spock.cl> In-Reply-To: <51D43E20.5020400@spock.cl> Content-Type: text/plain; charset=ISO-8859-1; 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: Fri, 05 Jul 2013 20:30:21 -0000 I have done some additional research on this, The machine is a MacBook Pro 4,1, the firmware is only able to boot directly to HFS+ formatted GPT partitions. It is able to boot into MBR based partitions (which are labeled "Windows" regardless of type) My disk layout is as follows # /usr/local/sbin/gdisk /dev/ada0 GPT fdisk (gdisk) version 0.8.5 Partition table scan: MBR: protective BSD: not present APM: not present GPT: present Found valid GPT with protective MBR; using GPT. Command (? for help): p Disk /dev/ada0: 625142448 sectors, 298.1 GiB Logical sector size: 512 bytes Disk identifier (GUID): 33EE1EC7-DF42-11E2-95A9-001CB3C56DFB Partition table holds up to 128 entries First usable sector is 34, last usable sector is 625142414 Partitions will be aligned on 8-sector boundaries Total free space is 13 sectors (6.5 KiB) Number Start (sector) End (sector) Size Code Name 1 34 161 64.0 KiB A501 2 168 16777383 8.0 GiB A502 swap0 3 16777384 625142407 290.1 GiB A504 disk0 Partition 1 contains the bootloader and is of type freebsd-boot Partition 2 is of type freebsd-swap Partition 3 is of type freebsd-zfs and contains the root filesystem As described, and with the bootloader installed via gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 ada0 My system is unable to boot by itself directly. It does boot with the help of refit or refind With 9.1-RELEASE, it used to be possible to create an "Hybrid MBR" (http://www.rodsbooks.com/gdisk/hybrid.html) either with refit of gdisk, activate the MBR entry that points to the bootloader and have the system boot directly without refit or refind With the new zfsloader from 9.1-STABLE, the system is still able to be booted from refit or refind, however, if i create the Hybrid MBR, the boot pwouldrocess stops with the message (twice) ZFS: can't find pool by guid ZFS: can't find pool by guid And the install rendered unbootable, either directly or with refit/refind Mounting the disk from a live CD and replacing /boot/zfsloader with the one from 9.1-RELEASE solves the problem (This means i cannot upgrade from ZFS v. 28 to the new feature flags spec ?) I don't know if this behavior qualifies for a problem report ? Thanks Roberto From owner-freebsd-stable@FreeBSD.ORG Sat Jul 6 03:38:09 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 2C7AB64A for ; Sat, 6 Jul 2013 03:38:09 +0000 (UTC) (envelope-from bsd-lists@hush.com) Received: from smtp5.hushmail.com (smtp5a.hushmail.com [65.39.178.235]) by mx1.freebsd.org (Postfix) with ESMTP id 17F4C131D for ; Sat, 6 Jul 2013 03:38:08 +0000 (UTC) Received: from smtp5.hushmail.com (smtp5a.hushmail.com [65.39.178.235]) by smtp5.hushmail.com (Postfix) with SMTP id 176D3600FD for ; Sat, 6 Jul 2013 03:38:08 +0000 (UTC) Received: from smtp.hushmail.com (w6.hushmail.com [65.39.178.92]) by smtp5.hushmail.com (Postfix) with ESMTP for ; Sat, 6 Jul 2013 03:38:08 +0000 (UTC) Received: by smtp.hushmail.com (Postfix, from userid 99) id F008D600EF; Sat, 6 Jul 2013 03:38:07 +0000 (UTC) MIME-Version: 1.0 Date: Fri, 05 Jul 2013 20:38:07 -0700 To: "freebsd-stable" Subject: When will subversion be ready for updating/upgrading src && ports? From: bsd-lists@hush.com In-Reply-To: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="UTF-8" Message-Id: <20130706033807.F008D600EF@smtp.hushmail.com> 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, 06 Jul 2013 03:38:09 -0000 Greetings, Well after posting a couple of questions to the list regarding questions I had before migrating from (cv)sup to subversion, I took the leap: mv /usr/src/ /usr/src.old/ mkdir /usr/src mv /usr/ports/ /usr/ports.old/ mkdir /usr/ports rm -fr /var/db/sup/* rm -fr /var/db/portsnap/* svn checkout svn://svn.freebsd.org/base/stable/8 /usr/src svn checkout svn://svn.freebsd.org/ports/head /usr/ports I then performed a portmaster -a which left me with a non-working X desktop. Turned out to be a problem with the Nvidia driver -- was 2.9.40, now 3.10.14. But loading it in loader.conf didn't create /dev/nvidia0, or /dev/nvidiactl To make a long story short, I attempted to update my src && ports, and try agaiin; svn update svn://svn.freebsd.org/ports/head /usr/ports FAILED! I don't have the exact output So I tried: cd /usr/ports svn update Which replied: svn: E155036: Please see the 'svn upgrade' command svn: E155036: The working copy at '/usr/ports' is too old (format 29) to work with client version '1.8.0 (r1490375)' (expects f ormat 31). You need to upgrade the working copy first. So I guess subversion isn't (yet) designed for this sort of stuff, which leaves me with a useless box. :( Thank you for all your time, and consideration. --chris From owner-freebsd-stable@FreeBSD.ORG Sat Jul 6 03:44:49 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 6989DA08 for ; Sat, 6 Jul 2013 03:44:49 +0000 (UTC) (envelope-from jdc@koitsu.org) Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net [217.70.183.195]) by mx1.freebsd.org (Postfix) with ESMTP id 28E751369 for ; Sat, 6 Jul 2013 03:44:48 +0000 (UTC) Received: from mfilter19-d.gandi.net (mfilter19-d.gandi.net [217.70.178.147]) by relay3-d.mail.gandi.net (Postfix) with ESMTP id 0E47BA80B5; Sat, 6 Jul 2013 05:44:38 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter19-d.gandi.net Received: from relay3-d.mail.gandi.net ([217.70.183.195]) by mfilter19-d.gandi.net (mfilter19-d.gandi.net [10.0.15.180]) (amavisd-new, port 10024) with ESMTP id PFTmVpjn0YVQ; Sat, 6 Jul 2013 05:44:36 +0200 (CEST) X-Originating-IP: 76.102.14.35 Received: from jdc.koitsu.org (c-76-102-14-35.hsd1.ca.comcast.net [76.102.14.35]) (Authenticated sender: jdc@koitsu.org) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id EF324A80B1; Sat, 6 Jul 2013 05:44:35 +0200 (CEST) Received: by icarus.home.lan (Postfix, from userid 1000) id A48DE73A31; Fri, 5 Jul 2013 20:44:33 -0700 (PDT) Date: Fri, 5 Jul 2013 20:44:33 -0700 From: Jeremy Chadwick To: bsd-lists@hush.com Subject: Re: When will subversion be ready for updating/upgrading src && ports? Message-ID: <20130706034433.GA19937@icarus.home.lan> References: <20130706033807.F008D600EF@smtp.hushmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130706033807.F008D600EF@smtp.hushmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) 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: Sat, 06 Jul 2013 03:44:49 -0000 On Fri, Jul 05, 2013 at 08:38:07PM -0700, bsd-lists@hush.com wrote: > Greetings, > Well after posting a couple of questions to the list regarding questions I had before > migrating from (cv)sup to subversion, I took the leap: > > mv /usr/src/ /usr/src.old/ > > mkdir /usr/src > > mv /usr/ports/ /usr/ports.old/ > > mkdir /usr/ports > > rm -fr /var/db/sup/* > rm -fr /var/db/portsnap/* > > svn checkout svn://svn.freebsd.org/base/stable/8 /usr/src > > svn checkout svn://svn.freebsd.org/ports/head /usr/ports > > I then performed a portmaster -a > > which left me with a non-working X desktop. > Turned out to be a problem with the Nvidia driver -- was 2.9.40, now 3.10.14. > But loading it in loader.conf didn't create /dev/nvidia0, or /dev/nvidiactl > To make a long story short, I attempted to update my src && ports, and try agaiin; > > svn update svn://svn.freebsd.org/ports/head /usr/ports > FAILED! I don't have the exact output Incorrect syntax -- should be one of the following (your choice): cd /usr/ports && svn update svn update /usr/ports > So I tried: > cd /usr/ports > svn update > Which replied: > svn: E155036: Please see the 'svn upgrade' command > svn: E155036: The working copy at '/usr/ports' > is too old (format 29) to work with client version '1.8.0 (r1490375)' (expects f > ormat 31). You need to upgrade the working copy first. > > So I guess subversion isn't (yet) designed for this sort of stuff, which leaves me with a useless box. :( Incorrect. Please look very, VERY closely at what the command is that it's telling you to use. Read it 4 times over. Pay close attention. The explanation: You installed subversion 1.7 or earlier when you originally started (i.e. subversion-1.7 or 1.6 or something else was installed). No problem. You then updated your ports tree. No problem. You then ran portmaster -a to upgrade/update all your ports (rebuild them). No problem. However this updated subversion to the latest in ports, which is 1.8. The subversion metadata (stored in the .svn directories, ex. /usr/src/.svn, /usr/ports/.svn, etc.) has changed as of 1.8. This is why you need to do "svn upgrade" in those directories. This is a one-time thing you have to do. That's all. -- | Jeremy Chadwick jdc@koitsu.org | | UNIX Systems Administrator http://jdc.koitsu.org/ | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Sat Jul 6 03:55:35 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 199F5BE1 for ; Sat, 6 Jul 2013 03:55:35 +0000 (UTC) (envelope-from erichsfreebsdlist@alogt.com) Received: from alogt.com (alogt.com [69.36.191.58]) by mx1.freebsd.org (Postfix) with ESMTP id DFDB413AF for ; Sat, 6 Jul 2013 03:55:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=alogt.com; s=default; h=Content-Transfer-Encoding:Content-Type:Mime-Version:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date; bh=kPyd3X48WLdX/9MRe4iLyl3lkhyMNCUAwW3O8icPGlo=; b=KWmcnGMIjZPnIP+8emevMYmwpOPUXCiqMwk48EPGG8z84R5Ve/fnrdoDDxUxyHJeMc3A6p5zbahtiPd6XTNqBjCQa65yljvN0n4cHTFhosbchUWX4UHW2ZOgkU/goezhsCSAaCOtFmfCX7ZIS2e2uC2KBsIrPyn/kGjM+HYRKZk=; Received: from [182.14.13.62] (port=51466 helo=X220.ovitrap.com) by sl-508-2.slc.westdc.net with esmtpsa (SSLv3:DHE-RSA-AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1UvJar-000Eik-SH; Fri, 05 Jul 2013 21:55:31 -0600 Date: Sat, 6 Jul 2013 11:55:23 +0800 From: Erich Dollansky To: bsd-lists@hush.com Subject: Re: When will subversion be ready for updating/upgrading src && ports? Message-ID: <20130706115523.7c6140a9@X220.ovitrap.com> In-Reply-To: <20130706033807.F008D600EF@smtp.hushmail.com> References: <20130706033807.F008D600EF@smtp.hushmail.com> X-Mailer: Claws Mail 3.9.2 (GTK+ 2.24.19; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - sl-508-2.slc.westdc.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - alogt.com X-Get-Message-Sender-Via: sl-508-2.slc.westdc.net: authenticated_id: erichsfreebsdlist@alogt.com X-Source: X-Source-Args: X-Source-Dir: 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: Sat, 06 Jul 2013 03:55:35 -0000 Hi, On Fri, 05 Jul 2013 20:38:07 -0700 bsd-lists@hush.com wrote: > Greetings, > Well after posting a couple of questions to the list regarding > questions I had before migrating from (cv)sup to subversion, I took > the leap: > > mv /usr/src/ /usr/src.old/ > > mkdir /usr/src > > mv /usr/ports/ /usr/ports.old/ > > mkdir /usr/ports > > rm -fr /var/db/sup/* > rm -fr /var/db/portsnap/* > > svn checkout svn://svn.freebsd.org/base/stable/8 /usr/src > > svn checkout svn://svn.freebsd.org/ports/head /usr/ports > > I then performed a portmaster -a > > which left me with a non-working X desktop. > Turned out to be a problem with the Nvidia driver -- was 2.9.40, now > 3.10.14. But loading it in loader.conf didn't create /dev/nvidia0, > or /dev/nvidiactl To make a long story short, I attempted to update > my src && ports, and try agaiin; > > svn update svn://svn.freebsd.org/ports/head /usr/ports > FAILED! I don't have the exact output > So I tried: > cd /usr/ports > svn update > Which replied: > svn: E155036: Please see the 'svn upgrade' command > svn: E155036: The working copy at '/usr/ports' > is too old (format 29) to work with client version '1.8.0 > (r1490375)' (expects f ormat 31). You need to upgrade the working > copy first. you need a big pipe for svn. I also do not understand why a program is not able to handle a format change automatically. > > So I guess subversion isn't (yet) designed for this sort of stuff, > which leaves me with a useless box. :( What did I say a long time ago? It takes time to get this up but not a cut-off date. Erich > > Thank you for all your time, and consideration. > > --chris > > _______________________________________________ > 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 Sat Jul 6 04:00:38 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 4CFFFD29 for ; Sat, 6 Jul 2013 04:00:38 +0000 (UTC) (envelope-from bsd-lists@hush.com) Received: from smtp10.hushmail.com (smtp10a.hushmail.com [65.39.178.239]) by mx1.freebsd.org (Postfix) with ESMTP id 36C11145A for ; Sat, 6 Jul 2013 04:00:37 +0000 (UTC) Received: from smtp10.hushmail.com (smtp10a.hushmail.com [65.39.178.239]) by smtp10.hushmail.com (Postfix) with SMTP id 94034C0236 for ; Sat, 6 Jul 2013 04:00:37 +0000 (UTC) Received: from smtp.hushmail.com (w6.hushmail.com [65.39.178.92]) by smtp10.hushmail.com (Postfix) with ESMTP; Sat, 6 Jul 2013 04:00:37 +0000 (UTC) Received: by smtp.hushmail.com (Postfix, from userid 99) id 3A527600EF; Sat, 6 Jul 2013 04:00:37 +0000 (UTC) MIME-Version: 1.0 Date: Fri, 05 Jul 2013 21:00:36 -0700 To: "Erich Dollansky" Subject: Re: When will subversion be ready for updating/upgrading src && ports? From: bsd-lists@hush.com In-Reply-To: <20130706115523.7c6140a9@X220.ovitrap.com> References: <20130706033807.F008D600EF@smtp.hushmail.com> <20130706115523.7c6140a9@X220.ovitrap.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="UTF-8" Message-Id: <20130706040037.3A527600EF@smtp.hushmail.com> 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: Sat, 06 Jul 2013 04:00:38 -0000 On 07/05/2013 at 8:55 PM, "Erich Dollansky" wrote: > >Hi, > >On Fri, 05 Jul 2013 20:38:07 -0700 >bsd-lists@hush.com wrote: > >> Greetings, >> Well after posting a couple of questions to the list regarding >> questions I had before migrating from (cv)sup to subversion, I >took >> the leap: >> >> mv /usr/src/ /usr/src.old/ >> >> mkdir /usr/src >> >> mv /usr/ports/ /usr/ports.old/ >> >> mkdir /usr/ports >> >> rm -fr /var/db/sup/* >> rm -fr /var/db/portsnap/* >> >> svn checkout svn://svn.freebsd.org/base/stable/8 /usr/src >> >> svn checkout svn://svn.freebsd.org/ports/head /usr/ports >> >> I then performed a portmaster -a >> >> which left me with a non-working X desktop. >> Turned out to be a problem with the Nvidia driver -- was 2.9.40, >now >> 3.10.14. But loading it in loader.conf didn't create >/dev/nvidia0, >> or /dev/nvidiactl To make a long story short, I attempted to >update >> my src && ports, and try agaiin; >> >> svn update svn://svn.freebsd.org/ports/head /usr/ports >> FAILED! I don't have the exact output >> So I tried: >> cd /usr/ports >> svn update >> Which replied: >> svn: E155036: Please see the 'svn upgrade' command >> svn: E155036: The working copy at '/usr/ports' >> is too old (format 29) to work with client version '1.8.0 >> (r1490375)' (expects f ormat 31). You need to upgrade the working >> copy first. > >you need a big pipe for svn. I also do not understand why a >program is >not able to handle a format change automatically. >> >> So I guess subversion isn't (yet) designed for this sort of >stuff, >> which leaves me with a useless box. :( > >What did I say a long time ago? It takes time to get this up but >not a >cut-off date. Grrrr... Memory like yours, should be illegal. :) > >Erich >> >> Thank you for all your time, and consideration. >> >> --chris >> >> _______________________________________________ >> 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 Sat Jul 6 04:00:53 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 46918E1C for ; Sat, 6 Jul 2013 04:00:53 +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 2422C1464 for ; Sat, 6 Jul 2013 04:00:52 +0000 (UTC) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.7/8.14.7) with ESMTP id r6640qtY041881; Fri, 5 Jul 2013 21:00:52 -0700 (PDT) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.7/8.14.7/Submit) id r6640qnD041880; Fri, 5 Jul 2013 21:00:52 -0700 (PDT) (envelope-from david) Date: Fri, 5 Jul 2013 21:00:52 -0700 From: David Wolfskill To: bsd-lists@hush.com Subject: Re: When will subversion be ready for updating/upgrading src && ports? Message-ID: <20130706040052.GA1261@albert.catwhisker.org> References: <20130706033807.F008D600EF@smtp.hushmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="vDpQvD79HZx/5O2q" Content-Disposition: inline In-Reply-To: <20130706033807.F008D600EF@smtp.hushmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) 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: Sat, 06 Jul 2013 04:00:53 -0000 --vDpQvD79HZx/5O2q Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jul 05, 2013 at 08:38:07PM -0700, bsd-lists@hush.com wrote: > ... > svn checkout svn://svn.freebsd.org/ports/head /usr/ports >=20 > I then performed a portmaster -a Prior to updating installed ports, review of ports/UPDATING is more than just a good idea. > which left me with a non-working X desktop. > Turned out to be a problem with the Nvidia driver -- was 2.9.40, now 3.10= =2E14. > But loading it in loader.conf didn't create /dev/nvidia0, or /dev/nvidiac= tl I am using nvidia-driver-310.44_1 successfully. > To make a long story short, I attempted to update my src && ports, and tr= y agaiin; >=20 > svn update svn://svn.freebsd.org/ports/head /usr/ports > FAILED! I don't have the exact output Is /usr/ports a real directly, or a symlink? (In my case, it is a symlink, so I needed to take a bit of evasive action after I updated svn to 1.8.) > So I tried: > cd /usr/ports > svn update > Which replied: > svn: E155036: Please see the 'svn upgrade' command > svn: E155036: The working copy at '/usr/ports' > is too old (format 29) to work with client version '1.8.0 (r1490375)' (ex= pects f > ormat 31). You need to upgrade the working copy first. >=20 > So I guess subversion isn't (yet) designed for this sort of stuff, That's a fairly classic non sequitur. I only have logs for the last year of using SVN to perform 2 update/build/smoke-test cycles/day for each of a couple of machines -- 1 set for stable/9; the other for head. I also update the installed ports under stable/9 (daily). (The two machines are my laptop and a "build machine.") And then I actually use the resulting stable/9 snapshot on my laptop for day-to-day activities -- until the next day, when it's "lather, rinse, repeat." Then there are few machines I only update weekly. Regarding the "svn: E155036: Please see the 'svn upgrade' command ..." message, that means that because you updated svn (probably from 1.7 to 1.8), you need to use the "svn upgrade" command on your previously-created working copies in order to use the new svn command on them. > which leaves me with a useless box. :( >=20 > Thank you for all your time, and consideration. Always set things up so you have a usable fallback. Whether that's by making backups and restoring from them or some other mechanism, that's up to you. (I tend to set machines up to be able to boot from multiple slices, which can be a suitable strategy, but it's certainly not as easy as falling off a log.) You may see my more recent update history on an assortment of machines at . 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. --vDpQvD79HZx/5O2q Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iEYEARECAAYFAlHXlnMACgkQmprOCmdXAD31CQCdEKiHOnWsVeQhOpRJeOO2MF+h 0JYAnixb+B7MTHwrtHysI6GzT1930rk8 =ZLs3 -----END PGP SIGNATURE----- --vDpQvD79HZx/5O2q-- From owner-freebsd-stable@FreeBSD.ORG Sat Jul 6 04:10:51 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id AF397FBF for ; Sat, 6 Jul 2013 04:10:51 +0000 (UTC) (envelope-from bsd-lists@hush.com) Received: from smtp5.hushmail.com (smtp5a.hushmail.com [65.39.178.235]) by mx1.freebsd.org (Postfix) with ESMTP id 8632815D1 for ; Sat, 6 Jul 2013 04:10:51 +0000 (UTC) Received: from smtp5.hushmail.com (smtp5a.hushmail.com [65.39.178.235]) by smtp5.hushmail.com (Postfix) with SMTP id AF15960187 for ; Sat, 6 Jul 2013 04:10:50 +0000 (UTC) Received: from smtp.hushmail.com (w6.hushmail.com [65.39.178.92]) by smtp5.hushmail.com (Postfix) with ESMTP; Sat, 6 Jul 2013 04:10:50 +0000 (UTC) Received: by smtp.hushmail.com (Postfix, from userid 99) id 5588F600FF; Sat, 6 Jul 2013 04:10:50 +0000 (UTC) MIME-Version: 1.0 Date: Fri, 05 Jul 2013 21:10:50 -0700 To: "David Wolfskill" Subject: Re: When will subversion be ready for updating/upgrading src && ports? From: bsd-lists@hush.com In-Reply-To: <20130706040052.GA1261@albert.catwhisker.org> References: <20130706033807.F008D600EF@smtp.hushmail.com> <20130706040052.GA1261@albert.catwhisker.org> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="UTF-8" Message-Id: <20130706041050.5588F600FF@smtp.hushmail.com> 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: Sat, 06 Jul 2013 04:10:51 -0000 Greetings, and thank you for your reply. On 07/05/2013 at 9:00 PM, "David Wolfskill" wrote: > >On Fri, Jul 05, 2013 at 08:38:07PM -0700, bsd-lists@hush.com wrote: >> ... >> svn checkout svn://svn.freebsd.org/ports/head /usr/ports >> >> I then performed a portmaster -a > >Prior to updating installed ports, review of ports/UPDATING is >more than >just a good idea. > >> which left me with a non-working X desktop. >> Turned out to be a problem with the Nvidia driver -- was 2.9.40, >now 3.10.14. >> But loading it in loader.conf didn't create /dev/nvidia0, or >/dev/nvidiactl > >I am using nvidia-driver-310.44_1 successfully. > >> To make a long story short, I attempted to update my src && >ports, and try agaiin; >> >> svn update svn://svn.freebsd.org/ports/head /usr/ports >> FAILED! I don't have the exact output > >Is /usr/ports a real directly, or a symlink? (In my case, it is a >symlink, so I needed to take a bit of evasive action after I >updated svn >to 1.8.) > >> So I tried: >> cd /usr/ports >> svn update >> Which replied: >> svn: E155036: Please see the 'svn upgrade' command >> svn: E155036: The working copy at '/usr/ports' >> is too old (format 29) to work with client version '1.8.0 >(r1490375)' (expects f >> ormat 31). You need to upgrade the working copy first. >> >> So I guess subversion isn't (yet) designed for this sort of >stuff, > >That's a fairly classic non sequitur. > >I only have logs for the last year of using SVN to perform 2 >update/build/smoke-test cycles/day for each of a couple of machines >-- 1 set for stable/9; the other for head. I also update the >installed ports under stable/9 (daily). (The two machines are my >laptop and a "build machine.") And then I actually use the >resulting >stable/9 snapshot on my laptop for day-to-day activities -- until >the next day, when it's "lather, rinse, repeat." > >Then there are few machines I only update weekly. > >Regarding the "svn: E155036: Please see the 'svn upgrade' command >..." >message, that means that because you updated svn (probably from >1.7 to >1.8), you need to use the "svn upgrade" command on your >previously-created working copies in order to use the new svn >command on >them. > >> which leaves me with a useless box. :( >> >> Thank you for all your time, and consideration. > >Always set things up so you have a usable fallback. Whether >that's by >making backups and restoring from them or some other mechanism, >that's >up to you. (I tend to set machines up to be able to boot from >multiple >slices, which can be a suitable strategy, but it's certainly not >as easy >as falling off a log.) My problem here, was two-fold; 1) Every time I was _ready_ to attempt the upgrade, pointyhat was failing on my ARCH (AMD64). 2) and this is the big one; I didn't have enough space to perform a reasonable backup prior. The second reason accounted for all the anxiety I expressed on the list, this time -- sorry. Thanks again, for the reply. --chris > >You may see my more recent update history on an assortment of >machines >at . > >Peace, >david >-- >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. From owner-freebsd-stable@FreeBSD.ORG Sat Jul 6 09:41:31 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id E5F7190; Sat, 6 Jul 2013 09:41:31 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-stable.sentex.ca (freebsd-stable.sentex.ca [IPv6:2607:f3e0:0:3::6502:9b]) by mx1.freebsd.org (Postfix) with ESMTP id 9B7971FA0; Sat, 6 Jul 2013 09:41:31 +0000 (UTC) Received: from freebsd-stable.sentex.ca (localhost [127.0.0.1]) by freebsd-stable.sentex.ca (8.14.5/8.14.5) with ESMTP id r669fUir081932; Sat, 6 Jul 2013 09:41:30 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-stable.sentex.ca (8.14.5/8.14.5/Submit) id r669fUPd081925; Sat, 6 Jul 2013 09:41:30 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 6 Jul 2013 09:41:30 GMT Message-Id: <201307060941.r669fUPd081925@freebsd-stable.sentex.ca> X-Authentication-Warning: freebsd-stable.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_9 tinderbox] failure on i386/i386 Precedence: bulk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jul 2013 09:41:32 -0000 TB --- 2013-07-06 03:25:16 - tinderbox 2.10 running on freebsd-stable.sentex.ca TB --- 2013-07-06 03:25:16 - FreeBSD freebsd-stable.sentex.ca 8.3-STABLE FreeBSD 8.3-STABLE #0: Tue Oct 16 17:37:58 UTC 2012 mdtancsa@freebsd-stable.sentex.ca:/usr/obj/usr/src/sys/server amd64 TB --- 2013-07-06 03:25:16 - starting RELENG_9 tinderbox run for i386/i386 TB --- 2013-07-06 03:25:16 - cleaning the object tree TB --- 2013-07-06 03:25:16 - /usr/local/bin/svn stat /src TB --- 2013-07-06 03:25:22 - At svn revision 252859 TB --- 2013-07-06 03:25:23 - building world TB --- 2013-07-06 03:25:23 - CROSS_BUILD_TESTING=YES TB --- 2013-07-06 03:25:23 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-06 03:25:23 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-06 03:25:23 - SRCCONF=/dev/null TB --- 2013-07-06 03:25:23 - TARGET=i386 TB --- 2013-07-06 03:25:23 - TARGET_ARCH=i386 TB --- 2013-07-06 03:25:23 - TZ=UTC TB --- 2013-07-06 03:25:23 - __MAKE_CONF=/dev/null TB --- 2013-07-06 03:25:23 - cd /src TB --- 2013-07-06 03:25:23 - /usr/bin/make -B buildworld >>> World build started on Sat Jul 6 03:25:23 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sat Jul 6 06:40:06 UTC 2013 TB --- 2013-07-06 06:40:06 - generating LINT kernel config TB --- 2013-07-06 06:40:06 - cd /src/sys/i386/conf TB --- 2013-07-06 06:40:06 - /usr/bin/make -B LINT TB --- 2013-07-06 06:40:06 - cd /src/sys/i386/conf TB --- 2013-07-06 06:40:06 - /usr/sbin/config -m LINT TB --- 2013-07-06 06:40:07 - building LINT kernel TB --- 2013-07-06 06:40:07 - CROSS_BUILD_TESTING=YES TB --- 2013-07-06 06:40:07 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-06 06:40:07 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-06 06:40:07 - SRCCONF=/dev/null TB --- 2013-07-06 06:40:07 - TARGET=i386 TB --- 2013-07-06 06:40:07 - TARGET_ARCH=i386 TB --- 2013-07-06 06:40:07 - TZ=UTC TB --- 2013-07-06 06:40:07 - __MAKE_CONF=/dev/null TB --- 2013-07-06 06:40:07 - cd /src TB --- 2013-07-06 06:40:07 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Jul 6 06:40:07 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT completed on Sat Jul 6 07:21:49 UTC 2013 TB --- 2013-07-06 07:21:49 - cd /src/sys/i386/conf TB --- 2013-07-06 07:21:49 - /usr/sbin/config -m LINT-NOINET TB --- 2013-07-06 07:21:49 - building LINT-NOINET kernel TB --- 2013-07-06 07:21:49 - CROSS_BUILD_TESTING=YES TB --- 2013-07-06 07:21:49 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-06 07:21:49 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-06 07:21:49 - SRCCONF=/dev/null TB --- 2013-07-06 07:21:49 - TARGET=i386 TB --- 2013-07-06 07:21:49 - TARGET_ARCH=i386 TB --- 2013-07-06 07:21:49 - TZ=UTC TB --- 2013-07-06 07:21:49 - __MAKE_CONF=/dev/null TB --- 2013-07-06 07:21:49 - cd /src TB --- 2013-07-06 07:21:49 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET >>> Kernel build for LINT-NOINET started on Sat Jul 6 07:21:49 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT-NOINET completed on Sat Jul 6 08:02:10 UTC 2013 TB --- 2013-07-06 08:02:10 - cd /src/sys/i386/conf TB --- 2013-07-06 08:02:10 - /usr/sbin/config -m LINT-NOINET6 TB --- 2013-07-06 08:02:10 - building LINT-NOINET6 kernel TB --- 2013-07-06 08:02:10 - CROSS_BUILD_TESTING=YES TB --- 2013-07-06 08:02:10 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-06 08:02:10 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-06 08:02:10 - SRCCONF=/dev/null TB --- 2013-07-06 08:02:10 - TARGET=i386 TB --- 2013-07-06 08:02:10 - TARGET_ARCH=i386 TB --- 2013-07-06 08:02:10 - TZ=UTC TB --- 2013-07-06 08:02:10 - __MAKE_CONF=/dev/null TB --- 2013-07-06 08:02:10 - cd /src TB --- 2013-07-06 08:02:10 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET6 >>> Kernel build for LINT-NOINET6 started on Sat Jul 6 08:02:10 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT-NOINET6 completed on Sat Jul 6 08:43:48 UTC 2013 TB --- 2013-07-06 08:43:48 - cd /src/sys/i386/conf TB --- 2013-07-06 08:43:48 - /usr/sbin/config -m LINT-NOIP TB --- 2013-07-06 08:43:48 - building LINT-NOIP kernel TB --- 2013-07-06 08:43:48 - CROSS_BUILD_TESTING=YES TB --- 2013-07-06 08:43:48 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-06 08:43:48 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-06 08:43:48 - SRCCONF=/dev/null TB --- 2013-07-06 08:43:48 - TARGET=i386 TB --- 2013-07-06 08:43:48 - TARGET_ARCH=i386 TB --- 2013-07-06 08:43:48 - TZ=UTC TB --- 2013-07-06 08:43:48 - __MAKE_CONF=/dev/null TB --- 2013-07-06 08:43:48 - cd /src TB --- 2013-07-06 08:43:48 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOIP >>> Kernel build for LINT-NOIP started on Sat Jul 6 08:43:48 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT-NOIP completed on Sat Jul 6 09:22:17 UTC 2013 TB --- 2013-07-06 09:22:17 - cd /src/sys/i386/conf TB --- 2013-07-06 09:22:17 - /usr/sbin/config -m LINT-VIMAGE TB --- 2013-07-06 09:22:17 - building LINT-VIMAGE kernel TB --- 2013-07-06 09:22:17 - CROSS_BUILD_TESTING=YES TB --- 2013-07-06 09:22:17 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-06 09:22:17 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-06 09:22:17 - SRCCONF=/dev/null TB --- 2013-07-06 09:22:17 - TARGET=i386 TB --- 2013-07-06 09:22:17 - TARGET_ARCH=i386 TB --- 2013-07-06 09:22:17 - TZ=UTC TB --- 2013-07-06 09:22:17 - __MAKE_CONF=/dev/null TB --- 2013-07-06 09:22:17 - cd /src TB --- 2013-07-06 09:22:17 - /usr/bin/make -B buildkernel KERNCONF=LINT-VIMAGE >>> Kernel build for LINT-VIMAGE started on Sat Jul 6 09:22:17 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/netinet/sctp_timer.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/netinet/sctp_usrreq.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/netinet/sctputil.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/netinet/tcp_debug.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/netinet/tcp_hostcache.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/netinet/tcp_input.c /src/sys/netinet/tcp_input.c:199: error: expected ',' or ';' before 'static' /src/sys/netinet/tcp_input.c:199: error: 'sysctl___net_inet_tcp_recvspace' undeclared here (not in a function) *** Error code 1 Stop in /obj/i386.i386/src/sys/LINT-VIMAGE. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-07-06 09:41:30 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-07-06 09:41:30 - ERROR: failed to build LINT-VIMAGE kernel TB --- 2013-07-06 09:41:30 - 17081.75 user 1769.73 system 22573.42 real http://tinderbox.freebsd.org/tinderbox-freebsd9-build-RELENG_9-i386-i386.full From owner-freebsd-stable@FreeBSD.ORG Sat Jul 6 10:10:39 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 59D7C7DE; Sat, 6 Jul 2013 10:10:39 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-stable.sentex.ca (freebsd-stable.sentex.ca [IPv6:2607:f3e0:0:3::6502:9b]) by mx1.freebsd.org (Postfix) with ESMTP id EC4D21082; Sat, 6 Jul 2013 10:10:38 +0000 (UTC) Received: from freebsd-stable.sentex.ca (localhost [127.0.0.1]) by freebsd-stable.sentex.ca (8.14.5/8.14.5) with ESMTP id r66AAcRY043993; Sat, 6 Jul 2013 10:10:38 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-stable.sentex.ca (8.14.5/8.14.5/Submit) id r66AAcLb043992; Sat, 6 Jul 2013 10:10:38 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 6 Jul 2013 10:10:38 GMT Message-Id: <201307061010.r66AAcLb043992@freebsd-stable.sentex.ca> X-Authentication-Warning: freebsd-stable.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_9 tinderbox] failure on amd64/amd64 Precedence: bulk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jul 2013 10:10:39 -0000 TB --- 2013-07-06 03:25:16 - tinderbox 2.10 running on freebsd-stable.sentex.ca TB --- 2013-07-06 03:25:16 - FreeBSD freebsd-stable.sentex.ca 8.3-STABLE FreeBSD 8.3-STABLE #0: Tue Oct 16 17:37:58 UTC 2012 mdtancsa@freebsd-stable.sentex.ca:/usr/obj/usr/src/sys/server amd64 TB --- 2013-07-06 03:25:16 - starting RELENG_9 tinderbox run for amd64/amd64 TB --- 2013-07-06 03:25:16 - cleaning the object tree TB --- 2013-07-06 03:25:16 - /usr/local/bin/svn stat /src TB --- 2013-07-06 03:25:22 - At svn revision 252859 TB --- 2013-07-06 03:25:23 - building world TB --- 2013-07-06 03:25:23 - CROSS_BUILD_TESTING=YES TB --- 2013-07-06 03:25:23 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-06 03:25:23 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-06 03:25:23 - SRCCONF=/dev/null TB --- 2013-07-06 03:25:23 - TARGET=amd64 TB --- 2013-07-06 03:25:23 - TARGET_ARCH=amd64 TB --- 2013-07-06 03:25:23 - TZ=UTC TB --- 2013-07-06 03:25:23 - __MAKE_CONF=/dev/null TB --- 2013-07-06 03:25:23 - cd /src TB --- 2013-07-06 03:25:23 - /usr/bin/make -B buildworld >>> World build started on Sat Jul 6 03:25:23 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Sat Jul 6 07:18:18 UTC 2013 TB --- 2013-07-06 07:18:18 - generating LINT kernel config TB --- 2013-07-06 07:18:18 - cd /src/sys/amd64/conf TB --- 2013-07-06 07:18:18 - /usr/bin/make -B LINT TB --- 2013-07-06 07:18:18 - cd /src/sys/amd64/conf TB --- 2013-07-06 07:18:18 - /usr/sbin/config -m LINT TB --- 2013-07-06 07:18:18 - building LINT kernel TB --- 2013-07-06 07:18:18 - CROSS_BUILD_TESTING=YES TB --- 2013-07-06 07:18:18 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-06 07:18:18 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-06 07:18:18 - SRCCONF=/dev/null TB --- 2013-07-06 07:18:18 - TARGET=amd64 TB --- 2013-07-06 07:18:18 - TARGET_ARCH=amd64 TB --- 2013-07-06 07:18:18 - TZ=UTC TB --- 2013-07-06 07:18:18 - __MAKE_CONF=/dev/null TB --- 2013-07-06 07:18:18 - cd /src TB --- 2013-07-06 07:18:18 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Jul 6 07:18:18 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT completed on Sat Jul 6 07:58:28 UTC 2013 TB --- 2013-07-06 07:58:28 - cd /src/sys/amd64/conf TB --- 2013-07-06 07:58:28 - /usr/sbin/config -m LINT-NOINET TB --- 2013-07-06 07:58:28 - building LINT-NOINET kernel TB --- 2013-07-06 07:58:28 - CROSS_BUILD_TESTING=YES TB --- 2013-07-06 07:58:28 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-06 07:58:28 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-06 07:58:28 - SRCCONF=/dev/null TB --- 2013-07-06 07:58:28 - TARGET=amd64 TB --- 2013-07-06 07:58:28 - TARGET_ARCH=amd64 TB --- 2013-07-06 07:58:28 - TZ=UTC TB --- 2013-07-06 07:58:28 - __MAKE_CONF=/dev/null TB --- 2013-07-06 07:58:28 - cd /src TB --- 2013-07-06 07:58:28 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET >>> Kernel build for LINT-NOINET started on Sat Jul 6 07:58:28 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT-NOINET completed on Sat Jul 6 08:36:32 UTC 2013 TB --- 2013-07-06 08:36:32 - cd /src/sys/amd64/conf TB --- 2013-07-06 08:36:32 - /usr/sbin/config -m LINT-NOINET6 TB --- 2013-07-06 08:36:32 - building LINT-NOINET6 kernel TB --- 2013-07-06 08:36:32 - CROSS_BUILD_TESTING=YES TB --- 2013-07-06 08:36:32 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-06 08:36:32 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-06 08:36:32 - SRCCONF=/dev/null TB --- 2013-07-06 08:36:32 - TARGET=amd64 TB --- 2013-07-06 08:36:32 - TARGET_ARCH=amd64 TB --- 2013-07-06 08:36:32 - TZ=UTC TB --- 2013-07-06 08:36:32 - __MAKE_CONF=/dev/null TB --- 2013-07-06 08:36:32 - cd /src TB --- 2013-07-06 08:36:32 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET6 >>> Kernel build for LINT-NOINET6 started on Sat Jul 6 08:36:32 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT-NOINET6 completed on Sat Jul 6 09:16:10 UTC 2013 TB --- 2013-07-06 09:16:10 - cd /src/sys/amd64/conf TB --- 2013-07-06 09:16:10 - /usr/sbin/config -m LINT-NOIP TB --- 2013-07-06 09:16:10 - building LINT-NOIP kernel TB --- 2013-07-06 09:16:10 - CROSS_BUILD_TESTING=YES TB --- 2013-07-06 09:16:10 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-06 09:16:10 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-06 09:16:10 - SRCCONF=/dev/null TB --- 2013-07-06 09:16:10 - TARGET=amd64 TB --- 2013-07-06 09:16:10 - TARGET_ARCH=amd64 TB --- 2013-07-06 09:16:10 - TZ=UTC TB --- 2013-07-06 09:16:10 - __MAKE_CONF=/dev/null TB --- 2013-07-06 09:16:10 - cd /src TB --- 2013-07-06 09:16:10 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOIP >>> Kernel build for LINT-NOIP started on Sat Jul 6 09:16:10 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT-NOIP completed on Sat Jul 6 09:51:49 UTC 2013 TB --- 2013-07-06 09:51:49 - cd /src/sys/amd64/conf TB --- 2013-07-06 09:51:49 - /usr/sbin/config -m LINT-VIMAGE TB --- 2013-07-06 09:51:49 - building LINT-VIMAGE kernel TB --- 2013-07-06 09:51:49 - CROSS_BUILD_TESTING=YES TB --- 2013-07-06 09:51:49 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-06 09:51:49 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-06 09:51:49 - SRCCONF=/dev/null TB --- 2013-07-06 09:51:49 - TARGET=amd64 TB --- 2013-07-06 09:51:49 - TARGET_ARCH=amd64 TB --- 2013-07-06 09:51:49 - TZ=UTC TB --- 2013-07-06 09:51:49 - __MAKE_CONF=/dev/null TB --- 2013-07-06 09:51:49 - cd /src TB --- 2013-07-06 09:51:49 - /usr/bin/make -B buildkernel KERNCONF=LINT-VIMAGE >>> Kernel build for LINT-VIMAGE started on Sat Jul 6 09:51:49 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/netinet/sctp_timer.c cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/netinet/sctp_usrreq.c cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/netinet/sctputil.c cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/netinet/tcp_debug.c cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/netinet/tcp_hostcache.c cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/netinet/tcp_input.c /src/sys/netinet/tcp_input.c:199: error: expected ',' or ';' before 'static' /src/sys/netinet/tcp_input.c:199: error: 'sysctl___net_inet_tcp_recvspace' undeclared here (not in a function) *** Error code 1 Stop in /obj/amd64.amd64/src/sys/LINT-VIMAGE. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-07-06 10:10:38 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-07-06 10:10:38 - ERROR: failed to build LINT-VIMAGE kernel TB --- 2013-07-06 10:10:38 - 18209.15 user 2025.56 system 24321.60 real http://tinderbox.freebsd.org/tinderbox-freebsd9-build-RELENG_9-amd64-amd64.full From owner-freebsd-stable@FreeBSD.ORG Sat Jul 6 19:11:51 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id BB26CD22; Sat, 6 Jul 2013 19:11:51 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-stable.sentex.ca (freebsd-stable.sentex.ca [IPv6:2607:f3e0:0:3::6502:9b]) by mx1.freebsd.org (Postfix) with ESMTP id 734AB10DB; Sat, 6 Jul 2013 19:11:51 +0000 (UTC) Received: from freebsd-stable.sentex.ca (localhost [127.0.0.1]) by freebsd-stable.sentex.ca (8.14.5/8.14.5) with ESMTP id r66JBoi4091139; Sat, 6 Jul 2013 19:11:50 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-stable.sentex.ca (8.14.5/8.14.5/Submit) id r66JBouL091132; Sat, 6 Jul 2013 19:11:50 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 6 Jul 2013 19:11:50 GMT Message-Id: <201307061911.r66JBouL091132@freebsd-stable.sentex.ca> X-Authentication-Warning: freebsd-stable.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_9 tinderbox] failure on i386/i386 Precedence: bulk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jul 2013 19:11:51 -0000 TB --- 2013-07-06 12:55:22 - tinderbox 2.10 running on freebsd-stable.sentex.ca TB --- 2013-07-06 12:55:22 - FreeBSD freebsd-stable.sentex.ca 8.3-STABLE FreeBSD 8.3-STABLE #0: Tue Oct 16 17:37:58 UTC 2012 mdtancsa@freebsd-stable.sentex.ca:/usr/obj/usr/src/sys/server amd64 TB --- 2013-07-06 12:55:22 - starting RELENG_9 tinderbox run for i386/i386 TB --- 2013-07-06 12:55:22 - cleaning the object tree TB --- 2013-07-06 12:56:33 - /usr/local/bin/svn stat /src TB --- 2013-07-06 12:56:40 - At svn revision 252885 TB --- 2013-07-06 12:56:41 - building world TB --- 2013-07-06 12:56:41 - CROSS_BUILD_TESTING=YES TB --- 2013-07-06 12:56:41 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-06 12:56:41 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-06 12:56:41 - SRCCONF=/dev/null TB --- 2013-07-06 12:56:41 - TARGET=i386 TB --- 2013-07-06 12:56:41 - TARGET_ARCH=i386 TB --- 2013-07-06 12:56:41 - TZ=UTC TB --- 2013-07-06 12:56:41 - __MAKE_CONF=/dev/null TB --- 2013-07-06 12:56:41 - cd /src TB --- 2013-07-06 12:56:41 - /usr/bin/make -B buildworld >>> World build started on Sat Jul 6 12:56:44 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sat Jul 6 16:10:49 UTC 2013 TB --- 2013-07-06 16:10:49 - generating LINT kernel config TB --- 2013-07-06 16:10:49 - cd /src/sys/i386/conf TB --- 2013-07-06 16:10:49 - /usr/bin/make -B LINT TB --- 2013-07-06 16:10:49 - cd /src/sys/i386/conf TB --- 2013-07-06 16:10:49 - /usr/sbin/config -m LINT TB --- 2013-07-06 16:10:49 - building LINT kernel TB --- 2013-07-06 16:10:49 - CROSS_BUILD_TESTING=YES TB --- 2013-07-06 16:10:49 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-06 16:10:49 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-06 16:10:49 - SRCCONF=/dev/null TB --- 2013-07-06 16:10:49 - TARGET=i386 TB --- 2013-07-06 16:10:49 - TARGET_ARCH=i386 TB --- 2013-07-06 16:10:49 - TZ=UTC TB --- 2013-07-06 16:10:49 - __MAKE_CONF=/dev/null TB --- 2013-07-06 16:10:49 - cd /src TB --- 2013-07-06 16:10:49 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Jul 6 16:10:49 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT completed on Sat Jul 6 16:52:57 UTC 2013 TB --- 2013-07-06 16:52:57 - cd /src/sys/i386/conf TB --- 2013-07-06 16:52:57 - /usr/sbin/config -m LINT-NOINET TB --- 2013-07-06 16:52:58 - building LINT-NOINET kernel TB --- 2013-07-06 16:52:58 - CROSS_BUILD_TESTING=YES TB --- 2013-07-06 16:52:58 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-06 16:52:58 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-06 16:52:58 - SRCCONF=/dev/null TB --- 2013-07-06 16:52:58 - TARGET=i386 TB --- 2013-07-06 16:52:58 - TARGET_ARCH=i386 TB --- 2013-07-06 16:52:58 - TZ=UTC TB --- 2013-07-06 16:52:58 - __MAKE_CONF=/dev/null TB --- 2013-07-06 16:52:58 - cd /src TB --- 2013-07-06 16:52:58 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET >>> Kernel build for LINT-NOINET started on Sat Jul 6 16:52:58 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT-NOINET completed on Sat Jul 6 17:33:04 UTC 2013 TB --- 2013-07-06 17:33:04 - cd /src/sys/i386/conf TB --- 2013-07-06 17:33:04 - /usr/sbin/config -m LINT-NOINET6 TB --- 2013-07-06 17:33:04 - building LINT-NOINET6 kernel TB --- 2013-07-06 17:33:04 - CROSS_BUILD_TESTING=YES TB --- 2013-07-06 17:33:04 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-06 17:33:04 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-06 17:33:04 - SRCCONF=/dev/null TB --- 2013-07-06 17:33:04 - TARGET=i386 TB --- 2013-07-06 17:33:04 - TARGET_ARCH=i386 TB --- 2013-07-06 17:33:04 - TZ=UTC TB --- 2013-07-06 17:33:04 - __MAKE_CONF=/dev/null TB --- 2013-07-06 17:33:04 - cd /src TB --- 2013-07-06 17:33:04 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET6 >>> Kernel build for LINT-NOINET6 started on Sat Jul 6 17:33:04 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT-NOINET6 completed on Sat Jul 6 18:14:41 UTC 2013 TB --- 2013-07-06 18:14:41 - cd /src/sys/i386/conf TB --- 2013-07-06 18:14:41 - /usr/sbin/config -m LINT-NOIP TB --- 2013-07-06 18:14:41 - building LINT-NOIP kernel TB --- 2013-07-06 18:14:41 - CROSS_BUILD_TESTING=YES TB --- 2013-07-06 18:14:41 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-06 18:14:41 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-06 18:14:41 - SRCCONF=/dev/null TB --- 2013-07-06 18:14:41 - TARGET=i386 TB --- 2013-07-06 18:14:41 - TARGET_ARCH=i386 TB --- 2013-07-06 18:14:41 - TZ=UTC TB --- 2013-07-06 18:14:41 - __MAKE_CONF=/dev/null TB --- 2013-07-06 18:14:41 - cd /src TB --- 2013-07-06 18:14:41 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOIP >>> Kernel build for LINT-NOIP started on Sat Jul 6 18:14:41 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT-NOIP completed on Sat Jul 6 18:52:30 UTC 2013 TB --- 2013-07-06 18:52:30 - cd /src/sys/i386/conf TB --- 2013-07-06 18:52:30 - /usr/sbin/config -m LINT-VIMAGE TB --- 2013-07-06 18:52:30 - building LINT-VIMAGE kernel TB --- 2013-07-06 18:52:30 - CROSS_BUILD_TESTING=YES TB --- 2013-07-06 18:52:30 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-06 18:52:30 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-06 18:52:30 - SRCCONF=/dev/null TB --- 2013-07-06 18:52:30 - TARGET=i386 TB --- 2013-07-06 18:52:30 - TARGET_ARCH=i386 TB --- 2013-07-06 18:52:30 - TZ=UTC TB --- 2013-07-06 18:52:30 - __MAKE_CONF=/dev/null TB --- 2013-07-06 18:52:30 - cd /src TB --- 2013-07-06 18:52:30 - /usr/bin/make -B buildkernel KERNCONF=LINT-VIMAGE >>> Kernel build for LINT-VIMAGE started on Sat Jul 6 18:52:30 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/netinet/sctp_timer.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/netinet/sctp_usrreq.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/netinet/sctputil.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/netinet/tcp_debug.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/netinet/tcp_hostcache.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/netinet/tcp_input.c /src/sys/netinet/tcp_input.c:199: error: expected ',' or ';' before 'static' /src/sys/netinet/tcp_input.c:199: error: 'sysctl___net_inet_tcp_recvspace' undeclared here (not in a function) *** Error code 1 Stop in /obj/i386.i386/src/sys/LINT-VIMAGE. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-07-06 19:11:50 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-07-06 19:11:50 - ERROR: failed to build LINT-VIMAGE kernel TB --- 2013-07-06 19:11:50 - 17027.67 user 1784.09 system 22588.11 real http://tinderbox.freebsd.org/tinderbox-freebsd9-build-RELENG_9-i386-i386.full From owner-freebsd-stable@FreeBSD.ORG Sat Jul 6 19:41:05 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 44790709; Sat, 6 Jul 2013 19:41:05 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-stable.sentex.ca (freebsd-stable.sentex.ca [IPv6:2607:f3e0:0:3::6502:9b]) by mx1.freebsd.org (Postfix) with ESMTP id D70AC11E8; Sat, 6 Jul 2013 19:41:04 +0000 (UTC) Received: from freebsd-stable.sentex.ca (localhost [127.0.0.1]) by freebsd-stable.sentex.ca (8.14.5/8.14.5) with ESMTP id r66Jf4Z3054417; Sat, 6 Jul 2013 19:41:04 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-stable.sentex.ca (8.14.5/8.14.5/Submit) id r66Jf48x054416; Sat, 6 Jul 2013 19:41:04 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 6 Jul 2013 19:41:04 GMT Message-Id: <201307061941.r66Jf48x054416@freebsd-stable.sentex.ca> X-Authentication-Warning: freebsd-stable.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_9 tinderbox] failure on amd64/amd64 Precedence: bulk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jul 2013 19:41:05 -0000 TB --- 2013-07-06 12:55:22 - tinderbox 2.10 running on freebsd-stable.sentex.ca TB --- 2013-07-06 12:55:22 - FreeBSD freebsd-stable.sentex.ca 8.3-STABLE FreeBSD 8.3-STABLE #0: Tue Oct 16 17:37:58 UTC 2012 mdtancsa@freebsd-stable.sentex.ca:/usr/obj/usr/src/sys/server amd64 TB --- 2013-07-06 12:55:22 - starting RELENG_9 tinderbox run for amd64/amd64 TB --- 2013-07-06 12:55:22 - cleaning the object tree TB --- 2013-07-06 12:56:33 - /usr/local/bin/svn stat /src TB --- 2013-07-06 12:56:39 - At svn revision 252885 TB --- 2013-07-06 12:56:41 - building world TB --- 2013-07-06 12:56:41 - CROSS_BUILD_TESTING=YES TB --- 2013-07-06 12:56:41 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-06 12:56:41 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-06 12:56:41 - SRCCONF=/dev/null TB --- 2013-07-06 12:56:41 - TARGET=amd64 TB --- 2013-07-06 12:56:41 - TARGET_ARCH=amd64 TB --- 2013-07-06 12:56:41 - TZ=UTC TB --- 2013-07-06 12:56:41 - __MAKE_CONF=/dev/null TB --- 2013-07-06 12:56:41 - cd /src TB --- 2013-07-06 12:56:41 - /usr/bin/make -B buildworld >>> World build started on Sat Jul 6 12:56:41 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Sat Jul 6 16:48:17 UTC 2013 TB --- 2013-07-06 16:48:17 - generating LINT kernel config TB --- 2013-07-06 16:48:17 - cd /src/sys/amd64/conf TB --- 2013-07-06 16:48:17 - /usr/bin/make -B LINT TB --- 2013-07-06 16:48:17 - cd /src/sys/amd64/conf TB --- 2013-07-06 16:48:17 - /usr/sbin/config -m LINT TB --- 2013-07-06 16:48:17 - building LINT kernel TB --- 2013-07-06 16:48:17 - CROSS_BUILD_TESTING=YES TB --- 2013-07-06 16:48:17 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-06 16:48:17 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-06 16:48:17 - SRCCONF=/dev/null TB --- 2013-07-06 16:48:17 - TARGET=amd64 TB --- 2013-07-06 16:48:17 - TARGET_ARCH=amd64 TB --- 2013-07-06 16:48:17 - TZ=UTC TB --- 2013-07-06 16:48:17 - __MAKE_CONF=/dev/null TB --- 2013-07-06 16:48:17 - cd /src TB --- 2013-07-06 16:48:17 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Jul 6 16:48:18 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT completed on Sat Jul 6 17:28:52 UTC 2013 TB --- 2013-07-06 17:28:52 - cd /src/sys/amd64/conf TB --- 2013-07-06 17:28:52 - /usr/sbin/config -m LINT-NOINET TB --- 2013-07-06 17:28:52 - building LINT-NOINET kernel TB --- 2013-07-06 17:28:52 - CROSS_BUILD_TESTING=YES TB --- 2013-07-06 17:28:52 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-06 17:28:52 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-06 17:28:52 - SRCCONF=/dev/null TB --- 2013-07-06 17:28:52 - TARGET=amd64 TB --- 2013-07-06 17:28:52 - TARGET_ARCH=amd64 TB --- 2013-07-06 17:28:52 - TZ=UTC TB --- 2013-07-06 17:28:52 - __MAKE_CONF=/dev/null TB --- 2013-07-06 17:28:52 - cd /src TB --- 2013-07-06 17:28:52 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET >>> Kernel build for LINT-NOINET started on Sat Jul 6 17:28:52 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT-NOINET completed on Sat Jul 6 18:06:50 UTC 2013 TB --- 2013-07-06 18:06:50 - cd /src/sys/amd64/conf TB --- 2013-07-06 18:06:50 - /usr/sbin/config -m LINT-NOINET6 TB --- 2013-07-06 18:06:50 - building LINT-NOINET6 kernel TB --- 2013-07-06 18:06:50 - CROSS_BUILD_TESTING=YES TB --- 2013-07-06 18:06:50 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-06 18:06:50 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-06 18:06:50 - SRCCONF=/dev/null TB --- 2013-07-06 18:06:50 - TARGET=amd64 TB --- 2013-07-06 18:06:50 - TARGET_ARCH=amd64 TB --- 2013-07-06 18:06:50 - TZ=UTC TB --- 2013-07-06 18:06:50 - __MAKE_CONF=/dev/null TB --- 2013-07-06 18:06:50 - cd /src TB --- 2013-07-06 18:06:50 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET6 >>> Kernel build for LINT-NOINET6 started on Sat Jul 6 18:06:51 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT-NOINET6 completed on Sat Jul 6 18:46:33 UTC 2013 TB --- 2013-07-06 18:46:33 - cd /src/sys/amd64/conf TB --- 2013-07-06 18:46:33 - /usr/sbin/config -m LINT-NOIP TB --- 2013-07-06 18:46:33 - building LINT-NOIP kernel TB --- 2013-07-06 18:46:33 - CROSS_BUILD_TESTING=YES TB --- 2013-07-06 18:46:33 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-06 18:46:33 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-06 18:46:33 - SRCCONF=/dev/null TB --- 2013-07-06 18:46:33 - TARGET=amd64 TB --- 2013-07-06 18:46:33 - TARGET_ARCH=amd64 TB --- 2013-07-06 18:46:33 - TZ=UTC TB --- 2013-07-06 18:46:33 - __MAKE_CONF=/dev/null TB --- 2013-07-06 18:46:33 - cd /src TB --- 2013-07-06 18:46:33 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOIP >>> Kernel build for LINT-NOIP started on Sat Jul 6 18:46:33 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT-NOIP completed on Sat Jul 6 19:22:05 UTC 2013 TB --- 2013-07-06 19:22:05 - cd /src/sys/amd64/conf TB --- 2013-07-06 19:22:05 - /usr/sbin/config -m LINT-VIMAGE TB --- 2013-07-06 19:22:05 - building LINT-VIMAGE kernel TB --- 2013-07-06 19:22:05 - CROSS_BUILD_TESTING=YES TB --- 2013-07-06 19:22:05 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-06 19:22:05 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-06 19:22:05 - SRCCONF=/dev/null TB --- 2013-07-06 19:22:05 - TARGET=amd64 TB --- 2013-07-06 19:22:05 - TARGET_ARCH=amd64 TB --- 2013-07-06 19:22:05 - TZ=UTC TB --- 2013-07-06 19:22:05 - __MAKE_CONF=/dev/null TB --- 2013-07-06 19:22:05 - cd /src TB --- 2013-07-06 19:22:05 - /usr/bin/make -B buildkernel KERNCONF=LINT-VIMAGE >>> Kernel build for LINT-VIMAGE started on Sat Jul 6 19:22:05 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/netinet/sctp_timer.c cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/netinet/sctp_usrreq.c cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/netinet/sctputil.c cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/netinet/tcp_debug.c cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/netinet/tcp_hostcache.c cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/netinet/tcp_input.c /src/sys/netinet/tcp_input.c:199: error: expected ',' or ';' before 'static' /src/sys/netinet/tcp_input.c:199: error: 'sysctl___net_inet_tcp_recvspace' undeclared here (not in a function) *** Error code 1 Stop in /obj/amd64.amd64/src/sys/LINT-VIMAGE. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-07-06 19:41:04 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-07-06 19:41:04 - ERROR: failed to build LINT-VIMAGE kernel TB --- 2013-07-06 19:41:04 - 18184.58 user 2034.72 system 24341.77 real http://tinderbox.freebsd.org/tinderbox-freebsd9-build-RELENG_9-amd64-amd64.full From owner-freebsd-stable@FreeBSD.ORG Sat Jul 6 20:19:37 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 58EC95DD; Sat, 6 Jul 2013 20:19:37 +0000 (UTC) (envelope-from jdavidlists@gmail.com) Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) by mx1.freebsd.org (Postfix) with ESMTP id 1EAC01333; Sat, 6 Jul 2013 20:19:37 +0000 (UTC) Received: by mail-ie0-f171.google.com with SMTP id qd12so7522794ieb.16 for ; Sat, 06 Jul 2013 13:19: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=XYj53Nft/wzoHf4v0BdYQoyrZTdpRBuS3bwslQcOpoE=; b=DeiuS1cHjzy0NAOYGy0Bri+qjd4sjGNBV3WRYwMTrTX1sQhHZ1JjuvoQe9YbIZ1nau PNrsjF7STzDnX7GtGzFn8P2LeON72wn1EhfIYOMAN4BCZKV/ZJVzLNNk9Z7WL23r2PI2 BZQLHJQhsIzzhxbDWK6axt2diUNsHHkpiHHMOh9LfP63tYz1amRCFGg64FyERps4ItiO n6mZfJk0JQWELsGExPhV1dezEfSL71Wt8q9kpwF93MlYBtro4/KbhwO8TiVPDbTsoCNu zQTXQquewOkU9utez5PjrSdpiw/t/aqzBm6Ta+jq9y8S9SX9IeCQyD8gXAZDVksf7Wre SCkA== MIME-Version: 1.0 X-Received: by 10.42.35.140 with SMTP id q12mr1394550icd.9.1373141976730; Sat, 06 Jul 2013 13:19:36 -0700 (PDT) Sender: jdavidlists@gmail.com Received: by 10.42.114.73 with HTTP; Sat, 6 Jul 2013 13:19:36 -0700 (PDT) In-Reply-To: <20130705032754.GO91021@kib.kiev.ua> References: <2D61560D-E3D9-4558-8715-8215DBBF21D9@FreeBSD.org> <20130705032754.GO91021@kib.kiev.ua> Date: Sat, 6 Jul 2013 16:19:36 -0400 X-Google-Sender-Auth: OkrfP-YAa019rq8TimX42cOyTE8 Message-ID: Subject: Re: Phantom nulls in usbdevs.h during 9-STABLE kernel build From: J David To: Konstantin Belousov Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 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: Sat, 06 Jul 2013 20:19:37 -0000 On Thu, Jul 4, 2013 at 11:27 PM, Konstantin Belousov wrote: > Try to apply r252528 and see if it helps. > OK, I svn up'd to get the clang changes and applied this patch as well. (Built tree off of local /usr/obj to avoid hitting the problem while building with the patch.) So far I have built the kernel 4 times with clang on NFS-mounted /usr/obj with no problems, so things seem improved although reading the commit description it sounds more like generalized corruption would result, so I don't really understand why it would crop up so consistently only in this one file. (But it's entirely possible I misunderstood the commit message.) It seems like usbdevs.h gets written once early in the boot process and then never again. So if this is indeed the fix, I wonder what the build does to exercise that bug so frequently. Thanks!