From owner-freebsd-current@FreeBSD.ORG Sun Dec 7 00:54:46 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2FCD81065676 for ; Sun, 7 Dec 2008 00:54:46 +0000 (UTC) (envelope-from jackie@boolome.com) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.191]) by mx1.freebsd.org (Postfix) with ESMTP id 859C68FC0C for ; Sun, 7 Dec 2008 00:54:44 +0000 (UTC) (envelope-from jackie@boolome.com) Received: by ti-out-0910.google.com with SMTP id a1so392961tib.3 for ; Sat, 06 Dec 2008 16:54:43 -0800 (PST) Received: by 10.110.86.3 with SMTP id j3mr534980tib.32.1228611282542; Sat, 06 Dec 2008 16:54:42 -0800 (PST) Received: from ?192.168.1.100? ([60.210.219.231]) by mx.google.com with ESMTPS id a4sm3529564tib.4.2008.12.06.16.54.39 (version=SSLv3 cipher=RC4-MD5); Sat, 06 Dec 2008 16:54:40 -0800 (PST) From: boolome To: Robert Noland In-Reply-To: <1228577856.1939.5.camel@wombat.2hip.net> References: <1228446881.1442.8.camel@www.boolome.cn> <1228451740.1982.2.camel@wombat.2hip.net> <1228454182.1172.1.camel@www.boolome.cn> <1228480648.1982.9.camel@wombat.2hip.net> <1228526478.1167.7.camel@www.boolome.cn> <1228577856.1939.5.camel@wombat.2hip.net> Content-Type: text/plain; charset=UTF-8 Organization: boolome Date: Sun, 07 Dec 2008 08:54:29 +0800 Message-Id: <1228611269.1716.6.camel@www.boolome.cn> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 8bit Cc: "freebsd-current@freebsd.org" Subject: Re: how to config for run compiz fusion X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Dec 2008 00:54:46 -0000 在 2008-12-06六的 10:37 -0500，Robert Noland写道： > On Sat, 2008-12-06 at 09:21 +0800, boolome wrote: > > 在 2008-12-05五的 07:37 -0500，Robert Noland写道： > > > On Fri, 2008-12-05 at 13:16 +0800, boolome wrote: > > > > 在 2008-12-04四的 23:35 -0500，Robert Noland写道： > > > > > On Fri, 2008-12-05 at 11:14 +0800, boolome wrote: > > > > > > Option "AccelMethod" "XAA" > > > > > > Option "XAANoOffscreenPixmaps" "true" > > > > > > Option "AddARGBGLXVisuals" "true" > > > > > > > > > > Try using EXA, which is the default. i.e. comment out all of the above > > > > > lines. Otherwise, it looks very much like what I run on my 965... What > > > > > version of FreeBSD are you running? > > > > > > > > > > robert. > > > > > > > > > I have commented the lines you mentioned . but problem same. > > > > %uname -a > > > > FreeBSD www.boolome.cn 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Sun Oct 19 > > > > 16:07:48 CST 2008 > > > > boolome@www.boolome.cn:/usr/obj/usr/src/sys/boolome i386 > > > > > > > > Thanks your reply,robert . > > > > > > > > and Can I have a look at your xorg.conf , and how you run compiz ? > > > > > > I posted my xorg.conf at http://people.freebsd.org/~rnoland/xorg.conf > > > Note that I'm running a pre-release of xserver 1.6 at the moment, but > > > the it should still be pretty much the same. For starting compiz, I use > > > fusion-icon, which has never been released, so there is no port. > > > "compiz --replace --sm-disable --ignore-desktop-hints ccp" should work > > > correctly though. > > > > > > If your still having issues, send me an xorg.log. > > > > > > robert. > > > > > > > > > > > > > > > > > This is some attachment . > > I found when I run "change screensave properties" ,the x crashed and the > > message is "drm0:[ithread]" , > > This message is displayed when the interrupt handler is installed. It > is normal when X is restarting after the crash or after a vt switch. > > X crashing could be many things... The log you sent doesn't show the > crash, it is probably from the restarted session. A backtrace from X is > probably the best way to track that down. > > robert. > > > There is something wrong with drm ? > > > > Thanks ,Robert . > > Are these messages useful? from xorg.log (II) intel(0): Output VGA connected (II) intel(0): Output VGA using initial mode 1440x900 (==) intel(0): Write-combining range (0xa0000,0x10000) was already clear (II) intel(0): detected 256 kB GTT. (II) intel(0): detected 7932 kB stolen memory. (==) intel(0): video overlay key set to 0x101fe (==) intel(0): Will not try to enable page flipping (==) intel(0): Triple buffering disabled (==) intel(0): Intel XvMC decoder disabled (==) intel(0): Using gamma correction (1.0, 1.0, 1.0) (**) intel(0): Display dimensions: (410, 260) mm (**) intel(0): DPI set to (89, 140) (II) Loading sub module "fb" (II) LoadModule: "fb" (II) Loading /usr/local/lib/xorg/modules//libfb.so (II) Module fb: vendor="X.Org Foundation" compiled for 1.4.2, module version = 1.0.0 ABI class: X.Org ANSI C Emulation, version 0.3 (II) Loading sub module "exa" (II) LoadModule: "exa" (II) Loading /usr/local/lib/xorg/modules//libexa.so (II) Module exa: vendor="X.Org Foundation" compiled for 1.4.2, module version = 2.2.0 ABI class: X.Org Video Driver, version 2.0 (II) Loading sub module "ramdac" (II) LoadModule: "ramdac"(II) Module "ramdac" already built-in (II) intel(0): Comparing regs from server start up to After PreInit (==) Depth 24 pixmap format is 32 bpp (II) do I need RAC? No, I don't. (II) resource ranges after preInit: [0] 0 0 0xfdf80000 - 0xfdfbffff (0x40000) MS[B] [1] 0 0 0xd0000000 - 0xdfffffff (0x10000000) MS[B] [2] 0 0 0xfdf00000 - 0xfdf7ffff (0x80000) MS[B] [3] -1 0 0x00100000 - 0x3fffffff (0x3ff00000) MX[B]E(B) [4] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [5] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [6] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [7] -1 0 0xfdeff000 - 0xfdefffff (0x1000) MX[B]E [8] -1 0 0xfdffd000 - 0xfdffdfff (0x1000) MX[B]E [9] -1 0 0xfdffe000 - 0xfdffefff (0x1000) MX[B]E [10] -1 0 0xfdfff000 - 0xfdffffff (0x1000) MX[B]E [11] -1 0 0xfdf80000 - 0xfdfbffff (0x40000) MX[B](B) [12] -1 0 0xd0000000 - 0xdfffffff (0x10000000) MX[B](B) [13] -1 0 0xfdf00000 - 0xfdf7ffff (0x80000) MX[B](B) [14] 0 0 0x000a0000 - 0x000affff (0x10000) MS[B](OprD) [15] 0 0 0x000b0000 - 0x000b7fff (0x8000) MS[B](OprD) [16] 0 0 0x000b8000 - 0x000bffff (0x8000) MS[B](OprD) [17] 0 0 0x0000ff00 - 0x0000ff07 (0x8) IS[B] [18] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [19] -1 0 0x00000000 - 0x000000ff (0x100) IX[B] [20] -1 0 0x0000de00 - 0x0000deff (0x100) IX[B]E [21] -1 0 0x00000500 - 0x000005ff (0x100) IX[B]E [22] -1 0 0x0000f300 - 0x0000f3ff (0x100) IX[B]E [23] -1 0 0x0000f400 - 0x0000f4ff (0x100) IX[B]E [24] -1 0 0x0000f500 - 0x0000f5ff (0x100) IX[B]E [25] -1 0 0x0000f600 - 0x0000f6ff (0x100) IX[B]E [26] -1 0 0x0000f700 - 0x0000f7ff (0x100) IX[B]E [27] -1 0 0x0000f800 - 0x0000f8ff (0x100) IX[B]E [28] -1 0 0x0000fa00 - 0x0000faff (0x100) IX[B]E [29] -1 0 0x0000f000 - 0x0000f0ff (0x100) IX[B]E [30] -1 0 0x0000fb00 - 0x0000fbff (0x100) IX[B]E [31] -1 0 0x0000fc00 - 0x0000fcff (0x100) IX[B]E [32] -1 0 0x0000fd00 - 0x0000fdff (0x100) IX[B]E [33] -1 0 0x0000fe00 - 0x0000feff (0x100) IX[B]E [34] -1 0 0x0000ff00 - 0x0000ff07 (0x8) IX[B](B) [35] 0 0 0x000003b0 - 0x000003bb (0xc) IS[B](OprU) [36] 0 0 0x000003c0 - 0x000003df (0x20) IS[B](OprU) (II) intel(0): Kernel reported 491520 total, 0 used (II) intel(0): I830CheckAvailableMemory: 1966080 kB available drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 14, (OK) drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 14, (OK) drmOpenByBusid: Searching for BusID pci:0000:00:02.0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 14, (OK) drmOpenByBusid: drmOpenMinor returns 14 drmOpenByBusid: drmGetBusid reports pci:0000:00:02.0 (II) [drm] DRM interface version 1.0 (EE) [drm] Could not set DRM device bus ID. (EE) intel(0): [dri] DRIScreenInit failed. Disabling DRI. (**) intel(0): Framebuffer compression disabled (**) intel(0): Tiling enabled (==) intel(0): Write-combining range (0xfdf00000,0x80000) was already clear (==) intel(0): Write-combining range (0xfdf80000,0x40000) was already clear (==) intel(0): VideoRam: 262144 KB (II) intel(0): Attempting memory allocation with tiled buffers. (II) intel(0): Tiled allocation successful. (II) intel(0): Page Flipping disabled (==) intel(0): Write-combining range (0xfdf00000,0x80000) was already clear (==) intel(0): Write-combining range (0xfdf80000,0x40000) was already clear (==) intel(0): Write-combining range (0xd0000000,0x10000000) was already set (II) intel(0): vgaHWGetIOBase: hwp->IOBase is 0x03d0, hwp->PIOOffset is 0x0000 (==) intel(0): Write-combining range (0xa0000,0x10000) was already clear (II) EXA(0): Offscreen pixmap area of 35389440 bytes (II) EXA(0): Driver registered support for the following operations: (II) Solid (II) Copy (II) Composite (RENDER acceleration) (==) intel(0): Backing store disabled (==) intel(0): Silken mouse enabled (II) intel(0): Initializing HW Cursor (II) intel(0): xf86BindGARTMemory: bind key 10 at 0x01000000 (pgoffset 4096) (II) intel(0): xf86BindGARTMemory: bind key 11 at 0x02000000 (pgoffset 8192) (II) intel(0): Fixed memory allocation layout: (II) intel(0): 0x00000000-0x0001ffff: ring buffer (128 kB) (II) intel(0): 0x00020000-0x00029fff: HW cursors (40 kB, 0x000000007f820000 physical ) (II) intel(0): 0x0002a000-0x00031fff: logical 3D context (32 kB) (II) intel(0): 0x00032000-0x00032fff: overlay registers (4 kB, 0x000000007f832000 physical ) (II) intel(0): 0x007bf000: end of stolen memory (II) intel(0): 0x01000000-0x01ffffff: front buffer (11520 kB) X tiled (II) intel(0): 0x02000000-0x041bffff: exa offscreen (34560 kB) (II) intel(0): 0x10000000: end of aperture (WW) intel(0): PRB0_CTL (0x0001f001) indicates ring buffer enabled (WW) intel(0): PRB0_HEAD (0x46c13f78) and PRB0_TAIL (0x000156e8) indicate ring buffer not flushed (WW) intel(0): Existing errors found in hardware state. Error in I830WaitLpRing(), timeout for 2 seconds pgetbl_ctl: 0x7ffc0001 getbl_err: 0x00000000 ipeir: 0x00000000 iphdr: 0x6db3ffff LP ring tail: 0x000156f0 head: 0x00013f78 len: 0x0001f001 start 0x00000000 eir: 0x0000 esr: 0x0000 emr: 0xffff instdone: 0xffc1 instpm: 0x0000 memmode: 0x00000306 instps: 0x800f00d0 hwstam: 0xeffe ier: 0x0042 imr: 0x0000 iir: 0x1020 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f0 count 1502 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f0 count 1502 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f0 count 1502 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f0 count 1502 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f0 count 1502 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f0 count 1502 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f0 count 1502 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f0 count 1502 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f0 count 1502 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f0 count 1502 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f0 count 1502 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f0 count 1502 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f0 count 1502 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f0 count 1502 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f0 count 1502 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f0 count 1502 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f0 count 1502 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f0 count 1502 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f0 count 1502 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f0 count 1502 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f0 count 1502 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f0 count 1502 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f0 count 1502 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f0 count 1502 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f0 count 1502 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f0 count 1502 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f0 count 1502 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f0 count 1502 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f0 count 1502 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f0 count 1502 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f0 count 1502 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f0 count 1502 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f0 count 1502 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f0 count 1502 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f0 count 1502 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f0 count 1502 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f0 count 1502 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f0 count 1502 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f0 count 1502 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f0 count 1502 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f0 count 1502 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f0 count 1502 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f0 count 1502 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f0 count 1502 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f0 count 1502 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f0 count 1502 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f0 count 1502 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f0 count 1502 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f0 count 1502 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f0 count 1502 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f0 count 1502 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f0 count 1502 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f0 count 1502 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f0 count 1502 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f0 count 1502 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f0 count 1502 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f0 count 1502 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f0 count 1502 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f0 count 1502 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f0 count 1502 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f0 count 1502 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f0 count 1502 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f0 count 1502 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f0 count 1502 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f0 count 1502 Ring end space: 125056 wanted 131064 Fatal server error: lockup Error in I830WaitLpRing(), timeout for 2 seconds pgetbl_ctl: 0x7ffc0001 getbl_err: 0x00000000 ipeir: 0x00000000 iphdr: 0x6db3ffff LP ring tail: 0x000156f8 head: 0x00013f78 len: 0x0001f001 start 0x00000000 eir: 0x0000 esr: 0x0000 emr: 0xffff instdone: 0xffc1 instpm: 0x0000 memmode: 0x00000306 instps: 0x800f00d0 hwstam: 0xeffe ier: 0x0042 imr: 0x0000 iir: 0x1020 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f8 count 1504 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f8 count 1504 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f8 count 1504 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f8 count 1504 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f8 count 1504 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f8 count 1504 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f8 count 1504 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f8 count 1504 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f8 count 1504 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f8 count 1504 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f8 count 1504 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f8 count 1504 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f8 count 1504 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f8 count 1504 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f8 count 1504 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f8 count 1504 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f8 count 1504 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f8 count 1504 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f8 count 1504 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f8 count 1504 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f8 count 1504 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f8 count 1504 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f8 count 1504 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f8 count 1504 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f8 count 1504 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f8 count 1504 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f8 count 1504 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f8 count 1504 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f8 count 1504 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f8 count 1504 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f8 count 1504 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f8 count 1504 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f8 count 1504 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f8 count 1504 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f8 count 1504 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f8 count 1504 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f8 count 1504 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f8 count 1504 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f8 count 1504 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f8 count 1504 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f8 count 1504 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f8 count 1504 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f8 count 1504 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f8 count 1504 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f8 count 1504 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f8 count 1504 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f8 count 1504 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f8 count 1504 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f8 count 1504 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f8 count 1504 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f8 count 1504 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f8 count 1504 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f8 count 1504 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f8 count 1504 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f8 count 1504 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f8 count 1504 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f8 count 1504 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f8 count 1504 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f8 count 1504 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f8 count 1504 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f8 count 1504 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f8 count 1504 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f8 count 1504 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f8 count 1504 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f8 count 1504 Ring end space: 125048 wanted 131064 FatalError re-entered, aborting lockup >From messages Dec 7 08:29:44 www console-kit-daemon[1005]: GLib-CRITICAL: g_hash_table_lookup: assertion `hash_table != NULL' failed Dec 7 08:29:44 www kernel: pid 1004 (Xorg), uid 0: exited on signal 6 (core dumped) Dec 7 08:29:44 www console-kit-daemon[1005]: GLib-CRITICAL: g_hash_table_destroy: assertion `hash_table != NULL' failed Dec 7 08:29:44 www gdm-binary[1003]: WARNING: gdm_slave_xioerror_handler: Fatal X error - Restarting :0 Dec 7 08:29:51 www kernel: pid 29007 (Xorg), uid 0: exited on signal 6 (core dumped) Dec 7 08:30:01 www kernel: pid 29013 (Xorg), uid 0: exited on signal 6 (core dumped) Dec 7 08:30:10 www kernel: pid 29023 (Xorg), uid 0: exited on signal 6 (core dumped) Dec 7 08:30:11 www gdm-binary[1002]: WARNING: Failed to start X server several times in a short time period; disabling display :0 From owner-freebsd-current@FreeBSD.ORG Sun Dec 7 01:07:46 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 133041065676 for ; Sun, 7 Dec 2008 01:07:46 +0000 (UTC) (envelope-from conrads@cox.net) Received: from eastrmmtao105.cox.net (eastrmmtao105.cox.net [68.230.240.47]) by mx1.freebsd.org (Postfix) with ESMTP id 9A6848FC18 for ; Sun, 7 Dec 2008 01:07:45 +0000 (UTC) (envelope-from conrads@cox.net) Received: from eastrmimpo01.cox.net ([68.1.16.119]) by eastrmmtao105.cox.net (InterMail vM.7.08.02.01 201-2186-121-102-20070209) with ESMTP id <20081207010744.FWOR14968.eastrmmtao105.cox.net@eastrmimpo01.cox.net>; Sat, 6 Dec 2008 20:07:44 -0500 Received: from serene.no-ip.org ([72.200.37.152]) by eastrmimpo01.cox.net with bizsmtp id o17k1a0043Gxf8w0217kQx; Sat, 06 Dec 2008 20:07:44 -0500 X-Authority-Analysis: v=1.0 c=1 a=OVRPlC57E5LFJG8NT7kA:9 a=agTK5kKbjzDoV7nL0vMA:7 a=HKl0NgFLCZcKh6YHWwdAVHzvfQ8A:4 a=4vB-4DCPJfMA:10 a=LY0hPdMaydYA:10 X-CM-Score: 0.00 Date: Sat, 6 Dec 2008 19:07:54 -0600 From: "Conrad J. Sabatier" To: cpghost Message-ID: <20081206190754.6c2bbd70@serene.no-ip.org> In-Reply-To: <20081203151537.GA1045@phenom.cordula.ws> References: <20081128234155.0221e263@serene.no-ip.org> <4930D7CE.4080909@psg.com> <20081202220643.72eb52a3@serene.no-ip.org> <20081203151537.GA1045@phenom.cordula.ws> X-Mailer: Claws Mail 3.5.0 (GTK+ 2.14.4; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: i give up X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Dec 2008 01:07:46 -0000 On Wed, 3 Dec 2008 16:15:37 +0100 cpghost wrote: > On Tue, Dec 02, 2008 at 10:06:43PM -0600, Conrad J. Sabatier wrote: > > Best wishes to the FreeBSD community. No hard feelings, and I will > > still continue to checkout the latest sources from time to time > > just on the outside chance that a solution will eventually be found. > > > > Sincerest regards from a long-time FreeBSD user now in exile. :-( > > Changing the OS just because one specific piece of swappable and > replaceable hardware isn't supported... isn't that overreacting a > little bit? Can't you circumvent your specific problem by adding a > supported adapter to your system(s)... at least until the issue is > fixed? As sysadmins, we do this all the time, wether with Linux or > FreeBSD. > > I feel your pain, but maybe you've built up quite a bit of frustration > over this specific issue and need a little hiatus. > > I hope you'll come back soon. I agree with you totally in principle, but my current financial situation/credit standing is such that I was forced to purchase this machine from one of the few vendors willing to offer me a line of credit. :-( If I could, I would gladly replace the non-functioning components, but I'm just too strapped for cash at the moment, so... I'm continuing to hold out hope that I can provide the missing bits of the puzzle that will lead to a solution. But I've already passed along everything I could get from Windows Vista's System Information tool, Linux's lspci command, and FreeBSD's pciconf and dmesg. I don't know what more iI can provide at this point. As another poster suggested, it's possible there's a bug/typo in the patches Soren sent me, although they all apply quite cleanly to every successive version of current I've tried them on. So...I'm at a loss at this point. It really is frustrating. I'm no fan of either Windows or Linux, but at least they do recognize my hardware. So I'm stuck for the time being. If anyone's interested, I'll repost or mail directly to them all the pertinent info I can gather. Just say the word and it shall be done. Thanks. -- Conrad J. Sabatier From owner-freebsd-current@FreeBSD.ORG Sun Dec 7 03:19:22 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 734D41065672; Sun, 7 Dec 2008 03:19:22 +0000 (UTC) (envelope-from ken@mthelicon.com) Received: from hercules.mthelicon.com (hercules.mthelicon.com [IPv6:2001:49f0:2023::2]) by mx1.freebsd.org (Postfix) with ESMTP id 3FC9D8FC0C; Sun, 7 Dec 2008 03:19:22 +0000 (UTC) (envelope-from ken@mthelicon.com) Received: from feathers.peganest.com (78-33-110-3.static-adsl.entanet.co.uk [78.33.110.3] (may be forged)) (authenticated bits=0) by hercules.mthelicon.com (8.14.3/8.14.2) with ESMTP id mB73JJQA022337 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Sun, 7 Dec 2008 03:19:21 GMT (envelope-from ken@mthelicon.com) From: Pegasus Mc Cleaft Organization: Feathers To: hackers@freebsd.org, current@freebsd.org Date: Sun, 7 Dec 2008 03:19:18 +0000 User-Agent: KMail/1.10.1 (FreeBSD/8.0-CURRENT; KDE/4.1.1; amd64; ; ) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200812070319.18461.ken@mthelicon.com> Cc: Subject: Problems with zfsboot loader if raidz present on any drive X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Dec 2008 03:19:22 -0000 Hello Hackers, Recently and friend and I have been trying to get the new gptzfsboot working on our machines and ran into a interesting problem. Initially I was building the world without the environment variable LOADER_ZFS_SUPPORT=YES in the /etc/make.conf and this, of course, didnt work very well. Every time the machine booted, it would throw 2 lines after the pin-wheel and then reboot. I couldent read what the lines were it went so fast. My friend had a bit more luck and got his machine working OK with a single drive and later a mirror drive added. I added the environment variable and rebuilt everything and installed. This time, I could see the bios drives and a further 2 lines of ZFS something and a reboot... No matter what I tried, I couldent get the machine to boot up to a point where I could try and fix the problem, so I started pulling devices out and found the following: If there is a raidz pool on any drive (not necessarily the one that you are trying to boot from) the loader dies and reboots the machine. My friend, as an experiment created 3 gpt partitions (in addition to the single partition that he had been previously booted from) on his single drive and made a raidz pool for testing. His machine showed the same condition as mine, however he was able to capture the message before the machine rebooted: ZFS: can only boot from disk or mirror vdevs ZFS: inconsistent nvlist contents / ~Peg From owner-freebsd-current@FreeBSD.ORG Sun Dec 7 07:10:02 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E57C01065670 for ; Sun, 7 Dec 2008 07:10:02 +0000 (UTC) (envelope-from peterjeremy@optushome.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 598BA8FC17 for ; Sun, 7 Dec 2008 07:09:56 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from mail15.syd.optusnet.com.au (mail15.syd.optusnet.com.au [211.29.132.196]) by fallbackmx06.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id mB6KkNu3007968 for ; Sun, 7 Dec 2008 07:46:23 +1100 Received: from server.vk2pj.dyndns.org (c122-106-215-175.belrs3.nsw.optusnet.com.au [122.106.215.175]) by mail15.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id mB6KkHNB016368 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 7 Dec 2008 07:46:20 +1100 X-Bogosity: Ham, spamicity=0.000000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.3/8.14.3) with ESMTP id mB6KkGKo046146; Sun, 7 Dec 2008 07:46:17 +1100 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.3/8.14.3/Submit) id mB6KkCET046145; Sun, 7 Dec 2008 07:46:12 +1100 (EST) (envelope-from peter) Date: Sun, 7 Dec 2008 07:46:12 +1100 From: Peter Jeremy To: Luigi Rizzo Message-ID: <20081206204611.GO58682@server.vk2pj.dyndns.org> References: <20081205142558.GA5394@onelab2.iet.unipi.it> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="YkilVOb9qhI0mB+X" Content-Disposition: inline In-Reply-To: <20081205142558.GA5394@onelab2.iet.unipi.it> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.18 (2008-05-17) Cc: current@freebsd.org Subject: Re: Running Forth/ficl as a user command ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Dec 2008 07:10:03 -0000 --YkilVOb9qhI0mB+X Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2008-Dec-05 15:25:58 +0100, Luigi Rizzo wrote: >apologies if the question is silly, but is there a >way to run the Forth interpreter embedded in /boot/loader >as a user command ? You could try building 'testmain' in src/sys/boot/ficl - I've not tried this but I think it does what you want. --=20 Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. --YkilVOb9qhI0mB+X Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkk65JMACgkQ/opHv/APuIdjLACgsN18RcB1vJcwErcJaJlc2U+I /PwAoJnz1W6sOOvHG1ny9zvpnHZfcxjE =04dI -----END PGP SIGNATURE----- --YkilVOb9qhI0mB+X-- From owner-freebsd-current@FreeBSD.ORG Sun Dec 7 09:22:19 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2D18A1065676; Sun, 7 Dec 2008 09:22:19 +0000 (UTC) (envelope-from dfr@rabson.org) Received: from itchy.rabson.org (unknown [IPv6:2002:50b1:e8f2:1::143]) by mx1.freebsd.org (Postfix) with ESMTP id DC2628FC19; Sun, 7 Dec 2008 09:22:18 +0000 (UTC) (envelope-from dfr@rabson.org) Received: from [IPv6:2001:470:909f:1:21b:63ff:feb8:5abc] (unknown [IPv6:2001:470:909f:1:21b:63ff:feb8:5abc]) by itchy.rabson.org (Postfix) with ESMTP id CD2273F9F; Sun, 7 Dec 2008 09:22:16 +0000 (GMT) Message-Id: <66BF33BA-EC11-446F-9DE7-15395F293FE2@rabson.org> From: Doug Rabson To: Pegasus Mc Cleaft In-Reply-To: <200812070319.18461.ken@mthelicon.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Date: Sun, 7 Dec 2008 09:22:16 +0000 References: <200812070319.18461.ken@mthelicon.com> X-Mailer: Apple Mail (2.929.2) Cc: hackers@freebsd.org, current@freebsd.org Subject: Re: Problems with zfsboot loader if raidz present on any drive X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Dec 2008 09:22:19 -0000 On 7 Dec 2008, at 03:19, Pegasus Mc Cleaft wrote: > Hello Hackers, > > Recently and friend and I have been trying to get the new > gptzfsboot working > on our machines and ran into a interesting problem. > > Initially I was building the world without the environment variable > LOADER_ZFS_SUPPORT=YES in the /etc/make.conf and this, of course, > didnt work > very well. Every time the machine booted, it would throw 2 lines > after the > pin-wheel and then reboot. I couldent read what the lines were it > went so > fast. > > My friend had a bit more luck and got his machine working OK with a > single > drive and later a mirror drive added. > > I added the environment variable and rebuilt everything and > installed. This > time, I could see the bios drives and a further 2 lines of ZFS > something and a > reboot... > > No matter what I tried, I couldent get the machine to boot up to a > point > where I could try and fix the problem, so I started pulling devices > out and > found the following: If there is a raidz pool on any drive (not > necessarily > the one that you are trying to boot from) the loader dies and > reboots the > machine. My friend, as an experiment created 3 gpt partitions (in > addition to > the single partition that he had been previously booted from) on his > single > drive and made a raidz pool for testing. His machine showed the same > condition > as mine, however he was able to capture the message before the machine > rebooted: > > > ZFS: can only boot from disk or mirror vdevs > > ZFS: inconsistent nvlist contents The zfsboot code in current doesn't support raidz or raidz2. I have been working on adding that support but its not ready yet. The code works in my test harness but crashes instantly when I put it in the boot code :(. I should have time to finish debugging it soon. From owner-freebsd-current@FreeBSD.ORG Sun Dec 7 09:23:49 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 71163106567B; Sun, 7 Dec 2008 09:23:49 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe12.swipnet.se [212.247.155.97]) by mx1.freebsd.org (Postfix) with ESMTP id 8F7578FC23; Sun, 7 Dec 2008 09:23:47 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=OxQIQV-UnBUA:10 a=OldrGD9YyLYA:10 a=P3SC899gXHkOLDnkTYxLZw==:17 a=6I5d2MoRAAAA:8 a=XWMPSL2NCp9O6ptO02YA:9 a=-m65pplqKBvUwPkz_OsA:7 a=rQWlRaZadRbjHd-41yFsA6_yBIcA:4 a=LY0hPdMaydYA:10 Received: from [62.113.133.240] (account mc467741@c2i.net [62.113.133.240] verified) by mailfe12.swip.net (CommuniGate Pro SMTP 5.2.6) with ESMTPA id 989066876; Sun, 07 Dec 2008 10:23:45 +0100 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Sun, 7 Dec 2008 10:25:58 +0100 User-Agent: KMail/1.9.7 References: <20081107082740.GA1334@icarus.home.lan> <200812061334.55365.hselasky@c2i.net> <031DE609-3E5B-4508-BAB0-95800B7F02F4@mac.com> In-Reply-To: <031DE609-3E5B-4508-BAB0-95800B7F02F4@mac.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200812071026.00497.hselasky@c2i.net> Cc: Marcel Moolenaar , freebsd-usb@freebsd.org, Alfred Perlstein Subject: Re: [Serious] busdma bug in -current in relation to USB hardware - review wanted X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Dec 2008 09:23:49 -0000 On Saturday 06 December 2008, Marcel Moolenaar wrote: > On Dec 6, 2008, at 4:34 AM, Hans Petter Selasky wrote: > > Hi, > > > > After various feedback from several people I have made a new patch > > proposal > > that will fix the busdma problem. > > > > See: > > > > http://perforce.freebsd.org/chv.cgi?CH=154181 > > > > Review wanted! > > The USB stack has a fixed page size of 4K. On our 64-bit platforms > PAGE_SIZE is at least 8K. Your change is sloppy in that respect > and doesn't make the distinction. That makes the patch a kluge. > The definition of BUS_DMA_NO_REALIGN is based on circumstantial > evidence only and as such, works as a side-effect. I don't think > that's a good design. > > I don't think there's any reason not to preserve the page offset > in all cases. So far all hardware worked whether or not their > DMA pages were bounced and the non-bounced pages would have a > possible non-zero page offset, whereas the bounced pages would > always have a zero page offset. In short: it works either way. > In particular, it works with the page offset preserved. Why not > preserve it always? What's the downside? Hi Marcel, I think you might be right there. There is one case in which I don't understand what is the correct busdma behaviour. If the DMA tag has an alignment of 4 bytes, and the memory loaded is not aligned to four bytes, then should a bounce page be used? If yes, then you will need to clear the page offset. Else not. NOTE: We are not talking about allocating DMA memory, only loading it. --HPS From owner-freebsd-current@FreeBSD.ORG Sun Dec 7 10:21:16 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9F9D71065676 for ; Sun, 7 Dec 2008 10:21:16 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from koef.zs64.net (koef.zs64.net [212.12.50.230]) by mx1.freebsd.org (Postfix) with ESMTP id 1E5608FC1E for ; Sun, 7 Dec 2008 10:21:15 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from localhost by koef.zs64.net (8.14.3/8.14.3) with ESMTP id mB7ALDgL075104 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Sun, 7 Dec 2008 11:21:14 +0100 (CET) (envelope-from stb@lassitu.de) (authenticated as stb) Message-Id: <5C97E586-4296-4835-A103-FD273B2D7A4F@lassitu.de> From: Stefan Bethke To: FreeBSD Current In-Reply-To: <31C70CBC-488A-4A9A-A642-37855E8F1DD1@lassitu.de> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Date: Sun, 7 Dec 2008 11:21:13 +0100 References: <20081117205526.GC1733@garage.freebsd.pl> <20081202203308.GA13818@hyperion.scode.org> <200812021254.21242.fjwcash@gmail.com> <20081202232924.GA19134@hyperion.scode.org> <31C70CBC-488A-4A9A-A642-37855E8F1DD1@lassitu.de> X-Mailer: Apple Mail (2.929.2) Subject: ZFS gets stuck X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Dec 2008 10:21:16 -0000 For the past week, I've been stress testing two new boxes by running make -j4 universe. /usr/src is on ufs, /usr/obj on zfs, backed by a single disk pool. Every so often (about once every one or two days), processes start getting wedged on accessing the zfs file systems. Just this morning I found: output from make universe: >> sparc64 started on Sun Dec 7 01:34:41 UTC 2008 >> amd64 completed on Sun Dec 7 02:18:39 UTC 2008 >> pc98 buildworld completed on Sun Dec 7 02:24:35 UTC 2008 >> sun4v started on Sun Dec 7 02:30:45 UTC 2008 ps shows me these processes that apparently are waiting on some zfs operation: 0 81836 81830 0 47 0 6732 4056 zio->i D ?? 0:13.11 find -sx / /tank /tank/ports /usr/obj /dev/null -type f ( -perm -u+x - or -perm -g+x -or -perm -o+x ) ( -perm -u+s -or -perm -g+s ) -exec ls - liTd {} + 0 86345 86344 0 76 0 11392 10300 zio->i D+ 0 0:00.53 make all DIRPRFX=kerberos5/lib/libasn1/ 0 91920 91420 0 76 0 7144 1792 zfsvfs D+ 0 0:00.00 sh -ev 0 91923 91902 0 76 0 2180 400 zfsvfs D+ 0 0:00.00 [cc] 0 91924 91900 0 76 0 10456 7572 zfsvfs D+ 0 0:00.02 / usr/obj/pc98/usr/src/tmp/usr/libexec/cc1 -E -quiet -nostdinc -I. -I@ - I@/contrib/altq -I/usr/obj/pc98/usr/src/sys/MAC -M -D_LONGLONG -DPC98 - D_KERNEL -DKLD_MODULE -DHAVE_KERNEL_OPTION_HEADERS /usr/src/sys/ modules/smbfs/../../netsmb/smb_dev.c df still works, ls /tank blocks. FreeBSD lokschuppen.lassitu.de 8.0-CURRENT FreeBSD 8.0-CURRENT #1: Wed Dec 3 07:05:03 UTC 2008 root@lokschuppen.lassitu.de:/usr/obj/usr/ src/sys/EISENBOOT amd64 So far, I've had this in loader.conf: vfs.zfs.arc_max="512M" vfs.zfs.prefetch_disable="1" I'm now adding vfs.zfs.zil_disable="1" to see if that makes a difference. Is there anything in particular people would want me to check out? Kernel is GENERIC minus a number of devices, and without INVARIANTS and WITNESS. Stefan -- Stefan Bethke Fon +49 170 346 0140 From owner-freebsd-current@FreeBSD.ORG Sun Dec 7 11:09:35 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ED0801065670 for ; Sun, 7 Dec 2008 11:09:35 +0000 (UTC) (envelope-from joao.barros@gmail.com) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.186]) by mx1.freebsd.org (Postfix) with ESMTP id 7210D8FC18 for ; Sun, 7 Dec 2008 11:09:35 +0000 (UTC) (envelope-from joao.barros@gmail.com) Received: by fk-out-0910.google.com with SMTP id k31so1086082fkk.11 for ; Sun, 07 Dec 2008 03:09:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=mO5gMikeLQLmWpNdI5Pz307UoIoRAOCrblBtgRG9Bpc=; b=AjQvar2tYKhyCGdFCQkAGx284Si/8deWAeJvTC1g2DzkN5UFw5kU7QBch0Y97M2GRx 4VksCWFFVAK7yO2BzXQBTnn3RQo3ShClqZ6v3umvblRUz9rd+oY7VEGmmWtIUMZ947pO VRdKhNC0S27yQZGME+NDXE2hZHOV+jnd8KyUw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=qo3+rUghik9Q2jt9G2RosjHZPpgGqtfsz7tiR5bVqJy430STidRCyiVs68ty4l0dly lvkhv7vqo3nJRMfE6pWhwfx32VTDi37cb+KF8p3rolMDTysGF49I/uPSrjjZBdoUsHQO S1Bu9tnhUhVrV9eOxGG2v/7906FGlhLWPHGK0= Received: by 10.180.253.12 with SMTP id a12mr776136bki.147.1228646913361; Sun, 07 Dec 2008 02:48:33 -0800 (PST) Received: by 10.180.236.13 with HTTP; Sun, 7 Dec 2008 02:48:33 -0800 (PST) Message-ID: <70e8236f0812070248p3341c24aob024995be08b962a@mail.gmail.com> Date: Sun, 7 Dec 2008 10:48:33 +0000 From: "Joao Barros" To: "Doug Rabson" In-Reply-To: <66BF33BA-EC11-446F-9DE7-15395F293FE2@rabson.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200812070319.18461.ken@mthelicon.com> <66BF33BA-EC11-446F-9DE7-15395F293FE2@rabson.org> Cc: hackers@freebsd.org, Pegasus Mc Cleaft , current@freebsd.org Subject: Re: Problems with zfsboot loader if raidz present on any drive X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Dec 2008 11:09:36 -0000 On Sun, Dec 7, 2008 at 9:22 AM, Doug Rabson wrote: > > On 7 Dec 2008, at 03:19, Pegasus Mc Cleaft wrote: > >> Hello Hackers, >> >> Recently and friend and I have been trying to get the new >> gptzfsboot working >> on our machines and ran into a interesting problem. >> >> Initially I was building the world without the environment variable >> LOADER_ZFS_SUPPORT=YES in the /etc/make.conf and this, of course, didnt >> work >> very well. Every time the machine booted, it would throw 2 lines after the >> pin-wheel and then reboot. I couldent read what the lines were it went so >> fast. >> >> My friend had a bit more luck and got his machine working OK with a >> single >> drive and later a mirror drive added. >> >> I added the environment variable and rebuilt everything and >> installed. This >> time, I could see the bios drives and a further 2 lines of ZFS something >> and a >> reboot... >> >> No matter what I tried, I couldent get the machine to boot up to a >> point >> where I could try and fix the problem, so I started pulling devices out >> and >> found the following: If there is a raidz pool on any drive (not >> necessarily >> the one that you are trying to boot from) the loader dies and reboots the >> machine. My friend, as an experiment created 3 gpt partitions (in addition >> to >> the single partition that he had been previously booted from) on his >> single >> drive and made a raidz pool for testing. His machine showed the same >> condition >> as mine, however he was able to capture the message before the machine >> rebooted: >> >> >> ZFS: can only boot from disk or mirror vdevs >> >> ZFS: inconsistent nvlist contents > > The zfsboot code in current doesn't support raidz or raidz2. I have been > working on adding that support but its not ready yet. The code works in my > test harness but crashes instantly when I put it in the boot code :(. I > should have time to finish debugging it soon. > After installing my system yesterday on a single disk with gptzfsboot, I connected my old raidz and I only got cyclic reboots. I knew instantly it had something to do with the raidz. Disconnecting 2 out of the 4 disks of the raidz would allow the system to boot as the raidz would not present itself as ONLINE. As a temporary workaround for this problem I disabled those 2 disks on the BIOS, the system boots fine and the kernel is able to find them later. Doug, when you feel comfortable to share any patches, I'm willing to test :-) -- Joao Barros From owner-freebsd-current@FreeBSD.ORG Sun Dec 7 11:35:12 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B19BA1065670 for ; Sun, 7 Dec 2008 11:35:12 +0000 (UTC) (envelope-from scode@hyperion.scode.org) Received: from hyperion.scode.org (cl-1361.ams-04.nl.sixxs.net [IPv6:2001:960:2:550::2]) by mx1.freebsd.org (Postfix) with ESMTP id 325828FC28 for ; Sun, 7 Dec 2008 11:35:12 +0000 (UTC) (envelope-from scode@hyperion.scode.org) Received: by hyperion.scode.org (Postfix, from userid 1001) id AD16B23C482; Sun, 7 Dec 2008 12:35:10 +0100 (CET) Date: Sun, 7 Dec 2008 12:35:10 +0100 From: Peter Schuller To: Marius =?iso-8859-1?Q?N=FCnnerich?= Message-ID: <20081207113509.GA19385@hyperion.scode.org> References: <20081117205526.GC1733@garage.freebsd.pl> <20081202203308.GA13818@hyperion.scode.org> <200812021254.21242.fjwcash@gmail.com> <20081202232924.GA19134@hyperion.scode.org> <31C70CBC-488A-4A9A-A642-37855E8F1DD1@lassitu.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Nq2Wo0NMKNjxTN9z" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: FreeBSD Current Subject: Re: HEADS UP: New ZFS in the tree. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Dec 2008 11:35:12 -0000 --Nq2Wo0NMKNjxTN9z Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable > While you are talking about it: Does anyone know if the fsync blocks > until the data is really stable on the device or if it simply returns > when ZIL is disabled? >=20 > In my understanding the topmost block would need to be written for the > "commit" to be on disk. My understanding is that disabling the ZIL *will* break the semantics of fsync(). The claim of "always consistent on disk" is not violated and is still maintained, since consistency refers to ZFS' internal consistency. The tuning guide someone posts a link to later in this thread has specific claims about this IIRC; such as NFS breaking (because fsync-on-close semantics mandated by NFS, among other things, will not be honored). --=20 / Peter Schuller PGP userID: 0xE9758B7D or 'Peter Schuller ' Key retrieval: Send an E-Mail to getpgpkey@scode.org E-Mail: peter.schuller@infidyne.com Web: http://www.scode.org --Nq2Wo0NMKNjxTN9z Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkk7tOwACgkQDNor2+l1i31wYQCeLkDSKHb1kfvO9ln6WRDD9vJP UFEAn1NzQ4lJadbEDsMmTh5ubK1krbYK =TciO -----END PGP SIGNATURE----- --Nq2Wo0NMKNjxTN9z-- From owner-freebsd-current@FreeBSD.ORG Sun Dec 7 12:17:24 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6461A1065670; Sun, 7 Dec 2008 12:17:24 +0000 (UTC) (envelope-from ken@mthelicon.com) Received: from hercules.mthelicon.com (hercules.mthelicon.com [IPv6:2001:49f0:2023::2]) by mx1.freebsd.org (Postfix) with ESMTP id 2D0A08FC14; Sun, 7 Dec 2008 12:17:24 +0000 (UTC) (envelope-from ken@mthelicon.com) Received: from feathers.peganest.com (78-33-110-3.static-adsl.entanet.co.uk [78.33.110.3] (may be forged)) (authenticated bits=0) by hercules.mthelicon.com (8.14.3/8.14.2) with ESMTP id mB7CHLVo024422 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Sun, 7 Dec 2008 12:17:23 GMT (envelope-from ken@mthelicon.com) From: Pegasus Mc Cleaft Organization: Feathers To: Doug Rabson Date: Sun, 7 Dec 2008 12:17:20 +0000 User-Agent: KMail/1.10.1 (FreeBSD/8.0-CURRENT; KDE/4.1.1; amd64; ; ) References: <200812070319.18461.ken@mthelicon.com> <66BF33BA-EC11-446F-9DE7-15395F293FE2@rabson.org> In-Reply-To: <66BF33BA-EC11-446F-9DE7-15395F293FE2@rabson.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200812071217.20500.ken@mthelicon.com> Cc: hackers@freebsd.org, current@freebsd.org Subject: Re: Problems with zfsboot loader if raidz present on any drive X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Dec 2008 12:17:24 -0000 On Sunday 07 December 2008 09:22:16 Doug Rabson wrote: > On 7 Dec 2008, at 03:19, Pegasus Mc Cleaft wrote: > > Hello Hackers, > > > > Recently and friend and I have been trying to get the new > > gptzfsboot working > > on our machines and ran into a interesting problem. > > > > Initially I was building the world without the environment variable > > LOADER_ZFS_SUPPORT=YES in the /etc/make.conf and this, of course, > > didnt work > > very well. Every time the machine booted, it would throw 2 lines > > after the > > pin-wheel and then reboot. I couldent read what the lines were it > > went so > > fast. > > > > My friend had a bit more luck and got his machine working OK with a > > single > > drive and later a mirror drive added. > > > > I added the environment variable and rebuilt everything and > > installed. This > > time, I could see the bios drives and a further 2 lines of ZFS > > something and a > > reboot... > > > > No matter what I tried, I couldent get the machine to boot up to a > > point > > where I could try and fix the problem, so I started pulling devices > > out and > > found the following: If there is a raidz pool on any drive (not > > necessarily > > the one that you are trying to boot from) the loader dies and > > reboots the > > machine. My friend, as an experiment created 3 gpt partitions (in > > addition to > > the single partition that he had been previously booted from) on his > > single > > drive and made a raidz pool for testing. His machine showed the same > > condition > > as mine, however he was able to capture the message before the machine > > rebooted: > > > > > > ZFS: can only boot from disk or mirror vdevs > > > > ZFS: inconsistent nvlist contents > > The zfsboot code in current doesn't support raidz or raidz2. I have > been working on adding that support but its not ready yet. The code > works in my test harness but crashes instantly when I put it in the > boot code :(. I should have time to finish debugging it soon. Hi Doug, In my haste to put a message to the group, I didnt do a very good job of explaining or give what platform I was working with. I set up a single disk pool with the gptzfsboot code on it as a boot drive. My idea was to have a single disk boot (and after it boots and I can kill the UFS drive I am currently booting from) convert it to a mirror. But I have 6 other drives in the machine that I have as a raidz for my /usr/home, et al. If the 6 raidz drives are present at boot time, the machine starts to cyclic reboot just after the pin-wheel. The machine I am working on is running FBSD8.0-Current as of midnight 7/12/2008 and the platform is AMD64. If I can help test in any way I would be more than happy to try, or provide any information necessary.. ~Peg From owner-freebsd-current@FreeBSD.ORG Sun Dec 7 12:41:19 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 71511106567A for ; Sun, 7 Dec 2008 12:41:19 +0000 (UTC) (envelope-from morganw@chemikals.org) Received: from warped.bluecherry.net (unknown [IPv6:2001:440:eeee:fffb::2]) by mx1.freebsd.org (Postfix) with ESMTP id 037678FC1C for ; Sun, 7 Dec 2008 12:41:19 +0000 (UTC) (envelope-from morganw@chemikals.org) Received: from volatile.chemikals.org (unknown [74.193.182.107]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by warped.bluecherry.net (Postfix) with ESMTPSA id A668684CC01A; Sun, 7 Dec 2008 06:41:16 -0600 (CST) Received: from localhost (morganw@localhost [127.0.0.1]) by volatile.chemikals.org (8.14.3/8.14.3) with ESMTP id mB7CfApe060403; Sun, 7 Dec 2008 06:41:11 -0600 (CST) (envelope-from morganw@chemikals.org) Date: Sun, 7 Dec 2008 06:41:10 -0600 (CST) From: Wes Morgan To: Peter Schuller In-Reply-To: <20081207113509.GA19385@hyperion.scode.org> Message-ID: References: <20081117205526.GC1733@garage.freebsd.pl> <20081202203308.GA13818@hyperion.scode.org> <200812021254.21242.fjwcash@gmail.com> <20081202232924.GA19134@hyperion.scode.org> <31C70CBC-488A-4A9A-A642-37855E8F1DD1@lassitu.de> <20081207113509.GA19385@hyperion.scode.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: =?ISO-8859-15?Q?Marius_N=FCnnerich?= , FreeBSD Current Subject: Re: HEADS UP: New ZFS in the tree. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Dec 2008 12:41:19 -0000 On Sun, 7 Dec 2008, Peter Schuller wrote: >> While you are talking about it: Does anyone know if the fsync blocks >> until the data is really stable on the device or if it simply returns >> when ZIL is disabled? >> >> In my understanding the topmost block would need to be written for the >> "commit" to be on disk. > > My understanding is that disabling the ZIL *will* break the semantics > of fsync(). > > The claim of "always consistent on disk" is not violated and is still > maintained, since consistency refers to ZFS' internal consistency. > > The tuning guide someone posts a link to later in this thread has > specific claims about this IIRC; such as NFS breaking (because > fsync-on-close semantics mandated by NFS, among other things, will not > be honored). And this would also apply to databases that rely on fsync() for ACID compliance, such as postgres, right? From owner-freebsd-current@FreeBSD.ORG Sun Dec 7 13:01:50 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3B24F106564A for ; Sun, 7 Dec 2008 13:01:50 +0000 (UTC) (envelope-from freebsdlists@bsdunix.ch) Received: from conversation.bsdunix.ch (ns1.bsdunix.ch [82.220.1.90]) by mx1.freebsd.org (Postfix) with ESMTP id E28BA8FC14 for ; Sun, 7 Dec 2008 13:01:49 +0000 (UTC) (envelope-from freebsdlists@bsdunix.ch) Received: from localhost (localhost [127.0.0.1]) by conversation.bsdunix.ch (Postfix) with ESMTP id 141535D67; Sun, 7 Dec 2008 14:01:48 +0100 (CET) X-Virus-Scanned: by amavisd-new at mail.bsdunix.ch Received: from conversation.bsdunix.ch ([127.0.0.1]) by localhost (conversation.bsdunix.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id JPA8lDxMGwEl; Sun, 7 Dec 2008 14:01:46 +0100 (CET) Received: from [192.168.1.101] (home.bsdunix.ch [82.220.17.23]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by conversation.bsdunix.ch (Postfix) with ESMTP id 3DC895D65; Sun, 7 Dec 2008 14:01:46 +0100 (CET) Message-Id: <9668C184-9534-4F0F-B633-C807DAD8ED95@bsdunix.ch> From: Thomas Vogt To: Wes Morgan In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Date: Sun, 7 Dec 2008 14:01:45 +0100 References: <20081117205526.GC1733@garage.freebsd.pl> <20081202203308.GA13818@hyperion.scode.org> <200812021254.21242.fjwcash@gmail.com> <20081202232924.GA19134@hyperion.scode.org> <31C70CBC-488A-4A9A-A642-37855E8F1DD1@lassitu.de> <20081207113509.GA19385@hyperion.scode.org> X-Mailer: Apple Mail (2.929.2) Cc: =?ISO-8859-1?Q?Marius_N=FCnnerich?= , FreeBSD Current , Peter Schuller Subject: Re: HEADS UP: New ZFS in the tree. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Dec 2008 13:01:50 -0000 Hello Am 07.12.2008 um 13:41 schrieb Wes Morgan: > On Sun, 7 Dec 2008, Peter Schuller wrote: > >>> While you are talking about it: Does anyone know if the fsync blocks >>> until the data is really stable on the device or if it simply >>> returns >>> when ZIL is disabled? >>> >>> In my understanding the topmost block would need to be written for >>> the >>> "commit" to be on disk. >> >> My understanding is that disabling the ZIL *will* break the semantics >> of fsync(). >> >> The claim of "always consistent on disk" is not violated and is still >> maintained, since consistency refers to ZFS' internal consistency. >> >> The tuning guide someone posts a link to later in this thread has >> specific claims about this IIRC; such as NFS breaking (because >> fsync-on-close semantics mandated by NFS, among other things, will >> not >> be honored). > > And this would also apply to databases that rely on fsync() for ACID > compliance, such as postgres, right? Yes. I do not recomment to disable ZIL in general. In my case it's just a workaround to get rid of deadlocks on my -CURRENT server (many rsync,http and ftp processes). It's also common to disable ZIL for better NFS performance but as Peter mentioned it has some drawbacks. Read: http://blogs.sun.com/erickustarz/entry/zil_disable it explains some drawbacks for fsync() and NFS. Quote: Disabling the ZIL can cause corruption for NFS clients in the case where a reply to the client is done before the server crashes, and the server crashes before the data is commited to stable storage. If you can't live with this, then don't turn off the ZIL. Regrads, Thomas Vogt From owner-freebsd-current@FreeBSD.ORG Sun Dec 7 14:56:29 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AFC791065675 for ; Sun, 7 Dec 2008 14:56:29 +0000 (UTC) (envelope-from zeiztm@gmail.com) Received: from mail-gx0-f19.google.com (mail-gx0-f19.google.com [209.85.217.19]) by mx1.freebsd.org (Postfix) with ESMTP id CF1728FC12 for ; Sun, 7 Dec 2008 14:56:28 +0000 (UTC) (envelope-from zeiztm@gmail.com) Received: by gxk12 with SMTP id 12so722105gxk.19 for ; Sun, 07 Dec 2008 06:56:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:mime-version:content-type; bh=/aWZQqwzd9FCjMHoLjS+x0I7D+9LXS20p0pJkBj/0K0=; b=ET9fLvHBevbvhrXJoVdvyLvjpHaTd6nWESlielvJPIf8IxOgs6TPmmzew8DttJtQfR x+lw8QMPs3b+9myIe8V9X8zt5y99s52GMzJQL1522YaSIqf2JGeZYBEBrQhPl5wN80Dq +b0+nrMHEUU69rzDTNBZt1k50oHivYqNJuzEI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=jDMJH30Ga1Tc1n/gx0TiEOuiQrjG/Q8DcBsi1FJfJ+EoZFIn0oOUoTuLAmTb7kD36v ogMRQKYa/FZA9Z8hDC3ZAOIRFUpFJhPtGyeABy9Odp9ZIeWO82exrvdoPD8MbCtG3X6s 13S4oNlYpcmlbrR8fZm1ZA+nSHBw2FjG0Eut8= Received: by 10.151.100.17 with SMTP id c17mr5879757ybm.204.1228660568643; Sun, 07 Dec 2008 06:36:08 -0800 (PST) Received: by 10.151.139.5 with HTTP; Sun, 7 Dec 2008 06:36:08 -0800 (PST) Message-ID: Date: Sun, 7 Dec 2008 09:36:08 -0500 From: "Greg Wang" To: current@freebsd.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_30250_20989668.1228660568621" X-Mailman-Approved-At: Sun, 07 Dec 2008 15:28:52 +0000 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: 8.0-CURRENT: No disks found! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Dec 2008 14:56:29 -0000 ------=_Part_30250_20989668.1228660568621 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Regular boot gives "fatal trap #12", "no acpi" and "safe mode" both give message "no disks found!" on sysinstall screen (partitioning). Both hashes are OK, burned @x4, 3 different CDs were tried. Asus P4S333c (SiS chipset 645/961), P4 2.4GHz, mem 768MB, ps2 keyboard, ps2 mouse, GeForce3-Ti200, monitor Viewsonic VA912b (1280x1024). 6.0, 6.2, 6.3, 6.4, 7.0 and 7.1-Beta2 - all run perfectly on that machine. Did 8.0 drop supporting SiS? Or what could be a reason? Another machine: Asus M3N78-VM, AthlonX2 (4450e) 2.3GHz, DDR2-800-4GB, NVidia chip, GeForce 8200 (onboard), ps2 keyboard, usb-mouse, SATA -HDD, SATA CD/DVD-W, all features - onboard. Monitor: SyncMaster2253bw. 8.0-CURRENT amd64 version. With CD1 could install only Base, Kernel and docs. Anything else including Xorg cannot be installed (error: no Index present). FTP: "there is no distribution on ftp://... do you want to try another ftp site?" pkg_add output: command not found. Again hashes are OK, 2 CDs were tried. Downloaded dvd.iso 3 times: first failed @97% (error: cannot copy from server), second download finished successfully but .iso file couldn't be found (mystery!), 3-rd download was OK. However I got the same problem with Index files on the DVD and "no distribution" with FTP using sysinstall. Fortunately dvd installed pkg_add and I managed to install X and then Gnome. Currently have problem with correct resolution (1680x1050) only 1280x1024 available as maximum. There is no data for ModeLine in xorg.0.log mentioned in handbook. Tried to force in xorg.conf: Section Monitor: HoryzSync 30.0-81.0 VertRefresh 50.0-76.0 Option "DPMS" that was accepted as well as DefaultDepth 24 under Screen section. Section Screen: Modes "1680x1050" Doesn't work. xorg.0.log output: "not used, no such name" ) xorg.0.log + - in the attachment. Installed KDE4 to try adjusting the resolution from there. Installed successfully, but then on boot screen: .../kdm: no such file or directory. The file /usr/local/bin/kdm - is there. In general 8.0-CURRENT-amd64 runs amazingly! Much better than Ubuntu8.10x64 and Suse11.1-beta5 I tried. Many thanks to developers! I realize that it's not even a beta and some features might not work, but maybe my info is useful. Thanks once more. ------=_Part_30250_20989668.1228660568621 Content-Type: application/octet-stream; name=Xorg.0.log.old Content-Transfer-Encoding: base64 X-Attachment-Id: f_fofshpyo1 Content-Disposition: attachment; filename=Xorg.0.log.old ClguT3JnIFggU2VydmVyIDEuNC4yClJlbGVhc2UgRGF0ZTogMTEgSnVuZSAyMDA4ClggUHJvdG9j b2wgVmVyc2lvbiAxMSwgUmV2aXNpb24gMApCdWlsZCBPcGVyYXRpbmcgU3lzdGVtOiBGcmVlQlNE IDguMC1DVVJSRU5UIGFtZDY0IApDdXJyZW50IE9wZXJhdGluZyBTeXN0ZW06IEZyZWVCU0Qga2Vy enBwMi5ST1NTR0kgOC4wLUNVUlJFTlQtMjAwODEyIEZyZWVCU0QgOC4wLUNVUlJFTlQtMjAwODEy ICMwOiBXZWQgRGVjICAzIDA2OjE0OjI4IFVUQyAyMDA4ICAgICByb290QG1hc29uLmNzZS5idWZm YWxvLmVkdTovdXNyL29iai91c3Ivc3JjL3N5cy9HRU5FUklDIGFtZDY0CkJ1aWxkIERhdGU6IDIz IEF1Z3VzdCAyMDA4ICAwMjoyNDoxMVBNCiAKCUJlZm9yZSByZXBvcnRpbmcgcHJvYmxlbXMsIGNo ZWNrIGh0dHA6Ly93aWtpLngub3JnCgl0byBtYWtlIHN1cmUgdGhhdCB5b3UgaGF2ZSB0aGUgbGF0 ZXN0IHZlcnNpb24uCk1vZHVsZSBMb2FkZXIgcHJlc2VudApNYXJrZXJzOiAoLS0pIHByb2JlZCwg KCoqKSBmcm9tIGNvbmZpZyBmaWxlLCAoPT0pIGRlZmF1bHQgc2V0dGluZywKCSgrKykgZnJvbSBj b21tYW5kIGxpbmUsICghISkgbm90aWNlLCAoSUkpIGluZm9ybWF0aW9uYWwsCgkoV1cpIHdhcm5p bmcsIChFRSkgZXJyb3IsIChOSSkgbm90IGltcGxlbWVudGVkLCAoPz8pIHVua25vd24uCig9PSkg TG9nIGZpbGU6ICIvdmFyL2xvZy9Yb3JnLjAubG9nIiwgVGltZTogU2F0IERlYyAgNiAyMjo0Nzow OCAyMDA4Cig9PSkgVXNpbmcgY29uZmlnIGZpbGU6ICIvZXRjL1gxMS94b3JnLmNvbmYiCig9PSkg U2VydmVyTGF5b3V0ICJYLm9yZyBDb25maWd1cmVkIgooKiopIHwtLT5TY3JlZW4gIlNjcmVlbjAi ICgwKQooKiopIHwgICB8LS0+TW9uaXRvciAiTW9uaXRvcjAiCigqKikgfCAgIHwtLT5EZXZpY2Ug IkNhcmQwIgooKiopIHwtLT5JbnB1dCBEZXZpY2UgIk1vdXNlMCIKKCoqKSB8LS0+SW5wdXQgRGV2 aWNlICJLZXlib2FyZDAiCig9PSkgQXV0b21hdGljYWxseSBhZGRpbmcgZGV2aWNlcwooPT0pIEF1 dG9tYXRpY2FsbHkgZW5hYmxpbmcgZGV2aWNlcwooPT0pIEluY2x1ZGluZyB0aGUgZGVmYXVsdCBm b250IHBhdGggL3Vzci9sb2NhbC9saWIvWDExL2ZvbnRzL21pc2MvLC91c3IvbG9jYWwvbGliL1gx MS9mb250cy9UVEYvLC91c3IvbG9jYWwvbGliL1gxMS9mb250cy9PVEYsL3Vzci9sb2NhbC9saWIv WDExL2ZvbnRzL1R5cGUxLywvdXNyL2xvY2FsL2xpYi9YMTEvZm9udHMvMTAwZHBpLywvdXNyL2xv Y2FsL2xpYi9YMTEvZm9udHMvNzVkcGkvLgooKiopIEZvbnRQYXRoIHNldCB0bzoKCS91c3IvbG9j YWwvbGliL1gxMS9mb250cy9taXNjLywKCS91c3IvbG9jYWwvbGliL1gxMS9mb250cy9UVEYvLAoJ L3Vzci9sb2NhbC9saWIvWDExL2ZvbnRzL09URiwKCS91c3IvbG9jYWwvbGliL1gxMS9mb250cy9U eXBlMS8sCgkvdXNyL2xvY2FsL2xpYi9YMTEvZm9udHMvMTAwZHBpLywKCS91c3IvbG9jYWwvbGli L1gxMS9mb250cy83NWRwaS8sCgkvdXNyL2xvY2FsL2xpYi9YMTEvZm9udHMvbWlzYy8sCgkvdXNy L2xvY2FsL2xpYi9YMTEvZm9udHMvVFRGLywKCS91c3IvbG9jYWwvbGliL1gxMS9mb250cy9PVEYs CgkvdXNyL2xvY2FsL2xpYi9YMTEvZm9udHMvVHlwZTEvLAoJL3Vzci9sb2NhbC9saWIvWDExL2Zv bnRzLzEwMGRwaS8sCgkvdXNyL2xvY2FsL2xpYi9YMTEvZm9udHMvNzVkcGkvCigqKikgUmdiUGF0 aCBzZXQgdG8gIi91c3IvbG9jYWwvc2hhcmUvWDExL3JnYiIKKCoqKSBNb2R1bGVQYXRoIHNldCB0 byAiL3Vzci9sb2NhbC9saWIveG9yZy9tb2R1bGVzIgooSUkpIExvYWRlciBtYWdpYzogMHg2ODJj ZTAKKElJKSBNb2R1bGUgQUJJIHZlcnNpb25zOgoJWC5PcmcgQU5TSSBDIEVtdWxhdGlvbjogMC4z CglYLk9yZyBWaWRlbyBEcml2ZXI6IDIuMAoJWC5PcmcgWElucHV0IGRyaXZlciA6IDIuMAoJWC5P cmcgU2VydmVyIEV4dGVuc2lvbiA6IDAuMwoJWC5PcmcgRm9udCBSZW5kZXJlciA6IDAuNQooSUkp IExvYWRlciBydW5uaW5nIG9uIGZyZWVic2QKKElJKSBMb2FkTW9kdWxlOiAicGNpZGF0YSIKKElJ KSBMb2FkaW5nIC91c3IvbG9jYWwvbGliL3hvcmcvbW9kdWxlcy8vbGlicGNpZGF0YS5zbwooSUkp IE1vZHVsZSBwY2lkYXRhOiB2ZW5kb3I9IlguT3JnIEZvdW5kYXRpb24iCgljb21waWxlZCBmb3Ig MS40LjIsIG1vZHVsZSB2ZXJzaW9uID0gMS4wLjAKCUFCSSBjbGFzczogWC5PcmcgVmlkZW8gRHJp dmVyLCB2ZXJzaW9uIDIuMAooLS0pIFVzaW5nIHN5c2NvbnMgZHJpdmVyIHdpdGggWCBzdXBwb3J0 ICh2ZXJzaW9uIDIuMCkKKC0tKSB1c2luZyBWVCBudW1iZXIgOQoKKFdXKSBPUyBkaWQgbm90IGNv dW50IFBDSSBkZXZpY2VzLCBndWVzc2luZyB3aWxkbHkKKElJKSBQQ0k6IFBDSSBzY2FuIChhbGwg dmFsdWVzIGFyZSBpbiBoZXgpCihJSSkgUENJOiAwMDowMDowOiBjaGlwIDEwZGUsMDc1NCBjYXJk IDEwNDMsODJmMiByZXYgYTIgY2xhc3MgMDUsMDAsMDAgaGRyIDAwCihJSSkgUENJOiAwMDowMTow OiBjaGlwIDEwZGUsMDc1YyBjYXJkIDEwNDMsODJmMiByZXYgYTIgY2xhc3MgMDYsMDEsMDAgaGRy IDgwCihJSSkgUENJOiAwMDowMToxOiBjaGlwIDEwZGUsMDc1MiBjYXJkIDEwNDMsODJmMiByZXYg YTEgY2xhc3MgMGMsMDUsMDAgaGRyIDgwCihJSSkgUENJOiAwMDowMToyOiBjaGlwIDEwZGUsMDc1 MSBjYXJkIDEwNDMsODJmMiByZXYgYTEgY2xhc3MgMDUsMDAsMDAgaGRyIDgwCihJSSkgUENJOiAw MDowMTozOiBjaGlwIDEwZGUsMDc1MyBjYXJkIDEwNDMsODJmMiByZXYgYTIgY2xhc3MgMGIsNDAs MDAgaGRyIDgwCihJSSkgUENJOiAwMDowMTo0OiBjaGlwIDEwZGUsMDU2OCBjYXJkIDEwNDMsODJm MiByZXYgYTEgY2xhc3MgMDUsMDAsMDAgaGRyIDgwCihJSSkgUENJOiAwMDowMjowOiBjaGlwIDEw ZGUsMDc3YiBjYXJkIDEwNDMsODJmMiByZXYgYTEgY2xhc3MgMGMsMDMsMTAgaGRyIDgwCihJSSkg UENJOiAwMDowMjoxOiBjaGlwIDEwZGUsMDc3YyBjYXJkIDEwNDMsODJmMiByZXYgYTEgY2xhc3Mg MGMsMDMsMjAgaGRyIDgwCihJSSkgUENJOiAwMDowNDowOiBjaGlwIDEwZGUsMDc3ZCBjYXJkIDEw NDMsODJmMiByZXYgYTEgY2xhc3MgMGMsMDMsMTAgaGRyIDgwCihJSSkgUENJOiAwMDowNDoxOiBj aGlwIDEwZGUsMDc3ZSBjYXJkIDEwNDMsODJmMiByZXYgYTEgY2xhc3MgMGMsMDMsMjAgaGRyIDgw CihJSSkgUENJOiAwMDowNzowOiBjaGlwIDEwZGUsMDc3NCBjYXJkIDEwNDMsODM0NSByZXYgYTEg Y2xhc3MgMDQsMDMsMDAgaGRyIDAwCihJSSkgUENJOiAwMDowODowOiBjaGlwIDEwZGUsMDc1YSBj YXJkIDAwMDAsMDAwMCByZXYgYTEgY2xhc3MgMDYsMDQsMDEgaGRyIDAxCihJSSkgUENJOiAwMDow OTowOiBjaGlwIDEwZGUsMGFkMCBjYXJkIDEwNDMsODJmMiByZXYgYTIgY2xhc3MgMDEsMDEsODUg aGRyIDAwCihJSSkgUENJOiAwMDowYTowOiBjaGlwIDEwZGUsMDc2MCBjYXJkIDEwNDMsODJmMiBy ZXYgYTIgY2xhc3MgMDIsMDAsMDAgaGRyIDAwCihJSSkgUENJOiAwMDowYjowOiBjaGlwIDEwZGUs MDU2OSBjYXJkIDAwMDAsMDAwMCByZXYgYTEgY2xhc3MgMDYsMDQsMDAgaGRyIDAxCihJSSkgUENJ OiAwMDoxMDowOiBjaGlwIDEwZGUsMDc3OCBjYXJkIDAwMDAsMDAwMCByZXYgYTEgY2xhc3MgMDYs MDQsMDAgaGRyIDAxCihJSSkgUENJOiAwMDoxMjowOiBjaGlwIDEwZGUsMDc1YiBjYXJkIDAwMDAs MDAwMCByZXYgYTEgY2xhc3MgMDYsMDQsMDAgaGRyIDAxCihJSSkgUENJOiAwMDoxODowOiBjaGlw IDEwMjIsMTEwMCBjYXJkIDAwMDAsMDAwMCByZXYgMDAgY2xhc3MgMDYsMDAsMDAgaGRyIDgwCihJ SSkgUENJOiAwMDoxODoxOiBjaGlwIDEwMjIsMTEwMSBjYXJkIDAwMDAsMDAwMCByZXYgMDAgY2xh c3MgMDYsMDAsMDAgaGRyIDgwCihJSSkgUENJOiAwMDoxODoyOiBjaGlwIDEwMjIsMTEwMiBjYXJk IDAwMDAsMDAwMCByZXYgMDAgY2xhc3MgMDYsMDAsMDAgaGRyIDgwCihJSSkgUENJOiAwMDoxODoz OiBjaGlwIDEwMjIsMTEwMyBjYXJkIDAwMDAsMDAwMCByZXYgMDAgY2xhc3MgMDYsMDAsMDAgaGRy IDgwCihJSSkgUENJOiAwMjowMDowOiBjaGlwIDEwZGUsMDg0OSBjYXJkIDEwNDMsODJmMiByZXYg YTIgY2xhc3MgMDMsMDAsMDAgaGRyIDAwCihJSSkgUENJOiBFbmQgb2YgUENJIHNjYW4KKElJKSBQ Q0ktdG8tSVNBIGJyaWRnZToKKElJKSBCdXMgLTE6IGJyaWRnZSBpcyBhdCAoMDoxOjApLCAoMCwt MSwtMSksIEJDVFJMOiAweDAwMDggKFZHQV9FTiBpcyBzZXQpCihJSSkgU3VidHJhY3RpdmUgUENJ LXRvLVBDSSBicmlkZ2U6CihJSSkgQnVzIDE6IGJyaWRnZSBpcyBhdCAoMDo4OjApLCAoMCwxLDEp LCBCQ1RSTDogMHgwMjAyIChWR0FfRU4gaXMgY2xlYXJlZCkKKElJKSBQQ0ktdG8tUENJIGJyaWRn ZToKKElJKSBCdXMgMjogYnJpZGdlIGlzIGF0ICgwOjExOjApLCAoMCwyLDIpLCBCQ1RSTDogMHgw MDFhIChWR0FfRU4gaXMgc2V0KQooSUkpIEJ1cyAyIEkvTyByYW5nZToKCVswXSAtMQkwCTB4MDAw MGUwMDAgLSAweDAwMDBlZmZmICgweDEwMDApIElYW0JdCihJSSkgQnVzIDIgbm9uLXByZWZldGNo YWJsZSBtZW1vcnkgcmFuZ2U6CglbMF0gLTEJMAkweGZkMDAwMDAwIC0gMHhmZWJmZmZmZiAoMHgx YzAwMDAwKSBNWFtCXQooSUkpIEJ1cyAyIHByZWZldGNoYWJsZSBtZW1vcnkgcmFuZ2U6CglbMF0g LTEJMAkweGYwMDAwMDAwIC0gMHhmYmZmZmZmZiAoMHhjMDAwMDAwKSBNWFtCXQooSUkpIFBDSS10 by1QQ0kgYnJpZGdlOgooSUkpIEJ1cyAzOiBicmlkZ2UgaXMgYXQgKDA6MTY6MCksICgwLDMsMyks IEJDVFJMOiAweDAwMDIgKFZHQV9FTiBpcyBjbGVhcmVkKQooSUkpIFBDSS10by1QQ0kgYnJpZGdl OgooSUkpIEJ1cyA0OiBicmlkZ2UgaXMgYXQgKDA6MTg6MCksICgwLDQsNCksIEJDVFJMOiAweDAw MDIgKFZHQV9FTiBpcyBjbGVhcmVkKQooSUkpIEhvc3QtdG8tUENJIGJyaWRnZToKKElJKSBCdXMg MDogYnJpZGdlIGlzIGF0ICgwOjI0OjApLCAoMCwwLDQpLCBCQ1RSTDogMHgwMDA4IChWR0FfRU4g aXMgc2V0KQooSUkpIEJ1cyAwIEkvTyByYW5nZToKCVswXSAtMQkwCTB4MDAwMDAwMDAgLSAweDAw MDBmZmZmICgweDEwMDAwKSBJWFtCXQooSUkpIEJ1cyAwIG5vbi1wcmVmZXRjaGFibGUgbWVtb3J5 IHJhbmdlOgoJWzBdIC0xCTAJMHgwMDAwMDAwMCAtIDB4ZmZmZmZmZmYgKDB4MTAwMDAwMDAwKSBN WFtCXQooSUkpIEJ1cyAwIHByZWZldGNoYWJsZSBtZW1vcnkgcmFuZ2U6CglbMF0gLTEJMAkweDAw MDAwMDAwIC0gMHhmZmZmZmZmZiAoMHgxMDAwMDAwMDApIE1YW0JdCigtLSkgUENJOiooMjowOjAp IG5WaWRpYSBDb3Jwb3JhdGlvbiB1bmtub3duIGNoaXBzZXQgKDB4MDg0OSkgcmV2IDE2MiwgTWVt IEAgMHhmZDAwMDAwMC8yNCwgMHhmMDAwMDAwMC8yNywgMHhmYTAwMDAwMC8yNSwgSS9PIEAgMHhl YzAwLzcsIEJJT1MgQCAweGZlYmUwMDAwLzE3CihJSSkgQWRkcmVzc2FibGUgYnVzIHJlc291cmNl IHJhbmdlcyBhcmUKCVswXSAtMQkwCTB4MDAwMDAwMDAgLSAweGZmZmZmZmZmICgweDEwMDAwMDAw MCkgTVhbQl0KCVsxXSAtMQkwCTB4MDAwMDAwMDAgLSAweDAwMDBmZmZmICgweDEwMDAwKSBJWFtC XQooSUkpIE9TLXJlcG9ydGVkIHJlc291cmNlIHJhbmdlczoKCVswXSAtMQkwCTB4ZmZmZmZmZmYg LSAweGZmZmZmZmZmICgweDEpIE1YW0JdCglbMV0gLTEJMAkweDAwMGYwMDAwIC0gMHgwMDBmZmZm ZiAoMHgxMDAwMCkgTVhbQl0KCVsyXSAtMQkwCTB4MDAwYzAwMDAgLSAweDAwMGVmZmZmICgweDMw MDAwKSBNWFtCXQoJWzNdIC0xCTAJMHgwMDAwMDAwMCAtIDB4MDAwOWZmZmYgKDB4YTAwMDApIE1Y W0JdCglbNF0gLTEJMAkweDAwMDBmZmZmIC0gMHgwMDAwZmZmZiAoMHgxKSBJWFtCXQoJWzVdIC0x CTAJMHgwMDAwMDAwMCAtIDB4MDAwMDAwMDAgKDB4MSkgSVhbQl0KKElJKSBBY3RpdmUgUENJIHJl c291cmNlIHJhbmdlczoKCVswXSAtMQkwCTB4ZmNmN2YwMDAgLSAweGZjZjdmZmZmICgweDEwMDAp IE1YW0JdRQoJWzFdIC0xCTAJMHhmY2Y3ZjQwMCAtIDB4ZmNmN2Y3ZmYgKDB4NDAwKSBNWFtCXUUK CVsyXSAtMQkwCTB4ZmNmN2MwMDAgLSAweGZjZjdmZmZmICgweDQwMDApIE1YW0JdRQoJWzNdIC0x CTAJMHhmY2Y3NjAwMCAtIDB4ZmNmNzdmZmYgKDB4MjAwMCkgTVhbQl1FCglbNF0gLTEJMAkweGZj Zjc4MDAwIC0gMHhmY2Y3ZmZmZiAoMHg4MDAwKSBNWFtCXUUKCVs1XSAtMQkwCTB4ZmNmN2Y4MDAg LSAweGZjZjdmZmZmICgweDgwMCkgTVhbQl1FCglbNl0gLTEJMAkweGZjZjdkMDAwIC0gMHhmY2Y3 ZGZmZiAoMHgxMDAwKSBNWFtCXUUKCVs3XSAtMQkwCTB4ZmNmN2ZjMDAgLSAweGZjZjdmZmZmICgw eDQwMCkgTVhbQl1FCglbOF0gLTEJMAkweGZjZjdlMDAwIC0gMHhmY2Y3ZmZmZiAoMHgyMDAwKSBN WFtCXUUKCVs5XSAtMQkwCTB4ZmViZTAwMDAgLSAweGZlYmZmZmZmICgweDIwMDAwKSBNWFtCXShC KQoJWzEwXSAtMQkwCTB4ZmEwMDAwMDAgLSAweGZiZmZmZmZmICgweDIwMDAwMDApIE1YW0JdKEIp CglbMTFdIC0xCTAJMHhmMDAwMDAwMCAtIDB4ZjdmZmZmZmYgKDB4ODAwMDAwMCkgTVhbQl0oQikK CVsxMl0gLTEJMAkweGZkMDAwMDAwIC0gMHhmZGZmZmZmZiAoMHgxMDAwMDAwKSBNWFtCXShCKQoJ WzEzXSAtMQkwCTB4ZmNmODAwMDAgLSAweGZjZmZmZmZmICgweDgwMDAwKSBNWFtCXUUKCVsxNF0g LTEJMAkweDAwMDBjODgwIC0gMHgwMDAwYzhmZiAoMHg4MCkgSVhbQl1FCglbMTVdIC0xCTAJMHgw MDAwY2MwMCAtIDB4MDAwMGNjZmYgKDB4MTAwKSBJWFtCXUUKCVsxNl0gLTEJMAkweDAwMDBkMDAw IC0gMHgwMDAwZDBmZiAoMHgxMDApIElYW0JdRQoJWzE3XSAtMQkwCTB4MDAwMGQwODAgLSAweDAw MDBkMGZmICgweDgwKSBJWFtCXUUKCVsxOF0gLTEJMAkweDAwMDBkNDAwIC0gMHgwMDAwZDRmZiAo MHgxMDApIElYW0JdRQoJWzE5XSAtMQkwCTB4MDAwMGQ0ODAgLSAweDAwMDBkNGZmICgweDgwKSBJ WFtCXUUKCVsyMF0gLTEJMAkweDAwMDAwNzAwIC0gMHgwMDAwMDdmZiAoMHgxMDApIElYW0JdRQoJ WzIxXSAtMQkwCTB4MDAwMDA2MDAgLSAweDAwMDAwNmZmICgweDEwMCkgSVhbQl1FCglbMjJdIC0x CTAJMHgwMDAwMGUwMCAtIDB4MDAwMDBlZmYgKDB4MTAwKSBJWFtCXUUKCVsyM10gLTEJMAkweDAw MDAwOTAwIC0gMHgwMDAwMDlmZiAoMHgxMDApIElYW0JdRQoJWzI0XSAtMQkwCTB4MDAwMGVjMDAg LSAweDAwMDBlYzdmICgweDgwKSBJWFtCXShCKQooSUkpIFBDSSBNZW1vcnkgcmVzb3VyY2Ugb3Zl cmxhcCByZWR1Y2VkIDB4ZmNmN2YwMDAgZnJvbSAweGZjZjdmZmZmIHRvIDB4ZmNmN2YzZmYKKElJ KSBQQ0kgTWVtb3J5IHJlc291cmNlIG92ZXJsYXAgcmVkdWNlZCAweGZjZjdjMDAwIGZyb20gMHhm Y2Y3ZmZmZiB0byAweGZjZjdjZmZmCihJSSkgUENJIEkvTyByZXNvdXJjZSBvdmVybGFwIHJlZHVj ZWQgMHgwMDAwZDAwMCBmcm9tIDB4MDAwMGQwZmYgdG8gMHgwMDAwZDA3ZgooSUkpIFBDSSBJL08g cmVzb3VyY2Ugb3ZlcmxhcCByZWR1Y2VkIDB4MDAwMGQ0MDAgZnJvbSAweDAwMDBkNGZmIHRvIDB4 MDAwMGQ0N2YKKElJKSBQQ0kgTWVtb3J5IHJlc291cmNlIG92ZXJsYXAgcmVkdWNlZCAweGZjZjc4 MDAwIGZyb20gMHhmY2Y3ZmZmZiB0byAweGZjZjdiZmZmCihJSSkgUENJIE1lbW9yeSByZXNvdXJj ZSBvdmVybGFwIHJlZHVjZWQgMHhmY2Y3ZjgwMCBmcm9tIDB4ZmNmN2ZmZmYgdG8gMHhmY2Y3ZmJm ZgooSUkpIFBDSSBNZW1vcnkgcmVzb3VyY2Ugb3ZlcmxhcCByZWR1Y2VkIDB4ZmNmN2UwMDAgZnJv bSAweGZjZjdmZmZmIHRvIDB4ZmNmN2VmZmYKKElJKSBBY3RpdmUgUENJIHJlc291cmNlIHJhbmdl cyBhZnRlciByZW1vdmluZyBvdmVybGFwczoKCVswXSAtMQkwCTB4ZmNmN2YwMDAgLSAweGZjZjdm M2ZmICgweDQwMCkgTVhbQl1FCglbMV0gLTEJMAkweGZjZjdmNDAwIC0gMHhmY2Y3ZjdmZiAoMHg0 MDApIE1YW0JdRQoJWzJdIC0xCTAJMHhmY2Y3YzAwMCAtIDB4ZmNmN2NmZmYgKDB4MTAwMCkgTVhb Ql1FCglbM10gLTEJMAkweGZjZjc2MDAwIC0gMHhmY2Y3N2ZmZiAoMHgyMDAwKSBNWFtCXUUKCVs0 XSAtMQkwCTB4ZmNmNzgwMDAgLSAweGZjZjdiZmZmICgweDQwMDApIE1YW0JdRQoJWzVdIC0xCTAJ MHhmY2Y3ZjgwMCAtIDB4ZmNmN2ZiZmYgKDB4NDAwKSBNWFtCXUUKCVs2XSAtMQkwCTB4ZmNmN2Qw MDAgLSAweGZjZjdkZmZmICgweDEwMDApIE1YW0JdRQoJWzddIC0xCTAJMHhmY2Y3ZmMwMCAtIDB4 ZmNmN2ZmZmYgKDB4NDAwKSBNWFtCXUUKCVs4XSAtMQkwCTB4ZmNmN2UwMDAgLSAweGZjZjdlZmZm ICgweDEwMDApIE1YW0JdRQoJWzldIC0xCTAJMHhmZWJlMDAwMCAtIDB4ZmViZmZmZmYgKDB4MjAw MDApIE1YW0JdKEIpCglbMTBdIC0xCTAJMHhmYTAwMDAwMCAtIDB4ZmJmZmZmZmYgKDB4MjAwMDAw MCkgTVhbQl0oQikKCVsxMV0gLTEJMAkweGYwMDAwMDAwIC0gMHhmN2ZmZmZmZiAoMHg4MDAwMDAw KSBNWFtCXShCKQoJWzEyXSAtMQkwCTB4ZmQwMDAwMDAgLSAweGZkZmZmZmZmICgweDEwMDAwMDAp IE1YW0JdKEIpCglbMTNdIC0xCTAJMHhmY2Y4MDAwMCAtIDB4ZmNmZmZmZmYgKDB4ODAwMDApIE1Y W0JdRQoJWzE0XSAtMQkwCTB4MDAwMGM4ODAgLSAweDAwMDBjOGZmICgweDgwKSBJWFtCXUUKCVsx NV0gLTEJMAkweDAwMDBjYzAwIC0gMHgwMDAwY2NmZiAoMHgxMDApIElYW0JdRQoJWzE2XSAtMQkw CTB4MDAwMGQwMDAgLSAweDAwMDBkMDdmICgweDgwKSBJWFtCXUUKCVsxN10gLTEJMAkweDAwMDBk MDgwIC0gMHgwMDAwZDBmZiAoMHg4MCkgSVhbQl1FCglbMThdIC0xCTAJMHgwMDAwZDQwMCAtIDB4 MDAwMGQ0N2YgKDB4ODApIElYW0JdRQoJWzE5XSAtMQkwCTB4MDAwMGQ0ODAgLSAweDAwMDBkNGZm ICgweDgwKSBJWFtCXUUKCVsyMF0gLTEJMAkweDAwMDAwNzAwIC0gMHgwMDAwMDdmZiAoMHgxMDAp IElYW0JdRQoJWzIxXSAtMQkwCTB4MDAwMDA2MDAgLSAweDAwMDAwNmZmICgweDEwMCkgSVhbQl1F CglbMjJdIC0xCTAJMHgwMDAwMGUwMCAtIDB4MDAwMDBlZmYgKDB4MTAwKSBJWFtCXUUKCVsyM10g LTEJMAkweDAwMDAwOTAwIC0gMHgwMDAwMDlmZiAoMHgxMDApIElYW0JdRQoJWzI0XSAtMQkwCTB4 MDAwMGVjMDAgLSAweDAwMDBlYzdmICgweDgwKSBJWFtCXShCKQooSUkpIE9TLXJlcG9ydGVkIHJl c291cmNlIHJhbmdlcyBhZnRlciByZW1vdmluZyBvdmVybGFwcyB3aXRoIFBDSToKCVswXSAtMQkw CTB4ZmZmZmZmZmYgLSAweGZmZmZmZmZmICgweDEpIE1YW0JdCglbMV0gLTEJMAkweDAwMGYwMDAw IC0gMHgwMDBmZmZmZiAoMHgxMDAwMCkgTVhbQl0KCVsyXSAtMQkwCTB4MDAwYzAwMDAgLSAweDAw MGVmZmZmICgweDMwMDAwKSBNWFtCXQoJWzNdIC0xCTAJMHgwMDAwMDAwMCAtIDB4MDAwOWZmZmYg KDB4YTAwMDApIE1YW0JdCglbNF0gLTEJMAkweDAwMDBmZmZmIC0gMHgwMDAwZmZmZiAoMHgxKSBJ WFtCXQoJWzVdIC0xCTAJMHgwMDAwMDAwMCAtIDB4MDAwMDAwMDAgKDB4MSkgSVhbQl0KKElJKSBB bGwgc3lzdGVtIHJlc291cmNlIHJhbmdlczoKCVswXSAtMQkwCTB4ZmZmZmZmZmYgLSAweGZmZmZm ZmZmICgweDEpIE1YW0JdCglbMV0gLTEJMAkweDAwMGYwMDAwIC0gMHgwMDBmZmZmZiAoMHgxMDAw MCkgTVhbQl0KCVsyXSAtMQkwCTB4MDAwYzAwMDAgLSAweDAwMGVmZmZmICgweDMwMDAwKSBNWFtC XQoJWzNdIC0xCTAJMHgwMDAwMDAwMCAtIDB4MDAwOWZmZmYgKDB4YTAwMDApIE1YW0JdCglbNF0g LTEJMAkweGZjZjdmMDAwIC0gMHhmY2Y3ZjNmZiAoMHg0MDApIE1YW0JdRQoJWzVdIC0xCTAJMHhm Y2Y3ZjQwMCAtIDB4ZmNmN2Y3ZmYgKDB4NDAwKSBNWFtCXUUKCVs2XSAtMQkwCTB4ZmNmN2MwMDAg LSAweGZjZjdjZmZmICgweDEwMDApIE1YW0JdRQoJWzddIC0xCTAJMHhmY2Y3NjAwMCAtIDB4ZmNm NzdmZmYgKDB4MjAwMCkgTVhbQl1FCglbOF0gLTEJMAkweGZjZjc4MDAwIC0gMHhmY2Y3YmZmZiAo MHg0MDAwKSBNWFtCXUUKCVs5XSAtMQkwCTB4ZmNmN2Y4MDAgLSAweGZjZjdmYmZmICgweDQwMCkg TVhbQl1FCglbMTBdIC0xCTAJMHhmY2Y3ZDAwMCAtIDB4ZmNmN2RmZmYgKDB4MTAwMCkgTVhbQl1F CglbMTFdIC0xCTAJMHhmY2Y3ZmMwMCAtIDB4ZmNmN2ZmZmYgKDB4NDAwKSBNWFtCXUUKCVsxMl0g LTEJMAkweGZjZjdlMDAwIC0gMHhmY2Y3ZWZmZiAoMHgxMDAwKSBNWFtCXUUKCVsxM10gLTEJMAkw eGZlYmUwMDAwIC0gMHhmZWJmZmZmZiAoMHgyMDAwMCkgTVhbQl0oQikKCVsxNF0gLTEJMAkweGZh MDAwMDAwIC0gMHhmYmZmZmZmZiAoMHgyMDAwMDAwKSBNWFtCXShCKQoJWzE1XSAtMQkwCTB4ZjAw MDAwMDAgLSAweGY3ZmZmZmZmICgweDgwMDAwMDApIE1YW0JdKEIpCglbMTZdIC0xCTAJMHhmZDAw MDAwMCAtIDB4ZmRmZmZmZmYgKDB4MTAwMDAwMCkgTVhbQl0oQikKCVsxN10gLTEJMAkweGZjZjgw MDAwIC0gMHhmY2ZmZmZmZiAoMHg4MDAwMCkgTVhbQl1FCglbMThdIC0xCTAJMHgwMDAwZmZmZiAt IDB4MDAwMGZmZmYgKDB4MSkgSVhbQl0KCVsxOV0gLTEJMAkweDAwMDAwMDAwIC0gMHgwMDAwMDAw MCAoMHgxKSBJWFtCXQoJWzIwXSAtMQkwCTB4MDAwMGM4ODAgLSAweDAwMDBjOGZmICgweDgwKSBJ WFtCXUUKCVsyMV0gLTEJMAkweDAwMDBjYzAwIC0gMHgwMDAwY2NmZiAoMHgxMDApIElYW0JdRQoJ WzIyXSAtMQkwCTB4MDAwMGQwMDAgLSAweDAwMDBkMDdmICgweDgwKSBJWFtCXUUKCVsyM10gLTEJ MAkweDAwMDBkMDgwIC0gMHgwMDAwZDBmZiAoMHg4MCkgSVhbQl1FCglbMjRdIC0xCTAJMHgwMDAw ZDQwMCAtIDB4MDAwMGQ0N2YgKDB4ODApIElYW0JdRQoJWzI1XSAtMQkwCTB4MDAwMGQ0ODAgLSAw eDAwMDBkNGZmICgweDgwKSBJWFtCXUUKCVsyNl0gLTEJMAkweDAwMDAwNzAwIC0gMHgwMDAwMDdm ZiAoMHgxMDApIElYW0JdRQoJWzI3XSAtMQkwCTB4MDAwMDA2MDAgLSAweDAwMDAwNmZmICgweDEw MCkgSVhbQl1FCglbMjhdIC0xCTAJMHgwMDAwMGUwMCAtIDB4MDAwMDBlZmYgKDB4MTAwKSBJWFtC XUUKCVsyOV0gLTEJMAkweDAwMDAwOTAwIC0gMHgwMDAwMDlmZiAoMHgxMDApIElYW0JdRQoJWzMw XSAtMQkwCTB4MDAwMGVjMDAgLSAweDAwMDBlYzdmICgweDgwKSBJWFtCXShCKQooSUkpICJleHRt b2QiIHdpbGwgYmUgbG9hZGVkLiBUaGlzIHdhcyBlbmFibGVkIGJ5IGRlZmF1bHQgYW5kIGFsc28g c3BlY2lmaWVkIGluIHRoZSBjb25maWcgZmlsZS4KKElJKSAiZGJlIiB3aWxsIGJlIGxvYWRlZC4g VGhpcyB3YXMgZW5hYmxlZCBieSBkZWZhdWx0IGFuZCBhbHNvIHNwZWNpZmllZCBpbiB0aGUgY29u ZmlnIGZpbGUuCihJSSkgImdseCIgd2lsbCBiZSBsb2FkZWQuIFRoaXMgd2FzIGVuYWJsZWQgYnkg ZGVmYXVsdCBhbmQgYWxzbyBzcGVjaWZpZWQgaW4gdGhlIGNvbmZpZyBmaWxlLgooSUkpICJmcmVl dHlwZSIgd2lsbCBiZSBsb2FkZWQuIFRoaXMgd2FzIGVuYWJsZWQgYnkgZGVmYXVsdCBhbmQgYWxz byBzcGVjaWZpZWQgaW4gdGhlIGNvbmZpZyBmaWxlLgooSUkpICJ0eXBlMSIgd2lsbCBiZSBsb2Fk ZWQuIFRoaXMgd2FzIGVuYWJsZWQgYnkgZGVmYXVsdCBhbmQgYWxzbyBzcGVjaWZpZWQgaW4gdGhl IGNvbmZpZyBmaWxlLgooSUkpICJyZWNvcmQiIHdpbGwgYmUgbG9hZGVkLiBUaGlzIHdhcyBlbmFi bGVkIGJ5IGRlZmF1bHQgYW5kIGFsc28gc3BlY2lmaWVkIGluIHRoZSBjb25maWcgZmlsZS4KKElJ KSAiZHJpIiB3aWxsIGJlIGxvYWRlZC4gVGhpcyB3YXMgZW5hYmxlZCBieSBkZWZhdWx0IGFuZCBh bHNvIHNwZWNpZmllZCBpbiB0aGUgY29uZmlnIGZpbGUuCihJSSkgTG9hZE1vZHVsZTogImRiZSIK KElJKSBMb2FkaW5nIC91c3IvbG9jYWwvbGliL3hvcmcvbW9kdWxlcy9leHRlbnNpb25zLy9saWJk YmUuc28KKElJKSBNb2R1bGUgZGJlOiB2ZW5kb3I9IlguT3JnIEZvdW5kYXRpb24iCgljb21waWxl ZCBmb3IgMS40LjIsIG1vZHVsZSB2ZXJzaW9uID0gMS4wLjAKCU1vZHVsZSBjbGFzczogWC5Pcmcg U2VydmVyIEV4dGVuc2lvbgoJQUJJIGNsYXNzOiBYLk9yZyBTZXJ2ZXIgRXh0ZW5zaW9uLCB2ZXJz aW9uIDAuMwooSUkpIExvYWRpbmcgZXh0ZW5zaW9uIERPVUJMRS1CVUZGRVIKKElJKSBMb2FkTW9k dWxlOiAiZHJpIgooSUkpIExvYWRpbmcgL3Vzci9sb2NhbC9saWIveG9yZy9tb2R1bGVzL2V4dGVu c2lvbnMvL2xpYmRyaS5zbwooSUkpIE1vZHVsZSBkcmk6IHZlbmRvcj0iWC5PcmcgRm91bmRhdGlv biIKCWNvbXBpbGVkIGZvciAxLjQuMiwgbW9kdWxlIHZlcnNpb24gPSAxLjAuMAoJQUJJIGNsYXNz OiBYLk9yZyBTZXJ2ZXIgRXh0ZW5zaW9uLCB2ZXJzaW9uIDAuMwooSUkpIExvYWRpbmcgZXh0ZW5z aW9uIFhGcmVlODYtRFJJCihJSSkgTG9hZE1vZHVsZTogImV4dG1vZCIKKElJKSBMb2FkaW5nIC91 c3IvbG9jYWwvbGliL3hvcmcvbW9kdWxlcy9leHRlbnNpb25zLy9saWJleHRtb2Quc28KKElJKSBN b2R1bGUgZXh0bW9kOiB2ZW5kb3I9IlguT3JnIEZvdW5kYXRpb24iCgljb21waWxlZCBmb3IgMS40 LjIsIG1vZHVsZSB2ZXJzaW9uID0gMS4wLjAKCU1vZHVsZSBjbGFzczogWC5PcmcgU2VydmVyIEV4 dGVuc2lvbgoJQUJJIGNsYXNzOiBYLk9yZyBTZXJ2ZXIgRXh0ZW5zaW9uLCB2ZXJzaW9uIDAuMwoo SUkpIExvYWRpbmcgZXh0ZW5zaW9uIFNIQVBFCihJSSkgTG9hZGluZyBleHRlbnNpb24gTUlULVNV TkRSWS1OT05TVEFOREFSRAooSUkpIExvYWRpbmcgZXh0ZW5zaW9uIEJJRy1SRVFVRVNUUwooSUkp IExvYWRpbmcgZXh0ZW5zaW9uIFNZTkMKKElJKSBMb2FkaW5nIGV4dGVuc2lvbiBNSVQtU0NSRUVO LVNBVkVSCihJSSkgTG9hZGluZyBleHRlbnNpb24gWEMtTUlTQwooSUkpIExvYWRpbmcgZXh0ZW5z aW9uIFhGcmVlODYtVmlkTW9kZUV4dGVuc2lvbgooSUkpIExvYWRpbmcgZXh0ZW5zaW9uIFhGcmVl ODYtTWlzYwooSUkpIExvYWRpbmcgZXh0ZW5zaW9uIFhGcmVlODYtREdBCihJSSkgTG9hZGluZyBl eHRlbnNpb24gRFBNUwooSUkpIExvYWRpbmcgZXh0ZW5zaW9uIFRPRy1DVVAKKElJKSBMb2FkaW5n IGV4dGVuc2lvbiBFeHRlbmRlZC1WaXN1YWwtSW5mb3JtYXRpb24KKElJKSBMb2FkaW5nIGV4dGVu c2lvbiBYVmlkZW8KKElJKSBMb2FkaW5nIGV4dGVuc2lvbiBYVmlkZW8tTW90aW9uQ29tcGVuc2F0 aW9uCihJSSkgTG9hZGluZyBleHRlbnNpb24gWC1SZXNvdXJjZQooSUkpIExvYWRNb2R1bGU6ICJn bHgiCihJSSkgTG9hZGluZyAvdXNyL2xvY2FsL2xpYi94b3JnL21vZHVsZXMvZXh0ZW5zaW9ucy8v bGliZ2x4LnNvCihJSSkgTW9kdWxlIGdseDogdmVuZG9yPSJYLk9yZyBGb3VuZGF0aW9uIgoJY29t cGlsZWQgZm9yIDEuNC4yLCBtb2R1bGUgdmVyc2lvbiA9IDEuMC4wCglBQkkgY2xhc3M6IFguT3Jn IFNlcnZlciBFeHRlbnNpb24sIHZlcnNpb24gMC4zCig9PSkgQUlHTFggZGlzYWJsZWQKKElJKSBM b2FkaW5nIGV4dGVuc2lvbiBHTFgKKElJKSBMb2FkTW9kdWxlOiAicmVjb3JkIgooSUkpIExvYWRp bmcgL3Vzci9sb2NhbC9saWIveG9yZy9tb2R1bGVzL2V4dGVuc2lvbnMvL2xpYnJlY29yZC5zbwoo SUkpIE1vZHVsZSByZWNvcmQ6IHZlbmRvcj0iWC5PcmcgRm91bmRhdGlvbiIKCWNvbXBpbGVkIGZv ciAxLjQuMiwgbW9kdWxlIHZlcnNpb24gPSAxLjEzLjAKCU1vZHVsZSBjbGFzczogWC5PcmcgU2Vy dmVyIEV4dGVuc2lvbgoJQUJJIGNsYXNzOiBYLk9yZyBTZXJ2ZXIgRXh0ZW5zaW9uLCB2ZXJzaW9u IDAuMwooSUkpIExvYWRpbmcgZXh0ZW5zaW9uIFJFQ09SRAooSUkpIExvYWRNb2R1bGU6ICJ4dHJh cCIKKElJKSBMb2FkaW5nIC91c3IvbG9jYWwvbGliL3hvcmcvbW9kdWxlcy9leHRlbnNpb25zLy9s aWJ4dHJhcC5zbwooSUkpIE1vZHVsZSB4dHJhcDogdmVuZG9yPSJYLk9yZyBGb3VuZGF0aW9uIgoJ Y29tcGlsZWQgZm9yIDEuNC4yLCBtb2R1bGUgdmVyc2lvbiA9IDEuMC4wCglNb2R1bGUgY2xhc3M6 IFguT3JnIFNlcnZlciBFeHRlbnNpb24KCUFCSSBjbGFzczogWC5PcmcgU2VydmVyIEV4dGVuc2lv biwgdmVyc2lvbiAwLjMKKElJKSBMb2FkaW5nIGV4dGVuc2lvbiBERUMtWFRSQVAKKElJKSBMb2Fk TW9kdWxlOiAiZnJlZXR5cGUiCihJSSkgTG9hZGluZyAvdXNyL2xvY2FsL2xpYi94b3JnL21vZHVs ZXMvZm9udHMvL2xpYmZyZWV0eXBlLnNvCihJSSkgTW9kdWxlIGZyZWV0eXBlOiB2ZW5kb3I9Ilgu T3JnIEZvdW5kYXRpb24gJiB0aGUgQWZ0ZXIgWC1UVCBQcm9qZWN0IgoJY29tcGlsZWQgZm9yIDEu NC4yLCBtb2R1bGUgdmVyc2lvbiA9IDIuMS4wCglNb2R1bGUgY2xhc3M6IFguT3JnIEZvbnQgUmVu ZGVyZXIKCUFCSSBjbGFzczogWC5PcmcgRm9udCBSZW5kZXJlciwgdmVyc2lvbiAwLjUKKElJKSBM b2FkaW5nIGZvbnQgRnJlZVR5cGUKKElJKSBMb2FkTW9kdWxlOiAidHlwZTEiCihJSSkgTG9hZGlu ZyAvdXNyL2xvY2FsL2xpYi94b3JnL21vZHVsZXMvZm9udHMvL2xpYnR5cGUxLnNvCihJSSkgTW9k dWxlIHR5cGUxOiB2ZW5kb3I9IlguT3JnIEZvdW5kYXRpb24iCgljb21waWxlZCBmb3IgMS40LjIs IG1vZHVsZSB2ZXJzaW9uID0gMS4wLjIKCU1vZHVsZSBjbGFzczogWC5PcmcgRm9udCBSZW5kZXJl cgoJQUJJIGNsYXNzOiBYLk9yZyBGb250IFJlbmRlcmVyLCB2ZXJzaW9uIDAuNQooSUkpIExvYWRp bmcgZm9udCBUeXBlMQooSUkpIExvYWRNb2R1bGU6ICJ2ZXNhIgooSUkpIExvYWRpbmcgL3Vzci9s b2NhbC9saWIveG9yZy9tb2R1bGVzL2RyaXZlcnMvL3Zlc2FfZHJ2LnNvCihJSSkgTW9kdWxlIHZl c2E6IHZlbmRvcj0iWC5PcmcgRm91bmRhdGlvbiIKCWNvbXBpbGVkIGZvciAxLjQuMiwgbW9kdWxl IHZlcnNpb24gPSAxLjMuMAoJTW9kdWxlIGNsYXNzOiBYLk9yZyBWaWRlbyBEcml2ZXIKCUFCSSBj bGFzczogWC5PcmcgVmlkZW8gRHJpdmVyLCB2ZXJzaW9uIDIuMAooSUkpIExvYWRNb2R1bGU6ICJt b3VzZSIKKElJKSBMb2FkaW5nIC91c3IvbG9jYWwvbGliL3hvcmcvbW9kdWxlcy9pbnB1dC8vbW91 c2VfZHJ2LnNvCihJSSkgTW9kdWxlIG1vdXNlOiB2ZW5kb3I9IlguT3JnIEZvdW5kYXRpb24iCglj b21waWxlZCBmb3IgMS40LjIsIG1vZHVsZSB2ZXJzaW9uID0gMS4yLjMKCU1vZHVsZSBjbGFzczog WC5PcmcgWElucHV0IERyaXZlcgoJQUJJIGNsYXNzOiBYLk9yZyBYSW5wdXQgZHJpdmVyLCB2ZXJz aW9uIDIuMAooSUkpIExvYWRNb2R1bGU6ICJrYmQiCihJSSkgTG9hZGluZyAvdXNyL2xvY2FsL2xp Yi94b3JnL21vZHVsZXMvaW5wdXQvL2tiZF9kcnYuc28KKElJKSBNb2R1bGUga2JkOiB2ZW5kb3I9 IlguT3JnIEZvdW5kYXRpb24iCgljb21waWxlZCBmb3IgMS40LjIsIG1vZHVsZSB2ZXJzaW9uID0g MS4yLjIKCU1vZHVsZSBjbGFzczogWC5PcmcgWElucHV0IERyaXZlcgoJQUJJIGNsYXNzOiBYLk9y ZyBYSW5wdXQgZHJpdmVyLCB2ZXJzaW9uIDIuMAooSUkpIFZFU0E6IGRyaXZlciBmb3IgVkVTQSBj aGlwc2V0czogdmVzYQooSUkpIFByaW1hcnkgRGV2aWNlIGlzOiBQQ0kgMDI6MDA6MAooLS0pIENo aXBzZXQgdmVzYSBmb3VuZAooSUkpIHJlc291cmNlIHJhbmdlcyBhZnRlciB4Zjg2Q2xhaW1GaXhl ZFJlc291cmNlcygpIGNhbGw6CglbMF0gLTEJMAkweGZmZmZmZmZmIC0gMHhmZmZmZmZmZiAoMHgx KSBNWFtCXQoJWzFdIC0xCTAJMHgwMDBmMDAwMCAtIDB4MDAwZmZmZmYgKDB4MTAwMDApIE1YW0Jd CglbMl0gLTEJMAkweDAwMGMwMDAwIC0gMHgwMDBlZmZmZiAoMHgzMDAwMCkgTVhbQl0KCVszXSAt MQkwCTB4MDAwMDAwMDAgLSAweDAwMDlmZmZmICgweGEwMDAwKSBNWFtCXQoJWzRdIC0xCTAJMHhm Y2Y3ZjAwMCAtIDB4ZmNmN2YzZmYgKDB4NDAwKSBNWFtCXUUKCVs1XSAtMQkwCTB4ZmNmN2Y0MDAg LSAweGZjZjdmN2ZmICgweDQwMCkgTVhbQl1FCglbNl0gLTEJMAkweGZjZjdjMDAwIC0gMHhmY2Y3 Y2ZmZiAoMHgxMDAwKSBNWFtCXUUKCVs3XSAtMQkwCTB4ZmNmNzYwMDAgLSAweGZjZjc3ZmZmICgw eDIwMDApIE1YW0JdRQoJWzhdIC0xCTAJMHhmY2Y3ODAwMCAtIDB4ZmNmN2JmZmYgKDB4NDAwMCkg TVhbQl1FCglbOV0gLTEJMAkweGZjZjdmODAwIC0gMHhmY2Y3ZmJmZiAoMHg0MDApIE1YW0JdRQoJ WzEwXSAtMQkwCTB4ZmNmN2QwMDAgLSAweGZjZjdkZmZmICgweDEwMDApIE1YW0JdRQoJWzExXSAt MQkwCTB4ZmNmN2ZjMDAgLSAweGZjZjdmZmZmICgweDQwMCkgTVhbQl1FCglbMTJdIC0xCTAJMHhm Y2Y3ZTAwMCAtIDB4ZmNmN2VmZmYgKDB4MTAwMCkgTVhbQl1FCglbMTNdIC0xCTAJMHhmZWJlMDAw MCAtIDB4ZmViZmZmZmYgKDB4MjAwMDApIE1YW0JdKEIpCglbMTRdIC0xCTAJMHhmYTAwMDAwMCAt IDB4ZmJmZmZmZmYgKDB4MjAwMDAwMCkgTVhbQl0oQikKCVsxNV0gLTEJMAkweGYwMDAwMDAwIC0g MHhmN2ZmZmZmZiAoMHg4MDAwMDAwKSBNWFtCXShCKQoJWzE2XSAtMQkwCTB4ZmQwMDAwMDAgLSAw eGZkZmZmZmZmICgweDEwMDAwMDApIE1YW0JdKEIpCglbMTddIC0xCTAJMHhmY2Y4MDAwMCAtIDB4 ZmNmZmZmZmYgKDB4ODAwMDApIE1YW0JdRQoJWzE4XSAtMQkwCTB4MDAwMGZmZmYgLSAweDAwMDBm ZmZmICgweDEpIElYW0JdCglbMTldIC0xCTAJMHgwMDAwMDAwMCAtIDB4MDAwMDAwMDAgKDB4MSkg SVhbQl0KCVsyMF0gLTEJMAkweDAwMDBjODgwIC0gMHgwMDAwYzhmZiAoMHg4MCkgSVhbQl1FCglb MjFdIC0xCTAJMHgwMDAwY2MwMCAtIDB4MDAwMGNjZmYgKDB4MTAwKSBJWFtCXUUKCVsyMl0gLTEJ MAkweDAwMDBkMDAwIC0gMHgwMDAwZDA3ZiAoMHg4MCkgSVhbQl1FCglbMjNdIC0xCTAJMHgwMDAw ZDA4MCAtIDB4MDAwMGQwZmYgKDB4ODApIElYW0JdRQoJWzI0XSAtMQkwCTB4MDAwMGQ0MDAgLSAw eDAwMDBkNDdmICgweDgwKSBJWFtCXUUKCVsyNV0gLTEJMAkweDAwMDBkNDgwIC0gMHgwMDAwZDRm ZiAoMHg4MCkgSVhbQl1FCglbMjZdIC0xCTAJMHgwMDAwMDcwMCAtIDB4MDAwMDA3ZmYgKDB4MTAw KSBJWFtCXUUKCVsyN10gLTEJMAkweDAwMDAwNjAwIC0gMHgwMDAwMDZmZiAoMHgxMDApIElYW0Jd RQoJWzI4XSAtMQkwCTB4MDAwMDBlMDAgLSAweDAwMDAwZWZmICgweDEwMCkgSVhbQl1FCglbMjld IC0xCTAJMHgwMDAwMDkwMCAtIDB4MDAwMDA5ZmYgKDB4MTAwKSBJWFtCXUUKCVszMF0gLTEJMAkw eDAwMDBlYzAwIC0gMHgwMDAwZWM3ZiAoMHg4MCkgSVhbQl0oQikKKElJKSByZXNvdXJjZSByYW5n ZXMgYWZ0ZXIgcHJvYmluZzoKCVswXSAtMQkwCTB4ZmZmZmZmZmYgLSAweGZmZmZmZmZmICgweDEp IE1YW0JdCglbMV0gLTEJMAkweDAwMGYwMDAwIC0gMHgwMDBmZmZmZiAoMHgxMDAwMCkgTVhbQl0K CVsyXSAtMQkwCTB4MDAwYzAwMDAgLSAweDAwMGVmZmZmICgweDMwMDAwKSBNWFtCXQoJWzNdIC0x CTAJMHgwMDAwMDAwMCAtIDB4MDAwOWZmZmYgKDB4YTAwMDApIE1YW0JdCglbNF0gLTEJMAkweGZj ZjdmMDAwIC0gMHhmY2Y3ZjNmZiAoMHg0MDApIE1YW0JdRQoJWzVdIC0xCTAJMHhmY2Y3ZjQwMCAt IDB4ZmNmN2Y3ZmYgKDB4NDAwKSBNWFtCXUUKCVs2XSAtMQkwCTB4ZmNmN2MwMDAgLSAweGZjZjdj ZmZmICgweDEwMDApIE1YW0JdRQoJWzddIC0xCTAJMHhmY2Y3NjAwMCAtIDB4ZmNmNzdmZmYgKDB4 MjAwMCkgTVhbQl1FCglbOF0gLTEJMAkweGZjZjc4MDAwIC0gMHhmY2Y3YmZmZiAoMHg0MDAwKSBN WFtCXUUKCVs5XSAtMQkwCTB4ZmNmN2Y4MDAgLSAweGZjZjdmYmZmICgweDQwMCkgTVhbQl1FCglb MTBdIC0xCTAJMHhmY2Y3ZDAwMCAtIDB4ZmNmN2RmZmYgKDB4MTAwMCkgTVhbQl1FCglbMTFdIC0x CTAJMHhmY2Y3ZmMwMCAtIDB4ZmNmN2ZmZmYgKDB4NDAwKSBNWFtCXUUKCVsxMl0gLTEJMAkweGZj ZjdlMDAwIC0gMHhmY2Y3ZWZmZiAoMHgxMDAwKSBNWFtCXUUKCVsxM10gLTEJMAkweGZlYmUwMDAw IC0gMHhmZWJmZmZmZiAoMHgyMDAwMCkgTVhbQl0oQikKCVsxNF0gLTEJMAkweGZhMDAwMDAwIC0g MHhmYmZmZmZmZiAoMHgyMDAwMDAwKSBNWFtCXShCKQoJWzE1XSAtMQkwCTB4ZjAwMDAwMDAgLSAw eGY3ZmZmZmZmICgweDgwMDAwMDApIE1YW0JdKEIpCglbMTZdIC0xCTAJMHhmZDAwMDAwMCAtIDB4 ZmRmZmZmZmYgKDB4MTAwMDAwMCkgTVhbQl0oQikKCVsxN10gLTEJMAkweGZjZjgwMDAwIC0gMHhm Y2ZmZmZmZiAoMHg4MDAwMCkgTVhbQl1FCglbMThdIDAJMAkweDAwMGEwMDAwIC0gMHgwMDBhZmZm ZiAoMHgxMDAwMCkgTVNbQl0KCVsxOV0gMAkwCTB4MDAwYjAwMDAgLSAweDAwMGI3ZmZmICgweDgw MDApIE1TW0JdCglbMjBdIDAJMAkweDAwMGI4MDAwIC0gMHgwMDBiZmZmZiAoMHg4MDAwKSBNU1tC XQoJWzIxXSAtMQkwCTB4MDAwMGZmZmYgLSAweDAwMDBmZmZmICgweDEpIElYW0JdCglbMjJdIC0x CTAJMHgwMDAwMDAwMCAtIDB4MDAwMDAwMDAgKDB4MSkgSVhbQl0KCVsyM10gLTEJMAkweDAwMDBj ODgwIC0gMHgwMDAwYzhmZiAoMHg4MCkgSVhbQl1FCglbMjRdIC0xCTAJMHgwMDAwY2MwMCAtIDB4 MDAwMGNjZmYgKDB4MTAwKSBJWFtCXUUKCVsyNV0gLTEJMAkweDAwMDBkMDAwIC0gMHgwMDAwZDA3 ZiAoMHg4MCkgSVhbQl1FCglbMjZdIC0xCTAJMHgwMDAwZDA4MCAtIDB4MDAwMGQwZmYgKDB4ODAp IElYW0JdRQoJWzI3XSAtMQkwCTB4MDAwMGQ0MDAgLSAweDAwMDBkNDdmICgweDgwKSBJWFtCXUUK CVsyOF0gLTEJMAkweDAwMDBkNDgwIC0gMHgwMDAwZDRmZiAoMHg4MCkgSVhbQl1FCglbMjldIC0x CTAJMHgwMDAwMDcwMCAtIDB4MDAwMDA3ZmYgKDB4MTAwKSBJWFtCXUUKCVszMF0gLTEJMAkweDAw MDAwNjAwIC0gMHgwMDAwMDZmZiAoMHgxMDApIElYW0JdRQoJWzMxXSAtMQkwCTB4MDAwMDBlMDAg LSAweDAwMDAwZWZmICgweDEwMCkgSVhbQl1FCglbMzJdIC0xCTAJMHgwMDAwMDkwMCAtIDB4MDAw MDA5ZmYgKDB4MTAwKSBJWFtCXUUKCVszM10gLTEJMAkweDAwMDBlYzAwIC0gMHgwMDAwZWM3ZiAo MHg4MCkgSVhbQl0oQikKCVszNF0gMAkwCTB4MDAwMDAzYjAgLSAweDAwMDAwM2JiICgweGMpIElT W0JdCglbMzVdIDAJMAkweDAwMDAwM2MwIC0gMHgwMDAwMDNkZiAoMHgyMCkgSVNbQl0KKElJKSBT ZXR0aW5nIHZnYSBmb3Igc2NyZWVuIDAuCihJSSkgTG9hZGluZyBzdWIgbW9kdWxlICJ2YmUiCihJ SSkgTG9hZE1vZHVsZTogInZiZSIKKElJKSBMb2FkaW5nIC91c3IvbG9jYWwvbGliL3hvcmcvbW9k dWxlcy8vbGlidmJlLnNvCihJSSkgTW9kdWxlIHZiZTogdmVuZG9yPSJYLk9yZyBGb3VuZGF0aW9u IgoJY29tcGlsZWQgZm9yIDEuNC4yLCBtb2R1bGUgdmVyc2lvbiA9IDEuMS4wCglBQkkgY2xhc3M6 IFguT3JnIFZpZGVvIERyaXZlciwgdmVyc2lvbiAyLjAKKElJKSBMb2FkaW5nIHN1YiBtb2R1bGUg ImludDEwIgooSUkpIExvYWRNb2R1bGU6ICJpbnQxMCIKKElJKSBMb2FkaW5nIC91c3IvbG9jYWwv bGliL3hvcmcvbW9kdWxlcy8vbGliaW50MTAuc28KKElJKSBNb2R1bGUgaW50MTA6IHZlbmRvcj0i WC5PcmcgRm91bmRhdGlvbiIKCWNvbXBpbGVkIGZvciAxLjQuMiwgbW9kdWxlIHZlcnNpb24gPSAx LjAuMAoJQUJJIGNsYXNzOiBYLk9yZyBWaWRlbyBEcml2ZXIsIHZlcnNpb24gMi4wCihJSSkgVkVT QSgwKTogaW5pdGlhbGl6aW5nIGludDEwCig9PSkgVkVTQSgwKTogV3JpdGUtY29tYmluaW5nIHJh bmdlICgweGEwMDAwLDB4MjAwMDApIHdhcyBhbHJlYWR5IGNsZWFyCig9PSkgVkVTQSgwKTogV3Jp dGUtY29tYmluaW5nIHJhbmdlICgweGMwMDAwLDB4NDAwMDApIHdhcyBhbHJlYWR5IGNsZWFyCihJ SSkgVkVTQSgwKTogUHJpbWFyeSBWX0JJT1Mgc2VnbWVudCBpczogMHhjMDAwCig9PSkgVkVTQSgw KTogV3JpdGUtY29tYmluaW5nIHJhbmdlICgweDAsMHgxMDAwKSB3YXMgYWxyZWFkeSBjbGVhcgoo PT0pIFZFU0EoMCk6IFdyaXRlLWNvbWJpbmluZyByYW5nZSAoMHgwLDB4MTAwMCkgd2FzIGFscmVh ZHkgY2xlYXIKKD09KSBWRVNBKDApOiBXcml0ZS1jb21iaW5pbmcgcmFuZ2UgKDB4MCwweDEwMDAp IHdhcyBhbHJlYWR5IGNsZWFyCihJSSkgVkVTQSgwKTogVkVTQSBCSU9TIGRldGVjdGVkCihJSSkg VkVTQSgwKTogVkVTQSBWQkUgVmVyc2lvbiAzLjAKKElJKSBWRVNBKDApOiBWRVNBIFZCRSBUb3Rh bCBNZW06IDE0MzM2IGtCCihJSSkgVkVTQSgwKTogVkVTQSBWQkUgT0VNOiBOVklESUEKKElJKSBW RVNBKDApOiBWRVNBIFZCRSBPRU0gU29mdHdhcmUgUmV2OiA5OC4xMTkKKElJKSBWRVNBKDApOiBW RVNBIFZCRSBPRU0gVmVuZG9yOiBOVklESUEgQ29ycG9yYXRpb24KKElJKSBWRVNBKDApOiBWRVNB IFZCRSBPRU0gUHJvZHVjdDogTUNQNzcgQm9hcmQgLSBtY3A3OHNvIAooSUkpIFZFU0EoMCk6IFZF U0EgVkJFIE9FTSBQcm9kdWN0IFJldjogQ2hpcCBSZXYgICAKKD09KSBWRVNBKDApOiBXcml0ZS1j b21iaW5pbmcgcmFuZ2UgKDB4MCwweDEwMDApIHdhcyBhbHJlYWR5IGNsZWFyCig9PSkgVkVTQSgw KTogV3JpdGUtY29tYmluaW5nIHJhbmdlICgweDAsMHgxMDAwKSB3YXMgYWxyZWFkeSBjbGVhcgoo PT0pIFZFU0EoMCk6IFdyaXRlLWNvbWJpbmluZyByYW5nZSAoMHgwLDB4MTAwMCkgd2FzIGFscmVh ZHkgY2xlYXIKKD09KSBWRVNBKDApOiBXcml0ZS1jb21iaW5pbmcgcmFuZ2UgKDB4MCwweDEwMDAp IHdhcyBhbHJlYWR5IGNsZWFyCig9PSkgVkVTQSgwKTogV3JpdGUtY29tYmluaW5nIHJhbmdlICgw eDAsMHgxMDAwKSB3YXMgYWxyZWFkeSBjbGVhcgooPT0pIFZFU0EoMCk6IFdyaXRlLWNvbWJpbmlu ZyByYW5nZSAoMHgwLDB4MTAwMCkgd2FzIGFscmVhZHkgY2xlYXIKKD09KSBWRVNBKDApOiBXcml0 ZS1jb21iaW5pbmcgcmFuZ2UgKDB4MCwweDEwMDApIHdhcyBhbHJlYWR5IGNsZWFyCig9PSkgVkVT QSgwKTogV3JpdGUtY29tYmluaW5nIHJhbmdlICgweDAsMHgxMDAwKSB3YXMgYWxyZWFkeSBjbGVh cgooPT0pIFZFU0EoMCk6IFdyaXRlLWNvbWJpbmluZyByYW5nZSAoMHgwLDB4MTAwMCkgd2FzIGFs cmVhZHkgY2xlYXIKKD09KSBWRVNBKDApOiBXcml0ZS1jb21iaW5pbmcgcmFuZ2UgKDB4MCwweDEw MDApIHdhcyBhbHJlYWR5IGNsZWFyCig9PSkgVkVTQSgwKTogV3JpdGUtY29tYmluaW5nIHJhbmdl ICgweDAsMHgxMDAwKSB3YXMgYWxyZWFkeSBjbGVhcgooPT0pIFZFU0EoMCk6IFdyaXRlLWNvbWJp bmluZyByYW5nZSAoMHgwLDB4MTAwMCkgd2FzIGFscmVhZHkgY2xlYXIKKD09KSBWRVNBKDApOiBX cml0ZS1jb21iaW5pbmcgcmFuZ2UgKDB4MCwweDEwMDApIHdhcyBhbHJlYWR5IGNsZWFyCig9PSkg VkVTQSgwKTogV3JpdGUtY29tYmluaW5nIHJhbmdlICgweDAsMHgxMDAwKSB3YXMgYWxyZWFkeSBj bGVhcgooPT0pIFZFU0EoMCk6IFdyaXRlLWNvbWJpbmluZyByYW5nZSAoMHgwLDB4MTAwMCkgd2Fz IGFscmVhZHkgY2xlYXIKKD09KSBWRVNBKDApOiBXcml0ZS1jb21iaW5pbmcgcmFuZ2UgKDB4MCww eDEwMDApIHdhcyBhbHJlYWR5IGNsZWFyCig9PSkgVkVTQSgwKTogV3JpdGUtY29tYmluaW5nIHJh bmdlICgweDAsMHgxMDAwKSB3YXMgYWxyZWFkeSBjbGVhcgooPT0pIFZFU0EoMCk6IFdyaXRlLWNv bWJpbmluZyByYW5nZSAoMHgwLDB4MTAwMCkgd2FzIGFscmVhZHkgY2xlYXIKKD09KSBWRVNBKDAp OiBXcml0ZS1jb21iaW5pbmcgcmFuZ2UgKDB4MCwweDEwMDApIHdhcyBhbHJlYWR5IGNsZWFyCig9 PSkgVkVTQSgwKTogV3JpdGUtY29tYmluaW5nIHJhbmdlICgweDAsMHgxMDAwKSB3YXMgYWxyZWFk eSBjbGVhcgooPT0pIFZFU0EoMCk6IFdyaXRlLWNvbWJpbmluZyByYW5nZSAoMHgwLDB4MTAwMCkg d2FzIGFscmVhZHkgY2xlYXIKKD09KSBWRVNBKDApOiBXcml0ZS1jb21iaW5pbmcgcmFuZ2UgKDB4 MCwweDEwMDApIHdhcyBhbHJlYWR5IGNsZWFyCig9PSkgVkVTQSgwKTogV3JpdGUtY29tYmluaW5n IHJhbmdlICgweDAsMHgxMDAwKSB3YXMgYWxyZWFkeSBjbGVhcgooPT0pIFZFU0EoMCk6IFdyaXRl LWNvbWJpbmluZyByYW5nZSAoMHgwLDB4MTAwMCkgd2FzIGFscmVhZHkgY2xlYXIKKD09KSBWRVNB KDApOiBXcml0ZS1jb21iaW5pbmcgcmFuZ2UgKDB4MCwweDEwMDApIHdhcyBhbHJlYWR5IGNsZWFy Cig9PSkgVkVTQSgwKTogV3JpdGUtY29tYmluaW5nIHJhbmdlICgweDAsMHgxMDAwKSB3YXMgYWxy ZWFkeSBjbGVhcgooPT0pIFZFU0EoMCk6IFdyaXRlLWNvbWJpbmluZyByYW5nZSAoMHgwLDB4MTAw MCkgd2FzIGFscmVhZHkgY2xlYXIKKD09KSBWRVNBKDApOiBXcml0ZS1jb21iaW5pbmcgcmFuZ2Ug KDB4MCwweDEwMDApIHdhcyBhbHJlYWR5IGNsZWFyCig9PSkgVkVTQSgwKTogV3JpdGUtY29tYmlu aW5nIHJhbmdlICgweDAsMHgxMDAwKSB3YXMgYWxyZWFkeSBjbGVhcgooPT0pIFZFU0EoMCk6IFdy aXRlLWNvbWJpbmluZyByYW5nZSAoMHgwLDB4MTAwMCkgd2FzIGFscmVhZHkgY2xlYXIKKD09KSBW RVNBKDApOiBXcml0ZS1jb21iaW5pbmcgcmFuZ2UgKDB4MCwweDEwMDApIHdhcyBhbHJlYWR5IGNs ZWFyCig9PSkgVkVTQSgwKTogV3JpdGUtY29tYmluaW5nIHJhbmdlICgweDAsMHgxMDAwKSB3YXMg YWxyZWFkeSBjbGVhcgooPT0pIFZFU0EoMCk6IFdyaXRlLWNvbWJpbmluZyByYW5nZSAoMHgwLDB4 MTAwMCkgd2FzIGFscmVhZHkgY2xlYXIKKD09KSBWRVNBKDApOiBXcml0ZS1jb21iaW5pbmcgcmFu Z2UgKDB4MCwweDEwMDApIHdhcyBhbHJlYWR5IGNsZWFyCig9PSkgVkVTQSgwKTogV3JpdGUtY29t YmluaW5nIHJhbmdlICgweDAsMHgxMDAwKSB3YXMgYWxyZWFkeSBjbGVhcgooPT0pIFZFU0EoMCk6 IFdyaXRlLWNvbWJpbmluZyByYW5nZSAoMHgwLDB4MTAwMCkgd2FzIGFscmVhZHkgY2xlYXIKKD09 KSBWRVNBKDApOiBXcml0ZS1jb21iaW5pbmcgcmFuZ2UgKDB4MCwweDEwMDApIHdhcyBhbHJlYWR5 IGNsZWFyCig9PSkgVkVTQSgwKTogV3JpdGUtY29tYmluaW5nIHJhbmdlICgweDAsMHgxMDAwKSB3 YXMgYWxyZWFkeSBjbGVhcgooPT0pIFZFU0EoMCk6IFdyaXRlLWNvbWJpbmluZyByYW5nZSAoMHgw LDB4MTAwMCkgd2FzIGFscmVhZHkgY2xlYXIKKD09KSBWRVNBKDApOiBXcml0ZS1jb21iaW5pbmcg cmFuZ2UgKDB4MCwweDEwMDApIHdhcyBhbHJlYWR5IGNsZWFyCig9PSkgVkVTQSgwKTogV3JpdGUt Y29tYmluaW5nIHJhbmdlICgweDAsMHgxMDAwKSB3YXMgYWxyZWFkeSBjbGVhcgooPT0pIFZFU0Eo MCk6IFdyaXRlLWNvbWJpbmluZyByYW5nZSAoMHgwLDB4MTAwMCkgd2FzIGFscmVhZHkgY2xlYXIK KD09KSBWRVNBKDApOiBXcml0ZS1jb21iaW5pbmcgcmFuZ2UgKDB4MCwweDEwMDApIHdhcyBhbHJl YWR5IGNsZWFyCig9PSkgVkVTQSgwKTogV3JpdGUtY29tYmluaW5nIHJhbmdlICgweDAsMHgxMDAw KSB3YXMgYWxyZWFkeSBjbGVhcgooPT0pIFZFU0EoMCk6IFdyaXRlLWNvbWJpbmluZyByYW5nZSAo MHgwLDB4MTAwMCkgd2FzIGFscmVhZHkgY2xlYXIKKD09KSBWRVNBKDApOiBXcml0ZS1jb21iaW5p bmcgcmFuZ2UgKDB4MCwweDEwMDApIHdhcyBhbHJlYWR5IGNsZWFyCig9PSkgVkVTQSgwKTogV3Jp dGUtY29tYmluaW5nIHJhbmdlICgweDAsMHgxMDAwKSB3YXMgYWxyZWFkeSBjbGVhcgooPT0pIFZF U0EoMCk6IFdyaXRlLWNvbWJpbmluZyByYW5nZSAoMHgwLDB4MTAwMCkgd2FzIGFscmVhZHkgY2xl YXIKKD09KSBWRVNBKDApOiBXcml0ZS1jb21iaW5pbmcgcmFuZ2UgKDB4MCwweDEwMDApIHdhcyBh bHJlYWR5IGNsZWFyCig9PSkgVkVTQSgwKTogV3JpdGUtY29tYmluaW5nIHJhbmdlICgweDAsMHgx MDAwKSB3YXMgYWxyZWFkeSBjbGVhcgooPT0pIFZFU0EoMCk6IFdyaXRlLWNvbWJpbmluZyByYW5n ZSAoMHgwLDB4MTAwMCkgd2FzIGFscmVhZHkgY2xlYXIKKD09KSBWRVNBKDApOiBXcml0ZS1jb21i aW5pbmcgcmFuZ2UgKDB4MCwweDEwMDApIHdhcyBhbHJlYWR5IGNsZWFyCig9PSkgVkVTQSgwKTog V3JpdGUtY29tYmluaW5nIHJhbmdlICgweDAsMHgxMDAwKSB3YXMgYWxyZWFkeSBjbGVhcgooPT0p IFZFU0EoMCk6IFdyaXRlLWNvbWJpbmluZyByYW5nZSAoMHgwLDB4MTAwMCkgd2FzIGFscmVhZHkg Y2xlYXIKKD09KSBWRVNBKDApOiBXcml0ZS1jb21iaW5pbmcgcmFuZ2UgKDB4MCwweDEwMDApIHdh cyBhbHJlYWR5IGNsZWFyCig9PSkgVkVTQSgwKTogV3JpdGUtY29tYmluaW5nIHJhbmdlICgweDAs MHgxMDAwKSB3YXMgYWxyZWFkeSBjbGVhcgooPT0pIFZFU0EoMCk6IFdyaXRlLWNvbWJpbmluZyBy YW5nZSAoMHgwLDB4MTAwMCkgd2FzIGFscmVhZHkgY2xlYXIKKD09KSBWRVNBKDApOiBXcml0ZS1j b21iaW5pbmcgcmFuZ2UgKDB4MCwweDEwMDApIHdhcyBhbHJlYWR5IGNsZWFyCig9PSkgVkVTQSgw KTogV3JpdGUtY29tYmluaW5nIHJhbmdlICgweDAsMHgxMDAwKSB3YXMgYWxyZWFkeSBjbGVhcgoo PT0pIFZFU0EoMCk6IFdyaXRlLWNvbWJpbmluZyByYW5nZSAoMHgwLDB4MTAwMCkgd2FzIGFscmVh ZHkgY2xlYXIKKD09KSBWRVNBKDApOiBXcml0ZS1jb21iaW5pbmcgcmFuZ2UgKDB4MCwweDEwMDAp IHdhcyBhbHJlYWR5IGNsZWFyCig9PSkgVkVTQSgwKTogV3JpdGUtY29tYmluaW5nIHJhbmdlICgw eDAsMHgxMDAwKSB3YXMgYWxyZWFkeSBjbGVhcgooPT0pIFZFU0EoMCk6IFdyaXRlLWNvbWJpbmlu ZyByYW5nZSAoMHgwLDB4MTAwMCkgd2FzIGFscmVhZHkgY2xlYXIKKD09KSBWRVNBKDApOiBXcml0 ZS1jb21iaW5pbmcgcmFuZ2UgKDB4MCwweDEwMDApIHdhcyBhbHJlYWR5IGNsZWFyCig9PSkgVkVT QSgwKTogV3JpdGUtY29tYmluaW5nIHJhbmdlICgweDAsMHgxMDAwKSB3YXMgYWxyZWFkeSBjbGVh cgooPT0pIFZFU0EoMCk6IFdyaXRlLWNvbWJpbmluZyByYW5nZSAoMHgwLDB4MTAwMCkgd2FzIGFs cmVhZHkgY2xlYXIKKD09KSBWRVNBKDApOiBXcml0ZS1jb21iaW5pbmcgcmFuZ2UgKDB4MCwweDEw MDApIHdhcyBhbHJlYWR5IGNsZWFyCig9PSkgVkVTQSgwKTogV3JpdGUtY29tYmluaW5nIHJhbmdl ICgweDAsMHgxMDAwKSB3YXMgYWxyZWFkeSBjbGVhcgooKiopIFZFU0EoMCk6IERlcHRoIDI0LCAo LS0pIGZyYW1lYnVmZmVyIGJwcCAzMgooPT0pIFZFU0EoMCk6IFJHQiB3ZWlnaHQgODg4Cig9PSkg VkVTQSgwKTogRGVmYXVsdCB2aXN1YWwgaXMgVHJ1ZUNvbG9yCig9PSkgVkVTQSgwKTogVXNpbmcg Z2FtbWEgY29ycmVjdGlvbiAoMS4wLCAxLjAsIDEuMCkKKElJKSBMb2FkaW5nIHN1YiBtb2R1bGUg ImRkYyIKKElJKSBMb2FkTW9kdWxlOiAiZGRjIihJSSkgTW9kdWxlICJkZGMiIGFscmVhZHkgYnVp bHQtaW4KKD09KSBWRVNBKDApOiBXcml0ZS1jb21iaW5pbmcgcmFuZ2UgKDB4MCwweDEwMDApIHdh cyBhbHJlYWR5IGNsZWFyCig9PSkgVkVTQSgwKTogV3JpdGUtY29tYmluaW5nIHJhbmdlICgweDAs MHgxMDAwKSB3YXMgYWxyZWFkeSBjbGVhcgooSUkpIFZFU0EoMCk6IFZFU0EgVkJFIEREQyBzdXBw b3J0ZWQKKElJKSBWRVNBKDApOiBWRVNBIFZCRSBEREMgTGV2ZWwgbm9uZQooSUkpIFZFU0EoMCk6 IFZFU0EgVkJFIEREQyB0cmFuc2ZlciBpbiBhcHByLiAwIHNlYy4KKD09KSBWRVNBKDApOiBXcml0 ZS1jb21iaW5pbmcgcmFuZ2UgKDB4MCwweDEwMDApIHdhcyBhbHJlYWR5IGNsZWFyCig9PSkgVkVT QSgwKTogV3JpdGUtY29tYmluaW5nIHJhbmdlICgweDAsMHgxMDAwKSB3YXMgYWxyZWFkeSBjbGVh cgooSUkpIFZFU0EoMCk6IFZFU0EgVkJFIEREQyByZWFkIGZhaWxlZAooSUkpIFZFU0EoMCk6IFNl YXJjaGluZyBmb3IgbWF0Y2hpbmcgVkVTQSBtb2RlKHMpOgooPT0pIFZFU0EoMCk6IFdyaXRlLWNv bWJpbmluZyByYW5nZSAoMHgwLDB4MTAwMCkgd2FzIGFscmVhZHkgY2xlYXIKKD09KSBWRVNBKDAp OiBXcml0ZS1jb21iaW5pbmcgcmFuZ2UgKDB4MCwweDEwMDApIHdhcyBhbHJlYWR5IGNsZWFyCk1v ZGU6IDEwMCAoNjQweDQwMCkKCU1vZGVBdHRyaWJ1dGVzOiAweDNiZgoJV2luQUF0dHJpYnV0ZXM6 IDB4NwoJV2luQkF0dHJpYnV0ZXM6IDB4MAoJV2luR3JhbnVsYXJpdHk6IDY0CglXaW5TaXplOiA2 NAoJV2luQVNlZ21lbnQ6IDB4YTAwMAoJV2luQlNlZ21lbnQ6IDB4MAoJV2luRnVuY1B0cjogMHhj MDAwODYwOAoJQnl0ZXNQZXJTY2FubGluZTogNjQwCglYUmVzb2x1dGlvbjogNjQwCglZUmVzb2x1 dGlvbjogNDAwCglYQ2hhclNpemU6IDgKCVlDaGFyU2l6ZTogMTYKCU51bWJlck9mUGxhbmVzOiAx CglCaXRzUGVyUGl4ZWw6IDgKCU51bWJlck9mQmFua3M6IDEKCU1lbW9yeU1vZGVsOiA0CglCYW5r U2l6ZTogMAoJTnVtYmVyT2ZJbWFnZXM6IDE0CglSZWRNYXNrU2l6ZTogMAoJUmVkRmllbGRQb3Np dGlvbjogMAoJR3JlZW5NYXNrU2l6ZTogMAoJR3JlZW5GaWVsZFBvc2l0aW9uOiAwCglCbHVlTWFz a1NpemU6IDAKCUJsdWVGaWVsZFBvc2l0aW9uOiAwCglSc3ZkTWFza1NpemU6IDAKCVJzdmRGaWVs ZFBvc2l0aW9uOiAwCglEaXJlY3RDb2xvck1vZGVJbmZvOiAwCglQaHlzQmFzZVB0cjogMHhmYjAw MDAwMAoJTGluQnl0ZXNQZXJTY2FuTGluZTogNjQwCglCbmtOdW1iZXJPZkltYWdlUGFnZXM6IDE0 CglMaW5OdW1iZXJPZkltYWdlUGFnZXM6IDE0CglMaW5SZWRNYXNrU2l6ZTogMAoJTGluUmVkRmll bGRQb3NpdGlvbjogMAoJTGluR3JlZW5NYXNrU2l6ZTogMAoJTGluR3JlZW5GaWVsZFBvc2l0aW9u OiAwCglMaW5CbHVlTWFza1NpemU6IDAKCUxpbkJsdWVGaWVsZFBvc2l0aW9uOiAwCglMaW5Sc3Zk TWFza1NpemU6IDAKCUxpblJzdmRGaWVsZFBvc2l0aW9uOiAwCglNYXhQaXhlbENsb2NrOiAyMjk1 MDAwMDAKKD09KSBWRVNBKDApOiBXcml0ZS1jb21iaW5pbmcgcmFuZ2UgKDB4MCwweDEwMDApIHdh cyBhbHJlYWR5IGNsZWFyCig9PSkgVkVTQSgwKTogV3JpdGUtY29tYmluaW5nIHJhbmdlICgweDAs MHgxMDAwKSB3YXMgYWxyZWFkeSBjbGVhcgpNb2RlOiAxMDEgKDY0MHg0ODApCglNb2RlQXR0cmli dXRlczogMHgzYmYKCVdpbkFBdHRyaWJ1dGVzOiAweDcKCVdpbkJBdHRyaWJ1dGVzOiAweDAKCVdp bkdyYW51bGFyaXR5OiA2NAoJV2luU2l6ZTogNjQKCVdpbkFTZWdtZW50OiAweGEwMDAKCVdpbkJT ZWdtZW50OiAweDAKCVdpbkZ1bmNQdHI6IDB4YzAwMDg2MDgKCUJ5dGVzUGVyU2NhbmxpbmU6IDY0 MAoJWFJlc29sdXRpb246IDY0MAoJWVJlc29sdXRpb246IDQ4MAoJWENoYXJTaXplOiA4CglZQ2hh clNpemU6IDE2CglOdW1iZXJPZlBsYW5lczogMQoJQml0c1BlclBpeGVsOiA4CglOdW1iZXJPZkJh bmtzOiAxCglNZW1vcnlNb2RlbDogNAoJQmFua1NpemU6IDAKCU51bWJlck9mSW1hZ2VzOiAxMAoJ UmVkTWFza1NpemU6IDAKCVJlZEZpZWxkUG9zaXRpb246IDAKCUdyZWVuTWFza1NpemU6IDAKCUdy ZWVuRmllbGRQb3NpdGlvbjogMAoJQmx1ZU1hc2tTaXplOiAwCglCbHVlRmllbGRQb3NpdGlvbjog MAoJUnN2ZE1hc2tTaXplOiAwCglSc3ZkRmllbGRQb3NpdGlvbjogMAoJRGlyZWN0Q29sb3JNb2Rl SW5mbzogMAoJUGh5c0Jhc2VQdHI6IDB4ZmIwMDAwMDAKCUxpbkJ5dGVzUGVyU2NhbkxpbmU6IDY0 MAoJQm5rTnVtYmVyT2ZJbWFnZVBhZ2VzOiAxMAoJTGluTnVtYmVyT2ZJbWFnZVBhZ2VzOiAxMAoJ TGluUmVkTWFza1NpemU6IDAKCUxpblJlZEZpZWxkUG9zaXRpb246IDAKCUxpbkdyZWVuTWFza1Np emU6IDAKCUxpbkdyZWVuRmllbGRQb3NpdGlvbjogMAoJTGluQmx1ZU1hc2tTaXplOiAwCglMaW5C bHVlRmllbGRQb3NpdGlvbjogMAoJTGluUnN2ZE1hc2tTaXplOiAwCglMaW5Sc3ZkRmllbGRQb3Np dGlvbjogMAoJTWF4UGl4ZWxDbG9jazogMjI5NTAwMDAwCig9PSkgVkVTQSgwKTogV3JpdGUtY29t YmluaW5nIHJhbmdlICgweDAsMHgxMDAwKSB3YXMgYWxyZWFkeSBjbGVhcgooPT0pIFZFU0EoMCk6 IFdyaXRlLWNvbWJpbmluZyByYW5nZSAoMHgwLDB4MTAwMCkgd2FzIGFscmVhZHkgY2xlYXIKTW9k ZTogMTAyICg4MDB4NjAwKQoJTW9kZUF0dHJpYnV0ZXM6IDB4MzNmCglXaW5BQXR0cmlidXRlczog MHg3CglXaW5CQXR0cmlidXRlczogMHgwCglXaW5HcmFudWxhcml0eTogNjQKCVdpblNpemU6IDY0 CglXaW5BU2VnbWVudDogMHhhMDAwCglXaW5CU2VnbWVudDogMHgwCglXaW5GdW5jUHRyOiAweGMw MDA4NjA4CglCeXRlc1BlclNjYW5saW5lOiAxMDAKCVhSZXNvbHV0aW9uOiA4MDAKCVlSZXNvbHV0 aW9uOiA2MDAKCVhDaGFyU2l6ZTogOAoJWUNoYXJTaXplOiAxNgoJTnVtYmVyT2ZQbGFuZXM6IDQK CUJpdHNQZXJQaXhlbDogNAoJTnVtYmVyT2ZCYW5rczogMQoJTWVtb3J5TW9kZWw6IDMKCUJhbmtT aXplOiAwCglOdW1iZXJPZkltYWdlczogMgoJUmVkTWFza1NpemU6IDAKCVJlZEZpZWxkUG9zaXRp b246IDAKCUdyZWVuTWFza1NpemU6IDAKCUdyZWVuRmllbGRQb3NpdGlvbjogMAoJQmx1ZU1hc2tT aXplOiAwCglCbHVlRmllbGRQb3NpdGlvbjogMAoJUnN2ZE1hc2tTaXplOiAwCglSc3ZkRmllbGRQ b3NpdGlvbjogMAoJRGlyZWN0Q29sb3JNb2RlSW5mbzogMAoJUGh5c0Jhc2VQdHI6IDB4MAoJTGlu Qnl0ZXNQZXJTY2FuTGluZTogMTAwCglCbmtOdW1iZXJPZkltYWdlUGFnZXM6IDIKCUxpbk51bWJl ck9mSW1hZ2VQYWdlczogMgoJTGluUmVkTWFza1NpemU6IDAKCUxpblJlZEZpZWxkUG9zaXRpb246 IDAKCUxpbkdyZWVuTWFza1NpemU6IDAKCUxpbkdyZWVuRmllbGRQb3NpdGlvbjogMAoJTGluQmx1 ZU1hc2tTaXplOiAwCglMaW5CbHVlRmllbGRQb3NpdGlvbjogMAoJTGluUnN2ZE1hc2tTaXplOiAw CglMaW5Sc3ZkRmllbGRQb3NpdGlvbjogMAoJTWF4UGl4ZWxDbG9jazogMTA4NTAwMDAwCig9PSkg VkVTQSgwKTogV3JpdGUtY29tYmluaW5nIHJhbmdlICgweDAsMHgxMDAwKSB3YXMgYWxyZWFkeSBj bGVhcgooPT0pIFZFU0EoMCk6IFdyaXRlLWNvbWJpbmluZyByYW5nZSAoMHgwLDB4MTAwMCkgd2Fz IGFscmVhZHkgY2xlYXIKTW9kZTogMTAzICg4MDB4NjAwKQoJTW9kZUF0dHJpYnV0ZXM6IDB4M2Jm CglXaW5BQXR0cmlidXRlczogMHg3CglXaW5CQXR0cmlidXRlczogMHgwCglXaW5HcmFudWxhcml0 eTogNjQKCVdpblNpemU6IDY0CglXaW5BU2VnbWVudDogMHhhMDAwCglXaW5CU2VnbWVudDogMHgw CglXaW5GdW5jUHRyOiAweGMwMDA4NjA4CglCeXRlc1BlclNjYW5saW5lOiA4MDAKCVhSZXNvbHV0 aW9uOiA4MDAKCVlSZXNvbHV0aW9uOiA2MDAKCVhDaGFyU2l6ZTogOAoJWUNoYXJTaXplOiAxNgoJ TnVtYmVyT2ZQbGFuZXM6IDEKCUJpdHNQZXJQaXhlbDogOAoJTnVtYmVyT2ZCYW5rczogMQoJTWVt b3J5TW9kZWw6IDQKCUJhbmtTaXplOiAwCglOdW1iZXJPZkltYWdlczogNgoJUmVkTWFza1NpemU6 IDAKCVJlZEZpZWxkUG9zaXRpb246IDAKCUdyZWVuTWFza1NpemU6IDAKCUdyZWVuRmllbGRQb3Np dGlvbjogMAoJQmx1ZU1hc2tTaXplOiAwCglCbHVlRmllbGRQb3NpdGlvbjogMAoJUnN2ZE1hc2tT aXplOiAwCglSc3ZkRmllbGRQb3NpdGlvbjogMAoJRGlyZWN0Q29sb3JNb2RlSW5mbzogMAoJUGh5 c0Jhc2VQdHI6IDB4ZmIwMDAwMDAKCUxpbkJ5dGVzUGVyU2NhbkxpbmU6IDgwMAoJQm5rTnVtYmVy T2ZJbWFnZVBhZ2VzOiA2CglMaW5OdW1iZXJPZkltYWdlUGFnZXM6IDYKCUxpblJlZE1hc2tTaXpl OiAwCglMaW5SZWRGaWVsZFBvc2l0aW9uOiAwCglMaW5HcmVlbk1hc2tTaXplOiAwCglMaW5HcmVl bkZpZWxkUG9zaXRpb246IDAKCUxpbkJsdWVNYXNrU2l6ZTogMAoJTGluQmx1ZUZpZWxkUG9zaXRp b246IDAKCUxpblJzdmRNYXNrU2l6ZTogMAoJTGluUnN2ZEZpZWxkUG9zaXRpb246IDAKCU1heFBp eGVsQ2xvY2s6IDIyOTUwMDAwMAooPT0pIFZFU0EoMCk6IFdyaXRlLWNvbWJpbmluZyByYW5nZSAo MHgwLDB4MTAwMCkgd2FzIGFscmVhZHkgY2xlYXIKKD09KSBWRVNBKDApOiBXcml0ZS1jb21iaW5p bmcgcmFuZ2UgKDB4MCwweDEwMDApIHdhcyBhbHJlYWR5IGNsZWFyCk1vZGU6IDEwNCAoMTAyNHg3 NjgpCglNb2RlQXR0cmlidXRlczogMHgzM2YKCVdpbkFBdHRyaWJ1dGVzOiAweDcKCVdpbkJBdHRy aWJ1dGVzOiAweDAKCVdpbkdyYW51bGFyaXR5OiA2NAoJV2luU2l6ZTogNjQKCVdpbkFTZWdtZW50 OiAweGEwMDAKCVdpbkJTZWdtZW50OiAweDAKCVdpbkZ1bmNQdHI6IDB4YzAwMDg2MDgKCUJ5dGVz UGVyU2NhbmxpbmU6IDEyOAoJWFJlc29sdXRpb246IDEwMjQKCVlSZXNvbHV0aW9uOiA3NjgKCVhD aGFyU2l6ZTogOAoJWUNoYXJTaXplOiAxNgoJTnVtYmVyT2ZQbGFuZXM6IDQKCUJpdHNQZXJQaXhl bDogNAoJTnVtYmVyT2ZCYW5rczogMQoJTWVtb3J5TW9kZWw6IDMKCUJhbmtTaXplOiAwCglOdW1i ZXJPZkltYWdlczogMQoJUmVkTWFza1NpemU6IDAKCVJlZEZpZWxkUG9zaXRpb246IDAKCUdyZWVu TWFza1NpemU6IDAKCUdyZWVuRmllbGRQb3NpdGlvbjogMAoJQmx1ZU1hc2tTaXplOiAwCglCbHVl RmllbGRQb3NpdGlvbjogMAoJUnN2ZE1hc2tTaXplOiAwCglSc3ZkRmllbGRQb3NpdGlvbjogMAoJ RGlyZWN0Q29sb3JNb2RlSW5mbzogMAoJUGh5c0Jhc2VQdHI6IDB4MAoJTGluQnl0ZXNQZXJTY2Fu TGluZTogMTI4CglCbmtOdW1iZXJPZkltYWdlUGFnZXM6IDEKCUxpbk51bWJlck9mSW1hZ2VQYWdl czogMQoJTGluUmVkTWFza1NpemU6IDAKCUxpblJlZEZpZWxkUG9zaXRpb246IDAKCUxpbkdyZWVu TWFza1NpemU6IDAKCUxpbkdyZWVuRmllbGRQb3NpdGlvbjogMAoJTGluQmx1ZU1hc2tTaXplOiAw CglMaW5CbHVlRmllbGRQb3NpdGlvbjogMAoJTGluUnN2ZE1hc2tTaXplOiAwCglMaW5Sc3ZkRmll bGRQb3NpdGlvbjogMAoJTWF4UGl4ZWxDbG9jazogMTA4NTAwMDAwCig9PSkgVkVTQSgwKTogV3Jp dGUtY29tYmluaW5nIHJhbmdlICgweDAsMHgxMDAwKSB3YXMgYWxyZWFkeSBjbGVhcgooPT0pIFZF U0EoMCk6IFdyaXRlLWNvbWJpbmluZyByYW5nZSAoMHgwLDB4MTAwMCkgd2FzIGFscmVhZHkgY2xl YXIKTW9kZTogMTA1ICgxMDI0eDc2OCkKCU1vZGVBdHRyaWJ1dGVzOiAweDNiZgoJV2luQUF0dHJp YnV0ZXM6IDB4NwoJV2luQkF0dHJpYnV0ZXM6IDB4MAoJV2luR3JhbnVsYXJpdHk6IDY0CglXaW5T aXplOiA2NAoJV2luQVNlZ21lbnQ6IDB4YTAwMAoJV2luQlNlZ21lbnQ6IDB4MAoJV2luRnVuY1B0 cjogMHhjMDAwODYwOAoJQnl0ZXNQZXJTY2FubGluZTogMTAyNAoJWFJlc29sdXRpb246IDEwMjQK CVlSZXNvbHV0aW9uOiA3NjgKCVhDaGFyU2l6ZTogOAoJWUNoYXJTaXplOiAxNgoJTnVtYmVyT2ZQ bGFuZXM6IDEKCUJpdHNQZXJQaXhlbDogOAoJTnVtYmVyT2ZCYW5rczogMQoJTWVtb3J5TW9kZWw6 IDQKCUJhbmtTaXplOiAwCglOdW1iZXJPZkltYWdlczogMwoJUmVkTWFza1NpemU6IDAKCVJlZEZp ZWxkUG9zaXRpb246IDAKCUdyZWVuTWFza1NpemU6IDAKCUdyZWVuRmllbGRQb3NpdGlvbjogMAoJ Qmx1ZU1hc2tTaXplOiAwCglCbHVlRmllbGRQb3NpdGlvbjogMAoJUnN2ZE1hc2tTaXplOiAwCglS c3ZkRmllbGRQb3NpdGlvbjogMAoJRGlyZWN0Q29sb3JNb2RlSW5mbzogMAoJUGh5c0Jhc2VQdHI6 IDB4ZmIwMDAwMDAKCUxpbkJ5dGVzUGVyU2NhbkxpbmU6IDEwMjQKCUJua051bWJlck9mSW1hZ2VQ YWdlczogMwoJTGluTnVtYmVyT2ZJbWFnZVBhZ2VzOiAzCglMaW5SZWRNYXNrU2l6ZTogMAoJTGlu UmVkRmllbGRQb3NpdGlvbjogMAoJTGluR3JlZW5NYXNrU2l6ZTogMAoJTGluR3JlZW5GaWVsZFBv c2l0aW9uOiAwCglMaW5CbHVlTWFza1NpemU6IDAKCUxpbkJsdWVGaWVsZFBvc2l0aW9uOiAwCglM aW5Sc3ZkTWFza1NpemU6IDAKCUxpblJzdmRGaWVsZFBvc2l0aW9uOiAwCglNYXhQaXhlbENsb2Nr OiAyMjk1MDAwMDAKKD09KSBWRVNBKDApOiBXcml0ZS1jb21iaW5pbmcgcmFuZ2UgKDB4MCwweDEw MDApIHdhcyBhbHJlYWR5IGNsZWFyCig9PSkgVkVTQSgwKTogV3JpdGUtY29tYmluaW5nIHJhbmdl ICgweDAsMHgxMDAwKSB3YXMgYWxyZWFkeSBjbGVhcgpNb2RlOiAxMDYgKDEyODB4MTAyNCkKCU1v ZGVBdHRyaWJ1dGVzOiAweDMzZgoJV2luQUF0dHJpYnV0ZXM6IDB4NwoJV2luQkF0dHJpYnV0ZXM6 IDB4MAoJV2luR3JhbnVsYXJpdHk6IDY0CglXaW5TaXplOiA2NAoJV2luQVNlZ21lbnQ6IDB4YTAw MAoJV2luQlNlZ21lbnQ6IDB4MAoJV2luRnVuY1B0cjogMHhjMDAwODYwOAoJQnl0ZXNQZXJTY2Fu bGluZTogMTYwCglYUmVzb2x1dGlvbjogMTI4MAoJWVJlc29sdXRpb246IDEwMjQKCVhDaGFyU2l6 ZTogOAoJWUNoYXJTaXplOiAxNgoJTnVtYmVyT2ZQbGFuZXM6IDQKCUJpdHNQZXJQaXhlbDogNAoJ TnVtYmVyT2ZCYW5rczogMQoJTWVtb3J5TW9kZWw6IDMKCUJhbmtTaXplOiAwCglOdW1iZXJPZklt YWdlczogMQoJUmVkTWFza1NpemU6IDAKCVJlZEZpZWxkUG9zaXRpb246IDAKCUdyZWVuTWFza1Np emU6IDAKCUdyZWVuRmllbGRQb3NpdGlvbjogMAoJQmx1ZU1hc2tTaXplOiAwCglCbHVlRmllbGRQ b3NpdGlvbjogMAoJUnN2ZE1hc2tTaXplOiAwCglSc3ZkRmllbGRQb3NpdGlvbjogMAoJRGlyZWN0 Q29sb3JNb2RlSW5mbzogMAoJUGh5c0Jhc2VQdHI6IDB4MAoJTGluQnl0ZXNQZXJTY2FuTGluZTog MTYwCglCbmtOdW1iZXJPZkltYWdlUGFnZXM6IDEKCUxpbk51bWJlck9mSW1hZ2VQYWdlczogMQoJ TGluUmVkTWFza1NpemU6IDAKCUxpblJlZEZpZWxkUG9zaXRpb246IDAKCUxpbkdyZWVuTWFza1Np emU6IDAKCUxpbkdyZWVuRmllbGRQb3NpdGlvbjogMAoJTGluQmx1ZU1hc2tTaXplOiAwCglMaW5C bHVlRmllbGRQb3NpdGlvbjogMAoJTGluUnN2ZE1hc2tTaXplOiAwCglMaW5Sc3ZkRmllbGRQb3Np dGlvbjogMAoJTWF4UGl4ZWxDbG9jazogMTA4NTAwMDAwCig9PSkgVkVTQSgwKTogV3JpdGUtY29t YmluaW5nIHJhbmdlICgweDAsMHgxMDAwKSB3YXMgYWxyZWFkeSBjbGVhcgooPT0pIFZFU0EoMCk6 IFdyaXRlLWNvbWJpbmluZyByYW5nZSAoMHgwLDB4MTAwMCkgd2FzIGFscmVhZHkgY2xlYXIKTW9k ZTogMTA3ICgxMjgweDEwMjQpCglNb2RlQXR0cmlidXRlczogMHgzYmYKCVdpbkFBdHRyaWJ1dGVz OiAweDcKCVdpbkJBdHRyaWJ1dGVzOiAweDAKCVdpbkdyYW51bGFyaXR5OiA2NAoJV2luU2l6ZTog NjQKCVdpbkFTZWdtZW50OiAweGEwMDAKCVdpbkJTZWdtZW50OiAweDAKCVdpbkZ1bmNQdHI6IDB4 YzAwMDg2MDgKCUJ5dGVzUGVyU2NhbmxpbmU6IDEyODAKCVhSZXNvbHV0aW9uOiAxMjgwCglZUmVz b2x1dGlvbjogMTAyNAoJWENoYXJTaXplOiA4CglZQ2hhclNpemU6IDE2CglOdW1iZXJPZlBsYW5l czogMQoJQml0c1BlclBpeGVsOiA4CglOdW1iZXJPZkJhbmtzOiAxCglNZW1vcnlNb2RlbDogNAoJ QmFua1NpemU6IDAKCU51bWJlck9mSW1hZ2VzOiAxCglSZWRNYXNrU2l6ZTogMAoJUmVkRmllbGRQ b3NpdGlvbjogMAoJR3JlZW5NYXNrU2l6ZTogMAoJR3JlZW5GaWVsZFBvc2l0aW9uOiAwCglCbHVl TWFza1NpemU6IDAKCUJsdWVGaWVsZFBvc2l0aW9uOiAwCglSc3ZkTWFza1NpemU6IDAKCVJzdmRG aWVsZFBvc2l0aW9uOiAwCglEaXJlY3RDb2xvck1vZGVJbmZvOiAwCglQaHlzQmFzZVB0cjogMHhm YjAwMDAwMAoJTGluQnl0ZXNQZXJTY2FuTGluZTogMTI4MAoJQm5rTnVtYmVyT2ZJbWFnZVBhZ2Vz OiAxCglMaW5OdW1iZXJPZkltYWdlUGFnZXM6IDEKCUxpblJlZE1hc2tTaXplOiAwCglMaW5SZWRG aWVsZFBvc2l0aW9uOiAwCglMaW5HcmVlbk1hc2tTaXplOiAwCglMaW5HcmVlbkZpZWxkUG9zaXRp b246IDAKCUxpbkJsdWVNYXNrU2l6ZTogMAoJTGluQmx1ZUZpZWxkUG9zaXRpb246IDAKCUxpblJz dmRNYXNrU2l6ZTogMAoJTGluUnN2ZEZpZWxkUG9zaXRpb246IDAKCU1heFBpeGVsQ2xvY2s6IDIy OTUwMDAwMAooPT0pIFZFU0EoMCk6IFdyaXRlLWNvbWJpbmluZyByYW5nZSAoMHgwLDB4MTAwMCkg d2FzIGFscmVhZHkgY2xlYXIKKD09KSBWRVNBKDApOiBXcml0ZS1jb21iaW5pbmcgcmFuZ2UgKDB4 MCwweDEwMDApIHdhcyBhbHJlYWR5IGNsZWFyCk1vZGU6IDEwZSAoMzIweDIwMCkKCU1vZGVBdHRy aWJ1dGVzOiAweDNiZgoJV2luQUF0dHJpYnV0ZXM6IDB4NwoJV2luQkF0dHJpYnV0ZXM6IDB4MAoJ V2luR3JhbnVsYXJpdHk6IDY0CglXaW5TaXplOiA2NAoJV2luQVNlZ21lbnQ6IDB4YTAwMAoJV2lu QlNlZ21lbnQ6IDB4MAoJV2luRnVuY1B0cjogMHhjMDAwODYwOAoJQnl0ZXNQZXJTY2FubGluZTog NjQwCglYUmVzb2x1dGlvbjogMzIwCglZUmVzb2x1dGlvbjogMjAwCglYQ2hhclNpemU6IDgKCVlD aGFyU2l6ZTogOAoJTnVtYmVyT2ZQbGFuZXM6IDEKCUJpdHNQZXJQaXhlbDogMTYKCU51bWJlck9m QmFua3M6IDEKCU1lbW9yeU1vZGVsOiA2CglCYW5rU2l6ZTogMAoJTnVtYmVyT2ZJbWFnZXM6IDMw CglSZWRNYXNrU2l6ZTogNQoJUmVkRmllbGRQb3NpdGlvbjogMTEKCUdyZWVuTWFza1NpemU6IDYK CUdyZWVuRmllbGRQb3NpdGlvbjogNQoJQmx1ZU1hc2tTaXplOiA1CglCbHVlRmllbGRQb3NpdGlv bjogMAoJUnN2ZE1hc2tTaXplOiAwCglSc3ZkRmllbGRQb3NpdGlvbjogMAoJRGlyZWN0Q29sb3JN b2RlSW5mbzogMAoJUGh5c0Jhc2VQdHI6IDB4ZmIwMDAwMDAKCUxpbkJ5dGVzUGVyU2NhbkxpbmU6 IDY0MAoJQm5rTnVtYmVyT2ZJbWFnZVBhZ2VzOiAzMAoJTGluTnVtYmVyT2ZJbWFnZVBhZ2VzOiAz MAoJTGluUmVkTWFza1NpemU6IDUKCUxpblJlZEZpZWxkUG9zaXRpb246IDExCglMaW5HcmVlbk1h c2tTaXplOiA2CglMaW5HcmVlbkZpZWxkUG9zaXRpb246IDUKCUxpbkJsdWVNYXNrU2l6ZTogNQoJ TGluQmx1ZUZpZWxkUG9zaXRpb246IDAKCUxpblJzdmRNYXNrU2l6ZTogMAoJTGluUnN2ZEZpZWxk UG9zaXRpb246IDAKCU1heFBpeGVsQ2xvY2s6IDIyOTUwMDAwMAooPT0pIFZFU0EoMCk6IFdyaXRl LWNvbWJpbmluZyByYW5nZSAoMHgwLDB4MTAwMCkgd2FzIGFscmVhZHkgY2xlYXIKKD09KSBWRVNB KDApOiBXcml0ZS1jb21iaW5pbmcgcmFuZ2UgKDB4MCwweDEwMDApIHdhcyBhbHJlYWR5IGNsZWFy CipNb2RlOiAxMGYgKDMyMHgyMDApCglNb2RlQXR0cmlidXRlczogMHgzYmYKCVdpbkFBdHRyaWJ1 dGVzOiAweDcKCVdpbkJBdHRyaWJ1dGVzOiAweDAKCVdpbkdyYW51bGFyaXR5OiA2NAoJV2luU2l6 ZTogNjQKCVdpbkFTZWdtZW50OiAweGEwMDAKCVdpbkJTZWdtZW50OiAweDAKCVdpbkZ1bmNQdHI6 IDB4YzAwMDg2MDgKCUJ5dGVzUGVyU2NhbmxpbmU6IDEyODAKCVhSZXNvbHV0aW9uOiAzMjAKCVlS ZXNvbHV0aW9uOiAyMDAKCVhDaGFyU2l6ZTogOAoJWUNoYXJTaXplOiA4CglOdW1iZXJPZlBsYW5l czogMQoJQml0c1BlclBpeGVsOiAzMgoJTnVtYmVyT2ZCYW5rczogMQoJTWVtb3J5TW9kZWw6IDYK CUJhbmtTaXplOiAwCglOdW1iZXJPZkltYWdlczogMTQKCVJlZE1hc2tTaXplOiA4CglSZWRGaWVs ZFBvc2l0aW9uOiAxNgoJR3JlZW5NYXNrU2l6ZTogOAoJR3JlZW5GaWVsZFBvc2l0aW9uOiA4CglC bHVlTWFza1NpemU6IDgKCUJsdWVGaWVsZFBvc2l0aW9uOiAwCglSc3ZkTWFza1NpemU6IDgKCVJz dmRGaWVsZFBvc2l0aW9uOiAyNAoJRGlyZWN0Q29sb3JNb2RlSW5mbzogMAoJUGh5c0Jhc2VQdHI6 IDB4ZmIwMDAwMDAKCUxpbkJ5dGVzUGVyU2NhbkxpbmU6IDEyODAKCUJua051bWJlck9mSW1hZ2VQ YWdlczogMTQKCUxpbk51bWJlck9mSW1hZ2VQYWdlczogMTQKCUxpblJlZE1hc2tTaXplOiA4CglM aW5SZWRGaWVsZFBvc2l0aW9uOiAxNgoJTGluR3JlZW5NYXNrU2l6ZTogOAoJTGluR3JlZW5GaWVs ZFBvc2l0aW9uOiA4CglMaW5CbHVlTWFza1NpemU6IDgKCUxpbkJsdWVGaWVsZFBvc2l0aW9uOiAw CglMaW5Sc3ZkTWFza1NpemU6IDgKCUxpblJzdmRGaWVsZFBvc2l0aW9uOiAyNAoJTWF4UGl4ZWxD bG9jazogMjI5NTAwMDAwCig9PSkgVkVTQSgwKTogV3JpdGUtY29tYmluaW5nIHJhbmdlICgweDAs MHgxMDAwKSB3YXMgYWxyZWFkeSBjbGVhcgooPT0pIFZFU0EoMCk6IFdyaXRlLWNvbWJpbmluZyBy YW5nZSAoMHgwLDB4MTAwMCkgd2FzIGFscmVhZHkgY2xlYXIKTW9kZTogMTExICg2NDB4NDgwKQoJ TW9kZUF0dHJpYnV0ZXM6IDB4M2JmCglXaW5BQXR0cmlidXRlczogMHg3CglXaW5CQXR0cmlidXRl czogMHgwCglXaW5HcmFudWxhcml0eTogNjQKCVdpblNpemU6IDY0CglXaW5BU2VnbWVudDogMHhh MDAwCglXaW5CU2VnbWVudDogMHgwCglXaW5GdW5jUHRyOiAweGMwMDA4NjA4CglCeXRlc1BlclNj YW5saW5lOiAxMjgwCglYUmVzb2x1dGlvbjogNjQwCglZUmVzb2x1dGlvbjogNDgwCglYQ2hhclNp emU6IDgKCVlDaGFyU2l6ZTogMTYKCU51bWJlck9mUGxhbmVzOiAxCglCaXRzUGVyUGl4ZWw6IDE2 CglOdW1iZXJPZkJhbmtzOiAxCglNZW1vcnlNb2RlbDogNgoJQmFua1NpemU6IDAKCU51bWJlck9m SW1hZ2VzOiA0CglSZWRNYXNrU2l6ZTogNQoJUmVkRmllbGRQb3NpdGlvbjogMTEKCUdyZWVuTWFz a1NpemU6IDYKCUdyZWVuRmllbGRQb3NpdGlvbjogNQoJQmx1ZU1hc2tTaXplOiA1CglCbHVlRmll bGRQb3NpdGlvbjogMAoJUnN2ZE1hc2tTaXplOiAwCglSc3ZkRmllbGRQb3NpdGlvbjogMAoJRGly ZWN0Q29sb3JNb2RlSW5mbzogMAoJUGh5c0Jhc2VQdHI6IDB4ZmIwMDAwMDAKCUxpbkJ5dGVzUGVy U2NhbkxpbmU6IDEyODAKCUJua051bWJlck9mSW1hZ2VQYWdlczogNAoJTGluTnVtYmVyT2ZJbWFn ZVBhZ2VzOiA0CglMaW5SZWRNYXNrU2l6ZTogNQoJTGluUmVkRmllbGRQb3NpdGlvbjogMTEKCUxp bkdyZWVuTWFza1NpemU6IDYKCUxpbkdyZWVuRmllbGRQb3NpdGlvbjogNQoJTGluQmx1ZU1hc2tT aXplOiA1CglMaW5CbHVlRmllbGRQb3NpdGlvbjogMAoJTGluUnN2ZE1hc2tTaXplOiAwCglMaW5S c3ZkRmllbGRQb3NpdGlvbjogMAoJTWF4UGl4ZWxDbG9jazogMjI5NTAwMDAwCig9PSkgVkVTQSgw KTogV3JpdGUtY29tYmluaW5nIHJhbmdlICgweDAsMHgxMDAwKSB3YXMgYWxyZWFkeSBjbGVhcgoo PT0pIFZFU0EoMCk6IFdyaXRlLWNvbWJpbmluZyByYW5nZSAoMHgwLDB4MTAwMCkgd2FzIGFscmVh ZHkgY2xlYXIKKk1vZGU6IDExMiAoNjQweDQ4MCkKCU1vZGVBdHRyaWJ1dGVzOiAweDNiZgoJV2lu QUF0dHJpYnV0ZXM6IDB4NwoJV2luQkF0dHJpYnV0ZXM6IDB4MAoJV2luR3JhbnVsYXJpdHk6IDY0 CglXaW5TaXplOiA2NAoJV2luQVNlZ21lbnQ6IDB4YTAwMAoJV2luQlNlZ21lbnQ6IDB4MAoJV2lu RnVuY1B0cjogMHhjMDAwODYwOAoJQnl0ZXNQZXJTY2FubGluZTogMjU2MAoJWFJlc29sdXRpb246 IDY0MAoJWVJlc29sdXRpb246IDQ4MAoJWENoYXJTaXplOiA4CglZQ2hhclNpemU6IDE2CglOdW1i ZXJPZlBsYW5lczogMQoJQml0c1BlclBpeGVsOiAzMgoJTnVtYmVyT2ZCYW5rczogMQoJTWVtb3J5 TW9kZWw6IDYKCUJhbmtTaXplOiAwCglOdW1iZXJPZkltYWdlczogMQoJUmVkTWFza1NpemU6IDgK CVJlZEZpZWxkUG9zaXRpb246IDE2CglHcmVlbk1hc2tTaXplOiA4CglHcmVlbkZpZWxkUG9zaXRp b246IDgKCUJsdWVNYXNrU2l6ZTogOAoJQmx1ZUZpZWxkUG9zaXRpb246IDAKCVJzdmRNYXNrU2l6 ZTogOAoJUnN2ZEZpZWxkUG9zaXRpb246IDI0CglEaXJlY3RDb2xvck1vZGVJbmZvOiAwCglQaHlz QmFzZVB0cjogMHhmYjAwMDAwMAoJTGluQnl0ZXNQZXJTY2FuTGluZTogMjU2MAoJQm5rTnVtYmVy T2ZJbWFnZVBhZ2VzOiAxCglMaW5OdW1iZXJPZkltYWdlUGFnZXM6IDEKCUxpblJlZE1hc2tTaXpl OiA4CglMaW5SZWRGaWVsZFBvc2l0aW9uOiAxNgoJTGluR3JlZW5NYXNrU2l6ZTogOAoJTGluR3Jl ZW5GaWVsZFBvc2l0aW9uOiA4CglMaW5CbHVlTWFza1NpemU6IDgKCUxpbkJsdWVGaWVsZFBvc2l0 aW9uOiAwCglMaW5Sc3ZkTWFza1NpemU6IDgKCUxpblJzdmRGaWVsZFBvc2l0aW9uOiAyNAoJTWF4 UGl4ZWxDbG9jazogMjI5NTAwMDAwCig9PSkgVkVTQSgwKTogV3JpdGUtY29tYmluaW5nIHJhbmdl ICgweDAsMHgxMDAwKSB3YXMgYWxyZWFkeSBjbGVhcgooPT0pIFZFU0EoMCk6IFdyaXRlLWNvbWJp bmluZyByYW5nZSAoMHgwLDB4MTAwMCkgd2FzIGFscmVhZHkgY2xlYXIKTW9kZTogMTE0ICg4MDB4 NjAwKQoJTW9kZUF0dHJpYnV0ZXM6IDB4M2JmCglXaW5BQXR0cmlidXRlczogMHg3CglXaW5CQXR0 cmlidXRlczogMHgwCglXaW5HcmFudWxhcml0eTogNjQKCVdpblNpemU6IDY0CglXaW5BU2VnbWVu dDogMHhhMDAwCglXaW5CU2VnbWVudDogMHgwCglXaW5GdW5jUHRyOiAweGMwMDA4NjA4CglCeXRl c1BlclNjYW5saW5lOiAxNjAwCglYUmVzb2x1dGlvbjogODAwCglZUmVzb2x1dGlvbjogNjAwCglY Q2hhclNpemU6IDgKCVlDaGFyU2l6ZTogMTYKCU51bWJlck9mUGxhbmVzOiAxCglCaXRzUGVyUGl4 ZWw6IDE2CglOdW1iZXJPZkJhbmtzOiAxCglNZW1vcnlNb2RlbDogNgoJQmFua1NpemU6IDAKCU51 bWJlck9mSW1hZ2VzOiAyCglSZWRNYXNrU2l6ZTogNQoJUmVkRmllbGRQb3NpdGlvbjogMTEKCUdy ZWVuTWFza1NpemU6IDYKCUdyZWVuRmllbGRQb3NpdGlvbjogNQoJQmx1ZU1hc2tTaXplOiA1CglC bHVlRmllbGRQb3NpdGlvbjogMAoJUnN2ZE1hc2tTaXplOiAwCglSc3ZkRmllbGRQb3NpdGlvbjog MAoJRGlyZWN0Q29sb3JNb2RlSW5mbzogMAoJUGh5c0Jhc2VQdHI6IDB4ZmIwMDAwMDAKCUxpbkJ5 dGVzUGVyU2NhbkxpbmU6IDE2MDAKCUJua051bWJlck9mSW1hZ2VQYWdlczogMgoJTGluTnVtYmVy T2ZJbWFnZVBhZ2VzOiAyCglMaW5SZWRNYXNrU2l6ZTogNQoJTGluUmVkRmllbGRQb3NpdGlvbjog MTEKCUxpbkdyZWVuTWFza1NpemU6IDYKCUxpbkdyZWVuRmllbGRQb3NpdGlvbjogNQoJTGluQmx1 ZU1hc2tTaXplOiA1CglMaW5CbHVlRmllbGRQb3NpdGlvbjogMAoJTGluUnN2ZE1hc2tTaXplOiAw CglMaW5Sc3ZkRmllbGRQb3NpdGlvbjogMAoJTWF4UGl4ZWxDbG9jazogMjI5NTAwMDAwCig9PSkg VkVTQSgwKTogV3JpdGUtY29tYmluaW5nIHJhbmdlICgweDAsMHgxMDAwKSB3YXMgYWxyZWFkeSBj bGVhcgooPT0pIFZFU0EoMCk6IFdyaXRlLWNvbWJpbmluZyByYW5nZSAoMHgwLDB4MTAwMCkgd2Fz IGFscmVhZHkgY2xlYXIKKk1vZGU6IDExNSAoODAweDYwMCkKCU1vZGVBdHRyaWJ1dGVzOiAweDNi ZgoJV2luQUF0dHJpYnV0ZXM6IDB4NwoJV2luQkF0dHJpYnV0ZXM6IDB4MAoJV2luR3JhbnVsYXJp dHk6IDY0CglXaW5TaXplOiA2NAoJV2luQVNlZ21lbnQ6IDB4YTAwMAoJV2luQlNlZ21lbnQ6IDB4 MAoJV2luRnVuY1B0cjogMHhjMDAwODYwOAoJQnl0ZXNQZXJTY2FubGluZTogMzIwMAoJWFJlc29s dXRpb246IDgwMAoJWVJlc29sdXRpb246IDYwMAoJWENoYXJTaXplOiA4CglZQ2hhclNpemU6IDE2 CglOdW1iZXJPZlBsYW5lczogMQoJQml0c1BlclBpeGVsOiAzMgoJTnVtYmVyT2ZCYW5rczogMQoJ TWVtb3J5TW9kZWw6IDYKCUJhbmtTaXplOiAwCglOdW1iZXJPZkltYWdlczogMQoJUmVkTWFza1Np emU6IDgKCVJlZEZpZWxkUG9zaXRpb246IDE2CglHcmVlbk1hc2tTaXplOiA4CglHcmVlbkZpZWxk UG9zaXRpb246IDgKCUJsdWVNYXNrU2l6ZTogOAoJQmx1ZUZpZWxkUG9zaXRpb246IDAKCVJzdmRN YXNrU2l6ZTogOAoJUnN2ZEZpZWxkUG9zaXRpb246IDI0CglEaXJlY3RDb2xvck1vZGVJbmZvOiAw CglQaHlzQmFzZVB0cjogMHhmYjAwMDAwMAoJTGluQnl0ZXNQZXJTY2FuTGluZTogMzIwMAoJQm5r TnVtYmVyT2ZJbWFnZVBhZ2VzOiAxCglMaW5OdW1iZXJPZkltYWdlUGFnZXM6IDEKCUxpblJlZE1h c2tTaXplOiA4CglMaW5SZWRGaWVsZFBvc2l0aW9uOiAxNgoJTGluR3JlZW5NYXNrU2l6ZTogOAoJ TGluR3JlZW5GaWVsZFBvc2l0aW9uOiA4CglMaW5CbHVlTWFza1NpemU6IDgKCUxpbkJsdWVGaWVs ZFBvc2l0aW9uOiAwCglMaW5Sc3ZkTWFza1NpemU6IDgKCUxpblJzdmRGaWVsZFBvc2l0aW9uOiAy NAoJTWF4UGl4ZWxDbG9jazogMjI5NTAwMDAwCig9PSkgVkVTQSgwKTogV3JpdGUtY29tYmluaW5n IHJhbmdlICgweDAsMHgxMDAwKSB3YXMgYWxyZWFkeSBjbGVhcgooPT0pIFZFU0EoMCk6IFdyaXRl LWNvbWJpbmluZyByYW5nZSAoMHgwLDB4MTAwMCkgd2FzIGFscmVhZHkgY2xlYXIKTW9kZTogMTE3 ICgxMDI0eDc2OCkKCU1vZGVBdHRyaWJ1dGVzOiAweDNiZgoJV2luQUF0dHJpYnV0ZXM6IDB4NwoJ V2luQkF0dHJpYnV0ZXM6IDB4MAoJV2luR3JhbnVsYXJpdHk6IDY0CglXaW5TaXplOiA2NAoJV2lu QVNlZ21lbnQ6IDB4YTAwMAoJV2luQlNlZ21lbnQ6IDB4MAoJV2luRnVuY1B0cjogMHhjMDAwODYw OAoJQnl0ZXNQZXJTY2FubGluZTogMjA0OAoJWFJlc29sdXRpb246IDEwMjQKCVlSZXNvbHV0aW9u OiA3NjgKCVhDaGFyU2l6ZTogOAoJWUNoYXJTaXplOiAxNgoJTnVtYmVyT2ZQbGFuZXM6IDEKCUJp dHNQZXJQaXhlbDogMTYKCU51bWJlck9mQmFua3M6IDEKCU1lbW9yeU1vZGVsOiA2CglCYW5rU2l6 ZTogMAoJTnVtYmVyT2ZJbWFnZXM6IDEKCVJlZE1hc2tTaXplOiA1CglSZWRGaWVsZFBvc2l0aW9u OiAxMQoJR3JlZW5NYXNrU2l6ZTogNgoJR3JlZW5GaWVsZFBvc2l0aW9uOiA1CglCbHVlTWFza1Np emU6IDUKCUJsdWVGaWVsZFBvc2l0aW9uOiAwCglSc3ZkTWFza1NpemU6IDAKCVJzdmRGaWVsZFBv c2l0aW9uOiAwCglEaXJlY3RDb2xvck1vZGVJbmZvOiAwCglQaHlzQmFzZVB0cjogMHhmYjAwMDAw MAoJTGluQnl0ZXNQZXJTY2FuTGluZTogMjA0OAoJQm5rTnVtYmVyT2ZJbWFnZVBhZ2VzOiAxCglM aW5OdW1iZXJPZkltYWdlUGFnZXM6IDEKCUxpblJlZE1hc2tTaXplOiA1CglMaW5SZWRGaWVsZFBv c2l0aW9uOiAxMQoJTGluR3JlZW5NYXNrU2l6ZTogNgoJTGluR3JlZW5GaWVsZFBvc2l0aW9uOiA1 CglMaW5CbHVlTWFza1NpemU6IDUKCUxpbkJsdWVGaWVsZFBvc2l0aW9uOiAwCglMaW5Sc3ZkTWFz a1NpemU6IDAKCUxpblJzdmRGaWVsZFBvc2l0aW9uOiAwCglNYXhQaXhlbENsb2NrOiAyMjk1MDAw MDAKKD09KSBWRVNBKDApOiBXcml0ZS1jb21iaW5pbmcgcmFuZ2UgKDB4MCwweDEwMDApIHdhcyBh bHJlYWR5IGNsZWFyCig9PSkgVkVTQSgwKTogV3JpdGUtY29tYmluaW5nIHJhbmdlICgweDAsMHgx MDAwKSB3YXMgYWxyZWFkeSBjbGVhcgoqTW9kZTogMTE4ICgxMDI0eDc2OCkKCU1vZGVBdHRyaWJ1 dGVzOiAweDNiZgoJV2luQUF0dHJpYnV0ZXM6IDB4NwoJV2luQkF0dHJpYnV0ZXM6IDB4MAoJV2lu R3JhbnVsYXJpdHk6IDY0CglXaW5TaXplOiA2NAoJV2luQVNlZ21lbnQ6IDB4YTAwMAoJV2luQlNl Z21lbnQ6IDB4MAoJV2luRnVuY1B0cjogMHhjMDAwODYwOAoJQnl0ZXNQZXJTY2FubGluZTogNDA5 NgoJWFJlc29sdXRpb246IDEwMjQKCVlSZXNvbHV0aW9uOiA3NjgKCVhDaGFyU2l6ZTogOAoJWUNo YXJTaXplOiAxNgoJTnVtYmVyT2ZQbGFuZXM6IDEKCUJpdHNQZXJQaXhlbDogMzIKCU51bWJlck9m QmFua3M6IDEKCU1lbW9yeU1vZGVsOiA2CglCYW5rU2l6ZTogMAoJTnVtYmVyT2ZJbWFnZXM6IDEK CVJlZE1hc2tTaXplOiA4CglSZWRGaWVsZFBvc2l0aW9uOiAxNgoJR3JlZW5NYXNrU2l6ZTogOAoJ R3JlZW5GaWVsZFBvc2l0aW9uOiA4CglCbHVlTWFza1NpemU6IDgKCUJsdWVGaWVsZFBvc2l0aW9u OiAwCglSc3ZkTWFza1NpemU6IDgKCVJzdmRGaWVsZFBvc2l0aW9uOiAyNAoJRGlyZWN0Q29sb3JN b2RlSW5mbzogMAoJUGh5c0Jhc2VQdHI6IDB4ZmIwMDAwMDAKCUxpbkJ5dGVzUGVyU2NhbkxpbmU6 IDQwOTYKCUJua051bWJlck9mSW1hZ2VQYWdlczogMQoJTGluTnVtYmVyT2ZJbWFnZVBhZ2VzOiAx CglMaW5SZWRNYXNrU2l6ZTogOAoJTGluUmVkRmllbGRQb3NpdGlvbjogMTYKCUxpbkdyZWVuTWFz a1NpemU6IDgKCUxpbkdyZWVuRmllbGRQb3NpdGlvbjogOAoJTGluQmx1ZU1hc2tTaXplOiA4CglM aW5CbHVlRmllbGRQb3NpdGlvbjogMAoJTGluUnN2ZE1hc2tTaXplOiA4CglMaW5Sc3ZkRmllbGRQ b3NpdGlvbjogMjQKCU1heFBpeGVsQ2xvY2s6IDIyOTUwMDAwMAooPT0pIFZFU0EoMCk6IFdyaXRl LWNvbWJpbmluZyByYW5nZSAoMHgwLDB4MTAwMCkgd2FzIGFscmVhZHkgY2xlYXIKKD09KSBWRVNB KDApOiBXcml0ZS1jb21iaW5pbmcgcmFuZ2UgKDB4MCwweDEwMDApIHdhcyBhbHJlYWR5IGNsZWFy Ck1vZGU6IDExYSAoMTI4MHgxMDI0KQoJTW9kZUF0dHJpYnV0ZXM6IDB4M2JmCglXaW5BQXR0cmli dXRlczogMHg3CglXaW5CQXR0cmlidXRlczogMHgwCglXaW5HcmFudWxhcml0eTogNjQKCVdpblNp emU6IDY0CglXaW5BU2VnbWVudDogMHhhMDAwCglXaW5CU2VnbWVudDogMHgwCglXaW5GdW5jUHRy OiAweGMwMDA4NjA4CglCeXRlc1BlclNjYW5saW5lOiAyNTYwCglYUmVzb2x1dGlvbjogMTI4MAoJ WVJlc29sdXRpb246IDEwMjQKCVhDaGFyU2l6ZTogOAoJWUNoYXJTaXplOiAxNgoJTnVtYmVyT2ZQ bGFuZXM6IDEKCUJpdHNQZXJQaXhlbDogMTYKCU51bWJlck9mQmFua3M6IDEKCU1lbW9yeU1vZGVs OiA2CglCYW5rU2l6ZTogMAoJTnVtYmVyT2ZJbWFnZXM6IDEKCVJlZE1hc2tTaXplOiA1CglSZWRG aWVsZFBvc2l0aW9uOiAxMQoJR3JlZW5NYXNrU2l6ZTogNgoJR3JlZW5GaWVsZFBvc2l0aW9uOiA1 CglCbHVlTWFza1NpemU6IDUKCUJsdWVGaWVsZFBvc2l0aW9uOiAwCglSc3ZkTWFza1NpemU6IDAK CVJzdmRGaWVsZFBvc2l0aW9uOiAwCglEaXJlY3RDb2xvck1vZGVJbmZvOiAwCglQaHlzQmFzZVB0 cjogMHhmYjAwMDAwMAoJTGluQnl0ZXNQZXJTY2FuTGluZTogMjU2MAoJQm5rTnVtYmVyT2ZJbWFn ZVBhZ2VzOiAxCglMaW5OdW1iZXJPZkltYWdlUGFnZXM6IDEKCUxpblJlZE1hc2tTaXplOiA1CglM aW5SZWRGaWVsZFBvc2l0aW9uOiAxMQoJTGluR3JlZW5NYXNrU2l6ZTogNgoJTGluR3JlZW5GaWVs ZFBvc2l0aW9uOiA1CglMaW5CbHVlTWFza1NpemU6IDUKCUxpbkJsdWVGaWVsZFBvc2l0aW9uOiAw CglMaW5Sc3ZkTWFza1NpemU6IDAKCUxpblJzdmRGaWVsZFBvc2l0aW9uOiAwCglNYXhQaXhlbENs b2NrOiAyMjk1MDAwMDAKKD09KSBWRVNBKDApOiBXcml0ZS1jb21iaW5pbmcgcmFuZ2UgKDB4MCww eDEwMDApIHdhcyBhbHJlYWR5IGNsZWFyCig9PSkgVkVTQSgwKTogV3JpdGUtY29tYmluaW5nIHJh bmdlICgweDAsMHgxMDAwKSB3YXMgYWxyZWFkeSBjbGVhcgoqTW9kZTogMTFiICgxMjgweDEwMjQp CglNb2RlQXR0cmlidXRlczogMHgzYmYKCVdpbkFBdHRyaWJ1dGVzOiAweDcKCVdpbkJBdHRyaWJ1 dGVzOiAweDAKCVdpbkdyYW51bGFyaXR5OiA2NAoJV2luU2l6ZTogNjQKCVdpbkFTZWdtZW50OiAw eGEwMDAKCVdpbkJTZWdtZW50OiAweDAKCVdpbkZ1bmNQdHI6IDB4YzAwMDg2MDgKCUJ5dGVzUGVy U2NhbmxpbmU6IDUxMjAKCVhSZXNvbHV0aW9uOiAxMjgwCglZUmVzb2x1dGlvbjogMTAyNAoJWENo YXJTaXplOiA4CglZQ2hhclNpemU6IDE2CglOdW1iZXJPZlBsYW5lczogMQoJQml0c1BlclBpeGVs OiAzMgoJTnVtYmVyT2ZCYW5rczogMQoJTWVtb3J5TW9kZWw6IDYKCUJhbmtTaXplOiAwCglOdW1i ZXJPZkltYWdlczogMQoJUmVkTWFza1NpemU6IDgKCVJlZEZpZWxkUG9zaXRpb246IDE2CglHcmVl bk1hc2tTaXplOiA4CglHcmVlbkZpZWxkUG9zaXRpb246IDgKCUJsdWVNYXNrU2l6ZTogOAoJQmx1 ZUZpZWxkUG9zaXRpb246IDAKCVJzdmRNYXNrU2l6ZTogOAoJUnN2ZEZpZWxkUG9zaXRpb246IDI0 CglEaXJlY3RDb2xvck1vZGVJbmZvOiAwCglQaHlzQmFzZVB0cjogMHhmYjAwMDAwMAoJTGluQnl0 ZXNQZXJTY2FuTGluZTogNTEyMAoJQm5rTnVtYmVyT2ZJbWFnZVBhZ2VzOiAxCglMaW5OdW1iZXJP ZkltYWdlUGFnZXM6IDEKCUxpblJlZE1hc2tTaXplOiA4CglMaW5SZWRGaWVsZFBvc2l0aW9uOiAx NgoJTGluR3JlZW5NYXNrU2l6ZTogOAoJTGluR3JlZW5GaWVsZFBvc2l0aW9uOiA4CglMaW5CbHVl TWFza1NpemU6IDgKCUxpbkJsdWVGaWVsZFBvc2l0aW9uOiAwCglMaW5Sc3ZkTWFza1NpemU6IDgK CUxpblJzdmRGaWVsZFBvc2l0aW9uOiAyNAoJTWF4UGl4ZWxDbG9jazogMjI5NTAwMDAwCig9PSkg VkVTQSgwKTogV3JpdGUtY29tYmluaW5nIHJhbmdlICgweDAsMHgxMDAwKSB3YXMgYWxyZWFkeSBj bGVhcgooPT0pIFZFU0EoMCk6IFdyaXRlLWNvbWJpbmluZyByYW5nZSAoMHgwLDB4MTAwMCkgd2Fz IGFscmVhZHkgY2xlYXIKTW9kZTogMTMwICgzMjB4MjAwKQoJTW9kZUF0dHJpYnV0ZXM6IDB4M2Jm CglXaW5BQXR0cmlidXRlczogMHg3CglXaW5CQXR0cmlidXRlczogMHgwCglXaW5HcmFudWxhcml0 eTogNjQKCVdpblNpemU6IDY0CglXaW5BU2VnbWVudDogMHhhMDAwCglXaW5CU2VnbWVudDogMHgw CglXaW5GdW5jUHRyOiAweGMwMDA4NjA4CglCeXRlc1BlclNjYW5saW5lOiAzMjAKCVhSZXNvbHV0 aW9uOiAzMjAKCVlSZXNvbHV0aW9uOiAyMDAKCVhDaGFyU2l6ZTogOAoJWUNoYXJTaXplOiA4CglO dW1iZXJPZlBsYW5lczogMQoJQml0c1BlclBpeGVsOiA4CglOdW1iZXJPZkJhbmtzOiAxCglNZW1v cnlNb2RlbDogNAoJQmFua1NpemU6IDAKCU51bWJlck9mSW1hZ2VzOiA2MgoJUmVkTWFza1NpemU6 IDAKCVJlZEZpZWxkUG9zaXRpb246IDAKCUdyZWVuTWFza1NpemU6IDAKCUdyZWVuRmllbGRQb3Np dGlvbjogMAoJQmx1ZU1hc2tTaXplOiAwCglCbHVlRmllbGRQb3NpdGlvbjogMAoJUnN2ZE1hc2tT aXplOiAwCglSc3ZkRmllbGRQb3NpdGlvbjogMAoJRGlyZWN0Q29sb3JNb2RlSW5mbzogMAoJUGh5 c0Jhc2VQdHI6IDB4ZmIwMDAwMDAKCUxpbkJ5dGVzUGVyU2NhbkxpbmU6IDMyMAoJQm5rTnVtYmVy T2ZJbWFnZVBhZ2VzOiA2MgoJTGluTnVtYmVyT2ZJbWFnZVBhZ2VzOiA2MgoJTGluUmVkTWFza1Np emU6IDAKCUxpblJlZEZpZWxkUG9zaXRpb246IDAKCUxpbkdyZWVuTWFza1NpemU6IDAKCUxpbkdy ZWVuRmllbGRQb3NpdGlvbjogMAoJTGluQmx1ZU1hc2tTaXplOiAwCglMaW5CbHVlRmllbGRQb3Np dGlvbjogMAoJTGluUnN2ZE1hc2tTaXplOiAwCglMaW5Sc3ZkRmllbGRQb3NpdGlvbjogMAoJTWF4 UGl4ZWxDbG9jazogMjI5NTAwMDAwCig9PSkgVkVTQSgwKTogV3JpdGUtY29tYmluaW5nIHJhbmdl ICgweDAsMHgxMDAwKSB3YXMgYWxyZWFkeSBjbGVhcgooPT0pIFZFU0EoMCk6IFdyaXRlLWNvbWJp bmluZyByYW5nZSAoMHgwLDB4MTAwMCkgd2FzIGFscmVhZHkgY2xlYXIKTW9kZTogMTMxICgzMjB4 NDAwKQoJTW9kZUF0dHJpYnV0ZXM6IDB4M2JmCglXaW5BQXR0cmlidXRlczogMHg3CglXaW5CQXR0 cmlidXRlczogMHgwCglXaW5HcmFudWxhcml0eTogNjQKCVdpblNpemU6IDY0CglXaW5BU2VnbWVu dDogMHhhMDAwCglXaW5CU2VnbWVudDogMHgwCglXaW5GdW5jUHRyOiAweGMwMDA4NjA4CglCeXRl c1BlclNjYW5saW5lOiAzMjAKCVhSZXNvbHV0aW9uOiAzMjAKCVlSZXNvbHV0aW9uOiA0MDAKCVhD aGFyU2l6ZTogOAoJWUNoYXJTaXplOiAxNgoJTnVtYmVyT2ZQbGFuZXM6IDEKCUJpdHNQZXJQaXhl bDogOAoJTnVtYmVyT2ZCYW5rczogMQoJTWVtb3J5TW9kZWw6IDQKCUJhbmtTaXplOiAwCglOdW1i ZXJPZkltYWdlczogMzAKCVJlZE1hc2tTaXplOiAwCglSZWRGaWVsZFBvc2l0aW9uOiAwCglHcmVl bk1hc2tTaXplOiAwCglHcmVlbkZpZWxkUG9zaXRpb246IDAKCUJsdWVNYXNrU2l6ZTogMAoJQmx1 ZUZpZWxkUG9zaXRpb246IDAKCVJzdmRNYXNrU2l6ZTogMAoJUnN2ZEZpZWxkUG9zaXRpb246IDAK CURpcmVjdENvbG9yTW9kZUluZm86IDAKCVBoeXNCYXNlUHRyOiAweGZiMDAwMDAwCglMaW5CeXRl c1BlclNjYW5MaW5lOiAzMjAKCUJua051bWJlck9mSW1hZ2VQYWdlczogMzAKCUxpbk51bWJlck9m SW1hZ2VQYWdlczogMzAKCUxpblJlZE1hc2tTaXplOiAwCglMaW5SZWRGaWVsZFBvc2l0aW9uOiAw CglMaW5HcmVlbk1hc2tTaXplOiAwCglMaW5HcmVlbkZpZWxkUG9zaXRpb246IDAKCUxpbkJsdWVN YXNrU2l6ZTogMAoJTGluQmx1ZUZpZWxkUG9zaXRpb246IDAKCUxpblJzdmRNYXNrU2l6ZTogMAoJ TGluUnN2ZEZpZWxkUG9zaXRpb246IDAKCU1heFBpeGVsQ2xvY2s6IDIyOTUwMDAwMAooPT0pIFZF U0EoMCk6IFdyaXRlLWNvbWJpbmluZyByYW5nZSAoMHgwLDB4MTAwMCkgd2FzIGFscmVhZHkgY2xl YXIKKD09KSBWRVNBKDApOiBXcml0ZS1jb21iaW5pbmcgcmFuZ2UgKDB4MCwweDEwMDApIHdhcyBh bHJlYWR5IGNsZWFyCk1vZGU6IDEzMiAoMzIweDQwMCkKCU1vZGVBdHRyaWJ1dGVzOiAweDNiZgoJ V2luQUF0dHJpYnV0ZXM6IDB4NwoJV2luQkF0dHJpYnV0ZXM6IDB4MAoJV2luR3JhbnVsYXJpdHk6 IDY0CglXaW5TaXplOiA2NAoJV2luQVNlZ21lbnQ6IDB4YTAwMAoJV2luQlNlZ21lbnQ6IDB4MAoJ V2luRnVuY1B0cjogMHhjMDAwODYwOAoJQnl0ZXNQZXJTY2FubGluZTogNjQwCglYUmVzb2x1dGlv bjogMzIwCglZUmVzb2x1dGlvbjogNDAwCglYQ2hhclNpemU6IDgKCVlDaGFyU2l6ZTogMTYKCU51 bWJlck9mUGxhbmVzOiAxCglCaXRzUGVyUGl4ZWw6IDE2CglOdW1iZXJPZkJhbmtzOiAxCglNZW1v cnlNb2RlbDogNgoJQmFua1NpemU6IDAKCU51bWJlck9mSW1hZ2VzOiAxNAoJUmVkTWFza1NpemU6 IDUKCVJlZEZpZWxkUG9zaXRpb246IDExCglHcmVlbk1hc2tTaXplOiA2CglHcmVlbkZpZWxkUG9z aXRpb246IDUKCUJsdWVNYXNrU2l6ZTogNQoJQmx1ZUZpZWxkUG9zaXRpb246IDAKCVJzdmRNYXNr U2l6ZTogMAoJUnN2ZEZpZWxkUG9zaXRpb246IDAKCURpcmVjdENvbG9yTW9kZUluZm86IDAKCVBo eXNCYXNlUHRyOiAweGZiMDAwMDAwCglMaW5CeXRlc1BlclNjYW5MaW5lOiA2NDAKCUJua051bWJl ck9mSW1hZ2VQYWdlczogMTQKCUxpbk51bWJlck9mSW1hZ2VQYWdlczogMTQKCUxpblJlZE1hc2tT aXplOiA1CglMaW5SZWRGaWVsZFBvc2l0aW9uOiAxMQoJTGluR3JlZW5NYXNrU2l6ZTogNgoJTGlu R3JlZW5GaWVsZFBvc2l0aW9uOiA1CglMaW5CbHVlTWFza1NpemU6IDUKCUxpbkJsdWVGaWVsZFBv c2l0aW9uOiAwCglMaW5Sc3ZkTWFza1NpemU6IDAKCUxpblJzdmRGaWVsZFBvc2l0aW9uOiAwCglN YXhQaXhlbENsb2NrOiAyMjk1MDAwMDAKKD09KSBWRVNBKDApOiBXcml0ZS1jb21iaW5pbmcgcmFu Z2UgKDB4MCwweDEwMDApIHdhcyBhbHJlYWR5IGNsZWFyCig9PSkgVkVTQSgwKTogV3JpdGUtY29t YmluaW5nIHJhbmdlICgweDAsMHgxMDAwKSB3YXMgYWxyZWFkeSBjbGVhcgoqTW9kZTogMTMzICgz MjB4NDAwKQoJTW9kZUF0dHJpYnV0ZXM6IDB4M2JmCglXaW5BQXR0cmlidXRlczogMHg3CglXaW5C QXR0cmlidXRlczogMHgwCglXaW5HcmFudWxhcml0eTogNjQKCVdpblNpemU6IDY0CglXaW5BU2Vn bWVudDogMHhhMDAwCglXaW5CU2VnbWVudDogMHgwCglXaW5GdW5jUHRyOiAweGMwMDA4NjA4CglC eXRlc1BlclNjYW5saW5lOiAxMjgwCglYUmVzb2x1dGlvbjogMzIwCglZUmVzb2x1dGlvbjogNDAw CglYQ2hhclNpemU6IDgKCVlDaGFyU2l6ZTogMTYKCU51bWJlck9mUGxhbmVzOiAxCglCaXRzUGVy UGl4ZWw6IDMyCglOdW1iZXJPZkJhbmtzOiAxCglNZW1vcnlNb2RlbDogNgoJQmFua1NpemU6IDAK CU51bWJlck9mSW1hZ2VzOiA2CglSZWRNYXNrU2l6ZTogOAoJUmVkRmllbGRQb3NpdGlvbjogMTYK CUdyZWVuTWFza1NpemU6IDgKCUdyZWVuRmllbGRQb3NpdGlvbjogOAoJQmx1ZU1hc2tTaXplOiA4 CglCbHVlRmllbGRQb3NpdGlvbjogMAoJUnN2ZE1hc2tTaXplOiA4CglSc3ZkRmllbGRQb3NpdGlv bjogMjQKCURpcmVjdENvbG9yTW9kZUluZm86IDAKCVBoeXNCYXNlUHRyOiAweGZiMDAwMDAwCglM aW5CeXRlc1BlclNjYW5MaW5lOiAxMjgwCglCbmtOdW1iZXJPZkltYWdlUGFnZXM6IDYKCUxpbk51 bWJlck9mSW1hZ2VQYWdlczogNgoJTGluUmVkTWFza1NpemU6IDgKCUxpblJlZEZpZWxkUG9zaXRp b246IDE2CglMaW5HcmVlbk1hc2tTaXplOiA4CglMaW5HcmVlbkZpZWxkUG9zaXRpb246IDgKCUxp bkJsdWVNYXNrU2l6ZTogOAoJTGluQmx1ZUZpZWxkUG9zaXRpb246IDAKCUxpblJzdmRNYXNrU2l6 ZTogOAoJTGluUnN2ZEZpZWxkUG9zaXRpb246IDI0CglNYXhQaXhlbENsb2NrOiAyMjk1MDAwMDAK KD09KSBWRVNBKDApOiBXcml0ZS1jb21iaW5pbmcgcmFuZ2UgKDB4MCwweDEwMDApIHdhcyBhbHJl YWR5IGNsZWFyCig9PSkgVkVTQSgwKTogV3JpdGUtY29tYmluaW5nIHJhbmdlICgweDAsMHgxMDAw KSB3YXMgYWxyZWFkeSBjbGVhcgpNb2RlOiAxMzQgKDMyMHgyNDApCglNb2RlQXR0cmlidXRlczog MHgzYmYKCVdpbkFBdHRyaWJ1dGVzOiAweDcKCVdpbkJBdHRyaWJ1dGVzOiAweDAKCVdpbkdyYW51 bGFyaXR5OiA2NAoJV2luU2l6ZTogNjQKCVdpbkFTZWdtZW50OiAweGEwMDAKCVdpbkJTZWdtZW50 OiAweDAKCVdpbkZ1bmNQdHI6IDB4YzAwMDg2MDgKCUJ5dGVzUGVyU2NhbmxpbmU6IDMyMAoJWFJl c29sdXRpb246IDMyMAoJWVJlc29sdXRpb246IDI0MAoJWENoYXJTaXplOiA4CglZQ2hhclNpemU6 IDgKCU51bWJlck9mUGxhbmVzOiAxCglCaXRzUGVyUGl4ZWw6IDgKCU51bWJlck9mQmFua3M6IDEK CU1lbW9yeU1vZGVsOiA0CglCYW5rU2l6ZTogMAoJTnVtYmVyT2ZJbWFnZXM6IDMwCglSZWRNYXNr U2l6ZTogMAoJUmVkRmllbGRQb3NpdGlvbjogMAoJR3JlZW5NYXNrU2l6ZTogMAoJR3JlZW5GaWVs ZFBvc2l0aW9uOiAwCglCbHVlTWFza1NpemU6IDAKCUJsdWVGaWVsZFBvc2l0aW9uOiAwCglSc3Zk TWFza1NpemU6IDAKCVJzdmRGaWVsZFBvc2l0aW9uOiAwCglEaXJlY3RDb2xvck1vZGVJbmZvOiAw CglQaHlzQmFzZVB0cjogMHhmYjAwMDAwMAoJTGluQnl0ZXNQZXJTY2FuTGluZTogMzIwCglCbmtO dW1iZXJPZkltYWdlUGFnZXM6IDMwCglMaW5OdW1iZXJPZkltYWdlUGFnZXM6IDMwCglMaW5SZWRN YXNrU2l6ZTogMAoJTGluUmVkRmllbGRQb3NpdGlvbjogMAoJTGluR3JlZW5NYXNrU2l6ZTogMAoJ TGluR3JlZW5GaWVsZFBvc2l0aW9uOiAwCglMaW5CbHVlTWFza1NpemU6IDAKCUxpbkJsdWVGaWVs ZFBvc2l0aW9uOiAwCglMaW5Sc3ZkTWFza1NpemU6IDAKCUxpblJzdmRGaWVsZFBvc2l0aW9uOiAw CglNYXhQaXhlbENsb2NrOiAyMjk1MDAwMDAKKD09KSBWRVNBKDApOiBXcml0ZS1jb21iaW5pbmcg cmFuZ2UgKDB4MCwweDEwMDApIHdhcyBhbHJlYWR5IGNsZWFyCig9PSkgVkVTQSgwKTogV3JpdGUt Y29tYmluaW5nIHJhbmdlICgweDAsMHgxMDAwKSB3YXMgYWxyZWFkeSBjbGVhcgpNb2RlOiAxMzUg KDMyMHgyNDApCglNb2RlQXR0cmlidXRlczogMHgzYmYKCVdpbkFBdHRyaWJ1dGVzOiAweDcKCVdp bkJBdHRyaWJ1dGVzOiAweDAKCVdpbkdyYW51bGFyaXR5OiA2NAoJV2luU2l6ZTogNjQKCVdpbkFT ZWdtZW50OiAweGEwMDAKCVdpbkJTZWdtZW50OiAweDAKCVdpbkZ1bmNQdHI6IDB4YzAwMDg2MDgK CUJ5dGVzUGVyU2NhbmxpbmU6IDY0MAoJWFJlc29sdXRpb246IDMyMAoJWVJlc29sdXRpb246IDI0 MAoJWENoYXJTaXplOiA4CglZQ2hhclNpemU6IDgKCU51bWJlck9mUGxhbmVzOiAxCglCaXRzUGVy UGl4ZWw6IDE2CglOdW1iZXJPZkJhbmtzOiAxCglNZW1vcnlNb2RlbDogNgoJQmFua1NpemU6IDAK CU51bWJlck9mSW1hZ2VzOiAxOQoJUmVkTWFza1NpemU6IDUKCVJlZEZpZWxkUG9zaXRpb246IDEx CglHcmVlbk1hc2tTaXplOiA2CglHcmVlbkZpZWxkUG9zaXRpb246IDUKCUJsdWVNYXNrU2l6ZTog NQoJQmx1ZUZpZWxkUG9zaXRpb246IDAKCVJzdmRNYXNrU2l6ZTogMAoJUnN2ZEZpZWxkUG9zaXRp b246IDAKCURpcmVjdENvbG9yTW9kZUluZm86IDAKCVBoeXNCYXNlUHRyOiAweGZiMDAwMDAwCglM aW5CeXRlc1BlclNjYW5MaW5lOiA2NDAKCUJua051bWJlck9mSW1hZ2VQYWdlczogMTkKCUxpbk51 bWJlck9mSW1hZ2VQYWdlczogMTkKCUxpblJlZE1hc2tTaXplOiA1CglMaW5SZWRGaWVsZFBvc2l0 aW9uOiAxMQoJTGluR3JlZW5NYXNrU2l6ZTogNgoJTGluR3JlZW5GaWVsZFBvc2l0aW9uOiA1CglM aW5CbHVlTWFza1NpemU6IDUKCUxpbkJsdWVGaWVsZFBvc2l0aW9uOiAwCglMaW5Sc3ZkTWFza1Np emU6IDAKCUxpblJzdmRGaWVsZFBvc2l0aW9uOiAwCglNYXhQaXhlbENsb2NrOiAyMjk1MDAwMDAK KD09KSBWRVNBKDApOiBXcml0ZS1jb21iaW5pbmcgcmFuZ2UgKDB4MCwweDEwMDApIHdhcyBhbHJl YWR5IGNsZWFyCig9PSkgVkVTQSgwKTogV3JpdGUtY29tYmluaW5nIHJhbmdlICgweDAsMHgxMDAw KSB3YXMgYWxyZWFkeSBjbGVhcgoqTW9kZTogMTM2ICgzMjB4MjQwKQoJTW9kZUF0dHJpYnV0ZXM6 IDB4M2JmCglXaW5BQXR0cmlidXRlczogMHg3CglXaW5CQXR0cmlidXRlczogMHgwCglXaW5HcmFu dWxhcml0eTogNjQKCVdpblNpemU6IDY0CglXaW5BU2VnbWVudDogMHhhMDAwCglXaW5CU2VnbWVu dDogMHgwCglXaW5GdW5jUHRyOiAweGMwMDA4NjA4CglCeXRlc1BlclNjYW5saW5lOiAxMjgwCglY UmVzb2x1dGlvbjogMzIwCglZUmVzb2x1dGlvbjogMjQwCglYQ2hhclNpemU6IDgKCVlDaGFyU2l6 ZTogOAoJTnVtYmVyT2ZQbGFuZXM6IDEKCUJpdHNQZXJQaXhlbDogMzIKCU51bWJlck9mQmFua3M6 IDEKCU1lbW9yeU1vZGVsOiA2CglCYW5rU2l6ZTogMAoJTnVtYmVyT2ZJbWFnZXM6IDEwCglSZWRN YXNrU2l6ZTogOAoJUmVkRmllbGRQb3NpdGlvbjogMTYKCUdyZWVuTWFza1NpemU6IDgKCUdyZWVu RmllbGRQb3NpdGlvbjogOAoJQmx1ZU1hc2tTaXplOiA4CglCbHVlRmllbGRQb3NpdGlvbjogMAoJ UnN2ZE1hc2tTaXplOiA4CglSc3ZkRmllbGRQb3NpdGlvbjogMjQKCURpcmVjdENvbG9yTW9kZUlu Zm86IDAKCVBoeXNCYXNlUHRyOiAweGZiMDAwMDAwCglMaW5CeXRlc1BlclNjYW5MaW5lOiAxMjgw CglCbmtOdW1iZXJPZkltYWdlUGFnZXM6IDEwCglMaW5OdW1iZXJPZkltYWdlUGFnZXM6IDEwCglM aW5SZWRNYXNrU2l6ZTogOAoJTGluUmVkRmllbGRQb3NpdGlvbjogMTYKCUxpbkdyZWVuTWFza1Np emU6IDgKCUxpbkdyZWVuRmllbGRQb3NpdGlvbjogOAoJTGluQmx1ZU1hc2tTaXplOiA4CglMaW5C bHVlRmllbGRQb3NpdGlvbjogMAoJTGluUnN2ZE1hc2tTaXplOiA4CglMaW5Sc3ZkRmllbGRQb3Np dGlvbjogMjQKCU1heFBpeGVsQ2xvY2s6IDIyOTUwMDAwMAooPT0pIFZFU0EoMCk6IFdyaXRlLWNv bWJpbmluZyByYW5nZSAoMHgwLDB4MTAwMCkgd2FzIGFscmVhZHkgY2xlYXIKKD09KSBWRVNBKDAp OiBXcml0ZS1jb21iaW5pbmcgcmFuZ2UgKDB4MCwweDEwMDApIHdhcyBhbHJlYWR5IGNsZWFyCk1v ZGU6IDEzZCAoNjQweDQwMCkKCU1vZGVBdHRyaWJ1dGVzOiAweDNiZgoJV2luQUF0dHJpYnV0ZXM6 IDB4NwoJV2luQkF0dHJpYnV0ZXM6IDB4MAoJV2luR3JhbnVsYXJpdHk6IDY0CglXaW5TaXplOiA2 NAoJV2luQVNlZ21lbnQ6IDB4YTAwMAoJV2luQlNlZ21lbnQ6IDB4MAoJV2luRnVuY1B0cjogMHhj MDAwODYwOAoJQnl0ZXNQZXJTY2FubGluZTogMTI4MAoJWFJlc29sdXRpb246IDY0MAoJWVJlc29s dXRpb246IDQwMAoJWENoYXJTaXplOiA4CglZQ2hhclNpemU6IDE2CglOdW1iZXJPZlBsYW5lczog MQoJQml0c1BlclBpeGVsOiAxNgoJTnVtYmVyT2ZCYW5rczogMQoJTWVtb3J5TW9kZWw6IDYKCUJh bmtTaXplOiAwCglOdW1iZXJPZkltYWdlczogNgoJUmVkTWFza1NpemU6IDUKCVJlZEZpZWxkUG9z aXRpb246IDExCglHcmVlbk1hc2tTaXplOiA2CglHcmVlbkZpZWxkUG9zaXRpb246IDUKCUJsdWVN YXNrU2l6ZTogNQoJQmx1ZUZpZWxkUG9zaXRpb246IDAKCVJzdmRNYXNrU2l6ZTogMAoJUnN2ZEZp ZWxkUG9zaXRpb246IDAKCURpcmVjdENvbG9yTW9kZUluZm86IDAKCVBoeXNCYXNlUHRyOiAweGZi MDAwMDAwCglMaW5CeXRlc1BlclNjYW5MaW5lOiAxMjgwCglCbmtOdW1iZXJPZkltYWdlUGFnZXM6 IDYKCUxpbk51bWJlck9mSW1hZ2VQYWdlczogNgoJTGluUmVkTWFza1NpemU6IDUKCUxpblJlZEZp ZWxkUG9zaXRpb246IDExCglMaW5HcmVlbk1hc2tTaXplOiA2CglMaW5HcmVlbkZpZWxkUG9zaXRp b246IDUKCUxpbkJsdWVNYXNrU2l6ZTogNQoJTGluQmx1ZUZpZWxkUG9zaXRpb246IDAKCUxpblJz dmRNYXNrU2l6ZTogMAoJTGluUnN2ZEZpZWxkUG9zaXRpb246IDAKCU1heFBpeGVsQ2xvY2s6IDIy OTUwMDAwMAooPT0pIFZFU0EoMCk6IFdyaXRlLWNvbWJpbmluZyByYW5nZSAoMHgwLDB4MTAwMCkg d2FzIGFscmVhZHkgY2xlYXIKKD09KSBWRVNBKDApOiBXcml0ZS1jb21iaW5pbmcgcmFuZ2UgKDB4 MCwweDEwMDApIHdhcyBhbHJlYWR5IGNsZWFyCiooSUkpIFZFU0EoMCk6IE5vdCB1c2luZyBidWls dC1pbiBtb2RlICI2NDB4NDAwIiAodnJlZnJlc2ggb3V0IG9mIHJhbmdlKQpNb2RlOiAxM2UgKDY0 MHg0MDApCglNb2RlQXR0cmlidXRlczogMHgzYmYKCVdpbkFBdHRyaWJ1dGVzOiAweDcKCVdpbkJB dHRyaWJ1dGVzOiAweDAKCVdpbkdyYW51bGFyaXR5OiA2NAoJV2luU2l6ZTogNjQKCVdpbkFTZWdt ZW50OiAweGEwMDAKCVdpbkJTZWdtZW50OiAweDAKCVdpbkZ1bmNQdHI6IDB4YzAwMDg2MDgKCUJ5 dGVzUGVyU2NhbmxpbmU6IDI1NjAKCVhSZXNvbHV0aW9uOiA2NDAKCVlSZXNvbHV0aW9uOiA0MDAK CVhDaGFyU2l6ZTogOAoJWUNoYXJTaXplOiAxNgoJTnVtYmVyT2ZQbGFuZXM6IDEKCUJpdHNQZXJQ aXhlbDogMzIKCU51bWJlck9mQmFua3M6IDEKCU1lbW9yeU1vZGVsOiA2CglCYW5rU2l6ZTogMAoJ TnVtYmVyT2ZJbWFnZXM6IDIKCVJlZE1hc2tTaXplOiA4CglSZWRGaWVsZFBvc2l0aW9uOiAxNgoJ R3JlZW5NYXNrU2l6ZTogOAoJR3JlZW5GaWVsZFBvc2l0aW9uOiA4CglCbHVlTWFza1NpemU6IDgK CUJsdWVGaWVsZFBvc2l0aW9uOiAwCglSc3ZkTWFza1NpemU6IDgKCVJzdmRGaWVsZFBvc2l0aW9u OiAyNAoJRGlyZWN0Q29sb3JNb2RlSW5mbzogMAoJUGh5c0Jhc2VQdHI6IDB4ZmIwMDAwMDAKCUxp bkJ5dGVzUGVyU2NhbkxpbmU6IDI1NjAKCUJua051bWJlck9mSW1hZ2VQYWdlczogMgoJTGluTnVt YmVyT2ZJbWFnZVBhZ2VzOiAyCglMaW5SZWRNYXNrU2l6ZTogOAoJTGluUmVkRmllbGRQb3NpdGlv bjogMTYKCUxpbkdyZWVuTWFza1NpemU6IDgKCUxpbkdyZWVuRmllbGRQb3NpdGlvbjogOAoJTGlu Qmx1ZU1hc2tTaXplOiA4CglMaW5CbHVlRmllbGRQb3NpdGlvbjogMAoJTGluUnN2ZE1hc2tTaXpl OiA4CglMaW5Sc3ZkRmllbGRQb3NpdGlvbjogMjQKCU1heFBpeGVsQ2xvY2s6IDIyOTUwMDAwMAoo PT0pIFZFU0EoMCk6IFdyaXRlLWNvbWJpbmluZyByYW5nZSAoMHgwLDB4MTAwMCkgd2FzIGFscmVh ZHkgY2xlYXIKKD09KSBWRVNBKDApOiBXcml0ZS1jb21iaW5pbmcgcmFuZ2UgKDB4MCwweDEwMDAp IHdhcyBhbHJlYWR5IGNsZWFyCk1vZGU6IDE2MCAoMTI4MHg4MDApCglNb2RlQXR0cmlidXRlczog MHgzYmYKCVdpbkFBdHRyaWJ1dGVzOiAweDcKCVdpbkJBdHRyaWJ1dGVzOiAweDAKCVdpbkdyYW51 bGFyaXR5OiA2NAoJV2luU2l6ZTogNjQKCVdpbkFTZWdtZW50OiAweGEwMDAKCVdpbkJTZWdtZW50 OiAweDAKCVdpbkZ1bmNQdHI6IDB4YzAwMDg2MDgKCUJ5dGVzUGVyU2NhbmxpbmU6IDEyODAKCVhS ZXNvbHV0aW9uOiAxMjgwCglZUmVzb2x1dGlvbjogODAwCglYQ2hhclNpemU6IDgKCVlDaGFyU2l6 ZTogMTYKCU51bWJlck9mUGxhbmVzOiAxCglCaXRzUGVyUGl4ZWw6IDgKCU51bWJlck9mQmFua3M6 IDEKCU1lbW9yeU1vZGVsOiA0CglCYW5rU2l6ZTogMAoJTnVtYmVyT2ZJbWFnZXM6IDIKCVJlZE1h c2tTaXplOiAwCglSZWRGaWVsZFBvc2l0aW9uOiAwCglHcmVlbk1hc2tTaXplOiAwCglHcmVlbkZp ZWxkUG9zaXRpb246IDAKCUJsdWVNYXNrU2l6ZTogMAoJQmx1ZUZpZWxkUG9zaXRpb246IDAKCVJz dmRNYXNrU2l6ZTogMAoJUnN2ZEZpZWxkUG9zaXRpb246IDAKCURpcmVjdENvbG9yTW9kZUluZm86 IDAKCVBoeXNCYXNlUHRyOiAweGZiMDAwMDAwCglMaW5CeXRlc1BlclNjYW5MaW5lOiAxMjgwCglC bmtOdW1iZXJPZkltYWdlUGFnZXM6IDIKCUxpbk51bWJlck9mSW1hZ2VQYWdlczogMgoJTGluUmVk TWFza1NpemU6IDAKCUxpblJlZEZpZWxkUG9zaXRpb246IDAKCUxpbkdyZWVuTWFza1NpemU6IDAK CUxpbkdyZWVuRmllbGRQb3NpdGlvbjogMAoJTGluQmx1ZU1hc2tTaXplOiAwCglMaW5CbHVlRmll bGRQb3NpdGlvbjogMAoJTGluUnN2ZE1hc2tTaXplOiAwCglMaW5Sc3ZkRmllbGRQb3NpdGlvbjog MAoJTWF4UGl4ZWxDbG9jazogMjI5NTAwMDAwCig9PSkgVkVTQSgwKTogV3JpdGUtY29tYmluaW5n IHJhbmdlICgweDAsMHgxMDAwKSB3YXMgYWxyZWFkeSBjbGVhcgooPT0pIFZFU0EoMCk6IFdyaXRl LWNvbWJpbmluZyByYW5nZSAoMHgwLDB4MTAwMCkgd2FzIGFscmVhZHkgY2xlYXIKKk1vZGU6IDE2 MSAoMTI4MHg4MDApCglNb2RlQXR0cmlidXRlczogMHgzYmYKCVdpbkFBdHRyaWJ1dGVzOiAweDcK CVdpbkJBdHRyaWJ1dGVzOiAweDAKCVdpbkdyYW51bGFyaXR5OiA2NAoJV2luU2l6ZTogNjQKCVdp bkFTZWdtZW50OiAweGEwMDAKCVdpbkJTZWdtZW50OiAweDAKCVdpbkZ1bmNQdHI6IDB4YzAwMDg2 MDgKCUJ5dGVzUGVyU2NhbmxpbmU6IDUxMjAKCVhSZXNvbHV0aW9uOiAxMjgwCglZUmVzb2x1dGlv bjogODAwCglYQ2hhclNpemU6IDgKCVlDaGFyU2l6ZTogMTYKCU51bWJlck9mUGxhbmVzOiAxCglC aXRzUGVyUGl4ZWw6IDMyCglOdW1iZXJPZkJhbmtzOiAxCglNZW1vcnlNb2RlbDogNgoJQmFua1Np emU6IDAKCU51bWJlck9mSW1hZ2VzOiAxCglSZWRNYXNrU2l6ZTogOAoJUmVkRmllbGRQb3NpdGlv bjogMTYKCUdyZWVuTWFza1NpemU6IDgKCUdyZWVuRmllbGRQb3NpdGlvbjogOAoJQmx1ZU1hc2tT aXplOiA4CglCbHVlRmllbGRQb3NpdGlvbjogMAoJUnN2ZE1hc2tTaXplOiA4CglSc3ZkRmllbGRQ b3NpdGlvbjogMjQKCURpcmVjdENvbG9yTW9kZUluZm86IDAKCVBoeXNCYXNlUHRyOiAweGZiMDAw MDAwCglMaW5CeXRlc1BlclNjYW5MaW5lOiA1MTIwCglCbmtOdW1iZXJPZkltYWdlUGFnZXM6IDEK CUxpbk51bWJlck9mSW1hZ2VQYWdlczogMQoJTGluUmVkTWFza1NpemU6IDgKCUxpblJlZEZpZWxk UG9zaXRpb246IDE2CglMaW5HcmVlbk1hc2tTaXplOiA4CglMaW5HcmVlbkZpZWxkUG9zaXRpb246 IDgKCUxpbkJsdWVNYXNrU2l6ZTogOAoJTGluQmx1ZUZpZWxkUG9zaXRpb246IDAKCUxpblJzdmRN YXNrU2l6ZTogOAoJTGluUnN2ZEZpZWxkUG9zaXRpb246IDI0CglNYXhQaXhlbENsb2NrOiAyMjk1 MDAwMDAKKD09KSBWRVNBKDApOiBXcml0ZS1jb21iaW5pbmcgcmFuZ2UgKDB4MCwweDEwMDApIHdh cyBhbHJlYWR5IGNsZWFyCig9PSkgVkVTQSgwKTogV3JpdGUtY29tYmluaW5nIHJhbmdlICgweDAs MHgxMDAwKSB3YXMgYWxyZWFkeSBjbGVhcgpNb2RlOiAxNjIgKDc2OHg0ODApCglNb2RlQXR0cmli dXRlczogMHgzYmYKCVdpbkFBdHRyaWJ1dGVzOiAweDcKCVdpbkJBdHRyaWJ1dGVzOiAweDAKCVdp bkdyYW51bGFyaXR5OiA2NAoJV2luU2l6ZTogNjQKCVdpbkFTZWdtZW50OiAweGEwMDAKCVdpbkJT ZWdtZW50OiAweDAKCVdpbkZ1bmNQdHI6IDB4YzAwMDg2MDgKCUJ5dGVzUGVyU2NhbmxpbmU6IDc2 OAoJWFJlc29sdXRpb246IDc2OAoJWVJlc29sdXRpb246IDQ4MAoJWENoYXJTaXplOiA4CglZQ2hh clNpemU6IDE2CglOdW1iZXJPZlBsYW5lczogMQoJQml0c1BlclBpeGVsOiA4CglOdW1iZXJPZkJh bmtzOiAxCglNZW1vcnlNb2RlbDogNAoJQmFua1NpemU6IDAKCU51bWJlck9mSW1hZ2VzOiA4CglS ZWRNYXNrU2l6ZTogMAoJUmVkRmllbGRQb3NpdGlvbjogMAoJR3JlZW5NYXNrU2l6ZTogMAoJR3Jl ZW5GaWVsZFBvc2l0aW9uOiAwCglCbHVlTWFza1NpemU6IDAKCUJsdWVGaWVsZFBvc2l0aW9uOiAw CglSc3ZkTWFza1NpemU6IDAKCVJzdmRGaWVsZFBvc2l0aW9uOiAwCglEaXJlY3RDb2xvck1vZGVJ bmZvOiAwCglQaHlzQmFzZVB0cjogMHhmYjAwMDAwMAoJTGluQnl0ZXNQZXJTY2FuTGluZTogNzY4 CglCbmtOdW1iZXJPZkltYWdlUGFnZXM6IDgKCUxpbk51bWJlck9mSW1hZ2VQYWdlczogOAoJTGlu UmVkTWFza1NpemU6IDAKCUxpblJlZEZpZWxkUG9zaXRpb246IDAKCUxpbkdyZWVuTWFza1NpemU6 IDAKCUxpbkdyZWVuRmllbGRQb3NpdGlvbjogMAoJTGluQmx1ZU1hc2tTaXplOiAwCglMaW5CbHVl RmllbGRQb3NpdGlvbjogMAoJTGluUnN2ZE1hc2tTaXplOiAwCglMaW5Sc3ZkRmllbGRQb3NpdGlv bjogMAoJTWF4UGl4ZWxDbG9jazogMjI5NTAwMDAwCig9PSkgVkVTQSgwKTogV3JpdGUtY29tYmlu aW5nIHJhbmdlICgweDAsMHgxMDAwKSB3YXMgYWxyZWFkeSBjbGVhcgooPT0pIFZFU0EoMCk6IFdy aXRlLWNvbWJpbmluZyByYW5nZSAoMHgwLDB4MTAwMCkgd2FzIGFscmVhZHkgY2xlYXIKTW9kZTog MTY4ICgxNjgweDEwNTApCglNb2RlQXR0cmlidXRlczogMHgzYmYKCVdpbkFBdHRyaWJ1dGVzOiAw eDcKCVdpbkJBdHRyaWJ1dGVzOiAweDAKCVdpbkdyYW51bGFyaXR5OiA2NAoJV2luU2l6ZTogNjQK CVdpbkFTZWdtZW50OiAweGEwMDAKCVdpbkJTZWdtZW50OiAweDAKCVdpbkZ1bmNQdHI6IDB4YzAw MDg2MDgKCUJ5dGVzUGVyU2NhbmxpbmU6IDE2ODAKCVhSZXNvbHV0aW9uOiAxNjgwCglZUmVzb2x1 dGlvbjogMTA1MAoJWENoYXJTaXplOiA4CglZQ2hhclNpemU6IDE2CglOdW1iZXJPZlBsYW5lczog MQoJQml0c1BlclBpeGVsOiA4CglOdW1iZXJPZkJhbmtzOiAxCglNZW1vcnlNb2RlbDogNAoJQmFu a1NpemU6IDAKCU51bWJlck9mSW1hZ2VzOiAxCglSZWRNYXNrU2l6ZTogMAoJUmVkRmllbGRQb3Np dGlvbjogMAoJR3JlZW5NYXNrU2l6ZTogMAoJR3JlZW5GaWVsZFBvc2l0aW9uOiAwCglCbHVlTWFz a1NpemU6IDAKCUJsdWVGaWVsZFBvc2l0aW9uOiAwCglSc3ZkTWFza1NpemU6IDAKCVJzdmRGaWVs ZFBvc2l0aW9uOiAwCglEaXJlY3RDb2xvck1vZGVJbmZvOiAwCglQaHlzQmFzZVB0cjogMHhmYjAw MDAwMAoJTGluQnl0ZXNQZXJTY2FuTGluZTogMTY4MAoJQm5rTnVtYmVyT2ZJbWFnZVBhZ2VzOiAx CglMaW5OdW1iZXJPZkltYWdlUGFnZXM6IDEKCUxpblJlZE1hc2tTaXplOiAwCglMaW5SZWRGaWVs ZFBvc2l0aW9uOiAwCglMaW5HcmVlbk1hc2tTaXplOiAwCglMaW5HcmVlbkZpZWxkUG9zaXRpb246 IDAKCUxpbkJsdWVNYXNrU2l6ZTogMAoJTGluQmx1ZUZpZWxkUG9zaXRpb246IDAKCUxpblJzdmRN YXNrU2l6ZTogMAoJTGluUnN2ZEZpZWxkUG9zaXRpb246IDAKCU1heFBpeGVsQ2xvY2s6IDIyOTUw MDAwMAooPT0pIFZFU0EoMCk6IFdyaXRlLWNvbWJpbmluZyByYW5nZSAoMHgwLDB4MTAwMCkgd2Fz IGFscmVhZHkgY2xlYXIKKD09KSBWRVNBKDApOiBXcml0ZS1jb21iaW5pbmcgcmFuZ2UgKDB4MCww eDEwMDApIHdhcyBhbHJlYWR5IGNsZWFyCipNb2RlOiAxNjkgKDE2ODB4MTA1MCkKCU1vZGVBdHRy aWJ1dGVzOiAweDNiZgoJV2luQUF0dHJpYnV0ZXM6IDB4NwoJV2luQkF0dHJpYnV0ZXM6IDB4MAoJ V2luR3JhbnVsYXJpdHk6IDY0CglXaW5TaXplOiA2NAoJV2luQVNlZ21lbnQ6IDB4YTAwMAoJV2lu QlNlZ21lbnQ6IDB4MAoJV2luRnVuY1B0cjogMHhjMDAwODYwOAoJQnl0ZXNQZXJTY2FubGluZTog NjcyMAoJWFJlc29sdXRpb246IDE2ODAKCVlSZXNvbHV0aW9uOiAxMDUwCglYQ2hhclNpemU6IDgK CVlDaGFyU2l6ZTogMTYKCU51bWJlck9mUGxhbmVzOiAxCglCaXRzUGVyUGl4ZWw6IDMyCglOdW1i ZXJPZkJhbmtzOiAxCglNZW1vcnlNb2RlbDogNgoJQmFua1NpemU6IDAKCU51bWJlck9mSW1hZ2Vz OiAxCglSZWRNYXNrU2l6ZTogOAoJUmVkRmllbGRQb3NpdGlvbjogMTYKCUdyZWVuTWFza1NpemU6 IDgKCUdyZWVuRmllbGRQb3NpdGlvbjogOAoJQmx1ZU1hc2tTaXplOiA4CglCbHVlRmllbGRQb3Np dGlvbjogMAoJUnN2ZE1hc2tTaXplOiA4CglSc3ZkRmllbGRQb3NpdGlvbjogMjQKCURpcmVjdENv bG9yTW9kZUluZm86IDAKCVBoeXNCYXNlUHRyOiAweGZiMDAwMDAwCglMaW5CeXRlc1BlclNjYW5M aW5lOiA2NzIwCglCbmtOdW1iZXJPZkltYWdlUGFnZXM6IDEKCUxpbk51bWJlck9mSW1hZ2VQYWdl czogMQoJTGluUmVkTWFza1NpemU6IDgKCUxpblJlZEZpZWxkUG9zaXRpb246IDE2CglMaW5HcmVl bk1hc2tTaXplOiA4CglMaW5HcmVlbkZpZWxkUG9zaXRpb246IDgKCUxpbkJsdWVNYXNrU2l6ZTog OAoJTGluQmx1ZUZpZWxkUG9zaXRpb246IDAKCUxpblJzdmRNYXNrU2l6ZTogOAoJTGluUnN2ZEZp ZWxkUG9zaXRpb246IDI0CglNYXhQaXhlbENsb2NrOiAyMjk1MDAwMDAKKD09KSBWRVNBKDApOiBX cml0ZS1jb21iaW5pbmcgcmFuZ2UgKDB4MCwweDEwMDApIHdhcyBhbHJlYWR5IGNsZWFyCig9PSkg VkVTQSgwKTogV3JpdGUtY29tYmluaW5nIHJhbmdlICgweDAsMHgxMDAwKSB3YXMgYWxyZWFkeSBj bGVhcgoqTW9kZTogMTdiICgxMjgweDcyMCkKCU1vZGVBdHRyaWJ1dGVzOiAweDNiZgoJV2luQUF0 dHJpYnV0ZXM6IDB4NwoJV2luQkF0dHJpYnV0ZXM6IDB4MAoJV2luR3JhbnVsYXJpdHk6IDY0CglX aW5TaXplOiA2NAoJV2luQVNlZ21lbnQ6IDB4YTAwMAoJV2luQlNlZ21lbnQ6IDB4MAoJV2luRnVu Y1B0cjogMHhjMDAwODYwOAoJQnl0ZXNQZXJTY2FubGluZTogNTEyMAoJWFJlc29sdXRpb246IDEy ODAKCVlSZXNvbHV0aW9uOiA3MjAKCVhDaGFyU2l6ZTogOAoJWUNoYXJTaXplOiAxNgoJTnVtYmVy T2ZQbGFuZXM6IDEKCUJpdHNQZXJQaXhlbDogMzIKCU51bWJlck9mQmFua3M6IDEKCU1lbW9yeU1v ZGVsOiA2CglCYW5rU2l6ZTogMAoJTnVtYmVyT2ZJbWFnZXM6IDEKCVJlZE1hc2tTaXplOiA4CglS ZWRGaWVsZFBvc2l0aW9uOiAxNgoJR3JlZW5NYXNrU2l6ZTogOAoJR3JlZW5GaWVsZFBvc2l0aW9u OiA4CglCbHVlTWFza1NpemU6IDgKCUJsdWVGaWVsZFBvc2l0aW9uOiAwCglSc3ZkTWFza1NpemU6 IDgKCVJzdmRGaWVsZFBvc2l0aW9uOiAyNAoJRGlyZWN0Q29sb3JNb2RlSW5mbzogMAoJUGh5c0Jh c2VQdHI6IDB4ZmIwMDAwMDAKCUxpbkJ5dGVzUGVyU2NhbkxpbmU6IDUxMjAKCUJua051bWJlck9m SW1hZ2VQYWdlczogMQoJTGluTnVtYmVyT2ZJbWFnZVBhZ2VzOiAxCglMaW5SZWRNYXNrU2l6ZTog OAoJTGluUmVkRmllbGRQb3NpdGlvbjogMTYKCUxpbkdyZWVuTWFza1NpemU6IDgKCUxpbkdyZWVu RmllbGRQb3NpdGlvbjogOAoJTGluQmx1ZU1hc2tTaXplOiA4CglMaW5CbHVlRmllbGRQb3NpdGlv bjogMAoJTGluUnN2ZE1hc2tTaXplOiA4CglMaW5Sc3ZkRmllbGRQb3NpdGlvbjogMjQKCU1heFBp eGVsQ2xvY2s6IDIyOTUwMDAwMAoKKElJKSBWRVNBKDApOiBUb3RhbCBNZW1vcnk6IDIyNCA2NEtC IGJhbmtzICgxNDMzNmtCKQooSUkpIFZFU0EoMCk6IE1vbml0b3IwOiBVc2luZyBoc3luYyByYW5n ZSBvZiAzMC4wMC04MS4wMCBrSHoKKElJKSBWRVNBKDApOiBNb25pdG9yMDogVXNpbmcgdnJlZnJl c2ggcmFuZ2Ugb2YgNTAuMDAtNzYuMDAgSHoKKElJKSBWRVNBKDApOiBOb3QgdXNpbmcgbW9kZSAi MTY4MHgxMDUwIiAobm8gbW9kZSBvZiB0aGlzIG5hbWUpCigtLSkgVkVTQSgwKTogVmlydHVhbCBz aXplIGlzIDEyODB4MTAyNCAocGl0Y2ggMTI4MCkKKCoqKSBWRVNBKDApOiAgQnVpbHQtaW4gbW9k ZSAiMTI4MHgxMDI0IgooKiopIFZFU0EoMCk6ICBCdWlsdC1pbiBtb2RlICIxMDI0eDc2OCIKKCoq KSBWRVNBKDApOiAgQnVpbHQtaW4gbW9kZSAiODAweDYwMCIKKCoqKSBWRVNBKDApOiAgQnVpbHQt aW4gbW9kZSAiNjQweDQ4MCIKKD09KSBWRVNBKDApOiBEUEkgc2V0IHRvICg5NiwgOTYpCihJSSkg VkVTQSgwKTogQXR0ZW1wdGluZyB0byB1c2UgNzVIeiByZWZyZXNoIGZvciBtb2RlICIxMjgweDEw MjQiICgxMWIpCig9PSkgVkVTQSgwKTogV3JpdGUtY29tYmluaW5nIHJhbmdlICgweDAsMHgxMDAw KSB3YXMgYWxyZWFkeSBjbGVhcgooPT0pIFZFU0EoMCk6IFdyaXRlLWNvbWJpbmluZyByYW5nZSAo MHgwLDB4MTAwMCkgd2FzIGFscmVhZHkgY2xlYXIKKElJKSBWRVNBKDApOiBBdHRlbXB0aW5nIHRv IHVzZSA3NUh6IHJlZnJlc2ggZm9yIG1vZGUgIjEwMjR4NzY4IiAoMTE4KQooPT0pIFZFU0EoMCk6 IFdyaXRlLWNvbWJpbmluZyByYW5nZSAoMHgwLDB4MTAwMCkgd2FzIGFscmVhZHkgY2xlYXIKKD09 KSBWRVNBKDApOiBXcml0ZS1jb21iaW5pbmcgcmFuZ2UgKDB4MCwweDEwMDApIHdhcyBhbHJlYWR5 IGNsZWFyCihJSSkgVkVTQSgwKTogQXR0ZW1wdGluZyB0byB1c2UgNzJIeiByZWZyZXNoIGZvciBt b2RlICI4MDB4NjAwIiAoMTE1KQooPT0pIFZFU0EoMCk6IFdyaXRlLWNvbWJpbmluZyByYW5nZSAo MHgwLDB4MTAwMCkgd2FzIGFscmVhZHkgY2xlYXIKKD09KSBWRVNBKDApOiBXcml0ZS1jb21iaW5p bmcgcmFuZ2UgKDB4MCwweDEwMDApIHdhcyBhbHJlYWR5IGNsZWFyCihJSSkgVkVTQSgwKTogQXR0 ZW1wdGluZyB0byB1c2UgNzNIeiByZWZyZXNoIGZvciBtb2RlICI2NDB4NDgwIiAoMTEyKQooPT0p IFZFU0EoMCk6IFdyaXRlLWNvbWJpbmluZyByYW5nZSAoMHgwLDB4MTAwMCkgd2FzIGFscmVhZHkg Y2xlYXIKKD09KSBWRVNBKDApOiBXcml0ZS1jb21iaW5pbmcgcmFuZ2UgKDB4MCwweDEwMDApIHdh cyBhbHJlYWR5IGNsZWFyCigqKikgVkVTQSgwKTogVXNpbmcgIlNoYWRvdyBGcmFtZWJ1ZmZlciIK KElJKSBMb2FkaW5nIHN1YiBtb2R1bGUgInNoYWRvdyIKKElJKSBMb2FkTW9kdWxlOiAic2hhZG93 IgooSUkpIExvYWRpbmcgL3Vzci9sb2NhbC9saWIveG9yZy9tb2R1bGVzLy9saWJzaGFkb3cuc28K KElJKSBNb2R1bGUgc2hhZG93OiB2ZW5kb3I9IlguT3JnIEZvdW5kYXRpb24iCgljb21waWxlZCBm b3IgMS40LjIsIG1vZHVsZSB2ZXJzaW9uID0gMS4xLjAKCUFCSSBjbGFzczogWC5PcmcgQU5TSSBD IEVtdWxhdGlvbiwgdmVyc2lvbiAwLjMKKElJKSBMb2FkaW5nIHN1YiBtb2R1bGUgImZiIgooSUkp IExvYWRNb2R1bGU6ICJmYiIKKElJKSBMb2FkaW5nIC91c3IvbG9jYWwvbGliL3hvcmcvbW9kdWxl cy8vbGliZmIuc28KKElJKSBNb2R1bGUgZmI6IHZlbmRvcj0iWC5PcmcgRm91bmRhdGlvbiIKCWNv bXBpbGVkIGZvciAxLjQuMiwgbW9kdWxlIHZlcnNpb24gPSAxLjAuMAoJQUJJIGNsYXNzOiBYLk9y ZyBBTlNJIEMgRW11bGF0aW9uLCB2ZXJzaW9uIDAuMwooPT0pIFZFU0EoMCk6IFdyaXRlLWNvbWJp bmluZyByYW5nZSAoMHgwLDB4MTAwMCkgd2FzIGFscmVhZHkgY2xlYXIKKC0tKSBEZXB0aCAyNCBw aXhtYXAgZm9ybWF0IGlzIDMyIGJwcAooSUkpIGRvIEkgbmVlZCBSQUM/ICBObywgSSBkb24ndC4K KElJKSByZXNvdXJjZSByYW5nZXMgYWZ0ZXIgcHJlSW5pdDoKCVswXSAtMQkwCTB4ZmZmZmZmZmYg LSAweGZmZmZmZmZmICgweDEpIE1YW0JdCglbMV0gLTEJMAkweDAwMGYwMDAwIC0gMHgwMDBmZmZm ZiAoMHgxMDAwMCkgTVhbQl0KCVsyXSAtMQkwCTB4MDAwYzAwMDAgLSAweDAwMGVmZmZmICgweDMw MDAwKSBNWFtCXQoJWzNdIC0xCTAJMHgwMDAwMDAwMCAtIDB4MDAwOWZmZmYgKDB4YTAwMDApIE1Y W0JdCglbNF0gLTEJMAkweGZjZjdmMDAwIC0gMHhmY2Y3ZjNmZiAoMHg0MDApIE1YW0JdRQoJWzVd IC0xCTAJMHhmY2Y3ZjQwMCAtIDB4ZmNmN2Y3ZmYgKDB4NDAwKSBNWFtCXUUKCVs2XSAtMQkwCTB4 ZmNmN2MwMDAgLSAweGZjZjdjZmZmICgweDEwMDApIE1YW0JdRQoJWzddIC0xCTAJMHhmY2Y3NjAw MCAtIDB4ZmNmNzdmZmYgKDB4MjAwMCkgTVhbQl1FCglbOF0gLTEJMAkweGZjZjc4MDAwIC0gMHhm Y2Y3YmZmZiAoMHg0MDAwKSBNWFtCXUUKCVs5XSAtMQkwCTB4ZmNmN2Y4MDAgLSAweGZjZjdmYmZm ICgweDQwMCkgTVhbQl1FCglbMTBdIC0xCTAJMHhmY2Y3ZDAwMCAtIDB4ZmNmN2RmZmYgKDB4MTAw MCkgTVhbQl1FCglbMTFdIC0xCTAJMHhmY2Y3ZmMwMCAtIDB4ZmNmN2ZmZmYgKDB4NDAwKSBNWFtC XUUKCVsxMl0gLTEJMAkweGZjZjdlMDAwIC0gMHhmY2Y3ZWZmZiAoMHgxMDAwKSBNWFtCXUUKCVsx M10gLTEJMAkweGZlYmUwMDAwIC0gMHhmZWJmZmZmZiAoMHgyMDAwMCkgTVhbQl0oQikKCVsxNF0g LTEJMAkweGZhMDAwMDAwIC0gMHhmYmZmZmZmZiAoMHgyMDAwMDAwKSBNWFtCXShCKQoJWzE1XSAt MQkwCTB4ZjAwMDAwMDAgLSAweGY3ZmZmZmZmICgweDgwMDAwMDApIE1YW0JdKEIpCglbMTZdIC0x CTAJMHhmZDAwMDAwMCAtIDB4ZmRmZmZmZmYgKDB4MTAwMDAwMCkgTVhbQl0oQikKCVsxN10gLTEJ MAkweGZjZjgwMDAwIC0gMHhmY2ZmZmZmZiAoMHg4MDAwMCkgTVhbQl1FCglbMThdIDAJMAkweDAw MGEwMDAwIC0gMHgwMDBhZmZmZiAoMHgxMDAwMCkgTVNbQl0KCVsxOV0gMAkwCTB4MDAwYjAwMDAg LSAweDAwMGI3ZmZmICgweDgwMDApIE1TW0JdCglbMjBdIDAJMAkweDAwMGI4MDAwIC0gMHgwMDBi ZmZmZiAoMHg4MDAwKSBNU1tCXQoJWzIxXSAtMQkwCTB4MDAwMGZmZmYgLSAweDAwMDBmZmZmICgw eDEpIElYW0JdCglbMjJdIC0xCTAJMHgwMDAwMDAwMCAtIDB4MDAwMDAwMDAgKDB4MSkgSVhbQl0K CVsyM10gLTEJMAkweDAwMDBjODgwIC0gMHgwMDAwYzhmZiAoMHg4MCkgSVhbQl1FCglbMjRdIC0x CTAJMHgwMDAwY2MwMCAtIDB4MDAwMGNjZmYgKDB4MTAwKSBJWFtCXUUKCVsyNV0gLTEJMAkweDAw MDBkMDAwIC0gMHgwMDAwZDA3ZiAoMHg4MCkgSVhbQl1FCglbMjZdIC0xCTAJMHgwMDAwZDA4MCAt IDB4MDAwMGQwZmYgKDB4ODApIElYW0JdRQoJWzI3XSAtMQkwCTB4MDAwMGQ0MDAgLSAweDAwMDBk NDdmICgweDgwKSBJWFtCXUUKCVsyOF0gLTEJMAkweDAwMDBkNDgwIC0gMHgwMDAwZDRmZiAoMHg4 MCkgSVhbQl1FCglbMjldIC0xCTAJMHgwMDAwMDcwMCAtIDB4MDAwMDA3ZmYgKDB4MTAwKSBJWFtC XUUKCVszMF0gLTEJMAkweDAwMDAwNjAwIC0gMHgwMDAwMDZmZiAoMHgxMDApIElYW0JdRQoJWzMx XSAtMQkwCTB4MDAwMDBlMDAgLSAweDAwMDAwZWZmICgweDEwMCkgSVhbQl1FCglbMzJdIC0xCTAJ MHgwMDAwMDkwMCAtIDB4MDAwMDA5ZmYgKDB4MTAwKSBJWFtCXUUKCVszM10gLTEJMAkweDAwMDBl YzAwIC0gMHgwMDAwZWM3ZiAoMHg4MCkgSVhbQl0oQikKCVszNF0gMAkwCTB4MDAwMDAzYjAgLSAw eDAwMDAwM2JiICgweGMpIElTW0JdCglbMzVdIDAJMAkweDAwMDAwM2MwIC0gMHgwMDAwMDNkZiAo MHgyMCkgSVNbQl0KKElJKSBMb2FkaW5nIHN1YiBtb2R1bGUgImludDEwIgooSUkpIExvYWRNb2R1 bGU6ICJpbnQxMCIKKElJKSBSZWxvYWRpbmcgL3Vzci9sb2NhbC9saWIveG9yZy9tb2R1bGVzLy9s aWJpbnQxMC5zbwooSUkpIFZFU0EoMCk6IGluaXRpYWxpemluZyBpbnQxMAooPT0pIFZFU0EoMCk6 IFdyaXRlLWNvbWJpbmluZyByYW5nZSAoMHhhMDAwMCwweDIwMDAwKSB3YXMgYWxyZWFkeSBjbGVh cgooSUkpIFZFU0EoMCk6IFByaW1hcnkgVl9CSU9TIHNlZ21lbnQgaXM6IDB4YzAwMAooPT0pIFZF U0EoMCk6IFdyaXRlLWNvbWJpbmluZyByYW5nZSAoMHgwLDB4MTAwMCkgd2FzIGFscmVhZHkgY2xl YXIKKD09KSBWRVNBKDApOiBXcml0ZS1jb21iaW5pbmcgcmFuZ2UgKDB4MCwweDEwMDApIHdhcyBh bHJlYWR5IGNsZWFyCig9PSkgVkVTQSgwKTogV3JpdGUtY29tYmluaW5nIHJhbmdlICgweDAsMHgx MDAwKSB3YXMgYWxyZWFkeSBjbGVhcgooSUkpIFZFU0EoMCk6IFZFU0EgQklPUyBkZXRlY3RlZAoo SUkpIFZFU0EoMCk6IFZFU0EgVkJFIFZlcnNpb24gMy4wCihJSSkgVkVTQSgwKTogVkVTQSBWQkUg VG90YWwgTWVtOiAxNDMzNiBrQgooSUkpIFZFU0EoMCk6IFZFU0EgVkJFIE9FTTogTlZJRElBCihJ SSkgVkVTQSgwKTogVkVTQSBWQkUgT0VNIFNvZnR3YXJlIFJldjogOTguMTE5CihJSSkgVkVTQSgw KTogVkVTQSBWQkUgT0VNIFZlbmRvcjogTlZJRElBIENvcnBvcmF0aW9uCihJSSkgVkVTQSgwKTog VkVTQSBWQkUgT0VNIFByb2R1Y3Q6IE1DUDc3IEJvYXJkIC0gbWNwNzhzbyAKKElJKSBWRVNBKDAp OiBWRVNBIFZCRSBPRU0gUHJvZHVjdCBSZXY6IENoaXAgUmV2ICAgCihXVykgVkVTQSgwKTogRmFp bGVkIHRvIHNldCB3cml0ZS1jb21iaW5pbmcgcmFuZ2UgKDB4ZmIwMDAwMDAsMHhlMDAwMDApCihJ SSkgVkVTQSgwKTogdmlydHVhbCBhZGRyZXNzID0gMHg4MDJlMDAwMDAsCglwaHlzaWNhbCBhZGRy ZXNzID0gMHhmYjAwMDAwMCwgc2l6ZSA9IDE0NjgwMDY0Cig9PSkgVkVTQSgwKTogV3JpdGUtY29t YmluaW5nIHJhbmdlICgweDAsMHgxMDAwKSB3YXMgYWxyZWFkeSBjbGVhcgooPT0pIFZFU0EoMCk6 IFdyaXRlLWNvbWJpbmluZyByYW5nZSAoMHgwLDB4MTAwMCkgd2FzIGFscmVhZHkgY2xlYXIKKD09 KSBWRVNBKDApOiBXcml0ZS1jb21iaW5pbmcgcmFuZ2UgKDB4MCwweDEwMDApIHdhcyBhbHJlYWR5 IGNsZWFyCig9PSkgVkVTQSgwKTogV3JpdGUtY29tYmluaW5nIHJhbmdlICgweDAsMHgxMDAwKSB3 YXMgYWxyZWFkeSBjbGVhcgooPT0pIFZFU0EoMCk6IFdyaXRlLWNvbWJpbmluZyByYW5nZSAoMHgw LDB4MTAwMCkgd2FzIGFscmVhZHkgY2xlYXIKKD09KSBWRVNBKDApOiBXcml0ZS1jb21iaW5pbmcg cmFuZ2UgKDB4MCwweDEwMDApIHdhcyBhbHJlYWR5IGNsZWFyCig9PSkgVkVTQSgwKTogV3JpdGUt Y29tYmluaW5nIHJhbmdlICgweDAsMHgxMDAwKSB3YXMgYWxyZWFkeSBjbGVhcgooPT0pIFZFU0Eo MCk6IFdyaXRlLWNvbWJpbmluZyByYW5nZSAoMHgwLDB4MTAwMCkgd2FzIGFscmVhZHkgY2xlYXIK KD09KSBWRVNBKDApOiBXcml0ZS1jb21iaW5pbmcgcmFuZ2UgKDB4MCwweDEwMDApIHdhcyBhbHJl YWR5IGNsZWFyCig9PSkgVkVTQSgwKTogV3JpdGUtY29tYmluaW5nIHJhbmdlICgweDAsMHgxMDAw KSB3YXMgYWxyZWFkeSBjbGVhcgooPT0pIFZFU0EoMCk6IFdyaXRlLWNvbWJpbmluZyByYW5nZSAo MHgwLDB4MTAwMCkgd2FzIGFscmVhZHkgY2xlYXIKKD09KSBWRVNBKDApOiBXcml0ZS1jb21iaW5p bmcgcmFuZ2UgKDB4MCwweDEwMDApIHdhcyBhbHJlYWR5IGNsZWFyCig9PSkgVkVTQSgwKTogV3Jp dGUtY29tYmluaW5nIHJhbmdlICgweDAsMHgxMDAwKSB3YXMgYWxyZWFkeSBjbGVhcgooPT0pIFZF U0EoMCk6IFdyaXRlLWNvbWJpbmluZyByYW5nZSAoMHgwLDB4MTAwMCkgd2FzIGFscmVhZHkgY2xl YXIKKD09KSBWRVNBKDApOiBEZWZhdWx0IHZpc3VhbCBpcyBUcnVlQ29sb3IKKD09KSBWRVNBKDAp OiBCYWNraW5nIHN0b3JlIGRpc2FibGVkCigqKikgT3B0aW9uICJkcG1zIgooKiopIFZFU0EoMCk6 IERQTVMgZW5hYmxlZAooPT0pIFJhbmRSIGVuYWJsZWQKKElJKSBTZXR0aW5nIHZnYSBmb3Igc2Ny ZWVuIDAuCihJSSkgSW5pdGlhbGl6aW5nIGJ1aWx0LWluIGV4dGVuc2lvbiBNSVQtU0hNCihJSSkg SW5pdGlhbGl6aW5nIGJ1aWx0LWluIGV4dGVuc2lvbiBYSW5wdXRFeHRlbnNpb24KKElJKSBJbml0 aWFsaXppbmcgYnVpbHQtaW4gZXh0ZW5zaW9uIFhURVNUCihJSSkgSW5pdGlhbGl6aW5nIGJ1aWx0 LWluIGV4dGVuc2lvbiBYS0VZQk9BUkQKKElJKSBJbml0aWFsaXppbmcgYnVpbHQtaW4gZXh0ZW5z aW9uIFhDLUFQUEdST1VQCihJSSkgSW5pdGlhbGl6aW5nIGJ1aWx0LWluIGV4dGVuc2lvbiBYQWNj ZXNzQ29udHJvbEV4dGVuc2lvbgooSUkpIEluaXRpYWxpemluZyBidWlsdC1pbiBleHRlbnNpb24g U0VDVVJJVFkKKElJKSBJbml0aWFsaXppbmcgYnVpbHQtaW4gZXh0ZW5zaW9uIFhJTkVSQU1BCihJ SSkgSW5pdGlhbGl6aW5nIGJ1aWx0LWluIGV4dGVuc2lvbiBYRklYRVMKKElJKSBJbml0aWFsaXpp bmcgYnVpbHQtaW4gZXh0ZW5zaW9uIFhGcmVlODYtQmlnZm9udAooSUkpIEluaXRpYWxpemluZyBi dWlsdC1pbiBleHRlbnNpb24gUkVOREVSCihJSSkgSW5pdGlhbGl6aW5nIGJ1aWx0LWluIGV4dGVu c2lvbiBSQU5EUgooSUkpIEluaXRpYWxpemluZyBidWlsdC1pbiBleHRlbnNpb24gQ09NUE9TSVRF CihJSSkgSW5pdGlhbGl6aW5nIGJ1aWx0LWluIGV4dGVuc2lvbiBEQU1BR0UKKElJKSBJbml0aWFs aXppbmcgYnVpbHQtaW4gZXh0ZW5zaW9uIFhFVklFCihJSSkgTG9hZGluZyBzdWIgbW9kdWxlICJH TGNvcmUiCihJSSkgTG9hZE1vZHVsZTogIkdMY29yZSIKKElJKSBMb2FkaW5nIC91c3IvbG9jYWwv bGliL3hvcmcvbW9kdWxlcy9leHRlbnNpb25zLy9saWJHTGNvcmUuc28KKElJKSBNb2R1bGUgR0xj b3JlOiB2ZW5kb3I9IlguT3JnIEZvdW5kYXRpb24iCgljb21waWxlZCBmb3IgMS40LjIsIG1vZHVs ZSB2ZXJzaW9uID0gMS4wLjAKCUFCSSBjbGFzczogWC5PcmcgU2VydmVyIEV4dGVuc2lvbiwgdmVy c2lvbiAwLjMKKElJKSBHTFg6IEluaXRpYWxpemVkIE1FU0EtUFJPWFkgR0wgcHJvdmlkZXIgZm9y IHNjcmVlbiAwCigqKikgT3B0aW9uICJQcm90b2NvbCIgImF1dG8iCigqKikgTW91c2UwOiBEZXZp Y2U6ICIvZGV2L3N5c21vdXNlIgooKiopIE1vdXNlMDogUHJvdG9jb2w6ICJhdXRvIgooKiopIE9w dGlvbiAiQ29yZVBvaW50ZXIiCigqKikgTW91c2UwOiBhbHdheXMgcmVwb3J0cyBjb3JlIGV2ZW50 cwooKiopIE9wdGlvbiAiRGV2aWNlIiAiL2Rldi9zeXNtb3VzZSIKKD09KSBNb3VzZTA6IEVtdWxh dGUzQnV0dG9ucywgRW11bGF0ZTNUaW1lb3V0OiA1MAooKiopIE9wdGlvbiAiWkF4aXNNYXBwaW5n IiAiNCA1IDYgNyIKKCoqKSBNb3VzZTA6IFpBeGlzTWFwcGluZzogYnV0dG9ucyA0LCA1LCA2IGFu ZCA3CigqKikgTW91c2UwOiBCdXR0b25zOiAxMQooKiopIE1vdXNlMDogU2Vuc2l0aXZpdHk6IDEK KCoqKSBPcHRpb24gIkNvcmVLZXlib2FyZCIKKCoqKSBLZXlib2FyZDA6IGFsd2F5cyByZXBvcnRz IGNvcmUgZXZlbnRzCigqKikgT3B0aW9uICJQcm90b2NvbCIgInN0YW5kYXJkIgooKiopIEtleWJv YXJkMDogUHJvdG9jb2w6IHN0YW5kYXJkCigqKikgT3B0aW9uICJBdXRvUmVwZWF0IiAiNTAwIDMw IgooKiopIE9wdGlvbiAiWGtiUnVsZXMiICJ4b3JnIgooKiopIEtleWJvYXJkMDogWGtiUnVsZXM6 ICJ4b3JnIgooKiopIE9wdGlvbiAiWGtiTW9kZWwiICJwYzEwNSIKKCoqKSBLZXlib2FyZDA6IFhr Yk1vZGVsOiAicGMxMDUiCigqKikgT3B0aW9uICJYa2JMYXlvdXQiICJ1cyIKKCoqKSBLZXlib2Fy ZDA6IFhrYkxheW91dDogInVzIgooKiopIE9wdGlvbiAiQ3VzdG9tS2V5Y29kZXMiICJvZmYiCigq KikgS2V5Ym9hcmQwOiBDdXN0b21LZXljb2RlcyBkaXNhYmxlZAooSUkpIGV2YWx1YXRpbmcgZGV2 aWNlIChLZXlib2FyZDApCihJSSkgWElOUFVUOiBBZGRpbmcgZXh0ZW5kZWQgaW5wdXQgZGV2aWNl ICJLZXlib2FyZDAiICh0eXBlOiBLRVlCT0FSRCkKKElJKSBldmFsdWF0aW5nIGRldmljZSAoTW91 c2UwKQooSUkpIFhJTlBVVDogQWRkaW5nIGV4dGVuZGVkIGlucHV0IGRldmljZSAiTW91c2UwIiAo dHlwZTogTU9VU0UpCihJSSkgTW91c2UwOiBTZXR1cEF1dG86IGh3LmlmdHlwZSBpcyA0LCBody5t b2RlbCBpcyAwCihJSSkgTW91c2UwOiBTZXR1cEF1dG86IHByb3RvY29sIGlzIFN5c01vdXNlCltj b25maWcvaGFsXSBjb3VsZG4ndCBpbml0aWFsaXNlIGNvbnRleHQ6IChudWxsKSAoKG51bGwpKQoo PT0pIFZFU0EoMCk6IFdyaXRlLWNvbWJpbmluZyByYW5nZSAoMHgwLDB4MTAwMCkgd2FzIGFscmVh ZHkgY2xlYXIKKD09KSBWRVNBKDApOiBXcml0ZS1jb21iaW5pbmcgcmFuZ2UgKDB4MCwweDEwMDAp IHdhcyBhbHJlYWR5IGNsZWFyCig9PSkgVkVTQSgwKTogV3JpdGUtY29tYmluaW5nIHJhbmdlICgw eDAsMHgxMDAwKSB3YXMgYWxyZWFkeSBjbGVhcgooPT0pIFZFU0EoMCk6IFdyaXRlLWNvbWJpbmlu ZyByYW5nZSAoMHgwLDB4MTAwMCkgd2FzIGFscmVhZHkgY2xlYXIKKD09KSBWRVNBKDApOiBXcml0 ZS1jb21iaW5pbmcgcmFuZ2UgKDB4MCwweDEwMDApIHdhcyBhbHJlYWR5IGNsZWFyCig9PSkgVkVT QSgwKTogV3JpdGUtY29tYmluaW5nIHJhbmdlICgweDAsMHgxMDAwKSB3YXMgYWxyZWFkeSBjbGVh cgpGcmVlRm9udFBhdGg6IEZQRSAiL3Vzci9sb2NhbC9saWIvWDExL2ZvbnRzL21pc2MvIiByZWZj b3VudCBpcyAyLCBzaG91bGQgYmUgMTsgZml4aW5nLgo= ------=_Part_30250_20989668.1228660568621 Content-Type: application/octet-stream; name=xorg.conf Content-Transfer-Encoding: base64 X-Attachment-Id: f_fofsinds2 Content-Disposition: attachment; filename=xorg.conf U2VjdGlvbiAiU2VydmVyTGF5b3V0IgoJSWRlbnRpZmllciAgICAgIlgub3JnIENvbmZpZ3VyZWQi CglTY3JlZW4gICAgICAwICAiU2NyZWVuMCIgMCAwCglJbnB1dERldmljZSAgICAiTW91c2UwIiAi Q29yZVBvaW50ZXIiCglJbnB1dERldmljZSAgICAiS2V5Ym9hcmQwIiAiQ29yZUtleWJvYXJkIgpF bmRTZWN0aW9uCgpTZWN0aW9uICJGaWxlcyIKCVJnYlBhdGggICAgICAiL3Vzci9sb2NhbC9zaGFy ZS9YMTEvcmdiIgoJTW9kdWxlUGF0aCAgICIvdXNyL2xvY2FsL2xpYi94b3JnL21vZHVsZXMiCglG b250UGF0aCAgICAgIi91c3IvbG9jYWwvbGliL1gxMS9mb250cy9taXNjLyIKCUZvbnRQYXRoICAg ICAiL3Vzci9sb2NhbC9saWIvWDExL2ZvbnRzL1RURi8iCglGb250UGF0aCAgICAgIi91c3IvbG9j YWwvbGliL1gxMS9mb250cy9PVEYiCglGb250UGF0aCAgICAgIi91c3IvbG9jYWwvbGliL1gxMS9m b250cy9UeXBlMS8iCglGb250UGF0aCAgICAgIi91c3IvbG9jYWwvbGliL1gxMS9mb250cy8xMDBk cGkvIgoJRm9udFBhdGggICAgICIvdXNyL2xvY2FsL2xpYi9YMTEvZm9udHMvNzVkcGkvIgpFbmRT ZWN0aW9uCgpTZWN0aW9uICJNb2R1bGUiCglMb2FkICAiR0xjb3JlIgoJTG9hZCAgImRiZSIKCUxv YWQgICJkcmkiCglMb2FkICAiZXh0bW9kIgoJTG9hZCAgImdseCIKCUxvYWQgICJyZWNvcmQiCglM b2FkICAieHRyYXAiCglMb2FkICAiZnJlZXR5cGUiCglMb2FkICAidHlwZTEiCkVuZFNlY3Rpb24K ClNlY3Rpb24gIklucHV0RGV2aWNlIgoJSWRlbnRpZmllciAgIktleWJvYXJkMCIKCURyaXZlciAg ICAgICJrYmQiCkVuZFNlY3Rpb24KClNlY3Rpb24gIklucHV0RGV2aWNlIgoJSWRlbnRpZmllciAg Ik1vdXNlMCIKCURyaXZlciAgICAgICJtb3VzZSIKCU9wdGlvbgkgICAgIlByb3RvY29sIiAiYXV0 byIKCU9wdGlvbgkgICAgIkRldmljZSIgIi9kZXYvc3lzbW91c2UiCglPcHRpb24JICAgICJaQXhp c01hcHBpbmciICI0IDUgNiA3IgpFbmRTZWN0aW9uCgpTZWN0aW9uICJNb25pdG9yIgoJSWRlbnRp ZmllciAgICJNb25pdG9yMCIKCVZlbmRvck5hbWUgICAiTW9uaXRvciBWZW5kb3IiCglNb2RlbE5h bWUgICAgIk1vbml0b3IgTW9kZWwiCglIb3JpelN5bmMJMzAuMC04MS4wCglWZXJ0UmVmcmVzaAk1 MC4wLTc2LjAKCU9wdGlvbgkJIkRQTVMiCkVuZFNlY3Rpb24KClNlY3Rpb24gIkRldmljZSIKICAg ICAgICAjIyMgQXZhaWxhYmxlIERyaXZlciBvcHRpb25zIGFyZTotCiAgICAgICAgIyMjIFZhbHVl czogPGk+OiBpbnRlZ2VyLCA8Zj46IGZsb2F0LCA8Ym9vbD46ICJUcnVlIi8iRmFsc2UiLAogICAg ICAgICMjIyA8c3RyaW5nPjogIlN0cmluZyIsIDxmcmVxPjogIjxmPiBIei9rSHovTUh6IgogICAg ICAgICMjIyBbYXJnXTogYXJnIG9wdGlvbmFsCiAgICAgICAgI09wdGlvbiAgICAgIlNoYWRvd0ZC IiAgICAgICAgICAgCSMgWzxib29sPl0KICAgICAgICAjT3B0aW9uICAgICAiRGVmYXVsdFJlZnJl c2giICAgICAJIyBbPGJvb2w+XQogICAgICAgICNPcHRpb24gICAgICJNb2RlU2V0Q2xlYXJTY3Jl ZW4iIAkjIFs8Ym9vbD5dCglJZGVudGlmaWVyICAiQ2FyZDAiCglEcml2ZXIgICAgICAidmVzYSIK CVZlbmRvck5hbWUgICJuVmlkaWEgQ29ycG9yYXRpb24iCglCb2FyZE5hbWUgICAiVW5rbm93biBC b2FyZCIKCUJ1c0lEICAgICAgICJQQ0k6MjowOjAiCkVuZFNlY3Rpb24KClNlY3Rpb24gIlNjcmVl biIKCUlkZW50aWZpZXIgIlNjcmVlbjAiCglEZXZpY2UgICAgICJDYXJkMCIKCU1vbml0b3IgICAg Ik1vbml0b3IwIgoJRGVmYXVsdERlcHRoCTI0CglTdWJTZWN0aW9uICJEaXNwbGF5IgoJCVZpZXdw b3J0ICAgMCAwCgkJRGVwdGggICAgIDI0CgkJTW9kZXMJIjE2ODB4MTA1MCIKCUVuZFN1YlNlY3Rp b24KCVN1YlNlY3Rpb24gIkRpc3BsYXkiCgkJVmlld3BvcnQgICAwIDAKCQlEZXB0aCAgICAgMjQK CUVuZFN1YlNlY3Rpb24KCVN1YlNlY3Rpb24gIkRpc3BsYXkiCgkJVmlld3BvcnQgICAwIDAKCQlE ZXB0aCAgICAgOAoJRW5kU3ViU2VjdGlvbgoJU3ViU2VjdGlvbiAiRGlzcGxheSIKCQlWaWV3cG9y dCAgIDAgMAoJCURlcHRoICAgICAxNQoJRW5kU3ViU2VjdGlvbgoJU3ViU2VjdGlvbiAiRGlzcGxh eSIKCQlWaWV3cG9ydCAgIDAgMAoJCURlcHRoICAgICAxNgoJRW5kU3ViU2VjdGlvbgoJU3ViU2Vj dGlvbiAiRGlzcGxheSIKCQlWaWV3cG9ydCAgIDAgMAoJCURlcHRoICAgICAyNAoJRW5kU3ViU2Vj dGlvbgpFbmRTZWN0aW9uCgo= ------=_Part_30250_20989668.1228660568621-- From owner-freebsd-current@FreeBSD.ORG Sun Dec 7 16:16:37 2008 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 79EBE1065675 for ; Sun, 7 Dec 2008 16:16:37 +0000 (UTC) (envelope-from bsam@ipt.ru) Received: from services.ipt.ru (services.ipt.ru [194.62.233.110]) by mx1.freebsd.org (Postfix) with ESMTP id 356508FC20 for ; Sun, 7 Dec 2008 16:16:37 +0000 (UTC) (envelope-from bsam@ipt.ru) Received: from bb.ipt.ru ([194.62.233.89]) by services.ipt.ru with esmtp (Exim 4.54 (FreeBSD)) id 1L9MJ9-000NRV-Av for freebsd-current@FreeBSD.org; Sun, 07 Dec 2008 19:16:35 +0300 To: freebsd-current@FreeBSD.org From: Boris Samorodov Date: Sun, 07 Dec 2008 19:16:34 +0300 Message-ID: <48202685@bb.ipt.ru> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Subject: gmirror+gjournal, newfs -J: can't figure out file system partition X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Dec 2008 16:16:37 -0000 Hello List, I can't do a newfs for gmirror+gjournal at two days old amd64-current: ----- tba# gmirror label -vb round-robin gm0 ad8 ad12 Metadata value stored on ad8. Metadata value stored on ad12. Done. tba# gmirror load GEOM_MIRROR: Device mirror/gm0 launched (2/2). tba# gjournal label mirror/gm0 ad4s2d tba# gjournal load GEOM_JOURNAL: Journal 3161485294: mirror/gm0 contains data. GEOM_JOURNAL: Journal 3161485294: ad4s2d contains journal. GEOM_JOURNAL: Journal mirror/gm0 clean. tba# newfs -J /dev/mirror/gm0.journal newfs: /dev/mirror/gm0.journal: can't figure out file system partition ----- Am I doing something stupid? Thanks! WBR -- Boris Samorodov (bsam) Research Engineer, http://www.ipt.ru Telephone & Internet SP FreeBSD committer, http://www.FreeBSD.org The Power To Serve From owner-freebsd-current@FreeBSD.ORG Sun Dec 7 16:19:50 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4B3761065670; Sun, 7 Dec 2008 16:19:50 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id D06008FC19; Sun, 7 Dec 2008 16:19:49 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.3/8.14.3/ALCHEMY.FRANKEN.DE) with ESMTP id mB7GJmHC082882; Sun, 7 Dec 2008 17:19:48 +0100 (CET) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.3/8.14.3/Submit) id mB7GJl8w082881; Sun, 7 Dec 2008 17:19:47 +0100 (CET) (envelope-from marius) Date: Sun, 7 Dec 2008 17:19:47 +0100 From: Marius Strobl To: Hans Petter Selasky Message-ID: <20081207161947.GA82662@alchemy.franken.de> References: <20081107082740.GA1334@icarus.home.lan> <200811081023.10058.hselasky@freebsd.org> <200811161408.21562.hselasky@c2i.net> <200812061334.55365.hselasky@c2i.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200812061334.55365.hselasky@c2i.net> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org, Alfred Perlstein , freebsd-usb@freebsd.org Subject: Re: [Serious] busdma bug in -current in relation to USB hardware - review wanted X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Dec 2008 16:19:50 -0000 On Sat, Dec 06, 2008 at 01:34:54PM +0100, Hans Petter Selasky wrote: > Hi, > > After various feedback from several people I have made a new patch proposal > that will fix the busdma problem. > > See: > > http://perforce.freebsd.org/chv.cgi?CH=154181 > > Review wanted! > > I don't know how to patch the psyco interface for SUN. Maybe there is nothing > that needs to be patched? Neither sparc64 nor sun4u has support for bounce buffers; it's not really worth the effort to implement IOMMU-bypass and bounce buffers for the few devices only doing < 32-bit DMA and for >= 32-bit DMA the IOMMU takes care of the address translation for all practical purposes. In any case this isn't specific to psycho(4). Marius From owner-freebsd-current@FreeBSD.ORG Sun Dec 7 16:45:53 2008 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C0B7B1065679 for ; Sun, 7 Dec 2008 16:45:53 +0000 (UTC) (envelope-from bsam@ipt.ru) Received: from services.ipt.ru (services.ipt.ru [194.62.233.110]) by mx1.freebsd.org (Postfix) with ESMTP id 7A2B68FC0C for ; Sun, 7 Dec 2008 16:45:53 +0000 (UTC) (envelope-from bsam@ipt.ru) Received: from bb.ipt.ru ([194.62.233.89]) by services.ipt.ru with esmtp (Exim 4.54 (FreeBSD)) id 1L9MlU-000Nnp-H1 for freebsd-current@FreeBSD.org; Sun, 07 Dec 2008 19:45:52 +0300 To: freebsd-current@FreeBSD.org References: <48202685@bb.ipt.ru> From: Boris Samorodov Date: Sun, 07 Dec 2008 19:45:52 +0300 In-Reply-To: <48202685@bb.ipt.ru> (Boris Samorodov's message of "Sun\, 07 Dec 2008 19\:16\:34 +0300") Message-ID: <82120927@bb.ipt.ru> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Subject: Re: gmirror+gjournal, newfs -J: can't figure out file system partition X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Dec 2008 16:45:53 -0000 Boris Samorodov writes: > I can't do a newfs for gmirror+gjournal at two days old amd64-current: Hm, even gjournal is not newfs'ed: ----- tba# gjournal label ad8 tba# gjournal load GEOM_JOURNAL: Journal 2321310154: ad8 contains data. GEOM_JOURNAL: Journal 2321310154: ad8 contains journal. GEOM_JOURNAL: Journal ad8 clean. tba# newfs -J ad8.journal newfs: /dev/ad8.journal: can't figure out file system partition ----- WBR -- Boris Samorodov (bsam) Research Engineer, http://www.ipt.ru Telephone & Internet SP FreeBSD committer, http://www.FreeBSD.org The Power To Serve From owner-freebsd-current@FreeBSD.ORG Sun Dec 7 17:39:44 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B815A106564A for ; Sun, 7 Dec 2008 17:39:44 +0000 (UTC) (envelope-from marck@rinet.ru) Received: from woozle.rinet.ru (woozle.rinet.ru [195.54.192.68]) by mx1.freebsd.org (Postfix) with ESMTP id 3A2D08FC17 for ; Sun, 7 Dec 2008 17:39:43 +0000 (UTC) (envelope-from marck@rinet.ru) Received: from localhost (localhost [127.0.0.1]) by woozle.rinet.ru (8.14.2/8.14.2) with ESMTP id mB7HdgoO034233; Sun, 7 Dec 2008 20:39:42 +0300 (MSK) (envelope-from marck@rinet.ru) Date: Sun, 7 Dec 2008 20:39:42 +0300 (MSK) From: Dmitry Morozovsky To: Boris Samorodov In-Reply-To: <82120927@bb.ipt.ru> Message-ID: References: <48202685@bb.ipt.ru> <82120927@bb.ipt.ru> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-NCC-RegID: ru.rinet X-OpenPGP-Key-ID: 6B691B03 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0.1 (woozle.rinet.ru [0.0.0.0]); Sun, 07 Dec 2008 20:39:42 +0300 (MSK) Cc: freebsd-current@freebsd.org Subject: Re: gmirror+gjournal, newfs -J: can't figure out file system partition X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Dec 2008 17:39:44 -0000 On Sun, 7 Dec 2008, Boris Samorodov wrote: BS> Boris Samorodov writes: BS> BS> > I can't do a newfs for gmirror+gjournal at two days old amd64-current: BS> BS> Hm, even gjournal is not newfs'ed: BS> ----- BS> tba# gjournal label ad8 BS> tba# gjournal load BS> GEOM_JOURNAL: Journal 2321310154: ad8 contains data. BS> GEOM_JOURNAL: Journal 2321310154: ad8 contains journal. BS> GEOM_JOURNAL: Journal ad8 clean. BS> tba# newfs -J ad8.journal BS> newfs: /dev/ad8.journal: can't figure out file system partition BS> ----- well, what if you create BSD partition inside it: bsdlabel -Bw ad8 gjournal ad8a gjournal load newfs -J ad8a.journal ? Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck@FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From owner-freebsd-current@FreeBSD.ORG Sun Dec 7 18:37:53 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BEFB2106564A for ; Sun, 7 Dec 2008 18:37:53 +0000 (UTC) (envelope-from bsam@ipt.ru) Received: from services.ipt.ru (services.ipt.ru [194.62.233.110]) by mx1.freebsd.org (Postfix) with ESMTP id 7516D8FC18 for ; Sun, 7 Dec 2008 18:37:53 +0000 (UTC) (envelope-from bsam@ipt.ru) Received: from bb.ipt.ru ([194.62.233.89]) by services.ipt.ru with esmtp (Exim 4.54 (FreeBSD)) id 1L9OVs-000PF7-5Y; Sun, 07 Dec 2008 21:37:52 +0300 To: Dmitry Morozovsky References: <48202685@bb.ipt.ru> <82120927@bb.ipt.ru> From: Boris Samorodov Date: Sun, 07 Dec 2008 21:37:51 +0300 In-Reply-To: (Dmitry Morozovsky's message of "Sun\, 7 Dec 2008 20\:39\:42 +0300 \(MSK\)") Message-ID: <05319744@bb.ipt.ru> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: luigi@FreeBSD.org, freebsd-current@freebsd.org Subject: Re: gmirror+gjournal, newfs -J: can't figure out file system partition X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Dec 2008 18:37:53 -0000 Dmitry Morozovsky writes: > On Sun, 7 Dec 2008, Boris Samorodov wrote: > BS> Boris Samorodov writes: > BS> > BS> > I can't do a newfs for gmirror+gjournal at two days old amd64-current: > BS> > BS> Hm, even gjournal is not newfs'ed: > BS> ----- > BS> tba# gjournal label ad8 > BS> tba# gjournal load > BS> GEOM_JOURNAL: Journal 2321310154: ad8 contains data. > BS> GEOM_JOURNAL: Journal 2321310154: ad8 contains journal. > BS> GEOM_JOURNAL: Journal ad8 clean. > BS> tba# newfs -J ad8.journal > BS> newfs: /dev/ad8.journal: can't figure out file system partition > BS> ----- > > well, what if you create BSD partition inside it: > > bsdlabel -Bw ad8 > gjournal ad8a > gjournal load > newfs -J ad8a.journal The same. But: # gjournal label ad8 # gjournal load # bsdlabel -Bw ad8.journal # newfs -J ad8.journala ...was a success. CCing to luigi@. There are chances his recent commit may broke newfs for journal. WBR -- Boris Samorodov (bsam) Research Engineer, http://www.ipt.ru Telephone & Internet SP FreeBSD committer, http://www.FreeBSD.org The Power To Serve From owner-freebsd-current@FreeBSD.ORG Sun Dec 7 18:51:04 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EAE421065670 for ; Sun, 7 Dec 2008 18:51:04 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.251]) by mx1.freebsd.org (Postfix) with ESMTP id 974718FC2E for ; Sun, 7 Dec 2008 18:51:04 +0000 (UTC) (envelope-from onemda@gmail.com) Received: by an-out-0708.google.com with SMTP id b6so339135ana.13 for ; Sun, 07 Dec 2008 10:51:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=gVdd/ubUab4nJk1vcPewiZwkQq+Sp3Qhst69d+9Ncr4=; b=FY1iE8otGOWp0zaJW3SfpSClNkA66YNbPNQ+KY1HIdBOImQsqy426i1198uq5DB8Q2 MFLOg2nEAKrZU78z422qvGcoh9PzoYybVcpTXvY1kkrS2aHzbSnbb6+QieaVuaqyt80j ZTb71mohi+j3Ic9fqokg++/5C0DHK9aq4sYyM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=vODtKExyo5o8spULzCUeUmaunRu16/ezpiiRxlESAcBUIW94cw3CXVlRhtF1mTegng ALf2NJLeyXwxWG57Vq3NocS/A8TTzg38GFSZuxkG2WP0vsCGAirCEpSuuRpblFeVrnQ6 jT6jI6V64YrFq58ZGFXLUWdOx55xeApnETwh0= Received: by 10.231.19.72 with SMTP id z8mr18848iba.42.1228675862636; Sun, 07 Dec 2008 10:51:02 -0800 (PST) Received: by 10.231.16.76 with HTTP; Sun, 7 Dec 2008 10:51:02 -0800 (PST) Message-ID: <3a142e750812071051m51d65581p49640ce5adc3c023@mail.gmail.com> Date: Sun, 7 Dec 2008 19:51:02 +0100 From: "Paul B. Mahol" To: boolome In-Reply-To: <1228461620.1175.1.camel@www.boolome.cn> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1228461620.1175.1.camel@www.boolome.cn> Cc: freebsd-current@freebsd.org Subject: Re: how to config for run compiz fusion X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Dec 2008 18:51:05 -0000 On 12/5/08, boolome wrote: >> On Fri, 2008-12-05 at 11:14 +0800, boolome wrote: >> > Option "AccelMethod" "XAA" >> > Option "XAANoOffscreenPixmaps" "true" >> > Option "AddARGBGLXVisuals" "true" >> >> Try using EXA, which is the default. i.e. comment out all of the > above >> lines. Otherwise, it looks very much like what I run on my 965... > What >> version of FreeBSD are you running? >> >> robert. >> > I have commented the lines you mentioned . but problem same. > %uname -a > FreeBSD www.boolome.cn 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Sun Oct 19 > 16:07:48 CST 2008 > boolome@www.boolome.cn:/usr/obj/usr/src/sys/boolome i386 You are using very old CURRENT. That version of CURRENT is known to have broken DRM/DRI on some intel cards. -- Paul From owner-freebsd-current@FreeBSD.ORG Sun Dec 7 23:03:21 2008 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6B9F11065675 for ; Sun, 7 Dec 2008 23:03:21 +0000 (UTC) (envelope-from regnauld@catpipe.net) Received: from moof.catpipe.net (moof.catpipe.net [129.142.64.64]) by mx1.freebsd.org (Postfix) with ESMTP id 26E018FC0C for ; Sun, 7 Dec 2008 23:03:20 +0000 (UTC) (envelope-from regnauld@catpipe.net) Received: from localhost (unknown [129.142.64.64]) by localhost.catpipe.net (Postfix) with ESMTP id 0777583B70C for ; Sun, 7 Dec 2008 23:30:11 +0100 (CET) X-Virus-Scanned: amavisd-new at catpipe.net Received: from moof.catpipe.net ([129.142.64.64]) by localhost (moof.catpipe.net [129.142.64.64]) (amavisd-new, port 10024) with ESMTP id l1Fp6JAKU9-V for ; Sun, 7 Dec 2008 23:30:10 +0100 (CET) Received: from macbook.catpipe.net (unknown [83.95.48.180]) (Authenticated sender: relayuser) by moof.catpipe.net (Postfix) with ESMTP id 945D783B708 for ; Sun, 7 Dec 2008 23:30:10 +0100 (CET) Received: by macbook.catpipe.net (Postfix, from userid 1001) id 6644526841E; Sun, 7 Dec 2008 23:30:10 +0100 (CET) Date: Sun, 7 Dec 2008 23:30:10 +0100 From: Phil Regnauld To: freebsd-current@FreeBSD.org Message-ID: <20081207223009.GA27635@macbook.catpipe.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.17 (2007-11-01) Cc: Subject: em(4) not sending/receiving data in recent current ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Dec 2008 23:03:21 -0000 Hi all, I recently upgraded a system (Dell Vostro desktop) running 8.0-CURRENT/amd64 from July to -current from a few days ago, and em(4) stopped working. By this I mean: - em0 probes and attaches correctly - link is detected - sending any data to/from the host simply fails tcpdump shows incoming ARP requests and they seem to be accepted by the ARP stack, and pinging another host shows outgoing ARP requests, but nothing is seen on the wire by the other hosts. Anyone else experiencing this, and could this be related to the em/e1000/igb split ? Cheers, Phil em0: port 0xfe00-0xfe1f mem 0xfdfc0000-0xfdfdffff,0xfdfff000-0xfdffffff irq 20 at device 25.0 on pci0 em0: Using MSI interrupt em0: [FILTER] em0: Ethernet address: 00:1d:09:91:25:e4 em0: link state changed to UP From owner-freebsd-current@FreeBSD.ORG Sun Dec 7 23:38:07 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CCAE71065673; Sun, 7 Dec 2008 23:38:07 +0000 (UTC) (envelope-from marck@rinet.ru) Received: from woozle.rinet.ru (woozle.rinet.ru [195.54.192.68]) by mx1.freebsd.org (Postfix) with ESMTP id 4E4708FC1C; Sun, 7 Dec 2008 23:38:06 +0000 (UTC) (envelope-from marck@rinet.ru) Received: from localhost (localhost [127.0.0.1]) by woozle.rinet.ru (8.14.2/8.14.2) with ESMTP id mB7Nc5nk076479; Mon, 8 Dec 2008 02:38:05 +0300 (MSK) (envelope-from marck@rinet.ru) Date: Mon, 8 Dec 2008 02:38:05 +0300 (MSK) From: Dmitry Morozovsky To: Ulf Lilleengen In-Reply-To: <20081201092900.GB1397@nobby.lan> Message-ID: References: <20081125154040.GA12632@nobby.lan> <20081201092900.GB1397@nobby.lan> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-NCC-RegID: ru.rinet X-OpenPGP-Key-ID: 6B691B03 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0.1 (woozle.rinet.ru [0.0.0.0]); Mon, 08 Dec 2008 02:38:05 +0300 (MSK) Cc: freebsd-current@freebsd.org Subject: Re: HEADSUP: CVS/Mirror mode for csup to be merged soon X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Dec 2008 23:38:07 -0000 On Mon, 1 Dec 2008, Ulf Lilleengen wrote: UL> I have gotten some positive reports, thanks for testing! So far, a bug UL> involving SKIP directory handling have been fixed. I still have one report UL> which I'd like to investigate more before getting anything in. In addition, UL> there seems to be performance problems on some files (with many deltas, such UL> as CVSROOT-*/modules,v etc.) due to some slow algorithms used in the RCS UL> handling. I'll try to speed it up a bit when it seems to work ok. Together I found my building machin stuck with csup eating all CPU and non-killable wither by HUP or TERM. It seems csup goes mad after server closing connection for some reason: Rsync CVSROOT-ports/exclude Receiver: Connection reset by peer ... there csup runs and runs... Any comments? Thanks in advance. Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck@FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From owner-freebsd-current@FreeBSD.ORG Sun Dec 7 23:38:21 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 758D6106578A for ; Sun, 7 Dec 2008 23:38:21 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 25C968FC14 for ; Sun, 7 Dec 2008 23:38:20 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by smarthost1.sentex.ca (8.14.3/8.14.3) with ESMTP id mB7NcIps098689; Sun, 7 Dec 2008 18:38:18 -0500 (EST) (envelope-from mike@sentex.net) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.13.8/8.13.3) with ESMTP id mB7NcIOu037177 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 7 Dec 2008 18:38:18 -0500 (EST) (envelope-from mike@sentex.net) Message-Id: <200812072338.mB7NcIOu037177@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 07 Dec 2008 18:38:13 -0500 To: Phil Regnauld , freebsd-current@freebsd.org From: Mike Tancsa In-Reply-To: <20081207223009.GA27635@macbook.catpipe.net> References: <20081207223009.GA27635@macbook.catpipe.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: Re: em(4) not sending/receiving data in recent current ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Dec 2008 23:38:21 -0000 At 05:30 PM 12/7/2008, Phil Regnauld wrote: >Anyone else experiencing this, and could this be related to the >em/e1000/igb split ? My current test box seems to be functioning fine from Dec 5th code igb0: port 0x3020-0x303f mem 0x48420000-0x4843ffff,0x48200000-0x483fffff,0x48444000-0x48447fff irq 16 at device 0.0 on pci1 igb0: Using MSIX interrupts with 6 vectors igb0: [ITHREAD] igb0: [ITHREAD] igb0: [ITHREAD] igb0: [ITHREAD] igb0: [ITHREAD] igb0: [ITHREAD] igb0: Ethernet address: 00:30:48:94:87:68 igb1: port 0x3000-0x301f mem 0x48400000-0x4841ffff,0x48000000-0x481fffff,0x48440000-0x48443fff irq 17 at device 0.1 on pci1 igb1: Using MSIX interrupts with 6 vectors igb1: [ITHREAD] igb1: [ITHREAD] igb1: [ITHREAD] igb1: [ITHREAD] igb1: [ITHREAD] igb1: [ITHREAD] igb1: Ethernet address: 00:30:48:94:87:69 em0: port 0x2000-0x201f mem 0x48680000-0x4869ffff,0x48600000-0x4867ffff irq 17 at device 0.0 on pci5 em0: Using MSI interrupt em0: [FILTER] em0: Ethernet address: 00:15:17:57:21:52 vgapci0: port 0x1000-0x10ff mem 0x40000000-0x47ffffff,0x48540000-0x4854ffff irq 18 at device 4.0 on pci6 em1: port 0x1100-0x113f mem 0x48520000-0x4853ffff,0x48500000-0x4851ffff irq 17 at device 5.0 on pci6 em1: [FILTER] em1: Ethernet address: 00:15:17:57:21:53 em0@pci0:5:0:0: class=0x020000 card=0x348d8086 chip=0x108c8086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '82573E Intel Corporation 82573E Gigabit Ethernet Controller (Copper)' class = network subclass = ethernet cap 01[c8] = powerspec 2 supports D0 D3 current D0 cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message cap 10[e0] = PCI-Express 1 endpoint em1@pci0:6:5:0: class=0x020000 card=0x348d8086 chip=0x10768086 rev=0x05 hdr=0x00 vendor = 'Intel Corporation' device = '82541EI Gigabit Ethernet Controller' class = network subclass = ethernet cap 01[dc] = powerspec 2 supports D0 D3 current D0 cap 07[e4] = PCI-X supports 2048 burst read, 1 split transaction ---Mike From owner-freebsd-current@FreeBSD.ORG Sun Dec 7 23:54:20 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BF0B01065670; Sun, 7 Dec 2008 23:54:20 +0000 (UTC) (envelope-from marck@rinet.ru) Received: from woozle.rinet.ru (woozle.rinet.ru [195.54.192.68]) by mx1.freebsd.org (Postfix) with ESMTP id 3E99B8FC1B; Sun, 7 Dec 2008 23:54:19 +0000 (UTC) (envelope-from marck@rinet.ru) Received: from localhost (localhost [127.0.0.1]) by woozle.rinet.ru (8.14.2/8.14.2) with ESMTP id mB7NsIOh076880; Mon, 8 Dec 2008 02:54:18 +0300 (MSK) (envelope-from marck@rinet.ru) Date: Mon, 8 Dec 2008 02:54:18 +0300 (MSK) From: Dmitry Morozovsky To: Ulf Lilleengen In-Reply-To: Message-ID: References: <20081125154040.GA12632@nobby.lan> <20081201092900.GB1397@nobby.lan> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-NCC-RegID: ru.rinet X-OpenPGP-Key-ID: 6B691B03 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0.1 (woozle.rinet.ru [0.0.0.0]); Mon, 08 Dec 2008 02:54:18 +0300 (MSK) Cc: freebsd-current@freebsd.org Subject: Re: HEADSUP: CVS/Mirror mode for csup to be merged soon X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Dec 2008 23:54:20 -0000 On Mon, 8 Dec 2008, Dmitry Morozovsky wrote: DM> Together I found my building machin stuck with csup eating all CPU and DM> non-killable wither by HUP or TERM. It seems csup goes mad after server closing DM> connection for some reason: DM> DM> Rsync CVSROOT-ports/exclude DM> Receiver: Connection reset by peer DM> ... DM> there csup runs and runs... DM> DM> Any comments? Thanks in advance. Sidenote: for current dataset, I can reliably lock csup in running state right after beginning parsing cvsroot-all collection. I tried two different CVSUP mirrors. I use ZFS on FreeBSD tree at given machine, and have a snapshot in case it would be useful. Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck@FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From owner-freebsd-current@FreeBSD.ORG Mon Dec 8 00:11:48 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 76AA31065672 for ; Mon, 8 Dec 2008 00:11:48 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.180]) by mx1.freebsd.org (Postfix) with ESMTP id 486BC8FC1C for ; Mon, 8 Dec 2008 00:11:48 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: by wa-out-1112.google.com with SMTP id m34so424726wag.27 for ; Sun, 07 Dec 2008 16:11:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type:references; bh=PVK64Q+A70ulqsVenAXzAgvRQvab31SRTC5y5Qw+lAM=; b=GUfoaTwy8BNc2J8gMCGNuT4iHwrfGvowlH9/cCbrzqIOS6DI7j+1dSI+Q4tngdu27x B3t2rk2xII9K2mg+QDlhq2CLTAaSDdYQfO1Seajp3HVNpHWyM42x1ye31eejm4mbrnkp +ieo+BM+53/CabqplWfAGiul7a6GS4bVdXXKo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=dc927zNg30Jdr9fC1KE+tuw+oovT1LJKMdk/Bk56m52S1wNO7+GgxCjzAMziIE+Fuv DpDZDsPLlc2xi9w4/n5m5wtJXQGFt7yqSJ90+WxY5RoT9beq/jZvaaFBe5iRyg39DJN2 pk3BPNdbG5fFmsuRDtFIT/CorI4jB8YZgJqP8= Received: by 10.114.174.2 with SMTP id w2mr1946559wae.195.1228693853635; Sun, 07 Dec 2008 15:50:53 -0800 (PST) Received: by 10.114.235.17 with HTTP; Sun, 7 Dec 2008 15:50:53 -0800 (PST) Message-ID: <2a41acea0812071550g40aaefc2yf0b9ccd6bc7bc981@mail.gmail.com> Date: Sun, 7 Dec 2008 15:50:53 -0800 From: "Jack Vogel" To: "Phil Regnauld" In-Reply-To: <20081207223009.GA27635@macbook.catpipe.net> MIME-Version: 1.0 References: <20081207223009.GA27635@macbook.catpipe.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org Subject: Re: em(4) not sending/receiving data in recent current ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Dec 2008 00:11:48 -0000 Can you please give me pciconf -lv Jack On Sun, Dec 7, 2008 at 2:30 PM, Phil Regnauld > wrote: > Hi all, > > I recently upgraded a system (Dell Vostro desktop) running > 8.0-CURRENT/amd64 from July to -current from a few days ago, > and em(4) stopped working. > > By this I mean: > > - em0 probes and attaches correctly > - link is detected > - sending any data to/from the host simply fails > > tcpdump shows incoming ARP requests and they seem to be accepted > by the ARP stack, and pinging another host shows outgoing ARP requests, but > nothing is seen on the wire by the other hosts. > > Anyone else experiencing this, and could this be related to the > em/e1000/igb split ? > > Cheers, > Phil > > > em0: port 0xfe00-0xfe1f mem > 0xfdfc0000-0xfdfdffff,0xfdfff000-0xfdffffff irq 20 at device 25.0 on pci0 > em0: Using MSI interrupt > em0: [FILTER] > em0: Ethernet address: 00:1d:09:91:25:e4 > em0: link state changed to UP > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Mon Dec 8 01:05:08 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3EE6E1065675 for ; Mon, 8 Dec 2008 01:05:08 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [62.111.66.27]) by mx1.freebsd.org (Postfix) with ESMTP id EA2348FC14 for ; Mon, 8 Dec 2008 01:05:07 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from localhost (amavis.str.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id 3949A41CA7A; Mon, 8 Dec 2008 02:05:06 +0100 (CET) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([62.111.66.27]) by localhost (amavis.str.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id liovMOxcn5zN; Mon, 8 Dec 2008 02:05:05 +0100 (CET) Received: by mail.cksoft.de (Postfix, from userid 66) id DB73441C927; Mon, 8 Dec 2008 02:05:05 +0100 (CET) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id CF00F4448DD; Mon, 8 Dec 2008 01:02:22 +0000 (UTC) Date: Mon, 8 Dec 2008 01:02:22 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Jack Vogel In-Reply-To: <2a41acea0812071550g40aaefc2yf0b9ccd6bc7bc981@mail.gmail.com> Message-ID: <20081208010013.R80401@maildrop.int.zabbadoz.net> References: <20081207223009.GA27635@macbook.catpipe.net> <2a41acea0812071550g40aaefc2yf0b9ccd6bc7bc981@mail.gmail.com> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org, Phil Regnauld Subject: Re: em(4) not sending/receiving data in recent current ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Dec 2008 01:05:08 -0000 On Sun, 7 Dec 2008, Jack Vogel wrote: Hi, > Can you please give me pciconf -lv I think the problem here is that the last driver import nuked one line essential for IPv4. Andrew Thompson readded it a few hours ago. See http://svn.freebsd.org/changeset/base/185748 /bz -- Bjoern A. Zeeb The greatest risk is not taking one. From owner-freebsd-current@FreeBSD.ORG Mon Dec 8 01:46:09 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6301A1065673 for ; Mon, 8 Dec 2008 01:46:09 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.180]) by mx1.freebsd.org (Postfix) with ESMTP id 32B868FC13 for ; Mon, 8 Dec 2008 01:46:08 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: by wa-out-1112.google.com with SMTP id m34so438023wag.27 for ; Sun, 07 Dec 2008 17:46:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type:references; bh=XSaPjt9JI65pcafy3nIpAWdjJCx258NsATh7smKMk2M=; b=UA+k7BV9HeAxoVet9Uy07sbLL+g8dsZVMDIguYmomnb1CZg0ezkzJqorq54yc21row Fbad1lnCL9dnQzyhfDnAX3QB6hYHkpNnJ5j7raIL4PJmMhn2tRDFXMXnRQR4RtKX/glG YXSLJ1HsyQdJ0SrSKm8Yikxp1D++KnXIeXGTk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=nLG1l5zeama/ah1WzZkPiFIGqDQy343IfXI7z244iRqRV0vaWSwvPqCNDaQaY9G8RC 0TRxGswrKtVkxnsaTYwB6F+T2UBjrhLTVDKjmKOYEo+Vh21eJuQtQeF4K+Xzm2t2rgHI bmn06SE09RDcmsWNwKXQfmq5eXFgiKsXDl56Y= Received: by 10.114.125.15 with SMTP id x15mr1994391wac.217.1228700768559; Sun, 07 Dec 2008 17:46:08 -0800 (PST) Received: by 10.114.235.17 with HTTP; Sun, 7 Dec 2008 17:46:08 -0800 (PST) Message-ID: <2a41acea0812071746n2d4b1094mf0631ff9163b3c1a@mail.gmail.com> Date: Sun, 7 Dec 2008 17:46:08 -0800 From: "Jack Vogel" To: "Bjoern A. Zeeb" In-Reply-To: <20081208010013.R80401@maildrop.int.zabbadoz.net> MIME-Version: 1.0 References: <20081207223009.GA27635@macbook.catpipe.net> <2a41acea0812071550g40aaefc2yf0b9ccd6bc7bc981@mail.gmail.com> <20081208010013.R80401@maildrop.int.zabbadoz.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org, Phil Regnauld Subject: Re: em(4) not sending/receiving data in recent current ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Dec 2008 01:46:09 -0000 DUH, and I was SO careful to keep those new #ifdef INET, somehow that header include just flew right on by :) Sorry all!! Jack On Sun, Dec 7, 2008 at 5:02 PM, Bjoern A. Zeeb < bzeeb-lists@lists.zabbadoz.net> wrote: > On Sun, 7 Dec 2008, Jack Vogel wrote: > > Hi, > > Can you please give me pciconf -lv >> > > I think the problem here is that the last driver import nuked one > line essential for IPv4. Andrew Thompson readded it a few hours ago. > See > http://svn.freebsd.org/changeset/base/185748 > > /bz > > -- > Bjoern A. Zeeb The greatest risk is not taking one. > From owner-freebsd-current@FreeBSD.ORG Mon Dec 8 03:24:42 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 45F091065672 for ; Mon, 8 Dec 2008 03:24:42 +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 16E0C8FC13 for ; Mon, 8 Dec 2008 03:24:41 +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 37C7C71EE75; Sun, 7 Dec 2008 22:24:41 -0500 (EST) 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 LyfrkqVq+amQ; Sun, 7 Dec 2008 22:24:41 -0500 (EST) Received: from localhost (daemon.egr.msu.edu [35.9.44.65]) by mx.egr.msu.edu (Postfix) with ESMTP id E8C9B71EE72; Sun, 7 Dec 2008 22:24:40 -0500 (EST) Received: by localhost (Postfix, from userid 21281) id CFFA5A6A; Sun, 7 Dec 2008 22:24:40 -0500 (EST) Date: Sun, 7 Dec 2008 22:24:40 -0500 From: Adam McDougall To: Stefan Bethke Message-ID: <20081208032440.GU93166@egr.msu.edu> References: <20081117205526.GC1733@garage.freebsd.pl> <20081202203308.GA13818@hyperion.scode.org> <200812021254.21242.fjwcash@gmail.com> <20081202232924.GA19134@hyperion.scode.org> <31C70CBC-488A-4A9A-A642-37855E8F1DD1@lassitu.de> <5C97E586-4296-4835-A103-FD273B2D7A4F@lassitu.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5C97E586-4296-4835-A103-FD273B2D7A4F@lassitu.de> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: FreeBSD Current Subject: Re: ZFS gets stuck X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Dec 2008 03:24:42 -0000 On Sun, Dec 07, 2008 at 11:21:13AM +0100, Stefan Bethke wrote: For the past week, I've been stress testing two new boxes by running make -j4 universe. /usr/src is on ufs, /usr/obj on zfs, backed by a single disk pool. Every so often (about once every one or two days), processes start getting wedged on accessing the zfs file systems. FreeBSD lokschuppen.lassitu.de 8.0-CURRENT FreeBSD 8.0-CURRENT #1: Wed Dec 3 07:05:03 UTC 2008 root@lokschuppen.lassitu.de:/usr/obj/usr/ src/sys/EISENBOOT amd64 So far, I've had this in loader.conf: vfs.zfs.arc_max="512M" vfs.zfs.prefetch_disable="1" I'm now adding vfs.zfs.zil_disable="1" to see if that makes a difference. Is there anything in particular people would want me to check out? Kernel is GENERIC minus a number of devices, and without INVARIANTS and WITNESS. I have one system running a recent -current with 2G of ram that would tend to get stuck almost nightly during a nightly rsync, and have been trying to tune it to get rid of the problems. I've made it about 6 days so far using just: vm.kmem_size=2G vm.kmem_size_max=2G vfs.zfs.arc_max=512M With these settings, I had two rsyncs running constantly for probably 12 hours on the first day or two and still once nightly, so far so good. I tried leaving the kmem settings out and while vm.kmem_size_max appeared to auto tune to approx 4.5G, I still had a out of kmem panic (a low number around 600 or 900M, I don't remember) until I boosted both kmem settings to 2G. I previously had ~1.6G for the kmem settings from when that was the highest they could be set, and maybe that wasn't high enough with recent -current because it had hangs every few days as opposed to every few months with zfs "6" (same zfs as in -stable). I might just be having a string of good luck, and the data that rsync transfers might have played a role (it changes a varying amount each day). If it looks fairly stable then I will apply the settings to a different, busier server with ZFS. From owner-freebsd-current@FreeBSD.ORG Mon Dec 8 08:49:27 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AB6C7106564A for ; Mon, 8 Dec 2008 08:49:27 +0000 (UTC) (envelope-from regnauld@catpipe.net) Received: from moof.catpipe.net (moof.catpipe.net [129.142.64.64]) by mx1.freebsd.org (Postfix) with ESMTP id 6122D8FC1A for ; Mon, 8 Dec 2008 08:49:27 +0000 (UTC) (envelope-from regnauld@catpipe.net) Received: from localhost (unknown [129.142.64.64]) by localhost.catpipe.net (Postfix) with ESMTP id 06EFB83B89D; Mon, 8 Dec 2008 09:49:26 +0100 (CET) X-Virus-Scanned: amavisd-new at catpipe.net Received: from moof.catpipe.net ([129.142.64.64]) by localhost (moof.catpipe.net [129.142.64.64]) (amavisd-new, port 10024) with ESMTP id HzZiMp8Dj7un; Mon, 8 Dec 2008 09:49:25 +0100 (CET) Received: from macbook.catpipe.net (flow.catpipe.net [195.249.214.179]) (Authenticated sender: relayuser) by moof.catpipe.net (Postfix) with ESMTP id 466FF83B87F; Mon, 8 Dec 2008 09:49:25 +0100 (CET) Received: by macbook.catpipe.net (Postfix, from userid 1001) id 4163F268704; Mon, 8 Dec 2008 09:49:25 +0100 (CET) Date: Mon, 8 Dec 2008 09:49:25 +0100 From: Phil Regnauld To: Jack Vogel Message-ID: <20081208084924.GA28330@macbook.catpipe.net> References: <20081207223009.GA27635@macbook.catpipe.net> <2a41acea0812071550g40aaefc2yf0b9ccd6bc7bc981@mail.gmail.com> <20081208010013.R80401@maildrop.int.zabbadoz.net> <2a41acea0812071746n2d4b1094mf0631ff9163b3c1a@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2a41acea0812071746n2d4b1094mf0631ff9163b3c1a@mail.gmail.com> X-Operating-System: Darwin 9.5.1 i386 User-Agent: Mutt/1.5.17 (2007-11-01) Cc: "Bjoern A. Zeeb" , freebsd-current@freebsd.org Subject: Re: em(4) not sending/receiving data in recent current ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Dec 2008 08:49:27 -0000 Jack Vogel (jfvogel) writes: > DUH, and I was SO careful to keep those new #ifdef INET, somehow that > header include just flew right on by :) > > Sorry all!! Funny, I have two IPv6 tunnels, rtsold running, IPv6 etc... and I NEVER thought to check if IPv6 was running :) Phil From owner-freebsd-current@FreeBSD.ORG Mon Dec 8 09:55:53 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 304151065672 for ; Mon, 8 Dec 2008 09:55:53 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.239]) by mx1.freebsd.org (Postfix) with ESMTP id 048408FC21 for ; Mon, 8 Dec 2008 09:55:52 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so1103492rvf.43 for ; Mon, 08 Dec 2008 01:55:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=NnZwwEt96CValfX+1/whGTe0rfl62iftP2vQpLdncTs=; b=HSDveU0f+kyEmwOOFaY8BHY/FP60VJ2RFZQxRjMvwrHtSi2k35x57MOnk0mp/0tSt6 VPEfTFRyGX4uKzj1/fXy0stvWTWXa3QQ29zswEVZONo3etKOcA+jTYuaKWDSkJ4KXpX3 AuUD/c0oYPCftBzxarI4/D/dDK6bFaFd7IxOM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=noA1+zX1Uecra9b78qZgeGYOOqahvRQkumtzDcajcsNEBLvmAjKMKVuPLlFyGJV2vr o0hu2lsOw44jrg7KOFJBVauEsRVZuaL/4BSFV5HaDR3j1YqUqooJ1r7K6sHn6xwGbbVc PrSTldD8LmwVzsJjNZb5khF8DU5AOwV2WPMdQ= Received: by 10.141.145.11 with SMTP id x11mr969492rvn.108.1228730152663; Mon, 08 Dec 2008 01:55:52 -0800 (PST) Received: by 10.140.158.13 with HTTP; Mon, 8 Dec 2008 01:55:52 -0800 (PST) Message-ID: <7d6fde3d0812080155y22cc7c0bne1fa0094671355e4@mail.gmail.com> Date: Mon, 8 Dec 2008 01:55:52 -0800 From: "Garrett Cooper" To: boolome In-Reply-To: <1228555830.1186.6.camel@www.boolome.cn> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1228555830.1186.6.camel@www.boolome.cn> Cc: freebsd-current@freebsd.org Subject: Re: make buildworld failed! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Dec 2008 09:55:53 -0000 On Sat, Dec 6, 2008 at 1:30 AM, boolome wrote: [snip] Looks like your source tree is incomplete. -Garrett From owner-freebsd-current@FreeBSD.ORG Mon Dec 8 12:27:23 2008 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 558E11065672 for ; Mon, 8 Dec 2008 12:27:23 +0000 (UTC) (envelope-from vova@sw.ru) Received: from relay.sw.ru (mailhub.sw.ru [195.214.232.25]) by mx1.freebsd.org (Postfix) with ESMTP id B7BA18FC12 for ; Mon, 8 Dec 2008 12:27:21 +0000 (UTC) (envelope-from vova@sw.ru) Received: from vbook.fbsd.ru ([10.30.1.111]) (authenticated bits=0) by relay.sw.ru (8.13.4/8.13.4) with ESMTP id mB8CRINT018983 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Dec 2008 15:27:19 +0300 (MSK) Received: from vova by vbook.fbsd.ru with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L9fCn-0003z0-WB; Mon, 08 Dec 2008 15:27:18 +0300 From: Vladimir Grebenschikov To: Sam Leffler In-Reply-To: <200811301906.mAUJ6Z30099035@svn.freebsd.org> References: <200811301906.mAUJ6Z30099035@svn.freebsd.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Mon, 08 Dec 2008 15:27:17 +0300 Message-Id: <1228739237.1860.21.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 FreeBSD GNOME Team Port Sender: Vladimir Grebenschikov Cc: current Subject: Re: svn commit: r185482 - head/sys/dev/ath/ath_rate/sample X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Dec 2008 12:27:23 -0000 * On Sun, 2008-11-30 at 19:06 +0000, Sam Leffler wrote: > Author: sam > Date: Sun Nov 30 19:06:35 2008 > New Revision: 185482 > URL: http://svn.freebsd.org/changeset/base/185482 > > Log: > Major overhaul: > o eliminate private state indexed by 802.11 rate codes; use the hal's > rate tables directly to get the same info > o calculate a mask of operational rates to optimize lookups and checks > (instead of using for loops and similar) > o optimize size bin operations > o ignore rates marked as "do not use" in the hal phy tables > o fix bug that caused upshifting to break in 11g once the rate dropped > below 11Mb/s > o add more intelligent multi-rate tx schedules > o add support for 1/2 and 1/4 width channels > o add dev.ath.X.sample_stats sysctl to dump runtime statistics to the console > (needs to go up to a user app) > o export more tuning knobs via sysctls (still a couple of magic constants) Looks like, after that commit, I can't use if_ath loaded as module any more: # kldload /boot/kernel/ath_rate.ko kldload: can't load /boot/kernel/ath_rate.ko: No such file or directory # dmesg | tail -n1 link_elf: symbol ath_hal_computetxtime undefined # Yes, I've read UPDATING entry 20081130. But I have no ath_hal entry in my kernel config, I've loaded ath as KLDs. How to fix that problem ? -- Vladimir B. Grebenschikov vova@fbsd.ru From owner-freebsd-current@FreeBSD.ORG Mon Dec 8 12:40:09 2008 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 55B671065672; Mon, 8 Dec 2008 12:40:09 +0000 (UTC) (envelope-from vova@sw.ru) Received: from relay.sw.ru (mailhub.sw.ru [195.214.232.25]) by mx1.freebsd.org (Postfix) with ESMTP id 8153B8FC1E; Mon, 8 Dec 2008 12:40:08 +0000 (UTC) (envelope-from vova@sw.ru) Received: from vbook.fbsd.ru ([10.30.1.111]) (authenticated bits=0) by relay.sw.ru (8.13.4/8.13.4) with ESMTP id mB8Ce34O006622 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Dec 2008 15:40:06 +0300 (MSK) Received: from vova by vbook.fbsd.ru with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L9fP9-0004L1-4v; Mon, 08 Dec 2008 15:40:03 +0300 From: Vladimir Grebenschikov To: Jille Timmermans In-Reply-To: <493D1436.3030606@quis.cx> References: <200811301906.mAUJ6Z30099035@svn.freebsd.org> <1228739237.1860.21.camel@localhost> <493D1436.3030606@quis.cx> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: SWsoft Date: Mon, 08 Dec 2008 15:40:02 +0300 Message-Id: <1228740002.1860.26.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 FreeBSD GNOME Team Port Sender: Vladimir Grebenschikov Cc: Sam Leffler , current Subject: Re: svn commit: r185482 - head/sys/dev/ath/ath_rate/sample X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: vova@fbsd.ru List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Dec 2008 12:40:09 -0000 On Mon, 2008-12-08 at 13:33 +0100, Jille Timmermans wrote: after cd /sys/modules/ath_rate_amrr make all make install kldload /boot/kernel/ath_rate .ko It works now, but why three directories in sys/modules tree make same .ko object: # fgrep ath /sys/modules/Makefile ath \ ath_rate_amrr \ ath_rate_onoe \ ath_rate_sample \ # fgrep KMOD /sys/modules/ath_rate*/Makefile /sys/modules/ath_rate_amrr/Makefile:KMOD= ath_rate /sys/modules/ath_rate_onoe/Makefile:KMOD= ath_rate /sys/modules/ath_rate_sample/Makefile:KMOD= ath_rate # Looks like one overwrites another. What is right behaviour ? > Vladimir Grebenschikov wrote: > > * On Sun, 2008-11-30 at 19:06 +0000, Sam Leffler wrote: > > > >> Author: sam > >> Date: Sun Nov 30 19:06:35 2008 > >> New Revision: 185482 > >> URL: http://svn.freebsd.org/changeset/base/185482 > >> > >> Log: > >> Major overhaul: > >> o eliminate private state indexed by 802.11 rate codes; use the hal's > >> rate tables directly to get the same info > >> o calculate a mask of operational rates to optimize lookups and checks > >> (instead of using for loops and similar) > >> o optimize size bin operations > >> o ignore rates marked as "do not use" in the hal phy tables > >> o fix bug that caused upshifting to break in 11g once the rate dropped > >> below 11Mb/s > >> o add more intelligent multi-rate tx schedules > >> o add support for 1/2 and 1/4 width channels > >> o add dev.ath.X.sample_stats sysctl to dump runtime statistics to the console > >> (needs to go up to a user app) > >> o export more tuning knobs via sysctls (still a couple of magic constants) > >> > > > > Looks like, after that commit, I can't use if_ath loaded as module any > > more: > > > > # kldload /boot/kernel/ath_rate.ko > > kldload: can't load /boot/kernel/ath_rate.ko: No such file or directory > > # dmesg | tail -n1 > > link_elf: symbol ath_hal_computetxtime undefined > > # > > > > Yes, I've read UPDATING entry 20081130. > > But I have no ath_hal entry in my kernel config, > > I've loaded ath as KLDs. > > > > How to fix that problem ? > > > I have the same problem if I load it with kernel modules. > If I compile it into my kernel (with ath, ath_hal and that option (can't > remember it for now)) my system paniced during boot. > I can't get a coredump, but I will try getting a stacktrace with ddb > tonight. > > My Atheros (2413 iirc) wasn't usable before the import (did some > printf's during boot, but I couldn't get ath0 showing up in ifconfig) > I am willing to help debugging if needed. > > -- Jille -- Vladimir B. Grebenschikov vova@fbsd.ru From owner-freebsd-current@FreeBSD.ORG Mon Dec 8 12:49:06 2008 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EFA501065677; Mon, 8 Dec 2008 12:49:06 +0000 (UTC) (envelope-from jille@quis.cx) Received: from mulgore.hexon-is.nl (mulgore.hexon-is.nl [82.94.237.14]) by mx1.freebsd.org (Postfix) with ESMTP id 8A8968FC0C; Mon, 8 Dec 2008 12:49:06 +0000 (UTC) (envelope-from jille@quis.cx) Received: from [10.0.0.72] ([10.15.16.6]) (authenticated bits=0) by mulgore.hexon-is.nl (8.14.1/8.13.8) with ESMTP id mB8CXVpK010448; Mon, 8 Dec 2008 13:33:31 +0100 Message-ID: <493D1436.3030606@quis.cx> Date: Mon, 08 Dec 2008 13:33:58 +0100 From: Jille Timmermans User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Vladimir Grebenschikov References: <200811301906.mAUJ6Z30099035@svn.freebsd.org> <1228739237.1860.21.camel@localhost> In-Reply-To: <1228739237.1860.21.camel@localhost> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Hexon-MailScanner-Information: Please contact the ISP for more information X-Hexon-MailScanner-ID: mB8CXVpK010448 X-Hexon-MailScanner: Found to be clean X-Hexon-MailScanner-From: jille@quis.cx X-Hexon-MailScanner-Watermark: 1229344419.62401@tQML9r3lpPjo19UINuKRlw Cc: Sam Leffler , current Subject: Re: svn commit: r185482 - head/sys/dev/ath/ath_rate/sample X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Dec 2008 12:49:07 -0000 Vladimir Grebenschikov wrote: > * On Sun, 2008-11-30 at 19:06 +0000, Sam Leffler wrote: > >> Author: sam >> Date: Sun Nov 30 19:06:35 2008 >> New Revision: 185482 >> URL: http://svn.freebsd.org/changeset/base/185482 >> >> Log: >> Major overhaul: >> o eliminate private state indexed by 802.11 rate codes; use the hal's >> rate tables directly to get the same info >> o calculate a mask of operational rates to optimize lookups and checks >> (instead of using for loops and similar) >> o optimize size bin operations >> o ignore rates marked as "do not use" in the hal phy tables >> o fix bug that caused upshifting to break in 11g once the rate dropped >> below 11Mb/s >> o add more intelligent multi-rate tx schedules >> o add support for 1/2 and 1/4 width channels >> o add dev.ath.X.sample_stats sysctl to dump runtime statistics to the console >> (needs to go up to a user app) >> o export more tuning knobs via sysctls (still a couple of magic constants) >> > > Looks like, after that commit, I can't use if_ath loaded as module any > more: > > # kldload /boot/kernel/ath_rate.ko > kldload: can't load /boot/kernel/ath_rate.ko: No such file or directory > # dmesg | tail -n1 > link_elf: symbol ath_hal_computetxtime undefined > # > > Yes, I've read UPDATING entry 20081130. > But I have no ath_hal entry in my kernel config, > I've loaded ath as KLDs. > > How to fix that problem ? > I have the same problem if I load it with kernel modules. If I compile it into my kernel (with ath, ath_hal and that option (can't remember it for now)) my system paniced during boot. I can't get a coredump, but I will try getting a stacktrace with ddb tonight. My Atheros (2413 iirc) wasn't usable before the import (did some printf's during boot, but I couldn't get ath0 showing up in ifconfig) I am willing to help debugging if needed. -- Jille From owner-freebsd-current@FreeBSD.ORG Mon Dec 8 14:36:39 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 49AF21065673 for ; Mon, 8 Dec 2008 14:36:39 +0000 (UTC) (envelope-from gavin.atkinson@ury.york.ac.uk) Received: from mail-gw2.york.ac.uk (mail-gw2.york.ac.uk [144.32.128.247]) by mx1.freebsd.org (Postfix) with ESMTP id D43BA8FC1E for ; Mon, 8 Dec 2008 14:36:38 +0000 (UTC) (envelope-from gavin.atkinson@ury.york.ac.uk) Received: from mail-gw7.york.ac.uk (mail-gw7.york.ac.uk [144.32.129.30]) by mail-gw2.york.ac.uk (8.13.6/8.13.6) with ESMTP id mB8EaPlO002861; Mon, 8 Dec 2008 14:36:25 GMT 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 1L9hDl-00025U-4a; Mon, 08 Dec 2008 14:36:25 +0000 Received: from buffy.york.ac.uk (localhost [127.0.0.1]) by buffy.york.ac.uk (8.14.2/8.14.2) with ESMTP id mB8EaOV3027664; Mon, 8 Dec 2008 14:36:24 GMT (envelope-from gavin.atkinson@ury.york.ac.uk) Received: (from ga9@localhost) by buffy.york.ac.uk (8.14.2/8.14.2/Submit) id mB8EaOrk027663; Mon, 8 Dec 2008 14:36:24 GMT (envelope-from gavin.atkinson@ury.york.ac.uk) X-Authentication-Warning: buffy.york.ac.uk: ga9 set sender to gavin.atkinson@ury.york.ac.uk using -f From: Gavin Atkinson To: "Conrad J. Sabatier" In-Reply-To: <20081206190754.6c2bbd70@serene.no-ip.org> References: <20081128234155.0221e263@serene.no-ip.org> <4930D7CE.4080909@psg.com> <20081202220643.72eb52a3@serene.no-ip.org> <20081203151537.GA1045@phenom.cordula.ws> <20081206190754.6c2bbd70@serene.no-ip.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Mon, 08 Dec 2008 14:36:23 +0000 Message-Id: <1228746983.27498.1.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.atkinson@ury.york.ac.uk Cc: freebsd-current@freebsd.org, cpghost Subject: Re: i give up X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Dec 2008 14:36:39 -0000 On Sat, 2008-12-06 at 19:07 -0600, Conrad J. Sabatier wrote: > I'm continuing to hold out hope that I can provide the missing bits of > the puzzle that will lead to a solution. But I've already passed along > everything I could get from Windows Vista's System Information tool, > Linux's lspci command, and FreeBSD's pciconf and dmesg. I don't know > what more iI can provide at this point. You could perhaps provide it again? I've still not seen it. > As another poster suggested, it's possible there's a bug/typo in the > patches Soren sent me, although they all apply quite cleanly to every > successive version of current I've tried them on. So...I'm at a loss > at this point. It really is frustrating. > > I'm no fan of either Windows or Linux, but at least they do recognize > my hardware. So I'm stuck for the time being. > > If anyone's interested, I'll repost or mail directly to them all the > pertinent info I can gather. Just say the word and it shall be done. Please. Gavin From owner-freebsd-current@FreeBSD.ORG Mon Dec 8 14:58:16 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DBDC8106564A for ; Mon, 8 Dec 2008 14:58:16 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.29]) by mx1.freebsd.org (Postfix) with ESMTP id 99E598FC18 for ; Mon, 8 Dec 2008 14:58:16 +0000 (UTC) (envelope-from onemda@gmail.com) Received: by yx-out-2324.google.com with SMTP id 8so444385yxb.13 for ; Mon, 08 Dec 2008 06:58:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:mime-version:content-type:content-transfer-encoding :content-disposition; bh=nEnN4Eo+W+Kju/S+Jxe0ynOmBw3o9laYmXPtHcXE+sQ=; b=wrWaHcOagryBj6DOR/b1/5d0QEP2UhMMC2i9mRyTSh2fH874341aESVI6GsYGeDrI/ L44Btnk0bnIx6ugdLKJWf2+fs8RDbInjMx84WEMiJFav8OObvwfVWfeVwJNYOL53bxlg oxfPif1/wM1aqc5pbnJQzZZEh/95hY/Cb/YiY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type :content-transfer-encoding:content-disposition; b=gjXdL2Sm1fK9lEKaIgYNXeptmsYQY3lc+IQkBpBhoc4YQz8z079v+hJGxM/wQM1BgG oN49K7VvPoCMP0MXrx+GgqFUsFY1yF57y51VRzQhb2f2mvs+YEjAM+UzTYB/XTOY7KJp j9FHnbxIzDeAJBoA0/CatlLS2+pnJoM6CbuvA= Received: by 10.231.30.198 with SMTP id v6mr26291ibc.26.1228748295252; Mon, 08 Dec 2008 06:58:15 -0800 (PST) Received: by 10.231.16.76 with HTTP; Mon, 8 Dec 2008 06:58:15 -0800 (PST) Message-ID: <3a142e750812080658r645dc1c4sdd612585fe9ad7d6@mail.gmail.com> Date: Mon, 8 Dec 2008 15:58:15 +0100 From: "Paul B. Mahol" To: "current@freebsd.org" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: Subject: panic: _rw_wlock_hard: recursing but non-recursive rw radix node head X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Dec 2008 14:58:16 -0000 I got panic, after pressing shutdown button: FreeBSD dhcppc1 8.0-CURRENT FreeBSD 8.0-CURRENT #3: Mon Dec 8 12:39:23 CET 2008 root@dhcppc1:/usr/obj/usr/src/sys/KERNEL i386 db:1:lockinfo> show locks db:1:locks> show alllocks Process 994 (wpa_supplicant) thread 0xc4756900 (100112) db:1:alllocks> show lockedvnods Locked vnodes db:0:kdb.enter.panic> show pcpu cpuid = 0 curthread = 0xc4756900: pid 994 "wpa_supplicant" curpcb = 0xe6518d90 fpcurthread = none idlethread = 0xc3d0ab40: pid 10 "idle: cpu0" APIC ID = 0 currentldt = 0x50 spin locks held: db:0:kdb.enter.panic> bt Tracing pid 994 tid 100112 td 0xc4756900 kdb_enter(c06181da,c06181da,c0617bc2,e6518868,0,...) at kdb_enter+0x3a panic(c0617bc2,c0603f55,c061e0eb,c0627193,3a9,...) at panic+0x136 _rw_wlock_hard(c3e53280,c4756900,c0627193,3a9,0,...) at _rw_wlock_hard+0x66 _rw_wlock(c3e53280,c0627193,3a9,c061da2b,3,...) at _rw_wlock+0xae rtrequest1_fib(2,e6518920,0,0,0,...) at rtrequest1_fib+0x92 rtrequest_fib(2,c59b2500,0,0,20405,...) at rtrequest_fib+0x5e rt_fixdelete(c59c10f0,c4124e10,22,c4124e10,c4124e74,...) at rt_fixdelete+0x51 rn_walktree_from(c3e53200,e6518a54,c47e8370,c054fa60,c4124e10,...) at rn_walktree_from+0xd6 rtrequest1_fib(2,e6518a20,e6518a50,0,c4744a00,...) at rtrequest1_fib+0x1ad rtinit(c4744a00,2,0,c4744a00,c06586c0,...) at rtinit+0x2d4 in_ifscrub(c3e6ec00,c4744a00,c06586c0,c06582fc,e6518b38,...) at in_ifscrub+0xed rip_ctlinput(0,c4744ab4,0,c4744a00,c3e6ec00,...) at rip_ctlinput+0x49 pfctlinput(0,c4744ab4,80206910,8842,e6518bb0,...) at pfctlinput+0x3b if_down(c3e6ec00,18f,c07ece44,63a,c3e6ec00,...) at if_down+0x36 ifhwioctl(c4756900,c07bfdc8,c47569a4,c07bfdc8,c064ded0,...) at ifhwioctl+0x2f9 ifioctl(c412e7a8,80206910,c477f440,c4756900,80206910,...) at ifioctl+0x301 soo_ioctl(c4016d20,80206910,c477f440,c4111d00,c4756900,...) at soo_ioctl+0x397 kern_ioctl(c4756900,3,80206910,c477f440,c477f440,...) at kern_ioctl+0x1dd ioctl(c4756900,e6518cf8,c,c063bd0b,c0646070,...) at ioctl+0x12f syscall(e6518d38) at syscall+0x283 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (54, FreeBSD ELF32, ioctl), eip = 0x28370063, esp = 0xbfbfe77c, ebp = 0xbfbfe7e8 --- <118>Stopping moused. <118>Stopping powerd. <118>Stopping devd. <118>Writing entropy file: <118>. <118>. <118>Dec 8 15:08:04 syslogd: exiting on signal 15 panic: _rw_wlock_hard: recursing but non-recursive rw radix node head @ /usr/src/sys/net/route.c:937 cpuid = 0 KDB: enter: panic exclusive sleep mutex rtentry (rtentry) r = 0 (0xc4124e74) locked @ /usr/src/sys/net/route.c:1019 exclusive rw radix node head (radix node head) r = 0 (0xc3e53280) locked @ /usr/src/sys/net/route.c:937 exclusive sleep mutex rtentry (rtentry) r = 0 (0xc4124e74) locked @ /usr/src/sys/net/route.c:1019 exclusive rw radix node head (radix node head) r = 0 (0xc3e53280) locked @ /usr/src/sys/net/route.c:937 -- Paul From owner-freebsd-current@FreeBSD.ORG Mon Dec 8 15:30:19 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CAF19106564A for ; Mon, 8 Dec 2008 15:30:19 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.231]) by mx1.freebsd.org (Postfix) with ESMTP id 94FF68FC12 for ; Mon, 8 Dec 2008 15:30:19 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so1218645rvf.43 for ; Mon, 08 Dec 2008 07:30:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=oHysyg3oKPckJPam6ecUgKCEHiFdAeuSrTlHikdIR7s=; b=SRN1uziwdeeOKlRydUyv+NhkjohE+oFmn7vJuOmwqlrGBU0pEnx9xp1MNbt3KUlzpF BWci7FlBpiW9uVa+pQipSlPNQq++I5/tHQhTbpy6CDZnFSnqDf9ZSbg0f2Ci7HRtlYSV Pgk066we5dL4WOyipTueQhJ9a0Y8uz/rLNuvw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=ijSOmXC0/5kVomvbJNBAGxWlSITIqCBLQxqzsFTrNLOedBvgky4e4ZueZIBNdiVUax ptNnhFtpH2mdlcs5UqCCkXPo6O5RzunLHhb0kIuR6QuVACx/KiMETdh0YvC+uSx4H03C 0qKA1B2KDeDEN9AnqVjzPTlqXLGnkDyeUBPvQ= Received: by 10.141.115.6 with SMTP id s6mr1694970rvm.235.1228750218646; Mon, 08 Dec 2008 07:30:18 -0800 (PST) Received: by 10.141.142.3 with HTTP; Mon, 8 Dec 2008 07:30:18 -0800 (PST) Message-ID: <3c1674c90812080730k7f5cc57cqcd41c574cc46ae3d@mail.gmail.com> Date: Mon, 8 Dec 2008 07:30:18 -0800 From: "Kip Macy" Sender: mat.macy@gmail.com To: "Paul B. Mahol" In-Reply-To: <3a142e750812080658r645dc1c4sdd612585fe9ad7d6@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <3a142e750812080658r645dc1c4sdd612585fe9ad7d6@mail.gmail.com> X-Google-Sender-Auth: 0ea0ecd86dc3f744 Cc: "current@freebsd.org" Subject: Re: panic: _rw_wlock_hard: recursing but non-recursive rw radix node head X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Dec 2008 15:30:19 -0000 Will post a fix this afternoon. Thanks, Kip On Mon, Dec 8, 2008 at 6:58 AM, Paul B. Mahol wrote: > I got panic, after pressing shutdown button: > > FreeBSD dhcppc1 8.0-CURRENT FreeBSD 8.0-CURRENT #3: Mon Dec 8 12:39:23 CET 2008 > root@dhcppc1:/usr/obj/usr/src/sys/KERNEL i386 > > db:1:lockinfo> show locks > db:1:locks> show alllocks > Process 994 (wpa_supplicant) thread 0xc4756900 (100112) > db:1:alllocks> show lockedvnods > Locked vnodes > db:0:kdb.enter.panic> show pcpu > cpuid = 0 > curthread = 0xc4756900: pid 994 "wpa_supplicant" > curpcb = 0xe6518d90 > fpcurthread = none > idlethread = 0xc3d0ab40: pid 10 "idle: cpu0" > APIC ID = 0 > currentldt = 0x50 > spin locks held: > db:0:kdb.enter.panic> bt > Tracing pid 994 tid 100112 td 0xc4756900 > kdb_enter(c06181da,c06181da,c0617bc2,e6518868,0,...) at kdb_enter+0x3a > panic(c0617bc2,c0603f55,c061e0eb,c0627193,3a9,...) at panic+0x136 > _rw_wlock_hard(c3e53280,c4756900,c0627193,3a9,0,...) at _rw_wlock_hard+0x66 > _rw_wlock(c3e53280,c0627193,3a9,c061da2b,3,...) at _rw_wlock+0xae > rtrequest1_fib(2,e6518920,0,0,0,...) at rtrequest1_fib+0x92 > rtrequest_fib(2,c59b2500,0,0,20405,...) at rtrequest_fib+0x5e > rt_fixdelete(c59c10f0,c4124e10,22,c4124e10,c4124e74,...) at rt_fixdelete+0x51 > rn_walktree_from(c3e53200,e6518a54,c47e8370,c054fa60,c4124e10,...) at > rn_walktree_from+0xd6 > rtrequest1_fib(2,e6518a20,e6518a50,0,c4744a00,...) at rtrequest1_fib+0x1ad > rtinit(c4744a00,2,0,c4744a00,c06586c0,...) at rtinit+0x2d4 > in_ifscrub(c3e6ec00,c4744a00,c06586c0,c06582fc,e6518b38,...) at in_ifscrub+0xed > rip_ctlinput(0,c4744ab4,0,c4744a00,c3e6ec00,...) at rip_ctlinput+0x49 > pfctlinput(0,c4744ab4,80206910,8842,e6518bb0,...) at pfctlinput+0x3b > if_down(c3e6ec00,18f,c07ece44,63a,c3e6ec00,...) at if_down+0x36 > ifhwioctl(c4756900,c07bfdc8,c47569a4,c07bfdc8,c064ded0,...) at ifhwioctl+0x2f9 > ifioctl(c412e7a8,80206910,c477f440,c4756900,80206910,...) at ifioctl+0x301 > soo_ioctl(c4016d20,80206910,c477f440,c4111d00,c4756900,...) at soo_ioctl+0x397 > kern_ioctl(c4756900,3,80206910,c477f440,c477f440,...) at kern_ioctl+0x1dd > ioctl(c4756900,e6518cf8,c,c063bd0b,c0646070,...) at ioctl+0x12f > syscall(e6518d38) at syscall+0x283 > Xint0x80_syscall() at Xint0x80_syscall+0x20 > --- syscall (54, FreeBSD ELF32, ioctl), eip = 0x28370063, esp = > 0xbfbfe77c, ebp = 0xbfbfe7e8 --- > > > > > <118>Stopping moused. > <118>Stopping powerd. > <118>Stopping devd. > <118>Writing entropy file: > <118>. > <118>. > <118>Dec 8 15:08:04 syslogd: exiting on signal 15 > panic: _rw_wlock_hard: recursing but non-recursive rw radix node head > @ /usr/src/sys/net/route.c:937 > > cpuid = 0 > KDB: enter: panic > exclusive sleep mutex rtentry (rtentry) r = 0 (0xc4124e74) locked @ > /usr/src/sys/net/route.c:1019 > exclusive rw radix node head (radix node head) r = 0 (0xc3e53280) > locked @ /usr/src/sys/net/route.c:937 > exclusive sleep mutex rtentry (rtentry) r = 0 (0xc4124e74) locked @ > /usr/src/sys/net/route.c:1019 > exclusive rw radix node head (radix node head) r = 0 (0xc3e53280) > locked @ /usr/src/sys/net/route.c:937 > > > -- > Paul > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > -- If we desire respect for the law, we must first make the law respectable. - Louis D. Brandeis From owner-freebsd-current@FreeBSD.ORG Mon Dec 8 16:21:26 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 374D2106567E for ; Mon, 8 Dec 2008 16:21:26 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id B27F98FC12 for ; Mon, 8 Dec 2008 16:21:25 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by smarthost1.sentex.ca (8.14.3/8.14.3) with ESMTP id mB8GLMpv093682 for ; Mon, 8 Dec 2008 11:21:23 -0500 (EST) (envelope-from mike@sentex.net) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.13.8/8.13.3) with ESMTP id mB8GLMxB041498 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 8 Dec 2008 11:21:22 -0500 (EST) (envelope-from mike@sentex.net) Message-Id: <200812081621.mB8GLMxB041498@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 08 Dec 2008 11:21:03 -0500 To: freebsd-current@freebsd.org From: Mike Tancsa Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Subject: uart vs sio differences ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Dec 2008 16:21:26 -0000 Hi, We are in the process of migrating one of our embedded apps to use uart by default instead of sio in RELENG_7 in prep for the day when sio eventually disappears. (The same problems we are having happen as well on HEAD, so I am posting here). Unfortunately, the application doesnt want to work with uart with puc backed devices, but still works with sio. Stranger still, the app works with the uart driver when uart attaches to the built in com port on the isa bus. However, its uart devices when its connected to a PUC backed serial card where the problems happen. e.g. when the uart driver attaches as so, puc0: port 0xe520-0xe53f,0xe540-0xe55f mem 0xa0005000-0xa0005fff,0xa0006000-0xa0006fff irq 15 at device 17.0 on pci0 puc0: [FILTER] uart0: <16950 or compatible> on puc0 uart0: [FILTER] uart1: <16950 or compatible> on puc0 uart1: [FILTER] uart2: <16950 or compatible> on puc0 uart2: [FILTER] uart3: <16950 or compatible> on puc0 uart3: [FILTER] the applications does not work. When its the sio driver, it works as expected. Not sure if thats an issue of the larger buffers of the 16950 vs 16650? i.e. sio sees it as a plain old 16550 vs uart seeing it as a 16950 puc0: port 0xe520-0xe53f,0xe540-0xe55f mem 0xa0005000-0xa0005fff,0xa0006000-0xa0006fff irq 15 at device 17.0 on pci0 puc0: [FILTER] sio1 on puc0 sio1: type 16550A sio1: [FILTER] sio2 on puc0 sio2: type 16550A sio2: [FILTER] sio3 on puc0 sio3: type 16550A sio3: [FILTER] sio4 on puc0 sio4: type 16550A sio4: [FILTER] Unfortunately, we only control the FreeBSD side of things and the other end of the serial connection is a windows app we dont control. Everything seems to work ok from our side, but the other side which we dont control seems to be missing some things we are sending it and vice versa. However, if I use something like minicom or cu, I see 2 way communication just fine and I can transfer data back and forth just fine. Is it possible some defaults are different from sio to uart that our app might not be setting properly when opening up the port ? The open routine is below static int open_dev(struct dev *dev) { struct termios t; int val; cur_state.carrier = 0; if (cur_state.num_trans == 0) { cur_state.startup = time(0); } TRY_OPEN_AGAIN: dev->fd = open(dev->name, O_RDWR); if (dev->fd >= 0) { if (debug) { syslog(LOG_LOCAL1 | LOG_DEBUG, "(%s) %s:%d: open_dev", dev->name, __FILE__, __LINE__); } if (tcgetattr(dev->fd, &t) >= 0) { t.c_ispeed = dev->speed; t.c_ospeed = dev->speed; t.c_lflag &= ~(ICANON | ISIG | IEXTEN | ECHO | ECHOE | ECHOK | ECHOKE | ECHONL | ECHOCTL | ECHOPRT | ALTWERASE | NOFLSH | TOSTOP | FLUSHO | PENDIN | NOKERNINFO | EXTPROC); t.c_iflag &= ~(ISTRIP | ICRNL | INLCR | IGNCR | IXON | IXOFF | IXANY | IMAXBEL | IGNBRK | BRKINT | INPCK | IGNPAR | PARM RK); t.c_oflag &= ~(OPOST | ONLCR | OCRNL | OXTABS | ONOEOT | ONOCR | ONLRET); t.c_cflag &= ~(CSIZE | CSTOPB | PARENB | CCTS_OFLOW | CRTS_IFLOW | CDTR_IFLOW | CDSR_OFLOW | CCAR_OFLOW); t.c_cflag |= (CS8); t.c_cc[VMIN] = 1; t.c_cc[VTIME] = 0; tcsetattr(dev->fd, TCSANOW, &t); val = fcntl(dev->fd, F_GETFL, 0); if (val >= 0) { fcntl(dev->fd, F_SETFL, val | O_NONBLOCK); } } else { tcflush(dev->fd, TCIOFLUSH); close(dev->fd); dev->fd = -1; } } else { if (errno == EINTR) goto TRY_OPEN_AGAIN; syslog(LOG_LOCAL1 | LOG_DEBUG, "(%s) open_dev errno=%d %s", dev->name, errno, strerror(errno)); } return dev->fd; } ---Mike -------------------------------------------------------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet since 1994 www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike From owner-freebsd-current@FreeBSD.ORG Mon Dec 8 18:49:52 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 36168106564A for ; Mon, 8 Dec 2008 18:49:52 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout022.mac.com (asmtpout022.mac.com [17.148.16.97]) by mx1.freebsd.org (Postfix) with ESMTP id 22E908FC08 for ; Mon, 8 Dec 2008 18:49:51 +0000 (UTC) (envelope-from xcllnt@mac.com) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Received: from mahamuni-t43.jnpr.net (natint3.juniper.net [66.129.224.36]) by asmtp022.mac.com (Sun Java(tm) System Messaging Server 6.3-7.03 (built Aug 7 2008; 32bit)) with ESMTPSA id <0KBK00M6VMZ36D70@asmtp022.mac.com> for freebsd-current@freebsd.org; Mon, 08 Dec 2008 10:49:51 -0800 (PST) Message-id: From: Marcel Moolenaar To: Mike Tancsa In-reply-to: <200812081621.mB8GLMxB041498@lava.sentex.ca> Date: Mon, 08 Dec 2008 10:49:51 -0800 References: <200812081621.mB8GLMxB041498@lava.sentex.ca> X-Mailer: Apple Mail (2.929.2) Cc: freebsd-current@freebsd.org Subject: Re: uart vs sio differences ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Dec 2008 18:49:52 -0000 On Dec 8, 2008, at 8:21 AM, Mike Tancsa wrote: > Unfortunately, we only control the FreeBSD side of things and the > other end of the serial connection is a windows app we dont > control. Everything seems to work ok from our side, but the other > side which we dont control seems to be missing some things we are > sending it and vice versa. It looks to me that flow-control is disabled, is that right? Not only does uart(4) make use of the larger buffer of the hardware, it's also more efficient under puc(4) than sio(4) is because of the use of the serdev I/F. It's possible that the receiver can not keep up when uart(4) is used. A serial line analyzer should tell you more... FYI, -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-current@FreeBSD.ORG Mon Dec 8 19:06:53 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 744A91065676 for ; Mon, 8 Dec 2008 19:06:53 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 3CAFC8FC21 for ; Mon, 8 Dec 2008 19:06:53 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by smarthost1.sentex.ca (8.14.3/8.14.3) with ESMTP id mB8J6p3p066039; Mon, 8 Dec 2008 14:06:51 -0500 (EST) (envelope-from mike@sentex.net) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.13.8/8.13.3) with ESMTP id mB8J6oha042222 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Dec 2008 14:06:50 -0500 (EST) (envelope-from mike@sentex.net) Message-Id: <200812081906.mB8J6oha042222@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 08 Dec 2008 14:06:48 -0500 To: Marcel Moolenaar From: Mike Tancsa In-Reply-To: References: <200812081621.mB8GLMxB041498@lava.sentex.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: freebsd-current@freebsd.org Subject: Re: uart vs sio differences ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Dec 2008 19:06:53 -0000 At 01:49 PM 12/8/2008, Marcel Moolenaar wrote: >On Dec 8, 2008, at 8:21 AM, Mike Tancsa wrote: > >>Unfortunately, we only control the FreeBSD side of things and the >>other end of the serial connection is a windows app we dont >>control. Everything seems to work ok from our side, but the other >>side which we dont control seems to be missing some things we are >>sending it and vice versa. > >It looks to me that flow-control is disabled, is that right? > >Not only does uart(4) make use of the larger buffer of the >hardware, it's also more efficient under puc(4) than sio(4) >is because of the use of the serdev I/F. It's possible that >the receiver can not keep up when uart(4) is used. A serial >line analyzer should tell you more... Hi, Yes, flow control is supposed to be disabled. When we hook up a serial line analyzer, the behaviour is rather odd. We only use 1200bps, so I dont think its a speed issue. Also, as part of the protocol, we poll the other side. We send a 3 byte poll, which the Windows side always sees, and it sends us back a 1 byte answer, which we see fine. However, when the Windows side has "something to say", it will send a different 1 byte response (which we get) and then the data, which is approximately 100 to 200 bytes which we only get about 30 bytes of. ---Mike From owner-freebsd-current@FreeBSD.ORG Mon Dec 8 19:18:10 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EB70B1065670 for ; Mon, 8 Dec 2008 19:18:10 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout019.mac.com (asmtpout019.mac.com [17.148.16.94]) by mx1.freebsd.org (Postfix) with ESMTP id D693F8FC0C for ; Mon, 8 Dec 2008 19:18:10 +0000 (UTC) (envelope-from xcllnt@mac.com) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Received: from sbansal-mbp.jnpr.net (natint3.juniper.net [66.129.224.36]) by asmtp019.mac.com (Sun Java(tm) System Messaging Server 6.3-7.03 (built Aug 7 2008; 32bit)) with ESMTPSA id <0KBK002WNOA9KJ40@asmtp019.mac.com> for freebsd-current@freebsd.org; Mon, 08 Dec 2008 11:18:10 -0800 (PST) Message-id: From: Marcel Moolenaar To: Mike Tancsa In-reply-to: <200812081906.mB8J6oha042222@lava.sentex.ca> Date: Mon, 08 Dec 2008 11:18:08 -0800 References: <200812081621.mB8GLMxB041498@lava.sentex.ca> <200812081906.mB8J6oha042222@lava.sentex.ca> X-Mailer: Apple Mail (2.929.2) Cc: freebsd-current@freebsd.org Subject: Re: uart vs sio differences ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Dec 2008 19:18:11 -0000 On Dec 8, 2008, at 11:06 AM, Mike Tancsa wrote: > At 01:49 PM 12/8/2008, Marcel Moolenaar wrote: > >> On Dec 8, 2008, at 8:21 AM, Mike Tancsa wrote: >> >>> Unfortunately, we only control the FreeBSD side of things and the >>> other end of the serial connection is a windows app we dont >>> control. Everything seems to work ok from our side, but the other >>> side which we dont control seems to be missing some things we are >>> sending it and vice versa. >> >> It looks to me that flow-control is disabled, is that right? >> >> Not only does uart(4) make use of the larger buffer of the >> hardware, it's also more efficient under puc(4) than sio(4) >> is because of the use of the serdev I/F. It's possible that >> the receiver can not keep up when uart(4) is used. A serial >> line analyzer should tell you more... > > Hi, > Yes, flow control is supposed to be disabled. When we hook > up a serial line analyzer, the behaviour is rather odd. We only use > 1200bps, so I dont think its a speed issue. Also, as part of the > protocol, we poll the other side. We send a 3 byte poll, which the > Windows side always sees, and it sends us back a 1 byte answer, > which we see fine. However, when the Windows side has "something to > say", it will send a different 1 byte response (which we get) and > then the data, which is approximately 100 to 200 bytes which we only > get about 30 bytes of. I see, so the FreeBSD box with uart(4) is missing data, not the Windows machine, right? Do you know if you get the first 30 bytes or the last 30 bytes or some mix? -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-current@FreeBSD.ORG Mon Dec 8 19:27:06 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 77C3F1065670 for ; Mon, 8 Dec 2008 19:27:06 +0000 (UTC) (envelope-from bahamasfranks@gmail.com) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.28]) by mx1.freebsd.org (Postfix) with ESMTP id 234B28FC19 for ; Mon, 8 Dec 2008 19:27:05 +0000 (UTC) (envelope-from bahamasfranks@gmail.com) Received: by yx-out-2324.google.com with SMTP id 8so515493yxb.13 for ; Mon, 08 Dec 2008 11:27:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=lbAXnpgzz3U6JyjiZFmpm+jMcyyhZ6xjF6iu4B9I3JU=; b=wFCw6lhINyvoZO75mLNlpwwoVZu1gVfZCx6FjB3Ol6VtGMCc7ENpatn/z7WY98c+0X m8zCTeVhBouRQFh4qr7ruRgP5sjRdygH8zd5Oo2nooAqOdo0SH/r5ZLY0YLlGpQGjGAv 6Rf0oCyfoP0a+MHEEdflsguPfv48WOr//P3F4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=s7A5ogV3Iy8YqYq+QLAy+YkeFZKIXr9JrtxsuBwpid+pnPtfXp//+H3OvIIsEbNj58 DywKd3xVZ6ISnAjFlbTiQM6avypwSqLJhzNUVBWQBrWLZpkKrUGhYfMo5MK/d9Z+XtOW K8zaUuLqgEdY4sYCliRfQ7/8wkuaodgvG/O0k= Received: by 10.101.1.16 with SMTP id d16mr1676437ani.66.1228764425240; Mon, 08 Dec 2008 11:27:05 -0800 (PST) Received: by 10.100.209.20 with HTTP; Mon, 8 Dec 2008 11:27:05 -0800 (PST) Message-ID: <539c60b90812081127s4ffb509fnea9d44d4298da666@mail.gmail.com> Date: Mon, 8 Dec 2008 12:27:05 -0700 From: "Steve Franks" To: pyunyh@gmail.com In-Reply-To: <20081206023016.GF22093@cdnetworks.co.kr> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <490F47BE.9080205@janh.de> <20081104015235.GC98154@cdnetworks.co.kr> <4910C055.8000505@janh.de> <20081105013558.GA99795@cdnetworks.co.kr> <20081203090658.GJ9639@cdnetworks.co.kr> <37502393@bb.ipt.ru> <20081206023016.GF22093@cdnetworks.co.kr> X-Mailman-Approved-At: Mon, 08 Dec 2008 19:37:12 +0000 Cc: current-list freebsd Subject: Re: Call for testers: Atheros AR8121(L1E)/AR8113/AR8114(L2E) ethernet X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Dec 2008 19:27:06 -0000 Hi, Test: seems my L1E is not appearing. pcib1: irq 16 at device 28.0 on pci0 pci1: on pcib1 pcib2: irq 17 at device 28.1 on pci0 pci2: on pcib2 pci2: at device 0.0 (no driver attached) [steve@dynstant ~]$ sudo kldload if_ale kldload: can't load if_ale: File exists [steve@dynstant ~]$ uname -a FreeBSD dynstant 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #0: Fri Dec 5 13:41:49 MST 2008 root@dynstant:/usr/obj/usr/src/sys/TILDE i386 I'm happy to poke around things if anyone can give me some guidance about what to test... Device is L1E embedded on the PCI-e bus on my motherboard....I suspect that is the problem. Thanks, Steve On Fri, Dec 5, 2008 at 7:30 PM, Pyun YongHyeon wrote: > On Fri, Dec 05, 2008 at 06:00:06PM +0300, Boris Samorodov wrote: > > Pyun YongHyeon writes: > > > On Wed, Nov 05, 2008 at 10:35:58AM +0900, To Jan Henrik Sylvester wrote: > > > > On Tue, Nov 04, 2008 at 10:36:21PM +0100, Jan Henrik Sylvester wrote: > > > > > Pyun YongHyeon wrote: > > > > > >On Mon, Nov 03, 2008 at 07:49:34PM +0100, Jan Henrik Sylvester wrote: > > > > > > > >Pyun YongHyeon writes: > > > > > > > >> http://people.freebsd.org/~yongari/ale/if_ale.c > > > > > > > > > > > > > > I got an Eee PC 1000H, too, with 7.1-BETA2 and just used scp to copy > > > > > > > with 11.5MB/s -- much better than wlan for big files. Great! > > > > > > > > > > > > > > > > > > >Thanks for testing! > > > > > > > > > > I was happy too early. Now I keep getting these: > > > > > ale0: DMA read error! -- resetting > > > > > ale0: could not disable Tx/Rx MAC(0x00000008)! > > > > > > FYI: Fix committed to HEAD(r185577). > > > > Works fine for me at EEEPC-1000. Good rate (~10MB/s), no interface > > UP/DOWN, no messages. Big thank you! > > > > No problem. Thanks for testing! > > -- > Regards, > Pyun YongHyeon > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Mon Dec 8 19:51:19 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 13E35106567F for ; Mon, 8 Dec 2008 19:51:19 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.237]) by mx1.freebsd.org (Postfix) with ESMTP id D69B78FC1F for ; Mon, 8 Dec 2008 19:51:18 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so1309767rvf.43 for ; Mon, 08 Dec 2008 11:51:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=fJey9i+oyKLpQ2YCy37bnSOhkDYgZUmgnSp4sNNP9xc=; b=CuFgwE4qVrQQkVTpB6UQyCey5fbfMRcU2DnJAnU+t8HDTWeS4zC9sKizyYs5BOC199 g1Nn1uDBBqe8b+0+plbUgHuFOWReC69ks/OaNeGsdfPyo2n9U9ZqT3Fm/6QQp22XCjbg pgphR5OJTQC5s6THXF5mv62LTutXmNpKp1dV4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=PNgim8KDIMVuhB6n0/gvxtaXePDmhEm1uPWX33ZuzrA0+rV9eVYzhBVyspU4sZ2xoz +cA1dGGOlZ3XR7jWEj0oqPkelnVw9UkALSE6ZGBjT3mzZN9b3UZ9N8D+eKmDF9dPx61h HM4vg0x69NOSUcgZ170EkYdbBd1hQ5i6aPvOk= Received: by 10.141.86.4 with SMTP id o4mr1808570rvl.172.1228765877718; Mon, 08 Dec 2008 11:51:17 -0800 (PST) Received: by 10.141.142.3 with HTTP; Mon, 8 Dec 2008 11:51:17 -0800 (PST) Message-ID: <3c1674c90812081151x9aef0eek256c69df3929f8ae@mail.gmail.com> Date: Mon, 8 Dec 2008 11:51:17 -0800 From: "Kip Macy" Sender: mat.macy@gmail.com To: "Paul B. Mahol" In-Reply-To: <3c1674c90812080730k7f5cc57cqcd41c574cc46ae3d@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <3a142e750812080658r645dc1c4sdd612585fe9ad7d6@mail.gmail.com> <3c1674c90812080730k7f5cc57cqcd41c574cc46ae3d@mail.gmail.com> X-Google-Sender-Auth: b4b3802f144afa79 Cc: "current@freebsd.org" Subject: Re: panic: _rw_wlock_hard: recursing but non-recursive rw radix node head X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Dec 2008 19:51:19 -0000 Please try the following patch: http://www.fsmware.com/freebsd/rnh_lock_recursion.diff Thanks, Kip On Mon, Dec 8, 2008 at 7:30 AM, Kip Macy wrote: > Will post a fix this afternoon. > > Thanks, > Kip > > On Mon, Dec 8, 2008 at 6:58 AM, Paul B. Mahol wrote: >> I got panic, after pressing shutdown button: >> >> FreeBSD dhcppc1 8.0-CURRENT FreeBSD 8.0-CURRENT #3: Mon Dec 8 12:39:23 CET 2008 >> root@dhcppc1:/usr/obj/usr/src/sys/KERNEL i386 >> >> db:1:lockinfo> show locks >> db:1:locks> show alllocks >> Process 994 (wpa_supplicant) thread 0xc4756900 (100112) >> db:1:alllocks> show lockedvnods >> Locked vnodes >> db:0:kdb.enter.panic> show pcpu >> cpuid = 0 >> curthread = 0xc4756900: pid 994 "wpa_supplicant" >> curpcb = 0xe6518d90 >> fpcurthread = none >> idlethread = 0xc3d0ab40: pid 10 "idle: cpu0" >> APIC ID = 0 >> currentldt = 0x50 >> spin locks held: >> db:0:kdb.enter.panic> bt >> Tracing pid 994 tid 100112 td 0xc4756900 >> kdb_enter(c06181da,c06181da,c0617bc2,e6518868,0,...) at kdb_enter+0x3a >> panic(c0617bc2,c0603f55,c061e0eb,c0627193,3a9,...) at panic+0x136 >> _rw_wlock_hard(c3e53280,c4756900,c0627193,3a9,0,...) at _rw_wlock_hard+0x66 >> _rw_wlock(c3e53280,c0627193,3a9,c061da2b,3,...) at _rw_wlock+0xae >> rtrequest1_fib(2,e6518920,0,0,0,...) at rtrequest1_fib+0x92 >> rtrequest_fib(2,c59b2500,0,0,20405,...) at rtrequest_fib+0x5e >> rt_fixdelete(c59c10f0,c4124e10,22,c4124e10,c4124e74,...) at rt_fixdelete+0x51 >> rn_walktree_from(c3e53200,e6518a54,c47e8370,c054fa60,c4124e10,...) at >> rn_walktree_from+0xd6 >> rtrequest1_fib(2,e6518a20,e6518a50,0,c4744a00,...) at rtrequest1_fib+0x1ad >> rtinit(c4744a00,2,0,c4744a00,c06586c0,...) at rtinit+0x2d4 >> in_ifscrub(c3e6ec00,c4744a00,c06586c0,c06582fc,e6518b38,...) at in_ifscrub+0xed >> rip_ctlinput(0,c4744ab4,0,c4744a00,c3e6ec00,...) at rip_ctlinput+0x49 >> pfctlinput(0,c4744ab4,80206910,8842,e6518bb0,...) at pfctlinput+0x3b >> if_down(c3e6ec00,18f,c07ece44,63a,c3e6ec00,...) at if_down+0x36 >> ifhwioctl(c4756900,c07bfdc8,c47569a4,c07bfdc8,c064ded0,...) at ifhwioctl+0x2f9 >> ifioctl(c412e7a8,80206910,c477f440,c4756900,80206910,...) at ifioctl+0x301 >> soo_ioctl(c4016d20,80206910,c477f440,c4111d00,c4756900,...) at soo_ioctl+0x397 >> kern_ioctl(c4756900,3,80206910,c477f440,c477f440,...) at kern_ioctl+0x1dd >> ioctl(c4756900,e6518cf8,c,c063bd0b,c0646070,...) at ioctl+0x12f >> syscall(e6518d38) at syscall+0x283 >> Xint0x80_syscall() at Xint0x80_syscall+0x20 >> --- syscall (54, FreeBSD ELF32, ioctl), eip = 0x28370063, esp = >> 0xbfbfe77c, ebp = 0xbfbfe7e8 --- >> >> >> >> >> <118>Stopping moused. >> <118>Stopping powerd. >> <118>Stopping devd. >> <118>Writing entropy file: >> <118>. >> <118>. >> <118>Dec 8 15:08:04 syslogd: exiting on signal 15 >> panic: _rw_wlock_hard: recursing but non-recursive rw radix node head >> @ /usr/src/sys/net/route.c:937 >> >> cpuid = 0 >> KDB: enter: panic >> exclusive sleep mutex rtentry (rtentry) r = 0 (0xc4124e74) locked @ >> /usr/src/sys/net/route.c:1019 >> exclusive rw radix node head (radix node head) r = 0 (0xc3e53280) >> locked @ /usr/src/sys/net/route.c:937 >> exclusive sleep mutex rtentry (rtentry) r = 0 (0xc4124e74) locked @ >> /usr/src/sys/net/route.c:1019 >> exclusive rw radix node head (radix node head) r = 0 (0xc3e53280) >> locked @ /usr/src/sys/net/route.c:937 >> >> >> -- >> Paul >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" >> > > > > -- > If we desire respect for the law, we must first make the law respectable. > - Louis D. Brandeis > -- If we desire respect for the law, we must first make the law respectable. - Louis D. Brandeis From owner-freebsd-current@FreeBSD.ORG Mon Dec 8 19:54:03 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B02581065670 for ; Mon, 8 Dec 2008 19:54:03 +0000 (UTC) (envelope-from gavin.atkinson@ury.york.ac.uk) Received: from mail-gw2.york.ac.uk (mail-gw2.york.ac.uk [144.32.128.247]) by mx1.freebsd.org (Postfix) with ESMTP id 432DD8FC19 for ; Mon, 8 Dec 2008 19:54:02 +0000 (UTC) (envelope-from gavin.atkinson@ury.york.ac.uk) Received: from mail-gw6.york.ac.uk (mail-gw6.york.ac.uk [144.32.129.26]) by mail-gw2.york.ac.uk (8.13.6/8.13.6) with ESMTP id mB8Jrve5021622; Mon, 8 Dec 2008 19:53:57 GMT Received: from buffy-128.york.ac.uk ([144.32.128.160] helo=buffy.york.ac.uk) by mail-gw6.york.ac.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1L9mB3-0001lZ-Po; Mon, 08 Dec 2008 19:53:57 +0000 Received: from buffy.york.ac.uk (localhost [127.0.0.1]) by buffy.york.ac.uk (8.14.2/8.14.2) with ESMTP id mB8Jrvjw029321; Mon, 8 Dec 2008 19:53:57 GMT (envelope-from gavin.atkinson@ury.york.ac.uk) Received: (from ga9@localhost) by buffy.york.ac.uk (8.14.2/8.14.2/Submit) id mB8JrvNH029320; Mon, 8 Dec 2008 19:53:57 GMT (envelope-from gavin.atkinson@ury.york.ac.uk) X-Authentication-Warning: buffy.york.ac.uk: ga9 set sender to gavin.atkinson@ury.york.ac.uk using -f From: Gavin Atkinson To: Steve Franks In-Reply-To: <539c60b90812081127s4ffb509fnea9d44d4298da666@mail.gmail.com> References: <490F47BE.9080205@janh.de> <20081104015235.GC98154@cdnetworks.co.kr> <4910C055.8000505@janh.de> <20081105013558.GA99795@cdnetworks.co.kr> <20081203090658.GJ9639@cdnetworks.co.kr> <37502393@bb.ipt.ru> <20081206023016.GF22093@cdnetworks.co.kr> <539c60b90812081127s4ffb509fnea9d44d4298da666@mail.gmail.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Mon, 08 Dec 2008 19:53:57 +0000 Message-Id: <1228766037.27498.6.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.atkinson@ury.york.ac.uk Cc: pyunyh@gmail.com, current-list freebsd Subject: Re: Call for testers: Atheros AR8121(L1E)/AR8113/AR8114(L2E) ethernet X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Dec 2008 19:54:03 -0000 On Mon, 2008-12-08 at 12:27 -0700, Steve Franks wrote: > Hi, > > Test: seems my L1E is not appearing. > > > pcib1: irq 16 at device 28.0 on pci0 > pci1: on pcib1 > pcib2: irq 17 at device 28.1 on pci0 > pci2: on pcib2 > pci2: at device 0.0 (no driver attached) > > [steve@dynstant ~]$ sudo kldload if_ale > kldload: can't load if_ale: File exists > > [steve@dynstant ~]$ uname -a > FreeBSD dynstant 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #0: Fri Dec 5 > 13:41:49 MST 2008 root@dynstant:/usr/obj/usr/src/sys/TILDE i386 > > I'm happy to poke around things if anyone can give me some guidance > about what to test... > > Device is L1E embedded on the PCI-e bus on my motherboard....I suspect > that is the problem. Firstly: The output of "pciconf -lcv" relating to the device in question would be essential. Gavin From owner-freebsd-current@FreeBSD.ORG Mon Dec 8 20:49:20 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B10F81065672 for ; Mon, 8 Dec 2008 20:49:20 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 76E078FC12 for ; Mon, 8 Dec 2008 20:49:20 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by smarthost1.sentex.ca (8.14.3/8.14.3) with ESMTP id mB8KnIlL097203; Mon, 8 Dec 2008 15:49:18 -0500 (EST) (envelope-from mike@sentex.net) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.13.8/8.13.3) with ESMTP id mB8KnHSN042710 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Dec 2008 15:49:17 -0500 (EST) (envelope-from mike@sentex.net) Message-Id: <200812082049.mB8KnHSN042710@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 08 Dec 2008 15:49:15 -0500 To: Marcel Moolenaar From: Mike Tancsa In-Reply-To: References: <200812081621.mB8GLMxB041498@lava.sentex.ca> <200812081906.mB8J6oha042222@lava.sentex.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: freebsd-current@freebsd.org Subject: Re: uart vs sio differences ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Dec 2008 20:49:20 -0000 At 02:18 PM 12/8/2008, Marcel Moolenaar wrote: >I see, so the FreeBSD box with uart(4) is missing data, >not the Windows machine, right? Hi, Correct. The FreeBSD box never gets the full data, nor do we see it on the "protocol analyzer". Our analyzer is just a special serial cable that copies the data from both sides to the monitor program (a dos app) on another machine. >Do you know if you get the first 30 bytes or the last 30 >bytes or some mix? Just checked, and we get the first 31 bytes each time. Is it possible the larger fifo buffer of the 16950 is holding onto the data too long ? The sio sees it as a plain old 16550, but the uart driver sees it as the 16950 that it is. ---Mike From owner-freebsd-current@FreeBSD.ORG Mon Dec 8 21:02:06 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 027901065670 for ; Mon, 8 Dec 2008 21:02:06 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.29]) by mx1.freebsd.org (Postfix) with ESMTP id 8F95D8FC0C for ; Mon, 8 Dec 2008 21:02:05 +0000 (UTC) (envelope-from onemda@gmail.com) Received: by yx-out-2324.google.com with SMTP id 8so539126yxb.13 for ; Mon, 08 Dec 2008 13:02:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=aPG1M1wxWWzoaVnOWzj4kc2t2Ed+qxK1qZsFt3hvHuQ=; b=CZQ32jZLv+1M/PPorxF43bsarkYaPz6tKTtWcuzMvhuCk/PCss1vuCtK5XFcMMaMLs EHWKZtBqBTb89X1y/6c/NuF/YriQb9548iVxDjZBylPE5ZEi7GtVQzuGNv2bp3xrCn/b SubuxsfMSGE6gJxB9VhlTy5JYuLuw9WR/Lb7o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=fN6Twmr6lg1v3GsEKV9JgxgPpwAGL6ZjEy3rbClASjYMn3ZaZtieldZvTpvX4yRW+i R9VqIcvMWRJf1w8sf5Ugfg1XNemeZLLkemwe4IqKR+eoFlWuLrLQhuoMzrjjZjXmCGMf KW9pvpyZCef92W3MQ+HG7f56c8/Jw414G1QOE= Received: by 10.231.14.72 with SMTP id f8mr29744iba.34.1228770123627; Mon, 08 Dec 2008 13:02:03 -0800 (PST) Received: by 10.231.17.68 with HTTP; Mon, 8 Dec 2008 13:02:03 -0800 (PST) Message-ID: <3a142e750812081302x2fd8bfcbqa61ea663f6786751@mail.gmail.com> Date: Mon, 8 Dec 2008 22:02:03 +0100 From: "Paul B. Mahol" To: "Kip Macy" In-Reply-To: <3c1674c90812081151x9aef0eek256c69df3929f8ae@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <3a142e750812080658r645dc1c4sdd612585fe9ad7d6@mail.gmail.com> <3c1674c90812080730k7f5cc57cqcd41c574cc46ae3d@mail.gmail.com> <3c1674c90812081151x9aef0eek256c69df3929f8ae@mail.gmail.com> Cc: "current@freebsd.org" Subject: Re: panic: _rw_wlock_hard: recursing but non-recursive rw radix node head X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Dec 2008 21:02:06 -0000 On 12/8/08, Kip Macy wrote: > Please try the following patch: > > http://www.fsmware.com/freebsd/rnh_lock_recursion.diff > > Thanks, > Kip Fixed. Thanks. -- Paul From owner-freebsd-current@FreeBSD.ORG Mon Dec 8 21:02:20 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8ECDB1065704 for ; Mon, 8 Dec 2008 21:02:20 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout016.mac.com (asmtpout016.mac.com [17.148.16.91]) by mx1.freebsd.org (Postfix) with ESMTP id 792128FC1E for ; Mon, 8 Dec 2008 21:02:20 +0000 (UTC) (envelope-from xcllnt@mac.com) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Received: from lynx.jnpr.net (natint3.juniper.net [66.129.224.36]) by asmtp016.mac.com (Sun Java(tm) System Messaging Server 6.3-7.03 (built Aug 7 2008; 32bit)) with ESMTPSA id <0KBK00L40T3VEF20@asmtp016.mac.com> for freebsd-current@freebsd.org; Mon, 08 Dec 2008 13:02:20 -0800 (PST) Message-id: <84A7F176-5A74-48AC-859A-C0D4C7CBCB48@mac.com> From: Marcel Moolenaar To: Mike Tancsa In-reply-to: <200812082049.mB8KnHSN042710@lava.sentex.ca> Date: Mon, 08 Dec 2008 13:02:18 -0800 References: <200812081621.mB8GLMxB041498@lava.sentex.ca> <200812081906.mB8J6oha042222@lava.sentex.ca> <200812082049.mB8KnHSN042710@lava.sentex.ca> X-Mailer: Apple Mail (2.929.2) Cc: freebsd-current@freebsd.org Subject: Re: uart vs sio differences ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Dec 2008 21:02:20 -0000 On Dec 8, 2008, at 12:49 PM, Mike Tancsa wrote: > At 02:18 PM 12/8/2008, Marcel Moolenaar wrote: > >> I see, so the FreeBSD box with uart(4) is missing data, >> not the Windows machine, right? > > Hi, > Correct. The FreeBSD box never gets the full data, nor do we > see it on the "protocol analyzer". Our analyzer is just a special > serial cable that copies the data from both sides to the monitor > program (a dos app) on another machine. Interesting. If it never shows up on the analyzer, then doesn't that indicate that it was never sent? Put differently: doesn't that indicate that the transmitter stops sending, and not that the receiver stops receiving? >> Do you know if you get the first 30 bytes or the last 30 >> bytes or some mix? > > > Just checked, and we get the first 31 bytes each time. Ok. Could you check if any of RTS/CTS, DTR/DSR or DCD toggles after about 30 characters? If the analyzer also just gets the 30 characters, then maybe the receiver signaled the transmitter to stop (think of the 16950 as having HW flow-control enabled and doing it on its own, without knowledge of the kernel). > Is it possible the larger fifo buffer of the 16950 is holding onto > the data too long ? The sio sees it as a plain old 16550, but the > uart driver sees it as the 16950 that it is. The 16950 has a 128-byte FIFO, so even if it holds on to data too long, I would expect to receive at least 128 bytes of data... -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-current@FreeBSD.ORG Mon Dec 8 21:23:18 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5A0EC106564A for ; Mon, 8 Dec 2008 21:23:18 +0000 (UTC) (envelope-from josh.carroll@gmail.com) Received: from mail-gx0-f19.google.com (mail-gx0-f19.google.com [209.85.217.19]) by mx1.freebsd.org (Postfix) with ESMTP id BF22A8FC17 for ; Mon, 8 Dec 2008 21:23:17 +0000 (UTC) (envelope-from josh.carroll@gmail.com) Received: by gxk12 with SMTP id 12so1251935gxk.19 for ; Mon, 08 Dec 2008 13:23:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:reply-to :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=Vbu1/KHOq6uRD5hI/ju60sO+v9F6guulfZL6nu/yzcY=; b=JvEmszcyeKHerS1xLsaFEiTCy2DOitMOEhPXjM8avxOioP5uDj/nDAHWzg9StSHU96 t2w5+nUR1vDkqD1u4yOiGjPiDzdk42zZnXULUTBe86M0paAadKPJm3GJkRK3MUCurleS QNN4K9GlM0/kkeD8Y0vtL3J/TaliEtXA/c84U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:reply-to:to:subject:cc:in-reply-to :mime-version:content-type:content-transfer-encoding :content-disposition:references; b=A/Ws4jD8eHRYaJ/drNTZ/rOPVUkCXu+23nDCRkgqD+feZnaDeiGoM8IzTKN8BhZumT s/kF+0WLjUW4W5jy4EIY9A8NjuuFVWrVEqxGNJurZIyRWLckYYKJp2kdTlIuSgCfaT8/ RJl4AKmCxaw1ppRfwkmAaQnR8qPKoYiJUZnjA= Received: by 10.151.15.9 with SMTP id s9mr8636648ybi.70.1228769563548; Mon, 08 Dec 2008 12:52:43 -0800 (PST) Received: by 10.150.123.1 with HTTP; Mon, 8 Dec 2008 12:52:43 -0800 (PST) Message-ID: <8cb6106e0812081252j2b0c8e78g4dcecf8d3770c269@mail.gmail.com> Date: Mon, 8 Dec 2008 15:52:43 -0500 From: "Josh Carroll" To: "Steve Franks" In-Reply-To: <539c60b90812081127s4ffb509fnea9d44d4298da666@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <490F47BE.9080205@janh.de> <20081104015235.GC98154@cdnetworks.co.kr> <4910C055.8000505@janh.de> <20081105013558.GA99795@cdnetworks.co.kr> <20081203090658.GJ9639@cdnetworks.co.kr> <37502393@bb.ipt.ru> <20081206023016.GF22093@cdnetworks.co.kr> <539c60b90812081127s4ffb509fnea9d44d4298da666@mail.gmail.com> Cc: pyunyh@gmail.com, current-list freebsd Subject: Re: Call for testers: Atheros AR8121(L1E)/AR8113/AR8114(L2E) ethernet X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: josh.carroll@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Dec 2008 21:23:18 -0000 > Device is L1E embedded on the PCI-e bus on my motherboard....I suspect > that is the problem. > > Thanks, > Steve Which motherboard? I have an Asus P5Q Pro, and it's being recognized properly on RELENG_7_1: % grep ale /var/run/dmesg.boot ale0: port 0xdc00-0xdc7f mem 0xfeac0000-0xfeafffff irq 17 at device 0.0 on pci2 ale0: 960 Tx FIFO, 1024 Rx FIFO ale0: Using 1 MSI messages. ale0: 4GB boundary crossed, switching to 32bit DMA addressing mode. miibus0: on ale0 ale0: Ethernet address: 00:23:54:31:7f:5b ale0: [FILTER] relevant pciconf -lv output: ale0@pci0:2:0:0: class=0x020000 card=0x82261043 chip=0x10261969 rev=0xb0 hdr=0x00 vendor = 'Attansic (Now owned by Atheros)' class = network subclass = ethernet iperf (ale0 as -s): [ 3] 0.0-10.0 sec 1.10 GBytes 941 Mbits/sec iperf (ale0 as -c): [ 3] 0.0-10.0 sec 1.08 GBytes 931 Mbits/sec So all seems well here. Josh From owner-freebsd-current@FreeBSD.ORG Mon Dec 8 21:50:23 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 996371065670 for ; Mon, 8 Dec 2008 21:50:23 +0000 (UTC) (envelope-from nealhogan@gmail.com) Received: from mail-gx0-f19.google.com (mail-gx0-f19.google.com [209.85.217.19]) by mx1.freebsd.org (Postfix) with ESMTP id 1202D8FC18 for ; Mon, 8 Dec 2008 21:50:22 +0000 (UTC) (envelope-from nealhogan@gmail.com) Received: by gxk12 with SMTP id 12so1267223gxk.19 for ; Mon, 08 Dec 2008 13:50:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:mime-version:content-type; bh=QkIShv0qE5joFrGudT2kNjxJGDDU4qpP3jfIEGcN5Cc=; b=H6j+CqiPboEl22HqECCGacs/SzDS8W3a6yAHg8swXiODkUu1JulwaAqo8es0qWuSaH qHc/KgfBBQCJeEUV+nluPQ9ELPAoTRXpQxZe5LyCoXwsniWGgxFX6H5Immq1uVl9vRI7 juDlSDptm1/EvAbnMuaKtNMVSo0V631m7L0IM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=MmXFocXOhg1eqo7CDbNsCYnbfn5At3PakjZyBd8ds6A7MuPMJiv/a4BIfpw5B9JiWH 5RXuQpPPDzgTqtvP/tHwnvrrAlFjxPa0p2o+6zPNZ2fSXlNdS8flIB2jumXsUDcX7eZ9 j84RJvKF+Gk2PmPBmtiYzcjon/JxSMFtTUXus= Received: by 10.150.186.21 with SMTP id j21mr1345872ybf.168.1228771686445; Mon, 08 Dec 2008 13:28:06 -0800 (PST) Received: by 10.151.148.5 with HTTP; Mon, 8 Dec 2008 13:28:06 -0800 (PST) Message-ID: Date: Mon, 8 Dec 2008 15:28:06 -0600 From: "Neal Hogan" To: freebsd-acpi@freebsd.org, freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: boot hang with 7.1BETA2 (12/08) an no wifi X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Dec 2008 21:50:23 -0000 Hi, I'm new to fBSD and recently installed 7.0 on my HP pavillion ze4400 (multiboot w/ XP). It appeared to work fine. I had it on there for several weeks and was just snooping around. Well, I attempted to upgrade to 7.1 prerelease. I used *freebsd-update upgrade -r 7.1-BETA2* and it seemed to work. However, when I reboot the system is hung after the the following line: pci1: on pcib1. I reboot with ACPI disabled and it boot fine. Below is my dmesg. Also, my wifi card doesn't work and I don't see it in the dmesg. The same was true of 7.0. This computer is older than my interest in *BSD. So, I don't know what card it has. Note that it works under XP. Thanks. Copyright (c) 1992-2008 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.1-PRERELEASE-p1 #0: Mon Nov 24 11:49:24 UTC 2008 root@i386-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: mobile AMD Athlon(tm) XP2400+ (1788.94-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x6a0 Stepping = 0 Features=0x383f9ff AMD Features=0xc0480800 real memory = 468647936 (446 MB) avail memory = 444547072 (423 MB) kbd1 at kbdmux0 ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) pcib0: pcibus 0 on motherboard pir0: on motherboard $PIR: Using invalid BIOS IRQ 5 from 0.10.INTA for link 0x6 pci0: on pcib0 agp0: on hostb0 pcib1: at device 1.0 on pci0 pci1: on pcib1 vgapci0: port 0x9000-0x90ff mem 0xe0000000-0xefffffff,0xd0100000-0xd010ffff irq 10 at device 5.0 on pci1 ohci0: mem 0xd0006000-0xd0006fff irq 9 at device 2.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: 4 ports with 4 removable, self powered pcm0: port 0x8400-0x84ff mem 0xd0007000-0xd0007fff irq 5 at device 6.0 on pci0 pcm0: pcm0: [GIANT-LOCKED] pcm0: [ITHREAD] isab0: at device 7.0 on pci0 isa0: on isab0 pci0: at device 8.0 (no driver attached) pci0: at device 9.0 (no driver attached) cbb0: mem 0x80000000-0x80000fff irq 5 at device 10.0 on pci0 cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 cbb0: [ITHREAD] fwohci0: mem 0xd0009000-0xd00097ff,0xd0000000-0xd0003fff irq 10 at device 12.0 on pci0 fwohci0: [FILTER] fwohci0: OHCI version 1.10 (ROM=1) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 00:0d:9d:71:9e:43:0c:6a fwohci0: Phy 1394a available S400, 1 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 fwe0: on firewire0 if_fwe0: Fake Ethernet address: 02:0d:9d:43:0c:6a fwe0: Ethernet address: 02:0d:9d:43:0c:6a fwip0: on firewire0 fwip0: Firewire address: 00:0d:9d:71:9e:43:0c:6a @ 0xfffe00000000, S400, maxrec 2048 sbp0: on firewire0 dcons_crom0: on firewire0 dcons_crom0: bus_addr 0x12c0000 fwohci0: Initiate bus reset fwohci0: BUS reset fwohci0: node_id=0xc000ffc0, gen=1, CYCLEMASTER mode atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x8080-0x808f at device 16.0 on pci0 atapci0: using PIO transfers above 137GB as workaround for 48bit DMA access bug, expect reduced performance ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] pci0: at device 17.0 (no driver attached) sis0: port 0x8c00-0x8cff mem 0xd000a000-0xd000afff irq 11 at device 18.0 on pci0 sis0: Silicon Revision: DP83816A miibus0: on sis0 nsphyter0: PHY 0 on miibus0 nsphyter0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto sis0: Ethernet address: 00:0d:9d:43:2b:a7 sis0: [ITHREAD] cpu0 on motherboard powernow0: on cpu0 pmtimer0 on isa0 orm0: at iomem 0xc0000-0xcefff,0xcf000-0xcf7ff,0xdb000-0xdbfff,0xdc000-0xdffff pnpid ORM0000 on isa0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model IntelliMouse, device ID 3 fdc0: at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fdc0: [FILTER] ppc0: at port 0x378-0x37f irq 7 on isa0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/16 bytes threshold ppbus0: on ppc0 ppbus0: [ITHREAD] plip0: on ppbus0 plip0: WARNING: using obsoleted IFF_NEEDSGIANT flag lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 ppc0: [GIANT-LOCKED] ppc0: [ITHREAD] sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio0: [FILTER] sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 unknown: can't assign resources (memory) unknown: can't assign resources (memory) unknown: can't assign resources (port) unknown: can't assign resources (memory) unknown: can't assign resources (memory) unknown: can't assign resources (port) unknown: can't assign resources (irq) unknown: can't assign resources (port) unknown: can't assign resources (port) ums0: on uhub0 ums0: 16 buttons and Z dir. umass0: on uhub0 Timecounter "TSC" frequency 1788940177 Hz quality 800 Timecounters tick every 1.000 msec firewire0: 1 nodes, maxhop <= 0, cable IRM = 0 (me) firewire0: bus manager 0 (me) ad0: 95396MB at ata0-master UDMA100 acd0: CDRW at ata1-master UDMA33 da0 at umass-sim0 bus 0 target 0 lun 0 da0: Removable Direct Access SCSI-0 device da0: 1.000MB/s transfers da0: 246MB (503808 512 byte sectors: 64H 32S/T 246C) Trying to mount root from ufs:/dev/ad0s2a WARNING: / was not properly dismounted WARNING: /usr was not properly dismounted /usr: mount pending error: blocks 56 files 2 WARNING: /var was not properly dismounted -- www.nealhogan.net From owner-freebsd-current@FreeBSD.ORG Mon Dec 8 22:39:30 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 52DA5106564A for ; Mon, 8 Dec 2008 22:39:30 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id F3A3A8FC1A for ; Mon, 8 Dec 2008 22:39:29 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by smarthost1.sentex.ca (8.14.3/8.14.3) with ESMTP id mB8MdRkF030630; Mon, 8 Dec 2008 17:39:28 -0500 (EST) (envelope-from mike@sentex.net) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.13.8/8.13.3) with ESMTP id mB8MdRhb043206 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Dec 2008 17:39:27 -0500 (EST) (envelope-from mike@sentex.net) Message-Id: <200812082239.mB8MdRhb043206@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 08 Dec 2008 17:39:25 -0500 To: Marcel Moolenaar From: Mike Tancsa In-Reply-To: <84A7F176-5A74-48AC-859A-C0D4C7CBCB48@mac.com> References: <200812081621.mB8GLMxB041498@lava.sentex.ca> <200812081906.mB8J6oha042222@lava.sentex.ca> <200812082049.mB8KnHSN042710@lava.sentex.ca> <84A7F176-5A74-48AC-859A-C0D4C7CBCB48@mac.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: freebsd-current@freebsd.org Subject: Re: uart vs sio differences ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Dec 2008 22:39:30 -0000 At 04:02 PM 12/8/2008, Marcel Moolenaar wrote: >On Dec 8, 2008, at 12:49 PM, Mike Tancsa wrote: > >>At 02:18 PM 12/8/2008, Marcel Moolenaar wrote: >> >>>I see, so the FreeBSD box with uart(4) is missing data, >>>not the Windows machine, right? >> >>Hi, >> Correct. The FreeBSD box never gets the full data, nor do we >>see it on the "protocol analyzer". Our analyzer is just a special >>serial cable that copies the data from both sides to the monitor >>program (a dos app) on another machine. > >Interesting. If it never shows up on the analyzer, then >doesn't that indicate that it was never sent? >Put differently: doesn't that indicate that the transmitter >stops sending, and not that the receiver stops receiving? What it appears to be is that as long as data is coming in, even at 1200bps, the ioctl FIONREAD returns zero and an actual read does not return any data until there is either a pause in the data coming in or possibly when we do a xmit/write at which point the accumulated data is available for us to read. We dont know if this is due to the hardware fifo or something in the driver itself. >>>Do you know if you get the first 30 bytes or the last 30 >>>bytes or some mix? >> >> >>Just checked, and we get the first 31 bytes each time. > >Ok. > >Could you check if any of RTS/CTS, DTR/DSR or DCD toggles >after about 30 characters? I am not sure if the DOS software we use reliably sees that. We have a fancier windows app that might be more accurate. ---Mike >If the analyzer also just gets the 30 characters, then maybe >the receiver signaled the transmitter to stop (think of the >16950 as having HW flow-control enabled and doing it on its >own, without knowledge of the kernel). > >> Is it possible the larger fifo buffer of the 16950 is holding onto >>the data too long ? The sio sees it as a plain old 16550, but the >>uart driver sees it as the 16950 that it is. > >The 16950 has a 128-byte FIFO, so even if it holds on to >data too long, I would expect to receive at least 128 >bytes of data... >-- >Marcel Moolenaar >xcllnt@mac.com > > From owner-freebsd-current@FreeBSD.ORG Mon Dec 8 22:47:43 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 84F751065672 for ; Mon, 8 Dec 2008 22:47:43 +0000 (UTC) (envelope-from nakaji@kankyo-u.ac.jp) Received: from www.heimat.gr.jp (unknown [IPv6:2001:3e0:a84::1]) by mx1.freebsd.org (Postfix) with ESMTP id 3C6B48FC08 for ; Mon, 8 Dec 2008 22:47:42 +0000 (UTC) (envelope-from nakaji@kankyo-u.ac.jp) X-Virus-Scanned: amavisd-new at heimat.gr.jp Received: from ra333.heimat.gr.jp.kankyo-u.ac.jp (ra333.heimat.gr.jp [IPv6:2001:3e0:a84:0:200:4cff:fe17:573c]) by www.heimat.gr.jp (8.14.3/8.14.3) with ESMTP id mB8MlZfZ097267; Tue, 9 Dec 2008 07:47:36 +0900 (JST) (envelope-from nakaji@kankyo-u.ac.jp) From: NAKAJI Hiroyuki To: freebsd-current@freebsd.org References: <87zljb8nw6.fsf@roddy.4407.kankyo-u.ac.jp> <3a142e750812050613w4e9155bat950f03716aa58beb@mail.gmail.com> <863ah2qivi.fsf@ra333.heimat.gr.jp> Date: Tue, 09 Dec 2008 07:47:35 +0900 In-Reply-To: <863ah2qivi.fsf@ra333.heimat.gr.jp> (NAKAJI Hiroyuki's message of "Sat, 06 Dec 2008 08:53:21 +0900") Message-ID: <86iqpu2sjc.fsf@ra333.heimat.gr.jp> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.60 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-5.0 required=13.0 tests=BAYES_00, CONTENT_TYPE_PRESENT, FAKEDWORD_ZERO, MIMEQENC, NO_RELAYS, QENCPTR1, QENCPTR2 autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on www.heimat.gr.jp Cc: Subject: Re: Fatal trap 12: page fault while in kernel mode X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Dec 2008 22:47:43 -0000 >>>>> In <863ah2qivi.fsf@ra333.heimat.gr.jp>=20 >>>>> NAKAJI Hiroyuki wrote: > So, what I have to do are three: > 1. Full upgrade to the latest kernel and userland (world) > 2. Observe whether a panic occurs, and > 3. When panic, save the crash dump and get full bt with kgdb > I hope it will not reach to the step three. Thanks. Unfortunately, I faced to "db> " on my serial console. db> bt Tracing pid 964 tid 100131 td 0xc49876c0 svc_run_internal(e6861d24,c0850793,c44f2780,e6861d38,1,...) at svc_run_inte= rnal+ 0x575 svc_thread_start(c44f2780,e6861d38,1,0,4836bd14,...) at svc_thread_start+0x= 10 fork_exit(c0a57fe0,c44f2780,e6861d38) at fork_exit+0x93 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip =3D 0xc, esp =3D 0x33, ebp =3D 0 --- db> call doadump Physical memory: 1010 MB Dumping 250 MB: 235 219 203 187 171 155 139 123 107 91 75 59 43 27 11 Dump complete =3D 0xf db> bt Tracing pid 964 tid 100131 td 0xc49876c0 svc_run_internal(e6861d24,c0850793,c44f2780,e6861d38,1,...) at svc_run_inte= rnal+ 0x575 svc_thread_start(c44f2780,e6861d38,1,0,4836bd14,...) at svc_thread_start+0x= 10 fork_exit(c0a57fe0,c44f2780,e6861d38) at fork_exit+0x93 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip =3D 0xc, esp =3D 0x33, ebp =3D 0 --- db> reset And then, I used kgdb. # kgdb /boot/kernel/kernel.symbols vmcore.9=20 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 condition= s. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd"... Unread portion of the kernel message buffer: Fatal trap 12: page fault while in kernel mode cpuid =3D 0; apic id =3D 00 fault virtual address =3D 0x0 fault code =3D supervisor read, page not present instruction pointer =3D 0x20:0xc0a57a75 stack pointer =3D 0x28:0xe6861c44 frame pointer =3D 0x28:0xe6861cec code segment =3D base 0x0, limit 0xfffff, type 0x1b =3D DPL 0, pres 1, def32 1, gran 1 processor eflags =3D interrupt enabled, resume, IOPL =3D 0 current process =3D 964 (nfsd: service) Physical memory: 1010 MB Dumping 250 MB: 235 219 203 187 171 155 139 123 107 91 75 59 43 27 11 Reading symbols from /boot/kernel/linprocfs.ko...Reading symbols from /boot= /kernel/linprocfs.ko.symbols...done. done. Loaded symbols for /boot/kernel/linprocfs.ko Reading symbols from /boot/kernel/linux.ko...Reading symbols from /boot/ker= nel/linux.ko.symbols...done. done. Loaded symbols for /boot/kernel/linux.ko Reading symbols from /boot/kernel/smbus.ko...Reading symbols from /boot/ker= nel/smbus.ko.symbols...done. done. Loaded symbols for /boot/kernel/smbus.ko Reading symbols from /boot/kernel/aio.ko...Reading symbols from /boot/kerne= l/aio.ko.symbols...done. done. Loaded symbols for /boot/kernel/aio.ko Reading symbols from /boot/kernel/mga.ko...Reading symbols from /boot/kerne= l/mga.ko.symbols...done. done. Loaded symbols for /boot/kernel/mga.ko Reading symbols from /boot/kernel/drm.ko...Reading symbols from /boot/kerne= l/drm.ko.symbols...done. done. Loaded symbols for /boot/kernel/drm.ko Reading symbols from /boot/kernel/atapicam.ko...Reading symbols from /boot/= kernel/atapicam.ko.symbols...done. done. Loaded symbols for /boot/kernel/atapicam.ko Reading symbols from /boot/kernel/nullfs.ko...Reading symbols from /boot/ke= rnel/nullfs.ko.symbols...done. done. Loaded symbols for /boot/kernel/nullfs.ko Reading symbols from /boot/kernel/logo_saver.ko...Reading symbols from /boo= t/kernel/logo_saver.ko.symbols...done. done. Loaded symbols for /boot/kernel/logo_saver.ko #0 doadump () at pcpu.h:246 246 pcpu.h: No such file or directory. in pcpu.h (kgdb) bt #0 doadump () at pcpu.h:246 #1 0xc04c2a69 in db_fncall (dummy1=3D-1059812576, dummy2=3D0, dummy3=3D-10= 67505768,=20 dummy4=3D0xe68619d8 "=EF=BF=BD:i=EF=BF=BD\2008'=EF=BF=BD") at /usr/src/= sys/ddb/db_command.c:548 #2 0xc04c2e61 in db_command (last_cmdp=3D0xc0d3e85c, cmd_table=3D0x0, dopa= ger=3D1) at /usr/src/sys/ddb/db_command.c:445 #3 0xc04c2fba in db_command_loop () at /usr/src/sys/ddb/db_command.c:498 #4 0xc04c4dfd in db_trap (type=3D12, code=3D0) at /usr/src/sys/ddb/db_main= .c:229 #5 0xc08a2456 in kdb_trap (type=3D12, code=3D0, tf=3D0xe6861c04) at /usr/src/sys/kern/subr_kdb.c:534 #6 0xc0b8059f in trap_fatal (frame=3D0xe6861c04, eva=3D0) at /usr/src/sys/i386/i386/trap.c:920 #7 0xc0b80860 in trap_pfault (frame=3D0xe6861c04, usermode=3D0, eva=3D0) at /usr/src/sys/i386/i386/trap.c:842 #8 0xc0b8126a in trap (frame=3D0xe6861c04) at /usr/src/sys/i386/i386/trap.= c:522 #9 0xc0b652cb in calltrap () at /usr/src/sys/i386/i386/exception.s:165 #10 0xc0a57a75 in svc_run_internal (pool=3D0xc44f2780, ismaster=3D0) at /usr/src/sys/rpc/svc.c:787 #11 0xc0a57ff0 in svc_thread_start (arg=3D0xc44f2780) at /usr/src/sys/rpc/svc.c:1188 #12 0xc0850793 in fork_exit (callout=3D0xc0a57fe0 ,=20 arg=3D0xc44f2780, frame=3D0xe6861d38) at /usr/src/sys/kern/kern_fork.c:= 821 #13 0xc0b65340 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:= 270 (kgdb)=20 In addition, # addr2line -e /boot/kernel/kernel.symbols 0xc0a57a75 /usr/src/sys/rpc/svc.c:787 Any help is appreciated. Thanks. --=20 NAKAJI Hiroyuki From owner-freebsd-current@FreeBSD.ORG Mon Dec 8 22:49:51 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 033731065670 for ; Mon, 8 Dec 2008 22:49:51 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.233]) by mx1.freebsd.org (Postfix) with ESMTP id C65EC8FC18 for ; Mon, 8 Dec 2008 22:49:50 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so1374113rvf.43 for ; Mon, 08 Dec 2008 14:49:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=dw2C4ZP8Fzijbw9UjU37YK/OUlXmcmcSJIrLTXJDTRk=; b=ZOHxN+LUbiXfQhHSPLSuF8biwavrcEworG1DNRKtp5lNwp4mQS4+Losv0kT1tkSosC 0OOCKoqCjG4an/Z6nmTdG9spzYIKOJsb/gw3chOlOOw5LlS6FkOElk7O513j+Z2Nf11A l9p6BCvd1KNx822Cy38lY73dwsxxhT0MrvWRs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=TstsfdH5rz0BT4wwZ5naDpj5v466TSEbpssRj9N3GPCLRamhGgQw3OheyjsouwODCg /G8pmv8AGqiydJOiIMjyXDSMLCGC/NKuSUKb4EcdLa6OjmQ5b4Ko2e0sQE7gB8D1psS7 BgGi13n33TIOFuM6EU7wASb4Jkp86KYdaXyik= Received: by 10.141.100.15 with SMTP id c15mr1896371rvm.52.1228776590327; Mon, 08 Dec 2008 14:49:50 -0800 (PST) Received: by 10.141.142.3 with HTTP; Mon, 8 Dec 2008 14:49:50 -0800 (PST) Message-ID: <3c1674c90812081449r7b8ef242lce478da3d2d7a968@mail.gmail.com> Date: Mon, 8 Dec 2008 14:49:50 -0800 From: "Kip Macy" Sender: mat.macy@gmail.com To: "NAKAJI Hiroyuki" In-Reply-To: <86iqpu2sjc.fsf@ra333.heimat.gr.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline References: <87zljb8nw6.fsf@roddy.4407.kankyo-u.ac.jp> <3a142e750812050613w4e9155bat950f03716aa58beb@mail.gmail.com> <863ah2qivi.fsf@ra333.heimat.gr.jp> <86iqpu2sjc.fsf@ra333.heimat.gr.jp> X-Google-Sender-Auth: 1bfffc3dccc1a4e2 Cc: freebsd-current@freebsd.org Subject: Re: Fatal trap 12: page fault while in kernel mode X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Dec 2008 22:49:51 -0000 UmVjZW50bHkgIC0gc3RhcnRpbmcgd2hlbj8KClRoYW5rcywKS2lwCgoKCk9uIE1vbiwgRGVjIDgs IDIwMDggYXQgMjo0NyBQTSwgTkFLQUpJIEhpcm95dWtpIDxuYWthamlAanAuZnJlZWJzZC5vcmc+ IHdyb3RlOgo+Pj4+Pj4gSW4gPDg2M2FoMnFpdmkuZnNmQHJhMzMzLmhlaW1hdC5nci5qcD4KPj4+ Pj4+ICAgTkFLQUpJIEhpcm95dWtpIDxuYWthamlAanAuZnJlZWJzZC5vcmc+IHdyb3RlOgo+Cj4+ IFNvLCB3aGF0IEkgaGF2ZSB0byBkbyBhcmUgdGhyZWU6Cj4KPj4gMS4gRnVsbCB1cGdyYWRlIHRv IHRoZSBsYXRlc3Qga2VybmVsIGFuZCB1c2VybGFuZCAod29ybGQpCj4+IDIuIE9ic2VydmUgd2hl dGhlciBhIHBhbmljIG9jY3VycywgYW5kCj4+IDMuIFdoZW4gcGFuaWMsIHNhdmUgdGhlIGNyYXNo IGR1bXAgYW5kIGdldCBmdWxsIGJ0IHdpdGgga2dkYgo+Cj4+IEkgaG9wZSBpdCB3aWxsIG5vdCBy ZWFjaCB0byB0aGUgc3RlcCB0aHJlZS4gVGhhbmtzLgo+Cj4gVW5mb3J0dW5hdGVseSwgSSBmYWNl ZCB0byAiZGI+ICIgb24gbXkgc2VyaWFsIGNvbnNvbGUuCj4KPiBkYj4gYnQKPiBUcmFjaW5nIHBp ZCA5NjQgdGlkIDEwMDEzMSB0ZCAweGM0OTg3NmMwCj4gc3ZjX3J1bl9pbnRlcm5hbChlNjg2MWQy NCxjMDg1MDc5MyxjNDRmMjc4MCxlNjg2MWQzOCwxLC4uLikgYXQgc3ZjX3J1bl9pbnRlcm5hbCsK PiAweDU3NQo+IHN2Y190aHJlYWRfc3RhcnQoYzQ0ZjI3ODAsZTY4NjFkMzgsMSwwLDQ4MzZiZDE0 LC4uLikgYXQgc3ZjX3RocmVhZF9zdGFydCsweDEwCj4gZm9ya19leGl0KGMwYTU3ZmUwLGM0NGYy NzgwLGU2ODYxZDM4KSBhdCBmb3JrX2V4aXQrMHg5Mwo+IGZvcmtfdHJhbXBvbGluZSgpIGF0IGZv cmtfdHJhbXBvbGluZSsweDgKPiAtLS0gdHJhcCAwLCBlaXAgPSAweGMsIGVzcCA9IDB4MzMsIGVi cCA9IDAgLS0tCj4gZGI+IGNhbGwgZG9hZHVtcAo+IFBoeXNpY2FsIG1lbW9yeTogMTAxMCBNQgo+ IER1bXBpbmcgMjUwIE1COiAyMzUgMjE5IDIwMyAxODcgMTcxIDE1NSAxMzkgMTIzIDEwNyA5MSA3 NSA1OSA0MyAyNyAxMQo+IER1bXAgY29tcGxldGUKPiA9IDB4Zgo+IGRiPiBidAo+IFRyYWNpbmcg cGlkIDk2NCB0aWQgMTAwMTMxIHRkIDB4YzQ5ODc2YzAKPiBzdmNfcnVuX2ludGVybmFsKGU2ODYx ZDI0LGMwODUwNzkzLGM0NGYyNzgwLGU2ODYxZDM4LDEsLi4uKSBhdCBzdmNfcnVuX2ludGVybmFs Kwo+IDB4NTc1Cj4gc3ZjX3RocmVhZF9zdGFydChjNDRmMjc4MCxlNjg2MWQzOCwxLDAsNDgzNmJk MTQsLi4uKSBhdCBzdmNfdGhyZWFkX3N0YXJ0KzB4MTAKPiBmb3JrX2V4aXQoYzBhNTdmZTAsYzQ0 ZjI3ODAsZTY4NjFkMzgpIGF0IGZvcmtfZXhpdCsweDkzCj4gZm9ya190cmFtcG9saW5lKCkgYXQg Zm9ya190cmFtcG9saW5lKzB4OAo+IC0tLSB0cmFwIDAsIGVpcCA9IDB4YywgZXNwID0gMHgzMywg ZWJwID0gMCAtLS0KPiBkYj4gcmVzZXQKPgo+IEFuZCB0aGVuLCBJIHVzZWQga2dkYi4KPgo+ICMg a2dkYiAvYm9vdC9rZXJuZWwva2VybmVsLnN5bWJvbHMgdm1jb3JlLjkKPiBHTlUgZ2RiIDYuMS4x IFtGcmVlQlNEXQo+IENvcHlyaWdodCAyMDA0IEZyZWUgU29mdHdhcmUgRm91bmRhdGlvbiwgSW5j Lgo+IEdEQiBpcyBmcmVlIHNvZnR3YXJlLCBjb3ZlcmVkIGJ5IHRoZSBHTlUgR2VuZXJhbCBQdWJs aWMgTGljZW5zZSwgYW5kIHlvdSBhcmUKPiB3ZWxjb21lIHRvIGNoYW5nZSBpdCBhbmQvb3IgZGlz dHJpYnV0ZSBjb3BpZXMgb2YgaXQgdW5kZXIgY2VydGFpbiBjb25kaXRpb25zLgo+IFR5cGUgInNo b3cgY29weWluZyIgdG8gc2VlIHRoZSBjb25kaXRpb25zLgo+IFRoZXJlIGlzIGFic29sdXRlbHkg bm8gd2FycmFudHkgZm9yIEdEQi4gIFR5cGUgInNob3cgd2FycmFudHkiIGZvciBkZXRhaWxzLgo+ IFRoaXMgR0RCIHdhcyBjb25maWd1cmVkIGFzICJpMzg2LW1hcmNlbC1mcmVlYnNkIi4uLgo+Cj4g VW5yZWFkIHBvcnRpb24gb2YgdGhlIGtlcm5lbCBtZXNzYWdlIGJ1ZmZlcjoKPgo+Cj4gRmF0YWwg dHJhcCAxMjogcGFnZSBmYXVsdCB3aGlsZSBpbiBrZXJuZWwgbW9kZQo+IGNwdWlkID0gMDsgYXBp YyBpZCA9IDAwCj4gZmF1bHQgdmlydHVhbCBhZGRyZXNzICAgPSAweDAKPiBmYXVsdCBjb2RlICAg ICAgICAgICAgICA9IHN1cGVydmlzb3IgcmVhZCwgcGFnZSBub3QgcHJlc2VudAo+IGluc3RydWN0 aW9uIHBvaW50ZXIgICAgID0gMHgyMDoweGMwYTU3YTc1Cj4gc3RhY2sgcG9pbnRlciAgICAgICAg ICAgPSAweDI4OjB4ZTY4NjFjNDQKPiBmcmFtZSBwb2ludGVyICAgICAgICAgICA9IDB4Mjg6MHhl Njg2MWNlYwo+IGNvZGUgc2VnbWVudCAgICAgICAgICAgID0gYmFzZSAweDAsIGxpbWl0IDB4ZmZm ZmYsIHR5cGUgMHgxYgo+ICAgICAgICAgICAgICAgICAgICAgICAgPSBEUEwgMCwgcHJlcyAxLCBk ZWYzMiAxLCBncmFuIDEKPiBwcm9jZXNzb3IgZWZsYWdzICAgICAgICA9IGludGVycnVwdCBlbmFi bGVkLCByZXN1bWUsIElPUEwgPSAwCj4gY3VycmVudCBwcm9jZXNzICAgICAgICAgPSA5NjQgKG5m c2Q6IHNlcnZpY2UpCj4gUGh5c2ljYWwgbWVtb3J5OiAxMDEwIE1CCj4gRHVtcGluZyAyNTAgTUI6 IDIzNSAyMTkgMjAzIDE4NyAxNzEgMTU1IDEzOSAxMjMgMTA3IDkxIDc1IDU5IDQzIDI3IDExCj4K PiBSZWFkaW5nIHN5bWJvbHMgZnJvbSAvYm9vdC9rZXJuZWwvbGlucHJvY2ZzLmtvLi4uUmVhZGlu ZyBzeW1ib2xzIGZyb20gL2Jvb3Qva2VybmVsL2xpbnByb2Nmcy5rby5zeW1ib2xzLi4uZG9uZS4K PiBkb25lLgo+IExvYWRlZCBzeW1ib2xzIGZvciAvYm9vdC9rZXJuZWwvbGlucHJvY2ZzLmtvCj4g UmVhZGluZyBzeW1ib2xzIGZyb20gL2Jvb3Qva2VybmVsL2xpbnV4LmtvLi4uUmVhZGluZyBzeW1i b2xzIGZyb20gL2Jvb3Qva2VybmVsL2xpbnV4LmtvLnN5bWJvbHMuLi5kb25lLgo+IGRvbmUuCj4g TG9hZGVkIHN5bWJvbHMgZm9yIC9ib290L2tlcm5lbC9saW51eC5rbwo+IFJlYWRpbmcgc3ltYm9s cyBmcm9tIC9ib290L2tlcm5lbC9zbWJ1cy5rby4uLlJlYWRpbmcgc3ltYm9scyBmcm9tIC9ib290 L2tlcm5lbC9zbWJ1cy5rby5zeW1ib2xzLi4uZG9uZS4KPiBkb25lLgo+IExvYWRlZCBzeW1ib2xz IGZvciAvYm9vdC9rZXJuZWwvc21idXMua28KPiBSZWFkaW5nIHN5bWJvbHMgZnJvbSAvYm9vdC9r ZXJuZWwvYWlvLmtvLi4uUmVhZGluZyBzeW1ib2xzIGZyb20gL2Jvb3Qva2VybmVsL2Fpby5rby5z eW1ib2xzLi4uZG9uZS4KPiBkb25lLgo+IExvYWRlZCBzeW1ib2xzIGZvciAvYm9vdC9rZXJuZWwv YWlvLmtvCj4gUmVhZGluZyBzeW1ib2xzIGZyb20gL2Jvb3Qva2VybmVsL21nYS5rby4uLlJlYWRp bmcgc3ltYm9scyBmcm9tIC9ib290L2tlcm5lbC9tZ2Eua28uc3ltYm9scy4uLmRvbmUuCj4gZG9u ZS4KPiBMb2FkZWQgc3ltYm9scyBmb3IgL2Jvb3Qva2VybmVsL21nYS5rbwo+IFJlYWRpbmcgc3lt Ym9scyBmcm9tIC9ib290L2tlcm5lbC9kcm0ua28uLi5SZWFkaW5nIHN5bWJvbHMgZnJvbSAvYm9v dC9rZXJuZWwvZHJtLmtvLnN5bWJvbHMuLi5kb25lLgo+IGRvbmUuCj4gTG9hZGVkIHN5bWJvbHMg Zm9yIC9ib290L2tlcm5lbC9kcm0ua28KPiBSZWFkaW5nIHN5bWJvbHMgZnJvbSAvYm9vdC9rZXJu ZWwvYXRhcGljYW0ua28uLi5SZWFkaW5nIHN5bWJvbHMgZnJvbSAvYm9vdC9rZXJuZWwvYXRhcGlj YW0ua28uc3ltYm9scy4uLmRvbmUuCj4gZG9uZS4KPiBMb2FkZWQgc3ltYm9scyBmb3IgL2Jvb3Qv a2VybmVsL2F0YXBpY2FtLmtvCj4gUmVhZGluZyBzeW1ib2xzIGZyb20gL2Jvb3Qva2VybmVsL251 bGxmcy5rby4uLlJlYWRpbmcgc3ltYm9scyBmcm9tIC9ib290L2tlcm5lbC9udWxsZnMua28uc3lt Ym9scy4uLmRvbmUuCj4gZG9uZS4KPiBMb2FkZWQgc3ltYm9scyBmb3IgL2Jvb3Qva2VybmVsL251 bGxmcy5rbwo+IFJlYWRpbmcgc3ltYm9scyBmcm9tIC9ib290L2tlcm5lbC9sb2dvX3NhdmVyLmtv Li4uUmVhZGluZyBzeW1ib2xzIGZyb20gL2Jvb3Qva2VybmVsL2xvZ29fc2F2ZXIua28uc3ltYm9s cy4uLmRvbmUuCj4gZG9uZS4KPiBMb2FkZWQgc3ltYm9scyBmb3IgL2Jvb3Qva2VybmVsL2xvZ29f c2F2ZXIua28KPiAjMCAgZG9hZHVtcCAoKSBhdCBwY3B1Lmg6MjQ2Cj4gMjQ2ICAgICBwY3B1Lmg6 IE5vIHN1Y2ggZmlsZSBvciBkaXJlY3RvcnkuCj4gICAgICAgIGluIHBjcHUuaAo+IChrZ2RiKSBi dAo+ICMwICBkb2FkdW1wICgpIGF0IHBjcHUuaDoyNDYKPiAjMSAgMHhjMDRjMmE2OSBpbiBkYl9m bmNhbGwgKGR1bW15MT0tMTA1OTgxMjU3NiwgZHVtbXkyPTAsIGR1bW15Mz0tMTA2NzUwNTc2OCwK PiAgICBkdW1teTQ9MHhlNjg2MTlkOCAi77+9Omnvv71cMjAwOCfvv70iKSBhdCAvdXNyL3NyYy9z eXMvZGRiL2RiX2NvbW1hbmQuYzo1NDgKPiAjMiAgMHhjMDRjMmU2MSBpbiBkYl9jb21tYW5kIChs YXN0X2NtZHA9MHhjMGQzZTg1YywgY21kX3RhYmxlPTB4MCwgZG9wYWdlcj0xKQo+ICAgIGF0IC91 c3Ivc3JjL3N5cy9kZGIvZGJfY29tbWFuZC5jOjQ0NQo+ICMzICAweGMwNGMyZmJhIGluIGRiX2Nv bW1hbmRfbG9vcCAoKSBhdCAvdXNyL3NyYy9zeXMvZGRiL2RiX2NvbW1hbmQuYzo0OTgKPiAjNCAg MHhjMDRjNGRmZCBpbiBkYl90cmFwICh0eXBlPTEyLCBjb2RlPTApIGF0IC91c3Ivc3JjL3N5cy9k ZGIvZGJfbWFpbi5jOjIyOQo+ICM1ICAweGMwOGEyNDU2IGluIGtkYl90cmFwICh0eXBlPTEyLCBj b2RlPTAsIHRmPTB4ZTY4NjFjMDQpCj4gICAgYXQgL3Vzci9zcmMvc3lzL2tlcm4vc3Vicl9rZGIu Yzo1MzQKPiAjNiAgMHhjMGI4MDU5ZiBpbiB0cmFwX2ZhdGFsIChmcmFtZT0weGU2ODYxYzA0LCBl dmE9MCkKPiAgICBhdCAvdXNyL3NyYy9zeXMvaTM4Ni9pMzg2L3RyYXAuYzo5MjAKPiAjNyAgMHhj MGI4MDg2MCBpbiB0cmFwX3BmYXVsdCAoZnJhbWU9MHhlNjg2MWMwNCwgdXNlcm1vZGU9MCwgZXZh PTApCj4gICAgYXQgL3Vzci9zcmMvc3lzL2kzODYvaTM4Ni90cmFwLmM6ODQyCj4gIzggIDB4YzBi ODEyNmEgaW4gdHJhcCAoZnJhbWU9MHhlNjg2MWMwNCkgYXQgL3Vzci9zcmMvc3lzL2kzODYvaTM4 Ni90cmFwLmM6NTIyCj4gIzkgIDB4YzBiNjUyY2IgaW4gY2FsbHRyYXAgKCkgYXQgL3Vzci9zcmMv c3lzL2kzODYvaTM4Ni9leGNlcHRpb24uczoxNjUKPiAjMTAgMHhjMGE1N2E3NSBpbiBzdmNfcnVu X2ludGVybmFsIChwb29sPTB4YzQ0ZjI3ODAsIGlzbWFzdGVyPTApCj4gICAgYXQgL3Vzci9zcmMv c3lzL3JwYy9zdmMuYzo3ODcKPiAjMTEgMHhjMGE1N2ZmMCBpbiBzdmNfdGhyZWFkX3N0YXJ0IChh cmc9MHhjNDRmMjc4MCkKPiAgICBhdCAvdXNyL3NyYy9zeXMvcnBjL3N2Yy5jOjExODgKPiAjMTIg MHhjMDg1MDc5MyBpbiBmb3JrX2V4aXQgKGNhbGxvdXQ9MHhjMGE1N2ZlMCA8c3ZjX3RocmVhZF9z dGFydD4sCj4gICAgYXJnPTB4YzQ0ZjI3ODAsIGZyYW1lPTB4ZTY4NjFkMzgpIGF0IC91c3Ivc3Jj L3N5cy9rZXJuL2tlcm5fZm9yay5jOjgyMQo+ICMxMyAweGMwYjY1MzQwIGluIGZvcmtfdHJhbXBv bGluZSAoKSBhdCAvdXNyL3NyYy9zeXMvaTM4Ni9pMzg2L2V4Y2VwdGlvbi5zOjI3MAo+IChrZ2Ri KQo+Cj4gSW4gYWRkaXRpb24sCj4KPiAjIGFkZHIybGluZSAtZSAvYm9vdC9rZXJuZWwva2VybmVs LnN5bWJvbHMgMHhjMGE1N2E3NQo+IC91c3Ivc3JjL3N5cy9ycGMvc3ZjLmM6Nzg3Cj4KPiBBbnkg aGVscCBpcyBhcHByZWNpYXRlZC4gVGhhbmtzLgo+IC0tCj4gTkFLQUpJIEhpcm95dWtpCj4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPiBmcmVlYnNkLWN1 cnJlbnRAZnJlZWJzZC5vcmcgbWFpbGluZyBsaXN0Cj4gaHR0cDovL2xpc3RzLmZyZWVic2Qub3Jn L21haWxtYW4vbGlzdGluZm8vZnJlZWJzZC1jdXJyZW50Cj4gVG8gdW5zdWJzY3JpYmUsIHNlbmQg YW55IG1haWwgdG8gImZyZWVic2QtY3VycmVudC11bnN1YnNjcmliZUBmcmVlYnNkLm9yZyIKPgoK CgotLSAKSWYgd2UgZGVzaXJlIHJlc3BlY3QgZm9yIHRoZSBsYXcsIHdlIG11c3QgZmlyc3QgbWFr ZSB0aGUgbGF3IHJlc3BlY3RhYmxlLgotIExvdWlzIEQuIEJyYW5kZWlzCg== From owner-freebsd-current@FreeBSD.ORG Mon Dec 8 22:51:14 2008 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 69823106564A; Mon, 8 Dec 2008 22:51:14 +0000 (UTC) (envelope-from sobomax@FreeBSD.org) Received: from sippysoft.com (gk1.360sip.com [72.236.70.240]) by mx1.freebsd.org (Postfix) with ESMTP id 311048FC08; Mon, 8 Dec 2008 22:51:13 +0000 (UTC) (envelope-from sobomax@FreeBSD.org) Received: from [192.168.1.38] (S0106001372fd1e07.vs.shawcable.net [70.71.171.106]) (authenticated bits=0) by sippysoft.com (8.13.8/8.13.8) with ESMTP id mB8Mf6OB093006 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Dec 2008 14:41:06 -0800 (PST) (envelope-from sobomax@FreeBSD.org) Message-ID: <493DA269.2070805@FreeBSD.org> Date: Mon, 08 Dec 2008 14:40:41 -0800 From: Maxim Sobolev Organization: Sippy Software, Inc. User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: hackers@FreeBSD.org, Luigi Rizzo , "current@freebsd.org" Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Enhancing cdboot [patch for review] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Dec 2008 22:51:14 -0000 Hi, Below please find patch that enhances cdboot with two compile-time options: 1. CDBOOT_SILENT. When this option is set, the cdboot doesn't produce any messages except "Loading, please wait..." and it also passes RBX_MUTE flag to the next stage to silence it as well. This is intended for custom installations where end-user is not required to see any messages or interfere with the boot process. 2. CDBOOT_PROMPT. When this option is enabled the cdboot behaves like windows xp or vista cd loader, that is it reads MBR from the first hard drive in the system and if the MBR is bootable (i.e. drive has some other operating system installed on it) then it presents user with "Press any key to boot from CD" prompt and waits 20 seconds. If key is not pressed then the control is passed to the MBR, otherwise CD is booted. This is intended for installation CD to allow unattended mode and also helps when installation CD is unintentionally left in the drive of the machine that is set to boot off CD. Any comments/suggestions are appreciated. If there are no objections I would like to commit the change. The long-term goal is to make CDBOOT_PROMPT default mode for installation CD. http://sobomax.sippysoft.com/~sobomax/cdboot.diff -Maxim From owner-freebsd-current@FreeBSD.ORG Mon Dec 8 22:51:14 2008 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EA6081065676; Mon, 8 Dec 2008 22:51:14 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: from sippysoft.com (gk1.360sip.com [72.236.70.240]) by mx1.freebsd.org (Postfix) with ESMTP id B2A178FC0C; Mon, 8 Dec 2008 22:51:14 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: from [192.168.1.38] (S0106001372fd1e07.vs.shawcable.net [70.71.171.106]) (authenticated bits=0) by sippysoft.com (8.13.8/8.13.8) with ESMTP id mB8MenNc092961 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Dec 2008 14:40:50 -0800 (PST) (envelope-from sobomax@sippysoft.com) Message-ID: <493DA258.7010001@sippysoft.com> Date: Mon, 08 Dec 2008 14:40:24 -0800 From: Maxim Sobolev Organization: Sippy Software User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: hackers@FreeBSD.org, Luigi Rizzo , "current@freebsd.org" Content-Type: text/plain; charset=KOI8-U; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 08 Dec 2008 23:04:47 +0000 Cc: Subject: Enhancing cdboot [patch for review] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Dec 2008 22:51:15 -0000 Hi, Below please find patch that enhances cdboot with two compile-time options: 1. CDBOOT_SILENT. When this option is set, the cdboot doesn't produce any messages except "Loading, please wait..." and it also passes RBX_MUTE flag to the next stage to silence it as well. This is intended for custom installations where end-user is not required to see any messages or interfere with the boot process. 2. CDBOOT_PROMPT. When this option is enabled the cdboot behaves like windows xp or vista cd loader, that is it reads MBR from the first hard drive in the system and if the MBR is bootable (i.e. drive has some other operating system installed on it) then it presents user with "Press any key to boot from CD" prompt and waits 20 seconds. If key is not pressed then the control is passed to the MBR, otherwise CD is booted. This is intended for installation CD to allow unattended mode and also helps when installation CD is unintentionally left in the drive of the machine that is set to boot off CD. Any comments/suggestions are appreciated. If there are no objections I would like to commit the change. The long-term goal is to make CDBOOT_PROMPT default mode for installation CD. http://sobomax.sippysoft.com/~sobomax/cdboot.diff -Maxim From owner-freebsd-current@FreeBSD.ORG Mon Dec 8 23:14:31 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C1C231065675 for ; Mon, 8 Dec 2008 23:14:31 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id 70FCA8FC16 for ; Mon, 8 Dec 2008 23:14:31 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from trouble.errno.com (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id mB8MaDFQ056168 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Dec 2008 14:36:14 -0800 (PST) (envelope-from sam@freebsd.org) Message-ID: <493DA15D.7080109@freebsd.org> Date: Mon, 08 Dec 2008 14:36:13 -0800 From: Sam Leffler Organization: FreeBSD Project User-Agent: Thunderbird 2.0.0.9 (X11/20071125) MIME-Version: 1.0 To: Vladimir Grebenschikov References: <200811301906.mAUJ6Z30099035@svn.freebsd.org> <1228739237.1860.21.camel@localhost> In-Reply-To: <1228739237.1860.21.camel@localhost> Content-Type: multipart/mixed; boundary="------------000701020606070005060705" X-DCC--Metrics: ebb.errno.com; whitelist Cc: current Subject: Re: svn commit: r185482 - head/sys/dev/ath/ath_rate/sample X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Dec 2008 23:14:31 -0000 This is a multi-part message in MIME format. --------------000701020606070005060705 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Vladimir Grebenschikov wrote: > * On Sun, 2008-11-30 at 19:06 +0000, Sam Leffler wrote: > >> Author: sam >> Date: Sun Nov 30 19:06:35 2008 >> New Revision: 185482 >> URL: http://svn.freebsd.org/changeset/base/185482 >> >> Log: >> Major overhaul: >> o eliminate private state indexed by 802.11 rate codes; use the hal's >> rate tables directly to get the same info >> o calculate a mask of operational rates to optimize lookups and checks >> (instead of using for loops and similar) >> o optimize size bin operations >> o ignore rates marked as "do not use" in the hal phy tables >> o fix bug that caused upshifting to break in 11g once the rate dropped >> below 11Mb/s >> o add more intelligent multi-rate tx schedules >> o add support for 1/2 and 1/4 width channels >> o add dev.ath.X.sample_stats sysctl to dump runtime statistics to the console >> (needs to go up to a user app) >> o export more tuning knobs via sysctls (still a couple of magic constants) >> > > Looks like, after that commit, I can't use if_ath loaded as module any > more: > > # kldload /boot/kernel/ath_rate.ko > kldload: can't load /boot/kernel/ath_rate.ko: No such file or directory > # dmesg | tail -n1 > link_elf: symbol ath_hal_computetxtime undefined > # > > Yes, I've read UPDATING entry 20081130. > But I have no ath_hal entry in my kernel config, > I've loaded ath as KLDs. > > How to fix that problem ? > > > Try the attached change. Sam --------------000701020606070005060705 Content-Type: text/x-patch; name="sample.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="sample.diff" Index: sample.c =================================================================== --- sample.c (revision 185745) +++ sample.c (working copy) @@ -1018,4 +1018,5 @@ }; DECLARE_MODULE(ath_rate, sample_mod, SI_SUB_DRIVERS, SI_ORDER_FIRST); MODULE_VERSION(ath_rate, 1); +MODULE_DEPEND(ath_rate, ath, 1, 1, 1); MODULE_DEPEND(ath_rate, wlan, 1, 1, 1); --------------000701020606070005060705-- From owner-freebsd-current@FreeBSD.ORG Mon Dec 8 23:14:32 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 26AA1106564A for ; Mon, 8 Dec 2008 23:14:32 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id CF7C68FC17 for ; Mon, 8 Dec 2008 23:14:31 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from trouble.errno.com (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id mB8MaXcm056171 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Dec 2008 14:36:34 -0800 (PST) (envelope-from sam@freebsd.org) Message-ID: <493DA171.5050402@freebsd.org> Date: Mon, 08 Dec 2008 14:36:33 -0800 From: Sam Leffler Organization: FreeBSD Project User-Agent: Thunderbird 2.0.0.9 (X11/20071125) MIME-Version: 1.0 To: Jille Timmermans References: <200811301906.mAUJ6Z30099035@svn.freebsd.org> <1228739237.1860.21.camel@localhost> <493D1436.3030606@quis.cx> In-Reply-To: <493D1436.3030606@quis.cx> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-DCC--Metrics: ebb.errno.com; whitelist Cc: Vladimir Grebenschikov , current Subject: Re: svn commit: r185482 - head/sys/dev/ath/ath_rate/sample X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Dec 2008 23:14:32 -0000 Jille Timmermans wrote: > Vladimir Grebenschikov wrote: >> * On Sun, 2008-11-30 at 19:06 +0000, Sam Leffler wrote: >> >>> Author: sam >>> Date: Sun Nov 30 19:06:35 2008 >>> New Revision: 185482 >>> URL: http://svn.freebsd.org/changeset/base/185482 >>> >>> Log: >>> Major overhaul: >>> o eliminate private state indexed by 802.11 rate codes; use the hal's >>> rate tables directly to get the same info >>> o calculate a mask of operational rates to optimize lookups and >>> checks >>> (instead of using for loops and similar) >>> o optimize size bin operations >>> o ignore rates marked as "do not use" in the hal phy tables >>> o fix bug that caused upshifting to break in 11g once the rate >>> dropped >>> below 11Mb/s >>> o add more intelligent multi-rate tx schedules >>> o add support for 1/2 and 1/4 width channels >>> o add dev.ath.X.sample_stats sysctl to dump runtime statistics to >>> the console >>> (needs to go up to a user app) >>> o export more tuning knobs via sysctls (still a couple of magic >>> constants) >>> >> >> Looks like, after that commit, I can't use if_ath loaded as module any >> more: >> >> # kldload /boot/kernel/ath_rate.ko >> kldload: can't load /boot/kernel/ath_rate.ko: No such file or directory >> # dmesg | tail -n1 link_elf: symbol ath_hal_computetxtime undefined >> # >> >> Yes, I've read UPDATING entry 20081130. >> But I have no ath_hal entry in my kernel config, I've loaded ath as >> KLDs. >> >> How to fix that problem ? >> > I have the same problem if I load it with kernel modules. > If I compile it into my kernel (with ath, ath_hal and that option > (can't remember it for now)) my system paniced during boot. > I can't get a coredump, but I will try getting a stacktrace with ddb > tonight. > > My Atheros (2413 iirc) wasn't usable before the import (did some > printf's during boot, but I couldn't get ath0 showing up in ifconfig) > I am willing to help debugging if needed. Where is the PR? Sam From owner-freebsd-current@FreeBSD.ORG Mon Dec 8 23:14:32 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 768691065672 for ; Mon, 8 Dec 2008 23:14:32 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id 354AE8FC18 for ; Mon, 8 Dec 2008 23:14:32 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from trouble.errno.com (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id mB8Mew1Q056204 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Dec 2008 14:40:59 -0800 (PST) (envelope-from sam@freebsd.org) Message-ID: <493DA27A.2070100@freebsd.org> Date: Mon, 08 Dec 2008 14:40:58 -0800 From: Sam Leffler Organization: FreeBSD Project User-Agent: Thunderbird 2.0.0.9 (X11/20071125) MIME-Version: 1.0 To: vova@fbsd.ru References: <200811301906.mAUJ6Z30099035@svn.freebsd.org> <1228739237.1860.21.camel@localhost> <493D1436.3030606@quis.cx> <1228740002.1860.26.camel@localhost> In-Reply-To: <1228740002.1860.26.camel@localhost> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-DCC--Metrics: ebb.errno.com; whitelist Cc: Jille Timmermans , current Subject: Re: svn commit: r185482 - head/sys/dev/ath/ath_rate/sample X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Dec 2008 23:14:32 -0000 ath's rate control module is bound using symbols so only one of these modules can ever be used at a time. A module dependency is used to auto-load the rate control module hence the fixed name. At the time this code was written it was felt the overhead to use indirect function calls and the like was too significant. Now folks may not care in which case you could use some sort of registration-style mechanism to allow runtime selection of the rate control algorithm. Fee free to supply patches. OTOH sample is so vastly superior to the other 2 algorithms that I almost removed the others recently. Sam Vladimir Grebenschikov wrote: > On Mon, 2008-12-08 at 13:33 +0100, Jille Timmermans wrote: > > after > cd /sys/modules/ath_rate_amrr > make all > make install > kldload /boot/kernel/ath_rate .ko > > It works now, but why three directories in sys/modules tree make > same .ko object: > > # fgrep ath /sys/modules/Makefile > ath \ > ath_rate_amrr \ > ath_rate_onoe \ > ath_rate_sample \ > # fgrep KMOD /sys/modules/ath_rate*/Makefile > /sys/modules/ath_rate_amrr/Makefile:KMOD= ath_rate > /sys/modules/ath_rate_onoe/Makefile:KMOD= ath_rate > /sys/modules/ath_rate_sample/Makefile:KMOD= ath_rate > # > > Looks like one overwrites another. What is right behaviour ? > > >> Vladimir Grebenschikov wrote: >> >>> * On Sun, 2008-11-30 at 19:06 +0000, Sam Leffler wrote: >>> >>> >>>> Author: sam >>>> Date: Sun Nov 30 19:06:35 2008 >>>> New Revision: 185482 >>>> URL: http://svn.freebsd.org/changeset/base/185482 >>>> >>>> Log: >>>> Major overhaul: >>>> o eliminate private state indexed by 802.11 rate codes; use the hal's >>>> rate tables directly to get the same info >>>> o calculate a mask of operational rates to optimize lookups and checks >>>> (instead of using for loops and similar) >>>> o optimize size bin operations >>>> o ignore rates marked as "do not use" in the hal phy tables >>>> o fix bug that caused upshifting to break in 11g once the rate dropped >>>> below 11Mb/s >>>> o add more intelligent multi-rate tx schedules >>>> o add support for 1/2 and 1/4 width channels >>>> o add dev.ath.X.sample_stats sysctl to dump runtime statistics to the console >>>> (needs to go up to a user app) >>>> o export more tuning knobs via sysctls (still a couple of magic constants) >>>> >>>> >>> Looks like, after that commit, I can't use if_ath loaded as module any >>> more: >>> >>> # kldload /boot/kernel/ath_rate.ko >>> kldload: can't load /boot/kernel/ath_rate.ko: No such file or directory >>> # dmesg | tail -n1 >>> link_elf: symbol ath_hal_computetxtime undefined >>> # >>> >>> Yes, I've read UPDATING entry 20081130. >>> But I have no ath_hal entry in my kernel config, >>> I've loaded ath as KLDs. >>> >>> How to fix that problem ? >>> >>> >> I have the same problem if I load it with kernel modules. >> If I compile it into my kernel (with ath, ath_hal and that option (can't >> remember it for now)) my system paniced during boot. >> I can't get a coredump, but I will try getting a stacktrace with ddb >> tonight. >> >> My Atheros (2413 iirc) wasn't usable before the import (did some >> printf's during boot, but I couldn't get ath0 showing up in ifconfig) >> I am willing to help debugging if needed. >> >> -- Jille >> From owner-freebsd-current@FreeBSD.ORG Mon Dec 8 23:46:20 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 577811065709; Mon, 8 Dec 2008 23:46:20 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.9.129]) by mx1.freebsd.org (Postfix) with ESMTP id 16EBE8FC24; Mon, 8 Dec 2008 23:46:19 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 4E3CB7309E; Tue, 9 Dec 2008 00:51:19 +0100 (CET) Date: Tue, 9 Dec 2008 00:51:19 +0100 From: Luigi Rizzo To: Maxim Sobolev Message-ID: <20081208235119.GA46608@onelab2.iet.unipi.it> References: <493DA269.2070805@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <493DA269.2070805@FreeBSD.org> User-Agent: Mutt/1.4.2.3i Cc: Luigi Rizzo , hackers@freebsd.org, "current@freebsd.org" Subject: Re: Enhancing cdboot [patch for review] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Dec 2008 23:46:20 -0000 On Mon, Dec 08, 2008 at 02:40:41PM -0800, Maxim Sobolev wrote: > Hi, > > Below please find patch that enhances cdboot with two compile-time options: ... > Any comments/suggestions are appreciated. If there are no objections I > would like to commit the change. The long-term goal is to make > CDBOOT_PROMPT default mode for installation CD. > > http://sobomax.sippysoft.com/~sobomax/cdboot.diff Looks good. Some comments: 1. since there is plenty of space in the cdboot sector, why don't you make the two option always compiled in, controlling which one to activate through flags in the bootsector itself, to be set patching the binary sector itself using a mechanism similar to boot0cfg. Of course you cannot alter a cdrom after you burn it, but it makes it easier to build CDs with one or the other defaults, patching cdboot or the iso image itself before creating/burning it. 2. in fact, the 'silent' option could be disabled at runtime by pressing some key (e.g. adding a short wait loop before proceeding; if this is meant for custom, unattended CDs the extra delay should not matter much); 3. one nitpick -- in one of the first chunks you replace $start with $LOAD, but if i am not mistaken operation depends on $LOAD = $start, so why don't you always use the same ? Also in terms of relocation size, wouldn't it be the case of hardwiring the size of the cd boot sector: - mov $((end_init - start)/2),%cx + mov 1024,%cx 4. another nitpick -- the value you pass in %si to the MBR does not seem to point to anything useful. As discussed about boot0.S and the followup in the mailing lists, there seems to be no standard but at least some MBR expect %si to point to a partition entry, so you should probably initialize one in a way similar way to that used by boot0.S cheers luigi From owner-freebsd-current@FreeBSD.ORG Mon Dec 8 23:54:02 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 923EB1065678 for ; Mon, 8 Dec 2008 23:54:02 +0000 (UTC) (envelope-from bahamasfranks@gmail.com) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.28]) by mx1.freebsd.org (Postfix) with ESMTP id 3F2488FC19 for ; Mon, 8 Dec 2008 23:54:02 +0000 (UTC) (envelope-from bahamasfranks@gmail.com) Received: by yw-out-2324.google.com with SMTP id 9so569877ywe.13 for ; Mon, 08 Dec 2008 15:54:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=xDJUnWpaWCI0J3OZqayOhXGV3dYP5XL2VXcMDuIfNnA=; b=wS/fUgLMOM0hUxFdpc+FVPFCS59+PrccXw/h+y83JXAm68HTedjQfjVv4rLbVpdju2 tl8DYDi8F/QSzPeVxKlcgkPHYFu9aCCWUvKKvc2Rt7DS/7wAsDooGmSDCxUAU6MQJ0Uc lB3ErrTttmdL/Yi5jSJlUpuGDn2UtGDNouwF0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=HzXL8LLi2SZk9u+kLxtXpE7pVz1D6qQISUlXrVo790CBGtpDDt9A5WTDUJZWjp2rxH nCpt39eBvIXOQ7fZ8jZyLn93n67AS5yVJfwVzNvXUuKOUPWYXYpOtG7BMAiaEtV/tUH2 BFzyhvM47wHXyyfqm4/fpDPO56XKSrEn0GgT8= Received: by 10.100.171.10 with SMTP id t10mr1824729ane.53.1228780441497; Mon, 08 Dec 2008 15:54:01 -0800 (PST) Received: by 10.100.209.20 with HTTP; Mon, 8 Dec 2008 15:54:01 -0800 (PST) Message-ID: <539c60b90812081554u228dfc0eud2f03796a2208a32@mail.gmail.com> Date: Mon, 8 Dec 2008 16:54:01 -0700 From: "Steve Franks" To: "Gavin Atkinson" In-Reply-To: <1228766037.27498.6.camel@buffy.york.ac.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <490F47BE.9080205@janh.de> <20081104015235.GC98154@cdnetworks.co.kr> <4910C055.8000505@janh.de> <20081105013558.GA99795@cdnetworks.co.kr> <20081203090658.GJ9639@cdnetworks.co.kr> <37502393@bb.ipt.ru> <20081206023016.GF22093@cdnetworks.co.kr> <539c60b90812081127s4ffb509fnea9d44d4298da666@mail.gmail.com> <1228766037.27498.6.camel@buffy.york.ac.uk> X-Mailman-Approved-At: Tue, 09 Dec 2008 00:11:07 +0000 Cc: pyunyh@gmail.com, current-list freebsd Subject: Re: Call for testers: Atheros AR8121(L1E)/AR8113/AR8114(L2E) ethernet X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Dec 2008 23:54:02 -0000 > Firstly: The output of "pciconf -lcv" relating to the device in > question would be essential. [steve@dynstant ~/projects]$ sudo pciconf -lcv none1@pci0:2:0:0: class=0x020000 card=0x28001565 chip=0x20481969 rev=0xa0 hdr=0x00 vendor = 'Attansic (Now owned by Atheros)' device = 'L2 Fast Ethernet 10/100 Base-T Controller' class = network subclass = ethernet cap 01[40] = powerspec 2 supports D0 D3 current D0 cap 05[48] = MSI supports 1 message, 64 bit cap 10[58] = PCI-Express 1 endpoint Well, it seems someone is not telling the truth here! pciconf reports L2, whereas the manufacturer said L1E. Guess I got rev'd on. Thanks anyways, y'all. Steve From owner-freebsd-current@FreeBSD.ORG Tue Dec 9 00:17:57 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C0E0A1065675 for ; Tue, 9 Dec 2008 00:17:57 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.231]) by mx1.freebsd.org (Postfix) with ESMTP id 841238FC12 for ; Tue, 9 Dec 2008 00:17:57 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so1403559rvf.43 for ; Mon, 08 Dec 2008 16:17:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:received:date:from :to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=2ILeycwdS9hcoDwIZZ8gWUhVGrPfRe6EGUg3isiRPJo=; b=Kky5Zm8kcIcCqMaoms7RbYZ+k2WfpJRAhxrkDtd5dYnjjsk8DdflsyJyaSP1KtpOwf hW8DFC3pyTQwr1SD6j4GdDKdJXR+9yOjSTQhX7BksCXDrhD2HsU+3bjk5ln70ia2uhTH jvRpEdWIjAQM8g9B2hk5cn9W82wTHv0hyFjY8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=Ti0fjPdSX53f4KQ1gAZpf2kxRwv07MXzsOz/1S8hm9xcdXUI2fbPYCipdRcItrz4GK YKhbKZKOLzmDniPS5rqJ+FMgS6bVVNYA1PE0hd6O4xabNnWIeGFlFsZBhPXYruNUYzNM r9knxtdcWsg8bsGPXs0FwTr4nEeX8Ywrx6qH0= Received: by 10.141.194.6 with SMTP id w6mr1502224rvp.11.1228781877201; Mon, 08 Dec 2008 16:17:57 -0800 (PST) Received: from michelle.cdnetworks.co.kr ([211.53.35.84]) by mx.google.com with ESMTPS id g31sm27705735rvb.7.2008.12.08.16.17.54 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 08 Dec 2008 16:17:56 -0800 (PST) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id mB90HoHv033896 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 9 Dec 2008 09:17:50 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id mB90Hnr3033895; Tue, 9 Dec 2008 09:17:49 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Tue, 9 Dec 2008 09:17:49 +0900 From: Pyun YongHyeon To: Steve Franks Message-ID: <20081209001749.GA33723@cdnetworks.co.kr> References: <490F47BE.9080205@janh.de> <20081104015235.GC98154@cdnetworks.co.kr> <4910C055.8000505@janh.de> <20081105013558.GA99795@cdnetworks.co.kr> <20081203090658.GJ9639@cdnetworks.co.kr> <37502393@bb.ipt.ru> <20081206023016.GF22093@cdnetworks.co.kr> <539c60b90812081127s4ffb509fnea9d44d4298da666@mail.gmail.com> <1228766037.27498.6.camel@buffy.york.ac.uk> <539c60b90812081554u228dfc0eud2f03796a2208a32@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <539c60b90812081554u228dfc0eud2f03796a2208a32@mail.gmail.com> User-Agent: Mutt/1.4.2.1i Cc: current-list freebsd Subject: Re: Call for testers: Atheros AR8121(L1E)/AR8113/AR8114(L2E) ethernet X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Dec 2008 00:17:57 -0000 On Mon, Dec 08, 2008 at 04:54:01PM -0700, Steve Franks wrote: > > Firstly: The output of "pciconf -lcv" relating to the device in > > question would be essential. > > [steve@dynstant ~/projects]$ sudo pciconf -lcv > none1@pci0:2:0:0: class=0x020000 card=0x28001565 chip=0x20481969 > rev=0xa0 hdr=0x00 > vendor = 'Attansic (Now owned by Atheros)' > device = 'L2 Fast Ethernet 10/100 Base-T Controller' > class = network > subclass = ethernet > cap 01[40] = powerspec 2 supports D0 D3 current D0 > cap 05[48] = MSI supports 1 message, 64 bit > cap 10[58] = PCI-Express 1 endpoint > > Well, it seems someone is not telling the truth here! pciconf Yeah, you should use ae(4) for this controller. > reports L2, whereas the manufacturer said L1E. Guess I got rev'd on. > > Thanks anyways, y'all. > > Steve -- Regards, Pyun YongHyeon From owner-freebsd-current@FreeBSD.ORG Tue Dec 9 00:29:32 2008 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 59EA6106564A; Tue, 9 Dec 2008 00:29:32 +0000 (UTC) (envelope-from sobomax@FreeBSD.org) Received: from sippysoft.com (gk1.360sip.com [72.236.70.240]) by mx1.freebsd.org (Postfix) with ESMTP id 17DD78FC16; Tue, 9 Dec 2008 00:29:31 +0000 (UTC) (envelope-from sobomax@FreeBSD.org) Received: from [192.168.1.38] (S0106001372fd1e07.vs.shawcable.net [70.71.171.106]) (authenticated bits=0) by sippysoft.com (8.13.8/8.13.8) with ESMTP id mB90TTqG098401 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Dec 2008 16:29:30 -0800 (PST) (envelope-from sobomax@FreeBSD.org) Message-ID: <493DBBD0.5080705@FreeBSD.org> Date: Mon, 08 Dec 2008 16:29:04 -0800 From: Maxim Sobolev Organization: Sippy Software, Inc. User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Luigi Rizzo References: <493DA269.2070805@FreeBSD.org> <20081208235119.GA46608@onelab2.iet.unipi.it> In-Reply-To: <20081208235119.GA46608@onelab2.iet.unipi.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Luigi Rizzo , hackers@FreeBSD.org, "current@freebsd.org" Subject: Re: Enhancing cdboot [patch for review] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Dec 2008 00:29:32 -0000 Luigi Rizzo wrote: > On Mon, Dec 08, 2008 at 02:40:41PM -0800, Maxim Sobolev wrote: >> Hi, >> >> Below please find patch that enhances cdboot with two compile-time options: > ... >> Any comments/suggestions are appreciated. If there are no objections I >> would like to commit the change. The long-term goal is to make >> CDBOOT_PROMPT default mode for installation CD. >> >> http://sobomax.sippysoft.com/~sobomax/cdboot.diff > > Looks good. Some comments: Thank you for the review and comments. Please see my answers below. > 1. since there is plenty of space in the cdboot sector, why don't you > make the two option always compiled in, controlling which one to > activate through flags in the bootsector itself, to be set > patching the binary sector itself using a mechanism similar to > boot0cfg. > Of course you cannot alter a cdrom after you burn it, > but it makes it easier to build CDs with one or the other defaults, > patching cdboot or the iso image itself before creating/burning it. > > 2. in fact, the 'silent' option could be disabled at runtime by > pressing some key (e.g. adding a short wait loop before proceeding; > if this is meant for custom, unattended CDs the extra delay should not > matter much); Good idea, I will see if I can put that in. In fact this behavior should have to be optional as well, since one of the uses for the "silent" option here is to provide tamper-resistant boot process on custom hardware. > 3. one nitpick -- in one of the first chunks you replace $start > with $LOAD, but if i am not mistaken operation depends on $LOAD = $start, > so why don't you always use the same ? No, they are not the same. $LOAD is address where BIOS loads boot sector, which is 0x7c00 by default (you can configure it when building CD-ROM, which is why it's an option). On the other hand, $start is address where code is compiled to be located, which is 0x0600. > Also in terms of relocation size, wouldn't it be the case of > hardwiring the size of the cd boot sector: > > - mov $((end_init - start)/2),%cx > + mov 1024,%cx Well, I don't see the reason to hardwire this. CDROM boot code can be of different size (within certain limits of course, to be selected when building ISO), it's not limited to fixed number of sectors like boot[012]. > 4. another nitpick -- the value you pass in %si to the MBR does not > seem to point to anything useful. As discussed about boot0.S and > the followup in the mailing lists, there seems to be no standard > but at least some MBR expect %si to point to a partition entry, > so you should probably initialize one in a way similar way to that > used by boot0.S Hmm, maybe I misunderstood it then. What do you mean by "point to partition entry exactly"? Right now it points to the beginning on MBR. -Maxim From owner-freebsd-current@FreeBSD.ORG Tue Dec 9 00:38:25 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 66F0F1065673 for ; Tue, 9 Dec 2008 00:38:25 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) Received: from zivm-out2.uni-muenster.de (ZIVM-OUT2.UNI-MUENSTER.DE [128.176.192.9]) by mx1.freebsd.org (Postfix) with ESMTP id F06598FC12 for ; Tue, 9 Dec 2008 00:38:24 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) X-IronPort-AV: E=Sophos;i="4.33,737,1220220000"; d="scan'208";a="206839283" Received: from zivmaildisp1.uni-muenster.de (HELO ZIVMAILUSER05.UNI-MUENSTER.DE) ([128.176.188.85]) by zivm-relay2.uni-muenster.de with ESMTP; 09 Dec 2008 01:38:24 +0100 Received: by ZIVMAILUSER05.UNI-MUENSTER.DE (Postfix, from userid 149459) id 0A0B31B07DC; Tue, 9 Dec 2008 01:38:24 +0100 (CET) Date: Tue, 09 Dec 2008 01:38:23 +0100 (CET) From: Alexander Best Sender: Organization: Westfaelische Wilhelms-Universitaet Muenster To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: ath cannot connect using WEP X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Dec 2008 00:38:25 -0000 this issue got resolved in one of the recent changes to svn. cheers. From owner-freebsd-current@FreeBSD.ORG Tue Dec 9 01:10:28 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 677021065672 for ; Tue, 9 Dec 2008 01:10:28 +0000 (UTC) (envelope-from conrads@cox.net) Received: from eastrmmtao103.cox.net (eastrmmtao103.cox.net [68.230.240.9]) by mx1.freebsd.org (Postfix) with ESMTP id DB3718FC13 for ; Tue, 9 Dec 2008 01:10:27 +0000 (UTC) (envelope-from conrads@cox.net) Received: from eastrmimpo01.cox.net ([68.1.16.119]) by eastrmmtao103.cox.net (InterMail vM.7.08.02.01 201-2186-121-102-20070209) with ESMTP id <20081209011026.KMFO18445.eastrmmtao103.cox.net@eastrmimpo01.cox.net>; Mon, 8 Dec 2008 20:10:26 -0500 Received: from serene.no-ip.org ([72.200.37.152]) by eastrmimpo01.cox.net with bizsmtp id opAR1a00H3Gxf8w02pARL6; Mon, 08 Dec 2008 20:10:26 -0500 X-Authority-Analysis: v=1.0 c=1 a=IAqBdRI-3KdHPZVhdOYA:9 a=0uwUK6ScZQ27-NM2DwcA:7 a=VNFDZQIS4AtWirZtkxYrhy2W8AgA:4 a=4vB-4DCPJfMA:10 a=LY0hPdMaydYA:10 a=QQ9Yaq4P0pC5SJBSBEwA:9 a=fjeiG0cGWUbPtD14rJIA:7 a=qlCH0KtIaV4MnaWxsFoGkXwbjUgA:4 a=PkWtS5Fzv2AA:10 a=e0fhMjvlNPMA:10 a=SUykI3mC9HhGrUzTZFIA:9 a=xGj1v9htaxV-cDgmxe463sFSOGQA:4 a=1DF-ZbDQmksA:10 a=fHSw_kM11N8sB_3B2QsA:9 a=VYRKUy09zfS_gypF758A:7 a=fVGSuxGywcXCMKzKG5Ur3mx1OWwA:4 a=1QKrkg8EzhYA:10 X-CM-Score: 0.00 Date: Mon, 8 Dec 2008 19:10:31 -0600 From: "Conrad J. Sabatier" To: Gavin Atkinson Message-ID: <20081208191031.0e0699d8@serene.no-ip.org> In-Reply-To: <1228746983.27498.1.camel@buffy.york.ac.uk> References: <20081128234155.0221e263@serene.no-ip.org> <4930D7CE.4080909@psg.com> <20081202220643.72eb52a3@serene.no-ip.org> <20081203151537.GA1045@phenom.cordula.ws> <20081206190754.6c2bbd70@serene.no-ip.org> <1228746983.27498.1.camel@buffy.york.ac.uk> X-Mailer: Claws Mail 3.5.0 (GTK+ 2.14.4; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="MP_/uxkKrGOcbHvWrQ.4JxzZG1R" Cc: freebsd-current@freebsd.org, cpghost Subject: Re: i give up X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Dec 2008 01:10:28 -0000 --MP_/uxkKrGOcbHvWrQ.4JxzZG1R Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline On Mon, 08 Dec 2008 14:36:23 +0000 Gavin Atkinson wrote: > On Sat, 2008-12-06 at 19:07 -0600, Conrad J. Sabatier wrote: > > I'm continuing to hold out hope that I can provide the missing bits > > of the puzzle that will lead to a solution. But I've already > > passed along everything I could get from Windows Vista's System > > Information tool, Linux's lspci command, and FreeBSD's pciconf and > > dmesg. I don't know what more I can provide at this point. > > You could perhaps provide it again? I've still not seen it. > > > As another poster suggested, it's possible there's a bug/typo in the > > patches Soren sent me, although they all apply quite cleanly to > > every successive version of current I've tried them on. So...I'm > > at a loss at this point. It really is frustrating. > > > > I'm no fan of either Windows or Linux, but at least they do > > recognize my hardware. So I'm stuck for the time being. > > > > If anyone's interested, I'll repost or mail directly to them all the > > pertinent info I can gather. Just say the word and it shall be > > done. > > Please. > > Gavin Thank you for your interest. I'm currently running under Linux (Ubuntu) as I write this, so I've attached the output of Linux's dmesg as well as "lspci" using various options. I'll post later (I'm going out to a meeting shortly) from FreeBSD and provide the output from dmesg and pciconf (and anything else you may suggest). I no longer have Windows Vista installed at all, so I can't offer anything from that (not that it would probably be terribly useful anyway). :-) It's PCI device 00:9.0 that seems to be causing all the trouble, if that's anything of a timesaver for you. Thanks again very much. It really would be so great to find a resolution to this problem so I can go back to enjoying the full use of my machine under FreeBSD. -- Conrad J. Sabatier --MP_/uxkKrGOcbHvWrQ.4JxzZG1R Content-Type: application/octet-stream; name=linux.dmesg Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=linux.dmesg WyAgICAwLjAwMDAwMF0gSW5pdGlhbGl6aW5nIGNncm91cCBzdWJzeXMgY3B1c2V0ClsgICAgMC4w MDAwMDBdIEluaXRpYWxpemluZyBjZ3JvdXAgc3Vic3lzIGNwdQpbICAgIDAuMDAwMDAwXSBMaW51 eCB2ZXJzaW9uIDIuNi4yNy0xMC1nZW5lcmljIChidWlsZGRAY3Jlc3RlZCkgKGdjYyB2ZXJzaW9u IDQuMy4yIChVYnVudHUgNC4zLjItMXVidW50dTExKSApICMxIFNNUCBGcmkgTm92IDIxIDE5OjE5 OjE4IFVUQyAyMDA4IChVYnVudHUgMi42LjI3LTEwLjIwLWdlbmVyaWMpClsgICAgMC4wMDAwMDBd IENvbW1hbmQgbGluZTogcm9vdD1VVUlEPTllNzViMTc0LTY2NjUtNDA0NS1iYjkwLWQ1YTVmY2Vl NTAzMyBybyB2Z2E9Nzg5ClsgICAgMC4wMDAwMDBdIEtFUk5FTCBzdXBwb3J0ZWQgY3B1czoKWyAg ICAwLjAwMDAwMF0gICBJbnRlbCBHZW51aW5lSW50ZWwKWyAgICAwLjAwMDAwMF0gICBBTUQgQXV0 aGVudGljQU1EClsgICAgMC4wMDAwMDBdICAgQ2VudGF1ciBDZW50YXVySGF1bHMKWyAgICAwLjAw MDAwMF0gQklPUy1wcm92aWRlZCBwaHlzaWNhbCBSQU0gbWFwOgpbICAgIDAuMDAwMDAwXSAgQklP Uy1lODIwOiAwMDAwMDAwMDAwMDAwMDAwIC0gMDAwMDAwMDAwMDA5YTAwMCAodXNhYmxlKQpbICAg IDAuMDAwMDAwXSAgQklPUy1lODIwOiAwMDAwMDAwMDAwMDlhMDAwIC0gMDAwMDAwMDAwMDBhMDAw MCAocmVzZXJ2ZWQpClsgICAgMC4wMDAwMDBdICBCSU9TLWU4MjA6IDAwMDAwMDAwMDAwZTIwMDAg LSAwMDAwMDAwMDAwMTAwMDAwIChyZXNlcnZlZCkKWyAgICAwLjAwMDAwMF0gIEJJT1MtZTgyMDog MDAwMDAwMDAwMDEwMDAwMCAtIDAwMDAwMDAwZGZmYjAwMDAgKHVzYWJsZSkKWyAgICAwLjAwMDAw MF0gIEJJT1MtZTgyMDogMDAwMDAwMDBkZmZiMDAwMCAtIDAwMDAwMDAwZGZmYmUwMDAgKEFDUEkg ZGF0YSkKWyAgICAwLjAwMDAwMF0gIEJJT1MtZTgyMDogMDAwMDAwMDBkZmZiZTAwMCAtIDAwMDAw MDAwZTAwMDAwMDAgKEFDUEkgTlZTKQpbICAgIDAuMDAwMDAwXSAgQklPUy1lODIwOiAwMDAwMDAw MGZlYzAwMDAwIC0gMDAwMDAwMDBmZWMwMTAwMCAocmVzZXJ2ZWQpClsgICAgMC4wMDAwMDBdICBC SU9TLWU4MjA6IDAwMDAwMDAwZmVlMDAwMDAgLSAwMDAwMDAwMGZlZjAwMDAwIChyZXNlcnZlZCkK WyAgICAwLjAwMDAwMF0gIEJJT1MtZTgyMDogMDAwMDAwMDBmZjcwMDAwMCAtIDAwMDAwMDAxMDAw MDAwMDAgKHJlc2VydmVkKQpbICAgIDAuMDAwMDAwXSAgQklPUy1lODIwOiAwMDAwMDAwMTAwMDAw MDAwIC0gMDAwMDAwMDE2MDAwMDAwMCAodXNhYmxlKQpbICAgIDAuMDAwMDAwXSBETUkgcHJlc2Vu dC4KWyAgICAwLjAwMDAwMF0gQU1JIEJJT1MgZGV0ZWN0ZWQ6IEJJT1MgbWF5IGNvcnJ1cHQgbG93 IFJBTSwgd29ya2luZyBpdCBhcm91bmQuClsgICAgMC4wMDAwMDBdIGxhc3RfcGZuID0gMHgxNjAw MDAgbWF4X2FyY2hfcGZuID0gMHgzZmZmZmZmZmYKWyAgICAwLjAwMDAwMF0gbGFzdF9wZm4gPSAw eGRmZmIwIG1heF9hcmNoX3BmbiA9IDB4M2ZmZmZmZmZmClsgICAgMC4wMDAwMDBdIGluaXRfbWVt b3J5X21hcHBpbmcKWyAgICAwLjAwMDAwMF0gIDAwMDAwMDAwMDAgLSAwMGRmZTAwMDAwIHBhZ2Ug Mk0KWyAgICAwLjAwMDAwMF0gIDAwZGZlMDAwMDAgLSAwMGRmZmIwMDAwIHBhZ2UgNGsKWyAgICAw LjAwMDAwMF0ga2VybmVsIGRpcmVjdCBtYXBwaW5nIHRhYmxlcyB1cCB0byBkZmZiMDAwMCBAIDEw MDAwLTE2MDAwClsgICAgMC4wMDAwMDBdIGxhc3RfbWFwX2FkZHI6IGRmZmIwMDAwIGVuZDogZGZm YjAwMDAKWyAgICAwLjAwMDAwMF0gaW5pdF9tZW1vcnlfbWFwcGluZwpbICAgIDAuMDAwMDAwXSAg MDEwMDAwMDAwMCAtIDAxNjAwMDAwMDAgcGFnZSAyTQpbICAgIDAuMDAwMDAwXSBrZXJuZWwgZGly ZWN0IG1hcHBpbmcgdGFibGVzIHVwIHRvIDE2MDAwMDAwMCBAIDE0MDAwLTFiMDAwClsgICAgMC4w MDAwMDBdIGxhc3RfbWFwX2FkZHI6IDE2MDAwMDAwMCBlbmQ6IDE2MDAwMDAwMApbICAgIDAuMDAw MDAwXSBSQU1ESVNLOiAzNzdhNzAwMCAtIDM3ZmVmMGU0ClsgICAgMC4wMDAwMDBdIEFDUEk6IFJT RFAgMDAwRkM1NTAsIDAwMTQgKHIwIEhQUU9FTSkKWyAgICAwLjAwMDAwMF0gQUNQSTogUlNEVCBE RkZCMDAwMCwgMDA0OCAocjEgSFBRT0VNIFNMSUMtQ1BDIDIwMDgwNTA1IE1TRlQgICAgICAgOTcp ClsgICAgMC4wMDAwMDBdIEFDUEk6IEZBQ1AgREZGQjAyMDAsIDAwODQgKHIxIEhQUU9FTSBTTElD LUNQQyAyMDA4MDUwNSBNU0ZUICAgICAgIDk3KQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBEU0RUIERG RkIwNDUwLCA5MkVCIChyMSBIUFFPRU0gU0xJQy1DUEMgICAgICAgIDIgSU5UTCAyMDA1MTExNykK WyAgICAwLjAwMDAwMF0gQUNQSTogRkFDUyBERkZCRTAwMCwgMDA0MApbICAgIDAuMDAwMDAwXSBB Q1BJOiBBUElDIERGRkIwMzkwLCAwMDgwIChyMSBIUFFPRU0gU0xJQy1DUEMgMjAwODA1MDUgTVNG VCAgICAgICA5NykKWyAgICAwLjAwMDAwMF0gQUNQSTogTUNGRyBERkZCMDQxMCwgMDAzQyAocjEg SFBRT0VNIFNMSUMtQ1BDIDIwMDgwNTA1IE1TRlQgICAgICAgOTcpClsgICAgMC4wMDAwMDBdIEFD UEk6IE9FTUIgREZGQkUwNDAsIDAwNzMgKHIxIEhQUU9FTSBTTElDLUNQQyAyMDA4MDUwNSBNU0ZU ICAgICAgIDk3KQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBIUEVUIERGRkI5NzQwLCAwMDM4IChyMSBI UFFPRU0gU0xJQy1DUEMgMjAwODA1MDUgTVNGVCAgICAgICA5NykKWyAgICAwLjAwMDAwMF0gQUNQ STogSU5GTyBERkZCRTBDMCwgMDEyNCAocjEgMDUwNTA4IEFNRElORk8gIDIwMDgwNTA1IE1TRlQg ICAgICAgOTcpClsgICAgMC4wMDAwMDBdIEFDUEk6IE5WSEQgREZGQkUxRjAsIDA1NTQgKHIxIEhQ UU9FTSBTTElDLUNQQyAyMDA4MDUwNSBNU0ZUICAgICAgIDk3KQpbICAgIDAuMDAwMDAwXSBBQ1BJ OiBTTElDIERGRkJFNzUwLCAwMTc2IChyMSBIUFFPRU0gU0xJQy1DUEMgICAgICAgIDEgTVNGVCAg ICAgICAgMSkKWyAgICAwLjAwMDAwMF0gQUNQSTogU1NEVCBERkZCOTc4MCwgMDU0NCAocjEgSFBR T0VNIFNMSUMtQ1BDICAgICAgICAxIEFNRCAgICAgICAgIDEpClsgICAgMC4wMDAwMDBdIFNjYW5u aW5nIE5VTUEgdG9wb2xvZ3kgaW4gTm9ydGhicmlkZ2UgMjQKWyAgICAwLjAwMDAwMF0gTm8gTlVN QSBjb25maWd1cmF0aW9uIGZvdW5kClsgICAgMC4wMDAwMDBdIEZha2luZyBhIG5vZGUgYXQgMDAw MDAwMDAwMDAwMDAwMC0wMDAwMDAwMTYwMDAwMDAwClsgICAgMC4wMDAwMDBdIEJvb3RtZW0gc2V0 dXAgbm9kZSAwIDAwMDAwMDAwMDAwMDAwMDAtMDAwMDAwMDE2MDAwMDAwMApbICAgIDAuMDAwMDAw XSAgIE5PREVfREFUQSBbMDAwMDAwMDAwMDAxNjAwMCAtIDAwMDAwMDAwMDAwMWFmZmZdClsgICAg MC4wMDAwMDBdICAgYm9vdG1hcCBbMDAwMDAwMDAwMDAxYjAwMCAtICAwMDAwMDAwMDAwMDQ2ZmZm XSBwYWdlcyAyYwpbICAgIDAuMDAwMDAwXSAoNyBlYXJseSByZXNlcnZhdGlvbnMpID09PiBib290 bWVtIFswMDAwMDAwMDAwIC0gMDE2MDAwMDAwMF0KWyAgICAwLjAwMDAwMF0gICAjMCBbMDAwMDAw MDAwMCAtIDAwMDAwMDEwMDBdICAgQklPUyBkYXRhIHBhZ2UgPT0+IFswMDAwMDAwMDAwIC0gMDAw MDAwMTAwMF0KWyAgICAwLjAwMDAwMF0gICAjMSBbMDAwMDAwNjAwMCAtIDAwMDAwMDgwMDBdICAg ICAgIFRSQU1QT0xJTkUgPT0+IFswMDAwMDA2MDAwIC0gMDAwMDAwODAwMF0KWyAgICAwLjAwMDAw MF0gICAjMiBbMDAwMDIwMDAwMCAtIDAwMDA4YjlmNWNdICAgIFRFWFQgREFUQSBCU1MgPT0+IFsw MDAwMjAwMDAwIC0gMDAwMDhiOWY1Y10KWyAgICAwLjAwMDAwMF0gICAjMyBbMDAzNzdhNzAwMCAt IDAwMzdmZWYwZTRdICAgICAgICAgIFJBTURJU0sgPT0+IFswMDM3N2E3MDAwIC0gMDAzN2ZlZjBl NF0KWyAgICAwLjAwMDAwMF0gICAjNCBbMDAwMDA5YTAwMCAtIDAwMDAxMDAwMDBdICAgIEJJT1Mg cmVzZXJ2ZWQgPT0+IFswMDAwMDlhMDAwIC0gMDAwMDEwMDAwMF0KWyAgICAwLjAwMDAwMF0gICAj NSBbMDAwMDAxMDAwMCAtIDAwMDAwMTQwMDBdICAgICAgICAgIFBHVEFCTEUgPT0+IFswMDAwMDEw MDAwIC0gMDAwMDAxNDAwMF0KWyAgICAwLjAwMDAwMF0gICAjNiBbMDAwMDAxNDAwMCAtIDAwMDAw MTYwMDBdICAgICAgICAgIFBHVEFCTEUgPT0+IFswMDAwMDE0MDAwIC0gMDAwMDAxNjAwMF0KWyAg ICAwLjAwMDAwMF0gZm91bmQgU01QIE1QLXRhYmxlIGF0IFtmZmZmODgwMDAwMGZmNzgwXSAwMDBm Zjc4MApbICAgIDAuMDAwMDAwXSAgW2ZmZmZlMjAwMDAwMDAwMDAtZmZmZmUyMDAwNTdmZmZmZl0g UE1EIC0+IFtmZmZmODgwMDI4MjAwMDAwLWZmZmY4ODAwMmQxZmZmZmZdIG9uIG5vZGUgMApbICAg IDAuMDAwMDAwXSBab25lIFBGTiByYW5nZXM6ClsgICAgMC4wMDAwMDBdICAgRE1BICAgICAgMHgw MDAwMDAxMCAtPiAweDAwMDAxMDAwClsgICAgMC4wMDAwMDBdICAgRE1BMzIgICAgMHgwMDAwMTAw MCAtPiAweDAwMTAwMDAwClsgICAgMC4wMDAwMDBdICAgTm9ybWFsICAgMHgwMDEwMDAwMCAtPiAw eDAwMTYwMDAwClsgICAgMC4wMDAwMDBdIE1vdmFibGUgem9uZSBzdGFydCBQRk4gZm9yIGVhY2gg bm9kZQpbICAgIDAuMDAwMDAwXSBlYXJseV9ub2RlX21hcFszXSBhY3RpdmUgUEZOIHJhbmdlcwpb ICAgIDAuMDAwMDAwXSAgICAgMDogMHgwMDAwMDAxMCAtPiAweDAwMDAwMDlhClsgICAgMC4wMDAw MDBdICAgICAwOiAweDAwMDAwMTAwIC0+IDB4MDAwZGZmYjAKWyAgICAwLjAwMDAwMF0gICAgIDA6 IDB4MDAxMDAwMDAgLT4gMHgwMDE2MDAwMApbICAgIDAuMDAwMDAwXSBPbiBub2RlIDAgdG90YWxw YWdlczogMTMxMDUyMgpbICAgIDAuMDAwMDAwXSAgIERNQSB6b25lOiAyMDgwIHBhZ2VzLCBMSUZP IGJhdGNoOjAKWyAgICAwLjAwMDAwMF0gICBETUEzMiB6b25lOiA4OTcwMDggcGFnZXMsIExJRk8g YmF0Y2g6MzEKWyAgICAwLjAwMDAwMF0gICBOb3JtYWwgem9uZTogMzg3MDcyIHBhZ2VzLCBMSUZP IGJhdGNoOjMxClsgICAgMC4wMDAwMDBdIEFDUEk6IFBNLVRpbWVyIElPIFBvcnQ6IDB4MjAwOApb ICAgIDAuMDAwMDAwXSBBQ1BJOiBMb2NhbCBBUElDIGFkZHJlc3MgMHhmZWUwMDAwMApbICAgIDAu MDAwMDAwXSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDAxXSBsYXBpY19pZFsweDAwXSBlbmFibGVk KQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDAyXSBsYXBpY19pZFsweDAx XSBlbmFibGVkKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDAzXSBsYXBp Y19pZFsweDAyXSBlbmFibGVkKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsw eDA0XSBsYXBpY19pZFsweDAzXSBlbmFibGVkKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBJT0FQSUMg KGlkWzB4MDRdIGFkZHJlc3NbMHhmZWMwMDAwMF0gZ3NpX2Jhc2VbMF0pClsgICAgMC4wMDAwMDBd IElPQVBJQ1swXTogYXBpY19pZCA0LCB2ZXJzaW9uIDAsIGFkZHJlc3MgMHhmZWMwMDAwMCwgR1NJ IDAtMjMKWyAgICAwLjAwMDAwMF0gQUNQSTogSU5UX1NSQ19PVlIgKGJ1cyAwIGJ1c19pcnEgMCBn bG9iYWxfaXJxIDIgZGZsIGRmbCkKWyAgICAwLjAwMDAwMF0gQUNQSTogSU5UX1NSQ19PVlIgKGJ1 cyAwIGJ1c19pcnEgOSBnbG9iYWxfaXJxIDkgaGlnaCBsZXZlbCkKWyAgICAwLjAwMDAwMF0gQUNQ STogSU5UX1NSQ19PVlIgKGJ1cyAwIGJ1c19pcnEgMTQgZ2xvYmFsX2lycSAxNCBoaWdoIGVkZ2Up ClsgICAgMC4wMDAwMDBdIEFDUEk6IElOVF9TUkNfT1ZSIChidXMgMCBidXNfaXJxIDE1IGdsb2Jh bF9pcnEgMTUgaGlnaCBlZGdlKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBJUlEwIHVzZWQgYnkgb3Zl cnJpZGUuClsgICAgMC4wMDAwMDBdIEFDUEk6IElSUTIgdXNlZCBieSBvdmVycmlkZS4KWyAgICAw LjAwMDAwMF0gQUNQSTogSVJROSB1c2VkIGJ5IG92ZXJyaWRlLgpbICAgIDAuMDAwMDAwXSBBQ1BJ OiBJUlExNCB1c2VkIGJ5IG92ZXJyaWRlLgpbICAgIDAuMDAwMDAwXSBBQ1BJOiBJUlExNSB1c2Vk IGJ5IG92ZXJyaWRlLgpbICAgIDAuMDAwMDAwXSBTZXR0aW5nIEFQSUMgcm91dGluZyB0byBmbGF0 ClsgICAgMC4wMDAwMDBdIEFDUEk6IEhQRVQgaWQ6IDB4MTBkZTgyMDEgYmFzZTogMHhmZWQwMDAw MApbICAgIDAuMDAwMDAwXSBVc2luZyBBQ1BJIChNQURUKSBmb3IgU01QIGNvbmZpZ3VyYXRpb24g aW5mb3JtYXRpb24KWyAgICAwLjAwMDAwMF0gU01QOiBBbGxvd2luZyA0IENQVXMsIDAgaG90cGx1 ZyBDUFVzClsgICAgMC4wMDAwMDBdIFBNOiBSZWdpc3RlcmVkIG5vc2F2ZSBtZW1vcnk6IDAwMDAw MDAwMDAwOWEwMDAgLSAwMDAwMDAwMDAwMGEwMDAwClsgICAgMC4wMDAwMDBdIFBNOiBSZWdpc3Rl cmVkIG5vc2F2ZSBtZW1vcnk6IDAwMDAwMDAwMDAwYTAwMDAgLSAwMDAwMDAwMDAwMGUyMDAwClsg ICAgMC4wMDAwMDBdIFBNOiBSZWdpc3RlcmVkIG5vc2F2ZSBtZW1vcnk6IDAwMDAwMDAwMDAwZTIw MDAgLSAwMDAwMDAwMDAwMTAwMDAwClsgICAgMC4wMDAwMDBdIFBNOiBSZWdpc3RlcmVkIG5vc2F2 ZSBtZW1vcnk6IDAwMDAwMDAwZGZmYjAwMDAgLSAwMDAwMDAwMGRmZmJlMDAwClsgICAgMC4wMDAw MDBdIFBNOiBSZWdpc3RlcmVkIG5vc2F2ZSBtZW1vcnk6IDAwMDAwMDAwZGZmYmUwMDAgLSAwMDAw MDAwMGUwMDAwMDAwClsgICAgMC4wMDAwMDBdIFBNOiBSZWdpc3RlcmVkIG5vc2F2ZSBtZW1vcnk6 IDAwMDAwMDAwZTAwMDAwMDAgLSAwMDAwMDAwMGZlYzAwMDAwClsgICAgMC4wMDAwMDBdIFBNOiBS ZWdpc3RlcmVkIG5vc2F2ZSBtZW1vcnk6IDAwMDAwMDAwZmVjMDAwMDAgLSAwMDAwMDAwMGZlYzAx MDAwClsgICAgMC4wMDAwMDBdIFBNOiBSZWdpc3RlcmVkIG5vc2F2ZSBtZW1vcnk6IDAwMDAwMDAw ZmVjMDEwMDAgLSAwMDAwMDAwMGZlZTAwMDAwClsgICAgMC4wMDAwMDBdIFBNOiBSZWdpc3RlcmVk IG5vc2F2ZSBtZW1vcnk6IDAwMDAwMDAwZmVlMDAwMDAgLSAwMDAwMDAwMGZlZjAwMDAwClsgICAg MC4wMDAwMDBdIFBNOiBSZWdpc3RlcmVkIG5vc2F2ZSBtZW1vcnk6IDAwMDAwMDAwZmVmMDAwMDAg LSAwMDAwMDAwMGZmNzAwMDAwClsgICAgMC4wMDAwMDBdIFBNOiBSZWdpc3RlcmVkIG5vc2F2ZSBt ZW1vcnk6IDAwMDAwMDAwZmY3MDAwMDAgLSAwMDAwMDAwMTAwMDAwMDAwClsgICAgMC4wMDAwMDBd IEFsbG9jYXRpbmcgUENJIHJlc291cmNlcyBzdGFydGluZyBhdCBlMjAwMDAwMCAoZ2FwOiBlMDAw MDAwMDoxZWMwMDAwMCkKWyAgICAwLjAwMDAwMF0gUEVSQ1BVOiBBbGxvY2F0aW5nIDY0OTI4IGJ5 dGVzIG9mIHBlciBjcHUgZGF0YQpbICAgIDAuMDAwMDAwXSBOUl9DUFVTOiA2NCwgbnJfY3B1X2lk czogNCwgbnJfbm9kZV9pZHMgMQpbICAgIDAuMDAwMDAwXSBCdWlsdCAxIHpvbmVsaXN0cyBpbiBO b2RlIG9yZGVyLCBtb2JpbGl0eSBncm91cGluZyBvbi4gIFRvdGFsIHBhZ2VzOiAxMjg2MTYwClsg ICAgMC4wMDAwMDBdIFBvbGljeSB6b25lOiBOb3JtYWwKWyAgICAwLjAwMDAwMF0gS2VybmVsIGNv bW1hbmQgbGluZTogcm9vdD1VVUlEPTllNzViMTc0LTY2NjUtNDA0NS1iYjkwLWQ1YTVmY2VlNTAz MyBybyB2Z2E9Nzg5ClsgICAgMC4wMDAwMDBdIEluaXRpYWxpemluZyBDUFUjMApbICAgIDAuMDAw MDAwXSBQSUQgaGFzaCB0YWJsZSBlbnRyaWVzOiA0MDk2IChvcmRlcjogMTIsIDMyNzY4IGJ5dGVz KQpbICAgIDAuMDAwMDAwXSBUU0M6IFBJVCBjYWxpYnJhdGlvbiBjb25maXJtZWQgYnkgUE1USU1F Ui4KWyAgICAwLjAwMDAwMF0gVFNDOiB1c2luZyBQSVQgY2FsaWJyYXRpb24gdmFsdWUKWyAgICAw LjAwMDAwMF0gRGV0ZWN0ZWQgMjE5OS45MzMgTUh6IHByb2Nlc3Nvci4KWyAgICAwLjAwNDAwMF0g c3B1cmlvdXMgODI1OUEgaW50ZXJydXB0OiBJUlE3LgpbICAgIDAuMDA0MDAwXSBDb25zb2xlOiBj b2xvdXIgZHVtbXkgZGV2aWNlIDgweDI1ClsgICAgMC4wMDQwMDBdIGNvbnNvbGUgW3R0eTBdIGVu YWJsZWQKWyAgICAwLjAwNDAwMF0gQ2hlY2tpbmcgYXBlcnR1cmUuLi4KWyAgICAwLjAwNDAwMF0g Tm8gQUdQIGJyaWRnZSBmb3VuZApbICAgIDAuMDA0MDAwXSBOb2RlIDA6IGFwZXJ0dXJlIEAgMjAw MDAwMDAgc2l6ZSAzMiBNQgpbICAgIDAuMDA0MDAwXSBBcGVydHVyZSBwb2ludGluZyB0byBlODIw IFJBTS4gSWdub3JpbmcuClsgICAgMC4wMDQwMDBdIFlvdXIgQklPUyBkb2Vzbid0IGxlYXZlIGEg YXBlcnR1cmUgbWVtb3J5IGhvbGUKWyAgICAwLjAwNDAwMF0gUGxlYXNlIGVuYWJsZSB0aGUgSU9N TVUgb3B0aW9uIGluIHRoZSBCSU9TIHNldHVwClsgICAgMC4wMDQwMDBdIFRoaXMgY29zdHMgeW91 IDY0IE1CIG9mIFJBTQpbICAgIDAuMDA0MDAwXSBNYXBwaW5nIGFwZXJ0dXJlIG92ZXIgNjU1MzYg S0Igb2YgUkFNIEAgMjAwMDAwMDAKWyAgICAwLjAwNDAwMF0gUE06IFJlZ2lzdGVyZWQgbm9zYXZl IG1lbW9yeTogMDAwMDAwMDAyMDAwMDAwMCAtIDAwMDAwMDAwMjQwMDAwMDAKWyAgICAwLjAwNDAw MF0gTWVtb3J5OiA1MDc4NzIway81NzY3MTY4ayBhdmFpbGFibGUgKDMxMTRrIGtlcm5lbCBjb2Rl LCAxNjMzNjhrIHJlc2VydmVkLCAxNTczayBkYXRhLCA1NDBrIGluaXQpClsgICAgMC4wMDQwMDBd IENQQTogcGFnZSBwb29sIGluaXRpYWxpemVkIDEgb2YgMSBwYWdlcyBwcmVhbGxvY2F0ZWQKWyAg ICAwLjAwNDAwMF0gU0xVQjogR2Vuc2xhYnM9MTMsIEhXYWxpZ249NjQsIE9yZGVyPTAtMywgTWlu T2JqZWN0cz0wLCBDUFVzPTQsIE5vZGVzPTEKWyAgICAwLjAwNDAwMF0gaHBldCBjbG9ja2V2ZW50 IHJlZ2lzdGVyZWQKWyAgICAwLjAwNDAwMF0gQ2FsaWJyYXRpbmcgZGVsYXkgbG9vcCAoc2tpcHBl ZCksIHZhbHVlIGNhbGN1bGF0ZWQgdXNpbmcgdGltZXIgZnJlcXVlbmN5Li4gNDM5OS44NiBCb2dv TUlQUyAobHBqPTg3OTk3MjApClsgICAgMC4wMDQwMDBdIFNlY3VyaXR5IEZyYW1ld29yayBpbml0 aWFsaXplZApbICAgIDAuMDA0MDAwXSBTRUxpbnV4OiAgRGlzYWJsZWQgYXQgYm9vdC4KWyAgICAw LjAwNDAwMF0gQXBwQXJtb3I6IEFwcEFybW9yIGluaXRpYWxpemVkClsgICAgMC4wMDQwMDBdIERl bnRyeSBjYWNoZSBoYXNoIHRhYmxlIGVudHJpZXM6IDEwNDg1NzYgKG9yZGVyOiAxMSwgODM4ODYw OCBieXRlcykKWyAgICAwLjAwNDQ5MV0gSW5vZGUtY2FjaGUgaGFzaCB0YWJsZSBlbnRyaWVzOiA1 MjQyODggKG9yZGVyOiAxMCwgNDE5NDMwNCBieXRlcykKWyAgICAwLjAwNjMzNV0gTW91bnQtY2Fj aGUgaGFzaCB0YWJsZSBlbnRyaWVzOiAyNTYKWyAgICAwLjAwNjUwN10gSW5pdGlhbGl6aW5nIGNn cm91cCBzdWJzeXMgbnMKWyAgICAwLjAwNjUxM10gSW5pdGlhbGl6aW5nIGNncm91cCBzdWJzeXMg Y3B1YWNjdApbICAgIDAuMDA2NTE2XSBJbml0aWFsaXppbmcgY2dyb3VwIHN1YnN5cyBtZW1vcnkK WyAgICAwLjAwNjUzMV0gQ1BVOiBMMSBJIENhY2hlOiA2NEsgKDY0IGJ5dGVzL2xpbmUpLCBEIGNh Y2hlIDY0SyAoNjQgYnl0ZXMvbGluZSkKWyAgICAwLjAwNjUzNV0gQ1BVOiBMMiBDYWNoZTogNTEy SyAoNjQgYnl0ZXMvbGluZSkKWyAgICAwLjAwNjUzOF0gQ1BVIDAvMCAtPiBOb2RlIDAKWyAgICAw LjAwNjU0Ml0gdHNlZzogMDAwMDAwMDAwMApbICAgIDAuMDA2NTU1XSBDUFU6IFBoeXNpY2FsIFBy b2Nlc3NvciBJRDogMApbICAgIDAuMDA2NTU3XSBDUFU6IFByb2Nlc3NvciBDb3JlIElEOiAwClsg ICAgMC4wMDY1NjldIHVzaW5nIEMxRSBhd2FyZSBpZGxlIHJvdXRpbmUKWyAgICAwLjAwNzkxNl0g QUNQSTogQ29yZSByZXZpc2lvbiAyMDA4MDYwOQpbICAgIDAuMDExNDYyXSBBQ1BJOiBDaGVja2lu ZyBpbml0cmFtZnMgZm9yIGN1c3RvbSBEU0RUClsgICAgMC4zMTQ0OTJdIC4uVElNRVI6IHZlY3Rv cj0weDMwIGFwaWMxPTAgcGluMT0yIGFwaWMyPS0xIHBpbjI9LTEKWyAgICAwLjM1NDE5OV0gQ1BV MDogQU1EIFBoZW5vbSh0bSkgOTU1MCBRdWFkLUNvcmUgUHJvY2Vzc29yIHN0ZXBwaW5nIDAzClsg ICAgMC4zNTQyMDVdIFVzaW5nIGxvY2FsIEFQSUMgdGltZXIgaW50ZXJydXB0cy4KWyAgICAwLjM1 NjAyM10gQVBJQyB0aW1lciBjYWxpYnJhdGlvbiByZXN1bHQgMTI0OTk2MTQKWyAgICAwLjM1NjAy NV0gRGV0ZWN0ZWQgMTIuNDk5IE1IeiBBUElDIHRpbWVyLgpbICAgIDAuMzU2MTQ2XSBCb290aW5n IHByb2Nlc3NvciAxLzEgaXAgNjAwMApbICAgIDAuMDA0MDAwXSBJbml0aWFsaXppbmcgQ1BVIzEK WyAgICAwLjAwNDAwMF0gQ2FsaWJyYXRpbmcgZGVsYXkgdXNpbmcgdGltZXIgc3BlY2lmaWMgcm91 dGluZS4uIDQ0MDAuMTMgQm9nb01JUFMgKGxwaj04ODAwMjc1KQpbICAgIDAuMDA0MDAwXSBDUFU6 IEwxIEkgQ2FjaGU6IDY0SyAoNjQgYnl0ZXMvbGluZSksIEQgY2FjaGUgNjRLICg2NCBieXRlcy9s aW5lKQpbICAgIDAuMDA0MDAwXSBDUFU6IEwyIENhY2hlOiA1MTJLICg2NCBieXRlcy9saW5lKQpb ICAgIDAuMDA0MDAwXSBDUFUgMS8xIC0+IE5vZGUgMApbICAgIDAuMDA0MDAwXSBDUFU6IFBoeXNp Y2FsIFByb2Nlc3NvciBJRDogMApbICAgIDAuMDA0MDAwXSBDUFU6IFByb2Nlc3NvciBDb3JlIElE OiAxClsgICAgMC40NDQ0NDVdIENQVTE6IEFNRCBQaGVub20odG0pIDk1NTAgUXVhZC1Db3JlIFBy b2Nlc3NvciBzdGVwcGluZyAwMwpbICAgIDAuNDQ0NDcyXSBjaGVja2luZyBUU0Mgc3luY2hyb25p emF0aW9uIFtDUFUjMCAtPiBDUFUjMV06IHBhc3NlZC4KWyAgICAwLjQ0ODA1MV0gU3lzdGVtIGhh cyBBTUQgQzFFIGVuYWJsZWQKWyAgICAwLjQ0ODA2OF0gU3dpdGNoIHRvIGJyb2FkY2FzdCBtb2Rl IG9uIENQVTEKWyAgICAwLjQ0ODEwNV0gQm9vdGluZyBwcm9jZXNzb3IgMi8yIGlwIDYwMDAKWyAg ICAwLjAwNDAwMF0gSW5pdGlhbGl6aW5nIENQVSMyClsgICAgMC4wMDQwMDBdIENhbGlicmF0aW5n IGRlbGF5IHVzaW5nIHRpbWVyIHNwZWNpZmljIHJvdXRpbmUuLiA0NDAwLjA1IEJvZ29NSVBTIChs cGo9ODgwMDEwNykKWyAgICAwLjAwNDAwMF0gQ1BVOiBMMSBJIENhY2hlOiA2NEsgKDY0IGJ5dGVz L2xpbmUpLCBEIGNhY2hlIDY0SyAoNjQgYnl0ZXMvbGluZSkKWyAgICAwLjAwNDAwMF0gQ1BVOiBM MiBDYWNoZTogNTEySyAoNjQgYnl0ZXMvbGluZSkKWyAgICAwLjAwNDAwMF0gQ1BVIDIvMiAtPiBO b2RlIDAKWyAgICAwLjAwNDAwMF0gQ1BVOiBQaHlzaWNhbCBQcm9jZXNzb3IgSUQ6IDAKWyAgICAw LjAwNDAwMF0gQ1BVOiBQcm9jZXNzb3IgQ29yZSBJRDogMgpbICAgIDAuNTM2MzcxXSBDUFUyOiBB TUQgUGhlbm9tKHRtKSA5NTUwIFF1YWQtQ29yZSBQcm9jZXNzb3Igc3RlcHBpbmcgMDMKWyAgICAw LjUzNjM5M10gY2hlY2tpbmcgVFNDIHN5bmNocm9uaXphdGlvbiBbQ1BVIzAgLT4gQ1BVIzJdOiBw YXNzZWQuClsgICAgMC41NDAwNTddIFN3aXRjaCB0byBicm9hZGNhc3QgbW9kZSBvbiBDUFUyClsg ICAgMC41NDAxMTJdIEJvb3RpbmcgcHJvY2Vzc29yIDMvMyBpcCA2MDAwClsgICAgMC4wMDQwMDBd IEluaXRpYWxpemluZyBDUFUjMwpbICAgIDAuMDA0MDAwXSBDYWxpYnJhdGluZyBkZWxheSB1c2lu ZyB0aW1lciBzcGVjaWZpYyByb3V0aW5lLi4gNDQwMC4wOSBCb2dvTUlQUyAobHBqPTg4MDAxODYp ClsgICAgMC4wMDQwMDBdIENQVTogTDEgSSBDYWNoZTogNjRLICg2NCBieXRlcy9saW5lKSwgRCBj YWNoZSA2NEsgKDY0IGJ5dGVzL2xpbmUpClsgICAgMC4wMDQwMDBdIENQVTogTDIgQ2FjaGU6IDUx MksgKDY0IGJ5dGVzL2xpbmUpClsgICAgMC4wMDQwMDBdIENQVSAzLzMgLT4gTm9kZSAwClsgICAg MC4wMDQwMDBdIENQVTogUGh5c2ljYWwgUHJvY2Vzc29yIElEOiAwClsgICAgMC4wMDQwMDBdIENQ VTogUHJvY2Vzc29yIENvcmUgSUQ6IDMKWyAgICAwLjYyODM4OF0gQ1BVMzogQU1EIFBoZW5vbSh0 bSkgOTU1MCBRdWFkLUNvcmUgUHJvY2Vzc29yIHN0ZXBwaW5nIDAzClsgICAgMC42Mjg0MTRdIGNo ZWNraW5nIFRTQyBzeW5jaHJvbml6YXRpb24gW0NQVSMwIC0+IENQVSMzXTogcGFzc2VkLgpbICAg IDAuNjMyMDU1XSBCcm91Z2h0IHVwIDQgQ1BVcwpbICAgIDAuNjMyMDU5XSBUb3RhbCBvZiA0IHBy b2Nlc3NvcnMgYWN0aXZhdGVkICgxNzYwMC4xNCBCb2dvTUlQUykuClsgICAgMC42MzIwNTRdIFN3 aXRjaCB0byBicm9hZGNhc3QgbW9kZSBvbiBDUFUzClsgICAgMC42MzIxNDJdIENQVTAgYXR0YWNo aW5nIHNjaGVkLWRvbWFpbjoKWyAgICAwLjYzMjE0NV0gIGRvbWFpbiAwOiBzcGFuIDAtMyBsZXZl bCBDUFUKWyAgICAwLjYzMjE0N10gICBncm91cHM6IDAgMSAyIDMKWyAgICAwLjYzMjE1MV0gICBk b21haW4gMTogc3BhbiAwLTMgbGV2ZWwgTk9ERQpbICAgIDAuNjMyMTUzXSAgICBncm91cHM6IDAt MwpbICAgIDAuNjMyMTU3XSBDUFUxIGF0dGFjaGluZyBzY2hlZC1kb21haW46ClsgICAgMC42MzIx NThdICBkb21haW4gMDogc3BhbiAwLTMgbGV2ZWwgQ1BVClsgICAgMC42MzIxNjBdICAgZ3JvdXBz OiAxIDIgMyAwClsgICAgMC42MzIxNjNdICAgZG9tYWluIDE6IHNwYW4gMC0zIGxldmVsIE5PREUK WyAgICAwLjYzMjE2NF0gICAgZ3JvdXBzOiAwLTMKWyAgICAwLjYzMjE2N10gQ1BVMiBhdHRhY2hp bmcgc2NoZWQtZG9tYWluOgpbICAgIDAuNjMyMTY5XSAgZG9tYWluIDA6IHNwYW4gMC0zIGxldmVs IENQVQpbICAgIDAuNjMyMTcwXSAgIGdyb3VwczogMiAzIDAgMQpbICAgIDAuNjMyMTczXSAgIGRv bWFpbiAxOiBzcGFuIDAtMyBsZXZlbCBOT0RFClsgICAgMC42MzIxNzVdICAgIGdyb3VwczogMC0z ClsgICAgMC42MzIxNzddIENQVTMgYXR0YWNoaW5nIHNjaGVkLWRvbWFpbjoKWyAgICAwLjYzMjE3 OV0gIGRvbWFpbiAwOiBzcGFuIDAtMyBsZXZlbCBDUFUKWyAgICAwLjYzMjE4MF0gICBncm91cHM6 IDMgMCAxIDIKWyAgICAwLjYzMjE4M10gICBkb21haW4gMTogc3BhbiAwLTMgbGV2ZWwgTk9ERQpb ICAgIDAuNjMyMTg1XSAgICBncm91cHM6IDAtMwpbICAgIDAuNjMyMjkzXSBTd2l0Y2ggdG8gYnJv YWRjYXN0IG1vZGUgb24gQ1BVMApbICAgIDAuNjMyMjkzXSBuZXRfbmFtZXNwYWNlOiAxNTUyIGJ5 dGVzClsgICAgMC42MzIyOTNdIEJvb3RpbmcgcGFyYXZpcnR1YWxpemVkIGtlcm5lbCBvbiBiYXJl IGhhcmR3YXJlClsgICAgMC42MzIzMjldIFRpbWU6ICAxOjE3OjA4ICBEYXRlOiAxMi8wNy8wOApb ICAgIDAuNjMyMzYxXSBORVQ6IFJlZ2lzdGVyZWQgcHJvdG9jb2wgZmFtaWx5IDE2ClsgICAgMC42 MzIzODFdIG5vZGUgMCBsaW5rIDA6IGlvIHBvcnQgWzEwMDAsIGZmZmZmZl0KWyAgICAwLjYzMjM4 MV0gbm9kZSAwIGxpbmsgMDogaW8gcG9ydCBbMjAwMCwgMmZmZl0KWyAgICAwLjYzMjM4MV0gVE9N OiAwMDAwMDAwMGUwMDAwMDAwIGFrYSAzNTg0TQpbICAgIDAuNjMyMzgxXSBGYW0gMTBoIG1tY29u ZiBbZjAwMDAwMDAsIGYwMGZmZmZmXQpbICAgIDAuNjMyMzgxXSBub2RlIDAgbGluayAwOiBtbWlv IFtmMDAwMDAwMCwgZjNmZmZmZmZdID09PiBbZjAxMDAwMDAsIGYzZmZmZmZmXQpbICAgIDAuNjMy MzgxXSBub2RlIDAgbGluayAwOiBtbWlvIFthMDAwMCwgYmZmZmZdClsgICAgMC42MzIzODFdIG5v ZGUgMCBsaW5rIDA6IG1taW8gW2UwMDAwMDAwLCBmZTBiZmZmZl0gPT0+IFtlMDAwMDAwMCwgZWZm ZmZmZmZdIGFuZCBbZjAxMDAwMDAsIGZlMGJmZmZmXQpbICAgIDAuNjMyMzgxXSBUT00yOiAwMDAw MDAwMTYwMDAwMDAwIGFrYSA1NjMyTQpbICAgIDAuNjMyMzgxXSBidXM6IFswMCwwN10gb24gbm9k ZSAwIGxpbmsgMApbICAgIDAuNjMyMzgxXSBidXM6IDAwIGluZGV4IDAgaW8gcG9ydDogWzAsIGZm ZmZdClsgICAgMC42MzIzODFdIGJ1czogMDAgaW5kZXggMSBtbWlvOiBbZjAxMDAwMDAsIGZmZmZm ZmZmXQpbICAgIDAuNjMyMzgxXSBidXM6IDAwIGluZGV4IDIgbW1pbzogW2EwMDAwLCBiZmZmZl0K WyAgICAwLjYzMjM4MV0gYnVzOiAwMCBpbmRleCAzIG1taW86IFtlMDAwMDAwMCwgZWZmZmZmZmZd ClsgICAgMC42MzIzODFdIGJ1czogMDAgaW5kZXggNCBtbWlvOiBbMTYwMDAwMDAwLCBmY2ZmZmZm ZmZmXQpbICAgIDAuNjMyMzgxXSBBQ1BJOiBidXMgdHlwZSBwY2kgcmVnaXN0ZXJlZApbICAgIDAu NjMyMzgxXSBQQ0k6IE1DRkcgY29uZmlndXJhdGlvbiAwOiBiYXNlIGYwMDAwMDAwIHNlZ21lbnQg MCBidXNlcyAwIC0gNjMKWyAgICAwLjYzMjM4MV0gUENJOiBOb3QgdXNpbmcgTU1DT05GSUcuClsg ICAgMC42MzIzODFdIFBDSTogVXNpbmcgY29uZmlndXJhdGlvbiB0eXBlIDEgZm9yIGJhc2UgYWNj ZXNzClsgICAgMC42MzIzODFdIFBDSTogVXNpbmcgY29uZmlndXJhdGlvbiB0eXBlIDEgZm9yIGV4 dGVuZGVkIGFjY2VzcwpbICAgIDAuNjMzMDQ2XSBBQ1BJOiBFQzogTG9vayB1cCBFQyBpbiBEU0RU ClsgICAgMC42NTc2ODldIEFDUEk6IEludGVycHJldGVyIGVuYWJsZWQKWyAgICAwLjY1NzY5NV0g QUNQSTogKHN1cHBvcnRzIFMwIFMxIFMzIFM0IFM1KQpbICAgIDAuNjU3NzE0XSBBQ1BJOiBVc2lu ZyBJT0FQSUMgZm9yIGludGVycnVwdCByb3V0aW5nClsgICAgMC42NTc4MDhdIFBDSTogTUNGRyBj b25maWd1cmF0aW9uIDA6IGJhc2UgZjAwMDAwMDAgc2VnbWVudCAwIGJ1c2VzIDAgLSA2MwpbICAg IDAuNjY3MjEzXSBQQ0k6IE1DRkcgYXJlYSBhdCBmMDAwMDAwMCByZXNlcnZlZCBpbiBBQ1BJIG1v dGhlcmJvYXJkIHJlc291cmNlcwpbICAgIDAuNjcwNTI3XSBQQ0k6IFVzaW5nIE1NQ09ORklHIGF0 IGYwMDAwMDAwIC0gZjNmZmZmZmYKWyAgICAwLjY5MjM0NF0gQUNQSTogUENJIFJvb3QgQnJpZGdl IFtQQ0kwXSAoMDAwMDowMCkKWyAgICAwLjY5NjEwOV0gUENJOiAwMDAwOjAwOjAxLjAgcmVnIDEw IGlvIHBvcnQ6IFsyZjAwLCAyZmZmXQpbICAgIDAuNjk2MTQ4XSBQQ0k6IDAwMDA6MDA6MDEuMSBy ZWcgMTAgaW8gcG9ydDogWzI5MDAsIDI5M2ZdClsgICAgMC42OTYxNThdIFBDSTogMDAwMDowMDow MS4xIHJlZyAyMCBpbyBwb3J0OiBbMmQwMCwgMmQzZl0KWyAgICAwLjY5NjE2Ml0gUENJOiAwMDAw OjAwOjAxLjEgcmVnIDI0IGlvIHBvcnQ6IFsyZTAwLCAyZTNmXQpbICAgIDAuNjk2MTc3XSBwY2kg MDAwMDowMDowMS4xOiBQTUUjIHN1cHBvcnRlZCBmcm9tIEQzaG90IEQzY29sZApbICAgIDAuNjk2 MTg1XSBwY2kgMDAwMDowMDowMS4xOiBQTUUjIGRpc2FibGVkClsgICAgMC42OTYyMzZdIFBDSTog MDAwMDowMDowMS4zIHJlZyAxMCAzMmJpdCBtbWlvOiBbZjllODAwMDAsIGY5ZWZmZmZmXQpbICAg IDAuNjk2MzU0XSBQQ0k6IDAwMDA6MDA6MDIuMCByZWcgMTAgMzJiaXQgbW1pbzogW2Y5ZTdmMDAw LCBmOWU3ZmZmZl0KWyAgICAwLjY5NjM3NV0gcGNpIDAwMDA6MDA6MDIuMDogc3VwcG9ydHMgRDEK WyAgICAwLjY5NjM3Nl0gcGNpIDAwMDA6MDA6MDIuMDogc3VwcG9ydHMgRDIKWyAgICAwLjY5NjM3 OF0gcGNpIDAwMDA6MDA6MDIuMDogUE1FIyBzdXBwb3J0ZWQgZnJvbSBEMCBEMSBEMiBEM2hvdCBE M2NvbGQKWyAgICAwLjY5NjM4M10gcGNpIDAwMDA6MDA6MDIuMDogUE1FIyBkaXNhYmxlZApbICAg IDAuNjk2NDA2XSBQQ0k6IDAwMDA6MDA6MDIuMSByZWcgMTAgMzJiaXQgbW1pbzogW2Y5ZTdlYzAw LCBmOWU3ZWNmZl0KWyAgICAwLjY5NjQzMF0gcGNpIDAwMDA6MDA6MDIuMTogc3VwcG9ydHMgRDEK WyAgICAwLjY5NjQzMl0gcGNpIDAwMDA6MDA6MDIuMTogc3VwcG9ydHMgRDIKWyAgICAwLjY5NjQz M10gcGNpIDAwMDA6MDA6MDIuMTogUE1FIyBzdXBwb3J0ZWQgZnJvbSBEMCBEMSBEMiBEM2hvdCBE M2NvbGQKWyAgICAwLjY5NjQzOF0gcGNpIDAwMDA6MDA6MDIuMTogUE1FIyBkaXNhYmxlZApbICAg IDAuNjk2NDYwXSBQQ0k6IDAwMDA6MDA6MDQuMCByZWcgMTAgMzJiaXQgbW1pbzogW2Y5ZTdkMDAw LCBmOWU3ZGZmZl0KWyAgICAwLjY5NjQ4MV0gcGNpIDAwMDA6MDA6MDQuMDogc3VwcG9ydHMgRDEK WyAgICAwLjY5NjQ4Ml0gcGNpIDAwMDA6MDA6MDQuMDogc3VwcG9ydHMgRDIKWyAgICAwLjY5NjQ4 NF0gcGNpIDAwMDA6MDA6MDQuMDogUE1FIyBzdXBwb3J0ZWQgZnJvbSBEMCBEMSBEMiBEM2hvdCBE M2NvbGQKWyAgICAwLjY5NjQ4OV0gcGNpIDAwMDA6MDA6MDQuMDogUE1FIyBkaXNhYmxlZApbICAg IDAuNjk2NTA5XSBQQ0k6IDAwMDA6MDA6MDQuMSByZWcgMTAgMzJiaXQgbW1pbzogW2Y5ZTdlODAw LCBmOWU3ZThmZl0KWyAgICAwLjY5NjUzM10gcGNpIDAwMDA6MDA6MDQuMTogc3VwcG9ydHMgRDEK WyAgICAwLjY5NjUzNF0gcGNpIDAwMDA6MDA6MDQuMTogc3VwcG9ydHMgRDIKWyAgICAwLjY5NjUz Nl0gcGNpIDAwMDA6MDA6MDQuMTogUE1FIyBzdXBwb3J0ZWQgZnJvbSBEMCBEMSBEMiBEM2hvdCBE M2NvbGQKWyAgICAwLjY5NjU0MV0gcGNpIDAwMDA6MDA6MDQuMTogUE1FIyBkaXNhYmxlZApbICAg IDAuNjk2NTcxXSBQQ0k6IDAwMDA6MDA6MDcuMCByZWcgMTAgMzJiaXQgbW1pbzogW2Y5ZTc4MDAw LCBmOWU3YmZmZl0KWyAgICAwLjY5NjU5NV0gcGNpIDAwMDA6MDA6MDcuMDogUE1FIyBzdXBwb3J0 ZWQgZnJvbSBEM2hvdCBEM2NvbGQKWyAgICAwLjY5NjU5OV0gcGNpIDAwMDA6MDA6MDcuMDogUE1F IyBkaXNhYmxlZApbICAgIDAuNjk2NjQ0XSBQQ0k6IDAwMDA6MDA6MDkuMCByZWcgMTAgaW8gcG9y dDogW2Q0ODAsIGQ0ODddClsgICAgMC42OTY2NDddIFBDSTogMDAwMDowMDowOS4wIHJlZyAxNCBp byBwb3J0OiBbZDQwMCwgZDQwM10KWyAgICAwLjY5NjY1MF0gUENJOiAwMDAwOjAwOjA5LjAgcmVn IDE4IGlvIHBvcnQ6IFtkMDgwLCBkMDg3XQpbICAgIDAuNjk2NjUzXSBQQ0k6IDAwMDA6MDA6MDku MCByZWcgMWMgaW8gcG9ydDogW2QwMDAsIGQwMDNdClsgICAgMC42OTY2NTZdIFBDSTogMDAwMDow MDowOS4wIHJlZyAyMCBpbyBwb3J0OiBbY2MwMCwgY2MwZl0KWyAgICAwLjY5NjY2MF0gUENJOiAw MDAwOjAwOjA5LjAgcmVnIDI0IDMyYml0IG1taW86IFtmOWU3NjAwMCwgZjllNzdmZmZdClsgICAg MC42OTY2ODldIFBDSTogMDAwMDowMDowYS4wIHJlZyAxMCAzMmJpdCBtbWlvOiBbZjllN2MwMDAs IGY5ZTdjZmZmXQpbICAgIDAuNjk2NjkzXSBQQ0k6IDAwMDA6MDA6MGEuMCByZWcgMTQgaW8gcG9y dDogW2M4ODAsIGM4ODddClsgICAgMC42OTY2OTZdIFBDSTogMDAwMDowMDowYS4wIHJlZyAxOCAz MmJpdCBtbWlvOiBbZjllN2U0MDAsIGY5ZTdlNGZmXQpbICAgIDAuNjk2Njk5XSBQQ0k6IDAwMDA6 MDA6MGEuMCByZWcgMWMgMzJiaXQgbW1pbzogW2Y5ZTdlMDAwLCBmOWU3ZTAwZl0KWyAgICAwLjY5 NjcxNV0gcGNpIDAwMDA6MDA6MGEuMDogc3VwcG9ydHMgRDEKWyAgICAwLjY5NjcxNl0gcGNpIDAw MDA6MDA6MGEuMDogc3VwcG9ydHMgRDIKWyAgICAwLjY5NjcxN10gcGNpIDAwMDA6MDA6MGEuMDog UE1FIyBzdXBwb3J0ZWQgZnJvbSBEMCBEMSBEMiBEM2hvdCBEM2NvbGQKWyAgICAwLjY5NjcyM10g cGNpIDAwMDA6MDA6MGEuMDogUE1FIyBkaXNhYmxlZApbICAgIDAuNjk2OTAwXSBwY2kgMDAwMDow MDoxMC4wOiBQTUUjIHN1cHBvcnRlZCBmcm9tIEQwIEQxIEQyIEQzaG90IEQzY29sZApbICAgIDAu Njk2OTA5XSBwY2kgMDAwMDowMDoxMC4wOiBQTUUjIGRpc2FibGVkClsgICAgMC42OTcwODJdIHBj aSAwMDAwOjAwOjEyLjA6IFBNRSMgc3VwcG9ydGVkIGZyb20gRDAgRDEgRDIgRDNob3QgRDNjb2xk ClsgICAgMC42OTcwOTFdIHBjaSAwMDAwOjAwOjEyLjA6IFBNRSMgZGlzYWJsZWQKWyAgICAwLjY5 NzI2OF0gcGNpIDAwMDA6MDA6MTMuMDogUE1FIyBzdXBwb3J0ZWQgZnJvbSBEMCBEMSBEMiBEM2hv dCBEM2NvbGQKWyAgICAwLjY5NzI4M10gcGNpIDAwMDA6MDA6MTMuMDogUE1FIyBkaXNhYmxlZApb ICAgIDAuNjk3NDU5XSBwY2kgMDAwMDowMDoxNC4wOiBQTUUjIHN1cHBvcnRlZCBmcm9tIEQwIEQx IEQyIEQzaG90IEQzY29sZApbICAgIDAuNjk3NDY4XSBwY2kgMDAwMDowMDoxNC4wOiBQTUUjIGRp c2FibGVkClsgICAgMC42OTc1NzRdIFBDSTogMDAwMDowMTowNS4wIHJlZyAxMCAzMmJpdCBtbWlv OiBbZjlmZmYwMDAsIGY5ZmZmZmZmXQpbICAgIDAuNjk3NjA0XSBwY2kgMDAwMDowMTowNS4wOiBz dXBwb3J0cyBEMQpbICAgIDAuNjk3NjA1XSBwY2kgMDAwMDowMTowNS4wOiBzdXBwb3J0cyBEMgpb ICAgIDAuNjk3NjA3XSBwY2kgMDAwMDowMTowNS4wOiBQTUUjIHN1cHBvcnRlZCBmcm9tIEQwIEQx IEQyIEQzaG90ClsgICAgMC42OTc2MTJdIHBjaSAwMDAwOjAxOjA1LjA6IFBNRSMgZGlzYWJsZWQK WyAgICAwLjY5NzYzOF0gcGNpIDAwMDA6MDA6MDguMDogdHJhbnNwYXJlbnQgYnJpZGdlClsgICAg MC42OTc2NDNdIFBDSTogYnJpZGdlIDAwMDA6MDA6MDguMCAzMmJpdCBtbWlvOiBbZjlmMDAwMDAs IGY5ZmZmZmZmXQpbICAgIDAuNjk3Njc0XSBQQ0k6IDAwMDA6MDI6MDAuMCByZWcgMTAgMzJiaXQg bW1pbzogW2ZkMDAwMDAwLCBmZGZmZmZmZl0KWyAgICAwLjY5NzY4MV0gUENJOiAwMDAwOjAyOjAw LjAgcmVnIDE0IDY0Yml0IG1taW86IFtlMDAwMDAwMCwgZWZmZmZmZmZdClsgICAgMC42OTc2ODhd IFBDSTogMDAwMDowMjowMC4wIHJlZyAxYyA2NGJpdCBtbWlvOiBbZmEwMDAwMDAsIGZiZmZmZmZm XQpbICAgIDAuNjk3NjkyXSBQQ0k6IDAwMDA6MDI6MDAuMCByZWcgMjQgaW8gcG9ydDogW2VjMDAs IGVjN2ZdClsgICAgMC42OTc2OTddIFBDSTogMDAwMDowMjowMC4wIHJlZyAzMCAzMmJpdCBtbWlv OiBbZmVhZTAwMDAsIGZlYWZmZmZmXQpbICAgIDAuNjk3NzQ4XSBQQ0k6IGJyaWRnZSAwMDAwOjAw OjEwLjAgaW8gcG9ydDogW2UwMDAsIGVmZmZdClsgICAgMC42OTc3NTVdIFBDSTogYnJpZGdlIDAw MDA6MDA6MTAuMCAzMmJpdCBtbWlvOiBbZmEwMDAwMDAsIGZlYWZmZmZmXQpbICAgIDAuNjk3NzY4 XSBQQ0k6IGJyaWRnZSAwMDAwOjAwOjEwLjAgNjRiaXQgbW1pbyBwcmVmOiBbZTAwMDAwMDAsIGVm ZmZmZmZmXQpbICAgIDAuNjk3ODc3XSBQQ0k6IDAwMDA6MDQ6MDAuMCByZWcgMTAgMzJiaXQgbW1p bzogW2ZlYmYwMDAwLCBmZWJmZmZmZl0KWyAgICAwLjY5NzkzNF0gcGNpIDAwMDA6MDQ6MDAuMDog c3VwcG9ydHMgRDEKWyAgICAwLjY5NzkzNl0gcGNpIDAwMDA6MDQ6MDAuMDogc3VwcG9ydHMgRDIK WyAgICAwLjY5NzkzN10gcGNpIDAwMDA6MDQ6MDAuMDogUE1FIyBzdXBwb3J0ZWQgZnJvbSBEMCBE MSBEMiBEM2hvdApbICAgIDAuNjk3OTQzXSBwY2kgMDAwMDowNDowMC4wOiBQTUUjIGRpc2FibGVk ClsgICAgMC42OTc5OTFdIFBDSTogYnJpZGdlIDAwMDA6MDA6MTMuMCAzMmJpdCBtbWlvOiBbZmVi MDAwMDAsIGZlYmZmZmZmXQpbICAgIDAuNjk4MTI3XSBBQ1BJOiBQQ0kgSW50ZXJydXB0IFJvdXRp bmcgVGFibGUgW1xfU0JfLlBDSTAuX1BSVF0KWyAgICAwLjY5ODY3N10gQUNQSTogUENJIEludGVy cnVwdCBSb3V0aW5nIFRhYmxlIFtcX1NCXy5QQ0kwLlAwUDEuX1BSVF0KWyAgICAwLjY5OTAyMl0g QUNQSTogUENJIEludGVycnVwdCBSb3V0aW5nIFRhYmxlIFtcX1NCXy5QQ0kwLk1YUjAuX1BSVF0K WyAgICAwLjY5OTIyN10gQUNQSTogUENJIEludGVycnVwdCBSb3V0aW5nIFRhYmxlIFtcX1NCXy5Q Q0kwLkJSMTIuX1BSVF0KWyAgICAwLjY5OTQyMV0gQUNQSTogUENJIEludGVycnVwdCBSb3V0aW5n IFRhYmxlIFtcX1NCXy5QQ0kwLkJSMTMuX1BSVF0KWyAgICAwLjY5OTYxOF0gQUNQSTogUENJIElu dGVycnVwdCBSb3V0aW5nIFRhYmxlIFtcX1NCXy5QQ0kwLkJSMTQuX1BSVF0KWyAgICAwLjcyOTI2 MV0gQUNQSTogUENJIEludGVycnVwdCBMaW5rIFtMTktBXSAoSVJRcyAxNiAxNyAxOCAxOSkgKjAs IGRpc2FibGVkLgpbICAgIDAuNzI5MjYxXSBBQ1BJOiBQQ0kgSW50ZXJydXB0IExpbmsgW0xOS0Jd IChJUlFzIDE2IDE3IDE4IDE5KSAqMCwgZGlzYWJsZWQuClsgICAgMC43MjkzMzVdIEFDUEk6IFBD SSBJbnRlcnJ1cHQgTGluayBbTE5LQ10gKElSUXMgMTYgMTcgMTggMTkpICowLCBkaXNhYmxlZC4K WyAgICAwLjcyOTc5MV0gQUNQSTogUENJIEludGVycnVwdCBMaW5rIFtMTktEXSAoSVJRcyAxNiAx NyAxOCAxOSkgKjE0ClsgICAgMC43MzAyNDhdIEFDUEk6IFBDSSBJbnRlcnJ1cHQgTGluayBbTE4w QV0gKElSUXMgMTYgMTcgMTggMTkpICoxMApbICAgIDAuNzMyMzY5XSBBQ1BJOiBQQ0kgSW50ZXJy dXB0IExpbmsgW0xOMEJdIChJUlFzIDE2IDE3IDE4IDE5KSAqMCwgZGlzYWJsZWQuClsgICAgMC43 MzI4MjBdIEFDUEk6IFBDSSBJbnRlcnJ1cHQgTGluayBbTE4wQ10gKElSUXMgMTYgMTcgMTggMTkp ICowLCBkaXNhYmxlZC4KWyAgICAwLjczMzI2Nl0gQUNQSTogUENJIEludGVycnVwdCBMaW5rIFtM TjBEXSAoSVJRcyAxNiAxNyAxOCAxOSkgKjAsIGRpc2FibGVkLgpbICAgIDAuNzMzNzE2XSBBQ1BJ OiBQQ0kgSW50ZXJydXB0IExpbmsgW0xOMUFdIChJUlFzIDE2IDE3IDE4IDE5KSAqMCwgZGlzYWJs ZWQuClsgICAgMC43MzQxNzFdIEFDUEk6IFBDSSBJbnRlcnJ1cHQgTGluayBbTE4xQl0gKElSUXMg MTYgMTcgMTggMTkpICowLCBkaXNhYmxlZC4KWyAgICAwLjczNDYyMV0gQUNQSTogUENJIEludGVy cnVwdCBMaW5rIFtMTjFDXSAoSVJRcyAxNiAxNyAxOCAxOSkgKjAsIGRpc2FibGVkLgpbICAgIDAu NzM1MDcyXSBBQ1BJOiBQQ0kgSW50ZXJydXB0IExpbmsgW0xOMURdIChJUlFzIDE2IDE3IDE4IDE5 KSAqMCwgZGlzYWJsZWQuClsgICAgMC43MzU1MjhdIEFDUEk6IFBDSSBJbnRlcnJ1cHQgTGluayBb TE4yQV0gKElSUXMgMTYgMTcgMTggMTkpICoxMQpbICAgIDAuNzM1OTgwXSBBQ1BJOiBQQ0kgSW50 ZXJydXB0IExpbmsgW0xOMkJdIChJUlFzIDE2IDE3IDE4IDE5KSAqMCwgZGlzYWJsZWQuClsgICAg MC43MzY0MjhdIEFDUEk6IFBDSSBJbnRlcnJ1cHQgTGluayBbTE4yQ10gKElSUXMgMTYgMTcgMTgg MTkpICowLCBkaXNhYmxlZC4KWyAgICAwLjczNjg4MF0gQUNQSTogUENJIEludGVycnVwdCBMaW5r IFtMTjJEXSAoSVJRcyAxNiAxNyAxOCAxOSkgKjAsIGRpc2FibGVkLgpbICAgIDAuNzM3MzM2XSBB Q1BJOiBQQ0kgSW50ZXJydXB0IExpbmsgW0xOM0FdIChJUlFzIDE2IDE3IDE4IDE5KSAqMTUKWyAg ICAwLjczNzc4N10gQUNQSTogUENJIEludGVycnVwdCBMaW5rIFtMTjNCXSAoSVJRcyAxNiAxNyAx OCAxOSkgKjAsIGRpc2FibGVkLgpbICAgIDAuNzM4MjQyXSBBQ1BJOiBQQ0kgSW50ZXJydXB0IExp bmsgW0xOM0NdIChJUlFzIDE2IDE3IDE4IDE5KSAqMCwgZGlzYWJsZWQuClsgICAgMC43Mzg2OTBd IEFDUEk6IFBDSSBJbnRlcnJ1cHQgTGluayBbTE4zRF0gKElSUXMgMTYgMTcgMTggMTkpICowLCBk aXNhYmxlZC4KWyAgICAwLjczOTE0OF0gQUNQSTogUENJIEludGVycnVwdCBMaW5rIFtMTjRBXSAo SVJRcyAxNiAxNyAxOCAxOSkgKjE0ClsgICAgMC43Mzk2MDRdIEFDUEk6IFBDSSBJbnRlcnJ1cHQg TGluayBbTE40Ql0gKElSUXMgMTYgMTcgMTggMTkpICowLCBkaXNhYmxlZC4KWyAgICAwLjc0MDA2 MV0gQUNQSTogUENJIEludGVycnVwdCBMaW5rIFtMTjRDXSAoSVJRcyAxNiAxNyAxOCAxOSkgKjAs IGRpc2FibGVkLgpbICAgIDAuNzQwNTE4XSBBQ1BJOiBQQ0kgSW50ZXJydXB0IExpbmsgW0xONERd IChJUlFzIDE2IDE3IDE4IDE5KSAqMCwgZGlzYWJsZWQuClsgICAgMC43NDA5NzBdIEFDUEk6IFBD SSBJbnRlcnJ1cHQgTGluayBbTE41QV0gKElSUXMgMTYgMTcgMTggMTkpICowLCBkaXNhYmxlZC4K WyAgICAwLjc0MTQyMl0gQUNQSTogUENJIEludGVycnVwdCBMaW5rIFtMTjVCXSAoSVJRcyAxNiAx NyAxOCAxOSkgKjAsIGRpc2FibGVkLgpbICAgIDAuNzQxODc4XSBBQ1BJOiBQQ0kgSW50ZXJydXB0 IExpbmsgW0xONUNdIChJUlFzIDE2IDE3IDE4IDE5KSAqMCwgZGlzYWJsZWQuClsgICAgMC43NDIz MzRdIEFDUEk6IFBDSSBJbnRlcnJ1cHQgTGluayBbTE41RF0gKElSUXMgMTYgMTcgMTggMTkpICow LCBkaXNhYmxlZC4KWyAgICAwLjc0Mjc4Nl0gQUNQSTogUENJIEludGVycnVwdCBMaW5rIFtMTjZB XSAoSVJRcyAxNiAxNyAxOCAxOSkgKjAsIGRpc2FibGVkLgpbICAgIDAuNzQzMjM5XSBBQ1BJOiBQ Q0kgSW50ZXJydXB0IExpbmsgW0xONkJdIChJUlFzIDE2IDE3IDE4IDE5KSAqMCwgZGlzYWJsZWQu ClsgICAgMC43NDM2OTVdIEFDUEk6IFBDSSBJbnRlcnJ1cHQgTGluayBbTE42Q10gKElSUXMgMTYg MTcgMTggMTkpICowLCBkaXNhYmxlZC4KWyAgICAwLjc0NDE2NV0gQUNQSTogUENJIEludGVycnVw dCBMaW5rIFtMTjZEXSAoSVJRcyAxNiAxNyAxOCAxOSkgKjAsIGRpc2FibGVkLgpbICAgIDAuNzQ0 NjE3XSBBQ1BJOiBQQ0kgSW50ZXJydXB0IExpbmsgW0xON0FdIChJUlFzIDE2IDE3IDE4IDE5KSAq MCwgZGlzYWJsZWQuClsgICAgMC43NDUwNzNdIEFDUEk6IFBDSSBJbnRlcnJ1cHQgTGluayBbTE43 Ql0gKElSUXMgMTYgMTcgMTggMTkpICowLCBkaXNhYmxlZC4KWyAgICAwLjc0NTUyNF0gQUNQSTog UENJIEludGVycnVwdCBMaW5rIFtMTjdDXSAoSVJRcyAxNiAxNyAxOCAxOSkgKjAsIGRpc2FibGVk LgpbICAgIDAuNzQ1OTc2XSBBQ1BJOiBQQ0kgSW50ZXJydXB0IExpbmsgW0xON0RdIChJUlFzIDE2 IDE3IDE4IDE5KSAqMCwgZGlzYWJsZWQuClsgICAgMC43NDY0MzddIEFDUEk6IFBDSSBJbnRlcnJ1 cHQgTGluayBbTFVCMF0gKElSUXMgMjAgMjEgMjIgMjMpICoxMQpbICAgIDAuNzQ2ODk5XSBBQ1BJ OiBQQ0kgSW50ZXJydXB0IExpbmsgW0xVQjJdIChJUlFzIDIwIDIxIDIyIDIzKSAqMTUKWyAgICAw Ljc0NzM1NF0gQUNQSTogUENJIEludGVycnVwdCBMaW5rIFtMTUFDXSAoSVJRcyAyMCAyMSAyMiAy MykgKjE1ClsgICAgMC43NDc4MTBdIEFDUEk6IFBDSSBJbnRlcnJ1cHQgTGluayBbTEFaQV0gKElS UXMgMjAgMjEgMjIgMjMpICoxMQpbICAgIDAuNzQ4MjYyXSBBQ1BJOiBQQ0kgSW50ZXJydXB0IExp bmsgW1NHUlVdIChJUlFzIDIwIDIxIDIyIDIzKSAqMCwgZGlzYWJsZWQuClsgICAgMC43NDg3MjRd IEFDUEk6IFBDSSBJbnRlcnJ1cHQgTGluayBbTFNNQl0gKElSUXMgMjAgMjEgMjIgMjMpICo3Clsg ICAgMC43NDkxODBdIEFDUEk6IFBDSSBJbnRlcnJ1cHQgTGluayBbTFBNVV0gKElSUXMgMjAgMjEg MjIgMjMpICoxMApbICAgIDAuNzQ5NjQ1XSBBQ1BJOiBQQ0kgSW50ZXJydXB0IExpbmsgW0xTQTBd IChJUlFzIDIwIDIxIDIyIDIzKSAqNQpbICAgIDAuNzUwMTgzXSBBQ1BJOiBQQ0kgSW50ZXJydXB0 IExpbmsgW0xBVEFdIChJUlFzIDIwIDIxIDIyIDIzKSAqMCwgZGlzYWJsZWQuClsgICAgMC43NTA2 NDhdIEFDUEk6IFBDSSBJbnRlcnJ1cHQgTGluayBbVUIxMV0gKElSUXMgMjAgMjEgMjIgMjMpICox NApbICAgIDAuNzUxMTAzXSBBQ1BJOiBQQ0kgSW50ZXJydXB0IExpbmsgW1VCMTJdIChJUlFzIDIw IDIxIDIyIDIzKSAqMTAKWyAgICAwLjc1MTIwNF0gTGludXggUGx1ZyBhbmQgUGxheSBTdXBwb3J0 IHYwLjk3IChjKSBBZGFtIEJlbGF5ClsgICAgMC43NTEyMDRdIHBucDogUG5QIEFDUEkgaW5pdApb ICAgIDAuNzUxMjA0XSBBQ1BJOiBidXMgdHlwZSBwbnAgcmVnaXN0ZXJlZApbICAgIDAuNzYyMzE4 XSBwbnA6IFBuUCBBQ1BJOiBmb3VuZCAxMyBkZXZpY2VzClsgICAgMC43NjIzMjJdIEFDUEk6IEFD UEkgYnVzIHR5cGUgcG5wIHVucmVnaXN0ZXJlZApbICAgIDAuNzYyMzQwXSBQQ0k6IFVzaW5nIEFD UEkgZm9yIElSUSByb3V0aW5nClsgICAgMC43NzYwMzldIE5FVDogUmVnaXN0ZXJlZCBwcm90b2Nv bCBmYW1pbHkgOApbICAgIDAuNzc2MDQzXSBORVQ6IFJlZ2lzdGVyZWQgcHJvdG9jb2wgZmFtaWx5 IDIwClsgICAgMC43NzYwNTddIE5ldExhYmVsOiBJbml0aWFsaXppbmcKWyAgICAwLjc3NjA1N10g TmV0TGFiZWw6ICBkb21haW4gaGFzaCBzaXplID0gMTI4ClsgICAgMC43NzYwNTddIE5ldExhYmVs OiAgcHJvdG9jb2xzID0gVU5MQUJFTEVEIENJUFNPdjQKWyAgICAwLjc3NjA1N10gTmV0TGFiZWw6 ICB1bmxhYmVsZWQgdHJhZmZpYyBhbGxvd2VkIGJ5IGRlZmF1bHQKWyAgICAwLjc3NjI2OV0gUENJ LURNQTogRGlzYWJsaW5nIEFHUC4KWyAgICAwLjc3Njc1NF0gUENJLURNQTogYXBlcnR1cmUgYmFz ZSBAIDIwMDAwMDAwIHNpemUgNjU1MzYgS0IKWyAgICAwLjc3Njc1NF0gUENJLURNQTogdXNpbmcg R0FSVCBJT01NVS4KWyAgICAwLjc3Njc1NF0gUENJLURNQTogUmVzZXJ2aW5nIDY0TUIgb2YgSU9N TVUgYXJlYSBpbiB0aGUgQUdQIGFwZXJ0dXJlClsgICAgMC43Nzc4NTFdIGhwZXQwOiBhdCBNTUlP IDB4ZmVkMDAwMDAsIElSUXMgMiwgOCwgMzEKWyAgICAwLjc3Nzg2M10gaHBldDA6IDMgMzItYml0 IHRpbWVycywgMjUwMDAwMDAgSHoKWyAgICAwLjc4MDA1Ml0gU3dpdGNoZWQgdG8gaGlnaCByZXNv bHV0aW9uIG1vZGUgb24gQ1BVIDAKWyAgICAwLjc4MDA1OV0gU3dpdGNoZWQgdG8gaGlnaCByZXNv bHV0aW9uIG1vZGUgb24gQ1BVIDMKWyAgICAwLjc4MDA2MV0gU3dpdGNoZWQgdG8gaGlnaCByZXNv bHV0aW9uIG1vZGUgb24gQ1BVIDIKWyAgICAwLjc4MDA2NV0gU3dpdGNoZWQgdG8gaGlnaCByZXNv bHV0aW9uIG1vZGUgb24gQ1BVIDEKWyAgICAwLjc4MjgwNV0gdHJhY2VyOiAxMjg2IHBhZ2VzIGFs bG9jYXRlZCBmb3IgNjU1MzYgZW50cmllcyBvZiA4MCBieXRlcwpbICAgIDAuNzgyODA5XSAgICBh Y3R1YWwgZW50cmllcyA2NTU4NgpbICAgIDAuNzgyOTA2XSBBcHBBcm1vcjogQXBwQXJtb3IgRmls ZXN5c3RlbSBFbmFibGVkClsgICAgMC43ODI5MzddIEFDUEk6IFJUQyBjYW4gd2FrZSBmcm9tIFM0 ClsgICAgMC44MDAxMTFdIHN5c3RlbSAwMDowNDogaW9wb3J0IHJhbmdlIDB4NGQwLTB4NGQxIGhh cyBiZWVuIHJlc2VydmVkClsgICAgMC44MDAxMTVdIHN5c3RlbSAwMDowNDogaW9wb3J0IHJhbmdl IDB4ODAwLTB4ODBmIGhhcyBiZWVuIHJlc2VydmVkClsgICAgMC44MDAxMjBdIHN5c3RlbSAwMDow NDogaW9wb3J0IHJhbmdlIDB4MjAwMC0weDIwN2YgaGFzIGJlZW4gcmVzZXJ2ZWQKWyAgICAwLjgw MDEyNF0gc3lzdGVtIDAwOjA0OiBpb3BvcnQgcmFuZ2UgMHgyMDgwLTB4MjBmZiBoYXMgYmVlbiBy ZXNlcnZlZApbICAgIDAuODAwMTI3XSBzeXN0ZW0gMDA6MDQ6IGlvcG9ydCByYW5nZSAweDI0MDAt MHgyNDdmIGhhcyBiZWVuIHJlc2VydmVkClsgICAgMC44MDAxMzFdIHN5c3RlbSAwMDowNDogaW9w b3J0IHJhbmdlIDB4MjQ4MC0weDI0ZmYgaGFzIGJlZW4gcmVzZXJ2ZWQKWyAgICAwLjgwMDEzNV0g c3lzdGVtIDAwOjA0OiBpb3BvcnQgcmFuZ2UgMHgyODAwLTB4Mjg3ZiBoYXMgYmVlbiByZXNlcnZl ZApbICAgIDAuODAwMTM4XSBzeXN0ZW0gMDA6MDQ6IGlvcG9ydCByYW5nZSAweDI4ODAtMHgyOGZm IGhhcyBiZWVuIHJlc2VydmVkClsgICAgMC44MDAxNDRdIHN5c3RlbSAwMDowNDogaW9tZW0gcmFu Z2UgMHhmZWQwNDAwMC0weGZlZDA0ZmZmIGhhcyBiZWVuIHJlc2VydmVkClsgICAgMC44MDAxNDld IHN5c3RlbSAwMDowNDogaW9tZW0gcmFuZ2UgMHhmZWUwMTAwMC0weGZlZWZmZmZmIGNvdWxkIG5v dCBiZSByZXNlcnZlZApbICAgIDAuODAwMTU5XSBzeXN0ZW0gMDA6MDc6IGlvbWVtIHJhbmdlIDB4 ZmVjMDAwMDAtMHhmZWMwMGZmZiBjb3VsZCBub3QgYmUgcmVzZXJ2ZWQKWyAgICAwLjgwMDE2NF0g c3lzdGVtIDAwOjA3OiBpb21lbSByYW5nZSAweGZlZTAwMDAwLTB4ZmVlMDBmZmYgY291bGQgbm90 IGJlIHJlc2VydmVkClsgICAgMC44MDAxODFdIHN5c3RlbSAwMDowYTogaW9wb3J0IHJhbmdlIDB4 YTAwLTB4YWRmIGhhcyBiZWVuIHJlc2VydmVkClsgICAgMC44MDAxODddIHN5c3RlbSAwMDowYjog aW9tZW0gcmFuZ2UgMHhmMDAwMDAwMC0weGYzZmZmZmZmIGhhcyBiZWVuIHJlc2VydmVkClsgICAg MC44MDAxOTVdIHN5c3RlbSAwMDowYzogaW9tZW0gcmFuZ2UgMHgwLTB4OWZmZmYgY291bGQgbm90 IGJlIHJlc2VydmVkClsgICAgMC44MDAxOTldIHN5c3RlbSAwMDowYzogaW9tZW0gcmFuZ2UgMHhj MDAwMC0weGNmZmZmIGhhcyBiZWVuIHJlc2VydmVkClsgICAgMC44MDAyMDNdIHN5c3RlbSAwMDow YzogaW9tZW0gcmFuZ2UgMHhlMDAwMC0weGZmZmZmIGNvdWxkIG5vdCBiZSByZXNlcnZlZApbICAg IDAuODAwMjA3XSBzeXN0ZW0gMDA6MGM6IGlvbWVtIHJhbmdlIDB4MTAwMDAwLTB4ZGZmZmZmZmYg Y291bGQgbm90IGJlIHJlc2VydmVkClsgICAgMC44MDAyMTFdIHN5c3RlbSAwMDowYzogaW9tZW0g cmFuZ2UgMHhmZWMwMDAwMC0weGZmZmZmZmZmIGNvdWxkIG5vdCBiZSByZXNlcnZlZApbICAgIDAu ODA1MzgwXSBwY2kgMDAwMDowMDowOC4wOiBQQ0kgYnJpZGdlLCBzZWNvbmRhcnkgYnVzIDAwMDA6 MDEKWyAgICAwLjgwNTM4M10gcGNpIDAwMDA6MDA6MDguMDogICBJTyB3aW5kb3c6IGRpc2FibGVk ClsgICAgMC44MDUzODldIHBjaSAwMDAwOjAwOjA4LjA6ICAgTUVNIHdpbmRvdzogMHhmOWYwMDAw MC0weGY5ZmZmZmZmClsgICAgMC44MDUzOTNdIHBjaSAwMDAwOjAwOjA4LjA6ICAgUFJFRkVUQ0gg d2luZG93OiBkaXNhYmxlZApbICAgIDAuODA1Mzk5XSBwY2kgMDAwMDowMDoxMC4wOiBQQ0kgYnJp ZGdlLCBzZWNvbmRhcnkgYnVzIDAwMDA6MDIKWyAgICAwLjgwNTQwNV0gcGNpIDAwMDA6MDA6MTAu MDogICBJTyB3aW5kb3c6IDB4ZTAwMC0weGVmZmYKWyAgICAwLjgwNTQxNl0gcGNpIDAwMDA6MDA6 MTAuMDogICBNRU0gd2luZG93OiAweGZhMDAwMDAwLTB4ZmVhZmZmZmYKWyAgICAwLjgwNTQyNV0g cGNpIDAwMDA6MDA6MTAuMDogICBQUkVGRVRDSCB3aW5kb3c6IDB4MDAwMDAwZTAwMDAwMDAtMHgw MDAwMDBlZmZmZmZmZgpbICAgIDAuODA1NDM5XSBwY2kgMDAwMDowMDoxMi4wOiBQQ0kgYnJpZGdl LCBzZWNvbmRhcnkgYnVzIDAwMDA6MDMKWyAgICAwLjgwNTQ0M10gcGNpIDAwMDA6MDA6MTIuMDog ICBJTyB3aW5kb3c6IGRpc2FibGVkClsgICAgMC44MDU0NTNdIHBjaSAwMDAwOjAwOjEyLjA6ICAg TUVNIHdpbmRvdzogZGlzYWJsZWQKWyAgICAwLjgwNTQ2MV0gcGNpIDAwMDA6MDA6MTIuMDogICBQ UkVGRVRDSCB3aW5kb3c6IGRpc2FibGVkClsgICAgMC44MDU0NzRdIHBjaSAwMDAwOjAwOjEzLjA6 IFBDSSBicmlkZ2UsIHNlY29uZGFyeSBidXMgMDAwMDowNApbICAgIDAuODA1NDc3XSBwY2kgMDAw MDowMDoxMy4wOiAgIElPIHdpbmRvdzogZGlzYWJsZWQKWyAgICAwLjgwNTQ4OF0gcGNpIDAwMDA6 MDA6MTMuMDogICBNRU0gd2luZG93OiAweGZlYjAwMDAwLTB4ZmViZmZmZmYKWyAgICAwLjgwNTQ5 Nl0gcGNpIDAwMDA6MDA6MTMuMDogICBQUkVGRVRDSCB3aW5kb3c6IGRpc2FibGVkClsgICAgMC44 MDU1MTFdIHBjaSAwMDAwOjAwOjE0LjA6IFBDSSBicmlkZ2UsIHNlY29uZGFyeSBidXMgMDAwMDow NQpbICAgIDAuODA1NTE0XSBwY2kgMDAwMDowMDoxNC4wOiAgIElPIHdpbmRvdzogZGlzYWJsZWQK WyAgICAwLjgwNTUyNF0gcGNpIDAwMDA6MDA6MTQuMDogICBNRU0gd2luZG93OiBkaXNhYmxlZApb ICAgIDAuODA1NTMyXSBwY2kgMDAwMDowMDoxNC4wOiAgIFBSRUZFVENIIHdpbmRvdzogZGlzYWJs ZWQKWyAgICAwLjgwNTU1MV0gcGNpIDAwMDA6MDA6MDguMDogc2V0dGluZyBsYXRlbmN5IHRpbWVy IHRvIDY0ClsgICAgMC44MDYxNTZdIEFDUEk6IFBDSSBJbnRlcnJ1cHQgTGluayBbTE4wQV0gZW5h YmxlZCBhdCBJUlEgMTkKWyAgICAwLjgwNjE2OF0gcGNpIDAwMDA6MDA6MTAuMDogUENJIElOVCBB IC0+IExpbmtbTE4wQV0gLT4gR1NJIDE5IChsZXZlbCwgbG93KSAtPiBJUlEgMTkKWyAgICAwLjgw NjE3OF0gcGNpIDAwMDA6MDA6MTAuMDogc2V0dGluZyBsYXRlbmN5IHRpbWVyIHRvIDY0ClsgICAg MC44MDY3NDddIEFDUEk6IFBDSSBJbnRlcnJ1cHQgTGluayBbTE4yQV0gZW5hYmxlZCBhdCBJUlEg MTgKWyAgICAwLjgwNjc1N10gcGNpIDAwMDA6MDA6MTIuMDogUENJIElOVCBBIC0+IExpbmtbTE4y QV0gLT4gR1NJIDE4IChsZXZlbCwgbG93KSAtPiBJUlEgMTgKWyAgICAwLjgwNjc2N10gcGNpIDAw MDA6MDA6MTIuMDogc2V0dGluZyBsYXRlbmN5IHRpbWVyIHRvIDY0ClsgICAgMC44MDczMjddIEFD UEk6IFBDSSBJbnRlcnJ1cHQgTGluayBbTE4zQV0gZW5hYmxlZCBhdCBJUlEgMTcKWyAgICAwLjgw NzMzNV0gcGNpIDAwMDA6MDA6MTMuMDogUENJIElOVCBBIC0+IExpbmtbTE4zQV0gLT4gR1NJIDE3 IChsZXZlbCwgbG93KSAtPiBJUlEgMTcKWyAgICAwLjgwNzM0NV0gcGNpIDAwMDA6MDA6MTMuMDog c2V0dGluZyBsYXRlbmN5IHRpbWVyIHRvIDY0ClsgICAgMC44MDc5MDZdIEFDUEk6IFBDSSBJbnRl cnJ1cHQgTGluayBbTE40QV0gZW5hYmxlZCBhdCBJUlEgMTYKWyAgICAwLjgwNzkxNV0gcGNpIDAw MDA6MDA6MTQuMDogUENJIElOVCBBIC0+IExpbmtbTE40QV0gLT4gR1NJIDE2IChsZXZlbCwgbG93 KSAtPiBJUlEgMTYKWyAgICAwLjgwNzkyNV0gcGNpIDAwMDA6MDA6MTQuMDogc2V0dGluZyBsYXRl bmN5IHRpbWVyIHRvIDY0ClsgICAgMC44MDc5MzVdIGJ1czogMDAgaW5kZXggMCBpbyBwb3J0OiBb MCwgZmZmZl0KWyAgICAwLjgwNzkzOV0gYnVzOiAwMCBpbmRleCAxIG1taW86IFswLCBmZmZmZmZm ZmZmZmZmZmZmXQpbICAgIDAuODA3OTQyXSBidXM6IDAxIGluZGV4IDAgbW1pbzogWzAsIDBdClsg ICAgMC44MDc5NDRdIGJ1czogMDEgaW5kZXggMSBtbWlvOiBbZjlmMDAwMDAsIGY5ZmZmZmZmXQpb ICAgIDAuODA3OTQ3XSBidXM6IDAxIGluZGV4IDIgbW1pbzogWzAsIDBdClsgICAgMC44MDc5NTBd IGJ1czogMDEgaW5kZXggMyBpbyBwb3J0OiBbMCwgZmZmZl0KWyAgICAwLjgwNzk1Ml0gYnVzOiAw MSBpbmRleCA0IG1taW86IFswLCBmZmZmZmZmZmZmZmZmZmZmXQpbICAgIDAuODA3OTYxXSBidXM6 IDAyIGluZGV4IDAgaW8gcG9ydDogW2UwMDAsIGVmZmZdClsgICAgMC44MDc5NjNdIGJ1czogMDIg aW5kZXggMSBtbWlvOiBbZmEwMDAwMDAsIGZlYWZmZmZmXQpbICAgIDAuODA3OTY2XSBidXM6IDAy IGluZGV4IDIgbW1pbzogW2UwMDAwMDAwLCBlZmZmZmZmZl0KWyAgICAwLjgwNzk2OV0gYnVzOiAw MiBpbmRleCAzIG1taW86IFswLCAwXQpbICAgIDAuODA3OTcyXSBidXM6IDAzIGluZGV4IDAgbW1p bzogWzAsIDBdClsgICAgMC44MDc5NzRdIGJ1czogMDMgaW5kZXggMSBtbWlvOiBbMCwgMF0KWyAg ICAwLjgwNzk3N10gYnVzOiAwMyBpbmRleCAyIG1taW86IFswLCAwXQpbICAgIDAuODA3OTc5XSBi dXM6IDAzIGluZGV4IDMgbW1pbzogWzAsIDBdClsgICAgMC44MDc5ODJdIGJ1czogMDQgaW5kZXgg MCBtbWlvOiBbMCwgMF0KWyAgICAwLjgwNzk4NF0gYnVzOiAwNCBpbmRleCAxIG1taW86IFtmZWIw MDAwMCwgZmViZmZmZmZdClsgICAgMC44MDc5ODddIGJ1czogMDQgaW5kZXggMiBtbWlvOiBbMCwg MF0KWyAgICAwLjgwNzk4OV0gYnVzOiAwNCBpbmRleCAzIG1taW86IFswLCAwXQpbICAgIDAuODA3 OTkyXSBidXM6IDA1IGluZGV4IDAgbW1pbzogWzAsIDBdClsgICAgMC44MDc5OTVdIGJ1czogMDUg aW5kZXggMSBtbWlvOiBbMCwgMF0KWyAgICAwLjgwODAwNV0gYnVzOiAwNSBpbmRleCAyIG1taW86 IFswLCAwXQpbICAgIDAuODA4MDA3XSBidXM6IDA1IGluZGV4IDMgbW1pbzogWzAsIDBdClsgICAg MC44MDgwMjNdIE5FVDogUmVnaXN0ZXJlZCBwcm90b2NvbCBmYW1pbHkgMgpbICAgIDAuODQ4Mzk1 XSBJUCByb3V0ZSBjYWNoZSBoYXNoIHRhYmxlIGVudHJpZXM6IDI2MjE0NCAob3JkZXI6IDksIDIw OTcxNTIgYnl0ZXMpClsgICAgMC44NTAwOTBdIFRDUCBlc3RhYmxpc2hlZCBoYXNoIHRhYmxlIGVu dHJpZXM6IDUyNDI4OCAob3JkZXI6IDExLCA4Mzg4NjA4IGJ5dGVzKQpbICAgIDAuODUzOTM0XSBU Q1AgYmluZCBoYXNoIHRhYmxlIGVudHJpZXM6IDY1NTM2IChvcmRlcjogOCwgMTA0ODU3NiBieXRl cykKWyAgICAwLjg1NDQwN10gVENQOiBIYXNoIHRhYmxlcyBjb25maWd1cmVkIChlc3RhYmxpc2hl ZCA1MjQyODggYmluZCA2NTUzNikKWyAgICAwLjg1NDQxMl0gVENQIHJlbm8gcmVnaXN0ZXJlZApb ICAgIDAuODY0MTc2XSBORVQ6IFJlZ2lzdGVyZWQgcHJvdG9jb2wgZmFtaWx5IDEKWyAgICAwLjg2 NDI5M10gY2hlY2tpbmcgaWYgaW1hZ2UgaXMgaW5pdHJhbWZzLi4uIGl0IGlzClsgICAgMS40NzE3 NDZdIEZyZWVpbmcgaW5pdHJkIG1lbW9yeTogODQ4MGsgZnJlZWQKWyAgICAxLjQ3NjYxMF0gYXVk aXQ6IGluaXRpYWxpemluZyBuZXRsaW5rIHNvY2tldCAoZGlzYWJsZWQpClsgICAgMS40NzY2Mjdd IHR5cGU9MjAwMCBhdWRpdCgxMjI4NjEyNjI4LjQ3NjoxKTogaW5pdGlhbGl6ZWQKWyAgICAxLjQ4 MTg1Ml0gSHVnZVRMQiByZWdpc3RlcmVkIDIgTUIgcGFnZSBzaXplLCBwcmUtYWxsb2NhdGVkIDAg cGFnZXMKWyAgICAxLjQ4NDQ1MF0gVkZTOiBEaXNrIHF1b3RhcyBkcXVvdF82LjUuMQpbICAgIDEu NDg0NTM4XSBEcXVvdC1jYWNoZSBoYXNoIHRhYmxlIGVudHJpZXM6IDUxMiAob3JkZXIgMCwgNDA5 NiBieXRlcykKWyAgICAxLjQ4NDYzOV0gbXNnbW5pIGhhcyBiZWVuIHNldCB0byA5OTM1ClsgICAg MS40ODQ3NTldIGlvIHNjaGVkdWxlciBub29wIHJlZ2lzdGVyZWQKWyAgICAxLjQ4NDc2Ml0gaW8g c2NoZWR1bGVyIGFudGljaXBhdG9yeSByZWdpc3RlcmVkClsgICAgMS40ODQ3NjVdIGlvIHNjaGVk dWxlciBkZWFkbGluZSByZWdpc3RlcmVkClsgICAgMS40ODQ4ODhdIGlvIHNjaGVkdWxlciBjZnEg cmVnaXN0ZXJlZCAoZGVmYXVsdCkKWyAgICAxLjU1MjUzN10gcGNpIDAwMDA6MDA6MDcuMDogRW5h YmxpbmcgSFQgTVNJIE1hcHBpbmcKWyAgICAxLjU1MjU2OF0gcGNpIDAwMDA6MDA6MDguMDogRW5h YmxpbmcgSFQgTVNJIE1hcHBpbmcKWyAgICAxLjU1MjU5OV0gcGNpIDAwMDA6MDA6MDkuMDogRW5h YmxpbmcgSFQgTVNJIE1hcHBpbmcKWyAgICAxLjU1MjYzMV0gcGNpIDAwMDA6MDA6MGEuMDogRW5h YmxpbmcgSFQgTVNJIE1hcHBpbmcKWyAgICAxLjU1MjY5MF0gcGNpIDAwMDA6MDA6MTAuMDogRW5h YmxpbmcgSFQgTVNJIE1hcHBpbmcKWyAgICAxLjU1Mjc2NV0gcGNpIDAwMDA6MDA6MTIuMDogRW5h YmxpbmcgSFQgTVNJIE1hcHBpbmcKWyAgICAxLjU1MjgzM10gcGNpIDAwMDA6MDA6MTMuMDogRW5h YmxpbmcgSFQgTVNJIE1hcHBpbmcKWyAgICAxLjU1MjkwMl0gcGNpIDAwMDA6MDA6MTQuMDogRW5h YmxpbmcgSFQgTVNJIE1hcHBpbmcKWyAgICAxLjU1Mjk1NV0gcGNpIDAwMDA6MDI6MDAuMDogQm9v dCB2aWRlbyBkZXZpY2UKWyAgICAxLjU1MzA5OV0gcGNpZXBvcnQtZHJpdmVyIDAwMDA6MDA6MTAu MDogc2V0dGluZyBsYXRlbmN5IHRpbWVyIHRvIDY0ClsgICAgMS41NTMyNjldIHBjaWVwb3J0LWRy aXZlciAwMDAwOjAwOjEwLjA6IGZvdW5kIE1TSSBjYXBhYmlsaXR5ClsgICAgMS41NTMzODddIHBj aV9leHByZXNzIDAwMDA6MDA6MTAuMDpwY2llMDA6IGFsbG9jYXRlIHBvcnQgc2VydmljZQpbICAg IDEuNTUzNjQwXSBwY2llcG9ydC1kcml2ZXIgMDAwMDowMDoxMi4wOiBzZXR0aW5nIGxhdGVuY3kg dGltZXIgdG8gNjQKWyAgICAxLjU1MzgwOF0gcGNpZXBvcnQtZHJpdmVyIDAwMDA6MDA6MTIuMDog Zm91bmQgTVNJIGNhcGFiaWxpdHkKWyAgICAxLjU1MzkyMV0gcGNpX2V4cHJlc3MgMDAwMDowMDox Mi4wOnBjaWUwMDogYWxsb2NhdGUgcG9ydCBzZXJ2aWNlClsgICAgMS41NTQxNzBdIHBjaWVwb3J0 LWRyaXZlciAwMDAwOjAwOjEzLjA6IHNldHRpbmcgbGF0ZW5jeSB0aW1lciB0byA2NApbICAgIDEu NTU0MzM4XSBwY2llcG9ydC1kcml2ZXIgMDAwMDowMDoxMy4wOiBmb3VuZCBNU0kgY2FwYWJpbGl0 eQpbICAgIDEuNTU0NDU0XSBwY2lfZXhwcmVzcyAwMDAwOjAwOjEzLjA6cGNpZTAwOiBhbGxvY2F0 ZSBwb3J0IHNlcnZpY2UKWyAgICAxLjU1NDcwMl0gcGNpZXBvcnQtZHJpdmVyIDAwMDA6MDA6MTQu MDogc2V0dGluZyBsYXRlbmN5IHRpbWVyIHRvIDY0ClsgICAgMS41NTQ4NzBdIHBjaWVwb3J0LWRy aXZlciAwMDAwOjAwOjE0LjA6IGZvdW5kIE1TSSBjYXBhYmlsaXR5ClsgICAgMS41NTQ5ODNdIHBj aV9leHByZXNzIDAwMDA6MDA6MTQuMDpwY2llMDA6IGFsbG9jYXRlIHBvcnQgc2VydmljZQpbICAg IDEuNTkyNjEyXSBocGV0X3Jlc291cmNlczogMHhmZWQwMDAwMCBpcyBidXN5ClsgICAgMS41OTI3 MTddIExpbnV4IGFncGdhcnQgaW50ZXJmYWNlIHYwLjEwMwpbICAgIDEuNTkyNzI1XSBTZXJpYWw6 IDgyNTAvMTY1NTAgZHJpdmVyNCBwb3J0cywgSVJRIHNoYXJpbmcgZW5hYmxlZApbICAgIDEuNTk0 OTYyXSBicmQ6IG1vZHVsZSBsb2FkZWQKWyAgICAxLjU5NTA0MF0gaW5wdXQ6IE1hY2ludG9zaCBt b3VzZSBidXR0b24gZW11bGF0aW9uIGFzIC9kZXZpY2VzL3ZpcnR1YWwvaW5wdXQvaW5wdXQwClsg ICAgMS41OTUxNTddIFBOUDogUFMvMiBDb250cm9sbGVyIFtQTlAwMzAzOlBTMkssUE5QMGYxMzpQ UzJNXSBhdCAweDYwLDB4NjQgaXJxIDEsMTIKWyAgICAxLjU5NzY1N10gc2VyaW86IGk4MDQyIEtC RCBwb3J0IGF0IDB4NjAsMHg2NCBpcnEgMQpbICAgIDEuNTk3NjY4XSBzZXJpbzogaTgwNDIgQVVY IHBvcnQgYXQgMHg2MCwweDY0IGlycSAxMgpbICAgIDEuNjI5ODIzXSBtaWNlOiBQUy8yIG1vdXNl IGRldmljZSBjb21tb24gZm9yIGFsbCBtaWNlClsgICAgMS42Mjk5NzFdIHJ0Y19jbW9zIDAwOjA2 OiBydGMgY29yZTogcmVnaXN0ZXJlZCBydGNfY21vcyBhcyBydGMwClsgICAgMS42MzAwMzBdIHJ0 YzA6IGFsYXJtcyB1cCB0byBvbmUgeWVhciwgeTNrLCBocGV0IGlycXMKWyAgICAxLjYzMDA3Nl0g Y3B1aWRsZTogdXNpbmcgZ292ZXJub3IgbGFkZGVyClsgICAgMS42MzAwNzldIGNwdWlkbGU6IHVz aW5nIGdvdmVybm9yIG1lbnUKWyAgICAxLjYzMDQ1OF0gVENQIGN1YmljIHJlZ2lzdGVyZWQKWyAg ICAxLjYzMDY5NF0gcmVnaXN0ZXJlZCB0YXNrc3RhdHMgdmVyc2lvbiAxClsgICAgMS42MzA4NDhd ICAgTWFnaWMgbnVtYmVyOiA0OjM4NDoyNTUKWyAgICAxLjYzMDg4MF0gdHR5IHR0eXRlOiBoYXNo IG1hdGNoZXMKWyAgICAxLjYzMTAzOV0gcnRjX2Ntb3MgMDA6MDY6IHNldHRpbmcgc3lzdGVtIGNs b2NrIHRvIDIwMDgtMTItMDcgMDE6MTc6MDkgVVRDICgxMjI4NjEyNjI5KQpbICAgIDEuNjMxMDQ0 XSBCSU9TIEVERCBmYWNpbGl0eSB2MC4xNiAyMDA0LUp1bi0yNSwgMCBkZXZpY2VzIGZvdW5kClsg ICAgMS42MzEwNDddIEVERCBpbmZvcm1hdGlvbiBub3QgYXZhaWxhYmxlLgpbICAgIDEuNjMxMDg0 XSBGcmVlaW5nIHVudXNlZCBrZXJuZWwgbWVtb3J5OiA1NDBrIGZyZWVkClsgICAgMS42MzEyNzhd IFdyaXRlIHByb3RlY3RpbmcgdGhlIGtlcm5lbCByZWFkLW9ubHkgZGF0YTogNDM0OGsKWyAgICAx LjY0OTYwNl0gaW5wdXQ6IEFUIFRyYW5zbGF0ZWQgU2V0IDIga2V5Ym9hcmQgYXMgL2RldmljZXMv cGxhdGZvcm0vaTgwNDIvc2VyaW8wL2lucHV0L2lucHV0MQpbICAgIDEuNjg3MjA0XSB2ZXNhZmI6 IGZyYW1lYnVmZmVyIGF0IDB4ZmIwMDAwMDAsIG1hcHBlZCB0byAweGZmZmZjMjAwMDU4MDAwMDAs IHVzaW5nIDM3NTBrLCB0b3RhbCAxNDMzNmsKWyAgICAxLjY4NzIxNF0gdmVzYWZiOiBtb2RlIGlz IDgwMHg2MDB4MzIsIGxpbmVsZW5ndGg9MzIwMCwgcGFnZXM9MQpbICAgIDEuNjg3MjE4XSB2ZXNh ZmI6IHNjcm9sbGluZzogcmVkcmF3ClsgICAgMS42ODcyMjFdIHZlc2FmYjogVHJ1ZWNvbG9yOiBz aXplPTg6ODo4OjgsIHNoaWZ0PTI0OjE2Ojg6MApbICAgIDEuNjg3NDIwXSBDb25zb2xlOiBzd2l0 Y2hpbmcgdG8gY29sb3VyIGZyYW1lIGJ1ZmZlciBkZXZpY2UgMTAweDM3ClsgICAgMS42OTMyODJd IGZiMDogVkVTQSBWR0EgZnJhbWUgYnVmZmVyIGRldmljZQpbICAgIDEuNzU0NjY5XSBmdXNlIGlu aXQgKEFQSSB2ZXJzaW9uIDcuOSkKWyAgICAxLjc3MDY2OV0gcHJvY2Vzc29yIEFDUEkwMDA3OjAw OiByZWdpc3RlcmVkIGFzIGNvb2xpbmdfZGV2aWNlMApbICAgIDEuNzcwODQ2XSBwcm9jZXNzb3Ig QUNQSTAwMDc6MDE6IHJlZ2lzdGVyZWQgYXMgY29vbGluZ19kZXZpY2UxClsgICAgMS43NzEwMTdd IHByb2Nlc3NvciBBQ1BJMDAwNzowMjogcmVnaXN0ZXJlZCBhcyBjb29saW5nX2RldmljZTIKWyAg ICAxLjc3MTE4Nl0gcHJvY2Vzc29yIEFDUEkwMDA3OjAzOiByZWdpc3RlcmVkIGFzIGNvb2xpbmdf ZGV2aWNlMwpbICAgIDIuMDEyNTM3XSB1c2Jjb3JlOiByZWdpc3RlcmVkIG5ldyBpbnRlcmZhY2Ug ZHJpdmVyIHVzYmZzClsgICAgMi4wMTM3NDRdIHVzYmNvcmU6IHJlZ2lzdGVyZWQgbmV3IGludGVy ZmFjZSBkcml2ZXIgaHViClsgICAgMi4wMjExODZdIHVzYmNvcmU6IHJlZ2lzdGVyZWQgbmV3IGRl dmljZSBkcml2ZXIgdXNiClsgICAgMi4wMjI1NzldIE5vIGRvY2sgZGV2aWNlcyBmb3VuZC4KWyAg ICAyLjAyNDE4OV0gZm9yY2VkZXRoOiBSZXZlcnNlIEVuZ2luZWVyZWQgbkZvcmNlIGV0aGVybmV0 IGRyaXZlci4gVmVyc2lvbiAwLjYxLgpbICAgIDIuMDI2MzkzXSBBQ1BJOiBQQ0kgSW50ZXJydXB0 IExpbmsgW0xNQUNdIGVuYWJsZWQgYXQgSVJRIDIzClsgICAgMi4wMjc4NzNdIGZvcmNlZGV0aCAw MDAwOjAwOjBhLjA6IFBDSSBJTlQgQSAtPiBMaW5rW0xNQUNdIC0+IEdTSSAyMyAobGV2ZWwsIGxv dykgLT4gSVJRIDIzClsgICAgMi4wMjk1MDhdIGZvcmNlZGV0aCAwMDAwOjAwOjBhLjA6IHNldHRp bmcgbGF0ZW5jeSB0aW1lciB0byA2NApbICAgIDIuMDM2MDQ0XSBTQ1NJIHN1YnN5c3RlbSBpbml0 aWFsaXplZApbICAgIDIuMDQ0MDM3XSBvaGNpX2hjZDogMjAwNiBBdWd1c3QgMDQgVVNCIDEuMSAn T3BlbicgSG9zdCBDb250cm9sbGVyIChPSENJKSBEcml2ZXIKWyAgICAyLjA1NTk5OF0gbGliYXRh IHZlcnNpb24gMy4wMCBsb2FkZWQuClsgICAgMi4wNTc3MDRdIFdhcm5pbmchIGVoY2lfaGNkIHNo b3VsZCBhbHdheXMgYmUgbG9hZGVkIGJlZm9yZSB1aGNpX2hjZCBhbmQgb2hjaV9oY2QsIG5vdCBh ZnRlcgpbICAgIDIuNTQ4ODkwXSBmb3JjZWRldGggMDAwMDowMDowYS4wOiBpZm5hbWUgZXRoMCwg UEhZIE9VSSAweDczMiBAIDEsIGFkZHIgMDA6MWY6YzY6NzA6MWU6MWQKWyAgICAyLjU1MDg5Ml0g Zm9yY2VkZXRoIDAwMDA6MDA6MGEuMDogaGlnaGRtYSBjc3VtIHB3cmN0bCBtZ210IHRpbWlycSBn Yml0IGxua3RpbSBtc2kgZGVzYy12MwpbICAgIDIuNTUzNzg4XSBBQ1BJOiBQQ0kgSW50ZXJydXB0 IExpbmsgW0xVQjBdIGVuYWJsZWQgYXQgSVJRIDIyClsgICAgMi41NTU5NDhdIG9oY2lfaGNkIDAw MDA6MDA6MDIuMDogUENJIElOVCBBIC0+IExpbmtbTFVCMF0gLT4gR1NJIDIyIChsZXZlbCwgbG93 KSAtPiBJUlEgMjIKWyAgICAyLjU1ODI4Ml0gb2hjaV9oY2QgMDAwMDowMDowMi4wOiBzZXR0aW5n IGxhdGVuY3kgdGltZXIgdG8gNjQKWyAgICAyLjU1ODI4NV0gb2hjaV9oY2QgMDAwMDowMDowMi4w OiBPSENJIEhvc3QgQ29udHJvbGxlcgpbICAgIDIuNTYwNjY0XSBvaGNpX2hjZCAwMDAwOjAwOjAy LjA6IG5ldyBVU0IgYnVzIHJlZ2lzdGVyZWQsIGFzc2lnbmVkIGJ1cyBudW1iZXIgMQpbICAgIDIu NTYzMTQyXSBvaGNpX2hjZCAwMDAwOjAwOjAyLjA6IGlycSAyMiwgaW8gbWVtIDB4ZjllN2YwMDAK WyAgICAyLjYyMjIwMF0gdXNiIHVzYjE6IGNvbmZpZ3VyYXRpb24gIzEgY2hvc2VuIGZyb20gMSBj aG9pY2UKWyAgICAyLjYyNDc4N10gaHViIDEtMDoxLjA6IFVTQiBodWIgZm91bmQKWyAgICAyLjYy NzM5Nl0gaHViIDEtMDoxLjA6IDYgcG9ydHMgZGV0ZWN0ZWQKWyAgICAyLjgzNzAxNV0gQUNQSTog UENJIEludGVycnVwdCBMaW5rIFtMVUIyXSBlbmFibGVkIGF0IElSUSAyMQpbICAgIDIuODM5Nzc2 XSBlaGNpX2hjZCAwMDAwOjAwOjAyLjE6IFBDSSBJTlQgQiAtPiBMaW5rW0xVQjJdIC0+IEdTSSAy MSAobGV2ZWwsIGxvdykgLT4gSVJRIDIxClsgICAgMi44NDI2OTRdIGVoY2lfaGNkIDAwMDA6MDA6 MDIuMTogc2V0dGluZyBsYXRlbmN5IHRpbWVyIHRvIDY0ClsgICAgMi44NDI2OTddIGVoY2lfaGNk IDAwMDA6MDA6MDIuMTogRUhDSSBIb3N0IENvbnRyb2xsZXIKWyAgICAyLjg0NjAzM10gZWhjaV9o Y2QgMDAwMDowMDowMi4xOiBuZXcgVVNCIGJ1cyByZWdpc3RlcmVkLCBhc3NpZ25lZCBidXMgbnVt YmVyIDIKWyAgICAyLjg0ODkyNV0gZWhjaV9oY2QgMDAwMDowMDowMi4xOiBkZWJ1ZyBwb3J0IDEK WyAgICAyLjg1MTczMl0gZWhjaV9oY2QgMDAwMDowMDowMi4xOiBjYWNoZSBsaW5lIHNpemUgb2Yg NjQgaXMgbm90IHN1cHBvcnRlZApbICAgIDIuODUxNzQ5XSBlaGNpX2hjZCAwMDAwOjAwOjAyLjE6 IGlycSAyMSwgaW8gbWVtIDB4ZjllN2VjMDAKWyAgICAzLjAxMjA4M10gdXNiIDEtNDogbmV3IGZ1 bGwgc3BlZWQgVVNCIGRldmljZSB1c2luZyBvaGNpX2hjZCBhbmQgYWRkcmVzcyAyClsgICAgMy4w MjQzMDhdIGVoY2lfaGNkIDAwMDA6MDA6MDIuMTogVVNCIDIuMCBzdGFydGVkLCBFSENJIDEuMDAs IGRyaXZlciAxMCBEZWMgMjAwNApbICAgIDMuMDI3ODI0XSB1c2IgdXNiMjogY29uZmlndXJhdGlv biAjMSBjaG9zZW4gZnJvbSAxIGNob2ljZQpbICAgIDMuMDMxMzE0XSBodWIgMi0wOjEuMDogVVNC IGh1YiBmb3VuZApbICAgIDMuMDM0Mzg4XSBodWIgMi0wOjEuMDogNiBwb3J0cyBkZXRlY3RlZApb ICAgIDMuMDgwMDQzXSBodWIgMS0wOjEuMDogdW5hYmxlIHRvIGVudW1lcmF0ZSBVU0IgZGV2aWNl IG9uIHBvcnQgNApbICAgIDMuMjQ2MTQwXSBBQ1BJOiBQQ0kgSW50ZXJydXB0IExpbmsgW1VCMTFd IGVuYWJsZWQgYXQgSVJRIDIwClsgICAgMy4yNDkyMTRdIG9oY2lfaGNkIDAwMDA6MDA6MDQuMDog UENJIElOVCBBIC0+IExpbmtbVUIxMV0gLT4gR1NJIDIwIChsZXZlbCwgbG93KSAtPiBJUlEgMjAK WyAgICAzLjI1MjQwMF0gb2hjaV9oY2QgMDAwMDowMDowNC4wOiBzZXR0aW5nIGxhdGVuY3kgdGlt ZXIgdG8gNjQKWyAgICAzLjI1MjQwMl0gb2hjaV9oY2QgMDAwMDowMDowNC4wOiBPSENJIEhvc3Qg Q29udHJvbGxlcgpbICAgIDMuMjU1NTkzXSBvaGNpX2hjZCAwMDAwOjAwOjA0LjA6IG5ldyBVU0Ig YnVzIHJlZ2lzdGVyZWQsIGFzc2lnbmVkIGJ1cyBudW1iZXIgMwpbICAgIDMuMjU4ODI4XSBvaGNp X2hjZCAwMDAwOjAwOjA0LjA6IGlycSAyMCwgaW8gbWVtIDB4ZjllN2QwMDAKWyAgICAzLjMxODMz NF0gdXNiIHVzYjM6IGNvbmZpZ3VyYXRpb24gIzEgY2hvc2VuIGZyb20gMSBjaG9pY2UKWyAgICAz LjMyMTU0Ml0gaHViIDMtMDoxLjA6IFVTQiBodWIgZm91bmQKWyAgICAzLjMyNDc1Ml0gaHViIDMt MDoxLjA6IDYgcG9ydHMgZGV0ZWN0ZWQKWyAgICAzLjM1NjAyOF0gdXNiIDItNDogbmV3IGhpZ2gg c3BlZWQgVVNCIGRldmljZSB1c2luZyBlaGNpX2hjZCBhbmQgYWRkcmVzcyAyClsgICAgMy40OTEw MzBdIHVzYiAyLTQ6IGNvbmZpZ3VyYXRpb24gIzEgY2hvc2VuIGZyb20gMSBjaG9pY2UKWyAgICAz LjQ5NTA3MV0gaHViIDItNDoxLjA6IFVTQiBodWIgZm91bmQKWyAgICAzLjQ5ODU5OF0gaHViIDIt NDoxLjA6IDQgcG9ydHMgZGV0ZWN0ZWQKWyAgICAzLjUzNDgzN10gQUNQSTogUENJIEludGVycnVw dCBMaW5rIFtVQjEyXSBlbmFibGVkIGF0IElSUSAyMwpbICAgIDMuNTM3OTMzXSBlaGNpX2hjZCAw MDAwOjAwOjA0LjE6IFBDSSBJTlQgQiAtPiBMaW5rW1VCMTJdIC0+IEdTSSAyMyAobGV2ZWwsIGxv dykgLT4gSVJRIDIzClsgICAgMy41NDEwNjBdIGVoY2lfaGNkIDAwMDA6MDA6MDQuMTogc2V0dGlu ZyBsYXRlbmN5IHRpbWVyIHRvIDY0ClsgICAgMy41NDEwNjNdIGVoY2lfaGNkIDAwMDA6MDA6MDQu MTogRUhDSSBIb3N0IENvbnRyb2xsZXIKWyAgICAzLjU0NDExMF0gZWhjaV9oY2QgMDAwMDowMDow NC4xOiBuZXcgVVNCIGJ1cyByZWdpc3RlcmVkLCBhc3NpZ25lZCBidXMgbnVtYmVyIDQKWyAgICAz LjU0NzE2Nl0gZWhjaV9oY2QgMDAwMDowMDowNC4xOiBkZWJ1ZyBwb3J0IDEKWyAgICAzLjU1MDEw OF0gZWhjaV9oY2QgMDAwMDowMDowNC4xOiBjYWNoZSBsaW5lIHNpemUgb2YgNjQgaXMgbm90IHN1 cHBvcnRlZApbICAgIDMuNTUwMTI0XSBlaGNpX2hjZCAwMDAwOjAwOjA0LjE6IGlycSAyMywgaW8g bWVtIDB4ZjllN2U4MDAKWyAgICAzLjU2NDI4MV0gZWhjaV9oY2QgMDAwMDowMDowNC4xOiBVU0Ig Mi4wIHN0YXJ0ZWQsIEVIQ0kgMS4wMCwgZHJpdmVyIDEwIERlYyAyMDA0ClsgICAgMy41NjcyNjJd IHVzYiB1c2I0OiBjb25maWd1cmF0aW9uICMxIGNob3NlbiBmcm9tIDEgY2hvaWNlClsgICAgMy41 NzAxOTRdIGh1YiA0LTA6MS4wOiBVU0IgaHViIGZvdW5kClsgICAgMy41NzMwNzRdIGh1YiA0LTA6 MS4wOiA2IHBvcnRzIGRldGVjdGVkClsgICAgMy43ODE1NzddIGFoY2kgMDAwMDowMDowOS4wOiB2 ZXJzaW9uIDMuMApbICAgIDMuNzgyMTgwXSBBQ1BJOiBQQ0kgSW50ZXJydXB0IExpbmsgW0xTQTBd IGVuYWJsZWQgYXQgSVJRIDIyClsgICAgMy43ODUwNTZdIGFoY2kgMDAwMDowMDowOS4wOiBQQ0kg SU5UIEEgLT4gTGlua1tMU0EwXSAtPiBHU0kgMjIgKGxldmVsLCBsb3cpIC0+IElSUSAyMgpbICAg IDMuNzg4MTMzXSBhaGNpIDAwMDA6MDA6MDkuMDogQUhDSSAwMDAxLjAyMDAgMzIgc2xvdHMgNiBw b3J0cyAzIEdicHMgMHgzZiBpbXBsIFJBSUQgbW9kZQpbICAgIDMuNzkxMTMyXSBhaGNpIDAwMDA6 MDA6MDkuMDogZmxhZ3M6IDY0Yml0IG5jcSBzbnRmIGxlZCBjbG8gcG1wIHBpbyAKWyAgICAzLjc5 NDA3OF0gYWhjaSAwMDAwOjAwOjA5LjA6IHNldHRpbmcgbGF0ZW5jeSB0aW1lciB0byA2NApbICAg IDMuNzk0Mzk3XSBzY3NpMCA6IGFoY2kKWyAgICAzLjc5ODMxNF0gc2NzaTEgOiBhaGNpClsgICAg My44MDIxMTldIHNjc2kyIDogYWhjaQpbICAgIDMuODA1ODg0XSBzY3NpMyA6IGFoY2kKWyAgICAz LjgwOTYwN10gc2NzaTQgOiBhaGNpClsgICAgMy44MTMyNzRdIHNjc2k1IDogYWhjaQpbICAgIDMu ODE1ODk2XSBhdGExOiBTQVRBIG1heCBVRE1BLzEzMyBhYmFyIG04MTkyQDB4ZjllNzYwMDAgcG9y dCAweGY5ZTc2MTAwIGlycSAyMjk5ClsgICAgMy44MTg1MTFdIGF0YTI6IFNBVEEgbWF4IFVETUEv MTMzIGFiYXIgbTgxOTJAMHhmOWU3NjAwMCBwb3J0IDB4ZjllNzYxODAgaXJxIDIyOTkKWyAgICAz LjgyMTA1N10gYXRhMzogU0FUQSBtYXggVURNQS8xMzMgYWJhciBtODE5MkAweGY5ZTc2MDAwIHBv cnQgMHhmOWU3NjIwMCBpcnEgMjI5OQpbICAgIDMuODIzNTgzXSBhdGE0OiBTQVRBIG1heCBVRE1B LzEzMyBhYmFyIG04MTkyQDB4ZjllNzYwMDAgcG9ydCAweGY5ZTc2MjgwIGlycSAyMjk5ClsgICAg My44MjYwNjRdIGF0YTU6IFNBVEEgbWF4IFVETUEvMTMzIGFiYXIgbTgxOTJAMHhmOWU3NjAwMCBw b3J0IDB4ZjllNzYzMDAgaXJxIDIyOTkKWyAgICAzLjgyODQ2Nl0gYXRhNjogU0FUQSBtYXggVURN QS8xMzMgYWJhciBtODE5MkAweGY5ZTc2MDAwIHBvcnQgMHhmOWU3NjM4MCBpcnEgMjI5OQpbICAg IDMuOTA5MDM1XSB1c2IgMi00LjI6IG5ldyBoaWdoIHNwZWVkIFVTQiBkZXZpY2UgdXNpbmcgZWhj aV9oY2QgYW5kIGFkZHJlc3MgMwpbICAgIDQuMzEyMjIyXSBhdGExOiBTQVRBIGxpbmsgdXAgMy4w IEdicHMgKFNTdGF0dXMgMTIzIFNDb250cm9sIDMwMCkKWyAgICA0LjMxNTUzNV0gYXRhMS4wMDog QVRBLTc6IEhpdGFjaGkgSERTNzIxMDc1S0xBMzMwLCBHSzhPQTg3QSwgbWF4IFVETUEvMTMzClsg ICAgNC4zMTc5MTRdIGF0YTEuMDA6IDE0NjUxNDkxNjggc2VjdG9ycywgbXVsdGkgMTY6IExCQTQ4 IE5DUSAoZGVwdGggMzEvMzIpClsgICAgNC4zMjE2MDJdIGF0YTEuMDA6IGNvbmZpZ3VyZWQgZm9y IFVETUEvMTMzClsgICAgNC44NDQ2ODldIHVzYiAyLTQuMjogY29uZmlndXJhdGlvbiAjMSBjaG9z ZW4gZnJvbSAxIGNob2ljZQpbICAgIDQuOTYwMjk2XSB1c2IgNC0zOiBuZXcgaGlnaCBzcGVlZCBV U0IgZGV2aWNlIHVzaW5nIGVoY2lfaGNkIGFuZCBhZGRyZXNzIDIKWyAgICA1LjA5Njg2Ml0gdXNi IDQtMzogY29uZmlndXJhdGlvbiAjMSBjaG9zZW4gZnJvbSAxIGNob2ljZQpbICAgIDUuMjA4ODIz XSBhdGEyOiBTQVRBIGxpbmsgdXAgMS41IEdicHMgKFNTdGF0dXMgMTEzIFNDb250cm9sIDMwMCkK WyAgICA1LjIxMjU5OV0gYXRhMi4wMDogQVRBUEk6IFRTU1Rjb3JwIENERFZEVyBUUy1INjUzTiwg MDYwOSwgbWF4IFVETUEvMzMsIEFUQVBJIEFOClsgICAgNS4yMTY3OTNdIGF0YTIuMDA6IGNvbmZp Z3VyZWQgZm9yIFVETUEvMzMKWyAgICA1LjUzNjI4Ml0gYXRhMzogU0FUQSBsaW5rIGRvd24gKFNT dGF0dXMgMCBTQ29udHJvbCAzMDApClsgICAgNS44NTYxNzddIGF0YTQ6IFNBVEEgbGluayBkb3du IChTU3RhdHVzIDAgU0NvbnRyb2wgMzAwKQpbICAgIDYuMTc2MTAzXSBhdGE1OiBTQVRBIGxpbmsg ZG93biAoU1N0YXR1cyAwIFNDb250cm9sIDMwMCkKWyAgICA2LjQ5NjE1M10gYXRhNjogU0FUQSBs aW5rIGRvd24gKFNTdGF0dXMgMCBTQ29udHJvbCAzMDApClsgICAgNi40OTg1NDZdIHNjc2kgMDow OjA6MDogRGlyZWN0LUFjY2VzcyAgICAgQVRBICAgICAgSGl0YWNoaSBIRFM3MjEwNyBHSzhPIFBR OiAwIEFOU0k6IDUKWyAgICA2LjUwMzQxNl0gc2NzaSAxOjA6MDowOiBDRC1ST00gICAgICAgICAg ICBUU1NUY29ycCBDRERWRFcgVFMtSDY1M04gIDA2MDkgUFE6IDAgQU5TSTogNQpbICAgIDYuNTA4 Mjk1XSBBQ1BJOiBQQ0kgSW50ZXJydXB0IExpbmsgW0xOS0RdIGVuYWJsZWQgYXQgSVJRIDE5Clsg ICAgNi41MTA2NzddIG9oY2kxMzk0IDAwMDA6MDE6MDUuMDogUENJIElOVCBBIC0+IExpbmtbTE5L RF0gLT4gR1NJIDE5IChsZXZlbCwgbG93KSAtPiBJUlEgMTkKWyAgICA2LjU2NDkwM10gb2hjaTEz OTQ6IGZ3LWhvc3QwOiBPSENJLTEzOTQgMS4wIChQQ0kpOiBJUlE9WzE5XSAgTU1JTz1bZjlmZmYw MDAtZjlmZmY3ZmZdICBNYXggUGFja2V0PVsxMDI0XSAgSVIvSVQgY29udGV4dHM9WzgvOF0KWyAg ICA2LjU5NjAxM10gc2NzaSAwOjA6MDowOiBBdHRhY2hlZCBzY3NpIGdlbmVyaWMgc2cwIHR5cGUg MApbICAgIDYuNTk4NzUwXSBzY3NpIDE6MDowOjA6IEF0dGFjaGVkIHNjc2kgZ2VuZXJpYyBzZzEg dHlwZSA1ClsgICAgNi42MDE0OTVdIHVzYmNvcmU6IHJlZ2lzdGVyZWQgbmV3IGludGVyZmFjZSBk cml2ZXIgbGlidXN1YWwKWyAgICA2LjYwNjcyMV0gdXNiY29yZTogcmVnaXN0ZXJlZCBuZXcgaW50 ZXJmYWNlIGRyaXZlciBoaWRkZXYKWyAgICA2LjYxMDM0MV0gaGlkZGV2OTZoaWRyYXcwOiBVU0Ig SElEIHYxLjEwIERldmljZSBbV2VzdGVybiBEaWdpdGFsIEV4dGVybmFsIEhERF0gb24gdXNiLTAw MDA6MDA6MDIuMS00LjIKWyAgICA2LjYxNTg4NV0gdXNiY29yZTogcmVnaXN0ZXJlZCBuZXcgaW50 ZXJmYWNlIGRyaXZlciB1c2JoaWQKWyAgICA2LjYxODY3MF0gdXNiaGlkOiB2Mi42OlVTQiBISUQg Y29yZSBkcml2ZXIKWyAgICA2LjYyMTgxN10gSW5pdGlhbGl6aW5nIFVTQiBNYXNzIFN0b3JhZ2Ug ZHJpdmVyLi4uClsgICAgNi42MjQ4OTddIHNjc2k2IDogU0NTSSBlbXVsYXRpb24gZm9yIFVTQiBN YXNzIFN0b3JhZ2UgZGV2aWNlcwpbICAgIDYuNjI4MDI0XSB1c2Itc3RvcmFnZTogZGV2aWNlIGZv dW5kIGF0IDMKWyAgICA2LjYyODAyNl0gdXNiLXN0b3JhZ2U6IHdhaXRpbmcgZm9yIGRldmljZSB0 byBzZXR0bGUgYmVmb3JlIHNjYW5uaW5nClsgICAgNi42MjgwNjJdIHNjc2k3IDogU0NTSSBlbXVs YXRpb24gZm9yIFVTQiBNYXNzIFN0b3JhZ2UgZGV2aWNlcwpbICAgIDYuNjMzMTQ5XSB1c2Jjb3Jl OiByZWdpc3RlcmVkIG5ldyBpbnRlcmZhY2UgZHJpdmVyIHVzYi1zdG9yYWdlClsgICAgNi42MzYw ODldIHVzYi1zdG9yYWdlOiBkZXZpY2UgZm91bmQgYXQgMgpbICAgIDYuNjM2MDkwXSB1c2Itc3Rv cmFnZTogd2FpdGluZyBmb3IgZGV2aWNlIHRvIHNldHRsZSBiZWZvcmUgc2Nhbm5pbmcKWyAgICA2 LjYzNjA5M10gVVNCIE1hc3MgU3RvcmFnZSBzdXBwb3J0IHJlZ2lzdGVyZWQuClsgICAgNi42Mzkw OTBdIERyaXZlciAnc2QnIG5lZWRzIHVwZGF0aW5nIC0gcGxlYXNlIHVzZSBidXNfdHlwZSBtZXRo b2RzClsgICAgNi42NDI3NzVdIHNkIDA6MDowOjA6IFtzZGFdIDE0NjUxNDkxNjggNTEyLWJ5dGUg aGFyZHdhcmUgc2VjdG9ycyAoNzUwMTU2IE1CKQpbICAgIDYuNjQ2MDA2XSBzZCAwOjA6MDowOiBb c2RhXSBXcml0ZSBQcm90ZWN0IGlzIG9mZgpbICAgIDYuNjQ5MDkyXSBzZCAwOjA6MDowOiBbc2Rh XSBNb2RlIFNlbnNlOiAwMCAzYSAwMCAwMApbICAgIDYuNjQ5MTE2XSBzZCAwOjA6MDowOiBbc2Rh XSBXcml0ZSBjYWNoZTogZW5hYmxlZCwgcmVhZCBjYWNoZTogZW5hYmxlZCwgZG9lc24ndCBzdXBw b3J0IERQTyBvciBGVUEKWyAgICA2LjY1NTM1NV0gc2QgMDowOjA6MDogW3NkYV0gMTQ2NTE0OTE2 OCA1MTItYnl0ZSBoYXJkd2FyZSBzZWN0b3JzICg3NTAxNTYgTUIpClsgICAgNi42NTg1NTJdIHNk IDA6MDowOjA6IFtzZGFdIFdyaXRlIFByb3RlY3QgaXMgb2ZmClsgICAgNi42NjE2NzRdIHNkIDA6 MDowOjA6IFtzZGFdIE1vZGUgU2Vuc2U6IDAwIDNhIDAwIDAwClsgICAgNi42NjE2OTJdIHNkIDA6 MDowOjA6IFtzZGFdIFdyaXRlIGNhY2hlOiBlbmFibGVkLCByZWFkIGNhY2hlOiBlbmFibGVkLCBk b2Vzbid0IHN1cHBvcnQgRFBPIG9yIEZVQQpbICAgIDYuNjY4MDA0XSAgc2RhOjw0PkRyaXZlciAn c3InIG5lZWRzIHVwZGF0aW5nIC0gcGxlYXNlIHVzZSBidXNfdHlwZSBtZXRob2RzClsgICAgNi42 ODQxMzRdICBzZGExIHNkYTIgPCBzZGE1ID4KWyAgICA2LjcyMDI4Nl0gc2QgMDowOjA6MDogW3Nk YV0gQXR0YWNoZWQgU0NTSSBkaXNrClsgICAgNi43MjU0MjBdIHNyMDogc2NzaTMtbW1jIGRyaXZl OiA4eC80MHggd3JpdGVyIGR2ZC1yYW0gY2QvcncgeGEvZm9ybTIgY2RkYSB0cmF5ClsgICAgNi43 Mjg2ODRdIFVuaWZvcm0gQ0QtUk9NIGRyaXZlciBSZXZpc2lvbjogMy4yMApbICAgIDYuNzMxOTI4 XSBzciAxOjA6MDowOiBBdHRhY2hlZCBzY3NpIENELVJPTSBzcjAKWyAgICA2Ljk0MjQ4Nl0gUE06 IFN0YXJ0aW5nIG1hbnVhbCByZXN1bWUgZnJvbSBkaXNrClsgICAgNi45NDU4MDFdIFBNOiBSZXN1 bWUgZnJvbSBwYXJ0aXRpb24gODo1ClsgICAgNi45NDU4MDNdIFBNOiBDaGVja2luZyBoaWJlcm5h dGlvbiBpbWFnZS4KWyAgICA2Ljk0NjE3OV0gUE06IFJlc3VtZSBmcm9tIGRpc2sgZmFpbGVkLgpb ICAgIDcuMDIwMTMyXSBram91cm5hbGQgc3RhcnRpbmcuICBDb21taXQgaW50ZXJ2YWwgNSBzZWNv bmRzClsgICAgNy4wMjMzNTldIEVYVDMtZnM6IG1vdW50ZWQgZmlsZXN5c3RlbSB3aXRoIG9yZGVy ZWQgZGF0YSBtb2RlLgpbICAgIDcuODQ4NDEwXSBpZWVlMTM5NDogSG9zdCBhZGRlZDogSUQ6QlVT WzAtMDA6MTAyM10gIEdVSURbMDAxZThjMDAwMTMzOGU3Y10KWyAgIDExLjYyNDQ3MF0gdXNiLXN0 b3JhZ2U6IGRldmljZSBzY2FuIGNvbXBsZXRlClsgICAxMS42Mjc3MDRdIHNjc2kgNjowOjA6MDog RGlyZWN0LUFjY2VzcyAgICAgV0QgICAgICAgMzIwMEpCIEV4dGVybmFsICAwMTEyIFBROiAwIEFO U0k6IDAKWyAgIDExLjYzNDA2OV0gdXNiLXN0b3JhZ2U6IGRldmljZSBzY2FuIGNvbXBsZXRlClsg ICAxMS42MzU4MTFdIHNjc2kgNzowOjA6MDogRGlyZWN0LUFjY2VzcyAgICAgR2VuZXJpYyAgVVNC IFNEIFJlYWRlciAgICAxLjAwIFBROiAwIEFOU0k6IDAKWyAgIDExLjYzNTg3NF0gc2QgNjowOjA6 MDogW3NkYl0gNjI1MTQyNDQ4IDUxMi1ieXRlIGhhcmR3YXJlIHNlY3RvcnMgKDMyMDA3MyBNQikK WyAgIDExLjYzNzk5NV0gc2QgNjowOjA6MDogW3NkYl0gV3JpdGUgUHJvdGVjdCBpcyBvZmYKWyAg IDExLjYzNzk5N10gc2QgNjowOjA6MDogW3NkYl0gTW9kZSBTZW5zZTogMzMgMDAgMDAgMDAKWyAg IDExLjYzNzk5OV0gc2QgNjowOjA6MDogW3NkYl0gQXNzdW1pbmcgZHJpdmUgY2FjaGU6IHdyaXRl IHRocm91Z2gKWyAgIDExLjYzODYxOF0gc2QgNjowOjA6MDogW3NkYl0gNjI1MTQyNDQ4IDUxMi1i eXRlIGhhcmR3YXJlIHNlY3RvcnMgKDMyMDA3MyBNQikKWyAgIDExLjY0MDk5NV0gc2QgNjowOjA6 MDogW3NkYl0gV3JpdGUgUHJvdGVjdCBpcyBvZmYKWyAgIDExLjY0MDk5N10gc2QgNjowOjA6MDog W3NkYl0gTW9kZSBTZW5zZTogMzMgMDAgMDAgMDAKWyAgIDExLjY0MDk5OV0gc2QgNjowOjA6MDog W3NkYl0gQXNzdW1pbmcgZHJpdmUgY2FjaGU6IHdyaXRlIHRocm91Z2gKWyAgIDExLjY0MTAwMV0g IHNkYjogc2RiMQpbICAgMTEuNjYxODkxXSAgc2RiMTogPGJzZDogc2RiNSBzZGI2IHNkYjcgc2Ri OCBzZGI5ID4KWyAgIDExLjY2NDkzNV0gc2NzaSA3OjA6MDoxOiBEaXJlY3QtQWNjZXNzICAgICBH ZW5lcmljICBVU0IgQ0YgUmVhZGVyICAgIDEuMDEgUFE6IDAgQU5TSTogMApbICAgMTEuNjY4MDUw XSBzZCA2OjA6MDowOiBbc2RiXSBBdHRhY2hlZCBTQ1NJIGRpc2sKWyAgIDExLjY3MTE4NV0gc2Qg NjowOjA6MDogQXR0YWNoZWQgc2NzaSBnZW5lcmljIHNnMiB0eXBlIDAKWyAgIDExLjY3NDUyOF0g c2NzaSA3OjA6MDoyOiBEaXJlY3QtQWNjZXNzICAgICBHZW5lcmljICBVU0IgU00gUmVhZGVyICAg IDEuMDIgUFE6IDAgQU5TSTogMApbICAgMTEuNjc4NTM0XSBzY3NpIDc6MDowOjM6IERpcmVjdC1B Y2Nlc3MgICAgIEdlbmVyaWMgIFVTQiBNUyBSZWFkZXIgICAgMS4wMyBQUTogMCBBTlNJOiAwClsg ICAxMS42ODM0NDNdIHNkIDc6MDowOjA6IFtzZGNdIEF0dGFjaGVkIFNDU0kgcmVtb3ZhYmxlIGRp c2sKWyAgIDExLjY4NjQxNl0gc2QgNzowOjA6MDogQXR0YWNoZWQgc2NzaSBnZW5lcmljIHNnMyB0 eXBlIDAKWyAgIDExLjY5MTYwMV0gc2QgNzowOjA6MTogW3NkZF0gQXR0YWNoZWQgU0NTSSByZW1v dmFibGUgZGlzawpbICAgMTEuNjk0NDYxXSBzZCA3OjA6MDoxOiBBdHRhY2hlZCBzY3NpIGdlbmVy aWMgc2c0IHR5cGUgMApbICAgMTEuNjk5NTU0XSBzZCA3OjA6MDoyOiBbc2RlXSBBdHRhY2hlZCBT Q1NJIHJlbW92YWJsZSBkaXNrClsgICAxMS43MDIzNjFdIHNkIDc6MDowOjI6IEF0dGFjaGVkIHNj c2kgZ2VuZXJpYyBzZzUgdHlwZSAwClsgICAxMS43MDc0NTVdIHNkIDc6MDowOjM6IFtzZGZdIEF0 dGFjaGVkIFNDU0kgcmVtb3ZhYmxlIGRpc2sKWyAgIDExLjcxMDI1NV0gc2QgNzowOjA6MzogQXR0 YWNoZWQgc2NzaSBnZW5lcmljIHNnNiB0eXBlIDAKWyAgIDE0LjcwMDExMV0gdWRldmQgdmVyc2lv biAxMjQgc3RhcnRlZApbICAgMTUuMTI4NzM2XSBpbnB1dDogUG93ZXIgQnV0dG9uIChGRikgYXMg L2RldmljZXMvTE5YU1lTVE06MDAvTE5YUFdSQk46MDAvaW5wdXQvaW5wdXQyClsgICAxNS4xNTI1 MjhdIEFDUEk6IFBvd2VyIEJ1dHRvbiAoRkYpIFtQV1JGXQpbICAgMTUuMTU1NzE1XSBpbnB1dDog UG93ZXIgQnV0dG9uIChDTSkgYXMgL2RldmljZXMvTE5YU1lTVE06MDAvZGV2aWNlOjAwL1BOUDBD MEM6MDAvaW5wdXQvaW5wdXQzClsgICAxNS4xODQ1MzRdIEFDUEk6IFBvd2VyIEJ1dHRvbiAoQ00p IFtQV1JCXQpbICAgMTUuNDg3NTQzXSBBQ1BJOiBXTUk6IE1hcHBlciBsb2FkZWQKWyAgIDE1LjY4 OTA5N10gSERBIEludGVsIDAwMDA6MDA6MDcuMDogcG93ZXIgc3RhdGUgY2hhbmdlZCBieSBBQ1BJ IHRvIEQwClsgICAxNS42OTI5MjFdIEFDUEk6IFBDSSBJbnRlcnJ1cHQgTGluayBbTEFaQV0gZW5h YmxlZCBhdCBJUlEgMjEKWyAgIDE1LjY5NTcxNV0gSERBIEludGVsIDAwMDA6MDA6MDcuMDogUENJ IElOVCBBIC0+IExpbmtbTEFaQV0gLT4gR1NJIDIxIChsZXZlbCwgbG93KSAtPiBJUlEgMjEKWyAg IDE1LjY5ODYyNF0gSERBIEludGVsIDAwMDA6MDA6MDcuMDogc2V0dGluZyBsYXRlbmN5IHRpbWVy IHRvIDY0ClsgICAxNS43MTUwMDldIHBjaV9ob3RwbHVnOiBQQ0kgSG90IFBsdWcgUENJIENvcmUg dmVyc2lvbjogMC41ClsgICAxNS43NDczMTJdIGhkYV9jb2RlYzogVW5rbm93biBtb2RlbCBmb3Ig QUxDODgzLCB0cnlpbmcgYXV0by1wcm9iZSBmcm9tIEJJT1MuLi4KWyAgIDE1Ljc2NTczMV0gaW5w dXQ6IFBDIFNwZWFrZXIgYXMgL2RldmljZXMvcGxhdGZvcm0vcGNzcGtyL2lucHV0L2lucHV0NApb ICAgMTUuNzg1MDYxXSBzaHBjaHA6IFN0YW5kYXJkIEhvdCBQbHVnIFBDSSBDb250cm9sbGVyIERy aXZlciB2ZXJzaW9uOiAwLjQKWyAgIDE1Ljk5MTMyMF0gZW5kX3JlcXVlc3Q6IEkvTyBlcnJvciwg ZGV2IHNyMCwgc2VjdG9yIDAKWyAgIDE1Ljk5NDQxM10gQnVmZmVyIEkvTyBlcnJvciBvbiBkZXZp Y2Ugc3IwLCBsb2dpY2FsIGJsb2NrIDAKWyAgIDE1Ljk5NzU0NV0gQnVmZmVyIEkvTyBlcnJvciBv biBkZXZpY2Ugc3IwLCBsb2dpY2FsIGJsb2NrIDEKWyAgIDE2LjAwMDU0OF0gQnVmZmVyIEkvTyBl cnJvciBvbiBkZXZpY2Ugc3IwLCBsb2dpY2FsIGJsb2NrIDIKWyAgIDE2LjAwMzUxMl0gQnVmZmVy IEkvTyBlcnJvciBvbiBkZXZpY2Ugc3IwLCBsb2dpY2FsIGJsb2NrIDMKWyAgIDE2LjAwNzkxM10g ZW5kX3JlcXVlc3Q6IEkvTyBlcnJvciwgZGV2IHNyMCwgc2VjdG9yIDAKWyAgIDE2LjAxMDc4OF0g QnVmZmVyIEkvTyBlcnJvciBvbiBkZXZpY2Ugc3IwLCBsb2dpY2FsIGJsb2NrIDAKWyAgIDE2LjQw ODgxOV0gbnZpZGlhOiBtb2R1bGUgbGljZW5zZSAnTlZJRElBJyB0YWludHMga2VybmVsLgpbICAg MTYuNjY2ODU4XSBudmlkaWEgMDAwMDowMjowMC4wOiBQQ0kgSU5UIEEgLT4gTGlua1tMTjBBXSAt PiBHU0kgMTkgKGxldmVsLCBsb3cpIC0+IElSUSAxOQpbICAgMTYuNjY5ODE1XSBudmlkaWEgMDAw MDowMjowMC4wOiBzZXR0aW5nIGxhdGVuY3kgdGltZXIgdG8gNjQKWyAgIDE2LjY2OTk3OF0gTlZS TTogbG9hZGluZyBOVklESUEgVU5JWCB4ODZfNjQgS2VybmVsIE1vZHVsZSAgMTc3LjgwICBXZWQg T2N0ICAxIDE0OjQzOjQ2IFBEVCAyMDA4ClsgICAxNi43NDIwNTVdIGhkYV9jb2RlYzogbnVtX3N0 ZXBzID0gMCBmb3IgTklEPTB4ZCAoY3RsID0gU3Vycm91bmQgUGxheWJhY2sgVm9sdW1lKQpbICAg MTYuNzQ1NjUyXSBoZGFfY29kZWM6IG51bV9zdGVwcyA9IDAgZm9yIE5JRD0weGYgKGN0bCA9IFNp ZGUgUGxheWJhY2sgVm9sdW1lKQpbICAgMTcuMzI3MDUyXSBpbnB1dDogSW1QUy8yIEdlbmVyaWMg V2hlZWwgTW91c2UgYXMgL2RldmljZXMvcGxhdGZvcm0vaTgwNDIvc2VyaW8xL2lucHV0L2lucHV0 NQpbICAgMTcuMzYxMDMxXSBscDogZHJpdmVyIGxvYWRlZCBidXQgbm8gZGV2aWNlcyBmb3VuZApb ICAgMTcuNTA5NDYyXSBBZGRpbmcgMTQxMzcxNjBrIHN3YXAgb24gL2Rldi9zZGE1LiAgUHJpb3Jp dHk6LTEgZXh0ZW50czoxIGFjcm9zczoxNDEzNzE2MGsKWyAgIDE4LjAwMDY4MV0gRVhUMyBGUyBv biBzZGExLCBpbnRlcm5hbCBqb3VybmFsClsgICAxOC41ODI2NDFdIHR5cGU9MTUwNSBhdWRpdCgx MjI4NjEyNjQ2LjQ1ODoyKTogb3BlcmF0aW9uPSJwcm9maWxlX2xvYWQiIG5hbWU9Ii91c3Ivc2hh cmUvZ2RtL2d1ZXN0LXNlc3Npb24vWHNlc3Npb24iIG5hbWUyPSJkZWZhdWx0IiBwaWQ9NDgyNApb ICAgMTguNzI2OTczXSB0eXBlPTE1MDUgYXVkaXQoMTIyODYxMjY0Ni42MDI6Myk6IG9wZXJhdGlv bj0icHJvZmlsZV9sb2FkIiBuYW1lPSIvdXNyL2xpYi9jdXBzL2JhY2tlbmQvY3Vwcy1wZGYiIG5h bWUyPSJkZWZhdWx0IiBwaWQ9NDgyOQpbICAgMTguNzI3MTU5XSB0eXBlPTE1MDUgYXVkaXQoMTIy ODYxMjY0Ni42MDI6NCk6IG9wZXJhdGlvbj0icHJvZmlsZV9sb2FkIiBuYW1lPSIvdXNyL3NiaW4v Y3Vwc2QiIG5hbWUyPSJkZWZhdWx0IiBwaWQ9NDgyOQpbICAgMTguNzY0OTU5XSB0eXBlPTE1MDUg YXVkaXQoMTIyODYxMjY0Ni42NDI6NSk6IG9wZXJhdGlvbj0icHJvZmlsZV9sb2FkIiBuYW1lPSIv dXNyL3NiaW4vbXlzcWxkIiBuYW1lMj0iZGVmYXVsdCIgcGlkPTQ4MzMKWyAgIDE4LjgwNzMyNl0g dHlwZT0xNTA1IGF1ZGl0KDEyMjg2MTI2NDYuNjgyOjYpOiBvcGVyYXRpb249InByb2ZpbGVfbG9h ZCIgbmFtZT0iL3Vzci9zYmluL25hbWVkIiBuYW1lMj0iZGVmYXVsdCIgcGlkPTQ4MzcKWyAgIDE4 LjkzMTE0MV0gaXBfdGFibGVzOiAoQykgMjAwMC0yMDA2IE5ldGZpbHRlciBDb3JlIFRlYW0KWyAg IDIxLjExMzY0N10gd2FybmluZzogYGF2YWhpLWRhZW1vbicgdXNlcyAzMi1iaXQgY2FwYWJpbGl0 aWVzIChsZWdhY3kgc3VwcG9ydCBpbiB1c2UpClsgICAyMy41MjgwMjVdIHR5cGU9MTUwMyBhdWRp dCgxMjI4NjEyNjUxLjQwNTo3KTogb3BlcmF0aW9uPSJjYXBhYmxlIiBuYW1lPSJzeXNfcmVzb3Vy Y2UiIHBpZD01NTA0IHByb2ZpbGU9Ii91c3Ivc2Jpbi9uYW1lZCIKWyAgIDMzLjQ4ODY3Nl0gcHBk ZXY6IHVzZXItc3BhY2UgcGFyYWxsZWwgcG9ydCBkcml2ZXIKWyAgIDM5Ljg5NDkwN10gTkVUOiBS ZWdpc3RlcmVkIHByb3RvY29sIGZhbWlseSAxMApbICAgMzkuODk1NDE0XSBsbzogRGlzYWJsZWQg UHJpdmFjeSBFeHRlbnNpb25zClsgICA0Ny4yMDQzMjddIG10cnI6IGJhc2UoMHhlMDAwMDAwMCkg aXMgbm90IGFsaWduZWQgb24gYSBzaXplKDB4ZmYwMDAwMCkgYm91bmRhcnkKWyAgIDQ4LjQzMTUy MV0gTkVUOiBSZWdpc3RlcmVkIHByb3RvY29sIGZhbWlseSAxNwpbICAgNTQuMDg3Nzg2XSB0eXBl PTE1MDMgYXVkaXQoMTIyODYxMjY4MS45NjM6OCk6IG9wZXJhdGlvbj0iY2FwYWJsZSIgbmFtZT0i c3lzX3Jlc291cmNlIiBwaWQ9NTUwMiBwcm9maWxlPSIvdXNyL3NiaW4vbmFtZWQiClsgICA1NC4w ODc5MThdIHR5cGU9MTUwMyBhdWRpdCgxMjI4NjEyNjgxLjk2Mzo5KTogb3BlcmF0aW9uPSJpbm9k ZV9wZXJtaXNzaW9uIiByZXF1ZXN0ZWRfbWFzaz0iOjpyIiBkZW5pZWRfbWFzaz0iOjpyIiBmc3Vp ZD0xMjkgbmFtZT0iL3Byb2MvNTUwMC9uZXQvaWZfaW5ldDYiIHBpZD01NTAyIHByb2ZpbGU9Ii91 c3Ivc2Jpbi9uYW1lZCIKWyAgIDU4Ljc0NDIwN10gZXRoMDogbm8gSVB2NiByb3V0ZXJzIHByZXNl bnQKWyAgOTE2LjAzOTIyM10gdWZzIHdhcyBjb21waWxlZCB3aXRoIHJlYWQtb25seSBzdXBwb3J0 LCBjYW4ndCBiZSBtb3VudGVkIGFzIHJlYWQtd3JpdGUKWyAgOTE2LjA1NTk2NF0gdWZzIHdhcyBj b21waWxlZCB3aXRoIHJlYWQtb25seSBzdXBwb3J0LCBjYW4ndCBiZSBtb3VudGVkIGFzIHJlYWQt d3JpdGUKWyAgOTE2LjA3MzYxNl0gdWZzIHdhcyBjb21waWxlZCB3aXRoIHJlYWQtb25seSBzdXBw b3J0LCBjYW4ndCBiZSBtb3VudGVkIGFzIHJlYWQtd3JpdGUKWyAgOTE2LjA5MTY4N10gdWZzIHdh cyBjb21waWxlZCB3aXRoIHJlYWQtb25seSBzdXBwb3J0LCBjYW4ndCBiZSBtb3VudGVkIGFzIHJl YWQtd3JpdGUKWyAgOTE2LjEwNzY2MF0gdWZzIHdhcyBjb21waWxlZCB3aXRoIHJlYWQtb25seSBz dXBwb3J0LCBjYW4ndCBiZSBtb3VudGVkIGFzIHJlYWQtd3JpdGUKWyAxMDEyLjIwOTUyMl0gQ0U6 IGhwZXQgaW5jcmVhc2luZyBtaW5fZGVsdGFfbnMgdG8gMTUwMDAgbnNlYwpbIDM2MzQuMzY1MDE0 XSB0eXBlPTE1MDMgYXVkaXQoMTIyODYxNjI1MS40MDg6MTApOiBvcGVyYXRpb249Imlub2RlX3Bl cm1pc3Npb24iIHJlcXVlc3RlZF9tYXNrPSI6OnIiIGRlbmllZF9tYXNrPSI6OnIiIGZzdWlkPTEy OSBuYW1lPSIvcHJvYy81NTAwL25ldC9pZl9pbmV0NiIgcGlkPTU1MDQgcHJvZmlsZT0iL3Vzci9z YmluL25hbWVkIgpbIDcyMzQuMzY1MzA5XSB0eXBlPTE1MDMgYXVkaXQoMTIyODYxOTg1MS40MDg6 MTEpOiBvcGVyYXRpb249Imlub2RlX3Blcm1pc3Npb24iIHJlcXVlc3RlZF9tYXNrPSI6OnIiIGRl bmllZF9tYXNrPSI6OnIiIGZzdWlkPTEyOSBuYW1lPSIvcHJvYy81NTAwL25ldC9pZl9pbmV0NiIg cGlkPTU1MDIgcHJvZmlsZT0iL3Vzci9zYmluL25hbWVkIgpbMTA4MzQuMzY1NDczXSB0eXBlPTE1 MDMgYXVkaXQoMTIyODYyMzQ1MS40MDg6MTIpOiBvcGVyYXRpb249Imlub2RlX3Blcm1pc3Npb24i IHJlcXVlc3RlZF9tYXNrPSI6OnIiIGRlbmllZF9tYXNrPSI6OnIiIGZzdWlkPTEyOSBuYW1lPSIv cHJvYy81NTAwL25ldC9pZl9pbmV0NiIgcGlkPTU1MDMgcHJvZmlsZT0iL3Vzci9zYmluL25hbWVk IgpbMTQ0MzQuMzY1NjQ2XSB0eXBlPTE1MDMgYXVkaXQoMTIyODYyNzA1MS40MDc6MTMpOiBvcGVy YXRpb249Imlub2RlX3Blcm1pc3Npb24iIHJlcXVlc3RlZF9tYXNrPSI6OnIiIGRlbmllZF9tYXNr PSI6OnIiIGZzdWlkPTEyOSBuYW1lPSIvcHJvYy81NTAwL25ldC9pZl9pbmV0NiIgcGlkPTU1MDQg cHJvZmlsZT0iL3Vzci9zYmluL25hbWVkIgpbMTgwMzQuMzY1NjgxXSB0eXBlPTE1MDMgYXVkaXQo MTIyODYzMDY1MS40MDk6MTQpOiBvcGVyYXRpb249Imlub2RlX3Blcm1pc3Npb24iIHJlcXVlc3Rl ZF9tYXNrPSI6OnIiIGRlbmllZF9tYXNrPSI6OnIiIGZzdWlkPTEyOSBuYW1lPSIvcHJvYy81NTAw L25ldC9pZl9pbmV0NiIgcGlkPTU1MDQgcHJvZmlsZT0iL3Vzci9zYmluL25hbWVkIgpbMjE2MzQu MzY1NzM0XSB0eXBlPTE1MDMgYXVkaXQoMTIyODYzNDI1MS40MDk6MTUpOiBvcGVyYXRpb249Imlu b2RlX3Blcm1pc3Npb24iIHJlcXVlc3RlZF9tYXNrPSI6OnIiIGRlbmllZF9tYXNrPSI6OnIiIGZz dWlkPTEyOSBuYW1lPSIvcHJvYy81NTAwL25ldC9pZl9pbmV0NiIgcGlkPTU1MDIgcHJvZmlsZT0i L3Vzci9zYmluL25hbWVkIgpbMjUyMzQuMzY2MzE5XSB0eXBlPTE1MDMgYXVkaXQoMTIyODYzNzg1 MS40MDk6MTYpOiBvcGVyYXRpb249Imlub2RlX3Blcm1pc3Npb24iIHJlcXVlc3RlZF9tYXNrPSI6 OnIiIGRlbmllZF9tYXNrPSI6OnIiIGZzdWlkPTEyOSBuYW1lPSIvcHJvYy81NTAwL25ldC9pZl9p bmV0NiIgcGlkPTU1MDMgcHJvZmlsZT0iL3Vzci9zYmluL25hbWVkIgpbMjg4MzQuMzY2NDIzXSB0 eXBlPTE1MDMgYXVkaXQoMTIyODY0MTQ1MS40MDk6MTcpOiBvcGVyYXRpb249Imlub2RlX3Blcm1p c3Npb24iIHJlcXVlc3RlZF9tYXNrPSI6OnIiIGRlbmllZF9tYXNrPSI6OnIiIGZzdWlkPTEyOSBu YW1lPSIvcHJvYy81NTAwL25ldC9pZl9pbmV0NiIgcGlkPTU1MDMgcHJvZmlsZT0iL3Vzci9zYmlu L25hbWVkIgpbMzI0MzQuMzY2NDQ5XSB0eXBlPTE1MDMgYXVkaXQoMTIyODY0NTA1MS40MDk6MTgp OiBvcGVyYXRpb249Imlub2RlX3Blcm1pc3Npb24iIHJlcXVlc3RlZF9tYXNrPSI6OnIiIGRlbmll ZF9tYXNrPSI6OnIiIGZzdWlkPTEyOSBuYW1lPSIvcHJvYy81NTAwL25ldC9pZl9pbmV0NiIgcGlk PTU1MDQgcHJvZmlsZT0iL3Vzci9zYmluL25hbWVkIgpbMzYwMzQuMzY2NDY4XSB0eXBlPTE1MDMg YXVkaXQoMTIyODY0ODY1MS40MDk6MTkpOiBvcGVyYXRpb249Imlub2RlX3Blcm1pc3Npb24iIHJl cXVlc3RlZF9tYXNrPSI6OnIiIGRlbmllZF9tYXNrPSI6OnIiIGZzdWlkPTEyOSBuYW1lPSIvcHJv Yy81NTAwL25ldC9pZl9pbmV0NiIgcGlkPTU1MDQgcHJvZmlsZT0iL3Vzci9zYmluL25hbWVkIgpb Mzk2MzQuMzY2NDcyXSB0eXBlPTE1MDMgYXVkaXQoMTIyODY1MjI1MS40MDk6MjApOiBvcGVyYXRp b249Imlub2RlX3Blcm1pc3Npb24iIHJlcXVlc3RlZF9tYXNrPSI6OnIiIGRlbmllZF9tYXNrPSI6 OnIiIGZzdWlkPTEyOSBuYW1lPSIvcHJvYy81NTAwL25ldC9pZl9pbmV0NiIgcGlkPTU1MDMgcHJv ZmlsZT0iL3Vzci9zYmluL25hbWVkIgpbNDMyMzQuMzY2NTM4XSB0eXBlPTE1MDMgYXVkaXQoMTIy ODY1NTg1MS40MDk6MjEpOiBvcGVyYXRpb249Imlub2RlX3Blcm1pc3Npb24iIHJlcXVlc3RlZF9t YXNrPSI6OnIiIGRlbmllZF9tYXNrPSI6OnIiIGZzdWlkPTEyOSBuYW1lPSIvcHJvYy81NTAwL25l dC9pZl9pbmV0NiIgcGlkPTU1MDEgcHJvZmlsZT0iL3Vzci9zYmluL25hbWVkIgpbNDY4MzQuMzY2 NTUzXSB0eXBlPTE1MDMgYXVkaXQoMTIyODY1OTQ1MS40MDk6MjIpOiBvcGVyYXRpb249Imlub2Rl X3Blcm1pc3Npb24iIHJlcXVlc3RlZF9tYXNrPSI6OnIiIGRlbmllZF9tYXNrPSI6OnIiIGZzdWlk PTEyOSBuYW1lPSIvcHJvYy81NTAwL25ldC9pZl9pbmV0NiIgcGlkPTU1MDMgcHJvZmlsZT0iL3Vz ci9zYmluL25hbWVkIgpbNTA0MzQuMzY2NTgzXSB0eXBlPTE1MDMgYXVkaXQoMTIyODY2MzA1MS40 MDk6MjMpOiBvcGVyYXRpb249Imlub2RlX3Blcm1pc3Npb24iIHJlcXVlc3RlZF9tYXNrPSI6OnIi IGRlbmllZF9tYXNrPSI6OnIiIGZzdWlkPTEyOSBuYW1lPSIvcHJvYy81NTAwL25ldC9pZl9pbmV0 NiIgcGlkPTU1MDIgcHJvZmlsZT0iL3Vzci9zYmluL25hbWVkIgpbNTQwMzQuMzY2NzE1XSB0eXBl PTE1MDMgYXVkaXQoMTIyODY2NjY1MS40MDk6MjQpOiBvcGVyYXRpb249Imlub2RlX3Blcm1pc3Np b24iIHJlcXVlc3RlZF9tYXNrPSI6OnIiIGRlbmllZF9tYXNrPSI6OnIiIGZzdWlkPTEyOSBuYW1l PSIvcHJvYy81NTAwL25ldC9pZl9pbmV0NiIgcGlkPTU1MDMgcHJvZmlsZT0iL3Vzci9zYmluL25h bWVkIgpbNTc2MzQuMzY2NzY0XSB0eXBlPTE1MDMgYXVkaXQoMTIyODY3MDI1MS40MDk6MjUpOiBv cGVyYXRpb249Imlub2RlX3Blcm1pc3Npb24iIHJlcXVlc3RlZF9tYXNrPSI6OnIiIGRlbmllZF9t YXNrPSI6OnIiIGZzdWlkPTEyOSBuYW1lPSIvcHJvYy81NTAwL25ldC9pZl9pbmV0NiIgcGlkPTU1 MDMgcHJvZmlsZT0iL3Vzci9zYmluL25hbWVkIgpbNjEyMzQuMzY2ODEzXSB0eXBlPTE1MDMgYXVk aXQoMTIyODY3Mzg1MS40MDk6MjYpOiBvcGVyYXRpb249Imlub2RlX3Blcm1pc3Npb24iIHJlcXVl c3RlZF9tYXNrPSI6OnIiIGRlbmllZF9tYXNrPSI6OnIiIGZzdWlkPTEyOSBuYW1lPSIvcHJvYy81 NTAwL25ldC9pZl9pbmV0NiIgcGlkPTU1MDQgcHJvZmlsZT0iL3Vzci9zYmluL25hbWVkIgpbNjQ4 MzQuMzY2ODI1XSB0eXBlPTE1MDMgYXVkaXQoMTIyODY3NzQ1MS40MDk6MjcpOiBvcGVyYXRpb249 Imlub2RlX3Blcm1pc3Npb24iIHJlcXVlc3RlZF9tYXNrPSI6OnIiIGRlbmllZF9tYXNrPSI6OnIi IGZzdWlkPTEyOSBuYW1lPSIvcHJvYy81NTAwL25ldC9pZl9pbmV0NiIgcGlkPTU1MDIgcHJvZmls ZT0iL3Vzci9zYmluL25hbWVkIgpbNjg0MzQuMzY2ODQwXSB0eXBlPTE1MDMgYXVkaXQoMTIyODY4 MTA1MS40MDk6MjgpOiBvcGVyYXRpb249Imlub2RlX3Blcm1pc3Npb24iIHJlcXVlc3RlZF9tYXNr PSI6OnIiIGRlbmllZF9tYXNrPSI6OnIiIGZzdWlkPTEyOSBuYW1lPSIvcHJvYy81NTAwL25ldC9p Zl9pbmV0NiIgcGlkPTU1MDIgcHJvZmlsZT0iL3Vzci9zYmluL25hbWVkIgpbNzIwMzQuMzY2ODQ4 XSB0eXBlPTE1MDMgYXVkaXQoMTIyODY4NDY1MS40MDk6MjkpOiBvcGVyYXRpb249Imlub2RlX3Bl cm1pc3Npb24iIHJlcXVlc3RlZF9tYXNrPSI6OnIiIGRlbmllZF9tYXNrPSI6OnIiIGZzdWlkPTEy OSBuYW1lPSIvcHJvYy81NTAwL25ldC9pZl9pbmV0NiIgcGlkPTU1MDIgcHJvZmlsZT0iL3Vzci9z YmluL25hbWVkIgpbNzU2MzQuMzY2OTI2XSB0eXBlPTE1MDMgYXVkaXQoMTIyODY4ODI1MS40MDk6 MzApOiBvcGVyYXRpb249Imlub2RlX3Blcm1pc3Npb24iIHJlcXVlc3RlZF9tYXNrPSI6OnIiIGRl bmllZF9tYXNrPSI6OnIiIGZzdWlkPTEyOSBuYW1lPSIvcHJvYy81NTAwL25ldC9pZl9pbmV0NiIg cGlkPTU1MDMgcHJvZmlsZT0iL3Vzci9zYmluL25hbWVkIgpbNzkyMzQuMzY2OTQ0XSB0eXBlPTE1 MDMgYXVkaXQoMTIyODY5MTg1MS40MDk6MzEpOiBvcGVyYXRpb249Imlub2RlX3Blcm1pc3Npb24i IHJlcXVlc3RlZF9tYXNrPSI6OnIiIGRlbmllZF9tYXNrPSI6OnIiIGZzdWlkPTEyOSBuYW1lPSIv cHJvYy81NTAwL25ldC9pZl9pbmV0NiIgcGlkPTU1MDIgcHJvZmlsZT0iL3Vzci9zYmluL25hbWVk IgpbODI4MzQuMzY3MDA1XSB0eXBlPTE1MDMgYXVkaXQoMTIyODY5NTQ1MS40MDk6MzIpOiBvcGVy YXRpb249Imlub2RlX3Blcm1pc3Npb24iIHJlcXVlc3RlZF9tYXNrPSI6OnIiIGRlbmllZF9tYXNr PSI6OnIiIGZzdWlkPTEyOSBuYW1lPSIvcHJvYy81NTAwL25ldC9pZl9pbmV0NiIgcGlkPTU1MDQg cHJvZmlsZT0iL3Vzci9zYmluL25hbWVkIgpbODY0MzQuMzY3MTM0XSB0eXBlPTE1MDMgYXVkaXQo MTIyODY5OTA1MS40MDk6MzMpOiBvcGVyYXRpb249Imlub2RlX3Blcm1pc3Npb24iIHJlcXVlc3Rl ZF9tYXNrPSI6OnIiIGRlbmllZF9tYXNrPSI6OnIiIGZzdWlkPTEyOSBuYW1lPSIvcHJvYy81NTAw L25ldC9pZl9pbmV0NiIgcGlkPTU1MDEgcHJvZmlsZT0iL3Vzci9zYmluL25hbWVkIgpbOTAwMzQu MzY3MTQyXSB0eXBlPTE1MDMgYXVkaXQoMTIyODcwMjY1MS40MDk6MzQpOiBvcGVyYXRpb249Imlu b2RlX3Blcm1pc3Npb24iIHJlcXVlc3RlZF9tYXNrPSI6OnIiIGRlbmllZF9tYXNrPSI6OnIiIGZz dWlkPTEyOSBuYW1lPSIvcHJvYy81NTAwL25ldC9pZl9pbmV0NiIgcGlkPTU1MDIgcHJvZmlsZT0i L3Vzci9zYmluL25hbWVkIgpbOTM2MzQuMzY3MTU2XSB0eXBlPTE1MDMgYXVkaXQoMTIyODcwNjI1 MS40MDk6MzUpOiBvcGVyYXRpb249Imlub2RlX3Blcm1pc3Npb24iIHJlcXVlc3RlZF9tYXNrPSI6 OnIiIGRlbmllZF9tYXNrPSI6OnIiIGZzdWlkPTEyOSBuYW1lPSIvcHJvYy81NTAwL25ldC9pZl9p bmV0NiIgcGlkPTU1MDQgcHJvZmlsZT0iL3Vzci9zYmluL25hbWVkIgpbOTcyMzQuMzY3MTgzXSB0 eXBlPTE1MDMgYXVkaXQoMTIyODcwOTg1MS40MDk6MzYpOiBvcGVyYXRpb249Imlub2RlX3Blcm1p c3Npb24iIHJlcXVlc3RlZF9tYXNrPSI6OnIiIGRlbmllZF9tYXNrPSI6OnIiIGZzdWlkPTEyOSBu YW1lPSIvcHJvYy81NTAwL25ldC9pZl9pbmV0NiIgcGlkPTU1MDEgcHJvZmlsZT0iL3Vzci9zYmlu L25hbWVkIgpbMTAwODM0LjM2NzE4Ml0gdHlwZT0xNTAzIGF1ZGl0KDEyMjg3MTM0NTEuNDA5OjM3 KTogb3BlcmF0aW9uPSJpbm9kZV9wZXJtaXNzaW9uIiByZXF1ZXN0ZWRfbWFzaz0iOjpyIiBkZW5p ZWRfbWFzaz0iOjpyIiBmc3VpZD0xMjkgbmFtZT0iL3Byb2MvNTUwMC9uZXQvaWZfaW5ldDYiIHBp ZD01NTAxIHByb2ZpbGU9Ii91c3Ivc2Jpbi9uYW1lZCIKWzEwNDQzNC4zNjcyMDBdIHR5cGU9MTUw MyBhdWRpdCgxMjI4NzE3MDUxLjQwOTozOCk6IG9wZXJhdGlvbj0iaW5vZGVfcGVybWlzc2lvbiIg cmVxdWVzdGVkX21hc2s9Ijo6ciIgZGVuaWVkX21hc2s9Ijo6ciIgZnN1aWQ9MTI5IG5hbWU9Ii9w cm9jLzU1MDAvbmV0L2lmX2luZXQ2IiBwaWQ9NTUwMSBwcm9maWxlPSIvdXNyL3NiaW4vbmFtZWQi ClsxMDgwMzQuMzY3MzA3XSB0eXBlPTE1MDMgYXVkaXQoMTIyODcyMDY1MS40MDk6MzkpOiBvcGVy YXRpb249Imlub2RlX3Blcm1pc3Npb24iIHJlcXVlc3RlZF9tYXNrPSI6OnIiIGRlbmllZF9tYXNr PSI6OnIiIGZzdWlkPTEyOSBuYW1lPSIvcHJvYy81NTAwL25ldC9pZl9pbmV0NiIgcGlkPTU1MDMg cHJvZmlsZT0iL3Vzci9zYmluL25hbWVkIgpbMTExNjM0LjM2NzMxOV0gdHlwZT0xNTAzIGF1ZGl0 KDEyMjg3MjQyNTEuNDA5OjQwKTogb3BlcmF0aW9uPSJpbm9kZV9wZXJtaXNzaW9uIiByZXF1ZXN0 ZWRfbWFzaz0iOjpyIiBkZW5pZWRfbWFzaz0iOjpyIiBmc3VpZD0xMjkgbmFtZT0iL3Byb2MvNTUw MC9uZXQvaWZfaW5ldDYiIHBpZD01NTAyIHByb2ZpbGU9Ii91c3Ivc2Jpbi9uYW1lZCIKWzExNTIz NC4zNjc4MTNdIHR5cGU9MTUwMyBhdWRpdCgxMjI4NzI3ODUxLjQwOTo0MSk6IG9wZXJhdGlvbj0i aW5vZGVfcGVybWlzc2lvbiIgcmVxdWVzdGVkX21hc2s9Ijo6ciIgZGVuaWVkX21hc2s9Ijo6ciIg ZnN1aWQ9MTI5IG5hbWU9Ii9wcm9jLzU1MDAvbmV0L2lmX2luZXQ2IiBwaWQ9NTUwMyBwcm9maWxl PSIvdXNyL3NiaW4vbmFtZWQiClsxMTg4MzQuMzY3ODIzXSB0eXBlPTE1MDMgYXVkaXQoMTIyODcz MTQ1MS40MDk6NDIpOiBvcGVyYXRpb249Imlub2RlX3Blcm1pc3Npb24iIHJlcXVlc3RlZF9tYXNr PSI6OnIiIGRlbmllZF9tYXNrPSI6OnIiIGZzdWlkPTEyOSBuYW1lPSIvcHJvYy81NTAwL25ldC9p Zl9pbmV0NiIgcGlkPTU1MDMgcHJvZmlsZT0iL3Vzci9zYmluL25hbWVkIgpbMTIyNDM0LjM2Nzk5 MF0gdHlwZT0xNTAzIGF1ZGl0KDEyMjg3MzUwNTEuNDA5OjQzKTogb3BlcmF0aW9uPSJpbm9kZV9w ZXJtaXNzaW9uIiByZXF1ZXN0ZWRfbWFzaz0iOjpyIiBkZW5pZWRfbWFzaz0iOjpyIiBmc3VpZD0x MjkgbmFtZT0iL3Byb2MvNTUwMC9uZXQvaWZfaW5ldDYiIHBpZD01NTA0IHByb2ZpbGU9Ii91c3Iv c2Jpbi9uYW1lZCIKWzEyNjAzNC4zNjgwMjhdIHR5cGU9MTUwMyBhdWRpdCgxMjI4NzM4NjUxLjQx MTo0NCk6IG9wZXJhdGlvbj0iaW5vZGVfcGVybWlzc2lvbiIgcmVxdWVzdGVkX21hc2s9Ijo6ciIg ZGVuaWVkX21hc2s9Ijo6ciIgZnN1aWQ9MTI5IG5hbWU9Ii9wcm9jLzU1MDAvbmV0L2lmX2luZXQ2 IiBwaWQ9NTUwMyBwcm9maWxlPSIvdXNyL3NiaW4vbmFtZWQiClsxMjk2MzQuMzY4MDIxXSB0eXBl PTE1MDMgYXVkaXQoMTIyODc0MjI1MS40MDk6NDUpOiBvcGVyYXRpb249Imlub2RlX3Blcm1pc3Np b24iIHJlcXVlc3RlZF9tYXNrPSI6OnIiIGRlbmllZF9tYXNrPSI6OnIiIGZzdWlkPTEyOSBuYW1l PSIvcHJvYy81NTAwL25ldC9pZl9pbmV0NiIgcGlkPTU1MDQgcHJvZmlsZT0iL3Vzci9zYmluL25h bWVkIgpbMTMzMjM0LjM2ODA1NV0gdHlwZT0xNTAzIGF1ZGl0KDEyMjg3NDU4NTEuNDExOjQ2KTog b3BlcmF0aW9uPSJpbm9kZV9wZXJtaXNzaW9uIiByZXF1ZXN0ZWRfbWFzaz0iOjpyIiBkZW5pZWRf bWFzaz0iOjpyIiBmc3VpZD0xMjkgbmFtZT0iL3Byb2MvNTUwMC9uZXQvaWZfaW5ldDYiIHBpZD01 NTAzIHByb2ZpbGU9Ii91c3Ivc2Jpbi9uYW1lZCIKWzEzNjgzNC4zNjgyMTldIHR5cGU9MTUwMyBh dWRpdCgxMjI4NzQ5NDUxLjQxMTo0Nyk6IG9wZXJhdGlvbj0iaW5vZGVfcGVybWlzc2lvbiIgcmVx dWVzdGVkX21hc2s9Ijo6ciIgZGVuaWVkX21hc2s9Ijo6ciIgZnN1aWQ9MTI5IG5hbWU9Ii9wcm9j LzU1MDAvbmV0L2lmX2luZXQ2IiBwaWQ9NTUwMiBwcm9maWxlPSIvdXNyL3NiaW4vbmFtZWQiClsx NDA0MzQuMzY4NTMzXSB0eXBlPTE1MDMgYXVkaXQoMTIyODc1MzA1MS40MTI6NDgpOiBvcGVyYXRp b249Imlub2RlX3Blcm1pc3Npb24iIHJlcXVlc3RlZF9tYXNrPSI6OnIiIGRlbmllZF9tYXNrPSI6 OnIiIGZzdWlkPTEyOSBuYW1lPSIvcHJvYy81NTAwL25ldC9pZl9pbmV0NiIgcGlkPTU1MDEgcHJv ZmlsZT0iL3Vzci9zYmluL25hbWVkIgpbMTQ0MDM0LjM2ODYwOV0gdHlwZT0xNTAzIGF1ZGl0KDEy Mjg3NTY2NTEuNDEyOjQ5KTogb3BlcmF0aW9uPSJpbm9kZV9wZXJtaXNzaW9uIiByZXF1ZXN0ZWRf bWFzaz0iOjpyIiBkZW5pZWRfbWFzaz0iOjpyIiBmc3VpZD0xMjkgbmFtZT0iL3Byb2MvNTUwMC9u ZXQvaWZfaW5ldDYiIHBpZD01NTAyIHByb2ZpbGU9Ii91c3Ivc2Jpbi9uYW1lZCIKWzE0NzYzNC4z Njg2MDhdIHR5cGU9MTUwMyBhdWRpdCgxMjI4NzYwMjUxLjQxMjo1MCk6IG9wZXJhdGlvbj0iaW5v ZGVfcGVybWlzc2lvbiIgcmVxdWVzdGVkX21hc2s9Ijo6ciIgZGVuaWVkX21hc2s9Ijo6ciIgZnN1 aWQ9MTI5IG5hbWU9Ii9wcm9jLzU1MDAvbmV0L2lmX2luZXQ2IiBwaWQ9NTUwNCBwcm9maWxlPSIv dXNyL3NiaW4vbmFtZWQiClsxNTEyMzQuMzY4NjM3XSB0eXBlPTE1MDMgYXVkaXQoMTIyODc2Mzg1 MS40MTI6NTEpOiBvcGVyYXRpb249Imlub2RlX3Blcm1pc3Npb24iIHJlcXVlc3RlZF9tYXNrPSI6 OnIiIGRlbmllZF9tYXNrPSI6OnIiIGZzdWlkPTEyOSBuYW1lPSIvcHJvYy81NTAwL25ldC9pZl9p bmV0NiIgcGlkPTU1MDQgcHJvZmlsZT0iL3Vzci9zYmluL25hbWVkIgpbMTU0ODM0LjM2ODc1Nl0g dHlwZT0xNTAzIGF1ZGl0KDEyMjg3Njc0NTEuNDEyOjUyKTogb3BlcmF0aW9uPSJpbm9kZV9wZXJt aXNzaW9uIiByZXF1ZXN0ZWRfbWFzaz0iOjpyIiBkZW5pZWRfbWFzaz0iOjpyIiBmc3VpZD0xMjkg bmFtZT0iL3Byb2MvNTUwMC9uZXQvaWZfaW5ldDYiIHBpZD01NTAyIHByb2ZpbGU9Ii91c3Ivc2Jp bi9uYW1lZCIKWzE1ODQzNC4zNjg3ODNdIHR5cGU9MTUwMyBhdWRpdCgxMjI4NzcxMDUxLjQxMjo1 Myk6IG9wZXJhdGlvbj0iaW5vZGVfcGVybWlzc2lvbiIgcmVxdWVzdGVkX21hc2s9Ijo6ciIgZGVu aWVkX21hc2s9Ijo6ciIgZnN1aWQ9MTI5IG5hbWU9Ii9wcm9jLzU1MDAvbmV0L2lmX2luZXQ2IiBw aWQ9NTUwMSBwcm9maWxlPSIvdXNyL3NiaW4vbmFtZWQiClsxNjIwMzQuMzY4ODIyXSB0eXBlPTE1 MDMgYXVkaXQoMTIyODc3NDY1MS40MTI6NTQpOiBvcGVyYXRpb249Imlub2RlX3Blcm1pc3Npb24i IHJlcXVlc3RlZF9tYXNrPSI6OnIiIGRlbmllZF9tYXNrPSI6OnIiIGZzdWlkPTEyOSBuYW1lPSIv cHJvYy81NTAwL25ldC9pZl9pbmV0NiIgcGlkPTU1MDQgcHJvZmlsZT0iL3Vzci9zYmluL25hbWVk IgpbMTY1NjM0LjM2ODg3M10gdHlwZT0xNTAzIGF1ZGl0KDEyMjg3NzgyNTEuNDEyOjU1KTogb3Bl cmF0aW9uPSJpbm9kZV9wZXJtaXNzaW9uIiByZXF1ZXN0ZWRfbWFzaz0iOjpyIiBkZW5pZWRfbWFz az0iOjpyIiBmc3VpZD0xMjkgbmFtZT0iL3Byb2MvNTUwMC9uZXQvaWZfaW5ldDYiIHBpZD01NTA0 IHByb2ZpbGU9Ii91c3Ivc2Jpbi9uYW1lZCIKWzE2OTIzNC4zNjg5MzFdIHR5cGU9MTUwMyBhdWRp dCgxMjI4NzgxODUxLjQxMjo1Nik6IG9wZXJhdGlvbj0iaW5vZGVfcGVybWlzc2lvbiIgcmVxdWVz dGVkX21hc2s9Ijo6ciIgZGVuaWVkX21hc2s9Ijo6ciIgZnN1aWQ9MTI5IG5hbWU9Ii9wcm9jLzU1 MDAvbmV0L2lmX2luZXQ2IiBwaWQ9NTUwNCBwcm9maWxlPSIvdXNyL3NiaW4vbmFtZWQiCg== --MP_/uxkKrGOcbHvWrQ.4JxzZG1R Content-Type: application/octet-stream; name=linux.lspci.vmm Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=linux.lspci.vmm U2xvdDoJMDA6MDAuMApDbGFzczoJUkFNIG1lbW9yeQpWZW5kb3I6CW5WaWRpYSBDb3Jwb3JhdGlv bgpEZXZpY2U6CU1DUDc4UyBbR2VGb3JjZSA4MjAwXSBNZW1vcnkgQ29udHJvbGxlcgpTVmVuZG9y OglIZXdsZXR0LVBhY2thcmQgQ29tcGFueQpTRGV2aWNlOglEZXZpY2UgMmE2ZQpSZXY6CWEyCgpT bG90OgkwMDowMS4wCkNsYXNzOglJU0EgYnJpZGdlClZlbmRvcjoJblZpZGlhIENvcnBvcmF0aW9u CkRldmljZToJTUNQNzhTIFtHZUZvcmNlIDgyMDBdIExQQyBCcmlkZ2UKU1ZlbmRvcjoJSGV3bGV0 dC1QYWNrYXJkIENvbXBhbnkKU0RldmljZToJRGV2aWNlIDJhNmUKUmV2OglhMgoKU2xvdDoJMDA6 MDEuMQpDbGFzczoJU01CdXMKVmVuZG9yOgluVmlkaWEgQ29ycG9yYXRpb24KRGV2aWNlOglNQ1A3 OFMgW0dlRm9yY2UgODIwMF0gU01CdXMKU1ZlbmRvcjoJSGV3bGV0dC1QYWNrYXJkIENvbXBhbnkK U0RldmljZToJRGV2aWNlIDJhNmUKUmV2OglhMQoKU2xvdDoJMDA6MDEuMgpDbGFzczoJUkFNIG1l bW9yeQpWZW5kb3I6CW5WaWRpYSBDb3Jwb3JhdGlvbgpEZXZpY2U6CU1DUDc4UyBbR2VGb3JjZSA4 MjAwXSBNZW1vcnkgQ29udHJvbGxlcgpTVmVuZG9yOglIZXdsZXR0LVBhY2thcmQgQ29tcGFueQpT RGV2aWNlOglEZXZpY2UgMmE2ZQpSZXY6CWExCgpTbG90OgkwMDowMS4zCkNsYXNzOglDby1wcm9j ZXNzb3IKVmVuZG9yOgluVmlkaWEgQ29ycG9yYXRpb24KRGV2aWNlOglNQ1A3OFMgW0dlRm9yY2Ug ODIwMF0gQ28tUHJvY2Vzc29yClNWZW5kb3I6CUhld2xldHQtUGFja2FyZCBDb21wYW55ClNEZXZp Y2U6CURldmljZSAyYTZlClJldjoJYTIKClNsb3Q6CTAwOjAxLjQKQ2xhc3M6CVJBTSBtZW1vcnkK VmVuZG9yOgluVmlkaWEgQ29ycG9yYXRpb24KRGV2aWNlOglNQ1A3OFMgW0dlRm9yY2UgODIwMF0g TWVtb3J5IENvbnRyb2xsZXIKU1ZlbmRvcjoJSGV3bGV0dC1QYWNrYXJkIENvbXBhbnkKU0Rldmlj ZToJRGV2aWNlIDJhNmUKUmV2OglhMQoKU2xvdDoJMDA6MDIuMApDbGFzczoJVVNCIENvbnRyb2xs ZXIKVmVuZG9yOgluVmlkaWEgQ29ycG9yYXRpb24KRGV2aWNlOglNQ1A3OFMgW0dlRm9yY2UgODIw MF0gT0hDSSBVU0IgMS4xIENvbnRyb2xsZXIKU1ZlbmRvcjoJSGV3bGV0dC1QYWNrYXJkIENvbXBh bnkKU0RldmljZToJRGV2aWNlIDJhNmUKUmV2OglhMQpQcm9nSWY6CTEwCgpTbG90OgkwMDowMi4x CkNsYXNzOglVU0IgQ29udHJvbGxlcgpWZW5kb3I6CW5WaWRpYSBDb3Jwb3JhdGlvbgpEZXZpY2U6 CU1DUDc4UyBbR2VGb3JjZSA4MjAwXSBFSENJIFVTQiAyLjAgQ29udHJvbGxlcgpTVmVuZG9yOglI ZXdsZXR0LVBhY2thcmQgQ29tcGFueQpTRGV2aWNlOglEZXZpY2UgMmE2ZQpSZXY6CWExClByb2dJ ZjoJMjAKClNsb3Q6CTAwOjA0LjAKQ2xhc3M6CVVTQiBDb250cm9sbGVyClZlbmRvcjoJblZpZGlh IENvcnBvcmF0aW9uCkRldmljZToJTUNQNzhTIFtHZUZvcmNlIDgyMDBdIE9IQ0kgVVNCIDEuMSBD b250cm9sbGVyClNWZW5kb3I6CUhld2xldHQtUGFja2FyZCBDb21wYW55ClNEZXZpY2U6CURldmlj ZSAyYTZlClJldjoJYTEKUHJvZ0lmOgkxMAoKU2xvdDoJMDA6MDQuMQpDbGFzczoJVVNCIENvbnRy b2xsZXIKVmVuZG9yOgluVmlkaWEgQ29ycG9yYXRpb24KRGV2aWNlOglNQ1A3OFMgW0dlRm9yY2Ug ODIwMF0gRUhDSSBVU0IgMi4wIENvbnRyb2xsZXIKU1ZlbmRvcjoJSGV3bGV0dC1QYWNrYXJkIENv bXBhbnkKU0RldmljZToJRGV2aWNlIDJhNmUKUmV2OglhMQpQcm9nSWY6CTIwCgpTbG90OgkwMDow Ny4wCkNsYXNzOglBdWRpbyBkZXZpY2UKVmVuZG9yOgluVmlkaWEgQ29ycG9yYXRpb24KRGV2aWNl OglSZWFsdGVrIEFMQzEyMDAgOC1DaGFubmVsIEhpZ2ggRGVmaW5pdGlvbiBBdWRpbyBDb2RlYwpT VmVuZG9yOglIZXdsZXR0LVBhY2thcmQgQ29tcGFueQpTRGV2aWNlOglEZXZpY2UgMmE2ZQpSZXY6 CWExCgpTbG90OgkwMDowOC4wCkNsYXNzOglQQ0kgYnJpZGdlClZlbmRvcjoJblZpZGlhIENvcnBv cmF0aW9uCkRldmljZToJTUNQNzhTIFtHZUZvcmNlIDgyMDBdIFBDSSBCcmlkZ2UKUmV2OglhMQpQ cm9nSWY6CTAxCgpTbG90OgkwMDowOS4wCkNsYXNzOglSQUlEIGJ1cyBjb250cm9sbGVyClZlbmRv cjoJblZpZGlhIENvcnBvcmF0aW9uCkRldmljZToJRGV2aWNlIDBhZDgKU1ZlbmRvcjoJSGV3bGV0 dC1QYWNrYXJkIENvbXBhbnkKU0RldmljZToJRGV2aWNlIDJhNmUKUmV2OglhMgoKU2xvdDoJMDA6 MGEuMApDbGFzczoJRXRoZXJuZXQgY29udHJvbGxlcgpWZW5kb3I6CW5WaWRpYSBDb3Jwb3JhdGlv bgpEZXZpY2U6CU1DUDc4UyBbR2VGb3JjZSA4MjAwXSBFdGhlcm5ldApTVmVuZG9yOglIZXdsZXR0 LVBhY2thcmQgQ29tcGFueQpTRGV2aWNlOglEZXZpY2UgMmE2ZQpSZXY6CWEyCgpTbG90OgkwMDox MC4wCkNsYXNzOglQQ0kgYnJpZGdlClZlbmRvcjoJblZpZGlhIENvcnBvcmF0aW9uCkRldmljZToJ TUNQNzhTIFtHZUZvcmNlIDgyMDBdIFBDSSBFeHByZXNzIEJyaWRnZQpSZXY6CWExCgpTbG90Ogkw MDoxMi4wCkNsYXNzOglQQ0kgYnJpZGdlClZlbmRvcjoJblZpZGlhIENvcnBvcmF0aW9uCkRldmlj ZToJTUNQNzhTIFtHZUZvcmNlIDgyMDBdIFBDSSBFeHByZXNzIEJyaWRnZQpSZXY6CWExCgpTbG90 OgkwMDoxMy4wCkNsYXNzOglQQ0kgYnJpZGdlClZlbmRvcjoJblZpZGlhIENvcnBvcmF0aW9uCkRl dmljZToJTUNQNzhTIFtHZUZvcmNlIDgyMDBdIFBDSSBCcmlkZ2UKUmV2OglhMQoKU2xvdDoJMDA6 MTQuMApDbGFzczoJUENJIGJyaWRnZQpWZW5kb3I6CW5WaWRpYSBDb3Jwb3JhdGlvbgpEZXZpY2U6 CU1DUDc4UyBbR2VGb3JjZSA4MjAwXSBQQ0kgQnJpZGdlClJldjoJYTEKClNsb3Q6CTAwOjE4LjAK Q2xhc3M6CUhvc3QgYnJpZGdlClZlbmRvcjoJQWR2YW5jZWQgTWljcm8gRGV2aWNlcyBbQU1EXQpE ZXZpY2U6CUZhbWlseSAxMGggW09wdGVyb24sIEF0aGxvbjY0LCBTZW1wcm9uXSBIeXBlclRyYW5z cG9ydCBDb25maWd1cmF0aW9uCgpTbG90OgkwMDoxOC4xCkNsYXNzOglIb3N0IGJyaWRnZQpWZW5k b3I6CUFkdmFuY2VkIE1pY3JvIERldmljZXMgW0FNRF0KRGV2aWNlOglGYW1pbHkgMTBoIFtPcHRl cm9uLCBBdGhsb242NCwgU2VtcHJvbl0gQWRkcmVzcyBNYXAKClNsb3Q6CTAwOjE4LjIKQ2xhc3M6 CUhvc3QgYnJpZGdlClZlbmRvcjoJQWR2YW5jZWQgTWljcm8gRGV2aWNlcyBbQU1EXQpEZXZpY2U6 CUZhbWlseSAxMGggW09wdGVyb24sIEF0aGxvbjY0LCBTZW1wcm9uXSBEUkFNIENvbnRyb2xsZXIK ClNsb3Q6CTAwOjE4LjMKQ2xhc3M6CUhvc3QgYnJpZGdlClZlbmRvcjoJQWR2YW5jZWQgTWljcm8g RGV2aWNlcyBbQU1EXQpEZXZpY2U6CUZhbWlseSAxMGggW09wdGVyb24sIEF0aGxvbjY0LCBTZW1w cm9uXSBNaXNjZWxsYW5lb3VzIENvbnRyb2wKClNsb3Q6CTAwOjE4LjQKQ2xhc3M6CUhvc3QgYnJp ZGdlClZlbmRvcjoJQWR2YW5jZWQgTWljcm8gRGV2aWNlcyBbQU1EXQpEZXZpY2U6CUZhbWlseSAx MGggW09wdGVyb24sIEF0aGxvbjY0LCBTZW1wcm9uXSBMaW5rIENvbnRyb2wKClNsb3Q6CTAxOjA1 LjAKQ2xhc3M6CUZpcmVXaXJlIChJRUVFIDEzOTQpClZlbmRvcjoJQWdlcmUgU3lzdGVtcwpEZXZp Y2U6CUZXMzIzClNWZW5kb3I6CUhld2xldHQtUGFja2FyZCBDb21wYW55ClNEZXZpY2U6CURldmlj ZSAyYTZlClJldjoJNzAKUHJvZ0lmOgkxMAoKU2xvdDoJMDI6MDAuMApDbGFzczoJVkdBIGNvbXBh dGlibGUgY29udHJvbGxlcgpWZW5kb3I6CW5WaWRpYSBDb3Jwb3JhdGlvbgpEZXZpY2U6CURldmlj ZSAwNmUwClNWZW5kb3I6CVVua25vd24gdmVuZG9yIDFiMGEKU0RldmljZToJRGV2aWNlIDkwMDQK UmV2OglhMQoKU2xvdDoJMDQ6MDAuMApDbGFzczoJQ29tbXVuaWNhdGlvbiBjb250cm9sbGVyClZl bmRvcjoJQ29uZXhhbnQgU3lzdGVtcywgSW5jLgpEZXZpY2U6CURldmljZSAyZjgyClNWZW5kb3I6 CUNvbmV4YW50IFN5c3RlbXMsIEluYy4KU0RldmljZToJRGV2aWNlIDAwMDAKCg== --MP_/uxkKrGOcbHvWrQ.4JxzZG1R Content-Type: application/octet-stream; name=linux.lspci.vvxxx Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=linux.lspci.vvxxx MDA6MDAuMCBSQU0gbWVtb3J5OiBuVmlkaWEgQ29ycG9yYXRpb24gTUNQNzhTIFtHZUZvcmNlIDgy MDBdIE1lbW9yeSBDb250cm9sbGVyIChyZXYgYTIpCglTdWJzeXN0ZW06IEhld2xldHQtUGFja2Fy ZCBDb21wYW55IERldmljZSAyYTZlCglDb250cm9sOiBJL08tIE1lbSsgQnVzTWFzdGVyKyBTcGVj Q3ljbGUtIE1lbVdJTlYtIFZHQVNub29wLSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJSLSBGYXN0QjJC LSBEaXNJTlR4LQoJU3RhdHVzOiBDYXArIDY2TUh6KyBVREYtIEZhc3RCMkIrIFBhckVyci0gREVW U0VMPWZhc3QgPlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydC0gPlNFUlItIDxQRVJSLSBJTlR4LQoJ TGF0ZW5jeTogMAoJQ2FwYWJpbGl0aWVzOiBbOTRdIEh5cGVyVHJhbnNwb3J0OiAjMWEKCUNhcGFi aWxpdGllczogWzYwXSBIeXBlclRyYW5zcG9ydDogUmV0cnkgTW9kZQoJQ2FwYWJpbGl0aWVzOiBb NDRdIEh5cGVyVHJhbnNwb3J0OiBTbGF2ZSBvciBQcmltYXJ5IEludGVyZmFjZQoJCUNvbW1hbmQ6 IEJhc2VVbml0SUQ9MCBVbml0Q250PTAgTWFzdEhvc3QtIERlZkRpci0gRFVMLQoJCUxpbmsgQ29u dHJvbCAwOiBDRmxFLSBDU1QtIENGRS0gPExrRmFpbC0gSW5pdCsgRU9DLSBUWE8tIDxDUkNFcnI9 MCBJc29jRW4tIExTRW4tIEV4dENUTC0gNjRiLQoJCUxpbmsgQ29uZmlnIDA6IE1MV0k9MTZiaXQg RHdGY0luLSBNTFdPPTE2Yml0IER3RmNPdXQtIExXST0xNmJpdCBEd0ZjSW5Fbi0gTFdPPTE2Yml0 IER3RmNPdXRFbi0KCQlMaW5rIENvbnRyb2wgMTogQ0ZsRS0gQ1NULSBDRkUtIDxMa0ZhaWwrIElu aXQtIEVPQysgVFhPKyA8Q1JDRXJyPTAgSXNvY0VuLSBMU0VuLSBFeHRDVEwtIDY0Yi0KCQlMaW5r IENvbmZpZyAxOiBNTFdJPThiaXQgRHdGY0luLSBNTFdPPThiaXQgRHdGY091dC0gTFdJPThiaXQg RHdGY0luRW4tIExXTz04Yml0IER3RmNPdXRFbi0KCQlSZXZpc2lvbiBJRDogMy4wMAoJCUxpbmsg RnJlcXVlbmN5IDA6IFthXQoJCUxpbmsgRXJyb3IgMDogPFByb3QtIDxPdmZsLSA8RU9DLSBDVExU bS0KCQlMaW5rIEZyZXF1ZW5jeSBDYXBhYmlsaXR5IDA6IDIwME1IeisgMzAwTUh6LSA0MDBNSHor IDUwME1Iei0gNjAwTUh6KyA4MDBNSHorIDEuMEdIeisgMS4yR0h6KyAxLjRHSHotIDEuNkdIei0g VmVuZC0KCQlGZWF0dXJlIENhcGFiaWxpdHk6IElzb2NGQysgTERUU1RPUCsgQ1JDVE0tIEVDVExU LSA2NGJBLSBVSURSRCsKCQlMaW5rIEZyZXF1ZW5jeSAxOiAyMDBNSHoKCQlMaW5rIEVycm9yIDE6 IDxQcm90LSA8T3ZmbC0gPEVPQy0gQ1RMVG0tCgkJTGluayBGcmVxdWVuY3kgQ2FwYWJpbGl0eSAx OiAyMDBNSHotIDMwME1Iei0gNDAwTUh6LSA1MDBNSHotIDYwME1Iei0gODAwTUh6LSAxLjBHSHot IDEuMkdIei0gMS40R0h6LSAxLjZHSHotIFZlbmQtCgkJRXJyb3IgSGFuZGxpbmc6IFBGbEUtIE9G bEUtIFBGRS0gT0ZFLSBFT0NGRS0gUkZFLSBDUkNGRS0gU0VSUkZFLSBDRi0gUkUtIFBORkUtIE9O RkUtIEVPQ05GRS0gUk5GRS0gQ1JDTkZFLSBTRVJSTkZFLQoJCVByZWZldGNoYWJsZSBtZW1vcnkg YmVoaW5kIGJyaWRnZSBVcHBlcjogMDAtMDAKCQlCdXMgTnVtYmVyOiAwMAoJQ2FwYWJpbGl0aWVz OiBbZDBdIEh5cGVyVHJhbnNwb3J0OiAjMWMKMDA6IGRlIDEwIDU0IDA3IDA2IDAwIGIwIDAwIGEy IDAwIDAwIDA1IDAwIDAwIDAwIDAwCjEwOiAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAw MCAwMCAwMCAwMCAwMCAwMAoyMDogMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAg M2MgMTAgNmUgMmEKMzA6IDAwIDAwIDAwIDAwIDk0IDAwIDAwIDAwIDAwIDAwIDAwIDAwIGZmIDAw IDAwIDAwCjQwOiAzYyAxMCA2ZSAyYSAwOCBkMCAwMCAwMCAyMCAwMCAxMSAxMSBkMCAwMCAwMCAw MAo1MDogNjAgMGEgZjUgN2YgNjMgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAKNjA6 IDA4IDQ0IDAwIGMwIGMxIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDA2IDg2IDAwIDExCjcwOiA5MiAy NCAwMSAwMCBkMCAwOSAwMCAwMCAyMSAwMCAwMCAwMCAwMCAwMCA0MCAwOAo4MDogMGMgODYgN2Qg MWYgNjQgMTQgMTIgMDAgMjAgMDAgMDAgMjAgZjUgN2YgMTEgMGUKOTA6IDc4IDAwIDAwIGEwIDA4 IDYwIDA3IGQwIDIxIDAwIDAwIDAwIDAwIDAwIDAwIDAwCmEwOiAwMCAwMCAwMCAwMCA3OSA4MCAw MCAwMCAwMCAwMCAwMCAwMCAyYiAzMiAwMCAzYQpiMDogMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAg MTAgMDAgMDAgMDAgMDAgMDAgMDAgMDAKYzA6IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAw IDAwIDAwIDAwIDAwIDAwIDAwCmQwOiAwOCAwMCAwMCBlMCAzZiAwMCAwMCAwMCAwMCAwMCAwMCAw MCAwMCAwMCAwMCAwMAplMDogMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAg MDAgMDAgMDAKZjA6IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAw IDAwCgowMDowMS4wIElTQSBicmlkZ2U6IG5WaWRpYSBDb3Jwb3JhdGlvbiBNQ1A3OFMgW0dlRm9y Y2UgODIwMF0gTFBDIEJyaWRnZSAocmV2IGEyKQoJU3Vic3lzdGVtOiBIZXdsZXR0LVBhY2thcmQg Q29tcGFueSBEZXZpY2UgMmE2ZQoJQ29udHJvbDogSS9PKyBNZW0rIEJ1c01hc3RlcisgU3BlY0N5 Y2xlKyBNZW1XSU5WLSBWR0FTbm9vcC0gUGFyRXJyLSBTdGVwcGluZy0gU0VSUi0gRmFzdEIyQi0g RGlzSU5UeC0KCVN0YXR1czogQ2FwLSA2Nk1IeisgVURGLSBGYXN0QjJCKyBQYXJFcnItIERFVlNF TD1mYXN0ID5UQWJvcnQtIDxUQWJvcnQtIDxNQWJvcnQtID5TRVJSLSA8UEVSUi0gSU5UeC0KCUxh dGVuY3k6IDAKCVJlZ2lvbiAwOiBJL08gcG9ydHMgYXQgMmYwMCBbc2l6ZT0yNTZdCjAwOiBkZSAx MCA1YyAwNyAwZiAwMCBhMCAwMCBhMiAwMCAwMSAwNiAwMCAwMCA4MCAwMAoxMDogMDEgMmYgMDAg MDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAKMjA6IDAwIDAwIDAwIDAwIDAw IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDNjIDEwIDZlIDJhCjMwOiAwMCAwMCAwMCAwMCAwMCAwMCAw MCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMAo0MDogM2MgMTAgNmUgMmEgMDAgMDAgZDAgZmUg ZmEgM2UgZmYgMDAgZmEgM2UgZmYgMDAKNTA6IGZhIDNlIGZmIDAwIDAwIDVhIDYyIDAyIDAwIDAw IDAwIDA1IDM3IDAwIDVjIDAxCjYwOiAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAw MCAwOCAwMCAwMCAwMAo3MDogMTAgMDAgZmYgZmYgNDUgODAgMTcgMDAgMDAgMDAgNDQgNTkgMDAg MDAgMDAgMDAKODA6IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDQwIDAzIGZmIDAwIGFh IGFhCjkwOiBmZiA3ZiAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMAph MDogMDMgMDAgMTAgODEgMDAgMDAgMDEgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAKYjA6IDAw IDAwIDAwIDAwIDAwIDBhIDdmIDBhIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwCmMwOiAwMCAwMCAw MCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMApkMDogMDAgMDAgMDAgMDAg MDAgMDAgMDAgMDAgMGMgODAgZTcgZjkgMDAgMzMgMDAgNjAKZTA6IDQxIDIwIGU2IDI0IDMwIDRh IDkzIDU2IDBhIDU4IDk3IDJjIDAwIDAwIDAwIDAwCmYwOiA4MCAwMCAwMCBmYyBmZCAwMCAwMCAw MCAxMCAwMCA4MCA4MCAwMCAwMCAwMCAwMAoKMDA6MDEuMSBTTUJ1czogblZpZGlhIENvcnBvcmF0 aW9uIE1DUDc4UyBbR2VGb3JjZSA4MjAwXSBTTUJ1cyAocmV2IGExKQoJU3Vic3lzdGVtOiBIZXds ZXR0LVBhY2thcmQgQ29tcGFueSBEZXZpY2UgMmE2ZQoJQ29udHJvbDogSS9PKyBNZW0tIEJ1c01h c3Rlci0gU3BlY0N5Y2xlLSBNZW1XSU5WLSBWR0FTbm9vcC0gUGFyRXJyLSBTdGVwcGluZy0gU0VS Ui0gRmFzdEIyQi0gRGlzSU5UeC0KCVN0YXR1czogQ2FwKyA2Nk1IeisgVURGLSBGYXN0QjJCKyBQ YXJFcnItIERFVlNFTD1mYXN0ID5UQWJvcnQtIDxUQWJvcnQtIDxNQWJvcnQtID5TRVJSLSA8UEVS Ui0gSU5UeC0KCUludGVycnVwdDogcGluIEEgcm91dGVkIHRvIElSUSA3CglSZWdpb24gMDogSS9P IHBvcnRzIGF0IDI5MDAgW3NpemU9NjRdCglSZWdpb24gNDogSS9PIHBvcnRzIGF0IDJkMDAgW3Np emU9NjRdCglSZWdpb24gNTogSS9PIHBvcnRzIGF0IDJlMDAgW3NpemU9NjRdCglDYXBhYmlsaXRp ZXM6IFs0NF0gUG93ZXIgTWFuYWdlbWVudCB2ZXJzaW9uIDIKCQlGbGFnczogUE1FQ2xrLSBEU0kt IEQxLSBEMi0gQXV4Q3VycmVudD0wbUEgUE1FKEQwLSxEMS0sRDItLEQzaG90KyxEM2NvbGQrKQoJ CVN0YXR1czogRDAgUE1FLUVuYWJsZS0gRFNlbD0wIERTY2FsZT0wIFBNRS0KMDA6IGRlIDEwIDUy IDA3IDAxIDAwIGIwIDAwIGExIDAwIDA1IDBjIDAwIDAwIDgwIDAwCjEwOiAwMSAyOSAwMCAwMCAw MCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMAoyMDogMDEgMmQgMDAgMDAgMDEgMmUg MDAgMDAgMDAgMDAgMDAgMDAgM2MgMTAgNmUgMmEKMzA6IDAwIDAwIDAwIDAwIDQ0IDAwIDAwIDAw IDAwIDAwIDAwIDAwIDA3IDAxIDAwIDAwCjQwOiAzYyAxMCA2ZSAyYSAwMSAwMCAwMiBjMCAwMCAw MCAwMCAwMCA2YSA5NiAwMCAwMAo1MDogMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAg MDAgMDAgMDAgMDAgMDAKNjA6IDAxIDIwIDAwIDAwIDAxIDI0IDAwIDAwIDAxIDI4IDAwIDAwIDAw IDAwIDAwIDAwCjcwOiAwMCAwMCAwMCAwMCAwMCAwMCBlOCBmOSAwMCAwMCAwMCAwMCAwMSAwMCAw MCAwMAo4MDogMDAgNDAgZDAgZmUgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAK OTA6IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwCmEwOiBh MCAwMSAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMApiMDogMDAgMDAg MDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAKYzA6IGQ0IDMwIDgwIDAx IDAxIDAwIDAwIDAwIDIwIDgyIDA4IDAyIDBkIDBkIDE5IDE5CmQwOiBjMCA2YyBjMCAwMCAxMCAw MCAwMSAwMCAwNSAwMCAwMCAwMCAwMCAwMCAwMCAwMAplMDogMDggMTAgMDQgMTAgMjAgNDYgMjAg MDcgODAgNjAgMDAgMDAgNDEgNDQgNDQgMDAKZjA6IDdhIGZmIDNkIDY3IGE3IGFmIDliIGY4IDEw IDAwIDgwIDgwIDAwIDAwIDAwIDAwCgowMDowMS4yIFJBTSBtZW1vcnk6IG5WaWRpYSBDb3Jwb3Jh dGlvbiBNQ1A3OFMgW0dlRm9yY2UgODIwMF0gTWVtb3J5IENvbnRyb2xsZXIgKHJldiBhMSkKCVN1 YnN5c3RlbTogSGV3bGV0dC1QYWNrYXJkIENvbXBhbnkgRGV2aWNlIDJhNmUKCUNvbnRyb2w6IEkv Ty0gTWVtLSBCdXNNYXN0ZXItIFNwZWNDeWNsZS0gTWVtV0lOVi0gVkdBU25vb3AtIFBhckVyci0g U3RlcHBpbmctIFNFUlItIEZhc3RCMkItIERpc0lOVHgrCglTdGF0dXM6IENhcC0gNjZNSHorIFVE Ri0gRmFzdEIyQisgUGFyRXJyLSBERVZTRUw9ZmFzdCA+VEFib3J0LSA8VEFib3J0LSA8TUFib3J0 LSA+U0VSUi0gPFBFUlItIElOVHgtCjAwOiBkZSAxMCA1MSAwNyAwMCAwNCBhMCAwMCBhMSAwMCAw MCAwNSAwMCAwMCA4MCAwMAoxMDogMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAg MDAgMDAgMDAgMDAKMjA6IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDNjIDEw IDZlIDJhCjMwOiAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAw MAo0MDogM2MgMTAgNmUgMmEgMDAgMDAgMDAgMDAgMTAgMDIgODAgMTAgMTAgMDIgMTAgMTAKNTA6 IDEwIDEwIDEwIDEwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDEwIDQyIDAwIDAwCjYwOiAwMCAw MCAwMCAwMCAwMCAwMSAwMCAwMSAwMyAwMSAwMSAwMiAwMSAwMSAwMiAwMQo3MDogMDEgMDAgMDAg MDAgMDAgMDAgMDAgMDAgMGIgMGEgMDUgMDAgMDMgMGQgMDAgMDAKODA6IDAxIDAwIDA2IDAwIDAw IDA0IDBhIDAzIDA0IDAwIDAwIDAwIDAwIDAwIDAwIDAwCjkwOiAwMSAwMCAwMCAwMCAwMCAwMCAw MCAwMCAwMCAwNCAwYiAxYyAwMCAwMCAwMCAwMAphMDogMDUgMDAgMDAgMDAgMDAgMTEgMGIgMGMg MDAgMDEgMDAgMDAgMGYgMDAgMDAgMDAKYjA6IDAwIDAwIDAwIDAwIDEyIDEyIDEyIDEyIDEyIDEy IDAxIDAxIDBhIDBjIDA1IDA2CmMwOiAwNSAwNSAwNSAwNSAwNSAwZSAwZSAwYyAwZSAwZSAwZiAw OCAwOSAwOSAwOCAwOApkMDogMDggMGUgMGQgMGQgMGQgMGQgMGYgMDAgMTIgMTIgMTIgMTIgMTIg MTIgMTIgMTIKZTA6IDEyIDEyIDEyIDEyIDEyIDEyIDEyIDEyIDA0IDAyIDE2IDBiIDBjIDEwIDBl IDBkCmYwOiAxMCAxMSAxNyAwZSAwZSAwOCAwOCAwMCAwMSAwMSAwMSAwMCAwMiAwMSAxMCAwMQoK MDA6MDEuMyBDby1wcm9jZXNzb3I6IG5WaWRpYSBDb3Jwb3JhdGlvbiBNQ1A3OFMgW0dlRm9yY2Ug ODIwMF0gQ28tUHJvY2Vzc29yIChyZXYgYTIpCglTdWJzeXN0ZW06IEhld2xldHQtUGFja2FyZCBD b21wYW55IERldmljZSAyYTZlCglDb250cm9sOiBJL08tIE1lbSsgQnVzTWFzdGVyKyBTcGVjQ3lj bGUtIE1lbVdJTlYtIFZHQVNub29wLSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJSLSBGYXN0QjJCLSBE aXNJTlR4LQoJU3RhdHVzOiBDYXAtIDY2TUh6KyBVREYtIEZhc3RCMkIrIFBhckVyci0gREVWU0VM PWZhc3QgPlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydC0gPlNFUlItIDxQRVJSLSBJTlR4LQoJTGF0 ZW5jeTogMCAoNzUwbnMgbWluLCAyNTBucyBtYXgpCglJbnRlcnJ1cHQ6IHBpbiBCIHJvdXRlZCB0 byBJUlEgMTAKCVJlZ2lvbiAwOiBNZW1vcnkgYXQgZjllODAwMDAgKDMyLWJpdCwgbm9uLXByZWZl dGNoYWJsZSkgW3NpemU9NTEyS10KMDA6IGRlIDEwIDUzIDA3IDA2IDAwIGEwIDAwIGEyIDAwIDQw IDBiIDAwIDAwIDgwIDAwCjEwOiAwMCAwMCBlOCBmOSAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAw MCAwMCAwMCAwMAoyMDogMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgM2MgMTAg NmUgMmEKMzA6IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDBhIDAyIDAzIDAx CjQwOiAzYyAxMCA2ZSAyYSAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMAo1MDog MDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAKNjA6IDAwIDAw IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwCjcwOiAwMCAwMCAwMCAw MCAwMCAwMCBlOCBmOSAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMAo4MDogMDUgOWMgODAgMDEgMDAg MDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAKOTA6IDAwIDAwIDAwIDAwIDAwIDAwIDAw IDAwIDAwIDAwIDAwIDAwIDA4IDAwIDAyIGE4CmEwOiAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAw MCAwMCAwMCAwMCAwMCAwMCAwMCAwMApiMDogMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAg MDAgMDAgMDAgMDAgMDAgMDAKYzA6IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAw IDAwIDAwIDAwIDAwCmQwOiAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAw MCAwMCAwMAplMDogMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAg MDAKZjA6IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwCgow MDowMS40IFJBTSBtZW1vcnk6IG5WaWRpYSBDb3Jwb3JhdGlvbiBNQ1A3OFMgW0dlRm9yY2UgODIw MF0gTWVtb3J5IENvbnRyb2xsZXIgKHJldiBhMSkKCVN1YnN5c3RlbTogSGV3bGV0dC1QYWNrYXJk IENvbXBhbnkgRGV2aWNlIDJhNmUKCUNvbnRyb2w6IEkvTy0gTWVtLSBCdXNNYXN0ZXItIFNwZWND eWNsZS0gTWVtV0lOVi0gVkdBU25vb3AtIFBhckVyci0gU3RlcHBpbmctIFNFUlItIEZhc3RCMkIt IERpc0lOVHgrCglTdGF0dXM6IENhcC0gNjZNSHorIFVERi0gRmFzdEIyQisgUGFyRXJyLSBERVZT RUw9ZmFzdCA+VEFib3J0LSA8VEFib3J0LSA8TUFib3J0LSA+U0VSUi0gPFBFUlItIElOVHgtCjAw OiBkZSAxMCA2OCAwNSAwMCAwNCBhMCAwMCBhMSAwMCAwMCAwNSAwMCAwMCA4MCAwMAoxMDogMDAg MDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAKMjA6IDAwIDAwIDAw IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDNjIDEwIDZlIDJhCjMwOiAwMCAwMCAwMCAwMCAw MCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMAo0MDogM2MgMTAgNmUgMmEgMDAgMDAg MDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAKNTA6IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAw IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwCjYwOiAwMiAwMCAwMCAwMCAwMSAwMCAwMCAwMCAwMiAw ZCAwOCAwMSAwOSAwMCAwMCAwMAo3MDogMGQgMDAgMDAgMDAgMDAgMDAgMDAgMGMgMDAgMDAgMDAg MDAgMGMgMDAgMDAgMDAKODA6IDAwIDAwIDAwIDAwIDA2IDAwIDAwIDAwIDA0IDAwIDAwIDAwIDAz IDAwIDAwIDAwCjkwOiAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAw MCAwMAphMDogMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAK YjA6IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwCmMwOiAw MCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMApkMDogMDAgMDAg MDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgODAgMDAgMDAKZTA6IDAwIDAwIDAwIDAw IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwCmYwOiAwMCAwMCAwMCAwMCAwMCAw MCAwMCAwMCBmYyAwYyAwMCAwMCAwMCAwMCAwMCAwMAoKMDA6MDIuMCBVU0IgQ29udHJvbGxlcjog blZpZGlhIENvcnBvcmF0aW9uIE1DUDc4UyBbR2VGb3JjZSA4MjAwXSBPSENJIFVTQiAxLjEgQ29u dHJvbGxlciAocmV2IGExKSAocHJvZy1pZiAxMCkKCVN1YnN5c3RlbTogSGV3bGV0dC1QYWNrYXJk IENvbXBhbnkgRGV2aWNlIDJhNmUKCUNvbnRyb2w6IEkvTysgTWVtKyBCdXNNYXN0ZXIrIFNwZWND eWNsZS0gTWVtV0lOVi0gVkdBU25vb3AtIFBhckVyci0gU3RlcHBpbmctIFNFUlItIEZhc3RCMkIt IERpc0lOVHgtCglTdGF0dXM6IENhcCsgNjZNSHorIFVERi0gRmFzdEIyQisgUGFyRXJyLSBERVZT RUw9ZmFzdCA+VEFib3J0LSA8VEFib3J0LSA8TUFib3J0LSA+U0VSUi0gPFBFUlItIElOVHgtCglM YXRlbmN5OiAwICg3NTBucyBtaW4sIDI1MG5zIG1heCkKCUludGVycnVwdDogcGluIEEgcm91dGVk IHRvIElSUSAyMgoJUmVnaW9uIDA6IE1lbW9yeSBhdCBmOWU3ZjAwMCAoMzItYml0LCBub24tcHJl ZmV0Y2hhYmxlKSBbc2l6ZT00S10KCUNhcGFiaWxpdGllczogWzQ0XSBQb3dlciBNYW5hZ2VtZW50 IHZlcnNpb24gMgoJCUZsYWdzOiBQTUVDbGstIERTSS0gRDErIEQyKyBBdXhDdXJyZW50PTBtQSBQ TUUoRDArLEQxKyxEMissRDNob3QrLEQzY29sZCspCgkJU3RhdHVzOiBEMCBQTUUtRW5hYmxlLSBE U2VsPTAgRFNjYWxlPTAgUE1FLQoJS2VybmVsIGRyaXZlciBpbiB1c2U6IG9oY2lfaGNkCglLZXJu ZWwgbW9kdWxlczogb2hjaS1oY2QKMDA6IGRlIDEwIDdiIDA3IDA3IDAwIGIwIDAwIGExIDEwIDAz IDBjIDAwIDAwIDgwIDAwCjEwOiAwMCBmMCBlNyBmOSAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAw MCAwMCAwMCAwMAoyMDogMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgM2MgMTAg NmUgMmEKMzA6IDAwIDAwIDAwIDAwIDQ0IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDBiIDAxIDAzIDAx CjQwOiAzYyAxMCA2ZSAyYSAwMSAwMCAwMiBmZSAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMAo1MDog MDAgMDAgMDAgMDAgMWQgNDcgNDAgMDAgMTAgMDAgMDAgMDAgMTAgMDAgMWYgMDMKNjA6IDAwIDAw IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwCjcwOiAwMCAwMCAwMCAw MCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMAo4MDogMDAgMDAgMDAgMDAgMDAg MDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAKOTA6IDAwIDAwIDAwIDAwIDAwIDAwIDAw IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwCmEwOiAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAw MCAwMCAwMCAwMCAwMCAwMCAwMCAwMApiMDogMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAg MDAgMDAgMDAgMDAgMDAgMDAKYzA6IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAw IDAwIDAwIDAwIDAwCmQwOiAwMiAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAw MCAwMCAwMAplMDogMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAg MDAKZjA6IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIGMwIDgwIDAwIDAwIDAwIDAwCgow MDowMi4xIFVTQiBDb250cm9sbGVyOiBuVmlkaWEgQ29ycG9yYXRpb24gTUNQNzhTIFtHZUZvcmNl IDgyMDBdIEVIQ0kgVVNCIDIuMCBDb250cm9sbGVyIChyZXYgYTEpIChwcm9nLWlmIDIwKQoJU3Vi c3lzdGVtOiBIZXdsZXR0LVBhY2thcmQgQ29tcGFueSBEZXZpY2UgMmE2ZQoJQ29udHJvbDogSS9P LSBNZW0rIEJ1c01hc3RlcisgU3BlY0N5Y2xlLSBNZW1XSU5WLSBWR0FTbm9vcC0gUGFyRXJyLSBT dGVwcGluZy0gU0VSUi0gRmFzdEIyQi0gRGlzSU5UeC0KCVN0YXR1czogQ2FwKyA2Nk1IeisgVURG LSBGYXN0QjJCKyBQYXJFcnItIERFVlNFTD1mYXN0ID5UQWJvcnQtIDxUQWJvcnQtIDxNQWJvcnQt ID5TRVJSLSA8UEVSUi0gSU5UeC0KCUxhdGVuY3k6IDAgKDc1MG5zIG1pbiwgMjUwbnMgbWF4KQoJ SW50ZXJydXB0OiBwaW4gQiByb3V0ZWQgdG8gSVJRIDIxCglSZWdpb24gMDogTWVtb3J5IGF0IGY5 ZTdlYzAwICgzMi1iaXQsIG5vbi1wcmVmZXRjaGFibGUpIFtzaXplPTI1Nl0KCUNhcGFiaWxpdGll czogWzQ0XSBEZWJ1ZyBwb3J0OiBCQVI9MSBvZmZzZXQ9MDBhMAoJQ2FwYWJpbGl0aWVzOiBbODBd IFBvd2VyIE1hbmFnZW1lbnQgdmVyc2lvbiAyCgkJRmxhZ3M6IFBNRUNsay0gRFNJLSBEMSsgRDIr IEF1eEN1cnJlbnQ9MG1BIFBNRShEMCssRDErLEQyKyxEM2hvdCssRDNjb2xkKykKCQlTdGF0dXM6 IEQwIFBNRS1FbmFibGUtIERTZWw9MCBEU2NhbGU9MCBQTUUtCglLZXJuZWwgZHJpdmVyIGluIHVz ZTogZWhjaV9oY2QKCUtlcm5lbCBtb2R1bGVzOiBlaGNpLWhjZAowMDogZGUgMTAgN2MgMDcgMDYg MDAgYjAgMDAgYTEgMjAgMDMgMGMgMDAgMDAgODAgMDAKMTA6IDAwIGVjIGU3IGY5IDAwIDAwIDAw IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwCjIwOiAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAw MCAwMCAwMCAwMCAzYyAxMCA2ZSAyYQozMDogMDAgMDAgMDAgMDAgNDQgMDAgMDAgMDAgMDAgMDAg MDAgMDAgMGYgMDIgMDMgMDEKNDA6IDNjIDEwIDZlIDJhIDBhIDgwIGEwIDIwIDAwIDAwIDAwIDAw IDAwIDAwIDAwIDAwCjUwOiAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAw MCAwMCAwMAo2MDogMjAgMjAgMDEgMDAgMDAgNjAgMTggODUgMDMgM2MgMGEgMDEgMDAgMDAgMDAg MDAKNzA6IDAwIDAxIDA4IDAwIDAwIDEwIDIwIDgwIDg5IDNkIGI2IDIyIDc3IDI1IGE0IDAwCjgw OiAwMSAwMCAwMiBmZSAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAxNSAxNiAwMCAwMAo5MDogMDAg MDEgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAKYTA6IDAxIDAwIDAw IDAwIDAwIDAwIDA4IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwCmIwOiAwMCAxMSAyMiAzMyA0 NCA0NCA0NCAwNCA1NSAwNSAwMCAwMCAwMCAwMCAwMCAwMApjMDogMTAgMTAgMmQgMGQgMDAgMDAg MDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAKZDA6IDAyIDAwIDAwIDAwIDAwIDAwIDAwIDAw IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwCmUwOiAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAw MCAwMCAwMCAwMCAwMCAwMCAwMApmMDogMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMTAgMDAgYzAg ODAgMDAgMDAgMDAgMDAKCjAwOjA0LjAgVVNCIENvbnRyb2xsZXI6IG5WaWRpYSBDb3Jwb3JhdGlv biBNQ1A3OFMgW0dlRm9yY2UgODIwMF0gT0hDSSBVU0IgMS4xIENvbnRyb2xsZXIgKHJldiBhMSkg KHByb2ctaWYgMTApCglTdWJzeXN0ZW06IEhld2xldHQtUGFja2FyZCBDb21wYW55IERldmljZSAy YTZlCglDb250cm9sOiBJL08rIE1lbSsgQnVzTWFzdGVyKyBTcGVjQ3ljbGUtIE1lbVdJTlYtIFZH QVNub29wLSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJSLSBGYXN0QjJCLSBEaXNJTlR4LQoJU3RhdHVz OiBDYXArIDY2TUh6KyBVREYtIEZhc3RCMkIrIFBhckVyci0gREVWU0VMPWZhc3QgPlRBYm9ydC0g PFRBYm9ydC0gPE1BYm9ydC0gPlNFUlItIDxQRVJSLSBJTlR4LQoJTGF0ZW5jeTogMCAoNzUwbnMg bWluLCAyNTBucyBtYXgpCglJbnRlcnJ1cHQ6IHBpbiBBIHJvdXRlZCB0byBJUlEgMjAKCVJlZ2lv biAwOiBNZW1vcnkgYXQgZjllN2QwMDAgKDMyLWJpdCwgbm9uLXByZWZldGNoYWJsZSkgW3NpemU9 NEtdCglDYXBhYmlsaXRpZXM6IFs0NF0gUG93ZXIgTWFuYWdlbWVudCB2ZXJzaW9uIDIKCQlGbGFn czogUE1FQ2xrLSBEU0ktIEQxKyBEMisgQXV4Q3VycmVudD0wbUEgUE1FKEQwKyxEMSssRDIrLEQz aG90KyxEM2NvbGQrKQoJCVN0YXR1czogRDAgUE1FLUVuYWJsZS0gRFNlbD0wIERTY2FsZT0wIFBN RS0KCUtlcm5lbCBkcml2ZXIgaW4gdXNlOiBvaGNpX2hjZAoJS2VybmVsIG1vZHVsZXM6IG9oY2kt aGNkCjAwOiBkZSAxMCA3ZCAwNyAwNyAwMCBiMCAwMCBhMSAxMCAwMyAwYyAwMCAwMCA4MCAwMAox MDogMDAgZDAgZTcgZjkgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAKMjA6IDAw IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDNjIDEwIDZlIDJhCjMwOiAwMCAwMCAw MCAwMCA0NCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwZSAwMSAwMyAwMQo0MDogM2MgMTAgNmUgMmEg MDEgMDAgMDIgZmUgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAKNTA6IDAwIDAwIDAwIDAwIDFkIDQ3 IDQwIDAwIDEwIDAwIDAwIDAwIDEwIDAwIDFmIDAzCjYwOiAwMCAwMCAwMCAwMCAwMCAwMCAwMCAw MCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMAo3MDogMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAg MDAgMDAgMDAgMDAgMDAgMDAgMDAKODA6IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAw IDAwIDAwIDAwIDAwIDAwCjkwOiAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAw MCAwMCAwMCAwMAphMDogMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAg MDAgMDAKYjA6IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAw CmMwOiAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMApkMDog MDIgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAKZTA6IDAwIDAw IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwCmYwOiAwMCAwMCAwMCAw MCAwMCAwMCAwMCAwMCAwMCAwMCBjMCA4MCAwMCAwMCAwMCAwMAoKMDA6MDQuMSBVU0IgQ29udHJv bGxlcjogblZpZGlhIENvcnBvcmF0aW9uIE1DUDc4UyBbR2VGb3JjZSA4MjAwXSBFSENJIFVTQiAy LjAgQ29udHJvbGxlciAocmV2IGExKSAocHJvZy1pZiAyMCkKCVN1YnN5c3RlbTogSGV3bGV0dC1Q YWNrYXJkIENvbXBhbnkgRGV2aWNlIDJhNmUKCUNvbnRyb2w6IEkvTy0gTWVtKyBCdXNNYXN0ZXIr IFNwZWNDeWNsZS0gTWVtV0lOVi0gVkdBU25vb3AtIFBhckVyci0gU3RlcHBpbmctIFNFUlItIEZh c3RCMkItIERpc0lOVHgtCglTdGF0dXM6IENhcCsgNjZNSHorIFVERi0gRmFzdEIyQisgUGFyRXJy LSBERVZTRUw9ZmFzdCA+VEFib3J0LSA8VEFib3J0LSA8TUFib3J0LSA+U0VSUi0gPFBFUlItIElO VHgtCglMYXRlbmN5OiAwICg3NTBucyBtaW4sIDI1MG5zIG1heCkKCUludGVycnVwdDogcGluIEIg cm91dGVkIHRvIElSUSAyMwoJUmVnaW9uIDA6IE1lbW9yeSBhdCBmOWU3ZTgwMCAoMzItYml0LCBu b24tcHJlZmV0Y2hhYmxlKSBbc2l6ZT0yNTZdCglDYXBhYmlsaXRpZXM6IFs0NF0gRGVidWcgcG9y dDogQkFSPTEgb2Zmc2V0PTAwYTAKCUNhcGFiaWxpdGllczogWzgwXSBQb3dlciBNYW5hZ2VtZW50 IHZlcnNpb24gMgoJCUZsYWdzOiBQTUVDbGstIERTSS0gRDErIEQyKyBBdXhDdXJyZW50PTBtQSBQ TUUoRDArLEQxKyxEMissRDNob3QrLEQzY29sZCspCgkJU3RhdHVzOiBEMCBQTUUtRW5hYmxlLSBE U2VsPTAgRFNjYWxlPTAgUE1FLQoJS2VybmVsIGRyaXZlciBpbiB1c2U6IGVoY2lfaGNkCglLZXJu ZWwgbW9kdWxlczogZWhjaS1oY2QKMDA6IGRlIDEwIDdlIDA3IDA2IDAwIGIwIDAwIGExIDIwIDAz IDBjIDAwIDAwIDgwIDAwCjEwOiAwMCBlOCBlNyBmOSAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAw MCAwMCAwMCAwMAoyMDogMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgM2MgMTAg NmUgMmEKMzA6IDAwIDAwIDAwIDAwIDQ0IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDBhIDAyIDAzIDAx CjQwOiAzYyAxMCA2ZSAyYSAwYSA4MCBhMCAyMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMAo1MDog MDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAKNjA6IDIwIDIw IDAxIDAwIDAwIDYwIDE4IDg1IDAzIDNjIDBhIDAxIDAwIDAwIDAwIDAwCjcwOiAwMCAwMSAwOCAw MCAwMCAxMCAyMCA4MCA4OSAzZCBiNiAyMiA3NyAyNSAwNCAwMAo4MDogMDEgMDAgMDIgZmUgMDAg MDAgMDAgMDAgMDAgMDAgMDAgMDAgMTUgMTYgMDAgMDAKOTA6IDAwIDAxIDAwIDAwIDAwIDAwIDAw IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwCmEwOiAwMSAwMCAwMCAwMCAwMCAwMCAwOCAwMCAw MCAwMCAwMCAwMCAwMCAwMCAwMCAwMApiMDogMDAgMTEgMjIgMzMgNDQgNDQgNDQgMDQgYWEgMGEg MDAgMDAgMDAgMDAgMDAgMDAKYzA6IDEwIDEwIDJkIDBkIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAw IDAwIDAwIDAwIDAwCmQwOiAwMiAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAw MCAwMCAwMAplMDogMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAg MDAKZjA6IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDEwIDAwIGMwIDgwIDAwIDAwIDAwIDAwCgow MDowNy4wIEF1ZGlvIGRldmljZTogblZpZGlhIENvcnBvcmF0aW9uIFJlYWx0ZWsgQUxDMTIwMCA4 LUNoYW5uZWwgSGlnaCBEZWZpbml0aW9uIEF1ZGlvIENvZGVjIChyZXYgYTEpCglTdWJzeXN0ZW06 IEhld2xldHQtUGFja2FyZCBDb21wYW55IERldmljZSAyYTZlCglDb250cm9sOiBJL08tIE1lbSsg QnVzTWFzdGVyKyBTcGVjQ3ljbGUtIE1lbVdJTlYtIFZHQVNub29wLSBQYXJFcnItIFN0ZXBwaW5n LSBTRVJSLSBGYXN0QjJCLSBEaXNJTlR4LQoJU3RhdHVzOiBDYXArIDY2TUh6KyBVREYtIEZhc3RC MkIrIFBhckVyci0gREVWU0VMPWZhc3QgPlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydC0gPlNFUlIt IDxQRVJSLSBJTlR4LQoJTGF0ZW5jeTogMCAoNTAwbnMgbWluLCAxMjUwbnMgbWF4KQoJSW50ZXJy dXB0OiBwaW4gQSByb3V0ZWQgdG8gSVJRIDIxCglSZWdpb24gMDogTWVtb3J5IGF0IGY5ZTc4MDAw ICgzMi1iaXQsIG5vbi1wcmVmZXRjaGFibGUpIFtzaXplPTE2S10KCUNhcGFiaWxpdGllczogWzQ0 XSBQb3dlciBNYW5hZ2VtZW50IHZlcnNpb24gMgoJCUZsYWdzOiBQTUVDbGstIERTSS0gRDEtIEQy LSBBdXhDdXJyZW50PTBtQSBQTUUoRDAtLEQxLSxEMi0sRDNob3QrLEQzY29sZCspCgkJU3RhdHVz OiBEMCBQTUUtRW5hYmxlLSBEU2VsPTAgRFNjYWxlPTAgUE1FLQoJQ2FwYWJpbGl0aWVzOiBbNTBd IE1lc3NhZ2UgU2lnbmFsbGVkIEludGVycnVwdHM6IE1hc2srIDY0Yml0KyBRdWV1ZT0wLzAgRW5h YmxlLQoJCUFkZHJlc3M6IDAwMDAwMDAwMDAwMDAwMDAgIERhdGE6IDAwMDAKCQlNYXNraW5nOiAw MDAwMDAwMCAgUGVuZGluZzogMDAwMDAwMDAKCUNhcGFiaWxpdGllczogWzZjXSBIeXBlclRyYW5z cG9ydDogTVNJIE1hcHBpbmcgRW5hYmxlKyBGaXhlZCsKCUtlcm5lbCBkcml2ZXIgaW4gdXNlOiBI REEgSW50ZWwKCUtlcm5lbCBtb2R1bGVzOiBzbmQtaGRhLWludGVsCjAwOiBkZSAxMCA3NCAwNyAw NiAwMCBiMCAwMCBhMSAwMCAwMyAwNCAwMCAwMCAwMCAwMAoxMDogMDAgODAgZTcgZjkgMDAgMDAg MDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAKMjA6IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAw IDAwIDAwIDAwIDAwIDNjIDEwIDZlIDJhCjMwOiAwMCAwMCAwMCAwMCA0NCAwMCAwMCAwMCAwMCAw MCAwMCAwMCAwYiAwMSAwMiAwNQo0MDogM2MgMTAgNmUgMmEgMDEgNTAgMDIgYzAgMDAgMDAgMDAg MDAgMDEgMDEgMGYgMDAKNTA6IDA1IDZjIDgwIDAxIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAw IDAwIDAwIDAwCjYwOiAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwZiAwMCAwMCAwMCAwOCAwMCAw MyBhOAo3MDogMDMgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAK ODA6IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwCjkwOiAw MCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMAphMDogMDAgMDAg MDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAKYjA6IDAwIDAwIDAwIDAw IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwCmMwOiAwMCAwMCAwMCAwMCAwMCAw MCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMApkMDogMDAgMDAgMDAgMDAgMDAgMDAgMDAg MDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAKZTA6IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAw IDAwIDAwIDAwIDAwIDAwIDAwIDAwCmYwOiAwMCAwMCAwMCAwMCAwMCAwMCAwMCA0NyA4MCAyOSBj MCAwMCAwMCAwMCAwMCAwMAoKMDA6MDguMCBQQ0kgYnJpZGdlOiBuVmlkaWEgQ29ycG9yYXRpb24g TUNQNzhTIFtHZUZvcmNlIDgyMDBdIFBDSSBCcmlkZ2UgKHJldiBhMSkgKHByb2ctaWYgMDEpCglD b250cm9sOiBJL08tIE1lbSsgQnVzTWFzdGVyKyBTcGVjQ3ljbGUtIE1lbVdJTlYtIFZHQVNub29w LSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJSLSBGYXN0QjJCLSBEaXNJTlR4LQoJU3RhdHVzOiBDYXAr IDY2TUh6KyBVREYtIEZhc3RCMkIrIFBhckVyci0gREVWU0VMPWZhc3QgPlRBYm9ydC0gPFRBYm9y dC0gPE1BYm9ydC0gPlNFUlItIDxQRVJSLSBJTlR4LQoJTGF0ZW5jeTogMAoJQnVzOiBwcmltYXJ5 PTAwLCBzZWNvbmRhcnk9MDEsIHN1Ym9yZGluYXRlPTAxLCBzZWMtbGF0ZW5jeT0zMgoJTWVtb3J5 IGJlaGluZCBicmlkZ2U6IGY5ZjAwMDAwLWY5ZmZmZmZmCglTZWNvbmRhcnkgc3RhdHVzOiA2Nk1I ei0gRmFzdEIyQisgUGFyRXJyLSBERVZTRUw9bWVkaXVtID5UQWJvcnQtIDxUQWJvcnQtIDxNQWJv cnQrIDxTRVJSLSA8UEVSUi0KCUJyaWRnZUN0bDogUGFyaXR5LSBTRVJSKyBOb0lTQS0gVkdBLSBN QWJvcnQtID5SZXNldC0gRmFzdEIyQi0KCQlQcmlEaXNjVG1yLSBTZWNEaXNjVG1yKyBEaXNjVG1y U3RhdC0gRGlzY1RtclNFUlJFbi0KCUNhcGFiaWxpdGllczogW2I4XSBTdWJzeXN0ZW06IEhld2xl dHQtUGFja2FyZCBDb21wYW55IERldmljZSAyYTZlCglDYXBhYmlsaXRpZXM6IFs4Y10gSHlwZXJU cmFuc3BvcnQ6IE1TSSBNYXBwaW5nIEVuYWJsZSsgRml4ZWQtCgkJTWFwcGluZyBBZGRyZXNzIEJh c2U6IDAwMDAwMDAwZmVlMDAwMDAKMDA6IGRlIDEwIDVhIDA3IDA2IDAwIGIwIDAwIGExIDAxIDA0 IDA2IDAwIDAwIDAxIDAwCjEwOiAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMSAwMSAyMCBm MCAwMCA4MCAyMgoyMDogZjAgZjkgZjAgZjkgZjAgZmYgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAg MDAgMDAKMzA6IDAwIDAwIDAwIDAwIGI4IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAyIDAy CjQwOiAwMCAwMCA3MyAwNyAwMCAwMCAwMCAwMCAyZiAwNyAwMCAwMCAwMCAwMCA0NCAwMAo1MDog MDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgZmYgMWYgZmYgMWYgMDAgMDAgMDAgMDAKNjA6IDAwIDAw IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwCjcwOiAwMCAwMCAwMCAw MCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMAo4MDogMDAgMGEgMDAgMDAgM2Mg MDAgMjAgMDAgMDAgMDAgMDAgMDAgMDggMDAgMDEgYTgKOTA6IDAwIDAwIGUwIGZlIDAwIDAwIDAw IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwCmEwOiAwNCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAw MCAwMCAwMCAwMCAwMCAwMCAwMCAwMApiMDogMDAgMDAgMDAgMDAgZmYgZmYgMDAgMDAgMGQgOGMg MDAgMDAgM2MgMTAgNmUgMmEKYzA6IDNjIDEwIDZlIDJhIDAzIDAwIDAwIDAwIDAwIDAwIDAwIDAw IDAwIDAwIDAwIDAwCmQwOiAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAw MCAwMCAwMAplMDogMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAg MDAKZjA6IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwCgow MDowOS4wIFJBSUQgYnVzIGNvbnRyb2xsZXI6IG5WaWRpYSBDb3Jwb3JhdGlvbiBEZXZpY2UgMGFk OCAocmV2IGEyKQoJU3Vic3lzdGVtOiBIZXdsZXR0LVBhY2thcmQgQ29tcGFueSBEZXZpY2UgMmE2 ZQoJQ29udHJvbDogSS9PKyBNZW0rIEJ1c01hc3RlcisgU3BlY0N5Y2xlLSBNZW1XSU5WLSBWR0FT bm9vcC0gUGFyRXJyLSBTdGVwcGluZy0gU0VSUisgRmFzdEIyQi0gRGlzSU5UeCsKCVN0YXR1czog Q2FwKyA2Nk1IeisgVURGLSBGYXN0QjJCKyBQYXJFcnItIERFVlNFTD1mYXN0ID5UQWJvcnQtIDxU QWJvcnQtIDxNQWJvcnQtID5TRVJSLSA8UEVSUi0gSU5UeC0KCUxhdGVuY3k6IDAgKDc1MG5zIG1p biwgMjUwbnMgbWF4KQoJSW50ZXJydXB0OiBwaW4gQSByb3V0ZWQgdG8gSVJRIDIyOTkKCVJlZ2lv biAwOiBJL08gcG9ydHMgYXQgZDQ4MCBbc2l6ZT04XQoJUmVnaW9uIDE6IEkvTyBwb3J0cyBhdCBk NDAwIFtzaXplPTRdCglSZWdpb24gMjogSS9PIHBvcnRzIGF0IGQwODAgW3NpemU9OF0KCVJlZ2lv biAzOiBJL08gcG9ydHMgYXQgZDAwMCBbc2l6ZT00XQoJUmVnaW9uIDQ6IEkvTyBwb3J0cyBhdCBj YzAwIFtzaXplPTE2XQoJUmVnaW9uIDU6IE1lbW9yeSBhdCBmOWU3NjAwMCAoMzItYml0LCBub24t cHJlZmV0Y2hhYmxlKSBbc2l6ZT04S10KCUNhcGFiaWxpdGllczogWzQ0XSBQb3dlciBNYW5hZ2Vt ZW50IHZlcnNpb24gMgoJCUZsYWdzOiBQTUVDbGstIERTSS0gRDEtIEQyLSBBdXhDdXJyZW50PTBt QSBQTUUoRDAtLEQxLSxEMi0sRDNob3QtLEQzY29sZC0pCgkJU3RhdHVzOiBEMCBQTUUtRW5hYmxl LSBEU2VsPTAgRFNjYWxlPTAgUE1FLQoJQ2FwYWJpbGl0aWVzOiBbOGNdIFNBVEEgSEJBIDw/PgoJ Q2FwYWJpbGl0aWVzOiBbYjBdIE1lc3NhZ2UgU2lnbmFsbGVkIEludGVycnVwdHM6IE1hc2stIDY0 Yml0KyBRdWV1ZT0wLzMgRW5hYmxlKwoJCUFkZHJlc3M6IDAwMDAwMDAwZmVlMGYwMGMgIERhdGE6 IDQxYTkKCUNhcGFiaWxpdGllczogW2VjXSBIeXBlclRyYW5zcG9ydDogTVNJIE1hcHBpbmcgRW5h YmxlKyBGaXhlZCsKCUtlcm5lbCBkcml2ZXIgaW4gdXNlOiBhaGNpCglLZXJuZWwgbW9kdWxlczog YWhjaQowMDogZGUgMTAgZDggMGEgMDcgMDUgYjAgMDAgYTIgMDAgMDQgMDEgMDAgMDAgMDAgMDAK MTA6IDgxIGQ0IDAwIDAwIDAxIGQ0IDAwIDAwIDgxIGQwIDAwIDAwIDAxIGQwIDAwIDAwCjIwOiAw MSBjYyAwMCAwMCAwMCA2MCBlNyBmOSAwMCAwMCAwMCAwMCAzYyAxMCA2ZSAyYQozMDogMDAgMDAg MDAgMDAgNDQgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDUgMDEgMDMgMDEKNDA6IDNjIDEwIDZlIDJh IDAxIDhjIDAyIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwCjUwOiAwZiA2OCA3OCA2MCAwMCAw MCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMAo2MDogMDAgMDAgMDAgMDAgNDAgMGMgMDAg MGYgMDEgMGYgMDYgNDIgMDAgMDAgMDAgMDAKNzA6IDJjIDc4IGM0IDQwIDAwIDAwIDAwIDAwIDAy IDAwIDIwIDA4IDM0IDAwIDIwIDE5CjgwOiAwMyAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAw MCAwMCAxMiBiMCAxMCAwMAo5MDogNWYgMDIgMDAgMDAgMjAgMDEgMDAgMDAgNTAgMDAgMDAgMDAg MDQgMDEgMDAgODAKYTA6IDZlIDVhIDAwIDAwIDgwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDYzIDcx IDAwIDAyCmIwOiAwNSBlYyA4NyAwMCAwYyBmMCBlMCBmZSAwMCAwMCAwMCAwMCBhOSA0MSAwMCAw MApjMDogMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAKZDA6 IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDA4IDAwIDQwIDAwIDAwIDAwIDAwIDAwCmUwOiAwMCAw MCAwMCAwMCAwMCAwMCAzZiAwMCAwMCAwMCAwMCAwMCAwOCAwMCAwMyBhOApmMDogMDAgMDAgMDAg MDAgMDAgMDAgMDAgMDAgMDAgYzEgOWUgODAgMDAgMDAgMDAgMDAKCjAwOjBhLjAgRXRoZXJuZXQg Y29udHJvbGxlcjogblZpZGlhIENvcnBvcmF0aW9uIE1DUDc4UyBbR2VGb3JjZSA4MjAwXSBFdGhl cm5ldCAocmV2IGEyKQoJU3Vic3lzdGVtOiBIZXdsZXR0LVBhY2thcmQgQ29tcGFueSBEZXZpY2Ug MmE2ZQoJQ29udHJvbDogSS9PKyBNZW0rIEJ1c01hc3RlcisgU3BlY0N5Y2xlLSBNZW1XSU5WLSBW R0FTbm9vcC0gUGFyRXJyLSBTdGVwcGluZy0gU0VSUi0gRmFzdEIyQi0gRGlzSU5UeCsKCVN0YXR1 czogQ2FwKyA2Nk1IeisgVURGLSBGYXN0QjJCKyBQYXJFcnItIERFVlNFTD1mYXN0ID5UQWJvcnQt IDxUQWJvcnQtIDxNQWJvcnQtID5TRVJSLSA8UEVSUi0gSU5UeC0KCUxhdGVuY3k6IDAgKDI1MG5z IG1pbiwgNTAwMG5zIG1heCkKCUludGVycnVwdDogcGluIEEgcm91dGVkIHRvIElSUSAyMjk4CglS ZWdpb24gMDogTWVtb3J5IGF0IGY5ZTdjMDAwICgzMi1iaXQsIG5vbi1wcmVmZXRjaGFibGUpIFtz aXplPTRLXQoJUmVnaW9uIDE6IEkvTyBwb3J0cyBhdCBjODgwIFtzaXplPThdCglSZWdpb24gMjog TWVtb3J5IGF0IGY5ZTdlNDAwICgzMi1iaXQsIG5vbi1wcmVmZXRjaGFibGUpIFtzaXplPTI1Nl0K CVJlZ2lvbiAzOiBNZW1vcnkgYXQgZjllN2UwMDAgKDMyLWJpdCwgbm9uLXByZWZldGNoYWJsZSkg W3NpemU9MTZdCglDYXBhYmlsaXRpZXM6IFs0NF0gUG93ZXIgTWFuYWdlbWVudCB2ZXJzaW9uIDIK CQlGbGFnczogUE1FQ2xrLSBEU0ktIEQxKyBEMisgQXV4Q3VycmVudD0wbUEgUE1FKEQwKyxEMSss RDIrLEQzaG90KyxEM2NvbGQrKQoJCVN0YXR1czogRDAgUE1FLUVuYWJsZSsgRFNlbD0wIERTY2Fs ZT0wIFBNRS0KCUNhcGFiaWxpdGllczogWzUwXSBNZXNzYWdlIFNpZ25hbGxlZCBJbnRlcnJ1cHRz OiBNYXNrKyA2NGJpdCsgUXVldWU9MC80IEVuYWJsZSsKCQlBZGRyZXNzOiAwMDAwMDAwMGZlZTBm MDBjICBEYXRhOiA0MWIxCgkJTWFza2luZzogMDAwMGZmZmUgIFBlbmRpbmc6IDAwMDAwMDAwCglD YXBhYmlsaXRpZXM6IFs2Y10gSHlwZXJUcmFuc3BvcnQ6IE1TSSBNYXBwaW5nIEVuYWJsZSsgRml4 ZWQrCglLZXJuZWwgZHJpdmVyIGluIHVzZTogZm9yY2VkZXRoCglLZXJuZWwgbW9kdWxlczogZm9y Y2VkZXRoCjAwOiBkZSAxMCA2MCAwNyAwNyAwNCBiMCAwMCBhMiAwMCAwMCAwMiAwMCAwMCAwMCAw MAoxMDogMDAgYzAgZTcgZjkgODEgYzggMDAgMDAgMDAgZTQgZTcgZjkgMDAgZTAgZTcgZjkKMjA6 IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDNjIDEwIDZlIDJhCjMwOiAwMCAw MCAwMCAwMCA0NCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwZiAwMSAwMSAxNAo0MDogM2MgMTAgNmUg MmEgMDEgNTAgMDIgZmUgMDAgMDEgMDAgMDAgMDEgMDAgMDAgMDAKNTA6IDA1IDZjIDg5IDAxIDBj IGYwIGUwIGZlIDAwIDAwIDAwIDAwIGIxIDQxIDAwIDAwCjYwOiBmZSBmZiAwMCAwMCAwMCAwMCAw MCAwMCBmZiAwMCAwMCAwMCAwOCAwMCAwMyBhOAo3MDogMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAg MDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAKODA6IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAw IDAwIDAwIDAwIDAwIDAwIDAwCjkwOiAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAw MCAwMCAwMCAwMCAwMAphMDogMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAg MDAgMDAgMDAKYjA6IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAw IDAwCmMwOiAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMApk MDogMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAKZTA6IDAw IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwCmYwOiAwMCAwMCAw MCAwMCAzMCAwMCAwMCAwMCAwMiA4MSBjMCAwMCAwMiAwMCAyMCAwOAoKMDA6MTAuMCBQQ0kgYnJp ZGdlOiBuVmlkaWEgQ29ycG9yYXRpb24gTUNQNzhTIFtHZUZvcmNlIDgyMDBdIFBDSSBFeHByZXNz IEJyaWRnZSAocmV2IGExKQoJQ29udHJvbDogSS9PKyBNZW0rIEJ1c01hc3RlcisgU3BlY0N5Y2xl LSBNZW1XSU5WLSBWR0FTbm9vcC0gUGFyRXJyLSBTdGVwcGluZy0gU0VSUi0gRmFzdEIyQi0gRGlz SU5UeCsKCVN0YXR1czogQ2FwKyA2Nk1Iei0gVURGLSBGYXN0QjJCLSBQYXJFcnItIERFVlNFTD1m YXN0ID5UQWJvcnQtIDxUQWJvcnQtIDxNQWJvcnQtID5TRVJSLSA8UEVSUi0gSU5UeC0KCUxhdGVu Y3k6IDAsIENhY2hlIExpbmUgU2l6ZTogNjQgYnl0ZXMKCUJ1czogcHJpbWFyeT0wMCwgc2Vjb25k YXJ5PTAyLCBzdWJvcmRpbmF0ZT0wMiwgc2VjLWxhdGVuY3k9MAoJSS9PIGJlaGluZCBicmlkZ2U6 IDAwMDBlMDAwLTAwMDBlZmZmCglNZW1vcnkgYmVoaW5kIGJyaWRnZTogZmEwMDAwMDAtZmVhZmZm ZmYKCVByZWZldGNoYWJsZSBtZW1vcnkgYmVoaW5kIGJyaWRnZTogMDAwMDAwMDBlMDAwMDAwMC0w MDAwMDAwMGVmZmZmZmZmCglTZWNvbmRhcnkgc3RhdHVzOiA2Nk1Iei0gRmFzdEIyQi0gUGFyRXJy LSBERVZTRUw9ZmFzdCA+VEFib3J0LSA8VEFib3J0LSA8TUFib3J0LSA8U0VSUi0gPFBFUlItCglC cmlkZ2VDdGw6IFBhcml0eS0gU0VSUisgTm9JU0EtIFZHQSsgTUFib3J0LSA+UmVzZXQtIEZhc3RC MkItCgkJUHJpRGlzY1Rtci0gU2VjRGlzY1Rtci0gRGlzY1RtclN0YXQtIERpc2NUbXJTRVJSRW4t CglDYXBhYmlsaXRpZXM6IFs0MF0gU3Vic3lzdGVtOiBIZXdsZXR0LVBhY2thcmQgQ29tcGFueSBE ZXZpY2UgMmE2ZQoJQ2FwYWJpbGl0aWVzOiBbNDhdIFBvd2VyIE1hbmFnZW1lbnQgdmVyc2lvbiAz CgkJRmxhZ3M6IFBNRUNsay0gRFNJLSBEMS0gRDItIEF1eEN1cnJlbnQ9MG1BIFBNRShEMCssRDEr LEQyKyxEM2hvdCssRDNjb2xkKykKCQlTdGF0dXM6IEQwIFBNRS1FbmFibGUtIERTZWw9MCBEU2Nh bGU9MCBQTUUtCglDYXBhYmlsaXRpZXM6IFs1MF0gTWVzc2FnZSBTaWduYWxsZWQgSW50ZXJydXB0 czogTWFzay0gNjRiaXQrIFF1ZXVlPTAvMSBFbmFibGUrCgkJQWRkcmVzczogMDAwMDAwMDBmZWUw ZjAwYyAgRGF0YTogNDE2OQoJQ2FwYWJpbGl0aWVzOiBbNjBdIEh5cGVyVHJhbnNwb3J0OiBNU0kg TWFwcGluZyBFbmFibGUrIEZpeGVkLQoJCU1hcHBpbmcgQWRkcmVzcyBCYXNlOiAwMDAwMDAwMGZl ZTAwMDAwCglDYXBhYmlsaXRpZXM6IFs4MF0gRXhwcmVzcyAodjIpIFJvb3QgUG9ydCAoU2xvdCsp LCBNU0kgMDAKCQlEZXZDYXA6CU1heFBheWxvYWQgMjU2IGJ5dGVzLCBQaGFudEZ1bmMgMCwgTGF0 ZW5jeSBMMHMgPDY0bnMsIEwxIDwxdXMKCQkJRXh0VGFnKyBSQkUrIEZMUmVzZXQtCgkJRGV2Q3Rs OglSZXBvcnQgZXJyb3JzOiBDb3JyZWN0YWJsZSsgTm9uLUZhdGFsKyBGYXRhbCsgVW5zdXBwb3J0 ZWQrCgkJCVJseGRPcmQrIEV4dFRhZy0gUGhhbnRGdW5jLSBBdXhQd3ItIE5vU25vb3ArCgkJCU1h eFBheWxvYWQgMTI4IGJ5dGVzLCBNYXhSZWFkUmVxIDUxMiBieXRlcwoJCURldlN0YToJQ29yckVy ci0gVW5jb3JyRXJyLSBGYXRhbEVyci0gVW5zdXBwUmVxLSBBdXhQd3ItIFRyYW5zUGVuZC0KCQlM bmtDYXA6CVBvcnQgIzAsIFNwZWVkIDIuNUdUL3MsIFdpZHRoIHgxNiwgQVNQTSBMMHMgTDEsIExh dGVuY3kgTDAgPDUxMm5zLCBMMSA8NHVzCgkJCUNsb2NrUE0tIFN1cHJpc2UtIExMQWN0UmVwKyBC d05vdCsKCQlMbmtDdGw6CUFTUE0gRGlzYWJsZWQ7IFJDQiA2NCBieXRlcyBEaXNhYmxlZC0gUmV0 cmFpbi0gQ29tbUNsay0KCQkJRXh0U3luY2gtIENsb2NrUE0tIEF1dFdpZERpcy0gQldJbnQtIEF1 dEJXSW50LQoJCUxua1N0YToJU3BlZWQgMi41R1QvcywgV2lkdGggeDE2LCBUckVyci0gVHJhaW4t IFNsb3RDbGsrIERMQWN0aXZlKyBCV01nbXQtIEFCV01nbXQtCgkJU2x0Q2FwOglBdHRuQnRuLSBQ d3JDdHJsLSBNUkwtIEF0dG5JbmQtIFB3ckluZC0gSG90UGx1Zy0gU3VycGlzZS0KCQkJU2xvdCAj ICAxLCBQb3dlckxpbWl0IDc1LjAwMDAwMDsgSW50ZXJsb2NrLSBOb0NvbXBsLQoJCVNsdEN0bDoJ RW5hYmxlOiBBdHRuQnRuLSBQd3JGbHQtIE1STC0gUHJlc0RldC0gQ21kQ3BsdC0gSFBJcnEtIExp bmtDaGctCgkJCUNvbnRyb2w6IEF0dG5JbmQgT2ZmLCBQd3JJbmQgT24sIFBvd2VyLSBJbnRlcmxv Y2stCgkJU2x0U3RhOglTdGF0dXM6IEF0dG5CdG4tIFBvd2VyRmx0LSBNUkwtIENtZENwbHQtIFBy ZXNEZXQrIEludGVybG9jay0KCQkJQ2hhbmdlZDogTVJMLSBQcmVzRGV0KyBMaW5rU3RhdGUrCgkJ Um9vdEN0bDogRXJyQ29ycmVjdGFibGUtIEVyck5vbi1GYXRhbC0gRXJyRmF0YWwtIFBNRUludEVu YS0gQ1JTVmlzaWJsZS0KCQlSb290Q2FwOiBDUlNWaXNpYmxlLQoJCVJvb3RTdGE6IFBNRSBSZXFJ RCAwMDAwLCBQTUVTdGF0dXMtIFBNRVBlbmRpbmctCglLZXJuZWwgZHJpdmVyIGluIHVzZTogcGNp ZXBvcnQtZHJpdmVyCglLZXJuZWwgbW9kdWxlczogc2hwY2hwCjAwOiBkZSAxMCA3OCAwNyAwNyAw NCAxMCAwMCBhMSAwMCAwNCAwNiAxMCAwMCAwMSAwMAoxMDogMDAgMDAgMDAgMDAgMDAgMDAgMDAg MDAgMDAgMDIgMDIgMDAgZTEgZTEgMDAgMDAKMjA6IDAwIGZhIGEwIGZlIDAxIGUwIGYxIGVmIDAw IDAwIDAwIDAwIDAwIDAwIDAwIDAwCjMwOiAwMCAwMCAwMCAwMCA0MCAwMCAwMCAwMCAwMCAwMCAw MCAwMCAwYSAwMSAxYSAwMAo0MDogMGQgNDggMDAgMDAgM2MgMTAgNmUgMmEgMDEgNTAgMDMgZjgg MDAgMDAgMDAgMDAKNTA6IDA1IDYwIDgzIDAwIDBjIGYwIGUwIGZlIDAwIDAwIDAwIDAwIDY5IDQx IDAwIDAwCjYwOiAwOCA4MCAwMSBhOCAwMCAwMCBlMCBmZSAwMCAwMCAwMCAwMCAwMCAwMCAwMCAw MAo3MDogMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAKODA6 IDEwIDAwIDQyIDAxIDIxIDgwIDAwIDAwIDFmIDI4IDAwIDAwIDAxIDNkIDMxIDAwCjkwOiAwMCAw MCAwMSAzMSA4MCAyNSAwOCAwMCBjMCAwMSA0OCAwMSAwMCAwMCAwMCAwMAphMDogMDAgMDAgMDAg MDAgMTMgMDAgMDAgMDAgMDYgMDAgMDAgMDAgMDAgMDAgMDAgMDAKYjA6IDAxIDAwIDAxIDAwIDAw IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwCmMwOiAwMCAwMCAwMCAwMCAwMCAwMCAw MCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMApkMDogMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAg MDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAKZTA6IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAw IDAwIDAwIDAwIDAwIDAwIDAwCmYwOiAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAw MCAwMCAwMCAwMCAwMAoKMDA6MTIuMCBQQ0kgYnJpZGdlOiBuVmlkaWEgQ29ycG9yYXRpb24gTUNQ NzhTIFtHZUZvcmNlIDgyMDBdIFBDSSBFeHByZXNzIEJyaWRnZSAocmV2IGExKQoJQ29udHJvbDog SS9PLSBNZW0tIEJ1c01hc3RlcisgU3BlY0N5Y2xlLSBNZW1XSU5WLSBWR0FTbm9vcC0gUGFyRXJy LSBTdGVwcGluZy0gU0VSUi0gRmFzdEIyQi0gRGlzSU5UeCsKCVN0YXR1czogQ2FwKyA2Nk1Iei0g VURGLSBGYXN0QjJCLSBQYXJFcnItIERFVlNFTD1mYXN0ID5UQWJvcnQtIDxUQWJvcnQtIDxNQWJv cnQtID5TRVJSLSA8UEVSUi0gSU5UeC0KCUxhdGVuY3k6IDAsIENhY2hlIExpbmUgU2l6ZTogNjQg Ynl0ZXMKCUJ1czogcHJpbWFyeT0wMCwgc2Vjb25kYXJ5PTAzLCBzdWJvcmRpbmF0ZT0wMywgc2Vj LWxhdGVuY3k9MAoJU2Vjb25kYXJ5IHN0YXR1czogNjZNSHotIEZhc3RCMkItIFBhckVyci0gREVW U0VMPWZhc3QgPlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydC0gPFNFUlItIDxQRVJSLQoJQnJpZGdl Q3RsOiBQYXJpdHktIFNFUlIrIE5vSVNBLSBWR0EtIE1BYm9ydC0gPlJlc2V0LSBGYXN0QjJCLQoJ CVByaURpc2NUbXItIFNlY0Rpc2NUbXItIERpc2NUbXJTdGF0LSBEaXNjVG1yU0VSUkVuLQoJQ2Fw YWJpbGl0aWVzOiBbNDBdIFN1YnN5c3RlbTogSGV3bGV0dC1QYWNrYXJkIENvbXBhbnkgRGV2aWNl IDJhNmUKCUNhcGFiaWxpdGllczogWzQ4XSBQb3dlciBNYW5hZ2VtZW50IHZlcnNpb24gMwoJCUZs YWdzOiBQTUVDbGstIERTSS0gRDEtIEQyLSBBdXhDdXJyZW50PTBtQSBQTUUoRDArLEQxKyxEMiss RDNob3QrLEQzY29sZCspCgkJU3RhdHVzOiBEMCBQTUUtRW5hYmxlLSBEU2VsPTAgRFNjYWxlPTAg UE1FLQoJQ2FwYWJpbGl0aWVzOiBbNTBdIE1lc3NhZ2UgU2lnbmFsbGVkIEludGVycnVwdHM6IE1h c2stIDY0Yml0KyBRdWV1ZT0wLzEgRW5hYmxlKwoJCUFkZHJlc3M6IDAwMDAwMDAwZmVlMGYwMGMg IERhdGE6IDQxNzEKCUNhcGFiaWxpdGllczogWzYwXSBIeXBlclRyYW5zcG9ydDogTVNJIE1hcHBp bmcgRW5hYmxlKyBGaXhlZC0KCQlNYXBwaW5nIEFkZHJlc3MgQmFzZTogMDAwMDAwMDBmZWUwMDAw MAoJQ2FwYWJpbGl0aWVzOiBbODBdIEV4cHJlc3MgKHYxKSBSb290IFBvcnQgKFNsb3QrKSwgTVNJ IDAwCgkJRGV2Q2FwOglNYXhQYXlsb2FkIDI1NiBieXRlcywgUGhhbnRGdW5jIDAsIExhdGVuY3kg TDBzIDw2NG5zLCBMMSA8MXVzCgkJCUV4dFRhZysgUkJFKyBGTFJlc2V0LQoJCURldkN0bDoJUmVw b3J0IGVycm9yczogQ29ycmVjdGFibGUrIE5vbi1GYXRhbCsgRmF0YWwrIFVuc3VwcG9ydGVkKwoJ CQlSbHhkT3JkKyBFeHRUYWctIFBoYW50RnVuYy0gQXV4UHdyLSBOb1Nub29wKwoJCQlNYXhQYXls b2FkIDEyOCBieXRlcywgTWF4UmVhZFJlcSA1MTIgYnl0ZXMKCQlEZXZTdGE6CUNvcnJFcnItIFVu Y29yckVyci0gRmF0YWxFcnItIFVuc3VwcFJlcS0gQXV4UHdyLSBUcmFuc1BlbmQtCgkJTG5rQ2Fw OglQb3J0ICMyLCBTcGVlZCAyLjVHVC9zLCBXaWR0aCB4MSwgQVNQTSBMMHMgTDEsIExhdGVuY3kg TDAgPDUxMm5zLCBMMSA8NHVzCgkJCUNsb2NrUE0tIFN1cHJpc2UtIExMQWN0UmVwKyBCd05vdC0K CQlMbmtDdGw6CUFTUE0gRGlzYWJsZWQ7IFJDQiA2NCBieXRlcyBEaXNhYmxlZC0gUmV0cmFpbi0g Q29tbUNsay0KCQkJRXh0U3luY2gtIENsb2NrUE0tIEF1dFdpZERpcy0gQldJbnQtIEF1dEJXSW50 LQoJCUxua1N0YToJU3BlZWQgMi41R1QvcywgV2lkdGggeDQsIFRyRXJyLSBUcmFpbi0gU2xvdENs aysgRExBY3RpdmUtIEJXTWdtdC0gQUJXTWdtdC0KCQlTbHRDYXA6CUF0dG5CdG4tIFB3ckN0cmwt IE1STC0gQXR0bkluZC0gUHdySW5kLSBIb3RQbHVnLSBTdXJwaXNlLQoJCQlTbG90ICMgIDMsIFBv d2VyTGltaXQgMTAuMDAwMDAwOyBJbnRlcmxvY2stIE5vQ29tcGwtCgkJU2x0Q3RsOglFbmFibGU6 IEF0dG5CdG4tIFB3ckZsdC0gTVJMLSBQcmVzRGV0LSBDbWRDcGx0LSBIUElycS0gTGlua0NoZy0K CQkJQ29udHJvbDogQXR0bkluZCBPZmYsIFB3ckluZCBPbiwgUG93ZXItIEludGVybG9jay0KCQlT bHRTdGE6CVN0YXR1czogQXR0bkJ0bi0gUG93ZXJGbHQtIE1STC0gQ21kQ3BsdC0gUHJlc0RldC0g SW50ZXJsb2NrLQoJCQlDaGFuZ2VkOiBNUkwtIFByZXNEZXQrIExpbmtTdGF0ZS0KCQlSb290Q3Rs OiBFcnJDb3JyZWN0YWJsZS0gRXJyTm9uLUZhdGFsLSBFcnJGYXRhbC0gUE1FSW50RW5hLSBDUlNW aXNpYmxlLQoJCVJvb3RDYXA6IENSU1Zpc2libGUtCgkJUm9vdFN0YTogUE1FIFJlcUlEIDAwMDAs IFBNRVN0YXR1cy0gUE1FUGVuZGluZy0KCUtlcm5lbCBkcml2ZXIgaW4gdXNlOiBwY2llcG9ydC1k cml2ZXIKCUtlcm5lbCBtb2R1bGVzOiBzaHBjaHAKMDA6IGRlIDEwIDViIDA3IDA0IDA0IDEwIDAw IGExIDAwIDA0IDA2IDEwIDAwIDAxIDAwCjEwOiAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAw MyAwMyAwMCBmMSAwMSAwMCAwMAoyMDogZjAgZmYgMDAgMDAgZjEgZmYgMDEgMDAgMDAgMDAgMDAg MDAgMDAgMDAgMDAgMDAKMzA6IDAwIDAwIDAwIDAwIDQwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDBi IDAxIDAyIDAwCjQwOiAwZCA0OCAwMCAwMCAzYyAxMCA2ZSAyYSAwMSA1MCAwMyBmOCAwMCAwMCAw MCAwMAo1MDogMDUgNjAgODMgMDAgMGMgZjAgZTAgZmUgMDAgMDAgMDAgMDAgNzEgNDEgMDAgMDAK NjA6IDA4IDgwIDAxIGE4IDAwIDAwIGUwIGZlIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwCjcwOiAw MCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMAo4MDogMTAgMDAg NDEgMDEgMjEgODAgMDAgMDAgMWYgMjggMDAgMDAgMTEgM2MgMTEgMDIKOTA6IDAwIDAwIDQxIDEw IDAwIDA1IDE4IDAwIGMwIDAxIDA4IDAwIDAwIDAwIDAwIDAwCmEwOiAwMCAwMCAwMCAwMCAxMyAw MCAwMCAwMCAwNiAwMCAwMCAwMCAwMCAwMCAwMCAwMApiMDogMDAgMDAgMDAgMDAgMDAgMDAgMDAg MDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAKYzA6IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAw IDAwIDAwIDAwIDAwIDAwIDAwIDAwCmQwOiAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAw MCAwMCAwMCAwMCAwMCAwMAplMDogMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAg MDAgMDAgMDAgMDAKZjA6IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAw IDAwIDAwCgowMDoxMy4wIFBDSSBicmlkZ2U6IG5WaWRpYSBDb3Jwb3JhdGlvbiBNQ1A3OFMgW0dl Rm9yY2UgODIwMF0gUENJIEJyaWRnZSAocmV2IGExKQoJQ29udHJvbDogSS9PLSBNZW0rIEJ1c01h c3RlcisgU3BlY0N5Y2xlLSBNZW1XSU5WLSBWR0FTbm9vcC0gUGFyRXJyLSBTdGVwcGluZy0gU0VS Ui0gRmFzdEIyQi0gRGlzSU5UeCsKCVN0YXR1czogQ2FwKyA2Nk1Iei0gVURGLSBGYXN0QjJCLSBQ YXJFcnItIERFVlNFTD1mYXN0ID5UQWJvcnQtIDxUQWJvcnQtIDxNQWJvcnQtID5TRVJSLSA8UEVS Ui0gSU5UeC0KCUxhdGVuY3k6IDAsIENhY2hlIExpbmUgU2l6ZTogNjQgYnl0ZXMKCUJ1czogcHJp bWFyeT0wMCwgc2Vjb25kYXJ5PTA0LCBzdWJvcmRpbmF0ZT0wNCwgc2VjLWxhdGVuY3k9MAoJTWVt b3J5IGJlaGluZCBicmlkZ2U6IGZlYjAwMDAwLWZlYmZmZmZmCglTZWNvbmRhcnkgc3RhdHVzOiA2 Nk1Iei0gRmFzdEIyQi0gUGFyRXJyLSBERVZTRUw9ZmFzdCA+VEFib3J0LSA8VEFib3J0LSA8TUFi b3J0KyA8U0VSUi0gPFBFUlItCglCcmlkZ2VDdGw6IFBhcml0eS0gU0VSUisgTm9JU0EtIFZHQS0g TUFib3J0LSA+UmVzZXQtIEZhc3RCMkItCgkJUHJpRGlzY1Rtci0gU2VjRGlzY1Rtci0gRGlzY1Rt clN0YXQtIERpc2NUbXJTRVJSRW4tCglDYXBhYmlsaXRpZXM6IFs0MF0gU3Vic3lzdGVtOiBIZXds ZXR0LVBhY2thcmQgQ29tcGFueSBEZXZpY2UgMmE2ZQoJQ2FwYWJpbGl0aWVzOiBbNDhdIFBvd2Vy IE1hbmFnZW1lbnQgdmVyc2lvbiAzCgkJRmxhZ3M6IFBNRUNsay0gRFNJLSBEMS0gRDItIEF1eEN1 cnJlbnQ9MG1BIFBNRShEMCssRDErLEQyKyxEM2hvdCssRDNjb2xkKykKCQlTdGF0dXM6IEQwIFBN RS1FbmFibGUtIERTZWw9MCBEU2NhbGU9MCBQTUUtCglDYXBhYmlsaXRpZXM6IFs1MF0gTWVzc2Fn ZSBTaWduYWxsZWQgSW50ZXJydXB0czogTWFzay0gNjRiaXQrIFF1ZXVlPTAvMSBFbmFibGUrCgkJ QWRkcmVzczogMDAwMDAwMDBmZWUwZjAwYyAgRGF0YTogNDE3OQoJQ2FwYWJpbGl0aWVzOiBbNjBd IEh5cGVyVHJhbnNwb3J0OiBNU0kgTWFwcGluZyBFbmFibGUrIEZpeGVkLQoJCU1hcHBpbmcgQWRk cmVzcyBCYXNlOiAwMDAwMDAwMGZlZTAwMDAwCglDYXBhYmlsaXRpZXM6IFs4MF0gRXhwcmVzcyAo djEpIFJvb3QgUG9ydCAoU2xvdCspLCBNU0kgMDAKCQlEZXZDYXA6CU1heFBheWxvYWQgMjU2IGJ5 dGVzLCBQaGFudEZ1bmMgMCwgTGF0ZW5jeSBMMHMgPDY0bnMsIEwxIDwxdXMKCQkJRXh0VGFnKyBS QkUrIEZMUmVzZXQtCgkJRGV2Q3RsOglSZXBvcnQgZXJyb3JzOiBDb3JyZWN0YWJsZSsgTm9uLUZh dGFsKyBGYXRhbCsgVW5zdXBwb3J0ZWQrCgkJCVJseGRPcmQrIEV4dFRhZy0gUGhhbnRGdW5jLSBB dXhQd3ItIE5vU25vb3ArCgkJCU1heFBheWxvYWQgMTI4IGJ5dGVzLCBNYXhSZWFkUmVxIDUxMiBi eXRlcwoJCURldlN0YToJQ29yckVyci0gVW5jb3JyRXJyLSBGYXRhbEVyci0gVW5zdXBwUmVxLSBB dXhQd3ItIFRyYW5zUGVuZC0KCQlMbmtDYXA6CVBvcnQgIzMsIFNwZWVkIDIuNUdUL3MsIFdpZHRo IHgxLCBBU1BNIEwwcyBMMSwgTGF0ZW5jeSBMMCA8NTEybnMsIEwxIDw0dXMKCQkJQ2xvY2tQTS0g U3VwcmlzZS0gTExBY3RSZXArIEJ3Tm90LQoJCUxua0N0bDoJQVNQTSBEaXNhYmxlZDsgUkNCIDY0 IGJ5dGVzIERpc2FibGVkLSBSZXRyYWluLSBDb21tQ2xrLQoJCQlFeHRTeW5jaC0gQ2xvY2tQTS0g QXV0V2lkRGlzLSBCV0ludC0gQXV0QldJbnQtCgkJTG5rU3RhOglTcGVlZCAyLjVHVC9zLCBXaWR0 aCB4MSwgVHJFcnItIFRyYWluLSBTbG90Q2xrKyBETEFjdGl2ZSsgQldNZ210LSBBQldNZ210LQoJ CVNsdENhcDoJQXR0bkJ0bi0gUHdyQ3RybC0gTVJMLSBBdHRuSW5kLSBQd3JJbmQtIEhvdFBsdWct IFN1cnBpc2UtCgkJCVNsb3QgIyAgNCwgUG93ZXJMaW1pdCAxMC4wMDAwMDA7IEludGVybG9jay0g Tm9Db21wbC0KCQlTbHRDdGw6CUVuYWJsZTogQXR0bkJ0bi0gUHdyRmx0LSBNUkwtIFByZXNEZXQt IENtZENwbHQtIEhQSXJxLSBMaW5rQ2hnLQoJCQlDb250cm9sOiBBdHRuSW5kIE9mZiwgUHdySW5k IE9uLCBQb3dlci0gSW50ZXJsb2NrLQoJCVNsdFN0YToJU3RhdHVzOiBBdHRuQnRuLSBQb3dlckZs dC0gTVJMLSBDbWRDcGx0LSBQcmVzRGV0KyBJbnRlcmxvY2stCgkJCUNoYW5nZWQ6IE1STC0gUHJl c0RldCsgTGlua1N0YXRlKwoJCVJvb3RDdGw6IEVyckNvcnJlY3RhYmxlLSBFcnJOb24tRmF0YWwt IEVyckZhdGFsLSBQTUVJbnRFbmEtIENSU1Zpc2libGUtCgkJUm9vdENhcDogQ1JTVmlzaWJsZS0K CQlSb290U3RhOiBQTUUgUmVxSUQgMDAwMCwgUE1FU3RhdHVzLSBQTUVQZW5kaW5nLQoJS2VybmVs IGRyaXZlciBpbiB1c2U6IHBjaWVwb3J0LWRyaXZlcgoJS2VybmVsIG1vZHVsZXM6IHNocGNocAow MDogZGUgMTAgN2EgMDcgMDYgMDQgMTAgMDAgYTEgMDAgMDQgMDYgMTAgMDAgMDEgMDAKMTA6IDAw IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDA0IDA0IDAwIGYxIDAxIDAwIDIwCjIwOiBiMCBmZSBi MCBmZSBmMSBmZiAwMSAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMAozMDogMDAgMDAgMDAgMDAg NDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMGYgMDEgMDIgMDAKNDA6IDBkIDQ4IDAwIDAwIDNjIDEw IDZlIDJhIDAxIDUwIDAzIGY4IDAwIDAwIDAwIDAwCjUwOiAwNSA2MCA4MyAwMCAwYyBmMCBlMCBm ZSAwMCAwMCAwMCAwMCA3OSA0MSAwMCAwMAo2MDogMDggODAgMDEgYTggMDAgMDAgZTAgZmUgMDAg MDAgMDAgMDAgMDAgMDAgMDAgMDAKNzA6IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAw IDAwIDAwIDAwIDAwIDAwCjgwOiAxMCAwMCA0MSAwMSAyMSA4MCAwMCAwMCAxZiAyOCAwMCAwMCAx MSAzYyAxMSAwMwo5MDogMDAgMDAgMTEgMzAgMDAgMDUgMjAgMDAgYzAgMDEgNDggMDEgMDAgMDAg MDAgMDAKYTA6IDAwIDAwIDAwIDAwIDEzIDAwIDAwIDAwIDA2IDAwIDAwIDAwIDAwIDAwIDAwIDAw CmIwOiAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMApjMDog MDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAKZDA6IDAwIDAw IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwCmUwOiAwMCAwMCAwMCAw MCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMApmMDogMDAgMDAgMDAgMDAgMDAg MDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAKCjAwOjE0LjAgUENJIGJyaWRnZTogblZp ZGlhIENvcnBvcmF0aW9uIE1DUDc4UyBbR2VGb3JjZSA4MjAwXSBQQ0kgQnJpZGdlIChyZXYgYTEp CglDb250cm9sOiBJL08tIE1lbS0gQnVzTWFzdGVyKyBTcGVjQ3ljbGUtIE1lbVdJTlYtIFZHQVNu b29wLSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJSLSBGYXN0QjJCLSBEaXNJTlR4KwoJU3RhdHVzOiBD YXArIDY2TUh6LSBVREYtIEZhc3RCMkItIFBhckVyci0gREVWU0VMPWZhc3QgPlRBYm9ydC0gPFRB Ym9ydC0gPE1BYm9ydC0gPlNFUlItIDxQRVJSLSBJTlR4LQoJTGF0ZW5jeTogMCwgQ2FjaGUgTGlu ZSBTaXplOiA2NCBieXRlcwoJQnVzOiBwcmltYXJ5PTAwLCBzZWNvbmRhcnk9MDUsIHN1Ym9yZGlu YXRlPTA1LCBzZWMtbGF0ZW5jeT0wCglTZWNvbmRhcnkgc3RhdHVzOiA2Nk1Iei0gRmFzdEIyQi0g UGFyRXJyLSBERVZTRUw9ZmFzdCA+VEFib3J0LSA8VEFib3J0LSA8TUFib3J0LSA8U0VSUi0gPFBF UlItCglCcmlkZ2VDdGw6IFBhcml0eS0gU0VSUisgTm9JU0EtIFZHQS0gTUFib3J0LSA+UmVzZXQt IEZhc3RCMkItCgkJUHJpRGlzY1Rtci0gU2VjRGlzY1Rtci0gRGlzY1RtclN0YXQtIERpc2NUbXJT RVJSRW4tCglDYXBhYmlsaXRpZXM6IFs0MF0gU3Vic3lzdGVtOiBIZXdsZXR0LVBhY2thcmQgQ29t cGFueSBEZXZpY2UgMmE2ZQoJQ2FwYWJpbGl0aWVzOiBbNDhdIFBvd2VyIE1hbmFnZW1lbnQgdmVy c2lvbiAzCgkJRmxhZ3M6IFBNRUNsay0gRFNJLSBEMS0gRDItIEF1eEN1cnJlbnQ9MG1BIFBNRShE MCssRDErLEQyKyxEM2hvdCssRDNjb2xkKykKCQlTdGF0dXM6IEQwIFBNRS1FbmFibGUtIERTZWw9 MCBEU2NhbGU9MCBQTUUtCglDYXBhYmlsaXRpZXM6IFs1MF0gTWVzc2FnZSBTaWduYWxsZWQgSW50 ZXJydXB0czogTWFzay0gNjRiaXQrIFF1ZXVlPTAvMSBFbmFibGUrCgkJQWRkcmVzczogMDAwMDAw MDBmZWUwZjAwYyAgRGF0YTogNDE4MQoJQ2FwYWJpbGl0aWVzOiBbNjBdIEh5cGVyVHJhbnNwb3J0 OiBNU0kgTWFwcGluZyBFbmFibGUrIEZpeGVkLQoJCU1hcHBpbmcgQWRkcmVzcyBCYXNlOiAwMDAw MDAwMGZlZTAwMDAwCglDYXBhYmlsaXRpZXM6IFs4MF0gRXhwcmVzcyAodjEpIFJvb3QgUG9ydCAo U2xvdCspLCBNU0kgMDAKCQlEZXZDYXA6CU1heFBheWxvYWQgMjU2IGJ5dGVzLCBQaGFudEZ1bmMg MCwgTGF0ZW5jeSBMMHMgPDY0bnMsIEwxIDwxdXMKCQkJRXh0VGFnKyBSQkUrIEZMUmVzZXQtCgkJ RGV2Q3RsOglSZXBvcnQgZXJyb3JzOiBDb3JyZWN0YWJsZSsgTm9uLUZhdGFsKyBGYXRhbCsgVW5z dXBwb3J0ZWQrCgkJCVJseGRPcmQrIEV4dFRhZy0gUGhhbnRGdW5jLSBBdXhQd3ItIE5vU25vb3Ar CgkJCU1heFBheWxvYWQgMTI4IGJ5dGVzLCBNYXhSZWFkUmVxIDUxMiBieXRlcwoJCURldlN0YToJ Q29yckVyci0gVW5jb3JyRXJyLSBGYXRhbEVyci0gVW5zdXBwUmVxLSBBdXhQd3ItIFRyYW5zUGVu ZC0KCQlMbmtDYXA6CVBvcnQgIzQsIFNwZWVkIDIuNUdUL3MsIFdpZHRoIHgxLCBBU1BNIEwwcyBM MSwgTGF0ZW5jeSBMMCA8NTEybnMsIEwxIDw0dXMKCQkJQ2xvY2tQTS0gU3VwcmlzZS0gTExBY3RS ZXArIEJ3Tm90LQoJCUxua0N0bDoJQVNQTSBEaXNhYmxlZDsgUkNCIDY0IGJ5dGVzIERpc2FibGVk LSBSZXRyYWluLSBDb21tQ2xrLQoJCQlFeHRTeW5jaC0gQ2xvY2tQTS0gQXV0V2lkRGlzLSBCV0lu dC0gQXV0QldJbnQtCgkJTG5rU3RhOglTcGVlZCAyLjVHVC9zLCBXaWR0aCB4MSwgVHJFcnItIFRy YWluLSBTbG90Q2xrKyBETEFjdGl2ZS0gQldNZ210LSBBQldNZ210LQoJCVNsdENhcDoJQXR0bkJ0 bi0gUHdyQ3RybC0gTVJMLSBBdHRuSW5kLSBQd3JJbmQtIEhvdFBsdWctIFN1cnBpc2UtCgkJCVNs b3QgIyAgNSwgUG93ZXJMaW1pdCAxMC4wMDAwMDA7IEludGVybG9jay0gTm9Db21wbC0KCQlTbHRD dGw6CUVuYWJsZTogQXR0bkJ0bi0gUHdyRmx0LSBNUkwtIFByZXNEZXQtIENtZENwbHQtIEhQSXJx LSBMaW5rQ2hnLQoJCQlDb250cm9sOiBBdHRuSW5kIE9mZiwgUHdySW5kIE9uLCBQb3dlci0gSW50 ZXJsb2NrLQoJCVNsdFN0YToJU3RhdHVzOiBBdHRuQnRuLSBQb3dlckZsdC0gTVJMLSBDbWRDcGx0 LSBQcmVzRGV0LSBJbnRlcmxvY2stCgkJCUNoYW5nZWQ6IE1STC0gUHJlc0RldC0gTGlua1N0YXRl LQoJCVJvb3RDdGw6IEVyckNvcnJlY3RhYmxlLSBFcnJOb24tRmF0YWwtIEVyckZhdGFsLSBQTUVJ bnRFbmEtIENSU1Zpc2libGUtCgkJUm9vdENhcDogQ1JTVmlzaWJsZS0KCQlSb290U3RhOiBQTUUg UmVxSUQgMDAwMCwgUE1FU3RhdHVzLSBQTUVQZW5kaW5nLQoJS2VybmVsIGRyaXZlciBpbiB1c2U6 IHBjaWVwb3J0LWRyaXZlcgoJS2VybmVsIG1vZHVsZXM6IHNocGNocAowMDogZGUgMTAgN2EgMDcg MDQgMDQgMTAgMDAgYTEgMDAgMDQgMDYgMTAgMDAgMDEgMDAKMTA6IDAwIDAwIDAwIDAwIDAwIDAw IDAwIDAwIDAwIDA1IDA1IDAwIGYxIDAxIDAwIDAwCjIwOiBmMCBmZiAwMCAwMCBmMSBmZiAwMSAw MCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMAozMDogMDAgMDAgMDAgMDAgNDAgMDAgMDAgMDAgMDAg MDAgMDAgMDAgMGUgMDEgMDIgMDAKNDA6IDBkIDQ4IDAwIDAwIDNjIDEwIDZlIDJhIDAxIDUwIDAz IGY4IDAwIDAwIDAwIDAwCjUwOiAwNSA2MCA4MyAwMCAwYyBmMCBlMCBmZSAwMCAwMCAwMCAwMCA4 MSA0MSAwMCAwMAo2MDogMDggODAgMDEgYTggMDAgMDAgZTAgZmUgMDAgMDAgMDAgMDAgMDAgMDAg MDAgMDAKNzA6IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAw CjgwOiAxMCAwMCA0MSAwMSAyMSA4MCAwMCAwMCAxZiAyOCAwMCAwMCAxMSAzYyAxMSAwNAo5MDog MDAgMDAgMTEgMTAgMDAgMDUgMjggMDAgYzAgMDEgMDAgMDAgMDAgMDAgMDAgMDAKYTA6IDAwIDAw IDAwIDAwIDEzIDAwIDAwIDAwIDA2IDAwIDAwIDAwIDAwIDAwIDAwIDAwCmIwOiAwMCAwMCAwMCAw MCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMApjMDogMDAgMDAgMDAgMDAgMDAg MDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAKZDA6IDAwIDAwIDAwIDAwIDAwIDAwIDAw IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwCmUwOiAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAw MCAwMCAwMCAwMCAwMCAwMCAwMCAwMApmMDogMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAg MDAgMDAgMDAgMDAgMDAgMDAKCjAwOjE4LjAgSG9zdCBicmlkZ2U6IEFkdmFuY2VkIE1pY3JvIERl dmljZXMgW0FNRF0gRmFtaWx5IDEwaCBbT3B0ZXJvbiwgQXRobG9uNjQsIFNlbXByb25dIEh5cGVy VHJhbnNwb3J0IENvbmZpZ3VyYXRpb24KCUNvbnRyb2w6IEkvTy0gTWVtLSBCdXNNYXN0ZXItIFNw ZWNDeWNsZS0gTWVtV0lOVi0gVkdBU25vb3AtIFBhckVyci0gU3RlcHBpbmctIFNFUlItIEZhc3RC MkItIERpc0lOVHgtCglTdGF0dXM6IENhcCsgNjZNSHotIFVERi0gRmFzdEIyQi0gUGFyRXJyLSBE RVZTRUw9ZmFzdCA+VEFib3J0LSA8VEFib3J0LSA8TUFib3J0LSA+U0VSUi0gPFBFUlItIElOVHgt CglDYXBhYmlsaXRpZXM6IFs4MF0gSHlwZXJUcmFuc3BvcnQ6IEhvc3Qgb3IgU2Vjb25kYXJ5IElu dGVyZmFjZQoJCUNvbW1hbmQ6IFdhcm1Sc3QrIERibEVuZC0gRGV2TnVtPTAgQ2hhaW5TaWRlLSBI b3N0SGlkZSsgU2xhdmUtIDxFT0NFcnItIERVTC0KCQlMaW5rIENvbnRyb2w6IENGbEUtIENTVC0g Q0ZFLSA8TGtGYWlsLSBJbml0KyBFT0MtIFRYTy0gPENSQ0Vycj0wIElzb2NFbi0gTFNFbi0gRXh0 Q1RMLSA2NGItCgkJTGluayBDb25maWc6IE1MV0k9MTZiaXQgRHdGY0luLSBNTFdPPTE2Yml0IER3 RmNPdXQtIExXST0xNmJpdCBEd0ZjSW5Fbi0gTFdPPTE2Yml0IER3RmNPdXRFbi0KCQlSZXZpc2lv biBJRDogMy4wMAoJCUxpbmsgRnJlcXVlbmN5OiBbYV0KCQlMaW5rIEVycm9yOiA8UHJvdC0gPE92 ZmwtIDxFT0MtIENUTFRtLQoJCUxpbmsgRnJlcXVlbmN5IENhcGFiaWxpdHk6IDIwME1IeisgMzAw TUh6LSA0MDBNSHorIDUwME1Iei0gNjAwTUh6KyA4MDBNSHorIDEuMEdIeisgMS4yR0h6KyAxLjRH SHotIDEuNkdIei0gVmVuZC0KCQlGZWF0dXJlIENhcGFiaWxpdHk6IElzb2NGQysgTERUU1RPUCsg Q1JDVE0tIEVDVExULSA2NGJBKyBVSURSRC0gRXh0UlMtIFVDbmZFLQowMDogMjIgMTAgMDAgMTIg MDAgMDAgMTAgMDAgMDAgMDAgMDAgMDYgMDAgMDAgODAgMDAKMTA6IDAwIDAwIDAwIDAwIDAwIDAw IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwCjIwOiAwMCAwMCAwMCAwMCAwMCAwMCAwMCAw MCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMAozMDogMDAgMDAgMDAgMDAgODAgMDAgMDAgMDAgMDAg MDAgMDAgMDAgMDAgMDAgMDAgMDAKNDA6IDAxIDAyIDA0IDAwIDAxIDAyIDA0IDAwIDAxIDAyIDA0 IDAwIDAxIDAyIDA0IDAwCjUwOiAwMSAwMiAwNCAwMCAwMSAwMiAwNCAwMCAwMSAwMiAwNCAwMCAw MSAwMiAwNCAwMAo2MDogMDAgMDAgMDMgMDAgZTAgMDAgMDAgMDAgMjAgYTggNGUgMDEgMjAgZjgg MDAgMDAKNzA6IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAw CjgwOiAwOCAwMCAwMSAyMSAyMCAwMCAxMSAxMSA2MCAwYSBmNSA4NyAxMyAwMCAwMCAwMAo5MDog ZDEgMDEgODQgODIgMDAgMDAgMDAgMDAgMDcgMDAgMDAgMDAgMDAgMDAgMDAgMDAKYTA6IDAwIDAw IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwCmIwOiAwMCAwMCAwMCAw MCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMApjMDogMDAgMDAgMDAgMDAgMDAg MDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAKZDA6IDAwIDAwIDAwIDAwIDAwIDAwIDAw IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwCmUwOiAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAw MCAwMCAwMCAwMCAwMCAwMCAwMCAwMApmMDogMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAg MDAgMDAgMDAgMDAgMDAgMDAKCjAwOjE4LjEgSG9zdCBicmlkZ2U6IEFkdmFuY2VkIE1pY3JvIERl dmljZXMgW0FNRF0gRmFtaWx5IDEwaCBbT3B0ZXJvbiwgQXRobG9uNjQsIFNlbXByb25dIEFkZHJl c3MgTWFwCglDb250cm9sOiBJL08tIE1lbS0gQnVzTWFzdGVyLSBTcGVjQ3ljbGUtIE1lbVdJTlYt IFZHQVNub29wLSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJSLSBGYXN0QjJCLSBEaXNJTlR4LQoJU3Rh dHVzOiBDYXAtIDY2TUh6LSBVREYtIEZhc3RCMkItIFBhckVyci0gREVWU0VMPWZhc3QgPlRBYm9y dC0gPFRBYm9ydC0gPE1BYm9ydC0gPlNFUlItIDxQRVJSLSBJTlR4LQowMDogMjIgMTAgMDEgMTIg MDAgMDAgMDAgMDAgMDAgMDAgMDAgMDYgMDAgMDAgODAgMDAKMTA6IDAwIDAwIDAwIDAwIDAwIDAw IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwCjIwOiAwMCAwMCAwMCAwMCAwMCAwMCAwMCAw MCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMAozMDogMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAg MDAgMDAgMDAgMDAgMDAgMDAgMDAKNDA6IDAzIDAwIDAwIDAwIDAwIDAwIDVmIDAxIDAwIDAwIDAw IDAwIDAwIDAwIDAwIDAwCjUwOiAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAw MCAwMCAwMCAwMAo2MDogMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAg MDAgMDAKNzA6IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAw CjgwOiAwMyAwMCBmMCAwMCA4MCBmZiBmMyAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMAo5MDog MDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAKYTA6IDAwIDAw IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwCmIwOiAwMyAwYSAwMCAw MCAwMCAwYiAwMCAwMCAwMyAwMCBlMCAwMCAwMCAwYiBmZSAwMApjMDogMTMgMTAgMDAgMDAgMDAg ZjAgZmYgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAKZDA6IDAzIDIwIDAwIDAwIDAwIDIwIDAw IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwCmUwOiAwMyAwMCAwMCAwNyAwMCAwMCAwMCAwMCAw MCAwMCAwMCAwMCAwMCAwMCAwMCAwMApmMDogMDMgMjAgMDAgZTAgMDAgMDAgMDAgMDAgMDAgMDAg MDAgMDAgMDAgMDAgMDAgMDAKCjAwOjE4LjIgSG9zdCBicmlkZ2U6IEFkdmFuY2VkIE1pY3JvIERl dmljZXMgW0FNRF0gRmFtaWx5IDEwaCBbT3B0ZXJvbiwgQXRobG9uNjQsIFNlbXByb25dIERSQU0g Q29udHJvbGxlcgoJQ29udHJvbDogSS9PLSBNZW0tIEJ1c01hc3Rlci0gU3BlY0N5Y2xlLSBNZW1X SU5WLSBWR0FTbm9vcC0gUGFyRXJyLSBTdGVwcGluZy0gU0VSUi0gRmFzdEIyQi0gRGlzSU5UeC0K CVN0YXR1czogQ2FwLSA2Nk1Iei0gVURGLSBGYXN0QjJCLSBQYXJFcnItIERFVlNFTD1mYXN0ID5U QWJvcnQtIDxUQWJvcnQtIDxNQWJvcnQtID5TRVJSLSA8UEVSUi0gSU5UeC0KMDA6IDIyIDEwIDAy IDEyIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDA2IDAwIDAwIDgwIDAwCjEwOiAwMCAwMCAwMCAwMCAw MCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMAoyMDogMDAgMDAgMDAgMDAgMDAgMDAg MDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAKMzA6IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAw IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwCjQwOiAwMSAwMCA4MCAwMCAwMSAwMCBhMCAwMCAwMSAw MCAwMCAwMCAwMSAwMCA0MCAwMAo1MDogMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAg MDAgMDAgMDAgMDAgMDAKNjA6IGUwIDNmIDE4IDAwIGUwIDNmIDM4IDAwIDAwIDAwIDAwIDAwIDAw IDAwIDAwIDAwCjcwOiAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwNSAwMCAwMCAwZiAwMCAwMCAw MCAwMAo4MDogNTIgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMzUgZmIgN2UgMGMgNDUgNjMgMTIgMDEK OTA6IDMwIDAwIDAxIDAwIDBiIDgwIDU4IDdmIDA3IDAzIDAwIDgwIDE0IDAwIDAwIDAwCmEwOiAw MCAwMiAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMApiMDogNDkgMjUg NmEgMDcgYjggMDAgMDAgMDAgMTggMTIgODEgMTIgZWUgZWMgYjkgNWEKYzA6IDAwIDAwIDAwIDAw IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwCmQwOiBkNiA4MyAzOSBjYiBiMSA1 MSBhZCBkMyA4MCA3OCA2MSAwNiBiNiBkMyA2MSAwNgplMDogYjcgNTkgNjYgODggMTEgNTEgNjEg MTUgOTcgNzAgOTggNTQgNDQgMTMgMjIgNDAKZjA6IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAw IDAwIDAwIDAwIDAwIDAwIDAwIDAwCgowMDoxOC4zIEhvc3QgYnJpZGdlOiBBZHZhbmNlZCBNaWNy byBEZXZpY2VzIFtBTURdIEZhbWlseSAxMGggW09wdGVyb24sIEF0aGxvbjY0LCBTZW1wcm9uXSBN aXNjZWxsYW5lb3VzIENvbnRyb2wKCUNvbnRyb2w6IEkvTy0gTWVtLSBCdXNNYXN0ZXItIFNwZWND eWNsZS0gTWVtV0lOVi0gVkdBU25vb3AtIFBhckVyci0gU3RlcHBpbmctIFNFUlItIEZhc3RCMkIt IERpc0lOVHgtCglTdGF0dXM6IENhcCsgNjZNSHotIFVERi0gRmFzdEIyQi0gUGFyRXJyLSBERVZT RUw9ZmFzdCA+VEFib3J0LSA8VEFib3J0LSA8TUFib3J0LSA+U0VSUi0gPFBFUlItIElOVHgtCglD YXBhYmlsaXRpZXM6IFtmMF0gU2VjdXJlIGRldmljZSA8Pz4KMDA6IDIyIDEwIDAzIDEyIDAwIDAw IDEwIDAwIDAwIDAwIDAwIDA2IDAwIDAwIDgwIDAwCjEwOiAwMCAwMCAwMCAwMCAwMCAwMCAwMCAw MCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMAoyMDogMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAg MDAgMDAgMDAgMDAgMDAgMDAgMDAKMzA6IDAwIDAwIDAwIDAwIGYwIDAwIDAwIDAwIDAwIDAwIDAw IDAwIDAwIDAwIDAwIDAwCjQwOiBmZiBmZiBmZiAzZiA0NCAwMCA5MCAwYSAwMCAwMCAwMCAwMCAw MCAwMCAwMCAwMAo1MDogMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAg MDAgMDAKNjA6IDAwIDAwIDAwIDAwIDA0IDAwIDdmIDEyIGMwIDAwIDAwIDEwIDUyIDgwIDAxIDAw CjcwOiA1MyAxMSAwNCAwMCAwMSAwMSAxOCA5MSAxNCAwYyAyMCAwMCAxNCAwOSAwOSAwMAo4MDog ODEgYTYgMDAgZTYgZTYgNDEgZTYgYTAgMDggMDAgMDAgMDAgMDAgNDAgNDQgMDAKOTA6IDAzIDAw IDAwIDAwIDEwIDAwIDAwIDAwIDAwIDNmIDVmIDAxIDAwIDAwIDAwIDAwCmEwOiAwMCAyOCAwZiBh MCA4MCA5OCAxYyAzMiAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMApiMDogMDAgMDAgMDAgMDAgMDAg MDAgMDAgMDAgMDAgMDAgMDAgMDAgZTUgMmMgMDIgMDAKYzA6IDAwIDAwIDAwIDAwIDAwIDAwIDAw IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwCmQwOiAwMCAwMCAwMCAwMCAyNSAwZiA4MSBjOCAx NiAxNyAwMCAwMyAyOCA1MSAwMCAwMAplMDogMDAgMDAgMDAgMDAgMzAgMTIgMDAgMDAgOTkgN2Yg MDcgMDIgMDAgMDAgMDAgMDAKZjA6IDBmIDAwIDEwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAw IDIzIDBmIDEwIDAwCgowMDoxOC40IEhvc3QgYnJpZGdlOiBBZHZhbmNlZCBNaWNybyBEZXZpY2Vz IFtBTURdIEZhbWlseSAxMGggW09wdGVyb24sIEF0aGxvbjY0LCBTZW1wcm9uXSBMaW5rIENvbnRy b2wKCUNvbnRyb2w6IEkvTy0gTWVtLSBCdXNNYXN0ZXItIFNwZWNDeWNsZS0gTWVtV0lOVi0gVkdB U25vb3AtIFBhckVyci0gU3RlcHBpbmctIFNFUlItIEZhc3RCMkItIERpc0lOVHgtCglTdGF0dXM6 IENhcC0gNjZNSHotIFVERi0gRmFzdEIyQi0gUGFyRXJyLSBERVZTRUw9ZmFzdCA+VEFib3J0LSA8 VEFib3J0LSA8TUFib3J0LSA+U0VSUi0gPFBFUlItIElOVHgtCjAwOiAyMiAxMCAwNCAxMiAwMCAw MCAwMCAwMCAwMCAwMCAwMCAwNiAwMCAwMCA4MCAwMAoxMDogMDAgMDAgMDAgMDAgMDAgMDAgMDAg MDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAKMjA6IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAw IDAwIDAwIDAwIDAwIDAwIDAwIDAwCjMwOiAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAw MCAwMCAwMCAwMCAwMCAwMAo0MDogMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAg MDAgMDAgMDAgMDAKNTA6IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAw IDAwIDAwCjYwOiAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAw MAo3MDogMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAKODA6 IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwCjkwOiAwMCAw MCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMAphMDogMDAgMDAgMDAg MDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAKYjA6IDAwIDAwIDAwIDAwIDAw IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwCmMwOiAwMCAwMCAwMCAwMCAwMCAwMCAw MCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMApkMDogMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAg MDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAKZTA6IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAw IDAwIDAwIDAwIDAwIDAwIDAwCmYwOiAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAw MCAwMCAwMCAwMCAwMAoKMDE6MDUuMCBGaXJlV2lyZSAoSUVFRSAxMzk0KTogQWdlcmUgU3lzdGVt cyBGVzMyMyAocmV2IDcwKSAocHJvZy1pZiAxMCkKCVN1YnN5c3RlbTogSGV3bGV0dC1QYWNrYXJk IENvbXBhbnkgRGV2aWNlIDJhNmUKCUNvbnRyb2w6IEkvTy0gTWVtKyBCdXNNYXN0ZXIrIFNwZWND eWNsZS0gTWVtV0lOVisgVkdBU25vb3AtIFBhckVyci0gU3RlcHBpbmctIFNFUlIrIEZhc3RCMkIt IERpc0lOVHgtCglTdGF0dXM6IENhcCsgNjZNSHotIFVERi0gRmFzdEIyQisgUGFyRXJyLSBERVZT RUw9bWVkaXVtID5UQWJvcnQtIDxUQWJvcnQtIDxNQWJvcnQtID5TRVJSLSA8UEVSUi0gSU5UeC0K CUxhdGVuY3k6IDMyICgzMDAwbnMgbWluLCA2MDAwbnMgbWF4KSwgQ2FjaGUgTGluZSBTaXplOiA2 NCBieXRlcwoJSW50ZXJydXB0OiBwaW4gQSByb3V0ZWQgdG8gSVJRIDE5CglSZWdpb24gMDogTWVt b3J5IGF0IGY5ZmZmMDAwICgzMi1iaXQsIG5vbi1wcmVmZXRjaGFibGUpIFtzaXplPTRLXQoJQ2Fw YWJpbGl0aWVzOiBbNDRdIFBvd2VyIE1hbmFnZW1lbnQgdmVyc2lvbiAyCgkJRmxhZ3M6IFBNRUNs ay0gRFNJLSBEMSsgRDIrIEF1eEN1cnJlbnQ9MG1BIFBNRShEMCssRDErLEQyKyxEM2hvdCssRDNj b2xkLSkKCQlTdGF0dXM6IEQwIFBNRS1FbmFibGUtIERTZWw9MCBEU2NhbGU9MCBQTUUrCglLZXJu ZWwgZHJpdmVyIGluIHVzZTogb2hjaTEzOTQKCUtlcm5lbCBtb2R1bGVzOiBvaGNpMTM5NAowMDog YzEgMTEgMTEgNTggMTYgMDEgOTAgMDIgNzAgMTAgMDAgMGMgMTAgMjAgMDAgMDAKMTA6IDAwIGYw IGZmIGY5IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwCjIwOiAwMCAwMCAwMCAw MCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAzYyAxMCA2ZSAyYQozMDogMDAgMDAgMDAgMDAgNDQg MDAgMDAgMDAgMDAgMDAgMDAgMDAgMGUgMDEgMGMgMTgKNDA6IDAwIDAwIDAwIDAwIDAxIDAwIDAy IDdlIDAwIDgwIDAwIDAwIDAwIDAwIDAwIDAwCjUwOiAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAw MCAwMCAwMCAwMCAwMCAwMCAwMCAwMAo2MDogMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAg MDAgMDAgMDAgMDAgMDAgMDAKNzA6IDAwIDhjIDFlIDAwIDdjIDhlIDMzIDAxIDAwIDAwIDAwIDAw IDAwIDAwIDAwIDAwCjgwOiAwMCA4YyAxZSAwMCA3YyA4ZSAzMyAwMSAwMCAwMCAwMCAwMCAwMCAw MCAwMCAwMAo5MDogMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAg MDAKYTA6IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwCmIw OiAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMApjMDogMDAg MDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAKZDA6IDAwIDAwIDAw IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwCmUwOiAwMCAwMCAwMCAwMCAw MCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMApmMDogMDAgMDAgMDAgMDAgMDAgMDAg MDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAKCjAyOjAwLjAgVkdBIGNvbXBhdGlibGUgY29u dHJvbGxlcjogblZpZGlhIENvcnBvcmF0aW9uIERldmljZSAwNmUwIChyZXYgYTEpCglTdWJzeXN0 ZW06IERldmljZSAxYjBhOjkwMDQKCUNvbnRyb2w6IEkvTysgTWVtKyBCdXNNYXN0ZXIrIFNwZWND eWNsZS0gTWVtV0lOVi0gVkdBU25vb3AtIFBhckVyci0gU3RlcHBpbmctIFNFUlIrIEZhc3RCMkIt IERpc0lOVHgtCglTdGF0dXM6IENhcCsgNjZNSHotIFVERi0gRmFzdEIyQi0gUGFyRXJyLSBERVZT RUw9ZmFzdCA+VEFib3J0LSA8VEFib3J0LSA8TUFib3J0LSA+U0VSUi0gPFBFUlItIElOVHgtCglM YXRlbmN5OiAwLCBDYWNoZSBMaW5lIFNpemU6IDY0IGJ5dGVzCglJbnRlcnJ1cHQ6IHBpbiBBIHJv dXRlZCB0byBJUlEgMTkKCVJlZ2lvbiAwOiBNZW1vcnkgYXQgZmQwMDAwMDAgKDMyLWJpdCwgbm9u LXByZWZldGNoYWJsZSkgW3NpemU9MTZNXQoJUmVnaW9uIDE6IE1lbW9yeSBhdCBlMDAwMDAwMCAo NjQtYml0LCBwcmVmZXRjaGFibGUpIFtzaXplPTI1Nk1dCglSZWdpb24gMzogTWVtb3J5IGF0IGZh MDAwMDAwICg2NC1iaXQsIG5vbi1wcmVmZXRjaGFibGUpIFtzaXplPTMyTV0KCVJlZ2lvbiA1OiBJ L08gcG9ydHMgYXQgZWMwMCBbc2l6ZT0xMjhdCglFeHBhbnNpb24gUk9NIGF0IGZlYWUwMDAwIFtk aXNhYmxlZF0gW3NpemU9MTI4S10KCUNhcGFiaWxpdGllczogWzYwXSBQb3dlciBNYW5hZ2VtZW50 IHZlcnNpb24gMwoJCUZsYWdzOiBQTUVDbGstIERTSS0gRDEtIEQyLSBBdXhDdXJyZW50PTBtQSBQ TUUoRDAtLEQxLSxEMi0sRDNob3QtLEQzY29sZC0pCgkJU3RhdHVzOiBEMCBQTUUtRW5hYmxlLSBE U2VsPTAgRFNjYWxlPTAgUE1FLQoJQ2FwYWJpbGl0aWVzOiBbNjhdIE1lc3NhZ2UgU2lnbmFsbGVk IEludGVycnVwdHM6IE1hc2stIDY0Yml0KyBRdWV1ZT0wLzAgRW5hYmxlLQoJCUFkZHJlc3M6IDAw MDAwMDAwMDAwMDAwMDAgIERhdGE6IDAwMDAKCUNhcGFiaWxpdGllczogWzc4XSBFeHByZXNzICh2 MSkgRW5kcG9pbnQsIE1TSSAwMAoJCURldkNhcDoJTWF4UGF5bG9hZCAxMjggYnl0ZXMsIFBoYW50 RnVuYyAwLCBMYXRlbmN5IEwwcyA8NTEybnMsIEwxIDw0dXMKCQkJRXh0VGFnKyBBdHRuQnRuLSBB dHRuSW5kLSBQd3JJbmQtIFJCRSsgRkxSZXNldC0KCQlEZXZDdGw6CVJlcG9ydCBlcnJvcnM6IENv cnJlY3RhYmxlLSBOb24tRmF0YWwtIEZhdGFsLSBVbnN1cHBvcnRlZC0KCQkJUmx4ZE9yZCsgRXh0 VGFnLSBQaGFudEZ1bmMtIEF1eFB3ci0gTm9Tbm9vcCsKCQkJTWF4UGF5bG9hZCAxMjggYnl0ZXMs IE1heFJlYWRSZXEgNTEyIGJ5dGVzCgkJRGV2U3RhOglDb3JyRXJyLSBVbmNvcnJFcnItIEZhdGFs RXJyLSBVbnN1cHBSZXEtIEF1eFB3ci0gVHJhbnNQZW5kLQoJCUxua0NhcDoJUG9ydCAjMCwgU3Bl ZWQgMi41R1QvcywgV2lkdGggeDE2LCBBU1BNIEwwcyBMMSwgTGF0ZW5jeSBMMCA8NTEybnMsIEwx IDwxdXMKCQkJQ2xvY2tQTS0gU3VwcmlzZS0gTExBY3RSZXAtIEJ3Tm90LQoJCUxua0N0bDoJQVNQ TSBEaXNhYmxlZDsgUkNCIDEyOCBieXRlcyBEaXNhYmxlZC0gUmV0cmFpbi0gQ29tbUNsay0KCQkJ RXh0U3luY2gtIENsb2NrUE0tIEF1dFdpZERpcy0gQldJbnQtIEF1dEJXSW50LQoJCUxua1N0YToJ U3BlZWQgMi41R1QvcywgV2lkdGggeDE2LCBUckVyci0gVHJhaW4tIFNsb3RDbGsrIERMQWN0aXZl LSBCV01nbXQtIEFCV01nbXQtCglDYXBhYmlsaXRpZXM6IFsxMDBdIFZpcnR1YWwgQ2hhbm5lbCA8 Pz4KCUNhcGFiaWxpdGllczogWzEyOF0gUG93ZXIgQnVkZ2V0aW5nIDw/PgoJQ2FwYWJpbGl0aWVz OiBbNjAwXSBWZW5kb3IgU3BlY2lmaWMgSW5mb3JtYXRpb24gPD8+CglLZXJuZWwgZHJpdmVyIGlu IHVzZTogbnZpZGlhCglLZXJuZWwgbW9kdWxlczogbnZpZGlhZmIsIG52aWRpYQowMDogZGUgMTAg ZTAgMDYgMDcgMDEgMTAgMDAgYTEgMDAgMDAgMDMgMTAgMDAgMDAgMDAKMTA6IDAwIDAwIDAwIGZk IDBjIDAwIDAwIGUwIDAwIDAwIDAwIDAwIDA0IDAwIDAwIGZhCjIwOiAwMCAwMCAwMCAwMCAwMSBl YyAwMCAwMCAwMCAwMCAwMCAwMCAwYSAxYiAwNCA5MAozMDogMDAgMDAgYWUgZmUgNjAgMDAgMDAg MDAgMDAgMDAgMDAgMDAgMGEgMDEgMDAgMDAKNDA6IDBhIDFiIDA0IDkwIDAwIDAwIDAwIDAwIDAw IDAwIDAwIDAwIDAwIDAwIDAwIDAwCjUwOiAwMSAwMCAwMCAwMCAwMSAwMCAwMCAwMCBjZSBkNiAy MyAwMCAwMCAwMCAwMCAwMAo2MDogMDEgNjggMDMgMDAgMDggMDAgMDAgMDAgMDUgNzggODAgMDAg MDAgMDAgMDAgMDAKNzA6IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDEwIDAwIDAxIDAwIGUwIDg0 IDAwIDAwCjgwOiAxMCAyOCAwMCAwMCAwMSAzZCAwMCAwMCAwOCAwMCAwMSAxMSAwMCAwMCAwMCAw MAo5MDogMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAKYTA6 IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwCmIwOiAwMCAw MCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMApjMDogMDAgMDAgMDAg MDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAKZDA6IDAwIDAwIDAwIDAwIDAw IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwCmUwOiAwMCAwMCAwMCAwMCAwMCAwMCAw MCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMApmMDogMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAg MDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAKCjA0OjAwLjAgQ29tbXVuaWNhdGlvbiBjb250cm9sbGVy OiBDb25leGFudCBTeXN0ZW1zLCBJbmMuIERldmljZSAyZjgyCglTdWJzeXN0ZW06IENvbmV4YW50 IFN5c3RlbXMsIEluYy4gRGV2aWNlIDAwMDAKCUNvbnRyb2w6IEkvTy0gTWVtKyBCdXNNYXN0ZXIr IFNwZWNDeWNsZS0gTWVtV0lOVi0gVkdBU25vb3AtIFBhckVyci0gU3RlcHBpbmctIFNFUlIrIEZh c3RCMkItIERpc0lOVHgtCglTdGF0dXM6IENhcCsgNjZNSHotIFVERi0gRmFzdEIyQi0gUGFyRXJy LSBERVZTRUw9ZmFzdCA+VEFib3J0LSA8VEFib3J0LSA8TUFib3J0LSA+U0VSUi0gPFBFUlItIElO VHgtCglMYXRlbmN5OiAwLCBDYWNoZSBMaW5lIFNpemU6IDY0IGJ5dGVzCglJbnRlcnJ1cHQ6IHBp biBBIHJvdXRlZCB0byBJUlEgMTUKCVJlZ2lvbiAwOiBNZW1vcnkgYXQgZmViZjAwMDAgKDMyLWJp dCwgbm9uLXByZWZldGNoYWJsZSkgW3NpemU9NjRLXQoJQ2FwYWJpbGl0aWVzOiBbNDBdIEV4cHJl c3MgKHYxKSBFbmRwb2ludCwgTVNJIDAwCgkJRGV2Q2FwOglNYXhQYXlsb2FkIDEyOCBieXRlcywg UGhhbnRGdW5jIDAsIExhdGVuY3kgTDBzIDw2NG5zLCBMMSA8MXVzCgkJCUV4dFRhZy0gQXR0bkJ0 bi0gQXR0bkluZC0gUHdySW5kLSBSQkUtIEZMUmVzZXQtCgkJRGV2Q3RsOglSZXBvcnQgZXJyb3Jz OiBDb3JyZWN0YWJsZS0gTm9uLUZhdGFsLSBGYXRhbC0gVW5zdXBwb3J0ZWQtCgkJCVJseGRPcmQr IEV4dFRhZy0gUGhhbnRGdW5jLSBBdXhQd3ItIE5vU25vb3ArCgkJCU1heFBheWxvYWQgMTI4IGJ5 dGVzLCBNYXhSZWFkUmVxIDUxMiBieXRlcwoJCURldlN0YToJQ29yckVyci0gVW5jb3JyRXJyKyBG YXRhbEVyci0gVW5zdXBwUmVxKyBBdXhQd3ItIFRyYW5zUGVuZC0KCQlMbmtDYXA6CVBvcnQgIzAs IFNwZWVkIDIuNUdUL3MsIFdpZHRoIHgxLCBBU1BNIEwwcyBMMSwgTGF0ZW5jeSBMMCA8MnVzLCBM MSA8NHVzCgkJCUNsb2NrUE0tIFN1cHJpc2UtIExMQWN0UmVwLSBCd05vdC0KCQlMbmtDdGw6CUFT UE0gRGlzYWJsZWQ7IFJDQiA2NCBieXRlcyBEaXNhYmxlZC0gUmV0cmFpbi0gQ29tbUNsay0KCQkJ RXh0U3luY2gtIENsb2NrUE0tIEF1dFdpZERpcy0gQldJbnQtIEF1dEJXSW50LQoJCUxua1N0YToJ U3BlZWQgMi41R1QvcywgV2lkdGggeDEsIFRyRXJyLSBUcmFpbi0gU2xvdENsay0gRExBY3RpdmUt IEJXTWdtdC0gQUJXTWdtdC0KCUNhcGFiaWxpdGllczogWzgwXSBQb3dlciBNYW5hZ2VtZW50IHZl cnNpb24gMgoJCUZsYWdzOiBQTUVDbGstIERTSSsgRDErIEQyKyBBdXhDdXJyZW50PTBtQSBQTUUo RDArLEQxKyxEMissRDNob3QrLEQzY29sZC0pCgkJU3RhdHVzOiBEMCBQTUUtRW5hYmxlLSBEU2Vs PTAgRFNjYWxlPTAgUE1FLQoJQ2FwYWJpbGl0aWVzOiBbOTBdIFZpdGFsIFByb2R1Y3QgRGF0YSA8 Pz4KCUNhcGFiaWxpdGllczogWzEwMF0gQWR2YW5jZWQgRXJyb3IgUmVwb3J0aW5nIDw/PgoJQ2Fw YWJpbGl0aWVzOiBbMjAwXSBWaXJ0dWFsIENoYW5uZWwgPD8+CjAwOiBmMSAxNCA4MiAyZiAwNiAw MSAxMCAwMCAwMCAwMCA4MCAwNyAxMCAwMCAwMCAwMAoxMDogMDAgMDAgYmYgZmUgMDAgMDAgMDAg MDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAKMjA6IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAw IDAwIDAwIDAwIGYxIDE0IDAwIDAwCjMwOiAwMCAwMCAwMCAwMCA0MCAwMCAwMCAwMCAwMCAwMCAw MCAwMCAwZiAwMSAwMCAwMAo0MDogMTAgODAgMDEgMDAgMDAgMDAgMDAgMDAgMTAgMjggMGEgMDAg MTEgNWMgMDEgMDAKNTA6IDAwIDAwIDExIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAw IDAwIDAwCjYwOiAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAw MAo3MDogMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAKODA6 IDAxIDkwIDIyIDdlIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwCjkwOiAwMyAw MCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMAphMDogMDAgMDAgMDAg MDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAKYjA6IDAwIDAwIDAwIDAwIDAw IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwCmMwOiAwMCAwMCAwMCAwMCAwMCAwMCAw MCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMApkMDogMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAg MDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAKZTA6IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAw IDAwIDAwIDAwIDAwIDAwIDAwCmYwOiAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAw MCAwMCAwMCAwMCAwMAoK --MP_/uxkKrGOcbHvWrQ.4JxzZG1R-- From owner-freebsd-current@FreeBSD.ORG Tue Dec 9 01:29:41 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2A4CF1065672; Tue, 9 Dec 2008 01:29:41 +0000 (UTC) (envelope-from keramida@ceid.upatras.gr) Received: from igloo.linux.gr (igloo.linux.gr [62.1.205.36]) by mx1.freebsd.org (Postfix) with ESMTP id 9890C8FC0C; Tue, 9 Dec 2008 01:29:40 +0000 (UTC) (envelope-from keramida@ceid.upatras.gr) Received: from kobe.laptop (adsl200-163.kln.forthnet.gr [79.103.13.163]) (authenticated bits=128) by igloo.linux.gr (8.14.3/8.14.3/Debian-5) with ESMTP id mB91TVeb001263 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 9 Dec 2008 03:29:36 +0200 Received: from kobe.laptop (kobe.laptop [127.0.0.1]) by kobe.laptop (8.14.3/8.14.3) with ESMTP id mB91TVmd066821; Tue, 9 Dec 2008 03:29:31 +0200 (EET) (envelope-from keramida@ceid.upatras.gr) Received: (from keramida@localhost) by kobe.laptop (8.14.3/8.14.3/Submit) id mB91TS4q066732; Tue, 9 Dec 2008 03:29:28 +0200 (EET) (envelope-from keramida@ceid.upatras.gr) From: Giorgos Keramidas To: Maxim Sobolev References: <493DA269.2070805@FreeBSD.org> <20081208235119.GA46608@onelab2.iet.unipi.it> <493DBBD0.5080705@FreeBSD.org> Date: Tue, 09 Dec 2008 03:29:28 +0200 In-Reply-To: <493DBBD0.5080705@FreeBSD.org> (Maxim Sobolev's message of "Mon, 08 Dec 2008 16:29:04 -0800") Message-ID: <87oczmjfuv.fsf@kobe.laptop> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-MailScanner-ID: mB91TVeb001263 X-Hellug-MailScanner: Found to be clean X-Hellug-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-3.957, required 5, autolearn=not spam, ALL_TRUSTED -1.80, AWL 0.44, BAYES_00 -2.60) X-Hellug-MailScanner-From: keramida@ceid.upatras.gr X-Spam-Status: No Cc: Luigi Rizzo , hackers@freebsd.org, Luigi Rizzo , "current@freebsd.org" Subject: Re: Enhancing cdboot [patch for review] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Dec 2008 01:29:41 -0000 On Mon, 08 Dec 2008 16:29:04 -0800, Maxim Sobolev wrote: > Luigi Rizzo wrote: >> On Mon, Dec 08, 2008 at 02:40:41PM -0800, Maxim Sobolev wrote: >>> Hi, >>> Below please find patch that enhances cdboot with two compile-time options: >> ... >>> Any comments/suggestions are appreciated. If there are no objections I >>> would like to commit the change. The long-term goal is to make >>> CDBOOT_PROMPT default mode for installation CD. >>> >>> http://sobomax.sippysoft.com/~sobomax/cdboot.diff >> >> Looks good. Some comments: > > Thank you for the review and comments. Please see my answers below. > >> 1. since there is plenty of space in the cdboot sector, why don't you >> make the two option always compiled in, controlling which one to >> activate through flags in the bootsector itself, to be set >> patching the binary sector itself using a mechanism similar to >> boot0cfg. >> Of course you cannot alter a cdrom after you burn it, >> but it makes it easier to build CDs with one or the other defaults, >> patching cdboot or the iso image itself before creating/burning it. >> >> 2. in fact, the 'silent' option could be disabled at runtime by >> pressing some key (e.g. adding a short wait loop before proceeding; >> if this is meant for custom, unattended CDs the extra delay should not >> matter much); > > Good idea, I will see if I can put that in. In fact this behavior should > have to be optional as well, since one of the uses for the "silent" > option here is to provide tamper-resistant boot process on custom > hardware. Nice pair of features :-) If there are no pressing space constraints maybe we can build both options in by default, but still make them opt-out when necessary? With a bit of makefile glue we can make it possible to compile with an `src.conf' that includes: WITH_CDBOOT_SILENT=1 WITHOUT_CDBOOT_PROMPT=1 This way the defaults can include support for both options, but we can conditionally compile *out* the bits that are not needed for some custom installation. Something like this can define one or both of these options in CFLAGS, depending on what `src.conf' contains: # When CDBOOT_SILENT is set, the cdboot doesn't produce any messages except # "Loading, please wait..." and it also passes RBX_MUTE flag to the next # stage to silence it as well. This is intended for custom installations # where end-user is not required to see any messages or interfere with the # boot process. .if ${MK_CDBOOT_SILENT} != "no" CFLAGS+= -DCDBOOT_SILENT .endif # When CDBOOT_PROMPT is enabled the cdboot behaves like windows xp or vista # cd loader, that is it reads MBR from the first hard drive in the system # and if the MBR is bootable (i.e. drive has some other operating system # installed on it) then it presents user with "Press any key to boot from # CD" prompt and waits for 20 seconds. If key is not pressed then the # control is passed to the MBR, otherwise CD is booted. This is intended for # installation CD to allow unattended mode and also helps when installation # CD has been unintentionally left in the drive of the machine that is set # to boot off CD. .if ${MK_CDBOOT_PROMPT} != "no" CFLAGS+= -DCDBOOT_PROMPT .endif The defaults for ${MK_CDBOOT_XXX} will have to be explicitly set in `src/share/mk/bsd.own.mk', near line 281: 281 # 282 # MK_* options which default to "yes". 283 # 284 .for var in \ ... But that shouldn't be a problem, AFAICT :-) From owner-freebsd-current@FreeBSD.ORG Tue Dec 9 01:49:07 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 848761065677 for ; Tue, 9 Dec 2008 01:49:07 +0000 (UTC) (envelope-from jackie@boolome.com) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.184]) by mx1.freebsd.org (Postfix) with ESMTP id 259528FC17 for ; Tue, 9 Dec 2008 01:49:06 +0000 (UTC) (envelope-from jackie@boolome.com) Received: by ti-out-0910.google.com with SMTP id a1so798674tib.3 for ; Mon, 08 Dec 2008 17:49:06 -0800 (PST) Received: by 10.110.62.4 with SMTP id k4mr4870701tia.17.1228787345852; Mon, 08 Dec 2008 17:49:05 -0800 (PST) Received: from ?192.168.1.100? ([60.210.216.198]) by mx.google.com with ESMTPS id u12sm958929tia.9.2008.12.08.17.49.02 (version=SSLv3 cipher=RC4-MD5); Mon, 08 Dec 2008 17:49:04 -0800 (PST) From: boolome To: Garrett Cooper In-Reply-To: <7d6fde3d0812080155y22cc7c0bne1fa0094671355e4@mail.gmail.com> References: <1228555830.1186.6.camel@www.boolome.cn> <7d6fde3d0812080155y22cc7c0bne1fa0094671355e4@mail.gmail.com> Content-Type: text/plain; charset=utf-8 Organization: boolome Date: Tue, 09 Dec 2008 09:48:50 +0800 Message-Id: <1228787330.13158.0.camel@www.boolome.cn> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 8bit Cc: freebsd-current@freebsd.org Subject: Re: make buildworld failed! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Dec 2008 01:49:07 -0000 在 2008-12-08一的 01:55 -0800，Garrett Cooper写道： > On Sat, Dec 6, 2008 at 1:30 AM, boolome wrote: > [snip] > > Looks like your source tree is incomplete. > -Garrett But have cvsup the latest source tree ! From owner-freebsd-current@FreeBSD.ORG Tue Dec 9 03:39:57 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B1CE91065670; Tue, 9 Dec 2008 03:39:57 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.9.129]) by mx1.freebsd.org (Postfix) with ESMTP id 707AF8FC13; Tue, 9 Dec 2008 03:39:57 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 4AA3E73098; Tue, 9 Dec 2008 04:44:56 +0100 (CET) Date: Tue, 9 Dec 2008 04:44:56 +0100 From: Luigi Rizzo To: Maxim Sobolev Message-ID: <20081209034456.GA54569@onelab2.iet.unipi.it> References: <493DA269.2070805@FreeBSD.org> <20081208235119.GA46608@onelab2.iet.unipi.it> <493DBBD0.5080705@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <493DBBD0.5080705@FreeBSD.org> User-Agent: Mutt/1.4.2.3i Cc: Luigi Rizzo , hackers@freebsd.org, "current@freebsd.org" Subject: Re: Enhancing cdboot [patch for review] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Dec 2008 03:39:57 -0000 On Mon, Dec 08, 2008 at 04:29:04PM -0800, Maxim Sobolev wrote: > Luigi Rizzo wrote: ... > >4. another nitpick -- the value you pass in %si to the MBR does not > > seem to point to anything useful. As discussed about boot0.S and > > the followup in the mailing lists, there seems to be no standard > > but at least some MBR expect %si to point to a partition entry, > > so you should probably initialize one in a way similar way to that > > used by boot0.S > > Hmm, maybe I misunderstood it then. What do you mean by "point to > partition entry exactly"? Right now it points to the beginning on MBR. ok, so here is what I know. Even though there is no standard, at least ldlinux.sys and perhaps other bootloaders expect %si to point to a 16-byte record containing the partition descriptor (same structure as one of the 4 records at 0x1be in the MBR) for the partition they were loaded from. ldlinux.sys uses this info to "relocate": it knows the location of the other sectors of ldlinux.sys relative to the beginning of the partition, and uses the start-of-partition from the record at %si to compute these locations in terms of absolute disk positions. Note that in principle a MBR does not need this info -- even if it is a multi-sector boot code such as boot0ext, it may well assume to be located at offset 0. On the other hand if the code on the MBR uses %si, then you should set the entry so that at least the starting CHS and LBA info point to the first sector on disk, i.e. CHS=0,0,1 and LBA=0. In practical terms -- make %si point to a 16-byte area of memory containing all 0's except for the byte representing the sector number for the start of the partition. See the code in a recent sys/boot/i386/boot0/boot0.S which gives some details on this. cheers luigi From owner-freebsd-current@FreeBSD.ORG Tue Dec 9 03:48:41 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 423BD1065678 for ; Tue, 9 Dec 2008 03:48:41 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id 169B88FC13 for ; Tue, 9 Dec 2008 03:48:41 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from trouble.errno.com (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id mB93manP057827 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Dec 2008 19:48:37 -0800 (PST) (envelope-from sam@freebsd.org) Message-ID: <493DEA94.2060900@freebsd.org> Date: Mon, 08 Dec 2008 19:48:36 -0800 From: Sam Leffler Organization: FreeBSD Project User-Agent: Thunderbird 2.0.0.9 (X11/20071125) MIME-Version: 1.0 To: Vladimir Grebenschikov References: <200811301906.mAUJ6Z30099035@svn.freebsd.org> <1228739237.1860.21.camel@localhost> <493DA15D.7080109@freebsd.org> In-Reply-To: <493DA15D.7080109@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-DCC--Metrics: ebb.errno.com; whitelist Cc: current Subject: Re: svn commit: r185482 - head/sys/dev/ath/ath_rate/sample X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Dec 2008 03:48:41 -0000 Sam Leffler wrote: > Vladimir Grebenschikov wrote: >> * On Sun, 2008-11-30 at 19:06 +0000, Sam Leffler wrote: >> >>> Author: sam >>> Date: Sun Nov 30 19:06:35 2008 >>> New Revision: 185482 >>> URL: http://svn.freebsd.org/changeset/base/185482 >>> >>> Log: >>> Major overhaul: >>> o eliminate private state indexed by 802.11 rate codes; use the hal's >>> rate tables directly to get the same info >>> o calculate a mask of operational rates to optimize lookups and >>> checks >>> (instead of using for loops and similar) >>> o optimize size bin operations >>> o ignore rates marked as "do not use" in the hal phy tables >>> o fix bug that caused upshifting to break in 11g once the rate >>> dropped >>> below 11Mb/s >>> o add more intelligent multi-rate tx schedules >>> o add support for 1/2 and 1/4 width channels >>> o add dev.ath.X.sample_stats sysctl to dump runtime statistics to >>> the console >>> (needs to go up to a user app) >>> o export more tuning knobs via sysctls (still a couple of magic >>> constants) >>> >> >> Looks like, after that commit, I can't use if_ath loaded as module any >> more: >> >> # kldload /boot/kernel/ath_rate.ko >> kldload: can't load /boot/kernel/ath_rate.ko: No such file or directory >> # dmesg | tail -n1 link_elf: symbol ath_hal_computetxtime undefined >> # >> >> Yes, I've read UPDATING entry 20081130. >> But I have no ath_hal entry in my kernel config, I've loaded ath as >> KLDs. >> >> How to fix that problem ? >> >> >> > Try the attached change. > Never mind this; you'll have to build ath into the kernel until I can sort out how to fix the module(s). Sam From owner-freebsd-current@FreeBSD.ORG Tue Dec 9 04:49:10 2008 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 71CB3106564A; Tue, 9 Dec 2008 04:49:10 +0000 (UTC) (envelope-from sobomax@FreeBSD.org) Received: from sippysoft.com (gk1.360sip.com [72.236.70.240]) by mx1.freebsd.org (Postfix) with ESMTP id 1C1DD8FC12; Tue, 9 Dec 2008 04:49:09 +0000 (UTC) (envelope-from sobomax@FreeBSD.org) Received: from [192.168.1.38] (S0106001372fd1e07.vs.shawcable.net [70.71.171.106]) (authenticated bits=0) by sippysoft.com (8.13.8/8.13.8) with ESMTP id mB94n6KT010797 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Dec 2008 20:49:08 -0800 (PST) (envelope-from sobomax@FreeBSD.org) Message-ID: <493DF8A3.6070905@FreeBSD.org> Date: Mon, 08 Dec 2008 20:48:35 -0800 From: Maxim Sobolev Organization: Sippy Software, Inc. User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Luigi Rizzo References: <493DA269.2070805@FreeBSD.org> <20081208235119.GA46608@onelab2.iet.unipi.it> <493DBBD0.5080705@FreeBSD.org> <20081209034456.GA54569@onelab2.iet.unipi.it> In-Reply-To: <20081209034456.GA54569@onelab2.iet.unipi.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Luigi Rizzo , hackers@FreeBSD.org, "current@freebsd.org" Subject: Re: Enhancing cdboot [patch for review] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Dec 2008 04:49:10 -0000 Luigi Rizzo wrote: > On Mon, Dec 08, 2008 at 04:29:04PM -0800, Maxim Sobolev wrote: >> Luigi Rizzo wrote: > ... >>> 4. another nitpick -- the value you pass in %si to the MBR does not >>> seem to point to anything useful. As discussed about boot0.S and >>> the followup in the mailing lists, there seems to be no standard >>> but at least some MBR expect %si to point to a partition entry, >>> so you should probably initialize one in a way similar way to that >>> used by boot0.S >> Hmm, maybe I misunderstood it then. What do you mean by "point to >> partition entry exactly"? Right now it points to the beginning on MBR. > > ok, so here is what I know. > > Even though there is no standard, at least ldlinux.sys and perhaps > other bootloaders expect %si to point to a 16-byte record containing > the partition descriptor (same structure as one of the 4 records > at 0x1be in the MBR) for the partition they were loaded from. > > ldlinux.sys uses this info to "relocate": it knows the location of the > other sectors of ldlinux.sys relative to the beginning of the partition, > and uses the start-of-partition from the record at %si to compute > these locations in terms of absolute disk positions. > > Note that in principle a MBR does not need this info -- even if it > is a multi-sector boot code such as boot0ext, it may well assume to > be located at offset 0. > > On the other hand if the code on the MBR uses %si, then you should > set the entry so that at least the starting CHS and LBA info point > to the first sector on disk, i.e. CHS=0,0,1 and LBA=0. > > In practical terms -- make %si point to a 16-byte area of memory > containing all 0's except for the byte representing the sector > number for the start of the partition. > See the code in a recent sys/boot/i386/boot0/boot0.S which gives > some details on this. I see, thank you for the explanation. It looks like it only makes sense for multi-stage boot loaders, when the stage has been loaded from some location within the disk and it needs some clue to determine where it has came from. In this case we simply emulate BIOS loading MBR, and from what I've read here MBR code should make no assumptions with regard to %si, so that I would just set it to zero. Do you think it could create any issues? -Maxim From owner-freebsd-current@FreeBSD.ORG Tue Dec 9 05:51:24 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4F57B106564A for ; Tue, 9 Dec 2008 05:51:24 +0000 (UTC) (envelope-from subbsd@gmail.com) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.24]) by mx1.freebsd.org (Postfix) with ESMTP id D5E598FC12 for ; Tue, 9 Dec 2008 05:51:22 +0000 (UTC) (envelope-from subbsd@gmail.com) Received: by ey-out-2122.google.com with SMTP id 6so601737eyi.7 for ; Mon, 08 Dec 2008 21:51:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:reply-to:to:subject:date :user-agent:mime-version:content-type:content-transfer-encoding :content-disposition:message-id; bh=QIevGRUGoklFohpgNo9kfeBoikqOexfbMbEXmZSLScU=; b=KSrPresw5D58jJE4cgtEV7UgsVRSwgS/FWpza7B6/hBLzGRX3z3gu6OBKLzfXYHgI2 LEYbx3t0QuAWYB7SdyfGy5oZnPfeJ0OpO/7VYiss8DKpkK3Pcq880cJ+Zu+oVxH1MwIy Morv0h6DtpfOrH1buRu3jY2pCIELygfV7dDxg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:reply-to:to:subject:date:user-agent:mime-version:content-type :content-transfer-encoding:content-disposition:message-id; b=EOtHMAO9M7Y9ul0VxW1vjR1WqDNKPFdMGI8/mD+eiHnNe9q6lEEz9hqBJmxMwDerWj LwEeCOVEqCAoUevx+wZ9+wLZqLgWPrs8LGthdFpoUEgo5WBlycnWy0nCod0tzIPukcxx lpxwrv9a5B9nwO+znG7VbJU6ZDDS6e1ku/pi0= Received: by 10.103.217.5 with SMTP id u5mr1540700muq.118.1228801881573; Mon, 08 Dec 2008 21:51:21 -0800 (PST) Received: from localhost.invalid ([77.241.45.156]) by mx.google.com with ESMTPS id 7sm9895566mup.24.2008.12.08.21.51.19 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 08 Dec 2008 21:51:20 -0800 (PST) From: Ole Vole To: freebsd-current@freebsd.org Date: Tue, 9 Dec 2008 08:51:36 +0300 User-Agent: KMail/1.10.1 (FreeBSD/8.0-CURRENT; KDE/4.1.1; i386; ; ) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200812090851.36669.subbsd@gmail.com> Subject: setfib not ready ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: subbsd@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Dec 2008 05:51:24 -0000 Hello maillist, i want looking for multiple route table in HEAD. So, i try setfib -F 1 route add default 127.0.0.1 setfib -F 1 netstat -rn but it return: setfib: 1: invalid FIB (max 0) (setfib -F 0 work correct- with netstat -rn print my default route table) sysctl: oid 'net.fibs' is read only for sysctl -w net.fibs=2 however in the case seting net.fibs at loader stage (loader.conf) it not change something for adding route table. Is setfib(2) not ready for testing yet ? From owner-freebsd-current@FreeBSD.ORG Tue Dec 9 05:57:03 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5CE1A106564A for ; Tue, 9 Dec 2008 05:57:03 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: from pele.citylink.co.nz (pele.citylink.co.nz [202.8.44.226]) by mx1.freebsd.org (Postfix) with ESMTP id 1FD1B8FC08 for ; Tue, 9 Dec 2008 05:57:02 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: from localhost (localhost [127.0.0.1]) by pele.citylink.co.nz (Postfix) with ESMTP id 8725B2BC48; Tue, 9 Dec 2008 18:57:01 +1300 (NZDT) X-Virus-Scanned: Debian amavisd-new at citylink.co.nz Received: from pele.citylink.co.nz ([127.0.0.1]) by localhost (pele.citylink.co.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pcUP+c6pwjN7; Tue, 9 Dec 2008 18:56:57 +1300 (NZDT) Received: from citylink.fud.org.nz (unknown [202.8.44.45]) by pele.citylink.co.nz (Postfix) with ESMTP; Tue, 9 Dec 2008 18:56:57 +1300 (NZDT) Received: by citylink.fud.org.nz (Postfix, from userid 1001) id 58AEA11445; Tue, 9 Dec 2008 18:56:56 +1300 (NZDT) Date: Mon, 8 Dec 2008 21:56:56 -0800 From: Andrew Thompson To: Ole Vole Message-ID: <20081209055656.GC44675@citylink.fud.org.nz> References: <200812090851.36669.subbsd@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200812090851.36669.subbsd@gmail.com> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: freebsd-current@freebsd.org Subject: Re: setfib not ready ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Dec 2008 05:57:03 -0000 On Tue, Dec 09, 2008 at 08:51:36AM +0300, Ole Vole wrote: > Hello maillist, > > i want looking for multiple route table in HEAD. So, i try > > setfib -F 1 route add default 127.0.0.1 > setfib -F 1 netstat -rn > but it return: > setfib: 1: invalid FIB (max 0) > > (setfib -F 0 work correct- with netstat -rn print my default route table) > > sysctl: oid 'net.fibs' is read only for > > sysctl -w net.fibs=2 > however in the case seting net.fibs at loader stage (loader.conf) it not > change something for adding route table. > > Is setfib(2) not ready for testing yet ? You can only use loader.conf to set the numbre of fibs to a lower number than is compiled in to your kernel, use "options ROUTETABLES=2" in your kernel config instead (or more than 2 if needed). Andrew From owner-freebsd-current@FreeBSD.ORG Tue Dec 9 07:37:50 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E3C851065783 for ; Tue, 9 Dec 2008 07:37:50 +0000 (UTC) (envelope-from jackie@boolome.com) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.185]) by mx1.freebsd.org (Postfix) with ESMTP id 7EC3B8FC16 for ; Tue, 9 Dec 2008 07:37:50 +0000 (UTC) (envelope-from jackie@boolome.com) Received: by ti-out-0910.google.com with SMTP id a1so900137tib.3 for ; Mon, 08 Dec 2008 23:37:49 -0800 (PST) Received: by 10.110.42.17 with SMTP id p17mr5238127tip.42.1228808269093; Mon, 08 Dec 2008 23:37:49 -0800 (PST) Received: from ?192.168.1.100? ([60.210.216.198]) by mx.google.com with ESMTPS id 22sm1947233tim.15.2008.12.08.23.37.46 (version=SSLv3 cipher=RC4-MD5); Mon, 08 Dec 2008 23:37:47 -0800 (PST) From: boolome To: freebsd-current@freebsd.org Content-Type: text/plain Organization: boolome Date: Tue, 09 Dec 2008 15:37:32 +0800 Message-Id: <1228808252.58600.1.camel@www.boolome.cn> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Subject: heads up : can not buildworld go on X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Dec 2008 07:37:51 -0000 cvsup to latest source tree ! m -lnvpair -luutil -lutil zfs_main.o(.text+0x15a): In function `unallow_callback': : undefined reference to `zfs_perm_remove' zfs_main.o(.text+0xa59): In function `unshare_unmount_path': : undefined reference to `zfs_unshareall_bypath' zfs_main.o(.text+0x125b): In function `share_mount_one': : undefined reference to `zfs_is_shared_smb' zfs_main.o(.text+0x13ba): In function `share_mount_one': : undefined reference to `zfs_share_smb' zfs_main.o(.text+0x1404): In function `share_mount_one': : undefined reference to `zfs_shareall' zfs_main.o(.text+0x1572): In function `upgrade_set_callback': : undefined reference to `zfs_spa_version' zfs_main.o(.text+0x16d1): In function `upgrade_set_callback': : undefined reference to `zpool_stage_history' zfs_main.o(.text+0x195a): In function `get_callback': : undefined reference to `zprop_print_one_property' zfs_main.o(.text+0x1a56): In function `get_callback': : undefined reference to `zprop_print_one_property' zfs_main.o(.text+0x2725): In function `usage': : undefined reference to `zfs_deleg_permissions' zfs_main.o(.text+0x28d2): In function `usage': : undefined reference to `zprop_iter' zfs_main.o(.text+0x2a27): In function `main': : undefined reference to `zpool_set_history_str' zfs_main.o(.text+0x2a3c): In function `main': : undefined reference to `zpool_stage_history' zfs_main.o(.text+0x42ae): In function `zfs_do_rename': : undefined reference to `zfs_create_ancestors' zfs_main.o(.text+0x45b8): In function `zfs_do_list': : undefined reference to `zprop_get_list' zfs_main.o(.text+0x4616): In function `zfs_do_list': : undefined reference to `zprop_free_list' zfs_main.o(.text+0x5052): In function `zfs_do_get': : undefined reference to `zprop_get_list' zfs_main.o(.text+0x50cf): In function `zfs_do_get': : undefined reference to `zprop_free_list' zfs_main.o(.text+0x50f3): In function `zfs_do_get': : undefined reference to `zprop_free_list' zfs_main.o(.text+0x5973): In function `zfs_do_create': : undefined reference to `zpool_get_prop_int' zfs_main.o(.text+0x5a3f): In function `zfs_do_create': : undefined reference to `zfs_dataset_exists' zfs_main.o(.text+0x5a5d): In function `zfs_do_create': : undefined reference to `zfs_create_ancestors' zfs_main.o(.text+0x5ccd): In function `zfs_do_clone': : undefined reference to `zfs_dataset_exists' zfs_main.o(.text+0x5ce9): In function `zfs_do_clone': : undefined reference to `zfs_create_ancestors' zfs_main.o(.text+0x628e): In function `parse_allow_args': : undefined reference to `zfs_build_perms' zfs_main.o(.text+0x6479): In function `zfs_do_allow': : undefined reference to `zfs_perm_set' zfs_main.o(.text+0x6573): In function `zfs_do_allow': : undefined reference to `zfs_perm_get' zfs_main.o(.text+0x67fe): In function `zfs_do_allow': : undefined reference to `zfs_free_allows' zfs_main.o(.text+0x6d4c): In function `unshare_unmount': : undefined reference to `zfs_unshareall_bypath' zfs_main.o(.text+0x7332): In function `unshare_unmount': : undefined reference to `zfs_unshareall' zfs_iter.o(.text+0x17b): In function `zfs_callback': : undefined reference to `zfs_get_pool_handle' zfs_iter.o(.text+0x193): In function `zfs_callback': : undefined reference to `zpool_get_prop_int' *** Error code 1 Stop in /usr/src/cddl/sbin/zfs. *** Error code 1 Stop in /usr/src/cddl/sbin. *** Error code 1 Stop in /usr/src/cddl. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. From owner-freebsd-current@FreeBSD.ORG Tue Dec 9 09:32:52 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 48A821065670; Tue, 9 Dec 2008 09:32:52 +0000 (UTC) (envelope-from nakaji@kankyo-u.ac.jp) Received: from www.heimat.gr.jp (unknown [IPv6:2001:3e0:a84::1]) by mx1.freebsd.org (Postfix) with ESMTP id B872B8FC16; Tue, 9 Dec 2008 09:32:51 +0000 (UTC) (envelope-from nakaji@kankyo-u.ac.jp) X-Virus-Scanned: amavisd-new at heimat.gr.jp Received: from ra333.heimat.gr.jp.kankyo-u.ac.jp (ra333.heimat.gr.jp [IPv6:2001:3e0:a84:0:200:4cff:fe17:573c]) by www.heimat.gr.jp (8.14.3/8.14.3) with ESMTP id mB99WXJq015562; Tue, 9 Dec 2008 18:32:33 +0900 (JST) (envelope-from nakaji@kankyo-u.ac.jp) From: NAKAJI Hiroyuki To: "Kip Macy" References: <87zljb8nw6.fsf@roddy.4407.kankyo-u.ac.jp> <3a142e750812050613w4e9155bat950f03716aa58beb@mail.gmail.com> <863ah2qivi.fsf@ra333.heimat.gr.jp> <86iqpu2sjc.fsf@ra333.heimat.gr.jp> <3c1674c90812081449r7b8ef242lce478da3d2d7a968@mail.gmail.com> Date: Tue, 09 Dec 2008 18:32:33 +0900 In-Reply-To: <3c1674c90812081449r7b8ef242lce478da3d2d7a968@mail.gmail.com> (Kip Macy's message of "Mon, 8 Dec 2008 14:49:50 -0800") Message-ID: <864p1d3d8u.fsf@ra333.heimat.gr.jp> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.60 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-5.0 required=13.0 tests=BAYES_00, CONTENT_TYPE_PRESENT, FAKEDWORD_ZERO, MIMEQENC, NO_RELAYS, QENCPTR1, QENCPTR2 autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on www.heimat.gr.jp Cc: freebsd-current@freebsd.org Subject: Re: Fatal trap 12: page fault while in kernel mode X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Dec 2008 09:32:52 -0000 >>>>> In <3c1674c90812081449r7b8ef242lce478da3d2d7a968@mail.gmail.com>=20 >>>>> "Kip Macy" wrote: > Recently - starting when? I noticed that panics since late November. But I forgot the day. My last update of the world was in October. Thanks. > On Mon, Dec 8, 2008 at 2:47 PM, NAKAJI Hiroyuki w= rote: > >>>>>> In <863ah2qivi.fsf@ra333.heimat.gr.jp> > >>>>>> NAKAJI Hiroyuki wrote: > > > >> So, what I have to do are three: > > > >> 1. Full upgrade to the latest kernel and userland (world) > >> 2. Observe whether a panic occurs, and > >> 3. When panic, save the crash dump and get full bt with kgdb > > > >> I hope it will not reach to the step three. Thanks. > > > > Unfortunately, I faced to "db> " on my serial console. > > > > db> bt > > Tracing pid 964 tid 100131 td 0xc49876c0 > > svc_run_internal(e6861d24,c0850793,c44f2780,e6861d38,1,...) at svc_run_= internal+ > > 0x575 > > svc_thread_start(c44f2780,e6861d38,1,0,4836bd14,...) at svc_thread_star= t+0x10 > > fork_exit(c0a57fe0,c44f2780,e6861d38) at fork_exit+0x93 > > fork_trampoline() at fork_trampoline+0x8 > > --- trap 0, eip =3D 0xc, esp =3D 0x33, ebp =3D 0 --- > > db> call doadump > > Physical memory: 1010 MB > > Dumping 250 MB: 235 219 203 187 171 155 139 123 107 91 75 59 43 27 11 > > Dump complete > > =3D 0xf > > db> bt > > Tracing pid 964 tid 100131 td 0xc49876c0 > > svc_run_internal(e6861d24,c0850793,c44f2780,e6861d38,1,...) at svc_run_= internal+ > > 0x575 > > svc_thread_start(c44f2780,e6861d38,1,0,4836bd14,...) at svc_thread_star= t+0x10 > > fork_exit(c0a57fe0,c44f2780,e6861d38) at fork_exit+0x93 > > fork_trampoline() at fork_trampoline+0x8 > > --- trap 0, eip =3D 0xc, esp =3D 0x33, ebp =3D 0 --- > > db> reset > > > > And then, I used kgdb. > > > > # kgdb /boot/kernel/kernel.symbols vmcore.9 > > GNU gdb 6.1.1 [FreeBSD] > > Copyright 2004 Free Software Foundation, Inc. > > GDB is free software, covered by the GNU General Public License, and yo= u are > > welcome to change it and/or distribute copies of it under certain condi= tions. > > Type "show copying" to see the conditions. > > There is absolutely no warranty for GDB. Type "show warranty" for deta= ils. > > This GDB was configured as "i386-marcel-freebsd"... > > > > Unread portion of the kernel message buffer: > > > > > > Fatal trap 12: page fault while in kernel mode > > cpuid =3D 0; apic id =3D 00 > > fault virtual address =3D 0x0 > > fault code =3D supervisor read, page not present > > instruction pointer =3D 0x20:0xc0a57a75 > > stack pointer =3D 0x28:0xe6861c44 > > frame pointer =3D 0x28:0xe6861cec > > code segment =3D base 0x0, limit 0xfffff, type 0x1b > > =3D DPL 0, pres 1, def32 1, gran 1 > > processor eflags =3D interrupt enabled, resume, IOPL =3D 0 > > current process =3D 964 (nfsd: service) > > Physical memory: 1010 MB > > Dumping 250 MB: 235 219 203 187 171 155 139 123 107 91 75 59 43 27 11 > > > > Reading symbols from /boot/kernel/linprocfs.ko...Reading symbols from /= boot/kernel/linprocfs.ko.symbols...done. > > done. > > Loaded symbols for /boot/kernel/linprocfs.ko > > Reading symbols from /boot/kernel/linux.ko...Reading symbols from /boot= /kernel/linux.ko.symbols...done. > > done. > > Loaded symbols for /boot/kernel/linux.ko > > Reading symbols from /boot/kernel/smbus.ko...Reading symbols from /boot= /kernel/smbus.ko.symbols...done. > > done. > > Loaded symbols for /boot/kernel/smbus.ko > > Reading symbols from /boot/kernel/aio.ko...Reading symbols from /boot/k= ernel/aio.ko.symbols...done. > > done. > > Loaded symbols for /boot/kernel/aio.ko > > Reading symbols from /boot/kernel/mga.ko...Reading symbols from /boot/k= ernel/mga.ko.symbols...done. > > done. > > Loaded symbols for /boot/kernel/mga.ko > > Reading symbols from /boot/kernel/drm.ko...Reading symbols from /boot/k= ernel/drm.ko.symbols...done. > > done. > > Loaded symbols for /boot/kernel/drm.ko > > Reading symbols from /boot/kernel/atapicam.ko...Reading symbols from /b= oot/kernel/atapicam.ko.symbols...done. > > done. > > Loaded symbols for /boot/kernel/atapicam.ko > > Reading symbols from /boot/kernel/nullfs.ko...Reading symbols from /boo= t/kernel/nullfs.ko.symbols...done. > > done. > > Loaded symbols for /boot/kernel/nullfs.ko > > Reading symbols from /boot/kernel/logo_saver.ko...Reading symbols from = /boot/kernel/logo_saver.ko.symbols...done. > > done. > > Loaded symbols for /boot/kernel/logo_saver.ko > > #0 doadump () at pcpu.h:246 > > 246 pcpu.h: No such file or directory. > > in pcpu.h > > (kgdb) bt > > #0 doadump () at pcpu.h:246 > > #1 0xc04c2a69 in db_fncall (dummy1=3D-1059812576, dummy2=3D0, dummy3= =3D-1067505768, > > dummy4=3D0xe68619d8 "=EF=BF=BD:i=EF=BF=BD\2008'=EF=BF=BD") at /usr/s= rc/sys/ddb/db_command.c:548 > > #2 0xc04c2e61 in db_command (last_cmdp=3D0xc0d3e85c, cmd_table=3D0x0, = dopager=3D1) > > at /usr/src/sys/ddb/db_command.c:445 > > #3 0xc04c2fba in db_command_loop () at /usr/src/sys/ddb/db_command.c:4= 98 > > #4 0xc04c4dfd in db_trap (type=3D12, code=3D0) at /usr/src/sys/ddb/db_= main.c:229 > > #5 0xc08a2456 in kdb_trap (type=3D12, code=3D0, tf=3D0xe6861c04) > > at /usr/src/sys/kern/subr_kdb.c:534 > > #6 0xc0b8059f in trap_fatal (frame=3D0xe6861c04, eva=3D0) > > at /usr/src/sys/i386/i386/trap.c:920 > > #7 0xc0b80860 in trap_pfault (frame=3D0xe6861c04, usermode=3D0, eva=3D= 0) > > at /usr/src/sys/i386/i386/trap.c:842 > > #8 0xc0b8126a in trap (frame=3D0xe6861c04) at /usr/src/sys/i386/i386/t= rap.c:522 > > #9 0xc0b652cb in calltrap () at /usr/src/sys/i386/i386/exception.s:165 > > #10 0xc0a57a75 in svc_run_internal (pool=3D0xc44f2780, ismaster=3D0) > > at /usr/src/sys/rpc/svc.c:787 > > #11 0xc0a57ff0 in svc_thread_start (arg=3D0xc44f2780) > > at /usr/src/sys/rpc/svc.c:1188 > > #12 0xc0850793 in fork_exit (callout=3D0xc0a57fe0 , > > arg=3D0xc44f2780, frame=3D0xe6861d38) at /usr/src/sys/kern/kern_fork= .c:821 > > #13 0xc0b65340 in fork_trampoline () at /usr/src/sys/i386/i386/exceptio= n.s:270 > > (kgdb) > > > > In addition, > > > > # addr2line -e /boot/kernel/kernel.symbols 0xc0a57a75 > > /usr/src/sys/rpc/svc.c:787 > > > > Any help is appreciated. Thanks. > > -- > > NAKAJI Hiroyuki > > _______________________________________________ > > freebsd-current@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.o= rg" > > > --=20 > If we desire respect for the law, we must first make the law respectable. > - Louis D. Brandeis --=20 NAKAJI Hiroyuki From owner-freebsd-current@FreeBSD.ORG Tue Dec 9 10:59:53 2008 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D93EB1065676 for ; Tue, 9 Dec 2008 10:59:53 +0000 (UTC) (envelope-from mattik@bigpond.net.au) Received: from nschwqsrv03p.mx.bigpond.com (nschwqsrv03p.mx.bigpond.com [61.9.189.237]) by mx1.freebsd.org (Postfix) with ESMTP id 66DB98FC1B for ; Tue, 9 Dec 2008 10:59:53 +0000 (UTC) (envelope-from mattik@bigpond.net.au) Received: from nschwotgx01p.mx.bigpond.com ([121.210.38.110]) by nschwmtas02p.mx.bigpond.com with ESMTP id <20081209083754.ORKL22514.nschwmtas02p.mx.bigpond.com@nschwotgx01p.mx.bigpond.com>; Tue, 9 Dec 2008 08:37:54 +0000 Received: from [192.168.1.77] (really [121.210.38.110]) by nschwotgx01p.mx.bigpond.com with ESMTP id <20081209083753.UHVP18392.nschwotgx01p.mx.bigpond.com@[192.168.1.77]>; Tue, 9 Dec 2008 08:37:53 +0000 In-Reply-To: <20081207223009.GA27635@macbook.catpipe.net> References: <20081207223009.GA27635@macbook.catpipe.net> Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: matti k Date: Tue, 9 Dec 2008 19:37:53 +1100 To: Phil Regnauld X-Mailer: Apple Mail (2.753.1) X-Authentication-Info: Submitted using SMTP AUTH PLAIN at nschwotgx01p.mx.bigpond.com from [121.210.38.110] using ID mattik@bigpond.net.au at Tue, 9 Dec 2008 08:37:53 +0000 X-RPD-ScanID: Class unknown; VirusThreatLevel unknown, RefID str=0001.0A150202.493E2E62.0025,ss=1,fgs=0 Cc: freebsd-current@FreeBSD.org Subject: Re: em(4) not sending/receiving data in recent current ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Dec 2008 10:59:53 -0000 On 08/12/2008, at 9:30 AM, Phil Regnauld wrote: > Hi all, > > I recently upgraded a system (Dell Vostro desktop) running > 8.0-CURRENT/amd64 from July to -current from a few days ago, > and em(4) stopped working. > > By this I mean: > > - em0 probes and attaches correctly > - link is detected > - sending any data to/from the host simply fails I have this same issue with fxp(4) on i386, last updated 2 days ago. I noticed a missing include was restored to sys/dev/e1000/if_em.c and presume that has fixed em(4)? Doesn't help with fxp(4) though ... I tried. Would appreciate any help getting networking going again. Cheers, Matti From owner-freebsd-current@FreeBSD.ORG Tue Dec 9 12:47:25 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AF7701065677 for ; Tue, 9 Dec 2008 12:47:25 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.237]) by mx1.freebsd.org (Postfix) with ESMTP id 7DEB78FC18 for ; Tue, 9 Dec 2008 12:47:24 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so1622345rvf.43 for ; Tue, 09 Dec 2008 04:47:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:cc:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=VZHlcuq4VImYs90EfYILaRe8JP6n9LY/cGlw5tZgLoE=; b=EVW9INVIjwrWgr00e520QfjG4z9pK6W0kMHoUPe0mgkPKIzybLxIC5LXfjXOs6i8c8 O2sbSMCrJM1y3P/NLuP8C7ekYc47VdORr3BQ/DPW7UpyQFJG8Nqi7S50nlIyGrPaXFhB RPl/Rc5OBAJ+UxRC7XBZkZnjLOt44pcsAKzKc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=cc:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=A45tzHTiqINo5m3TVrNRZtamsJB5EsIskt3fNvwCI32vE3hqce49n8JncgtsORrKrl rWLtJsRAoeb9YXjj2ibM8TU41CzODVKCwcRrIWlI4eHqL0+dRIsi3Fs1H0uVHjH5IcUj 0GtE6+UtRXaONnKcQNaLMxcrFwTV59NNWTkHA= Received: by 10.141.115.16 with SMTP id s16mr33231rvm.209.1228826844540; Tue, 09 Dec 2008 04:47:24 -0800 (PST) Received: from ?192.168.10.3? (adsl-76-254-4-6.dsl.pltn13.sbcglobal.net [76.254.4.6]) by mx.google.com with ESMTPS id g14sm5363255rvb.0.2008.12.09.04.47.23 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 09 Dec 2008 04:47:23 -0800 (PST) Message-Id: <53DC39AE-EE1E-41DE-801D-45737249D93B@gmail.com> From: Garrett Cooper To: boolome In-Reply-To: <1228787330.13158.0.camel@www.boolome.cn> Content-Type: text/plain; charset=UTF-8; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v929.2) Date: Tue, 9 Dec 2008 03:18:42 -0800 References: <1228555830.1186.6.camel@www.boolome.cn> <7d6fde3d0812080155y22cc7c0bne1fa0094671355e4@mail.gmail.com> <1228787330.13158.0.camel@www.boolome.cn> X-Mailer: Apple Mail (2.929.2) Cc: freebsd-current@freebsd.org Subject: Re: make buildworld failed! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Dec 2008 12:47:25 -0000 On Dec 8, 2008, at 5:48 PM, boolome wrote: > =E5=9C=A8 2008-12-08=E4=B8=80=E7=9A=84 01:55 -0800=EF=BC=8CGarrett = Cooper=E5=86=99=E9=81=93=EF=BC=9A >> On Sat, Dec 6, 2008 at 1:30 AM, boolome wrote: >> [snip] >> >> Looks like your source tree is incomplete. >> -Garrett > > But have cvsup the latest source tree ! It's not necessarily your fault though. What cvsup server are you =20 using and did you interrupt it during an update? -Garrett= From owner-freebsd-current@FreeBSD.ORG Tue Dec 9 14:36:36 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 920961065675 for ; Tue, 9 Dec 2008 14:36:36 +0000 (UTC) (envelope-from elias@artx.ru) Received: from round.artx.ru (round.artx.ru [80.73.175.73]) by mx1.freebsd.org (Postfix) with ESMTP id 4C1738FC0C for ; Tue, 9 Dec 2008 14:36:36 +0000 (UTC) (envelope-from elias@artx.ru) Received: by round.artx.ru (Postfix, from userid 1001) id 70E4A5C27; Tue, 9 Dec 2008 17:19:08 +0300 (MSK) Date: Tue, 9 Dec 2008 17:19:08 +0300 From: Ilya Orehov To: "M. Warner Losh" Message-ID: <20081209141908.GA15845@artx.ru> References: <20081205174838.GA22652@albert.catwhisker.org> <20081205.120056.255409238.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20081205.120056.255409238.imp@bsdimp.com> User-Agent: Mutt/1.4.2.3i Cc: current@freebsd.org Subject: Re: "interrupt storm..."; seems associated with an0 NIC X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Dec 2008 14:36:36 -0000 +------- M. Warner Losh, 2008-12-05 ------- | Thanks. Grump. Will have to back out and try again. Hello! I see storm too, but with 32-bit cards. Thinkpad 600X, two cardbus cards: xl0 and ath0. Since pccbb.c 1.176 and pccbb_pci.c 1.30 after rebooting with card(s) inserted or inserting any card I see "interrupt storm...throttling..." messages about 1 per second. Laptop remains usable, cards working. Storm don't stop even if I eject all cards. During storm, vmstat -i shows rate ~500 on cbb. No messages appeared if laptop rebooted without cards (until any card inserted). Later revisions ( pccbb.c 1.178 and pccbb_pci.c 1.31) didn't bring any visible changes. But this hack helped. No storm detected, vmstat -i shows rate 0 or 1 on cbb. diff -up xxx/pccbb_pci.c ./pccbb_pci.c --- xxx/pccbb_pci.c 2008-12-06 11:56:00.000000000 +0300 +++ ./pccbb_pci.c 2008-12-09 14:08:03.000000000 +0300 @@ -689,6 +689,7 @@ cbb_pci_filt(void *arg) struct cbb_softc *sc = arg; uint32_t sockevent; int retval = FILTER_STRAY; + int ack = 0; /* * Read the socket event. Sometimes, the theory goes, the PCI @@ -722,6 +723,7 @@ cbb_pci_filt(void *arg) sc->cardok = 0; cbb_disable_func_intr(sc); wakeup(&sc->intrhand); + ack = 1; } /* * If we get a power interrupt, wakeup anybody that might @@ -732,7 +734,10 @@ cbb_pci_filt(void *arg) cbb_set(sc, CBB_SOCKET_EVENT, CBB_SOCKET_EVENT_POWER); sc->powerintr++; wakeup((void *)&sc->powerintr); + ack = 1; } + if (!ack) + cbb_set(sc, CBB_SOCKET_EVENT, sockevent); retval = FILTER_HANDLED; } /* Do you need dmesg or some other info? regards, Ilya. | | Warner | _______________________________________________ | freebsd-current@freebsd.org mailing list | http://lists.freebsd.org/mailman/listinfo/freebsd-current | To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" | +----------------------------- From owner-freebsd-current@FreeBSD.ORG Tue Dec 9 14:57:24 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BB6031065672 for ; Tue, 9 Dec 2008 14:57:24 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 8144D8FC19 for ; Tue, 9 Dec 2008 14:57:24 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by smarthost1.sentex.ca (8.14.3/8.14.3) with ESMTP id mB9EvMZC029901; Tue, 9 Dec 2008 09:57:22 -0500 (EST) (envelope-from mike@sentex.net) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.13.8/8.13.3) with ESMTP id mB9EvLSD047534 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 9 Dec 2008 09:57:21 -0500 (EST) (envelope-from mike@sentex.net) Message-Id: <200812091457.mB9EvLSD047534@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 09 Dec 2008 09:57:20 -0500 To: Marcel Moolenaar From: Mike Tancsa In-Reply-To: <7.1.0.9.0.20081208173515.13f62e88@sentex.net> References: <200812081621.mB8GLMxB041498@lava.sentex.ca> <200812081906.mB8J6oha042222@lava.sentex.ca> <200812082049.mB8KnHSN042710@lava.sentex.ca> <84A7F176-5A74-48AC-859A-C0D4C7CBCB48@mac.com> <7.1.0.9.0.20081208173515.13f62e88@sentex.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: freebsd-current@freebsd.org Subject: Re: uart vs sio differences ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Dec 2008 14:57:24 -0000 At 05:39 PM 12/8/2008, Mike Tancsa wrote: >What it appears to be is that as long as data is coming in, even at >1200bps, the ioctl FIONREAD returns zero and an actual read does not >return any data until there is either a pause in the data coming in >or possibly when we do a xmit/write at which point the accumulated >data is available for us to read. > >We dont know if this is due to the hardware fifo or something in the >driver itself. OK, I think we found the issue! http://www.freebsd.org/cgi/query-pr.cgi?pr=121421 Not sure if the semantics are exactly right, but adding hint.uart.0.flags="0x100" hint.uart.1.flags="0x100" hint.uart.2.flags="0x100" hint.uart.3.flags="0x100" to device.hints fixed the issue! The next question-- is there a way to do this with the ucom driver as well ? We are seeing the same issue with it. ---Mike From owner-freebsd-current@FreeBSD.ORG Tue Dec 9 16:30:42 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C396A1065670 for ; Tue, 9 Dec 2008 16:30:42 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 80F568FC2E for ; Tue, 9 Dec 2008 16:30:42 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id mB9GRUkf095798; Tue, 9 Dec 2008 09:27:30 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Tue, 09 Dec 2008 09:27:39 -0700 (MST) Message-Id: <20081209.092739.35219831.imp@bsdimp.com> To: elias@artx.ru From: "M. Warner Losh" In-Reply-To: <20081209141908.GA15845@artx.ru> References: <20081205174838.GA22652@albert.catwhisker.org> <20081205.120056.255409238.imp@bsdimp.com> <20081209141908.GA15845@artx.ru> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: "interrupt storm..."; seems associated with an0 NIC X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Dec 2008 16:30:42 -0000 In message: <20081209141908.GA15845@artx.ru> Ilya Orehov writes: : +------- M. Warner Losh, 2008-12-05 ------- : | Thanks. Grump. Will have to back out and try again. : : Hello! : : I see storm too, but with 32-bit cards. : : Thinkpad 600X, two cardbus cards: xl0 and ath0. : : Since pccbb.c 1.176 and pccbb_pci.c 1.30 : after rebooting with card(s) inserted or inserting any card : I see "interrupt storm...throttling..." messages about 1 per second. : Laptop remains usable, cards working. : Storm don't stop even if I eject all cards. : During storm, vmstat -i shows rate ~500 on cbb. : No messages appeared if laptop rebooted without cards : (until any card inserted). : : Later revisions ( pccbb.c 1.178 and pccbb_pci.c 1.31) : didn't bring any visible changes. : : But this hack helped. : No storm detected, vmstat -i shows rate 0 or 1 on cbb. : : diff -up xxx/pccbb_pci.c ./pccbb_pci.c : --- xxx/pccbb_pci.c 2008-12-06 11:56:00.000000000 +0300 : +++ ./pccbb_pci.c 2008-12-09 14:08:03.000000000 +0300 : @@ -689,6 +689,7 @@ cbb_pci_filt(void *arg) : struct cbb_softc *sc = arg; : uint32_t sockevent; : int retval = FILTER_STRAY; : + int ack = 0; : : /* : * Read the socket event. Sometimes, the theory goes, the PCI : @@ -722,6 +723,7 @@ cbb_pci_filt(void *arg) : sc->cardok = 0; : cbb_disable_func_intr(sc); : wakeup(&sc->intrhand); : + ack = 1; : } : /* : * If we get a power interrupt, wakeup anybody that might : @@ -732,7 +734,10 @@ cbb_pci_filt(void *arg) : cbb_set(sc, CBB_SOCKET_EVENT, CBB_SOCKET_EVENT_POWER); : sc->powerintr++; : wakeup((void *)&sc->powerintr); : + ack = 1; : } : + if (!ack) : + cbb_set(sc, CBB_SOCKET_EVENT, sockevent); : retval = FILTER_HANDLED; : } : /* : : Do you need dmesg or some other info? Can you please do the following: + if (!ack) { + printf("Need to ack %#x\n", sockevent); + cbb_set(sc, CBB_SOCKET_EVENT, sockevent); + } And let me know what it says? Warner From owner-freebsd-current@FreeBSD.ORG Tue Dec 9 16:37:03 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8B8C5106564A for ; Tue, 9 Dec 2008 16:37:03 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [192.147.25.65]) by mx1.freebsd.org (Postfix) with ESMTP id 5EFF58FC1B for ; Tue, 9 Dec 2008 16:37:03 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from 64.3.1.253.ptr.us.xo.net ([64.3.1.253]:28519 helo=LROSENMAN) by thebighonker.lerctr.org with esmtpa (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LA5a1-0003yk-9i for freebsd-current@freebsd.org; Tue, 09 Dec 2008 10:37:02 -0600 From: "Larry Rosenman" To: Date: Tue, 9 Dec 2008 10:36:51 -0600 Message-ID: <004901c95a1c$5c6b2680$15417380$@org> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 thread-index: AclaHFY0TXxGu0hTQoi2lybbzt6j4g== Content-Language: en-us X-Spam-Score: -2.5 (--) X-LERCTR-Spam-Score: -2.5 (--) X-Spam-Report: SpamScore (-2.5/5.0) ALL_TRUSTED=-1.8, BAYES_00=-2.599, TVD_RCVD_IP=1.931 X-LERCTR-Spam-Report: SpamScore (-2.5/5.0) ALL_TRUSTED=-1.8, BAYES_00=-2.599, TVD_RCVD_IP=1.931 DomainKey-Status: no signature Subject: Why does host and dig show a ; as \;? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Dec 2008 16:37:03 -0000 Why does the host command, dig, and a named_db.dump all show a ; as \; in a TXT record? This confuses folks like me that are trying to verify DK and DKIM TXT records. Thanks! -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 512-248-2683 E-Mail: ler@lerctr.org US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 From owner-freebsd-current@FreeBSD.ORG Tue Dec 9 16:56:56 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 77A24106567B for ; Tue, 9 Dec 2008 16:56:56 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 3DA3B8FC1C for ; Tue, 9 Dec 2008 16:56:56 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by smarthost1.sentex.ca (8.14.3/8.14.3) with ESMTP id mB9GusDQ052539; Tue, 9 Dec 2008 11:56:54 -0500 (EST) (envelope-from mike@sentex.net) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.13.8/8.13.3) with ESMTP id mB9Gusd7048089 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 9 Dec 2008 11:56:54 -0500 (EST) (envelope-from mike@sentex.net) Message-Id: <200812091656.mB9Gusd7048089@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 09 Dec 2008 11:56:53 -0500 To: Marcel Moolenaar From: Mike Tancsa In-Reply-To: <200812091457.mB9EvLSD047534@lava.sentex.ca> References: <200812081621.mB8GLMxB041498@lava.sentex.ca> <200812081906.mB8J6oha042222@lava.sentex.ca> <200812082049.mB8KnHSN042710@lava.sentex.ca> <84A7F176-5A74-48AC-859A-C0D4C7CBCB48@mac.com> <7.1.0.9.0.20081208173515.13f62e88@sentex.net> <200812091457.mB9EvLSD047534@lava.sentex.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: freebsd-current@freebsd.org Subject: Re: uart vs sio differences ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Dec 2008 16:56:56 -0000 At 09:57 AM 12/9/2008, Mike Tancsa wrote: >The next question-- is there a way to do this with the ucom driver >as well ? We are seeing the same issue with it. Not sure if its the "best" way to do it, but http://lists.freebsd.org/pipermail/freebsd-usb/2008-December/005817.html seems to fix it for our app. ---Mike From owner-freebsd-current@FreeBSD.ORG Tue Dec 9 17:42:02 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 772771065670 for ; Tue, 9 Dec 2008 17:42:02 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id 0EE648FC13 for ; Tue, 9 Dec 2008 17:42:01 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from phobos.local ([192.168.254.200]) (authenticated bits=0) by pooker.samsco.org (8.14.2/8.14.2) with ESMTP id mB9HfwCt019827; Tue, 9 Dec 2008 10:41:58 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <493EADE6.60508@samsco.org> Date: Tue, 09 Dec 2008 10:41:58 -0700 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.13) Gecko/20080313 SeaMonkey/1.1.9 MIME-Version: 1.0 To: Mike Tancsa References: <200812081621.mB8GLMxB041498@lava.sentex.ca> <200812081906.mB8J6oha042222@lava.sentex.ca> <200812082049.mB8KnHSN042710@lava.sentex.ca> <84A7F176-5A74-48AC-859A-C0D4C7CBCB48@mac.com> <7.1.0.9.0.20081208173515.13f62e88@sentex.net> <200812091457.mB9EvLSD047534@lava.sentex.ca> <493EA759.4000504@samsco.org> In-Reply-To: <493EA759.4000504@samsco.org> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.4 required=3.8 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on pooker.samsco.org Cc: Marcel Moolenaar , freebsd-current@freebsd.org Subject: Re: uart vs sio differences ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Dec 2008 17:42:02 -0000 Scott Long wrote: > Mike Tancsa wrote: >> At 05:39 PM 12/8/2008, Mike Tancsa wrote: >> >>> What it appears to be is that as long as data is coming in, even at >>> 1200bps, the ioctl FIONREAD returns zero and an actual read does not >>> return any data until there is either a pause in the data coming in >>> or possibly when we do a xmit/write at which point the accumulated >>> data is available for us to read. >>> >>> We dont know if this is due to the hardware fifo or something in the >>> driver itself. >> >> OK, I think we found the issue! >> >> http://www.freebsd.org/cgi/query-pr.cgi?pr=121421 >> >> Not sure if the semantics are exactly right, but adding >> >> hint.uart.0.flags="0x100" >> hint.uart.1.flags="0x100" >> hint.uart.2.flags="0x100" >> hint.uart.3.flags="0x100" >> >> to device.hints fixed the issue! >> >> The next question-- is there a way to do this with the ucom driver as >> well ? We are seeing the same issue with it. >> >> ---Mike > > It's pretty sad that the uart driver can't keep up with the 16550 at > full FIFO depth, though I can see exactly why. Even though the driver > will normally use a fast interrupt handler, that handler does nothing > but schedule the sio swi thread. Well, I shouldn't say that that's the > only thing it does; it also does a spinwait on a home-rolled semaphore > with the swi thread, something that I'm not sure I understand. Maybe > the author thought that there was a risk of missed wakeups of the swi? > > That aside, I think what needs to happen is for the driver to use the > interrupt handler to pull the bytes out of the hardware and into an > internal lockless ring buffer, then schedule the swi to process the ring > buffer. I'll see if I can come up with some code for this today. Not > sure if the same can be done for ucom since the USB stack below it > presents a lot more complications and overhead. > > Scott > Bah, that's what I get for reading code before I'm awake. The uart driver does do exactly what I suggest it should. It has a 384 byte ring buffer, which should be more than enough. So I wonder if the spin-wait on the swi semaphore is what is killing it, though. Scott From owner-freebsd-current@FreeBSD.ORG Tue Dec 9 17:50:09 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 573C21065675 for ; Tue, 9 Dec 2008 17:50:09 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id E383E8FC0C for ; Tue, 9 Dec 2008 17:50:08 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from phobos.local ([192.168.254.200]) (authenticated bits=0) by pooker.samsco.org (8.14.2/8.14.2) with ESMTP id mB9HE19Q019707; Tue, 9 Dec 2008 10:14:01 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <493EA759.4000504@samsco.org> Date: Tue, 09 Dec 2008 10:14:01 -0700 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.13) Gecko/20080313 SeaMonkey/1.1.9 MIME-Version: 1.0 To: Mike Tancsa References: <200812081621.mB8GLMxB041498@lava.sentex.ca> <200812081906.mB8J6oha042222@lava.sentex.ca> <200812082049.mB8KnHSN042710@lava.sentex.ca> <84A7F176-5A74-48AC-859A-C0D4C7CBCB48@mac.com> <7.1.0.9.0.20081208173515.13f62e88@sentex.net> <200812091457.mB9EvLSD047534@lava.sentex.ca> In-Reply-To: <200812091457.mB9EvLSD047534@lava.sentex.ca> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.4 required=3.8 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on pooker.samsco.org Cc: Marcel Moolenaar , freebsd-current@freebsd.org Subject: Re: uart vs sio differences ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Dec 2008 17:50:09 -0000 Mike Tancsa wrote: > At 05:39 PM 12/8/2008, Mike Tancsa wrote: > >> What it appears to be is that as long as data is coming in, even at >> 1200bps, the ioctl FIONREAD returns zero and an actual read does not >> return any data until there is either a pause in the data coming in or >> possibly when we do a xmit/write at which point the accumulated data >> is available for us to read. >> >> We dont know if this is due to the hardware fifo or something in the >> driver itself. > > OK, I think we found the issue! > > http://www.freebsd.org/cgi/query-pr.cgi?pr=121421 > > Not sure if the semantics are exactly right, but adding > > hint.uart.0.flags="0x100" > hint.uart.1.flags="0x100" > hint.uart.2.flags="0x100" > hint.uart.3.flags="0x100" > > to device.hints fixed the issue! > > The next question-- is there a way to do this with the ucom driver as > well ? We are seeing the same issue with it. > > ---Mike It's pretty sad that the uart driver can't keep up with the 16550 at full FIFO depth, though I can see exactly why. Even though the driver will normally use a fast interrupt handler, that handler does nothing but schedule the sio swi thread. Well, I shouldn't say that that's the only thing it does; it also does a spinwait on a home-rolled semaphore with the swi thread, something that I'm not sure I understand. Maybe the author thought that there was a risk of missed wakeups of the swi? That aside, I think what needs to happen is for the driver to use the interrupt handler to pull the bytes out of the hardware and into an internal lockless ring buffer, then schedule the swi to process the ring buffer. I'll see if I can come up with some code for this today. Not sure if the same can be done for ucom since the USB stack below it presents a lot more complications and overhead. Scott From owner-freebsd-current@FreeBSD.ORG Tue Dec 9 18:13:32 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 11B1F106564A for ; Tue, 9 Dec 2008 18:13:32 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout022.mac.com (asmtpout022.mac.com [17.148.16.97]) by mx1.freebsd.org (Postfix) with ESMTP id EED958FC16 for ; Tue, 9 Dec 2008 18:13:31 +0000 (UTC) (envelope-from xcllnt@mac.com) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Received: from [192.168.1.94] (209-128-86-226.bayarea.net [209.128.86.226]) by asmtp022.mac.com (Sun Java(tm) System Messaging Server 6.3-7.03 (built Aug 7 2008; 32bit)) with ESMTPSA id <0KBM009ADFYIP690@asmtp022.mac.com> for freebsd-current@freebsd.org; Tue, 09 Dec 2008 10:13:31 -0800 (PST) Message-id: <0E8F5AD4-A139-413E-A760-A1BEDDF44BAA@mac.com> From: Marcel Moolenaar To: Scott Long In-reply-to: <493EA759.4000504@samsco.org> Date: Tue, 09 Dec 2008 10:13:30 -0800 References: <200812081621.mB8GLMxB041498@lava.sentex.ca> <200812081906.mB8J6oha042222@lava.sentex.ca> <200812082049.mB8KnHSN042710@lava.sentex.ca> <84A7F176-5A74-48AC-859A-C0D4C7CBCB48@mac.com> <7.1.0.9.0.20081208173515.13f62e88@sentex.net> <200812091457.mB9EvLSD047534@lava.sentex.ca> <493EA759.4000504@samsco.org> X-Mailer: Apple Mail (2.929.2) Cc: freebsd-current@freebsd.org, Mike Tancsa Subject: Re: uart vs sio differences ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Dec 2008 18:13:32 -0000 On Dec 9, 2008, at 9:14 AM, Scott Long wrote: > That aside, I think what needs to happen is for the driver to use the > interrupt handler to pull the bytes out of the hardware and into an > internal lockless ring buffer, then schedule the swi to process the > ring > buffer. The uart(4) driver is exactly doing what you describe. -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-current@FreeBSD.ORG Tue Dec 9 19:14:31 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BA2A21065670 for ; Tue, 9 Dec 2008 19:14:31 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (adsl-63-193-123-122.dsl.snfc21.pacbell.net [63.193.123.122]) by mx1.freebsd.org (Postfix) with ESMTP id E13698FC1B for ; Tue, 9 Dec 2008 19:14:30 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.3/8.14.3) with ESMTP id mB9JEUYH090349 for ; Tue, 9 Dec 2008 11:14:30 -0800 (PST) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.3/8.14.3/Submit) id mB9JEUT1090348 for current@freebsd.org; Tue, 9 Dec 2008 11:14:30 -0800 (PST) (envelope-from david) Resent-Message-Id: <200812091914.mB9JEUT1090348@albert.catwhisker.org> Received: from janus.catwhisker.org (janus.catwhisker.org [172.16.8.1]) by albert.catwhisker.org (8.14.3/8.14.3) with ESMTP id mB9J1VJl090312 for ; Tue, 9 Dec 2008 11:01:31 -0800 (PST) (envelope-from owner-freebsd-hackers@freebsd.org) Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53]) by janus.catwhisker.org (8.14.3/8.14.3) with ESMTP id mB9J1To7082522 for ; Tue, 9 Dec 2008 11:01:29 -0800 (PST) (envelope-from owner-freebsd-hackers@freebsd.org) Received: from hub.freebsd.org (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 9C626177098; Tue, 9 Dec 2008 19:01:18 +0000 (UTC) (envelope-from owner-freebsd-hackers@freebsd.org) Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id EFA1910656EE; Tue, 9 Dec 2008 19:01:17 +0000 (UTC) (envelope-from owner-freebsd-hackers@freebsd.org) Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E38A3106568C for ; Tue, 9 Dec 2008 19:01:10 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (adsl-63-193-123-122.dsl.snfc21.pacbell.net [63.193.123.122]) by mx1.freebsd.org (Postfix) with ESMTP id 715138FC2C for ; Tue, 9 Dec 2008 19:01:10 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.3/8.14.3) with ESMTP id mB9J1AWg090301 for ; Tue, 9 Dec 2008 11:01:10 -0800 (PST) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.3/8.14.3/Submit) id mB9J1A05090300 for hackers@freebsd.org; Tue, 9 Dec 2008 11:01:10 -0800 (PST) (envelope-from david) Date: Tue, 9 Dec 2008 11:01:10 -0800 From: David Wolfskill To: hackers@freebsd.org Message-ID: <20081209190110.GW60731@albert.catwhisker.org> References: <20081203001538.GC96383@bunrab.catwhisker.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="dQ+ozEaLk2y6HH72" Content-Disposition: inline In-Reply-To: <20081203001538.GC96383@bunrab.catwhisker.org> User-Agent: Mutt/1.4.2.3i X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Sender: owner-freebsd-hackers@freebsd.org Errors-To: owner-freebsd-hackers@freebsd.org Resent-From: david@catwhisker.org Resent-Date: Tue, 9 Dec 2008 11:14:30 -0800 Resent-To: current@freebsd.org Cc: Subject: Re: NFS (& amd?) dysfunction descending a hierarchy X-BeenThere: freebsd-current@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Dec 2008 19:14:31 -0000 --dQ+ozEaLk2y6HH72 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Dec 02, 2008 at 04:15:38PM -0800, David Wolfskill wrote: > I seem to have a fairly- (though not deterministly so) reproducible > mode of failure with an NFS-mounted directory hierarchy: An attempt to > traverse a "sufficiently large" hierarchy (e.g., via "tar zcpf" or "rm > -fr") will fail to "visit" some subdirectories, typically apparently > acting as if the subdirectories in question do not actually exist > (despite the names having been returned in the output of a previous > readdir()). > ...=20 I was able to reproduce the external symptoms of the failure running CURRENT as of yesterday, using "rm -fr" of a copy of a recent /usr/ports hierachy on an NFS-mounted file system as a test case. However, I believe the mechanism may be a bit different -- while still being other than what I would expect. One aspect in which the externally-observable symptoms were different (under CURRENT, vs. RELENG_7) is that under CURRENT, once the error condition occurred, the NFS client machine was in a state where it merely kept repeating nfs server pid848@fbsd-build:/volume: not responding until I logged in as root & rebooted it. Here's a cut/paste of the kdump from the ktrace of the amd(8) process under CURRENT, showing where the master amd(8) process (pid 848) forks a child (4126) to try the unmount: 848 amd 1228846258.722953 CALL gettimeofday(0x8078e48,0) 848 amd 1228846258.722964 RET gettimeofday 0 848 amd 1228846258.722982 CALL sigprocmask(SIG_BLOCK,0xbfbfeaec,0x= bfbfeadc) 848 amd 1228846258.722993 RET sigprocmask 0 848 amd 1228846258.723003 CALL fork 848 amd 1228846258.730250 RET fork 4126/0x101e 848 amd 1228846258.730405 CALL sigprocmask(SIG_SETMASK,0xbfbfeadc,= 0) 4126 amd 1228846258.730252 RET fork 0 4126 amd 1228846258.730456 CALL getpid 4126 amd 1228846258.730467 RET getpid 4126/0x101e 4126 amd 1228846258.730493 CALL unmount(0x2825f340,0) 848 amd 1228846258.730422 RET sigprocmask 0 848 amd 1228846258.730595 CALL gettimeofday(0x8078e48,0) 848 amd 1228846258.730608 RET gettimeofday 0 =2E.. 848 amd 1228846258.914814 CALL sigprocmask(SIG_SETMASK,0xbfbfeba0,= 0) 848 amd 1228846258.914826 RET sigprocmask 0 848 amd 1228846258.914838 CALL select(0x400,0xbfbfec40,0,0,0xbfbfe= cd8) 4126 amd 1228846259.090428 RET unmount 0 4126 amd 1228846259.090492 CALL sigprocmask(SIG_BLOCK,0x2809b080,0x= bfbfea0c) 4126 amd 1228846259.090505 RET sigprocmask 0 4126 amd 1228846259.090518 CALL sigprocmask(SIG_SETMASK,0x2809b090,= 0) 4126 amd 1228846259.090530 RET sigprocmask 0 4126 amd 1228846259.090545 CALL sigprocmask(SIG_BLOCK,0x2809b080,0x= bfbfe9dc) 4126 amd 1228846259.090556 RET sigprocmask 0 4126 amd 1228846259.090576 CALL sigprocmask(SIG_SETMASK,0x2809b090,= 0) 4126 amd 1228846259.090587 RET sigprocmask 0 4126 amd 1228846259.090605 CALL exit(0) 848 amd 1228846259.091248 RET select -1 errno 4 Interrupted syste= m call 848 amd 1228846259.091277 PSIG SIGCHLD caught handler=3D0x805e090 = mask=3D0x0 code=3D0x0 848 amd 1228846259.091298 CALL wait4(0xffffffff,0xbfbfe83c,WNOHANG= ,0) 848 amd 1228846259.091329 RET wait4 4126/0x101e 848 amd 1228846259.091342 CALL wait4(0xffffffff,0xbfbfe83c,WNOHANG= ,0) 848 amd 1228846259.091352 RET wait4 -1 errno 10 No child processes 848 amd 1228846259.091365 CALL sigprocmask(SIG_SETMASK,0x80795bc,0) 848 amd 1228846259.091377 RET sigprocmask 0 848 amd 1228846259.091390 CALL sigprocmask(SIG_BLOCK,0x80792c4,0) 848 amd 1228846259.091401 RET sigprocmask 0 848 amd 1228846259.091411 CALL gettimeofday(0x8078e48,0) 848 amd 1228846259.091422 RET gettimeofday 0 Note that while the child didn't get EBUSY (as it does under RELENG_7) -- indeed, the unmount call appears to have returned 0 -- the master amd(8) process looks to be seeing "errno 4 Interrupted system call." And here's a relevent part of the kdump from the "rm -fr" -- I had kdump spit out Epoch timestamps with each in order to make correlation easier: 4121 rm 1228846258.736266 CALL unlink(0x2821c148) 4121 rm 1228846258.736281 NAMI "distinfo" 4121 rm 1228846258.738329 RET unlink 0 4121 rm 1228846258.738379 CALL unlink(0x2821c1b8) 4121 rm 1228846258.738401 NAMI "pkg-descr" 4121 rm 1228846258.739963 RET unlink 0 4121 rm 1228846258.739982 CALL open(0x28178b6b,O_RDONLY,0) 4121 rm 1228846258.740002 NAMI ".." 4121 rm 1228846258.740541 RET open 4 4121 rm 1228846258.740558 CALL fstat(0x4,0xbfbfe96c) 4121 rm 1228846258.740579 STRU struct stat {dev=3D67174155, ino=3D= 22674937, mode=3Ddrwxr-xr-x , nlink=3D114, uid=3D9874, gid=3D929, rdev=3D0,= atime=3D1228846258.184514000, stime =3D1228846258.779501000, ctime=3D1228846258.779501000, birthtime=3D-1, size= =3D12288, blksize=3D4096, blocks=3D24, flags=3D0x0 } 4121 rm 1228846258.740593 RET fstat 0 4121 rm 1228846258.740608 CALL fchdir(0x4) 4121 rm 1228846258.740626 RET fchdir 0 4121 rm 1228846258.740641 CALL close(0x4) 4121 rm 1228846258.740976 RET close 0 4121 rm 1228846258.740991 CALL rmdir(0x2821c538) 4121 rm 1228846258.741007 NAMI "dnscheck" 4121 rm 1228846258.741764 RET rmdir 0 4121 rm 1228846258.741783 CALL stat(0x2821d028,0xbfbfe900) 4121 rm 1228846258.741799 NAMI "dnsdoctor" 4121 rm 1228846258.742050 STRU struct stat {dev=3D67174155, ino=3D= 2519891, mode=3Ddrwxr-xr-x , nlink=3D3, uid=3D9874, gid=3D929, rdev=3D0, at= ime=3D1228844788, stime=3D1227555712,=20 ctime=3D1228845836.981842000, birthtime=3D-1, size=3D4096, blksize=3D4096, = blocks=3D8, flags=3D0x0 } 4121 rm 1228846258.742066 RET stat 0 4121 rm 1228846258.742080 CALL open(0x2821d028,O_NONBLOCK,= 0x28200000) 4121 rm 1228846258.742097 NAMI "dnsdoctor" 4121 rm 1228846258.742419 RET open 4 4121 rm 1228846258.742435 CALL fstat(0x4,0xbfbfe6a0) 4121 rm 1228846258.742452 STRU struct stat {dev=3D67174155, ino=3D= 2519891, mode=3Ddrwxr-xr-x , nlink=3D3, uid=3D9874, gid=3D929, rdev=3D0, at= ime=3D1228844788, stime=3D1227555712,=20 ctime=3D1228845836.981842000, birthtime=3D-1, size=3D4096, blksize=3D4096, = blocks=3D8, flags=3D0x0 } 4121 rm 1228846258.742465 RET fstat 0 4121 rm 1228846258.742480 CALL fcntl(0x4,F_SETFD,FD_CLOEXEC) 4121 rm 1228846258.742495 RET fcntl 0 4121 rm 1228846258.742516 CALL fstatfs(0x4,0xbfbfe700) 4121 rm 1228846258.742792 RET fstatfs -1 errno 2 No such file or = directory 4121 rm 1228846258.742809 CALL close(0x4) 4121 rm 1228846258.743187 RET close 0 4121 rm 1228846258.743203 CALL stat(0x2821d098,0xbfbfe900) 4121 rm 1228846258.743219 NAMI "dnsflood" 4121 rm 1228846258.743544 STRU struct stat {dev=3D67174155, ino=3D= 2519892, mode=3Ddrwxr-xr-x , nlink=3D3, uid=3D9874, gid=3D929, rdev=3D0, at= ime=3D1228844788, stime=3D1227555712, ctime=3D1228845836.978868000, birthti= me=3D-1, size=3D4096, blksize=3D4096, blocks=3D8, flags=3D0x0 } 4121 rm 1228846258.743559 RET stat 0 4121 rm 1228846258.743574 CALL open(0x2821d098,O_NONBLOCK,= 0x28200000) 4121 rm 1228846258.743590 NAMI "dnsflood" 4121 rm 1228846258.743792 RET open 4 4121 rm 1228846258.743809 CALL fstat(0x4,0xbfbfe6a0) 4121 rm 1228846258.743826 STRU struct stat {dev=3D67174155, ino=3D= 2519892, mode=3Ddrwxr-xr-x , nlink=3D3, uid=3D9874, gid=3D929, rdev=3D0, at= ime=3D1228844788, stime=3D1227555712, ctime=3D1228845836.978868000, birthti= me=3D-1, size=3D4096, blksize=3D4096, blocks=3D8, flags=3D0x0 } 4121 rm 1228846258.743840 RET fstat 0 4121 rm 1228846258.743854 CALL fcntl(0x4,F_SETFD,FD_CLOEXEC) 4121 rm 1228846258.743867 RET fcntl 0 4121 rm 1228846258.743882 CALL fstatfs(0x4,0xbfbfe700) 4121 rm 1228846258.744008 RET fstatfs -1 errno 2 No such file or = directory 4121 rm 1228846258.744022 CALL close(0x4) 4121 rm 1228846258.744411 RET close 0 [I included a moderate amount of successful processing near the beginning of that excerpt, so folks could see the pattern.] In contrast, here are the similar kdump excerpts from RELENG_7: 702 amd 1228774660.297858 CALL gettimeofday(0x807ad48,0) 702 amd 1228774660.297864 RET gettimeofday 0 702 amd 1228774660.297872 CALL sigprocmask(SIG_BLOCK,0xbfbfeaec,0x= bfbfeadc) 702 amd 1228774660.297878 RET sigprocmask 0 702 amd 1228774660.297883 CALL fork 702 amd 1228774660.302658 RET fork 16840/0x41c8 16840 amd 1228774660.302660 RET fork 0 702 amd 1228774660.302689 CALL sigprocmask(SIG_SETMASK,0xbfbfeadc,= 0) 16840 amd 1228774660.302707 CALL getpid 16840 amd 1228774660.302725 RET getpid 16840/0x41c8 702 amd 1228774660.302715 RET sigprocmask 0 702 amd 1228774660.302746 CALL gettimeofday(0x807ad48,0) 16840 amd 1228774660.302753 CALL unmount(0x2837d310,0) 702 amd 1228774660.302753 RET gettimeofday 0 =2E.. 702 amd 1228774660.417933 CALL select(0x400,0xbfbfec40,0,0,0xbfbfe= cd8) 16840 amd 1228774660.434632 RET unmount -1 errno 16 Device busy 16840 amd 1228774660.434684 CALL sigprocmask(SIG_BLOCK,0x28097c00,0x= bfbfea0c) 16840 amd 1228774660.434691 RET sigprocmask 0 16840 amd 1228774660.434699 CALL sigprocmask(SIG_SETMASK,0x28097c10,= 0) 16840 amd 1228774660.434705 RET sigprocmask 0 16840 amd 1228774660.434713 CALL sigprocmask(SIG_BLOCK,0x28097c00,0x= bfbfe9dc) 16840 amd 1228774660.434718 RET sigprocmask 0 16840 amd 1228774660.434729 CALL sigprocmask(SIG_SETMASK,0x28097c10,= 0) 16840 amd 1228774660.434734 RET sigprocmask 0 16840 amd 1228774660.434745 CALL exit(0x10) 702 amd 1228774660.435214 RET select -1 errno 4 Interrupted syste= m call 702 amd 1228774660.435227 PSIG SIGCHLD caught handler=3D0x805de20 = mask=3D0x0 code=3D0x0 702 amd 1228774660.435237 CALL wait4(0xffffffff,0xbfbfe83c,WNOHANG= ,0) 702 amd 1228774660.435255 RET wait4 16840/0x41c8 702 amd 1228774660.435296 CALL wait4(0xffffffff,0xbfbfe83c,WNOHANG= ,0) 702 amd 1228774660.435302 RET wait4 -1 errno 10 No child processes 702 amd 1228774660.435307 CALL sigprocmask(SIG_SETMASK,0x807ba7c,0) 702 amd 1228774660.435312 RET sigprocmask 0 702 amd 1228774660.435317 CALL sigprocmask(SIG_BLOCK,0x807b784,0) 702 amd 1228774660.435323 RET sigprocmask 0 and: 16835 rm 1228774660.305162 CALL open(0x2816280b,O_RDONLY,0) 16835 rm 1228774660.305173 NAMI ".." 16835 rm 1228774660.305626 RET open 4 16835 rm 1228774660.305634 CALL fstat(0x4,0xbfbfe93c) 16835 rm 1228774660.305644 STRU struct stat {dev=3D50396945, ino=3D= 29713037, mode=3Ddrwxr-xr-x , nlink=3D91, uid=3D9874, gid=3D929, rdev=3D0, = atime=3D1228774657.877477000, stime=3D 1228774660.314260000, ctime=3D1228774660.314260000, birthtime=3D0, size=3D2= 0480, blksize=3D4096, blocks=3D40, flags=3D0x0 } 16835 rm 1228774660.305651 RET fstat 0 16835 rm 1228774660.305658 CALL fchdir(0x4) 16835 rm 1228774660.305667 RET fchdir 0 16835 rm 1228774660.305674 CALL close(0x4) 16835 rm 1228774660.305824 RET close 0 16835 rm 1228774660.305831 CALL rmdir(0x2821afe8) 16835 rm 1228774660.305838 NAMI "p-interp" 16835 rm 1228774660.306498 RET rmdir 0 16835 rm 1228774660.306513 CALL stat(0x28218b48,0xbfbfe8cc) 16835 rm 1228774660.306519 NAMI "pcemu" 16835 rm 1228774660.306756 STRU struct stat {dev=3D50396945, ino=3D= 8465981, mode=3Ddrwxr-xr-x , nlink=3D5, uid=3D9874, gid=3D929, rdev=3D0, at= ime=3D1228772282, stime=3D1227555736,=20 ctime=3D1228773351.399184000, birthtime=3D0, size=3D4096, blksize=3D4096, b= locks=3D8, flags=3D0x0 } 16835 rm 1228774660.306764 RET stat 0 16835 rm 1228774660.306770 CALL open(0x28218b48,O_NONBLOCK,= 0x1) 16835 rm 1228774660.306776 NAMI "pcemu" 16835 rm 1228774660.307003 RET open 4 16835 rm 1228774660.307010 CALL fstat(0x4,0xbfbfe8cc) 16835 rm 1228774660.307018 STRU struct stat {dev=3D50396945, ino=3D= 8465981, mode=3Ddrwxr-xr-x , nlink=3D5, uid=3D9874, gid=3D929, rdev=3D0, at= ime=3D1228772282, stime=3D1227555736,=20 ctime=3D1228773351.399184000, birthtime=3D0, size=3D4096, blksize=3D4096, b= locks=3D8, flags=3D0x0 } 16835 rm 1228774660.307025 RET fstat 0 16835 rm 1228774660.307031 CALL fcntl(0x4,F_SETFD,FD_CLOEXEC) 16835 rm 1228774660.307039 RET fcntl 0 16835 rm 1228774660.307049 CALL fstatfs(0x4,0xbfbfe6f4) 16835 rm 1228774660.307294 RET fstatfs -1 errno 2 No such file or = directory 16835 rm 1228774660.307302 CALL close(0x4) 16835 rm 1228774660.307549 RET close 0 16835 rm 1228774660.307557 CALL stat(0x28218b98,0xbfbfe8cc) 16835 rm 1228774660.307563 NAMI "pearpc" 16835 rm 1228774660.307759 STRU struct stat {dev=3D50396945, ino=3D= 27094159, mode=3Ddrwxr-xr-x , nlink=3D4, uid=3D9874, gid=3D929, rdev=3D0, a= time=3D1228772282, stime=3D1227555736, ctime=3D1228773351.390236000, birtht= ime=3D0, size=3D4096, blksize=3D4096, blocks=3D8, flags=3D0x0 } 16835 rm 1228774660.307767 RET stat 0 16835 rm 1228774660.307772 CALL open(0x28218b98,O_NONBLOCK,= 0x1) 16835 rm 1228774660.307779 NAMI "pearpc" 16835 rm 1228774660.308000 RET open 4 16835 rm 1228774660.308007 CALL fstat(0x4,0xbfbfe8cc) 16835 rm 1228774660.308015 STRU struct stat {dev=3D50396945, ino=3D= 27094159, mode=3Ddrwxr-xr-x , nlink=3D4, uid=3D9874, gid=3D929, rdev=3D0, a= time=3D1228772282, stime=3D1227555736, ctime=3D1228773351.390236000, birtht= ime=3D0, size=3D4096, blksize=3D4096, blocks=3D8, flags=3D0x0 } 16835 rm 1228774660.308021 RET fstat 0 16835 rm 1228774660.308026 CALL fcntl(0x4,F_SETFD,FD_CLOEXEC) 16835 rm 1228774660.308032 RET fcntl 0 16835 rm 1228774660.308038 CALL fstatfs(0x4,0xbfbfe6f4) 16835 rm 1228774660.308101 RET fstatfs -1 errno 2 No such file or = directory 16835 rm 1228774660.308108 CALL close(0x4) 16835 rm 1228774660.308350 RET close 0 So either way, the user-level program attempting the directory hierarchy traversal can be coded to be very careful, yet still receive a rude surprise -- the system saying that a file that the program had already opened (and still has opened) does not exist. How rude! :-{ I'll be very happy to test suggested patches, whether intended to fix the problem or merely facilitate diagnosis. That said, it shouldn't be difficult to reproduce this -- I did it with a copy of /usr/ports; a colleague has reported doing so with a copy of /usr/src (though I haven't witnessed that). Peace, david --=20 David H. Wolfskill david@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --dQ+ozEaLk2y6HH72 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkk+wHUACgkQmprOCmdXAD25wwCeOVCAPA1VsOGdt1mlGyqRb9QZ MoEAnRZW06V29ACC3EW1JO1ojpYPiCvq =pw7g -----END PGP SIGNATURE----- --dQ+ozEaLk2y6HH72-- From owner-freebsd-current@FreeBSD.ORG Tue Dec 9 19:20:35 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EAAEC1065675 for ; Tue, 9 Dec 2008 19:20:35 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 966398FC08 for ; Tue, 9 Dec 2008 19:20:35 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by smarthost1.sentex.ca (8.14.3/8.14.3) with ESMTP id mB9JKXbh087934; Tue, 9 Dec 2008 14:20:33 -0500 (EST) (envelope-from mike@sentex.net) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.13.8/8.13.3) with ESMTP id mB9JKWD1048771 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 9 Dec 2008 14:20:32 -0500 (EST) (envelope-from mike@sentex.net) Message-Id: <200812091920.mB9JKWD1048771@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 09 Dec 2008 14:20:31 -0500 To: Scott Long From: Mike Tancsa In-Reply-To: <493EA759.4000504@samsco.org> References: <200812081621.mB8GLMxB041498@lava.sentex.ca> <200812081906.mB8J6oha042222@lava.sentex.ca> <200812082049.mB8KnHSN042710@lava.sentex.ca> <84A7F176-5A74-48AC-859A-C0D4C7CBCB48@mac.com> <7.1.0.9.0.20081208173515.13f62e88@sentex.net> <200812091457.mB9EvLSD047534@lava.sentex.ca> <493EA759.4000504@samsco.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Marcel Moolenaar , freebsd-current@freebsd.org Subject: Re: uart vs sio differences ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Dec 2008 19:20:36 -0000 At 12:14 PM 12/9/2008, Scott Long wrote: buffer. I'll see if I can come up with some code for this today. Not >sure if the same can be done for ucom since the USB stack below it >presents a lot more complications and overhead. Hi Scott, It seems to work in the USB case if I reduce the receive and xmit buffers. Do you know if there are any nasty unintended side effects of doing this ? I did the follow simple hack to the driver to get our app to work. --- sys/dev/usb/uftdi.c.orig 2008-12-09 11:47:02.000000000 -0500 +++ sys/dev/usb/uftdi.c 2008-12-09 11:47:05.000000000 -0500 @@ -198,6 +198,7 @@ usb_interface_descriptor_t *id; usb_endpoint_descriptor_t *ed; int i; + unsigned int ivar; usbd_status err; struct ucom_softc *ucom = &sc->sc_ucom; DPRINTFN(10,("\nuftdi_attach: sc=%p\n", sc)); @@ -353,11 +354,27 @@ ucom->sc_portno = FTDI_PIT_SIOA; else ucom->sc_portno = FTDI_PIT_SIOA + id->bInterfaceNumber; - /* bulkin, bulkout set above */ - ucom->sc_ibufsize = UFTDIIBUFSIZE; - ucom->sc_obufsize = UFTDIOBUFSIZE - sc->sc_hdrlen; - ucom->sc_ibufsizepad = UFTDIIBUFSIZE; + /* For certain low speed / timing sensitive applications having the buffers too large causes + data to be stuck in the queue too long. By adding a tuneable, users can lower the buffer + size to what works for their application + */ + + if (!resource_int_value( + "uftdi", device_get_unit(ucom->sc_dev), "buffersize", &ivar) && (ivar > sc->sc_hdrlen && ivar <= UFTDIIBUFSIZE) ) { + ucom->sc_ibufsize = ivar; + ucom->sc_obufsize = ivar - sc->sc_hdrlen; + ucom->sc_ibufsizepad = ivar;; + device_printf(ucom->sc_dev, "Setting buffers to %d\n",ivar); + } + else + { + ucom->sc_ibufsize = UFTDIIBUFSIZE; + ucom->sc_obufsize = UFTDIOBUFSIZE - sc->sc_hdrlen; + ucom->sc_ibufsizepad = UFTDIIBUFSIZE; + device_printf(ucom->sc_dev, "Setting buffers to default of %d\n",UFTDIIBUFSIZE); + + } ucom->sc_opkthdrlen = sc->sc_hdrlen; ---Mike From owner-freebsd-current@FreeBSD.ORG Tue Dec 9 19:24:46 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 484911065670 for ; Tue, 9 Dec 2008 19:24:46 +0000 (UTC) (envelope-from elias@artx.ru) Received: from round.artx.ru (round.artx.ru [80.73.175.73]) by mx1.freebsd.org (Postfix) with ESMTP id 550468FC14 for ; Tue, 9 Dec 2008 19:24:41 +0000 (UTC) (envelope-from elias@artx.ru) Received: by round.artx.ru (Postfix, from userid 1001) id 782115C27; Tue, 9 Dec 2008 22:24:39 +0300 (MSK) Date: Tue, 9 Dec 2008 22:24:39 +0300 From: Ilya Orehov To: "M. Warner Losh" Message-ID: <20081209192439.GA16703@artx.ru> References: <20081205174838.GA22652@albert.catwhisker.org> <20081205.120056.255409238.imp@bsdimp.com> <20081209141908.GA15845@artx.ru> <20081209.092739.35219831.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="9amGYk9869ThD9tj" Content-Disposition: inline In-Reply-To: <20081209.092739.35219831.imp@bsdimp.com> User-Agent: Mutt/1.4.2.3i Cc: current@freebsd.org Subject: Re: "interrupt storm..."; seems associated with an0 NIC X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Dec 2008 19:24:46 -0000 --9amGYk9869ThD9tj Content-Type: text/plain; charset=koi8-r Content-Disposition: inline +------- M. Warner Losh, 2008-12-09 ------- | In message: <20081209141908.GA15845@artx.ru> | Ilya Orehov writes: | : +------- M. Warner Losh, 2008-12-05 ------- | : | Thanks. Grump. Will have to back out and try again. | : | : Hello! | : | : I see storm too, but with 32-bit cards. | : | : Thinkpad 600X, two cardbus cards: xl0 and ath0. | : | : Since pccbb.c 1.176 and pccbb_pci.c 1.30 | : after rebooting with card(s) inserted or inserting any card | : I see "interrupt storm...throttling..." messages about 1 per second. | : Laptop remains usable, cards working. | : Storm don't stop even if I eject all cards. | : During storm, vmstat -i shows rate ~500 on cbb. | : No messages appeared if laptop rebooted without cards | : (until any card inserted). | : | : Later revisions ( pccbb.c 1.178 and pccbb_pci.c 1.31) | : didn't bring any visible changes. | : | : But this hack helped. | : No storm detected, vmstat -i shows rate 0 or 1 on cbb. | : | : diff -up xxx/pccbb_pci.c ./pccbb_pci.c | : --- xxx/pccbb_pci.c 2008-12-06 11:56:00.000000000 +0300 | : +++ ./pccbb_pci.c 2008-12-09 14:08:03.000000000 +0300 | : @@ -689,6 +689,7 @@ cbb_pci_filt(void *arg) | : struct cbb_softc *sc = arg; | : uint32_t sockevent; | : int retval = FILTER_STRAY; | : + int ack = 0; | : | : /* | : * Read the socket event. Sometimes, the theory goes, the PCI | : @@ -722,6 +723,7 @@ cbb_pci_filt(void *arg) | : sc->cardok = 0; | : cbb_disable_func_intr(sc); | : wakeup(&sc->intrhand); | : + ack = 1; | : } | : /* | : * If we get a power interrupt, wakeup anybody that might | : @@ -732,7 +734,10 @@ cbb_pci_filt(void *arg) | : cbb_set(sc, CBB_SOCKET_EVENT, CBB_SOCKET_EVENT_POWER); | : sc->powerintr++; | : wakeup((void *)&sc->powerintr); | : + ack = 1; | : } | : + if (!ack) | : + cbb_set(sc, CBB_SOCKET_EVENT, sockevent); | : retval = FILTER_HANDLED; | : } | : /* | : | : Do you need dmesg or some other info? | | Can you please do the following: | | + if (!ack) { | + printf("Need to ack %#x\n", sockevent); | + cbb_set(sc, CBB_SOCKET_EVENT, sockevent); | + } | | And let me know what it says? Recompiled, rebooted with xl0 - message printed only once after xl0 initialization: "Need to ack 0x1" Then I ejected xl0 - no message. When the card was inserted back, same message appeared. ... ad0: 57231MB at ata0-master UDMA33 xl0: <3Com 3c575TX Fast Etherlink XL> port 0x1000-0x103f irq 11 at device 0.0 on cardbus1 miibus0: on xl0 tdkphy0: PHY 0 on miibus0 tdkphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto xl0: Ethernet address: 00:60:08:d2:38:56 xl0: [ITHREAD] Need to ack 0x1 acd0: CDROM at ata1-master PIO4 Trying to mount root from ufs:/dev/ad0s2a WARNING: attempt to net_add_domain(bluetooth) after domainfinalize() xl0: reset didn't complete xl0: command never completed! xl0: command never completed! xl0: command never completed! tdkphy0: detached miibus0: detached xl0: detached Need to ack 0x1 xl0: <3Com 3c575TX Fast Etherlink XL> port 0x1000-0x103f irq 11 at device 0.0 on cardbus1 miibus0: on xl0 tdkphy0: PHY 0 on miibus0 tdkphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto xl0: Ethernet address: 00:60:08:d2:38:56 xl0: [ITHREAD] xl0: link state changed to DOWN xl0: link state changed to UP regards, Ilya. | | Warner | +----------------------------- --9amGYk9869ThD9tj Content-Type: text/plain; charset=koi8-r Content-Disposition: attachment; filename="dmesg.ack" Copyright (c) 1992-2008 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-CURRENT #13: Tue Dec 9 21:34:37 MSK 2008 elias@.......ru:/usr/src/sys/i386/compile/TB Preloaded elf kernel "/boot/kernel/kernel" at 0xc09ee000. Preloaded elf module "/boot/kernel/snd_csa.ko" at 0xc09ee174. Preloaded elf module "/boot/kernel/sound.ko" at 0xc09ee220. Preloaded elf module "/boot/kernel/ng_ubt.ko" at 0xc09ee2cc. Preloaded elf module "/boot/kernel/netgraph.ko" at 0xc09ee378. Preloaded elf module "/boot/kernel/acpi.ko" at 0xc09ee428. Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 498274309 Hz CPU: Intel Pentium III (498.27-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x681 Stepping = 1 Features=0x383f9ff Instruction TLB: 4 KB pages, 4-way set associative, 32 entries Instruction TLB: 4 MB pages, fully associative, 2 entries Data TLB: 4 KB pages, 4-way set associative, 64 entries 2nd-level cache: 256 KB, 8-way set associative, 32 byte line size 1st-level instruction cache: 16 KB, 4-way set associative, 32 byte line size Data TLB: 4 MB Pages, 4-way set associative, 8 entries 1st-level data cache: 16 KB, 4-way set associative, 32 byte line size real memory = 268238848 (255 MB) Physical memory chunk(s): 0x0000000000001000 - 0x000000000009efff, 647168 bytes (158 pages) 0x0000000000100000 - 0x00000000003fffff, 3145728 bytes (768 pages) 0x0000000000c25000 - 0x000000000fb4dfff, 250777600 bytes (61225 pages) avail memory = 253173760 (241 MB) bios32: Found BIOS32 Service Directory header at 0xc00fd800 bios32: Entry = 0xfd820 (c00fd820) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xfd880+0x0 pnpbios: Found PnP BIOS data at 0xc00fe700 pnpbios: Entry = f0000:e724 Rev = 1.0 pnpbios: Event flag at 415 Other BIOS signatures found: snd_unit_init() u=0x00ff8000 [512] d=0x00007c00 [32] c=0x000003ff [1024] feeder_register: snd_unit=-1 snd_maxautovchans=16 latency=5 feeder_buffersize=16384 feeder_rate_min=1 feeder_rate_max=2016000 feeder_rate_round=25 ath_rate: version 1.9 wlan: <802.11 Link Layer> kbd: new array size 4 kbd1 at kbdmux0 mem: Pentium Pro MTRR support enabled io: null: random: ACPI: RSDP @ 0x0xfd6e0/0x0014 (v 0 IBM ) ACPI: RSDT @ 0x0xffd0000/0x0028 (v 1 IBM TP600X 0x00000001 0x00000000) ACPI: FACP @ 0x0xffd0100/0x0074 (v 1 IBM TP600X 0x00000001 0x00000000) ACPI: DSDT @ 0x0xffd0200/0xAF9E (v 1 IBM TP600X 0x00000102 MSFT 0x0100000C) ACPI: FACS @ 0x0xffdf000/0x0040 npx0: INT 16 interface acpi0: on motherboard pci_open(1): mode 1 addr port (0x0cf8) is 0x80003b40 pci_open(1a): mode1res=0x80000000 (0x80000000) pci_cfgcheck: device 0 [class=060000] [hdr=00] is there (id=71908086) pcibios: BIOS version 2.10 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: \\_SB_.PCI0.ISA0.PIRQ -> bus 0 dev 1 func 0 acpi0: [MPSAFE] acpi0: [ITHREAD] acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: \\_SB_.PCI0.CBS0.CBUS -> bus 0 dev 2 func 0 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: \\_SB_.PCI0.CBS1.CBUS -> bus 0 dev 2 func 1 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: \\_SB_.PCI0.PM00.X3DB -> bus 0 dev 7 func 3 acpi0: Power Button (fixed) acpi0: wakeup code va 0xc1c5f000 pa 0x1000 atpic: Programming IRQ9 as level/low acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: \\_SB_.PCI0.IDE0.X140 -> bus 0 dev 7 func 1 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: \\_SB_.PCI0.DOCK.IDE1.X140 -> bus 0 dev 0 func 1 acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, ff00000 (3) failed ACPI timer: 0/5 0/5 0/5 0/5 0/5 0/5 0/5 0/5 0/5 0/4 -> 0 Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 acpi_timer0: <24-bit timer at 3.579545MHz> port 0xef08-0xef0b on acpi0 acpi_ec0: port 0x62,0x66 on acpi0 pci_link0: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 6 7 9 10 11 12 14 15 Validation 0 255 N 0 3 4 5 6 7 9 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 9 10 11 12 14 15 pci_link1: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 6 7 9 10 11 12 14 15 Validation 0 255 N 0 3 4 5 6 7 9 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 9 10 11 12 14 15 pci_link2: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 6 7 9 10 11 12 14 15 Validation 0 255 N 0 3 4 5 6 7 9 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 9 10 11 12 14 15 pci_link3: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 6 7 9 10 11 12 14 15 Validation 0 255 N 0 3 4 5 6 7 9 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 9 10 11 12 14 15 acpi_lid0: on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 ACPI: Found matching pin for 0.7.INTD at func 2: 11 ACPI: Found matching pin for 0.2.INTA at func 0: 11 ACPI: Found matching pin for 0.2.INTB at func 1: 11 ACPI: Found matching pin for 0.3.INTA at func 0: 11 ACPI: Found matching pin for 0.6.INTA at func 0: 11 pci0: on pcib0 pci0: domain=0, physical bus=0 found-> vendor=0x8086, dev=0x7190, revid=0x03 domain=0, bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0xa210, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) map[10]: type Prefetchable Memory, range 32, base 0x40000000, size 26, enabled found-> vendor=0x8086, dev=0x7191, revid=0x03 domain=0, bus=0, slot=1, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0007, statreg=0x0220, cachelnsz=0 (dwords) lattimer=0xa8 (5040 ns), mingnt=0x88 (34000 ns), maxlat=0x00 (0 ns) found-> vendor=0x104c, dev=0xac1b, revid=0x03 domain=0, bus=0, slot=2, func=0 class=06-07-00, hdrtype=0x02, mfdev=1 cmdreg=0x0007, statreg=0x0210, cachelnsz=8 (dwords) lattimer=0xa8 (5040 ns), mingnt=0xc0 (48000 ns), maxlat=0x03 (750 ns) intpin=a, irq=11 powerspec 1 supports D0 D1 D2 D3 current D0 map[10]: type Memory, range 32, base 0x50103000, size 12, enabled pcib0: matched entry for 0.2.INTA (src \\_SB_.LNKA:0) pcib0: slot 2 INTA routed to irq 11 via \\_SB_.LNKA found-> vendor=0x104c, dev=0xac1b, revid=0x03 domain=0, bus=0, slot=2, func=1 class=06-07-00, hdrtype=0x02, mfdev=1 cmdreg=0x0007, statreg=0x0210, cachelnsz=8 (dwords) lattimer=0xa8 (5040 ns), mingnt=0xc0 (48000 ns), maxlat=0x03 (750 ns) intpin=b, irq=11 powerspec 1 supports D0 D1 D2 D3 current D0 map[10]: type Memory, range 32, base 0x50102000, size 12, enabled pcib0: matched entry for 0.2.INTB (src \\_SB_.LNKB:0) pcib0: slot 2 INTB routed to irq 11 via \\_SB_.LNKB found-> vendor=0x11c1, dev=0x0449, revid=0x01 domain=0, bus=0, slot=3, func=0 class=07-80-00, hdrtype=0x00, mfdev=0 cmdreg=0x0107, statreg=0x8290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0xfc (63000 ns), maxlat=0x0e (3500 ns) intpin=a, irq=11 powerspec 2 supports D0 D2 D3 current D0 map[10]: type Memory, range 32, base 0x50101000, size 8, enabled map[14]: type I/O Port, range 32, base 0x4500, size 3, enabled map[18]: type I/O Port, range 32, base 0x4400, size 8, enabled pcib0: matched entry for 0.3.INTA (src \\_SB_.LNKC:0) pcib0: slot 3 INTA routed to irq 11 via \\_SB_.LNKC found-> vendor=0x1013, dev=0x6003, revid=0x01 domain=0, bus=0, slot=6, func=0 class=04-01-00, hdrtype=0x00, mfdev=0 cmdreg=0x0106, statreg=0x0410, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x04 (1000 ns), maxlat=0x18 (6000 ns) intpin=a, irq=11 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type Memory, range 32, base 0x50100000, size 12, enabled map[14]: type Memory, range 32, base 0x50000000, size 20, enabled pcib0: matched entry for 0.6.INTA (src \\_SB_.LNKA:0) pcib0: slot 6 INTA routed to irq 11 via \\_SB_.LNKA found-> vendor=0x8086, dev=0x7110, revid=0x02 domain=0, bus=0, slot=7, func=0 class=06-80-00, hdrtype=0x00, mfdev=1 cmdreg=0x000f, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x7111, revid=0x01 domain=0, bus=0, slot=7, func=1 class=01-01-80, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x30 (1440 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) map[20]: type I/O Port, range 32, base 0xfcf0, size 4, enabled found-> vendor=0x8086, dev=0x7112, revid=0x01 domain=0, bus=0, slot=7, func=2 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x30 (1440 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=d, irq=11 map[20]: type I/O Port, range 32, base 0x4000, size 5, enabled pcib0: matched entry for 0.7.INTD (src \\_SB_.LNKD:0) pcib0: slot 7 INTD routed to irq 11 via \\_SB_.LNKD found-> vendor=0x8086, dev=0x7113, revid=0x03 domain=0, bus=0, slot=7, func=3 class=06-80-00, hdrtype=0x00, mfdev=0 cmdreg=0x0003, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) map[90]: type I/O Port, range 32, base 0xefa0, size 4, enabled agp0: on hostb0 hostb0: Reserved 0x4000000 bytes for rid 0x10 type 3 at 0x40000000 agp0: allocating GATT for aperture of size 64M pcib1: at device 1.0 on pci0 pcib1: domain 0 pcib1: secondary bus 1 pcib1: subordinate bus 1 pcib1: I/O decode 0xd000-0xdfff pcib1: memory decode 0x70000000-0xdfffffff pcib1: prefetched decode 0xe0000000-0xf7ffffff ACPI: Found matching pin for 1.0.INTA at func 0: 11 pci1: on pcib1 pci1: domain=0, physical bus=1 found-> vendor=0x10c8, dev=0x0006, revid=0x00 domain=0, bus=1, slot=0, func=0 class=03-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x80 (3840 ns), mingnt=0x10 (4000 ns), maxlat=0xff (63750 ns) intpin=a, irq=11 powerspec 1 supports D0 D1 D2 D3 current D0 map[10]: type Prefetchable Memory, range 32, base 0xe0000000, size 25, enabled pcib1: requested memory range 0xe0000000-0xe1ffffff: good map[14]: type Memory, range 32, base 0x70000000, size 22, enabled pcib1: requested memory range 0x70000000-0x703fffff: good map[18]: type Memory, range 32, base 0x70400000, size 20, enabled pcib1: requested memory range 0x70400000-0x704fffff: good pcib1: matched entry for 1.0.INTA (src \\_SB_.LNKA:0) pcib1: slot 0 INTA routed to irq 11 via \\_SB_.LNKA vgapci0: mem 0xe0000000-0xe1ffffff,0x70000000-0x703fffff,0x70400000-0x704fffff irq 11 at device 0.0 on pci1 cbb0: mem 0x50103000-0x50103fff irq 11 at device 2.0 on pci0 cbb0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0x50103000 cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 cbb0: [MPSAFE] cbb0: [FILTER] cbb0: PCI Configuration space: 0x00: 0xac1b104c 0x02100007 0x06070003 0x0082a808 0x10: 0x50103000 0x020000a0 0xb0040200 0xfffff000 0x20: 0x00000000 0xfffff000 0x00000000 0x0000fffc 0x30: 0x00000000 0x0000fffc 0x00000000 0x0740010b 0x40: 0x01301014 0x00000001 0x00000000 0x00000000 0x50: 0x00000000 0x00000000 0x00000000 0x00000000 0x60: 0x00000000 0x00000000 0x00000000 0x00000000 0x70: 0x00000000 0x00000000 0x00000000 0x00000000 0x80: 0x00449069 0x00000000 0x80818080 0x00001000 0x90: 0x416602c0 0x00000000 0x00000000 0x00000000 0xa0: 0x7e110001 0x00c00000 0x00000000 0x00000000 0xb0: 0x00000000 0x00000000 0x00000000 0x00000000 0xc0: 0x00000000 0x00000000 0x00000000 0x00000000 0xd0: 0x00000000 0x00000000 0x00000000 0x00000000 0xe0: 0x00000000 0x00000000 0x00000000 0x00000000 0xf0: 0x00000000 0x00000000 0x00000000 0x00000000 cbb1: mem 0x50102000-0x50102fff irq 11 at device 2.1 on pci0 cbb1: Reserved 0x1000 bytes for rid 0x10 type 3 at 0x50102000 cardbus1: on cbb1 pccard1: <16-bit PCCard bus> on cbb1 cbb1: [MPSAFE] cbb1: [FILTER] cbb1: PCI Configuration space: 0x00: 0xac1b104c 0x02100007 0x06070003 0x0082a808 0x10: 0x50102000 0x020000a0 0xb0070500 0xfffff000 0x20: 0x00000000 0xfffff000 0x00000000 0x0000fffc 0x30: 0x00000000 0x0000fffc 0x00000000 0x0740020b 0x40: 0x01301014 0x00000001 0x00000000 0x00000000 0x50: 0x00000000 0x00000000 0x00000000 0x00000000 0x60: 0x00000000 0x00000000 0x00000000 0x00000000 0x70: 0x00000000 0x00000000 0x00000000 0x00000000 0x80: 0x0044b069 0x00000000 0x80818080 0x00001000 0x90: 0x416602c0 0x00000000 0x00000000 0x00000000 0xa0: 0x7e110001 0x00c00000 0x00000000 0x00000000 0xb0: 0x00000000 0x00000000 0x00000000 0x00000000 0xc0: 0x00000000 0x00000000 0x00000000 0x00000000 0xd0: 0x00000000 0x00000000 0x00000000 0x00000000 0xe0: 0x00000000 0x00000000 0x00000000 0x00000000 0xf0: 0x00000000 0x00000000 0x00000000 0x00000000 pci0: at device 3.0 (no driver attached) csa0: mem 0x50100000-0x50100fff,0x50000000-0x500fffff irq 11 at device 6.0 on pci0 csa: card is Thinkpad 600X/A20/T20 csa0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0x50100000 csa0: Reserved 0x100000 bytes for rid 0x14 type 3 at 0x50000000 csa0: [GIANT-LOCKED] csa0: [ITHREAD] pcm0: on csa0 pcm0: pcm0: Codec features headphone, 20 bit DAC, 18 bit ADC, 6 bit master volume, Crystal Semi 3D Stereo Enhancement pcm0: Primary codec extended features AMAP pcm0: ac97 codec dac ready count: 0 pcm0: Mixer "vol": pcm0: Mixer "pcm": pcm0: Mixer "speaker": pcm0: Mixer "line": pcm0: Mixer "mic": pcm0: Mixer "cd": pcm0: Mixer "rec": pcm0: Mixer "igain": pcm0: Mixer "ogain": pcm0: Mixer "line1": pcm0: Mixer "phin": pcm0: Mixer "phout": pcm0: Mixer "video": pcm0: [GIANT-LOCKED] pcm0: [ITHREAD] pcm0: clone manager: deadline=750ms flags=0x8000001e pcm0: sndbuf_setmap f813000, 1000; 0xc1fed000 -> f813000 pcm0: sndbuf_setmap f814000, 1000; 0xc1fee000 -> f814000 PCI-ISA bridge with incorrect subclass 0x80 PCI-ISA bridge with incorrect subclass 0x80 isab0: at device 7.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xfcf0-0xfcff at device 7.1 on pci0 atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0xfcf0 ata0: on atapci0 atapci0: Reserved 0x8 bytes for rid 0x10 type 4 at 0x1f0 atapci0: Reserved 0x1 bytes for rid 0x14 type 4 at 0x3f6 ata0: reset tp1 mask=03 ostat0=50 ostat1=00 ata0: stat0=0x50 err=0x01 lsb=0x00 msb=0x00 ata0: stat1=0x00 err=0x01 lsb=0x00 msb=0x00 ata0: reset tp2 stat0=50 stat1=00 devices=0x1 ata0: [MPSAFE] ata0: [ITHREAD] ata1: on atapci0 atapci0: Reserved 0x8 bytes for rid 0x18 type 4 at 0x170 atapci0: Reserved 0x1 bytes for rid 0x1c type 4 at 0x376 ata1: reset tp1 mask=03 ostat0=51 ostat1=00 ata1: stat0=0x00 err=0x01 lsb=0x14 msb=0xeb ata1: stat1=0x00 err=0x04 lsb=0x7f msb=0x7f ata1: reset tp2 stat0=00 stat1=00 devices=0x10000 ata1: [MPSAFE] ata1: [ITHREAD] uhci0: port 0x4000-0x401f irq 11 at device 7.2 on pci0 uhci0: Reserved 0x20 bytes for rid 0x20 type 4 at 0x4000 uhci0: [GIANT-LOCKED] uhci0: [ITHREAD] usb0: on uhci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 2 ports with 2 removable, self powered pci0: at device 7.3 (no driver attached) acpi_tz0: on acpi0 acpi_tz1: on acpi0 acpi_tz2: on acpi0 acpi_tz3: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0045 atkbd: keyboard ID 0x54ab (2) kbd0 at atkbd0 kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: unable to allocate IRQ psmcpnp0: irq 12 on acpi0 psm0: current command byte:0045 psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model Generic PS/2 mouse, device ID 0-00, 2 buttons psm0: config:00000000, flags:00000008, packet size:3 psm0: syncmask:c0, syncbits:00 atrtc0: port 0x70-0x73 irq 8 on acpi0 atrtc0: registered as a time-of-day clock (resolution 1000000us) battery0: on acpi0 acpi_acad0: on acpi0 cpu0: on acpi0 cpu0: switching to generic Cx mode acpi_throttle0: on cpu0 acpi_throttle0: P_CNT from P_BLK 0xef10 ex_isa_identify() pnp_identify: Trying Read_Port at 203 pnp_identify: Trying Read_Port at 243 pnp_identify: Trying Read_Port at 283 pnp_identify: Trying Read_Port at 2c3 pnp_identify: Trying Read_Port at 303 pnp_identify: Trying Read_Port at 343 pnp_identify: Trying Read_Port at 383 pnp_identify: Trying Read_Port at 3c3 PNP Identify complete isa_probe_children: disabling PnP devices pmtimer0 on isa0 ata: ata0 already exists; skipping it ata: ata1 already exists; skipping it atkbdc: atkbdc0 already exists; skipping it atrtc: atrtc0 already exists; skipping it sc: sc0 already exists; skipping it vga: vga0 already exists; skipping it isa_probe_children: probing non-PnP devices orm0: at iomem 0xc0000-0xcbfff pnpid ORM0000 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sc0: fb0, kbd1, terminal emulator: sc (syscons terminal) vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 adv0: not probed (disabled) aha0: not probed (disabled) aic0: not probed (disabled) bt0: not probed (disabled) cs0: not probed (disabled) ed0: not probed (disabled) fdc0 failed to probe at port 0x3f0 irq 6 drq 2 on isa0 fe0: not probed (disabled) ie0: not probed (disabled) le0: not probed (disabled) ppc0: parallel port found at 0x3bc ppc0: cannot reserve I/O port range ppc0: failed to probe at port 0x3bc-0x3c3 irq 7 on isa0 sn0: not probed (disabled) uart0: <16550 or compatible> at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 uart0: [FILTER] uart0: fast interrupt uart1: failed to probe at port 0x2f8-0x2ff irq 3 on isa0 uart2: not probed (disabled) uart3: not probed (disabled) isa_probe_children: probing PnP devices Device configuration finished. procfs registered Timecounter "TSC" frequency 498274309 Hz quality 800 Timecounters tick every 1.000 msec ipfw2 initialized, divert loadable, nat loadable, rule-based forwarding enabled, default to accept, logging limited to 100 packets/entry by default lo0: bpf attached ata0: identify ch->devices=00000001 battery0: battery initialization start acpi_acad0: acline initialization start system power profile changed to 'economy' acpi_acad0: Off Line acpi_acad0: acline initialization done, tried 1 times ata0-master: pio=PIO4 wdma=WDMA2 udma=UDMA100 cable=80 wire ad0: setting Pacpi_tz1: _AC0: temperature 43.8 >= setpoint 33.5 IO4 on PIIX4 chipacpi_tz1: switched from NONE to _AC0: 43.8C ad0: setting UDMA33 on PIIX4 chip ad0: 57231MB at ata0-master UDMA33 ad0: 117210240 sectors [124032C/15H/63S] 16 sectors/interrupt 1 depth queue ata1: identify ch->devices=00010000 GEOM: new disk ad0 map[10]: type I/O Port, range 32, base 0, size 6, port disabled found-> vendor=0x10b7, dev=0x5057, revid=0x00 domain=0, bus=5, slot=0, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0000, statreg=0x0200, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x03 (750 ns), maxlat=0x08 (2000 ns) intpin=a, irq=11 xl0: <3Com 3c575TX Fast Etherlink XL> port 0x1000-0x103f irq 11 at device 0.0 on cardbus1 xl0: Reserved 0x40 bytes for rid 0x10 type 4 at 0x1000 cbb1: Opening I/O: 0x1000-0x103f xl0: using port I/O xl0: media options word: 40 xl0: found MII/AUTO miibus0: on xl0 tdkphy0: PHY 0 on miibus0 tdkphy0: OUI 0x00c039, model 0x0014, rev. 3 tdkphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto xl0: bpf attached xl0: Ethernet address: 00:60:08:d2:38:56 xl0: [MPSAFE] xl0: [ITHREAD] ata1-master: pio=PIO4 wdma=WDMA2 udma=UNSUPPORTED cable=40 wire battery0: battery initialization done, tried 1 times Need to ack 0x1 acd0: setting PIO4 on PIIX4 chip acd0: CDROM drive at ata1 as master acd0: read 4134KB/s (4134KB/s), 128KB buffer, PIO4 acd0: Reads: CDR, CDRW, CDDA stream acd0: Writes: acd0: Audio: play, 16 volume levels acd0: Mechanism: ejectable tray, unlocked acd0: Medium: no/blank disc Trying to mount root from ufs:/dev/ad0s2a ct_to_ts([2008-12-09 21:42:31]) = 1228858951.000000000 start_init: trying /sbin/init WARNING: attempt to net_add_domain(bluetooth) after domainfinalize() splash: image decoder found: snake_saver xl0: reset didn't complete xl0: command never completed! xl0: command never completed! xl0: command never completed! tdkphy0: detached miibus0: detached xl0: detached Need to ack 0x1 map[10]: type I/O Port, range 32, base 0, size 6, port disabled found-> vendor=0x10b7, dev=0x5057, revid=0x00 domain=0, bus=5, slot=0, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0000, statreg=0x0200, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x03 (750 ns), maxlat=0x08 (2000 ns) intpin=a, irq=11 xl0: <3Com 3c575TX Fast Etherlink XL> port 0x1000-0x103f irq 11 at device 0.0 on cardbus1 xl0: Reserved 0x40 bytes for rid 0x10 type 4 at 0x1000 cbb1: Opening I/O: 0x1000-0x103f xl0: using port I/O xl0: media options word: 40 xl0: found MII/AUTO miibus0: on xl0 tdkphy0: PHY 0 on miibus0 tdkphy0: OUI 0x00c039, model 0x0014, rev. 3 tdkphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto xl0: bpf attached xl0: Ethernet address: 00:60:08:d2:38:56 xl0: [MPSAFE] xl0: [ITHREAD] xl0: link state changed to DOWN system power profile changed to 'performance' acpi_acad0: On Line xl0: link state changed to UP --9amGYk9869ThD9tj-- From owner-freebsd-current@FreeBSD.ORG Tue Dec 9 19:42:05 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 517DD1065672 for ; Tue, 9 Dec 2008 19:42:05 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id 189F38FC25 for ; Tue, 9 Dec 2008 19:42:05 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from [IPv6:2001:7b8:3a7:0:6569:b2b8:b062:30d4] (unknown [IPv6:2001:7b8:3a7:0:6569:b2b8:b062:30d4]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 219C684438; Tue, 9 Dec 2008 20:42:04 +0100 (CET) Message-ID: <493ECA0D.7090901@andric.com> Date: Tue, 09 Dec 2008 20:42:05 +0100 From: Dimitry Andric User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.1b3pre) Gecko/20081205 Shredder/3.0b2pre MIME-Version: 1.0 To: Larry Rosenman References: <004901c95a1c$5c6b2680$15417380$@org> In-Reply-To: <004901c95a1c$5c6b2680$15417380$@org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Why does host and dig show a ; as \;? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Dec 2008 19:42:05 -0000 On 2008-12-09 17:36, Larry Rosenman wrote: > Why does the host command, dig, and a named_db.dump all show a ; as \; in a > TXT record? AFAICS the semicolon is a comment character in BIND software (at least in all config files and so on), and therefore it needs to be escaped. From owner-freebsd-current@FreeBSD.ORG Tue Dec 9 19:49:03 2008 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7CD2D1065672 for ; Tue, 9 Dec 2008 19:49:03 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 20C4E8FC08 for ; Tue, 9 Dec 2008 19:49:03 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id mB9JlYs6097982; Tue, 9 Dec 2008 12:47:34 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Tue, 09 Dec 2008 12:47:43 -0700 (MST) Message-Id: <20081209.124743.-201314317.imp@bsdimp.com> To: elias@artx.ru From: "M. Warner Losh" In-Reply-To: <20081209192439.GA16703@artx.ru> References: <20081209141908.GA15845@artx.ru> <20081209.092739.35219831.imp@bsdimp.com> <20081209192439.GA16703@artx.ru> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: current@FreeBSD.org Subject: Re: "interrupt storm..."; seems associated with an0 NIC X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Dec 2008 19:49:03 -0000 In message: <20081209192439.GA16703@artx.ru> Ilya Orehov writes: : Need to ack 0x1 What happens if you also print the current mask register? CBB_SOCKET_MASK? Warner From owner-freebsd-current@FreeBSD.ORG Tue Dec 9 19:49:31 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5786B1065672 for ; Tue, 9 Dec 2008 19:49:31 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [192.147.25.65]) by mx1.freebsd.org (Postfix) with ESMTP id 33B768FC12 for ; Tue, 9 Dec 2008 19:49:31 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from thebighonker.lerctr.org ([192.147.25.65]:57885) by thebighonker.lerctr.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LA8aH-00063l-CO; Tue, 09 Dec 2008 13:49:30 -0600 Date: Tue, 9 Dec 2008 13:49:27 -0600 (CST) From: Larry Rosenman To: Dimitry Andric In-Reply-To: <493ECA0D.7090901@andric.com> Message-ID: References: <004901c95a1c$5c6b2680$15417380$@org> <493ECA0D.7090901@andric.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: -1.0 (-) X-LERCTR-Spam-Score: -1.0 (-) X-Spam-Report: SpamScore (-1.0/5.0) ALL_TRUSTED=-1.8, BAYES_00=-2.599, FM_MULTI_ODD2=1.1, FM_MULTI_ODD3=0.7, FM_MULTI_ODD4=0.7, FM_MULTI_ODD5=0.9 X-LERCTR-Spam-Report: SpamScore (-1.0/5.0) ALL_TRUSTED=-1.8, BAYES_00=-2.599, FM_MULTI_ODD2=1.1, FM_MULTI_ODD3=0.7, FM_MULTI_ODD4=0.7, FM_MULTI_ODD5=0.9 DomainKey-Status: no signature Cc: freebsd-current@freebsd.org Subject: Re: Why does host and dig show a ; as \;? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Dec 2008 19:49:31 -0000 On Tue, 9 Dec 2008, Dimitry Andric wrote: > On 2008-12-09 17:36, Larry Rosenman wrote: >> Why does the host command, dig, and a named_db.dump all show a ; as \; in a >> TXT record? > > AFAICS the semicolon is a comment character in BIND software (at least > in all config files and so on), and therefore it needs to be escaped. > This is in the responses as shown: $ host -t txt blueprint._domainkey.lombardi.com blueprint._domainkey.lombardi.com descriptive text "v=DKIM1\; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDCkAwTHQf0339ugaLhgZWCfGWvgzB92PrD03kpk/RsFv5novZZT0QnL2zVXyBFHe2BjbVrfOl9oF33A3hniVrt89iz3dhZD9NWiYsBZl5qYhTfNe7Ia8ZeBb+PuswQnEWG5/aFmkAoDj2L6RHUJlAyjDo4dxCbqnDiFUiV4BqMQQIDAQAB\;" But the actual record does NOT have the \ in it. This was confusing to me. -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 512-248-2683 E-Mail: ler@lerctr.org US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 From owner-freebsd-current@FreeBSD.ORG Tue Dec 9 20:33:42 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5C5AC1065672 for ; Tue, 9 Dec 2008 20:33:42 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id E8E398FC24 for ; Tue, 9 Dec 2008 20:33:41 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from phobos.local ([192.168.254.200]) (authenticated bits=0) by pooker.samsco.org (8.14.2/8.14.2) with ESMTP id mB9KXbZl020578; Tue, 9 Dec 2008 13:33:38 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <493ED621.5010006@samsco.org> Date: Tue, 09 Dec 2008 13:33:37 -0700 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.13) Gecko/20080313 SeaMonkey/1.1.9 MIME-Version: 1.0 To: Marcel Moolenaar References: <200812081621.mB8GLMxB041498@lava.sentex.ca> <200812081906.mB8J6oha042222@lava.sentex.ca> <200812082049.mB8KnHSN042710@lava.sentex.ca> <84A7F176-5A74-48AC-859A-C0D4C7CBCB48@mac.com> <7.1.0.9.0.20081208173515.13f62e88@sentex.net> <200812091457.mB9EvLSD047534@lava.sentex.ca> <493EA759.4000504@samsco.org> <0E8F5AD4-A139-413E-A760-A1BEDDF44BAA@mac.com> In-Reply-To: <0E8F5AD4-A139-413E-A760-A1BEDDF44BAA@mac.com> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.4 required=3.8 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on pooker.samsco.org Cc: freebsd-current@freebsd.org, Mike Tancsa Subject: Re: uart vs sio differences ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Dec 2008 20:33:42 -0000 Marcel Moolenaar wrote: > > On Dec 9, 2008, at 9:14 AM, Scott Long wrote: > >> That aside, I think what needs to happen is for the driver to use the >> interrupt handler to pull the bytes out of the hardware and into an >> internal lockless ring buffer, then schedule the swi to process the ring >> buffer. > > The uart(4) driver is exactly doing what you describe. > Yup, my mistake. However, I think that the semaphore spinwait in uart_sched_softih() is the source of the problems here. Imagine a a timeline scenario like this (in 8-CURRENT): CPU0 CPU1 irq4 uart_intr() UART_RECEIVE() uart_sched_softih() check ttypend swi_sched() uart_swi uart_tty_intr() clear ttypend tty_lock() irq4 uart_intr() UART_RECEIVE() uart_sched_softih() check ttypend swi_sched() irq4 uart_intr() UART_RECEIVE() uart_sched_softif() check ttypend With FreeBSD 6 and 7, it's even worse because Giant can be contended on before ttypend is cleared. But in either case, what you've effectively done here is created a home-rolled spinlock that comes after a sleep lock, so the time-critical interrupt handler is now slaved to the slow swi handler, completely defeating the benefits of having a fast handler (and also defeating WITNESS checks against this kind of problem). You really don't need the home-rolled semaphore. You already atomically read and write the variable, so you can just have uart_tty_intr() continue to loop around to check if it changes. Or since you already have a nice lockless ring buffer, you could just extend it also store each pending flag update. Scott From owner-freebsd-current@FreeBSD.ORG Tue Dec 9 20:44:07 2008 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 25188106564A for ; Tue, 9 Dec 2008 20:44:07 +0000 (UTC) (envelope-from elias@artx.ru) Received: from round.artx.ru (round.artx.ru [80.73.175.73]) by mx1.freebsd.org (Postfix) with ESMTP id B09948FC1F for ; Tue, 9 Dec 2008 20:44:05 +0000 (UTC) (envelope-from elias@artx.ru) Received: by round.artx.ru (Postfix, from userid 1001) id 3AEA75C27; Tue, 9 Dec 2008 23:44:04 +0300 (MSK) Date: Tue, 9 Dec 2008 23:44:04 +0300 From: Ilya Orehov To: "M. Warner Losh" Message-ID: <20081209204404.GA17018@artx.ru> References: <20081209141908.GA15845@artx.ru> <20081209.092739.35219831.imp@bsdimp.com> <20081209192439.GA16703@artx.ru> <20081209.124743.-201314317.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20081209.124743.-201314317.imp@bsdimp.com> User-Agent: Mutt/1.4.2.3i Cc: current@FreeBSD.org Subject: Re: "interrupt storm..."; seems associated with an0 NIC X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Dec 2008 20:44:07 -0000 +------- M. Warner Losh, 2008-12-09 ------- | In message: <20081209192439.GA16703@artx.ru> | Ilya Orehov writes: | : Need to ack 0x1 | | What happens if you also print the current mask register? CBB_SOCKET_MASK? Rebooted with xl0 card inserted, first time (after initialization) mask=7, after eject/insert xl0 mask=1. ... xl0: Ethernet address: 00:60:08:d2:38:56 xl0: [ITHREAD] Need to ack 0x1, mask=00000007 acd0: CDROM at ata1-master PIO4 Trying to mount root from ufs:/dev/ad0s2a WARNING: attempt to net_add_domain(bluetooth) after domainfinalize() xl0: reset didn't complete xl0: command never completed! xl0: command never completed! xl0: command never completed! tdkphy0: detached miibus0: detached xl0: detached Need to ack 0x1, mask=00000001 xl0: <3Com 3c575TX Fast Etherlink XL> port 0x1000-0x103f irq 11 at device 0.0 on cardbus1 miibus0: on xl0 ... Rebooted once more, without card. After card (xl0) inserted, mask=1. Rebooted with same card inserted in second slot. First time (after initialization) mask=7, after eject/insert into same slot xl0 mask=1, after eject card was inserted into first slot, mask=1, code was: if (!ack) { mask = cbb_get(sc, CBB_SOCKET_MASK); printf("Need to ack %#x, mask=%08x\n", sockevent, mask); cbb_set(sc, CBB_SOCKET_EVENT, sockevent); } regards, Ilya. | | Warner | +----------------------------- From owner-freebsd-current@FreeBSD.ORG Tue Dec 9 20:44:42 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B86981065673 for ; Tue, 9 Dec 2008 20:44:42 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout018.mac.com (asmtpout018.mac.com [17.148.16.93]) by mx1.freebsd.org (Postfix) with ESMTP id A06DA8FC21 for ; Tue, 9 Dec 2008 20:44:42 +0000 (UTC) (envelope-from xcllnt@mac.com) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Received: from lynx.jnpr.net (natint3.juniper.net [66.129.224.36]) by asmtp018.mac.com (Sun Java(tm) System Messaging Server 6.3-7.03 (built Aug 7 2008; 32bit)) with ESMTPSA id <0KBM00DO2MY5V520@asmtp018.mac.com> for freebsd-current@freebsd.org; Tue, 09 Dec 2008 12:44:30 -0800 (PST) Message-id: <30BECC4D-DD91-4C13-8F0B-5A2AE59DFC5D@mac.com> From: Marcel Moolenaar To: Scott Long In-reply-to: <493ED621.5010006@samsco.org> Date: Tue, 09 Dec 2008 12:44:29 -0800 References: <200812081621.mB8GLMxB041498@lava.sentex.ca> <200812081906.mB8J6oha042222@lava.sentex.ca> <200812082049.mB8KnHSN042710@lava.sentex.ca> <84A7F176-5A74-48AC-859A-C0D4C7CBCB48@mac.com> <7.1.0.9.0.20081208173515.13f62e88@sentex.net> <200812091457.mB9EvLSD047534@lava.sentex.ca> <493EA759.4000504@samsco.org> <0E8F5AD4-A139-413E-A760-A1BEDDF44BAA@mac.com> <493ED621.5010006@samsco.org> X-Mailer: Apple Mail (2.929.2) Cc: freebsd-current@freebsd.org, Mike Tancsa Subject: Re: uart vs sio differences ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Dec 2008 20:44:42 -0000 On Dec 9, 2008, at 12:33 PM, Scott Long wrote: > > Yup, my mistake. However, I think that the semaphore spinwait in > uart_sched_softih() is the source of the problems here. It's not a semaphore spinwait. It's just an atomic operation: 1. read old, 2. calculate new from old, 3. atomic_cmpset(old, new) 4. goto 1 if 3 fails. The loop iterates only if ttypend got changed between 1 and 3. There's no spinwaiting and no semaphore-like behaviour. FYI, -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-current@FreeBSD.ORG Tue Dec 9 21:18:43 2008 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AC84F1065672 for ; Tue, 9 Dec 2008 21:18:43 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 42E2E8FC20 for ; Tue, 9 Dec 2008 21:18:43 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id mB9LG7Kv099036; Tue, 9 Dec 2008 14:16:07 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Tue, 09 Dec 2008 14:16:16 -0700 (MST) Message-Id: <20081209.141616.2139790010.imp@bsdimp.com> To: elias@artx.ru From: "M. Warner Losh" In-Reply-To: <20081209204404.GA17018@artx.ru> References: <20081209192439.GA16703@artx.ru> <20081209.124743.-201314317.imp@bsdimp.com> <20081209204404.GA17018@artx.ru> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: current@FreeBSD.org Subject: Re: "interrupt storm..."; seems associated with an0 NIC X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Dec 2008 21:18:43 -0000 Thanks! This helps a lot. The fact that xl works also is an important hint for me for another problem I'm chasing... does this patch cause the printfs we've added to not be hit? Warner Index: pccbb.c =================================================================== --- pccbb.c (revision 185750) +++ pccbb.c (working copy) @@ -514,7 +514,7 @@ * a chance to run. */ mtx_lock(&sc->mtx); - cbb_setb(sc, CBB_SOCKET_MASK, CBB_SOCKET_MASK_CD | CBB_SOCKET_MASK_CSTS); + cbb_setb(sc, CBB_SOCKET_MASK, CBB_SOCKET_MASK_CD); msleep(&sc->intrhand, &sc->mtx, 0, "-", 0); err = 0; while (err != EWOULDBLOCK && In message: <20081209204404.GA17018@artx.ru> Ilya Orehov writes: : +------- M. Warner Losh, 2008-12-09 ------- : | In message: <20081209192439.GA16703@artx.ru> : | Ilya Orehov writes: : | : Need to ack 0x1 : | : | What happens if you also print the current mask register? CBB_SOCKET_MASK? : : Rebooted with xl0 card inserted, : first time (after initialization) mask=7, : after eject/insert xl0 mask=1. : : ... : xl0: Ethernet address: 00:60:08:d2:38:56 : xl0: [ITHREAD] : Need to ack 0x1, mask=00000007 : acd0: CDROM at ata1-master PIO4 : Trying to mount root from ufs:/dev/ad0s2a : WARNING: attempt to net_add_domain(bluetooth) after domainfinalize() : xl0: reset didn't complete : xl0: command never completed! : xl0: command never completed! : xl0: command never completed! : tdkphy0: detached : miibus0: detached : xl0: detached : Need to ack 0x1, mask=00000001 : xl0: <3Com 3c575TX Fast Etherlink XL> port 0x1000-0x103f irq 11 at device 0.0 on cardbus1 : miibus0: on xl0 : ... : : Rebooted once more, without card. : After card (xl0) inserted, mask=1. : : Rebooted with same card inserted in second slot. : First time (after initialization) mask=7, : after eject/insert into same slot xl0 mask=1, : after eject card was inserted into first slot, mask=1, : : code was: : if (!ack) { : mask = cbb_get(sc, CBB_SOCKET_MASK); : printf("Need to ack %#x, mask=%08x\n", sockevent, mask); : cbb_set(sc, CBB_SOCKET_EVENT, sockevent); : } : : regards, : Ilya. : : : | : | Warner : | : +----------------------------- : : From owner-freebsd-current@FreeBSD.ORG Tue Dec 9 21:26:10 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0C23E106574A for ; Tue, 9 Dec 2008 21:26:09 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 15E548FC0C for ; Tue, 9 Dec 2008 21:26:08 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [IPv6:::1]) (authenticated bits=0) by server.baldwin.cx (8.14.3/8.14.3) with ESMTP id mB9LPpFu014957; Tue, 9 Dec 2008 16:26:02 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: "Paul B. Mahol" Date: Tue, 9 Dec 2008 16:02:10 -0500 User-Agent: KMail/1.9.7 References: <200811191510.53793.jhb@FreeBSD.org> <200812051608.50120.jhb@freebsd.org> <3a142e750812051354n747bcbcayb31d8d5f4cc15098@mail.gmail.com> In-Reply-To: <3a142e750812051354n747bcbcayb31d8d5f4cc15098@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200812091602.10850.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [IPv6:::1]); Tue, 09 Dec 2008 16:26:03 -0500 (EST) X-Virus-Scanned: ClamAV 0.94.2/8738/Tue Dec 9 14:31:40 2008 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: freebsd-current@freebsd.org Subject: Re: [PATCH] MPSAFE/LOOKUP_SHARED cd9660 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Dec 2008 21:26:10 -0000 On Friday 05 December 2008 04:54:23 pm Paul B. Mahol wrote: > On 12/5/08, John Baldwin wrote: > > On Friday 05 December 2008 03:56:31 pm Paul B. Mahol wrote: > >> On 12/5/08, John Baldwin wrote: > >> > On Thursday 20 November 2008 05:47:28 pm John Baldwin wrote: > >> >> On Thursday 20 November 2008 04:30:57 pm Paul B. Mahol wrote: > >> >> > On 11/19/08, John Baldwin wrote: > >> >> > > This is a relatively simple patch to mark cd9660 MPSAFE and enable > >> > shared > >> >> > > lookups. The changes to cd9660_lookup() mirror similar changes to > >> >> > > ufs_lookup() to use static variables for local data rather than > >> >> > > abusing > >> >> > > i-node members of the parent directory. I've done some light > >> >> > > testing > >> >> > > of > >> >> > > this, but not super-strenuous. This patch also includes simple > >> >> > > locking > >> >> for > >> >> > > the iconv support in the kernel. That locking uses an sx lock to > >> >> serialize > >> >> > > open and close of translator tables and the associated refcount. > >> >> > > Actual > >> >> > > conversions do not need any locks, however as the mount holds a > >> > reference > >> >> on > >> >> > > the table. > >> >> > > > >> >> > > http://www.FreeBSD.org/~jhb/patches/cd9660_mpsafe.patch > >> >> > > > >> >> > > >> >> > With this patch I'm unable to kldunload libiconv.ko once it is > >> >> > loaded. > >> >> > And trying to kldunload libiconv.ko will make any next > >> >> kldload/kldstat/kldunload > >> >> > to fail waiting forever(livelock). > >> >> > > >> >> > Regression were not encountered while only cd9660.ko were kldloaded. > >> >> > >> >> So this is actually due to a bug in the module code. If you have two > >> > modules > >> >> like this: > >> >> > >> >> DECLARE_MODULE(foo, SI_SUB_DRIVERS, SI_ORDER_FIRST); > >> >> DECLARE_MODULE(bar, SI_SUB_DRIVERS, SI_ORDER_SECOND); > >> >> > >> >> The SI_* constants ensure that foo's module handler is called before > > bar's > >> >> > >> >> module handler for MOD_LOAD. However, we don't enforce a reverse order > >> >> (bar > >> >> then foo) for MOD_UNLOAD. In fact, the order of MOD_UNLOAD events is > >> >> random > >> >> and has no relation to the SI_* constants. :( > >> >> > >> >> What is happening here is that one of the 'bar' modules in libiconv.ko > >> >> is > >> >> getting unloaded after 'foo' gets unloaded and using a destroyed lock > > (you > >> >> > >> >> get a panic if you run with INVARIANTS). > >> > > >> > So this should now be fixed with this commit. If you could verify that > >> > iconv > >> > works ok with the latest kern_module.c I would appreciate it. > >> > > >> > Author: jhb > >> > Date: Fri Dec 5 16:47:30 2008 > >> > New Revision: 185642 > >> > URL: http://svn.freebsd.org/changeset/base/185642 > >> > > >> > Log: > >> > When the SYSINIT() to load a module invokes the MOD_LOAD event > >> > successfully, > >> > move that module to the head of the associated linker file's list of > >> > modules. > >> > The end result is that once all the modules are loaded, they are > >> > sorted > > in > >> > the reverse of their load order. This causes the kernel linker to > > invoke > >> > the MOD_QUIESCE and MOD_UNLOAD events in the reverse of the order that > >> > MOD_LOAD was invoked. This means that the ordering of MOD_LOAD events > >> > that > >> > is set by the SI_* paramters to DECLARE_MODULE() are now honored in > >> > the > >> > same > >> > order they would be for SYSUNINIT() for the MOD_QUIESCE and MOD_UNLOAD > >> > events. > >> > > >> > MFC after: 1 month > >> > > >> > -- > >> > John Baldwin > >> > > >> > >> Yes it works, I tried hard multiple times kldload/kldunload > >> {libiconv,cd9660,cd9660_iconv in various order} to livelock/panic it, > >> but without success. > >> > >> FYI following LORs happened: > >> > >> lock order reversal: > >> 1st 0xc4322ce8 isofs (isofs) @ /usr/src/sys/kern/vfs_lookup.c:442 > >> 2nd 0xd7d8d740 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:2443 > >> 3rd 0xc4322bdc isofs (isofs) @ > >> /usr/src/sys/modules/cd9660/../../fs/cd9660/cd9660_vfsops.c:694 > > > > This LOR should be addressed in the latest cd9660 locking patches. > > > > -- > > John Baldwin > > > > Oh, why I did not checked new version? > > Yes that LOR have gone, but when doing "ll -R" first time on /mnt > I got following messages from kernel: > > RRIP without PX field? x ~ 50 times. > > I see you changed LK_EXCLUSIVE to flags, and with MPSAFE .... The RRIP stuff is all done in cd9660_vget_internal() under an exclusive lock. It could be a property of the ISO image. "PX" holds permissions (owner, etc.). Do you get the same messages w/o the patch with the same ISO image / CD? -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue Dec 9 23:01:35 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BA931106567E for ; Tue, 9 Dec 2008 23:01:35 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (adsl-63-193-123-122.dsl.snfc21.pacbell.net [63.193.123.122]) by mx1.freebsd.org (Postfix) with ESMTP id 3C0B38FC0C for ; Tue, 9 Dec 2008 23:01:35 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.3/8.14.3) with ESMTP id mB9N1Zb7091414 for ; Tue, 9 Dec 2008 15:01:35 -0800 (PST) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.3/8.14.3/Submit) id mB9N1Zq6091413 for current@freebsd.org; Tue, 9 Dec 2008 15:01:35 -0800 (PST) (envelope-from david) Date: Tue, 9 Dec 2008 15:01:34 -0800 From: David Wolfskill To: current@freebsd.org Message-ID: <20081209230134.GC60731@albert.catwhisker.org> Mail-Followup-To: David Wolfskill , current@freebsd.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="h13GW2gLSV2TxsNR" Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Cc: Subject: Laptop w/ dark screen & no (working) keyboard X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Dec 2008 23:01:35 -0000 --h13GW2gLSV2TxsNR Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable This would be a freshly-built CURRENT; sources as of around 0330 hrs. US/Pacific this morning. Breaking into the debugger (Ctl+Atl+Esc), I see on the serial console: KDB: enter: manual escape to debugger [thread pid 12 tid 100020 ] Stopped at kdb_enter+0x3a: movl $0,kdb_why db> bt Tracing pid 12 tid 100020 td 0xc4e766c0 kdb_enter(c0b6de50,c0ba2bbb,1,0,1,...) at kdb_enter+0x3a scgetc(c0cf5fd0,0,c0ba2ae5,26b,c085148c,...) at scgetc+0x53f sckbdevent(c4de0300,0,c0e874a0,c4dac880,c4a78c64,...) at sckbdevent+0x224 kbdmux_intr(c4de0300,0,c4dac898,c4e6a7c0,c4dac898,...) at kbdmux_intr+0x2b kbdmux_kbd_intr(c4de0300,1,c0bb8e10,54,c4e6a7dc,...) at kbdmux_kbd_intr+0x25 taskqueue_run(c4e6a7c0,c4a78cc8,c07f14e5,0,0,...) at taskqueue_run+0x10b taskqueue_swi_giant_run(0,0,c0bb0715,46d,c4dac038,...) at taskqueue_swi_gia= nt_run+0x13 intr_event_execute_handlers(c4d677ec,c4dac000,c0bb0715,4dd,c4dac070,...) at= intr_event_execute_handlers+0x125 ithread_loop(c4e749d0,c4a78d38,c0bb0490,32d,c4d677ec,...) at ithread_loop+0= x9f fork_exit(c07f20c0,c4e749d0,c4a78d38) at fork_exit+0xb8 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip =3D 0, esp =3D 0xc4a78d70, ebp =3D 0 --- db> show locks exclusive sleep mutex Giant (Giant) r =3D 1 (0xc0cf5fd0) locked @ /usr/src/= sys/dev/kbdmux/kbdmux.c:1044 db>=20 Anything else I can try to extract from this that might be useful? Peace, david --=20 David H. Wolfskill david@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --h13GW2gLSV2TxsNR Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkk++M4ACgkQmprOCmdXAD3zgQCfWvBdswYGVgxqq16WcGCHWi5g 98YAnjBhOJMvYvXKD3sWVxQR5JxTW6b7 =keKI -----END PGP SIGNATURE----- --h13GW2gLSV2TxsNR-- From owner-freebsd-current@FreeBSD.ORG Tue Dec 9 23:15:09 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B9D261065678 for ; Tue, 9 Dec 2008 23:15:09 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.30]) by mx1.freebsd.org (Postfix) with ESMTP id 686058FC13 for ; Tue, 9 Dec 2008 23:15:09 +0000 (UTC) (envelope-from onemda@gmail.com) Received: by yw-out-2324.google.com with SMTP id 9so111014ywe.13 for ; Tue, 09 Dec 2008 15:15:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=7FOOBsdDUcJsM5XhqlfDPbD2XRoPrTdR/0h0PATiYgM=; b=S7rbsmhxPaVxuONrr3eDmXeN5ARYJtEwgQd57YblC03049zspyK2g/O9gZEl5y8+tF 0IPJReM3eX6nlExUGYf4ixoyx9Iz1JcRAGmkxOXF4wmD7bXfJZJTCSUJMXqEj/JUhaUh fLjH+Xzg+2SmqvAMb8q04QbbMKXIgpxJbMReE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=uUzRyeGulpxH5qytRGCdftwMqm2RsxBH6DfeZJCis28BOBJzK83a1ul94R+gXC1H7U Jp6iNCImhzZBzjEEZ2ZzfnvntBHayszEnokeZ03CHmN/0bgXgBka3j6HvhhN2qJWK59k RIQEldquaezD1Mb9YJBoWZ8FaXl8t/WPggQWo= Received: by 10.231.30.74 with SMTP id t10mr13415ibc.33.1228864507705; Tue, 09 Dec 2008 15:15:07 -0800 (PST) Received: by 10.231.15.194 with HTTP; Tue, 9 Dec 2008 15:15:07 -0800 (PST) Message-ID: <3a142e750812091515u3f2e5807j3652f2cc3551a3b2@mail.gmail.com> Date: Wed, 10 Dec 2008 00:15:07 +0100 From: "Paul B. Mahol" To: "John Baldwin" In-Reply-To: <200812091602.10850.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200811191510.53793.jhb@FreeBSD.org> <200812051608.50120.jhb@freebsd.org> <3a142e750812051354n747bcbcayb31d8d5f4cc15098@mail.gmail.com> <200812091602.10850.jhb@freebsd.org> Cc: freebsd-current@freebsd.org Subject: Re: [PATCH] MPSAFE/LOOKUP_SHARED cd9660 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Dec 2008 23:15:09 -0000 On 12/9/08, John Baldwin wrote: > On Friday 05 December 2008 04:54:23 pm Paul B. Mahol wrote: >> On 12/5/08, John Baldwin wrote: >> > On Friday 05 December 2008 03:56:31 pm Paul B. Mahol wrote: >> >> On 12/5/08, John Baldwin wrote: >> >> > On Thursday 20 November 2008 05:47:28 pm John Baldwin wrote: >> >> >> On Thursday 20 November 2008 04:30:57 pm Paul B. Mahol wrote: >> >> >> > On 11/19/08, John Baldwin wrote: >> >> >> > > This is a relatively simple patch to mark cd9660 MPSAFE and >> >> >> > > enable >> >> > shared >> >> >> > > lookups. The changes to cd9660_lookup() mirror similar changes >> >> >> > > to >> >> >> > > ufs_lookup() to use static variables for local data rather than >> >> >> > > abusing >> >> >> > > i-node members of the parent directory. I've done some light >> >> >> > > testing >> >> >> > > of >> >> >> > > this, but not super-strenuous. This patch also includes simple >> >> >> > > locking >> >> >> for >> >> >> > > the iconv support in the kernel. That locking uses an sx lock >> >> >> > > to >> >> >> serialize >> >> >> > > open and close of translator tables and the associated refcount. >> >> >> > > Actual >> >> >> > > conversions do not need any locks, however as the mount holds a >> >> > reference >> >> >> on >> >> >> > > the table. >> >> >> > > >> >> >> > > http://www.FreeBSD.org/~jhb/patches/cd9660_mpsafe.patch >> >> >> > > >> >> >> > >> >> >> > With this patch I'm unable to kldunload libiconv.ko once it is >> >> >> > loaded. >> >> >> > And trying to kldunload libiconv.ko will make any next >> >> >> kldload/kldstat/kldunload >> >> >> > to fail waiting forever(livelock). >> >> >> > >> >> >> > Regression were not encountered while only cd9660.ko were >> >> >> > kldloaded. >> >> >> >> >> >> So this is actually due to a bug in the module code. If you have >> >> >> two >> >> > modules >> >> >> like this: >> >> >> >> >> >> DECLARE_MODULE(foo, SI_SUB_DRIVERS, SI_ORDER_FIRST); >> >> >> DECLARE_MODULE(bar, SI_SUB_DRIVERS, SI_ORDER_SECOND); >> >> >> >> >> >> The SI_* constants ensure that foo's module handler is called before >> > bar's >> >> >> >> >> >> module handler for MOD_LOAD. However, we don't enforce a reverse > order >> >> >> (bar >> >> >> then foo) for MOD_UNLOAD. In fact, the order of MOD_UNLOAD events >> >> >> is >> >> >> random >> >> >> and has no relation to the SI_* constants. :( >> >> >> >> >> >> What is happening here is that one of the 'bar' modules in >> >> >> libiconv.ko >> >> >> is >> >> >> getting unloaded after 'foo' gets unloaded and using a destroyed >> >> >> lock >> > (you >> >> >> >> >> >> get a panic if you run with INVARIANTS). >> >> > >> >> > So this should now be fixed with this commit. If you could verify >> >> > that >> >> > iconv >> >> > works ok with the latest kern_module.c I would appreciate it. >> >> > >> >> > Author: jhb >> >> > Date: Fri Dec 5 16:47:30 2008 >> >> > New Revision: 185642 >> >> > URL: http://svn.freebsd.org/changeset/base/185642 >> >> > >> >> > Log: >> >> > When the SYSINIT() to load a module invokes the MOD_LOAD event >> >> > successfully, >> >> > move that module to the head of the associated linker file's list >> >> > of >> >> > modules. >> >> > The end result is that once all the modules are loaded, they are >> >> > sorted >> > in >> >> > the reverse of their load order. This causes the kernel linker to >> > invoke >> >> > the MOD_QUIESCE and MOD_UNLOAD events in the reverse of the order > that >> >> > MOD_LOAD was invoked. This means that the ordering of MOD_LOAD > events >> >> > that >> >> > is set by the SI_* paramters to DECLARE_MODULE() are now honored in >> >> > the >> >> > same >> >> > order they would be for SYSUNINIT() for the MOD_QUIESCE and > MOD_UNLOAD >> >> > events. >> >> > >> >> > MFC after: 1 month >> >> > >> >> > -- >> >> > John Baldwin >> >> > >> >> >> >> Yes it works, I tried hard multiple times kldload/kldunload >> >> {libiconv,cd9660,cd9660_iconv in various order} to livelock/panic it, >> >> but without success. >> >> >> >> FYI following LORs happened: >> >> >> >> lock order reversal: >> >> 1st 0xc4322ce8 isofs (isofs) @ /usr/src/sys/kern/vfs_lookup.c:442 >> >> 2nd 0xd7d8d740 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:2443 >> >> 3rd 0xc4322bdc isofs (isofs) @ >> >> /usr/src/sys/modules/cd9660/../../fs/cd9660/cd9660_vfsops.c:694 >> > >> > This LOR should be addressed in the latest cd9660 locking patches. >> > >> > -- >> > John Baldwin >> > >> >> Oh, why I did not checked new version? >> >> Yes that LOR have gone, but when doing "ll -R" first time on /mnt >> I got following messages from kernel: >> >> RRIP without PX field? x ~ 50 times. >> >> I see you changed LK_EXCLUSIVE to flags, and with MPSAFE .... > > The RRIP stuff is all done in cd9660_vget_internal() under an exclusive > lock. > It could be a property of the ISO image. "PX" holds permissions (owner, > etc.). Do you get the same messages w/o the patch with the same ISO image / > CD? > > -- > John Baldwin > No I do not, but I may try other CDs I have many of them, including FreeBSD one. If it is irrelevant than it should not be displayed. -- Paul From owner-freebsd-current@FreeBSD.ORG Tue Dec 9 23:16:45 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B05801065680 for ; Tue, 9 Dec 2008 23:16:45 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.248]) by mx1.freebsd.org (Postfix) with ESMTP id 5C0338FC19 for ; Tue, 9 Dec 2008 23:16:45 +0000 (UTC) (envelope-from onemda@gmail.com) Received: by an-out-0708.google.com with SMTP id b6so105658ana.13 for ; Tue, 09 Dec 2008 15:16:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=WBQFCDyb9dvi4Ct7Q9WqNhSFSgpPTHwGBeG2jBfOwok=; b=V9dFoePVO3ti7rlMXiuPYWv+ESkUkXaiIvFJDLwCsaZYfcEOf0wSp+QapE98mdqRkk eE6X8l2pMwLaRjx+c43KEs0MtFrvn3RBQtUvyI3i57kmyDJDmPjuZFgJ3UVLNF9HVDfR QdpAgokcdHvwrU+wVIgSh0eFw3Wuwn6YMmExg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=A2nnzRqzBhK8l774nxw2Orqo3WW73bYJSVkibvuOHCnM9nHFShbEx5K52Jm2/MChFz 2vKhYGG3/ONE20xdaIeBsLi2V7ZMO/0HCzr6LKMMxhu8HS+6YGwz18o6mOlBLO8CJbv+ 19iISr187kQQIVJmN5cHo3m4KPalYhkWLlyEs= Received: by 10.231.16.74 with SMTP id n10mr13578iba.28.1228864603869; Tue, 09 Dec 2008 15:16:43 -0800 (PST) Received: by 10.231.15.194 with HTTP; Tue, 9 Dec 2008 15:16:43 -0800 (PST) Message-ID: <3a142e750812091516n6bb0880ewb298314e9ba296c@mail.gmail.com> Date: Wed, 10 Dec 2008 00:16:43 +0100 From: "Paul B. Mahol" To: "John Baldwin" In-Reply-To: <3a142e750812091515u3f2e5807j3652f2cc3551a3b2@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200811191510.53793.jhb@FreeBSD.org> <200812051608.50120.jhb@freebsd.org> <3a142e750812051354n747bcbcayb31d8d5f4cc15098@mail.gmail.com> <200812091602.10850.jhb@freebsd.org> <3a142e750812091515u3f2e5807j3652f2cc3551a3b2@mail.gmail.com> Cc: freebsd-current@freebsd.org Subject: Re: [PATCH] MPSAFE/LOOKUP_SHARED cd9660 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Dec 2008 23:16:45 -0000 On 12/10/08, Paul B. Mahol wrote: > On 12/9/08, John Baldwin wrote: >> On Friday 05 December 2008 04:54:23 pm Paul B. Mahol wrote: >>> On 12/5/08, John Baldwin wrote: >>> > On Friday 05 December 2008 03:56:31 pm Paul B. Mahol wrote: >>> >> On 12/5/08, John Baldwin wrote: >>> >> > On Thursday 20 November 2008 05:47:28 pm John Baldwin wrote: >>> >> >> On Thursday 20 November 2008 04:30:57 pm Paul B. Mahol wrote: >>> >> >> > On 11/19/08, John Baldwin wrote: >>> >> >> > > This is a relatively simple patch to mark cd9660 MPSAFE and >>> >> >> > > enable >>> >> > shared >>> >> >> > > lookups. The changes to cd9660_lookup() mirror similar changes >>> >> >> > > to >>> >> >> > > ufs_lookup() to use static variables for local data rather than >>> >> >> > > abusing >>> >> >> > > i-node members of the parent directory. I've done some light >>> >> >> > > testing >>> >> >> > > of >>> >> >> > > this, but not super-strenuous. This patch also includes simple >>> >> >> > > locking >>> >> >> for >>> >> >> > > the iconv support in the kernel. That locking uses an sx lock >>> >> >> > > to >>> >> >> serialize >>> >> >> > > open and close of translator tables and the associated >>> >> >> > > refcount. >>> >> >> > > Actual >>> >> >> > > conversions do not need any locks, however as the mount holds a >>> >> > reference >>> >> >> on >>> >> >> > > the table. >>> >> >> > > >>> >> >> > > http://www.FreeBSD.org/~jhb/patches/cd9660_mpsafe.patch >>> >> >> > > >>> >> >> > >>> >> >> > With this patch I'm unable to kldunload libiconv.ko once it is >>> >> >> > loaded. >>> >> >> > And trying to kldunload libiconv.ko will make any next >>> >> >> kldload/kldstat/kldunload >>> >> >> > to fail waiting forever(livelock). >>> >> >> > >>> >> >> > Regression were not encountered while only cd9660.ko were >>> >> >> > kldloaded. >>> >> >> >>> >> >> So this is actually due to a bug in the module code. If you have >>> >> >> two >>> >> > modules >>> >> >> like this: >>> >> >> >>> >> >> DECLARE_MODULE(foo, SI_SUB_DRIVERS, SI_ORDER_FIRST); >>> >> >> DECLARE_MODULE(bar, SI_SUB_DRIVERS, SI_ORDER_SECOND); >>> >> >> >>> >> >> The SI_* constants ensure that foo's module handler is called >>> >> >> before >>> > bar's >>> >> >> >>> >> >> module handler for MOD_LOAD. However, we don't enforce a reverse >> order >>> >> >> (bar >>> >> >> then foo) for MOD_UNLOAD. In fact, the order of MOD_UNLOAD events >>> >> >> is >>> >> >> random >>> >> >> and has no relation to the SI_* constants. :( >>> >> >> >>> >> >> What is happening here is that one of the 'bar' modules in >>> >> >> libiconv.ko >>> >> >> is >>> >> >> getting unloaded after 'foo' gets unloaded and using a destroyed >>> >> >> lock >>> > (you >>> >> >> >>> >> >> get a panic if you run with INVARIANTS). >>> >> > >>> >> > So this should now be fixed with this commit. If you could verify >>> >> > that >>> >> > iconv >>> >> > works ok with the latest kern_module.c I would appreciate it. >>> >> > >>> >> > Author: jhb >>> >> > Date: Fri Dec 5 16:47:30 2008 >>> >> > New Revision: 185642 >>> >> > URL: http://svn.freebsd.org/changeset/base/185642 >>> >> > >>> >> > Log: >>> >> > When the SYSINIT() to load a module invokes the MOD_LOAD event >>> >> > successfully, >>> >> > move that module to the head of the associated linker file's list >>> >> > of >>> >> > modules. >>> >> > The end result is that once all the modules are loaded, they are >>> >> > sorted >>> > in >>> >> > the reverse of their load order. This causes the kernel linker to >>> > invoke >>> >> > the MOD_QUIESCE and MOD_UNLOAD events in the reverse of the order >> that >>> >> > MOD_LOAD was invoked. This means that the ordering of MOD_LOAD >> events >>> >> > that >>> >> > is set by the SI_* paramters to DECLARE_MODULE() are now honored >>> >> > in >>> >> > the >>> >> > same >>> >> > order they would be for SYSUNINIT() for the MOD_QUIESCE and >> MOD_UNLOAD >>> >> > events. >>> >> > >>> >> > MFC after: 1 month >>> >> > >>> >> > -- >>> >> > John Baldwin >>> >> > >>> >> >>> >> Yes it works, I tried hard multiple times kldload/kldunload >>> >> {libiconv,cd9660,cd9660_iconv in various order} to livelock/panic it, >>> >> but without success. >>> >> >>> >> FYI following LORs happened: >>> >> >>> >> lock order reversal: >>> >> 1st 0xc4322ce8 isofs (isofs) @ /usr/src/sys/kern/vfs_lookup.c:442 >>> >> 2nd 0xd7d8d740 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:2443 >>> >> 3rd 0xc4322bdc isofs (isofs) @ >>> >> /usr/src/sys/modules/cd9660/../../fs/cd9660/cd9660_vfsops.c:694 >>> > >>> > This LOR should be addressed in the latest cd9660 locking patches. >>> > >>> > -- >>> > John Baldwin >>> > >>> >>> Oh, why I did not checked new version? >>> >>> Yes that LOR have gone, but when doing "ll -R" first time on /mnt >>> I got following messages from kernel: >>> >>> RRIP without PX field? x ~ 50 times. >>> >>> I see you changed LK_EXCLUSIVE to flags, and with MPSAFE .... >> >> The RRIP stuff is all done in cd9660_vget_internal() under an exclusive >> lock. >> It could be a property of the ISO image. "PX" holds permissions (owner, >> etc.). Do you get the same messages w/o the patch with the same ISO image >> / >> CD? >> >> -- >> John Baldwin >> > > No I do not, but I may try other CDs I have many of them, including FreeBSD s/Yes I do. Its to late here ... > one. > If it is irrelevant than it should not be displayed. -- Paul From owner-freebsd-current@FreeBSD.ORG Tue Dec 9 23:22:09 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DE933106564A for ; Tue, 9 Dec 2008 23:22:09 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (adsl-63-193-123-122.dsl.snfc21.pacbell.net [63.193.123.122]) by mx1.freebsd.org (Postfix) with ESMTP id 9AF2F8FC18 for ; Tue, 9 Dec 2008 23:22:09 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.3/8.14.3) with ESMTP id mB9NM9xj091497 for ; Tue, 9 Dec 2008 15:22:09 -0800 (PST) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.3/8.14.3/Submit) id mB9NM93T091496 for current@freebsd.org; Tue, 9 Dec 2008 15:22:09 -0800 (PST) (envelope-from david) Date: Tue, 9 Dec 2008 15:22:09 -0800 From: David Wolfskill To: current@freebsd.org Message-ID: <20081209232209.GD60731@albert.catwhisker.org> Mail-Followup-To: David Wolfskill , current@freebsd.org References: <20081209230134.GC60731@albert.catwhisker.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="684cmtc/Pyvt2LSS" Content-Disposition: inline In-Reply-To: <20081209230134.GC60731@albert.catwhisker.org> User-Agent: Mutt/1.4.2.3i Cc: Subject: Re: Laptop w/ dark screen & no (working) keyboard X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Dec 2008 23:22:10 -0000 --684cmtc/Pyvt2LSS Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable After a reboot -- which exhibited the same symptoms initially: login: lock order reversal: 1st 0xc55bfad0 ufs (ufs) @ /usr/src/sys/ufs/ffs/ffs_snapshot.c:424 2nd 0xd8d3fc50 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:2443 3rd 0xc52d337c ufs (ufs) @ /usr/src/sys/ufs/ffs/ffs_snapshot.c:545 KDB: stack backtrace: db_trace_self_wrapper(c0bb77be,c4bbb40c,c0851645,4,c0bb2cb1,...) at db_trac= e_self_wrapper+0x26 kdb_backtrace(4,c0bb2cb1,c4d21810,c4d24e18,c4bbb468,...) at kdb_backtrace+0= x29 _witness_debugger(c0bba487,c52d337c,c0bade76,c4d24e18,c0bd8a13,...) at _wit= ness_debugger+0x25 witness_checkorder(c52d337c,9,c0bd8a13,221,0,...) at witness_checkorder+0x8= 39 __lockmgr_args(c52d337c,80100,c52d3398,0,0,...) at __lockmgr_args+0x797 ffs_lock(c4bbb578,c0e35ee0,c55860a4,80100,c52d3324,...) at ffs_lock+0x8a VOP_LOCK1_APV(c0cbf480,c4bbb578,c4bbb598,c0cd3400,c52d3324,...) at VOP_LOCK= 1_APV+0xa5 _vn_lock(c52d3324,80100,c0bd8a13,221,c4d55800,...) at _vn_lock+0x5e ffs_snapshot(c51c0a00,c53029c0,c0bda378,15e,3,...) at ffs_snapshot+0x1527 ffs_mount(c51c0a00,c5586000,c0bc0c2b,3dc,c4e8ac80,...) at ffs_mount+0x146f vfs_donmount(c5586000,211000,c52fdb00,c52fdb00,201000,...) at vfs_donmount+= 0x1312 nmount(c5586000,c4bbbcf8,c,c4bbbd38,c0c9b790,...) at nmount+0xbe syscall(c4bbbd38) at syscall+0x2a3 -- I got involved in some other things, when I happened to see (on the serial console): Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (378, FreeBSD ELF32, nmount), eip =3D 0x280e6c9b, esp =3D 0xbfb= feb1c, ebp =3D 0xbfbfee78 --- info: [drm] Setting GART location based on new memory map info: [drm] Loading R200 Microcode info: [drm] writeback test succeeded in 2 usecs drm0: [MPSAFE] drm0: [ITHREAD] lock order reversal: 1st 0xd8d3fc50 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:2443 2nd 0xc4f9f01c snaplk (snaplk) @ /usr/src/sys/ufs/ffs/ffs_snapshot.c:794 KDB: stack backtrace: db_trace_self_wrapper(c0bb77be,c4bbb40c,c0851645,4,c0bb2cb1,...) at db_trac= e_self_wrapper+0x26 kdb_backtrace(4,c0bb2cb1,c4d21810,c4d25638,c4bbb468,...) at kdb_backtrace+0= x29 _witness_debugger(c0bba46e,c4f9f01c,c0bd8a75,c4d25638,c0bd8a13,...) at _wit= ness_debugger+0x25 witness_checkorder(c4f9f01c,9,c0bd8a13,31a,c55bfaec,...) at witness_checkor= der+0x839 __lockmgr_args(c4f9f01c,80400,c55bfaec,0,0,...) at __lockmgr_args+0x797 ffs_lock(c4bbb578,0,0,80400,c55bfa78,...) at ffs_lock+0x8a VOP_LOCK1_APV(c0cbf480,c4bbb578,c211a614,c0cd3400,c55bfa78,...) at VOP_LOCK= 1_APV+0xa5 _vn_lock(c55bfa78,80400,c0bd8a13,31a,0,...) at _vn_lock+0x5e ffs_snapshot(c51c0a00,c53029c0,c0bda378,15e,3,...) at ffs_snapshot+0x28c6 ffs_mount(c51c0a00,c5586000,c0bc0c2b,3dc,c4e8ac80,...) at ffs_mount+0x146f vfs_donmount(c5586000,211000,c52fdb00,c52fdb00,201000,...) at vfs_donmount+= 0x1312 nmount(c5586000,c4bbbcf8,c,c4bbbd38,c0c9b790,...) at nmount+0xbe syscall(c4bbbd38) at syscall+0x2a3 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (378, FreeBSD ELF32, nmount), eip =3D 0x280e6c9b, esp =3D 0xbfb= feb1c, ebp =3D 0xbfbfee78 --- FreeBSD/i386 (Amnesiac) (ttyu0) login:=20 [end of cut/paste] and the screen lit up. :-} Peace, david --=20 David H. Wolfskill david@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --684cmtc/Pyvt2LSS Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkk+/aAACgkQmprOCmdXAD2o5QCfVj2rTOYyoU4mEIw0lgtKUvQU +t0AnjwnbUYlKmNJlutODQ/2rH3yGqGF =Rucp -----END PGP SIGNATURE----- --684cmtc/Pyvt2LSS-- From owner-freebsd-current@FreeBSD.ORG Tue Dec 9 23:56:05 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A11C61065672 for ; Tue, 9 Dec 2008 23:56:05 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from mail-gx0-f18.google.com (mail-gx0-f18.google.com [209.85.217.18]) by mx1.freebsd.org (Postfix) with ESMTP id 359258FC1E for ; Tue, 9 Dec 2008 23:56:05 +0000 (UTC) (envelope-from onemda@gmail.com) Received: by gxk11 with SMTP id 11so431182gxk.12 for ; Tue, 09 Dec 2008 15:56:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=iPY+lnazi89JzCuetPFbsLm2aLFzALR1Rox6BtCJtPo=; b=aM0I47i3KjMfWe1ccKvcblRdVdYwCgYFD7K0ob3lkPKz5vZUr5vmdbeITPtdv3/Ru/ Qib5GA0ieSk3TYmyx3euCQGdFWk/AKysDDIfbyAdlL9q3c2ef/wj+8ZhxExZLiHZim0t zIFCvtD21stDXlgO96usAzj81cahhtx8AjRJc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=Vosxedzv29dFEsBqGnW5Nm4rCpCdQkjV7ZqeTXWjVQt1pJhAAq2ORs6X+JLZvCqIC7 gIFMXKI2N9hZ3eXiKznmlvPipzLKjMkaLUcJVzsejyVJcFAcBNJ94G088cKZLmwBxrlK iuZW0udZojvptE2Q5LwIH9bQXsKPYrIpGNViM= Received: by 10.231.15.73 with SMTP id j9mr14055iba.35.1228866964105; Tue, 09 Dec 2008 15:56:04 -0800 (PST) Received: by 10.231.15.194 with HTTP; Tue, 9 Dec 2008 15:56:04 -0800 (PST) Message-ID: <3a142e750812091556x682008dagb8e1e867d0bdca79@mail.gmail.com> Date: Wed, 10 Dec 2008 00:56:04 +0100 From: "Paul B. Mahol" To: "John Baldwin" In-Reply-To: <3a142e750812091516n6bb0880ewb298314e9ba296c@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200811191510.53793.jhb@FreeBSD.org> <200812051608.50120.jhb@freebsd.org> <3a142e750812051354n747bcbcayb31d8d5f4cc15098@mail.gmail.com> <200812091602.10850.jhb@freebsd.org> <3a142e750812091515u3f2e5807j3652f2cc3551a3b2@mail.gmail.com> <3a142e750812091516n6bb0880ewb298314e9ba296c@mail.gmail.com> Cc: freebsd-current@freebsd.org Subject: Re: [PATCH] MPSAFE/LOOKUP_SHARED cd9660 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Dec 2008 23:56:05 -0000 On 12/10/08, Paul B. Mahol wrote: > On 12/10/08, Paul B. Mahol wrote: >> On 12/9/08, John Baldwin wrote: >>> On Friday 05 December 2008 04:54:23 pm Paul B. Mahol wrote: >>>> On 12/5/08, John Baldwin wrote: >>>> > On Friday 05 December 2008 03:56:31 pm Paul B. Mahol wrote: >>>> >> On 12/5/08, John Baldwin wrote: >>>> >> > On Thursday 20 November 2008 05:47:28 pm John Baldwin wrote: >>>> >> >> On Thursday 20 November 2008 04:30:57 pm Paul B. Mahol wrote: >>>> >> >> > On 11/19/08, John Baldwin wrote: >>>> >> >> > > This is a relatively simple patch to mark cd9660 MPSAFE and >>>> >> >> > > enable >>>> >> > shared >>>> >> >> > > lookups. The changes to cd9660_lookup() mirror similar >>>> >> >> > > changes >>>> >> >> > > to >>>> >> >> > > ufs_lookup() to use static variables for local data rather >>>> >> >> > > than >>>> >> >> > > abusing >>>> >> >> > > i-node members of the parent directory. I've done some light >>>> >> >> > > testing >>>> >> >> > > of >>>> >> >> > > this, but not super-strenuous. This patch also includes >>>> >> >> > > simple >>>> >> >> > > locking >>>> >> >> for >>>> >> >> > > the iconv support in the kernel. That locking uses an sx lock >>>> >> >> > > to >>>> >> >> serialize >>>> >> >> > > open and close of translator tables and the associated >>>> >> >> > > refcount. >>>> >> >> > > Actual >>>> >> >> > > conversions do not need any locks, however as the mount holds >>>> >> >> > > a >>>> >> > reference >>>> >> >> on >>>> >> >> > > the table. >>>> >> >> > > >>>> >> >> > > http://www.FreeBSD.org/~jhb/patches/cd9660_mpsafe.patch >>>> >> >> > > >>>> >> >> > >>>> >> >> > With this patch I'm unable to kldunload libiconv.ko once it is >>>> >> >> > loaded. >>>> >> >> > And trying to kldunload libiconv.ko will make any next >>>> >> >> kldload/kldstat/kldunload >>>> >> >> > to fail waiting forever(livelock). >>>> >> >> > >>>> >> >> > Regression were not encountered while only cd9660.ko were >>>> >> >> > kldloaded. >>>> >> >> >>>> >> >> So this is actually due to a bug in the module code. If you have >>>> >> >> two >>>> >> > modules >>>> >> >> like this: >>>> >> >> >>>> >> >> DECLARE_MODULE(foo, SI_SUB_DRIVERS, SI_ORDER_FIRST); >>>> >> >> DECLARE_MODULE(bar, SI_SUB_DRIVERS, SI_ORDER_SECOND); >>>> >> >> >>>> >> >> The SI_* constants ensure that foo's module handler is called >>>> >> >> before >>>> > bar's >>>> >> >> >>>> >> >> module handler for MOD_LOAD. However, we don't enforce a reverse >>> order >>>> >> >> (bar >>>> >> >> then foo) for MOD_UNLOAD. In fact, the order of MOD_UNLOAD events >>>> >> >> is >>>> >> >> random >>>> >> >> and has no relation to the SI_* constants. :( >>>> >> >> >>>> >> >> What is happening here is that one of the 'bar' modules in >>>> >> >> libiconv.ko >>>> >> >> is >>>> >> >> getting unloaded after 'foo' gets unloaded and using a destroyed >>>> >> >> lock >>>> > (you >>>> >> >> >>>> >> >> get a panic if you run with INVARIANTS). >>>> >> > >>>> >> > So this should now be fixed with this commit. If you could verify >>>> >> > that >>>> >> > iconv >>>> >> > works ok with the latest kern_module.c I would appreciate it. >>>> >> > >>>> >> > Author: jhb >>>> >> > Date: Fri Dec 5 16:47:30 2008 >>>> >> > New Revision: 185642 >>>> >> > URL: http://svn.freebsd.org/changeset/base/185642 >>>> >> > >>>> >> > Log: >>>> >> > When the SYSINIT() to load a module invokes the MOD_LOAD event >>>> >> > successfully, >>>> >> > move that module to the head of the associated linker file's list >>>> >> > of >>>> >> > modules. >>>> >> > The end result is that once all the modules are loaded, they are >>>> >> > sorted >>>> > in >>>> >> > the reverse of their load order. This causes the kernel linker >>>> >> > to >>>> > invoke >>>> >> > the MOD_QUIESCE and MOD_UNLOAD events in the reverse of the order >>> that >>>> >> > MOD_LOAD was invoked. This means that the ordering of MOD_LOAD >>> events >>>> >> > that >>>> >> > is set by the SI_* paramters to DECLARE_MODULE() are now honored >>>> >> > in >>>> >> > the >>>> >> > same >>>> >> > order they would be for SYSUNINIT() for the MOD_QUIESCE and >>> MOD_UNLOAD >>>> >> > events. >>>> >> > >>>> >> > MFC after: 1 month >>>> >> > >>>> >> > -- >>>> >> > John Baldwin >>>> >> > >>>> >> >>>> >> Yes it works, I tried hard multiple times kldload/kldunload >>>> >> {libiconv,cd9660,cd9660_iconv in various order} to livelock/panic it, >>>> >> but without success. >>>> >> >>>> >> FYI following LORs happened: >>>> >> >>>> >> lock order reversal: >>>> >> 1st 0xc4322ce8 isofs (isofs) @ /usr/src/sys/kern/vfs_lookup.c:442 >>>> >> 2nd 0xd7d8d740 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:2443 >>>> >> 3rd 0xc4322bdc isofs (isofs) @ >>>> >> /usr/src/sys/modules/cd9660/../../fs/cd9660/cd9660_vfsops.c:694 >>>> > >>>> > This LOR should be addressed in the latest cd9660 locking patches. >>>> > >>>> > -- >>>> > John Baldwin >>>> > >>>> >>>> Oh, why I did not checked new version? >>>> >>>> Yes that LOR have gone, but when doing "ll -R" first time on /mnt >>>> I got following messages from kernel: >>>> >>>> RRIP without PX field? x ~ 50 times. >>>> >>>> I see you changed LK_EXCLUSIVE to flags, and with MPSAFE .... >>> >>> The RRIP stuff is all done in cd9660_vget_internal() under an exclusive >>> lock. >>> It could be a property of the ISO image. "PX" holds permissions (owner, >>> etc.). Do you get the same messages w/o the patch with the same ISO >>> image >>> / >>> CD? >>> >>> -- >>> John Baldwin >>> >> >> No I do not, but I may try other CDs I have many of them, including >> FreeBSD FreeBSD snapshot CD have same "issue". It doesnt appear always (I mean I do not count vfs cache) maybe disabling SMP and PREEMPTION will silent it. > s/Yes I do. Its to late here ... > >> one. >> If it is irrelevant than it should not be displayed. -- Paul From owner-freebsd-current@FreeBSD.ORG Wed Dec 10 00:28:16 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 05B88106564A for ; Wed, 10 Dec 2008 00:28:16 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.28]) by mx1.freebsd.org (Postfix) with ESMTP id A48698FC19 for ; Wed, 10 Dec 2008 00:28:15 +0000 (UTC) (envelope-from onemda@gmail.com) Received: by yw-out-2324.google.com with SMTP id 9so124126ywe.13 for ; Tue, 09 Dec 2008 16:28:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=R+kNkuH5htocDA/gxxSBzyF+37OCF1UQFttqRTnrkUo=; b=IZEcJyqwUhy6v7KWyPbtXfSXt7zwrlU1kAQgzTbjwns0JG2wQOO5bqqnsM3UGENfNg sBOaVLBRb8gL12HvgN/OwMX6CKfG0OTO65YNzNzQ6Vku2Hch/6XNd9u0oD4f4epfZEV2 4rWJrcvYOqDsfOwmQKLIR6AlwGhvhdBu7rPwY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=Dw9LiVNg9EHVh46m3KrFhzEKq2r8A7ykeV4gSOI5q5NCKAZPpYB67F8rWARZ9ORPX/ AOg729aXwyEs0yNCUhQnQ/iyAnRi8HoqAae/D/Ha9YGz5syvla5QE3+EARqEbCd/e6XR mFDFRDOuGt4EKPeOuAlJMzY9D/w13dpMZRVko= Received: by 10.231.19.204 with SMTP id c12mr14246ibb.20.1228868894233; Tue, 09 Dec 2008 16:28:14 -0800 (PST) Received: by 10.231.15.194 with HTTP; Tue, 9 Dec 2008 16:28:14 -0800 (PST) Message-ID: <3a142e750812091628l69034673sa2e11e71ba0bdad4@mail.gmail.com> Date: Wed, 10 Dec 2008 01:28:14 +0100 From: "Paul B. Mahol" To: "John Baldwin" In-Reply-To: <3a142e750812091516n6bb0880ewb298314e9ba296c@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200811191510.53793.jhb@FreeBSD.org> <200812051608.50120.jhb@freebsd.org> <3a142e750812051354n747bcbcayb31d8d5f4cc15098@mail.gmail.com> <200812091602.10850.jhb@freebsd.org> <3a142e750812091515u3f2e5807j3652f2cc3551a3b2@mail.gmail.com> <3a142e750812091516n6bb0880ewb298314e9ba296c@mail.gmail.com> Cc: freebsd-current@freebsd.org Subject: Re: [PATCH] MPSAFE/LOOKUP_SHARED cd9660 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Dec 2008 00:28:16 -0000 On 12/10/08, Paul B. Mahol wrote: > On 12/10/08, Paul B. Mahol wrote: >> On 12/9/08, John Baldwin wrote: >>> On Friday 05 December 2008 04:54:23 pm Paul B. Mahol wrote: >>>> On 12/5/08, John Baldwin wrote: >>>> > On Friday 05 December 2008 03:56:31 pm Paul B. Mahol wrote: >>>> >> On 12/5/08, John Baldwin wrote: >>>> >> > On Thursday 20 November 2008 05:47:28 pm John Baldwin wrote: >>>> >> >> On Thursday 20 November 2008 04:30:57 pm Paul B. Mahol wrote: >>>> >> >> > On 11/19/08, John Baldwin wrote: >>>> >> >> > > This is a relatively simple patch to mark cd9660 MPSAFE and >>>> >> >> > > enable >>>> >> > shared >>>> >> >> > > lookups. The changes to cd9660_lookup() mirror similar >>>> >> >> > > changes >>>> >> >> > > to >>>> >> >> > > ufs_lookup() to use static variables for local data rather >>>> >> >> > > than >>>> >> >> > > abusing >>>> >> >> > > i-node members of the parent directory. I've done some light >>>> >> >> > > testing >>>> >> >> > > of >>>> >> >> > > this, but not super-strenuous. This patch also includes >>>> >> >> > > simple >>>> >> >> > > locking >>>> >> >> for >>>> >> >> > > the iconv support in the kernel. That locking uses an sx lock >>>> >> >> > > to >>>> >> >> serialize >>>> >> >> > > open and close of translator tables and the associated >>>> >> >> > > refcount. >>>> >> >> > > Actual >>>> >> >> > > conversions do not need any locks, however as the mount holds >>>> >> >> > > a >>>> >> > reference >>>> >> >> on >>>> >> >> > > the table. >>>> >> >> > > >>>> >> >> > > http://www.FreeBSD.org/~jhb/patches/cd9660_mpsafe.patch >>>> >> >> > > >>>> >> >> > >>>> >> >> > With this patch I'm unable to kldunload libiconv.ko once it is >>>> >> >> > loaded. >>>> >> >> > And trying to kldunload libiconv.ko will make any next >>>> >> >> kldload/kldstat/kldunload >>>> >> >> > to fail waiting forever(livelock). >>>> >> >> > >>>> >> >> > Regression were not encountered while only cd9660.ko were >>>> >> >> > kldloaded. >>>> >> >> >>>> >> >> So this is actually due to a bug in the module code. If you have >>>> >> >> two >>>> >> > modules >>>> >> >> like this: >>>> >> >> >>>> >> >> DECLARE_MODULE(foo, SI_SUB_DRIVERS, SI_ORDER_FIRST); >>>> >> >> DECLARE_MODULE(bar, SI_SUB_DRIVERS, SI_ORDER_SECOND); >>>> >> >> >>>> >> >> The SI_* constants ensure that foo's module handler is called >>>> >> >> before >>>> > bar's >>>> >> >> >>>> >> >> module handler for MOD_LOAD. However, we don't enforce a reverse >>> order >>>> >> >> (bar >>>> >> >> then foo) for MOD_UNLOAD. In fact, the order of MOD_UNLOAD events >>>> >> >> is >>>> >> >> random >>>> >> >> and has no relation to the SI_* constants. :( >>>> >> >> >>>> >> >> What is happening here is that one of the 'bar' modules in >>>> >> >> libiconv.ko >>>> >> >> is >>>> >> >> getting unloaded after 'foo' gets unloaded and using a destroyed >>>> >> >> lock >>>> > (you >>>> >> >> >>>> >> >> get a panic if you run with INVARIANTS). >>>> >> > >>>> >> > So this should now be fixed with this commit. If you could verify >>>> >> > that >>>> >> > iconv >>>> >> > works ok with the latest kern_module.c I would appreciate it. >>>> >> > >>>> >> > Author: jhb >>>> >> > Date: Fri Dec 5 16:47:30 2008 >>>> >> > New Revision: 185642 >>>> >> > URL: http://svn.freebsd.org/changeset/base/185642 >>>> >> > >>>> >> > Log: >>>> >> > When the SYSINIT() to load a module invokes the MOD_LOAD event >>>> >> > successfully, >>>> >> > move that module to the head of the associated linker file's list >>>> >> > of >>>> >> > modules. >>>> >> > The end result is that once all the modules are loaded, they are >>>> >> > sorted >>>> > in >>>> >> > the reverse of their load order. This causes the kernel linker >>>> >> > to >>>> > invoke >>>> >> > the MOD_QUIESCE and MOD_UNLOAD events in the reverse of the order >>> that >>>> >> > MOD_LOAD was invoked. This means that the ordering of MOD_LOAD >>> events >>>> >> > that >>>> >> > is set by the SI_* paramters to DECLARE_MODULE() are now honored >>>> >> > in >>>> >> > the >>>> >> > same >>>> >> > order they would be for SYSUNINIT() for the MOD_QUIESCE and >>> MOD_UNLOAD >>>> >> > events. >>>> >> > >>>> >> > MFC after: 1 month >>>> >> > >>>> >> > -- >>>> >> > John Baldwin >>>> >> > >>>> >> >>>> >> Yes it works, I tried hard multiple times kldload/kldunload >>>> >> {libiconv,cd9660,cd9660_iconv in various order} to livelock/panic it, >>>> >> but without success. >>>> >> >>>> >> FYI following LORs happened: >>>> >> >>>> >> lock order reversal: >>>> >> 1st 0xc4322ce8 isofs (isofs) @ /usr/src/sys/kern/vfs_lookup.c:442 >>>> >> 2nd 0xd7d8d740 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:2443 >>>> >> 3rd 0xc4322bdc isofs (isofs) @ >>>> >> /usr/src/sys/modules/cd9660/../../fs/cd9660/cd9660_vfsops.c:694 >>>> > >>>> > This LOR should be addressed in the latest cd9660 locking patches. >>>> > >>>> > -- >>>> > John Baldwin >>>> > >>>> >>>> Oh, why I did not checked new version? >>>> >>>> Yes that LOR have gone, but when doing "ll -R" first time on /mnt >>>> I got following messages from kernel: >>>> >>>> RRIP without PX field? x ~ 50 times. >>>> >>>> I see you changed LK_EXCLUSIVE to flags, and with MPSAFE .... >>> >>> The RRIP stuff is all done in cd9660_vget_internal() under an exclusive >>> lock. >>> It could be a property of the ISO image. "PX" holds permissions (owner, >>> etc.). Do you get the same messages w/o the patch with the same ISO >>> image >>> / >>> CD? >>> >>> -- >>> John Baldwin >>> >> >> No I do not, but I may try other CDs I have many of them, including >> FreeBSD > s/Yes I do. Its to late here ... Ignore that reply. cd9660.ko without patch doesnt have this issue. cd9660.ko with cd9660_mpsafe.patch have this issue, on every CD I tried. -- Paul From owner-freebsd-current@FreeBSD.ORG Wed Dec 10 00:38:43 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 901B51065672 for ; Wed, 10 Dec 2008 00:38:43 +0000 (UTC) (envelope-from jackie@boolome.com) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.190]) by mx1.freebsd.org (Postfix) with ESMTP id 333988FC1B for ; Wed, 10 Dec 2008 00:38:43 +0000 (UTC) (envelope-from jackie@boolome.com) Received: by ti-out-0910.google.com with SMTP id a1so81748tib.3 for ; Tue, 09 Dec 2008 16:38:42 -0800 (PST) Received: by 10.110.69.5 with SMTP id r5mr952650tia.36.1228869522049; Tue, 09 Dec 2008 16:38:42 -0800 (PST) Received: from ?192.168.1.100? ([221.1.79.7]) by mx.google.com with ESMTPS id i6sm1493870tid.5.2008.12.09.16.38.39 (version=SSLv3 cipher=RC4-MD5); Tue, 09 Dec 2008 16:38:40 -0800 (PST) From: boolome To: Garrett Cooper In-Reply-To: <53DC39AE-EE1E-41DE-801D-45737249D93B@gmail.com> References: <1228555830.1186.6.camel@www.boolome.cn> <7d6fde3d0812080155y22cc7c0bne1fa0094671355e4@mail.gmail.com> <1228787330.13158.0.camel@www.boolome.cn> <53DC39AE-EE1E-41DE-801D-45737249D93B@gmail.com> Content-Type: text/plain; charset=utf-8 Organization: boolome Date: Wed, 10 Dec 2008 08:38:26 +0800 Message-Id: <1228869506.1255.3.camel@www.boolome.cn> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 8bit Cc: freebsd-current@freebsd.org Subject: Re: make buildworld failed! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Dec 2008 00:38:43 -0000 在 2008-12-09二的 03:18 -0800，Garrett Cooper写道： > On Dec 8, 2008, at 5:48 PM, boolome wrote: > > > 在 2008-12-08一的 01:55 -0800，Garrett Cooper写道： > >> On Sat, Dec 6, 2008 at 1:30 AM, boolome wrote: > >> [snip] > >> > >> Looks like your source tree is incomplete. > >> -Garrett > > > > But have cvsup the latest source tree ! > > It's not necessarily your fault though. What cvsup server are you > using and did you interrupt it during an update? > -Garrett The cvsup server is cvsup.freebsd.org . During an update ,I did not interrupt it. But when I got to that dir executed :make obj && make depend && make ,successed.. Is the soure tree's problem ? By the way I 'am using a custom kernel . From owner-freebsd-current@FreeBSD.ORG Wed Dec 10 06:11:56 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3DCBF1065670 for ; Wed, 10 Dec 2008 06:11:56 +0000 (UTC) (envelope-from mike@jellydonut.org) Received: from mail-bw0-f14.google.com (mail-bw0-f14.google.com [209.85.218.14]) by mx1.freebsd.org (Postfix) with ESMTP id 7759D8FC08 for ; Wed, 10 Dec 2008 06:11:55 +0000 (UTC) (envelope-from mike@jellydonut.org) Received: by bwz7 with SMTP id 7so303662bwz.19 for ; Tue, 09 Dec 2008 22:11:53 -0800 (PST) Received: by 10.181.142.13 with SMTP id u13mr334588bkn.8.1228888198810; Tue, 09 Dec 2008 21:49:58 -0800 (PST) Received: by 10.181.240.8 with HTTP; Tue, 9 Dec 2008 21:49:58 -0800 (PST) Message-ID: <1de79840812092149t4d212027o2c908635419fa838@mail.gmail.com> Date: Wed, 10 Dec 2008 00:49:58 -0500 From: "Michael Proto" To: "FreeBSD Current" , freebsd-questions@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: behavioral change of "read" builtin for sh on 8-CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Dec 2008 06:11:56 -0000 I've noticed a behavioral difference of the "read" builtin statement within /bin/sh on CURRENT and I'm hoping someone can point me in the right direction on how to restore the old behavior. I have a /bin/sh script that accepts input for IP address information: #!/bin/sh set -x DEFINT=vr0 DEFIP=192.168.0.1 DEFMASK=255.255.255.0 read -p "Enter network interface [$DEFINT]: " -t 5 INT read -p "Enter IP address [$DEFIP]: " -t 5 IP read -p "Enter netmask [$DEFMASK]: " -t 5 MASK echo ${INT:=$DEFINT} : ${IP:=$DEFIP}/${MASK:=$DEFMASK} This script waits for terminal input for each of the above variables (INT, IP, MASK) and defaults to a script-provided value if no input is entered in 5 seconds for each variable. On 6.x and 7.x if I simply hit Enter at the prompt (and don't provide any input) no value is assigned to the variable so my INT, IP, and MASK variables are set to null and the parameter substitution of the DEF* variables works as expected. On 8-CURRENT if I hit Enter with no input at the prompt the system seems to recognize the newline as input and continues to sit there until I hit Enter again. When I do this there appears to be a strange unprintable value assigned to the INT, IP, and MASK variables yet the variable subsitution doesn't work correctly. The man page on sh lists the following behavior for read: read [-p prompt] [-t timeout] [-er] variable ... The prompt is printed if the -p option is specified and the stan- dard input is a terminal. Then a line is read from the standard input. The trailing newline is deleted from the line and the line is split as described in the section on White Space Splitting (Field Splitting) above, and the pieces are assigned to the variables in order. If there are more pieces than variables, the remaining pieces (along with the characters in IFS that sepa- rated them) are assigned to the last variable. If there are more variables than pieces, the remaining variables are assigned the null string. As I interpret this, read should delete the trailing newline and assign a null value since there is is no "input" before the newline. Then the variable substitution should take over and assign the DEF* variables appropriately. 6 and 7 follow this but 8 does not. Here's the output of the script (with set -x) to help show what I'm seeing. This is on 6 and 7: + DEFINT=vr0 + DEFIP=192.168.0.1 + DEFMASK=255.255.255.0 + read -p Enter network interface [vr0]: -t 5 INT Enter network interface [vr0]: + read -p Enter IP address [192.168.0.1]: -t 5 IP Enter IP address [192.168.0.1]: + read -p Enter netmask [255.255.255.0]: -t 5 MASK Enter netmask [255.255.255.0]: + echo vr0 : 192.168.0.1/255.255.255.0 vr0 : 192.168.0.1/255.255.255.0 And this is what I see with 8: + DEFINT=vr0 + DEFIP=192.168.0.1 + DEFMASK=255.255.255.0 + read -p Enter network interface [vr0]: -t 5 INT Enter network interface [vr0]: + read -p Enter IP address [192.168.0.1]: -t 5 IP Enter IP address [192.168.0.1]: + read -p Enter netmask [255.255.255.0]: -t 5 MASK Enter netmask [255.255.255.0]: /: cho /: Strange that the "echo" statement is missing the first "e" character in the debug output. Even stranger on 8-CURRENT, if I *do* enter input before the newline (say I change the IP address or the network interface), the first character is not echoed back to the screen but is still saved to the variable. Here's an example when I run the script and provide input at each prompt: + DEFINT=vr0 + DEFIP=192.168.0.1 + DEFMASK=255.255.255.0 + read -p Enter network interface [vr0]: -t 5 INT Enter network interface [vr0]: r0 + read -p Enter IP address [192.168.0.1]: -t 5 IP Enter IP address [192.168.0.1]: 92.168.0.1 + read -p Enter netmask [255.255.255.0]: -t 5 MASK Enter netmask [255.255.255.0]: 55.255.255.0 + echo br0 : 192.168.0.1/255.255.255.0 br0 : 192.168.0.1/255.255.255.0 + echo ifconfig br0 inet 192.168.0.1 netmask 255.255.255.0 Notice that when I'm prompted, the first character doesn't echo but is still saved in the variable. Does anyone else see this same behavior? Any ideas on how to reset it back to how it works in STABLE? I'm not doing anything special with IFS so I'm stumped on how to troubleshoot this. Thanks, Proto From owner-freebsd-current@FreeBSD.ORG Wed Dec 10 07:40:53 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0172F1065670; Wed, 10 Dec 2008 07:40:53 +0000 (UTC) (envelope-from qingli@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id E240E8FC17; Wed, 10 Dec 2008 07:40:52 +0000 (UTC) (envelope-from qingli@FreeBSD.org) Received: from freefall.freebsd.org (qingli@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id mBA7eqHB034925; Wed, 10 Dec 2008 07:40:52 GMT (envelope-from qingli@freefall.freebsd.org) Received: (from qingli@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id mBA7eqjO034924; Wed, 10 Dec 2008 07:40:52 GMT (envelope-from qingli) Date: Wed, 10 Dec 2008 07:40:52 GMT From: Qing Li Message-Id: <200812100740.mBA7eqjO034924@freefall.freebsd.org> To: current@freebsd.org Cc: freebsd-net@freebsd.org Subject: last call for L2/L3 rewrite code review X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Dec 2008 07:40:53 -0000 As you know the L2+L3 rewrite project (aka arp-v2) for both ARP and ND6 has been active for quite some time now. In a nutshell, the work removes the L2 tables (ARP and ND6) from the L3 routing table. This redesign simplifies the routing code and completely eliminates the route cloning concept. I discussed about this work at BSDCan 2007 and again at the recent devsummit at Google. I have requested code review and feedback since last May. It's becoming increasingly difficult to maintain a separate branch (p4 or svn) due to the high volume of new features' related commits. The integration and unit testing efforts increase in complexity by the week. We (Julian, Sam, Kip, Robert and I) discussed about a possible commit timeframe during the devsummit. And it seems now is as good as any because we all have overcommitted ourselves, and frankly speaking unless the feature is fully committed, getting the thorough code review and broader testing is simply unrealistic. I have been running the new arp-v2 kernel as a regular production machine on a daily basis, however, I am certain my testing is insufficient, which is another good reason to get the feature into the official -current tree. Putting a closure on this work will allow me to focus on developing additional networking features and completing my other backlog tasks for the project. Although the code will continue to evolve, on the other hand, the code is stable enough that I believe it is ready for general (-CURRENT) consumption. I would like to commit the code within a week if not sooner. Again, I would like to ask for your review and feedback. Flaming is fine, which I prefer getting the flames now rather than later. Quite a few developers have contributed to this project in the past: Glebius Smirnoff, Luigi Rizzo, Alessandro Cerri, and Andre Oppermann. And most recently: - Kip Macy revised the locking code completely, thus completing the last piece of the puzzle, Kip has also been conducting active functional testing - Sam Leffler has helped me improving/refactoring the code, and provided valuable reviews - Julian Elischer setup the perforce tree for me and has helped me maintaining that branch The latest patch that is generated out of Perforce without Kip Macy's locking modification is at http://people.freebsd.org/~qingli/arp-v2-p4-diff The complete P4 project tree is located at //depot/projects/arp-v2 The full project sits in the svn branch that is located at svn+ssh://svn.freebsd.org/base/projects/arpv2_merge_1 Once this code is fully committed into -CURRENT, I will be on standby to fix any arp/nd6 related bugs. Kip Macy will be on standby to fix any locking related issues. Kip will also be acting as my backup when I'd be out partying. Thanks, -- Qing mailto: qingli@freebsd.org From owner-freebsd-current@FreeBSD.ORG Wed Dec 10 07:55:55 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7240B1065676 for ; Wed, 10 Dec 2008 07:55:55 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) Received: from 0.mx.codelabs.ru (0.mx.codelabs.ru [144.206.177.45]) by mx1.freebsd.org (Postfix) with ESMTP id 11E508FC17 for ; Wed, 10 Dec 2008 07:55:54 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=one; d=codelabs.ru; h=Received:Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:Content-Type:Content-Disposition:In-Reply-To:Sender; b=WPP3/1/iT75DUrm9wvOhqA0jr7HtkbHt/+KSSYb4Lpa+VXfLlZEl66trmOeab7F7dmsTzdGhKQ2pYzVIGrzmFtKBO9Qfy5rQgEfVQs9vb3DnnkXQVs9HJTIIYHzwisxWrzdcSc4mz8/MyZCCaPfP41AB+JkJkUBGimE7Vv8B9Wo=; Received: from void.codelabs.ru (void.codelabs.ru [144.206.177.25]) by 0.mx.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1LAJvE-0000LB-TG; Wed, 10 Dec 2008 10:55:52 +0300 Date: Wed, 10 Dec 2008 10:55:51 +0300 From: Eygene Ryabinkin To: Larry Rosenman Message-ID: References: <004901c95a1c$5c6b2680$15417380$@org> <493ECA0D.7090901@andric.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="+W7ryvxEk4RRyt+P" Content-Disposition: inline In-Reply-To: Sender: rea-fbsd@codelabs.ru Cc: Dimitry Andric , freebsd-current@freebsd.org, dougb@freebsd.org Subject: Re: Why does host and dig show a ; as \;? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Dec 2008 07:55:55 -0000 --+W7ryvxEk4RRyt+P Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Larry, good day. Tue, Dec 09, 2008 at 01:49:27PM -0600, Larry Rosenman wrote: > On Tue, 9 Dec 2008, Dimitry Andric wrote: > > On 2008-12-09 17:36, Larry Rosenman wrote: > >> Why does the host command, dig, and a named_db.dump all show a ; as \;= in a > >> TXT record? > > > > AFAICS the semicolon is a comment character in BIND software (at least > > in all config files and so on), and therefore it needs to be escaped. It doesn't need to be escaped inside strings themselves, at least there is no reason to have comments inside strings and BIND itself treats ';' inside strings as ordinary characters. But BIND's internal helper txt_totext does the escaping: ----- lib/dns/rdata.c /* double quote, semi-colon, backslash */ if (*sp =3D=3D 0x22 || *sp =3D=3D 0x3b || *sp =3D=3D 0x5c) { if (tl < 2) return (ISC_R_NOSPACE); *tp++ =3D '\\'; tl--; } ----- And BIND understands both escaped and unescaped semicolons inside strings in zone files -- it treats both of them in a same way. I don't have access to BIND's CVSWeb interface, so I can not trace the origin of semicolon escaping, but I feel that historically BIND treated semicolons inside strings as the plain symbols and this remained so to be backwards-compatible. And escaping in the BIND's output is the stricter form of string formatting. However, for example, our Russian TLD registrars are suggesting to avoid escapes inside strings if it is possible. Don't know why -- it is just a recipe without explanation. I am CC'ing Doug Barton, who maintains BIND for FreeBSD. Doug, is there any requirement for escaping the semicolons inside strings? I am failing to find it in http://www.ietf.org/rfc/rfc1035.txt: it talks about semicolons, but not about escaping and there seems to be no proper BNF notation for DNS zone files. Am I missing something? Thanks! --=20 Eygene _ ___ _.--. # \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard / ' ` , __.--' # to read the on-line manual =20 )/' _/ \ `-_, / # while single-stepping the kernel. `-'" `"\_ ,_.-;_.-\_ ', fsc/as # _.-'_./ {_.' ; / # -- FreeBSD Developers handbook=20 {_.-``-' {_/ # --+W7ryvxEk4RRyt+P Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkk/dgcACgkQthUKNsbL7YhboQCfcineiqkVrieRI0Mgg5OUCjXc ZGYAnjWmYAujZSBk7ZDj/qMzJV0t0OA9 =UPdy -----END PGP SIGNATURE----- --+W7ryvxEk4RRyt+P-- From owner-freebsd-current@FreeBSD.ORG Wed Dec 10 08:29:01 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B4BAB106567E; Wed, 10 Dec 2008 08:29:01 +0000 (UTC) (envelope-from dfr@rabson.org) Received: from itchy.rabson.org (unknown [IPv6:2002:50b1:e8f2:1::143]) by mx1.freebsd.org (Postfix) with ESMTP id 2D6538FC1A; Wed, 10 Dec 2008 08:29:01 +0000 (UTC) (envelope-from dfr@rabson.org) Received: from [IPv6:2001:470:909f:1:21b:63ff:feb8:5abc] (unknown [IPv6:2001:470:909f:1:21b:63ff:feb8:5abc]) by itchy.rabson.org (Postfix) with ESMTP id 712753FAA; Wed, 10 Dec 2008 08:28:59 +0000 (GMT) Message-Id: From: Doug Rabson To: "Paul Wootton" In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Date: Wed, 10 Dec 2008 08:28:59 +0000 References: <200812070319.18461.ken@mthelicon.com><66BF33BA-EC11-446F-9DE7-15395F293FE2@rabson.org> <200812071217.20500.ken@mthelicon.com> X-Mailer: Apple Mail (2.929.2) Cc: 'Joao Barros' , hackers@freebsd.org, current@freebsd.org, 'Pegasus Mc Cleaft' Subject: Re: Problems with zfsboot loader if raidz present on any drive X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Dec 2008 08:29:01 -0000 On 9 Dec 2008, at 23:54, Paul Wootton wrote: >> -----Original Message----- >> From: owner-freebsd-hackers@freebsd.org >> [mailto:owner-freebsd-hackers@freebsd.org] On Behalf Of Pegasus Mc >> Cleaft >> Sent: 07 December 2008 12:17 >> To: Doug Rabson >> Cc: hackers@freebsd.org; current@freebsd.org >> Subject: Re: Problems with zfsboot loader if raidz present on any >> drive >> >> On Sunday 07 December 2008 09:22:16 Doug Rabson wrote: >> On 7 Dec 2008, at 03:19, Pegasus Mc Cleaft wrote: >>>> Hello Hackers, >>>> >>>> Recently and friend and I have been trying to get the new >>>> gptzfsboot working on our machines and ran into a interesting >>>> problem. >>>> >>>> Initially I was building the world without the environment >>>> variable LOADER_ZFS_SUPPORT=YES in the /etc/make.conf and this, of >>>> course, didnt work very well. Every time the machine booted, it >>>> would throw 2 lines after the pin-wheel and then reboot. I >>>> couldent read what the lines were it went so fast. >>>> >>>> My friend had a bit more luck and got his machine working OK with >>>> a single drive and later a mirror drive added. >>>> >>>> I added the environment variable and rebuilt everything and >>>> installed. This time, I could see the bios drives and a further 2 >>>> lines of ZFS something and a reboot... >>>> >>>> No matter what I tried, I couldent get the machine to boot up to >>>> a point where I could try and fix the problem, so I started >>>> pulling devices out and found the following: If there is a raidz >>>> pool on any drive (not necessarily the one that you are trying to >>>> boot from) the loader dies and reboots the machine. My friend, as >>>> an experiment created 3 gpt partitions (in addition to the single >>>> partition that he had been previously booted from) on his single >>>> drive and made a raidz pool for testing. His machine showed the >>>> same condition as mine, however he was able to capture the message >>>> before the machine >>>> rebooted: >>>> >>>> >>>> ZFS: can only boot from disk or mirror vdevs >>>> >>>> ZFS: inconsistent nvlist contents >>> >>> The zfsboot code in current doesn't support raidz or raidz2. I have >>> been working on adding that support but its not ready yet. The code >>> works in my test harness but crashes instantly when I put it in the >>> boot code :(. I should have time to finish debugging it soon. >> >> Hi Doug, >> >> In my haste to put a message to the group, I didnt do a very good > job >> of explaining or give what platform I was working with. >> >> I set up a single disk pool with the gptzfsboot code on it as a boot > drive. >> My idea was to have a single disk boot (and after it boots and I can >> kill the UFS drive I am currently booting from) convert it to a >> mirror. But I have 6 other drives in the machine that I have as a >> raidz > for my /usr/home, et al. >> >> If the 6 raidz drives are present at boot time, the machine starts > to >> cyclic reboot just after the pin-wheel. >> >> The machine I am working on is running FBSD8.0-Current as of > midnight >> 7/12/2008 and the platform is AMD64. >> >> If I can help test in any way I would be more than happy to try, or >> provide any information necessary.. >> >> ~Peg > > Hi Doug, > I was working with Peg on this over the weekend. > I think I have a patch for this - see > http://www.freebsd.org/cgi/query-pr.cgi?pr=129539 > The problem was that we were not checking the return code from > vdev_init_from_nvlist() on line 726 in /usr/src/sys/boot/zfs/zfsimpl.c > > > Joao, > Do you want to try the attached patch? It seems to have fixed the > problem, > at least on mine and Peg's machine. This looks like the right fix. I will commit something similar to this today. From owner-freebsd-current@FreeBSD.ORG Wed Dec 10 09:28:47 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F1DC31065673; Wed, 10 Dec 2008 09:28:47 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [62.111.66.27]) by mx1.freebsd.org (Postfix) with ESMTP id AA11A8FC0C; Wed, 10 Dec 2008 09:28:47 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from localhost (amavis.str.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id 3623C41C615; Wed, 10 Dec 2008 10:10:06 +0100 (CET) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([62.111.66.27]) by localhost (amavis.str.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id 52ZzB2rBQcmu; Wed, 10 Dec 2008 10:10:05 +0100 (CET) Received: by mail.cksoft.de (Postfix, from userid 66) id D762941C62F; Wed, 10 Dec 2008 10:10:05 +0100 (CET) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 0FF4D4448DD; Wed, 10 Dec 2008 09:09:59 +0000 (UTC) Date: Wed, 10 Dec 2008 09:09:59 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Qing Li In-Reply-To: <200812100740.mBA7eqjO034924@freefall.freebsd.org> Message-ID: <20081210090429.G97918@maildrop.int.zabbadoz.net> References: <200812100740.mBA7eqjO034924@freefall.freebsd.org> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org, FreeBSD current mailing list Subject: Re: last call for L2/L3 rewrite code review X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Dec 2008 09:28:48 -0000 On Wed, 10 Dec 2008, Qing Li wrote: Hi, > It's becoming increasingly difficult to maintain a separate > branch (p4 or svn) due to the high volume of new features' > related commits. The integration and unit testing efforts > increase in complexity by the week. [..] > I would like to commit the code within > a week if not sooner. I think waiting another few days would be good, so end of the weekend or something seems realistic, but not so before. The reason I am asking is that people are still seeing panics from the rnh locking and aren't even able to boot machines. Mixng route locking bugs with this rewrite will be painful. As I hope that the rnh bugs will be solved within 2-3 days things would be good for getting this monster in:) > The complete P4 project tree is located at > > //depot/projects/arp-v2 > > The full project sits in the svn branch that is located at > > svn+ssh://svn.freebsd.org/base/projects/arpv2_merge_1 Which of the two is the one to track the next days or are you going to keep them in sync? /bz -- Bjoern A. Zeeb The greatest risk is not taking one. From owner-freebsd-current@FreeBSD.ORG Wed Dec 10 09:30:36 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 21164106567B for ; Wed, 10 Dec 2008 09:30:36 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.234]) by mx1.freebsd.org (Postfix) with ESMTP id E3D008FC27 for ; Wed, 10 Dec 2008 09:30:35 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so321175rvf.43 for ; Wed, 10 Dec 2008 01:30:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=IQWAr2//dmZ7s4JNLSsg4MIAV1LfhLmqcaB/N0tApFU=; b=PwbjpLM0T1EpDIdU+jBis2zoRPKmo2wEgzzkIMeF5+68QqITreYbZRdcR1iZl5hCZk Xa8lpi4DcsDXF58eZu2zxZXMSOHFNiqUBC614AwEmmn0bwU0YL7S1/WXstvMpRkbfLwp SR12GYTZyllGSELM/Y2x3NYTQhlafUQQKYnrE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=qGrM6WjhuLLHoJJC27rzPNRzynj0+AmSKP2e5U/W3m0sSHcdDtivXIWtvyxp1HJs2l mOS1D8vQJj5AgyfO2oaLHe4XCMoKEHEXSnUVfevZjfv7dgHiikFzPGfsspHiE7Ixw07m 2QPvreZzh42dlRy7Gh2o9pFjpYCDslPQeR5DE= Received: by 10.140.158.4 with SMTP id g4mr557447rve.160.1228901435578; Wed, 10 Dec 2008 01:30:35 -0800 (PST) Received: by 10.141.142.3 with HTTP; Wed, 10 Dec 2008 01:30:35 -0800 (PST) Message-ID: <3c1674c90812100130y5433403akc68f72a5086b921c@mail.gmail.com> Date: Wed, 10 Dec 2008 01:30:35 -0800 From: "Kip Macy" Sender: mat.macy@gmail.com To: "Bjoern A. Zeeb" In-Reply-To: <20081210090429.G97918@maildrop.int.zabbadoz.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200812100740.mBA7eqjO034924@freefall.freebsd.org> <20081210090429.G97918@maildrop.int.zabbadoz.net> X-Google-Sender-Auth: 7b65664b5d1bd8ef Cc: Qing Li , FreeBSD current mailing list , freebsd-net@freebsd.org Subject: Re: last call for L2/L3 rewrite code review X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Dec 2008 09:30:36 -0000 > The reason I am asking is that people are still seeing panics from > the rnh locking and aren't even able to boot machines. I have not seen this. Please tell me where this occurs. > Mixng route > locking bugs with this rewrite will be painful. As I hope that the > rnh bugs will be solved within 2-3 days things would be good for > getting this monster in:) To the best of my knowledge, the few bugs that have occurred have been fixed within a day of them being reported. >> svn+ssh://svn.freebsd.org/base/projects/arpv2_merge_1 > > Which of the two is the one to track the next days or are you going to > keep them in sync? > The svn branch will be the one that is kept up to date with all fixes. I will be IFC'ing in to it once a day. Thanks, Kip From owner-freebsd-current@FreeBSD.ORG Wed Dec 10 09:53:52 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8648A1065672 for ; Wed, 10 Dec 2008 09:53:52 +0000 (UTC) (envelope-from james-freebsd-current@jrv.org) Received: from mail.jrv.org (adsl-70-243-84-13.dsl.austtx.swbell.net [70.243.84.13]) by mx1.freebsd.org (Postfix) with ESMTP id 38F7E8FC0C for ; Wed, 10 Dec 2008 09:53:52 +0000 (UTC) (envelope-from james-freebsd-current@jrv.org) Received: from kremvax.housenet.jrv (kremvax.housenet.jrv [192.168.3.124]) by mail.jrv.org (8.14.3/8.13.1) with ESMTP id mBA9Ebug053841 for ; Wed, 10 Dec 2008 03:14:37 -0600 (CST) (envelope-from james-freebsd-current@jrv.org) Authentication-Results: mail.jrv.org; domainkeys=pass (testing) header.from=james-freebsd-current@jrv.org DomainKey-Signature: a=rsa-sha1; s=enigma; d=jrv.org; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:subject: x-enigmail-version:content-type:content-transfer-encoding; b=r5sG7KlDHKc2+V2Sfq+eE2P15QrjTkIa0Yj0y3UiBnMaNYF9EqgJy07W7rLC6yxLv n/Tw6+dngwzt2NSBSHf+Bt2b1jgG18paCLKVCGzVrO/Ql5rySumpbq4Y6QA6NXH4TnK hH7achOY1QmBnsKe8p1XH4z1zh5nDWLWTFrC930= Message-ID: <493F887D.7000705@jrv.org> Date: Wed, 10 Dec 2008 03:14:37 -0600 From: "James R. Van Artsdalen" User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105) MIME-Version: 1.0 To: freebsd-current@freebsd.org X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Is FreeBSD -CURRENT sata port multiplier support functional yet? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Dec 2008 09:53:52 -0000 Is FreeBSD -CURRENT sata port multiplier support functional yet? I just tried the 8.0-CURRENT-200812-amd64-dvd1.iso snapshot on a Dell 435MT (Core i7) with a generic Silicon Image 3132 card (three different cards actually) and two Sans Digital eSATA enclosures that were tested to work OK with a Macintosh before & after the FreeBSD test. It appears the port multiplier is detected but that FreeBSD is not able to probe the disks behind the port multiplier. ata2 below has the port multiplier enclosure attached. There are disks in the 0 and 1 slots in the enclosure. The disk in slot 0 is detected by the 3132 option ROM. The enclosure and all slots work fine on a Macintosh with the Silicon Image drivers. The boot disk on ata4 is on an Intel chip. atapci0: port 0xcc00-0xcc7f mem 0xfbcffc00-0xfbcffc7f,0xfbcf8000-0xfbcfbfff irq 16 at device 0.0 on pci2 atapci0: Reserved 0x80 bytes for rid 0x20 type 4 at 0xcc00 atapci0: [MPSAFE] atapci0: [ITHREAD] atapci0: Reserved 0x80 bytes for rid 0x10 type 3 at 0xfbcffc00 atapci0: Reserved 0x4000 bytes for rid 0x18 type 3 at 0xfbcf8000 ata2: on atapci0 ata2: channel HW reset timeout ata2: SATA connect status=00000000 ata2: phy reset found no device ata2: [MPSAFE] ata2: [ITHREAD] ata3: on atapci0 ata3: channel HW reset timeout ata3: SATA connect status=00000000 ata3: phy reset found no device ata3: [MPSAFE] ata3: [ITHREAD] ... ata2: identify ch->devices=00000000 ata3: identify ch->devices=00000000 ata4: identify ch->devices=00000001 firewire0: 1 nodes, maxhop <= 0, cable IRM = 0 (me) firewire0: bus manager 0 (me) ata2: CONNECT requested ata4-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire ad8: 476940MB at ata4-master SATA300 ad8: 976773168 sectors [969021C/16H/63S] 16 sectors/interrupt 1 depth queue GEOM: new disk ad8 spa_config_load:92[1]: Cannot open /boot/zfs/zpool.cache. ZFS filesystem version 13 zvol_init:1167[1]: ZVOL Initialized. ZFS storage pool version 13 ata2: CONNECTED ata2: channel HW reset time=0ms ata2: SATA connect time=0ms ata2: siiprb_issue_cmd time=530ms status=00050000 ata2: SIGNATURE=96690101 ata2: siiprb_issue_cmd time=0ms status=00010000 ata2: siiprb_issue_cmd time=0ms status=00010000 ata2: siiprb_issue_cmd time=0ms status=00010000 ata2: SiI 3726 r1706 Portmultiplier with 5 ports ata2: siiprb_issue_cmd time=0ms status=00010000 ata2: siiprb_issue_cmd time=0ms status=00010000 ata2: siiprb_issue_cmd time=0ms status=00010000 ata2: p0: connect time 0ms ata2: siiprb_issue_cmd time=0ms status=00010000 ata2: p0: SIGNATURE=ffffffff ata2: error writing PM port ata2: p1: writing ATA_SC_DET_RESET failed ata2: error writing PM port ata2: p2: writing ATA_SC_DET_RESET failed ata2: error writing PM port ata2: p3: writing ATA_SC_DET_RESET failed ata2: error writing PM port ata2: p4: writing ATA_SC_DET_RESET failed ata2: siiprb_reset devices=00008000 ata2: identify ch->devices=00008000 (probe0:sbp0:0:0:0): error 22 (probe0:sbp0:0:0:0): Unretryable Error (probe1:sbp0:0:1:0): error 22 (probe1:sbp0:0:1:0): Unretryable Error (probe2:sbp0:0:2:0): error 22 (probe2:sbp0:0:2:0): Unretryable Error (probe3:sbp0:0:3:0): error 22 (probe3:sbp0:0:3:0): Unretryable Error (probe4:sbp0:0:4:0): error 22 (probe4:sbp0:0:4:0): Unretryable Error (probe5:sbp0:0:5:0): error 22 (probe5:sbp0:0:5:0): Unretryable Error (probe6:sbp0:0:6:0): error 22 (probe6:sbp0:0:6:0): Unretryable Error ad8: Intel check1 failed From owner-freebsd-current@FreeBSD.ORG Wed Dec 10 10:19:36 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 582BA1065678 for ; Wed, 10 Dec 2008 10:19:36 +0000 (UTC) (envelope-from elias@artx.ru) Received: from round.artx.ru (round.artx.ru [80.73.175.73]) by mx1.freebsd.org (Postfix) with ESMTP id C80518FC1A for ; Wed, 10 Dec 2008 10:19:35 +0000 (UTC) (envelope-from elias@artx.ru) Received: by round.artx.ru (Postfix, from userid 1001) id C733A5C27; Wed, 10 Dec 2008 13:19:33 +0300 (MSK) Date: Wed, 10 Dec 2008 13:19:33 +0300 From: Ilya Orehov To: "M. Warner Losh" Message-ID: <20081210101933.GA19248@artx.ru> References: <20081209192439.GA16703@artx.ru> <20081209.124743.-201314317.imp@bsdimp.com> <20081209204404.GA17018@artx.ru> <20081209.141616.2139790010.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20081209.141616.2139790010.imp@bsdimp.com> User-Agent: Mutt/1.4.2.3i Cc: current@freebsd.org Subject: Re: "interrupt storm..."; seems associated with an0 NIC X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Dec 2008 10:19:36 -0000 +------- M. Warner Losh, 2008-12-09 ------- | Thanks! This helps a lot. The fact that xl works also is an | important hint for me for another problem I'm chasing... | | does this patch cause the printfs we've added to not be hit? With patch printf still hit, but in different places, and mask is different now: 6 during startup (later then without patch), and 0 or 6 after card insertion. Tried (insert/eject) several times, sequence hardly repeatable, but maybe it depends on timings : if card inserted quickly after eject, mask=0. That puzzled me, so I went to single user. In single user, if rebooted without card: card inserted -> no message, card ejected -> "Need to ack 0x1, mask=00000006" In single user too: card inserted -> no message, IP set with ifconfig xl0 -> "Need to ack 0x1, mask=00000006" card ejected -> no message Then i reverted patch to check in single user: Reboot without card, single user. Card inserted -> "Need to ack 0x1, mask=00000001" IP set with ifconfig -> no message card ejected -> no message Reboot with card, Card initialized -> "Need to ack 0x1, mask=00000007" regards, Ilya. | | Warner | | Index: pccbb.c | =================================================================== | --- pccbb.c (revision 185750) | +++ pccbb.c (working copy) | @@ -514,7 +514,7 @@ | * a chance to run. | */ | mtx_lock(&sc->mtx); | - cbb_setb(sc, CBB_SOCKET_MASK, CBB_SOCKET_MASK_CD | CBB_SOCKET_MASK_CSTS); | + cbb_setb(sc, CBB_SOCKET_MASK, CBB_SOCKET_MASK_CD); | msleep(&sc->intrhand, &sc->mtx, 0, "-", 0); | err = 0; | while (err != EWOULDBLOCK && | | | In message: <20081209204404.GA17018@artx.ru> | Ilya Orehov writes: | : +------- M. Warner Losh, 2008-12-09 ------- | : | In message: <20081209192439.GA16703@artx.ru> | : | Ilya Orehov writes: | : | : Need to ack 0x1 | : | | : | What happens if you also print the current mask register? CBB_SOCKET_MASK? | : | : Rebooted with xl0 card inserted, | : first time (after initialization) mask=7, | : after eject/insert xl0 mask=1. | : | : ... | : xl0: Ethernet address: 00:60:08:d2:38:56 | : xl0: [ITHREAD] | : Need to ack 0x1, mask=00000007 | : acd0: CDROM at ata1-master PIO4 | : Trying to mount root from ufs:/dev/ad0s2a | : WARNING: attempt to net_add_domain(bluetooth) after domainfinalize() | : xl0: reset didn't complete | : xl0: command never completed! | : xl0: command never completed! | : xl0: command never completed! | : tdkphy0: detached | : miibus0: detached | : xl0: detached | : Need to ack 0x1, mask=00000001 | : xl0: <3Com 3c575TX Fast Etherlink XL> port 0x1000-0x103f irq 11 at device 0.0 on cardbus1 | : miibus0: on xl0 | : ... | : | : Rebooted once more, without card. | : After card (xl0) inserted, mask=1. | : | : Rebooted with same card inserted in second slot. | : First time (after initialization) mask=7, | : after eject/insert into same slot xl0 mask=1, | : after eject card was inserted into first slot, mask=1, | : | : code was: | : if (!ack) { | : mask = cbb_get(sc, CBB_SOCKET_MASK); | : printf("Need to ack %#x, mask=%08x\n", sockevent, mask); | : cbb_set(sc, CBB_SOCKET_EVENT, sockevent); | : } | : | : regards, | : Ilya. | : | : | : | | : | Warner | : | | : +----------------------------- | : | : | +----------------------------- From owner-freebsd-current@FreeBSD.ORG Wed Dec 10 10:21:20 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C1B081065670; Wed, 10 Dec 2008 10:21:20 +0000 (UTC) (envelope-from zec@icir.org) Received: from labs4.cc.fer.hr (labs4.cc.fer.hr [161.53.72.24]) by mx1.freebsd.org (Postfix) with ESMTP id 4EFB58FC1C; Wed, 10 Dec 2008 10:21:20 +0000 (UTC) (envelope-from zec@icir.org) Received: from sluga.fer.hr (sluga.cc.fer.hr [161.53.72.14]) by labs4.cc.fer.hr (8.14.2/8.14.2) with ESMTP id mBAA9sgo021825; Wed, 10 Dec 2008 11:09:54 +0100 (CET) Received: from [192.168.200.110] ([161.53.19.79]) by sluga.fer.hr with Microsoft SMTPSVC(6.0.3790.3959); Wed, 10 Dec 2008 11:09:21 +0100 From: Marko Zec To: freebsd-net@freebsd.org Date: Wed, 10 Dec 2008 11:09:14 +0100 User-Agent: KMail/1.9.7 References: <200812100740.mBA7eqjO034924@freefall.freebsd.org> <20081210090429.G97918@maildrop.int.zabbadoz.net> <3c1674c90812100130y5433403akc68f72a5086b921c@mail.gmail.com> In-Reply-To: <3c1674c90812100130y5433403akc68f72a5086b921c@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200812101109.14851.zec@icir.org> X-OriginalArrivalTime: 10 Dec 2008 10:09:21.0300 (UTC) FILETIME=[5ECC6540:01C95AAF] X-Scanned-By: MIMEDefang 2.64 on 161.53.72.24 Cc: FreeBSD current mailing list , "Bjoern A. Zeeb" , Kip Macy , Qing Li Subject: Re: last call for L2/L3 rewrite code review X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Dec 2008 10:21:20 -0000 On Wednesday 10 December 2008 10:30:35 Kip Macy wrote: > > The reason I am asking is that people are still seeing panics from > > the rnh locking and aren't even able to boot machines. > > I have not seen this. Please tell me where this occurs. I had a machine with defaultrouter from /etc/rc.conf pointing to a gateway which wasn't directly reachable, so the machine would panic before going multiuser. Nevertheless I can confirm that your change 185849 just resolved this issue, thanks a lot for a quick fix! Marko > > Mixng route > > locking bugs with this rewrite will be painful. As I hope that the > > rnh bugs will be solved within 2-3 days things would be good for > > getting this monster in:) > > To the best of my knowledge, the few bugs that have occurred have > been fixed within a day of them being reported. > > >> svn+ssh://svn.freebsd.org/base/projects/arpv2_merge_1 > > > > Which of the two is the one to track the next days or are you going > > to keep them in sync? > > The svn branch will be the one that is kept up to date with all > fixes. I will be IFC'ing in to it once a day. > > Thanks, > Kip > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to > "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Wed Dec 10 10:44:32 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D3B1F1065678 for ; Wed, 10 Dec 2008 10:44:32 +0000 (UTC) (envelope-from sos@freebsd.org) Received: from deepcore.dk (adsl.deepcore.dk [87.63.29.106]) by mx1.freebsd.org (Postfix) with ESMTP id 60CA08FC1D for ; Wed, 10 Dec 2008 10:44:32 +0000 (UTC) (envelope-from sos@freebsd.org) Received: from [172.18.2.117] (axiell-gw1.novi.dk [77.243.61.137]) by deepcore.dk (8.14.3/8.14.2) with ESMTP id mBAAMbFe029959; Wed, 10 Dec 2008 11:22:37 +0100 (CET) (envelope-from sos@freebsd.org) Message-Id: <226981FE-F27C-4C5F-8112-90213E45E99A@freebsd.org> From: =?ISO-8859-1?Q?S=F8ren_Schmidt?= To: "James R. Van Artsdalen" In-Reply-To: <493F887D.7000705@jrv.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v929.2) Date: Wed, 10 Dec 2008 11:22:38 +0100 References: <493F887D.7000705@jrv.org> X-Mailer: Apple Mail (2.929.2) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (deepcore.dk [87.63.29.106]); Wed, 10 Dec 2008 11:22:38 +0100 (CET) Cc: freebsd-current@freebsd.org Subject: Re: Is FreeBSD -CURRENT sata port multiplier support functional yet? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Dec 2008 10:44:32 -0000 On 10Dec, 2008, at 10:14 , James R. Van Artsdalen wrote: > Is FreeBSD -CURRENT sata port multiplier support functional yet? > > I just tried the 8.0-CURRENT-200812-amd64-dvd1.iso snapshot on a Dell > 435MT (Core i7) with a generic Silicon Image 3132 card (three =20 > different > cards actually) and two Sans Digital eSATA enclosures that were tested > to work OK with a Macintosh before & after the FreeBSD test. > > It appears the port multiplier is detected but that FreeBSD is not =20 > able > to probe the disks behind the port multiplier. I works in some setups but not all, seems PM's even with the same ID =20 and revision are not created equal, so we still have the fine mess to =20= find out things as we did in the old days. I have a setup with SiI chips that works with one PM but fails on 2 =20 others, all three PM's use the same chip (ID and rev), go figure :) I'll get it fixed eventually, but spare time is sparse -S=F8ren= From owner-freebsd-current@FreeBSD.ORG Wed Dec 10 10:44:33 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E4A2A106564A for ; Wed, 10 Dec 2008 10:44:33 +0000 (UTC) (envelope-from sos@freebsd.org) Received: from deepcore.dk (adsl.deepcore.dk [87.63.29.106]) by mx1.freebsd.org (Postfix) with ESMTP id 6F6DB8FC16 for ; Wed, 10 Dec 2008 10:44:33 +0000 (UTC) (envelope-from sos@freebsd.org) Received: from [172.18.2.117] (axiell-gw1.novi.dk [77.243.61.137]) by deepcore.dk (8.14.3/8.14.2) with ESMTP id mBAAI5Hn029871; Wed, 10 Dec 2008 11:18:05 +0100 (CET) (envelope-from sos@freebsd.org) Message-Id: <237FB18B-DACD-45F9-85DF-E214A33FDE5F@freebsd.org> From: =?ISO-8859-1?Q?S=F8ren_Schmidt?= To: "Conrad J. Sabatier" In-Reply-To: <20081206190754.6c2bbd70@serene.no-ip.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v929.2) Date: Wed, 10 Dec 2008 11:18:05 +0100 References: <20081128234155.0221e263@serene.no-ip.org> <4930D7CE.4080909@psg.com> <20081202220643.72eb52a3@serene.no-ip.org> <20081203151537.GA1045@phenom.cordula.ws> <20081206190754.6c2bbd70@serene.no-ip.org> X-Mailer: Apple Mail (2.929.2) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (deepcore.dk [87.63.29.106]); Wed, 10 Dec 2008 11:18:06 +0100 (CET) Cc: freebsd-current@freebsd.org, cpghost Subject: Re: i give up X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Dec 2008 10:44:34 -0000 On 7Dec, 2008, at 2:07 , Conrad J. Sabatier wrote: > > As another poster suggested, it's possible there's a bug/typo in the > patches Soren sent me, although they all apply quite cleanly to every > successive version of current I've tried them on. So...I'm at a loss > at this point. It really is frustrating. > In fact it seems there is a typo in that patch, you need to use the =20 ATA_NFORCE_MCP77_A8 device ID instead of the ATA_NFORCE_MCP77_A1 in =20 the patch to match your HW. However, you should have been able to tell that pretty quickly by =20 looking at the ID's you sent back when and the patch ;) Anyhow there is just that much I can do in situations like this, I =20 only have limitted time and cannot possibly attend to all the problems =20= I get in my inbox in a timely manner, sorry. "life sucks - and then you die" -S=F8ren From owner-freebsd-current@FreeBSD.ORG Wed Dec 10 12:16:16 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1AA1C1065673 for ; Wed, 10 Dec 2008 12:16:16 +0000 (UTC) (envelope-from channa.kad@gmail.com) Received: from rn-out-0910.google.com (rn-out-0910.google.com [64.233.170.188]) by mx1.freebsd.org (Postfix) with ESMTP id CA48A8FC1C for ; Wed, 10 Dec 2008 12:16:15 +0000 (UTC) (envelope-from channa.kad@gmail.com) Received: by rn-out-0910.google.com with SMTP id j71so489498rne.12 for ; Wed, 10 Dec 2008 04:16:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:mime-version:content-type:content-transfer-encoding :content-disposition; bh=m9NmKMvAcQFJ20BmVwxqIhs+6u4W0Aeya1ojXOfJpU8=; b=p1mChxZUtSOgjb4VA/Z/9RuT4+P2C5fNTihSZ4ScLNJHGw8p5eP/GRWdFvleSVt16C q843G3+qPq3Y4qhBfYk3eeQ81Gvj3gCph18ktcZu/RABmcBX8/0CzsQnRADQ/7ua+Q4j qArI1vHARV7DvLpo8qFiLS0ug4PNaYUnl0rBM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:mime-version:content-type :content-transfer-encoding:content-disposition; b=Vht1N+3uTXzQh5n8SvhfCV243mM2l0Ah5iKoztkv4d46avAYrY3Hv0lSiZWrcIXzmk ArjhWTNbqJeoXkVUaN0NiJdBJxmEbC6VIenSBcHn0NWaKXdFKEDEVdeN+IpuzG9DMFwh P4pYbaAlNjp2wlDhENJIttKzhVN+mrJ1yeLBM= Received: by 10.64.250.7 with SMTP id x7mr1030593qbh.94.1228911374365; Wed, 10 Dec 2008 04:16:14 -0800 (PST) Received: by 10.64.156.4 with HTTP; Wed, 10 Dec 2008 04:16:14 -0800 (PST) Message-ID: <515c64960812100416x306eacbdic3872bc8bc2244b7@mail.gmail.com> Date: Wed, 10 Dec 2008 17:46:14 +0530 From: Channa To: "Jason Evans" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: freebsd-current@freebsd.org Subject: jtmalloc performance Vs ptmalloc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Dec 2008 12:16:16 -0000 Hi, I tried to execute the benchmark test malloc-test to compare the ptmalloc performance and jemalloc performance. jemalloc seems to performance better than ptmalloc under following conditions. - If memory requests are less than 3840Bytes jemalloc is faster than ptmalloc Jemalloc: # ./malloc-test 1024 10000000 5 Starting test with 5 threads... Thread -1086325424 adjusted timing: 0.893323 seconds for 10000000 requests of 1024 bytes. Thread -1090519728 adjusted timing: 0.893581 seconds for 10000000 requests of 1024 bytes. Thread -1082131120 adjusted timing: 0.983221 seconds for 10000000 requests of 1024 bytes. Thread -1088422576 adjusted timing: 1.346636 seconds for 10000000 requests of 1024 bytes. Thread -1084228272 adjusted timing: 1.394940 seconds for 10000000 requests of 1024 bytes. Ptmalloc: # ./malloc-test 1024 10000000 5 Starting test with 5 threads... Thread -1208353904 adjusted timing: 2.427992 seconds for 10000000 requests of 1024 bytes. Thread -1239823472 adjusted timing: 2.474918 seconds for 10000000 requests of 1024 bytes. Thread -1218843760 adjusted timing: 2.394854 seconds for 10000000 requests of 1024 bytes. Thread -1250313328 adjusted timing: 3.695654 seconds for 10000000 requests of 1024 bytes. Thread -1229333616 adjusted timing: 5.081604 seconds for 10000000 requests of 1024 bytes. - If memory requests are page aligned i.e large allocations jemalloc is slower than ptmalloc. jemalloc: # ./malloc-test 9300 10000000 5 Starting test with 5 threads... Thread -1077936816 adjusted timing: 4.648531 seconds for 10000000 requests of 9300 bytes. Thread -1086325424 adjusted timing: 4.837230 seconds for 10000000 requests of 9300 bytes. Thread -1080033968 adjusted timing: 4.978933 seconds for 10000000 requests of 9300 bytes. Thread -1084228272 adjusted timing: 7.029323 seconds for 10000000 requests of 9300 bytes. Thread -1082131120 adjusted timing: 7.075402 seconds for 10000000 requests of 9300 bytes. Ptmalloc: # ./malloc-test_glib 9300 10000000 5 Starting test with 5 threads... Thread -1229083760 adjusted timing: 2.860437 seconds for 10000000 requests of 9300 bytes. Thread -1250063472 adjusted timing: 3.254859 seconds for 10000000 requests of 9300 bytes. Thread -1218593904 adjusted timing: 4.334052 seconds for 10000000 requests of 9300 bytes. Thread -1208104048 adjusted timing: 4.139268 seconds for 10000000 requests of 9300 bytes. Thread -1239573616 adjusted timing: 5.396595 seconds for 10000000 requests of 9300 bytes. So jemalloc takes more time for Large allocations than ptmalloc. For Huge allocations freater than 1MB again jemalloc is faster than ptmalloc. i tested this on 4 CPU intel x86 machine. Could you please tell me if there is any method to increase the performance for Large allocations.? I tried to increase the bins by setting the PAGE_SHIFT to 13 that time the performance of jemalloc was better for allocations till 7936. As per my analysis using bins for all allocations less than 1MB reduces the time taken but which may not be correct. I am trying to modify the Large allocations to increase the performance, Could you suggest some ideas. Thanks in Advance, Channa From owner-freebsd-current@FreeBSD.ORG Wed Dec 10 12:56:28 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ADE8D106564A for ; Wed, 10 Dec 2008 12:56:28 +0000 (UTC) (envelope-from CQG00620@nifty.ne.jp) Received: from mail.asahi-net.or.jp (mail2.asahi-net.or.jp [202.224.39.198]) by mx1.freebsd.org (Postfix) with ESMTP id 83F4F8FC12 for ; Wed, 10 Dec 2008 12:56:28 +0000 (UTC) (envelope-from CQG00620@nifty.ne.jp) Received: from asahi-net.jp (l207029.dynamic.ppp.asahi-net.or.jp [218.219.207.29]) by mail.asahi-net.or.jp (Postfix) with ESMTP id 25732615CD for ; Wed, 10 Dec 2008 21:56:26 +0900 (JST) Date: Wed, 10 Dec 2008 21:56:25 +0900 From: WATANABE Kazuhiro To: freebsd-current User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.7 Emacs/21.3 (i386--freebsd) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20081210125627.25732615CD@mail.asahi-net.or.jp> Subject: [patch] de(4) has not worked on 8-current since Feb 13 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Dec 2008 12:56:28 -0000 Hi, all. My de(4) NICs has not worked on 8-current since Feb 13. I've tried to checkout the 8-current source tree from the CVS repository with a number of "-D" options and re-compiled it. As a result a kernel which is made from sources with "cvs checkout -D '2008-02-12 00:00 UTC' src" works well with the de(4) NICs. But with '2008-02-13 00:00 UTC' and the later date, the kernel cannot send data from the NICs. Receiving data are fine. For example: $ scp other_host:/boot/kernel/kernel . Password: kernel 100% 4717KB 943.5KB/s 00:05 $ scp /boot/kernel/kernel other_host: Password: kernel 1% 192KB 0.0KB/s - stalled -^CKilled by signal 2. $ The latest 8-current has the same problem. And these NICs works well on 7.0-RELEASE. To resolve the problem, I have to restore a change which was commited to sys/i386/i386/busdma_machdep.c revision 1.91. http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/i386/i386/busdma_machdep.c#rev1.91 Here is a patch. But I don't know the meaning of this :-( --- sys/i386/i386/busdma_machdep.c.orig 2008-12-08 20:33:16.000000000 +0900 +++ sys/i386/i386/busdma_machdep.c 2008-12-08 21:24:43.000000000 +0900 @@ -585,7 +585,7 @@ * Count the number of bounce pages * needed in order to complete this transfer */ - vaddr = (vm_offset_t)buf; + vaddr = trunc_page((vm_offset_t)buf); vendaddr = (vm_offset_t)buf + buflen; while (vaddr < vendaddr) { @@ -594,7 +594,7 @@ run_filter(dmat, paddr) != 0) { map->pagesneeded++; } - vaddr += (PAGE_SIZE - ((vm_offset_t)vaddr & PAGE_MASK)); + vaddr += PAGE_SIZE; } CTR1(KTR_BUSDMA, "pagesneeded= %d\n", map->pagesneeded); } I've tested the patch on the latest 8-current with the following NICs. * SMC EtherPower10/100 $ uname -a FreeBSD aries.sign.local 8.0-CURRENT FreeBSD 8.0-CURRENT #4: Tue Dec 9 15:03:24 JST 2008 nabe@capricorn:/FreeBSD/obj/pc98/HEAD/pc98/FreeBSD/HEAD/src/sys/LEFTEYE pc98 $ dmesg | grep '^de[0-9]' de0: port 0x6000-0x607f mem 0x20410000-0x2041007f irq 3 at device 13.0 on pci0 de0: SMC 9332BDT 21140A [10-100Mb/s] pass 2.0 de0: WARNING: using obsoleted if_watchdog interface de0: Ethernet address: 00:00:c0:xx:xx:xx de0: [ITHREAD] * Corega FastEther PCI-TX $ uname -a FreeBSD scorpio.sign.local 8.0-CURRENT FreeBSD 8.0-CURRENT #4: Tue Dec 9 15:01:10 JST 2008 nabe@capricorn:/FreeBSD/obj/i386/HEAD/FreeBSD/HEAD/src/sys/GENERIC i386 $ dmesg | grep '^de[0-9]' de0: port 0xe000-0xe07f mem 0xd9001000-0xd900107f irq 11 at device 15.0 on pci0 de0: 21140A [10-100Mb/s] pass 2.2 de0: WARNING: using obsoleted if_watchdog interface de0: Ethernet address: 00:00:f4:xx:xx:xx de0: [ITHREAD] --- WATANABE Kazuhiro (CQG00620@nifty.ne.jp) From owner-freebsd-current@FreeBSD.ORG Wed Dec 10 13:47:37 2008 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BDE091065670 for ; Wed, 10 Dec 2008 13:47:37 +0000 (UTC) (envelope-from bsam@ipt.ru) Received: from services.ipt.ru (services.ipt.ru [194.62.233.110]) by mx1.freebsd.org (Postfix) with ESMTP id D29378FC13 for ; Wed, 10 Dec 2008 13:47:36 +0000 (UTC) (envelope-from bsam@ipt.ru) Received: from bb.ipt.ru ([194.62.233.89]) by services.ipt.ru with esmtp (Exim 4.54 (FreeBSD)) id 1LAPPb-000OdQ-7C for freebsd-current@FreeBSD.org; Wed, 10 Dec 2008 16:47:35 +0300 To: freebsd-current@FreeBSD.org From: Boris Samorodov Date: Wed, 10 Dec 2008 16:47:34 +0300 Message-ID: <92804393@bb.ipt.ru> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Subject: Timeda 8-multiport adapter: only 2 ports available X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Dec 2008 13:47:37 -0000 Hi All, I've got a Sunix PCI Serial 8-channel Multiport adapter (Timedia chipset): ----- puc0@pci0:5:2:0: class=0x070002 card=0x40661409 chip=0x71681409 rev=0x01 hdr=0x00 vendor = 'Timedia Technology Co Ltd' device = '40371409 PCI / ISA Asynchronous UART Signal Chips Solution' class = simple comms subclass = UART ----- Here is a verbose dmesg: ----- puc0: port 0xec00-0xec1f,0xe880-0xe88f,0xe800-0xe807,0xe480-0xe487,0xe400-0xe407,0xe080-0xe087 irq 18 at device 2.0 on pci5 puc0: Reserved 0x20 bytes for rid 0x10 type 4 at 0xec00 puc0: Reserved 0x10 bytes for rid 0x14 type 4 at 0xe880 puc0: Reserved 0x8 bytes for rid 0x18 type 4 at 0xe800 puc0: Reserved 0x8 bytes for rid 0x1c type 4 at 0xe480 puc0: Reserved 0x8 bytes for rid 0x20 type 4 at 0xe400 puc0: Reserved 0x8 bytes for rid 0x24 type 4 at 0xe080 puc0: [FILTER] uart4: <16550 or compatible> on puc0 uart4: [FILTER] uart4: fast interrupt uart5: <16550 or compatible> on puc0 uart5: [FILTER] uart5: fast interrupt ----- devinfo -rv: ----- pci5 puc0 pnpinfo vendor=0x1409 device=0x7168 subvendor=0x1409 subdevice=0x4066 class=0x070002 at slot=2 function=0 I/O ports: 0xe080-0xe087 0xe400-0xe407 0xe480-0xe487 0xe800-0xe807 0xe880-0xe88f 0xec00-0xec1f uart4 puc0 I/O port mapping: 60416-60423 puc0 port numbers: 1 uart5 puc0 I/O port mapping: 60424-60431 puc0 port numbers: 2 ----- The system: ----- FreeBSD host.ipt.ru 8.0-CURRENT FreeBSD 8.0-CURRENT #7: Fri Dec 5 14:58:48 MSK 2008 root@host.ipt.ru:/usr/obj/usr/src/sys/HOST i386 ----- Well, I need other ports. SOS! ;-) WBR -- Boris Samorodov (bsam) Research Engineer, http://www.ipt.ru Telephone & Internet SP FreeBSD committer, http://www.FreeBSD.org The Power To Serve From owner-freebsd-current@FreeBSD.ORG Wed Dec 10 00:33:46 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5F97D1065675; Wed, 10 Dec 2008 00:33:46 +0000 (UTC) (envelope-from paul@fletchermoorland.co.uk) Received: from hydra.fletchermoorland.co.uk (93-152-14-233.daisydsl.managedbroadband.co.uk [93.152.14.233]) by mx1.freebsd.org (Postfix) with ESMTP id AC8EC8FC0C; Wed, 10 Dec 2008 00:33:45 +0000 (UTC) (envelope-from paul@fletchermoorland.co.uk) Received: from apollo (78-32-77-91.static-adsl.entanet.co.uk [78.32.77.91] (may be forged)) by hydra.fletchermoorland.co.uk (8.14.2/8.14.2) with ESMTP id mB9NsOCU026758; Tue, 9 Dec 2008 23:54:24 GMT (envelope-from paul@fletchermoorland.co.uk) From: "Paul Wootton" To: "'Doug Rabson'" , "'Joao Barros'" References: <200812070319.18461.ken@mthelicon.com><66BF33BA-EC11-446F-9DE7-15395F293FE2@rabson.org> <200812071217.20500.ken@mthelicon.com> Date: Tue, 9 Dec 2008 23:54:23 -0000 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_097A_01C95A59.76D7E7A0" X-Mailer: Microsoft Office Outlook 11 Thread-Index: AclYZdeqvU848MR2S165xKklLA3etgB84p/Q X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 In-Reply-To: <200812071217.20500.ken@mthelicon.com> X-Mailman-Approved-At: Wed, 10 Dec 2008 14:03:56 +0000 Cc: hackers@freebsd.org, current@freebsd.org, 'Pegasus Mc Cleaft' Subject: RE: Problems with zfsboot loader if raidz present on any drive X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Dec 2008 00:33:46 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_097A_01C95A59.76D7E7A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit >-----Original Message----- >From: owner-freebsd-hackers@freebsd.org >[mailto:owner-freebsd-hackers@freebsd.org] On Behalf Of Pegasus Mc >Cleaft >Sent: 07 December 2008 12:17 > To: Doug Rabson > Cc: hackers@freebsd.org; current@freebsd.org > Subject: Re: Problems with zfsboot loader if raidz present on any >drive > > On Sunday 07 December 2008 09:22:16 Doug Rabson wrote: > On 7 Dec 2008, at 03:19, Pegasus Mc Cleaft wrote: > > > Hello Hackers, > > > > > > Recently and friend and I have been trying to get the new > > > gptzfsboot working on our machines and ran into a interesting > > > problem. > > > > > > Initially I was building the world without the environment > > > variable LOADER_ZFS_SUPPORT=YES in the /etc/make.conf and this, of > > > course, didnt work very well. Every time the machine booted, it > > > would throw 2 lines after the pin-wheel and then reboot. I > > > couldent read what the lines were it went so fast. > > > > > > My friend had a bit more luck and got his machine working OK with > > > a single drive and later a mirror drive added. > > > > > > I added the environment variable and rebuilt everything and > > > installed. This time, I could see the bios drives and a further 2 > > > lines of ZFS something and a reboot... > > > > > > No matter what I tried, I couldent get the machine to boot up to > > > a point where I could try and fix the problem, so I started > > > pulling devices out and found the following: If there is a raidz > > > pool on any drive (not necessarily the one that you are trying to > > > boot from) the loader dies and reboots the machine. My friend, as > > > an experiment created 3 gpt partitions (in addition to the single > > > partition that he had been previously booted from) on his single > > > drive and made a raidz pool for testing. His machine showed the > > > same condition as mine, however he was able to capture the message > > > before the machine > > > rebooted: > > > > > > > > > ZFS: can only boot from disk or mirror vdevs > > > > > > ZFS: inconsistent nvlist contents > > > > The zfsboot code in current doesn't support raidz or raidz2. I have > > been working on adding that support but its not ready yet. The code > > works in my test harness but crashes instantly when I put it in the > > boot code :(. I should have time to finish debugging it soon. > > Hi Doug, > > In my haste to put a message to the group, I didnt do a very good job > of explaining or give what platform I was working with. > > I set up a single disk pool with the gptzfsboot code on it as a boot drive. > My idea was to have a single disk boot (and after it boots and I can > kill the UFS drive I am currently booting from) convert it to a > mirror. But I have 6 other drives in the machine that I have as a raidz for my /usr/home, et al. > > If the 6 raidz drives are present at boot time, the machine starts to > cyclic reboot just after the pin-wheel. > > The machine I am working on is running FBSD8.0-Current as of midnight > 7/12/2008 and the platform is AMD64. > > If I can help test in any way I would be more than happy to try, or > provide any information necessary.. > > ~Peg Hi Doug, I was working with Peg on this over the weekend. I think I have a patch for this - see http://www.freebsd.org/cgi/query-pr.cgi?pr=129539 The problem was that we were not checking the return code from vdev_init_from_nvlist() on line 726 in /usr/src/sys/boot/zfs/zfsimpl.c Joao, Do you want to try the attached patch? It seems to have fixed the problem, at least on mine and Peg's machine. Cheers Paul ------=_NextPart_000_097A_01C95A59.76D7E7A0 Content-Type: application/octet-stream; name="zfsimpl.c.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="zfsimpl.c.patch" *** zfsimpl.c Wed Nov 19 16:59:19 2008=0A= --- zfsimpl.c.fix Tue Dec 9 22:48:36 2008=0A= ***************=0A= *** 721,731 ****=0A= if (nvlist_find(nvlist,=0A= ZPOOL_CONFIG_VDEV_TREE,=0A= DATA_TYPE_NVLIST, 0, &vdevs)) {=0A= return (EIO);=0A= }=0A= ! vdev_init_from_nvlist(vdevs, &top_vdev);=0A= =0A= /*=0A= * Add the toplevel vdev to the pool if its not already there.=0A= */=0A= STAILQ_FOREACH(pool_vdev, &spa->spa_vdevs, v_childlink)=0A= --- 721,733 ----=0A= if (nvlist_find(nvlist,=0A= ZPOOL_CONFIG_VDEV_TREE,=0A= DATA_TYPE_NVLIST, 0, &vdevs)) {=0A= return (EIO);=0A= }=0A= ! int initRetVal =3D vdev_init_from_nvlist(vdevs, &top_vdev);=0A= ! if(initRetVal)=0A= ! return initRetVal;=0A= =0A= /*=0A= * Add the toplevel vdev to the pool if its not already there.=0A= */=0A= STAILQ_FOREACH(pool_vdev, &spa->spa_vdevs, v_childlink)=0A= ------=_NextPart_000_097A_01C95A59.76D7E7A0-- From owner-freebsd-current@FreeBSD.ORG Wed Dec 10 09:25:44 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D5071106564A for ; Wed, 10 Dec 2008 09:25:44 +0000 (UTC) (envelope-from levitchd@insightbb.com) Received: from mxsf02.insightbb.com (mxsf02.insightbb.com [74.128.0.63]) by mx1.freebsd.org (Postfix) with ESMTP id A31898FC1C for ; Wed, 10 Dec 2008 09:25:44 +0000 (UTC) (envelope-from levitchd@insightbb.com) X-IronPort-AV: E=Sophos;i="4.33,746,1220241600"; d="scan'208";a="574690466" Received: from unknown (HELO asav00.insightbb.com) ([172.31.249.124]) by mxsf02.insightbb.com with ESMTP; 10 Dec 2008 03:57:06 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AicFALMSP0lKgDM6/2dsb2JhbACBbI0VwTSDBw X-IronPort-AV: E=Sophos;i="4.33,746,1220241600"; d="scan'208";a="63839045" Received: from 74-128-51-58.dhcp.insightbb.com (HELO freebsd7.levitch.org) ([74.128.51.58]) by asavout00.insightbb.com with ESMTP; 10 Dec 2008 03:57:06 -0500 Message-ID: <493F84A4.1060103@insightbb.com> Date: Wed, 10 Dec 2008 03:58:12 -0500 From: Darrel User-Agent: Thunderbird 2.0.0.18 (X11/20081123) MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 10 Dec 2008 14:13:34 +0000 Subject: $FreeBSD: www/en/handbook/Makefile,v 1.9 2002/06/27 19:55:40 nik Exp $ X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Dec 2008 09:25:44 -0000 (66) @ 3:18:42> uname -a FreeBSD freebsd7.levitch.org 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Sun Dec 7 16:19:00 EST 2008 darrel1@freebsd7.levitch.org:/usr/obj/usr/src/sys/D amd64 how to install /usr/doc and /usr/www on this local machine? packet filter is implemented on this network. sincerely, darrel From owner-freebsd-current@FreeBSD.ORG Wed Dec 10 14:13:50 2008 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4D9181065675 for ; Wed, 10 Dec 2008 14:13:50 +0000 (UTC) (envelope-from bsam@ipt.ru) Received: from services.ipt.ru (services.ipt.ru [194.62.233.110]) by mx1.freebsd.org (Postfix) with ESMTP id 087BA8FC23 for ; Wed, 10 Dec 2008 14:13:50 +0000 (UTC) (envelope-from bsam@ipt.ru) Received: from bb.ipt.ru ([194.62.233.89]) by services.ipt.ru with esmtp (Exim 4.54 (FreeBSD)) id 1LAPoz-000OyB-2R for freebsd-current@FreeBSD.org; Wed, 10 Dec 2008 17:13:49 +0300 To: freebsd-current@FreeBSD.org References: <92804393@bb.ipt.ru> From: Boris Samorodov Date: Wed, 10 Dec 2008 17:13:48 +0300 In-Reply-To: <92804393@bb.ipt.ru> (Boris Samorodov's message of "Wed\, 10 Dec 2008 16\:47\:34 +0300") Message-ID: <26722819@bb.ipt.ru> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Subject: Re: Timeda 8-multiport adapter: only 2 ports available X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Dec 2008 14:13:50 -0000 Boris Samorodov writes: > I've got a Sunix PCI Serial 8-channel Multiport adapter (Timedia chipset): > ----- > puc0@pci0:5:2:0: class=0x070002 card=0x40661409 chip=0x71681409 rev=0x01 hdr=0x00 > vendor = 'Timedia Technology Co Ltd' > device = '40371409 PCI / ISA Asynchronous UART Signal Chips Solution' Actually the card is 4066, while 4037 (according to pucdata.c) is indeed a dual-port card. May be the card is wrongly interpreted by the OS? > class = simple comms > subclass = UART > ----- > > Here is a verbose dmesg: > ----- > puc0: port 0xec00-0xec1f,0xe880-0xe88f,0xe800-0xe807,0xe480-0xe487,0xe400-0xe407,0xe080-0xe087 irq 18 at device 2.0 on pci5 > puc0: Reserved 0x20 bytes for rid 0x10 type 4 at 0xec00 > puc0: Reserved 0x10 bytes for rid 0x14 type 4 at 0xe880 > puc0: Reserved 0x8 bytes for rid 0x18 type 4 at 0xe800 > puc0: Reserved 0x8 bytes for rid 0x1c type 4 at 0xe480 > puc0: Reserved 0x8 bytes for rid 0x20 type 4 at 0xe400 > puc0: Reserved 0x8 bytes for rid 0x24 type 4 at 0xe080 > puc0: [FILTER] > uart4: <16550 or compatible> on puc0 > uart4: [FILTER] > uart4: fast interrupt > uart5: <16550 or compatible> on puc0 > uart5: [FILTER] > uart5: fast interrupt > ----- > > devinfo -rv: > ----- > pci5 > puc0 pnpinfo vendor=0x1409 device=0x7168 subvendor=0x1409 subdevice=0x4066 class=0x070002 at slot=2 function=0 > I/O ports: > 0xe080-0xe087 > 0xe400-0xe407 > 0xe480-0xe487 > 0xe800-0xe807 > 0xe880-0xe88f > 0xec00-0xec1f > uart4 > puc0 I/O port mapping: > 60416-60423 > puc0 port numbers: > 1 > uart5 > puc0 I/O port mapping: > 60424-60431 > puc0 port numbers: > 2 > ----- > > The system: > ----- > FreeBSD host.ipt.ru 8.0-CURRENT FreeBSD 8.0-CURRENT #7: Fri Dec 5 14:58:48 MSK 2008 root@host.ipt.ru:/usr/obj/usr/src/sys/HOST i386 > ----- > > Well, I need other ports. SOS! ;-) WBR -- Boris Samorodov (bsam) Research Engineer, http://www.ipt.ru Telephone & Internet SP FreeBSD committer, http://www.FreeBSD.org The Power To Serve From owner-freebsd-current@FreeBSD.ORG Wed Dec 10 15:38:03 2008 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 24FE31065678 for ; Wed, 10 Dec 2008 15:38:03 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) Received: from 0.mx.codelabs.ru (0.mx.codelabs.ru [144.206.177.45]) by mx1.freebsd.org (Postfix) with ESMTP id C991D8FC1D for ; Wed, 10 Dec 2008 15:38:02 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=one; d=codelabs.ru; h=Received:Date:From:To:Cc:Subject:Message-ID:Reply-To:References:MIME-Version:Content-Type:Content-Disposition:In-Reply-To:Sender; b=lTaB44+WYYxsh3Kpo0GR1H8Sh8SK5ZTMTM31YJe2xioz58+8A5L1p9jEGMK64IqMr1s3kufNVmNfJcJ/6FXwrrOd1jQvocNvMBTOAmA+089nTL1yoyrP1Ije16W67dx7U0isQfIdwBeZl4RoXwnyhkuvl3BUqA5tZ6R6np0vJds=; Received: from shadow.codelabs.ru (shadow.codelabs.ru [144.206.177.8]) by 0.mx.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1LAR8T-0007cl-Hc; Wed, 10 Dec 2008 18:38:01 +0300 Date: Wed, 10 Dec 2008 18:38:00 +0300 From: Eygene Ryabinkin To: Boris Samorodov Message-ID: References: <92804393@bb.ipt.ru> <26722819@bb.ipt.ru> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="7iMSBzlTiPOCCT2k" Content-Disposition: inline In-Reply-To: <26722819@bb.ipt.ru> Sender: rea-fbsd@codelabs.ru Cc: freebsd-current@FreeBSD.org Subject: Re: Timeda 8-multiport adapter: only 2 ports available X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rea-fbsd@codelabs.ru List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Dec 2008 15:38:03 -0000 --7iMSBzlTiPOCCT2k Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Boris, good day. Wed, Dec 10, 2008 at 05:13:48PM +0300, Boris Samorodov wrote: > Boris Samorodov writes: >=20 > > I've got a Sunix PCI Serial 8-channel Multiport adapter (Timedia chipse= t): > > ----- > > puc0@pci0:5:2:0: class=3D0x070002 card=3D0x40661409 chip=3D0x716= 81409 rev=3D0x01 hdr=3D0x00 > > vendor =3D 'Timedia Technology Co Ltd' > > device =3D '40371409 PCI / ISA Asynchronous UART Signal Chips S= olution' >=20 > Actually the card is 4066, while 4037 (according to pucdata.c) is indeed > a dual-port card. May be the card is wrongly interpreted by the OS? pciconf just don't know about 4066, so is prints what it has in the database. This is irrelevant to the driver -- it discovers the correct chip with 8 ports: > > puc0: port 0xec00-0xec1f,0xe880-0xe8= 8f,0xe800-0xe807,0xe480-0xe487,0xe400-0xe407,0xe080-0xe087 irq 18 at device= 2.0 on pci5 > > puc0: Reserved 0x20 bytes for rid 0x10 type 4 at 0xec00 > > puc0: Reserved 0x10 bytes for rid 0x14 type 4 at 0xe880 > > puc0: Reserved 0x8 bytes for rid 0x18 type 4 at 0xe800 > > puc0: Reserved 0x8 bytes for rid 0x1c type 4 at 0xe480 > > puc0: Reserved 0x8 bytes for rid 0x20 type 4 at 0xe400 > > puc0: Reserved 0x8 bytes for rid 0x24 type 4 at 0xe080 > > puc0: [FILTER] > > uart4: <16550 or compatible> on puc0 > > uart4: [FILTER] > > uart4: fast interrupt > > uart5: <16550 or compatible> on puc0 > > uart5: [FILTER] > > uart5: fast interrupt > > ----- Judging by this output, the 6 ports that got their reservations at dev/pci/pci.c are the ones that aren't recognized by uart. You may need to add trace printfs to uart_puc_probe (uart_bus_puc.c) and to uart_bus_probe (uart_core.c), just around the register resource allocator. This should show what devices are passed to the probe routines and which are rejected. Be sure to include 'rid' values to your debug output to get the idea what ports we're speaking about. --=20 Eygene _ ___ _.--. # \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard / ' ` , __.--' # to read the on-line manual =20 )/' _/ \ `-_, / # while single-stepping the kernel. `-'" `"\_ ,_.-;_.-\_ ', fsc/as # _.-'_./ {_.' ; / # -- FreeBSD Developers handbook=20 {_.-``-' {_/ # --7iMSBzlTiPOCCT2k Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkk/4lcACgkQthUKNsbL7Yi1PACfZSMBOC1L012UYGv+HiIrbbJy gwYAnAlb3nG2AoZpK/u1L2NVINsHnaVL =COq+ -----END PGP SIGNATURE----- --7iMSBzlTiPOCCT2k-- From owner-freebsd-current@FreeBSD.ORG Wed Dec 10 16:19:44 2008 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7661C1065670 for ; Wed, 10 Dec 2008 16:19:44 +0000 (UTC) (envelope-from bsam@ipt.ru) Received: from services.ipt.ru (services.ipt.ru [194.62.233.110]) by mx1.freebsd.org (Postfix) with ESMTP id 3005F8FC14 for ; Wed, 10 Dec 2008 16:19:44 +0000 (UTC) (envelope-from bsam@ipt.ru) Received: from bb.ipt.ru ([194.62.233.89]) by services.ipt.ru with esmtp (Exim 4.54 (FreeBSD)) id 1LARmo-0000Zv-VW; Wed, 10 Dec 2008 19:19:43 +0300 To: rea-fbsd@codelabs.ru References: <92804393@bb.ipt.ru> <26722819@bb.ipt.ru> From: Boris Samorodov Date: Wed, 10 Dec 2008 19:19:42 +0300 In-Reply-To: (Eygene Ryabinkin's message of "Wed\, 10 Dec 2008 18\:38\:00 +0300") Message-ID: <39207585@bb.ipt.ru> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-current@FreeBSD.org Subject: Re: Timeda 8-multiport adapter: only 2 ports available X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Dec 2008 16:19:44 -0000 Hello Eygene, Eygene Ryabinkin writes: > Boris, good day. > Wed, Dec 10, 2008 at 05:13:48PM +0300, Boris Samorodov wrote: >> Boris Samorodov writes: >> >> > I've got a Sunix PCI Serial 8-channel Multiport adapter (Timedia chipset): >> > ----- >> > puc0@pci0:5:2:0: class=0x070002 card=0x40661409 chip=0x71681409 rev=0x01 hdr=0x00 >> > vendor = 'Timedia Technology Co Ltd' >> > device = '40371409 PCI / ISA Asynchronous UART Signal Chips Solution' >> >> Actually the card is 4066, while 4037 (according to pucdata.c) is indeed >> a dual-port card. May be the card is wrongly interpreted by the OS? > > pciconf just don't know about 4066, so is prints what it has in the > database. This is irrelevant to the driver -- it discovers the correct > chip with 8 ports: > >> > puc0: port 0xec00-0xec1f,0xe880-0xe88f,0xe800-0xe807,0xe480-0xe487,0xe400-0xe407,0xe080-0xe087 irq 18 at device 2.0 on pci5 >> > puc0: Reserved 0x20 bytes for rid 0x10 type 4 at 0xec00 >> > puc0: Reserved 0x10 bytes for rid 0x14 type 4 at 0xe880 >> > puc0: Reserved 0x8 bytes for rid 0x18 type 4 at 0xe800 >> > puc0: Reserved 0x8 bytes for rid 0x1c type 4 at 0xe480 >> > puc0: Reserved 0x8 bytes for rid 0x20 type 4 at 0xe400 >> > puc0: Reserved 0x8 bytes for rid 0x24 type 4 at 0xe080 >> > puc0: [FILTER] >> > uart4: <16550 or compatible> on puc0 >> > uart4: [FILTER] >> > uart4: fast interrupt >> > uart5: <16550 or compatible> on puc0 >> > uart5: [FILTER] >> > uart5: fast interrupt >> > ----- > > Judging by this output, the 6 ports that got their reservations at > dev/pci/pci.c are the ones that aren't recognized by uart. You may need Thanks for your explanation. > to add trace printfs to uart_puc_probe (uart_bus_puc.c) and to > uart_bus_probe (uart_core.c), just around the register resource > allocator. This should show what devices are passed to the probe > routines and which are rejected. Be sure to include 'rid' values to > your debug output to get the idea what ports we're speaking about. I wish I can. :-( Can you give me an example / forward to howto or like? Thanks. BTW, our mailservers don't like each other: ----- 2008-12-10 18:39:07 1LAR9W-000Ka0-VK H=0.mx.codelabs.ru [144.206.177.45] sender verify fail for : response to "MAIL FROM:<>" from 0.mx.codelabs.ru [144.206.177.45] was: 550 failed ----- WBR -- Boris Samorodov (bsam) Research Engineer, http://www.ipt.ru Telephone & Internet SP FreeBSD committer, http://www.FreeBSD.org The Power To Serve From owner-freebsd-current@FreeBSD.ORG Wed Dec 10 16:47:02 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D12911065670; Wed, 10 Dec 2008 16:47:02 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from phoenix.cs.uoguelph.ca (phoenix.cs.uoguelph.ca [131.104.94.216]) by mx1.freebsd.org (Postfix) with ESMTP id 91CD48FC1D; Wed, 10 Dec 2008 16:47:02 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from muncher.cs.uoguelph.ca (muncher.cs.uoguelph.ca [131.104.91.102]) by phoenix.cs.uoguelph.ca (8.13.1/8.13.1) with ESMTP id mBAGT07B031229; Wed, 10 Dec 2008 11:29:00 -0500 Received: from localhost (rmacklem@localhost) by muncher.cs.uoguelph.ca (8.11.7p3+Sun/8.11.6) with ESMTP id mBAGUQ125461; Wed, 10 Dec 2008 11:30:26 -0500 (EST) X-Authentication-Warning: muncher.cs.uoguelph.ca: rmacklem owned process doing -bs Date: Wed, 10 Dec 2008 11:30:26 -0500 (EST) From: Rick Macklem X-X-Sender: rmacklem@muncher.cs.uoguelph.ca To: David Wolfskill In-Reply-To: <20081209190110.GW60731@albert.catwhisker.org> Message-ID: References: <20081203001538.GC96383@bunrab.catwhisker.org> <20081209190110.GW60731@albert.catwhisker.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Scanned-By: MIMEDefang 2.63 on 131.104.94.216 Cc: hackers@freebsd.org, current@freebsd.org Subject: Re: NFS (& amd?) dysfunction descending a hierarchy X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Dec 2008 16:47:02 -0000 On Tue, 9 Dec 2008, David Wolfskill wrote: > On Tue, Dec 02, 2008 at 04:15:38PM -0800, David Wolfskill wrote: >> I seem to have a fairly- (though not deterministly so) reproducible >> mode of failure with an NFS-mounted directory hierarchy: An attempt to >> traverse a "sufficiently large" hierarchy (e.g., via "tar zcpf" or "rm >> -fr") will fail to "visit" some subdirectories, typically apparently >> acting as if the subdirectories in question do not actually exist >> (despite the names having been returned in the output of a previous >> readdir()). >> ... > > I was able to reproduce the external symptoms of the failure running > CURRENT as of yesterday, using "rm -fr" of a copy of a recent > /usr/ports hierachy on an NFS-mounted file system as a test case. > However, I believe the mechanism may be a bit different -- while > still being other than what I would expect. > > One aspect in which the externally-observable symptoms were different > (under CURRENT, vs. RELENG_7) is that under CURRENT, once the error > condition occurred, the NFS client machine was in a state where it > merely kept repeating > > nfs server pid848@fbsd-build:/volume: not responding > > until I logged in as root & rebooted it. > The different behaviour for -CURRENT could be the newer RPC layer that was recently introduced, but that doesn't explain the basic problem. All I can think of is to ask the obvious question. "Are you using interruptible or soft mounts?" If so, switch to hard mounts and see if the problem goes away. (imho, neither interruptible nor soft mounts are a good idea. You can use a forced dismount if there is a crashed NFS server that isn't coming back anytime soon.) If you are getting this with hard mounts, I'm afraid I have no idea what the problem is, rick. From owner-freebsd-current@FreeBSD.ORG Wed Dec 10 16:48:34 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A550F106568E for ; Wed, 10 Dec 2008 16:48:34 +0000 (UTC) (envelope-from rdivacky@lev.vlakno.cz) Received: from vlakno.cz (77-93-215-190.static.masterinter.net [77.93.215.190]) by mx1.freebsd.org (Postfix) with ESMTP id 499818FC1E for ; Wed, 10 Dec 2008 16:48:33 +0000 (UTC) (envelope-from rdivacky@lev.vlakno.cz) Received: from localhost (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id 580D19CB1B2 for ; Wed, 10 Dec 2008 17:43:48 +0100 (CET) X-Virus-Scanned: amavisd-new at vlakno.cz Received: from vlakno.cz ([127.0.0.1]) by localhost (lev.vlakno.cz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rttWrP2zZhUJ for ; Wed, 10 Dec 2008 17:43:46 +0100 (CET) Received: from lev.vlakno.cz (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id 14F289CB229 for ; Wed, 10 Dec 2008 17:43:46 +0100 (CET) Received: (from rdivacky@localhost) by lev.vlakno.cz (8.14.2/8.14.2/Submit) id mBAGhj1C032758 for current@freebsd.org; Wed, 10 Dec 2008 17:43:45 +0100 (CET) (envelope-from rdivacky) Date: Wed, 10 Dec 2008 17:43:45 +0100 From: Roman Divacky To: current@freebsd.org Message-ID: <20081210164345.GA32188@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="cNdxnHkX5QqsyA0e" Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Cc: Subject: [PANIC]: rw_lock panic in in_pcballoc() in r185864 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Dec 2008 16:48:34 -0000 --cNdxnHkX5QqsyA0e Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Fatal trap 12: page fault while in kernel mode cpuid =3D 1; apic id =3D 01 fault virtual address =3D 0x1a4 fault code =3D supervisor read, page not present instruction pointer =3D 0x20:0xc0528cc9 stack pointer =3D 0x28:0xc3e77ba8 frame pointer =3D 0x28:0xc3e77bcc code segment =3D base 0x0, limit 0xfffff, type 0x1b =3D DPL 0, pres 1, def32 1, gran 1 processor eflags =3D interrupt enabled, resume, IOPL =3D 0 current process =3D 160 (ifconfig) Physical memory: 978 MB Dumping 46 MB: 31 15 Reading symbols from /boot/kernel/snd_hda.ko...Reading symbols from /boot/k= ernel /snd_hda.ko.symbols...done. done. Loaded symbols for /boot/kernel/snd_hda.ko Reading symbols from /boot/kernel/sound.ko...Reading symbols from /boot/ker= nel/s ound.ko.symbols...done. done. Loaded symbols for /boot/kernel/sound.ko Reading symbols from /boot/modules/nvidia.ko...done. Loaded symbols for /boot/modules/nvidia.ko #0 doadump () at pcpu.h:246 246 pcpu.h: No such file or directory. in pcpu.h (kgdb) bt #0 doadump () at pcpu.h:246 #1 0xc045c834 in db_fncall (dummy1=3D-1008240272, dummy2=3D0, dummy3=3D0, dummy4=3D0xc3e7793c "\001") at ../../../ddb/db_command.c:548 #2 0xc045cbaf in db_command (last_cmdp=3D0xc076765c, cmd_table=3D0x0, dopa= ger=3D1) at ../../../ddb/db_command.c:445 #3 0xc045ce36 in db_command_loop () at ../../../ddb/db_command.c:498 #4 0xc045ec9f in db_trap (type=3D12, code=3D0) at ../../../ddb/db_main.c:2= 29 #5 0xc055966a in kdb_trap (type=3D12, code=3D0, tf=3D0xc3e77b68) at ../../../kern/subr_kdb.c:534 #6 0xc06d7a1a in trap_fatal (frame=3D0xc3e77b68, eva=3D420) at ../../../i386/i386/trap.c:920 #7 0xc06d7daa in trap_pfault (frame=3D0xc3e77b68, usermode=3D0, eva=3D420) at ../../../i386/i386/trap.c:842 #8 0xc06d883c in trap (frame=3D0xc3e77b68) at ../../../i386/i386/trap.c:522 #9 0xc06bd28b in calltrap () at ../../../i386/i386/exception.s:165 #10 0xc0528cc9 in _rw_wlock_hard (rw=3D0xc45a00a4, tid=3D3293569600, file= =3D0x0, line=3D0) at ../../../kern/kern_rwlock.c:616 #11 0xc05eae42 in in_pcballoc (so=3D0xc459e000, pcbinfo=3D0xc0794b40) at ../../../netinet/in_pcb.c:238 #12 0xc060b403 in udp_attach (so=3D0xc459e000, proto=3D0, td=3D0xc44fe240) at ../../../netinet/udp_usrreq.c:1131 #13 0xc0586df5 in socreate (dom=3D2, aso=3D0xc3e77c6c, type=3D2, proto=3D0, #14 0xc058d974 in socket (td=3D0xc44fe240, uap=3D0xc3e77cf8) ---Type to continue, or q to quit---Dec 10 17:29:23 witte= n log in: ROOT LOGIN (root) ON ttyv1 at ../../../kern/uipc_syscalls.c:178 #15 0xc06d8010 in syscall (frame=3D0xc3e77d38) at ../../../i386/i386/trap.c= :1076 #16 0xc06bd320 in Xint0x80_syscall () at ../../../i386/i386/exception.s:261 #17 0x00000033 in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) p *pcbinfo $2 =3D {ipi_listhead =3D 0xc0794b24, ipi_count =3D 1, ipi_hashbase =3D 0xc4= 2fe000, ipi_hashmask =3D 127, ipi_porthashbase =3D 0xc42fce00, ipi_porthashmask = =3D 127, ipi_lastport =3D 0, ipi_lastlow =3D 0, ipi_lasthi =3D 0, ipi_zone =3D 0xc= 1471360, ipi_gencnt =3D 0, ipi_lock =3D {lock_object =3D {lo_name =3D 0xc0713b87 "= udp", lo_flags =3D 69926928, lo_data =3D 0, lo_witness =3D 0x0}, rw_lock =3D 3293569600}, ipi_pspare =3D { (kgdb) p *pcbinfo->ipi_zone $4 =3D {uz_name =3D 0xc0716712 "udpcb", uz_lock =3D 0xc147ed88, uz_keg =3D 0xc147ed80, uz_link =3D {le_next =3D 0x0, le_prev =3D 0xc147ed= a8}, uz_full_bucket =3D {lh_first =3D 0x0}, uz_free_bucket =3D {lh_first =3D 0= x0}, uz_ctor =3D 0, uz_dtor =3D 0, uz_init =3D 0, uz_fini =3D 0, uz_allocs =3D= 0, uz_frees =3D 0, uz_fails =3D 0, uz_fills =3D 0, uz_count =3D 23, uz_cpu = =3D {{ uc_freebucket =3D 0x0, uc_allocbucket =3D 0x0, uc_allocs =3D 0, uc_frees =3D 0}}} the code tries to rw_rwlock() the inp->inp_lock, the inp is allocated from an UMA zone which has no constructor and in the in_pcballoc()=20 the rwlock is never initialized. I believe that's why it crashes can someone confirm/fix that? thnx roman --cNdxnHkX5QqsyA0e Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkk/8cEACgkQLVEj6D3CBEyRwwCbBjcLeSXyinWPClj5i05AGHyy ngsAn2GC/xCuG0qVZ6GF8qQMSrD2nO5Y =Ktsa -----END PGP SIGNATURE----- --cNdxnHkX5QqsyA0e-- From owner-freebsd-current@FreeBSD.ORG Wed Dec 10 16:50:22 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EFA9E106564A; Wed, 10 Dec 2008 16:50:22 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (adsl-63-193-123-122.dsl.snfc21.pacbell.net [63.193.123.122]) by mx1.freebsd.org (Postfix) with ESMTP id 9EAF48FC19; Wed, 10 Dec 2008 16:50:22 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.3/8.14.3) with ESMTP id mBAGoMmB096841; Wed, 10 Dec 2008 08:50:22 -0800 (PST) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.3/8.14.3/Submit) id mBAGoMDE096840; Wed, 10 Dec 2008 08:50:22 -0800 (PST) (envelope-from david) Date: Wed, 10 Dec 2008 08:50:22 -0800 From: David Wolfskill To: Rick Macklem Message-ID: <20081210165022.GJ60731@albert.catwhisker.org> Mail-Followup-To: David Wolfskill , Rick Macklem , hackers@freebsd.org, current@freebsd.org References: <20081203001538.GC96383@bunrab.catwhisker.org> <20081209190110.GW60731@albert.catwhisker.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="tCj5P50694qw/4D5" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: hackers@freebsd.org, current@freebsd.org Subject: Re: NFS (& amd?) dysfunction descending a hierarchy X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Dec 2008 16:50:23 -0000 --tCj5P50694qw/4D5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Dec 10, 2008 at 11:30:26AM -0500, Rick Macklem wrote: >...=20 > The different behaviour for -CURRENT could be the newer RPC layer that > was recently introduced, but that doesn't explain the basic problem. OK. > All I can think of is to ask the obvious question. "Are you using > interruptible or soft mounts?" If so, switch to hard mounts and see > if the problem goes away. (imho, neither interruptible nor soft mounts > are a good idea. You can use a forced dismount if there is a crashed > NFS server that isn't coming back anytime soon.) =46rom examination of /etc/amd* -- I don't see how to get mount(8) or amq(8) to report it -- it appears that we are using interruptible mounts, as we always have. The point is that the behavior has changed in an unexpected way. And I'm not so sure that the use of a forced dismount is generally available, as it would require logging in to the NFS client first, which may be difficult if the NFS server hosting non-root home directories is failing to respond and direct root login via ssh(1) is not permitted (as is the default). > If you are getting this with hard mounts, I'm afraid I have no idea > what the problem is, rick. What concerns me is that even if the attempted unmount gets EBUSY, the user-level process descending the directory hierarchy is getting ENOENT trying to issue fstatfs() against an open file descriptor. I'm having trouble figuring out any way that makes any sense. Peace, david --=20 David H. Wolfskill david@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --tCj5P50694qw/4D5 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkk/800ACgkQmprOCmdXAD2NAQCfcV496CaI836vIAQjUOhGuQYW 1zgAn0/s2ng685xXauSQ5hRqX362lIMG =nYag -----END PGP SIGNATURE----- --tCj5P50694qw/4D5-- From owner-freebsd-current@FreeBSD.ORG Wed Dec 10 17:06:27 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 15C5A1065677; Wed, 10 Dec 2008 17:06:27 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.terabit.net.ua (mail.terabit.net.ua [195.137.202.147]) by mx1.freebsd.org (Postfix) with ESMTP id ABDC78FC1A; Wed, 10 Dec 2008 17:06:26 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from skuns.zoral.com.ua ([91.193.166.194] helo=mail.zoral.com.ua) by mail.terabit.net.ua with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63 (FreeBSD)) (envelope-from ) id 1LASW1-00054Z-16; Wed, 10 Dec 2008 19:06:25 +0200 Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id mBAH6Kox055739 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 10 Dec 2008 19:06:21 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3) with ESMTP id mBAH6KEr027414; Wed, 10 Dec 2008 19:06:20 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3/Submit) id mBAH6KFf027413; Wed, 10 Dec 2008 19:06:20 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 10 Dec 2008 19:06:20 +0200 From: Kostik Belousov To: David Wolfskill , Rick Macklem , hackers@freebsd.org, current@freebsd.org Message-ID: <20081210170620.GS2038@deviant.kiev.zoral.com.ua> References: <20081203001538.GC96383@bunrab.catwhisker.org> <20081209190110.GW60731@albert.catwhisker.org> <20081210165022.GJ60731@albert.catwhisker.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="TRAzd1zqvkbVQS90" Content-Disposition: inline In-Reply-To: <20081210165022.GJ60731@albert.catwhisker.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua X-Virus-Scanned: mail.terabit.net.ua 1LASW1-00054Z-16 04fd08197217dfef5fa1386ec898a19d X-Terabit: YES Cc: Subject: Re: NFS (& amd?) dysfunction descending a hierarchy X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Dec 2008 17:06:27 -0000 --TRAzd1zqvkbVQS90 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Dec 10, 2008 at 08:50:22AM -0800, David Wolfskill wrote: > On Wed, Dec 10, 2008 at 11:30:26AM -0500, Rick Macklem wrote: > >...=20 > > The different behaviour for -CURRENT could be the newer RPC layer that > > was recently introduced, but that doesn't explain the basic problem. >=20 > OK. >=20 > > All I can think of is to ask the obvious question. "Are you using > > interruptible or soft mounts?" If so, switch to hard mounts and see > > if the problem goes away. (imho, neither interruptible nor soft mounts > > are a good idea. You can use a forced dismount if there is a crashed > > NFS server that isn't coming back anytime soon.) >=20 > From examination of /etc/amd* -- I don't see how to get mount(8) or > amq(8) to report it -- it appears that we are using interruptible > mounts, as we always have. >=20 > The point is that the behavior has changed in an unexpected way. And > I'm not so sure that the use of a forced dismount is generally > available, as it would require logging in to the NFS client first, which > may be difficult if the NFS server hosting non-root home directories is > failing to respond and direct root login via ssh(1) is not permitted (as > is the default). >=20 > > If you are getting this with hard mounts, I'm afraid I have no idea > > what the problem is, rick. >=20 > What concerns me is that even if the attempted unmount gets EBUSY, the > user-level process descending the directory hierarchy is getting ENOENT > trying to issue fstatfs() against an open file descriptor. >=20 > I'm having trouble figuring out any way that makes any sense. Basically, the problem is that NFS uses shared lookup, and this allows for the bug where several negative namecache entries are created for non-existent node. Then this node gets created, removing only the first negative namecache entry. For some reasons, vnode is reclaimed; amd' tasting of unmount is a good reason for vnode to be reclaimed. Now, you have existing path and a negative cache entry. This was reported by Peter Holm first, I listed relevant revisions that should fix this in previous mail. --TRAzd1zqvkbVQS90 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkk/9wwACgkQC3+MBN1Mb4h0/QCgiRKkwR+u0kcvEVdC3RxdPskp c5MAoKKMfVJelmr3tQ1aOar81q7Ydpxt =nQ99 -----END PGP SIGNATURE----- --TRAzd1zqvkbVQS90-- From owner-freebsd-current@FreeBSD.ORG Wed Dec 10 17:22:45 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 501871065678 for ; Wed, 10 Dec 2008 17:22:45 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.28]) by mx1.freebsd.org (Postfix) with ESMTP id 01D9B8FC1A for ; Wed, 10 Dec 2008 17:22:44 +0000 (UTC) (envelope-from onemda@gmail.com) Received: by yx-out-2324.google.com with SMTP id 8so268333yxb.13 for ; Wed, 10 Dec 2008 09:22:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=fdNwcW5rWFIeiec5f+VENDeKsYXEzDMVQ3Qkb78vdYo=; b=AKzlWhZYZJPjAVFAomnD+O0/KtfU9jZ93famG873q72Wp5M73OrDqiMUXNZCjD9gJR DTaHH90L/PkrsyTSg2uYzRF6NQoqYbNddsFbWKjcCnZLQcAQMpJruN9UGKB+T7NUtIZQ nROTUIF+9zsXXJi2gj7lAfxBU3nw3UcNcTEeE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=feeTQqIs/YMRW18opnAUpLNXBP5AAn6AaeICGtqcF9eusvFWTjGEzZVM/188uOF/zD K289GIX7vuBhCC//sZczeZQQ2y8nfE62JEB9/tnCTEWnkRe9/ZaB8yWi1gZzih3sucbV BdzmuSmDMVE7b9BlwyMCgxAlss8qXUaclsJAg= Received: by 10.231.12.141 with SMTP id x13mr22292ibx.52.1228929763255; Wed, 10 Dec 2008 09:22:43 -0800 (PST) Received: by 10.231.17.8 with HTTP; Wed, 10 Dec 2008 09:22:43 -0800 (PST) Message-ID: <3a142e750812100922m553be9c6sdcd81d98c81c7ab4@mail.gmail.com> Date: Wed, 10 Dec 2008 18:22:43 +0100 From: "Paul B. Mahol" To: "John Baldwin" In-Reply-To: <200812091602.10850.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200811191510.53793.jhb@FreeBSD.org> <200812051608.50120.jhb@freebsd.org> <3a142e750812051354n747bcbcayb31d8d5f4cc15098@mail.gmail.com> <200812091602.10850.jhb@freebsd.org> Cc: freebsd-current@freebsd.org Subject: Re: [PATCH] MPSAFE/LOOKUP_SHARED cd9660 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Dec 2008 17:22:45 -0000 On 12/9/08, John Baldwin wrote: > The RRIP stuff is all done in cd9660_vget_internal() under an exclusive > lock. > It could be a property of the ISO image. "PX" holds permissions (owner, > etc.). Do you get the same messages w/o the patch with the same ISO image / > CD? > > -- > John Baldwin > I searched little for this message and found kern/63446 PR interesting comment: Caused by cd9660_vnops.c rev. 1.77. VOP_READDIR returns bogus d_fileno, VFS_VGET on this value returns bogus vnode with zeroed attributes. I think that whatever locking is done is done wrong. -- Paul From owner-freebsd-current@FreeBSD.ORG Wed Dec 10 18:53:26 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 385D31065673; Wed, 10 Dec 2008 18:53:26 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id A7AB38FC24; Wed, 10 Dec 2008 18:53:25 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [IPv6:::1]) (authenticated bits=0) by server.baldwin.cx (8.14.3/8.14.3) with ESMTP id mBAIqvkR024770; Wed, 10 Dec 2008 13:53:14 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-current@freebsd.org Date: Wed, 10 Dec 2008 13:31:23 -0500 User-Agent: KMail/1.9.7 References: <493DA269.2070805@FreeBSD.org> <20081208235119.GA46608@onelab2.iet.unipi.it> In-Reply-To: <20081208235119.GA46608@onelab2.iet.unipi.it> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200812101331.24182.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [IPv6:::1]); Wed, 10 Dec 2008 13:53:17 -0500 (EST) X-Virus-Scanned: ClamAV 0.94.2/8743/Wed Dec 10 10:08:45 2008 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Luigi Rizzo , hackers@freebsd.org, Luigi Rizzo , "current@freebsd.org" Subject: Re: Enhancing cdboot [patch for review] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Dec 2008 18:53:26 -0000 On Monday 08 December 2008 06:51:19 pm Luigi Rizzo wrote: > On Mon, Dec 08, 2008 at 02:40:41PM -0800, Maxim Sobolev wrote: > > Hi, > > > > Below please find patch that enhances cdboot with two compile-time options: > ... > > Any comments/suggestions are appreciated. If there are no objections I > > would like to commit the change. The long-term goal is to make > > CDBOOT_PROMPT default mode for installation CD. > > > > http://sobomax.sippysoft.com/~sobomax/cdboot.diff > > Looks good. Some comments: > 1. since there is plenty of space in the cdboot sector, why don't you > make the two option always compiled in, controlling which one to > activate through flags in the bootsector itself, to be set > patching the binary sector itself using a mechanism similar to > boot0cfg. > Of course you cannot alter a cdrom after you burn it, > but it makes it easier to build CDs with one or the other defaults, > patching cdboot or the iso image itself before creating/burning it. I don't think this is very useful because CDs are read-only. You can just as easily build a different cdboot rather than having to write some custom cdbootcfg util to patch the binary. > 2. in fact, the 'silent' option could be disabled at runtime by > pressing some key (e.g. adding a short wait loop before proceeding; > if this is meant for custom, unattended CDs the extra delay should not > matter much); I don't imagine anyone will know to press a key to get verbose messages, and the CD boot process is quick enough you would have to add an artificial delay to it to allow for the keypress. > 3. one nitpick -- in one of the first chunks you replace $start > with $LOAD, but if i am not mistaken operation depends on $LOAD = $start, > so why don't you always use the same ? No, because he relocates it, $start is now the relocated address, but the BIOS loads it at LOAD which is now != $start. > Also in terms of relocation size, wouldn't it be the case of > hardwiring the size of the cd boot sector: > > - mov $((end_init - start)/2),%cx > + mov 1024,%cx I prefer the existing code to make sure and copy the full boot loader, whatever it's size is. Maxim, My only comment is to please make the new block comment match the style of the existing block comments by having '#\n' lines before and after. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Wed Dec 10 18:53:26 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 385D31065673; Wed, 10 Dec 2008 18:53:26 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id A7AB38FC24; Wed, 10 Dec 2008 18:53:25 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [IPv6:::1]) (authenticated bits=0) by server.baldwin.cx (8.14.3/8.14.3) with ESMTP id mBAIqvkR024770; Wed, 10 Dec 2008 13:53:14 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-current@freebsd.org Date: Wed, 10 Dec 2008 13:31:23 -0500 User-Agent: KMail/1.9.7 References: <493DA269.2070805@FreeBSD.org> <20081208235119.GA46608@onelab2.iet.unipi.it> In-Reply-To: <20081208235119.GA46608@onelab2.iet.unipi.it> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200812101331.24182.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [IPv6:::1]); Wed, 10 Dec 2008 13:53:17 -0500 (EST) X-Virus-Scanned: ClamAV 0.94.2/8743/Wed Dec 10 10:08:45 2008 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Luigi Rizzo , hackers@freebsd.org, Luigi Rizzo , "current@freebsd.org" Subject: Re: Enhancing cdboot [patch for review] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Dec 2008 18:53:26 -0000 On Monday 08 December 2008 06:51:19 pm Luigi Rizzo wrote: > On Mon, Dec 08, 2008 at 02:40:41PM -0800, Maxim Sobolev wrote: > > Hi, > > > > Below please find patch that enhances cdboot with two compile-time options: > ... > > Any comments/suggestions are appreciated. If there are no objections I > > would like to commit the change. The long-term goal is to make > > CDBOOT_PROMPT default mode for installation CD. > > > > http://sobomax.sippysoft.com/~sobomax/cdboot.diff > > Looks good. Some comments: > 1. since there is plenty of space in the cdboot sector, why don't you > make the two option always compiled in, controlling which one to > activate through flags in the bootsector itself, to be set > patching the binary sector itself using a mechanism similar to > boot0cfg. > Of course you cannot alter a cdrom after you burn it, > but it makes it easier to build CDs with one or the other defaults, > patching cdboot or the iso image itself before creating/burning it. I don't think this is very useful because CDs are read-only. You can just as easily build a different cdboot rather than having to write some custom cdbootcfg util to patch the binary. > 2. in fact, the 'silent' option could be disabled at runtime by > pressing some key (e.g. adding a short wait loop before proceeding; > if this is meant for custom, unattended CDs the extra delay should not > matter much); I don't imagine anyone will know to press a key to get verbose messages, and the CD boot process is quick enough you would have to add an artificial delay to it to allow for the keypress. > 3. one nitpick -- in one of the first chunks you replace $start > with $LOAD, but if i am not mistaken operation depends on $LOAD = $start, > so why don't you always use the same ? No, because he relocates it, $start is now the relocated address, but the BIOS loads it at LOAD which is now != $start. > Also in terms of relocation size, wouldn't it be the case of > hardwiring the size of the cd boot sector: > > - mov $((end_init - start)/2),%cx > + mov 1024,%cx I prefer the existing code to make sure and copy the full boot loader, whatever it's size is. Maxim, My only comment is to please make the new block comment match the style of the existing block comments by having '#\n' lines before and after. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Wed Dec 10 18:58:42 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 88554106567C for ; Wed, 10 Dec 2008 18:58:42 +0000 (UTC) (envelope-from citrin@citrin.ru) Received: from mail-chaos.rambler.ru (mail-chaos.rambler.ru [81.19.68.130]) by mx1.freebsd.org (Postfix) with ESMTP id 344F98FC1B for ; Wed, 10 Dec 2008 18:58:42 +0000 (UTC) (envelope-from citrin@citrin.ru) Received: from [192.168.1.15] (unknown [81.19.90.156]) (Authenticated sender: citrin@citrin.ru) by mail-chaos.rambler.ru (Postfix) with ESMTPSA id 39F981703C; Wed, 10 Dec 2008 21:58:40 +0300 (MSK) Message-ID: <4940115F.7080004@citrin.ru> Date: Wed, 10 Dec 2008 21:58:39 +0300 From: Anton Yuzhaninov User-Agent: Thunderbird 2.0.0.18 (X11/20081129) MIME-Version: 1.0 To: Pyun YongHyeon References: <200812080248.mB82mfV9043154@svn.freebsd.org> In-Reply-To: <200812080248.mB82mfV9043154@svn.freebsd.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: svn commit: r185756 - head/sys/dev/re X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Dec 2008 18:58:42 -0000 Pyun YongHyeon wrote: > Author: yongari > Date: Mon Dec 8 02:48:41 2008 > New Revision: 185756 > URL: http://svn.freebsd.org/changeset/base/185756 > > Log: > Reduce spin wait time consumed in GMII register access routines. > Waiting for 1ms for each GMII register access looks overkill and it > may also decrease overall performance of driver because re(4) > invokes mii_tick for every hz. > > Tested by: rpaulo > > Modified: > head/sys/dev/re/if_re.c > > Modified: head/sys/dev/re/if_re.c > ============================================================================== > --- head/sys/dev/re/if_re.c Mon Dec 8 02:38:13 2008 (r185755) > +++ head/sys/dev/re/if_re.c Mon Dec 8 02:48:41 2008 (r185756) > @@ -417,13 +417,12 @@ re_gmii_readreg(device_t dev, int phy, i > } > > CSR_WRITE_4(sc, RL_PHYAR, reg << 16); > - DELAY(1000); > > for (i = 0; i < RL_TIMEOUT; i++) { > + DELAY(30); > rval = CSR_READ_4(sc, RL_PHYAR); > if (rval & RL_PHYAR_BUSY) > break; > - DELAY(100); > } > > if (i == RL_TIMEOUT) { > @@ -445,13 +444,12 @@ re_gmii_writereg(device_t dev, int phy, > > CSR_WRITE_4(sc, RL_PHYAR, (reg << 16) | > (data & RL_PHYAR_PHYDATA) | RL_PHYAR_BUSY); > - DELAY(1000); > > for (i = 0; i < RL_TIMEOUT; i++) { > + DELAY(30); > rval = CSR_READ_4(sc, RL_PHYAR); > if (!(rval & RL_PHYAR_BUSY)) > break; > - DELAY(100); > } > > if (i == RL_TIMEOUT) { After this commit I see in logs errors: Dec 10 21:37:42 citrin kernel: re0: PHY read failed Dec 10 21:38:05 citrin last message repeated 3 times Dec 10 21:38:44 citrin last message repeated 3 times Dec 10 21:38:44 citrin kernel: re0: link state changed to DOWN Dec 10 21:38:45 citrin kernel: re0: link state changed to UP Dec 10 21:38:55 citrin kernel: re0: PHY read failed Dec 10 21:39:38 citrin last message repeated 3 times Dec 10 21:39:38 citrin kernel: re0: link state changed to DOWN Dec 10 21:39:39 citrin kernel: re0: link state changed to UP Dec 10 21:40:09 citrin kernel: re0: PHY read failed Dec 10 21:40:21 citrin kernel: re0: PHY read failed Dec 10 21:41:03 citrin kernel: re0: PHY read failed I tried to revert this patch - errors disappeared. HW: re0@pci0:2:5:0: class=0x020000 card=0xe0001458 chip=0x816710ec rev=0x10 hdr=0x00 vendor = 'Realtek Semiconductor' device = 'RTL8169/8110 Family Gigabit Ethernet NIC' class = network subclass = ethernet cap 01[dc] = powerspec 2 supports D0 D1 D2 D3 current D0 from dmesg: re0: port 0xa000-0xa0ff mem 0xe1000000-0xe10000ff irq 21 at device 5.0 on pci2 re0: Chip rev. 0x18000000 re0: MAC rev. 0x00000000 -- Anton Yuzhaninov From owner-freebsd-current@FreeBSD.ORG Wed Dec 10 19:23:49 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BE1611065676; Wed, 10 Dec 2008 19:23:49 +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 9BF698FC18; Wed, 10 Dec 2008 19:23:49 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTP id 38AC146B53; Wed, 10 Dec 2008 14:23:49 -0500 (EST) Date: Wed, 10 Dec 2008 19:23:49 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Roman Divacky In-Reply-To: <20081210164345.GA32188@freebsd.org> Message-ID: References: <20081210164345.GA32188@freebsd.org> User-Agent: Alpine 1.10 (BSF 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: current@freebsd.org Subject: Re: [PANIC]: rw_lock panic in in_pcballoc() in r185864 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Dec 2008 19:23:49 -0000 On Wed, 10 Dec 2008, Roman Divacky wrote: > #9 0xc06bd28b in calltrap () at ../../../i386/i386/exception.s:165 > #10 0xc0528cc9 in _rw_wlock_hard (rw=0xc45a00a4, tid=3293569600, file=0x0, > line=0) at ../../../kern/kern_rwlock.c:616 > #11 0xc05eae42 in in_pcballoc (so=0xc459e000, pcbinfo=0xc0794b40) > at ../../../netinet/in_pcb.c:238 > #12 0xc060b403 in udp_attach (so=0xc459e000, proto=0, td=0xc44fe240) > at ../../../netinet/udp_usrreq.c:1131 > #13 0xc0586df5 in socreate (dom=2, aso=0xc3e77c6c, type=2, proto=0, > #14 0xc058d974 in socket (td=0xc44fe240, uap=0xc3e77cf8) > ---Type to continue, or q to quit---Dec 10 17:29:23 witten log > in: ROOT LOGIN (root) ON ttyv1 > > at ../../../kern/uipc_syscalls.c:178 > #15 0xc06d8010 in syscall (frame=0xc3e77d38) at ../../../i386/i386/trap.c:1076 > #16 0xc06bd320 in Xint0x80_syscall () at ../../../i386/i386/exception.s:261 > #17 0x00000033 in ?? () > Previous frame inner to this frame (corrupt stack?) > > (kgdb) p *pcbinfo > $2 = {ipi_listhead = 0xc0794b24, ipi_count = 1, ipi_hashbase = 0xc42fe000, > ipi_hashmask = 127, ipi_porthashbase = 0xc42fce00, ipi_porthashmask = 127, > ipi_lastport = 0, ipi_lastlow = 0, ipi_lasthi = 0, ipi_zone = 0xc1471360, > ipi_gencnt = 0, ipi_lock = {lock_object = {lo_name = 0xc0713b87 "udp", > lo_flags = 69926928, lo_data = 0, lo_witness = 0x0}, > rw_lock = 3293569600}, ipi_pspare = { > (kgdb) p *pcbinfo->ipi_zone > $4 = {uz_name = 0xc0716712 "udpcb", uz_lock = 0xc147ed88, > uz_keg = 0xc147ed80, uz_link = {le_next = 0x0, le_prev = 0xc147eda8}, > uz_full_bucket = {lh_first = 0x0}, uz_free_bucket = {lh_first = 0x0}, > uz_ctor = 0, uz_dtor = 0, uz_init = 0, uz_fini = 0, uz_allocs = 0, > uz_frees = 0, uz_fails = 0, uz_fills = 0, uz_count = 23, uz_cpu = {{ > uc_freebucket = 0x0, uc_allocbucket = 0x0, uc_allocs = 0, > uc_frees = 0}}} > > the code tries to rw_rwlock() the inp->inp_lock, the inp is allocated from > an UMA zone which has no constructor and in the in_pcballoc() the rwlock is > never initialized. I believe that's why it crashes > > can someone confirm/fix that? Hmm. I disagree with the diagnosis, although clearly there's a problem here of some sort since panicking is, well, bad. Each protocol using the inpcb framework provides its own UMA zone and is responsible for initializing the lock on the inpcb when memory is first pulled into the cache. For UDP, that occurs in udp_inpcb_init(), the init function passed into uma_zcreate() in udp_init(). Notice that when in_pcballoc() zeroes the inpcb, it stops at inp_zero_size, which is before inp_lock, and since the inpcb zone for UDP is set to be a no-free zone, there's no INP lock destroy. So, given that this code has worked for quite a long time for many people, this really raises two questions: (1) how reproduceable is this and at what point does it kick in during the boot/runtime, and (2) when did this start happening in terms of updating your source? Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-current@FreeBSD.ORG Wed Dec 10 19:58:02 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E624E106564A for ; Wed, 10 Dec 2008 19:58:02 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 876408FC1D for ; Wed, 10 Dec 2008 19:58:02 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [IPv6:::1]) (authenticated bits=0) by server.baldwin.cx (8.14.3/8.14.3) with ESMTP id mBAJvori025274; Wed, 10 Dec 2008 14:57:56 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: "Paul B. Mahol" Date: Wed, 10 Dec 2008 14:50:04 -0500 User-Agent: KMail/1.9.7 References: <200811191510.53793.jhb@FreeBSD.org> <200812091602.10850.jhb@freebsd.org> <3a142e750812100922m553be9c6sdcd81d98c81c7ab4@mail.gmail.com> In-Reply-To: <3a142e750812100922m553be9c6sdcd81d98c81c7ab4@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200812101450.04638.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [IPv6:::1]); Wed, 10 Dec 2008 14:57:56 -0500 (EST) X-Virus-Scanned: ClamAV 0.94.2/8744/Wed Dec 10 13:09:46 2008 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: freebsd-current@freebsd.org Subject: Re: [PATCH] MPSAFE/LOOKUP_SHARED cd9660 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Dec 2008 19:58:03 -0000 On Wednesday 10 December 2008 12:22:43 pm Paul B. Mahol wrote: > On 12/9/08, John Baldwin wrote: > > The RRIP stuff is all done in cd9660_vget_internal() under an exclusive > > lock. > > It could be a property of the ISO image. "PX" holds permissions (owner, > > etc.). Do you get the same messages w/o the patch with the same ISO image / > > CD? > > > > -- > > John Baldwin > > > > I searched little for this message and found kern/63446 PR interesting comment: > > Caused by cd9660_vnops.c rev. 1.77. VOP_READDIR returns bogus > d_fileno, VFS_VGET on this value returns bogus vnode with zeroed attributes. > > I think that whatever locking is done is done wrong. That issue isn't a locking issue, it's an issue with VOP_READDIR() using a different meaning for i-node numbers than VFS_VGET(), and would happen regardless of any Giant or vnode locking. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Wed Dec 10 19:58:08 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 809F41065675 for ; Wed, 10 Dec 2008 19:58:08 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 213DB8FC19 for ; Wed, 10 Dec 2008 19:58:08 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [IPv6:::1]) (authenticated bits=0) by server.baldwin.cx (8.14.3/8.14.3) with ESMTP id mBAJvorj025274; Wed, 10 Dec 2008 14:58:02 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: "Paul B. Mahol" Date: Wed, 10 Dec 2008 14:50:47 -0500 User-Agent: KMail/1.9.7 References: <200811191510.53793.jhb@FreeBSD.org> <3a142e750812091516n6bb0880ewb298314e9ba296c@mail.gmail.com> <3a142e750812091628l69034673sa2e11e71ba0bdad4@mail.gmail.com> In-Reply-To: <3a142e750812091628l69034673sa2e11e71ba0bdad4@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200812101450.47191.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [IPv6:::1]); Wed, 10 Dec 2008 14:58:02 -0500 (EST) X-Virus-Scanned: ClamAV 0.94.2/8744/Wed Dec 10 13:09:46 2008 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: freebsd-current@freebsd.org Subject: Re: [PATCH] MPSAFE/LOOKUP_SHARED cd9660 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Dec 2008 19:58:08 -0000 On Tuesday 09 December 2008 07:28:14 pm Paul B. Mahol wrote: > On 12/10/08, Paul B. Mahol wrote: > > On 12/10/08, Paul B. Mahol wrote: > >> On 12/9/08, John Baldwin wrote: > >>> The RRIP stuff is all done in cd9660_vget_internal() under an exclusive > >>> lock. > >>> It could be a property of the ISO image. "PX" holds permissions (owner, > >>> etc.). Do you get the same messages w/o the patch with the same ISO > >>> image > >>> / > >>> CD? > >>> > >>> -- > >>> John Baldwin > >>> > >> > >> No I do not, but I may try other CDs I have many of them, including > >> FreeBSD > > s/Yes I do. Its to late here ... > Ignore that reply. > > cd9660.ko without patch doesnt have this issue. > cd9660.ko with cd9660_mpsafe.patch have this issue, on every CD I tried. Ok, I will try to reproduce this locally. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Wed Dec 10 20:45:31 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2B51B106564A for ; Wed, 10 Dec 2008 20:45:31 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id A0AF68FC08 for ; Wed, 10 Dec 2008 20:45:30 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [IPv6:::1]) (authenticated bits=0) by server.baldwin.cx (8.14.3/8.14.3) with ESMTP id mBAKjHkW025674; Wed, 10 Dec 2008 15:45:24 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-current@freebsd.org Date: Wed, 10 Dec 2008 15:39:25 -0500 User-Agent: KMail/1.9.7 References: <20081210125627.25732615CD@mail.asahi-net.or.jp> In-Reply-To: <20081210125627.25732615CD@mail.asahi-net.or.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200812101539.26031.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [IPv6:::1]); Wed, 10 Dec 2008 15:45:24 -0500 (EST) X-Virus-Scanned: ClamAV 0.94.2/8744/Wed Dec 10 13:09:46 2008 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: WATANABE Kazuhiro Subject: Re: [patch] de(4) has not worked on 8-current since Feb 13 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Dec 2008 20:45:31 -0000 On Wednesday 10 December 2008 07:56:25 am WATANABE Kazuhiro wrote: > Hi, all. > > My de(4) NICs has not worked on 8-current since Feb 13. Try this patch to de(4) instead. It removes the alignment requirement for TX buffers since the 4-byte alignment is only required for RX. Index: if_de.c =================================================================== --- if_de.c (revision 185867) +++ if_de.c (working copy) @@ -4491,7 +4491,8 @@ /* Allocate memory for a single descriptor ring. */ static int tulip_busdma_allocring(device_t dev, tulip_softc_t * const sc, size_t count, - bus_size_t maxsize, int nsegs, tulip_ringinfo_t *ri, const char *name) + bus_size_t alignment, bus_size_t maxsize, int nsegs, tulip_ringinfo_t *ri, + const char *name) { size_t size; int error, i; @@ -4527,7 +4528,7 @@ } /* Allocate a tag for the data buffers. */ - error = bus_dma_tag_create(NULL, 4, 0, + error = bus_dma_tag_create(NULL, alignment, 0, BUS_SPACE_MAXADDR_32BIT, BUS_SPACE_MAXADDR, NULL, NULL, maxsize, nsegs, TULIP_DATA_PER_DESC, 0, NULL, NULL, &ri->ri_data_tag); if (error) { @@ -4586,8 +4587,8 @@ /* * Allocate space and dmamap for transmit ring. */ - error = tulip_busdma_allocring(dev, sc, TULIP_TXDESCS, TULIP_DATA_PER_DESC, - TULIP_MAX_TXSEG, &sc->tulip_txinfo, "transmit"); + error = tulip_busdma_allocring(dev, sc, 1, TULIP_TXDESCS, + TULIP_DATA_PER_DESC, TULIP_MAX_TXSEG, &sc->tulip_txinfo, "transmit"); if (error) return (error); @@ -4598,7 +4599,7 @@ * a waste in practice though as an ethernet frame can easily fit * in TULIP_RX_BUFLEN bytes. */ - error = tulip_busdma_allocring(dev, sc, TULIP_RXDESCS, MCLBYTES, 1, + error = tulip_busdma_allocring(dev, sc, 4, TULIP_RXDESCS, MCLBYTES, 1, &sc->tulip_rxinfo, "receive"); if (error) return (error); -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Wed Dec 10 21:27:42 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0EA19106567A; Wed, 10 Dec 2008 21:27:42 +0000 (UTC) (envelope-from keramida@freebsd.org) Received: from igloo.linux.gr (igloo.linux.gr [62.1.205.36]) by mx1.freebsd.org (Postfix) with ESMTP id 91DCA8FC25; Wed, 10 Dec 2008 21:27:41 +0000 (UTC) (envelope-from keramida@freebsd.org) Received: from kobe.laptop (adsl22-219.kln.forthnet.gr [77.49.149.219]) (authenticated bits=128) by igloo.linux.gr (8.14.3/8.14.3/Debian-5) with ESMTP id mBALRWAt004298 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 10 Dec 2008 23:27:38 +0200 Received: from kobe.laptop (kobe.laptop [127.0.0.1]) by kobe.laptop (8.14.3/8.14.3) with ESMTP id mBALRWqG006915; Wed, 10 Dec 2008 23:27:32 +0200 (EET) (envelope-from keramida@freebsd.org) Received: (from keramida@localhost) by kobe.laptop (8.14.3/8.14.3/Submit) id mBALRVKI006914; Wed, 10 Dec 2008 23:27:31 +0200 (EET) (envelope-from keramida@freebsd.org) From: Giorgos Keramidas To: "Michael Proto" References: <1de79840812092149t4d212027o2c908635419fa838@mail.gmail.com> Date: Wed, 10 Dec 2008 23:27:31 +0200 In-Reply-To: <1de79840812092149t4d212027o2c908635419fa838@mail.gmail.com> (Michael Proto's message of "Wed, 10 Dec 2008 00:49:58 -0500") Message-ID: <87zlj390vw.fsf@kobe.laptop> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-MailScanner-ID: mBALRWAt004298 X-Hellug-MailScanner: Found to be clean X-Hellug-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-4.301, required 5, autolearn=not spam, ALL_TRUSTED -1.80, AWL 0.10, BAYES_00 -2.60) X-Hellug-MailScanner-From: keramida@freebsd.org X-Spam-Status: No Cc: FreeBSD Current , freebsd-questions@freebsd.org Subject: Re: behavioral change of "read" builtin for sh on 8-CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Dec 2008 21:27:42 -0000 Hi Michael, This looks like a bug in 8.0-CURRENT. Can you please file a bug report and include the text you sent below? On Wed, 10 Dec 2008 00:49:58 -0500, "Michael Proto" wrote: > I've noticed a behavioral difference of the "read" builtin statement within > /bin/sh on CURRENT and I'm hoping someone can point me in the right > direction on how to restore the old behavior. > > I have a /bin/sh script that accepts input for IP address information: > > #!/bin/sh > set -x > DEFINT=vr0 > DEFIP=192.168.0.1 > DEFMASK=255.255.255.0 > read -p "Enter network interface [$DEFINT]: " -t 5 INT > read -p "Enter IP address [$DEFIP]: " -t 5 IP > read -p "Enter netmask [$DEFMASK]: " -t 5 MASK > echo ${INT:=$DEFINT} : ${IP:=$DEFIP}/${MASK:=$DEFMASK} > > This script waits for terminal input for each of the above variables (INT, > IP, MASK) and defaults to a script-provided value if no input is entered in > 5 seconds for each variable. On 6.x and 7.x if I simply hit Enter at the > prompt (and don't provide any input) no value is assigned to the variable so > my INT, IP, and MASK variables are set to null and the parameter > substitution of the DEF* variables works as expected. > > On 8-CURRENT if I hit Enter with no input at the prompt the system seems to > recognize the newline as input and continues to sit there until I hit Enter > again. When I do this there appears to be a strange unprintable value > assigned to the INT, IP, and MASK variables yet the variable subsitution > doesn't work correctly. > > The man page on sh lists the following behavior for read: > > read [-p prompt] [-t timeout] [-er] variable ... > The prompt is printed if the -p option is specified and the > stan- > dard input is a terminal. Then a line is read from the > standard > input. The trailing newline is deleted from the line and the > line is split as described in the section on White Space > Splitting (Field Splitting) above, and the pieces are assigned > to > the variables in order. If there are more pieces than > variables, > the remaining pieces (along with the characters in IFS that > sepa- > rated them) are assigned to the last variable. If there are > more > variables than pieces, the remaining variables are assigned the > null string. > > > As I interpret this, read should delete the trailing newline and assign a > null value since there is is no "input" before the newline. Then the > variable substitution should take over and assign the DEF* variables > appropriately. 6 and 7 follow this but 8 does not. > > Here's the output of the script (with set -x) to help show what I'm seeing. > > This is on 6 and 7: > > + DEFINT=vr0 > + DEFIP=192.168.0.1 > + DEFMASK=255.255.255.0 > + read -p Enter network interface [vr0]: -t 5 INT > Enter network interface [vr0]: > + read -p Enter IP address [192.168.0.1]: -t 5 IP > Enter IP address [192.168.0.1]: > + read -p Enter netmask [255.255.255.0]: -t 5 MASK > Enter netmask [255.255.255.0]: > + echo vr0 : 192.168.0.1/255.255.255.0 > vr0 : 192.168.0.1/255.255.255.0 > > > And this is what I see with 8: > > + DEFINT=vr0 > + DEFIP=192.168.0.1 > + DEFMASK=255.255.255.0 > + read -p Enter network interface [vr0]: -t 5 INT > Enter network interface [vr0]: > + read -p Enter IP address [192.168.0.1]: -t 5 IP > Enter IP address [192.168.0.1]: > + read -p Enter netmask [255.255.255.0]: -t 5 MASK > Enter netmask [255.255.255.0]: > /: cho > /: > > Strange that the "echo" statement is missing the first "e" character in the > debug output. > > Even stranger on 8-CURRENT, if I *do* enter input before the newline (say I > change the IP address or the network interface), the first character is not > echoed back to the screen but is still saved to the variable. Here's an > example when I run the script and provide input at each prompt: > > + DEFINT=vr0 > + DEFIP=192.168.0.1 > + DEFMASK=255.255.255.0 > + read -p Enter network interface [vr0]: -t 5 INT > Enter network interface [vr0]: r0 > + read -p Enter IP address [192.168.0.1]: -t 5 IP > Enter IP address [192.168.0.1]: 92.168.0.1 > + read -p Enter netmask [255.255.255.0]: -t 5 MASK > Enter netmask [255.255.255.0]: 55.255.255.0 > + echo br0 : 192.168.0.1/255.255.255.0 > br0 : 192.168.0.1/255.255.255.0 > + echo ifconfig br0 inet 192.168.0.1 netmask 255.255.255.0 > > Notice that when I'm prompted, the first character doesn't echo but is still > saved in the variable. > > > Does anyone else see this same behavior? Any ideas on how to reset it back > to how it works in STABLE? I'm not doing anything special with IFS so I'm > stumped on how to troubleshoot this. > > > > Thanks, > Proto > _______________________________________________ > freebsd-questions@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to "freebsd-questions-unsubscribe@freebsd.org" > -- From owner-freebsd-current@FreeBSD.ORG Wed Dec 10 21:28:25 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CD7091065670 for ; Wed, 10 Dec 2008 21:28:25 +0000 (UTC) (envelope-from uspoerlein@gmail.com) 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 599E28FC25 for ; Wed, 10 Dec 2008 21:28:25 +0000 (UTC) (envelope-from uspoerlein@gmail.com) Received: from roadrunner.spoerlein.net (e180148116.adsl.alicedsl.de [85.180.148.116]) by acme.spoerlein.net (8.14.2/8.14.2) with ESMTP id mBALSNUH018941 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 10 Dec 2008 22:28:24 +0100 (CET) (envelope-from uspoerlein@gmail.com) Received: from roadrunner.spoerlein.net (localhost [127.0.0.1]) by roadrunner.spoerlein.net (8.14.3/8.14.3) with ESMTP id mBALSMMH007257 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 10 Dec 2008 22:28:22 +0100 (CET) (envelope-from uspoerlein@gmail.com) Received: (from uqs@localhost) by roadrunner.spoerlein.net (8.14.3/8.14.3/Submit) id mBALSLqp007256 for current@freebsd.org; Wed, 10 Dec 2008 22:28:21 +0100 (CET) (envelope-from uspoerlein@gmail.com) Date: Wed, 10 Dec 2008 22:28:21 +0100 From: Ulrich Spoerlein To: current@freebsd.org Message-ID: <20081210212821.GF1494@roadrunner.spoerlein.net> Mail-Followup-To: current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.18 (2008-05-17) Cc: Subject: ZFS backup advice X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Dec 2008 21:28:25 -0000 Servus, I'm looking for advice on setting up a ZFS based hard disk backup solution. Given a large set of data, with perhaps 500MB data changes per day and two 1 TB disks, which option would you prefer and why: A) Separate ZFS pools on both disk. Using zfs send|recv to transfer snapshots every 2-3 days, taking the "backup" pool offline in the time in between (to keep the disk safe from surges, etc). or B) One ZFS mirror pool across both disk, resilvering the second half every 2-3 days and then detaching it again. Right now I'm favouring option A, as I can selectively "backup" part of the pool (excluding /usr/obj for example, though it is <10% of total capacity, so not a strong point), can use compression on the backup-pool and can potentially keep more snapshots on it than on the live pool. It should also be faster than resilvering the mirror every other day. I'd use B, iff ZFS is able to "self-heal" defective sectors on one mirror half, even if it is not fully resilvered. Does anyone know if this is possible? Cheers, Ulrich Spoerlein -- It is better to remain silent and be thought a fool, than to speak, and remove all doubt. From owner-freebsd-current@FreeBSD.ORG Wed Dec 10 21:41:38 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3FBA0106564A for ; Wed, 10 Dec 2008 21:41:38 +0000 (UTC) (envelope-from admin@lissyara.su) Received: from hosting.lissyara.su (hosting.lissyara.su [77.221.149.162]) by mx1.freebsd.org (Postfix) with ESMTP id B27278FC16 for ; Wed, 10 Dec 2008 21:41:37 +0000 (UTC) (envelope-from admin@lissyara.su) Received: from [89.178.149.178] (port=54916 helo=acer.lissyara.int.otradno.ru) by hosting.lissyara.su with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LAWoK-0007YG-3j for freebsd-current@freebsd.org; Thu, 11 Dec 2008 00:41:36 +0300 Message-ID: <4940378F.9040701@lissyara.su> Date: Thu, 11 Dec 2008 00:41:35 +0300 From: Alex Keda User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; ru-RU; rv:1.8.1.18) Gecko/20081124 Thunderbird/2.0.0.18 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Description: if spam count > 60 - this is spam X-Spam-Count: 0 X-Descriptions: powered by www.lissyara.su X-Bounce-ID: hosting.lissyara.su Subject: bge && route problem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Dec 2008 21:41:38 -0000 before last update (2 days ago) I have problem: when many packets run over interface - network inaccessible - no ping, nothing not works. frequently I see problem when update source three with fast cvsup mirror. But - no problem with slow mirror. if I down/up interface - all OK short time - 20-30 seconds. After last update, problem still, but, system hang after ifconfig bge0 down && ifconfig bge0 up & I cannot correct shutdown - only reset. when system hang, 1 process get all cpu resources: ps -auxww | grep rout root 1545 100,0 0,0 2704 912 ?? R 0:21 0:00,73 route add default 192.168.250.254 ps -auxww | grep ifconf root 1569 0,0 0,1 7912 1392 v1 L 0:22 0:00,00 ifconfig bge0 down root 1572 0,0 0,1 7912 1392 v1 L 0:23 0:00,00 ifconfig bge0 down root 1575 0,0 0,1 7912 1392 v1 L 0:23 0:00,00 ifconfig bge0 down root 1578 0,0 0,1 7912 1392 v1 L 0:23 0:00,00 ifconfig bge0 down network unrecheable if, before first ifconfig bge0 down && ifconfig bge0 up & I connect to network with ssh|another tcp services - system hang later 5-10 seconds after down/up interface acer# uname -a FreeBSD acer.lissyara.int.otradno.ru 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Mon Dec 8 23:41:04 MSK 2008 lissyara@acer.lissyara.int.otradno.ru:/usr/obj/usr/src/sys/color-console amd64 acer# acer# ifconfig bge0 bge0: flags=8843 metric 0 mtu 1500 options=9b ether 00:1f:29:89:38:f3 inet 192.168.250.1 netmask 0xffffff00 broadcast 192.168.250.255 media: Ethernet autoselect (100baseTX ) status: active acer# acer# dmesg | grep bge bge0: mem 0xd0000000-0xd000ffff irq 16 at device 0.0 on pci16 miibus0: on bge0 bge0: Ethernet address: 00:1f:29:89:38:f3 bge0: [ITHREAD] acer# bge0@pci0:16:0:0: class=0x020000 card=0x30c2103c chip=0x171314e4 rev=0x02 hdr=0x00 vendor = 'Broadcom Corporation' device = 'NetLink BCM5906M Fast Ethernet PCIe' class = network subclass = ethernet From owner-freebsd-current@FreeBSD.ORG Wed Dec 10 21:47:36 2008 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B7C671065672 for ; Wed, 10 Dec 2008 21:47:36 +0000 (UTC) (envelope-from rdivacky@lev.vlakno.cz) Received: from vlakno.cz (77-93-215-190.static.masterinter.net [77.93.215.190]) by mx1.freebsd.org (Postfix) with ESMTP id 3A32D8FC14 for ; Wed, 10 Dec 2008 21:47:35 +0000 (UTC) (envelope-from rdivacky@lev.vlakno.cz) Received: from localhost (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id 0397E9CB1BC; Wed, 10 Dec 2008 22:42:51 +0100 (CET) X-Virus-Scanned: amavisd-new at vlakno.cz Received: from vlakno.cz ([127.0.0.1]) by localhost (lev.vlakno.cz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7vc9ucPgOw5Y; Wed, 10 Dec 2008 22:42:48 +0100 (CET) Received: from lev.vlakno.cz (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id 99B249CB22D; Wed, 10 Dec 2008 22:42:48 +0100 (CET) Received: (from rdivacky@localhost) by lev.vlakno.cz (8.14.2/8.14.2/Submit) id mBALgm77070074; Wed, 10 Dec 2008 22:42:48 +0100 (CET) (envelope-from rdivacky) Date: Wed, 10 Dec 2008 22:42:48 +0100 From: Roman Divacky To: Robert Watson Message-ID: <20081210214248.GA69246@freebsd.org> References: <20081210164345.GA32188@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: current@FreeBSD.org Subject: Re: [PANIC]: rw_lock panic in in_pcballoc() in r185864 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Dec 2008 21:47:36 -0000 On Wed, Dec 10, 2008 at 07:23:49PM +0000, Robert Watson wrote: > On Wed, 10 Dec 2008, Roman Divacky wrote: > > >#9 0xc06bd28b in calltrap () at ../../../i386/i386/exception.s:165 > >#10 0xc0528cc9 in _rw_wlock_hard (rw=0xc45a00a4, tid=3293569600, file=0x0, > > line=0) at ../../../kern/kern_rwlock.c:616 > >#11 0xc05eae42 in in_pcballoc (so=0xc459e000, pcbinfo=0xc0794b40) > > at ../../../netinet/in_pcb.c:238 > >#12 0xc060b403 in udp_attach (so=0xc459e000, proto=0, td=0xc44fe240) > > at ../../../netinet/udp_usrreq.c:1131 > >#13 0xc0586df5 in socreate (dom=2, aso=0xc3e77c6c, type=2, proto=0, > >#14 0xc058d974 in socket (td=0xc44fe240, uap=0xc3e77cf8) > >---Type to continue, or q to quit---Dec 10 17:29:23 > >witten log > >in: ROOT LOGIN (root) ON ttyv1 > > > > at ../../../kern/uipc_syscalls.c:178 > >#15 0xc06d8010 in syscall (frame=0xc3e77d38) at > >../../../i386/i386/trap.c:1076 > >#16 0xc06bd320 in Xint0x80_syscall () at ../../../i386/i386/exception.s:261 > >#17 0x00000033 in ?? () > >Previous frame inner to this frame (corrupt stack?) > > > >(kgdb) p *pcbinfo > >$2 = {ipi_listhead = 0xc0794b24, ipi_count = 1, ipi_hashbase = 0xc42fe000, > > ipi_hashmask = 127, ipi_porthashbase = 0xc42fce00, ipi_porthashmask = 127, > > ipi_lastport = 0, ipi_lastlow = 0, ipi_lasthi = 0, ipi_zone = 0xc1471360, > > ipi_gencnt = 0, ipi_lock = {lock_object = {lo_name = 0xc0713b87 "udp", > > lo_flags = 69926928, lo_data = 0, lo_witness = 0x0}, > > rw_lock = 3293569600}, ipi_pspare = { > >(kgdb) p *pcbinfo->ipi_zone > >$4 = {uz_name = 0xc0716712 "udpcb", uz_lock = 0xc147ed88, > > uz_keg = 0xc147ed80, uz_link = {le_next = 0x0, le_prev = 0xc147eda8}, > > uz_full_bucket = {lh_first = 0x0}, uz_free_bucket = {lh_first = 0x0}, > > uz_ctor = 0, uz_dtor = 0, uz_init = 0, uz_fini = 0, uz_allocs = 0, > > uz_frees = 0, uz_fails = 0, uz_fills = 0, uz_count = 23, uz_cpu = {{ > > uc_freebucket = 0x0, uc_allocbucket = 0x0, uc_allocs = 0, > > uc_frees = 0}}} > > > >the code tries to rw_rwlock() the inp->inp_lock, the inp is allocated from > >an UMA zone which has no constructor and in the in_pcballoc() the rwlock > >is never initialized. I believe that's why it crashes > > > >can someone confirm/fix that? > > Hmm. I disagree with the diagnosis, although clearly there's a problem > here of some sort since panicking is, well, bad. Each protocol using the > inpcb framework provides its own UMA zone and is responsible for > initializing the lock on the inpcb when memory is first pulled into the > cache. For UDP, that occurs in udp_inpcb_init(), the init function passed > into uma_zcreate() in udp_init(). Notice that when in_pcballoc() zeroes > the inpcb, it stops at inp_zero_size, which is before inp_lock, and since > the inpcb zone for UDP is set to be a no-free zone, there's no INP lock > destroy. hm... I wondered how it could work before that.... anyway, I got this crash > So, given that this code has worked for quite a long time for many people, > this really raises two questions: (1) how reproduceable is this and at what > point does it kick in during the boot/runtime, and (2) when did this start > happening in terms of updating your source? ad (1): I get this on every boot when dhcp kicks in (it uses udp I believe) ie. 100% reproducible ad (2): Mon Dec 8 23:02:27 CET 2008 kernel (svn up-dated at most 10 minutes before that) works 100% ok I have the crash dump and the kernel at hand so I can do basically anything you ask me to do :) anything I can provide? thnx roman From owner-freebsd-current@FreeBSD.ORG Wed Dec 10 22:14:03 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C985F1065670 for ; Wed, 10 Dec 2008 22:14:03 +0000 (UTC) (envelope-from jille@quis.cx) Received: from istud.quis.cx (ip83-113-174-82.adsl2.static.versatel.nl [82.174.113.83]) by mx1.freebsd.org (Postfix) with ESMTP id 823228FC12 for ; Wed, 10 Dec 2008 22:14:03 +0000 (UTC) (envelope-from jille@quis.cx) Received: from [192.168.1.4] (ille [192.168.1.4]) by istud.quis.cx (Postfix) with ESMTP id CAA935C20 for ; Wed, 10 Dec 2008 23:14:01 +0100 (CET) Message-ID: <49403F27.3020605@quis.cx> Date: Wed, 10 Dec 2008 23:13:59 +0100 From: Jille Timmermans User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: FreeBSD Current X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: Panic when loading if_ath X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Dec 2008 22:14:03 -0000 Hello list, A panic with if_ath (Atheros 2413) root /sys/modules/ath_rate_amrr# make root /sys/modules/ath_rate_amrr# make install root ~# kldload if_ath warning: KLD '/boot/kernel/if_ath.ko' is newer than the linker.hints file ath0: mem 0xc9000000-0xc900ffff irq 18 at device 1.0 on pci5 ath0: [ITHREAD] Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x0 fault code = supervisor read, page not present instruction pointer = 0x20:0x0 stack pointer = 0x28:0xc43cc748 frame pointer = 0x28:0xc43cc75c code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current_process = 993 (kldload) trap number = 12 panic: page fault cpuid = 0 [dump] [reboot] WARNING: /tmp was not properly dismounted WARNING: /usr was not properly dismounted WARNING: /var was not properly dismounted Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x5bbfe499 fault code = supervisor read, page not present instruction pointer = 0x20:0xc0684c37 stack pointer = 0x28:0xc4364a5c frame pointer = 0x28:0xc4364c28 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 136 (ifconfig) trap number = 12 panic: page fault cpuid = 0 [a few crashes later, when it comes to mind to get a backtrace] root ~# kldload ath_rate root ~# kldload if_ath ath0: mem 0xc9000000-0xc900ffff irq 18 at device 1.0 on pci5 ath0: [ITHREAD] [panic] uart_z8530_class(c4ac5000, 0, 1, 1, c4390000, ...) at 0 ar5212Attach(1a, c48b0000, 1, c4389000, c437c8ec, ...) at ar5212Attach+0x211 ath_hal_attach(1a, c48b0000, 1, c4389000, c437c8ec, ...) at ath_hal_attach+0x56 ath_attach(1a, c48b0000, 3, c437c940, ffffffff, ...) at ath_attach+0x9e ath_pci_attach(c46bb200, c4823854, c09fcf80, c099dc60, 80000000, ...) at ath_pci_attach+0x332 device_attach([snip]) at device_attach+0x36f device_probe_and_attach([snip) at ...+0x43 pci_driver_added([snip]) at +0x104 devclass_add_driver([snip]) at +0xe8 driver_module_handler([snip]) at +0x79 module_register_init() linker_load_module() kern_kldload() (Please don't tell me you want any of that snips.) Any extra information I can provide to you ? I am willing to help debugging / crashing. -- Jille From owner-freebsd-current@FreeBSD.ORG Wed Dec 10 22:15:45 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6E4071065675; Wed, 10 Dec 2008 22:15:45 +0000 (UTC) (envelope-from marius@nuenneri.ch) Received: from rn-out-0910.google.com (rn-out-0910.google.com [64.233.170.190]) by mx1.freebsd.org (Postfix) with ESMTP id C132E8FC14; Wed, 10 Dec 2008 22:15:44 +0000 (UTC) (envelope-from marius@nuenneri.ch) Received: by rn-out-0910.google.com with SMTP id j71so792741rne.12 for ; Wed, 10 Dec 2008 14:15:43 -0800 (PST) Received: by 10.90.28.20 with SMTP id b20mr1181978agb.60.1228947343685; Wed, 10 Dec 2008 14:15:43 -0800 (PST) Received: by 10.90.73.15 with HTTP; Wed, 10 Dec 2008 14:15:43 -0800 (PST) Message-ID: Date: Wed, 10 Dec 2008 23:15:43 +0100 From: "=?ISO-8859-1?Q?Marius_N=FCnnerich?=" To: freebsd-geom@freebsd.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: Cc: Alexander@leidinger.net, jb@freebsd.org, FreeBSD Current Subject: Re: DTrace probes for geom_kern, geom_io and geom_event X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Dec 2008 22:15:45 -0000 current CC'ed, maybe there are some people interested in DTrace that don't read geom. On Thu, Dec 4, 2008 at 9:41 PM, Marius N=FCnnerich wro= te: > Hi, > > I wrote a bunch of DTrace probes for the core geom files mentioned in > the subject. The patch for current is available at > http://nuenneri.ch/freebsd/geom_probes.patch > > Anyone interested in testing them? Just apply the patch, add options > KDTRACE_HOOKS to your kernel and build it like this: > # make WITH_CTF=3D1 KERNCONF=3DYOURKERNEL buildkernel installkernel > > After reboot you can > # kldload dtraceall > and see the new probes with > # dtrace -lP geom > > A sample script: > #!/usr/sbin/dtrace -s > #pragma D option quiet > > geom::: > { > @geom[execname, probemod, probefunc, probename] =3D count(); > @geom_all[execname, probemod, probefunc, probename] =3D count(); > } > > tick-10sec > { > normalize(@geom, 10) > printa("%@8u %@8u %12s %s:%s:%s\n", @geom_all, @geom); > printf("\n"); > clear(@geom); > } > > This is hand copied. You can chmod 755 and run it. > > I'm not sure how to handle the opt_kdtrace.h case in geom.h, see patch li= ne 842. > Any comments on the patch? > > @phk: Are you interested in committing this when there are no > complaints? Are you interested in more probes? After some tips from Alexander Leidinger I updated the patch, new version h= ere: http://nuenneri.ch/freebsd/geom_probes2.patch There are some questions I'd like to discuss: 1. I wrote the SDT_PROBE_DEFINEs right before the function definition, I know this violates the usual style as that stuff would normally belong to the top of the file. I think in this case it would be worthwhile to break with this tradition 2. Should I use the full function name for the probes (with the g_ prefix) even though it's defined under the provider geom 3. Should there be a probe for every switch case in g_io_check? I think this won't work with the fall-through that is used right now 4. Alexander proposed to change the module name kern to core. I'm not sure about this as kern refers to the filename, like io and event do 5. I'm thinking about defining a G_TRACE macro for SDT_PROBE(geom, ...) 6. Does anybody know of a way to probe functions with varargs properly? Like g_trace 7. What about g_bioq_(un)lock functions, I just added one probe for it, I do not really see a point in adding entry and return probes (they are there with FBT anyway). This is consistent with g_topology_lock etc. What about making macros of the two functions like g_topology_lock 8. What about adding macros for (un)locking other locks like g_eventlock, so one could add probes and trace them 9. Writing hundreds of entry and return probes is boring, especially as there is the FBT provider. Maybe it's possible to give the FBT probes better names like geom:io:g_io_schedule_down:entry instead of fbt:kernel:g_io_schedule:entry. Every FBT probe has a provider of fbt und module of kernel right now. One also has to define the argument types which I think FBT figures out by itself. If this would work we could concentrate on adding SDT probes to interesting places inside of functions or macros Bye Marius From owner-freebsd-current@FreeBSD.ORG Wed Dec 10 22:34:55 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A3A81106564A for ; Wed, 10 Dec 2008 22:34:55 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id 4E1578FC1B for ; Wed, 10 Dec 2008 22:34:55 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from trouble.errno.com (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id mBAMYs0J072711 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 10 Dec 2008 14:34:54 -0800 (PST) (envelope-from sam@freebsd.org) Message-ID: <4940440E.9050805@freebsd.org> Date: Wed, 10 Dec 2008 14:34:54 -0800 From: Sam Leffler Organization: FreeBSD Project User-Agent: Thunderbird 2.0.0.9 (X11/20071125) MIME-Version: 1.0 To: Jille Timmermans References: <49403F27.3020605@quis.cx> In-Reply-To: <49403F27.3020605@quis.cx> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-DCC--Metrics: ebb.errno.com; whitelist Cc: FreeBSD Current Subject: Re: Panic when loading if_ath X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Dec 2008 22:34:55 -0000 Jille Timmermans wrote: > Hello list, > > A panic with if_ath (Atheros 2413) > > root /sys/modules/ath_rate_amrr# make > root /sys/modules/ath_rate_amrr# make install > root ~# kldload if_ath > warning: KLD '/boot/kernel/if_ath.ko' is newer than the linker.hints file > ath0: mem 0xc9000000-0xc900ffff irq 18 at device 1.0 on pci5 > ath0: [ITHREAD] > > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address = 0x0 > fault code = supervisor read, page not present > instruction pointer = 0x20:0x0 > stack pointer = 0x28:0xc43cc748 > frame pointer = 0x28:0xc43cc75c > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current_process = 993 (kldload) > trap number = 12 > panic: page fault > cpuid = 0 > > [dump] > [reboot] > WARNING: /tmp was not properly dismounted > WARNING: /usr was not properly dismounted > WARNING: /var was not properly dismounted > > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address = 0x5bbfe499 > fault code = supervisor read, page not present > instruction pointer = 0x20:0xc0684c37 > stack pointer = 0x28:0xc4364a5c > frame pointer = 0x28:0xc4364c28 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 136 (ifconfig) > trap number = 12 > panic: page fault > cpuid = 0 > > [a few crashes later, when it comes to mind to get a backtrace] > root ~# kldload ath_rate > root ~# kldload if_ath > ath0: mem 0xc9000000-0xc900ffff irq 18 at device 1.0 on pci5 > ath0: [ITHREAD] > [panic] > uart_z8530_class(c4ac5000, 0, 1, 1, c4390000, ...) at 0 > ar5212Attach(1a, c48b0000, 1, c4389000, c437c8ec, ...) at ar5212Attach+0x211 > ath_hal_attach(1a, c48b0000, 1, c4389000, c437c8ec, ...) at > ath_hal_attach+0x56 > ath_attach(1a, c48b0000, 3, c437c940, ffffffff, ...) at ath_attach+0x9e > ath_pci_attach(c46bb200, c4823854, c09fcf80, c099dc60, 80000000, ...) at > ath_pci_attach+0x332 > device_attach([snip]) at device_attach+0x36f > device_probe_and_attach([snip) at ...+0x43 > pci_driver_added([snip]) at +0x104 > devclass_add_driver([snip]) at +0xe8 > driver_module_handler([snip]) at +0x79 > module_register_init() > linker_load_module() > kern_kldload() > > (Please don't tell me you want any of that snips.) > > Any extra information I can provide to you ? > I am willing to help debugging / crashing. > > Try building the driver into the kernel. Also use sample and not amrr. Sam From owner-freebsd-current@FreeBSD.ORG Wed Dec 10 22:58:15 2008 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1BD0A1065675; Wed, 10 Dec 2008 22:58:15 +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 E8AF78FC12; Wed, 10 Dec 2008 22:58:14 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTP id 89B4846B38; Wed, 10 Dec 2008 17:58:14 -0500 (EST) Date: Wed, 10 Dec 2008 22:58:14 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Roman Divacky In-Reply-To: <20081210214248.GA69246@freebsd.org> Message-ID: References: <20081210164345.GA32188@freebsd.org> <20081210214248.GA69246@freebsd.org> User-Agent: Alpine 1.10 (BSF 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: current@FreeBSD.org Subject: Re: [PANIC]: rw_lock panic in in_pcballoc() in r185864 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Dec 2008 22:58:15 -0000 On Wed, 10 Dec 2008, Roman Divacky wrote: > hm... I wondered how it could work before that.... anyway, I got this crash Well, nothing says it still works that way, that's just the theory :-). >> So, given that this code has worked for quite a long time for many people, >> this really raises two questions: (1) how reproduceable is this and at what >> point does it kick in during the boot/runtime, and (2) when did this start >> happening in terms of updating your source? > > ad (1): I get this on every boot when dhcp kicks in (it uses udp I believe) > ie. 100% reproducible > > ad (2): Mon Dec 8 23:02:27 CET 2008 kernel (svn up-dated at most 10 minutes > before that) works 100% ok > > I have the crash dump and the kernel at hand so I can do basically anything > you ask me to do :) anything I can provide? Well, to be honest, the easiest thing to do may be to play the binary search game to narrow down the point where the problem starts a bit more. There are a few kinds of things that might lead to this problem -- perhaps we (I?) mucked up initialization of the inpcb with recent changes, or a virtualization-related change tripped something up, or a locking/scheduler change or such. The other thing that would be helpful is a dump of *inp so that we can see what state inp_lock is in. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-current@FreeBSD.ORG Wed Dec 10 23:54:23 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 14FE71065676; Wed, 10 Dec 2008 23:54:23 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.28]) by mx1.freebsd.org (Postfix) with ESMTP id 9234D8FC1B; Wed, 10 Dec 2008 23:54:22 +0000 (UTC) (envelope-from onemda@gmail.com) Received: by yx-out-2324.google.com with SMTP id 8so349615yxb.13 for ; Wed, 10 Dec 2008 15:54:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=LFC8NgYZByxJkMUd/TIK2615ymZFBdnhWt1lbEPo268=; b=ISwIv59683BsQpd91/P+TcmQ/Kdzew+tCuSV0PAOZkm2yk7XQ8ns5/+1VhD59nFHmc Ri2OzvFVfQ09I+qCIFNaFFzm4th77mCAepTCsXti13Q0b/uoBebQ0TKD3Mt0hj7t8Ifz a6z9i/8imoElNXFHLOJlXgExsTAWYNvbqN7S0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=pWw+oFZLbp9p2bwZp0mDuy8Vdm/nPQNn6QiYhPmrXqX7GD8nKVBm5+rE1YYUTkFav5 owz729DgzfakBy9pnYMwQz2Nk7ZdIa1m67HZmD8e/S1GMDL/2jY+9M8nnq4+GY8KcLOn sN/q2/5T+1d6gxMhX4hLaO6dReChO9uDE1dUY= Received: by 10.231.16.75 with SMTP id n11mr26519iba.40.1228953260996; Wed, 10 Dec 2008 15:54:20 -0800 (PST) Received: by 10.231.12.5 with HTTP; Wed, 10 Dec 2008 15:54:20 -0800 (PST) Message-ID: <3a142e750812101554o656347f9w42c7486db4fc4a9e@mail.gmail.com> Date: Thu, 11 Dec 2008 00:54:20 +0100 From: "Paul B. Mahol" To: "John Baldwin" In-Reply-To: <200812101450.04638.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200811191510.53793.jhb@FreeBSD.org> <200812091602.10850.jhb@freebsd.org> <3a142e750812100922m553be9c6sdcd81d98c81c7ab4@mail.gmail.com> <200812101450.04638.jhb@freebsd.org> Cc: freebsd-current@freebsd.org Subject: Re: [PATCH] MPSAFE/LOOKUP_SHARED cd9660 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Dec 2008 23:54:23 -0000 On 12/10/08, John Baldwin wrote: > On Wednesday 10 December 2008 12:22:43 pm Paul B. Mahol wrote: >> On 12/9/08, John Baldwin wrote: >> > The RRIP stuff is all done in cd9660_vget_internal() under an exclusive >> > lock. >> > It could be a property of the ISO image. "PX" holds permissions (owner, >> > etc.). Do you get the same messages w/o the patch with the same ISO > image / >> > CD? >> > >> > -- >> > John Baldwin >> > >> >> I searched little for this message and found kern/63446 PR interesting > comment: >> >> Caused by cd9660_vnops.c rev. 1.77. VOP_READDIR returns bogus >> d_fileno, VFS_VGET on this value returns bogus vnode with zeroed > attributes. >> >> I think that whatever locking is done is done wrong. > > That issue isn't a locking issue, it's an issue with VOP_READDIR() using a > different meaning for i-node numbers than VFS_VGET(), and would happen > regardless of any Giant or vnode locking. Yes, I know that that issue/PR doesnt have anything to do with locking. But displaying bogus messages and still having functional cd9660 for general use means that something is not correctly locked. -- Paul From owner-freebsd-current@FreeBSD.ORG Thu Dec 11 00:02:48 2008 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 66BCC1065673 for ; Thu, 11 Dec 2008 00:02:48 +0000 (UTC) (envelope-from bsam@ipt.ru) Received: from services.ipt.ru (services.ipt.ru [194.62.233.110]) by mx1.freebsd.org (Postfix) with ESMTP id E5CAA8FC1B for ; Thu, 11 Dec 2008 00:02:47 +0000 (UTC) (envelope-from bsam@ipt.ru) Received: from bb.ipt.ru ([194.62.233.89]) by services.ipt.ru with esmtp (Exim 4.54 (FreeBSD)) id 1LAZ0s-0006Rl-QQ; Thu, 11 Dec 2008 03:02:42 +0300 To: rea-fbsd@codelabs.ru References: <92804393@bb.ipt.ru> <26722819@bb.ipt.ru> From: Boris Samorodov Date: Thu, 11 Dec 2008 03:02:42 +0300 In-Reply-To: (Eygene Ryabinkin's message of "Wed\, 10 Dec 2008 18\:38\:00 +0300") Message-ID: <26719629@bb.ipt.ru> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-current@FreeBSD.org Subject: Re: Timeda 8-multiport adapter: only 2 ports available X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Dec 2008 00:02:48 -0000 Eygene Ryabinkin writes: > Boris, good day. > > Wed, Dec 10, 2008 at 05:13:48PM +0300, Boris Samorodov wrote: >> Boris Samorodov writes: >> >> > I've got a Sunix PCI Serial 8-channel Multiport adapter (Timedia chipset): >> > ----- >> > puc0@pci0:5:2:0: class=0x070002 card=0x40661409 chip=0x71681409 rev=0x01 hdr=0x00 >> > vendor = 'Timedia Technology Co Ltd' >> > device = '40371409 PCI / ISA Asynchronous UART Signal Chips Solution' >> >> Actually the card is 4066, while 4037 (according to pucdata.c) is indeed >> a dual-port card. May be the card is wrongly interpreted by the OS? > > pciconf just don't know about 4066, so is prints what it has in the > database. This is irrelevant to the driver -- it discovers the correct > chip with 8 ports: > >> > puc0: port 0xec00-0xec1f,0xe880-0xe88f,0xe800-0xe807,0xe480-0xe487,0xe400-0xe407,0xe080-0xe087 irq 18 at device 2.0 on pci5 >> > puc0: Reserved 0x20 bytes for rid 0x10 type 4 at 0xec00 >> > puc0: Reserved 0x10 bytes for rid 0x14 type 4 at 0xe880 >> > puc0: Reserved 0x8 bytes for rid 0x18 type 4 at 0xe800 >> > puc0: Reserved 0x8 bytes for rid 0x1c type 4 at 0xe480 >> > puc0: Reserved 0x8 bytes for rid 0x20 type 4 at 0xe400 >> > puc0: Reserved 0x8 bytes for rid 0x24 type 4 at 0xe080 >> > puc0: [FILTER] >> > uart4: <16550 or compatible> on puc0 >> > uart4: [FILTER] >> > uart4: fast interrupt >> > uart5: <16550 or compatible> on puc0 >> > uart5: [FILTER] >> > uart5: fast interrupt >> > ----- > > Judging by this output, the 6 ports that got their reservations at > dev/pci/pci.c are the ones that aren't recognized by uart. You may need > to add trace printfs to uart_puc_probe (uart_bus_puc.c) and to > uart_bus_probe (uart_core.c), just around the register resource > allocator. This should show what devices are passed to the probe > routines and which are rejected. Be sure to include 'rid' values to > your debug output to get the idea what ports we're speaking about. Seems that just the same card should work: http://lists.freebsd.org/pipermail/freebsd-stable/2008-May/042505.html I've added some diagnistic. But 'rid' is not what you want, I guess: ----- puc0: port 0xec00-0xec1f,0xe880-0xe88f,0xe800-0xe807,0xe480-0xe487,0xe400-0xe407,0xe080-0xe087 irq 18 at device 2.0 on pci5 puc0: Reserved 0x20 bytes for rid 0x10 type 4 at 0xec00 puc0: Reserved 0x10 bytes for rid 0x14 type 4 at 0xe880 puc0: Reserved 0x8 bytes for rid 0x18 type 4 at 0xe800 puc0: Reserved 0x8 bytes for rid 0x1c type 4 at 0xe480 puc0: Reserved 0x8 bytes for rid 0x20 type 4 at 0xe400 puc0: Reserved 0x8 bytes for rid 0x24 type 4 at 0xe080 puc0: [FILTER] uart4: uart_puc_probe: type = 1, error = 0 uart4: uart_puc_probe: probing for uart bus uart4: uart_bus_probe: Entering uart4: /usr/src/sys/dev/uart/uart_core.c:374: continue with rid=0x0 ns8250_bus_probe: entering ns8250_probe: entering ns8250_probe: got IIR register: 0x1 ns8250_probe: got MCR register: 0x0 ns8250_probe: no errors, exiting ns8250_bus_probe:656: continue ns8250_bus_probe:664: continue ns8250_bus_probe:749: Reset FIFOs ns8250_bus_probe:752: FIFO count=16 ns8250_bus_probe:792: no errors, exiting uart4: uart_bus_probe: Uart probe returned 0 uart4: uart_bus_probe: exiting uart4: uart_puc_probe: type = 1, error = 0 uart4: uart_puc_probe: probing for uart bus uart4: uart_bus_probe: Entering uart4: /usr/src/sys/dev/uart/uart_core.c:374: continue with rid=0x0 ns8250_bus_probe: entering ns8250_probe: entering ns8250_probe: got IIR register: 0xc1 ns8250_probe: got MCR register: 0x8 ns8250_probe: no errors, exiting ns8250_bus_probe:656: continue ns8250_bus_probe:664: continue ns8250_bus_probe:749: Reset FIFOs ns8250_bus_probe:752: FIFO count=16 ns8250_bus_probe:792: no errors, exiting uart4: uart_bus_probe: Uart probe returned 0 uart4: uart_bus_probe: exiting uart4: <16550 or compatible> on puc0 uart4: [FILTER] uart4: fast interrupt uart5: uart_puc_probe: type = 1, error = 0 uart5: uart_puc_probe: probing for uart bus uart5: uart_bus_probe: Entering uart5: /usr/src/sys/dev/uart/uart_core.c:374: continue with rid=0x0 ns8250_bus_probe: entering ns8250_probe: entering ns8250_probe: got IIR register: 0x1 ns8250_probe: got MCR register: 0x0 ns8250_probe: no errors, exiting ns8250_bus_probe:656: continue ns8250_bus_probe:664: continue ns8250_bus_probe:749: Reset FIFOs ns8250_bus_probe:752: FIFO count=16 ns8250_bus_probe:792: no errors, exiting uart5: uart_bus_probe: Uart probe returned 0 uart5: uart_bus_probe: exiting uart5: uart_puc_probe: type = 1, error = 0 uart5: uart_puc_probe: probing for uart bus uart5: uart_bus_probe: Entering uart5: /usr/src/sys/dev/uart/uart_core.c:374: continue with rid=0x0 ns8250_bus_probe: entering ns8250_probe: entering ns8250_probe: got IIR register: 0xc1 ns8250_probe: got MCR register: 0x8 ns8250_probe: no errors, exiting ns8250_bus_probe:656: continue ns8250_bus_probe:664: continue ns8250_bus_probe:749: Reset FIFOs ns8250_bus_probe:752: FIFO count=16 ns8250_bus_probe:792: no errors, exiting uart5: uart_bus_probe: Uart probe returned 0 uart5: uart_bus_probe: exiting uart5: <16550 or compatible> on puc0 uart5: [FILTER] uart5: fast interrupt uart6: uart_puc_probe: type = 1, error = 0 uart6: uart_puc_probe: probing for uart bus uart6: uart_bus_probe: Entering uart6: /usr/src/sys/dev/uart/uart_core.c:374: continue with rid=0x0 ns8250_bus_probe: entering ns8250_probe: entering ns8250_probe: got IIR register: 0x1 ns8250_probe: got MCR register: 0x40 ns8250_probe: got MCR wrong register, exiting with ENXIO ns8250_bus_probe:645: error at ns8250_probe(), exiting, returning 6 uart6: uart_bus_probe: Uart probe returned 6 uart6: uart_bus_probe: exiting uart6: uart_puc_probe: type = 1, error = 0 uart6: uart_puc_probe: probing for uart bus uart6: uart_bus_probe: Entering uart6: /usr/src/sys/dev/uart/uart_core.c:374: continue with rid=0x0 ns8250_bus_probe: entering ns8250_probe: entering ns8250_probe: got IIR register: 0x1 ns8250_probe: got MCR register: 0x40 ns8250_probe: got MCR wrong register, exiting with ENXIO ns8250_bus_probe:645: error at ns8250_probe(), exiting, returning 6 uart6: uart_bus_probe: Uart probe returned 6 uart6: uart_bus_probe: exiting uart6: uart_puc_probe: type = 1, error = 0 uart6: uart_puc_probe: probing for uart bus uart6: uart_bus_probe: Entering uart6: /usr/src/sys/dev/uart/uart_core.c:374: continue with rid=0x0 ns8250_bus_probe: entering ns8250_probe: entering ns8250_probe: got IIR register: 0x1 ns8250_probe: got MCR register: 0x40 ns8250_probe: got MCR wrong register, exiting with ENXIO ns8250_bus_probe:645: error at ns8250_probe(), exiting, returning 6 uart6: uart_bus_probe: Uart probe returned 6 uart6: uart_bus_probe: exiting uart6: uart_puc_probe: type = 1, error = 0 uart6: uart_puc_probe: probing for uart bus uart6: uart_bus_probe: Entering uart6: /usr/src/sys/dev/uart/uart_core.c:374: continue with rid=0x0 ns8250_bus_probe: entering ns8250_probe: entering ns8250_probe: got IIR register: 0x1 ns8250_probe: got MCR register: 0x40 ns8250_probe: got MCR wrong register, exiting with ENXIO ns8250_bus_probe:645: error at ns8250_probe(), exiting, returning 6 uart6: uart_bus_probe: Uart probe returned 6 uart6: uart_bus_probe: exiting uart6: uart_puc_probe: type = 1, error = 0 uart6: uart_puc_probe: probing for uart bus uart6: uart_bus_probe: Entering uart6: /usr/src/sys/dev/uart/uart_core.c:374: continue with rid=0x0 ns8250_bus_probe: entering ns8250_probe: entering ns8250_probe: got IIR register: 0x1 ns8250_probe: got MCR register: 0x40 ns8250_probe: got MCR wrong register, exiting with ENXIO ns8250_bus_probe:645: error at ns8250_probe(), exiting, returning 6 uart6: uart_bus_probe: Uart probe returned 6 uart6: uart_bus_probe: exiting uart6: uart_puc_probe: type = 1, error = 0 uart6: uart_puc_probe: probing for uart bus uart6: uart_bus_probe: Entering uart6: /usr/src/sys/dev/uart/uart_core.c:374: continue with rid=0x0 ns8250_bus_probe: entering ns8250_probe: entering ns8250_probe: got IIR register: 0x1 ns8250_probe: got MCR register: 0x40 ns8250_probe: got MCR wrong register, exiting with ENXIO ns8250_bus_probe:645: error at ns8250_probe(), exiting, returning 6 uart6: uart_bus_probe: Uart probe returned 6 uart6: uart_bus_probe: exiting ----- WBR -- Boris Samorodov (bsam) Research Engineer, http://www.ipt.ru Telephone & Internet SP FreeBSD committer, http://www.FreeBSD.org The Power To Serve From owner-freebsd-current@FreeBSD.ORG Thu Dec 11 00:29:00 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 629EB106564A for ; Thu, 11 Dec 2008 00:29:00 +0000 (UTC) (envelope-from jille@quis.cx) Received: from istud.quis.cx (ip83-113-174-82.adsl2.static.versatel.nl [82.174.113.83]) by mx1.freebsd.org (Postfix) with ESMTP id 0A8288FC14 for ; Thu, 11 Dec 2008 00:28:58 +0000 (UTC) (envelope-from jille@quis.cx) Received: from [192.168.1.4] (ille [192.168.1.4]) by istud.quis.cx (Postfix) with ESMTP id E2B415C19; Thu, 11 Dec 2008 01:28:57 +0100 (CET) Message-ID: <49405EC7.8080906@quis.cx> Date: Thu, 11 Dec 2008 01:28:55 +0100 From: Jille Timmermans User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Sam Leffler References: <49403F27.3020605@quis.cx> <4940440E.9050805@freebsd.org> In-Reply-To: <4940440E.9050805@freebsd.org> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD Current Subject: Re: Panic when loading if_ath X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Dec 2008 00:29:00 -0000 Sam Leffler schreef: > Jille Timmermans wrote: >> Hello list, >> >> A panic with if_ath (Atheros 2413) >> >> root /sys/modules/ath_rate_amrr# make >> root /sys/modules/ath_rate_amrr# make install >> root ~# kldload if_ath >> warning: KLD '/boot/kernel/if_ath.ko' is newer than the linker.hints file >> ath0: mem 0xc9000000-0xc900ffff irq 18 at device 1.0 on >> pci5 >> ath0: [ITHREAD] >> >> Fatal trap 12: page fault while in kernel mode >> cpuid = 0; apic id = 00 >> fault virtual address = 0x0 >> fault code = supervisor read, page not present >> instruction pointer = 0x20:0x0 >> stack pointer = 0x28:0xc43cc748 >> frame pointer = 0x28:0xc43cc75c >> code segment = base 0x0, limit 0xfffff, type 0x1b >> = DPL 0, pres 1, def32 1, gran 1 >> processor eflags = interrupt enabled, resume, IOPL = 0 >> current_process = 993 (kldload) >> trap number = 12 >> panic: page fault >> cpuid = 0 >> >> [dump] >> [reboot] >> WARNING: /tmp was not properly dismounted >> WARNING: /usr was not properly dismounted >> WARNING: /var was not properly dismounted >> >> Fatal trap 12: page fault while in kernel mode >> cpuid = 0; apic id = 00 >> fault virtual address = 0x5bbfe499 >> fault code = supervisor read, page not present >> instruction pointer = 0x20:0xc0684c37 >> stack pointer = 0x28:0xc4364a5c >> frame pointer = 0x28:0xc4364c28 >> code segment = base 0x0, limit 0xfffff, type 0x1b >> = DPL 0, pres 1, def32 1, gran 1 >> processor eflags = interrupt enabled, resume, IOPL = 0 >> current process = 136 (ifconfig) >> trap number = 12 >> panic: page fault >> cpuid = 0 >> >> [a few crashes later, when it comes to mind to get a backtrace] >> root ~# kldload ath_rate >> root ~# kldload if_ath >> ath0: mem 0xc9000000-0xc900ffff irq 18 at device 1.0 on >> pci5 >> ath0: [ITHREAD] >> [panic] >> uart_z8530_class(c4ac5000, 0, 1, 1, c4390000, ...) at 0 >> ar5212Attach(1a, c48b0000, 1, c4389000, c437c8ec, ...) at >> ar5212Attach+0x211 >> ath_hal_attach(1a, c48b0000, 1, c4389000, c437c8ec, ...) at >> ath_hal_attach+0x56 >> ath_attach(1a, c48b0000, 3, c437c940, ffffffff, ...) at ath_attach+0x9e >> ath_pci_attach(c46bb200, c4823854, c09fcf80, c099dc60, 80000000, ...) at >> ath_pci_attach+0x332 >> device_attach([snip]) at device_attach+0x36f >> device_probe_and_attach([snip) at ...+0x43 >> pci_driver_added([snip]) at +0x104 >> devclass_add_driver([snip]) at +0xe8 >> driver_module_handler([snip]) at +0x79 >> module_register_init() >> linker_load_module() >> kern_kldload() >> >> (Please don't tell me you want any of that snips.) >> >> Any extra information I can provide to you ? >> I am willing to help debugging / crashing. >> >> > Try building the driver into the kernel. Also use sample and not amrr. root ~# cd /sys/modules/ath_rate_sample root /sys/modules/ath_rate_sample# make root /sys/modules/ath_rate_sample# make install root /sys/modules/ath_rate_sample# kldload if_ath link_elf: symbol ath_hal_computetxtime undefined KLD if_ath.ko: depends on ath_rate - not available kldload: can't load if_ath: No such file or directory root /sys/modules/ath_rate_sample# kldload ath_rate link_elf: symbol ath_hal_computetxtime undefined kldload: can't load ath_rate: No such file or directory I'll try compiling it in. -- Jille > > Sam > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Thu Dec 11 00:45:52 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4BD7B1065673 for ; Thu, 11 Dec 2008 00:45:52 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id 077F48FC0C for ; Thu, 11 Dec 2008 00:45:51 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from trouble.errno.com (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id mBB0jo7Z073547 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 10 Dec 2008 16:45:51 -0800 (PST) (envelope-from sam@freebsd.org) Message-ID: <494062BE.5050202@freebsd.org> Date: Wed, 10 Dec 2008 16:45:50 -0800 From: Sam Leffler Organization: FreeBSD Project User-Agent: Thunderbird 2.0.0.9 (X11/20071125) MIME-Version: 1.0 To: Jille Timmermans References: <49403F27.3020605@quis.cx> <4940440E.9050805@freebsd.org> <49405EC7.8080906@quis.cx> In-Reply-To: <49405EC7.8080906@quis.cx> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-DCC--Metrics: ebb.errno.com; whitelist Cc: FreeBSD Current Subject: Re: Panic when loading if_ath X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Dec 2008 00:45:52 -0000 Jille Timmermans wrote: > Sam Leffler schreef: > >> Jille Timmermans wrote: >> >>> Hello list, >>> >>> A panic with if_ath (Atheros 2413) >>> >>> root /sys/modules/ath_rate_amrr# make >>> root /sys/modules/ath_rate_amrr# make install >>> root ~# kldload if_ath >>> warning: KLD '/boot/kernel/if_ath.ko' is newer than the linker.hints file >>> ath0: mem 0xc9000000-0xc900ffff irq 18 at device 1.0 on >>> pci5 >>> ath0: [ITHREAD] >>> >>> Fatal trap 12: page fault while in kernel mode >>> cpuid = 0; apic id = 00 >>> fault virtual address = 0x0 >>> fault code = supervisor read, page not present >>> instruction pointer = 0x20:0x0 >>> stack pointer = 0x28:0xc43cc748 >>> frame pointer = 0x28:0xc43cc75c >>> code segment = base 0x0, limit 0xfffff, type 0x1b >>> = DPL 0, pres 1, def32 1, gran 1 >>> processor eflags = interrupt enabled, resume, IOPL = 0 >>> current_process = 993 (kldload) >>> trap number = 12 >>> panic: page fault >>> cpuid = 0 >>> >>> [dump] >>> [reboot] >>> WARNING: /tmp was not properly dismounted >>> WARNING: /usr was not properly dismounted >>> WARNING: /var was not properly dismounted >>> >>> Fatal trap 12: page fault while in kernel mode >>> cpuid = 0; apic id = 00 >>> fault virtual address = 0x5bbfe499 >>> fault code = supervisor read, page not present >>> instruction pointer = 0x20:0xc0684c37 >>> stack pointer = 0x28:0xc4364a5c >>> frame pointer = 0x28:0xc4364c28 >>> code segment = base 0x0, limit 0xfffff, type 0x1b >>> = DPL 0, pres 1, def32 1, gran 1 >>> processor eflags = interrupt enabled, resume, IOPL = 0 >>> current process = 136 (ifconfig) >>> trap number = 12 >>> panic: page fault >>> cpuid = 0 >>> >>> [a few crashes later, when it comes to mind to get a backtrace] >>> root ~# kldload ath_rate >>> root ~# kldload if_ath >>> ath0: mem 0xc9000000-0xc900ffff irq 18 at device 1.0 on >>> pci5 >>> ath0: [ITHREAD] >>> [panic] >>> uart_z8530_class(c4ac5000, 0, 1, 1, c4390000, ...) at 0 >>> ar5212Attach(1a, c48b0000, 1, c4389000, c437c8ec, ...) at >>> ar5212Attach+0x211 >>> ath_hal_attach(1a, c48b0000, 1, c4389000, c437c8ec, ...) at >>> ath_hal_attach+0x56 >>> ath_attach(1a, c48b0000, 3, c437c940, ffffffff, ...) at ath_attach+0x9e >>> ath_pci_attach(c46bb200, c4823854, c09fcf80, c099dc60, 80000000, ...) at >>> ath_pci_attach+0x332 >>> device_attach([snip]) at device_attach+0x36f >>> device_probe_and_attach([snip) at ...+0x43 >>> pci_driver_added([snip]) at +0x104 >>> devclass_add_driver([snip]) at +0xe8 >>> driver_module_handler([snip]) at +0x79 >>> module_register_init() >>> linker_load_module() >>> kern_kldload() >>> >>> (Please don't tell me you want any of that snips.) >>> >>> Any extra information I can provide to you ? >>> I am willing to help debugging / crashing. >>> >>> >>> >> Try building the driver into the kernel. Also use sample and not amrr. >> > root ~# cd /sys/modules/ath_rate_sample > root /sys/modules/ath_rate_sample# make > root /sys/modules/ath_rate_sample# make install > root /sys/modules/ath_rate_sample# kldload if_ath > link_elf: symbol ath_hal_computetxtime undefined > KLD if_ath.ko: depends on ath_rate - not available > kldload: can't load if_ath: No such file or directory > root /sys/modules/ath_rate_sample# kldload ath_rate > link_elf: symbol ath_hal_computetxtime undefined > kldload: can't load ath_rate: No such file or directory > > I'll try compiling it in. > > I know module building is broken; I posted recently to just build things into the kernel. I've got a possible solution in p4 in the sam_vap branch if you want to try it. I removed the ath_rate_* modules and just smooshed the code into the ath module so we go from (ath+ath_hal+ath_rate) to just (ath). Right now I want to see if your problem is in the module mess, ath_rate_amrr, or something else. I tested 2413 w/ the driver built into the kernel so I'm guessing it's amrr which I may just nuke entirely (along with onoe). Sam From owner-freebsd-current@FreeBSD.ORG Thu Dec 11 00:56:17 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1ECAF1065673; Thu, 11 Dec 2008 00:56:17 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id D19148FC13; Thu, 11 Dec 2008 00:56:16 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.14.3/8.14.3) with ESMTP id mBB0uEga051723; Wed, 10 Dec 2008 19:56:14 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.14.3/8.14.3) with ESMTP id mBB0uETk017914; Wed, 10 Dec 2008 19:56:14 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id F115073039; Wed, 10 Dec 2008 19:56:13 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20081211005613.F115073039@freebsd-current.sentex.ca> Date: Wed, 10 Dec 2008 19:56:13 -0500 (EST) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on clamscanner2 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on ia64/ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Dec 2008 00:56:17 -0000 TB --- 2008-12-10 22:52:52 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2008-12-10 22:52:52 - starting HEAD tinderbox run for ia64/ia64 TB --- 2008-12-10 22:52:52 - cleaning the object tree TB --- 2008-12-10 22:53:27 - cvsupping the source tree TB --- 2008-12-10 22:53:27 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/ia64/ia64/supfile TB --- 2008-12-10 22:53:35 - building world TB --- 2008-12-10 22:53:35 - MAKEOBJDIRPREFIX=/obj TB --- 2008-12-10 22:53:35 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2008-12-10 22:53:35 - TARGET=ia64 TB --- 2008-12-10 22:53:35 - TARGET_ARCH=ia64 TB --- 2008-12-10 22:53:35 - TZ=UTC TB --- 2008-12-10 22:53:35 - __MAKE_CONF=/dev/null TB --- 2008-12-10 22:53:35 - cd /src TB --- 2008-12-10 22:53:35 - /usr/bin/make -B buildworld >>> World build started on Wed Dec 10 22:53:36 UTC 2008 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Thu Dec 11 00:40:46 UTC 2008 TB --- 2008-12-11 00:40:46 - generating LINT kernel config TB --- 2008-12-11 00:40:46 - cd /src/sys/ia64/conf TB --- 2008-12-11 00:40:46 - /usr/bin/make -B LINT TB --- 2008-12-11 00:40:46 - building LINT kernel TB --- 2008-12-11 00:40:46 - MAKEOBJDIRPREFIX=/obj TB --- 2008-12-11 00:40:46 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2008-12-11 00:40:46 - TARGET=ia64 TB --- 2008-12-11 00:40:46 - TARGET_ARCH=ia64 TB --- 2008-12-11 00:40:46 - TZ=UTC TB --- 2008-12-11 00:40:46 - __MAKE_CONF=/dev/null TB --- 2008-12-11 00:40:46 - cd /src TB --- 2008-12-11 00:40:46 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Dec 11 00:40:46 UTC 2008 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] /src/sys/kern/vfs_aio.c:2633: error: dereferencing pointer to incomplete type /src/sys/kern/vfs_aio.c: In function 'freebsd32_olio_listio': /src/sys/kern/vfs_aio.c:2859: error: storage size of 'osig' isn't known cc1: warnings being treated as errors /src/sys/kern/vfs_aio.c:2859: warning: unused variable 'osig' /src/sys/kern/vfs_aio.c: In function 'freebsd32_lio_listio': /src/sys/kern/vfs_aio.c:2904: error: storage size of 'sig32' isn't known /src/sys/kern/vfs_aio.c:2904: warning: unused variable 'sig32' *** Error code 1 Stop in /obj/ia64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-12-11 00:56:13 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-12-11 00:56:13 - ERROR: failed to build lint kernel TB --- 2008-12-11 00:56:13 - 6055.20 user 427.31 system 7401.26 real http://tinderbox.des.no/tinderbox-head-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Thu Dec 11 01:00:29 2008 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3B9961065672 for ; Thu, 11 Dec 2008 01:00:29 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout011.mac.com (asmtpout011.mac.com [17.148.16.86]) by mx1.freebsd.org (Postfix) with ESMTP id 246DC8FC1B for ; Thu, 11 Dec 2008 01:00:29 +0000 (UTC) (envelope-from xcllnt@mac.com) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed Received: from yiangh-mbp.jnpr.net (natint3.juniper.net [66.129.224.36]) by asmtp011.mac.com (Sun Java(tm) System Messaging Server 6.3-7.03 (built Aug 7 2008; 32bit)) with ESMTPSA id <0KBO006RYTGO5830@asmtp011.mac.com> for freebsd-current@FreeBSD.org; Wed, 10 Dec 2008 17:00:25 -0800 (PST) Message-id: <19F75E66-0535-4982-9726-E2C0A03117EA@mac.com> From: Marcel Moolenaar To: Boris Samorodov In-reply-to: <26719629@bb.ipt.ru> Date: Wed, 10 Dec 2008 17:00:24 -0800 References: <92804393@bb.ipt.ru> <26722819@bb.ipt.ru> <26719629@bb.ipt.ru> X-Mailer: Apple Mail (2.929.2) Cc: freebsd-current@FreeBSD.org, rea-fbsd@codelabs.ru Subject: Re: Timeda 8-multiport adapter: only 2 ports available X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Dec 2008 01:00:29 -0000 On Dec 10, 2008, at 4:02 PM, Boris Samorodov wrote: > Seems that just the same card should work: > http://lists.freebsd.org/pipermail/freebsd-stable/2008-May/042505.html > > I've added some diagnistic. But 'rid' is not what you want, I guess: The RID is fine. It should always be 0. * > uart4: /usr/src/sys/dev/uart/uart_core.c:374: continue with rid=0x0 > ns8250_probe: no errors, exiting * > uart4: /usr/src/sys/dev/uart/uart_core.c:374: continue with rid=0x0 > ns8250_probe: no errors, exiting * > uart5: /usr/src/sys/dev/uart/uart_core.c:374: continue with rid=0x0 > ns8250_probe: no errors, exiting * > uart5: /usr/src/sys/dev/uart/uart_core.c:374: continue with rid=0x0 > ns8250_probe: no errors, exiting * > uart6: /usr/src/sys/dev/uart/uart_core.c:374: continue with rid=0x0 > ns8250_probe: got MCR wrong register, exiting with ENXIO * > uart6: /usr/src/sys/dev/uart/uart_core.c:374: continue with rid=0x0 > ns8250_probe: got MCR wrong register, exiting with ENXIO * > uart6: /usr/src/sys/dev/uart/uart_core.c:374: continue with rid=0x0 > ns8250_probe: got MCR wrong register, exiting with ENXIO * > uart6: /usr/src/sys/dev/uart/uart_core.c:374: continue with rid=0x0 > ns8250_probe: got MCR wrong register, exiting with ENXIO * > uart6: /usr/src/sys/dev/uart/uart_core.c:374: continue with rid=0x0 > ns8250_probe: got MCR wrong register, exiting with ENXIO * > uart6: /usr/src/sys/dev/uart/uart_core.c:374: continue with rid=0x0 > ns8250_probe: got MCR wrong register, exiting with ENXIO It looks like the mapping is wrong. That is, uart(4) gets to probe 8 ports but rejects 6. I would add debugging information to puc(4) and in particular to where resources are assigned to ports so that we can see what the BAR and offsets within the BAR are for each port. FYI, -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-current@FreeBSD.ORG Thu Dec 11 01:06:47 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C119E1065672 for ; Thu, 11 Dec 2008 01:06:47 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [62.111.66.27]) by mx1.freebsd.org (Postfix) with ESMTP id 733658FC1A for ; Thu, 11 Dec 2008 01:06:47 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from localhost (amavis.str.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id CC82641C733; Thu, 11 Dec 2008 02:06:45 +0100 (CET) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([62.111.66.27]) by localhost (amavis.str.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id q0GnF4tl1XZO; Thu, 11 Dec 2008 02:06:45 +0100 (CET) Received: by mail.cksoft.de (Postfix, from userid 66) id 588EE41C679; Thu, 11 Dec 2008 02:06:45 +0100 (CET) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 892734448DD; Thu, 11 Dec 2008 01:05:43 +0000 (UTC) Date: Thu, 11 Dec 2008 01:05:43 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: FreeBSD Tinderbox In-Reply-To: <20081211005613.F115073039@freebsd-current.sentex.ca> Message-ID: <20081211010452.M97918@maildrop.int.zabbadoz.net> References: <20081211005613.F115073039@freebsd-current.sentex.ca> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: FreeBSD current mailing list , ia64@freebsd.org Subject: Re: [head tinderbox] failure on ia64/ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Dec 2008 01:06:47 -0000 On Wed, 10 Dec 2008, FreeBSD Tinderbox wrote: > [...] > /src/sys/kern/vfs_aio.c:2633: error: dereferencing pointer to incomplete type > /src/sys/kern/vfs_aio.c: In function 'freebsd32_olio_listio': > /src/sys/kern/vfs_aio.c:2859: error: storage size of 'osig' isn't known > cc1: warnings being treated as errors > /src/sys/kern/vfs_aio.c:2859: warning: unused variable 'osig' > /src/sys/kern/vfs_aio.c: In function 'freebsd32_lio_listio': > /src/sys/kern/vfs_aio.c:2904: error: storage size of 'sig32' isn't known > /src/sys/kern/vfs_aio.c:2904: warning: unused variable 'sig32' > *** Error code 1 This should be fixed with r185898 and be gone witht he next round of tb runs. -- Bjoern A. Zeeb The greatest risk is not taking one. From owner-freebsd-current@FreeBSD.ORG Thu Dec 11 01:45:58 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 219DD1065672 for ; Thu, 11 Dec 2008 01:45:58 +0000 (UTC) (envelope-from josh.carroll@gmail.com) Received: from mail-gx0-f12.google.com (mail-gx0-f12.google.com [209.85.217.12]) by mx1.freebsd.org (Postfix) with ESMTP id 8C5AD8FC17 for ; Thu, 11 Dec 2008 01:45:57 +0000 (UTC) (envelope-from josh.carroll@gmail.com) Received: by gxk5 with SMTP id 5so229025gxk.19 for ; Wed, 10 Dec 2008 17:45:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:reply-to :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=bj8f48eTyREWfV2mIarL0WRD5FRQKRVWQLr06/XETQU=; b=wq4dkjrKh75ZsmlIVNuM5dxIS4rUu0cfS1bljBvlSpiPhY1y5NASwqrh6IIUpoV4mM UpEyAcRvsA/jQIIjvGih7g9YRqJqoZTNcMbLcjQiAOuVhv7FXoo97qmgfHEF4gDYbelf Tt12MGjgwWI8O9zxbBJR4l6SX0h8pUsfAwgz8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:reply-to:to:subject:cc:in-reply-to :mime-version:content-type:content-transfer-encoding :content-disposition:references; b=QXPtlImw7XiqQOIA4KcjjTSAYddw0J4jcfeP/AmeSzS8cW1/hepEcPU6kjFx67iwpC Itzpj/jhnzWI6YrNeM56QTIRmnVu6XzQ+TsPSXF5JgCOv+CejTFrqtWmt9kKRFoJwTHy vwW+SiqtaNHYPMUfTj33vIU43fGIwtUmBuWaY= Received: by 10.151.8.8 with SMTP id l8mr3266558ybi.5.1228959956589; Wed, 10 Dec 2008 17:45:56 -0800 (PST) Received: by 10.150.123.1 with HTTP; Wed, 10 Dec 2008 17:45:56 -0800 (PST) Message-ID: <8cb6106e0812101745l54b23a08k7fbeddeb605f88ea@mail.gmail.com> Date: Wed, 10 Dec 2008 20:45:56 -0500 From: "Josh Carroll" To: "Steve Franks" In-Reply-To: <8cb6106e0812081252j2b0c8e78g4dcecf8d3770c269@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <490F47BE.9080205@janh.de> <20081104015235.GC98154@cdnetworks.co.kr> <4910C055.8000505@janh.de> <20081105013558.GA99795@cdnetworks.co.kr> <20081203090658.GJ9639@cdnetworks.co.kr> <37502393@bb.ipt.ru> <20081206023016.GF22093@cdnetworks.co.kr> <539c60b90812081127s4ffb509fnea9d44d4298da666@mail.gmail.com> <8cb6106e0812081252j2b0c8e78g4dcecf8d3770c269@mail.gmail.com> Cc: pyunyh@gmail.com, current-list freebsd Subject: Re: Call for testers: Atheros AR8121(L1E)/AR8113/AR8114(L2E) ethernet X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: josh.carroll@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Dec 2008 01:45:58 -0000 > ale0@pci0:2:0:0: class=0x020000 card=0x82261043 chip=0x10261969 > rev=0xb0 hdr=0x00 > vendor = 'Attansic (Now owned by Atheros)' > class = network > subclass = ethernet > > iperf (ale0 as -s): [ 3] 0.0-10.0 sec 1.10 GBytes 941 Mbits/sec > iperf (ale0 as -c): [ 3] 0.0-10.0 sec 1.08 GBytes 931 Mbits/sec > > So all seems well here. Well, I spoke too soon. Overall gigE throughput wise and day to day activities (NAT'd 20 Mbit FiOS) were fine. Tonight, however, I went to watch a 720p video (~4 Mbps bitrate or less) on my Popcorn Hour over NFS which has worked fine in the past. It was extremely "jerky" and unwatchable. Figuring perhaps the Popcorn Hour had an issue, I fired up an NFS server on another box and the video streamed just fine. I then rebooted this box and threw in a trusty old PCI em(4) card, and all is well. I tried playing with these two sysctl knobs for ale0: dev.ale.0.int_rx_mod and dev.ale.0.int_tx_mod I tried setting both to 0 and both to higher numbers on the documented scale (10000 I believe), neither of which helped. I imagine since what I want here is a "smoother" transmission, setting int_tx_mod to 0 is what would have the most effect, but the video still was not playable with it set to 0. I've since disabled the ale0 interface in the BIOS and I'm using the em(4) for now. Is there another knob for ale I should try adjusting? Thanks, Josh From owner-freebsd-current@FreeBSD.ORG Thu Dec 11 05:19:47 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D725C1065670; Thu, 11 Dec 2008 05:19:47 +0000 (UTC) (envelope-from channa.kad@gmail.com) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.30]) by mx1.freebsd.org (Postfix) with ESMTP id 847AD8FC1E; Thu, 11 Dec 2008 05:19:47 +0000 (UTC) (envelope-from channa.kad@gmail.com) Received: by yx-out-2324.google.com with SMTP id 8so383837yxb.13 for ; Wed, 10 Dec 2008 21:19:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:mime-version:content-type:content-transfer-encoding :content-disposition; bh=ANCLWcKIUM5EIo/TiraL496MOV6qljZJEbCuUgEWFcw=; b=V+1ZrsjtqL3kOJjla7ywltXL35mU1Hx4IAXHq3w68+cFfzxjuvebI6pgj66J5dvocb CfWGIXooaARWUhM10MRhQYpCzpsVxB5kbNTGEZDYQ7bv/Iwk+trZEnCBkzc0aHsHMlYZ ciI6uzwywiQCsCd3I4b0ZeBW/TvK9Z+fNIBhQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:mime-version:content-type :content-transfer-encoding:content-disposition; b=MqZwDla+r39FGXIdUzHywQ3mQuGp4tOkEJNX063pCUdanKEpmrfGw8ogujiAly+QdC PnTis+FQdSeInYSS0xTNzUyyhbI5MyIBVXI/4X88+cLt49bsSyb+f8tXvD+OXrvQrb1C T/GgTAz5nTwQ/tCaTLEFdQAGxZ6WZwyclArrA= Received: by 10.65.212.18 with SMTP id o18mr1768003qbq.21.1228972786453; Wed, 10 Dec 2008 21:19:46 -0800 (PST) Received: by 10.64.156.4 with HTTP; Wed, 10 Dec 2008 21:19:46 -0800 (PST) Message-ID: <515c64960812102119l5e7fb629n1a7e4b551e2c1ab5@mail.gmail.com> Date: Thu, 11 Dec 2008 10:49:46 +0530 From: Channa To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: Jason Evans Subject: jemalloc performance Vs ptmalloc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Dec 2008 05:19:47 -0000 Hi, Sorry there was a spell mistake in the prev post. I tried to execute the benchmark test malloc-test to compare the ptmalloc performance and jemalloc performance. jemalloc seems to performance better than ptmalloc under following conditions. - If memory requests are less than 3840Bytes jemalloc is faster than ptmalloc Jemalloc: # ./malloc-test 1024 10000000 5 Starting test with 5 threads... Thread -1086325424 adjusted timing: 0.893323 seconds for 10000000 requests of 1024 bytes. Thread -1090519728 adjusted timing: 0.893581 seconds for 10000000 requests of 1024 bytes. Thread -1082131120 adjusted timing: 0.983221 seconds for 10000000 requests of 1024 bytes. Thread -1088422576 adjusted timing: 1.346636 seconds for 10000000 requests of 1024 bytes. Thread -1084228272 adjusted timing: 1.394940 seconds for 10000000 requests of 1024 bytes. Ptmalloc: # ./malloc-test 1024 10000000 5 Starting test with 5 threads... Thread -1208353904 adjusted timing: 2.427992 seconds for 10000000 requests of 1024 bytes. Thread -1239823472 adjusted timing: 2.474918 seconds for 10000000 requests of 1024 bytes. Thread -1218843760 adjusted timing: 2.394854 seconds for 10000000 requests of 1024 bytes. Thread -1250313328 adjusted timing: 3.695654 seconds for 10000000 requests of 1024 bytes. Thread -1229333616 adjusted timing: 5.081604 seconds for 10000000 requests of 1024 bytes. - If memory requests are page aligned i.e large allocations jemalloc is slower than ptmalloc. jemalloc: # ./malloc-test 9300 10000000 5 Starting test with 5 threads... Thread -1077936816 adjusted timing: 4.648531 seconds for 10000000 requests of 9300 bytes. Thread -1086325424 adjusted timing: 4.837230 seconds for 10000000 requests of 9300 bytes. Thread -1080033968 adjusted timing: 4.978933 seconds for 10000000 requests of 9300 bytes. Thread -1084228272 adjusted timing: 7.029323 seconds for 10000000 requests of 9300 bytes. Thread -1082131120 adjusted timing: 7.075402 seconds for 10000000 requests of 9300 bytes. Ptmalloc: # ./malloc-test_glib 9300 10000000 5 Starting test with 5 threads... Thread -1229083760 adjusted timing: 2.860437 seconds for 10000000 requests of 9300 bytes. Thread -1250063472 adjusted timing: 3.254859 seconds for 10000000 requests of 9300 bytes. Thread -1218593904 adjusted timing: 4.334052 seconds for 10000000 requests of 9300 bytes. Thread -1208104048 adjusted timing: 4.139268 seconds for 10000000 requests of 9300 bytes. Thread -1239573616 adjusted timing: 5.396595 seconds for 10000000 requests of 9300 bytes. So jemalloc takes more time for Large allocations than ptmalloc. For Huge allocations freater than 1MB again jemalloc is faster than ptmalloc. i tested this on 4 CPU intel x86 machine. Could you please tell me if there is any method to increase the performance for Large allocations.? I tried to increase the bins by setting the PAGE_SHIFT to 13 that time the performance of jemalloc was better for allocations till 7936. As per my analysis using bins for all allocations less than 1MB reduces the time taken but which may not be correct. I am trying to modify the Large allocations to increase the performance, Could you suggest some ideas. Thanks in Advance, Channa From owner-freebsd-current@FreeBSD.ORG Thu Dec 11 05:23:06 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 10BAF1065670; Thu, 11 Dec 2008 05:23:06 +0000 (UTC) (envelope-from mike@jellydonut.org) Received: from mail-fx0-f19.google.com (mail-fx0-f19.google.com [209.85.220.19]) by mx1.freebsd.org (Postfix) with ESMTP id E4C598FC1B; Thu, 11 Dec 2008 05:23:04 +0000 (UTC) (envelope-from mike@jellydonut.org) Received: by fxm12 with SMTP id 12so374573fxm.19 for ; Wed, 10 Dec 2008 21:23:03 -0800 (PST) Received: by 10.181.28.15 with SMTP id f15mr605520bkj.75.1228972983177; Wed, 10 Dec 2008 21:23:03 -0800 (PST) Received: by 10.181.240.8 with HTTP; Wed, 10 Dec 2008 21:23:03 -0800 (PST) Message-ID: <1de79840812102123p2144fb37hc9a0b2c958061c34@mail.gmail.com> Date: Thu, 11 Dec 2008 00:23:03 -0500 From: "Michael Proto" To: "Giorgos Keramidas" In-Reply-To: <87zlj390vw.fsf@kobe.laptop> MIME-Version: 1.0 References: <1de79840812092149t4d212027o2c908635419fa838@mail.gmail.com> <87zlj390vw.fsf@kobe.laptop> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: FreeBSD Current , freebsd-questions@freebsd.org Subject: Re: behavioral change of "read" builtin for sh on 8-CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Dec 2008 05:23:06 -0000 Thanks! PR 129566 filed on this issue. -Proto On Wed, Dec 10, 2008 at 4:27 PM, Giorgos Keramidas wrote: > Hi Michael, > > This looks like a bug in 8.0-CURRENT. > > Can you please file a bug report and include the text you sent below? > > On Wed, 10 Dec 2008 00:49:58 -0500, "Michael Proto" > wrote: > > I've noticed a behavioral difference of the "read" builtin statement > within > > /bin/sh on CURRENT and I'm hoping someone can point me in the right > > direction on how to restore the old behavior. > > > > I have a /bin/sh script that accepts input for IP address information: > > > > #!/bin/sh > > set -x > > DEFINT=vr0 > > DEFIP=192.168.0.1 > > DEFMASK=255.255.255.0 > > read -p "Enter network interface [$DEFINT]: " -t 5 INT > > read -p "Enter IP address [$DEFIP]: " -t 5 IP > > read -p "Enter netmask [$DEFMASK]: " -t 5 MASK > > echo ${INT:=$DEFINT} : ${IP:=$DEFIP}/${MASK:=$DEFMASK} > > > > This script waits for terminal input for each of the above variables > (INT, > > IP, MASK) and defaults to a script-provided value if no input is entered > in > > 5 seconds for each variable. On 6.x and 7.x if I simply hit Enter at the > > prompt (and don't provide any input) no value is assigned to the variable > so > > my INT, IP, and MASK variables are set to null and the parameter > > substitution of the DEF* variables works as expected. > > > > On 8-CURRENT if I hit Enter with no input at the prompt the system seems > to > > recognize the newline as input and continues to sit there until I hit > Enter > > again. When I do this there appears to be a strange unprintable value > > assigned to the INT, IP, and MASK variables yet the variable subsitution > > doesn't work correctly. > > > > The man page on sh lists the following behavior for read: > > > > read [-p prompt] [-t timeout] [-er] variable ... > > The prompt is printed if the -p option is specified and the > > stan- > > dard input is a terminal. Then a line is read from the > > standard > > input. The trailing newline is deleted from the line and > the > > line is split as described in the section on White Space > > Splitting (Field Splitting) above, and the pieces are > assigned > > to > > the variables in order. If there are more pieces than > > variables, > > the remaining pieces (along with the characters in IFS that > > sepa- > > rated them) are assigned to the last variable. If there are > > more > > variables than pieces, the remaining variables are assigned > the > > null string. > > > > > > As I interpret this, read should delete the trailing newline and assign a > > null value since there is is no "input" before the newline. Then the > > variable substitution should take over and assign the DEF* variables > > appropriately. 6 and 7 follow this but 8 does not. > > > > Here's the output of the script (with set -x) to help show what I'm > seeing. > > > > This is on 6 and 7: > > > > + DEFINT=vr0 > > + DEFIP=192.168.0.1 > > + DEFMASK=255.255.255.0 > > + read -p Enter network interface [vr0]: -t 5 INT > > Enter network interface [vr0]: > > + read -p Enter IP address [192.168.0.1]: -t 5 IP > > Enter IP address [192.168.0.1]: > > + read -p Enter netmask [255.255.255.0]: -t 5 MASK > > Enter netmask [255.255.255.0]: > > + echo vr0 : 192.168.0.1/255.255.255.0 > > vr0 : 192.168.0.1/255.255.255.0 > > > > > > And this is what I see with 8: > > > > + DEFINT=vr0 > > + DEFIP=192.168.0.1 > > + DEFMASK=255.255.255.0 > > + read -p Enter network interface [vr0]: -t 5 INT > > Enter network interface [vr0]: > > + read -p Enter IP address [192.168.0.1]: -t 5 IP > > Enter IP address [192.168.0.1]: > > + read -p Enter netmask [255.255.255.0]: -t 5 MASK > > Enter netmask [255.255.255.0]: > > /: cho > > /: > > > > Strange that the "echo" statement is missing the first "e" character in > the > > debug output. > > > > Even stranger on 8-CURRENT, if I *do* enter input before the newline (say > I > > change the IP address or the network interface), the first character is > not > > echoed back to the screen but is still saved to the variable. Here's an > > example when I run the script and provide input at each prompt: > > > > + DEFINT=vr0 > > + DEFIP=192.168.0.1 > > + DEFMASK=255.255.255.0 > > + read -p Enter network interface [vr0]: -t 5 INT > > Enter network interface [vr0]: r0 > > + read -p Enter IP address [192.168.0.1]: -t 5 IP > > Enter IP address [192.168.0.1]: 92.168.0.1 > > + read -p Enter netmask [255.255.255.0]: -t 5 MASK > > Enter netmask [255.255.255.0]: 55.255.255.0 > > + echo br0 : 192.168.0.1/255.255.255.0 > > br0 : 192.168.0.1/255.255.255.0 > > + echo ifconfig br0 inet 192.168.0.1 netmask 255.255.255.0 > > > > Notice that when I'm prompted, the first character doesn't echo but is > still > > saved in the variable. > > > > > > Does anyone else see this same behavior? Any ideas on how to reset it > back > > to how it works in STABLE? I'm not doing anything special with IFS so I'm > > stumped on how to troubleshoot this. > > > > > > > > Thanks, > > Proto > > _______________________________________________ > > freebsd-questions@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > > To unsubscribe, send any mail to " > freebsd-questions-unsubscribe@freebsd.org" > > > > -- > From owner-freebsd-current@FreeBSD.ORG Thu Dec 11 05:35:03 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CEC181065670 for ; Thu, 11 Dec 2008 05:35:03 +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 829C98FC08 for ; Thu, 11 Dec 2008 05:35:03 +0000 (UTC) (envelope-from randy@psg.com) Received: from [202.214.86.146] (helo=rmac.psg.com) by ran.psg.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LAeCU-000Dje-OL for current@freebsd.org; Thu, 11 Dec 2008 05:35:03 +0000 Message-ID: <4940A685.7040608@psg.com> Date: Thu, 11 Dec 2008 14:35:01 +0900 From: Randy Bush User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20081204 Thunderbird/3.0b1 MIME-Version: 1.0 To: FreeBSD Current Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: panic: sleeping thread & bufwrite: buffer is not busy??? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Dec 2008 05:35:03 -0000 i386 soekris 5501 current as of Dec 11 00:27 gmt Unread portion of the kernel message buffer: Sleeping thread (tid 100054, pid 646) owns a non-sleepable lock panic: sleeping thread panic: bufwrite: buffer is not busy??? Uptime: 2m1s Physical memory: 503 MB #0 doadump () at pcpu.h:246 #1 0xc0571f33 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:420 #2 0xc05720f7 in panic (fmt=Variable "fmt" is not available.) at /usr/src/sys/kern/kern_shutdown.c:576 #3 0xc06fc75c in ffs_bufwrite (bp=0xc2937e20) at /usr/src/sys/ufs/ffs/ffs_vfsops.c:1786 #4 0xc05c7250 in vfs_bio_awrite (bp=0xc2937e20) at buf.h:385 #5 0xc05cfee0 in vop_stdfsync (ap=0xc2a89b34) at /usr/src/sys/kern/vfs_default.c:479 #6 0xc0520ad3 in devfs_fsync (ap=0xc2a89b34) at /usr/src/sys/fs/devfs/devfs_vnops.c:485 #7 0xc074e50e in VOP_FSYNC_APV (vop=0xc07cc800, a=0xc2a89b34) at vnode_if.c:1007 #8 0xc06fd0a2 in ffs_sync (mp=0xc2e33c80, waitfor=2, td=0xc2c28480) at vnode_if.h:529 #9 0xc05e0803 in sync (td=0xc2c28480, uap=0x0) at /usr/src/sys/kern/vfs_syscalls.c:149 #10 0xc0571ad2 in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:312 #11 0xc05720f7 in panic (fmt=Variable "fmt" is not available.) at /usr/src/sys/kern/kern_shutdown.c:576 #12 0xc059ec81 in propagate_priority (td=0xc2e696c0) at /usr/src/sys/kern/subr_turnstile.c:222 #13 0xc059f551 in turnstile_wait (ts=0xc2c0ee10, owner=0xc2e696c0, queue=Variable "queue" is not available.) at /usr/src/sys/kern/subr_turnstile.c:738 #14 0xc0570c73 in _rw_wlock_hard (rw=0xc2cdcd80, tid=3267527808, file=0x0, line=0) at /usr/src/sys/kern/kern_rwlock.c:705 #15 0xc06bdcb6 in in6_mtutimo (rock=0xc2cdcd00) at /usr/src/sys/netinet6/in6_rmx.c:437 #16 0xc0580f77 in softclock (arg=0xc07ffbe0) at /usr/src/sys/kern/kern_timeout.c:398 #17 0xc055790a in intr_event_execute_handlers (p=0xc2c257ec, ie=0xc2c22400) at /usr/src/sys/kern/kern_intr.c:1134 #18 0xc0558933 in ithread_loop (arg=0xc2c07ba0) at /usr/src/sys/kern/kern_intr.c:1147 #19 0xc0555cb6 in fork_exit (callout=0xc05588d0 , arg=0xc2c07ba0, frame=0xc2a89d38) at /usr/src/sys/kern/kern_fork.c:821 #20 0xc0730a50 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:270 From owner-freebsd-current@FreeBSD.ORG Thu Dec 11 08:50:27 2008 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0DDB610656D6 for ; Thu, 11 Dec 2008 08:50:27 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) Received: from 0.mx.codelabs.ru (0.mx.codelabs.ru [144.206.177.45]) by mx1.freebsd.org (Postfix) with ESMTP id B0B7C8FC20 for ; Thu, 11 Dec 2008 08:50:26 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=one; d=codelabs.ru; h=Received:Date:From:To:Cc:Subject:Message-ID:Reply-To:References:MIME-Version:Content-Type:Content-Disposition:In-Reply-To:Sender; b=pmcQa7uAQ7+AbKZkTKJgFa5uFMnuVV1Loti8Ez+Y2QH1SaJvlhiKKrHqBcL+QgjCJG02EfcpsBzstUif5MnAKjfQieOUcX27WNgvjiMzsmFMwIlTFMvTXTtTD6KpiZ8Xx9NkAHHLWLSSXQZ2OMNo4vUUahni1qbOfLlgkaID15Q=; Received: from void.codelabs.ru (void.codelabs.ru [144.206.177.25]) by 0.mx.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1LAhFZ-0003Py-NC; Thu, 11 Dec 2008 11:50:25 +0300 Date: Thu, 11 Dec 2008 11:50:24 +0300 From: Eygene Ryabinkin To: Marcel Moolenaar Message-ID: References: <92804393@bb.ipt.ru> <26722819@bb.ipt.ru> <26719629@bb.ipt.ru> <19F75E66-0535-4982-9726-E2C0A03117EA@mac.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="SkvwRMAIpAhPCcCJ" Content-Disposition: inline In-Reply-To: <19F75E66-0535-4982-9726-E2C0A03117EA@mac.com> Sender: rea-fbsd@codelabs.ru Cc: Boris Samorodov , freebsd-current@FreeBSD.org Subject: Re: Timeda 8-multiport adapter: only 2 ports available X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rea-fbsd@codelabs.ru List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Dec 2008 08:50:27 -0000 --SkvwRMAIpAhPCcCJ Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Marcel, Boris, good day. Wed, Dec 10, 2008 at 05:00:24PM -0800, Marcel Moolenaar wrote: > > Seems that just the same card should work: > > http://lists.freebsd.org/pipermail/freebsd-stable/2008-May/042505.html > > > > I've added some diagnistic. But 'rid' is not what you want, I guess: > > The RID is fine. It should always be 0. Seems like a dumb question, but nevertheless. What I don't understand is the following: BAR to port mapping for the Timedia is tricky, it mixes BARs and offsets for the different ports (you should know this, since you wrote the support ;)). But in uart_bus_probe you're passing rid =3D 0 and it is used for resource allocation and consequently the same rid is used for all ports (at least I read the code in this way). But puc_get_bar() uses calculated rid values, but does essentially the same thing: resource allocation via bus_alloc_resource(). And sc->sc_bas is initialized from the obtained sc->sc_rres (inside uart_bus_probe) and it is subsequently used for ns8250_probe() that is failing. I see that uart_bus_pci.c calls uart_bus_probe() with the actual rid. It does not mean that puc code should do the same, but ... Boris, could you please add the line ----- printf("%s: BAS, handle is 0x%lx, tag is 0x%x\n", __func__, (unsigned long)bas->bsh, (unsigned int)bas->bst); ----- to the beginning of ns8250_probe() and show the results. Thanks! --=20 Eygene _ ___ _.--. # \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard / ' ` , __.--' # to read the on-line manual =20 )/' _/ \ `-_, / # while single-stepping the kernel. `-'" `"\_ ,_.-;_.-\_ ', fsc/as # _.-'_./ {_.' ; / # -- FreeBSD Developers handbook=20 {_.-``-' {_/ # --SkvwRMAIpAhPCcCJ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAklA1FAACgkQthUKNsbL7YiBXQCgnOuvK3iWtbSIJA2Bti+7CF0Z DpcAni17Xm64G5S/gq5Va7xjmaB8ENQD =JoL1 -----END PGP SIGNATURE----- --SkvwRMAIpAhPCcCJ-- From owner-freebsd-current@FreeBSD.ORG Thu Dec 11 09:40:42 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7975A1065673 for ; Thu, 11 Dec 2008 09:40:42 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.171]) by mx1.freebsd.org (Postfix) with ESMTP id 0D5D28FC1A for ; Thu, 11 Dec 2008 09:40:41 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: by ug-out-1314.google.com with SMTP id 30so188352ugs.39 for ; Thu, 11 Dec 2008 01:40:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=DkfPAI+TATGn0oZ0usSV/D6GAmIVONekF3/XTfWickA=; b=Wf+QlcQpTETF8CMPNLAEBqr2giIDyeItA4noUwhocyLcK8cPrmAP3vRSSR0WRCrhE8 huWOQ4stG2uxlWAdgHRbYvj4QcCTNP4O6Rlru442PueoKO/LS4JFlgth3Wwxf6jrITCo Q1pyPJA2f7nCKk3JvLWrpz1nZuxb75ZEA7nAM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=MyIGgaReh82uj5zrTcZ9EvJh1owL3evdLdO4bUGzvX2bfN5N386vG4DMOW+GkN8ttI mON4uC9Isd8ckvnu1+y6K0WOFmuQ3+J8Z2dRaX0xtkMl+urmPf+yDREHavp3pvhrw3sE sJOc+YOIc5MUi666FqPulpENDAVK5CDXFActU= Received: by 10.66.222.6 with SMTP id u6mr4763539ugg.19.1228988440855; Thu, 11 Dec 2008 01:40:40 -0800 (PST) Received: by 10.67.22.7 with HTTP; Thu, 11 Dec 2008 01:40:40 -0800 (PST) Message-ID: <7d6fde3d0812110140y44df387dg14f83c5483fe96ff@mail.gmail.com> Date: Thu, 11 Dec 2008 01:40:40 -0800 From: "Garrett Cooper" To: boolome In-Reply-To: <1228869506.1255.3.camel@www.boolome.cn> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1228555830.1186.6.camel@www.boolome.cn> <7d6fde3d0812080155y22cc7c0bne1fa0094671355e4@mail.gmail.com> <1228787330.13158.0.camel@www.boolome.cn> <53DC39AE-EE1E-41DE-801D-45737249D93B@gmail.com> <1228869506.1255.3.camel@www.boolome.cn> Cc: freebsd-current@freebsd.org Subject: Re: make buildworld failed! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Dec 2008 09:40:42 -0000 On Tue, Dec 9, 2008 at 4:38 PM, boolome wrote: > $B:_(B 2008-12-09$BFsE*(B 03:18 -0800$B!$(BGarrett Cooper$B> On Dec 8, 2008, at 5:48 PM, boolome wrote: >> >> > $B:_(B 2008-12-08$B0lE*(B 01:55 -0800$B!$(BGarrett Cooper$B> >> On Sat, Dec 6, 2008 at 1:30 AM, boolome wrote: >> >> [snip] >> >> >> >> Looks like your source tree is incomplete. >> >> -Garrett >> > >> > But have cvsup the latest source tree ! >> >> It's not necessarily your fault though. What cvsup server are you >> using and did you interrupt it during an update? >> -Garrett > > The cvsup server is cvsup.freebsd.org . > > During an update ,I did not interrupt it. > > But when I got to that dir executed :make obj && make depend && > make ,successed.. > > Is the soure tree's problem ? > By the way I 'am using a custom kernel . Hmmm.. not sure. If I had logs I could help you out more, but unfortunately I don't ;(. I'd chock it up to a bad build environment or maybe just bad prebuilt objs. -Garrett From owner-freebsd-current@FreeBSD.ORG Thu Dec 11 11:09:12 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 432471065670; Thu, 11 Dec 2008 11:09:12 +0000 (UTC) (envelope-from gary.jennejohn@freenet.de) Received: from mout0.freenet.de (mout0.freenet.de [IPv6:2001:748:100:40::2:2]) by mx1.freebsd.org (Postfix) with ESMTP id CDAFB8FC17; Thu, 11 Dec 2008 11:09:11 +0000 (UTC) (envelope-from gary.jennejohn@freenet.de) Received: from [195.4.92.27] (helo=17.mx.freenet.de) by mout0.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.69 #65) id 1LAjPq-000758-Da; Thu, 11 Dec 2008 12:09:10 +0100 Received: from mb4d6.m.pppool.de ([89.49.180.214]:22419 helo=ernst.jennejohn.org) by 17.mx.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.69 #68) id 1LAjPq-0002KU-3y; Thu, 11 Dec 2008 12:09:10 +0100 Date: Thu, 11 Dec 2008 12:09:08 +0100 From: Gary Jennejohn To: Anton Yuzhaninov Message-ID: <20081211120908.57f99124@ernst.jennejohn.org> In-Reply-To: <4940115F.7080004@citrin.ru> References: <200812080248.mB82mfV9043154@svn.freebsd.org> <4940115F.7080004@citrin.ru> X-Mailer: Claws Mail 3.5.0 (GTK+ 2.12.11; amd64-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: current@freebsd.org, Pyun YongHyeon Subject: Re: svn commit: r185756 - head/sys/dev/re X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gary.jennejohn@freenet.de List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Dec 2008 11:09:12 -0000 On Wed, 10 Dec 2008 21:58:39 +0300 Anton Yuzhaninov wrote: > Pyun YongHyeon wrote: > > Author: yongari > > Date: Mon Dec 8 02:48:41 2008 > > New Revision: 185756 > > URL: http://svn.freebsd.org/changeset/base/185756 > > > > Log: > > Reduce spin wait time consumed in GMII register access routines. > > Waiting for 1ms for each GMII register access looks overkill and it > > may also decrease overall performance of driver because re(4) > > invokes mii_tick for every hz. > > > > Tested by: rpaulo > > > > Modified: > > head/sys/dev/re/if_re.c > > > > Modified: head/sys/dev/re/if_re.c > > ============================================================================== > > --- head/sys/dev/re/if_re.c Mon Dec 8 02:38:13 2008 (r185755) > > +++ head/sys/dev/re/if_re.c Mon Dec 8 02:48:41 2008 (r185756) > > @@ -417,13 +417,12 @@ re_gmii_readreg(device_t dev, int phy, i > > } > > > > CSR_WRITE_4(sc, RL_PHYAR, reg << 16); > > - DELAY(1000); > > > > for (i = 0; i < RL_TIMEOUT; i++) { > > + DELAY(30); > > rval = CSR_READ_4(sc, RL_PHYAR); > > if (rval & RL_PHYAR_BUSY) > > break; > > - DELAY(100); > > } > > > > if (i == RL_TIMEOUT) { > > @@ -445,13 +444,12 @@ re_gmii_writereg(device_t dev, int phy, > > > > CSR_WRITE_4(sc, RL_PHYAR, (reg << 16) | > > (data & RL_PHYAR_PHYDATA) | RL_PHYAR_BUSY); > > - DELAY(1000); > > > > for (i = 0; i < RL_TIMEOUT; i++) { > > + DELAY(30); > > rval = CSR_READ_4(sc, RL_PHYAR); > > if (!(rval & RL_PHYAR_BUSY)) > > break; > > - DELAY(100); > > } > > > > if (i == RL_TIMEOUT) { > > After this commit I see in logs errors: > > Dec 10 21:37:42 citrin kernel: re0: PHY read failed > Dec 10 21:38:05 citrin last message repeated 3 times > Dec 10 21:38:44 citrin last message repeated 3 times > Dec 10 21:38:44 citrin kernel: re0: link state changed to DOWN > Dec 10 21:38:45 citrin kernel: re0: link state changed to UP > Dec 10 21:38:55 citrin kernel: re0: PHY read failed > Dec 10 21:39:38 citrin last message repeated 3 times > Dec 10 21:39:38 citrin kernel: re0: link state changed to DOWN > Dec 10 21:39:39 citrin kernel: re0: link state changed to UP > Dec 10 21:40:09 citrin kernel: re0: PHY read failed > Dec 10 21:40:21 citrin kernel: re0: PHY read failed > Dec 10 21:41:03 citrin kernel: re0: PHY read failed > > I tried to revert this patch - errors disappeared. > I was seeing these errors too, but disabling MSI made them disappear. --- Gary Jennejohn From owner-freebsd-current@FreeBSD.ORG Thu Dec 11 12:54:51 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DF31A106564A; Thu, 11 Dec 2008 12:54:51 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from redbull.bpaserver.net (redbullneu.bpaserver.net [213.198.78.217]) by mx1.freebsd.org (Postfix) with ESMTP id 4DBBA8FC1A; Thu, 11 Dec 2008 12:54:51 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from outgoing.leidinger.net (pD9E2DE31.dip.t-dialin.net [217.226.222.49]) by redbull.bpaserver.net (Postfix) with ESMTP id C24072E15C; Thu, 11 Dec 2008 13:54:43 +0100 (CET) Received: from webmail.leidinger.net (webmail.leidinger.net [192.168.1.102]) by outgoing.leidinger.net (Postfix) with ESMTP id E326E18DD8C; Thu, 11 Dec 2008 13:54:39 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=Leidinger.net; s=outgoing-alex; t=1229000080; bh=C+xXCrh5QqVWSJp3IOxCqYnWayngc0aB9 DaFmHkQ7NE=; h=Message-ID:Date:From:To:Cc:Subject:References: In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=rBN0t1fuCG5Hyf8ZLD3R5ppm+H60gYS4Q1jDVI5FXNfTaRQjt9SvrBvOHhWN1oR6U Wei65UFjgtmSAeu5GJiU9Wd54WGbOorrddMu6SwfUMjUuxX0s8qhmgp/+U7aA2KOeqJ IMBGOABiECDm8roPTQuL17WGd3E9X6rVqlngSODU5WPr9RSS9Hzlvu1icR8k1pP3XB9 OyExSo2dCfw8T1Kt/p08Mn2l5Y+AlNayuumz8uZ9on5Pio++rgUT9PULThf2FohWgeu KDkIZmXPzIJ+hsc9Km5sqIqJ1rc9LhHDInPyVPjPHZdo6V6Zlr9ftskWwvW/DmAifMJ ek82hh9sA== Received: (from www@localhost) by webmail.leidinger.net (8.14.3/8.13.8/Submit) id mBBCsdgU018136; Thu, 11 Dec 2008 13:54:39 +0100 (CET) (envelope-from Alexander@Leidinger.net) Received: from pslux.cec.eu.int (pslux.cec.eu.int [158.169.9.14]) by webmail.leidinger.net (Horde Framework) with HTTP; Thu, 11 Dec 2008 13:54:38 +0100 Message-ID: <20081211135438.52433nmj45ia112c@webmail.leidinger.net> X-Priority: 3 (Normal) Date: Thu, 11 Dec 2008 13:54:38 +0100 From: Alexander Leidinger To: Marius =?utf-8?b?TsO8bm5lcmljaA==?= References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.3) / FreeBSD-8.0 X-BPAnet-MailScanner-Information: Please contact the ISP for more information X-MailScanner-ID: C24072E15C.1B2A6 X-BPAnet-MailScanner: Found to be clean X-BPAnet-MailScanner-SpamCheck: not spam, ORDB-RBL, SpamAssassin (not cached, score=-14.6, required 6, BAYES_00 -15.00, DKIM_SIGNED 0.00, DKIM_VERIFIED -0.00, MIME_8BIT_HEADER 0.30, RDNS_DYNAMIC 0.10) X-BPAnet-MailScanner-From: alexander@leidinger.net X-Spam-Status: No Cc: jb@freebsd.org, FreeBSD Current , freebsd-geom@freebsd.org Subject: Re: DTrace probes for geom_kern, geom_io and geom_event X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Dec 2008 12:54:52 -0000 Quoting Marius N=C3=BCnnerich (from Wed, 10 Dec 2008 = =20 23:15:43 +0100): > After some tips from Alexander Leidinger I updated the patch, new =20 > version here: > http://nuenneri.ch/freebsd/geom_probes2.patch Again: I just reviewed the patch, so I don't have the complete context =20 of the functions, just what I see in the patch (-> high level dtrace =20 review, not geom specific probe review). Still inconsistent locking probes. Lock is fired without the lock =20 held, unlock is fired with the lock held. Both should IMHO be fired =20 either with the lock held or without the lock held, but not with the =20 current mix. g_new_bio/g_io_schedule_up: the return probe has the name "entry" in =20 your patch. A msleep probe could give some more info (sometimes there are even =20 zero arguments, but there are 3-5 things which could be interesting to =20 know). Similar for tsleep (the time should be provided in the probe =20 arguments too). I don't think we need "loop" probes. Given that g_trace is a debugging function and that dtrace is =20 superior, I don't think you need to instrument g_trace with dtrace =20 probes. g_topology_lock/unlock should provide the lock in the probe arguments. =20 Again, see above, either both probes firing with the lock, or without =20 the lock, but not mixed as it is. > There are some questions I'd like to discuss: > 2. Should I use the full function name for the probes (with the g_ > prefix) even though it's defined under the provider geom IMHO yes, it's more easy for the person grepping around, as "bioq" can =20 be found in a lot of unrelated places, but "g_bioq_init" only in =20 places where you want to know about. > 3. Should there be a probe for every switch case in g_io_check? I > think this won't work with the fall-through that is used right now IMHO at least in every code block which is doing something sensible. =20 Dtrace is not expensive, having a lot of probes does not hurt (except =20 maybe in a critical path). You could fire an read_not_permitted probe, =20 or a write_not_permitted probe or whatever. This can be done =20 additionally to the return probe. This way it's very easy to see if =20 there's a permission problem, without the need to write errno checks =20 in dtrace. If you have a lot of returns but only a handful of =20 permission errors, it's better to have some specific probes which can =20 be fired. Keep in mind dtrace is designed to be used to debug problems =20 on production systems. > 4. Alexander proposed to change the module name kern to core. I'm not > sure about this as kern refers to the filename, like io and event do - core for kern - core_io for io (maybe) - core_event for event (maybe) This way you can use gmirror, graid3, ... later as module names and =20 people/sysadmins without much GEOM knowledge don't have a problem to =20 see distinguish with real GEOM core stuff and stuff in GEOM providers. > 7. What about g_bioq_(un)lock functions, I just added one probe for > it, I do not really see a point in adding entry and return probes > (they are there with FBT anyway). This is consistent with > g_topology_lock etc. What about making macros of the two functions > like g_topology_lock Regarding FBT: the advantage of the geom dtrace-provider is that you =20 can tell to give everything for geom, while with with the fbt =20 dtrace-provider you need to know the naming conventions in the kernel. =20 So while you have in fbt the possibility to get access to the probes, =20 the sysadmin which does not know much about GEOM can get a meaningful =20 overview in case entry and return probes available in the geom =20 dtrace-provider. A lot of places in the kernel do not have a naming =20 convention like GEOM, so when we handle them (e.g. the linuxulator), =20 we need to add entry/return probes so that sysadmins without knowledge =20 about kernel internals can search for solutions of their problems. We =20 should be consistent in our probe naming, else it's not easy to use =20 dtrace. > 9. Writing hundreds of entry and return probes is boring, especially > as there is the FBT provider. Maybe it's possible to give the FBT > probes better names like geom:io:g_io_schedule_down:entry instead of > fbt:kernel:g_io_schedule:entry. Every FBT probe has a provider of fbt > und module of kernel right now. One also has to define the argument > types which I think FBT figures out by itself. If this would work we > could concentrate on adding SDT probes to interesting places inside of > functions or macros Both ways have good and bad parts. One argument against this is to =20 stay synchronized with vendor code. Another one is complexity to =20 handle this (currently the fbt part is automatic, I don't see a way to =20 handle related stuff which is spread into several places to within the =20 same namespace without introducing hints into different places which =20 tells what belongs where). HTH, Alexander. --=20 "They shot him five times. But he's though." =09=09-- Santino Corleone, "Chapter 2", page 79 http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID =3D B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID =3D 72077137 From owner-freebsd-current@FreeBSD.ORG Thu Dec 11 13:00:58 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1EF3A1065673 for ; Thu, 11 Dec 2008 13:00:58 +0000 (UTC) (envelope-from CQG00620@nifty.ne.jp) Received: from mail.asahi-net.or.jp (mail2.asahi-net.or.jp [202.224.39.198]) by mx1.freebsd.org (Postfix) with ESMTP id D63B88FC1C for ; Thu, 11 Dec 2008 13:00:57 +0000 (UTC) (envelope-from CQG00620@nifty.ne.jp) Received: from asahi-net.jp (l207029.dynamic.ppp.asahi-net.or.jp [218.219.207.29]) by mail.asahi-net.or.jp (Postfix) with ESMTP id 66F69590F5; Thu, 11 Dec 2008 22:00:56 +0900 (JST) Date: Thu, 11 Dec 2008 21:59:43 +0900 From: WATANABE Kazuhiro To: freebsd-current In-Reply-To: <200812101539.26031.jhb@freebsd.org> References: <20081210125627.25732615CD@mail.asahi-net.or.jp> <200812101539.26031.jhb@freebsd.org> User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.7 Emacs/21.3 (i386--freebsd) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20081211130056.66F69590F5@mail.asahi-net.or.jp> Cc: Subject: Re: [patch] de(4) has not worked on 8-current since Feb 13 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Dec 2008 13:00:58 -0000 Thanks for your quick reply. First, I restored busdma_machdep.c and applied your patch. Then I re-compiled a kernel and rebooted the system. Unfortunately it causes kernel panic when the system enters multi user mode. Here is an output of kgdb. $ kgdb /boot/kernel/kernel.symbols /var/crash/vmcore.0 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd"... Unread portion of the kernel message buffer: Copyright (c) 1992-2008 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-CURRENT #6: Thu Dec 11 13:45:26 JST 2008 nabe@capricorn:/FreeBSD/obj/i386/HEAD/FreeBSD/HEAD/src/sys/GENERIC WARNING: WITNESS option enabled, expect reduced performance. Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel Pentium III (751.71-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x681 Stepping = 1 Features=0x383f9ff real memory = 268435456 (256 MB) avail memory = 243986432 (232 MB) kbd1 at kbdmux0 ACPI Error (tbxfroot-0308): A valid RSDP was not found [20070320] ACPI: Table initialisation failed: AE_NOT_FOUND ACPI: Try disabling either ACPI or apic support. pcib0: pcibus 0 on motherboard pir0: on motherboard pci0: on pcib0 agp0: on hostb0 pcib1: at device 1.0 on pci0 pci1: on pcib1 vgapci0: port 0xc000-0xc0ff mem 0xd4000000-0xd4ffffff,0xd6000000-0xd6000fff irq 11 at device 0.0 on pci1 isab0: at device 7.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xf000-0xf00f at device 7.1 on pci0 ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] uhci0: port 0xd000-0xd01f irq 12 at device 7.2 on pci0 uhci0: [GIANT-LOCKED] uhci0: [ITHREAD] usb0: on uhci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 2 ports with 2 removable, self powered piix0: port 0x5000-0x500f at device 7.3 on pci0 Timecounter "PIIX" frequency 3579545 Hz quality 0 pci0: at device 9.0 (no driver attached) xl0: <3Com 3c905C-TX Fast Etherlink XL> port 0xd800-0xd87f mem 0xd9000000-0xd900007f irq 12 at device 11.0 on pci0 miibus0: on xl0 xlphy0: <3c905C 10/100 internal PHY> PHY 24 on miibus0 xlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto xl0: Ethernet address: 00:50:04:xx:xx:xx xl0: [ITHREAD] pci0: at device 13.0 (no driver attached) de0: port 0xe000-0xe07f mem 0xd9001000-0xd900107f irq 11 at device 15.0 on pci0 de0: 21140A [10-100Mb/s] pass 2.2 de0: WARNING: using obsoleted if_watchdog interface de0: Ethernet address: 00:00:f4:xx:xx:xx de0: [ITHREAD] cpu0 on motherboard smist0: on cpu0 device_attach: smist0 attach returned 6 pmtimer0 on isa0 atrtc0: at port 0x70-0x71 irq 8 pnpid PNP0b00 on isa0 atkbdc0: at port 0x60,0x64 irq 1 pnpid PNP0303 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] unknown: can't assign resources (memory) unknown: can't assign resources (port) uart0: <16550 or compatible> at port 0x3f8-0x3ff irq 4 flags 0x10 pnpid PNP0501 on isa0 uart0: [FILTER] uart0: console (9600,n,8,1) fdc1: at port 0x3f2-0x3f5,0x3f7 irq 6 drq 2 pnpid PNP0700 on isa0 fdc1: [FILTER] ppc0: at port 0x378-0x37f irq 7 pnpid PNP0400 on isa0 ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode ppc0: [GIANT-LOCKED] ppc0: [ITHREAD] ppbus0: on ppc0 plip0: on ppbus0 plip0: WARNING: using obsoleted IFF_NEEDSGIANT flag lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 uart1: <16550 or compatible> at port 0x2f8-0x2ff irq 3 pnpid PNP0501 on isa0 uart1: [FILTER] orm0: at iomem 0xc0000-0xc97ff,0xcc000-0xcc7ff pnpid ORM0000 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x100> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 fdc0: No FDOUT register! unknown: can't assign resources (memory) unknown: can't assign resources (port) Timecounter "TSC" frequency 751707385 Hz quality 800 Timecounters tick every 1.000 msec ad0: 6194MB at ata0-master UDMA33 acd0: CDROM at ata0-slave PIO4 WARNING: WITNESS option enabled, expect reduced performance. Trying to mount root from ufs:/dev/ad0s2a lock order reversal: 1st 0xc2951044 user map (user map) @ /FreeBSD/HEAD/src/sys/vm/vm_map.c:3115 2nd 0xc2ac87ac ufs (ufs) @ /FreeBSD/HEAD/src/sys/kern/vfs_subr.c:2079 KDB: stack backtrace: db_trace_self_wrapper(c0be23c3,c267b90c,c08729c5,4,c0bdd802,...) at db_trace_self_wrapper+0x26 kdb_backtrace(4,c0bdd802,c2905728,c2909f78,c267b968,...) at kdb_backtrace+0x29 _witness_debugger(c0be50ba,c2ac87ac,c0bd88ba,c2909f78,c0bebfa9,...) at _witness_debugger+0x25 witness_checkorder(c2ac87ac,1,c0bebfa9,81f,0,...) at witness_checkorder+0x839 __lockmgr_args(c2ac87ac,200501,c2ac87c8,0,0,...) at __lockmgr_args+0x237 ffs_lock(c267ba78,c087276b,c0c083c6,200501,c2ac8754,...) at ffs_lock+0x8a VOP_LOCK1_APV(c0ce88e0,c267ba78,c294ce24,c0cfc9c0,c2ac8754,...) at VOP_LOCK1_APV+0xa5 _vn_lock(c2ac8754,200501,c0bebfa9,81f,4,...) at _vn_lock+0x5e vget(c2ac8754,200501,c294cd80,4b4,0,...) at vget+0xc9 vnode_pager_lock(c187d744,0,c0c0592a,127,c267bc18,...) at vnode_pager_lock+0x1e0 vm_fault(c2951000,80db000,2,8,80db460,...) at vm_fault+0x1df trap_pfault(5,0,c0c15785,2e7,c294ad34,...) at trap_pfault+0x118 trap(c267bd38) at trap+0x289 calltrap() at calltrap+0x6 --- trap 0xc, eip = 0x80480e5, esp = 0xbfbfeef0, ebp = 0xbfbfef10 --- <118>Entropy harvesting: <118> interrupts <118> ethernet <118> point_to_point <118> kickstart <118>. <118>/dev/ad0s2a: FILE SYSTEM CLEAN; SKIPPING CHECKS <118>/dev/ad0s2a: clean, 338407 free (4679 frags, 41716 blocks, 0.9% fragmentation) Kernel page fault with the following non-sleepable locks held: exclusive sleep mutex network driver (de0) r = 0 (0xc2a3ec40) locked @ /FreeBSD/HEAD/src/sys/dev/de/if_de.c:3880 KDB: stack backtrace: db_trace_self_wrapper(c0be23c3,c2727a54,c08729c5,c0babaac,f28,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c0babaac,f28,ffffffff,c0e71824,c2727a8c,...) at kdb_backtrace+0x29 _witness_debugger(c0be4685,c2727aa0,4,1,0,...) at _witness_debugger+0x25 witness_warn(5,0,c0c15785,c2a67480,c294a7ec,...) at witness_warn+0x1fd trap(c2727b2c) at trap+0x152 calltrap() at calltrap+0x6 --- trap 0xc, eip = 0xc0b11bd8, esp = 0xc2727b6c, ebp = 0xc2727b88 --- _bus_dmamap_count_pages(c2a46600,1533000,c2c2d000,7f0,1,...) at _bus_dmamap_count_pages+0x18 bus_dmamap_load_mbuf(c2a46600,1533000,c2beab00,c05ed570,c2720040,...) at bus_dmamap_load_mbuf+0xb4 tulip_rx_intr(c2a3ec40,4,c0babaac,e0f,0,...) at tulip_rx_intr+0x45c tulip_tx_intr(c2a3ec40,4,c0babaac,eba,c2a3e800,...) at tulip_tx_intr+0xf9 tulip_intr_handler(c2a3ec40,0,c0babaac,f28,c2a38cc0,...) at tulip_intr_handler+0x2a4 tulip_intr_normal(c2a3e800,0,0,0,c2947bb8,...) at tulip_intr_normal+0x3c intr_event_execute_handlers(c294a7ec,c2947b80,c0d35580,c2727cf8,c2947bf0,...) at intr_event_execute_handlers+0x125 ithread_loop(c2a615a0,c2727d38,c0bdaf6d,32d,c294a7ec,...) at ithread_loop+0x9f fork_exit(c0813920,c2a615a0,c2727d38) at fork_exit+0xb8 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xc2727d70, ebp = 0 --- Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x1533008 fault code = supervisor read, page not present instruction pointer = 0x20:0xc0b11bd8 stack pointer = 0x28:0xc2727b6c frame pointer = 0x28:0xc2727b88 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 12 (irq11: de0) panic: from debugger cpuid = 0 Uptime: 24s Physical memory: 239 MB Dumping 32 MB: 17 1 #0 doadump () at pcpu.h:246 246 pcpu.h: No such file or directory. in pcpu.h (kgdb) bt #0 doadump () at pcpu.h:246 #1 0xc08338ce in boot (howto=260) at /FreeBSD/HEAD/src/sys/kern/kern_shutdown.c:420 #2 0xc0833ba2 in panic (fmt=Variable "fmt" is not available. ) at /FreeBSD/HEAD/src/sys/kern/kern_shutdown.c:576 #3 0xc04bd387 in db_panic (addr=Could not find the frame base for "db_panic". ) at /FreeBSD/HEAD/src/sys/ddb/db_command.c:478 #4 0xc04bd9b1 in db_command (last_cmdp=0xc0cfe0dc, cmd_table=0x0, dopager=1) at /FreeBSD/HEAD/src/sys/ddb/db_command.c:445 #5 0xc04bdb0a in db_command_loop () at /FreeBSD/HEAD/src/sys/ddb/db_command.c:498 #6 0xc04bf96d in db_trap (type=12, code=0) at /FreeBSD/HEAD/src/sys/ddb/db_main.c:229 #7 0xc08611b6 in kdb_trap (type=12, code=0, tf=0xc2727b2c) at /FreeBSD/HEAD/src/sys/kern/subr_kdb.c:534 #8 0xc0b3152f in trap_fatal (frame=0xc2727b2c, eva=22229000) at /FreeBSD/HEAD/src/sys/i386/i386/trap.c:920 #9 0xc0b31e70 in trap (frame=0xc2727b2c) at /FreeBSD/HEAD/src/sys/i386/i386/trap.c:318 #10 0xc0b162ab in calltrap () at /FreeBSD/HEAD/src/sys/i386/i386/exception.s:165 #11 0x01533008 in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) list /FreeBSD/HEAD/src/sys/dev/de/if_de.c:3880 3875 static void 3876 tulip_intr_normal(void *arg) 3877 { 3878 tulip_softc_t * sc = (tulip_softc_t *) arg; 3879 3880 TULIP_LOCK(sc); 3881 #if defined(TULIP_DEBUG) 3882 sc->tulip_dbg.dbg_intrs++; 3883 #endif 3884 tulip_intr_handler(sc); (kgdb) At Wed, 10 Dec 2008 15:39:25 -0500, John Baldwin wrote: > On Wednesday 10 December 2008 07:56:25 am WATANABE Kazuhiro wrote: > > Hi, all. > > > > My de(4) NICs has not worked on 8-current since Feb 13. > > Try this patch to de(4) instead. It removes the alignment requirement for TX > buffers since the 4-byte alignment is only required for RX. > > Index: if_de.c > =================================================================== > --- if_de.c (revision 185867) > +++ if_de.c (working copy) > @@ -4491,7 +4491,8 @@ > /* Allocate memory for a single descriptor ring. */ > static int > tulip_busdma_allocring(device_t dev, tulip_softc_t * const sc, size_t count, > - bus_size_t maxsize, int nsegs, tulip_ringinfo_t *ri, const char *name) > + bus_size_t alignment, bus_size_t maxsize, int nsegs, tulip_ringinfo_t *ri, > + const char *name) > { > size_t size; > int error, i; > @@ -4527,7 +4528,7 @@ > } > > /* Allocate a tag for the data buffers. */ > - error = bus_dma_tag_create(NULL, 4, 0, > + error = bus_dma_tag_create(NULL, alignment, 0, > BUS_SPACE_MAXADDR_32BIT, BUS_SPACE_MAXADDR, NULL, NULL, > maxsize, nsegs, TULIP_DATA_PER_DESC, 0, NULL, NULL, &ri->ri_data_tag); > if (error) { > @@ -4586,8 +4587,8 @@ > /* > * Allocate space and dmamap for transmit ring. > */ > - error = tulip_busdma_allocring(dev, sc, TULIP_TXDESCS, TULIP_DATA_PER_DESC, > - TULIP_MAX_TXSEG, &sc->tulip_txinfo, "transmit"); > + error = tulip_busdma_allocring(dev, sc, 1, TULIP_TXDESCS, > + TULIP_DATA_PER_DESC, TULIP_MAX_TXSEG, &sc->tulip_txinfo, "transmit"); > if (error) > return (error); > > @@ -4598,7 +4599,7 @@ > * a waste in practice though as an ethernet frame can easily fit > * in TULIP_RX_BUFLEN bytes. > */ > - error = tulip_busdma_allocring(dev, sc, TULIP_RXDESCS, MCLBYTES, 1, > + error = tulip_busdma_allocring(dev, sc, 4, TULIP_RXDESCS, MCLBYTES, 1, > &sc->tulip_rxinfo, "receive"); > if (error) > return (error); --- WATANABE Kazuhiro (CQG00620@nifty.ne.jp) From owner-freebsd-current@FreeBSD.ORG Thu Dec 11 13:00:58 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BB5F61065675 for ; Thu, 11 Dec 2008 13:00:58 +0000 (UTC) (envelope-from CQG00620@nifty.ne.jp) Received: from mail.asahi-net.or.jp (mail1.asahi-net.or.jp [202.224.39.197]) by mx1.freebsd.org (Postfix) with ESMTP id 68CB08FC29 for ; Thu, 11 Dec 2008 13:00:58 +0000 (UTC) (envelope-from CQG00620@nifty.ne.jp) Received: from asahi-net.jp (l207029.dynamic.ppp.asahi-net.or.jp [218.219.207.29]) by mail.asahi-net.or.jp (Postfix) with ESMTP id B53EE5D0A4; Thu, 11 Dec 2008 22:00:57 +0900 (JST) Date: Thu, 11 Dec 2008 22:00:42 +0900 From: WATANABE Kazuhiro To: Scott Long In-Reply-To: <494019AB.3020505@samsco.org> References: <20081210125627.25732615CD@mail.asahi-net.or.jp> <494019AB.3020505@samsco.org> User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.7 Emacs/21.3 (i386--freebsd) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20081211130057.B53EE5D0A4@mail.asahi-net.or.jp> Cc: freebsd-current Subject: Re: [patch] de(4) has not worked on 8-current since Feb 13 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Dec 2008 13:00:58 -0000 CC'ed to freebsd-current. At Wed, 10 Dec 2008 12:34:03 -0700, Scott Long wrote: > WATANABE Kazuhiro wrote: > > Hi, all. > > > > My de(4) NICs has not worked on 8-current since Feb 13. > > > > > > Can you define "not worked" a little better? Does it give errors, or > corrupt data, or appear to not transmit and/or receive? > > Scott Thanks for your reply. I should have written more details about the problem... On recent 8-current, my de(4) NICs cannot send any (almost all) data from it. * The system boots normally. * Probing/attaching the de(4) NICs are done successfully. * The system can receive data from the other hosts. For example the following command was finished normally in 14 seconds: $ /usr/bin/time scp other_host:/boot/kernel/kernel . Password: kernel 100% 4717KB 471.7KB/s 00:10 14.03 real 0.53 user 0.40 sys $ * The system cannot send any data to the other hosts. For example the following command was "stalled" and never finished (I interrupted the command after 5 minutes). None of the data were sent: $ /usr/bin/time scp /boot/kernel/kernel other_host: Password: kernel 1% 192KB 0.0KB/s - stalled -^CKilled by signal 2. 336.01 real 0.05 user 0.17 sys $ * The system doesn't show any error/warning messages. * I can "slogin" from the other hosts to the system, and some small amount of text output (ex. an output of "dmesg") are done successfully. But a bit large amount of text output are stopped after a few seconds. For example: $ ls -l /boot/kernel/kernel -r-xr-xr-x 1 root wheel 10975839 Dec 11 13:46 /boot/kernel/kernel $ hd /boot/kernel/kernel | head 00000000 7f 45 4c 46 01 01 01 09 00 00 00 00 00 00 00 00 |.ELF............| 00000010 02 00 03 00 01 00 00 00 e0 c5 46 c0 34 00 00 00 |..........F.4...| 00000020 58 22 92 00 00 00 00 00 34 00 20 00 05 00 28 00 |X"......4. ...(.| 00000030 23 00 20 00 06 00 00 00 34 00 00 00 34 00 40 c0 |#. .....4...4.@.| 00000040 34 00 40 c0 a0 00 00 00 a0 00 00 00 05 00 00 00 |4.@.............| 00000050 04 00 00 00 03 00 00 00 d4 00 00 00 d4 00 40 c0 |..............@.| 00000060 d4 00 40 c0 0d 00 00 00 0d 00 00 00 04 00 00 00 |..@.............| 00000070 01 00 00 00 01 00 00 00 00 00 00 00 00 00 40 c0 |..............@.| 00000080 00 00 40 c0 a0 ca 81 00 a0 ca 81 00 05 00 00 00 |..@.............| 00000090 00 10 00 00 01 00 00 00 a0 ca 81 00 a0 da c1 c0 |................| $ hd /boot/kernel/kernel 00000000 7f 45 4c 46 01 01 01 09 00 00 00 00 00 00 00 00 |.ELF............| 00000010 02 00 03 00 01 00 00 00 e0 c5 46 c0 34 00 00 00 |..........F.4...| 00000020 58 22 92 00 00 00 00 00 34 00 20 00 05 00 28 00 |X"......4. ...(.| 00000030 23 00 20 00 06 00 00 00 34 00 00 00 34 00 40 c0 |#. .....4...4.@.| 00000040 34 00 40 c0 a0 00 00 00 a0 00 00 00 05 00 00 00 |4.@.............| (snip) 00005d90 0a 20 00 00 0b 00 00 00 00 00 00 00 70 15 00 00 |. ..........p...| 00005da0 ce 2a 00 00 36 23 00 00 c6 2a 00 00 0b 14 00 00 |.*..6#...*......| 00005db0 7c 03 00 00 b1 27 00 00 d9 1e 00 00 2e 15 00 00 ||....'..........| 00005dc0 00 00 00 00 6d 22 00 00 04 2a 00 00 72 23 00 00 |....m"...*..r#..| 00005dd0 00 00 00 00 00 00 00 00 d3 1f 00 00 00 00 00 00 |................| (Stopped here. 0x5de0 == 24032 bytes) --- WATANABE Kazuhiro (CQG00620@nifty.ne.jp) From owner-freebsd-current@FreeBSD.ORG Thu Dec 11 14:16:56 2008 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 20AA81065672 for ; Thu, 11 Dec 2008 14:16:56 +0000 (UTC) (envelope-from bsam@ipt.ru) Received: from services.ipt.ru (services.ipt.ru [194.62.233.110]) by mx1.freebsd.org (Postfix) with ESMTP id 878028FC12 for ; Thu, 11 Dec 2008 14:16:55 +0000 (UTC) (envelope-from bsam@ipt.ru) Received: from bb.ipt.ru ([194.62.233.89]) by services.ipt.ru with esmtp (Exim 4.54 (FreeBSD)) id 1LAmLV-000HD5-Qq; Thu, 11 Dec 2008 17:16:53 +0300 To: Marcel Moolenaar References: <92804393@bb.ipt.ru> <26722819@bb.ipt.ru> <26719629@bb.ipt.ru> <19F75E66-0535-4982-9726-E2C0A03117EA@mac.com> From: Boris Samorodov Date: Thu, 11 Dec 2008 17:16:53 +0300 In-Reply-To: <19F75E66-0535-4982-9726-E2C0A03117EA@mac.com> (Marcel Moolenaar's message of "Wed\, 10 Dec 2008 17\:00\:24 -0800") Message-ID: <05268378@bb.ipt.ru> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-current@FreeBSD.org, rea-fbsd@codelabs.ru Subject: Re: Timeda 8-multiport adapter: only 2 ports available X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Dec 2008 14:16:56 -0000 Marcel Moolenaar writes: > On Dec 10, 2008, at 4:02 PM, Boris Samorodov wrote: > >> Seems that just the same card should work: >> http://lists.freebsd.org/pipermail/freebsd-stable/2008-May/042505.html >> >> I've added some diagnistic. But 'rid' is not what you want, I guess: > > The RID is fine. It should always be 0. > > * >> uart4: /usr/src/sys/dev/uart/uart_core.c:374: continue with rid=0x0 > >> ns8250_probe: no errors, exiting > * >> uart4: /usr/src/sys/dev/uart/uart_core.c:374: continue with rid=0x0 >> ns8250_probe: no errors, exiting > * >> uart5: /usr/src/sys/dev/uart/uart_core.c:374: continue with rid=0x0 >> ns8250_probe: no errors, exiting > * >> uart5: /usr/src/sys/dev/uart/uart_core.c:374: continue with rid=0x0 >> ns8250_probe: no errors, exiting > * >> uart6: /usr/src/sys/dev/uart/uart_core.c:374: continue with rid=0x0 >> ns8250_probe: got MCR wrong register, exiting with ENXIO > * >> uart6: /usr/src/sys/dev/uart/uart_core.c:374: continue with rid=0x0 >> ns8250_probe: got MCR wrong register, exiting with ENXIO > * >> uart6: /usr/src/sys/dev/uart/uart_core.c:374: continue with rid=0x0 >> ns8250_probe: got MCR wrong register, exiting with ENXIO > * >> uart6: /usr/src/sys/dev/uart/uart_core.c:374: continue with rid=0x0 >> ns8250_probe: got MCR wrong register, exiting with ENXIO > * >> uart6: /usr/src/sys/dev/uart/uart_core.c:374: continue with rid=0x0 >> ns8250_probe: got MCR wrong register, exiting with ENXIO > * >> uart6: /usr/src/sys/dev/uart/uart_core.c:374: continue with rid=0x0 >> ns8250_probe: got MCR wrong register, exiting with ENXIO > > It looks like the mapping is wrong. That is, uart(4) gets to > probe 8 ports but rejects 6. I would add debugging information > to puc(4) and in particular to where resources are assigned > to ports so that we can see what the BAR and offsets within the > BAR are for each port. If I understand you correctly, here it is: ----- pci5: on pcib5 pci5: domain=0, physical bus=5 found-> vendor=0x1409, dev=0x7168, revid=0x01 domain=0, bus=5, slot=2, func=0 class=07-00-02, hdrtype=0x00, mfdev=0 cmdreg=0x0081, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=5 map[10]: type I/O Port, range 32, base 0xec00, size 5, enabled pcib5: requested I/O range 0xec00-0xec1f: in range map[14]: type I/O Port, range 32, base 0xe880, size 4, enabled pcib5: requested I/O range 0xe880-0xe88f: in range map[18]: type I/O Port, range 32, base 0xe800, size 3, enabled pcib5: requested I/O range 0xe800-0xe807: in range map[1c]: type I/O Port, range 32, base 0xe480, size 3, enabled pcib5: requested I/O range 0xe480-0xe487: in range map[20]: type I/O Port, range 32, base 0xe400, size 3, enabled pcib5: requested I/O range 0xe400-0xe407: in range map[24]: type I/O Port, range 32, base 0xe080, size 3, enabled pcib5: requested I/O range 0xe080-0xe087: in range pcib5: matched entry for 5.2.INTA pcib5: slot 2 INTA hardwired to IRQ 18 puc_config_timedia: entering with command 4 puc_config_timedia: command PUC_CFG_GET_NPORTS, result = 8, no errors, exiting puc_config_timedia: entering with command 1 puc_config_timedia: command PUC_CFG_GET_DESC, exiting puc_config_timedia: entering with command 4 puc_config_timedia: command PUC_CFG_GET_NPORTS, result = 8, no errors, exiting puc_config_timedia: entering with command 1 puc_config_timedia: command PUC_CFG_GET_DESC, exiting puc0: port 0xec00-0xec1f,0xe880-0xe88f,0xe800-0xe807,0xe480-0xe487,0xe400-0xe407,0xe080-0xe087 irq 18 at device 2.0 on pci5 puc_config_timedia: entering with command 4 puc_config_timedia: command PUC_CFG_GET_NPORTS, result = 8, no errors, exiting puc_config_timedia: entering with command 8 puc_config_timedia: command default, no (?) errors, exiting puc_config_timedia: error ENXIO, exiting puc_config_timedia: entering with command 7 puc_config_timedia: command PUC_CFG_GET_TYPE, result = 1, no errors, exiting puc_config_timedia: entering with command 6 puc_config_timedia: command PUC_CFG_GET_RID, result = 16, no errors, exiting puc0: Reserved 0x20 bytes for rid 0x10 type 4 at 0xec00 puc_config_timedia: entering with command 5 puc_config_timedia: command PUC_CFG_GET_OFS, result = 0, no errors, exiting puc_config_timedia: entering with command 3 puc_config_timedia: command default, no (?) errors, exiting puc_config_timedia: error ENXIO, exiting puc_config_timedia: entering with command 0 puc_config_timedia: command default, no (?) errors, exiting puc_config_timedia: error ENXIO, exiting puc_config_timedia: entering with command 7 puc_config_timedia: command PUC_CFG_GET_TYPE, result = 1, no errors, exiting puc_config_timedia: entering with command 6 puc_config_timedia: command PUC_CFG_GET_RID, result = 16, no errors, exiting puc_config_timedia: entering with command 5 puc_config_timedia: command PUC_CFG_GET_OFS, result = 8, no errors, exiting puc_config_timedia: entering with command 3 puc_config_timedia: command default, no (?) errors, exiting puc_config_timedia: error ENXIO, exiting puc_config_timedia: entering with command 0 puc_config_timedia: command default, no (?) errors, exiting puc_config_timedia: error ENXIO, exiting puc_config_timedia: entering with command 7 puc_config_timedia: command PUC_CFG_GET_TYPE, result = 1, no errors, exiting puc_config_timedia: entering with command 6 puc_config_timedia: command PUC_CFG_GET_RID, result = 20, no errors, exiting puc0: Reserved 0x10 bytes for rid 0x14 type 4 at 0xe880 puc_config_timedia: entering with command 5 puc_config_timedia: command PUC_CFG_GET_OFS, result = 0, no errors, exiting puc_config_timedia: entering with command 3 puc_config_timedia: command default, no (?) errors, exiting puc_config_timedia: error ENXIO, exiting puc_config_timedia: entering with command 0 puc_config_timedia: command default, no (?) errors, exiting puc_config_timedia: error ENXIO, exiting puc_config_timedia: entering with command 7 puc_config_timedia: command PUC_CFG_GET_TYPE, result = 1, no errors, exiting puc_config_timedia: entering with command 6 puc_config_timedia: command PUC_CFG_GET_RID, result = 20, no errors, exiting puc_config_timedia: entering with command 5 puc_config_timedia: command PUC_CFG_GET_OFS, result = 8, no errors, exiting puc_config_timedia: entering with command 3 puc_config_timedia: command default, no (?) errors, exiting puc_config_timedia: error ENXIO, exiting puc_config_timedia: entering with command 0 puc_config_timedia: command default, no (?) errors, exiting puc_config_timedia: error ENXIO, exiting puc_config_timedia: entering with command 7 puc_config_timedia: command PUC_CFG_GET_TYPE, result = 1, no errors, exiting puc_config_timedia: entering with command 6 puc_config_timedia: command PUC_CFG_GET_RID, result = 24, no errors, exiting puc0: Reserved 0x8 bytes for rid 0x18 type 4 at 0xe800 puc_config_timedia: entering with command 5 puc_config_timedia: command PUC_CFG_GET_OFS, result = 0, no errors, exiting puc_config_timedia: entering with command 3 puc_config_timedia: command default, no (?) errors, exiting puc_config_timedia: error ENXIO, exiting puc_config_timedia: entering with command 0 puc_config_timedia: command default, no (?) errors, exiting puc_config_timedia: error ENXIO, exiting puc_config_timedia: entering with command 7 puc_config_timedia: command PUC_CFG_GET_TYPE, result = 1, no errors, exiting puc_config_timedia: entering with command 6 puc_config_timedia: command PUC_CFG_GET_RID, result = 28, no errors, exiting puc0: Reserved 0x8 bytes for rid 0x1c type 4 at 0xe480 puc_config_timedia: entering with command 5 puc_config_timedia: command PUC_CFG_GET_OFS, result = 0, no errors, exiting puc_config_timedia: entering with command 3 puc_config_timedia: command default, no (?) errors, exiting puc_config_timedia: error ENXIO, exiting puc_config_timedia: entering with command 0 puc_config_timedia: command default, no (?) errors, exiting puc_config_timedia: error ENXIO, exiting puc_config_timedia: entering with command 7 puc_config_timedia: command PUC_CFG_GET_TYPE, result = 1, no errors, exiting puc_config_timedia: entering with command 6 puc_config_timedia: command PUC_CFG_GET_RID, result = 32, no errors, exiting puc0: Reserved 0x8 bytes for rid 0x20 type 4 at 0xe400 puc_config_timedia: entering with command 5 puc_config_timedia: command PUC_CFG_GET_OFS, result = 0, no errors, exiting puc_config_timedia: entering with command 3 puc_config_timedia: command default, no (?) errors, exiting puc_config_timedia: error ENXIO, exiting puc_config_timedia: entering with command 0 puc_config_timedia: command default, no (?) errors, exiting puc_config_timedia: error ENXIO, exiting puc_config_timedia: entering with command 7 puc_config_timedia: command PUC_CFG_GET_TYPE, result = 1, no errors, exiting puc_config_timedia: entering with command 6 puc_config_timedia: command PUC_CFG_GET_RID, result = 36, no errors, exiting puc0: Reserved 0x8 bytes for rid 0x24 type 4 at 0xe080 puc_config_timedia: entering with command 5 puc_config_timedia: command PUC_CFG_GET_OFS, result = 0, no errors, exiting puc_config_timedia: entering with command 3 puc_config_timedia: command default, no (?) errors, exiting puc_config_timedia: error ENXIO, exiting puc_config_timedia: entering with command 0 puc_config_timedia: command default, no (?) errors, exiting puc_config_timedia: error ENXIO, exiting puc_config_timedia: entering with command 2 puc_config_timedia: command default, no (?) errors, exiting puc_config_timedia: error ENXIO, exiting puc0: [FILTER] ----- WBR -- Boris Samorodov (bsam) Research Engineer, http://www.ipt.ru Telephone & Internet SP FreeBSD committer, http://www.FreeBSD.org The Power To Serve From owner-freebsd-current@FreeBSD.ORG Thu Dec 11 14:36:29 2008 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9EAE61065673 for ; Thu, 11 Dec 2008 14:36:29 +0000 (UTC) (envelope-from bsam@ipt.ru) Received: from services.ipt.ru (services.ipt.ru [194.62.233.110]) by mx1.freebsd.org (Postfix) with ESMTP id 2BBFF8FC14 for ; Thu, 11 Dec 2008 14:36:29 +0000 (UTC) (envelope-from bsam@ipt.ru) Received: from bb.ipt.ru ([194.62.233.89]) by services.ipt.ru with esmtp (Exim 4.54 (FreeBSD)) id 1LAmeS-000HS7-7Z; Thu, 11 Dec 2008 17:36:28 +0300 To: rea-fbsd@codelabs.ru References: <92804393@bb.ipt.ru> <26722819@bb.ipt.ru> <26719629@bb.ipt.ru> <19F75E66-0535-4982-9726-E2C0A03117EA@mac.com> From: Boris Samorodov Date: Thu, 11 Dec 2008 17:36:27 +0300 In-Reply-To: (Eygene Ryabinkin's message of "Thu\, 11 Dec 2008 11\:50\:24 +0300") Message-ID: <94541668@bb.ipt.ru> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-current@FreeBSD.org, Marcel Moolenaar Subject: Re: Timeda 8-multiport adapter: only 2 ports available X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Dec 2008 14:36:29 -0000 Hello Eygene, Marcel and All, I've found some DOS/Linux docs/programs at the producers's site and unzipped them: ftp://ftp.ipt.ru/pub/sunix/ Eygene Ryabinkin writes: > Boris, could you please add the line > ----- > printf("%s: BAS, handle is 0x%lx, tag is 0x%x\n", __func__, > (unsigned long)bas->bsh, (unsigned int)bas->bst); > ----- > to the beginning of ns8250_probe() and show the results. Here it is: % dmesg | grep -A2 -B3 BAS ----- uart4: /usr/src/sys/dev/uart/uart_core.c:374: continue with rid=0x0 ns8250_bus_probe: entering ns8250_probe: entering ns8250_probe: BAS, handle is 0xec00, tag is 0x0 ns8250_probe: got IIR register: 0x1 ns8250_probe: got MCR register: 0x0 -- uart4: /usr/src/sys/dev/uart/uart_core.c:374: continue with rid=0x0 ns8250_bus_probe: entering ns8250_probe: entering ns8250_probe: BAS, handle is 0xec00, tag is 0x0 ns8250_probe: got IIR register: 0xc1 ns8250_probe: got MCR register: 0x8 -- uart5: /usr/src/sys/dev/uart/uart_core.c:374: continue with rid=0x0 ns8250_bus_probe: entering ns8250_probe: entering ns8250_probe: BAS, handle is 0xec08, tag is 0x0 ns8250_probe: got IIR register: 0x1 ns8250_probe: got MCR register: 0x0 -- uart5: /usr/src/sys/dev/uart/uart_core.c:374: continue with rid=0x0 ns8250_bus_probe: entering ns8250_probe: entering ns8250_probe: BAS, handle is 0xec08, tag is 0x0 ns8250_probe: got IIR register: 0xc1 ns8250_probe: got MCR register: 0x8 -- uart6: /usr/src/sys/dev/uart/uart_core.c:374: continue with rid=0x0 ns8250_bus_probe: entering ns8250_probe: entering ns8250_probe: BAS, handle is 0xe880, tag is 0x0 ns8250_probe: got IIR register: 0x1 ns8250_probe: got MCR register: 0x40 -- uart6: /usr/src/sys/dev/uart/uart_core.c:374: continue with rid=0x0 ns8250_bus_probe: entering ns8250_probe: entering ns8250_probe: BAS, handle is 0xe888, tag is 0x0 ns8250_probe: got IIR register: 0x1 ns8250_probe: got MCR register: 0x40 -- uart6: /usr/src/sys/dev/uart/uart_core.c:374: continue with rid=0x0 ns8250_bus_probe: entering ns8250_probe: entering ns8250_probe: BAS, handle is 0xe800, tag is 0x0 ns8250_probe: got IIR register: 0x1 ns8250_probe: got MCR register: 0x40 -- uart6: /usr/src/sys/dev/uart/uart_core.c:374: continue with rid=0x0 ns8250_bus_probe: entering ns8250_probe: entering ns8250_probe: BAS, handle is 0xe480, tag is 0x0 ns8250_probe: got IIR register: 0x1 ns8250_probe: got MCR register: 0x40 -- uart6: /usr/src/sys/dev/uart/uart_core.c:374: continue with rid=0x0 ns8250_bus_probe: entering ns8250_probe: entering ns8250_probe: BAS, handle is 0xe400, tag is 0x0 ns8250_probe: got IIR register: 0x1 ns8250_probe: got MCR register: 0x40 -- uart6: /usr/src/sys/dev/uart/uart_core.c:374: continue with rid=0x0 ns8250_bus_probe: entering ns8250_probe: entering ns8250_probe: BAS, handle is 0xe080, tag is 0x0 ns8250_probe: got IIR register: 0x1 ns8250_probe: got MCR register: 0x40 -- uart0: /usr/src/sys/dev/uart/uart_core.c:374: continue with rid=0x0 ns8250_bus_probe: entering ns8250_probe: entering ns8250_probe: BAS, handle is 0x3f8, tag is 0x0 ns8250_probe: got IIR register: 0x1 ns8250_probe: got MCR register: 0x0 -- uart0: /usr/src/sys/dev/uart/uart_core.c:374: continue with rid=0x0 ns8250_bus_probe: entering ns8250_probe: entering ns8250_probe: BAS, handle is 0x3f8, tag is 0x0 ns8250_probe: got IIR register: 0xc1 ns8250_probe: got MCR register: 0x8 -- uart1: /usr/src/sys/dev/uart/uart_core.c:374: continue with rid=0x0 ns8250_bus_probe: entering ns8250_probe: entering ns8250_probe: BAS, handle is 0x2f8, tag is 0x0 ns8250_probe: got IIR register: 0xff ns8250_probe: got wrong IIR register, exiting with ENXIO ----- Full verbose dmesg: ftp://ftp.ipt.ru/pub/sunix/dmesg.6.txt WBR -- Boris Samorodov (bsam) Research Engineer, http://www.ipt.ru Telephone & Internet SP FreeBSD committer, http://www.FreeBSD.org The Power To Serve From owner-freebsd-current@FreeBSD.ORG Thu Dec 11 16:21:23 2008 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D766D106564A for ; Thu, 11 Dec 2008 16:21:23 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by mx1.freebsd.org (Postfix) with ESMTP id A70888FC20 for ; Thu, 11 Dec 2008 16:21:23 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id CA6821E7402; Thu, 11 Dec 2008 11:21:22 -0500 (EST) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute1.internal (MEProxy); Thu, 11 Dec 2008 11:21:22 -0500 X-Sasl-enc: yuuKBzYYFkRcpyqDX5dn75ylnXe1413rVhJ71WO1+6x0 1229012482 Received: from empiric.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id E33C841737; Thu, 11 Dec 2008 11:21:21 -0500 (EST) Message-ID: <49413DFF.9030004@FreeBSD.org> Date: Thu, 11 Dec 2008 16:21:19 +0000 From: "Bruce M. Simpson" User-Agent: Thunderbird 2.0.0.18 (X11/20081205) MIME-Version: 1.0 To: Maxim Sobolev References: <493DA269.2070805@FreeBSD.org> In-Reply-To: <493DA269.2070805@FreeBSD.org> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Luigi Rizzo , hackers@FreeBSD.org, "current@freebsd.org" Subject: Re: Enhancing cdboot [patch for review] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Dec 2008 16:21:23 -0000 This sounds and looks cool, diff looks OK (haven't applied), Luigi's comments seem well thought out and expressed. cheers BMS From owner-freebsd-current@FreeBSD.ORG Thu Dec 11 16:40:54 2008 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3C650106564A for ; Thu, 11 Dec 2008 16:40:54 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout022.mac.com (asmtpout022.mac.com [17.148.16.97]) by mx1.freebsd.org (Postfix) with ESMTP id 27E968FC25 for ; Thu, 11 Dec 2008 16:40:53 +0000 (UTC) (envelope-from xcllnt@mac.com) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Received: from vupadhyaya-t43.jnpr.net (natint3.juniper.net [66.129.224.36]) by asmtp022.mac.com (Sun Java(tm) System Messaging Server 6.3-7.03 (built Aug 7 2008; 32bit)) with ESMTPSA id <0KBQ0064O1046G90@asmtp022.mac.com> for freebsd-current@FreeBSD.org; Thu, 11 Dec 2008 08:40:53 -0800 (PST) Message-id: From: Marcel Moolenaar To: rea-fbsd@codelabs.ru In-reply-to: Date: Thu, 11 Dec 2008 08:40:53 -0800 References: <92804393@bb.ipt.ru> <26722819@bb.ipt.ru> <26719629@bb.ipt.ru> <19F75E66-0535-4982-9726-E2C0A03117EA@mac.com> X-Mailer: Apple Mail (2.929.2) Cc: Boris Samorodov , freebsd-current@FreeBSD.org Subject: Re: Timeda 8-multiport adapter: only 2 ports available X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Dec 2008 16:40:54 -0000 On Dec 11, 2008, at 12:50 AM, Eygene Ryabinkin wrote: > Marcel, Boris, good day. > > Wed, Dec 10, 2008 at 05:00:24PM -0800, Marcel Moolenaar wrote: >>> Seems that just the same card should work: >>> http://lists.freebsd.org/pipermail/freebsd-stable/2008-May/042505.html >>> >>> I've added some diagnistic. But 'rid' is not what you want, I guess: >> >> The RID is fine. It should always be 0. > > Seems like a dumb question, but nevertheless. > > What I don't understand is the following: BAR to port mapping for > the Timedia is tricky, it mixes BARs and offsets for the different > ports (you should know this, since you wrote the support ;)). Correct (on both accounts :-) > But in uart_bus_probe you're passing rid = 0 and it is used for > resource > allocation and consequently the same rid is used for all ports (at > least > I read the code in this way). But puc_get_bar() uses calculated rid > values, but does essentially the same thing: resource allocation via > bus_alloc_resource(). And sc->sc_bas is initialized from the obtained > sc->sc_rres (inside uart_bus_probe) and it is subsequently used for > ns8250_probe() that is failing. > > I see that uart_bus_pci.c calls uart_bus_probe() with the actual rid. > It does not mean that puc code should do the same, but ... It could have been done that way, but such is not necessary. It would not have been a problem for uart to do it, as can be seen from uart_bus_pci.c, but it would have introduced some complexity for sio(4). We needed to support sio(4) at that time and I didn't want to touch sio(4) at all. Since puc(4) needs to maintain a mapping from the child's device_t to some internal data structure, it was trivial to have the child use RID 0 in all cases and have that mapped to the right bus tag and handle pair... FYI, -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-current@FreeBSD.ORG Thu Dec 11 16:57:08 2008 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DCCA11065676 for ; Thu, 11 Dec 2008 16:57:08 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) Received: from 0.mx.codelabs.ru (0.mx.codelabs.ru [144.206.177.45]) by mx1.freebsd.org (Postfix) with ESMTP id 8A8198FC1A for ; Thu, 11 Dec 2008 16:57:08 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=one; d=codelabs.ru; h=Received:Date:From:To:Cc:Subject:Message-ID:Reply-To:References:MIME-Version:Content-Type:Content-Disposition:In-Reply-To:Sender; b=TfFkoGdDSZ+JfKRh/Mb00iMs3WQbV0begVPjNzsmEue2yXMXO633Guj2ySCKykN8LYxNFC+2pqtlyi5nqUUR5LMPQwvfahzylhmLzt1itCJ7MB1Kw9gN6sMq1IF6AogK58OH3s8kEtILSqReZgLc7h82rkDzWQApx8edleZg7h8=; Received: from void.codelabs.ru (void.codelabs.ru [144.206.177.25]) by 0.mx.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1LAoqZ-000CIo-Bn; Thu, 11 Dec 2008 19:57:07 +0300 Date: Thu, 11 Dec 2008 19:57:05 +0300 From: Eygene Ryabinkin To: Marcel Moolenaar Message-ID: <41fBYCE8+WXjiJ69CbLadytILOA@1kze6/ikh5UKbI80fwIBmcuwJuU> References: <92804393@bb.ipt.ru> <26722819@bb.ipt.ru> <26719629@bb.ipt.ru> <19F75E66-0535-4982-9726-E2C0A03117EA@mac.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Bqc0IY4JZZt50bUr" Content-Disposition: inline In-Reply-To: Sender: rea-fbsd@codelabs.ru Cc: Boris Samorodov , freebsd-current@FreeBSD.org Subject: Re: Timeda 8-multiport adapter: only 2 ports available X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rea-fbsd@codelabs.ru List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Dec 2008 16:57:08 -0000 --Bqc0IY4JZZt50bUr Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Marcel, Thu, Dec 11, 2008 at 08:40:53AM -0800, Marcel Moolenaar wrote: > Since > puc(4) needs to maintain a mapping from the child's device_t > to some internal data structure, it was trivial to have the > child use RID 0 in all cases and have that mapped to the > right bus tag and handle pair... Sorry for me being so dumb, but how it is done? Is 'dev' argument to the bus_alloc_resource() carries all specifics? Am I missing some documentation? Thanks! --=20 Eygene _ ___ _.--. # \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard / ' ` , __.--' # to read the on-line manual =20 )/' _/ \ `-_, / # while single-stepping the kernel. `-'" `"\_ ,_.-;_.-\_ ', fsc/as # _.-'_./ {_.' ; / # -- FreeBSD Developers handbook=20 {_.-``-' {_/ # --Bqc0IY4JZZt50bUr Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAklBRmEACgkQthUKNsbL7YgfkQCfZodsEPy6xXDhhUbAuBu+Qc6b GPsAn2sq+DW16l8SVmtPFloaf8KrQuU4 =61sH -----END PGP SIGNATURE----- --Bqc0IY4JZZt50bUr-- From owner-freebsd-current@FreeBSD.ORG Thu Dec 11 17:07:03 2008 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 626251065675 for ; Thu, 11 Dec 2008 17:07:03 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout014.mac.com (asmtpout014.mac.com [17.148.16.89]) by mx1.freebsd.org (Postfix) with ESMTP id 4F7928FC14 for ; Thu, 11 Dec 2008 17:07:03 +0000 (UTC) (envelope-from xcllnt@mac.com) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed Received: from sbansal-mbp.jnpr.net (natint3.juniper.net [66.129.224.36]) by asmtp014.mac.com (Sun Java(tm) System Messaging Server 6.3-7.03 (built Aug 7 2008; 32bit)) with ESMTPSA id <0KBQ00LKM27KW630@asmtp014.mac.com> for freebsd-current@FreeBSD.org; Thu, 11 Dec 2008 09:06:57 -0800 (PST) Message-id: From: Marcel Moolenaar To: Boris Samorodov In-reply-to: <94541668@bb.ipt.ru> Date: Thu, 11 Dec 2008 09:06:56 -0800 References: <92804393@bb.ipt.ru> <26722819@bb.ipt.ru> <26719629@bb.ipt.ru> <19F75E66-0535-4982-9726-E2C0A03117EA@mac.com> <94541668@bb.ipt.ru> X-Mailer: Apple Mail (2.929.2) Cc: freebsd-current@FreeBSD.org, rea-fbsd@codelabs.ru Subject: Re: Timeda 8-multiport adapter: only 2 ports available X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Dec 2008 17:07:03 -0000 On Dec 11, 2008, at 6:36 AM, Boris Samorodov wrote: > Hello Eygene, Marcel and All, > > > I've found some DOS/Linux docs/programs at the producers's site > and unzipped them: > ftp://ftp.ipt.ru/pub/sunix/ > > > Eygene Ryabinkin writes: > >> Boris, could you please add the line >> ----- >> printf("%s: BAS, handle is 0x%lx, tag is 0x%x\n", __func__, >> (unsigned long)bas->bsh, (unsigned int)bas->bst); >> ----- >> to the beginning of ns8250_probe() and show the results. Good suggestion, Eygene! Summary: port 1: IO=0xec00; IIR=0x1, 0xc1; MCR=0x0, 0x8 port 2: IO=0xec08; IIR=0x1, 0xc1; MCR=0x0, 0x8 port 3: IO=0xe880; IIR=0x1; MCR=0x40 port 4: IO=0xe888; IIR=0x1; MCR=0x40 port 5: IO=0xe800; IIR=0x1; MCR=0x40 port 6: IO=0xe480; IIR=0x1; MCR=0x40 port 7: IO=0xe400; IIR=0x1; MCR=0x40 port 8: IO=0xe080; IIR=0x1; MCR=0x40 For ports 3-8, the MCR has a value that's not liked by uart(4). I think we need to know what that value means. Are the ports disabled? Are they in a non-standard mode? Is it just a non-standard status bit that's set and we should ignore it? etc... Boris: can you apply the following patch and see if uart(4) attaches to all ports? If yes, can you see if those ports actually work as well? Index: uart_dev_ns8250.c =================================================================== --- uart_dev_ns8250.c (revision 185784) +++ uart_dev_ns8250.c (working copy) @@ -241,7 +241,7 @@ if (val & 0x30) return (ENXIO); val = uart_getreg(bas, REG_MCR); - if (val & 0xe0) + if (val & 0xa0) return (ENXIO); return (0); Thanks. -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-current@FreeBSD.ORG Thu Dec 11 17:16:13 2008 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D5684106564A for ; Thu, 11 Dec 2008 17:16:13 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout016.mac.com (asmtpout016.mac.com [17.148.16.91]) by mx1.freebsd.org (Postfix) with ESMTP id C11918FC1B for ; Thu, 11 Dec 2008 17:16:13 +0000 (UTC) (envelope-from xcllnt@mac.com) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed Received: from [172.24.104.109] (natint3.juniper.net [66.129.224.36]) by asmtp016.mac.com (Sun Java(tm) System Messaging Server 6.3-7.03 (built Aug 7 2008; 32bit)) with ESMTPSA id <0KBQ004IQ2N0QW00@asmtp016.mac.com> for freebsd-current@FreeBSD.org; Thu, 11 Dec 2008 09:16:13 -0800 (PST) Message-id: <10176E1D-54D5-4C57-9311-DE304250E2CE@mac.com> From: Marcel Moolenaar To: rea-fbsd@codelabs.ru In-reply-to: <41fBYCE8+WXjiJ69CbLadytILOA@1kze6/ikh5UKbI80fwIBmcuwJuU> Date: Thu, 11 Dec 2008 09:16:12 -0800 References: <92804393@bb.ipt.ru> <26722819@bb.ipt.ru> <26719629@bb.ipt.ru> <19F75E66-0535-4982-9726-E2C0A03117EA@mac.com> <41fBYCE8+WXjiJ69CbLadytILOA@1kze6/ikh5UKbI80fwIBmcuwJuU> X-Mailer: Apple Mail (2.929.2) Cc: Boris Samorodov , freebsd-current@FreeBSD.org Subject: Re: Timeda 8-multiport adapter: only 2 ports available X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Dec 2008 17:16:13 -0000 On Dec 11, 2008, at 8:57 AM, Eygene Ryabinkin wrote: > Marcel, > > Thu, Dec 11, 2008 at 08:40:53AM -0800, Marcel Moolenaar wrote: >> Since >> puc(4) needs to maintain a mapping from the child's device_t >> to some internal data structure, it was trivial to have the >> child use RID 0 in all cases and have that mapped to the >> right bus tag and handle pair... > > Sorry for me being so dumb, but how it is done? Is 'dev' argument > to the bus_alloc_resource() carries all specifics? Am I missing > some documentation? Ok, let's follow the trail where the child is uart(4) and the parent is puc(4). A driver calls bus_alloc_resource(). The first argument of which is the device_t of the /driver. bus_alloc_resource() is defined in sys/kern/subr_bus.c and is calls the KOBJ method with the same name. The BUS_ALLOC_RESOURCE method has the parent of the device as the first argument and the device itself (the child) as the second argument. The KOBJ method in this case resolves to puc_bus_alloc_resource() in sys/dev/puc.c. In that function you'll see a call to device_get_ivars(uartdev). This is how puc(4) gets the a pointer to the puc_port structure that corresponds to the uartdev. All the information is in the puc_port struct. Obviously, puc(4) has called device_set_ivars() first (see puc_bfe_attac()). FYI, -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-current@FreeBSD.ORG Thu Dec 11 17:24:12 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4BAA8106564A; Thu, 11 Dec 2008 17:24:12 +0000 (UTC) (envelope-from citrin@citrin.ru) Received: from mail-chaos.rambler.ru (mail-chaos.rambler.ru [81.19.68.130]) by mx1.freebsd.org (Postfix) with ESMTP id 060C48FC08; Thu, 11 Dec 2008 17:24:11 +0000 (UTC) (envelope-from citrin@citrin.ru) Received: from [81.19.90.234] (unknown [81.19.90.234]) (Authenticated sender: citrin@citrin.ru) by mail-chaos.rambler.ru (Postfix) with ESMTPSA id 52AA91704D; Thu, 11 Dec 2008 20:24:10 +0300 (MSK) Message-ID: <49414CB9.7060903@citrin.ru> Date: Thu, 11 Dec 2008 20:24:09 +0300 From: Anton Yuzhaninov User-Agent: Thunderbird 2.0.0.18 (X11/20081129) MIME-Version: 1.0 To: gary.jennejohn@freenet.de References: <200812080248.mB82mfV9043154@svn.freebsd.org> <4940115F.7080004@citrin.ru> <20081211120908.57f99124@ernst.jennejohn.org> In-Reply-To: <20081211120908.57f99124@ernst.jennejohn.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: current@freebsd.org, Pyun YongHyeon Subject: Re: svn commit: r185756 - head/sys/dev/re X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Dec 2008 17:24:12 -0000 Gary Jennejohn wrote: > On Wed, 10 Dec 2008 21:58:39 +0300 > Anton Yuzhaninov wrote: > >> Pyun YongHyeon wrote: >>> Author: yongari >>> Date: Mon Dec 8 02:48:41 2008 >>> New Revision: 185756 >>> URL: http://svn.freebsd.org/changeset/base/185756 >>> >>> Log: >>> Reduce spin wait time consumed in GMII register access routines. >>> Waiting for 1ms for each GMII register access looks overkill and it >>> may also decrease overall performance of driver because re(4) >>> invokes mii_tick for every hz. >>> >>> Tested by: rpaulo >>> >>> Modified: >>> head/sys/dev/re/if_re.c >>> >>> Modified: head/sys/dev/re/if_re.c >>> ============================================================================== >>> --- head/sys/dev/re/if_re.c Mon Dec 8 02:38:13 2008 (r185755) >>> +++ head/sys/dev/re/if_re.c Mon Dec 8 02:48:41 2008 (r185756) >>> @@ -417,13 +417,12 @@ re_gmii_readreg(device_t dev, int phy, i >>> } >>> >>> CSR_WRITE_4(sc, RL_PHYAR, reg << 16); >>> - DELAY(1000); >>> >>> for (i = 0; i < RL_TIMEOUT; i++) { >>> + DELAY(30); >>> rval = CSR_READ_4(sc, RL_PHYAR); >>> if (rval & RL_PHYAR_BUSY) >>> break; >>> - DELAY(100); >>> } >>> >>> if (i == RL_TIMEOUT) { >>> @@ -445,13 +444,12 @@ re_gmii_writereg(device_t dev, int phy, >>> >>> CSR_WRITE_4(sc, RL_PHYAR, (reg << 16) | >>> (data & RL_PHYAR_PHYDATA) | RL_PHYAR_BUSY); >>> - DELAY(1000); >>> >>> for (i = 0; i < RL_TIMEOUT; i++) { >>> + DELAY(30); >>> rval = CSR_READ_4(sc, RL_PHYAR); >>> if (!(rval & RL_PHYAR_BUSY)) >>> break; >>> - DELAY(100); >>> } >>> >>> if (i == RL_TIMEOUT) { >> After this commit I see in logs errors: >> >> Dec 10 21:37:42 citrin kernel: re0: PHY read failed >> Dec 10 21:38:05 citrin last message repeated 3 times >> Dec 10 21:38:44 citrin last message repeated 3 times >> Dec 10 21:38:44 citrin kernel: re0: link state changed to DOWN >> Dec 10 21:38:45 citrin kernel: re0: link state changed to UP >> Dec 10 21:38:55 citrin kernel: re0: PHY read failed >> Dec 10 21:39:38 citrin last message repeated 3 times >> Dec 10 21:39:38 citrin kernel: re0: link state changed to DOWN >> Dec 10 21:39:39 citrin kernel: re0: link state changed to UP >> Dec 10 21:40:09 citrin kernel: re0: PHY read failed >> Dec 10 21:40:21 citrin kernel: re0: PHY read failed >> Dec 10 21:41:03 citrin kernel: re0: PHY read failed >> >> I tried to revert this patch - errors disappeared. >> > > I was seeing these errors too, but disabling MSI made them disappear. 1. MSI don't used (seems to be not supported by this NIC or blacklisted). 2. Commit http://svn.freebsd.org/changeset/base/185896 fixes this errors. -- Anton Yuzhaninov From owner-freebsd-current@FreeBSD.ORG Thu Dec 11 17:45:14 2008 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 408731065670; Thu, 11 Dec 2008 17:45:14 +0000 (UTC) (envelope-from rdivacky@lev.vlakno.cz) Received: from vlakno.cz (77-93-215-190.static.masterinter.net [77.93.215.190]) by mx1.freebsd.org (Postfix) with ESMTP id ED5A88FC25; Thu, 11 Dec 2008 17:45:12 +0000 (UTC) (envelope-from rdivacky@lev.vlakno.cz) Received: from localhost (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id B2F829CB1BE; Thu, 11 Dec 2008 18:40:26 +0100 (CET) X-Virus-Scanned: amavisd-new at vlakno.cz Received: from vlakno.cz ([127.0.0.1]) by localhost (lev.vlakno.cz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rPXprjPJdvfY; Thu, 11 Dec 2008 18:40:24 +0100 (CET) Received: from lev.vlakno.cz (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id 398509CB2B8; Thu, 11 Dec 2008 18:40:24 +0100 (CET) Received: (from rdivacky@localhost) by lev.vlakno.cz (8.14.2/8.14.2/Submit) id mBBHeNdm057568; Thu, 11 Dec 2008 18:40:23 +0100 (CET) (envelope-from rdivacky) Date: Thu, 11 Dec 2008 18:40:23 +0100 From: Roman Divacky To: Robert Watson Message-ID: <20081211174023.GA57297@freebsd.org> References: <20081210164345.GA32188@freebsd.org> <20081210214248.GA69246@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: current@FreeBSD.org Subject: Re: [PANIC]: rw_lock panic in in_pcballoc() in r185864 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Dec 2008 17:45:14 -0000 On Wed, Dec 10, 2008 at 10:58:14PM +0000, Robert Watson wrote: > > On Wed, 10 Dec 2008, Roman Divacky wrote: > > >hm... I wondered how it could work before that.... anyway, I got this crash > > Well, nothing says it still works that way, that's just the theory :-). > > >>So, given that this code has worked for quite a long time for many > >>people, this really raises two questions: (1) how reproduceable is this > >>and at what point does it kick in during the boot/runtime, and (2) when > >>did this start happening in terms of updating your source? > > > >ad (1): I get this on every boot when dhcp kicks in (it uses udp I > >believe) ie. 100% reproducible > > > >ad (2): Mon Dec 8 23:02:27 CET 2008 kernel (svn up-dated at most 10 > >minutes before that) works 100% ok > > > >I have the crash dump and the kernel at hand so I can do basically > >anything you ask me to do :) anything I can provide? > > Well, to be honest, the easiest thing to do may be to play the binary > search game to narrow down the point where the problem starts a bit more. > There are a few kinds of things that might lead to this problem -- perhaps > we (I?) mucked up initialization of the inpcb with recent changes, or a > virtualization-related change tripped something up, or a locking/scheduler > change or such. it's something between 185772 and 185864, dont you have any dhcp-enabled machine? if so.. can you reproduce that? > The other thing that would be helpful is a dump of *inp so that we can see > what state inp_lock is in. I foolishly deleted the kernel matching the vmcore, I'll try to do that tomorrow From owner-freebsd-current@FreeBSD.ORG Thu Dec 11 18:00:14 2008 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CC73C1065677 for ; Thu, 11 Dec 2008 18:00:14 +0000 (UTC) (envelope-from bsam@ipt.ru) Received: from services.ipt.ru (services.ipt.ru [194.62.233.110]) by mx1.freebsd.org (Postfix) with ESMTP id 82F878FC19 for ; Thu, 11 Dec 2008 18:00:14 +0000 (UTC) (envelope-from bsam@ipt.ru) Received: from bb.ipt.ru ([194.62.233.89]) by services.ipt.ru with esmtp (Exim 4.54 (FreeBSD)) id 1LAppd-000K1u-7h; Thu, 11 Dec 2008 21:00:13 +0300 To: Marcel Moolenaar References: <92804393@bb.ipt.ru> <26722819@bb.ipt.ru> <26719629@bb.ipt.ru> <19F75E66-0535-4982-9726-E2C0A03117EA@mac.com> <94541668@bb.ipt.ru> From: Boris Samorodov Date: Thu, 11 Dec 2008 21:00:12 +0300 In-Reply-To: (Marcel Moolenaar's message of "Thu\, 11 Dec 2008 09\:06\:56 -0800") Message-ID: <48144979@bb.ipt.ru> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-current@FreeBSD.org, rea-fbsd@codelabs.ru Subject: Re: Timeda 8-multiport adapter: only 2 ports available X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Dec 2008 18:00:14 -0000 Marcel Moolenaar writes: > Summary: > > port 1: IO=0xec00; IIR=0x1, 0xc1; MCR=0x0, 0x8 > port 2: IO=0xec08; IIR=0x1, 0xc1; MCR=0x0, 0x8 > port 3: IO=0xe880; IIR=0x1; MCR=0x40 > port 4: IO=0xe888; IIR=0x1; MCR=0x40 > port 5: IO=0xe800; IIR=0x1; MCR=0x40 > port 6: IO=0xe480; IIR=0x1; MCR=0x40 > port 7: IO=0xe400; IIR=0x1; MCR=0x40 > port 8: IO=0xe080; IIR=0x1; MCR=0x40 > > For ports 3-8, the MCR has a value that's not liked by > uart(4). I think we need to know what that value means. > Are the ports disabled? Are they in a non-standard > mode? Is it just a non-standard status bit that's set > and we should ignore it? etc... > > Boris: can you apply the following patch and see if > uart(4) attaches to all ports? If yes, can you see > if those ports actually work as well? All ports were attached. But ports 3-8 don't work as axpected. I see garbage when connecting via those ports. BTW, I'm not sure if it may help, but FYI: the card is made of two different chip types: SUN1889 (1-2 ports) and SUN1699 (3-8 ports). Thanks! WBR -- Boris Samorodov (bsam) Research Engineer, http://www.ipt.ru Telephone & Internet SP FreeBSD committer, http://www.FreeBSD.org The Power To Serve From owner-freebsd-current@FreeBSD.ORG Thu Dec 11 18:01:20 2008 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 29D6E106564A for ; Thu, 11 Dec 2008 18:01:20 +0000 (UTC) (envelope-from bsam@ipt.ru) Received: from services.ipt.ru (services.ipt.ru [194.62.233.110]) by mx1.freebsd.org (Postfix) with ESMTP id D5F438FC26 for ; Thu, 11 Dec 2008 18:01:19 +0000 (UTC) (envelope-from bsam@ipt.ru) Received: from bb.ipt.ru ([194.62.233.89]) by services.ipt.ru with esmtp (Exim 4.54 (FreeBSD)) id 1LApqg-000K2d-Ta; Thu, 11 Dec 2008 21:01:19 +0300 To: Marcel Moolenaar References: <92804393@bb.ipt.ru> <26722819@bb.ipt.ru> <26719629@bb.ipt.ru> <19F75E66-0535-4982-9726-E2C0A03117EA@mac.com> <94541668@bb.ipt.ru> <48144979@bb.ipt.ru> From: Boris Samorodov Date: Thu, 11 Dec 2008 21:01:18 +0300 In-Reply-To: <48144979@bb.ipt.ru> (Boris Samorodov's message of "Thu\, 11 Dec 2008 21\:00\:12 +0300") Message-ID: <82064913@bb.ipt.ru> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-current@FreeBSD.org, rea-fbsd@codelabs.ru Subject: Re: Timeda 8-multiport adapter: only 2 ports available X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Dec 2008 18:01:20 -0000 Boris Samorodov writes: > All ports were attached. But ports 3-8 don't work as axpected. > I see garbage when connecting via those ports. The relevant part of dmesg: ftp://ftp.ipt.ru/pub/sunix/dmesg.7.txt WBR -- Boris Samorodov (bsam) Research Engineer, http://www.ipt.ru Telephone & Internet SP FreeBSD committer, http://www.FreeBSD.org The Power To Serve From owner-freebsd-current@FreeBSD.ORG Thu Dec 11 18:18:34 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 096E31065680; Thu, 11 Dec 2008 18:18:34 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by mx1.freebsd.org (Postfix) with ESMTP id D38BD8FC1D; Thu, 11 Dec 2008 18:18:33 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id 659181E6DF7; Thu, 11 Dec 2008 13:18:33 -0500 (EST) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute1.internal (MEProxy); Thu, 11 Dec 2008 13:18:33 -0500 X-Sasl-enc: 0/L1gkxbnjobDAH76arPK1cWctvbZsQxXGLhGnZwFSGk 1229019512 Received: from empiric.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id A052613B10; Thu, 11 Dec 2008 13:18:32 -0500 (EST) Message-ID: <49415977.6010307@FreeBSD.org> Date: Thu, 11 Dec 2008 18:18:31 +0000 From: "Bruce M. Simpson" User-Agent: Thunderbird 2.0.0.18 (X11/20081205) MIME-Version: 1.0 To: Qing Li References: <200812100740.mBA7eqjO034924@freefall.freebsd.org> In-Reply-To: <200812100740.mBA7eqjO034924@freefall.freebsd.org> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, current@freebsd.org Subject: Re: last call for L2/L3 rewrite code review X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Dec 2008 18:18:34 -0000 Hi, Just skimming this I notice it uses the if_afdata[AF_INET] pointer purely for lltbl purposes; this clashes with the IGMPv3 code drop. Please look in the bms_netdev branch, where I introduce a 'struct ip_ifinfo' to make more general use of that slot. IGMPv3 needs to store per-interface state for AF_INET, so this slot really needs to be shared with other AF_INET stuff. Looks like it needs to be updated for VIMAGE also, hopefully others more familiar with this can help -- I am busy enough with non-programming activity as it is to get up to speed on this, although I have at least managed to print Julian's write-up... Other than that, it looks like a much needed improvement and we are all very grateful for our work on this. thanks BMS From owner-freebsd-current@FreeBSD.ORG Thu Dec 11 18:26:11 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D3D3C1065673 for ; Thu, 11 Dec 2008 18:26:11 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from rn-out-0910.google.com (rn-out-0910.google.com [64.233.170.191]) by mx1.freebsd.org (Postfix) with ESMTP id 90B728FC1A for ; Thu, 11 Dec 2008 18:26:11 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: by rn-out-0910.google.com with SMTP id j71so1188873rne.12 for ; Thu, 11 Dec 2008 10:26:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=ubaaaUkMbcYtXx6UpW4zX3ePoFxJA77gWR4fJc2oO2U=; b=pSbKJTXst5YTnswN13WQR9T89Pjur4P+9R+IVdxTldMAexxBW0QS73MUISiGEzLT+p LXgC+c//JM/Bh34iMHVCay/TTbfHXYiELJjamIEdQPLO1U0tWgK7GkIbidCpIYGkVCgn DbEIlbiAoYIKKFUB9Ms/WtPAbnFIxwh9xU9Wc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=cVahkLGP4pZ/Od+SLfevKZ1QoP+YzkyS+uIf1UqjT6sGzrpOX6KPDUfc8gPJR11UXD chQPGYgj8UPlSZEctlFFpn7VS/RK7qFXqyw28cQunqBrxpdBySuotl/Cpw9WR7zFyJ5c +ieWZmH3kYNSzHnKO29KjxRycXtWhPEpH7B0M= Received: by 10.90.89.18 with SMTP id m18mr1689931agb.96.1229018201301; Thu, 11 Dec 2008 09:56:41 -0800 (PST) Received: by 10.90.91.14 with HTTP; Thu, 11 Dec 2008 09:56:41 -0800 (PST) Message-ID: Date: Thu, 11 Dec 2008 17:56:41 +0000 From: pluknet To: "Zaphod Beeblebrox" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <5f67a8c40812041432y13793ee5k1d2526c9829dc16f@mail.gmail.com> Cc: freebsd-current Subject: Re: SATA CD fail. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Dec 2008 18:26:11 -0000 2008/12/5 pluknet : > 2008/12/5 Zaphod Beeblebrox : >> I've got an HP DL-360 1U here that has a slim SATA CDROM. I've (so far) >> tried booting FreeBSD-7.0-RELEASE and FreeBSD-7.1-BETA2. I've tried both >> rewritable media (my first choice) and write-once media. The kernel loads >> fine, but multiuser fails with "acd0: TIMEOUT - READ_BIG retrying" ... >> twice, followed by "timed out". > > I workarounded this by ejecting CD after kernel is loaded but before > probing media, then > installing from sysinstall via NFS from this CD inserted on nearby > with IDE CDROM computer. > [redirected from -stable] This issue was on recent CURRENT around November for me. And hey. After later cvsup to Dec 11 this problem disappeared. Now it boots with media injected in SATA DVD. acd0: DVDR at ata4-master SATA150 GEOM_LABEL: Label for provider acd0 is iso9660/STALKER_CS. -- wbr, pluknet From owner-freebsd-current@FreeBSD.ORG Thu Dec 11 18:29:39 2008 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6366C1065670 for ; Thu, 11 Dec 2008 18:29:39 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout015.mac.com (asmtpout015.mac.com [17.148.16.90]) by mx1.freebsd.org (Postfix) with ESMTP id 4FC3C8FC08 for ; Thu, 11 Dec 2008 18:29:39 +0000 (UTC) (envelope-from xcllnt@mac.com) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed Received: from lynx.jnpr.net (natint3.juniper.net [66.129.224.36]) by asmtp015.mac.com (Sun Java(tm) System Messaging Server 6.3-7.03 (built Aug 7 2008; 32bit)) with ESMTPSA id <0KBQ00ECL61EP720@asmtp015.mac.com> for freebsd-current@FreeBSD.org; Thu, 11 Dec 2008 10:29:39 -0800 (PST) Message-id: <548CF0A3-1B07-49DA-A177-6EA85FD8CF2F@mac.com> From: Marcel Moolenaar To: Boris Samorodov In-reply-to: <48144979@bb.ipt.ru> Date: Thu, 11 Dec 2008 10:29:37 -0800 References: <92804393@bb.ipt.ru> <26722819@bb.ipt.ru> <26719629@bb.ipt.ru> <19F75E66-0535-4982-9726-E2C0A03117EA@mac.com> <94541668@bb.ipt.ru> <48144979@bb.ipt.ru> X-Mailer: Apple Mail (2.929.2) Cc: freebsd-current@FreeBSD.org, rea-fbsd@codelabs.ru Subject: Re: Timeda 8-multiport adapter: only 2 ports available X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Dec 2008 18:29:39 -0000 On Dec 11, 2008, at 10:00 AM, Boris Samorodov wrote: > Marcel Moolenaar writes: > >> Summary: >> >> port 1: IO=0xec00; IIR=0x1, 0xc1; MCR=0x0, 0x8 >> port 2: IO=0xec08; IIR=0x1, 0xc1; MCR=0x0, 0x8 >> port 3: IO=0xe880; IIR=0x1; MCR=0x40 >> port 4: IO=0xe888; IIR=0x1; MCR=0x40 >> port 5: IO=0xe800; IIR=0x1; MCR=0x40 >> port 6: IO=0xe480; IIR=0x1; MCR=0x40 >> port 7: IO=0xe400; IIR=0x1; MCR=0x40 >> port 8: IO=0xe080; IIR=0x1; MCR=0x40 >> >> For ports 3-8, the MCR has a value that's not liked by >> uart(4). I think we need to know what that value means. >> Are the ports disabled? Are they in a non-standard >> mode? Is it just a non-standard status bit that's set >> and we should ignore it? etc... >> >> Boris: can you apply the following patch and see if >> uart(4) attaches to all ports? If yes, can you see >> if those ports actually work as well? > > All ports were attached. But ports 3-8 don't work as axpected. > I see garbage when connecting via those ports. Ok, so it's more than just a non-standard status bit that can be ignored :-/ Unfortunately, I don't have any of their hardware, nor any documentation... -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-current@FreeBSD.ORG Thu Dec 11 18:32:29 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 093AB1065672; Thu, 11 Dec 2008 18:32:29 +0000 (UTC) (envelope-from jille@quis.cx) Received: from istud.quis.cx (ip83-113-174-82.adsl2.static.versatel.nl [82.174.113.83]) by mx1.freebsd.org (Postfix) with ESMTP id 8E0A88FC19; Thu, 11 Dec 2008 18:32:28 +0000 (UTC) (envelope-from jille@quis.cx) Received: from [192.168.1.4] (ille [192.168.1.4]) by istud.quis.cx (Postfix) with ESMTP id 028DE5C34; Thu, 11 Dec 2008 19:32:27 +0100 (CET) Message-ID: <49415CB8.7040302@quis.cx> Date: Thu, 11 Dec 2008 19:32:24 +0100 From: Jille Timmermans User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Sam Leffler References: <49403F27.3020605@quis.cx> <4940440E.9050805@freebsd.org> <49405EC7.8080906@quis.cx> <494062BE.5050202@freebsd.org> In-Reply-To: <494062BE.5050202@freebsd.org> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD Current Subject: Re: Panic when loading if_ath X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Dec 2008 18:32:29 -0000 Sam Leffler schreef: > Jille Timmermans wrote: >> Sam Leffler schreef: >> >>> Jille Timmermans wrote: >>> >>>> Hello list, >>>> >>>> A panic with if_ath (Atheros 2413) >>>> >>>> root /sys/modules/ath_rate_amrr# make >>>> root /sys/modules/ath_rate_amrr# make install >>>> root ~# kldload if_ath >>>> warning: KLD '/boot/kernel/if_ath.ko' is newer than the linker.hints >>>> file >>>> ath0: mem 0xc9000000-0xc900ffff irq 18 at device 1.0 on >>>> pci5 >>>> ath0: [ITHREAD] >>>> >>>> Fatal trap 12: page fault while in kernel mode >>>> cpuid = 0; apic id = 00 >>>> fault virtual address = 0x0 >>>> fault code = supervisor read, page not present >>>> instruction pointer = 0x20:0x0 >>>> stack pointer = 0x28:0xc43cc748 >>>> frame pointer = 0x28:0xc43cc75c >>>> code segment = base 0x0, limit 0xfffff, type 0x1b >>>> = DPL 0, pres 1, def32 1, gran 1 >>>> processor eflags = interrupt enabled, resume, IOPL = 0 >>>> current_process = 993 (kldload) >>>> trap number = 12 >>>> panic: page fault >>>> cpuid = 0 >>>> >>>> [dump] >>>> [reboot] >>>> WARNING: /tmp was not properly dismounted >>>> WARNING: /usr was not properly dismounted >>>> WARNING: /var was not properly dismounted >>>> >>>> Fatal trap 12: page fault while in kernel mode >>>> cpuid = 0; apic id = 00 >>>> fault virtual address = 0x5bbfe499 >>>> fault code = supervisor read, page not present >>>> instruction pointer = 0x20:0xc0684c37 >>>> stack pointer = 0x28:0xc4364a5c >>>> frame pointer = 0x28:0xc4364c28 >>>> code segment = base 0x0, limit 0xfffff, type 0x1b >>>> = DPL 0, pres 1, def32 1, gran 1 >>>> processor eflags = interrupt enabled, resume, IOPL = 0 >>>> current process = 136 (ifconfig) >>>> trap number = 12 >>>> panic: page fault >>>> cpuid = 0 >>>> >>>> [a few crashes later, when it comes to mind to get a backtrace] >>>> root ~# kldload ath_rate >>>> root ~# kldload if_ath >>>> ath0: mem 0xc9000000-0xc900ffff irq 18 at device 1.0 on >>>> pci5 >>>> ath0: [ITHREAD] >>>> [panic] >>>> uart_z8530_class(c4ac5000, 0, 1, 1, c4390000, ...) at 0 >>>> ar5212Attach(1a, c48b0000, 1, c4389000, c437c8ec, ...) at >>>> ar5212Attach+0x211 >>>> ath_hal_attach(1a, c48b0000, 1, c4389000, c437c8ec, ...) at >>>> ath_hal_attach+0x56 >>>> ath_attach(1a, c48b0000, 3, c437c940, ffffffff, ...) at ath_attach+0x9e >>>> ath_pci_attach(c46bb200, c4823854, c09fcf80, c099dc60, 80000000, >>>> ...) at >>>> ath_pci_attach+0x332 >>>> device_attach([snip]) at device_attach+0x36f >>>> device_probe_and_attach([snip) at ...+0x43 >>>> pci_driver_added([snip]) at +0x104 >>>> devclass_add_driver([snip]) at +0xe8 >>>> driver_module_handler([snip]) at +0x79 >>>> module_register_init() >>>> linker_load_module() >>>> kern_kldload() >>>> >>>> (Please don't tell me you want any of that snips.) >>>> >>>> Any extra information I can provide to you ? >>>> I am willing to help debugging / crashing. >>>> >>>> >>> Try building the driver into the kernel. Also use sample and not amrr. >>> >> root ~# cd /sys/modules/ath_rate_sample >> root /sys/modules/ath_rate_sample# make >> root /sys/modules/ath_rate_sample# make install >> root /sys/modules/ath_rate_sample# kldload if_ath >> link_elf: symbol ath_hal_computetxtime undefined >> KLD if_ath.ko: depends on ath_rate - not available >> kldload: can't load if_ath: No such file or directory >> root /sys/modules/ath_rate_sample# kldload ath_rate >> link_elf: symbol ath_hal_computetxtime undefined >> kldload: can't load ath_rate: No such file or directory >> >> I'll try compiling it in. >> >> > I know module building is broken; I posted recently to just build things > into the kernel. I've got a possible solution in p4 in the sam_vap > branch if you want to try it. I removed the ath_rate_* modules and just > smooshed the code into the ath module so we go from > (ath+ath_hal+ath_rate) to just (ath). > > Right now I want to see if your problem is in the module mess, > ath_rate_amrr, or something else. I tested 2413 w/ the driver built > into the kernel so I'm guessing it's amrr which I may just nuke entirely > (along with onoe). The built-in version panics as well (while booting). (Information of which I think it is relevant) ath0: mem 0xc9000000-0xc900ffff irq 18 at device 1.0 on pci5 ath0: [ITHREAD] Fatal trap 1: privileged instruction fault while in kernel mode cpuid = 0; apic id = 00 instruction pointer = 0x20:0x3 current process = 0 (swapper) trap number = 1 Uptime: 1s db> bt uart_z8530_class(c46da000, 0, 1, 1, c433c000, ...) at 0x3 ar5212Attach(1a, c48c9000, 1, c433c000, c437c8ec, ...) at ar5212Attach+0x70a ath_hal_attach(1a, c46c9000, 3, c10208b8, ffffffff, ...) at ath_hal_attach+0xbe kernel config entries: options AH_SUPPORT_AR5416 device ath device ath_hal device ath_rate_sample How can I get a kernel of your p4 source ? Can you provide me a diff against head or something alike ? -- Jille > > Sam > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Thu Dec 11 18:40:18 2008 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 608A71065678 for ; Thu, 11 Dec 2008 18:40:18 +0000 (UTC) (envelope-from bsam@ipt.ru) Received: from services.ipt.ru (services.ipt.ru [194.62.233.110]) by mx1.freebsd.org (Postfix) with ESMTP id 17B7E8FC1E for ; Thu, 11 Dec 2008 18:40:18 +0000 (UTC) (envelope-from bsam@ipt.ru) Received: from bb.ipt.ru ([194.62.233.89]) by services.ipt.ru with esmtp (Exim 4.54 (FreeBSD)) id 1LAqSP-000KY1-3x; Thu, 11 Dec 2008 21:40:17 +0300 To: Marcel Moolenaar References: <92804393@bb.ipt.ru> <26722819@bb.ipt.ru> <26719629@bb.ipt.ru> <19F75E66-0535-4982-9726-E2C0A03117EA@mac.com> <94541668@bb.ipt.ru> <48144979@bb.ipt.ru> <548CF0A3-1B07-49DA-A177-6EA85FD8CF2F@mac.com> From: Boris Samorodov Date: Thu, 11 Dec 2008 21:40:16 +0300 In-Reply-To: <548CF0A3-1B07-49DA-A177-6EA85FD8CF2F@mac.com> (Marcel Moolenaar's message of "Thu\, 11 Dec 2008 10\:29\:37 -0800") Message-ID: <15982575@bb.ipt.ru> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-current@FreeBSD.org Subject: Re: Timeda 8-multiport adapter: only 2 ports available X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Dec 2008 18:40:18 -0000 Marcel Moolenaar writes: > Unfortunately, I don't have any of their hardware, nor any > documentation... There is a linux driver code: ftp://ftp.ipt.ru/pub/sunix/golden_V1.08/golden/driver I know that's not much... Thanks! WBR -- Boris Samorodov (bsam) Research Engineer, http://www.ipt.ru Telephone & Internet SP FreeBSD committer, http://www.FreeBSD.org The Power To Serve From owner-freebsd-current@FreeBSD.ORG Thu Dec 11 18:41:25 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 80DB61065675 for ; Thu, 11 Dec 2008 18:41:25 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.28]) by mx1.freebsd.org (Postfix) with ESMTP id 3A0078FC14 for ; Thu, 11 Dec 2008 18:41:25 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: by yw-out-2324.google.com with SMTP id 9so504550ywe.13 for ; Thu, 11 Dec 2008 10:41:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=7cGLcbHfXLbTKNOY7U6CEY1976d+Kd7YG+Vl995GlJE=; b=UBw8pWWua9AAZGIfhUuLRDNX1seTZ/cT50ePhTeYajtm4L4ZYG/pF2uB0utESEVxAn tb/hvNM1E3bpolJvH692DJ0ZLwfoSWgey4S92euuzyvaQ1d/eTGlnrGf6AkEB4OcVHU5 w4He4ol/Mr4FSS2RNu7t+4bol10rZ+kRDfX8M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=EHo8eFih5iiLyf3sWFVN0kaQ9uLiGKrM5huCPyh51x21zNQDFzBiMtfIyxnuPdhNi4 6fDAHNjeAAxjLNo2HDkeKDOTftXw1zFfLm83SWrdEvYeJZ8UNk2+7H4WLU17gtnoK37t 6rCmUq4OU6A3SQEE0IZYBpXL9o1X/LPFatxdE= Received: by 10.90.99.6 with SMTP id w6mr1700528agb.81.1229019015810; Thu, 11 Dec 2008 10:10:15 -0800 (PST) Received: by 10.90.91.14 with HTTP; Thu, 11 Dec 2008 10:10:15 -0800 (PST) Message-ID: Date: Thu, 11 Dec 2008 18:10:15 +0000 From: pluknet To: "Maksim Yevmenkin" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <48ED3D0F.6050209@cran.org.uk> Cc: Bruce Cran , current@freebsd.org Subject: Re: LOR during boot (if_sis.c/kbdmux.c - Giant after non-sleepable) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Dec 2008 18:41:25 -0000 2008/10/9 Maksim Yevmenkin : > On 10/8/08, Bruce Cran wrote: >> During boot I pressed Scroll Lock at the wrong time and got a LOR. >> Switching between consoles became really slow once the system was running, >> taking a couple of seconds each time. >> I'm running -current from a few days ago. >> >> lock order reversal: (Giant after non-sleepable) >> 1st 0xc4283e84 sis0 (network driver) @ >> /usr/src/sys/dev/sis/if_sis.c:2106 >> 2nd 0xc0d0d430 Giant (Giant) @ >> /usr/src/sys/dev/kbdmux/kbdmux.c:1103 >> KDB: stack backtrace: >> db_trace_self_wrapper(c0bc49d7,c3ee27f0,c0837e85,4,c0bc0367,...) >> at db_trace_self_wrapper+0x26 >> kdb_backtrace(4,c0bc0367,c0b9b6f1,c411d1a0,c3ee2848,...) >> at kdb_backtrace+0x29 >> _witness_debugger(c0bc728c,c0d0d430,c0be0869,c411d1a0,c0b9b6f1,...) >> at _witness_debugger+0x25 >> witness_checkorder(c0d0d430,9,c0b9b6f1,44f,0,...) at >> witness_checkorder+0x800 >> _mtx_lock_flags(c0d0d430,0,c0b9b6f1,44f,c4167d20,...) at >> _mtx_lock_flags+0xc4 >> kbdmux_ioctl(c4221b00,40044b13,c3ee28c8,100202,7,...) >> at kbdmux_ioctl+0x76e >> update_kbd_state(c0bc0367,c0bbaf86,2,c44b08c0,c0c577a0,...) >> at update_kbd_state+0x44 >> sc_cnputc(c0c577a0,73,c3ee2a94,5,73,...) at sc_cnputc+0x39 >> cnputc(73,c3ee2a94,c3ee2944,c082a2a1,c0be63cd,...) at >> cnputc+0x5f >> putcons(c0be63cd,c0bbaf86,1000001,c41d9d6d,c082a240,...) >> at putcons+0x17 >> putchar(73,c3ee2a94,c0d11900,1,c41d9d6f,...) at >> putchar+0x61 >> kvprintf(c0b668aa,c082a240,c3ee2a94,a,c3ee2ac0,...) at >> kvprintf+0xa27 >> printf(c0b668aa,c41d9d6c,0,c4283e00,c4283e00,...) at >> printf+0x4e >> device_print_prettyname(c4277c80,c4289800,c4283e00,c4283e00,c3ee2b24,...) >> at device_print_prettyname+0x4c >> device_printf(c4277c80,c0bab5be,f4,0,c06da240,...) at >> device_printf+0x12 >> sis_initl(c4283e84,0,c0bab5a0,83a,80206910,...) at >> sis_initl+0x99d >> sis_ioctl(c428cc00,80206910,c45ab740,628,c428cc00,...) at >> sis_ioctl+0xa8 >> ifhwioctl(c44b08c0,c452122c,c0e4d6d0,c44b0964,c0e4d6d0,...) >> at ifhwioctl+0x3eb >> ifioctl(c4555ab8,80206910,c45ab740,c44b08c0,80206910,...) >> at ifioctl+0x305 >> soo_ioctl(c449f3b8,80206910,c45ab740,c4169400,c44b08c0,...) >> at soo_ioctl+0x397 >> kern_ioctl(c44b08c0,5,80206910,c45ab740,8318c0,...) at >> kern_ioctl+0x1dd >> ioctl(c44b08c0,c3ee2cf8,c,c0bf8ba3,c0c9b110,...) at >> ioctl+0x134 >> syscall(c3ee2d38) at syscall+0x2a3 >> Xint0x80_syscall() at Xint0x80_syscall+0x20 >> --- syscall (54, FreeBSD ELF32, ioctl), eip = 0x281a9a23, esp = 0xbfbfe5bc, >> ebp = 0xbfbfe618 --- > > well, this particular lor is caused by the fact that sc_cnputc() wants > to muck around kbd state. i do not know syscons code very well, but > this looks rather strange to me. i really do not know why the function > that really should just put a char on screen wants to do something > with kbd. i see the code tries to deal with scroll lock, so that is > consistent with your report. > > kbdmux was recently changed to use Giant based locking (as an attempt > to work around other problems). when update_kbd_state() uses ioctl() > on kbd device, kbdmux will try to grab Giant. the whole thing was > started by device_printf() that is called from sis_initl() with > another mutex held. > > so, to me, sc_cnputc() is broken and should be fixed. > Just to confirm it still exists. A bit different LOR though. CURRENT from December. lock order reversal: (Giant after non-sleepable) 1st 0xc5e08074 vnode interlock (vnode interlock) @ /usr/src/sys/vm/vnode_pager.c:1201 2nd 0xc087f9d0 Giant (Giant) @ /usr/src/sys/dev/kbdmux/kbdmux.c:1103 KDB: stack backtrace: db_trace_self_wrapper(c07f3714,e7cc564c,c05d7425,4,c07eec87,...) at db_trace_self_wrapper+0x26 kdb_backtrace(4,c07eec87,c54f50a8,c54f41a0,e7cc56a8,...) at kdb_backtrace+0x29 _witness_debugger(c07f639f,c087f9d0,c0807a3d,c54f41a0,c07df81e,...) at _witness_debugger+0x25 witness_checkorder(c087f9d0,9,c07df81e,44f,0,...) at witness_checkorder+0x839 _mtx_lock_flags(c087f9d0,0,c07df81e,44f,e7cc5700,...) at _mtx_lock_flags+0xc4 kbdmux_ioctl(c5608600,40044b13,e7cc5728,100202,c083e324,...) at kbdmux_ioctl+0x76e update_kbd_state(c0589e3c,c5df3e10,4,c07eec87,c0831bc0,...) at update_kbd_state+0x44 sc_cnputc(c0831bc0,6c,e7cc58f4,5,6c,...) at sc_cnputc+0x39 cnputc(6c,e7cc58f4,e7cc57a4,c05c9871,c07fd19d,...) at cnputc+0x5f putcons(c07fd19d,c07eec87,100009a,c09bfd80,c05c9810,...) at putcons+0x17 putchar(6c,e7cc58f4,246,c07e9e46,c59b0900,...) at putchar+0x61 kvprintf(c07f633c,c05c9810,e7cc58f4,a,e7cc5920,...) at kvprintf+0x9e printf(c07f633c,0,c07f55e7,4e3,e7cc5944,...) at printf+0x4e witness_checkorder(c5e08058,9,c07fd19d,81f,0,...) at witness_checkorder+0x6a1 __lockmgr_args(c5e08058,200501,c5e08074,0,0,...) at __lockmgr_args+0x797 vop_stdlock(e7cc5a78,c05d71cb,c0810948,200501,c5e08000,...) at vop_stdlock+0x62 VOP_LOCK1_APV(c5a2a000,e7cc5a78,c59b09a4,c0867bc0,c5e08000,...) at VOP_LOCK1_APV+0xa5 _vn_lock(c5e08000,200501,c07fd19d,81f,4,...) at _vn_lock+0x5e vget(c5e08000,200501,c59b0900,4b2,0,...) at vget+0xc9 vnode_pager_lock(c5e1a744,0,c080df26,127,e7cc5c18,...) at vnode_pager_lock+0x1e0 vm_fault(c5b91000,281a0000,1,0,281a0000,...) at vm_fault+0x1df trap_pfault(5,0,c08195a4,2e7,c59b0900,...) at trap_pfault+0xf9 trap(e7cc5d38) at trap+0x289 calltrap() at calltrap+0x6 --- trap 0xc, eip = 0x80496d0, esp = 0xbfbfec80, ebp = 0xbfbfed58 --- -- wbr, pluknet From owner-freebsd-current@FreeBSD.ORG Thu Dec 11 19:08:55 2008 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DA532106567A; Thu, 11 Dec 2008 19:08:55 +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 B7E3F8FC13; Thu, 11 Dec 2008 19:08:55 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTP id 5403846B2E; Thu, 11 Dec 2008 14:08:55 -0500 (EST) Date: Thu, 11 Dec 2008 19:08:55 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Roman Divacky In-Reply-To: <20081211174023.GA57297@freebsd.org> Message-ID: References: <20081210164345.GA32188@freebsd.org> <20081210214248.GA69246@freebsd.org> <20081211174023.GA57297@freebsd.org> User-Agent: Alpine 1.10 (BSF 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: current@FreeBSD.org Subject: Re: [PANIC]: rw_lock panic in in_pcballoc() in r185864 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Dec 2008 19:08:55 -0000 On Thu, 11 Dec 2008, Roman Divacky wrote: >>> I have the crash dump and the kernel at hand so I can do basically >>> anything you ask me to do :) anything I can provide? >> >> Well, to be honest, the easiest thing to do may be to play the binary >> search game to narrow down the point where the problem starts a bit more. >> There are a few kinds of things that might lead to this problem -- perhaps >> we (I?) mucked up initialization of the inpcb with recent changes, or a >> virtualization-related change tripped something up, or a locking/scheduler >> change or such. > > it's something between 185772 and 185864, dont you have any dhcp-enabled > machine? if so.. can you reproduce that? I have several boxes, real and virtual, using DHCP and very recent (tm) kernels and no sign of this panic. That's why I think there's something going on here that's a bit more subtle. For example, we'd really like to know what in the rw_wlock() call got tripped over as a NULL pointer... >> The other thing that would be helpful is a dump of *inp so that we can see >> what state inp_lock is in. > > I foolishly deleted the kernel matching the vmcore, I'll try to do that > tomorrow OK. Once you get the panic, I think the most interesting questions have to do with the contents of *inp, *inp->inp_lock.lock_object, etc. It might also be interesting to know whether any UDP use triggers the panic, or just DHCP. You can test this by booting to single-user, configuring lo0 manually, and then doing "dig @127.0.0.1 ." or some other activity that triggers a UDP packet to be sent. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-current@FreeBSD.ORG Thu Dec 11 19:32:01 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4F8AE106567B for ; Thu, 11 Dec 2008 19:32:01 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from palm.hoeg.nl (mx0.hoeg.nl [IPv6:2001:7b8:613:100::211]) by mx1.freebsd.org (Postfix) with ESMTP id 15E9B8FC16 for ; Thu, 11 Dec 2008 19:32:01 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: by palm.hoeg.nl (Postfix, from userid 1000) id 2D0801CE11; Thu, 11 Dec 2008 20:34:50 +0100 (CET) Date: Thu, 11 Dec 2008 20:34:50 +0100 From: Ed Schouten To: pluknet Message-ID: <20081211193450.GF1176@hoeg.nl> References: <48ED3D0F.6050209@cran.org.uk> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="2NLGdgz3UMHa/lqP" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: Bruce Cran , current@freebsd.org, Maksim Yevmenkin Subject: Re: LOR during boot (if_sis.c/kbdmux.c - Giant after non-sleepable) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Dec 2008 19:32:01 -0000 --2NLGdgz3UMHa/lqP Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello, * pluknet wrote: > lock order reversal: (Giant after non-sleepable) > 1st 0xc4283e84 sis0 (network driver) @ > /usr/src/sys/dev/sis/if_sis.c:2106 > 2nd 0xc0d0d430 Giant (Giant) @ > /usr/src/sys/dev/kbdmux/kbdmux.c:1103 This problem is probably related to this PR: http://www.freebsd.org/cgi/query-pr.cgi?pr=3D127446 --=20 Ed Schouten WWW: http://80386.nl/ --2NLGdgz3UMHa/lqP Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAklBa1oACgkQ52SDGA2eCwVHsQCdHHp66fyPHfXHbunRh7iOJ2tM koIAn0xf3IY7gz7DZ2FtsxdyxsrgY+Ua =FroD -----END PGP SIGNATURE----- --2NLGdgz3UMHa/lqP-- From owner-freebsd-current@FreeBSD.ORG Thu Dec 11 19:43:13 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D608E1065670 for ; Thu, 11 Dec 2008 19:43:13 +0000 (UTC) (envelope-from olivier@gid0.org) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.30]) by mx1.freebsd.org (Postfix) with ESMTP id 99EE38FC14 for ; Thu, 11 Dec 2008 19:43:13 +0000 (UTC) (envelope-from olivier@gid0.org) Received: by yx-out-2324.google.com with SMTP id 8so519331yxb.13 for ; Thu, 11 Dec 2008 11:43:13 -0800 (PST) Received: by 10.142.237.19 with SMTP id k19mr942276wfh.31.1229022736491; Thu, 11 Dec 2008 11:12:16 -0800 (PST) Received: by 10.142.170.10 with HTTP; Thu, 11 Dec 2008 11:12:16 -0800 (PST) Message-ID: <367b2c980812111112u4d5f59ct788c43fbdc64840e@mail.gmail.com> Date: Thu, 11 Dec 2008 20:12:16 +0100 From: "Olivier SMEDTS" To: pluknet In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <5f67a8c40812041432y13793ee5k1d2526c9829dc16f@mail.gmail.com> Cc: Zaphod Beeblebrox , freebsd-current Subject: Re: SATA CD fail. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Dec 2008 19:43:13 -0000 2008/12/11 pluknet : > 2008/12/5 pluknet : >> 2008/12/5 Zaphod Beeblebrox : >>> I've got an HP DL-360 1U here that has a slim SATA CDROM. I've (so far) >>> tried booting FreeBSD-7.0-RELEASE and FreeBSD-7.1-BETA2. I've tried both >>> rewritable media (my first choice) and write-once media. The kernel loads >>> fine, but multiuser fails with "acd0: TIMEOUT - READ_BIG retrying" ... >>> twice, followed by "timed out". I've got the same issue with my SATA DVD-RW drive when trying tu burn a media. I can "burncd blank" but I have the same errors than you when trying to "burncd data image.iso fixate". I don't remember if I had problems installing 7.0-RELEASE with a CD-ROM on my computer 6 months ago. I use latest -CURRENT on amd64. >> I workarounded this by ejecting CD after kernel is loaded but before >> probing media, then >> installing from sysinstall via NFS from this CD inserted on nearby >> with IDE CDROM computer. >> > [redirected from -stable] > > This issue was on recent CURRENT around November for me. > And hey. After later cvsup to Dec 11 this problem disappeared. > Now it boots with media injected in SATA DVD. > > acd0: DVDR at ata4-master SATA150 > GEOM_LABEL: Label for provider acd0 is iso9660/STALKER_CS. > > -- > wbr, > pluknet > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > -- Olivier Smedts _ ASCII ribbon campaign ( ) e-mail: olivier@gid0.org - against HTML email & vCards X www: http://www.gid0.org - against proprietary attachments / \ "Il y a seulement 10 sortes de gens dans le monde : ceux qui comprennent le binaire, et ceux qui ne le comprennent pas." From owner-freebsd-current@FreeBSD.ORG Thu Dec 11 20:36:02 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F1C9E1065670 for ; Thu, 11 Dec 2008 20:36:02 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.234]) by mx1.freebsd.org (Postfix) with ESMTP id 8703A8FC1A for ; Thu, 11 Dec 2008 20:36:02 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so1024206rvf.43 for ; Thu, 11 Dec 2008 12:36:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=OSO03p+RlLYr/UWW6YAj3bpoEzSZ4nnYkcRQ6DVCnMY=; b=frka6h50SLXPmlYJi30oeHXLU/nJRRi7LE1MKu2bTiJHW1iJ/fPQK8atg1Zuo7sGcK 5FPXy6GBUMOJqpps6Xy0eA9SqYTD+b1IbblSuq+EJwo7BdL40ElLEdZ6DEe4Wvys7J5I vPYC7qU+cylSAT85YWoRPIPiZ5bcRWfYiB98U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=qQdeauExR4/H10QZGnwbPWepQIH3n5LtSkSN8SlXI/S3mfyVOgDNIk3xQ8gwykbvoJ Llu8KVWXsCfalScbknUt3f7IYg8DQNTR7o8bY0aixGSmtHnhC8cerdY9MzyH2vU5++0E mKvoZBxzp9W+qa1tJ9CHV8p0tHFEaTo0hxue4= Received: by 10.141.18.12 with SMTP id v12mr1464280rvi.187.1229027762113; Thu, 11 Dec 2008 12:36:02 -0800 (PST) Received: by 10.140.158.13 with HTTP; Thu, 11 Dec 2008 12:36:02 -0800 (PST) Message-ID: <7d6fde3d0812111236t1b234271xcd7cf0ad7db6b99d@mail.gmail.com> Date: Thu, 11 Dec 2008 12:36:02 -0800 From: "Garrett Cooper" To: "Wesley Shields" In-Reply-To: <20081211203220.GE150@atarininja.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1228555830.1186.6.camel@www.boolome.cn> <7d6fde3d0812080155y22cc7c0bne1fa0094671355e4@mail.gmail.com> <1228787330.13158.0.camel@www.boolome.cn> <53DC39AE-EE1E-41DE-801D-45737249D93B@gmail.com> <1228869506.1255.3.camel@www.boolome.cn> <7d6fde3d0812110140y44df387dg14f83c5483fe96ff@mail.gmail.com> <20081211203220.GE150@atarininja.org> Cc: freebsd-current@freebsd.org, boolome Subject: Re: make buildworld failed! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Dec 2008 20:36:03 -0000 On Thu, Dec 11, 2008 at 12:32 PM, Wesley Shields wrote: > On Thu, Dec 11, 2008 at 01:40:40AM -0800, Garrett Cooper wrote: >> On Tue, Dec 9, 2008 at 4:38 PM, boolome wrote: >> > ?$B:_ 2008-12-09?$BFsE* 03:18 -0800?$B!$Garrett Cooper?$B> >> On Dec 8, 2008, at 5:48 PM, boolome wrote: >> >> >> >> > ?$B:_ 2008-12-08?$B0lE* 01:55 -0800?$B!$Garrett Cooper?$B> >> >> On Sat, Dec 6, 2008 at 1:30 AM, boolome wrote: >> >> >> [snip] >> >> >> >> >> >> Looks like your source tree is incomplete. >> >> >> -Garrett >> >> > >> >> > But have cvsup the latest source tree ! >> >> >> >> It's not necessarily your fault though. What cvsup server are you >> >> using and did you interrupt it during an update? >> >> -Garrett >> > >> > The cvsup server is cvsup.freebsd.org . >> > >> > During an update ,I did not interrupt it. >> > >> > But when I got to that dir executed :make obj && make depend && >> > make ,successed.. >> > >> > Is the soure tree's problem ? >> > By the way I 'am using a custom kernel . >> >> Hmmm.. not sure. If I had logs I could help you out more, but >> unfortunately I don't ;(. > > Unless I missed it the cause of the error is not in the logs provided. > Were you building in parallel? > >> I'd chock it up to a bad build environment or maybe just bad prebuilt objs. > > My money is on a broken kernel config. > > -- WXS Yeah, well either way we don't have enough data to say with absolute authority that "this is the root cause of the failure". A full log would have been incredibly helpful. And FWIW it looks like it was a bootstrap toolchain error (it failed running flex to bootstrap gcc). -Garrett From owner-freebsd-current@FreeBSD.ORG Thu Dec 11 20:48:30 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C2E4D1065675 for ; Thu, 11 Dec 2008 20:48:30 +0000 (UTC) (envelope-from wxs@atarininja.org) Received: from syn.atarininja.org (syn.csh.rit.edu [129.21.60.158]) by mx1.freebsd.org (Postfix) with ESMTP id 9C9D18FC2B for ; Thu, 11 Dec 2008 20:48:30 +0000 (UTC) (envelope-from wxs@atarininja.org) Received: by syn.atarininja.org (Postfix, from userid 1001) id 7306C5C17; Thu, 11 Dec 2008 15:32:20 -0500 (EST) Date: Thu, 11 Dec 2008 15:32:20 -0500 From: Wesley Shields To: Garrett Cooper Message-ID: <20081211203220.GE150@atarininja.org> References: <1228555830.1186.6.camel@www.boolome.cn> <7d6fde3d0812080155y22cc7c0bne1fa0094671355e4@mail.gmail.com> <1228787330.13158.0.camel@www.boolome.cn> <53DC39AE-EE1E-41DE-801D-45737249D93B@gmail.com> <1228869506.1255.3.camel@www.boolome.cn> <7d6fde3d0812110140y44df387dg14f83c5483fe96ff@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7d6fde3d0812110140y44df387dg14f83c5483fe96ff@mail.gmail.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-current@freebsd.org, boolome Subject: Re: make buildworld failed! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Dec 2008 20:48:30 -0000 On Thu, Dec 11, 2008 at 01:40:40AM -0800, Garrett Cooper wrote: > On Tue, Dec 9, 2008 at 4:38 PM, boolome wrote: > > ?$B:_ 2008-12-09?$BFsE* 03:18 -0800?$B!$Garrett Cooper?$B >> On Dec 8, 2008, at 5:48 PM, boolome wrote: > >> > >> > ?$B:_ 2008-12-08?$B0lE* 01:55 -0800?$B!$Garrett Cooper?$B >> >> On Sat, Dec 6, 2008 at 1:30 AM, boolome wrote: > >> >> [snip] > >> >> > >> >> Looks like your source tree is incomplete. > >> >> -Garrett > >> > > >> > But have cvsup the latest source tree ! > >> > >> It's not necessarily your fault though. What cvsup server are you > >> using and did you interrupt it during an update? > >> -Garrett > > > > The cvsup server is cvsup.freebsd.org . > > > > During an update ,I did not interrupt it. > > > > But when I got to that dir executed :make obj && make depend && > > make ,successed.. > > > > Is the soure tree's problem ? > > By the way I 'am using a custom kernel . > > Hmmm.. not sure. If I had logs I could help you out more, but > unfortunately I don't ;(. Unless I missed it the cause of the error is not in the logs provided. Were you building in parallel? > I'd chock it up to a bad build environment or maybe just bad prebuilt objs. My money is on a broken kernel config. -- WXS From owner-freebsd-current@FreeBSD.ORG Thu Dec 11 20:53:40 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 852B61065670 for ; Thu, 11 Dec 2008 20:53:40 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.229]) by mx1.freebsd.org (Postfix) with ESMTP id 5619C8FC1D for ; Thu, 11 Dec 2008 20:53:40 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so1030967rvf.43 for ; Thu, 11 Dec 2008 12:53:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=SNIIPK6UJ742j1HUQ/JOhiSz5GLHD4kcnEeNIAokItU=; b=GyTCP9whXFOjgIePoJFORqUVPzr4AJRL2l6A4gK1c5nQmEiwB2m2rGCBFC3bxr5LJV YnIOLW95DdC5gugOFahMKJfaA9OdwWI6YpWix6Lt1Ud9JHJyj2HVLN1i7WTU4jmT8BrH KfV26WpG+Y0UNdrjtjYmH8PyYi3wraxsb2M7g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=DEOxDc+FVmDwzWW93Pku8k/jUZjYA3HxMDZ3leHGXkych/mAXXwD2h7scoBYKgre/V TJyTmiVNPqh1iZ75730A7qz+PvtZ4t/zFRxi/zVZUX3u3nRs2nkxztGFdbU8CghVzoq2 zYJ2dojJ001H6bXdHUtj07N0f4ZiA4j3wrh2E= Received: by 10.141.84.17 with SMTP id m17mr1478577rvl.64.1229028820006; Thu, 11 Dec 2008 12:53:40 -0800 (PST) Received: by 10.140.158.13 with HTTP; Thu, 11 Dec 2008 12:53:39 -0800 (PST) Message-ID: <7d6fde3d0812111253n4b8f7135n76e9cef63158943e@mail.gmail.com> Date: Thu, 11 Dec 2008 12:53:39 -0800 From: "Garrett Cooper" To: "WATANABE Kazuhiro" In-Reply-To: <20081211130057.B53EE5D0A4@mail.asahi-net.or.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20081210125627.25732615CD@mail.asahi-net.or.jp> <494019AB.3020505@samsco.org> <20081211130057.B53EE5D0A4@mail.asahi-net.or.jp> Cc: freebsd-current Subject: Re: [patch] de(4) has not worked on 8-current since Feb 13 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Dec 2008 20:53:40 -0000 On Thu, Dec 11, 2008 at 5:00 AM, WATANABE Kazuhiro wrote: > CC'ed to freebsd-current. > > At Wed, 10 Dec 2008 12:34:03 -0700, > Scott Long wrote: >> WATANABE Kazuhiro wrote: >> > Hi, all. >> > >> > My de(4) NICs has not worked on 8-current since Feb 13. >> > >> > >> >> Can you define "not worked" a little better? Does it give errors, or >> corrupt data, or appear to not transmit and/or receive? >> >> Scott > > Thanks for your reply. I should have written more details about the > problem... > > On recent 8-current, my de(4) NICs cannot send any (almost all) data > from it. > > * The system boots normally. > > * Probing/attaching the de(4) NICs are done successfully. > > * The system can receive data from the other hosts. For example the > following command was finished normally in 14 seconds: > > $ /usr/bin/time scp other_host:/boot/kernel/kernel . > Password: > kernel 100% 4717KB 471.7KB/s 00:10 > 14.03 real 0.53 user 0.40 sys > $ > > * The system cannot send any data to the other hosts. For example > the following command was "stalled" and never finished > (I interrupted the command after 5 minutes). None of the data were > sent: > > $ /usr/bin/time scp /boot/kernel/kernel other_host: > Password: > kernel 1% 192KB 0.0KB/s - stalled -^CKilled by signal 2. > 336.01 real 0.05 user 0.17 sys > $ > > * The system doesn't show any error/warning messages. > > * I can "slogin" from the other hosts to the system, and some small > amount of text output (ex. an output of "dmesg") are done > successfully. But a bit large amount of text output are stopped > after a few seconds. For example: > > $ ls -l /boot/kernel/kernel > -r-xr-xr-x 1 root wheel 10975839 Dec 11 13:46 /boot/kernel/kernel > $ hd /boot/kernel/kernel | head > 00000000 7f 45 4c 46 01 01 01 09 00 00 00 00 00 00 00 00 |.ELF............| > 00000010 02 00 03 00 01 00 00 00 e0 c5 46 c0 34 00 00 00 |..........F.4...| > 00000020 58 22 92 00 00 00 00 00 34 00 20 00 05 00 28 00 |X"......4. ...(.| > 00000030 23 00 20 00 06 00 00 00 34 00 00 00 34 00 40 c0 |#. .....4...4.@.| > 00000040 34 00 40 c0 a0 00 00 00 a0 00 00 00 05 00 00 00 |4.@.............| > 00000050 04 00 00 00 03 00 00 00 d4 00 00 00 d4 00 40 c0 |..............@.| > 00000060 d4 00 40 c0 0d 00 00 00 0d 00 00 00 04 00 00 00 |..@.............| > 00000070 01 00 00 00 01 00 00 00 00 00 00 00 00 00 40 c0 |..............@.| > 00000080 00 00 40 c0 a0 ca 81 00 a0 ca 81 00 05 00 00 00 |..@.............| > 00000090 00 10 00 00 01 00 00 00 a0 ca 81 00 a0 da c1 c0 |................| > $ hd /boot/kernel/kernel > 00000000 7f 45 4c 46 01 01 01 09 00 00 00 00 00 00 00 00 |.ELF............| > 00000010 02 00 03 00 01 00 00 00 e0 c5 46 c0 34 00 00 00 |..........F.4...| > 00000020 58 22 92 00 00 00 00 00 34 00 20 00 05 00 28 00 |X"......4. ...(.| > 00000030 23 00 20 00 06 00 00 00 34 00 00 00 34 00 40 c0 |#. .....4...4.@.| > 00000040 34 00 40 c0 a0 00 00 00 a0 00 00 00 05 00 00 00 |4.@.............| > (snip) > 00005d90 0a 20 00 00 0b 00 00 00 00 00 00 00 70 15 00 00 |. ..........p...| > 00005da0 ce 2a 00 00 36 23 00 00 c6 2a 00 00 0b 14 00 00 |.*..6#...*......| > 00005db0 7c 03 00 00 b1 27 00 00 d9 1e 00 00 2e 15 00 00 ||....'..........| > 00005dc0 00 00 00 00 6d 22 00 00 04 2a 00 00 72 23 00 00 |....m"...*..r#..| > 00005dd0 00 00 00 00 00 00 00 00 d3 1f 00 00 00 00 00 00 |................| > (Stopped here. 0x5de0 == 24032 bytes) Hmm... definitely a TXO issue. msk(4) had similar problems with my chipset using an MTU of 1492 and checksumming until I provided Pyun some data which helped him improve the driver code for the chipset. Probably not the case here, but are there any tcpdump sessions with raw frames that we could get to help traceback the cause? Thanks, -Garrett From owner-freebsd-current@FreeBSD.ORG Thu Dec 11 21:32:35 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A1C6D1065672 for ; Thu, 11 Dec 2008 21:32:35 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.terabit.net.ua (mail.terabit.net.ua [195.137.202.147]) by mx1.freebsd.org (Postfix) with ESMTP id 3B8408FC1C for ; Thu, 11 Dec 2008 21:32:35 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from skuns.zoral.com.ua ([91.193.166.194] helo=mail.zoral.com.ua) by mail.terabit.net.ua with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63 (FreeBSD)) (envelope-from ) id 1LAt97-000DYe-55; Thu, 11 Dec 2008 23:32:33 +0200 Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id mBBLWRqL075193 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 11 Dec 2008 23:32:27 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3) with ESMTP id mBBLWRWl052439; Thu, 11 Dec 2008 23:32:27 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3/Submit) id mBBLWRak052438; Thu, 11 Dec 2008 23:32:27 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 11 Dec 2008 23:32:27 +0200 From: Kostik Belousov To: Randy Bush Message-ID: <20081211213227.GX2038@deviant.kiev.zoral.com.ua> References: <4940A685.7040608@psg.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="jrD2fTATTFYrkNk2" Content-Disposition: inline In-Reply-To: <4940A685.7040608@psg.com> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua X-Virus-Scanned: mail.terabit.net.ua 1LAt97-000DYe-55 438f26493986dd12bbf14f36f0cd5b57 X-Terabit: YES Cc: FreeBSD Current Subject: Re: panic: sleeping thread & bufwrite: buffer is not busy??? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Dec 2008 21:32:35 -0000 --jrD2fTATTFYrkNk2 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Dec 11, 2008 at 02:35:01PM +0900, Randy Bush wrote: > i386 soekris 5501 > current as of Dec 11 00:27 gmt >=20 > Unread portion of the kernel message buffer: > Sleeping thread (tid 100054, pid 646) owns a non-sleepable lock > panic: sleeping thread > panic: bufwrite: buffer is not busy??? > Uptime: 2m1s > Physical memory: 503 MB >=20 > #0 doadump () at pcpu.h:246 > #1 0xc0571f33 in boot (howto=3D260) at /usr/src/sys/kern/kern_shutdown.c= :420 > #2 0xc05720f7 in panic (fmt=3DVariable "fmt" is not available.) > at /usr/src/sys/kern/kern_shutdown.c:576 > #3 0xc06fc75c in ffs_bufwrite (bp=3D0xc2937e20) > at /usr/src/sys/ufs/ffs/ffs_vfsops.c:1786 > #4 0xc05c7250 in vfs_bio_awrite (bp=3D0xc2937e20) at buf.h:385 > #5 0xc05cfee0 in vop_stdfsync (ap=3D0xc2a89b34) > at /usr/src/sys/kern/vfs_default.c:479 > #6 0xc0520ad3 in devfs_fsync (ap=3D0xc2a89b34) > at /usr/src/sys/fs/devfs/devfs_vnops.c:485 > #7 0xc074e50e in VOP_FSYNC_APV (vop=3D0xc07cc800, a=3D0xc2a89b34) > at vnode_if.c:1007 > #8 0xc06fd0a2 in ffs_sync (mp=3D0xc2e33c80, waitfor=3D2, td=3D0xc2c28480) > at vnode_if.h:529 > #9 0xc05e0803 in sync (td=3D0xc2c28480, uap=3D0x0) > at /usr/src/sys/kern/vfs_syscalls.c:149 > #10 0xc0571ad2 in boot (howto=3D256) at /usr/src/sys/kern/kern_shutdown.c= :312 > #11 0xc05720f7 in panic (fmt=3DVariable "fmt" is not available.) > at /usr/src/sys/kern/kern_shutdown.c:576 > #12 0xc059ec81 in propagate_priority (td=3D0xc2e696c0) > at /usr/src/sys/kern/subr_turnstile.c:222 > #13 0xc059f551 in turnstile_wait (ts=3D0xc2c0ee10, owner=3D0xc2e696c0,=20 > queue=3DVariable "queue" is not available.) > at /usr/src/sys/kern/subr_turnstile.c:738 > #14 0xc0570c73 in _rw_wlock_hard (rw=3D0xc2cdcd80, tid=3D3267527808,=20 > file=3D0x0, line=3D0) > at /usr/src/sys/kern/kern_rwlock.c:705 > #15 0xc06bdcb6 in in6_mtutimo (rock=3D0xc2cdcd00) > at /usr/src/sys/netinet6/in6_rmx.c:437 > #16 0xc0580f77 in softclock (arg=3D0xc07ffbe0) > at /usr/src/sys/kern/kern_timeout.c:398 > #17 0xc055790a in intr_event_execute_handlers (p=3D0xc2c257ec, ie=3D0xc2c= 22400) > at /usr/src/sys/kern/kern_intr.c:1134 > #18 0xc0558933 in ithread_loop (arg=3D0xc2c07ba0) > at /usr/src/sys/kern/kern_intr.c:1147 > #19 0xc0555cb6 in fork_exit (callout=3D0xc05588d0 , > arg=3D0xc2c07ba0, frame=3D0xc2a89d38) at /usr/src/sys/kern/kern_fork.= c:821 > #20 0xc0730a50 in fork_trampoline () at=20 > /usr/src/sys/i386/i386/exception.s:270 Do you have sysctl kern.sync_on_panic=3D1 ? The trace looks like some problem in ipv6, panic, attempt to sync ufs, and second panic due to locking actually turned off by the first panic. --jrD2fTATTFYrkNk2 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAklBht0ACgkQC3+MBN1Mb4isXwCg9Iq15ZI3Y7OMLPHJVDexsCFd JS0AoMF0JHqcw+doCNPVJhf7ZgNU1lgn =PcPS -----END PGP SIGNATURE----- --jrD2fTATTFYrkNk2-- From owner-freebsd-current@FreeBSD.ORG Thu Dec 11 21:38:06 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 01594106564A; Thu, 11 Dec 2008 21:38:06 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.236]) by mx1.freebsd.org (Postfix) with ESMTP id 24B298FC22; Thu, 11 Dec 2008 21:38:04 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so1047701rvf.43 for ; Thu, 11 Dec 2008 13:38:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=6PtEuUNqYyP9mJFuKpNjjXDfyp2LXS8p+viVpNCdBMY=; b=E1XLX6jejNFgbsSHorze3uM42F7ZTU4q4KlxftgmCydwV+KgfK3xCn21fqk74AT0OU IcH82x2gsWE/LgrOcekuK4W5/c+tGihnWm6p0SXF8y03BgTTpBmedRGPjLVk8Q7rG+al K++PHlMCUE4rHnNJjx2XVM11N+vizAr4/Omd8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=lNATF6M/VdcPELMlWs0NkvfjOa9GpVdtpAhDX+cKGeJrCGhbsoLqkLTIQL+gZGTlmG 4ZeJmfISQUBR29GhDEWVEFT9SVw35qHVNixUrnH3SEdS6/l/JoKHhyMf5irS+K13ShCt tT0QTCchsmiV75QtDNpH/xMuT/7g/xHM7pDVg= Received: by 10.141.48.6 with SMTP id a6mr1504265rvk.36.1229031484656; Thu, 11 Dec 2008 13:38:04 -0800 (PST) Received: by 10.141.142.3 with HTTP; Thu, 11 Dec 2008 13:38:04 -0800 (PST) Message-ID: <3c1674c90812111338p69c33bd5sa26315cba4981011@mail.gmail.com> Date: Thu, 11 Dec 2008 13:38:04 -0800 From: "Kip Macy" Sender: mat.macy@gmail.com To: "Bruce M. Simpson" In-Reply-To: <49415977.6010307@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200812100740.mBA7eqjO034924@freefall.freebsd.org> <49415977.6010307@FreeBSD.org> X-Google-Sender-Auth: 1449877b1265c4a8 Cc: Qing Li , current@freebsd.org, freebsd-net@freebsd.org Subject: Re: last call for L2/L3 rewrite code review X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Dec 2008 21:38:06 -0000 I think that you're request to not monopolize the AF_INET slot is reasonable. Do you intend to merge bms_netdev before 8 branches (I'm guessing this coming summer)? Cheers, Kip On Thu, Dec 11, 2008 at 10:18 AM, Bruce M. Simpson wrote: > Hi, > > Just skimming this I notice it uses the if_afdata[AF_INET] pointer purely > for lltbl purposes; this clashes with the IGMPv3 code drop. > > Please look in the bms_netdev branch, where I introduce a 'struct ip_ifinfo' > to make more general use of that slot. IGMPv3 needs to store per-interface > state for AF_INET, so this slot really needs to be shared with other AF_INET > stuff. > > Looks like it needs to be updated for VIMAGE also, hopefully others more > familiar with this can help -- I am busy enough with non-programming > activity as it is to get up to speed on this, although I have at least > managed to print Julian's write-up... > > Other than that, it looks like a much needed improvement and we are all very > grateful for our work on this. > > thanks > BMS > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > -- If we desire respect for the law, we must first make the law respectable. - Louis D. Brandeis From owner-freebsd-current@FreeBSD.ORG Thu Dec 11 21:53:32 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 831A3106564A for ; Thu, 11 Dec 2008 21:53:32 +0000 (UTC) (envelope-from cryx-freebsd@h3q.com) Received: from mail.h3q.com (mail.h3q.com [213.73.89.199]) by mx1.freebsd.org (Postfix) with ESMTP id C11A58FC1D for ; Thu, 11 Dec 2008 21:53:30 +0000 (UTC) (envelope-from cryx-freebsd@h3q.com) Received: (qmail 86756 invoked from network); 11 Dec 2008 21:53:29 -0000 Received: from unknown (HELO goa.local) (smtpsend@85.179.28.10) by mail.h3q.com with AES256-SHA encrypted SMTP; 11 Dec 2008 21:53:29 -0000 Message-ID: <49418BD9.8080105@h3q.com> Date: Thu, 11 Dec 2008 22:53:29 +0100 From: Philipp Wuensche User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105) MIME-Version: 1.0 To: bseklecki@collaborativefusion.com References: <20081201085229.D80401@maildrop.int.zabbadoz.net> <20081201122937.81475f0zhfsjya4o@webmail.leidinger.net> <6ae50c2d0812021800x791d2cfeh45d590de120f76df@mail.gmail.com> <1228483574.2805.499.camel@soundwave.ws.pitbpa0.priv.collaborativefusion.com> <86skp2l804.fsf@ds4.des.no> <1228507529.2805.539.camel@soundwave.ws.pitbpa0.priv.collaborativefusion.com> In-Reply-To: <1228507529.2805.539.camel@soundwave.ws.pitbpa0.priv.collaborativefusion.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: FreeBSD virtualization mailing list , Alexander Leidinger , alexus , freebsd-current@freebsd.org, =?UTF-8?B?RGFnLUVybGluZyBTbcO4cmdyYXY=?= , "Bjoern A. Zeeb" , freebsd-jail@freebsd.org Subject: Re: HEADS UP: r185435 multi-IPv4/v6/no-IP jails in HEAD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Dec 2008 21:53:32 -0000 Brian A. Seklecki wrote: > On Fri, 2008-12-05 at 20:47 +0100, Dag-Erling Smørgrav wrote: >> The question is, does it change existing behavior, or just add new >> functionality? > > The syntax semantics should be backward compatible, so likely the > latter. Not entirely true, the jls output is totaly different than before and breaks third-party applications like jailaudit and ezjail. It is uneasy to parse too. greetings, Philipp From owner-freebsd-current@FreeBSD.ORG Thu Dec 11 22:19:26 2008 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 46F5D106564A; Thu, 11 Dec 2008 22:19:26 +0000 (UTC) (envelope-from rdivacky@lev.vlakno.cz) Received: from vlakno.cz (77-93-215-190.static.masterinter.net [77.93.215.190]) by mx1.freebsd.org (Postfix) with ESMTP id F1C948FC19; Thu, 11 Dec 2008 22:19:25 +0000 (UTC) (envelope-from rdivacky@lev.vlakno.cz) Received: from localhost (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id 623309CB19A; Thu, 11 Dec 2008 23:14:39 +0100 (CET) X-Virus-Scanned: amavisd-new at vlakno.cz Received: from vlakno.cz ([127.0.0.1]) by localhost (lev.vlakno.cz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hbUGkvF3TLfS; Thu, 11 Dec 2008 23:14:27 +0100 (CET) Received: from lev.vlakno.cz (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id A42D89CB238; Thu, 11 Dec 2008 23:14:27 +0100 (CET) Received: (from rdivacky@localhost) by lev.vlakno.cz (8.14.2/8.14.2/Submit) id mBBMERs7012442; Thu, 11 Dec 2008 23:14:27 +0100 (CET) (envelope-from rdivacky) Date: Thu, 11 Dec 2008 23:14:27 +0100 From: Roman Divacky To: Robert Watson Message-ID: <20081211221427.GA12310@freebsd.org> References: <20081210164345.GA32188@freebsd.org> <20081210214248.GA69246@freebsd.org> <20081211174023.GA57297@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: current@FreeBSD.org Subject: Re: [PANIC]: rw_lock panic in in_pcballoc() in r185864 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Dec 2008 22:19:26 -0000 On Thu, Dec 11, 2008 at 07:08:55PM +0000, Robert Watson wrote: > > On Thu, 11 Dec 2008, Roman Divacky wrote: > > >>>I have the crash dump and the kernel at hand so I can do basically > >>>anything you ask me to do :) anything I can provide? > >> > >>Well, to be honest, the easiest thing to do may be to play the binary > >>search game to narrow down the point where the problem starts a bit more. > >>There are a few kinds of things that might lead to this problem -- > >>perhaps we (I?) mucked up initialization of the inpcb with recent > >>changes, or a virtualization-related change tripped something up, or a > >>locking/scheduler change or such. > > > >it's something between 185772 and 185864, dont you have any dhcp-enabled > >machine? if so.. can you reproduce that? > > I have several boxes, real and virtual, using DHCP and very recent (tm) > kernels and no sign of this panic. That's why I think there's something > going on here that's a bit more subtle. For example, we'd really like to > know what in the rw_wlock() call got tripped over as a NULL pointer... > > >>The other thing that would be helpful is a dump of *inp so that we can > >>see what state inp_lock is in. > > > >I foolishly deleted the kernel matching the vmcore, I'll try to do that > >tomorrow > > OK. Once you get the panic, I think the most interesting questions have to > do with the contents of *inp, *inp->inp_lock.lock_object, etc. It might > also be interesting to know whether any UDP use triggers the panic, or just > DHCP. You can test this by booting to single-user, configuring lo0 > manually, and then doing "dig @127.0.0.1 ." or some other activity that > triggers a UDP packet to be sent. I just booted r185942 and it seems to work fine, so I guess it could have been some stale obj file or something. sorry for the noise From owner-freebsd-current@FreeBSD.ORG Thu Dec 11 22:21:26 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 397ED1065675; Thu, 11 Dec 2008 22:21:26 +0000 (UTC) (envelope-from rdivacky@lev.vlakno.cz) Received: from vlakno.cz (77-93-215-190.static.masterinter.net [77.93.215.190]) by mx1.freebsd.org (Postfix) with ESMTP id A12E28FC17; Thu, 11 Dec 2008 22:21:25 +0000 (UTC) (envelope-from rdivacky@lev.vlakno.cz) Received: from localhost (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id 2DC719CB19A; Thu, 11 Dec 2008 23:16:40 +0100 (CET) X-Virus-Scanned: amavisd-new at vlakno.cz Received: from vlakno.cz ([127.0.0.1]) by localhost (lev.vlakno.cz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 84PrVd3hhdKT; Thu, 11 Dec 2008 23:16:28 +0100 (CET) Received: from lev.vlakno.cz (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id 439A29CB238; Thu, 11 Dec 2008 23:16:28 +0100 (CET) Received: (from rdivacky@localhost) by lev.vlakno.cz (8.14.2/8.14.2/Submit) id mBBMGSnS012718; Thu, 11 Dec 2008 23:16:28 +0100 (CET) (envelope-from rdivacky) Date: Thu, 11 Dec 2008 23:16:28 +0100 From: Roman Divacky To: John Baldwin Message-ID: <20081211221628.GA12494@freebsd.org> References: <20081120171325.GA53026@freebsd.org> <200812041424.13298.jhb@freebsd.org> <20081204220438.GA17059@freebsd.org> <200812041745.14587.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="p4qYPpj5QlsIQJ0K" Content-Disposition: inline In-Reply-To: <200812041745.14587.jhb@freebsd.org> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org Subject: Re: atrtc0: Warnings about mappings of I/O and interrupt X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Dec 2008 22:21:26 -0000 --p4qYPpj5QlsIQJ0K Content-Type: multipart/mixed; boundary="zYM0uCDKw75PZbzx" Content-Disposition: inline --zYM0uCDKw75PZbzx Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Dec 04, 2008 at 05:45:14PM -0500, John Baldwin wrote: > On Thursday 04 December 2008 05:04:38 pm Roman Divacky wrote: > > On Thu, Dec 04, 2008 at 02:24:13PM -0500, John Baldwin wrote: > > > On Thursday 20 November 2008 12:13:25 pm Roman Divacky wrote: > > > > hi > > > >=20 > > > > I upgraded from roughly 10 days old -CURRENT to this: > > > >=20 > > > > FreeBSD witten 8.0-CURRENT FreeBSD 8.0-CURRENT #55: Wed Nov 19 23:2= 3:49=20 > CET=20 > > > 2008 > > > > root@witten:/usr/obj/usr/src/sys/MYKERNEL i386 > > > >=20 > > > > and I am getting this at boot: > > > >=20 > > > > atrtc0: at port 0x70 irq 8 on isa0 > > > > atrtc0: Warning: Couldn't map I/O. > > > > atrtc0: Warning: Couldn't map Interrupt. > > > >=20 > > > > the booting itself works fine and I dont see any odd effects. > > >=20 > > > The driver is just a stub anyway. Do you have any atrtc0 hints, and = can=20 > you=20 > > > grab the output for the 'atrtc0' device from 'devinfo -r'? > >=20 > > witten ~# grep atrtc /boot/device.hints > > hint.atrtc.0.at=3D"isa" > > hint.atrtc.0.port=3D"0x70" > > hint.atrtc.0.irq=3D"8" > >=20 > > (but that's the default I believe) > >=20 > > devinfo -r shows "empty" atrtc0 but: > >=20 > > atrtc1 > > Interrupt request lines: > > 8 > > I/O ports: > > 0x70-0x71 > >=20 > > any more info I can provide? >=20 > Hmmmm, that should have worked fine in that atrtc1 should have taken over= =20 > the 'atrtc0' hints. If you don't mind, can you add some debugging printf= s to=20 > acpi_hint_device_unit() (maybe only do them if the 'name' parameter=20 > is "atrtc" to avoid clutter). with the attached patch I am getting the attached dmesg. do you want me to do some other thing? roman --zYM0uCDKw75PZbzx Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="acpi.patch" Content-Transfer-Encoding: quoted-printable Index: acpi.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- acpi.c (revision 185942) +++ acpi.c (working copy) @@ -991,8 +991,12 @@ /* Must have an "at" for acpi or isa. */ resource_string_value(name, unit, "at", &s); if (!(strcmp(s, "acpi0") =3D=3D 0 || strcmp(s, "acpi") =3D=3D 0 || - strcmp(s, "isa0") =3D=3D 0 || strcmp(s, "isa") =3D=3D 0)) + strcmp(s, "isa0") =3D=3D 0 || strcmp(s, "isa") =3D=3D 0)) { + if (strstr(name, "atrtc")) { + printf("AT: %s\n", s); + } continue; + } =20 /* * Check for matching resources. We must have at least one, @@ -1003,24 +1007,36 @@ */ matches =3D 0; if (resource_long_value(name, unit, "port", &value) =3D=3D 0) { + if (strstr(name, "atrtc")) { + printf("PORT: %ld\n", value); + } if (acpi_match_resource_hint(child, SYS_RES_IOPORT, value)) matches++; else continue; } if (resource_long_value(name, unit, "maddr", &value) =3D=3D 0) { + if (strstr(name, "atrtc")) { + printf("MADDR: %ld\n", value); + } if (acpi_match_resource_hint(child, SYS_RES_MEMORY, value)) matches++; else continue; } if (resource_long_value(name, unit, "irq", &value) =3D=3D 0) { + if (strstr(name, "atrtc")) { + printf("IRQ: %ld\n", value); + } if (acpi_match_resource_hint(child, SYS_RES_IRQ, value)) matches++; else continue; } if (resource_long_value(name, unit, "drq", &value) =3D=3D 0) { + if (strstr(name, "atrtc")) { + printf("DRQ: %ld\n", value); + } if (acpi_match_resource_hint(child, SYS_RES_DRQ, value)) matches++; else --zYM0uCDKw75PZbzx Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="dmesg.jhb" Copyright (c) 1992-2008 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-CURRENT #22: Thu Dec 11 23:11:40 CET 2008 root@witten:/root/freebsd/sys/i386/compile/NEOLOGISM Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 4200+ (2204.61-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x40fb2 Stepping = 2 Features=0x178bfbff Features2=0x2001 AMD Features=0xea500800 AMD Features2=0x1f Cores per package: 2 real memory = 1039007744 (990 MB) avail memory = 1003794432 (957 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0: Changing APIC ID to 2 ioapic0 irqs 0-23 on motherboard acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) PORT: 112 PORT: 112 PORT: 112 PORT: 112 acpi0: reservation of 3dee0000, 20000 (3) failed acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, 3dde0000 (3) failed Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x4008-0x400b on acpi0 acpi_hpet0: iomem 0xfefff000-0xfefff3ff on acpi0 Timecounter "HPET" frequency 25000000 Hz quality 900 PORT: 112 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 pcib3: at device 4.0 on pci0 pci3: on pcib3 vgapci0: mem 0xfc000000-0xfcffffff,0xd0000000-0xdfffffff,0xfb000000-0xfbffffff irq 16 at device 5.0 on pci0 nvidia0: on vgapci0 vgapci0: child nvidia0 requested pci_enable_busmaster vgapci0: child nvidia0 requested pci_enable_io nvidia0: [GIANT-LOCKED] nvidia0: [ITHREAD] pci0: at device 9.0 (no driver attached) isab0: 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) pci0: at device 11.0 (no driver attached) pci0: at device 11.1 (no driver attached) atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xf400-0xf40f at device 13.0 on pci0 ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] atapci1: port 0x9f0-0x9f7,0xbf0-0xbf3,0x970-0x977,0xb70-0xb73,0xe000-0xe00f mem 0xfe02d000-0xfe02dfff irq 20 at device 14.0 on pci0 atapci1: [ITHREAD] ata2: on atapci1 ata2: [ITHREAD] ata3: on atapci1 ata3: [ITHREAD] atapci2: port 0x9e0-0x9e7,0xbe0-0xbe3,0x960-0x967,0xb60-0xb63,0xcc00-0xcc0f mem 0xfe02c000-0xfe02cfff irq 21 at device 15.0 on pci0 atapci2: [ITHREAD] ata4: on atapci2 ata4: [ITHREAD] ata5: on atapci2 ata5: [ITHREAD] pcib4: at device 16.0 on pci0 pci4: on pcib4 hdac0: mem 0xfe024000-0xfe027fff irq 22 at device 16.1 on pci0 hdac0: HDA Driver Revision: 20081123_0118 hdac0: [ITHREAD] nfe0: port 0xc800-0xc807 mem 0xfe02b000-0xfe02bfff irq 23 at device 20.0 on pci0 miibus0: on nfe0 e1000phy0: PHY 1 on miibus0 e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX-FDX, auto nfe0: Ethernet address: 00:1b:fc:63:69:d7 nfe0: [FILTER] PORT: 112 PORT: 112 acpi_tz0: on acpi0 PORT: 112 PORT: 112 PORT: 112 PORT: 112 PORT: 112 PORT: 112 PORT: 112 PORT: 112 PORT: 112 PORT: 112 PORT: 112 PORT: 112 PORT: 112 PORT: 112 PORT: 112 PORT: 112 PORT: 112 PORT: 112 PORT: 112 PORT: 112 IRQ: 8 PORT: 112 IRQ: 8 atrtc1: port 0x70-0x73 on acpi0 PORT: 112 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model IntelliMouse, device ID 3 PORT: 112 PORT: 112 PORT: 112 PORT: 112 PORT: 112 PORT: 112 PORT: 112 PORT: 112 cpu0: on acpi0 powernow0: on cpu0 cpu1: on acpi0 powernow1: on cpu1 PORT: 112 PORT: 112 PORT: 112 PORT: 112 PORT: 112 PORT: 112 PORT: 112 PORT: 112 PORT: 112 PORT: 112 PORT: 112 PORT: 112 PORT: 112 PORT: 112 PORT: 112 PORT: 112 PORT: 112 PORT: 112 PORT: 112 PORT: 112 PORT: 112 PORT: 112 PORT: 112 PORT: 112 PORT: 112 PORT: 112 PORT: 112 PORT: 112 PORT: 112 PORT: 112 pmtimer0 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 atrtc0: at port 0x70 irq 8 on isa0 atrtc0: Warning: Couldn't map I/O. atrtc0: Warning: Couldn't map Interrupt. Timecounters tick every 1.000 msec ad0: 152627MB at ata0-master UDMA100 acd0: DVDROM at ata1-slave UDMA33 hdac0: HDA Codec #0: Analog Devices AD1986A hdac0: hdac_widget_connection_parse: nid=18 WARNING: zero cnid entnum=4 j=2 index=0 entries=8 found=2 res=0x21002211 pcm0: at cad 0 nid 1 on hdac0 pcm1: at cad 0 nid 1 on hdac0 pcm2: at cad 0 nid 1 on hdac0 SMP: AP CPU #1 Launched! Trying to mount root from ufs:/dev/ad0s1a --zYM0uCDKw75PZbzx-- --p4qYPpj5QlsIQJ0K Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAklBkTwACgkQLVEj6D3CBEzzDACfSszftSOvl0nLA8+53YFPNsT+ NrQAn3+HdcLnSDiTJAm6NUrj8Wd5GvFg =zUUg -----END PGP SIGNATURE----- --p4qYPpj5QlsIQJ0K-- From owner-freebsd-current@FreeBSD.ORG Thu Dec 11 22:30:29 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 55D121065670 for ; Thu, 11 Dec 2008 22:30:29 +0000 (UTC) (envelope-from cryx-freebsd@h3q.com) Received: from mail.h3q.com (mail.h3q.com [213.73.89.199]) by mx1.freebsd.org (Postfix) with ESMTP id 95F048FC0C for ; Thu, 11 Dec 2008 22:30:28 +0000 (UTC) (envelope-from cryx-freebsd@h3q.com) Received: (qmail 99607 invoked from network); 11 Dec 2008 22:30:27 -0000 Received: from unknown (HELO goa.local) (smtpsend@85.179.28.10) by mail.h3q.com with AES256-SHA encrypted SMTP; 11 Dec 2008 22:30:27 -0000 Message-ID: <49419482.2040502@h3q.com> Date: Thu, 11 Dec 2008 23:30:26 +0100 From: Philipp Wuensche User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105) MIME-Version: 1.0 To: freebsd-jail@freebsd.org References: <20081201085229.D80401@maildrop.int.zabbadoz.net> <20081201122937.81475f0zhfsjya4o@webmail.leidinger.net> <6ae50c2d0812021800x791d2cfeh45d590de120f76df@mail.gmail.com> <1228483574.2805.499.camel@soundwave.ws.pitbpa0.priv.collaborativefusion.com> <86skp2l804.fsf@ds4.des.no> <1228507529.2805.539.camel@soundwave.ws.pitbpa0.priv.collaborativefusion.com> <49418BD9.8080105@h3q.com> <20081211221113.S97918@maildrop.int.zabbadoz.net> In-Reply-To: <20081211221113.S97918@maildrop.int.zabbadoz.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: freebsd-current@freebsd.org, bseklecki@collaborativefusion.com Subject: Re: HEADS UP: r185435 multi-IPv4/v6/no-IP jails in HEAD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Dec 2008 22:30:29 -0000 Bjoern A. Zeeb wrote: > On Thu, 11 Dec 2008, Philipp Wuensche wrote: > > Hi, > >> Brian A. Seklecki wrote: >>> On Fri, 2008-12-05 at 20:47 +0100, Dag-Erling Smrgrav wrote: >>>> The question is, does it change existing behavior, or just add new >>>> functionality? >>> >>> The syntax semantics should be backward compatible, so likely the >>> latter. >> >> Not entirely true, the jls output is totaly different than before and >> breaks third-party applications like jailaudit and ezjail. > > This is only true if you use any of the new features. In case you use > single-IPv4 jails as before there should be absoultely no change in the > output format. Why do I get the new jls output then when I only use one ipaddr. for a jail and none of the new features at all? > PS: I trimmed the CC: list as noone was able to adhere to Reply-To. freebsd-current should be in the CC as the discussion is if it is MFCd and let loose to 7.2R greetings, Philipp From owner-freebsd-current@FreeBSD.ORG Thu Dec 11 22:32:54 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4C78A1065676; Thu, 11 Dec 2008 22:32:54 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id 0497A8FC18; Thu, 11 Dec 2008 22:32:53 +0000 (UTC) (envelope-from des@des.no) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id D1D2E6D43F; Thu, 11 Dec 2008 22:32:52 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id ADCA7844C0; Thu, 11 Dec 2008 23:32:52 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Philipp Wuensche References: <20081201085229.D80401@maildrop.int.zabbadoz.net> <20081201122937.81475f0zhfsjya4o@webmail.leidinger.net> <6ae50c2d0812021800x791d2cfeh45d590de120f76df@mail.gmail.com> <1228483574.2805.499.camel@soundwave.ws.pitbpa0.priv.collaborativefusion.com> <86skp2l804.fsf@ds4.des.no> <1228507529.2805.539.camel@soundwave.ws.pitbpa0.priv.collaborativefusion.com> <49418BD9.8080105@h3q.com> Date: Thu, 11 Dec 2008 23:32:52 +0100 In-Reply-To: <49418BD9.8080105@h3q.com> (Philipp Wuensche's message of "Thu, 11 Dec 2008 22:53:29 +0100") Message-ID: <867i66s5pn.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD virtualization mailing list , alexus , freebsd-current@freebsd.org, Alexander Leidinger , "Bjoern A. Zeeb" , freebsd-jail@freebsd.org, bseklecki@collaborativefusion.com Subject: Re: HEADS UP: r185435 multi-IPv4/v6/no-IP jails in HEAD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Dec 2008 22:32:54 -0000 Philipp Wuensche writes: > Not entirely true, the jls output is totaly different than before and > breaks third-party applications like jailaudit and ezjail. > > It is uneasy to parse too. jls | tail +3 | while read line ; do set $line if [ $# =3D 3 ] ; then echo "jail $1 (name $2 root $3) IPs:" elif [ $# =3D 1 ] ; then echo " $1" else echo "huh?" fi done DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Thu Dec 11 22:50:07 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3D23C1065675; Thu, 11 Dec 2008 22:50:07 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [62.111.66.27]) by mx1.freebsd.org (Postfix) with ESMTP id E51E68FC1F; Thu, 11 Dec 2008 22:50:06 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from localhost (amavis.str.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id F2D8E41C6DB; Thu, 11 Dec 2008 23:50:05 +0100 (CET) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([62.111.66.27]) by localhost (amavis.str.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id EI8oZSwdLL14; Thu, 11 Dec 2008 23:50:05 +0100 (CET) Received: by mail.cksoft.de (Postfix, from userid 66) id ABCE941C6BB; Thu, 11 Dec 2008 23:50:05 +0100 (CET) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 29ACD4448DD; Thu, 11 Dec 2008 22:48:54 +0000 (UTC) Date: Thu, 11 Dec 2008 22:48:53 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Philipp Wuensche In-Reply-To: <49419482.2040502@h3q.com> Message-ID: <20081211224737.B97918@maildrop.int.zabbadoz.net> References: <20081201085229.D80401@maildrop.int.zabbadoz.net> <20081201122937.81475f0zhfsjya4o@webmail.leidinger.net> <6ae50c2d0812021800x791d2cfeh45d590de120f76df@mail.gmail.com> <1228483574.2805.499.camel@soundwave.ws.pitbpa0.priv.collaborativefusion.com> <86skp2l804.fsf@ds4.des.no> <1228507529.2805.539.camel@soundwave.ws.pitbpa0.priv.collaborativefusion.com> <49418BD9.8080105@h3q.com> <20081211221113.S97918@maildrop.int.zabbadoz.net> <49419482.2040502@h3q.com> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-jail@freebsd.org, freebsd-current@freebsd.org Subject: Re: HEADS UP: r185435 multi-IPv4/v6/no-IP jails in HEAD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Dec 2008 22:50:07 -0000 On Thu, 11 Dec 2008, Philipp Wuensche wrote: Hi, >>> Not entirely true, the jls output is totaly different than before and >>> breaks third-party applications like jailaudit and ezjail. >> >> This is only true if you use any of the new features. In case you use >> single-IPv4 jails as before there should be absoultely no change in the >> output format. > > Why do I get the new jls output then when I only use one ipaddr. for a > jail and none of the new features at all? What are you using? The version from HEAD or are you running a patch on either HEAD or 7 and if so from when? /bz -- Bjoern A. Zeeb The greatest risk is not taking one. From owner-freebsd-current@FreeBSD.ORG Thu Dec 11 22:52:31 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A4E361065677 for ; Thu, 11 Dec 2008 22:52:31 +0000 (UTC) (envelope-from cryx-freebsd@h3q.com) Received: from mail.h3q.com (mail.h3q.com [213.73.89.199]) by mx1.freebsd.org (Postfix) with ESMTP id DE1C28FC14 for ; Thu, 11 Dec 2008 22:52:30 +0000 (UTC) (envelope-from cryx-freebsd@h3q.com) Received: (qmail 5962 invoked from network); 11 Dec 2008 22:52:29 -0000 Received: from unknown (HELO goa.local) (smtpsend@85.179.28.10) by mail.h3q.com with AES256-SHA encrypted SMTP; 11 Dec 2008 22:52:29 -0000 Message-ID: <494199AD.2060404@h3q.com> Date: Thu, 11 Dec 2008 23:52:29 +0100 From: Philipp Wuensche User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105) MIME-Version: 1.0 To: "Bjoern A. Zeeb" References: <20081201085229.D80401@maildrop.int.zabbadoz.net> <20081201122937.81475f0zhfsjya4o@webmail.leidinger.net> <6ae50c2d0812021800x791d2cfeh45d590de120f76df@mail.gmail.com> <1228483574.2805.499.camel@soundwave.ws.pitbpa0.priv.collaborativefusion.com> <86skp2l804.fsf@ds4.des.no> <1228507529.2805.539.camel@soundwave.ws.pitbpa0.priv.collaborativefusion.com> <49418BD9.8080105@h3q.com> <20081211221113.S97918@maildrop.int.zabbadoz.net> <49419482.2040502@h3q.com> <20081211224737.B97918@maildrop.int.zabbadoz.net> In-Reply-To: <20081211224737.B97918@maildrop.int.zabbadoz.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-jail@freebsd.org, freebsd-current@freebsd.org Subject: Re: HEADS UP: r185435 multi-IPv4/v6/no-IP jails in HEAD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Dec 2008 22:52:31 -0000 Bjoern A. Zeeb wrote: > On Thu, 11 Dec 2008, Philipp Wuensche wrote: > > Hi, > >>>> Not entirely true, the jls output is totaly different than before and >>>> breaks third-party applications like jailaudit and ezjail. >>> >>> This is only true if you use any of the new features. In case you use >>> single-IPv4 jails as before there should be absoultely no change in the >>> output format. >> >> Why do I get the new jls output then when I only use one ipaddr. for a >> jail and none of the new features at all? > > What are you using? The version from HEAD or are you running a patch > on either HEAD or 7 and if so from when? The version from HEAD without any patches. * $FreeBSD: src/usr.sbin/jls/jls.c,v 1.7 2008/12/11 01:04:25 bz Exp $ greetings, philipp From owner-freebsd-current@FreeBSD.ORG Thu Dec 11 22:53:50 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 36BF71065675; Thu, 11 Dec 2008 22:53:50 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (adsl-63-193-123-122.dsl.snfc21.pacbell.net [63.193.123.122]) by mx1.freebsd.org (Postfix) with ESMTP id C9EB68FC24; Thu, 11 Dec 2008 22:53:49 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.3/8.14.3) with ESMTP id mBBMrnth005935; Thu, 11 Dec 2008 14:53:49 -0800 (PST) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.3/8.14.3/Submit) id mBBMrn8J005934; Thu, 11 Dec 2008 14:53:49 -0800 (PST) (envelope-from david) Date: Thu, 11 Dec 2008 14:53:49 -0800 From: David Wolfskill To: Kostik Belousov Message-ID: <20081211225349.GB5597@albert.catwhisker.org> Mail-Followup-To: David Wolfskill , Kostik Belousov , hackers@freebsd.org, current@freebsd.org References: <20081203001538.GC96383@bunrab.catwhisker.org> <20081209190110.GW60731@albert.catwhisker.org> <20081210165022.GJ60731@albert.catwhisker.org> <20081210170620.GS2038@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="O5XBE6gyVG5Rl6Rj" Content-Disposition: inline In-Reply-To: <20081210170620.GS2038@deviant.kiev.zoral.com.ua> User-Agent: Mutt/1.4.2.3i Cc: hackers@freebsd.org, current@freebsd.org Subject: Re: NFS (& amd?) dysfunction descending a hierarchy X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Dec 2008 22:53:50 -0000 --O5XBE6gyVG5Rl6Rj Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Dec 10, 2008 at 07:06:20PM +0200, Kostik Belousov wrote: > ... > > What concerns me is that even if the attempted unmount gets EBUSY, the > > user-level process descending the directory hierarchy is getting ENOENT > > trying to issue fstatfs() against an open file descriptor. > >=20 > > I'm having trouble figuring out any way that makes any sense. >=20 > Basically, the problem is that NFS uses shared lookup, and this allows > for the bug where several negative namecache entries are created for > non-existent node. Then this node gets created, removing only the first > negative namecache entry. For some reasons, vnode is reclaimed; amd' > tasting of unmount is a good reason for vnode to be reclaimed. >=20 > Now, you have existing path and a negative cache entry. This was > reported by Peter Holm first, I listed relevant revisions that > should fix this in previous mail. Well, I messed up the machine I had been using for testing, and needed to wait for IT to do something to it since I don't have physical or console access to it. So after I happened to demonstrate the effect using my desktop -- which had been running RELENG_7_1, sources updated as of around 0400 hrs. US/Pacific -- I decided to go ahead and update the desktop to RELENG_7_1 as of this morning (which had the commit to sys/kern/vfs_cache.c), then test. It still failed, apparently in the same way; details below. First, here's a list of the files that were changed: U lib/libarchive/archive_read_support_format_iso9660.c U lib/libarchive/archive_string.c U lib/libarchive/archive_string.h U lib/libc/gen/times.3 U lib/libc/i386/sys/pipe.S U lib/libc/i386/sys/reboot.S U lib/libc/i386/sys/setlogin.S U lib/libutil/Makefile U lib/libutil/kinfo_getfile.c U lib/libutil/kinfo_getvmmap.c U lib/libutil/libutil.h U share/man/man4/bce.4 U share/man/man5/Makefile U share/man/man5/fstab.5 U share/man/man5/nullfs.5 U sys/amd64/Makefile U sys/boot/forth/loader.conf.5 U sys/dev/ale/if_ale.c U sys/dev/bce/if_bce.c U sys/dev/cxgb/cxgb_main.c U sys/dev/cxgb/common/cxgb_ael1002.c U sys/dev/cxgb/common/cxgb_t3_hw.c U sys/dev/cxgb/common/cxgb_xgmac.c U sys/dev/re/if_re.c U sys/fs/nullfs/null_vnops.c U sys/kern/Make.tags.inc U sys/kern/kern_descrip.c U sys/kern/kern_proc.c U sys/kern/vfs_cache.c U sys/netinet/in_pcb.h U sys/pci/if_rlreg.h U sys/sys/sysctl.h U sys/sys/user.h U sys/ufs/ufs/ufs_quota.c U usr.bin/procstat/Makefile U usr.bin/procstat/procstat_files.c U usr.bin/procstat/procstat_vm.c U usr.bin/tar/util.c U usr.bin/tar/test/Makefile U usr.bin/tar/test/test_strip_components.c U usr.bin/tar/test/test_symlink_dir.c U usr.bin/xargs/xargs.1 U usr.sbin/mtree/mtree.c We see that sys/kern/vfs_cache.c is, indeed, among them. And: dwolf-bsd(7.1-P)[5] grep '\$FreeBSD' /sys/kern/vfs_cache.c __FBSDID("$FreeBSD: src/sys/kern/vfs_cache.c,v 1.114.2.3 2008/12/09 16:20:5= 8 kib Exp $"); dwolf-bsd(7.1-P)[6]=20 That should correspond to the desired version of the file. Here we see an excerpt from the ktrace output for the amd(8) process and its children; this is a point when amd(8) is trying an unmount() to see if it can get away with it: 977 amd 1229033597.269612 CALL gettimeofday(0x807ad48,0) 977 amd 1229033597.269620 RET gettimeofday 0 977 amd 1229033597.269630 CALL sigprocmask(SIG_BLOCK,0xbfbfeaec,0x= bfbfeadc) 977 amd 1229033597.269637 RET sigprocmask 0 977 amd 1229033597.269645 CALL fork 977 amd 1229033597.273810 RET fork 1712/0x6b0 1712 amd 1229033597.273811 RET fork 0 977 amd 1229033597.273836 CALL sigprocmask(SIG_SETMASK,0xbfbfeadc,= 0) 1712 amd 1229033597.273845 CALL getpid 977 amd 1229033597.273850 RET sigprocmask 0 1712 amd 1229033597.273855 RET getpid 1712/0x6b0 977 amd 1229033597.273864 CALL gettimeofday(0x807ad48,0) 977 amd 1229033597.273874 RET gettimeofday 0 1712 amd 1229033597.273878 CALL unmount(0x2832c610,0) =2E.. 1712 amd 1229033597.352643 RET unmount -1 errno 16 Device busy 1712 amd 1229033597.352695 CALL sigprocmask(SIG_BLOCK,0x28097c00,0x= bfbfea0c) 1712 amd 1229033597.352728 RET sigprocmask 0 1712 amd 1229033597.352751 CALL sigprocmask(SIG_SETMASK,0x28097c10,= 0) 1712 amd 1229033597.352769 RET sigprocmask 0 1712 amd 1229033597.352781 CALL sigprocmask(SIG_BLOCK,0x28097c00,0x= bfbfe9dc) 1712 amd 1229033597.352790 RET sigprocmask 0 1712 amd 1229033597.352801 CALL sigprocmask(SIG_SETMASK,0x28097c10,= 0) 1712 amd 1229033597.352805 RET sigprocmask 0 1712 amd 1229033597.352815 CALL exit(0x10) 977 amd 1229033597.353085 RET select -1 errno 4 Interrupted syste= m call 977 amd 1229033597.353093 PSIG SIGCHLD caught handler=3D0x805de50 = mask=3D0x0 code=3D0x0 977 amd 1229033597.353103 CALL wait4(0xffffffff,0xbfbfe83c,WNOHANG= ,0) 977 amd 1229033597.353116 RET wait4 1712/0x6b0 977 amd 1229033597.353122 CALL wait4(0xffffffff,0xbfbfe83c,WNOHANG= ,0) 977 amd 1229033597.353127 RET wait4 -1 errno 10 No child processes So amd(8) master process (pid 977) jorks off a child (pid 1712) to try an umount(), which it initiates at 1229033597.273878. At 1229033597.352643 the child gets control back, as well as an EBUSY, which I would expect to mean that the attempt failed. The child exits at 1229033597.352815 with a status code of 16. Armed with that, we look at a ktrace excerpt from "rm -fr": 1660 rm 1229033597.283277 CALL rmdir(0x2822b388) 1660 rm 1229033597.283283 NAMI "stvef-paks" 1660 rm 1229033597.285599 RET rmdir 0 1660 rm 1229033597.285620 CALL stat(0x2822b3e8,0xbfbfe8dc) 1660 rm 1229033597.285626 NAMI "stvef-server" 1660 rm 1229033597.286071 STRU struct stat {dev=3D83951372, ino=3D= 20124614, mode=3Ddrwxr-xr-x , nlink=3D3, uid=3D9874, gid=3D929, rdev=3D0, a= time=3D1228844788, stime=3D1227555769, ctime=3D1228845828.326650000, birtht= ime=3D0, size=3D4096, blksize=3D4096, blocks=3D8, flags=3D0x0 } 1660 rm 1229033597.286078 RET stat 0 1660 rm 1229033597.286084 CALL open(0x2822b3e8,O_NONBLOCK,= 0x1) 1660 rm 1229033597.286091 NAMI "stvef-server" 1660 rm 1229033597.287145 RET open 4 1660 rm 1229033597.287154 CALL fstat(0x4,0xbfbfe8dc) 1660 rm 1229033597.287161 STRU struct stat {dev=3D83951372, ino=3D= 20124614, mode=3Ddrwxr-xr-x , nlink=3D3, uid=3D9874, gid=3D929, rdev=3D0, a= time=3D1228844788, stime=3D1227555769, ctime=3D1228845828.326650000, birtht= ime=3D0, size=3D4096, blksize=3D4096, blocks=3D8, flags=3D0x0 } 1660 rm 1229033597.287166 RET fstat 0 1660 rm 1229033597.287171 CALL fcntl(0x4,F_SETFD,FD_CLOEXEC) 1660 rm 1229033597.287177 RET fcntl 0 1660 rm 1229033597.287187 CALL fstatfs(0x4,0xbfbfe704) 1660 rm 1229033597.287195 RET fstatfs -1 errno 2 No such file or = directory 1660 rm 1229033597.287202 CALL close(0x4) 1660 rm 1229033597.287211 RET close 0 [Sorry for the long lines....] Here we see that the "rm" process (pid 1660) removed a directory named stvef-paks sucessfully in the interval between 1229033597.283277 (when the request was made) and 1229033597.285599 (when the 0 return occurred). The "rm" process proceeds to process a directory named stvef-server: * At 1229033597.285620 it issues a stat(); the successful return is at 1229033597.286078. * At 1229033597.286084 it issues an open(); the successful return is at 1229033597.287145. The FD is 4. * At 1229033597.287154 it issues an fstat() against FD 4; the successful return is at 1229033597.287166. * At 1229033597.287171 it issues an fcntl() against FD 4; the successful return is at 1229033597.287177. * At 1229033597.287187 it issues an fstatfs() against FD 4; the unsuccessful return is at 1229033597.287195, claiming ENOENT. Say WHAT??!? I expect to be able to test a bit more promptly now. Peace, david --=20 David H. Wolfskill david@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --O5XBE6gyVG5Rl6Rj Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAklBmfwACgkQmprOCmdXAD1AEgCfdbAL8t/OB2S5QMtS2Yybo7rQ kqwAniaONokHwedGnl6LnGMCEfZjbwFc =8hTW -----END PGP SIGNATURE----- --O5XBE6gyVG5Rl6Rj-- From owner-freebsd-current@FreeBSD.ORG Thu Dec 11 23:20:08 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 010131065688; Thu, 11 Dec 2008 23:20:08 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [62.111.66.27]) by mx1.freebsd.org (Postfix) with ESMTP id A820F8FC19; Thu, 11 Dec 2008 23:20:07 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from localhost (amavis.str.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id AC93841C749; Fri, 12 Dec 2008 00:20:05 +0100 (CET) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([62.111.66.27]) by localhost (amavis.str.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id dsVzb+S87Qc8; Fri, 12 Dec 2008 00:20:05 +0100 (CET) Received: by mail.cksoft.de (Postfix, from userid 66) id 61C6B41C736; Fri, 12 Dec 2008 00:20:05 +0100 (CET) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id DAEC94448DD; Thu, 11 Dec 2008 23:16:16 +0000 (UTC) Date: Thu, 11 Dec 2008 23:16:16 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Philipp Wuensche In-Reply-To: <494199AD.2060404@h3q.com> Message-ID: <20081211231422.T97918@maildrop.int.zabbadoz.net> References: <20081201085229.D80401@maildrop.int.zabbadoz.net> <20081201122937.81475f0zhfsjya4o@webmail.leidinger.net> <6ae50c2d0812021800x791d2cfeh45d590de120f76df@mail.gmail.com> <1228483574.2805.499.camel@soundwave.ws.pitbpa0.priv.collaborativefusion.com> <86skp2l804.fsf@ds4.des.no> <1228507529.2805.539.camel@soundwave.ws.pitbpa0.priv.collaborativefusion.com> <49418BD9.8080105@h3q.com> <20081211221113.S97918@maildrop.int.zabbadoz.net> <49419482.2040502@h3q.com> <20081211224737.B97918@maildrop.int.zabbadoz.net> <494199AD.2060404@h3q.com> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-jail@freebsd.org, freebsd-current@freebsd.org Subject: Re: HEADS UP: r185435 multi-IPv4/v6/no-IP jails in HEAD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Dec 2008 23:20:08 -0000 On Thu, 11 Dec 2008, Philipp Wuensche wrote: Hi, ok, after another round of private mails I got it; I had been living with jail patches for too long; the jls output (without -v) should be on one line and not on two. That wasn't intended. Unfortunately noone had complained the months before.. I'll look at this. /bz -- Bjoern A. Zeeb The greatest risk is not taking one. From owner-freebsd-current@FreeBSD.ORG Fri Dec 12 02:05:49 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5485C1065691 for ; Fri, 12 Dec 2008 02:05:49 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.229]) by mx1.freebsd.org (Postfix) with ESMTP id 122898FC2A for ; Fri, 12 Dec 2008 02:05:49 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so1146860rvf.43 for ; Thu, 11 Dec 2008 18:05:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:received:date:from :to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=VGHNQt/wN7pdqIbmEPrjFxy7A1vfa2y4pzp3bVqh+Mk=; b=jtQ2HApU/aha81+STV2/9ay65s11vFTkYSr3xGvHl6WPkaGHrWZOUXyi+gCXmW6W1v q1IkoATm8rbNPCtdpeQWnt0UY3MDRteZ/0lBUSVR/AsVhu/n5kMH+9lnrkR3zq/jGdnM NoiCMEEK8dbbjTJQs8mmgMPtGmvpRvlQSvfiY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=nhEvfd2sbUB3F4Zp37TgKERdrajtwm8/LOnuP8KzMU2LxbxFKstOglnqUuyhaKhJcv aPDRFHSEdRg/eyqLvXV+U3Ga7/W0Jcye/VdWtkRUjo1qnTmKc8Qo497mRV7bw6ZNJMNc ctXysEf+HeDc4dZFxyIfCASjl97FqO7Ovpw5g= Received: by 10.140.201.8 with SMTP id y8mr1626819rvf.101.1229047548804; Thu, 11 Dec 2008 18:05:48 -0800 (PST) Received: from michelle.cdnetworks.co.kr ([211.53.35.84]) by mx.google.com with ESMTPS id k2sm3438822rvb.8.2008.12.11.18.05.44 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 11 Dec 2008 18:05:45 -0800 (PST) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id mBC25d4f047299 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 12 Dec 2008 11:05:39 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id mBC25dmg047298; Fri, 12 Dec 2008 11:05:39 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Fri, 12 Dec 2008 11:05:39 +0900 From: Pyun YongHyeon To: Josh Carroll Message-ID: <20081212020539.GI46707@cdnetworks.co.kr> References: <490F47BE.9080205@janh.de> <20081104015235.GC98154@cdnetworks.co.kr> <4910C055.8000505@janh.de> <20081105013558.GA99795@cdnetworks.co.kr> <20081203090658.GJ9639@cdnetworks.co.kr> <37502393@bb.ipt.ru> <20081206023016.GF22093@cdnetworks.co.kr> <539c60b90812081127s4ffb509fnea9d44d4298da666@mail.gmail.com> <8cb6106e0812081252j2b0c8e78g4dcecf8d3770c269@mail.gmail.com> <8cb6106e0812101745l54b23a08k7fbeddeb605f88ea@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8cb6106e0812101745l54b23a08k7fbeddeb605f88ea@mail.gmail.com> User-Agent: Mutt/1.4.2.1i Cc: Steve Franks , current-list freebsd Subject: Re: Call for testers: Atheros AR8121(L1E)/AR8113/AR8114(L2E) ethernet X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Dec 2008 02:05:49 -0000 On Wed, Dec 10, 2008 at 08:45:56PM -0500, Josh Carroll wrote: > > ale0@pci0:2:0:0: class=0x020000 card=0x82261043 chip=0x10261969 > > rev=0xb0 hdr=0x00 > > vendor = 'Attansic (Now owned by Atheros)' > > class = network > > subclass = ethernet > > > > iperf (ale0 as -s): [ 3] 0.0-10.0 sec 1.10 GBytes 941 Mbits/sec > > iperf (ale0 as -c): [ 3] 0.0-10.0 sec 1.08 GBytes 931 Mbits/sec > > > > So all seems well here. > > Well, I spoke too soon. Overall gigE throughput wise and day to day > activities (NAT'd 20 Mbit FiOS) were fine. > > Tonight, however, I went to watch a 720p video (~4 Mbps bitrate or > less) on my Popcorn Hour over NFS which has worked fine in the past. > It was extremely "jerky" and unwatchable. Figuring perhaps the Popcorn > Hour had an issue, I fired up an NFS server on another box and the > video streamed just fine. I then rebooted this box and threw in a > trusty old PCI em(4) card, and all is well. > > I tried playing with these two sysctl knobs for ale0: > > dev.ale.0.int_rx_mod > > and > > dev.ale.0.int_tx_mod > > I tried setting both to 0 and both to higher numbers on the documented > scale (10000 I believe), neither of which helped. I imagine since what > I want here is a "smoother" transmission, setting int_tx_mod to 0 is > what would have the most effect, but the video still was not playable > with it set to 0. > > I've since disabled the ale0 interface in the BIOS and I'm using the > em(4) for now. > > Is there another knob for ale I should try adjusting? > Would you show me the output of "sysctl dev.ale.0.stats"? -- Regards, Pyun YongHyeon From owner-freebsd-current@FreeBSD.ORG Fri Dec 12 02:47:23 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DEE751065673 for ; Fri, 12 Dec 2008 02:47:23 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.224]) by mx1.freebsd.org (Postfix) with ESMTP id A98898FC19 for ; Fri, 12 Dec 2008 02:47:23 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so1161313rvf.43 for ; Thu, 11 Dec 2008 18:47:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:received:date:from :to:subject:message-id:reply-to:mime-version:content-type :content-disposition:user-agent; bh=na+ZNiuHG8IkMx4TK8u2Xvnvsy+gxZ+F54euv/p04pM=; b=kGM4Sxmg6h5FoEvzndfDikIx89cPkVgEzNcHZF1SOlzGafTKVkYLVk/M9UviKSsJmw GViZGN9Ttz32f55wvoh5+bogtVSfHOFmlo9bAXkvpzL/UAMRRZLgXSFpNg1ITKk2Dqq5 SAr7q8WfFhI3hQd8ZbTfLD65zmRV1Cwf84Xjk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:subject:message-id:reply-to:mime-version:content-type :content-disposition:user-agent; b=XTayw6e7ESzxWI9qaI2HQ82TkMuG6sSlY4KDH5pCDxAbRalLdrr0IAnitjuRH5PDV0 0RA5oirjywHtZ1mfbvNREfYnKQsZTQ+BNwmgBOryOnkm0KGQIOYntthcZiFuuAMzKxBF /UTmB01+s9i1vCim+hrvLqv38RpHMV0baEWTc= Received: by 10.141.137.16 with SMTP id p16mr1633857rvn.180.1229050043362; Thu, 11 Dec 2008 18:47:23 -0800 (PST) Received: from michelle.cdnetworks.co.kr ([211.53.35.84]) by mx.google.com with ESMTPS id k2sm3533934rvb.8.2008.12.11.18.47.21 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 11 Dec 2008 18:47:22 -0800 (PST) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id mBC2lE4p047435 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 12 Dec 2008 11:47:14 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id mBC2lEEP047434 for freebsd-current@FreeBSD.org; Fri, 12 Dec 2008 11:47:14 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Fri, 12 Dec 2008 11:47:13 +0900 From: Pyun YongHyeon To: freebsd-current@FreeBSD.org Message-ID: <20081212024713.GK46707@cdnetworks.co.kr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Cc: Subject: CFT: RTL8168C re(4) attach issue X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Dec 2008 02:47:24 -0000 Hi, There had been several reports that some revision of RTL8168C were not able to access PHY which in turn resulted in device attach failure. For instance re(4) used to show the following messages. re0: Chip rev. 0x3c000000 re0: MAC rev. 0x00200000 re0: PHY write failed re0: PHY write failed re0: MII without any phy! For users who suffered from these issues, please try re(4)/rl(4) at the following URL and let me know how it goes. http://people.freebsd.org/~yongari/re/if_re.c (copy it to /usr/usr/sys/dev/re/) http://people.freebsd.org/~yongari/re/if_rlreg.h (copy it /usr/src/sys/pci/) http://people.freebsd.org/~yongari/re/if_rl.c (copy it /usr/src/sys/pci/) And rebuild re(4) and rl(4). Since the issue is not always happen testers should do power recycle several times to verify the issue. Thanks. -- Regards, Pyun YongHyeon From owner-freebsd-current@FreeBSD.ORG Fri Dec 12 03:23:51 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 450251065676 for ; Fri, 12 Dec 2008 03:23:51 +0000 (UTC) (envelope-from josh.carroll@gmail.com) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.29]) by mx1.freebsd.org (Postfix) with ESMTP id EDEDF8FC17 for ; Fri, 12 Dec 2008 03:23:50 +0000 (UTC) (envelope-from josh.carroll@gmail.com) Received: by yx-out-2324.google.com with SMTP id 8so589970yxb.13 for ; Thu, 11 Dec 2008 19:23:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:reply-to :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=AVK1zmD+oA4f192URjjI1xVqpF26n/1T6/yJbxRELnY=; b=BBM25cd/zqsxMS6MvqzdaACuYKBn/CrOzM/aJN6IkaiRCzPuEbzENnVtfrBiNh5NQE dL8M3zmk7iGXnoRCJfnvy+36ydlKs9hCZKq9igsfoqBj4vxPktG+wJKBEN/+muaFHtua xp6xXYml7ht+fl9GoRhQaO064A2wYtxVZOnOo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:reply-to:to:subject:cc:in-reply-to :mime-version:content-type:content-transfer-encoding :content-disposition:references; b=Nvm1SIA3AfaC3xQem83m7exF4B3KJw2l2m3Ej805oS3XCGSDoVH8ejm4WyLHDIl5aO NJ73yCiKoI88jz0I7+x01FBa/gYZqZIclX85bDGPl7UEcxxGi1RCRjpRiILnVmlWhSle Iggb3rio6xhSjQYCftnPPFY/xvrpK6j233b6Y= Received: by 10.151.103.11 with SMTP id f11mr5462667ybm.203.1229052230377; Thu, 11 Dec 2008 19:23:50 -0800 (PST) Received: by 10.150.123.1 with HTTP; Thu, 11 Dec 2008 19:23:50 -0800 (PST) Message-ID: <8cb6106e0812111923l15f1f715g6f20f5925e1d471a@mail.gmail.com> Date: Thu, 11 Dec 2008 22:23:50 -0500 From: "Josh Carroll" To: pyunyh@gmail.com In-Reply-To: <20081212020539.GI46707@cdnetworks.co.kr> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <490F47BE.9080205@janh.de> <4910C055.8000505@janh.de> <20081105013558.GA99795@cdnetworks.co.kr> <20081203090658.GJ9639@cdnetworks.co.kr> <37502393@bb.ipt.ru> <20081206023016.GF22093@cdnetworks.co.kr> <539c60b90812081127s4ffb509fnea9d44d4298da666@mail.gmail.com> <8cb6106e0812081252j2b0c8e78g4dcecf8d3770c269@mail.gmail.com> <8cb6106e0812101745l54b23a08k7fbeddeb605f88ea@mail.gmail.com> <20081212020539.GI46707@cdnetworks.co.kr> Cc: Steve Franks , current-list freebsd Subject: Re: Call for testers: Atheros AR8121(L1E)/AR8113/AR8114(L2E) ethernet X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: josh.carroll@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Dec 2008 03:23:51 -0000 > Would you show me the output of "sysctl dev.ale.0.stats"? Here is the output shortly after a reboot, before I try to stream anything: dev.ale.0.stats.rx.good_frames: 1843 dev.ale.0.stats.rx.good_bcast_frames: 9 dev.ale.0.stats.rx.good_mcast_frames: 0 dev.ale.0.stats.rx.pause_frames: 0 dev.ale.0.stats.rx.control_frames: 0 dev.ale.0.stats.rx.crc_errs: 0 dev.ale.0.stats.rx.len_errs: 0 dev.ale.0.stats.rx.good_octets: 229803 dev.ale.0.stats.rx.good_bcast_octets: 1844 dev.ale.0.stats.rx.good_mcast_octets: 0 dev.ale.0.stats.rx.runts: 0 dev.ale.0.stats.rx.fragments: 0 dev.ale.0.stats.rx.frames_64: 351 dev.ale.0.stats.rx.frames_65_127: 1174 dev.ale.0.stats.rx.frames_128_255: 107 dev.ale.0.stats.rx.frames_256_511: 188 dev.ale.0.stats.rx.frames_512_1023: 13 dev.ale.0.stats.rx.frames_1024_1518: 24 dev.ale.0.stats.rx.frames_1519_max: 0 dev.ale.0.stats.rx.trunc_errs: 0 dev.ale.0.stats.rx.fifo_oflows: 0 dev.ale.0.stats.rx.rrs_errs: 0 dev.ale.0.stats.rx.align_errs: 0 dev.ale.0.stats.rx.filtered: 14 dev.ale.0.stats.tx.good_frames: 2109 dev.ale.0.stats.tx.good_bcast_frames: 27 dev.ale.0.stats.tx.good_mcast_frames: 0 dev.ale.0.stats.tx.pause_frames: 0 dev.ale.0.stats.tx.control_frames: 0 dev.ale.0.stats.tx.excess_defers: 0 dev.ale.0.stats.tx.defers: 0 dev.ale.0.stats.tx.good_octets: 1284006 dev.ale.0.stats.tx.good_bcast_octets: 0 dev.ale.0.stats.tx.good_mcast_octets: 0 dev.ale.0.stats.tx.frames_64: 157 dev.ale.0.stats.tx.frames_65_127: 677 dev.ale.0.stats.tx.frames_128_255: 300 dev.ale.0.stats.tx.frames_256_511: 122 dev.ale.0.stats.tx.frames_512_1023: 148 dev.ale.0.stats.tx.frames_1024_1518: 705 dev.ale.0.stats.tx.frames_1519_max: 0 dev.ale.0.stats.tx.single_colls: 0 dev.ale.0.stats.tx.multi_colls: 0 dev.ale.0.stats.tx.late_colls: 0 dev.ale.0.stats.tx.excess_colls: 0 dev.ale.0.stats.tx.abort: 0 dev.ale.0.stats.tx.underruns: 0 dev.ale.0.stats.tx.desc_underruns: 0 dev.ale.0.stats.tx.len_errs: 0 dev.ale.0.stats.tx.trunc_errs: 3040 And after trying to stream (I let it struggle along for about 30-40 seconds): dev.ale.0.stats.rx.good_frames: 4350 dev.ale.0.stats.rx.good_bcast_frames: 35 dev.ale.0.stats.rx.good_mcast_frames: 0 dev.ale.0.stats.rx.pause_frames: 3636 dev.ale.0.stats.rx.control_frames: 0 dev.ale.0.stats.rx.crc_errs: 0 dev.ale.0.stats.rx.len_errs: 0 dev.ale.0.stats.rx.good_octets: 660242 dev.ale.0.stats.rx.good_bcast_octets: 5634 dev.ale.0.stats.rx.good_mcast_octets: 0 dev.ale.0.stats.rx.runts: 0 dev.ale.0.stats.rx.fragments: 0 dev.ale.0.stats.rx.frames_64: 4007 dev.ale.0.stats.rx.frames_65_127: 1822 dev.ale.0.stats.rx.frames_128_255: 1818 dev.ale.0.stats.rx.frames_256_511: 259 dev.ale.0.stats.rx.frames_512_1023: 86 dev.ale.0.stats.rx.frames_1024_1518: 60 dev.ale.0.stats.rx.frames_1519_max: 0 dev.ale.0.stats.rx.trunc_errs: 0 dev.ale.0.stats.rx.fifo_oflows: 0 dev.ale.0.stats.rx.rrs_errs: 0 dev.ale.0.stats.rx.align_errs: 0 dev.ale.0.stats.rx.filtered: 66 dev.ale.0.stats.tx.good_frames: 19902 dev.ale.0.stats.tx.good_bcast_frames: 29 dev.ale.0.stats.tx.good_mcast_frames: 0 dev.ale.0.stats.tx.pause_frames: 0 dev.ale.0.stats.tx.control_frames: 0 dev.ale.0.stats.tx.excess_defers: 0 dev.ale.0.stats.tx.defers: 0 dev.ale.0.stats.tx.good_octets: 25559139 dev.ale.0.stats.tx.good_bcast_octets: 0 dev.ale.0.stats.tx.good_mcast_octets: 0 dev.ale.0.stats.tx.frames_64: 181 dev.ale.0.stats.tx.frames_65_127: 1107 dev.ale.0.stats.tx.frames_128_255: 434 dev.ale.0.stats.tx.frames_256_511: 1450 dev.ale.0.stats.tx.frames_512_1023: 356 dev.ale.0.stats.tx.frames_1024_1518: 16374 dev.ale.0.stats.tx.frames_1519_max: 0 dev.ale.0.stats.tx.single_colls: 0 dev.ale.0.stats.tx.multi_colls: 0 dev.ale.0.stats.tx.late_colls: 0 dev.ale.0.stats.tx.excess_colls: 0 dev.ale.0.stats.tx.abort: 0 dev.ale.0.stats.tx.underruns: 0 dev.ale.0.stats.tx.desc_underruns: 0 dev.ale.0.stats.tx.len_errs: 0 dev.ale.0.stats.tx.trunc_errs: 3370 Thanks, Josh From owner-freebsd-current@FreeBSD.ORG Fri Dec 12 03:40:50 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8F06C1065672 for ; Fri, 12 Dec 2008 03:40:50 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.234]) by mx1.freebsd.org (Postfix) with ESMTP id 5012E8FC1F for ; Fri, 12 Dec 2008 03:40:50 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so1179299rvf.43 for ; Thu, 11 Dec 2008 19:40:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:received:date:from :to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=wHPv22D/RwWqEndn7v1MYZsEXqHPKuk6c70JBDHXLNE=; b=IRBcGwQfaEqSqwDOemejhDCbizCQ9EEEV6wAlTzaWQMhF3hYbwXXyGS1gBS+rZ+rKb XOBa3xV75eZXv3yaq1w1zAUgtOgfDRbTFy/K4YNhBeVladFNzElMH4y0i/m/7ZIASiFg dRyNjLf+lIOMNJUpLZ4IQ9kAJUMmPorWHz5k0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=xVbAzmBSc49ne2AnFcXEQ0rL42z8cCyYlcY642pzAxn7tBWTYoneLLGqaPHP3L8G1y h/b+jM+an1bkBf0GBoWjPg0hqAnhEeRUXhXb/x+lhKqDMn170O6KfFfujlbFDhMupgPN IPFq9c/Aykg2kWy0BfMyTYD57FXtFZJMe7xiE= Received: by 10.141.88.3 with SMTP id q3mr1648444rvl.229.1229053249907; Thu, 11 Dec 2008 19:40:49 -0800 (PST) Received: from michelle.cdnetworks.co.kr ([211.53.35.84]) by mx.google.com with ESMTPS id k37sm17407294rvb.1.2008.12.11.19.40.47 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 11 Dec 2008 19:40:48 -0800 (PST) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id mBC3egap047572 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 12 Dec 2008 12:40:42 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id mBC3egsZ047571; Fri, 12 Dec 2008 12:40:42 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Fri, 12 Dec 2008 12:40:42 +0900 From: Pyun YongHyeon To: Josh Carroll Message-ID: <20081212034042.GL46707@cdnetworks.co.kr> References: <4910C055.8000505@janh.de> <20081105013558.GA99795@cdnetworks.co.kr> <20081203090658.GJ9639@cdnetworks.co.kr> <37502393@bb.ipt.ru> <20081206023016.GF22093@cdnetworks.co.kr> <539c60b90812081127s4ffb509fnea9d44d4298da666@mail.gmail.com> <8cb6106e0812081252j2b0c8e78g4dcecf8d3770c269@mail.gmail.com> <8cb6106e0812101745l54b23a08k7fbeddeb605f88ea@mail.gmail.com> <20081212020539.GI46707@cdnetworks.co.kr> <8cb6106e0812111923l15f1f715g6f20f5925e1d471a@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8cb6106e0812111923l15f1f715g6f20f5925e1d471a@mail.gmail.com> User-Agent: Mutt/1.4.2.1i Cc: Steve Franks , current-list freebsd Subject: Re: Call for testers: Atheros AR8121(L1E)/AR8113/AR8114(L2E) ethernet X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Dec 2008 03:40:50 -0000 On Thu, Dec 11, 2008 at 10:23:50PM -0500, Josh Carroll wrote: > > Would you show me the output of "sysctl dev.ale.0.stats"? > > Here is the output shortly after a reboot, before I try to stream anything: > > dev.ale.0.stats.rx.good_frames: 1843 > dev.ale.0.stats.rx.good_bcast_frames: 9 > dev.ale.0.stats.rx.good_mcast_frames: 0 > dev.ale.0.stats.rx.pause_frames: 0 > dev.ale.0.stats.rx.control_frames: 0 > dev.ale.0.stats.rx.crc_errs: 0 [...] > And after trying to stream (I let it struggle along for about 30-40 seconds): > > dev.ale.0.stats.rx.good_frames: 4350 > dev.ale.0.stats.rx.good_bcast_frames: 35 > dev.ale.0.stats.rx.good_mcast_frames: 0 > dev.ale.0.stats.rx.pause_frames: 3636 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > dev.ale.0.stats.rx.control_frames: 0 > dev.ale.0.stats.rx.crc_errs: 0 [...] I guess it's caused by flow-control frames. The flow-control feature is disabled in most drivers as mii(4) layer still lacks the feture. ale(4) has flow-control support code but it is in disabled state. When mii(4) is ready to handle flow-controls ale(4) may work better. em(4) does not rely on mii(4) layer so it implemented flow-controls in driver. You can check flow-control satus of em(4) with "sysctl dev.em.0.stats=1"(See XON/XOFF). -- Regards, Pyun YongHyeon From owner-freebsd-current@FreeBSD.ORG Fri Dec 12 03:51:25 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 893E81065670 for ; Fri, 12 Dec 2008 03:51:25 +0000 (UTC) (envelope-from josh.carroll@gmail.com) Received: from mail-gx0-f12.google.com (mail-gx0-f12.google.com [209.85.217.12]) by mx1.freebsd.org (Postfix) with ESMTP id 26ADB8FC17 for ; Fri, 12 Dec 2008 03:51:25 +0000 (UTC) (envelope-from josh.carroll@gmail.com) Received: by gxk5 with SMTP id 5so780628gxk.19 for ; Thu, 11 Dec 2008 19:51:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:reply-to :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=ssCiL2ADC5FKuQI0NOP16QOvJ2/qdIMd0UE3qYGXW2g=; b=pB60WoGUeZJiTzZhbBVl8Rx0s7raNqYCvpeFpCqUgoJBFnfzKaXtBlsF6pLhhxIPyh dovgdgLArKEumIj8fDUpb7jQy5PGwlL+7LrJwgJknwa1j5qtSproG7J9angmsHVCQfBY OYlWOq8tCdYpfpf/KVX1VWxVN0MGHgg10UUEQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:reply-to:to:subject:cc:in-reply-to :mime-version:content-type:content-transfer-encoding :content-disposition:references; b=fjESN4RoHJjhoepNZ/fo5U3fzvGvRMTyuurW75HbU7lupWexquFzovgqJkg3lh6Kdx vNJdJKb0F0RQIjfg/7/ZFIAF48qtJn+oTzBQySz4QK86KSozI+8HNCLaUNgAj4WT+1dC NOMTN/HERlvy7cSf92gKx+qVIrYofPsEUMLpE= Received: by 10.151.43.19 with SMTP id v19mr3148738ybj.2.1229053883895; Thu, 11 Dec 2008 19:51:23 -0800 (PST) Received: by 10.150.123.1 with HTTP; Thu, 11 Dec 2008 19:51:23 -0800 (PST) Message-ID: <8cb6106e0812111951k18f4663ck2121b550dfe57322@mail.gmail.com> Date: Thu, 11 Dec 2008 22:51:23 -0500 From: "Josh Carroll" To: pyunyh@gmail.com In-Reply-To: <20081212034042.GL46707@cdnetworks.co.kr> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4910C055.8000505@janh.de> <20081203090658.GJ9639@cdnetworks.co.kr> <37502393@bb.ipt.ru> <20081206023016.GF22093@cdnetworks.co.kr> <539c60b90812081127s4ffb509fnea9d44d4298da666@mail.gmail.com> <8cb6106e0812081252j2b0c8e78g4dcecf8d3770c269@mail.gmail.com> <8cb6106e0812101745l54b23a08k7fbeddeb605f88ea@mail.gmail.com> <20081212020539.GI46707@cdnetworks.co.kr> <8cb6106e0812111923l15f1f715g6f20f5925e1d471a@mail.gmail.com> <20081212034042.GL46707@cdnetworks.co.kr> Cc: Steve Franks , current-list freebsd Subject: Re: Call for testers: Atheros AR8121(L1E)/AR8113/AR8114(L2E) ethernet X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: josh.carroll@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Dec 2008 03:51:25 -0000 > I guess it's caused by flow-control frames. > The flow-control feature is disabled in most drivers as mii(4) > layer still lacks the feture. ale(4) has flow-control support code > but it is in disabled state. When mii(4) is ready to handle > flow-controls ale(4) may work better. > em(4) does not rely on mii(4) layer so it implemented flow-controls > in driver. You can check flow-control satus of em(4) with > "sysctl dev.em.0.stats=1"(See XON/XOFF). Hmm, any idea why my previous motherboard (P5K-E) which had an msk(4) worked ok without the stuttering for this streaming? I believe it relies on mii as well, right? Thanks, I guess I'll stick with the em(4) PCI card, at least until I can get a PCI-E em(4). :) Josh From owner-freebsd-current@FreeBSD.ORG Fri Dec 12 03:56:33 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 87E681065670 for ; Fri, 12 Dec 2008 03:56:33 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.237]) by mx1.freebsd.org (Postfix) with ESMTP id 4894B8FC17 for ; Fri, 12 Dec 2008 03:56:33 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so1184391rvf.43 for ; Thu, 11 Dec 2008 19:56:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:received:date:from :to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=slD0A7YeehrIAJuYQJ635f2wbvqiOJ7xWqFrbO6YEe0=; b=vf6FN3nev+RlxH8Cyn9uV0KPKKZQQi0fyoBb8HRIX9MZC1KQ2059+7PpUW787SIyhE 3c+Dm38BoOlPCEVVAGsGKad/Lq9DRmOJatPZapy780p3zYL/DBYafnetJ6arDR31WAxp 5I8yBswRbvdbrDFrx7cYAUVrdS/IB1WtkdjCw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=joEdtYrIFveizz+8fCtBz1So7JI7w/xfcVRgzeFOcNCvKRiMO9mJKsNIsU3PDhQ4zg EJkGc6IsOOhjamfTBxdjjJ9Ul8GTf/j12Yln67PMhWQbnl5miyrMTCA0NEgYvHWEInQR P83QRxyXVPdGJxqN1Pko+eSKWQB2Yr+oRuN60= Received: by 10.140.208.17 with SMTP id f17mr1655813rvg.261.1229054192861; Thu, 11 Dec 2008 19:56:32 -0800 (PST) Received: from michelle.cdnetworks.co.kr ([211.53.35.84]) by mx.google.com with ESMTPS id f42sm1689876rvb.7.2008.12.11.19.56.30 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 11 Dec 2008 19:56:32 -0800 (PST) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id mBC3uP2r047650 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 12 Dec 2008 12:56:25 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id mBC3uPVb047649; Fri, 12 Dec 2008 12:56:25 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Fri, 12 Dec 2008 12:56:25 +0900 From: Pyun YongHyeon To: Josh Carroll Message-ID: <20081212035625.GN46707@cdnetworks.co.kr> References: <20081203090658.GJ9639@cdnetworks.co.kr> <37502393@bb.ipt.ru> <20081206023016.GF22093@cdnetworks.co.kr> <539c60b90812081127s4ffb509fnea9d44d4298da666@mail.gmail.com> <8cb6106e0812081252j2b0c8e78g4dcecf8d3770c269@mail.gmail.com> <8cb6106e0812101745l54b23a08k7fbeddeb605f88ea@mail.gmail.com> <20081212020539.GI46707@cdnetworks.co.kr> <8cb6106e0812111923l15f1f715g6f20f5925e1d471a@mail.gmail.com> <20081212034042.GL46707@cdnetworks.co.kr> <8cb6106e0812111951k18f4663ck2121b550dfe57322@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8cb6106e0812111951k18f4663ck2121b550dfe57322@mail.gmail.com> User-Agent: Mutt/1.4.2.1i Cc: Steve Franks , current-list freebsd Subject: Re: Call for testers: Atheros AR8121(L1E)/AR8113/AR8114(L2E) ethernet X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Dec 2008 03:56:33 -0000 On Thu, Dec 11, 2008 at 10:51:23PM -0500, Josh Carroll wrote: > > I guess it's caused by flow-control frames. > > The flow-control feature is disabled in most drivers as mii(4) > > layer still lacks the feture. ale(4) has flow-control support code > > but it is in disabled state. When mii(4) is ready to handle > > flow-controls ale(4) may work better. > > em(4) does not rely on mii(4) layer so it implemented flow-controls > > in driver. You can check flow-control satus of em(4) with > > "sysctl dev.em.0.stats=1"(See XON/XOFF). > > Hmm, any idea why my previous motherboard (P5K-E) which had an msk(4) > worked ok without the stuttering for this streaming? I believe it > relies on mii as well, right? > Yes, but msk(4) had hacks in e100phy(4) to enable flow-controls. I don't want to add these hacks to all other drivers in tree. > Thanks, I guess I'll stick with the em(4) PCI card, at least until I > can get a PCI-E em(4). :) > > Josh -- Regards, Pyun YongHyeon From owner-freebsd-current@FreeBSD.ORG Fri Dec 12 04:03:05 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7BA9D1065670 for ; Fri, 12 Dec 2008 04:03:05 +0000 (UTC) (envelope-from josh.carroll@gmail.com) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.31]) by mx1.freebsd.org (Postfix) with ESMTP id 2CAD88FC21 for ; Fri, 12 Dec 2008 04:03:04 +0000 (UTC) (envelope-from josh.carroll@gmail.com) Received: by yw-out-2324.google.com with SMTP id 9so592424ywe.13 for ; Thu, 11 Dec 2008 20:03:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:reply-to :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=ii4zQQF5POrAQx9CPXp4cwV03KlYpny7hJ+uwP2Gn9o=; b=WG2P1xM4nFpQiiEAoIW1zAsF3s6oPG4msGvIj52TkYa06xGgKNFvcYgc5XvPG6Py8b 7dM40j9gWrLkeS4rouVzi+3ubzdzoF/ujZP8dWA5NT7v0sgsNICS82e4ddDhhSKoObwc srpgnKqmdV1enEUI1hGacBFLllyBEnaXfkevw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:reply-to:to:subject:cc:in-reply-to :mime-version:content-type:content-transfer-encoding :content-disposition:references; b=H3KWirl/E6q/1JJpBrh1r+bkazs5uEN8EKwHv2kr5/Ov0MHsOoRuq7Z9lr9pngynOV gkHWszF0UPkBfU4bfRDJPargqCmNFs7RrJmYEHSRrkQ40jo2ZMBZLgLgvXR4sBDk2Moq LaxuE7cy8wteKc9XoGh7TsY7NO7ptnnmLiNrE= Received: by 10.150.216.3 with SMTP id o3mr5544263ybg.148.1229054584476; Thu, 11 Dec 2008 20:03:04 -0800 (PST) Received: by 10.150.123.1 with HTTP; Thu, 11 Dec 2008 20:03:04 -0800 (PST) Message-ID: <8cb6106e0812112003s38233af6v8d324cf70eafc8fc@mail.gmail.com> Date: Thu, 11 Dec 2008 23:03:04 -0500 From: "Josh Carroll" To: pyunyh@gmail.com In-Reply-To: <20081212035625.GN46707@cdnetworks.co.kr> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20081203090658.GJ9639@cdnetworks.co.kr> <20081206023016.GF22093@cdnetworks.co.kr> <539c60b90812081127s4ffb509fnea9d44d4298da666@mail.gmail.com> <8cb6106e0812081252j2b0c8e78g4dcecf8d3770c269@mail.gmail.com> <8cb6106e0812101745l54b23a08k7fbeddeb605f88ea@mail.gmail.com> <20081212020539.GI46707@cdnetworks.co.kr> <8cb6106e0812111923l15f1f715g6f20f5925e1d471a@mail.gmail.com> <20081212034042.GL46707@cdnetworks.co.kr> <8cb6106e0812111951k18f4663ck2121b550dfe57322@mail.gmail.com> <20081212035625.GN46707@cdnetworks.co.kr> Cc: Steve Franks , current-list freebsd Subject: Re: Call for testers: Atheros AR8121(L1E)/AR8113/AR8114(L2E) ethernet X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: josh.carroll@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Dec 2008 04:03:05 -0000 > Yes, but msk(4) had hacks in e100phy(4) to enable flow-controls. > I don't want to add these hacks to all other drivers in tree. Thanks for the explanation! I certainly understand not wanting to put non-standard hacks into the code. I imagine the number of people affected by this is minimal (like I said, the overall throughput/performance was fine). I'll just consider getting a PCI-E em(4) in the future if the PCI bus begins to become a bottleneck for me, which is unlikely as I have no raid in any of the connected machines with gigE. Regards, Josh From owner-freebsd-current@FreeBSD.ORG Fri Dec 12 04:47:56 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D970C1065670 for ; Fri, 12 Dec 2008 04:47:56 +0000 (UTC) (envelope-from petry@netmasters.com) Received: from colo3.NetMasters.Com (colo3.netmasters.com [144.202.0.66]) by mx1.freebsd.org (Postfix) with ESMTP id B0ED98FC12 for ; Fri, 12 Dec 2008 04:47:56 +0000 (UTC) (envelope-from petry@netmasters.com) Received: from dolly.netmasters.com (dolly.netmasters.com [199.201.245.12]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by colo3.NetMasters.Com (Postfix) with ESMTPSA id BA71B102C66; Thu, 11 Dec 2008 23:31:55 -0500 (EST) Message-Id: From: Michael Petry To: pyunyh@gmail.com In-Reply-To: <20081212024713.GK46707@cdnetworks.co.kr> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Date: Thu, 11 Dec 2008 23:31:55 -0500 References: <20081212024713.GK46707@cdnetworks.co.kr> X-Mailer: Apple Mail (2.929.2) MailScanner-NULL-Check: 1229661119.11301@Gk5kx1o90gZ8D7hkp80ZoA X-NetMasters-MailScanner-Information: Please contact the ISP for more information X-MailScanner-ID: BA71B102C66.1B1A8 X-NetMasters-MailScanner: Found to be clean X-NetMasters-MailScanner-From: petry@netmasters.com X-Spam-Status: No Cc: freebsd-current@FreeBSD.org Subject: Re: CFT: RTL8168C re(4) attach issue X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Dec 2008 04:47:56 -0000 On Dec 11, 2008, at 9:47 PM, Pyun YongHyeon wrote: > Hi, > > There had been several reports that some revision of RTL8168C were > not able to access PHY which in turn resulted in device attach > failure. For instance re(4) used to show the following messages. > re0: Chip rev. 0x3c000000 > re0: MAC rev. 0x00200000 > re0: PHY write failed > re0: PHY write failed > re0: MII without any phy! > > For users who suffered from these issues, please try re(4)/rl(4) at > the following URL and let me know how it goes. > http://people.freebsd.org/~yongari/re/if_re.c (copy it to /usr/usr/ > sys/dev/re/) > http://people.freebsd.org/~yongari/re/if_rlreg.h (copy it /usr/src/ > sys/pci/) > http://people.freebsd.org/~yongari/re/if_rl.c (copy it /usr/src/sys/ > pci/) > > And rebuild re(4) and rl(4). Since the issue is not always happen > testers should do power recycle several times to verify the issue. > > Thanks. > -- > Regards, > Pyun YongHyeon > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org > " Thanks!! That got it working for me. HP Pavilion a6442p with a Realtek on the motherboard re0: port 0xe800-0xe8ff mem 0xfebff000-0xfebfffff, 0xfdff0000-0xfdffffff irq 18 at device 0.0 on pci2 re0: Chip rev. 0x3c000000 re0: MAC rev. 0x00200000 miibus0: on re0 rgephy0: PHY 1 on miibus0 rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto re0: Ethernet address: 00:1f:c6:4c:55:dc re0: [FILTER] re0@pci0:2:0:0: class=0x020000 card=0x2a6f103c chip=0x816810ec rev=0x02 hdr=0x00 vendor = 'Realtek Semiconductor' device = 'RTL8168/8111 PCI-E Gigabit Ethernet NIC' class = network subclass = ethernet Mike From owner-freebsd-current@FreeBSD.ORG Fri Dec 12 05:57:09 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1DC1C1065670 for ; Fri, 12 Dec 2008 05:57:09 +0000 (UTC) (envelope-from dgerow@afflictions.org) Received: from slow2-v.mail.gandi.net (slow2-v.mail.gandi.net [217.70.178.89]) by mx1.freebsd.org (Postfix) with ESMTP id 91F288FC16 for ; Fri, 12 Dec 2008 05:57:08 +0000 (UTC) (envelope-from dgerow@afflictions.org) Received: from relay4-v.mail.gandi.net (relay4-v.mail.gandi.net [217.70.178.78]) by slow2-v.mail.gandi.net (Postfix) with ESMTP id CE3E921E24E for ; Fri, 12 Dec 2008 06:41:47 +0100 (CET) Received: from plebeian.afflictions.org (206-248-190-85.dsl.teksavvy.com [206.248.190.85]) by relay4-v.mail.gandi.net (Postfix) with ESMTP id E5C0FBA26 for ; Fri, 12 Dec 2008 06:41:41 +0100 (CET) Received: by plebeian.afflictions.org (Postfix, from userid 1001) id 53E0F7089; Fri, 12 Dec 2008 00:41:38 -0500 (EST) Date: Fri, 12 Dec 2008 00:41:38 -0500 From: Damian Gerow To: freebsd-current@freebsd.org Message-ID: <20081212054137.GA42087@plebeian.afflictions.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Panic while using ural(4) with wpa_supplicant X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Dec 2008 05:57:09 -0000 Though I've got an iwn(4), it's a 5300, which isn't yet supported. In the meantime, I'm trying to use one of the Nintendo WiFi USB sticks to provide cheap wireless network capabilities. However, when I try to use it, I invariably receive a panic. Note that I've not yet tried just using ural(4) without wpa_supplicant, as I don't have any open or WEP-protected networks against which to test. OS is a CURRENT from the morning of Dec 12. Kernel is GENERIC. Host has an established em(4) connection, and rc.conf contains the following pertinent entries: ----- #wlans_ural0="wlan0" ifconfig_wlan0="WPA DHCP" ----- Steps to Reproduce: 1) Plug in the ural(4) device: ----- ural0: on uhub7 ural0: MAC/BBP RT2570 (rev 0x05), RF RT2526 ural0: WARNING: using obsoleted IFF_NEEDSGIANT flag ----- 2) Prepare wlan0: ----- # ifconfig wlan0 create wlandev ural0 ----- 3) Wait for network connection to establish. wpa_supplicant will kick off, establish a connection, and dhclient will negotiate an IP address. At this point, triggering the panic can be done in a few ways: a) Sometimes it happens on its own, immediately. b) Performing network activity. c) Stopping wlan0 (/etc/rc.d/netif stop). d) Physically removing ural0. Most reliable is c (thus, by extension, d). 4) Observe the panic: ----- panic: _rw_rlock (radix node head): wlock already held @ /repo/freebsd/8-CURRENT/src/sys/net/route.c: 291 ----- Here's the kgdb output: ----- # cd /usr/obj/repo/freebsd/8-CURRENT/src/sys/GENERIC # kgdb kernel.debug /var/crash/vmcore.1 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 = 0; apic id = 00 fault virtual address = 0x40 fault code = supervisor read data, page not present instruction pointer = 0x8:0xffffffff80436da5 stack pointer = 0x10:0xfffffffeb3e62b10 frame pointer = 0x10:0xfffffffeb3e62b20 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 = 12 (irq19: ehci1) panic: from debugger cpuid = 0 Uptime: 1m58s Physical memory: 3976 MB Dumping 302 MB: 287 271 255 239 223 207 191 175 159 143 127 111 95 79 63 47 31 15 Reading symbols from /boot/kernel/geom_eli.ko...Reading symbols from /boot/kernel/geom_eli.ko.symbols...done. done. Loaded symbols for /boot/kernel/geom_eli.ko Reading symbols from /boot/kernel/crypto.ko...Reading symbols from /boot/kernel/crypto.ko.symbols...done. done. Loaded symbols for /boot/kernel/crypto.ko Reading symbols from /boot/kernel/zlib.ko...Reading symbols from /boot/kernel/zlib.ko.symbols...done. done. Loaded symbols for /boot/kernel/zlib.ko Reading symbols from /boot/kernel/zfs.ko...Reading symbols from /boot/kernel/zfs.ko.symbols...done. done. Loaded symbols for /boot/kernel/zfs.ko Reading symbols from /boot/kernel/opensolaris.ko...Reading symbols from /boot/kernel/opensolaris.ko.symbols...done. done. Loaded symbols for /boot/kernel/opensolaris.ko Reading symbols from /boot/kernel/i915.ko...Reading symbols from /boot/kernel/i915.ko.symbols...done. done. Loaded symbols for /boot/kernel/i915.ko Reading symbols from /boot/kernel/drm.ko...Reading symbols from /boot/kernel/drm.ko.symbols...done. done. Loaded symbols for /boot/kernel/drm.ko #0 doadump () at pcpu.h:196 196 __asm __volatile("movq %%gs:0,%0" : "=r" (td)); (kgdb) list *0xffffffff80436da5 0xffffffff80436da5 is in ehci_idone (/repo/freebsd/8-CURRENT/src/sys/dev/usb/ehci.c:914). 909 nextphys = EHCI_LINK_ADDR(le32toh(epipe->sqh->qh.qh_qtd.qtd_next)); 910 altnextphys = 911 EHCI_LINK_ADDR(le32toh(epipe->sqh->qh.qh_qtd.qtd_altnext)); 912 for (sqtd = ex->sqtdstart; sqtd != ex->sqtdend->nextqtd; 913 sqtd = sqtd->nextqtd) { 914 if (sqtd->physaddr == nextphys) { 915 epipe->sqh->qh.qh_qtd.qtd_next = 916 htole32(ex->sqtdend->nextqtd->physaddr); 917 DPRINTFN(4, ("ehci_idone: updated overlay next ptr\n")); 918 (kgdb) backtrace #0 doadump () at pcpu.h:196 #1 0xffffffff804fc3f0 in boot (howto=260) at /repo/freebsd/8-CURRENT/src/sys/kern/kern_shutdown.c:420 #2 0xffffffff804fc756 in panic (fmt=Variable "fmt" is not available. ) at /repo/freebsd/8-CURRENT/src/sys/kern/kern_shutdown.c:576 #3 0xffffffff801c38aa in db_panic (addr=Variable "addr" is not available. ) at /repo/freebsd/8-CURRENT/src/sys/ddb/db_command.c:478 #4 0xffffffff801c3e53 in db_command (last_cmdp=0xffffffff80b00d20, cmd_table=Variable "cmd_table" is not available. ) at /repo/freebsd/8-CURRENT/src/sys/ddb/db_command.c:445 #5 0xffffffff801c3f9d in db_command_loop () at /repo/freebsd/8-CURRENT/src/sys/ddb/db_command.c:498 #6 0xffffffff801c5de6 in db_trap (type=Variable "type" is not available. ) at /repo/freebsd/8-CURRENT/src/sys/ddb/db_main.c:229 #7 0xffffffff80529c13 in kdb_trap (type=12, code=0, tf=0xfffffffeb3e62a60) at /repo/freebsd/8-CURRENT/src/sys/kern/subr_kdb.c:534 #8 0xffffffff807a820d in trap_fatal (frame=0xfffffffeb3e62a60, eva=64) at /repo/freebsd/8-CURRENT/src/sys/amd64/amd64/trap.c:754 #9 0xffffffff807a8437 in trap_pfault (frame=0xfffffffeb3e62a60, usermode=0) at /repo/freebsd/8-CURRENT/src/sys/amd64/amd64/trap.c:675 #10 0xffffffff807a8e26 in trap (frame=0xfffffffeb3e62a60) at /repo/freebsd/8-CURRENT/src/sys/amd64/amd64/trap.c:444 #11 0xffffffff8078bbae in calltrap () at /repo/freebsd/8-CURRENT/src/sys/amd64/amd64/exception.S:217 #12 0xffffffff80436da5 in ehci_idone (ex=0xffffff0003ab5c00) at /repo/freebsd/8-CURRENT/src/sys/dev/usb/ehci.c:912 #13 0xffffffff804376b0 in ehci_softintr (v=0xffffff0003ab5c00) at /repo/freebsd/8-CURRENT/src/sys/dev/usb/ehci.c:802 #14 0xffffffff80465505 in usb_schedsoftintr (bus=Variable "bus" is not available. ) at /repo/freebsd/8-CURRENT/src/sys/dev/usb/usb.c:848 #15 0xffffffff8043923d in ehci_intr1 (sc=0xffffff000355a000) at /repo/freebsd/8-CURRENT/src/sys/dev/usb/ehci.c:631 #16 0xffffffff80439d52 in ehci_intr (v=Variable "v" is not available. ) at /repo/freebsd/8-CURRENT/src/sys/dev/usb/ehci.c:590 #17 0xffffffff804ddd5a in intr_event_execute_handlers (p=Variable "p" is not available. ) at /repo/freebsd/8-CURRENT/src/sys/kern/kern_intr.c:1134 #18 0xffffffff804de91d in ithread_loop (arg=Variable "arg" is not available. ) at /repo/freebsd/8-CURRENT/src/sys/kern/kern_intr.c:1147 #19 0xffffffff804dbd76 in fork_exit (callout=0xffffffff804de85f , arg=0xffffff000360ea60, frame=0xfffffffeb3e62c90) at /repo/freebsd/8-CURRENT/src/sys/kern/kern_fork.c:821 #20 0xffffffff8078bfbe in fork_trampoline () at /repo/freebsd/8-CURRENT/src/sys/amd64/amd64/exception.S:521 #21 0x0000000000000000 in ?? () #22 0x0000000000000000 in ?? () #23 0x0000000000000001 in ?? () #24 0x0000000000000000 in ?? () #25 0x0000000000000000 in ?? () #26 0x0000000000000000 in ?? () #27 0x0000000000000000 in ?? () #28 0x0000000000000000 in ?? () #29 0x0000000000000000 in ?? () #30 0x0000000000000000 in ?? () #31 0x0000000000000000 in ?? () #32 0x0000000000000000 in ?? () #33 0x0000000000000000 in ?? () #34 0x0000000000000000 in ?? () #35 0x0000000000000000 in ?? () #36 0x0000000000000000 in ?? () #37 0x0000000000000000 in ?? () #38 0x0000000000000000 in ?? () #39 0x0000000000000000 in ?? () #40 0x0000000000000000 in ?? () #41 0x0000000000000000 in ?? () #42 0x0000000000000000 in ?? () #43 0x0000000000000000 in ?? () #44 0x0000000000000000 in ?? () #45 0x0000000000ee3000 in ?? () #46 0x0000000000000000 in ?? () #47 0xffffffff80b3dac0 in affinity () #48 0xffffffff80b3dac0 in affinity () #49 0xffffff00014d3390 in ?? () #50 0xfffffffeb3e62b90 in ?? () #51 0xfffffffeb3e62b48 in ?? () #52 0xffffff00035b4720 in ?? () #53 0xffffffff8051dec6 in sched_switch (td=0xffffff000360ea60, newtd=0xffffffff804de85f, flags=Cannot access memory at address 0xffffffffffffffc0 ) at /repo/freebsd/8-CURRENT/src/sys/kern/sched_ule.c:1848 Previous frame inner to this frame (corrupt stack?) (kgdb) ----- From owner-freebsd-current@FreeBSD.ORG Fri Dec 12 08:12:25 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 64F6E106564A for ; Fri, 12 Dec 2008 08:12:25 +0000 (UTC) (envelope-from admin@kkip.pl) Received: from mainframe.kkip.pl (kkip.pl [87.105.164.78]) by mx1.freebsd.org (Postfix) with ESMTP id 0FCF38FC12 for ; Fri, 12 Dec 2008 08:12:25 +0000 (UTC) (envelope-from admin@kkip.pl) Received: from admin.admin.lan.kkip.pl ([10.66.3.254]) by mainframe.kkip.pl with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LB2iv-000JSQ-B4; Fri, 12 Dec 2008 08:46:12 +0100 Message-ID: <494216C2.7080606@kkip.pl> Date: Fri, 12 Dec 2008 08:46:10 +0100 From: Bartosz Stec User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Randy Bush References: <4940A685.7040608@psg.com> In-Reply-To: <4940A685.7040608@psg.com> Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated-User: admin@kkip.pl X-Authenticator: plain X-Sender-Verify: SUCCEEDED (sender exists & accepts mail) X-Spam-Score: -8.9 X-Spam-Score-Int: -88 X-Exim-Version: 4.69 (build at 01-Nov-2008 10:39:57) X-Date: 2008-12-12 08:46:12 X-Connected-IP: 10.66.3.254:1685 X-Message-Linecount: 107 X-Body-Linecount: 93 X-Message-Size: 4304 X-Body-Size: 3749 X-Received-Count: 1 X-Recipient-Count: 2 X-Local-Recipient-Count: 2 X-Local-Recipient-Defer-Count: 0 X-Local-Recipient-Fail-Count: 0 Cc: FreeBSD Current Subject: Re: panic: sleeping thread & bufwrite: buffer is not busy??? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Dec 2008 08:12:25 -0000 Randy Bush pisze: > i386 soekris 5501 > current as of Dec 11 00:27 gmt > > Unread portion of the kernel message buffer: > Sleeping thread (tid 100054, pid 646) owns a non-sleepable lock > panic: sleeping thread > panic: bufwrite: buffer is not busy??? > Uptime: 2m1s > Physical memory: 503 MB > > #0 doadump () at pcpu.h:246 > #1 0xc0571f33 in boot (howto=260) at > /usr/src/sys/kern/kern_shutdown.c:420 > #2 0xc05720f7 in panic (fmt=Variable "fmt" is not available.) > at /usr/src/sys/kern/kern_shutdown.c:576 > #3 0xc06fc75c in ffs_bufwrite (bp=0xc2937e20) > at /usr/src/sys/ufs/ffs/ffs_vfsops.c:1786 > #4 0xc05c7250 in vfs_bio_awrite (bp=0xc2937e20) at buf.h:385 > #5 0xc05cfee0 in vop_stdfsync (ap=0xc2a89b34) > at /usr/src/sys/kern/vfs_default.c:479 > #6 0xc0520ad3 in devfs_fsync (ap=0xc2a89b34) > at /usr/src/sys/fs/devfs/devfs_vnops.c:485 > #7 0xc074e50e in VOP_FSYNC_APV (vop=0xc07cc800, a=0xc2a89b34) > at vnode_if.c:1007 > #8 0xc06fd0a2 in ffs_sync (mp=0xc2e33c80, waitfor=2, td=0xc2c28480) > at vnode_if.h:529 > #9 0xc05e0803 in sync (td=0xc2c28480, uap=0x0) > at /usr/src/sys/kern/vfs_syscalls.c:149 > #10 0xc0571ad2 in boot (howto=256) at > /usr/src/sys/kern/kern_shutdown.c:312 > #11 0xc05720f7 in panic (fmt=Variable "fmt" is not available.) > at /usr/src/sys/kern/kern_shutdown.c:576 > #12 0xc059ec81 in propagate_priority (td=0xc2e696c0) > at /usr/src/sys/kern/subr_turnstile.c:222 > #13 0xc059f551 in turnstile_wait (ts=0xc2c0ee10, owner=0xc2e696c0, > queue=Variable "queue" is not available.) > at /usr/src/sys/kern/subr_turnstile.c:738 > #14 0xc0570c73 in _rw_wlock_hard (rw=0xc2cdcd80, tid=3267527808, > file=0x0, line=0) > at /usr/src/sys/kern/kern_rwlock.c:705 > #15 0xc06bdcb6 in in6_mtutimo (rock=0xc2cdcd00) > at /usr/src/sys/netinet6/in6_rmx.c:437 > #16 0xc0580f77 in softclock (arg=0xc07ffbe0) > at /usr/src/sys/kern/kern_timeout.c:398 > #17 0xc055790a in intr_event_execute_handlers (p=0xc2c257ec, > ie=0xc2c22400) > at /usr/src/sys/kern/kern_intr.c:1134 > #18 0xc0558933 in ithread_loop (arg=0xc2c07ba0) > at /usr/src/sys/kern/kern_intr.c:1147 > #19 0xc0555cb6 in fork_exit (callout=0xc05588d0 , > arg=0xc2c07ba0, frame=0xc2a89d38) at > /usr/src/sys/kern/kern_fork.c:821 > #20 0xc0730a50 in fork_trampoline () at > /usr/src/sys/i386/i386/exception.s:270 > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to > "freebsd-current-unsubscribe@freebsd.org" I have similiar problem: Dump header from device /dev/ad0s1b Architecture: i386 Architecture Version: 2 Dump Length: 216797184B (206 MB) Blocksize: 512 Dumptime: Thu Dec 11 20:20:45 2008 Hostname: serwer.obsysa.net Magic: FreeBSD Kernel Dump Version String: FreeBSD 8.0-CURRENT #3: Thu Dec 11 16:55:50 CET 2008 ncpnc@serwer.obsysa.net:/usr/obj/usr/src/sys/ATHLON8 Panic String: sleeping thread Dump Parity: 1830535215 Bounds: 0 Dump Status: good Unfortunately I cannot provide more debug information at this time because kernel was built without debugging options. (I will rebuild it if needed) However I can still provide some info: - kernel panic while loading modules, just after loding ZFS module (I have RAIDZ configuration) and after a couple of minutes without any visible action on the screen. - I have this panic with *every* build I made after 7 Dec 2008, but I don't remember wchich day exactly I have experienced that for the first time. - For now I'm using kernel builded 7 Dec 2008 and no panic seen at all. -- Bartosz Stec From owner-freebsd-current@FreeBSD.ORG Fri Dec 12 09:52:45 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 15C151065670 for ; Fri, 12 Dec 2008 09:52:45 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.terabit.net.ua (mail.terabit.net.ua [195.137.202.147]) by mx1.freebsd.org (Postfix) with ESMTP id A38F88FC14 for ; Fri, 12 Dec 2008 09:52:44 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from skuns.zoral.com.ua ([91.193.166.194] helo=mail.zoral.com.ua) by mail.terabit.net.ua with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63 (FreeBSD)) (envelope-from ) id 1LB4hO-0007te-7T; Fri, 12 Dec 2008 11:52:42 +0200 Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id mBC9qc8U039990 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 12 Dec 2008 11:52:39 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3) with ESMTP id mBC9qckr025019; Fri, 12 Dec 2008 11:52:38 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3/Submit) id mBC9qca5025018; Fri, 12 Dec 2008 11:52:38 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 12 Dec 2008 11:52:38 +0200 From: Kostik Belousov To: Bartosz Stec Message-ID: <20081212095238.GY2038@deviant.kiev.zoral.com.ua> References: <4940A685.7040608@psg.com> <494216C2.7080606@kkip.pl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="UJoEJyuH25+IoM96" Content-Disposition: inline In-Reply-To: <494216C2.7080606@kkip.pl> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua X-Virus-Scanned: mail.terabit.net.ua 1LB4hO-0007te-7T c26b065b130b663fc565536a76ee9982 X-Terabit: YES Cc: Randy Bush , FreeBSD Current Subject: Re: panic: sleeping thread & bufwrite: buffer is not busy??? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Dec 2008 09:52:45 -0000 --UJoEJyuH25+IoM96 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Dec 12, 2008 at 08:46:10AM +0100, Bartosz Stec wrote: > Randy Bush pisze: > >i386 soekris 5501 > >current as of Dec 11 00:27 gmt > > > >Unread portion of the kernel message buffer: > >Sleeping thread (tid 100054, pid 646) owns a non-sleepable lock > >panic: sleeping thread > >panic: bufwrite: buffer is not busy??? > >Uptime: 2m1s > >Physical memory: 503 MB > > > >#0 doadump () at pcpu.h:246 > >#1 0xc0571f33 in boot (howto=3D260) at=20 > >/usr/src/sys/kern/kern_shutdown.c:420 > >#2 0xc05720f7 in panic (fmt=3DVariable "fmt" is not available.) > > at /usr/src/sys/kern/kern_shutdown.c:576 > >#3 0xc06fc75c in ffs_bufwrite (bp=3D0xc2937e20) > > at /usr/src/sys/ufs/ffs/ffs_vfsops.c:1786 > >#4 0xc05c7250 in vfs_bio_awrite (bp=3D0xc2937e20) at buf.h:385 > >#5 0xc05cfee0 in vop_stdfsync (ap=3D0xc2a89b34) > > at /usr/src/sys/kern/vfs_default.c:479 > >#6 0xc0520ad3 in devfs_fsync (ap=3D0xc2a89b34) > > at /usr/src/sys/fs/devfs/devfs_vnops.c:485 > >#7 0xc074e50e in VOP_FSYNC_APV (vop=3D0xc07cc800, a=3D0xc2a89b34) > > at vnode_if.c:1007 > >#8 0xc06fd0a2 in ffs_sync (mp=3D0xc2e33c80, waitfor=3D2, td=3D0xc2c2848= 0) > > at vnode_if.h:529 > >#9 0xc05e0803 in sync (td=3D0xc2c28480, uap=3D0x0) > > at /usr/src/sys/kern/vfs_syscalls.c:149 > >#10 0xc0571ad2 in boot (howto=3D256) at=20 > >/usr/src/sys/kern/kern_shutdown.c:312 > >#11 0xc05720f7 in panic (fmt=3DVariable "fmt" is not available.) > > at /usr/src/sys/kern/kern_shutdown.c:576 > >#12 0xc059ec81 in propagate_priority (td=3D0xc2e696c0) > > at /usr/src/sys/kern/subr_turnstile.c:222 > >#13 0xc059f551 in turnstile_wait (ts=3D0xc2c0ee10, owner=3D0xc2e696c0,= =20 > >queue=3DVariable "queue" is not available.) > > at /usr/src/sys/kern/subr_turnstile.c:738 > >#14 0xc0570c73 in _rw_wlock_hard (rw=3D0xc2cdcd80, tid=3D3267527808,=20 > >file=3D0x0, line=3D0) > > at /usr/src/sys/kern/kern_rwlock.c:705 > >#15 0xc06bdcb6 in in6_mtutimo (rock=3D0xc2cdcd00) > > at /usr/src/sys/netinet6/in6_rmx.c:437 > >#16 0xc0580f77 in softclock (arg=3D0xc07ffbe0) > > at /usr/src/sys/kern/kern_timeout.c:398 > >#17 0xc055790a in intr_event_execute_handlers (p=3D0xc2c257ec,=20 > >ie=3D0xc2c22400) > > at /usr/src/sys/kern/kern_intr.c:1134 > >#18 0xc0558933 in ithread_loop (arg=3D0xc2c07ba0) > > at /usr/src/sys/kern/kern_intr.c:1147 > >#19 0xc0555cb6 in fork_exit (callout=3D0xc05588d0 , > > arg=3D0xc2c07ba0, frame=3D0xc2a89d38) at=20 > >/usr/src/sys/kern/kern_fork.c:821 > >#20 0xc0730a50 in fork_trampoline () at=20 > >/usr/src/sys/i386/i386/exception.s:270 > >_______________________________________________ > >freebsd-current@freebsd.org mailing list > >http://lists.freebsd.org/mailman/listinfo/freebsd-current > >To unsubscribe, send any mail to=20 > >"freebsd-current-unsubscribe@freebsd.org" > I have similiar problem: >=20 > Dump header from device /dev/ad0s1b > Architecture: i386 > Architecture Version: 2 > Dump Length: 216797184B (206 MB) > Blocksize: 512 > Dumptime: Thu Dec 11 20:20:45 2008 > Hostname: serwer.obsysa.net > Magic: FreeBSD Kernel Dump > Version String: FreeBSD 8.0-CURRENT #3: Thu Dec 11 16:55:50 CET 2008 > ncpnc@serwer.obsysa.net:/usr/obj/usr/src/sys/ATHLON8 > Panic String: sleeping thread > Dump Parity: 1830535215 > Bounds: 0 > Dump Status: good >=20 > Unfortunately I cannot provide more debug information at this time=20 > because kernel was built without debugging options. (I will rebuild it=20 > if needed) However I can still provide some info: > - kernel panic while loading modules, just after loding ZFS module (I=20 > have RAIDZ configuration) and after a couple of minutes without any=20 > visible action on the screen. > - I have this panic with *every* build I made after 7 Dec 2008, but I=20 > don't remember wchich day exactly I have experienced that for the first= =20 > time. > - For now I'm using kernel builded 7 Dec 2008 and no panic seen at all. You are mixing the issues without a reason. To claim that you problem is similar, you need to show the similar backtrace. The panic shown is the late manifestation of a problem, it is kind a catch-all for some sort of locking issues. --UJoEJyuH25+IoM96 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAklCNGYACgkQC3+MBN1Mb4izUwCfcJciBNXp2Ff39V0+WqpajGaZ drgAmwZpNqrv8FJkiR93k1/taCju5yyg =W8wK -----END PGP SIGNATURE----- --UJoEJyuH25+IoM96-- From owner-freebsd-current@FreeBSD.ORG Fri Dec 12 10:08:41 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2A92F1065672 for ; Fri, 12 Dec 2008 10:08:41 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.225]) by mx1.freebsd.org (Postfix) with ESMTP id E6EE68FC20 for ; Fri, 12 Dec 2008 10:08:40 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so1297656rvf.43 for ; Fri, 12 Dec 2008 02:08:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:received:date:from :to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=6IDegw9yLBZwXASspEPTTirDjBp6t8dAZDeRmteP1oI=; b=f/ILR1s3AoZhqtTiLe/UhuFc13cgtHpC45jBEhBT0SSlPV756A1EcA+8AXgRZztEue xeSctzKQBmrc8QuyD/q2FspjvecllC677az/w31yIou6uxbW18i5RGy6ffDlLPWgSHRz eIImYXZhCdzNqKOe/qd4j9vdfzitgBqnMPfLs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=R3HSpJa///NlfOoMFByUj6wJsB6iqsfYkvdvRyFYkcqdfYPcEJ2Nnx60goMxP6P1zv 7S3vo136ilDGL2hVUC9TKc9zBJVsZQTvXHkQzfnfbDpigNzyg5mW0xElzXk491eVJnAl waGbW9MIhq1Xnh3Om28pzGfiARlYIHRdXoQAI= Received: by 10.141.51.10 with SMTP id d10mr1820451rvk.195.1229076520515; Fri, 12 Dec 2008 02:08:40 -0800 (PST) Received: from michelle.cdnetworks.co.kr ([211.53.35.84]) by mx.google.com with ESMTPS id b8sm8205608rvf.3.2008.12.12.02.08.37 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 12 Dec 2008 02:08:39 -0800 (PST) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id mBCA8WPk048654 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 12 Dec 2008 19:08:32 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id mBCA8Tkc048653; Fri, 12 Dec 2008 19:08:29 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Fri, 12 Dec 2008 19:08:28 +0900 From: Pyun YongHyeon To: Michael Petry Message-ID: <20081212100828.GP46707@cdnetworks.co.kr> References: <20081212024713.GK46707@cdnetworks.co.kr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Cc: freebsd-current@FreeBSD.org Subject: Re: CFT: RTL8168C re(4) attach issue X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Dec 2008 10:08:41 -0000 On Thu, Dec 11, 2008 at 11:31:55PM -0500, Michael Petry wrote: > > On Dec 11, 2008, at 9:47 PM, Pyun YongHyeon wrote: > > >Hi, > > > >There had been several reports that some revision of RTL8168C were > >not able to access PHY which in turn resulted in device attach > >failure. For instance re(4) used to show the following messages. > >re0: Chip rev. 0x3c000000 > >re0: MAC rev. 0x00200000 > >re0: PHY write failed > >re0: PHY write failed > >re0: MII without any phy! > > > >For users who suffered from these issues, please try re(4)/rl(4) at > >the following URL and let me know how it goes. > >http://people.freebsd.org/~yongari/re/if_re.c (copy it to /usr/usr/ > >sys/dev/re/) > >http://people.freebsd.org/~yongari/re/if_rlreg.h (copy it /usr/src/ > >sys/pci/) > >http://people.freebsd.org/~yongari/re/if_rl.c (copy it /usr/src/sys/ > >pci/) > > > >And rebuild re(4) and rl(4). Since the issue is not always happen > >testers should do power recycle several times to verify the issue. > > > >Thanks. > >-- > >Regards, > >Pyun YongHyeon > >_______________________________________________ > >freebsd-current@freebsd.org mailing list > >http://lists.freebsd.org/mailman/listinfo/freebsd-current > >To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org > >" > > Thanks!! > > That got it working for me. > > HP Pavilion a6442p with a Realtek on the motherboard > > re0: Gigabit Ethernet> port 0xe800-0xe8ff mem 0xfebff000-0xfebfffff, > 0xfdff0000-0xfdffffff irq 18 at device 0.0 on pci2 > re0: Chip rev. 0x3c000000 > re0: MAC rev. 0x00200000 > miibus0: on re0 > rgephy0: PHY 1 on miibus0 > rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, > 1000baseT-FDX, auto > re0: Ethernet address: 00:1f:c6:4c:55:dc > re0: [FILTER] > Thanks, would you also verify WOL functionality? -- Regards, Pyun YongHyeon From owner-freebsd-current@FreeBSD.ORG Fri Dec 12 10:35:12 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EFA151065670 for ; Fri, 12 Dec 2008 10:35:11 +0000 (UTC) (envelope-from admin@kkip.pl) Received: from mainframe.kkip.pl (kkip.pl [87.105.164.78]) by mx1.freebsd.org (Postfix) with ESMTP id 809F58FC22 for ; Fri, 12 Dec 2008 10:35:10 +0000 (UTC) (envelope-from admin@kkip.pl) Received: from admin.admin.lan.kkip.pl ([10.66.3.254]) by mainframe.kkip.pl with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LB5MQ-0003sf-4c; Fri, 12 Dec 2008 11:35:08 +0100 Message-ID: <49423E5A.10900@kkip.pl> Date: Fri, 12 Dec 2008 11:35:06 +0100 From: Bartosz Stec User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Kostik Belousov References: <4940A685.7040608@psg.com> <494216C2.7080606@kkip.pl> <20081212095238.GY2038@deviant.kiev.zoral.com.ua> In-Reply-To: <20081212095238.GY2038@deviant.kiev.zoral.com.ua> Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated-User: admin@kkip.pl X-Authenticator: plain X-Sender-Verify: SUCCEEDED (sender exists & accepts mail) X-Spam-Score: -8.9 X-Spam-Score-Int: -88 X-Exim-Version: 4.69 (build at 01-Nov-2008 10:39:57) X-Date: 2008-12-12 11:35:08 X-Connected-IP: 10.66.3.254:3405 X-Message-Linecount: 131 X-Body-Linecount: 117 X-Message-Size: 5507 X-Body-Size: 4815 X-Received-Count: 1 X-Recipient-Count: 3 X-Local-Recipient-Count: 3 X-Local-Recipient-Defer-Count: 0 X-Local-Recipient-Fail-Count: 0 Cc: Randy Bush , FreeBSD Current Subject: Re: panic: sleeping thread & bufwrite: buffer is not busy??? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Dec 2008 10:35:12 -0000 Kostik Belousov pisze: > On Fri, Dec 12, 2008 at 08:46:10AM +0100, Bartosz Stec wrote: > >> Randy Bush pisze: >> >>> i386 soekris 5501 >>> current as of Dec 11 00:27 gmt >>> >>> Unread portion of the kernel message buffer: >>> Sleeping thread (tid 100054, pid 646) owns a non-sleepable lock >>> panic: sleeping thread >>> panic: bufwrite: buffer is not busy??? >>> Uptime: 2m1s >>> Physical memory: 503 MB >>> >>> #0 doadump () at pcpu.h:246 >>> #1 0xc0571f33 in boot (howto=260) at >>> /usr/src/sys/kern/kern_shutdown.c:420 >>> #2 0xc05720f7 in panic (fmt=Variable "fmt" is not available.) >>> at /usr/src/sys/kern/kern_shutdown.c:576 >>> #3 0xc06fc75c in ffs_bufwrite (bp=0xc2937e20) >>> at /usr/src/sys/ufs/ffs/ffs_vfsops.c:1786 >>> #4 0xc05c7250 in vfs_bio_awrite (bp=0xc2937e20) at buf.h:385 >>> #5 0xc05cfee0 in vop_stdfsync (ap=0xc2a89b34) >>> at /usr/src/sys/kern/vfs_default.c:479 >>> #6 0xc0520ad3 in devfs_fsync (ap=0xc2a89b34) >>> at /usr/src/sys/fs/devfs/devfs_vnops.c:485 >>> #7 0xc074e50e in VOP_FSYNC_APV (vop=0xc07cc800, a=0xc2a89b34) >>> at vnode_if.c:1007 >>> #8 0xc06fd0a2 in ffs_sync (mp=0xc2e33c80, waitfor=2, td=0xc2c28480) >>> at vnode_if.h:529 >>> #9 0xc05e0803 in sync (td=0xc2c28480, uap=0x0) >>> at /usr/src/sys/kern/vfs_syscalls.c:149 >>> #10 0xc0571ad2 in boot (howto=256) at >>> /usr/src/sys/kern/kern_shutdown.c:312 >>> #11 0xc05720f7 in panic (fmt=Variable "fmt" is not available.) >>> at /usr/src/sys/kern/kern_shutdown.c:576 >>> #12 0xc059ec81 in propagate_priority (td=0xc2e696c0) >>> at /usr/src/sys/kern/subr_turnstile.c:222 >>> #13 0xc059f551 in turnstile_wait (ts=0xc2c0ee10, owner=0xc2e696c0, >>> queue=Variable "queue" is not available.) >>> at /usr/src/sys/kern/subr_turnstile.c:738 >>> #14 0xc0570c73 in _rw_wlock_hard (rw=0xc2cdcd80, tid=3267527808, >>> file=0x0, line=0) >>> at /usr/src/sys/kern/kern_rwlock.c:705 >>> #15 0xc06bdcb6 in in6_mtutimo (rock=0xc2cdcd00) >>> at /usr/src/sys/netinet6/in6_rmx.c:437 >>> #16 0xc0580f77 in softclock (arg=0xc07ffbe0) >>> at /usr/src/sys/kern/kern_timeout.c:398 >>> #17 0xc055790a in intr_event_execute_handlers (p=0xc2c257ec, >>> ie=0xc2c22400) >>> at /usr/src/sys/kern/kern_intr.c:1134 >>> #18 0xc0558933 in ithread_loop (arg=0xc2c07ba0) >>> at /usr/src/sys/kern/kern_intr.c:1147 >>> #19 0xc0555cb6 in fork_exit (callout=0xc05588d0 , >>> arg=0xc2c07ba0, frame=0xc2a89d38) at >>> /usr/src/sys/kern/kern_fork.c:821 >>> #20 0xc0730a50 in fork_trampoline () at >>> /usr/src/sys/i386/i386/exception.s:270 >>> _______________________________________________ >>> freebsd-current@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-current >>> To unsubscribe, send any mail to >>> "freebsd-current-unsubscribe@freebsd.org" >>> >> I have similiar problem: >> >> Dump header from device /dev/ad0s1b >> Architecture: i386 >> Architecture Version: 2 >> Dump Length: 216797184B (206 MB) >> Blocksize: 512 >> Dumptime: Thu Dec 11 20:20:45 2008 >> Hostname: serwer.obsysa.net >> Magic: FreeBSD Kernel Dump >> Version String: FreeBSD 8.0-CURRENT #3: Thu Dec 11 16:55:50 CET 2008 >> ncpnc@serwer.obsysa.net:/usr/obj/usr/src/sys/ATHLON8 >> Panic String: sleeping thread >> Dump Parity: 1830535215 >> Bounds: 0 >> Dump Status: good >> >> Unfortunately I cannot provide more debug information at this time >> because kernel was built without debugging options. (I will rebuild it >> if needed) However I can still provide some info: >> - kernel panic while loading modules, just after loding ZFS module (I >> have RAIDZ configuration) and after a couple of minutes without any >> visible action on the screen. >> - I have this panic with *every* build I made after 7 Dec 2008, but I >> don't remember wchich day exactly I have experienced that for the first >> time. >> - For now I'm using kernel builded 7 Dec 2008 and no panic seen at all. >> > > You are mixing the issues without a reason. To claim that you problem > is similar, you need to show the similar backtrace. The panic shown is > the late manifestation of a problem, it is kind a catch-all for some > sort of locking issues. > OK. I'll try to build debug kernel today and I will provide backtrace. I forgot to mention in my last post that I saw very similiar (if not identical) lines to: Sleeping thread (tid 100054, pid 646) owns a non-sleepable lock panic: sleeping thread panic: bufwrite: buffer is not busy??? while checking dmesg buffer after one of the panics earlier. That's why I assumed it's probably the same issue. Sorry for confusion, they're my first steps with CURRENT and very first experience with kernel panic :). Cheers! -- Bartosz Stec From owner-freebsd-current@FreeBSD.ORG Fri Dec 12 10:37:35 2008 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7A336106564A for ; Fri, 12 Dec 2008 10:37:35 +0000 (UTC) (envelope-from bsam@ipt.ru) Received: from services.ipt.ru (services.ipt.ru [194.62.233.110]) by mx1.freebsd.org (Postfix) with ESMTP id 2D84E8FC13 for ; Fri, 12 Dec 2008 10:37:35 +0000 (UTC) (envelope-from bsam@ipt.ru) Received: from bb.ipt.ru ([194.62.233.89]) by services.ipt.ru with esmtp (Exim 4.54 (FreeBSD)) id 1LB5On-0006it-Gu; Fri, 12 Dec 2008 13:37:33 +0300 To: Marcel Moolenaar References: <92804393@bb.ipt.ru> <26722819@bb.ipt.ru> <26719629@bb.ipt.ru> <19F75E66-0535-4982-9726-E2C0A03117EA@mac.com> <94541668@bb.ipt.ru> <48144979@bb.ipt.ru> <548CF0A3-1B07-49DA-A177-6EA85FD8CF2F@mac.com> From: Boris Samorodov Date: Fri, 12 Dec 2008 13:37:33 +0300 In-Reply-To: <548CF0A3-1B07-49DA-A177-6EA85FD8CF2F@mac.com> (Marcel Moolenaar's message of "Thu\, 11 Dec 2008 10\:29\:37 -0800") Message-ID: <94539778@bb.ipt.ru> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-current@FreeBSD.org, rea-fbsd@codelabs.ru Subject: Re: Timeda 8-multiport adapter: only 2 ports available X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Dec 2008 10:37:35 -0000 Marcel Moolenaar writes: > On Dec 11, 2008, at 10:00 AM, Boris Samorodov wrote: >> Marcel Moolenaar writes: >> >>> Summary: >>> >>> port 1: IO=0xec00; IIR=0x1, 0xc1; MCR=0x0, 0x8 >>> port 2: IO=0xec08; IIR=0x1, 0xc1; MCR=0x0, 0x8 >>> port 3: IO=0xe880; IIR=0x1; MCR=0x40 >>> port 4: IO=0xe888; IIR=0x1; MCR=0x40 >>> port 5: IO=0xe800; IIR=0x1; MCR=0x40 >>> port 6: IO=0xe480; IIR=0x1; MCR=0x40 >>> port 7: IO=0xe400; IIR=0x1; MCR=0x40 >>> port 8: IO=0xe080; IIR=0x1; MCR=0x40 >>> >>> For ports 3-8, the MCR has a value that's not liked by >>> uart(4). I think we need to know what that value means. >>> Are the ports disabled? Are they in a non-standard >>> mode? Is it just a non-standard status bit that's set >>> and we should ignore it? etc... >>> >>> Boris: can you apply the following patch and see if >>> uart(4) attaches to all ports? If yes, can you see >>> if those ports actually work as well? >> >> All ports were attached. But ports 3-8 don't work as axpected. >> I see garbage when connecting via those ports. > > Ok, so it's more than just a non-standard status bit that > can be ignored :-/ > > Unfortunately, I don't have any of their hardware, nor any > documentation... Seems I've found something interesting. Here is a procedure to initialize ports from producer's sources: ----- static int golden_startup(struct snx_port *port) { struct golden_port *up = (struct golden_port *)port; up->capabilities = uart_config[up->port.type].flags; up->mcr = 0; if (up->capabilities & UART_CLEAR_FIFO) { WRITE_UART_FCR(up, UART_FCR_ENABLE_FIFO); WRITE_UART_FCR(up, UART_FCR_ENABLE_FIFO | UART_FCR_CLEAR_RCVR | UART_FCR_CLEAR_XMIT); WRITE_UART_FCR(up, 0); } (void) READ_UART_LSR(up); (void) READ_UART_RX(up); (void) READ_UART_IIR(up); (void) READ_UART_MSR(up); if (!(up->port.flags & UPF_BUGGY_UART) && (READ_UART_LSR(up) == 0xff)) { printk("GOLDEN Info : ttySNX%d: LSR safety check engaged!\n", up->port.line); return -ENODEV; } WRITE_UART_LCR(up, UART_LCR_WLEN8); if (up->port.type == PORT_SUN1699) { up->ier = UART_IER_RLSI | UART_IER_RDI | SUN1699_CLK_DIVIDER_DISABLE; } else if (up->port.type == PORT_SUN1889) { up->ier = UART_IER_RLSI | UART_IER_RDI; } else { up->ier = UART_IER_RLSI | UART_IER_RDI; } WRITE_UART_IER(up, up->ier); (void) READ_UART_LSR(up); (void) READ_UART_RX(up); (void) READ_UART_IIR(up); (void) READ_UART_MSR(up); return 0; } ----- I may say that SUN1889 uarts are initialized like default. And indeed two first ports work here. The card contains only one SUN1889 chip (for two first ports). All other chips are SUN1699 which (better to say serial ports) should be initialized with the flag SUN1699_CLK_DIVIDER_DISABLE (0x10). Don't know how/where to do it. :-( For those curious source and headers may be found at: ftp://ftp.ipt.ru/pub/sunix/golden_V1.08/golden/driver WBR -- Boris Samorodov (bsam) Research Engineer, http://www.ipt.ru Telephone & Internet SP FreeBSD committer, http://www.FreeBSD.org The Power To Serve From owner-freebsd-current@FreeBSD.ORG Fri Dec 12 10:38:57 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6B20A1065676 for ; Fri, 12 Dec 2008 10:38:57 +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 467958FC1F for ; Fri, 12 Dec 2008 10:38:57 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTP id E3EA046B51; Fri, 12 Dec 2008 05:38:56 -0500 (EST) Date: Fri, 12 Dec 2008 10:38:56 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Kostik Belousov In-Reply-To: <20081212095238.GY2038@deviant.kiev.zoral.com.ua> Message-ID: References: <4940A685.7040608@psg.com> <494216C2.7080606@kkip.pl> <20081212095238.GY2038@deviant.kiev.zoral.com.ua> User-Agent: Alpine 1.10 (BSF 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Randy Bush , Bartosz Stec , FreeBSD Current Subject: Re: panic: sleeping thread & bufwrite: buffer is not busy??? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Dec 2008 10:38:57 -0000 On Fri, 12 Dec 2008, Kostik Belousov wrote: >> Unfortunately I cannot provide more debug information at this time >> because kernel was built without debugging options. (I will rebuild it >> if needed) However I can still provide some info: >> - kernel panic while loading modules, just after loding ZFS module (I >> have RAIDZ configuration) and after a couple of minutes without any >> visible action on the screen. >> - I have this panic with *every* build I made after 7 Dec 2008, but I >> don't remember wchich day exactly I have experienced that for the first >> time. >> - For now I'm using kernel builded 7 Dec 2008 and no panic seen at all. > > You are mixing the issues without a reason. To claim that you problem is > similar, you need to show the similar backtrace. The panic shown is the late > manifestation of a problem, it is kind a catch-all for some sort of locking > issues. This is the second report of weird rwlock-related panics in a week. We should read the code on this one closely, but I can't help but notice that it's similar to Roman's report of an rwlock-related panic. Was there a locking/scheduling change in the last week or two in -current that could explain these symptoms? Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-current@FreeBSD.ORG Fri Dec 12 10:41:02 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6D8F41065676 for ; Fri, 12 Dec 2008 10:41:02 +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 48C2D8FC16 for ; Fri, 12 Dec 2008 10:41:02 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTP id E0A6246B64; Fri, 12 Dec 2008 05:41:01 -0500 (EST) Date: Fri, 12 Dec 2008 10:41:01 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Bartosz Stec In-Reply-To: <49423E5A.10900@kkip.pl> Message-ID: References: <4940A685.7040608@psg.com> <494216C2.7080606@kkip.pl> <20081212095238.GY2038@deviant.kiev.zoral.com.ua> <49423E5A.10900@kkip.pl> User-Agent: Alpine 1.10 (BSF 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Kostik Belousov , Randy Bush , FreeBSD Current Subject: Re: panic: sleeping thread & bufwrite: buffer is not busy??? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Dec 2008 10:41:02 -0000 On Fri, 12 Dec 2008, Bartosz Stec wrote: > OK. I'll try to build debug kernel today and I will provide backtrace. I > forgot to mention in my last post that I saw very similiar (if not > identical) lines to: > > Sleeping thread (tid 100054, pid 646) owns a non-sleepable lock > panic: sleeping thread > panic: bufwrite: buffer is not busy??? > > while checking dmesg buffer after one of the panics earlier. That's why I > assumed it's probably the same issue. Sorry for confusion, they're my first > steps with CURRENT and very first experience with kernel panic :). Yeah, secondary panics can significantly complicate the debugging process, unfortunately. Another similar class of confusing cases exist when panics occur and are then preempted during the panic by another thread that promptly trips over state left behind by the first thread, and panics. :-) Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-current@FreeBSD.ORG Fri Dec 12 11:25:22 2008 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5F2A0106564A; Fri, 12 Dec 2008 11:25:21 +0000 (UTC) (envelope-from rdivacky@lev.vlakno.cz) Received: from vlakno.cz (77-93-215-190.static.masterinter.net [77.93.215.190]) by mx1.freebsd.org (Postfix) with ESMTP id 15DFE8FC16; Fri, 12 Dec 2008 11:25:20 +0000 (UTC) (envelope-from rdivacky@lev.vlakno.cz) Received: from localhost (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id 5A7FD9CB198; Fri, 12 Dec 2008 12:20:33 +0100 (CET) X-Virus-Scanned: amavisd-new at vlakno.cz Received: from vlakno.cz ([127.0.0.1]) by localhost (lev.vlakno.cz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aOTgaFnl-fmr; Fri, 12 Dec 2008 12:20:31 +0100 (CET) Received: from lev.vlakno.cz (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id 1AE3B9CB2B8; Fri, 12 Dec 2008 12:20:31 +0100 (CET) Received: (from rdivacky@localhost) by lev.vlakno.cz (8.14.2/8.14.2/Submit) id mBCBKUmx074692; Fri, 12 Dec 2008 12:20:30 +0100 (CET) (envelope-from rdivacky) Date: Fri, 12 Dec 2008 12:20:30 +0100 From: Roman Divacky To: Robert Watson Message-ID: <20081212112030.GA74265@freebsd.org> References: <4940A685.7040608@psg.com> <494216C2.7080606@kkip.pl> <20081212095238.GY2038@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: Kostik Belousov , Randy Bush , Bartosz Stec , FreeBSD Current Subject: Re: panic: sleeping thread & bufwrite: buffer is not busy??? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Dec 2008 11:25:22 -0000 On Fri, Dec 12, 2008 at 10:38:56AM +0000, Robert Watson wrote: > On Fri, 12 Dec 2008, Kostik Belousov wrote: > > >>Unfortunately I cannot provide more debug information at this time > >>because kernel was built without debugging options. (I will rebuild it > >>if needed) However I can still provide some info: > >>- kernel panic while loading modules, just after loding ZFS module (I > >>have RAIDZ configuration) and after a couple of minutes without any > >>visible action on the screen. > >>- I have this panic with *every* build I made after 7 Dec 2008, but I > >>don't remember wchich day exactly I have experienced that for the first > >>time. > >>- For now I'm using kernel builded 7 Dec 2008 and no panic seen at all. > > > >You are mixing the issues without a reason. To claim that you problem is > >similar, you need to show the similar backtrace. The panic shown is the > >late manifestation of a problem, it is kind a catch-all for some sort of > >locking issues. > > This is the second report of weird rwlock-related panics in a week. We > should read the code on this one closely, but I can't help but notice that > it's similar to Roman's report of an rwlock-related panic. Was there a > locking/scheduling change in the last week or two in -current that could > explain these symptoms? I still have the vmcore from the crash... can it help? From owner-freebsd-current@FreeBSD.ORG Fri Dec 12 13:41:40 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7B1181065678; Fri, 12 Dec 2008 13:41:40 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.terabit.net.ua (mail.terabit.net.ua [195.137.202.147]) by mx1.freebsd.org (Postfix) with ESMTP id D70E38FC1B; Fri, 12 Dec 2008 13:41:39 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from skuns.zoral.com.ua ([91.193.166.194] helo=mail.zoral.com.ua) by mail.terabit.net.ua with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63 (FreeBSD)) (envelope-from ) id 1LB8Gv-0008X3-TJ; Fri, 12 Dec 2008 15:41:38 +0200 Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id mBCDfUKM061875 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 12 Dec 2008 15:41:30 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3) with ESMTP id mBCDfTLm097664; Fri, 12 Dec 2008 15:41:30 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3/Submit) id mBCDfTOC097663; Fri, 12 Dec 2008 15:41:29 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 12 Dec 2008 15:41:29 +0200 From: Kostik Belousov To: David Wolfskill , hackers@freebsd.org, current@freebsd.org Message-ID: <20081212134129.GD2038@deviant.kiev.zoral.com.ua> References: <20081203001538.GC96383@bunrab.catwhisker.org> <20081209190110.GW60731@albert.catwhisker.org> <20081210165022.GJ60731@albert.catwhisker.org> <20081210170620.GS2038@deviant.kiev.zoral.com.ua> <20081211225349.GB5597@albert.catwhisker.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ZPyQn7mfIBXOql8K" Content-Disposition: inline In-Reply-To: <20081211225349.GB5597@albert.catwhisker.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua X-Virus-Scanned: mail.terabit.net.ua 1LB8Gv-0008X3-TJ b4c2b8acd62b5bbc628e5797911f2a14 X-Terabit: YES Cc: Subject: Re: NFS (& amd?) dysfunction descending a hierarchy X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Dec 2008 13:41:40 -0000 --ZPyQn7mfIBXOql8K Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Dec 11, 2008 at 02:53:49PM -0800, David Wolfskill wrote: > On Wed, Dec 10, 2008 at 07:06:20PM +0200, Kostik Belousov wrote: > > ... > > > What concerns me is that even if the attempted unmount gets EBUSY, the > > > user-level process descending the directory hierarchy is getting ENOE= NT > > > trying to issue fstatfs() against an open file descriptor. > > >=20 > > > I'm having trouble figuring out any way that makes any sense. > >=20 > > Basically, the problem is that NFS uses shared lookup, and this allows > > for the bug where several negative namecache entries are created for > > non-existent node. Then this node gets created, removing only the first > > negative namecache entry. For some reasons, vnode is reclaimed; amd' > > tasting of unmount is a good reason for vnode to be reclaimed. > >=20 > > Now, you have existing path and a negative cache entry. This was > > reported by Peter Holm first, I listed relevant revisions that > > should fix this in previous mail. >=20 > Well, I messed up the machine I had been using for testing, and needed > to wait for IT to do something to it since I don't have physical or > console access to it. >=20 > So after I happened to demonstrate the effect using my desktop -- which > had been running RELENG_7_1, sources updated as of around 0400 hrs. > US/Pacific -- I decided to go ahead and update the desktop to RELENG_7_1 > as of this morning (which had the commit to sys/kern/vfs_cache.c), then > test. >=20 > It still failed, apparently in the same way; details below. >=20 > First, here's a list of the files that were changed: >=20 > U lib/libarchive/archive_read_support_format_iso9660.c > U lib/libarchive/archive_string.c > U lib/libarchive/archive_string.h > U lib/libc/gen/times.3 > U lib/libc/i386/sys/pipe.S > U lib/libc/i386/sys/reboot.S > U lib/libc/i386/sys/setlogin.S > U lib/libutil/Makefile > U lib/libutil/kinfo_getfile.c > U lib/libutil/kinfo_getvmmap.c > U lib/libutil/libutil.h > U share/man/man4/bce.4 > U share/man/man5/Makefile > U share/man/man5/fstab.5 > U share/man/man5/nullfs.5 > U sys/amd64/Makefile > U sys/boot/forth/loader.conf.5 > U sys/dev/ale/if_ale.c > U sys/dev/bce/if_bce.c > U sys/dev/cxgb/cxgb_main.c > U sys/dev/cxgb/common/cxgb_ael1002.c > U sys/dev/cxgb/common/cxgb_t3_hw.c > U sys/dev/cxgb/common/cxgb_xgmac.c > U sys/dev/re/if_re.c > U sys/fs/nullfs/null_vnops.c > U sys/kern/Make.tags.inc > U sys/kern/kern_descrip.c > U sys/kern/kern_proc.c > U sys/kern/vfs_cache.c > U sys/netinet/in_pcb.h > U sys/pci/if_rlreg.h > U sys/sys/sysctl.h > U sys/sys/user.h > U sys/ufs/ufs/ufs_quota.c > U usr.bin/procstat/Makefile > U usr.bin/procstat/procstat_files.c > U usr.bin/procstat/procstat_vm.c > U usr.bin/tar/util.c > U usr.bin/tar/test/Makefile > U usr.bin/tar/test/test_strip_components.c > U usr.bin/tar/test/test_symlink_dir.c > U usr.bin/xargs/xargs.1 > U usr.sbin/mtree/mtree.c >=20 > We see that sys/kern/vfs_cache.c is, indeed, among them. And: >=20 > dwolf-bsd(7.1-P)[5] grep '\$FreeBSD' /sys/kern/vfs_cache.c > __FBSDID("$FreeBSD: src/sys/kern/vfs_cache.c,v 1.114.2.3 2008/12/09 16:20= :58 kib Exp $"); > dwolf-bsd(7.1-P)[6]=20 >=20 > That should correspond to the desired version of the file. >=20 > Here we see an excerpt from the ktrace output for the amd(8) process and > its children; this is a point when amd(8) is trying an unmount() to see > if it can get away with it: >=20 > 977 amd 1229033597.269612 CALL gettimeofday(0x807ad48,0) > 977 amd 1229033597.269620 RET gettimeofday 0 > 977 amd 1229033597.269630 CALL sigprocmask(SIG_BLOCK,0xbfbfeaec,= 0xbfbfeadc) > 977 amd 1229033597.269637 RET sigprocmask 0 > 977 amd 1229033597.269645 CALL fork > 977 amd 1229033597.273810 RET fork 1712/0x6b0 > 1712 amd 1229033597.273811 RET fork 0 > 977 amd 1229033597.273836 CALL sigprocmask(SIG_SETMASK,0xbfbfead= c,0) > 1712 amd 1229033597.273845 CALL getpid > 977 amd 1229033597.273850 RET sigprocmask 0 > 1712 amd 1229033597.273855 RET getpid 1712/0x6b0 > 977 amd 1229033597.273864 CALL gettimeofday(0x807ad48,0) > 977 amd 1229033597.273874 RET gettimeofday 0 > 1712 amd 1229033597.273878 CALL unmount(0x2832c610,0) > ... > 1712 amd 1229033597.352643 RET unmount -1 errno 16 Device busy > 1712 amd 1229033597.352695 CALL sigprocmask(SIG_BLOCK,0x28097c00,= 0xbfbfea0c) > 1712 amd 1229033597.352728 RET sigprocmask 0 > 1712 amd 1229033597.352751 CALL sigprocmask(SIG_SETMASK,0x28097c1= 0,0) > 1712 amd 1229033597.352769 RET sigprocmask 0 > 1712 amd 1229033597.352781 CALL sigprocmask(SIG_BLOCK,0x28097c00,= 0xbfbfe9dc) > 1712 amd 1229033597.352790 RET sigprocmask 0 > 1712 amd 1229033597.352801 CALL sigprocmask(SIG_SETMASK,0x28097c1= 0,0) > 1712 amd 1229033597.352805 RET sigprocmask 0 > 1712 amd 1229033597.352815 CALL exit(0x10) > 977 amd 1229033597.353085 RET select -1 errno 4 Interrupted sys= tem call > 977 amd 1229033597.353093 PSIG SIGCHLD caught handler=3D0x805de5= 0 mask=3D0x0 code=3D0x0 > 977 amd 1229033597.353103 CALL wait4(0xffffffff,0xbfbfe83c,WNOHA= NG,0) > 977 amd 1229033597.353116 RET wait4 1712/0x6b0 > 977 amd 1229033597.353122 CALL wait4(0xffffffff,0xbfbfe83c,WNOHA= NG,0) > 977 amd 1229033597.353127 RET wait4 -1 errno 10 No child proces= ses >=20 >=20 > So amd(8) master process (pid 977) jorks off a child (pid 1712) to > try an umount(), which it initiates at 1229033597.273878. At > 1229033597.352643 the child gets control back, as well as an EBUSY, > which I would expect to mean that the attempt failed. The child > exits at 1229033597.352815 with a status code of 16. >=20 > Armed with that, we look at a ktrace excerpt from "rm -fr": >=20 > 1660 rm 1229033597.283277 CALL rmdir(0x2822b388) > 1660 rm 1229033597.283283 NAMI "stvef-paks" > 1660 rm 1229033597.285599 RET rmdir 0 > 1660 rm 1229033597.285620 CALL stat(0x2822b3e8,0xbfbfe8dc) > 1660 rm 1229033597.285626 NAMI "stvef-server" > 1660 rm 1229033597.286071 STRU struct stat {dev=3D83951372, ino= =3D20124614, mode=3Ddrwxr-xr-x , nlink=3D3, uid=3D9874, gid=3D929, rdev=3D0= , atime=3D1228844788, stime=3D1227555769, ctime=3D1228845828.326650000, bir= thtime=3D0, size=3D4096, blksize=3D4096, blocks=3D8, flags=3D0x0 } > 1660 rm 1229033597.286078 RET stat 0 > 1660 rm 1229033597.286084 CALL open(0x2822b3e8,O_NONBLOCK,0x1) > 1660 rm 1229033597.286091 NAMI "stvef-server" > 1660 rm 1229033597.287145 RET open 4 > 1660 rm 1229033597.287154 CALL fstat(0x4,0xbfbfe8dc) > 1660 rm 1229033597.287161 STRU struct stat {dev=3D83951372, ino= =3D20124614, mode=3Ddrwxr-xr-x , nlink=3D3, uid=3D9874, gid=3D929, rdev=3D0= , atime=3D1228844788, stime=3D1227555769, ctime=3D1228845828.326650000, bir= thtime=3D0, size=3D4096, blksize=3D4096, blocks=3D8, flags=3D0x0 } > 1660 rm 1229033597.287166 RET fstat 0 > 1660 rm 1229033597.287171 CALL fcntl(0x4,F_SETFD,FD_CLOEXEC) > 1660 rm 1229033597.287177 RET fcntl 0 > 1660 rm 1229033597.287187 CALL fstatfs(0x4,0xbfbfe704) > 1660 rm 1229033597.287195 RET fstatfs -1 errno 2 No such file o= r directory > 1660 rm 1229033597.287202 CALL close(0x4) > 1660 rm 1229033597.287211 RET close 0 >=20 > [Sorry for the long lines....] >=20 > Here we see that the "rm" process (pid 1660) removed a directory > named stvef-paks sucessfully in the interval between 1229033597.283277 > (when the request was made) and 1229033597.285599 (when the 0 return > occurred). The "rm" process proceeds to process a directory named > stvef-server: >=20 > * At 1229033597.285620 it issues a stat(); the successful return > is at 1229033597.286078. >=20 > * At 1229033597.286084 it issues an open(); the successful return > is at 1229033597.287145. The FD is 4. >=20 > * At 1229033597.287154 it issues an fstat() against FD 4; the successful > return is at 1229033597.287166. >=20 > * At 1229033597.287171 it issues an fcntl() against FD 4; the > successful return is at 1229033597.287177. >=20 > * At 1229033597.287187 it issues an fstatfs() against FD 4; the > unsuccessful return is at 1229033597.287195, claiming ENOENT. >=20 > Say WHAT??!? >=20 > I expect to be able to test a bit more promptly now. But is this error transient or permanent ? I.e., would restart of rm successful or failing ? Anyway, this error looks different too. --ZPyQn7mfIBXOql8K Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAklCagkACgkQC3+MBN1Mb4jOBgCeJtuwzLJH5kX0gUBlu2VqG/yD lzAAoK6FmV53wAKwPlQDbf0Ryd4LXsbZ =pDvh -----END PGP SIGNATURE----- --ZPyQn7mfIBXOql8K-- From owner-freebsd-current@FreeBSD.ORG Fri Dec 12 14:36:43 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CFD1A1065670; Fri, 12 Dec 2008 14:36:43 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (adsl-63-193-123-122.dsl.snfc21.pacbell.net [63.193.123.122]) by mx1.freebsd.org (Postfix) with ESMTP id 900888FC17; Fri, 12 Dec 2008 14:36:43 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.3/8.14.3) with ESMTP id mBCEahKY010819; Fri, 12 Dec 2008 06:36:43 -0800 (PST) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.3/8.14.3/Submit) id mBCEahXe010818; Fri, 12 Dec 2008 06:36:43 -0800 (PST) (envelope-from david) Date: Fri, 12 Dec 2008 06:36:43 -0800 From: David Wolfskill To: Kostik Belousov Message-ID: <20081212143643.GE5597@albert.catwhisker.org> Mail-Followup-To: David Wolfskill , Kostik Belousov , hackers@freebsd.org, current@freebsd.org References: <20081203001538.GC96383@bunrab.catwhisker.org> <20081209190110.GW60731@albert.catwhisker.org> <20081210165022.GJ60731@albert.catwhisker.org> <20081210170620.GS2038@deviant.kiev.zoral.com.ua> <20081211225349.GB5597@albert.catwhisker.org> <20081212134129.GD2038@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="0H629O+sVkh21xTi" Content-Disposition: inline In-Reply-To: <20081212134129.GD2038@deviant.kiev.zoral.com.ua> User-Agent: Mutt/1.4.2.3i Cc: hackers@freebsd.org, current@freebsd.org Subject: Re: NFS (& amd?) dysfunction descending a hierarchy X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Dec 2008 14:36:44 -0000 --0H629O+sVkh21xTi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Dec 12, 2008 at 03:41:29PM +0200, Kostik Belousov wrote: > ... > > * At 1229033597.287187 it issues an fstatfs() against FD 4; the > > unsuccessful return is at 1229033597.287195, claiming ENOENT. > >=20 > > Say WHAT??!? > ... >=20 > But is this error transient or permanent ? I.e., would restart of rm > successful or failing ? In a test yesterday, it took 3 attempts (each attempt being an invocations of "rm -fr ~bspace/ports") to actually complete removal of the hierarchy. Please note that: * Done on a locally-mounted file systen (vs. NFS), a single invocation is sufficient and terminates normally. Each of the above-cited attempts but the last terminated with a status code of 1 (as well as a whine that one or more subdirectories was not empty -- this, as a result of "rm" getting inconsistent information about the status of the file system). * Done on either a locally- or NFS-mounted file system in FreeBSD 6.x, a single invocation is sufficient and terminates normally. In other words, this is a regression. > Anyway, this error looks different too. ? From the earlier-posted results in 7.x? Not that I can tell. In each case, the amd(8) child process is forked to attempt an unmount(), tries it, gets EBUSY, and exits. Meanwhile, rm(1) is descending a directory tree. It had performed a readdir(), and had been unlinking files and performing rmdir() against empty subdirectories. It encounters an entry, issues stat(), finds that it's a subdirectory, open()s it, gets an FD, issues fstat(), gets results that match those of the earlier stat(), issues fcntl() against the FD (which returns 0), tries to issue fstatfs() against the FD *that is still open*, and gets told ENOENT. It does differ from the behavior in 8-CURRENT, in that the amd(8) child process in 8-CURRENT does not appear to get EBUSY. The behavior from rm(1)'s perspective is very similar, though. If it would help, I could try getting a ktrace from a 6.x system, but I expect it will be very boring: the amd(8) child process should get EBUSY (as it does in 7.x), and nothing else should happen, since the unmount() attempt failed. And since it failed, rm(1) doesn't get told inconsistent information, so things Just Work. I admit that I'm no expert on VFS or much of the rest of the kernel, for that matter. But what I have observed happening in recent 7.x is both wrong and a regression. Peace, david --=20 David H. Wolfskill david@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --0H629O+sVkh21xTi Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAklCdvkACgkQmprOCmdXAD0uAwCeOCN2mO3bpUGorAOu2wCSLxlY mgkAoIBbaJTfCWkCNclH+N2ADyZRPrOp =Bmdx -----END PGP SIGNATURE----- --0H629O+sVkh21xTi-- From owner-freebsd-current@FreeBSD.ORG Fri Dec 12 15:37:18 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1420C106567A for ; Fri, 12 Dec 2008 15:37:16 +0000 (UTC) (envelope-from CQG00620@nifty.ne.jp) Received: from mail.asahi-net.or.jp (mail1.asahi-net.or.jp [202.224.39.197]) by mx1.freebsd.org (Postfix) with ESMTP id D6D328FC23 for ; Fri, 12 Dec 2008 15:37:15 +0000 (UTC) (envelope-from CQG00620@nifty.ne.jp) Received: from asahi-net.jp (i223090.dynamic.ppp.asahi-net.or.jp [61.125.223.90]) by mail.asahi-net.or.jp (Postfix) with ESMTP id 3E15760FA3; Sat, 13 Dec 2008 00:37:14 +0900 (JST) Date: Sat, 13 Dec 2008 00:37:14 +0900 From: WATANABE Kazuhiro To: freebsd-current In-Reply-To: <7d6fde3d0812111253n4b8f7135n76e9cef63158943e@mail.gmail.com> References: <20081210125627.25732615CD@mail.asahi-net.or.jp> <494019AB.3020505@samsco.org> <20081211130057.B53EE5D0A4@mail.asahi-net.or.jp> <7d6fde3d0812111253n4b8f7135n76e9cef63158943e@mail.gmail.com> User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.7 Emacs/21.3 (i386--freebsd) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20081212153714.3E15760FA3@mail.asahi-net.or.jp> Cc: Garrett Cooper Subject: Re: [patch] de(4) has not worked on 8-current since Feb 13 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Dec 2008 15:37:18 -0000 Hi. I've posted a tcpdump output ("tcpdump -i de0 -w scp_local_to_remote.pcap") to the URL below. http://homepage2.nifty.com/dumb_show/unix/work/scp_local_to_remote.pcap In this output I ran "scp /boot/kernel/kernel remote_host:" on the system, and interruped it after 5 minutes (local_host = "scorpio", remote_host = "pisces"). At Thu, 11 Dec 2008 12:53:39 -0800, Garrett Cooper wrote: > On Thu, Dec 11, 2008 at 5:00 AM, WATANABE Kazuhiro wrote: > > CC'ed to freebsd-current. > > > > At Wed, 10 Dec 2008 12:34:03 -0700, > > Scott Long wrote: > >> WATANABE Kazuhiro wrote: > >> > Hi, all. > >> > > >> > My de(4) NICs has not worked on 8-current since Feb 13. > >> > > >> > > >> > >> Can you define "not worked" a little better? Does it give errors, or > >> corrupt data, or appear to not transmit and/or receive? > >> > >> Scott > > > > Thanks for your reply. I should have written more details about the > > problem... > > > > On recent 8-current, my de(4) NICs cannot send any (almost all) data > > from it. > > > > * The system boots normally. > > > > * Probing/attaching the de(4) NICs are done successfully. > > > > * The system can receive data from the other hosts. For example the > > following command was finished normally in 14 seconds: > > > > $ /usr/bin/time scp other_host:/boot/kernel/kernel . > > Password: > > kernel 100% 4717KB 471.7KB/s 00:10 > > 14.03 real 0.53 user 0.40 sys > > $ > > > > * The system cannot send any data to the other hosts. For example > > the following command was "stalled" and never finished > > (I interrupted the command after 5 minutes). None of the data were > > sent: > > > > $ /usr/bin/time scp /boot/kernel/kernel other_host: > > Password: > > kernel 1% 192KB 0.0KB/s - stalled -^CKilled by signal 2. > > 336.01 real 0.05 user 0.17 sys > > $ > > > > * The system doesn't show any error/warning messages. > > > > * I can "slogin" from the other hosts to the system, and some small > > amount of text output (ex. an output of "dmesg") are done > > successfully. But a bit large amount of text output are stopped > > after a few seconds. For example: > > > > $ ls -l /boot/kernel/kernel > > -r-xr-xr-x 1 root wheel 10975839 Dec 11 13:46 /boot/kernel/kernel > > $ hd /boot/kernel/kernel | head > > 00000000 7f 45 4c 46 01 01 01 09 00 00 00 00 00 00 00 00 |.ELF............| > > 00000010 02 00 03 00 01 00 00 00 e0 c5 46 c0 34 00 00 00 |..........F.4...| > > 00000020 58 22 92 00 00 00 00 00 34 00 20 00 05 00 28 00 |X"......4. ...(.| > > 00000030 23 00 20 00 06 00 00 00 34 00 00 00 34 00 40 c0 |#. .....4...4.@.| > > 00000040 34 00 40 c0 a0 00 00 00 a0 00 00 00 05 00 00 00 |4.@.............| > > 00000050 04 00 00 00 03 00 00 00 d4 00 00 00 d4 00 40 c0 |..............@.| > > 00000060 d4 00 40 c0 0d 00 00 00 0d 00 00 00 04 00 00 00 |..@.............| > > 00000070 01 00 00 00 01 00 00 00 00 00 00 00 00 00 40 c0 |..............@.| > > 00000080 00 00 40 c0 a0 ca 81 00 a0 ca 81 00 05 00 00 00 |..@.............| > > 00000090 00 10 00 00 01 00 00 00 a0 ca 81 00 a0 da c1 c0 |................| > > $ hd /boot/kernel/kernel > > 00000000 7f 45 4c 46 01 01 01 09 00 00 00 00 00 00 00 00 |.ELF............| > > 00000010 02 00 03 00 01 00 00 00 e0 c5 46 c0 34 00 00 00 |..........F.4...| > > 00000020 58 22 92 00 00 00 00 00 34 00 20 00 05 00 28 00 |X"......4. ...(.| > > 00000030 23 00 20 00 06 00 00 00 34 00 00 00 34 00 40 c0 |#. .....4...4.@.| > > 00000040 34 00 40 c0 a0 00 00 00 a0 00 00 00 05 00 00 00 |4.@.............| > > (snip) > > 00005d90 0a 20 00 00 0b 00 00 00 00 00 00 00 70 15 00 00 |. ..........p...| > > 00005da0 ce 2a 00 00 36 23 00 00 c6 2a 00 00 0b 14 00 00 |.*..6#...*......| > > 00005db0 7c 03 00 00 b1 27 00 00 d9 1e 00 00 2e 15 00 00 ||....'..........| > > 00005dc0 00 00 00 00 6d 22 00 00 04 2a 00 00 72 23 00 00 |....m"...*..r#..| > > 00005dd0 00 00 00 00 00 00 00 00 d3 1f 00 00 00 00 00 00 |................| > > (Stopped here. 0x5de0 == 24032 bytes) > > Hmm... definitely a TXO issue. > > msk(4) had similar problems with my chipset using an MTU of 1492 and > checksumming until I provided Pyun some data which helped him improve > the driver code for the chipset. > > Probably not the case here, but are there any tcpdump sessions with > raw frames that we could get to help traceback the cause? > > Thanks, > -Garrett --- WATANABE Kazuhiro (CQG00620@nifty.ne.jp) From owner-freebsd-current@FreeBSD.ORG Fri Dec 12 15:42:32 2008 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 526E61065672; Fri, 12 Dec 2008 15:42:32 +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 2CA988FC1D; Fri, 12 Dec 2008 15:42:32 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTP id DDA5C46B0D; Fri, 12 Dec 2008 10:42:31 -0500 (EST) Date: Fri, 12 Dec 2008 15:42:31 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Roman Divacky In-Reply-To: <20081212112030.GA74265@freebsd.org> Message-ID: References: <4940A685.7040608@psg.com> <494216C2.7080606@kkip.pl> <20081212095238.GY2038@deviant.kiev.zoral.com.ua> <20081212112030.GA74265@freebsd.org> User-Agent: Alpine 1.10 (BSF 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Kostik Belousov , Randy Bush , Bartosz Stec , FreeBSD Current Subject: Re: panic: sleeping thread & bufwrite: buffer is not busy??? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Dec 2008 15:42:32 -0000 On Fri, 12 Dec 2008, Roman Divacky wrote: >>> You are mixing the issues without a reason. To claim that you problem is >>> similar, you need to show the similar backtrace. The panic shown is the >>> late manifestation of a problem, it is kind a catch-all for some sort of >>> locking issues. >> >> This is the second report of weird rwlock-related panics in a week. We >> should read the code on this one closely, but I can't help but notice that >> it's similar to Roman's report of an rwlock-related panic. Was there a >> locking/scheduling change in the last week or two in -current that could >> explain these symptoms? > > I still have the vmcore from the crash... can it help? I think the most important thing is to see the contents of *inp and *inp->inp_lock.lock_object. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-current@FreeBSD.ORG Fri Dec 12 15:49:09 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ADF4D1065675; Fri, 12 Dec 2008 15:49:09 +0000 (UTC) (envelope-from andrew@atrens.ca) Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by mx1.freebsd.org (Postfix) with ESMTP id 51F308FC1B; Fri, 12 Dec 2008 15:49:09 +0000 (UTC) (envelope-from andrew@atrens.ca) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP ID DSNKSUKH9HgEe4Ll2jpCsBz9XYf53YSFu9/Z@postini.com; Fri, 12 Dec 2008 07:49:09 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.311.2; Fri, 12 Dec 2008 07:46:40 -0800 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 12 Dec 2008 07:46:40 -0800 Received: from antipi.jnpr.net ([10.10.2.34]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 12 Dec 2008 07:46:40 -0800 Received: from proton.jnpr.net ([10.10.2.37]) by antipi.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 12 Dec 2008 10:46:39 -0500 Received: from mikisew.jnpr.net ([10.227.1.182]) by proton.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 12 Dec 2008 10:46:38 -0500 Message-ID: <4942879F.1040601@atrens.ca> Date: Fri, 12 Dec 2008 10:47:43 -0500 From: Andrew Atrens User-Agent: Thunderbird 2.0.0.17pre (X11/20081001) MIME-Version: 1.0 To: Sam Leffler References: <493418EA.7020602@freebsd.org> In-Reply-To: <493418EA.7020602@freebsd.org> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Dec 2008 15:46:38.0240 (UTC) FILETIME=[D1C7E200:01C95C70] Cc: freebsd-current@freebsd.org Subject: Re: HEADS UP: r185522 - in head: . share/man/man4 sys/amd64/conf sys/arm/conf sys/conf sys/contrib/dev/ath sys/dev/ath sys/dev/ath/ath_rate/amrr sys/dev/ath/ath_rate/onoe sys/dev/ath/ath_rate/sample ... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Dec 2008 15:49:09 -0000 Hi Sam, I'm noticing that regdomain support for 'FCCB' appears to be included but is not hooked in to a countrycode yet. I've made the (very simple) changes myself and the kernel appears to be sane though I haven't yet attempted a connection at 10 or 5 Mhz, 20Mhz definitely still works .. $ ifconfig -v ath0 list channels Channel 1 : 2412 Mhz 11b Channel 6 : 2437 Mhz 11g/10Mhz Channel 1 : 2412 Mhz 11g Channel 6 : 2437 Mhz 11g/5Mhz Channel 1 : 2412 Mhz 11g/10Mhz Channel 7 : 2442 Mhz 11b Channel 1 : 2412 Mhz 11g/5Mhz Channel 7 : 2442 Mhz 11g Channel 2 : 2417 Mhz 11b Channel 7 : 2442 Mhz 11g/10Mhz Channel 2 : 2417 Mhz 11g Channel 7 : 2442 Mhz 11g/5Mhz Channel 2 : 2417 Mhz 11g/10Mhz Channel 8 : 2447 Mhz 11b Channel 2 : 2417 Mhz 11g/5Mhz Channel 8 : 2447 Mhz 11g Channel 3 : 2422 Mhz 11b Channel 8 : 2447 Mhz 11g/10Mhz Channel 3 : 2422 Mhz 11g Channel 8 : 2447 Mhz 11g/5Mhz Channel 3 : 2422 Mhz 11g/10Mhz Channel 9 : 2452 Mhz 11b Channel 3 : 2422 Mhz 11g/5Mhz Channel 9 : 2452 Mhz 11g Channel 4 : 2427 Mhz 11b Channel 9 : 2452 Mhz 11g/10Mhz Channel 4 : 2427 Mhz 11g Channel 9 : 2452 Mhz 11g/5Mhz Channel 4 : 2427 Mhz 11g/10Mhz Channel 10 : 2457 Mhz 11b Channel 4 : 2427 Mhz 11g/5Mhz Channel 10 : 2457 Mhz 11g Channel 5 : 2432 Mhz 11b Channel 10 : 2457 Mhz 11g/10Mhz Channel 5 : 2432 Mhz 11g Channel 10 : 2457 Mhz 11g/5Mhz Channel 5 : 2432 Mhz 11g/10Mhz Channel 11 : 2462 Mhz 11b Channel 5 : 2432 Mhz 11g/5Mhz Channel 11 : 2462 Mhz 11g Channel 6 : 2437 Mhz 11b Channel 11 : 2462 Mhz 11g/10Mhz Channel 6 : 2437 Mhz 11g Channel 11 : 2462 Mhz 11g/5Mhz Channel 6 : 2437 Mhz 11g Turbo Since it appears that everything is in place to support it, I'm curious whether there is some technical or regulatory/legal reason that this hasn't yet been done .. I'm not sure of all of the tradeoffs of 5Mhz/10Mhz channels @2GHz, I know that one downside is that likely only ofdm modulations will work, an obvious one is that you'd lose half the bandwidth. On the positive side I suspect (as is the case for 900Mhz) one's noise immunity may change (improve?), and perhaps my signal may get a bit more 'punch' as on the access side I'm firing through a fair bit of foliage. Cheers, --Andrew From owner-freebsd-current@FreeBSD.ORG Fri Dec 12 17:15:34 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 42CFB106564A for ; Fri, 12 Dec 2008 17:15:34 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id 083318FC1E for ; Fri, 12 Dec 2008 17:15:33 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from trouble.errno.com (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id mBCHFVes086305 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 12 Dec 2008 09:15:31 -0800 (PST) (envelope-from sam@freebsd.org) Message-ID: <49429C33.9030300@freebsd.org> Date: Fri, 12 Dec 2008 09:15:31 -0800 From: Sam Leffler Organization: FreeBSD Project User-Agent: Thunderbird 2.0.0.9 (X11/20071125) MIME-Version: 1.0 To: Andrew Atrens References: <493418EA.7020602@freebsd.org> <4942879F.1040601@atrens.ca> In-Reply-To: <4942879F.1040601@atrens.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-DCC--Metrics: ebb.errno.com; whitelist Cc: freebsd-current@freebsd.org Subject: Re: HEADS UP: r185522 - in head: . share/man/man4 sys/amd64/conf sys/arm/conf sys/conf sys/contrib/dev/ath sys/dev/ath sys/dev/ath/ath_rate/amrr sys/dev/ath/ath_rate/onoe sys/dev/ath/ath_rate/sample ... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Dec 2008 17:15:34 -0000 Andrew Atrens wrote: > Hi Sam, > > I'm noticing that regdomain support for 'FCCB' appears to be included > but is not hooked in to a countrycode yet. I've made the (very simple) > changes myself and the kernel appears to be sane though I haven't yet > attempted a connection at 10 or 5 Mhz, 20Mhz definitely still works .. > > $ ifconfig -v ath0 list channels > Channel 1 : 2412 Mhz 11b Channel 6 : 2437 Mhz 11g/10Mhz > Channel 1 : 2412 Mhz 11g Channel 6 : 2437 Mhz 11g/5Mhz > Channel 1 : 2412 Mhz 11g/10Mhz Channel 7 : 2442 Mhz 11b > Channel 1 : 2412 Mhz 11g/5Mhz Channel 7 : 2442 Mhz 11g > Channel 2 : 2417 Mhz 11b Channel 7 : 2442 Mhz 11g/10Mhz > Channel 2 : 2417 Mhz 11g Channel 7 : 2442 Mhz 11g/5Mhz > Channel 2 : 2417 Mhz 11g/10Mhz Channel 8 : 2447 Mhz 11b > Channel 2 : 2417 Mhz 11g/5Mhz Channel 8 : 2447 Mhz 11g > Channel 3 : 2422 Mhz 11b Channel 8 : 2447 Mhz 11g/10Mhz > Channel 3 : 2422 Mhz 11g Channel 8 : 2447 Mhz 11g/5Mhz > Channel 3 : 2422 Mhz 11g/10Mhz Channel 9 : 2452 Mhz 11b > Channel 3 : 2422 Mhz 11g/5Mhz Channel 9 : 2452 Mhz 11g > Channel 4 : 2427 Mhz 11b Channel 9 : 2452 Mhz 11g/10Mhz > Channel 4 : 2427 Mhz 11g Channel 9 : 2452 Mhz 11g/5Mhz > Channel 4 : 2427 Mhz 11g/10Mhz Channel 10 : 2457 Mhz 11b > Channel 4 : 2427 Mhz 11g/5Mhz Channel 10 : 2457 Mhz 11g > Channel 5 : 2432 Mhz 11b Channel 10 : 2457 Mhz 11g/10Mhz > Channel 5 : 2432 Mhz 11g Channel 10 : 2457 Mhz 11g/5Mhz > Channel 5 : 2432 Mhz 11g/10Mhz Channel 11 : 2462 Mhz 11b > Channel 5 : 2432 Mhz 11g/5Mhz Channel 11 : 2462 Mhz 11g > Channel 6 : 2437 Mhz 11b Channel 11 : 2462 Mhz 11g/10Mhz > Channel 6 : 2437 Mhz 11g Channel 11 : 2462 Mhz 11g/5Mhz > Channel 6 : 2437 Mhz 11g Turbo > > Since it appears that everything is in place to support it, I'm > curious whether there is some technical or regulatory/legal reason > that this hasn't yet been done .. > > I'm not sure of all of the tradeoffs of 5Mhz/10Mhz channels @2GHz, I > know that one downside is that likely only ofdm modulations will work, > an obvious one is that you'd lose half the bandwidth. > > On the positive side I suspect (as is the case for 900Mhz) one's noise > immunity may change (improve?), and perhaps my signal may get a bit > more 'punch' as on the access side I'm firing through a fair bit of > foliage. > FCCB was added solely for testing 1/2 and 1/4 width channel support in 2.4G; hence the lack of a public hookup. I can't advise you on regulatory issues. Given the shortage of spectrum in the 2.4 band I can imagine folks doing outdoor applications might find this useful. Sam From owner-freebsd-current@FreeBSD.ORG Fri Dec 12 17:49:15 2008 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3C8701065676 for ; Fri, 12 Dec 2008 17:49:15 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout015.mac.com (asmtpout015.mac.com [17.148.16.90]) by mx1.freebsd.org (Postfix) with ESMTP id 20D668FC14 for ; Fri, 12 Dec 2008 17:49:15 +0000 (UTC) (envelope-from xcllnt@mac.com) MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_tkBOjEQzhdlx2dQU1fqXQA)" Received: from sbansal-mbp.jnpr.net (natint3.juniper.net [66.129.224.36]) by asmtp015.mac.com (Sun Java(tm) System Messaging Server 6.3-7.03 (built Aug 7 2008; 32bit)) with ESMTPSA id <0KBR00827YTMV310@asmtp015.mac.com> for freebsd-current@FreeBSD.org; Fri, 12 Dec 2008 09:48:59 -0800 (PST) Message-id: <9939E942-A2FC-4240-BC14-527D45C187B7@mac.com> From: Marcel Moolenaar To: Boris Samorodov In-reply-to: <94539778@bb.ipt.ru> Date: Fri, 12 Dec 2008 09:48:58 -0800 References: <92804393@bb.ipt.ru> <26722819@bb.ipt.ru> <26719629@bb.ipt.ru> <19F75E66-0535-4982-9726-E2C0A03117EA@mac.com> <94541668@bb.ipt.ru> <48144979@bb.ipt.ru> <548CF0A3-1B07-49DA-A177-6EA85FD8CF2F@mac.com> <94539778@bb.ipt.ru> X-Mailer: Apple Mail (2.929.2) Cc: freebsd-current@FreeBSD.org, rea-fbsd@codelabs.ru Subject: Re: Timeda 8-multiport adapter: only 2 ports available X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Dec 2008 17:49:15 -0000 --Boundary_(ID_tkBOjEQzhdlx2dQU1fqXQA) Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-transfer-encoding: 7BIT On Dec 12, 2008, at 2:37 AM, Boris Samorodov wrote: > I may say that SUN1889 uarts are initialized like default. And indeed > two first ports work here. The card contains only one SUN1889 chip > (for > two first ports). All other chips are SUN1699 which (better to say > serial ports) should be initialized with the flag > SUN1699_CLK_DIVIDER_DISABLE (0x10). > > Don't know how/where to do it. :-( Since it's puc(4) that has the visibility, it's puc(4) that should pre-initialize the IER register for ports that need special treatment. Then later when uart(4) probes and attaches, we need to make sure that uart(4) doesn't mess up the settings, but other than that it does not need to know. Unfortunately, there's no existing configuration command for this sort of thing. In particular, you want to pass the resource corresponding to the port to the config function so that it can talk to the hardware without kluges. The attached patch is a quick and dirty way to program the ports. Can you see if it actually works and if it makes a difference? -- Marcel Moolenaar xcllnt@mac.com --Boundary_(ID_tkBOjEQzhdlx2dQU1fqXQA) Content-type: application/octet-stream; x-unix-mode=0644; name=puc.diff Content-transfer-encoding: 7bit Content-disposition: attachment; filename=puc.diff Index: pucdata.c =================================================================== --- pucdata.c (revision 185784) +++ pucdata.c (working copy) @@ -1145,6 +1145,10 @@ case PUC_CFG_GET_TYPE: *res = PUC_TYPE_SERIAL; return (0); + case PUC_CFG_INIT_PORT: + bus_write_1((struct res *)res, 1 /* IER */, + (port >= 2) ? 0x10 : 0); + return (0); default: break; } Index: puc_cfg.c =================================================================== --- puc_cfg.c (revision 185784) +++ puc_cfg.c (working copy) @@ -166,6 +166,8 @@ } *r = PUC_TYPE_SERIAL; return (0); + case PUC_CFG_INIT_PORT: + return (0); case PUC_CFG_SETUP: *r = ENXIO; return (0); Index: puc.c =================================================================== --- puc.c (revision 185784) +++ puc.c (working copy) @@ -296,6 +296,9 @@ goto fail; port->p_rclk = res; + (void)puc_config(sc, PUC_CFG_INIT_PORT, idx, + (void *)port->p_rres); + port->p_dev = device_add_child(dev, NULL, -1); if (port->p_dev != NULL) device_set_ivars(port->p_dev, (void *)port); Index: puc_cfg.h =================================================================== --- puc_cfg.h (revision 185784) +++ puc_cfg.h (working copy) @@ -62,6 +62,7 @@ PUC_CFG_GET_OFS, PUC_CFG_GET_RID, PUC_CFG_GET_TYPE, + PUC_CFG_INIT_PORT, PUC_CFG_SETUP }; --Boundary_(ID_tkBOjEQzhdlx2dQU1fqXQA)-- From owner-freebsd-current@FreeBSD.ORG Fri Dec 12 20:08:44 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 884F61065670 for ; Fri, 12 Dec 2008 20:08:44 +0000 (UTC) (envelope-from dgerow@afflictions.org) Received: from relay3-v.mail.gandi.net (relay3-v.mail.gandi.net [217.70.178.77]) by mx1.freebsd.org (Postfix) with ESMTP id 22F998FC0C for ; Fri, 12 Dec 2008 20:08:44 +0000 (UTC) (envelope-from dgerow@afflictions.org) Received: from plebeian.afflictions.org (206-248-190-85.dsl.teksavvy.com [206.248.190.85]) by relay3-v.mail.gandi.net (Postfix) with ESMTP id A6D1ABA10 for ; Fri, 12 Dec 2008 21:08:41 +0100 (CET) Received: by plebeian.afflictions.org (Postfix, from userid 1001) id B9AAD707A; Fri, 12 Dec 2008 15:08:38 -0500 (EST) Date: Fri, 12 Dec 2008 15:08:38 -0500 From: Damian Gerow To: freebsd-current@freebsd.org Message-ID: <20081212200838.GA44353@plebeian.afflictions.org> References: <20081212054137.GA42087@plebeian.afflictions.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20081212054137.GA42087@plebeian.afflictions.org> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Panic when destroying interfaces (kern/116837?) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Dec 2008 20:08:44 -0000 When investigating panics when destroying bridge(4) and tap(4) interfaces, I'm receiving a panic suspiciously similar to what I was seeing with ural(4) and wpa_supplicant(8). (It's likely that I'm seeing two separate issues with ural(4), but only investigated the one triggered when removing one of the devices.) Looking at the panic I receive with ural: : ----- : panic: _rw_rlock (radix node head): wlock already held @ /repo/freebsd/8-CURRENT/src/sys/net/route.c: 291 : ----- I see exactly the same message when destroying bridge(4) and tap(4) virtual interfaces: ----- # kldload if_bridge # ifconfig bridge0 create bridge0: Ethernet address: e6:02:10:1c:bc:22 # ifconfig bridge0 destroy panic: _rw_rlock (radix node head): wlock already held @ /repo/freebsd/8-CURRENT/src/sys/net/route.c: 291 ----- The actual panic is exactly the same for bridge(4) and tap(4), save two specific lines. Here's a bridge(4) dump, copied by hand, as I was unable to coax db into a dump (pid 47662 is ifconfig): ----- cpuid = 1 KDB: enter: panic [thread pid 47662 tid 100145] Stopped at kdb_enter+0x3d: movq $0:0xb2d8c5(%rip) db> where Tracing pid 47662 tid 100145 td 0xffffff000a02a000 kdb_enter() at kdb_enter+0x3d panic() at panic+0x1c8 _rw_rlock() at _rw_rlock+0x78 rtalloc1_fib() at rtalloc1_fib+0x4c rtalloc1() at rtalloc1+0xe in6_ifdetach() at in6_ifdetach+0x45d if_detach() at if_detach+0x112 ether_ifdetach() at ether_ifdetach+0x41 bridge_clone_destroy() at bridge_clone_destroy+0x125 ifc_simple_destroy() at ifc_simple_destroy+0x22 if_clone_destroyif() at if_clone_destroyif+0xde if_clone_destroy() at if_clone_destroy+0x8d ifioctl() at ifioctl+0x10e soo_ioctl() at soo_ioctl+0x33f kern_ioctl() at kern_ioctl+0x1a5 ioctl() at ioctl()+0x158 syscall() at syscall()+0x2e9 Xfast_syscall() at Xfast_syscall+0xab --- syscall (54, FreeBSD ELF64, ioctl), rip = 0x800a5a09c, rsp = 0x7fffffffe398, rbp = 0x7fffffffee29 --- ----- The two lines that change with a tap(4) panic are the lines starting, "bridge_clone_destroy" and "--- sysctall". They are, instead: ----- tap_destroy() at tap_destroy+0x2d --- syscall (54, FreeBSD ELF64, ioctl), rip = 0x800a5a09c, rsp = 0x7fffffffe398, rbp = 0x7fffffffee2e --- ----- After taking a better look through the PR database, this seems to be the same thing as kern/116837, which hasn't been touched since February. I'll be taking a look at the proposed patch to see if I can modify it for bridge(4) and tap(4), unless there's something bigger going on, as this seems to affect a number of different interface types: at least bridge(4) and tap(4); possibly ural(4) and wlan(4) as well. - Damian From owner-freebsd-current@FreeBSD.ORG Fri Dec 12 20:17:08 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 34A6F1065673 for ; Fri, 12 Dec 2008 20:17:08 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: from pele.citylink.co.nz (pele.citylink.co.nz [202.8.44.226]) by mx1.freebsd.org (Postfix) with ESMTP id EFFE88FC13 for ; Fri, 12 Dec 2008 20:17:07 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: from localhost (localhost [127.0.0.1]) by pele.citylink.co.nz (Postfix) with ESMTP id 89834FF01; Sat, 13 Dec 2008 09:17:06 +1300 (NZDT) X-Virus-Scanned: Debian amavisd-new at citylink.co.nz Received: from pele.citylink.co.nz ([127.0.0.1]) by localhost (pele.citylink.co.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yV8Z1NlNga1q; Sat, 13 Dec 2008 09:17:02 +1300 (NZDT) Received: from citylink.fud.org.nz (unknown [202.8.44.45]) by pele.citylink.co.nz (Postfix) with ESMTP; Sat, 13 Dec 2008 09:17:02 +1300 (NZDT) Received: by citylink.fud.org.nz (Postfix, from userid 1001) id 1F45A1142E; Sat, 13 Dec 2008 09:17:02 +1300 (NZDT) Date: Fri, 12 Dec 2008 12:17:01 -0800 From: Andrew Thompson To: Damian Gerow Message-ID: <20081212201701.GA9491@citylink.fud.org.nz> References: <20081212054137.GA42087@plebeian.afflictions.org> <20081212200838.GA44353@plebeian.afflictions.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20081212200838.GA44353@plebeian.afflictions.org> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: freebsd-current@freebsd.org Subject: Re: Panic when destroying interfaces (kern/116837?) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Dec 2008 20:17:08 -0000 On Fri, Dec 12, 2008 at 03:08:38PM -0500, Damian Gerow wrote: > When investigating panics when destroying bridge(4) and tap(4) interfaces, > I'm receiving a panic suspiciously similar to what I was seeing with ural(4) > and wpa_supplicant(8). > > (It's likely that I'm seeing two separate issues with ural(4), but only > investigated the one triggered when removing one of the devices.) > > Looking at the panic I receive with ural: > > : ----- > : panic: _rw_rlock (radix node head): wlock already held @ /repo/freebsd/8-CURRENT/src/sys/net/route.c: 291 > : ----- > > I see exactly the same message when destroying bridge(4) and tap(4) virtual > interfaces: > > ----- > # kldload if_bridge > # ifconfig bridge0 create > bridge0: Ethernet address: e6:02:10:1c:bc:22 > # ifconfig bridge0 destroy > > panic: _rw_rlock (radix node head): wlock already held @ /repo/freebsd/8-CURRENT/src/sys/net/route.c: 291 > ----- This is now fixed, just update. Andrew From owner-freebsd-current@FreeBSD.ORG Fri Dec 12 20:25:13 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 160321065672 for ; Fri, 12 Dec 2008 20:25:13 +0000 (UTC) (envelope-from dgerow@afflictions.org) Received: from relay4-v.mail.gandi.net (relay4-v.mail.gandi.net [217.70.178.78]) by mx1.freebsd.org (Postfix) with ESMTP id CF3178FC38 for ; Fri, 12 Dec 2008 20:25:12 +0000 (UTC) (envelope-from dgerow@afflictions.org) Received: from plebeian.afflictions.org (206-248-190-85.dsl.teksavvy.com [206.248.190.85]) by relay4-v.mail.gandi.net (Postfix) with ESMTP id 911C6BA17 for ; Fri, 12 Dec 2008 21:25:10 +0100 (CET) Received: by plebeian.afflictions.org (Postfix, from userid 1001) id 6B26170F4; Fri, 12 Dec 2008 15:24:53 -0500 (EST) Date: Fri, 12 Dec 2008 15:24:53 -0500 From: Damian Gerow To: freebsd-current@freebsd.org Message-ID: <20081212202453.GB44353@plebeian.afflictions.org> References: <20081212054137.GA42087@plebeian.afflictions.org> <20081212200838.GA44353@plebeian.afflictions.org> <20081212201701.GA9491@citylink.fud.org.nz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20081212201701.GA9491@citylink.fud.org.nz> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: Panic when destroying interfaces (kern/116837?) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Dec 2008 20:25:13 -0000 Andrew Thompson wrote: : This is now fixed, just update. Great, thanks! From owner-freebsd-current@FreeBSD.ORG Fri Dec 12 20:27:30 2008 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B849C1065678; Fri, 12 Dec 2008 20:27:30 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (unknown [IPv6:2a01:170:102f::2]) by mx1.freebsd.org (Postfix) with ESMTP id 3DE708FC2C; Fri, 12 Dec 2008 20:27:30 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (localhost [127.0.0.1]) by lurza.secnetix.de (8.14.3/8.14.3) with ESMTP id mBCKRRAU011008; Fri, 12 Dec 2008 21:27:28 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.14.3/8.14.3/Submit) id mBCKRRZt011007; Fri, 12 Dec 2008 21:27:27 +0100 (CET) (envelope-from olli) Date: Fri, 12 Dec 2008 21:27:27 +0100 (CET) Message-Id: <200812122027.mBCKRRZt011007@lurza.secnetix.de> From: Oliver Fromme To: freebsd-current@FreeBSD.ORG, freebsd-usb@FreeBSD.ORG X-Newsgroups: list.freebsd-current User-Agent: tin/1.8.3-20070201 ("Scotasay") (UNIX) (FreeBSD/6.4-PRERELEASE-20080904 (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Fri, 12 Dec 2008 21:27:28 +0100 (CET) Cc: Subject: usb2 + scanner HP ScanJet 4300C X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Dec 2008 20:27:30 -0000 Hi, I've got a HP ScanJet 4300C that seems to be a little bit stubborn. It doesn't work with the old USB code, so I updated to 8-current and compiled a kernel with the new usb2 drivers. Now I get: usb2_alloc_device:1590: Failure selecting configuration index 0: USB_ERR_TIMEOUT, port 2, addr 2 ugen0.2: at usbus0 uhub_reattach_port:402: could not allocate new device! "usbconfig list" says: ugen0.1: at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON ugen1.1: at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON Is there anything I can do, except for forgetting about this scanner alltogether? (The scanner does have an LPT connector, but the computer does not. I assume that the scanner wouldn't work with a USB-printer adapter either, because SANE probably only works with "real" LPT ports.) Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mn- chen, HRB 125758, Geschftsfhrer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "One of the main causes of the fall of the Roman Empire was that, lacking zero, they had no way to indicate successful termination of their C programs." -- Robert Firth From owner-freebsd-current@FreeBSD.ORG Fri Dec 12 20:36:33 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1EA03106570A; Fri, 12 Dec 2008 20:36:33 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe08.swip.net [212.247.154.225]) by mx1.freebsd.org (Postfix) with ESMTP id 7F0A38FC1B; Fri, 12 Dec 2008 20:36:32 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=P3SC899gXHkOLDnkTYxLZw==:17 a=G9fvKB-1MRFWVLZUkH8A:9 a=hYCaWgoOe3TXl_HFMUkkMbs7dxcA:4 a=LY0hPdMaydYA:10 Received: from [62.113.133.240] (account mc467741@c2i.net [62.113.133.240] verified) by mailfe08.swip.net (CommuniGate Pro SMTP 5.2.6) with ESMTPA id 1163200011; Fri, 12 Dec 2008 21:36:30 +0100 From: Hans Petter Selasky To: freebsd-usb@freebsd.org Date: Fri, 12 Dec 2008 21:38:44 +0100 User-Agent: KMail/1.9.7 References: <200812122027.mBCKRRZt011007@lurza.secnetix.de> In-Reply-To: <200812122027.mBCKRRZt011007@lurza.secnetix.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200812122138.45325.hselasky@c2i.net> Cc: freebsd-current@freebsd.org, Oliver Fromme Subject: Re: usb2 + scanner HP ScanJet 4300C X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Dec 2008 20:36:33 -0000 On Friday 12 December 2008, Oliver Fromme wrote: > usb2_alloc_device: You could try to edit the code in "sys/dev/usb2/core/usb2_device.c" and loop two times on the set_config command in "usb2_alloc_device()". Or you can try to make the code ignore the return value from the failing set_config command. Also try to turn on more debugging: sysctl hw.usb2.debug=15 --HPS From owner-freebsd-current@FreeBSD.ORG Fri Dec 12 22:15:05 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 535E01065675; Fri, 12 Dec 2008 22:15:05 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.9.129]) by mx1.freebsd.org (Postfix) with ESMTP id 19EF48FC12; Fri, 12 Dec 2008 22:15:04 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id B7E5473098; Fri, 12 Dec 2008 23:04:28 +0100 (CET) Date: Fri, 12 Dec 2008 23:04:28 +0100 From: Luigi Rizzo To: Oliver Fromme Message-ID: <20081212220428.GB64751@onelab2.iet.unipi.it> References: <200812122027.mBCKRRZt011007@lurza.secnetix.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200812122027.mBCKRRZt011007@lurza.secnetix.de> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org, freebsd-usb@freebsd.org Subject: Re: usb2 + scanner HP ScanJet 4300C X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Dec 2008 22:15:05 -0000 On Fri, Dec 12, 2008 at 09:27:27PM +0100, Oliver Fromme wrote: > Hi, > > I've got a HP ScanJet 4300C that seems to be a little bit > stubborn. > ... > Is there anything I can do, except for forgetting about > this scanner alltogether? one option is to put the device IDs in uscanner.c and see if it is recognised. But other than that, i wouldn't waste much time: for 50..80 euro you can get one of the Epson multifunction printer scanners (i have personally tried DX4400 to DX7050) which are well supported and extremely reliable. see http://info.iet.unipi.it/~luigi/FreeBSD/dx5050.html cheers luigi From owner-freebsd-current@FreeBSD.ORG Fri Dec 12 23:15:14 2008 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8F5A21065672; Fri, 12 Dec 2008 23:15:14 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (unknown [IPv6:2a01:170:102f::2]) by mx1.freebsd.org (Postfix) with ESMTP id 12ECA8FC19; Fri, 12 Dec 2008 23:15:13 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (localhost [127.0.0.1]) by lurza.secnetix.de (8.14.3/8.14.3) with ESMTP id mBCNFBg6018008; Sat, 13 Dec 2008 00:15:11 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.14.3/8.14.3/Submit) id mBCNFBTj018007; Sat, 13 Dec 2008 00:15:11 +0100 (CET) (envelope-from olli) Date: Sat, 13 Dec 2008 00:15:11 +0100 (CET) Message-Id: <200812122315.mBCNFBTj018007@lurza.secnetix.de> From: Oliver Fromme To: freebsd-current@FreeBSD.ORG, freebsd-usb@FreeBSD.ORG, hselasky@c2i.net In-Reply-To: X-Newsgroups: list.freebsd-current User-Agent: tin/1.8.3-20070201 ("Scotasay") (UNIX) (FreeBSD/6.4-PRERELEASE-20080904 (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Sat, 13 Dec 2008 00:15:11 +0100 (CET) Cc: Subject: Re: usb2 + scanner HP ScanJet 4300C X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Dec 2008 23:15:14 -0000 Hans Petter Selasky wrote: > On Friday 12 December 2008, Oliver Fromme wrote: > > usb2_alloc_device: > > You could try to edit the code in "sys/dev/usb2/core/usb2_device.c" and loop > two times on the set_config command in "usb2_alloc_device()". > > Or you can try to make the code ignore the return value from the failing > set_config command. Also try to turn on more debugging: > > sysctl hw.usb2.debug=15 Thank you! That got me a step forward. Looping two or even three times didn't help, the set_config just continued to time out and fail. Then I followed your second advice and inserted "err = 0;" so the error was ignored. Now the device attaches! usbconfig list says: ugen0.1: at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON ugen1.1: at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON ugen0.2: at usbus0, cfg=255 md=HOST spd=FULL (12Mbps) pwr=ON Does that mean this device needs a quirk entry or something like that? I mean, setting err = 0 is a hack, it's not the proper solution. Unfortunately I wasn't able to check whether it works with SANE because I had to catch the train ... I'll continue with that next week. I hope I can finally make this scanner work ... The uscanner(4) manpage claims the 4300C is supported (for years already), but that wasn't true until now. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mn- chen, HRB 125758, Geschftsfhrer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "A language that doesn't have everything is actually easier to program in than some that do." -- Dennis M. Ritchie From owner-freebsd-current@FreeBSD.ORG Fri Dec 12 23:28:10 2008 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8F432106564A; Fri, 12 Dec 2008 23:28:10 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (unknown [IPv6:2a01:170:102f::2]) by mx1.freebsd.org (Postfix) with ESMTP id EFF2A8FC12; Fri, 12 Dec 2008 23:28:09 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (localhost [127.0.0.1]) by lurza.secnetix.de (8.14.3/8.14.3) with ESMTP id mBCNS8kx018581; Sat, 13 Dec 2008 00:28:08 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.14.3/8.14.3/Submit) id mBCNS8Zl018580; Sat, 13 Dec 2008 00:28:08 +0100 (CET) (envelope-from olli) Date: Sat, 13 Dec 2008 00:28:08 +0100 (CET) Message-Id: <200812122328.mBCNS8Zl018580@lurza.secnetix.de> From: Oliver Fromme To: freebsd-current@FreeBSD.ORG, freebsd-usb@FreeBSD.ORG, rizzo@iet.unipi.it In-Reply-To: X-Newsgroups: list.freebsd-current User-Agent: tin/1.8.3-20070201 ("Scotasay") (UNIX) (FreeBSD/6.4-PRERELEASE-20080904 (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Sat, 13 Dec 2008 00:28:08 +0100 (CET) Cc: Subject: Re: usb2 + scanner HP ScanJet 4300C X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Dec 2008 23:28:10 -0000 Luigi Rizzo wrote: > On Fri, Dec 12, 2008 at 09:27:27PM +0100, Oliver Fromme wrote: > > Hi, > > > > I've got a HP ScanJet 4300C that seems to be a little bit > > stubborn. > > > ... > > Is there anything I can do, except for forgetting about > > this scanner alltogether? > > one option is to put the device IDs in uscanner.c and see if > it is recognised. Thanks for the advice, but the device IDs _are_ already in uscanner.c. I checked that when I was experimenting with the old USB stack. The probe fails much earlier, before the uscanner code has a chance to do anything. So the problem isn't in uscanner.c. > But other than that, i wouldn't waste much time: > for 50..80 euro you can get one of the > Epson multifunction printer scanners (i have personally > tried DX4400 to DX7050) which are well supported and > extremely reliable. I bought this ScanJet 4300 C specifically because it is listed as supported by FreeBSD in the uscanner(4) manpage. I'm not going to spend more money on anything else (which wouldn't be guaranteed to work either). Either I get this beast to work somehow with FreeBSD, or I will have to use a different OS to drive the scanner. Fortunately Hans Petter's advice seems to help, although I still have to test whether SANE will work. (But I'm optimistic, now that the device attaches.) Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mn- chen, HRB 125758, Geschftsfhrer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "... there are two ways of constructing a software design: One way is to make it so simple that there are _obviously_ no deficiencies and the other way is to make it so complicated that there are no _obvious_ deficiencies." -- C.A.R. Hoare, ACM Turing Award Lecture, 1980 From owner-freebsd-current@FreeBSD.ORG Sat Dec 13 12:04:32 2008 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 97475106564A for ; Sat, 13 Dec 2008 12:04:32 +0000 (UTC) (envelope-from glz@hidden-powers.com) Received: from mail.hidden-powers.com (mail.hidden-powers.com [213.242.135.162]) by mx1.freebsd.org (Postfix) with ESMTP id 47D598FC12 for ; Sat, 13 Dec 2008 12:04:32 +0000 (UTC) (envelope-from glz@hidden-powers.com) Received: from mail.hidden-powers.com (localhost [127.0.0.1]) by dkim.hidden-powers.com (Postfix) with ESMTP id 543266D5DF for ; Sat, 13 Dec 2008 13:04:31 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=hidden-powers.com; h=date :from:to:subject:message-id:mime-version:content-type: content-transfer-encoding; s=selector1; bh=EvGOs0EGJfHQv4GT4lnOC jK6nCY=; b=NHhj8kWszpEYsxFtplp3apJ4kmZBvv6m9q5OUVr8D2315ahO+Tv5A cMvICOon6du21AaDpAdKeR98DJxUATPmgqehQS824fnXVLhuIXLezq5okxKFY2uC 0tvsujWNR+QlaKpO4diuCvG3JO85PaJeSDyyX7StxoRd5ZUuNDCh8U= Received: from [10.255.253.2] (unknown [10.255.253.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.hidden-powers.com (Postfix) with ESMTPSA id 4614B6D4DE for ; Sat, 13 Dec 2008 13:04:31 +0100 (CET) Date: Sat, 13 Dec 2008 13:04:30 +0100 From: Goran Lowkrantz To: freebsd-current@FreeBSD.ORG Message-ID: <088C87B70CB486D2F808091A@[10.255.253.2]> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: Subject: [PANIC] _rw_rlock (radix node head): wlock already held @ /usr/src/sys/net/route.c:291 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Dec 2008 12:04:32 -0000 I upgraded to CURRENT Dec 12 11pm and get this panic when ifconfig tries to add an ipv6 route. I have not been able to get a dump and only screen console, so the boot messages, crash and backtrace is supplied in a series of jpegs avalable at . This crash is 100% and I can recreate it if there is more information needed. /glz --- "There is hopeful symbolism in the fact that flags do not wave in a vacuum." -- Arthur C. Clarke From owner-freebsd-current@FreeBSD.ORG Sat Dec 13 13:36:27 2008 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 26CE71065672 for ; Sat, 13 Dec 2008 13:36:27 +0000 (UTC) (envelope-from bsam@ipt.ru) Received: from services.ipt.ru (services.ipt.ru [194.62.233.110]) by mx1.freebsd.org (Postfix) with ESMTP id CCB1F8FC0C for ; Sat, 13 Dec 2008 13:36:26 +0000 (UTC) (envelope-from bsam@ipt.ru) Received: from bb.ipt.ru ([194.62.233.89]) by services.ipt.ru with esmtp (Exim 4.54 (FreeBSD)) id 1LBUfR-00019Q-By; Sat, 13 Dec 2008 16:36:25 +0300 To: Marcel Moolenaar References: <92804393@bb.ipt.ru> <26722819@bb.ipt.ru> <26719629@bb.ipt.ru> <19F75E66-0535-4982-9726-E2C0A03117EA@mac.com> <94541668@bb.ipt.ru> <48144979@bb.ipt.ru> <548CF0A3-1B07-49DA-A177-6EA85FD8CF2F@mac.com> <94539778@bb.ipt.ru> <9939E942-A2FC-4240-BC14-527D45C187B7@mac.com> From: Boris Samorodov Date: Sat, 13 Dec 2008 16:36:25 +0300 In-Reply-To: <9939E942-A2FC-4240-BC14-527D45C187B7@mac.com> (Marcel Moolenaar's message of "Fri\, 12 Dec 2008 09\:48\:58 -0800") Message-ID: <94529078@bb.ipt.ru> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-current@FreeBSD.org, rea-fbsd@codelabs.ru Subject: Re: Timeda 8-multiport adapter: only 2 ports available X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Dec 2008 13:36:27 -0000 Marcel Moolenaar writes: > The attached patch is a quick and dirty way to > program the ports. Can you see if it actually works and > if it makes a difference? ----- cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -std=c99 -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj/usr/src/sys/BB/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -I/usr/obj/usr/src/sys/BB -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -fstack-protector -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/puc/../../dev/puc/puc.c /usr/src/sys/modules/puc/../../dev/puc/pucdata.c: In function 'puc_config_timedia': /usr/src/sys/modules/puc/../../dev/puc/pucdata.c:1157: error: dereferencing pointer to incomplete type /usr/src/sys/modules/puc/../../dev/puc/pucdata.c:1157: error: dereferencing pointer to incomplete type *** Error code 1 ----- That's for the line [*]: ----- --- pucdata.c (revision 185784) +++ pucdata.c (working copy) @@ -1145,6 +1145,10 @@ case PUC_CFG_GET_TYPE: *res = PUC_TYPE_SERIAL; return (0); + case PUC_CFG_INIT_PORT: + bus_write_1((struct res *)res, 1 /* IER */, [*] + (port >= 2) ? 0x10 : 0); + return (0); default: break; } ----- WBR -- Boris Samorodov (bsam) Research Engineer, http://www.ipt.ru Telephone & Internet SP FreeBSD committer, http://www.FreeBSD.org The Power To Serve From owner-freebsd-current@FreeBSD.ORG Sat Dec 13 19:45:19 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 644AC1065678 for ; Sat, 13 Dec 2008 19:45:19 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.10]) by mx1.freebsd.org (Postfix) with ESMTP id E818B8FC1E for ; Sat, 13 Dec 2008 19:45:18 +0000 (UTC) (envelope-from max@love2party.net) Received: from vampire.homelinux.org (dslb-088-066-024-089.pools.arcor-ip.net [88.66.24.89]) by mrelayeu.kundenserver.de (node=mrelayeu7) with ESMTP (Nemesis) id 0ML2xA-1LBaQP2kge-00049V; Sat, 13 Dec 2008 20:45:17 +0100 Received: (qmail 31355 invoked from network); 13 Dec 2008 19:45:17 -0000 Received: from fbsd8.laiers.local (192.168.4.151) by ns1.laiers.local with SMTP; 13 Dec 2008 19:45:17 -0000 From: Max Laier Organization: FreeBSD To: FreeBSD virtualization mailing list Date: Sat, 13 Dec 2008 20:45:16 +0100 User-Agent: KMail/1.10.1 (FreeBSD/8.0-CURRENT; KDE/4.1.1; i386; ; ) References: <200812131913.mBDJD38C037353@svn.freebsd.org> <20081213191345.M97918@maildrop.int.zabbadoz.net> In-Reply-To: <20081213191345.M97918@maildrop.int.zabbadoz.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200812132045.17207.max@love2party.net> X-Provags-ID: V01U2FsdGVkX19/BHheOLP5ACI2RNUxV3jNdesZlvJXDoFwmVq oyV8WhvMH0Lhg+EvLysdt699f70BKS/C1soo9SCtrwoN70t2au 4iXO2znnzXD/NwCILu0yA== Cc: svn-src-head@freebsd.org, freebsd-net@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, FreeBSD current mailing list Subject: Re: HEADS UP: vimage - virtualized global variables in the network stack X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Dec 2008 19:45:19 -0000 On Saturday 13 December 2008 20:33:53 Bjoern A. Zeeb wrote: ... > This state of having the variables in parallel, global and in the > container struct, will be maintained for another (short) time until > the entire virtualization framework is in. This is needed, so that > all three possible states can be benchmarked from exactly the same > code changeset. > > > For developers comitting new code or changing code it is important to > properly add virtualized variables in the way that: > 1) the globals and externs (if needed) are added/kept in sync as both > a) globals under #ifdef VIMAGE_GLOBALS and b) to the appropriate > container struct + the V_ macro. > When used somewhere in code one has to use the V_foobarbaz version. Is there (an easy) way to have the tinderbox build every other run without VIMAGE_GLOBALS so that the most obvious error (global available, but not in the container struct - or the other way around) can be warned about? -- /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News From owner-freebsd-current@FreeBSD.ORG Sat Dec 13 19:54:12 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ABB4D1065670; Sat, 13 Dec 2008 19:54:12 +0000 (UTC) (envelope-from bz@FreeBSD.org) Received: from mail.cksoft.de (mail.cksoft.de [62.111.66.27]) by mx1.freebsd.org (Postfix) with ESMTP id 37C9A8FC08; Sat, 13 Dec 2008 19:54:12 +0000 (UTC) (envelope-from bz@FreeBSD.org) Received: from localhost (amavis.str.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id CBAC441C64A; Sat, 13 Dec 2008 20:35:05 +0100 (CET) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([62.111.66.27]) by localhost (amavis.str.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id LuSxzKuBSDNS; Sat, 13 Dec 2008 20:35:05 +0100 (CET) Received: by mail.cksoft.de (Postfix, from userid 66) id 6AADA41C615; Sat, 13 Dec 2008 20:35:05 +0100 (CET) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 555864448D5; Sat, 13 Dec 2008 19:33:54 +0000 (UTC) Date: Sat, 13 Dec 2008 19:33:53 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org, FreeBSD virtualization mailing list In-Reply-To: <200812131913.mBDJD38C037353@svn.freebsd.org> Message-ID: <20081213191345.M97918@maildrop.int.zabbadoz.net> References: <200812131913.mBDJD38C037353@svn.freebsd.org> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org, FreeBSD current mailing list Subject: HEADS UP: vimage - virtualized global variables in the network stack X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: FreeBSD virtualization mailing list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Dec 2008 19:54:12 -0000 On Sat, 13 Dec 2008, Bjoern A. Zeeb wrote: Hi, > Author: bz > Date: Sat Dec 13 19:13:03 2008 > New Revision: 186048 > URL: http://svn.freebsd.org/changeset/base/186048 > > Log: > Second round of putting global variables, which were virtualized > but formerly missed under VIMAGE_GLOBAL. > > Put the extern declarations of the virtualized globals > under VIMAGE_GLOBAL as the globals themsevles are already. > This will help by the time when we are going to remove the globals > entirely. As some of you might have noticed that Marko's last commit for the first time in the series of vimage commits was an actual functional change. By default HEAD is no longer using the globals. With my commit the current set of virtualized variables is assumed to be "clean". This basically means three things: 1) The former globals and their externs are all under #ifdef VIMAGE_GLOBALS 2) The same variables are present in a 'container struct' 3) The initialization of those is done from 'constructor ("init") functions' This state of having the variables in parallel, global and in the container struct, will be maintained for another (short) time until the entire virtualization framework is in. This is needed, so that all three possible states can be benchmarked from exactly the same code changeset. For developers comitting new code or changing code it is important to properly add virtualized variables in the way that: 1) the globals and externs (if needed) are added/kept in sync as both a) globals under #ifdef VIMAGE_GLOBALS and b) to the appropriate container struct + the V_ macro. When used somewhere in code one has to use the V_foobarbaz version. 2) Any new virtualized globals must not be directly initialized. They have to be initialized from a contructor function (which is usually there already). If you are confused about some of the terms etc. follow the links in the "Some documentation" section on the wiki: http://wiki.freebsd.org/Image The "Vimage Coding - beginners guide / FAQ" tries to answer the 101 questions. For the beaf you'll find the link to a document in perforce with the last question (that you may already know). We'll try to enhance this as we get questions or the integration goes on. In case of questions or suggestions ideally follow-up on freebsd-virtualization@ . /bz -- Bjoern A. Zeeb The greatest risk is not taking one. From owner-freebsd-current@FreeBSD.ORG Sat Dec 13 20:10:07 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7744410656A3; Sat, 13 Dec 2008 20:10:07 +0000 (UTC) (envelope-from bz@FreeBSD.org) Received: from mail.cksoft.de (mail.cksoft.de [62.111.66.27]) by mx1.freebsd.org (Postfix) with ESMTP id F28588FC17; Sat, 13 Dec 2008 20:10:06 +0000 (UTC) (envelope-from bz@FreeBSD.org) Received: from localhost (amavis.str.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id 2048F41C6A3; Sat, 13 Dec 2008 21:10:06 +0100 (CET) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([62.111.66.27]) by localhost (amavis.str.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id AL8qj7J-9cEK; Sat, 13 Dec 2008 21:10:05 +0100 (CET) Received: by mail.cksoft.de (Postfix, from userid 66) id BC8A041C6A1; Sat, 13 Dec 2008 21:10:05 +0100 (CET) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 1A8434448D5; Sat, 13 Dec 2008 20:07:38 +0000 (UTC) Date: Sat, 13 Dec 2008 20:07:38 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Max Laier In-Reply-To: <200812132045.17207.max@love2party.net> Message-ID: <20081213195343.V97918@maildrop.int.zabbadoz.net> References: <200812131913.mBDJD38C037353@svn.freebsd.org> <20081213191345.M97918@maildrop.int.zabbadoz.net> <200812132045.17207.max@love2party.net> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: src-committers@freebsd.org, FreeBSD current mailing list , FreeBSD virtualization mailing list , freebsd-net@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: HEADS UP: vimage - virtualized global variables in the network stack X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Dec 2008 20:10:07 -0000 On Sat, 13 Dec 2008, Max Laier wrote: > On Saturday 13 December 2008 20:33:53 Bjoern A. Zeeb wrote: > ... >> This state of having the variables in parallel, global and in the >> container struct, will be maintained for another (short) time until >> the entire virtualization framework is in. This is needed, so that >> all three possible states can be benchmarked from exactly the same >> code changeset. >> >> >> For developers comitting new code or changing code it is important to >> properly add virtualized variables in the way that: >> 1) the globals and externs (if needed) are added/kept in sync as both >> a) globals under #ifdef VIMAGE_GLOBALS and b) to the appropriate >> container struct + the V_ macro. >> When used somewhere in code one has to use the V_foobarbaz version. > > Is there (an easy) way to have the tinderbox build every other run without > VIMAGE_GLOBALS so that the most obvious error (global available, but not in > the container struct - or the other way around) can be warned about? Without VIMAGE_GLOBALS is the default; we have been building this for a few days already. The flip had been so smoothly that almost noone had really noticed. Marko has done a really great job! Thus my HEADS UP now after I am confident enough that (almost) all places were caught and clean. In case you want to check yourself you can simply put a file into one or multiple archs conf dir that looks like: ------------------------------------------------------------------------ > cat sys/amd64/conf/LINT-VIMAGE_GLOBALS include LINT ident LINT-VIMAGE_GLOBALS options VIMAGE_GLOBALS ------------------------------------------------------------------------ I am doing that build every other day from now to catch the possible error of a virtualized variable in the container struct w/o the global. But as this is the least problematic case I do not want to commit the kernel configuration as it'll make builds longer for everyone, etc. The more problematic cases that builds cannot catch are: - static initialization of a virtualized 'global'. - a newly added virtualized 'global' that is not under #ifdef VIMAGE_GLOBALS I have scripts to identify the latter already. The former will only be caught be either code inspection or "unexpected results" when running. /bz -- Bjoern A. Zeeb The greatest risk is not taking one. From owner-freebsd-current@FreeBSD.ORG Sat Dec 13 20:14:41 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 96E47106567A for ; Sat, 13 Dec 2008 20:14:41 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: from rv-out-0708.google.com (rv-out-0708.google.com [209.85.198.241]) by mx1.freebsd.org (Postfix) with ESMTP id 65F588FC08 for ; Sat, 13 Dec 2008 20:14:41 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: by rv-out-0708.google.com with SMTP id k29so2515043rvb.0 for ; Sat, 13 Dec 2008 12:14:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=xPIzmigZybDcOT7ZjVBtHkHPoW7DCz9p2gTLESSmk+A=; b=lO/vXz2Ae1S+6WN/9u1ELVVOPv+prjfd8jBu3OU7AxdNyBRb/C3y9oaV3udETQPJb4 V+rRKqlXBUJiYFydnOgg7rdu3ouPvfxcBxVFDgv2UeGtKBBRulDDIFKViHQ4Y4l4admh rbE7GmNakZUZQZW6UHrKNYgiCPT5xWZFPcYvA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=xqf1jiCf2lUBzVX9ed/iGNxlqQMzCl8w+Vo7epgSiYNKoPFcIeItEUGGxPuLh2i3Xf hD0IQZKDjIGjObzOoRH5ydh70xYRc39fEHOBak/U85HDuM3m923Q5WSxhBOTGSl6oUuG mITAsJJH0kxDE6lT7YEIvhkZ5S7CmvqGkVDa0= Received: by 10.140.201.8 with SMTP id y8mr2702548rvf.101.1229199281106; Sat, 13 Dec 2008 12:14:41 -0800 (PST) Received: by 10.141.142.3 with HTTP; Sat, 13 Dec 2008 12:14:41 -0800 (PST) Message-ID: <3c1674c90812131214r354a11d7i35d354694026cb78@mail.gmail.com> Date: Sat, 13 Dec 2008 20:14:41 +0000 From: "Kip Macy" Sender: mat.macy@gmail.com To: "Tor Egge" In-Reply-To: <20081213.200612.74714794.Tor.Egge@cvsup.no.freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <088C87B70CB486D2F808091A@10.255.253.2> <20081213.200612.74714794.Tor.Egge@cvsup.no.freebsd.org> X-Google-Sender-Auth: 34a4223234b49ce8 Cc: glz@hidden-powers.com, freebsd-current@freebsd.org Subject: Re: [PANIC] _rw_rlock (radix node head): wlock already held @ /usr/src/sys/net/route.c:291 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Dec 2008 20:14:41 -0000 Heh, that is the correct fix that I was about to commit. Thanks, Kip On Sat, Dec 13, 2008 at 8:06 PM, Tor Egge wrote: >> I upgraded to CURRENT Dec 12 11pm and get this panic when ifconfig tries to >> add an ipv6 route. > > I've gotten similar panics and am currently using the enclosed patch. > > - Tor Egge > > Index: sys/netinet/in_rmx.c > =================================================================== > RCS file: /home/ncvs/src/sys/netinet/in_rmx.c,v > retrieving revision 1.65 > diff -u -r1.65 in_rmx.c > --- sys/netinet/in_rmx.c 2 Dec 2008 21:37:28 -0000 1.65 > +++ sys/netinet/in_rmx.c 13 Dec 2008 15:43:33 -0000 > @@ -115,7 +115,7 @@ > * ARP entry and delete it if so. > */ > rt2 = in_rtalloc1((struct sockaddr *)sin, 0, > - RTF_CLONING, rt->rt_fibnum); > + RTF_CLONING | RTF_RNH_LOCKED, rt->rt_fibnum); > if (rt2) { > if (rt2->rt_flags & RTF_LLINFO && > rt2->rt_flags & RTF_HOST && > Index: sys/netinet6/in6_rmx.c > =================================================================== > RCS file: /home/ncvs/src/sys/netinet6/in6_rmx.c,v > retrieving revision 1.31 > diff -u -r1.31 in6_rmx.c > --- sys/netinet6/in6_rmx.c 8 Dec 2008 00:28:21 -0000 1.31 > +++ sys/netinet6/in6_rmx.c 13 Dec 2008 19:51:18 -0000 > @@ -160,7 +160,8 @@ > * Find out if it is because of an > * ARP entry and delete it if so. > */ > - rt2 = rtalloc1((struct sockaddr *)sin6, 0, RTF_CLONING); > + rt2 = rtalloc1((struct sockaddr *)sin6, 0, > + RTF_CLONING | RTF_RNH_LOCKED); > if (rt2) { > if (rt2->rt_flags & RTF_LLINFO && > rt2->rt_flags & RTF_HOST && > @@ -187,7 +188,8 @@ > * net route entry, 3ffe:0501:: -> if0. > * This case should not raise an error. > */ > - rt2 = rtalloc1((struct sockaddr *)sin6, 0, RTF_CLONING); > + rt2 = rtalloc1((struct sockaddr *)sin6, 0, > + RTF_CLONING | RTF_RNH_LOCKED); > if (rt2) { > if ((rt2->rt_flags & (RTF_CLONING|RTF_HOST|RTF_GATEWAY)) > == RTF_CLONING > > -- If we desire respect for the law, we must first make the law respectable. - Louis D. Brandeis From owner-freebsd-current@FreeBSD.ORG Sat Dec 13 20:18:55 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F2F521065679 for ; Sat, 13 Dec 2008 20:18:55 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.238]) by mx1.freebsd.org (Postfix) with ESMTP id C390C8FC1C for ; Sat, 13 Dec 2008 20:18:55 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so2058914rvf.43 for ; Sat, 13 Dec 2008 12:18:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=eORgIfhaSere9HX1xR1B44sYf5DKDJY9d4YSjEThgCc=; b=JufUoS6WUvRIhAXlP2B4cE++PMfSqqAMbOTPhFfGnFoXP6CY67u/L6eUw1JdHjx0LY afC34N66Zrkk6tJtmSLG+EEltJVd5OGRYnn3pgeijyFhzUhkHNF+4mp1tonTUXWil6JU inm+yw35hm5hMoBNZaHVaVkvd5Lu53gNH1tAE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=J0P/el/GS9ZxkwlDKW7SFB0nuQ8quAsLpsMVav+Ekty9cFizDjPzO5Ut+p5s4EHnoF SnhqDXYuYdGqmyiCwaWiEioh3t/knHSlibsKrqIpRaCx71uEg2puWBmm/OL5K10heYIc sAVRd1cFNDbQsKwaGFgdek4vT5CtC1x6M1B1I= Received: by 10.140.199.15 with SMTP id w15mr2688124rvf.253.1229199534752; Sat, 13 Dec 2008 12:18:54 -0800 (PST) Received: by 10.141.142.3 with HTTP; Sat, 13 Dec 2008 12:18:54 -0800 (PST) Message-ID: <3c1674c90812131218r30f54d32w73299c0a67b48627@mail.gmail.com> Date: Sat, 13 Dec 2008 20:18:54 +0000 From: "Kip Macy" Sender: mat.macy@gmail.com To: "Goran Lowkrantz" In-Reply-To: <088C87B70CB486D2F808091A@10.255.253.2> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <088C87B70CB486D2F808091A@10.255.253.2> X-Google-Sender-Auth: 615135f6f2c33998 Cc: freebsd-current@freebsd.org Subject: Re: [PANIC] _rw_rlock (radix node head): wlock already held @ /usr/src/sys/net/route.c:291 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Dec 2008 20:18:56 -0000 Please try the latest sources. Thanks, Kip On Sat, Dec 13, 2008 at 12:04 PM, Goran Lowkrantz wrote: > I upgraded to CURRENT Dec 12 11pm and get this panic when ifconfig tries to > add an ipv6 route. I have not been able to get a dump and only screen > console, so the boot messages, crash and backtrace is supplied in a series > of jpegs avalable at > . > > This crash is 100% and I can recreate it if there is more information > needed. > > /glz > > --- > "There is hopeful symbolism in the fact that flags do not wave in a vacuum." > -- Arthur C. Clarke > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > -- If we desire respect for the law, we must first make the law respectable. - Louis D. Brandeis From owner-freebsd-current@FreeBSD.ORG Sat Dec 13 20:27:17 2008 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6C195106570C; Sat, 13 Dec 2008 20:27:17 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 259428FC13; Sat, 13 Dec 2008 20:27:17 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id mBDKOPGs092903; Sat, 13 Dec 2008 13:24:25 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Sat, 13 Dec 2008 13:24:25 -0700 (MST) Message-Id: <20081213.132425.41724046.imp@bsdimp.com> To: max@love2party.net From: Warner Losh In-Reply-To: <200812132045.17207.max@love2party.net> References: <200812131913.mBDJD38C037353@svn.freebsd.org> <20081213191345.M97918@maildrop.int.zabbadoz.net> <200812132045.17207.max@love2party.net> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: src-committers@FreeBSD.org, current@FreeBSD.org, freebsd-virtualization@FreeBSD.org, freebsd-net@FreeBSD.org, svn-src-all@FreeBSD.org, svn-src-head@FreeBSD.org Subject: Re: HEADS UP: vimage - virtualized global variables in the network stack X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Dec 2008 20:27:17 -0000 From: Max Laier Subject: Re: HEADS UP: vimage - virtualized global variables in the network stack Date: Sat, 13 Dec 2008 20:45:16 +0100 > On Saturday 13 December 2008 20:33:53 Bjoern A. Zeeb wrote: > ... > > This state of having the variables in parallel, global and in the > > container struct, will be maintained for another (short) time until > > the entire virtualization framework is in. This is needed, so that > > all three possible states can be benchmarked from exactly the same > > code changeset. > > > > > > For developers comitting new code or changing code it is important to > > properly add virtualized variables in the way that: > > 1) the globals and externs (if needed) are added/kept in sync as both > > a) globals under #ifdef VIMAGE_GLOBALS and b) to the appropriate > > container struct + the V_ macro. > > When used somewhere in code one has to use the V_foobarbaz version. > > Is there (an easy) way to have the tinderbox build every other run without > VIMAGE_GLOBALS so that the most obvious error (global available, but not in > the container struct - or the other way around) can be warned about? This actually points out why the 'tinderbox' name is bogus for the universe plus failure: universe builds all the kernels. Tinderbox builds LINT only. Warner From owner-freebsd-current@FreeBSD.ORG Sat Dec 13 20:36:27 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4DFF61065678 for ; Sat, 13 Dec 2008 20:36:27 +0000 (UTC) (envelope-from Tor.Egge@cvsup.no.freebsd.org) Received: from pil.idi.ntnu.no (pil.idi.ntnu.no [129.241.107.93]) by mx1.freebsd.org (Postfix) with ESMTP id C1C828FC13 for ; Sat, 13 Dec 2008 20:36:26 +0000 (UTC) (envelope-from Tor.Egge@cvsup.no.freebsd.org) Received: from cvsup.no.freebsd.org (c2h5oh.idi.ntnu.no [129.241.103.69]) by pil.idi.ntnu.no (8.14.1/8.13.1) with ESMTP id mBDK6tVX016031 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 13 Dec 2008 21:06:56 +0100 (MET) Received: from localhost (localhost [127.0.0.1]) by cvsup.no.freebsd.org (8.14.2/8.14.2) with ESMTP id mBDK6tpc038808; Sat, 13 Dec 2008 20:06:55 GMT (envelope-from Tor.Egge@cvsup.no.freebsd.org) Date: Sat, 13 Dec 2008 20:06:12 +0000 (UTC) Message-Id: <20081213.200612.74714794.Tor.Egge@cvsup.no.freebsd.org> To: glz@hidden-powers.com From: Tor Egge In-Reply-To: <088C87B70CB486D2F808091A@[10.255.253.2]> References: <088C87B70CB486D2F808091A@[10.255.253.2]> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Multipart/Mixed; boundary="--Next_Part(Sat_Dec_13_20_06_12_2008_364)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned-By: mimedefang.idi.ntnu.no, using CLAMD X-SMTP-From: Sender=, Relay/Client=c2h5oh.idi.ntnu.no [129.241.103.69], EHLO=cvsup.no.freebsd.org X-Scanned-By: MIMEDefang 2.48 on 129.241.107.38 X-Scanned-By: mimedefang.idi.ntnu.no, using MIMEDefang 2.48 with local filter 16.42-idi X-Filter-Time: 1 seconds Cc: freebsd-current@freebsd.org, kmacy@freebsd.org Subject: Re: [PANIC] _rw_rlock (radix node head): wlock already held @ /usr/src/sys/net/route.c:291 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Dec 2008 20:36:27 -0000 ----Next_Part(Sat_Dec_13_20_06_12_2008_364)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit > I upgraded to CURRENT Dec 12 11pm and get this panic when ifconfig tries to > add an ipv6 route. I've gotten similar panics and am currently using the enclosed patch. - Tor Egge ----Next_Part(Sat_Dec_13_20_06_12_2008_364)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="rmx2.diff" Index: sys/netinet/in_rmx.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/in_rmx.c,v retrieving revision 1.65 diff -u -r1.65 in_rmx.c --- sys/netinet/in_rmx.c 2 Dec 2008 21:37:28 -0000 1.65 +++ sys/netinet/in_rmx.c 13 Dec 2008 15:43:33 -0000 @@ -115,7 +115,7 @@ * ARP entry and delete it if so. */ rt2 = in_rtalloc1((struct sockaddr *)sin, 0, - RTF_CLONING, rt->rt_fibnum); + RTF_CLONING | RTF_RNH_LOCKED, rt->rt_fibnum); if (rt2) { if (rt2->rt_flags & RTF_LLINFO && rt2->rt_flags & RTF_HOST && Index: sys/netinet6/in6_rmx.c =================================================================== RCS file: /home/ncvs/src/sys/netinet6/in6_rmx.c,v retrieving revision 1.31 diff -u -r1.31 in6_rmx.c --- sys/netinet6/in6_rmx.c 8 Dec 2008 00:28:21 -0000 1.31 +++ sys/netinet6/in6_rmx.c 13 Dec 2008 19:51:18 -0000 @@ -160,7 +160,8 @@ * Find out if it is because of an * ARP entry and delete it if so. */ - rt2 = rtalloc1((struct sockaddr *)sin6, 0, RTF_CLONING); + rt2 = rtalloc1((struct sockaddr *)sin6, 0, + RTF_CLONING | RTF_RNH_LOCKED); if (rt2) { if (rt2->rt_flags & RTF_LLINFO && rt2->rt_flags & RTF_HOST && @@ -187,7 +188,8 @@ * net route entry, 3ffe:0501:: -> if0. * This case should not raise an error. */ - rt2 = rtalloc1((struct sockaddr *)sin6, 0, RTF_CLONING); + rt2 = rtalloc1((struct sockaddr *)sin6, 0, + RTF_CLONING | RTF_RNH_LOCKED); if (rt2) { if ((rt2->rt_flags & (RTF_CLONING|RTF_HOST|RTF_GATEWAY)) == RTF_CLONING ----Next_Part(Sat_Dec_13_20_06_12_2008_364)----