From nobody@FreeBSD.org  Wed Sep 15 02:05:16 2010
Return-Path: <nobody@FreeBSD.org>
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id 21E09106566B
	for <freebsd-gnats-submit@FreeBSD.org>; Wed, 15 Sep 2010 02:05:16 +0000 (UTC)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (www.freebsd.org [IPv6:2001:4f8:fff6::21])
	by mx1.freebsd.org (Postfix) with ESMTP id 102278FC0C
	for <freebsd-gnats-submit@FreeBSD.org>; Wed, 15 Sep 2010 02:05:16 +0000 (UTC)
Received: from www.freebsd.org (localhost [127.0.0.1])
	by www.freebsd.org (8.14.3/8.14.3) with ESMTP id o8F25FVI083061
	for <freebsd-gnats-submit@FreeBSD.org>; Wed, 15 Sep 2010 02:05:15 GMT
	(envelope-from nobody@www.freebsd.org)
Received: (from nobody@localhost)
	by www.freebsd.org (8.14.3/8.14.3/Submit) id o8F25F39083060;
	Wed, 15 Sep 2010 02:05:15 GMT
	(envelope-from nobody)
Message-Id: <201009150205.o8F25F39083060@www.freebsd.org>
Date: Wed, 15 Sep 2010 02:05:15 GMT
From: Tyler S <tyler@680x0.com>
To: freebsd-gnats-submit@FreeBSD.org
Subject: Unknown error generates IRQ address decoding error
X-Send-Pr-Version: www-3.1
X-GNATS-Notify:

>Number:         150581
>Category:       arm
>Synopsis:       [irq] Unknown error generates IRQ address decoding error
>Confidential:   no
>Severity:       serious
>Priority:       low
>Responsible:    freebsd-arm
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Wed Sep 15 02:10:01 UTC 2010
>Closed-Date:    
>Last-Modified:  Mon Sep 20 07:08:43 UTC 2010
>Originator:     Tyler S
>Release:        -current
>Organization:
>Environment:
FreeBSD armadeus 9.0-CURRENT FreeBSD 9.0-CURRENT #3: Tue Sep 14 04:49:25 UTC 2010     ulterior@adumbral.local:/usr/obj/arm.arm/usr/src/sys/SHEEVAPLUG  arm

>Description:
When executing "portsnap fetch", the machine (a guruplug server plus) floods its local console with:
c86a862ec3012622d1fc4d0d450dcb2469828ffec71fd7 46% of   63 MB  214 kBps 02m43s
c86a862ec3012622d1fc4d0d450dcb2469828ffec71fd7 46% of   63 MB  213 kBps 02m43s
c86a862ec3012622d1fc4d0d450dcb2469828ffec71fd7 46% of   63 MB  213 kBps 02m43s
c86a862ec3012622d1fc4d0d450dcb2469828ffec71fd7 47% of   63 MB  213 kBps 02m41s
c86a862ec3012622d1fc4d0d450dcb2469828ffec71fd7 47% of   63 MB  213 kBps 02m40s
c86a862ec3012622d1fc4d0d450dcb2469828ffec71fd7 47% of   63 MB  213 kBps 02m39s
c86a862ec3012622d1fc4d0d450dcb2469828ffec71fd7 47% of   63 MB  213 kBps 02m38s
c86a862ec3012622d1fc4d0d450dcb2469828ffec71fd7 48% of   63 MB  212 kBps 02m38s
c86a862ec3012622d1fc4d0d450dcb2469828ffec71fd7 48% of   63 MB  213 kBps 02m37s
c86a862ec3012622d1fc4d0d450dcb2469828ffec71fd7 48% of   63 MB  213 kBps 02m35s
c86a862ec3012622d1fc4d0d450dcb2469828ffec71fd7 49% of   63 MB  212 kBps 02m35s
c86a862ec3012622d1fc4d0d450dcb2469828ffec71fd7 49% of   63 MB  212 kBps 02m34s
c86a862ec3012622d1fc4d0d450dcb2469828ffec71fd7 49% of   63 MB  213 kBps 02m32s
c86a862ec3012622d1fc4d0d450dcb2469828ffec71fd7 50% of   63 MB  214 kBps 02m30s
c86a862ec3012622d1fc4d0d450dcb2469828ffec71fd7 50% of   63 MB  214 kBps 02m28s
c86a862ec301262IRQ ERR: cause: 0x00000001
IRQ ERR: Address decoding error
IRQ ERR: cause: 0x00000001
IRQ ERR: Address decoding error
IRQ ERR: cause: 0x00000001
IRQ ERR: Address decoding error
IRQ ERR: cause: 0x00000001
IRQ ERR: Address decoding error
IRQ ERR: cause: 0x00000001
IRQ ERR: Address decoding error
IRQ ERR: cause: 0x00000001
IRQ ERR: Address decoding error
IRQ ERR: cause: 0x00000001
IRQ ERR: Address decoding error
IRQ ERR: cause: 0x00000001
IRQ ERR: Address decoding error
IRQ ERR: cause: 0x00000001
IRQ ERR: Address decoding error
IRQ ERR: cause: 0x00000001
IRQ ERR: Address decoding error
IRQ ERR: cause: 0x00000001
IRQ ERR: Address decoding error
IRQ ERR: cause: 0x00000001
IRQ ERR: Address decoding error
IRQ ERR: cause: 0x00000001
- snip -

