From owner-freebsd-stable@FreeBSD.ORG Sun Jul 12 19:18:19 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 10377106564A for ; Sun, 12 Jul 2009 19:18:19 +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 C05EE8FC0A for ; Sun, 12 Jul 2009 19:18:18 +0000 (UTC) (envelope-from rwatson@freebsd.org) Received: from [192.168.2.101] (host86-145-8-156.range86-145.btcentralplus.com [86.145.8.156]) by cyrus.watson.org (Postfix) with ESMTPSA id B53FC46B64; Sun, 12 Jul 2009 15:18:17 -0400 (EDT) Message-Id: From: "Robert N. M. Watson" To: Oliver Pinter In-Reply-To: <6101e8c40907100517q2d2e5891m62b0b7d57496b10@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Sun, 12 Jul 2009 20:18:16 +0100 References: <6101e8c40907091755n5aefe289r6eec14cf7f4287dc@mail.gmail.com> <6101e8c40907100517q2d2e5891m62b0b7d57496b10@mail.gmail.com> X-Mailer: Apple Mail (2.935.3) 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: Sun, 12 Jul 2009 19:18:19 -0000 On 10 Jul 2009, at 13:17, Oliver Pinter wrote: > I know, that the bt is useful, but ddb works with usb keyboard? > At nigth then I send the log. Unfortunately, a known issue with FreeBSD 8.0 is that the new USB stack, while a vast improvement over the previous USB stack in countless ways, does not support polled access from DDB. You will need to use a serial port, firewire port, ps/2, or AT keyboard in order to get interactive DDB support. If that's not feasible, or if it's just easier, you may be able to use the DDB scripting facility + textdumps to run DDB commands automatically on panic to produce useful debugging output. Take a look at the textdump(4) man page for details. This can be combined with a traditional crashdump to capture both DDB output and normal dump data for use with kgdb. Robert > > //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 >>> " >>> >> > From owner-freebsd-stable@FreeBSD.ORG Sun Jul 12 19:28: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 820461065672; Sun, 12 Jul 2009 19:28:29 +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 6176D8FC0C; Sun, 12 Jul 2009 19:28:29 +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 n6CJSSxL009745; Sun, 12 Jul 2009 12:28:28 -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: Sun, 12 Jul 2009 12:21:32 -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: AcoCD7nm0QOYQHIsS0ibc0bZM9LvQwBFjzrm References: <4A5734C3.3000806@restart.be> <4A5864DC.1070106@restart.be> From: "Li, Qing" To: "Henri Hennebert" Cc: freebsd-net@freebsd.org, freebsd-current@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: Sun, 12 Jul 2009 19:28:30 -0000 The patch has been committed, svn revision 195643. Thanks, -- Qing -----Original Message----- From: Henri Hennebert [mailto:hlh@restart.be] Sent: Sat 7/11/2009 3:09 AM To: Li, Qing Cc: freebsd-stable@freebsd.org; freebsd-net@freebsd.org Subject: Re: 8.0-BETA1 - for the record - different paths followed by = IPv4 and IPv6 for 'local' connections =20 Li, Qing wrote: > Hi, >=20 > 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. I apply the patch, reset my pf.conf to its previous content and all is=20 running smoothly. By the way, I discover after my post that my=20 "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 >=20 >> 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:: >> >=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. >=20 > -- Qing >=20 >=20 >=20 > -----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, >=20 > 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! >=20 > My configuration: >=20 > [root@avoriaz ~]# ifconfig em0 >=20 > 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 >=20 > [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:: >=20 > pf.conf: >=20 > 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 >=20 > The problem: >=20 > [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! >=20 > tcpdump and logging in pf show me that >=20 > 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) >=20 > So no problem, there is `set skip on lo0' >=20 > 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. >=20 > 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 >=20 > Then all is OK >=20 > By the way, on 7.2 >=20 > netstat -rn display >=20 > 192.168.24.1 00:1d:60:ad:2a:ce > .... > 2001:41d0:2:2d29:1:1:: 00:1d:60:ad:2a:ce >=20 >=20 > On 8.0-BETA1 there is an assymetry: >=20 > netstat -rn display >=20 > 192.168.24.1 link#3 > .... > no entry for 2001:41d0:2:2d29:1:1:: >=20 > Hope it may help someone >=20 > Henri >=20 > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to = "freebsd-stable-unsubscribe@freebsd.org" >=20 From owner-freebsd-stable@FreeBSD.ORG Sun Jul 12 20:00: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 6E7461065674 for ; Sun, 12 Jul 2009 20:00:26 +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 6A7DC8FC1C for ; Sun, 12 Jul 2009 20:00: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: Aj8FANrdWUrCVfWh/2dsb2JhbACBUMdPgmyBHQU X-IronPort-AV: E=Sophos;i="4.42,387,1243800000"; d="p7s'?scan'208";a="4268036" Received: from mail.ksu.ru (HELO ruby.ksu.ru) ([193.232.252.56]) by iout.kzn.ru with ESMTP; 13 Jul 2009 00:00:22 +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 n6CJ7G8a003595; Sun, 12 Jul 2009 19:07:16 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 n6CJxVHh048105; Sun, 12 Jul 2009 23:59:32 +0400 (MSD) (envelope-from amarat@ksu.ru) Message-ID: <4A5A40A3.1080202@ksu.ru> Date: Sun, 12 Jul 2009 23:59:31 +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: "Marat N.Afanasyev" References: <4A50E947.9020608@ksu.ru> In-Reply-To: <4A50E947.9020608@ksu.ru> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060403050800040209030600" 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, 12 Jul 2009 20:00:26 -0000 This is a cryptographically signed message in MIME format. --------------ms060403050800040209030600 Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Marat N.Afanasyev wrote: > > 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? > thanks everybody, i have resolved this as my misunderstanding of UFS basics, so it was pretty good lesson for me :) -- SY, Marat --------------ms060403050800040209030600 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 AKCCAcMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDkwNzEy MTk1OTMxWjAjBgkqhkiG9w0BCQQxFgQUClCcoZaDQddX9rFVpFk88+BGs4owUgYJKoZIhvcN AQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYF Kw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhB6bDKOp5G1FXoMYwM88WApMIGHBgsq hkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1 aW5nIENBAhB6bDKOp5G1FXoMYwM88WApMA0GCSqGSIb3DQEBAQUABIIBAKfC2tplpMFpwB6x HNLRVU4n7asXH9s3wphKtHcblvKbM/FDf9Wsd05GAh3hrz9dxw7xidy78V7AjwWZYhD/Hbvt OMCpu58uINwNJnpDxswq5KDISntv9xg84SBULLORJUNVt3IOgMbkMwXa9mmXZmprfUJBEd4j mG+YLIu3HPaDd+PacbkGe1BF2CWu/6w7vnTk7VX4if27XNNkVEpA4j8fuf7xItS76u6DWOjj T/Yte93BuTu7n4vTPwbstFVwb9bzGkVjSQJqpJon2r7z+79Z/3RxcC8qpR3CzyGsbvnoQP7D MXa2iOGdAC+WdcZLSitMCCOH9DBqnsbeKumWFV0AAAAAAAA= --------------ms060403050800040209030600-- From owner-freebsd-stable@FreeBSD.ORG Sun Jul 12 20:21: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 81C9C106566B; Sun, 12 Jul 2009 20:21:12 +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 D5B6A8FC13; Sun, 12 Jul 2009 20:21:11 +0000 (UTC) (envelope-from oliver.pntr@gmail.com) Received: by fxm24 with SMTP id 24so1547347fxm.43 for ; Sun, 12 Jul 2009 13:21: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=rWy0uKbR+/XyT6OKRz5AWpBVFXaWijvedwQDVJZTtR4=; b=ChInjncF4t8tZk6GcP35FHT697qSL3Zt/jub9+ydpI0CcqDPAuMhERBAkkh4YTWJ25 yGJZtrCPZwPzC4qxd3pUFwsraH4VSU7lNC+x1AhttlqXUJ0NyOjwVJJQW/FW2ZFGsf7p gKgnjlMbtOr2j5S5irzlFZqsYbwxnsh4Cal6s= 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=swWlcIF+KPW6zRb0BFuuKQGUJwDk0EfpSHa63RKDoT99LdAezjq55kMThbCZyRf6xg 1Wa9icMSvWCCu/K4EXLmy2dkBf/c3ocTCXNd9HDsb8E+5/Jrx4Vbrc7x9nrteCZu5Wcc 46L1wkT6JSVWR6dZ0qs/seuS/8WH/Yi118aiQ= MIME-Version: 1.0 Received: by 10.103.174.18 with SMTP id b18mr2202941mup.129.1247430070671; Sun, 12 Jul 2009 13:21:10 -0700 (PDT) In-Reply-To: References: <6101e8c40907091755n5aefe289r6eec14cf7f4287dc@mail.gmail.com> <6101e8c40907100517q2d2e5891m62b0b7d57496b10@mail.gmail.com> Date: Sun, 12 Jul 2009 22:21:10 +0200 Message-ID: <6101e8c40907121321v3e307e06l27c318ed3956197@mail.gmail.com> From: Oliver Pinter To: "Robert N. M. 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: Sun, 12 Jul 2009 20:21:12 -0000 On 7/12/09, Robert N. M. Watson wrote: > > On 10 Jul 2009, at 13:17, Oliver Pinter wrote: > >> I know, that the bt is useful, but ddb works with usb keyboard? >> At nigth then I send the log. > > Unfortunately, a known issue with FreeBSD 8.0 is that the new USB > stack, while a vast improvement over the previous USB stack in > countless ways, does not support polled access from DDB. You will need > to use a serial port, firewire port, ps/2, or AT keyboard in order to > get interactive DDB support. > it worked with usb keyboard, the pictured and the last log is made with usb keyboard.. > If that's not feasible, or if it's just easier, you may be able to use > the DDB scripting facility + textdumps to run DDB commands > automatically on panic to produce useful debugging output. Take a look > at the textdump(4) man page for details. This can be combined with a > traditional crashdump to capture both DDB output and normal dump data > for use with kgdb. jeah, I readed the man (ddb and textdump), and I used a small script.. > > Robert > thanks for the help >> >> //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 >>>> >>>> " >>>> >>> >> > > From owner-freebsd-stable@FreeBSD.ORG Sun Jul 12 23:36: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 E954C10656C4 for ; Sun, 12 Jul 2009 23:36:58 +0000 (UTC) (envelope-from rebotados@exemys.com) Received: from web.hostmailing.com (web.hostmailing.com [200.110.145.34]) by mx1.freebsd.org (Postfix) with ESMTP id 948818FC08 for ; Sun, 12 Jul 2009 23:36:57 +0000 (UTC) (envelope-from rebotados@exemys.com) Received: from web.hostmailing.com ([200.110.145.34] helo=www.hostmailing.com) by web.hostmailing.com with esmtpa (Exim 4.63) (envelope-from ) id 1MQ8ZU-0003Rc-5O for freebsd-stable@freebsd.org; Sun, 12 Jul 2009 20:35:04 -0300 Date: Sun, 12 Jul 2009 20:35:04 -0300 To: freebsd-stable@freebsd.org From: Mkt-Exemys Message-ID: X-Priority: 3 X-Mailer: wh4535 [version 3.1] MIME-Version: 1.0 Content-Type: text/plain; charset = "iso-8859-1" Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Industrial Intelligent Wi-Fi (I2W) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: exemys-mkt@exemys.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jul 2009 23:36:59 -0000 This is a message in multipart MIME format. Your mail client should not be displaying this. Consider upgrading your mail client to view this message correctly. From owner-freebsd-stable@FreeBSD.ORG Mon Jul 13 05:23: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 8608B106564A for ; Mon, 13 Jul 2009 05:23:03 +0000 (UTC) (envelope-from grarpamp@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 18E028FC1C for ; Mon, 13 Jul 2009 05:23:02 +0000 (UTC) (envelope-from grarpamp@gmail.com) Received: by fxm24 with SMTP id 24so1664508fxm.43 for ; Sun, 12 Jul 2009 22:23:02 -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=eN2Hxkk+Dmk7zfroDgQ49DdESRZSEEd3qFdST3fKrwk=; b=JBbLM5iHhHRCvl3viPEZ0XlwCCg0jVM/rCJXRf6C/1VCc9wqLq4NNbIMzOw7/HmJNk jKtEWAJYUD5NM0cF2S/GS3jUK22jdcwoNF5/dyqIbfsCFS4sXDS1nN9XgEUFynFfmFuu TcJcE0UzB5UN8xVJvapgN2Dlkq9/5DhKyY510= 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=qybHjNmJ+UKTb5s94f1nWxt9UHJskeEDCQgBWafewHCY2ApuqhZP6/G2lrabu9V5Xh jTANlbnXnie2VE5mpPm4C2PDhyyzlE10Zx61ppHBwpdUIDr1jLm9yoLgBjfv3k3NeXkF UDEJP1PqRatKmpRC6KX6zy0n5OmZox2StgRV0= MIME-Version: 1.0 Received: by 10.204.57.67 with SMTP id b3mr4775487bkh.99.1247460919434; Sun, 12 Jul 2009 21:55:19 -0700 (PDT) Date: Mon, 13 Jul 2009 00:55:19 -0400 Message-ID: From: grarpamp To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: FreeBSD RoadMap 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, 13 Jul 2009 05:23:03 -0000 Is there a general roadmap of what's planned for future major releases? I don't mean minor stuff like driver or contributed version bumps. But bigger, or just plain cool things, like as SMP, soft updates, ZFS, netgraph, pf, etc, were in the past. I poked around the website and wiki a bit and didn't see any sort of all in one document. Some sort of dynamic non-binding wiki doc with direction or work as to how the next two [or 3] majors after the current one [8] would be interesting. And could be used by those looking at investing in FreeBSD as a future or continuing platform. Certainly core/committers have thoughts on this that are publishable. Something so people can see where all the projects fit into the whole. From owner-freebsd-stable@FreeBSD.ORG Mon Jul 13 07:55: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 E89D5106566C for ; Mon, 13 Jul 2009 07:55:34 +0000 (UTC) (envelope-from andrew@areilly.bpa.nu) Received: from nskntmtas01p.mx.bigpond.com (nskntmtas01p.mx.bigpond.com [61.9.168.137]) by mx1.freebsd.org (Postfix) with ESMTP id 745888FC0A for ; Mon, 13 Jul 2009 07:55:33 +0000 (UTC) (envelope-from andrew@areilly.bpa.nu) Received: from nskntotgx02p.mx.bigpond.com ([124.188.162.219]) by nskntmtas01p.mx.bigpond.com with ESMTP id <20090713075532.LJPO1860.nskntmtas01p.mx.bigpond.com@nskntotgx02p.mx.bigpond.com> for ; Mon, 13 Jul 2009 07:55:32 +0000 Received: from areilly.bpa.nu ([124.188.162.219]) by nskntotgx02p.mx.bigpond.com with ESMTP id <20090713075532.XFYM1990.nskntotgx02p.mx.bigpond.com@areilly.bpa.nu> for ; Mon, 13 Jul 2009 07:55:32 +0000 Received: (qmail 12238 invoked by uid 501); 13 Jul 2009 07:55:27 -0000 Date: Mon, 13 Jul 2009 17:55:27 +1000 From: Andrew Reilly To: grarpamp Message-ID: <20090713075527.GA11259@duncan.reilly.home> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-RPD-ScanID: Class unknown; VirusThreatLevel unknown, RefID str=0001.0A150205.4A5AE874.0069,ss=1,fgs=0 X-SIH-MSG-ID: rxw1GN37TAD0zmQv0WC2OwcnyAzlq3Mv8Z4QX81loRIGTUDBp8PfStreLP1Ru8u6xD9PJhqCNGQlaa/mTY3RstCK Cc: freebsd-stable@freebsd.org Subject: Re: FreeBSD RoadMap 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, 13 Jul 2009 07:55:35 -0000 On Mon, Jul 13, 2009 at 12:55:19AM -0400, grarpamp wrote: > Is there a general roadmap of what's planned > for future major releases? I don't mean minor > stuff like driver or contributed version bumps. > But bigger, or just plain cool things, like as SMP, > soft updates, ZFS, netgraph, pf, etc, were in the past. I doubt that there's much "big" in the ambit of "Unix-like OS" that isn't already in the 8-current series. In a project like FreeBSD, "what's in the roadmap" equates pretty closely with "what are the developers working on", and that is summarised in the quarterly status reports, such as this one: http://www.freebsd.org/news/status/report-2009-01-2009-03.html As for when any of this will "hit the tree" and find its way into a release, that's very much a "how long is a piece of string" sort of question; not really the way FreeBSD works. Particularly since it moved to a calendar-based release schedule. IMO, YMMV, i-do-not-speak-for-freebsd, etc. Cheers, -- Andrew From owner-freebsd-stable@FreeBSD.ORG Mon Jul 13 11:19: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 1775E106564A for ; Mon, 13 Jul 2009 11:19:34 +0000 (UTC) (envelope-from pluknet@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 9870D8FC1B for ; Mon, 13 Jul 2009 11:19:33 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: by fxm24 with SMTP id 24so1803443fxm.43 for ; Mon, 13 Jul 2009 04:19:32 -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=rS1bu0f6gOXWwg9JK85JWNpAumSL+9MmymhWgEb5/6k=; b=giXUcVeFyUNMZPfCcF+Eho75IP+b7+mjctqm69xwsjGDAs7Au4dzkqhcPjXJUNRVYr xfDIuoEV4aHF3Uz+6bTj4hAju3cVTp8Z+kphdgivkBM8y9BHqLJy5OhHNakJcYhE4bDI mHf1oSSmYzu5zmGSmSMQIy4Dw2INUhk1QWyUg= 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=brBhZcq3ungBJVl8fkCFbQurkvv2hqAEQRJn6dOFg+Yekk+DgMk88BMwk1TLjOLJug aw7iA5tIke2vuYt0brqYHseZj0d3S66wF2ya0g1VfW5hm0Q+d0DBQZAycI6FyZQYtTra ovCeoHK7J5uzkLhga5PtBw7uXK3u4l7BnjJB4= MIME-Version: 1.0 Received: by 10.204.57.138 with SMTP id c10mr104120bkh.56.1247483972424; Mon, 13 Jul 2009 04:19:32 -0700 (PDT) Date: Mon, 13 Jul 2009 15:19:32 +0400 Message-ID: From: pluknet To: freebsd-stable Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [quota] quotacheck wont go with geom_label 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, 13 Jul 2009 11:19:34 -0000 Hi. I found that a file system mounted through /dev/label/name doesn't work with quotacheck. It turned out that quotacheck after looking at fstab tries to open /dev/label/name and then receives EPERM (6.2, 7.2), while it works fine with ordinary device-mounted file systems. Is there a fix? Should I file a PR? -- wbr, pluknet From owner-freebsd-stable@FreeBSD.ORG Mon Jul 13 13:30:48 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 1C66310656F9 for ; Mon, 13 Jul 2009 13:30:48 +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 8521C8FC21 for ; Mon, 13 Jul 2009 13:30:47 +0000 (UTC) (envelope-from oliver.pntr@gmail.com) Received: by bwz21 with SMTP id 21so1853353bwz.43 for ; Mon, 13 Jul 2009 06:30:46 -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=DS0jPt5wcgsHeVunB8RDKoTzVSPGtQAFEJ4GVAn7qpk=; b=nls7kGswcBjcENodYc1DKCmnUcuqp+CEH2ijaCRrWbK7Na/t2G3fUNK18zAz9zw3oH hJeAKLIIVReaXAkoUfVWVWIMi0jO3tpF/atkcmW7HRkkr7JXizhh8bciBJoZnxsrmq+h C0cqn2yiJtaDew3UzQjSFRupFRZif1ROCRzkQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=UzUg+ghtjmLE+B5VU38z2XQlVNDZxRZnq8/vrgFFTYVPJNzyXQfW7TGfBpk9+58oQ2 gZzc5yo5tN/DiZfDdRVoSZbUaZf7rue4gh+GHvs/+MwCRctKXtOKIBR94lDC2jvaDsIk Nrnxion0VRCBN/nv3ejGGU0PiBhIOcJUMUQrQ= MIME-Version: 1.0 Received: by 10.103.174.18 with SMTP id b18mr2587806mup.129.1247490003239; Mon, 13 Jul 2009 06:00:03 -0700 (PDT) Date: Mon, 13 Jul 2009 15:00:03 +0200 Message-ID: <6101e8c40907130600j528bd4d5ue348563e89c7ffa3@mail.gmail.com> From: Oliver Pinter To: stable@freebsd.org Content-Type: multipart/mixed; boundary=0016e6587a0c810307046e95e600 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: ZFS, unionfs - Operation not supported 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, 13 Jul 2009 13:30:48 -0000 --0016e6587a0c810307046e95e600 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi all! It is the problematic FS: zpower on /mnt/zpower (zfs, local) /usr/src on /mnt/zpower/jail/default/ports (nullfs, local) and the failed command: mount_unionfs -o below /mnt/zpower/jail/default/ports/ /mnt/zpower/jail/www/usr/ports/ (truss mount_unionfs -o below /mnt/zpower/jail/default/ports/ /mnt/zpower/jail/www/usr/ports/ ) > & /tmp/unionfs.log Have I any chance, to unionmount ZFS with UFS or ZFS not supported this operations? --0016e6587a0c810307046e95e600-- From owner-freebsd-stable@FreeBSD.ORG Mon Jul 13 15:25: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 1B24F106564A for ; Mon, 13 Jul 2009 15:25:50 +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 BD73C8FC0C for ; Mon, 13 Jul 2009 15:25:49 +0000 (UTC) (envelope-from sagara@tomahawk.com.sg) Received: (qmail 31804 invoked by alias); 13 Jul 2009 12:07:32 -0000 Message-ID: <20090713120732.31803.qmail@us1.tomahawkonline.net> From: "Sagara Wijetunga" To: freebsd-stable@freebsd.org Date: Mon, 13 Jul 2009 07:07:32 -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: nsouch@freebsd.org, bishop@rr.iij4u.or.jp, n_hibma@freebsd.org Subject: FreeBSD 7.2 USB stack info needed 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, 13 Jul 2009 15:25:50 -0000 Hi FreeBSD community After an USB thumb drive id pluged in, the devd prints following line: +umass0 vendor=0x0781 product=0x5406 devclass=0x00 devsubclass=0x00 release=0x0200 sernum="087663165D8139E6" intclass=0x08 intsubclass=0x06 at port=0 interface=0 vendor=0x0781 product=0x5406 devclass=0x00 devsubclass=0x00 release=0x0200 sernum="087663165D8139E6" intclass=0x08 intsubclass=0x06 on uhub4 1. Could I know which exact program print above line on /dev/devctl ? 2. I want to print another line with "daN" as the device-name, where N is 0 to 9, with minimum vendor and product ids once the allocated device-name is known for USB Mass Storage devices. Your additional ideas/feedback/help is most welcomed. Kind regards Sagara From owner-freebsd-stable@FreeBSD.ORG Mon Jul 13 16:39: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 7E1FE106564A for ; Mon, 13 Jul 2009 16:39:27 +0000 (UTC) (envelope-from uqs@spoerlein.net) Received: from acme.spoerlein.net (cl-43.dus-01.de.sixxs.net [IPv6:2a01:198:200:2a::2]) by mx1.freebsd.org (Postfix) with ESMTP id 0D0CD8FC16 for ; Mon, 13 Jul 2009 16:39:26 +0000 (UTC) (envelope-from uqs@spoerlein.net) Received: from acme.spoerlein.net (localhost.spoerlein.net [127.0.0.1]) by acme.spoerlein.net (8.14.3/8.14.3) with ESMTP id n6DGdMYC075461 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Jul 2009 18:39:23 +0200 (CEST) (envelope-from uqs@spoerlein.net) Received: (from uqs@localhost) by acme.spoerlein.net (8.14.3/8.14.3/Submit) id n6DGdMpG075460; Mon, 13 Jul 2009 18:39:22 +0200 (CEST) (envelope-from uqs@spoerlein.net) Date: Mon, 13 Jul 2009 18:39:22 +0200 From: Ulrich =?utf-8?B?U3DDtnJsZWlu?= To: Dominic Fandrey Message-ID: <20090713163922.GM2145@acme.spoerlein.net> Mail-Followup-To: Dominic Fandrey , freebsd-stable@freebsd.org References: <4A4DC67C.3010804@bsdforen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4A4DC67C.3010804@bsdforen.de> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-stable@freebsd.org Subject: Re: mergemaster merge left/right 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, 13 Jul 2009 16:39:27 -0000 On Fri, 03.07.2009 at 10:51:08 +0200, Dominic Fandrey wrote: > I'd really like mergemaster to tell me whether the left > or the right side is the new file. > > # $FreeBSD: src/etc/devd.conf,v 1.38. | # $FreeBSD: src/etc/devd.conf,v 1.38. > > Like this I have no idea which one to pick. When using X, maximize your xterm horizontally and use mergemaster -w100 or something like that. It will probe the tty again and offer the "real" width, so I usually just run mergemaster -w1 and hit enter. hth, Ulrich Spörlein From owner-freebsd-stable@FreeBSD.ORG Mon Jul 13 16:57: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 28705106564A for ; Mon, 13 Jul 2009 16:57:20 +0000 (UTC) (envelope-from uqs@spoerlein.net) Received: from acme.spoerlein.net (cl-43.dus-01.de.sixxs.net [IPv6:2a01:198:200:2a::2]) by mx1.freebsd.org (Postfix) with ESMTP id AC41F8FC14 for ; Mon, 13 Jul 2009 16:57:19 +0000 (UTC) (envelope-from uqs@spoerlein.net) Received: from acme.spoerlein.net (localhost.spoerlein.net [127.0.0.1]) by acme.spoerlein.net (8.14.3/8.14.3) with ESMTP id n6DGvIjn076246 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Jul 2009 18:57:18 +0200 (CEST) (envelope-from uqs@spoerlein.net) Received: (from uqs@localhost) by acme.spoerlein.net (8.14.3/8.14.3/Submit) id n6DGvIqN076245; Mon, 13 Jul 2009 18:57:18 +0200 (CEST) (envelope-from uqs@spoerlein.net) Date: Mon, 13 Jul 2009 18:57:17 +0200 From: Ulrich =?utf-8?B?U3DDtnJsZWlu?= To: Vlad Galu Message-ID: <20090713165717.GN2145@acme.spoerlein.net> Mail-Followup-To: Vlad Galu , freebsd-stable@freebsd.org References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-stable@freebsd.org Subject: Re: 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: Mon, 13 Jul 2009 16:57:20 -0000 On Thu, 09.07.2009 at 16:13:25 +0300, Vlad Galu wrote: > 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. Just a me too. This is most likely because nscd is also caching negative lookups. The usual workaround would be to restart it using /etc/rc.d/nscd restart Cheers, Ulrich Spörlein From owner-freebsd-stable@FreeBSD.ORG Mon Jul 13 17:28: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 B2D8F1065672 for ; Mon, 13 Jul 2009 17:28:14 +0000 (UTC) (envelope-from mike@jellydonut.org) Received: from mail-fx0-f224.google.com (mail-fx0-f224.google.com [209.85.220.224]) by mx1.freebsd.org (Postfix) with ESMTP id 513028FC08 for ; Mon, 13 Jul 2009 17:28:13 +0000 (UTC) (envelope-from mike@jellydonut.org) Received: by fxm24 with SMTP id 24so2024614fxm.43 for ; Mon, 13 Jul 2009 10:28:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.107.9 with SMTP id z9mr2292731fao.1.1247506093237; Mon, 13 Jul 2009 10:28:13 -0700 (PDT) In-Reply-To: <20090713165717.GN2145@acme.spoerlein.net> References: <20090713165717.GN2145@acme.spoerlein.net> Date: Mon, 13 Jul 2009 13:28:13 -0400 Message-ID: <1de79840907131028n5b8f21deyd968639732c651a4@mail.gmail.com> From: Michael Proto To: Vlad Galu , freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Subject: Re: 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: Mon, 13 Jul 2009 17:28:14 -0000 On Mon, Jul 13, 2009 at 12:57 PM, Ulrich Sp=F6rlein wrot= e: > On Thu, 09.07.2009 at 16:13:25 +0300, Vlad Galu wrote: >> 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 pgsq= l -g 70 >> pw: group disappeared during update >> [root@vgalu /usr/ports/databases/postgresql84-server]# pw group add pgsq= l -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. > > Just a me too. This is most likely because nscd is also caching negative > lookups. The usual workaround would be to restart it using > /etc/rc.d/nscd restart > A slightly lower-impact alternative would be to use "nscd -i passwd" to invalidate the password cache. -Proto From owner-freebsd-stable@FreeBSD.ORG Mon Jul 13 17:43: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 DD3A11065670 for ; Mon, 13 Jul 2009 17:43:52 +0000 (UTC) (envelope-from mcdouga9@egr.msu.edu) Received: from mx.egr.msu.edu (surfnturf.egr.msu.edu [35.9.37.164]) by mx1.freebsd.org (Postfix) with ESMTP id B01958FC17 for ; Mon, 13 Jul 2009 17:43:52 +0000 (UTC) (envelope-from mcdouga9@egr.msu.edu) Received: from localhost (localhost [127.0.0.1]) by mx.egr.msu.edu (Postfix) with ESMTP id C71EB57548; Mon, 13 Jul 2009 13:43:51 -0400 (EDT) X-Virus-Scanned: amavisd-new at egr.msu.edu Received: from mx.egr.msu.edu ([127.0.0.1]) by localhost (surfnturf.egr.msu.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ShLKVvCgGJ1r; Mon, 13 Jul 2009 13:43:51 -0400 (EDT) Received: from [35.9.44.65] (daemon.egr.msu.edu [35.9.44.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: mcdouga9) by mx.egr.msu.edu (Postfix) with ESMTPSA id 5638E57542; Mon, 13 Jul 2009 13:43:51 -0400 (EDT) Message-ID: <4A5B7257.1010202@egr.msu.edu> Date: Mon, 13 Jul 2009 13:43:51 -0400 From: Adam McDougall User-Agent: Thunderbird 2.0.0.22 (X11/20090625) MIME-Version: 1.0 To: Michael Proto References: <20090713165717.GN2145@acme.spoerlein.net> <1de79840907131028n5b8f21deyd968639732c651a4@mail.gmail.com> In-Reply-To: <1de79840907131028n5b8f21deyd968639732c651a4@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Vlad Galu , freebsd-stable@freebsd.org Subject: Re: 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: Mon, 13 Jul 2009 17:43:53 -0000 Michael Proto wrote: > On Mon, Jul 13, 2009 at 12:57 PM, Ulrich Spörlein wrote: > >> On Thu, 09.07.2009 at 16:13:25 +0300, Vlad Galu wrote: >> >>> 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. >>> >> Just a me too. This is most likely because nscd is also caching negative >> lookups. The usual workaround would be to restart it using >> /etc/rc.d/nscd restart >> >> > > A slightly lower-impact alternative would be to use "nscd -i passwd" > to invalidate the password cache. > > > -Proto > _______________________________________________ > I was intending to report this soon as well (its been on my list for a while) as a problematic issue while installing ports. The other issue I had was Java would crash immediately if I had nscd running (configured to cache YP). I plan to report that soon if it still happens with 1.6. I probably tested with 1.4 or 1.5. From owner-freebsd-stable@FreeBSD.ORG Mon Jul 13 18:51: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 38FD4106566C for ; Mon, 13 Jul 2009 18:51:55 +0000 (UTC) (envelope-from masoom.shaikh@gmail.com) Received: from mail-vw0-f172.google.com (mail-vw0-f172.google.com [209.85.212.172]) by mx1.freebsd.org (Postfix) with ESMTP id DDBE98FC16 for ; Mon, 13 Jul 2009 18:51:54 +0000 (UTC) (envelope-from masoom.shaikh@gmail.com) Received: by vwj2 with SMTP id 2so2080025vwj.3 for ; Mon, 13 Jul 2009 11:51: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:cc:content-type; bh=2pYjCM5UmFc3VDFR4JBoU3tspM95uVA1ZzYGUkE6ZpY=; b=RybvuWpqyvFb6waOkGUwhsExYKVFOsCVYdJ2pB5QhKm0Bw1Utk0wrlTGBh/cD+R8LY cAJDMWY5qLo5bgoELqme/4OUkZQ0YQdyLllOejZNQKKtRKehf/cSi+/6wt0hSC/D/neY DrgnP4JYoYfjgtht9SdhAQz7Suq7nex/oLBnw= 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=F90EcuqCdceqwa+zwA9gU++/wajCx3vLvJzbT97d3dJmwUg4ziTWLqBdiGxuXtuKKQ k7OlkbhAKH3Lfyqk+nhG1AbpTejjCp6mS7CyP5bOJXEbD+82M+7PAXkzWjb5NkASJsOD 5rPl87KzKc6WuG5f58vouNxA++qSDSuENtt/Q= MIME-Version: 1.0 Received: by 10.220.80.134 with SMTP id t6mr7522100vck.108.1247509574877; Mon, 13 Jul 2009 11:26:14 -0700 (PDT) In-Reply-To: <20090713075527.GA11259@duncan.reilly.home> References: <20090713075527.GA11259@duncan.reilly.home> Date: Mon, 13 Jul 2009 18:26:14 +0000 Message-ID: From: Masoom Shaikh To: Andrew Reilly Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org, grarpamp Subject: Re: FreeBSD RoadMap 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, 13 Jul 2009 18:51:55 -0000 can this help ? http://ivoras.sharanet.org/freebsd/freebsd8.html On Mon, Jul 13, 2009 at 7:55 AM, Andrew Reilly < andrew-freebsd@areilly.bpc-users.org> wrote: > On Mon, Jul 13, 2009 at 12:55:19AM -0400, grarpamp wrote: > > Is there a general roadmap of what's planned > > for future major releases? I don't mean minor > > stuff like driver or contributed version bumps. > > But bigger, or just plain cool things, like as SMP, > > soft updates, ZFS, netgraph, pf, etc, were in the past. > > I doubt that there's much "big" in the ambit of "Unix-like OS" > that isn't already in the 8-current series. > > In a project like FreeBSD, "what's in the roadmap" equates > pretty closely with "what are the developers working on", and > that is summarised in the quarterly status reports, such as this > one: > http://www.freebsd.org/news/status/report-2009-01-2009-03.html > > As for when any of this will "hit the tree" and find its way > into a release, that's very much a "how long is a piece of > string" sort of question; not really the way FreeBSD works. > Particularly since it moved to a calendar-based release > schedule. > > IMO, YMMV, i-do-not-speak-for-freebsd, etc. > > Cheers, > > -- > Andrew > _______________________________________________ > 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 13 19:26: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 4BB211065678 for ; Mon, 13 Jul 2009 19:26:30 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id ED8B08FC23 for ; Mon, 13 Jul 2009 19:26:28 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 814AC46B2A; Mon, 13 Jul 2009 15:26:28 -0400 (EDT) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 825198A096; Mon, 13 Jul 2009 15:26:27 -0400 (EDT) From: John Baldwin To: freebsd-stable@freebsd.org Date: Mon, 13 Jul 2009 15:15:58 -0400 User-Agent: KMail/1.9.7 References: <20090703100627.197838cphjnil82s@10.248.192.16> <20090706200115.1411150frxepkbuo@webmail.private.lan> <20090707105103.946813hdks2mra80@10.248.192.16> In-Reply-To: <20090707105103.946813hdks2mra80@10.248.192.16> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200907131515.59195.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Mon, 13 Jul 2009 15:26:27 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: 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, 13 Jul 2009 19:26:33 -0000 On Tuesday 07 July 2009 5:51:03 am Ian J Hart wrote: > 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. > >> > >> > > 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 This one does look like a hardware issue from the stack trace. It's hard to know if the first panic you saw was a hardware issue as well without the stack trace information. > #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 -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Mon Jul 13 19:28:29 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 7AE911065700 for ; Mon, 13 Jul 2009 19:28:29 +0000 (UTC) (envelope-from bounces4s@donateshoes.org) Received: from mail.donateshoes.org (mail.donateshoes.org [75.146.12.233]) by mx1.freebsd.org (Postfix) with ESMTP id 38F3D8FC1D for ; Mon, 13 Jul 2009 19:28:29 +0000 (UTC) (envelope-from bounces4s@donateshoes.org) Received: from 192.168.112.30 [192.168.112.30] by mail.donateshoes.org with ESMTP (SMTPD-11.0) id 025a00000823a546; Mon, 13 Jul 2009 10:22:38 -0500 From: "Soles4Souls and Nine West" To: stable@freebsd.org Message-Id: <20090713102238.783555046@donateshoes.org> Date: Mon, 13 Jul 2009 10:22:38 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Introducing the Vintage America Collection with Nine West Benefitting Soles4Souls X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: marketing@donateshoes.org List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2009 19:28:30 -0000 Introducing the Vintage America Collection with Nine West Benefitting Soles4Souls From owner-freebsd-stable@FreeBSD.ORG Mon Jul 13 19:50: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 422E2106566B for ; Mon, 13 Jul 2009 19:50:18 +0000 (UTC) (envelope-from wolfgang@lyxys.ka.sub.org) Received: from saturn.lyxys.ka.sub.org (saturn.lyxys.ka.sub.org [217.29.35.151]) by mx1.freebsd.org (Postfix) with ESMTP id B1BC38FC14 for ; Mon, 13 Jul 2009 19:50:17 +0000 (UTC) (envelope-from wolfgang@lyxys.ka.sub.org) Received: from juno.lyxys.ka.sub.org (juno.lyxys.ka.sub.org [IPv6:2001:5c0:8521:0:20f:feff:fe0e:7312]) by saturn.lyxys.ka.sub.org (8.14.2/8.14.2) with ESMTP id n6DJd4pL089900 for ; Mon, 13 Jul 2009 21:39:04 +0200 (CEST) (envelope-from wolfgang@lyxys.ka.sub.org) Received: from juno.lyxys.ka.sub.org (localhost [127.0.0.1]) by juno.lyxys.ka.sub.org (8.14.3/8.14.3) with ESMTP id n6DJd4n3049938 for ; Mon, 13 Jul 2009 21:39:04 +0200 (CEST) (envelope-from wolfgang@lyxys.ka.sub.org) Received: (from wolfgang@localhost) by juno.lyxys.ka.sub.org (8.14.3/8.14.3/Submit) id n6DJd3bf049937 for freebsd-stable@freebsd.org; Mon, 13 Jul 2009 21:39:03 +0200 (CEST) (envelope-from wolfgang@lyxys.ka.sub.org) X-Authentication-Warning: juno.lyxys.ka.sub.org: wolfgang set sender to wolfgang@lyxys.ka.sub.org using -f Date: Mon, 13 Jul 2009 21:39:03 +0200 From: Wolfgang Zenker To: freebsd-stable@freebsd.org Message-ID: <20090713193903.GA49591@lyxys.ka.sub.org> References: <20090713075527.GA11259@duncan.reilly.home> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Organization: private site Subject: Re: FreeBSD RoadMap 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, 13 Jul 2009 19:50:18 -0000 * Masoom Shaikh [090713 20:26]: > On Mon, Jul 13, 2009 at 7:55 AM, Andrew Reilly wrote: >> On Mon, Jul 13, 2009 at 12:55:19AM -0400, grarpamp wrote: >>> Is there a general roadmap of what's planned >>> for future major releases? I don't mean minor >>> stuff like driver or contributed version bumps. >>> But bigger, or just plain cool things, like as SMP, >>> soft updates, ZFS, netgraph, pf, etc, were in the past. >> I doubt that there's much "big" in the ambit of "Unix-like OS" >> that isn't already in the 8-current series. >> In a project like FreeBSD, "what's in the roadmap" equates >> pretty closely with "what are the developers working on", and >> that is summarised in the quarterly status reports, such as this >> one: >> http://www.freebsd.org/news/status/report-2009-01-2009-03.html >> As for when any of this will "hit the tree" and find its way >> into a release, that's very much a "how long is a piece of >> string" sort of question; not really the way FreeBSD works. >> Particularly since it moved to a calendar-based release >> schedule. >> IMO, YMMV, i-do-not-speak-for-freebsd, etc. > can this help ? > http://ivoras.sharanet.org/freebsd/freebsd8.html or you could visit this years eurobsdcon and listen to http://www.ukuug.org/events/eurobsdcon2009/talks/#mckusick :-) From owner-freebsd-stable@FreeBSD.ORG Mon Jul 13 23:24: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 31AAA106566C for ; Mon, 13 Jul 2009 23:24:40 +0000 (UTC) (envelope-from graham@menhennitt.com.au) Received: from hapkido.dreamhost.com (hapkido.dreamhost.com [66.33.216.122]) by mx1.freebsd.org (Postfix) with ESMTP id 158BF8FC1A for ; Mon, 13 Jul 2009 23:24:39 +0000 (UTC) (envelope-from graham@menhennitt.com.au) Received: from friskymail-a4.g.dreamhost.com (caibbdcaaaaf.dreamhost.com [208.113.200.5]) by hapkido.dreamhost.com (Postfix) with ESMTP id 6C951179768 for ; Mon, 13 Jul 2009 16:03:56 -0700 (PDT) Received: from [127.0.0.1] (c220-239-199-115.chirn1.vic.optusnet.com.au [220.239.199.115]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by friskymail-a4.g.dreamhost.com (Postfix) with ESMTP id 2EADD121CE7 for ; Mon, 13 Jul 2009 16:03:54 -0700 (PDT) Message-ID: <4A5BBD50.2020408@menhennitt.com.au> Date: Tue, 14 Jul 2009 09:03:44 +1000 From: Graham Menhennitt 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 Cc: Subject: problem with Soekris net5501 and USB hub 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, 13 Jul 2009 23:24:40 -0000 I originally sent this to the Soekris list thinking it was platform specific. I got a couple of replies suggesting that it's a FreeBSD problem instead. So, if anybody can offer any insights, I would most appreciate it. I have a Soekris net5501 running FreeBSD 7-Stable. I want to connect a number of USB devices to it: - a HP Laserjet 1020 printer - an APC Back UPS 350 UPS - a 6-in-one card reader (not so fussed about this one). The Soekris box has only one USB port brought out to a connector on the case, so rather than mod the box to add another port, I thought I would just use an external hub. If I plug any of the devcies directly into the Soekris's USB port it works fine. However, if I use a USB hub then it doesn't work at all. I've tried it with two different hubs and two different cables. I've tried the hubs both with a plug pack, and being powered from the USB bus. The only thing common to the failures is the Soefkis and freeBSD. The hubs are both USB 2.0 according to their advertising. The hub itself is recognised (although I don't have the output from usbdevs available at the moment). The UPS doesn't ever seem to be recognised when connected via the hub - there's nothing in dmesg and nothing in usbdevs. Ditto for the 6-in-one card reader - the LED on the front of it doesn't even light up. The printer sometimes gets partially recognised. The output from "usbdevs -v" when the printer is connected directly and working properly looks like: Controller /dev/usb0: addr 1: full speed, self powered, config 1, OHCI root hub(0x0000), AMD(0x0000), rev 1.00 port 1 powered port 2 powered port 3 powered port 4 powered Controller /dev/usb1: addr 1: high speed, self powered, config 1, EHCI root hub(0x0000), AMD(0x0000), rev 1.00 port 1 addr 2: high speed, self powered, config 1, HP LaserJet 1020(0x2b17), Hewlett-Packard(0x03f0), rev 1.00 port 2 powered port 3 powered port 4 powered However, if I connect it via the hub, it sometimes doesn't show it at all, while other times it says something like (doing this from memory): port 1 addr 2: high speed, self powered, config 1, 0x2b17(0x2b17), vendor 0x03f0(0x03f0), rev 1.00 So, it can see it but it doesn't resolve the vendor or device ids. It looks like the Soekris can see whatever is directly connected to it, but can't (reliably) see things that more than one step away. My (custom) kernel has: device usb # USB Bus (required) device umass # Disks/Mass storage - Requires scbus and da device scbus # SCSI bus (required for SCSI) device da # Direct Access (disks) device uhci # UHCI PCI->USB interface device ohci # OHCI PCI->USB interface device ehci # EHCI PCI->USB interface (USB 2.0) device ugen # Generic So, does anybody have any ideas about how to fix this. Thanks for any help, Graham From owner-freebsd-stable@FreeBSD.ORG Mon Jul 13 23:43: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 0DA93106564A for ; Mon, 13 Jul 2009 23:43:27 +0000 (UTC) (envelope-from pprocacci@datapipe.net) Received: from que31.charter.net (que31.charter.net [209.225.8.23]) by mx1.freebsd.org (Postfix) with ESMTP id C49D28FC0A for ; Mon, 13 Jul 2009 23:43:26 +0000 (UTC) (envelope-from pprocacci@datapipe.net) Received: from imp10 ([10.20.200.10]) by mta11.charter.net (InterMail vM.7.09.01.00 201-2219-108-20080618) with ESMTP id <20090713232938.WWCW22327.mta11.charter.net@imp10>; Mon, 13 Jul 2009 19:29:38 -0400 Received: from beast.myhome ([75.138.242.5]) by imp10 with smtp.charter.net id FbVd1c00T07hwzv05bVeBn; Mon, 13 Jul 2009 19:29:38 -0400 Message-ID: <4A5BC379.7040004@datapipe.net> Date: Mon, 13 Jul 2009 18:30:01 -0500 From: "Paul A. Procacci" User-Agent: Thunderbird 2.0.0.22 (X11/20090711) MIME-Version: 1.0 To: Graham Menhennitt References: <4A5BBD50.2020408@menhennitt.com.au> In-Reply-To: <4A5BBD50.2020408@menhennitt.com.au> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-stable@FreeBSD.ORG" Subject: Re: problem with Soekris net5501 and USB hub 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, 13 Jul 2009 23:43:27 -0000 Hello, I recently (just yesterday) had a similar problem with 7-STABLE not being able to detect devices attached to a hub. I immediately upgraded to 8-BETA1 and the problem is gone, though I've run into a number of other issues unrelated to usb devices. The sokeris will more than likely fair better on FBSD 8 than my multipurpose machine, but it may be worth a try. ~Paul Graham Menhennitt wrote: > I originally sent this to the Soekris list thinking it was platform > specific. I got a couple of replies suggesting that it's a FreeBSD > problem instead. So, if anybody can offer any insights, I would most > appreciate it. > > I have a Soekris net5501 running FreeBSD 7-Stable. I want to connect a > number of USB devices to it: > - a HP Laserjet 1020 printer > - an APC Back UPS 350 UPS > - a 6-in-one card reader (not so fussed about this one). > The Soekris box has only one USB port brought out to a connector on the > case, so rather than mod the box to add another port, I thought I would > just use an external hub. > > If I plug any of the devcies directly into the Soekris's USB port it > works fine. However, if I use a USB hub then it doesn't work at all. > I've tried it with two different hubs and two different cables. I've > tried the hubs both with a plug pack, and being powered from the USB > bus. The only thing common to the failures is the Soefkis and freeBSD. > The hubs are both USB 2.0 according to their advertising. > > The hub itself is recognised (although I don't have the output from > usbdevs available at the moment). The UPS doesn't ever seem to be > recognised when connected via the hub - there's nothing in dmesg and > nothing in usbdevs. Ditto for the 6-in-one card reader - the LED on the > front of it doesn't even light up. > > The printer sometimes gets partially recognised. The output from > "usbdevs -v" when the printer is connected directly and working properly > looks like: > > Controller /dev/usb0: > addr 1: full speed, self powered, config 1, OHCI root hub(0x0000), > AMD(0x0000), rev 1.00 > port 1 powered > port 2 powered > port 3 powered > port 4 powered > Controller /dev/usb1: > addr 1: high speed, self powered, config 1, EHCI root hub(0x0000), > AMD(0x0000), rev 1.00 > port 1 addr 2: high speed, self powered, config 1, HP LaserJet > 1020(0x2b17), Hewlett-Packard(0x03f0), rev 1.00 > port 2 powered > port 3 powered > port 4 powered > > However, if I connect it via the hub, it sometimes doesn't show it at > all, while other times it says something like (doing this from memory): > > port 1 addr 2: high speed, self powered, config 1, 0x2b17(0x2b17), > vendor 0x03f0(0x03f0), rev 1.00 > > So, it can see it but it doesn't resolve the vendor or device ids. It > looks like the Soekris can see whatever is directly connected to it, but > can't (reliably) see things that more than one step away. > > My (custom) kernel has: > > device usb # USB Bus (required) > device umass # Disks/Mass storage - Requires > scbus and da > device scbus # SCSI bus (required for SCSI) > device da # Direct Access (disks) > device uhci # UHCI PCI->USB interface > device ohci # OHCI PCI->USB interface > device ehci # EHCI PCI->USB interface (USB 2.0) > device ugen # Generic > > So, does anybody have any ideas about how to fix this. > > Thanks for any help, > Graham > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From owner-freebsd-stable@FreeBSD.ORG Tue Jul 14 04:33: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 2F0CA1065689 for ; Tue, 14 Jul 2009 04:33:55 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with ESMTP id CD2708FC13 for ; Tue, 14 Jul 2009 04:33:52 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: (qmail 16062 invoked by uid 399); 14 Jul 2009 04:33:49 -0000 Received: from localhost (HELO ?192.168.0.100?) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 14 Jul 2009 04:33:49 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4A5C0AAF.1090604@FreeBSD.org> Date: Mon, 13 Jul 2009 21:33:51 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Dominic Fandrey , freebsd-stable@freebsd.org References: <4A4DC67C.3010804@bsdforen.de> <20090713163922.GM2145@acme.spoerlein.net> In-Reply-To: <20090713163922.GM2145@acme.spoerlein.net> X-Enigmail-Version: 0.95.7 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: Subject: Re: mergemaster merge left/right 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, 14 Jul 2009 04:34:12 -0000 Ulrich Spörlein wrote: > When using X, maximize your xterm horizontally and use mergemaster -w100 > or something like that. It will probe the tty again and offer the "real" > width, so I usually just run mergemaster -w1 and hit enter. Making the window wider is good advice, but the -w option is not needed. If you're running mergemaster in any sort of tty it will automatically set the column width for sdiff for you. hth, Doug From owner-freebsd-stable@FreeBSD.ORG Tue Jul 14 05:42: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 C0906106566B for ; Tue, 14 Jul 2009 05:42:53 +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 870468FC0A for ; Tue, 14 Jul 2009 05:42:53 +0000 (UTC) (envelope-from sagara@tomahawk.com.sg) Received: (qmail 7845 invoked by alias); 14 Jul 2009 02:24:35 -0000 Message-ID: <20090714022435.7844.qmail@us1.tomahawkonline.net> References: <20090713120732.31803.qmail@us1.tomahawkonline.net> In-Reply-To: <20090713120732.31803.qmail@us1.tomahawkonline.net> From: "Sagara Wijetunga" To: freebsd-stable@freebsd.org Date: Mon, 13 Jul 2009 21:24:35 -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 Subject: Re: FreeBSD 7.2 USB stack info needed 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, 14 Jul 2009 05:42:54 -0000 Sagara Wijetunga writes: > Hi FreeBSD community > > After an USB thumb drive id pluged in, the devd prints following line: > > +umass0 vendor=0x0781 product=0x5406 devclass=0x00 devsubclass=0x00 > release=0x0200 sernum="087663165D8139E6" intclass=0x08 intsubclass=0x06 at > port=0 interface=0 vendor=0x0781 product=0x5406 devclass=0x00 > devsubclass=0x00 release=0x0200 sernum="087663165D8139E6" intclass=0x08 > intsubclass=0x06 on uhub4 > > > 1. Could I know which exact program print above line on /dev/devctl ? > > 2. I want to print another line with "daN" as the device-name, where N is > 0 to 9, with minimum vendor and product ids once the allocated device-name > is known for USB Mass Storage devices. Your additional ideas/feedback/help > is most welcomed. > There is a typing mistake: "After an USB thumb drive id pluged in" should be corrected as "After an USB thumb drive is plugged in". Very sorry for the mistake. Btw, I have started looking at umass.c and will have a look at later at usb.c of /usr/src/sys/dev/usb/. Any help is still very much appreciated. Best regards Sagara From owner-freebsd-stable@FreeBSD.ORG Tue Jul 14 08:41: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 961DD106566C for ; Tue, 14 Jul 2009 08:41:16 +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 E13858FC14 for ; Tue, 14 Jul 2009 08:41:15 +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; Tue, 14 Jul 2009 10:41:14 +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 n6E8fDu2021731for ; Tue, 14 Jul 2009 10:41:13 +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 n6E8fDn5019889for ; Tue, 14 Jul 2009 10:41:13 +0200 Received: (from nordhaug@localhost)by harr.himolde.no (8.13.1/8.13.1/Submit) id n6E8fDu0019888for freebsd-stable@freebsd.org; Tue, 14 Jul 2009 10:41:13 +0200 Date: Tue, 14 Jul 2009 10:41:13 +0200 From: "Hans F. Nordhaug" To: freebsd-stable@freebsd.org Message-ID: <20090714084113.GA19867@hiMolde.no> References: <20090708114127.GA22749@hiMolde.no> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <20090708114127.GA22749@hiMolde.no> User-Agent: Mutt/1.4.1i X-imss-version: 2.054 X-imss-result: Passed X-imss-approveListMatch: *@*.no Subject: Re: 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: Tue, 14 Jul 2009 08:41:16 -0000 * Hans F. Nordhaug [2009-07-08]: > 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. Apperently it was only meand my machine ;-) I reinstalled FreeBSD 7.2 on a newer computer and then freebsd-update or portsnap worked nicely. Best regards, Hans Nordhaug From owner-freebsd-stable@FreeBSD.ORG Tue Jul 14 09:38: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 EE86E106566C for ; Tue, 14 Jul 2009 09:38:04 +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 AAE958FC21 for ; Tue, 14 Jul 2009 09:38:04 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1MQeSX-0003Hh-Ib for freebsd-stable@freebsd.org; Tue, 14 Jul 2009 09:38:01 +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, 14 Jul 2009 09:38:01 +0000 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 14 Jul 2009 09:38:01 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: Ivan Voras Date: Tue, 14 Jul 2009 11:37:52 +0200 Lines: 18 Message-ID: References: <6101e8c40907130600j528bd4d5ue348563e89c7ffa3@mail.gmail.com> 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: <6101e8c40907130600j528bd4d5ue348563e89c7ffa3@mail.gmail.com> Sender: news Subject: Re: ZFS, unionfs - Operation not supported 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, 14 Jul 2009 09:38:05 -0000 Oliver Pinter wrote: > Hi all! > > It is the problematic FS: > zpower on /mnt/zpower (zfs, local) > /usr/src on /mnt/zpower/jail/default/ports (nullfs, local) > > and the failed command: > mount_unionfs -o below /mnt/zpower/jail/default/ports/ > /mnt/zpower/jail/www/usr/ports/ > > (truss mount_unionfs -o below /mnt/zpower/jail/default/ports/ > /mnt/zpower/jail/www/usr/ports/ ) > & /tmp/unionfs.log > > Have I any chance, to unionmount ZFS with UFS or ZFS not supported > this operations? Yes, unionfs is not supported with ZFS. From owner-freebsd-stable@FreeBSD.ORG Tue Jul 14 13:03: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 27CA41065678 for ; Tue, 14 Jul 2009 13:03:02 +0000 (UTC) (envelope-from gavin@FreeBSD.org) Received: from mail-gw1.york.ac.uk (mail-gw1.york.ac.uk [144.32.128.246]) by mx1.freebsd.org (Postfix) with ESMTP id AFB8C8FC1F for ; Tue, 14 Jul 2009 13:03:01 +0000 (UTC) (envelope-from gavin@FreeBSD.org) Received: from mail-gw7.york.ac.uk (mail-gw7.york.ac.uk [144.32.129.30]) by mail-gw1.york.ac.uk (8.13.6/8.13.6) with ESMTP id n6ECVjUS008389; Tue, 14 Jul 2009 13:31:45 +0100 (BST) Received: from buffy-128.york.ac.uk ([144.32.128.160] helo=buffy.york.ac.uk) by mail-gw7.york.ac.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1MQhAf-0005lG-6q; Tue, 14 Jul 2009 13:31:45 +0100 Received: from buffy.york.ac.uk (localhost [127.0.0.1]) by buffy.york.ac.uk (8.14.3/8.14.3) with ESMTP id n6ECViaC092669; Tue, 14 Jul 2009 13:31:44 +0100 (BST) (envelope-from gavin@FreeBSD.org) Received: (from ga9@localhost) by buffy.york.ac.uk (8.14.3/8.14.3/Submit) id n6ECVhTb092667; Tue, 14 Jul 2009 13:31:43 +0100 (BST) (envelope-from gavin@FreeBSD.org) X-Authentication-Warning: buffy.york.ac.uk: ga9 set sender to gavin@FreeBSD.org using -f From: Gavin Atkinson To: Adam McDougall In-Reply-To: <4A5B7257.1010202@egr.msu.edu> References: <20090713165717.GN2145@acme.spoerlein.net> <1de79840907131028n5b8f21deyd968639732c651a4@mail.gmail.com> <4A5B7257.1010202@egr.msu.edu> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Date: Tue, 14 Jul 2009 13:31:43 +0100 Message-Id: <1247574703.82683.17.camel@buffy.york.ac.uk> Mime-Version: 1.0 X-Mailer: Evolution 2.22.2 FreeBSD GNOME Team Port X-York-MailScanner: Found to be clean X-York-MailScanner-From: gavin@freebsd.org Cc: Michael Proto , Vlad Galu , freebsd-stable@FreeBSD.org Subject: Re: 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: Tue, 14 Jul 2009 13:03:02 -0000 On Mon, 2009-07-13 at 13:43 -0400, Adam McDougall wrote: > Michael Proto wrote: > > On Mon, Jul 13, 2009 at 12:57 PM, Ulrich Sp=F6rlein = wrote: > > =20 > >> On Thu, 09.07.2009 at 16:13:25 +0300, Vlad Galu wrote: > >> =20 > >>> 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 p= gsql -g 70 > >>> pw: group disappeared during update > >>> [root@vgalu /usr/ports/databases/postgresql84-server]# pw group add p= gsql -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. > >>> =20 > >> Just a me too. This is most likely because nscd is also caching negati= ve > >> lookups. The usual workaround would be to restart it using > >> /etc/rc.d/nscd restart > >> > >> =20 > > A slightly lower-impact alternative would be to use "nscd -i passwd" > > to invalidate the password cache. > > > > > I was intending to report this soon as well (its been on my list for a=20 > while) as a problematic > issue while installing ports. The other issue I had was Java would=20 > crash immediately if I had > nscd running (configured to cache YP). I plan to report that soon if it=20 > still happens with 1.6. > I probably tested with 1.4 or 1.5.=20 This is a known problem with nscd(8), see ports/125330 and bin/119695. If you have any further information (or even a patch) it's probably best to append it to the second of those PRs. Thanks, Gavin From owner-freebsd-stable@FreeBSD.ORG Tue Jul 14 13:51: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 C18831065674 for ; Tue, 14 Jul 2009 13:51:16 +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 F10F08FC1E for ; Tue, 14 Jul 2009 13:51:15 +0000 (UTC) (envelope-from ianjhart@ntlworld.com) Received: from aamtaout01-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 <20090714135111.ZWUP6742.mtaout01-winn.ispmail.ntl.com@aamtaout01-winn.ispmail.ntl.com>; Tue, 14 Jul 2009 14:51:11 +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 <20090714135110.EUBR13254.aamtaout01-winn.ispmail.ntl.com@cpc1-cove3-0-0-cust909.sol2.cable.ntl.com>; Tue, 14 Jul 2009 14:51:10 +0100 X-Virus-Scanned: amavisd-new at omega.private.lan 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 n6EDp1R7091119; Tue, 14 Jul 2009 14:51:01 +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, 14 Jul 2009 14:51:01 +0100 Message-ID: <20090714145101.60515vh49s7o7c4k@10.248.192.16> Date: Tue, 14 Jul 2009 14:51:01 +0100 From: Ian J Hart To: John Baldwin 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=6I5d2MoRAAAA:8 a=NLZqzBF-AAAA:8 a=BCnuk2dfNdKuxyDpmCAA:9 a=rgW8EkriWl-XZtypsQUA:7 a=WuZJzH7Yg3oZOK2JX59kGtxBf0UA:4 a=SV7veod9ZcQA:10 a=_dQi-Dcv4p4A:10 a=lgnsO7v62Er_t-pk:21 a=jlZRnsnPKrVumdme: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: Tue, 14 Jul 2009 13:51:17 -0000 Quoting John Baldwin : > On Tuesday 07 July 2009 5:51:03 am Ian J Hart wrote: >> 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. >>>> >>>> >>> 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 > > This one does look like a hardware issue from the stack trace. It's hard to > know if the first panic you saw was a hardware issue as well without the > stack trace information. > >> #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 > > -- > John Baldwin > The remote backup continues to run so there was definitely some issue there. No more reboots, but it wasn't doing that regularly without some additional load. Hopefully I can swap parts around until I find the offending item. Thanks for your input. -- ian j hart ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From owner-freebsd-stable@FreeBSD.ORG Tue Jul 14 16:49: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 0B3961065677 for ; Tue, 14 Jul 2009 16:49:36 +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 0607F8FC28 for ; Tue, 14 Jul 2009 16:49:34 +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: Au4EAFRUXErCVfWh/2dsb2JhbACBUdB1gmuBHQWBPYI1 X-IronPort-AV: E=Sophos;i="4.42,398,1243800000"; d="p7s'?scan'208";a="4298936" Received: from mail.ksu.ru (HELO ruby.ksu.ru) ([193.232.252.56]) by iout.kzn.ru with ESMTP; 14 Jul 2009 20:49: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 n6EFuldh013475; Tue, 14 Jul 2009 15:56:47 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 n6EGmx39030701; Tue, 14 Jul 2009 20:49:00 +0400 (MSD) (envelope-from amarat@ksu.ru) Message-ID: <4A5CB6FB.4090808@ksu.ru> Date: Tue, 14 Jul 2009 20:48:59 +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: Graham Menhennitt References: <4A5BBD50.2020408@menhennitt.com.au> In-Reply-To: <4A5BBD50.2020408@menhennitt.com.au> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030207010308050603030909" Cc: freebsd-stable@freebsd.org Subject: Re: problem with Soekris net5501 and USB hub 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, 14 Jul 2009 16:49:36 -0000 This is a cryptographically signed message in MIME format. --------------ms030207010308050603030909 Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Graham Menhennitt wrote: > I originally sent this to the Soekris list thinking it was platform > specific. I got a couple of replies suggesting that it's a FreeBSD > problem instead. So, if anybody can offer any insights, I would most > appreciate it. > > I have a Soekris net5501 running FreeBSD 7-Stable. I want to connect a > number of USB devices to it: > - a HP Laserjet 1020 printer > - an APC Back UPS 350 UPS > - a 6-in-one card reader (not so fussed about this one). > The Soekris box has only one USB port brought out to a connector on the > case, so rather than mod the box to add another port, I thought I would > just use an external hub. > > If I plug any of the devcies directly into the Soekris's USB port it > works fine. However, if I use a USB hub then it doesn't work at all. > I've tried it with two different hubs and two different cables. I've > tried the hubs both with a plug pack, and being powered from the USB > bus. The only thing common to the failures is the Soefkis and freeBSD. > The hubs are both USB 2.0 according to their advertising. > > The hub itself is recognised (although I don't have the output from > usbdevs available at the moment). The UPS doesn't ever seem to be > recognised when connected via the hub - there's nothing in dmesg and > nothing in usbdevs. Ditto for the 6-in-one card reader - the LED on the > front of it doesn't even light up. > > The printer sometimes gets partially recognised. The output from > "usbdevs -v" when the printer is connected directly and working properly > looks like: > > Controller /dev/usb0: > addr 1: full speed, self powered, config 1, OHCI root hub(0x0000), > AMD(0x0000), rev 1.00 > port 1 powered > port 2 powered > port 3 powered > port 4 powered > Controller /dev/usb1: > addr 1: high speed, self powered, config 1, EHCI root hub(0x0000), > AMD(0x0000), rev 1.00 > port 1 addr 2: high speed, self powered, config 1, HP LaserJet > 1020(0x2b17), Hewlett-Packard(0x03f0), rev 1.00 > port 2 powered > port 3 powered > port 4 powered > > However, if I connect it via the hub, it sometimes doesn't show it at > all, while other times it says something like (doing this from memory): > > port 1 addr 2: high speed, self powered, config 1, 0x2b17(0x2b17), > vendor 0x03f0(0x03f0), rev 1.00 > > So, it can see it but it doesn't resolve the vendor or device ids. It > looks like the Soekris can see whatever is directly connected to it, but > can't (reliably) see things that more than one step away. > > My (custom) kernel has: > > device usb # USB Bus (required) > device umass # Disks/Mass storage - Requires scbus > and da > device scbus # SCSI bus (required for SCSI) > device da # Direct Access (disks) > device uhci # UHCI PCI->USB interface > device ohci # OHCI PCI->USB interface > device ehci # EHCI PCI->USB interface (USB 2.0) > device ugen # Generic > > So, does anybody have any ideas about how to fix this. > > Thanks for any help, > Graham > _______________________________________________ > 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" > see http://www.freebsd.org/cgi/query-pr.cgi?pr=131074 i think your case is very similar to mine -- SY, Marat --------------ms030207010308050603030909 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 AKCCAcMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDkwNzE0 MTY0ODU5WjAjBgkqhkiG9w0BCQQxFgQUzDj1birqQtdtfTg70nKEckxgJFAwUgYJKoZIhvcN AQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYF Kw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhB6bDKOp5G1FXoMYwM88WApMIGHBgsq hkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1 aW5nIENBAhB6bDKOp5G1FXoMYwM88WApMA0GCSqGSIb3DQEBAQUABIIBAExOiQauvguCWnMC 2ThDlit9dAYTqWqLuRwFVC6bl0d1CS/vevKCoCzHnXa19S6HExbLIh5sg240+jfbinHnKB3u 2U+AszzDdbkGaT3wpcoPmp0g3FtqFE1kVZl9iYpqNjI4RKtukx7ZVa0ZULB2c/hY/dDufHQ5 tRWJWBn1wLvVhvT20oaPGFtuOHgjG+P7bhlzf8XXED+mXjAeZc2RsUTm4fSuc8Rn9YTEUfxQ O05oT2dEqifW9Sgze8WDmTMbgTMpwJE4UeFW+dGcvCj3NjCnk87xZSheF7cl83x7JXhW7A8a 4OIzdjV/5zce2OobEBiQtdHUxa5YXsqp7s9QrWwAAAAAAAA= --------------ms030207010308050603030909-- From owner-freebsd-stable@FreeBSD.ORG Tue Jul 14 17:39: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 316CF1065698 for ; Tue, 14 Jul 2009 17:39:18 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id E41E48FC23 for ; Tue, 14 Jul 2009 17:39:17 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 7B33546B5C; Tue, 14 Jul 2009 13:39:17 -0400 (EDT) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 655148A099; Tue, 14 Jul 2009 13:39:16 -0400 (EDT) From: John Baldwin To: freebsd-stable@freebsd.org Date: Tue, 14 Jul 2009 13:00:16 -0400 User-Agent: KMail/1.9.7 References: <20090714145101.60515vh49s7o7c4k@10.248.192.16> In-Reply-To: <20090714145101.60515vh49s7o7c4k@10.248.192.16> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200907141300.16634.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Tue, 14 Jul 2009 13:39:16 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: 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, 14 Jul 2009 17:39:19 -0000 On Tuesday 14 July 2009 9:51:01 am Ian J Hart wrote: > Quoting John Baldwin : > > > On Tuesday 07 July 2009 5:51:03 am Ian J Hart wrote: > >> 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. > >>>> > >>>> > >>> 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 > > > > This one does look like a hardware issue from the stack trace. It's hard to > > know if the first panic you saw was a hardware issue as well without the > > stack trace information. > > > >> #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 > > > > -- > > John Baldwin > > > > The remote backup continues to run so there was definitely some issue > there. No more reboots, but it wasn't doing that regularly without > some additional load. > > Hopefully I can swap parts around until I find the offending item. > > Thanks for your input. I would try running memtest86 to check your RAM. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Wed Jul 15 09:08:19 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 530E110656BC for ; Wed, 15 Jul 2009 09:08:19 +0000 (UTC) (envelope-from randy@psg.com) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by mx1.freebsd.org (Postfix) with ESMTP id 86FA58FC1E for ; Wed, 15 Jul 2009 09:08:17 +0000 (UTC) (envelope-from randy@psg.com) Received: from localhost ([127.0.0.1] helo=rmac.psg.com) by ran.psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MR0TI-000KXg-Px for freebsd-stable@freebsd.org; Wed, 15 Jul 2009 09:08:17 +0000 Received: from rmac.local.psg.com (localhost [127.0.0.1]) by rmac.psg.com (Postfix) with ESMTP id 4D60428CF390 for ; Wed, 15 Jul 2009 18:08:16 +0900 (JST) Date: Wed, 15 Jul 2009 18:08:16 +0900 Message-ID: From: Randy Bush To: FreeBSD Stable User-Agent: Wanderlust/2.15.5 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.7 Emacs/22.3 (i386-apple-darwin9.6.0) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: boot crash with ddb & break_to_debugger 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, 15 Jul 2009 09:08:21 -0000 i386 cvsupped as of yesterday =DA=C4=C4=C4=C4=C4=C4=C4=C4=C4=C4=C4=C4=C4=C4=C4=C4=C4=C4=C4=C4=C4=C4=C4= =C4=C4=C4=C4=C4=C4=C4=C4=C4=C4=C4=C4=C4=C4=C4=C4=C4=C4=BF =B3 =B3 =B3 =B3 , , =B3 =B3 /( )` =B3 Welcome to FreeBSD! =B3 \ \___ / | =B3 =B3 /- _ `-/ ' =B3 =B3 (/\/ \ \ /\ =B3 1. Boot FreeBSD [default] =B3 / / | ` \ =B3 2. Boot FreeBSD with ACPI disabled =B3 O O ) / | =B3 3. Boot FreeBSD in Safe Mode =B3 `-^--'`< ' =B3 4. Boot FreeBSD in single user mode =B3 (_.) _ ) / =B3 5. Boot FreeBSD with verbose logging =B3 `.___/` / = =20 =B3 6. Escape to loader prompt =B3 `-----' / =B3 7. Reboot =B3 <----. __ / __ \ =B3 =B3 <----|=3D=3D=3D=3DO)))=3D= =3D) \) /=3D=3D=3D=3D| =B3 =B3 <----' `--' `.__,' \ =B3 =B3 | | =B3 =B3 \ / = /\ =B3 Select option, [Enter] for default =B3 ______( (_ / \_= _____/ =B3 or [Space] to pause timer -1 =B3 ,' ,-----' | =C0=C4=C4=C4=C4=C4=C4=C4=C4=C4=C4=C4=C4=C4=C4=C4=C4=C4=C4=C4=C4=C4=C4=C4= =C4=C4=C4=C4=C4=C4=C4=C4=C4=C4=C4=C4=C4=C4=C4=C4=C4=C4=D9 `--{_____= _____)=20 KDB: debugger backends: ddb KDB: current backend: ddb 131072K of memory above 4GB ignored 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 #28: Wed Jul 15 08:11:56 GMT 2009 root@psg.com:/usr/obj/usr/src/sys/PSG kmem_suballoc: bad status return of 3. panic: kmem_suballoc cpuid =3D 0 KDB: enter: panic [thread pid 0 tid 0 ] Stopped at kdb_enter_why+0x3a: movl $0,kdb_why db> trace Tracing pid 0 tid 0 td 0xc07fad60 kdb_enter_why(c078b1b8,c078b1b8,c079e7a8,c0c20d04,0,...) at kdb_enter_why+0= x3a panic(c079e7a8,3,0,0,c07fb8a0,...) at panic+0x138 kmem_suballoc(c1071000,c07fb8a0,c07fb8a4,40000000,1,...) at kmem_suballoc+0= x91 kmeminit(0,c1ec00,c1ec00,c1e000,c25000,...) at kmeminit+0x18a mi_startup() at mi_startup+0xa6 begin() at begin+0x2c db> From owner-freebsd-stable@FreeBSD.ORG Wed Jul 15 09:34:39 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 4D9F9106564A for ; Wed, 15 Jul 2009 09:34:39 +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 8863A8FC2A for ; Wed, 15 Jul 2009 09:34:37 +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: AvYEAOk/XUrCVfWh/2dsb2JhbACBUc8xhAkF X-IronPort-AV: E=Sophos;i="4.42,403,1243800000"; d="p7s'?scan'208";a="4311467" Received: from mail.ksu.ru (HELO ruby.ksu.ru) ([193.232.252.56]) by iout.kzn.ru with ESMTP; 15 Jul 2009 13:34:34 +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 n6F8Z8QP024058; Wed, 15 Jul 2009 08:35:08 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 n6F9X9F3070187; Wed, 15 Jul 2009 13:33:09 +0400 (MSD) (envelope-from amarat@ksu.ru) Message-ID: <4A5DA250.9000902@ksu.ru> Date: Wed, 15 Jul 2009 13:33:04 +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: =?UTF-8?B?U8O4cmVuIFNjaG1pZHQ=?= References: <8EB69F68-8ED2-469C-B83E-2555A72630B4@deepcore.dk> In-Reply-To: <8EB69F68-8ED2-469C-B83E-2555A72630B4@deepcore.dk> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010701010005030205040805" Cc: stable@freebsd.org, hackers@freebsd.org Subject: Re: ATA driver update for 7.2RELEASE 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, 15 Jul 2009 09:34:42 -0000 This is a cryptographically signed message in MIME format. --------------ms010701010005030205040805 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable S=C3=B8ren Schmidt wrote: > Over the past months I've gotten huge amounts of requests for ATA=20 > related things, so I've whipped up what I use here for FreeBSD 7.2-Rele= ase. >=20 > This is a total replacement of the ATA driver, modulerized as in=20 > -current, but based on my WIP not from what might have happend to=20 > -current since I gave up maintainership. >=20 > There is a number of new chipsets supported in here that I dont think i= s=20 > in any of the official sources (havn't checked in quite some time=20 > though), mostly newish ATI, nVidia and Marvell chips (yeah those bugger= s=20 > with both ATA & SATA ports). >=20 > You can find and install.sh script and a tarball of the needed files at= : >=20 > http://www.deepcore.dk/pub/ATA >=20 > Put both in /usr/src and run install.sh. >=20 > As I dont subscribe to any of the mailing lists nor does my FreeBSD.org= =20 > mail address seem to work anymore, you will need to reply to me directl= y=20 > if needed. >=20 > As always - Enjoy! >=20 > -S=C3=B8ren i think i'm dumb, but can you tell me how can atapicam be enabled with=20 this implementation of ata? i couldn't still find a way :( --=20 SY, Marat --------------ms010701010005030205040805 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 AKCCAcMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDkwNzE1 MDkzMzA0WjAjBgkqhkiG9w0BCQQxFgQUAwCK3nArtoYS2eyvApopicJ99WMwUgYJKoZIhvcN AQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYF Kw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhB6bDKOp5G1FXoMYwM88WApMIGHBgsq hkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1 aW5nIENBAhB6bDKOp5G1FXoMYwM88WApMA0GCSqGSIb3DQEBAQUABIIBABFvQ4iyUku8/guS VkEh5JHY08RViFXgwszfRNIfrE9JQyRGDF99Tl6zAeVyqYfaU4gOtkuzUL7XwmrIvUgxI4ja 1bQEp9kDc7M+/lzdggzURgpcR+Z01MtHp5WkrCiosPDICd39v+saZ9OxMav0UeVazDQ9ckwl lYz5JmbGtJ/1uqmXnR+O9ZoXSYkNwj+T5CTGT48irncC7zk/XrEETXNlfP1pS16n1FnexvxG qwoVJae/rEVQh/yFr3fWBS3/YPVjlW0NR2RWseZx8lFfNdm+gfAkY0wdFSnXNtFcWLp851wF aaBoWNilA65GxkECHj7H0UBagzEjMxVhBFbWijQAAAAAAAA= --------------ms010701010005030205040805-- From owner-freebsd-stable@FreeBSD.ORG Wed Jul 15 10:45: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 E524C106566C for ; Wed, 15 Jul 2009 10:45:28 +0000 (UTC) (envelope-from Johan@double-l.nl) Received: from smtp-vbr13.xs4all.nl (smtp-vbr13.xs4all.nl [194.109.24.33]) by mx1.freebsd.org (Postfix) with ESMTP id 6AFF88FC17 for ; Wed, 15 Jul 2009 10:45:28 +0000 (UTC) (envelope-from Johan@double-l.nl) Received: from w2003s01.double-l.local (double-l.xs4all.nl [80.126.205.144]) by smtp-vbr13.xs4all.nl (8.13.8/8.13.8) with ESMTP id n6FAjRQ6043469 for ; Wed, 15 Jul 2009 12:45:27 +0200 (CEST) (envelope-from Johan@double-l.nl) Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 15 Jul 2009 12:45:26 +0200 Message-ID: <57200BF94E69E54880C9BB1AF714BBCB5DEA56@w2003s01.double-l.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: mergemaster ezjails. different behaviour between 7.1 and 7.2 and up Thread-Index: AcoFOV0LDezHRdr+QhqBnbI2dpDP5Q== From: "Johan Hendriks" To: X-Virus-Scanned: by XS4ALL Virus Scanner Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: mergemaster ezjails. different behaviour between 7.1 and 7.2 and up 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, 15 Jul 2009 10:45:29 -0000 Hello all . =20 I have an issue using mergemaster and ezjail after the update to FreeBSD 7.2 from 7.1 I have several boxes running ezjails from FreeBSD 7.0 to 7.1 and i always use the same way to update these machines. =20 First a buildworld cycle. then reboot and make sure jails are not running. then ezjail-admin update -i After that i do a mergemaster of the jails. #mergemaster -iU -D /usr/jails/jail1 on a 7.2 and above system i get the following error. cd /usr/src/etc/..; install -o root -g wheel -m 444 COPYRIGHT /var/tmp/temproot/ install -o root -g wheel -m 444 /usr/src/etc/../sys/amd64/conf/GENERIC.hints /var/tmp/temproot/boot/device.hints *** Beginning comparison *** Checking /usr/jails/test//etc/rc.d for stale files *** No stale files found *** There is no installed version of ./boot/device.hints install: mkdir /usr/jails/test//boot: File exists install: /usr/jails/test//boot: No such file or directory *** FATAL ERROR: Unable to install ./boot/device.hints to /usr/jails/test//boot jailhost_co test # =20 And it drops me to the commandline again. On the old 7.0 and 7.1 it works well. It does not drop to commandline but carries on like the example below. cd /usr/src/etc/..; install -o root -g wheel -m 444 COPYRIGHT /var/tmp/temproot/ install -o root -g wheel -m 444 /usr/src/etc/../sys/i386/conf/GENERIC.hints /var/tmp/temproot/boot/device.hints *** Beginning comparison *** Checking /usr/jails/ftp/etc/rc.d for stale files *** No stale files found *** There is no installed version of ./boot/device.hints install: mkdir /usr/jails/ftp/boot: File exists install: /usr/jails/ftp/boot: No such file or directory *** Problem installing ./boot/device.hints, it will remain to merge by hand *** Temp ./etc/bluetooth/hcsecd.conf and installed have the same CVS Id, deleting Here it comes with the *** Problem installing ./boot/device.hints, it will remain to merge by hand line On 7.2 and up (also 8.0BETA1) ir gives me this=20 *** FATAL ERROR: Unable to install ./boot/device.hints to /usr/jails/test//boot Do i need another option i need to give mergemaster? =20 I hope things are clear, i am not that good in explaining things in another language. Regards, Johan =20 =20 From owner-freebsd-stable@FreeBSD.ORG Wed Jul 15 11:14: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 F40691065754 for ; Wed, 15 Jul 2009 11:14:13 +0000 (UTC) (envelope-from graham@menhennitt.com.au) Received: from fallbackmx06.syd.optusnet.com.au (fallbackmx06.syd.optusnet.com.au [211.29.132.8]) by mx1.freebsd.org (Postfix) with ESMTP id F40A18FC08 for ; Wed, 15 Jul 2009 11:14:12 +0000 (UTC) (envelope-from graham@menhennitt.com.au) Received: from mail02.syd.optusnet.com.au (mail02.syd.optusnet.com.au [211.29.132.183]) by fallbackmx06.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id n6F9ZNb2016094 for ; Wed, 15 Jul 2009 19:35:23 +1000 Received: from maxwell.mencon.com.au (c220-239-199-115.chirn1.vic.optusnet.com.au [220.239.199.115]) by mail02.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id n6F9ZGcS009854; Wed, 15 Jul 2009 19:35:16 +1000 Received: from [203.2.73.73] (chief.mencon.com.au [203.2.73.73]) by maxwell.mencon.com.au (Postfix) with ESMTP id E4F1C5C5F; Wed, 15 Jul 2009 19:35:15 +1000 (EST) Message-ID: <4A5DA2D7.6080709@menhennitt.com.au> Date: Wed, 15 Jul 2009 19:35:19 +1000 From: Graham Menhennitt User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: "Marat N.Afanasyev" References: <4A5BBD50.2020408@menhennitt.com.au> <4A5CB6FB.4090808@ksu.ru> In-Reply-To: <4A5CB6FB.4090808@ksu.ru> Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: problem with Soekris net5501 and USB hub 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, 15 Jul 2009 11:14:14 -0000 Marat N.Afanasyev wrote: > Graham Menhennitt wrote: >> I originally sent this to the Soekris list thinking it was platform >> specific. I got a couple of replies suggesting that it's a FreeBSD >> problem instead. So, if anybody can offer any insights, I would most >> appreciate it. >> >> I have a Soekris net5501 running FreeBSD 7-Stable. I want to connect >> a number of USB devices to it: >> - a HP Laserjet 1020 printer >> - an APC Back UPS 350 UPS >> - a 6-in-one card reader (not so fussed about this one). >> The Soekris box has only one USB port brought out to a connector on >> the case, so rather than mod the box to add another port, I thought I >> would just use an external hub. >> >> If I plug any of the devcies directly into the Soekris's USB port it >> works fine. However, if I use a USB hub then it doesn't work at all. > see http://www.freebsd.org/cgi/query-pr.cgi?pr=131074 i think your > case is very similar to mine Thanks Marat (and the others that replied). It is the same problem as in that PR - if the devices are connected at boot time everything works. If I power them on later it doesn't. For now that will be my workaround. I'll look at upgrading to 8 some time soon. Thanks again, Graham From owner-freebsd-stable@FreeBSD.ORG Wed Jul 15 13:48: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 C34A51065689; Wed, 15 Jul 2009 13:48:24 +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 F1B558FC12; Wed, 15 Jul 2009 13:48:23 +0000 (UTC) (envelope-from ianjhart@ntlworld.com) Received: from aamtaout02-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 <20090715134819.TTVI6611.mtaout02-winn.ispmail.ntl.com@aamtaout02-winn.ispmail.ntl.com>; Wed, 15 Jul 2009 14:48:19 +0100 Received: from cpc1-cove3-0-0-cust909.sol2.cable.ntl.com ([86.20.31.142]) by aamtaout02-winn.ispmail.ntl.com (InterMail vG.2.02.00.01 201-2161-120-102-20060912) with ESMTP id <20090715134819.OTXP21638.aamtaout02-winn.ispmail.ntl.com@cpc1-cove3-0-0-cust909.sol2.cable.ntl.com>; Wed, 15 Jul 2009 14:48:19 +0100 X-Virus-Scanned: amavisd-new at omega.private.lan 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 n6FDlvLv006949; Wed, 15 Jul 2009 14:47:57 +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; Wed, 15 Jul 2009 14:47:56 +0100 Message-ID: <20090715144756.107076ji8zo2oh0k@10.248.192.16> Date: Wed, 15 Jul 2009 14:47:56 +0100 From: Ian J Hart To: John Baldwin References: <20090714145101.60515vh49s7o7c4k@10.248.192.16> <200907141300.16634.jhb@freebsd.org> In-Reply-To: <200907141300.16634.jhb@freebsd.org> 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=6I5d2MoRAAAA:8 a=NLZqzBF-AAAA:8 a=pu2GmGBiriTffNN3MroA:9 a=ZeEn40FFaf4qDjDoOo0A:7 a=Kx3brIwj9YRegh4A7SqITyVILFgA:4 a=SV7veod9ZcQA:10 a=_dQi-Dcv4p4A:10 a=70Ui9NTFQqM8-blI:21 a=sXwrx7q-aWA_qakX: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: Wed, 15 Jul 2009 13:48:25 -0000 Quoting John Baldwin : > On Tuesday 14 July 2009 9:51:01 am Ian J Hart wrote: >> Quoting John Baldwin : >> >> > On Tuesday 07 July 2009 5:51:03 am Ian J Hart wrote: >> >> 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. >> >>>> >> >>>> >> >>> 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 >> > >> > This one does look like a hardware issue from the stack trace. It's hard > to >> > know if the first panic you saw was a hardware issue as well without the >> > stack trace information. >> > >> >> #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 >> > >> > -- >> > John Baldwin >> > >> >> The remote backup continues to run so there was definitely some issue >> there. No more reboots, but it wasn't doing that regularly without >> some additional load. >> >> Hopefully I can swap parts around until I find the offending item. >> >> Thanks for your input. > > I would try running memtest86 to check your RAM. > > -- > John Baldwin > It's ECC and was extensively tested when new so I suspect it's something else, but I'll memtest it overnight anyway. Sat at a panic when I went to put the floppy in.No debugger prompt and unresponsive so I power cycled it :( -- ian j hart ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From owner-freebsd-stable@FreeBSD.ORG Wed Jul 15 14:48:54 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 E446A106566B; Wed, 15 Jul 2009 14:48:54 +0000 (UTC) (envelope-from sos@deepcore.dk) Received: from deepcore.dk (adsl.deepcore.dk [87.63.29.106]) by mx1.freebsd.org (Postfix) with ESMTP id 6E1BC8FC0A; Wed, 15 Jul 2009 14:48:54 +0000 (UTC) (envelope-from sos@deepcore.dk) Received: from [192.168.0.138] ([192.168.0.138]) by deepcore.dk (8.14.3/8.14.3) with ESMTP id n6FElERZ035856; Wed, 15 Jul 2009 16:47:14 +0200 (CEST) (envelope-from sos@deepcore.dk) Message-Id: From: =?ISO-8859-1?Q?S=F8ren_Schmidt?= To: "Marat N.Afanasyev" In-Reply-To: <4A5DA250.9000902@ksu.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 15 Jul 2009 16:48:52 +0200 References: <8EB69F68-8ED2-469C-B83E-2555A72630B4@deepcore.dk> <4A5DA250.9000902@ksu.ru> X-Mailer: Apple Mail (2.935.3) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.3.2 (deepcore.dk [87.63.29.106]); Wed, 15 Jul 2009 16:47:15 +0200 (CEST) Cc: stable@freebsd.org, hackers@freebsd.org Subject: Re: ATA driver update for 7.2RELEASE 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, 15 Jul 2009 14:48:55 -0000 On 15Jul, 2009, at 11:33 , Marat N.Afanasyev wrote: > S=F8ren Schmidt wrote: >> Over the past months I've gotten huge amounts of requests for ATA =20 >> related things, so I've whipped up what I use here for FreeBSD 7.2-=20= >> Release. >> This is a total replacement of the ATA driver, modulerized as in -=20 >> current, but based on my WIP not from what might have happend to -=20 >> current since I gave up maintainership. >> There is a number of new chipsets supported in here that I dont =20 >> think is in any of the official sources (havn't checked in quite =20 >> some time though), mostly newish ATI, nVidia and Marvell chips =20 >> (yeah those buggers with both ATA & SATA ports). >> You can find and install.sh script and a tarball of the needed =20 >> files at: >> http://www.deepcore.dk/pub/ATA >> Put both in /usr/src and run install.sh. >> As I dont subscribe to any of the mailing lists nor does my =20 >> FreeBSD.org mail address seem to work anymore, you will need to =20 >> reply to me directly if needed. >> As always - Enjoy! >> -S=F8ren > > i think i'm dumb, but can you tell me how can atapicam be enabled =20 > with this implementation of ata? i couldn't still find a way :( You could just grap atapi-cam.c from stock 7.2 and use that I guess =20 (as a module or compiled in), newer used it though... -S=F8ren -- From owner-freebsd-stable@FreeBSD.ORG Thu Jul 16 07:06: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 C3F05106564A for ; Thu, 16 Jul 2009 07:06:01 +0000 (UTC) (envelope-from hiyorin@gmail.com) Received: from mail-px0-f200.google.com (mail-px0-f200.google.com [209.85.216.200]) by mx1.freebsd.org (Postfix) with ESMTP id 8F48C8FC17 for ; Thu, 16 Jul 2009 07:06:01 +0000 (UTC) (envelope-from hiyorin@gmail.com) Received: by pxi38 with SMTP id 38so1455498pxi.3 for ; Thu, 16 Jul 2009 00:06:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=kvTJEMLgRM94Y6DdSpgL5ZB5bJMz+PwMK6KK2ibzkFc=; b=wOwtURqC/+SiT1t7Z7D7ASAnTQ9/gTgLDmZtJVaWukaV+KtNwG96tDlV9I5VVTU2KM DxtVUcJY4XSLDQr8wOVJqS/8M4om5OKJfKGlK5s6yAvpNZW8NumwKiPk80VBHF3Rmx3I 8Ef4IQpuOcecr0F0earNI/DDXBiUMRdaywAbg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=Qufmk1xPPNoVIkZE76A8tmyU2yihKq/WyikF9nHJnGGyRONkCKd2O47HVl6KFy5BRF Cf8JlWfGdKjP/FzpH3ADMg/TABVwuc99ltXHzVQ+KmkHiVe812/5IZiNAeg9oWF3mk9u gsEhN40LUMxS78OT2E/iflpwFkCC8u/idRS6k= Received: by 10.141.43.19 with SMTP id v19mr4980531rvj.22.1247726740133; Wed, 15 Jul 2009 23:45:40 -0700 (PDT) Received: from ?10.130.10.181? ([202.82.159.125]) by mx.google.com with ESMTPS id g31sm11604665rvb.10.2009.07.15.23.45.38 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 15 Jul 2009 23:45:39 -0700 (PDT) Message-ID: <4A5ECC8C.7030808@gmail.com> Date: Thu, 16 Jul 2009 14:45:32 +0800 From: "C. C. Tang" User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <3bbf2fe10907061818v245abd0cgc3ca5073cb93aea4@mail.gmail.com> <3bbf2fe10907061827g35eaeb49g26cf6fdb64436ca7@mail.gmail.com> <3bbf2fe10907080250q35899d3dhc2f101b62c6e5306@mail.gmail.com> In-Reply-To: <3bbf2fe10907080250q35899d3dhc2f101b62c6e5306@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: Thu, 16 Jul 2009 07:06:02 -0000 Attilio Rao wrote: > 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 > I think I am also having similar problem on my Atom machine. (FreeBSD-7.2-Release-p1) It does not happen at boot/reboot but panic randomly. And I found that it remains stable for more than a month now after I disabled powerd... (although I want to have it enabled) -- C.C. From owner-freebsd-stable@FreeBSD.ORG Thu Jul 16 07:08: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 30B401065674 for ; Thu, 16 Jul 2009 07:08:06 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-bw0-f208.google.com (mail-bw0-f208.google.com [209.85.218.208]) by mx1.freebsd.org (Postfix) with ESMTP id DBB8B8FC18 for ; Thu, 16 Jul 2009 07:08:04 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: by bwz4 with SMTP id 4so1234251bwz.43 for ; Thu, 16 Jul 2009 00:08:03 -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=UWRMQGcEjgmLPNIs97HN6Ff/s1AdZWnFN/v1n8PHen4=; b=olwSpwtJfXugKKVSv6rGOZJLrIi/FbO68khnKukjhhAGtZM6oMCPIsnLnj6oq2IEs8 RTRQdvdXwNb+5gfMw3P7D+WzIX15pNJkMh3kzmDi7pCnRf/YW/MHGgPpSivPAPHxQDL3 E7+d0L+Zf3RlkdmE5eYxB47pav7OgeQut0GNo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=xFp6NhdiKQt0+HinsXBWb+Prus7VSf8C0oenUWrD7XPp1cd4/K7KVbJ28ZwGuTAKDb 5UhEU64o7LCVXLa8t6gMr6gohfdXhNq8hp4JU+7ajG3auIzQmq108e7gDy8VEUTYK2nz II7iSRu061B2xN9/JHUSCq631TrVLtt/y0l84= MIME-Version: 1.0 Received: by 10.103.239.10 with SMTP id q10mr4639150mur.36.1247728082914; Thu, 16 Jul 2009 00:08:02 -0700 (PDT) Date: Thu, 16 Jul 2009 11:08:02 +0400 Message-ID: From: pluknet To: freebsd-stable Content-Type: multipart/mixed; boundary=001636765b692890dd046ecd5539 Subject: [bce] panic on boot in bce(4) on 7.2: invalid ife->ifm_data (0xa) 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, 16 Jul 2009 07:08:06 -0000 --001636765b692890dd046ecd5539 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi. I got the following kernel panic on boot: invalid ife->ifm_data (0xa) in mii_phy_setmedia This is near /sys/dev/mii/mii_physubr.c:126 KASSERT(ife->ifm_data >=0 && ife->ifm_data < MII_NMEDIA, ("invalid ife->ifm_data (0x%x) in mii_phy_setmedia", ife->ifm_data)); Kernel is 7.2 GENERIC plus debug options: options KDB options DDB options LOCK_PROFILING options INVARIANTS # Enable calls of extra sanity checking options INVARIANT_SUPPORT # Extra sanity checks of internal structures, required by INVARIANTS options WITNESS # Enable checks to detect deadlocks and cycles options DEBUG_LOCKS options DEBUG_VFS_LOCKS options DIAGNOSTIC options BREAK_TO_DEBUGGER options STACK I have no the serial connection on this box this time, so ddb pictures captured with a camera are here: http://test.myrz.ru/tmp/panic_on_bce/ Verbose dmesg from stock GENERIC attached. bce0@pci0:11:0:0: class=0x020000 card=0x03a91014 chip=0x163914e4 rev=0x20 hdr=0x00 vendor = 'Broadcom Corporation' device = 'NetXtreme II BCM5709 Gigabit Ethernet' class = network subclass = ethernet bce1@pci0:11:0:1: class=0x020000 card=0x03a91014 chip=0x163914e4 rev=0x20 hdr=0x00 vendor = 'Broadcom Corporation' device = 'NetXtreme II BCM5709 Gigabit Ethernet' class = network subclass = ethernet -- wbr, pluknet --001636765b692890dd046ecd5539 Content-Type: application/octet-stream; name="dmesg.verbose" Content-Disposition: attachment; filename="dmesg.verbose" Content-Transfer-Encoding: base64 X-Attachment-Id: f_fx75275n0 Q29weXJpZ2h0IChjKSAxOTkyLTIwMDkgVGhlIEZyZWVCU0QgUHJvamVjdC4KQ29weXJpZ2h0IChj KSAxOTc5LCAxOTgwLCAxOTgzLCAxOTg2LCAxOTg4LCAxOTg5LCAxOTkxLCAxOTkyLCAxOTkzLCAx OTk0CglUaGUgUmVnZW50cyBvZiB0aGUgVW5pdmVyc2l0eSBvZiBDYWxpZm9ybmlhLiBBbGwgcmln aHRzIHJlc2VydmVkLgpGcmVlQlNEIGlzIGEgcmVnaXN0ZXJlZCB0cmFkZW1hcmsgb2YgVGhlIEZy ZWVCU0QgRm91bmRhdGlvbi4KRnJlZUJTRCA3LjItUkVMRUFTRSAjMDogRnJpIE1heSAgMSAwODo0 OToxMyBVVEMgMjAwOQogICAgcm9vdEB3YWxrZXIuY3NlLmJ1ZmZhbG8uZWR1Oi91c3Ivb2JqL3Vz ci9zcmMvc3lzL0dFTkVSSUMKUHJlbG9hZGVkIGVsZiBrZXJuZWwgIi9ib290L2tlcm5lbC5vbGQv a2VybmVsIiBhdCAweGMwZTY3MDAwLgpQcmVsb2FkZWQgZWxmIG1vZHVsZSAiL2Jvb3Qva2VybmVs Lm9sZC9hY3BpLmtvIiBhdCAweGMwZTY3MjA0LgpDYWxpYnJhdGluZyBjbG9jayhzKSAuLi4gaTgy NTQgY2xvY2s6IDExOTMxNzYgSHoKQ0xLX1VTRV9JODI1NF9DQUxJQlJBVElPTiBub3Qgc3BlY2lm aWVkIC0gdXNpbmcgZGVmYXVsdCBmcmVxdWVuY3kKVGltZWNvdW50ZXIgImk4MjU0IiBmcmVxdWVu Y3kgMTE5MzE4MiBIeiBxdWFsaXR5IDAKQ2FsaWJyYXRpbmcgVFNDIGNsb2NrIC4uLiBUU0MgY2xv Y2s6IDIyNjY3NjM1OTYgSHoKQ1BVOiBJbnRlbChSKSBYZW9uKFIpIENQVSAgICAgICAgICAgRTU1 MjAgIEAgMi4yN0dIeiAoMjI2Ni43Ni1NSHogNjg2LWNsYXNzIENQVSkKICBPcmlnaW4gPSAiR2Vu dWluZUludGVsIiAgSWQgPSAweDEwNmE1ICBTdGVwcGluZyA9IDUKICBGZWF0dXJlcz0weGJmZWJm YmZmPEZQVSxWTUUsREUsUFNFLFRTQyxNU1IsUEFFLE1DRSxDWDgsQVBJQyxTRVAsTVRSUixQR0Us TUNBLENNT1YsUEFULFBTRTM2LENMRkxVU0gsRFRTLEFDUEksTU1YLEZYU1IsU1NFLFNTRTIsU1Ms SFRULFRNLFBCRT4KICBGZWF0dXJlczI9MHg5Y2UzYmQ8U1NFMyxEVEVTNjQsTU9OLERTX0NQTCxW TVgsRVNULFRNMixTU1NFMyxDWDE2LHhUUFIsUERDTSxEQ0EsU1NFNC4xLFNTRTQuMixQT1BDTlQ+ CiAgQU1EIEZlYXR1cmVzPTB4MjgxMDAwMDA8TlgsUkRUU0NQLExNPgogIEFNRCBGZWF0dXJlczI9 MHgxPExBSEY+CiAgQ29yZXMgcGVyIHBhY2thZ2U6IDgKICBMb2dpY2FsIENQVXMgcGVyIGNvcmU6 IDIKCkRhdGEgVExCOiA0IEtCIHBhZ2VzLCA0LXdheSBzZXQgYXNzb2NpYXRpdmUsIDY0IGVudHJp ZXMKMXN0LWxldmVsIGRhdGEgY2FjaGU6IDMyIEtCLCA4LXdheSBzZXQgYXNzb2NpYXRpdmUsIDY0 IGJ5dGUgbGluZSBzaXplCkwyIGNhY2hlOiAyNTYga2J5dGVzLCA4LXdheSBhc3NvY2lhdGl2ZSwg NjQgYnl0ZXMvbGluZQpyZWFsIG1lbW9yeSAgPSAyMTM3NTgzNjE2ICgyMDM4IE1CKQpQaHlzaWNh bCBtZW1vcnkgY2h1bmsocyk6CjB4MDAwMDAwMDAwMDAwMTAwMCAtIDB4MDAwMDAwMDAwMDA5YmZm ZiwgNjM0ODgwIGJ5dGVzICgxNTUgcGFnZXMpCjB4MDAwMDAwMDAwMDEwMDAwMCAtIDB4MDAwMDAw MDAwMDNmZmZmZiwgMzE0NTcyOCBieXRlcyAoNzY4IHBhZ2VzKQoweDAwMDAwMDAwMDEwMjUwMDAg LSAweDAwMDAwMDAwN2IzMTRmZmYsIDIwNDk5MDA1NDQgYnl0ZXMgKDUwMDQ2NCBwYWdlcykKMHgw MDAwMDAwMDdkN2UwMDAwIC0gMHgwMDAwMDAwMDdmNjdlZmZmLCAzMjEwODU0NCBieXRlcyAoNzgz OSBwYWdlcykKYXZhaWwgbWVtb3J5ID0gMjA4MTM1MzcyOCAoMTk4NCBNQikKVGFibGUgJ0ZBQ1An IGF0IDB4N2Y3ZmIwMDAKVGFibGUgJ1RDUEEnIGF0IDB4N2Y3ZmQwMDAKVGFibGUgJ0FQSUMnIGF0 IDB4N2Y3ZjcwMDAKTUFEVDogRm91bmQgdGFibGUgYXQgMHg3ZjdmNzAwMApNUCBDb25maWd1cmF0 aW9uIFRhYmxlIHZlcnNpb24gMS40IGZvdW5kIGF0IDB4YzAwZTM0ZTAKQVBJQzogVXNpbmcgdGhl IE1BRFQgZW51bWVyYXRvci4KTUFEVDogRm91bmQgQ1BVIEFQSUMgSUQgMCBBQ1BJIElEIDA6IGVu YWJsZWQKU01QOiBBZGRlZCBDUFUgMCAoQVApCk1BRFQ6IEZvdW5kIENQVSBBUElDIElEIDIgQUNQ SSBJRCAxOiBlbmFibGVkClNNUDogQWRkZWQgQ1BVIDIgKEFQKQpNQURUOiBGb3VuZCBDUFUgQVBJ QyBJRCA0IEFDUEkgSUQgMjogZW5hYmxlZApTTVA6IEFkZGVkIENQVSA0IChBUCkKTUFEVDogRm91 bmQgQ1BVIEFQSUMgSUQgNiBBQ1BJIElEIDM6IGVuYWJsZWQKU01QOiBBZGRlZCBDUFUgNiAoQVAp Ck1BRFQ6IEZvdW5kIENQVSBBUElDIElEIDE2IEFDUEkgSUQgNDogZGlzYWJsZWQKTUFEVDogRm91 bmQgQ1BVIEFQSUMgSUQgMTggQUNQSSBJRCA1OiBkaXNhYmxlZApNQURUOiBGb3VuZCBDUFUgQVBJ QyBJRCAyMCBBQ1BJIElEIDY6IGRpc2FibGVkCk1BRFQ6IEZvdW5kIENQVSBBUElDIElEIDIyIEFD UEkgSUQgNzogZGlzYWJsZWQKTUFEVDogRm91bmQgQ1BVIEFQSUMgSUQgMSBBQ1BJIElEIDg6IGVu YWJsZWQKU01QOiBBZGRlZCBDUFUgMSAoQVApCk1BRFQ6IEZvdW5kIENQVSBBUElDIElEIDMgQUNQ SSBJRCA5OiBlbmFibGVkClNNUDogQWRkZWQgQ1BVIDMgKEFQKQpNQURUOiBGb3VuZCBDUFUgQVBJ QyBJRCA1IEFDUEkgSUQgMTA6IGVuYWJsZWQKU01QOiBBZGRlZCBDUFUgNSAoQVApCk1BRFQ6IEZv dW5kIENQVSBBUElDIElEIDcgQUNQSSBJRCAxMTogZW5hYmxlZApTTVA6IEFkZGVkIENQVSA3IChB UCkKTUFEVDogRm91bmQgQ1BVIEFQSUMgSUQgMTcgQUNQSSBJRCAxMjogZGlzYWJsZWQKTUFEVDog Rm91bmQgQ1BVIEFQSUMgSUQgMTkgQUNQSSBJRCAxMzogZGlzYWJsZWQKTUFEVDogRm91bmQgQ1BV IEFQSUMgSUQgMjEgQUNQSSBJRCAxNDogZGlzYWJsZWQKTUFEVDogRm91bmQgQ1BVIEFQSUMgSUQg MjMgQUNQSSBJRCAxNTogZGlzYWJsZWQKQUNQSSBBUElDIFRhYmxlOiA8SUJNICAgIFRIVVJMRVkg PgpJTlRSOiBBZGRpbmcgbG9jYWwgQVBJQyAyIGFzIGEgdGFyZ2V0CklOVFI6IEFkZGluZyBsb2Nh bCBBUElDIDQgYXMgYSB0YXJnZXQKSU5UUjogQWRkaW5nIGxvY2FsIEFQSUMgNiBhcyBhIHRhcmdl dApGcmVlQlNEL1NNUDogTXVsdGlwcm9jZXNzb3IgU3lzdGVtIERldGVjdGVkOiA4IENQVXMKIGNw dTAgKEJTUCk6IEFQSUMgSUQ6ICAwCiBjcHUxIChBUC9IVCk6IEFQSUMgSUQ6ICAxCiBjcHUyIChB UCk6IEFQSUMgSUQ6ICAyCiBjcHUzIChBUC9IVCk6IEFQSUMgSUQ6ICAzCiBjcHU0IChBUCk6IEFQ SUMgSUQ6ICA0CiBjcHU1IChBUC9IVCk6IEFQSUMgSUQ6ICA1CiBjcHU2IChBUCk6IEFQSUMgSUQ6 ICA2CiBjcHU3IChBUC9IVCk6IEFQSUMgSUQ6ICA3CmJpb3MzMjogRm91bmQgQklPUzMyIFNlcnZp Y2UgRGlyZWN0b3J5IGhlYWRlciBhdCAweGMwMGZkNmQwCmJpb3MzMjogRW50cnkgPSAweGZkNmUx IChjMDBmZDZlMSkgIFJldiA9IDAgIExlbiA9IDEKcGNpYmlvczogUENJIEJJT1MgZW50cnkgYXQg MHhmMDAwMCsweGQ3MWUKcG5wYmlvczogRm91bmQgUG5QIEJJT1MgZGF0YSBhdCAweGMwMGZkZmEw CnBucGJpb3M6IEVudHJ5ID0gZjAwMDA6NTUzYiAgUmV2ID0gMS4wCk90aGVyIEJJT1Mgc2lnbmF0 dXJlcyBmb3VuZDoKQVBJQzogQ1BVIDAgaGFzIEFDUEkgSUQgMApBUElDOiBDUFUgMSBoYXMgQUNQ SSBJRCA4CkFQSUM6IENQVSAyIGhhcyBBQ1BJIElEIDEKQVBJQzogQ1BVIDMgaGFzIEFDUEkgSUQg OQpBUElDOiBDUFUgNCBoYXMgQUNQSSBJRCAyCkFQSUM6IENQVSA1IGhhcyBBQ1BJIElEIDEwCkFQ SUM6IENQVSA2IGhhcyBBQ1BJIElEIDMKQVBJQzogQ1BVIDcgaGFzIEFDUEkgSUQgMTEKVUxFOiBz ZXR1cCBjcHUgZ3JvdXAgMApVTEU6IHNldHVwIGNwdSAwClVMRTogYWRkaW5nIGNwdSAwIHRvIGdy b3VwIDA6IGNwdXMgMSBtYXNrIDB4MQpVTEU6IHNldHVwIGNwdSAxClVMRTogYWRkaW5nIGNwdSAx IHRvIGdyb3VwIDA6IGNwdXMgMiBtYXNrIDB4MwpVTEU6IHNldHVwIGNwdSBncm91cCAxClVMRTog c2V0dXAgY3B1IDIKVUxFOiBhZGRpbmcgY3B1IDIgdG8gZ3JvdXAgMTogY3B1cyAxIG1hc2sgMHg0 ClVMRTogc2V0dXAgY3B1IDMKVUxFOiBhZGRpbmcgY3B1IDMgdG8gZ3JvdXAgMTogY3B1cyAyIG1h c2sgMHhDClVMRTogc2V0dXAgY3B1IGdyb3VwIDIKVUxFOiBzZXR1cCBjcHUgNApVTEU6IGFkZGlu ZyBjcHUgNCB0byBncm91cCAyOiBjcHVzIDEgbWFzayAweDEwClVMRTogc2V0dXAgY3B1IDUKVUxF OiBhZGRpbmcgY3B1IDUgdG8gZ3JvdXAgMjogY3B1cyAyIG1hc2sgMHgzMApVTEU6IHNldHVwIGNw dSBncm91cCAzClVMRTogc2V0dXAgY3B1IDYKVUxFOiBhZGRpbmcgY3B1IDYgdG8gZ3JvdXAgMzog Y3B1cyAxIG1hc2sgMHg0MApVTEU6IHNldHVwIGNwdSA3ClVMRTogYWRkaW5nIGNwdSA3IHRvIGdy b3VwIDM6IGNwdXMgMiBtYXNrIDB4QzAKQUNQSTogUlNEUCBAIDB4MHhmZGZkMC8weDAwMjQgKHYg IDIgSUJNICAgKQpBQ1BJOiBYU0RUIEAgMHgweDdmN2ZlMTIwLzB4MDA3NCAodiAgMSBJQk0gICAg VEhVUkxFWSAgMHgwMDAwMDAwMCAgICAgIDB4MDEwMDAwMTMpCkFDUEk6IEZBQ1AgQCAweDB4N2Y3 ZmIwMDAvMHgwMEY0ICh2ICA0IElCTSAgICBUSFVSTEVZICAweDAwMDAwMDAwIElCTSAgMHgwMTAw MDAxMykKQUNQSTogRFNEVCBAIDB4MHg3ZjdmODAwMC8weDI4ODUgKHYgIDEgSUJNICAgIFRIVVJM RVkgIDB4MDAwMDAwMDMgSUJNICAweDAxMDAwMDEzKQpBQ1BJOiBGQUNTIEAgMHgweDdmNzM1MDAw LzB4MDA0MApBQ1BJOiBUQ1BBIEAgMHgweDdmN2ZkMDAwLzB4MDA2NCAodiAgMCAgICAgICAgICAg ICAgICAgMHgwMDAwMDAwMCAgICAgIDB4MDAwMDAwMDApCkFDUEk6IEFQSUMgQCAweDB4N2Y3Zjcw MDAvMHgwMERFICh2ICAyIElCTSAgICBUSFVSTEVZICAweDAwMDAwMDAwIElCTSAgMHgwMTAwMDAx MykKQUNQSTogTUNGRyBAIDB4MHg3ZjdmNjAwMC8weDAwM0MgKHYgIDEgSUJNICAgIFRIVVJMRVkg IDB4MDAwMDAwMDEgSUJNICAweDAxMDAwMDEzKQpBQ1BJOiBTTElDIEAgMHgweDdmN2Y1MDAwLzB4 MDE3NiAodiAgMSBJQk0gICAgVEhVUkxFWSAgMHgwMDAwMDAwMCBJQk0gIDB4MDEwMDAwMTMpCkFD UEk6IEhQRVQgQCAweDB4N2Y3ZjQwMDAvMHgwMDM4ICh2ICAxIElCTSAgICBUSFVSTEVZICAweDAw MDAwMDAxIElCTSAgMHgwMTAwMDAxMykKQUNQSTogU1NEVCBAIDB4MHg3ZjdmMzAwMC8weDAxMTMg KHYgIDIgSUJNICAgIENQVVNDT1BFIDB4MDAwMDQwMDAgSUJNICAweDAxMDAwMDEzKQpBQ1BJOiBT U0RUIEAgMHgweDdmN2YyMDAwLzB4MEIyNCAodiAgMiBJQk0gICAgUFNUQVRFUE0gMHgwMDAwNDAw MCBJQk0gIDB4MDEwMDAwMTMpCkFDUEk6IEVSU1QgQCAweDB4N2Y3ZjEwMDAvMHgwMjMwICh2ICAx IElCTSAgICBUSFVSTEVZICAweDAwMDAwMDAxIElCTSAgMHgwMTAwMDAxMykKQUNQSTogRE1BUiBA IDB4MHg3ZjdmMDAwMC8weDAwODggKHYgIDEgSUJNICAgIFRIVVJMRVkgIDB4MDAwMDAwMDEgSUJN ICAweDAxMDAwMDEzKQpNQURUOiBGb3VuZCBJTyBBUElDIElEIDgsIEludGVycnVwdCAwIGF0IDB4 ZmVjMDAwMDAKaW9hcGljMDogUm91dGluZyBleHRlcm5hbCA4MjU5QSdzIC0+IGludHBpbiAwCk1B RFQ6IEZvdW5kIElPIEFQSUMgSUQgOSwgSW50ZXJydXB0IDI0IGF0IDB4ZmVjODAwMDAKTUFEVDog SW50ZXJydXB0IG92ZXJyaWRlOiBzb3VyY2UgMCwgaXJxIDIKaW9hcGljMDogUm91dGluZyBJUlEg MCAtPiBpbnRwaW4gMgpNQURUOiBJbnRlcnJ1cHQgb3ZlcnJpZGU6IHNvdXJjZSA5LCBpcnEgOQpp b2FwaWMwOiBpbnRwaW4gOSB0cmlnZ2VyOiBsZXZlbApsYXBpYzogUm91dGluZyBOTUkgLT4gTElO VDEKbGFwaWM6IExJTlQxIHRyaWdnZXI6IGVkZ2UKbGFwaWM6IExJTlQxIHBvbGFyaXR5OiBoaWdo CmlvYXBpYzAgPFZlcnNpb24gMi4wPiBpcnFzIDAtMjMgb24gbW90aGVyYm9hcmQKaW9hcGljMSA8 VmVyc2lvbiAyLjA+IGlycXMgMjQtNDcgb24gbW90aGVyYm9hcmQKY3B1MCBCU1A6CiAgICAgSUQ6 IDB4MDAwMDAwMDAgICBWRVI6IDB4MDAwNjAwMTUgTERSOiAweDAwMDAwMDAwIERGUjogMHhmZmZm ZmZmZgogIGxpbnQwOiAweDAwMDEwNzAwIGxpbnQxOiAweDAwMDAwNDAwIFRQUjogMHgwMDAwMDAw MCBTVlI6IDB4MDAwMDAxZmYKICB0aW1lcjogMHgwMDAxMDBlZiB0aGVybTogMHgwMDAxMDAwMCBl cnI6IDB4MDAwMTAwMDAgcGNtOiAweDAwMDEwMDAwCndsYW5fYW1ycjogPEFNUlIgVHJhbnNtaXQg UmF0ZSBDb250cm9sIEFsZ29yaXRobT4Kd2xhbjogPDgwMi4xMSBMaW5rIExheWVyPgpudWxsOiA8 bnVsbCBkZXZpY2UsIHplcm8gZGV2aWNlPgpyYW5kb206IDxlbnRyb3B5IHNvdXJjZSwgU29mdHdh cmUsIFlhcnJvdz4KbmZzbG9jazogcHNldWRvLWRldmljZQppbzogPEkvTz4Ka2JkOiBuZXcgYXJy YXkgc2l6ZSA0CmtiZDEgYXQga2JkbXV4MAptZW06IDxtZW1vcnk+ClBlbnRpdW0gUHJvIE1UUlIg c3VwcG9ydCBlbmFibGVkCmhwdHJyOiBSb2NrZXRSQUlEIDE3eHgvMnh4eCBTQVRBIGNvbnRyb2xs ZXIgZHJpdmVyIHYxLjIgKE1heSAgMSAyMDA5IDA4OjQ3OjI0KQpucHgwOiBJTlQgMTYgaW50ZXJm YWNlCmFjcGkwOiA8SUJNIFRIVVJMRVk+IG9uIG1vdGhlcmJvYXJkCmlvYXBpYzA6IHJvdXRpbmcg aW50cGluIDkgKElTQSBJUlEgOSkgdG8gdmVjdG9yIDQ4CmFjcGkwOiBbTVBTQUZFXQphY3BpMDog W0lUSFJFQURdCmFjcGkwOiBQb3dlciBCdXR0b24gKGZpeGVkKQphY3BpMDogd2FrZXVwIGNvZGUg dmEgMHhjNTA3NzAwMCBwYSAweDEwMDAKcGNpX29wZW4oMSk6CW1vZGUgMSBhZGRyIHBvcnQgKDB4 MGNmOCkgaXMgMHgwMDAwMDAwMApwY2lfb3BlbigxYSk6CW1vZGUxcmVzPTB4ODAwMDAwMDAgKDB4 ODAwMDAwMDApCnBjaV9jZmdjaGVjazoJZGV2aWNlIDAgW2NsYXNzPTA2MDAwMF0gW2hkcj0wMF0g aXMgdGhlcmUgKGlkPTM0MDY4MDg2KQpwY2liaW9zOiBCSU9TIHZlcnNpb24gMy4wMApBY3BpT3NE ZXJpdmVQY2lJZDogXFxfU0JfLlBDSTAuTFBDMC5QUlIwIC0+IGJ1cyAwIGRldiAzMSBmdW5jIDAK QWNwaU9zRGVyaXZlUGNpSWQ6IFxcX1NCXy5QQ0kwLkxQQzAuUFJSMSAtPiBidXMgMCBkZXYgMzEg ZnVuYyAwCmFjcGlfaHBldDA6IHZlbmQ6IDB4ODA4NiByZXY6IDB4MSBudW06IDMgaHo6IDE0MzE4 MTgwIG9wdHM6IGxlZ2FjeV9yb3V0ZSA2NC1iaXQKVGltZWNvdW50ZXIgIkhQRVQiIGZyZXF1ZW5j eSAxNDMxODE4MCBIeiBxdWFsaXR5IDkwMApBQ1BJIHRpbWVyOiAxLzIgMS8wIDEvMiAxLzEgMS8y IDEvMCAxLzAgMS8yIDEvMCAxLzEgLT4gMTAKVGltZWNvdW50ZXIgIkFDUEktZmFzdCIgZnJlcXVl bmN5IDM1Nzk1NDUgSHogcXVhbGl0eSAxMDAwCmFjcGlfdGltZXIwOiA8MjQtYml0IHRpbWVyIGF0 IDMuNTc5NTQ1TUh6PiBwb3J0IDB4NTg4LTB4NThiIG9uIGFjcGkwCnBjaV9saW5rMDogICAgICAg IEluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCiAgSW5pdGlhbCBQcm9iZSAgICAgICAwICAgMTEg ICBOICAgICAwICAzIDQgNSA2IDcgOSAxMCAxMSAxMiAxNCAxNQogIFZhbGlkYXRpb24gICAgICAg ICAgMCAgIDExICAgTiAgICAgMCAgMyA0IDUgNiA3IDkgMTAgMTEgMTIgMTQgMTUKICBBZnRlciBE aXNhYmxlICAgICAgIDAgIDI1NSAgIE4gICAgIDAgIDMgNCA1IDYgNyA5IDEwIDExIDEyIDE0IDE1 CnBjaV9saW5rMTogICAgICAgIEluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCiAgSW5pdGlhbCBQ cm9iZSAgICAgICAwICAgMTAgICBOICAgICAwICAzIDQgNSA2IDcgOSAxMCAxMSAxMiAxNCAxNQog IFZhbGlkYXRpb24gICAgICAgICAgMCAgIDEwICAgTiAgICAgMCAgMyA0IDUgNiA3IDkgMTAgMTEg MTIgMTQgMTUKICBBZnRlciBEaXNhYmxlICAgICAgIDAgIDI1NSAgIE4gICAgIDAgIDMgNCA1IDYg NyA5IDEwIDExIDEyIDE0IDE1CnBjaV9saW5rMjogICAgICAgIEluZGV4ICBJUlEgIFJ0ZCAgUmVm ICBJUlFzCiAgSW5pdGlhbCBQcm9iZSAgICAgICAwICAgIDUgICBOICAgICAwICAzIDQgNSA2IDcg OSAxMCAxMSAxMiAxNCAxNQogIFZhbGlkYXRpb24gICAgICAgICAgMCAgICA1ICAgTiAgICAgMCAg MyA0IDUgNiA3IDkgMTAgMTEgMTIgMTQgMTUKICBBZnRlciBEaXNhYmxlICAgICAgIDAgIDI1NSAg IE4gICAgIDAgIDMgNCA1IDYgNyA5IDEwIDExIDEyIDE0IDE1CnBjaV9saW5rMzogICAgICAgIElu ZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCiAgSW5pdGlhbCBQcm9iZSAgICAgICAwICAgMTEgICBO ICAgICAwICAzIDQgNSA2IDcgOSAxMCAxMSAxMiAxNCAxNQogIFZhbGlkYXRpb24gICAgICAgICAg MCAgIDExICAgTiAgICAgMCAgMyA0IDUgNiA3IDkgMTAgMTEgMTIgMTQgMTUKICBBZnRlciBEaXNh YmxlICAgICAgIDAgIDI1NSAgIE4gICAgIDAgIDMgNCA1IDYgNyA5IDEwIDExIDEyIDE0IDE1CnBj aV9saW5rNDogICAgICAgIEluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCiAgSW5pdGlhbCBQcm9i ZSAgICAgICAwICAyNTUgICBOICAgICAwICAzIDQgNSA2IDcgOSAxMCAxMSAxMiAxNCAxNQogIFZh bGlkYXRpb24gICAgICAgICAgMCAgMjU1ICAgTiAgICAgMCAgMyA0IDUgNiA3IDkgMTAgMTEgMTIg MTQgMTUKICBBZnRlciBEaXNhYmxlICAgICAgIDAgIDI1NSAgIE4gICAgIDAgIDMgNCA1IDYgNyA5 IDEwIDExIDEyIDE0IDE1CnBjaV9saW5rNTogICAgICAgIEluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJ UlFzCiAgSW5pdGlhbCBQcm9iZSAgICAgICAwICAgMTEgICBOICAgICAwICAzIDQgNSA2IDcgOSAx MCAxMSAxMiAxNCAxNQogIFZhbGlkYXRpb24gICAgICAgICAgMCAgIDExICAgTiAgICAgMCAgMyA0 IDUgNiA3IDkgMTAgMTEgMTIgMTQgMTUKICBBZnRlciBEaXNhYmxlICAgICAgIDAgIDI1NSAgIE4g ICAgIDAgIDMgNCA1IDYgNyA5IDEwIDExIDEyIDE0IDE1CnBjaV9saW5rNjogICAgICAgIEluZGV4 ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCiAgSW5pdGlhbCBQcm9iZSAgICAgICAwICAgMTEgICBOICAg ICAwICAzIDQgNSA2IDcgOSAxMCAxMSAxMiAxNCAxNQogIFZhbGlkYXRpb24gICAgICAgICAgMCAg IDExICAgTiAgICAgMCAgMyA0IDUgNiA3IDkgMTAgMTEgMTIgMTQgMTUKICBBZnRlciBEaXNhYmxl ICAgICAgIDAgIDI1NSAgIE4gICAgIDAgIDMgNCA1IDYgNyA5IDEwIDExIDEyIDE0IDE1CnBjaV9s aW5rNzogICAgICAgIEluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCiAgSW5pdGlhbCBQcm9iZSAg ICAgICAwICAyNTUgICBOICAgICAwICAzIDQgNSA2IDcgOSAxMCAxMSAxMiAxNCAxNQogIFZhbGlk YXRpb24gICAgICAgICAgMCAgMjU1ICAgTiAgICAgMCAgMyA0IDUgNiA3IDkgMTAgMTEgMTIgMTQg MTUKICBBZnRlciBEaXNhYmxlICAgICAgIDAgIDI1NSAgIE4gICAgIDAgIDMgNCA1IDYgNyA5IDEw IDExIDEyIDE0IDE1CnBjaWIwOiA8QUNQSSBIb3N0LVBDSSBicmlkZ2U+IHBvcnQgMHhjZjgtMHhj ZmYgb24gYWNwaTAKcGNpMDogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjAKcGNpMDogZG9tYWluPTAs IHBoeXNpY2FsIGJ1cz0wCmZvdW5kLT4JdmVuZG9yPTB4ODA4NiwgZGV2PTB4MzQwNiwgcmV2aWQ9 MHgxMwoJZG9tYWluPTAsIGJ1cz0wLCBzbG90PTAsIGZ1bmM9MAoJY2xhc3M9MDYtMDAtMDAsIGhk cnR5cGU9MHgwMCwgbWZkZXY9MAoJY21kcmVnPTB4MDA0MCwgc3RhdHJlZz0weDAwMTAsIGNhY2hl bG5zej0xNiAoZHdvcmRzKQoJbGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDAwICgwIG5z KSwgbWF4bGF0PTB4MDAgKDAgbnMpCglpbnRwaW49YSwgaXJxPTExCglwb3dlcnNwZWMgMyAgc3Vw cG9ydHMgRDAgRDMgIGN1cnJlbnQgRDAKCU1TSSBzdXBwb3J0cyAyIG1lc3NhZ2VzLCB2ZWN0b3Ig bWFza3MKcGNpYjA6IG1hdGNoZWQgZW50cnkgZm9yIDAuMC5JTlRBCnBjaWIwOiBzbG90IDAgSU5U QSBoYXJkd2lyZWQgdG8gSVJRIDE2CmZvdW5kLT4JdmVuZG9yPTB4ODA4NiwgZGV2PTB4MzQwOCwg cmV2aWQ9MHgxMwoJZG9tYWluPTAsIGJ1cz0wLCBzbG90PTEsIGZ1bmM9MAoJY2xhc3M9MDYtMDQt MDAsIGhkcnR5cGU9MHgwMSwgbWZkZXY9MAoJY21kcmVnPTB4MDA0Nywgc3RhdHJlZz0weDAwMTAs IGNhY2hlbG5zej0xNiAoZHdvcmRzKQoJbGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDAz ICg3NTAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKCWludHBpbj1hLCBpcnE9MTEKCXBvd2Vyc3Bl YyAzICBzdXBwb3J0cyBEMCBEMyAgY3VycmVudCBEMAoJTVNJIHN1cHBvcnRzIDIgbWVzc2FnZXMs IHZlY3RvciBtYXNrcwpwY2liMDogbWF0Y2hlZCBlbnRyeSBmb3IgMC4xLklOVEEKcGNpYjA6IHNs b3QgMSBJTlRBIGhhcmR3aXJlZCB0byBJUlEgMjgKZm91bmQtPgl2ZW5kb3I9MHg4MDg2LCBkZXY9 MHgzNDA5LCByZXZpZD0weDEzCglkb21haW49MCwgYnVzPTAsIHNsb3Q9MiwgZnVuYz0wCgljbGFz cz0wNi0wNC0wMCwgaGRydHlwZT0weDAxLCBtZmRldj0wCgljbWRyZWc9MHgwMDQwLCBzdGF0cmVn PTB4MDAxMCwgY2FjaGVsbnN6PTE2IChkd29yZHMpCglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWlu Z250PTB4MDMgKDc1MCBucyksIG1heGxhdD0weDAwICgwIG5zKQoJaW50cGluPWEsIGlycT0xMQoJ cG93ZXJzcGVjIDMgIHN1cHBvcnRzIEQwIEQzICBjdXJyZW50IEQwCglNU0kgc3VwcG9ydHMgMiBt ZXNzYWdlcywgdmVjdG9yIG1hc2tzCnBjaWIwOiBtYXRjaGVkIGVudHJ5IGZvciAwLjIuSU5UQQpw Y2liMDogc2xvdCAyIElOVEEgaGFyZHdpcmVkIHRvIElSUSAyOQpmb3VuZC0+CXZlbmRvcj0weDgw ODYsIGRldj0weDM0MGEsIHJldmlkPTB4MTMKCWRvbWFpbj0wLCBidXM9MCwgc2xvdD0zLCBmdW5j PTAKCWNsYXNzPTA2LTA0LTAwLCBoZHJ0eXBlPTB4MDEsIG1mZGV2PTAKCWNtZHJlZz0weDAwNDAs IHN0YXRyZWc9MHgwMDEwLCBjYWNoZWxuc3o9MTYgKGR3b3JkcykKCWxhdHRpbWVyPTB4MDAgKDAg bnMpLCBtaW5nbnQ9MHgwMyAoNzUwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCglpbnRwaW49YSwg aXJxPTExCglwb3dlcnNwZWMgMyAgc3VwcG9ydHMgRDAgRDMgIGN1cnJlbnQgRDAKCU1TSSBzdXBw b3J0cyAyIG1lc3NhZ2VzLCB2ZWN0b3IgbWFza3MKcGNpYjA6IG1hdGNoZWQgZW50cnkgZm9yIDAu My5JTlRBCnBjaWIwOiBzbG90IDMgSU5UQSBoYXJkd2lyZWQgdG8gSVJRIDI0CmZvdW5kLT4JdmVu ZG9yPTB4ODA4NiwgZGV2PTB4MzQwYywgcmV2aWQ9MHgxMwoJZG9tYWluPTAsIGJ1cz0wLCBzbG90 PTUsIGZ1bmM9MAoJY2xhc3M9MDYtMDQtMDAsIGhkcnR5cGU9MHgwMSwgbWZkZXY9MAoJY21kcmVn PTB4MDA0MCwgc3RhdHJlZz0weDAwMTAsIGNhY2hlbG5zej0xNiAoZHdvcmRzKQoJbGF0dGltZXI9 MHgwMCAoMCBucyksIG1pbmdudD0weDAzICg3NTAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKCWlu dHBpbj1hLCBpcnE9MTEKCXBvd2Vyc3BlYyAzICBzdXBwb3J0cyBEMCBEMyAgY3VycmVudCBEMAoJ TVNJIHN1cHBvcnRzIDIgbWVzc2FnZXMsIHZlY3RvciBtYXNrcwpwY2liMDogbWF0Y2hlZCBlbnRy eSBmb3IgMC41LklOVEEKcGNpYjA6IHNsb3QgNSBJTlRBIGhhcmR3aXJlZCB0byBJUlEgMjYKZm91 bmQtPgl2ZW5kb3I9MHg4MDg2LCBkZXY9MHgzNDBlLCByZXZpZD0weDEzCglkb21haW49MCwgYnVz PTAsIHNsb3Q9NywgZnVuYz0wCgljbGFzcz0wNi0wNC0wMCwgaGRydHlwZT0weDAxLCBtZmRldj0w CgljbWRyZWc9MHgwMDQwLCBzdGF0cmVnPTB4MDAxMCwgY2FjaGVsbnN6PTE2IChkd29yZHMpCgls YXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MDMgKDc1MCBucyksIG1heGxhdD0weDAwICgw IG5zKQoJaW50cGluPWEsIGlycT0xMQoJcG93ZXJzcGVjIDMgIHN1cHBvcnRzIEQwIEQzICBjdXJy ZW50IEQwCglNU0kgc3VwcG9ydHMgMiBtZXNzYWdlcywgdmVjdG9yIG1hc2tzCnBjaWIwOiBtYXRj aGVkIGVudHJ5IGZvciAwLjcuSU5UQQpwY2liMDogc2xvdCA3IElOVEEgaGFyZHdpcmVkIHRvIElS USAzMApmb3VuZC0+CXZlbmRvcj0weDgwODYsIGRldj0weDM0MTAsIHJldmlkPTB4MTMKCWRvbWFp bj0wLCBidXM9MCwgc2xvdD05LCBmdW5jPTAKCWNsYXNzPTA2LTA0LTAwLCBoZHJ0eXBlPTB4MDEs IG1mZGV2PTAKCWNtZHJlZz0weDAwNDAsIHN0YXRyZWc9MHgwMDEwLCBjYWNoZWxuc3o9MTYgKGR3 b3JkcykKCWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9MHgwMyAoNzUwIG5zKSwgbWF4bGF0 PTB4MDAgKDAgbnMpCglpbnRwaW49YSwgaXJxPTExCglwb3dlcnNwZWMgMyAgc3VwcG9ydHMgRDAg RDMgIGN1cnJlbnQgRDAKCU1TSSBzdXBwb3J0cyAyIG1lc3NhZ2VzLCB2ZWN0b3IgbWFza3MKcGNp YjA6IG1hdGNoZWQgZW50cnkgZm9yIDAuOS5JTlRBCnBjaWIwOiBzbG90IDkgSU5UQSBoYXJkd2ly ZWQgdG8gSVJRIDMyCmZvdW5kLT4JdmVuZG9yPTB4ODA4NiwgZGV2PTB4MzQyNSwgcmV2aWQ9MHgx MwoJZG9tYWluPTAsIGJ1cz0wLCBzbG90PTE2LCBmdW5jPTAKCWNsYXNzPTA4LTAwLTAwLCBoZHJ0 eXBlPTB4MDAsIG1mZGV2PTEKCWNtZHJlZz0weDAwMDAsIHN0YXRyZWc9MHgwMDEwLCBjYWNoZWxu c3o9MTYgKGR3b3JkcykKCWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9MHgwMCAoMCBucyks IG1heGxhdD0weDAwICgwIG5zKQpmb3VuZC0+CXZlbmRvcj0weDgwODYsIGRldj0weDM0MjYsIHJl dmlkPTB4MTMKCWRvbWFpbj0wLCBidXM9MCwgc2xvdD0xNiwgZnVuYz0xCgljbGFzcz0wOC0wMC0w MCwgaGRydHlwZT0weDAwLCBtZmRldj0xCgljbWRyZWc9MHgwMDAwLCBzdGF0cmVnPTB4MDAwMCwg Y2FjaGVsbnN6PTE2IChkd29yZHMpCglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MDAg KDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKZm91bmQtPgl2ZW5kb3I9MHg4MDg2LCBkZXY9MHgz NDI3LCByZXZpZD0weDEzCglkb21haW49MCwgYnVzPTAsIHNsb3Q9MTcsIGZ1bmM9MAoJY2xhc3M9 MDgtMDAtMDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MQoJY21kcmVnPTB4MDAwMCwgc3RhdHJlZz0w eDAwMTAsIGNhY2hlbG5zej0xNiAoZHdvcmRzKQoJbGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdu dD0weDAwICgwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCmZvdW5kLT4JdmVuZG9yPTB4ODA4Niwg ZGV2PTB4MzQyOCwgcmV2aWQ9MHgxMwoJZG9tYWluPTAsIGJ1cz0wLCBzbG90PTE3LCBmdW5jPTEK CWNsYXNzPTA4LTAwLTAwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTEKCWNtZHJlZz0weDAwMDAsIHN0 YXRyZWc9MHgwMDAwLCBjYWNoZWxuc3o9MTYgKGR3b3JkcykKCWxhdHRpbWVyPTB4MDAgKDAgbnMp LCBtaW5nbnQ9MHgwMCAoMCBucyksIG1heGxhdD0weDAwICgwIG5zKQpmb3VuZC0+CXZlbmRvcj0w eDgwODYsIGRldj0weDM0MmUsIHJldmlkPTB4MTMKCWRvbWFpbj0wLCBidXM9MCwgc2xvdD0yMCwg ZnVuYz0wCgljbGFzcz0wOC0wMC0wMCwgaGRydHlwZT0weDAwLCBtZmRldj0xCgljbWRyZWc9MHgw MDAwLCBzdGF0cmVnPTB4MDAxMCwgY2FjaGVsbnN6PTE2IChkd29yZHMpCglsYXR0aW1lcj0weDAw ICgwIG5zKSwgbWluZ250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKZm91bmQtPgl2 ZW5kb3I9MHg4MDg2LCBkZXY9MHgzNDIyLCByZXZpZD0weDEzCglkb21haW49MCwgYnVzPTAsIHNs b3Q9MjAsIGZ1bmM9MQoJY2xhc3M9MDgtMDAtMDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MQoJY21k cmVnPTB4MDAwMCwgc3RhdHJlZz0weDAwMTAsIGNhY2hlbG5zej0xNiAoZHdvcmRzKQoJbGF0dGlt ZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDAwICgwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCmZv dW5kLT4JdmVuZG9yPTB4ODA4NiwgZGV2PTB4MzQyMywgcmV2aWQ9MHgxMwoJZG9tYWluPTAsIGJ1 cz0wLCBzbG90PTIwLCBmdW5jPTIKCWNsYXNzPTA4LTAwLTAwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2 PTEKCWNtZHJlZz0weDAwMDAsIHN0YXRyZWc9MHgwMDEwLCBjYWNoZWxuc3o9MTYgKGR3b3JkcykK CWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9MHgwMCAoMCBucyksIG1heGxhdD0weDAwICgw IG5zKQpmb3VuZC0+CXZlbmRvcj0weDgwODYsIGRldj0weDM0MzgsIHJldmlkPTB4MTMKCWRvbWFp bj0wLCBidXM9MCwgc2xvdD0yMCwgZnVuYz0zCgljbGFzcz0wOC0wMC0wMCwgaGRydHlwZT0weDAw LCBtZmRldj0xCgljbWRyZWc9MHgwMDAwLCBzdGF0cmVnPTB4MDAwMCwgY2FjaGVsbnN6PTE2IChk d29yZHMpCglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9 MHgwMCAoMCBucykKZm91bmQtPgl2ZW5kb3I9MHg4MDg2LCBkZXY9MHgzNDJmLCByZXZpZD0weDEz Cglkb21haW49MCwgYnVzPTAsIHNsb3Q9MjEsIGZ1bmM9MAoJY2xhc3M9MDgtMDAtMjAsIGhkcnR5 cGU9MHgwMCwgbWZkZXY9MQoJY21kcmVnPTB4MDAwMCwgc3RhdHJlZz0weDAwMDAsIGNhY2hlbG5z ej0xNiAoZHdvcmRzKQoJbGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDAwICgwIG5zKSwg bWF4bGF0PTB4MDAgKDAgbnMpCmZvdW5kLT4JdmVuZG9yPTB4ODA4NiwgZGV2PTB4MzQzMCwgcmV2 aWQ9MHgxMwoJZG9tYWluPTAsIGJ1cz0wLCBzbG90PTIyLCBmdW5jPTAKCWNsYXNzPTA4LTgwLTAw LCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTEKCWNtZHJlZz0weDAwMDYsIHN0YXRyZWc9MHgwMDEwLCBj YWNoZWxuc3o9MTYgKGR3b3JkcykKCWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9MHgwMCAo MCBucyksIG1heGxhdD0weDAwICgwIG5zKQoJaW50cGluPWEsIGlycT0xMQoJcG93ZXJzcGVjIDMg IHN1cHBvcnRzIEQwIEQzICBjdXJyZW50IEQwCglNU0ktWCBzdXBwb3J0cyAxIG1lc3NhZ2UgaW4g bWFwIDB4MTAKCW1hcFsxMF06IHR5cGUgTWVtb3J5LCByYW5nZSA2NCwgYmFzZSAweDk3YTAwMDAw LCBzaXplIDE0LCBlbmFibGVkCnBjaWIwOiBtYXRjaGVkIGVudHJ5IGZvciAwLjIyLklOVEEKcGNp YjA6IHNsb3QgMjIgSU5UQSBoYXJkd2lyZWQgdG8gSVJRIDE2CmZvdW5kLT4JdmVuZG9yPTB4ODA4 NiwgZGV2PTB4MzQzMSwgcmV2aWQ9MHgxMwoJZG9tYWluPTAsIGJ1cz0wLCBzbG90PTIyLCBmdW5j PTEKCWNsYXNzPTA4LTgwLTAwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTEKCWNtZHJlZz0weDAwMDYs IHN0YXRyZWc9MHgwMDEwLCBjYWNoZWxuc3o9MTYgKGR3b3JkcykKCWxhdHRpbWVyPTB4MDAgKDAg bnMpLCBtaW5nbnQ9MHgwMCAoMCBucyksIG1heGxhdD0weDAwICgwIG5zKQoJaW50cGluPWIsIGly cT0xMAoJcG93ZXJzcGVjIDMgIHN1cHBvcnRzIEQwIEQzICBjdXJyZW50IEQwCglNU0ktWCBzdXBw b3J0cyAxIG1lc3NhZ2UgaW4gbWFwIDB4MTAKCW1hcFsxMF06IHR5cGUgTWVtb3J5LCByYW5nZSA2 NCwgYmFzZSAweDk3YTA0MDAwLCBzaXplIDE0LCBlbmFibGVkCnBjaWIwOiBtYXRjaGVkIGVudHJ5 IGZvciAwLjIyLklOVEIKcGNpYjA6IHNsb3QgMjIgSU5UQiBoYXJkd2lyZWQgdG8gSVJRIDE3CmZv dW5kLT4JdmVuZG9yPTB4ODA4NiwgZGV2PTB4MzQzMiwgcmV2aWQ9MHgxMwoJZG9tYWluPTAsIGJ1 cz0wLCBzbG90PTIyLCBmdW5jPTIKCWNsYXNzPTA4LTgwLTAwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2 PTEKCWNtZHJlZz0weDAwMDYsIHN0YXRyZWc9MHgwMDEwLCBjYWNoZWxuc3o9MTYgKGR3b3JkcykK CWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9MHgwMCAoMCBucyksIG1heGxhdD0weDAwICgw IG5zKQoJaW50cGluPWMsIGlycT01Cglwb3dlcnNwZWMgMyAgc3VwcG9ydHMgRDAgRDMgIGN1cnJl bnQgRDAKCU1TSS1YIHN1cHBvcnRzIDEgbWVzc2FnZSBpbiBtYXAgMHgxMAoJbWFwWzEwXTogdHlw ZSBNZW1vcnksIHJhbmdlIDY0LCBiYXNlIDB4OTdhMDgwMDAsIHNpemUgMTQsIGVuYWJsZWQKcGNp YjA6IG1hdGNoZWQgZW50cnkgZm9yIDAuMjIuSU5UQwpwY2liMDogc2xvdCAyMiBJTlRDIGhhcmR3 aXJlZCB0byBJUlEgMTgKZm91bmQtPgl2ZW5kb3I9MHg4MDg2LCBkZXY9MHgzNDMzLCByZXZpZD0w eDEzCglkb21haW49MCwgYnVzPTAsIHNsb3Q9MjIsIGZ1bmM9MwoJY2xhc3M9MDgtODAtMDAsIGhk cnR5cGU9MHgwMCwgbWZkZXY9MQoJY21kcmVnPTB4MDAwNiwgc3RhdHJlZz0weDAwMTAsIGNhY2hl bG5zej0xNiAoZHdvcmRzKQoJbGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDAwICgwIG5z KSwgbWF4bGF0PTB4MDAgKDAgbnMpCglpbnRwaW49ZCwgaXJxPTExCglwb3dlcnNwZWMgMyAgc3Vw cG9ydHMgRDAgRDMgIGN1cnJlbnQgRDAKCU1TSS1YIHN1cHBvcnRzIDEgbWVzc2FnZSBpbiBtYXAg MHgxMAoJbWFwWzEwXTogdHlwZSBNZW1vcnksIHJhbmdlIDY0LCBiYXNlIDB4OTdhMGMwMDAsIHNp emUgMTQsIGVuYWJsZWQKcGNpYjA6IG1hdGNoZWQgZW50cnkgZm9yIDAuMjIuSU5URApwY2liMDog c2xvdCAyMiBJTlREIGhhcmR3aXJlZCB0byBJUlEgMTkKZm91bmQtPgl2ZW5kb3I9MHg4MDg2LCBk ZXY9MHgzNDI5LCByZXZpZD0weDEzCglkb21haW49MCwgYnVzPTAsIHNsb3Q9MjIsIGZ1bmM9NAoJ Y2xhc3M9MDgtODAtMDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MQoJY21kcmVnPTB4MDAwNiwgc3Rh dHJlZz0weDAwMTAsIGNhY2hlbG5zej0xNiAoZHdvcmRzKQoJbGF0dGltZXI9MHgwMCAoMCBucyks IG1pbmdudD0weDAwICgwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCglpbnRwaW49YSwgaXJxPTEx Cglwb3dlcnNwZWMgMyAgc3VwcG9ydHMgRDAgRDMgIGN1cnJlbnQgRDAKCU1TSS1YIHN1cHBvcnRz IDEgbWVzc2FnZSBpbiBtYXAgMHgxMAoJbWFwWzEwXTogdHlwZSBNZW1vcnksIHJhbmdlIDY0LCBi YXNlIDB4OTdhMTAwMDAsIHNpemUgMTQsIGVuYWJsZWQKcGNpYjA6IG1hdGNoZWQgZW50cnkgZm9y IDAuMjIuSU5UQQpwY2liMDogc2xvdCAyMiBJTlRBIGhhcmR3aXJlZCB0byBJUlEgMTYKZm91bmQt Pgl2ZW5kb3I9MHg4MDg2LCBkZXY9MHgzNDJhLCByZXZpZD0weDEzCglkb21haW49MCwgYnVzPTAs IHNsb3Q9MjIsIGZ1bmM9NQoJY2xhc3M9MDgtODAtMDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MQoJ Y21kcmVnPTB4MDAwNiwgc3RhdHJlZz0weDAwMTAsIGNhY2hlbG5zej0xNiAoZHdvcmRzKQoJbGF0 dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDAwICgwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMp CglpbnRwaW49YiwgaXJxPTEwCglwb3dlcnNwZWMgMyAgc3VwcG9ydHMgRDAgRDMgIGN1cnJlbnQg RDAKCU1TSS1YIHN1cHBvcnRzIDEgbWVzc2FnZSBpbiBtYXAgMHgxMAoJbWFwWzEwXTogdHlwZSBN ZW1vcnksIHJhbmdlIDY0LCBiYXNlIDB4OTdhMTQwMDAsIHNpemUgMTQsIGVuYWJsZWQKcGNpYjA6 IG1hdGNoZWQgZW50cnkgZm9yIDAuMjIuSU5UQgpwY2liMDogc2xvdCAyMiBJTlRCIGhhcmR3aXJl ZCB0byBJUlEgMTcKZm91bmQtPgl2ZW5kb3I9MHg4MDg2LCBkZXY9MHgzNDJiLCByZXZpZD0weDEz Cglkb21haW49MCwgYnVzPTAsIHNsb3Q9MjIsIGZ1bmM9NgoJY2xhc3M9MDgtODAtMDAsIGhkcnR5 cGU9MHgwMCwgbWZkZXY9MQoJY21kcmVnPTB4MDAwNiwgc3RhdHJlZz0weDAwMTAsIGNhY2hlbG5z ej0xNiAoZHdvcmRzKQoJbGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDAwICgwIG5zKSwg bWF4bGF0PTB4MDAgKDAgbnMpCglpbnRwaW49YywgaXJxPTUKCXBvd2Vyc3BlYyAzICBzdXBwb3J0 cyBEMCBEMyAgY3VycmVudCBEMAoJTVNJLVggc3VwcG9ydHMgMSBtZXNzYWdlIGluIG1hcCAweDEw CgltYXBbMTBdOiB0eXBlIE1lbW9yeSwgcmFuZ2UgNjQsIGJhc2UgMHg5N2ExODAwMCwgc2l6ZSAx NCwgZW5hYmxlZApwY2liMDogbWF0Y2hlZCBlbnRyeSBmb3IgMC4yMi5JTlRDCnBjaWIwOiBzbG90 IDIyIElOVEMgaGFyZHdpcmVkIHRvIElSUSAxOApmb3VuZC0+CXZlbmRvcj0weDgwODYsIGRldj0w eDM0MmMsIHJldmlkPTB4MTMKCWRvbWFpbj0wLCBidXM9MCwgc2xvdD0yMiwgZnVuYz03CgljbGFz cz0wOC04MC0wMCwgaGRydHlwZT0weDAwLCBtZmRldj0xCgljbWRyZWc9MHgwMDA2LCBzdGF0cmVn PTB4MDAxMCwgY2FjaGVsbnN6PTE2IChkd29yZHMpCglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWlu Z250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKCWludHBpbj1kLCBpcnE9MTEKCXBv d2Vyc3BlYyAzICBzdXBwb3J0cyBEMCBEMyAgY3VycmVudCBEMAoJTVNJLVggc3VwcG9ydHMgMSBt ZXNzYWdlIGluIG1hcCAweDEwCgltYXBbMTBdOiB0eXBlIE1lbW9yeSwgcmFuZ2UgNjQsIGJhc2Ug MHg5N2ExYzAwMCwgc2l6ZSAxNCwgZW5hYmxlZApwY2liMDogbWF0Y2hlZCBlbnRyeSBmb3IgMC4y Mi5JTlRECnBjaWIwOiBzbG90IDIyIElOVEQgaGFyZHdpcmVkIHRvIElSUSAxOQpmb3VuZC0+CXZl bmRvcj0weDgwODYsIGRldj0weDNhMzcsIHJldmlkPTB4MDAKCWRvbWFpbj0wLCBidXM9MCwgc2xv dD0yNiwgZnVuYz0wCgljbGFzcz0wYy0wMy0wMCwgaGRydHlwZT0weDAwLCBtZmRldj0xCgljbWRy ZWc9MHgwMDA1LCBzdGF0cmVnPTB4MDI5MCwgY2FjaGVsbnN6PTAgKGR3b3JkcykKCWxhdHRpbWVy PTB4MDAgKDAgbnMpLCBtaW5nbnQ9MHgwMCAoMCBucyksIG1heGxhdD0weDAwICgwIG5zKQoJaW50 cGluPWEsIGlycT0xMAoJbWFwWzIwXTogdHlwZSBJL08gUG9ydCwgcmFuZ2UgMzIsIGJhc2UgMHgy MGEwLCBzaXplICA1LCBlbmFibGVkCnBjaWIwOiBtYXRjaGVkIGVudHJ5IGZvciAwLjI2LklOVEEK cGNpYjA6IHNsb3QgMjYgSU5UQSBoYXJkd2lyZWQgdG8gSVJRIDE3CmZvdW5kLT4JdmVuZG9yPTB4 ODA4NiwgZGV2PTB4M2EzOCwgcmV2aWQ9MHgwMAoJZG9tYWluPTAsIGJ1cz0wLCBzbG90PTI2LCBm dW5jPTEKCWNsYXNzPTBjLTAzLTAwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTAKCWNtZHJlZz0weDAw MDUsIHN0YXRyZWc9MHgwMjkwLCBjYWNoZWxuc3o9MCAoZHdvcmRzKQoJbGF0dGltZXI9MHgwMCAo MCBucyksIG1pbmdudD0weDAwICgwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCglpbnRwaW49Yiwg aXJxPTUKCW1hcFsyMF06IHR5cGUgSS9PIFBvcnQsIHJhbmdlIDMyLCBiYXNlIDB4MjA4MCwgc2l6 ZSAgNSwgZW5hYmxlZApwY2liMDogbWF0Y2hlZCBlbnRyeSBmb3IgMC4yNi5JTlRCCnBjaWIwOiBz bG90IDI2IElOVEIgaGFyZHdpcmVkIHRvIElSUSAxOApmb3VuZC0+CXZlbmRvcj0weDgwODYsIGRl dj0weDNhM2MsIHJldmlkPTB4MDAKCWRvbWFpbj0wLCBidXM9MCwgc2xvdD0yNiwgZnVuYz03Cglj bGFzcz0wYy0wMy0yMCwgaGRydHlwZT0weDAwLCBtZmRldj0wCgljbWRyZWc9MHgwMTQ2LCBzdGF0 cmVnPTB4MDI5MCwgY2FjaGVsbnN6PTAgKGR3b3JkcykKCWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBt aW5nbnQ9MHgwMCAoMCBucyksIG1heGxhdD0weDAwICgwIG5zKQoJaW50cGluPWMsIGlycT0xMQoJ cG93ZXJzcGVjIDIgIHN1cHBvcnRzIEQwIEQzICBjdXJyZW50IEQwCgltYXBbMTBdOiB0eXBlIE1l bW9yeSwgcmFuZ2UgMzIsIGJhc2UgMHg5N2EyMTQwMCwgc2l6ZSAxMCwgZW5hYmxlZApwY2liMDog bWF0Y2hlZCBlbnRyeSBmb3IgMC4yNi5JTlRDCnBjaWIwOiBzbG90IDI2IElOVEMgaGFyZHdpcmVk IHRvIElSUSAxOQpmb3VuZC0+CXZlbmRvcj0weDgwODYsIGRldj0weDNhNDAsIHJldmlkPTB4MDAK CWRvbWFpbj0wLCBidXM9MCwgc2xvdD0yOCwgZnVuYz0wCgljbGFzcz0wNi0wNC0wMCwgaGRydHlw ZT0weDAxLCBtZmRldj0xCgljbWRyZWc9MHgwMDQ3LCBzdGF0cmVnPTB4MDAxMCwgY2FjaGVsbnN6 PTE2IChkd29yZHMpCglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MDMgKDc1MCBucyks IG1heGxhdD0weDAwICgwIG5zKQoJaW50cGluPWEsIGlycT0xMQoJcG93ZXJzcGVjIDIgIHN1cHBv cnRzIEQwIEQzICBjdXJyZW50IEQwCglNU0kgc3VwcG9ydHMgMSBtZXNzYWdlCnBjaWIwOiBtYXRj aGVkIGVudHJ5IGZvciAwLjI4LklOVEEKcGNpYjA6IHNsb3QgMjggSU5UQSBoYXJkd2lyZWQgdG8g SVJRIDE2CmZvdW5kLT4JdmVuZG9yPTB4ODA4NiwgZGV2PTB4M2E0OCwgcmV2aWQ9MHgwMAoJZG9t YWluPTAsIGJ1cz0wLCBzbG90PTI4LCBmdW5jPTQKCWNsYXNzPTA2LTA0LTAwLCBoZHJ0eXBlPTB4 MDEsIG1mZGV2PTEKCWNtZHJlZz0weDAwNDcsIHN0YXRyZWc9MHgwMDEwLCBjYWNoZWxuc3o9MTYg KGR3b3JkcykKCWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9MHgwYiAoMjc1MCBucyksIG1h eGxhdD0weDAwICgwIG5zKQoJaW50cGluPWEsIGlycT0xMQoJcG93ZXJzcGVjIDIgIHN1cHBvcnRz IEQwIEQzICBjdXJyZW50IEQwCglNU0kgc3VwcG9ydHMgMSBtZXNzYWdlCnBjaWIwOiBtYXRjaGVk IGVudHJ5IGZvciAwLjI4LklOVEEKcGNpYjA6IHNsb3QgMjggSU5UQSBoYXJkd2lyZWQgdG8gSVJR IDE2CmZvdW5kLT4JdmVuZG9yPTB4ODA4NiwgZGV2PTB4M2EzNCwgcmV2aWQ9MHgwMAoJZG9tYWlu PTAsIGJ1cz0wLCBzbG90PTI5LCBmdW5jPTAKCWNsYXNzPTBjLTAzLTAwLCBoZHJ0eXBlPTB4MDAs IG1mZGV2PTEKCWNtZHJlZz0weDAwMDUsIHN0YXRyZWc9MHgwMjkwLCBjYWNoZWxuc3o9MCAoZHdv cmRzKQoJbGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDAwICgwIG5zKSwgbWF4bGF0PTB4 MDAgKDAgbnMpCglpbnRwaW49YSwgaXJxPTEwCgltYXBbMjBdOiB0eXBlIEkvTyBQb3J0LCByYW5n ZSAzMiwgYmFzZSAweDIwNjAsIHNpemUgIDUsIGVuYWJsZWQKcGNpYjA6IG1hdGNoZWQgZW50cnkg Zm9yIDAuMjkuSU5UQQpwY2liMDogc2xvdCAyOSBJTlRBIGhhcmR3aXJlZCB0byBJUlEgMTcKZm91 bmQtPgl2ZW5kb3I9MHg4MDg2LCBkZXY9MHgzYTM1LCByZXZpZD0weDAwCglkb21haW49MCwgYnVz PTAsIHNsb3Q9MjksIGZ1bmM9MQoJY2xhc3M9MGMtMDMtMDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9 MAoJY21kcmVnPTB4MDAwNSwgc3RhdHJlZz0weDAyOTAsIGNhY2hlbG5zej0wIChkd29yZHMpCgls YXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBu cykKCWludHBpbj1iLCBpcnE9NQoJbWFwWzIwXTogdHlwZSBJL08gUG9ydCwgcmFuZ2UgMzIsIGJh c2UgMHgyMDQwLCBzaXplICA1LCBlbmFibGVkCnBjaWIwOiBtYXRjaGVkIGVudHJ5IGZvciAwLjI5 LklOVEIKcGNpYjA6IHNsb3QgMjkgSU5UQiBoYXJkd2lyZWQgdG8gSVJRIDE4CmZvdW5kLT4JdmVu ZG9yPTB4ODA4NiwgZGV2PTB4M2EzNiwgcmV2aWQ9MHgwMAoJZG9tYWluPTAsIGJ1cz0wLCBzbG90 PTI5LCBmdW5jPTIKCWNsYXNzPTBjLTAzLTAwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTAKCWNtZHJl Zz0weDAwMDUsIHN0YXRyZWc9MHgwMjkwLCBjYWNoZWxuc3o9MCAoZHdvcmRzKQoJbGF0dGltZXI9 MHgwMCAoMCBucyksIG1pbmdudD0weDAwICgwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCglpbnRw aW49YywgaXJxPTExCgltYXBbMjBdOiB0eXBlIEkvTyBQb3J0LCByYW5nZSAzMiwgYmFzZSAweDIw MjAsIHNpemUgIDUsIGVuYWJsZWQKcGNpYjA6IG1hdGNoZWQgZW50cnkgZm9yIDAuMjkuSU5UQwpw Y2liMDogc2xvdCAyOSBJTlRDIGhhcmR3aXJlZCB0byBJUlEgMTkKZm91bmQtPgl2ZW5kb3I9MHg4 MDg2LCBkZXY9MHgzYTNhLCByZXZpZD0weDAwCglkb21haW49MCwgYnVzPTAsIHNsb3Q9MjksIGZ1 bmM9NwoJY2xhc3M9MGMtMDMtMjAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MAoJY21kcmVnPTB4MDE0 Niwgc3RhdHJlZz0weDAyOTAsIGNhY2hlbG5zej0wIChkd29yZHMpCglsYXR0aW1lcj0weDAwICgw IG5zKSwgbWluZ250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKCWludHBpbj1hLCBp cnE9MTAKCXBvd2Vyc3BlYyAyICBzdXBwb3J0cyBEMCBEMyAgY3VycmVudCBEMAoJbWFwWzEwXTog dHlwZSBNZW1vcnksIHJhbmdlIDMyLCBiYXNlIDB4OTdhMjEwMDAsIHNpemUgMTAsIGVuYWJsZWQK cGNpYjA6IG1hdGNoZWQgZW50cnkgZm9yIDAuMjkuSU5UQQpwY2liMDogc2xvdCAyOSBJTlRBIGhh cmR3aXJlZCB0byBJUlEgMTcKZm91bmQtPgl2ZW5kb3I9MHg4MDg2LCBkZXY9MHgyNDRlLCByZXZp ZD0weDkwCglkb21haW49MCwgYnVzPTAsIHNsb3Q9MzAsIGZ1bmM9MAoJY2xhc3M9MDYtMDQtMDEs IGhkcnR5cGU9MHgwMSwgbWZkZXY9MAoJY21kcmVnPTB4MDE0MCwgc3RhdHJlZz0weDAwMTAsIGNh Y2hlbG5zej0wIChkd29yZHMpCglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MDMgKDc1 MCBucyksIG1heGxhdD0weDAwICgwIG5zKQpmb3VuZC0+CXZlbmRvcj0weDgwODYsIGRldj0weDNh MTgsIHJldmlkPTB4MDAKCWRvbWFpbj0wLCBidXM9MCwgc2xvdD0zMSwgZnVuYz0wCgljbGFzcz0w Ni0wMS0wMCwgaGRydHlwZT0weDAwLCBtZmRldj0xCgljbWRyZWc9MHgwMTQ3LCBzdGF0cmVnPTB4 MDIxMCwgY2FjaGVsbnN6PTAgKGR3b3JkcykKCWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9 MHgwMCAoMCBucyksIG1heGxhdD0weDAwICgwIG5zKQpmb3VuZC0+CXZlbmRvcj0weDgwODYsIGRl dj0weDNhMjAsIHJldmlkPTB4MDAKCWRvbWFpbj0wLCBidXM9MCwgc2xvdD0zMSwgZnVuYz0yCglj bGFzcz0wMS0wMS04YSwgaGRydHlwZT0weDAwLCBtZmRldj0wCgljbWRyZWc9MHgwMDQ3LCBzdGF0 cmVnPTB4MDJiMCwgY2FjaGVsbnN6PTAgKGR3b3JkcykKCWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBt aW5nbnQ9MHgwMCAoMCBucyksIG1heGxhdD0weDAwICgwIG5zKQoJaW50cGluPWEsIGlycT0xMQoJ cG93ZXJzcGVjIDMgIHN1cHBvcnRzIEQwIEQzICBjdXJyZW50IEQwCgltYXBbMjBdOiB0eXBlIEkv TyBQb3J0LCByYW5nZSAzMiwgYmFzZSAweDIwZjAsIHNpemUgIDQsIGVuYWJsZWQKCW1hcFsyNF06 IHR5cGUgSS9PIFBvcnQsIHJhbmdlIDMyLCBiYXNlIDB4MjBlMCwgc2l6ZSAgNCwgZW5hYmxlZApw Y2liMDogbWF0Y2hlZCBlbnRyeSBmb3IgMC4zMS5JTlRBCnBjaWIwOiBzbG90IDMxIElOVEEgaGFy ZHdpcmVkIHRvIElSUSAxNgpmb3VuZC0+CXZlbmRvcj0weDgwODYsIGRldj0weDNhMzAsIHJldmlk PTB4MDAKCWRvbWFpbj0wLCBidXM9MCwgc2xvdD0zMSwgZnVuYz0zCgljbGFzcz0wYy0wNS0wMCwg aGRydHlwZT0weDAwLCBtZmRldj0wCgljbWRyZWc9MHgwMTQzLCBzdGF0cmVnPTB4MDI4MCwgY2Fj aGVsbnN6PTAgKGR3b3JkcykKCWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9MHgwMCAoMCBu cyksIG1heGxhdD0weDAwICgwIG5zKQoJaW50cGluPWIsIGlycT0xMQoJbWFwWzEwXTogdHlwZSBN ZW1vcnksIHJhbmdlIDY0LCBiYXNlIDB4OTdhMjE4MDAsIHNpemUgIDgsIGVuYWJsZWQKCW1hcFsy MF06IHR5cGUgSS9PIFBvcnQsIHJhbmdlIDMyLCBiYXNlIDB4MjAwMCwgc2l6ZSAgNSwgZW5hYmxl ZApwY2liMDogbWF0Y2hlZCBlbnRyeSBmb3IgMC4zMS5JTlRCCnBjaWIwOiBzbG90IDMxIElOVEIg aGFyZHdpcmVkIHRvIElSUSAyMgpmb3VuZC0+CXZlbmRvcj0weDgwODYsIGRldj0weDNhMjYsIHJl dmlkPTB4MDAKCWRvbWFpbj0wLCBidXM9MCwgc2xvdD0zMSwgZnVuYz01CgljbGFzcz0wMS0wMS04 NSwgaGRydHlwZT0weDAwLCBtZmRldj0wCgljbWRyZWc9MHgwMDQ3LCBzdGF0cmVnPTB4MDJiMCwg Y2FjaGVsbnN6PTAgKGR3b3JkcykKCWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9MHgwMCAo MCBucyksIG1heGxhdD0weDAwICgwIG5zKQoJaW50cGluPWMsIGlycT0xMQoJcG93ZXJzcGVjIDMg IHN1cHBvcnRzIEQwIEQzICBjdXJyZW50IEQwCgltYXBbMTBdOiB0eXBlIEkvTyBQb3J0LCByYW5n ZSAzMiwgYmFzZSAweDIxMDgsIHNpemUgIDMsIGVuYWJsZWQKCW1hcFsxNF06IHR5cGUgSS9PIFBv cnQsIHJhbmdlIDMyLCBiYXNlIDB4MjEyNCwgc2l6ZSAgMiwgZW5hYmxlZAoJbWFwWzE4XTogdHlw ZSBJL08gUG9ydCwgcmFuZ2UgMzIsIGJhc2UgMHgyMTAwLCBzaXplICAzLCBlbmFibGVkCgltYXBb MWNdOiB0eXBlIEkvTyBQb3J0LCByYW5nZSAzMiwgYmFzZSAweDIxMjAsIHNpemUgIDIsIGVuYWJs ZWQKCW1hcFsyMF06IHR5cGUgSS9PIFBvcnQsIHJhbmdlIDMyLCBiYXNlIDB4MjBkMCwgc2l6ZSAg NCwgZW5hYmxlZAoJbWFwWzI0XTogdHlwZSBJL08gUG9ydCwgcmFuZ2UgMzIsIGJhc2UgMHgyMGMw LCBzaXplICA0LCBlbmFibGVkCnBjaWIwOiBtYXRjaGVkIGVudHJ5IGZvciAwLjMxLklOVEMKcGNp YjA6IHNsb3QgMzEgSU5UQyBoYXJkd2lyZWQgdG8gSVJRIDIxCnBjaWIxOiA8QUNQSSBQQ0ktUENJ IGJyaWRnZT4gaXJxIDI4IGF0IGRldmljZSAxLjAgb24gcGNpMApwY2liMTogICBkb21haW4gICAg ICAgICAgICAwCnBjaWIxOiAgIHNlY29uZGFyeSBidXMgICAgIDExCnBjaWIxOiAgIHN1Ym9yZGlu YXRlIGJ1cyAgIDE1CnBjaWIxOiAgIEkvTyBkZWNvZGUgICAgICAgIDB4ZjAwMC0weGZmZgpwY2li MTogICBtZW1vcnkgZGVjb2RlICAgICAweDkyMDAwMDAwLTB4OTVmZmZmZmYKcGNpYjE6ICAgbm8g cHJlZmV0Y2hlZCBkZWNvZGUKcGNpMTE6IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWIxCnBjaTExOiBk b21haW49MCwgcGh5c2ljYWwgYnVzPTExCmZvdW5kLT4JdmVuZG9yPTB4MTRlNCwgZGV2PTB4MTYz OSwgcmV2aWQ9MHgyMAoJZG9tYWluPTAsIGJ1cz0xMSwgc2xvdD0wLCBmdW5jPTAKCWNsYXNzPTAy LTAwLTAwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTEKCWNtZHJlZz0weDAwNDYsIHN0YXRyZWc9MHgw MDEwLCBjYWNoZWxuc3o9MTYgKGR3b3JkcykKCWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9 MHgwMCAoMCBucyksIG1heGxhdD0weDAwICgwIG5zKQoJaW50cGluPWEsIGlycT0xMQoJcG93ZXJz cGVjIDMgIHN1cHBvcnRzIEQwIEQzICBjdXJyZW50IEQwCglNU0kgc3VwcG9ydHMgMTYgbWVzc2Fn ZXMsIDY0IGJpdAoJTVNJLVggc3VwcG9ydHMgOSBtZXNzYWdlcyBpbiBtYXAgMHgxMAoJbWFwWzEw XTogdHlwZSBNZW1vcnksIHJhbmdlIDY0LCBiYXNlIDB4OTIwMDAwMDAsIHNpemUgMjUsIGVuYWJs ZWQKcGNpYjE6IHJlcXVlc3RlZCBtZW1vcnkgcmFuZ2UgMHg5MjAwMDAwMC0weDkzZmZmZmZmOiBn b29kCnBjaWIxOiBtYXRjaGVkIGVudHJ5IGZvciAxMS4wLklOVEEKcGNpYjE6IHNsb3QgMCBJTlRB IGhhcmR3aXJlZCB0byBJUlEgMjgKZm91bmQtPgl2ZW5kb3I9MHgxNGU0LCBkZXY9MHgxNjM5LCBy ZXZpZD0weDIwCglkb21haW49MCwgYnVzPTExLCBzbG90PTAsIGZ1bmM9MQoJY2xhc3M9MDItMDAt MDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MQoJY21kcmVnPTB4MDA0Niwgc3RhdHJlZz0weDAwMTAs IGNhY2hlbG5zej0xNiAoZHdvcmRzKQoJbGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDAw ICgwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCglpbnRwaW49YiwgaXJxPTEwCglwb3dlcnNwZWMg MyAgc3VwcG9ydHMgRDAgRDMgIGN1cnJlbnQgRDAKCU1TSSBzdXBwb3J0cyAxNiBtZXNzYWdlcywg NjQgYml0CglNU0ktWCBzdXBwb3J0cyA5IG1lc3NhZ2VzIGluIG1hcCAweDEwCgltYXBbMTBdOiB0 eXBlIE1lbW9yeSwgcmFuZ2UgNjQsIGJhc2UgMHg5NDAwMDAwMCwgc2l6ZSAyNSwgZW5hYmxlZApw Y2liMTogcmVxdWVzdGVkIG1lbW9yeSByYW5nZSAweDk0MDAwMDAwLTB4OTVmZmZmZmY6IGdvb2QK cGNpYjE6IG1hdGNoZWQgZW50cnkgZm9yIDExLjAuSU5UQgpwY2liMTogc2xvdCAwIElOVEIgaGFy ZHdpcmVkIHRvIElSUSA0MApiY2UwOiA8QnJvYWRjb20gTmV0WHRyZW1lIElJIEJDTTU3MDkgMTAw MEJhc2UtVCAoQzApPiBtZW0gMHg5MjAwMDAwMC0weDkzZmZmZmZmIGlycSAyOCBhdCBkZXZpY2Ug MC4wIG9uIHBjaTExCmJjZTA6IFJlc2VydmVkIDB4MjAwMDAwMCBieXRlcyBmb3IgcmlkIDB4MTAg dHlwZSAzIGF0IDB4OTIwMDAwMDAKYmNlMDogYXR0ZW1wdGluZyB0byBhbGxvY2F0ZSAxIE1TSSB2 ZWN0b3JzICgxNiBzdXBwb3J0ZWQpCm1zaTogcm91dGluZyBNU0kgSVJRIDI1NiB0byB2ZWN0b3Ig NjQKYmNlMDogdXNpbmcgSVJRIDI1NiBmb3IgTVNJCm1paWJ1czA6IDxNSUkgYnVzPiBvbiBiY2Uw CnVrcGh5MDogPEdlbmVyaWMgSUVFRSA4MDIuM3UgbWVkaWEgaW50ZXJmYWNlPiBQSFkgMSBvbiBt aWlidXMwCnVrcGh5MDogT1VJIDB4MDA1MGVmLCBtb2RlbCAweDAwM2MsIHJldi4gOAp1a3BoeTA6 ICAxMGJhc2VULCAxMGJhc2VULUZEWCwgMTAwYmFzZVRYLCAxMDBiYXNlVFgtRkRYLCAxMDAwYmFz ZVQsIDEwMDBiYXNlVC1GRFgsIGF1dG8KYmNlMDogYnBmIGF0dGFjaGVkCmJjZTA6IEV0aGVybmV0 IGFkZHJlc3M6IDAwOjFhOjY0OmU1OjEzOmVjCmJjZTA6IFtNUFNBRkVdCmJjZTA6IFtJVEhSRUFE XQpiY2UwOiBBU0lDICgweDU3MDkyMDAzKTsgUmV2IChDMCk7IEJ1cyAoUENJZSB4MiwgNUdicHMp OyBCL0MgKDB4MDQwNjA3MDUpOyBGbGFncyggTUZXIE1TSSApCmJjZTE6IDxCcm9hZGNvbSBOZXRY dHJlbWUgSUkgQkNNNTcwOSAxMDAwQmFzZS1UIChDMCk+IG1lbSAweDk0MDAwMDAwLTB4OTVmZmZm ZmYgaXJxIDQwIGF0IGRldmljZSAwLjEgb24gcGNpMTEKYmNlMTogUmVzZXJ2ZWQgMHgyMDAwMDAw IGJ5dGVzIGZvciByaWQgMHgxMCB0eXBlIDMgYXQgMHg5NDAwMDAwMApiY2UxOiBhdHRlbXB0aW5n IHRvIGFsbG9jYXRlIDEgTVNJIHZlY3RvcnMgKDE2IHN1cHBvcnRlZCkKbXNpOiByb3V0aW5nIE1T SSBJUlEgMjU3IHRvIHZlY3RvciA4MApiY2UxOiB1c2luZyBJUlEgMjU3IGZvciBNU0kKbWlpYnVz MTogPE1JSSBidXM+IG9uIGJjZTEKdWtwaHkxOiA8R2VuZXJpYyBJRUVFIDgwMi4zdSBtZWRpYSBp bnRlcmZhY2U+IFBIWSAxIG9uIG1paWJ1czEKdWtwaHkxOiBPVUkgMHgwMDUwZWYsIG1vZGVsIDB4 MDAzYywgcmV2LiA4CnVrcGh5MTogIDEwYmFzZVQsIDEwYmFzZVQtRkRYLCAxMDBiYXNlVFgsIDEw MGJhc2VUWC1GRFgsIDEwMDBiYXNlVCwgMTAwMGJhc2VULUZEWCwgYXV0bwpiY2UxOiBicGYgYXR0 YWNoZWQKYmNlMTogRXRoZXJuZXQgYWRkcmVzczogMDA6MWE6NjQ6ZTU6MTM6ZWUKYmNlMTogW01Q U0FGRV0KYmNlMTogW0lUSFJFQURdCmJjZTE6IEFTSUMgKDB4NTcwOTIwMDMpOyBSZXYgKEMwKTsg QnVzIChQQ0llIHgyLCA1R2Jwcyk7IEIvQyAoMHgwNDA2MDcwNSk7IEZsYWdzKCBNRlcgTVNJICkK cGNpYjI6IDxQQ0ktUENJIGJyaWRnZT4gaXJxIDI5IGF0IGRldmljZSAyLjAgb24gcGNpMApwY2li MjogICBkb21haW4gICAgICAgICAgICAwCnBjaWIyOiAgIHNlY29uZGFyeSBidXMgICAgIDE2CnBj aWIyOiAgIHN1Ym9yZGluYXRlIGJ1cyAgIDIwCnBjaWIyOiAgIEkvTyBkZWNvZGUgICAgICAgIDB4 MC0weDAKcGNpYjI6ICAgbm8gcHJlZmV0Y2hlZCBkZWNvZGUKcGNpMTY6IDxQQ0kgYnVzPiBvbiBw Y2liMgpwY2kxNjogZG9tYWluPTAsIHBoeXNpY2FsIGJ1cz0xNgpwY2liMzogPEFDUEkgUENJLVBD SSBicmlkZ2U+IGlycSAyNCBhdCBkZXZpY2UgMy4wIG9uIHBjaTAKcGNpYjM6ICAgZG9tYWluICAg ICAgICAgICAgMApwY2liMzogICBzZWNvbmRhcnkgYnVzICAgICAyMQpwY2liMzogICBzdWJvcmRp bmF0ZSBidXMgICAyNQpwY2liMzogICBJL08gZGVjb2RlICAgICAgICAweDAtMHgwCnBjaWIzOiAg IG5vIHByZWZldGNoZWQgZGVjb2RlCnBjaTIxOiA8QUNQSSBQQ0kgYnVzPiBvbiBwY2liMwpwY2ky MTogZG9tYWluPTAsIHBoeXNpY2FsIGJ1cz0yMQpwY2liNDogPFBDSS1QQ0kgYnJpZGdlPiBpcnEg MjYgYXQgZGV2aWNlIDUuMCBvbiBwY2kwCnBjaWI0OiAgIGRvbWFpbiAgICAgICAgICAgIDAKcGNp YjQ6ICAgc2Vjb25kYXJ5IGJ1cyAgICAgMjYKcGNpYjQ6ICAgc3Vib3JkaW5hdGUgYnVzICAgMzAK cGNpYjQ6ICAgSS9PIGRlY29kZSAgICAgICAgMHgwLTB4MApwY2liNDogICBubyBwcmVmZXRjaGVk IGRlY29kZQpwY2kyNjogPFBDSSBidXM+IG9uIHBjaWI0CnBjaTI2OiBkb21haW49MCwgcGh5c2lj YWwgYnVzPTI2CnBjaWI1OiA8QUNQSSBQQ0ktUENJIGJyaWRnZT4gaXJxIDMwIGF0IGRldmljZSA3 LjAgb24gcGNpMApwY2liNTogICBkb21haW4gICAgICAgICAgICAwCnBjaWI1OiAgIHNlY29uZGFy eSBidXMgICAgIDMxCnBjaWI1OiAgIHN1Ym9yZGluYXRlIGJ1cyAgIDM1CnBjaWI1OiAgIEkvTyBk ZWNvZGUgICAgICAgIDB4MC0weDAKcGNpYjU6ICAgbm8gcHJlZmV0Y2hlZCBkZWNvZGUKcGNpMzE6 IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWI1CnBjaTMxOiBkb21haW49MCwgcGh5c2ljYWwgYnVzPTMx CnBjaWI2OiA8QUNQSSBQQ0ktUENJIGJyaWRnZT4gaXJxIDMyIGF0IGRldmljZSA5LjAgb24gcGNp MApwY2liNjogICBkb21haW4gICAgICAgICAgICAwCnBjaWI2OiAgIHNlY29uZGFyeSBidXMgICAg IDM2CnBjaWI2OiAgIHN1Ym9yZGluYXRlIGJ1cyAgIDQwCnBjaWI2OiAgIEkvTyBkZWNvZGUgICAg ICAgIDB4MC0weDAKcGNpYjY6ICAgbm8gcHJlZmV0Y2hlZCBkZWNvZGUKcGNpMzY6IDxBQ1BJIFBD SSBidXM+IG9uIHBjaWI2CnBjaTM2OiBkb21haW49MCwgcGh5c2ljYWwgYnVzPTM2CnBjaTA6IDxi YXNlIHBlcmlwaGVyYWwsIGludGVycnVwdCBjb250cm9sbGVyPiBhdCBkZXZpY2UgMTYuMCAobm8g ZHJpdmVyIGF0dGFjaGVkKQpwY2kwOiA8YmFzZSBwZXJpcGhlcmFsLCBpbnRlcnJ1cHQgY29udHJv bGxlcj4gYXQgZGV2aWNlIDE2LjEgKG5vIGRyaXZlciBhdHRhY2hlZCkKcGNpMDogPGJhc2UgcGVy aXBoZXJhbCwgaW50ZXJydXB0IGNvbnRyb2xsZXI+IGF0IGRldmljZSAxNy4wIChubyBkcml2ZXIg YXR0YWNoZWQpCnBjaTA6IDxiYXNlIHBlcmlwaGVyYWwsIGludGVycnVwdCBjb250cm9sbGVyPiBh dCBkZXZpY2UgMTcuMSAobm8gZHJpdmVyIGF0dGFjaGVkKQpwY2kwOiA8YmFzZSBwZXJpcGhlcmFs LCBpbnRlcnJ1cHQgY29udHJvbGxlcj4gYXQgZGV2aWNlIDIwLjAgKG5vIGRyaXZlciBhdHRhY2hl ZCkKcGNpMDogPGJhc2UgcGVyaXBoZXJhbCwgaW50ZXJydXB0IGNvbnRyb2xsZXI+IGF0IGRldmlj ZSAyMC4xIChubyBkcml2ZXIgYXR0YWNoZWQpCnBjaTA6IDxiYXNlIHBlcmlwaGVyYWwsIGludGVy cnVwdCBjb250cm9sbGVyPiBhdCBkZXZpY2UgMjAuMiAobm8gZHJpdmVyIGF0dGFjaGVkKQpwY2kw OiA8YmFzZSBwZXJpcGhlcmFsLCBpbnRlcnJ1cHQgY29udHJvbGxlcj4gYXQgZGV2aWNlIDIwLjMg KG5vIGRyaXZlciBhdHRhY2hlZCkKcGNpMDogPGJhc2UgcGVyaXBoZXJhbD4gYXQgZGV2aWNlIDIy LjAgKG5vIGRyaXZlciBhdHRhY2hlZCkKcGNpMDogPGJhc2UgcGVyaXBoZXJhbD4gYXQgZGV2aWNl IDIyLjEgKG5vIGRyaXZlciBhdHRhY2hlZCkKcGNpMDogPGJhc2UgcGVyaXBoZXJhbD4gYXQgZGV2 aWNlIDIyLjIgKG5vIGRyaXZlciBhdHRhY2hlZCkKcGNpMDogPGJhc2UgcGVyaXBoZXJhbD4gYXQg ZGV2aWNlIDIyLjMgKG5vIGRyaXZlciBhdHRhY2hlZCkKcGNpMDogPGJhc2UgcGVyaXBoZXJhbD4g YXQgZGV2aWNlIDIyLjQgKG5vIGRyaXZlciBhdHRhY2hlZCkKcGNpMDogPGJhc2UgcGVyaXBoZXJh bD4gYXQgZGV2aWNlIDIyLjUgKG5vIGRyaXZlciBhdHRhY2hlZCkKcGNpMDogPGJhc2UgcGVyaXBo ZXJhbD4gYXQgZGV2aWNlIDIyLjYgKG5vIGRyaXZlciBhdHRhY2hlZCkKcGNpMDogPGJhc2UgcGVy aXBoZXJhbD4gYXQgZGV2aWNlIDIyLjcgKG5vIGRyaXZlciBhdHRhY2hlZCkKdWhjaTA6IDxVSENJ IChnZW5lcmljKSBVU0IgY29udHJvbGxlcj4gcG9ydCAweDIwYTAtMHgyMGJmIGlycSAxNyBhdCBk ZXZpY2UgMjYuMCBvbiBwY2kwCnVoY2kwOiBSZXNlcnZlZCAweDIwIGJ5dGVzIGZvciByaWQgMHgy MCB0eXBlIDQgYXQgMHgyMGEwCmlvYXBpYzA6IHJvdXRpbmcgaW50cGluIDE3IChQQ0kgSVJRIDE3 KSB0byB2ZWN0b3IgNDkKdWhjaTA6IFtHSUFOVC1MT0NLRURdCnVoY2kwOiBbSVRIUkVBRF0KdXNi MDogPFVIQ0kgKGdlbmVyaWMpIFVTQiBjb250cm9sbGVyPiBvbiB1aGNpMAp1c2IwOiBVU0IgcmV2 aXNpb24gMS4wCnVodWIwOiA8SW50ZWwgVUhDSSByb290IGh1YiwgY2xhc3MgOS8wLCByZXYgMS4w MC8xLjAwLCBhZGRyIDE+IG9uIHVzYjAKdWh1YjA6IDIgcG9ydHMgd2l0aCAyIHJlbW92YWJsZSwg c2VsZiBwb3dlcmVkCnVoY2kxOiA8VUhDSSAoZ2VuZXJpYykgVVNCIGNvbnRyb2xsZXI+IHBvcnQg MHgyMDgwLTB4MjA5ZiBpcnEgMTggYXQgZGV2aWNlIDI2LjEgb24gcGNpMAp1aGNpMTogUmVzZXJ2 ZWQgMHgyMCBieXRlcyBmb3IgcmlkIDB4MjAgdHlwZSA0IGF0IDB4MjA4MAppb2FwaWMwOiByb3V0 aW5nIGludHBpbiAxOCAoUENJIElSUSAxOCkgdG8gdmVjdG9yIDUwCnVoY2kxOiBbR0lBTlQtTE9D S0VEXQp1aGNpMTogW0lUSFJFQURdCnVzYjE6IDxVSENJIChnZW5lcmljKSBVU0IgY29udHJvbGxl cj4gb24gdWhjaTEKdXNiMTogVVNCIHJldmlzaW9uIDEuMAp1aHViMTogPEludGVsIFVIQ0kgcm9v dCBodWIsIGNsYXNzIDkvMCwgcmV2IDEuMDAvMS4wMCwgYWRkciAxPiBvbiB1c2IxCnVodWIxOiAy IHBvcnRzIHdpdGggMiByZW1vdmFibGUsIHNlbGYgcG93ZXJlZAplaGNpMDogPEVIQ0kgKGdlbmVy aWMpIFVTQiAyLjAgY29udHJvbGxlcj4gbWVtIDB4OTdhMjE0MDAtMHg5N2EyMTdmZiBpcnEgMTkg YXQgZGV2aWNlIDI2Ljcgb24gcGNpMAplaGNpMDogUmVzZXJ2ZWQgMHg0MDAgYnl0ZXMgZm9yIHJp ZCAweDEwIHR5cGUgMyBhdCAweDk3YTIxNDAwCmlvYXBpYzA6IHJvdXRpbmcgaW50cGluIDE5IChQ Q0kgSVJRIDE5KSB0byB2ZWN0b3IgNTEKZWhjaTA6IFtHSUFOVC1MT0NLRURdCmVoY2kwOiBbSVRI UkVBRF0KdXNiMjogRUhDSSB2ZXJzaW9uIDEuMAp1c2IyOiB3cm9uZyBudW1iZXIgb2YgY29tcGFu aW9ucyAoMyAhPSAyKQp1c2IyOiBjb21wYW5pb24gY29udHJvbGxlcnMsIDIgcG9ydHMgZWFjaDog dXNiMCB1c2IxCnVzYjI6IDxFSENJIChnZW5lcmljKSBVU0IgMi4wIGNvbnRyb2xsZXI+IG9uIGVo Y2kwCnVzYjI6IFVTQiByZXZpc2lvbiAyLjAKdWh1YjI6IDxJbnRlbCBFSENJIHJvb3QgaHViLCBj bGFzcyA5LzAsIHJldiAyLjAwLzEuMDAsIGFkZHIgMT4gb24gdXNiMgp1aHViMjogNiBwb3J0cyB3 aXRoIDYgcmVtb3ZhYmxlLCBzZWxmIHBvd2VyZWQKcGNpYjc6IDxQQ0ktUENJIGJyaWRnZT4gaXJx IDE2IGF0IGRldmljZSAyOC4wIG9uIHBjaTAKcGNpYjc6ICAgZG9tYWluICAgICAgICAgICAgMApw Y2liNzogICBzZWNvbmRhcnkgYnVzICAgICAxCnBjaWI3OiAgIHN1Ym9yZGluYXRlIGJ1cyAgIDUK cGNpYjc6ICAgSS9PIGRlY29kZSAgICAgICAgMHgxMDAwLTB4MWZmZgpwY2liNzogICBtZW1vcnkg ZGVjb2RlICAgICAweDk3OTAwMDAwLTB4OTc5ZmZmZmYKcGNpYjc6ICAgbm8gcHJlZmV0Y2hlZCBk ZWNvZGUKcGNpMTogPFBDSSBidXM+IG9uIHBjaWI3CnBjaTE6IGRvbWFpbj0wLCBwaHlzaWNhbCBi dXM9MQpmb3VuZC0+CXZlbmRvcj0weDEwMDAsIGRldj0weDAwNjAsIHJldmlkPTB4MDQKCWRvbWFp bj0wLCBidXM9MSwgc2xvdD0wLCBmdW5jPTAKCWNsYXNzPTAxLTA0LTAwLCBoZHJ0eXBlPTB4MDAs IG1mZGV2PTAKCWNtZHJlZz0weDAwNDcsIHN0YXRyZWc9MHgwMDEwLCBjYWNoZWxuc3o9MTYgKGR3 b3JkcykKCWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9MHgwMCAoMCBucyksIG1heGxhdD0w eDAwICgwIG5zKQoJaW50cGluPWEsIGlycT0xMQoJcG93ZXJzcGVjIDIgIHN1cHBvcnRzIEQwIEQx IEQzICBjdXJyZW50IEQwCglNU0kgc3VwcG9ydHMgNCBtZXNzYWdlcywgNjQgYml0CglNU0ktWCBz dXBwb3J0cyA0IG1lc3NhZ2VzIGluIG1hcCAweDEwCgltYXBbMTBdOiB0eXBlIE1lbW9yeSwgcmFu Z2UgNjQsIGJhc2UgMHg5NzkwMDAwMCwgc2l6ZSAxOCwgZW5hYmxlZApwY2liNzogcmVxdWVzdGVk IG1lbW9yeSByYW5nZSAweDk3OTAwMDAwLTB4OTc5M2ZmZmY6IGdvb2QKCW1hcFsxOF06IHR5cGUg SS9PIFBvcnQsIHJhbmdlIDMyLCBiYXNlIDB4MTAwMCwgc2l6ZSAgOCwgZW5hYmxlZApwY2liNzog cmVxdWVzdGVkIEkvTyByYW5nZSAweDEwMDAtMHgxMGZmOiBpbiByYW5nZQoJbWFwWzFjXTogdHlw ZSBNZW1vcnksIHJhbmdlIDY0LCBiYXNlIDB4OTc5NDAwMDAsIHNpemUgMTgsIGVuYWJsZWQKcGNp Yjc6IHJlcXVlc3RlZCBtZW1vcnkgcmFuZ2UgMHg5Nzk0MDAwMC0weDk3OTdmZmZmOiBnb29kCnBj aWIwOiBtYXRjaGVkIGVudHJ5IGZvciAwLjI4LklOVEEKcGNpYjA6IHNsb3QgMjggSU5UQSBoYXJk d2lyZWQgdG8gSVJRIDE2CnBjaWI3OiBzbG90IDAgSU5UQSBpcyByb3V0ZWQgdG8gaXJxIDE2Cm1m aTA6IDxMU0kgTWVnYVNBUyAxMDc4PiBwb3J0IDB4MTAwMC0weDEwZmYgbWVtIDB4OTc5MDAwMDAt MHg5NzkzZmZmZiwweDk3OTQwMDAwLTB4OTc5N2ZmZmYgaXJxIDE2IGF0IGRldmljZSAwLjAgb24g cGNpMQptZmkwOiBSZXNlcnZlZCAweDQwMDAwIGJ5dGVzIGZvciByaWQgMHgxMCB0eXBlIDMgYXQg MHg5NzkwMDAwMAptZmkwOiBNZWdhcmFpZCBTQVMgZHJpdmVyIFZlciAzLjAwIAptZmkwOiBNYXgg ZncgY21kcz0gMTAwOCwgc2l6aW5nIGRyaXZlciBwb29sIHRvIDEyOAptZmkwOiA3NDUyICgzMDEw NTcyNDBzLzB4MDAyMC9pbmZvKSAtIFNodXRkb3duIGNvbW1hbmQgcmVjZWl2ZWQgZnJvbSBob3N0 Cm1maTA6IDc0NTMgKGJvb3QgKyAzcy8weDAwMjAvaW5mbykgLSBGaXJtd2FyZSBpbml0aWFsaXph dGlvbiBzdGFydGVkIChQQ0kgSUQgMDA2MC8xMDAwLzAzNjQvMTAxNCkKbWZpMDogNzQ1NCAoYm9v dCArIDNzLzB4MDAyMC9pbmZvKSAtIEZpcm13YXJlIHZlcnNpb24gMS40MC4zMi0wNjAyCm1maTA6 IDc0NTUgKGJvb3QgKyAzcy8weDAwMjAvaW5mbykgLSBGaXJtd2FyZSBpbml0aWFsaXphdGlvbiBz dGFydGVkIChQQ0kgSUQgMDA2MC8xMDAwLzAzNjQvMTAxNCkKbWZpMDogNzQ1NiAoYm9vdCArIDNz LzB4MDAyMC9pbmZvKSAtIEZpcm13YXJlIHZlcnNpb24gMS40MC4zMi0wNjAyCm1maTA6IDc0NTcg KGJvb3QgKyA2M3MvMHgwMDA4L1dBUk4pIC0gQmF0dGVyeSBOb3QgUHJlc2VudAptZmkwOiA3NDU4 IChib290ICsgNjNzLzB4MDAyMC9pbmZvKSAtIEJvYXJkIFJldmlzaW9uIAptZmkwOiA3NDU5IChi b290ICsgODFzLzB4MDAwMi9pbmZvKSAtIEluc2VydGVkOiBQRCAwOChlMHhmZi9zOCkKbWZpMDog NzQ2MCAoYm9vdCArIDgxcy8weDAwMDIvaW5mbykgLSBJbnNlcnRlZDogUEQgMDgoZTB4ZmYvczgp IEluZm86IGVuY2xQZD1mZmZmLCBzY3NpVHlwZT0wLCBwb3J0TWFwPTAwLCBzYXNBZGRyPTUwMDBj NTAwMTJlOWQ4NDksMDAwMDAwMDAwMDAwMDAwMAptZmkwOiA3NDYxIChib290ICsgODFzLzB4MDAw Mi9pbmZvKSAtIFBEIDA4KGUweGZmL3M4KSBGUlUgaXMgNDJEMDYyMyAgICAgCm1maTA6IDc0NjIg KGJvb3QgKyA4MXMvMHgwMDAyL2luZm8pIC0gSW5zZXJ0ZWQ6IFBEIDA5KGUweGZmL3M5KQptZmkw OiA3NDYzIChib290ICsgODFzLzB4MDAwMi9pbmZvKSAtIEluc2VydGVkOiBQRCAwOShlMHhmZi9z OSkgSW5mbzogZW5jbFBkPWZmZmYsIHNjc2lUeXBlPTAsIHBvcnRNYXA9MDEsIHNhc0FkZHI9NTAw MGM1MDAxMmU5ZGJiZCwwMDAwMDAwMDAwMDAwMDAwCm1maTA6IDc0NjQgKGJvb3QgKyA4MXMvMHgw MDAyL2luZm8pIC0gUEQgMDkoZTB4ZmYvczkpIEZSVSBpcyA0MkQwNjIzICAgICAKbWZpMDogNzQ2 NSAoYm9vdCArIDgxcy8weDAwMDIvaW5mbykgLSBJbnNlcnRlZDogUEQgMGEoZTB4ZmYvczEwKQpt ZmkwOiA3NDY2IChib290ICsgODFzLzB4MDAwMi9pbmZvKSAtIEluc2VydGVkOiBQRCAwYShlMHhm Zi9zMTApIEluZm86IGVuY2xQZD1mZmZmLCBzY3NpVHlwZT0wLCBwb3J0TWFwPTA0LCBzYXNBZGRy PTUwMDBjNTAwMTJmZWEyOTEsMDAwMDAwMDAwMDAwMDAwMAptZmkwOiA3NDY3IChib290ICsgODFz LzB4MDAwMi9pbmZvKSAtIFBEIDBhKGUweGZmL3MxMCkgRlJVIGlzIDQyRDA2MjMgICAgIAptZmkw OiA3NDY4IChib290ICsgODFzLzB4MDAwMi9pbmZvKSAtIEluc2VydGVkOiBQRCAwYihlMHhmZi9z MTEpCm1maTA6IDc0NjkgKGJvb3QgKyA4MXMvMHgwMDAyL2luZm8pIC0gSW5zZXJ0ZWQ6IFBEIDBi KGUweGZmL3MxMSkgSW5mbzogZW5jbFBkPWZmZmYsIHNjc2lUeXBlPTAsIHBvcnRNYXA9MDUsIHNh c0FkZHI9NTAwMGM1MDAxMmZlMTc2ZCwwMDAwMDAwMDAwMDAwMDAwCm1maTA6IDc0NzAgKGJvb3Qg KyA4MXMvMHgwMDAyL2luZm8pIC0gUEQgMGIoZTB4ZmYvczExKSBGUlUgaXMgNDJEMDYyMyAgICAg Cm1maTA6IDc0NzEgKGJvb3QgKyA4MXMvMHgwMDAyL2luZm8pIC0gSW5zZXJ0ZWQ6IFBEIDBjKGUw eGZmL3MxMikKbWZpMDogNzQ3MiAoYm9vdCArIDgxcy8weDAwMDIvaW5mbykgLSBJbnNlcnRlZDog UEQgMGMoZTB4ZmYvczEyKSBJbmZvOiBlbmNsUGQ9ZmZmZiwgc2NzaVR5cGU9MCwgcG9ydE1hcD0w Miwgc2FzQWRkcj01MDAwYzUwMDEyZmUxZDlkLDAwMDAwMDAwMDAwMDAwMDAKbWZpMDogNzQ3MyAo Ym9vdCArIDgxcy8weDAwMDIvaW5mbykgLSBQRCAwYyhlMHhmZi9zMTIpIEZSVSBpcyA0MkQwNjIz ICAgICAKbWZpMDogNzQ3NCAoYm9vdCArIDgxcy8weDAwMDIvaW5mbykgLSBJbnNlcnRlZDogUEQg MGQoZTB4ZmYvczEzKQptZmkwOiA3NDc1IChib290ICsgODFzLzB4MDAwMi9pbmZvKSAtIEluc2Vy dGVkOiBQRCAwZChlMHhmZi9zMTMpIEluZm86IGVuY2xQZD1mZmZmLCBzY3NpVHlwZT0wLCBwb3J0 TWFwPTAzLCBzYXNBZGRyPTUwMDBjNTAwMTJmYjQ4ZWQsMDAwMDAwMDAwMDAwMDAwMAptZmkwOiA3 NDc2IChib290ICsgODFzLzB4MDAwMi9pbmZvKSAtIFBEIDBkKGUweGZmL3MxMykgRlJVIGlzIDQy RDA2MjMgICAgIAptZmkwOiA3NDc3IChib290ICsgODFzLzB4MDAwMi9pbmZvKSAtIEluc2VydGVk OiBQRCAwZShlMHhmZi9zMTQpCm1maTA6IDc0NzggKGJvb3QgKyA4MXMvMHgwMDAyL2luZm8pIC0g SW5zZXJ0ZWQ6IFBEIDBlKGUweGZmL3MxNCkgSW5mbzogZW5jbFBkPWZmZmYsIHNjc2lUeXBlPTAs IHBvcnRNYXA9MDYsIHNhc0FkZHI9NTAwMGM1MDAxMmZlNzEwMSwwMDAwMDAwMDAwMDAwMDAwCm1m aTA6IDc0NzkgKGJvb3QgKyA4MXMvMHgwMDAyL2luZm8pIC0gUEQgMGUoZTB4ZmYvczE0KSBGUlUg aXMgNDJEMDYyMyAgICAgCm1maTA6IDc0ODAgKGJvb3QgKyA4MXMvMHgwMDAyL2luZm8pIC0gSW5z ZXJ0ZWQ6IFBEIDBmKGUweGZmL3MxNSkKbWZpMDogNzQ4MSAoYm9vdCArIDgxcy8weDAwMDIvaW5m bykgLSBJbnNlcnRlZDogUEQgMGYoZTB4ZmYvczE1KSBJbmZvOiBlbmNsUGQ9ZmZmZiwgc2NzaVR5 cGU9MCwgcG9ydE1hcD0wNywgc2FzQWRkcj01MDAwYzUwMDEyZmQ2YmFkLDAwMDAwMDAwMDAwMDAw MDAKbWZpMDogNzQ4MiAoYm9vdCArIDgxcy8weDAwMDIvaW5mbykgLSBQRCAwZihlMHhmZi9zMTUp IEZSVSBpcyA0MkQwNjIzICAgICAKbWZpMDogNzQ4MyAoYm9vdCArIDgxcy8weDAwMDEvaW5mbykg LSBQb2xpY3kgY2hhbmdlIG9uIFZEIDAwLzAgdG8gW0lEPTAwLGRjcD02ZCxjY3A9NmMsYXA9MCxk Yz0wLGRiZ2k9MF0gZnJvbSBbSUQ9MDAsZGNwPTZkLGNjcD02ZCxhcD0wLGRjPTAsZGJnaT0wXQpt ZmkwOiA3NDg0IChib290ICsgODJzLzB4MDAwOC9XQVJOKSAtIEJCVSBkaXNhYmxlZDsgY2hhbmdp bmcgV0IgdmlydHVhbCBkaXNrcyB0byBXVAppb2FwaWMwOiByb3V0aW5nIGludHBpbiAxNiAoUENJ IElSUSAxNikgdG8gdmVjdG9yIDUyCm1maTA6IFtNUFNBRkVdCm1maTA6IFtJVEhSRUFEXQpwY2li ODogPFBDSS1QQ0kgYnJpZGdlPiBpcnEgMTYgYXQgZGV2aWNlIDI4LjQgb24gcGNpMApwY2liODog ICBkb21haW4gICAgICAgICAgICAwCnBjaWI4OiAgIHNlY29uZGFyeSBidXMgICAgIDYKcGNpYjg6 ICAgc3Vib3JkaW5hdGUgYnVzICAgMTAKcGNpYjg6ICAgSS9PIGRlY29kZSAgICAgICAgMHhmMDAw LTB4ZmZmCnBjaWI4OiAgIG1lbW9yeSBkZWNvZGUgICAgIDB4OTcwMDAwMDAtMHg5NzhmZmZmZgpw Y2liODogICBwcmVmZXRjaGVkIGRlY29kZSAweDk2MDAwMDAwLTB4OTZmZmZmZmYKcGNpNjogPFBD SSBidXM+IG9uIHBjaWI4CnBjaTY6IGRvbWFpbj0wLCBwaHlzaWNhbCBidXM9Ngpmb3VuZC0+CXZl bmRvcj0weDEwMWIsIGRldj0weDA0NTIsIHJldmlkPTB4MDEKCWRvbWFpbj0wLCBidXM9Niwgc2xv dD0wLCBmdW5jPTAKCWNsYXNzPTA2LTA0LTAwLCBoZHJ0eXBlPTB4MDEsIG1mZGV2PTAKCWNtZHJl Zz0weDAwNDcsIHN0YXRyZWc9MHgwMDEwLCBjYWNoZWxuc3o9MTYgKGR3b3JkcykKCWxhdHRpbWVy PTB4MDAgKDAgbnMpLCBtaW5nbnQ9MHgwYiAoMjc1MCBucyksIG1heGxhdD0weDAwICgwIG5zKQoJ aW50cGluPWEsIGlycT0xMQoJcG93ZXJzcGVjIDMgIHN1cHBvcnRzIEQwIEQzICBjdXJyZW50IEQw CglNU0kgc3VwcG9ydHMgMiBtZXNzYWdlcywgNjQgYml0CnBjaWIwOiBtYXRjaGVkIGVudHJ5IGZv ciAwLjI4LklOVEEKcGNpYjA6IHNsb3QgMjggSU5UQSBoYXJkd2lyZWQgdG8gSVJRIDE2CnBjaWI4 OiBzbG90IDAgSU5UQSBpcyByb3V0ZWQgdG8gaXJxIDE2CnBjaWI5OiA8UENJLVBDSSBicmlkZ2U+ IGlycSAxNiBhdCBkZXZpY2UgMC4wIG9uIHBjaTYKcGNpYjk6ICAgZG9tYWluICAgICAgICAgICAg MApwY2liOTogICBzZWNvbmRhcnkgYnVzICAgICA3CnBjaWI5OiAgIHN1Ym9yZGluYXRlIGJ1cyAg IDcKcGNpYjk6ICAgSS9PIGRlY29kZSAgICAgICAgMHhmMDAwLTB4ZmZmCnBjaWI5OiAgIG1lbW9y eSBkZWNvZGUgICAgIDB4OTcwMDAwMDAtMHg5NzhmZmZmZgpwY2liOTogICBwcmVmZXRjaGVkIGRl Y29kZSAweDk2MDAwMDAwLTB4OTZmZmZmZmYKcGNpNzogPFBDSSBidXM+IG9uIHBjaWI5CnBjaTc6 IGRvbWFpbj0wLCBwaHlzaWNhbCBidXM9Nwpmb3VuZC0+CXZlbmRvcj0weDEwMmIsIGRldj0weDA1 MzAsIHJldmlkPTB4MDAKCWRvbWFpbj0wLCBidXM9Nywgc2xvdD0wLCBmdW5jPTAKCWNsYXNzPTAz LTAwLTAwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTAKCWNtZHJlZz0weDAwMDcsIHN0YXRyZWc9MHgw MjkwLCBjYWNoZWxuc3o9MTYgKGR3b3JkcykKCWxhdHRpbWVyPTB4NDAgKDE5MjAgbnMpLCBtaW5n bnQ9MHgxMCAoNDAwMCBucyksIG1heGxhdD0weDIwICg4MDAwIG5zKQoJaW50cGluPWEsIGlycT0x MQoJcG93ZXJzcGVjIDEgIHN1cHBvcnRzIEQwIEQzICBjdXJyZW50IEQwCgltYXBbMTBdOiB0eXBl IFByZWZldGNoYWJsZSBNZW1vcnksIHJhbmdlIDMyLCBiYXNlIDB4OTYwMDAwMDAsIHNpemUgMjQs IGVuYWJsZWQKcGNpYjk6IHJlcXVlc3RlZCBtZW1vcnkgcmFuZ2UgMHg5NjAwMDAwMC0weDk2ZmZm ZmZmOiBnb29kCnBjaWI4OiByZXF1ZXN0ZWQgbWVtb3J5IHJhbmdlIDB4OTYwMDAwMDAtMHg5NmZm ZmZmZjogZ29vZAoJbWFwWzE0XTogdHlwZSBNZW1vcnksIHJhbmdlIDMyLCBiYXNlIDB4OTc4MDAw MDAsIHNpemUgMTQsIGVuYWJsZWQKcGNpYjk6IHJlcXVlc3RlZCBtZW1vcnkgcmFuZ2UgMHg5Nzgw MDAwMC0weDk3ODAzZmZmOiBnb29kCnBjaWI4OiByZXF1ZXN0ZWQgbWVtb3J5IHJhbmdlIDB4OTc4 MDAwMDAtMHg5NzgwM2ZmZjogZ29vZAoJbWFwWzE4XTogdHlwZSBNZW1vcnksIHJhbmdlIDMyLCBi YXNlIDB4OTcwMDAwMDAsIHNpemUgMjMsIGVuYWJsZWQKcGNpYjk6IHJlcXVlc3RlZCBtZW1vcnkg cmFuZ2UgMHg5NzAwMDAwMC0weDk3N2ZmZmZmOiBnb29kCnBjaWI4OiByZXF1ZXN0ZWQgbWVtb3J5 IHJhbmdlIDB4OTcwMDAwMDAtMHg5NzdmZmZmZjogZ29vZApwY2liMDogbWF0Y2hlZCBlbnRyeSBm b3IgMC4yOC5JTlRBCnBjaWIwOiBzbG90IDI4IElOVEEgaGFyZHdpcmVkIHRvIElSUSAxNgpwY2li ODogc2xvdCAwIElOVEEgaXMgcm91dGVkIHRvIGlycSAxNgpwY2liOTogc2xvdCAwIElOVEEgaXMg cm91dGVkIHRvIGlycSAxNgp2Z2FwY2kwOiA8VkdBLWNvbXBhdGlibGUgZGlzcGxheT4gbWVtIDB4 OTYwMDAwMDAtMHg5NmZmZmZmZiwweDk3ODAwMDAwLTB4OTc4MDNmZmYsMHg5NzAwMDAwMC0weDk3 N2ZmZmZmIGlycSAxNiBhdCBkZXZpY2UgMC4wIG9uIHBjaTcKdWhjaTI6IDxVSENJIChnZW5lcmlj KSBVU0IgY29udHJvbGxlcj4gcG9ydCAweDIwNjAtMHgyMDdmIGlycSAxNyBhdCBkZXZpY2UgMjku MCBvbiBwY2kwCnVoY2kyOiBSZXNlcnZlZCAweDIwIGJ5dGVzIGZvciByaWQgMHgyMCB0eXBlIDQg YXQgMHgyMDYwCnVoY2kyOiBbR0lBTlQtTE9DS0VEXQp1aGNpMjogW0lUSFJFQURdCnVzYjM6IDxV SENJIChnZW5lcmljKSBVU0IgY29udHJvbGxlcj4gb24gdWhjaTIKdXNiMzogVVNCIHJldmlzaW9u IDEuMAp1aHViMzogPEludGVsIFVIQ0kgcm9vdCBodWIsIGNsYXNzIDkvMCwgcmV2IDEuMDAvMS4w MCwgYWRkciAxPiBvbiB1c2IzCnVodWIzOiAyIHBvcnRzIHdpdGggMiByZW1vdmFibGUsIHNlbGYg cG93ZXJlZAp1aGNpMzogPFVIQ0kgKGdlbmVyaWMpIFVTQiBjb250cm9sbGVyPiBwb3J0IDB4MjA0 MC0weDIwNWYgaXJxIDE4IGF0IGRldmljZSAyOS4xIG9uIHBjaTAKdWhjaTM6IFJlc2VydmVkIDB4 MjAgYnl0ZXMgZm9yIHJpZCAweDIwIHR5cGUgNCBhdCAweDIwNDAKdWhjaTM6IFtHSUFOVC1MT0NL RURdCnVoY2kzOiBbSVRIUkVBRF0KdXNiNDogPFVIQ0kgKGdlbmVyaWMpIFVTQiBjb250cm9sbGVy PiBvbiB1aGNpMwp1c2I0OiBVU0IgcmV2aXNpb24gMS4wCnVodWI0OiA8SW50ZWwgVUhDSSByb290 IGh1YiwgY2xhc3MgOS8wLCByZXYgMS4wMC8xLjAwLCBhZGRyIDE+IG9uIHVzYjQKdWh1YjQ6IDIg cG9ydHMgd2l0aCAyIHJlbW92YWJsZSwgc2VsZiBwb3dlcmVkCnVoY2k0OiA8VUhDSSAoZ2VuZXJp YykgVVNCIGNvbnRyb2xsZXI+IHBvcnQgMHgyMDIwLTB4MjAzZiBpcnEgMTkgYXQgZGV2aWNlIDI5 LjIgb24gcGNpMAp1aGNpNDogUmVzZXJ2ZWQgMHgyMCBieXRlcyBmb3IgcmlkIDB4MjAgdHlwZSA0 IGF0IDB4MjAyMAp1aGNpNDogW0dJQU5ULUxPQ0tFRF0KdWhjaTQ6IFtJVEhSRUFEXQp1c2I1OiA8 VUhDSSAoZ2VuZXJpYykgVVNCIGNvbnRyb2xsZXI+IG9uIHVoY2k0CnVzYjU6IFVTQiByZXZpc2lv biAxLjAKdWh1YjU6IDxJbnRlbCBVSENJIHJvb3QgaHViLCBjbGFzcyA5LzAsIHJldiAxLjAwLzEu MDAsIGFkZHIgMT4gb24gdXNiNQp1aHViNTogMiBwb3J0cyB3aXRoIDIgcmVtb3ZhYmxlLCBzZWxm IHBvd2VyZWQKZWhjaTE6IDxFSENJIChnZW5lcmljKSBVU0IgMi4wIGNvbnRyb2xsZXI+IG1lbSAw eDk3YTIxMDAwLTB4OTdhMjEzZmYgaXJxIDE3IGF0IGRldmljZSAyOS43IG9uIHBjaTAKZWhjaTE6 IFJlc2VydmVkIDB4NDAwIGJ5dGVzIGZvciByaWQgMHgxMCB0eXBlIDMgYXQgMHg5N2EyMTAwMApl aGNpMTogW0dJQU5ULUxPQ0tFRF0KZWhjaTE6IFtJVEhSRUFEXQp1c2I2OiBFSENJIHZlcnNpb24g MS4wCnVzYjY6IGNvbXBhbmlvbiBjb250cm9sbGVycywgMiBwb3J0cyBlYWNoOiB1c2IzIHVzYjQg dXNiNQp1c2I2OiA8RUhDSSAoZ2VuZXJpYykgVVNCIDIuMCBjb250cm9sbGVyPiBvbiBlaGNpMQp1 c2I2OiBVU0IgcmV2aXNpb24gMi4wCnVodWI2OiA8SW50ZWwgRUhDSSByb290IGh1YiwgY2xhc3Mg OS8wLCByZXYgMi4wMC8xLjAwLCBhZGRyIDE+IG9uIHVzYjYKdWh1YjY6IDYgcG9ydHMgd2l0aCA2 IHJlbW92YWJsZSwgc2VsZiBwb3dlcmVkCnBjaWIxMDogPFBDSS1QQ0kgYnJpZGdlPiBhdCBkZXZp Y2UgMzAuMCBvbiBwY2kwCnBjaWIxMDogICBkb21haW4gICAgICAgICAgICAwCnBjaWIxMDogICBz ZWNvbmRhcnkgYnVzICAgICA0MQpwY2liMTA6ICAgc3Vib3JkaW5hdGUgYnVzICAgNDUKcGNpYjEw OiAgIEkvTyBkZWNvZGUgICAgICAgIDB4MC0weDAKcGNpYjEwOiAgIG5vIHByZWZldGNoZWQgZGVj b2RlCnBjaWIxMDogICBTdWJ0cmFjdGl2ZWx5IGRlY29kZWQgYnJpZGdlLgpwY2k0MTogPFBDSSBi dXM+IG9uIHBjaWIxMApwY2k0MTogZG9tYWluPTAsIHBoeXNpY2FsIGJ1cz00MQppc2FiMDogPFBD SS1JU0EgYnJpZGdlPiBhdCBkZXZpY2UgMzEuMCBvbiBwY2kwCmlzYTA6IDxJU0EgYnVzPiBvbiBp c2FiMAphdGFwY2kwOiA8SW50ZWwgSUNIMTAgU0FUQTMwMCBjb250cm9sbGVyPiBwb3J0IDB4MWYw LTB4MWY3LDB4M2Y2LDB4MTcwLTB4MTc3LDB4Mzc2LDB4MjBmMC0weDIwZmYsMHgyMGUwLTB4MjBl ZiBpcnEgMTYgYXQgZGV2aWNlIDMxLjIgb24gcGNpMAphdGFwY2kwOiBSZXNlcnZlZCAweDEwIGJ5 dGVzIGZvciByaWQgMHgyMCB0eXBlIDQgYXQgMHgyMGYwCmF0YXBjaTA6IFJlc2VydmVkIDB4MTAg Ynl0ZXMgZm9yIHJpZCAweDI0IHR5cGUgNCBhdCAweDIwZTAKYXRhMDogPEFUQSBjaGFubmVsIDA+ IG9uIGF0YXBjaTAKYXRhcGNpMDogUmVzZXJ2ZWQgMHg4IGJ5dGVzIGZvciByaWQgMHgxMCB0eXBl IDQgYXQgMHgxZjAKYXRhcGNpMDogUmVzZXJ2ZWQgMHgxIGJ5dGVzIGZvciByaWQgMHgxNCB0eXBl IDQgYXQgMHgzZjYKYXRhMDogcmVzZXQgdHAxIG1hc2s9MDMgb3N0YXQwPTAwIG9zdGF0MT0wMAph dGEwOiBzdGF0MD0weDAwIGVycj0weDAxIGxzYj0weDE0IG1zYj0weGViCmF0YTA6IHN0YXQxPTB4 MDAgZXJyPTB4MDEgbHNiPTB4MTQgbXNiPTB4ZWIKYXRhMDogcmVzZXQgdHAyIHN0YXQwPTAwIHN0 YXQxPTAwIGRldmljZXM9MHhjPEFUQVBJX1NMQVZFLEFUQVBJX01BU1RFUj4KaW9hcGljMDogcm91 dGluZyBpbnRwaW4gMTQgKElTQSBJUlEgMTQpIHRvIHZlY3RvciA1MwphdGEwOiBbTVBTQUZFXQph dGEwOiBbSVRIUkVBRF0KYXRhMTogPEFUQSBjaGFubmVsIDE+IG9uIGF0YXBjaTAKYXRhcGNpMDog UmVzZXJ2ZWQgMHg4IGJ5dGVzIGZvciByaWQgMHgxOCB0eXBlIDQgYXQgMHgxNzAKYXRhcGNpMDog UmVzZXJ2ZWQgMHgxIGJ5dGVzIGZvciByaWQgMHgxYyB0eXBlIDQgYXQgMHgzNzYKYXRhMTogcmVz ZXQgdHAxIG1hc2s9MDMgb3N0YXQwPTdmIG9zdGF0MT03ZgphdGExOiBzdGF0MD0weDdmIGVycj0w eGZmIGxzYj0weGZmIG1zYj0weGZmCmF0YTE6IHN0YXQwPTB4N2YgZXJyPTB4ZmYgbHNiPTB4ZmYg bXNiPTB4ZmYKYXRhMTogc3RhdDA9MHg3ZiBlcnI9MHhmZiBsc2I9MHhmZiBtc2I9MHhmZgphdGEx OiBzdGF0MD0weDdmIGVycj0weGZmIGxzYj0weGZmIG1zYj0weGZmCmF0YTE6IHN0YXQwPTB4N2Yg ZXJyPTB4ZmYgbHNiPTB4ZmYgbXNiPTB4ZmYKYXRhMTogc3RhdDA9MHg3ZiBlcnI9MHhmZiBsc2I9 MHhmZiBtc2I9MHhmZgphdGExOiBzdGF0MD0weDdmIGVycj0weGZmIGxzYj0weGZmIG1zYj0weGZm CmF0YTE6IHN0YXQwPTB4N2YgZXJyPTB4ZmYgbHNiPTB4ZmYgbXNiPTB4ZmYKYXRhMTogc3RhdDA9 MHg3ZiBlcnI9MHhmZiBsc2I9MHhmZiBtc2I9MHhmZgphdGExOiBzdGF0MD0weDdmIGVycj0weGZm IGxzYj0weGZmIG1zYj0weGZmCmF0YTE6IHN0YXQwPTB4N2YgZXJyPTB4ZmYgbHNiPTB4ZmYgbXNi PTB4ZmYKYXRhMTogc3RhdDA9MHg3ZiBlcnI9MHhmZiBsc2I9MHhmZiBtc2I9MHhmZgphdGExOiBz dGF0MD0weDdmIGVycj0weGZmIGxzYj0weGZmIG1zYj0weGZmCmF0YTE6IHN0YXQwPTB4N2YgZXJy PTB4ZmYgbHNiPTB4ZmYgbXNiPTB4ZmYKYXRhMTogc3RhdDA9MHg3ZiBlcnI9MHhmZiBsc2I9MHhm ZiBtc2I9MHhmZgphdGExOiBzdGF0MD0weDdmIGVycj0weGZmIGxzYj0weGZmIG1zYj0weGZmCmF0 YTE6IHN0YXQwPTB4N2YgZXJyPTB4ZmYgbHNiPTB4ZmYgbXNiPTB4ZmYKYXRhMTogc3RhdDA9MHg3 ZiBlcnI9MHhmZiBsc2I9MHhmZiBtc2I9MHhmZgphdGExOiBzdGF0MD0weDdmIGVycj0weGZmIGxz Yj0weGZmIG1zYj0weGZmCmF0YTE6IHN0YXQwPTB4N2YgZXJyPTB4ZmYgbHNiPTB4ZmYgbXNiPTB4 ZmYKYXRhMTogc3RhdDA9MHg3ZiBlcnI9MHhmZiBsc2I9MHhmZiBtc2I9MHhmZgphdGExOiBzdGF0 MD0weDdmIGVycj0weGZmIGxzYj0weGZmIG1zYj0weGZmCmF0YTE6IHN0YXQxPTB4N2YgZXJyPTB4 ZmYgbHNiPTB4ZmYgbXNiPTB4ZmYKYXRhMTogcmVzZXQgdHAyIHN0YXQwPWZmIHN0YXQxPWZmIGRl dmljZXM9MHgwCmlvYXBpYzA6IHJvdXRpbmcgaW50cGluIDE1IChJU0EgSVJRIDE1KSB0byB2ZWN0 b3IgNTQKYXRhMTogW01QU0FGRV0KYXRhMTogW0lUSFJFQURdCnBjaTA6IDxzZXJpYWwgYnVzLCBT TUJ1cz4gYXQgZGV2aWNlIDMxLjMgKG5vIGRyaXZlciBhdHRhY2hlZCkKYXRhcGNpMTogPEludGVs IElDSDEwIFNBVEEzMDAgY29udHJvbGxlcj4gcG9ydCAweDIxMDgtMHgyMTBmLDB4MjEyNC0weDIx MjcsMHgyMTAwLTB4MjEwNywweDIxMjAtMHgyMTIzLDB4MjBkMC0weDIwZGYsMHgyMGMwLTB4MjBj ZiBpcnEgMjEgYXQgZGV2aWNlIDMxLjUgb24gcGNpMAphdGFwY2kxOiBSZXNlcnZlZCAweDEwIGJ5 dGVzIGZvciByaWQgMHgyMCB0eXBlIDQgYXQgMHgyMGQwCmlvYXBpYzA6IHJvdXRpbmcgaW50cGlu IDIxIChQQ0kgSVJRIDIxKSB0byB2ZWN0b3IgNTUKYXRhcGNpMTogW01QU0FGRV0KYXRhcGNpMTog W0lUSFJFQURdCmF0YXBjaTE6IFJlc2VydmVkIDB4MTAgYnl0ZXMgZm9yIHJpZCAweDI0IHR5cGUg NCBhdCAweDIwYzAKYXRhMjogPEFUQSBjaGFubmVsIDA+IG9uIGF0YXBjaTEKYXRhcGNpMTogUmVz ZXJ2ZWQgMHg4IGJ5dGVzIGZvciByaWQgMHgxMCB0eXBlIDQgYXQgMHgyMTA4CmF0YXBjaTE6IFJl c2VydmVkIDB4NCBieXRlcyBmb3IgcmlkIDB4MTQgdHlwZSA0IGF0IDB4MjEyNAphdGEyOiByZXNl dCB0cDEgbWFzaz0wMyBvc3RhdDA9N2Ygb3N0YXQxPTdmCmF0YTI6IHN0YXQwPTB4N2YgZXJyPTB4 ZmYgbHNiPTB4ZmYgbXNiPTB4ZmYKYXRhMjogc3RhdDA9MHg3ZiBlcnI9MHhmZiBsc2I9MHhmZiBt c2I9MHhmZgphdGEyOiBzdGF0MD0weDdmIGVycj0weGZmIGxzYj0weGZmIG1zYj0weGZmCmF0YTI6 IHN0YXQwPTB4N2YgZXJyPTB4ZmYgbHNiPTB4ZmYgbXNiPTB4ZmYKYXRhMjogc3RhdDA9MHg3ZiBl cnI9MHhmZiBsc2I9MHhmZiBtc2I9MHhmZgphdGEyOiBzdGF0MD0weDdmIGVycj0weGZmIGxzYj0w eGZmIG1zYj0weGZmCmF0YTI6IHN0YXQwPTB4N2YgZXJyPTB4ZmYgbHNiPTB4ZmYgbXNiPTB4ZmYK YXRhMjogc3RhdDA9MHg3ZiBlcnI9MHhmZiBsc2I9MHhmZiBtc2I9MHhmZgphdGEyOiBzdGF0MD0w eDdmIGVycj0weGZmIGxzYj0weGZmIG1zYj0weGZmCmF0YTI6IHN0YXQwPTB4N2YgZXJyPTB4ZmYg bHNiPTB4ZmYgbXNiPTB4ZmYKYXRhMjogc3RhdDA9MHg3ZiBlcnI9MHhmZiBsc2I9MHhmZiBtc2I9 MHhmZgphdGEyOiBzdGF0MD0weDdmIGVycj0weGZmIGxzYj0weGZmIG1zYj0weGZmCmF0YTI6IHN0 YXQwPTB4N2YgZXJyPTB4ZmYgbHNiPTB4ZmYgbXNiPTB4ZmYKYXRhMjogc3RhdDA9MHg3ZiBlcnI9 MHhmZiBsc2I9MHhmZiBtc2I9MHhmZgphdGEyOiBzdGF0MD0weDdmIGVycj0weGZmIGxzYj0weGZm IG1zYj0weGZmCmF0YTI6IHN0YXQwPTB4N2YgZXJyPTB4ZmYgbHNiPTB4ZmYgbXNiPTB4ZmYKYXRh Mjogc3RhdDA9MHg3ZiBlcnI9MHhmZiBsc2I9MHhmZiBtc2I9MHhmZgphdGEyOiBzdGF0MD0weDdm IGVycj0weGZmIGxzYj0weGZmIG1zYj0weGZmCmF0YTI6IHN0YXQwPTB4N2YgZXJyPTB4ZmYgbHNi PTB4ZmYgbXNiPTB4ZmYKYXRhMjogc3RhdDA9MHg3ZiBlcnI9MHhmZiBsc2I9MHhmZiBtc2I9MHhm ZgphdGEyOiBzdGF0MD0weDdmIGVycj0weGZmIGxzYj0weGZmIG1zYj0weGZmCmF0YTI6IHN0YXQw PTB4N2YgZXJyPTB4ZmYgbHNiPTB4ZmYgbXNiPTB4ZmYKYXRhMjogc3RhdDE9MHg3ZiBlcnI9MHhm ZiBsc2I9MHhmZiBtc2I9MHhmZgphdGEyOiByZXNldCB0cDIgc3RhdDA9ZmYgc3RhdDE9ZmYgZGV2 aWNlcz0weDAKYXRhMjogW01QU0FGRV0KYXRhMjogW0lUSFJFQURdCmF0YTM6IDxBVEEgY2hhbm5l bCAxPiBvbiBhdGFwY2kxCmF0YXBjaTE6IFJlc2VydmVkIDB4OCBieXRlcyBmb3IgcmlkIDB4MTgg dHlwZSA0IGF0IDB4MjEwMAphdGFwY2kxOiBSZXNlcnZlZCAweDQgYnl0ZXMgZm9yIHJpZCAweDFj IHR5cGUgNCBhdCAweDIxMjAKYXRhMzogcmVzZXQgdHAxIG1hc2s9MDMgb3N0YXQwPTdmIG9zdGF0 MT03ZgphdGEzOiBzdGF0MD0weDdmIGVycj0weGZmIGxzYj0weGZmIG1zYj0weGZmCmF0YTM6IHN0 YXQwPTB4N2YgZXJyPTB4ZmYgbHNiPTB4ZmYgbXNiPTB4ZmYKYXRhMzogc3RhdDA9MHg3ZiBlcnI9 MHhmZiBsc2I9MHhmZiBtc2I9MHhmZgphdGEzOiBzdGF0MD0weDdmIGVycj0weGZmIGxzYj0weGZm IG1zYj0weGZmCmF0YTM6IHN0YXQwPTB4N2YgZXJyPTB4ZmYgbHNiPTB4ZmYgbXNiPTB4ZmYKYXRh Mzogc3RhdDA9MHg3ZiBlcnI9MHhmZiBsc2I9MHhmZiBtc2I9MHhmZgphdGEzOiBzdGF0MD0weDdm IGVycj0weGZmIGxzYj0weGZmIG1zYj0weGZmCmF0YTM6IHN0YXQwPTB4N2YgZXJyPTB4ZmYgbHNi PTB4ZmYgbXNiPTB4ZmYKYXRhMzogc3RhdDA9MHg3ZiBlcnI9MHhmZiBsc2I9MHhmZiBtc2I9MHhm ZgphdGEzOiBzdGF0MD0weDdmIGVycj0weGZmIGxzYj0weGZmIG1zYj0weGZmCmF0YTM6IHN0YXQw PTB4N2YgZXJyPTB4ZmYgbHNiPTB4ZmYgbXNiPTB4ZmYKYXRhMzogc3RhdDA9MHg3ZiBlcnI9MHhm ZiBsc2I9MHhmZiBtc2I9MHhmZgphdGEzOiBzdGF0MD0weDdmIGVycj0weGZmIGxzYj0weGZmIG1z Yj0weGZmCmF0YTM6IHN0YXQwPTB4N2YgZXJyPTB4ZmYgbHNiPTB4ZmYgbXNiPTB4ZmYKYXRhMzog c3RhdDA9MHg3ZiBlcnI9MHhmZiBsc2I9MHhmZiBtc2I9MHhmZgphdGEzOiBzdGF0MD0weDdmIGVy cj0weGZmIGxzYj0weGZmIG1zYj0weGZmCmF0YTM6IHN0YXQwPTB4N2YgZXJyPTB4ZmYgbHNiPTB4 ZmYgbXNiPTB4ZmYKYXRhMzogc3RhdDA9MHg3ZiBlcnI9MHhmZiBsc2I9MHhmZiBtc2I9MHhmZgph dGEzOiBzdGF0MD0weDdmIGVycj0weGZmIGxzYj0weGZmIG1zYj0weGZmCmF0YTM6IHN0YXQwPTB4 N2YgZXJyPTB4ZmYgbHNiPTB4ZmYgbXNiPTB4ZmYKYXRhMzogc3RhdDA9MHg3ZiBlcnI9MHhmZiBs c2I9MHhmZiBtc2I9MHhmZgphdGEzOiBzdGF0MD0weDdmIGVycj0weGZmIGxzYj0weGZmIG1zYj0w eGZmCmF0YTM6IHN0YXQxPTB4N2YgZXJyPTB4ZmYgbHNiPTB4ZmYgbXNiPTB4ZmYKYXRhMzogcmVz ZXQgdHAyIHN0YXQwPWZmIHN0YXQxPWZmIGRldmljZXM9MHgwCmF0YTM6IFtNUFNBRkVdCmF0YTM6 IFtJVEhSRUFEXQpzaW8wOiBpcnEgbWFwczogMHhjMjEgMHhjMjkgMHhjMjEgMHhjMjEKc2lvMDog aXJxIG1hcHM6IDB4YzIxIDB4YzI5IDB4YzIxIDB4YzIxCnNpbzA6IDwxNjU1MEEtY29tcGF0aWJs ZSBDT00gcG9ydD4gcG9ydCAweDJmOC0weDJmZiBpcnEgMyBmbGFncyAweDEwIG9uIGFjcGkwCnNp bzA6IHR5cGUgMTY1NTBBCmlvYXBpYzA6IHJvdXRpbmcgaW50cGluIDMgKElTQSBJUlEgMykgdG8g dmVjdG9yIDU2CnNpbzA6IFtGSUxURVJdCmNwdTA6IDxBQ1BJIENQVT4gb24gYWNwaTAKY3B1MDog c3dpdGNoaW5nIHRvIGdlbmVyaWMgQ3ggbW9kZQplc3QwOiA8RW5oYW5jZWQgU3BlZWRTdGVwIEZy ZXF1ZW5jeSBDb250cm9sPiBvbiBjcHUwCmVzdDA6IEludmFsaWQgaWQxNiAoc2V0LCBjdXIpID0g KDE2LCAxNykKZXN0MDogSW52YWxpZCBmcmVxIDIxMjgsIGlnbm9yZWQuCmVzdDA6IEludmFsaWQg aWQxNiAoc2V0LCBjdXIpID0gKDE1LCAxNykKZXN0MDogSW52YWxpZCBmcmVxIDE5OTUsIGlnbm9y ZWQuCmVzdDA6IEludmFsaWQgaWQxNiAoc2V0LCBjdXIpID0gKDE0LCAxNykKZXN0MDogSW52YWxp ZCBmcmVxIDE4NjIsIGlnbm9yZWQuCmVzdDA6IEludmFsaWQgaWQxNiAoc2V0LCBjdXIpID0gKDEz LCAxNykKZXN0MDogSW52YWxpZCBmcmVxIDE3MjksIGlnbm9yZWQuCmVzdDA6IEludmFsaWQgaWQx NiAoc2V0LCBjdXIpID0gKDEyLCAxNykKZXN0MDogSW52YWxpZCBmcmVxIDE1OTYsIGlnbm9yZWQu CnA0dGNjMDogPENQVSBGcmVxdWVuY3kgVGhlcm1hbCBDb250cm9sPiBvbiBjcHUwCmNwdTE6IDxB Q1BJIENQVT4gb24gYWNwaTAKZXN0MTogPEVuaGFuY2VkIFNwZWVkU3RlcCBGcmVxdWVuY3kgQ29u dHJvbD4gb24gY3B1MQplc3QxOiBJbnZhbGlkIGlkMTYgKHNldCwgY3VyKSA9ICgxNiwgMTcpCmVz dDE6IEludmFsaWQgZnJlcSAyMTI4LCBpZ25vcmVkLgplc3QxOiBJbnZhbGlkIGlkMTYgKHNldCwg Y3VyKSA9ICgxNSwgMTcpCmVzdDE6IEludmFsaWQgZnJlcSAxOTk1LCBpZ25vcmVkLgplc3QxOiBJ bnZhbGlkIGlkMTYgKHNldCwgY3VyKSA9ICgxNCwgMTcpCmVzdDE6IEludmFsaWQgZnJlcSAxODYy LCBpZ25vcmVkLgplc3QxOiBJbnZhbGlkIGlkMTYgKHNldCwgY3VyKSA9ICgxMywgMTcpCmVzdDE6 IEludmFsaWQgZnJlcSAxNzI5LCBpZ25vcmVkLgplc3QxOiBJbnZhbGlkIGlkMTYgKHNldCwgY3Vy KSA9ICgxMiwgMTcpCmVzdDE6IEludmFsaWQgZnJlcSAxNTk2LCBpZ25vcmVkLgpwNHRjYzE6IDxD UFUgRnJlcXVlbmN5IFRoZXJtYWwgQ29udHJvbD4gb24gY3B1MQpjcHUyOiA8QUNQSSBDUFU+IG9u IGFjcGkwCmVzdDI6IDxFbmhhbmNlZCBTcGVlZFN0ZXAgRnJlcXVlbmN5IENvbnRyb2w+IG9uIGNw dTIKZXN0MjogSW52YWxpZCBpZDE2IChzZXQsIGN1cikgPSAoMTYsIDE3KQplc3QyOiBJbnZhbGlk IGZyZXEgMjEyOCwgaWdub3JlZC4KZXN0MjogSW52YWxpZCBpZDE2IChzZXQsIGN1cikgPSAoMTUs IDE3KQplc3QyOiBJbnZhbGlkIGZyZXEgMTk5NSwgaWdub3JlZC4KZXN0MjogSW52YWxpZCBpZDE2 IChzZXQsIGN1cikgPSAoMTQsIDE3KQplc3QyOiBJbnZhbGlkIGZyZXEgMTg2MiwgaWdub3JlZC4K ZXN0MjogSW52YWxpZCBpZDE2IChzZXQsIGN1cikgPSAoMTMsIDE3KQplc3QyOiBJbnZhbGlkIGZy ZXEgMTcyOSwgaWdub3JlZC4KZXN0MjogSW52YWxpZCBpZDE2IChzZXQsIGN1cikgPSAoMTIsIDE3 KQplc3QyOiBJbnZhbGlkIGZyZXEgMTU5NiwgaWdub3JlZC4KcDR0Y2MyOiA8Q1BVIEZyZXF1ZW5j eSBUaGVybWFsIENvbnRyb2w+IG9uIGNwdTIKY3B1MzogPEFDUEkgQ1BVPiBvbiBhY3BpMAplc3Qz OiA8RW5oYW5jZWQgU3BlZWRTdGVwIEZyZXF1ZW5jeSBDb250cm9sPiBvbiBjcHUzCmVzdDM6IElu dmFsaWQgaWQxNiAoc2V0LCBjdXIpID0gKDE2LCAxNykKZXN0MzogSW52YWxpZCBmcmVxIDIxMjgs IGlnbm9yZWQuCmVzdDM6IEludmFsaWQgaWQxNiAoc2V0LCBjdXIpID0gKDE1LCAxNykKZXN0Mzog SW52YWxpZCBmcmVxIDE5OTUsIGlnbm9yZWQuCmVzdDM6IEludmFsaWQgaWQxNiAoc2V0LCBjdXIp ID0gKDE0LCAxNykKZXN0MzogSW52YWxpZCBmcmVxIDE4NjIsIGlnbm9yZWQuCmVzdDM6IEludmFs aWQgaWQxNiAoc2V0LCBjdXIpID0gKDEzLCAxNykKZXN0MzogSW52YWxpZCBmcmVxIDE3MjksIGln bm9yZWQuCmVzdDM6IEludmFsaWQgaWQxNiAoc2V0LCBjdXIpID0gKDEyLCAxNykKZXN0MzogSW52 YWxpZCBmcmVxIDE1OTYsIGlnbm9yZWQuCnA0dGNjMzogPENQVSBGcmVxdWVuY3kgVGhlcm1hbCBD b250cm9sPiBvbiBjcHUzCmNwdTQ6IDxBQ1BJIENQVT4gb24gYWNwaTAKZXN0NDogPEVuaGFuY2Vk IFNwZWVkU3RlcCBGcmVxdWVuY3kgQ29udHJvbD4gb24gY3B1NAplc3Q6IENQVSBzdXBwb3J0cyBF bmhhbmNlZCBTcGVlZHN0ZXAsIGJ1dCBpcyBub3QgcmVjb2duaXplZC4KZXN0OiBjcHVfdmVuZG9y IEdlbnVpbmVJbnRlbCwgbXNyIDExCmRldmljZV9hdHRhY2g6IGVzdDQgYXR0YWNoIHJldHVybmVk IDYKcDR0Y2M0OiA8Q1BVIEZyZXF1ZW5jeSBUaGVybWFsIENvbnRyb2w+IG9uIGNwdTQKY3B1NTog PEFDUEkgQ1BVPiBvbiBhY3BpMAplc3Q1OiA8RW5oYW5jZWQgU3BlZWRTdGVwIEZyZXF1ZW5jeSBD b250cm9sPiBvbiBjcHU1CmVzdDogQ1BVIHN1cHBvcnRzIEVuaGFuY2VkIFNwZWVkc3RlcCwgYnV0 IGlzIG5vdCByZWNvZ25pemVkLgplc3Q6IGNwdV92ZW5kb3IgR2VudWluZUludGVsLCBtc3IgMTEK ZGV2aWNlX2F0dGFjaDogZXN0NSBhdHRhY2ggcmV0dXJuZWQgNgpwNHRjYzU6IDxDUFUgRnJlcXVl bmN5IFRoZXJtYWwgQ29udHJvbD4gb24gY3B1NQpjcHU2OiA8QUNQSSBDUFU+IG9uIGFjcGkwCmVz dDY6IDxFbmhhbmNlZCBTcGVlZFN0ZXAgRnJlcXVlbmN5IENvbnRyb2w+IG9uIGNwdTYKZXN0OiBD UFUgc3VwcG9ydHMgRW5oYW5jZWQgU3BlZWRzdGVwLCBidXQgaXMgbm90IHJlY29nbml6ZWQuCmVz dDogY3B1X3ZlbmRvciBHZW51aW5lSW50ZWwsIG1zciAxMQpkZXZpY2VfYXR0YWNoOiBlc3Q2IGF0 dGFjaCByZXR1cm5lZCA2CnA0dGNjNjogPENQVSBGcmVxdWVuY3kgVGhlcm1hbCBDb250cm9sPiBv biBjcHU2CmNwdTc6IDxBQ1BJIENQVT4gb24gYWNwaTAKZXN0NzogPEVuaGFuY2VkIFNwZWVkU3Rl cCBGcmVxdWVuY3kgQ29udHJvbD4gb24gY3B1Nwplc3Q6IENQVSBzdXBwb3J0cyBFbmhhbmNlZCBT cGVlZHN0ZXAsIGJ1dCBpcyBub3QgcmVjb2duaXplZC4KZXN0OiBjcHVfdmVuZG9yIEdlbnVpbmVJ bnRlbCwgbXNyIDExCmRldmljZV9hdHRhY2g6IGVzdDcgYXR0YWNoIHJldHVybmVkIDYKcDR0Y2M3 OiA8Q1BVIEZyZXF1ZW5jeSBUaGVybWFsIENvbnRyb2w+IG9uIGNwdTcKdW5rbm93bjogc3RhdHVz IHJlZyB0ZXN0IGZhaWxlZCBmZgp1bmtub3duOiBzdGF0dXMgcmVnIHRlc3QgZmFpbGVkIGZmCnVu a25vd246IHN0YXR1cyByZWcgdGVzdCBmYWlsZWQgZmYKdW5rbm93bjogc3RhdHVzIHJlZyB0ZXN0 IGZhaWxlZCBmZgp1bmtub3duOiBzdGF0dXMgcmVnIHRlc3QgZmFpbGVkIGZmCnVua25vd246IHN0 YXR1cyByZWcgdGVzdCBmYWlsZWQgZmYKYWhjX2lzYV9wcm9iZSAwOiBpb3BvcnQgMHhjMDAgYWxs b2MgZmFpbGVkCmV4X2lzYV9pZGVudGlmeSgpCmF0YTogYXRhMCBhbHJlYWR5IGV4aXN0czsgc2tp cHBpbmcgaXQKYXRhOiBhdGExIGFscmVhZHkgZXhpc3RzOyBza2lwcGluZyBpdApzaW86IHNpbzAg YWxyZWFkeSBleGlzdHM7IHNraXBwaW5nIGl0CnBucF9pZGVudGlmeTogVHJ5aW5nIFJlYWRfUG9y dCBhdCAyMDMKcG5wX2lkZW50aWZ5OiBUcnlpbmcgUmVhZF9Qb3J0IGF0IDI0MwpwbnBfaWRlbnRp Znk6IFRyeWluZyBSZWFkX1BvcnQgYXQgMjgzCnBucF9pZGVudGlmeTogVHJ5aW5nIFJlYWRfUG9y dCBhdCAyYzMKcG5wX2lkZW50aWZ5OiBUcnlpbmcgUmVhZF9Qb3J0IGF0IDMwMwpwbnBfaWRlbnRp Znk6IFRyeWluZyBSZWFkX1BvcnQgYXQgMzQzCnBucF9pZGVudGlmeTogVHJ5aW5nIFJlYWRfUG9y dCBhdCAzODMKcG5wX2lkZW50aWZ5OiBUcnlpbmcgUmVhZF9Qb3J0IGF0IDNjMwpQTlAgSWRlbnRp ZnkgY29tcGxldGUKc2M6IHNjMCBhbHJlYWR5IGV4aXN0czsgc2tpcHBpbmcgaXQKdmdhOiB2Z2Ew IGFscmVhZHkgZXhpc3RzOyBza2lwcGluZyBpdAppc2FfcHJvYmVfY2hpbGRyZW46IGRpc2FibGlu ZyBQblAgZGV2aWNlcwppc2FfcHJvYmVfY2hpbGRyZW46IHByb2Jpbmcgbm9uLVBuUCBkZXZpY2Vz CnBtdGltZXIwIG9uIGlzYTAKb3JtMDogPElTQSBPcHRpb24gUk9Ncz4gYXQgaW9tZW0gMHhjMDAw MC0weGM3ZmZmLDB4Y2MwMDAtMHhkMWZmZiBwbnBpZCBPUk0wMDAwIG9uIGlzYTAKYWR2MDogbm90 IHByb2JlZCAoZGlzYWJsZWQpCmFoYTA6IG5vdCBwcm9iZWQgKGRpc2FibGVkKQphaWMwOiBub3Qg cHJvYmVkIChkaXNhYmxlZCkKYXRrYmRjMDogPEtleWJvYXJkIGNvbnRyb2xsZXIgKGk4MDQyKT4g YXQgcG9ydCAweDYwLDB4NjQgb24gaXNhMAphdGtiZDA6IDxBVCBLZXlib2FyZD4gaXJxIDEgb24g YXRrYmRjMAphdGtiZDogdGhlIGN1cnJlbnQga2JkIGNvbnRyb2xsZXIgY29tbWFuZCBieXRlIDAw NGQKYXRrYmQ6IGtleWJvYXJkIElEIDB4ZmZmZmZmZmYgKDEpCmF0a2JkOiBmYWlsZWQgdG8gcmVz ZXQgdGhlIGtleWJvYXJkLgprYmQwIGF0IGF0a2JkMAprYmQwOiBhdGtiZDAsIEFUIDg0ICgxKSwg Y29uZmlnOjB4MCwgZmxhZ3M6MHgzZDAwMDAKaW9hcGljMDogcm91dGluZyBpbnRwaW4gMSAoSVNB IElSUSAxKSB0byB2ZWN0b3IgNTcKYXRrYmQwOiBbR0lBTlQtTE9DS0VEXQphdGtiZDA6IFtJVEhS RUFEXQpwc20wOiBjdXJyZW50IGNvbW1hbmQgYnl0ZTowMDRkCnBzbTA6IGZhaWxlZCB0byByZXNl dCB0aGUgYXV4IGRldmljZS4KYnQwOiBub3QgcHJvYmVkIChkaXNhYmxlZCkKY3MwOiBub3QgcHJv YmVkIChkaXNhYmxlZCkKZWQwOiBub3QgcHJvYmVkIChkaXNhYmxlZCkKZmRjMCBmYWlsZWQgdG8g cHJvYmUgYXQgcG9ydCAweDNmMC0weDNmNSwweDNmNyBpcnEgNiBkcnEgMiBvbiBpc2EwCmZlMDog bm90IHByb2JlZCAoZGlzYWJsZWQpCmllMDogbm90IHByb2JlZCAoZGlzYWJsZWQpCmxlMDogbm90 IHByb2JlZCAoZGlzYWJsZWQpCnBwYzA6IHBhcmFsbGVsIHBvcnQgbm90IGZvdW5kLgpwcGMwOiA8 UGFyYWxsZWwgcG9ydD4gZmFpbGVkIHRvIHByb2JlIGF0IGlycSA3IG9uIGlzYTAKc2MwOiA8U3lz dGVtIGNvbnNvbGU+IGF0IGZsYWdzIDB4MTAwIG9uIGlzYTAKc2MwOiBWR0EgPDE2IHZpcnR1YWwg Y29uc29sZXMsIGZsYWdzPTB4MzAwPgpzYzA6IGZiMCwga2JkMSwgdGVybWluYWwgZW11bGF0b3I6 IHNjIChzeXNjb25zIHRlcm1pbmFsKQpzaW8xIGZhaWxlZCB0byBwcm9iZSBhdCBwb3J0IDB4MmY4 IGlycSAzIG9uIGlzYTAKc2lvMjogbm90IHByb2JlZCAoZGlzYWJsZWQpCnNpbzM6IG5vdCBwcm9i ZWQgKGRpc2FibGVkKQpzbjA6IG5vdCBwcm9iZWQgKGRpc2FibGVkKQp2Z2EwOiA8R2VuZXJpYyBJ U0EgVkdBPiBhdCBwb3J0IDB4M2MwLTB4M2RmIGlvbWVtIDB4YTAwMDAtMHhiZmZmZiBvbiBpc2Ew CnZ0MDogbm90IHByb2JlZCAoZGlzYWJsZWQpCmlzYV9wcm9iZV9jaGlsZHJlbjogcHJvYmluZyBQ blAgZGV2aWNlcwp1bXMwOiA8TWljcm9zb2Z0IE1pY3Jvc29mdCAzLUJ1dHRvbiBNb3VzZSB3aXRo IEludGVsbGlFeWUoVE0pLCBjbGFzcyAwLzAsIHJldiAxLjEwLzMuMDAsIGFkZHIgMj4gb24gdWh1 YjAKdW1zMDogMyBidXR0b25zIGFuZCBaIGRpci4KY2RjZTA6IDxJQk0gUk5ESVMvQ0RDIEVUSEVS LCBjbGFzcyAyLzAsIHJldiAyLjAwLzIuMTUsIGFkZHIgMj4gb24gdWh1YjMKY2RjZTA6IGZha2lu ZyBNQUMgYWRkcmVzcwpjZGNlMDogV0FSTklORzogdXNpbmcgb2Jzb2xldGVkIElGRl9ORUVEU0dJ QU5UIGZsYWcKY2RjZTA6IGJwZiBhdHRhY2hlZApjZGNlMDogRXRoZXJuZXQgYWRkcmVzczogMmE6 MDA6MDA6MDA6MDA6MDAKdWtiZDA6IDxMSVRFT04gVGVjaG5vbG9neSBVU0IgTXVsdGltZWRpYSBL ZXlib2FyZCwgY2xhc3MgMC8wLCByZXYgMS4xMC8xLjAxLCBhZGRyIDI+IG9uIHVodWI1CmtiZDIg YXQgdWtiZDAKa2JkMjogdWtiZDAsIGdlbmVyaWMgKDApLCBjb25maWc6MHgwLCBmbGFnczoweDNk MDAwMApEZXZpY2UgY29uZmlndXJhdGlvbiBmaW5pc2hlZC4KUmVkdWNpbmcga2Vybi5tYXh2bm9k ZXMgMTMzNDcwIC0+IDEwMDAwMApwcm9jZnMgcmVnaXN0ZXJlZApsYXBpYzogRGl2aXNvciAyLCBG cmVxdWVuY3kgNjY2Njk1MTYgaHoKVGltZWNvdW50ZXIgIlRTQyIgZnJlcXVlbmN5IDIyNjY3NjM1 OTYgSHogcXVhbGl0eSAtMTAwClRpbWVjb3VudGVycyB0aWNrIGV2ZXJ5IDEuMDAwIG1zZWMKbG8w OiBicGYgYXR0YWNoZWQKaHB0cnI6IG5vIGNvbnRyb2xsZXIgZGV0ZWN0ZWQuCmF0YTA6IHJlaW5p dGluZyBjaGFubmVsIC4uCmF0YTA6IHJlc2V0IHRwMSBtYXNrPTAzIG9zdGF0MD0wMCBvc3RhdDE9 MDAKYXRhMDogc3RhdDA9MHgwMCBlcnI9MHgwMSBsc2I9MHgxNCBtc2I9MHhlYgphdGEwOiBzdGF0 MT0weDAwIGVycj0weDAxIGxzYj0weDE0IG1zYj0weGViCmF0YTA6IHJlc2V0IHRwMiBzdGF0MD0w MCBzdGF0MT0wMCBkZXZpY2VzPTB4YzxBVEFQSV9TTEFWRSxBVEFQSV9NQVNURVI+CmF0YTA6IHJl aW5pdCBkb25lIC4uCmF0YTA6IHJlaW5pdGluZyBjaGFubmVsIC4uCmF0YTA6IHJlc2V0IHRwMSBt YXNrPTAzIG9zdGF0MD0wMCBvc3RhdDE9MDAKYXRhMDogc3RhdDA9MHgwMCBlcnI9MHgwMSBsc2I9 MHgxNCBtc2I9MHhlYgphdGEwOiBzdGF0MT0weDAwIGVycj0weDAxIGxzYj0weDE0IG1zYj0weGVi CmF0YTA6IHJlc2V0IHRwMiBzdGF0MD0wMCBzdGF0MT0wMCBkZXZpY2VzPTB4YzxBVEFQSV9TTEFW RSxBVEFQSV9NQVNURVI+CmF0YTA6IHJlaW5pdCBkb25lIC4uCmF0YTAtbWFzdGVyOiBwaW89UElP NCB3ZG1hPVdETUEyIHVkbWE9VURNQTEzMyBjYWJsZT00MCB3aXJlCmFjZDA6IDxITC1EVC1TVCBE VkRSQU0gR1NBLVQ1ME4vUlkwNT4gRFZEUiBkcml2ZSBhdCBhdGEwIGFzIG1hc3RlcgphY2QwOiBy ZWFkIDQxMzRLQi9zICg0MTM0S0Ivcykgd3JpdGUgNDEzNEtCL3MgKDQxMzRLQi9zKSwgMjA0OEtC IGJ1ZmZlciwgU0FUQTE1MAphY2QwOiBSZWFkczogQ0RSLCBDRFJXLCBDRERBIHN0cmVhbSwgRFZE Uk9NLCBEVkRSLCBEVkRSQU0sIHBhY2tldAphY2QwOiBXcml0ZXM6IENEUiwgQ0RSVywgRFZEUiwg RFZEUkFNLCB0ZXN0IHdyaXRlLCBidXJucHJvb2YKYWNkMDogQXVkaW86IHBsYXksIDI1NiB2b2x1 bWUgbGV2ZWxzCmFjZDA6IE1lY2hhbmlzbTogZWplY3RhYmxlIHRyYXksIHVubG9ja2VkCmFjZDA6 IE1lZGl1bTogQ0QtUk9NIHVua25vd24KbWZpMDogNzQ4NSAoMzAxMDU3Mzk5cy8weDAwMjAvaW5m bykgLSBUaW1lIGVzdGFibGlzaGVkIGFzIDA3LzE2LzA5IDExOjAzOjE5OyAoMTI4IHNlY29uZHMg c2luY2UgcG93ZXIgb24pCm1maWQwOiA8TUZJIExvZ2ljYWwgRGlzaz4gb24gbWZpMAptZmlkMDog OTc0NjUyTUIgKDE5OTYwODcyOTYgc2VjdG9ycykgUkFJRCB2b2x1bWUgJycgaXMgb3B0aW1hbApB VEEgUHNldWRvUkFJRCBsb2FkZWQKU01QOiBBUCBDUFUgIzYgTGF1bmNoZWQhCmNwdTYgQVA6CiAg ICAgSUQ6IDB4MDYwMDAwMDAgICBWRVI6IDB4MDAwNjAwMTUgTERSOiAweDAwMDAwMDAwIERGUjog MHhmZmZmZmZmZgogIGxpbnQwOiAweDAwMDEwNzAwIGxpbnQxOiAweDAwMDAwNDAwIFRQUjogMHgw MDAwMDAwMCBTVlI6IDB4MDAwMDAxZmYKICB0aW1lcjogMHgwMDAyMDBlZiB0aGVybTogMHgwMDAx MDAwMCBlcnI6IDB4MDAwMTAwMDAgcGNtOiAweDAwMDEwMDAwClNNUDogQVAgQ1BVICMxIExhdW5j aGVkIQpjcHUxIEFQOgogICAgIElEOiAweDAxMDAwMDAwICAgVkVSOiAweDAwMDYwMDE1IExEUjog MHgwMDAwMDAwMCBERlI6IDB4ZmZmZmZmZmYKICBsaW50MDogMHgwMDAxMDcwMCBsaW50MTogMHgw MDAwMDQwMCBUUFI6IDB4MDAwMDAwMDAgU1ZSOiAweDAwMDAwMWZmCiAgdGltZXI6IDB4MDAwMjAw ZWYgdGhlcm06IDB4MDAwMTAwMDAgZXJyOiAweDAwMDEwMDAwIHBjbTogMHgwMDAxMDAwMApTTVA6 IEFQIENQVSAjNCBMYXVuY2hlZCEKY3B1NCBBUDoKICAgICBJRDogMHgwNDAwMDAwMCAgIFZFUjog MHgwMDA2MDAxNSBMRFI6IDB4MDAwMDAwMDAgREZSOiAweGZmZmZmZmZmCiAgbGludDA6IDB4MDAw MTA3MDAgbGludDE6IDB4MDAwMDA0MDAgVFBSOiAweDAwMDAwMDAwIFNWUjogMHgwMDAwMDFmZgog IHRpbWVyOiAweDAwMDIwMGVmIHRoZXJtOiAweDAwMDEwMDAwIGVycjogMHgwMDAxMDAwMCBwY206 IDB4MDAwMTAwMDAKU01QOiBBUCBDUFUgIzIgTGF1bmNoZWQhCmNwdTIgQVA6CiAgICAgSUQ6IDB4 MDIwMDAwMDAgICBWRVI6IDB4MDAwNjAwMTUgTERSOiAweDAwMDAwMDAwIERGUjogMHhmZmZmZmZm ZgogIGxpbnQwOiAweDAwMDEwNzAwIGxpbnQxOiAweDAwMDAwNDAwIFRQUjogMHgwMDAwMDAwMCBT VlI6IDB4MDAwMDAxZmYKICB0aW1lcjogMHgwMDAyMDBlZiB0aGVybTogMHgwMDAxMDAwMCBlcnI6 IDB4MDAwMTAwMDAgcGNtOiAweDAwMDEwMDAwClNNUDogQVAgQ1BVICM3IExhdW5jaGVkIQpjcHU3 IEFQOgogICAgIElEOiAweDA3MDAwMDAwICAgVkVSOiAweDAwMDYwMDE1IExEUjogMHgwMDAwMDAw MCBERlI6IDB4ZmZmZmZmZmYKICBsaW50MDogMHgwMDAxMDcwMCBsaW50MTogMHgwMDAwMDQwMCBU UFI6IDB4MDAwMDAwMDAgU1ZSOiAweDAwMDAwMWZmCiAgdGltZXI6IDB4MDAwMjAwZWYgdGhlcm06 IDB4MDAwMTAwMDAgZXJyOiAweDAwMDEwMDAwIHBjbTogMHgwMDAxMDAwMApTTVA6IEFQIENQVSAj MyBMYXVuY2hlZCEKY3B1MyBBUDoKICAgICBJRDogMHgwMzAwMDAwMCAgIFZFUjogMHgwMDA2MDAx NSBMRFI6IDB4MDAwMDAwMDAgREZSOiAweGZmZmZmZmZmCiAgbGludDA6IDB4MDAwMTA3MDAgbGlu dDE6IDB4MDAwMDA0MDAgVFBSOiAweDAwMDAwMDAwIFNWUjogMHgwMDAwMDFmZgogIHRpbWVyOiAw eDAwMDIwMGVmIHRoZXJtOiAweDAwMDEwMDAwIGVycjogMHgwMDAxMDAwMCBwY206IDB4MDAwMTAw MDAKU01QOiBBUCBDUFUgIzUgTGF1bmNoZWQhCmNwdTUgQVA6CiAgICAgSUQ6IDB4MDUwMDAwMDAg ICBWRVI6IDB4MDAwNjAwMTUgTERSOiAweDAwMDAwMDAwIERGUjogMHhmZmZmZmZmZgogIGxpbnQw OiAweDAwMDEwNzAwIGxpbnQxOiAweDAwMDAwNDAwIFRQUjogMHgwMDAwMDAwMCBTVlI6IDB4MDAw MDAxZmYKICB0aW1lcjogMHgwMDAyMDBlZiB0aGVybTogMHgwMDAxMDAwMCBlcnI6IDB4MDAwMTAw MDAgcGNtOiAweDAwMDEwMDAwCmlvYXBpYzA6IEFzc2lnbmluZyBJU0EgSVJRIDEgdG8gbG9jYWwg QVBJQyAwCmlvYXBpYzA6IEFzc2lnbmluZyBJU0EgSVJRIDMgdG8gbG9jYWwgQVBJQyAyCmlvYXBp YzA6IEFzc2lnbmluZyBJU0EgSVJRIDkgdG8gbG9jYWwgQVBJQyA0CmlvYXBpYzA6IEFzc2lnbmlu ZyBJU0EgSVJRIDE0IHRvIGxvY2FsIEFQSUMgNgppb2FwaWMwOiBBc3NpZ25pbmcgSVNBIElSUSAx NSB0byBsb2NhbCBBUElDIDAKaW9hcGljMDogQXNzaWduaW5nIFBDSSBJUlEgMTYgdG8gbG9jYWwg QVBJQyAyCmlvYXBpYzA6IEFzc2lnbmluZyBQQ0kgSVJRIDE3IHRvIGxvY2FsIEFQSUMgNAppb2Fw aWMwOiBBc3NpZ25pbmcgUENJIElSUSAxOCB0byBsb2NhbCBBUElDIDYKaW9hcGljMDogQXNzaWdu aW5nIFBDSSBJUlEgMTkgdG8gbG9jYWwgQVBJQyAwCmlvYXBpYzA6IEFzc2lnbmluZyBQQ0kgSVJR IDIxIHRvIGxvY2FsIEFQSUMgMgptc2k6IEFzc2lnbmluZyBNU0kgSVJRIDI1NiB0byBsb2NhbCBB UElDIDQKbXNpOiBBc3NpZ25pbmcgTVNJIElSUSAyNTcgdG8gbG9jYWwgQVBJQyA2CkdFT006IG5l dyBkaXNrIG1maWQwCkdFT01fTEFCRUw6IExhYmVsIGZvciBwcm92aWRlciBtZmlkMHMxYSBpcyB1 ZnNpZC80YTViNjk2ZTJmNDg5YTgxLgpHRU9NX0xBQkVMOiBMYWJlbCBmb3IgcHJvdmlkZXIgbWZp ZDBzMWQgaXMgdWZzaWQvNGE1Y2MzYWVhZWFkMTU2YS4KR0VPTV9MQUJFTDogTGFiZWwgZm9yIHBy b3ZpZGVyIG1maWQwczFlIGlzIHVmc2lkLzRhNWNjM2FjODk3MDE2NTUuCkdFT01fTEFCRUw6IExh YmVsIGZvciBwcm92aWRlciBtZmlkMHMxZiBpcyB1ZnNpZC80YTVjYzM2ZjYyZTMwOGQ4LgpUcnlp bmcgdG8gbW91bnQgcm9vdCBmcm9tIHVmczovZGV2L21maWQwczFhCnN0YXJ0X2luaXQ6IHRyeWlu ZyAvc2Jpbi9pbml0CkdFT01fTEFCRUw6IExhYmVsIHVmc2lkLzRhNWI2OTZlMmY0ODlhODEgcmVt b3ZlZC4KR0VPTV9MQUJFTDogTGFiZWwgZm9yIHByb3ZpZGVyIG1maWQwczFhIGlzIHVmc2lkLzRh NWI2OTZlMmY0ODlhODEuCkdFT01fTEFCRUw6IExhYmVsIHVmc2lkLzRhNWNjMzZmNjJlMzA4ZDgg cmVtb3ZlZC4KR0VPTV9MQUJFTDogTGFiZWwgZm9yIHByb3ZpZGVyIG1maWQwczFmIGlzIHVmc2lk LzRhNWNjMzZmNjJlMzA4ZDguCkdFT01fTEFCRUw6IExhYmVsIHVmc2lkLzRhNWNjM2FjODk3MDE2 NTUgcmVtb3ZlZC4KR0VPTV9MQUJFTDogTGFiZWwgZm9yIHByb3ZpZGVyIG1maWQwczFlIGlzIHVm c2lkLzRhNWNjM2FjODk3MDE2NTUuCkdFT01fTEFCRUw6IExhYmVsIHVmc2lkLzRhNWNjM2FlYWVh ZDE1NmEgcmVtb3ZlZC4KR0VPTV9MQUJFTDogTGFiZWwgZm9yIHByb3ZpZGVyIG1maWQwczFkIGlz IHVmc2lkLzRhNWNjM2FlYWVhZDE1NmEuCkdFT01fTEFCRUw6IExhYmVsIHVmc2lkLzRhNWI2OTZl MmY0ODlhODEgcmVtb3ZlZC4KR0VPTV9MQUJFTDogTGFiZWwgdWZzaWQvNGE1Y2MzNmY2MmUzMDhk OCByZW1vdmVkLgpHRU9NX0xBQkVMOiBMYWJlbCB1ZnNpZC80YTVjYzNhYzg5NzAxNjU1IHJlbW92 ZWQuCkdFT01fTEFCRUw6IExhYmVsIHVmc2lkLzRhNWNjM2FlYWVhZDE1NmEgcmVtb3ZlZC4KTGlu dXggRUxGIGV4ZWMgaGFuZGxlciBpbnN0YWxsZWQKYmNlMDogbGluayBzdGF0ZSBjaGFuZ2VkIHRv IFVQCg== --001636765b692890dd046ecd5539-- From owner-freebsd-stable@FreeBSD.ORG Thu Jul 16 08:54: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 456F51065673 for ; Thu, 16 Jul 2009 08:54:46 +0000 (UTC) (envelope-from dan.naumov@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.243]) by mx1.freebsd.org (Postfix) with ESMTP id EDA638FC21 for ; Thu, 16 Jul 2009 08:54:45 +0000 (UTC) (envelope-from dan.naumov@gmail.com) Received: by an-out-0708.google.com with SMTP id d14so2101209and.13 for ; Thu, 16 Jul 2009 01:54:45 -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=biFKqVfzxWKakPSWrb/IEfF5fhOdtA7eO/t203TcGg4=; b=lghFJ7vvCHBptpFv5p0eihi6SarHv/waFL8APTPzmNorPKqf5EbCNizAnAFW74J7t7 EQN53uZ3XCHwG+SCN4gc25vNYQrNO5sjlNekXsjoJH8LK4YT4EQm6q8JxnZ72mZN0M2j c/1qsDgakZPtDgjKZyl5JCxo1rO3M4M6ooogE= 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=X9YGvoyZ6gTRrMSU2F+IOySvsSxTyDAxORBAi1lJAxOzGwD0JVVDLCGsu0jLxh5IDA ZIIQ9mCGtLY6I6zhOCfsH87z7H7qSmJcBVMvbyNh7bBnH0uah47FeIj5+tmABIAAZv4e LTAz/ob/61C10fTYEkmN1rnDr0+iZAHbfvS/I= MIME-Version: 1.0 Received: by 10.100.171.13 with SMTP id t13mr11510542ane.94.1247734485219; Thu, 16 Jul 2009 01:54:45 -0700 (PDT) In-Reply-To: <4A5ECC8C.7030808@gmail.com> References: <3bbf2fe10907061818v245abd0cgc3ca5073cb93aea4@mail.gmail.com> <3bbf2fe10907061827g35eaeb49g26cf6fdb64436ca7@mail.gmail.com> <3bbf2fe10907080250q35899d3dhc2f101b62c6e5306@mail.gmail.com> <4A5ECC8C.7030808@gmail.com> Date: Thu, 16 Jul 2009 11:54:45 +0300 Message-ID: From: Dan Naumov To: "C. C. Tang" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org 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: Thu, 16 Jul 2009 08:54:46 -0000 >> But is that happening at reboot time? >> >> Thanks, >> Attilio >> > > I think I am also having similar problem on my Atom machine. > (FreeBSD-7.2-Release-p1) > It does not happen at boot/reboot but panic randomly. > And I found that it remains stable for more than a month now after I > disabled powerd... (although I want to have it enabled) I hope you can get some crash dumps for the developers to look at, Attilio was trying to help me but sadly the machine had to be put into active use so I could no longer play with FreeBSD due to unsolved instability. - Sincerely, Dan Naumov From owner-freebsd-stable@FreeBSD.ORG Thu Jul 16 09:43: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 0D6391065670 for ; Thu, 16 Jul 2009 09:43:06 +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 2477E8FC28 for ; Thu, 16 Jul 2009 09:43:04 +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: ApsEAJWSXkrCVfWh/2dsb2JhbACBUc88gm2BHgWBQA X-IronPort-AV: E=Sophos;i="4.42,410,1243800000"; d="p7s'?scan'208";a="4329003" Received: from mail.ksu.ru (HELO ruby.ksu.ru) ([193.232.252.56]) by iout.kzn.ru with ESMTP; 16 Jul 2009 13:43:02 +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 n6G8iY6Z026163 for ; Thu, 16 Jul 2009 08:44:34 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 n6G9gY2W019401 for ; Thu, 16 Jul 2009 13:42:34 +0400 (MSD) (envelope-from amarat@ksu.ru) Message-ID: <4A5EF609.10000@ksu.ru> Date: Thu, 16 Jul 2009 13:42:33 +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 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050009020402090002020306" Subject: coretemp(4) build broken in recent 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: Thu, 16 Jul 2009 09:43:06 -0000 This is a cryptographically signed message in MIME format. --------------ms050009020402090002020306 Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit i have 7.2-S csupped to today midnight and while trying to build kernel i have the following error: ===> coretemp (all) cc -O2 -fno-strict-aliasing -pipe -O2 -pipe -msse2 -msse3 -m3dnow -march=athlon64 -D_KERNEL -DKLD_MODULE -std=c99 -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj/usr/src/sys/ZEALOT/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -fno-omit-frame-pointer -I/usr/obj/usr/src/sys/ZEALOT -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -c /usr/src/sys/modules/coretemp/../../dev/coretemp/coretemp.c /usr/src/sys/modules/coretemp/../../dev/coretemp/coretemp.c: In function 'coretemp_identify': /usr/src/sys/modules/coretemp/../../dev/coretemp/coretemp.c:98: error: 'cpu_vendor_id' undeclared (first use in this function) /usr/src/sys/modules/coretemp/../../dev/coretemp/coretemp.c:98: error: (Each undeclared identifier is reported only once /usr/src/sys/modules/coretemp/../../dev/coretemp/coretemp.c:98: error: for each function it appears in.) /usr/src/sys/modules/coretemp/../../dev/coretemp/coretemp.c:98: error: 'CPU_VENDOR_INTEL' undeclared (first use in this function) *** Error code 1 Stop in /usr/src/sys/modules/coretemp. *** Error code 1 i've tried to find either cpu_vendor_id or CPU_VENDOR_INTEL in source tree, but didn't succeeded. can anybody reproduce this error? and can anybody tell how to fix it? :) -- SY, Marat --------------ms050009020402090002020306 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 AKCCAcMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDkwNzE2 MDk0MjM0WjAjBgkqhkiG9w0BCQQxFgQUU3bWsKKFXNp1Ve9dO2Iddp8gbCowUgYJKoZIhvcN AQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYF Kw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhB6bDKOp5G1FXoMYwM88WApMIGHBgsq hkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1 aW5nIENBAhB6bDKOp5G1FXoMYwM88WApMA0GCSqGSIb3DQEBAQUABIIBAA+WvEYM4ulhXxdE UCMyQDLUqK277tWtvwJmzAvI8kVKikf+jmWPClV9zj/kRbfxG26qP8MOWABDOyaXs4VkZURx 7w+L7vHHxii2/qlW08+a2mLfnMSlYMvH6T/JPNsBkWJZ/M+gEjQU8j7X9YtJ9OkWW0GT87zs pelp9/Lqr/4FwTeODvSM8uhJC9v848/pl1HnYB8X0jl8c988whjV90Ej6VaDy5G5n6HkXKFg c5WTJTdDsMpxTwCd64IqzIm1wP6N6aeVH5iIQOmMUaWE3PznRf0GWx+Ga9hm0y1cvPiptEWL odFlD4XjoBjG/6AzujwwHssW2g5MEX7Jf26YbP0AAAAAAAA= --------------ms050009020402090002020306-- From owner-freebsd-stable@FreeBSD.ORG Thu Jul 16 11:05: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 DCE441065675 for ; Thu, 16 Jul 2009 11:05:45 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 160B18FC15 for ; Thu, 16 Jul 2009 11:05:44 +0000 (UTC) (envelope-from avg@freebsd.org) 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 OAA14022; Thu, 16 Jul 2009 14:04:56 +0300 (EEST) (envelope-from avg@freebsd.org) Message-ID: <4A5F0958.4050504@freebsd.org> Date: Thu, 16 Jul 2009 14:04:56 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.22 (X11/20090630) MIME-Version: 1.0 To: "Marat N.Afanasyev" References: <4A5EF609.10000@ksu.ru> In-Reply-To: <4A5EF609.10000@ksu.ru> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit Cc: freebsd-stable Subject: Re: coretemp(4) build broken in recent 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: Thu, 16 Jul 2009 11:05:46 -0000 on 16/07/2009 12:42 Marat N.Afanasyev said the following: > i have 7.2-S csupped to today midnight and while trying to build kernel > i have the following error: [snip] > i've tried to find either cpu_vendor_id or CPU_VENDOR_INTEL in source > tree, but didn't succeeded. can anybody reproduce this error? and can > anybody tell how to fix it? :) It seems that you are using CVSup server with out-of-sync data. This has already been discussed, but not on the public mailing lists. In that case the offending server was cvsup7.ru.FreeBSD.org -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Thu Jul 16 11:16: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 EE708106564A for ; Thu, 16 Jul 2009 11:16:04 +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 EB5F08FC1E for ; Thu, 16 Jul 2009 11:16:03 +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: ApsEAM+oXkrCVfWh/2dsb2JhbACBUc8Hgm2BHgWBQA X-IronPort-AV: E=Sophos;i="4.42,410,1243800000"; d="p7s'?scan'208";a="4330539" Received: from mail.ksu.ru (HELO ruby.ksu.ru) ([193.232.252.56]) by iout.kzn.ru with ESMTP; 16 Jul 2009 15:16:02 +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 n6GAHUGE020370; Thu, 16 Jul 2009 10:17:30 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 n6GBFU7U020583; Thu, 16 Jul 2009 15:15:30 +0400 (MSD) (envelope-from amarat@ksu.ru) Message-ID: <4A5F0BD2.6060105@ksu.ru> Date: Thu, 16 Jul 2009 15:15:30 +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: Andriy Gapon References: <4A5EF609.10000@ksu.ru> <4A5F0958.4050504@freebsd.org> In-Reply-To: <4A5F0958.4050504@freebsd.org> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040003000307040901080603" Cc: freebsd-stable Subject: Re: coretemp(4) build broken in recent 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: Thu, 16 Jul 2009 11:16:05 -0000 This is a cryptographically signed message in MIME format. --------------ms040003000307040901080603 Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Andriy Gapon wrote: > on 16/07/2009 12:42 Marat N.Afanasyev said the following: >> i have 7.2-S csupped to today midnight and while trying to build kernel >> i have the following error: > [snip] >> i've tried to find either cpu_vendor_id or CPU_VENDOR_INTEL in source >> tree, but didn't succeeded. can anybody reproduce this error? and can >> anybody tell how to fix it? :) > > It seems that you are using CVSup server with out-of-sync data. > This has already been discussed, but not on the public mailing lists. > In that case the offending server was cvsup7.ru.FreeBSD.org > it seems so -- SY, Marat --------------ms040003000307040901080603 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 AKCCAcMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDkwNzE2 MTExNTMwWjAjBgkqhkiG9w0BCQQxFgQU9irAXOfYup7fWc1eSwKYXLjd4XkwUgYJKoZIhvcN AQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYF Kw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhB6bDKOp5G1FXoMYwM88WApMIGHBgsq hkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1 aW5nIENBAhB6bDKOp5G1FXoMYwM88WApMA0GCSqGSIb3DQEBAQUABIIBAGgtWkvYXkaLQ7pU vb0pc7sgjrq0ifUgfd+fn9zNq/lVTbll0ITLBhAzE//IHc2ZVe7BunudlQJbfgLL8UvZfiIJ S8Q982SJSuOmQlAYD52L8LO4unpv3OF9m9uw1Xa+/DWD7thJl1T9I/Pt3ftgSAg8NevzU7cm O47mheDMNzqBMlbfPYVDz0PhmGVrJlZqEIzFthgC/JxE7cNb6rIwrm/Iva8qiyct4A42AamR W1KQ8DfZjySWXrEBrqAyM+zZgZ51ljr/uKoW0xk3WxHaEBLULeqU4Xjy/X100jLl9uEwM2xS xelWB3l31KbZKaZG6mVuW0uS/SB2x7IE5Td8KmYAAAAAAAA= --------------ms040003000307040901080603-- From owner-freebsd-stable@FreeBSD.ORG Thu Jul 16 19:01: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 B9DCC1065674 for ; Thu, 16 Jul 2009 19:01:46 +0000 (UTC) (envelope-from jfb@mr-happy.com) Received: from vexbert.mr-paradox.net (vexbert.mr-paradox.net [IPv6:2001:470:b:28:f::1]) by mx1.freebsd.org (Postfix) with ESMTP id 9D6118FC20 for ; Thu, 16 Jul 2009 19:01:46 +0000 (UTC) (envelope-from jfb@mr-happy.com) Received: from crow.mr-happy.com (crow.mr-happy.com [10.1.0.2]) by vexbert.mr-paradox.net (Postfix) with ESMTP id 9EEDE84550 for ; Thu, 16 Jul 2009 15:01:45 -0400 (EDT) Received: by crow.mr-happy.com (Postfix, from userid 16139) id F32CC4501B; Thu, 16 Jul 2009 15:01:44 -0400 (EDT) Date: Thu, 16 Jul 2009 15:01:44 -0400 From: Jeff Blank To: freebsd-stable@freebsd.org Message-ID: <20090716190144.GB88257@mr-happy.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Face: #0jV*~a}VtKS-&E/!EJpH('H1Va}24dxF0oT&+.R3Gu8C; xhSC+<|+H84&YLbMvphuRT4cp3.|8EN_(2Eix/6{.Up~u`a^}0Ln&b+9Fw|BPig@-{y\pL_46d&ZwA]5%_AU?}DezfE&1!>H?3E$!Yve7.O<+..Jnb4:'6Ey_]FtFzU9=*l$1p/@gA,Ze>^5<]+r(XJ+m7`/vMDc$'wy|`e Subject: 7.2-STABLE amd64 panic at/after mount root (ZFS) 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, 16 Jul 2009 19:01:47 -0000 Hi, I've built RELENG_7 from sources csupped at around 0700 UTC today. 'make installkernel', reboot, panic: ===== Trying to mount root from zfs:zgm0/root Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x0 fault code = supervisor read data, page not present instruction pointer = 0x8:0xffffffff80da14fd stack pointer = 0x10:0xffffff800001efd0 frame pointer = 0x10:0xffffff800001f020 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 = 1 (swapper) trap number = 12 panic: page fault cpuid = 0 GEOM_MIRROR: Device gm0: rebuilding provider ad4 stopped. Uptime: 8s Cannot dump. No dump device defined. Automatic reboot in 15 seconds - press a key on the console to abort ===== My ZFS pool is from well before the recent ZFS MFC. The full text of the boot-up is below, along with loader.conf. As maybe something of a side note, I rebuilt the kernel with options DDB options KDB options KDB_UNATTENDED options BREAK_TO_DEBUGGER added to GENERIC, but I'm unable to access the debugger fully. Using vidconsole, a USB keyboard is non-responsive once the panic occurs, and this system has no PS/2 ports. I tried using comconsole, but this system appears to have squirrely serial as well, so while I can "press a key" and get a ddb prompt, what I type does not show up or shows up as something else, as though there's a baud-rate mismatch. (comconsole works fine from the loader to the ddb prompt, but it fails to be useful once that point is reached.) Does anyone have any suggestions as to how I can access the debugger? Thank you for any help with any of this. Jeff /boot/loader.conf: ===== beastie_disable=YES atapicam_load=YES snd_hda_load=YES snd_driver_load=NO linux_load=YES geom_mirror_load=YES hw.pci.enable_msi=0 zfs_load=YES vfs.zfs.arc_max=256M vfs.root.mountfrom="zfs:zgm0/root" ===== console output: ===== KDB: debugger backends: ddb KDB: current backend: ddb 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 #0: Thu Jul 16 13:26:59 EDT 2009 root@bender.tc.mtu.edu:/usr/obj/usr/src/sys/DEBUG Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 5600+ (2906.09-MHz K8-class CPU) Origin = "AuthenticAMD" Id = 0x60fb2 Stepping = 2 Features=0x178bfbff Features2=0x2001 AMD Features=0xea500800 AMD Features2=0x11f TSC: P-state invariant Cores per package: 2 usable memory = 4277772288 (4079 MB) avail memory = 4097368064 (3907 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 This module (opensolaris) contains code covered by the Common Development and Distribution License (CDDL) see http://opensolaris.org/os/licensing/opensolaris_license/ ioapic0: Changing APIC ID to 4 ioapic0 irqs 0-23 on motherboard kbd0 at kbdmux0 acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, bfdd0000 (3) failed Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 acpi_hpet0: iomem 0xfeff0000-0xfeff03ff on acpi0 Timecounter "HPET" frequency 25000000 Hz quality 900 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: at device 0.0 (no driver attached) pci0: at device 0.1 (no driver attached) pci0: at device 0.2 (no driver attached) pci0: at device 0.3 (no driver attached) pci0: at device 0.4 (no driver attached) pci0: at device 0.5 (no driver attached) pci0: at device 0.6 (no driver attached) pci0: at device 0.7 (no driver attached) pcib1: at device 2.0 on pci0 pci1: on pcib1 pcib2: at device 3.0 on pci0 pci2: on pcib2 bge0: mem 0xf d8f0000-0xfd8fffff irq 16 at device 0.0 on pci2 miibus0: on bge0 brgphy0: PHY 1 on miibus0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-F DX, auto bge0: Ethernet address: 00:1e:c9:44:30:14 bge0: [ITHREAD] pcib3: at device 4.0 on pci0 pci3: on pcib3 vgapci0: port 0xbc00-0xbcff mem 0xd0000000-0xdfffffff,0 xfddf0000-0xfddfffff irq 16 at device 0.0 on pci3 vgapci1: mem 0xfdde0000-0xfddeffff at device 0.1 on pci 3 pci0: at device 9.0 (no driver attached) isab0: port 0x1d00-0x1dff at device 10.0 on pci0 isa0: on isab0 pci0: at device 10.1 (no driver attached) pci0: at device 10.2 (no driver attached) ohci0: mem 0xfe02f000-0xfe02ffff irq 21 at devic e 11.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: 8 ports with 8 removable, self powered ehci0: mem 0xfe02e000-0xfe02e0ff irq 22 at d evice 11.1 on pci0 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb1: EHCI version 1.0 usb1: companion controller, 8 ports each: usb0 usb1: on ehci0 usb1: USB revision 2.0 uhub1: on usb1 uhub1: 8 ports with 8 removable, self powered atapci0: port 0x9f0-0x9f7,0xbf0-0xbf3,0 x970-0x977,0xb70-0xb73,0xe000-0xe00f mem 0xfe02d000-0xfe02dfff irq 23 at device 14.0 on pci0 atapci0: [ITHREAD] ata2: on atapci0 ata2: [ITHREAD] ata3: on atapci0 ata3: [ITHREAD] atapci1: port 0x9e0-0x9e7,0xbe0-0xbe3,0 x960-0x967,0xb60-0xb63,0xcc00-0xcc0f mem 0xfe02c000-0xfe02cfff irq 20 at device 15.0 on pci0 atapci1: [ITHREAD] ata4: on atapci1 ata4: [ITHREAD] ata5: on atapci1 ata5: [ITHREAD] pcib4: at device 16.0 on pci0 pci4: on pcib4 txp0: <3Com 3cR990-SRV-97 Etherlink Server with 3XP Processor> port 0x9c00-0x9c7 f mem 0xfdcc0000-0xfdcfffff irq 16 at device 8.0 on pci4 txp0: Typhoon 1.0 sleep image (2000/07/07) txp0: Ethernet address: 00:04:76:f8:0c:b2 txp0: [FILTER] hdac0: mem 0xfe024000-0xfe027fff irq 21 at device 16.1 on pci0 hdac0: HDA Driver Revision: 20090624_0136 hdac0: [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, console sio0: [FILTER] ppc0: port 0x378-0x37f irq 7 on acpi0 ppc0: Generic chipset (EPP/NIBBLE) in COMPATIBLE mode ppbus0: on ppc0 ppbus0: [ITHREAD] ppi0: on ppbus0 plip0: on ppbus0 plip0: WARNING: using obsoleted IFF_NEEDSGIANT flag lpt0: on ppbus0 lpt0: Interrupt-driven port ppc0: [GIANT-LOCKED] ppc0: [ITHREAD] cpu0: on acpi0 powernow0: on cpu0 cpu1: on acpi0 powernow1: on cpu1 orm0: at iomem 0xc0000-0xcf7ff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 ukbd0: on uhub0 kbd1 at ukbd0 ums0: on uhub0 ums0: 3 buttons and Z dir. ums1: on uhub0 ums1: 5 buttons and Z dir. WARNING: ZFS is considered to be an experimental feature in FreeBSD. Timecounters tick every 1.000 msec ZFS filesystem version 13 ZFS storage pool version 13 ad4: 152587MB at ata2-master SATA300 ad6: 152587MB at ata3-master SATA300 GEOM_MIRROR: Device mirror/gm0 launched (1/2). GEOM_MIRROR: Device gm0: rebuilding provider ad4. acd0: CDROM at ata4-master SATA150 acd1: CDRW at ata5-master SATA150 hdac0: HDA Codec #0: Sigmatel STAC9220 pcm0: at cad 0 nid 1 on hdac0 acd1: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 (probe1:ata3:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 (probe1:ata3:0:0:0): CAM Status: SCSI Status Error (probe1:ata3:0:0:0): SCSI Status: Check Condition (probe1:ata3:0:0:0): NOT READY asc:3a,1 (probe1:ata3:0:0:0): Medium not present - tray closed (probe1:ata3:0:0:0): Unretryable error acd1: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 (probe0:ata2:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 (probe0:ata2:0:0:0): CAM Status: SCSI Status Error (probe0:ata2:0:0:0): SCSI Status: Check Condition (probe0:ata2:0:0:0): NOT READY asc:3a,0 (probe0:ata2:0:0:0): Medium not present (probe0:ata2:0:0:0): Unretryable error acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 cd1 at ata3 bus 0 target 0 lun 0 cd1: Removable CD-ROM SCSI-0 device cd1: 3.300MB/s transfers cd1: Attempt to query device size failed: NOT READY, Medium not present - tray c losed SMP: AP CPU #1 Launched! cd0 at ata2 bus 0 target 0 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: 3.300MB/s transfers cd0: Attempt to query device size failed: NOT READY, Medium not present Trying to mount root from zfs:zgm0/root Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x0 fault code = supervisor read data, page not present instruction pointer = 0x8:0xffffffff80da14fd stack pointer = 0x10:0xffffff800001efd0 frame pointer = 0x10:0xffffff800001f020 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 = 1 (swapper) trap number = 12 panic: page fault cpuid = 0 GEOM_MIRROR: Device gm0: rebuilding provider ad4 stopped. Uptime: 8s Cannot dump. No dump device defined. Automatic reboot in 15 seconds - press a key on the console to abort ===== From owner-freebsd-stable@FreeBSD.ORG Thu Jul 16 19:11: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 2CF721065672 for ; Thu, 16 Jul 2009 19:11:30 +0000 (UTC) (envelope-from oberman@es.net) Received: from mailgw.es.net (mail2.es.net [IPv6:2001:400:107:1::2]) by mx1.freebsd.org (Postfix) with ESMTP id 14CD58FC24 for ; Thu, 16 Jul 2009 19:11:30 +0000 (UTC) (envelope-from oberman@es.net) Received: from ptavv.es.net (ptavv.es.net [IPv6:2001:400:910::29]) by mailgw.es.net (8.14.3/8.14.3) with ESMTP id n6GJBTgs005211 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 16 Jul 2009 12:11:29 -0700 Received: from ptavv.es.net (ptavv.es.net [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 13B041CC0D; Thu, 16 Jul 2009 12:11:29 -0700 (PDT) To: John Marshall In-reply-to: Your message of "Thu, 09 Jul 2009 12:11:19 +1000." <20090709021119.GA26896@rwpc12.mby.riverwillow.net.au> Date: Thu, 16 Jul 2009 12:11:29 -0700 From: "Kevin Oberman" Message-Id: <20090716191129.13B041CC0D@ptavv.es.net> X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2009-07-16_09:2009-07-03, 2009-07-16, 2009-07-16 signatures=0 Cc: freebsd-stable@freebsd.org 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, 16 Jul 2009 19:11:30 -0000 > Date: Thu, 9 Jul 2009 12:11:19 +1000 > From: John Marshall > Sender: owner-freebsd-stable@freebsd.org > > 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. > > -- > John Marshall John, Both of these problems have been reported and Doug is working on a fix for mergemaster to deal with the case where a new file is added to /etc but a file of the same named already exists. I also reported the issue with LOCAL and a fix for this is also in the pipe. When 8.0 is released, I'm pretty sure that ntp.conf will look a bit different from what you see and it won't overwrite the existing file (at least without asking). -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 From owner-freebsd-stable@FreeBSD.ORG Thu Jul 16 19:16:29 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 AD059106564A for ; Thu, 16 Jul 2009 19:16:29 +0000 (UTC) (envelope-from oberman@es.net) Received: from mailgw.es.net (mail3.es.net [IPv6:2001:400:4c01::2]) by mx1.freebsd.org (Postfix) with ESMTP id 84A768FC0C for ; Thu, 16 Jul 2009 19:16:29 +0000 (UTC) (envelope-from oberman@es.net) Received: from ptavv.es.net (ptavv.es.net [IPv6:2001:400:910::29]) by mailgw.es.net (8.14.3/8.14.3) with ESMTP id n6GJGOeD004216 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 16 Jul 2009 12:16:29 -0700 Received: from ptavv.es.net (ptavv.es.net [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 50BFB1CC0D for ; Thu, 16 Jul 2009 12:16:24 -0700 (PDT) To: stable@freebsd.org Date: Thu, 16 Jul 2009 12:16:24 -0700 From: "Kevin Oberman" Message-Id: <20090716191624.50BFB1CC0D@ptavv.es.net> X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2009-07-16_09:2009-07-03, 2009-07-16, 2009-07-16 signatures=0 Cc: Subject: Posts regarding 8.0-beta 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, 16 Jul 2009 19:16:29 -0000 Just a reminder...there is no 8-stable as of today nor is there a RELENG_8 branch in CVS. Posts regarding 8.0 should go to current@. The folks who are most likely able to help with 8.0 problems are more likely to see it there and, if you are watching current@, you may see that the issue you are reporting has already been discussed. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 From owner-freebsd-stable@FreeBSD.ORG Thu Jul 16 19:48: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 AF3AD1065696 for ; Thu, 16 Jul 2009 19:48:33 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by mx1.freebsd.org (Postfix) with ESMTP id 7D5268FC0C for ; Thu, 16 Jul 2009 19:48:33 +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 CE84D3B32DC; Thu, 16 Jul 2009 15:48:32 -0400 (EDT) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute1.internal (MEProxy); Thu, 16 Jul 2009 15:48:32 -0400 X-Sasl-enc: ODo3St1GFP9H6zVJYbDpMz5WhR10xx7MiNuR2yJRXZbd 1247773712 Received: from [192.168.123.18] (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id 1C52C20CA; Thu, 16 Jul 2009 15:48:32 -0400 (EDT) Message-ID: <4A5F840D.4050408@incunabulum.net> Date: Thu, 16 Jul 2009 20:48:29 +0100 From: Bruce Simpson User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Sagara Wijetunga References: <20090713120732.31803.qmail@us1.tomahawkonline.net> In-Reply-To: <20090713120732.31803.qmail@us1.tomahawkonline.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: bishop@rr.iij4u.or.jp, nsouch@freebsd.org, freebsd-stable@freebsd.org, n_hibma@freebsd.org Subject: Re: FreeBSD 7.2 USB stack info needed 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, 16 Jul 2009 19:48:34 -0000 Sagara Wijetunga wrote: > > 1. Could I know which exact program print above line on /dev/devctl ? The kernel... > 2. I want to print another line with "daN" as the device-name, where N > is 0 to 9, with minimum vendor and product ids once the allocated > device-name is known for USB Mass Storage devices. Your additional > ideas/feedback/help is most welcomed. rwatson had a patch for something like this somewhere. cheers BMS From owner-freebsd-stable@FreeBSD.ORG Fri Jul 17 04:08:23 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 49FCB1065675 for ; Fri, 17 Jul 2009 04:08:23 +0000 (UTC) (envelope-from matheusber@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.246]) by mx1.freebsd.org (Postfix) with ESMTP id F1CC38FC2B for ; Fri, 17 Jul 2009 04:08:22 +0000 (UTC) (envelope-from matheusber@gmail.com) Received: by an-out-0708.google.com with SMTP id d14so298776and.13 for ; Thu, 16 Jul 2009 21:08:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:received:date:from:to :subject:message-id:x-mailer:mime-version:content-type :content-transfer-encoding; bh=0ZqdYuAHJj3b8JJl9TyOltqTS5QKectpqovZADGspEA=; b=FZDQe+uepWG4mZRUglwvIqIE9dpX4EzKaNi0Rk56iyAYm2J5BaL7iySbLzJ+oUtyFE 8xfmjKcfHfoJI3ibYx0L0Tkm/S6fz8+N4HW2VoZaVY+fLtwqwS7TcCCG8QePOAQT4UuJ rVHJfhQ0wN7VeltSwOUlRn3VEaC8ercbuOeOg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:date:from:to:subject:message-id:x-mailer:mime-version :content-type:content-transfer-encoding; b=Iqs21w8pOnwwavH3OY5Kl26yoTezXYNhfxTa6KzpzXO7XZinT+M58tfG/G6CD30k+Z hpL29sOemGipP+XwOsP+FaguzEcGVc9xQJwC7gwgsUQE0C5lSCb5Vl8YIFp9TTWk2LMt 8lexlzHiECEN/zri/zsJ+VNJOYQ1bBtO6naoU= Received: by 10.100.5.12 with SMTP id 12mr913522ane.69.1247803702223; Thu, 16 Jul 2009 21:08:22 -0700 (PDT) Received: from cygnus.homeunix.com ([189.71.108.65]) by mx.google.com with ESMTPS id d22sm1266593and.5.2009.07.16.21.08.20 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 16 Jul 2009 21:08:20 -0700 (PDT) Sender: Nenhum_de_Nos Received: from arroway (arroway.apartnet [10.1.1.80]) by cygnus.homeunix.com (Postfix) with SMTP id 36218B871E for ; Fri, 17 Jul 2009 01:08:14 -0300 (BRT) Date: Fri, 17 Jul 2009 01:08:13 -0300 From: Nenhum_de_Nos To: freebsd-stable@freebsd.org Message-Id: <20090717010813.03477b27.matheus@eternamente.info> X-Mailer: Sylpheed 2.4.8 (GTK+ 2.12.9; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: gstripe 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: Fri, 17 Jul 2009 04:08:23 -0000 hail, I have a problem with gstripe on today stable. I created this stripe using a bit more old stable (two weeks tops) and it can't be read on old stable (from 30/12/2008). So I recreated in 8-BETA1 and I could mount and see files. When I tried again on 30/12/2008 stable and todays, on PII machine (i386): [root@xxx ~]# gstripe status Name Status Components stripe/stripe0 UP ad4s2 ad6s2 [root@xxx ~]# gstripe list Geom name: stripe0 State: UP Status: Total=2, Online=2 Type: MANUAL Stripesize: 4096 ID: 2302026851 Providers: 1. Name: stripe/stripe0 Mediasize: 1242615693312 (1.1T) Sectorsize: 512 Mode: r0w0e0 Consumers: 1. Name: ad4s2 Mediasize: 621307846656 (579G) Sectorsize: 512 Mode: r0w0e0 Number: 0 2. Name: ad6s2 Mediasize: 621307846656 (579G) Sectorsize: 512 Mode: r0w0e0 Number: 1 [root@xxx ~]# ls /dev/stripe/ stripe0 stripe0c [root@xxx ~]# mount /dev/stripe/stripe0 /null mount: /dev/stripe/stripe0 : Invalid argument on 8-BETA1 it works, but can't create stripe on it and use on this stable box though. the stripe already has files ! so anything weird could make me loose my data ... the 8-BETA1 is amd64 and core 2 quad cpu. any hints ? 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 Fri Jul 17 06:57: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 43F43106564A for ; Fri, 17 Jul 2009 06:57:41 +0000 (UTC) (envelope-from graham@menhennitt.com.au) Received: from mail09.syd.optusnet.com.au (mail09.syd.optusnet.com.au [211.29.132.190]) by mx1.freebsd.org (Postfix) with ESMTP id BBF0F8FC18 for ; Fri, 17 Jul 2009 06:57:40 +0000 (UTC) (envelope-from graham@menhennitt.com.au) Received: from maxwell.mencon.com.au (c220-239-199-115.chirn1.vic.optusnet.com.au [220.239.199.115]) by mail09.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id n6H6vbhU029437 for ; Fri, 17 Jul 2009 16:57:38 +1000 Received: from [203.2.73.73] (chief.mencon.com.au [203.2.73.73]) by maxwell.mencon.com.au (Postfix) with ESMTP id CF54A5C58 for ; Fri, 17 Jul 2009 16:57:37 +1000 (EST) Message-ID: <4A6020E1.9010600@menhennitt.com.au> Date: Fri, 17 Jul 2009 16:57:37 +1000 From: Graham Menhennitt User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: FreeBSD stable Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: ath0: stuck beacon; resetting (bmiss count 4) 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, 17 Jul 2009 06:57:41 -0000 I'me getting the message "ath0: stuck beacon; resetting (bmiss count 4)" logged to syslog every so often. I have a Soekris net5501 with a Wistron CM9 mini-PCI wireless card. I'm running FreeBSD 7.2-stable and "dmesg | grep ath0" gives: ath0: mem 0xa0010000-0xa001ffff irq 15 at device 17.0 on pci0 ath0: [ITHREAD] ath0: WARNING: using obsoleted if_watchdog interface ath0: Ethernet address: 00:0b:6b:36:99:93 ath0: mac 5.9 phy 4.3 radio 3.6 ath0: ath_chan_set: unable to reset channel 6 (2437 Mhz, flags 0x490 hal flags 0x150), hal status 12 I've seen Sam Leffler's reply to a previous question about the same log message at http://lists.freebsd.org/pipermail/freebsd-current/2009-March/004196.html. Looking at the source code of if_ath.c in stable: if (sc->sc_bmisscount > 3) /* NB: 3 is a guess */ taskqueue_enqueue(sc->sc_tq, &sc->sc_bstucktask);\ Now, in head the 3 has been made a variable but it doesn't seem to be able to be tuned in any reasonable way. I've tied increasing it to 20 and it doesn't seem to have any obvious bad effects. So, my questions: - is 3 really a good guess? - can it be increased safely? - what sort of values should I try? - are there any consequences of increasing it? - could it be made a sysctl tunable? Thanks for any help, Graham From owner-freebsd-stable@FreeBSD.ORG Fri Jul 17 10: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 C6E451065672 for ; Fri, 17 Jul 2009 10:20:29 +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 840048FC1B for ; Fri, 17 Jul 2009 10:20:29 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1MRkYD-0000Fk-NW for freebsd-stable@freebsd.org; Fri, 17 Jul 2009 10:20:25 +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 ; Fri, 17 Jul 2009 10:20:25 +0000 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 17 Jul 2009 10:20:25 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: Ivan Voras Date: Fri, 17 Jul 2009 12:20:03 +0200 Lines: 32 Message-ID: References: <20090717010813.03477b27.matheus@eternamente.info> 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: <20090717010813.03477b27.matheus@eternamente.info> Sender: news Subject: Re: gstripe 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: Fri, 17 Jul 2009 10:20:30 -0000 Nenhum_de_Nos wrote: > hail, > > I have a problem with gstripe on today stable. I created this stripe using a bit more old stable (two weeks tops) and it can't be read on old stable (from 30/12/2008). So I recreated in 8-BETA1 and I could mount and see files. When I tried again on 30/12/2008 stable and todays, on PII machine (i386): So your problem is that: a) you created a gstripe array on a recent STABLE (two weeks ago) and it was fine b) you tried to use it with an old STABLE (30.12.2008.) and it didn't work c) you tried to use it with today's STABLE and it didn't work d) it works with 8-BETA1 ? The only thing that comes to my mind is that during your tests you have changed the stripe size, making the file system data unusable (and unmountable). > [root@xxx ~]# gstripe status > Name Status Components > stripe/stripe0 UP ad4s2 > ad6s2 > mount: /dev/stripe/stripe0 : Invalid argument > > on 8-BETA1 it works, but can't create stripe on it and use on this stable box though. the stripe already has files ! so anything weird could make me loose my data ... Are you saying you won't use 8-BETA1 because you fear there may be problems with it? If so, you shouldn't worry so much - 8-CURRENT is very stable. From owner-freebsd-stable@FreeBSD.ORG Fri Jul 17 12:07: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 E77761065673 for ; Fri, 17 Jul 2009 12:07:55 +0000 (UTC) (envelope-from matheusber@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 959128FC2E for ; Fri, 17 Jul 2009 12:07:54 +0000 (UTC) (envelope-from matheusber@gmail.com) Received: by yxe11 with SMTP id 11so1331428yxe.3 for ; Fri, 17 Jul 2009 05:07:54 -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=4ZQwU56Zijuu4WSj+wc2Kav32teDd0RMITyyW/rlcDo=; b=qN6kkbK+SFygLMkA3FZpamiYmQc3COWnHL2aFEk8v8b9E3gP77FbjZz6lDiNgk4g86 8k0b8lygZ5+XeMGN5vcnPevGLr87P3wiLm8t8b0Ny7hZWax1jPp0Pe8t2NivfKnx+Tja sK1gTKaTjQxASYjtn4PzT2IJc6wyU6n8B4aPo= 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=uCANF5AXwFc0PvUSZ46ZWNOPKee4tKg66Ys6NHwtAxX0AiSHJcIBKwkMH4TmA23xyL H0rKYbV78PQvAXOfX1LbE1VXeqh4zjQRVzKIpvDsyIsjx4/gBLYXUHkvbDDyigKvdPi1 VbJz8+GFGG7VFK3ZIOPnXRtFDOljlj4QEQBQA= Received: by 10.90.101.17 with SMTP id y17mr805174agb.80.1247832474344; Fri, 17 Jul 2009 05:07:54 -0700 (PDT) Received: from cygnus.homeunix.com ([189.71.108.65]) by mx.google.com with ESMTPS id 36sm28391agc.20.2009.07.17.05.07.52 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 17 Jul 2009 05:07:53 -0700 (PDT) Sender: Nenhum_de_Nos Received: by cygnus.homeunix.com (Postfix, from userid 80) id 03E69B8722; Fri, 17 Jul 2009 09:07:48 -0300 (BRT) Received: from 189.92.202.0 (SquirrelMail authenticated user matheus) by cygnus.homeunix.com with HTTP; Fri, 17 Jul 2009 09:07:48 -0300 (BRT) Message-ID: <0a394f735684111014877d2b39783693.squirrel@cygnus.homeunix.com> In-Reply-To: References: <20090717010813.03477b27.matheus@eternamente.info> Date: Fri, 17 Jul 2009 09:07:48 -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: gstripe 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: Fri, 17 Jul 2009 12:07:56 -0000 On Fri, July 17, 2009 07:20, Ivan Voras wrote: > Nenhum_de_Nos wrote: >> hail, >> >> I have a problem with gstripe on today stable. I created this stripe >> using a bit more old stable (two weeks tops) and it can't be read on old >> stable (from 30/12/2008). So I recreated in 8-BETA1 and I could mount >> and see files. When I tried again on 30/12/2008 stable and todays, on >> PII machine (i386): > > So your problem is that: > > a) you created a gstripe array on a recent STABLE (two weeks ago) and it > was fine > b) you tried to use it with an old STABLE (30.12.2008.) and it didn't work > c) you tried to use it with today's STABLE and it didn't work > d) it works with 8-BETA1 > ? its quite this. the stripe just vanishes when I try to see it in any stable. and if I create in stable, a reboot makes it go way :( > The only thing that comes to my mind is that during your tests you have > changed the stripe size, making the file system data unusable (and > unmountable). > >> [root@xxx ~]# gstripe status >> Name Status Components >> stripe/stripe0 UP ad4s2 >> ad6s2 > >> mount: /dev/stripe/stripe0 : Invalid argument >> >> on 8-BETA1 it works, but can't create stripe on it and use on this >> stable box though. the stripe already has files ! so anything weird >> could make me loose my data ... > > Are you saying you won't use 8-BETA1 because you fear there may be > problems with it? If so, you shouldn't worry so much - 8-CURRENT is very > stable. I know it is. 8-CURRENT is great really (I use it in other places). my main concern is that this is a server with mail/dns/dhcp/apache/some other services I forgot and changing to 8-BETA may need to recompile all things, and need time I don't have right now ... can I just update and use all software compiled for 7.1-PRERELEASE ? 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 Fri Jul 17 13:42: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 4C8391065670 for ; Fri, 17 Jul 2009 13:42:39 +0000 (UTC) (envelope-from pluknet@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 9B9C98FC08 for ; Fri, 17 Jul 2009 13:42:38 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: by fxm24 with SMTP id 24so666586fxm.43 for ; Fri, 17 Jul 2009 06:42:37 -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=SV7fX7ATa8Lt0T1ng8SImTfKVx8VI/5VimugLVn4y9s=; b=tudyzTyK67qg50RG5mx4COKM2iinVtYKYOd9y+6u8Iiwbe8m8o5J6Rtbk631yV7QYC X0QRWMzVGb89F2F/3sA1tSk07GRPI8aXfEeS8lSij7M6tPAevc8Ofi7hVJlGv/4IvM9X f3JYZ1CNrBmZktBO8hJu4BWF7oJ//obxZ1skM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=bUYJ2DE4QGsCb3ItPdhFo6E56oMtyFgGB/qZ+UBJO1v6XvEMZGL3aESvWUlAnTpyD1 7HNXzfZHizumFUCVd3g7UhQhpOwE5bEU4PyHJXmI7SeJnMGF0WvRMhoCOMR2MfwlOUJJ GiksstrG8PBWYOGC7FWMWiwd79zf9lefsNb4E= MIME-Version: 1.0 Received: by 10.204.71.210 with SMTP id i18mr951610bkj.48.1247838157334; Fri, 17 Jul 2009 06:42:37 -0700 (PDT) Date: Fri, 17 Jul 2009 17:42:37 +0400 Message-ID: From: pluknet To: freebsd-stable , Xin LI Content-Type: multipart/mixed; boundary=001636c5b7c61aea3b046ee6f67b Cc: Subject: [rfc] MFC 7.x bce(4) to 6.x 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, 17 Jul 2009 13:42:39 -0000 --001636c5b7c61aea3b046ee6f67b Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi. Is there a planned MFC of bce(4) changes between 6.4 and 7.2 to RELENG_6? We need this at work in order to support Broadcom BCM5709 in (post-)6.4. I could able to backport recent 7.x changes to 6.4. I'm not sure about MSI and/or TSO4 stability here since there are changes since 6.x in bce(4). What I did is checkout RELENG_7 bce sources plus small hackish patch to compile this on 6.x. # uname -a FreeBSD 6.4-RELEASE FreeBSD 6.4-RELEASE #0: Fri Jul 17 21:08:32 MSD 2009 root@:/usr/obj/usr/src/sys/SMP i386 It seems to work good. I have a network access to the box now. after kldload if_bce: bce0: mem 0x92000000-0x93ffffff irq 28 at device 0.0 on pci11 miibus0: on bce0 ukphy0: on miibus0 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FD X, auto bce0: Ethernet address: 00:1a:64:e5:13:ec bce0: link state changed to DOWN bce0: ASIC (0x57092003); Rev (C0); Bus (PCIe x2, 5Gbps); B/C (0x04060705); Flags ( MFW MSI ) bce1: mem 0x94000000-0x95ffffff irq 40 at device 0.1 on pci11 miibus1: on bce1 ukphy1: on miibus1 ukphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FD X, auto bce1: Ethernet address: 00:1a:64:e5:13:ee bce1: ASIC (0x bce1: link state changed to DOWN 57092003); Rev (C0); Bus (PCIe x2, 5Gbps); B/C (0x04060705); Flags( MFW MSI ) bce0: link state changed to UP bce0: link state changed to DOWN bce0: link state changed to UP The patch (against if_bce.c,v 1.34.2.9): --- /home/pluknet/cvs-7/src/sys/dev/bce/if_bce.c Wed Jun 3 13:42:55 2009 +++ bce/if_bce.c Fri Jul 17 15:26:00 2009 @@ -54,6 +54,12 @@ __FBSDID("$FreeBSD: src/sys/dev/bce/if_b #include #include +/* From sys/mbuf.h */ +#define CSUM_TSO 0x0020 /* will do TSO */ + +/* From net/if.h */ +#define IFCAP_TSO4 0x00100 /* can do TCP Segmentation Offload */ + /****************************************************************************/ /* BCE Debug Options */ /****************************************************************************/ @@ -1059,7 +1065,7 @@ bce_attach(device_t dev) /* Hookup IRQ last. */ rc = bus_setup_intr(dev, sc->bce_res_irq, INTR_TYPE_NET | INTR_MPSAFE, - NULL, bce_intr, sc, &sc->bce_intrhand); + bce_intr, sc, &sc->bce_intrhand); if (rc) { BCE_PRINTF("%s(%d): Failed to setup IRQ!\n", @@ -6391,13 +6397,24 @@ bce_tx_encap(struct bce_softc *sc, struc bus_dma_segment_t segs[BCE_MAX_SEGMENTS]; bus_dmamap_t map; struct tx_bd *txbd = NULL; +#if __FreeBSD_version <= 700022 + struct m_tag *mtag; +#endif struct mbuf *m0; +#if __FreeBSD_version > 700022 struct ether_vlan_header *eh; struct ip *ip; struct tcphdr *th; - u16 prod, chain_prod, etype, mss = 0, vlan_tag = 0, flags = 0; +#endif + u16 prod, chain_prod, +#if __FreeBSD_version > 700022 + etype, +#endif + mss = 0, vlan_tag = 0, flags = 0; u32 prod_bseq; +#if __FreeBSD_version > 700022 int hdr_len = 0, e_hlen = 0, ip_hlen = 0, tcp_hlen = 0, ip_len = 0; +#endif #ifdef BCE_DEBUG u16 debug_prod; @@ -6418,6 +6435,7 @@ bce_tx_encap(struct bce_softc *sc, struc flags |= TX_BD_FLAGS_IP_CKSUM; if (m0->m_pkthdr.csum_flags & (CSUM_TCP | CSUM_UDP)) flags |= TX_BD_FLAGS_TCP_UDP_CKSUM; +#if __FreeBSD_version > 700022 if (m0->m_pkthdr.csum_flags & CSUM_TSO) { /* For TSO the controller needs two pieces of info, */ /* the MSS and the IP+TCP options length. */ @@ -6481,14 +6499,23 @@ bce_tx_encap(struct bce_softc *sc, struc bce_tx_encap_skip_tso: DBRUN(sc->requested_tso_frames++); } +#endif } /* Transfer any VLAN tags to the bd. */ +#if __FreeBSD_version > 700022 if (m0->m_flags & M_VLANTAG) { flags |= TX_BD_FLAGS_VLAN_TAG; vlan_tag = m0->m_pkthdr.ether_vtag; } +#else + mtag = VLAN_OUTPUT_TAG(sc->bce_ifp, m0); + if (mtag != NULL) { + flags |= TX_BD_FLAGS_VLAN_TAG; + vlan_tag = VLAN_TAG_VALUE(mtag); + } +#endif /* Map the mbuf into DMAable memory. */ prod = sc->tx_prod; chain_prod = TX_CHAIN_IDX(prod); -- wbr, pluknet --001636c5b7c61aea3b046ee6f67b Content-Type: application/octet-stream; name="bce.7-down-to-6.patch" Content-Disposition: attachment; filename="bce.7-down-to-6.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_fx8ylxw00 ZGlmZiAtdXJwTiAvaG9tZS9wbHVrbmV0L2N2cy03L3NyYy9zeXMvZGV2L2JjZS9pZl9iY2UuYyBi Y2UvaWZfYmNlLmMKLS0tIC9ob21lL3BsdWtuZXQvY3ZzLTcvc3JjL3N5cy9kZXYvYmNlL2lmX2Jj ZS5jCVdlZCBKdW4gIDMgMTM6NDI6NTUgMjAwOQorKysgYmNlL2lmX2JjZS5jCUZyaSBKdWwgMTcg MTU6MjY6MDAgMjAwOQpAQCAtNTQsNiArNTQsMTIgQEAgX19GQlNESUQoIiRGcmVlQlNEOiBzcmMv c3lzL2Rldi9iY2UvaWZfYgogI2luY2x1ZGUgPGRldi9iY2UvaWZfYmNlcmVnLmg+CiAjaW5jbHVk ZSA8ZGV2L2JjZS9pZl9iY2Vmdy5oPgogCisvKiBGcm9tIHN5cy9tYnVmLmggKi8KKyNkZWZpbmUg Q1NVTV9UU08JMHgwMDIwCQkvKiB3aWxsIGRvIFRTTyAqLworCisvKiBGcm9tIG5ldC9pZi5oICov CisjZGVmaW5lIElGQ0FQX1RTTzQJMHgwMDEwMAkJLyogY2FuIGRvIFRDUCBTZWdtZW50YXRpb24g T2ZmbG9hZCAqLworCiAvKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKi8KIC8qIEJDRSBEZWJ1ZyBPcHRpb25z ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAq LwogLyoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKiovCkBAIC0xMDU5LDcgKzEwNjUsNyBAQCBiY2VfYXR0YWNo KGRldmljZV90IGRldikKIAogCS8qIEhvb2t1cCBJUlEgbGFzdC4gKi8KIAlyYyA9IGJ1c19zZXR1 cF9pbnRyKGRldiwgc2MtPmJjZV9yZXNfaXJxLCBJTlRSX1RZUEVfTkVUIHwgSU5UUl9NUFNBRkUs Ci0JCU5VTEwsIGJjZV9pbnRyLCBzYywgJnNjLT5iY2VfaW50cmhhbmQpOworCQliY2VfaW50ciwg c2MsICZzYy0+YmNlX2ludHJoYW5kKTsKIAogCWlmIChyYykgewogCQlCQ0VfUFJJTlRGKCIlcygl ZCk6IEZhaWxlZCB0byBzZXR1cCBJUlEhXG4iLApAQCAtNjM5MSwxMyArNjM5NywyNCBAQCBiY2Vf dHhfZW5jYXAoc3RydWN0IGJjZV9zb2Z0YyAqc2MsIHN0cnVjCiAJYnVzX2RtYV9zZWdtZW50X3Qg c2Vnc1tCQ0VfTUFYX1NFR01FTlRTXTsKIAlidXNfZG1hbWFwX3QgbWFwOwogCXN0cnVjdCB0eF9i ZCAqdHhiZCA9IE5VTEw7CisjaWYgX19GcmVlQlNEX3ZlcnNpb24gPD0gNzAwMDIyCisJc3RydWN0 IG1fdGFnICptdGFnOworI2VuZGlmCiAJc3RydWN0IG1idWYgKm0wOworI2lmIF9fRnJlZUJTRF92 ZXJzaW9uID4gNzAwMDIyCiAJc3RydWN0IGV0aGVyX3ZsYW5faGVhZGVyICplaDsKIAlzdHJ1Y3Qg aXAgKmlwOwogCXN0cnVjdCB0Y3BoZHIgKnRoOwotCXUxNiBwcm9kLCBjaGFpbl9wcm9kLCBldHlw ZSwgbXNzID0gMCwgdmxhbl90YWcgPSAwLCBmbGFncyA9IDA7CisjZW5kaWYKKwl1MTYgcHJvZCwg Y2hhaW5fcHJvZCwKKyNpZiBfX0ZyZWVCU0RfdmVyc2lvbiA+IDcwMDAyMgorCWV0eXBlLAorI2Vu ZGlmCisJbXNzID0gMCwgdmxhbl90YWcgPSAwLCBmbGFncyA9IDA7CiAJdTMyIHByb2RfYnNlcTsK KyNpZiBfX0ZyZWVCU0RfdmVyc2lvbiA+IDcwMDAyMgogCWludCBoZHJfbGVuID0gMCwgZV9obGVu ID0gMCwgaXBfaGxlbiA9IDAsIHRjcF9obGVuID0gMCwgaXBfbGVuID0gMDsKKyNlbmRpZgogCiAj aWZkZWYgQkNFX0RFQlVHCiAJdTE2IGRlYnVnX3Byb2Q7CkBAIC02NDE4LDYgKzY0MzUsNyBAQCBi Y2VfdHhfZW5jYXAoc3RydWN0IGJjZV9zb2Z0YyAqc2MsIHN0cnVjCiAJCQlmbGFncyB8PSBUWF9C RF9GTEFHU19JUF9DS1NVTTsKIAkJaWYgKG0wLT5tX3BrdGhkci5jc3VtX2ZsYWdzICYgKENTVU1f VENQIHwgQ1NVTV9VRFApKQogCQkJZmxhZ3MgfD0gVFhfQkRfRkxBR1NfVENQX1VEUF9DS1NVTTsK KyNpZiBfX0ZyZWVCU0RfdmVyc2lvbiA+IDcwMDAyMgogCQlpZiAobTAtPm1fcGt0aGRyLmNzdW1f ZmxhZ3MgJiBDU1VNX1RTTykgewogCQkJLyogRm9yIFRTTyB0aGUgY29udHJvbGxlciBuZWVkcyB0 d28gcGllY2VzIG9mIGluZm8sICovCiAJCQkvKiB0aGUgTVNTIGFuZCB0aGUgSVArVENQIG9wdGlv bnMgbGVuZ3RoLiAgICAgICAgICAgKi8KQEAgLTY0ODEsMTQgKzY0OTksMjMgQEAgYmNlX3R4X2Vu Y2FwKHN0cnVjdCBiY2Vfc29mdGMgKnNjLCBzdHJ1YwogYmNlX3R4X2VuY2FwX3NraXBfdHNvOgog CQkJREJSVU4oc2MtPnJlcXVlc3RlZF90c29fZnJhbWVzKyspOwogCQl9CisjZW5kaWYKIAl9CiAK IAkvKiBUcmFuc2ZlciBhbnkgVkxBTiB0YWdzIHRvIHRoZSBiZC4gKi8KKyNpZiBfX0ZyZWVCU0Rf dmVyc2lvbiA+IDcwMDAyMgogCWlmIChtMC0+bV9mbGFncyAmIE1fVkxBTlRBRykgewogCQlmbGFn cyB8PSBUWF9CRF9GTEFHU19WTEFOX1RBRzsKIAkJdmxhbl90YWcgPSBtMC0+bV9wa3RoZHIuZXRo ZXJfdnRhZzsKIAl9CiAKKyNlbHNlCisgICAgICAgIG10YWcgPSBWTEFOX09VVFBVVF9UQUcoc2Mt PmJjZV9pZnAsIG0wKTsKKyAgICAgICAgaWYgKG10YWcgIT0gTlVMTCkgeworICAgICAgICAgICAg ICAgIGZsYWdzIHw9IFRYX0JEX0ZMQUdTX1ZMQU5fVEFHOworICAgICAgICAgICAgICAgIHZsYW5f dGFnID0gVkxBTl9UQUdfVkFMVUUobXRhZyk7CisgICAgICAgIH0KKyNlbmRpZgogCS8qIE1hcCB0 aGUgbWJ1ZiBpbnRvIERNQWFibGUgbWVtb3J5LiAqLwogCXByb2QgPSBzYy0+dHhfcHJvZDsKIAlj aGFpbl9wcm9kID0gVFhfQ0hBSU5fSURYKHByb2QpOwo= --001636c5b7c61aea3b046ee6f67b-- From owner-freebsd-stable@FreeBSD.ORG Fri Jul 17 13:46: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 3E9A5106566B for ; Fri, 17 Jul 2009 13:46:17 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-bw0-f208.google.com (mail-bw0-f208.google.com [209.85.218.208]) by mx1.freebsd.org (Postfix) with ESMTP id A94E88FC12 for ; Fri, 17 Jul 2009 13:46:16 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: by bwz4 with SMTP id 4so659417bwz.43 for ; Fri, 17 Jul 2009 06:46:15 -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 :content-transfer-encoding; bh=Cmk+bfeJT5bBClANV+mR7FR3FhAetrF7aw6CPjHukvA=; b=QDaQqcuA3mG5VLdwMS5y4yjgGWtZrlMmuapzVZdkzi+afv+ftxp6nkY/pQckXC+7Wu WJq5kovssiRmie1VZQrBvbRXPFEvE92Wq+ED+8i5sgKAv768DO0b8MKllWY6F95EM2fj czFQNnA7OQ69a3LrYm7aJ/otvkluFs6nVE800= 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:content-transfer-encoding; b=sbzy6LD9n1Cd+3JyE+C3Hk+FOb9P5n0fW3L4eaGjHto2oOKaRNg/D+4IeGikSrp5E8 5/A70dbHuhfaSFz+SakYa8hViyqiJMdI37hq0SO7AH+ugGQzjtkgNwyOMZ3Fv5GWU24u G07hPOamnIpVb8j7hFTVTSh1SfTp8J3nTuViI= MIME-Version: 1.0 Received: by 10.204.50.212 with SMTP id a20mr955355bkg.35.1247838375033; Fri, 17 Jul 2009 06:46:15 -0700 (PDT) In-Reply-To: References: Date: Fri, 17 Jul 2009 17:46:14 +0400 Message-ID: From: pluknet To: freebsd-stable , Xin LI Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Subject: Re: [rfc] MFC 7.x bce(4) to 6.x 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, 17 Jul 2009 13:46:17 -0000 2009/7/17 pluknet : > Hi. > > Is there a planned MFC of bce(4) changes between 6.4 and 7.2 to RELENG_6? > > We need this at work in order to support Broadcom BCM5709 in (post-)6.4. > > I could able to backport recent 7.x changes to 6.4. > I'm not sure about MSI and/or TSO4 stability here since there are > changes since 6.x in bce(4). > What I did is checkout RELENG_7 bce sources plus small hackish patch > to compile this on 6.x. > > # uname -a > FreeBSD =A06.4-RELEASE FreeBSD 6.4-RELEASE #0: Fri Jul 17 21:08:32 MSD > 2009 =A0 =A0 root@:/usr/obj/usr/src/sys/SMP =A0i386 > > It seems to work good. I have a network access to the box now. > > after kldload if_bce: > bce0: mem 0x92000000-0x93= ffffff > irq 28 at device 0.0 on pci11 > miibus0: on bce0 > ukphy0: on miibus0 > ukphy0: =A010baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 100= 0baseT-FD > X, auto > bce0: Ethernet address: 00:1a:64:e5:13:ec > bce0: link state changed to DOWN > bce0: ASIC (0x57092003); Rev (C0); Bus (PCIe x2, 5Gbps); B/C (0x04060705)= ; Flags > ( MFW MSI ) > bce1: mem 0x94000000-0x95= ffffff > irq 40 at device 0.1 on pci11 > miibus1: on bce1 > ukphy1: on miibus1 > ukphy1: =A010baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 100= 0baseT-FD > X, auto > bce1: Ethernet address: 00:1a:64:e5:13:ee > bce1: ASIC (0x > bce1: link state changed to DOWN > 57092003); Rev (C0); Bus (PCIe x2, 5Gbps); B/C (0x04060705); Flags( MFW M= SI ) > bce0: link state changed to UP > bce0: link state changed to DOWN > bce0: link state changed to UP Ah, yes. Forgot to show dmesg from 7.2 for comparison: bce0: mem 0x92000000-0x93ffffff irq 28 at device 0.0 on pci11 bce0: Reserved 0x2000000 bytes for rid 0x10 type 3 at 0x92000000 bce0: attempting to allocate 1 MSI vectors (16 supported) bce0: using IRQ 256 for MSI miibus0: on bce0 bce0: bpf attached bce0: Ethernet address: 00:1a:64:e5:13:ec bce0: [MPSAFE] bce0: [ITHREAD] bce0: ASIC (0x57092003); Rev (C0); Bus (PCIe x2, 5Gbps); B/C (0x04060705); Flags( MFW MSI ) bce1: mem 0x94000000-0x95ffffff irq 40 at device 0.1 on pci11 bce1: Reserved 0x2000000 bytes for rid 0x10 type 3 at 0x94000000 bce1: attempting to allocate 1 MSI vectors (16 supported) bce1: using IRQ 257 for MSI miibus1: on bce1 bce1: bpf attached bce1: Ethernet address: 00:1a:64:e5:13:ee bce1: [MPSAFE] bce1: [ITHREAD] bce1: ASIC (0x57092003); Rev (C0); Bus (PCIe x2, 5Gbps); B/C (0x04060705); Flags( MFW MSI ) bce0: link state changed to UP > > The patch (against if_bce.c,v 1.34.2.9): > > --- /home/pluknet/cvs-7/src/sys/dev/bce/if_bce.c =A0 =A0 =A0 =A0Wed Jun = =A03 13:42:55 2009 > +++ bce/if_bce.c =A0 =A0 =A0 =A0Fri Jul 17 15:26:00 2009 > @@ -54,6 +54,12 @@ __FBSDID("$FreeBSD: src/sys/dev/bce/if_b > =A0#include > =A0#include > > +/* From sys/mbuf.h */ > +#define CSUM_TSO =A0 =A0 =A0 0x0020 =A0 =A0 =A0 =A0 =A0/* will do TSO */ > + > +/* From net/if.h */ > +#define IFCAP_TSO4 =A0 =A0 0x00100 =A0 =A0 =A0 =A0 /* can do TCP Segment= ation Offload */ > + > =A0/*********************************************************************= *******/ > =A0/* BCE Debug Options =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0*/ > =A0/*********************************************************************= *******/ > @@ -1059,7 +1065,7 @@ bce_attach(device_t dev) > > =A0 =A0 =A0 =A0/* Hookup IRQ last. */ > =A0 =A0 =A0 =A0rc =3D bus_setup_intr(dev, sc->bce_res_irq, INTR_TYPE_NET = | INTR_MPSAFE, > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 NULL, bce_intr, sc, &sc->bce_intrhand); > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 bce_intr, sc, &sc->bce_intrhand); > > =A0 =A0 =A0 =A0if (rc) { > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0BCE_PRINTF("%s(%d): Failed to setup IRQ!\n= ", > @@ -6391,13 +6397,24 @@ bce_tx_encap(struct bce_softc *sc, struc > =A0 =A0 =A0 =A0bus_dma_segment_t segs[BCE_MAX_SEGMENTS]; > =A0 =A0 =A0 =A0bus_dmamap_t map; > =A0 =A0 =A0 =A0struct tx_bd *txbd =3D NULL; > +#if __FreeBSD_version <=3D 700022 > + =A0 =A0 =A0 struct m_tag *mtag; > +#endif > =A0 =A0 =A0 =A0struct mbuf *m0; > +#if __FreeBSD_version > 700022 > =A0 =A0 =A0 =A0struct ether_vlan_header *eh; > =A0 =A0 =A0 =A0struct ip *ip; > =A0 =A0 =A0 =A0struct tcphdr *th; > - =A0 =A0 =A0 u16 prod, chain_prod, etype, mss =3D 0, vlan_tag =3D 0, fla= gs =3D 0; > +#endif > + =A0 =A0 =A0 u16 prod, chain_prod, > +#if __FreeBSD_version > 700022 > + =A0 =A0 =A0 etype, > +#endif > + =A0 =A0 =A0 mss =3D 0, vlan_tag =3D 0, flags =3D 0; > =A0 =A0 =A0 =A0u32 prod_bseq; > +#if __FreeBSD_version > 700022 > =A0 =A0 =A0 =A0int hdr_len =3D 0, e_hlen =3D 0, ip_hlen =3D 0, tcp_hlen = =3D 0, ip_len =3D 0; > +#endif > > =A0#ifdef BCE_DEBUG > =A0 =A0 =A0 =A0u16 debug_prod; > @@ -6418,6 +6435,7 @@ bce_tx_encap(struct bce_softc *sc, struc > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0flags |=3D TX_BD_FLAGS_IP_= CKSUM; > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (m0->m_pkthdr.csum_flags & (CSUM_TCP | = CSUM_UDP)) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0flags |=3D TX_BD_FLAGS_TCP= _UDP_CKSUM; > +#if __FreeBSD_version > 700022 > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (m0->m_pkthdr.csum_flags & CSUM_TSO) { > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/* For TSO the controller = needs two pieces of info, */ > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/* the MSS and the IP+TCP = options length. =A0 =A0 =A0 =A0 =A0 */ > @@ -6481,14 +6499,23 @@ bce_tx_encap(struct bce_softc *sc, struc > =A0bce_tx_encap_skip_tso: > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0DBRUN(sc->requested_tso_fr= ames++); > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0} > +#endif > =A0 =A0 =A0 =A0} > > =A0 =A0 =A0 =A0/* Transfer any VLAN tags to the bd. */ > +#if __FreeBSD_version > 700022 > =A0 =A0 =A0 =A0if (m0->m_flags & M_VLANTAG) { > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0flags |=3D TX_BD_FLAGS_VLAN_TAG; > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0vlan_tag =3D m0->m_pkthdr.ether_vtag; > =A0 =A0 =A0 =A0} > > +#else > + =A0 =A0 =A0 =A0mtag =3D VLAN_OUTPUT_TAG(sc->bce_ifp, m0); > + =A0 =A0 =A0 =A0if (mtag !=3D NULL) { > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0flags |=3D TX_BD_FLAGS_VLAN_TAG; > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0vlan_tag =3D VLAN_TAG_VALUE(mtag); > + =A0 =A0 =A0 =A0} > +#endif > =A0 =A0 =A0 =A0/* Map the mbuf into DMAable memory. */ > =A0 =A0 =A0 =A0prod =3D sc->tx_prod; > =A0 =A0 =A0 =A0chain_prod =3D TX_CHAIN_IDX(prod); > > -- > wbr, > pluknet > --=20 wbr, pluknet From owner-freebsd-stable@FreeBSD.ORG Fri Jul 17 20:09: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 395A91065670 for ; Fri, 17 Jul 2009 20:09:08 +0000 (UTC) (envelope-from news@citylink.dinoex.sub.org) Received: from uucp.dinoex.sub.de (uucp.dinoex.sub.de [194.45.71.2]) by mx1.freebsd.org (Postfix) with ESMTP id AB3EC8FC12 for ; Fri, 17 Jul 2009 20:09:07 +0000 (UTC) (envelope-from news@citylink.dinoex.sub.org) Received: from uucp.dinoex.sub.de (uucp@uucp.dinoex.sub.de [194.45.71.2] (may be forged)) by uucp.dinoex.sub.de (8.14.3/8.14.2) with ESMTP id n6HJcAXX085623 for ; Fri, 17 Jul 2009 21:38:10 +0200 (CEST) (envelope-from news@citylink.dinoex.sub.org) X-MDaemon-Deliver-To: Received: from citylink.dinoex.sub.org (uucp@localhost) by uucp.dinoex.sub.de (8.14.3/8.14.2/Submit) with UUCP id n6HJcAtF085622 for freebsd-stable@FreeBSD.ORG; Fri, 17 Jul 2009 21:38:10 +0200 (CEST) (envelope-from news@citylink.dinoex.sub.org) Received: from gate.oper.dinoex.org (gate-e [192.168.98.2]) by citylink.dinoex.sub.de (8.14.3/8.14.2) with ESMTP id n6HJYYlp003318 for ; Fri, 17 Jul 2009 21:34:34 +0200 (CEST) (envelope-from news@gate.oper.dinoex.org) Received: from gate.oper.dinoex.org (gate-e [192.168.98.2]) by gate.oper.dinoex.org (8.14.3/8.14.3) with ESMTP id n6HJY2Bd003205 for ; Fri, 17 Jul 2009 21:34:03 +0200 (CEST) (envelope-from news@gate.oper.dinoex.org) Received: (from news@localhost) by gate.oper.dinoex.org (8.14.3/8.14.3/Submit) id n6HJY28D003193 for freebsd-stable@FreeBSD.ORG; Fri, 17 Jul 2009 21:34:02 +0200 (CEST) (envelope-from news) From: pmc@citylink.dinoex.sub.org (Peter Much) Message-ID: Date: Fri, 17 Jul 2009 19:12:06 GMT Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=ISO-8859-1 Mime-Version: 1.0 Organization: dread of the bookshelf X-Newsreader: trn 4.0-test76 (Apr 2, 2001) Sender: To: freebsd-stable@FreeBSD.ORG X-Milter: Spamilter (Reciever: uucp.dinoex.sub.de; Sender-ip: 194.45.71.2; Sender-helo: uucp.dinoex.sub.de; ) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (uucp.dinoex.sub.de [194.45.71.2]); Fri, 17 Jul 2009 21:38:11 +0200 (CEST) Cc: Subject: Can an app crash from a single TCP packet lost in transmission? 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, 17 Jul 2009 20:09:08 -0000 The first thing I noticed was that my nameserver had gone. I searched for the reason and found: >Jul 15 04:04:52 edge kernel: swap_pager_getswapspace(3): failed < ... hundreds more of these ... > >Jul 15 04:05:07 edge kernel: pid 47113 (named), uid 53, was killed: out of swap space That didn't make sense - the machine has enough swapspace. But since this did repeat every other night, I started logging ps output minutely. And so I found a postgres database backup going weird: 03:23 70 78433 78432 0 96 0 8220 4196 - R ?? 0:22.84 pg_dump -b < ... > 03:49 70 78433 78432 0 96 0 8220 4024 - R ?? 17:06.61 pg_dump -b 03:50 70 78433 78432 0 96 0 8220 4024 - R ?? 17:46.15 pg_dump -b 03:51 70 78433 78432 0 96 0 8220 4024 - R ?? 18:26.69 pg_dump -b 03:52 70 78433 78432 0 47 0 139292 57888 select S ?? 18:37.65 pg_dump -b 03:53 70 78433 78432 0 48 0 139292 57828 select S ?? 18:40.36 pg_dump -b 03:54 70 78433 78432 0 -20 0 401436 69092 swread DL ?? 18:42.49 pg_dump -b 03:55 70 78433 78432 0 -20 0 401436 63232 swread DL ?? 18:43.99 pg_dump -b That process starts with 8MB memory, and runs so for half an hour, then suddenly between 03:51 and 03:52 memory usage explodes. And in that night it did not run out of swap space - instead it gave an error message: >pg_dump: Error message from server: lost synchronization with server: > got message type "0", length 154143043 >pg_dump: The command was: COPY public.file (fileid, fileindex, jobid, > pathid, filenameid, markid, lstat, md5) TO stdout; But that database backup is at that time quite in the middle of dumping a db table containing lots of small records - there is no reason why a 154 MB "message" should be transferred between server and client while copying records of ~60 Bytes each. One other thing did happen between 03:51 and 03:52 - the DSL internet connection did disconnect/reconnect and obtained a new IP adress. Afterwards, a script does flush and reload an ipfw table() with the new local adresses - and during this process one(!) packet of the database session was dropped. I could verify that relation: every night when there were memory problems, few packets from the database backup were lost during the firewall reconfigure - in nights when no packets were lost, there were no memory problems. I will now change the firewall handling to get rid of that packet loss, but also, I need some refresh on how TCP works: I thought TCP would not be disturbed by a lost packet, but would automatically resend that packet until ACK received; and I thought this would happen below the application, so practically the application CANNOT go weird from a lost packet... Is there any reason why this would not be true on a localhost connection? rgds, PMc From owner-freebsd-stable@FreeBSD.ORG Fri Jul 17 20:49: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 28AF41065670 for ; Fri, 17 Jul 2009 20:49:11 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from asmtpout022.mac.com (asmtpout022.mac.com [17.148.16.97]) by mx1.freebsd.org (Postfix) with ESMTP id 158448FC18 for ; Fri, 17 Jul 2009 20:49:11 +0000 (UTC) (envelope-from cswiger@mac.com) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Received: from cswiger1.apple.com ([17.227.140.124]) by asmtp022.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KMY001UU1TYRM40@asmtp022.mac.com> for freebsd-stable@FreeBSD.ORG; Fri, 17 Jul 2009 13:49:10 -0700 (PDT) Message-id: <7090AD67-2082-4AFA-B130-C20A7DC970FA@mac.com> From: Chuck Swiger To: Peter Much In-reply-to: Date: Fri, 17 Jul 2009 13:49:10 -0700 References: X-Mailer: Apple Mail (2.935.3) Cc: freebsd-stable@FreeBSD.ORG Subject: Re: Can an app crash from a single TCP packet lost in transmission? 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, 17 Jul 2009 20:49:11 -0000 On Jul 17, 2009, at 12:12 PM, Peter Much wrote: [ ... ] > One other thing did happen between 03:51 and 03:52 - the DSL > internet connection did disconnect/reconnect and obtained a new > IP adress. Afterwards, a script does flush and reload an ipfw table() > with the new local adresses - and during this process one(!) packet > of the database session was dropped. Well, there you go: having your IP change is certainly going to break existing network connections; I don't believe there is anything which is going to move the existing connection state in a NAT translation layer or whatever over to the new IP. Presumably you can obtain a static IP and avoid such issues. -- -Chuck From owner-freebsd-stable@FreeBSD.ORG Fri Jul 17 23:13: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 2F570106566C for ; Fri, 17 Jul 2009 23:13:35 +0000 (UTC) (envelope-from news@citylink.dinoex.sub.org) Received: from uucp.dinoex.sub.de (uucp.dinoex.sub.de [194.45.71.2]) by mx1.freebsd.org (Postfix) with ESMTP id 98C708FC12 for ; Fri, 17 Jul 2009 23:13:34 +0000 (UTC) (envelope-from news@citylink.dinoex.sub.org) Received: from uucp.dinoex.sub.de (uucp@uucp.dinoex.sub.de [194.45.71.2] (may be forged)) by uucp.dinoex.sub.de (8.14.3/8.14.2) with ESMTP id n6HNCqI8047862 for ; Sat, 18 Jul 2009 01:12:52 +0200 (CEST) (envelope-from news@citylink.dinoex.sub.org) X-MDaemon-Deliver-To: Received: from citylink.dinoex.sub.org (uucp@localhost) by uucp.dinoex.sub.de (8.14.3/8.14.2/Submit) with UUCP id n6HNCq6r047861 for freebsd-stable@FreeBSD.ORG; Sat, 18 Jul 2009 01:12:52 +0200 (CEST) (envelope-from news@citylink.dinoex.sub.org) Received: from gate.oper.dinoex.org (gate-e [192.168.98.2]) by citylink.dinoex.sub.de (8.14.3/8.14.2) with ESMTP id n6HME68D026386 for ; Sat, 18 Jul 2009 00:14:06 +0200 (CEST) (envelope-from news@gate.oper.dinoex.org) Received: from gate.oper.dinoex.org (gate-e [192.168.98.2]) by gate.oper.dinoex.org (8.14.3/8.14.3) with ESMTP id n6HME2t3026307 for ; Sat, 18 Jul 2009 00:14:02 +0200 (CEST) (envelope-from news@gate.oper.dinoex.org) Received: (from news@localhost) by gate.oper.dinoex.org (8.14.3/8.14.3/Submit) id n6HME2rg026300 for freebsd-stable@FreeBSD.ORG; Sat, 18 Jul 2009 00:14:02 +0200 (CEST) (envelope-from news) From: pmc@citylink.dinoex.sub.org (Peter Much) Message-ID: Date: Fri, 17 Jul 2009 21:59:21 GMT Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=ISO-8859-1 References: <7090AD67-2082-4AFA-B130-C20A7DC970FA@mac.com> Mime-Version: 1.0 Organization: dread of the bookshelf X-Newsreader: trn 4.0-test76 (Apr 2, 2001) Sender: To: freebsd-stable@FreeBSD.ORG X-Milter: Spamilter (Reciever: uucp.dinoex.sub.de; Sender-ip: 194.45.71.2; Sender-helo: uucp.dinoex.sub.de; ) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (uucp.dinoex.sub.de [194.45.71.2]); Sat, 18 Jul 2009 01:12:53 +0200 (CEST) Cc: Subject: Re: Can an app crash from a single TCP packet lost in transmission? 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, 17 Jul 2009 23:13:35 -0000 aka Chuck Swiger schrieb mit Datum Fri, 17 Jul 2009 13:49:10 -0700 in m2n.fbsd.stable: |On Jul 17, 2009, at 12:12 PM, Peter Much wrote: |[ ... ] |> One other thing did happen between 03:51 and 03:52 - the DSL |> internet connection did disconnect/reconnect and obtained a new |> IP adress. Afterwards, a script does flush and reload an ipfw table() |> with the new local adresses - and during this process one(!) packet |> of the database session was dropped. | |Well, there you go: having your IP change is certainly going to break |existing network connections; Uh, is that so? Maybe I wasnt clear enough: the failing database connection is a LOCALHOST-LOCALHOST connection - and it uses the (fixed) IP of one of the LAN interfaces, not the dynamic internet IP on the tun/PPP interface. Changing the IP on one interface while using another interface is, to all my knowledge, normal business. And even IF there were problem with that, then I would expect the connection to timeout and fail, I would NOT expect a memory leak to appear and drive the system out of swap within seconds. !I don't believe there is anything which |is going to move the existing connection state in a NAT translation |layer or whatever over to the new IP. Nay, that doesnt work. |Presumably you can obtain a |static IP and avoid such issues. I have a static internet IP on the machine, also, for HTTPS. I have lots of interfaces there. And I did run some tests in the meantime. The problem is in the PostgresQL library; it doesnt depend on a changed IP; - I only need to steal one packet out of the transmission, then the database client will grow to VSZ=1500GB and bigger. That's perfect reproduceable. The postgresQL is 8.2, rather old by now - but I really wonder that noone else did get into this during all the time. rgds, PMc From owner-freebsd-stable@FreeBSD.ORG Sat Jul 18 00:01: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 EEBB11065672 for ; Sat, 18 Jul 2009 00:01:21 +0000 (UTC) (envelope-from matheusber@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 9A4338FC0A for ; Sat, 18 Jul 2009 00:01:21 +0000 (UTC) (envelope-from matheusber@gmail.com) Received: by yxe11 with SMTP id 11so1991263yxe.3 for ; Fri, 17 Jul 2009 17:01:21 -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=hVw8QtPavLqCt1sEyLklQOy6FlL+oy9bQ7jyow7Hflk=; b=WMM7/oRmIs6qQNCjFWHfjp8/eNlbF8P4G2BfSye/mF2+DUGechw0nfT4dRfz/akp73 5DFNLg++vnhBhaA0ZaxN8cdJXjOlwx8Gatlg3y58UxY7iBHzBGg1/Ge2qw6W/csddf03 PIVWgDgPaJCbI3/TBMcY/kGHDVdrp3EFvYIs4= 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=hMnAdqZMcISqIJUHkHZ28+ih3BwQxWu8OADHSlJldLkY/48UMFIIGq8s2wrC7GUe2t eqprQTlKiV+06R20LSqSuRt4bM2kdUZippZwafzZYwcwOOXBUtOn8lndkEZ0idv3tH2n wiAK0Ntq9uOROFGHL4puJPOQrBbozLRGUGDOA= Received: by 10.90.119.15 with SMTP id r15mr1315844agc.98.1247875281111; Fri, 17 Jul 2009 17:01:21 -0700 (PDT) Received: from cygnus.homeunix.com ([189.71.108.65]) by mx.google.com with ESMTPS id 10sm560283agb.36.2009.07.17.17.01.19 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 17 Jul 2009 17:01:20 -0700 (PDT) Sender: Nenhum_de_Nos Received: by cygnus.homeunix.com (Postfix, from userid 80) id 458BFB80C2; Fri, 17 Jul 2009 21:01:15 -0300 (BRT) Received: from 10.1.1.71 (SquirrelMail authenticated user matheus) by 10.1.1.10 with HTTP; Fri, 17 Jul 2009 21:01:15 -0300 (BRT) Message-ID: <2fd30e75fbd3e231117ab9f2459f896b.squirrel@10.1.1.10> In-Reply-To: <0a394f735684111014877d2b39783693.squirrel@cygnus.homeunix.com> References: <20090717010813.03477b27.matheus@eternamente.info> <0a394f735684111014877d2b39783693.squirrel@cygnus.homeunix.com> Date: Fri, 17 Jul 2009 21:01:15 -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: gstripe 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: Sat, 18 Jul 2009 00:01:22 -0000 On Fri, July 17, 2009 09:07, Nenhum_de_Nos wrote: > > On Fri, July 17, 2009 07:20, Ivan Voras wrote: >> Nenhum_de_Nos wrote: >>> hail, >>> >>> I have a problem with gstripe on today stable. I created this stripe >>> using a bit more old stable (two weeks tops) and it can't be read on >>> old >>> stable (from 30/12/2008). So I recreated in 8-BETA1 and I could mount >>> and see files. When I tried again on 30/12/2008 stable and todays, on >>> PII machine (i386): >> >> So your problem is that: >> >> a) you created a gstripe array on a recent STABLE (two weeks ago) and it >> was fine >> b) you tried to use it with an old STABLE (30.12.2008.) and it didn't >> work >> c) you tried to use it with today's STABLE and it didn't work >> d) it works with 8-BETA1 >> ? > > its quite this. the stripe just vanishes when I try to see it in any > stable. and if I create in stable, a reboot makes it go way :( > >> The only thing that comes to my mind is that during your tests you have >> changed the stripe size, making the file system data unusable (and >> unmountable). >> >>> [root@xxx ~]# gstripe status >>> Name Status Components >>> stripe/stripe0 UP ad4s2 >>> ad6s2 >> >>> mount: /dev/stripe/stripe0 : Invalid argument >>> >>> on 8-BETA1 it works, but can't create stripe on it and use on this >>> stable box though. the stripe already has files ! so anything weird >>> could make me loose my data ... >> >> Are you saying you won't use 8-BETA1 because you fear there may be >> problems with it? If so, you shouldn't worry so much - 8-CURRENT is very >> stable. > > I know it is. 8-CURRENT is great really (I use it in other places). my > main concern is that this is a server with mail/dns/dhcp/apache/some other > services I forgot and changing to 8-BETA may need to recompile all things, > and need time I don't have right now ... > > can I just update and use all software compiled for 7.1-PRERELEASE ? > > thanks, > > matheus thins here just got weird. I did updated to 8-BETA2. same problem though. so I just thought it was problem when I create a stripe in amd64 machine and try to use it on i386. I then put the drives in the amd64 machine, and it did worked fine, after another gstripe create command. so I rebooted the amd64 machine to see if after reboot the stripe would be there. guess what ... nothing there ... I used gmirror and gstripe for about an year, no problem. couple of months ago I had a problem and had to change the pc (dead one). so all changed, using sil3114 sata pci card now and PII 300 MHz. now the disks behave like this. if anyone has any leads, I'm moving data from the disks now ... can test though. 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 Sat Jul 18 03:29: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 0C38710656C0; Sat, 18 Jul 2009 03:29:36 +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 C8E138FC12; Sat, 18 Jul 2009 03:29:35 +0000 (UTC) (envelope-from kensmith@cse.Buffalo.EDU) Received: from [192.168.1.101] (cpe-74-77-179-53.buffalo.res.rr.com [74.77.179.53]) (authenticated bits=0) by phoebe.cse.buffalo.edu (8.14.1/8.13.7) with ESMTP id n6I3TRiD041362 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 17 Jul 2009 23:29:35 -0400 (EDT) (envelope-from kensmith@cse.buffalo.edu) From: Ken Smith To: freebsd-current@freebsd.org, freebsd-stable Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-RuqrIPjOVPF9Nk6DFIZv" Date: Fri, 17 Jul 2009 23:29:19 -0400 Message-Id: <1247887759.14210.18.camel@neo.cse.buffalo.edu> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 FreeBSD GNOME Team Port X-DCC-Buffalo.EDU-Metrics: phoebe.cse.buffalo.edu 1029; Body=0 Fuz1=0 Fuz2=0 Cc: Subject: 8.0-BETA2 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: Sat, 18 Jul 2009 03:29:36 -0000 --=-RuqrIPjOVPF9Nk6DFIZv Content-Type: text/plain Content-Transfer-Encoding: quoted-printable The second of the BETA builds for the FreeBSD-8.0 release cycle is now available. There are still a few things being finished up so a couple more moderately large commits are coming but we seem to be making good progress. The target date for the last of the things still being worked on is BETA3. In the meantime we appreciate the feedback we have received from people who have started testing and some of those problems have been fixed as well. As was the case with BETA1, BETA2 is still a little bit "rough around the edges" and we still have various debugging tools enabled that cause the system to perform worse than it will when those debugging tools get disabled. We don't know of any issues that will "eat your data" or anything like that so in that regard it's safe but we don't recommend it for production use quite yet. If you notice problems you can report them through the normal Gnats PR system or on the freebsd-current mailing list. Sorry for not specifying that in the BETA1 announcement. With the X.0 releases I make the announcements of how the release is progressing on both freebsd-current and freebsd-stable because what's being released is "about to become a stable branch" so some people who only read freebsd-stable might be interested. But when it comes to watching for discussions about the release the developer community tends to pay more attention to the freebsd-current mailing list. ISO images for all supported architectures are available on the FTP sites, and a "memory stick" image is available for amd64/i386 architectures. For amd64/i386 architectures the DVD and memstick images include the documentation packages this time but no other packages yet. None of the other images included packages. The memstick image should now work in "fixit" mode (livefs). If you are using csup/cvsup methods to update an older system the branch tag to use is still head ("."). The freebsd-update(8) utility supports binary upgrades of i386 and amd64 systems running earlier FreeBSD releases. Systems running 7.0-RELEASE, 7.1-RELEASE, 7.2-RELEASE, or 8.0-BETA2 can upgrade as follows: =20 # freebsd-update upgrade -r 8.0-BETA2 =20 During this process, FreeBSD Update may ask the user to help by merging som= e configuration files or by confirming that the automatically performed mergi= ng was done correctly. =20 # freebsd-update install =20 The system must be rebooted with the newly installed kernel before continui= ng. =20 # shutdown -r now =20 After rebooting, freebsd-update needs to be run again to install the new userland components: # freebsd-update install =20 At this point, users of systems being upgraded from FreeBSD 7.x will be prompted by freebsd-update to rebuild all third-party applications (e.g., ports installed from the ports tree) due to updates in system libraries. S= ee http://www.daemonology.net/blog/2009-07-11-freebsd-update-to-8.0-beta1.ht= ml for mode details. After updating installed third-party applications (and again, only if freebsd-update printed a message indicating that this was necessary), run freebsd-update again so that it can delete the old (no long= er used) system libraries: # freebsd-update install =20 Finally, reboot into 8.0-BETA2: =20 # shutdown -r now MD5/SHA256 checksums for the image files: MD5 (8.0-BETA2-amd64-bootonly.iso) =3D 7e389124bfa5c216324b12660664a41d MD5 (8.0-BETA2-amd64-disc1.iso) =3D c5a8391ec3eda90e310590c6e9352e43 MD5 (8.0-BETA2-amd64-dvd1.iso) =3D c148d1eac8fbafce3dc26a5186a3c7c6 MD5 (8.0-BETA2-amd64-livefs.iso) =3D 24e2da8a58e8df86a1a72d3fd2aa95a1 MD5 (8.0-BETA2-amd64-memstick.img) =3D 06d466ba9cf5c3a22aee92586fa96d7f MD5 (8.0-BETA2-i386-bootonly.iso) =3D 4279dec2239df09ec7b93e52f96e55bb MD5 (8.0-BETA2-i386-disc1.iso) =3D 16173fee72aa8cdd7d39d8ce3238276c MD5 (8.0-BETA2-i386-dvd1.iso) =3D 3a04d48154c702021e9abac271e9a700 MD5 (8.0-BETA2-i386-livefs.iso) =3D 6ca1813b3ac7cc9abe8f44c9875a50bf MD5 (8.0-BETA2-i386-memstick.img) =3D 5db506264c4b2d60b902d63ebc49a317 MD5 (8.0-BETA2-ia64-bootonly.iso) =3D baac960edebc8a10131db8debe961168 MD5 (8.0-BETA2-ia64-disc1.iso) =3D 77ecfb115e4dbc5eaaad6d42e8e93bae MD5 (8.0-BETA2-ia64-disc2.iso) =3D 77fe3b112b74858abc9586e5ac0c8355 MD5 (8.0-BETA2-ia64-disc3.iso) =3D ddc874a6e67d290a6af96221a025e90a MD5 (8.0-BETA2-ia64-dvd1.iso) =3D ac85730dfabea642cf91471954f541dd MD5 (8.0-BETA2-ia64-livefs.iso) =3D 5806ddd76a778bcde03e3c92f0005173 MD5 (8.0-BETA2-pc98-bootonly.iso) =3D b0c5c41251242483c2048b77dadc7a76 MD5 (8.0-BETA2-pc98-disc1.iso) =3D 49a0974e0abd5e63618ea99634313bbe MD5 (8.0-BETA2-pc98-livefs.iso) =3D dddfdb2e0f6ffd0497f9ce9a00812c24 MD5 (8.0-BETA2-powerpc-bootonly.iso) =3D 2bd42f619809aedbd3ac6a5b1beeec6d MD5 (8.0-BETA2-powerpc-disc1.iso) =3D 329c5d3082fe3479545018092d3a0850 MD5 (8.0-BETA2-powerpc-disc2.iso) =3D ba7d5337e9c1cc9c356372a7d7f4015d MD5 (8.0-BETA2-powerpc-disc3.iso) =3D 46567950c6e6d969ec584637641e042c MD5 (8.0-BETA2-sparc64-bootonly.iso) =3D 47bba49d0f4ea3c58163db9146c46d6c MD5 (8.0-BETA2-sparc64-disc1.iso) =3D 93af6d6d1164276d83c3e8c67a904422 MD5 (8.0-BETA2-sparc64-dvd1.iso) =3D 269ebf61580485eb8fc3abb063b5a309 SHA256 (8.0-BETA2-amd64-bootonly.iso) =3D c11389094ee73389eb3e3ad22e165f158= cce0003431a88eb27ae253fd76b70a8 SHA256 (8.0-BETA2-amd64-disc1.iso) =3D 49121108535986690eebc7c894a56bdd1e4b= 5afc8ed1470afb0ebc79debb2c1e SHA256 (8.0-BETA2-amd64-dvd1.iso) =3D d3f36481fd022bad67cc020eeb19f261330c2= 79592a0062c43804fdc32a0c08d SHA256 (8.0-BETA2-amd64-livefs.iso) =3D 35d02c1b6bdcc54721f955f3beb68c6e67b= 610554a2e28c28391041cdab75ddf SHA256 (8.0-BETA2-amd64-memstick.img) =3D 66eb336e4de03cc68f1929db233d3edb3= 7fc05b814cde68fe8f618340b91cb66 SHA256 (8.0-BETA2-i386-bootonly.iso) =3D 904b8aa5380ea81604ea81c9c88b3bb3ad= e744a45cececa512fc78b07c1bbacd SHA256 (8.0-BETA2-i386-disc1.iso) =3D 5699c6e4f8a7084dc6d6fe835c1c40cc7b016= 14091b057df07d72537e8e33ef4 SHA256 (8.0-BETA2-i386-dvd1.iso) =3D f5cc663850f6e20ece9e7e2c6b9503b8f9599a= cfdd20e5a19ffad4541d33fc7f SHA256 (8.0-BETA2-i386-livefs.iso) =3D f2a50f00ba9f30c564fd7be320c7bc1111af= 2b192a47e036cd97fa72092435e3 SHA256 (8.0-BETA2-i386-memstick.img) =3D 6d66fee850102d966b00123590f139fb38= e6d33d818ff8c6ce58c4ae3853e209 SHA256 (8.0-BETA2-ia64-bootonly.iso) =3D 69da5d8fb3d17bade7b596f5bd81bacfb1= c178bf184be462661786e99ac3f80d SHA256 (8.0-BETA2-ia64-disc1.iso) =3D c59b03585d364ad0b305eb3d71c168c0d1e0b= 100270802ed22efdc80de59f792 SHA256 (8.0-BETA2-ia64-disc2.iso) =3D 7f398777025c970f265446d18bb7f571a2078= e147843bd1345827164a040b9f3 SHA256 (8.0-BETA2-ia64-disc3.iso) =3D cf4a0bb280892cc09af10f138aa3a8df70453= 80e63946427d582c8217ed3231c SHA256 (8.0-BETA2-ia64-dvd1.iso) =3D e1379d207a0659ab4397c1c84e7193e1efe0d0= 4db96b21c712b1bdc9e86079ad SHA256 (8.0-BETA2-ia64-livefs.iso) =3D 3881e3eaba4988c23a3cf19d04c2e055b861= 288d938ad8c4352dacfd6a97c35a SHA256 (8.0-BETA2-pc98-bootonly.iso) =3D fc2f234ed68e0a3c1a254771485b012bf1= 24009cb1a928e67204a2f1aad63519 SHA256 (8.0-BETA2-pc98-disc1.iso) =3D 7b5450fc0ae04ec80788a91b8d6caf449c22e= d2e373ebf89263d2affebe74cf8 SHA256 (8.0-BETA2-pc98-livefs.iso) =3D cf9c823eb58fee48421c16900c270b97fefb= 61a1f90501791e88b74102862763 SHA256 (8.0-BETA2-powerpc-bootonly.iso) =3D 99d50bc3c35b36b41fe0871d3505d70= 2c75a8025178dbc33603b77c9886d23af SHA256 (8.0-BETA2-powerpc-disc1.iso) =3D 4afdc4e8be4ea178ce791b5c3e1881538c= c118b336c5337ce15d811e245a926d SHA256 (8.0-BETA2-powerpc-disc2.iso) =3D a7c21ffb213e0b73e24e5d9a317599445a= c8c69cb37efa554768692622b176cc SHA256 (8.0-BETA2-powerpc-disc3.iso) =3D 6213f6a5e19a4146d6e20bffb36d6e1a7d= 3aa192db83f14f6ec599fa38472a6f SHA256 (8.0-BETA2-sparc64-bootonly.iso) =3D 998fcc77ec2675e7eb7d826ae87897b= ead56189cc79ede57b214d3357d56499d SHA256 (8.0-BETA2-sparc64-disc1.iso) =3D 22d61fc13dd544af390de56940e1a4c041= abe18249cdc110ae02613d1f5d761a SHA256 (8.0-BETA2-sparc64-dvd1.iso) =3D 2478e8c3508e8b8f8b9f0ed6a9c67c04693= 75cb2ba224114583fe14da6fb237e --=20 Ken Smith - From there to here, from here to | kensmith@cse.buffalo.edu there, funny things are everywhere. | - Theodore Geisel | --=-RuqrIPjOVPF9Nk6DFIZv 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) iEYEABECAAYFAkphQYEACgkQ/G14VSmup/bMdQCfVHWK9cq3bRXS6ktCyGQfbq3k 98sAn19XBKWukpRE9Mqaim0Idi8BBDol =ug2o -----END PGP SIGNATURE----- --=-RuqrIPjOVPF9Nk6DFIZv-- From owner-freebsd-stable@FreeBSD.ORG Sat Jul 18 04:13: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 F41C11065673 for ; Sat, 18 Jul 2009 04:13:34 +0000 (UTC) (envelope-from ari@ish.com.au) Received: from fish.ish.com.au (eth5921.nsw.adsl.internode.on.net [59.167.240.32]) by mx1.freebsd.org (Postfix) with ESMTP id B58A68FC1C for ; Sat, 18 Jul 2009 04:13:34 +0000 (UTC) (envelope-from ari@ish.com.au) Received: from [10.29.62.4] (port=56120 helo=Aris-MacBook-Pro.local) by fish.ish.com.au with esmtpa (Exim 4.69) (envelope-from ) id 1MS2CI-0002mc-0u; Sat, 18 Jul 2009 15:10:58 +1000 Message-ID: <4A614957.4060703@ish.com.au> Date: Sat, 18 Jul 2009 14:02:31 +1000 From: Aristedes Maniatis User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.1pre) Gecko/20090714 Shredder/3.0b3pre MIME-Version: 1.0 To: Ken Smith References: <1247887759.14210.18.camel@neo.cse.buffalo.edu> In-Reply-To: <1247887759.14210.18.camel@neo.cse.buffalo.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, freebsd-stable Subject: Re: 8.0-BETA2 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: Sat, 18 Jul 2009 04:13:35 -0000 On 18/07/09 1:29 PM, Ken Smith wrote: > # freebsd-update upgrade -r 8.0-BETA2 > > During this process, FreeBSD Update may ask the user to help by merging some > configuration files or by confirming that the automatically performed merging > was done correctly. > > # freebsd-update install > > The system must be rebooted with the newly installed kernel before continuing. > > # shutdown -r now FreeBSD 7 users who have /usr /var, etc on ZFS should not follow these instructions exactly. Rebooting into a new kernel with the old userland ZFS tools will result in the system not being able to mount the ZFS filesystems and therefore not being able to reboot. [1] Ari Maniatis [1] See my more detailed comment at the bottom here: http://www.daemonology.net/blog/2009-07-11-freebsd-update-to-8.0-beta1.html --------------------------> ish http://www.ish.com.au Level 1, 30 Wilson Street Newtown 2042 Australia phone +61 2 9550 5001 fax +61 2 9550 4001 GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A From owner-freebsd-stable@FreeBSD.ORG Sat Jul 18 07:30: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 0984C106564A; Sat, 18 Jul 2009 07:30:41 +0000 (UTC) (envelope-from bh@izb.knu.ac.kr) Received: from pinus.izb.knu.ac.kr (pinus.izb.knu.ac.kr [IPv6:2001:470:1f05:5f6:3::1]) by mx1.freebsd.org (Postfix) with ESMTP id AF3068FC1E; Sat, 18 Jul 2009 07:30:40 +0000 (UTC) (envelope-from bh@izb.knu.ac.kr) Received: from pinus.izb.knu.ac.kr (localhost [IPv6:::1]) by pinus.izb.knu.ac.kr (Postfix) with ESMTP id B7AD857357; Sat, 18 Jul 2009 16:30:38 +0900 (KST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=izb.knu.ac.kr; h=from:to:cc:subject:references:date:in-reply-to:message-id :mime-version:content-type:content-transfer-encoding; s= soyeomul; bh=7dGPz7a/3NRCxS7Lgd9T5loFYXyWurQ89JCIZeJDUBk=; b=k+U AoSe5OoOcS9Sgt2nxKDfPnWcjvwbOyMJfSOt5nZqkSqGH1op+dh6mZsm3pCZjJq5 L2pI9ZsnT5/54i8Iz6wrKzKJrKrNeP7k1IEyc5iGmTgXL6v5MdP0ACD799BfBWXd fDhIYIvKejtYBN96BwV+1M9PFJFyWRn37DKBc+tc= DomainKey-Signature: a=rsa-sha1; c=simple; d=izb.knu.ac.kr; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type:content-transfer-encoding; q=dns; s=soyeomul; b=RZ 1IIq9og/e4Kzo0K2yr4NwnFiegmYYZIOA3GMk5YDhZHThVBV7mWF7+RcJw79VAPk rUWqVOo7DUUbSHcHCWDCzeD22rfQeWW33DhJuWNb7gTKlCyD2QYOwuw+ubni7QGr 9rrk9Wry3duFYTn/UL2+ZlfaizJM8tnGKHK3cE8CU= Received: from rhodo.izb.knu.ac.kr (rhodo.izb.knu.ac.kr [IPv6:2001:470:1f05:5f8:3::2]) by pinus.izb.knu.ac.kr (Postfix) with ESMTP id 4BF4457355; Sat, 18 Jul 2009 16:30:38 +0900 (KST) Received: from betla.izb.knu.ac.kr (betla.izb.knu.ac.kr [IPv6:2001:470:1f05:5f6:3::a1]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: bh@izb.knu.ac.kr) by rhodo.izb.knu.ac.kr (Postfix) with ESMTP id 2994F1CD6F; Sat, 18 Jul 2009 16:30:34 +0900 (KST) From: Byung-Hee HWANG To: Ken Smith References: <1247887759.14210.18.camel@neo.cse.buffalo.edu> Date: Sat, 18 Jul 2009 16:30:27 +0900 In-Reply-To: <1247887759.14210.18.camel@neo.cse.buffalo.edu> (Ken Smith's message of "Fri, 17 Jul 2009 23:29:19 -0400") Message-ID: <86zlb2o3cc.fsf@betla.izb.knu.ac.kr> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.95 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, freebsd-stable Subject: Re: 8.0-BETA2 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: Sat, 18 Jul 2009 07:30:41 -0000 Ken Smith writes: > The second of the BETA builds for the FreeBSD-8.0 release cycle is now > available. There are still a few things being finished up so a couple > more moderately large commits are coming but we seem to be making good > progress. The target date for the last of the things still being worked > on is BETA3. In the meantime we appreciate the feedback we have > received from people who have started testing and some of those problems > have been fixed as well. [...] For some reason, i'll start to test with BETA3 instead of BETA2. Until that time, good job, Ken! Sincerely, --=20 Byung-Hee HWANG, KNU =E2=88=91 WWW: http://izb.knu.ac.kr/~bh/ "Don't tell me a big movie star like Johnny Fontane has to ask your father = for a favor?" -- Kay Adams, "Chapter 1", page 42 From owner-freebsd-stable@FreeBSD.ORG Sat Jul 18 08:06: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 52364106566B for ; Sat, 18 Jul 2009 08:06:57 +0000 (UTC) (envelope-from njm@njm.me.uk) Received: from smtp003.apm-internet.net (smtp003.apm-internet.net [85.119.248.52]) by mx1.freebsd.org (Postfix) with SMTP id BB3478FC08 for ; Sat, 18 Jul 2009 08:06:56 +0000 (UTC) (envelope-from njm@njm.me.uk) Received: (qmail 47324 invoked from network); 18 Jul 2009 07:40:14 -0000 Received: from unknown (HELO titania.njm.me.uk) (86.148.211.148) by smtp003.apm-internet.net with SMTP; 18 Jul 2009 07:40:14 -0000 Received: from titania.njm.me.uk (localhost [127.0.0.1]) by titania.njm.me.uk (8.14.3/8.14.3) with ESMTP id n6I7eDQc043335; Sat, 18 Jul 2009 08:40:13 +0100 (BST) (envelope-from njm@njm.me.uk) Received: (from njm@localhost) by titania.njm.me.uk (8.14.3/8.14.3/Submit) id n6I7eDGr043334; Sat, 18 Jul 2009 08:40:13 +0100 (BST) (envelope-from njm@njm.me.uk) Date: Sat, 18 Jul 2009 08:40:13 +0100 From: "N.J. Mann" To: Ken Smith Message-ID: <20090718074013.GA42796@titania.njm.me.uk> Mail-Followup-To: Ken Smith , freebsd-current@freebsd.org, freebsd-stable References: <1247887759.14210.18.camel@neo.cse.buffalo.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1247887759.14210.18.camel@neo.cse.buffalo.edu> X-Operating-System: FreeBSD 7.2-STABLE User-Agent: mutt-NJM (2009-07-16) Cc: freebsd-current@freebsd.org, freebsd-stable Subject: Re: 8.0-BETA2 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: Sat, 18 Jul 2009 08:06:58 -0000 In message <1247887759.14210.18.camel@neo.cse.buffalo.edu>, Ken Smith (kensmith@cse.Buffalo.EDU) wrote: > > The second of the BETA builds for the FreeBSD-8.0 release cycle is now > available. There are still a few things being finished up so a couple > more moderately large commits are coming but we seem to be making good > progress. The target date for the last of the things still being worked > on is BETA3. In the meantime we appreciate the feedback we have > received from people who have started testing and some of those problems > have been fixed as well. > > As was the case with BETA1, BETA2 is still a little bit "rough around > the edges" and we still have various debugging tools enabled that cause > the system to perform worse than it will when those debugging tools get > disabled. We don't know of any issues that will "eat your data" or > anything like that so in that regard it's safe but we don't recommend it > for production use quite yet. If you notice problems you can report > them through the normal Gnats PR system or on the freebsd-current > mailing list. Sorry for not specifying that in the BETA1 announcement. > With the X.0 releases I make the announcements of how the release is > progressing on both freebsd-current and freebsd-stable because what's > being released is "about to become a stable branch" so some people who > only read freebsd-stable might be interested. But when it comes to > watching for discussions about the release the developer community tends > to pay more attention to the freebsd-current mailing list. > > ISO images for all supported architectures are available on the FTP > sites, and a "memory stick" image is available for amd64/i386 > architectures. For amd64/i386 architectures the DVD and memstick images > include the documentation packages this time but no other packages yet. > None of the other images included packages. The memstick image should > now work in "fixit" mode (livefs). > > If you are using csup/cvsup methods to update an older system the branch > tag to use is still head ("."). > > The freebsd-update(8) utility supports binary upgrades of i386 and amd64 > systems running earlier FreeBSD releases. Systems running 7.0-RELEASE, > 7.1-RELEASE, 7.2-RELEASE, or 8.0-BETA2 can upgrade as follows: ^^^^^^^^^ I think in this one instance you actually mean 8.0-BETA1. Cheers, Nick. -- From owner-freebsd-stable@FreeBSD.ORG Sat Jul 18 16:22: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 2A6E31065672; Sat, 18 Jul 2009 16:22:33 +0000 (UTC) (envelope-from info@martenvijn.nl) Received: from smtp-vbr16.xs4all.nl (smtp-vbr16.xs4all.nl [194.109.24.36]) by mx1.freebsd.org (Postfix) with ESMTP id 7C53D8FC1C; Sat, 18 Jul 2009 16:22:32 +0000 (UTC) (envelope-from info@martenvijn.nl) Received: from [192.168.178.47] (martenvijn.xs4all.nl [80.101.161.153]) by smtp-vbr16.xs4all.nl (8.13.8/8.13.8) with ESMTP id n6IG4vOU079510; Sat, 18 Jul 2009 18:04:58 +0200 (CEST) (envelope-from info@martenvijn.nl) From: Marten Vijn To: Ken Smith In-Reply-To: <1247887759.14210.18.camel@neo.cse.buffalo.edu> References: <1247887759.14210.18.camel@neo.cse.buffalo.edu> Content-Type: text/plain Date: Sat, 18 Jul 2009 18:05:00 +0200 Message-Id: <1247933100.14935.20.camel@mvn-desktop> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by XS4ALL Virus Scanner Cc: freebsd-current@freebsd.org, freebsd-stable Subject: make distribution Re: 8.0-BETA2 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: Sat, 18 Jul 2009 16:22:33 -0000 cd /usr/src make distribution gives an error data below, kidn regards, Marten make installworld DESTDIR=/usr/tftpboot1/ make installkernel DESTDIR=/usr/tftpboot1/ ok> # make distribution DESTDIR=/usr/tftpboot1/ cd /usr/src/etc; MAKEOBJDIRPREFIX=/usr/obj MACHINE_ARCH=i386 MACHINE=i386 CPUTYPE= GROFF_BIN_PATH=/usr/obj/usr/src/tmp/legacy/usr/bin GROFF_FONT_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/groff_font GROFF_TMAC_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/tmac PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/usr/games:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/usr/obj/usr/src/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin make distribution cd /usr/src/etc; install -o root -g wheel -m 644 auth.conf crontab devd.conf devfs.conf ddb.conf dhclient.conf disktab fbtab ftpusers gettytab group hosts hosts.allow hosts.equiv inetd.conf libalias.conf login.access login.conf mac.conf motd netconfig network.subr networks newsyslog.conf nsswitch.conf phones profile protocols rc rc.bsdextended rc.firewall rc.firewall6 rc.initdiskless rc.sendmail rc.shutdown rc.subr remote rpc services shells sysctl.conf syslog.conf etc.i386/ttys amd.map apmd.conf snmpd.config freebsd-update.conf /usr/src/etc/../usr.bin/locate/locate/locate.rc hosts.lpd printcap /usr/src/etc/../usr.bin/mail/misc/mail.rc /usr/src/etc/../gnu/usr.bin/man/manpath/manpath.config ntp.conf nscd.conf portsnap.conf pf.os csh.cshrc csh.login csh.logout regdomain.xml /usr/tftpboot1//etc; cap_mkdb -l /usr/tftpboot1//etc/login.conf; install -o root -g wheel -m 755 netstart pccard_ether rc.suspend rc.resume /usr/tftpboot1//etc; install -o root -g wheel -m 600 master.passwd nsmb.conf opieaccess /usr/tftpboot1//etc; pwd_mkdb -L -i -p -d /usr/tftpboot1//etc /usr/tftpboot1//etc/master.passwd cd /usr/src/etc/bluetooth; make install install -o root -g wheel -m 600 hcsecd.conf /usr/tftpboot1//etc/bluetooth/hcsecd.conf install -o root -g wheel -m 644 hosts /usr/tftpboot1//etc/bluetooth/hosts install -o root -g wheel -m 444 protocols /usr/tftpboot1//etc/bluetooth cd /usr/src/etc/defaults; make install install -o root -g wheel -m 444 bluetooth.device.conf devfs.rules periodic.conf rc.conf /usr/tftpboot1//etc/defaults cd /usr/src/etc/devd; make install install -o root -g wheel -m 644 asus.conf /usr/tftpboot1//etc/devd cd /usr/src/etc/gss; make install install -o root -g wheel -m 444 mech qop /usr/tftpboot1//etc/gss cd /usr/src/etc/periodic; make install ===> daily (install) install -o root -g wheel -m 755 100.clean-disks 110.clean-tmps 120.clean-preserve 200.backup-passwd 330.news 400.status-disks 404.status-zfs 405.status-ata-raid 406.status-gmirror 407.status-graid3 408.status-gstripe 409.status-gconcat 420.status-network 450.status-security 999.local 310.accounting 470.status-named 300.calendar 130.clean-msgs 480.status-ntpd 140.clean-rwho 430.status-rwho 150.clean-hoststat 210.backup-aliases 440.status-mailq 460.status-mail-rejects 500.queuerun /usr/tftpboot1//etc/periodic/daily ===> security (install) install -o root -g wheel -m 755 100.chksetuid 200.chkmounts 300.chkuid0 400.passwdless 410.logincheck 700.kernelmsg 800.loginfail 900.tcpwrap security.functions 510.ipfdenied 500.ipfwdenied 550.ipfwlimit 520.pfdenied /usr/tftpboot1//etc/periodic/security ===> weekly (install) install -o root -g wheel -m 755 340.noid 999.local 310.locate 320.whatis 330.catman 400.status-pkg /usr/tftpboot1//etc/periodic/weekly ===> monthly (install) install -o root -g wheel -m 755 999.local 200.accounting /usr/tftpboot1//etc/periodic/monthly cd /usr/src/etc/rc.d; make install install -o root -g wheel -m 555 DAEMON FILESYSTEMS LOGIN NETWORKING SERVERS abi accounting addswap adjkerntz amd apm apmd archdep atm1 atm2 atm3 auditd auto_linklocal bgfsck bluetooth bootparams bridge bsnmpd bthidd ccd cleanvar cleartmp cron ddb defaultroute devd devfs dhclient dmesg dumpon encswap fsck ftp-proxy ftpd gbde geli geli2 gssd hcsecd hostapd hostid hostname inetd initrandom ip6addrctl ip6fw ipfilter ipfs ipfw ipmon ipnat ipsec ipxrouted jail kadmind kerberos keyserv kldxref kpasswdd ldconfig local localpkg lockd lpd mixer motd mountcritlocal mountcritremote mountlate mdconfig mdconfig2 mountd moused mroute6d mrouted msgs named natd netif netoptions network_ipv6 newsyslog nfsclient nfscbd nfsd nfsserver nfsuserd nisdomain nsswitch ntpd ntpdate othermta pf pflog pfsync powerd power_profile ppp pppoed pwcheck quota random rarpd resolv rfcomm_pppd_server root route6d routed routing rpcbind rtadvd rwho savecore sdpd securelevel sendmail serial sppp statd swap1 syscons sysctl syslogd timed tmp ugidfw var virecover watchdogd wpa_supplicant ypbind yppasswdd ypserv ypset ypupdated ypxfrd zfs sshd nscd /usr/tftpboot1//etc/rc.d cd /usr/src/etc/../gnu/usr.bin/send-pr; make etc-gnats-freefall install -o root -g wheel -m 0644 /usr/src/gnu/usr.bin/send-pr/categories /usr/tftpboot1//etc/gnats/freefall cd /usr/src/etc/../share/termcap; make etc-termcap ln -fs /usr/share/misc/termcap /usr/tftpboot1//etc/termcap cd /usr/src/etc/../usr.sbin/rmt; make etc-rmt rm -f /usr/tftpboot1//etc/rmt ln -s /usr/sbin/rmt /usr/tftpboot1//etc/rmt cd /usr/src/etc/pam.d; make install install -o root -g wheel -m 444 README /usr/tftpboot1//etc/pam.d/README make: don't know how to make gdm. Stop *** Error code 2 Stop in /usr/src/etc. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. # dmesg 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-BETA2 #7 r195750: Sat Jul 18 12:18:02 UTC 2009 root@:/usr/obj/usr/src/sys/GENERIC WARNING: WITNESS option enabled, expect reduced performance. Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Celeron(R) CPU 440 @ 2.00GHz (1995.01-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x10661 Stepping = 1 Features=0xafebfbff Features2=0xe31d AMD Features=0x20100000 AMD Features2=0x1 TSC: P-state invariant real memory = 536870912 (512 MB) avail memory = 1022689280 (975 MB) ACPI APIC Table: ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, 3f5e0000 (3) failed Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 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 pcib2: at device 0.0 on pci1 pci2: on pcib2 pcib3: at device 0.2 on pci1 pci3: on pcib3 vgapci0: port 0xff00-0xff07 mem 0xfcc00000-0xfccfffff,0xd0000000-0xdfffffff irq 16 at device 2.0 on pci0 agp0: on vgapci0 agp0: detected 7676k stolen memory agp0: aperture size is 256M pcib4: irq 16 at device 28.0 on pci0 pci4: on pcib4 em0: port 0x5f00-0x5f1f mem 0xfdee0000-0xfdefffff irq 16 at device 0.0 on pci4 em0: Using MSI interrupt em0: [FILTER] em0: Ethernet address: 00:10:f3:15:ae:e8 pcib5: irq 17 at device 28.1 on pci0 pci5: on pcib5 em1: port 0xdf00-0xdf1f mem 0xfdce0000-0xfdcfffff irq 17 at device 0.0 on pci5 em1: Using MSI interrupt em1: [FILTER] em1: Ethernet address: 00:10:f3:15:ae:e9 pcib6: irq 18 at device 28.2 on pci0 pci6: on pcib6 em2: port 0xcf00-0xcf1f mem 0xfdae0000-0xfdafffff irq 18 at device 0.0 on pci6 em2: Using MSI interrupt em2: [FILTER] em2: Ethernet address: 00:10:f3:15:ae:ea pcib7: irq 19 at device 28.3 on pci0 pci7: on pcib7 em3: port 0xaf00-0xaf1f mem 0xfd8e0000-0xfd8fffff irq 19 at device 0.0 on pci7 em3: Using MSI interrupt em3: [FILTER] em3: Ethernet address: 00:10:f3:15:ae:eb pcib8: irq 16 at device 28.4 on pci0 pci8: on pcib8 em4: port 0x9f00-0x9f1f mem 0xfd6e0000-0xfd6fffff irq 16 at device 0.0 on pci8 em4: Using MSI interrupt em4: [FILTER] em4: Ethernet address: 00:10:f3:15:ae:ec pcib9: irq 17 at device 28.5 on pci0 pci9: on pcib9 em5: port 0x8f00-0x8f1f mem 0xfd4e0000-0xfd4fffff irq 17 at device 0.0 on pci9 em5: Using MSI interrupt em5: [FILTER] em5: Ethernet address: 00:10:f3:15:ae:ed uhci0: port 0xfe00-0xfe1f irq 23 at device 29.0 on pci0 uhci0: [ITHREAD] uhci0: LegSup = 0x003b usbus0: on uhci0 uhci1: port 0xfd00-0xfd1f irq 20 at device 29.1 on pci0 uhci1: [ITHREAD] uhci1: LegSup = 0x0010 usbus1: on uhci1 ehci0: mem 0xfdfff000-0xfdfff3ff irq 23 at device 29.7 on pci0 ehci0: [ITHREAD] usbus2: EHCI version 1.0 usbus2: on ehci0 pcib10: at device 30.0 on pci0 pci10: on pcib10 em6: port 0xbf00-0xbf3f mem 0xfd0e0000-0xfd0fffff,0xfd0c0000-0xfd0dffff irq 18 at device 14.0 on pci10 em6: [FILTER] em6: Ethernet address: 00:10:f3:15:ae:ee em7: port 0xbe00-0xbe3f mem 0xfd0a0000-0xfd0bffff,0xfd080000-0xfd09ffff irq 17 at device 15.0 on pci10 em7: [FILTER] em7: Ethernet address: 00:10:f3:15:ae:ef isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0xfa00-0xfa07,0xf900-0xf903,0xf800-0xf807,0xf700-0xf703,0xf600-0xf60f,0xf500-0xf50f irq 19 at device 31.2 on pci0 atapci0: [ITHREAD] ata2: on atapci0 ata2: [ITHREAD] ata3: on atapci0 ata3: [ITHREAD] pci0: at device 31.3 (no driver attached) atapci1: port 0xf300-0xf307,0xf200-0xf203,0xf100-0xf107,0xf000-0xf003,0xef00-0xef0f,0xee00-0xee0f irq 19 at device 31.5 on pci0 atapci1: [ITHREAD] ata4: on atapci1 ata4: [ITHREAD] ata5: on atapci1 ata5: [ITHREAD] acpi_tz0: on acpi0 atrtc0: port 0x70-0x73 irq 8 on acpi0 uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 uart0: [FILTER] uart0: console (9600,n,8,1) uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0 uart1: [FILTER] ppc0: port 0x378-0x37f irq 7 on acpi0 ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode ppc0: [ITHREAD] ppbus0: on ppc0 plip0: on ppbus0 plip0: [ITHREAD] lpt0: on ppbus0 lpt0: [ITHREAD] lpt0: Interrupt-driven port ppi0: on ppbus0 cpu0: on acpi0 p4tcc0: on cpu0 pmtimer0 on isa0 orm0: at iomem 0xc0000-0xcafff,0xcc000-0xccfff,0xef000-0xeffff pnpid ORM0000 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 ata0 at port 0x1f0-0x1f7,0x3f6 irq 14 on isa0 ata0: [ITHREAD] ata1 at port 0x170-0x177,0x376 irq 15 on isa0 ata1: [ITHREAD] atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] Timecounter "TSC" frequency 1995012830 Hz quality 800 Timecounters tick every 1.000 msec usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 480Mbps High Speed USB v2.0 ad4: FAILURE - SET_MULTI status=51 error=4 ad4: 1943MB at ata2-master SATA150 ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 ugen2.1: at usbus2 uhub2: on usbus2 ad8: 305245MB at ata4-master SATA300 WARNING: WITNESS option enabled, expect reduced performance. GEOM: ad8s1: geometry does not match label (255h,63s != 16h,63s). Root mount waiting for: usbus2 usbus1 usbus0 uhub0: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered Root mount waiting for: usbus2 Root mount waiting for: usbus2 uhub2: 6 ports with 6 removable, self powered Trying to mount root from ufs:/dev/ad8s1a WARNING: /tmp was not properly dismounted WARNING: /usr was not properly dismounted WARNING: /var was not properly dismounted em0: link state changed to UP lock order reversal: 1st 0xc4caead0 ufs (ufs) @ /usr/src/sys/ufs/ffs/ffs_snapshot.c:423 2nd 0xd85133a0 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:2558 3rd 0xc4a6f594 ufs (ufs) @ /usr/src/sys/ufs/ffs/ffs_snapshot.c:544 KDB: stack backtrace: db_trace_self_wrapper(c0c6bc14,e6cec408,c08bc9d5,c08ad71b,c0c6eac2,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c08ad71b,c0c6eac2,c452be90,c452efb8,e6cec464,...) at kdb_backtrace+0x29 _witness_debugger(c0c6eac2,c4a6f594,c0c617fd,c452efb8,c0c8d400,...) at _witness_debugger+0x25 witness_checkorder(c4a6f594,9,c0c8d400,220,0,...) at witness_checkorder +0x839 __lockmgr_args(c4a6f594,80100,c4a6f5b0,0,0,...) at __lockmgr_args+0x7a7 ffs_lock(e6cec574,c0efbb18,c4ca6764,80100,c4a6f53c,...) at ffs_lock+0x8a VOP_LOCK1_APV(c0d6e900,e6cec574,e6cec594,c0d87380,c4a6f53c,...) at VOP_LOCK1_APV+0xb5 _vn_lock(c4a6f53c,80100,c0c8d400,220,c455b600,...) at _vn_lock+0x5e ffs_snapshot(c49dca10,c49db620,c0c8ed65,15f,c0c7506a,...) at ffs_snapshot+0x150b ffs_mount(c49dca10,0,c0c75557,3d2,0,...) at ffs_mount+0x14aa vfs_donmount(c4ca66c0,211000,c45b5b00,c45b5b00,bfbfecb4,...) at vfs_donmount+0x1012 nmount(c4ca66c0,e6ceccf8,c,c4ca66c0,c0d4fe38,...) at nmount+0x75 syscall(e6cecd38) at syscall+0x2a3 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (378, FreeBSD ELF32, nmount), eip = 0x280ee76b, esp = 0xbfbfeadc, ebp = 0xbfbfee28 --- lock order reversal: 1st 0xd85133a0 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:2558 2nd 0xc4a21bdc snaplk (snaplk) @ /usr/src/sys/ufs/ffs/ffs_snapshot.c:793 KDB: stack backtrace: db_trace_self_wrapper(c0c6bc14,e6cec408,c08bc9d5,c08ad71b,c0c6eaa9,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c08ad71b,c0c6eaa9,c452be90,c452f2f8,e6cec464,...) at kdb_backtrace+0x29 _witness_debugger(c0c6eaa9,c4a21bdc,c0c8d462,c452f2f8,c0c8d400,...) at _witness_debugger+0x25 witness_checkorder(c4a21bdc,9,c0c8d400,319,c4caeaec,...) at witness_checkorder+0x839 __lockmgr_args(c4a21bdc,80400,c4caeaec,0,0,...) at __lockmgr_args+0x7a7 ffs_lock(e6cec574,0,0,80400,c4caea78,...) at ffs_lock+0x8a VOP_LOCK1_APV(c0d6e900,e6cec574,c195cb90,c0d87380,c4caea78,...) at VOP_LOCK1_APV+0xb5 _vn_lock(c4caea78,80400,c0c8d400,319,0,...) at _vn_lock+0x5e ffs_snapshot(c49dca10,c49db620,c0c8ed65,15f,c0c7506a,...) at ffs_snapshot+0x28b6 ffs_mount(c49dca10,0,c0c75557,3d2,0,...) at ffs_mount+0x14aa vfs_donmount(c4ca66c0,211000,c45b5b00,c45b5b00,bfbfecb4,...) at vfs_donmount+0x1012 nmount(c4ca66c0,e6ceccf8,c,c4ca66c0,c0d4fe38,...) at nmount+0x75 syscall(e6cecd38) at syscall+0x2a3 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (378, FreeBSD ELF32, nmount), eip = 0x280ee76b, esp = 0xbfbfeadc, ebp = 0xbfbfee28 --- lock order reversal: 1st 0xc4a21bdc snaplk (snaplk) @ /usr/src/sys/kern/vfs_vnops.c:296 2nd 0xc4caead0 ufs (ufs) @ /usr/src/sys/ufs/ffs/ffs_snapshot.c:1587 KDB: stack backtrace: db_trace_self_wrapper(c0c6bc14,e6cec8b8,c08bc9d5,c08ad71b,c0c6eaa9,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c08ad71b,c0c6eaa9,c452f2f8,c452efb8,e6cec914,...) at kdb_backtrace+0x29 _witness_debugger(c0c6eaa9,c4caead0,c0c617fd,c452efb8,c0c8d400,...) at _witness_debugger+0x25 witness_checkorder(c4caead0,9,c0c8d400,633,0,...) at witness_checkorder +0x839 __lockmgr_args(c4caead0,80000,0,0,0,...) at __lockmgr_args+0x7a7 ffs_snapremove(c4caea78,c49dca10,0,c0c76f01,41d,...) at ffs_snapremove +0x11f softdep_releasefile(c4b6dd24,e6ceca9c,2,c0efbae8,c0d553dc,...) at softdep_releasefile+0x3b ufs_inactive(e6cecadc,c4caeaec,c4caea78,c4caeaec,e6cecaf4,...) at ufs_inactive+0x1bc VOP_INACTIVE_APV(c0d6e900,e6cecadc,c0c75d38,924,c0d87340,...) at VOP_INACTIVE_APV+0xa5 vinactive(c0d6e900,e6cecb10,c0c75d38,8aa,128,...) at vinactive+0x8e vput(c4caea78,e6cecb4c,c0c76f01,128,0,...) at vput+0x1cd vn_close(c4caea78,1,c456d100,c4ca66c0,0,...) at vn_close+0x19a vn_closefile(c49f0620,c4ca66c0,3,0,c49f0620,...) at vn_closefile+0xe4 _fdrop(c49f0620,c4ca66c0,e6cecc18,c08bc81c,0,c4ca6764,c0efbae8,c0d569c0,c0c63538,c4ca302c,45b,c0c63538,e6cecc40,c0883a80,c4ca302c,8,c0c63538,45b) at _fdrop+0x43 closef(c49f0620,c4ca66c0,45b,440,c4ca302c,...) at closef+0x290 kern_close(c4ca66c0,4,e6cecd2c,c0ba8e93,c4ca66c0,...) at kern_close +0x117 close(c4ca66c0,e6ceccf8,4,c0c6f8c2,c0d4d588,...) at close+0x1a syscall(e6cecd38) at syscall+0x2a3 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (6, FreeBSD ELF32, close), eip = 0x28192253, esp = 0xbfbfeadc, ebp = 0xbfbfee28 --- lock order reversal: 1st 0xd858bbb0 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:2558 2nd 0xc49a1a00 dirhash (dirhash) @ /usr/src/sys/ufs/ufs/ufs_dirhash.c:285 KDB: stack backtrace: db_trace_self_wrapper(c0c6bc14,e6cfca74,c08bc9d5,c08ad71b,c0c6eaa9,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c08ad71b,c0c6eaa9,c452be90,c452f020,e6cfcad0,...) at kdb_backtrace+0x29 _witness_debugger(c0c6eaa9,c49a1a00,c0c8f887,c452f020,c0c8f520,...) at _witness_debugger+0x25 witness_checkorder(c49a1a00,9,c0c8f520,11d,0,...) at witness_checkorder +0x839 _sx_xlock(c49a1a00,0,c0c8f520,11d,da6cd018,...) at _sx_xlock+0x85 ufsdirhash_acquire(0,e,c47a6000,d858bb50,da6cd018,...) at ufsdirhash_acquire+0x35 ufsdirhash_remove(c4dd31d0,da6cd018,18,e6cfcb60,e6cfcb5c,...) at ufsdirhash_remove+0x14 ufs_dirremove(c4dd6a78,c4def658,500800c,0,c4dd6a78,...) at ufs_dirremove +0xe5 ufs_remove(e6cfcc34,0,0,0,c4decb84,...) at ufs_remove+0x6e VOP_REMOVE_APV(c0d6e900,e6cfcc34,c4decb84,e6cfcc0c,28216238,...) at VOP_REMOVE_APV+0xa5 kern_unlinkat(c4ca5d80,ffffff9c,28216238,0,e6cfcc80,...) at kern_unlinkat+0x181 kern_unlink(c4ca5d80,28216238,0,e6cfcd2c,c0ba8e93,...) at kern_unlink +0x27 unlink(c4ca5d80,e6cfccf8,4,c0c89eb5,c0d4d5f8,...) at unlink+0x22 syscall(e6cfcd38) at syscall+0x2a3 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (10, FreeBSD ELF32, unlink), eip = 0x28168d6f, esp = 0xbfbfec5c, ebp = 0xbfbfec88 --- # From owner-freebsd-stable@FreeBSD.ORG Sat Jul 18 17:04: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 069421065674; Sat, 18 Jul 2009 17:04:31 +0000 (UTC) (envelope-from danger@FreeBSD.org) Received: from services.rulez.sk (services.rulez.sk [92.240.234.125]) by mx1.freebsd.org (Postfix) with ESMTP id B11BC8FC14; Sat, 18 Jul 2009 17:04:30 +0000 (UTC) (envelope-from danger@FreeBSD.org) Received: from localhost (services.rulez.sk [92.240.234.125]) by services.rulez.sk (Postfix) with ESMTP id B4D421334500; Sat, 18 Jul 2009 18:48:06 +0200 (CEST) X-Virus-Scanned: amavisd-new at rulez.sk Received: from services.rulez.sk ([92.240.234.125]) by localhost (services.rulez.sk [92.240.234.125]) (amavisd-new, port 10024) with ESMTP id f1VU8C-cLAUl; Sat, 18 Jul 2009 18:48:05 +0200 (CEST) Received: from [10.10.1.14] (unknown [217.73.23.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: danger@rulez.sk) by services.rulez.sk (Postfix) with ESMTPSA id DACF513344A8; Sat, 18 Jul 2009 18:48:05 +0200 (CEST) Message-ID: <4A61FCC0.4040303@FreeBSD.org> Date: Sat, 18 Jul 2009 18:48:00 +0200 From: Daniel Gerzo Organization: The FreeBSD Project User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Marten Vijn References: <1247887759.14210.18.camel@neo.cse.buffalo.edu> <1247933100.14935.20.camel@mvn-desktop> In-Reply-To: <1247933100.14935.20.camel@mvn-desktop> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Ken Smith , freebsd-stable , freebsd-current@freebsd.org Subject: Re: make distribution Re: 8.0-BETA2 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: Sat, 18 Jul 2009 17:04:31 -0000 Marten Vijn wrote: > cd /usr/src > make distribution gives an error > > data below, > > README /usr/tftpboot1//etc/pam.d/README > make: don't know how to make gdm. Stop > *** Error code 2 > > Stop in /usr/src/etc. > *** Error code 1 > > Stop in /usr/src. > *** Error code 1 > > Stop in /usr/src. I believe r195753 fixes this problem. Please update your sources. -- S pozdravom / Best regards Daniel Gerzo, FreeBSD committer From owner-freebsd-stable@FreeBSD.ORG Sat Jul 18 17:14: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 B8F13106566B; Sat, 18 Jul 2009 17:14:36 +0000 (UTC) (envelope-from info@martenvijn.nl) Received: from smtp-vbr10.xs4all.nl (smtp-vbr10.xs4all.nl [194.109.24.30]) by mx1.freebsd.org (Postfix) with ESMTP id 540E88FC16; Sat, 18 Jul 2009 17:14:36 +0000 (UTC) (envelope-from info@martenvijn.nl) Received: from [192.168.178.47] (martenvijn.xs4all.nl [80.101.161.153]) by smtp-vbr10.xs4all.nl (8.13.8/8.13.8) with ESMTP id n6IHEPpl088225; Sat, 18 Jul 2009 19:14:25 +0200 (CEST) (envelope-from info@martenvijn.nl) From: Marten Vijn To: Daniel Gerzo In-Reply-To: <4A61FCC0.4040303@FreeBSD.org> References: <1247887759.14210.18.camel@neo.cse.buffalo.edu> <1247933100.14935.20.camel@mvn-desktop> <4A61FCC0.4040303@FreeBSD.org> Content-Type: text/plain Date: Sat, 18 Jul 2009 19:14:27 +0200 Message-Id: <1247937267.14935.23.camel@mvn-desktop> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by XS4ALL Virus Scanner Cc: freebsd-current@FreeBSD.org, Ken Smith , freebsd-stable Subject: Re: make distribution Re: 8.0-BETA2 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: Sat, 18 Jul 2009 17:14:37 -0000 On Sat, 2009-07-18 at 18:48 +0200, Daniel Gerzo wrote: > Marten Vijn wrote: > > cd /usr/src > > make distribution gives an error > > > > data below, > > > > > README /usr/tftpboot1//etc/pam.d/README > > make: don't know how to make gdm. Stop > > *** Error code 2 > > > > Stop in /usr/src/etc. > > *** Error code 1 > > > > Stop in /usr/src. > > *** Error code 1 > > > > Stop in /usr/src. > > I believe r195753 fixes this problem. Please update your sources. I should have mentioned my rev: Last Changed Rev: 195752 updating to Last Changed Rev: 195754 Fixes the issues thanks, Marten > -- http://martenvijn.nl Marten Vijn http://martenvijn.nl/trac/wiki/soas Sugar on a Stick http://bsd.wifisoft.org/nek/ The Network Event Kit http://har2009.org 13th-16th August http://opencommunitycamp.org 26th Jul - 2nd August