From owner-freebsd-stable@FreeBSD.ORG Sun Jul 5 18:06:55 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D59991065670 for ; Sun, 5 Jul 2009 18:06:55 +0000 (UTC) (envelope-from amarat@ksu.ru) Received: from mx.kzn.ru (mx.kzn.ru [194.85.243.38]) by mx1.freebsd.org (Postfix) with ESMTP id B412B8FC13 for ; Sun, 5 Jul 2009 18:06:53 +0000 (UTC) (envelope-from amarat@ksu.ru) Authentication-Results: iout.kzn.ru; dkim=neutral (message not signed) header.i=none Received-SPF: None identity=pra; client-ip=193.232.252.56; receiver=iout.kzn.ru; envelope-from="amarat@ksu.ru"; x-sender="amarat@ksu.ru"; x-conformance=sidf_compatible Received-SPF: None identity=mailfrom; client-ip=193.232.252.56; receiver=iout.kzn.ru; envelope-from="amarat@ksu.ru"; x-sender="amarat@ksu.ru"; x-conformance=sidf_compatible Received-SPF: None identity=helo; client-ip=193.232.252.56; receiver=iout.kzn.ru; envelope-from="amarat@ksu.ru"; x-sender="postmaster@ruby.ksu.ru"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgkFANOFUErCVfWh/2dsb2JhbACBUMd3gnaBHAWBOg X-IronPort-AV: E=Sophos;i="4.42,352,1243800000"; d="p7s'?scan'208";a="4184188" Received: from mail.ksu.ru (HELO ruby.ksu.ru) ([193.232.252.56]) by iout.kzn.ru with ESMTP; 05 Jul 2009 21:56:25 +0400 X-Pass-Through: Kazan State University Network Received: from zealot.ksu.ru ([194.85.245.161]) by ksu.ru (8.13.4/8.13.4) with ESMTP id n65H3xP4004329 for ; Sun, 5 Jul 2009 17:04:00 GMT Received: from zealot.ksu.ru (localhost.lnet [127.0.0.1]) by zealot.ksu.ru (8.14.3/8.14.3) with ESMTP id n65HuNqw026638 for ; Sun, 5 Jul 2009 21:56:23 +0400 (MSD) (envelope-from amarat@ksu.ru) Message-ID: <4A50E947.9020608@ksu.ru> Date: Sun, 05 Jul 2009 21:56:23 +0400 From: "Marat N.Afanasyev" User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.8.1.22) Gecko/20090704 SeaMonkey/1.1.17 MIME-Version: 1.0 To: FreeBSD-STABLE Mailing List Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000900070902020105010703" Subject: bug in ufs? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jul 2009 18:06:56 -0000 This is a cryptographically signed message in MIME format. --------------ms000900070902020105010703 Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit hello! i have a strange problem with writing data to my ufs2+su filesystem. 1. i made a 1T gpt partition on my storage server, and formatted it: newfs -U -m 0 -o time -i 32768 /dev/da1p3a 2. i tried to move data from other servers to this filesystem, total size of files is slightly less than 1T 3. i encountered a 'No space left on device' while i still have 11G of free space and about 13 million free inodes on the filesystem: #df -ih Filesystem Size Used Avail Capacity iused ifree %iused Mounted on /dev/da1p3a 1.0T 1.0T 11G 99% 20397465 13363173 60% /mnt/45_114 all i want to know is whether this is a bug or a feature? and if such a behavior is well-known, where can i read about it? -- SY, Marat --------------ms000900070902020105010703 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII8zCC AtQwggI9oAMCAQICEHpsMo6nkbUVegxjAzzxYCkwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDQwMTE5MTUxOFoX DTEwMDQwMTE5MTUxOFowPzEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEcMBoG CSqGSIb3DQEJARYNYW1hcmF0QGtzdS5ydTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALqa7MfgjbsxmgpTOKxAN7w+cFViFA8NrULAARwVQJQJCnVRGf3i97EwNdLE8VTNniU4 ybS4gtLsy9gfNuuyPV2AJESpgrxaG+KZyHu1f6P4e31YBbnbtWVTUxZ3U/vWoL+BOAOI4S84 Cx834a4uYK75WhpZKd56qet5loyn9N1wBZNgCh9AwU31lA/Q0iCSKpEIxuhbElNXHNnqAlts CtNXsKgsT8mP7QI52h0cBOPSZqvz++e/wruJGgKeCECqo8ftwwya3CYkH1lhH2Q1zeXwez1E 1+solM48odH+odn29ctmOqr3PzZfmBJyGFf5FagTKNia/ys48yBtVU/RXHsCAwEAAaMqMCgw GAYDVR0RBBEwD4ENYW1hcmF0QGtzdS5ydTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUA A4GBAG4Pj7KRSJ/M28KNynJOPCHg26L15S9OfQ+ckMaPPDRAejtdlUdCgkoyD9d1Du/amAk6 A3NcY2I/MsFW2vSonQfU+7cJZiyuhfw7wQlOovCx7USw1dmF6u3EljWZV+Kg4Vi3vN2dPyJx tv8li9McWQoMLmm5zzFGGRaSRnnrnZFsMIIC1DCCAj2gAwIBAgIQemwyjqeRtRV6DGMDPPFg KTANBgkqhkiG9w0BAQUFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1 bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElz c3VpbmcgQ0EwHhcNMDkwNDAxMTkxNTE4WhcNMTAwNDAxMTkxNTE4WjA/MR8wHQYDVQQDExZU aGF3dGUgRnJlZW1haWwgTWVtYmVyMRwwGgYJKoZIhvcNAQkBFg1hbWFyYXRAa3N1LnJ1MIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuprsx+CNuzGaClM4rEA3vD5wVWIUDw2t QsABHBVAlAkKdVEZ/eL3sTA10sTxVM2eJTjJtLiC0uzL2B8267I9XYAkRKmCvFob4pnIe7V/ o/h7fVgFudu1ZVNTFndT+9agv4E4A4jhLzgLHzfhri5grvlaGlkp3nqp63mWjKf03XAFk2AK H0DBTfWUD9DSIJIqkQjG6FsSU1cc2eoCW2wK01ewqCxPyY/tAjnaHRwE49Jmq/P757/Cu4ka Ap4IQKqjx+3DDJrcJiQfWWEfZDXN5fB7PUTX6yiUzjyh0f6h2fb1y2Y6qvc/Nl+YEnIYV/kV qBMo2Jr/KzjzIG1VT9FcewIDAQABoyowKDAYBgNVHREEETAPgQ1hbWFyYXRAa3N1LnJ1MAwG A1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEFBQADgYEAbg+PspFIn8zbwo3Kck48IeDbovXlL059 D5yQxo88NEB6O12VR0KCSjIP13UO79qYCToDc1xjYj8ywVba9KidB9T7twlmLK6F/DvBCU6i 8LHtRLDV2YXq7cSWNZlX4qDhWLe83Z0/InG2/yWL0xxZCgwuabnPMUYZFpJGeeudkWwwggM/ MIICqKADAgECAgENMA0GCSqGSIb3DQEBBQUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMM V2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25z dWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYD VQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNv bmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDMwNzE3MDAwMDAwWhcNMTMwNzE2MjM1OTU5 WjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRk LjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwgZ8wDQYJ KoZIhvcNAQEBBQADgY0AMIGJAoGBAMSmPFVzVftOucqZWh5owHUEcJ3f6f+jHuy9zfVb8hp2 vX8MOmHyv1HOAdTlUAow1wJjWiyJFXCO3cnwK4Vaqj9xVsuvPAsH5/EfkTYkKhPPK9Xzgnc9 A74r/rsYPge/QIACZNenprufZdHFKlSFD0gEf6e20TxhBEAeZBlyYLf7AgMBAAGjgZQwgZEw EgYDVR0TAQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6MDigNqA0hjJodHRwOi8vY3JsLnRoYXd0 ZS5jb20vVGhhd3RlUGVyc29uYWxGcmVlbWFpbENBLmNybDALBgNVHQ8EBAMCAQYwKQYDVR0R BCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDItMTM4MA0GCSqGSIb3DQEBBQUAA4GB AEiM0VCD6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0whuPg2H6otnzYvwPQcUCCTcDz9reFhYsPZ Ohl+hLGZGwDFGguCdJ4lUJRix9sncVcljd2pnDmOjCBPZV+V2vf3h9bGCE6u9uo05RAaWzVN d+NWIXiC3CEZNd4ksdMdRv9dX2VPMYIDZDCCA2ACAQEwdjBiMQswCQYDVQQGEwJaQTElMCMG A1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEHpsMo6nkbUVegxjAzzxYCkwCQYFKw4DAhoF AKCCAcMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDkwNzA1 MTc1NjIzWjAjBgkqhkiG9w0BCQQxFgQU69lOJChVXNiHsJ6pa5JGW5ISMh8wUgYJKoZIhvcN AQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYF Kw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhB6bDKOp5G1FXoMYwM88WApMIGHBgsq hkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1 aW5nIENBAhB6bDKOp5G1FXoMYwM88WApMA0GCSqGSIb3DQEBAQUABIIBAGxpPUo1wyfLyxAo o4Sx25g8cxZA/kwzVKQH7SYzHXKlcWJVvlLmnH/FvZmTMxxLxSDVSfcwRnNFDTB+M/s1lG3U 1l8NMEnfumsbW8AmU8otINqE5630aLYPorbtT6r2zH0XnrkpUkL1JpxcVnwjdcdq5oyGVOHT IiByIZmEcr+qwUn7vGv0WoaiMukp/5OlKYXBTiLVAbKAQ2WWbryn1YcOHvX1LHdzlKul0eci g+A9yeAYUTTmfBKH4ph3x6jxHj1/fQJ3UNZKq6/wRQZH24fWZhK8Dz/NsxsS1vGrWXGz8kaW WypvD9Rejr4CNmN+gPptK5JqUHdS6f4k3bORbl0AAAAAAAA= --------------ms000900070902020105010703-- From owner-freebsd-stable@FreeBSD.ORG Sun Jul 5 18:59:17 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5B9491065676 for ; Sun, 5 Jul 2009 18:59:17 +0000 (UTC) (envelope-from dan.naumov@gmail.com) Received: from mail-yx0-f181.google.com (mail-yx0-f181.google.com [209.85.210.181]) by mx1.freebsd.org (Postfix) with ESMTP id 0C35C8FC1A for ; Sun, 5 Jul 2009 18:59:16 +0000 (UTC) (envelope-from dan.naumov@gmail.com) Received: by yxe11 with SMTP id 11so5087459yxe.3 for ; Sun, 05 Jul 2009 11:59:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=stgTihARUDEhY3k2MkNyGwr12fNs+WRelRFGraRk7so=; b=V/Seep6Fv7OiUQWpW8RGmFH7XmB1YCScRZkORB9/LzT2MUivTGHtL9AyhZlTiGxNFj 4z95XrTMQDgzwD5Xwu0HWo3rQMVulWXyUpljiVGKf8xTtEieG3gvYcaRM0TWWDILmiwx pIHrFSVfQYtrpF/OYTSWd02KazAMeod6pRmZE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=gkX7mikiQW2CWYzA3MvvQOVToF6l3b0t39YoRyN57h48RWxwXEzIEKVGd5HbUv4yKh uxQpRGtnlFcCdZi213NvNI390OL0CSJT+NEOcbsvllSbh7QqqBgU1ucWns4V55zAbqlm Ibr19WWkTDhxDMmeAn5ZT03YvD8Q55l07O7Zw= MIME-Version: 1.0 Received: by 10.100.141.2 with SMTP id o2mr6848532and.151.1246820356397; Sun, 05 Jul 2009 11:59:16 -0700 (PDT) In-Reply-To: <4A50E947.9020608@ksu.ru> References: <4A50E947.9020608@ksu.ru> Date: Sun, 5 Jul 2009 21:59:16 +0300 Message-ID: From: Dan Naumov To: "Marat N.Afanasyev" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD-STABLE Mailing List Subject: Re: bug in ufs? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jul 2009 18:59:17 -0000 2009/7/5 Marat N.Afanasyev : > hello! > > i have a strange problem with writing data to my ufs2+su filesystem. > > 1. i made a 1T gpt partition on my storage server, and formatted it: > newfs -U -m 0 -o time -i 32768 /dev/da1p3a > > 2. i tried to move data from other servers to this filesystem, total size= of > files is slightly less than 1T > > 3. i encountered a 'No space left on device' while i still have 11G of fr= ee > space and about 13 million free inodes on the filesystem: > > #df -ih > Filesystem =A0 =A0 Size =A0 =A0Used =A0 Avail Capacity =A0iused =A0 =A0if= ree %iused Mounted > on > /dev/da1p3a =A0 =A01.0T =A0 =A01.0T =A0 =A0 11G =A0 =A099% 20397465 13363= 173 =A0 60% > /mnt/45_114 > > all i want to know is whether this is a bug or a feature? and if such a > behavior is well-known, where can i read about it? By default, a part of a filesystem is reserved, the amount reserved has historically varied between 5-8%. This is adjustable. See the "-m" switch to tunefs. - Sincerely, Dan Naumov From owner-freebsd-stable@FreeBSD.ORG Sun Jul 5 19:31:28 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3956F106564A for ; Sun, 5 Jul 2009 19:31:28 +0000 (UTC) (envelope-from amarat@ksu.ru) Received: from mx.kzn.ru (mx.kzn.ru [194.85.243.38]) by mx1.freebsd.org (Postfix) with ESMTP id 2E5168FC0A for ; Sun, 5 Jul 2009 19:31:26 +0000 (UTC) (envelope-from amarat@ksu.ru) Authentication-Results: iout.kzn.ru; dkim=neutral (message not signed) header.i=none Received-SPF: None identity=pra; client-ip=193.232.252.56; receiver=iout.kzn.ru; envelope-from="amarat@ksu.ru"; x-sender="amarat@ksu.ru"; x-conformance=sidf_compatible Received-SPF: None identity=mailfrom; client-ip=193.232.252.56; receiver=iout.kzn.ru; envelope-from="amarat@ksu.ru"; x-sender="amarat@ksu.ru"; x-conformance=sidf_compatible Received-SPF: None identity=helo; client-ip=193.232.252.56; receiver=iout.kzn.ru; envelope-from="amarat@ksu.ru"; x-sender="postmaster@ruby.ksu.ru"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgkFABacUErCVfWh/2dsb2JhbACBULomCI05gjEfCB6BHAWBOg X-IronPort-AV: E=Sophos;i="4.42,352,1243800000"; d="p7s'?scan'208";a="4184717" Received: from mail.ksu.ru (HELO ruby.ksu.ru) ([193.232.252.56]) by iout.kzn.ru with ESMTP; 05 Jul 2009 23:31:25 +0400 X-Pass-Through: Kazan State University Network Received: from zealot.ksu.ru ([194.85.245.161]) by ksu.ru (8.13.4/8.13.4) with ESMTP id n65IcXHH005821; Sun, 5 Jul 2009 18:38:33 GMT Received: from zealot.ksu.ru (localhost.lnet [127.0.0.1]) by zealot.ksu.ru (8.14.3/8.14.3) with ESMTP id n65JUuwc028275; Sun, 5 Jul 2009 23:30:56 +0400 (MSD) (envelope-from amarat@ksu.ru) Message-ID: <4A50FF6F.2080106@ksu.ru> Date: Sun, 05 Jul 2009 23:30:55 +0400 From: "Marat N.Afanasyev" User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.8.1.22) Gecko/20090704 SeaMonkey/1.1.17 MIME-Version: 1.0 To: Dan Naumov , FreeBSD-STABLE Mailing List References: <4A50E947.9020608@ksu.ru> In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070806030200010308010207" Cc: Subject: Re: bug in ufs? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jul 2009 19:31:28 -0000 This is a cryptographically signed message in MIME format. --------------ms070806030200010308010207 Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Dan Naumov wrote: > 2009/7/5 Marat N.Afanasyev : >> hello! >> >> i have a strange problem with writing data to my ufs2+su filesystem. >> >> 1. i made a 1T gpt partition on my storage server, and formatted it: >> newfs -U -m 0 -o time -i 32768 /dev/da1p3a >> >> 2. i tried to move data from other servers to this filesystem, total size of >> files is slightly less than 1T >> >> 3. i encountered a 'No space left on device' while i still have 11G of free >> space and about 13 million free inodes on the filesystem: >> >> #df -ih >> Filesystem Size Used Avail Capacity iused ifree %iused Mounted >> on >> /dev/da1p3a 1.0T 1.0T 11G 99% 20397465 13363173 60% >> /mnt/45_114 >> >> all i want to know is whether this is a bug or a feature? and if such a >> behavior is well-known, where can i read about it? > > By default, a part of a filesystem is reserved, the amount reserved > has historically varied between 5-8%. This is adjustable. See the "-m" > switch to tunefs. > > - Sincerely, > Dan Naumov > as you can see from newfs commandline (1.) I already diminished this root reserve to zero percent. and i'm sorry i forgot to mention that i'm trying to move my data using root account, of course. -- SY, Marat --------------ms070806030200010308010207 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII8zCC AtQwggI9oAMCAQICEHpsMo6nkbUVegxjAzzxYCkwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDQwMTE5MTUxOFoX DTEwMDQwMTE5MTUxOFowPzEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEcMBoG CSqGSIb3DQEJARYNYW1hcmF0QGtzdS5ydTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALqa7MfgjbsxmgpTOKxAN7w+cFViFA8NrULAARwVQJQJCnVRGf3i97EwNdLE8VTNniU4 ybS4gtLsy9gfNuuyPV2AJESpgrxaG+KZyHu1f6P4e31YBbnbtWVTUxZ3U/vWoL+BOAOI4S84 Cx834a4uYK75WhpZKd56qet5loyn9N1wBZNgCh9AwU31lA/Q0iCSKpEIxuhbElNXHNnqAlts CtNXsKgsT8mP7QI52h0cBOPSZqvz++e/wruJGgKeCECqo8ftwwya3CYkH1lhH2Q1zeXwez1E 1+solM48odH+odn29ctmOqr3PzZfmBJyGFf5FagTKNia/ys48yBtVU/RXHsCAwEAAaMqMCgw GAYDVR0RBBEwD4ENYW1hcmF0QGtzdS5ydTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUA A4GBAG4Pj7KRSJ/M28KNynJOPCHg26L15S9OfQ+ckMaPPDRAejtdlUdCgkoyD9d1Du/amAk6 A3NcY2I/MsFW2vSonQfU+7cJZiyuhfw7wQlOovCx7USw1dmF6u3EljWZV+Kg4Vi3vN2dPyJx tv8li9McWQoMLmm5zzFGGRaSRnnrnZFsMIIC1DCCAj2gAwIBAgIQemwyjqeRtRV6DGMDPPFg KTANBgkqhkiG9w0BAQUFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1 bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElz c3VpbmcgQ0EwHhcNMDkwNDAxMTkxNTE4WhcNMTAwNDAxMTkxNTE4WjA/MR8wHQYDVQQDExZU aGF3dGUgRnJlZW1haWwgTWVtYmVyMRwwGgYJKoZIhvcNAQkBFg1hbWFyYXRAa3N1LnJ1MIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuprsx+CNuzGaClM4rEA3vD5wVWIUDw2t QsABHBVAlAkKdVEZ/eL3sTA10sTxVM2eJTjJtLiC0uzL2B8267I9XYAkRKmCvFob4pnIe7V/ o/h7fVgFudu1ZVNTFndT+9agv4E4A4jhLzgLHzfhri5grvlaGlkp3nqp63mWjKf03XAFk2AK H0DBTfWUD9DSIJIqkQjG6FsSU1cc2eoCW2wK01ewqCxPyY/tAjnaHRwE49Jmq/P757/Cu4ka Ap4IQKqjx+3DDJrcJiQfWWEfZDXN5fB7PUTX6yiUzjyh0f6h2fb1y2Y6qvc/Nl+YEnIYV/kV qBMo2Jr/KzjzIG1VT9FcewIDAQABoyowKDAYBgNVHREEETAPgQ1hbWFyYXRAa3N1LnJ1MAwG A1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEFBQADgYEAbg+PspFIn8zbwo3Kck48IeDbovXlL059 D5yQxo88NEB6O12VR0KCSjIP13UO79qYCToDc1xjYj8ywVba9KidB9T7twlmLK6F/DvBCU6i 8LHtRLDV2YXq7cSWNZlX4qDhWLe83Z0/InG2/yWL0xxZCgwuabnPMUYZFpJGeeudkWwwggM/ MIICqKADAgECAgENMA0GCSqGSIb3DQEBBQUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMM V2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25z dWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYD VQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNv bmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDMwNzE3MDAwMDAwWhcNMTMwNzE2MjM1OTU5 WjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRk LjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwgZ8wDQYJ KoZIhvcNAQEBBQADgY0AMIGJAoGBAMSmPFVzVftOucqZWh5owHUEcJ3f6f+jHuy9zfVb8hp2 vX8MOmHyv1HOAdTlUAow1wJjWiyJFXCO3cnwK4Vaqj9xVsuvPAsH5/EfkTYkKhPPK9Xzgnc9 A74r/rsYPge/QIACZNenprufZdHFKlSFD0gEf6e20TxhBEAeZBlyYLf7AgMBAAGjgZQwgZEw EgYDVR0TAQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6MDigNqA0hjJodHRwOi8vY3JsLnRoYXd0 ZS5jb20vVGhhd3RlUGVyc29uYWxGcmVlbWFpbENBLmNybDALBgNVHQ8EBAMCAQYwKQYDVR0R BCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDItMTM4MA0GCSqGSIb3DQEBBQUAA4GB AEiM0VCD6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0whuPg2H6otnzYvwPQcUCCTcDz9reFhYsPZ Ohl+hLGZGwDFGguCdJ4lUJRix9sncVcljd2pnDmOjCBPZV+V2vf3h9bGCE6u9uo05RAaWzVN d+NWIXiC3CEZNd4ksdMdRv9dX2VPMYIDZDCCA2ACAQEwdjBiMQswCQYDVQQGEwJaQTElMCMG A1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEHpsMo6nkbUVegxjAzzxYCkwCQYFKw4DAhoF AKCCAcMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDkwNzA1 MTkzMDU1WjAjBgkqhkiG9w0BCQQxFgQU0vUc8H9+B1ZA7AyW2hYRxmlQHTcwUgYJKoZIhvcN AQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYF Kw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhB6bDKOp5G1FXoMYwM88WApMIGHBgsq hkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1 aW5nIENBAhB6bDKOp5G1FXoMYwM88WApMA0GCSqGSIb3DQEBAQUABIIBAD8obiYS8Vzn14yO rSq4wWLBtiEKJCctBLAKq342HeS8Dsocm/LCxLk+LkzuTXD93tJC7SjginBiN5JrZ7+oRbze 0+rlWCgbi4Of8X9Cyxp6qdzTZrN0uQDZLRYqYTQQRNfJzNJesnwsdNUd9dXRAPjLY1DbHGOf +pUF4gngeHKJn7MozE5ylfTNgEAPsgeWBpgFo5ruTUKoa0Sn/IQDylGkfXvfnoj3qH9QiQJf Knh8IRV+McxAb2M3W6TW5gKCETls53WSsJR4d1h0jYLfa97m7HeAX//momkpEuLM/vtLSvAJ Nml4L2po1YkTjf+gKyXC3Wl0/ecyfxjR+b5oXKAAAAAAAAA= --------------ms070806030200010308010207-- From owner-freebsd-stable@FreeBSD.ORG Mon Jul 6 07:39:48 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1F3F81065677 for ; Mon, 6 Jul 2009 07:39:48 +0000 (UTC) (envelope-from mail25@bzerk.org) Received: from ei.bzerk.org (tunnel490.ipv6.xs4all.nl [IPv6:2001:888:10:1ea::2]) by mx1.freebsd.org (Postfix) with ESMTP id 9FB8C8FC14 for ; Mon, 6 Jul 2009 07:39:47 +0000 (UTC) (envelope-from mail25@bzerk.org) Received: from ei.bzerk.org (BOFH@localhost [127.0.0.1]) by ei.bzerk.org (8.14.2/8.14.2) with ESMTP id n667dgXi078589; Mon, 6 Jul 2009 09:39:42 +0200 (CEST) (envelope-from mail25@bzerk.org) Received: (from bulk@localhost) by ei.bzerk.org (8.14.2/8.14.2/Submit) id n667df6x078588; Mon, 6 Jul 2009 09:39:41 +0200 (CEST) (envelope-from mail25@bzerk.org) Date: Mon, 6 Jul 2009 09:39:41 +0200 From: Ruben de Groot To: Ian J Hart Message-ID: <20090706073941.GA78371@ei.bzerk.org> Mail-Followup-To: Ruben de Groot , Ian J Hart , "Patrick M. Hausen" , Dimitry Andric , FreeBSD Stable Mailing List References: <20090703142528.GA11039@hugo10.ka.punkt.de> <4A4E174A.1050207@andric.com> <20090703144121.GC11039@hugo10.ka.punkt.de> <4A4E1E24.3020303@andric.com> <20090703152150.GE11039@hugo10.ka.punkt.de> <20090705003834.12211k8697td2o74@webmail.private.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090705003834.12211k8697td2o74@webmail.private.lan> User-Agent: Mutt/1.4.2.3i X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on ei.bzerk.org X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0.1 (ei.bzerk.org [127.0.0.1]); Mon, 06 Jul 2009 09:39:45 +0200 (CEST) Cc: Dimitry Andric , FreeBSD Stable Mailing List Subject: Re: What is /boot/kernel/*.symbols? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 07:39:48 -0000 On Sun, Jul 05, 2009 at 12:38:34AM +0100, Ian J Hart typed: > > I just had an installworld fail due to this (/rescue). > > Given that many people will have chosen the default root size offered > by sysinstall a different build default would seem prudent. > > In any case sysinstall needs to be updated (1GB?). Let's not put off > new users anymore than we have to. The default root partition created by sysinstall (provided the disk is large enough) is 512 MB, which is more than enough. #define ROOT_DEFAULT_SIZE 512 Ruben From owner-freebsd-stable@FreeBSD.ORG Mon Jul 6 07:43:00 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7A0AA1065676 for ; Mon, 6 Jul 2009 07:43:00 +0000 (UTC) (envelope-from hausen@punkt.de) Received: from kagate.punkt.de (kagate.punkt.de [217.29.33.131]) by mx1.freebsd.org (Postfix) with ESMTP id D20318FC1D for ; Mon, 6 Jul 2009 07:42:59 +0000 (UTC) (envelope-from hausen@punkt.de) Received: from hugo10.ka.punkt.de (hugo10.ka.punkt.de [10.0.0.110]) by kagate1.punkt.de with ESMTP id n667gwTr073655 for ; Mon, 6 Jul 2009 09:42:58 +0200 (CEST) Received: from hugo10.ka.punkt.de (localhost [127.0.0.1]) by hugo10.ka.punkt.de (8.14.2/8.14.2) with ESMTP id n667gvHN007253; Mon, 6 Jul 2009 09:42:57 +0200 (CEST) (envelope-from ry93@hugo10.ka.punkt.de) Received: (from ry93@localhost) by hugo10.ka.punkt.de (8.14.2/8.14.2/Submit) id n667gvj4007252; Mon, 6 Jul 2009 09:42:57 +0200 (CEST) (envelope-from ry93) Date: Mon, 6 Jul 2009 09:42:57 +0200 From: "Patrick M. Hausen" To: Ruben de Groot , Ian J Hart , "Patrick M. Hausen" , Dimitry Andric , FreeBSD Stable Mailing List Message-ID: <20090706074256.GD6306@hugo10.ka.punkt.de> References: <20090703142528.GA11039@hugo10.ka.punkt.de> <4A4E174A.1050207@andric.com> <20090703144121.GC11039@hugo10.ka.punkt.de> <4A4E1E24.3020303@andric.com> <20090703152150.GE11039@hugo10.ka.punkt.de> <20090705003834.12211k8697td2o74@webmail.private.lan> <20090706073941.GA78371@ei.bzerk.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20090706073941.GA78371@ei.bzerk.org> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: Subject: Re: What is /boot/kernel/*.symbols? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 07:43:01 -0000 Hello, On Mon, Jul 06, 2009 at 09:39:41AM +0200, Ruben de Groot wrote: > On Sun, Jul 05, 2009 at 12:38:34AM +0100, Ian J Hart typed: > > > > I just had an installworld fail due to this (/rescue). > > > > Given that many people will have chosen the default root size offered > > by sysinstall a different build default would seem prudent. > > > > In any case sysinstall needs to be updated (1GB?). Let's not put off > > new users anymore than we have to. > > The default root partition created by sysinstall (provided the disk is large > enough) is 512 MB, which is more than enough. > > #define ROOT_DEFAULT_SIZE 512 IMHO it is not. If you install a kernel with *.symbols present twice (i.e. kernel and kernel.old contain symbol files), your root partition will be > 95% full. That's why I started this discussion in the first place and decided not to install the symbols on production machines for now. Kind regards, Patrick -- punkt.de GmbH * Kaiserallee 13a * 76133 Karlsruhe Tel. 0721 9109 0 * Fax 0721 9109 100 info@punkt.de http://www.punkt.de Gf: Jürgen Egeling AG Mannheim 108285 From owner-freebsd-stable@FreeBSD.ORG Mon Jul 6 08:34:45 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 239061065675 for ; Mon, 6 Jul 2009 08:34:45 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id D7D478FC15 for ; Mon, 6 Jul 2009 08:34:44 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from [IPv6:2001:7b8:3a7:0:bdb1:b6a5:88be:cfe9] (unknown [IPv6:2001:7b8:3a7:0:bdb1:b6a5:88be:cfe9]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 466055C59; Mon, 6 Jul 2009 10:34:43 +0200 (CEST) Message-ID: <4A51B721.5020505@andric.com> Date: Mon, 06 Jul 2009 10:34:41 +0200 From: Dimitry Andric User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.1.1pre) Gecko/20090705 Shredder/3.0b3pre MIME-Version: 1.0 To: "Patrick M. Hausen" References: <20090703142528.GA11039@hugo10.ka.punkt.de> <4A4E174A.1050207@andric.com> <20090703144121.GC11039@hugo10.ka.punkt.de> <4A4E1E24.3020303@andric.com> <20090703152150.GE11039@hugo10.ka.punkt.de> <20090705003834.12211k8697td2o74@webmail.private.lan> <20090706073941.GA78371@ei.bzerk.org> <20090706074256.GD6306@hugo10.ka.punkt.de> In-Reply-To: <20090706074256.GD6306@hugo10.ka.punkt.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Ruben de Groot , FreeBSD Stable Mailing List Subject: Re: What is /boot/kernel/*.symbols? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 08:34:45 -0000 On 2009-07-06 09:42, Patrick M. Hausen wrote: >> #define ROOT_DEFAULT_SIZE 512 > > IMHO it is not. If you install a kernel with *.symbols present > twice (i.e. kernel and kernel.old contain symbol files), your > root partition will be > 95% full. I'm not sure how you arrive at this number; even with -CURRENT (on i386, with all debug symbols), I could store about 4 complete kernels on such a filesystem: $ du -hs /boot/kernel* 122M /boot/kernel 122M /boot/kernel.20090629a 121M /boot/kernel.20090630a 122M /boot/kernel.20090702a 121M /boot/kernel.20090703a All other files on my root filesystem use up an additional ~25 MiB, so in practice, it would be limited to 3 kernels, with more than enough breathing room. From owner-freebsd-stable@FreeBSD.ORG Mon Jul 6 08:41:41 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A6F651065675 for ; Mon, 6 Jul 2009 08:41:41 +0000 (UTC) (envelope-from dan.naumov@gmail.com) Received: from mail-yx0-f181.google.com (mail-yx0-f181.google.com [209.85.210.181]) by mx1.freebsd.org (Postfix) with ESMTP id 5ABEE8FC24 for ; Mon, 6 Jul 2009 08:41:40 +0000 (UTC) (envelope-from dan.naumov@gmail.com) Received: by yxe11 with SMTP id 11so5540380yxe.3 for ; Mon, 06 Jul 2009 01:41:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=bmAj4n85r105+z+tggk+p8OM8deJI1fwzol1v13DmTw=; b=LfBJcGotDwM0JR+6J1CDOucwP8RocmTp8w4K2N5WI64IQjUOn0iGzWV2tyWCe7PxXC znH/1tERfDf0xK9i88skSedQ1orFqlf3HR+J1TiHZSkAvtnqQ6vj540OwL4KzogiGhJh lS/AvVac+TzHafxqaqeeaIuqmajR/Aux1AcRA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=BAtuwAJODkfoneAKdIykSE2pmxFByIoT75KyU7T7D7aheOJLKxVnw3bs93w8ZY3wx7 1piZ+/Hf8oI35Jhx6g4kW9NqVTL1FeUr6YDKROtZfVhMci+CZ8H8fbURhZnyZvrTnUAx YtvT9m0KiNU5IMhE3yKJ7Pfsm7MK/6Bhisu8I= MIME-Version: 1.0 Received: by 10.100.96.12 with SMTP id t12mr8212847anb.4.1246869700484; Mon, 06 Jul 2009 01:41:40 -0700 (PDT) In-Reply-To: <4A51B721.5020505@andric.com> References: <20090703142528.GA11039@hugo10.ka.punkt.de> <4A4E174A.1050207@andric.com> <20090703144121.GC11039@hugo10.ka.punkt.de> <4A4E1E24.3020303@andric.com> <20090703152150.GE11039@hugo10.ka.punkt.de> <20090705003834.12211k8697td2o74@webmail.private.lan> <20090706073941.GA78371@ei.bzerk.org> <20090706074256.GD6306@hugo10.ka.punkt.de> <4A51B721.5020505@andric.com> Date: Mon, 6 Jul 2009 11:41:40 +0300 Message-ID: From: Dan Naumov To: Dimitry Andric Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Ruben de Groot , FreeBSD Stable Mailing List Subject: Re: What is /boot/kernel/*.symbols? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 08:41:41 -0000 On Mon, Jul 6, 2009 at 11:34 AM, Dimitry Andric wrote: > On 2009-07-06 09:42, Patrick M. Hausen wrote: >>> #define ROOT_DEFAULT_SIZE =A0 =A0 =A0 =A0 =A0 =A0 =A0 512 >> >> IMHO it is not. If you install a kernel with *.symbols present >> twice (i.e. kernel and kernel.old contain symbol files), your >> root partition will be > 95% full. > > I'm not sure how you arrive at this number; even with -CURRENT (on i386, > with all debug symbols), I could store about 4 complete kernels on such > a filesystem: > > $ du -hs /boot/kernel* > 122M =A0 =A0/boot/kernel > 122M =A0 =A0/boot/kernel.20090629a > 121M =A0 =A0/boot/kernel.20090630a > 122M =A0 =A0/boot/kernel.20090702a > 121M =A0 =A0/boot/kernel.20090703a > > All other files on my root filesystem use up an additional ~25 MiB, so > in practice, it would be limited to 3 kernels, with more than enough > breathing room. atom# uname -a FreeBSD atom.localdomain 7.2-RELEASE-p1 FreeBSD 7.2-RELEASE-p1 #0: Tue Jun 9 18:02:21 UTC 2009 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 atom# du -hs /boot/kernel* 205M /boot/kernel This is on a stock 7.2-release/amd64 updated to -p1 with freebsd-update, 2 kernels is the maximum that would fit into the default 512mb partition size for /, a bit too tight for my liking. - Sincerely, Dan Naumov From owner-freebsd-stable@FreeBSD.ORG Mon Jul 6 08:42:49 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 425A81065674 for ; Mon, 6 Jul 2009 08:42:49 +0000 (UTC) (envelope-from emikulic@gmail.com) Received: from ipmail03.adl6.internode.on.net (ipmail03.adl6.internode.on.net [203.16.214.141]) by mx1.freebsd.org (Postfix) with ESMTP id C20E38FC14 for ; Mon, 6 Jul 2009 08:42:48 +0000 (UTC) (envelope-from emikulic@gmail.com) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAC9WUUqWZZrw/2dsb2JhbAC8Eo8IhBIFgTo X-IronPort-AV: E=Sophos;i="4.42,355,1243780200"; d="scan'208";a="2381834" Received: from ppp154-240.static.internode.on.net ([150.101.154.240]) by ipmail03.adl6.internode.on.net with ESMTP; 06 Jul 2009 18:12:46 +0930 Received: by ppp154-240.static.internode.on.net (Poo-fix, from userid 1001) id 717C95C65; Mon, 6 Jul 2009 18:42:45 +1000 (EST) Date: Mon, 6 Jul 2009 18:42:45 +1000 From: Emil Mikulic To: Dimitry Andric Message-ID: <20090706084245.GA38494@dmr.ath.cx> References: <20090703142528.GA11039@hugo10.ka.punkt.de> <4A4E174A.1050207@andric.com> <20090703144121.GC11039@hugo10.ka.punkt.de> <4A4E1E24.3020303@andric.com> <20090703152150.GE11039@hugo10.ka.punkt.de> <20090705003834.12211k8697td2o74@webmail.private.lan> <20090706073941.GA78371@ei.bzerk.org> <20090706074256.GD6306@hugo10.ka.punkt.de> <4A51B721.5020505@andric.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A51B721.5020505@andric.com> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: Ruben de Groot , FreeBSD Stable Mailing List Subject: Re: What is /boot/kernel/*.symbols? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 08:42:49 -0000 On Mon, Jul 06, 2009 at 10:34:41AM +0200, Dimitry Andric wrote: > I'm not sure how you arrive at this number; even with -CURRENT (on i386, > with all debug symbols), I could store about 4 complete kernels on such > a filesystem: > > $ du -hs /boot/kernel* > 122M /boot/kernel I get about the same on an i386: 119M /boot/kernel However, on amd64: 227M /boot/kernel --Emil From owner-freebsd-stable@FreeBSD.ORG Mon Jul 6 08:46:53 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DE7A6106564A for ; Mon, 6 Jul 2009 08:46:52 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id 9E12C8FC0C for ; Mon, 6 Jul 2009 08:46:52 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from [IPv6:2001:7b8:3a7:0:bdb1:b6a5:88be:cfe9] (unknown [IPv6:2001:7b8:3a7:0:bdb1:b6a5:88be:cfe9]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id AAC5F5C59; Mon, 6 Jul 2009 10:46:51 +0200 (CEST) Message-ID: <4A51B9FA.9010906@andric.com> Date: Mon, 06 Jul 2009 10:46:50 +0200 From: Dimitry Andric User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.1.1pre) Gecko/20090705 Shredder/3.0b3pre MIME-Version: 1.0 To: Dan Naumov References: <20090703142528.GA11039@hugo10.ka.punkt.de> <4A4E174A.1050207@andric.com> <20090703144121.GC11039@hugo10.ka.punkt.de> <4A4E1E24.3020303@andric.com> <20090703152150.GE11039@hugo10.ka.punkt.de> <20090705003834.12211k8697td2o74@webmail.private.lan> <20090706073941.GA78371@ei.bzerk.org> <20090706074256.GD6306@hugo10.ka.punkt.de> <4A51B721.5020505@andric.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Ruben de Groot , FreeBSD Stable Mailing List Subject: Re: What is /boot/kernel/*.symbols? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 08:46:53 -0000 On 2009-07-06 10:41, Dan Naumov wrote: > atom# uname -a > FreeBSD atom.localdomain 7.2-RELEASE-p1 FreeBSD 7.2-RELEASE-p1 #0: Tue > Jun 9 18:02:21 UTC 2009 > root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 > > atom# du -hs /boot/kernel* > 205M /boot/kernel Right, so it's a lot bigger on amd64. I guess those 64-bit pointers aren't entirely free. :) So indeed, on amd64 and possibly some other 'big' architectures (ia64?), cranking the default root filesystem size to e.g. 1024M would be nice. From owner-freebsd-stable@FreeBSD.ORG Mon Jul 6 08:53:46 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C2EB1106564A for ; Mon, 6 Jul 2009 08:53:46 +0000 (UTC) (envelope-from petefrench@ticketswitch.com) Received: from constantine.ticketswitch.com (constantine.ticketswitch.com [IPv6:2002:57e0:1d4e:1::3]) by mx1.freebsd.org (Postfix) with ESMTP id 89DD48FC1B for ; Mon, 6 Jul 2009 08:53:46 +0000 (UTC) (envelope-from petefrench@ticketswitch.com) Received: from dilbert.rattatosk ([10.64.50.6] helo=dilbert.ticketswitch.com) by constantine.ticketswitch.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MNjxG-000COb-KF; Mon, 06 Jul 2009 09:53:42 +0100 Received: from petefrench by dilbert.ticketswitch.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MNjxG-00094l-II; Mon, 06 Jul 2009 09:53:42 +0100 To: dan.naumov@gmail.com, dimitry@andric.com In-Reply-To: Message-Id: From: Pete French Date: Mon, 06 Jul 2009 09:53:42 +0100 Cc: mail25@bzerk.org, freebsd-stable@freebsd.org Subject: Re: What is /boot/kernel/*.symbols? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 08:53:47 -0000 > > I'm not sure how you arrive at this number; even with -CURRENT (on i386, > > with all debug symbols), I could store about 4 complete kernels on such > > a filesystem: > > > > $ du -hs /boot/kernel* > > 122M  /boot/kernel > > atom# du -hs /boot/kernel* > 205M /boot/kernel i386: 127 meg amd64: 208 meg those are machines built from identical source, only differeing in the architecture. unless you are constrained to using i386 for some reason then 512 meg is going to be a bit small. -pete. From owner-freebsd-stable@FreeBSD.ORG Mon Jul 6 08:54:05 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1F9E41065686 for ; Mon, 6 Jul 2009 08:54:05 +0000 (UTC) (envelope-from marck@rinet.ru) Received: from woozle.rinet.ru (woozle.rinet.ru [195.54.192.68]) by mx1.freebsd.org (Postfix) with ESMTP id 985C58FC18 for ; Mon, 6 Jul 2009 08:54:04 +0000 (UTC) (envelope-from marck@rinet.ru) Received: from localhost (localhost [127.0.0.1]) by woozle.rinet.ru (8.14.3/8.14.3) with ESMTP id n668s2wG041168; Mon, 6 Jul 2009 12:54:02 +0400 (MSD) (envelope-from marck@rinet.ru) Date: Mon, 6 Jul 2009 12:54:02 +0400 (MSD) From: Dmitry Morozovsky To: "Patrick M. Hausen" In-Reply-To: <20090703142528.GA11039@hugo10.ka.punkt.de> Message-ID: References: <20090703142528.GA11039@hugo10.ka.punkt.de> 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.2.2 (woozle.rinet.ru [0.0.0.0]); Mon, 06 Jul 2009 12:54:03 +0400 (MSD) Cc: FreeBSD Stable Mailing List Subject: Re: What is /boot/kernel/*.symbols? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 08:54:05 -0000 Hi there Patrick, On Fri, 3 Jul 2009, Patrick M. Hausen wrote: PMH> 7.2-System: PMH> ----------- PMH> makeoptions DEBUG=-g PMH> PMH> $ du -sk /boot/kernel PMH> 214778 /boot/kernel PMH> PMH> Lots of those files filling /boot/kernel. PMH> PMH> PMH> On a current server with 512 MB /, the filesystem is at PMH> 97% after installing a new kernel twice. Can I get rid of PMH> these files somehow or are they necessary, in which case PMH> I will need way bigger root filesystems? Define INSTALL_NODEBUG somewhere (on installkernel commandline or maybe even in /etc/make.conf) -- 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 Mon Jul 6 09:39:10 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 43879106564A for ; Mon, 6 Jul 2009 09:39:10 +0000 (UTC) (envelope-from mail25@bzerk.org) Received: from ei.bzerk.org (tunnel490.ipv6.xs4all.nl [IPv6:2001:888:10:1ea::2]) by mx1.freebsd.org (Postfix) with ESMTP id A50228FC0C for ; Mon, 6 Jul 2009 09:39:09 +0000 (UTC) (envelope-from mail25@bzerk.org) Received: from ei.bzerk.org (BOFH@localhost [127.0.0.1]) by ei.bzerk.org (8.14.2/8.14.2) with ESMTP id n669d4GO079670; Mon, 6 Jul 2009 11:39:04 +0200 (CEST) (envelope-from mail25@bzerk.org) Received: (from bulk@localhost) by ei.bzerk.org (8.14.2/8.14.2/Submit) id n669d4o6079669; Mon, 6 Jul 2009 11:39:04 +0200 (CEST) (envelope-from mail25@bzerk.org) Date: Mon, 6 Jul 2009 11:39:04 +0200 From: Ruben de Groot To: Dimitry Andric Message-ID: <20090706093904.GA79434@ei.bzerk.org> Mail-Followup-To: Ruben de Groot , Dimitry Andric , Dan Naumov , "Patrick M. Hausen" , FreeBSD Stable Mailing List References: <4A4E174A.1050207@andric.com> <20090703144121.GC11039@hugo10.ka.punkt.de> <4A4E1E24.3020303@andric.com> <20090703152150.GE11039@hugo10.ka.punkt.de> <20090705003834.12211k8697td2o74@webmail.private.lan> <20090706073941.GA78371@ei.bzerk.org> <20090706074256.GD6306@hugo10.ka.punkt.de> <4A51B721.5020505@andric.com> <4A51B9FA.9010906@andric.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A51B9FA.9010906@andric.com> User-Agent: Mutt/1.4.2.3i X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on ei.bzerk.org X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0.1 (ei.bzerk.org [127.0.0.1]); Mon, 06 Jul 2009 11:39:07 +0200 (CEST) Cc: FreeBSD Stable Mailing List , Dan Naumov Subject: Re: What is /boot/kernel/*.symbols? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 09:39:10 -0000 On Mon, Jul 06, 2009 at 10:46:50AM +0200, Dimitry Andric typed: > On 2009-07-06 10:41, Dan Naumov wrote: > > atom# uname -a > > FreeBSD atom.localdomain 7.2-RELEASE-p1 FreeBSD 7.2-RELEASE-p1 #0: Tue > > Jun 9 18:02:21 UTC 2009 > > root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 > > > > atom# du -hs /boot/kernel* > > 205M /boot/kernel > > Right, so it's a lot bigger on amd64. I guess those 64-bit pointers > aren't entirely free. :) I'm not sure where the size difference comes from. I have some sparc64 systems running -current with symbols and the size of /boot/kernel is more comparable to i386, even with the 8-byte pointer size: > uname -p sparc64 > du -sk /boot/kernel 137918 /boot/kernel > So indeed, on amd64 and possibly some other 'big' architectures (ia64?), > cranking the default root filesystem size to e.g. 1024M would be nice. Indeed. From owner-freebsd-stable@FreeBSD.ORG Mon Jul 6 11:32:54 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D6F341065677 for ; Mon, 6 Jul 2009 11:32:54 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id 953AB8FC1E for ; Mon, 6 Jul 2009 11:32:54 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from [IPv6:2001:7b8:3a7:0:bdb1:b6a5:88be:cfe9] (unknown [IPv6:2001:7b8:3a7:0:bdb1:b6a5:88be:cfe9]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 9E2A65C59; Mon, 6 Jul 2009 13:32:53 +0200 (CEST) Message-ID: <4A51E0E4.4020707@andric.com> Date: Mon, 06 Jul 2009 13:32:52 +0200 From: Dimitry Andric User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.1.1pre) Gecko/20090705 Shredder/3.0b3pre MIME-Version: 1.0 To: Ruben de Groot , Dan Naumov , "Patrick M. Hausen" , FreeBSD Stable Mailing List References: <4A4E174A.1050207@andric.com> <20090703144121.GC11039@hugo10.ka.punkt.de> <4A4E1E24.3020303@andric.com> <20090703152150.GE11039@hugo10.ka.punkt.de> <20090705003834.12211k8697td2o74@webmail.private.lan> <20090706073941.GA78371@ei.bzerk.org> <20090706074256.GD6306@hugo10.ka.punkt.de> <4A51B721.5020505@andric.com> <4A51B9FA.9010906@andric.com> <20090706093904.GA79434@ei.bzerk.org> In-Reply-To: <20090706093904.GA79434@ei.bzerk.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: Re: What is /boot/kernel/*.symbols? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 11:32:55 -0000 On 2009-07-06 11:39, Ruben de Groot wrote: >>> root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 >>> >>> atom# du -hs /boot/kernel* >>> 205M /boot/kernel >> >> Right, so it's a lot bigger on amd64. I guess those 64-bit pointers >> aren't entirely free. :) > > I'm not sure where the size difference comes from. I have some sparc64 > systems running -current with symbols and the size of /boot/kernel is > more comparable to i386, even with the 8-byte pointer size: > >> uname -p > sparc64 >> du -sk /boot/kernel > 137918 /boot/kernel It looks like on amd64, the kernel is compiled with optimization flags: -O2 -frename-registers -pipe -fno-strict-aliasing by default, while on i386, they are just: -O -pipe Maybe this accounts for the huge difference? Does -O2 do a lot more inlining? In any case, it's a weird inconstency, if you ask me. But it's intentional, as /usr/src/sys/conf/kern.pre.mk says: . if ${MACHINE_ARCH} == "amd64" COPTFLAGS?=-O2 -frename-registers -pipe . else COPTFLAGS?=${_MINUS_O} -pipe . endif where ${_MINUS_O} is by default just "-O", since DEBUG is enabled... From owner-freebsd-stable@FreeBSD.ORG Mon Jul 6 13:54:52 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 516B61065672 for ; Mon, 6 Jul 2009 13:54:52 +0000 (UTC) (envelope-from ianjhart@ntlworld.com) Received: from mtaout01-winn.ispmail.ntl.com (mtaout01-winn.ispmail.ntl.com [81.103.221.47]) by mx1.freebsd.org (Postfix) with ESMTP id 81A198FC18 for ; Mon, 6 Jul 2009 13:54:41 +0000 (UTC) (envelope-from ianjhart@ntlworld.com) Received: from aamtaout03-winn.ispmail.ntl.com ([81.103.221.35]) by mtaout01-winn.ispmail.ntl.com (InterMail vM.7.08.04.00 201-2186-134-20080326) with ESMTP id <20090706135440.XGCS6742.mtaout01-winn.ispmail.ntl.com@aamtaout03-winn.ispmail.ntl.com> for ; Mon, 6 Jul 2009 14:54:40 +0100 Received: from cpc1-cove3-0-0-cust909.sol2.cable.ntl.com ([86.20.31.142]) by aamtaout03-winn.ispmail.ntl.com (InterMail vG.2.02.00.01 201-2161-120-102-20060912) with ESMTP id <20090706135438.TBDH2093.aamtaout03-winn.ispmail.ntl.com@cpc1-cove3-0-0-cust909.sol2.cable.ntl.com> for ; Mon, 6 Jul 2009 14:54:38 +0100 X-Virus-Scanned: amavisd-new at cpc2-cove3-0-0-cust311.sol2.cable.ntl.com Received: from localhost (localhost [127.0.0.1]) by cpc1-cove3-0-0-cust909.sol2.cable.ntl.com (8.14.3/8.14.3) with ESMTP id n66Ds4pp094595; Mon, 6 Jul 2009 14:54:05 +0100 (BST) (envelope-from ianjhart@cpc1-cove3-0-0-cust909.sol2.cable.ntl.com) Received: from localhost (localhost [127.0.0.1]) by 10.248.192.16 (Horde Framework) with HTTP; Mon, 06 Jul 2009 14:54:04 +0100 Message-ID: <20090706145404.18961bxcol12mmm8@10.248.192.16> Date: Mon, 06 Jul 2009 14:54:04 +0100 From: Ian J Hart To: Ian J Hart MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) 4.3.3 / FreeBSD-7.2 X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on cpc1-cove3-0-0-cust909.sol2.cable.ntl.com X-Cloudmark-Analysis: v=1.0 c=1 a=NLZqzBF-AAAA:8 a=QUEW3XSM2DZn_9SOm6sA:9 a=A7WvWm82AN4KUmwFZo4A:7 a=GO_U5CWzHdRwP_0S8aTJxyqNuqIA:4 a=_dQi-Dcv4p4A:10 a=ptSpW7h4ap_yjRm4:21 a=I7iIhw23TH53n5DK:21 Cc: freebsd-stable@freebsd.org Subject: Re: trap 12 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 13:54:52 -0000 Quoting Ian J Hart : > Is this likely to be hardware? Details will follow if not. > > [copied from a screen dump] > > Fatal trap 12: page fault while in kernel mode > cpuid = 1; apic id = 01 > fault virtual address = 0x0 > fault code = supervisor write data, page not present > instruction pointer = 0x8:0xffffffff807c6c12 > stack pointer = 0x10:0xffffffff510e7890 > frame pointer = 0x10:0xffffff00054a6c90 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, long 1 def32 0, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 75372 (printf) > trap number = 12 > panic: page fault > cpuid = 1 > uptime: 8m2s > Cannot dump. No dump device defined. > > Some suggestions (off list) that it may not be hardware, so here's the follow up. supermicro 5015b-mt (super X7SBi mobo) Intel Q6600 8GB ECC DDR2 4x Seagate 320GB, two gmirror, two idle. issues so far 1 OK) 7.x doesn't boot without hw.ata.atapi_dma=0. Not recently tested. 2 OK) disks enumerate differently 6.x to 7.x. Painful if you hardwired the providor into your mirror. 3) 6.3 and 7.2 remote dump over ssh fails with 'Disconnecting: Corrupted MAC on input.' 4) On 7.2 (AFAICT from logs) random reboots under load. e.g. the above generated by a portupgrade run. I had dumpdev=none as I hadn't setup rc.early to allow savecore to work. In the interests of full disclosure I should say that this box was migrated from older hardware and then source upgraded from i386 to amd64 (6.3). Only one issue with that, format of accounting file.Upgrade to 7.2 and a rebuild or two since then. This box is our email server and there's no load. An identical box running as a gateway/firewall backup dumps okay and doesn't reboot. That box does drop network connections when running a cvsup server (treelist write), but when configured to pass through these connections (using balance) runs okay. But that's a story for another day as it's still on 6.x. Anyway, I put the two gmirror disks in another chassis and the remote dumps are now completing.This at least does seem to be hardware. Before I moved the two gmirror disks I synced a third disk. I can now test (most of) the original hardware and software. I was unable to make this single disk system crash, so I added two new disks and synced them.Now a 3 disk mirror, one disk idle. I've disabled sendmail and the email server so as not to clash. A portupgrade run caused a crash. I've setup coredumps so I can now test. Remote backup dumps do fail. xmail# kldstat Id Refs Address Size Name 1 2 0xffffffff80100000 bd23e0 kernel 2 1 0xffffffff80cd3000 20608 geom_mirror.ko I did have ipfw module loaded, but I got the crash without it so I've removed it (firewall_type=OPEN). Ran crashinfo, now have much more info than I need ;) Starting another portupgrade run now to see how reproducable this is. Later BIOS waiting in USB floppy. dmesg after sig. Thanks -- ian j hart Copyright (c) 1992-2009 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 7.2-RELEASE-p1 #0: Tue Jun 16 18:03:10 BST 2009 mungethis@hostname:/usr/obj/usr/src/sys/GENERIC Preloaded elf kernel "/boot/kernel/kernel" at 0xffffffff80cf5000. Preloaded elf obj module "/boot/kernel/geom_mirror.ko" at 0xffffffff80cf5220. Calibrating clock(s) ... i8254 clock: 1193168 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 2394010944 Hz CPU: Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz (2394.01-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x6fb Stepping = 11 Features=0xbfebfbff Features2=0xe3bd AMD Features=0x20100800 AMD Features2=0x1 Cores per package: 4 usable memory = 8575127552 (8177 MB) Physical memory chunk(s): 0x0000000000001000 - 0x0000000000098fff, 622592 bytes (152 pages) 0x0000000000d27000 - 0x00000000cfe6ffff, 3474231296 bytes (848201 pages) 0x0000000100000000 - 0x000000021f8b3fff, 4824186880 bytes (1177780 pages) avail memory = 8273580032 (7890 MB) ACPI APIC Table: INTR: Adding local APIC 1 as a target INTR: Adding local APIC 2 as a target INTR: Adding local APIC 3 as a target FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 APIC: CPU 0 has ACPI ID 0 APIC: CPU 1 has ACPI ID 1 APIC: CPU 2 has ACPI ID 2 APIC: CPU 3 has ACPI ID 3 ULE: setup cpu group 0 ULE: setup cpu 0 ULE: adding cpu 0 to group 0: cpus 1 mask 0x1 ULE: setup cpu group 1 ULE: setup cpu 1 ULE: adding cpu 1 to group 1: cpus 1 mask 0x2 ULE: setup cpu group 2 ULE: setup cpu 2 ULE: adding cpu 2 to group 2: cpus 1 mask 0x4 ULE: setup cpu group 3 ULE: setup cpu 3 ULE: adding cpu 3 to group 3: cpus 1 mask 0x8 ACPI: RSDP @ 0x0xf69a0/0x0024 (v 2 PTLTD ) ACPI: XSDT @ 0x0xcfe77290/0x00A4 (v 1 PTLTD XSDT 0x06040000 LTP 0x00000000) ACPI: FACP @ 0x0xcfe80d60/0x00F4 (v 3 INTEL 0x06040000 PTL 0x00000002) ACPI: DSDT @ 0x0xcfe7a435/0x68B7 (v 1 INTEL BEARLAKE 0x06040000 MSFT 0x03000000) ACPI: FACS @ 0x0xcfe83fc0/0x0040 ACPI: _MAR @ 0x0xcfe80e54/0x0030 (v 1 Intel OEMDMAR 0x06040000 LOHR 0x00000001) ACPI: MCFG @ 0x0xcfe80e84/0x003C (v 1 PTLTD MCFG 0x06040000 LTP 0x00000000) ACPI: HPET @ 0x0xcfe80ec0/0x0038 (v 1 PTLTD HPETTBL 0x06040000 LTP 0x00000001) ACPI: APIC @ 0x0xcfe80ef8/0x0090 (v 1 PTLTD APIC 0x06040000 LTP 0x00000000) ACPI: BOOT @ 0x0xcfe80f88/0x0028 (v 1 PTLTD $SBFTBL$ 0x06040000 LTP 0x00000001) ACPI: SPCR @ 0x0xcfe80fb0/0x0050 (v 1 PTLTD $UCRTBL$ 0x06040000 PTL 0x00000001) ACPI: SSDT @ 0x0xcfe78ba7/0x025F (v 1 PmRef Cpu0Tst 0x00003000 INTL 0x20050228) ACPI: SSDT @ 0x0xcfe78b01/0x00A6 (v 1 PmRef Cpu7Tst 0x00003000 INTL 0x20050228) ACPI: SSDT @ 0x0xcfe78a5b/0x00A6 (v 1 PmRef Cpu6Tst 0x00003000 INTL 0x20050228) ACPI: SSDT @ 0x0xcfe789b5/0x00A6 (v 1 PmRef Cpu5Tst 0x00003000 INTL 0x20050228) ACPI: SSDT @ 0x0xcfe7890f/0x00A6 (v 1 PmRef Cpu4Tst 0x00003000 INTL 0x20050228) ACPI: SSDT @ 0x0xcfe78869/0x00A6 (v 1 PmRef Cpu3Tst 0x00003000 INTL 0x20050228) ACPI: SSDT @ 0x0xcfe787c3/0x00A6 (v 1 PmRef Cpu2Tst 0x00003000 INTL 0x20050228) ACPI: SSDT @ 0x0xcfe7871d/0x00A6 (v 1 PmRef Cpu1Tst 0x00003000 INTL 0x20050228) ACPI: SSDT @ 0x0xcfe77334/0x13E9 (v 1 PmRef CpuPm 0x00003000 INTL 0x20050228) MADT: Found IO APIC ID 4, Interrupt 0 at 0xfec00000 ioapic0: Routing external 8259A's -> intpin 0 MADT: Found IO APIC ID 5, Interrupt 24 at 0xfecc0000 lapic0: Routing NMI -> LINT1 lapic0: LINT1 trigger: edge lapic0: LINT1 polarity: high lapic1: Routing NMI -> LINT1 lapic1: LINT1 trigger: edge lapic1: LINT1 polarity: high lapic2: Routing NMI -> LINT1 lapic2: LINT1 trigger: edge lapic2: LINT1 polarity: high lapic3: Routing NMI -> LINT1 lapic3: LINT1 trigger: edge lapic3: LINT1 polarity: high MADT: Interrupt override: source 0, irq 2 ioapic0: Routing IRQ 0 -> intpin 2 MADT: Interrupt override: source 9, irq 9 ioapic0: intpin 9 trigger: level ioapic0 irqs 0-23 on motherboard ioapic1 irqs 24-47 on motherboard cpu0 BSP: ID: 0x00000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00000200 err: 0x00010000 pcm: 0x00010000 wlan_amrr: wlan: <802.11 Link Layer> null: random: nfslock: pseudo-device kbd: new array size 4 kbd1 at kbdmux0 mem: io: hptrr: RocketRAID 17xx/2xxx SATA controller driver v1.2 (Jun 16 2009 18:03:00) acpi0: on motherboard ioapic0: routing intpin 9 (ISA IRQ 9) to vector 48 acpi0: [MPSAFE] acpi0: [ITHREAD] acpi0: Power Button (fixed) AcpiOsDerivePciId: \\_SB_.PCI0.REGS -> bus 0 dev 0 func 0 AcpiOsDerivePciId: \\_SB_.PCI0.IGD0.IGDP -> bus 0 dev 2 func 0 AcpiOsDerivePciId: \\_SB_.PCI0.LPC0.REGS -> bus 0 dev 31 func 0 AcpiOsDerivePciId: \\_SB_.PCI0.LPC0.PIRX -> bus 0 dev 31 func 0 AcpiOsDerivePciId: \\_SB_.PCI0.LPC0.PIRY -> bus 0 dev 31 func 0 ACPI timer: 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 -> 10 Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 pci_link0: Index IRQ Rtd Ref IRQs Initial Probe 0 5 N 0 3 4 5 6 7 10 11 12 14 15 Validation 0 5 N 0 3 4 5 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link1: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 3 4 5 6 7 10 11 12 14 15 Validation 0 10 N 0 3 4 5 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link2: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 3 4 5 6 7 10 11 12 14 15 Validation 0 11 N 0 3 4 5 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link3: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 6 7 10 11 12 14 15 Validation 0 255 N 0 3 4 5 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link4: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 6 7 10 11 12 14 15 Validation 0 255 N 0 3 4 5 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link5: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 6 7 10 11 12 14 15 Validation 0 255 N 0 3 4 5 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link6: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 3 4 5 6 7 10 11 12 14 15 Validation 0 11 N 0 3 4 5 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link7: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 3 4 5 6 7 10 11 12 14 15 Validation 0 10 N 0 3 4 5 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 10 11 12 14 15 acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 acpi_hpet0: vend: 0x8086 rev: 0x1 num: 3 hz: 14318180 opts: legacy_route 64-bit Timecounter "HPET" frequency 14318180 Hz quality 900 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: domain=0, physical bus=0 found-> vendor=0x8086, dev=0x29f0, revid=0x01 domain=0, bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0106, statreg=0x2090, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x29f1, revid=0x01 domain=0, bus=0, slot=1, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0107, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) intpin=a, irq=5 powerspec 3 supports D0 D3 current D0 MSI supports 1 message pcib0: matched entry for 0.1.INTA pcib0: slot 1 INTA hardwired to IRQ 16 found-> vendor=0x8086, dev=0x2937, revid=0x02 domain=0, bus=0, slot=26, func=0 class=0c-03-00, hdrtype=0x00, mfdev=1 cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=5 map[20]: type I/O Port, range 32, base 0x1820, size 5, enabled pcib0: matched entry for 0.26.INTA pcib0: slot 26 INTA hardwired to IRQ 16 found-> vendor=0x8086, dev=0x2938, revid=0x02 domain=0, bus=0, slot=26, func=1 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=10 map[20]: type I/O Port, range 32, base 0x1840, size 5, enabled pcib0: matched entry for 0.26.INTB pcib0: slot 26 INTB hardwired to IRQ 17 found-> vendor=0x8086, dev=0x2939, revid=0x02 domain=0, bus=0, slot=26, func=2 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=11 map[20]: type I/O Port, range 32, base 0x1860, size 5, enabled pcib0: matched entry for 0.26.INTC pcib0: slot 26 INTC hardwired to IRQ 18 found-> vendor=0x8086, dev=0x293c, revid=0x02 domain=0, bus=0, slot=26, func=7 class=0c-03-20, hdrtype=0x00, mfdev=0 cmdreg=0x0106, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=11 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xd8601800, size 10, enabled pcib0: matched entry for 0.26.INTC pcib0: slot 26 INTC hardwired to IRQ 18 found-> vendor=0x8086, dev=0x2940, revid=0x02 domain=0, bus=0, slot=28, func=0 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0000, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x40 (16000 ns), maxlat=0x00 (0 ns) intpin=a, irq=5 powerspec 2 supports D0 D3 current D0 MSI supports 1 message pcib0: matched entry for 0.28.INTA pcib0: slot 28 INTA hardwired to IRQ 16 found-> vendor=0x8086, dev=0x2948, revid=0x02 domain=0, bus=0, slot=28, func=4 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0007, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) intpin=a, irq=5 powerspec 2 supports D0 D3 current D0 MSI supports 1 message pcib0: matched entry for 0.28.INTA pcib0: slot 28 INTA hardwired to IRQ 16 found-> vendor=0x8086, dev=0x294a, revid=0x02 domain=0, bus=0, slot=28, func=5 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0007, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) intpin=b, irq=10 powerspec 2 supports D0 D3 current D0 MSI supports 1 message pcib0: matched entry for 0.28.INTB pcib0: slot 28 INTB hardwired to IRQ 17 found-> vendor=0x8086, dev=0x2934, revid=0x02 domain=0, bus=0, slot=29, func=0 class=0c-03-00, hdrtype=0x00, mfdev=1 cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 map[20]: type I/O Port, range 32, base 0x1880, size 5, enabled pcib0: matched entry for 0.29.INTA pcib0: slot 29 INTA hardwired to IRQ 23 found-> vendor=0x8086, dev=0x2935, revid=0x02 domain=0, bus=0, slot=29, func=1 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=11 map[20]: type I/O Port, range 32, base 0x18a0, size 5, enabled pcib0: matched entry for 0.29.INTB pcib0: slot 29 INTB hardwired to IRQ 22 found-> vendor=0x8086, dev=0x2936, revid=0x02 domain=0, bus=0, slot=29, func=2 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=11 map[20]: type I/O Port, range 32, base 0x18c0, size 5, enabled pcib0: matched entry for 0.29.INTC pcib0: slot 29 INTC hardwired to IRQ 18 found-> vendor=0x8086, dev=0x293a, revid=0x02 domain=0, bus=0, slot=29, func=7 class=0c-03-20, hdrtype=0x00, mfdev=0 cmdreg=0x0106, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xd8601c00, size 10, enabled pcib0: matched entry for 0.29.INTA pcib0: slot 29 INTA hardwired to IRQ 23 found-> vendor=0x8086, dev=0x244e, revid=0x92 domain=0, bus=0, slot=30, func=0 class=06-04-01, hdrtype=0x01, mfdev=0 cmdreg=0x0107, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x0c (3000 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2916, revid=0x02 domain=0, bus=0, slot=31, func=0 class=06-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x0210, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2922, revid=0x02 domain=0, bus=0, slot=31, func=2 class=01-06-01, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x02b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=10 powerspec 3 supports D0 D3 current D0 MSI supports 16 messages map[10]: type I/O Port, range 32, base 0x1c50, size 3, enabled map[14]: type I/O Port, range 32, base 0x1c44, size 2, enabled map[18]: type I/O Port, range 32, base 0x1c48, size 3, enabled map[1c]: type I/O Port, range 32, base 0x1c40, size 2, enabled map[20]: type I/O Port, range 32, base 0x18e0, size 5, enabled map[24]: type Memory, range 32, base 0xd8601000, size 11, enabled pcib0: matched entry for 0.31.INTB pcib0: slot 31 INTB hardwired to IRQ 17 found-> vendor=0x8086, dev=0x2930, revid=0x02 domain=0, bus=0, slot=31, func=3 class=0c-05-00, hdrtype=0x00, mfdev=0 cmdreg=0x0001, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=10 map[10]: type Memory, range 64, base 0xd8602000, size 8, memory disabled map[20]: type I/O Port, range 32, base 0x1100, size 5, enabled pcib0: matched entry for 0.31.INTB pcib0: slot 31 INTB hardwired to IRQ 17 found-> vendor=0x8086, dev=0x2932, revid=0x02 domain=0, bus=0, slot=31, func=6 class=11-80-00, hdrtype=0x00, mfdev=0 cmdreg=0x0002, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=5 powerspec 3 supports D0 D3 current D0 map[10]: type Memory, range 64, base 0xd8600000, size 12, enabled pcib0: matched entry for 0.31.INTA pcib0: slot 31 INTA hardwired to IRQ 16 pcib1: irq 16 at device 1.0 on pci0 pcib1: domain 0 pcib1: secondary bus 1 pcib1: subordinate bus 2 pcib1: I/O decode 0xf000-0xfff pcib1: memory decode 0xd8100000-0xd81fffff pcib1: no prefetched decode pcib1: could not get PCI interrupt routing table for \\_SB_.PCI0.PEG_ - AE_NOT_FOUND pci1: on pcib1 pci1: domain=0, physical bus=1 found-> vendor=0x8086, dev=0x032c, revid=0x09 domain=0, bus=1, slot=0, func=0 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0107, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit found-> vendor=0x8086, dev=0x0326, revid=0x09 domain=0, bus=1, slot=0, func=1 class=08-00-20, hdrtype=0x00, mfdev=1 cmdreg=0x0106, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xd8100000, size 12, enabled pcib1: requested memory range 0xd8100000-0xd8100fff: good pcib2: at device 0.0 on pci1 pcib2: domain 0 pcib2: secondary bus 2 pcib2: subordinate bus 2 pcib2: I/O decode 0xf000-0xfff pcib2: no prefetched decode pci2: on pcib2 pci2: domain=0, physical bus=2 uhci0: port 0x1820-0x183f irq 16 at device 26.0 on pci0 uhci0: Reserved 0x20 bytes for rid 0x20 type 4 at 0x1820 ioapic0: routing intpin 16 (PCI IRQ 16) to vector 49 uhci0: [GIANT-LOCKED] uhci0: [ITHREAD] usb0: on uhci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 2 ports with 2 removable, self powered uhci1: port 0x1840-0x185f irq 17 at device 26.1 on pci0 uhci1: Reserved 0x20 bytes for rid 0x20 type 4 at 0x1840 ioapic0: routing intpin 17 (PCI IRQ 17) to vector 50 uhci1: [GIANT-LOCKED] uhci1: [ITHREAD] usb1: on uhci1 usb1: USB revision 1.0 uhub1: on usb1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0x1860-0x187f irq 18 at device 26.2 on pci0 uhci2: Reserved 0x20 bytes for rid 0x20 type 4 at 0x1860 ioapic0: routing intpin 18 (PCI IRQ 18) to vector 51 uhci2: [GIANT-LOCKED] uhci2: [ITHREAD] usb2: on uhci2 usb2: USB revision 1.0 uhub2: on usb2 uhub2: 2 ports with 2 removable, self powered ehci0: mem 0xd8601800-0xd8601bff irq 18 at device 26.7 on pci0 ehci0: Reserved 0x400 bytes for rid 0x10 type 3 at 0xd8601800 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb3: EHCI version 1.0 usb3: companion controllers, 2 ports each: usb0 usb1 usb2 usb3: on ehci0 usb3: USB revision 2.0 uhub3: on usb3 uhub3: 6 ports with 6 removable, self powered pcib3: irq 16 at device 28.0 on pci0 pcib3: domain 0 pcib3: secondary bus 5 pcib3: subordinate bus 5 pcib3: I/O decode 0x0-0x0 pcib3: no prefetched decode pci5: on pcib3 pci5: domain=0, physical bus=5 pcib4: irq 16 at device 28.4 on pci0 pcib4: domain 0 pcib4: secondary bus 13 pcib4: subordinate bus 13 pcib4: I/O decode 0x2000-0x2fff pcib4: memory decode 0xd8000000-0xd80fffff pcib4: no prefetched decode pci13: on pcib4 pci13: domain=0, physical bus=13 found-> vendor=0x8086, dev=0x108c, revid=0x03 domain=0, bus=13, slot=0, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0107, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=5 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 32, base 0xd8000000, size 17, enabled pcib4: requested memory range 0xd8000000-0xd801ffff: good map[18]: type I/O Port, range 32, base 0x2000, size 5, enabled pcib4: requested I/O range 0x2000-0x201f: in range pcib4: matched entry for 13.0.INTA pcib4: slot 0 INTA hardwired to IRQ 16 em0: port 0x2000-0x201f mem 0xd8000000-0xd801ffff irq 16 at device 0.0 on pci13 em0: Reserved 0x20000 bytes for rid 0x10 type 3 at 0xd8000000 em0: attempting to allocate 1 MSI vectors (1 supported) msi: routing MSI IRQ 256 to vector 52 em0: using IRQ 256 for MSI em0: Using MSI interrupt em0: [FILTER] em0: bpf attached em0: Ethernet address: 00:30:48:66:83:a0 pcib5: irq 17 at device 28.5 on pci0 pcib5: domain 0 pcib5: secondary bus 15 pcib5: subordinate bus 15 pcib5: I/O decode 0x3000-0x3fff pcib5: memory decode 0xd8200000-0xd82fffff pcib5: no prefetched decode pci15: on pcib5 pci15: domain=0, physical bus=15 found-> vendor=0x8086, dev=0x109a, revid=0x00 domain=0, bus=15, slot=0, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0107, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 32, base 0xd8200000, size 17, enabled pcib5: requested memory range 0xd8200000-0xd821ffff: good map[18]: type I/O Port, range 32, base 0x3000, size 5, enabled pcib5: requested I/O range 0x3000-0x301f: in range pcib5: matched entry for 15.0.INTA pcib5: slot 0 INTA hardwired to IRQ 17 em1: port 0x3000-0x301f mem 0xd8200000-0xd821ffff irq 17 at device 0.0 on pci15 em1: Reserved 0x20000 bytes for rid 0x10 type 3 at 0xd8200000 em1: attempting to allocate 1 MSI vectors (1 supported) msi: routing MSI IRQ 257 to vector 53 em1: using IRQ 257 for MSI em1: Using MSI interrupt em1: [FILTER] em1: bpf attached em1: Ethernet address: 00:30:48:66:83:a1 uhci3: port 0x1880-0x189f irq 23 at device 29.0 on pci0 uhci3: Reserved 0x20 bytes for rid 0x20 type 4 at 0x1880 ioapic0: routing intpin 23 (PCI IRQ 23) to vector 54 uhci3: [GIANT-LOCKED] uhci3: [ITHREAD] usb4: on uhci3 usb4: USB revision 1.0 uhub4: on usb4 uhub4: 2 ports with 2 removable, self powered uhci4: port 0x18a0-0x18bf irq 22 at device 29.1 on pci0 uhci4: Reserved 0x20 bytes for rid 0x20 type 4 at 0x18a0 ioapic0: routing intpin 22 (PCI IRQ 22) to vector 55 uhci4: [GIANT-LOCKED] uhci4: [ITHREAD] usb5: on uhci4 usb5: USB revision 1.0 uhub5: on usb5 uhub5: 2 ports with 2 removable, self powered uhci5: port 0x18c0-0x18df irq 18 at device 29.2 on pci0 uhci5: Reserved 0x20 bytes for rid 0x20 type 4 at 0x18c0 uhci5: [GIANT-LOCKED] uhci5: [ITHREAD] usb6: on uhci5 usb6: USB revision 1.0 uhub6: on usb6 uhub6: 2 ports with 2 removable, self powered ehci1: mem 0xd8601c00-0xd8601fff irq 23 at device 29.7 on pci0 ehci1: Reserved 0x400 bytes for rid 0x10 type 3 at 0xd8601c00 ehci1: [GIANT-LOCKED] ehci1: [ITHREAD] usb7: EHCI version 1.0 usb7: companion controllers, 2 ports each: usb4 usb5 usb6 usb7: on ehci1 usb7: USB revision 2.0 uhub7: on usb7 uhub7: 6 ports with 6 removable, self powered pcib6: at device 30.0 on pci0 pcib6: domain 0 pcib6: secondary bus 17 pcib6: subordinate bus 17 pcib6: I/O decode 0x4000-0x4fff pcib6: memory decode 0xd8300000-0xd83fffff pcib6: prefetched decode 0xd0000000-0xd7ffffff pcib6: Subtractively decoded bridge. pci17: on pcib6 pci17: domain=0, physical bus=17 found-> vendor=0x1002, dev=0x515e, revid=0x02 domain=0, bus=17, slot=3, func=0 class=03-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0187, statreg=0x0290, cachelnsz=8 (dwords) lattimer=0x42 (1980 ns), mingnt=0x08 (2000 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type Prefetchable Memory, range 32, base 0xd0000000, size 27, enabled pcib6: requested memory range 0xd0000000-0xd7ffffff: good map[14]: type I/O Port, range 32, base 0x4000, size 8, enabled pcib6: requested I/O range 0x4000-0x40ff: in range map[18]: type Memory, range 32, base 0xd8300000, size 16, enabled pcib6: requested memory range 0xd8300000-0xd830ffff: good pcib6: matched entry for 17.3.INTA pcib6: slot 3 INTA hardwired to IRQ 22 found-> vendor=0x1283, dev=0x8213, revid=0x00 domain=0, bus=17, slot=4, func=0 class=01-01-85, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0210, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x08 (2000 ns), maxlat=0x08 (2000 ns) intpin=a, irq=10 powerspec 2 supports D0 D3 current D0 map[10]: type I/O Port, range 32, base 0x4420, size 3, enabled pcib6: requested I/O range 0x4420-0x4427: in range map[14]: type I/O Port, range 32, base 0x4414, size 2, enabled pcib6: requested I/O range 0x4414-0x4417: in range map[18]: type I/O Port, range 32, base 0x4418, size 3, enabled pcib6: requested I/O range 0x4418-0x441f: in range map[1c]: type I/O Port, range 32, base 0x4410, size 2, enabled pcib6: requested I/O range 0x4410-0x4413: in range map[20]: type I/O Port, range 32, base 0x4400, size 4, enabled pcib6: requested I/O range 0x4400-0x440f: in range pcib6: matched entry for 17.4.INTA pcib6: slot 4 INTA hardwired to IRQ 23 vgapci0: port 0x4000-0x40ff mem 0xd0000000-0xd7ffffff,0xd8300000-0xd830ffff irq 22 at device 3.0 on pci17 atapci0: port 0x4420-0x4427,0x4414-0x4417,0x4418-0x441f,0x4410-0x4413,0x4400-0x440f irq 23 at device 4.0 on pci17 atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0x4400 atapci0: [MPSAFE] atapci0: [ITHREAD] ata2: on atapci0 atapci0: Reserved 0x8 bytes for rid 0x10 type 4 at 0x4420 atapci0: Reserved 0x4 bytes for rid 0x14 type 4 at 0x4414 ata2: reset tp1 mask=03 ostat0=60 ostat1=50 ata2: stat0=0x20 err=0x20 lsb=0x20 msb=0x20 ata2: stat1=0x00 err=0x01 lsb=0x14 msb=0xeb ata2: reset tp2 stat0=20 stat1=00 devices=0x8 ata2: [MPSAFE] ata2: [ITHREAD] isab0: at device 31.0 on pci0 isa0: on isab0 atapci1: port 0x1c50-0x1c57,0x1c44-0x1c47,0x1c48-0x1c4f,0x1c40-0x1c43,0x18e0-0x18ff mem 0xd8601000-0xd86017ff irq 17 at device 31.2 on pci0 atapci1: Reserved 0x20 bytes for rid 0x20 type 4 at 0x18e0 atapci1: Reserved 0x800 bytes for rid 0x24 type 3 at 0xd8601000 atapci1: [MPSAFE] atapci1: [ITHREAD] atapci1: AHCI Version 01.20 controller with 6 ports detected ata3: on atapci1 ata3: SATA connect time=0ms ata3: SIGNATURE: 00000101 ata3: ahci_reset devices=0x1 ata3: [MPSAFE] ata3: [ITHREAD] ata4: on atapci1 ata4: SATA connect time=0ms ata4: SIGNATURE: 00000101 ata4: ahci_reset devices=0x1 ata4: [MPSAFE] ata4: [ITHREAD] ata5: on atapci1 ata5: SATA connect time=0ms ata5: SIGNATURE: 00000101 ata5: ahci_reset devices=0x1 ata5: [MPSAFE] ata5: [ITHREAD] ata6: on atapci1 ata6: SATA connect time=0ms ata6: SIGNATURE: 00000101 ata6: ahci_reset devices=0x1 ata6: [MPSAFE] ata6: [ITHREAD] ata7: on atapci1 ata7: port not implemented ata7: [MPSAFE] ata7: [ITHREAD] ata8: on atapci1 ata8: port not implemented ata8: [MPSAFE] ata8: [ITHREAD] pci0: at device 31.3 (no driver attached) pci0: at device 31.6 (no driver attached) acpi_button0: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0047 atkbd: keyboard ID 0x41ab (2) kbd0 at atkbd0 kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 ioapic0: routing intpin 1 (ISA IRQ 1) to vector 56 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: unable to allocate IRQ psmcpnp0: irq 12 on acpi0 psm0: current command byte:0047 psm0: irq 12 on atkbdc0 ioapic0: routing intpin 12 (ISA IRQ 12) to vector 57 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model IntelliMouse Explorer, device ID 4-00, 5 buttons psm0: config:00000000, flags:00000008, packet size:4 psm0: syncmask:08, syncbits:00 sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: irq maps: 0 0 0 0 sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: irq maps: 0 0 0 0 sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A ioapic0: routing intpin 4 (ISA IRQ 4) to vector 58 sio0: [FILTER] sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled sio1: irq maps: 0 0 0 0 sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled sio1: irq maps: 0 0 0 0 sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A ioapic0: routing intpin 3 (ISA IRQ 3) to vector 59 sio1: [FILTER] fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: ic_type 90 part_id 80 ioapic0: routing intpin 6 (ISA IRQ 6) to vector 60 fdc0: [FILTER] ppc0: using extended I/O port range ppc0: ECP SPP ECP+EPP SPP ppc0: port 0x378-0x37f,0x778-0x77f irq 7 drq 3 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/9 bytes threshold ppbus0: on ppc0 ioapic0: routing intpin 7 (ISA IRQ 7) to vector 61 ppbus0: [MPSAFE] ppbus0: [ITHREAD] plip0: on ppbus0 plip0: WARNING: using obsoleted IFF_NEEDSGIANT flag plip0: bpf attached lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 ppc0: [GIANT-LOCKED] ppc0: [ITHREAD] cpu0: on acpi0 ACPI: SSDT @ 0x0xcfe78e06/0x01DD (v 1 PmRef Cpu0Ist 0x00003000 INTL 0x20050228) cpu0: switching to generic Cx mode est0: on cpu0 est0: Invalid id16 (set, cur) = (1563, 2344) est0: Invalid freq 1600, ignored. p4tcc0: on cpu0 cpu1: on acpi0 ACPI: SSDT @ 0x0xcfe78fe3/0x016E (v 1 PmRef Cpu1Ist 0x00003000 INTL 0x20050228) est1: on cpu1 est1: Invalid id16 (set, cur) = (1563, 2344) est1: Invalid freq 1600, ignored. p4tcc1: on cpu1 cpu2: on acpi0 ACPI: SSDT @ 0x0xcfe79151/0x016E (v 1 PmRef Cpu2Ist 0x00003000 INTL 0x20050228) est2: on cpu2 est2: Invalid id16 (set, cur) = (1563, 2344) est2: Invalid freq 1600, ignored. p4tcc2: on cpu2 cpu3: on acpi0 ACPI: SSDT @ 0x0xcfe792bf/0x016E (v 1 PmRef Cpu3Ist 0x00003000 INTL 0x20050228) est3: on cpu3 est3: Invalid id16 (set, cur) = (1563, 2344) est3: Invalid freq 1600, ignored. p4tcc3: on cpu3 ex_isa_identify() atkbdc: atkbdc0 already exists; skipping it fdc: fdc0 already exists; skipping it ppc: ppc0 already exists; skipping it sio: sio0 already exists; skipping it sio: sio1 already exists; skipping it ahc_isa_probe 1: ioport 0x1c00 alloc failed sc: sc0 already exists; skipping it vga: vga0 already exists; skipping it isa_probe_children: disabling PnP devices isa_probe_children: probing non-PnP devices orm0: at iomem 0xc0000-0xcafff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sc0: fb0, kbd1, terminal emulator: sc (syscons terminal) sio2: not probed (disabled) sio3: not probed (disabled) vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 isa_probe_children: probing PnP devices umass0: on uhub0 umass0:0:0:-1: Attached to scbus0 Device configuration finished. Reducing kern.maxvnodes 343811 -> 100000 procfs registered lapic: Divisor 2, Frequency 133000612 hz Timecounter "TSC" frequency 2394010944 Hz quality -100 Timecounters tick every 1.000 msec lo0: bpf attached hptrr: no controller detected. ata2-slave: pio=PIO4 wdma=WDMA2 udma=UDMA33 cable=80 wire acd0: setting PIO4 on IT8213F chip acd0: DVDROM drive at ata2 as slave acd0: read 4134KB/s (4134KB/s), 2048KB buffer, PIO4 acd0: Reads: CDR, CDRW, CDDA stream, DVDROM, DVDR, DVDRAM, packet acd0: Writes: acd0: Audio: play, 256 volume levels acd0: Mechanism: ejectable tray, unlocked acd0: Medium: CD-R 120mm data disc ata3-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire ad6: 305245MB at ata3-master SATA300 ad6: 625142448 sectors [620181C/16H/63S] 16 sectors/interrupt 1 depth queue ad6: Intel check1 failed ad6: Adaptec check1 failed ad6: LSI (v3) check1 failed ad6: LSI (v2) check1 failed ad6: FreeBSD check1 failed ata4-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire ad8: 305245MB at ata4-master SATA300 ad8: 625142448 sectors [620181C/16H/63S] 16 sectors/interrupt 1 depth queue ad8: Intel check1 failed ad8: Adaptec check1 failed ad8: LSI (v3) check1 failed ad8: LSI (v2) check1 failed ad8: FreeBSD check1 failed ata5-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire ad10: 305245MB at ata5-master SATA300 ad10: 625142448 sectors [620181C/16H/63S] 16 sectors/interrupt 1 depth queue ad10: Intel check1 failed ad10: Adaptec check1 failed ad10: LSI (v3) check1 failed ad10: LSI (v2) check1 failed ad10: FreeBSD check1 failed ata6-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire ad12: 305245MB at ata6-master SATA300 ad12: 625142448 sectors [620181C/16H/63S] 16 sectors/interrupt 1 depth queue ad12: Intel check1 failed ad12: Adaptec check1 failed ad12: LSI (v3) check1 failed ad12: LSI (v2) check1 failed ad12: FreeBSD check1 failed (probe0:umass-sim0:0:0:0): Down reving Protocol Version from 2 to 0? acd0: FAILURE - READ_BIG ILLEGAL REQUEST asc=0x64 ascq=0x00 (probe0:umass-sim0:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 (probe0:umass-sim0:0:0:0): CAM Status: SCSI Status Error (probe0:umass-sim0:0:0:0): SCSI Status: Check Condition (probe0:umass-sim0:0:0:0): UNIT ATTENTION asc:28,0 (probe0:umass-sim0:0:0:0): Not ready to ready change, medium may have changed (probe0:umass-sim0:0:0:0): (probe0:umass-sim0:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 (probe0:umass-sim0:0:0:0): UNIT ATTENTION asc:28,0 (probe0:umass-sim0:0:0:0): Not ready to ready change, medium may have changed Retrying Command (per Sense Data) (probe0:umass-sim0:0:0:0): Retrying Command pass0 at umass-sim0 bus 0 target 0 lun 0 pass0: Removable Direct Access SCSI-0 device pass0: 20KB/s transfers ATA PseudoRAID loaded SMP: AP CPU #1 Launched! cpu1 AP: ID: 0x01000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000200ef therm: 0x00010000 err: 0x00010000 pcm: 0x00010000 SMP: AP CPU #3 Launched! cpu3 AP: ID: 0x03000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000200ef therm: 0x00010000 err: 0x00010000 pcm: 0x00010000 SMP: AP CPU #2 Launched! cpu2 AP: ID: 0x02000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000200ef therm: 0x00010000 err: 0x00010000 pcm: 0x00010000 ioapic0: Assigning ISA IRQ 1 to local APIC 0 ioapic0: Assigning ISA IRQ 3 to local APIC 1 ioapic0: Assigning ISA IRQ 4 to local APIC 2 ioapic0: Assigning ISA IRQ 6 to local APIC 3 ioapic0: Assigning ISA IRQ 7 to local APIC 0 ioapic0: Assigning ISA IRQ 9 to local APIC 1 ioapic0: Assigning ISA IRQ 12 to local APIC 2 ioapic0: Assigning PCI IRQ 16 to local APIC 3 ioapic0: Assigning PCI IRQ 17 to local APIC 0 ioapic0: Assigning PCI IRQ 18 to local APIC 1 ioapic0: Assigning PCI IRQ 22 to local APIC 2 ioapic0: Assigning PCI IRQ 23 to local APIC 3 msi: Assigning MSI IRQ 256 to local APIC 0 msi: Assigning MSI IRQ 257 to local APIC 1 da0 at umass-sim0 bus 0 target 0 lun 0 da0: Removable Direct Access SCSI-0 device da0: 20KB/s transfers da0: 1MB (2880 512 byte sectors: 64H 32S/T 1C) acd0: FAILURE - READ_BIG ILLEGAL REQUEST asc=0x64 ascq=0x00 GEOM_LABEL: Label for provider acd0 is iso9660/FreeBSD_Install. GEOM: new disk ad6 acd0: FAILURE - READ_BIG ILLEGAL REQUEST asc=0x64 ascq=0x00 acd0: FAILURE - READ_BIG ILLEGAL REQUEST asc=0x64 ascq=0x00 GEOM: new disk ad8 GEOM: new disk ad10 GEOM: new disk ad12 GEOM: new disk da0 acd0: FAILURE - READ_BIG ILLEGAL REQUEST asc=0x64 ascq=0x00 GEOM_MIRROR: Device mirror/gm0 launched (3/3). GEOM_LABEL: Label for provider ad12s1 is ufsid/488efb68e5c53bb1. GEOM_LABEL: Label for provider mirror/gm0s1a is ufsid/489cb5723873a365. GEOM_LABEL: Label for provider mirror/gm0s1d is ufsid/489cb5806d417263. GEOM_LABEL: Label for provider mirror/gm0s1e is ufsid/489cb5847a0f8baa. GEOM_LABEL: Label for provider mirror/gm0s1f is ufsid/489cb58839896589. GEOM_LABEL: Label for provider mirror/gm0s1g is ufsid/489cb58c07734311. Trying to mount root from ufs:/dev/mirror/gm0s1a start_init: trying /sbin/init GEOM_LABEL: Label ufsid/489cb5723873a365 removed. GEOM_LABEL: Label for provider mirror/gm0s1a is ufsid/489cb5723873a365. GEOM_LABEL: Label ufsid/489cb5806d417263 removed. GEOM_LABEL: Label for provider mirror/gm0s1d is ufsid/489cb5806d417263. GEOM_LABEL: Label ufsid/489cb5847a0f8baa removed. GEOM_LABEL: Label for provider mirror/gm0s1e is ufsid/489cb5847a0f8baa. GEOM_LABEL: Label ufsid/489cb58839896589 removed. GEOM_LABEL: Label for provider mirror/gm0s1f is ufsid/489cb58839896589. GEOM_LABEL: Label ufsid/489cb58c07734311 removed. GEOM_LABEL: Label for provider mirror/gm0s1g is ufsid/489cb58c07734311. GEOM_LABEL: Label ufsid/489cb5723873a365 removed. GEOM_LABEL: Label ufsid/489cb5806d417263 removed. GEOM_LABEL: Label ufsid/489cb5847a0f8baa removed. GEOM_LABEL: Label ufsid/489cb58839896589 removed. GEOM_LABEL: Label ufsid/489cb58c07734311 removed. em1: Link is up 1000 Mbps Full Duplex em0: Link is up 1000 Mbps Full Duplex em0: link state changed to UP -- ian j hart ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From owner-freebsd-stable@FreeBSD.ORG Mon Jul 6 14:30:04 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 70EFC10656C8 for ; Mon, 6 Jul 2009 14:30:04 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by mx1.freebsd.org (Postfix) with ESMTP id 44FDE8FC08 for ; Mon, 6 Jul 2009 14:30:04 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id C8EEA3AE739 for ; Mon, 6 Jul 2009 10:30:03 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute1.internal (MEProxy); Mon, 06 Jul 2009 10:30:03 -0400 X-Sasl-enc: Wh/M4B52hKUDdI7IvKX9P6LW1Nnkz/EdyajWyQsS6fOp 1246890603 Received: from anglepoise.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id 68E072692A for ; Mon, 6 Jul 2009 10:30:03 -0400 (EDT) Message-ID: <4A520A69.4010000@incunabulum.net> Date: Mon, 06 Jul 2009 15:30:01 +0100 From: Bruce Simpson User-Agent: Thunderbird 2.0.0.22 (X11/20090626) MIME-Version: 1.0 To: freebsd-stable Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Merging a GCC bug fix to RELENG_7 - how? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 14:30:05 -0000 Hi all, This GCC bug bites us in the Boost regression tests in a number of places. Uh oh, I've stepped on the one-line fix bomb: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31899 http://gcc.gnu.org/viewcvs?view=rev&revision=129199 What's funny is that COPYING in the root of that branch is GPLv2, but the affected file's license is GPLv3. So what on earth do we do? thanks, BMS From owner-freebsd-stable@FreeBSD.ORG Mon Jul 6 16:07:34 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E7D8F106567C for ; Mon, 6 Jul 2009 16:07:34 +0000 (UTC) (envelope-from miklosovic.freebsd@gmail.com) Received: from mail-bw0-f221.google.com (mail-bw0-f221.google.com [209.85.218.221]) by mx1.freebsd.org (Postfix) with ESMTP id 72B988FC22 for ; Mon, 6 Jul 2009 16:07:34 +0000 (UTC) (envelope-from miklosovic.freebsd@gmail.com) Received: by bwz21 with SMTP id 21so529135bwz.43 for ; Mon, 06 Jul 2009 09:07:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=clI4uJQ4i8AChES3hA3eUwZTBcAU8HMjdzHynchYNJs=; b=jON2xAf5vqFhY7H5iaiTywftN4OQtl5n9kPYtpqvC/OvWV4y5rgvb8UsfHuhPmOFZu OMnlU6GK4igAC+3iMnJDeaPm7aCjadfpHLDsw/tzVGVKAR6Yql6uPohEQLHl7ykD3EYt 3kF0geHgzbjhyZN/jRbJlwsRQN3ppVNon/JYM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=n4AmxiAZVmsEuAvlRm1xK9bbjA95luHoMHwITynQ22sfqzAIlZ8uNbAU6R7jUT9/rp eB31n5a5Z0Tup/dypw/gqHvVwD5GSQCG7oSWPC6MRJWJ6OsGcPqDkIw+jVPFzOMkwwmN iGfMIMKaxAw0RmK8++f+Yba+2GW8D6OKj0HSI= MIME-Version: 1.0 Received: by 10.103.6.14 with SMTP id j14mr2735959mui.48.1246894914195; Mon, 06 Jul 2009 08:41:54 -0700 (PDT) Date: Mon, 6 Jul 2009 17:41:54 +0200 Message-ID: From: Stefan Miklosovic To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: acer aspire 3613 acpi problem X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 16:07:35 -0000 hi all, I have a problem with acpi at acer aspire 3613. While it boot, errors appears. Here are links for more information. I did like is written in acpi handbook for freebsd. I also run iasl command, but nothing changed. http://dexter.kmit.sk/~stewe/asl_output http://dexter.kmit.sk/~stewe/hw.acpi http://dexter.kmit.sk/~stewe/stewe-freebsd72.asl http://dexter.kmit.sk/~stewe/dmesg_verbose thank you have a nice day From owner-freebsd-stable@FreeBSD.ORG Mon Jul 6 16:33:56 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5D8A9106564A for ; Mon, 6 Jul 2009 16:33:56 +0000 (UTC) (envelope-from sulfurfff@gmail.com) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.25]) by mx1.freebsd.org (Postfix) with ESMTP id 18C098FC17 for ; Mon, 6 Jul 2009 16:33:55 +0000 (UTC) (envelope-from sulfurfff@gmail.com) Received: by qw-out-2122.google.com with SMTP id 5so1559806qwd.7 for ; Mon, 06 Jul 2009 09:33:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=6RQpyk8ugZ1j7STYjgw0PxgKCUkSjux6G4CPhFmf8ig=; b=dL/z05XQSbr3p4b39AgFswKd5p9ZL34P1uUKYxfMViABpnKxS+bPz9ecJUZBs4Oiqt wxbp75V95WGco8+02kMvLrnKtKM3PaTNDaDJDKbwzwf1OhTuxtdBcsiG5XVxJcmHwejG D7IcIyJ7cqyGdpaMfKalJ/+24AYZN5c4yCZwg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=fkwFnFffBYqFYNGP38xm/ocZR9/VS8FVixvZ4flbkaus2qArIey+1KS8YYCgwX2Oxu sTHZSe+mXxDdXQPlCPJXHvEHnMCYOQ8+hoWkKrsr9G+mS6j/UvV/DcsoH9akQokLX5xW ZEJlhiH8tjBBKUQmh4ve9h47X3rtZjfHX2xUM= MIME-Version: 1.0 Received: by 10.231.11.136 with SMTP id t8mr2387086ibt.50.1246896254045; Mon, 06 Jul 2009 09:04:14 -0700 (PDT) Date: Mon, 6 Jul 2009 11:04:14 -0500 Message-ID: From: "Ishmael F.E." To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: upgrading ports without recompiling X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 16:33:56 -0000 Hi there . =BFHow can I upgrade my ports without having to recompile everything? . I allready did # freebsd-update -r 7.2-RELEASE upgrade install # reboot # freebsd-update install . But it didn'nt upgrade the ports, so I tryed # portupgrade -af but it tried to compile everything . I also tried # portsnap fetch # portsnap extract # portsnap fetch update # portupgrade -a --batch -u -P . but it also tried to compile everything . so, =BFhow can I upgrade the ports? unfortunatley I don't have time to compile my 64bit system . . --=20 [=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D] [En muchos lugares, tomar fotos es visto como] [una costumbre vil y reprensible ] [=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D] From owner-freebsd-stable@FreeBSD.ORG Mon Jul 6 17:16:38 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AE241106566C for ; Mon, 6 Jul 2009 17:16:38 +0000 (UTC) (envelope-from mike@jellydonut.org) Received: from mail-bw0-f221.google.com (mail-bw0-f221.google.com [209.85.218.221]) by mx1.freebsd.org (Postfix) with ESMTP id 455538FC0C for ; Mon, 6 Jul 2009 17:16:37 +0000 (UTC) (envelope-from mike@jellydonut.org) Received: by bwz21 with SMTP id 21so569911bwz.43 for ; Mon, 06 Jul 2009 10:16:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.113.3 with SMTP id y3mr2165912fap.71.1246898848117; Mon, 06 Jul 2009 09:47:28 -0700 (PDT) In-Reply-To: References: Date: Mon, 6 Jul 2009 12:47:28 -0400 Message-ID: <1de79840907060947j6cdf96f6k7966a866ef02a13b@mail.gmail.com> From: Michael Proto To: "Ishmael F.E." Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org Subject: Re: upgrading ports without recompiling X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 17:16:39 -0000 On Mon, Jul 6, 2009 at 12:04 PM, Ishmael F.E. wrote: > Hi there > . > =BFHow can I upgrade my ports without having to recompile everything? > . > I allready did > # freebsd-update -r 7.2-RELEASE upgrade install > # reboot > # freebsd-update install > . > But it didn'nt upgrade the ports, so I tryed > # portupgrade -af > but it tried to compile everything > . > I also tried > # portsnap fetch > # portsnap extract > # portsnap fetch update > # portupgrade -a --batch -u -P > . > but it also tried to compile everything > . > so, =BFhow can I upgrade the ports? > unfortunatley I don't have time to compile my 64bit system You could use packages provided by the FreeBSD package repositories... portupgrade -aP Although those packages will contain the standard port options, which may differ from your installed ports if you compiled them originally and changed any of the options screens. If you're looking to upgrade ports with custom options applied, then rebuilding your ports from source is your only real option. -Proto From owner-freebsd-stable@FreeBSD.ORG Mon Jul 6 17:20:17 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 952A7106566C for ; Mon, 6 Jul 2009 17:20:17 +0000 (UTC) (envelope-from mike@jellydonut.org) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by mx1.freebsd.org (Postfix) with ESMTP id 31CCB8FC17 for ; Mon, 6 Jul 2009 17:20:16 +0000 (UTC) (envelope-from mike@jellydonut.org) Received: by fxm18 with SMTP id 18so3678381fxm.43 for ; Mon, 06 Jul 2009 10:20:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.117.75 with SMTP id p11mr1879911faq.75.1246898928123; Mon, 06 Jul 2009 09:48:48 -0700 (PDT) In-Reply-To: <1de79840907060947j6cdf96f6k7966a866ef02a13b@mail.gmail.com> References: <1de79840907060947j6cdf96f6k7966a866ef02a13b@mail.gmail.com> Date: Mon, 6 Jul 2009 12:48:47 -0400 Message-ID: <1de79840907060948o28bfc23fu2aa325cb11802997@mail.gmail.com> From: Michael Proto To: "Ishmael F.E." Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: upgrading ports without recompiling X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 17:20:17 -0000 On Mon, Jul 6, 2009 at 12:47 PM, Michael Proto wrote: > You could use packages provided by the FreeBSD package repositories... > > portupgrade -aP > > Although those packages will contain the standard port options, which > may differ from your installed ports if you compiled them originally > and changed any of the options screens. If you're looking to upgrade > ports with custom options applied, then rebuilding your ports from > source is your only real option. > > > -Proto > Sorry, try "portupgrade -aPP" to use ONLY precompiled packages. -Proto From owner-freebsd-stable@FreeBSD.ORG Mon Jul 6 17:28:13 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2CB481065672 for ; Mon, 6 Jul 2009 17:28:13 +0000 (UTC) (envelope-from tevans.uk@googlemail.com) Received: from mail-ew0-f213.google.com (mail-ew0-f213.google.com [209.85.219.213]) by mx1.freebsd.org (Postfix) with ESMTP id A94ED8FC25 for ; Mon, 6 Jul 2009 17:28:11 +0000 (UTC) (envelope-from tevans.uk@googlemail.com) Received: by ewy9 with SMTP id 9so4382626ewy.43 for ; Mon, 06 Jul 2009 10:28:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:subject:from:to:cc :in-reply-to:references:content-type:date:message-id:mime-version :x-mailer:content-transfer-encoding; bh=Cnlyqb7e7WNG68VaHb+aEGlm4xg03l99mQCJMB+SBCY=; b=hmf+XamH3Puz9l6J2u/d19fQNS8WEwF6kPmOxfz7Q7nMBkuxpYvrN4zJPiQWG+9IFe DTyLbr72J6LX25SL841udF2iVLh6QYZa02SKJk+YZd7gSe3wWg2xsOiJBjZ0qDgNxUDp I0Y2XUppOztf64YtGRwgO3IDOFhEQSASKT730= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:x-mailer:content-transfer-encoding; b=ASTHVV9PHDwd1EVo96FyTEP57LEpSwDfUjmDt9pKXcZ+l5GNLiy/l1iNSlTDY6b3TZ pFAUtaLO0TqZhUK4Kq2SGdVlx+0MRFfH812tRC/S3dTIwN+fZJlrSKHzPpNqmcLZtKDT G4YdJstyN5VALj4qN7sXOoLrxiC90pfjuWN0w= Received: by 10.210.116.14 with SMTP id o14mr5786963ebc.97.1246899452534; Mon, 06 Jul 2009 09:57:32 -0700 (PDT) Received: from ?127.0.0.1? (87-194-39-182.bethere.co.uk [87.194.39.182]) by mx.google.com with ESMTPS id 28sm288353eye.16.2009.07.06.09.57.27 (version=SSLv3 cipher=RC4-MD5); Mon, 06 Jul 2009 09:57:27 -0700 (PDT) From: Tom Evans To: "Ishmael F.E." In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Date: Mon, 06 Jul 2009 17:57:26 +0100 Message-Id: <1246899446.2437.227.camel@strangepork.london.mintel.ad> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 8bit Cc: freebsd-stable@freebsd.org Subject: Re: upgrading ports without recompiling X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 17:28:13 -0000 On Mon, 2009-07-06 at 11:04 -0500, Ishmael F.E. wrote: > Hi there > . > ¿How can I upgrade my ports without having to recompile everything? > . > I allready did > # freebsd-update -r 7.2-RELEASE upgrade install > # reboot > # freebsd-update install > . > But it didn'nt upgrade the ports, so I tryed > # portupgrade -af > but it tried to compile everything > . > I also tried > # portsnap fetch > # portsnap extract > # portsnap fetch update > # portupgrade -a --batch -u -P > . > but it also tried to compile everything > . > so, ¿how can I upgrade the ports? > unfortunatley I don't have time to compile my 64bit system > . > . portupgrade will use packages where available with the -P flag, and will only use packages with the -PP flag. However, since you say it failed to find packages with -P, falling back to recompiling, then it will probably fail even more with -PP. man portupgrade for more details. Cheers Tom From owner-freebsd-stable@FreeBSD.ORG Mon Jul 6 17:46:29 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2A58E106566C for ; Mon, 6 Jul 2009 17:46:29 +0000 (UTC) (envelope-from amarat@ksu.ru) Received: from mx.kzn.ru (mx.kzn.ru [194.85.243.38]) by mx1.freebsd.org (Postfix) with ESMTP id 1833E8FC14 for ; Mon, 6 Jul 2009 17:46:27 +0000 (UTC) (envelope-from amarat@ksu.ru) Authentication-Results: iout.kzn.ru; dkim=neutral (message not signed) header.i=none Received-SPF: None identity=pra; client-ip=193.232.252.56; receiver=iout.kzn.ru; envelope-from="amarat@ksu.ru"; x-sender="amarat@ksu.ru"; x-conformance=sidf_compatible Received-SPF: None identity=mailfrom; client-ip=193.232.252.56; receiver=iout.kzn.ru; envelope-from="amarat@ksu.ru"; x-sender="amarat@ksu.ru"; x-conformance=sidf_compatible Received-SPF: None identity=helo; client-ip=193.232.252.56; receiver=iout.kzn.ru; envelope-from="amarat@ksu.ru"; x-sender="postmaster@ruby.ksu.ru"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aq4EAPvUUUrCVfWh/2dsb2JhbACBUc1YgnaBHAWBOg X-IronPort-AV: E=Sophos;i="4.42,357,1243800000"; d="p7s'?scan'208";a="4200180" Received: from mail.ksu.ru (HELO ruby.ksu.ru) ([193.232.252.56]) by iout.kzn.ru with ESMTP; 06 Jul 2009 21:46:26 +0400 X-Pass-Through: Kazan State University Network Received: from zealot.ksu.ru ([194.85.245.161]) by ksu.ru (8.13.4/8.13.4) with ESMTP id n66GrNq8021161; Mon, 6 Jul 2009 16:53:24 GMT Received: from zealot.ksu.ru (localhost.lnet [127.0.0.1]) by zealot.ksu.ru (8.14.3/8.14.3) with ESMTP id n66Hjj6l051586; Mon, 6 Jul 2009 21:45:46 +0400 (MSD) (envelope-from amarat@ksu.ru) Message-ID: <4A523849.1070001@ksu.ru> Date: Mon, 06 Jul 2009 21:45:45 +0400 From: "Marat N.Afanasyev" User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.8.1.22) Gecko/20090704 SeaMonkey/1.1.17 MIME-Version: 1.0 To: Ralf Folkerts , FreeBSD-STABLE Mailing List References: <4A50E947.9020608@ksu.ru> <4A523518.7050008@gmx.de> In-Reply-To: <4A523518.7050008@gmx.de> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030503080109080001060808" Cc: Subject: Re: bug in ufs? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 17:46:29 -0000 This is a cryptographically signed message in MIME format. --------------ms030503080109080001060808 Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Ralf Folkerts wrote: > Marat N.Afanasyev wrote: >> hello! >> >> i have a strange problem with writing data to my ufs2+su filesystem. >> >> 1. i made a 1T gpt partition on my storage server, and formatted it: >> newfs -U -m 0 -o time -i 32768 /dev/da1p3a >> >> 2. i tried to move data from other servers to this filesystem, total >> size of files is slightly less than 1T >> >> 3. i encountered a 'No space left on device' while i still have 11G of >> free space and about 13 million free inodes on the filesystem: >> >> #df -ih >> Filesystem Size Used Avail Capacity iused ifree %iused >> Mounted on >> /dev/da1p3a 1.0T 1.0T 11G 99% 20397465 13363173 60% >> /mnt/45_114 >> >> all i want to know is whether this is a bug or a feature? and if such >> a behavior is well-known, where can i read about it? > Hi Marat, > > just a guess: Are there sparse Files on the Source System that are not > being detected by the Tool you used to restore the data? If you used > (bsd)tar, did you try -S? > > A while ago I ran into a similar Problem when copying > Oracle-Database-Files (on Linux, though) and the -S - Option came to > rescue. > > Cheers, > _ralf_ i have a huge amount of small files on the source systems, as you can see they have about 20 million files and almost each of them is jpeg or gif. afaik, there are no sparse files at all. i still cannot figure out what is it: a free space leak in ufs2+su or bug in statfs(3), that is used in df, or something else. -- SY, Marat --------------ms030503080109080001060808 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII8zCC AtQwggI9oAMCAQICEHpsMo6nkbUVegxjAzzxYCkwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDQwMTE5MTUxOFoX DTEwMDQwMTE5MTUxOFowPzEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEcMBoG CSqGSIb3DQEJARYNYW1hcmF0QGtzdS5ydTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALqa7MfgjbsxmgpTOKxAN7w+cFViFA8NrULAARwVQJQJCnVRGf3i97EwNdLE8VTNniU4 ybS4gtLsy9gfNuuyPV2AJESpgrxaG+KZyHu1f6P4e31YBbnbtWVTUxZ3U/vWoL+BOAOI4S84 Cx834a4uYK75WhpZKd56qet5loyn9N1wBZNgCh9AwU31lA/Q0iCSKpEIxuhbElNXHNnqAlts CtNXsKgsT8mP7QI52h0cBOPSZqvz++e/wruJGgKeCECqo8ftwwya3CYkH1lhH2Q1zeXwez1E 1+solM48odH+odn29ctmOqr3PzZfmBJyGFf5FagTKNia/ys48yBtVU/RXHsCAwEAAaMqMCgw GAYDVR0RBBEwD4ENYW1hcmF0QGtzdS5ydTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUA A4GBAG4Pj7KRSJ/M28KNynJOPCHg26L15S9OfQ+ckMaPPDRAejtdlUdCgkoyD9d1Du/amAk6 A3NcY2I/MsFW2vSonQfU+7cJZiyuhfw7wQlOovCx7USw1dmF6u3EljWZV+Kg4Vi3vN2dPyJx tv8li9McWQoMLmm5zzFGGRaSRnnrnZFsMIIC1DCCAj2gAwIBAgIQemwyjqeRtRV6DGMDPPFg KTANBgkqhkiG9w0BAQUFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1 bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElz c3VpbmcgQ0EwHhcNMDkwNDAxMTkxNTE4WhcNMTAwNDAxMTkxNTE4WjA/MR8wHQYDVQQDExZU aGF3dGUgRnJlZW1haWwgTWVtYmVyMRwwGgYJKoZIhvcNAQkBFg1hbWFyYXRAa3N1LnJ1MIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuprsx+CNuzGaClM4rEA3vD5wVWIUDw2t QsABHBVAlAkKdVEZ/eL3sTA10sTxVM2eJTjJtLiC0uzL2B8267I9XYAkRKmCvFob4pnIe7V/ o/h7fVgFudu1ZVNTFndT+9agv4E4A4jhLzgLHzfhri5grvlaGlkp3nqp63mWjKf03XAFk2AK H0DBTfWUD9DSIJIqkQjG6FsSU1cc2eoCW2wK01ewqCxPyY/tAjnaHRwE49Jmq/P757/Cu4ka Ap4IQKqjx+3DDJrcJiQfWWEfZDXN5fB7PUTX6yiUzjyh0f6h2fb1y2Y6qvc/Nl+YEnIYV/kV qBMo2Jr/KzjzIG1VT9FcewIDAQABoyowKDAYBgNVHREEETAPgQ1hbWFyYXRAa3N1LnJ1MAwG A1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEFBQADgYEAbg+PspFIn8zbwo3Kck48IeDbovXlL059 D5yQxo88NEB6O12VR0KCSjIP13UO79qYCToDc1xjYj8ywVba9KidB9T7twlmLK6F/DvBCU6i 8LHtRLDV2YXq7cSWNZlX4qDhWLe83Z0/InG2/yWL0xxZCgwuabnPMUYZFpJGeeudkWwwggM/ MIICqKADAgECAgENMA0GCSqGSIb3DQEBBQUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMM V2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25z dWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYD VQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNv bmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDMwNzE3MDAwMDAwWhcNMTMwNzE2MjM1OTU5 WjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRk LjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwgZ8wDQYJ KoZIhvcNAQEBBQADgY0AMIGJAoGBAMSmPFVzVftOucqZWh5owHUEcJ3f6f+jHuy9zfVb8hp2 vX8MOmHyv1HOAdTlUAow1wJjWiyJFXCO3cnwK4Vaqj9xVsuvPAsH5/EfkTYkKhPPK9Xzgnc9 A74r/rsYPge/QIACZNenprufZdHFKlSFD0gEf6e20TxhBEAeZBlyYLf7AgMBAAGjgZQwgZEw EgYDVR0TAQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6MDigNqA0hjJodHRwOi8vY3JsLnRoYXd0 ZS5jb20vVGhhd3RlUGVyc29uYWxGcmVlbWFpbENBLmNybDALBgNVHQ8EBAMCAQYwKQYDVR0R BCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDItMTM4MA0GCSqGSIb3DQEBBQUAA4GB AEiM0VCD6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0whuPg2H6otnzYvwPQcUCCTcDz9reFhYsPZ Ohl+hLGZGwDFGguCdJ4lUJRix9sncVcljd2pnDmOjCBPZV+V2vf3h9bGCE6u9uo05RAaWzVN d+NWIXiC3CEZNd4ksdMdRv9dX2VPMYIDZDCCA2ACAQEwdjBiMQswCQYDVQQGEwJaQTElMCMG A1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEHpsMo6nkbUVegxjAzzxYCkwCQYFKw4DAhoF AKCCAcMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDkwNzA2 MTc0NTQ1WjAjBgkqhkiG9w0BCQQxFgQUHLMebWWFUctxjbh+oG34Vkt4Df0wUgYJKoZIhvcN AQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYF Kw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhB6bDKOp5G1FXoMYwM88WApMIGHBgsq hkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1 aW5nIENBAhB6bDKOp5G1FXoMYwM88WApMA0GCSqGSIb3DQEBAQUABIIBAC4Vzb4jedKfk8q3 yvUP5H5CeUDdxB9PMVWsg0dvfcp0VPRdIwvg3iZ6y3RxiGjQxnoQvHiGK9+Ktzx4+sZ4ekFt /yHXjIphe6/lVV/UeFwDTHpMXDbbDTPuKC6VYEUjcDyMk+J7Pn5US6eZhqWWx0Vo3+4wNpvZ tAKIcMoemfroMgB1fQKt4uaoiGLgmhwMeoTGG84Y24hqIUqfRQHQLDtCeUzdyT8MpPlElUUJ pjRM0/Qv/rfn9Z46Jv35txLuaZSW6QQpLibI9R5JXBkJnrlFlBYm2oC9JMjsLerQoOtrwzvn cq3I7N48+CpC2v21hVH0iwiV2dVbGL6oKsG8mfEAAAAAAAA= --------------ms030503080109080001060808-- From owner-freebsd-stable@FreeBSD.ORG Mon Jul 6 18:25:15 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2763D106564A for ; Mon, 6 Jul 2009 18:25:15 +0000 (UTC) (envelope-from tkjacobsen@gmail.com) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by mx1.freebsd.org (Postfix) with ESMTP id A56238FC08 for ; Mon, 6 Jul 2009 18:25:14 +0000 (UTC) (envelope-from tkjacobsen@gmail.com) Received: by fxm18 with SMTP id 18so3712731fxm.43 for ; Mon, 06 Jul 2009 11:25:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date :user-agent:references:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:message-id; bh=WFZ8Lbwc6Oj8hxCOOJpDfEHyMUvg2M96+lUqePWVmOA=; b=VbFqY19PkA6CLyGCJ4QOF7kPztwbdX2gS2fdbEhUwWAEn8XTUhEHFTDeGpbLfc+9dI ZV6Rw45DLdwBZVbJeCIZ5J2R5ur16eX1adr1PumLsj/51vpyxqcCfDNXKKu06ybJGjmS mwnfdZiySUkqxrjRGIaLI8c0DhvqKWVIJZnhA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:references:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :message-id; b=H33fvyVHlQ4AhXT/uoiQYBMEcmsqiAKsRkYOn4IDvpo1M/o1ZPU4HcmT+KNQcOeWi2 wzYkKirkaHdJhj4OTO4tlQaZn7rsOpOQJ3nRuYBon5Syq/I5jbgJHvwQRbsMhKUttgCo qFU6ZTlHRWYIc6c22k25N0a/QsGdB/LWNofuo= Received: by 10.103.160.10 with SMTP id m10mr2757214muo.50.1246902720066; Mon, 06 Jul 2009 10:52:00 -0700 (PDT) Received: from photon.std (84-238-115-154.u.parknet.dk [84.238.115.154]) by mx.google.com with ESMTPS id t10sm35018617muh.30.2009.07.06.10.51.59 (version=SSLv3 cipher=RC4-MD5); Mon, 06 Jul 2009 10:51:59 -0700 (PDT) From: Troels Kofoed Jacobsen To: freebsd-stable@freebsd.org Date: Mon, 6 Jul 2009 19:51:55 +0200 User-Agent: KMail/1.11.4 (FreeBSD/7.2-STABLE; KDE/4.2.4; amd64; ; ) References: <1246899446.2437.227.camel@strangepork.london.mintel.ad> In-Reply-To: <1246899446.2437.227.camel@strangepork.london.mintel.ad> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200907061951.56023.tkjacobsen@gmail.com> Subject: Re: upgrading ports without recompiling X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 18:25:15 -0000 On Monday 06 July 2009 18:57:26 Tom Evans wrote: > On Mon, 2009-07-06 at 11:04 -0500, Ishmael F.E. wrote: > > Hi there > > . > > =C2=BFHow can I upgrade my ports without having to recompile everything? > > . > > I allready did > > # freebsd-update -r 7.2-RELEASE upgrade install > > # reboot > > # freebsd-update install > > . > > But it didn'nt upgrade the ports, so I tryed > > # portupgrade -af > > but it tried to compile everything > > . > > I also tried > > # portsnap fetch > > # portsnap extract > > # portsnap fetch update > > # portupgrade -a --batch -u -P > > . > > but it also tried to compile everything > > . > > so, =C2=BFhow can I upgrade the ports? > > unfortunatley I don't have time to compile my 64bit system > > . > > . > > portupgrade will use packages where available with the -P flag, and will > only use packages with the -PP flag. However, since you say it failed to > find packages with -P, falling back to recompiling, then it will > probably fail even more with -PP. > > man portupgrade for more details. > > Cheers > > Tom > > _______________________________________________ > 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" Have a look at pkg_upgrade from bsdadminscripts (sysutils/bsdadminscripts). =46rom man page: DESCRIPTION The pkg_upgrade script allows the updating, installing and replacing of packages without using a local copy of the ports tree. Instead most required information is listed in an INDEX file that is kept in sync w= ith the package server by uma(1). I found it to be the best solution when still using packages on my laptop. Best regards Troels Kofoed Jacobsen From owner-freebsd-stable@FreeBSD.ORG Mon Jul 6 19:01:27 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 66C1A106566C for ; Mon, 6 Jul 2009 19:01:27 +0000 (UTC) (envelope-from ianjhart@ntlworld.com) Received: from mtaout02-winn.ispmail.ntl.com (mtaout02-winn.ispmail.ntl.com [81.103.221.48]) by mx1.freebsd.org (Postfix) with ESMTP id BC8378FC08 for ; Mon, 6 Jul 2009 19:01:26 +0000 (UTC) (envelope-from ianjhart@ntlworld.com) Received: from aamtaout03-winn.ispmail.ntl.com ([81.103.221.35]) by mtaout02-winn.ispmail.ntl.com (InterMail vM.7.08.04.00 201-2186-134-20080326) with ESMTP id <20090706190125.FCAI6611.mtaout02-winn.ispmail.ntl.com@aamtaout03-winn.ispmail.ntl.com> for ; Mon, 6 Jul 2009 20:01:25 +0100 Received: from cpc1-cove3-0-0-cust909.sol2.cable.ntl.com ([86.20.31.142]) by aamtaout03-winn.ispmail.ntl.com (InterMail vG.2.02.00.01 201-2161-120-102-20060912) with ESMTP id <20090706190124.ZCUC2093.aamtaout03-winn.ispmail.ntl.com@cpc1-cove3-0-0-cust909.sol2.cable.ntl.com> for ; Mon, 6 Jul 2009 20:01:24 +0100 X-Virus-Scanned: amavisd-new at cpc2-cove3-0-0-cust311.sol2.cable.ntl.com Received: from localhost (localhost [127.0.0.1]) by cpc1-cove3-0-0-cust909.sol2.cable.ntl.com (8.14.3/8.14.3) with ESMTP id n66J1F1x049923 for ; Mon, 6 Jul 2009 20:01:15 +0100 (BST) (envelope-from ianjhart@cpc1-cove3-0-0-cust909.sol2.cable.ntl.com) Received: from gamma.private.lan (gamma.private.lan [192.168.0.12]) by webmail.private.lan (Horde Framework) with HTTP; Mon, 06 Jul 2009 20:01:15 +0100 Message-ID: <20090706200115.1411150frxepkbuo@webmail.private.lan> Date: Mon, 06 Jul 2009 20:01:15 +0100 From: Ian J Hart To: freebsd-stable@freebsd.org References: <20090703100627.197838cphjnil82s@10.248.192.16> In-Reply-To: <20090703100627.197838cphjnil82s@10.248.192.16> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) 4.3.3 / FreeBSD-7.2 X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on cpc1-cove3-0-0-cust909.sol2.cable.ntl.com X-Cloudmark-Analysis: v=1.0 c=1 a=NLZqzBF-AAAA:8 a=AGjRiwtqXb2IeUPghGIA:9 a=iTknAmwptopIoBnpULMA:7 a=tqQ8obpP1drZus9jbdYxmCGPaT8A:4 a=_dQi-Dcv4p4A:10 a=HqeWOG4S6a4qnMPG:21 a=hM9huFWvRCncf8Rw:21 Subject: Re: trap 12 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 19:01:27 -0000 Quoting Ian J Hart : > Is this likely to be hardware? Details will follow if not. > > [copied from a screen dump] > > Fatal trap 12: page fault while in kernel mode > cpuid = 1; apic id = 01 > fault virtual address = 0x0 > fault code = supervisor write data, page not present > instruction pointer = 0x8:0xffffffff807c6c12 > stack pointer = 0x10:0xffffffff510e7890 > frame pointer = 0x10:0xffffff00054a6c90 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, long 1 def32 0, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 75372 (printf) > trap number = 12 > panic: page fault > cpuid = 1 > uptime: 8m2s > Cannot dump. No dump device defined. > > [First attempt apparently went into a blackhole. Apologies in you get this twice.] Some suggestions (off list) that it may not be hardware, so here's the follow up. supermicro 5015b-mt (super X7SBi mobo) Intel Q6600 8GB ECC DDR2 4x Seagate 320GB, two gmirror, two idle. issues so far 1 OK) 7.x doesn't boot without hw.ata.atapi_dma=0. Not recently tested. 2 OK) disks enumerate differently 6.x to 7.x. Painful if you hardwired the providor into your mirror. 3) 6.3 and 7.2 remote dump over ssh fails with 'Disconnecting: Corrupted MAC on input.' 4) On 7.2 (AFAICT from logs) random reboots under load. e.g. the above generated by a portupgrade run. I had dumpdev=none as I hadn't setup rc.early to allow savecore to work. In the interests of full disclosure I should say that this box was migrated from older hardware and then source upgraded from i386 to amd64 (6.3). Only one issue with that, format of accounting file.Upgrade to 7.2 and a rebuild or two since then. This box is our email server and there's no load. An identical box running as a gateway/firewall backup dumps okay and doesn't reboot. That box does drop network connections when running a cvsup server (treelist write), but when configured to pass through these connections (using balance) runs okay. But that's a story for another day as it's still on 6.x. Anyway, I put the two gmirror disks in another chassis and the remote dumps are now completing.This at least does seem to be hardware. Before I moved the two gmirror disks I synced a third disk. I can now test (most of) the original hardware and software. I was unable to make this single disk system crash, so I added two new disks and synced them.Now a 3 disk mirror, one disk idle. I've disabled sendmail and the email server so as not to clash. A portupgrade run caused a crash. I've setup coredumps so I can now test. Remote backup dumps do fail. xmail# kldstat Id Refs Address Size Name 1 2 0xffffffff80100000 bd23e0 kernel 2 1 0xffffffff80cd3000 20608 geom_mirror.ko I did have ipfw module loaded, but I got the crash without it so I've removed it (firewall_type=OPEN). Ran crashinfo, now have much more info than I need ;) Starting another portupgrade run now to see how reproducable this is. Later BIOS waiting in USB floppy. Copyright (c) 1992-2009 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 7.2-RELEASE-p1 #0: Tue Jun 16 18:03:10 BST 2009 mungethis@hostname:/usr/obj/usr/src/sys/GENERIC Preloaded elf kernel "/boot/kernel/kernel" at 0xffffffff80cf5000. Preloaded elf obj module "/boot/kernel/geom_mirror.ko" at 0xffffffff80cf5220. Calibrating clock(s) ... i8254 clock: 1193168 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 2394010944 Hz CPU: Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz (2394.01-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x6fb Stepping = 11 Features=0xbfebfbff Features2=0xe3bd AMD Features=0x20100800 AMD Features2=0x1 Cores per package: 4 usable memory = 8575127552 (8177 MB) Physical memory chunk(s): 0x0000000000001000 - 0x0000000000098fff, 622592 bytes (152 pages) 0x0000000000d27000 - 0x00000000cfe6ffff, 3474231296 bytes (848201 pages) 0x0000000100000000 - 0x000000021f8b3fff, 4824186880 bytes (1177780 pages) avail memory = 8273580032 (7890 MB) ACPI APIC Table: INTR: Adding local APIC 1 as a target INTR: Adding local APIC 2 as a target INTR: Adding local APIC 3 as a target FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 APIC: CPU 0 has ACPI ID 0 APIC: CPU 1 has ACPI ID 1 APIC: CPU 2 has ACPI ID 2 APIC: CPU 3 has ACPI ID 3 ULE: setup cpu group 0 ULE: setup cpu 0 ULE: adding cpu 0 to group 0: cpus 1 mask 0x1 ULE: setup cpu group 1 ULE: setup cpu 1 ULE: adding cpu 1 to group 1: cpus 1 mask 0x2 ULE: setup cpu group 2 ULE: setup cpu 2 ULE: adding cpu 2 to group 2: cpus 1 mask 0x4 ULE: setup cpu group 3 ULE: setup cpu 3 ULE: adding cpu 3 to group 3: cpus 1 mask 0x8 ACPI: RSDP @ 0x0xf69a0/0x0024 (v 2 PTLTD ) ACPI: XSDT @ 0x0xcfe77290/0x00A4 (v 1 PTLTD XSDT 0x06040000 LTP 0x00000000) ACPI: FACP @ 0x0xcfe80d60/0x00F4 (v 3 INTEL 0x06040000 PTL 0x00000002) ACPI: DSDT @ 0x0xcfe7a435/0x68B7 (v 1 INTEL BEARLAKE 0x06040000 MSFT 0x03000000) ACPI: FACS @ 0x0xcfe83fc0/0x0040 ACPI: _MAR @ 0x0xcfe80e54/0x0030 (v 1 Intel OEMDMAR 0x06040000 LOHR 0x00000001) ACPI: MCFG @ 0x0xcfe80e84/0x003C (v 1 PTLTD MCFG 0x06040000 LTP 0x00000000) ACPI: HPET @ 0x0xcfe80ec0/0x0038 (v 1 PTLTD HPETTBL 0x06040000 LTP 0x00000001) ACPI: APIC @ 0x0xcfe80ef8/0x0090 (v 1 PTLTD APIC 0x06040000 LTP 0x00000000) ACPI: BOOT @ 0x0xcfe80f88/0x0028 (v 1 PTLTD $SBFTBL$ 0x06040000 LTP 0x00000001) ACPI: SPCR @ 0x0xcfe80fb0/0x0050 (v 1 PTLTD $UCRTBL$ 0x06040000 PTL 0x00000001) ACPI: SSDT @ 0x0xcfe78ba7/0x025F (v 1 PmRef Cpu0Tst 0x00003000 INTL 0x20050228) ACPI: SSDT @ 0x0xcfe78b01/0x00A6 (v 1 PmRef Cpu7Tst 0x00003000 INTL 0x20050228) ACPI: SSDT @ 0x0xcfe78a5b/0x00A6 (v 1 PmRef Cpu6Tst 0x00003000 INTL 0x20050228) ACPI: SSDT @ 0x0xcfe789b5/0x00A6 (v 1 PmRef Cpu5Tst 0x00003000 INTL 0x20050228) ACPI: SSDT @ 0x0xcfe7890f/0x00A6 (v 1 PmRef Cpu4Tst 0x00003000 INTL 0x20050228) ACPI: SSDT @ 0x0xcfe78869/0x00A6 (v 1 PmRef Cpu3Tst 0x00003000 INTL 0x20050228) ACPI: SSDT @ 0x0xcfe787c3/0x00A6 (v 1 PmRef Cpu2Tst 0x00003000 INTL 0x20050228) ACPI: SSDT @ 0x0xcfe7871d/0x00A6 (v 1 PmRef Cpu1Tst 0x00003000 INTL 0x20050228) ACPI: SSDT @ 0x0xcfe77334/0x13E9 (v 1 PmRef CpuPm 0x00003000 INTL 0x20050228) MADT: Found IO APIC ID 4, Interrupt 0 at 0xfec00000 ioapic0: Routing external 8259A's -> intpin 0 MADT: Found IO APIC ID 5, Interrupt 24 at 0xfecc0000 lapic0: Routing NMI -> LINT1 lapic0: LINT1 trigger: edge lapic0: LINT1 polarity: high lapic1: Routing NMI -> LINT1 lapic1: LINT1 trigger: edge lapic1: LINT1 polarity: high lapic2: Routing NMI -> LINT1 lapic2: LINT1 trigger: edge lapic2: LINT1 polarity: high lapic3: Routing NMI -> LINT1 lapic3: LINT1 trigger: edge lapic3: LINT1 polarity: high MADT: Interrupt override: source 0, irq 2 ioapic0: Routing IRQ 0 -> intpin 2 MADT: Interrupt override: source 9, irq 9 ioapic0: intpin 9 trigger: level ioapic0 irqs 0-23 on motherboard ioapic1 irqs 24-47 on motherboard cpu0 BSP: ID: 0x00000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00000200 err: 0x00010000 pcm: 0x00010000 wlan_amrr: wlan: <802.11 Link Layer> null: random: nfslock: pseudo-device kbd: new array size 4 kbd1 at kbdmux0 mem: io: hptrr: RocketRAID 17xx/2xxx SATA controller driver v1.2 (Jun 16 2009 18:03:00) acpi0: on motherboard ioapic0: routing intpin 9 (ISA IRQ 9) to vector 48 acpi0: [MPSAFE] acpi0: [ITHREAD] acpi0: Power Button (fixed) AcpiOsDerivePciId: \\_SB_.PCI0.REGS -> bus 0 dev 0 func 0 AcpiOsDerivePciId: \\_SB_.PCI0.IGD0.IGDP -> bus 0 dev 2 func 0 AcpiOsDerivePciId: \\_SB_.PCI0.LPC0.REGS -> bus 0 dev 31 func 0 AcpiOsDerivePciId: \\_SB_.PCI0.LPC0.PIRX -> bus 0 dev 31 func 0 AcpiOsDerivePciId: \\_SB_.PCI0.LPC0.PIRY -> bus 0 dev 31 func 0 ACPI timer: 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 -> 10 Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 pci_link0: Index IRQ Rtd Ref IRQs Initial Probe 0 5 N 0 3 4 5 6 7 10 11 12 14 15 Validation 0 5 N 0 3 4 5 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link1: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 3 4 5 6 7 10 11 12 14 15 Validation 0 10 N 0 3 4 5 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link2: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 3 4 5 6 7 10 11 12 14 15 Validation 0 11 N 0 3 4 5 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link3: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 6 7 10 11 12 14 15 Validation 0 255 N 0 3 4 5 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link4: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 6 7 10 11 12 14 15 Validation 0 255 N 0 3 4 5 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link5: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 6 7 10 11 12 14 15 Validation 0 255 N 0 3 4 5 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link6: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 3 4 5 6 7 10 11 12 14 15 Validation 0 11 N 0 3 4 5 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link7: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 3 4 5 6 7 10 11 12 14 15 Validation 0 10 N 0 3 4 5 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 10 11 12 14 15 acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 acpi_hpet0: vend: 0x8086 rev: 0x1 num: 3 hz: 14318180 opts: legacy_route 64-bit Timecounter "HPET" frequency 14318180 Hz quality 900 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: domain=0, physical bus=0 found-> vendor=0x8086, dev=0x29f0, revid=0x01 domain=0, bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0106, statreg=0x2090, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x29f1, revid=0x01 domain=0, bus=0, slot=1, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0107, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) intpin=a, irq=5 powerspec 3 supports D0 D3 current D0 MSI supports 1 message pcib0: matched entry for 0.1.INTA pcib0: slot 1 INTA hardwired to IRQ 16 found-> vendor=0x8086, dev=0x2937, revid=0x02 domain=0, bus=0, slot=26, func=0 class=0c-03-00, hdrtype=0x00, mfdev=1 cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=5 map[20]: type I/O Port, range 32, base 0x1820, size 5, enabled pcib0: matched entry for 0.26.INTA pcib0: slot 26 INTA hardwired to IRQ 16 found-> vendor=0x8086, dev=0x2938, revid=0x02 domain=0, bus=0, slot=26, func=1 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=10 map[20]: type I/O Port, range 32, base 0x1840, size 5, enabled pcib0: matched entry for 0.26.INTB pcib0: slot 26 INTB hardwired to IRQ 17 found-> vendor=0x8086, dev=0x2939, revid=0x02 domain=0, bus=0, slot=26, func=2 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=11 map[20]: type I/O Port, range 32, base 0x1860, size 5, enabled pcib0: matched entry for 0.26.INTC pcib0: slot 26 INTC hardwired to IRQ 18 found-> vendor=0x8086, dev=0x293c, revid=0x02 domain=0, bus=0, slot=26, func=7 class=0c-03-20, hdrtype=0x00, mfdev=0 cmdreg=0x0106, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=11 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xd8601800, size 10, enabled pcib0: matched entry for 0.26.INTC pcib0: slot 26 INTC hardwired to IRQ 18 found-> vendor=0x8086, dev=0x2940, revid=0x02 domain=0, bus=0, slot=28, func=0 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0000, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x40 (16000 ns), maxlat=0x00 (0 ns) intpin=a, irq=5 powerspec 2 supports D0 D3 current D0 MSI supports 1 message pcib0: matched entry for 0.28.INTA pcib0: slot 28 INTA hardwired to IRQ 16 found-> vendor=0x8086, dev=0x2948, revid=0x02 domain=0, bus=0, slot=28, func=4 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0007, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) intpin=a, irq=5 powerspec 2 supports D0 D3 current D0 MSI supports 1 message pcib0: matched entry for 0.28.INTA pcib0: slot 28 INTA hardwired to IRQ 16 found-> vendor=0x8086, dev=0x294a, revid=0x02 domain=0, bus=0, slot=28, func=5 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0007, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) intpin=b, irq=10 powerspec 2 supports D0 D3 current D0 MSI supports 1 message pcib0: matched entry for 0.28.INTB pcib0: slot 28 INTB hardwired to IRQ 17 found-> vendor=0x8086, dev=0x2934, revid=0x02 domain=0, bus=0, slot=29, func=0 class=0c-03-00, hdrtype=0x00, mfdev=1 cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 map[20]: type I/O Port, range 32, base 0x1880, size 5, enabled pcib0: matched entry for 0.29.INTA pcib0: slot 29 INTA hardwired to IRQ 23 found-> vendor=0x8086, dev=0x2935, revid=0x02 domain=0, bus=0, slot=29, func=1 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=11 map[20]: type I/O Port, range 32, base 0x18a0, size 5, enabled pcib0: matched entry for 0.29.INTB pcib0: slot 29 INTB hardwired to IRQ 22 found-> vendor=0x8086, dev=0x2936, revid=0x02 domain=0, bus=0, slot=29, func=2 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=11 map[20]: type I/O Port, range 32, base 0x18c0, size 5, enabled pcib0: matched entry for 0.29.INTC pcib0: slot 29 INTC hardwired to IRQ 18 found-> vendor=0x8086, dev=0x293a, revid=0x02 domain=0, bus=0, slot=29, func=7 class=0c-03-20, hdrtype=0x00, mfdev=0 cmdreg=0x0106, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xd8601c00, size 10, enabled pcib0: matched entry for 0.29.INTA pcib0: slot 29 INTA hardwired to IRQ 23 found-> vendor=0x8086, dev=0x244e, revid=0x92 domain=0, bus=0, slot=30, func=0 class=06-04-01, hdrtype=0x01, mfdev=0 cmdreg=0x0107, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x0c (3000 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2916, revid=0x02 domain=0, bus=0, slot=31, func=0 class=06-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x0210, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2922, revid=0x02 domain=0, bus=0, slot=31, func=2 class=01-06-01, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x02b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=10 powerspec 3 supports D0 D3 current D0 MSI supports 16 messages map[10]: type I/O Port, range 32, base 0x1c50, size 3, enabled map[14]: type I/O Port, range 32, base 0x1c44, size 2, enabled map[18]: type I/O Port, range 32, base 0x1c48, size 3, enabled map[1c]: type I/O Port, range 32, base 0x1c40, size 2, enabled map[20]: type I/O Port, range 32, base 0x18e0, size 5, enabled map[24]: type Memory, range 32, base 0xd8601000, size 11, enabled pcib0: matched entry for 0.31.INTB pcib0: slot 31 INTB hardwired to IRQ 17 found-> vendor=0x8086, dev=0x2930, revid=0x02 domain=0, bus=0, slot=31, func=3 class=0c-05-00, hdrtype=0x00, mfdev=0 cmdreg=0x0001, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=10 map[10]: type Memory, range 64, base 0xd8602000, size 8, memory disabled map[20]: type I/O Port, range 32, base 0x1100, size 5, enabled pcib0: matched entry for 0.31.INTB pcib0: slot 31 INTB hardwired to IRQ 17 found-> vendor=0x8086, dev=0x2932, revid=0x02 domain=0, bus=0, slot=31, func=6 class=11-80-00, hdrtype=0x00, mfdev=0 cmdreg=0x0002, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=5 powerspec 3 supports D0 D3 current D0 map[10]: type Memory, range 64, base 0xd8600000, size 12, enabled pcib0: matched entry for 0.31.INTA pcib0: slot 31 INTA hardwired to IRQ 16 pcib1: irq 16 at device 1.0 on pci0 pcib1: domain 0 pcib1: secondary bus 1 pcib1: subordinate bus 2 pcib1: I/O decode 0xf000-0xfff pcib1: memory decode 0xd8100000-0xd81fffff pcib1: no prefetched decode pcib1: could not get PCI interrupt routing table for \\_SB_.PCI0.PEG_ - AE_NOT_FOUND pci1: on pcib1 pci1: domain=0, physical bus=1 found-> vendor=0x8086, dev=0x032c, revid=0x09 domain=0, bus=1, slot=0, func=0 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0107, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit found-> vendor=0x8086, dev=0x0326, revid=0x09 domain=0, bus=1, slot=0, func=1 class=08-00-20, hdrtype=0x00, mfdev=1 cmdreg=0x0106, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xd8100000, size 12, enabled pcib1: requested memory range 0xd8100000-0xd8100fff: good pcib2: at device 0.0 on pci1 pcib2: domain 0 pcib2: secondary bus 2 pcib2: subordinate bus 2 pcib2: I/O decode 0xf000-0xfff pcib2: no prefetched decode pci2: on pcib2 pci2: domain=0, physical bus=2 uhci0: port 0x1820-0x183f irq 16 at device 26.0 on pci0 uhci0: Reserved 0x20 bytes for rid 0x20 type 4 at 0x1820 ioapic0: routing intpin 16 (PCI IRQ 16) to vector 49 uhci0: [GIANT-LOCKED] uhci0: [ITHREAD] usb0: on uhci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 2 ports with 2 removable, self powered uhci1: port 0x1840-0x185f irq 17 at device 26.1 on pci0 uhci1: Reserved 0x20 bytes for rid 0x20 type 4 at 0x1840 ioapic0: routing intpin 17 (PCI IRQ 17) to vector 50 uhci1: [GIANT-LOCKED] uhci1: [ITHREAD] usb1: on uhci1 usb1: USB revision 1.0 uhub1: on usb1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0x1860-0x187f irq 18 at device 26.2 on pci0 uhci2: Reserved 0x20 bytes for rid 0x20 type 4 at 0x1860 ioapic0: routing intpin 18 (PCI IRQ 18) to vector 51 uhci2: [GIANT-LOCKED] uhci2: [ITHREAD] usb2: on uhci2 usb2: USB revision 1.0 uhub2: on usb2 uhub2: 2 ports with 2 removable, self powered ehci0: mem 0xd8601800-0xd8601bff irq 18 at device 26.7 on pci0 ehci0: Reserved 0x400 bytes for rid 0x10 type 3 at 0xd8601800 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb3: EHCI version 1.0 usb3: companion controllers, 2 ports each: usb0 usb1 usb2 usb3: on ehci0 usb3: USB revision 2.0 uhub3: on usb3 uhub3: 6 ports with 6 removable, self powered pcib3: irq 16 at device 28.0 on pci0 pcib3: domain 0 pcib3: secondary bus 5 pcib3: subordinate bus 5 pcib3: I/O decode 0x0-0x0 pcib3: no prefetched decode pci5: on pcib3 pci5: domain=0, physical bus=5 pcib4: irq 16 at device 28.4 on pci0 pcib4: domain 0 pcib4: secondary bus 13 pcib4: subordinate bus 13 pcib4: I/O decode 0x2000-0x2fff pcib4: memory decode 0xd8000000-0xd80fffff pcib4: no prefetched decode pci13: on pcib4 pci13: domain=0, physical bus=13 found-> vendor=0x8086, dev=0x108c, revid=0x03 domain=0, bus=13, slot=0, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0107, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=5 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 32, base 0xd8000000, size 17, enabled pcib4: requested memory range 0xd8000000-0xd801ffff: good map[18]: type I/O Port, range 32, base 0x2000, size 5, enabled pcib4: requested I/O range 0x2000-0x201f: in range pcib4: matched entry for 13.0.INTA pcib4: slot 0 INTA hardwired to IRQ 16 em0: port 0x2000-0x201f mem 0xd8000000-0xd801ffff irq 16 at device 0.0 on pci13 em0: Reserved 0x20000 bytes for rid 0x10 type 3 at 0xd8000000 em0: attempting to allocate 1 MSI vectors (1 supported) msi: routing MSI IRQ 256 to vector 52 em0: using IRQ 256 for MSI em0: Using MSI interrupt em0: [FILTER] em0: bpf attached em0: Ethernet address: 00:30:48:66:83:a0 pcib5: irq 17 at device 28.5 on pci0 pcib5: domain 0 pcib5: secondary bus 15 pcib5: subordinate bus 15 pcib5: I/O decode 0x3000-0x3fff pcib5: memory decode 0xd8200000-0xd82fffff pcib5: no prefetched decode pci15: on pcib5 pci15: domain=0, physical bus=15 found-> vendor=0x8086, dev=0x109a, revid=0x00 domain=0, bus=15, slot=0, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0107, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 32, base 0xd8200000, size 17, enabled pcib5: requested memory range 0xd8200000-0xd821ffff: good map[18]: type I/O Port, range 32, base 0x3000, size 5, enabled pcib5: requested I/O range 0x3000-0x301f: in range pcib5: matched entry for 15.0.INTA pcib5: slot 0 INTA hardwired to IRQ 17 em1: port 0x3000-0x301f mem 0xd8200000-0xd821ffff irq 17 at device 0.0 on pci15 em1: Reserved 0x20000 bytes for rid 0x10 type 3 at 0xd8200000 em1: attempting to allocate 1 MSI vectors (1 supported) msi: routing MSI IRQ 257 to vector 53 em1: using IRQ 257 for MSI em1: Using MSI interrupt em1: [FILTER] em1: bpf attached em1: Ethernet address: 00:30:48:66:83:a1 uhci3: port 0x1880-0x189f irq 23 at device 29.0 on pci0 uhci3: Reserved 0x20 bytes for rid 0x20 type 4 at 0x1880 ioapic0: routing intpin 23 (PCI IRQ 23) to vector 54 uhci3: [GIANT-LOCKED] uhci3: [ITHREAD] usb4: on uhci3 usb4: USB revision 1.0 uhub4: on usb4 uhub4: 2 ports with 2 removable, self powered uhci4: port 0x18a0-0x18bf irq 22 at device 29.1 on pci0 uhci4: Reserved 0x20 bytes for rid 0x20 type 4 at 0x18a0 ioapic0: routing intpin 22 (PCI IRQ 22) to vector 55 uhci4: [GIANT-LOCKED] uhci4: [ITHREAD] usb5: on uhci4 usb5: USB revision 1.0 uhub5: on usb5 uhub5: 2 ports with 2 removable, self powered uhci5: port 0x18c0-0x18df irq 18 at device 29.2 on pci0 uhci5: Reserved 0x20 bytes for rid 0x20 type 4 at 0x18c0 uhci5: [GIANT-LOCKED] uhci5: [ITHREAD] usb6: on uhci5 usb6: USB revision 1.0 uhub6: on usb6 uhub6: 2 ports with 2 removable, self powered ehci1: mem 0xd8601c00-0xd8601fff irq 23 at device 29.7 on pci0 ehci1: Reserved 0x400 bytes for rid 0x10 type 3 at 0xd8601c00 ehci1: [GIANT-LOCKED] ehci1: [ITHREAD] usb7: EHCI version 1.0 usb7: companion controllers, 2 ports each: usb4 usb5 usb6 usb7: on ehci1 usb7: USB revision 2.0 uhub7: on usb7 uhub7: 6 ports with 6 removable, self powered pcib6: at device 30.0 on pci0 pcib6: domain 0 pcib6: secondary bus 17 pcib6: subordinate bus 17 pcib6: I/O decode 0x4000-0x4fff pcib6: memory decode 0xd8300000-0xd83fffff pcib6: prefetched decode 0xd0000000-0xd7ffffff pcib6: Subtractively decoded bridge. pci17: on pcib6 pci17: domain=0, physical bus=17 found-> vendor=0x1002, dev=0x515e, revid=0x02 domain=0, bus=17, slot=3, func=0 class=03-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0187, statreg=0x0290, cachelnsz=8 (dwords) lattimer=0x42 (1980 ns), mingnt=0x08 (2000 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type Prefetchable Memory, range 32, base 0xd0000000, size 27, enabled pcib6: requested memory range 0xd0000000-0xd7ffffff: good map[14]: type I/O Port, range 32, base 0x4000, size 8, enabled pcib6: requested I/O range 0x4000-0x40ff: in range map[18]: type Memory, range 32, base 0xd8300000, size 16, enabled pcib6: requested memory range 0xd8300000-0xd830ffff: good pcib6: matched entry for 17.3.INTA pcib6: slot 3 INTA hardwired to IRQ 22 found-> vendor=0x1283, dev=0x8213, revid=0x00 domain=0, bus=17, slot=4, func=0 class=01-01-85, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0210, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x08 (2000 ns), maxlat=0x08 (2000 ns) intpin=a, irq=10 powerspec 2 supports D0 D3 current D0 map[10]: type I/O Port, range 32, base 0x4420, size 3, enabled pcib6: requested I/O range 0x4420-0x4427: in range map[14]: type I/O Port, range 32, base 0x4414, size 2, enabled pcib6: requested I/O range 0x4414-0x4417: in range map[18]: type I/O Port, range 32, base 0x4418, size 3, enabled pcib6: requested I/O range 0x4418-0x441f: in range map[1c]: type I/O Port, range 32, base 0x4410, size 2, enabled pcib6: requested I/O range 0x4410-0x4413: in range map[20]: type I/O Port, range 32, base 0x4400, size 4, enabled pcib6: requested I/O range 0x4400-0x440f: in range pcib6: matched entry for 17.4.INTA pcib6: slot 4 INTA hardwired to IRQ 23 vgapci0: port 0x4000-0x40ff mem 0xd0000000-0xd7ffffff,0xd8300000-0xd830ffff irq 22 at device 3.0 on pci17 atapci0: port 0x4420-0x4427,0x4414-0x4417,0x4418-0x441f,0x4410-0x4413,0x4400-0x440f irq 23 at device 4.0 on pci17 atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0x4400 atapci0: [MPSAFE] atapci0: [ITHREAD] ata2: on atapci0 atapci0: Reserved 0x8 bytes for rid 0x10 type 4 at 0x4420 atapci0: Reserved 0x4 bytes for rid 0x14 type 4 at 0x4414 ata2: reset tp1 mask=03 ostat0=60 ostat1=50 ata2: stat0=0x20 err=0x20 lsb=0x20 msb=0x20 ata2: stat1=0x00 err=0x01 lsb=0x14 msb=0xeb ata2: reset tp2 stat0=20 stat1=00 devices=0x8 ata2: [MPSAFE] ata2: [ITHREAD] isab0: at device 31.0 on pci0 isa0: on isab0 atapci1: port 0x1c50-0x1c57,0x1c44-0x1c47,0x1c48-0x1c4f,0x1c40-0x1c43,0x18e0-0x18ff mem 0xd8601000-0xd86017ff irq 17 at device 31.2 on pci0 atapci1: Reserved 0x20 bytes for rid 0x20 type 4 at 0x18e0 atapci1: Reserved 0x800 bytes for rid 0x24 type 3 at 0xd8601000 atapci1: [MPSAFE] atapci1: [ITHREAD] atapci1: AHCI Version 01.20 controller with 6 ports detected ata3: on atapci1 ata3: SATA connect time=0ms ata3: SIGNATURE: 00000101 ata3: ahci_reset devices=0x1 ata3: [MPSAFE] ata3: [ITHREAD] ata4: on atapci1 ata4: SATA connect time=0ms ata4: SIGNATURE: 00000101 ata4: ahci_reset devices=0x1 ata4: [MPSAFE] ata4: [ITHREAD] ata5: on atapci1 ata5: SATA connect time=0ms ata5: SIGNATURE: 00000101 ata5: ahci_reset devices=0x1 ata5: [MPSAFE] ata5: [ITHREAD] ata6: on atapci1 ata6: SATA connect time=0ms ata6: SIGNATURE: 00000101 ata6: ahci_reset devices=0x1 ata6: [MPSAFE] ata6: [ITHREAD] ata7: on atapci1 ata7: port not implemented ata7: [MPSAFE] ata7: [ITHREAD] ata8: on atapci1 ata8: port not implemented ata8: [MPSAFE] ata8: [ITHREAD] pci0: at device 31.3 (no driver attached) pci0: at device 31.6 (no driver attached) acpi_button0: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0047 atkbd: keyboard ID 0x41ab (2) kbd0 at atkbd0 kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 ioapic0: routing intpin 1 (ISA IRQ 1) to vector 56 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: unable to allocate IRQ psmcpnp0: irq 12 on acpi0 psm0: current command byte:0047 psm0: irq 12 on atkbdc0 ioapic0: routing intpin 12 (ISA IRQ 12) to vector 57 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model IntelliMouse Explorer, device ID 4-00, 5 buttons psm0: config:00000000, flags:00000008, packet size:4 psm0: syncmask:08, syncbits:00 sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: irq maps: 0 0 0 0 sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: irq maps: 0 0 0 0 sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A ioapic0: routing intpin 4 (ISA IRQ 4) to vector 58 sio0: [FILTER] sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled sio1: irq maps: 0 0 0 0 sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled sio1: irq maps: 0 0 0 0 sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A ioapic0: routing intpin 3 (ISA IRQ 3) to vector 59 sio1: [FILTER] fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: ic_type 90 part_id 80 ioapic0: routing intpin 6 (ISA IRQ 6) to vector 60 fdc0: [FILTER] ppc0: using extended I/O port range ppc0: ECP SPP ECP+EPP SPP ppc0: port 0x378-0x37f,0x778-0x77f irq 7 drq 3 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/9 bytes threshold ppbus0: on ppc0 ioapic0: routing intpin 7 (ISA IRQ 7) to vector 61 ppbus0: [MPSAFE] ppbus0: [ITHREAD] plip0: on ppbus0 plip0: WARNING: using obsoleted IFF_NEEDSGIANT flag plip0: bpf attached lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 ppc0: [GIANT-LOCKED] ppc0: [ITHREAD] cpu0: on acpi0 ACPI: SSDT @ 0x0xcfe78e06/0x01DD (v 1 PmRef Cpu0Ist 0x00003000 INTL 0x20050228) cpu0: switching to generic Cx mode est0: on cpu0 est0: Invalid id16 (set, cur) = (1563, 2344) est0: Invalid freq 1600, ignored. p4tcc0: on cpu0 cpu1: on acpi0 ACPI: SSDT @ 0x0xcfe78fe3/0x016E (v 1 PmRef Cpu1Ist 0x00003000 INTL 0x20050228) est1: on cpu1 est1: Invalid id16 (set, cur) = (1563, 2344) est1: Invalid freq 1600, ignored. p4tcc1: on cpu1 cpu2: on acpi0 ACPI: SSDT @ 0x0xcfe79151/0x016E (v 1 PmRef Cpu2Ist 0x00003000 INTL 0x20050228) est2: on cpu2 est2: Invalid id16 (set, cur) = (1563, 2344) est2: Invalid freq 1600, ignored. p4tcc2: on cpu2 cpu3: on acpi0 ACPI: SSDT @ 0x0xcfe792bf/0x016E (v 1 PmRef Cpu3Ist 0x00003000 INTL 0x20050228) est3: on cpu3 est3: Invalid id16 (set, cur) = (1563, 2344) est3: Invalid freq 1600, ignored. p4tcc3: on cpu3 ex_isa_identify() atkbdc: atkbdc0 already exists; skipping it fdc: fdc0 already exists; skipping it ppc: ppc0 already exists; skipping it sio: sio0 already exists; skipping it sio: sio1 already exists; skipping it ahc_isa_probe 1: ioport 0x1c00 alloc failed sc: sc0 already exists; skipping it vga: vga0 already exists; skipping it isa_probe_children: disabling PnP devices isa_probe_children: probing non-PnP devices orm0: at iomem 0xc0000-0xcafff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sc0: fb0, kbd1, terminal emulator: sc (syscons terminal) sio2: not probed (disabled) sio3: not probed (disabled) vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 isa_probe_children: probing PnP devices umass0: on uhub0 umass0:0:0:-1: Attached to scbus0 Device configuration finished. Reducing kern.maxvnodes 343811 -> 100000 procfs registered lapic: Divisor 2, Frequency 133000612 hz Timecounter "TSC" frequency 2394010944 Hz quality -100 Timecounters tick every 1.000 msec lo0: bpf attached hptrr: no controller detected. ata2-slave: pio=PIO4 wdma=WDMA2 udma=UDMA33 cable=80 wire acd0: setting PIO4 on IT8213F chip acd0: DVDROM drive at ata2 as slave acd0: read 4134KB/s (4134KB/s), 2048KB buffer, PIO4 acd0: Reads: CDR, CDRW, CDDA stream, DVDROM, DVDR, DVDRAM, packet acd0: Writes: acd0: Audio: play, 256 volume levels acd0: Mechanism: ejectable tray, unlocked acd0: Medium: CD-R 120mm data disc ata3-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire ad6: 305245MB at ata3-master SATA300 ad6: 625142448 sectors [620181C/16H/63S] 16 sectors/interrupt 1 depth queue ad6: Intel check1 failed ad6: Adaptec check1 failed ad6: LSI (v3) check1 failed ad6: LSI (v2) check1 failed ad6: FreeBSD check1 failed ata4-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire ad8: 305245MB at ata4-master SATA300 ad8: 625142448 sectors [620181C/16H/63S] 16 sectors/interrupt 1 depth queue ad8: Intel check1 failed ad8: Adaptec check1 failed ad8: LSI (v3) check1 failed ad8: LSI (v2) check1 failed ad8: FreeBSD check1 failed ata5-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire ad10: 305245MB at ata5-master SATA300 ad10: 625142448 sectors [620181C/16H/63S] 16 sectors/interrupt 1 depth queue ad10: Intel check1 failed ad10: Adaptec check1 failed ad10: LSI (v3) check1 failed ad10: LSI (v2) check1 failed ad10: FreeBSD check1 failed ata6-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire ad12: 305245MB at ata6-master SATA300 ad12: 625142448 sectors [620181C/16H/63S] 16 sectors/interrupt 1 depth queue ad12: Intel check1 failed ad12: Adaptec check1 failed ad12: LSI (v3) check1 failed ad12: LSI (v2) check1 failed ad12: FreeBSD check1 failed (probe0:umass-sim0:0:0:0): Down reving Protocol Version from 2 to 0? acd0: FAILURE - READ_BIG ILLEGAL REQUEST asc=0x64 ascq=0x00 (probe0:umass-sim0:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 (probe0:umass-sim0:0:0:0): CAM Status: SCSI Status Error (probe0:umass-sim0:0:0:0): SCSI Status: Check Condition (probe0:umass-sim0:0:0:0): UNIT ATTENTION asc:28,0 (probe0:umass-sim0:0:0:0): Not ready to ready change, medium may have changed (probe0:umass-sim0:0:0:0): (probe0:umass-sim0:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 (probe0:umass-sim0:0:0:0): UNIT ATTENTION asc:28,0 (probe0:umass-sim0:0:0:0): Not ready to ready change, medium may have changed Retrying Command (per Sense Data) (probe0:umass-sim0:0:0:0): Retrying Command pass0 at umass-sim0 bus 0 target 0 lun 0 pass0: Removable Direct Access SCSI-0 device pass0: 20KB/s transfers ATA PseudoRAID loaded SMP: AP CPU #1 Launched! cpu1 AP: ID: 0x01000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000200ef therm: 0x00010000 err: 0x00010000 pcm: 0x00010000 SMP: AP CPU #3 Launched! cpu3 AP: ID: 0x03000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000200ef therm: 0x00010000 err: 0x00010000 pcm: 0x00010000 SMP: AP CPU #2 Launched! cpu2 AP: ID: 0x02000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000200ef therm: 0x00010000 err: 0x00010000 pcm: 0x00010000 ioapic0: Assigning ISA IRQ 1 to local APIC 0 ioapic0: Assigning ISA IRQ 3 to local APIC 1 ioapic0: Assigning ISA IRQ 4 to local APIC 2 ioapic0: Assigning ISA IRQ 6 to local APIC 3 ioapic0: Assigning ISA IRQ 7 to local APIC 0 ioapic0: Assigning ISA IRQ 9 to local APIC 1 ioapic0: Assigning ISA IRQ 12 to local APIC 2 ioapic0: Assigning PCI IRQ 16 to local APIC 3 ioapic0: Assigning PCI IRQ 17 to local APIC 0 ioapic0: Assigning PCI IRQ 18 to local APIC 1 ioapic0: Assigning PCI IRQ 22 to local APIC 2 ioapic0: Assigning PCI IRQ 23 to local APIC 3 msi: Assigning MSI IRQ 256 to local APIC 0 msi: Assigning MSI IRQ 257 to local APIC 1 da0 at umass-sim0 bus 0 target 0 lun 0 da0: Removable Direct Access SCSI-0 device da0: 20KB/s transfers da0: 1MB (2880 512 byte sectors: 64H 32S/T 1C) acd0: FAILURE - READ_BIG ILLEGAL REQUEST asc=0x64 ascq=0x00 GEOM_LABEL: Label for provider acd0 is iso9660/FreeBSD_Install. GEOM: new disk ad6 acd0: FAILURE - READ_BIG ILLEGAL REQUEST asc=0x64 ascq=0x00 acd0: FAILURE - READ_BIG ILLEGAL REQUEST asc=0x64 ascq=0x00 GEOM: new disk ad8 GEOM: new disk ad10 GEOM: new disk ad12 GEOM: new disk da0 acd0: FAILURE - READ_BIG ILLEGAL REQUEST asc=0x64 ascq=0x00 GEOM_MIRROR: Device mirror/gm0 launched (3/3). GEOM_LABEL: Label for provider ad12s1 is ufsid/488efb68e5c53bb1. GEOM_LABEL: Label for provider mirror/gm0s1a is ufsid/489cb5723873a365. GEOM_LABEL: Label for provider mirror/gm0s1d is ufsid/489cb5806d417263. GEOM_LABEL: Label for provider mirror/gm0s1e is ufsid/489cb5847a0f8baa. GEOM_LABEL: Label for provider mirror/gm0s1f is ufsid/489cb58839896589. GEOM_LABEL: Label for provider mirror/gm0s1g is ufsid/489cb58c07734311. Trying to mount root from ufs:/dev/mirror/gm0s1a start_init: trying /sbin/init GEOM_LABEL: Label ufsid/489cb5723873a365 removed. GEOM_LABEL: Label for provider mirror/gm0s1a is ufsid/489cb5723873a365. GEOM_LABEL: Label ufsid/489cb5806d417263 removed. GEOM_LABEL: Label for provider mirror/gm0s1d is ufsid/489cb5806d417263. GEOM_LABEL: Label ufsid/489cb5847a0f8baa removed. GEOM_LABEL: Label for provider mirror/gm0s1e is ufsid/489cb5847a0f8baa. GEOM_LABEL: Label ufsid/489cb58839896589 removed. GEOM_LABEL: Label for provider mirror/gm0s1f is ufsid/489cb58839896589. GEOM_LABEL: Label ufsid/489cb58c07734311 removed. GEOM_LABEL: Label for provider mirror/gm0s1g is ufsid/489cb58c07734311. GEOM_LABEL: Label ufsid/489cb5723873a365 removed. GEOM_LABEL: Label ufsid/489cb5806d417263 removed. GEOM_LABEL: Label ufsid/489cb5847a0f8baa removed. GEOM_LABEL: Label ufsid/489cb58839896589 removed. GEOM_LABEL: Label ufsid/489cb58c07734311 removed. em1: Link is up 1000 Mbps Full Duplex em0: Link is up 1000 Mbps Full Duplex em0: link state changed to UP -- ian j hart ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From owner-freebsd-stable@FreeBSD.ORG Mon Jul 6 19:10:34 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 86293106564A for ; Mon, 6 Jul 2009 19:10:34 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.9.129]) by mx1.freebsd.org (Postfix) with ESMTP id 4BDAF8FC19 for ; Mon, 6 Jul 2009 19:10:33 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id D5E4D73098; Mon, 6 Jul 2009 21:16:17 +0200 (CEST) Date: Mon, 6 Jul 2009 21:16:17 +0200 From: Luigi Rizzo To: Bruce Simpson Message-ID: <20090706191617.GC35071@onelab2.iet.unipi.it> References: <4A520A69.4010000@incunabulum.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A520A69.4010000@incunabulum.net> User-Agent: Mutt/1.4.2.3i Cc: freebsd-stable Subject: Re: Merging a GCC bug fix to RELENG_7 - how? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 19:10:34 -0000 On Mon, Jul 06, 2009 at 03:30:01PM +0100, Bruce Simpson wrote: > Hi all, > > This GCC bug bites us in the Boost regression tests in a number of places. > > Uh oh, I've stepped on the one-line fix bomb: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31899 > http://gcc.gnu.org/viewcvs?view=rev&revision=129199 > > What's funny is that COPYING in the root of that branch is GPLv2, but > the affected file's license is GPLv3. > > So what on earth do we do? the whole change is one line - gcc_unreachable (); + return *tp; and according to the dates bugzilla and the repository, when the patch was submitted the file was still marked as GPLv2. So I would think that taking the v2 file and the v2 patch still makes a v2 file, doesn't it ? cheers luigi From owner-freebsd-stable@FreeBSD.ORG Mon Jul 6 19:37:00 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8FDF21065672 for ; Mon, 6 Jul 2009 19:37:00 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (skuns.zoral.com.ua [91.193.166.194]) by mx1.freebsd.org (Postfix) with ESMTP id 2734A8FC08 for ; Mon, 6 Jul 2009 19:36:59 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id n66Jasc3042519 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 6 Jul 2009 22:36:54 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3) with ESMTP id n66Jas25099531; Mon, 6 Jul 2009 22:36:54 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3/Submit) id n66JarEm099530; Mon, 6 Jul 2009 22:36:53 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 6 Jul 2009 22:36:53 +0300 From: Kostik Belousov To: "Marat N.Afanasyev" Message-ID: <20090706193653.GU2884@deviant.kiev.zoral.com.ua> References: <4A50E947.9020608@ksu.ru> <4A523518.7050008@gmx.de> <4A523849.1070001@ksu.ru> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="VoIY86CJP7r500ch" Content-Disposition: inline In-Reply-To: <4A523849.1070001@ksu.ru> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: Ralf Folkerts , FreeBSD-STABLE Mailing List Subject: Re: bug in ufs? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 19:37:00 -0000 --VoIY86CJP7r500ch Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jul 06, 2009 at 09:45:45PM +0400, Marat N.Afanasyev wrote: > Ralf Folkerts wrote: > >Marat N.Afanasyev wrote: > >>hello! > >> > >>i have a strange problem with writing data to my ufs2+su filesystem. > >> > >>1. i made a 1T gpt partition on my storage server, and formatted it: > >>newfs -U -m 0 -o time -i 32768 /dev/da1p3a > >> > >>2. i tried to move data from other servers to this filesystem, total=20 > >>size of files is slightly less than 1T > >> > >>3. i encountered a 'No space left on device' while i still have 11G of= =20 > >>free space and about 13 million free inodes on the filesystem: > >> > >>#df -ih > >>Filesystem Size Used Avail Capacity iused ifree %iused=20 > >>Mounted on > >>/dev/da1p3a 1.0T 1.0T 11G 99% 20397465 13363173 60%=20 > >>/mnt/45_114 > >> > >>all i want to know is whether this is a bug or a feature? and if such= =20 > >>a behavior is well-known, where can i read about it? > >Hi Marat, > > > >just a guess: Are there sparse Files on the Source System that are not= =20 > >being detected by the Tool you used to restore the data? If you used=20 > >(bsd)tar, did you try -S? > > > >A while ago I ran into a similar Problem when copying=20 > >Oracle-Database-Files (on Linux, though) and the -S - Option came to=20 > >rescue. > > > >Cheers, > >_ralf_ >=20 > i have a huge amount of small files on the source systems, as you can=20 > see they have about 20 million files and almost each of them is jpeg or= =20 > gif. afaik, there are no sparse files at all. >=20 > i still cannot figure out what is it: a free space leak in ufs2+su or=20 > bug in statfs(3), that is used in df, or something else. My guess that it is due to fragmentation. As an experiment, try to create 1-byte file. Does it work on the filesystem in described state ? --VoIY86CJP7r500ch Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkpSUlUACgkQC3+MBN1Mb4imfACgyipDroKAZqEOVqeScX9cAVBt SooAoMLtKu5no0wCmBc3EPd4G/0C94Io =Xlq2 -----END PGP SIGNATURE----- --VoIY86CJP7r500ch-- From owner-freebsd-stable@FreeBSD.ORG Mon Jul 6 19:54:51 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0D5711065674 for ; Mon, 6 Jul 2009 19:54:51 +0000 (UTC) (envelope-from marck@rinet.ru) Received: from woozle.rinet.ru (woozle.rinet.ru [195.54.192.68]) by mx1.freebsd.org (Postfix) with ESMTP id 68A308FC0A for ; Mon, 6 Jul 2009 19:54:50 +0000 (UTC) (envelope-from marck@rinet.ru) Received: from localhost (localhost [127.0.0.1]) by woozle.rinet.ru (8.14.3/8.14.3) with ESMTP id n66JsmBx005899; Mon, 6 Jul 2009 23:54:49 +0400 (MSD) (envelope-from marck@rinet.ru) Date: Mon, 6 Jul 2009 23:54:48 +0400 (MSD) From: Dmitry Morozovsky To: Kostik Belousov In-Reply-To: <20090706193653.GU2884@deviant.kiev.zoral.com.ua> Message-ID: References: <4A50E947.9020608@ksu.ru> <4A523518.7050008@gmx.de> <4A523849.1070001@ksu.ru> <20090706193653.GU2884@deviant.kiev.zoral.com.ua> 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.2.2 (woozle.rinet.ru [0.0.0.0]); Mon, 06 Jul 2009 23:54:49 +0400 (MSD) Cc: Ralf Folkerts , "Marat N.Afanasyev" , FreeBSD-STABLE Mailing List Subject: Re: bug in ufs? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 19:54:51 -0000 On Mon, 6 Jul 2009, Kostik Belousov wrote: KB> > >>i have a strange problem with writing data to my ufs2+su filesystem. KB> > >> KB> > >>1. i made a 1T gpt partition on my storage server, and formatted it: KB> > >>newfs -U -m 0 -o time -i 32768 /dev/da1p3a KB> > >> KB> > >>2. i tried to move data from other servers to this filesystem, total KB> > >>size of files is slightly less than 1T KB> > >> KB> > >>3. i encountered a 'No space left on device' while i still have 11G of KB> > >>free space and about 13 million free inodes on the filesystem: KB> > >> KB> > >>#df -ih KB> > >>Filesystem Size Used Avail Capacity iused ifree %iused KB> > >>Mounted on KB> > >>/dev/da1p3a 1.0T 1.0T 11G 99% 20397465 13363173 60% KB> > >>/mnt/45_114 KB> > >> KB> > >>all i want to know is whether this is a bug or a feature? and if such KB> > >>a behavior is well-known, where can i read about it? KB> > >Hi Marat, KB> > > KB> > >just a guess: Are there sparse Files on the Source System that are not KB> > >being detected by the Tool you used to restore the data? If you used KB> > >(bsd)tar, did you try -S? KB> > > KB> > >A while ago I ran into a similar Problem when copying KB> > >Oracle-Database-Files (on Linux, though) and the -S - Option came to KB> > >rescue. KB> > > KB> > >Cheers, KB> > >_ralf_ KB> > KB> > i have a huge amount of small files on the source systems, as you can KB> > see they have about 20 million files and almost each of them is jpeg or KB> > gif. afaik, there are no sparse files at all. KB> > KB> > i still cannot figure out what is it: a free space leak in ufs2+su or KB> > bug in statfs(3), that is used in df, or something else. KB> KB> My guess that it is due to fragmentation. KB> As an experiment, try to create 1-byte file. Does it work on the filesystem KB> in described state ? Doesn't UFS store one-byte (or several-bytes, like PID file) file entirely in the inode, not consuming any data blocks? -- 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 Mon Jul 6 20:01:16 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D7F87106567A for ; Mon, 6 Jul 2009 20:01:16 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (skuns.zoral.com.ua [91.193.166.194]) by mx1.freebsd.org (Postfix) with ESMTP id 715E38FC18 for ; Mon, 6 Jul 2009 20:01:16 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id n66K1B7D043935 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 6 Jul 2009 23:01:11 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3) with ESMTP id n66K1AZn099917; Mon, 6 Jul 2009 23:01:10 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3/Submit) id n66K1ABI099916; Mon, 6 Jul 2009 23:01:10 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 6 Jul 2009 23:01:10 +0300 From: Kostik Belousov To: Dmitry Morozovsky Message-ID: <20090706200110.GX2884@deviant.kiev.zoral.com.ua> References: <4A50E947.9020608@ksu.ru> <4A523518.7050008@gmx.de> <4A523849.1070001@ksu.ru> <20090706193653.GU2884@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="7aBBD6ClYIPKzb+y" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: Ralf Folkerts , "Marat N.Afanasyev" , FreeBSD-STABLE Mailing List Subject: Re: bug in ufs? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 20:01:17 -0000 --7aBBD6ClYIPKzb+y Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jul 06, 2009 at 11:54:48PM +0400, Dmitry Morozovsky wrote: > On Mon, 6 Jul 2009, Kostik Belousov wrote: >=20 > KB> > >>i have a strange problem with writing data to my ufs2+su filesyst= em. > KB> > >> > KB> > >>1. i made a 1T gpt partition on my storage server, and formatted = it: > KB> > >>newfs -U -m 0 -o time -i 32768 /dev/da1p3a > KB> > >> > KB> > >>2. i tried to move data from other servers to this filesystem, to= tal=20 > KB> > >>size of files is slightly less than 1T > KB> > >> > KB> > >>3. i encountered a 'No space left on device' while i still have 1= 1G of=20 > KB> > >>free space and about 13 million free inodes on the filesystem: > KB> > >> > KB> > >>#df -ih > KB> > >>Filesystem Size Used Avail Capacity iused ifree %ius= ed=20 > KB> > >>Mounted on > KB> > >>/dev/da1p3a 1.0T 1.0T 11G 99% 20397465 13363173 60= %=20 > KB> > >>/mnt/45_114 > KB> > >> > KB> > >>all i want to know is whether this is a bug or a feature? and if = such=20 > KB> > >>a behavior is well-known, where can i read about it? > KB> > >Hi Marat, > KB> > > > KB> > >just a guess: Are there sparse Files on the Source System that are= not=20 > KB> > >being detected by the Tool you used to restore the data? If you us= ed=20 > KB> > >(bsd)tar, did you try -S? > KB> > > > KB> > >A while ago I ran into a similar Problem when copying=20 > KB> > >Oracle-Database-Files (on Linux, though) and the -S - Option came = to=20 > KB> > >rescue. > KB> > > > KB> > >Cheers, > KB> > >_ralf_ > KB> >=20 > KB> > i have a huge amount of small files on the source systems, as you c= an=20 > KB> > see they have about 20 million files and almost each of them is jpe= g or=20 > KB> > gif. afaik, there are no sparse files at all. > KB> >=20 > KB> > i still cannot figure out what is it: a free space leak in ufs2+su = or=20 > KB> > bug in statfs(3), that is used in df, or something else. > KB>=20 > KB> My guess that it is due to fragmentation. > KB> As an experiment, try to create 1-byte file. Does it work on the file= system > KB> in described state ? >=20 > Doesn't UFS store one-byte (or several-bytes, like PID file) file entirel= y in=20 > the inode, not consuming any data blocks? No, 1-byte file is stored in fragment. Long write tries to allocate whole block. This is why I wrote about fragmentation. Answering your question, it is short symlinks that are stored in inode in the data block pointers. --7aBBD6ClYIPKzb+y Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkpSWAYACgkQC3+MBN1Mb4gtNQCgsI5MyodW0usa9NS3sjb/EGbw q8wAoJDnyBexdckyU3u4g8HKUej+ShFz =K+wz -----END PGP SIGNATURE----- --7aBBD6ClYIPKzb+y-- From owner-freebsd-stable@FreeBSD.ORG Mon Jul 6 20:16:27 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5C0CA1065676 for ; Mon, 6 Jul 2009 20:16:27 +0000 (UTC) (envelope-from amarat@ksu.ru) Received: from mx.kzn.ru (mx.kzn.ru [194.85.243.38]) by mx1.freebsd.org (Postfix) with ESMTP id 574B08FC18 for ; Mon, 6 Jul 2009 20:16:25 +0000 (UTC) (envelope-from amarat@ksu.ru) Authentication-Results: iout.kzn.ru; dkim=neutral (message not signed) header.i=none Received-SPF: None identity=pra; client-ip=193.232.252.56; receiver=iout.kzn.ru; envelope-from="amarat@ksu.ru"; x-sender="amarat@ksu.ru"; x-conformance=sidf_compatible Received-SPF: None identity=mailfrom; client-ip=193.232.252.56; receiver=iout.kzn.ru; envelope-from="amarat@ksu.ru"; x-sender="amarat@ksu.ru"; x-conformance=sidf_compatible Received-SPF: None identity=helo; client-ip=193.232.252.56; receiver=iout.kzn.ru; envelope-from="amarat@ksu.ru"; x-sender="postmaster@ruby.ksu.ru"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aq4EACP4UUrCVfWh/2dsb2JhbACBUc02gnaBHAWBOg X-IronPort-AV: E=Sophos;i="4.42,358,1243800000"; d="p7s'?scan'208";a="4201244" Received: from mail.ksu.ru (HELO ruby.ksu.ru) ([193.232.252.56]) by iout.kzn.ru with ESMTP; 07 Jul 2009 00:16:23 +0400 X-Pass-Through: Kazan State University Network Received: from zealot.ksu.ru ([194.85.245.161]) by ksu.ru (8.13.4/8.13.4) with ESMTP id n66JNPon011429; Mon, 6 Jul 2009 19:23:25 GMT Received: from zealot.ksu.ru (localhost.lnet [127.0.0.1]) by zealot.ksu.ru (8.14.3/8.14.3) with ESMTP id n66KFkK1054126; Tue, 7 Jul 2009 00:15:47 +0400 (MSD) (envelope-from amarat@ksu.ru) Message-ID: <4A525B72.1010808@ksu.ru> Date: Tue, 07 Jul 2009 00:15:46 +0400 From: "Marat N.Afanasyev" User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.8.1.22) Gecko/20090704 SeaMonkey/1.1.17 MIME-Version: 1.0 To: Kostik Belousov References: <4A50E947.9020608@ksu.ru> <4A523518.7050008@gmx.de> <4A523849.1070001@ksu.ru> <20090706193653.GU2884@deviant.kiev.zoral.com.ua> In-Reply-To: <20090706193653.GU2884@deviant.kiev.zoral.com.ua> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000003020409070406060704" Cc: Ralf Folkerts , FreeBSD-STABLE Mailing List Subject: Re: bug in ufs? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 20:16:28 -0000 This is a cryptographically signed message in MIME format. --------------ms000003020409070406060704 Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Kostik Belousov wrote: > On Mon, Jul 06, 2009 at 09:45:45PM +0400, Marat N.Afanasyev wrote: >> i have a huge amount of small files on the source systems, as you can >> see they have about 20 million files and almost each of them is jpeg or >> gif. afaik, there are no sparse files at all. >> >> i still cannot figure out what is it: a free space leak in ufs2+su or >> bug in statfs(3), that is used in df, or something else. > > My guess that it is due to fragmentation. > As an experiment, try to create 1-byte file. Does it work on the filesystem > in described state ? I can create small files, as many as i have patience, maximum size of such "small file" is 14336, so. it seems that if file is no greater than (block_size-2048) it can be created. larger file cannot be created. imho, fragmentation on filesystem should be very low, there were no deletions on it, just creations. -- SY, Marat --------------ms000003020409070406060704 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII8zCC AtQwggI9oAMCAQICEHpsMo6nkbUVegxjAzzxYCkwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDQwMTE5MTUxOFoX DTEwMDQwMTE5MTUxOFowPzEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEcMBoG CSqGSIb3DQEJARYNYW1hcmF0QGtzdS5ydTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALqa7MfgjbsxmgpTOKxAN7w+cFViFA8NrULAARwVQJQJCnVRGf3i97EwNdLE8VTNniU4 ybS4gtLsy9gfNuuyPV2AJESpgrxaG+KZyHu1f6P4e31YBbnbtWVTUxZ3U/vWoL+BOAOI4S84 Cx834a4uYK75WhpZKd56qet5loyn9N1wBZNgCh9AwU31lA/Q0iCSKpEIxuhbElNXHNnqAlts CtNXsKgsT8mP7QI52h0cBOPSZqvz++e/wruJGgKeCECqo8ftwwya3CYkH1lhH2Q1zeXwez1E 1+solM48odH+odn29ctmOqr3PzZfmBJyGFf5FagTKNia/ys48yBtVU/RXHsCAwEAAaMqMCgw GAYDVR0RBBEwD4ENYW1hcmF0QGtzdS5ydTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUA A4GBAG4Pj7KRSJ/M28KNynJOPCHg26L15S9OfQ+ckMaPPDRAejtdlUdCgkoyD9d1Du/amAk6 A3NcY2I/MsFW2vSonQfU+7cJZiyuhfw7wQlOovCx7USw1dmF6u3EljWZV+Kg4Vi3vN2dPyJx tv8li9McWQoMLmm5zzFGGRaSRnnrnZFsMIIC1DCCAj2gAwIBAgIQemwyjqeRtRV6DGMDPPFg KTANBgkqhkiG9w0BAQUFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1 bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElz c3VpbmcgQ0EwHhcNMDkwNDAxMTkxNTE4WhcNMTAwNDAxMTkxNTE4WjA/MR8wHQYDVQQDExZU aGF3dGUgRnJlZW1haWwgTWVtYmVyMRwwGgYJKoZIhvcNAQkBFg1hbWFyYXRAa3N1LnJ1MIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuprsx+CNuzGaClM4rEA3vD5wVWIUDw2t QsABHBVAlAkKdVEZ/eL3sTA10sTxVM2eJTjJtLiC0uzL2B8267I9XYAkRKmCvFob4pnIe7V/ o/h7fVgFudu1ZVNTFndT+9agv4E4A4jhLzgLHzfhri5grvlaGlkp3nqp63mWjKf03XAFk2AK H0DBTfWUD9DSIJIqkQjG6FsSU1cc2eoCW2wK01ewqCxPyY/tAjnaHRwE49Jmq/P757/Cu4ka Ap4IQKqjx+3DDJrcJiQfWWEfZDXN5fB7PUTX6yiUzjyh0f6h2fb1y2Y6qvc/Nl+YEnIYV/kV qBMo2Jr/KzjzIG1VT9FcewIDAQABoyowKDAYBgNVHREEETAPgQ1hbWFyYXRAa3N1LnJ1MAwG A1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEFBQADgYEAbg+PspFIn8zbwo3Kck48IeDbovXlL059 D5yQxo88NEB6O12VR0KCSjIP13UO79qYCToDc1xjYj8ywVba9KidB9T7twlmLK6F/DvBCU6i 8LHtRLDV2YXq7cSWNZlX4qDhWLe83Z0/InG2/yWL0xxZCgwuabnPMUYZFpJGeeudkWwwggM/ MIICqKADAgECAgENMA0GCSqGSIb3DQEBBQUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMM V2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25z dWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYD VQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNv bmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDMwNzE3MDAwMDAwWhcNMTMwNzE2MjM1OTU5 WjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRk LjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwgZ8wDQYJ KoZIhvcNAQEBBQADgY0AMIGJAoGBAMSmPFVzVftOucqZWh5owHUEcJ3f6f+jHuy9zfVb8hp2 vX8MOmHyv1HOAdTlUAow1wJjWiyJFXCO3cnwK4Vaqj9xVsuvPAsH5/EfkTYkKhPPK9Xzgnc9 A74r/rsYPge/QIACZNenprufZdHFKlSFD0gEf6e20TxhBEAeZBlyYLf7AgMBAAGjgZQwgZEw EgYDVR0TAQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6MDigNqA0hjJodHRwOi8vY3JsLnRoYXd0 ZS5jb20vVGhhd3RlUGVyc29uYWxGcmVlbWFpbENBLmNybDALBgNVHQ8EBAMCAQYwKQYDVR0R BCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDItMTM4MA0GCSqGSIb3DQEBBQUAA4GB AEiM0VCD6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0whuPg2H6otnzYvwPQcUCCTcDz9reFhYsPZ Ohl+hLGZGwDFGguCdJ4lUJRix9sncVcljd2pnDmOjCBPZV+V2vf3h9bGCE6u9uo05RAaWzVN d+NWIXiC3CEZNd4ksdMdRv9dX2VPMYIDZDCCA2ACAQEwdjBiMQswCQYDVQQGEwJaQTElMCMG A1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEHpsMo6nkbUVegxjAzzxYCkwCQYFKw4DAhoF AKCCAcMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDkwNzA2 MjAxNTQ2WjAjBgkqhkiG9w0BCQQxFgQUxDU+jPxs4id9CGGkrKfTVzcHXA0wUgYJKoZIhvcN AQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYF Kw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhB6bDKOp5G1FXoMYwM88WApMIGHBgsq hkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1 aW5nIENBAhB6bDKOp5G1FXoMYwM88WApMA0GCSqGSIb3DQEBAQUABIIBAHEKEOwUiq7CiFAG rPnI9k1Bm/dqk8O2b0iUs9G2ih9bq5e8MeqdmoKU38x1Wfh0z/JXLPObmPjWSe7mTNKxI+X4 qVoqnjcQpXkz8pGZaxU8bNQXmcqyjuGP2a1CDJaWGKTxJmjPSwgrJMK1Uv9N8SDctDqYU5rx jeEG6wrhA1s06d3FnpHuDptCnySrN4SQjFk6vysH4x4nTfIaG5BMYh45L2dAUXYnrkamqGOe 0hePO+lD4mGFuxh/C58AkmPjklIN/ljNl3pf4WTgqoC622tBh/l33YBdlMDcYXxlNa823eoi yuQMnbsbcRv9i4VNreEXGJ3HfmJdcY0B6TBsEz8AAAAAAAA= --------------ms000003020409070406060704-- From owner-freebsd-stable@FreeBSD.ORG Mon Jul 6 20:20:58 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 77194106564A for ; Mon, 6 Jul 2009 20:20:58 +0000 (UTC) (envelope-from marck@rinet.ru) Received: from woozle.rinet.ru (woozle.rinet.ru [195.54.192.68]) by mx1.freebsd.org (Postfix) with ESMTP id EAC818FC0A for ; Mon, 6 Jul 2009 20:20:53 +0000 (UTC) (envelope-from marck@rinet.ru) Received: from localhost (localhost [127.0.0.1]) by woozle.rinet.ru (8.14.3/8.14.3) with ESMTP id n66KKq2g006369; Tue, 7 Jul 2009 00:20:52 +0400 (MSD) (envelope-from marck@rinet.ru) Date: Tue, 7 Jul 2009 00:20:52 +0400 (MSD) From: Dmitry Morozovsky To: Kostik Belousov In-Reply-To: <20090706200110.GX2884@deviant.kiev.zoral.com.ua> Message-ID: References: <4A50E947.9020608@ksu.ru> <4A523518.7050008@gmx.de> <4A523849.1070001@ksu.ru> <20090706193653.GU2884@deviant.kiev.zoral.com.ua> <20090706200110.GX2884@deviant.kiev.zoral.com.ua> 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.2.2 (woozle.rinet.ru [0.0.0.0]); Tue, 07 Jul 2009 00:20:53 +0400 (MSD) Cc: Ralf Folkerts , "Marat N.Afanasyev" , FreeBSD-STABLE Mailing List Subject: Re: bug in ufs? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 20:20:58 -0000 On Mon, 6 Jul 2009, Kostik Belousov wrote: KB> > KB> My guess that it is due to fragmentation. KB> > KB> As an experiment, try to create 1-byte file. Does it work on the filesystem KB> > KB> in described state ? KB> > KB> > Doesn't UFS store one-byte (or several-bytes, like PID file) file entirely in KB> > the inode, not consuming any data blocks? KB> KB> No, 1-byte file is stored in fragment. Long write tries to allocate whole KB> block. This is why I wrote about fragmentation. KB> KB> Answering your question, it is short symlinks that are stored in inode KB> in the data block pointers. Ah yes, I somehow mixed these two cases, thank you for clarification. -- 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 Mon Jul 6 20:21:36 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7C6221065670 for ; Mon, 6 Jul 2009 20:21:36 +0000 (UTC) (envelope-from tech@unixteacher.org) Received: from smtp.linuxsecurity.us (ns.linuxsecurity.us [174.133.245.130]) by mx1.freebsd.org (Postfix) with ESMTP id 45CA18FC20 for ; Mon, 6 Jul 2009 20:21:36 +0000 (UTC) (envelope-from tech@unixteacher.org) Received: from smtp.linuxsecurity.us (localhost [127.0.0.1]) by smtp.linuxsecurity.us (Postfix) with ESMTP id 35EDA375803 for ; Mon, 6 Jul 2009 22:05:07 +0200 (CEST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=selector1; d=unixteacher.org; h=Received:X-Virus-Scanned:Received:Received:Message-ID:From:To:Subject:Date:Organization:MIME-Version:Content-Type:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE; b=kYt1DINnE7ciqas53SW3NsDXjmyGCJWeG4Yr3M/m1qp16Ab4CLlgGGXEUDBPaNWCJreJSh530ddldY52nqC0XnA4df0xZQABrDV0w8mCUsWaUvDdmbMOmLB2p1YqPNmdLp/XR6eVWmJCPmFjkapY5QqfiiyGLyBN8lEKyiIiBlI=; Received: from localhost (localhost [127.0.0.1]) by smtp.linuxsecurity.us (Postfix) with ESMTP id 2D950375801 for ; Mon, 6 Jul 2009 22:05:07 +0200 (CEST) X-Virus-Scanned: This header was added to track abuse. LINUX SECURITY GROUP - ANTI SPAM SOLUTIONS http://www.linux-security.us/ . For abuse/spam send e-mail with headers to abuse at unixteacher.org Received: from smtp.linuxsecurity.us ([127.0.0.1]) by localhost (linuxsecurity.us [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MJjVWeqqVsRw for ; Mon, 6 Jul 2009 22:03:41 +0200 (CEST) Received: from workstation (dslb-088-066-012-251.pools.arcor-ip.net [88.66.12.251]) by smtp.linuxsecurity.us (Postfix) with ESMTPA id C4548375802 for ; Mon, 6 Jul 2009 22:03:40 +0200 (CEST) Message-ID: <0475D596F44442839D969C59B5E93F84@workstation> From: "Amza Marian" To: Date: Mon, 6 Jul 2009 22:03:31 +0200 Organization: Linux Security Group MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6001.18000 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6001.18049 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: hw.realmem in stable. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 20:21:37 -0000 Hello, I running 7.2-RELEASE i386 and i seem to have some problems with my = system. hw.realmem does not report correctly the memory.=20 Anybody know whatis the problem ? lsg ~ # sysctl -a | grep hw.*mem hw.physmem: 4214419456 hw.usermem: 3941974016 hw.realmem: 603979776 hw.firewire.fwmem.speed: 2 hw.firewire.fwmem.eui64_lo: 0 hw.firewire.fwmem.eui64_hi: 0 hw.cbb.start_memory: 2281701376 hw.pci.host_mem_start: 2147483648 lsg ~ #=20 lsg ~ # uname -rm 7.2-RELEASE i386 lsg ~ # Thank you. Regards, Amza Marian=20 From owner-freebsd-stable@FreeBSD.ORG Mon Jul 6 20:34:34 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 38BDE1065672 for ; Mon, 6 Jul 2009 20:34:34 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (skuns.zoral.com.ua [91.193.166.194]) by mx1.freebsd.org (Postfix) with ESMTP id 8A0318FC15 for ; Mon, 6 Jul 2009 20:34:33 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id n66KYSFc045582 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 6 Jul 2009 23:34:28 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3) with ESMTP id n66KYSEV000634; Mon, 6 Jul 2009 23:34:28 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3/Submit) id n66KYRbL000633; Mon, 6 Jul 2009 23:34:27 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 6 Jul 2009 23:34:27 +0300 From: Kostik Belousov To: "Marat N.Afanasyev" Message-ID: <20090706203427.GZ2884@deviant.kiev.zoral.com.ua> References: <4A50E947.9020608@ksu.ru> <4A523518.7050008@gmx.de> <4A523849.1070001@ksu.ru> <20090706193653.GU2884@deviant.kiev.zoral.com.ua> <4A525B72.1010808@ksu.ru> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="D0q9PqIqvBFeK6vt" Content-Disposition: inline In-Reply-To: <4A525B72.1010808@ksu.ru> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: Ralf Folkerts , FreeBSD-STABLE Mailing List Subject: Re: bug in ufs? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 20:34:34 -0000 --D0q9PqIqvBFeK6vt Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jul 07, 2009 at 12:15:46AM +0400, Marat N.Afanasyev wrote: > Kostik Belousov wrote: > >On Mon, Jul 06, 2009 at 09:45:45PM +0400, Marat N.Afanasyev wrote: > >>i have a huge amount of small files on the source systems, as you can= =20 > >>see they have about 20 million files and almost each of them is jpeg or= =20 > >>gif. afaik, there are no sparse files at all. > >> > >>i still cannot figure out what is it: a free space leak in ufs2+su or= =20 > >>bug in statfs(3), that is used in df, or something else. > > > >My guess that it is due to fragmentation. > >As an experiment, try to create 1-byte file. Does it work on the filesys= tem > >in described state ? >=20 > I can create small files, as many as i have patience, maximum size of=20 > such "small file" is 14336, so. it seems that if file is no greater than= =20 > (block_size-2048) it can be created. larger file cannot be created. >=20 > imho, fragmentation on filesystem should be very low, there were no=20 > deletions on it, just creations. The fragmentation on UFS usually means using fragments for the file tails, not having file sequential blocks allocated in the non-sequential disk blocks. You experiment confirms my hypothesis. --D0q9PqIqvBFeK6vt Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkpSX9MACgkQC3+MBN1Mb4jgygCeMmOgxVzrTPkVoxCnKl+sjtVV TogAnj27rBmc12PpsGwfcvZiIuPWo9iH =9SPE -----END PGP SIGNATURE----- --D0q9PqIqvBFeK6vt-- From owner-freebsd-stable@FreeBSD.ORG Mon Jul 6 20:58:08 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CBAB9106564A for ; Mon, 6 Jul 2009 20:58:08 +0000 (UTC) (envelope-from tech@unixteacher.org) Received: from smtp.linuxsecurity.us (ns.linuxsecurity.us [174.133.245.130]) by mx1.freebsd.org (Postfix) with ESMTP id 9595E8FC08 for ; Mon, 6 Jul 2009 20:58:08 +0000 (UTC) (envelope-from tech@unixteacher.org) Received: from smtp.linuxsecurity.us (localhost [127.0.0.1]) by smtp.linuxsecurity.us (Postfix) with ESMTP id C4587375801 for ; Mon, 6 Jul 2009 22:58:06 +0200 (CEST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=selector1; d=unixteacher.org; h=Received:X-Virus-Scanned:Received:Received:Message-ID:From:To:References:In-Reply-To:Subject:Date:Organization:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE; b=wDH08SZtqxyo0W9YmGP+PHyETBZjNzq5NWWZZ8fkh9q5Wovy5PCQzolYVnmVVHQvjJiVP4jRiLgY4PXlssGDBYaq3RLHnUlmf/9VgVzzhrW0ruNfLvsP0+dgGrs4sccy0RVVfYFxKp5Nx9hZF50PLB8qVSkHeufeQ6XjVMfahys=; Received: from localhost (localhost [127.0.0.1]) by smtp.linuxsecurity.us (Postfix) with ESMTP id BBCFE375802 for ; Mon, 6 Jul 2009 22:58:06 +0200 (CEST) X-Virus-Scanned: This header was added to track abuse. LINUX SECURITY GROUP - ANTI SPAM SOLUTIONS http://www.linux-security.us/ . For abuse/spam send e-mail with headers to abuse at unixteacher.org Received: from smtp.linuxsecurity.us ([127.0.0.1]) by localhost (linuxsecurity.us [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GKofR-+wOusr for ; Mon, 6 Jul 2009 22:57:12 +0200 (CEST) Received: from workstation (dslb-088-066-012-251.pools.arcor-ip.net [88.66.12.251]) by smtp.linuxsecurity.us (Postfix) with ESMTPA id BAAE5375801 for ; Mon, 6 Jul 2009 22:57:11 +0200 (CEST) Message-ID: <42650195230C4DE4B7816F944EB3B464@workstation> From: "Amza Marian" To: References: <0475D596F44442839D969C59B5E93F84@workstation> In-Reply-To: Date: Mon, 6 Jul 2009 22:57:02 +0200 Organization: Linux Security Group MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6001.18000 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6001.18049 Subject: Re: hw.realmem in stable. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 20:58:09 -0000 I have the kernel compiled with PAE option but anyway, the system report only 600 MB ram lsg ~ # sysctl -a | grep hw.*mem hw.physmem: 4214419456 hw.usermem: 3997806592 hw.realmem: 603979776 hw.firewire.fwmem.speed: 2 hw.firewire.fwmem.eui64_lo: 0 hw.firewire.fwmem.eui64_hi: 0 hw.cbb.start_memory: 2281701376 hw.pci.host_mem_start: 2147483648 lsg ~ # grep memory /var/run/dmesg.boot real memory = 4898947072 (4672 MB) avail memory = 4117958656 (3927 MB) lsg ~ # Thank you. Regards, Amza Marian > >> hw.realmem does not report correctly the memory. > Might be this... > http://www.freebsd.org/doc/en/books/faq/compatibility-memory.html > > Regards > > Damian > > -- > Damian Weber, > > > On Mon, 6 Jul 2009, Amza Marian wrote: > >> Date: Mon, 6 Jul 2009 22:03:31 +0200 >> From: Amza Marian >> To: freebsd-stable@freebsd.org >> Subject: hw.realmem in stable. >> >> Hello, >> >> I running 7.2-RELEASE i386 and i seem to have some problems with my >> system. >> hw.realmem does not report correctly the memory. >> Anybody know whatis the problem ? >> >> lsg ~ # sysctl -a | grep hw.*mem >> hw.physmem: 4214419456 >> hw.usermem: 3941974016 >> hw.realmem: 603979776 >> hw.firewire.fwmem.speed: 2 >> hw.firewire.fwmem.eui64_lo: 0 >> hw.firewire.fwmem.eui64_hi: 0 >> hw.cbb.start_memory: 2281701376 >> hw.pci.host_mem_start: 2147483648 >> lsg ~ # >> >> lsg ~ # uname -rm >> 7.2-RELEASE i386 >> lsg ~ # >> >> >> Thank you. >> >> Regards, >> Amza Marian >> _______________________________________________ >> 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 Mon Jul 6 21:03:18 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 049171065670 for ; Mon, 6 Jul 2009 21:03:18 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id BD3228FC16 for ; Mon, 6 Jul 2009 21:03:17 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from [IPv6:2001:7b8:3a7:0:bdb1:b6a5:88be:cfe9] (unknown [IPv6:2001:7b8:3a7:0:bdb1:b6a5:88be:cfe9]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id D52CD5C59; Mon, 6 Jul 2009 23:03:16 +0200 (CEST) Message-ID: <4A526693.5020401@andric.com> Date: Mon, 06 Jul 2009 23:03:15 +0200 From: Dimitry Andric User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.1.1pre) Gecko/20090705 Shredder/3.0b3pre MIME-Version: 1.0 To: Amza Marian References: <0475D596F44442839D969C59B5E93F84@workstation> <42650195230C4DE4B7816F944EB3B464@workstation> In-Reply-To: <42650195230C4DE4B7816F944EB3B464@workstation> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: hw.realmem in stable. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 21:03:18 -0000 On 2009-07-06 22:57, Amza Marian wrote: > I have the kernel compiled with PAE option but anyway, the system report > only 600 MB ram ... > hw.realmem: 603979776 ... > lsg ~ # grep memory /var/run/dmesg.boot > real memory = 4898947072 (4672 MB) > avail memory = 4117958656 (3927 MB) This looks like a wraparound issue, your realmem doesn't fit into a 32-bit integer: 4,672 MB - 2^32 = 4,898,947,072 - 4,294,967,296 = 603,979,776 From owner-freebsd-stable@FreeBSD.ORG Mon Jul 6 21:20:46 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DBF9B106567E for ; Mon, 6 Jul 2009 21:20:46 +0000 (UTC) (envelope-from rick@kiwi-computer.com) Received: from hamlet.setfilepointer.com (hamlet.SetFilePointer.com [63.224.10.2]) by mx1.freebsd.org (Postfix) with SMTP id 827868FC29 for ; Mon, 6 Jul 2009 21:20:46 +0000 (UTC) (envelope-from rick@kiwi-computer.com) Received: (qmail 60912 invoked from network); 6 Jul 2009 16:20:45 -0500 Received: from keira.kiwi-computer.com (HELO kiwi-computer.com) (63.224.10.3) by hamlet.setfilepointer.com with SMTP; 6 Jul 2009 16:20:45 -0500 Received: (qmail 91449 invoked by uid 2001); 6 Jul 2009 21:20:45 -0000 Date: Mon, 6 Jul 2009 16:20:45 -0500 From: "Rick C. Petty" To: Ruben de Groot , FreeBSD Stable Mailing List Message-ID: <20090706212045.GA91095@keira.kiwi-computer.com> References: <20090703144121.GC11039@hugo10.ka.punkt.de> <4A4E1E24.3020303@andric.com> <20090703152150.GE11039@hugo10.ka.punkt.de> <20090705003834.12211k8697td2o74@webmail.private.lan> <20090706073941.GA78371@ei.bzerk.org> <20090706074256.GD6306@hugo10.ka.punkt.de> <4A51B721.5020505@andric.com> <4A51B9FA.9010906@andric.com> <20090706093904.GA79434@ei.bzerk.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090706093904.GA79434@ei.bzerk.org> User-Agent: Mutt/1.4.2.3i Cc: Subject: Re: What is /boot/kernel/*.symbols? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rick-freebsd2008@kiwi-computer.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 21:20:47 -0000 On Mon, Jul 06, 2009 at 11:39:04AM +0200, Ruben de Groot wrote: > On Mon, Jul 06, 2009 at 10:46:50AM +0200, Dimitry Andric typed: > > > > Right, so it's a lot bigger on amd64. I guess those 64-bit pointers > > aren't entirely free. :) > > I'm not sure where the size difference comes from. I have some sparc64 > systems running -current with symbols and the size of /boot/kernel is > more comparable to i386, even with the 8-byte pointer size: Um, probably there are a lot of devices on amd64 that aren't available for sparc64? -- Rick C. Petty From owner-freebsd-stable@FreeBSD.ORG Mon Jul 6 21:22:34 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 062A01065690 for ; Mon, 6 Jul 2009 21:22:34 +0000 (UTC) (envelope-from tech@unixteacher.org) Received: from smtp.linuxsecurity.us (ns.linuxsecurity.us [174.133.245.130]) by mx1.freebsd.org (Postfix) with ESMTP id C52CB8FC12 for ; Mon, 6 Jul 2009 21:22:33 +0000 (UTC) (envelope-from tech@unixteacher.org) Received: from smtp.linuxsecurity.us (localhost [127.0.0.1]) by smtp.linuxsecurity.us (Postfix) with ESMTP id 74A6D375801; Mon, 6 Jul 2009 23:22:32 +0200 (CEST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=selector1; d=unixteacher.org; h=Received:X-Virus-Scanned:Received:Received:Message-ID:From:To:Cc:References:In-Reply-To:Subject:Date:Organization:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE; b=ItQSjwYGCflmn1n7LhpFQs9UijAnMq62pm5hNSaJnvnLWGRg9MSlVveobGr5k0tO7lEFAyRMOdzBqmuG8i94IynQb4gtMs8YzFZWFO62vOLlr3NpD0T/4/rmvEBoQA9Wx2QUx18oHTbf+pk3J3h8sZYTuP9bO6QCyyQmQ/toftE=; Received: from localhost (localhost [127.0.0.1]) by smtp.linuxsecurity.us (Postfix) with ESMTP id 6BF7A375803; Mon, 6 Jul 2009 23:22:32 +0200 (CEST) X-Virus-Scanned: This header was added to track abuse. LINUX SECURITY GROUP - ANTI SPAM SOLUTIONS http://www.linux-security.us/ . For abuse/spam send e-mail with headers to abuse at unixteacher.org Received: from smtp.linuxsecurity.us ([127.0.0.1]) by localhost (linuxsecurity.us [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c91Xn1DcGfOt; Mon, 6 Jul 2009 23:21:29 +0200 (CEST) Received: from workstation (dslb-088-066-012-251.pools.arcor-ip.net [88.66.12.251]) by smtp.linuxsecurity.us (Postfix) with ESMTPA id 05E4F375801; Mon, 6 Jul 2009 23:21:28 +0200 (CEST) Message-ID: <785FFA80D58E4B5194F2DCFE15488903@workstation> From: "Amza Marian" To: "Dimitry Andric" References: <0475D596F44442839D969C59B5E93F84@workstation> <42650195230C4DE4B7816F944EB3B464@workstation> <4A526693.5020401@andric.com> In-Reply-To: <4A526693.5020401@andric.com> Date: Mon, 6 Jul 2009 23:21:19 +0200 Organization: Linux Security Group MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6001.18000 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6001.18049 Cc: freebsd-stable@freebsd.org Subject: Re: hw.realmem in stable. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 21:22:34 -0000 Thank you sir. Is there any solution for this issue ? (because applications does not work correctly. - like mysql.) (sorry for my english.) ----- Original Message ----- From: "Dimitry Andric" To: "Amza Marian" Cc: Sent: Monday, July 06, 2009 11:03 PM Subject: Re: hw.realmem in stable. > On 2009-07-06 22:57, Amza Marian wrote: >> I have the kernel compiled with PAE option but anyway, the system report >> only 600 MB ram > ... >> hw.realmem: 603979776 > ... >> lsg ~ # grep memory /var/run/dmesg.boot >> real memory = 4898947072 (4672 MB) >> avail memory = 4117958656 (3927 MB) > > This looks like a wraparound issue, your realmem doesn't fit into a > 32-bit integer: > > 4,672 MB - 2^32 = 4,898,947,072 - 4,294,967,296 = 603,979,776 From owner-freebsd-stable@FreeBSD.ORG Mon Jul 6 22:08:27 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 66A051065674 for ; Mon, 6 Jul 2009 22:08:27 +0000 (UTC) (envelope-from amarat@ksu.ru) Received: from mx.kzn.ru (mx.kzn.ru [194.85.243.38]) by mx1.freebsd.org (Postfix) with ESMTP id 7EE5F8FC1F for ; Mon, 6 Jul 2009 22:08:26 +0000 (UTC) (envelope-from amarat@ksu.ru) Authentication-Results: iout.kzn.ru; dkim=neutral (message not signed) header.i=none Received-SPF: None identity=pra; client-ip=193.232.252.56; receiver=iout.kzn.ru; envelope-from="amarat@ksu.ru"; x-sender="amarat@ksu.ru"; x-conformance=sidf_compatible Received-SPF: None identity=mailfrom; client-ip=193.232.252.56; receiver=iout.kzn.ru; envelope-from="amarat@ksu.ru"; x-sender="amarat@ksu.ru"; x-conformance=sidf_compatible Received-SPF: None identity=helo; client-ip=193.232.252.56; receiver=iout.kzn.ru; envelope-from="amarat@ksu.ru"; x-sender="postmaster@ruby.ksu.ru"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aq4EABgTUkrCVfWh/2dsb2JhbACBUc1GgnaBHAWBOg X-IronPort-AV: E=Sophos;i="4.42,358,1243800000"; d="p7s'?scan'208";a="4201969" Received: from mail.ksu.ru (HELO ruby.ksu.ru) ([193.232.252.56]) by iout.kzn.ru with ESMTP; 07 Jul 2009 02:08:24 +0400 X-Pass-Through: Kazan State University Network Received: from zealot.ksu.ru ([194.85.245.161]) by ksu.ru (8.13.4/8.13.4) with ESMTP id n66LFc6B001093; Mon, 6 Jul 2009 21:15:39 GMT Received: from zealot.ksu.ru (localhost.lnet [127.0.0.1]) by zealot.ksu.ru (8.14.3/8.14.3) with ESMTP id n66M802U056027; Tue, 7 Jul 2009 02:08:00 +0400 (MSD) (envelope-from amarat@ksu.ru) Message-ID: <4A5275C0.50607@ksu.ru> Date: Tue, 07 Jul 2009 02:08:00 +0400 From: "Marat N.Afanasyev" User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.8.1.22) Gecko/20090704 SeaMonkey/1.1.17 MIME-Version: 1.0 To: Kostik Belousov References: <4A50E947.9020608@ksu.ru> <4A523518.7050008@gmx.de> <4A523849.1070001@ksu.ru> <20090706193653.GU2884@deviant.kiev.zoral.com.ua> <4A525B72.1010808@ksu.ru> <20090706203427.GZ2884@deviant.kiev.zoral.com.ua> In-Reply-To: <20090706203427.GZ2884@deviant.kiev.zoral.com.ua> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010104080805080500080909" Cc: FreeBSD-STABLE Mailing List Subject: Re: bug in ufs? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 22:08:27 -0000 This is a cryptographically signed message in MIME format. --------------ms010104080805080500080909 Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Kostik Belousov wrote: > On Tue, Jul 07, 2009 at 12:15:46AM +0400, Marat N.Afanasyev wrote: >> Kostik Belousov wrote: >>> On Mon, Jul 06, 2009 at 09:45:45PM +0400, Marat N.Afanasyev wrote: >>>> i have a huge amount of small files on the source systems, as you can >>>> see they have about 20 million files and almost each of them is jpeg or >>>> gif. afaik, there are no sparse files at all. >>>> >>>> i still cannot figure out what is it: a free space leak in ufs2+su or >>>> bug in statfs(3), that is used in df, or something else. >>> My guess that it is due to fragmentation. >>> As an experiment, try to create 1-byte file. Does it work on the filesystem >>> in described state ? >> I can create small files, as many as i have patience, maximum size of >> such "small file" is 14336, so. it seems that if file is no greater than >> (block_size-2048) it can be created. larger file cannot be created. >> >> imho, fragmentation on filesystem should be very low, there were no >> deletions on it, just creations. > > The fragmentation on UFS usually means using fragments for the file tails, > not having file sequential blocks allocated in the non-sequential disk > blocks. > > You experiment confirms my hypothesis. is there any way to change this behavior? and i wonder why even if i can create a reasonable number of small files i cannot create a slightly larger file joining two unallocated parts of different blocks even if no fully free block exists? ;) -- SY, Marat --------------ms010104080805080500080909 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII8zCC AtQwggI9oAMCAQICEHpsMo6nkbUVegxjAzzxYCkwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDQwMTE5MTUxOFoX DTEwMDQwMTE5MTUxOFowPzEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEcMBoG CSqGSIb3DQEJARYNYW1hcmF0QGtzdS5ydTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALqa7MfgjbsxmgpTOKxAN7w+cFViFA8NrULAARwVQJQJCnVRGf3i97EwNdLE8VTNniU4 ybS4gtLsy9gfNuuyPV2AJESpgrxaG+KZyHu1f6P4e31YBbnbtWVTUxZ3U/vWoL+BOAOI4S84 Cx834a4uYK75WhpZKd56qet5loyn9N1wBZNgCh9AwU31lA/Q0iCSKpEIxuhbElNXHNnqAlts CtNXsKgsT8mP7QI52h0cBOPSZqvz++e/wruJGgKeCECqo8ftwwya3CYkH1lhH2Q1zeXwez1E 1+solM48odH+odn29ctmOqr3PzZfmBJyGFf5FagTKNia/ys48yBtVU/RXHsCAwEAAaMqMCgw GAYDVR0RBBEwD4ENYW1hcmF0QGtzdS5ydTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUA A4GBAG4Pj7KRSJ/M28KNynJOPCHg26L15S9OfQ+ckMaPPDRAejtdlUdCgkoyD9d1Du/amAk6 A3NcY2I/MsFW2vSonQfU+7cJZiyuhfw7wQlOovCx7USw1dmF6u3EljWZV+Kg4Vi3vN2dPyJx tv8li9McWQoMLmm5zzFGGRaSRnnrnZFsMIIC1DCCAj2gAwIBAgIQemwyjqeRtRV6DGMDPPFg KTANBgkqhkiG9w0BAQUFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1 bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElz c3VpbmcgQ0EwHhcNMDkwNDAxMTkxNTE4WhcNMTAwNDAxMTkxNTE4WjA/MR8wHQYDVQQDExZU aGF3dGUgRnJlZW1haWwgTWVtYmVyMRwwGgYJKoZIhvcNAQkBFg1hbWFyYXRAa3N1LnJ1MIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuprsx+CNuzGaClM4rEA3vD5wVWIUDw2t QsABHBVAlAkKdVEZ/eL3sTA10sTxVM2eJTjJtLiC0uzL2B8267I9XYAkRKmCvFob4pnIe7V/ o/h7fVgFudu1ZVNTFndT+9agv4E4A4jhLzgLHzfhri5grvlaGlkp3nqp63mWjKf03XAFk2AK H0DBTfWUD9DSIJIqkQjG6FsSU1cc2eoCW2wK01ewqCxPyY/tAjnaHRwE49Jmq/P757/Cu4ka Ap4IQKqjx+3DDJrcJiQfWWEfZDXN5fB7PUTX6yiUzjyh0f6h2fb1y2Y6qvc/Nl+YEnIYV/kV qBMo2Jr/KzjzIG1VT9FcewIDAQABoyowKDAYBgNVHREEETAPgQ1hbWFyYXRAa3N1LnJ1MAwG A1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEFBQADgYEAbg+PspFIn8zbwo3Kck48IeDbovXlL059 D5yQxo88NEB6O12VR0KCSjIP13UO79qYCToDc1xjYj8ywVba9KidB9T7twlmLK6F/DvBCU6i 8LHtRLDV2YXq7cSWNZlX4qDhWLe83Z0/InG2/yWL0xxZCgwuabnPMUYZFpJGeeudkWwwggM/ MIICqKADAgECAgENMA0GCSqGSIb3DQEBBQUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMM V2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25z dWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYD VQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNv bmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDMwNzE3MDAwMDAwWhcNMTMwNzE2MjM1OTU5 WjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRk LjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwgZ8wDQYJ KoZIhvcNAQEBBQADgY0AMIGJAoGBAMSmPFVzVftOucqZWh5owHUEcJ3f6f+jHuy9zfVb8hp2 vX8MOmHyv1HOAdTlUAow1wJjWiyJFXCO3cnwK4Vaqj9xVsuvPAsH5/EfkTYkKhPPK9Xzgnc9 A74r/rsYPge/QIACZNenprufZdHFKlSFD0gEf6e20TxhBEAeZBlyYLf7AgMBAAGjgZQwgZEw EgYDVR0TAQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6MDigNqA0hjJodHRwOi8vY3JsLnRoYXd0 ZS5jb20vVGhhd3RlUGVyc29uYWxGcmVlbWFpbENBLmNybDALBgNVHQ8EBAMCAQYwKQYDVR0R BCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDItMTM4MA0GCSqGSIb3DQEBBQUAA4GB AEiM0VCD6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0whuPg2H6otnzYvwPQcUCCTcDz9reFhYsPZ Ohl+hLGZGwDFGguCdJ4lUJRix9sncVcljd2pnDmOjCBPZV+V2vf3h9bGCE6u9uo05RAaWzVN d+NWIXiC3CEZNd4ksdMdRv9dX2VPMYIDZDCCA2ACAQEwdjBiMQswCQYDVQQGEwJaQTElMCMG A1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEHpsMo6nkbUVegxjAzzxYCkwCQYFKw4DAhoF AKCCAcMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDkwNzA2 MjIwODAwWjAjBgkqhkiG9w0BCQQxFgQUxWw7vUAi75WaqJ/t9gQ8ZV+BPeUwUgYJKoZIhvcN AQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYF Kw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhB6bDKOp5G1FXoMYwM88WApMIGHBgsq hkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1 aW5nIENBAhB6bDKOp5G1FXoMYwM88WApMA0GCSqGSIb3DQEBAQUABIIBAHgJFPiLMKPH7bx6 b9C8GaXwct5gyNniijRCeaNqRALtT6CUtEUwdHljPNxa7UCsNrPnoy7y4XqJwLpqnnzB/zjo VNuGX59s689lzb2yNwNOr3xhMhfEkTNvfz+H0Jei6ceO8H2yKPD1aIzxW32w9ioIw39klmxD rnwM0SvcJnoaAoYdtPYvc1HAFeEb8lUEWHNwmmzpnNz+cwGgGTh7FZMqepWmp01xdyfZQPH5 4Tcik5Ld9P4bVqllVEWOjMXOLf6D82TU+0JQM5HDT6SX9E0wTx7gMIAdFaZR7obO5buPmysM pmS4pzmyXf2kzNMmE06FHoZqyG3NdcfKvMbLjQEAAAAAAAA= --------------ms010104080805080500080909-- From owner-freebsd-stable@FreeBSD.ORG Mon Jul 6 23:18:38 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E9D9E1065676 for ; Mon, 6 Jul 2009 23:18:38 +0000 (UTC) (envelope-from pj@smo.de) Received: from mail.ilk.de (mx-out14.ilk.de [194.121.104.14]) by mx1.freebsd.org (Postfix) with ESMTP id 553798FC17 for ; Mon, 6 Jul 2009 23:18:38 +0000 (UTC) (envelope-from pj@smo.de) Received: from bologna.intern.smo.de (pool55.ka.ilk.net [212.86.194.55]) by mail.ilk.de (8.13.4/8.13.4/ilk-relay) with ESMTP id n66HGZ3q022322; Mon, 6 Jul 2009 19:16:35 +0200 Received: from [192.168.153.208] (herdubreid.intern.smo.de [192.168.153.208]) by bologna.intern.smo.de (8.13.8+Sun/8.13.8) with ESMTP id n66HGWbI029253; Mon, 6 Jul 2009 19:16:32 +0200 (CEST) Message-ID: <4A523185.90007@smo.de> Date: Mon, 06 Jul 2009 19:16:53 +0200 From: Philipp Ost User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.13) Gecko/20090411 X-Accept-Language: de, en-us, en MIME-Version: 1.0 To: "Ishmael F.E." References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-stable@freebsd.org Subject: Re: upgrading ports without recompiling X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 23:18:39 -0000 Ishmael F.E. wrote: [...] > . > so, ¿how can I upgrade the ports? > unfortunatley I don't have time to compile my 64bit system Have you looked at the -PP option of portupgrade? I don't know how portmaster handles upgrades using packages only. HTH, Philipp From owner-freebsd-stable@FreeBSD.ORG Tue Jul 7 00:42:06 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7BDDE1065678 for ; Tue, 7 Jul 2009 00:42:06 +0000 (UTC) (envelope-from dan@langille.org) Received: from nyi.unixathome.org (nyi.unixathome.org [64.147.113.42]) by mx1.freebsd.org (Postfix) with ESMTP id 4450A8FC15 for ; Tue, 7 Jul 2009 00:42:05 +0000 (UTC) (envelope-from dan@langille.org) Received: from localhost (localhost [127.0.0.1]) by nyi.unixathome.org (Postfix) with ESMTP id 185C2509E1; Tue, 7 Jul 2009 01:22:19 +0100 (BST) X-Virus-Scanned: amavisd-new at unixathome.org Received: from nyi.unixathome.org ([127.0.0.1]) by localhost (nyi.unixathome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L0hFnzFfRPdI; Tue, 7 Jul 2009 01:22:17 +0100 (BST) Received: from bast.unixathome.org (bast.unixathome.org [10.8.1.1]) by nyi.unixathome.org (Postfix) with ESMTP id 334D250994; Tue, 7 Jul 2009 01:22:17 +0100 (BST) Received: from polo.unixathome.org (polo.unixathome.org [10.55.0.23]) by bast.unixathome.org (Postfix) with ESMTP id CD5A9B857; Tue, 7 Jul 2009 01:22:15 +0100 (BST) Message-ID: <4A529537.8070206@langille.org> Date: Mon, 06 Jul 2009 20:22:15 -0400 From: Dan Langille User-Agent: Thunderbird 2.0.0.22 (X11/20090627) MIME-Version: 1.0 To: Dan Langille References: <49774BAE.3000809@ksu.ru> <20090122071845.GF4881@alf.bsdes.net> <4978A10A.9060006@langille.org> <7697CDAB-B4E7-480A-B31A-1F54275B8D54@langille.org> In-Reply-To: <7697CDAB-B4E7-480A-B31A-1F54275B8D54@langille.org> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Cc: Victor Balada Diaz , freebsd-stable@freebsd.org, Pete French , "Marat N.Afanasyev" Subject: Re: interrupt storm on MSI IXP600 based motherboards X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2009 00:42:06 -0000 Dan Langille wrote: > > On Jan 22, 2009, at 11:38 AM, Dan Langille wrote: > >> Victor Balada Diaz wrote: >>> On Wed, Jan 21, 2009 at 07:22:06PM +0300, Marat N.Afanasyev wrote: >>>>>> trouble with onboard re(4) was resolved in -CURRENT and -STABLE, >>>>>> but storms are not bound to ethernet only. storm may appear on any >>>>>> device. if any device generates enough interrupts rate, storm will >>>>>> arrive. >>>>> Yes, I just got another storm, on my ATA controller this time. Ah >>>>> well, so much for the idea of disabling unneeded devices! >>>>> >>>>> -pete. >>>>> >>>> it's a kind of magic, really. I built a new kernel with KDB and DDB >>>> and after 1 day, 13:15 I'm still waiting for storm to arrive. And I >>>> added >>>> hw.acpi.osname="Linux" to /boot/loader.conf. >>> Try doing lots of IO and you will get the problem soon. You might >>> want to try: >>> while true; do dd if=/dev/zero of=BAH bs=1M count=1024; sync; done >> >> FWIW, last night I changed the address of the comm port IO in my BIOS. >> Then I ran the Bacula regression test suite (lots of IO). For my >> machine, once the interrupt storm starts, it continues. I do not know >> if that happens to everyone. >> >> Since changing the address, I have had no interrupt storms. I have >> been running the above IO loop for about ten minutes. >> >> No storm yet (knock on wood). > > > And it's back: > > Jan 22 17:21:46 polo kernel: interrupt storm detected on "irq22:"; > throttling interrupt source > Jan 22 17:23:19 polo kernel: interrupt storm detected on "irq22:"; > throttling interrupt source > Jan 22 17:28:20 polo kernel: interrupt storm detected on "irq22:"; > throttling interrupt source > Jan 22 17:33:20 polo kernel: interrupt storm detected on "irq22:"; > throttling interrupt source > Jan 22 17:38:20 polo kernel: interrupt storm detected on "irq22:"; > throttling interrupt source > > I shall try the hw.acpi.osname="Linux" option now. > > From dmsg: Jan 22 18:10:07 polo kernel: ACPI: Overriding _OS definition > with "Linux" The problem returns: Jul 6 20:12:10 polo kernel: interrupt storm detected on "irq22:"; throttling interrupt source Jul 6 20:12:41 polo last message repeated 31 times Jul 6 20:14:42 polo last message repeated 121 times Jul 6 20:17:09 polo last message repeated 147 times FreeBSD polo.example.org 7.2-STABLE FreeBSD 7.2-STABLE #10: Mon Jun 1 19:19:13 EDT 2009 dan@example.org:/usr/obj/usr/src/sys/PHENOM amd64 Copyright (c) 1992-2009 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 7.2-STABLE #10: Mon Jun 1 19:19:13 EDT 2009 dan@example.org:/usr/obj/usr/src/sys/PHENOM Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD Phenom(tm) 9600 Quad-Core Processor (2300.17-MHz K8-class CPU) Origin = "AuthenticAMD" Id = 0x100f22 Stepping = 2 Features=0x178bfbff Features2=0x802009> AMD Features=0xee500800 AMD Features2=0x7ff,,,Prefetch,,> TSC: P-state invariant Cores per package: 4 usable memory = 4281012224 (4082 MB) avail memory = 4108423168 (3918 MB) ACPI APIC Table: <122107 APIC0947> FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: <122107 RSDT0947> on motherboard ACPI: Overriding _OS definition with "Linux" acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of fee00000, 1000 (3) failed acpi0: reservation of ffb80000, 80000 (3) failed acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, cff00000 (3) failed ACPI HPET table warning: Sequence is non-zero (2) Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 acpi_timer0: <32-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 900 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: at device 11.0 on pci0 pci1: on pcib1 vgapci0: port 0xd800-0xd87f mem 0xfd000000-0xfdffffff,0xd0000000-0xdfffffff,0xfa000000-0xfbffffff irq 19 at device 0.0 on pci1 atapci0: port 0xc000-0xc007,0xb000-0xb003,0xa000-0xa007,0x9000-0x9003,0x8000-0x800f mem 0xf9fff800-0xf9fffbff irq 22 at device 18.0 on pci0 atapci0: [ITHREAD] atapci0: AHCI Version 01.10 controller with 4 ports detected ata2: on atapci0 ata2: [ITHREAD] ata3: on atapci0 ata3: [ITHREAD] ata4: on atapci0 ata4: [ITHREAD] ata5: on atapci0 ata5: [ITHREAD] ohci0: mem 0xf9ffe000-0xf9ffefff irq 16 at device 19.0 on pci0 ohci0: [GIANT-LOCKED] ohci0: [ITHREAD] usb0: OHCI version 1.0, legacy support usb0: SMM does not respond, resetting usb0: on ohci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 2 ports with 2 removable, self powered ohci1: mem 0xf9ffd000-0xf9ffdfff irq 17 at device 19.1 on pci0 ohci1: [GIANT-LOCKED] ohci1: [ITHREAD] usb1: OHCI version 1.0, legacy support usb1: SMM does not respond, resetting usb1: on ohci1 usb1: USB revision 1.0 uhub1: on usb1 uhub1: 2 ports with 2 removable, self powered ohci2: mem 0xf9ffc000-0xf9ffcfff irq 18 at device 19.2 on pci0 ohci2: [GIANT-LOCKED] ohci2: [ITHREAD] usb2: OHCI version 1.0, legacy support usb2: SMM does not respond, resetting usb2: on ohci2 usb2: USB revision 1.0 uhub2: on usb2 uhub2: 2 ports with 2 removable, self powered ohci3: mem 0xf9ffb000-0xf9ffbfff irq 17 at device 19.3 on pci0 ohci3: [GIANT-LOCKED] ohci3: [ITHREAD] usb3: OHCI version 1.0, legacy support usb3: SMM does not respond, resetting usb3: on ohci3 usb3: USB revision 1.0 uhub3: on usb3 uhub3: 2 ports with 2 removable, self powered ohci4: mem 0xf9ffa000-0xf9ffafff irq 18 at device 19.4 on pci0 ohci4: [GIANT-LOCKED] ohci4: [ITHREAD] usb4: OHCI version 1.0, legacy support usb4: SMM does not respond, resetting usb4: on ohci4 usb4: USB revision 1.0 uhub4: on usb4 uhub4: 2 ports with 2 removable, self powered ehci0: mem 0xf9fff000-0xf9fff0ff irq 19 at device 19.5 on pci0 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb5: EHCI version 1.0 usb5: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 usb4 usb5: on ehci0 usb5: USB revision 2.0 uhub5: on usb5 uhub5: 10 ports with 10 removable, self powered pci0: at device 20.0 (no driver attached) atapci1: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xff00-0xff0f at device 20.1 on pci0 ata0: on atapci1 ata0: [ITHREAD] hdac0: mem 0xf9ff4000-0xf9ff7fff irq 16 at device 20.2 on pci0 hdac0: HDA Driver Revision: 20090329_0131 hdac0: [ITHREAD] isab0: at device 20.3 on pci0 isa0: on isab0 pcib2: at device 20.4 on pci0 pci2: on pcib2 fwohci0: port 0xe800-0xe87f mem 0xfebff800-0xfebfffff irq 23 at device 0.0 on pci2 fwohci0: [FILTER] fwohci0: OHCI version 1.10 (ROM=1) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 00:dc:10:00:01:53:a0:bc fwohci0: Phy 1394a available S400, 2 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 dcons_crom0: on firewire0 dcons_crom0: bus_addr 0x1464000 fwe0: on firewire0 if_fwe0: Fake Ethernet address: 02:dc:10:53:a0:bc fwe0: Ethernet address: 02:dc:10:53:a0:bc fwip0: on firewire0 fwip0: Firewire address: 00:dc:10:00:01:53:a0:bc @ 0xfffe00000000, S400, maxrec 2048 sbp0: on firewire0 fwohci0: Initiate bus reset fwohci0: BUS reset fwohci0: node_id=0xc800ffc0, gen=1, CYCLEMASTER mode fxp0: port 0xe400-0xe43f mem 0xfebfe000-0xfebfefff,0xfea00000-0xfeafffff irq 22 at device 2.0 on pci2 miibus0: on fxp0 inphy0: PHY 1 on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp0: Ethernet address: 00:04:ac:d3:78:23 fxp0: [ITHREAD] acpi_button0: on acpi0 sio0: configured irq 3 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: configured irq 3 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 flags 0x10 on acpi0 sio0: type 16550A sio0: [FILTER] fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: [FILTER] fd0: <1440-KB 3.5" drive> on fdc0 drive 0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model IntelliMouse, device ID 3 cpu0: on acpi0 acpi_throttle0: on cpu0 acpi_throttle0: CLK_VAL field overlaps THT_EN bit device_attach: acpi_throttle0 attach returned 6 cpu1: on acpi0 cpu2: on acpi0 cpu3: on acpi0 ppc0: cannot reserve I/O port range sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 ugen0: on uhub4 Timecounters tick every 1.000 msec firewire0: 1 nodes, maxhop <= 0, cable IRM = 0 (me) firewire0: bus manager 0 (me) acd0: CDRW at ata0-slave UDMA33 ad4: 476940MB at ata2-master SATA300 ad6: 476940MB at ata3-master SATA300 hdac0: HDA Codec #0: Realtek ALC888 pcm0: at cad 0 nid 1 on hdac0 pcm1: at cad 0 nid 1 on hdac0 pcm2: at cad 0 nid 1 on hdac0 GEOM_MIRROR: Device mirror/gm0 launched (2/2). GEOM_LABEL: Label for provider mirror/gm0s1a is ufsid/47c95ad36ed40e80. GEOM_LABEL: Label for provider mirror/gm0s1d is ufsid/47c95ae2ac3d5ead. GEOM_LABEL: Label for provider mirror/gm0s1e is ufsid/47c95ad3fa3660aa. GEOM_LABEL: Label for provider mirror/gm0s1f is ufsid/47c95ad37ffedafc. acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 (probe0:ata0:0:1:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 (probe0:ata0:0:1:0): CAM Status: SCSI Status Error (probe0:ata0:0:1:0): SCSI Status: Check Condition (probe0:ata0:0:1:0): NOT READY asc:3a,1 (probe0:ata0:0:1:0): Medium not present - tray closed (probe0:ata0:0:1:0): Unretryable error acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 cd0 at ata0 bus 0 target 1 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: 33.000MB/s transfers cd0: Attempt to query device size failed: NOT READY, Medium not present - tray closed SMP: AP CPU #1 Launched! SMP: AP CPU #2 Launched! SMP: AP CPU #3 Launched! Trying to mount root from ufs:/dev/mirror/gm0s1a GEOM_LABEL: Label ufsid/47c95ad36ed40e80 removed. GEOM_LABEL: Label for provider mirror/gm0s1a is ufsid/47c95ad36ed40e80. GEOM_LABEL: Label ufsid/47c95ad3fa3660aa removed. GEOM_LABEL: Label for provider mirror/gm0s1e is ufsid/47c95ad3fa3660aa. GEOM_LABEL: Label ufsid/47c95ad37ffedafc removed. GEOM_LABEL: Label for provider mirror/gm0s1f is ufsid/47c95ad37ffedafc. GEOM_LABEL: Label ufsid/47c95ae2ac3d5ead removed. GEOM_LABEL: Label for provider mirror/gm0s1d is ufsid/47c95ae2ac3d5ead. GEOM_LABEL: Label ufsid/47c95ad36ed40e80 removed. GEOM_LABEL: Label ufsid/47c95ad3fa3660aa removed. GEOM_LABEL: Label ufsid/47c95ad37ffedafc removed. GEOM_LABEL: Label ufsid/47c95ae2ac3d5ead removed. [dan@polo:/usr/home/dan] $ From owner-freebsd-stable@FreeBSD.ORG Tue Jul 7 00:51:12 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E9D6A1065679; Tue, 7 Jul 2009 00:51:12 +0000 (UTC) (envelope-from kensmith@cse.Buffalo.EDU) Received: from phoebe.cse.buffalo.edu (phoebe.cse.buffalo.edu [128.205.32.89]) by mx1.freebsd.org (Postfix) with ESMTP id B15508FC14; Tue, 7 Jul 2009 00:51:12 +0000 (UTC) (envelope-from kensmith@cse.Buffalo.EDU) Received: from [128.205.32.76] (bauer.cse.buffalo.edu [128.205.32.76]) (authenticated bits=0) by phoebe.cse.buffalo.edu (8.14.1/8.13.7) with ESMTP id n670X2Ns080408 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 6 Jul 2009 20:33:11 -0400 (EDT) (envelope-from kensmith@cse.buffalo.edu) From: Ken Smith To: freebsd-stable , freebsd-current Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-zDff1WUjPA5wALxM3eGB" Organization: U. Buffalo CSE Department Date: Mon, 06 Jul 2009 20:33:02 -0400 Message-Id: <1246926782.11597.23.camel@bauer.cse.buffalo.edu> Mime-Version: 1.0 X-Mailer: Evolution 2.24.5 FreeBSD GNOME Team Port X-DCC-Buffalo.EDU-Metrics: phoebe.cse.buffalo.edu 1029; Body=0 Fuz1=0 Fuz2=0 Cc: Subject: FreeBSD 8.0-BETA1 Available X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2009 00:51:13 -0000 --=-zDff1WUjPA5wALxM3eGB Content-Type: text/plain Content-Transfer-Encoding: quoted-printable The first public test build of the FreeBSD 8.0-RELEASE test cycle is now available, 8.0-BETA1. Through the next week or so more information about the release will be posted but here is the current target schedule for the other 'major events': BETA2: July 13, 2009 BETA3: July 20, 2009 RC1: July 27, 2009 RC2: August 17, 2009 RELEASE:August 31, 2009 People with the resources to do so (test machines...) are encouraged to give 8.0-BETA1 a try. At this point it is not quite ready for production systems but mostly because there is still some ongoing work in a few areas that may cause some changes in things like ABI/API. Debugging support (WITNESS, malloc debugging, etc.) are also still turned on and those tend to cause a performance hit. As far as we know there are no known issues that would cause data corruption or anything like that, just the issues with performance and potential for changes caused by ongoing work. If you find problems they can be reported through the normal Gnats based PR system or posted to the mailing lists. Note that for BETA1 no packages were included with any of the images. The amd64 and i386 architectures include a file named: 8.0-BETA1--memstick.img If you copy that to a USB memory stick newer machines should be able to boot from it and use it to install from. Note that you need to overwrite the contents of the memory stick completely, not copy it into an existing filesystem on the memory stick. Exactly how you do that depends on your machine but just to give you an example this works on the machine I tested it with: dd if=3D8.0-BETA1-amd64-memstick.img of=3D/dev/da0 bs=3D10240 conv=3Dsync Be careful if you have SCSI drives, more USB disks than just the memory stick, etc - make sure /dev/da0 (or whatever you use) is the memory stick. Using this image for livefs based rescue mode is known to not work, that is one of the things still being worked on. FreeBSD Update was not ready for updates to 8.0 at the point this message was sent but it is also being worked on. A separate message will be posted when it's ready. Checksums for the images: MD5 (8.0-BETA1-amd64-bootonly.iso) =3D e7cc0b3b022775f6be058044f171e3d2 MD5 (8.0-BETA1-amd64-disc1.iso) =3D ad259bc0d57e1a7ae1afdc04bbb87cfd MD5 (8.0-BETA1-amd64-dvd1.iso) =3D f240e48be3db47ed338bb157244b874d MD5 (8.0-BETA1-amd64-livefs.iso) =3D 2a0f06d61d2722efe68cf8c6a14de0c6 MD5 (8.0-BETA1-amd64-memstick.img) =3D 10bc42a388c213497f03aadad30e0486 MD5 (8.0-BETA1-i386-bootonly.iso) =3D cadcdb82377705061a0d464569ecfef7 MD5 (8.0-BETA1-i386-disc1.iso) =3D 9e19a4edcc3b2d7f594cbcdc7fcabace MD5 (8.0-BETA1-i386-dvd1.iso) =3D 98a2f5e05391eb4ab2b421443296cd7b MD5 (8.0-BETA1-i386-livefs.iso) =3D c1d35cd8a15434b2af0bc1f27ddb48a1 MD5 (8.0-BETA1-i386-memstick.img) =3D c6a0fbe8e31b2987b5da47c52705fa8e MD5 (8.0-BETA1-ia64-bootonly.iso) =3D d40385e657477566100ae66485a98bb3 MD5 (8.0-BETA1-ia64-disc1.iso) =3D 216b4e54536bb41c5a9543ce88f288bc MD5 (8.0-BETA1-ia64-disc2.iso) =3D 790eb3e163aee02c7c6dddcfa54cc167 MD5 (8.0-BETA1-ia64-disc3.iso) =3D b59510898c2ce1cfe594620cc2f9de97 MD5 (8.0-BETA1-ia64-dvd1.iso) =3D ce7d5abec2aaed9028b82c66445e2734 MD5 (8.0-BETA1-ia64-livefs.iso) =3D 5021774a2349d960e859082065c1bc86 MD5 (8.0-BETA1-pc98-bootonly.iso) =3D 9a421562167c5d6806784151c26694fe MD5 (8.0-BETA1-pc98-disc1.iso) =3D b5ca7555697677eb23057fffe2c47062 MD5 (8.0-BETA1-pc98-livefs.iso) =3D 0c8a405c394651ea61dee34d9637b47e MD5 (8.0-BETA1-powerpc-bootonly.iso) =3D e982f204c4024c544f88753b400007a5 MD5 (8.0-BETA1-powerpc-disc1.iso) =3D 0e59688100a8288e2bee87c4d0f9b0ee MD5 (8.0-BETA1-powerpc-disc2.iso) =3D 1426a523d1b2480c4f546422934d1cc4 MD5 (8.0-BETA1-powerpc-disc3.iso) =3D d6b7505441c756be547b4587331af6b9 MD5 (8.0-BETA1-powerpc-livefs.iso) =3D 2dbf7c3543fcd35c834fd19f64f240cf MD5 (8.0-BETA1-sparc64-bootonly.iso) =3D 24004c2014edcbafb68f09399db1b74d MD5 (8.0-BETA1-sparc64-disc1.iso) =3D 96e7a0b14581fac7ab845a4e9916d393 MD5 (8.0-BETA1-sparc64-dvd1.iso) =3D efcc5a4923f335cd483d76395333b639 SHA256 (8.0-BETA1-amd64-bootonly.iso) =3D d49e8651f71c1a4a4d2ad9b4e391e7dfe= a2fec159a716876c4c0a547b346d34d SHA256 (8.0-BETA1-amd64-disc1.iso) =3D 692eb89c0ba07dc161ad2ea366516a2210c5= d5e5cf90a48ed6316e67b7ebb5e4 SHA256 (8.0-BETA1-amd64-dvd1.iso) =3D eaf4a18c269589af516f6c96af164f918345a= 34e2fb1e5273762479a7779c4cd SHA256 (8.0-BETA1-amd64-livefs.iso) =3D b9e68d7944707f73f0894e0f610ff73ff5c= 5350e9dbc15d980a4d9413d61daf8 SHA256 (8.0-BETA1-amd64-memstick.img) =3D c3ece618be54d4c51400945d8922f6724= 547453a133c32450ac2ebbacaabaa65 SHA256 (8.0-BETA1-i386-bootonly.iso) =3D d82918557e595fdb76ae8d4158e0f5738a= 3879985d6c5109b944d382c9f767af SHA256 (8.0-BETA1-i386-disc1.iso) =3D 398a93e851088391fc1cca6c3ff50494afc4e= 5471791cff12204ef8673b81472 SHA256 (8.0-BETA1-i386-dvd1.iso) =3D b61e14733e498fe83e482010b036f3aabb8d7d= ace2ed5fb8b8dbe371141a2caa SHA256 (8.0-BETA1-i386-livefs.iso) =3D 6d47e830bea1a96d851490d41b4a47248a03= ec2a6c39df534ca407aba2daf58a SHA256 (8.0-BETA1-i386-memstick.img) =3D b7561c27ea789447e368a1e2398249282a= e46e8752a82bbb3614cb5db3d606e7 SHA256 (8.0-BETA1-ia64-bootonly.iso) =3D 6e9b9cc92a82b062cc5d9d51da7652a790= 97894b16e8c2cf8bcdb7b51c3aa576 SHA256 (8.0-BETA1-ia64-disc1.iso) =3D 52ca59f0129cda5651bf0aad3daa57a07a719= 580c3ece28be63178e40e6f0613 SHA256 (8.0-BETA1-ia64-disc2.iso) =3D f6e1bded3aec557e19ef0249b9c3b17ba3c5e= 0aca99d98ae697e6107c9bb3061 SHA256 (8.0-BETA1-ia64-disc3.iso) =3D b8b8e5ce0cca5eb3dd0dc8ea05b7de399cb93= 7ecc4b960eb092e621cda22bbd5 SHA256 (8.0-BETA1-ia64-dvd1.iso) =3D 29d5852bef2d09c73075242ea2e2d35072a51b= 30b624d5229ed8aec6737cfbc5 SHA256 (8.0-BETA1-ia64-livefs.iso) =3D 0a92eb0f09dfd4f4ab0694fd94482e4682ed= ed3425186737bd0e2440e957dd3b SHA256 (8.0-BETA1-pc98-bootonly.iso) =3D 5d77d1fb6a5d7e819b0d90d1848f7d029d= 64ce456ca550e3049d63eb5fc8891a SHA256 (8.0-BETA1-pc98-disc1.iso) =3D 5e11719fd24d8f8a9fd0fd4ce07c72509c197= e48b1e45060d931b0f8bcad9335 SHA256 (8.0-BETA1-pc98-livefs.iso) =3D 271056add63d5e82f85a482cfd0efcfaaacb= 1b5941337fc459782e97577f3e0e SHA256 (8.0-BETA1-powerpc-bootonly.iso) =3D 60c984e47d8e71eb87ae382cb1bc19a= 0abd982095b5906dafb539e799ad0a51e SHA256 (8.0-BETA1-powerpc-disc1.iso) =3D 647b51471e71a8de9ab4a0c42fa94d869f= ae33a2f5f3a0aaa07592bb9854a49f SHA256 (8.0-BETA1-powerpc-disc2.iso) =3D 9a46aecda07f6b6fa040bf7c852c3a99eb= 27e8db529c8f26974d5a9a2ecf0b8d SHA256 (8.0-BETA1-powerpc-disc3.iso) =3D efe792cb535ea2a6ee821cdcd5fd1e5306= e116e32b57e2f1e6d4309f672830ab SHA256 (8.0-BETA1-powerpc-livefs.iso) =3D 1b8e5c401bf5b14c0a14d91b21895ed22= 73287158e59a158313bcec43aead8ff SHA256 (8.0-BETA1-sparc64-bootonly.iso) =3D 2775ceec218f5fef0bc2d17ea80e149= 2f423307f27cec38df352b1e9ee6f96a4 SHA256 (8.0-BETA1-sparc64-disc1.iso) =3D 9eac5684c3c650e2cac01343c7933931ae= f0227bdb6e9a4931402ad0dd41b9c8 SHA256 (8.0-BETA1-sparc64-dvd1.iso) =3D 207268ec113811213d73b571c2322585c26= cf6beae88e27e5680e77c93e249b2 --=20 Ken Smith - From there to here, from here to | kensmith@cse.buffalo.edu there, funny things are everywhere. | - Theodore Geisel | --=-zDff1WUjPA5wALxM3eGB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEABECAAYFAkpSl7AACgkQ/G14VSmup/aqfQCePQYepsJ8Lr6x0SgzG2Mv/EVx EMYAn307W6Ad2Ib7oM52utK5RxRWsV3h =PyZW -----END PGP SIGNATURE----- --=-zDff1WUjPA5wALxM3eGB-- From owner-freebsd-stable@FreeBSD.ORG Tue Jul 7 01:12:15 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A4E2D1065670 for ; Tue, 7 Jul 2009 01:12:15 +0000 (UTC) (envelope-from dan.naumov@gmail.com) Received: from mail-yx0-f181.google.com (mail-yx0-f181.google.com [209.85.210.181]) by mx1.freebsd.org (Postfix) with ESMTP id 6533D8FC0C for ; Tue, 7 Jul 2009 01:12:15 +0000 (UTC) (envelope-from dan.naumov@gmail.com) Received: by yxe11 with SMTP id 11so6400620yxe.3 for ; Mon, 06 Jul 2009 18:12:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=rdJw+zvKPjqB5m2zLfF9T81rs/pEDImtOtCRDGg3Juc=; b=Cy6Cs907RNFUM8gNQ1og1EWQsdMySYTotSJDr/R6+aU0KmuUS8IYniJcM+MKSQCgV2 256k95E/lk/VXO0V4tfwwI4aH/yVz9tYScCSk+zhT9kB4jnX2t4OtQjLLo/NxoxroZS3 Ioljy44C+OCNxu8VZvZ9a/8pakSJFUB+XLrmU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=TRV+4DES8JQlY3hK16khcBtQOaYBuMCRe25FCoLBkrX7Mh9Vu9GX3yCE5nm6Yi2RTF IDcX+PMNrND496NrrHrVCNqPSLZAzhVWBuIEulY/iJZkINEftmBWojHXyL+zdrFB4wu1 YKB3OCjrqKWy+gc2p1PKNadDidroORSnkRvek= MIME-Version: 1.0 Received: by 10.100.92.2 with SMTP id p2mr9700271anb.7.1246929134550; Mon, 06 Jul 2009 18:12:14 -0700 (PDT) Date: Tue, 7 Jul 2009 04:12:14 +0300 Message-ID: From: Dan Naumov To: FreeBSD-STABLE Mailing List Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: 7.2-release/amd64: panic, spin lock held too long X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2009 01:12:15 -0000 I just got a panic following by a reboot a few seconds after running "portsnap update", /var/log/messages shows the following: Jul 7 03:49:38 atom syslogd: kernel boot file is /boot/kernel/kernel Jul 7 03:49:38 atom kernel: spin lock 0xffffffff80b3edc0 (sched lock 1) held by 0xffffff00017d8370 (tid 100054) too long Jul 7 03:49:38 atom kernel: panic: spin lock held too long /var/crash looks empty. This is a system running official 7.2-p1 binaries since I am using freebsd-update to keep up with the patches (just updated to -p2 after this panic) running with very low load, mostly serving files to my home network over Samba and running a few irssi instances in a screen. What do I need to do to catch more information if/when this happens again? - Sincerely, Dan Naumov From owner-freebsd-stable@FreeBSD.ORG Tue Jul 7 01:18:11 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7ED5F1065670 for ; Tue, 7 Jul 2009 01:18:11 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by mx1.freebsd.org (Postfix) with ESMTP id 0B8328FC15 for ; Tue, 7 Jul 2009 01:18:10 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: by fxm18 with SMTP id 18so3879520fxm.43 for ; Mon, 06 Jul 2009 18:18:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=5Lr2T5SRTmIJCnuq6sGdLRgflUqaR5l4Kbtl2MpcEZ4=; b=r2vXG+9c3N0L+N1SZEX8RaeShTF+wP3uApEwhft5ikKoy68JIwe8YT2+Gz832wJgaH UaZODnCKGE/cni/KxaW5r80SF8wdL7ixOTAB0F0DBw3odV0UDPHQc/2Ii8eOv0u3ffdY 9p9oXM/7SwvXnbAtWDrm9PTu07S5J3dhV50bM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=cXCZz1ck0hspZsNkFzMUn2RKacKlC2/U1eOYFzSyeGkCuA0wG7xlelWPgKgsdLq+iP iinlpTHcU3lBfUUNYSoiUpL2jtXn4jbxvVbRbZB/fBnTzfIMtZbL4Fy0ZDEy3idShd2V FCEP4XWkFQFFCOVbvjEsVeetZ0aXG9vtMI/r4= MIME-Version: 1.0 Sender: asmrookie@gmail.com Received: by 10.223.108.15 with SMTP id d15mr2391300fap.62.1246929490108; Mon, 06 Jul 2009 18:18:10 -0700 (PDT) In-Reply-To: References: Date: Tue, 7 Jul 2009 03:18:10 +0200 X-Google-Sender-Auth: 54c161573281bdaa Message-ID: <3bbf2fe10907061818v245abd0cgc3ca5073cb93aea4@mail.gmail.com> From: Attilio Rao To: Dan Naumov Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: FreeBSD-STABLE Mailing List Subject: Re: 7.2-release/amd64: panic, spin lock held too long X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2009 01:18:11 -0000 2009/7/7 Dan Naumov : > I just got a panic following by a reboot a few seconds after running > "portsnap update", /var/log/messages shows the following: > > Jul 7 03:49:38 atom syslogd: kernel boot file is /boot/kernel/kernel > Jul 7 03:49:38 atom kernel: spin lock 0xffffffff80b3edc0 (sched lock > 1) held by 0xffffff00017d8370 (tid 100054) too long > Jul 7 03:49:38 atom kernel: panic: spin lock held too long That's a known bug, affecting -CURRENT as well. The cpustop IPI is handled though an NMI, which means it could interrupt a CPU in any moment, even while holding a spinlock, violating one well known FreeBSD rule. That means that the cpu can stop itself while the thread was holding the sched lock spinlock and not releasing it (there is no way, modulo highly hackish, to fix that). In the while hardclock() wants to schedule something else to run and got stuck on the thread lock. Ideal fix would involve not using a NMI for serving the cpustop while having a cheap way (not making the common path too hard) to tell hardclock() to avoid scheduling while cpustop is in flight. Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-stable@FreeBSD.ORG Tue Jul 7 01:25:08 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9E48D1065673 for ; Tue, 7 Jul 2009 01:25:08 +0000 (UTC) (envelope-from dan.naumov@gmail.com) Received: from mail-gx0-f210.google.com (mail-gx0-f210.google.com [209.85.217.210]) by mx1.freebsd.org (Postfix) with ESMTP id 441328FC17 for ; Tue, 7 Jul 2009 01:25:07 +0000 (UTC) (envelope-from dan.naumov@gmail.com) Received: by gxk6 with SMTP id 6so4870074gxk.19 for ; Mon, 06 Jul 2009 18:25:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=t+ZBrOOAK8+UBjQru4untHaky5qkDfLWEdEBBYvahwo=; b=lltiKdCRPdJVe2h0Fp87tosf32nrvdYvpG+7LQSgV4leZcToQpMB8Rgm5NlGXl1O1G 0d5jJlRX5L1aT2MroJgbmGd18oDGFMKkeZTmjUp+FgP7/STqJ8uWJuFx2bYOy4XYOMsu 6VvGPd6mIj+EqJTcB3qjiudTnG7CUm5feGPY4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=o2w0v1wsWuOtgaZLs3R92ujBCQjrgJfhH4bw7NCY13WMVhr9Jwr9eaq/oLrivm268P ggz/0WhHseBHhgArzDTpOqQ30uh+CQvjf0njnsuzA64LKlQBr9l7BpKQFLYUtZGrdRNt SITFJDA1LzLaVXMXGtY8a1q4bq3iQ/00VFlCA= MIME-Version: 1.0 Received: by 10.100.96.12 with SMTP id t12mr9706864anb.4.1246929907469; Mon, 06 Jul 2009 18:25:07 -0700 (PDT) In-Reply-To: <3bbf2fe10907061818v245abd0cgc3ca5073cb93aea4@mail.gmail.com> References: <3bbf2fe10907061818v245abd0cgc3ca5073cb93aea4@mail.gmail.com> Date: Tue, 7 Jul 2009 04:25:07 +0300 Message-ID: From: Dan Naumov To: Attilio Rao Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD-STABLE Mailing List Subject: Re: 7.2-release/amd64: panic, spin lock held too long X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2009 01:25:08 -0000 On Tue, Jul 7, 2009 at 4:18 AM, Attilio Rao wrote: > 2009/7/7 Dan Naumov : >> I just got a panic following by a reboot a few seconds after running >> "portsnap update", /var/log/messages shows the following: >> >> Jul =A07 03:49:38 atom syslogd: kernel boot file is /boot/kernel/kernel >> Jul =A07 03:49:38 atom kernel: spin lock 0xffffffff80b3edc0 (sched lock >> 1) held by 0xffffff00017d8370 (tid 100054) too long >> Jul =A07 03:49:38 atom kernel: panic: spin lock held too long > > That's a known bug, affecting -CURRENT as well. > The cpustop IPI is handled though an NMI, which means it could > interrupt a CPU in any moment, even while holding a spinlock, > violating one well known FreeBSD rule. > That means that the cpu can stop itself while the thread was holding > the sched lock spinlock and not releasing it (there is no way, modulo > highly hackish, to fix that). > In the while hardclock() wants to schedule something else to run and > got stuck on the thread lock. > > Ideal fix would involve not using a NMI for serving the cpustop while > having a cheap way (not making the common path too hard) to tell > hardclock() to avoid scheduling while cpustop is in flight. > > Thanks, > Attilio Any idea if a fix is being worked on and how unlucky must one be to run into this issue, should I expect it to happen again? Is it basically completely random? - Sincerely, Dan Naumov From owner-freebsd-stable@FreeBSD.ORG Tue Jul 7 01:27:50 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B6493106566C for ; Tue, 7 Jul 2009 01:27:50 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-bw0-f221.google.com (mail-bw0-f221.google.com [209.85.218.221]) by mx1.freebsd.org (Postfix) with ESMTP id 399CC8FC08 for ; Tue, 7 Jul 2009 01:27:48 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: by bwz21 with SMTP id 21so777515bwz.43 for ; Mon, 06 Jul 2009 18:27:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=16ur+hlFU9BZOVozVG9HWZ66MuNq4GYtP1m/4ZfYA2k=; b=CiHs+9oQe9Y4c3G7t5l1TYhaGVoxVnu0OBWuPrMKkGV2yEjLkMvj/z/BU9mbM+RzWk dxwvr6Y3NnvXOoMo4Ufu5cybOeyCcPeBv6dEeBn0s8SYf1GXRYUi7ydQJnp+fr9KLqXX K5I6HY8HhmTrVW9i8obyIGgK3B0c4eicLD4JE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=vx3Fjvwvtm3gQN3DTaF6Ywtq8LKBvecrY/Epyu4JNtrcM7Foz/I6moflvdjK7Mel9a NgpDU2SPbRDU0d/bjKpkglRIEpHGG7yloY64HwTk9PjhupRHSdTzf2Od4c44ZpSE0J9s c4Ga9z31F8z2/spE6kp/CQm1ZPSTALtx6ToWQ= MIME-Version: 1.0 Sender: asmrookie@gmail.com Received: by 10.223.108.210 with SMTP id g18mr2356188fap.38.1246930068071; Mon, 06 Jul 2009 18:27:48 -0700 (PDT) In-Reply-To: References: <3bbf2fe10907061818v245abd0cgc3ca5073cb93aea4@mail.gmail.com> Date: Tue, 7 Jul 2009 03:27:48 +0200 X-Google-Sender-Auth: fc3bc7471f60a415 Message-ID: <3bbf2fe10907061827g35eaeb49g26cf6fdb64436ca7@mail.gmail.com> From: Attilio Rao To: Dan Naumov Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: FreeBSD-STABLE Mailing List Subject: Re: 7.2-release/amd64: panic, spin lock held too long X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2009 01:27:51 -0000 2009/7/7 Dan Naumov : > On Tue, Jul 7, 2009 at 4:18 AM, Attilio Rao wrote: >> 2009/7/7 Dan Naumov : >>> I just got a panic following by a reboot a few seconds after running >>> "portsnap update", /var/log/messages shows the following: >>> >>> Jul 7 03:49:38 atom syslogd: kernel boot file is /boot/kernel/kernel >>> Jul 7 03:49:38 atom kernel: spin lock 0xffffffff80b3edc0 (sched lock >>> 1) held by 0xffffff00017d8370 (tid 100054) too long >>> Jul 7 03:49:38 atom kernel: panic: spin lock held too long >> >> That's a known bug, affecting -CURRENT as well. >> The cpustop IPI is handled though an NMI, which means it could >> interrupt a CPU in any moment, even while holding a spinlock, >> violating one well known FreeBSD rule. >> That means that the cpu can stop itself while the thread was holding >> the sched lock spinlock and not releasing it (there is no way, modulo >> highly hackish, to fix that). >> In the while hardclock() wants to schedule something else to run and >> got stuck on the thread lock. >> >> Ideal fix would involve not using a NMI for serving the cpustop while >> having a cheap way (not making the common path too hard) to tell >> hardclock() to avoid scheduling while cpustop is in flight. >> >> Thanks, >> Attilio > > Any idea if a fix is being worked on and how unlucky must one be to > run into this issue, should I expect it to happen again? Is it > basically completely random? I'd like to work on that issue before BETA3 (and backport to STABLE_7), I'm just time-constrained right now. it is completely random. Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-stable@FreeBSD.ORG Tue Jul 7 02:15:50 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 37BDF10656B6 for ; Tue, 7 Jul 2009 02:15:50 +0000 (UTC) (envelope-from cmdlnkid@gmail.com) Received: from mail-px0-f172.google.com (mail-px0-f172.google.com [209.85.216.172]) by mx1.freebsd.org (Postfix) with ESMTP id D12EC8FC1C for ; Tue, 7 Jul 2009 02:15:47 +0000 (UTC) (envelope-from cmdlnkid@gmail.com) Received: by pxi2 with SMTP id 2so308629pxi.3 for ; Mon, 06 Jul 2009 19:15:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:cc:subject :in-reply-to:message-id:references:user-agent:x-openpgp-key-id :x-openpgp-key-fingerprint:mime-version:content-type :content-transfer-encoding; bh=ADdYJYQ7s+qSX1gn4xb1AYYgppxgiPKnUeORaXWAEzk=; b=Z7M+7J7MieZeL+ImT67Qd51xHENqq8YPbGslQV8Be6wPcsa8C+JltSMgsgx0zt1rz2 1TmTcaV4oz/zMbQh1nK6OC7g42MX20Pej4iiQxxPWNDPjvrazvwGRPPAftOTdtK2ZtHX V2SXXv6ZsZJhvrxTHQwmudNX3T1YnGVpb8fR8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:cc:subject:in-reply-to:message-id:references:user-agent :x-openpgp-key-id:x-openpgp-key-fingerprint:mime-version :content-type:content-transfer-encoding; b=qsuTf+tNUHRJqo4JeVw6Dyv257OiRUTrIl7SPMOy+ZSPPbD+B0hr1T17q/84MazwtN wmKPndO7TAQ5msOqEr6y0htOzMdkBB6V3mULmjF23N7HZp+HxhMkgTMD/yELYQiloypd UoA/Whv0W/pRfpdk+u1ErF4ojmA5ZiupTnS98= Received: by 10.115.95.20 with SMTP id x20mr8563400wal.40.1246932947052; Mon, 06 Jul 2009 19:15:47 -0700 (PDT) Received: from ?192.168.1.66? (adsl-99-35-14-242.dsl.klmzmi.sbcglobal.net [99.35.14.242]) by mx.google.com with ESMTPS id g25sm12255288wag.43.2009.07.06.19.15.44 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 06 Jul 2009 19:15:45 -0700 (PDT) Date: Mon, 6 Jul 2009 22:15:39 -0400 From: CmdLnKid cc: FreeBSD Stable In-Reply-To: <4A523185.90007@smo.de> Message-ID: References: <4A523185.90007@smo.de> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-OpenPGP-Key-ID: 0xDFFDD218 X-OpenPGP-Key-Fingerprint: 2924 1C72 A6C2 852A 2094 25EE 9968 2636 DFFD D218 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8BIT Subject: Re: upgrading ports without recompiling X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2009 02:16:03 -0000 On Mon, 6 Jul 2009 13:16 -0000, pj wrote: > Ishmael F.E. wrote: > [...] >> . >> so, ¿how can I upgrade the ports? >> unfortunatley I don't have time to compile my 64bit system > > Have you looked at the -PP option of portupgrade? > I don't know how portmaster handles upgrades using packages only. > You could look into devel/ccache & devel/distcc if you would like to speed up your compile times. Of course your first compile will always be the slowest one but everyone after that will be faster. This is not always advised as a good solution and has been known to throw some pretty weird compiler bugs and also fail while compiling certain ports but that is tweakable through /etc/make.conf*. Best regards. J. Hellenthal From owner-freebsd-stable@FreeBSD.ORG Tue Jul 7 06:38:59 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 660761065672 for ; Tue, 7 Jul 2009 06:38:59 +0000 (UTC) (envelope-from admin@kkip.pl) Received: from mainframe.kkip.pl (kkip.pl [87.105.164.78]) by mx1.freebsd.org (Postfix) with ESMTP id B6E338FC08 for ; Tue, 7 Jul 2009 06:38:58 +0000 (UTC) (envelope-from admin@kkip.pl) Received: from mb01.admin.lan.kkip.pl ([10.66.3.254]) by mainframe.kkip.pl with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MO4KM-000Npc-NE; Tue, 07 Jul 2009 08:38:57 +0200 Message-ID: <4A52ED7F.5030904@kkip.pl> Date: Tue, 07 Jul 2009 08:38:55 +0200 From: Bartosz Stec User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: CmdLnKid References: <4A523185.90007@smo.de> In-Reply-To: X-Authenticated-User: admin@kkip.pl X-Authenticator: plain X-Sender-Verify: SUCCEEDED (sender exists & accepts mail) X-Spam-Score: -8.9 X-Spam-Score-Int: -88 X-Exim-Version: 4.69 (build at 04-Jun-2009 16:07:02) X-Date: 2009-07-07 08:38:57 X-Connected-IP: 10.66.3.254:4148 X-Message-Linecount: 175 X-Body-Linecount: 161 X-Message-Size: 5771 X-Body-Size: 5084 X-Received-Count: 1 X-Recipient-Count: 3 X-Local-Recipient-Count: 3 X-Local-Recipient-Defer-Count: 0 X-Local-Recipient-Fail-Count: 0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org, sulfurfff@gmail.com Subject: Re: upgrading ports without recompiling X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2009 06:38:59 -0000 CmdLnKid pisze: > On Mon, 6 Jul 2009 13:16 -0000, pj wrote: > >> Ishmael F.E. wrote: >> [...] >>> . >>> so, ¿how can I upgrade the ports? >>> unfortunatley I don't have time to compile my 64bit system You don't need to compile whole OS to compile ports, if this is what you had in mind. >> >> Have you looked at the -PP option of portupgrade? >> I don't know how portmaster handles upgrades using packages only. >> > > You could look into devel/ccache & devel/distcc if you would like to > speed up your compile times. Of course your first compile will always > be the slowest one but everyone after that will be faster. This is not > always advised as a good solution and has been known to throw some > pretty weird compiler bugs and also fail while compiling certain ports > but that is tweakable through /etc/make.conf*. > Well, I heard about some problems with ccache, although I personally experienced only one of them - fail when building world on AMD64. Here's my make.conf, feel free to give it try after installing ccache (Try to set MAKEOPTS = CPU cores +1, and set appropriate CPUTYPE): CPUTYPE=athlon64 MAKEOPTS=-j3 # USE CCACHE .if !defined(NOCCACHE) CC=/usr/local/libexec/ccache/world-cc CXX=/usr/local/libexec/ccache/world-c++ .endif # default build settings for ports collection .if ${.CURDIR:M*/ports/*} CFLAGS= -O2 -fno-strict-aliasing -pipe -funroll-loops -fomit-frame-pointer CXXFLAGS= -O2 -fno-strict-aliasing -pipe -funroll-loops .endif # default build settings for base system .if ${.CURDIR:M*/usr/src/*} || ${.CURDIR:M*/usr/obj/*} CFLAGS=-O2 -fno-strict-aliasing -pipe COPTFLAGS=-O2 -fno-strict-aliasing -pipe CXXFLAGS=${CFLAGS} .endif In case of any problem with specific port (or world) type in shell: # setenv NOCCACHE before build. This should give you maximum compile speed in case when package is unavailable while using portupgrade -afP -- Bartosz Stec From owner-freebsd-stable@FreeBSD.ORG Tue Jul 7 07:10:28 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 87E3A1065670 for ; Tue, 7 Jul 2009 07:10:28 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by mx1.freebsd.org (Postfix) with ESMTP id 13D408FC15 for ; Tue, 7 Jul 2009 07:10:27 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: by fxm18 with SMTP id 18so3963961fxm.43 for ; Tue, 07 Jul 2009 00:10:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=o6kMaB53p+0MW8lic0F/vnOoCeu7goQdQ6hCsQ5NUuk=; b=ZPZZ3R/qAmbr84R7Ekg8jMjhwtoIYTvqKf9u/iOBH73CKem74FGHxWKOedhCpthpbL cdeJzxu4WLz93VHb/Txm1A4gMgUa8+PVwhtDuMhokU107dzeaYVxp18dKfBLSpK1ljhi kMugLIveeyrQVgK1KRjmz76+2Zq2YlZgHSXxg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=hPW9gSqvMfciIWjAiqZFav3yIFHNs27TcSap5joWyqbv011jx3JURNvSYv3cnRsQVJ 7QRzpwcvQfnCaJkUtu0Qsm4C/PfXl6MREPD37BYz85nKOBEvsE63PXGh6dg0DJWRIVdl b9O3TGNxFXWkicT2KqtHzg42vOzgQQ5RkuRA0= MIME-Version: 1.0 Received: by 10.204.58.79 with SMTP id f15mr5396522bkh.202.1246950626824; Tue, 07 Jul 2009 00:10:26 -0700 (PDT) In-Reply-To: <4A5275C0.50607@ksu.ru> References: <4A50E947.9020608@ksu.ru> <4A523518.7050008@gmx.de> <4A523849.1070001@ksu.ru> <20090706193653.GU2884@deviant.kiev.zoral.com.ua> <4A525B72.1010808@ksu.ru> <20090706203427.GZ2884@deviant.kiev.zoral.com.ua> <4A5275C0.50607@ksu.ru> Date: Tue, 7 Jul 2009 11:10:26 +0400 Message-ID: From: pluknet To: "Marat N.Afanasyev" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Kostik Belousov , FreeBSD-STABLE Mailing List Subject: Re: bug in ufs? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2009 07:10:28 -0000 2009/7/7 Marat N.Afanasyev : > Kostik Belousov wrote: >> >> On Tue, Jul 07, 2009 at 12:15:46AM +0400, Marat N.Afanasyev wrote: >>> >>> Kostik Belousov wrote: >>>> >>>> On Mon, Jul 06, 2009 at 09:45:45PM +0400, Marat N.Afanasyev wrote: >>>>> >>>>> i have a huge amount of small files on the source systems, as you can >>>>> see they have about 20 million files and almost each of them is jpeg or gif. >>>>> afaik, there are no sparse files at all. >>>>> >>>>> i still cannot figure out what is it: a free space leak in ufs2+su or >>>>> bug in statfs(3), that is used in df, or something else. >>>> >>>> My guess that it is due to fragmentation. >>>> As an experiment, try to create 1-byte file. Does it work on the >>>> filesystem >>>> in described state ? >>> >>> I can create small files, as many as i have patience, maximum size of >>> such "small file" is 14336, so. it seems that if file is no greater than >>> (block_size-2048) it can be created. larger file cannot be created. >>> >>> imho, fragmentation on filesystem should be very low, there were no >>> deletions on it, just creations. >> >> The fragmentation on UFS usually means using fragments for the file tails, >> not having file sequential blocks allocated in the non-sequential disk >> blocks. >> >> You experiment confirms my hypothesis. > > i cannot create a slightly larger > file joining two unallocated parts of different blocks even if no fully free > block exists? ;) You can't. As far as I remember, ffs_alloc() tries to populate a number of whole blocks and then only packs a remain data tail into a partially allocated block (one, two, .. seven fragments), thus creating a block fragmentation. In other words, it's impossible to partially allocate several blocks for a one file. Can you show your dumpfs output (superblock part)? -- wbr, pluknet From owner-freebsd-stable@FreeBSD.ORG Tue Jul 7 08:17:12 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1C69E106566C for ; Tue, 7 Jul 2009 08:17:12 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from mail12.syd.optusnet.com.au (mail12.syd.optusnet.com.au [211.29.132.193]) by mx1.freebsd.org (Postfix) with ESMTP id 9AF038FC1C for ; Tue, 7 Jul 2009 08:17:11 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from server.vk2pj.dyndns.org (c122-106-247-205.belrs3.nsw.optusnet.com.au [122.106.247.205]) by mail12.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id n678Gw6X032587 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 7 Jul 2009 18:17:04 +1000 X-Bogosity: Ham, spamicity=0.000000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.3/8.14.3) with ESMTP id n678GwMx068701; Tue, 7 Jul 2009 18:16:58 +1000 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.3/8.14.3/Submit) id n678Gw82068700; Tue, 7 Jul 2009 18:16:58 +1000 (EST) (envelope-from peter) Date: Tue, 7 Jul 2009 18:16:58 +1000 From: Peter Jeremy To: "Marat N.Afanasyev" Message-ID: <20090707081658.GA68385@server.vk2pj.dyndns.org> References: <4A50E947.9020608@ksu.ru> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="W/nzBZO5zC0uMSeA" Content-Disposition: inline In-Reply-To: <4A50E947.9020608@ksu.ru> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.19 (2009-01-05) Cc: FreeBSD-STABLE Mailing List Subject: Re: bug in ufs? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2009 08:17:12 -0000 --W/nzBZO5zC0uMSeA Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2009-Jul-05 21:56:23 +0400, "Marat N.Afanasyev" wrote: >i have a strange problem with writing data to my ufs2+su filesystem. Overall, I think you are pushing UFS and have hit one of its limits. >1. i made a 1T gpt partition on my storage server, and formatted it: >newfs -U -m 0 -o time -i 32768 /dev/da1p3a '-m 0' is undesirable. The default 8% free space is intended to hide the sort of effect you've run into. Unless you can find a slightly bigger disk, I suggest you try building an 8K/1K filesystem by adding '-b 8192 -f 1024' - this will be slightly slower than the default 16K/2K but will hopefully allow you to fit slightly more files in. >2. i tried to move data from other servers to this filesystem, total=20 >size of files is slightly less than 1T Can you be more accurate than "slightly less than 1T" (ie how many MiB) and what is the size distribution of the files? The average size is 48KiB but are they all roughly the same size or do they vary widely? Are there many files <16KiB? >3. i encountered a 'No space left on device' while i still have 11G of=20 >free space and about 13 million free inodes on the filesystem: > >#df -ih >Filesystem Size Used Avail Capacity iused ifree %iused=20 >Mounted on >/dev/da1p3a 1.0T 1.0T 11G 99% 20397465 13363173 60%=20 >/mnt/45_114 More significant figures are needed. How about 'df -im' or 'df -ik'. How close are you to fitting in all the files you want? >all i want to know is whether this is a bug or a feature? and if such a=20 >behavior is well-known, where can i read about it? Have a read of /usr/share/doc/smm/05.fastfs/paper.ascii.gz - especially the bits about "fragments". Whilst this paper talks about the original UFS and a 4K/1K configuration, the principles remain the same in UFS2. --=20 Peter Jeremy --W/nzBZO5zC0uMSeA Content-Type: application/x-pkcs7-signature Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIIPuQYJKoZIhvcNAQcCoIIPqjCCD6YCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC DSUwggXgMIIDyKADAgECAgMD984wDQYJKoZIhvcNAQEFBQAweTEQMA4GA1UEChMHUm9vdCBD QTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNp Z25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0QGNhY2VydC5vcmcwHhcN MDcwODI4MDA1MjAzWhcNMDkwODI3MDA1MjAzWjCBoDEVMBMGA1UEAxMMUGV0ZXIgSmVyZW15 MSswKQYJKoZIhvcNAQkBFhxwZXRlcmplcmVteUBvcHR1c2hvbWUuY29tLmF1MScwJQYJKoZI hvcNAQkBFhhwZXRlci5qZXJlbXlAYXV1Zy5vcmcuYXUxMTAvBgkqhkiG9w0BCQEWInBldGVy LmplcmVteUBhbGNhdGVsLWx1Y2VudC5jb20uYXUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQC0saUsCMQRDIW7pALRwK5z9/gRCBYiYNnmx9fYEsDiIJ1zYJd33Z7hJ4exUXOG Zk3IZjtSyUh9Qnqvic9bvhKpsLKE/2xzmj5ddfN4WzNcaM0+S2J6DzU5kZprn9Ex7A6YJ8WH vEy8f1mXBnQ8SCwAsBJ41tIdW8cxkBRGCL9A+LFzEoHQ9x150eK2UjVHG7tjeFRMkiQC8BDo 7YY+dxH5apyru952xcu4HKEeOeb31WJhxa+HDiWhzbBR8vlUDocyy+41/LAbIET3VfPIuEwo mrDgt3xKw1INUzXVi+jENzIqy8yFX9FigKlo/QDAfg58qvCs//BgpBxu7PUKTPyDAgMBAAGj ggFHMIIBQzAMBgNVHRMBAf8EAjAAMFYGCWCGSAGG+EIBDQRJFkdUbyBnZXQgeW91ciBvd24g Y2VydGlmaWNhdGUgZm9yIEZSRUUgaGVhZCBvdmVyIHRvIGh0dHA6Ly93d3cuQ0FjZXJ0Lm9y ZzBABgNVHSUEOTA3BggrBgEFBQcDBAYIKwYBBQUHAwIGCisGAQQBgjcKAwQGCisGAQQBgjcK AwMGCWCGSAGG+EIEATAyBggrBgEFBQcBAQQmMCQwIgYIKwYBBQUHMAGGFmh0dHA6Ly9vY3Nw LmNhY2VydC5vcmcwZQYDVR0RBF4wXIEccGV0ZXJqZXJlbXlAb3B0dXNob21lLmNvbS5hdYEY cGV0ZXIuamVyZW15QGF1dWcub3JnLmF1gSJwZXRlci5qZXJlbXlAYWxjYXRlbC1sdWNlbnQu Y29tLmF1MA0GCSqGSIb3DQEBBQUAA4ICAQAXxWquW06hLqy4/mGkSaQCZpaeZ4ILLEA80TKi 7jSMVxnQzcjalox79LhWYBeIK7J+w5cfblD3o9lVvrwhSzDE3GmwKrz9aZIsNzD0LgTaQ6gv f7U1DWex02WwowMwG00AAcqXwC7ZbOyl1gaVgXQuaYjUyggCPq9n54IlYRAVAWE/JBFVwqNP JWdpDt7AMpa22UAJL+5rWaOde6SsUS55NTEQ7M32/xNCAFDwwO3rQ6ToEqpQUeoVyGnRdp+q oJFkKE/fnngWy8wP9RPV+yxfJ4OfsLcILnp66wROwSECySJGkppO4C4NApOyHa4sZx8Ui6XP A5EiICCCRIYJP3+sdlwgazfNu1lZ+/uHrajGgnpS7lGRZITa6hFcFJpoCHDjurPJWwPqdzpK 8wcSXeV05oEldK5FfOjzcaUd6mI/YLK3j4Ie7VQg1zB32shzM0Lk8iDLIAO+vKcBzi79dCjR Hr0lKLttEVfNUcqDhEHzDvQsc+IYc8C4KibGeS9kRcx136EYXYn4dNu8Rab6ELTyaORlEB2z jo9HcToNfO/jLwByiRAHefTyziljVqAv6PaaVFNcTtiCEzFwi/eJERNZ0A9RS0Q+yIrC+dC3 0Oz8TVUisJ4YOYJPVL1bVAzWVzf0IpIYPTixy9dpTItAY6BOTHzpcY/mCqiqoi36QXyCfDCC Bz0wggUloAMCAQICAQAwDQYJKoZIhvcNAQEEBQAweTEQMA4GA1UEChMHUm9vdCBDQTEeMBwG A1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25pbmcg QXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0QGNhY2VydC5vcmcwHhcNMDMwMzMw MTIyOTQ5WhcNMzMwMzI5MTIyOTQ5WjB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVo dHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3Jp dHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzCCAiIwDQYJKoZIhvcNAQEB BQADggIPADCCAgoCggIBAM4iwOJGfew2KAdQlvKgM0CMS/E7Zj8x5WsCNtvWfPbxiI9OdzYF QZX5CfASz0aGc2C3bn7owFhkrs2wrUUXDGP6Zwro1tK/PueYxPBM+uADuzVdbCHeniDZus1m Mjdy+vcI9cfNWMmO5w5e6j7+HKEUChVshoRbZGYqeqlLU3n1iKJ77i8KYSuNsn5NVqUT7Ora kp6sREEeWGBlBWb4wES9y5T3Qn4L92VomFEF8PMFkQQdGxeC7MhXu8NreojxsHLMJVsgkewW AhKPMukXGEjQxwUuAjBCuCWcBWs/qjqn61NI9+jStgeY3BvGNH9/yRyCegVYKwhb8ziiqxdd ZsmY154Qi6LS3XSa93EMcmDfzW+YM52WNHY+JHqSsA6VHm/moEU4R6rXQe1KtxL21xuDig8u 2Am2WdeqBP/Sk31oLt2LS6tYui+N6pWnoMNUiaX724tRIp2yw74RviyRhouWeK0g04ovGj/G 0FFlhyGxGQFlf0Uch/V80EFMTymYIf0zH3UMBFH6GXfb1BQc7oHDHfWYt2kGkSLdAFDMgTGs Egd7ONpoW+Yr1H7JX63o63JM8wHlSyC/mqZXypEAAYuhdSE3tWMNZz5GT3AgZ87F1lnbAuDw 0svNumK3kEHo3SDkKbxkKULIItx4mv9D7JgbCVFLWlrCcfHEy3Op5aELAgMBAAGjggHOMIIB yjAdBgNVHQ4EFgQUFrUyG9TH8+DmjvO90rA67rI5GNEwgaMGA1UdIwSBmzCBmIAUFrUyG9TH 8+DmjvO90rA67rI5GNGhfaR7MHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6 Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEh MB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnggEAMA8GA1UdEwEB/wQFMAMBAf8w MgYDVR0fBCswKTAnoCWgI4YhaHR0cHM6Ly93d3cuY2FjZXJ0Lm9yZy9yZXZva2UuY3JsMDAG CWCGSAGG+EIBBAQjFiFodHRwczovL3d3dy5jYWNlcnQub3JnL3Jldm9rZS5jcmwwNAYJYIZI AYb4QgEIBCcWJWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZy9pbmRleC5waHA/aWQ9MTAwVgYJYIZI AYb4QgENBEkWR1RvIGdldCB5b3VyIG93biBjZXJ0aWZpY2F0ZSBmb3IgRlJFRSBoZWFkIG92 ZXIgdG8gaHR0cDovL3d3dy5jYWNlcnQub3JnMA0GCSqGSIb3DQEBBAUAA4ICAQAox+6cggK6 XIASyjUKHYFviWqZzPJoD3+n4Y1YlT698gbDkFqstWD2mUMBo4hwnJ1inaSHr2dYDTA2O+at SNPLdAKGcT7iKwNo8TRiQEY7U+oo9Kz7ZpVTik1d/TvZYNfKeWk7sWWSpsaBglyczetNAYql 3xFVqhXKHzfAgphwYdtqfJajji5UPk8hqZDv3IK/3OhFrU2Qcwg8lGWwBJl2f+K8wmoVqpcE NyTYHpRObQ5RvtbEj8qWbfdD3+gwZSc7e7tDQ2PEQ/ey7GjM4RmOIvuY4XtaPgE3O4sIsKLz lU4ay5vNmrHbsnDwLUrb2LDjb0VIMxL//jwyKlT3xPeK8Igjwkf+ZHpxwNEepmOwB36kL9MB j9yfK7bGCKkPk0gl/BL9n0Lc88Q+9lew191p0QZ3NApL0sqg/xzGjMkWvsTMMjdoc18I+1H3 SVM2BQqVAkzyeRoQ9tg6dZzzHfGiDXBnhhuzFvUv5aTreYb5PQvCcwulmaxv/Ge45S8Lphgk jXvRSDUpGECsk2DhloZQtHpZ2I8hC5/PgpHGO79r3AeRuZdWI6q2bJTGSAY85M5OquT2Lwnc U28u/HTrOmOZwqasibynskSgDYoQ42zyJMv6m59wRy7eFIvUsiAJlqJk8SQc3KE1nBWy1LxV Ln0G9ZwOVfRa1pPadq0lc0zFQzGCAlwwggJYAgEBMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0Ex HjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWdu aW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMD984w CQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0wOTA3MDcwODE2NThaMCMGCSqGSIb3DQEJBDEWBBQff/T5YdDI4PS/n1cNdo48Y52rsjBS BgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASCAQArfqM2Bb1Z SNeIrKUVWEGKlO24Ay6W6CWTzdyH9VsQ4zqYivSH4h1iWVUz065ywPI64T3gW01NBW6X2Wwb 1IBaYgn77NLLbjRsKcPscZPlGqbV+xfwH3IgXeG/HEgc4SBBFUoqyLIu97BgijzidSPvXfp3 xu5uO5JwYUtx4rwax3Dg8hdOYo9wii1jTi37pshGodbKRJqmPgf06GztDe1zIgMbc2gFqdID EhBmPlya66GtsMyYXeqyUy8sk3SV6becQQnCY17Dt1jay1+7ofxUWk6VNN6n3SEq+WFXXiHP JcEjUnmuTHGZV4WmphWOpSgAhopdH7Peqk5aA+jt2p51 --W/nzBZO5zC0uMSeA-- From owner-freebsd-stable@FreeBSD.ORG Tue Jul 7 08:37:09 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 15707106564A for ; Tue, 7 Jul 2009 08:37:09 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id C3E9F8FC19 for ; Tue, 7 Jul 2009 08:37:08 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1MO6Ak-0007N1-Je for freebsd-stable@freebsd.org; Tue, 07 Jul 2009 08:37:06 +0000 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 07 Jul 2009 08:37:06 +0000 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 07 Jul 2009 08:37:06 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: Ivan Voras Date: Tue, 07 Jul 2009 10:36:57 +0200 Lines: 10 Message-ID: References: <0475D596F44442839D969C59B5E93F84@workstation> <42650195230C4DE4B7816F944EB3B464@workstation> <4A526693.5020401@andric.com> <785FFA80D58E4B5194F2DCFE15488903@workstation> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Thunderbird 2.0.0.21 (X11/20090615) In-Reply-To: <785FFA80D58E4B5194F2DCFE15488903@workstation> Sender: news Subject: Re: hw.realmem in stable. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2009 08:37:09 -0000 Amza Marian wrote: > > Thank you sir. > > Is there any solution for this issue ? (because applications does not > work correctly. - like mysql.) Why wouldn't MySQL work correctly? Does it inspect FreeBSD sysctls? (why would it, since you can configure its memory usage through its configuration files) From owner-freebsd-stable@FreeBSD.ORG Tue Jul 7 08:59:26 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E5AA5106566C for ; Tue, 7 Jul 2009 08:59:26 +0000 (UTC) (envelope-from petefrench@ticketswitch.com) Received: from constantine.ticketswitch.com (constantine.ticketswitch.com [IPv6:2002:57e0:1d4e:1::3]) by mx1.freebsd.org (Postfix) with ESMTP id ACE918FC0A for ; Tue, 7 Jul 2009 08:59:26 +0000 (UTC) (envelope-from petefrench@ticketswitch.com) Received: from dilbert.rattatosk ([10.64.50.6] helo=dilbert.ticketswitch.com) by constantine.ticketswitch.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MO6Vu-000Oof-K2; Tue, 07 Jul 2009 09:58:58 +0100 Received: from petefrench by dilbert.ticketswitch.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MO6Vu-000GSe-IB; Tue, 07 Jul 2009 09:58:58 +0100 To: dan@langille.org In-Reply-To: <4A529537.8070206@langille.org> Message-Id: From: Pete French Date: Tue, 07 Jul 2009 09:58:58 +0100 Cc: amarat@ksu.ru, freebsd-stable@freebsd.org, victor@bsdes.net Subject: Re: interrupt storm on MSI IXP600 based motherboards X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2009 08:59:27 -0000 > The problem returns: > Jul 6 20:12:10 polo kernel: interrupt storm detected on "irq22:"; > throttling interrupt source Six months is a long gap! I was hooinh the problem had gone away. I havent seen it on here since I started running 7.2-STABLE, and before that I made it go away by using a debug kernel. -pete. From owner-freebsd-stable@FreeBSD.ORG Tue Jul 7 09:25:00 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 55BEC106566C for ; Tue, 7 Jul 2009 09:25:00 +0000 (UTC) (envelope-from mail25@bzerk.org) Received: from ei.bzerk.org (tunnel490.ipv6.xs4all.nl [IPv6:2001:888:10:1ea::2]) by mx1.freebsd.org (Postfix) with ESMTP id BA28A8FC15 for ; Tue, 7 Jul 2009 09:24:59 +0000 (UTC) (envelope-from mail25@bzerk.org) Received: from ei.bzerk.org (BOFH@localhost [127.0.0.1]) by ei.bzerk.org (8.14.2/8.14.2) with ESMTP id n679OsDC092779; Tue, 7 Jul 2009 11:24:54 +0200 (CEST) (envelope-from mail25@bzerk.org) Received: (from bulk@localhost) by ei.bzerk.org (8.14.2/8.14.2/Submit) id n679OqaN092778; Tue, 7 Jul 2009 11:24:52 +0200 (CEST) (envelope-from mail25@bzerk.org) Date: Tue, 7 Jul 2009 11:24:51 +0200 From: Ruben de Groot To: "Rick C. Petty" Message-ID: <20090707092451.GA92743@ei.bzerk.org> Mail-Followup-To: Ruben de Groot , "Rick C. Petty" , FreeBSD Stable Mailing List References: <4A4E1E24.3020303@andric.com> <20090703152150.GE11039@hugo10.ka.punkt.de> <20090705003834.12211k8697td2o74@webmail.private.lan> <20090706073941.GA78371@ei.bzerk.org> <20090706074256.GD6306@hugo10.ka.punkt.de> <4A51B721.5020505@andric.com> <4A51B9FA.9010906@andric.com> <20090706093904.GA79434@ei.bzerk.org> <20090706212045.GA91095@keira.kiwi-computer.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090706212045.GA91095@keira.kiwi-computer.com> User-Agent: Mutt/1.4.2.3i X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on ei.bzerk.org X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0.1 (ei.bzerk.org [127.0.0.1]); Tue, 07 Jul 2009 11:24:57 +0200 (CEST) Cc: Ruben de Groot , FreeBSD Stable Mailing List Subject: Re: What is /boot/kernel/*.symbols? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2009 09:25:00 -0000 On Mon, Jul 06, 2009 at 04:20:45PM -0500, Rick C. Petty typed: > On Mon, Jul 06, 2009 at 11:39:04AM +0200, Ruben de Groot wrote: > > On Mon, Jul 06, 2009 at 10:46:50AM +0200, Dimitry Andric typed: > > > > > > Right, so it's a lot bigger on amd64. I guess those 64-bit pointers > > > aren't entirely free. :) > > > > I'm not sure where the size difference comes from. I have some sparc64 > > systems running -current with symbols and the size of /boot/kernel is > > more comparable to i386, even with the 8-byte pointer size: > > Um, probably there are a lot of devices on amd64 that aren't available for > sparc64? Yes, That's probably it. From owner-freebsd-stable@FreeBSD.ORG Tue Jul 7 09:51:08 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 889651065670 for ; Tue, 7 Jul 2009 09:51:08 +0000 (UTC) (envelope-from ianjhart@ntlworld.com) Received: from mtaout02-winn.ispmail.ntl.com (mtaout02-winn.ispmail.ntl.com [81.103.221.48]) by mx1.freebsd.org (Postfix) with ESMTP id 053678FC1C for ; Tue, 7 Jul 2009 09:51:07 +0000 (UTC) (envelope-from ianjhart@ntlworld.com) Received: from aamtaout01-winn.ispmail.ntl.com ([81.103.221.35]) by mtaout02-winn.ispmail.ntl.com (InterMail vM.7.08.04.00 201-2186-134-20080326) with ESMTP id <20090707095106.BDIY6611.mtaout02-winn.ispmail.ntl.com@aamtaout01-winn.ispmail.ntl.com> for ; Tue, 7 Jul 2009 10:51:06 +0100 Received: from cpc1-cove3-0-0-cust909.sol2.cable.ntl.com ([86.20.31.142]) by aamtaout01-winn.ispmail.ntl.com (InterMail vG.2.02.00.01 201-2161-120-102-20060912) with ESMTP id <20090707095106.RMWF13254.aamtaout01-winn.ispmail.ntl.com@cpc1-cove3-0-0-cust909.sol2.cable.ntl.com> for ; Tue, 7 Jul 2009 10:51:06 +0100 X-Virus-Scanned: amavisd-new at cpc2-cove3-0-0-cust311.sol2.cable.ntl.com Received: from localhost (localhost [127.0.0.1]) by cpc1-cove3-0-0-cust909.sol2.cable.ntl.com (8.14.3/8.14.3) with ESMTP id n679p3eK031360 for ; Tue, 7 Jul 2009 10:51:03 +0100 (BST) (envelope-from ianjhart@cpc1-cove3-0-0-cust909.sol2.cable.ntl.com) Received: from localhost (localhost [127.0.0.1]) by 10.248.192.16 (Horde Framework) with HTTP; Tue, 07 Jul 2009 10:51:03 +0100 Message-ID: <20090707105103.946813hdks2mra80@10.248.192.16> Date: Tue, 07 Jul 2009 10:51:03 +0100 From: Ian J Hart To: freebsd-stable@freebsd.org References: <20090703100627.197838cphjnil82s@10.248.192.16> <20090706200115.1411150frxepkbuo@webmail.private.lan> In-Reply-To: <20090706200115.1411150frxepkbuo@webmail.private.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) 4.3.3 / FreeBSD-7.2 X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on cpc1-cove3-0-0-cust909.sol2.cable.ntl.com X-Cloudmark-Analysis: v=1.0 c=1 a=NLZqzBF-AAAA:8 a=SqJks5JA5r34FEmSh80A:9 a=QNahSL-9qi7wLYiZnnYA:7 a=EQ2J-qoA6lNrSCd3ukVrfPpApugA:4 a=_dQi-Dcv4p4A:10 a=YVatAntiOeEYisNx:21 a=sA_10-0IDPlEuGJD:21 Subject: Re: trap 12 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2009 09:51:08 -0000 Quoting Ian J Hart : > Quoting Ian J Hart : > >> Is this likely to be hardware? Details will follow if not. >> >> [copied from a screen dump] >> >> Fatal trap 12: page fault while in kernel mode >> cpuid = 1; apic id = 01 >> fault virtual address = 0x0 >> fault code = supervisor write data, page not present >> instruction pointer = 0x8:0xffffffff807c6c12 >> stack pointer = 0x10:0xffffffff510e7890 >> frame pointer = 0x10:0xffffff00054a6c90 >> code segment = base 0x0, limit 0xfffff, type 0x1b >> = DPL 0, pres 1, long 1 def32 0, gran 1 >> processor eflags = interrupt enabled, resume, IOPL = 0 >> current process = 75372 (printf) >> trap number = 12 >> panic: page fault >> cpuid = 1 >> uptime: 8m2s >> Cannot dump. No dump device defined. >> >> > > [First attempt apparently went into a blackhole. Apologies in you > get this twice.] > > Some suggestions (off list) that it may not be hardware, so here's > the follow up. > > supermicro 5015b-mt (super X7SBi mobo) > Intel Q6600 > 8GB ECC DDR2 > 4x Seagate 320GB, two gmirror, two idle. > > issues so far > > 1 OK) 7.x doesn't boot without hw.ata.atapi_dma=0. Not recently tested. > 2 OK) disks enumerate differently 6.x to 7.x. Painful if you > hardwired the providor into your mirror. > 3) 6.3 and 7.2 remote dump over ssh fails with 'Disconnecting: > Corrupted MAC on input.' > 4) On 7.2 (AFAICT from logs) random reboots under load. e.g. the > above generated by a portupgrade run. > > I had dumpdev=none as I hadn't setup rc.early to allow savecore to work. > > In the interests of full disclosure I should say that this box was > migrated from older hardware and then source upgraded from i386 to > amd64 (6.3). Only one issue with that, format of accounting > file.Upgrade to 7.2 and a rebuild or two since then. > > This box is our email server and there's no load. An identical box > running as a gateway/firewall backup dumps okay and doesn't reboot. > That box does drop network connections when running a cvsup server > (treelist write), but when configured to pass through these > connections (using balance) runs okay. But that's a story for > another day as it's still on 6.x. > > Anyway, I put the two gmirror disks in another chassis and the > remote dumps are now completing.This at least does seem to be > hardware. > > Before I moved the two gmirror disks I synced a third disk. I can > now test (most of) the original hardware and software. > > I was unable to make this single disk system crash, so I added two > new disks and synced them.Now a 3 disk mirror, one disk idle. > > I've disabled sendmail and the email server so as not to clash. > > A portupgrade run caused a crash. I've setup coredumps so I can now > test. Remote backup dumps do fail. > > xmail# kldstat > Id Refs Address Size Name > 1 2 0xffffffff80100000 bd23e0 kernel > 2 1 0xffffffff80cd3000 20608 geom_mirror.ko > > I did have ipfw module loaded, but I got the crash without it so > I've removed it (firewall_type=OPEN). > > Ran crashinfo, now have much more info than I need ;) > > Starting another portupgrade run now to see how reproducable this is. > > Later BIOS waiting in USB floppy. > [snip dmesg] It took 2 runs of portupgrade -af.Some corruption in the dbs may have to pkg_delete -a. FreeBSD * 7.2-RELEASE-p1 FreeBSD 7.2-RELEASE-p1 #0: Tue Jun 16 18:03:10 BST 2009 *@*:/usr/obj/usr/src/sys/GENERIC amd64 panic: page fault GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"... Unread portion of the kernel message buffer: Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 01 fault virtual address = 0xfffffffff5555570 fault code = supervisor write data, page not present instruction pointer = 0x8:0xffffffff807c429b stack pointer = 0x10:0xffffffff511e4710 frame pointer = 0x10:0x20 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 69996 (mkdir) trap number = 12 panic: page fault cpuid = 1 Uptime: 19h16m41s Physical memory: 8177 MB Dumping 730 MB: 715 699 683 667 651 635 619 603 587 571 555 539 523 507 491 475 459 443 427 411 395 379 363 347 331 315 299 283 267 251 235 219 203 187 171 155 139 123 107 91 75 59 43 27 11 Reading symbols from /boot/kernel/geom_mirror.ko...Reading symbols from /boot/kernel/geom_mirror.ko.symbols...done. done. Loaded symbols for /boot/kernel/geom_mirror.ko #0 doadump () at pcpu.h:195 195 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump () at pcpu.h:195 #1 0x0000000000000004 in ?? () #2 0xffffffff8050df19 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418 #3 0xffffffff8050e322 in panic (fmt=0x104
) at /usr/src/sys/kern/kern_shutdown.c:574 #4 0xffffffff807d21f3 in trap_fatal (frame=0xffffff0005f94a50, eva=Variable "eva" is not available. ) at /usr/src/sys/amd64/amd64/trap.c:757 #5 0xffffffff807d25c5 in trap_pfault (frame=0xffffffff511e4660, usermode=0) at /usr/src/sys/amd64/amd64/trap.c:673 #6 0xffffffff807d2f04 in trap (frame=0xffffffff511e4660) at /usr/src/sys/amd64/amd64/trap.c:444 #7 0xffffffff807b706e in calltrap () at /usr/src/sys/amd64/amd64/exception.S:209 #8 0xffffffff807c429b in free_pv_entry (pmap=0xffffffff80b66c80, pv=Variable "pv" is not available. ) at /usr/src/sys/amd64/amd64/pmap.c:1905 #9 0xffffffff807c4403 in pmap_remove_entry (pmap=Variable "pmap" is not available. ) at /usr/src/sys/amd64/amd64/pmap.c:2131 #10 0xffffffff807c6447 in pmap_remove_pte (pmap=0xffffffff80b66c80, ptq=0xaaaaaaa8, va=18446744070506639360, ptepde=23601251, free=0xffffffff511e4790) at /usr/src/sys/amd64/amd64/pmap.c:2366 #11 0xffffffff807cab87 in pmap_remove (pmap=0xffffffff80b66c80, sva=18446744070506639360, eva=18446744070506909696) at /usr/src/sys/amd64/amd64/pmap.c:2510 #12 0xffffffff8073bf80 in vm_map_delete (map=0xffffff00016830f8, start=18446744070506639360, end=18446744070506909696) at /usr/src/sys/vm/vm_map.c:2400 #13 0xffffffff80739905 in kmem_free_wakeup (map=0xffffff00016830f8, addr=18446744070506639360, size=267264) at /usr/src/sys/vm/vm_kern.c:462 #14 0xffffffff804e648d in exec_free_args (args=0xffffffff511e4b00) at /usr/src/sys/kern/kern_exec.c:1098 #15 0xffffffff804e784a in kern_execve (td=0xffffff0005f94a50, args=0xffffffff511e4b00, mac_p=Variable "mac_p" is not available. ) at /usr/src/sys/kern/kern_exec.c:836 #16 0xffffffff804e7fd7 in execve (td=0xffffff0005f94a50, uap=Variable "uap" is not available. ) at /usr/src/sys/kern/kern_exec.c:202 #17 0xffffffff807d2847 in syscall (frame=0xffffffff511e4c80) at /usr/src/sys/amd64/amd64/trap.c:900 #18 0xffffffff807b727b in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:330 #19 0x00000008005044b0 in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) -- ian j hart ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From owner-freebsd-stable@FreeBSD.ORG Tue Jul 7 11:20:29 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5903E10656D2 for ; Tue, 7 Jul 2009 11:20:29 +0000 (UTC) (envelope-from tonix@interazioni.it) Received: from mx02.interazioni.net (mx02.interazioni.net [80.94.114.204]) by mx1.freebsd.org (Postfix) with ESMTP id 9E46B8FC13 for ; Tue, 7 Jul 2009 11:20:28 +0000 (UTC) (envelope-from tonix@interazioni.it) Received: (qmail 68394 invoked by uid 88); 7 Jul 2009 10:53:46 -0000 Received: from unknown (HELO ?192.168.56.198?) (tonix@interazioni.it@85.18.206.139) by relay.interazioni.net with ESMTPA; 7 Jul 2009 10:53:46 -0000 Message-ID: <4A532938.2020207@interazioni.it> Date: Tue, 07 Jul 2009 12:53:44 +0200 From: "Tonix (Antonio Nati)" User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Subject: CARP in standard kernel? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2009 11:20:29 -0000 I saw in the past requests for adding carp in standard kernel. As of today, is there any chance to have it in kernel, as loadable module? It would semplify a lot usage of freebsd-ipdate, instead of rebuilduing a custom kernel each time. Thanks, Tonino -- ------------------------------------------------------------ Inter@zioni Interazioni di Antonio Nati http://www.interazioni.it tonix@interazioni.it ------------------------------------------------------------ From owner-freebsd-stable@FreeBSD.ORG Tue Jul 7 11:59:35 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DBC77106564A for ; Tue, 7 Jul 2009 11:59:34 +0000 (UTC) (envelope-from matheusber@gmail.com) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.26]) by mx1.freebsd.org (Postfix) with ESMTP id 88CE78FC0A for ; Tue, 7 Jul 2009 11:59:34 +0000 (UTC) (envelope-from matheusber@gmail.com) Received: by qw-out-2122.google.com with SMTP id 5so1801237qwd.7 for ; Tue, 07 Jul 2009 04:59:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:received:received :message-id:in-reply-to:references:date:subject:from:to:user-agent :mime-version:content-type:content-transfer-encoding:x-priority :importance; bh=QwU0tlIotwsSJIzSbqH6Po70Pvt+UrHPpOItdYeVWr8=; b=v+fAW6dhsT6PI6L2Qhh1MvQLHOTF2dQCRFYl5sZ7zWCW+bf+qCHYLpg7cSeq0x6jqr nYAWxn3ympJWNo1F1FtZdzzP/ZH26kPuCGbFmNi7kBF5j3Xi7pWHsD4NgPzpcp0tnZsH r/DfbHYdHdfrRkxTFB8aH/X9cxs7vsnN1DK1M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:in-reply-to:references:date:subject:from:to :user-agent:mime-version:content-type:content-transfer-encoding :x-priority:importance; b=NxUm3aernFVEOQEOwHPXZi7MnQzdX99mI0eCPgn1v0LKjY2746G+yfJS91BUepLUvI jmndIGSDRhMTie242dgiSiCsbRxh8J/tTTn4sVLKWMC5DeLfFfchZKRMV9lvpilf7wCo jlEMFqPXGaebq24gSXugivbBIbmBARhtCkn6k= Received: by 10.224.28.145 with SMTP id m17mr6500820qac.214.1246967973906; Tue, 07 Jul 2009 04:59:33 -0700 (PDT) Received: from cygnus.homeunix.com ([189.71.105.194]) by mx.google.com with ESMTPS id 7sm8422747qwf.6.2009.07.07.04.59.32 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 07 Jul 2009 04:59:33 -0700 (PDT) Sender: Nenhum_de_Nos Received: by cygnus.homeunix.com (Postfix, from userid 80) id 55190B8083; Tue, 7 Jul 2009 08:59:28 -0300 (BRT) Received: from 189.92.196.33 (SquirrelMail authenticated user matheus) by cygnus.homeunix.com with HTTP; Tue, 7 Jul 2009 08:59:28 -0300 (BRT) Message-ID: <31e543efcd95f2d24d071467f4df04b4.squirrel@cygnus.homeunix.com> In-Reply-To: <4A532938.2020207@interazioni.it> References: <4A532938.2020207@interazioni.it> Date: Tue, 7 Jul 2009 08:59:28 -0300 (BRT) From: "Nenhum_de_Nos" To: freebsd-stable@freebsd.org User-Agent: SquirrelMail/1.4.15 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: Re: CARP in standard kernel? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2009 11:59:35 -0000 On Tue, July 7, 2009 07:53, Tonix (Antonio Nati) wrote: > I saw in the past requests for adding carp in standard kernel. > As of today, is there any chance to have it in kernel, as loadable module? > It would semplify a lot usage of freebsd-ipdate, instead of rebuilduing > a custom kernel each time. would be a great deal to me if I could have CARP and ALTQ built-in. no need to recompile, just use freebsd-update :) matheus -- We will call you cygnus, The God of balance you shall be A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? http://en.wikipedia.org/wiki/Posting_style From owner-freebsd-stable@FreeBSD.ORG Tue Jul 7 13:05:33 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9D23F1065670; Tue, 7 Jul 2009 13:05:33 +0000 (UTC) (envelope-from dan.naumov@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.245]) by mx1.freebsd.org (Postfix) with ESMTP id 437C18FC17; Tue, 7 Jul 2009 13:05:33 +0000 (UTC) (envelope-from dan.naumov@gmail.com) Received: by an-out-0708.google.com with SMTP id d14so2143326and.13 for ; Tue, 07 Jul 2009 06:05:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=4VFw8EIYibBP+4pIopo7fzEBovy4niRY34322hIHhnY=; b=icmMrqcFAgMFEreePBEvt3TDfhQGeqKspyl+wopNo2MP5GzPIiSgthJfgWxqPrWTVs MyalqoKfm73Aj2RX3vLgCJUkePaZcRk/685FtiLUq32+hNCNzhzhOBzhiqsupXj80q5+ /Zbh2aGBDN5HM/r2ChQjIsruOUQT+UoyFBWS0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=d2Cleo8hpj7whROhIMxNYExtz6x5kX6SphB1L3GgPLZDNQbOoMIwr0Y3+y1vYAvIV3 wGY3LAFVdyxd92R26DzNrGkCJ7OaFokUdnBIQ8k4b+6XKkRf+bbODaY/uSbATA39Kc4L id9Tvhw1VioGGB8WXM7p6VEMdrZrkazkgC+uM= MIME-Version: 1.0 Received: by 10.100.94.4 with SMTP id r4mr10507202anb.171.1246971932463; Tue, 07 Jul 2009 06:05:32 -0700 (PDT) In-Reply-To: <1246926782.11597.23.camel@bauer.cse.buffalo.edu> References: <1246926782.11597.23.camel@bauer.cse.buffalo.edu> Date: Tue, 7 Jul 2009 16:05:32 +0300 Message-ID: From: Dan Naumov To: Ken Smith Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current , freebsd-stable Subject: Re: FreeBSD 8.0-BETA1 Available X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2009 13:05:34 -0000 On Tue, Jul 7, 2009 at 3:33 AM, Ken Smith wrote: > Be careful if you have SCSI drives, more USB disks than just the memory > stick, etc - make sure /dev/da0 (or whatever you use) is the memory > stick. =A0Using this image for livefs based rescue mode is known to not > work, that is one of the things still being worked on. Hey Just wanted a small clarification, does livefs based rescue mode mean "fixit environment" or not? I would like to do some configuration testing with 8.0-beta1, but applying the configuration pretty much requires working in FIXIT, since sysinstall isn't exactly up to the task. - Sincerely, Dan Naumov From owner-freebsd-stable@FreeBSD.ORG Tue Jul 7 14:13:54 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5B4141065673 for ; Tue, 7 Jul 2009 14:13:54 +0000 (UTC) (envelope-from sagara@tomahawk.com.sg) Received: from us1.tomahawkonline.net (us1.tomahawkonline.net [66.98.178.56]) by mx1.freebsd.org (Postfix) with SMTP id 20D5D8FC18 for ; Tue, 7 Jul 2009 14:13:53 +0000 (UTC) (envelope-from sagara@tomahawk.com.sg) Received: (qmail 23014 invoked by alias); 7 Jul 2009 10:55:50 -0000 Message-ID: <20090707105550.23013.qmail@us1.tomahawkonline.net> References: <1246926782.11597.23.camel@bauer.cse.buffalo.edu> In-Reply-To: <1246926782.11597.23.camel@bauer.cse.buffalo.edu> From: "Sagara Wijetunga" To: Ken Smith Date: Tue, 07 Jul 2009 05:55:50 -0500 Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current , freebsd-stable Subject: Re: FreeBSD 8.0-BETA1 Available X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2009 14:13:54 -0000 Ken Smith writes: > > The first public test build of the FreeBSD 8.0-RELEASE test cycle is now > available, 8.0-BETA1. Through the next week or so more information > about the release will be posted but here is the current target schedule > for the other 'major events': > > BETA2: July 13, 2009 > BETA3: July 20, 2009 > RC1: July 27, 2009 > RC2: August 17, 2009 > RELEASE:August 31, 2009 > Hi all Congratulations! This is a very good news though we did not expect FreeBSD 8.0 this soon. We planed our Tomahawk Desktop 3.0 to be based on FreeBSD 8.0. Now days we are very busy finalising the Tomahawk Desktop 2.0 beta to be released somewhere in August. Will sure give FreeBSD 8.0 a try after we released our 2.0 beta. We wish good luck to FreeBSD 8.0 team. Best regards Sagara From owner-freebsd-stable@FreeBSD.ORG Tue Jul 7 14:18:02 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 91D711065676 for ; Tue, 7 Jul 2009 14:18:02 +0000 (UTC) (envelope-from petefrench@ticketswitch.com) Received: from constantine.ticketswitch.com (constantine.ticketswitch.com [IPv6:2002:57e0:1d4e:1::3]) by mx1.freebsd.org (Postfix) with ESMTP id 58EDA8FC14 for ; Tue, 7 Jul 2009 14:18:02 +0000 (UTC) (envelope-from petefrench@ticketswitch.com) Received: from dilbert.rattatosk ([10.64.50.6] helo=dilbert.ticketswitch.com) by constantine.ticketswitch.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MOBUa-0002zb-Cs; Tue, 07 Jul 2009 15:17:56 +0100 Received: from petefrench by dilbert.ticketswitch.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MOBUa-0000Ns-Br; Tue, 07 Jul 2009 15:17:56 +0100 To: dan@langille.org, petefrench@ticketswitch.com Message-Id: From: Pete French Date: Tue, 07 Jul 2009 15:17:56 +0100 Cc: amarat@ksu.ru, freebsd-stable@freebsd.org, victor@bsdes.net Subject: Re: interrupt storm on MSI IXP600 based motherboards X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2009 14:18:02 -0000 Oh FFS! This morning I sent the following email.. > Six months is a long gap! I was hooinh the problem had gone away. I > havent seen it on here since I started running 7.2-STABLE, and > before that I made it go away by using a debug kernel. ...and within an hour of typing that I also started seeing these messages again for the first time in 6 months! That's one hell of a co-inicdence. Surely it cant be date related ? -pete. From owner-freebsd-stable@FreeBSD.ORG Tue Jul 7 16:09:29 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B64121065698 for ; Tue, 7 Jul 2009 16:09:29 +0000 (UTC) (envelope-from rick@kiwi-computer.com) Received: from hamlet.setfilepointer.com (hamlet.SetFilePointer.com [63.224.10.2]) by mx1.freebsd.org (Postfix) with SMTP id 5BC6D8FC08 for ; Tue, 7 Jul 2009 16:09:28 +0000 (UTC) (envelope-from rick@kiwi-computer.com) Received: (qmail 77155 invoked from network); 7 Jul 2009 11:09:28 -0500 Received: from keira.kiwi-computer.com (HELO kiwi-computer.com) (63.224.10.3) by hamlet.setfilepointer.com with SMTP; 7 Jul 2009 11:09:28 -0500 Received: (qmail 1734 invoked by uid 2001); 7 Jul 2009 16:09:28 -0000 Date: Tue, 7 Jul 2009 11:09:28 -0500 From: "Rick C. Petty" To: Ruben de Groot , FreeBSD Stable Mailing List Message-ID: <20090707160928.GA1662@keira.kiwi-computer.com> References: <20090703152150.GE11039@hugo10.ka.punkt.de> <20090705003834.12211k8697td2o74@webmail.private.lan> <20090706073941.GA78371@ei.bzerk.org> <20090706074256.GD6306@hugo10.ka.punkt.de> <4A51B721.5020505@andric.com> <4A51B9FA.9010906@andric.com> <20090706093904.GA79434@ei.bzerk.org> <20090706212045.GA91095@keira.kiwi-computer.com> <20090707092451.GA92743@ei.bzerk.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090707092451.GA92743@ei.bzerk.org> User-Agent: Mutt/1.4.2.3i Cc: Subject: Re: What is /boot/kernel/*.symbols? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rick-freebsd2008@kiwi-computer.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2009 16:09:30 -0000 On Tue, Jul 07, 2009 at 11:24:51AM +0200, Ruben de Groot wrote: > On Mon, Jul 06, 2009 at 04:20:45PM -0500, Rick C. Petty typed: > > On Mon, Jul 06, 2009 at 11:39:04AM +0200, Ruben de Groot wrote: > > > On Mon, Jul 06, 2009 at 10:46:50AM +0200, Dimitry Andric typed: > > > > > > > > Right, so it's a lot bigger on amd64. I guess those 64-bit pointers > > > > aren't entirely free. :) > > > > > > I'm not sure where the size difference comes from. I have some sparc64 > > > systems running -current with symbols and the size of /boot/kernel is > > > more comparable to i386, even with the 8-byte pointer size: > > > > Um, probably there are a lot of devices on amd64 that aren't available for > > sparc64? > > Yes, That's probably it. It was just a theory; I don't have sparc64. What's your output of "ls -1 /boot/kernel | wc"? -- Rick C. Petty From owner-freebsd-stable@FreeBSD.ORG Tue Jul 7 16:29:26 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3825F106566C for ; Tue, 7 Jul 2009 16:29:26 +0000 (UTC) (envelope-from dan.naumov@gmail.com) Received: from mail-gx0-f210.google.com (mail-gx0-f210.google.com [209.85.217.210]) by mx1.freebsd.org (Postfix) with ESMTP id E13218FC17 for ; Tue, 7 Jul 2009 16:29:25 +0000 (UTC) (envelope-from dan.naumov@gmail.com) Received: by gxk6 with SMTP id 6so5450773gxk.19 for ; Tue, 07 Jul 2009 09:29:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=2/V75nhWTIMaAHbpBrmJ6P31+jVBidwCjkBZj1C1ySM=; b=FzROZLh19rNFj7E+pXQ9MzfTaNKd/yMvY7JwRs1Pmm9cQ77ZgUsQWlrBSSAy1DXZjt dNFLIWahQdup+gMI3+SPpL2ua8uP7sdzI2GJIbcG3t/0hH7DaZkCnF0Ucmfqe+pwZXsu 6gmfrJo3hi2YIIfX19PCfo7MFD2qF+enwSg7A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=RgubLCTNCBFUgA63r5WeXYx/HAzY7UGlMQx4TbUI/2QmXaeX8xdrLT08XhbHLKcBE3 hETGC88BYxJxUXbnIKND7fuV/6lcaVxgnEUViJtfk1LCt9wciiG4DST6Km5YX7WMoz+k uz9tnIgOUSAA6kY+g4Rghg3O3y1UTD+PpzixE= MIME-Version: 1.0 Received: by 10.100.92.2 with SMTP id p2mr10996830anb.7.1246984165278; Tue, 07 Jul 2009 09:29:25 -0700 (PDT) In-Reply-To: <20090707160928.GA1662@keira.kiwi-computer.com> References: <20090703152150.GE11039@hugo10.ka.punkt.de> <20090706073941.GA78371@ei.bzerk.org> <20090706074256.GD6306@hugo10.ka.punkt.de> <4A51B721.5020505@andric.com> <4A51B9FA.9010906@andric.com> <20090706093904.GA79434@ei.bzerk.org> <20090706212045.GA91095@keira.kiwi-computer.com> <20090707092451.GA92743@ei.bzerk.org> <20090707160928.GA1662@keira.kiwi-computer.com> Date: Tue, 7 Jul 2009 19:29:24 +0300 Message-ID: From: Dan Naumov To: rick-freebsd2008@kiwi-computer.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Ruben de Groot , FreeBSD Stable Mailing List Subject: Re: What is /boot/kernel/*.symbols? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2009 16:29:26 -0000 On Tue, Jul 7, 2009 at 7:09 PM, Rick C. Petty wrote: > On Tue, Jul 07, 2009 at 11:24:51AM +0200, Ruben de Groot wrote: >> On Mon, Jul 06, 2009 at 04:20:45PM -0500, Rick C. Petty typed: >> > On Mon, Jul 06, 2009 at 11:39:04AM +0200, Ruben de Groot wrote: >> > > On Mon, Jul 06, 2009 at 10:46:50AM +0200, Dimitry Andric typed: >> > > > >> > > > Right, so it's a lot bigger on amd64. =A0I guess those 64-bit poin= ters >> > > > aren't entirely free. :) >> > > >> > > I'm not sure where the size difference comes from. I have some sparc= 64 >> > > systems running -current with symbols and the size of /boot/kernel i= s >> > > more comparable to i386, even with the 8-byte pointer size: >> > >> > Um, probably there are a lot of devices on amd64 that aren't available= for >> > sparc64? >> >> Yes, That's probably it. > > It was just a theory; I don't have sparc64. =A0What's your output of > "ls -1 /boot/kernel | wc"? > > -- Rick C. Petty atom# uname -a FreeBSD atom.localdomain 7.2-RELEASE-p2 FreeBSD 7.2-RELEASE-p2 #0: Wed Jun 24 00:14:35 UTC 2009 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 atom# ls -1 /boot/kernel | wc 1011 1011 15243 - Sincerely, Dan Naumov From owner-freebsd-stable@FreeBSD.ORG Tue Jul 7 16:45:34 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1357C106564A for ; Tue, 7 Jul 2009 16:45:34 +0000 (UTC) (envelope-from sulfurfff@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.251]) by mx1.freebsd.org (Postfix) with ESMTP id BBEEA8FC18 for ; Tue, 7 Jul 2009 16:45:33 +0000 (UTC) (envelope-from sulfurfff@gmail.com) Received: by an-out-0708.google.com with SMTP id d14so2211683and.13 for ; Tue, 07 Jul 2009 09:45:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=7pTU8OkhbUPeqVeTay3o91VikTTAkqIYRiEXw2bdD9E=; b=dVQqvKPWhP1CrKcezcWrcYyGyBX2bi95HVfGkagV3LehJgeweX8OBNzT6wRreSbZjP n8u5BljljQFY/gYAfC1mfViSik/SPN+ca6XU3NC3MyMlAFwPPTSmsMj2oenk2o0yNVlT oWCL8+xMVDwOg3jjXwRtQh6njRb+571h7DT/o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=uyD/We81IXEAAqycEm/90WEtDAjt4TuLyeo+Zufe6ufljCm1uWYqeNojKnSQOtSwY3 F48oBMLaheLQM9lBmG68JRImOG80bGXozyMkj/E4/9oX2A5prioF1l4dS8bjtEj4wf7g 5XH8XXsG/pIUH1Xahxqs+Jnjb2Nshv9/HQgFA= MIME-Version: 1.0 Received: by 10.100.229.14 with SMTP id b14mr10858212anh.187.1246985132455; Tue, 07 Jul 2009 09:45:32 -0700 (PDT) In-Reply-To: <4A52ED7F.5030904@kkip.pl> References: <4A523185.90007@smo.de> <4A52ED7F.5030904@kkip.pl> Date: Tue, 7 Jul 2009 11:45:30 -0500 Message-ID: From: "Ishmael F.E." To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: upgrading ports without recompiling X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2009 16:45:34 -0000 portupgrade -aPP seems to have worked, thougth I got LOTS of warnings and plenty of packages weren't upgraded to the latest version (like gstreamer* which latest version seems to be 0.10.22 but I still have 0.10.20 as dependency for pidgin) . As for compiling, I think it's not worth unless the OS is being twicked which is not the case for me at this moment. . Tanks for your help . . 2009/7/7 Bartosz Stec > CmdLnKid pisze: > > On Mon, 6 Jul 2009 13:16 -0000, pj wrote: > > Ishmael F.E. wrote: > [...] > > . > so, =BFhow can I upgrade the ports? > unfortunatley I don't have time to compile my 64bit system > > You don't need to compile whole OS to compile ports, if this is what you > had in mind. > > > Have you looked at the -PP option of portupgrade? > I don't know how portmaster handles upgrades using packages only. > > > You could look into devel/ccache & devel/distcc if you would like to spee= d > up your compile times. Of course your first compile will always be the > slowest one but everyone after that will be faster. This is not always > advised as a good solution and has been known to throw some pretty weird > compiler bugs and also fail while compiling certain ports but that is > tweakable through /etc/make.conf*. > > Well, I heard about some problems with ccache, although I personally > experienced only one of them - fail when building world on AMD64. Here's = my > make.conf, feel free to give it try after installing ccache (Try to set > MAKEOPTS =3D CPU cores +1, and set appropriate CPUTYPE): > > CPUTYPE=3Dathlon64 > MAKEOPTS=3D-j3 > > # USE CCACHE > .if !defined(NOCCACHE) > CC=3D/usr/local/libexec/ccache/world-cc > CXX=3D/usr/local/libexec/ccache/world-c++ > .endif > > # default build settings for ports collection > .if ${.CURDIR:M*/ports/*} > CFLAGS=3D -O2 -fno-strict-aliasing -pipe -funroll-loops -fomit-frame-poin= ter > CXXFLAGS=3D -O2 -fno-strict-aliasing -pipe -funroll-loops > .endif > > # default build settings for base system > .if ${.CURDIR:M*/usr/src/*} || ${.CURDIR:M*/usr/obj/*} > CFLAGS=3D-O2 -fno-strict-aliasing -pipe > COPTFLAGS=3D-O2 -fno-strict-aliasing -pipe > CXXFLAGS=3D${CFLAGS} > .endif > > In case of any problem with specific port (or world) type in shell: > > # setenv NOCCACHE > > before build. This should give you maximum compile speed in case when > package is unavailable while using portupgrade -afP > > -- > Bartosz Stec > > > --=20 [=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D] [En muchos lugares, tomar fotos es visto como] [una costumbre vil y reprensible ] [=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D] From owner-freebsd-stable@FreeBSD.ORG Tue Jul 7 18:07:49 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5E0A0106566C; Tue, 7 Jul 2009 18:07:49 +0000 (UTC) (envelope-from kensmith@cse.Buffalo.EDU) Received: from phoebe.cse.buffalo.edu (phoebe.cse.buffalo.edu [128.205.32.89]) by mx1.freebsd.org (Postfix) with ESMTP id 0C9098FC15; Tue, 7 Jul 2009 18:07:48 +0000 (UTC) (envelope-from kensmith@cse.Buffalo.EDU) Received: from [128.205.32.76] (bauer.cse.buffalo.edu [128.205.32.76]) (authenticated bits=0) by phoebe.cse.buffalo.edu (8.14.1/8.13.7) with ESMTP id n67I7kAH094219 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 7 Jul 2009 14:07:48 -0400 (EDT) (envelope-from kensmith@cse.buffalo.edu) From: Ken Smith To: Dan Naumov In-Reply-To: References: <1246926782.11597.23.camel@bauer.cse.buffalo.edu> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-7MsKdWumJEgDal7C3gEE" Organization: U. Buffalo CSE Department Date: Tue, 07 Jul 2009 14:07:43 -0400 Message-Id: <1246990063.25765.18.camel@bauer.cse.buffalo.edu> Mime-Version: 1.0 X-Mailer: Evolution 2.24.5 FreeBSD GNOME Team Port X-DCC-Buffalo.EDU-Metrics: phoebe.cse.buffalo.edu 1336; Body=0 Fuz1=0 Fuz2=0 Cc: freebsd-current , freebsd-stable Subject: Re: FreeBSD 8.0-BETA1 Available X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2009 18:07:49 -0000 --=-7MsKdWumJEgDal7C3gEE Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2009-07-07 at 16:05 +0300, Dan Naumov wrote: > Just wanted a small clarification, does livefs based rescue mode mean > "fixit environment" or not? Yes, that's what it means. It's known to not work at the moment but it's being worked on. I wanted to mention that because it might have been confusing given what I put onto it (the files needed for livefs mode are on it, sysinstall itself needs a bit more work though). But once that is working this is my guess as to what people would find most useful on such an image so I wanted to give people a feel for roughly how big they'll wind up being. It will basically be the dvd minus packages. --=20 Ken Smith - From there to here, from here to | kensmith@cse.buffalo.edu there, funny things are everywhere. | - Theodore Geisel | --=-7MsKdWumJEgDal7C3gEE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEABECAAYFAkpTjuYACgkQ/G14VSmup/YI9ACghcxZFClQEx81cwrAoe/0Kz5K 0PgAn3ZksuFDlEya68HbFnMnc3vcepZb =/yqg -----END PGP SIGNATURE----- --=-7MsKdWumJEgDal7C3gEE-- From owner-freebsd-stable@FreeBSD.ORG Tue Jul 7 20:22:56 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A66CA1065672 for ; Tue, 7 Jul 2009 20:22:56 +0000 (UTC) (envelope-from mahlon@martini.nu) Received: from martini.nu (martini.nu [198.145.180.83]) by mx1.freebsd.org (Postfix) with SMTP id 779858FC1A for ; Tue, 7 Jul 2009 20:22:56 +0000 (UTC) (envelope-from mahlon@martini.nu) Received: (qmail 99381 invoked by uid 1000); 7 Jul 2009 19:56:14 -0000 Date: Tue, 7 Jul 2009 12:56:14 -0700 From: "Mahlon E. Smith" To: freebsd-stable@freebsd.org Message-ID: <20090707195614.GA24326@martini.nu> Mail-Followup-To: "Mahlon E. Smith" , freebsd-stable@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="6c2NcOVqGQ03X4Wi" Content-Disposition: inline X-GPG-Fingerprint: 19B8 DDB3 0156 3A03 FA80 8278 C0BE 6BFB 3606 B267 X-Sysinfo: FreeBSD 7.0-RELEASE-p1 i386 User-Agent: Mutt/1.5.17 (2007-11-01) Subject: ZFS: drive replacement performance X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2009 20:22:56 -0000 --6c2NcOVqGQ03X4Wi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I've got a 9 sata drive raidz1 array, started at version 6, upgraded to version 13. I had an apparent drive failure, and then at some point, a kernel panic (unrelated to ZFS.) The reboot caused the device numbers to shuffle, so I did an 'export/import' to re-read the metadata and get the array back up. Once I swapped drives, I issued a 'zpool replace'. That was 4 days ago now. The progress in a 'zpool status' looks like this, as of right now: scrub: resilver in progress for 0h0m, 0.00% done, 2251h0m to go =2E.. which is a little concerning, since a) it appears to have not moved since I started it, and b) I'm in a DEGRADED state until it finishes... if it finishes. So, I reach out to the list! - Is the resilver progress notification in a known weird state under FreeBSD? - Anything I can do to kick this in the pants? Tuning params? - This was my first drive failure under ZFS -- anything I should have done differently? Such as NOT doing the export/import? (Not sure what else I could have done there.) Some additional info is below. Drives are at about 20% busy, according to vmstat. Seem to have bandwidth to spare. This is a FreeBSD 7.2-STABLE system from the end of May -- 32 bit, 2G of RAM. I have the luxury of this being a test machine (for exactly stuff like this), so I'm willing to try whatever without worrying about production data or SLA. :) -- Mahlon E. Smith =20 http://www.martini.nu/contact.html ----------------------------------------------------------------------- % zfs list store NAME USED AVAIL REFER MOUNTPOINT store 1.22T 2.36T 32.0K none ----------------------------------------------------------------------- % cat /boot/loader.conf vm.kmem_size_max=3D"768M" vm.kmem_size=3D"768M" vfs.zfs.arc_max=3D"256M" ----------------------------------------------------------------------- % zpool status store pool: store state: DEGRADED status: One or more devices is currently being resilvered. The pool will continue to function, possibly in a degraded state. action: Wait for the resilver to complete. scrub: resilver in progress for 0h0m, 0.00% done, 2251h0m to go config: NAME STATE READ WRITE CKSUM store DEGRADED 0 0 0 raidz1 DEGRADED 0 0 0 da0 ONLINE 0 0 0 274K resilve= red da1 ONLINE 0 0 0 282K resilve= red replacing DEGRADED 0 0 0 2025342973333799752 UNAVAIL 3 4.11K 0 was /dev/da2 da8 ONLINE 0 0 0 418K resilve= red da2 ONLINE 0 0 0 280K resilve= red da3 ONLINE 0 0 0 269K resilve= red da4 ONLINE 0 0 0 266K resilve= red da5 ONLINE 0 0 0 270K resilve= red da6 ONLINE 0 0 0 270K resilve= red da7 ONLINE 0 0 0 267K resilve= red errors: No known data errors ----------------------------------------------------------------------- % zpool iostat -v capacity operations bandwidth pool used avail read write read write ------------------------- ----- ----- ----- ----- ----- ----- store 1.37T 2.72T 49 106 138K 543K raidz1 1.37T 2.72T 49 106 138K 543K da0 - - 15 62 1017K 79.9K da1 - - 15 62 1020K 80.3K replacing - - 0 103 0 88.3K 2025342973333799752 - - 0 0 1.45K 261 da8 - - 0 79 1.45K 98.2K da2 - - 14 62 948K 80.3K da3 - - 13 62 894K 80.0K da4 - - 14 63 942K 80.3K da5 - - 15 62 992K 80.4K da6 - - 15 62 1000K 80.1K da7 - - 15 62 1022K 80.1K ------------------------- ----- ----- ----- ----- ----- ----- --6c2NcOVqGQ03X4Wi Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- iD8DBQFKU6he1bsjBDapbeMRAutpAJ9RSF4mSydmeAO9GXtBM8n0FSNgKgCeMjgl nsDg01FjPMgEQX1XBqxbDPc= =wCV4 -----END PGP SIGNATURE----- --6c2NcOVqGQ03X4Wi-- From owner-freebsd-stable@FreeBSD.ORG Tue Jul 7 20:54:02 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 976431065672 for ; Tue, 7 Jul 2009 20:54:02 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-yx0-f181.google.com (mail-yx0-f181.google.com [209.85.210.181]) by mx1.freebsd.org (Postfix) with ESMTP id 4B6D08FC41 for ; Tue, 7 Jul 2009 20:54:02 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: by yxe11 with SMTP id 11so7316268yxe.3 for ; Tue, 07 Jul 2009 13:54:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=our+FETW1sfuYiMVCafbkOyVZ8OIUUYp46XvY2VLDuQ=; b=WfLM/UplZknQE6pHguoMEoLY+xnbEfRSFR5ou1aJVs0xYeyxIVNVVWjj7fdFZK/OMf f2kq6bfPDLG2lOxZxIsQxgvMEUw892x74kJQHbDSNfKcDGdC5V9M1HBuYuTkl1QGbGxr 2J1UmjD9Lx7jzcNQEOGDFXE0ZO+x+5dfwYdBo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=pE14euKv5nykihnxUlEUYifHqFizh8c3YhD/UzyGahqgfP2iDDOghxJBeyDSAwSweo uzV6bBKPjG/3Zej2q20epeQZ+cZGXJBbC6jqCEJCWGT1ZYnQr+tPjeRn34wd0AwhLbUl wzB2eFW9K95buPypdtOPM5dDOZv3Mz047opEQ= MIME-Version: 1.0 Received: by 10.151.111.19 with SMTP id o19mr598138ybm.6.1247000041689; Tue, 07 Jul 2009 13:54:01 -0700 (PDT) In-Reply-To: <20090707195614.GA24326@martini.nu> References: <20090707195614.GA24326@martini.nu> Date: Tue, 7 Jul 2009 13:54:01 -0700 Message-ID: From: Freddie Cash To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: ZFS: drive replacement performance X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2009 20:54:02 -0000 On Tue, Jul 7, 2009 at 12:56 PM, Mahlon E. Smith wrote: > I've got a 9 sata drive raidz1 array, started at version 6, upgraded to > version 13. I had an apparent drive failure, and then at some point, a > kernel panic (unrelated to ZFS.) The reboot caused the device numbers > to shuffle, so I did an 'export/import' to re-read the metadata and get > the array back up. > This is why we've started using glabel(8) to label our drives, and then add the labels to the pool: # zpool create store raidz1 label/disk01 label/disk02 label/disk03 That way, it does matter where the kernel detects the drives or what the physical device node is called, GEOM picks up the label, and ZFS uses the label. > Once I swapped drives, I issued a 'zpool replace'. > See comment at the end: what's the replace command that you used? > > That was 4 days ago now. The progress in a 'zpool status' looks like > this, as of right now: > > scrub: resilver in progress for 0h0m, 0.00% done, 2251h0m to go > > ... which is a little concerning, since a) it appears to have not moved > since I started it, and b) I'm in a DEGRADED state until it finishes... > if it finishes. > There's something wrong here. It definitely should be incrementing. Even when we did the foolish thing of creating a 24-drive raidz2 vdev and had to replace a drive, the progress bar did change. Never got above 39% as it kept restarting, but it did increment. > > So, I reach out to the list! > > - Is the resilver progress notification in a known weird state under > FreeBSD? > > - Anything I can do to kick this in the pants? Tuning params? > I'd redo the replace command, and check the output of "zpool status" to make sure it's showing the proper device node and not some random string of numbers like it is. > - This was my first drive failure under ZFS -- anything I should have > done differently? Such as NOT doing the export/import? (Not sure > what else I could have done there.) > If you knew which drive it was, I'd have shutdown the server and replaced it, so that the drives came back up renumbered correctly. This happened to us once when I was playing around with simulating dead drives (pulling drives) and rebooting. That's when I moved over to using glabels. % zpool status store > pool: store > state: DEGRADED > status: One or more devices is currently being resilvered. The pool will > continue to function, possibly in a degraded state. > action: Wait for the resilver to complete. > scrub: resilver in progress for 0h0m, 0.00% done, 2251h0m to go > config: > > NAME STATE READ WRITE CKSUM > store DEGRADED 0 0 0 > raidz1 DEGRADED 0 0 0 > da0 ONLINE 0 0 0 274K > resilvered > da1 ONLINE 0 0 0 282K > resilvered > replacing DEGRADED 0 0 0 > 2025342973333799752 UNAVAIL 3 4.11K 0 was /dev/da2 > da8 ONLINE 0 0 0 418K > resilvered > da2 ONLINE 0 0 0 280K > resilvered > da3 ONLINE 0 0 0 269K > resilvered > da4 ONLINE 0 0 0 266K > resilvered > da5 ONLINE 0 0 0 270K > resilvered > da6 ONLINE 0 0 0 270K > resilvered > da7 ONLINE 0 0 0 267K > resilvered > > errors: No known data errors > > > ----------------------------------------------------------------------- > > > % zpool iostat -v > capacity operations bandwidth > pool used avail read write read write > ------------------------- ----- ----- ----- ----- ----- ----- > store 1.37T 2.72T 49 106 138K 543K > raidz1 1.37T 2.72T 49 106 138K 543K > da0 - - 15 62 1017K 79.9K > da1 - - 15 62 1020K 80.3K > replacing - - 0 103 0 88.3K > 2025342973333799752 - - 0 0 1.45K 261 > da8 - - 0 79 1.45K 98.2K > da2 - - 14 62 948K 80.3K > da3 - - 13 62 894K 80.0K > da4 - - 14 63 942K 80.3K > da5 - - 15 62 992K 80.4K > da6 - - 15 62 1000K 80.1K > da7 - - 15 62 1022K 80.1K > ------------------------- ----- ----- ----- ----- ----- ----- > That definitely doesn't look right. It should be showing the device name there in the "replacing" section. What's the exact "zpool replace" command that you used? -- Freddie Cash fjwcash@gmail.com From owner-freebsd-stable@FreeBSD.ORG Tue Jul 7 21:17:36 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 34BD0106564A for ; Tue, 7 Jul 2009 21:17:36 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (lor.one-eyed-alien.net [69.66.77.232]) by mx1.freebsd.org (Postfix) with ESMTP id C8B6B8FC12 for ; Tue, 7 Jul 2009 21:17:35 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.14.3/8.14.3) with ESMTP id n67Krwtk010945; Tue, 7 Jul 2009 15:53:58 -0500 (CDT) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.14.3/8.14.3/Submit) id n67Krwn8010944; Tue, 7 Jul 2009 15:53:58 -0500 (CDT) (envelope-from brooks) Date: Tue, 7 Jul 2009 15:53:58 -0500 From: Brooks Davis To: "Mahlon E. Smith" , freebsd-stable@freebsd.org Message-ID: <20090707205357.GA2415@lor.one-eyed-alien.net> References: <20090707195614.GA24326@martini.nu> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="wRRV7LY7NUeQGEoC" Content-Disposition: inline In-Reply-To: <20090707195614.GA24326@martini.nu> User-Agent: Mutt/1.5.17 (2007-11-01) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (lor.one-eyed-alien.net [127.0.0.1]); Tue, 07 Jul 2009 15:53:58 -0500 (CDT) Cc: Subject: Re: ZFS: drive replacement performance X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2009 21:17:36 -0000 --wRRV7LY7NUeQGEoC Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jul 07, 2009 at 12:56:14PM -0700, Mahlon E. Smith wrote: >=20 > I've got a 9 sata drive raidz1 array, started at version 6, upgraded to > version 13. I had an apparent drive failure, and then at some point, a > kernel panic (unrelated to ZFS.) The reboot caused the device numbers > to shuffle, so I did an 'export/import' to re-read the metadata and get > the array back up. >=20 > Once I swapped drives, I issued a 'zpool replace'. >=20 > That was 4 days ago now. The progress in a 'zpool status' looks like > this, as of right now: >=20 > scrub: resilver in progress for 0h0m, 0.00% done, 2251h0m to go >=20 > ... which is a little concerning, since a) it appears to have not moved > since I started it, and b) I'm in a DEGRADED state until it finishes... > if it finishes. >=20 > So, I reach out to the list! >=20 > - Is the resilver progress notification in a known weird state under > FreeBSD? >=20 > - Anything I can do to kick this in the pants? Tuning params? >=20 > - This was my first drive failure under ZFS -- anything I should have > done differently? Such as NOT doing the export/import? (Not sure > what else I could have done there.) I'm seeing essentially the same think on an 8.0-BETA1 box with an 8-disk raidz1 pool. Every once in a while the system makes it to 0.05% done and gives a vaguely reasonable rebuild time, but it quickly drops back to reports 0.00% and it's basically not making any forward progress. In my case this is a copy of a mirror so while it would be a bit annoying to rebuild, the system could be rebuilt fairly easily. On thing I did just notice is that my zpool version is 13, but my file systems are all v1 rather than the latest (v3). I don't know if this is relevant or not. -- Brooks --wRRV7LY7NUeQGEoC Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iD8DBQFKU7XlXY6L6fI4GtQRApHqAJ9eZtLw+zDtGh3Lj889mAtcyGcKZQCeNbzW ju/nRRU3nPDz/RNYZNuLWNg= =AikS -----END PGP SIGNATURE----- --wRRV7LY7NUeQGEoC-- From owner-freebsd-stable@FreeBSD.ORG Tue Jul 7 22:26:32 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6F4351065673 for ; Tue, 7 Jul 2009 22:26:32 +0000 (UTC) (envelope-from mahlon@martini.nu) Received: from martini.nu (martini.nu [198.145.180.83]) by mx1.freebsd.org (Postfix) with SMTP id 46CF48FC18 for ; Tue, 7 Jul 2009 22:26:32 +0000 (UTC) (envelope-from mahlon@martini.nu) Received: (qmail 86030 invoked by uid 1000); 7 Jul 2009 22:26:31 -0000 Date: Tue, 7 Jul 2009 15:26:31 -0700 From: "Mahlon E. Smith" To: Freddie Cash Message-ID: <20090707222631.GA70750@martini.nu> Mail-Followup-To: "Mahlon E. Smith" , Freddie Cash , freebsd-stable@freebsd.org References: <20090707195614.GA24326@martini.nu> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="gBBFr7Ir9EOA20Yy" Content-Disposition: inline In-Reply-To: X-GPG-Fingerprint: 19B8 DDB3 0156 3A03 FA80 8278 C0BE 6BFB 3606 B267 X-Sysinfo: FreeBSD 7.0-RELEASE-p1 i386 User-Agent: Mutt/1.5.17 (2007-11-01) Cc: freebsd-stable@freebsd.org Subject: Re: ZFS: drive replacement performance X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2009 22:26:32 -0000 --gBBFr7Ir9EOA20Yy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jul 07, 2009, Freddie Cash wrote: >=20 > This is why we've started using glabel(8) to label our drives, and then a= dd > the labels to the pool: > # zpool create store raidz1 label/disk01 label/disk02 label/disk03 >=20 > That way, it does matter where the kernel detects the drives or what the > physical device node is called, GEOM picks up the label, and ZFS uses the > label. Ah, slick. I'll definitely be doing that moving forward. Wonder if I could do it piecemeal now via a shell game, labeling and replacing each individual drive? Will put that on my "try it" list. > > Once I swapped drives, I issued a 'zpool replace'. > > >=20 > See comment at the end: what's the replace command that you used? After the reboot that shuffled device order, the 'da2' changed to that ID number. To have it accept the replace command, I had to use the number itself -- I couldn't use 'da2' since that was now elsewhere, in use, on the raidz1. Surprisingly, it worked. Or at least, it appeared to. % zpool replace store 2025342973333799752 da8 > There's something wrong here. It definitely should be incrementing. Even > when we did the foolish thing of creating a 24-drive raidz2 vdev and had = to > replace a drive, the progress bar did change. Never got above 39% as it > kept restarting, but it did increment. Strangely, the ETA is jumping all over the place, from 50 hours to 2000+ hours. Never seen the percent complete over 0.01% done, but then it goes back to 0.00%. > I'd redo the replace command, and check the output of "zpool status" > to make sure it's showing the proper device node and not some random > string of numbers like it is. Hmm, I'm hunting for it but I don't see it -- know of any way to stop a replace in progress? Thanks for the quick reply, Freddie! -- Mahlon E. Smith =20 http://www.martini.nu/contact.html --gBBFr7Ir9EOA20Yy Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- iD8DBQFKU8uX1bsjBDapbeMRAoX+AKCfikB4n4yDPt5Dv9H1GsiY+iVqbQCePobm +SxZArzPWuj+CpLicMXhsl4= =n8gd -----END PGP SIGNATURE----- --gBBFr7Ir9EOA20Yy-- From owner-freebsd-stable@FreeBSD.ORG Tue Jul 7 22:32:28 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CB3491065670 for ; Tue, 7 Jul 2009 22:32:28 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-yx0-f181.google.com (mail-yx0-f181.google.com [209.85.210.181]) by mx1.freebsd.org (Postfix) with ESMTP id 862EF8FC1B for ; Tue, 7 Jul 2009 22:32:28 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: by yxe11 with SMTP id 11so7418934yxe.3 for ; Tue, 07 Jul 2009 15:32:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=rOIZtQo1MHqBjMYSpoOpVmXvYQcIYbEOSUspihCa/IA=; b=w9SYRCdebGuxeOnbs78qgFVOlhp183jPl3eXlLIpJ7UmS0TyElxTA195nzjtwtsnJ3 t3Eutdxw4YH+Qf7Kh5J5ufnhV7GmMLIjBYAYI/44C8cnOovA1L79LbC2pgvAV+qWdEbL E0oF7tMXyeN42M7qlp++FFCmNc1F7sXfDSeaI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=uDvsllXJiRLVAoeN9uhQlB3NrFPicBOVoToe86jtFRrp+88yt/ULq+0I7qwzgW04W5 1h7ue6iKYTYBQuuHkSYubx7v9VjiSvi8M4lZqC8ocZtb8mQw3F1kZoC8npAdwYKquSCn XfcxK56WAezvQGNC416D48LVNk9waKA3Ir6EA= MIME-Version: 1.0 Received: by 10.151.111.19 with SMTP id o19mr749303ybm.6.1247005947516; Tue, 07 Jul 2009 15:32:27 -0700 (PDT) In-Reply-To: <20090707222631.GA70750@martini.nu> References: <20090707195614.GA24326@martini.nu> <20090707222631.GA70750@martini.nu> Date: Tue, 7 Jul 2009 15:32:27 -0700 Message-ID: From: Freddie Cash To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: ZFS: drive replacement performance X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2009 22:32:29 -0000 On Tue, Jul 7, 2009 at 3:26 PM, Mahlon E. Smith wrote: > On Tue, Jul 07, 2009, Freddie Cash wrote: > > > > This is why we've started using glabel(8) to label our drives, and then > add > > the labels to the pool: > > # zpool create store raidz1 label/disk01 label/disk02 label/disk03 > > > > That way, it does matter where the kernel detects the drives or what the > > physical device node is called, GEOM picks up the label, and ZFS uses the > > label. > > Ah, slick. I'll definitely be doing that moving forward. Wonder if I > could do it piecemeal now via a shell game, labeling and replacing each > individual drive? Will put that on my "try it" list. > Yes, this can be done piecemeal, after the fact, on an already configured pool. That's how I did it on one of our servers. It was originally configured using the device node names (da0, da1, etc). Then I set up the second server, but used labels. Then I went back to the first server, labelled the drives, and did "zpool replace storage da0 label/disk01" for each drive. Doesn't take long to resilver, as it knows that it's the same device. > > > > > Once I swapped drives, I issued a 'zpool replace'. > > > > > See comment at the end: what's the replace command that you used? > > > After the reboot that shuffled device order, the 'da2' changed to that > ID number. To have it accept the replace command, I had to use the > number itself -- I couldn't use 'da2' since that was now elsewhere, in > use, on the raidz1. Surprisingly, it worked. Or at least, it appeared > to. > > % zpool replace store 2025342973333799752 da8 > Hmm, you might be able to use glabel here, to label this new drive, and then do the replace command using the label. I think (never tried) you can use "zpool scrub -s store" to stop the resilver. If not, you should be able to re-do the replace command. > > > > There's something wrong here. It definitely should be incrementing. > Even > > when we did the foolish thing of creating a 24-drive raidz2 vdev and had > to > > replace a drive, the progress bar did change. Never got above 39% as it > > kept restarting, but it did increment. > > Strangely, the ETA is jumping all over the place, from 50 hours to 2000+ > hours. Never seen the percent complete over 0.01% done, but then it > goes back to 0.00%. > Hrm, odd. -- Freddie Cash fjwcash@gmail.com From owner-freebsd-stable@FreeBSD.ORG Tue Jul 7 22:40:06 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2F4521065670 for ; Tue, 7 Jul 2009 22:40:06 +0000 (UTC) (envelope-from dan.naumov@gmail.com) Received: from mail-yx0-f181.google.com (mail-yx0-f181.google.com [209.85.210.181]) by mx1.freebsd.org (Postfix) with ESMTP id D95488FC0A for ; Tue, 7 Jul 2009 22:40:05 +0000 (UTC) (envelope-from dan.naumov@gmail.com) Received: by yxe11 with SMTP id 11so7426582yxe.3 for ; Tue, 07 Jul 2009 15:40:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=AjV901ikXi/KBOLdHkXocNpdhNWycdt/ouVzvbqCM1g=; b=eiOQAg/xM2akguy9UUZD1EnSDN+HonUTu1Fep8xmn9BUcIC/grAIxDxxXZfaT95lZM gu4+7axedhkPWYnFi6BOOfotWqEW4/p4afnHgoXvOS81HLmZJ5Guyyy3eJbjRsVRkRh0 /xM/f76F8m+Zz8Gqu5NozFmDGJ4TkA9nveES4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=eeGMs5htn5JHb+5jaWwbQq//So5D6srOsjH4YnR9j4mGYVkEqBakvN9T92dAbahx9V 3kdxyPhYl5QGQg5n1gajWnf2WjUT3z03+MadsED5fgN3X7bFpSKW0rZ3ZGWhp/YrHM+i CM4NJ1adw4XgXSXemd7kwdDywV9JqvjSiSFYo= MIME-Version: 1.0 Received: by 10.100.166.10 with SMTP id o10mr11394301ane.126.1247006404219; Tue, 07 Jul 2009 15:40:04 -0700 (PDT) In-Reply-To: References: <20090707195614.GA24326@martini.nu> <20090707222631.GA70750@martini.nu> Date: Wed, 8 Jul 2009 01:40:02 +0300 Message-ID: From: Dan Naumov To: Freddie Cash Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org Subject: Re: ZFS: drive replacement performance X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2009 22:40:06 -0000 On Wed, Jul 8, 2009 at 1:32 AM, Freddie Cash wrote: > On Tue, Jul 7, 2009 at 3:26 PM, Mahlon E. Smith wrote= : > >> On Tue, Jul 07, 2009, Freddie Cash wrote: >> > >> > This is why we've started using glabel(8) to label our drives, and the= n >> add >> > the labels to the pool: >> > =A0 # zpool create store raidz1 label/disk01 label/disk02 label/disk03 >> > >> > That way, it does matter where the kernel detects the drives or what t= he >> > physical device node is called, GEOM picks up the label, and ZFS uses = the >> > label. >> >> Ah, slick. =A0I'll definitely be doing that moving forward. =A0Wonder if= I >> could do it piecemeal now via a shell game, labeling and replacing each >> individual drive? =A0Will put that on my "try it" list. Not to derail this discussion, but can anyone explain if the actual glabel metadata is protected in any way? If I use glabel to label a disk and then create a pool using /dev/label/disklabel, won't ZFS eventually overwrite the glabel metadata in the last sector since the disk in it's entirety is given to the pool? Or is every filesystem used by FreeBSD (ufs, zfs, etc) hardcoded to ignore the last few sectors of any disk and/or partition and not write data to it to avoid such issues? - Sincerely, Dan Naumov From owner-freebsd-stable@FreeBSD.ORG Tue Jul 7 22:50:20 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E94931065673 for ; Tue, 7 Jul 2009 22:50:20 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (lor.one-eyed-alien.net [69.66.77.232]) by mx1.freebsd.org (Postfix) with ESMTP id 7D6778FC19 for ; Tue, 7 Jul 2009 22:50:20 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.14.3/8.14.3) with ESMTP id n67MnHOM011817; Tue, 7 Jul 2009 17:49:17 -0500 (CDT) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.14.3/8.14.3/Submit) id n67MnG33011816; Tue, 7 Jul 2009 17:49:16 -0500 (CDT) (envelope-from brooks) Date: Tue, 7 Jul 2009 17:49:16 -0500 From: Brooks Davis To: Dan Naumov Message-ID: <20090707224916.GB2415@lor.one-eyed-alien.net> References: <20090707195614.GA24326@martini.nu> <20090707222631.GA70750@martini.nu> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="mxv5cy4qt+RJ9ypb" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (lor.one-eyed-alien.net [127.0.0.1]); Tue, 07 Jul 2009 17:49:17 -0500 (CDT) Cc: freebsd-stable@freebsd.org Subject: Re: ZFS: drive replacement performance X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2009 22:50:21 -0000 --mxv5cy4qt+RJ9ypb Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jul 08, 2009 at 01:40:02AM +0300, Dan Naumov wrote: > On Wed, Jul 8, 2009 at 1:32 AM, Freddie Cash wrote: > > On Tue, Jul 7, 2009 at 3:26 PM, Mahlon E. Smith wro= te: > > > >> On Tue, Jul 07, 2009, Freddie Cash wrote: > >> > > >> > This is why we've started using glabel(8) to label our drives, and t= hen > >> add > >> > the labels to the pool: > >> > ? # zpool create store raidz1 label/disk01 label/disk02 label/disk03 > >> > > >> > That way, it does matter where the kernel detects the drives or what= the > >> > physical device node is called, GEOM picks up the label, and ZFS use= s the > >> > label. > >> > >> Ah, slick. ?I'll definitely be doing that moving forward. ?Wonder if I > >> could do it piecemeal now via a shell game, labeling and replacing each > >> individual drive? ?Will put that on my "try it" list. >=20 > Not to derail this discussion, but can anyone explain if the actual > glabel metadata is protected in any way? If I use glabel to label a > disk and then create a pool using /dev/label/disklabel, won't ZFS > eventually overwrite the glabel metadata in the last sector since the > disk in it's entirety is given to the pool? Or is every filesystem > used by FreeBSD (ufs, zfs, etc) hardcoded to ignore the last few > sectors of any disk and/or partition and not write data to it to avoid > such issues? Disks labeled with glabel lose their last sector to the label. It is not accessible by ZFS. Disks with bsdlabel partition tables are at risk due to the brain dead decision to allow partitions to overlap the first sector, but modern designs like glabel avoid this mistake. -- Brooks --mxv5cy4qt+RJ9ypb Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iD8DBQFKU9DsXY6L6fI4GtQRAgk8AKCstTdrPAi+kMC8M03pcsKhLoUX7ACfde8Z +UPNUogsP7+YjFNSW1pnmXE= =YMoj -----END PGP SIGNATURE----- --mxv5cy4qt+RJ9ypb-- From owner-freebsd-stable@FreeBSD.ORG Tue Jul 7 22:53:01 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 68BEF1065670 for ; Tue, 7 Jul 2009 22:53:01 +0000 (UTC) (envelope-from andrew@modulus.org) Received: from email.octopus.com.au (email.octopus.com.au [122.100.2.232]) by mx1.freebsd.org (Postfix) with ESMTP id 29BB18FC14 for ; Tue, 7 Jul 2009 22:53:00 +0000 (UTC) (envelope-from andrew@modulus.org) Received: by email.octopus.com.au (Postfix, from userid 1002) id BF12A17D4D; Wed, 8 Jul 2009 08:34:47 +1000 (EST) X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on email.octopus.com.au X-Spam-Level: X-Spam-Status: No, score=-1.4 required=10.0 tests=ALL_TRUSTED autolearn=failed version=3.2.3 Received: from [10.1.50.60] (ppp121-44-41-14.lns10.syd7.internode.on.net [121.44.41.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: admin@email.octopus.com.au) by email.octopus.com.au (Postfix) with ESMTP id BACCC17CFD; Wed, 8 Jul 2009 08:34:43 +1000 (EST) Message-ID: <4A53CCEC.7010808@modulus.org> Date: Wed, 08 Jul 2009 08:32:12 +1000 From: Andrew Snow User-Agent: Thunderbird 2.0.0.14 (X11/20080523) MIME-Version: 1.0 To: "Mahlon E. Smith" , freebsd-stable@freebsd.org References: <20090707195614.GA24326@martini.nu> <20090707222631.GA70750@martini.nu> In-Reply-To: <20090707222631.GA70750@martini.nu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: ZFS: drive replacement performance X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2009 22:53:01 -0000 Mahlon E. Smith wrote: > Strangely, the ETA is jumping all over the place, from 50 hours to 2000+ > hours. Never seen the percent complete over 0.01% done, but then it > goes back to 0.00%. Are you taking snapshots from crontab? Older versions of the ZFS code re-started scrubbing whenever a snapshot was taken. From owner-freebsd-stable@FreeBSD.ORG Tue Jul 7 23:10:41 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C6FFC106564A for ; Tue, 7 Jul 2009 23:10:41 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (lor.one-eyed-alien.net [69.66.77.232]) by mx1.freebsd.org (Postfix) with ESMTP id 805568FC0A for ; Tue, 7 Jul 2009 23:10:41 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.14.3/8.14.3) with ESMTP id n67N9bu2011928; Tue, 7 Jul 2009 18:09:37 -0500 (CDT) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.14.3/8.14.3/Submit) id n67N9aHA011927; Tue, 7 Jul 2009 18:09:36 -0500 (CDT) (envelope-from brooks) Date: Tue, 7 Jul 2009 18:09:36 -0500 From: Brooks Davis To: Andrew Snow Message-ID: <20090707230936.GC2415@lor.one-eyed-alien.net> References: <20090707195614.GA24326@martini.nu> <20090707222631.GA70750@martini.nu> <4A53CCEC.7010808@modulus.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="+xNpyl7Qekk2NvDX" Content-Disposition: inline In-Reply-To: <4A53CCEC.7010808@modulus.org> User-Agent: Mutt/1.5.17 (2007-11-01) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (lor.one-eyed-alien.net [127.0.0.1]); Tue, 07 Jul 2009 18:09:38 -0500 (CDT) Cc: freebsd-stable@freebsd.org Subject: Re: ZFS: drive replacement performance X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2009 23:10:42 -0000 --+xNpyl7Qekk2NvDX Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jul 08, 2009 at 08:32:12AM +1000, Andrew Snow wrote: > Mahlon E. Smith wrote: >=20 >> Strangely, the ETA is jumping all over the place, from 50 hours to 2000+ >> hours. Never seen the percent complete over 0.01% done, but then it >> goes back to 0.00%. >=20 > Are you taking snapshots from crontab? Older versions of the ZFS code=20 > re-started scrubbing whenever a snapshot was taken. I know I'm not doing anything to mine. It's just sitting there unused. -- Brooks --+xNpyl7Qekk2NvDX Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iD8DBQFKU9WwXY6L6fI4GtQRAs6YAKDRZPbSd+A4R+FxFHSUV3mqaB6F6ACfedzP sGyCTf2hQwnfbVhk0uuZB7E= =7ffk -----END PGP SIGNATURE----- --+xNpyl7Qekk2NvDX-- From owner-freebsd-stable@FreeBSD.ORG Tue Jul 7 23:20:08 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D0A59106564A; Tue, 7 Jul 2009 23:20:08 +0000 (UTC) (envelope-from dan.naumov@gmail.com) Received: from mail-yx0-f181.google.com (mail-yx0-f181.google.com [209.85.210.181]) by mx1.freebsd.org (Postfix) with ESMTP id 69DDD8FC16; Tue, 7 Jul 2009 23:20:07 +0000 (UTC) (envelope-from dan.naumov@gmail.com) Received: by yxe11 with SMTP id 11so7466526yxe.3 for ; Tue, 07 Jul 2009 16:20:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=1wz2wTBtkFo56cVui6kpiS+Xn71x3ty+PrEHyXEP4Q0=; b=tQC22uBmsW58BO7Kh3AEAeIDIVmh2fCC8Og3MwtjN9hy3SKwNOouWz1wlsCQuaKhnF BG4a6eoZe8EbsfieteeZNYLL72n1/h1Pzsuv/I9WSpd162CiGprbKKlxWuP/Ivl9OVGM g+UKi/69SFLJ171lwUuGmT0zdtHCT7mSSQwuo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=Y7myFZQOuzuvvK8vkK8jgbAdLTgK+HnOVMg0YXse9BkBbM/mWBYTZ9DXHtmt6apWPw tZqIki7BNn5oxCoK0R1D/ewek5M5xEAQ65p0nrF82azMIOt60b7ToVAvkLQz3s+Fw/XD bH9n+pxSYfO9YQHwAn2R+VMEWrftX4ElHQnWE= MIME-Version: 1.0 Received: by 10.100.195.15 with SMTP id s15mr11494872anf.18.1247008807465; Tue, 07 Jul 2009 16:20:07 -0700 (PDT) Date: Wed, 8 Jul 2009 02:20:07 +0300 Message-ID: From: Dan Naumov To: Brooks Davis Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org, freebsd-geom@freebsd.org Subject: glabel metadata protection (WAS: ZFS: drive replacement performance) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2009 23:20:09 -0000 >> Not to derail this discussion, but can anyone explain if the actual >> glabel metadata is protected in any way? If I use glabel to label a >> disk and then create a pool using /dev/label/disklabel, won't ZFS >> eventually overwrite the glabel metadata in the last sector since the >> disk in it's entirety is given to the pool? Or is every filesystem >> used by FreeBSD (ufs, zfs, etc) hardcoded to ignore the last few >> sectors of any disk and/or partition and not write data to it to avoid >> such issues? > > Disks labeled with glabel lose their last sector to the label. =A0It is n= ot > accessible by ZFS. =A0Disks with bsdlabel partition tables are at risk du= e to > the brain dead decision to allow partitions to overlap the first sector, > but modern designs like glabel avoid this mistake. > > -- Brooks So what happens if I was to do the following (for the same of example): gpart create -s GPT /dev/ad1 glabel label -v disk01 /dev/ad1 gpart add -b 1 -s -t freebsd-zfs /dev/ad1 Does "gpart add" automatically somehow recognize that the last sector of contains the glabel and automatically re-adjusts this command to make the freebsd-zfs partition take "entiredisk minus last sector" ? I can understand the logic of metadata being protected if I do a: "gpart add -b 1 -s -t freebsd-zfs /dev/label/disk01" since gpart will have to go through the actual label first, but what actually happens if I issue a gpart directly to the /dev/device? - Sincerely, Dan Naumov From owner-freebsd-stable@FreeBSD.ORG Wed Jul 8 00:13:38 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 073D1106568C for ; Wed, 8 Jul 2009 00:13:38 +0000 (UTC) (envelope-from mahlon@martini.nu) Received: from martini.nu (martini.nu [198.145.180.83]) by mx1.freebsd.org (Postfix) with SMTP id D1B368FC17 for ; Wed, 8 Jul 2009 00:13:37 +0000 (UTC) (envelope-from mahlon@martini.nu) Received: (qmail 47188 invoked by uid 1000); 8 Jul 2009 00:13:36 -0000 Date: Tue, 7 Jul 2009 17:13:36 -0700 From: "Mahlon E. Smith" To: Freddie Cash Message-ID: <20090708001336.GA95670@martini.nu> Mail-Followup-To: "Mahlon E. Smith" , Freddie Cash , freebsd-stable@freebsd.org References: <20090707195614.GA24326@martini.nu> <20090707222631.GA70750@martini.nu> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="azLHFNyN32YCQGCU" Content-Disposition: inline In-Reply-To: X-GPG-Fingerprint: 19B8 DDB3 0156 3A03 FA80 8278 C0BE 6BFB 3606 B267 X-Sysinfo: FreeBSD 7.0-RELEASE-p1 i386 User-Agent: Mutt/1.5.17 (2007-11-01) Cc: freebsd-stable@freebsd.org Subject: Re: ZFS: drive replacement performance X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2009 00:13:38 -0000 --azLHFNyN32YCQGCU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jul 07, 2009, Freddie Cash wrote: >=20 > I think (never tried) you can use "zpool scrub -s store" to stop the > resilver. If not, you should be able to re-do the replace command. Hmm. I think I may be stuck. % zpool scrub -s store % zpool status | grep scrub scrub: resilver in progress for 0h0m, 0.00% done, 745h41m to go % zpool replace store 2025342973333799752 da8 invalid vdev specification use '-f' to override the following errors: /dev/da8 is part of active pool 'store' =20 % zpool replace -f store 2025342973333799752 da8 invalid vdev specification the following errors must be manually repaired: /dev/da8 is part of active pool 'store' % zpool detach store da8 cannot detach da8: no valid replicas % zpool detach store 2025342973333799752 cannot detach 2025342973333799752: no valid replicas I also tried another export/import cycle, in the random hope that would stop the active replace -- no dice. *However*, on the import, now I see this flooding my console (wasn't there previously, strangely): Jul 7 16:50:15 disobedience root: ZFS: vdev I/O failure, zpool=3Dstore pat= h=3D/dev/da2 offset=3D262144 size=3D8192 error=3D6 Jul 7 16:50:15 disobedience root: ZFS: vdev I/O failure, zpool=3Dstore pat= h=3D/dev/da2 offset=3D499988824064 size=3D8192 error=3D6 I now have to wonder if that's really the active da2 it is complaining about (the one claiming to be online with 0 errors) or the one I'm trying to replace with da8. The current da2 doesn't seem to be having any additional problems, like the checksum mismatches or other associated console errors I've come to expect, but of course the old one is no longer attached to the machine. In any event, I'd wager that isn't something I normally want to see, and I may have something else going on here. (Bad controller, etc?) Serves me right for naming a machine 'disobedience', I guess. Next one is getting named 'subservience.' Going to halt and pull da8 under the assumption that will at least stop the resilver, and try the detach again. I'll holler back if I get stuff going again, but this is looking more like a hardware problem. Thanks again for the insight! -Mahlon -- Mahlon E. Smith =20 http://www.martini.nu/contact.html --azLHFNyN32YCQGCU Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- iD8DBQFKU+Sw1bsjBDapbeMRAoN1AJ4hnaXAcsumQ4YPl6hgeS8j+b0+swCgq8O0 4X/YnS2iCHK8jd47S0D15SE= =GIVG -----END PGP SIGNATURE----- --azLHFNyN32YCQGCU-- From owner-freebsd-stable@FreeBSD.ORG Wed Jul 8 00:57:30 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6A0511065694; Wed, 8 Jul 2009 00:57:30 +0000 (UTC) (envelope-from dan.naumov@gmail.com) Received: from mail-yx0-f181.google.com (mail-yx0-f181.google.com [209.85.210.181]) by mx1.freebsd.org (Postfix) with ESMTP id 0CD3D8FC0A; Wed, 8 Jul 2009 00:57:29 +0000 (UTC) (envelope-from dan.naumov@gmail.com) Received: by yxe11 with SMTP id 11so7559780yxe.3 for ; Tue, 07 Jul 2009 17:57:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=i9xQSOhaUzNrVJNjOy/zqHwLMBG0YUBBqdHeTQO1lLs=; b=S0s/f/d/7gyc4lvdHScQSVik0PnG2IIg5wV53zqOJZmBYgQ5KG2esU4BRsTpabqjJg 7pePAkx01vXq3yFxWiW8qGrGW+AckL+zFLPHbsSienFAVE+NrRi+17oenSFhLY2oxYAp OM0P0mKFHnoDr2rHRIwUUofkAbBp/luSplKL4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=n14H1XdTN+vT+5ljlVuhq2nvW7Dvbi55YC68ZDoLlWhG6Omz7sx4zhc0mh5vZ6rBqM 2gnDQ7VVTJy2+mdyBS/tvi/e4U4Fc0A+E0MJtm9GblR3l3P1XzGuqQ6AtpmIG/LAaKr5 Uem7nc3luORHRhzhvMmyMPVir8AV3entPSYMY= MIME-Version: 1.0 Received: by 10.100.96.9 with SMTP id t9mr11587681anb.106.1247014649403; Tue, 07 Jul 2009 17:57:29 -0700 (PDT) In-Reply-To: <3bbf2fe10907061827g35eaeb49g26cf6fdb64436ca7@mail.gmail.com> References: <3bbf2fe10907061818v245abd0cgc3ca5073cb93aea4@mail.gmail.com> <3bbf2fe10907061827g35eaeb49g26cf6fdb64436ca7@mail.gmail.com> Date: Wed, 8 Jul 2009 03:57:29 +0300 Message-ID: From: Dan Naumov To: Attilio Rao Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD-STABLE Mailing List Subject: Re: 7.2-release/amd64: panic, spin lock held too long X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2009 00:57:30 -0000 On Tue, Jul 7, 2009 at 4:27 AM, Attilio Rao wrote: > 2009/7/7 Dan Naumov : >> On Tue, Jul 7, 2009 at 4:18 AM, Attilio Rao wrote: >>> 2009/7/7 Dan Naumov : >>>> I just got a panic following by a reboot a few seconds after running >>>> "portsnap update", /var/log/messages shows the following: >>>> >>>> Jul =A07 03:49:38 atom syslogd: kernel boot file is /boot/kernel/kerne= l >>>> Jul =A07 03:49:38 atom kernel: spin lock 0xffffffff80b3edc0 (sched loc= k >>>> 1) held by 0xffffff00017d8370 (tid 100054) too long >>>> Jul =A07 03:49:38 atom kernel: panic: spin lock held too long >>> >>> That's a known bug, affecting -CURRENT as well. >>> The cpustop IPI is handled though an NMI, which means it could >>> interrupt a CPU in any moment, even while holding a spinlock, >>> violating one well known FreeBSD rule. >>> That means that the cpu can stop itself while the thread was holding >>> the sched lock spinlock and not releasing it (there is no way, modulo >>> highly hackish, to fix that). >>> In the while hardclock() wants to schedule something else to run and >>> got stuck on the thread lock. >>> >>> Ideal fix would involve not using a NMI for serving the cpustop while >>> having a cheap way (not making the common path too hard) to tell >>> hardclock() to avoid scheduling while cpustop is in flight. >>> >>> Thanks, >>> Attilio >> >> Any idea if a fix is being worked on and how unlucky must one be to >> run into this issue, should I expect it to happen again? Is it >> basically completely random? > > I'd like to work on that issue before BETA3 (and backport to > STABLE_7), I'm just time-constrained right now. > it is completely random. > > Thanks, > Attilio Ok, this is getting pretty bad, 23 hours later, I get the same kind of panic, the only difference is that instead of "portsnap update", this was triggered by "portsnap cron" which I have running between 3 and 4 am every day: Jul 8 03:03:49 atom kernel: ssppiinn lloocckk 00xxffffffffffffffff8800bb33eeddc400 ((sscchheedd lloocck k1 )0 )h ehledl db yb y 0x0xfffffffffff0f00001081735339760e 0( t(itdi d 10100006070)5 )t otoo ol olnogng Jul 8 03:03:49 atom kernel: p Jul 8 03:03:49 atom kernel: anic: spin lock held too long Jul 8 03:03:49 atom kernel: cpuid =3D 0 Jul 8 03:03:49 atom kernel: Uptime: 23h2m38s - Sincerely, Dan Naumov From owner-freebsd-stable@FreeBSD.ORG Wed Jul 8 01:07:16 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A0407106564A; Wed, 8 Jul 2009 01:07:16 +0000 (UTC) (envelope-from bp@barryp.org) Received: from itasca.hexavalent.net (itasca.hexavalent.net [67.207.138.180]) by mx1.freebsd.org (Postfix) with ESMTP id 68C618FC0A; Wed, 8 Jul 2009 01:07:16 +0000 (UTC) (envelope-from bp@barryp.org) Received: from eden.barryp.org (host-145-114-107-208.midco.net [208.107.114.145]) by itasca.hexavalent.net (Postfix) with ESMTPS id C57B223C549; Tue, 7 Jul 2009 19:49:52 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=barryp.org; s=itasca; t=1247014192; bh=vqsypQSX/+1KSkQr+XN249Yxr9LIFW9LP6e3Giijunk=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=LOVzwbeVl1WD tlp+cs9ugo1j5WY6K0dASg7rUlWOFfIvfhgflaUC7U2+5vOU5TodNNX7an9ghl/OEV1 7gn25z0tpmXzAahpTnGvcoF7v+gou3qDelivao00KY0B5KGZVTt9cqjbdSPAqr5QcRL jjgtZn7cfwDhriuyIBn7DFv9Q= Received: from [10.66.1.233] (helo=barry-pedersons-macbook.local) by eden.barryp.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67 (FreeBSD)) (envelope-from ) id 1MOLM6-0003Sm-He; Tue, 07 Jul 2009 19:49:50 -0500 Message-ID: <4A53ED2D.4070309@barryp.org> Date: Tue, 07 Jul 2009 19:49:49 -0500 From: Barry Pederson User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Dan Naumov References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org, freebsd-geom@freebsd.org Subject: Re: glabel metadata protection (WAS: ZFS: drive replacement performance) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2009 01:07:17 -0000 Dan Naumov wrote: >>> If I use glabel to label a >>> disk and then create a pool using /dev/label/disklabel, won't ZFS >>> eventually overwrite the glabel metadata in the last sector since the >>> disk in it's entirety is given to the pool? I would say in this case you're *not* giving the entire disk to the pool, you're giving ZFS a geom that's one sector smaller than the disk. ZFS never sees or can touch the glabel metadata. > So what happens if I was to do the following (for the same of example): > > gpart create -s GPT /dev/ad1 > glabel label -v disk01 /dev/ad1 > gpart add -b 1 -s -t freebsd-zfs /dev/ad1 > > Does "gpart add" automatically somehow recognize that the last sector > of contains the glabel and automatically re-adjusts this > command to make the freebsd-zfs partition take "entiredisk minus last > sector" ? I can understand the logic of metadata being protected if I > do a: "gpart add -b 1 -s -t freebsd-zfs > /dev/label/disk01" since gpart will have to go through the actual > label first, but what actually happens if I issue a gpart directly to > the /dev/device? I'd guess bad stuff would happen here, with a conflict between what gpt and glabel would want to do with the end of the disk. If you wanted to use glabel with a GPT partition, I'd think you'd want to gpart create -s GPT /dev/ad1 (use "gpart show" to see what space is now available for GPT partitions, it won't start at 1 and won't go to the very end of the disk) gpart add -b 34 -s -t freebsd-zfs /dev/ad1 glabel label -v disk01 /dev/ad1p1 (and then use label/disk01 in a zpool) Barry From owner-freebsd-stable@FreeBSD.ORG Wed Jul 8 01:53:20 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 412D11065677 for ; Wed, 8 Jul 2009 01:53:20 +0000 (UTC) (envelope-from emikulic@gmail.com) Received: from ipmail03.adl6.internode.on.net (ipmail03.adl6.internode.on.net [203.16.214.141]) by mx1.freebsd.org (Postfix) with ESMTP id C53FB8FC1B for ; Wed, 8 Jul 2009 01:53:19 +0000 (UTC) (envelope-from emikulic@gmail.com) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAPqWU0qWZZrw/2dsb2JhbAC9fJIQhAcFgTo X-IronPort-AV: E=Sophos;i="4.42,365,1243780200"; d="scan'208";a="3042579" Received: from ppp154-240.static.internode.on.net ([150.101.154.240]) by ipmail03.adl6.internode.on.net with ESMTP; 08 Jul 2009 11:23:18 +0930 Received: by ppp154-240.static.internode.on.net (Poo-fix, from userid 1001) id 1B3BC5C65; Wed, 8 Jul 2009 11:53:17 +1000 (EST) Date: Wed, 8 Jul 2009 11:53:17 +1000 From: Emil Mikulic To: Brooks Davis Message-ID: <20090708015317.GA47872@dmr.ath.cx> References: <20090707195614.GA24326@martini.nu> <20090707205357.GA2415@lor.one-eyed-alien.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090707205357.GA2415@lor.one-eyed-alien.net> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: freebsd-stable@freebsd.org Subject: Re: ZFS: drive replacement performance X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2009 01:53:20 -0000 On Tue, Jul 07, 2009 at 03:53:58PM -0500, Brooks Davis wrote: > I'm seeing essentially the same think on an 8.0-BETA1 box with an 8-disk > raidz1 pool. Every once in a while the system makes it to 0.05% done > and gives a vaguely reasonable rebuild time, but it quickly drops back > to reports 0.00% and it's basically not making any forward progress. You're not creating or deleting snapshots, are you? AFAICT doing that will make scrub (and resilver) start from scratch. --Emil From owner-freebsd-stable@FreeBSD.ORG Wed Jul 8 02:20:15 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3BDD3106564A for ; Wed, 8 Jul 2009 02:20:15 +0000 (UTC) (envelope-from drew@mykitchentable.net) Received: from smtp1.mc.surewest.net (qsmtp.mc.surewest.net [66.60.130.145]) by mx1.freebsd.org (Postfix) with SMTP id 15C348FC0A for ; Wed, 8 Jul 2009 02:20:15 +0000 (UTC) (envelope-from drew@mykitchentable.net) Received: (qmail 5704 invoked from network); 7 Jul 2009 19:14:50 -0700 Received: by simscan 1.1.0 ppid: 5674, pid: 5675, t: 2.2179s scanners: regex: 1.1.0 attach: 1.1.0 spam: 3.1.7-deb X-Spam-Checker-Version: SpamAssassin 3.1.7-deb (2006-10-05) on smtp1.surewest.net X-Spam-Level: X-Spam-Status: No, score=0.0 required=10.0 tests=none autolearn=disabled version=3.1.7-deb X-Spam-CMAE-Analysis: v=1.0 c=1 a=70updLwoonEA:10 a=6I5d2MoRAAAA:8 a=jDt-9pEAAAAA:8 a=WB5y4THb-h1CX-FQArQA:9 a=tvVk0dBmYKEOy3Iv0EQA:7 a=UvNFtsshgjIAgGv1m6CezGG9_lsA:4 a=R35AumO-WOIA:10 Received: from unknown (HELO blacklamb.mykitchentable.net) (69.62.230.77) by smtp1 with SMTP; 7 Jul 2009 19:14:48 -0700 Received: from [192.168.2.3] (unknown [192.168.2.3]) by blacklamb.mykitchentable.net (Postfix) with ESMTPA id 96619165E85 for ; Tue, 7 Jul 2009 18:53:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=mykitchentable.net; s=default; t=1247018012; bh=g399Krhuvw8/atdvCOcxHE/1e3n5MnKCe76nALEn1vY=; h=Message-ID:Date:From:MIME-Version:To:Subject:Content-Type: Content-Transfer-Encoding; b=3rfK433qC5MYFAmmPIkOAObcB/tiwA9D0a/Lcm/uXZS0OQqrkmPh0NWNTj1Dir20D SSSA6WqNWtRaO7nyBKoV7Z2Oj2JrCGueCzWa7aR/YoZuBBU7WeVwMFyMYUtv3u4oJT Juu9Nnu8c65Xg0dbKR3YFUUymFWF6ZyW/iUuYSZs= Message-ID: <4A53FC1B.5090303@mykitchentable.net> Date: Tue, 07 Jul 2009 18:53:31 -0700 From: Drew Tomlinson User-Agent: Thunderbird 2.0.0.19 (X11/20090122) MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Help With Custom Disk Layout For New Install X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2009 02:20:15 -0000 I have a new box and have been trying to install 7.2 amd64 on it for the past week. I now see that 8.0-BETA1 is available and would be willing to install it if it supports my intended config below. I'm using this page as a guide but am at the console so I'm just using the Fix It CD: http://www.freebsd.org/doc/en/articles/remote-install/installation.html I'm having two problems. gmirror fails silently (i.e. nothing exists in /dev/mirror). zpool command complains about libraries not being available or something to that effect. I only want to use FreeBSD on this box and I want to dedicate all drives to FreeBSD. The box has 4 SATA drives detected as follows: ad6 - 750 GB ad8 - 500 GB ad12 - 500 GB ad14 - 500 GB My thought is to break the disks up as so: ad6 a: 500M b: 500M d: 465G e: 225G (rest of drive) ad8 a: 500M b: 500M d: 465G (rest of drive) ad12 b: 1000M d: 465G (rest of drive) ad14 b: 1000M d: 465G (rest of drive) Then to install, I want to use gmirror and zfs as so: / - mirror ad6a and ad8a swap - all the b: partitions (if that's the right term) for a total of 3 GB swap. zfs - make a raid1z zpool with ad6d, ad8d, ad12d, and ad14d. in this pool I will create /usr and /var ad6e will just be extra space for some other use. So does my plan make sense? And if so, how can I best accomplish it? Is there a better guide somewhere? Should I use gpart and glabel instead of fdisk and bsdlabel? I've read the man pages for gpart and glabel but didn't really get it and thus returned to the more familiar fdisk and bsdlabel. Thanks, Drew -- Be a Great Magician! Visit The Alchemist's Warehouse http://www.alchemistswarehouse.com From owner-freebsd-stable@FreeBSD.ORG Wed Jul 8 05:46:20 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BA40E1065672 for ; Wed, 8 Jul 2009 05:46:20 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (lor.one-eyed-alien.net [69.66.77.232]) by mx1.freebsd.org (Postfix) with ESMTP id 6CC188FC1B for ; Wed, 8 Jul 2009 05:46:20 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.14.3/8.14.3) with ESMTP id n685jGfv014227; Wed, 8 Jul 2009 00:45:16 -0500 (CDT) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.14.3/8.14.3/Submit) id n685jG2o014226; Wed, 8 Jul 2009 00:45:16 -0500 (CDT) (envelope-from brooks) Date: Wed, 8 Jul 2009 00:45:16 -0500 From: Brooks Davis To: Emil Mikulic Message-ID: <20090708054516.GA14211@lor.one-eyed-alien.net> References: <20090707195614.GA24326@martini.nu> <20090707205357.GA2415@lor.one-eyed-alien.net> <20090708015317.GA47872@dmr.ath.cx> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="FL5UXtIhxfXey3p5" Content-Disposition: inline In-Reply-To: <20090708015317.GA47872@dmr.ath.cx> User-Agent: Mutt/1.5.17 (2007-11-01) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (lor.one-eyed-alien.net [127.0.0.1]); Wed, 08 Jul 2009 00:45:17 -0500 (CDT) Cc: freebsd-stable@freebsd.org Subject: Re: ZFS: drive replacement performance X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2009 05:46:21 -0000 --FL5UXtIhxfXey3p5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jul 08, 2009 at 11:53:17AM +1000, Emil Mikulic wrote: > On Tue, Jul 07, 2009 at 03:53:58PM -0500, Brooks Davis wrote: > > I'm seeing essentially the same think on an 8.0-BETA1 box with an 8-disk > > raidz1 pool. Every once in a while the system makes it to 0.05% done > > and gives a vaguely reasonable rebuild time, but it quickly drops back > > to reports 0.00% and it's basically not making any forward progress. >=20 > You're not creating or deleting snapshots, are you? > AFAICT doing that will make scrub (and resilver) start from scratch. As far as I know, no snapshots are being created or deleted. -- Brooks --FL5UXtIhxfXey3p5 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iD8DBQFKVDJsXY6L6fI4GtQRAhxLAJ0QJSejLzEgrkSmgrsBNiWOl0Vw4gCfX4Uo jdO9jVNbLA2lqKHlLEuVb5I= =yQYy -----END PGP SIGNATURE----- --FL5UXtIhxfXey3p5-- From owner-freebsd-stable@FreeBSD.ORG Wed Jul 8 06:54:59 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 02FBC106564A for ; Wed, 8 Jul 2009 06:54:59 +0000 (UTC) (envelope-from mail25@bzerk.org) Received: from ei.bzerk.org (tunnel490.ipv6.xs4all.nl [IPv6:2001:888:10:1ea::2]) by mx1.freebsd.org (Postfix) with ESMTP id 646128FC12 for ; Wed, 8 Jul 2009 06:54:58 +0000 (UTC) (envelope-from mail25@bzerk.org) Received: from ei.bzerk.org (BOFH@localhost [127.0.0.1]) by ei.bzerk.org (8.14.2/8.14.2) with ESMTP id n686srBa003017; Wed, 8 Jul 2009 08:54:53 +0200 (CEST) (envelope-from mail25@bzerk.org) Received: (from bulk@localhost) by ei.bzerk.org (8.14.2/8.14.2/Submit) id n686sqxU003016; Wed, 8 Jul 2009 08:54:52 +0200 (CEST) (envelope-from mail25@bzerk.org) Date: Wed, 8 Jul 2009 08:54:52 +0200 From: Ruben de Groot To: Dan Naumov Message-ID: <20090708065452.GB2904@ei.bzerk.org> Mail-Followup-To: Ruben de Groot , Dan Naumov , rick-freebsd2008@kiwi-computer.com, FreeBSD Stable Mailing List References: <20090706073941.GA78371@ei.bzerk.org> <20090706074256.GD6306@hugo10.ka.punkt.de> <4A51B721.5020505@andric.com> <4A51B9FA.9010906@andric.com> <20090706093904.GA79434@ei.bzerk.org> <20090706212045.GA91095@keira.kiwi-computer.com> <20090707092451.GA92743@ei.bzerk.org> <20090707160928.GA1662@keira.kiwi-computer.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on ei.bzerk.org X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0.1 (ei.bzerk.org [127.0.0.1]); Wed, 08 Jul 2009 08:54:57 +0200 (CEST) Cc: rick-freebsd2008@kiwi-computer.com, FreeBSD Stable Mailing List Subject: Re: What is /boot/kernel/*.symbols? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2009 06:54:59 -0000 On Tue, Jul 07, 2009 at 07:29:24PM +0300, Dan Naumov typed: > On Tue, Jul 7, 2009 at 7:09 PM, Rick C. > Petty wrote: > > On Tue, Jul 07, 2009 at 11:24:51AM +0200, Ruben de Groot wrote: > >> On Mon, Jul 06, 2009 at 04:20:45PM -0500, Rick C. Petty typed: > >> > On Mon, Jul 06, 2009 at 11:39:04AM +0200, Ruben de Groot wrote: > >> > > On Mon, Jul 06, 2009 at 10:46:50AM +0200, Dimitry Andric typed: > >> > > > > >> > > > Right, so it's a lot bigger on amd64. ?I guess those 64-bit pointers > >> > > > aren't entirely free. :) > >> > > > >> > > I'm not sure where the size difference comes from. I have some sparc64 > >> > > systems running -current with symbols and the size of /boot/kernel is > >> > > more comparable to i386, even with the 8-byte pointer size: > >> > > >> > Um, probably there are a lot of devices on amd64 that aren't available for > >> > sparc64? > >> > >> Yes, That's probably it. > > > > It was just a theory; I don't have sparc64. ?What's your output of > > "ls -1 /boot/kernel | wc"? > > > > -- Rick C. Petty > > atom# uname -a > FreeBSD atom.localdomain 7.2-RELEASE-p2 FreeBSD 7.2-RELEASE-p2 #0: Wed > Jun 24 00:14:35 UTC 2009 > root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 > > atom# ls -1 /boot/kernel | wc > 1011 1011 15243 On sparc: morninglightmountain# uname -pr 8.0-CURRENT sparc64 morninglightmountain# ls /boot/kernel | wc 853 853 13045 morninglightmountain# wc -l /usr/src/sys/sparc64/conf/GENERIC /usr/src/sys/amd64/conf/GENERIC 247 /usr/src/sys/sparc64/conf/GENERIC 322 /usr/src/sys/amd64/conf/GENERIC 569 total So, fewer drivers and also less devices in GENERIC, as might be expected. regards, Ruben From owner-freebsd-stable@FreeBSD.ORG Wed Jul 8 07:18:57 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3396D106566C; Wed, 8 Jul 2009 07:18:57 +0000 (UTC) (envelope-from dan.naumov@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.245]) by mx1.freebsd.org (Postfix) with ESMTP id CF9BB8FC08; Wed, 8 Jul 2009 07:18:56 +0000 (UTC) (envelope-from dan.naumov@gmail.com) Received: by an-out-0708.google.com with SMTP id d14so2461176and.13 for ; Wed, 08 Jul 2009 00:18:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=3BrcMTc4dn8GTLTuMt2Mvu4NPEwao1ULV2v7hwKru6s=; b=ntCyndFgZ2z3UOk6/gqe1As0q9N+WDXgy6zXw0xkuju5oEwwgXnm91V1xM6kqgmLtJ MFXGsyG5jAODKb8jtpq/SeBcWmAA9VPSIqIpxlzjhuOSQAoeoWKCIdl3VZIsh7H20wyY cy7yid9t2jx3pxaGHjxvOSioFqX2mQJNorW5k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=NXmFcIQxkYcrifylFLQD9GkVRMh4+GZMcNMKTB8Ew0oxSGAdnH70GgVfJli77Hs3Qy 6cqsryAyOPdaMAAdNLz+/jC0nEFM3UBc/U26JNX6wYkFTVR7i7w+3kiUk8se1hdknQaR xBTn85xt83K4tgQqr9FZT2XPCJPeokJuqKuAE= MIME-Version: 1.0 Received: by 10.101.66.17 with SMTP id t17mr12074997ank.41.1247037536211; Wed, 08 Jul 2009 00:18:56 -0700 (PDT) In-Reply-To: References: <3bbf2fe10907061818v245abd0cgc3ca5073cb93aea4@mail.gmail.com> <3bbf2fe10907061827g35eaeb49g26cf6fdb64436ca7@mail.gmail.com> Date: Wed, 8 Jul 2009 10:18:56 +0300 Message-ID: From: Dan Naumov To: Attilio Rao Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD-STABLE Mailing List Subject: Re: 7.2-release/amd64: panic, spin lock held too long X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2009 07:18:57 -0000 On Wed, Jul 8, 2009 at 3:57 AM, Dan Naumov wrote: > On Tue, Jul 7, 2009 at 4:27 AM, Attilio Rao wrote: >> 2009/7/7 Dan Naumov : >>> On Tue, Jul 7, 2009 at 4:18 AM, Attilio Rao wrote: >>>> 2009/7/7 Dan Naumov : >>>>> I just got a panic following by a reboot a few seconds after running >>>>> "portsnap update", /var/log/messages shows the following: >>>>> >>>>> Jul =A07 03:49:38 atom syslogd: kernel boot file is /boot/kernel/kern= el >>>>> Jul =A07 03:49:38 atom kernel: spin lock 0xffffffff80b3edc0 (sched lo= ck >>>>> 1) held by 0xffffff00017d8370 (tid 100054) too long >>>>> Jul =A07 03:49:38 atom kernel: panic: spin lock held too long >>>> >>>> That's a known bug, affecting -CURRENT as well. >>>> The cpustop IPI is handled though an NMI, which means it could >>>> interrupt a CPU in any moment, even while holding a spinlock, >>>> violating one well known FreeBSD rule. >>>> That means that the cpu can stop itself while the thread was holding >>>> the sched lock spinlock and not releasing it (there is no way, modulo >>>> highly hackish, to fix that). >>>> In the while hardclock() wants to schedule something else to run and >>>> got stuck on the thread lock. >>>> >>>> Ideal fix would involve not using a NMI for serving the cpustop while >>>> having a cheap way (not making the common path too hard) to tell >>>> hardclock() to avoid scheduling while cpustop is in flight. >>>> >>>> Thanks, >>>> Attilio >>> >>> Any idea if a fix is being worked on and how unlucky must one be to >>> run into this issue, should I expect it to happen again? Is it >>> basically completely random? >> >> I'd like to work on that issue before BETA3 (and backport to >> STABLE_7), I'm just time-constrained right now. >> it is completely random. >> >> Thanks, >> Attilio > > Ok, this is getting pretty bad, 23 hours later, I get the same kind of > panic, the only difference is that instead of "portsnap update", this > was triggered by "portsnap cron" which I have running between 3 and 4 > am every day: > > Jul =A08 03:03:49 atom kernel: ssppiinn =A0lloocckk > 00xxffffffffffffffff8800bb33eeddc400 =A0((sscchheedd =A0lloocck k1 )0 )h > ehledl db yb y 0x0xfffffffffff0f00001081735339760e 0( t(itdi d > 10100006070)5 )t otoo ol olnogng > Jul =A08 03:03:49 atom kernel: p > Jul =A08 03:03:49 atom kernel: anic: spin lock held too long > Jul =A08 03:03:49 atom kernel: cpuid =3D 0 > Jul =A08 03:03:49 atom kernel: Uptime: 23h2m38s I have now tried repeating the problem by running "stress --cpu 8 --io 8 --vm 4 --vm-bytes 1024M --timeout 600s --verbose" which pushed system load into the 15.50 ballpark and simultaneously running "portsnap fetch" and "portsnap update" but I couldn't manually trigger the panic, it seems that this problem is indeed random (although it baffles me why is it specifically portsnap triggering it). I have now disabled powerd to check whether that makes any difference to system stability. The only other things running on the system are: sshd, ntpd, smartd, smbd/nmdb and a few instances of irssi in screens. - Sincerely, Dan Naumov From owner-freebsd-stable@FreeBSD.ORG Wed Jul 8 08:10:27 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D9B1E10656EA for ; Wed, 8 Jul 2009 08:10:27 +0000 (UTC) (envelope-from tonix@interazioni.it) Received: from mx02.interazioni.net (mx02.interazioni.net [80.94.114.204]) by mx1.freebsd.org (Postfix) with ESMTP id 278888FC19 for ; Wed, 8 Jul 2009 08:10:26 +0000 (UTC) (envelope-from tonix@interazioni.it) Received: (qmail 75323 invoked by uid 88); 8 Jul 2009 08:10:24 -0000 Received: from unknown (HELO ?192.168.56.198?) (tonix@interazioni.it@85.18.206.139) by relay.interazioni.net with ESMTPA; 8 Jul 2009 08:10:23 -0000 Message-ID: <4A54546E.2070908@interazioni.it> Date: Wed, 08 Jul 2009 10:10:22 +0200 From: "Tonix (Antonio Nati)" User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <4A532938.2020207@interazioni.it> In-Reply-To: <4A532938.2020207@interazioni.it> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: CARP in standard kernel? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2009 08:10:30 -0000 Tonix (Antonio Nati) ha scritto: > I saw in the past requests for adding carp in standard kernel. > As of today, is there any chance to have it in kernel, as loadable > module? > It would semplify a lot usage of freebsd-ipdate, instead of > rebuilduing a custom kernel each time. > > Thanks, > > Tonino > May CARP be a loadable module, or does it need to 'stay' inside base kernel? Tonino -- ------------------------------------------------------------ Inter@zioni Interazioni di Antonio Nati http://www.interazioni.it tonix@interazioni.it ------------------------------------------------------------ From owner-freebsd-stable@FreeBSD.ORG Wed Jul 8 08:19:40 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C0F32106564A for ; Wed, 8 Jul 2009 08:19:40 +0000 (UTC) (envelope-from ronald-freebsd8@klop.yi.org) Received: from smtp-out1.tiscali.nl (smtp-out1.tiscali.nl [195.241.79.176]) by mx1.freebsd.org (Postfix) with ESMTP id 871A28FC14 for ; Wed, 8 Jul 2009 08:19:40 +0000 (UTC) (envelope-from ronald-freebsd8@klop.yi.org) Received: from [212.123.145.58] (helo=sjakie.klop.ws) by smtp-out1.tiscali.nl with esmtp id 1MOSNP-0000Nw-3m for ; Wed, 08 Jul 2009 10:19:39 +0200 Received: from 82-170-177-25.ip.telfort.nl (localhost [127.0.0.1]) by sjakie.klop.ws (Postfix) with ESMTP id 60E6AD4F6 for ; Wed, 8 Jul 2009 10:19:38 +0200 (CEST) Date: Wed, 08 Jul 2009 10:19:37 +0200 To: "freebsd-stable@freebsd.org" From: "Ronald Klop" Content-Type: text/plain; format=flowed; delsp=yes; charset=us-ascii MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Message-ID: User-Agent: Opera Mail/9.64 (FreeBSD) Subject: Zfs on usb-disk checksum errors? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2009 08:19:41 -0000 Hi. I put zfs on my external usb-disk, so I can backup my harddisk with zfs send/receive. I now have corruption on this volume. [root@sjakie ~]# zpool status -v pool: extern state: ONLINE status: One or more devices has experienced an error resulting in data corruption. Applications may be affected. action: Restore the file in question if possible. Otherwise restore the entire pool from backup. see: http://www.sun.com/msg/ZFS-8000-8A scrub: scrub completed after 0h2m with 0 errors on Wed Jul 8 00:35:09 2009 config: NAME STATE READ WRITE CKSUM extern ONLINE 1 0 0 da0 ONLINE 9 0 0 errors: Permanent errors have been detected in the following files: <0x3f>:<0xf5d6> I don't really understand which files have corruption. :-( In my syslog is this: (repeated quite often) Jul 8 10:00:37 sjakie kernel: (da0:umass-sim0:0:0:0): SYNCHRONIZE CACHE(10). CDB: 35 0 0 0 0 0 0 0 0 0 Jul 8 10:00:37 sjakie kernel: (da0:umass-sim0:0:0:0): CAM Status: SCSI Status Error Jul 8 10:00:37 sjakie kernel: (da0:umass-sim0:0:0:0): SCSI Status: Check Condition Jul 8 10:00:37 sjakie kernel: (da0:umass-sim0:0:0:0): ILLEGAL REQUEST asc:20,0 Jul 8 10:00:37 sjakie kernel: (da0:umass-sim0:0:0:0): Invalid command operation code Jul 8 10:00:37 sjakie kernel: (da0:umass-sim0:0:0:0): Unretryable error and sometimes Jul 8 10:00:35 sjakie root: ZFS: vdev I/O failure, zpool=extern path=/dev/da0 offset=127558877184 size=3072 error=5 Jul 8 10:00:35 sjakie root: ZFS: vdev I/O failure, zpool=extern path=/dev/da0 offset=127558877184 size=3072 error=5 Jul 8 10:00:35 sjakie root: ZFS: zpool I/O failure, zpool=extern error=5 With varying offsets and sizes. What can I conclude from this? Is the disk failing? Is the 'Invalid command operation code' something to worry about? It didn't show up when the disk was UFS. I reinstalled the pool but the read-errors showed up again. Thanks for any advice, Ronald. From owner-freebsd-stable@FreeBSD.ORG Wed Jul 8 08:38:05 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 782791065670; Wed, 8 Jul 2009 08:38:05 +0000 (UTC) (envelope-from petefrench@ticketswitch.com) Received: from constantine.ticketswitch.com (constantine.ticketswitch.com [IPv6:2002:57e0:1d4e:1::3]) by mx1.freebsd.org (Postfix) with ESMTP id 3EE698FC21; Wed, 8 Jul 2009 08:38:05 +0000 (UTC) (envelope-from petefrench@ticketswitch.com) Received: from dilbert.rattatosk ([10.64.50.6] helo=dilbert.ticketswitch.com) by constantine.ticketswitch.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MOSfB-000BsX-HJ; Wed, 08 Jul 2009 09:38:01 +0100 Received: from petefrench by dilbert.ticketswitch.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MOSfB-0004Rl-GS; Wed, 08 Jul 2009 09:38:01 +0100 To: bp@barryp.org, dan.naumov@gmail.com In-Reply-To: <4A53ED2D.4070309@barryp.org> Message-Id: From: Pete French Date: Wed, 08 Jul 2009 09:38:01 +0100 Cc: freebsd-stable@freebsd.org, freebsd-geom@freebsd.org Subject: Re: glabel metadata protection (WAS: ZFS: drive replacement performance) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2009 08:38:05 -0000 > I would say in this case you're *not* giving the entire disk to the > pool, you're giving ZFS a geom that's one sector smaller than the disk. > ZFS never sees or can touch the glabel metadata. Is ZFS happy if the size of it's disc changes underneath it ? I have expanded a zpool a couple of times simply by changing the size of the partition and rebooting the machine - it comes up with the new amount of free space fine. Never tried it the other way though. The reason I mention it is that someone suggested glabeling a drive in an existing pool and using replace to swap it over. Which should be good I guess unless the last sector was in use. ZFS spreads stuff all over the disc as I unserdtand it though, so that might not be a good assumption, even on a fairly empty filesystem. -pete. From owner-freebsd-stable@FreeBSD.ORG Wed Jul 8 09:07:09 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C4FC9106564A for ; Wed, 8 Jul 2009 09:07:09 +0000 (UTC) (envelope-from john.marshall@riverwillow.com.au) Received: from mail1.riverwillow.net.au (mail1.riverwillow.net.au [203.58.93.36]) by mx1.freebsd.org (Postfix) with ESMTP id 453388FC14 for ; Wed, 8 Jul 2009 09:07:08 +0000 (UTC) (envelope-from john.marshall@riverwillow.com.au) Received: from rwpc12.mby.riverwillow.net.au (rwpc12.mby.riverwillow.net.au [172.25.24.168]) (authenticated bits=0) by mail1.riverwillow.net.au (8.14.3/8.14.3) with ESMTP id n688q311079376 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 8 Jul 2009 18:52:03 +1000 (AEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=riverwillow.com.au; s=m1001; t=1247043123; bh=v1uuv6a7iDQtoO9+4SUzHIp9eP9WDGhoU/qpbd6kxJw=; h=Date:From:To:Subject:Message-ID:Mime-Version:Content-Type; b=VICxM9TtfY3NyqqLcupQo3gTj1ZsYrsCRKGWM1mfWiF7wYPOxU5Qd8twwD5YguvQB rLdx5sdsbBz9r4yzGar55ZcZOdvuSSN0WqvjDwY6Q2BDmfMLwcX+VdVGOFbeK7Zmbw 1dG38TbSRFJM+CTXEGU7MI9YoeSvsW8+JbDlEnNs= Received: from rwpc12.mby.riverwillow.net.au (localhost [127.0.0.1]) by rwpc12.mby.riverwillow.net.au (8.14.3/8.14.3) with ESMTP id n688q3J8023143 for ; Wed, 8 Jul 2009 18:52:03 +1000 (AEST) (envelope-from john.marshall@riverwillow.com.au) Received: (from john@localhost) by rwpc12.mby.riverwillow.net.au (8.14.3/8.14.3/Submit) id n688q3vR023142 for freebsd-stable@freebsd.org; Wed, 8 Jul 2009 18:52:03 +1000 (AEST) (envelope-from john) Date: Wed, 8 Jul 2009 18:52:02 +1000 From: John Marshall To: freebsd-stable@freebsd.org Message-ID: <20090708085202.GS1025@rwpc12.mby.riverwillow.net.au> Mail-Followup-To: freebsd-stable@freebsd.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="zCKi3GIZzVBPywwA" Content-Disposition: inline User-Agent: Mutt/1.4.2.3i OpenPGP: id=A29A84A2; url=http://pki.riverwillow.net.au/pgp/johnmarshall.asc Subject: sshd GSSAPIAuthentication broken after 8.0-BETA1 upgrade X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2009 09:07:10 -0000 --zCKi3GIZzVBPywwA Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I source upgraded a (test) server here (i386) from 7.2-RELEASE-p2 to 8.0-BETA1 this morning. I use GSSAPI as the primary authentication method for sshd on that server. After the upgrade GSSAPI authentication stopped working and I can't get enough information to figure out why. Perhaps the newer version of Heimdal behaves differently? Perhaps the newer version of sshd behaves differently? If I run sshd with debug "-ddd" I see the following: debug1: attempt 1 failures 0 debug2: input_userauth_request: try method gssapi-with-mic debug3: mm_request_send entering: type 37 debug3: mm_request_receive_expect entering: type 38 debug3: mm_request_receive entering debug3: monitor_read: checking request 37 debug3: mm_request_send entering: type 38 debug3: mm_request_receive entering Postponed gssapi-with-mic for john from 192.0.2.123 port 57225 ssh2 debug3: mm_request_send entering: type 39 debug3: mm_request_receive_expect entering: type 40 debug3: mm_request_receive entering debug3: monitor_read: checking request 39 debug1: Received some client credentials debug3: mm_request_send entering: type 40 debug3: mm_request_receive entering debug3: mm_request_send entering: type 43 debug3: mm_request_receive_expect entering: type 44 debug3: mm_request_receive entering debug3: monitor_read: checking request 43 debug3: mm_request_send entering: type 44 debug3: mm_request_receive entering GSSAPI MIC check failed On the client side (with ssh -vvv) I see: debug3: preferred gssapi-with-mic,publickey,keyboard-interactive,password debug3: authmethod_lookup gssapi-with-mic debug3: remaining preferred: publickey,keyboard-interactive,password debug3: authmethod_is_enabled gssapi-with-mic debug1: Next authentication method: gssapi-with-mic debug2: we sent a gssapi-with-mic packet, wait for reply debug1: Delegating credentials debug1: Delegating credentials debug1: Authentications that can continue: publickey,gssapi-with-mic,keyboa= rd-interactive debug2: we did not send a packet, disable method Does anybody know of changes between existing STABLE releases and 8.0 which would cause this behaviour - and how to accommodate it? Do any strange Kerberos things need to be done as part of the upgrade? The client still happily authenticates via GSSAPI to sshd on our other 7.2-RELEASE servers. Subsequent authentication methods succeed on the 8.0-BETA1 sshd server, it's just GSSAPI that isn't working. Thanks. --=20 John Marshall --zCKi3GIZzVBPywwA Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEARECAAYFAkpUXjIACgkQw/tAaKKahKLQ3gCgvkdI2Wv2wGVCQ+C3IRW9SWXZ G1YAn1A73RWRibiy9hLOce42xGYTZM3R =b+RH -----END PGP SIGNATURE----- --zCKi3GIZzVBPywwA-- From owner-freebsd-stable@FreeBSD.ORG Wed Jul 8 09:50:37 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ACB421065677 for ; Wed, 8 Jul 2009 09:50:37 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by mx1.freebsd.org (Postfix) with ESMTP id 31C928FC19 for ; Wed, 8 Jul 2009 09:50:36 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: by fxm18 with SMTP id 18so4652433fxm.43 for ; Wed, 08 Jul 2009 02:50:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=e3Mjw4iMLL0atCyHwrluoh6bI0wCWyhFZu8ENkRDkRA=; b=Y6jG2xwj590Kr4D61kHS2Vl2Z9S4U5nE+OR5F3tPdPJ5x4CGviD9YWN8747RYz9zyf 1VnO2rH//WjYRFfkVW61W3E0KOWyc8LMdYvx78FTIpXaJSGs/qYXkEARUWSk6/nx/kCB obMwHEIRxv+e6linLIh+4UYzGPQMWaczAQ4MM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=W5Zlm8S1BQk1ENBM7tpET+510no8brahxv3cJ3QXYa/asDfMLTzAsRbIBHpwjRKqAI A4V97vF11QaNtVluyn6kx6xIhzjs5DvtildXUYv8Fon1um0MwKalqSfVtXEtL2TClAc8 LHEfVVRdbPNJRVIKXcD/W8ad2vksK2MYFgbmE= MIME-Version: 1.0 Sender: asmrookie@gmail.com Received: by 10.223.105.7 with SMTP id r7mr3243872fao.8.1247046636101; Wed, 08 Jul 2009 02:50:36 -0700 (PDT) In-Reply-To: References: <3bbf2fe10907061818v245abd0cgc3ca5073cb93aea4@mail.gmail.com> <3bbf2fe10907061827g35eaeb49g26cf6fdb64436ca7@mail.gmail.com> Date: Wed, 8 Jul 2009 11:50:36 +0200 X-Google-Sender-Auth: 229ed4d9e280b82e Message-ID: <3bbf2fe10907080250q35899d3dhc2f101b62c6e5306@mail.gmail.com> From: Attilio Rao To: Dan Naumov Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: FreeBSD-STABLE Mailing List Subject: Re: 7.2-release/amd64: panic, spin lock held too long X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2009 09:50:37 -0000 2009/7/8 Dan Naumov : > On Wed, Jul 8, 2009 at 3:57 AM, Dan Naumov wrote: >> On Tue, Jul 7, 2009 at 4:27 AM, Attilio Rao wrote: >>> 2009/7/7 Dan Naumov : >>>> On Tue, Jul 7, 2009 at 4:18 AM, Attilio Rao wrote: >>>>> 2009/7/7 Dan Naumov : >>>>>> I just got a panic following by a reboot a few seconds after running >>>>>> "portsnap update", /var/log/messages shows the following: >>>>>> >>>>>> Jul 7 03:49:38 atom syslogd: kernel boot file is /boot/kernel/kernel >>>>>> Jul 7 03:49:38 atom kernel: spin lock 0xffffffff80b3edc0 (sched lock >>>>>> 1) held by 0xffffff00017d8370 (tid 100054) too long >>>>>> Jul 7 03:49:38 atom kernel: panic: spin lock held too long >>>>> >>>>> That's a known bug, affecting -CURRENT as well. >>>>> The cpustop IPI is handled though an NMI, which means it could >>>>> interrupt a CPU in any moment, even while holding a spinlock, >>>>> violating one well known FreeBSD rule. >>>>> That means that the cpu can stop itself while the thread was holding >>>>> the sched lock spinlock and not releasing it (there is no way, modulo >>>>> highly hackish, to fix that). >>>>> In the while hardclock() wants to schedule something else to run and >>>>> got stuck on the thread lock. >>>>> >>>>> Ideal fix would involve not using a NMI for serving the cpustop while >>>>> having a cheap way (not making the common path too hard) to tell >>>>> hardclock() to avoid scheduling while cpustop is in flight. >>>>> >>>>> Thanks, >>>>> Attilio >>>> >>>> Any idea if a fix is being worked on and how unlucky must one be to >>>> run into this issue, should I expect it to happen again? Is it >>>> basically completely random? >>> >>> I'd like to work on that issue before BETA3 (and backport to >>> STABLE_7), I'm just time-constrained right now. >>> it is completely random. >>> >>> Thanks, >>> Attilio >> >> Ok, this is getting pretty bad, 23 hours later, I get the same kind of >> panic, the only difference is that instead of "portsnap update", this >> was triggered by "portsnap cron" which I have running between 3 and 4 >> am every day: >> >> Jul 8 03:03:49 atom kernel: ssppiinn lloocckk >> 00xxffffffffffffffff8800bb33eeddc400 ((sscchheedd lloocck k1 )0 )h >> ehledl db yb y 0x0xfffffffffff0f00001081735339760e 0( t(itdi d >> 10100006070)5 )t otoo ol olnogng >> Jul 8 03:03:49 atom kernel: p >> Jul 8 03:03:49 atom kernel: anic: spin lock held too long >> Jul 8 03:03:49 atom kernel: cpuid = 0 >> Jul 8 03:03:49 atom kernel: Uptime: 23h2m38s > > I have now tried repeating the problem by running "stress --cpu 8 --io > 8 --vm 4 --vm-bytes 1024M --timeout 600s --verbose" which pushed > system load into the 15.50 ballpark and simultaneously running > "portsnap fetch" and "portsnap update" but I couldn't manually trigger > the panic, it seems that this problem is indeed random (although it > baffles me why is it specifically portsnap triggering it). I have now > disabled powerd to check whether that makes any difference to system > stability. But is that happening at reboot time? Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-stable@FreeBSD.ORG Wed Jul 8 10:01:47 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D6212106564A for ; Wed, 8 Jul 2009 10:01:47 +0000 (UTC) (envelope-from lstewart@freebsd.org) Received: from lauren.room52.net (lauren.room52.net [210.50.193.198]) by mx1.freebsd.org (Postfix) with ESMTP id 6B09D8FC12 for ; Wed, 8 Jul 2009 10:01:47 +0000 (UTC) (envelope-from lstewart@freebsd.org) Received: from lstewart-laptop.caia.swin.edu.au (host86-150-124-14.range86-150.btcentralplus.com [86.150.124.14]) (authenticated bits=0) by lauren.room52.net (8.14.3/8.14.3) with ESMTP id n68A1avL048900 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 8 Jul 2009 20:01:40 +1000 (EST) (envelope-from lstewart@freebsd.org) Message-ID: <4A546E73.4050603@freebsd.org> Date: Wed, 08 Jul 2009 11:01:23 +0100 From: Lawrence Stewart User-Agent: Thunderbird 2.0.0.22 (X11/20090626) MIME-Version: 1.0 To: "Tonix (Antonio Nati)" References: <4A532938.2020207@interazioni.it> In-Reply-To: <4A532938.2020207@interazioni.it> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.8 required=5.0 tests=AWL,BAYES_40,RCVD_IN_PBL, RDNS_DYNAMIC,SPF_SOFTFAIL autolearn=disabled version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on lauren.room52.net Cc: freebsd-stable@freebsd.org Subject: Re: CARP in standard kernel? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2009 10:01:48 -0000 Tonix (Antonio Nati) wrote: > I saw in the past requests for adding carp in standard kernel. > As of today, is there any chance to have it in kernel, as loadable module? > It would semplify a lot usage of freebsd-ipdate, instead of rebuilduing > a custom kernel each time. See the freebsd-net@ "CARP as a module; followup thoughts" thread for a link to a patch. Cheers, Lawrence From owner-freebsd-stable@FreeBSD.ORG Wed Jul 8 10:18:43 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1AA64106566C for ; Wed, 8 Jul 2009 10:18:43 +0000 (UTC) (envelope-from hlh@restart.be) Received: from tignes.restart.be (tignes.restart.be [IPv6:2001:41d0:2:2d29:0:1::]) by mx1.freebsd.org (Postfix) with ESMTP id 9D7158FC21 for ; Wed, 8 Jul 2009 10:18:42 +0000 (UTC) (envelope-from hlh@restart.be) Received: from restart.be (avoriaz.tunnel.bel [IPv6:2001:41d0:2:2d29:1:ffff::]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "avoriaz.restart.be", Issuer "CA master" (verified OK)) by tignes.restart.be (Postfix) with ESMTPS id B314A4B4A; Wed, 8 Jul 2009 12:18:41 +0200 (CEST) Received: from morzine.restart.bel (morzine.restart.be [IPv6:2001:41d0:2:2d29:1:2::]) (authenticated bits=0) by restart.be (8.14.3/8.14.3) with ESMTP id n68AIbJU057227; Wed, 8 Jul 2009 12:18:37 +0200 (CEST) (envelope-from hlh@restart.be) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=restart.be; s=avoriaz; t=1247048321; bh=iuGtDv/vffu/VOfQ2Qp/SJIUbIdrfLNCd5/QtQHSBF0=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=aQUZLoDOjVFx9kbeGuYG3a5XvQ+6i5dyvvQT3GGxM/SvMsiurmP+SuTMCnmfuq3H7 b0NL6SgxZxGD+Q0vDFZfQ== DomainKey-Signature: a=rsa-sha1; s=avoriaz; d=restart.be; c=nofws; q=dns; h=message-id:date:from:organization:user-agent:mime-version:to:cc: subject:references:in-reply-to:content-type: content-transfer-encoding:x-scanned-by; b=ysIFCz07zKckLfxnmyEa4IV2PG2i7m8oXooDvckgIqAVEgfA1SPjgsrcGfmGQq2pu DRx4mhcxYpfeAUU6xG28w== Message-ID: <4A54727D.9080205@restart.be> Date: Wed, 08 Jul 2009 12:18:37 +0200 From: Henri Hennebert Organization: RestartSoft User-Agent: Thunderbird 2.0.0.22 (X11/20090627) MIME-Version: 1.0 To: Ronald Klop References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.64 on IPv6:2001:41d0:2:2d29:1:1:: Cc: "freebsd-stable@freebsd.org" Subject: Re: Zfs on usb-disk checksum errors? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2009 10:18:43 -0000 Ronald Klop wrote: > Hi. > > I put zfs on my external usb-disk, so I can backup my harddisk with zfs > send/receive. > I now have corruption on this volume. > > [root@sjakie ~]# zpool status -v > pool: extern > state: ONLINE > status: One or more devices has experienced an error resulting in data > corruption. Applications may be affected. > action: Restore the file in question if possible. Otherwise restore the > entire pool from backup. > see: http://www.sun.com/msg/ZFS-8000-8A > scrub: scrub completed after 0h2m with 0 errors on Wed Jul 8 00:35:09 > 2009 > config: > > NAME STATE READ WRITE CKSUM > extern ONLINE 1 0 0 > da0 ONLINE 9 0 0 > > errors: Permanent errors have been detected in the following files: > > <0x3f>:<0xf5d6> > > I don't really understand which files have corruption. :-( > In my syslog is this: (repeated quite often) > Jul 8 10:00:37 sjakie kernel: (da0:umass-sim0:0:0:0): SYNCHRONIZE > CACHE(10). CDB: 35 0 0 0 0 0 0 0 0 0 > Jul 8 10:00:37 sjakie kernel: (da0:umass-sim0:0:0:0): CAM Status: SCSI > Status Error > Jul 8 10:00:37 sjakie kernel: (da0:umass-sim0:0:0:0): SCSI Status: > Check Condition > Jul 8 10:00:37 sjakie kernel: (da0:umass-sim0:0:0:0): ILLEGAL REQUEST > asc:20,0 > Jul 8 10:00:37 sjakie kernel: (da0:umass-sim0:0:0:0): Invalid command > operation code > Jul 8 10:00:37 sjakie kernel: (da0:umass-sim0:0:0:0): Unretryable error > I experience the same error with 'Kingston DataTraveler II 1.13'. I simply add in /usr/src/sys/dev/usb/usbdevs: product KINGSTON DATATRAVELER_2 0x1600 DAtaTraveler II (VENDOR was already in the file). and in sys/dev/usb/storage/umass.c: { USB_VENDOR_KINGSTON, USB_PRODUCT_KINGSTON_DATATRAVELER_2, RID_WILDCARD, UMASS_PROTO_SCSI | UMASS_PROTO_BBB, NO_SYNCHRONIZE_CACHE }, Note the flag NO_SYNCHRONIZE_CACHE and everything return to normal. PS - I encounter this problem on 7.2_STABLE with the MFC of ZFS v13. Henri > and sometimes > Jul 8 10:00:35 sjakie root: ZFS: vdev I/O failure, zpool=extern > path=/dev/da0 offset=127558877184 size=3072 error=5 > Jul 8 10:00:35 sjakie root: ZFS: vdev I/O failure, zpool=extern > path=/dev/da0 offset=127558877184 size=3072 error=5 > Jul 8 10:00:35 sjakie root: ZFS: zpool I/O failure, zpool=extern error=5 > With varying offsets and sizes. > > What can I conclude from this? Is the disk failing? Is the 'Invalid > command operation code' something to worry about? It didn't show up when > the disk was UFS. > > I reinstalled the pool but the read-errors showed up again. > > Thanks for any advice, > > Ronald. > _______________________________________________ > 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 Jul 8 12:11:32 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B6AA81065673 for ; Wed, 8 Jul 2009 12:11:32 +0000 (UTC) (envelope-from Hans.F.Nordhaug@hiMolde.no) Received: from sil.himolde.no (sil.hiMolde.no [158.38.83.3]) by mx1.freebsd.org (Postfix) with ESMTP id E44038FC12 for ; Wed, 8 Jul 2009 12:11:31 +0000 (UTC) (envelope-from Hans.F.Nordhaug@hiMolde.no) Received: from malle.himolde.no ([158.38.68.22]) by sil.himolde.no with InterScan Message Security Suite; Wed, 08 Jul 2009 13:41:29 +0200 Received: from harr.himolde.no (harr.hiMolde.no [158.38.68.20])by malle.himolde.no (8.13.8/8.13.8) with ESMTP id n68BfRFc007266for ; Wed, 8 Jul 2009 13:41:27 +0200 Received: from harr.himolde.no (harr.himolde.no [127.0.0.1])by harr.himolde.no (8.13.1/8.13.1) with ESMTP id n68BfRRv022779for ; Wed, 8 Jul 2009 13:41:27 +0200 Received: (from nordhaug@localhost)by harr.himolde.no (8.13.1/8.13.1/Submit) id n68BfR4d022778for freebsd-stable@freebsd.org; Wed, 8 Jul 2009 13:41:27 +0200 Date: Wed, 8 Jul 2009 13:41:27 +0200 From: "Hans F. Nordhaug" To: freebsd-stable@freebsd.org Message-ID: <20090708114127.GA22749@hiMolde.no> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline User-Agent: Mutt/1.4.1i X-imss-version: 2.054 X-imss-result: Passed X-imss-approveListMatch: *@*.no Subject: portsnap and freebsd-update (metadata) failure X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2009 12:11:33 -0000 Hi! Quick question: Is it just me and my freshly installed FreeBSD 7.2 that fails when running freebsd-update or portsnap right now? With freebsd-update I tried update4 and update1. Just ask for more info, if it's needed to debug the problem. Best regards, Hans Nordhaug From owner-freebsd-stable@FreeBSD.ORG Wed Jul 8 12:22:13 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4FD47106564A for ; Wed, 8 Jul 2009 12:22:13 +0000 (UTC) (envelope-from tonix@interazioni.it) Received: from mx02.interazioni.net (mx02.interazioni.net [80.94.114.204]) by mx1.freebsd.org (Postfix) with ESMTP id 93D3A8FC15 for ; Wed, 8 Jul 2009 12:22:12 +0000 (UTC) (envelope-from tonix@interazioni.it) Received: (qmail 53586 invoked by uid 88); 8 Jul 2009 12:22:10 -0000 Received: from unknown (HELO ?192.168.56.198?) (tonix@interazioni.it@85.18.206.139) by relay.interazioni.net with ESMTPA; 8 Jul 2009 12:22:10 -0000 Message-ID: <4A548F72.6070601@interazioni.it> Date: Wed, 08 Jul 2009 14:22:10 +0200 From: "Tonix (Antonio Nati)" User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Lawrence Stewart References: <4A532938.2020207@interazioni.it> <4A546E73.4050603@freebsd.org> In-Reply-To: <4A546E73.4050603@freebsd.org> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: CARP in standard kernel? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2009 12:22:13 -0000 Lawrence Stewart ha scritto: > Tonix (Antonio Nati) wrote: >> I saw in the past requests for adding carp in standard kernel. >> As of today, is there any chance to have it in kernel, as loadable >> module? >> It would semplify a lot usage of freebsd-ipdate, instead of >> rebuilduing a custom kernel each time. > > See the freebsd-net@ "CARP as a module; followup thoughts" thread for > a link to a patch. > Conclusion of linked thread is not clear. CARP cannot be loadable, ok, but why cannot be included in standard kernel? The same for AltQ, IPFW, PF, or other features widely used. The most of ISP like me using FreeBSD will use at least one of these features, so we are excluded from freebsd-update. Thanks, Tonino > Cheers, > Lawrence > _______________________________________________ > 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" > -- ------------------------------------------------------------ Inter@zioni Interazioni di Antonio Nati http://www.interazioni.it tonix@interazioni.it ------------------------------------------------------------ From owner-freebsd-stable@FreeBSD.ORG Wed Jul 8 12:27:35 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 34106106567D for ; Wed, 8 Jul 2009 12:27:35 +0000 (UTC) (envelope-from tonix@interazioni.it) Received: from mx02.interazioni.net (mx02.interazioni.net [80.94.114.204]) by mx1.freebsd.org (Postfix) with ESMTP id 743868FC1B for ; Wed, 8 Jul 2009 12:27:34 +0000 (UTC) (envelope-from tonix@interazioni.it) Received: (qmail 55847 invoked by uid 88); 8 Jul 2009 12:27:33 -0000 Received: from unknown (HELO ?192.168.56.198?) (tonix@interazioni.it@85.18.206.139) by relay.interazioni.net with ESMTPA; 8 Jul 2009 12:27:33 -0000 Message-ID: <4A5490B5.4000708@interazioni.it> Date: Wed, 08 Jul 2009 14:27:33 +0200 From: "Tonix (Antonio Nati)" User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 CC: freebsd-stable@freebsd.org References: <4A532938.2020207@interazioni.it> <4A546E73.4050603@freebsd.org> <4A548F72.6070601@interazioni.it> In-Reply-To: <4A548F72.6070601@interazioni.it> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: CARP in standard kernel? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2009 12:27:37 -0000 Read again the linked thread, about loadable CARP. It can be done, patch is for version 8, but it is not sure it will be included. Any hope to have it, loadable or static doesn't matter, in 7.3? Thanks, Tonino Tonix (Antonio Nati) ha scritto: > Lawrence Stewart ha scritto: >> Tonix (Antonio Nati) wrote: >>> I saw in the past requests for adding carp in standard kernel. >>> As of today, is there any chance to have it in kernel, as loadable >>> module? >>> It would semplify a lot usage of freebsd-ipdate, instead of >>> rebuilduing a custom kernel each time. >> >> See the freebsd-net@ "CARP as a module; followup thoughts" thread for >> a link to a patch. >> > > Conclusion of linked thread is not clear. CARP cannot be loadable, ok, > but why cannot be included in standard kernel? > > The same for AltQ, IPFW, PF, or other features widely used. > The most of ISP like me using FreeBSD will use at least one of these > features, so we are excluded from freebsd-update. > > Thanks, > > Tonino > > >> Cheers, >> Lawrence >> _______________________________________________ >> 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" >> > > -- ------------------------------------------------------------ Inter@zioni Interazioni di Antonio Nati http://www.interazioni.it tonix@interazioni.it ------------------------------------------------------------ From owner-freebsd-stable@FreeBSD.ORG Wed Jul 8 16:36:04 2009 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1AF1E106568A for ; Wed, 8 Jul 2009 16:36:04 +0000 (UTC) (envelope-from gotb1496458_1495115_946881_1717761457@cmpgnr.com) Received: from mta16br.cmpgnr.com (mta16br.cmpgnr.com [216.24.227.16]) by mx1.freebsd.org (Postfix) with SMTP id BA0B48FC2F for ; Wed, 8 Jul 2009 16:36:03 +0000 (UTC) (envelope-from gotb1496458_1495115_946881_1717761457@cmpgnr.com) Message-ID: <9501410.1247069086350.KadaSegment.225.1@mta16br.cmpgnr.com> Date: Wed, 8 Jul 2009 12:04:46 -0400 (EDT) From: Classical Academic Press To: stable@freebsd.org Errors-To: gotb1496458_1495115_946881_1717761457@cmpgnr.com Content-Transfer-Encoding: quoted-printable X-Campaign: 1496458.1495115.946881.1717761457 Bounces-To: gotb1496458_1495115_946881_1717761457@cmpgnr.com MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: New Poetry and Bible Texts for Homeschoolers X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Classical Academic Press List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2009 16:36:04 -0000 = =09=09=09=09=09=09=09=09=09=09 =09=09 =09=09=09 [1]3D"" July 2009 =09=09 =09=09 = =09=09=09 =09=09=09=09The Art of Poetry by Christine Perrin, MFA= [2][=] Shipping by the end of July!= If you have ever felt mystified by, or unable to enjoy the signific= ance of poetry, this text will lead you step by step to an understanding an= d love of this branch of literature, guided by a gifted poet and teacher. = The Art of Poetry is a excellent middle school or high school curric= ulum; it will teach the practice of reading a poem slowly and carefully, in= troduce students to the elements of poetry (such as imagery and metaphor) a= nd the many forms that can make a poem, from sonnet to open verse. In the b= elief that practice is the best way to learn, this book is rich with explic= ations, exercises, and activities. A biography of each poet is also includ= ed, along with an audio CD featuring a reading of many of the poems. Also = available is a corresponding teacher's edition containing explications of e= very poem in the student text. Art of Poetry Offered Online<= br>Do you have a student who would like to study poetry with Christine Perr= in? Christine teaches poetry at the high school and college level (at Messi= ah College) and is offering an online course for 15 qualified students this= fall. If interested, please contact Christine directly at czperrin@gma= il.com. [3]Pre-Order and View Sample Chapters! Pre-Order Today! Song School Greek<= /font> [4][www.classicalacademicp=] Shipping by = the end of July! Song School Greek is a lively and gentle in= troduction to Koine Greek, the language of the New Testament, designed for = children in the early elementary grades. Each of the thirty-two weekly less= ons includes songs, fun vocabulary, illustrations, handwriting practice, st= ories, games and activities. Enjoyable, everyday vocabulary is introduced i= n weekly lessons to encourage and engage young students. A lively musical C= D, with a track corresponding to each chapter, is included in the program! = The Teacher's Edition will also include a DVD for parents and teachers, wi= th extra instruction, particularly for teachers who do not know Greek thems= elves! [5]Pre-Order and View Sample Chapters! <= font face=3D'Verdana,Arial, Helvetica,sans-serif' size=3D'2' class=3D'bold2= '>Now Available! God's Great Covenant Book = 2. [6][ggcOT1_M=] [7][ima=] God's Great Covenant, Old= Testament Two is now available, which means that the entire Old Testam= ent is now taught in the series. God's Great Covenant is a grammar = stage Bible curriculum, classical in it's pedagogy. It teaches the facts o= f the Bible to elementary students in a clear chronological narrative, with= God as the main character. The texts are Reformed and Covenantal in the= ir theological approach, and emphasize God's faithfulness through all histo= ry. The stories are told with simple elegance, appropriate for children, b= ut not compromising on the heart of the Biblical text, or God's character a= nd his justice and mercy. If you have been looking for a meaty and chron= ological, yet devotional study of the Bible for your children, this may be = just what you are looking for! And two texts teaching the New Testam= ent are on their way as well! Look for God's Great Covenant: New Testam= ent One next spring! It will focus entirely on Jesus' life in the Gosp= els. =09=09=09 =09=09=09 =09=09=09=09=09=09=09=09 =09=09=09=09 =09=09=09=09= =09=09=09=09[8] 3D"" =09=09=09=09 [9][3D"http:=] <= a name=3D"contentBlock1004"> [10][3D"htt=] [11]= [aa_MED.jpg"] =09=09=09 =09=09=09=09 =09=09=09 =09=09=09=09=A9Classical Academic Press3920 Market Street Camp Hill, PA 17011 ph: 866-730-0711 fax: 71= 7-730-0721 email: info@classicalsubjects.com www.classicalacademicpre= ss.com =09=09=09=09=09 =09=09 =09=09 You are subscribed as stable@freebsd.org. To unsubscribe please [12]click here. [aa_MED.jpg"] = References Visible links 1. 3D"http://cmpgnr.com/r.html?c=3D149= 2. 3D"http://cmpgnr.com/r.html?c=3D1496458&r=3D1495115&t=3D1= 3. 3D"http://cmpgnr.com/r.html?c=3D1496458&r=3D1495= 4. 3D"http://cmpgnr.com/r.html?c=3D1496458&r=3D= 5. 3D"http://cmpgnr.com/r.html?c=3D1496458&r=3D1495115&t= 6. 3D"http://cmpgnr.com/r.html?c=3D14964= 7. 3D"http://cmpgnr.com/r.html?c=3D1496= 8. 3D"http://cmpgnr.com/r.html?c=3D1496458&r=3D1495115&t= 9. 3D"http://cmpgnr=/ 10. 3D"http://cmpgnr.c=/ 11. =3D"http://cmpgnr.com/r.html?c=3D1496458&r=3D1495115&t=3D1717761457&l=3D1&d= 12. file://localhost/tmp/3D= Hidden links: 13. 3D"http://=/ From owner-freebsd-stable@FreeBSD.ORG Wed Jul 8 16:38:23 2009 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B72571065688 for ; Wed, 8 Jul 2009 16:38:23 +0000 (UTC) (envelope-from gotb1496464_1495121_946878_1717748658@cmpgnr.com) Received: from mta21br.cmpgnr.com (mta21br.cmpgnr.com [216.24.227.21]) by mx1.freebsd.org (Postfix) with SMTP id 4622D8FC27 for ; Wed, 8 Jul 2009 16:38:23 +0000 (UTC) (envelope-from gotb1496464_1495121_946878_1717748658@cmpgnr.com) Message-ID: <19118957.1247069146530.KadaSegment.227.3@mta21br.cmpgnr.com> Date: Wed, 8 Jul 2009 12:05:46 -0400 (EDT) From: Classical Academic Press To: stable@freebsd.org Errors-To: gotb1496464_1495121_946878_1717748658@cmpgnr.com Content-Transfer-Encoding: quoted-printable X-Campaign: 1496464.1495121.946878.1717748658 Bounces-To: gotb1496464_1495121_946878_1717748658@cmpgnr.com MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: New Poetry and Bible Texts for Homeschoolers X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Classical Academic Press List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2009 16:38:24 -0000 = =09=09=09=09=09=09=09=09=09=09 =09=09 =09=09=09 [1]3D"" July 2009 =09=09 =09=09 = =09=09=09 =09=09=09=09The Art of Poetry by Christine Perrin, MFA= [2][=] Shipping by the end of July!= If you have ever felt mystified by, or unable to enjoy the signific= ance of poetry, this text will lead you step by step to an understanding an= d love of this branch of literature, guided by a gifted poet and teacher. = The Art of Poetry is a excellent middle school or high school curric= ulum; it will teach the practice of reading a poem slowly and carefully, in= troduce students to the elements of poetry (such as imagery and metaphor) a= nd the many forms that can make a poem, from sonnet to open verse. In the b= elief that practice is the best way to learn, this book is rich with explic= ations, exercises, and activities. A biography of each poet is also includ= ed, along with an audio CD featuring a reading of many of the poems. Also = available is a corresponding teacher's edition containing explications of e= very poem in the student text. Art of Poetry Offered Online<= br>Do you have a student who would like to study poetry with Christine Perr= in? Christine teaches poetry at the high school and college level (at Messi= ah College) and is offering an online course for 15 qualified students this= fall. If interested, please contact Christine directly at czperrin@gma= il.com. [3]Pre-Order and View Sample Chapters! Pre-Order Today! Song School Greek<= /font> [4][www.classicalacademicp=] Shipping by = the end of July! Song School Greek is a lively and gentle in= troduction to Koine Greek, the language of the New Testament, designed for = children in the early elementary grades. Each of the thirty-two weekly less= ons includes songs, fun vocabulary, illustrations, handwriting practice, st= ories, games and activities. Enjoyable, everyday vocabulary is introduced i= n weekly lessons to encourage and engage young students. A lively musical C= D, with a track corresponding to each chapter, is included in the program! = The Teacher's Edition will also include a DVD for parents and teachers, wi= th extra instruction, particularly for teachers who do not know Greek thems= elves! [5]Pre-Order and View Sample Chapters! <= font face=3D'Verdana,Arial, Helvetica,sans-serif' size=3D'2' class=3D'bold2= '>Now Available! God's Great Covenant Book = 2. [6][ggcOT1_M=] [7][ima=] God's Great Covenant, Old= Testament Two is now available, which means that the entire Old Testam= ent is now taught in the series. God's Great Covenant is a grammar = stage Bible curriculum, classical in it's pedagogy. It teaches the facts o= f the Bible to elementary students in a clear chronological narrative, with= God as the main character. The texts are Reformed and Covenantal in the= ir theological approach, and emphasize God's faithfulness through all histo= ry. The stories are told with simple elegance, appropriate for children, b= ut not compromising on the heart of the Biblical text, or God's character a= nd his justice and mercy. If you have been looking for a meaty and chron= ological, yet devotional study of the Bible for your children, this may be = just what you are looking for! And two texts teaching the New Testam= ent are on their way as well! Look for God's Great Covenant: New Testam= ent One next spring! It will focus entirely on Jesus' life in the Gosp= els. =09=09=09 =09=09=09 =09=09=09=09=09=09=09=09 =09=09=09=09 =09=09=09=09= =09=09=09=09[8] 3D"" =09=09=09=09 [9][3D"http:=] <= a name=3D"contentBlock1004"> [10][3D"htt=] [11]= [aa_MED.jpg"] =09=09=09 =09=09=09=09 =09=09=09 =09=09=09=09=A9Classical Academic Press3920 Market Street Camp Hill, PA 17011 ph: 866-730-0711 fax: 71= 7-730-0721 email: info@classicalsubjects.com www.classicalacademicpre= ss.com =09=09=09=09=09 =09=09 =09=09 You are subscribed as stable@freebsd.org. To unsubscribe please [12]click here. [aa_MED.jpg"] = References Visible links 1. 3D"http://cmpgnr.com/r.html?c=3D149= 2. 3D"http://cmpgnr.com/r.html?c=3D1496464&r=3D1495121&t=3D1= 3. 3D"http://cmpgnr.com/r.html?c=3D1496464&r=3D1495= 4. 3D"http://cmpgnr.com/r.html?c=3D1496464&r=3D= 5. 3D"http://cmpgnr.com/r.html?c=3D1496464&r=3D1495121&t= 6. 3D"http://cmpgnr.com/r.html?c=3D14964= 7. 3D"http://cmpgnr.com/r.html?c=3D1496= 8. 3D"http://cmpgnr.com/r.html?c=3D1496464&r=3D1495121&t= 9. 3D"http://cmpgnr=/ 10. 3D"http://cmpgnr.c=/ 11. =3D"http://cmpgnr.com/r.html?c=3D1496464&r=3D1495121&t=3D1717748658&l=3D1&d= 12. file://localhost/tmp/3D= Hidden links: 13. 3D"http://=/ From owner-freebsd-stable@FreeBSD.ORG Wed Jul 8 18:12:55 2009 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9FCAF1065672 for ; Wed, 8 Jul 2009 18:12:55 +0000 (UTC) (envelope-from tex@unixteacher.org) Received: from smtp.linuxsecurity.us (ns.linuxsecurity.us [174.133.245.130]) by mx1.freebsd.org (Postfix) with ESMTP id 6A6C08FC13 for ; Wed, 8 Jul 2009 18:12:55 +0000 (UTC) (envelope-from tex@unixteacher.org) Received: from smtp.linuxsecurity.us (localhost [127.0.0.1]) by smtp.linuxsecurity.us (Postfix) with ESMTP id 53D60375801; Wed, 8 Jul 2009 19:53:01 +0200 (CEST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=selector1; d=unixteacher.org; h=Received:X-Virus-Scanned:Received:Received:Message-ID:From:To:Cc:References:In-Reply-To:Subject:Date:Organization:MIME-Version:Content-Type:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:Content-Transfer-Encoding; b=uuNty9Fi8K8LgfOlX42Kbx1pZrul5B7UexbeGKLES+6hrHHq6BJog7+mxBu5gK7vKLgfJTrbBO12Iaspep8W9RFmlHVEMYBwHjUoagBaYvZDjfSXigKSQ1e+xvUndO/y+dxFvHBhtNjjr1OxdIl2G/vj+/z4+XExpAO2anHAies=; Received: from localhost (localhost [127.0.0.1]) by smtp.linuxsecurity.us (Postfix) with ESMTP id 4B1F9375802; Wed, 8 Jul 2009 19:53:01 +0200 (CEST) X-Virus-Scanned: This header was added to track abuse. LINUX SECURITY GROUP - ANTI SPAM SOLUTIONS http://www.linux-security.us/ . For abuse/spam send e-mail with headers to abuse at unixteacher.org Received: from smtp.linuxsecurity.us ([127.0.0.1]) by localhost (linuxsecurity.us [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yf1MwmgO-Igt; Wed, 8 Jul 2009 19:52:21 +0200 (CEST) Received: from workstation (dslb-088-066-012-251.pools.arcor-ip.net [88.66.12.251]) by smtp.linuxsecurity.us (Postfix) with ESMTPA id CAC2B375801; Wed, 8 Jul 2009 19:52:20 +0200 (CEST) Message-ID: From: "Amza Marian" To: "Classical Academic Press" , References: <19118957.1247069146530.KadaSegment.227.3@mta21br.cmpgnr.com> In-Reply-To: <19118957.1247069146530.KadaSegment.227.3@mta21br.cmpgnr.com> Date: Wed, 8 Jul 2009 19:52:03 +0200 Organization: Linux Security Group MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6001.18000 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6001.18049 Content-Transfer-Encoding: quoted-printable Cc: info@classicalsubjects.com Subject: Re: New Poetry and Bible Texts for Homeschoolers X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2009 18:12:56 -0000 You are idiot ? That is email address for FreeBSD discussions. "You are subscribed as stable@freebsd.org. To unsubscribe please click ..= " In your bible there is no rules abut spammers :-P ----- Original Message -----=20 From: "Classical Academic Press" To: Sent: Wednesday, July 08, 2009 6:05 PM Subject: New Poetry and Bible Texts for Homeschoolers =3D09 [1]3D"" July 2009 =3D09 The Art of Poetry by Christine Perrin, MFA [2][=3D Shipping by the end of July!=3D If you have ever felt mystified by, or unable to enjoy the signific=20 ance of poetry, this text will lead you step by step to an understanding an=3D love of this branch of literature, guided by a gifted poet and teacher. =3Dhe Art of Poetry is a excellent middle school or high school curric=3Dlum; it will teach the practice of reading a poem slowly and carefully, in=3Droduce students to the elements of poetry (such as imagery and metaphor) a=3Dd the many forms that can make a poem, from sonnet to open verse. In the b=3Dlief that practice is the best way to learn, this book is rich with explic=20 ations, exercises, and activities. A biography of each poet is also includ=3Dd, along with an audio CD featuring a reading of many of the poems. Also =3Dvailable is a corresponding teacher's edition containing explications of e=3Dery poem in the student text. Art of Poetry Offered Online<=3Dr>Do you have a student who would like to study poetry with Christine Perr=3Dn? Christine teaches poetry at the high school and college level (at Messi=3Dh College) and is offering an online course for 15 qualified students this=3Dall. If interested, please contact Christine directly at czperrin@gma=3Dl.com. [3]Pre-Order and View Sample Chapters! Pre-Order Today! Song School Greek<=3Dfont> [4][www.classicalacademicp=3D Shipping by =3Dhe end of July! Song School Greek is a lively and gentle in=3Droduction to Koine Greek, the language of the New Testament, designed for =3Dhildren in the early elementary grades. Each of the thirty-two weekly less=3Dns includes songs, fun vocabulary, illustrations, handwriting practice, st=3Dries, games and activities. Enjoyable, everyday vocabulary is introduced i=3D weekly lessons to encourage and engage young students. A lively musical C=3D, with a track corresponding to each chapter, is included in the program! =3Dhe Teacher's Edition will also include a DVD for parents and teachers, wi=3Dh extra instruction, particularly for teachers who do not know Greek thems=3Dlves! [5]Pre-Order and View Sample Chapters! <=3Dont face=3D'Verdana,Arial, Helvetica,sans-serif' size=3D'2' class=3D'bold2=3D>Now Available! God's Great Covenant Book =3D. [6][ggcOT1_M=3D [7][ima=3DGod's Great Covenant, Old=3Destament Two is now available, which means that the entire Old Testam=3Dnt is now taught in the series. God's Great Covenant is a grammar =3Dtage Bible curriculum, classical in it's pedagogy. It teaches the facts o=3D the Bible to elementary students in a clear chronological narrative, with=3Dod as the main character. The texts are Reformed and Covenantal in the=3Dr theological approach, and emphasize God's faithfulness through all histo=3Dy. The stories are told with simple elegance, appropriate for children, b=3Dt not compromising on the heart of the Biblical text, or God's character a = nd=20 his justice and mercy. If you have been looking for a meaty and chron=3Dlogical, yet devotional study of the Bible for your children, this may be =3Dust what you are looking for! And two texts teaching the New Testam=3Dnt are on their way as well! Look for God's Great Covenant: New Testam=3Dnt One next spring! It will focus entirely on Jesus' life in the Gosp=3Dls. =3D09 [8] 3D"" [9][3D"http:=3D <=3D name=3D"contentBlock1004"> [10][3D"htt=3D [11]=3Daa_MED.jpg"] =A9Classical Academic Press3920 Market Street Camp Hill, PA 17011 ph: 866-730-0711 fax: 71=3D-730-0721 email: info@classicalsubjects.com www.classicalacademicpre=3Ds.com You are subscribed as stable@freebsd.org. To unsubscribe please [12]click here. [aa_MED.jpg"] References Visible links 1. 3D"http://cmpgnr.com/r.html?c=3D149 2.=20 3D"http://cmpgnr.com/r.html?c=3D1496464&r=3D1495121&t=3D1 3.=20 3D"http://cmpgnr.com/r.html?c=3D1496464&r=3D1495 4.=20 3D"http://cmpgnr.com/r.html?c=3D1496464&r=3D 5.=20 3D"http://cmpgnr.com/r.html?c=3D1496464&r=3D1495121&t 6.=20 3D"http://cmpgnr.com/r.html?c=3D14964 7. 3D"http://cmpgnr.com/r.html?c=3D= 1496=20 8. 3D"http://cmpgnr.com/r.html?c=3D1496464&r=3D1495121&t 9. 3D"http://c= mpgnr=3D 10. 3D"http://cmpgnr.c=3D 11. =3D"http://cmpgnr.com/r.html?c=3D1496464&r=3D1495121&t=3D1717748658= &l=3D1&d 12.=20 file://localhost/tmp/3D Hidden links: 13. 3D"http://=3D _______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"= =20 From owner-freebsd-stable@FreeBSD.ORG Wed Jul 8 19:45:33 2009 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 28F97106564A for ; Wed, 8 Jul 2009 19:45:33 +0000 (UTC) (envelope-from cm@therek.net) Received: from lux.therek.net (lux.therek.net [64.85.172.243]) by mx1.freebsd.org (Postfix) with ESMTP id D3E6A8FC22 for ; Wed, 8 Jul 2009 19:45:32 +0000 (UTC) (envelope-from cm@therek.net) Received: from frameshift.waw.therek.net (dixie.therek.net [82.210.167.89]) (authenticated bits=0) by lux.therek.net (8.14.3/8.14.3) with ESMTP id n68JWpfT032661 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Wed, 8 Jul 2009 21:32:53 +0200 (CEST) Message-ID: <4A54F462.4050800@therek.net> Date: Wed, 08 Jul 2009 21:32:50 +0200 From: Cezary Morga User-Agent: Thunderbird 2.0.0.22 (X11/20090701) MIME-Version: 1.0 To: Amza Marian References: <19118957.1247069146530.KadaSegment.227.3@mta21br.cmpgnr.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: stable@freebsd.org Subject: Re: New Poetry and Bible Texts for Homeschoolers X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2009 19:45:33 -0000 Amza Marian pisze: > You are idiot ? > That is email address for FreeBSD discussions. > > "You are subscribed as stable@freebsd.org. To unsubscribe please click .." > > In your bible there is no rules abut spammers :-P Way to go tiger! Answering an obvious spam is not very smart. Are you an eye-dee-ten-tee too? -- Cezary Morga "Middle age is when you've met so many people that every new person you meet reminds you of someone else." (Ogden Nash) From owner-freebsd-stable@FreeBSD.ORG Wed Jul 8 20:27:03 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6DB49106564A; Wed, 8 Jul 2009 20:27:03 +0000 (UTC) (envelope-from andreast-list@fgznet.ch) Received: from smtp.fgznet.ch (mail.fgznet.ch [81.92.96.47]) by mx1.freebsd.org (Postfix) with ESMTP id 080098FC0A; Wed, 8 Jul 2009 20:27:02 +0000 (UTC) (envelope-from andreast-list@fgznet.ch) Received: from deuterium.andreas.nets ([91.190.8.131]) by smtp.fgznet.ch (8.13.8/8.13.8/Submit_SMTPAUTH) with ESMTP id n68K1tO3037986; Wed, 8 Jul 2009 22:01:56 +0200 (CEST) (envelope-from andreast-list@fgznet.ch) Message-ID: <4A54FB33.8060705@fgznet.ch> Date: Wed, 08 Jul 2009 22:01:55 +0200 From: Andreas Tobler User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Ken Smith References: <1246926782.11597.23.camel@bauer.cse.buffalo.edu> In-Reply-To: <1246926782.11597.23.camel@bauer.cse.buffalo.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.64 on 81.92.96.47 Cc: freebsd-current , freebsd-stable Subject: Re: FreeBSD 8.0-BETA1 Available X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2009 20:27:04 -0000 Ken Smith wrote: > The amd64 and i386 architectures include a file named: > > 8.0-BETA1--memstick.img > > If you copy that to a USB memory stick newer machines should be able to > boot from it and use it to install from. Note that you need to > overwrite the contents of the memory stick completely, not copy it into > an existing filesystem on the memory stick. Exactly how you do that > depends on your machine but just to give you an example this works on > the machine I tested it with: > > dd if=8.0-BETA1-amd64-memstick.img of=/dev/da0 bs=10240 conv=sync > > Be careful if you have SCSI drives, more USB disks than just the memory > stick, etc - make sure /dev/da0 (or whatever you use) is the memory > stick. Using this image for livefs based rescue mode is known to not > work, that is one of the things still being worked on. Unfortunately my biggest mem stick has only 512MB. So I tried to dd to an usb drive. (Will get a bigger stick tomorrow) I was successful in installing the image, although, a few packages did not install. I did a kern developer package. I guess the packages are missing on the .img? Right now I'm installing the other things via net. Is this method equal to an usb stick install at all? Below the top of dmesg. TIA, Andreas --- Copyright (c) 1992-2009 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 8.0-BETA1 #0: Sat Jul 4 03:55:14 UTC 2009 root@almeida.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC WARNING: WITNESS option enabled, expect reduced performance. Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Pentium(R) 4 CPU 2.80GHz (2793.01-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf29 Stepping = 9 Features=0xbfebfbff Features2=0x4400 real memory = 536870912 (512 MB) avail memory = 473395200 (451 MB) --- From owner-freebsd-stable@FreeBSD.ORG Wed Jul 8 21:00:25 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4CC161065676 for ; Wed, 8 Jul 2009 21:00:25 +0000 (UTC) (envelope-from thomas@ronner.org) Received: from mail.knopje.net (mail.knopje.net [213.214.107.232]) by mx1.freebsd.org (Postfix) with ESMTP id 1074C8FC17 for ; Wed, 8 Jul 2009 21:00:25 +0000 (UTC) (envelope-from thomas@ronner.org) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.knopje.net (Postfix) with ESMTP id 23E133812B for ; Wed, 8 Jul 2009 22:30:59 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at knopje.net Received: from mail.knopje.net ([127.0.0.1]) by localhost (hal.knopje.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HiOKZQjs-eTU for ; Wed, 8 Jul 2009 22:30:58 +0200 (CEST) Received: from [192.168.28.106] (48-251.surfsnel.dsl.internl.net [145.99.251.48]) by mail.knopje.net (Postfix) with ESMTP id B31BC38103 for ; Wed, 8 Jul 2009 22:30:58 +0200 (CEST) From: Thomas Ronner To: freebsd-stable@freebsd.org Content-Type: text/plain Date: Wed, 08 Jul 2009 22:30:58 +0200 Message-Id: <1247085058.6197.18.camel@bugstore> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 7bit Subject: ZFS: zpool scrub lockup X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2009 21:00:25 -0000 Hello, I don't know whether this is the right list; maybe freebsd-fs is more appropriate. So please redirect me there if this isn't the right place. My system (i386, Athlon XP) locks hard when scrubbing a certain pool. It has been doing this for at least a couple of months now. For this reason I upgraded to 7.2-STABLE recently as this had the latest ZFS bits, but this doesn't help. It even makes the problem worse: in previous versions I just hit the reset button and forgot about it, but now it "remembers" that it was scrubbing (I presume) and tries to resume at the exact same place, locking up again. This means I haven't been able to mount these ZFS volumes successfully: the moment I do a /etc/rc.d/zfs start from single user mode (I have my /, /var and /usr on UFS) it locks up in a couple of seconds. And by locks up I really mean locks up. No panic, nothing. Pressing the reset button on the chassis is the only way to reboot. Details about my system: Athlon XP 2400+ Asus K7V-880 (VIA chipset; 2 IDE, 2 SATA ports) 2 GB RAM Promise Ultra133-TX2 (2 port IDE controller) Promise SATA150 4 port SATA controller Promise SATA300 4 port SATA controller 4 Maxtor 300 GB IDE disks 1 Maxtor 300 GB SATA disk 1 WD 320 GB SATA disk 6 Samsung 1 TB SATA disks The Samsung disks form the pool I'm having trouble with. They are connected to the Promise controllers. Does anyone know how I can debug this? I'm not even sure whether it is a software or a hardware problem. Any help is greatly appreciated! Regards, Thomas From owner-freebsd-stable@FreeBSD.ORG Thu Jul 9 03:41:47 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3CB6A1065744 for ; Thu, 9 Jul 2009 03:41:47 +0000 (UTC) (envelope-from john.marshall@riverwillow.com.au) Received: from mail1.riverwillow.net.au (mail1.riverwillow.net.au [203.58.93.36]) by mx1.freebsd.org (Postfix) with ESMTP id B15798FC2D for ; Thu, 9 Jul 2009 03:41:46 +0000 (UTC) (envelope-from john.marshall@riverwillow.com.au) Received: from rwpc12.mby.riverwillow.net.au (rwpc12.mby.riverwillow.net.au [172.25.24.168]) (authenticated bits=0) by mail1.riverwillow.net.au (8.14.3/8.14.3) with ESMTP id n692BKpF011699 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 9 Jul 2009 12:11:20 +1000 (AEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=riverwillow.com.au; s=m1001; t=1247105480; bh=zYNwprcqLNGTAzBNQwjNdSgkJ0Ia5+JkbaClIPTG1cw=; h=Date:From:To:Subject:Message-ID:Mime-Version:Content-Type; b=ysiun+15GphKO+52Sjy49Wio30JqTkKSbfF7HzrJqzkRTjDm92B4arIN/2YXqroEJ G9jcMEcYGRqqeQ9US13hUSQedNfPv99xfR8xfJW+JT783Br7KxYZ+mDXBtgOB/kpQ/ 2ikQScraR+8Yq/zu7jjfMhtHV4w4HA49OZgjkP+k= Received: from rwpc12.mby.riverwillow.net.au (localhost [127.0.0.1]) by rwpc12.mby.riverwillow.net.au (8.14.3/8.14.3) with ESMTP id n692BJLq026926 for ; Thu, 9 Jul 2009 12:11:20 +1000 (AEST) (envelope-from john.marshall@riverwillow.com.au) Received: (from john@localhost) by rwpc12.mby.riverwillow.net.au (8.14.3/8.14.3/Submit) id n692BJHv026925 for freebsd-stable@freebsd.org; Thu, 9 Jul 2009 12:11:19 +1000 (AEST) (envelope-from john) Date: Thu, 9 Jul 2009 12:11:19 +1000 From: John Marshall To: freebsd-stable@freebsd.org Message-ID: <20090709021119.GA26896@rwpc12.mby.riverwillow.net.au> Mail-Followup-To: freebsd-stable@freebsd.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="HlL+5n6rz5pIUxbD" Content-Disposition: inline User-Agent: Mutt/1.4.2.3i OpenPGP: id=A29A84A2; url=http://pki.riverwillow.net.au/pgp/johnmarshall.asc Subject: 8.0-BETA1 Source Upgrade breaks NTP configuration X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 03:41:47 -0000 --HlL+5n6rz5pIUxbD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Yesterday I source-upgraded a 7.2-RELEASE-p2 test i386 server to 8.0-BETA1. I have just discovered that it broke that server's NTP service. PROBLEM 1 - Existing /etc/ntp.conf overwritten For source upgrades I run "mergemaster -iCPU" and it has served me well until now. Mergemaster appeared to run "as normal" for this upgrade, prompting me for decisions on how to deal with the handful of usual files. It didn't tell me that it had decided to overwrite my existing /etc/ntp.conf with the new default version from the source tree! (OK, perhaps it told me in the big, long list at the end but it didn't prompt me to supersede my existing file). Looking at the mergemaster(8) man page, I can't see how the options I use would have resulted in my existing /etc/ntp.conf being overwritten with the version from the source tree - but obviously there is a woops factor there, either with me or mergemaster. Digging deeper, it looks like it may be due to the fact that this is a new supplied file and an entry for /etc/ntp.conf didn't exist in /var/db/mergemaster.mtree from the previous (7.2-RELEASE) run. How should this be handled? PROBLEM 2 - Default ntp.conf uses LOCAL clock So, having had the FreeBSD upgrade magically re-configure my NTP server (no, I wasn't prompted to overwrite ntp.conf), I find that my NTP server is now synchronizing with it's own (potentially wrong) local system clock! Our firewall is configured to allow NTP traffic between our internal NTP servers and specific upstream NTP servers. The default configuration file specifies different servers which we don't use, so this NTP server couldn't "see" them. The new default configuration file includes "127.127.1.0" as a configured server. Because we could see no "real" NTP servers, we synchronized with our local system clock. That means that we think we are synchronized to a reliable upstream source. Rather than losing synch and discovering the problem, we think we are synchronized to a reliable source and we and our clients drift away from reality in blissful ignorance. Surely this violates POLA! Could we *please* at least comment out the LOCAL server config in the supplied ntp.conf? Personally I would rather see it removed. It is one thing to tell people where the gun is if they want to shoot themselves in the foot; it's another thing to load it and fire it for them. I think it is good to have a default ntp.conf to help new users get started. I think it is a bad thing to include potentially dangerous elements in that configuration which could cause grief to a novice NTP administrator. If the default configuration provides scope for such surprises, they will (rightly) blame FreeBSD. --=20 John Marshall --HlL+5n6rz5pIUxbD Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEARECAAYFAkpVUccACgkQw/tAaKKahKKekACgrFW0bHE61nBAonhkxrJo+S/q M9IAnje/jr/xYFFbD0LYJK/W53vN3gqN =64Sy -----END PGP SIGNATURE----- --HlL+5n6rz5pIUxbD-- From owner-freebsd-stable@FreeBSD.ORG Thu Jul 9 03:42:37 2009 Return-Path: Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6C00A10656A3; Thu, 9 Jul 2009 03:42:37 +0000 (UTC) (envelope-from kensmith@cse.Buffalo.EDU) Received: from phoebe.cse.buffalo.edu (phoebe.cse.buffalo.edu [128.205.32.89]) by mx1.freebsd.org (Postfix) with ESMTP id A26C58FC27; Thu, 9 Jul 2009 03:42:36 +0000 (UTC) (envelope-from kensmith@cse.Buffalo.EDU) Received: from [128.205.32.76] (bauer.cse.buffalo.edu [128.205.32.76]) (authenticated bits=0) by phoebe.cse.buffalo.edu (8.14.1/8.13.7) with ESMTP id n692eN6c099086 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 8 Jul 2009 22:40:26 -0400 (EDT) (envelope-from kensmith@cse.buffalo.edu) From: Ken Smith To: Andreas Tobler In-Reply-To: <4A54FB33.8060705@fgznet.ch> References: <1246926782.11597.23.camel@bauer.cse.buffalo.edu> <4A54FB33.8060705@fgznet.ch> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-UtWhNAtrVEQmcGkzdMsW" Organization: U. Buffalo CSE Department Date: Wed, 08 Jul 2009 22:40:23 -0400 Message-Id: <1247107223.31816.7.camel@bauer.cse.buffalo.edu> Mime-Version: 1.0 X-Mailer: Evolution 2.24.5 FreeBSD GNOME Team Port X-DCC-Buffalo.EDU-Metrics: phoebe.cse.buffalo.edu 1336; Body=0 Fuz1=0 Fuz2=0 Cc: freebsd-current , freebsd-stable Subject: Re: FreeBSD 8.0-BETA1 Available X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 03:42:38 -0000 --=-UtWhNAtrVEQmcGkzdMsW Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed, 2009-07-08 at 22:01 +0200, Andreas Tobler wrote: > I was successful in installing the image, although, a few packages did=20 > not install. I did a kern developer package. I guess the packages are=20 > missing on the .img? Correct, no packages with BETA1. It's probably the documentation packages it went looking for and couldn't find. I'll be providing at least the docs packages with BETA2. Not sure if I'll start trying to provide a larger set of packages for the DVD or wait for BETA3 for that (leaning towards waiting at the moment). --=20 Ken Smith - From there to here, from here to | kensmith@cse.buffalo.edu there, funny things are everywhere. | - Theodore Geisel | --=-UtWhNAtrVEQmcGkzdMsW Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEABECAAYFAkpVWJcACgkQ/G14VSmup/Y05QCglHkXaBxkLwZTqCCaCAKUMZM6 k6cAn0fT/Vf2nSW3DLXlGtHpx/S9l67u =3q9j -----END PGP SIGNATURE----- --=-UtWhNAtrVEQmcGkzdMsW-- From owner-freebsd-stable@FreeBSD.ORG Thu Jul 9 04:43:35 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3333B106566C for ; Thu, 9 Jul 2009 04:43:35 +0000 (UTC) (envelope-from jonathan@kc8onw.net) Received: from vps.kc8onw.net (kc8onw.net [69.31.85.203]) by mx1.freebsd.org (Postfix) with ESMTP id 0B9B28FC12 for ; Thu, 9 Jul 2009 04:43:34 +0000 (UTC) (envelope-from jonathan@kc8onw.net) Received: from [10.70.3.194] (in-67-236-240-112.dhcp.embarqhsd.net [67.236.240.112]) by vps.kc8onw.net (Postfix) with ESMTPSA id B94EF17031; Wed, 8 Jul 2009 21:03:51 -0400 (EDT) Message-ID: <4A5541E9.2050801@kc8onw.net> Date: Wed, 08 Jul 2009 21:03:37 -0400 From: Jonathan User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b3pre) Gecko/20090223 Thunderbird/3.0b2 MIME-Version: 1.0 To: "Mahlon E. Smith" , freebsd-stable@freebsd.org References: <20090707195614.GA24326@martini.nu> <20090707222631.GA70750@martini.nu> <20090708001336.GA95670@martini.nu> In-Reply-To: <20090708001336.GA95670@martini.nu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: ZFS: drive replacement performance X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 04:43:35 -0000 On 7/7/2009 8:13 PM, Mahlon E. Smith wrote: > I also tried another export/import cycle, in the random hope that would > stop the active replace -- no dice. *However*, on the import, now I see > this flooding my console (wasn't there previously, strangely): > > Jul 7 16:50:15 disobedience root: ZFS: vdev I/O failure, zpool=store path=/dev/da2 offset=262144 size=8192 error=6 > Jul 7 16:50:15 disobedience root: ZFS: vdev I/O failure, zpool=store path=/dev/da2 offset=499988824064 size=8192 error=6 I actually just had this exact issue with a dead drive, controller renumbering, and vdev I/O failure. I eventually shut the system down completely, pulled the new drive, checked all the drive connections, powered the machine back up without the new drive. Then I inserted the new drive and initiated a scan for it. Apparently ZFS doesn't realize when a resilver is partially done because it resilvered in a matter of seconds at this point. I then did a scrub which found several million checksum errors but successfully corrected the pool without any vdev I/O failure errors. I hope this helps, Jonathan Stewart From owner-freebsd-stable@FreeBSD.ORG Thu Jul 9 07:15:44 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 90B7E1065679 for ; Thu, 9 Jul 2009 07:15:44 +0000 (UTC) (envelope-from aw1@stade.co.uk) Received: from v-smtp-auth-relay-1.gradwell.net (v-smtp-auth-relay-1.gradwell.net [79.135.125.40]) by mx1.freebsd.org (Postfix) with ESMTP id EB86B8FC1C for ; Thu, 9 Jul 2009 07:15:43 +0000 (UTC) (envelope-from aw1@stade.co.uk) Received: from 93-97-22-18.zone5.bethere.co.uk ([93.97.22.18] helo=access2.hanley.stade.co.uk) by v-smtp-auth-relay-1.gradwell.net with esmtp (Gradwell gwh-smtpd 1.290) id 4a552273.3520.16d; Wed, 8 Jul 2009 23:49:23 +0100 (envelope-sender ) Received: from steerpike.hanley.stade.co.uk (steerpike [192.168.1.10]) by access2.hanley.stade.co.uk (8.14.1/8.14.1) with ESMTP id n68MnM9O049249; Wed, 8 Jul 2009 23:49:22 +0100 (BST) (envelope-from aw1@steerpike.hanley.stade.co.uk) Received: from steerpike.hanley.stade.co.uk (localhost [127.0.0.1]) by steerpike.hanley.stade.co.uk (8.14.3/8.14.3) with ESMTP id n68MnMuL090571; Wed, 8 Jul 2009 23:49:22 +0100 (BST) (envelope-from aw1@steerpike.hanley.stade.co.uk) Received: (from aw1@localhost) by steerpike.hanley.stade.co.uk (8.14.3/8.14.3/Submit) id n68MnMcY090570; Wed, 8 Jul 2009 23:49:22 +0100 (BST) (envelope-from aw1) Date: Wed, 8 Jul 2009 23:49:21 +0100 From: Adrian Wontroba To: Drew Tomlinson Message-ID: <20090708224921.GA81685@steerpike.hanley.stade.co.uk> Mail-Followup-To: Adrian Wontroba , Drew Tomlinson , freebsd-stable@freebsd.org References: <4A53FC1B.5090303@mykitchentable.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A53FC1B.5090303@mykitchentable.net> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-PRERELEASE Organization: Oh dear, I've joined one again. X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on steerpike.hanley.stade.co.uk X-Virus-Status: Clean Cc: freebsd-stable@freebsd.org Subject: Re: Help With Custom Disk Layout For New Install X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: aw1@stade.co.uk List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 07:15:44 -0000 On Tue, Jul 07, 2009 at 06:53:31PM -0700, Drew Tomlinson wrote: > ... gmirror fails silently (i.e. nothing exists in /dev/mirror). ... I can't speak for the rest of your post but have you got the following in /boot/loader.conf? geom_mirror_load="YES" -- Adrian Wontroba It is far better to be deceived than to be undeceived by those we love. From owner-freebsd-stable@FreeBSD.ORG Thu Jul 9 11:05:09 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B0812106567B for ; Thu, 9 Jul 2009 11:05:09 +0000 (UTC) (envelope-from vince@unsane.co.uk) Received: from unsane.co.uk (unsane-pt.tunnel.tserv5.lon1.ipv6.he.net [IPv6:2001:470:1f08:110::2]) by mx1.freebsd.org (Postfix) with ESMTP id EA1998FC25 for ; Thu, 9 Jul 2009 11:05:08 +0000 (UTC) (envelope-from vince@unsane.co.uk) Received: from vhoffman.lon.namesco.net (150.117-84-212.staticip.namesco.net [212.84.117.150]) (authenticated bits=0) by unsane.co.uk (8.14.3/8.14.0) with ESMTP id n69B81vF015990 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 9 Jul 2009 12:08:04 +0100 (BST) (envelope-from vince@unsane.co.uk) Message-ID: <4A55CEDF.6010702@unsane.co.uk> Date: Thu, 09 Jul 2009 12:05:03 +0100 From: Vincent Hoffman User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <20090709021119.GA26896@rwpc12.mby.riverwillow.net.au> In-Reply-To: <20090709021119.GA26896@rwpc12.mby.riverwillow.net.au> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: 8.0-BETA1 Source Upgrade breaks NTP configuration X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 11:05:12 -0000 John Marshall wrote: > Yesterday I source-upgraded a 7.2-RELEASE-p2 test i386 server to > 8.0-BETA1. I have just discovered that it broke that server's NTP > service. > > PROBLEM 1 - Existing /etc/ntp.conf overwritten > > > Digging deeper, it looks like it may be due to the fact that this is a > new supplied file and an entry for /etc/ntp.conf didn't exist in > /var/db/mergemaster.mtree from the previous (7.2-RELEASE) run. How > should this be handled? you are correct, There was a thread on -CURRENT about this recently see http://lists.freebsd.org/pipermail/freebsd-current/2009-July/008968.html I think there was discussion of a patch to mergemaster. > > PROBLEM 2 - Default ntp.conf uses LOCAL clock > Again much discussed, a new improved version using freebsd.pool.ntp.org and commenting out the LOCAL option was posted to the freebsd-net list not long ago by David MAlone, hopefully to be applied soon. Vince From owner-freebsd-stable@FreeBSD.ORG Thu Jul 9 11:25:15 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 169431065673 for ; Thu, 9 Jul 2009 11:25:15 +0000 (UTC) (envelope-from hausen@punkt.de) Received: from kagate.punkt.de (kagate.punkt.de [217.29.33.131]) by mx1.freebsd.org (Postfix) with ESMTP id 9C5CE8FC14 for ; Thu, 9 Jul 2009 11:25:14 +0000 (UTC) (envelope-from hausen@punkt.de) Received: from hugo10.ka.punkt.de (hugo10.ka.punkt.de [10.0.0.110]) by kagate1.punkt.de with ESMTP id n69BPDos013171 for ; Thu, 9 Jul 2009 13:25:13 +0200 (CEST) Received: from hugo10.ka.punkt.de (localhost [127.0.0.1]) by hugo10.ka.punkt.de (8.14.2/8.14.2) with ESMTP id n69BPCFZ046467 for ; Thu, 9 Jul 2009 13:25:12 +0200 (CEST) (envelope-from ry93@hugo10.ka.punkt.de) Received: (from ry93@localhost) by hugo10.ka.punkt.de (8.14.2/8.14.2/Submit) id n69BPCjw046466 for freebsd-stable@freebsd.org; Thu, 9 Jul 2009 13:25:12 +0200 (CEST) (envelope-from ry93) Date: Thu, 9 Jul 2009 13:25:12 +0200 From: "Patrick M. Hausen" To: FreeBSD Stable Mailing List Message-ID: <20090709112512.GA44158@hugo10.ka.punkt.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.5.17 (2007-11-01) Subject: ZFS - thanks X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 11:25:15 -0000 Hi, all, I just wanted to say a big big thank you to Kip and all the developers who made ZFS on FreeBSD real. And to everyone who provided helpful comments in the last couple of days. I had to delete and rebuild my zpool to switch from a 12-disk raidz2 to two 6-disk ones, but yesterday I could replace the raw devices with glabel devices and practice replacing a failed disk at the same time. ;-) So now we have this setup: NAME STATE READ WRITE CKSUM zfs ONLINE 0 0 0 raidz2 ONLINE 0 0 0 label/disk100 ONLINE 0 0 0 label/disk101 ONLINE 0 0 0 label/disk102 ONLINE 0 0 0 label/disk103 ONLINE 0 0 0 label/disk104 ONLINE 0 0 0 label/disk105 ONLINE 0 0 0 raidz2 ONLINE 0 0 0 label/disk106 ONLINE 0 0 0 label/disk107 ONLINE 0 0 0 label/disk108 ONLINE 0 0 0 label/disk109 ONLINE 0 0 0 label/disk110 ONLINE 0 0 0 label/disk111 ONLINE 0 0 0 which will get another enclosure with 6 750-GB-disks, soon. I really like the way I can manage storage from the operating system without propriatary controller management software or even rebooting into the BIOS. Kind regards, Patrick -- punkt.de GmbH * Kaiserallee 13a * 76133 Karlsruhe Tel. 0721 9109 0 * Fax 0721 9109 100 info@punkt.de http://www.punkt.de Gf: Jürgen Egeling AG Mannheim 108285 From owner-freebsd-stable@FreeBSD.ORG Thu Jul 9 12:17:43 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CB153106564A for ; Thu, 9 Jul 2009 12:17:43 +0000 (UTC) (envelope-from matheusber@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.178]) by mx1.freebsd.org (Postfix) with ESMTP id 94B178FC0A for ; Thu, 9 Jul 2009 12:17:43 +0000 (UTC) (envelope-from matheusber@gmail.com) Received: by wa-out-1112.google.com with SMTP id m38so24501waf.27 for ; Thu, 09 Jul 2009 05:17:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:received:received :message-id:in-reply-to:references:date:subject:from:to:user-agent :mime-version:content-type:content-transfer-encoding:x-priority :importance; bh=360hnSaaQYjoXzs8+HDmT7xUCzYDcdzCVmZdX2tObSU=; b=Ri77cimz9m4u77gf2R94Pfc79Be6PAs2Nm51NfYZ/nT2mp6mWAJChObKjUP/xrC1vw V9L0U440fFKXf2W6zUQQ9pgV5iYPyXjdt2gTaEK6Z0hRl+/zlQfAe6kxDslqj0CCgfJB q0mJEBhZJmEDlrWPAfYciF2COBQqgAuBHUCDo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:in-reply-to:references:date:subject:from:to :user-agent:mime-version:content-type:content-transfer-encoding :x-priority:importance; b=Jlb60NCtATsaNkhMJEOTMdF/GKmARfR7swsGw3O+ev3RVzEs428a5u3oKp5r+emXId VbT/Cl06ZXrRFyKXj3FD/TIrJYjsnMWA5uKMa2VyrHq+zJ+tCI/kuT/BHuGACpABKe3e a6kiP5eJWv5JMO2yq1p3LudflcGNDkfZUUbQk= Received: by 10.114.169.12 with SMTP id r12mr1211193wae.68.1247141863163; Thu, 09 Jul 2009 05:17:43 -0700 (PDT) Received: from cygnus.homeunix.com ([189.71.13.173]) by mx.google.com with ESMTPS id j28sm5551955waf.67.2009.07.09.05.17.40 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 09 Jul 2009 05:17:42 -0700 (PDT) Sender: Nenhum_de_Nos Received: by cygnus.homeunix.com (Postfix, from userid 80) id 8EB12B8083; Thu, 9 Jul 2009 09:17:35 -0300 (BRT) Received: from 189.93.27.2 (SquirrelMail authenticated user matheus) by cygnus.homeunix.com with HTTP; Thu, 9 Jul 2009 09:17:35 -0300 (BRT) Message-ID: <73a41d4b72d62b0bfe3d0fb7206376a8.squirrel@cygnus.homeunix.com> In-Reply-To: <20090709112512.GA44158@hugo10.ka.punkt.de> References: <20090709112512.GA44158@hugo10.ka.punkt.de> Date: Thu, 9 Jul 2009 09:17:35 -0300 (BRT) From: "Nenhum_de_Nos" To: freebsd-stable@freebsd.org User-Agent: SquirrelMail/1.4.15 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: Re: ZFS - thanks X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 12:17:44 -0000 On Thu, July 9, 2009 08:25, Patrick M. Hausen wrote: > Hi, all, > > I just wanted to say a big big thank you to Kip and all the > developers who made ZFS on FreeBSD real. > > And to everyone who provided helpful comments in the > last couple of days. > > I had to delete and rebuild my zpool to switch from a > 12-disk raidz2 to two 6-disk ones, but yesterday I could > replace the raw devices with glabel devices and practice > replacing a failed disk at the same time. ;-) > > So now we have this setup: > > NAME STATE READ WRITE CKSUM > zfs ONLINE 0 0 0 > raidz2 ONLINE 0 0 0 > label/disk100 ONLINE 0 0 0 > label/disk101 ONLINE 0 0 0 > label/disk102 ONLINE 0 0 0 > label/disk103 ONLINE 0 0 0 > label/disk104 ONLINE 0 0 0 > label/disk105 ONLINE 0 0 0 > raidz2 ONLINE 0 0 0 > label/disk106 ONLINE 0 0 0 > label/disk107 ONLINE 0 0 0 > label/disk108 ONLINE 0 0 0 > label/disk109 ONLINE 0 0 0 > label/disk110 ONLINE 0 0 0 > label/disk111 ONLINE 0 0 0 > > which will get another enclosure with 6 750-GB-disks, soon. > > I really like the way I can manage storage from the operating > system without propriatary controller management software or > even rebooting into the BIOS. > > Kind regards, > Patrick I've always been curious about this. is said not good to have many disks in one pool. ok then. but this layout you're using in here will have the same effect as the twelve disks in only one pool ? (the space here is the sum of both pools ?) thanks, matheus -- We will call you cygnus, The God of balance you shall be A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? http://en.wikipedia.org/wiki/Posting_style From owner-freebsd-stable@FreeBSD.ORG Thu Jul 9 12:25:42 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DEE3C1065676 for ; Thu, 9 Jul 2009 12:25:42 +0000 (UTC) (envelope-from dan.naumov@gmail.com) Received: from mail-yx0-f181.google.com (mail-yx0-f181.google.com [209.85.210.181]) by mx1.freebsd.org (Postfix) with ESMTP id 9970E8FC1E for ; Thu, 9 Jul 2009 12:25:42 +0000 (UTC) (envelope-from dan.naumov@gmail.com) Received: by yxe11 with SMTP id 11so168298yxe.3 for ; Thu, 09 Jul 2009 05:25:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=qKRNiPBj+WRctprZ873Mcatc73mZoumQ0n7cQ2xIla4=; b=dlzZ7I2SckkL9WiNMolmBbdkPnogMb/Ke39xqGpFXBSlsmf4qMtb19Miu88y3vq/yw v0azoLmB4WckEW4/Er5FtEhgUkhjZ4cvAivTYUgZNFumvbs3i+hr3+2LsdtgMjYbMM4E v/pQKJ3KjTqxiKQFRaGoFIWbfi8cJCNyTiysI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=bRGDVgg/z1QNwD4CQRrIKP6FcMhCgqVqHSN/qlW5bmq0d1JstEva78Qs9xpOIGRtvh c3/KdLA1KG2vpDzwOLEBzJpaixFxOWu5H6nKQK3/CRs1fw+xU+lLkRszOJUW/bevHKsh b9jazDgEIyeA7raWZx5Y08Iy5G0KZsteDCKXU= MIME-Version: 1.0 Received: by 10.100.3.7 with SMTP id 7mr952188anc.99.1247142341794; Thu, 09 Jul 2009 05:25:41 -0700 (PDT) In-Reply-To: <73a41d4b72d62b0bfe3d0fb7206376a8.squirrel@cygnus.homeunix.com> References: <20090709112512.GA44158@hugo10.ka.punkt.de> <73a41d4b72d62b0bfe3d0fb7206376a8.squirrel@cygnus.homeunix.com> Date: Thu, 9 Jul 2009 15:25:41 +0300 Message-ID: From: Dan Naumov To: Nenhum_de_Nos Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org Subject: Re: ZFS - thanks X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 12:25:43 -0000 On Thu, Jul 9, 2009 at 3:17 PM, Nenhum_de_Nos wro= te: > > On Thu, July 9, 2009 08:25, Patrick M. Hausen wrote: >> Hi, all, >> >> I just wanted to say a big big thank you to Kip and all the >> developers who made ZFS on FreeBSD real. >> >> And to everyone who provided helpful comments in the >> last couple of days. >> >> I had to delete and rebuild my zpool to switch from a >> 12-disk raidz2 to two 6-disk ones, but yesterday I could >> replace the raw devices with glabel devices and practice >> replacing a failed disk at the same time. ;-) >> >> So now we have this setup: >> >> =A0 =A0 =A0 NAME =A0 =A0 =A0 =A0 =A0 =A0 =A0 STATE =A0 =A0 READ WRITE CK= SUM >> =A0 =A0 =A0 zfs =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ONLINE =A0 =A0 =A0 0 =A0 = =A0 0 =A0 =A0 0 >> =A0 =A0 =A0 =A0 raidz2 =A0 =A0 =A0 =A0 =A0 ONLINE =A0 =A0 =A0 0 =A0 =A0 = 0 =A0 =A0 0 >> =A0 =A0 =A0 =A0 =A0 label/disk100 =A0ONLINE =A0 =A0 =A0 0 =A0 =A0 0 =A0 = =A0 0 >> =A0 =A0 =A0 =A0 =A0 label/disk101 =A0ONLINE =A0 =A0 =A0 0 =A0 =A0 0 =A0 = =A0 0 >> =A0 =A0 =A0 =A0 =A0 label/disk102 =A0ONLINE =A0 =A0 =A0 0 =A0 =A0 0 =A0 = =A0 0 >> =A0 =A0 =A0 =A0 =A0 label/disk103 =A0ONLINE =A0 =A0 =A0 0 =A0 =A0 0 =A0 = =A0 0 >> =A0 =A0 =A0 =A0 =A0 label/disk104 =A0ONLINE =A0 =A0 =A0 0 =A0 =A0 0 =A0 = =A0 0 >> =A0 =A0 =A0 =A0 =A0 label/disk105 =A0ONLINE =A0 =A0 =A0 0 =A0 =A0 0 =A0 = =A0 0 >> =A0 =A0 =A0 =A0 raidz2 =A0 =A0 =A0 =A0 =A0 ONLINE =A0 =A0 =A0 0 =A0 =A0 = 0 =A0 =A0 0 >> =A0 =A0 =A0 =A0 =A0 label/disk106 =A0ONLINE =A0 =A0 =A0 0 =A0 =A0 0 =A0 = =A0 0 >> =A0 =A0 =A0 =A0 =A0 label/disk107 =A0ONLINE =A0 =A0 =A0 0 =A0 =A0 0 =A0 = =A0 0 >> =A0 =A0 =A0 =A0 =A0 label/disk108 =A0ONLINE =A0 =A0 =A0 0 =A0 =A0 0 =A0 = =A0 0 >> =A0 =A0 =A0 =A0 =A0 label/disk109 =A0ONLINE =A0 =A0 =A0 0 =A0 =A0 0 =A0 = =A0 0 >> =A0 =A0 =A0 =A0 =A0 label/disk110 =A0ONLINE =A0 =A0 =A0 0 =A0 =A0 0 =A0 = =A0 0 >> =A0 =A0 =A0 =A0 =A0 label/disk111 =A0ONLINE =A0 =A0 =A0 0 =A0 =A0 0 =A0 = =A0 0 >> >> which will get another enclosure with 6 750-GB-disks, soon. >> >> I really like the way I can manage storage from the operating >> system without propriatary controller management software or >> even rebooting into the BIOS. >> >> Kind regards, >> Patrick > > I've always been curious about this. is said not good to have many disks > in one pool. ok then. but this layout you're using in here will have the > same effect as the twelve disks in only one pool ? (the space here is the > sum of both pools ?) Having an enormous pool consisting of dozens of disks is not the actual problem. Having the pool consist of large (> 9 disks) raidz/raidz2 "groups" is. A single pool consising of 5 x 8 disk raidz (40 disks total) is fine. A single pool consisting of a 40 (or any amount bigger than 9) disk raidz is not. - Sincerely, Dan Naumov From owner-freebsd-stable@FreeBSD.ORG Thu Jul 9 12:30:45 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EB153106566B for ; Thu, 9 Jul 2009 12:30:44 +0000 (UTC) (envelope-from matheusber@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.176]) by mx1.freebsd.org (Postfix) with ESMTP id B26058FC1D for ; Thu, 9 Jul 2009 12:30:44 +0000 (UTC) (envelope-from matheusber@gmail.com) Received: by wa-out-1112.google.com with SMTP id m38so26008waf.27 for ; Thu, 09 Jul 2009 05:30:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:received:received :message-id:in-reply-to:references:date:subject:from:to:user-agent :mime-version:content-type:content-transfer-encoding:x-priority :importance; bh=w1PJZCRrzFqxOpdchKDNrfDDwBQDLe1e/7OhZAZVsME=; b=g4kpQeFVJwfu9DeIkNgPNUY/bo1bCVQKXupBOtMP2fw0wXbGrcywo3kkrJY9usGDkZ YAxkGnUBdgU7rQRiP5KSzb55aLMz4L349yjJAWpYfRu6KBq3HRomdZR9e52a49UqLhO5 NW0JVdqeA5TCBX2PJb5RtpCfMARbjuQYW2SmM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:in-reply-to:references:date:subject:from:to :user-agent:mime-version:content-type:content-transfer-encoding :x-priority:importance; b=Ef6qYf0tzX/IK6BiRGAOprHwAUwZxTPg1VwYvurlB0TC+IP+U9VwODwM3aomVPBRSK Fyj1GEIx7ztgwFM62Tb76xZkPS4ESI26Sl+cIQAJI5SfVGNuWTZU0J+4qpnNz+GTb17M QH4ESnQ3W95Ps8eX7LQ6eZ/MFbP/DFEenfBcU= Received: by 10.115.110.15 with SMTP id n15mr1160083wam.144.1247142644457; Thu, 09 Jul 2009 05:30:44 -0700 (PDT) Received: from cygnus.homeunix.com ([189.71.13.173]) by mx.google.com with ESMTPS id m34sm17151477waf.22.2009.07.09.05.30.42 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 09 Jul 2009 05:30:43 -0700 (PDT) Sender: Nenhum_de_Nos Received: by cygnus.homeunix.com (Postfix, from userid 80) id 9CA01B8083; Thu, 9 Jul 2009 09:30:34 -0300 (BRT) Received: from 189.93.27.2 (SquirrelMail authenticated user matheus) by cygnus.homeunix.com with HTTP; Thu, 9 Jul 2009 09:30:34 -0300 (BRT) Message-ID: <84665df87e93a6ccf24d9837cbc53eba.squirrel@cygnus.homeunix.com> In-Reply-To: References: <20090709112512.GA44158@hugo10.ka.punkt.de> <73a41d4b72d62b0bfe3d0fb7206376a8.squirrel@cygnus.homeunix.com> Date: Thu, 9 Jul 2009 09:30:34 -0300 (BRT) From: "Nenhum_de_Nos" To: freebsd-stable@freebsd.org User-Agent: SquirrelMail/1.4.15 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: Re: ZFS - thanks X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 12:30:45 -0000 On Thu, July 9, 2009 09:25, Dan Naumov wrote: > On Thu, Jul 9, 2009 at 3:17 PM, Nenhum_de_Nos > wrote: >> >> On Thu, July 9, 2009 08:25, Patrick M. Hausen wrote: >>> Hi, all, >>> >>> I just wanted to say a big big thank you to Kip and all the >>> developers who made ZFS on FreeBSD real. >>> >>> And to everyone who provided helpful comments in the >>> last couple of days. >>> >>> I had to delete and rebuild my zpool to switch from a >>> 12-disk raidz2 to two 6-disk ones, but yesterday I could >>> replace the raw devices with glabel devices and practice >>> replacing a failed disk at the same time. ;-) >>> >>> So now we have this setup: >>> >>>       NAME               STATE     READ WRITE CKSUM >>>       zfs                ONLINE       0     0     0 >>>         raidz2           ONLINE       0     0     0 >>>           label/disk100  ONLINE       0     0     0 >>>           label/disk101  ONLINE       0     0     0 >>>           label/disk102  ONLINE       0     0     0 >>>           label/disk103  ONLINE       0     0     0 >>>           label/disk104  ONLINE       0     0     0 >>>           label/disk105  ONLINE       0     0     0 >>>         raidz2           ONLINE       0     0     0 >>>           label/disk106  ONLINE       0     0     0 >>>           label/disk107  ONLINE       0     0     0 >>>           label/disk108  ONLINE       0     0     0 >>>           label/disk109  ONLINE       0     0     0 >>>           label/disk110  ONLINE       0     0     0 >>>           label/disk111  ONLINE       0     0     0 >>> >>> which will get another enclosure with 6 750-GB-disks, soon. >>> >>> I really like the way I can manage storage from the operating >>> system without propriatary controller management software or >>> even rebooting into the BIOS. >>> >>> Kind regards, >>> Patrick >> >> I've always been curious about this. is said not good to have many disks >> in one pool. ok then. but this layout you're using in here will have the >> same effect as the twelve disks in only one pool ? (the space here is >> the >> sum of both pools ?) > > Having an enormous pool consisting of dozens of disks is not the > actual problem. Having the pool consist of large (> 9 disks) > raidz/raidz2 "groups" is. > > A single pool consising of 5 x 8 disk raidz (40 disks total) is fine. > A single pool consisting of a 40 (or any amount bigger than 9) disk > raidz is not. thanks. but the final file system in both these cases are the same ? (what I'll see in df -h). matheus -- We will call you cygnus, The God of balance you shall be A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? http://en.wikipedia.org/wiki/Posting_style From owner-freebsd-stable@FreeBSD.ORG Thu Jul 9 12:34:38 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CCF57106566C for ; Thu, 9 Jul 2009 12:34:38 +0000 (UTC) (envelope-from hausen@punkt.de) Received: from kagate.punkt.de (kagate.punkt.de [217.29.33.131]) by mx1.freebsd.org (Postfix) with ESMTP id 407668FC17 for ; Thu, 9 Jul 2009 12:34:38 +0000 (UTC) (envelope-from hausen@punkt.de) Received: from hugo10.ka.punkt.de (hugo10.ka.punkt.de [10.0.0.110]) by kagate1.punkt.de with ESMTP id n69CYbph013992 for ; Thu, 9 Jul 2009 14:34:37 +0200 (CEST) Received: from hugo10.ka.punkt.de (localhost [127.0.0.1]) by hugo10.ka.punkt.de (8.14.2/8.14.2) with ESMTP id n69CYZXT048712; Thu, 9 Jul 2009 14:34:35 +0200 (CEST) (envelope-from ry93@hugo10.ka.punkt.de) Received: (from ry93@localhost) by hugo10.ka.punkt.de (8.14.2/8.14.2/Submit) id n69CYZ6n048711; Thu, 9 Jul 2009 14:34:35 +0200 (CEST) (envelope-from ry93) Date: Thu, 9 Jul 2009 14:34:35 +0200 From: "Patrick M. Hausen" To: Nenhum_de_Nos Message-ID: <20090709123434.GC46563@hugo10.ka.punkt.de> References: <20090709112512.GA44158@hugo10.ka.punkt.de> <73a41d4b72d62b0bfe3d0fb7206376a8.squirrel@cygnus.homeunix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <73a41d4b72d62b0bfe3d0fb7206376a8.squirrel@cygnus.homeunix.com> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: freebsd-stable@freebsd.org Subject: Re: ZFS - thanks X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 12:34:39 -0000 Hello, On Thu, Jul 09, 2009 at 09:17:35AM -0300, Nenhum_de_Nos wrote: > > So now we have this setup: > > > > NAME STATE READ WRITE CKSUM > > zfs ONLINE 0 0 0 > > raidz2 ONLINE 0 0 0 > > label/disk100 ONLINE 0 0 0 > > label/disk101 ONLINE 0 0 0 > > label/disk102 ONLINE 0 0 0 > > label/disk103 ONLINE 0 0 0 > > label/disk104 ONLINE 0 0 0 > > label/disk105 ONLINE 0 0 0 > > raidz2 ONLINE 0 0 0 > > label/disk106 ONLINE 0 0 0 > > label/disk107 ONLINE 0 0 0 > > label/disk108 ONLINE 0 0 0 > > label/disk109 ONLINE 0 0 0 > > label/disk110 ONLINE 0 0 0 > > label/disk111 ONLINE 0 0 0 > > > > which will get another enclosure with 6 750-GB-disks, soon. > I've always been curious about this. is said not good to have many disks > in one pool. ok then. but this layout you're using in here will have the > same effect as the twelve disks in only one pool ? (the space here is the > sum of both pools ?) It is not good to have too many disks in one group. What you see above is one pool with two raidz2 groups. As far as I understood the documentation after that helpful comment on this list, this is the recommended configuration. ------------------------------- http://www.solarisinternals.com/wiki/index.php/ZFS_Best_Practices_Guide "The recommended number of disks per group is between 3 and 9. If you have more disks, use multiple groups." ------------------------------- The result is, of course, one big pool with lots of storage space, but the overhead necessary for redundancy is roughly twice that of my "dangerous" twelve-disk configuration. So I lost the equivalent of two disks or about 1 TB here. Fast, reliable, cheap - pick any two ;-) Kind regards, Patrick -- punkt.de GmbH * Kaiserallee 13a * 76133 Karlsruhe Tel. 0721 9109 0 * Fax 0721 9109 100 info@punkt.de http://www.punkt.de Gf: Jürgen Egeling AG Mannheim 108285 From owner-freebsd-stable@FreeBSD.ORG Thu Jul 9 12:39:36 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E0FB71065672 for ; Thu, 9 Jul 2009 12:39:36 +0000 (UTC) (envelope-from dan.naumov@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.245]) by mx1.freebsd.org (Postfix) with ESMTP id 95DA38FC19 for ; Thu, 9 Jul 2009 12:39:36 +0000 (UTC) (envelope-from dan.naumov@gmail.com) Received: by an-out-0708.google.com with SMTP id d14so53447and.13 for ; Thu, 09 Jul 2009 05:39:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=RBBL1ovmfMWEfNRlbuWgNqLb7AefaGuM3nPfPb+/owU=; b=IrUUb/iVF+bQyc3k+wSB+eHDHQHOhy0FxyeNN3d63n7sdW2sx4tjdwVadGbFumdsKr +N+Bbh1UIS93kEn5n7a5dEnweVrTajTT4EPZshh6ypNw/i64e8gBGsY16iU6nwzD/hCQ rFpG6I1f542/MkGJbYqwyRs8jgx624ZVf8Xvc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=wNJCBfNbMrdih6G8xPKwrSgGfb0Ko1lgoc599WxeQ7TRTDf6k8RVPuOJ/ZtWj3i76p FQcOuTFjruDt7oc2dhg4n/A2YShpTkdMR9SAltERsDj56+EM97ydgwYj2ArehDfiLM78 J1h4GWZt706oCX8gzjmCFgticyJiisHFzxwao= MIME-Version: 1.0 Received: by 10.100.119.17 with SMTP id r17mr1034246anc.3.1247143176062; Thu, 09 Jul 2009 05:39:36 -0700 (PDT) In-Reply-To: <84665df87e93a6ccf24d9837cbc53eba.squirrel@cygnus.homeunix.com> References: <20090709112512.GA44158@hugo10.ka.punkt.de> <73a41d4b72d62b0bfe3d0fb7206376a8.squirrel@cygnus.homeunix.com> <84665df87e93a6ccf24d9837cbc53eba.squirrel@cygnus.homeunix.com> Date: Thu, 9 Jul 2009 15:39:35 +0300 Message-ID: From: Dan Naumov To: Nenhum_de_Nos Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org Subject: Re: ZFS - thanks X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 12:39:37 -0000 On Thu, Jul 9, 2009 at 3:30 PM, Nenhum_de_Nos wro= te: > > On Thu, July 9, 2009 09:25, Dan Naumov wrote: >> On Thu, Jul 9, 2009 at 3:17 PM, Nenhum_de_Nos >> wrote: >>> >>> On Thu, July 9, 2009 08:25, Patrick M. Hausen wrote: >>>> Hi, all, >>>> >>>> I just wanted to say a big big thank you to Kip and all the >>>> developers who made ZFS on FreeBSD real. >>>> >>>> And to everyone who provided helpful comments in the >>>> last couple of days. >>>> >>>> I had to delete and rebuild my zpool to switch from a >>>> 12-disk raidz2 to two 6-disk ones, but yesterday I could >>>> replace the raw devices with glabel devices and practice >>>> replacing a failed disk at the same time. ;-) >>>> >>>> So now we have this setup: >>>> >>>> =A0 =A0 =A0 NAME =A0 =A0 =A0 =A0 =A0 =A0 =A0 STATE =A0 =A0 READ WRITE = CKSUM >>>> =A0 =A0 =A0 zfs =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ONLINE =A0 =A0 =A0 0 = =A0 =A0 0 =A0 =A0 0 >>>> =A0 =A0 =A0 =A0 raidz2 =A0 =A0 =A0 =A0 =A0 ONLINE =A0 =A0 =A0 0 =A0 = =A0 0 =A0 =A0 0 >>>> =A0 =A0 =A0 =A0 =A0 label/disk100 =A0ONLINE =A0 =A0 =A0 0 =A0 =A0 0 = =A0 =A0 0 >>>> =A0 =A0 =A0 =A0 =A0 label/disk101 =A0ONLINE =A0 =A0 =A0 0 =A0 =A0 0 = =A0 =A0 0 >>>> =A0 =A0 =A0 =A0 =A0 label/disk102 =A0ONLINE =A0 =A0 =A0 0 =A0 =A0 0 = =A0 =A0 0 >>>> =A0 =A0 =A0 =A0 =A0 label/disk103 =A0ONLINE =A0 =A0 =A0 0 =A0 =A0 0 = =A0 =A0 0 >>>> =A0 =A0 =A0 =A0 =A0 label/disk104 =A0ONLINE =A0 =A0 =A0 0 =A0 =A0 0 = =A0 =A0 0 >>>> =A0 =A0 =A0 =A0 =A0 label/disk105 =A0ONLINE =A0 =A0 =A0 0 =A0 =A0 0 = =A0 =A0 0 >>>> =A0 =A0 =A0 =A0 raidz2 =A0 =A0 =A0 =A0 =A0 ONLINE =A0 =A0 =A0 0 =A0 = =A0 0 =A0 =A0 0 >>>> =A0 =A0 =A0 =A0 =A0 label/disk106 =A0ONLINE =A0 =A0 =A0 0 =A0 =A0 0 = =A0 =A0 0 >>>> =A0 =A0 =A0 =A0 =A0 label/disk107 =A0ONLINE =A0 =A0 =A0 0 =A0 =A0 0 = =A0 =A0 0 >>>> =A0 =A0 =A0 =A0 =A0 label/disk108 =A0ONLINE =A0 =A0 =A0 0 =A0 =A0 0 = =A0 =A0 0 >>>> =A0 =A0 =A0 =A0 =A0 label/disk109 =A0ONLINE =A0 =A0 =A0 0 =A0 =A0 0 = =A0 =A0 0 >>>> =A0 =A0 =A0 =A0 =A0 label/disk110 =A0ONLINE =A0 =A0 =A0 0 =A0 =A0 0 = =A0 =A0 0 >>>> =A0 =A0 =A0 =A0 =A0 label/disk111 =A0ONLINE =A0 =A0 =A0 0 =A0 =A0 0 = =A0 =A0 0 >>>> >>>> which will get another enclosure with 6 750-GB-disks, soon. >>>> >>>> I really like the way I can manage storage from the operating >>>> system without propriatary controller management software or >>>> even rebooting into the BIOS. >>>> >>>> Kind regards, >>>> Patrick >>> >>> I've always been curious about this. is said not good to have many disk= s >>> in one pool. ok then. but this layout you're using in here will have th= e >>> same effect as the twelve disks in only one pool ? (the space here is >>> the >>> sum of both pools ?) >> >> Having an enormous pool consisting of dozens of disks is not the >> actual problem. Having the pool consist of large (> 9 disks) >> raidz/raidz2 "groups" is. >> >> A single pool consising of 5 x 8 disk raidz (40 disks total) is fine. >> A single pool consisting of a 40 (or any amount bigger than 9) disk >> raidz is not. > > thanks. but the final file system in both these cases are the same ? (wha= t > I'll see in df -h). No. A single pool consisting of 5 x 8 disk raidz will have 40 disks total, 35 disks worth of space A single pool consisting of 5 x 8 disk raidz2 will have 40 disks total, 30 disks worth of space A single 40 disk raidz (DO NOT DO THIS) will have 40 disks total, 39 disks worth of space and will definately explode on you sooner rather than later (probably on the first import, export or scrub). - Sincerely, Dan Naumov From owner-freebsd-stable@FreeBSD.ORG Thu Jul 9 13:13:46 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 768DF1065672 for ; Thu, 9 Jul 2009 13:13:46 +0000 (UTC) (envelope-from dudu@dudu.ro) Received: from mail-fx0-f224.google.com (mail-fx0-f224.google.com [209.85.220.224]) by mx1.freebsd.org (Postfix) with ESMTP id 179258FC17 for ; Thu, 9 Jul 2009 13:13:45 +0000 (UTC) (envelope-from dudu@dudu.ro) Received: by fxm24 with SMTP id 24so130502fxm.43 for ; Thu, 09 Jul 2009 06:13:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.108.74 with SMTP id e10mr331829fap.35.1247145225220; Thu, 09 Jul 2009 06:13:45 -0700 (PDT) From: Vlad Galu Date: Thu, 9 Jul 2009 16:13:25 +0300 Message-ID: To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: pw groupadd/useradd fail when the nscd cache is used for name/group resolution X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 13:13:46 -0000 I've stumbled upon this while installing postgres. In /etc/nsswitch.conf I had "group: cache files compat" and "passwd: cache files compat". Once I commented them out things started working again. Before the change, this is how it looked like: -- cut here -- [root@vgalu /usr/ports/databases/postgresql84-server]# pw group add pgsql -g 70 pw: group disappeared during update [root@vgalu /usr/ports/databases/postgresql84-server]# pw group add pgsql -g 70 pw: group 'pgsql' already exists [root@vgalu /usr/ports/databases/postgresql84-server]# -- and here -- Shouldn't 'files' be used upon a cache miss? If this is a PEBKAC, sorry for the noise. From owner-freebsd-stable@FreeBSD.ORG Thu Jul 9 13:21:55 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 95F061065687 for ; Thu, 9 Jul 2009 13:21:55 +0000 (UTC) (envelope-from tonix@interazioni.it) Received: from mx02.interazioni.net (mx02.interazioni.net [80.94.114.204]) by mx1.freebsd.org (Postfix) with ESMTP id BBAB28FC08 for ; Thu, 9 Jul 2009 13:21:54 +0000 (UTC) (envelope-from tonix@interazioni.it) Received: (qmail 72601 invoked by uid 88); 9 Jul 2009 13:21:52 -0000 Received: from unknown (HELO ?192.168.56.198?) (tonix@interazioni.it@85.18.206.139) by relay.interazioni.net with ESMTPA; 9 Jul 2009 13:21:52 -0000 Message-ID: <4A55EEEC.3030007@interazioni.it> Date: Thu, 09 Jul 2009 15:21:48 +0200 From: "Tonix (Antonio Nati)" User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <20090709112512.GA44158@hugo10.ka.punkt.de> <73a41d4b72d62b0bfe3d0fb7206376a8.squirrel@cygnus.homeunix.com> <20090709123434.GC46563@hugo10.ka.punkt.de> In-Reply-To: <20090709123434.GC46563@hugo10.ka.punkt.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: ZFS - thanks X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 13:21:55 -0000 Patrick M. Hausen ha scritto: > Hello, > > On Thu, Jul 09, 2009 at 09:17:35AM -0300, Nenhum_de_Nos wrote: > > >>> So now we have this setup: >>> >>> NAME STATE READ WRITE CKSUM >>> zfs ONLINE 0 0 0 >>> raidz2 ONLINE 0 0 0 >>> label/disk100 ONLINE 0 0 0 >>> label/disk101 ONLINE 0 0 0 >>> label/disk102 ONLINE 0 0 0 >>> label/disk103 ONLINE 0 0 0 >>> label/disk104 ONLINE 0 0 0 >>> label/disk105 ONLINE 0 0 0 >>> raidz2 ONLINE 0 0 0 >>> label/disk106 ONLINE 0 0 0 >>> label/disk107 ONLINE 0 0 0 >>> label/disk108 ONLINE 0 0 0 >>> label/disk109 ONLINE 0 0 0 >>> label/disk110 ONLINE 0 0 0 >>> label/disk111 ONLINE 0 0 0 >>> >>> which will get another enclosure with 6 750-GB-disks, soon. >>> > > >> I've always been curious about this. is said not good to have many disks >> in one pool. ok then. but this layout you're using in here will have the >> same effect as the twelve disks in only one pool ? (the space here is the >> sum of both pools ?) >> > > It is not good to have too many disks in one group. What you see > above is one pool with two raidz2 groups. > > As far as I understood the documentation after that helpful > comment on this list, this is the recommended configuration. > > ------------------------------- > http://www.solarisinternals.com/wiki/index.php/ZFS_Best_Practices_Guide > > "The recommended number of disks per group is between 3 and 9. > If you have more disks, use multiple groups." > ------------------------------- > > The result is, of course, one big pool with lots of storage > space, but the overhead necessary for redundancy is roughly > twice that of my "dangerous" twelve-disk configuration. > > So I lost the equivalent of two disks or about 1 TB here. > Fast, reliable, cheap - pick any two ;-) > > Kind regards, > Patrick > I see a lot of people advicing to use ZFS RAID instead of HW RAID. I'm going to use HP duplicated iSCSI subsystems, which have autonomous RAID, so I'm confused about this advice. Following the ZFS RAID stream, should I keep each disk alone in iSCSI and let the ZFS make the RAID job? Should not HW RAID to be (a lot) more efficient? Which would be the wrong side of using HW RAID with ZFS? Thanks, Tonino -- ------------------------------------------------------------ Inter@zioni Interazioni di Antonio Nati http://www.interazioni.it tonix@interazioni.it ------------------------------------------------------------ From owner-freebsd-stable@FreeBSD.ORG Thu Jul 9 13:43:04 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 57FBE106566C for ; Thu, 9 Jul 2009 13:43:04 +0000 (UTC) (envelope-from hausen@punkt.de) Received: from kagate.punkt.de (kagate.punkt.de [217.29.33.131]) by mx1.freebsd.org (Postfix) with ESMTP id BB3C78FC17 for ; Thu, 9 Jul 2009 13:43:03 +0000 (UTC) (envelope-from hausen@punkt.de) Received: from hugo10.ka.punkt.de (hugo10.ka.punkt.de [10.0.0.110]) by kagate1.punkt.de with ESMTP id n69Dh2v2014943 for ; Thu, 9 Jul 2009 15:43:02 +0200 (CEST) Received: from hugo10.ka.punkt.de (localhost [127.0.0.1]) by hugo10.ka.punkt.de (8.14.2/8.14.2) with ESMTP id n69Dh263051117; Thu, 9 Jul 2009 15:43:02 +0200 (CEST) (envelope-from ry93@hugo10.ka.punkt.de) Received: (from ry93@localhost) by hugo10.ka.punkt.de (8.14.2/8.14.2/Submit) id n69Dh20G051116; Thu, 9 Jul 2009 15:43:02 +0200 (CEST) (envelope-from ry93) Date: Thu, 9 Jul 2009 15:43:02 +0200 From: "Patrick M. Hausen" To: "Tonix (Antonio Nati)" Message-ID: <20090709134302.GA50485@hugo10.ka.punkt.de> References: <20090709112512.GA44158@hugo10.ka.punkt.de> <73a41d4b72d62b0bfe3d0fb7206376a8.squirrel@cygnus.homeunix.com> <20090709123434.GC46563@hugo10.ka.punkt.de> <4A55EEEC.3030007@interazioni.it> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4A55EEEC.3030007@interazioni.it> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: freebsd-stable@freebsd.org Subject: Re: ZFS - thanks X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 13:43:04 -0000 Hello, On Thu, Jul 09, 2009 at 03:21:48PM +0200, Tonix (Antonio Nati) wrote: > I see a lot of people advicing to use ZFS RAID instead of HW RAID. > I'm going to use HP duplicated iSCSI subsystems, which have autonomous > RAID, so I'm confused about this advice. > Following the ZFS RAID stream, should I keep each disk alone in iSCSI and > let the ZFS make the RAID job? > Should not HW RAID to be (a lot) more efficient? You cannot escape the poor write performance of RAID 5 and comparable setups with or without hardware. No matter how much you cache, one time a block must be written to disk. And for RAID 1 or 1+0 we found the impact on modern CPUs negligible. So we switched to GEOM for mirroring a long time ago for one simple reason: hardware replacement. With a "hardware RAID" you need the precise brand and model of the controller (worst case) to read a disk with valuable data on it in case of a complete machine failure and replacement. What, if that's not avaliable any more? With software you just need an arbitrary machine with the matching HDD interface (P-ATA, S-ATA, SCSI, ...) This is my first attempt at software RAID-other-than-1, but I'm really pleased with the results so far. The system is a Fujitsu (former Fujitsu Siemens) SX 40 JBOD with a SAS host interface and SAS or S-ATA disks. You can daisy chain 3 of these boxes with twelve disks each to one server. The host adapter in my server doesn't have any RAID functions. LSI something, easily replaced. Reasonably priced, nice, scalable solution for our needs. It's a datastore, so it doesn't do anything but backup and restore. I would not use ZFS for something that needs to be "up" 24x7 just yet. We had a couple of crashes before we changed some memory parameters. Kind regards, Patrick -- punkt.de GmbH * Kaiserallee 13a * 76133 Karlsruhe Tel. 0721 9109 0 * Fax 0721 9109 100 info@punkt.de http://www.punkt.de Gf: Jürgen Egeling AG Mannheim 108285 From owner-freebsd-stable@FreeBSD.ORG Thu Jul 9 13:47:14 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C087B106567D for ; Thu, 9 Jul 2009 13:47:14 +0000 (UTC) (envelope-from steve@ibctech.ca) Received: from smtp.ibctech.ca (v6.ibctech.ca [IPv6:2607:f118::b6]) by mx1.freebsd.org (Postfix) with SMTP id 3E3D18FC0A for ; Thu, 9 Jul 2009 13:47:14 +0000 (UTC) (envelope-from steve@ibctech.ca) Received: (qmail 85864 invoked by uid 89); 9 Jul 2009 13:48:55 -0000 Received: from unknown (HELO ?IPv6:2607:f118::5?) (steve@ibctech.ca@2607:f118::5) by 2607:f118::b6 with ESMTPA; 9 Jul 2009 13:48:55 -0000 Message-ID: <4A55F4DC.5010504@ibctech.ca> Date: Thu, 09 Jul 2009 09:47:08 -0400 From: Steve Bertrand User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: "Patrick M. Hausen" References: <20090709112512.GA44158@hugo10.ka.punkt.de> <73a41d4b72d62b0bfe3d0fb7206376a8.squirrel@cygnus.homeunix.com> <20090709123434.GC46563@hugo10.ka.punkt.de> <4A55EEEC.3030007@interazioni.it> <20090709134302.GA50485@hugo10.ka.punkt.de> In-Reply-To: <20090709134302.GA50485@hugo10.ka.punkt.de> X-Enigmail-Version: 0.95.7 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090909030206020805030800" Cc: freebsd-stable@freebsd.org, "Tonix \(Antonio Nati\)" Subject: Re: ZFS - thanks X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 13:47:15 -0000 This is a cryptographically signed message in MIME format. --------------ms090909030206020805030800 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Patrick M. Hausen wrote: > So we switched to GEOM for mirroring a long time ago for > one simple reason: hardware replacement. Amen. Steve --------------ms090909030206020805030800 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII/zCC AtowggJDoAMCAQICEEs5xg/J3t77QWJ4SatV1HcwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDUwNzIzMTYxMFoX DTEwMDUwNzIzMTYxMFowQjEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEfMB0G CSqGSIb3DQEJARYQc3RldmVAaWJjdGVjaC5jYTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAJSTRAjP1RVa87/mnZn+PBTbENgyhhBJ4rWApmaNcthzRdk2DB/49KrXx3EQP60w Lj4KU0DFkiGNVj9BnVxRAx/WDXKxGC3uGGEG6gjyWv8KFMWMsH9mL7y7uNow1HueT6pZUf9o yY8Ewd+01QpGi7FfXOae7lGHhbEwnEJGwz08ytRfLmH0KtEzlZanZZhwDGX5s1kIHnyxdACh 3byXY6Z2bOrx0rcrQHCnHJppxddR60F7igjaMuBFstE51h9XTgXDNKJbglqTug5ghGihNuP6 VsBN7ue62y96UGIE22TvKEcAQ665vQGjHqZeSzZYy+hWNOa27pWFmhlqFjx0x8MCAwEAAaMt MCswGwYDVR0RBBQwEoEQc3RldmVAaWJjdGVjaC5jYTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3 DQEBBQUAA4GBAMOmjxjp2Xzk6ZHLwTgFDzVhm98RjRT3UXotKjNIR7SgwfWF5wkJrx4I+dXu ui5ztMEq4bTTRgJ344MqE6uZiZlg+tBIFHZGCJfKdzsX4QuV2jmw0sR5dMaYxG6tlDB0YUMv gTqzV7ZDpiusTMOZe9pP1PdxFhOcIJXtMQDj5LhuMIIC2jCCAkOgAwIBAgIQSznGD8ne3vtB YnhJq1XUdzANBgkqhkiG9w0BAQUFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3Rl IENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDkwNTA3MjMxNjEwWhcNMTAwNTA3MjMxNjEwWjBCMR8wHQYD VQQDExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMR8wHQYJKoZIhvcNAQkBFhBzdGV2ZUBpYmN0 ZWNoLmNhMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAlJNECM/VFVrzv+admf48 FNsQ2DKGEEnitYCmZo1y2HNF2TYMH/j0qtfHcRA/rTAuPgpTQMWSIY1WP0GdXFEDH9YNcrEY Le4YYQbqCPJa/woUxYywf2YvvLu42jDUe55PqllR/2jJjwTB37TVCkaLsV9c5p7uUYeFsTCc QkbDPTzK1F8uYfQq0TOVlqdlmHAMZfmzWQgefLF0AKHdvJdjpnZs6vHStytAcKccmmnF11Hr QXuKCNoy4EWy0TnWH1dOBcM0oluCWpO6DmCEaKE24/pWwE3u57rbL3pQYgTbZO8oRwBDrrm9 AaMepl5LNljL6FY05rbulYWaGWoWPHTHwwIDAQABoy0wKzAbBgNVHREEFDASgRBzdGV2ZUBp YmN0ZWNoLmNhMAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEFBQADgYEAw6aPGOnZfOTpkcvB OAUPNWGb3xGNFPdRei0qM0hHtKDB9YXnCQmvHgj51e66LnO0wSrhtNNGAnfjgyoTq5mJmWD6 0EgUdkYIl8p3OxfhC5XaObDSxHl0xpjEbq2UMHRhQy+BOrNXtkOmK6xMw5l72k/U93EWE5wg le0xAOPkuG4wggM/MIICqKADAgECAgENMA0GCSqGSIb3DQEBBQUAMIHRMQswCQYDVQQGEwJa QTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoT EVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERp dmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG 9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDMwNzE3MDAwMDAwWhcN MTMwNzE2MjM1OTU5WjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRp bmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp bmcgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMSmPFVzVftOucqZWh5owHUEcJ3f 6f+jHuy9zfVb8hp2vX8MOmHyv1HOAdTlUAow1wJjWiyJFXCO3cnwK4Vaqj9xVsuvPAsH5/Ef kTYkKhPPK9Xzgnc9A74r/rsYPge/QIACZNenprufZdHFKlSFD0gEf6e20TxhBEAeZBlyYLf7 AgMBAAGjgZQwgZEwEgYDVR0TAQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6MDigNqA0hjJodHRw Oi8vY3JsLnRoYXd0ZS5jb20vVGhhd3RlUGVyc29uYWxGcmVlbWFpbENBLmNybDALBgNVHQ8E BAMCAQYwKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDItMTM4MA0GCSqG SIb3DQEBBQUAA4GBAEiM0VCD6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0whuPg2H6otnzYvwPQc UCCTcDz9reFhYsPZOhl+hLGZGwDFGguCdJ4lUJRix9sncVcljd2pnDmOjCBPZV+V2vf3h9bG CE6u9uo05RAaWzVNd+NWIXiC3CEZNd4ksdMdRv9dX2VPMYIDZDCCA2ACAQEwdjBiMQswCQYD VQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEEs5xg/J3t77QWJ4SatV 1HcwCQYFKw4DAhoFAKCCAcMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B CQUxDxcNMDkwNzA5MTM0NzA4WjAjBgkqhkiG9w0BCQQxFgQULS6VjUPxTJ7p7DHKm3XSA7rO YpYwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZI hvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYwYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAq BgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhBLOcYPyd7e+0Fi eEmrVdR3MIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBG cmVlbWFpbCBJc3N1aW5nIENBAhBLOcYPyd7e+0FieEmrVdR3MA0GCSqGSIb3DQEBAQUABIIB AI5PCt6W+47OrTiSE47pzq1EftRoDH6g0eQahxnUuhFA1JNh5y0Iz/i96zgUxmyfnXvQR/31 Yck0YBKPSUJuTVMeDiGa9TXB2mFB4WJ2St/CcULJrAq4UcZZItFEY8ZUa9SdVB9CCBHff4BM bAZs18N0fQP19eUgMa96yaW0S2RW/eqjPpnFpRON3BweJ6mvWusHaGgpX0r0ixnGas/vUCg/ qI5veb8lxYUzaTkwXH/fs4OuJwKicwOkvdoCVoKLLXOlunot5KSMGuEK+VjEo+tHibLEci60 0tHRd5ld9xvF0WBufHTJ8wX0bEtCKwO+SSWSyiQF11KrD5oqHUfGkA8AAAAAAAA= --------------ms090909030206020805030800-- From owner-freebsd-stable@FreeBSD.ORG Thu Jul 9 14:06:39 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3A71F106568C for ; Thu, 9 Jul 2009 14:06:39 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 7FAF98FC17 for ; Thu, 9 Jul 2009 14:06:38 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id RAA10564; Thu, 09 Jul 2009 17:06:35 +0300 (EEST) (envelope-from avg@icyb.net.ua) Message-ID: <4A55F96B.6070303@icyb.net.ua> Date: Thu, 09 Jul 2009 17:06:35 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.22 (X11/20090630) MIME-Version: 1.0 To: Thomas Ronner References: <1247085058.6197.18.camel@bugstore> In-Reply-To: <1247085058.6197.18.camel@bugstore> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=KOI8-U Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: ZFS: zpool scrub lockup X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 14:06:39 -0000 on 08/07/2009 23:30 Thomas Ronner said the following: > Hello, > > I don't know whether this is the right list; maybe freebsd-fs is more > appropriate. So please redirect me there if this isn't the right place. > > My system (i386, Athlon XP) locks hard when scrubbing a certain pool. It > has been doing this for at least a couple of months now. For this reason > I upgraded to 7.2-STABLE recently as this had the latest ZFS bits, but > this doesn't help. It even makes the problem worse: in previous versions > I just hit the reset button and forgot about it, but now it "remembers" > that it was scrubbing (I presume) and tries to resume at the exact same > place, locking up again. This means I haven't been able to mount these > ZFS volumes successfully: the moment I do a /etc/rc.d/zfs start from > single user mode (I have my /, /var and /usr on UFS) it locks up in a > couple of seconds. And by locks up I really mean locks up. No panic, > nothing. Pressing the reset button on the chassis is the only way to > reboot. You can try adding SW_WATCHDOG option to your kernel which might help catching the lockup. Things like INVARIANTS and WITNESS might help th debugging too. Serial console for remote debugging would be very useful too. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Thu Jul 9 15:35:13 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8135510656B2 for ; Thu, 9 Jul 2009 15:35:13 +0000 (UTC) (envelope-from thomas@ronner.org) Received: from mail.knopje.net (mail.knopje.net [213.214.107.232]) by mx1.freebsd.org (Postfix) with ESMTP id 46ADD8FC16 for ; Thu, 9 Jul 2009 15:35:13 +0000 (UTC) (envelope-from thomas@ronner.org) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.knopje.net (Postfix) with ESMTP id 06F4F38128; Thu, 9 Jul 2009 17:35:12 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at knopje.net Received: from mail.knopje.net ([127.0.0.1]) by localhost (hal.knopje.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JtklKXDhqgbV; Thu, 9 Jul 2009 17:35:11 +0200 (CEST) Received: from [192.168.28.109] (48-251.surfsnel.dsl.internl.net [145.99.251.48]) by mail.knopje.net (Postfix) with ESMTP id 94409380FC; Thu, 9 Jul 2009 17:35:11 +0200 (CEST) Message-ID: <4A560E2F.1050906@ronner.org> Date: Thu, 09 Jul 2009 17:35:11 +0200 From: Thomas Ronner User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <1247085058.6197.18.camel@bugstore> <4A55F96B.6070303@icyb.net.ua> In-Reply-To: <4A55F96B.6070303@icyb.net.ua> Content-Type: text/plain; charset=KOI8-U; format=flowed Content-Transfer-Encoding: 7bit Cc: Andriy Gapon Subject: Re: ZFS: zpool scrub lockup X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 15:35:13 -0000 Hi Andriy, Andriy Gapon wrote: > on 08/07/2009 23:30 Thomas Ronner said the following: >> Hello, >> >> I don't know whether this is the right list; maybe freebsd-fs is more >> appropriate. So please redirect me there if this isn't the right place. >> >> My system (i386, Athlon XP) locks hard when scrubbing a certain pool. It >> has been doing this for at least a couple of months now. For this reason >> I upgraded to 7.2-STABLE recently as this had the latest ZFS bits, but >> this doesn't help. It even makes the problem worse: in previous versions >> I just hit the reset button and forgot about it, but now it "remembers" >> that it was scrubbing (I presume) and tries to resume at the exact same >> place, locking up again. This means I haven't been able to mount these >> ZFS volumes successfully: the moment I do a /etc/rc.d/zfs start from >> single user mode (I have my /, /var and /usr on UFS) it locks up in a >> couple of seconds. And by locks up I really mean locks up. No panic, >> nothing. Pressing the reset button on the chassis is the only way to >> reboot. > > You can try adding SW_WATCHDOG option to your kernel which might help catching the > lockup. Things like INVARIANTS and WITNESS might help th debugging too. > Serial console for remote debugging would be very useful too. > I'll definitely try those and report back on this list. Thanks for your answer! Regards, Thomas From owner-freebsd-stable@FreeBSD.ORG Thu Jul 9 17:21:03 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 045051065670 for ; Thu, 9 Jul 2009 17:21:03 +0000 (UTC) (envelope-from thomas@ronner.org) Received: from mail.knopje.net (mail.knopje.net [213.214.107.232]) by mx1.freebsd.org (Postfix) with ESMTP id BD72E8FC19 for ; Thu, 9 Jul 2009 17:21:01 +0000 (UTC) (envelope-from thomas@ronner.org) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.knopje.net (Postfix) with ESMTP id 2BA3938128; Thu, 9 Jul 2009 19:21:01 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at knopje.net Received: from mail.knopje.net ([127.0.0.1]) by localhost (hal.knopje.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dqq+FNdjWwyc; Thu, 9 Jul 2009 19:21:00 +0200 (CEST) Received: from [192.168.28.109] (48-251.surfsnel.dsl.internl.net [145.99.251.48]) by mail.knopje.net (Postfix) with ESMTP id AEE08380FC; Thu, 9 Jul 2009 19:21:00 +0200 (CEST) Message-ID: <4A5626FC.5000306@ronner.org> Date: Thu, 09 Jul 2009 19:21:00 +0200 From: Thomas Ronner User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <1247085058.6197.18.camel@bugstore> <4A55F96B.6070303@icyb.net.ua> <4A560E2F.1050906@ronner.org> In-Reply-To: <4A560E2F.1050906@ronner.org> Content-Type: text/plain; charset=KOI8-U; format=flowed Content-Transfer-Encoding: 7bit Cc: Andriy Gapon Subject: Re: ZFS: zpool scrub lockup X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 17:21:03 -0000 Thomas Ronner wrote: > Hi Andriy, > > Andriy Gapon wrote: >> on 08/07/2009 23:30 Thomas Ronner said the following: >>> Hello, >>> >>> I don't know whether this is the right list; maybe freebsd-fs is more >>> appropriate. So please redirect me there if this isn't the right place. >>> >>> My system (i386, Athlon XP) locks hard when scrubbing a certain pool. It >>> has been doing this for at least a couple of months now. For this reason >>> I upgraded to 7.2-STABLE recently as this had the latest ZFS bits, but >>> this doesn't help. It even makes the problem worse: in previous versions >>> I just hit the reset button and forgot about it, but now it "remembers" >>> that it was scrubbing (I presume) and tries to resume at the exact same >>> place, locking up again. This means I haven't been able to mount these >>> ZFS volumes successfully: the moment I do a /etc/rc.d/zfs start from >>> single user mode (I have my /, /var and /usr on UFS) it locks up in a >>> couple of seconds. And by locks up I really mean locks up. No panic, >>> nothing. Pressing the reset button on the chassis is the only way to >>> reboot. >> >> You can try adding SW_WATCHDOG option to your kernel which might help >> catching the >> lockup. Things like INVARIANTS and WITNESS might help th debugging too. >> Serial console for remote debugging would be very useful too. >> > > I'll definitely try those and report back on this list. Thanks for your > answer! I put the following in my kernel config: # debugging options KDB options DDB options GDB options BREAK_TO_DEBUGGER options INVARIANTS options INVARIANT_SUPPORT options WITNESS options WITNESS_KDB options DEBUG_VFS_LOCKS options DIAGNOSTIC options SW_WATCHDOG When I send a BREAK from my serial console it enters the debugger, so that works. But when I start ZFS (/etc/rc.d/zfs start) it freezes again and BREAK doesn't enter the debugger. I'll try playing with the watchdog now, but I doubt this will help. Any clues? Thanks, Thomas From owner-freebsd-stable@FreeBSD.ORG Thu Jul 9 17:35:09 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C458B1065676 for ; Thu, 9 Jul 2009 17:35:09 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 1331B8FC1B for ; Thu, 9 Jul 2009 17:35:08 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id UAA15530; Thu, 09 Jul 2009 20:35:07 +0300 (EEST) (envelope-from avg@icyb.net.ua) Message-ID: <4A562A4A.2000201@icyb.net.ua> Date: Thu, 09 Jul 2009 20:35:06 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.22 (X11/20090630) MIME-Version: 1.0 To: Thomas Ronner References: <1247085058.6197.18.camel@bugstore> <4A55F96B.6070303@icyb.net.ua> <4A560E2F.1050906@ronner.org> <4A5626FC.5000306@ronner.org> In-Reply-To: <4A5626FC.5000306@ronner.org> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=KOI8-U Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: ZFS: zpool scrub lockup X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 17:35:10 -0000 on 09/07/2009 20:21 Thomas Ronner said the following: > I put the following in my kernel config: > > # debugging > options KDB > options DDB > options GDB > options BREAK_TO_DEBUGGER > options INVARIANTS > options INVARIANT_SUPPORT > options WITNESS > options WITNESS_KDB > options DEBUG_VFS_LOCKS > options DIAGNOSTIC > options SW_WATCHDOG > > When I send a BREAK from my serial console it enters the debugger, so > that works. But when I start ZFS (/etc/rc.d/zfs start) it freezes again > and BREAK doesn't enter the debugger. I'll try playing with the watchdog > now, but I doubt this will help. Any clues? > For watchdog to fire it first needs to be enabled, e.g. by starting watchdogd. Try to run /etc/rd.d/watchdogd onestart before zfs start and then wait for about 16 seconds (default timeout). If that doesn't help, then it seems that the only option would be debugging via serial console. Or manually generating NMI, if your system has an NMI button/switch/jumper. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Thu Jul 9 18:25:45 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6FC1D10656A8 for ; Thu, 9 Jul 2009 18:25:45 +0000 (UTC) (envelope-from thomas@ronner.org) Received: from mail.knopje.net (mail.knopje.net [213.214.107.232]) by mx1.freebsd.org (Postfix) with ESMTP id 331BC8FC0A for ; Thu, 9 Jul 2009 18:25:45 +0000 (UTC) (envelope-from thomas@ronner.org) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.knopje.net (Postfix) with ESMTP id 712A138128; Thu, 9 Jul 2009 20:25:44 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at knopje.net Received: from mail.knopje.net ([127.0.0.1]) by localhost (hal.knopje.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ig9WbusHNDg7; Thu, 9 Jul 2009 20:25:44 +0200 (CEST) Received: from [192.168.28.109] (48-251.surfsnel.dsl.internl.net [145.99.251.48]) by mail.knopje.net (Postfix) with ESMTP id 09809380FC; Thu, 9 Jul 2009 20:25:43 +0200 (CEST) Message-ID: <4A563627.7040407@ronner.org> Date: Thu, 09 Jul 2009 20:25:43 +0200 From: Thomas Ronner User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Andriy Gapon References: <1247085058.6197.18.camel@bugstore> <4A55F96B.6070303@icyb.net.ua> <4A560E2F.1050906@ronner.org> <4A5626FC.5000306@ronner.org> <4A562A4A.2000201@icyb.net.ua> In-Reply-To: <4A562A4A.2000201@icyb.net.ua> Content-Type: text/plain; charset=KOI8-U; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: ZFS: zpool scrub lockup X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 18:25:45 -0000 Andriy Gapon wrote: > For watchdog to fire it first needs to be enabled, e.g. by starting watchdogd. > Try to run /etc/rd.d/watchdogd onestart before zfs start and then wait for about > 16 seconds (default timeout). I tried this. When only running 'watchdog' (without starting the daemon) it enters the debugger in 16 seconds. The only way to continue is issuing the 'watchdog' debugger command (I presume this disables the watchdog?), followed by 'c'. But when re-enabling the watchdog by running /etc/rc.d/watchdogd start (I already added watchdogd to rc.conf) > If that doesn't help, then it seems that the only option would be debugging via > serial console. Or manually generating NMI, if your system has an NMI > button/switch/jumper. No, I don't have a manual NMI thingy. Is this: http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug-online-gdb.html (10.6 On-Line Kernel Debugging Using Remote GDB) the debugging via serial console you're referring to? Thanks, Thomas From owner-freebsd-stable@FreeBSD.ORG Thu Jul 9 18:52:32 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B5B72106564A; Thu, 9 Jul 2009 18:52:32 +0000 (UTC) (envelope-from andreast-list@fgznet.ch) Received: from smtp.fgznet.ch (mail.fgznet.ch [81.92.96.47]) by mx1.freebsd.org (Postfix) with ESMTP id 50BE48FC17; Thu, 9 Jul 2009 18:52:32 +0000 (UTC) (envelope-from andreast-list@fgznet.ch) Received: from deuterium.andreas.nets ([91.190.8.131]) by smtp.fgznet.ch (8.13.8/8.13.8/Submit_SMTPAUTH) with ESMTP id n69IqL1o053881; Thu, 9 Jul 2009 20:52:22 +0200 (CEST) (envelope-from andreast-list@fgznet.ch) Message-ID: <4A563C65.20402@fgznet.ch> Date: Thu, 09 Jul 2009 20:52:21 +0200 From: Andreas Tobler User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Ken Smith References: <1246926782.11597.23.camel@bauer.cse.buffalo.edu> <4A54FB33.8060705@fgznet.ch> <1247107223.31816.7.camel@bauer.cse.buffalo.edu> In-Reply-To: <1247107223.31816.7.camel@bauer.cse.buffalo.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.64 on 81.92.96.47 Cc: freebsd-current , freebsd-stable Subject: Re: FreeBSD 8.0-BETA1 Available X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 18:52:33 -0000 Ken Smith wrote: > On Wed, 2009-07-08 at 22:01 +0200, Andreas Tobler wrote: >> I was successful in installing the image, although, a few packages did >> not install. I did a kern developer package. I guess the packages are >> missing on the .img? > > Correct, no packages with BETA1. It's probably the documentation > packages it went looking for and couldn't find. I'll be providing at > least the docs packages with BETA2. Not sure if I'll start trying to > provide a larger set of packages for the DVD or wait for BETA3 for that > (leaning towards waiting at the moment). Ok, that means no doc/dict/docproj/man/ports/src (and the ones I didn't choose) in the BETA1? I did the install again with a real stick and everything went fine besides not finding the above packages. Thanks, Andreas From owner-freebsd-stable@FreeBSD.ORG Thu Jul 9 19:18:27 2009 Return-Path: Delivered-To: stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 00B651065673 for ; Thu, 9 Jul 2009 19:18:27 +0000 (UTC) (envelope-from mi+thun@aldan.algebra.com) Received: from aldan.algebra.com (aldan.algebra.com [216.254.65.224]) by mx1.freebsd.org (Postfix) with ESMTP id 974A58FC21 for ; Thu, 9 Jul 2009 19:18:26 +0000 (UTC) (envelope-from mi+thun@aldan.algebra.com) Received: from aldan.algebra.com (localhost [127.0.0.1]) by aldan.algebra.com (8.14.3/8.14.3) with ESMTP id n69J7U9b097444; Thu, 9 Jul 2009 15:07:30 -0400 (EDT) (envelope-from mi+thun@aldan.algebra.com) Message-ID: <4A563FF2.3010305@aldan.algebra.com> Date: Thu, 09 Jul 2009 15:07:30 -0400 From: "Mikhail T." User-Agent: Thunderbird 2.0.0.21 (X11/20090407) MIME-Version: 1.0 To: stable@FreeBSD.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: kde@FreeBSD.org Subject: process stuck in "umtxn" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 19:18:27 -0000 Hello! I noticed, that my build of KDE4 ports got suspiciously quiet... Pressing Ctrl-T shows: load: 0.01 cmd: automoc4 78507 [umtxn] 0.00u 0.00s 0% 3552k According to gdb, the process' stack is: #0 0x0000000800d9620a in __error () from /lib/libthr.so.3 #1 0x0000000800d95f0c in __error () from /lib/libthr.so.3 #2 0x0000000800d911eb in pthread_mutex_getyieldloops_np () from /lib/libthr.so.3 #3 0x0000000800f0941b in _malloc_postfork () from /lib/libc.so.7 #4 0x0000000800d93c60 in fork () from /lib/libthr.so.3 #5 0x0000000800778e4a in QProcessPrivate::startProcess () from /opt/lib/qt4/libQtCore.so.4 #6 0x000000080073f2c6 in QProcess::start () from /opt/lib/qt4/libQtCore.so.4 .... My system is 7.2-PRERELEASE/amd64 from April 9th. Please, advise. Thanks! Yours, -mi From owner-freebsd-stable@FreeBSD.ORG Thu Jul 9 19:25:09 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F24AF106566C for ; Thu, 9 Jul 2009 19:25:09 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by mx1.freebsd.org (Postfix) with ESMTP id 41CC38FC12 for ; Thu, 9 Jul 2009 19:25:09 +0000 (UTC) (envelope-from mike@sentex.net) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.14.3/8.14.3) with ESMTP id n69JMYvS067578 for ; Thu, 9 Jul 2009 15:22:34 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <200907091922.n69JMYvS067578@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 09 Jul 2009 15:25:09 -0400 To: freebsd-stable@freebsd.org From: Mike Tancsa Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: pppoe on a VLAN interface issues (RELENG_7) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 19:25:10 -0000 I wanted to share a DSL modem that is in bridge mode between two FreeBSD boxes that make use of many VLANs on a pair of em interfaces. In other words, I cant dedicate a physical interface to just using the DSL. Normally, when creating vlans, I like to create them as so /sbin/ifconfig em1.172 create 192.168.1.3/24 em1.172: flags=8843 metric 0 mtu 1500 options=3 ether 00:30:48:d2:d6:11 inet 192.168.1.3 netmask 0xffffff00 broadcast 192.168.1.255 media: Ethernet autoselect (1000baseTX ) status: active vlan: 172 parent interface: em1 However, if I try and bring up pppoe using em1.10 as the PPPoE device, it does not work. Jul 9 14:34:17 fw02 ppp[1484]: tun0: Phase: deflink: closed -> opening Jul 9 14:34:17 fw02 kernel: ng_ether_attach: can't name node em1.10 Jul 9 14:34:17 fw02 kernel: ng_ether_attach: can't name node em1.172 Jul 9 14:34:17 fw02 kernel: ng_ether_attach: can't name node em1.24 Jul 9 14:34:17 fw02 kernel: WARNING: attempt to net_add_domain(netgraph) after domainfinalize() Jul 9 14:34:17 fw02 kernel: Jul 9 14:34:17 fw02 kernel: ng_ether_attach: can't name node em1.10 Jul 9 14:34:17 fw02 kernel: Jul 9 14:34:17 fw02 kernel: ng_ether_attach: can't name node em1.172 Jul 9 14:34:17 fw02 kernel: Jul 9 14:34:17 fw02 kernel: ng_ether_attach: can't name node em1.24 Jul 9 14:34:17 fw02 ppp[1484]: tun0: Warning: em1.172: Cannot send a netgraph message: Invalid argument Jul 9 14:34:17 fw02 ppp[1484]: tun0: Chat: Failed to open device Jul 9 14:34:17 fw02 ppp[1484]: tun0: Phase: deflink: Enter pause (30) for redialing. Jul 9 14:34:47 fw02 ppp[1484]: tun0: Chat: deflink: Redial timer expired. Jul 9 14:34:47 fw02 ppp[1484]: tun0: Warning: em1.172: Cannot send a netgraph message: Invalid argument Jul 9 14:34:47 fw02 ppp[1484]: tun0: Warning: deflink: PPPoE: unknown host Jul 9 14:34:47 fw02 ppp[1484]: tun0: Warning: deflink: PPPoE: unknown host Jul 9 14:34:47 fw02 ppp[1484]: tun0: Warning: deflink: Device (PPPoE:em1.172) must begin with a '/', a '!' or contain at least one ':' Jul 9 14:34:47 fw02 ppp[1484]: tun0: Chat: Failed to open device Jul 9 14:34:47 fw02 ppp[1484]: tun0: Phase: deflink: Enter pause (30) for redialing. Jul 9 14:34:50 fw02 ppp[1484]: tun0: Phase: Signal 15, terminate. BUT, if I make the vlan device the "old way" /sbin/ifconfig vlan172 create 192.168.1.3/24 vlandev em1 vlan 172 it works It still complains about the other 2 interfaces, but it does not seem to interfere with the PPPoE connection Jul 9 14:48:15 macs-fw02 kernel: ng_ether_attach: can't name node em1.10 Jul 9 14:48:15 macs-fw02 kernel: ng_ether_attach: can't name node em1.24 Jul 9 14:48:15 macs-fw02 kernel: Jul 9 14:48:15 macs-fw02 kernel: ng_ether_attach: can't name node em1.10 Jul 9 14:48:15 macs-fw02 kernel: Jul 9 14:48:15 macs-fw02 kernel: ng_ether_attach: can't name node em1.24 Jul 9 14:48:16 macs-fw02 kernel: WARNING: attempt to net_add_domain(netgraph) after domainfinalize() Is there some reason this does not work ? ---Mike -------------------------------------------------------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet since 1994 www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike From owner-freebsd-stable@FreeBSD.ORG Thu Jul 9 20:45:51 2009 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A7667106564A for ; Thu, 9 Jul 2009 20:45:51 +0000 (UTC) (envelope-from dan@dan.emsphone.com) Received: from email2.allantgroup.com (email2.emsphone.com [199.67.51.116]) by mx1.freebsd.org (Postfix) with ESMTP id 5C5BB8FC16 for ; Thu, 9 Jul 2009 20:45:51 +0000 (UTC) (envelope-from dan@dan.emsphone.com) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by email2.allantgroup.com (8.14.0/8.14.0) with ESMTP id n69KGhFB052976 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 9 Jul 2009 15:16:43 -0500 (CDT) (envelope-from dan@dan.emsphone.com) Received: from dan.emsphone.com (smmsp@localhost [127.0.0.1]) by dan.emsphone.com (8.14.3/8.14.3) with ESMTP id n69KGhwC098711 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 9 Jul 2009 15:16:43 -0500 (CDT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.14.3/8.14.3/Submit) id n69K1pxp064112; Thu, 9 Jul 2009 15:01:51 -0500 (CDT) (envelope-from dan) Date: Thu, 9 Jul 2009 15:01:50 -0500 From: Dan Nelson To: "Mikhail T." Message-ID: <20090709200148.GD63413@dan.emsphone.com> References: <4A563FF2.3010305@aldan.algebra.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A563FF2.3010305@aldan.algebra.com> X-OS: FreeBSD 7.2-STABLE User-Agent: Mutt/1.5.19 (2009-01-05) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on email2.allantgroup.com X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (email2.allantgroup.com [199.67.51.78]); Thu, 09 Jul 2009 15:16:43 -0500 (CDT) X-Scanned-By: MIMEDefang 2.45 Cc: stable@freebsd.org, kde@freebsd.org Subject: Re: process stuck in "umtxn" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 20:45:52 -0000 In the last episode (Jul 09), Mikhail T. said: > I noticed, that my build of KDE4 ports got suspiciously quiet... Pressing > Ctrl-T shows: > > load: 0.01 cmd: automoc4 78507 [umtxn] 0.00u 0.00s 0% 3552k > > According to gdb, the process' stack is: > > #0 0x0000000800d9620a in __error () from /lib/libthr.so.3 > #1 0x0000000800d95f0c in __error () from /lib/libthr.so.3 > #2 0x0000000800d911eb in pthread_mutex_getyieldloops_np () from /lib/libthr.so.3 > #3 0x0000000800f0941b in _malloc_postfork () from /lib/libc.so.7 > #4 0x0000000800d93c60 in fork () from /lib/libthr.so.3 > #5 0x0000000800778e4a in QProcessPrivate::startProcess () from /opt/lib/qt4/libQtCore.so.4 > #6 0x000000080073f2c6 in QProcess::start () from /opt/lib/qt4/libQtCore.so.4 > .... > > My system is 7.2-PRERELEASE/amd64 from April 9th. Please, advise. > Thanks! Yours, That could be due to the following bug, fixed after 7.2 was released. Appliying the patch and rebuilding libc should be all you need to fix it: http://security.freebsd.org/advisories/FreeBSD-EN-09:04.fork.asc -- Dan Nelson dnelson@allantgroup.com From owner-freebsd-stable@FreeBSD.ORG Thu Jul 9 23:13:36 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 78CFD106566C for ; Thu, 9 Jul 2009 23:13:36 +0000 (UTC) (envelope-from andrew@modulus.org) Received: from email.octopus.com.au (email.octopus.com.au [122.100.2.232]) by mx1.freebsd.org (Postfix) with ESMTP id 37B8A8FC13 for ; Thu, 9 Jul 2009 23:13:35 +0000 (UTC) (envelope-from andrew@modulus.org) Received: by email.octopus.com.au (Postfix, from userid 1002) id 8328117DAE; Fri, 10 Jul 2009 09:14:00 +1000 (EST) X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on email.octopus.com.au X-Spam-Level: X-Spam-Status: No, score=-1.4 required=10.0 tests=ALL_TRUSTED autolearn=failed version=3.2.3 Received: from [10.1.50.60] (ppp121-44-41-14.lns10.syd7.internode.on.net [121.44.41.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: admin@email.octopus.com.au) by email.octopus.com.au (Postfix) with ESMTP id 7AC5E1736A; Fri, 10 Jul 2009 09:13:56 +1000 (EST) Message-ID: <4A567919.8000704@modulus.org> Date: Fri, 10 Jul 2009 09:11:21 +1000 From: Andrew Snow User-Agent: Thunderbird 2.0.0.14 (X11/20080523) MIME-Version: 1.0 To: "Patrick M. Hausen" References: <20090709112512.GA44158@hugo10.ka.punkt.de> <73a41d4b72d62b0bfe3d0fb7206376a8.squirrel@cygnus.homeunix.com> <20090709123434.GC46563@hugo10.ka.punkt.de> <4A55EEEC.3030007@interazioni.it> <20090709134302.GA50485@hugo10.ka.punkt.de> In-Reply-To: <20090709134302.GA50485@hugo10.ka.punkt.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org, "Tonix \(Antonio Nati\)" Subject: Re: ZFS - thanks X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 23:13:36 -0000 Patrick M. Hausen wrote: > You cannot escape the poor write performance of RAID 5 and > comparable setups with or without hardware. No matter how > much you cache, one time a block must be written to disk. ZFS RAIDZ works differently: It is based on variable-sized blocks written to the disks based on incoming data stream, grouped into transactions. This makes it very efficient for clustering multi-threaded random I/O writes together into large physical disk writes. (The downside is it has to read the entire "stripe" even if you are only reading one byte, in order to calculate and verify the checksum.) - Andrew From owner-freebsd-stable@FreeBSD.ORG Fri Jul 10 00:55:31 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 14B27106564A for ; Fri, 10 Jul 2009 00:55:31 +0000 (UTC) (envelope-from oliver.pntr@gmail.com) Received: from mail-bw0-f221.google.com (mail-bw0-f221.google.com [209.85.218.221]) by mx1.freebsd.org (Postfix) with ESMTP id 95B268FC1B for ; Fri, 10 Jul 2009 00:55:30 +0000 (UTC) (envelope-from oliver.pntr@gmail.com) Received: by bwz21 with SMTP id 21so458141bwz.43 for ; Thu, 09 Jul 2009 17:55:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=HTNQxAq1vT8NGm8PqPGaqsBuw0Hvp68cY6I04Cca8QU=; b=TCmU7luaDf3DlDJ2J0L56vjPD5zTxuQoLK24wNezZCtW4RC+Qh+JVHv/oBZ8ENONOI bJbSseqbOCidAGoxAYdV3AWX77GJeLoMHKsC7U7LAiNNbVw7kyzTj3ISafLuJXx9P05Q Pcfc02pjPO7MaBOxjB53/d9qhfYaWxioalCV0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=ctWHOdkWQ5cvrmHvitixHDTC2Hh9J/p0cYCNCKzQX96OteJGILZilwH/OU0QQKKUmc 1UcfEenLpJOHDE3nmnJq6ulfKUw7mo3F6Jsh76/PUMKzhJWS9aYkjv/pqqadyj5QB/6Z XO60F6oNR9uZTFHhxo2CnGZm/UONKGXL2HB00= MIME-Version: 1.0 Received: by 10.103.1.17 with SMTP id d17mr770092mui.60.1247187329553; Thu, 09 Jul 2009 17:55:29 -0700 (PDT) Date: Fri, 10 Jul 2009 02:55:29 +0200 Message-ID: <6101e8c40907091755n5aefe289r6eec14cf7f4287dc@mail.gmail.com> From: Oliver Pinter To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: smbfs panic when lost connection or unmount --force X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2009 00:55:31 -0000 Hi all! It is a kernel panic, when force unmount the smbfs volume or lost the connection with the samba server. -- Thes OS is: kern.ostype: FreeBSD kern.osrelease: 7.2-STABLE kern.osrevision: 199506 kern.version: FreeBSD 7.2-STABLE #4: Sat Jun 27 21:44:32 CEST 2009 root@oliverp:/usr/obj/usr/src/sys/stable kern.osreldate: 702103 -- make.conf: CPUTYPE?=core2 CFLAGS= -O2 -fno-strict-aliasing -pipe MODULES_OVERRIDE=smbfs libiconv libmchain zfs opensolaris drm cd9660 cd9660_iconv -- panic message: Jul 10 01:58:39 oliverp syslogd: kernel boot file is /boot/kernel/kernel Jul 10 01:58:39 oliverp kernel: kernel trap 12 with interrupts disabled Jul 10 01:58:39 oliverp kernel: Jul 10 01:58:39 oliverp kernel: Jul 10 01:58:39 oliverp kernel: Fatal trap 12: page fault while in kernel mode Jul 10 01:58:39 oliverp kernel: cpuid = 2; apic id = 02 Jul 10 01:58:39 oliverp kernel: fault virtual address = 0x30 Jul 10 01:58:39 oliverp kernel: fault code = supervisor read data, page not present Jul 10 01:58:39 oliverp kernel: instruction pointer = 0x8:0xffffffff80327fd0 Jul 10 01:58:39 oliverp kernel: stack pointer = 0x10:0xffffff8078360940 Jul 10 01:58:39 oliverp kernel: frame pointer = 0x10:0xffffff0004c31390 Jul 10 01:58:39 oliverp kernel: code segment = base 0x0, limit 0xfffff, type 0x1b Jul 10 01:58:39 oliverp kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 Jul 10 01:58:39 oliverp kernel: processor eflags = resume, IOPL = 0 Jul 10 01:58:39 oliverp kernel: current process = 60406 (smbiod0) Jul 10 01:58:39 oliverp kernel: trap number = 12 Jul 10 01:58:39 oliverp kernel: panic: page fault Jul 10 01:58:39 oliverp kernel: cpuid = 2 Jul 10 01:58:39 oliverp kernel: Uptime: 6h51m16s Jul 10 01:58:39 oliverp kernel: Physical memory: 4087 MB Jul 10 01:58:39 oliverp kernel: Dumping 2448 MB:Copyright (c) 1992-2009 The FreeBSD Project. From owner-freebsd-stable@FreeBSD.ORG Fri Jul 10 00:59:21 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 82093106566C for ; Fri, 10 Jul 2009 00:59:21 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-fx0-f205.google.com (mail-fx0-f205.google.com [209.85.220.205]) by mx1.freebsd.org (Postfix) with ESMTP id 111B08FC1E for ; Fri, 10 Jul 2009 00:59:20 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: by fxm1 with SMTP id 1so519681fxm.19 for ; Thu, 09 Jul 2009 17:59:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=Vtbh5zOYtkVcXLGTB8dINXeZ9rGn5hTgsEhtUOfOSiw=; b=Vckb1B3o+qhMCCGR58oY2WeTrA+kXCgfMbbGuI1v/sZOPu9u5mrHOz6QxnC9RWmBf+ I7VMOVIgLX8H3hLIOP77+HyqAD7BsU7oRPZdBYycOyaSDIbdkvUJsF1d6HJdrBlgYPHe e4nbpMdWz66c3gg6u9hhgXldomjVBE+MpUN90= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=FUjCbc9IKk/95gObb/x0YvwRpQxk7bm7dbEeJAYVuyNiDvjoaHvpZ9eKVLwsGUbIUS DA5LDEC8SzW50dcPa9IZlJEyVXTtbUBR99qj5I3qRgOzha+s9qrjScmEFA83g6k9Fi8n wXwQHGMlRsTAoM9J1MwZOir9/3wmhLg21v4hE= MIME-Version: 1.0 Sender: asmrookie@gmail.com Received: by 10.223.108.78 with SMTP id e14mr656465fap.88.1247187559965; Thu, 09 Jul 2009 17:59:19 -0700 (PDT) In-Reply-To: <6101e8c40907091755n5aefe289r6eec14cf7f4287dc@mail.gmail.com> References: <6101e8c40907091755n5aefe289r6eec14cf7f4287dc@mail.gmail.com> Date: Fri, 10 Jul 2009 02:59:19 +0200 X-Google-Sender-Auth: 134545f817914404 Message-ID: <3bbf2fe10907091759g1f1f9502tb498382c5f3b48d6@mail.gmail.com> From: Attilio Rao To: Oliver Pinter Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: smbfs panic when lost connection or unmount --force X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2009 00:59:21 -0000 2009/7/10 Oliver Pinter : > Hi all! > > It is a kernel panic, when force unmount the smbfs volume or lost the > connection with the samba server. > > -- > Thes OS is: > > > kern.ostype: FreeBSD > kern.osrelease: 7.2-STABLE > kern.osrevision: 199506 > kern.version: FreeBSD 7.2-STABLE #4: Sat Jun 27 21:44:32 CEST 2009 > root@oliverp:/usr/obj/usr/src/sys/stable > kern.osreldate: 702103 > > -- > make.conf: > > > CPUTYPE?=core2 > CFLAGS= -O2 -fno-strict-aliasing -pipe > MODULES_OVERRIDE=smbfs libiconv libmchain zfs opensolaris drm cd9660 > cd9660_iconv > > -- > panic message: > > Jul 10 01:58:39 oliverp syslogd: kernel boot file is /boot/kernel/kernel > Jul 10 01:58:39 oliverp kernel: kernel trap 12 with interrupts disabled > Jul 10 01:58:39 oliverp kernel: > Jul 10 01:58:39 oliverp kernel: > Jul 10 01:58:39 oliverp kernel: Fatal trap 12: page fault while in kernel mode > Jul 10 01:58:39 oliverp kernel: cpuid = 2; apic id = 02 > Jul 10 01:58:39 oliverp kernel: fault virtual address = 0x30 > Jul 10 01:58:39 oliverp kernel: fault code = supervisor read data, > page not present > Jul 10 01:58:39 oliverp kernel: instruction pointer = 0x8:0xffffffff80327fd0 > Jul 10 01:58:39 oliverp kernel: stack pointer = 0x10:0xffffff8078360940 > Jul 10 01:58:39 oliverp kernel: frame pointer = 0x10:0xffffff0004c31390 > Jul 10 01:58:39 oliverp kernel: code segment = base 0x0, limit > 0xfffff, type 0x1b > Jul 10 01:58:39 oliverp kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 > Jul 10 01:58:39 oliverp kernel: processor eflags = resume, IOPL = 0 > Jul 10 01:58:39 oliverp kernel: current process = 60406 (smbiod0) > Jul 10 01:58:39 oliverp kernel: trap number = 12 > Jul 10 01:58:39 oliverp kernel: panic: page fault > Jul 10 01:58:39 oliverp kernel: cpuid = 2 > Jul 10 01:58:39 oliverp kernel: Uptime: 6h51m16s > Jul 10 01:58:39 oliverp kernel: Physical memory: 4087 MB > Jul 10 01:58:39 oliverp kernel: Dumping 2448 MB:Copyright (c) > 1992-2009 The FreeBSD Project. Can you at least produce a backtrace for that? Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-stable@FreeBSD.ORG Fri Jul 10 03:01:29 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2D44A1065675 for ; Fri, 10 Jul 2009 03:01:29 +0000 (UTC) (envelope-from invitations@boxbe.com) Received: from app002.boxbe.com (app002.boxbe.com [208.96.33.198]) by mx1.freebsd.org (Postfix) with ESMTP id 09EA98FC1B for ; Fri, 10 Jul 2009 03:01:29 +0000 (UTC) (envelope-from invitations@boxbe.com) Received: from app002.boxbe.com (localhost.localdomain [127.0.0.1]) by app002.boxbe.com (Postfix) with ESMTP id 860A2583F9 for ; Thu, 9 Jul 2009 19:29:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=boxbe.com; h=date:from :reply-to:to:message-id:subject:mime-version:content-type; s=s1; bh=tsvdLZOmmat6ICZmIypCVc5O5hM=; b=X91Ma9zwwf9biVd9o3LxFgLdzVUz hoUMypFo+R8rJYBxUcIsap+HPGXl//slgM8JYdnC4zZJeNrJPYBmu5Z2oXY4uaKi eypeO33fxqhNvacnjS4wXBv3XnM8qP+xA0i5BoN9lUj4RLWE0naSKJfwX6aBmpCO Ipaxf3EFPXKVl+A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=boxbe.com; h=date:from:reply-to :to:message-id:subject:mime-version:content-type; q=dns; s=s1; b=bqwbxaJ9gH22kqgB+2rK4lBwJYCJDzrR3vLKFyLXiVyWPePhXoT22ar0phQZU bnP9Or77dGhBREBB6aLdiXLgkXGAm2bNQOfUS0RNxcQlXo/ysWiDNKhZJ5F/0Z/F 7QNS6ZIUjq9SpLIkxMiZupann+RAIauyCOWiQlF9CDNxHw= Received: from app002.boxbe.com (localhost.localdomain [127.0.0.1]) by app002.boxbe.com (Postfix) with ESMTP id BFD74583C5 for ; Thu, 9 Jul 2009 19:29:15 -0700 (PDT) Date: Thu, 9 Jul 2009 19:29:15 -0700 (PDT) From: ahmad syarifudin To: freebsd-stable@freebsd.org Message-ID: <1389727859.11369011.1247192955785.JavaMail.prod@app002.boxbe.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_11369008_1393306464.1247192955783" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: ahmad syarifudin added you as a friend on Boxbe X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ahmad syarifudin List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2009 03:01:29 -0000 ------=_Part_11369008_1393306464.1247192955783 Content-Type: multipart/related; boundary="----=_Part_11369009_1140053560.1247192955783" ------=_Part_11369009_1140053560.1247192955783 Content-Type: multipart/alternative; boundary="----=_Part_11369010_1031084386.1247192955784" ------=_Part_11369010_1031084386.1247192955784 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I use Boxbe to manage my inbox. I think Boxbe can help you, too! Here's the link: https://www.boxbe.com/register?tc=211772005_1203235125 -ahmad Please do not reply directly to this email. This message was sent at the request of syarifudin@gmail.com. Boxbe will not use your email address for any other purpose. Click the link below if you would prefer not to receive any further invitations from Boxbe members: https://www.boxbe.com/unsubscribe?email=freebsd-stable@freebsd.org&tc=211772005_1203235125 Boxbe integrates with Yahoo!, Gmail, and AOL email addresses. Get Boxbe today! Boxbe, Inc. | 2390 Chestnut Street #201 | San Francisco, CA 94123 ------=_Part_11369010_1031084386.1247192955784 Content-Transfer-Encoding: 7bit MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Boxbe | Contact Request I use Boxbe to manage my inbox. I think Boxbe can help you, too! Here's the link: [1]https://www.boxbe.com/register?tc=211772005_1203235125 -ahmad Please do not reply directly to this email. This message was sent at the request of syarifudin@gmail.com. Boxbe will not use your email address for any other purpose. If you would prefer not to receive any further invitations from Boxbe members, [2]click here. Boxbe, Inc. | 2390 Chestnut Street #201 | San Francisco, CA 94123 References 1. https://www.boxbe.com/register?tc=211772005_1203235125 2. https://www.boxbe.com/unsubscribe?email=freebsd-stable@freebsd.org&tc=211772005_1203235125 ------=_Part_11369010_1031084386.1247192955784-- ------=_Part_11369009_1140053560.1247192955783-- ------=_Part_11369008_1393306464.1247192955783-- From owner-freebsd-stable@FreeBSD.ORG Fri Jul 10 07:35:42 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 32DFF106564A for ; Fri, 10 Jul 2009 07:35:42 +0000 (UTC) (envelope-from vm@vm.net.ua) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.158]) by mx1.freebsd.org (Postfix) with ESMTP id C1A968FC1B for ; Fri, 10 Jul 2009 07:35:41 +0000 (UTC) (envelope-from vm@vm.net.ua) Received: by fg-out-1718.google.com with SMTP id 13so175892fge.12 for ; Fri, 10 Jul 2009 00:35:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.239.181.10 with SMTP id k10mr157372hbg.166.1247210916127; Fri, 10 Jul 2009 00:28:36 -0700 (PDT) In-Reply-To: <200907091922.n69JMYvS067578@lava.sentex.ca> References: <200907091922.n69JMYvS067578@lava.sentex.ca> From: =?UTF-8?B?0JLQuNGC0LDQu9C40Lkg0JzQvtC40YHQtdC10LI=?= Date: Fri, 10 Jul 2009 10:28:16 +0300 Message-ID: To: freebsd-stable Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: pppoe on a VLAN interface issues (RELENG_7) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2009 07:35:42 -0000 2009/7/9 Mike Tancsa Jul 9 14:34:17 fw02 kernel: ng_ether_attach: can't name node em1.10 > Jul 9 14:34:17 fw02 kernel: ng_ether_attach: can't name node em1.172 > Jul 9 14:34:17 fw02 kernel: ng_ether_attach: can't name node em1.24 > > Is there some reason this does not work ? > reason - interfaces names with "." :) --=20 WBR, =D0=92=D0=B8=D1=82=D0=B0=D0=BB=D0=B8=D0=B9 =D0=9C=D0=BE=D0=B8=D1=81=D0= =B5=D0=B5=D0=B2, vm@vm.net.ua Nick-hdl: VM347-RIPE, VM265-UANIC ICQ# 111222168 From owner-freebsd-stable@FreeBSD.ORG Fri Jul 10 07:48:14 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D7D9A106564A for ; Fri, 10 Jul 2009 07:48:14 +0000 (UTC) (envelope-from vm@vm.net.ua) Received: from mail-fx0-f224.google.com (mail-fx0-f224.google.com [209.85.220.224]) by mx1.freebsd.org (Postfix) with ESMTP id 74A738FC0A for ; Fri, 10 Jul 2009 07:48:14 +0000 (UTC) (envelope-from vm@vm.net.ua) Received: by fxm24 with SMTP id 24so560005fxm.43 for ; Fri, 10 Jul 2009 00:48:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.239.159.208 with SMTP id z16mr141228hbc.8.1247210427320; Fri, 10 Jul 2009 00:20:27 -0700 (PDT) In-Reply-To: <200907091922.n69JMYvS067578@lava.sentex.ca> References: <200907091922.n69JMYvS067578@lava.sentex.ca> From: =?UTF-8?B?0JLQuNGC0LDQu9C40Lkg0JzQvtC40YHQtdC10LI=?= Date: Fri, 10 Jul 2009 10:20:07 +0300 Message-ID: To: Mike Tancsa Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org Subject: Re: pppoe on a VLAN interface issues (RELENG_7) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2009 07:48:15 -0000 2009/7/9 Mike Tancsa Jul 9 14:34:17 fw02 kernel: ng_ether_attach: can't name node em1.10 > Jul 9 14:34:17 fw02 kernel: ng_ether_attach: can't name node em1.172 > Jul 9 14:34:17 fw02 kernel: ng_ether_attach: can't name node em1.24 > > Is there some reason this does not work ? reason - names of interfaces with "." :) --=20 WBR, =D0=92=D0=B8=D1=82=D0=B0=D0=BB=D0=B8=D0=B9 =D0=9C=D0=BE=D0=B8=D1=81=D0= =B5=D0=B5=D0=B2, vm@vm.net.ua Nick-hdl: VM347-RIPE, VM265-UANIC ICQ# 111222168 From owner-freebsd-stable@FreeBSD.ORG Fri Jul 10 11:10:04 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B23FF106566B for ; Fri, 10 Jul 2009 11:10:04 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 8CB528FC08 for ; Fri, 10 Jul 2009 11:10:04 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 45E0446B46; Fri, 10 Jul 2009 07:10:04 -0400 (EDT) Date: Fri, 10 Jul 2009 12:10:04 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Oliver Pinter In-Reply-To: <6101e8c40907091755n5aefe289r6eec14cf7f4287dc@mail.gmail.com> Message-ID: References: <6101e8c40907091755n5aefe289r6eec14cf7f4287dc@mail.gmail.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-stable@freebsd.org Subject: Re: smbfs panic when lost connection or unmount --force X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2009 11:10:04 -0000 On Fri, 10 Jul 2009, Oliver Pinter wrote: > It is a kernel panic, when force unmount the smbfs volume or lost the > connection with the samba server. This is a NULL pointer dereference in the kernel. Per Attilio's e-mail, a stack trace should help us track it down. Thanks! Robert N M Watson Computer Laboratory University of Cambridge > > -- > Thes OS is: > > > kern.ostype: FreeBSD > kern.osrelease: 7.2-STABLE > kern.osrevision: 199506 > kern.version: FreeBSD 7.2-STABLE #4: Sat Jun 27 21:44:32 CEST 2009 > root@oliverp:/usr/obj/usr/src/sys/stable > kern.osreldate: 702103 > > -- > make.conf: > > > CPUTYPE?=core2 > CFLAGS= -O2 -fno-strict-aliasing -pipe > MODULES_OVERRIDE=smbfs libiconv libmchain zfs opensolaris drm cd9660 > cd9660_iconv > > -- > panic message: > > Jul 10 01:58:39 oliverp syslogd: kernel boot file is /boot/kernel/kernel > Jul 10 01:58:39 oliverp kernel: kernel trap 12 with interrupts disabled > Jul 10 01:58:39 oliverp kernel: > Jul 10 01:58:39 oliverp kernel: > Jul 10 01:58:39 oliverp kernel: Fatal trap 12: page fault while in kernel mode > Jul 10 01:58:39 oliverp kernel: cpuid = 2; apic id = 02 > Jul 10 01:58:39 oliverp kernel: fault virtual address = 0x30 > Jul 10 01:58:39 oliverp kernel: fault code = supervisor read data, > page not present > Jul 10 01:58:39 oliverp kernel: instruction pointer = 0x8:0xffffffff80327fd0 > Jul 10 01:58:39 oliverp kernel: stack pointer = 0x10:0xffffff8078360940 > Jul 10 01:58:39 oliverp kernel: frame pointer = 0x10:0xffffff0004c31390 > Jul 10 01:58:39 oliverp kernel: code segment = base 0x0, limit > 0xfffff, type 0x1b > Jul 10 01:58:39 oliverp kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 > Jul 10 01:58:39 oliverp kernel: processor eflags = resume, IOPL = 0 > Jul 10 01:58:39 oliverp kernel: current process = 60406 (smbiod0) > Jul 10 01:58:39 oliverp kernel: trap number = 12 > Jul 10 01:58:39 oliverp kernel: panic: page fault > Jul 10 01:58:39 oliverp kernel: cpuid = 2 > Jul 10 01:58:39 oliverp kernel: Uptime: 6h51m16s > Jul 10 01:58:39 oliverp kernel: Physical memory: 4087 MB > Jul 10 01:58:39 oliverp kernel: Dumping 2448 MB:Copyright (c) > 1992-2009 The FreeBSD Project. > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From owner-freebsd-stable@FreeBSD.ORG Fri Jul 10 11:38:49 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9CB06106566C for ; Fri, 10 Jul 2009 11:38:49 +0000 (UTC) (envelope-from raul@pop.isdefe.es) Received: from mail1.isdefe.es (mail1.isdefe.es [194.15.213.239]) by mx1.freebsd.org (Postfix) with ESMTP id 62AAD8FC14 for ; Fri, 10 Jul 2009 11:38:49 +0000 (UTC) (envelope-from raul@pop.isdefe.es) Received: from mail1.isdefe.es (mail1.isdefe.es [127.0.0.1]) by localhost.isdefe.es (Postfix) with ESMTP id 9733E2BAC1F for ; Fri, 10 Jul 2009 13:21:24 +0200 (CEST) Received: from [10.200.104.66] (unknown [10.200.104.66]) by mail1.isdefe.es (Postfix) with ESMTP id 8B8CC2BAC1C for ; Fri, 10 Jul 2009 13:21:24 +0200 (CEST) Message-ID: <4A57244A.1090109@pop.isdefe.es> Date: Fri, 10 Jul 2009 13:21:46 +0200 From: Raul User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: regression on releng_7 (and 8 beta1 vs proliant dl 385) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2009 11:38:49 -0000 Hello, I've tried an 8 beta 1 (from usb image, and source upgrade) and releng_7 (both amd64) from today on a hp's proliant 385 with the same misbehaviors, kernel hung during boot at exactly the same point. Last message on the console is: 'pci0: on pcib0' and the disk led activity is solid on. After some trial / error and looking for more information, I've tried verbose boot and surprisingly the machines finish the boot process flawlessly and ask for credentials. verbose dmesg availables at: http://pastebin.com/m1918b1db http://pastebin.com/m5edd8d03 Both boxes used to run releng_7_2 perfectly, and are ready to try whatever you ask me ;). Thanks a lot in advance. Regards, Raul. From owner-freebsd-stable@FreeBSD.ORG Fri Jul 10 12:09:54 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8CCBB106564A for ; Fri, 10 Jul 2009 12:09:54 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id B79158FC12 for ; Fri, 10 Jul 2009 12:09:53 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id PAA03654; Fri, 10 Jul 2009 15:09:51 +0300 (EEST) (envelope-from avg@icyb.net.ua) Message-ID: <4A572F8E.6040004@icyb.net.ua> Date: Fri, 10 Jul 2009 15:09:50 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.22 (X11/20090630) MIME-Version: 1.0 To: Thomas Ronner References: <1247085058.6197.18.camel@bugstore> <4A55F96B.6070303@icyb.net.ua> <4A560E2F.1050906@ronner.org> <4A5626FC.5000306@ronner.org> <4A562A4A.2000201@icyb.net.ua> <4A563627.7040407@ronner.org> In-Reply-To: <4A563627.7040407@ronner.org> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=KOI8-U Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: ZFS: zpool scrub lockup X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2009 12:09:54 -0000 on 09/07/2009 21:25 Thomas Ronner said the following: > Is this: > http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug-online-gdb.html > (10.6 On-Line Kernel Debugging Using Remote GDB) the debugging via > serial console you're referring to? Yes. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Fri Jul 10 12:17:44 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1D2F71065672 for ; Fri, 10 Jul 2009 12:17:44 +0000 (UTC) (envelope-from oliver.pntr@gmail.com) Received: from mail-bw0-f221.google.com (mail-bw0-f221.google.com [209.85.218.221]) by mx1.freebsd.org (Postfix) with ESMTP id 030BF8FC26 for ; Fri, 10 Jul 2009 12:17:42 +0000 (UTC) (envelope-from oliver.pntr@gmail.com) Received: by bwz21 with SMTP id 21so669195bwz.43 for ; Fri, 10 Jul 2009 05:17:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=vuQskjpY/5TmBT5+7TwUiG2CWAtTutBWAvDetPRJZ9c=; b=qJ3oBjsuYtGiXqgVTy3t50bhdwP2VQ2Cs//0PhXdiQk1uR1gX8xtJN4mJ8omHMB8yd CauzlOvyu0c7mCsvC8MaCwwQvXR5G9PcdGuUyi1dwCFtj7S/rfCRM1HWVGCliCJsV6Y/ pErCQzVVLFS4d/NhI5+c3R9+hZrzPAGav20Fc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=AwC1AKBdSZjgt3bDoDC2IR+Q5Q61xWRTndVNqEYrCC5zgMf8tvDUcwUY51ADIgC5dD 3z6px3kRgNTCQ+3rU+KERa0UgcaOv+OeFQkDhbP12/JlYZ+aCy+du5itV6Iptls6W7+3 fesgSrfOfxc8dq+a1qss5eyhgWRvhcOzc/efs= MIME-Version: 1.0 Received: by 10.103.176.20 with SMTP id d20mr1066549mup.27.1247228261811; Fri, 10 Jul 2009 05:17:41 -0700 (PDT) In-Reply-To: References: <6101e8c40907091755n5aefe289r6eec14cf7f4287dc@mail.gmail.com> Date: Fri, 10 Jul 2009 14:17:41 +0200 Message-ID: <6101e8c40907100517q2d2e5891m62b0b7d57496b10@mail.gmail.com> From: Oliver Pinter To: Robert Watson Content-Type: multipart/mixed; boundary=00163641759b7fc68c046e58f5d0 Cc: freebsd-stable@freebsd.org Subject: Re: smbfs panic when lost connection or unmount --force X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2009 12:17:44 -0000 --00163641759b7fc68c046e58f5d0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hello! I know, that the bt is useful, but ddb works with usb keyboard? At nigth then I send the log. //sorry for bad english ps.: attached the config On 7/10/09, Robert Watson wrote: > > On Fri, 10 Jul 2009, Oliver Pinter wrote: > >> It is a kernel panic, when force unmount the smbfs volume or lost the >> connection with the samba server. > > This is a NULL pointer dereference in the kernel. Per Attilio's e-mail, a > stack trace should help us track it down. Thanks! > > Robert N M Watson > Computer Laboratory > University of Cambridge > >> >> -- >> Thes OS is: >> >> >> kern.ostype: FreeBSD >> kern.osrelease: 7.2-STABLE >> kern.osrevision: 199506 >> kern.version: FreeBSD 7.2-STABLE #4: Sat Jun 27 21:44:32 CEST 2009 >> root@oliverp:/usr/obj/usr/src/sys/stable >> kern.osreldate: 702103 >> >> -- >> make.conf: >> >> >> CPUTYPE?=core2 >> CFLAGS= -O2 -fno-strict-aliasing -pipe >> MODULES_OVERRIDE=smbfs libiconv libmchain zfs opensolaris drm cd9660 >> cd9660_iconv >> >> -- >> panic message: >> >> Jul 10 01:58:39 oliverp syslogd: kernel boot file is /boot/kernel/kernel >> Jul 10 01:58:39 oliverp kernel: kernel trap 12 with interrupts disabled >> Jul 10 01:58:39 oliverp kernel: >> Jul 10 01:58:39 oliverp kernel: >> Jul 10 01:58:39 oliverp kernel: Fatal trap 12: page fault while in kernel >> mode >> Jul 10 01:58:39 oliverp kernel: cpuid = 2; apic id = 02 >> Jul 10 01:58:39 oliverp kernel: fault virtual address = 0x30 >> Jul 10 01:58:39 oliverp kernel: fault code = supervisor read data, >> page not present >> Jul 10 01:58:39 oliverp kernel: instruction pointer = >> 0x8:0xffffffff80327fd0 >> Jul 10 01:58:39 oliverp kernel: stack pointer = >> 0x10:0xffffff8078360940 >> Jul 10 01:58:39 oliverp kernel: frame pointer = >> 0x10:0xffffff0004c31390 >> Jul 10 01:58:39 oliverp kernel: code segment = base 0x0, limit >> 0xfffff, type 0x1b >> Jul 10 01:58:39 oliverp kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 >> Jul 10 01:58:39 oliverp kernel: processor eflags = resume, IOPL = 0 >> Jul 10 01:58:39 oliverp kernel: current process = 60406 (smbiod0) >> Jul 10 01:58:39 oliverp kernel: trap number = 12 >> Jul 10 01:58:39 oliverp kernel: panic: page fault >> Jul 10 01:58:39 oliverp kernel: cpuid = 2 >> Jul 10 01:58:39 oliverp kernel: Uptime: 6h51m16s >> Jul 10 01:58:39 oliverp kernel: Physical memory: 4087 MB >> Jul 10 01:58:39 oliverp kernel: Dumping 2448 MB:Copyright (c) >> 1992-2009 The FreeBSD Project. >> _______________________________________________ >> 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" >> > --00163641759b7fc68c046e58f5d0 Content-Type: text/plain; charset=US-ASCII; name=kernel_conf Content-Disposition: attachment; filename=kernel_conf Content-Transfer-Encoding: base64 X-Attachment-Id: file0 IwojIEdFTkVSSUMgLS0gR2VuZXJpYyBrZXJuZWwgY29uZmlndXJhdGlvbiBmaWxlIGZvciBGcmVl QlNEL2FtZDY0CiMKIyBGb3IgbW9yZSBpbmZvcm1hdGlvbiBvbiB0aGlzIGZpbGUsIHBsZWFzZSBy ZWFkIHRoZSBoYW5kYm9vayBzZWN0aW9uIG9uCiMgS2VybmVsIENvbmZpZ3VyYXRpb24gRmlsZXM6 CiMKIyAgICBodHRwOi8vd3d3LkZyZWVCU0Qub3JnL2RvYy9lbl9VUy5JU084ODU5LTEvYm9va3Mv aGFuZGJvb2sva2VybmVsY29uZmlnLWNvbmZpZy5odG1sCiMKIyBUaGUgaGFuZGJvb2sgaXMgYWxz byBhdmFpbGFibGUgbG9jYWxseSBpbiAvdXNyL3NoYXJlL2RvYy9oYW5kYm9vawojIGlmIHlvdSd2 ZSBpbnN0YWxsZWQgdGhlIGRvYyBkaXN0cmlidXRpb24sIG90aGVyd2lzZSBhbHdheXMgc2VlIHRo ZQojIEZyZWVCU0QgV29ybGQgV2lkZSBXZWIgc2VydmVyIChodHRwOi8vd3d3LkZyZWVCU0Qub3Jn LykgZm9yIHRoZQojIGxhdGVzdCBpbmZvcm1hdGlvbi4KIwojIEFuIGV4aGF1c3RpdmUgbGlzdCBv ZiBvcHRpb25zIGFuZCBtb3JlIGRldGFpbGVkIGV4cGxhbmF0aW9ucyBvZiB0aGUKIyBkZXZpY2Ug bGluZXMgaXMgYWxzbyBwcmVzZW50IGluIHRoZSAuLi8uLi9jb25mL05PVEVTIGFuZCBOT1RFUyBm aWxlcy4KIyBJZiB5b3UgYXJlIGluIGRvdWJ0IGFzIHRvIHRoZSBwdXJwb3NlIG9yIG5lY2Vzc2l0 eSBvZiBhIGxpbmUsIGNoZWNrIGZpcnN0CiMgaW4gTk9URVMuCiMKIyAkRnJlZUJTRDogc3JjL3N5 cy9hbWQ2NC9jb25mL0dFTkVSSUMsdiAxLjQ4NC4yLjE0IDIwMDgvMDgvMjkgMTg6NTQ6MzUgamhi IEV4cCAkCgpjcHUJCUhBTU1FUgppZGVudAkJc1RhQmxFLWRlYnVnCgojIFRvIHN0YXRpY2FsbHkg Y29tcGlsZSBpbiBkZXZpY2Ugd2lyaW5nIGluc3RlYWQgb2YgL2Jvb3QvZGV2aWNlLmhpbnRzCiNo aW50cwkJIkdFTkVSSUMuaGludHMiCQkjIERlZmF1bHQgcGxhY2VzIHRvIGxvb2sgZm9yIGRldmlj ZXMuCgptYWtlb3B0aW9ucwlERUJVRz0tZwkJIyBCdWlsZCBrZXJuZWwgd2l0aCBnZGIoMSkgZGVi dWcgc3ltYm9scwoKIyBEZWJ1Z2dpbmcgZm9yIHVzZSBpbiAtY3VycmVudApvcHRpb25zICAgICAg ICAgS0RCICAgICAgICAgICAgICAgICAgICAgIyBFbmFibGUga2VybmVsIGRlYnVnZ2VyIHN1cHBv cnQuCm9wdGlvbnMgICAgICAgICBEREIgICAgICAgICAgICAgICAgICAgICAjIFN1cHBvcnQgRERC LgpvcHRpb25zICAgICAgICAgR0RCICAgICAgICAgICAgICAgICAgICAgIyBTdXBwb3J0IHJlbW90 ZSBHREIuCm9wdGlvbnMgICAgICAgICBJTlZBUklBTlRTICAgICAgICAgICAgICAjIEVuYWJsZSBj YWxscyBvZiBleHRyYSBzYW5pdHkgY2hlY2tpbmcKb3B0aW9ucyAgICAgICAgIElOVkFSSUFOVF9T VVBQT1JUICAgICAgICMgRXh0cmEgc2FuaXR5IGNoZWNrcyBvZiBpbnRlcm5hbCBzdHJ1Y3QKIyB1 cmVzLCByZXF1aXJlZCBieSBJTlZBUklBTlRTCm9wdGlvbnMgICAgICAgICBXSVRORVNTICAgICAg ICAgICAgICAgICAjIEVuYWJsZSBjaGVja3MgdG8gZGV0ZWN0IGRlYWRsb2NrcyBhbmQKIyBjeWNs ZXMKIwoKCm9wdGlvbnMgCVNDSEVEX1VMRQkJIyBVTEUgc2NoZWR1bGVyCm9wdGlvbnMgCVBSRUVN UFRJT04JCSMgRW5hYmxlIGtlcm5lbCB0aHJlYWQgcHJlZW1wdGlvbgpvcHRpb25zIAlJTkVUCQkJ IyBJbnRlck5FVHdvcmtpbmcKb3B0aW9ucyAJSU5FVDYJCQkjIElQdjYgY29tbXVuaWNhdGlvbnMg cHJvdG9jb2xzCm9wdGlvbnMgCVNDVFAJCQkjIFN0cmVhbSBDb250cm9sIFRyYW5zbWlzc2lvbiBQ cm90b2NvbCAKb3B0aW9ucyAJRkZTCQkJIyBCZXJrZWxleSBGYXN0IEZpbGVzeXN0ZW0Kb3B0aW9u cyAJU09GVFVQREFURVMJCSMgRW5hYmxlIEZGUyBzb2Z0IHVwZGF0ZXMgc3VwcG9ydApvcHRpb25z ICAgICAgICAgVUZTX0VYVEFUVFIKb3B0aW9ucyAgICAgICAgIFVGU19FWFRBVFRSX0FVVE9TVEFS VApvcHRpb25zIAlVRlNfQUNMCQkJIyBTdXBwb3J0IGZvciBhY2Nlc3MgY29udHJvbCBsaXN0cwpv cHRpb25zIAlVRlNfRElSSEFTSAkJIyBJbXByb3ZlIHBlcmZvcm1hbmNlIG9uIGJpZyBkaXJlY3Rv cmllcwpvcHRpb25zIAlVRlNfR0pPVVJOQUwJCSMgRW5hYmxlIGdqb3VybmFsLWJhc2VkIFVGUyBq b3VybmFsaW5nCm9wdGlvbnMgCU1EX1JPT1QJCQkjIE1EIGlzIGEgcG90ZW50aWFsIHJvb3QgZGV2 aWNlCiNvcHRpb25zIAlORlNDTElFTlQJCSMgTmV0d29yayBGaWxlc3lzdGVtIENsaWVudAojb3B0 aW9ucyAJTkZTU0VSVkVSCQkjIE5ldHdvcmsgRmlsZXN5c3RlbSBTZXJ2ZXIKI29wdGlvbnMgCU5G U0xPQ0tECQkjIE5ldHdvcmsgTG9jayBNYW5hZ2VyCiNvcHRpb25zIAlORlNfUk9PVAkJIyBORlMg dXNhYmxlIGFzIC8sIHJlcXVpcmVzIE5GU0NMSUVOVAojb3B0aW9ucyAJTlRGUwkJCSMgTlQgRmls ZSBTeXN0ZW0Kb3B0aW9ucyAJTVNET1NGUwkJCSMgTVNET1MgRmlsZXN5c3RlbQpvcHRpb25zIAlD RDk2NjAJCQkjIElTTyA5NjYwIEZpbGVzeXN0ZW0Kb3B0aW9ucyAJUFJPQ0ZTCQkJIyBQcm9jZXNz IGZpbGVzeXN0ZW0gKHJlcXVpcmVzIFBTRVVET0ZTKQpvcHRpb25zIAlQU0VVRE9GUwkJIyBQc2V1 ZG8tZmlsZXN5c3RlbSBmcmFtZXdvcmsKb3B0aW9ucyAJR0VPTV9QQVJUX0dQVAkJIyBHVUlEIFBh cnRpdGlvbiBUYWJsZXMuCm9wdGlvbnMgCUdFT01fTEFCRUwJCSMgUHJvdmlkZXMgbGFiZWxpemF0 aW9uCm9wdGlvbnMgCUNPTVBBVF80M1RUWQkJIyBCU0QgNC4zIFRUWSBjb21wYXQgW0tFRVAgVEhJ UyFdCm9wdGlvbnMgCUNPTVBBVF9JQTMyCQkjIENvbXBhdGlibGUgd2l0aCBpMzg2IGJpbmFyaWVz Cm9wdGlvbnMgCUNPTVBBVF9GUkVFQlNENAkJIyBDb21wYXRpYmxlIHdpdGggRnJlZUJTRDQKb3B0 aW9ucyAJQ09NUEFUX0ZSRUVCU0Q1CQkjIENvbXBhdGlibGUgd2l0aCBGcmVlQlNENQpvcHRpb25z IAlDT01QQVRfRlJFRUJTRDYJCSMgQ29tcGF0aWJsZSB3aXRoIEZyZWVCU0Q2Cm9wdGlvbnMgCVND U0lfREVMQVk9NTAwMAkJIyBEZWxheSAoaW4gbXMpIGJlZm9yZSBwcm9iaW5nIFNDU0kKb3B0aW9u cyAJS1RSQUNFCQkJIyBrdHJhY2UoMSkgc3VwcG9ydApvcHRpb25zIAlTVEFDSwkJCSMgc3RhY2so OSkgc3VwcG9ydApvcHRpb25zIAlTWVNWU0hNCQkJIyBTWVNWLXN0eWxlIHNoYXJlZCBtZW1vcnkK b3B0aW9ucyAJU1lTVk1TRwkJCSMgU1lTVi1zdHlsZSBtZXNzYWdlIHF1ZXVlcwpvcHRpb25zIAlT WVNWU0VNCQkJIyBTWVNWLXN0eWxlIHNlbWFwaG9yZXMKb3B0aW9ucyAJX0tQT1NJWF9QUklPUklU WV9TQ0hFRFVMSU5HICMgUE9TSVggUDEwMDNfMUIgcmVhbC10aW1lIGV4dGVuc2lvbnMKb3B0aW9u cyAJS0JEX0lOU1RBTExfQ0RFVgkjIGluc3RhbGwgYSBDREVWIGVudHJ5IGluIC9kZXYKb3B0aW9u cyAJQURBUFRJVkVfR0lBTlQJCSMgR2lhbnQgbXV0ZXggaXMgYWRhcHRpdmUuCm9wdGlvbnMgCVNU T1BfTk1JCQkjIFN0b3AgQ1BVUyB1c2luZyBOTUkgaW5zdGVhZCBvZiBJUEkKb3B0aW9ucyAJQVVE SVQJCQkjIFNlY3VyaXR5IGV2ZW50IGF1ZGl0aW5nCiNvcHRpb25zIAlLRFRSQUNFX0ZSQU1FCQkj IEVuc3VyZSBmcmFtZXMgYXJlIGNvbXBpbGVkIGluCiNvcHRpb25zIAlLRFRSQUNFX0hPT0tTCQkj IEtlcm5lbCBEVHJhY2UgaG9va3MKCiMgTWFrZSBhbiBTTVAtY2FwYWJsZSBrZXJuZWwgYnkgZGVm YXVsdApvcHRpb25zIAlTTVAJCQkjIFN5bW1ldHJpYyBNdWx0aVByb2Nlc3NvciBLZXJuZWwKCm9w dGlvbnMgICAgICAgICBIWj0xMDAKCiMgQ1BVIGZyZXF1ZW5jeSBjb250cm9sCmRldmljZQkJY3B1 ZnJlcQoKIyBCdXMgc3VwcG9ydC4KZGV2aWNlCQlhY3BpCmRldmljZQkJcGNpCgojIEZsb3BweSBk cml2ZXMKI2RldmljZQkJZmRjCgojIEFUQSBhbmQgQVRBUEkgZGV2aWNlcwpkZXZpY2UJCWF0YQpk ZXZpY2UJCWF0YWRpc2sJCSMgQVRBIGRpc2sgZHJpdmVzCmRldmljZQkJYXRhcmFpZAkJIyBBVEEg UkFJRCBkcml2ZXMKZGV2aWNlCQlhdGFwaWNkCQkjIEFUQVBJIENEUk9NIGRyaXZlcwojZGV2aWNl CQlhdGFwaWZkCQkjIEFUQVBJIGZsb3BweSBkcml2ZXMKI2RldmljZQkJYXRhcGlzdAkJIyBBVEFQ SSB0YXBlIGRyaXZlcwpvcHRpb25zIAlBVEFfU1RBVElDX0lECSMgU3RhdGljIGRldmljZSBudW1i ZXJpbmcKCiMgU0NTSSBDb250cm9sbGVycwojZGV2aWNlCQlhaGMJCSMgQUhBMjk0MCBhbmQgb25i b2FyZCBBSUM3eHh4IGRldmljZXMKI29wdGlvbnMgCUFIQ19SRUdfUFJFVFRZX1BSSU5UCSMgUHJp bnQgcmVnaXN0ZXIgYml0ZmllbGRzIGluIGRlYnVnCgkJCQkJIyBvdXRwdXQuICBBZGRzIH4xMjhr IHRvIGRyaXZlci4KI2RldmljZQkJYWhkCQkjIEFIQTM5MzIwLzI5MzIwIGFuZCBvbmJvYXJkIEFJ Qzc5eHggZGV2aWNlcwojb3B0aW9ucyAJQUhEX1JFR19QUkVUVFlfUFJJTlQJIyBQcmludCByZWdp c3RlciBiaXRmaWVsZHMgaW4gZGVidWcKCQkJCQkjIG91dHB1dC4gIEFkZHMgfjIxNWsgdG8gZHJp dmVyLgojZGV2aWNlCQlhbWQJCSMgQU1EIDUzQzk3NCAoVGVrcmFtIERDLTM5MChUKSkKI2Rldmlj ZQkJaHB0aW9wCQkjIEhpZ2hwb2ludCBSb2NrZXRSYWlkIDN4eHggc2VyaWVzCiNkZXZpY2UJCWlz cAkJIyBRbG9naWMgZmFtaWx5CiNkZXZpY2UgCWlzcGZ3CQkjIEZpcm13YXJlIGZvciBRTG9naWMg SEJBcy0gbm9ybWFsbHkgYSBtb2R1bGUKI2RldmljZQkJbXB0CQkjIExTSS1Mb2dpYyBNUFQtRnVz aW9uCiNkZXZpY2UJCW5jcgkJIyBOQ1IvU3ltYmlvcyBMb2dpYwojZGV2aWNlCQlzeW0JCSMgTkNS L1N5bWJpb3MgTG9naWMgKG5ld2VyIGNoaXBzZXRzICsgdGhvc2Ugb2YgYG5jcicpCiNkZXZpY2UJ CXRybQkJIyBUZWtyYW0gREMzOTVVL1VXL0YgREMzMTVVIGFkYXB0ZXJzCgojZGV2aWNlCQlhZHYJ CSMgQWR2YW5zeXMgU0NTSSBhZGFwdGVycwojZGV2aWNlCQlhZHcJCSMgQWR2YW5zeXMgd2lkZSBT Q1NJIGFkYXB0ZXJzCiNkZXZpY2UJCWFpYwkJIyBBZGFwdGVjIDE1WzAxMl14IFNDU0kgYWRhcHRl cnMsIEFJQy02WzIzXTYwLgojZGV2aWNlCQlidAkJIyBCdXNsb2dpYy9NeWxleCBNdWx0aU1hc3Rl ciBTQ1NJIGFkYXB0ZXJzCgoKIyBTQ1NJIHBlcmlwaGVyYWxzCmRldmljZQkJc2NidXMJCSMgU0NT SSBidXMgKHJlcXVpcmVkIGZvciBTQ1NJKQpkZXZpY2UJCWNoCQkjIFNDU0kgbWVkaWEgY2hhbmdl cnMKZGV2aWNlCQlkYQkJIyBEaXJlY3QgQWNjZXNzIChkaXNrcykKI2RldmljZQkJc2EJCSMgU2Vx dWVudGlhbCBBY2Nlc3MgKHRhcGUgZXRjKQpkZXZpY2UJCWNkCQkjIENECmRldmljZQkJcGFzcwkJ IyBQYXNzdGhyb3VnaCBkZXZpY2UgKGRpcmVjdCBTQ1NJIGFjY2VzcykKZGV2aWNlCQlzZXMJCSMg U0NTSSBFbnZpcm9ubWVudGFsIFNlcnZpY2VzIChhbmQgU0FGLVRFKQoKIyBSQUlEIGNvbnRyb2xs ZXJzIGludGVyZmFjZWQgdG8gdGhlIFNDU0kgc3Vic3lzdGVtCiNkZXZpY2UJCWFtcgkJIyBBTUkg TWVnYVJBSUQKI2RldmljZQkJYXJjbXNyCQkjIEFyZWNhIFNBVEEgSUkgUkFJRAojZGV2aWNlCQlj aXNzCQkjIENvbXBhcSBTbWFydCBSQUlEIDUqCiNkZXZpY2UJCWRwdAkJIyBEUFQgU21hcnRjYWNo ZSBJSUksIElWIC0gU2VlIE5PVEVTIGZvciBvcHRpb25zCiNkZXZpY2UJCWhwdG12CQkjIEhpZ2hw b2ludCBSb2NrZXRSQUlEIDE4MngKI2RldmljZQkJaHB0cnIJCSMgSGlnaHBvaW50IFJvY2tldFJB SUQgMTd4eCwgMjJ4eCwgMjN4eCwgMjV4eApkZXZpY2UJCWlpcgkJIyBJbnRlbCBJbnRlZ3JhdGVk IFJBSUQKI2RldmljZQkJaXBzCQkjIElCTSAoQWRhcHRlYykgU2VydmVSQUlECiNkZXZpY2UJCW1s eQkJIyBNeWxleCBBY2NlbGVSQUlEL2VYdHJlbWVSQUlECiNkZXZpY2UJCXR3YQkJIyAzd2FyZSA5 MDAwIHNlcmllcyBQQVRBL1NBVEEgUkFJRAoKIyBSQUlEIGNvbnRyb2xsZXJzCiNkZXZpY2UJCWFh YwkJIyBBZGFwdGVjIEZTQSBSQUlECiNkZXZpY2UJCWFhY3AJCSMgU0NTSSBwYXNzdGhyb3VnaCBm b3IgYWFjIChyZXF1aXJlcyBDQU0pCiNkZXZpY2UJCWlkYQkJIyBDb21wYXEgU21hcnQgUkFJRAoj ZGV2aWNlCQltZmkJCSMgTFNJIE1lZ2FSQUlEIFNBUwojZGV2aWNlCQltbHgJCSMgTXlsZXggREFD OTYwIGZhbWlseQojWFhYIHBvaW50ZXIvaW50IHdhcm5pbmdzCiNkZXZpY2UJCXBzdAkJIyBQcm9t aXNlIFN1cGVydHJhayBTWDYwMDAKI2RldmljZQkJdHdlCQkjIDN3YXJlIEFUQSBSQUlECgojIGF0 a2JkYzAgY29udHJvbHMgYm90aCB0aGUga2V5Ym9hcmQgYW5kIHRoZSBQUy8yIG1vdXNlCmRldmlj ZQkJYXRrYmRjCQkjIEFUIGtleWJvYXJkIGNvbnRyb2xsZXIKZGV2aWNlCQlhdGtiZAkJIyBBVCBr ZXlib2FyZApkZXZpY2UJCXBzbQkJIyBQUy8yIG1vdXNlCgpkZXZpY2UJCWtiZG11eAkJIyBrZXli b2FyZCBtdWx0aXBsZXhlcgoKZGV2aWNlCQl2Z2EJCSMgVkdBIHZpZGVvIGNhcmQgZHJpdmVyCgpk ZXZpY2UJCXNwbGFzaAkJIyBTcGxhc2ggc2NyZWVuIGFuZCBzY3JlZW4gc2F2ZXIgc3VwcG9ydAoK IyBzeXNjb25zIGlzIHRoZSBkZWZhdWx0IGNvbnNvbGUgZHJpdmVyLCByZXNlbWJsaW5nIGFuIFND TyBjb25zb2xlCmRldmljZQkJc2MKCmRldmljZQkJYWdwCQkjIHN1cHBvcnQgc2V2ZXJhbCBBR1Ag Y2hpcHNldHMKCiMgUENDQVJEIChQQ01DSUEpIHN1cHBvcnQKIyBQQ01DSUEgYW5kIGNhcmRidXMg YnJpZGdlIHN1cHBvcnQKI2RldmljZQkJY2JiCQkjIGNhcmRidXMgKHllbnRhKSBicmlkZ2UKI2Rl dmljZQkJcGNjYXJkCQkjIFBDIENhcmQgKDE2LWJpdCkgYnVzCiNkZXZpY2UJCWNhcmRidXMJCSMg Q2FyZEJ1cyAoMzItYml0KSBidXMKCiMgU2VyaWFsIChDT00pIHBvcnRzCmRldmljZQkJc2lvCQkj IDgyNTAsIDE2WzQ1XTUwIGJhc2VkIHNlcmlhbCBwb3J0cwpkZXZpY2UJCXVhcnQJCSMgR2VuZXJp YyBVQVJUIGRyaXZlcgoKIyBQYXJhbGxlbCBwb3J0CmRldmljZQkJcHBjCmRldmljZQkJcHBidXMJ CSMgUGFyYWxsZWwgcG9ydCBidXMgKHJlcXVpcmVkKQpkZXZpY2UJCWxwdAkJIyBQcmludGVyCmRl dmljZQkJcGxpcAkJIyBUQ1AvSVAgb3ZlciBwYXJhbGxlbApkZXZpY2UJCXBwaQkJIyBQYXJhbGxl bCBwb3J0IGludGVyZmFjZSBkZXZpY2UKI2RldmljZQkJdnBvCQkjIFJlcXVpcmVzIHNjYnVzIGFu ZCBkYQoKIyBJZiB5b3UndmUgZ290IGEgImR1bWIiIHNlcmlhbCBvciBwYXJhbGxlbCBQQ0kgY2Fy ZCB0aGF0IGlzCiMgc3VwcG9ydGVkIGJ5IHRoZSBwdWMoNCkgZ2x1ZSBkcml2ZXIsIHVuY29tbWVu dCB0aGUgZm9sbG93aW5nCiMgbGluZSB0byBlbmFibGUgaXQgKGNvbm5lY3RzIHRvIHNpbywgdWFy dCBhbmQvb3IgcHBjIGRyaXZlcnMpOgojZGV2aWNlCQlwdWMKCiMgUENJIEV0aGVybmV0IE5JQ3Mu CiNkZXZpY2UJCWRlCQkjIERFQy9JbnRlbCBEQzIxeDR4IChgYFR1bGlwJycpCiNkZXZpY2UJCWVt CQkjIEludGVsIFBSTy8xMDAwIEdpZ2FiaXQgRXRoZXJuZXQgRmFtaWx5CiNkZXZpY2UJCWlnYgkJ IyBJbnRlbCBQUk8vMTAwMCBQQ0lFIFNlcnZlciBHaWdhYml0IEZhbWlseQojZGV2aWNlCQlpeGdi CQkjIEludGVsIFBSTy8xMEdiRSBFdGhlcm5ldCBDYXJkCiNkZXZpY2UJCWxlCQkjIEFNRCBBbTc5 MDAgTEFOQ0UgYW5kIEFtNzlDOXh4IFBDbmV0CiNkZXZpY2UJCXR4cAkJIyAzQ29tIDNjUjk5MCAo YGBUeXBob29uJycpCiNkZXZpY2UJCXZ4CQkjIDNDb20gM2M1OTAsIDNjNTk1IChgYFZvcnRleCcn KQoKIyBQQ0kgRXRoZXJuZXQgTklDcyB0aGF0IHVzZSB0aGUgY29tbW9uIE1JSSBidXMgY29udHJv bGxlciBjb2RlLgojIE5PVEU6IEJlIHN1cmUgdG8ga2VlcCB0aGUgJ2RldmljZSBtaWlidXMnIGxp bmUgaW4gb3JkZXIgdG8gdXNlIHRoZXNlIE5JQ3MhCmRldmljZQkJbWlpYnVzCQkjIE1JSSBidXMg c3VwcG9ydAojZGV2aWNlCQlhZ2UJCSMgQXR0YW5zaWMvQXRoZXJvcyBMMSBHaWdhYml0IEV0aGVy bmV0CiNkZXZpY2UJCWJjZQkJIyBCcm9hZGNvbSBCQ001NzA2L0JDTTU3MDggR2lnYWJpdCBFdGhl cm5ldAojZGV2aWNlCQliZmUJCSMgQnJvYWRjb20gQkNNNDQweCAxMC8xMDAgRXRoZXJuZXQKI2Rl dmljZQkJYmdlCQkjIEJyb2FkY29tIEJDTTU3MHh4IEdpZ2FiaXQgRXRoZXJuZXQKI2RldmljZQkJ ZGMJCSMgREVDL0ludGVsIDIxMTQzIGFuZCB2YXJpb3VzIHdvcmthbGlrZXMKI2RldmljZQkJZXQJ CSMgQWdlcmUgRVQxMzEwIDEwLzEwMC9HaWdhYml0IEV0aGVybmV0CiNkZXZpY2UJCWZ4cAkJIyBJ bnRlbCBFdGhlckV4cHJlc3MgUFJPLzEwMEIgKDgyNTU3LCA4MjU1OCkKI2RldmljZQkJam1lCQkj IEpNaWNyb24gSk1DMjUwIEdpZ2FiaXQvSk1DMjYwIEZhc3QgRXRoZXJuZXQKI2RldmljZQkJbGdl CQkjIExldmVsIDEgTFhUMTAwMSBnaWdhYml0IEV0aGVybmV0CmRldmljZQkJbXNrCQkjIE1hcnZl bGwvU3lzS29ubmVjdCBZdWtvbiBJSSBHaWdhYml0IEV0aGVybmV0CiNkZXZpY2UJCW5mZQkJIyBu VmlkaWEgbkZvcmNlIE1DUCBvbi1ib2FyZCBFdGhlcm5ldAojZGV2aWNlCQluZ2UJCSMgTmF0U2Vt aSBEUDgzODIwIGdpZ2FiaXQgRXRoZXJuZXQKI2RldmljZQkJbnZlCQkjIG5WaWRpYSBuRm9yY2Ug TUNQIG9uLWJvYXJkIEV0aGVybmV0IE5ldHdvcmtpbmcKI2RldmljZQkJcGNuCQkjIEFNRCBBbTc5 Qzk3eCBQQ0kgMTAvMTAwIChwcmVjZWRlbmNlIG92ZXIgJ2xlJykKI2RldmljZQkJcmUJCSMgUmVh bFRlayA4MTM5QysvODE2OS84MTY5Uy84MTEwUwojZGV2aWNlCQlybAkJIyBSZWFsVGVrIDgxMjkv ODEzOQojZGV2aWNlCQlzZgkJIyBBZGFwdGVjIEFJQy02OTE1IChgYFN0YXJmaXJlJycpCiNkZXZp Y2UJCXNpcwkJIyBTaWxpY29uIEludGVncmF0ZWQgU3lzdGVtcyBTaVMgOTAwL1NpUyA3MDE2CmRl dmljZQkJc2sJCSMgU3lzS29ubmVjdCBTSy05ODR4ICYgU0stOTgyeCBnaWdhYml0IEV0aGVybmV0 CiNkZXZpY2UJCXN0ZQkJIyBTdW5kYW5jZSBTVDIwMSAoRC1MaW5rIERGRS01NTBUWCkKI2Rldmlj ZQkJdGkJCSMgQWx0ZW9uIE5ldHdvcmtzIFRpZ29uIEkvSUkgZ2lnYWJpdCBFdGhlcm5ldAojZGV2 aWNlCQl0bAkJIyBUZXhhcyBJbnN0cnVtZW50cyBUaHVuZGVyTEFOCiNkZXZpY2UJCXR4CQkjIFNN QyBFdGhlclBvd2VyIElJICg4M2MxNzAgYGBFUElDJycpCiNkZXZpY2UJCXZnZQkJIyBWSUEgVlQ2 MTJ4IGdpZ2FiaXQgRXRoZXJuZXQKI2RldmljZQkJdnIJCSMgVklBIFJoaW5lLCBSaGluZSBJSQoj ZGV2aWNlCQl3YgkJIyBXaW5ib25kIFc4OUM4NDBGCiNkZXZpY2UJCXhsCQkjIDNDb20gM2M5MHgg KGBgQm9vbWVyYW5nJycsIGBgQ3ljbG9uZScnKQoKIyBJU0EgRXRoZXJuZXQgTklDcy4gIHBjY2Fy ZCBOSUNzIGluY2x1ZGVkLgojZGV2aWNlCQljcwkJIyBDcnlzdGFsIFNlbWljb25kdWN0b3IgQ1M4 OXgwIE5JQwojICdkZXZpY2UgZWQnIHJlcXVpcmVzICdkZXZpY2UgbWlpYnVzJwojZGV2aWNlCQll ZAkJIyBORVsxMl0wMDAsIFNNQyBVbHRyYSwgM2M1MDMsIERTODM5MCBjYXJkcwojZGV2aWNlCQll eAkJIyBJbnRlbCBFdGhlckV4cHJlc3MgUHJvLzEwIGFuZCBQcm8vMTArCiNkZXZpY2UJCWVwCQkj IEV0aGVybGluayBJSUkgYmFzZWQgY2FyZHMKI2RldmljZQkJZmUJCSMgRnVqaXRzdSBNQjg2OTZ4 IGJhc2VkIGNhcmRzCiNkZXZpY2UJCXNuCQkjIFNNQydzIDkwMDAgc2VyaWVzIG9mIEV0aGVybmV0 IGNoaXBzCiNkZXZpY2UJCXhlCQkjIFhpcmNvbSBwY2NhcmQgRXRoZXJuZXQKCiMgV2lyZWxlc3Mg TklDIGNhcmRzCiNkZXZpY2UJCXdsYW4JCSMgODAyLjExIHN1cHBvcnQKI2RldmljZQkJd2xhbl93 ZXAJIyA4MDIuMTEgV0VQIHN1cHBvcnQKI2RldmljZQkJd2xhbl9jY21wCSMgODAyLjExIENDTVAg c3VwcG9ydAojZGV2aWNlCQl3bGFuX3RraXAJIyA4MDIuMTEgVEtJUCBzdXBwb3J0CiNkZXZpY2UJ CXdsYW5fYW1ycgkjIEFNUlIgdHJhbnNtaXQgcmF0ZSBjb250cm9sIGFsZ29yaXRobQojZGV2aWNl CQl3bGFuX3NjYW5fYXAJIyA4MDIuMTEgQVAgbW9kZSBzY2FubmluZwojZGV2aWNlCQl3bGFuX3Nj YW5fc3RhCSMgODAyLjExIFNUQSBtb2RlIHNjYW5uaW5nCiNkZXZpY2UJCWFuCQkjIEFpcm9uZXQg NDUwMC80ODAwIDgwMi4xMSB3aXJlbGVzcyBOSUNzLgojZGV2aWNlCQlhdGgJCSMgQXRoZXJvcyBw Y2kvY2FyZGJ1cyBOSUMncwojZGV2aWNlCQlhdGhfaGFsCQkjIEF0aGVyb3MgSEFMIChIYXJkd2Fy ZSBBY2Nlc3MgTGF5ZXIpCiNkZXZpY2UJCWF0aF9yYXRlX3NhbXBsZQkjIFNhbXBsZVJhdGUgdHgg cmF0ZSBjb250cm9sIGZvciBhdGgKI2RldmljZQkJYXdpCQkjIEJheVN0YWNrIDY2MCBhbmQgb3Ro ZXJzCiNkZXZpY2UJCXJhbAkJIyBSYWxpbmsgVGVjaG5vbG9neSBSVDI1MDAgd2lyZWxlc3MgTklD cy4KI2RldmljZQkJd2kJCSMgV2F2ZUxBTi9JbnRlcnNpbC9TeW1ib2wgODAyLjExIHdpcmVsZXNz IE5JQ3MuCgojIFBzZXVkbyBkZXZpY2VzLgpkZXZpY2UJCWxvb3AJCSMgTmV0d29yayBsb29wYmFj awpkZXZpY2UJCXJhbmRvbQkJIyBFbnRyb3B5IGRldmljZQpkZXZpY2UJCWV0aGVyCQkjIEV0aGVy bmV0IHN1cHBvcnQKZGV2aWNlCQlzbAkJIyBLZXJuZWwgU0xJUAojZGV2aWNlCQlwcHAJCSMgS2Vy bmVsIFBQUApkZXZpY2UJCXR1bgkJIyBQYWNrZXQgdHVubmVsLgpkZXZpY2UJCXB0eQkJIyBQc2V1 ZG8tdHR5cyAodGVsbmV0IGV0YykKZGV2aWNlCQltZAkJIyBNZW1vcnkgImRpc2tzIgpkZXZpY2UJ CWdpZgkJIyBJUHY2IGFuZCBJUHY0IHR1bm5lbGluZwpkZXZpY2UJCWZhaXRoCQkjIElQdjYtdG8t SVB2NCByZWxheWluZyAodHJhbnNsYXRpb24pCmRldmljZQkJZmlybXdhcmUJIyBmaXJtd2FyZSBh c3Npc3QgbW9kdWxlCgojIFRoZSBgYnBmJyBkZXZpY2UgZW5hYmxlcyB0aGUgQmVya2VsZXkgUGFj a2V0IEZpbHRlci4KIyBCZSBhd2FyZSBvZiB0aGUgYWRtaW5pc3RyYXRpdmUgY29uc2VxdWVuY2Vz IG9mIGVuYWJsaW5nIHRoaXMhCiMgTm90ZSB0aGF0ICdicGYnIGlzIHJlcXVpcmVkIGZvciBESENQ LgpkZXZpY2UJCWJwZgkJIyBCZXJrZWxleSBwYWNrZXQgZmlsdGVyCgojIFVTQiBzdXBwb3J0CmRl dmljZQkJdWhjaQkJIyBVSENJIFBDSS0+VVNCIGludGVyZmFjZQpkZXZpY2UJCW9oY2kJCSMgT0hD SSBQQ0ktPlVTQiBpbnRlcmZhY2UKZGV2aWNlCQllaGNpCQkjIEVIQ0kgUENJLT5VU0IgaW50ZXJm YWNlIChVU0IgMi4wKQpkZXZpY2UJCXVzYgkJIyBVU0IgQnVzIChyZXF1aXJlZCkKI2RldmljZQkJ dWRicAkJIyBVU0IgRG91YmxlIEJ1bGsgUGlwZSBkZXZpY2VzCmRldmljZQkJdWdlbgkJIyBHZW5l cmljCmRldmljZQkJdWhpZAkJIyAiSHVtYW4gSW50ZXJmYWNlIERldmljZXMiCmRldmljZQkJdWti ZAkJIyBLZXlib2FyZApkZXZpY2UJCXVscHQJCSMgUHJpbnRlcgpkZXZpY2UJCXVtYXNzCQkjIERp c2tzL01hc3Mgc3RvcmFnZSAtIFJlcXVpcmVzIHNjYnVzIGFuZCBkYQpkZXZpY2UJCXVtcwkJIyBN b3VzZQojZGV2aWNlCQl1cmFsCQkjIFJhbGluayBUZWNobm9sb2d5IFJUMjUwMFVTQiB3aXJlbGVz cyBOSUNzCiNkZXZpY2UJCXVyaW8JCSMgRGlhbW9uZCBSaW8gNTAwIE1QMyBwbGF5ZXIKZGV2aWNl CQl1c2Nhbm5lcgkjIFNjYW5uZXJzCiMgVVNCIFNlcmlhbCBkZXZpY2VzCmRldmljZQkJdWNvbQkJ IyBHZW5lcmljIGNvbSB0dHlzCiNkZXZpY2UJCXVhcmsJCSMgVGVjaG5vbG9naWVzIEFSSzMxMTYg YmFzZWQgc2VyaWFsIGFkYXB0ZXJzCiNkZXZpY2UJCXVic2EJCSMgQmVsa2luIEY1VTEwMyBhbmQg Y29tcGF0aWJsZSBzZXJpYWwgYWRhcHRlcnMKI2RldmljZQkJdWJzZXIJCSMgQldDVCBjb25zb2xl IHNlcmlhbCBhZGFwdGVycwojZGV2aWNlCQl1ZnRkaQkJIyBGb3IgRlRESSB1c2Igc2VyaWFsIGFk YXB0ZXJzCiNkZXZpY2UJCXVpcGFxCQkjIFNvbWUgV2luQ0UgYmFzZWQgZGV2aWNlcwojZGV2aWNl CQl1cGxjb20JCSMgUHJvbGlmaWMgUEwtMjMwMyBzZXJpYWwgYWRhcHRlcnMKI2RldmljZQkJdXNs Y29tCQkjIFNJIExhYnMgQ1AyMTAxL0NQMjEwMiBzZXJpYWwgYWRhcHRlcnMKI2RldmljZQkJdXZp c29yCQkjIFZpc29yIGFuZCBQYWxtIGRldmljZXMKI2RldmljZQkJdXZzY29tCQkjIFVTQiBzZXJp YWwgc3VwcG9ydCBmb3IgRERJIHBvY2tldCdzIFBIUwojIFVTQiBFdGhlcm5ldCwgcmVxdWlyZXMg bWlpYnVzCiNkZXZpY2UJCWF1ZQkJIyBBRE10ZWsgVVNCIEV0aGVybmV0CiNkZXZpY2UJCWF4ZQkJ IyBBU0lYIEVsZWN0cm9uaWNzIFVTQiBFdGhlcm5ldAojZGV2aWNlCQljZGNlCQkjIEdlbmVyaWMg VVNCIG92ZXIgRXRoZXJuZXQKI2RldmljZQkJY3VlCQkjIENBVEMgVVNCIEV0aGVybmV0CiNkZXZp Y2UJCWt1ZQkJIyBLYXdhc2FraSBMU0kgVVNCIEV0aGVybmV0CiNkZXZpY2UJCXJ1ZQkJIyBSZWFs VGVrIFJUTDgxNTAgVVNCIEV0aGVybmV0CgojIEZpcmVXaXJlIHN1cHBvcnQKZGV2aWNlCQlmaXJl d2lyZQkjIEZpcmVXaXJlIGJ1cyBjb2RlCmRldmljZQkJc2JwCQkjIFNDU0kgb3ZlciBGaXJlV2ly ZSAoUmVxdWlyZXMgc2NidXMgYW5kIGRhKQpkZXZpY2UJCWZ3ZQkJIyBFdGhlcm5ldCBvdmVyIEZp cmVXaXJlIChub24tc3RhbmRhcmQhKQpkZXZpY2UJCWZ3aXAJCSMgSVAgb3ZlciBGaXJlV2lyZSAo UkZDIDI3MzQsMzE0NikKZGV2aWNlCQlkY29ucwkJIyBEdW1iIGNvbnNvbGUgZHJpdmVyCmRldmlj ZQkJZGNvbnNfY3JvbQkjIENvbmZpZ3VyYXRpb24gUk9NIGZvciBkY29ucwoKZGV2aWNlICAgICAg ICAgIHNvdW5kCmRldmljZQkJc25kX2hkYQoKZGV2aWNlCQljb3JldGVtcApkZXZpY2UJCWF0YXBp Y2FtCm9wdGlvbnMJCVZGU19BSU8Kb3B0aW9ucwkJU0NfRElTQUJMRV9SRUJPT1QgIyBDdHJsLUFs dC1EZWwKb3B0aW9ucwkJSVBGSVJFV0FMTApvcHRpb25zIAlJUEZJUkVXQUxMX1ZFUkJPU0UKb3B0 aW9ucyAJSVBGSVJFV0FMTF9WRVJCT1NFX0xJTUlUPTEwCm9wdGlvbnMgCUlQU1RFQUxUSApkZXZp Y2UJCWNwdWN0bApkZXZpY2UJCWFjcGlfYWlib29zdApvcHRpb25zCQlNQUMKb3B0aW9ucwkJTUFD X0JTREVYVEVOREVECgo= --00163641759b7fc68c046e58f5d0-- From owner-freebsd-stable@FreeBSD.ORG Fri Jul 10 12:32:08 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 517FB106564A for ; Fri, 10 Jul 2009 12:32:08 +0000 (UTC) (envelope-from hlh@restart.be) Received: from tignes.restart.be (tignes.restart.be [IPv6:2001:41d0:2:2d29:0:1::]) by mx1.freebsd.org (Postfix) with ESMTP id D60E08FC1A; Fri, 10 Jul 2009 12:32:07 +0000 (UTC) (envelope-from hlh@restart.be) Received: from restart.be (avoriaz.tunnel.bel [IPv6:2001:41d0:2:2d29:1:ffff::]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "avoriaz.restart.be", Issuer "CA master" (verified OK)) by tignes.restart.be (Postfix) with ESMTPS id 2E6D94D3C; Fri, 10 Jul 2009 14:32:07 +0200 (CEST) Received: from morzine.restart.bel (morzine.restart.be [IPv6:2001:41d0:2:2d29:1:2::]) (authenticated bits=0) by restart.be (8.14.3/8.14.3) with ESMTP id n6ACW3pK055253; Fri, 10 Jul 2009 14:32:03 +0200 (CEST) (envelope-from hlh@restart.be) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=restart.be; s=avoriaz; t=1247229126; bh=ynWlcHTMgLkGhZcs/xWgOh4gJTwVT4EFsQqlWq+SLXM=; h=Message-ID:Date:From:MIME-Version:To:Subject:Content-Type: Content-Transfer-Encoding; b=VtDtprSArc+BGQcwRznBRhT5yH+xLrTxd6RtL/M9N4813UxW0HASKPEbpAqZcBZW7 I3ckuOy8LOrMeCIcBz/SA== DomainKey-Signature: a=rsa-sha1; s=avoriaz; d=restart.be; c=nofws; q=dns; h=message-id:date:from:organization:user-agent:mime-version:to: subject:content-type:content-transfer-encoding:x-scanned-by; b=CSRxbeTCecuXE7zCvkpPuYiENX9HFn1EbHTNkU5H4AzQAGHd6XA6KnhAEtka5PT67 EZtBvR+xQAhilf01f15Gg== Message-ID: <4A5734C3.3000806@restart.be> Date: Fri, 10 Jul 2009 14:32:03 +0200 From: Henri Hennebert Organization: RestartSoft User-Agent: Thunderbird 2.0.0.22 (X11/20090627) MIME-Version: 1.0 To: freebsd-stable@freebsd.org, freebsd-st@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.64 on IPv6:2001:41d0:2:2d29:1:1:: Cc: Subject: 8.0-BETA1 - for the record - different paths followed by IPv4 and IPv6 for 'local' connections X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2009 12:32:08 -0000 Hello, After upgrading from 7.2-STABLE to 8.0-BETA1 I encounter a problem when connecting with firefox to a local apache server using the global unicast IPv6 address of the local machine. pf.conf must be updated! My configuration: [root@avoriaz ~]# ifconfig em0 em0: flags=8843 metric 0 mtu 1500 options=19b ether 00:1d:60:ad:2a:ce inet 192.168.24.1 netmask 0xffffff00 broadcast 192.168.24.255 inet6 fe80::21d:60ff:fead:2ace%em0 prefixlen 64 scopeid 0x1 inet6 2001:41d0:2:2d29:1:1:: prefixlen 80 media: Ethernet 100baseTX (100baseTX ) status: active [root@avoriaz ~]# host www.restart.bel www.restart.bel is an alias for avoriaz.restart.bel. avoriaz.restart.bel has address 192.168.24.1 avoriaz.restart.bel has IPv6 address 2001:41d0:2:2d29:1:1:: pf.conf: int_if="em0" block in log all block out log all set skip on lo0 antispoof quick for $int_if inet # Allow trafic with physical internal network pass in quick on $int_if from ($int_if:network) to ($int_if) keep state pass out quick on $int_if from ($int_if) to ($int_if:network) keep state The problem: [root@avoriaz ~]# telnet -4 www.restart.bel 80 Trying 192.168.24.1... Connected to avoriaz.restart.bel. Escape character is '^]'. ^] telnet> quit Connection closed. [root@avoriaz ~]# telnet -6 www.restart.bel 80 Trying 2001:41d0:2:2d29:1:1::... --->Never connect and get a timeout! tcpdump and logging in pf show me that For a IPv4 connection: the packet from telnet to apache pass 2 times on lo0 (out and in) the answer packet from apache to telnet pass 2 times on lo0 (out and in) So no problem, there is `set skip on lo0' For a IPv6 connection: The first packet from telnet to apache pass 2 times on lo0 (out and in) The answer packet from apache to telnet path on em0 and is rejected due to the default flags S/SA. So I have to change pf.conf and replace the last line: pass out quick on $int_if from ($int_if) to ($int_if:network) \ keep state flags any Then all is OK By the way, on 7.2 netstat -rn display 192.168.24.1 00:1d:60:ad:2a:ce .... 2001:41d0:2:2d29:1:1:: 00:1d:60:ad:2a:ce On 8.0-BETA1 there is an assymetry: netstat -rn display 192.168.24.1 link#3 .... no entry for 2001:41d0:2:2d29:1:1:: Hope it may help someone Henri From owner-freebsd-stable@FreeBSD.ORG Fri Jul 10 12:35:33 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C71F3106566C; Fri, 10 Jul 2009 12:35:33 +0000 (UTC) (envelope-from hlh@restart.be) Received: from tignes.restart.be (tignes.restart.be [IPv6:2001:41d0:2:2d29:0:1::]) by mx1.freebsd.org (Postfix) with ESMTP id 7F2BC8FC19; Fri, 10 Jul 2009 12:35:33 +0000 (UTC) (envelope-from hlh@restart.be) Received: from restart.be (avoriaz.tunnel.bel [IPv6:2001:41d0:2:2d29:1:ffff::]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "avoriaz.restart.be", Issuer "CA master" (verified OK)) by tignes.restart.be (Postfix) with ESMTPS id CCB084D53; Fri, 10 Jul 2009 14:35:32 +0200 (CEST) Received: from morzine.restart.bel (morzine.restart.be [IPv6:2001:41d0:2:2d29:1:2::]) (authenticated bits=0) by restart.be (8.14.3/8.14.3) with ESMTP id n6ACZTK8055297; Fri, 10 Jul 2009 14:35:29 +0200 (CEST) (envelope-from hlh@restart.be) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=restart.be; s=avoriaz; t=1247229332; bh=yPMyJBmWtRvc4He6EP6dBDK6HLp9l9++4rz067/EBaY=; h=Message-ID:Date:From:MIME-Version:To:Subject:Content-Type: Content-Transfer-Encoding; b=LTr+3h4OW9aPvIKpMip8CtXMqRCaXOv+S0okutnJ0/Zwc1dBjw0Ps31Y6lNGbK4/D InMIHj9MNnX26Pmd716dA== DomainKey-Signature: a=rsa-sha1; s=avoriaz; d=restart.be; c=nofws; q=dns; h=message-id:date:from:organization:user-agent:mime-version:to: subject:content-type:content-transfer-encoding:x-scanned-by; b=lRJOv3pdq14gPH9pRCYEUX7T9ZHIGlBgMBJCfno0utNdb7s4vH13fQbN960S92thO yyUHYH9M8r/CGtsoBLNyw== Message-ID: <4A573591.1000506@restart.be> Date: Fri, 10 Jul 2009 14:35:29 +0200 From: Henri Hennebert Organization: RestartSoft User-Agent: Thunderbird 2.0.0.22 (X11/20090627) MIME-Version: 1.0 To: freebsd-stable@freebsd.org, freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.64 on IPv6:2001:41d0:2:2d29:1:1:: Cc: Subject: 8.0-BETA1 - for the record - different paths followed by IPv4 and IPv6 for 'local' connections X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2009 12:35:34 -0000 Hello, After upgrading from 7.2-STABLE to 8.0-BETA1 I encounter a problem when connecting with firefox to a local apache server using the global unicast IPv6 address of the local machine. pf.conf must be updated! My configuration: [root@avoriaz ~]# ifconfig em0 em0: flags=8843 metric 0 mtu 1500 options=19b ether 00:1d:60:ad:2a:ce inet 192.168.24.1 netmask 0xffffff00 broadcast 192.168.24.255 inet6 fe80::21d:60ff:fead:2ace%em0 prefixlen 64 scopeid 0x1 inet6 2001:41d0:2:2d29:1:1:: prefixlen 80 media: Ethernet 100baseTX (100baseTX ) status: active [root@avoriaz ~]# host www.restart.bel www.restart.bel is an alias for avoriaz.restart.bel. avoriaz.restart.bel has address 192.168.24.1 avoriaz.restart.bel has IPv6 address 2001:41d0:2:2d29:1:1:: pf.conf: int_if="em0" block in log all block out log all set skip on lo0 antispoof quick for $int_if inet # Allow trafic with physical internal network pass in quick on $int_if from ($int_if:network) to ($int_if) keep state pass out quick on $int_if from ($int_if) to ($int_if:network) keep state The problem: [root@avoriaz ~]# telnet -4 www.restart.bel 80 Trying 192.168.24.1... Connected to avoriaz.restart.bel. Escape character is '^]'. ^] telnet> quit Connection closed. [root@avoriaz ~]# telnet -6 www.restart.bel 80 Trying 2001:41d0:2:2d29:1:1::... --->Never connect and get a timeout! tcpdump and logging in pf show me that For a IPv4 connection: the packet from telnet to apache pass 2 times on lo0 (out and in) the answer packet from apache to telnet pass 2 times on lo0 (out and in) So no problem, there is `set skip on lo0' For a IPv6 connection: The first packet from telnet to apache pass 2 times on lo0 (out and in) The answer packet from apache to telnet path on em0 and is rejected due to the default flags S/SA. So I have to change pf.conf and replace the last line: pass out quick on $int_if from ($int_if) to ($int_if:network) \ keep state flags any Then all is OK By the way, on 7.2 netstat -rn display 192.168.24.1 00:1d:60:ad:2a:ce .... 2001:41d0:2:2d29:1:1:: 00:1d:60:ad:2a:ce On 8.0-BETA1 there is an assymetry: netstat -rn display 192.168.24.1 link#3 .... no entry for 2001:41d0:2:2d29:1:1:: Hope it may help someone Henri From owner-freebsd-stable@FreeBSD.ORG Fri Jul 10 13:54:18 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0926C106564A for ; Fri, 10 Jul 2009 13:54:18 +0000 (UTC) (envelope-from thomas@ronner.org) Received: from mail.knopje.net (mail.knopje.net [213.214.107.232]) by mx1.freebsd.org (Postfix) with ESMTP id C0D3A8FC1A for ; Fri, 10 Jul 2009 13:54:17 +0000 (UTC) (envelope-from thomas@ronner.org) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.knopje.net (Postfix) with ESMTP id 4BC8138129; Fri, 10 Jul 2009 15:54:16 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at knopje.net Received: from mail.knopje.net ([127.0.0.1]) by localhost (hal.knopje.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cB55QrY+5nW7; Fri, 10 Jul 2009 15:54:15 +0200 (CEST) Received: from [192.168.28.106] (48-251.surfsnel.dsl.internl.net [145.99.251.48]) by mail.knopje.net (Postfix) with ESMTP id B2FDC380FB; Fri, 10 Jul 2009 15:54:15 +0200 (CEST) From: Thomas Ronner To: Andriy Gapon In-Reply-To: <4A572F8E.6040004@icyb.net.ua> References: <1247085058.6197.18.camel@bugstore> <4A55F96B.6070303@icyb.net.ua> <4A560E2F.1050906@ronner.org> <4A5626FC.5000306@ronner.org> <4A562A4A.2000201@icyb.net.ua> <4A563627.7040407@ronner.org> <4A572F8E.6040004@icyb.net.ua> Content-Type: text/plain Date: Fri, 10 Jul 2009 15:54:15 +0200 Message-Id: <1247234055.5197.0.camel@bugstore> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: ZFS: zpool scrub lockup X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2009 13:54:18 -0000 On Fri, 2009-07-10 at 15:09 +0300, Andriy Gapon wrote: > on 09/07/2009 21:25 Thomas Ronner said the following: > > Is this: > > http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug-online-gdb.html > > (10.6 On-Line Kernel Debugging Using Remote GDB) the debugging via > > serial console you're referring to? > > Yes. > Thanks. I'll try that in a couple of weeks when I return from vacation. Thomas From owner-freebsd-stable@FreeBSD.ORG Fri Jul 10 15:01:25 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0E9F4106566C; Fri, 10 Jul 2009 15:01:25 +0000 (UTC) (envelope-from oliver.pntr@gmail.com) Received: from mail-fx0-f224.google.com (mail-fx0-f224.google.com [209.85.220.224]) by mx1.freebsd.org (Postfix) with ESMTP id 604738FC16; Fri, 10 Jul 2009 15:01:24 +0000 (UTC) (envelope-from oliver.pntr@gmail.com) Received: by fxm24 with SMTP id 24so770729fxm.43 for ; Fri, 10 Jul 2009 08:01:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=UpKyNJjoydptUIbswU7O0mDi/KiFklPvnpzEif5FkOM=; b=ZpuuSRfsNgOkUJfJomFPa0NUiMNhh7X3kZx2XkhXy2JCxiQGro8Bof+bUpfcM18aWa mihrcK1TPI0pUJkBr1RsJDSaabc/v57ZhQFJT6Jl/hKq89EQnB5agbo1iIrrglY5H5cE k+N+JR89lLmxQWbWGj5Iaqt2MFJgwX5vkEsjA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=reO1EEpbzebT0h1ESHrgzvExz4d7VKVwrY2vAthijGySvhsN1lzIvvBQKlJDvCLTkX zEzwcRSgdUzY4qzcx84LPt/AIqTmxWh9Y/TUJFJUY7DMalHrVDEwU8jX0HmBn+jXv5dB TmjuU9+unesajGMsVN6NyTbZfqTydRX2YlYMo= MIME-Version: 1.0 Received: by 10.103.217.5 with SMTP id u5mr1147990muq.43.1247238082033; Fri, 10 Jul 2009 08:01:22 -0700 (PDT) In-Reply-To: References: <6101e8c40907091755n5aefe289r6eec14cf7f4287dc@mail.gmail.com> Date: Fri, 10 Jul 2009 17:01:21 +0200 Message-ID: <6101e8c40907100801r382ded4boddd853f771867bd0@mail.gmail.com> From: Oliver Pinter To: Robert Watson Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: smbfs panic when lost connection or unmount --force X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2009 15:01:25 -0000 Hello! Here is the bt: http://centaur.sch.bme.hu/~oliverp/freebsd/smbfs_panic/DSC01845.JPG http://centaur.sch.bme.hu/~oliverp/freebsd/smbfs_panic/DSC01846.JPG http://centaur.sch.bme.hu/~oliverp/freebsd/smbfs_panic/DSC01847.JPG steps to reproduce: 1) mount_smbfs -I server //biz@foo.bar.baz /media/biz 2) generate IO from smb (cp somewate ..) 3) under IO pull down the network cable 4) a) wait to panic b) umount -f /media/biz, and the system faster panics On 7/10/09, Robert Watson wrote: > > On Fri, 10 Jul 2009, Oliver Pinter wrote: > >> It is a kernel panic, when force unmount the smbfs volume or lost the >> connection with the samba server. > > This is a NULL pointer dereference in the kernel. Per Attilio's e-mail, a > stack trace should help us track it down. Thanks! > > Robert N M Watson > Computer Laboratory > University of Cambridge > >> >> -- >> Thes OS is: >> >> >> kern.ostype: FreeBSD >> kern.osrelease: 7.2-STABLE >> kern.osrevision: 199506 >> kern.version: FreeBSD 7.2-STABLE #4: Sat Jun 27 21:44:32 CEST 2009 >> root@oliverp:/usr/obj/usr/src/sys/stable >> kern.osreldate: 702103 >> >> -- >> make.conf: >> >> >> CPUTYPE?=core2 >> CFLAGS= -O2 -fno-strict-aliasing -pipe >> MODULES_OVERRIDE=smbfs libiconv libmchain zfs opensolaris drm cd9660 >> cd9660_iconv >> >> -- >> panic message: >> >> Jul 10 01:58:39 oliverp syslogd: kernel boot file is /boot/kernel/kernel >> Jul 10 01:58:39 oliverp kernel: kernel trap 12 with interrupts disabled >> Jul 10 01:58:39 oliverp kernel: >> Jul 10 01:58:39 oliverp kernel: >> Jul 10 01:58:39 oliverp kernel: Fatal trap 12: page fault while in kernel >> mode >> Jul 10 01:58:39 oliverp kernel: cpuid = 2; apic id = 02 >> Jul 10 01:58:39 oliverp kernel: fault virtual address = 0x30 >> Jul 10 01:58:39 oliverp kernel: fault code = supervisor read data, >> page not present >> Jul 10 01:58:39 oliverp kernel: instruction pointer = >> 0x8:0xffffffff80327fd0 >> Jul 10 01:58:39 oliverp kernel: stack pointer = >> 0x10:0xffffff8078360940 >> Jul 10 01:58:39 oliverp kernel: frame pointer = >> 0x10:0xffffff0004c31390 >> Jul 10 01:58:39 oliverp kernel: code segment = base 0x0, limit >> 0xfffff, type 0x1b >> Jul 10 01:58:39 oliverp kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 >> Jul 10 01:58:39 oliverp kernel: processor eflags = resume, IOPL = 0 >> Jul 10 01:58:39 oliverp kernel: current process = 60406 (smbiod0) >> Jul 10 01:58:39 oliverp kernel: trap number = 12 >> Jul 10 01:58:39 oliverp kernel: panic: page fault >> Jul 10 01:58:39 oliverp kernel: cpuid = 2 >> Jul 10 01:58:39 oliverp kernel: Uptime: 6h51m16s >> Jul 10 01:58:39 oliverp kernel: Physical memory: 4087 MB >> Jul 10 01:58:39 oliverp kernel: Dumping 2448 MB:Copyright (c) >> 1992-2009 The FreeBSD Project. >> _______________________________________________ >> freebsd-stable@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" >> > From owner-freebsd-stable@FreeBSD.ORG Fri Jul 10 18:20:59 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2F8101065670 for ; Fri, 10 Jul 2009 18:20:59 +0000 (UTC) (envelope-from jensrasmus@gmail.com) Received: from mail-fx0-f224.google.com (mail-fx0-f224.google.com [209.85.220.224]) by mx1.freebsd.org (Postfix) with ESMTP id A74F68FC13 for ; Fri, 10 Jul 2009 18:20:58 +0000 (UTC) (envelope-from jensrasmus@gmail.com) Received: by fxm24 with SMTP id 24so867964fxm.43 for ; Fri, 10 Jul 2009 11:20:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=cLqimPMyA+MddB24EZevZZgnVsnrplyVsFmTnOsPvjY=; b=vx6yG8nTQzZLYNwUpLfUSVQHXiU5cExzeiKoQT/YYmEofQNuE7kfQjqBU0n1izvXdw +tTBq0+SKk+6l00qofwVd8kcS/Tfxj4mDq4nB2Q08q2hA7o6e9xiIhyyudEMVJy/EwsK v4qE6k2djFu3yk8MWsJFWHH9qn54rQeOsqUFg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=uL6Hue/W7X1RXCNPkn0VziDsC1OM5h9suor+zLIypjMsxVF81HECDpOthrJsGPByE0 lfQUCIP3WjVN/bohV87HU+BGBaC0HCx7+qp4A6WZSmFgDS7bYsF9Oewjqy7/oid9S6hk tyepfwx9+qDZKPX0hhwHyMRfM97nt725LE1wg= MIME-Version: 1.0 Received: by 10.204.118.134 with SMTP id v6mr2157631bkq.31.1247248829454; Fri, 10 Jul 2009 11:00:29 -0700 (PDT) Date: Fri, 10 Jul 2009 20:00:29 +0200 Message-ID: <63e02e980907101100o5c9e0ca1uaba843be033f8869@mail.gmail.com> From: Jens Rasmus Liland To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Error when using 'portupgrade -ay'. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2009 18:20:59 -0000 Hello! I had an error just now running 'portupgrade -ay'. Got this output: ---OUTPUT START--- ---> Session started at: Fri, 10 Jul 2009 18:58:30 +0200 ** Port directory not found: x11-drivers/xf86-video-vga ** Port marked as IGNORE: x11-drivers/xf86-video-via: requires pciVideoPtr typedef ** Port directory not found: x11/xorg-protos ** Port directory not found: x11/xphelloworld ---> Skipping 'x11-drivers/xorg-drivers' (xorg-drivers-7.3_3) because a requisite package 'xf86-video-vga-4.1.0_2' (x11-drivers/xf86-video-vga) failed (specify -k to force) ---> ** Upgrade tasks 3: 0 done, 4 ignored, 1 skipped and 0 failed ---> Skipping 'x11/xorg-apps' (xorg-apps-7.3) because a requisite package 'xphelloworld-1.0.1_1' (x11/xphelloworld) failed (specify -k to force) ---> ** Upgrade tasks 3: 0 done, 4 ignored, 2 skipped and 0 failed ---> Skipping 'x11/xorg' (xorg-7.3_2) because a requisite package 'xorg-drivers-7.3_3' (x11-drivers/xorg-drivers) failed (specify -k to force) ---> ** Upgrade tasks 3: 0 done, 4 ignored, 3 skipped and 0 failed ---> Listing the results (+:done / -:ignored / *:skipped / !:failed) - x11-drivers/xf86-video-vga (port directory error) - x11-drivers/xf86-video-via (marked as IGNORE) - x11/xorg-protos (port directory error) - x11/xphelloworld (port directory error) * x11-drivers/xorg-drivers (xorg-drivers-7.3_3) * x11/xorg-apps (xorg-apps-7.3) * x11/xorg (xorg-7.3_2) ---> Packages processed: 0 done, 4 ignored, 3 skipped and 0 failed ---> Session ended at: Fri, 10 Jul 2009 18:58:46 +0200 (consumed 00:00:15) ---OUTPUT STOP--- I've never got an error like this. What am I to do to make it work correctly again? /Rasmus From owner-freebsd-stable@FreeBSD.ORG Fri Jul 10 18:40:08 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D557E1065672 for ; Fri, 10 Jul 2009 18:40:08 +0000 (UTC) (envelope-from quakelee@geekcn.org) Received: from tarsier.delphij.net (delphij-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:2c9::2]) by mx1.freebsd.org (Postfix) with ESMTP id EFAF48FC0C for ; Fri, 10 Jul 2009 18:40:07 +0000 (UTC) (envelope-from quakelee@geekcn.org) Received: from tarsier.geekcn.org (tarsier.geekcn.org [211.166.10.233]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tarsier.delphij.net (Postfix) with ESMTPS id 216105C024 for ; Sat, 11 Jul 2009 02:40:07 +0800 (CST) Received: from localhost (tarsier.geekcn.org [211.166.10.233]) by tarsier.geekcn.org (Postfix) with ESMTP id DD8C755CD558 for ; Sat, 11 Jul 2009 02:40:06 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([211.166.10.233]) by localhost (mail.geekcn.org [211.166.10.233]) (amavisd-new, port 10024) with ESMTP id 7INBONn2bQBj for ; Sat, 11 Jul 2009 02:39:07 +0800 (CST) Received: from qlmacbook.xbaynet.com (unknown [222.131.114.89]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTPSA id 51BC055CD54A for ; Sat, 11 Jul 2009 02:38:58 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=geekcn.org; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:subject: content-type:content-transfer-encoding; b=npQuj+ZvnZn1sgS+KB9iedDta894Bpx+27SDCmhmGrzWNxYn1HAp5TjaMpLLevAIO FP6+tQ6S6qRLT+pYkup8g== Message-ID: <4A578AB6.3000600@geekcn.org> Date: Sat, 11 Jul 2009 02:38:46 +0800 From: Chao Shin User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: weird sata DMA error X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2009 18:40:09 -0000 Hi all, I have a dell optiplex 755 box. I plug a second disk on it for backup logs. It always report error message like below when heavy read load. ad9: TIMEOUT - READ_DMA48 retrying (1 retry left) LBA=1511796863 ad9: TIMEOUT - READ_DMA48 retrying (0 retries left) LBA=1511796863 ad9: FAILURE - READ_DMA48 timed out LBA=1511796863 g_vfs_done():ad9s1d[READ(offset=774039961600, length=16384)]error = 5 ad9: TIMEOUT - READ_DMA48 retrying (1 retry left) LBA=1513678143 ad9: TIMEOUT - READ_DMA48 retrying (0 retries left) LBA=1513678143 ad9: FAILURE - READ_DMA48 timed out LBA=1513678143 g_vfs_done():ad9s1d[READ(offset=775003176960, length=16384)]error = 5 We had changed another disk, sata cable, box and upgrade freebsd from 7.1-RELEASE-p5 to 7.2-RELEASE. but error message still come out. I have tried smartctl to send self-test command to disk, but it didn't start test, I have no idea about that now. There is smart message and dmesg below: # smartctl -a /dev/ad9 smartctl version 5.38 [amd64-portbld-freebsd7.2] Copyright (C) 2002-8 Bruce Allen Home page is http://smartmontools.sourceforge.net/ === START OF INFORMATION SECTION === Device Model: WDC WD15EADS-00R6B0 Serial Number: WD-WCAVY0256398 Firmware Version: 01.00A01 User Capacity: 1,500,301,910,016 bytes Device is: Not in smartctl database [for details use: -P showall] ATA Version is: 8 ATA Standard is: Exact ATA specification draft version not indicated Local Time is: Thu Jul 9 13:42:22 2009 CST SMART support is: Available - device has SMART capability. SMART support is: Enabled === START OF READ SMART DATA SECTION === SMART overall-health self-assessment test result: PASSED General SMART Values: Offline data collection status: (0x85) Offline data collection activity was aborted by an interrupting command from host. Auto Offline Data Collection: Enabled. Self-test execution status: ( 249) Self-test routine in progress... 90% of test remaining. Total time to complete Offline data collection: (32400) seconds. Offline data collection capabilities: (0x7b) SMART execute Offline immediate. Auto Offline data collection on/off support. Suspend Offline collection upon new command. Offline surface scan supported. Self-test supported. Conveyance Self-test supported. Selective Self-test supported. SMART capabilities: (0x0003) Saves SMART data before entering power-saving mode. Supports SMART auto save timer. Error logging capability: (0x01) Error logging supported. General Purpose Logging supported. Short self-test routine recommended polling time: ( 2) minutes. Extended self-test routine recommended polling time: ( 255) minutes. Conveyance self-test routine recommended polling time: ( 5) minutes. SCT capabilities: (0x303f) SCT Status supported. SCT Feature Control supported. SCT Data Table supported. SMART Attributes Data Structure revision number: 16 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x002f 198 195 051 Pre-fail Always - 20340 3 Spin_Up_Time 0x0027 155 144 021 Pre-fail Always - 9250 4 Start_Stop_Count 0x0032 100 100 000 Old_age Always - 22 5 Reallocated_Sector_Ct 0x0033 193 193 140 Pre-fail Always - 52 7 Seek_Error_Rate 0x002e 200 200 000 Old_age Always - 0 9 Power_On_Hours 0x0032 099 099 000 Old_age Always - 904 10 Spin_Retry_Count 0x0032 100 253 000 Old_age Always - 0 11 Calibration_Retry_Count 0x0032 100 253 000 Old_age Always - 0 12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 20 192 Power-Off_Retract_Count 0x0032 200 200 000 Old_age Always - 4 193 Load_Cycle_Count 0x0032 200 200 000 Old_age Always - 18 194 Temperature_Celsius 0x0022 115 100 000 Old_age Always - 37 196 Reallocated_Event_Count 0x0032 149 149 000 Old_age Always - 51 197 Current_Pending_Sector 0x0032 196 195 000 Old_age Always - 1213 198 Offline_Uncorrectable 0x0030 200 196 000 Old_age Offline - 0 199 UDMA_CRC_Error_Count 0x0032 200 200 000 Old_age Always - 0 200 Multi_Zone_Error_Rate 0x0008 006 006 000 Old_age Offline - 38929 SMART Error Log Version: 1 No Errors Logged SMART Self-test log structure revision number 1 No self-tests have been logged. [To run self-tests, use: smartctl -t] SMART Selective self-test log data structure revision number 1 SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS 1 0 0 Not_testing 2 0 0 Not_testing 3 0 0 Not_testing 4 0 0 Not_testing 5 0 0 Not_testing Selective self-test flags (0x0): After scanning selected spans, do NOT read-scan remainder of disk. If Selective self-test is pending on power-up, resume after 0 minute delay. There is hardware info, Copyright (c) 1992-2009 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 7.2-RELEASE-p2 #0: Thu Jul 9 12:46:37 CST 2009 root@birdspark1.intra.umessage.com.cn:/usr/obj/usr/src/sys/BIRD Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Core(TM)2 Duo CPU E6550 @ 2.33GHz (2327.50-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x6fb Stepping = 11 Features=0xbfebfbff Features2=0xe3fd AMD Features=0x20100800 AMD Features2=0x1 Cores per package: 2 usable memory = 6287015936 (5995 MB) avail memory = 6046175232 (5766 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0: Changing APIC ID to 8 ioapic0 irqs 0-23 on motherboard lapic0: Forcing LINT1 to edge trigger kbd1 at kbdmux0 acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 900 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: irq 16 at device 1.0 on pci0 pci1: on pcib1 vgapci0: port 0xec90-0xec97 mem 0xfea00000-0xfea7ffff,0xd0000000-0xdfffffff,0xfeb00000-0xfebfffff irq 16 at device 2.0 on pci0 agp0: on vgapci0 agp0: detected 7164k stolen memory agp0: aperture size is 256M vgapci1: mem 0xfea80000-0xfeafffff at device 2.1 on pci0 pci0: at device 3.0 (no driver attached) atapci0: port 0xfe80-0xfe87,0xfe90-0xfe93,0xfea0-0xfea7,0xfeb0-0xfeb3,0xfef0-0xfeff irq 18 at device 3.2 on pci0 atapci0: [ITHREAD] ata2: on atapci0 ata2: [ITHREAD] ata3: on atapci0 ata3: [ITHREAD] pci0: at device 3.3 (no driver attached) em0: port 0xecc0-0xecdf mem 0xfe9e0000-0xfe9fffff,0xfe9db000-0xfe9dbfff irq 21 at device 25.0 on pci0 em0: Using MSI interrupt em0: [FILTER] em0: Ethernet address: 00:1a:a0:d9:35:9b uhci0: port 0xff20-0xff3f irq 16 at device 26.0 on pci0 uhci0: [GIANT-LOCKED] uhci0: [ITHREAD] usb0: on uhci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 2 ports with 2 removable, self powered uhci1: port 0xff00-0xff1f irq 17 at device 26.1 on pci0 uhci1: [GIANT-LOCKED] uhci1: [ITHREAD] usb1: on uhci1 usb1: USB revision 1.0 uhub1: on usb1 uhub1: 2 ports with 2 removable, self powered ehci0: mem 0xfe9d9c00-0xfe9d9fff irq 22 at device 26.7 on pci0 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb2: waiting for BIOS to give up control usb2: EHCI version 1.0 usb2: wrong number of companions (3 != 2) usb2: companion controllers, 2 ports each: usb0 usb1 usb2: on ehci0 usb2: USB revision 2.0 uhub2: on usb2 uhub2: 6 ports with 6 removable, self powered pci0: at device 27.0 (no driver attached) pcib2: irq 16 at device 28.0 on pci0 pci2: on pcib2 uhci2: port 0xff80-0xff9f irq 23 at device 29.0 on pci0 uhci2: [GIANT-LOCKED] uhci2: [ITHREAD] usb3: on uhci2 usb3: USB revision 1.0 uhub3: on usb3 uhub3: 2 ports with 2 removable, self powered uhci3: port 0xff60-0xff7f irq 17 at device 29.1 on pci0 uhci3: [GIANT-LOCKED] uhci3: [ITHREAD] usb4: on uhci3 usb4: USB revision 1.0 uhub4: on usb4 uhub4: 2 ports with 2 removable, self powered uhci4: port 0xff40-0xff5f irq 18 at device 29.2 on pci0 uhci4: [GIANT-LOCKED] uhci4: [ITHREAD] usb5: on uhci4 usb5: USB revision 1.0 uhub5: on usb5 uhub5: 2 ports with 2 removable, self powered ehci1: mem 0xff980800-0xff980bff irq 23 at device 29.7 on pci0 ehci1: [GIANT-LOCKED] ehci1: [ITHREAD] usb6: waiting for BIOS to give up control usb6: timed out waiting for BIOS usb6: EHCI version 1.0 usb6: companion controllers, 2 ports each: usb3 usb4 usb5 usb6: on ehci1 usb6: USB revision 2.0 uhub6: on usb6 uhub6: 6 ports with 6 removable, self powered pcib3: at device 30.0 on pci0 pci3: on pcib3 isab0: at device 31.0 on pci0 isa0: on isab0 atapci1: port 0xfe00-0xfe07,0xfe10-0xfe13,0xfe20-0xfe27,0xfe30-0xfe33,0xfec0-0xfecf,0xeca0-0xecaf irq 18 at device 31.2 on pci0 atapci1: [ITHREAD] ata4: on atapci1 ata4: [ITHREAD] ata5: on atapci1 ata5: [ITHREAD] pci0: at device 31.3 (no driver attached) atapci2: port 0xfe40-0xfe47,0xfe50-0xfe53,0xfe60-0xfe67,0xfe70-0xfe73,0xfed0-0xfedf,0xecb0-0xecbf irq 18 at device 31.5 on pci0 atapci2: [ITHREAD] ata6: on atapci2 ata6: [ITHREAD] ata7: on atapci2 ata7: [ITHREAD] sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A sio0: [FILTER] cpu0: on acpi0 est0: on cpu0 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 724072406000724 device_attach: est0 attach returned 6 p4tcc0: on cpu0 cpu1: on acpi0 est1: on cpu1 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 724072406000724 device_attach: est1 attach returned 6 p4tcc1: on cpu1 orm0: at iomem 0xc0000-0xcb7ff,0xcb800-0xcd7ff,0xcd800-0xcffff on isa0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Timecounters tick every 1.000 msec ad8: 152587MB at ata4-master SATA300 ad9: 1430799MB at ata4-slave SATA300 From owner-freebsd-stable@FreeBSD.ORG Fri Jul 10 18:50:10 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E8A541065686 for ; Fri, 10 Jul 2009 18:50:10 +0000 (UTC) (envelope-from dan.naumov@gmail.com) Received: from mail-yx0-f181.google.com (mail-yx0-f181.google.com [209.85.210.181]) by mx1.freebsd.org (Postfix) with ESMTP id A39C88FC08 for ; Fri, 10 Jul 2009 18:50:10 +0000 (UTC) (envelope-from dan.naumov@gmail.com) Received: by yxe11 with SMTP id 11so1822472yxe.3 for ; Fri, 10 Jul 2009 11:50:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=tP22NXX2Z3F2d+yGKzHJ1yacaiJ84/EbZ56MZxvv1T0=; b=vQUnlx+3l2qdZx9hcHTtnNsrQel+c6rnw27ECuCTH7y/BVJJMUKd1MpPut5ssf3cmP MxbiTsXIxIKytYDJ9Dwvo0vsxkIzIUVSzyG/nj39EejQp501Oa9l3AmveQE8iGWXiCqF F6IWMPnnlEp3u55qkkHCF136DXZL9Hro8eXN8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=wV0XMXb0hGeIhgl49Ak8TjmOExmlyHBAXsvUxiDc2c5en7jdpq3jBOqEy0dipDH9t6 EYej/BthlHzq/blH+UgnLirUshu7JaaTNc7LgTfSm4iSDDpOsdAHmSUQswvoZ4Xuu0oo t0kyA5EoA003SKkgB+UedWK1kMaO6mHrhsd2c= MIME-Version: 1.0 Received: by 10.100.14.16 with SMTP id 16mr3017588ann.128.1247251810102; Fri, 10 Jul 2009 11:50:10 -0700 (PDT) In-Reply-To: <63e02e980907101100o5c9e0ca1uaba843be033f8869@mail.gmail.com> References: <63e02e980907101100o5c9e0ca1uaba843be033f8869@mail.gmail.com> Date: Fri, 10 Jul 2009 21:50:10 +0300 Message-ID: From: Dan Naumov To: Jens Rasmus Liland Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org Subject: Re: Error when using 'portupgrade -ay'. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2009 18:50:11 -0000 On Fri, Jul 10, 2009 at 9:00 PM, Jens Rasmus Liland w= rote: > Hello! > > I had an error just now running 'portupgrade -ay'. Got this output: > > ---OUTPUT START--- > > ---> =A0Session started at: Fri, 10 Jul 2009 18:58:30 +0200 > ** Port directory not found: x11-drivers/xf86-video-vga > ** Port marked as IGNORE: x11-drivers/xf86-video-via: > =A0 =A0requires pciVideoPtr typedef > ** Port directory not found: x11/xorg-protos > ** Port directory not found: x11/xphelloworld > ---> =A0Skipping 'x11-drivers/xorg-drivers' (xorg-drivers-7.3_3) because = a > requisite package 'xf86-video-vga-4.1.0_2' (x11-drivers/xf86-video-vga) > failed (specify -k to force) > ---> =A0** Upgrade tasks 3: 0 done, 4 ignored, 1 skipped and 0 failed > ---> =A0Skipping 'x11/xorg-apps' (xorg-apps-7.3) because a requisite pack= age > 'xphelloworld-1.0.1_1' (x11/xphelloworld) failed (specify -k to force) > ---> =A0** Upgrade tasks 3: 0 done, 4 ignored, 2 skipped and 0 failed > ---> =A0Skipping 'x11/xorg' (xorg-7.3_2) because a requisite package > 'xorg-drivers-7.3_3' (x11-drivers/xorg-drivers) failed (specify -k to for= ce) > ---> =A0** Upgrade tasks 3: 0 done, 4 ignored, 3 skipped and 0 failed > ---> =A0Listing the results (+:done / -:ignored / *:skipped / !:failed) > =A0 =A0- x11-drivers/xf86-video-vga (port directory error) > =A0 =A0- x11-drivers/xf86-video-via (marked as IGNORE) > =A0 =A0- x11/xorg-protos (port directory error) > =A0 =A0- x11/xphelloworld (port directory error) > =A0 =A0* x11-drivers/xorg-drivers (xorg-drivers-7.3_3) > =A0 =A0* x11/xorg-apps (xorg-apps-7.3) > =A0 =A0* x11/xorg (xorg-7.3_2) > ---> =A0Packages processed: 0 done, 4 ignored, 3 skipped and 0 failed > ---> =A0Session ended at: Fri, 10 Jul 2009 18:58:46 +0200 (consumed 00:00= :15) > > ---OUTPUT STOP--- > > I've never got an error like this. What am I to do to make it work correc= tly > again? What is the method you use for updating your ports tree? What happens if you nuke /usr/ports from orbit and run: "portsnap fetch; portsnap extract" and try running 'portupgrade -ay' again? - Sincerely, Dan Naumov From owner-freebsd-stable@FreeBSD.ORG Fri Jul 10 20:49:40 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 062191065673; Fri, 10 Jul 2009 20:49:40 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-bw0-f221.google.com (mail-bw0-f221.google.com [209.85.218.221]) by mx1.freebsd.org (Postfix) with ESMTP id 5EB768FC16; Fri, 10 Jul 2009 20:49:38 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: by bwz21 with SMTP id 21so913507bwz.43 for ; Fri, 10 Jul 2009 13:49:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=StV2SaKOAF/A0aYyRMiPwpKeb+vjZPyM6TOMGZqgF34=; b=sSdfpjQgrbsOryO2hplaYtXApq6tez310eZqC950HlqfpQaxZ7ez6V3bTQr82/7sIF Tgr+aiAz8MDeOQ4g14ddXEqUn5fO7nXsLOJBknDDYIeyxMD7v6bxBTSnNS+6YAUfwDsf XOwcJEt0zD2gXViJGvyCb/gT3ET0P4oBMvo20= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=EaHVdqRj0TkGuTeSSfQ0D5BKifXST/W9gzvlizU2iViKcSuda3xN9ei5D+AzVss7MS 8VnkXODjy6RGeQXRMalM1NvJ5weZIlkAhe8AesSj10ADT6LdAJ+NIVkHJWgAlE5Hr42N +FqWeunTxwkiw8Wa2AwwRiMkWuE4+3grneAbw= MIME-Version: 1.0 Sender: asmrookie@gmail.com Received: by 10.223.105.7 with SMTP id r7mr1391787fao.8.1247258977289; Fri, 10 Jul 2009 13:49:37 -0700 (PDT) In-Reply-To: <6101e8c40907100801r382ded4boddd853f771867bd0@mail.gmail.com> References: <6101e8c40907091755n5aefe289r6eec14cf7f4287dc@mail.gmail.com> <6101e8c40907100801r382ded4boddd853f771867bd0@mail.gmail.com> Date: Fri, 10 Jul 2009 22:49:37 +0200 X-Google-Sender-Auth: 8b891e572bb3ef1a Message-ID: <3bbf2fe10907101349t64bc0acav371498aed580b6bd@mail.gmail.com> From: Attilio Rao To: Oliver Pinter Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org, Robert Watson Subject: Re: smbfs panic when lost connection or unmount --force X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2009 20:49:40 -0000 2009/7/10 Oliver Pinter : > Hello! > > Here is the bt: > http://centaur.sch.bme.hu/~oliverp/freebsd/smbfs_panic/DSC01845.JPG > http://centaur.sch.bme.hu/~oliverp/freebsd/smbfs_panic/DSC01846.JPG > http://centaur.sch.bme.hu/~oliverp/freebsd/smbfs_panic/DSC01847.JPG Could you please add in this informations registers state and locked vnodes? Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-stable@FreeBSD.ORG Fri Jul 10 22:01:55 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 49778106564A; Fri, 10 Jul 2009 22:01:55 +0000 (UTC) (envelope-from oliver.pntr@gmail.com) Received: from mail-fx0-f224.google.com (mail-fx0-f224.google.com [209.85.220.224]) by mx1.freebsd.org (Postfix) with ESMTP id 7A79A8FC14; Fri, 10 Jul 2009 22:01:54 +0000 (UTC) (envelope-from oliver.pntr@gmail.com) Received: by fxm24 with SMTP id 24so949457fxm.43 for ; Fri, 10 Jul 2009 15:01:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=R4KhQwYoH+38xzlyMhqnm5pAN2Mk1J/D1GjPb1AVPGA=; b=mFouswsl8ySB4ZDqPOGGCLEiv2Y2PUGMDVnzOHK3R0HVjFVCBGS6BGM9YDTaCl7odh oP/rhDyFS203AB4MoaCnTbPDCzBqpBI9RWHkEvgLIsYNaZbCmafpUDkaafI6tsryqAF5 ufJsZ+KflECuIi9q0VwdkVUDG/BEL+SxhdQtU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=uNNFIkb/bWcXZUiflNOzoOIwyHZ3UPe3EAzc8Y5vxcTZsZOKk+aIKwuku4sTzUUYLW 6LO41Y2LoQVLNhysJhqx6QM7N+BAC8pM6+LjXyRjosDVq/6enaMps5TlICYCtm1TIvQi QxQ4SaHeQZIqZkb8/S7lyw7rpT4mqLboTjBbQ= MIME-Version: 1.0 Received: by 10.103.1.17 with SMTP id d17mr1358426mui.60.1247263313363; Fri, 10 Jul 2009 15:01:53 -0700 (PDT) In-Reply-To: <3bbf2fe10907101349t64bc0acav371498aed580b6bd@mail.gmail.com> References: <6101e8c40907091755n5aefe289r6eec14cf7f4287dc@mail.gmail.com> <6101e8c40907100801r382ded4boddd853f771867bd0@mail.gmail.com> <3bbf2fe10907101349t64bc0acav371498aed580b6bd@mail.gmail.com> Date: Sat, 11 Jul 2009 00:01:53 +0200 Message-ID: <6101e8c40907101501k36d757fch61b27f6a78a559d6@mail.gmail.com> From: Oliver Pinter To: Attilio Rao Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org, Robert Watson Subject: Re: smbfs panic when lost connection or unmount --force X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2009 22:01:55 -0000 regs and vnodes: http://centaur.sch.bme.hu/~oliverp/freebsd/smbfs_panic/DSC01854.JPG http://centaur.sch.bme.hu/~oliverp/freebsd/smbfs_panic/DSC01855.JPG http://centaur.sch.bme.hu/~oliverp/freebsd/smbfs_panic/DSC01856.JPG http://centaur.sch.bme.hu/~oliverp/freebsd/smbfs_panic/DSC01857.JPG http://centaur.sch.bme.hu/~oliverp/freebsd/smbfs_panic/DSC01858.JPG http://centaur.sch.bme.hu/~oliverp/freebsd/smbfs_panic/DSC01859.JPG http://centaur.sch.bme.hu/~oliverp/freebsd/smbfs_panic/DSC01860.JPG On 7/10/09, Attilio Rao wrote: > 2009/7/10 Oliver Pinter : >> Hello! >> >> Here is the bt: >> http://centaur.sch.bme.hu/~oliverp/freebsd/smbfs_panic/DSC01845.JPG >> http://centaur.sch.bme.hu/~oliverp/freebsd/smbfs_panic/DSC01846.JPG >> http://centaur.sch.bme.hu/~oliverp/freebsd/smbfs_panic/DSC01847.JPG > > Could you please add in this informations registers state and locked > vnodes? > > Thanks, > Attilio > > > -- > Peace can only be achieved by understanding - A. Einstein > From owner-freebsd-stable@FreeBSD.ORG Fri Jul 10 22:03:24 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D077E1065801 for ; Fri, 10 Jul 2009 22:03:24 +0000 (UTC) (envelope-from qing.li@bluecoat.com) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by mx1.freebsd.org (Postfix) with ESMTP id 4D17E8FC1F; Fri, 10 Jul 2009 22:03:24 +0000 (UTC) (envelope-from qing.li@bluecoat.com) Received: from bcs-mail03.internal.cacheflow.com ([10.2.2.95]) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id n6ALphwX004611; Fri, 10 Jul 2009 14:51:44 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 10 Jul 2009 14:51:39 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 8.0-BETA1 - for the record - different paths followed by IPv4 and IPv6 for 'local' connections Thread-Index: AcoBWrJ+I+9bnFsRRUabMfoqrB4rsgATKDg1 References: <4A5734C3.3000806@restart.be> From: "Li, Qing" To: "Henri Hennebert" , , Cc: Subject: RE: 8.0-BETA1 - for the record - different paths followed by IPv4 and IPv6 for 'local' connections X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2009 22:03:25 -0000 Hi, Please try patch-7-10 in my home directory = http://people.freebsd.org/~qingli/ and let me know how it works out for you. I thought I had committed the = patch=20 but turned out I didn't. > > On 8.0-BETA1 there is an assymetry: > > netstat -rn display >=20 > 192.168.24.1 link#3 > .... > no entry for 2001:41d0:2:2d29:1:1:: >=20 This is by design as part of the new architecture in 8.0, which = maintains=20 the L2 ARP/ND6 and L3 routing tables separately. -- Qing -----Original Message----- From: owner-freebsd-stable@freebsd.org on behalf of Henri Hennebert Sent: Fri 7/10/2009 5:32 AM To: freebsd-stable@freebsd.org; freebsd-st@freebsd.org Subject: 8.0-BETA1 - for the record - different paths followed by IPv4 = and IPv6 for 'local' connections =20 Hello, After upgrading from 7.2-STABLE to 8.0-BETA1 I encounter a problem when=20 connecting with firefox to a local apache server using the global=20 unicast IPv6 address of the local machine. pf.conf must be updated! My configuration: [root@avoriaz ~]# ifconfig em0 em0: flags=3D8843 metric 0 mtu = 1500 options=3D19b ether 00:1d:60:ad:2a:ce inet 192.168.24.1 netmask 0xffffff00 broadcast 192.168.24.255 inet6 fe80::21d:60ff:fead:2ace%em0 prefixlen 64 scopeid 0x1 inet6 2001:41d0:2:2d29:1:1:: prefixlen 80 media: Ethernet 100baseTX (100baseTX ) status: active [root@avoriaz ~]# host www.restart.bel www.restart.bel is an alias for avoriaz.restart.bel. avoriaz.restart.bel has address 192.168.24.1 avoriaz.restart.bel has IPv6 address 2001:41d0:2:2d29:1:1:: pf.conf: int_if=3D"em0" block in log all block out log all set skip on lo0 antispoof quick for $int_if inet # Allow trafic with physical internal network pass in quick on $int_if from ($int_if:network) to ($int_if) keep state pass out quick on $int_if from ($int_if) to ($int_if:network) keep state The problem: [root@avoriaz ~]# telnet -4 www.restart.bel 80 Trying 192.168.24.1... Connected to avoriaz.restart.bel. Escape character is '^]'. ^] telnet> quit Connection closed. [root@avoriaz ~]# telnet -6 www.restart.bel 80 Trying 2001:41d0:2:2d29:1:1::... --->Never connect and get a timeout! tcpdump and logging in pf show me that For a IPv4 connection: the packet from telnet to apache pass 2 times on lo0 (out and in) the answer packet from apache to telnet pass 2 times on lo0 (out and in) So no problem, there is `set skip on lo0' For a IPv6 connection: The first packet from telnet to apache pass 2 times on lo0 (out and in) The answer packet from apache to telnet path on em0 and is rejected due to the default flags S/SA. So I have to change pf.conf and replace the last line: pass out quick on $int_if from ($int_if) to ($int_if:network) \ keep state flags any Then all is OK By the way, on 7.2 netstat -rn display 192.168.24.1 00:1d:60:ad:2a:ce .... 2001:41d0:2:2d29:1:1:: 00:1d:60:ad:2a:ce On 8.0-BETA1 there is an assymetry: netstat -rn display 192.168.24.1 link#3 .... no entry for 2001:41d0:2:2d29:1:1:: Hope it may help someone Henri _______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to = "freebsd-stable-unsubscribe@freebsd.org" From owner-freebsd-stable@FreeBSD.ORG Sat Jul 11 00:58:37 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D00CF106568F; Sat, 11 Jul 2009 00:58:37 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-bw0-f221.google.com (mail-bw0-f221.google.com [209.85.218.221]) by mx1.freebsd.org (Postfix) with ESMTP id 256DA8FC21; Sat, 11 Jul 2009 00:58:36 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: by bwz21 with SMTP id 21so976497bwz.43 for ; Fri, 10 Jul 2009 17:58:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=pZq/gERy2d6kwb/9pEH26fQKXUu5NMM6kJNCgn4grpE=; b=sQHLACD4aOGDEvZFdGIkHNjXgsDu7XqAW5TcSEv8Xu4KVGSWh7oQx/YU9AHdJOpkoi 8qFgz8vjMgnpHfXCd85wiN2l+oQmZH0YvXs+8Sz0KgNceGAtPjhLLiVijTgNzq5BCl2E UnN5o5CyByTDEQzv2GjGdkTDMm+itfjo80eoI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=Uh3xITv3gvkFzlKzBO3Gp6Km9WJN/uxxY9kGRgzmwyj/yPrZQSDAhQzYzFE0PZga8f lKfde4TJYU8gHaxp9hg4lKDHPVuSJG/mUfMkM5zXkhjXbciMz7vUjk07iEkXGikhGO4r 7zo7WDdYeZ4hg/jGtm8M3Xa2JHtHGosZnKlYc= MIME-Version: 1.0 Sender: asmrookie@gmail.com Received: by 10.223.126.10 with SMTP id a10mr1427499fas.17.1247273916031; Fri, 10 Jul 2009 17:58:36 -0700 (PDT) In-Reply-To: <6101e8c40907101501k36d757fch61b27f6a78a559d6@mail.gmail.com> References: <6101e8c40907091755n5aefe289r6eec14cf7f4287dc@mail.gmail.com> <6101e8c40907100801r382ded4boddd853f771867bd0@mail.gmail.com> <3bbf2fe10907101349t64bc0acav371498aed580b6bd@mail.gmail.com> <6101e8c40907101501k36d757fch61b27f6a78a559d6@mail.gmail.com> Date: Sat, 11 Jul 2009 02:58:35 +0200 X-Google-Sender-Auth: 78339c2d23d3b558 Message-ID: <3bbf2fe10907101758x81d926bo5eb9f5adb9c80e25@mail.gmail.com> From: Attilio Rao To: Oliver Pinter Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Robert Watson , freebsd-stable@freebsd.org Subject: Re: smbfs panic when lost connection or unmount --force X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jul 2009 00:58:38 -0000 2009/7/11 Oliver Pinter : > regs and vnodes: > > http://centaur.sch.bme.hu/~oliverp/freebsd/smbfs_panic/DSC01854.JPG > http://centaur.sch.bme.hu/~oliverp/freebsd/smbfs_panic/DSC01855.JPG > http://centaur.sch.bme.hu/~oliverp/freebsd/smbfs_panic/DSC01856.JPG > http://centaur.sch.bme.hu/~oliverp/freebsd/smbfs_panic/DSC01857.JPG > http://centaur.sch.bme.hu/~oliverp/freebsd/smbfs_panic/DSC01858.JPG > http://centaur.sch.bme.hu/~oliverp/freebsd/smbfs_panic/DSC01859.JPG > http://centaur.sch.bme.hu/~oliverp/freebsd/smbfs_panic/DSC01860.JPG Sorry, maybe I wasn't clear, you should spell them 'lockedvnods'. Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-stable@FreeBSD.ORG Sat Jul 11 08:40:46 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 45327106566C for ; Sat, 11 Jul 2009 08:40:46 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from mail11.syd.optusnet.com.au (mail11.syd.optusnet.com.au [211.29.132.192]) by mx1.freebsd.org (Postfix) with ESMTP id CA0F98FC23 for ; Sat, 11 Jul 2009 08:40:45 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from server.vk2pj.dyndns.org (c122-106-247-205.belrs3.nsw.optusnet.com.au [122.106.247.205]) by mail11.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id n6B8egnl011288 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 11 Jul 2009 18:40:43 +1000 X-Bogosity: Ham, spamicity=0.000000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.3/8.14.3) with ESMTP id n6B8eg3a014763; Sat, 11 Jul 2009 18:40:42 +1000 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.3/8.14.3/Submit) id n6B8egZX014762; Sat, 11 Jul 2009 18:40:42 +1000 (EST) (envelope-from peter) Date: Sat, 11 Jul 2009 18:40:42 +1000 From: Peter Jeremy To: Dan Naumov Message-ID: <20090711084042.GA77702@server.vk2pj.dyndns.org> References: <20090709112512.GA44158@hugo10.ka.punkt.de> <73a41d4b72d62b0bfe3d0fb7206376a8.squirrel@cygnus.homeunix.com> <84665df87e93a6ccf24d9837cbc53eba.squirrel@cygnus.homeunix.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="y0ulUmNC+osPPQO6" Content-Disposition: inline In-Reply-To: X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.19 (2009-01-05) Cc: freebsd-stable@freebsd.org Subject: Re: ZFS - thanks X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jul 2009 08:40:46 -0000 --y0ulUmNC+osPPQO6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2009-Jul-09 15:39:35 +0300, Dan Naumov wrote: >A single 40 disk raidz (DO NOT DO THIS) will have 40 disks total, 39 >disks worth of space and will definately explode on you sooner rather >than later (probably on the first import, export or scrub). Can you provide a reference for this statement. AFAIK, the only reason for the upper recommended limit of 9 disks is performance. --=20 Peter Jeremy --y0ulUmNC+osPPQO6 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (FreeBSD) iEYEARECAAYFAkpYUAoACgkQ/opHv/APuIecvgCdFq7GwBQOkPMFGHJiM9tjg4xl iIYAmwSg5z4KbFub8yPNktoXvnwYG05y =HDb/ -----END PGP SIGNATURE----- --y0ulUmNC+osPPQO6-- From owner-freebsd-stable@FreeBSD.ORG Sat Jul 11 08:44:10 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0C8F71065670 for ; Sat, 11 Jul 2009 08:44:10 +0000 (UTC) (envelope-from dan.naumov@gmail.com) Received: from mail-gx0-f217.google.com (mail-gx0-f217.google.com [209.85.217.217]) by mx1.freebsd.org (Postfix) with ESMTP id B6D118FC08 for ; Sat, 11 Jul 2009 08:44:09 +0000 (UTC) (envelope-from dan.naumov@gmail.com) Received: by gxk17 with SMTP id 17so1760667gxk.19 for ; Sat, 11 Jul 2009 01:44:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=mTOSeAVB9iH+u2bFhq6XjpUAlw6n7ft0oOnyjwf8kOM=; b=A4+2BYpwRmiCuLptErAAI2eKJxV+fogJZAx/yW/dxQEmOZJEPc7Sfxj7nEM4T+dZs2 qosiie3I/PhfzJ/X9XJZg3X9UvB59Utuv3v9/iRiHZrx53OdXsKRfwqEg1dQ5/esOsnJ 9AWV9uQSQKTT/K7+iXZC/WpWTTkfiJ//GyfaQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=OrAq2E7qCdmGL6vkvY8BmG5Tz/zf9ur83CGozhh9P7trLp1c6/5mMcOathucBas0HV 4eA7NZvb4nDvtWvEpRMP0MXQZBVl8Pov6adcJ1QTcAS2dgOSKJFiLgeE1DB4+Nw3Ltw1 IhOocHyZMw2+Wo5340LwOjblO6vCOJ+XIGf48= MIME-Version: 1.0 Received: by 10.100.127.14 with SMTP id z14mr4029288anc.37.1247301849221; Sat, 11 Jul 2009 01:44:09 -0700 (PDT) In-Reply-To: <20090711084042.GA77702@server.vk2pj.dyndns.org> References: <20090709112512.GA44158@hugo10.ka.punkt.de> <73a41d4b72d62b0bfe3d0fb7206376a8.squirrel@cygnus.homeunix.com> <84665df87e93a6ccf24d9837cbc53eba.squirrel@cygnus.homeunix.com> <20090711084042.GA77702@server.vk2pj.dyndns.org> Date: Sat, 11 Jul 2009 11:44:09 +0300 Message-ID: From: Dan Naumov To: Peter Jeremy Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org Subject: Re: ZFS - thanks X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jul 2009 08:44:10 -0000 On Sat, Jul 11, 2009 at 11:40 AM, Peter Jeremy wrote: > On 2009-Jul-09 15:39:35 +0300, Dan Naumov wrote: >>A single 40 disk raidz (DO NOT DO THIS) will have 40 disks total, 39 >>disks worth of space and will definately explode on you sooner rather >>than later (probably on the first import, export or scrub). > > Can you provide a reference for this statement. =A0AFAIK, the only > reason for the upper recommended limit of 9 disks is performance. > > -- > Peter Jeremy Searching the different FreeBSD mailing lists (which have had discussions about such cases) and googling should yield results. - Sincerely, Dan Naumov From owner-freebsd-stable@FreeBSD.ORG Sat Jul 11 10:09:48 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6D205106566C; Sat, 11 Jul 2009 10:09:48 +0000 (UTC) (envelope-from hlh@restart.be) Received: from tignes.restart.be (tignes.restart.be [IPv6:2001:41d0:2:2d29:0:1::]) by mx1.freebsd.org (Postfix) with ESMTP id E99C78FC0A; Sat, 11 Jul 2009 10:09:47 +0000 (UTC) (envelope-from hlh@restart.be) Received: from restart.be (avoriaz.tunnel.bel [IPv6:2001:41d0:2:2d29:1:ffff::]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "avoriaz.restart.be", Issuer "CA master" (verified OK)) by tignes.restart.be (Postfix) with ESMTPS id 1106349EC; Sat, 11 Jul 2009 12:09:47 +0200 (CEST) Received: from avoriaz.restart.bel (avoriaz.restart.be [IPv6:2001:41d0:2:2d29:1:1::]) (authenticated bits=0) by restart.be (8.14.3/8.14.3) with ESMTP id n6BA9WFF002010; Sat, 11 Jul 2009 12:09:44 +0200 (CEST) (envelope-from hlh@restart.be) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=restart.be; s=avoriaz; t=1247306986; bh=ohZzOiiDOclM9ju3h+ps/X/cNm82mYLSLdB0v1b9nm4=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=zduN8S5MpQBGMK8EG4q9yYtnIWoK6a8dG2eWJGTmDsZqRlJTxMZcSjGZZqzjQUzXM jF2ApULFOOa19pU2kCxxg== DomainKey-Signature: a=rsa-sha1; s=avoriaz; d=restart.be; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type: content-transfer-encoding:x-scanned-by; b=FqlBW87rw1hbX+XOTru7+xqPdq2MXEBitcIYu/SBfF2LgFN7+gg+2uoxLJ8xlLGt8 s/iVMnxKbvjikV17MtQ0g== Message-ID: <4A5864DC.1070106@restart.be> Date: Sat, 11 Jul 2009 12:09:32 +0200 From: Henri Hennebert User-Agent: Thunderbird 2.0.0.22 (X11/20090710) MIME-Version: 1.0 To: "Li, Qing" References: <4A5734C3.3000806@restart.be> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.64 on IPv6:2001:41d0:2:2d29:1:1:: Cc: freebsd-net@freebsd.org, freebsd-stable@freebsd.org Subject: Re: 8.0-BETA1 - for the record - different paths followed by IPv4 and IPv6 for 'local' connections X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jul 2009 10:09:50 -0000 Li, Qing wrote: > Hi, > > Please try patch-7-10 in my home directory http://people.freebsd.org/~qingli/ > and let me know how it works out for you. I thought I had committed the patch > but turned out I didn't. I apply the patch, reset my pf.conf to its previous content and all is running smoothly. By the way, I discover after my post that my "solution" was not working for long (many bytes) connections and this is solved too. Many thank for your time Henri PS please commit as soon as possible > >> On 8.0-BETA1 there is an assymetry: >> >> netstat -rn display >> >> 192.168.24.1 link#3 >> .... >> no entry for 2001:41d0:2:2d29:1:1:: >> > > This is by design as part of the new architecture in 8.0, which maintains > the L2 ARP/ND6 and L3 routing tables separately. > > -- Qing > > > > -----Original Message----- > From: owner-freebsd-stable@freebsd.org on behalf of Henri Hennebert > Sent: Fri 7/10/2009 5:32 AM > To: freebsd-stable@freebsd.org; freebsd-st@freebsd.org > Subject: 8.0-BETA1 - for the record - different paths followed by IPv4 and IPv6 for 'local' connections > > Hello, > > After upgrading from 7.2-STABLE to 8.0-BETA1 I encounter a problem when > connecting with firefox to a local apache server using the global > unicast IPv6 address of the local machine. pf.conf must be updated! > > My configuration: > > [root@avoriaz ~]# ifconfig em0 > > em0: flags=8843 metric 0 mtu 1500 > options=19b > ether 00:1d:60:ad:2a:ce > inet 192.168.24.1 netmask 0xffffff00 broadcast 192.168.24.255 > inet6 fe80::21d:60ff:fead:2ace%em0 prefixlen 64 scopeid 0x1 > inet6 2001:41d0:2:2d29:1:1:: prefixlen 80 > media: Ethernet 100baseTX (100baseTX ) > status: active > > [root@avoriaz ~]# host www.restart.bel > www.restart.bel is an alias for avoriaz.restart.bel. > avoriaz.restart.bel has address 192.168.24.1 > avoriaz.restart.bel has IPv6 address 2001:41d0:2:2d29:1:1:: > > pf.conf: > > int_if="em0" > block in log all > block out log all > set skip on lo0 > antispoof quick for $int_if inet > # Allow trafic with physical internal network > pass in quick on $int_if from ($int_if:network) to ($int_if) keep state > pass out quick on $int_if from ($int_if) to ($int_if:network) keep state > > The problem: > > [root@avoriaz ~]# telnet -4 www.restart.bel 80 > Trying 192.168.24.1... > Connected to avoriaz.restart.bel. > Escape character is '^]'. > ^] > telnet> quit > Connection closed. > [root@avoriaz ~]# telnet -6 www.restart.bel 80 > Trying 2001:41d0:2:2d29:1:1::... > --->Never connect and get a timeout! > > tcpdump and logging in pf show me that > > For a IPv4 connection: > the packet from telnet to apache pass 2 times on lo0 (out and in) > the answer packet from apache to telnet pass 2 times on lo0 (out and in) > > So no problem, there is `set skip on lo0' > > For a IPv6 connection: > The first packet from telnet to apache pass 2 times on lo0 (out and in) > The answer packet from apache to telnet path on em0 and is rejected > due to the default flags S/SA. > > So I have to change pf.conf and replace the last line: > pass out quick on $int_if from ($int_if) to ($int_if:network) \ > keep state flags any > > Then all is OK > > By the way, on 7.2 > > netstat -rn display > > 192.168.24.1 00:1d:60:ad:2a:ce > .... > 2001:41d0:2:2d29:1:1:: 00:1d:60:ad:2a:ce > > > On 8.0-BETA1 there is an assymetry: > > netstat -rn display > > 192.168.24.1 link#3 > .... > no entry for 2001:41d0:2:2d29:1:1:: > > Hope it may help someone > > Henri > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From owner-freebsd-stable@FreeBSD.ORG Sat Jul 11 14:15:29 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 98157106564A for ; Sat, 11 Jul 2009 14:15:29 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id 59D2B8FC0C for ; Sat, 11 Jul 2009 14:15:29 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from [IPv6:2001:7b8:3a7:0:cc47:6265:9b5e:7450] (unknown [IPv6:2001:7b8:3a7:0:cc47:6265:9b5e:7450]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id D28D25C42; Sat, 11 Jul 2009 16:15:27 +0200 (CEST) Message-ID: <4A589E80.10901@andric.com> Date: Sat, 11 Jul 2009 16:15:28 +0200 From: Dimitry Andric User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.1.1pre) Gecko/20090705 Shredder/3.0b3pre MIME-Version: 1.0 To: Peter Jeremy References: <20090709112512.GA44158@hugo10.ka.punkt.de> <73a41d4b72d62b0bfe3d0fb7206376a8.squirrel@cygnus.homeunix.com> <84665df87e93a6ccf24d9837cbc53eba.squirrel@cygnus.homeunix.com> <20090711084042.GA77702@server.vk2pj.dyndns.org> In-Reply-To: <20090711084042.GA77702@server.vk2pj.dyndns.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org, Dan Naumov Subject: Re: ZFS - thanks X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jul 2009 14:15:29 -0000 On 2009-07-11 10:40, Peter Jeremy wrote: > On 2009-Jul-09 15:39:35 +0300, Dan Naumov wrote: >> A single 40 disk raidz (DO NOT DO THIS) will have 40 disks total, 39 >> disks worth of space and will definately explode on you sooner rather >> than later (probably on the first import, export or scrub). > > Can you provide a reference for this statement. AFAIK, the only > reason for the upper recommended limit of 9 disks is performance. The more disks you use in one RAID set, the higher the probability that more than one disk will fail at the same time. An interesting read can be found here: http://blogs.zdnet.com/storage/?p=162 From owner-freebsd-stable@FreeBSD.ORG Sat Jul 11 14:48:31 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B3E46106567C; Sat, 11 Jul 2009 14:48:31 +0000 (UTC) (envelope-from oliver.pntr@gmail.com) Received: from mail-fx0-f224.google.com (mail-fx0-f224.google.com [209.85.220.224]) by mx1.freebsd.org (Postfix) with ESMTP id B298F8FC2A; Sat, 11 Jul 2009 14:48:30 +0000 (UTC) (envelope-from oliver.pntr@gmail.com) Received: by fxm24 with SMTP id 24so1157389fxm.43 for ; Sat, 11 Jul 2009 07:48:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=QCoj+CJRN4cqa6rVBnuHM7GiTcSrfl2o5tMvPSm57uM=; b=siOjE9UaJ/dYW/sVMnMCIbBYi+GNUo5d+sueXrrqiPybY4rxA8tFXxYouX7djj4S/3 y4Yg3usp9PqAnCIbNPlF2DHPbIdVH1p5kMlwpK+cb5gwMBae8libLqIoMZ8zd85j2ULt ZQuobo+W97dLWqVDz/1mpDON91W07NQTKZ7k8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=c8GQYGnMgCdeGl7JH6FamCE8qYHAHVboz0ekzGw8NVo3yGFdiFdDkXQTxHxjfXE27Y wfka2qkvpTI9u9+sFkhbG2cOrso9trYy/shHOW3QPGfAzrNR/N0Jp5dEwdJc43U3DU4A ye2q4v+goVGJAwfI1a+9hJCmovIR++44zyYbE= MIME-Version: 1.0 Received: by 10.103.240.5 with SMTP id s5mr1676577mur.5.1247323709765; Sat, 11 Jul 2009 07:48:29 -0700 (PDT) In-Reply-To: <3bbf2fe10907101758x81d926bo5eb9f5adb9c80e25@mail.gmail.com> References: <6101e8c40907091755n5aefe289r6eec14cf7f4287dc@mail.gmail.com> <6101e8c40907100801r382ded4boddd853f771867bd0@mail.gmail.com> <3bbf2fe10907101349t64bc0acav371498aed580b6bd@mail.gmail.com> <6101e8c40907101501k36d757fch61b27f6a78a559d6@mail.gmail.com> <3bbf2fe10907101758x81d926bo5eb9f5adb9c80e25@mail.gmail.com> Date: Sat, 11 Jul 2009 16:48:29 +0200 Message-ID: <6101e8c40907110748n602a03frb3519abe2e251d72@mail.gmail.com> From: Oliver Pinter To: Attilio Rao Content-Type: multipart/mixed; boundary=001636920027a3fdf5046e6f2e96 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Robert Watson , freebsd-stable@freebsd.org Subject: Re: smbfs panic when lost connection or unmount --force X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jul 2009 14:48:32 -0000 --001636920027a3fdf5046e6f2e96 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit the good vnods On 7/11/09, Attilio Rao wrote: > 2009/7/11 Oliver Pinter : >> regs and vnodes: >> >> http://centaur.sch.bme.hu/~oliverp/freebsd/smbfs_panic/DSC01854.JPG >> http://centaur.sch.bme.hu/~oliverp/freebsd/smbfs_panic/DSC01855.JPG >> http://centaur.sch.bme.hu/~oliverp/freebsd/smbfs_panic/DSC01856.JPG >> http://centaur.sch.bme.hu/~oliverp/freebsd/smbfs_panic/DSC01857.JPG >> http://centaur.sch.bme.hu/~oliverp/freebsd/smbfs_panic/DSC01858.JPG >> http://centaur.sch.bme.hu/~oliverp/freebsd/smbfs_panic/DSC01859.JPG >> http://centaur.sch.bme.hu/~oliverp/freebsd/smbfs_panic/DSC01860.JPG > > Sorry, maybe I wasn't clear, you should spell them 'lockedvnods'. > > Thanks, > Attilio > > > > -- > Peace can only be achieved by understanding - A. Einstein > --001636920027a3fdf5046e6f2e96-- From owner-freebsd-stable@FreeBSD.ORG Sat Jul 11 15:05:14 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C3A251065670 for ; Sat, 11 Jul 2009 15:05:14 +0000 (UTC) (envelope-from ronald-freebsd8@klop.yi.org) Received: from smtp-out0.tiscali.nl (smtp-out0.tiscali.nl [195.241.79.175]) by mx1.freebsd.org (Postfix) with ESMTP id 5E9F08FC17 for ; Sat, 11 Jul 2009 15:05:14 +0000 (UTC) (envelope-from ronald-freebsd8@klop.yi.org) Received: from [212.123.145.58] (helo=sjakie.klop.ws) by smtp-out0.tiscali.nl with esmtp id 1MPe8X-0007qF-4s; Sat, 11 Jul 2009 17:05:13 +0200 Received: from 82-170-177-25.ip.telfort.nl (localhost [127.0.0.1]) by sjakie.klop.ws (Postfix) with ESMTP id DF09AA2A9; Sat, 11 Jul 2009 17:05:11 +0200 (CEST) Date: Sat, 11 Jul 2009 17:05:11 +0200 To: "Henri Hennebert" , "Ronald Klop" From: "Ronald Klop" Content-Type: text/plain; format=flowed; delsp=yes; charset=us-ascii MIME-Version: 1.0 References: <4A54727D.9080205@restart.be> Content-Transfer-Encoding: 7bit Message-ID: In-Reply-To: <4A54727D.9080205@restart.be> User-Agent: Opera Mail/9.64 (FreeBSD) Cc: "freebsd-stable@freebsd.org" Subject: Re: Zfs on usb-disk checksum errors? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jul 2009 15:05:15 -0000 On Wed, 08 Jul 2009 12:18:37 +0200, Henri Hennebert wrote: > Ronald Klop wrote: >> Hi. >> I put zfs on my external usb-disk, so I can backup my harddisk with >> zfs send/receive. >> I now have corruption on this volume. >> [root@sjakie ~]# zpool status -v >> pool: extern >> state: ONLINE >> status: One or more devices has experienced an error resulting in data >> corruption. Applications may be affected. >> action: Restore the file in question if possible. Otherwise restore the >> entire pool from backup. >> see: http://www.sun.com/msg/ZFS-8000-8A >> scrub: scrub completed after 0h2m with 0 errors on Wed Jul 8 00:35:09 >> 2009 >> config: >> NAME STATE READ WRITE CKSUM >> extern ONLINE 1 0 0 >> da0 ONLINE 9 0 0 >> errors: Permanent errors have been detected in the following files: >> <0x3f>:<0xf5d6> >> I don't really understand which files have corruption. :-( >> In my syslog is this: (repeated quite often) >> Jul 8 10:00:37 sjakie kernel: (da0:umass-sim0:0:0:0): SYNCHRONIZE >> CACHE(10). CDB: 35 0 0 0 0 0 0 0 0 0 >> Jul 8 10:00:37 sjakie kernel: (da0:umass-sim0:0:0:0): CAM Status: SCSI >> Status Error >> Jul 8 10:00:37 sjakie kernel: (da0:umass-sim0:0:0:0): SCSI Status: >> Check Condition >> Jul 8 10:00:37 sjakie kernel: (da0:umass-sim0:0:0:0): ILLEGAL REQUEST >> asc:20,0 >> Jul 8 10:00:37 sjakie kernel: (da0:umass-sim0:0:0:0): Invalid command >> operation code >> Jul 8 10:00:37 sjakie kernel: (da0:umass-sim0:0:0:0): Unretryable error >> > I experience the same error with 'Kingston DataTraveler II 1.13'. I > simply add in /usr/src/sys/dev/usb/usbdevs: > > product KINGSTON DATATRAVELER_2 0x1600 DAtaTraveler II > > (VENDOR was already in the file). > > and in sys/dev/usb/storage/umass.c: > > { USB_VENDOR_KINGSTON, USB_PRODUCT_KINGSTON_DATATRAVELER_2, > RID_WILDCARD, UMASS_PROTO_SCSI | UMASS_PROTO_BBB, > NO_SYNCHRONIZE_CACHE }, > Note the flag NO_SYNCHRONIZE_CACHE and everything return to normal. > > PS - I encounter this problem on 7.2_STABLE with the MFC of ZFS v13. > > Henri Thanks a lot. I owe you a beer! It works great now. Ronald. From owner-freebsd-stable@FreeBSD.ORG Sat Jul 11 16:10:09 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 9ADA5106566B for ; Sat, 11 Jul 2009 16:10:09 +0000 (UTC) (envelope-from cperciva@freebsd.org) Received: from xps.daemonology.net (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx2.freebsd.org (Postfix) with SMTP id 40D2B1506AF for ; Sat, 11 Jul 2009 16:10:09 +0000 (UTC) (envelope-from cperciva@freebsd.org) Received: (qmail 7448 invoked from network); 11 Jul 2009 16:10:08 -0000 Received: from unknown (HELO xps.daemonology.net) (127.0.0.1) by localhost with SMTP; 11 Jul 2009 16:10:08 -0000 Message-ID: <4A58B960.8050204@freebsd.org> Date: Sat, 11 Jul 2009 09:10:08 -0700 From: Colin Percival User-Agent: Thunderbird 2.0.0.21 (X11/20090405) MIME-Version: 1.0 To: FreeBSD Current , FreeBSD Stable X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: FreeBSD 8.0-BETA1 available via FreeBSD Update X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jul 2009 16:10:10 -0000 Hi all, The FreeBSD Update bits for FreeBSD 8.0-BETA1 are now available. Sorry for the delay. I've posted a step-by-step guide to my blog at http://www.daemonology.net/blog/2009-07-11-freebsd-update-to-8.0-beta1.html and I'm asking people to leave comments on that page if they encounter any problems -- I'm aware of two systems already which didn't manage to reboot after installing 8.0-BETA1 kernels, so this is definitely a case of "here be dragons". -- Colin Percival Security Officer, FreeBSD | freebsd.org | The power to serve Founder / author, Tarsnap | tarsnap.com | Online backups for the truly paranoid From owner-freebsd-stable@FreeBSD.ORG Sat Jul 11 20:07:54 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EE2CA106564A for ; Sat, 11 Jul 2009 20:07:54 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-yx0-f181.google.com (mail-yx0-f181.google.com [209.85.210.181]) by mx1.freebsd.org (Postfix) with ESMTP id A3FB38FC08 for ; Sat, 11 Jul 2009 20:07:54 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: by yxe11 with SMTP id 11so2737999yxe.3 for ; Sat, 11 Jul 2009 13:07:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=q1M4tkMJ54NwLsx5cUrvx9dWsdX2CQkp2RI+93rVKhA=; b=T082m1PJlsg1BM68AM6zE8UrsfpLv4HsD3w74q0gzzcsUUO6vxYNIfHfyKboGzjlnD G2OPugoI7BdIl11GmyeCiCmHvStwn1aY387VIrSeEZUS+EfFLny4E8AzarMqQx9wBtoB b+F1pl8m4dF8GRBwNl4gJPeMzi6liTyJLCOsc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=QPdDOQSiSXfg9fMa8anQAdsJL9XD5kZpBrDNBpI67nZ4Z9A49V6SNlxX3IvCzRhfan hmt0+mLbR1S7hkj1MySF0SVmTwvMsb6o5nOgcsv4cWY963Lv87oS2pdW1cx0TUzF3Z5w c5ap5uQkblvmc26vQPrR7WwWJ2dbE+xzCe/lA= MIME-Version: 1.0 Received: by 10.151.155.5 with SMTP id h5mr5387702ybo.259.1247342873817; Sat, 11 Jul 2009 13:07:53 -0700 (PDT) In-Reply-To: <20090711084042.GA77702@server.vk2pj.dyndns.org> References: <20090709112512.GA44158@hugo10.ka.punkt.de> <73a41d4b72d62b0bfe3d0fb7206376a8.squirrel@cygnus.homeunix.com> <84665df87e93a6ccf24d9837cbc53eba.squirrel@cygnus.homeunix.com> <20090711084042.GA77702@server.vk2pj.dyndns.org> Date: Sat, 11 Jul 2009 13:07:52 -0700 Message-ID: From: Freddie Cash To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: ZFS - thanks X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jul 2009 20:07:55 -0000 On Sat, Jul 11, 2009 at 1:40 AM, Peter Jeremy wrote: > On 2009-Jul-09 15:39:35 +0300, Dan Naumov wrote: > >A single 40 disk raidz (DO NOT DO THIS) will have 40 disks total, 39 > >disks worth of space and will definately explode on you sooner rather > >than later (probably on the first import, export or scrub). > > Can you provide a reference for this statement. AFAIK, the only > reason for the upper recommended limit of 9 disks is performance. > We found it impossible to re-silver a new/replacement drive in a 24-drive raidz2 vdev. Even after almost two weeks of trying, it never got above 20-30% complete before restarting. That led me to do a bunch of web searches, and found several blogs by Sun people that went over how the raidz implementation works, what the limitations are (limited to the IOps of a single drive), and the recommendation to never use more than 8 or 9 drives in any single vdev. -- Freddie Cash fjwcash@gmail.com