and the machine becomes unresponsive, prompting a cold boot.

Kernel was built with the following patches applied to it:

--- /usr/src/sys/kern/vfs_mount.c.orig	2010-07-04 22:50:00.613726077 -0400
+++ /usr/src/sys/kern/vfs_mount.c	2010-07-05 12:11:09.986561693 -0400
@@ -1651,6 +1651,9 @@
 	int error, i, asked = 0;

 	options = NULL;
+
+	/* NASTY HACK: wait for USB sticks to appear */
+	pause("usbhack", hz * 10);

 	root_mount_prepare();

--- /usr/src/etc/rc.d/fsck.orig	2010-07-07 13:02:41.765255856 -0400
+++ /usr/src/etc/rc.d/fsck	2010-07-07 13:02:46.286575144 -0400
@@ -27,7 +27,16 @@
 		if checkyesno background_fsck; then
 			fsck -F -p
 		else
-			fsck -p
+			if checkyesno force_fsck; then
+				echo "Force fsck enabled"
+				for filesystem in ${force_fsck_list}
+				do
+					echo "Force check $filesystem"
+					fsck -y $filesystem
+				done
+			else
+				fsck -p
+			fi
 		fi

 		case $? in
--- /usr/src/contrib/bind9/lib/isc/arm/include/isc/atomic.h.orig	2010-08-04 02:02:01.194401084 -0400
+++ /usr/src/contrib/bind9/lib/isc/arm/include/isc/atomic.h	2010-08-04 02:04:53.462379414 -0400
@@ -49,26 +49,22 @@
 static inline isc_int32_t
 isc_atomic_cmpxchg(isc_int32_t *p, isc_int32_t cmpval, isc_int32_t val)
 {
-	register int done, ras_start;
+	register int done, ras_start  = 0xffff1004;

 	__asm __volatile("1:\n"
 	    "adr	%1, 1b\n"
-	    "mov	%0, #0xe0000004\n"
 	    "str	%1, [%0]\n"
-	    "mov	%0, #0xe0000008\n"
 	    "adr	%1, 2f\n"
-	    "str	%1, [%0]\n"
+	    "str	%1, [%0, #4]\n"
 	    "ldr	%1, [%2]\n"
 	    "cmp	%1, %3\n"
 	    "streq	%4, [%2]\n"
 	    "2:\n"
 	    "mov	%3, #0\n"
-	    "mov	%0, #0xe0000004\n"
 	    "str	%3, [%0]\n"
 	    "mov	%3, #0xffffffff\n"
-	    "mov	%0, #0xe0000008\n"
-	    "str	%3, [%0]\n"
-	    : "=r" (ras_start), "=r" (done)
+	    "str	%3, [%0, #4]\n"
+	    : "+r" (ras_start), "=r" (done)
 	    ,"+r" (p), "+r" (cmpval), "+r" (val) : : "memory");
 	return (done);
and, the following kernel configuration:

#
# Custom kernel for Marvell SheevaPlug devices.
#
# $FreeBSD: src/sys/arm/conf/SHEEVAPLUG,v 1.3 2010/06/13 13:28:53 raj Exp $
#

ident           SHEEVAPLUG
include         "../mv/kirkwood/std.sheevaplug"

options         SOC_MV_KIRKWOOD
makeoptions     MODULES_OVERRIDE=""

#makeoptions    DEBUG=-g                #Build kernel with gdb(1) debug symbols
makeoptions     WERROR="-Werror"

options         SCHED_4BSD              #4BSD scheduler
options         INET                    #InterNETworking
options         INET6                   #IPv6 communications protocols
options         FFS                     #Berkeley Fast Filesystem
options         NFSCLIENT               #Network Filesystem Client
options         NFSLOCKD                #Network Lock Manager
options         NFS_ROOT                #NFS usable as /, requires NFSCLIENT
#options        BOOTP
#options        BOOTP_NFSROOT
#options        BOOTP_NFSV3
#options        BOOTP_WIRED_TO=mge0

options         GEOM_PART_BSD
options         GEOM_PART_GPT
options         GEOM_PART_MBR
options         GEOM_LABEL

options         SOFTUPDATES     # Enable FF Soft updates support
options         MSDOSFS         # Enable MSDOS Filesystems
options         PROCFS          # Process Filesystem
options         PSEUDOFS        # Psuedo-filesystem support
#options                ZFS             # zfs module
#options                opensolaris     # support module for zfs
# Root fs on USB device
#options        ROOTDEVNAME=\"ufs:/dev/da0a\"

options         SYSVSHM                 #SYSV-style shared memory
options         SYSVMSG                 #SYSV-style message queues
options         SYSVSEM                 #SYSV-style semaphores
options         _KPOSIX_PRIORITY_SCHEDULING #Posix P1003_1B real-time extensions
options         MUTEX_NOINLINE
options         RWLOCK_NOINLINE
#options        NO_FFS_SNAPSHOT
#options        NO_SWAPPING

# extra
options SW_WATCHDOG
options IPFIREWALL
options IPFIREWALL_FORWARD
options IPFIREWALL_DEFAULT_TO_ACCEPT
options IPFIREWALL_VERBOSE
options IPFIREWALL_VERBOSE_LIMIT=80
device ata
device atadisk # ATA disk drives
options ATA_STATIC_ID # Static device numbering

# Debugging
options         ALT_BREAK_TO_DEBUGGER
options         DDB
options         KDB

# Pseudo devices
device          random
device          pty
device          loop
device          md                      # Memory Disks
# Serial ports
device          uart

# Networking
device          ether
device          mge                     # Marvell Gigabit Ethernet controller
device          mii
device          e1000phy
device          bpf
options         HZ=1000
options         DEVICE_POLLING
device          vlan

# USB
options         USB_DEBUG       # enable debug msgs
device          usb
device          ehci
device          umass
device          scbus
device          pass
device          da

# Flattened Device Tree
options         FDT
options         FDT_DTB_STATIC
makeoptions     FDT_DTS_FILE=sheevaplug.dts


>How-To-Repeat:
run "portsnap fetch" on a guruplug server+ with the above configuration.
>Fix:


>Release-Note:
>Audit-Trail:

From: Tyler Saylor <wthww@680x0.com>
To: FreeBSD-gnats-submit@freebsd.org, freebsd-arm@freebsd.org
Cc:  
Subject: Re: arm/150581: Unknown error generates IRQ address decoding error
Date: Wed, 15 Sep 2010 05:17:14 -0400

 --e0cb4e8875659d65f7049048cb30
 Content-Type: text/plain; charset=ISO-8859-1
 
 Actually, this may not be an issue. I realized I applied patches meant for
 -stable to -current. I will checkout the source again and rebuild to see
 what happens.
 
 On Tue, Sep 14, 2010 at 10:10 PM, <FreeBSD-gnats-submit@freebsd.org> wrote:
 
 > Thank you very much for your problem report.
 > It has the internal identification `arm/150581'.
 > The individual assigned to look at your
 > report is: freebsd-arm.
 >
 > You can access the state of your problem report at any time
 > via this link:
 >
 > http://www.freebsd.org/cgi/query-pr.cgi?pr=150581
 >
 > >Category:       arm
 > >Responsible:    freebsd-arm
 > >Synopsis:       Unknown error generates IRQ address decoding error
 > >Arrival-Date:   Wed Sep 15 02:10:01 UTC 2010
 >
 
 --e0cb4e8875659d65f7049048cb30
 Content-Type: text/html; charset=ISO-8859-1
 Content-Transfer-Encoding: quoted-printable
 
 Actually, this may not be an issue. I realized I applied patches meant for =
 -stable to -current. I will checkout the source again and rebuild to see wh=
 at happens.<br><br><div class=3D"gmail_quote">On Tue, Sep 14, 2010 at 10:10=
  PM,  <span dir=3D"ltr">&lt;<a href=3D"mailto:FreeBSD-gnats-submit@freebsd.=
 org">FreeBSD-gnats-submit@freebsd.org</a>&gt;</span> wrote:<br>
 <blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; borde=
 r-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">Thank you very mu=
 ch for your problem report.<br>
 It has the internal identification `arm/150581&#39;.<br>
 The individual assigned to look at your<br>
 report is: freebsd-arm.<br>
 <br>
 You can access the state of your problem report at any time<br>
 via this link:<br>
 <br>
 <a href=3D"http://www.freebsd.org/cgi/query-pr.cgi?pr=3D150581" target=3D"_=
 blank">http://www.freebsd.org/cgi/query-pr.cgi?pr=3D150581</a><br>
 <br>
 &gt;Category: =A0 =A0 =A0 arm<br>
 &gt;Responsible: =A0 =A0freebsd-arm<br>
 &gt;Synopsis: =A0 =A0 =A0 Unknown error generates IRQ address decoding erro=
 r<br>
 &gt;Arrival-Date: =A0 Wed Sep 15 02:10:01 UTC 2010<br>
 </blockquote></div><br>
 
 --e0cb4e8875659d65f7049048cb30--

From: Johny Mattsson <johny.mattsson+fbsd@gmail.com>
To: Tyler Saylor <wthww@680x0.com>
Cc: FreeBSD-gnats-submit@freebsd.org, freebsd-arm@freebsd.org
Subject: Re: arm/150581: Unknown error generates IRQ address decoding error
Date: Fri, 17 Sep 2010 10:44:58 +1000

 --0003255753be3ea5ae049069df63
 Content-Type: text/plain; charset=UTF-8
 
 Hi Tyler,
 
 The issue could be the same that I'm having on my PogoPlug (stripped down
 version of the Sheevaplug essentially). I don't have a serial console on it,
 so I haven't been able to get any actual error messages, but I do experience
 the same hard hang when I have heavy USB I/O. I'm still working on resolving
 this issue properly, but I have found a work-around. If rolling back those
 patches didn't fix the problem for you, try limiting the amount of RAM the
 kernel sees down to 128MiB. For me, going from the actual 256MiB down to
 128MiB prevents the I/O lock-up and I have a stable system (I can in fact
 push it up to 131MiB, but above that it's bad news).
 
 To limit the RAM, open /usr/src/sys/boot/fdt/dts/sheevaplug.dts, find the
 "memory" entry and reduce it to 0x08000000, then rebuild your kernel.
 
 I'd be very interested in hearing whether this fixes your issue, as it's
 been quite frustrating to troubleshoot this without seeing what goes on the
 console when the hang occurs!
 
 Regards,
 /Johny
 
 --0003255753be3ea5ae049069df63
 Content-Type: text/html; charset=UTF-8
 Content-Transfer-Encoding: quoted-printable
 
 Hi Tyler,<br><br>The issue could be the same that I&#39;m having on my Pogo=
 Plug (stripped down version of the Sheevaplug essentially). I don&#39;t hav=
 e a serial console on it, so I haven&#39;t been able to get any actual erro=
 r messages, but I do experience the same hard hang when I have heavy USB I/=
 O. I&#39;m still working on resolving this issue properly, but I have found=
  a work-around. If rolling back those patches didn&#39;t fix the problem fo=
 r you, try limiting the amount of RAM the kernel sees down to 128MiB. For m=
 e, going from the actual 256MiB down to 128MiB prevents the I/O lock-up and=
  I have a stable system (I can in fact push it up to 131MiB, but above that=
  it&#39;s bad news).<br>
 <br>To limit the RAM, open /usr/src/sys/boot/fdt/dts/sheevaplug.dts, find t=
 he &quot;memory&quot; entry and reduce it to 0x08000000, then rebuild your =
 kernel.<br><br>I&#39;d be very interested in hearing whether this fixes you=
 r issue, as it&#39;s been quite frustrating to troubleshoot this without se=
 eing what goes on the console when the hang occurs!<br>
 <br>Regards,<br>/Johny<br>
 
 --0003255753be3ea5ae049069df63--

From: Johny Mattsson <johny.mattsson+fbsd@gmail.com>
To: Tyler Saylor <wthww@680x0.com>
Cc: FreeBSD-gnats-submit@freebsd.org, freebsd-arm@freebsd.org, 
	Mark Tinguely <marktinguely@gmail.com>
Subject: Re: arm/150581: Unknown error generates IRQ address decoding error [patch]
Date: Sat, 18 Sep 2010 19:01:51 +1000

 --005045013dcc1b66c1049084eec3
 Content-Type: multipart/alternative; boundary=005045013dcc1b66bb049084eec1
 
 --005045013dcc1b66bb049084eec1
 Content-Type: text/plain; charset=UTF-8
 
 Hi Tyler (and list),
 
 It turned out this was the same issue I've been trying to hunt down the
 cause of for a couple of weeks. With a lot of help from Mark Tinguely I've
 finally nailed it.
 
 This problem is caused by a double-whammy of bugs.
 
 First of all, the USB bridge address decoding register definitions fail to
 account for the main offset from the base of the USB port range. This means
 that decode_win_usb_setup() in sys/arm/mv/common.c doesn't actually manage
 to set up the windows properly. Instead of poking the address decoding
 registers it writes to the ID and HWGENERAL registers, and possibly others
 depending on how much RAM is installed. As a result of not getting the
 windows set up properly, the USB controller ends up only being capable of
 decoding a limited range of addresses. The precise range might depend on how
 the boot loader initialized the controller, or it might use a default range.
 As I only have one type of hardware I can't readily verify which it is.
 
 With the incorrect windows established, under heavy USB I/O the controller
 typically ends up trying to decode an address which is outside its
 window(s), and raises an error interrupt for it. This in itself is not
 fatal.
 
 The actual hang is caused by a failure to sufficiently clear the error
 condition in the error interrupt handler (err_intr() in
 dev/usb/controllers/ehci_mv.c). For an address decode error, it is necessary
 to read out the error address from the bridge error address register.
 Failure to do so before returning from the interrupt handler causes the
 interrupt to be reissued.
 
 The attached patch addresses both issues. I have successfully tested it on
 my 88F6281 based Pogoplug, and I have verified the register addresses
 against the 88F5281 documentation.
 
 Unless someone can find fault with this patch, I'd love to see this
 committed.
 
 Regards,
 /Johny
 
 --005045013dcc1b66bb049084eec1
 Content-Type: text/html; charset=UTF-8
 Content-Transfer-Encoding: quoted-printable
 
 Hi Tyler (and list),<br><br>It turned out this was the same issue I&#39;ve =
 been trying to hunt down the cause of for a couple of weeks. With a lot of =
 help from Mark Tinguely I&#39;ve finally nailed it.<br><br>This problem is =
 caused by a double-whammy of bugs.<br>
 <br>First of all, the USB bridge address decoding register definitions fail=
  to account for the main offset from the base of the USB port range. This m=
 eans that decode_win_usb_setup() in sys/arm/mv/common.c doesn&#39;t actuall=
 y manage to set up the windows properly. Instead of poking the address deco=
 ding registers it writes to the ID and HWGENERAL registers, and possibly ot=
 hers depending on how much RAM is installed. As a result of not getting the=
  windows set up properly, the USB controller ends up only being capable of =
 decoding a limited range of addresses. The precise range might depend on ho=
 w the boot loader initialized the controller, or it might use a default ran=
 ge. As I only have one type of hardware I can&#39;t readily verify which it=
  is.<br>
 <br>With the incorrect windows established, under heavy USB I/O the control=
 ler typically ends up trying to decode an address which is outside its wind=
 ow(s), and raises an error interrupt for it. This in itself is not fatal.<b=
 r>
 <br>The actual hang is caused by a failure to sufficiently clear the error =
 condition in the error interrupt handler (err_intr() in dev/usb/controllers=
 /ehci_mv.c). For an address decode error, it is necessary to read out the e=
 rror address from the bridge error address register. Failure to do so befor=
 e returning from the interrupt handler causes the interrupt to be reissued.=
 <br>
 <br>The attached patch addresses both issues. I have successfully tested it=
  on my 88F6281 based Pogoplug, and I have verified the register addresses a=
 gainst the 88F5281 documentation.<br><br>Unless someone can find fault with=
  this patch, I&#39;d love to see this committed.<br>
 <br>Regards,<br>/Johny<br>
 
 --005045013dcc1b66bb049084eec1--
 --005045013dcc1b66c1049084eec3
 Content-Type: application/octet-stream; name="arm150581.patch"
 Content-Disposition: attachment; filename="arm150581.patch"
 Content-Transfer-Encoding: base64
 X-Attachment-Id: f_ge88ndz60
 
 LS0tIHN5cy9kZXYvdXNiL2NvbnRyb2xsZXIvZWhjaV9tdi5jLm9yaWcJMjAxMC0wOS0xNyAxODo1
 NjowMy4wMDAwMDAwMDAgKzEwMDAKKysrIHN5cy9kZXYvdXNiL2NvbnRyb2xsZXIvZWhjaV9tdi5j
 CTIwMTAtMDktMTggMTg6Mjc6MzYuMDAwMDAwMDAwICsxMDAwCkBAIC05Niw2ICs5Niw3IEBACiAK
 ICNkZWZpbmUJVVNCX0JSSURHRV9JTlRSX0NBVVNFICAweDIxMAogI2RlZmluZQlVU0JfQlJJREdF
 X0lOVFJfTUFTSyAgIDB4MjE0CisjZGVmaW5lCVVTQl9CUklER0VfRVJSX0FERFIgICAgMHgyMUMK
 IAogI2RlZmluZQlNVl9VU0JfQUREUl9ERUNPREVfRVJSICgxIDw8IDApCiAjZGVmaW5lCU1WX1VT
 Ql9IT1NUX1VOREVSRkxPVyAgKDEgPDwgMSkKQEAgLTM2MCw2ICszNjEsMjEgQEAKIAkJCXByaW50
 ZigiSVJRIEVSUjogVW5rbm93biBlcnJvclxuIik7CiAKIAkJRVdSSVRFNChzYywgVVNCX0JSSURH
 RV9JTlRSX0NBVVNFLCAwKTsKKworCQkvKgorCQkgKiBJbiBjYXNlIG9mIGFuIGFkZHJlc3MgZGVj
 b2RlIGVycm9yLCB3ZSBtdXN0IHJlYWQgZnJvbQorCQkgKiB0aGUgVVNCX0JSSURHRV9FUlJfQURE
 UiByZWdpc3RlciB0byBjbGVhciBpdCB0byBhbGxvdworCQkgKiB0aGUgY29udHJvbGxlciB0byBs
 YXRjaCBhIG5ldyBhZGRyZXNzIGluIG5leHQgdGltZSB0aGlzCisJCSAqIGVycm9yIG9jY3Vycy4g
 SWYgd2UgZG9uJ3QgcmVhZCBpdCwgd2UgZ2V0IHRoZSBpbnRlcnJ1cHQKKwkJICogcmVpc3N1ZWQg
 YWQgaW5maW5pdHVtLCBldmVuIHRob3VnaCB3ZSBoYXZlIGNsZWFyZWQgdGhlCisJCSAqIGludGVy
 cnVwdCBjYXVzZS4KKwkJICovCisJCWlmIChjYXVzZSAmIE1WX1VTQl9BRERSX0RFQ09ERV9FUlIp
 CisJCXsKKwkJCXVuc2lnbmVkIGVycmFkZHIgPSBFUkVBRDQoc2MsIFVTQl9CUklER0VfRVJSX0FE
 RFIpOworCQkJcHJpbnRmKCJJUlEgRVJSOiBVU0IgQnJpZGdlIEVycm9yIEFkZHJlc3M6IDB4JTA4
 eFxuIiwKKwkJCQllcnJhZGRyKTsKKwkJfQogCX0KIAlyZXR1cm4gKEZJTFRFUl9IQU5ETEVEKTsK
 IH0KLS0tIHN5cy9hcm0vbXYvbXZ3aW4uaC5vcmlnCTIwMTAtMDktMTggMTg6MTM6MDkuMDAwMDAw
 MDAwICsxMDAwCisrKyBzeXMvYXJtL212L212d2luLmgJMjAxMC0wOS0xOCAxODoxNzo0NC4wMDAw
 MDAwMDAgKzEwMDAKQEAgLTEzOCw4ICsxMzgsOCBAQAogI2RlZmluZSBNVl9XSU5fQ0VTQV9BVFRS
 CQkwCiAjZW5kaWYKIAotI2RlZmluZSBNVl9XSU5fVVNCX0NUUkwobikJCSgweDEwICogKG4pICsg
 MHgwKQotI2RlZmluZSBNVl9XSU5fVVNCX0JBU0UobikJCSgweDEwICogKG4pICsgMHg0KQorI2Rl
 ZmluZSBNVl9XSU5fVVNCX0NUUkwobikJCSgweDEwICogKG4pICsgMHgzMjApCisjZGVmaW5lIE1W
 X1dJTl9VU0JfQkFTRShuKQkJKDB4MTAgKiAobikgKyAweDMyNCkKICNkZWZpbmUgTVZfV0lOX1VT
 Ql9NQVgJCQk0CiAKICNkZWZpbmUgTVZfV0lOX0VUSF9CQVNFKG4pCQkoMHg4ICogKG4pICsgMHgy
 MDApCg==
 --005045013dcc1b66c1049084eec3--
>Unformatted:
