From owner-freebsd-stable@FreeBSD.ORG Sun Apr 12 09:11:43 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B88D32FE for ; Sun, 12 Apr 2015 09:11:43 +0000 (UTC) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6C4B75F8 for ; Sun, 12 Apr 2015 09:11:43 +0000 (UTC) Received: by qkx62 with SMTP id 62so118097702qkx.0 for ; Sun, 12 Apr 2015 02:11:42 -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=twRomF/ilesR7weyBpGBhAyKLTLLVaC6oyteBpfYMLU=; b=zu+kpcf40sIqiGoIIqnOFN3sIZILUNYdvWL8ZzEMgJIsNOH5ZKG/Mo7RQlma1fb/DY OvZbkLgJ13dROfxKDIfMXcVo7Gxm3scEGS1DlyBB053hRaz58DQc1IoipuyY0HcbDH+a SjFvMDM9RJ100RMp3mxAtlZqLEHAjWU7wBzUfsPGVrL8/e3YKC0rK47ZX8m7iK0h8zFD FjvnXWrugwQSUXSCwprnwsFZecQ6s9vcoiz3cltEl3oN5aBs32/otYoRKAJTIc6YSXay W/o41PCzcniEfcWXWvUAjWkgjlaNckYW2Q8FC/7NtZ2+teqqVOpCzvhTS+H4v+VdErli jzNg== MIME-Version: 1.0 X-Received: by 10.140.148.20 with SMTP id 20mr11462302qhu.67.1428829902520; Sun, 12 Apr 2015 02:11:42 -0700 (PDT) Received: by 10.229.182.3 with HTTP; Sun, 12 Apr 2015 02:11:42 -0700 (PDT) Date: Sun, 12 Apr 2015 12:11:42 +0300 Message-ID: Subject: Need help with diagnostics From: Michael BlackHeart To: freebsd-stable Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 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, 12 Apr 2015 09:11:43 -0000 In a log Apr 11 10:10:23 diablo kernel: Q1[ 0] (nseg=2) (DS.V:0xfffffe0121174a00 DS.P:0x2f74a00) I: 168cc117 L:02fc6300 F:0004 Apr 11 10:10:23 diablo kernel: (D[0] = a7174ed2(002c0000), D[1] = 03016000(05c80000) Apr 11 10:10:23 diablo kernel: (D[2] = 00000000(00000000), D[3] = 00000000(00000000) Apr 11 10:10:23 diablo kernel: Seq: 17600 swtry: 0 ADDBAW?: 1 DOBAW?: 1 Apr 11 10:10:23 diablo kernel: 4ba99c7e 407c05fe 6000c000 04348000 00858687 81bf8197 Apr 11 10:10:23 diablo kernel: 000081f1 08f00cf6 709039ce 20000000 00000000 00000000 00000000 Apr 11 10:10:23 diablo kernel: [end] Apr 11 10:10:23 diablo kernel: (DS.V:0xfffffe01211c6300 DS.P:0x2fc6300) I: 168cc117 L:00000000 F:0004 Apr 11 10:10:23 diablo kernel: (D[0] = 29cd87d2(002c0000), D[1] = 81646004(05c80000) Apr 11 10:10:23 diablo kernel: (D[2] = 00000000(00000000), D[3] = 00000000(00000000) Apr 11 10:10:23 diablo kernel: Seq: 17616 swtry: 0 ADDBAW?: 1 DOBAW?: 1 Apr 11 10:10:23 diablo kernel: 4baa709f 403c05fe 4000c000 04348000 00858687 86058572 Apr 11 10:10:23 diablo kernel: 000086c4 08000000 00000000 20000000 00000000 00000000 00000000 Apr 11 10:10:23 diablo kernel: [end] Apr 11 10:10:23 diablo kernel: Q1[ 0] (nseg=2) (DS.V:0xfffffe0121174a00 DS.P:0x2f74a00) I: 168cc117 L:02fc6300 F:0004 Apr 11 10:10:23 diablo kernel: (D[0] = a7174ed2(002c0000), D[1] = 03016000(05c80000) Apr 11 10:10:23 diablo kernel: (D[2] = 00000000(00000000), D[3] = 00000000(00000000) Apr 11 10:10:23 diablo kernel: Seq: 17600 swtry: 1 ADDBAW?: 1 DOBAW?: 1 Apr 11 10:10:23 diablo kernel: 4ba99c7e 407c05fe 6000c000 04348000 00858687 829a825a Apr 11 10:10:23 diablo kernel: 000082ea 08f013ea 709039ce 20000000 00000000 00000000 00000000 Apr 11 10:10:23 diablo kernel: [end] Apr 11 10:10:23 diablo kernel: (DS.V:0xfffffe01211c6300 DS.P:0x2fc6300) I: 168cc117 L:02f48400 F:0004 Apr 11 10:10:23 diablo kernel: (D[0] = 29cd87d2(002c0000), D[1] = 81646004(05c80000) Apr 11 10:10:23 diablo kernel: (D[2] = 00000000(00000000), D[3] = 00000000(00000000) Apr 11 10:10:23 diablo kernel: Seq: 17616 swtry: 1 ADDBAW?: 1 DOBAW?: 1 Apr 11 10:10:23 diablo kernel: 4baaf794 403c05fe 6000c000 04348000 00858687 86058572 Apr 11 10:10:23 diablo kernel: 000086c4 08f00000 00000000 20000000 00000000 00000000 00000000 Apr 11 10:10:23 diablo kernel: [end] Apr 11 10:10:23 diablo kernel: (DS.V:0xfffffe0121148400 DS.P:0x2f48400) I: 168cc117 L:00000000 F:0014 Apr 11 10:10:23 diablo kernel: (D[0] = aebe6dd2(002c0000), D[1] = 7f960804(05c80000) Apr 11 10:10:23 diablo kernel: (D[2] = 00000000(00000000), D[3] = 00000000(00000000) Apr 11 10:10:23 diablo kernel: Seq: 17648 swtry: 0 ADDBAW?: 1 DOBAW?: 1 Apr 11 10:10:23 diablo kernel: 4bac81c2 403c05fe 4000c000 24348000 81858687 80e380d1 Apr 11 10:10:23 diablo kernel: 837a80fc 08000000 00000000 20000000 00000000 00000000 00000000 Apr 11 10:10:23 diablo kernel: [end] Apr 11 10:10:23 diablo kernel: Q1[ 0] (nseg=2) (DS.V:0xfffffe0121174a00 DS.P:0x2f74a00) I: 168cc117 L:02fc6300 F:0004 Apr 11 10:10:23 diablo kernel: (D[0] = a7174ed2(002c0000), D[1] = 03016000(05c80000) Apr 11 10:10:23 diablo kernel: (D[2] = 00000000(00000000), D[3] = 00000000(00000000) Apr 11 10:10:23 diablo kernel: Seq: 17600 swtry: 2 ADDBAW?: 1 DOBAW?: 1 Apr 11 10:10:23 diablo kernel: 4ba99c7e 407c05fe 6000c000 04348000 00858687 852a84ac Apr 11 10:10:23 diablo kernel: 000085cc 08f028c6 709039ce 20000000 00000000 00000000 00000000 Apr 11 10:10:23 diablo kernel: [end] Apr 11 10:10:23 diablo kernel: (DS.V:0xfffffe01211c6300 DS.P:0x2fc6300) I: 168cc117 L:02f48400 F:0004 Apr 11 10:10:23 diablo kernel: (D[0] = 29cd87d2(002c0000), D[1] = 81646004(05c80000) Apr 11 10:10:23 diablo kernel: (D[2] = 00000000(00000000), D[3] = 00000000(00000000) Apr 11 10:10:23 diablo kernel: Seq: 17616 swtry: 2 ADDBAW?: 1 DOBAW?: 1 Apr 11 10:10:23 diablo kernel: 4baaf794 403c05fe 6000c000 04348000 00858687 86058572 Apr 11 10:10:23 diablo kernel: 000086c4 08f00000 00000000 20000000 00000000 00000000 00000000 Apr 11 10:10:23 diablo kernel: [end] Apr 11 10:10:23 diablo kernel: (DS.V:0xfffffe0121148400 DS.P:0x2f48400) I: 168cc117 L:02f3df00 F:0014 Apr 11 10:10:23 diablo kernel: (D[0] = aebe6dd2(002c0000), D[1] = 7f960804(05c80000) Apr 11 10:10:23 diablo kernel: (D[2] = 00000000(00000000), D[3] = 00000000(00000000) Apr 11 10:10:23 diablo kernel: Seq: 17648 swtry: 1 ADDBAW?: 1 DOBAW?: 1 Apr 11 10:10:23 diablo kernel: 4bac63b6 403c05fe 6000c000 24348000 81858687 80e380d1 Apr 11 10:10:23 diablo kernel: 837a80fc 08f00000 00000000 20000000 00000000 00000000 00000000 Apr 11 10:10:23 diablo kernel: [end] Apr 11 10:10:23 diablo kernel: (DS.V:0xfffffe012113df00 DS.P:0x2f3df00) I: 168cc117 L:02f74f00 F:0004 Apr 11 10:10:23 diablo kernel: (D[0] = 832a9cd2(002c0000), D[1] = 1aa35004(05c80000) Apr 11 10:10:23 diablo kernel: (D[2] = 00000000(00000000), D[3] = 00000000(00000000) Apr 11 10:10:23 diablo kernel: Seq: 17696 swtry: 0 ADDBAW?: 1 DOBAW?: 1 Apr 11 10:10:23 diablo kernel: 4bafba32 403c05fe 6000c000 24348000 81858687 80e380d1 Apr 11 10:10:23 diablo kernel: 837a80fc 08f00000 00000000 20000000 00000000 00000000 00000000 Apr 11 10:10:23 diablo kernel: [end] Apr 11 10:10:23 diablo kernel: (DS.V:0xfffffe0121174f00 DS.P:0x2f74f00) I: 168cc117 L:02fd6c00 F:0004 Apr 11 10:10:23 diablo kernel: (D[0] = b59054d2(002c0000), D[1] = 030ef000(05c80000) Apr 11 10:10:23 diablo kernel: (D[2] = 00000000(00000000), D[3] = 00000000(00000000) Apr 11 10:10:23 diablo kernel: Seq: 17712 swtry: 0 ADDBAW?: 1 DOBAW?: 1 Apr 11 10:10:23 diablo kernel: 4bb04a06 403c05fe 6000c000 24348000 81858687 80e380d1 Apr 11 10:10:23 diablo kernel: 837a80fc 08f00000 00000000 20000000 00000000 00000000 00000000 Apr 11 10:10:23 diablo kernel: [end] Apr 11 10:10:23 diablo kernel: (DS.V:0xfffffe01211d6c00 DS.P:0x2fd6c00) I: 168cc117 L:00000000 F:0014 Apr 11 10:10:23 diablo kernel: (D[0] = b66f58d2(002c0000), D[1] = 5332f804(05c80000) Apr 11 10:10:23 diablo kernel: (D[2] = 00000000(00000000), D[3] = 00000000(00000000) Apr 11 10:10:23 diablo kernel: Seq: 17728 swtry: 0 ADDBAW?: 1 DOBAW?: 1 Apr 11 10:10:23 diablo kernel: 4bb13810 403c05fe 4000c000 04348000 00858687 829a825a Apr 11 10:10:23 diablo kernel: 000082ea 08000000 00000000 20000000 00000000 00000000 00000000 Apr 11 10:10:23 diablo kernel: [end] First time I see this and do not know what is it and how to handle it. There's no kernel debug symbols. -- amd_miek Think different. Just superior. From owner-freebsd-stable@FreeBSD.ORG Sun Apr 12 17:57:40 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 826A639E for ; Sun, 12 Apr 2015 17:57:40 +0000 (UTC) Received: from mail2.glyndwr.ac.uk (autodiscover.glyndwr.ac.uk [194.82.118.162]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail2.glyndwr.ac.uk", Issuer "TERENA SSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E2CA9C4 for ; Sun, 12 Apr 2015 17:57:39 +0000 (UTC) Received: from XCH7.wrexham.local ([fe80::4b1:2f4e:799f:2fb]) by XCH2.wrexham.local ([2002:c252:76a2::c252:76a2]) with mapi id 14.03.0224.002; Sun, 12 Apr 2015 18:57:35 +0100 From: Gareth Wyn Roberts To: "freebsd-stable@freebsd.org" Subject: msk msk0 watchdog timeout freeze hang lock stop problem Thread-Topic: msk msk0 watchdog timeout freeze hang lock stop problem Thread-Index: AdB1SJ7I96oMbb9aSL6oKcwiEr6BLQ== Date: Sun, 12 Apr 2015 17:57:34 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [213.122.248.173] Content-Type: multipart/mixed; boundary="_004_A861E9C3B0586445B36C4BB29ABF2DB46B2EA6F7XCH7wrexhamloca_" MIME-Version: 1.0 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 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, 12 Apr 2015 17:57:40 -0000 --_004_A861E9C3B0586445B36C4BB29ABF2DB46B2EA6F7XCH7wrexhamloca_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I've run in to problems using the msk device where initially it works well = enough to set DHCP etc. but stops/freezes as soon as any appreciable networ= k traffic occurs . There are several threads describing similar symptoms ov= er the past two years or more. I've been following several false leads but= have finally found a solution (at least it solves my problem). I'm running a standard FreeBSD 10.1-RELEASE and the NIC is detected as: mskc0: mem 0xfa000000-0xfa003fff i= rq 19 at device 0.0 on pci6 msk0: on msk= c0 msk0: Ethernet address: 00:13:77:e9:df:eb miibus0: on msk0 e1000phy0: PHY 0 on miibus0 e1000phy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT= , 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-ma ster, auto, auto-flow The network worked when using the i386 release, but failed for the amd64 re= lease (as reported previously) which prompted me to disable 64-bit DMA (the= patch for this is attached below). This worked for the first kernel built= but mysteriously failed when another unrelated part of the kernel was chan= ged (a usb driver) and the kernel recompiled. So identical msk driver code= worked in one kernel but not the second! This suggested that alignment dif= ferences between the two kernels were causing the msk driver to fail. Other= s have reported varying behaviour depending on different circumstances. It transpires that changing just one value in the if_mskreg.h file solved a= ll my problems. Subsequently I have not been able to make it fail under he= avy network traffic in either 32-bit or 64-bit mode. I'm working on 10.1-RELEASE source, i.e. if_msk.c revision 262524 and if_ms= kreg.h revision 264442. Here's the patch to if_mskreg.h --- if_mskreg.h-orig 2014-11-11 20:02:58.000000000 +0000 +++ if_mskreg.h 2015-04-12 18:47:20.000000000 +0100 @@ -2179,9 +2179,11 @@ * At first I guessed 8 bytes, the size of a single descriptor, would be * required alignment constraints. But, it seems that Yukon II have 4096 * bytes boundary alignment constraints. + * And it seems that the DMA status region for the Yukon Ultra 2 (88E8057) + * requires 8192 byte alignment to prevent locking. */ #define MSK_RING_ALIGN 4096 -#define MSK_STAT_ALIGN 4096 +#define MSK_STAT_ALIGN 8192 The patches to both files which also implement a MSK_64BIT_DMA_DISABLE flag= are attached. Perhaps the developers would consider committing these as i= t may be useful for future debugging. Gareth. --_004_A861E9C3B0586445B36C4BB29ABF2DB46B2EA6F7XCH7wrexhamloca_ Content-Type: text/x-patch; name="if_mskreg.h.rev264442.diff" Content-Description: if_mskreg.h.rev264442.diff Content-Disposition: attachment; filename="if_mskreg.h.rev264442.diff"; size=603; creation-date="Sun, 12 Apr 2015 17:52:31 GMT"; modification-date="Sun, 12 Apr 2015 17:52:31 GMT" Content-Transfer-Encoding: base64 LS0tIGlmX21za3JlZy5oLW9yaWcJMjAxNC0xMS0xMSAyMDowMjo1OC4wMDAwMDAwMDAgKzAwMDAK KysrIGlmX21za3JlZy5oCTIwMTUtMDQtMTIgMTg6NDc6MjAuMDAwMDAwMDAwICswMTAwCkBAIC0y MTc5LDkgKzIxNzksMTEgQEAKICAqIEF0IGZpcnN0IEkgZ3Vlc3NlZCA4IGJ5dGVzLCB0aGUgc2l6 ZSBvZiBhIHNpbmdsZSBkZXNjcmlwdG9yLCB3b3VsZCBiZQogICogcmVxdWlyZWQgYWxpZ25tZW50 IGNvbnN0cmFpbnRzLiBCdXQsIGl0IHNlZW1zIHRoYXQgWXVrb24gSUkgaGF2ZSA0MDk2CiAgKiBi eXRlcyBib3VuZGFyeSBhbGlnbm1lbnQgY29uc3RyYWludHMuCisgKiBBbmQgaXQgc2VlbXMgdGhh dCB0aGUgRE1BIHN0YXR1cyByZWdpb24gZm9yIHRoZSBZdWtvbiBVbHRyYSAyICg4OEU4MDU3KQor ICogcmVxdWlyZXMgODE5MiBieXRlIGFsaWdubWVudCB0byBwcmV2ZW50IGxvY2tpbmcuCiAgKi8K ICNkZWZpbmUgTVNLX1JJTkdfQUxJR04JNDA5NgotI2RlZmluZQlNU0tfU1RBVF9BTElHTgk0MDk2 CisjZGVmaW5lCU1TS19TVEFUX0FMSUdOCTgxOTIKIAogLyogUnggZGVzY3JpcHRvciBkYXRhIHN0 cnVjdHVyZSAqLwogc3RydWN0IG1za19yeF9kZXNjIHsK --_004_A861E9C3B0586445B36C4BB29ABF2DB46B2EA6F7XCH7wrexhamloca_ Content-Type: text/x-patch; name="if_msk.c.rev262524.dma.diff" Content-Description: if_msk.c.rev262524.dma.diff Content-Disposition: attachment; filename="if_msk.c.rev262524.dma.diff"; size=3748; creation-date="Sun, 12 Apr 2015 17:52:52 GMT"; modification-date="Sun, 12 Apr 2015 17:52:52 GMT" Content-Transfer-Encoding: base64 LS0tIGlmX21zay5jLW9yaWcJMjAxNC0xMS0xMSAyMDowMjo1OC4wMDAwMDAwMDAgKzAwMDAKKysr IGlmX21zay5jCTIwMTUtMDQtMTIgMDI6MTU6MTIuNTUxMDA1MDAwICswMTAwCkBAIC0yMTY0LDgg KzIxNjQsOCBAQAogCWVycm9yID0gYnVzX2RtYV90YWdfY3JlYXRlKAogCQkgICAgYnVzX2dldF9k bWFfdGFnKHNjLT5tc2tfZGV2KSwJLyogcGFyZW50ICovCiAJCSAgICBNU0tfU1RBVF9BTElHTiwg MCwJCS8qIGFsaWdubWVudCwgYm91bmRhcnkgKi8KLQkJICAgIEJVU19TUEFDRV9NQVhBRERSLAkJ LyogbG93YWRkciAqLwotCQkgICAgQlVTX1NQQUNFX01BWEFERFIsCQkvKiBoaWdoYWRkciAqLwor CQkgICAgQlVTX0RNQV9UQUdfTE9XQUREUiwJLyogbG93YWRkciAqLworCQkgICAgQlVTX0RNQV9U QUdfSElHSEFERFIsCS8qIGhpZ2hhZGRyICovCiAJCSAgICBOVUxMLCBOVUxMLAkJCS8qIGZpbHRl ciwgZmlsdGVyYXJnICovCiAJCSAgICBzdGF0X3N6LAkJCS8qIG1heHNpemUgKi8KIAkJICAgIDEs CQkJCS8qIG5zZWdtZW50cyAqLwpAQCAtMjIzNSw4ICsyMjM1LDggQEAKIAllcnJvciA9IGJ1c19k bWFfdGFnX2NyZWF0ZSgKIAkJICAgIGJ1c19nZXRfZG1hX3RhZyhzY19pZi0+bXNrX2lmX2Rldiks CS8qIHBhcmVudCAqLwogCQkgICAgMSwgMCwJCQkvKiBhbGlnbm1lbnQsIGJvdW5kYXJ5ICovCi0J CSAgICBCVVNfU1BBQ0VfTUFYQUREUiwJCS8qIGxvd2FkZHIgKi8KLQkJICAgIEJVU19TUEFDRV9N QVhBRERSLAkJLyogaGlnaGFkZHIgKi8KKwkJICAgIEJVU19ETUFfVEFHX0xPV0FERFIsCS8qIGxv d2FkZHIgKi8KKwkJICAgIEJVU19ETUFfVEFHX0hJR0hBRERSLAkvKiBoaWdoYWRkciAqLwogCQkg ICAgTlVMTCwgTlVMTCwJCQkvKiBmaWx0ZXIsIGZpbHRlcmFyZyAqLwogCQkgICAgQlVTX1NQQUNF X01BWFNJWkVfMzJCSVQsCS8qIG1heHNpemUgKi8KIAkJICAgIDAsCQkJCS8qIG5zZWdtZW50cyAq LwpAQCAtMjI1Miw4ICsyMjUyLDggQEAKIAkvKiBDcmVhdGUgdGFnIGZvciBUeCByaW5nLiAqLwog CWVycm9yID0gYnVzX2RtYV90YWdfY3JlYXRlKHNjX2lmLT5tc2tfY2RhdGEubXNrX3BhcmVudF90 YWcsLyogcGFyZW50ICovCiAJCSAgICBNU0tfUklOR19BTElHTiwgMCwJCS8qIGFsaWdubWVudCwg Ym91bmRhcnkgKi8KLQkJICAgIEJVU19TUEFDRV9NQVhBRERSLAkJLyogbG93YWRkciAqLwotCQkg ICAgQlVTX1NQQUNFX01BWEFERFIsCQkvKiBoaWdoYWRkciAqLworCQkgICAgQlVTX0RNQV9UQUdf TE9XQUREUiwJLyogbG93YWRkciAqLworCQkgICAgQlVTX0RNQV9UQUdfSElHSEFERFIsCS8qIGhp Z2hhZGRyICovCiAJCSAgICBOVUxMLCBOVUxMLAkJCS8qIGZpbHRlciwgZmlsdGVyYXJnICovCiAJ CSAgICBNU0tfVFhfUklOR19TWiwJCS8qIG1heHNpemUgKi8KIAkJICAgIDEsCQkJCS8qIG5zZWdt ZW50cyAqLwpAQCAtMjI3MCw4ICsyMjcwLDggQEAKIAkvKiBDcmVhdGUgdGFnIGZvciBSeCByaW5n LiAqLwogCWVycm9yID0gYnVzX2RtYV90YWdfY3JlYXRlKHNjX2lmLT5tc2tfY2RhdGEubXNrX3Bh cmVudF90YWcsLyogcGFyZW50ICovCiAJCSAgICBNU0tfUklOR19BTElHTiwgMCwJCS8qIGFsaWdu bWVudCwgYm91bmRhcnkgKi8KLQkJICAgIEJVU19TUEFDRV9NQVhBRERSLAkJLyogbG93YWRkciAq LwotCQkgICAgQlVTX1NQQUNFX01BWEFERFIsCQkvKiBoaWdoYWRkciAqLworCQkgICAgQlVTX0RN QV9UQUdfTE9XQUREUiwJLyogbG93YWRkciAqLworCQkgICAgQlVTX0RNQV9UQUdfSElHSEFERFIs CS8qIGhpZ2hhZGRyICovCiAJCSAgICBOVUxMLCBOVUxMLAkJCS8qIGZpbHRlciwgZmlsdGVyYXJn ICovCiAJCSAgICBNU0tfUlhfUklOR19TWiwJCS8qIG1heHNpemUgKi8KIAkJICAgIDEsCQkJCS8q IG5zZWdtZW50cyAqLwpAQCAtMjI4OCw4ICsyMjg4LDggQEAKIAkvKiBDcmVhdGUgdGFnIGZvciBU eCBidWZmZXJzLiAqLwogCWVycm9yID0gYnVzX2RtYV90YWdfY3JlYXRlKHNjX2lmLT5tc2tfY2Rh dGEubXNrX3BhcmVudF90YWcsLyogcGFyZW50ICovCiAJCSAgICAxLCAwLAkJCS8qIGFsaWdubWVu dCwgYm91bmRhcnkgKi8KLQkJICAgIEJVU19TUEFDRV9NQVhBRERSLAkJLyogbG93YWRkciAqLwot CQkgICAgQlVTX1NQQUNFX01BWEFERFIsCQkvKiBoaWdoYWRkciAqLworCQkgICAgQlVTX0RNQV9U QUdfTE9XQUREUiwJLyogbG93YWRkciAqLworCQkgICAgQlVTX0RNQV9UQUdfSElHSEFERFIsCS8q IGhpZ2hhZGRyICovCiAJCSAgICBOVUxMLCBOVUxMLAkJCS8qIGZpbHRlciwgZmlsdGVyYXJnICov CiAJCSAgICBNU0tfVFNPX01BWFNJWkUsCQkvKiBtYXhzaXplICovCiAJCSAgICBNU0tfTUFYVFhT RUdTLAkJLyogbnNlZ21lbnRzICovCkBAIC0yMzEzLDggKzIzMTMsOCBAQAogCS8qIENyZWF0ZSB0 YWcgZm9yIFJ4IGJ1ZmZlcnMuICovCiAJZXJyb3IgPSBidXNfZG1hX3RhZ19jcmVhdGUoc2NfaWYt Pm1za19jZGF0YS5tc2tfcGFyZW50X3RhZywvKiBwYXJlbnQgKi8KIAkJICAgIHJ4YWxpZ24sIDAs CQkJLyogYWxpZ25tZW50LCBib3VuZGFyeSAqLwotCQkgICAgQlVTX1NQQUNFX01BWEFERFIsCQkv KiBsb3dhZGRyICovCi0JCSAgICBCVVNfU1BBQ0VfTUFYQUREUiwJCS8qIGhpZ2hhZGRyICovCisJ CSAgICBCVVNfRE1BX1RBR19MT1dBRERSLAkvKiBsb3dhZGRyICovCisJCSAgICBCVVNfRE1BX1RB R19ISUdIQUREUiwJLyogaGlnaGFkZHIgKi8KIAkJICAgIE5VTEwsIE5VTEwsCQkJLyogZmlsdGVy LCBmaWx0ZXJhcmcgKi8KIAkJICAgIE1DTEJZVEVTLAkJCS8qIG1heHNpemUgKi8KIAkJICAgIDEs CQkJCS8qIG5zZWdtZW50cyAqLwpAQCAtMjQyNCw4ICsyNDI0LDggQEAKIAkvKiBDcmVhdGUgdGFn IGZvciBqdW1ibyBSeCByaW5nLiAqLwogCWVycm9yID0gYnVzX2RtYV90YWdfY3JlYXRlKHNjX2lm LT5tc2tfY2RhdGEubXNrX3BhcmVudF90YWcsLyogcGFyZW50ICovCiAJCSAgICBNU0tfUklOR19B TElHTiwgMCwJCS8qIGFsaWdubWVudCwgYm91bmRhcnkgKi8KLQkJICAgIEJVU19TUEFDRV9NQVhB RERSLAkJLyogbG93YWRkciAqLwotCQkgICAgQlVTX1NQQUNFX01BWEFERFIsCQkvKiBoaWdoYWRk ciAqLworCQkgICAgQlVTX0RNQV9UQUdfTE9XQUREUiwJLyogbG93YWRkciAqLworCQkgICAgQlVT X0RNQV9UQUdfSElHSEFERFIsCS8qIGhpZ2hhZGRyICovCiAJCSAgICBOVUxMLCBOVUxMLAkJCS8q IGZpbHRlciwgZmlsdGVyYXJnICovCiAJCSAgICBNU0tfSlVNQk9fUlhfUklOR19TWiwJLyogbWF4 c2l6ZSAqLwogCQkgICAgMSwJCQkJLyogbnNlZ21lbnRzICovCkBAIC0yNDQ5LDggKzI0NDksOCBA QAogCS8qIENyZWF0ZSB0YWcgZm9yIGp1bWJvIFJ4IGJ1ZmZlcnMuICovCiAJZXJyb3IgPSBidXNf ZG1hX3RhZ19jcmVhdGUoc2NfaWYtPm1za19jZGF0YS5tc2tfcGFyZW50X3RhZywvKiBwYXJlbnQg Ki8KIAkJICAgIHJ4YWxpZ24sIDAsCQkJLyogYWxpZ25tZW50LCBib3VuZGFyeSAqLwotCQkgICAg QlVTX1NQQUNFX01BWEFERFIsCQkvKiBsb3dhZGRyICovCi0JCSAgICBCVVNfU1BBQ0VfTUFYQURE UiwJCS8qIGhpZ2hhZGRyICovCisJCSAgICBCVVNfRE1BX1RBR19MT1dBRERSLAkvKiBsb3dhZGRy ICovCisJCSAgICBCVVNfRE1BX1RBR19ISUdIQUREUiwJLyogaGlnaGFkZHIgKi8KIAkJICAgIE5V TEwsIE5VTEwsCQkJLyogZmlsdGVyLCBmaWx0ZXJhcmcgKi8KIAkJICAgIE1KVU05QllURVMsCQkJ LyogbWF4c2l6ZSAqLwogCQkgICAgMSwJCQkJLyogbnNlZ21lbnRzICovCg== --_004_A861E9C3B0586445B36C4BB29ABF2DB46B2EA6F7XCH7wrexhamloca_ Content-Type: text/x-patch; name="if_mskreg.h.rev264442.dma.diff" Content-Description: if_mskreg.h.rev264442.dma.diff Content-Disposition: attachment; filename="if_mskreg.h.rev264442.dma.diff"; size=1533; creation-date="Sun, 12 Apr 2015 17:53:17 GMT"; modification-date="Sun, 12 Apr 2015 17:53:17 GMT" Content-Transfer-Encoding: base64 LS0tIGlmX21za3JlZy5oLW9yaWcJMjAxNC0xMS0xMSAyMDowMjo1OC4wMDAwMDAwMDAgKzAwMDAK KysrIGlmX21za3JlZy5oCTIwMTUtMDQtMTIgMTM6MTc6MjguMDAwMDAwMDAwICswMTAwCkBAIC0y MTc5LDkgKzIxNzksMTEgQEAKICAqIEF0IGZpcnN0IEkgZ3Vlc3NlZCA4IGJ5dGVzLCB0aGUgc2l6 ZSBvZiBhIHNpbmdsZSBkZXNjcmlwdG9yLCB3b3VsZCBiZQogICogcmVxdWlyZWQgYWxpZ25tZW50 IGNvbnN0cmFpbnRzLiBCdXQsIGl0IHNlZW1zIHRoYXQgWXVrb24gSUkgaGF2ZSA0MDk2CiAgKiBi eXRlcyBib3VuZGFyeSBhbGlnbm1lbnQgY29uc3RyYWludHMuCisgKiBBbmQgaXQgc2VlbXMgdGhh dCB0aGUgRE1BIHN0YXR1cyByZWdpb24gZm9yIHRoZSBZdWtvbiBVbHRyYSAyICg4OEU4MDU3KQor ICogcmVxdWlyZXMgODE5MiBieXRlIGFsaWdubWVudCB0byBwcmV2ZW50IGxvY2tpbmcuCiAgKi8K ICNkZWZpbmUgTVNLX1JJTkdfQUxJR04JNDA5NgotI2RlZmluZQlNU0tfU1RBVF9BTElHTgk0MDk2 CisjZGVmaW5lCU1TS19TVEFUX0FMSUdOCTgxOTIKIAogLyogUnggZGVzY3JpcHRvciBkYXRhIHN0 cnVjdHVyZSAqLwogc3RydWN0IG1za19yeF9kZXNjIHsKQEAgLTIzMjcsMTUgKzIzMjksMjkgQEAK ICAqIGFsbG9jYXRlcyA1MCUgbW9yZSB0b3RhbCBUWCBidWZmZXJzIG9uIHBsYXRmb3JtcyB0aGF0 IHN1cHBvcnQgNjRiaXQKICAqIERNQS4KICAqLworI3VuZGVmIE1TS182NEJJVF9ETUFfRElTQUJM RQkJLyogRGVmaW5lIHRvIHVzZSAzMmJpdCBETUEgb24gNjRiaXQgaGFyZHdhcmUgKi8KICNpZiAo QlVTX1NQQUNFX01BWEFERFIgPiAweEZGRkZGRkZGKQorI2lmbmRlZiBNU0tfNjRCSVRfRE1BX0RJ U0FCTEUKICNkZWZpbmUJTVNLXzY0QklUX0RNQQogI2RlZmluZSBNU0tfVFhfUklOR19DTlQJCTM4 NAogI2RlZmluZSBNU0tfUlhfUklOR19DTlQJCTUxMgorI2RlZmluZSBCVVNfRE1BX1RBR19MT1dB RERSIEJVU19TUEFDRV9NQVhBRERSCisjZGVmaW5lIEJVU19ETUFfVEFHX0hJR0hBRERSIEJVU19T UEFDRV9NQVhBRERSCiAjZWxzZQogI3VuZGVmCU1TS182NEJJVF9ETUEKICNkZWZpbmUgTVNLX1RY X1JJTkdfQ05UCQkyNTYKICNkZWZpbmUgTVNLX1JYX1JJTkdfQ05UCQkyNTYKKyNkZWZpbmUgQlVT X0RNQV9UQUdfTE9XQUREUiBCVVNfU1BBQ0VfTUFYQUREUl8zMkJJVAorI2RlZmluZSBCVVNfRE1B X1RBR19ISUdIQUREUiBCVVNfU1BBQ0VfTUFYQUREUgogI2VuZGlmCisjZWxzZQorI3VuZGVmCU1T S182NEJJVF9ETUEKKyNkZWZpbmUgTVNLX1RYX1JJTkdfQ05UCQkyNTYKKyNkZWZpbmUgTVNLX1JY X1JJTkdfQ05UCQkyNTYKKyNkZWZpbmUgQlVTX0RNQV9UQUdfTE9XQUREUiBCVVNfU1BBQ0VfTUFY QUREUgorI2RlZmluZSBCVVNfRE1BX1RBR19ISUdIQUREUiBCVVNfU1BBQ0VfTUFYQUREUgorI2Vu ZGlmCisKICNkZWZpbmUJTVNLX1JYX0JVRl9BTElHTgk4CiAjZGVmaW5lIE1TS19KVU1CT19SWF9S SU5HX0NOVAlNU0tfUlhfUklOR19DTlQKICNkZWZpbmUgTVNLX01BWFRYU0VHUwkJMzUK --_004_A861E9C3B0586445B36C4BB29ABF2DB46B2EA6F7XCH7wrexhamloca_-- From owner-freebsd-stable@FreeBSD.ORG Sun Apr 12 18:27:57 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0A533A37 for ; Sun, 12 Apr 2015 18:27:57 +0000 (UTC) Received: from home.opsec.eu (home.opsec.eu [IPv6:2001:14f8:200::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B918F5E6 for ; Sun, 12 Apr 2015 18:27:56 +0000 (UTC) Received: from pi by home.opsec.eu with local (Exim 4.85 (FreeBSD)) (envelope-from ) id 1YhMbt-000D1c-LL; Sun, 12 Apr 2015 20:27:57 +0200 Date: Sun, 12 Apr 2015 20:27:57 +0200 From: Kurt Jaeger To: Gareth Wyn Roberts Subject: Re: msk msk0 watchdog timeout freeze hang lock stop problem Message-ID: <20150412182757.GC2743@home.opsec.eu> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Cc: "freebsd-stable@freebsd.org" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 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, 12 Apr 2015 18:27:57 -0000 Hi! > I've run in to problems using the msk device [...] > I'm working on 10.1-RELEASE source, i.e. if_msk.c revision 262524 and if_mskreg.h revision 264442. > > Here's the patch to if_mskreg.h [...] Thanks for the suggested fix. There are five PRs, all describe similar things: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197887 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197002 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=189404 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=186872 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=166727 I added some pointer to your posting, maybe someone can test it ? -- pi@opsec.eu +49 171 3101372 5 years to go ! From owner-freebsd-stable@FreeBSD.ORG Mon Apr 13 01:25:50 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CAA1922E; Mon, 13 Apr 2015 01:25:50 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id B47B32C5; Mon, 13 Apr 2015 01:25:50 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id AE3E5D0; Mon, 13 Apr 2015 01:25:50 +0000 (UTC) Date: Mon, 13 Apr 2015 01:25:49 +0000 (GMT) From: jenkins-admin@freebsd.org To: jenkins-admin@FreeBSD.org, freebsd-stable@freebsd.org, jpaetzel@FreeBSD.org, kib@FreeBSD.org, markj@FreeBSD.org, dchagin@FreeBSD.org Message-ID: <1114399441.0.1428888350093.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build is back to normal : FreeBSD_stable_10 #1341 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Instance-Identity: MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkKKb2VAfYQKfu1t7qk4nR5qzUBEI+UqT4BPec4qHVhqUy0FFdq50sMH+3y9bCDNOufctov6VqTNffZ3YXArnZK95YF0OX97fh+E9txYOUX1adc+TikcKjuYpHmL5dE62eaZTI+4A5jnRonskQ1PaoIFz0Kbu4mWzkFsmdiXTraGzomXq4cHUCATA2+K4eDYgjXEQI30z3GOMmmZ4t/+6QGk1cMb/BqMWHbn80AsRCb4tU7Hpd72XLDpsuO7YRP1Q0CjmNAuBOTj+sFiiOe6U9HpqOlQN+iFUvBdZo/ybuy5Kh71cAaYQNL68cYdZJ6binH/DkG3KY/fS7DFYAeuwjwIDAQAB X-Jenkins-Job: FreeBSD_stable_10 X-Jenkins-Result: SUCCESS X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 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, 13 Apr 2015 01:25:50 -0000 See From owner-freebsd-stable@FreeBSD.ORG Mon Apr 13 08:13:57 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B0D9324A for ; Mon, 13 Apr 2015 08:13:57 +0000 (UTC) Received: from mail-pd0-x22d.google.com (mail-pd0-x22d.google.com [IPv6:2607:f8b0:400e:c02::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 77B9F1C0 for ; Mon, 13 Apr 2015 08:13:57 +0000 (UTC) Received: by pddn5 with SMTP id n5so99431804pdd.2 for ; Mon, 13 Apr 2015 01:13:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=9O9MMaMffkammEGiGk269Tv1g87K6p1iYwQVT3tOV/E=; b=h9AB225anKOtw6T3OuJVODt4CkmdBg5kHPZ9QxGK/EOn2vmBCz6fdd1YHCZvTYJdnX 6mobYQTU0Jo4YtDWMpUB748IIDyF9bL1FUd8gI2kK2Nq+P5fuWIQuoTR8kSSW1I2qvqK kC7mDGZJk9xl4T+mWW8QEN0k/yDa0e9zgchDm+40MsbB7OjRLlK10yH4wY/vPQ4y33Z6 g0oqu9dHdFpdJFziXNCApvePGryuErSfxlwkTvaFG3hyfrcGKc3xGvj7HU2S5sDOFJ3a g16X/C+n1Nz/Ow27WLsOctT28IfJmHC5fMsdt5OducMBxTP2pagseOYfdxNcAkFEtmku 1seQ== X-Received: by 10.66.193.72 with SMTP id hm8mr24420983pac.24.1428912836965; Mon, 13 Apr 2015 01:13:56 -0700 (PDT) Received: from pyunyh@gmail.com ([106.247.248.2]) by mx.google.com with ESMTPSA id c16sm6421070pdl.61.2015.04.13.01.13.53 (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 13 Apr 2015 01:13:55 -0700 (PDT) From: Yonghyeon PYUN X-Google-Original-From: "Yonghyeon PYUN" Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Mon, 13 Apr 2015 17:13:48 +0900 Date: Mon, 13 Apr 2015 17:13:48 +0900 To: Gareth Wyn Roberts Subject: Re: msk msk0 watchdog timeout freeze hang lock stop problem Message-ID: <20150413081348.GA965@michelle.fasterthan.com> Reply-To: pyunyh@gmail.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: "freebsd-stable@freebsd.org" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 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, 13 Apr 2015 08:13:57 -0000 On Sun, Apr 12, 2015 at 05:57:34PM +0000, Gareth Wyn Roberts wrote: > I've run in to problems using the msk device where initially it works well enough to set DHCP etc. but stops/freezes as soon as any appreciable network traffic occurs . There are several threads describing similar symptoms over the past two years or more. I've been following several false leads but have finally found a solution (at least it solves my problem). > > I'm running a standard FreeBSD 10.1-RELEASE and the NIC is detected as: > > mskc0: mem 0xfa000000-0xfa003fff irq 19 at device 0.0 on pci6 > msk0: on mskc0 > msk0: Ethernet address: 00:13:77:e9:df:eb > miibus0: on msk0 > e1000phy0: PHY 0 on miibus0 > e1000phy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-ma > ster, auto, auto-flow > > The network worked when using the i386 release, but failed for the amd64 release (as reported previously) which prompted me to disable 64-bit DMA (the patch for this is attached below). This worked for the first kernel built but mysteriously failed when another unrelated part of the kernel was changed (a usb driver) and the kernel recompiled. So identical msk driver code worked in one kernel but not the second! This suggested that alignment differences between the two kernels were causing the msk driver to fail. Others have reported varying behaviour depending on different circumstances. > > It transpires that changing just one value in the if_mskreg.h file solved all my problems. Subsequently I have not been able to make it fail under heavy network traffic in either 32-bit or 64-bit mode. > I'm working on 10.1-RELEASE source, i.e. if_msk.c revision 262524 and if_mskreg.h revision 264442. Thanks for letting me know your findings. I really appreciate that. I recall that the alignment requirement of status LEs(List Elements in Marvell terms) is 2048 and the maximum size of the status LEs is 4096 bytes(Actual alignment seems to be much lower value like 32 or 64 bytes, but alignment 2048 is chosen to avoid silicon bugs). Later experiments showed some variants of Yukon II require 4096 bytes alignment and I changed the alignment to 4096 in the past. It seems your finding indicates msk(4) needs 8192 alignment for status LEs. However this does not explain how and why the same code in 8.x/9.x works well. In addition, it's not common to require alignment size greater than PAGE_SIZE on x86 given that the maximum size of DMA buffer is 4096 bytes. I have to check whether there was a change in bus_dma(9) between 8.x/9.x and 10.x but it needs more time due to lack of spare time. Probably you can verify the DMA address of status LEs meets the following requirements both on i386 and amd64. - Alignment is 4096. - Number of DMA segment is 1. - DMA segment base address plus DMA segment size does not cross a PAGE_SIZE boundary. > > Here's the patch to if_mskreg.h > --- if_mskreg.h-orig 2014-11-11 20:02:58.000000000 +0000 > +++ if_mskreg.h 2015-04-12 18:47:20.000000000 +0100 > @@ -2179,9 +2179,11 @@ > * At first I guessed 8 bytes, the size of a single descriptor, would be > * required alignment constraints. But, it seems that Yukon II have 4096 > * bytes boundary alignment constraints. > + * And it seems that the DMA status region for the Yukon Ultra 2 (88E8057) > + * requires 8192 byte alignment to prevent locking. > */ > #define MSK_RING_ALIGN 4096 > -#define MSK_STAT_ALIGN 4096 > +#define MSK_STAT_ALIGN 8192 > > > The patches to both files which also implement a MSK_64BIT_DMA_DISABLE flag are attached. Perhaps the developers would consider committing these as it may be useful for future debugging. > If you have more than 4GB memory installed and disables 64bit DMA addressing, msk(4) shall use bounce buffers. Passing packets through bounce buffers involves copy operation and it costs a lot. You can check hw.busdma sysctl node to see whether there are drivers that use bounce buffers. And if you want to disable 64bit DMA on 64bit architectures, add '#undef MSK_64BIT_DMA' just below BUS_SPACE_MAXADDR check in if_mskreg.h. From owner-freebsd-stable@FreeBSD.ORG Mon Apr 13 08:59:07 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 25664F64 for ; Mon, 13 Apr 2015 08:59:07 +0000 (UTC) Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9A272875 for ; Mon, 13 Apr 2015 08:59:06 +0000 (UTC) Received: by laat2 with SMTP id t2so52127822laa.1 for ; Mon, 13 Apr 2015 01:59:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=aVs4gqkx42ey1EcRerTjl+Sag/5V+gVc64K4JoNswbU=; b=EoMABiBkHOf4Yr9Zt64h0NRwzx+IfACyPCzEoVutgjO4wbnb58DzP0uV4fEVr638R2 uviBAZwOK7JdJGDmgjuPzVDAuZ7ciZcgM1RkHWVmrsM+tLZbboV7p+gaMmnpAyndXZnZ 7AZ2/4pImrNrBCO5FchheN9tlKhtR/Uv3kS5tWWGeaVaafpvGeaouNFVx/Y+HNeSiy4m +saNdtX5QAVulVb6DOmcEsSF0+w2W4mIHU7ctcdQbhumAFe6LLe1NAWa+7ipCOijmbs4 yYshjgrV77jzp+Ggw2lrql2hVqrOkZZdayeGbkVFRWBco0nyNhyKziV73IIZDlAMHM0Y owBQ== X-Received: by 10.153.5.36 with SMTP id cj4mr12192693lad.69.1428915544587; Mon, 13 Apr 2015 01:59:04 -0700 (PDT) Received: from [192.168.2.192] ([78.84.244.14]) by mx.google.com with ESMTPSA id k15sm1501556laa.28.2015.04.13.01.59.03 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Apr 2015 01:59:03 -0700 (PDT) Message-ID: <552B8556.9080402@gmail.com> Date: Mon, 13 Apr 2015 11:59:02 +0300 From: Alnis Morics User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Icedove/31.5.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: msk msk0 watchdog timeout freeze hang lock stop problem Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 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, 13 Apr 2015 08:59:07 -0000 Hm... I patched if_msk.c with if_msk.c.rev262524.dma.diff (attachment-001.bin) and if_mskreg.h with if_mskreg.h.rev264442.dma.diff (attachment-002.bin), and nothing changed: scp'ing 50 MB soon got "stalled" and ended up with "broken pipe", as it was before. I have 10.1-RELEASE-p9 amd64 pciconf -lv: [..] mskc0@pci0:9:0:0: class=0x020000 card=0xc072144d chip=0x435411ab rev=0x00 hdr=0x00 vendor = 'Marvell Technology Group Ltd.' device = '88E8040 PCI-E Fast Ethernet Controller' class = network subclass = ethernet Alnis From owner-freebsd-stable@FreeBSD.ORG Mon Apr 13 12:36:10 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9AABA380; Mon, 13 Apr 2015 12:36:10 +0000 (UTC) Received: from local.wintek.com (local.wintek.com [72.12.201.234]) by mx1.freebsd.org (Postfix) with ESMTP id 66CE81CF; Mon, 13 Apr 2015 12:36:10 +0000 (UTC) Received: from rjk.wintek.local (172.28.1.248) by local.wintek.com (172.28.1.234) with Microsoft SMTP Server id 8.3.342.0; Mon, 13 Apr 2015 08:36:28 -0400 Message-ID: <552BB833.6080505@wintek.com> Date: Mon, 13 Apr 2015 08:36:03 -0400 From: Richard Kuhns User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:36.0) Gecko/20100101 Firefox/36.0 SeaMonkey/2.33.1 MIME-Version: 1.0 To: Dimitry Andric Subject: Re: Problem building world (amd64) this morning References: <5527D3FC.3000003@wintek.com> <20150410145529.GH15644@albert.catwhisker.org> <9B3B9CA5-2B7E-407E-98EA-285F86D30BEF@cs.huji.ac.il> <20150410181818.GL1394@zxy.spb.ru> <20FD13EA-9A24-41B8-A0A3-19F5EDC8FB4E@odo.in-berlin.de> <41483D80-FC3C-46B7-8121-9DD9D122B01E@FreeBSD.org> <5BA239A6-596E-422E-AC46-15D83CA7C880@odo.in-berlin.de> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Cc: "freebsd-stable@freebsd.org" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 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, 13 Apr 2015 12:36:10 -0000 On 04/10/15 16:42, Dimitry Andric wrote: > On 10 Apr 2015, at 21:32, Michael Grimm wrote: >> >> Dimitry Andric wrote: >> >>> On 10 Apr 2015, at 20:55, Michael Grimm wrote: >> >>>> I can confirm that. r281288 compiles without failing, r281289 fails. >>> >>> I've tried all possible ways of reproducing this problem, but it always >>> works for me. Can somebody who experiences the problem please do a >>> clean build using script(1), and post the full build log somewhere? >>> Preferably a make buildworld without -j, so commands are not >>> interspersed. >> >> Compilation at r281289 is on its way. I'll send you a link after completion. > > Thanks, but you can stop that compilation now. :) I finally managed to > reproduce the problem, and it turns out I also had to MFC r272814 and > r272815, which I have done in r281382. That should really fix it > properly... Sorry for the breakage. > > -Dimitry > Checking back in after being offline for a couple of days, I find it's fixed :-) Many thanks! -- Richard Kuhns Main Number: 765-742-8428 Wintek Corporation Direct: 765-269-8541 427 N 6th Street Internet Support: 765-269-8503 Lafayette, IN 47901-2211 Consulting: 765-269-8504 From owner-freebsd-stable@FreeBSD.ORG Mon Apr 13 15:59:11 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CF948E5B; Mon, 13 Apr 2015 15:59:11 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id BBADAE0B; Mon, 13 Apr 2015 15:59:11 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 2AD0E26D; Mon, 13 Apr 2015 15:59:10 +0000 (UTC) Date: Mon, 13 Apr 2015 15:59:08 +0000 (GMT) From: jenkins-admin@freebsd.org To: jenkins-admin@FreeBSD.org, freebsd-stable@freebsd.org Message-ID: <1881763265.10.1428940748681.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build is back to normal : FreeBSD_stable_9 #737 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Instance-Identity: MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkKKb2VAfYQKfu1t7qk4nR5qzUBEI+UqT4BPec4qHVhqUy0FFdq50sMH+3y9bCDNOufctov6VqTNffZ3YXArnZK95YF0OX97fh+E9txYOUX1adc+TikcKjuYpHmL5dE62eaZTI+4A5jnRonskQ1PaoIFz0Kbu4mWzkFsmdiXTraGzomXq4cHUCATA2+K4eDYgjXEQI30z3GOMmmZ4t/+6QGk1cMb/BqMWHbn80AsRCb4tU7Hpd72XLDpsuO7YRP1Q0CjmNAuBOTj+sFiiOe6U9HpqOlQN+iFUvBdZo/ybuy5Kh71cAaYQNL68cYdZJ6binH/DkG3KY/fS7DFYAeuwjwIDAQAB X-Jenkins-Job: FreeBSD_stable_9 X-Jenkins-Result: SUCCESS X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 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, 13 Apr 2015 15:59:11 -0000 See From owner-freebsd-stable@FreeBSD.ORG Mon Apr 13 21:33:11 2015 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E1B201A5 for ; Mon, 13 Apr 2015 21:33:11 +0000 (UTC) Received: from woozle.rinet.ru (woozle.rinet.ru [195.54.192.68]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 60D2BC2C for ; Mon, 13 Apr 2015 21:33:10 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by woozle.rinet.ru (8.14.5/8.14.5) with ESMTP id t3DLWeVh049732 for ; Tue, 14 Apr 2015 00:32:40 +0300 (MSK) (envelope-from marck@rinet.ru) Date: Tue, 14 Apr 2015 00:32:40 +0300 (MSK) From: Dmitry Morozovsky To: freebsd-stable@FreeBSD.org Subject: [GEOM] Disk IO error when resyncing gmirror -> massive hang in D state Message-ID: 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]); Tue, 14 Apr 2015 00:32:40 +0300 (MSK) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 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, 13 Apr 2015 21:33:12 -0000 Dear colleagues, unfortunately, the machine in question is in productin, so I have no clear reproduce case. I do have console logs, however. prerequisites: - rather fresh stable/10, amd64, SuperMicro MicroCloud 1150, X10SLD-F/HF - su+j ufs2 on top of gmirror of two SATA Toshiba drives - one disk died some time ago, so gmirror works in degraded state trouble: - inserted new drive, labelled, started gmirror resync - apparently remaining drive also has read issues: (ada0:ahcich1:0:0:0): READ_FPDMA_QUEUED. ACB: 60 00 10 b2 c3 40 01 00 00 01 00 00 (ada0:ahcich1:0:0:0): CAM status: ATA Status Error (ada0:ahcich1:0:0:0): ATA status: 41 (DRDY ERR), error: 40 (UNC ) (ada0:ahcich1:0:0:0): RES: 41 40 04 b3 c3 40 01 00 00 00 01 (ada0:ahcich1:0:0:0): Error 5, Retries exhausted GEOM_MIRROR: Request failed (error=5). ada0a[READ(offset=6566445056, length=131072)] GEOM_MIRROR: Synchronization request failed (error=5). mirror/m0a[READ(offset=6566445056, length=131072)] at this point, all requests to disk I/O are stalled, all cron jobs, syslogd, dchpd, etc. Situation reproduce itself at least two times, then as an emergency new drive had been labelled independently and rsynced over. Any thoughts? Thanks in advance! -- 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 Tue Apr 14 20:05:05 2015 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 12CE6C82; Tue, 14 Apr 2015 20:05:05 +0000 (UTC) Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A9B73931; Tue, 14 Apr 2015 20:05:04 +0000 (UTC) Received: by wgsk9 with SMTP id k9so24265063wgs.3; Tue, 14 Apr 2015 13:05:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:subject:message-id:mime-version:content-type :content-disposition:user-agent; bh=1Kc5ZyEd0dzHb/d00SGHgJafzsn6eCFUrGIL5RFgnx8=; b=iZfMbOMqMe4WYmXLCue3tHWsLyTEoyp4TbgPboLnWZ8BxoS3R5IpBZN5KzfixqEs+c 5KN2S1b9MsSjqp4XpIzKyMvkkLiJ0jy3aQMkjF/18FluO1sJrUYTo0ipIJyq7X3Em1Ae Trn3PObnXhN4PvOsHwQP0zPl8YcsyahansM2H01HeY+xb0dEBs4jIhBvRlWa0vkPdfJN +g8fLWwjT9leWn2GKkBxsmkBBW+Ns31as2kRyDBNZoLLv55Ehb0BFXz46O70Cm7wQgoY TaykIppp7r3ciouX0GuS20J6TrCbfWJuLVbhWu2KgrnLVBFTS8YaN0muAmy/hUcWEDQs yU9g== X-Received: by 10.180.105.193 with SMTP id go1mr34484947wib.92.1429041903056; Tue, 14 Apr 2015 13:05:03 -0700 (PDT) Received: from ivaldir.etoilebsd.net ([2001:41d0:8:db4c::1]) by mx.google.com with ESMTPSA id b1sm2953600wjs.17.2015.04.14.13.05.01 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 14 Apr 2015 13:05:02 -0700 (PDT) Sender: Baptiste Daroussin Date: Tue, 14 Apr 2015 22:05:00 +0200 From: Baptiste Daroussin To: ports@FreeBSD.org, current@FreeBSD.org, stable@FreeBSD.org Subject: pkg 1.5.0 is out Message-ID: <20150414200459.GE39658@ivaldir.etoilebsd.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="o0ZfoUVt4BxPQnbU" Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 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, 14 Apr 2015 20:05:05 -0000 --o0ZfoUVt4BxPQnbU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi all, Final pkg 1.5.0 has been released. What happened since pkg 1.4.0: - Initial provides/requires support - Lots of new regression tests have been added - Initial support for OS X - Initial support for NetBSD/EdgeBSD - Update most of the bundled third party software has been updated to their latest version - Improve the messages reported by pkg - Properly support file flags - Implement argument support for custom keywords - Extend setting credential via plist to allow to set file flags - Make credential syntax via plist more flexible allow to only defines the first - pkg updating now supports case insensitive matching - pkg create now support a verbose mode - Add an option to change the default on question, until now the default answer was "No" with that option set it would be "Yes" - Lots of fixes to pkg audit -r - Global memory usage reduction and speed up - Improvements and cleanup on pkg alias - pkg annotate --show --all has been fixed - Make pkg.h C++ friendly - Lots of improvements in the solver - Lots of fixes on 32 bits platforms - Add support for: pkg create -M ./plop.ucl -p ./plop.plist - New pkg -r that will install in the given rootdir without chrooting - Export PKG_ROOTDIR to scripts allow to make them as portable as possible - Stop trying to remove all installed package with the argument of pkg delete is a local file - Be more explicit about why the solver it going to reinstall, remove or upgrade (when possible) - Plenty of bug fixes - Plenty of new bugs - pkg shlibs now support -q - pkg lock gained a new --has-locked-packages option - pkg now resumes fetch if possible - CONSERVATIVE_UPGRADE is now on by default - pkg alias now have a -l argument to list aliases - A sample pkg.conf is now installed with a bunch of aliases set by default - Fix the backup script to properly export an sql which will be importable via pkg shell and/or sqlite out of box I would like to thank anyone that has been contributing to pkg to make this release happen (via code, bug report, feature request, testing and documentation) For pkg 1.6.0 among other things and depending on the time, here is what we do plan to work on: - Safe cherry-picking of upgrades (aka: pkg upgrade something) - New context dependant messages: * messages that only appears during upgrades * messages that only appears on deinstall * messages that only appears on install - Extend provides/requires to support flexible dependencies - Linux package backend (?) - Allow multiple versions of a given package in a repo - Add more regression tests - Improve documentation - Best regards, Bapt --o0ZfoUVt4BxPQnbU Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlUtcusACgkQ8kTtMUmk6Ey6TwCdEzriE+H3YlQpvVXMZBGK7EVh xJoAnR67p5YXrGpXH9+tl7yikv81D21M =DpPp -----END PGP SIGNATURE----- --o0ZfoUVt4BxPQnbU-- From owner-freebsd-stable@FreeBSD.ORG Tue Apr 14 20:19:13 2015 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 536474DA; Tue, 14 Apr 2015 20:19:13 +0000 (UTC) Received: from mail-ob0-x233.google.com (mail-ob0-x233.google.com [IPv6:2607:f8b0:4003:c01::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 16556A8F; Tue, 14 Apr 2015 20:19:13 +0000 (UTC) Received: by obbeb7 with SMTP id eb7so9337384obb.3; Tue, 14 Apr 2015 13:19:12 -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=+wEhbdoDs6jcrKt7eLbUK75Vf6z22nrx5BmYbjy8hbU=; b=K04XxLB6tm8H+n0RRScYqVbrf61di/5ApaObDa/7VJdY2xzIj6mXuXdpW27jNst4eW AoTgG3dg0a0R8930FMvhzBFSLQ0mGd454sC4EULMHnLURmrJFwSRRc3nhoUKUk3DIhot qntJthega3BTS4nQPmrbC4/36rUZSo2rKcDRsNc1NHWcaRvQmNfL1A0QcP6PuH4CA0HI lze7gF9zieYNGeC6izJXt95fnXb6iNktXZ8H32pXlNjAWXvGaePxXP8S2OndO4hNmqxF gfMP+5jmMupVlDlshSj02GSscsADLiGTrnlxAqRPmwMMOxdAZuZRjQSnkqxrc3D6ivEP przw== MIME-Version: 1.0 X-Received: by 10.182.66.79 with SMTP id d15mr18023053obt.58.1429042752343; Tue, 14 Apr 2015 13:19:12 -0700 (PDT) Received: by 10.182.72.4 with HTTP; Tue, 14 Apr 2015 13:19:12 -0700 (PDT) In-Reply-To: <20150414200459.GE39658@ivaldir.etoilebsd.net> References: <20150414200459.GE39658@ivaldir.etoilebsd.net> Date: Tue, 14 Apr 2015 23:19:12 +0300 Message-ID: Subject: Re: pkg 1.5.0 is out From: Mikhail Tsatsenko To: Baptiste Daroussin Cc: "freebsd-ports@freebsd.org" , current@freebsd.org, "freebsd-stable@freebsd.org Stable" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 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, 14 Apr 2015 20:19:13 -0000 2015-04-14 23:05 GMT+03:00 Baptiste Daroussin : > Hi all, Hi, thanks for your great work! > > Final pkg 1.5.0 has been released. > > What happened since pkg 1.4.0: > - Initial provides/requires support > - Lots of new regression tests have been added > - Initial support for OS X > - Initial support for NetBSD/EdgeBSD > - Update most of the bundled third party software has been updated to their > latest version > - Improve the messages reported by pkg > - Properly support file flags > - Implement argument support for custom keywords > - Extend setting credential via plist to allow to set file flags > - Make credential syntax via plist more flexible allow to only defines the first > - pkg updating now supports case insensitive matching > - pkg create now support a verbose mode > - Add an option to change the default on question, until now the default answer > was "No" with that option set it would be "Yes" > - Lots of fixes to pkg audit -r > - Global memory usage reduction and speed up > - Improvements and cleanup on pkg alias > - pkg annotate --show --all has been fixed > - Make pkg.h C++ friendly > - Lots of improvements in the solver > - Lots of fixes on 32 bits platforms > - Add support for: pkg create -M ./plop.ucl -p ./plop.plist > - New pkg -r that will install in the given rootdir without chrooting > - Export PKG_ROOTDIR to scripts allow to make them as portable as possible > - Stop trying to remove all installed package with the argument of pkg delete is > a local file > - Be more explicit about why the solver it going to reinstall, remove or upgrade > (when possible) > - Plenty of bug fixes > - Plenty of new bugs > - pkg shlibs now support -q > - pkg lock gained a new --has-locked-packages option > - pkg now resumes fetch if possible > - CONSERVATIVE_UPGRADE is now on by default > - pkg alias now have a -l argument to list aliases > - A sample pkg.conf is now installed with a bunch of aliases set by default > - Fix the backup script to properly export an sql which will be importable via > pkg shell and/or sqlite out of box > > I would like to thank anyone that has been contributing to pkg to make this > release happen (via code, bug report, feature request, testing and documentation) > > For pkg 1.6.0 among other things and depending on the time, here is what we do > plan to work on: > - Safe cherry-picking of upgrades (aka: pkg upgrade something) > - New context dependant messages: > * messages that only appears during upgrades > * messages that only appears on deinstall > * messages that only appears on install > - Extend provides/requires to support flexible dependencies > - Linux package backend (?) > - Allow multiple versions of a given package in a repo > - Add more regression tests > - Improve documentation > - > > Best regards, > Bapt -- Mikhail From owner-freebsd-stable@FreeBSD.ORG Tue Apr 14 20:35:02 2015 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7F87EA16; Tue, 14 Apr 2015 20:35:02 +0000 (UTC) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0A4FFCBE; Tue, 14 Apr 2015 20:35:02 +0000 (UTC) Received: by wiun10 with SMTP id n10so36253738wiu.1; Tue, 14 Apr 2015 13:35: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=wVIhNfnulk4Nph/NxcxCrpgegoUIldDSDv6DuJgG4mU=; b=nREPt4luRYyYC5llSJtyGOWy5qqgzzy3o3OEkysTeuH4XT67PyOYzedDZz+eaL8TLC fmHdRHjbLoATp8zMJGMGC74LAKS0GXtbumojMky+dE5G4e8l2xUIYdeGUUJwWDsDFDlR ek41jyRrOCJYOYOKNrGYhKyZ9vUUYGQEfPwajQu24Jan0Bl3NF63thxW57yqHnKECSbq ndZLQLA/CtgRDosJWjhrRxXmMxQdx9goNGis4H0+viAw5Z4qzMhp6qN9j3APbrs3gmYA LettHefGFJHgOxQDgH9xpxyyNMNdaScd/bRO/Xg1s/8hykj2n++3mEJkvctox7pxfPri Hewg== MIME-Version: 1.0 X-Received: by 10.180.105.136 with SMTP id gm8mr36342880wib.13.1429043700494; Tue, 14 Apr 2015 13:35:00 -0700 (PDT) Received: by 10.180.44.172 with HTTP; Tue, 14 Apr 2015 13:34:59 -0700 (PDT) Received: by 10.180.44.172 with HTTP; Tue, 14 Apr 2015 13:34:59 -0700 (PDT) In-Reply-To: References: <20150414200459.GE39658@ivaldir.etoilebsd.net> Date: Tue, 14 Apr 2015 22:34:59 +0200 Message-ID: Subject: Re: pkg 1.5.0 is out From: =?UTF-8?Q?Fernando_Apestegu=C3=ADa?= To: Mikhail Tsatsenko Cc: current@freebsd.org, Baptiste Daroussin , "freebsd-stable@freebsd.org Stable" , "freebsd-ports@freebsd.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 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, 14 Apr 2015 20:35:02 -0000 El 14/04/2015 22:19, "Mikhail Tsatsenko" escribi=C3= =B3: > > 2015-04-14 23:05 GMT+03:00 Baptiste Daroussin : > > Hi all, > Hi, > thanks for your great work! +1 > > > > Final pkg 1.5.0 has been released. > > > > What happened since pkg 1.4.0: > > - Initial provides/requires support > > - Lots of new regression tests have been added > > - Initial support for OS X > > - Initial support for NetBSD/EdgeBSD > > - Update most of the bundled third party software has been updated to their > > latest version > > - Improve the messages reported by pkg > > - Properly support file flags > > - Implement argument support for custom keywords > > - Extend setting credential via plist to allow to set file flags > > - Make credential syntax via plist more flexible allow to only defines the first > > - pkg updating now supports case insensitive matching > > - pkg create now support a verbose mode > > - Add an option to change the default on question, until now the default answer > > was "No" with that option set it would be "Yes" > > - Lots of fixes to pkg audit -r > > - Global memory usage reduction and speed up > > - Improvements and cleanup on pkg alias > > - pkg annotate --show --all has been fixed > > - Make pkg.h C++ friendly > > - Lots of improvements in the solver > > - Lots of fixes on 32 bits platforms > > - Add support for: pkg create -M ./plop.ucl -p ./plop.plist > > - New pkg -r that will install in the given rootdir without chrooting > > - Export PKG_ROOTDIR to scripts allow to make them as portable as possible > > - Stop trying to remove all installed package with the argument of pkg delete is > > a local file > > - Be more explicit about why the solver it going to reinstall, remove or upgrade > > (when possible) > > - Plenty of bug fixes > > - Plenty of new bugs > > - pkg shlibs now support -q > > - pkg lock gained a new --has-locked-packages option > > - pkg now resumes fetch if possible > > - CONSERVATIVE_UPGRADE is now on by default > > - pkg alias now have a -l argument to list aliases > > - A sample pkg.conf is now installed with a bunch of aliases set by default > > - Fix the backup script to properly export an sql which will be importable via > > pkg shell and/or sqlite out of box > > > > I would like to thank anyone that has been contributing to pkg to make this > > release happen (via code, bug report, feature request, testing and documentation) > > > > For pkg 1.6.0 among other things and depending on the time, here is what we do > > plan to work on: > > - Safe cherry-picking of upgrades (aka: pkg upgrade something) > > - New context dependant messages: > > * messages that only appears during upgrades > > * messages that only appears on deinstall > > * messages that only appears on install > > - Extend provides/requires to support flexible dependencies > > - Linux package backend (?) > > - Allow multiple versions of a given package in a repo > > - Add more regression tests > > - Improve documentation > > - > > > > Best regards, > > Bapt > > > > -- > Mikhail > _______________________________________________ > freebsd-ports@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscribe@freebsd.org" From owner-freebsd-stable@FreeBSD.ORG Tue Apr 14 20:40:45 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 31234CC9 for ; Tue, 14 Apr 2015 20:40:45 +0000 (UTC) Received: from mail-la0-x22f.google.com (mail-la0-x22f.google.com [IPv6:2a00:1450:4010:c03::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A0139D1C for ; Tue, 14 Apr 2015 20:40:44 +0000 (UTC) Received: by lagv1 with SMTP id v1so17712190lag.3 for ; Tue, 14 Apr 2015 13:40:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=etNyBOO9eq9EGY7kIaJ+z5hVhZHPRakX5qAN3t85R9Q=; b=epFfwVC2DLB1hgPfNJ2/EhRp0vulQcFRCJNt7+rCPQhQKNgxXGYupJDtDYTowh9GDj +4DFwK4/XFhuZ3v7TOfbzDE4mXb3eBC5gysOq+mFUf51sNPGEClIAYcDAp3ipjr496oo w1Lu0vv7YsA3jsRlPCiLkus+z14xUbq1G3LRHxhVcg4pjIOmyFmo79d5Vw7hlLbNLv7T 9MNuZKIP4N+dMRzQui20tRSJVXXcMl5LSTK2DfZJsbUdnrI6aaRSSk/7KxBY1jxLRNmv ML0GwA4ZovvRpdc3r/zXeeUJ2xNGHdelaX6ZO8FEaubfhgNYiwtoczrN63uein60kCeZ sP9A== X-Received: by 10.113.11.12 with SMTP id ee12mr20501340lbd.5.1429044042204; Tue, 14 Apr 2015 13:40:42 -0700 (PDT) Received: from [192.168.2.192] ([78.84.244.14]) by mx.google.com with ESMTPSA id x2sm479097laj.8.2015.04.14.13.40.40 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 14 Apr 2015 13:40:41 -0700 (PDT) Message-ID: <552D7B47.1030207@gmail.com> Date: Tue, 14 Apr 2015 23:40:39 +0300 From: Alnis Morics User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Icedove/31.5.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: pkg 1.5.0 is out References: <20150414200459.GE39658@ivaldir.etoilebsd.net> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 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, 14 Apr 2015 20:40:45 -0000 On 04/14/2015 11:34 PM, Fernando Apesteguía wrote: > El 14/04/2015 22:19, "Mikhail Tsatsenko" escribió: >> 2015-04-14 23:05 GMT+03:00 Baptiste Daroussin : >>> Hi all, >> Hi, >> thanks for your great work! > +1 +1 > >>> Final pkg 1.5.0 has been released. >>> >>> What happened since pkg 1.4.0: >>> - Initial provides/requires support >>> - Lots of new regression tests have been added >>> - Initial support for OS X >>> - Initial support for NetBSD/EdgeBSD >>> - Update most of the bundled third party software has been updated to > their >>> latest version >>> - Improve the messages reported by pkg >>> - Properly support file flags >>> - Implement argument support for custom keywords >>> - Extend setting credential via plist to allow to set file flags >>> - Make credential syntax via plist more flexible allow to only defines > the first >>> - pkg updating now supports case insensitive matching >>> - pkg create now support a verbose mode >>> - Add an option to change the default on question, until now the > default answer >>> was "No" with that option set it would be "Yes" >>> - Lots of fixes to pkg audit -r >>> - Global memory usage reduction and speed up >>> - Improvements and cleanup on pkg alias >>> - pkg annotate --show --all has been fixed >>> - Make pkg.h C++ friendly >>> - Lots of improvements in the solver >>> - Lots of fixes on 32 bits platforms >>> - Add support for: pkg create -M ./plop.ucl -p ./plop.plist >>> - New pkg -r that will install in the given rootdir without > chrooting >>> - Export PKG_ROOTDIR to scripts allow to make them as portable as > possible >>> - Stop trying to remove all installed package with the argument of pkg > delete is >>> a local file >>> - Be more explicit about why the solver it going to reinstall, remove > or upgrade >>> (when possible) >>> - Plenty of bug fixes >>> - Plenty of new bugs >>> - pkg shlibs now support -q >>> - pkg lock gained a new --has-locked-packages option >>> - pkg now resumes fetch if possible >>> - CONSERVATIVE_UPGRADE is now on by default >>> - pkg alias now have a -l argument to list aliases >>> - A sample pkg.conf is now installed with a bunch of aliases set by > default >>> - Fix the backup script to properly export an sql which will be > importable via >>> pkg shell and/or sqlite out of box >>> >>> I would like to thank anyone that has been contributing to pkg to make > this >>> release happen (via code, bug report, feature request, testing and > documentation) >>> For pkg 1.6.0 among other things and depending on the time, here is > what we do >>> plan to work on: >>> - Safe cherry-picking of upgrades (aka: pkg upgrade something) >>> - New context dependant messages: >>> * messages that only appears during upgrades >>> * messages that only appears on deinstall >>> * messages that only appears on install >>> - Extend provides/requires to support flexible dependencies >>> - Linux package backend (?) >>> - Allow multiple versions of a given package in a repo >>> - Add more regression tests >>> - Improve documentation >>> - - portmaster support (-P)? >>> >>> Best regards, >>> Bapt >> >> >> -- >> Mikhail >> _______________________________________________ >> freebsd-ports@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-ports >> To unsubscribe, send any mail to "freebsd-ports-unsubscribe@freebsd.org" > _______________________________________________ > 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 Apr 14 23:25:17 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E1361554 for ; Tue, 14 Apr 2015 23:25:17 +0000 (UTC) Received: from mail-pd0-x22d.google.com (mail-pd0-x22d.google.com [IPv6:2607:f8b0:400e:c02::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AD68D1CE for ; Tue, 14 Apr 2015 23:25:17 +0000 (UTC) Received: by pdbqa5 with SMTP id qa5so29402551pdb.1 for ; Tue, 14 Apr 2015 16:25:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=mJMVNWn1bmcDWf8xQ8Ty5L7VXIwYKYedRqYcAZqfWoM=; b=tVHPmZYu+MnDGCTxn8Ag+k6f8NlGLKDsrNYPc/0p2+v/b/St8QXdcmGAw77Jgxzbjb 4qXgQHRiZjf7CXwthy05fLy++oTSD/+JeJAstUgCCPyEBAc1a5qud5n2icoE8wOBcWVv aT9xaRYz3sP9C3Irud+2poiOD9cJhFL6DR8hFK9kFIjxmTllv5CJ+5Kep6KgTbWnspiT 9zf66HRxV3WuD8rWNzrp64ZMwZ2CCPT90JZYq6u3B3d5LenQJV/zll92aIsDZQTA6hYz 6JDdPHMLcZJr6b3jcmFjIPoVLuTqFGXaVYjqumEzjh2ngKvUjCvg9a+N/qFPCzpGj8oO cTSQ== X-Received: by 10.66.142.137 with SMTP id rw9mr5351071pab.56.1429053917164; Tue, 14 Apr 2015 16:25:17 -0700 (PDT) Received: from [192.168.42.12] (a82-linw-910.blocka-148.stargate.ca. [64.253.148.82]) by mx.google.com with ESMTPSA id x4sm2146986pdl.55.2015.04.14.16.25.16 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 14 Apr 2015 16:25:16 -0700 (PDT) Message-ID: <552DA1AF.30107@gmail.com> Date: Tue, 14 Apr 2015 16:24:31 -0700 From: Jamie Maher User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: bug 195458 - 10.2 release or 10.1 patch? Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 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, 14 Apr 2015 23:25:18 -0000 Hello, I noticed that a fix for bug 195458 "Hang on shutdown/root unmount after FreeBSD 10.1R upgrade" was MFC'd as revision 281386 in the 10-stable Jenkins 1338 build log: "Fix the hand(sp? hang) after the immediate reboot after the init binary is unlinked." The bug seems to hang any new FreeBSD 10.1 install using the default installer filesystem choice of "Auto (UFS)" upon reboot following a freebsd-update update install for the first time. This can cause an unfavorable view of freebsd stability if someone is trying out the latest stable release of FreeBSD and their first experience after making sure everything is up to date is a hang. This can also cause a headache if you do not have physical or KVM access to the server to reboot it. Will there be an patch addressing this in 10.1, or will it be rolled into a later release eg. 10.2 which seems to be scheduled for November 2015... quite a long way out. I would think it would be good as well to issue a warning about the problem in the meantime? https://www.freebsd.org/releases/10.1R/errata.html#open-issues Regards, Jamie From owner-freebsd-stable@FreeBSD.ORG Wed Apr 15 09:57:55 2015 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AA3C560A; Wed, 15 Apr 2015 09:57:55 +0000 (UTC) Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6CF82C5; Wed, 15 Apr 2015 09:57:55 +0000 (UTC) Received: by qkhg7 with SMTP id g7so73857256qkh.2; Wed, 15 Apr 2015 02:57:54 -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=mu0zTPPnpJc/856TTICPeXV2PesPeLFDiQAmEeAGe9s=; b=qgxZKoOQdjy3FVR2sO9E6g2LFvzURmD6FCOSEI9Qg4etJjMQea/tn5s3yyncoQo19b FUcxeQXDXruQ8Z43ky72vlUU/XbdPnnFNhGw0mXd/NJADOIFjnVev6Sknbj2gnB3LQ4U +RNhMWZ3hw+yw1vRPTokWkt4T+QdtI2BcSebzDLE4KIJFslCgfPaB9awJygFDVrRhcYr WARMqhqlmIibgz6/ILW6Iac8Uy072+AFSCfZlHye//qiykIu/T1G15f5BhvPPbZb4gPT o5bO0pWfSYkhO3gZR/TRMChp0jnH71tV6pPYLky3/QlCR99dg7m/NUmCqYKmBFGVdoQU 8ijw== MIME-Version: 1.0 X-Received: by 10.229.251.6 with SMTP id mq6mr31384648qcb.14.1429091848182; Wed, 15 Apr 2015 02:57:28 -0700 (PDT) Received: by 10.229.200.66 with HTTP; Wed, 15 Apr 2015 02:57:28 -0700 (PDT) In-Reply-To: <20150414200459.GE39658@ivaldir.etoilebsd.net> References: <20150414200459.GE39658@ivaldir.etoilebsd.net> Date: Wed, 15 Apr 2015 10:57:28 +0100 Message-ID: Subject: Re: pkg 1.5.0 is out From: Big Lebowski To: Baptiste Daroussin Cc: "ports@FreeBSD.org Ports" , current@freebsd.org, stable@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 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, 15 Apr 2015 09:57:55 -0000 On Tue, Apr 14, 2015 at 9:05 PM, Baptiste Daroussin wrote: > Hi all, > > Final pkg 1.5.0 has been released. > > > Best regards, > Bapt Congratulations to entire pkg team and thanks for your hard work! I've one question - how does the OSX support work? What are plans for it? What packages are working? And so on... Regards, BL From owner-freebsd-stable@FreeBSD.ORG Wed Apr 15 10:35:36 2015 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C2769F74; Wed, 15 Apr 2015 10:35:36 +0000 (UTC) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5F5AB813; Wed, 15 Apr 2015 10:35:36 +0000 (UTC) Received: by wiun10 with SMTP id n10so54572684wiu.1; Wed, 15 Apr 2015 03:35:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=SYFEopKy4bs4BWYpk9Iw2fGks95qR+aNDjSIeGdvbmk=; b=Tod66+24WA9RUXqgXKU09lEx2ja9VJrnIdpAc3x93GDKTo6vRJ3B28OT+xHcgjIkk/ u2QfeZZGuNh9bB6uTwOJP/Uy6LPUa2By2Xc7J/j+0LbzjBzp2E3qYsO5hEaNroJIn0DM 1lZb0FYzvA57aJPAqEiXnz1NVw0cxodMv+H1RaV24DoWBJ3liaWCGzq9bbUiTb4qBSBr GJplcj2Y1ZImfCrmbcH00VK0jS6JsRv2a72HHkFd5MtJCdUz3hiVRVDrcS6HCORSIFXS j2N5qnw7XeJaz10i5AObvsOqKSksnbWC9HeTYA0cjJqZ8cB6hM/kV7kbjEY4p0RcYsCh Qx4Q== X-Received: by 10.180.108.81 with SMTP id hi17mr40180024wib.91.1429094134790; Wed, 15 Apr 2015 03:35:34 -0700 (PDT) Received: from ivaldir.etoilebsd.net ([2001:41d0:8:db4c::1]) by mx.google.com with ESMTPSA id fs9sm5372971wjc.34.2015.04.15.03.35.33 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 Apr 2015 03:35:33 -0700 (PDT) Sender: Baptiste Daroussin Date: Wed, 15 Apr 2015 12:35:31 +0200 From: Baptiste Daroussin To: Big Lebowski Cc: "ports@FreeBSD.org Ports" , current@freebsd.org, stable@freebsd.org Subject: Re: pkg 1.5.0 is out Message-ID: <20150415103531.GO39658@ivaldir.etoilebsd.net> References: <20150414200459.GE39658@ivaldir.etoilebsd.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="da9oBGf5DLtF9ehv" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 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, 15 Apr 2015 10:35:36 -0000 --da9oBGf5DLtF9ehv Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Apr 15, 2015 at 10:57:28AM +0100, Big Lebowski wrote: > On Tue, Apr 14, 2015 at 9:05 PM, Baptiste Daroussin wr= ote: > > Hi all, > > > > Final pkg 1.5.0 has been released. > > > > > > Best regards, > > Bapt >=20 > Congratulations to entire pkg team and thanks for your hard work! >=20 > I've one question - how does the OSX support work? What are plans for > it? What packages are working? And so on... That should been asked to the people that made the support for OSX I'm just= the messenger here, I do not have access to any OSX to be able to test/code, I'm just making sure I do not break their work :) Best regards, Bapt --da9oBGf5DLtF9ehv Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlUuPvMACgkQ8kTtMUmk6EzJogCgkYINsBCNm9g779d5rKQ20oTR FyQAoJSDP5+NWv6ZyyiUEyf5V7Vl1lMD =W1J2 -----END PGP SIGNATURE----- --da9oBGf5DLtF9ehv-- From owner-freebsd-stable@FreeBSD.ORG Wed Apr 15 21:44:46 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 00196673 for ; Wed, 15 Apr 2015 21:44:45 +0000 (UTC) Received: from mail-vn0-x234.google.com (mail-vn0-x234.google.com [IPv6:2607:f8b0:400c:c0f::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9AFBD953 for ; Wed, 15 Apr 2015 21:44:45 +0000 (UTC) Received: by vnbf1 with SMTP id f1so20630417vnb.0 for ; Wed, 15 Apr 2015 14:44:44 -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=ql5O7zmKmXdKQq8Nq+fPdHdaVrKfGfSqkaWp2s9NDPc=; b=LzFapjdugRCI979tck+49ghihTChHhapPF4wYXU8q4V+MXGghxonH65sec/di/Pftf 2tJS9a+UtFOfKIGyf9hrIFAVJ1ZwylQtWFjJtDJWJW4bG99+u9ba/tCKX4bLdLyOBsTX mULu5rao3PbeIsctuRsn2kBRWsq8MBS2hhaXlPWtEcOwD3fpdnHp4i1oreBNDK9CmNnG 39P/Z40IeuoiipeZPkNKpd/Y/8m8LdX0stwFUiZugXuGupbE1ZnAHulcqAwRCTewtfzD ZM6frVRLdytXKja4H51xmYW1fxQ7RrjBR1IgV2eMqakprjEwzS6NDsFrivUAYH9CXwbQ zmLg== MIME-Version: 1.0 X-Received: by 10.202.175.213 with SMTP id y204mr17714018oie.22.1429134284324; Wed, 15 Apr 2015 14:44:44 -0700 (PDT) Received: by 10.202.44.196 with HTTP; Wed, 15 Apr 2015 14:44:44 -0700 (PDT) In-Reply-To: References: <2F9DC176-912C-40C0-BAB7-DB66BD572ABA@vnode.se> <54D8E341.101@pix.net> <1423501720.16794.18.camel@freebsd.org> Date: Wed, 15 Apr 2015 14:44:44 -0700 Message-ID: Subject: Re: freebsd-update and hang during reboot From: Nick Rogers To: Nick Rogers Cc: FreeBSD STABLE Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 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, 15 Apr 2015 21:44:46 -0000 On Mon, Mar 9, 2015 at 9:19 AM, Nick Rogers wrote: > > > On Tue, Feb 10, 2015 at 1:37 PM, Nick Rogers wrote: > >> >> >> On Mon, Feb 9, 2015 at 9:08 AM, Ian Lepore wrote: >> >>> On Mon, 2015-02-09 at 11:41 -0500, Kurt Lidl wrote: >>> > Joel wrote: >>> > > Hi, >>> > > >>> > > Just about every machine I have seems to hang after running >>> freebsd-update and doing a reboot. The last message on the screen is "A= ll >>> buffers synced=E2=80=9D and it just freezes. >>> > > >>> > > This happens when doing a freebsd-update and going from 10.0 to >>> 10.1, but also when doing a fresh 10.1 install and using freebsd-update= to >>> get the latest -pX security patches. As soon as I reboot the machine, i= t >>> hangs. >>> > > >>> > > I=E2=80=99ve tried it on several different HP ProLiant models, on I= ntel NUCs >>> and on VMware virtual machines. Same phenomenon everywhere. It=E2=80=99= s really >>> easy to trigger: just install 10.1, use default settings everywhere, >>> freebsd-update fetch/install, shutdown -r now and BOOM. It hangs. I thi= nk >>> I=E2=80=99ve seen it on >>> > > >>> > > >>> > > >>> > > >>> > > 30 servers or so now. >>> > > >>> > > Everything works like it should after the initial hang tough - no >>> matter how many times I reboot it completes the reboot cycle just fine. >>> > > >>> > > I=E2=80=99ve seen several people (mostly on IRC) mention this probl= em, but >>> no solution. >>> > > >>> > > Is anyone working on fixing this? >>> > >>> > I ran into this problem in spades when upgrading a set of servers fro= m >>> > FreeBSD 9.0 to 9.1. I happened consistently. Normal reboots worked, >>> > but when going from 9.0 to 9.1, it *ALWAYS* hung, and it always hung >>> > at the same place, after printing the "All buffers synced" message. >>> > >>> > I ultimately determined that if I did the following, rather than >>> > just a "reboot" or "shutdown -r now 'FreeBSD 9.1-RELEASE upgrade'", >>> > it would consistently AVOID the hang: >>> > >>> > sync ; sync ; sync ; shutdown -o -n -r now "FreeBSD 9.1 install" >>> > >>> > Your mileage may vary, but you don't have a lot to lose by trying it. >>> > >>> > -Kurt >>> > >>> >>> That is just bad advice. sync(1) does not g'tee that all data has been >>> written, no matter how many times you type it. shutdown -n tells the >>> system to abandon unwritten data. All in all, this is a recipe for >>> silent filesystem corruption. Using it after an update is just asking >>> to have a mix of old and new files on the system after the reboot. >>> >>> A more robust workaround would be to "mount -r" on all filesystems >>> before invoking the shutdown (even a shutdown -n should be safe after >>> everything has been remounted readonly). If the mount -r hangs on one >>> of the filesystems, then you've probably got a clue as to where a norma= l >>> shutdown is hanging. >>> >> >> FWIW mount -r on the root filesystem hangs for me. If I disable >> softupdates-journaling on the root filesystem before the upgrade process= , >> the system no longer hangs on the last reboot after userland upgrade. >> However, the root filesystem still comes up dirty with an incorrect free >> block count during fsck. >> > > Is anyone working on fixing this problem? It seems like this should have > some kind of "full court press" as it is obviously affecting plenty of > people, some of which have spoken up in the following PR > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D195458 > > I realize its a tough problem to track down, and if I had the appropriate > skills I would help. But so far all I've been able to do, like others, is > replicate and complain about the problem. > > Its still affecting upgrading to 10.1-RELEASE-p6 from the official > 10.1-RELEASE distribution, and from 10.1-RELEASE-p5. I just had another > production server hang during reboot after updating to p6, and I don't se= e > this changing for the inevitable p7 unless this problem gets more > attention. Can someone with the right skill-set please help figure this > out? Thank you. > In case anyone is still dealing with this problem, the fix was MFC'd to stable/10 a few days. I am assuming this will not end up getting back ported to releng/10.1. I've compiled a patch with the fix that works against 10.1-RELEASE. Maybe it will be useful for any of you like me that don't run 10-stable, but are comfortable with custom kernels and are still dealing with this issue when running freebsd-update every time a new patch level is released. Diff is below. # Fix bug causing a hang while unmounting the root filesystem during # reboot after performing a freebsd-update. # # # Original commit to HEAD: # https://svnweb.freebsd.org/base?view=3Drevision&revision=3D280760 # MFC to stable: # https://svnweb.freebsd.org/base?view=3Drevision&revision=3D281350 # # The following commits were taken from stable/10/sys/ufs/ffs between # the release of 10.1-RELEASE (r272459) and MFC of the fix (r281350) # in order for the fix to cleanly apply to releng/10.1. The two # unrelated commits seem like reasonable fixes to include as well. # # https://svnweb.freebsd.org/base?view=3Drevision&revision=3D281350 # https://svnweb.freebsd.org/base?view=3Drevision&revision=3D278667 # https://svnweb.freebsd.org/base?view=3Drevision&revision=3D274305 # Index: ufs/ffs/ffs_vfsops.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- ufs/ffs/ffs_vfsops.c (revision 272459) +++ ufs/ffs/ffs_vfsops.c (revision 281350) @@ -1502,8 +1502,11 @@ if (fs->fs_fmod !=3D 0 && fs->fs_ronly !=3D 0 && ump->um_fsckpid =3D=3D 0= ) panic("%s: ffs_sync: modification on read-only filesystem", fs->fs_fsmnt); - if (waitfor =3D=3D MNT_LAZY) - return (ffs_sync_lazy(mp)); + if (waitfor =3D=3D MNT_LAZY) { + if (!rebooting) + return (ffs_sync_lazy(mp)); + waitfor =3D MNT_NOWAIT; + } /* * Write back each (modified) inode. @@ -1560,7 +1563,7 @@ /* * Force stale filesystem control information to be flushed. */ - if (waitfor =3D=3D MNT_WAIT) { + if (waitfor =3D=3D MNT_WAIT || rebooting) { if ((error =3D softdep_flushworklist(ump->um_mountp, &count, td))) allerror =3D error; /* Flushed work items may create new vnodes to clean */ @@ -1577,9 +1580,12 @@ if (bo->bo_numoutput > 0 || bo->bo_dirty.bv_cnt > 0) { BO_UNLOCK(bo); vn_lock(devvp, LK_EXCLUSIVE | LK_RETRY); - if ((error =3D VOP_FSYNC(devvp, waitfor, td)) !=3D 0) + error =3D VOP_FSYNC(devvp, waitfor, td); + VOP_UNLOCK(devvp, 0); + if (MOUNTEDSOFTDEP(mp) && (error =3D=3D 0 || error =3D=3D EAGAIN)) + error =3D ffs_sbupdate(ump, waitfor, 0); + if (error !=3D 0) allerror =3D error; - VOP_UNLOCK(devvp, 0); if (allerror =3D=3D 0 && waitfor =3D=3D MNT_WAIT) goto loop; } else if (suspend !=3D 0) { Index: ufs/ffs/ffs_softdep.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- ufs/ffs/ffs_softdep.c (revision 272459) +++ ufs/ffs/ffs_softdep.c (revision 281350) @@ -735,9 +735,10 @@ static void check_clear_deps(struct mount *); static void softdep_error(char *, int); static int softdep_process_worklist(struct mount *, int); -static int softdep_waitidle(struct mount *); +static int softdep_waitidle(struct mount *, int); static void drain_output(struct vnode *); static struct buf *getdirtybuf(struct buf *, struct rwlock *, int); +static int check_inodedep_free(struct inodedep *); static void clear_remove(struct mount *); static void clear_inodedeps(struct mount *); static void unlinked_inodedep(struct mount *, struct inodedep *); @@ -1377,6 +1378,10 @@ mp =3D (struct mount *)addr; ump =3D VFSTOUFS(mp); atomic_add_int(&stat_flush_threads, 1); + ACQUIRE_LOCK(ump); + ump->softdep_flags &=3D ~FLUSH_STARTING; + wakeup(&ump->softdep_flushtd); + FREE_LOCK(ump); if (print_threads) { if (stat_flush_threads =3D=3D 1) printf("Running %s at pid %d\n", bufdaemonproc->p_comm, @@ -1389,7 +1394,7 @@ VFSTOUFS(mp)->softdep_jblocks->jb_suspended)) kthread_suspend_check(); ACQUIRE_LOCK(ump); - if ((ump->softdep_flags & FLUSH_CLEANUP) =3D=3D 0) + if ((ump->softdep_flags & (FLUSH_CLEANUP | FLUSH_EXIT)) =3D=3D 0) msleep(&ump->softdep_flushtd, LOCK_PTR(ump), PVM, "sdflush", hz / 2); ump->softdep_flags &=3D ~FLUSH_CLEANUP; @@ -1419,11 +1424,9 @@ ump =3D VFSTOUFS(mp); LOCK_OWNED(ump); - if ((ump->softdep_flags & (FLUSH_CLEANUP | FLUSH_EXIT)) =3D=3D 0) { + if ((ump->softdep_flags & (FLUSH_CLEANUP | FLUSH_EXIT)) =3D=3D 0) ump->softdep_flags |=3D FLUSH_CLEANUP; - if (ump->softdep_flushtd->td_wchan =3D=3D &ump->softdep_flushtd) - wakeup(&ump->softdep_flushtd); - } + wakeup(&ump->softdep_flushtd); } static int @@ -1468,14 +1471,10 @@ TAILQ_INSERT_TAIL(&softdepmounts, sdp, sd_next); FREE_GBLLOCK(&lk); if ((altump->softdep_flags & - (FLUSH_CLEANUP | FLUSH_EXIT)) =3D=3D 0) { + (FLUSH_CLEANUP | FLUSH_EXIT)) =3D=3D 0) altump->softdep_flags |=3D FLUSH_CLEANUP; - altump->um_softdep->sd_cleanups++; - if (altump->softdep_flushtd->td_wchan =3D=3D - &altump->softdep_flushtd) { - wakeup(&altump->softdep_flushtd); - } - } + altump->um_softdep->sd_cleanups++; + wakeup(&altump->softdep_flushtd); FREE_LOCK(altump); } } @@ -1887,8 +1886,8 @@ struct thread *td; { struct vnode *devvp; - int count, error =3D 0; struct ufsmount *ump; + int count, error; /* * Alternately flush the block device associated with the mount @@ -1897,6 +1896,7 @@ * are found. */ *countp =3D 0; + error =3D 0; ump =3D VFSTOUFS(oldmnt); devvp =3D ump->um_devvp; while ((count =3D softdep_process_worklist(oldmnt, 1)) > 0) { @@ -1904,36 +1904,47 @@ vn_lock(devvp, LK_EXCLUSIVE | LK_RETRY); error =3D VOP_FSYNC(devvp, MNT_WAIT, td); VOP_UNLOCK(devvp, 0); - if (error) + if (error !=3D 0) break; } return (error); } +#define SU_WAITIDLE_RETRIES 20 static int -softdep_waitidle(struct mount *mp) +softdep_waitidle(struct mount *mp, int flags __unused) { struct ufsmount *ump; - int error; - int i; + struct vnode *devvp; + struct thread *td; + int error, i; ump =3D VFSTOUFS(mp); + devvp =3D ump->um_devvp; + td =3D curthread; + error =3D 0; ACQUIRE_LOCK(ump); - for (i =3D 0; i < 10 && ump->softdep_deps; i++) { + for (i =3D 0; i < SU_WAITIDLE_RETRIES && ump->softdep_deps !=3D 0; i++) { ump->softdep_req =3D 1; - if (ump->softdep_on_worklist) - panic("softdep_waitidle: work added after flush."); - msleep(&ump->softdep_deps, LOCK_PTR(ump), PVM, "softdeps", 1); + KASSERT((flags & FORCECLOSE) =3D=3D 0 || + ump->softdep_on_worklist =3D=3D 0, + ("softdep_waitidle: work added after flush")); + msleep(&ump->softdep_deps, LOCK_PTR(ump), PVM | PDROP, + "softdeps", 10 * hz); + vn_lock(devvp, LK_EXCLUSIVE | LK_RETRY); + error =3D VOP_FSYNC(devvp, MNT_WAIT, td); + VOP_UNLOCK(devvp, 0); + if (error !=3D 0) + break; + ACQUIRE_LOCK(ump); } ump->softdep_req =3D 0; - FREE_LOCK(ump); - error =3D 0; - if (i =3D=3D 10) { + if (i =3D=3D SU_WAITIDLE_RETRIES && error =3D=3D 0 && ump->softdep_deps != =3D 0) { error =3D EBUSY; printf("softdep_waitidle: Failed to flush worklist for %p\n", mp); } - + FREE_LOCK(ump); return (error); } @@ -1990,7 +2001,7 @@ error =3D EBUSY; } if (!error) - error =3D softdep_waitidle(oldmnt); + error =3D softdep_waitidle(oldmnt, flags); if (!error) { if (oldmnt->mnt_kern_flag & MNTK_UNMOUNT) { retry =3D 0; @@ -2490,9 +2501,18 @@ /* * Start our flushing thread in the bufdaemon process. */ + ACQUIRE_LOCK(ump); + ump->softdep_flags |=3D FLUSH_STARTING; + FREE_LOCK(ump); kproc_kthread_add(&softdep_flush, mp, &bufdaemonproc, &ump->softdep_flushtd, 0, 0, "softdepflush", "%s worker", mp->mnt_stat.f_mntonname); + ACQUIRE_LOCK(ump); + while ((ump->softdep_flags & FLUSH_STARTING) !=3D 0) { + msleep(&ump->softdep_flushtd, LOCK_PTR(ump), PVM, "sdstart", + hz / 2); + } + FREE_LOCK(ump); /* * When doing soft updates, the counters in the * superblock may have gotten out of sync. Recomputation @@ -7629,17 +7649,13 @@ return (1); } -/* - * Try to free an inodedep structure. Return 1 if it could be freed. - */ static int -free_inodedep(inodedep) +check_inodedep_free(inodedep) struct inodedep *inodedep; { LOCK_OWNED(VFSTOUFS(inodedep->id_list.wk_mp)); - if ((inodedep->id_state & (ONWORKLIST | UNLINKED)) !=3D 0 || - (inodedep->id_state & ALLCOMPLETE) !=3D ALLCOMPLETE || + if ((inodedep->id_state & ALLCOMPLETE) !=3D ALLCOMPLETE || !LIST_EMPTY(&inodedep->id_dirremhd) || !LIST_EMPTY(&inodedep->id_pendinghd) || !LIST_EMPTY(&inodedep->id_bufwait) || @@ -7654,6 +7670,21 @@ inodedep->id_nlinkdelta !=3D 0 || inodedep->id_savedino1 !=3D NULL) return (0); + return (1); +} + +/* + * Try to free an inodedep structure. Return 1 if it could be freed. + */ +static int +free_inodedep(inodedep) + struct inodedep *inodedep; +{ + + LOCK_OWNED(VFSTOUFS(inodedep->id_list.wk_mp)); + if ((inodedep->id_state & (ONWORKLIST | UNLINKED)) !=3D 0 || + !check_inodedep_free(inodedep)) + return (0); if (inodedep->id_state & ONDEPLIST) LIST_REMOVE(inodedep, id_deps); LIST_REMOVE(inodedep, id_hash); @@ -13838,7 +13869,8 @@ { struct bufobj *bo; struct ufsmount *ump; - int error; + struct inodedep *inodedep; + int error, unlinked; bo =3D &devvp->v_bufobj; ASSERT_BO_WLOCKED(bo); @@ -13899,6 +13931,20 @@ break; } + unlinked =3D 0; + if (MOUNTEDSUJ(mp)) { + for (inodedep =3D TAILQ_FIRST(&ump->softdep_unlinked); + inodedep !=3D NULL; + inodedep =3D TAILQ_NEXT(inodedep, id_unlinked)) { + if ((inodedep->id_state & (UNLINKED | UNLINKLINKS | + UNLINKONLIST)) !=3D (UNLINKED | UNLINKLINKS | + UNLINKONLIST) || + !check_inodedep_free(inodedep)) + continue; + unlinked++; + } + } + /* * Reasons for needing more work before suspend: * - Dirty buffers on devvp. @@ -13908,8 +13954,8 @@ error =3D 0; if (bo->bo_numoutput > 0 || bo->bo_dirty.bv_cnt > 0 || - softdep_depcnt !=3D 0 || - ump->softdep_deps !=3D 0 || + softdep_depcnt !=3D unlinked || + ump->softdep_deps !=3D unlinked || softdep_accdepcnt !=3D ump->softdep_accdeps || secondary_writes !=3D 0 || mp->mnt_secondary_writes !=3D 0 || Index: ufs/ffs/softdep.h =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- ufs/ffs/softdep.h (revision 272459) +++ ufs/ffs/softdep.h (revision 281350) @@ -1063,6 +1063,8 @@ */ #define FLUSH_EXIT 0x0001 /* time to exit */ #define FLUSH_CLEANUP 0x0002 /* need to clear out softdep structures */ +#define FLUSH_STARTING 0x0004 /* flush thread not yet started */ + /* * Keep the old names from when these were in the ufsmount structure. */ > >>> -- Ian >>> >>> >>> _______________________________________________ >>> freebsd-stable@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >>> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.or= g >>> " >>> >> >> > From owner-freebsd-stable@FreeBSD.ORG Wed Apr 15 21:52:21 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 40CE6B9F for ; Wed, 15 Apr 2015 21:52:21 +0000 (UTC) Received: from mail2.glyndwr.ac.uk (mail2.glyndwr.ac.uk [194.82.118.162]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail2.glyndwr.ac.uk", Issuer "TERENA SSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id ABB02A77 for ; Wed, 15 Apr 2015 21:52:20 +0000 (UTC) Received: from XCH9.wrexham.local (2002:c252:76aa::c252:76aa) by XCH2.wrexham.local (2002:c252:76a2::c252:76a2) with Microsoft SMTP Server (TLS) id 14.3.224.2; Wed, 15 Apr 2015 22:52:10 +0100 Received: from XCH7.wrexham.local ([fe80::4b1:2f4e:799f:2fb]) by XCH9.wrexham.local ([::1]) with mapi id 14.03.0210.002; Wed, 15 Apr 2015 22:52:10 +0100 From: Gareth Wyn Roberts To: "pyunyh@gmail.com" CC: "freebsd-stable@freebsd.org" Subject: RE: msk msk0 watchdog timeout freeze hang lock stop problem Thread-Topic: msk msk0 watchdog timeout freeze hang lock stop problem Thread-Index: AdB1SJ7I96oMbb9aSL6oKcwiEr6BLQAcMP4AAIMYBec= Date: Wed, 15 Apr 2015 21:52:09 +0000 Message-ID: References: , <20150413081348.GA965@michelle.fasterthan.com> In-Reply-To: <20150413081348.GA965@michelle.fasterthan.com> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [81.158.237.56] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 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, 15 Apr 2015 21:52:21 -0000 I've inserted code to print some values which show the differences between = specifying 4096 or 8192 for MSK_STAT_ALIGN. In both cases the status buffe= r has length 0x4000 (8x2048=3D16K) but the alignments are different as expe= cted, respectively start addresses 0x5c3b000 or 0xbdc2c000. The following values were output from functions msk_status_dma_alloc(), msk= _dmamap_cb() and msk_handle_events(). The "Break #n" refer to breaks in msk_handle_events(). "#1" occurs if ((con= trol & HW_OWNER) =3D=3D 0), "#5" is OP_RXSTAT and "#6" is OP_TXINDEXLE. The first output is for MSK_STAT_ALIGN=3D8192. It continues normally. Alt= hough not shown here, it reaches cons=3D2047 then cons=3D0 as expected. The second output is for MSK_STAT_ALIGN=3D4096. Although there can be isol= ated occurences of "Break #1" (e.g. cons=3D196) (?are these to be expected?= ), it continues normally until cons=3D512. At this point it continually in= vokes the "#1" block because the msk_control from msk_stat_ring[512] is alw= ays zero and the network hangs immediately. This suggests the Yukon Ultra 2= 88E8057 can't access the next 4096 memory block, but why not? Please let me know if any further information would be helpful. ------------ Start of MSK_STAT_ALIGN=3D8192 output ------------------------= ----- mskc0: mem 0xfa000000-0xfa003fff i= rq 19 at device 0.0 on pci6 mskc0: Successful creation of DMA tag mskc0: sc->msk_stat_count=3D2048 mskc0: stat_sz=3D16384 mskc0: sc->msk_stat_tag=3D0xfffff800050b99a0 mskc0: Successful allocation of DMA'able memory for status ring mskc0: sc->msk_stat_map=3D0xfffff800050b99a8 msk_dmamap_cb (stat): nseg=3D1 msk_dmamap_cb (stat): error=3D0 msk_dmamap_cb (stat): segs[0].ds_addr=3D3183656960=3D0xbdc2c000 msk_dmamap_cb (stat): segs[0].ds_len=3D16384=3D0x4000 mskc0: Successful load of DMA'able memory for status ring mskc0: sc->msk_stat_ring_paddr=3D3183656960=3D0xbdc2c000 msk0: on msk= c0 msk0: Ethernet address: 00:13:77:e9:df:eb miibus0: on msk0 e1000phy0: PHY 0 on miibus0 e1000phy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT= , 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow ... mskc0: msk_handle_events: Break #6 cons=3D0 csrread=3D1 mskc0: msk_handle_events: Break #5 cons=3D1 csrread=3D2 mskc0: msk_handle_events: Break #6 cons=3D2 csrread=3D3 mskc0: msk_handle_events: Break #5 cons=3D3 csrread=3D5 mskc0: msk_handle_events: Break #6 cons=3D4 csrread=3D6 mskc0: msk_handle_events: Break #6 cons=3D5 csrread=3D6 mskc0: msk_handle_events: Break #6 cons=3D6 csrread=3D7 mskc0: msk_handle_events: Break #5 cons=3D7 csrread=3D8 mskc0: msk_handle_events: Break #5 cons=3D8 csrread=3D10 mskc0: msk_handle_events: Break #6 cons=3D9 csrread=3D10 ... mskc0: msk_handle_events: Break #5 cons=3D510 csrread=3D511 mskc0: msk_handle_events: Break #6 cons=3D511 csrread=3D512 mskc0: msk_handle_events: Break #5 cons=3D512 csrread=3D513 mskc0: msk_handle_events: Break #5 cons=3D513 csrread=3D514 mskc0: msk_handle_events: Break #6 cons=3D514 csrread=3D515 mskc0: msk_handle_events: Break #5 cons=3D515 csrread=3D516 ...etc. ------------ Start of MSK_STAT_ALIGN=3D4096 output ------------------------= ----- mskc0: mem 0xfa000000-0xfa003fff i= rq 19 at device 0.0 on pci6 mskc0: Successful creation of DMA tag mskc0: sc->msk_stat_count=3D2048 mskc0: stat_sz=3D16384 mskc0: sc->msk_stat_tag=3D0xfffff800050b99a0 mskc0: Successful allocation of DMA'able memory for status ring mskc0: sc->msk_stat_map=3D0xfffff800050b99a8 msk_dmamap_cb (stat): nseg=3D1 msk_dmamap_cb (stat): error=3D0 msk_dmamap_cb (stat): segs[0].ds_addr=3D96710656=3D0x5c3b000 msk_dmamap_cb (stat): segs[0].ds_len=3D16384=3D0x4000 mskc0: Successful load of DMA'able memory for status ring mskc0: sc->msk_stat_ring_paddr=3D96710656=3D0x5c3b000 msk0: on msk= c0 msk0: Ethernet address: 00:13:77:e9:df:eb miibus0: on msk0 e1000phy0: PHY 0 on miibus0 e1000phy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT= , 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow ... mskc0: msk_handle_events: Break #5 cons=3D0 csrread=3D2 mskc0: msk_handle_events: Break #5 cons=3D1 csrread=3D2 mskc0: msk_handle_events: Break #5 cons=3D2 csrread=3D3 mskc0: msk_handle_events: Break #5 cons=3D3 csrread=3D4 mskc0: msk_handle_events: Break #5 cons=3D4 csrread=3D5 mskc0: msk_handle_events: Break #5 cons=3D5 csrread=3D7 mskc0: msk_handle_events: Break #5 cons=3D6 csrread=3D7 mskc0: msk_handle_events: Break #5 cons=3D7 csrread=3D9 mskc0: msk_handle_events: Break #5 cons=3D8 csrread=3D9 mskc0: msk_handle_events: Break #5 cons=3D9 csrread=3D10 mskc0: msk_handle_events: Break #5 cons=3D10 csrread=3D11 ... mskc0: msk_handle_events: Break #6 cons=3D194 csrread=3D197 mskc0: msk_handle_events: Break #5 cons=3D195 csrread=3D197 mskc0: msk_handle_events: Break #1 cons=3D196 csrread=3D197 mskc0: msk_handle_events: sd=3D0xfffffe011e23b620 sd->msk_control=3D161061= 2806 control=3D1610612806 mskc0: msk_handle_events: Break #5 cons=3D196 csrread=3D197 mskc0: msk_handle_events: Break #5 cons=3D197 csrread=3D198 ... mskc0: msk_handle_events: Break #5 cons=3D510 csrread=3D511 mskc0: msk_handle_events: Break #5 cons=3D511 csrread=3D512 mskc0: msk_handle_events: Break #1 cons=3D512 csrread=3D513 mskc0: msk_handle_events: sd=3D0xfffffe011e23c000 sd->msk_control=3D0 con= trol=3D0 mskc0: msk_handle_events: Break #1 cons=3D512 csrread=3D513 mskc0: msk_handle_events: sd=3D0xfffffe011e23c000 sd->msk_control=3D0 con= trol=3D0 mskc0: msk_handle_events: Break #1 cons=3D512 csrread=3D513 mskc0: msk_handle_events: sd=3D0xfffffe011e23c000 sd->msk_control=3D0 con= trol=3D0 mskc0: msk_handle_events: Break #1 cons=3D512 csrread=3D513 mskc0: msk_handle_events: sd=3D0xfffffe011e23c000 sd->msk_control=3D0 con= trol=3D0 mskc0: msk_handle_events: Break #1 cons=3D512 csrread=3D513 mskc0: msk_handle_events: sd=3D0xfffffe011e23c000 sd->msk_control=3D0 con= trol=3D0 mskc0: msk_handle_events: Break #1 cons=3D512 csrread=3D513 mskc0: msk_handle_events: sd=3D0xfffffe011e23c000 sd->msk_control=3D0 con= trol=3D0 mskc0: msk_handle_events: Break #1 cons=3D512 csrread=3D513 mskc0: msk_handle_events: sd=3D0xfffffe011e23c000 sd->msk_control=3D0 con= trol=3D0 ... mskc0: msk_handle_events: Break #1 cons=3D512 csrread=3D519 mskc0: msk_handle_events: sd=3D0xfffffe011e23c000 sd->msk_control=3D0 con= trol=3D0 mskc0: msk_handle_events: Break #1 cons=3D512 csrread=3D519 mskc0: msk_handle_events: sd=3D0xfffffe011e23c000 sd->msk_control=3D0 con= trol=3D0 ...etc ________________________________________ From: owner-freebsd-stable@freebsd.org [owner-freebsd-stable@freebsd.org] o= n behalf of Yonghyeon PYUN [pyunyh@gmail.com] Sent: 13 April 2015 09:13 To: Gareth Wyn Roberts Cc: freebsd-stable@freebsd.org Subject: Re: msk msk0 watchdog timeout freeze hang lock stop problem On Sun, Apr 12, 2015 at 05:57:34PM +0000, Gareth Wyn Roberts wrote: > I've run in to problems using the msk device where initially it works wel= l enough to set DHCP etc. but stops/freezes as soon as any appreciable netw= ork traffic occurs . There are several threads describing similar symptoms = over the past two years or more. I've been following several false leads b= ut have finally found a solution (at least it solves my problem). > > I'm running a standard FreeBSD 10.1-RELEASE and the NIC is detected as: > > mskc0: mem 0xfa000000-0xfa003fff= irq 19 at device 0.0 on pci6 > msk0: on m= skc0 > msk0: Ethernet address: 00:13:77:e9:df:eb > miibus0: on msk0 > e1000phy0: PHY 0 on miibus0 > e1000phy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000bas= eT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-ma > ster, auto, auto-flow > > The network worked when using the i386 release, but failed for the amd64 = release (as reported previously) which prompted me to disable 64-bit DMA (t= he patch for this is attached below). This worked for the first kernel bui= lt but mysteriously failed when another unrelated part of the kernel was ch= anged (a usb driver) and the kernel recompiled. So identical msk driver co= de worked in one kernel but not the second! This suggested that alignment d= ifferences between the two kernels were causing the msk driver to fail. Oth= ers have reported varying behaviour depending on different circumstances. > > It transpires that changing just one value in the if_mskreg.h file solved= all my problems. Subsequently I have not been able to make it fail under = heavy network traffic in either 32-bit or 64-bit mode. > I'm working on 10.1-RELEASE source, i.e. if_msk.c revision 262524 and if_= mskreg.h revision 264442. Thanks for letting me know your findings. I really appreciate that. I recall that the alignment requirement of status LEs(List Elements in Marvell terms) is 2048 and the maximum size of the status LEs is 4096 bytes(Actual alignment seems to be much lower value like 32 or 64 bytes, but alignment 2048 is chosen to avoid silicon bugs). Later experiments showed some variants of Yukon II require 4096 bytes alignment and I changed the alignment to 4096 in the past. It seems your finding indicates msk(4) needs 8192 alignment for status LEs. However this does not explain how and why the same code in 8.x/9.x works well. In addition, it's not common to require alignment size greater than PAGE_SIZE on x86 given that the maximum size of DMA buffer is 4096 bytes. I have to check whether there was a change in bus_dma(9) between 8.x/9.x and 10.x but it needs more time due to lack of spare time. Probably you can verify the DMA address of status LEs meets the following requirements both on i386 and amd64. - Alignment is 4096. - Number of DMA segment is 1. - DMA segment base address plus DMA segment size does not cross a PAGE_SIZE boundary. > > Here's the patch to if_mskreg.h > --- if_mskreg.h-orig 2014-11-11 20:02:58.000000000 +0000 > +++ if_mskreg.h 2015-04-12 18:47:20.000000000 +0100 > @@ -2179,9 +2179,11 @@ > * At first I guessed 8 bytes, the size of a single descriptor, would be > * required alignment constraints. But, it seems that Yukon II have 4096 > * bytes boundary alignment constraints. > + * And it seems that the DMA status region for the Yukon Ultra 2 (88E805= 7) > + * requires 8192 byte alignment to prevent locking. > */ > #define MSK_RING_ALIGN 4096 > -#define MSK_STAT_ALIGN 4096 > +#define MSK_STAT_ALIGN 8192 > > > The patches to both files which also implement a MSK_64BIT_DMA_DISABLE fl= ag are attached. Perhaps the developers would consider committing these as= it may be useful for future debugging. > If you have more than 4GB memory installed and disables 64bit DMA addressing, msk(4) shall use bounce buffers. Passing packets through bounce buffers involves copy operation and it costs a lot. You can check hw.busdma sysctl node to see whether there are drivers that use bounce buffers. And if you want to disable 64bit DMA on 64bit architectures, add '#undef MSK_64BIT_DMA' just below BUS_SPACE_MAXADDR check in if_mskreg.h. _______________________________________________ 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 Wed Apr 15 22:05:23 2015 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 45BACF46; Wed, 15 Apr 2015 22:05:23 +0000 (UTC) Received: from mail-vn0-x229.google.com (mail-vn0-x229.google.com [IPv6:2607:f8b0:400c:c0f::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 120D1BA5; Wed, 15 Apr 2015 22:05:22 +0000 (UTC) Received: by vnbg7 with SMTP id g7so20711521vnb.10; Wed, 15 Apr 2015 15:05:22 -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=nJXeIdq8yrKVkSFF8V73t08okFLolibRDjoFmbO6nrk=; b=siGH5S3ZseIrxtbT+KmYiopWpomC8yrgitbPawfdP7gQfzYMkundLcaPBz/8DEndCx bBGds2BfPhiGSurwj3nlMQ3ZpKCsyiGpsLKbfRqH4CtzjIhsrkBg30DqGj7v8fpuUIw6 rL9Dk73vv+2XUONLiLjsMk4+ckXVwewBsU6Bw9iJc2321z9V3oJnmeTy1wa6Kk0+9Cf+ yOJucy+945bVyoV5DFar4pTrxBf+SLqeeYTBjwURm8b3nhp5lHR+VxChcQwzaQa7qCnW VJmmXprAZRzeEZcF/jYSIx4jksPA1Iaurq9hdxtkOKI8JECXXrTyDJu/+cIrdwoI4EEO SIpA== MIME-Version: 1.0 X-Received: by 10.60.147.165 with SMTP id tl5mr22874746oeb.81.1429135522005; Wed, 15 Apr 2015 15:05:22 -0700 (PDT) Received: by 10.202.211.130 with HTTP; Wed, 15 Apr 2015 15:05:21 -0700 (PDT) In-Reply-To: <20150414200459.GE39658@ivaldir.etoilebsd.net> References: <20150414200459.GE39658@ivaldir.etoilebsd.net> Date: Thu, 16 Apr 2015 00:05:21 +0200 Message-ID: Subject: Re: pkg 1.5.0 is out From: Zenny To: Baptiste Daroussin Cc: ports@freebsd.org, current@freebsd.org, stable@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 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, 15 Apr 2015 22:05:23 -0000 Rapid evolution of pkgng! :D Thanks for your great work! On 4/14/15, Baptiste Daroussin wrote: > Hi all, > > Final pkg 1.5.0 has been released. > > What happened since pkg 1.4.0: > - Initial provides/requires support > - Lots of new regression tests have been added > - Initial support for OS X > - Initial support for NetBSD/EdgeBSD > - Update most of the bundled third party software has been updated to their > latest version > - Improve the messages reported by pkg > - Properly support file flags > - Implement argument support for custom keywords > - Extend setting credential via plist to allow to set file flags > - Make credential syntax via plist more flexible allow to only defines the > first > - pkg updating now supports case insensitive matching > - pkg create now support a verbose mode > - Add an option to change the default on question, until now the default > answer > was "No" with that option set it would be "Yes" > - Lots of fixes to pkg audit -r > - Global memory usage reduction and speed up > - Improvements and cleanup on pkg alias > - pkg annotate --show --all has been fixed > - Make pkg.h C++ friendly > - Lots of improvements in the solver > - Lots of fixes on 32 bits platforms > - Add support for: pkg create -M ./plop.ucl -p ./plop.plist > - New pkg -r that will install in the given rootdir without > chrooting > - Export PKG_ROOTDIR to scripts allow to make them as portable as possible > - Stop trying to remove all installed package with the argument of pkg > delete is > a local file > - Be more explicit about why the solver it going to reinstall, remove or > upgrade > (when possible) > - Plenty of bug fixes > - Plenty of new bugs > - pkg shlibs now support -q > - pkg lock gained a new --has-locked-packages option > - pkg now resumes fetch if possible > - CONSERVATIVE_UPGRADE is now on by default > - pkg alias now have a -l argument to list aliases > - A sample pkg.conf is now installed with a bunch of aliases set by default > - Fix the backup script to properly export an sql which will be importable > via > pkg shell and/or sqlite out of box > > I would like to thank anyone that has been contributing to pkg to make this > release happen (via code, bug report, feature request, testing and > documentation) > > For pkg 1.6.0 among other things and depending on the time, here is what we > do > plan to work on: > - Safe cherry-picking of upgrades (aka: pkg upgrade something) > - New context dependant messages: > * messages that only appears during upgrades > * messages that only appears on deinstall > * messages that only appears on install > - Extend provides/requires to support flexible dependencies > - Linux package backend (?) > - Allow multiple versions of a given package in a repo > - Add more regression tests > - Improve documentation > - > > Best regards, > Bapt > From owner-freebsd-stable@FreeBSD.ORG Thu Apr 16 04:16:42 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 59D5E6C1 for ; Thu, 16 Apr 2015 04:16:42 +0000 (UTC) Received: from mail-ig0-x233.google.com (mail-ig0-x233.google.com [IPv6:2607:f8b0:4001:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 15E16785 for ; Thu, 16 Apr 2015 04:16:42 +0000 (UTC) Received: by igbqf9 with SMTP id qf9so42190137igb.1 for ; Wed, 15 Apr 2015 21:16:41 -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:message-id:subject :from:to:cc:content-type; bh=/seDws/QQ1QbuL5N10886eLGRwf9rPD6aBl3vNWq5kg=; b=nprrTIGS2eDfGl2rOKNuYZuvujfAdpP9WcxwqfiTB3usE0NL8RfIwBO4HMDKb9MzWN kqr1mKUqQu9aisNiwEo1jKv7ZMbS7udIFNmCnTxdBQYA5qfmmqxsHvbKiCA3YPp4pvcH GMKR0SCyoKklFdq561qoodGm/jPZu76r+o4nNyyYzNUpul9GbYLdluQ4eqPnIm0gfTdy Mgpxb/l3bb4ofpmKEbF2ruYHEslnllv+XxcCeWWhhzkYdlHHrBuKwWD187tK4PmCvQXn HUgkUkl0tzK+4tyFJhsNYUxIyIRE2peU7m2tsqjaHGvMIWhrBHPUr9TB6Cp1f5HxsJMt 2EAA== MIME-Version: 1.0 X-Received: by 10.42.133.197 with SMTP id i5mr5010413ict.5.1429157801426; Wed, 15 Apr 2015 21:16:41 -0700 (PDT) Sender: kob6558@gmail.com Received: by 10.107.174.22 with HTTP; Wed, 15 Apr 2015 21:16:41 -0700 (PDT) In-Reply-To: References: <2F9DC176-912C-40C0-BAB7-DB66BD572ABA@vnode.se> <54D8E341.101@pix.net> <1423501720.16794.18.camel@freebsd.org> Date: Wed, 15 Apr 2015 21:16:41 -0700 X-Google-Sender-Auth: HfJWk_Xe3KBuqw0IVkn1Ne0_zU4 Message-ID: Subject: Re: freebsd-update and hang during reboot From: Kevin Oberman To: Nick Rogers Cc: FreeBSD STABLE Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 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, 16 Apr 2015 04:16:42 -0000 Thanks Steve, for providing this patch, but please note that for this to work, you MUST copy a GENERIC kernel into /boot as /boot/GENERIC. If you run a GENERIC kernel, just "cp /boot/kernel/kernel /boot/GENERIC". Details are in the Handbook at https://www.freebsd.org/doc/handbook/updating-upgrading-freebsdupdate.html. This means rebuilding a patched kernel after each update that touches the kernel. (Many do not!) Also be very careful with cutting and pasting this diff as whitespace can get messed up resulting in failures. ( NE +) Kevin Oberman, Network Engineer, Retired E-mail: rkoberman@gmail.com On Wed, Apr 15, 2015 at 2:44 PM, Nick Rogers wrote: > On Mon, Mar 9, 2015 at 9:19 AM, Nick Rogers wrote: > > > > > > > On Tue, Feb 10, 2015 at 1:37 PM, Nick Rogers wrote= : > > > >> > >> > >> On Mon, Feb 9, 2015 at 9:08 AM, Ian Lepore wrote: > >> > >>> On Mon, 2015-02-09 at 11:41 -0500, Kurt Lidl wrote: > >>> > Joel wrote: > >>> > > Hi, > >>> > > > >>> > > Just about every machine I have seems to hang after running > >>> freebsd-update and doing a reboot. The last message on the screen is > "All > >>> buffers synced=E2=80=9D and it just freezes. > >>> > > > >>> > > This happens when doing a freebsd-update and going from 10.0 to > >>> 10.1, but also when doing a fresh 10.1 install and using > freebsd-update to > >>> get the latest -pX security patches. As soon as I reboot the machine, > it > >>> hangs. > >>> > > > >>> > > I=E2=80=99ve tried it on several different HP ProLiant models, on= Intel > NUCs > >>> and on VMware virtual machines. Same phenomenon everywhere. It=E2=80= =99s really > >>> easy to trigger: just install 10.1, use default settings everywhere, > >>> freebsd-update fetch/install, shutdown -r now and BOOM. It hangs. I > think > >>> I=E2=80=99ve seen it on > >>> > > > >>> > > > >>> > > > >>> > > > >>> > > 30 servers or so now. > >>> > > > >>> > > Everything works like it should after the initial hang tough - no > >>> matter how many times I reboot it completes the reboot cycle just fin= e. > >>> > > > >>> > > I=E2=80=99ve seen several people (mostly on IRC) mention this pro= blem, but > >>> no solution. > >>> > > > >>> > > Is anyone working on fixing this? > >>> > > >>> > I ran into this problem in spades when upgrading a set of servers > from > >>> > FreeBSD 9.0 to 9.1. I happened consistently. Normal reboots worke= d, > >>> > but when going from 9.0 to 9.1, it *ALWAYS* hung, and it always hun= g > >>> > at the same place, after printing the "All buffers synced" message. > >>> > > >>> > I ultimately determined that if I did the following, rather than > >>> > just a "reboot" or "shutdown -r now 'FreeBSD 9.1-RELEASE upgrade'", > >>> > it would consistently AVOID the hang: > >>> > > >>> > sync ; sync ; sync ; shutdown -o -n -r now "FreeBSD 9.1 install" > >>> > > >>> > Your mileage may vary, but you don't have a lot to lose by trying i= t. > >>> > > >>> > -Kurt > >>> > > >>> > >>> That is just bad advice. sync(1) does not g'tee that all data has be= en > >>> written, no matter how many times you type it. shutdown -n tells the > >>> system to abandon unwritten data. All in all, this is a recipe for > >>> silent filesystem corruption. Using it after an update is just askin= g > >>> to have a mix of old and new files on the system after the reboot. > >>> > >>> A more robust workaround would be to "mount -r" on all filesystems > >>> before invoking the shutdown (even a shutdown -n should be safe after > >>> everything has been remounted readonly). If the mount -r hangs on on= e > >>> of the filesystems, then you've probably got a clue as to where a > normal > >>> shutdown is hanging. > >>> > >> > >> FWIW mount -r on the root filesystem hangs for me. If I disable > >> softupdates-journaling on the root filesystem before the upgrade > process, > >> the system no longer hangs on the last reboot after userland upgrade. > >> However, the root filesystem still comes up dirty with an incorrect fr= ee > >> block count during fsck. > >> > > > > Is anyone working on fixing this problem? It seems like this should ha= ve > > some kind of "full court press" as it is obviously affecting plenty of > > people, some of which have spoken up in the following PR > > > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D195458 > > > > I realize its a tough problem to track down, and if I had the appropria= te > > skills I would help. But so far all I've been able to do, like others, = is > > replicate and complain about the problem. > > > > Its still affecting upgrading to 10.1-RELEASE-p6 from the official > > 10.1-RELEASE distribution, and from 10.1-RELEASE-p5. I just had another > > production server hang during reboot after updating to p6, and I don't > see > > this changing for the inevitable p7 unless this problem gets more > > attention. Can someone with the right skill-set please help figure this > > out? Thank you. > > > > In case anyone is still dealing with this problem, the fix was MFC'd to > stable/10 a few days. I am assuming this will not end up getting back > ported to releng/10.1. I've compiled a patch with the fix that works > against 10.1-RELEASE. Maybe it will be useful for any of you like me that > don't run 10-stable, but are comfortable with custom kernels and are stil= l > dealing with this issue when running freebsd-update every time a new patc= h > level is released. Diff is below. > > # Fix bug causing a hang while unmounting the root filesystem during > # reboot after performing a freebsd-update. > # > # > # Original commit to HEAD: > # https://svnweb.freebsd.org/base?view=3Drevision&revision=3D280760 > # MFC to stable: > # https://svnweb.freebsd.org/base?view=3Drevision&revision=3D281350 > # > # The following commits were taken from stable/10/sys/ufs/ffs between > # the release of 10.1-RELEASE (r272459) and MFC of the fix (r281350) > # in order for the fix to cleanly apply to releng/10.1. The two > # unrelated commits seem like reasonable fixes to include as well. > # > # https://svnweb.freebsd.org/base?view=3Drevision&revision=3D281350 > # https://svnweb.freebsd.org/base?view=3Drevision&revision=3D278667 > # https://svnweb.freebsd.org/base?view=3Drevision&revision=3D274305 > # > Index: ufs/ffs/ffs_vfsops.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- ufs/ffs/ffs_vfsops.c (revision 272459) > +++ ufs/ffs/ffs_vfsops.c (revision 281350) > @@ -1502,8 +1502,11 @@ > if (fs->fs_fmod !=3D 0 && fs->fs_ronly !=3D 0 && ump->um_fsckpid =3D=3D= 0) > panic("%s: ffs_sync: modification on read-only filesystem", > fs->fs_fsmnt); > - if (waitfor =3D=3D MNT_LAZY) > - return (ffs_sync_lazy(mp)); > + if (waitfor =3D=3D MNT_LAZY) { > + if (!rebooting) > + return (ffs_sync_lazy(mp)); > + waitfor =3D MNT_NOWAIT; > + } > > /* > * Write back each (modified) inode. > @@ -1560,7 +1563,7 @@ > /* > * Force stale filesystem control information to be flushed. > */ > - if (waitfor =3D=3D MNT_WAIT) { > + if (waitfor =3D=3D MNT_WAIT || rebooting) { > if ((error =3D softdep_flushworklist(ump->um_mountp, &count, td))) > allerror =3D error; > /* Flushed work items may create new vnodes to clean */ > @@ -1577,9 +1580,12 @@ > if (bo->bo_numoutput > 0 || bo->bo_dirty.bv_cnt > 0) { > BO_UNLOCK(bo); > vn_lock(devvp, LK_EXCLUSIVE | LK_RETRY); > - if ((error =3D VOP_FSYNC(devvp, waitfor, td)) !=3D 0) > + error =3D VOP_FSYNC(devvp, waitfor, td); > + VOP_UNLOCK(devvp, 0); > + if (MOUNTEDSOFTDEP(mp) && (error =3D=3D 0 || error =3D=3D EAGAIN)) > + error =3D ffs_sbupdate(ump, waitfor, 0); > + if (error !=3D 0) > allerror =3D error; > - VOP_UNLOCK(devvp, 0); > if (allerror =3D=3D 0 && waitfor =3D=3D MNT_WAIT) > goto loop; > } else if (suspend !=3D 0) { > Index: ufs/ffs/ffs_softdep.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- ufs/ffs/ffs_softdep.c (revision 272459) > +++ ufs/ffs/ffs_softdep.c (revision 281350) > @@ -735,9 +735,10 @@ > static void check_clear_deps(struct mount *); > static void softdep_error(char *, int); > static int softdep_process_worklist(struct mount *, int); > -static int softdep_waitidle(struct mount *); > +static int softdep_waitidle(struct mount *, int); > static void drain_output(struct vnode *); > static struct buf *getdirtybuf(struct buf *, struct rwlock *, int); > +static int check_inodedep_free(struct inodedep *); > static void clear_remove(struct mount *); > static void clear_inodedeps(struct mount *); > static void unlinked_inodedep(struct mount *, struct inodedep *); > @@ -1377,6 +1378,10 @@ > mp =3D (struct mount *)addr; > ump =3D VFSTOUFS(mp); > atomic_add_int(&stat_flush_threads, 1); > + ACQUIRE_LOCK(ump); > + ump->softdep_flags &=3D ~FLUSH_STARTING; > + wakeup(&ump->softdep_flushtd); > + FREE_LOCK(ump); > if (print_threads) { > if (stat_flush_threads =3D=3D 1) > printf("Running %s at pid %d\n", bufdaemonproc->p_comm, > @@ -1389,7 +1394,7 @@ > VFSTOUFS(mp)->softdep_jblocks->jb_suspended)) > kthread_suspend_check(); > ACQUIRE_LOCK(ump); > - if ((ump->softdep_flags & FLUSH_CLEANUP) =3D=3D 0) > + if ((ump->softdep_flags & (FLUSH_CLEANUP | FLUSH_EXIT)) =3D=3D 0) > msleep(&ump->softdep_flushtd, LOCK_PTR(ump), PVM, > "sdflush", hz / 2); > ump->softdep_flags &=3D ~FLUSH_CLEANUP; > @@ -1419,11 +1424,9 @@ > > ump =3D VFSTOUFS(mp); > LOCK_OWNED(ump); > - if ((ump->softdep_flags & (FLUSH_CLEANUP | FLUSH_EXIT)) =3D=3D 0) { > + if ((ump->softdep_flags & (FLUSH_CLEANUP | FLUSH_EXIT)) =3D=3D 0) > ump->softdep_flags |=3D FLUSH_CLEANUP; > - if (ump->softdep_flushtd->td_wchan =3D=3D &ump->softdep_flushtd) > - wakeup(&ump->softdep_flushtd); > - } > + wakeup(&ump->softdep_flushtd); > } > > static int > @@ -1468,14 +1471,10 @@ > TAILQ_INSERT_TAIL(&softdepmounts, sdp, sd_next); > FREE_GBLLOCK(&lk); > if ((altump->softdep_flags & > - (FLUSH_CLEANUP | FLUSH_EXIT)) =3D=3D 0) { > + (FLUSH_CLEANUP | FLUSH_EXIT)) =3D=3D 0) > altump->softdep_flags |=3D FLUSH_CLEANUP; > - altump->um_softdep->sd_cleanups++; > - if (altump->softdep_flushtd->td_wchan =3D=3D > - &altump->softdep_flushtd) { > - wakeup(&altump->softdep_flushtd); > - } > - } > + altump->um_softdep->sd_cleanups++; > + wakeup(&altump->softdep_flushtd); > FREE_LOCK(altump); > } > } > @@ -1887,8 +1886,8 @@ > struct thread *td; > { > struct vnode *devvp; > - int count, error =3D 0; > struct ufsmount *ump; > + int count, error; > > /* > * Alternately flush the block device associated with the mount > @@ -1897,6 +1896,7 @@ > * are found. > */ > *countp =3D 0; > + error =3D 0; > ump =3D VFSTOUFS(oldmnt); > devvp =3D ump->um_devvp; > while ((count =3D softdep_process_worklist(oldmnt, 1)) > 0) { > @@ -1904,36 +1904,47 @@ > vn_lock(devvp, LK_EXCLUSIVE | LK_RETRY); > error =3D VOP_FSYNC(devvp, MNT_WAIT, td); > VOP_UNLOCK(devvp, 0); > - if (error) > + if (error !=3D 0) > break; > } > return (error); > } > > +#define SU_WAITIDLE_RETRIES 20 > static int > -softdep_waitidle(struct mount *mp) > +softdep_waitidle(struct mount *mp, int flags __unused) > { > struct ufsmount *ump; > - int error; > - int i; > + struct vnode *devvp; > + struct thread *td; > + int error, i; > > ump =3D VFSTOUFS(mp); > + devvp =3D ump->um_devvp; > + td =3D curthread; > + error =3D 0; > ACQUIRE_LOCK(ump); > - for (i =3D 0; i < 10 && ump->softdep_deps; i++) { > + for (i =3D 0; i < SU_WAITIDLE_RETRIES && ump->softdep_deps !=3D 0; i++)= { > ump->softdep_req =3D 1; > - if (ump->softdep_on_worklist) > - panic("softdep_waitidle: work added after flush."); > - msleep(&ump->softdep_deps, LOCK_PTR(ump), PVM, "softdeps", 1); > + KASSERT((flags & FORCECLOSE) =3D=3D 0 || > + ump->softdep_on_worklist =3D=3D 0, > + ("softdep_waitidle: work added after flush")); > + msleep(&ump->softdep_deps, LOCK_PTR(ump), PVM | PDROP, > + "softdeps", 10 * hz); > + vn_lock(devvp, LK_EXCLUSIVE | LK_RETRY); > + error =3D VOP_FSYNC(devvp, MNT_WAIT, td); > + VOP_UNLOCK(devvp, 0); > + if (error !=3D 0) > + break; > + ACQUIRE_LOCK(ump); > } > ump->softdep_req =3D 0; > - FREE_LOCK(ump); > - error =3D 0; > - if (i =3D=3D 10) { > + if (i =3D=3D SU_WAITIDLE_RETRIES && error =3D=3D 0 && ump->softdep_deps= !=3D 0) { > error =3D EBUSY; > printf("softdep_waitidle: Failed to flush worklist for %p\n", > mp); > } > - > + FREE_LOCK(ump); > return (error); > } > > @@ -1990,7 +2001,7 @@ > error =3D EBUSY; > } > if (!error) > - error =3D softdep_waitidle(oldmnt); > + error =3D softdep_waitidle(oldmnt, flags); > if (!error) { > if (oldmnt->mnt_kern_flag & MNTK_UNMOUNT) { > retry =3D 0; > @@ -2490,9 +2501,18 @@ > /* > * Start our flushing thread in the bufdaemon process. > */ > + ACQUIRE_LOCK(ump); > + ump->softdep_flags |=3D FLUSH_STARTING; > + FREE_LOCK(ump); > kproc_kthread_add(&softdep_flush, mp, &bufdaemonproc, > &ump->softdep_flushtd, 0, 0, "softdepflush", "%s worker", > mp->mnt_stat.f_mntonname); > + ACQUIRE_LOCK(ump); > + while ((ump->softdep_flags & FLUSH_STARTING) !=3D 0) { > + msleep(&ump->softdep_flushtd, LOCK_PTR(ump), PVM, "sdstart", > + hz / 2); > + } > + FREE_LOCK(ump); > /* > * When doing soft updates, the counters in the > * superblock may have gotten out of sync. Recomputation > @@ -7629,17 +7649,13 @@ > return (1); > } > > -/* > - * Try to free an inodedep structure. Return 1 if it could be freed. > - */ > static int > -free_inodedep(inodedep) > +check_inodedep_free(inodedep) > struct inodedep *inodedep; > { > > LOCK_OWNED(VFSTOUFS(inodedep->id_list.wk_mp)); > - if ((inodedep->id_state & (ONWORKLIST | UNLINKED)) !=3D 0 || > - (inodedep->id_state & ALLCOMPLETE) !=3D ALLCOMPLETE || > + if ((inodedep->id_state & ALLCOMPLETE) !=3D ALLCOMPLETE || > !LIST_EMPTY(&inodedep->id_dirremhd) || > !LIST_EMPTY(&inodedep->id_pendinghd) || > !LIST_EMPTY(&inodedep->id_bufwait) || > @@ -7654,6 +7670,21 @@ > inodedep->id_nlinkdelta !=3D 0 || > inodedep->id_savedino1 !=3D NULL) > return (0); > + return (1); > +} > + > +/* > + * Try to free an inodedep structure. Return 1 if it could be freed. > + */ > +static int > +free_inodedep(inodedep) > + struct inodedep *inodedep; > +{ > + > + LOCK_OWNED(VFSTOUFS(inodedep->id_list.wk_mp)); > + if ((inodedep->id_state & (ONWORKLIST | UNLINKED)) !=3D 0 || > + !check_inodedep_free(inodedep)) > + return (0); > if (inodedep->id_state & ONDEPLIST) > LIST_REMOVE(inodedep, id_deps); > LIST_REMOVE(inodedep, id_hash); > @@ -13838,7 +13869,8 @@ > { > struct bufobj *bo; > struct ufsmount *ump; > - int error; > + struct inodedep *inodedep; > + int error, unlinked; > > bo =3D &devvp->v_bufobj; > ASSERT_BO_WLOCKED(bo); > @@ -13899,6 +13931,20 @@ > break; > } > > + unlinked =3D 0; > + if (MOUNTEDSUJ(mp)) { > + for (inodedep =3D TAILQ_FIRST(&ump->softdep_unlinked); > + inodedep !=3D NULL; > + inodedep =3D TAILQ_NEXT(inodedep, id_unlinked)) { > + if ((inodedep->id_state & (UNLINKED | UNLINKLINKS | > + UNLINKONLIST)) !=3D (UNLINKED | UNLINKLINKS | > + UNLINKONLIST) || > + !check_inodedep_free(inodedep)) > + continue; > + unlinked++; > + } > + } > + > /* > * Reasons for needing more work before suspend: > * - Dirty buffers on devvp. > @@ -13908,8 +13954,8 @@ > error =3D 0; > if (bo->bo_numoutput > 0 || > bo->bo_dirty.bv_cnt > 0 || > - softdep_depcnt !=3D 0 || > - ump->softdep_deps !=3D 0 || > + softdep_depcnt !=3D unlinked || > + ump->softdep_deps !=3D unlinked || > softdep_accdepcnt !=3D ump->softdep_accdeps || > secondary_writes !=3D 0 || > mp->mnt_secondary_writes !=3D 0 || > Index: ufs/ffs/softdep.h > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- ufs/ffs/softdep.h (revision 272459) > +++ ufs/ffs/softdep.h (revision 281350) > @@ -1063,6 +1063,8 @@ > */ > #define FLUSH_EXIT 0x0001 /* time to exit */ > #define FLUSH_CLEANUP 0x0002 /* need to clear out softdep structures */ > +#define FLUSH_STARTING 0x0004 /* flush thread not yet started */ > + > /* > * Keep the old names from when these were in the ufsmount structure. > */ > > > > > > >>> -- Ian > >>> > >>> > >>> _______________________________________________ > >>> 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 > >>> " > >>> > >> > >> > > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From owner-freebsd-stable@FreeBSD.ORG Thu Apr 16 06:21:08 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 34B1DB88 for ; Thu, 16 Apr 2015 06:21:08 +0000 (UTC) Received: from mail-pd0-x232.google.com (mail-pd0-x232.google.com [IPv6:2607:f8b0:400e:c02::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id F06EB277 for ; Thu, 16 Apr 2015 06:21:07 +0000 (UTC) Received: by pdbqa5 with SMTP id qa5so80400120pdb.1 for ; Wed, 15 Apr 2015 23:21:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=NdZ+8YjccJg84V6lgYAbGzkmBa4iN3rGx5tJhLMd7jY=; b=BualWB+nKhxtKSTkFjRpYgX3iOA436TETrnXe7vjxQW1oQB2mdJgjQkfOWg9G0fJTs +jsR4LhO0aW3Zz1IFPbtulEjeE6ZzlvoNbFGUQLKTWRKXODhWUOq1+zX3HLCYwEMRLNo wmofi7ydhl6K3vwOhgDAZRUZXorm1KtKqlIcIy/ELG3BbPzLs2xMhFGzz0d4OUjeXXV0 7WgzJZbL3r4vuEgv8o5Zwy4f51yJfupjAWVKPnr8RvKuB+K9ax1HtiUuypuZLBaplLNw 2hTqYRZCyKWvDbnE/Yq8HqrZYDmVxPVWugh4qUO7qPkpzZbQlmix4V+8ycqVJTPxxzNw mLhw== X-Received: by 10.70.133.194 with SMTP id pe2mr53588093pdb.57.1429165267448; Wed, 15 Apr 2015 23:21:07 -0700 (PDT) Received: from pyunyh@gmail.com ([106.247.248.2]) by mx.google.com with ESMTPSA id da10sm5963771pac.42.2015.04.15.23.21.03 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 15 Apr 2015 23:21:05 -0700 (PDT) From: Yonghyeon PYUN X-Google-Original-From: "Yonghyeon PYUN" Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Thu, 16 Apr 2015 15:20:56 +0900 Date: Thu, 16 Apr 2015 15:20:56 +0900 To: Gareth Wyn Roberts Cc: "freebsd-stable@freebsd.org" Subject: Re: msk msk0 watchdog timeout freeze hang lock stop problem Message-ID: <20150416062056.GA970@michelle.fasterthan.com> Reply-To: pyunyh@gmail.com References: <20150413081348.GA965@michelle.fasterthan.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="liOOAslEiF7prFVr" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 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, 16 Apr 2015 06:21:08 -0000 --liOOAslEiF7prFVr Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wed, Apr 15, 2015 at 09:52:09PM +0000, Gareth Wyn Roberts wrote: > I've inserted code to print some values which show the differences between specifying 4096 or 8192 for MSK_STAT_ALIGN. In both cases the status buffer has length 0x4000 (8x2048=16K) but the alignments are different as expected, respectively start addresses 0x5c3b000 or 0xbdc2c000. > > The following values were output from functions msk_status_dma_alloc(), msk_dmamap_cb() and msk_handle_events(). > The "Break #n" refer to breaks in msk_handle_events(). "#1" occurs if ((control & HW_OWNER) == 0), "#5" is OP_RXSTAT and "#6" is OP_TXINDEXLE. > > The first output is for MSK_STAT_ALIGN=8192. It continues normally. Although not shown here, it reaches cons=2047 then cons=0 as expected. > > The second output is for MSK_STAT_ALIGN=4096. Although there can be isolated occurences of "Break #1" (e.g. cons=196) (?are these to be expected?), it continues normally until cons=512. At this point it continually invokes the "#1" block because the msk_control from msk_stat_ring[512] is always zero and the network hangs immediately. This suggests the Yukon Ultra 2 88E8057 can't access the next 4096 memory block, but why not? > Yes, it seems the status LE block is not updated at all for MSK_STAT_ALIGN == 4096 and some elements of the status block looks suspicious(put index increases but the value in the location is 0). I vaguely guess this indicates there are DMA alignment and/or DMA boundary issues. The maximum number of elements of the status block is 4096 so the maximum size of the status block is 32KB. For i386, msk(4) uses 8KB status block(1024 elements). For 64bit architectures, the block size is increased to 16KB(2048 elements). Probably the safe alignment value for the status block would be 32K. This looks excessive value to me but it shall avoid guessing DMA boundary issue. > Please let me know if any further information would be helpful. > Thanks a lot. I've attached a diff which sets the alignment of TX/RX ring and status block to 32KB. Not sure whether this also addresses other msk(4) related watchdog timeouts. --liOOAslEiF7prFVr Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="msk.align.diff" Index: sys/dev/msk/if_mskreg.h =================================================================== --- sys/dev/msk/if_mskreg.h (revision 281587) +++ sys/dev/msk/if_mskreg.h (working copy) @@ -2175,13 +2175,8 @@ #define MSK_ADDR_LO(x) ((uint64_t) (x) & 0xffffffffUL) #define MSK_ADDR_HI(x) ((uint64_t) (x) >> 32) -/* - * At first I guessed 8 bytes, the size of a single descriptor, would be - * required alignment constraints. But, it seems that Yukon II have 4096 - * bytes boundary alignment constraints. - */ -#define MSK_RING_ALIGN 4096 -#define MSK_STAT_ALIGN 4096 +#define MSK_RING_ALIGN 32768 +#define MSK_STAT_ALIGN 32768 /* Rx descriptor data structure */ struct msk_rx_desc { --liOOAslEiF7prFVr-- From owner-freebsd-stable@FreeBSD.ORG Thu Apr 16 11:54:53 2015 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F17D2C11 for ; Thu, 16 Apr 2015 11:54:52 +0000 (UTC) Received: from woozle.rinet.ru (woozle.rinet.ru [195.54.192.68]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 801FEE5A for ; Thu, 16 Apr 2015 11:54:51 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by woozle.rinet.ru (8.14.5/8.14.5) with ESMTP id t3GBlRDC010708; Thu, 16 Apr 2015 14:47:27 +0300 (MSK) (envelope-from marck@rinet.ru) Date: Thu, 16 Apr 2015 14:47:27 +0300 (MSK) From: Dmitry Morozovsky To: Walter Cramer cc: freebsd-stable@FreeBSD.org Subject: Re: [GEOM] Disk IO error when resyncing gmirror -> massive hang in D state In-Reply-To: <20150415132245.B71411@mulder.mintsol.com> Message-ID: References: <20150415132245.B71411@mulder.mintsol.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]); Thu, 16 Apr 2015 14:48:34 +0300 (MSK) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 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, 16 Apr 2015 11:54:53 -0000 Walter, thanks for your suggestions. to quickly answer: I' already evacuated data to the new drive (see the last paragraph of my original message). Luckily no critical data were on failed disk part, so rsync finished well the very first pass. The only question still actually open for me is why the kernel was stuck in geom, not returning read/write errors to the applications I'll try to collect lab machine with this drive (which is still by my work table) and reproduce the error. On Wed, 15 Apr 2015, Walter Cramer wrote: > Here are a few ideas I had, if more capable people have not already sent you > better ones: > > Copy as much important data as possible from the Toshiba drive, since it could > degrade further or die at any time. > > Check whether a 'dd' command can quickly reproduce the error, so you can try > things faster. > > If the failing drive is not fairly cold, try chilling it with a strong fan. > > Briefly put the drive in another system, to see if using a different power > supply, controller, data cable, etc. would help. Changing the orientation > (direction of gravity on the drive) might also be good. > > If nothing else helped, a tiny c language program might use open(), read(), > lseek(), write(), etc. to copy all readable sectors to your replacement disk > (using zeros for the unreadable bad sectors). > > -Walter > > > On Tue, 14 Apr 2015, Dmitry Morozovsky wrote: > > > Dear colleagues, > > > > unfortunately, the machine in question is in productin, so I have no clear > > reproduce case. I do have console logs, however. > > > > prerequisites: > > - rather fresh stable/10, amd64, SuperMicro MicroCloud 1150, X10SLD-F/HF > > - su+j ufs2 on top of gmirror of two SATA Toshiba drives > > - one disk died some time ago, so gmirror works in degraded state > > > > trouble: > > - inserted new drive, labelled, started gmirror resync > > - apparently remaining drive also has read issues: > > (ada0:ahcich1:0:0:0): READ_FPDMA_QUEUED. ACB: 60 00 10 b2 c3 40 01 00 00 01 > > 00 00 > > (ada0:ahcich1:0:0:0): CAM status: ATA Status Error > > (ada0:ahcich1:0:0:0): ATA status: 41 (DRDY ERR), error: 40 (UNC ) > > (ada0:ahcich1:0:0:0): RES: 41 40 04 b3 c3 40 01 00 00 00 01 > > (ada0:ahcich1:0:0:0): Error 5, Retries exhausted > > GEOM_MIRROR: Request failed (error=5). ada0a[READ(offset=6566445056, > > length=131072)] > > GEOM_MIRROR: Synchronization request failed (error=5). > > mirror/m0a[READ(offset=6566445056, length=131072)] > > > > at this point, all requests to disk I/O are stalled, all cron jobs, syslogd, > > dchpd, etc. > > > > Situation reproduce itself at least two times, then as an emergency new > > drive > > had been labelled independently and rsynced over. > > > > Any thoughts? > > > > Thanks in advance! > > > > > > -- > > Sincerely, > > D.Marck [DM5020, MCK-RIPE, DM3-RIPN] > > [ FreeBSD committer: marck@FreeBSD.org ] > > ------------------------------------------------------------------------ > > *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** > > ------------------------------------------------------------------------ > > _______________________________________________ > > 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" > -- 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 Thu Apr 16 15:57:48 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B18C6453 for ; Thu, 16 Apr 2015 15:57:48 +0000 (UTC) Received: from khavrinen.csail.mit.edu (khavrinen.csail.mit.edu [IPv6:2001:470:8b2d:1e1c:21b:21ff:feb8:d7b0]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "khavrinen.csail.mit.edu", Issuer "Client CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 6C132F14 for ; Thu, 16 Apr 2015 15:57:48 +0000 (UTC) Received: from khavrinen.csail.mit.edu (localhost [127.0.0.1]) by khavrinen.csail.mit.edu (8.14.9/8.14.9) with ESMTP id t3GFvkXw077714 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL CN=khavrinen.csail.mit.edu issuer=Client+20CA) for ; Thu, 16 Apr 2015 11:57:46 -0400 (EDT) (envelope-from wollman@khavrinen.csail.mit.edu) Received: (from wollman@localhost) by khavrinen.csail.mit.edu (8.14.9/8.14.9/Submit) id t3GFvjl9077711; Thu, 16 Apr 2015 11:57:45 -0400 (EDT) (envelope-from wollman) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21807.56313.968764.118664@khavrinen.csail.mit.edu> Date: Thu, 16 Apr 2015 11:57:45 -0400 From: Garrett Wollman To: freebsd-stable@freebsd.org Subject: auditd zombies in 10.1? X-Mailer: VM 7.17 under 21.4 (patch 22) "Instant Classic" XEmacs Lucid X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (khavrinen.csail.mit.edu [127.0.0.1]); Thu, 16 Apr 2015 11:57:46 -0400 (EDT) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 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, 16 Apr 2015 15:57:48 -0000 I notice that systems of ours which were recently upgraded to 10.1 are accumulating zombies at an alarming rate. (Well, alarming enough to cause me to be paged at 4 in the morning, at any rate!) These zombies are all children of auditd. Has anyone else seen or debugged this? -GAWollman From owner-freebsd-stable@FreeBSD.ORG Fri Apr 17 01:52:04 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from hub.FreeBSD.org (hub.freebsd.org [IPv6:2001:1900:2254:206c::16:88]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 85547CD3; Fri, 17 Apr 2015 01:52:03 +0000 (UTC) Date: Fri, 17 Apr 2015 01:52:00 +0000 From: Glen Barber To: Nick Rogers Cc: FreeBSD STABLE Subject: Re: freebsd-update and hang during reboot Message-ID: <20150417015200.GA1338@hub.FreeBSD.org> References: <2F9DC176-912C-40C0-BAB7-DB66BD572ABA@vnode.se> <54D8E341.101@pix.net> <1423501720.16794.18.camel@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="OXfL5xGRrasGEqWY" Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD 11.0-CURRENT amd64 X-SCUD-Definition: Sudden Completely Unexpected Dataloss X-SULE-Definition: Sudden Unexpected Learning Event User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 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, 17 Apr 2015 01:52:04 -0000 --OXfL5xGRrasGEqWY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Apr 15, 2015 at 02:44:44PM -0700, Nick Rogers wrote: > On Mon, Mar 9, 2015 at 9:19 AM, Nick Rogers wrote: > > Is anyone working on fixing this problem? It seems like this should have > > some kind of "full court press" as it is obviously affecting plenty of > > people, some of which have spoken up in the following PR > > > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D195458 > > > > I realize its a tough problem to track down, and if I had the appropria= te > > skills I would help. But so far all I've been able to do, like others, = is > > replicate and complain about the problem. > > > > Its still affecting upgrading to 10.1-RELEASE-p6 from the official > > 10.1-RELEASE distribution, and from 10.1-RELEASE-p5. I just had another > > production server hang during reboot after updating to p6, and I don't = see > > this changing for the inevitable p7 unless this problem gets more > > attention. Can someone with the right skill-set please help figure this > > out? Thank you. > > >=20 > In case anyone is still dealing with this problem, the fix was MFC'd to > stable/10 a few days. I am assuming this will not end up getting back > ported to releng/10.1. An EN for 10.1-RELEASE is planned. Glen --OXfL5xGRrasGEqWY Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJVMGdAAAoJEAMUWKVHj+KTAyoP/0PSJhBb7oKWm2D37QAAZciF /BfZlPY8Oseyr+ZLjXybjPZZ/4UDLULiNUlG+HSD58yNptS6WTZAHYoyIbPJ5RiK 8nzd6MLOjEyPrtPAcDyp1O/3J65gpWG9uck8gLi1pB2OBIiOhLAdxcz7lomOzH+o r5CsyBupYevJDT/7+AzgANOlRbF0xw+HjTm9r+SwVPOROFUEn6oolyCizLODT91Z MyT2/hluFpe+5PLgZWoIgqbhtr2ydfEm/4FVqcnsNqVSDNXqJT43J6mAdu+ERkmL wqSxWg4KiaO9ehQjsD/OhKhzhVmqYtxNXs6AAWboza6ecoDIWNecUPAtCU/eB63j ot3GF2dD9vT3BQYYNBxTqVpojKCxT6m6xV2ZYqcVnd9U5s3ytI0AF0E8pDAz8qN+ LUBm2Kr5OGe2MHINPa/xoD4yy+3tgHi+31mo8KGI8JfKCUrjgwzogPGvvqdH9e41 rP/E/IL/ebbMMJXCS4kXmtjgK4f3sm7nhMNPCoy5sDioTc8zDkgilxIqPey7AcDE YtiTDf6fzr6fWVocXhcjWPk4hwNTSKfLbb1uGst7xWWR22QYVfdpVKiqg3dZk299 nYuvhn0tMgiarrVP5fhvWsURwNZ7siig8cZMzXO9JScrsy3Ou5qDfx+5iDDqxrtZ d9ItNSGN00rsIxJElP29 =5M9L -----END PGP SIGNATURE----- --OXfL5xGRrasGEqWY-- From owner-freebsd-stable@FreeBSD.ORG Fri Apr 17 10:16:45 2015 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6753E501 for ; Fri, 17 Apr 2015 10:16:45 +0000 (UTC) Received: from woozle.rinet.ru (woozle.rinet.ru [195.54.192.68]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DCB14876 for ; Fri, 17 Apr 2015 10:16:44 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by woozle.rinet.ru (8.14.5/8.14.5) with ESMTP id t3HADfFC025485 for ; Fri, 17 Apr 2015 13:14:41 +0300 (MSK) (envelope-from marck@rinet.ru) Date: Fri, 17 Apr 2015 13:13:41 +0300 (MSK) From: Dmitry Morozovsky To: freebsd-stable@FreeBSD.org Subject: building stable/10 on stable/9 Message-ID: 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]); Fri, 17 Apr 2015 13:14:48 +0300 (MSK) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 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, 17 Apr 2015 10:16:45 -0000 Dear colleagues, is this path unsupported now? I have marck@beaver:/FreeBSD/pristine/src.10> uname -a FreeBSD beaver.rinet.ru 9.3-STABLE FreeBSD 9.3-STABLE #2 r281609: Thu Apr 16 22:43:32 MSK 2015 marck@beaver.rinet.ru:/usr/obj/usr/src/sys/BEAVER amd64 ... and /FreeBSD/pristine/src.10/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/copyhostent.c:42: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'struct' *** Error code 1 Stop. bmake[2]: stopped in /FreeBSD/pristine/src.10/kerberos5/lib/libroken *** Error code 1 Thanks in advance. -- 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 Fri Apr 17 20:55:53 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 01313A22 for ; Fri, 17 Apr 2015 20:55:52 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id E1991C9E for ; Fri, 17 Apr 2015 20:55:52 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 48DEA32A for ; Fri, 17 Apr 2015 20:55:53 +0000 (UTC) Date: Fri, 17 Apr 2015 20:55:53 +0000 (GMT) From: jenkins-admin@freebsd.org To: freebsd-stable@freebsd.org Message-ID: <1677302908.14.1429304153244.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <634241330.13.1429295835613.JavaMail.jenkins@jenkins-9.freebsd.org> References: <634241330.13.1429295835613.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build is back to normal : Build-UFS-image #1512 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Instance-Identity: MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkKKb2VAfYQKfu1t7qk4nR5qzUBEI+UqT4BPec4qHVhqUy0FFdq50sMH+3y9bCDNOufctov6VqTNffZ3YXArnZK95YF0OX97fh+E9txYOUX1adc+TikcKjuYpHmL5dE62eaZTI+4A5jnRonskQ1PaoIFz0Kbu4mWzkFsmdiXTraGzomXq4cHUCATA2+K4eDYgjXEQI30z3GOMmmZ4t/+6QGk1cMb/BqMWHbn80AsRCb4tU7Hpd72XLDpsuO7YRP1Q0CjmNAuBOTj+sFiiOe6U9HpqOlQN+iFUvBdZo/ybuy5Kh71cAaYQNL68cYdZJ6binH/DkG3KY/fS7DFYAeuwjwIDAQAB X-Jenkins-Job: Build-UFS-image X-Jenkins-Result: SUCCESS X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 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, 17 Apr 2015 20:55:53 -0000 See From owner-freebsd-stable@FreeBSD.ORG Fri Apr 17 21:32:48 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6C448726; Fri, 17 Apr 2015 21:32:48 +0000 (UTC) Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2F24AD0; Fri, 17 Apr 2015 21:32:48 +0000 (UTC) Received: by oica37 with SMTP id a37so83192517oic.0; Fri, 17 Apr 2015 14:32:47 -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=qtiZf0wzy2Yji11E6SeY50j0nufdK0qtb6Fk5G2dGLo=; b=dWj0P85W6axtCylecQkCsG5PNtdQAMNrDrlp8Zp+hBpR59ZxJmXLhHdYyuuS/dHzx9 BVJTMRWDNOipensSSKe/n/y/JFUCG72/TP4lFM6OSA3PhZAxVc8L0i9931Xkks1fqc2F /85tmRvLYR1YMvynd1ivncS0U9FPBP5zhVJtRAKRM3Fhxdg8n7fki4LhAtCO0w2BpFXJ jvZnSH2WojQ+1b0CaAmnUcmS2+05y2A5ZwjkyVUggbrvn25AOXLsQ0bLxpoNgNkpzuUi LyBBLA6y21E3G+xEOB9C7z/ovHMrrEAIANoxXYxvPIqL3ccOaSA545vJjnIN2bu/qoCl g75w== MIME-Version: 1.0 X-Received: by 10.202.219.195 with SMTP id s186mr4508180oig.25.1429306367461; Fri, 17 Apr 2015 14:32:47 -0700 (PDT) Received: by 10.202.44.196 with HTTP; Fri, 17 Apr 2015 14:32:47 -0700 (PDT) In-Reply-To: <20150417015200.GA1338@hub.FreeBSD.org> References: <2F9DC176-912C-40C0-BAB7-DB66BD572ABA@vnode.se> <54D8E341.101@pix.net> <1423501720.16794.18.camel@freebsd.org> <20150417015200.GA1338@hub.FreeBSD.org> Date: Fri, 17 Apr 2015 14:32:47 -0700 Message-ID: Subject: Re: freebsd-update and hang during reboot From: Nick Rogers To: Glen Barber Cc: FreeBSD STABLE Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 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, 17 Apr 2015 21:32:48 -0000 On Thu, Apr 16, 2015 at 6:52 PM, Glen Barber wrote: > On Wed, Apr 15, 2015 at 02:44:44PM -0700, Nick Rogers wrote: > > On Mon, Mar 9, 2015 at 9:19 AM, Nick Rogers wrote: > > > Is anyone working on fixing this problem? It seems like this should > have > > > some kind of "full court press" as it is obviously affecting plenty of > > > people, some of which have spoken up in the following PR > > > > > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195458 > > > > > > I realize its a tough problem to track down, and if I had the > appropriate > > > skills I would help. But so far all I've been able to do, like others, > is > > > replicate and complain about the problem. > > > > > > Its still affecting upgrading to 10.1-RELEASE-p6 from the official > > > 10.1-RELEASE distribution, and from 10.1-RELEASE-p5. I just had another > > > production server hang during reboot after updating to p6, and I don't > see > > > this changing for the inevitable p7 unless this problem gets more > > > attention. Can someone with the right skill-set please help figure this > > > out? Thank you. > > > > > > > In case anyone is still dealing with this problem, the fix was MFC'd to > > stable/10 a few days. I am assuming this will not end up getting back > > ported to releng/10.1. > > An EN for 10.1-RELEASE is planned. > Oh thats good to know. Thank you. I had asked that in the related bug a week or so ago and did not receive a response, so I figured it would not. Any idea the eta for the EN? > Glen > > From owner-freebsd-stable@FreeBSD.ORG Fri Apr 17 22:08:30 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from hub.FreeBSD.org (hub.freebsd.org [IPv6:2001:1900:2254:206c::16:88]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 77AA0C99; Fri, 17 Apr 2015 22:08:29 +0000 (UTC) Date: Fri, 17 Apr 2015 22:08:25 +0000 From: Glen Barber To: Nick Rogers Cc: FreeBSD STABLE Subject: Re: freebsd-update and hang during reboot Message-ID: <20150417220825.GA1311@hub.FreeBSD.org> References: <2F9DC176-912C-40C0-BAB7-DB66BD572ABA@vnode.se> <54D8E341.101@pix.net> <1423501720.16794.18.camel@freebsd.org> <20150417015200.GA1338@hub.FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="HlL+5n6rz5pIUxbD" Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD 11.0-CURRENT amd64 X-SCUD-Definition: Sudden Completely Unexpected Dataloss X-SULE-Definition: Sudden Unexpected Learning Event User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 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, 17 Apr 2015 22:08:30 -0000 --HlL+5n6rz5pIUxbD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Apr 17, 2015 at 02:32:47PM -0700, Nick Rogers wrote: > On Thu, Apr 16, 2015 at 6:52 PM, Glen Barber wrote: > > On Wed, Apr 15, 2015 at 02:44:44PM -0700, Nick Rogers wrote: > > > In case anyone is still dealing with this problem, the fix was MFC'd = to > > > stable/10 a few days. I am assuming this will not end up getting back > > > ported to releng/10.1. > > > > An EN for 10.1-RELEASE is planned. > > >=20 > Oh thats good to know. Thank you. I had asked that in the related bug a > week or so ago and did not receive a response, so I figured it would not. > Any idea the eta for the EN? >=20 I'm behind on email, and saw your email to this list first. No ETA yet, but it is being worked on. Glen --HlL+5n6rz5pIUxbD Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJVMYRZAAoJEAMUWKVHj+KTf74P/0gN/8atMjgNn6DfphDE81JL lsIk60a2o6fNxLtsrlSAYfQSdsZWXYVMA1AG7+GskAAHAFqP/QJmwGr4khAms0on ZS+3z36R/GItm489uMcwHsQYKulPl4lm0BhQQoo+V7oiSa3Sw5H60bx4dOI3NHi0 uYyeSyNLkF6E2OZV6TUeAnRev52bK2y9R3b5mKCxkQLeLMK5yU5b+EKzI+6KF3Jj mxnGzwWwjHeAc0bpkckEl/Zn7b65HE9/ltIYVKfLKvswbQusib8z2xPbw+OMRfZq E1HyZWxObxhiIXEHMTYNx7uNftj1K8nd2mHdiyhYOtuefL7SOsJ6uy2XO+rUzHP+ YlvfW6Y6GJRJ5Sjk38U7wFbxRClft1Rpy0mtC9ahH/XtVynPka/I3ucf4uPkg9pa IpRK1RKaeywXhFQg/VO+0n/DhedSw0my7t+Rx7GNB4HUbXHfc0MGMnCTZQtbrZ9/ o5x5Mb00rFatJI1rB/f3QhJkuGjT/V3jW7qHoysvE6/BPQL99EEQqsBsOkSQrCe6 zgKx5faEMKMyA7z7gvTMYw/KtOoAdKDGeoDmFPWtaD14AuF6yoKP3K4DjsipV9nw KxNs3bnt9PBc+6p7r7G9nUrPzJrnSp3d2ut4GsdKq2NKzs2TO1NR3L7c1qeQ2qkG uE8K+CfA30ppsxeVWAZg =MiB6 -----END PGP SIGNATURE----- --HlL+5n6rz5pIUxbD--