From owner-freebsd-stable@FreeBSD.ORG Sun Apr 5 16:28:32 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F1355106566C for ; Sun, 5 Apr 2009 16:28:32 +0000 (UTC) (envelope-from Martin.Blapp@t-systems.ch) Received: from mail100.t-systems.ch (mail109.t-systems.ch [193.108.232.23]) by mx1.freebsd.org (Postfix) with ESMTP id 6B50F8FC18 for ; Sun, 5 Apr 2009 16:28:32 +0000 (UTC) (envelope-from Martin.Blapp@t-systems.ch) Received: from wsairz0042.t-systems.ch (Not Verified[53.250.54.32]) by mail100.t-systems.ch with MailMarshal (using TLS: SSLv23) id ; Sun, 05 Apr 2009 18:18:14 +0200 Received: from TSS-EXCH01.t-systems.ch ([53.250.54.26]) by wsairz0042.t-systems.ch ([53.250.54.32]) with mapi; Sun, 5 Apr 2009 18:18:14 +0200 From: "Blapp, Martin" To: "freebsd-stable@freebsd.org" Date: Sun, 5 Apr 2009 18:18:13 +0200 Thread-Topic: FreeBSD 7.2-BETA1 tcp retransmit crash Thread-Index: AQHJtgoelLc+aRYgDk+FO6S3KnQ39Q== Message-ID: <509A7CA1EA3EA046B1A5BA2FCFDB3C8EC764853900@TSS-EXCH01.t-systems.ch> Accept-Language: de-DE, de-CH Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, de-CH Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 HC: x Subject: FreeBSD 7.2-BETA1 tcp retransmit crash X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Apr 2009 16:28:33 -0000 Hi all, Looks like the same problem as PR 129197 (FreeBSD 7 panic) http://www.freebsd.org/cgi/query-pr.cgi?pr=3D129197 OS: FreeBSD 7.2 BETA1 PF: Enabled SACK: net.inet.tcp.sack.enable: 1 Happens after some/many soabort calls ... I can reproduce it after 3-4 hours running time. Currently I'm testing a workaround but I guess the underlying problem should be fixed. -- Martin Fatal trap 12: page fault while in kernel mode cpuid =3D 1; apic id =3D 01 fault virtual address =3D 0xc fault code =3D supervisor read, page not present instruction pointer =3D 0x20:0xc07c6cb0 stack pointer =3D 0x28:0xc2f9c97c frame pointer =3D 0x28:0xc2f9c984 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 25 (em0 taskq) trap number =3D 12 panic: page fault cpuid =3D 1 Uptime: 4h12m47s Physical memory: 499 MB Dumping 104 MB: 89 73 57 41 25 9 Reading symbols from /boot/kernel/acpi.ko...Reading symbols from /boot/kern= el/acpi.ko.symbols...done. done. Loaded symbols for /boot/kernel/acpi.ko Reading symbols from /usr/local/lib/vmware-tools/modules/drivers/vmmemctl.k= o...done. Loaded symbols for /usr/local/lib/vmware-tools/modules/drivers/vmmemctl.ko Reading symbols from /usr/local/lib/vmware-tools/modules/drivers/vmxnet.ko.= ..done. Loaded symbols for /usr/local/lib/vmware-tools/modules/drivers/vmxnet.ko Reading symbols from /usr/local/lib/vmware-tools/modules/drivers/vmblock.ko= ...done. Loaded symbols for /usr/local/lib/vmware-tools/modules/drivers/vmblock.ko Reading symbols from /usr/local/lib/vmware-tools/modules/drivers/vmhgfs.ko.= ..done. Loaded symbols for /usr/local/lib/vmware-tools/modules/drivers/vmhgfs.ko Reading symbols from /boot/kernel/pf.ko...Reading symbols from /boot/kernel= /pf.ko.symbols...done. done. Loaded symbols for /boot/kernel/pf.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/modules/accf_smtp.ko...done. Loaded symbols for /boot/modules/accf_smtp.ko #0 doadump () at pcpu.h:196 #1 0xc0772d87 in boot (howto=3D260) at /usr/src/sys/kern/kern_shutdown.c:4= 18 #2 0xc0773059 in panic (fmt=3DVariable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:574 #3 0xc0a5062c in trap_fatal (frame=3D0xc2f9c93c, eva=3D12) at /usr/src/sys= /i386/i386/trap.c:939 #4 0xc0a508b0 in trap_pfault (frame=3D0xc2f9c93c, usermode=3D0, eva=3D12) = at /usr/src/sys/i386/i386/trap.c:852 #5 0xc0a5125c in trap (frame=3D0xc2f9c93c) at /usr/src/sys/i386/i386/trap.= c:530 #6 0xc0a3593b in calltrap () at /usr/src/sys/i386/i386/exception.s:159 #7 0xc07c6cb0 in sbsndptr (sb=3D0xc342ede4, off=3D112, len=3D113, moff=3D0= xc2f9ca04) at /usr/src/sys/kern/uipc_sockbuf.c:939 #8 0xc089cd64 in tcp_output (tp=3D0xc43311d0) at /usr/src/sys/netinet/tcp_= output.c:798 #9 0xc089974a in tcp_do_segment (m=3D0xc34a6600, th=3D0xc34c8024, so=3D0xc= 342ed00, tp=3D0xc43311d0, drop_hdrlen=3D52, tlen=3D0) at /usr/src/sys/netinet/tcp_input.c:1835 #10 0xc089b2ee in tcp_input (m=3D0xc34a6600, off0=3D20) at /usr/src/sys/net= inet/tcp_input.c:846 #11 0xc08340a0 in ip_input (m=3D0xc34a6600) at /usr/src/sys/netinet/ip_inpu= t.c:664 #12 0xc081ae15 in netisr_dispatch (num=3D2, m=3D0xc34a6600) at /usr/src/sys= /net/netisr.c:185 #13 0xc0810d81 in ether_demux (ifp=3D0xc31bb400, m=3D0xc34a6600) at /usr/sr= c/sys/net/if_ethersubr.c:834 #14 0xc0811173 in ether_input (ifp=3D0xc31bb400, m=3D0xc34a6600) at /usr/sr= c/sys/net/if_ethersubr.c:692 #15 0xc0561f2a in em_rxeof (adapter=3D0xc31bc000, count=3D99) at /usr/src/s= ys/dev/e1000/if_em.c:4539 #16 0xc0562a57 in em_handle_rxtx (context=3D0xc31bc000, pending=3D1) at /us= r/src/sys/dev/e1000/if_em.c:1702 #17 0xc07a8015 in taskqueue_run (queue=3D0xc3181780) at /usr/src/sys/kern/s= ubr_taskqueue.c:282 #18 0xc07a8228 in taskqueue_thread_loop (arg=3D0xc31c035c) at /usr/src/sys/= kern/subr_taskqueue.c:401 #19 0xc074d839 in fork_exit (callout=3D0xc07a8160 , = arg=3D0xc31c035c, frame=3D0xc2f9cd38) at /usr/src/sys/kern/kern_fork.c:810 #20 0xc0a359b0 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:= 264 (kgdb) frame 7 #7 0xc07c6cb0 in sbsndptr (sb=3D0xc342ede4, off=3D112, len=3D113, moff=3D0= xc2f9ca04) at /usr/src/sys/kern/uipc_sockbuf.c:939 939 off > 0 && off >=3D m->m_len; (kgdb) list 934 *moff =3D off - sb->sb_sndptroff; 935 m =3D ret =3D sb->sb_sndptr ? sb->sb_sndptr : sb->sb_mb; 936 937 /* Advance by len to be as close as possible for the next t= ransmit. */ 938 for (off =3D off - sb->sb_sndptroff + len - 1; 939 off > 0 && off >=3D m->m_len; 940 m =3D m->m_next) { 941 sb->sb_sndptroff +=3D m->m_len; 942 off -=3D m->m_len; 943 } (kgdb) p sb->sb_sndptr $1 =3D (struct mbuf *) 0x0 (kgdb) p sb->sb_mb $2 =3D (struct mbuf *) 0x0 Kein Wunder gibts da nen Crash ... (kgdb) p *sb $8 =3D {sb_sel =3D {si_thrlist =3D {tqe_next =3D 0x0, tqe_prev =3D 0x0}, si= _thread =3D 0x0, si_note =3D {kl_list =3D {slh_first =3D 0x0}, kl_lock =3D 0xc0747700 , kl_unlock =3D 0xc07470e0 , kl_locked =3D 0xc07470c0 , kl_lockarg =3D 0xc342ee08}, si_flags =3D 0}, sb_mtx =3D {lock_object = =3D {lo_name =3D 0xc0ad4ad8 "so_snd", lo_type =3D 0xc0ad4ad8 "so_snd", lo_f= lags =3D 16973824, lo_witness_data =3D {lod_list =3D {stqe_next =3D 0x0}, lod_witness = =3D 0x0}}, mtx_lock =3D 3272403696, mtx_recurse =3D 0}, sb_sx =3D {lock_obj= ect =3D { lo_name =3D 0xc0ad4ae6 "so_snd_sx", lo_type =3D 0xc0ad4ae6 "so_snd_sx= ", lo_flags =3D 37421056, lo_witness_data =3D {lod_list =3D {stqe_next =3D = 0x0}, lod_witness =3D 0x0}}, sx_lock =3D 1, sx_recurse =3D 0}, sb_state = =3D 16, sb_mb =3D 0x0, sb_mbtail =3D 0x0, sb_lastrecord =3D 0x0, sb_sndptr = =3D 0x0, sb_sndptroff =3D 0, sb_cc =3D 0, sb_hiwat =3D 33580, sb_mbcnt =3D 0, sb_m= cnt =3D 0, sb_ccnt =3D 0, sb_mbmax =3D 262144, sb_ctl =3D 0, sb_lowat =3D 2= 048, sb_timeo =3D 0, sb_flags =3D 2048} (kgdb) f 8 #8 0xc089cd64 in tcp_output (tp=3D0xc43311d0) at /usr/src/sys/netinet/tcp_= output.c:798 798 mb =3D sbsndptr(&so->so_snd, off, len, &moff); p *so $9 =3D {so_count =3D 0, so_type =3D 1, so_options =3D 12, so_linger =3D 0, = so_state =3D 24633, so_qstate =3D 2048, so_pcb =3D 0xc40e0708, so_proto =3D= 0xc0b994a8, so_head =3D 0xc4056b60, so_incomp =3D {tqh_first =3D 0x0, tqh_last =3D 0x= 0}, so_comp =3D {tqh_first =3D 0x0, tqh_last =3D 0x0}, so_list =3D {tqe_nex= t =3D 0x0, tqe_prev =3D 0xc445b02c}, so_qlen =3D 0, so_incqlen =3D 0, so_qlimit = =3D 0, so_timeo =3D 0, so_error =3D 0, so_sigio =3D 0x0, so_oobmark =3D 0, = so_aiojobq =3D { tqh_first =3D 0x0, tqh_last =3D 0xc342ed48}, so_rcv =3D {sb_sel =3D {si= _thrlist =3D {tqe_next =3D 0x0, tqe_prev =3D 0x0}, si_thread =3D 0x0, si_no= te =3D {kl_list =3D { slh_first =3D 0x0}, kl_lock =3D 0xc0747700 , kl_= unlock =3D 0xc07470e0 , kl_locked =3D 0xc07470c0 , kl_lockarg =3D 0xc342ed74}, si_flags =3D 0}, sb_mtx =3D {lock_objec= t =3D {lo_name =3D 0xc0ad4adf "so_rcv", lo_type =3D 0xc0ad4adf "so_rcv", lo_flags =3D 16973824, lo_witness_data =3D {lod_list =3D {stqe_next= =3D 0x0}, lod_witness =3D 0x0}}, mtx_lock =3D 4, mtx_recurse =3D 0}, sb_sx= =3D {lock_object =3D { lo_name =3D 0xc0ad4af0 "so_rcv_sx", lo_type =3D 0xc0ad4af0 "so_rcv_= sx", lo_flags =3D 37421056, lo_witness_data =3D {lod_list =3D {stqe_next = =3D 0x0}, lod_witness =3D 0x0}}, sx_lock =3D 1, sx_recurse =3D 0}, sb_state= =3D 32, sb_mb =3D 0x0, sb_mbtail =3D 0x0, sb_lastrecord =3D 0x0, sb_sndptr= =3D 0x0, sb_sndptroff =3D 0, sb_cc =3D 0, sb_hiwat =3D 65700, sb_mbcnt =3D 0, sb= _mcnt =3D 0, sb_ccnt =3D 0, sb_mbmax =3D 262144, sb_ctl =3D 0, sb_lowat =3D= 1, sb_timeo =3D 0, sb_flags =3D 2048}, so_snd =3D {sb_sel =3D {si_thrlist =3D {tqe_next = =3D 0x0, tqe_prev =3D 0x0}, si_thread =3D 0x0, si_note =3D {kl_list =3D {sl= h_first =3D 0x0}, kl_lock =3D 0xc0747700 , kl_unlock =3D 0xc07470e0 = , kl_locked =3D 0xc07470c0 , kl_lockarg =3D 0xc342ee08}, si_flags =3D 0}, sb_mtx =3D {lock_objec= t =3D {lo_name =3D 0xc0ad4ad8 "so_snd", lo_type =3D 0xc0ad4ad8 "so_snd", lo_flags =3D 16973824, lo_witness_data =3D {lod_list =3D {stqe_next= =3D 0x0}, lod_witness =3D 0x0}}, mtx_lock =3D 3272403696, mtx_recurse =3D = 0}, sb_sx =3D { lock_object =3D {lo_name =3D 0xc0ad4ae6 "so_snd_sx", lo_type =3D 0xc0= ad4ae6 "so_snd_sx", lo_flags =3D 37421056, lo_witness_data =3D {lod_list = =3D { stqe_next =3D 0x0}, lod_witness =3D 0x0}}, sx_lock =3D 1, sx_re= curse =3D 0}, sb_state =3D 16, sb_mb =3D 0x0, sb_mbtail =3D 0x0, sb_lastrec= ord =3D 0x0, sb_sndptr =3D 0x0, sb_sndptroff =3D 0, sb_cc =3D 0, sb_hiwat =3D 33580,= sb_mbcnt =3D 0, sb_mcnt =3D 0, sb_ccnt =3D 0, sb_mbmax =3D 262144, sb_ctl = =3D 0, sb_lowat =3D 2048, sb_timeo =3D 0, sb_flags =3D 2048}, so_upcall =3D 0, so_upcallarg =3D 0= x5dc0, so_cred =3D 0xc4260900, so_label =3D 0x0, so_peerlabel =3D 0x0, so_g= encnt =3D 118111, so_emuldata =3D 0x0, so_accf =3D 0x0, so_fibnum =3D 0} (kgdb) p so->so_snd $10 =3D {sb_sel =3D {si_thrlist =3D {tqe_next =3D 0x0, tqe_prev =3D 0x0}, s= i_thread =3D 0x0, si_note =3D {kl_list =3D {slh_first =3D 0x0}, kl_lock =3D 0xc0747700 , kl_unlock =3D 0xc07470e0 , kl_locked =3D 0xc07470c0 , kl_lockarg =3D 0xc342ee08}, si_flags =3D 0}, sb_mtx =3D {lock_object = =3D {lo_name =3D 0xc0ad4ad8 "so_snd", lo_type =3D 0xc0ad4ad8 "so_snd", lo_f= lags =3D 16973824, lo_witness_data =3D {lod_list =3D {stqe_next =3D 0x0}, lod_witness = =3D 0x0}}, mtx_lock =3D 3272403696, mtx_recurse =3D 0}, sb_sx =3D {lock_obj= ect =3D { lo_name =3D 0xc0ad4ae6 "so_snd_sx", lo_type =3D 0xc0ad4ae6 "so_snd_sx= ", lo_flags =3D 37421056, lo_witness_data =3D {lod_list =3D {stqe_next =3D = 0x0}, lod_witness =3D 0x0}}, sx_lock =3D 1, sx_recurse =3D 0}, sb_state = =3D 16, sb_mb =3D 0x0, sb_mbtail =3D 0x0, sb_lastrecord =3D 0x0, sb_sndptr = =3D 0x0, sb_sndptroff =3D 0, sb_cc =3D 0, sb_hiwat =3D 33580, sb_mbcnt =3D 0, sb_m= cnt =3D 0, sb_ccnt =3D 0, sb_mbmax =3D 262144, sb_ctl =3D 0, sb_lowat =3D 2= 048, sb_timeo =3D 0, sb_flags =3D 2048} (kgdb) f 10 #10 0xc089b2ee in tcp_input (m=3D0xc34a6600, off0=3D20) at /usr/src/sys/net= inet/tcp_input.c:846 846 tcp_do_segment(m, th, so, tp, drop_hdrlen, tlen); (kgdb) p m $13 =3D (struct mbuf *) 0xc34a6600 (kgdb) p *m $14 =3D {m_hdr =3D {mh_next =3D 0x0, mh_nextpkt =3D 0x0, mh_data =3D 0xc34c= 8010 "E", mh_len =3D 52, mh_flags =3D 3, mh_type =3D 1, pad =3D "\000"}, M_= dat =3D {MH =3D { MH_pkthdr =3D {rcvif =3D 0xc31bb400, header =3D 0x0, len =3D 52, csum= _flags =3D 3840, csum_data =3D 65535, tso_segsz =3D 0, ether_vtag =3D 0, ta= gs =3D { slh_first =3D 0xc4c06b80}}, MH_dat =3D {MH_ext =3D {ext_buf =3D 0= xc34c8000 "\005", ext_free =3D 0, ext_args =3D 0x0, ext_size =3D 2048, ref_= cnt =3D 0xc34af9dc, ext_type =3D 6}, MH_databuf =3D "\000\200L=C3\000\000\000\000\000\000\000\000\000\b\= 000\000=DC=F9J=C3\006\000\000\000e\224=EC\"\230\0058>\a=DC6\217F=E4=EE=CD?= =B4=CA=C6=C3L=A9\tc\021=DBk=EB=ED=BEs\177=D2\211=ADy\214\020\rXr=BB&yPI\v^N= \210=A1=DF[\005=BD=AA=B9@=C8d/\003\215=FC=AE\2205=AD=B9RE$\003\020=CEf\035O= 0G=CF=DE\216U\"=EB=E5=B3=F5=B8\215`\002=E2=C9=C2\n\212=BE\207=EFr\036=EB=E6= j=B0=E4=DB=A8HU\234\034=C6=A4=AA.=DAb=DA\031\220=DB=AF=EDAe=A9\0333\207=FFz= =F3=BD \025v=A5<\a=AFZ=CE\205W<=B2\233'\205\002)\nRk=CA=E4]\024>\214=F5\217= \217p]\230=D4w>=BAs=C4"...}}, M_databuf =3D "\000=B4\033=C3\000\000\000\0004\000\000\000\000\017\000\= 000=FF=FF\000\000\000\000\000\000\200k=C0=C4\000\200L=C3\000\000\000\000\00= 0\000\000\000\000\b\000\000=DC=F9J=C3\006\000\000\000e\224=EC\"\230\0058>\a= =DC6\217F=E4=EE=CD?=B4=CA=C6=C3L=A9\tc\021=DBk=EB=ED=BEs\177=D2\211=ADy\214= \020\rXr=BB&yPI\v^N\210=A1=DF[\005=BD=AA=B9@=C8d/\003\215=FC=AE\2205=AD=B9R= E$\003\020=CEf\035O0G=CF=DE\216U\"=EB=E5=B3=F5=B8\215`\002=E2=C9=C2\n\212= =BE\207=EFr\036=EB=E6j=B0=E4=DB=A8HU\234\034=C6=A4=AA.=DAb=DA\031\220=DB=AF= =EDAe=A9\0333\207=FFz=F3=BD \025v=A5<\a=AFZ=CE\205W"...}}= From owner-freebsd-stable@FreeBSD.ORG Sun Apr 5 16:37:51 2009 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 923C7106566B for ; Sun, 5 Apr 2009 16:37:51 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by mx1.freebsd.org (Postfix) with ESMTP id 2BB438FC0A for ; Sun, 5 Apr 2009 16:37:51 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: (qmail 19282 invoked by uid 399); 5 Apr 2009 16:37:47 -0000 Received: from localhost (HELO 192-168-1-103.nodomain) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 5 Apr 2009 16:37:47 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <49D783AD.6090408@FreeBSD.org> Date: Sat, 04 Apr 2009 08:58:37 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 2.0.0.21 (X11/20090321) MIME-Version: 1.0 To: =?UTF-8?B?SG9yc3QgR8O8bnRoZXIgQnVya2hhcmR0IElJSQ==?= References: <18fb180c21bb7e10f6c7fd878ffde0a3@localhost.localdomain> <1238759663.2433.10.camel@horst-tla> In-Reply-To: <1238759663.2433.10.camel@horst-tla> X-Enigmail-Version: 0.95.7 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Vahid Chitsazzadeh , stable@freebsd.org Subject: Re: Check out my photos on Facebook X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Apr 2009 16:37:51 -0000 Please don't respond to spam e-mail on FreeBSD mailing lists, it just creates more spam. I never saw the actual spam, my filter handled it, but I did see all these followups. Also, please don't use profanity on the FreeBSD mailing lists. Thanks, Doug -- This .signature sanitized for your protection From owner-freebsd-stable@FreeBSD.ORG Sun Apr 5 16:59:04 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9C5EE106564A for ; Sun, 5 Apr 2009 16:59:04 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [195.88.108.3]) by mx1.freebsd.org (Postfix) with ESMTP id 55BA28FC19 for ; Sun, 5 Apr 2009 16:59:04 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id 82DB941C730; Sun, 5 Apr 2009 18:40:06 +0200 (CEST) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([195.88.108.3]) by localhost (amavis.fra.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id pTNKOSCfLlri; Sun, 5 Apr 2009 18:40:06 +0200 (CEST) Received: by mail.cksoft.de (Postfix, from userid 66) id 1CD4541C729; Sun, 5 Apr 2009 18:40:06 +0200 (CEST) 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 1D2F64448E6; Sun, 5 Apr 2009 16:39:31 +0000 (UTC) Date: Sun, 5 Apr 2009 16:39:31 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: "Blapp, Martin" In-Reply-To: <509A7CA1EA3EA046B1A5BA2FCFDB3C8EC764853900@TSS-EXCH01.t-systems.ch> Message-ID: <20090405163705.U15361@maildrop.int.zabbadoz.net> References: <509A7CA1EA3EA046B1A5BA2FCFDB3C8EC764853900@TSS-EXCH01.t-systems.ch> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "freebsd-stable@freebsd.org" Subject: Re: FreeBSD 7.2-BETA1 tcp retransmit crash X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Apr 2009 16:59:05 -0000 On Sun, 5 Apr 2009, Blapp, Martin wrote: Hi Martin, > Looks like the same problem as PR 129197 (FreeBSD 7 panic) > > http://www.freebsd.org/cgi/query-pr.cgi?pr=129197 > > OS: FreeBSD 7.2 BETA1 > PF: Enabled > SACK: net.inet.tcp.sack.enable: 1 > > Happens after some/many soabort calls ... I can reproduce it > after 3-4 hours running time. Currently I'm testing a workaround > but I guess the underlying problem should be fixed. I had added a few assertions to HEAD last autumn to catch (possibly different) but still same panics that I haven't MFCed yet. I'll try to get the list of revisions together and get you a diff. With that I'd expect you to either hit a KASSERT or a pnic. -- Bjoern A. Zeeb The greatest risk is not taking one. From owner-freebsd-stable@FreeBSD.ORG Sun Apr 5 18:30:07 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5B5B910657C3 for ; Sun, 5 Apr 2009 18:30:07 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [195.88.108.3]) by mx1.freebsd.org (Postfix) with ESMTP id 144C58FC08 for ; Sun, 5 Apr 2009 18:30:06 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id CCF9F41C759; Sun, 5 Apr 2009 20:30:05 +0200 (CEST) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([195.88.108.3]) by localhost (amavis.fra.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id S2bpgfVQG4ZK; Sun, 5 Apr 2009 20:30:05 +0200 (CEST) Received: by mail.cksoft.de (Postfix, from userid 66) id 5C72641C751; Sun, 5 Apr 2009 20:30:05 +0200 (CEST) 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 605444448E6; Sun, 5 Apr 2009 18:27:16 +0000 (UTC) Date: Sun, 5 Apr 2009 18:27:16 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: "Blapp, Martin" In-Reply-To: <20090405163705.U15361@maildrop.int.zabbadoz.net> Message-ID: <20090405180621.F15361@maildrop.int.zabbadoz.net> References: <509A7CA1EA3EA046B1A5BA2FCFDB3C8EC764853900@TSS-EXCH01.t-systems.ch> <20090405163705.U15361@maildrop.int.zabbadoz.net> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "freebsd-stable@freebsd.org" Subject: Re: FreeBSD 7.2-BETA1 tcp retransmit crash X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Apr 2009 18:30:07 -0000 On Sun, 5 Apr 2009, Bjoern A. Zeeb wrote: Hi, > On Sun, 5 Apr 2009, Blapp, Martin wrote: > > Hi Martin, > >> Looks like the same problem as PR 129197 (FreeBSD 7 panic) >> >> http://www.freebsd.org/cgi/query-pr.cgi?pr=129197 >> >> OS: FreeBSD 7.2 BETA1 >> PF: Enabled >> SACK: net.inet.tcp.sack.enable: 1 >> >> Happens after some/many soabort calls ... I can reproduce it >> after 3-4 hours running time. Currently I'm testing a workaround >> but I guess the underlying problem should be fixed. > > I had added a few assertions to HEAD last autumn to catch (possibly > different) but still same panics that I haven't MFCed yet. > > I'll try to get the list of revisions together and get you a diff. > With that I'd expect you to either hit a KASSERT or a pnic. Here's the patch of what I found was left un-MFCed: http://people.freebsd.org/~bz/20090405-mfc-r182841-r182842.diff According to your gdb output you are not getting to sbsndptr() with an invalid length so it's less likely to hit the KASSERT(). It would be interesting to see if at least the sbsndptr() patch works and gives you the panic. In that case I'd finally have a positive confirmation that those changes are right and MFC them;-) The ways I had found to hit this had been fixed a year ago and properly MFCed. This one sounds more like a race and other memory problem. What kind of patch are you testing? /bz -- Bjoern A. Zeeb The greatest risk is not taking one. From owner-freebsd-stable@FreeBSD.ORG Mon Apr 6 02:04:49 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4A74B106566B for ; Mon, 6 Apr 2009 02:04:49 +0000 (UTC) (envelope-from vas@mpeks.tomsk.su) Received: from relay2.tomsk.ru (relay2.tomsk.ru [212.73.124.8]) by mx1.freebsd.org (Postfix) with ESMTP id 6752F8FC15 for ; Mon, 6 Apr 2009 02:04:47 +0000 (UTC) (envelope-from vas@mpeks.tomsk.su) X-Virus-Scanned: by clamd daemon 0.93.1 for FreeBSD at relay2.tomsk.ru Received: from admin.sibptus.tomsk.ru (account sudakov@sibptus.tomsk.ru [212.73.125.240] verified) by relay2.tomsk.ru (CommuniGate Pro SMTP 5.1.13) with ESMTPSA id 12243585 for freebsd-stable@freebsd.org; Mon, 06 Apr 2009 09:04:46 +0700 Received: (from sudakov@localhost) by admin.sibptus.tomsk.ru (8.13.6/8.13.6/Submit) id n3624kRv078865 for freebsd-stable@freebsd.org; Mon, 6 Apr 2009 09:04:46 +0700 (OMSST) (envelope-from vas@mpeks.tomsk.su) X-Authentication-Warning: admin.sibptus.tomsk.ru: sudakov set sender to vas@mpeks.tomsk.su using -f Date: Mon, 6 Apr 2009 09:04:46 +0700 From: Victor Sudakov To: freebsd-stable@freebsd.org Message-ID: <20090406020446.GD78037@admin.sibptus.tomsk.ru> Mail-Followup-To: Victor Sudakov , freebsd-stable@freebsd.org References: <20090402044358.GA34249@admin.sibptus.tomsk.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090402044358.GA34249@admin.sibptus.tomsk.ru> User-Agent: Mutt/1.4.2.3i Organization: AO "Svyaztransneft", SibPTUS X-PGP-Key: http://vas.tomsk.ru/vas.asc Subject: Re: Failure to make world for RELENG_6_4 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2009 02:04:49 -0000 Victor Sudakov wrote: > > I have recently submitted 2 PRs > misc/133066 This one was due to a dirty source tree. > misc/133264 This one however is not so simple. I have tried building world under VMWare ESXi 3.5.0 Update 3 (FreeBSD as a guest OS) and the building process crashed occasionally if more than 1 CPU is allocated to the virtual machine. The failures are due to various processes like sh, sed or cc1 dupming core on signal 11 during the build. The problem seems to be SMP related because enabling only 1 virtual CPU removes the problem. Of course it is also VMWare related. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:sudakov@sibptus.tomsk.ru From owner-freebsd-stable@FreeBSD.ORG Mon Apr 6 02:10:07 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 849F71065674 for ; Mon, 6 Apr 2009 02:10:07 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.delphij.net (delphij-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:2c9::2]) by mx1.freebsd.org (Postfix) with ESMTP id 27E1F8FC27 for ; Mon, 6 Apr 2009 02:10:07 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [211.166.10.233]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tarsier.delphij.net (Postfix) with ESMTPS id 007D128449 for ; Mon, 6 Apr 2009 10:10:05 +0800 (CST) Received: from localhost (tarsier.geekcn.org [211.166.10.233]) by tarsier.geekcn.org (Postfix) with ESMTP id 655F2EBA95B; Mon, 6 Apr 2009 10:10:05 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([211.166.10.233]) by localhost (mail.geekcn.org [211.166.10.233]) (amavisd-new, port 10024) with ESMTP id ZlFQrRfFDYAQ; Mon, 6 Apr 2009 10:10:00 +0800 (CST) Received: from charlie.delphij.net (c-69-181-141-49.hsd1.ca.comcast.net [69.181.141.49]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTPSA id B40B1EB8623; Mon, 6 Apr 2009 10:09:59 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:reply-to:organization:user-agent: mime-version:to:subject:references:in-reply-to:x-enigmail-version:openpgp: content-type:content-transfer-encoding; b=laEARmlqRox+BIx6+jxQkNgj7Ss72XHeOM0g2dJkrORca9hwzls5LhG5Ss/DAm8tZ h3qvdsCSechEBe+aSEECg== Message-ID: <49D96475.2070309@delphij.net> Date: Sun, 05 Apr 2009 19:09:57 -0700 From: Xin LI Organization: The FreeBSD Project User-Agent: Thunderbird 2.0.0.21 (X11/20090324) MIME-Version: 1.0 To: Victor Sudakov , freebsd-stable@freebsd.org References: <20090402044358.GA34249@admin.sibptus.tomsk.ru> <20090406020446.GD78037@admin.sibptus.tomsk.ru> In-Reply-To: <20090406020446.GD78037@admin.sibptus.tomsk.ru> X-Enigmail-Version: 0.95.7 OpenPGP: id=18EDEBA0; url=http://www.delphij.net/delphij.asc Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Subject: Re: Failure to make world for RELENG_6_4 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2009 02:10:07 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Victor Sudakov wrote: >> misc/133264 > > This one however is not so simple. I have tried building world under > VMWare ESXi 3.5.0 Update 3 (FreeBSD as a guest OS) and the building > process crashed occasionally if more than 1 CPU is allocated to the > virtual machine. The failures are due to various processes like sh, > sed or cc1 dupming core on signal 11 during the build. > > The problem seems to be SMP related because enabling only 1 virtual > CPU removes the problem. Of course it is also VMWare related. - From what you have described, it's likely that there is some memory issue. The FreeBSD Virtual Memory system tends to use all physical memory and this could be a problem for faulty memory chips (i.e. it's more easy for FreeBSD to trigger problems). If you have access to the host system and possible, would you please try to install FreeBSD directly and see if the problem still occurs? Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEARECAAYFAknZZHUACgkQi+vbBBjt66DbrACfY0tbGQImQgm9PJJGbWDQPZLt FvIAoK+fWNP2eA37Zs6WpSaF0zG83vWg =7wMS -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Mon Apr 6 02:50:57 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BFEF810656C3 for ; Mon, 6 Apr 2009 02:50:57 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.delphij.net (delphij-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:2c9::2]) by mx1.freebsd.org (Postfix) with ESMTP id 1C65A8FC08 for ; Mon, 6 Apr 2009 02:50:56 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [211.166.10.233]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tarsier.delphij.net (Postfix) with ESMTPS id A5BEE28450 for ; Mon, 6 Apr 2009 10:50:54 +0800 (CST) Received: from localhost (tarsier.geekcn.org [211.166.10.233]) by tarsier.geekcn.org (Postfix) with ESMTP id 5ED79EBAAB3; Mon, 6 Apr 2009 10:50:54 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([211.166.10.233]) by localhost (mail.geekcn.org [211.166.10.233]) (amavisd-new, port 10024) with ESMTP id sA+a4mY5GTNQ; Mon, 6 Apr 2009 10:50:45 +0800 (CST) Received: from charlie.delphij.net (c-69-181-141-49.hsd1.ca.comcast.net [69.181.141.49]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTPSA id 9BDA6EBAA9D; Mon, 6 Apr 2009 10:50:43 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:reply-to:organization:user-agent: mime-version:to:cc:subject:references:in-reply-to: x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=oU9G2VKTSGhUv8D85OKQWtqFk3BtysrgiH3xyEioxNEB6przXl1u/iAyE49Qy1n3C nMpX9TM9q5+YVc1xwGCcg== Message-ID: <49D96E01.8070107@delphij.net> Date: Sun, 05 Apr 2009 19:50:41 -0700 From: Xin LI Organization: The FreeBSD Project User-Agent: Thunderbird 2.0.0.21 (X11/20090324) MIME-Version: 1.0 To: Alexander Kabaev References: <20090402044358.GA34249@admin.sibptus.tomsk.ru> <20090406020446.GD78037@admin.sibptus.tomsk.ru> <49D96475.2070309@delphij.net> <20090405223623.0fb6150b@kan.dnsalias.net> In-Reply-To: <20090405223623.0fb6150b@kan.dnsalias.net> X-Enigmail-Version: 0.95.7 OpenPGP: id=18EDEBA0; url=http://www.delphij.net/delphij.asc Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Victor Sudakov , d@delphij.net, freebsd-stable@freebsd.org Subject: Re: Failure to make world for RELENG_6_4 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2009 02:50:58 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Alexander Kabaev wrote: > On Sun, 05 Apr 2009 19:09:57 -0700 > Xin LI wrote: >> - From what you have described, it's likely that there is some memory >> issue. The FreeBSD Virtual Memory system tends to use all physical >> memory and this could be a problem for faulty memory chips (i.e. it's >> more easy for FreeBSD to trigger problems). >> >> If you have access to the host system and possible, would you please >> try to install FreeBSD directly and see if the problem still occurs? >> >> Cheers, >> - -- >> Xin LI http://www.delphij.net/ >> FreeBSD - The Power to Serve! > JFYI, > > this seems to be the issue with combination of FreeBSD 6.x and VMWare > hypervisor when running with more than one virtual CPUs. I see it will > the full range of VMWare products, from Player to Fusion and > Workstation. FreeBSD 7 and up are working fine. I see, thanks for the pointer. Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEARECAAYFAknZbgAACgkQi+vbBBjt66D7fACgiiqUD6G0YobszxnDpQEvrdtM g80AoJPh1UDufIml6i66iWJw5EdH6uEH =rlCg -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Mon Apr 6 03:08:47 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 60DC5106564A for ; Mon, 6 Apr 2009 03:08:47 +0000 (UTC) (envelope-from kabaev@gmail.com) Received: from mail-qy0-f134.google.com (mail-qy0-f134.google.com [209.85.221.134]) by mx1.freebsd.org (Postfix) with ESMTP id 00B0F8FC17 for ; Mon, 6 Apr 2009 03:08:46 +0000 (UTC) (envelope-from kabaev@gmail.com) Received: by qyk40 with SMTP id 40so3339112qyk.3 for ; Sun, 05 Apr 2009 20:08:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:cc:subject :message-id:in-reply-to:references:x-mailer:mime-version :content-type:content-transfer-encoding; bh=/QE2A0660kXlWUZUzNqLreYEoLKOGsFJJBsB0Gk9P2I=; b=MlK1Z4aOKoOnR8U0+jE2yIT3Do3yRNNJ+bqlC/bF47LUP8UrokLrxjKtF4QtNkXW51 HQl34ZLcVGgqdsjPxQg0agZtweCbD0I4XhWI/N8AEbl726OLK31t3EjAfp8V4UKk/9+T hpvsA33pJtSeOcs1KuaFrdpucUhkvcXEz9vBQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type:content-transfer-encoding; b=R8m71/TbU1HVV9jElvdad6LIvc+JWNq5+24XSdgBW0cBMDyz75HPy0pYIuRUlYURTy eOAnCCy1KJ/3stjmVb4Kb2SHV0BDVxQyRJRW55GSxFn/c5KzzzVoxGXCBtt+IO3h4pqA 8e26RhcaRJasWfmCQz2jQf7NdLWazvOKBgL1Q= Received: by 10.224.37.79 with SMTP id w15mr3163173qad.231.1238985386475; Sun, 05 Apr 2009 19:36:26 -0700 (PDT) Received: from kan.dnsalias.net (c-98-217-224-113.hsd1.ma.comcast.net [98.217.224.113]) by mx.google.com with ESMTPS id 6sm5471191qwk.17.2009.04.05.19.36.24 (version=SSLv3 cipher=RC4-MD5); Sun, 05 Apr 2009 19:36:25 -0700 (PDT) Date: Sun, 5 Apr 2009 22:36:23 -0400 From: Alexander Kabaev To: d@delphij.net Message-ID: <20090405223623.0fb6150b@kan.dnsalias.net> In-Reply-To: <49D96475.2070309@delphij.net> References: <20090402044358.GA34249@admin.sibptus.tomsk.ru> <20090406020446.GD78037@admin.sibptus.tomsk.ru> <49D96475.2070309@delphij.net> X-Mailer: Claws Mail 3.7.1 (GTK+ 2.14.7; i386-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Victor Sudakov , delphij@delphij.net, freebsd-stable@freebsd.org Subject: Re: Failure to make world for RELENG_6_4 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2009 03:08:47 -0000 On Sun, 05 Apr 2009 19:09:57 -0700 Xin LI wrote: > > - From what you have described, it's likely that there is some memory > issue. The FreeBSD Virtual Memory system tends to use all physical > memory and this could be a problem for faulty memory chips (i.e. it's > more easy for FreeBSD to trigger problems). > > If you have access to the host system and possible, would you please > try to install FreeBSD directly and see if the problem still occurs? > > Cheers, > - -- > Xin LI http://www.delphij.net/ > FreeBSD - The Power to Serve! JFYI, this seems to be the issue with combination of FreeBSD 6.x and VMWare hypervisor when running with more than one virtual CPUs. I see it will the full range of VMWare products, from Player to Fusion and Workstation. FreeBSD 7 and up are working fine. -- Alexander Kabaev From owner-freebsd-stable@FreeBSD.ORG Mon Apr 6 04:39:48 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3EABF106566B for ; Mon, 6 Apr 2009 04:39:48 +0000 (UTC) (envelope-from vas@mpeks.tomsk.su) Received: from relay2.tomsk.ru (relay2.tomsk.ru [212.73.124.8]) by mx1.freebsd.org (Postfix) with ESMTP id 8C7878FC0A for ; Mon, 6 Apr 2009 04:39:47 +0000 (UTC) (envelope-from vas@mpeks.tomsk.su) X-Virus-Scanned: by clamd daemon 0.93.1 for FreeBSD at relay2.tomsk.ru Received: from admin.sibptus.tomsk.ru (account sudakov@sibptus.tomsk.ru [212.73.125.240] verified) by relay2.tomsk.ru (CommuniGate Pro SMTP 5.1.13) with ESMTPSA id 12244051 for freebsd-stable@freebsd.org; Mon, 06 Apr 2009 11:39:45 +0700 Received: (from sudakov@localhost) by admin.sibptus.tomsk.ru (8.13.6/8.13.6/Submit) id n364dj0B084334 for freebsd-stable@freebsd.org; Mon, 6 Apr 2009 11:39:45 +0700 (OMSST) (envelope-from vas@mpeks.tomsk.su) X-Authentication-Warning: admin.sibptus.tomsk.ru: sudakov set sender to vas@mpeks.tomsk.su using -f Date: Mon, 6 Apr 2009 11:39:45 +0700 From: Victor Sudakov To: freebsd-stable@freebsd.org Message-ID: <20090406043945.GA84052@admin.sibptus.tomsk.ru> Mail-Followup-To: Victor Sudakov , freebsd-stable@freebsd.org References: <20090402044358.GA34249@admin.sibptus.tomsk.ru> <20090406020446.GD78037@admin.sibptus.tomsk.ru> <49D96475.2070309@delphij.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49D96475.2070309@delphij.net> User-Agent: Mutt/1.4.2.3i Organization: AO "Svyaztransneft", SibPTUS X-PGP-Key: http://vas.tomsk.ru/vas.asc Subject: Re: Failure to make world for RELENG_6_4 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2009 04:39:48 -0000 Xin LI wrote: > >> misc/133264 > > > > This one however is not so simple. I have tried building world under > > VMWare ESXi 3.5.0 Update 3 (FreeBSD as a guest OS) and the building > > process crashed occasionally if more than 1 CPU is allocated to the > > virtual machine. The failures are due to various processes like sh, > > sed or cc1 dupming core on signal 11 during the build. > > > > The problem seems to be SMP related because enabling only 1 virtual > > CPU removes the problem. Of course it is also VMWare related. > > - From what you have described, it's likely that there is some memory > issue. The FreeBSD Virtual Memory system tends to use all physical > memory and this could be a problem for faulty memory chips (i.e. it's > more easy for FreeBSD to trigger problems). How is this connected with the number of virtual CPUs? When I give only 1 CPU to the virtual machine, the problem is gone. > > If you have access to the host system and possible, would you please try > to install FreeBSD directly and see if the problem still occurs? Sorry, I cannot do that. This host is already running several Windows servers and has been thoroughly tested before production use. I have however run Memtest-86 v3.2 in the virtual machine for 2 hours and it has found no errors. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:sudakov@sibptus.tomsk.ru From owner-freebsd-stable@FreeBSD.ORG Mon Apr 6 04:40:14 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 936191065786 for ; Mon, 6 Apr 2009 04:40:14 +0000 (UTC) (envelope-from vas@mpeks.tomsk.su) Received: from relay2.tomsk.ru (relay2.tomsk.ru [212.73.124.8]) by mx1.freebsd.org (Postfix) with ESMTP id A8F8C8FC20 for ; Mon, 6 Apr 2009 04:40:13 +0000 (UTC) (envelope-from vas@mpeks.tomsk.su) X-Virus-Scanned: by clamd daemon 0.93.1 for FreeBSD at relay2.tomsk.ru Received: from admin.sibptus.tomsk.ru (account sudakov@sibptus.tomsk.ru [212.73.125.240] verified) by relay2.tomsk.ru (CommuniGate Pro SMTP 5.1.13) with ESMTPSA id 12244040 for freebsd-stable@freebsd.org; Mon, 06 Apr 2009 11:40:12 +0700 Received: (from sudakov@localhost) by admin.sibptus.tomsk.ru (8.13.6/8.13.6/Submit) id n364eBnr084361 for freebsd-stable@freebsd.org; Mon, 6 Apr 2009 11:40:12 +0700 (OMSST) (envelope-from vas@mpeks.tomsk.su) X-Authentication-Warning: admin.sibptus.tomsk.ru: sudakov set sender to vas@mpeks.tomsk.su using -f Date: Mon, 6 Apr 2009 11:40:11 +0700 From: Victor Sudakov To: freebsd-stable@freebsd.org Message-ID: <20090406044011.GB84052@admin.sibptus.tomsk.ru> Mail-Followup-To: Victor Sudakov , freebsd-stable@freebsd.org References: <20090402044358.GA34249@admin.sibptus.tomsk.ru> <20090406020446.GD78037@admin.sibptus.tomsk.ru> <49D96475.2070309@delphij.net> <20090405223623.0fb6150b@kan.dnsalias.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090405223623.0fb6150b@kan.dnsalias.net> User-Agent: Mutt/1.4.2.3i Organization: AO "Svyaztransneft", SibPTUS X-PGP-Key: http://vas.tomsk.ru/vas.asc Subject: Re: Failure to make world for RELENG_6_4 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2009 04:40:14 -0000 Alexander Kabaev wrote: > > this seems to be the issue with combination of FreeBSD 6.x and VMWare > hypervisor when running with more than one virtual CPUs. I see it will > the full range of VMWare products, from Player to Fusion and > Workstation. FreeBSD 7 and up are working fine. Is there a hypervisor which has no problems with FreeBSD? I have tried several. 1. Under Microsoft (former Connectix) VirtualPC, FreeBSD has timer problems ("microuptime went backwards"). 2. Under VirtualBox, some processes tend to hang with the obscure kernel mesage "sigreturn: eflags = 0x80286" (the VirtualBox bugtracker claims the issue is fixed, but it is not). 3. Under ESXi, you know. 4. What about Xen? Is it worth trying? -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:sudakov@sibptus.tomsk.ru From owner-freebsd-stable@FreeBSD.ORG Mon Apr 6 04:54:32 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C6AA31065673 for ; Mon, 6 Apr 2009 04:54:32 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.delphij.net (delphij-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:2c9::2]) by mx1.freebsd.org (Postfix) with ESMTP id 6A19C8FC08 for ; Mon, 6 Apr 2009 04:54:31 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [211.166.10.233]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tarsier.delphij.net (Postfix) with ESMTPS id 3A8CA28448 for ; Mon, 6 Apr 2009 12:54:30 +0800 (CST) Received: from localhost (tarsier.geekcn.org [211.166.10.233]) by tarsier.geekcn.org (Postfix) with ESMTP id 858A0EBAD8E; Mon, 6 Apr 2009 12:54:29 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([211.166.10.233]) by localhost (mail.geekcn.org [211.166.10.233]) (amavisd-new, port 10024) with ESMTP id FMSKiHTxu1Vn; Mon, 6 Apr 2009 12:54:24 +0800 (CST) Received: from charlie.delphij.net (c-69-181-141-49.hsd1.ca.comcast.net [69.181.141.49]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTPSA id 54F6DEB983C; Mon, 6 Apr 2009 12:54:22 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:reply-to:organization:user-agent: mime-version:to:subject:references:in-reply-to:x-enigmail-version:openpgp: content-type:content-transfer-encoding; b=bbsb84OcJ7NOp0QuLYS7lFopXd+rMMCjQpv8ZM32z7ErE0pVx1Uf9PcZMPZDraUy5 /1EnO+foQ/iZopZhlMFmQ== Message-ID: <49D98AFB.2050308@delphij.net> Date: Sun, 05 Apr 2009 21:54:19 -0700 From: Xin LI Organization: The FreeBSD Project User-Agent: Thunderbird 2.0.0.21 (X11/20090324) MIME-Version: 1.0 To: Victor Sudakov , freebsd-stable@freebsd.org References: <20090402044358.GA34249@admin.sibptus.tomsk.ru> <20090406020446.GD78037@admin.sibptus.tomsk.ru> <49D96475.2070309@delphij.net> <20090406043945.GA84052@admin.sibptus.tomsk.ru> In-Reply-To: <20090406043945.GA84052@admin.sibptus.tomsk.ru> X-Enigmail-Version: 0.95.7 OpenPGP: id=18EDEBA0; url=http://www.delphij.net/delphij.asc Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: Re: Failure to make world for RELENG_6_4 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2009 04:54:33 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Victor Sudakov wrote: > Xin LI wrote: >>>> misc/133264 >>> This one however is not so simple. I have tried building world under >>> VMWare ESXi 3.5.0 Update 3 (FreeBSD as a guest OS) and the building >>> process crashed occasionally if more than 1 CPU is allocated to the >>> virtual machine. The failures are due to various processes like sh, >>> sed or cc1 dupming core on signal 11 during the build. >>> >>> The problem seems to be SMP related because enabling only 1 virtual >>> CPU removes the problem. Of course it is also VMWare related. >> - From what you have described, it's likely that there is some memory >> issue. The FreeBSD Virtual Memory system tends to use all physical >> memory and this could be a problem for faulty memory chips (i.e. it's >> more easy for FreeBSD to trigger problems). > > How is this connected with the number of virtual CPUs? > When I give only 1 CPU to the virtual machine, the problem is gone. > >> If you have access to the host system and possible, would you please try >> to install FreeBSD directly and see if the problem still occurs? > > Sorry, I cannot do that. This host is already running several Windows > servers and has been thoroughly tested before production use. > > I have however run Memtest-86 v3.2 in the virtual machine for > 2 hours and it has found no errors. No, memtest is known to be weaker than a 'make world'. According to kan@, it looks like a bug in FreeBSD 6.x :( unfortunately. The good news is that the problem has been fixed in 7.x series. Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEARECAAYFAknZivsACgkQi+vbBBjt66Ag+QCeKj/hsbvPLuiKa65iLsxWj5lt 0JEAnjWtwrGKX11P8h9W2ATmO13dwFT7 =ZVZj -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Mon Apr 6 04:55:08 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B49C8106566C for ; Mon, 6 Apr 2009 04:55:08 +0000 (UTC) (envelope-from rebotados@exemys.com) Received: from server2.hostmailing.com (server2.hostmailing.com [200.110.145.42]) by mx1.freebsd.org (Postfix) with ESMTP id EC9B78FC1C for ; Mon, 6 Apr 2009 04:55:07 +0000 (UTC) (envelope-from rebotados@exemys.com) Received: from web.hostmailing.com ([200.110.145.34] helo=www.hostmailing.com) by server2.hostmailing.com with esmtpa (Exim 4.68) (envelope-from ) id 1LqaRp-0004Gj-3t for freebsd-stable@freebsd.org; Sun, 05 Apr 2009 19:04:13 -0300 Date: Sun, 5 Apr 2009 20:30:54 -0300 To: freebsd-stable@freebsd.org From: Exemys Message-ID: <4495e349640a1ba874f88a8169da227b@www.hostmailing.com> X-Priority: 3 X-Mailer: wh4535 [version 3.1] MIME-Version: 1.0 Content-Type: text/plain; charset = "iso-8859-1" Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Modbus I/O Module - Analog / Digital X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: exemys@exemys.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2009 04:55:09 -0000 This is a message in multipart MIME format. Your mail client should not be displaying this. Consider upgrading your mail client to view this message correctly. From owner-freebsd-stable@FreeBSD.ORG Mon Apr 6 06:19:04 2009 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 25F45106564A; Mon, 6 Apr 2009 06:19:04 +0000 (UTC) (envelope-from eugen@eg.svzserv.kuzbass.ru) Received: from eg.svzserv.kuzbass.ru (eg.svzserv.kuzbass.ru [213.184.65.84]) by mx1.freebsd.org (Postfix) with ESMTP id 31C438FC33; Mon, 6 Apr 2009 06:19:02 +0000 (UTC) (envelope-from eugen@eg.svzserv.kuzbass.ru) Received: from eg.svzserv.kuzbass.ru (localhost [127.0.0.1]) by eg.svzserv.kuzbass.ru (8.14.3/8.14.3) with ESMTP id n365KamD000919; Mon, 6 Apr 2009 13:20:36 +0800 (KRAST) (envelope-from eugen@eg.svzserv.kuzbass.ru) Received: (from eugen@localhost) by eg.svzserv.kuzbass.ru (8.14.3/8.14.3/Submit) id n365KZ1U000918; Mon, 6 Apr 2009 13:20:35 +0800 (KRAST) (envelope-from eugen) Date: Mon, 6 Apr 2009 13:20:35 +0800 (KRAST) Message-Id: <200904060520.n365KZ1U000918@eg.svzserv.kuzbass.ru> To: FreeBSD-gnats-submit@freebsd.org From: Eugene Grosbein X-send-pr-version: 3.113 X-GNATS-Notify: Cc: stable@freebsd.org, rwatson@freebsd.org, obrien@freebsd.org Subject: repeatable 6.4-STABLE kernel panic: sleeping thread X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2009 06:19:04 -0000 >Submitter-Id: current-users >Originator: Eugene Grosbein >Organization: Svyaz Service >Confidential: no >Synopsis: repeatable 6.4-STABLE kernel panic: sleeping thread >Severity: critical >Priority: high >Category: kern >Class: sw-bug >Release: FreeBSD 6.4-STABLE i386 >Environment: System: FreeBSD eg.svzserv.kuzbass.ru 6.4-STABLE FreeBSD 6.4-STABLE #18: Mon Apr 6 12:56:06 KRAST 2009 eugen@eg.svzserv.kuzbass.ru:/usr/local/obj/usr/local/src/sys/EG i386 re(4) network driver >Description: 1 April I've updated my 6.4-STABLE (running 19 March 2009 sources before) to lastest RELENG_6 using standard source upgrade path and now it cannot boot - panices just after inetd start. It boots with kernel.old just fine. My kernel is monolithic and there are no kernel modules loaded other than acpi.ko. Here comes gdb backtrace: Script started on Mon Apr 6 12:07:44 2009 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: <118> mousechar_start <118>. <118>Starting inetd. Sleeping thread (tid 100084, pid 684) owns a non-sleepable lock sched_switch(c4e74600,0,1,4c477be9,b39fb614,...) at 0xc053ddcf = sched_switch+0x158 mi_switch(1,0) at 0xc0531483 = mi_switch+0x1d5 sleepq_switch(c07a7504,4,0,e752cb3c,c04ef432,...) at 0xc054e0f9 = sleepq_switch+0x93 sleepq_wait_sig(c07a7504,c07a74e0,c07429df,101,0,...) at 0xc054e280 = sleepq_wait_sig+0x21 cv_wait_sig(c07a7504,c07a74e0,e752cb78,8,e752cb58,...) at 0xc04ef432 = cv_wait_sig+0x15a kern_select(c4e74600,8,bfbfe8b0,0,0,...) at 0xc05549ae = kern_select+0x67d select(c4e74600,e752cd04,14,c4e74600,2817f000,...) at 0xc0554327 = select+0x63 syscall(3b,3b,3b,bfbfedc0,bfbfee40,...) at 0xc070822d = syscall+0x34f Xint0x80_syscall() at 0xc06f035f = Xint0x80_syscall+0x1f --- syscall (93, FreeBSD ELF32, select), eip = 0x2816af63, esp = 0xbfbfdb8c, ebp = 0xbfbfee78 --- panic: sleeping thread cpuid = 0 KDB: stack backtrace: kdb_backtrace(c075ab91,0,c07427ff,e35d1bd0,0,...) at 0xc05470aa = kdb_backtrace+0x2f panic(c07427ff,ffffffff,2ac,c4b15a80,e35d1be8,...) at 0xc0528e09 = panic+0x129 propagate_priority(c4b15a80,c4e74600,c05511d8,c4b15a80,e35d1c38,...) at 0xc0550c49 = propagate_priority+0x69 turnstile_wait(c07abfec,c4e74600,0,0,4,...) at 0xc05517b8 = turnstile_wait+0x34b _mtx_lock_sleep(c07abfec,c4b15a80,0,0,0,...) at 0xc051c240 = _mtx_lock_sleep+0x10d tcp_isn_tick(0,0,0,0,1ac3ffac,...) at 0xc0600b86 = tcp_isn_tick+0x4d softclock(0,e35d1cd4,6,363f5101,c4b15a80,...) at 0xc0538396 = softclock+0x2f6 ithread_execute_handlers(c4b14648,c4b63080,0,0,0,...) at 0xc050a353 = ithread_execute_handlers+0x162 ithread_loop(c4aee940,e35d1d38,0,0,0,...) at 0xc050a4ae = ithread_loop+0x64 fork_exit(c050a44a,c4aee940,e35d1d38) at 0xc0508d1e = fork_exit+0x7b fork_trampoline() at 0xc06f036c = fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xe35d1d6c, ebp = 0 --- Uptime: 6s Dumping 1023 MB (2 chunks) chunk 0: 1MB (159 pages) ... ok chunk 1: 1023MB (261872 pages) 1007 991 975 959 943 927 911 895 879 863 847 831 815 799 783 767 751 735 719 703 687 671 655 639 623 607 591 575 559 543 527 511 495 479 463 447 431 415 399 383 367 351 335 319 303 287 271 255 239 223 207 191 175 159 143 127 111 95 79 63 47 31 15 Reading symbols from /boot/modules/snd_hda.ko...done. Loaded symbols for /boot/modules/snd_hda.ko Reading symbols from /boot/modules/sound.ko...done. Loaded symbols for /boot/modules/sound.ko Reading symbols from /boot/modules/aio.ko...done. Loaded symbols for /boot/modules/aio.ko Reading symbols from /boot/modules/acpi.ko...done. Loaded symbols for /boot/modules/acpi.ko #0 doadump () at pcpu.h:165 165 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); (kgdb) bt full #0 doadump () at pcpu.h:165 No locals. #1 0xc0528ae9 in boot (howto=260) at /usr/local/src/sys/kern/kern_shutdown.c:410 first_buf_printf = 1 #2 0xc0528ec8 in panic (fmt=0xc07427ff "sleeping thread") at /usr/local/src/sys/kern/kern_shutdown.c:566 td = (struct thread *) 0xc4b15a80 bootopt = 260 newpanic = 1 ap = 0xc4b15a80 "HF±Äà\215±Ä" buf = "sleeping thread", '\0' #3 0xc0550c49 in propagate_priority (td=0xc4e74600) at /usr/local/src/sys/kern/subr_turnstile.c:209 tc = (struct turnstile_chain *) 0xc4b15a80 ts = (struct turnstile *) 0xc4e73140 pri = 52 #4 0xc05517b8 in turnstile_wait (lock=0xc07abfec, owner=0x0, queue=0) at /usr/local/src/sys/kern/subr_turnstile.c:715 tc = (struct turnstile_chain *) 0xc07a6a38 ts = (struct turnstile *) 0xc4e73140 td = (struct thread *) 0xc4b15a80 td1 = (struct thread *) 0xc4b15a80 #5 0xc051c240 in _mtx_lock_sleep (m=0xc07abfec, tid=3299957376, opts=0, ---Type to continue, or q to quit--- file=0x0, line=0) at /usr/local/src/sys/kern/kern_mutex.c:579 owner = (volatile struct thread *) 0xc4e74600 v = 0 #6 0xc0600b86 in tcp_isn_tick (xtp=0x0) at /usr/local/src/sys/netinet/tcp_subr.c:1485 projected_offset = 0 #7 0xc0538396 in softclock (dummy=0x0) at /usr/local/src/sys/kern/kern_timeout.c:274 c_func = (void (*)(void *)) 0xc0600b39 c_arg = (void *) 0x0 c_mtx = (struct mtx *) 0x0 c_flags = 22 c = (struct callout *) 0x0 bucket = (struct callout_tailq *) 0xd8b21598 curticks = 5545 steps = 0 depth = 3 mpcalls = 1 mtxcalls = 0 gcalls = 2 #8 0xc050a353 in ithread_execute_handlers (p=0xc4b14648, ie=0xc4b63080) at /usr/local/src/sys/kern/kern_intr.c:682 ih = (struct intr_handler *) 0xc4b62880 ihn = (struct intr_handler *) 0xc4c4ea40 ---Type to continue, or q to quit--- #9 0xc050a4ae in ithread_loop (arg=0xc4aee940) at /usr/local/src/sys/kern/kern_intr.c:766 intr_event = (struct intr_thread *) 0xc4aee940 ie = (struct intr_event *) 0xc4b63080 td = (struct thread *) 0xc4b15a80 p = (struct proc *) 0xc4b14648 #10 0xc0508d1e in fork_exit (callout=0xc050a44a , arg=0x0, frame=0x0) at /usr/local/src/sys/kern/kern_fork.c:788 p = (struct proc *) 0xc4b14648 td = (struct thread *) 0x0 #11 0xc06f036c in fork_trampoline () at /usr/local/src/sys/i386/i386/exception.s:208 No locals. (kgdb) frame 6 #6 0xc0600b86 in tcp_isn_tick (xtp=0x0) at /usr/local/src/sys/netinet/tcp_subr.c:1485 1485 INP_INFO_WLOCK(&tcbinfo); (kgdb) l 1480 tcp_isn_tick(xtp) 1481 void *xtp; 1482 { 1483 u_int32_t projected_offset; 1484 1485 INP_INFO_WLOCK(&tcbinfo); 1486 projected_offset = isn_offset_old + ISN_BYTES_PER_SECOND / 100; 1487 1488 if (SEQ_GT(projected_offset, isn_offset)) 1489 isn_offset = projected_offset; (kgdb) quit Script done on Mon Apr 6 12:08:54 2009 I've investigated the case and found that there was only one commit to src/sys/netinet, that was ip_output.c,v 1.242.2.20 I've backed it out, rebuilt kernel and it does not panices anymore. >How-To-Repeat: Build and run RELENG_6 after 24 March 2009. >Fix: Unknown. Workaround is to backout this commit: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/ip_output.c.diff?r1=1.242.2.19;r2=1.242.2.20 Eugene Grosbein From owner-freebsd-stable@FreeBSD.ORG Mon Apr 6 07:57:15 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 618661065674 for ; Mon, 6 Apr 2009 07:57:15 +0000 (UTC) (envelope-from Martin.Blapp@t-systems.ch) Received: from mail100.t-systems.ch (mail109.t-systems.ch [193.108.232.23]) by mx1.freebsd.org (Postfix) with ESMTP id E9D798FC0C for ; Mon, 6 Apr 2009 07:57:14 +0000 (UTC) (envelope-from Martin.Blapp@t-systems.ch) Received: from wsairz0042.t-systems.ch (Not Verified[53.250.54.32]) by mail100.t-systems.ch with MailMarshal (using TLS: SSLv23) id ; Mon, 06 Apr 2009 09:57:13 +0200 Received: from TSS-EXCH01.t-systems.ch ([53.250.54.26]) by wsairz0042.t-systems.ch ([53.250.54.32]) with mapi; Mon, 6 Apr 2009 09:57:13 +0200 From: "Blapp, Martin" To: "freebsd-stable@freebsd.org" Date: Mon, 6 Apr 2009 09:57:13 +0200 Thread-Topic: FreeBSD 7.2-BETA1 tcp retransmit crash Thread-Index: Acm2HJcg8SN2w9OcQLSgg80fc/r40AAb5zJM Message-ID: <509A7CA1EA3EA046B1A5BA2FCFDB3C8EC764853902@TSS-EXCH01.t-systems.ch> References: <509A7CA1EA3EA046B1A5BA2FCFDB3C8EC764853900@TSS-EXCH01.t-systems.ch> <20090405163705.U15361@maildrop.int.zabbadoz.net>, <20090405180621.F15361@maildrop.int.zabbadoz.net> In-Reply-To: <20090405180621.F15361@maildrop.int.zabbadoz.net> Accept-Language: de-DE, de-CH Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, de-CH Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 HC: x Subject: AW: FreeBSD 7.2-BETA1 tcp retransmit crash X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2009 07:57:15 -0000 Hi, (kgdb) frame 7 #7 0xc07c6cb0 in sbsndptr (sb=3D0xc342ede4, off=3D112, len=3D113, moff=3D0= xc2f9ca04) at /usr/src/sys/kern/uipc_sockbuf.c:939 This is also interesting. Is this an OffByOne somewhere ? As I said it's just a workaround, and for now it didn't crash anymore :-) I could modify this patch to see what happens exactly, dumpping the mbuf. The workaround I currently use is just skipping and dropping this mbuf: --- sys/kern/uipc_sockbuf.c.orig 2009-04-05 18:01:35.000000000 +0200 +++ sys/kern/uipc_sockbuf.c 2009-04-05 18:01:46.000000000 +0200 @@ -930,6 +930,13 @@ return (sb->sb_mb); } + /* + * Try to avoid some retransmit panics + */ + if (sb->sb_sndptr =3D=3D NULL && sb->sb_mb =3D=3D NULL) { + return (NULL); + } + /* Return closest mbuf in chain for current offset. */ *moff =3D off - sb->sb_sndptroff; m =3D ret =3D sb->sb_sndptr ? sb->sb_sndptr : sb->sb_mb; --- sys/netinet/tcp_output.c.orig 2009-04-05 18:01:29.000000000 +0200 +++ sys/netinet/tcp_output.c 2009-04-05 18:04:17.000000000 +0200 @@ -797,6 +797,17 @@ */ mb =3D sbsndptr(&so->so_snd, off, len, &moff); + + /* + * Avoid panics. Mask the error with ENETDOWN + */ + if (mb =3D=3D NULL) { + SOCKBUF_UNLOCK(&so->so_snd); + (void) m_free(m); + error =3D ENETDOWN; + goto out; + } + if (len <=3D MHLEN - hdrlen - max_linkhdr) { m_copydata(mb, moff, (int)len, mtod(m, caddr_t) + hdrlen); From owner-freebsd-stable@FreeBSD.ORG Mon Apr 6 13:44:35 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4A8C91065711 for ; Mon, 6 Apr 2009 13:44:35 +0000 (UTC) (envelope-from vas@mpeks.tomsk.su) Received: from relay2.tomsk.ru (relay2.tomsk.ru [212.73.124.8]) by mx1.freebsd.org (Postfix) with ESMTP id 82AA48FC13 for ; Mon, 6 Apr 2009 13:44:34 +0000 (UTC) (envelope-from vas@mpeks.tomsk.su) X-Virus-Scanned: by clamd daemon 0.93.1 for FreeBSD at relay2.tomsk.ru Received: from admin.sibptus.tomsk.ru (account sudakov@sibptus.tomsk.ru [212.73.125.240] verified) by relay2.tomsk.ru (CommuniGate Pro SMTP 5.1.13) with ESMTPSA id 12247985 for freebsd-stable@freebsd.org; Mon, 06 Apr 2009 20:44:29 +0700 Received: (from sudakov@localhost) by admin.sibptus.tomsk.ru (8.13.6/8.13.6/Submit) id n36DiSsd099552 for freebsd-stable@freebsd.org; Mon, 6 Apr 2009 20:44:28 +0700 (OMSST) (envelope-from vas@mpeks.tomsk.su) X-Authentication-Warning: admin.sibptus.tomsk.ru: sudakov set sender to vas@mpeks.tomsk.su using -f Date: Mon, 6 Apr 2009 20:44:28 +0700 From: Victor Sudakov To: freebsd-stable@freebsd.org Message-ID: <20090406134428.GA99411@admin.sibptus.tomsk.ru> Mail-Followup-To: Victor Sudakov , freebsd-stable@freebsd.org References: <20090402044358.GA34249@admin.sibptus.tomsk.ru> <20090406020446.GD78037@admin.sibptus.tomsk.ru> <49D96475.2070309@delphij.net> <20090406043945.GA84052@admin.sibptus.tomsk.ru> <49D98AFB.2050308@delphij.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49D98AFB.2050308@delphij.net> User-Agent: Mutt/1.4.2.3i Organization: AO "Svyaztransneft", SibPTUS X-PGP-Key: http://vas.tomsk.ru/vas.asc Subject: Re: Failure to make world for RELENG_6_4 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2009 13:44:35 -0000 Xin LI wrote: > > According to kan@, it looks like a bug in FreeBSD 6.x :( unfortunately. > The good news is that the problem has been fixed in 7.x series. Yes, I confirm that "make buildworld" works fine for RELENG_7_1 under VMWare ESXi with 2 virtual CPUs, even with -j4 or -j8. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:sudakov@sibptus.tomsk.ru From owner-freebsd-stable@FreeBSD.ORG Mon Apr 6 19:51:43 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A07C81065B55 for ; Mon, 6 Apr 2009 19:51:43 +0000 (UTC) (envelope-from cacti@ekman.netline.com) Received: from ekman.netline.com (ekman.netline.com [209.133.56.28]) by mx1.freebsd.org (Postfix) with ESMTP id 912BA8FC22 for ; Mon, 6 Apr 2009 19:51:43 +0000 (UTC) (envelope-from cacti@ekman.netline.com) Received: by ekman.netline.com (Postfix, from userid 1000) id 3D4E61184B5; Mon, 6 Apr 2009 12:19:23 -0700 (PDT) To: freebsd-stable@freebsd.org Message-ID: <1239045563.43872.qmail@Poste-italiane.it> From: "MondoBancoPosta" Date: Mon, 6 Apr 2009 12:19:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Premio vi aspetta! X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2009 19:51:47 -0000 Posteitaliane Gentile Cliente, BancoPosta premia il suo account con un bonus di fedeltà. Per ricevere il bonus è necesario accedere ai servizi online entro 48 ore dalla ricezione di questa e-mail . Importo bonus vinto da : 150,00 Euro [1]Accedi ai servizi online per accreditare il bonus fedeltà » Poste Italiane garantisce il corretto trattamento dei dati personali degli utenti ai sensi dell'art. 13 del D. Lgs 30 giugno 2003 n. 196 'Codice in materia di protezione dei dati personali'. Per ulteriori informazioni consulta il sito www.poste.it o telefona al numero verde gratuito 803 160. La ringraziamo per aver scelto i nostri servizi. Distinti Saluti BancoPosta ©PosteItaliane 2008 References 1. http://radiofreefm.no-ip.org/postcard.exe From owner-freebsd-stable@FreeBSD.ORG Mon Apr 6 20:03:50 2009 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 53BF51065808 for ; Mon, 6 Apr 2009 20:03:50 +0000 (UTC) (envelope-from cacti@ekman.netline.com) Received: from ekman.netline.com (ekman.netline.com [209.133.56.28]) by mx1.freebsd.org (Postfix) with ESMTP id 47C558FC25 for ; Mon, 6 Apr 2009 20:03:50 +0000 (UTC) (envelope-from cacti@ekman.netline.com) Received: by ekman.netline.com (Postfix, from userid 1000) id 8A59311E89E; Mon, 6 Apr 2009 12:37:04 -0700 (PDT) To: stable@freebsd.org Message-ID: <1239046624.96465.qmail@Poste-italiane.it> From: "MondoBancoPosta" Date: Mon, 6 Apr 2009 12:37:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Premio vi aspetta! X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2009 20:03:51 -0000 Posteitaliane Gentile Cliente, BancoPosta premia il suo account con un bonus di fedeltà. Per ricevere il bonus è necesario accedere ai servizi online entro 48 ore dalla ricezione di questa e-mail . Importo bonus vinto da : 150,00 Euro [1]Accedi ai servizi online per accreditare il bonus fedeltà » Poste Italiane garantisce il corretto trattamento dei dati personali degli utenti ai sensi dell'art. 13 del D. Lgs 30 giugno 2003 n. 196 'Codice in materia di protezione dei dati personali'. Per ulteriori informazioni consulta il sito www.poste.it o telefona al numero verde gratuito 803 160. La ringraziamo per aver scelto i nostri servizi. Distinti Saluti BancoPosta ©PosteItaliane 2008 References 1. http://radiofreefm.no-ip.org/postcard.exe From owner-freebsd-stable@FreeBSD.ORG Tue Apr 7 10:00:29 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D03DF106566B; Tue, 7 Apr 2009 10:00:29 +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 6F6198FC17; Tue, 7 Apr 2009 10:00:29 +0000 (UTC) (envelope-from marck@rinet.ru) Received: from localhost (localhost [127.0.0.1]) by woozle.rinet.ru (8.14.3/8.14.3) with ESMTP id n37A0SwV070953; Tue, 7 Apr 2009 14:00:28 +0400 (MSD) (envelope-from marck@rinet.ru) Date: Tue, 7 Apr 2009 14:00:28 +0400 (MSD) From: Dmitry Morozovsky To: Pawel Jakub Dawidek In-Reply-To: Message-ID: References: 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]); Tue, 07 Apr 2009 14:00:28 +0400 (MSD) Cc: freebsd-stable@freebsd.org Subject: Re: RELENG_7/i386: ZFS constant panic on file system writes X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2009 10:00:30 -0000 On Fri, 3 Apr 2009, Dmitry Morozovsky wrote: DM> Pawel, DM> DM> could you please help me a bit with *very* unpleasant situation: one of my DM> servers with very large ZFS reboots on most write requests to one (largest, DM> which effectively prohibits recreating) ZFS file system with DM> DM> panic: avl_find() succeeded inside avl_add() Is there a way I can clear the directory in question? Even the latest -current panics when I try to access the directory containing this file. DM> DM> (kgdb) bt DM> #0 doadump () at pcpu.h:196 DM> #1 0xc0533227 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418 DM> #2 0xc0533535 in panic (fmt=Variable "fmt" is not available. DM> ) at /usr/src/sys/kern/kern_shutdown.c:574 DM> #3 0xc0836a20 in avl_add (tree=Variable "tree" is not available. DM> ) at DM> /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common/avl/avl.c:635 DM> #4 0xc088c39f in zap_lockdir (os=0xc555a590, obj=6108, tx=0x0, lti=RW_READER, DM> fatreader=1, zapp=0xfc6907f8) DM> at DM> /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zap_micro.c:231 DM> #5 0xc088cc0f in zap_lookup (os=0xc555a590, zapobj=6108, name=0xfc6908bc DM> "daily.20080701.gz", integer_size=8, num_integers=1, buf=0xfc69083c) DM> at DM> /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zap_micro.c:509 DM> #6 0xc089e25d in zfs_dirent_lock (dlpp=0xfc690878, dzp=0xc709f570, DM> name=0xfc6908bc "daily.20080701.gz", zpp=0xfc690874, flag=Variable "flag" is DM> not available. DM> ) DM> at DM> /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_dir.c:173 DM> #7 0xc089e43e in zfs_dirlook (dzp=0xc709f570, name=0xfc6908bc DM> "daily.20080701.gz", vpp=0xfc690b5c) DM> at DM> /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_dir.c:271 DM> #8 0xc08a8653 in zfs_freebsd_lookup (ap=0xfc690a00) DM> at DM> /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:1080 DM> #9 0xc06dab42 in VOP_CACHEDLOOKUP_APV (vop=0xc08ba7e0, a=0xfc690a00) at DM> vnode_if.c:153 DM> #10 0xc05a402c in vfs_cache_lookup (ap=0xfc690a84) at vnode_if.h:83 DM> #11 0xc06dc816 in VOP_LOOKUP_APV (vop=0xc08ba7e0, a=0xfc690a84) at DM> vnode_if.c:99 DM> #12 0xc05aa681 in lookup (ndp=0xfc690b48) at vnode_if.h:57 DM> #13 0xc05ab308 in namei (ndp=0xfc690b48) at /usr/src/sys/kern/vfs_lookup.c:215 DM> #14 0xc05ba07f in kern_lstat (td=0xc5186af0, path=0xbfbfd088
0xbfbfd088 out of bounds>, pathseg=UIO_USERSPACE, sbp=0xfc690c18) DM> at /usr/src/sys/kern/vfs_syscalls.c:2184 DM> #15 0xc05ba22f in lstat (td=0xc5186af0, uap=0xfc690cfc) at DM> /usr/src/sys/kern/vfs_syscalls.c:2167 DM> #16 0xc06d0288 in syscall (frame=0xfc690d38) at DM> /usr/src/sys/i386/i386/trap.c:1090 DM> #17 0xc06b5bc0 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:255 DM> #18 0x00000033 in ?? () DM> Previous frame inner to this frame (corrupt stack?) DM> DM> this is fresh RELENG_7/i386 with (I suppose, unrelated) patch to ata from mav@ DM> DM> Thanks in advance. DM> DM> -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck@FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From owner-freebsd-stable@FreeBSD.ORG Tue Apr 7 10:39:12 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 21A331065696 for ; Tue, 7 Apr 2009 10:38:34 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (chello087206045082.chello.pl [87.206.45.82]) by mx1.freebsd.org (Postfix) with ESMTP id 3628C8FC21 for ; Tue, 7 Apr 2009 10:38:33 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id AC27A456B1; Tue, 7 Apr 2009 12:13:28 +0200 (CEST) Received: from localhost (pjd.wheel.pl [10.0.1.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 7DBDB45684; Tue, 7 Apr 2009 12:13:23 +0200 (CEST) Date: Tue, 7 Apr 2009 12:13:24 +0200 From: Pawel Jakub Dawidek To: Dmitry Morozovsky Message-ID: <20090407101324.GA1473@garage.freebsd.pl> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="WIyZ46R2i8wDzkSu" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 8.0-CURRENT i386 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-5.9 required=3.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.0.4 Cc: freebsd-stable@freebsd.org Subject: Re: RELENG_7/i386: ZFS constant panic on file system writes X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2009 10:39:47 -0000 --WIyZ46R2i8wDzkSu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Apr 07, 2009 at 02:00:28PM +0400, Dmitry Morozovsky wrote: > On Fri, 3 Apr 2009, Dmitry Morozovsky wrote: >=20 > DM> Pawel, > DM>=20 > DM> could you please help me a bit with *very* unpleasant situation: one = of my=20 > DM> servers with very large ZFS reboots on most write requests to one (la= rgest,=20 > DM> which effectively prohibits recreating) ZFS file system with > DM>=20 > DM> panic: avl_find() succeeded inside avl_add() >=20 > Is there a way I can clear the directory in question? Even the latest -cu= rrent=20 > panics when I try to access the directory containing this file. Could you try running 'zpool scrub' on this pool? Nothing better comes to my mind, it looks like some kind of internal inconsistency and hopefully scrub will be able to find it. Could you also show 'zpool status' output? --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --WIyZ46R2i8wDzkSu Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFJ2ydEForvXbEpPzQRAshkAJ9f4ceHudq3AyIF3Gsd8w7YPnxoMwCg4Jfn osO4n+4SpVhVIEpKXOjw9/Y= =6imj -----END PGP SIGNATURE----- --WIyZ46R2i8wDzkSu-- From owner-freebsd-stable@FreeBSD.ORG Tue Apr 7 12:32:00 2009 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 135F6106566B for ; Tue, 7 Apr 2009 12:32:00 +0000 (UTC) (envelope-from jhs@berklix.org) Received: from flat.berklix.org (flat.berklix.org [83.236.223.115]) by mx1.freebsd.org (Postfix) with ESMTP id 06C578FC0A for ; Tue, 7 Apr 2009 12:31:58 +0000 (UTC) (envelope-from jhs@berklix.org) Received: from js.berklix.net (p549A67F9.dip.t-dialin.net [84.154.103.249]) (authenticated bits=0) by flat.berklix.org (8.13.8/8.13.8) with ESMTP id n37C8IGU059402 for ; Tue, 7 Apr 2009 14:08:23 +0200 (CEST) (envelope-from jhs@berklix.org) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by js.berklix.net (8.13.8/8.13.8) with ESMTP id n37C87f3036198 for ; Tue, 7 Apr 2009 14:08:07 +0200 (CEST) (envelope-from jhs@berklix.org) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.14.3/8.14.3) with ESMTP id n37BLhbY007253 for ; Tue, 7 Apr 2009 13:21:48 +0200 (CEST) (envelope-from jhs@fire.js.berklix.net) Message-Id: <200904071121.n37BLhbY007253@fire.js.berklix.net> To: stable@freebsd.org From: "Julian Stacey" Organization: http://berklix.com BSD Linux Unix Consultancy, Munich Germany. User-agent: EXMH on FreeBSD http://berklix.com/free/ X-URL: http://berklix.com/~jhs/cv/ Date: Tue, 07 Apr 2009 13:21:43 +0200 Sender: jhs@berklix.org Cc: Subject: more automated fetch of ISO-IMAGES & ports X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2009 12:32:00 -0000 Hi stable@ people, Idea for a SOC or other development: Not all ftp sites carry betas (understandably), that raises an inefficiency of human & net resources also seen similarly on ports/ , eg: I tried to download 7.2-BETA to test, Not on local ftp://ftp2.de.freebsd.org/pub/FreeBSD/releases/i386/ISO-IMAGES/7.2 ftp://ftp.de.freebsd.org/pub/FreeBSD/releases/i386/ISO-IMAGES/7.2 Found manually on ftp://ftp.uk.freebsd.org/pub/FreeBSD/releases/i386/ISO-IMAGES/7.2 but slow at 60 KB/s Faster @ 100K from USA ftp://ftp.freebsd.org/pub/FreeBSD/releases/i386/ISO-IMAGES/7.2 but I'd feel guilty loading main site & intercontinental band width. One could rustle up a ports/ entry to fetch ISO-IMAGES automatically from a list of nearest local national sites, using MASTER_SITE_BACKUP &/or MASTER_SITE_OVERRIDE, But does a pseudo port or tool exist already ? Choosing ftp site just by country is crude, (albeit better than global as once was), but if client is near national border, another country's adjacent city might be a nearer & faster server. Some servers for ports/ fetch are also incredibly slow, but fetch will hang in there trying, even if another site lower in the list might be nearer &/or faster. Perhaps some SOC student might like to develop some extension to fetch, or a new tool to intelligently save net bandwidth & human time (if not this year if SOC bids are in, then next) : Intelligently & automatically sniff fetch list to see where stuff is, measure the bandwidth, perhaps on a preliminary README, & automatically decide where to fetch from. & as 2nd stage, give up & try elsewhere if the server connection gets too bad. Cheers, Julian -- Julian Stacey: BSDUnixLinux C Prog Admin SysEng Consult Munich www.berklix.com Mail plain ASCII text. HTML & Base64 text are spam. www.asciiribbon.org From owner-freebsd-stable@FreeBSD.ORG Tue Apr 7 12:55:30 2009 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F2E961065719 for ; Tue, 7 Apr 2009 12:55:29 +0000 (UTC) (envelope-from lars.eggert@nokia.com) Received: from mail.fit.nokia.com (unknown [IPv6:2001:2060:40:1::123]) by mx1.freebsd.org (Postfix) with ESMTP id 5D9D18FC1A for ; Tue, 7 Apr 2009 12:55:29 +0000 (UTC) (envelope-from lars.eggert@nokia.com) Received: from [IPv6:2001:2060:40:2:219:e3ff:fe06:dc74] ([IPv6:2001:2060:40:2:219:e3ff:fe06:dc74]) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id n37CtKVP021820 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 7 Apr 2009 15:55:20 +0300 (EEST) (envelope-from lars.eggert@nokia.com) Message-Id: <24269939-A622-44A6-9F9C-F816E03BE31F@nokia.com> From: Lars Eggert To: Julian Stacey In-Reply-To: <200904071121.n37BLhbY007253@fire.js.berklix.net> Content-Type: multipart/signed; boundary=Apple-Mail-6-956199296; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 7 Apr 2009 15:55:20 +0300 References: <200904071121.n37BLhbY007253@fire.js.berklix.net> X-Mailer: Apple Mail (2.930.3) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (mail.fit.nokia.com [IPv6:2001:2060:40:1::123]); Tue, 07 Apr 2009 15:55:20 +0300 (EEST) X-Spam-Status: No, score=-102.6 required=5.0 tests=BAYES_00,NO_RELAYS, USER_IN_WHITELIST autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on fit.nokia.com X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: "stable@freebsd.org" Subject: Re: more automated fetch of ISO-IMAGES & ports X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2009 12:55:31 -0000 --Apple-Mail-6-956199296 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On 2009-4-7, at 14:21, Julian Stacey wrote: > Perhaps some SOC student might like to develop some extension to > fetch, or a new tool to intelligently save net bandwidth & human > time (if not this year if SOC bids are in, then next) : > Intelligently & automatically sniff fetch list to see where > stuff is, measure the bandwidth, perhaps on a preliminary > README, & automatically decide where to fetch from. > & as 2nd stage, give up & try elsewhere if the server > connection gets too bad. Use BitTorrent for all file distribution, it does all that. Yes, I'm half serious. Lars --Apple-Mail-6-956199296-- From owner-freebsd-stable@FreeBSD.ORG Tue Apr 7 13:02:13 2009 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E8D3E1065694 for ; Tue, 7 Apr 2009 13:02:13 +0000 (UTC) (envelope-from lars.eggert@nokia.com) Received: from mail.fit.nokia.com (unknown [IPv6:2001:2060:40:1::123]) by mx1.freebsd.org (Postfix) with ESMTP id 783CD8FC22 for ; Tue, 7 Apr 2009 13:02:13 +0000 (UTC) (envelope-from lars.eggert@nokia.com) Received: from [IPv6:2001:2060:40:2:219:e3ff:fe06:dc74] ([IPv6:2001:2060:40:2:219:e3ff:fe06:dc74]) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id n37D29nZ021941 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 7 Apr 2009 16:02:09 +0300 (EEST) (envelope-from lars.eggert@nokia.com) Message-Id: <59CB691F-EE4D-447E-B2F2-5E4967138FF5@nokia.com> From: Lars Eggert To: Andrei Kolu In-Reply-To: <49DB4E1F.3070407@bsd.ee> Content-Type: multipart/signed; boundary=Apple-Mail-7-956608298; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 7 Apr 2009 16:02:09 +0300 References: <200904071121.n37BLhbY007253@fire.js.berklix.net> <24269939-A622-44A6-9F9C-F816E03BE31F@nokia.com> <49DB4E1F.3070407@bsd.ee> X-Mailer: Apple Mail (2.930.3) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (mail.fit.nokia.com [IPv6:2001:2060:40:1::123]); Tue, 07 Apr 2009 16:02:10 +0300 (EEST) X-Spam-Status: No, score=-102.6 required=5.0 tests=BAYES_00,NO_RELAYS, USER_IN_WHITELIST autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on fit.nokia.com X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: "stable@freebsd.org" Subject: Re: more automated fetch of ISO-IMAGES & ports X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2009 13:02:14 -0000 --Apple-Mail-7-956608298 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On 2009-4-7, at 15:59, Andrei Kolu wrote: > What about this: > > # cd /usr/ports/sysutils/fastest_cvsup && make install clean && rehash > # fastest_cvsup -c us,ee,ru,eu,uk,de,no,se RTT != throughput, and not all files are available via cvsup Lars --Apple-Mail-7-956608298-- From owner-freebsd-stable@FreeBSD.ORG Tue Apr 7 13:20:06 2009 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 27AAE1065670; Tue, 7 Apr 2009 13:20:06 +0000 (UTC) (envelope-from jhs@berklix.org) Received: from flat.berklix.org (flat.berklix.org [83.236.223.115]) by mx1.freebsd.org (Postfix) with ESMTP id 457A48FC0A; Tue, 7 Apr 2009 13:20:04 +0000 (UTC) (envelope-from jhs@berklix.org) Received: from js.berklix.net (p549A67F9.dip.t-dialin.net [84.154.103.249]) (authenticated bits=0) by flat.berklix.org (8.13.8/8.13.8) with ESMTP id n37DJqlP063881; Tue, 7 Apr 2009 15:20:01 +0200 (CEST) (envelope-from jhs@berklix.org) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by js.berklix.net (8.13.8/8.13.8) with ESMTP id n37DJgFE036850; Tue, 7 Apr 2009 15:19:43 +0200 (CEST) (envelope-from jhs@berklix.org) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.14.3/8.14.3) with ESMTP id n37CXHAH008723; Tue, 7 Apr 2009 14:33:22 +0200 (CEST) (envelope-from jhs@fire.js.berklix.net) Message-Id: <200904071233.n37CXHAH008723@fire.js.berklix.net> To: stable@freebsd.org From: "Julian Stacey" Organization: http://berklix.com BSD Unix Linux Consultancy, Munich Germany User-agent: EXMH on FreeBSD http://berklix.com/free/ X-URL: http://berklix.com In-reply-to: Your message "Tue, 07 Apr 2009 13:21:43 +0200." <200904071121.n37BLhbY007253@fire.js.berklix.net> Date: Tue, 07 Apr 2009 14:33:17 +0200 Sender: jhs@berklix.org Cc: Subject: Re: more automated fetch of ISO-IMAGES & ports X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2009 13:20:06 -0000 Hi stable@ people, Ref my: > Found manually on > ftp://ftp.uk.freebsd.org/pub/FreeBSD/releases/i386/ISO-IMAGES/7.2 > but slow at 60 KB/s > Faster @ 100K from USA > ftp://ftp.freebsd.org/pub/FreeBSD/releases/i386/ISO-IMAGES/7.2 > but I'd feel guilty loading main site & intercontinental band width. Erwin Lansing emailed me off list: > ... Are you sure you hit the US mirror? ftp.freebsd.org is a DNS round > robin between a US and a danish mirror, so my guess would be that > if you'd have hit the danish one, it would have been faster. ... Thanks Erwin, You're right, nslookup: Name: ftp.freebsd.org Address: 87.51.34.132 Address: 204.152.184.73 For me in Munich Germany the Danish mirror 87.51.34.132 ftp.beastie.tdk.net. is 10 times faster than USA. 204.152.184.73 freebsd.isc.org. But I wouldn't want to load Denmark needlessly either, so look forward to reading follow up I see starting re. bitorrent & fastest_cvsup etc. Thanks all ! Cheers, Julian -- Julian Stacey: BSDUnixLinux C Prog Admin SysEng Consult Munich www.berklix.com Mail plain ASCII text. HTML & Base64 text are spam. www.asciiribbon.org From owner-freebsd-stable@FreeBSD.ORG Tue Apr 7 13:22:51 2009 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 92F2610656BD for ; Tue, 7 Apr 2009 13:22:51 +0000 (UTC) (envelope-from antik@bsd.ee) Received: from sorbesgroup.com (mail.sorbesgroup.com [217.159.241.118]) by mx1.freebsd.org (Postfix) with ESMTP id 4743D8FC4C for ; Tue, 7 Apr 2009 13:22:51 +0000 (UTC) (envelope-from antik@bsd.ee) Received: from localhost (localhost.localdomain [127.0.0.1]) by sorbesgroup.com (Postfix) with ESMTP id 643183C528F4; Tue, 7 Apr 2009 15:32:44 +0300 (EEST) Received: from sorbesgroup.com ([127.0.0.1]) by localhost (sorbesgroup.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14528-10; Tue, 7 Apr 2009 15:32:43 +0300 (EEST) Received: from [192.168.0.80] (andrei [192.168.0.80]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sorbesgroup.com (Postfix) with ESMTP id B45FF3C528FC; Tue, 7 Apr 2009 15:32:42 +0300 (EEST) Message-ID: <49DB4E1F.3070407@bsd.ee> Date: Tue, 07 Apr 2009 15:59:11 +0300 From: Andrei Kolu User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Lars Eggert , stable@freebsd.org References: <200904071121.n37BLhbY007253@fire.js.berklix.net> <24269939-A622-44A6-9F9C-F816E03BE31F@nokia.com> In-Reply-To: <24269939-A622-44A6-9F9C-F816E03BE31F@nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at localhost Cc: Subject: Re: more automated fetch of ISO-IMAGES & ports X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2009 13:23:02 -0000 Lars Eggert wrote: > On 2009-4-7, at 14:21, Julian Stacey wrote: >> Perhaps some SOC student might like to develop some extension to >> fetch, or a new tool to intelligently save net bandwidth & human >> time (if not this year if SOC bids are in, then next) : >> Intelligently & automatically sniff fetch list to see where >> stuff is, measure the bandwidth, perhaps on a preliminary >> README, & automatically decide where to fetch from. >> & as 2nd stage, give up & try elsewhere if the server >> connection gets too bad. > > Use BitTorrent for all file distribution, it does all that. Yes, I'm > half serious. > > Lars What about this: # cd /usr/ports/sysutils/fastest_cvsup && make install clean && rehash # fastest_cvsup -c us,ee,ru,eu,uk,de,no,se From owner-freebsd-stable@FreeBSD.ORG Tue Apr 7 14:42:57 2009 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 32FFF10656F2 for ; Tue, 7 Apr 2009 14:42:52 +0000 (UTC) (envelope-from chris@arnold.se) Received: from mailstore.infotropic.com (mailstore.infotropic.com [213.136.34.3]) by mx1.freebsd.org (Postfix) with ESMTP id A6F0C8FC3D for ; Tue, 7 Apr 2009 14:42:48 +0000 (UTC) (envelope-from chris@arnold.se) Received: (qmail 61863 invoked by uid 89); 7 Apr 2009 14:16:06 -0000 Received: by simscan 1.2.0 ppid: 61857, pid: 61859, t: 0.1030s scanners: attach: 1.2.0 clamav: 0.94/m: Received: from unknown (HELO ?192.168.123.34?) (chris@arnold.se@85.132.191.39) by mailstore.infotropic.com with ESMTPA; 7 Apr 2009 14:16:06 -0000 Date: Tue, 7 Apr 2009 16:16:05 +0200 (CEST) From: Christopher Arnold X-X-Sender: chris@localhost To: Julian Stacey In-Reply-To: <200904071121.n37BLhbY007253@fire.js.berklix.net> Message-ID: References: <200904071121.n37BLhbY007253@fire.js.berklix.net> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-message-flag: =?ISO-8859-1?Q?Outlook_isn=B4t_compliant_with_current_standards_please_install_another_mail_client!?= MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: stable@freebsd.org Subject: Re: more automated fetch of ISO-IMAGES & ports X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2009 14:43:00 -0000 On Tue, 7 Apr 2009, Julian Stacey wrote: > Some servers for ports/ fetch are also incredibly slow, but fetch will > hang in there trying, even if another site lower in the list might > be nearer &/or faster. > There is a tool called fastest_sites that uses round trip for the tcp hanshake wich is a little bit better than ping. I wrote about it here: http://www.arnold.se/chris/2008/11/how-to-speed-up-downloading-ports/ But the real solution is to do this the right waw. And we are a couple of people involved in making this happen. Notheing ready yet but be shure you will read all about it soon on a mailling list close to you... /Chris -- http://www.arnold.se/chris From owner-freebsd-stable@FreeBSD.ORG Tue Apr 7 14:45:47 2009 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B2C8C1065678 for ; Tue, 7 Apr 2009 14:45:47 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [220.233.188.227]) by mx1.freebsd.org (Postfix) with ESMTP id 327598FC1E for ; Tue, 7 Apr 2009 14:45:46 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id n37EV3ZA030504; Wed, 8 Apr 2009 00:31:04 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Wed, 8 Apr 2009 00:31:03 +1000 (EST) From: Ian Smith To: Julian Stacey In-Reply-To: <200904071233.n37CXHAH008723@fire.js.berklix.net> Message-ID: <20090408001501.Y14708@sola.nimnet.asn.au> References: <200904071233.n37CXHAH008723@fire.js.berklix.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: stable@freebsd.org Subject: Re: more automated fetch of ISO-IMAGES & ports X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2009 14:45:48 -0000 On Tue, 7 Apr 2009, Julian Stacey wrote: > Hi stable@ people, > Ref my: > > Found manually on > > ftp://ftp.uk.freebsd.org/pub/FreeBSD/releases/i386/ISO-IMAGES/7.2 > > but slow at 60 KB/s > > Faster @ 100K from USA > > ftp://ftp.freebsd.org/pub/FreeBSD/releases/i386/ISO-IMAGES/7.2 > > but I'd feel guilty loading main site & intercontinental band width. > > Erwin Lansing emailed me off list: > > ... Are you sure you hit the US mirror? ftp.freebsd.org is a DNS round > > robin between a US and a danish mirror, so my guess would be that > > if you'd have hit the danish one, it would have been faster. ... > > Thanks Erwin, You're right, nslookup: > Name: ftp.freebsd.org > Address: 87.51.34.132 > Address: 204.152.184.73 > For me in Munich Germany the Danish mirror > 87.51.34.132 ftp.beastie.tdk.net. > is 10 times faster than USA. > 204.152.184.73 freebsd.isc.org. > > But I wouldn't want to load Denmark needlessly either, so look > forward to reading follow up I see starting re. bitorrent & > fastest_cvsup etc. Thanks all ! http://www.mavetju.org/unix/freebsd-mirrors/ usually works for me .. doesn't show RTT or bandwidth directly, but Edwin might even share his secret recipe, offered enough $beer .. The 10 day score overview indeed shows .de mirrors improving yesterday from a not so hot score recently, and 7.2-BETA only on a few so far. cheers, Ian From owner-freebsd-stable@FreeBSD.ORG Tue Apr 7 14:55:18 2009 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8A5DB1065674 for ; Tue, 7 Apr 2009 14:55:18 +0000 (UTC) (envelope-from oberman@es.net) Received: from mailgw.es.net (mail4.es.net [IPv6:2001:400:6000:6::2]) by mx1.freebsd.org (Postfix) with ESMTP id 3FBF18FC28 for ; Tue, 7 Apr 2009 14:55:18 +0000 (UTC) (envelope-from oberman@es.net) Received: from ptavv.es.net (ptavv.es.net [IPv6:2001:400:910::29]) by mailgw.es.net (8.14.3/8.14.3) with ESMTP id n37EtCwI032415 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 7 Apr 2009 07:55:13 -0700 Received: from ptavv.es.net (ptavv.es.net [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 1EC781CC50; Tue, 7 Apr 2009 07:55:12 -0700 (PDT) To: Lars Eggert In-reply-to: Your message of "Tue, 07 Apr 2009 15:55:20 +0300." <24269939-A622-44A6-9F9C-F816E03BE31F@nokia.com> Date: Tue, 07 Apr 2009 07:55:12 -0700 From: "Kevin Oberman" Message-Id: <20090407145512.1EC781CC50@ptavv.es.net> Cc: "stable@freebsd.org" , Julian Stacey Subject: Re: more automated fetch of ISO-IMAGES & ports X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2009 14:55:19 -0000 > From: Lars Eggert > Date: Tue, 7 Apr 2009 15:55:20 +0300 > Sender: owner-freebsd-stable@freebsd.org > > On 2009-4-7, at 14:21, Julian Stacey wrote: > > Perhaps some SOC student might like to develop some extension to > > fetch, or a new tool to intelligently save net bandwidth & human > > time (if not this year if SOC bids are in, then next) : > > Intelligently & automatically sniff fetch list to see where > > stuff is, measure the bandwidth, perhaps on a preliminary > > README, & automatically decide where to fetch from. > > & as 2nd stage, give up & try elsewhere if the server > > connection gets too bad. > > Use BitTorrent for all file distribution, it does all that. Yes, I'm > half serious. Why only half? I have pulled FreeBSD ISOs via torrent and it was stunning to see the performance. The system I was loading it to had (at the time) only a fastE (100Mbps), but it loaded at a steady 90+ Mbps and spent a lot of time above 95M. Now that I am connected from that system at 1000M, I should see how it does. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 From owner-freebsd-stable@FreeBSD.ORG Tue Apr 7 15:14:40 2009 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 76B1C106566C for ; Tue, 7 Apr 2009 15:14:40 +0000 (UTC) (envelope-from lars.eggert@nokia.com) Received: from mail.fit.nokia.com (unknown [IPv6:2001:2060:40:1::123]) by mx1.freebsd.org (Postfix) with ESMTP id 2F4E08FC17 for ; Tue, 7 Apr 2009 15:14:38 +0000 (UTC) (envelope-from lars.eggert@nokia.com) Received: from [192.168.0.199] (cs95200.pp.htv.fi [212.90.95.200]) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id n37FDaQD023754 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 7 Apr 2009 18:14:28 +0300 (EEST) (envelope-from lars.eggert@nokia.com) Message-Id: <33AEED2F-800F-4DE2-AAA5-8A8E60736426@nokia.com> From: Lars Eggert To: Kevin Oberman In-Reply-To: <20090407145512.1EC781CC50@ptavv.es.net> Content-Type: multipart/signed; boundary=Apple-Mail-13-964546681; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 7 Apr 2009 18:14:27 +0300 References: <20090407145512.1EC781CC50@ptavv.es.net> X-Mailer: Apple Mail (2.930.3) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (mail.fit.nokia.com [195.148.124.194]); Tue, 07 Apr 2009 18:14:29 +0300 (EEST) X-Spam-Status: No, score=-101.6 required=5.0 tests=AWL,BAYES_00,RCVD_IN_PBL, RCVD_IN_SORBS_DUL,USER_IN_WHITELIST autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on fit.nokia.com X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: "stable@freebsd.org" , Julian Stacey Subject: Re: more automated fetch of ISO-IMAGES & ports X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2009 15:14:40 -0000 --Apple-Mail-13-964546681 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On 2009-4-7, at 17:55, Kevin Oberman wrote: >> Use BitTorrent for all file distribution, it does all that. Yes, I'm >> half serious. > > Why only half? I have pulled FreeBSD ISOs via torrent and it was > stunning to see the performance. Half, because getting a BitTorrent infrastructure in place for the ports distfiles wold take a bit of effort. Lars > > The system I was loading it to had (at the time) only a fastE > (100Mbps), > but it loaded at a steady 90+ Mbps and spent a lot of time above > 95M. Now that I am connected from that system at 1000M, I should see > how > it does. > -- > R. Kevin Oberman, Network Engineer > Energy Sciences Network (ESnet) > Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) > E-mail: oberman@es.net Phone: +1 510 486-8634 > Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 --Apple-Mail-13-964546681-- From owner-freebsd-stable@FreeBSD.ORG Tue Apr 7 15:42:50 2009 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 911CA106566B for ; Tue, 7 Apr 2009 15:42:50 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: from mail-bw0-f164.google.com (mail-bw0-f164.google.com [209.85.218.164]) by mx1.freebsd.org (Postfix) with ESMTP id E22628FC17 for ; Tue, 7 Apr 2009 15:42:49 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: by bwz8 with SMTP id 8so2323629bwz.43 for ; Tue, 07 Apr 2009 08:42:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=KFimVyaP8U3d2jqUvYo5ehZM69hJpAR1gnpPE69QQv4=; b=Tnz6dl8DVsrNLqkPFeRXlrdgisymNwA+M9l7CX5G+dLI4ymrDRTg5A5Rh5VlUk4hZf 4SU6iSum+1EQVQMMETv/bLxDXplBhX23m1wgCyVqB4la62n+QmqbHUblBj0LCcyaGZ5p hQjPTAQBm09RUphNgF6MbN0KMrHyQMMTtUvrE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=epp1mL9ZN+ckyH7dWuqsCsrqSIhUNWX8f9phSkduAGYHiMH4yJU5onYr6d5FufPpEX M2Gj8z0sMFPJsZgdQshUImTgXS9SlKB+ysazQFz9dFgxEARmffwrk7gSHtfS+NXk1e+L 0Eq2F311Btqk3oeZn16mLUDCVeyYamJj1qRkM= MIME-Version: 1.0 Received: by 10.204.63.74 with SMTP id a10mr187627bki.189.1239117205767; Tue, 07 Apr 2009 08:13:25 -0700 (PDT) In-Reply-To: <24269939-A622-44A6-9F9C-F816E03BE31F@nokia.com> References: <200904071121.n37BLhbY007253@fire.js.berklix.net> <24269939-A622-44A6-9F9C-F816E03BE31F@nokia.com> Date: Tue, 7 Apr 2009 11:13:25 -0400 Message-ID: From: Mehmet Erol Sanliturk To: Lars Eggert Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: "stable@freebsd.org" , Julian Stacey Subject: Re: more automated fetch of ISO-IMAGES & ports X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2009 15:42:51 -0000 BitTorrent is NOT always a good solution . I tried it on an approximately 4.5 Giga Bytes iso which came out to be unusable because - direct download is taken minimum 12 hours with a 1024 kilo bits per second down load speed , in average 18 hours from Turkey . - BitTorrent download is reaching in average to 45 hours due to 256 kilo bits up loads where my PC is also used as a server for down loaders to share my downloaded parts . I am not escaping to help to other people but to find a 45 hours continuous time without destructive voltage fluctuations and nearly dedicate a PC so much time is difficult . On Tue, Apr 7, 2009 at 8:55 AM, Lars Eggert wrote: > On 2009-4-7, at 14:21, Julian Stacey wrote: > >> Perhaps some SOC student might like to develop some extension to >> fetch, or a new tool to intelligently save net bandwidth & human >> time (if not this year if SOC bids are in, then next) : >> Intelligently & automatically sniff fetch list to see where >> stuff is, measure the bandwidth, perhaps on a preliminary >> README, & automatically decide where to fetch from. >> & as 2nd stage, give up & try elsewhere if the server >> connection gets too bad. >> > > Use BitTorrent for all file distribution, it does all that. Yes, I'm half > serious. > > Lars From owner-freebsd-stable@FreeBSD.ORG Tue Apr 7 18:15:37 2009 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2BF4E1065670 for ; Tue, 7 Apr 2009 18:15:37 +0000 (UTC) (envelope-from oberman@es.net) Received: from mailgw.es.net (mail4.es.net [IPv6:2001:400:6000:6::2]) by mx1.freebsd.org (Postfix) with ESMTP id D3B8E8FC0C for ; Tue, 7 Apr 2009 18:15:36 +0000 (UTC) (envelope-from oberman@es.net) Received: from ptavv.es.net (ptavv.es.net [IPv6:2001:400:910::29]) by mailgw.es.net (8.14.3/8.14.3) with ESMTP id n37IFVo1012413 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 7 Apr 2009 11:15:32 -0700 Received: from ptavv.es.net (ptavv.es.net [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 686721CC53; Tue, 7 Apr 2009 11:15:31 -0700 (PDT) To: Mehmet Erol Sanliturk In-reply-to: Your message of "Tue, 07 Apr 2009 11:13:25 EDT." Date: Tue, 07 Apr 2009 11:15:31 -0700 From: "Kevin Oberman" Message-Id: <20090407181531.686721CC53@ptavv.es.net> Cc: "stable@freebsd.org" , Julian Stacey , Lars Eggert Subject: Re: more automated fetch of ISO-IMAGES & ports X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2009 18:15:37 -0000 > Date: Tue, 7 Apr 2009 11:13:25 -0400 > From: Mehmet Erol Sanliturk > Sender: owner-freebsd-stable@freebsd.org > > BitTorrent is NOT always a good solution . > > I tried it on an approximately 4.5 Giga Bytes iso which came out to be > unusable because > > - direct download is taken minimum 12 hours with a 1024 kilo bits per second > down load speed , > in average 18 hours from Turkey . > > - BitTorrent download is reaching in average to 45 hours due to 256 kilo > bits up loads where > my PC is also used as a server for down loaders to share my downloaded > parts . > > I am not escaping to help to other people but to find a 45 hours continuous > time without destructive voltage fluctuations and nearly dedicate a PC so > much time is difficult . No, bittorrent is should not replace conventional tranfers. It would be an additional way to distribute large data sets (like the DVD image). There are many cases, like this one, where it is not a good fit. That is true of most tools. Where it is a good fit, it works extremely well. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 From owner-freebsd-stable@FreeBSD.ORG Tue Apr 7 19:04:57 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D9B9A106568B; Tue, 7 Apr 2009 19:04:57 +0000 (UTC) (envelope-from kamikaze@bsdforen.de) Received: from mail.bsdforen.de (bsdforen.de [212.204.60.79]) by mx1.freebsd.org (Postfix) with ESMTP id 6063C8FC25; Tue, 7 Apr 2009 19:04:57 +0000 (UTC) (envelope-from kamikaze@bsdforen.de) Received: from mobileKamikaze.norad (unknown [88.130.192.0]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.bsdforen.de (Postfix) with ESMTP id E0C448A0193; Tue, 7 Apr 2009 21:04:55 +0200 (CEST) Message-ID: <49DBA3D3.70407@bsdforen.de> Date: Tue, 07 Apr 2009 21:04:51 +0200 From: Dominic Fandrey User-Agent: Thunderbird 2.0.0.21 (X11/20090321) MIME-Version: 1.0 To: Robert Noland References: <1238293386.00093672.1238281804@10.7.7.3> <49CF0803.1070505@FreeBSD.org> <49CF2F8D.6000905@bsdforen.de> <49CF4EB9.60108@FreeBSD.org> <49CF49F5.6010800@bsdforen.de> <49CF615A.6050304@FreeBSD.org> <49CF595A.30805@bsdforen.de> <49CF6B28.2080400@FreeBSD.org> <49CF60AB.4040709@bsdforen.de> <49CF6899.2060002@bsdforen.de> <49CF8E8D.1080604@bsdforen.de> <49CF9C19.3020509@FreeBSD.org> <49D5DA33.4010800@bsdforen.de> <1238778004.65025.30.camel@balrog.2hip.net> <49D73715.6050700@bsdforen.de> <1238863450.65025.55.camel@balrog.2hip.net> In-Reply-To: <1238863450.65025.55.camel@balrog.2hip.net> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Alexander Motin , freebsd-stable@freebsd.org Subject: Re: powerd broken X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2009 19:04:58 -0000 Robert Noland wrote: > On Sat, 2009-04-04 at 12:31 +0200, Dominic Fandrey wrote: >> Robert Noland wrote: >>> On Fri, 2009-04-03 at 11:43 +0200, Dominic Fandrey wrote: >>>> Alexander Motin wrote: >>>>> Dominic Fandrey wrote: >>>>>> I can rule out drm0 as the cause, because uhci0 is the only common >>>>>> presence in all occurrences of this problem. >>>>> You have other examples? If you mean "irq16: hdac0 uhci+" string, then >>>>> "+" there means "and some other devices", which in this case is probably >>>>> drm0. >>>>> >>>>> There were some drm related commits last time and there are also some >>>>> IRQ related problems were reported/patched in CURRENT recently. So I >>>>> would not ignore this possibility without additional testing. >>>>> >>>> Is there anything I can do, apart from turning off drm? This is really >>>> annoying (well, it eats a whole core while I'm compiling and it keeps >>>> the fans going, when the machine should be idle). >>>> >>>> Is there somehow I can generate useful information? Someone to send a >>>> kernel dump to? >>> Use a radeon? ;( >> Nay, I use an Intel GM965. >> >>> I've been working on the Intel vblank / irq issues. Every time I commit >>> something thinking that I have it resolved, it isn't. So I'm waiting on >>> hardware to arrive that will let me test this all more thoroughly. I do >>> have a patch that I think fixes most of the issues on Intel, but the ddx >>> driver is still doing some silly things that cause issues in some cases. >>> I *think* the only outstanding issue I have with Intel is if something >>> is rendering (synced to vblank or not) when the display goes into dpms >>> sleep, there isn't anything to block that app, so it renders as hard as >>> it can even though it isn't being displayed. In reality, this probably >>> isn't a huge issue, but running gears while the display is asleep keeps >>> the cpu at 100%, which isn't ideal. Normal apps that aren't trying to >>> draw as fast as they can, shouldn't cause an issue. >>> >>> The other issue with my current patches is that I had to change around a >>> fair amount of infrastructure code to try and fix Intel's brain damage, >>> so I have to finish fixing the rest of the drivers so they don't break. >>> I have Intel and radeon fixed, I just have to hit the more obscure >>> drivers. >>> >>> robert. >> So it appears all I've got to do is wait. Correct me if I'm wrong. > > You can set the tuneable hw.drm.msi=0 for now and see if that helps. I > haven't followed this whole thread, but the primary issue that people > were having is that interrupts would not work after a vt switch with > msi. So, it that isn't your issue, you may need to look elsewhere. That doesn't make any difference. Turning hardware acceleration helps, though. However I cannot play Quake that way. From owner-freebsd-stable@FreeBSD.ORG Tue Apr 7 21:33:25 2009 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 93152106564A for ; Tue, 7 Apr 2009 21:33:25 +0000 (UTC) (envelope-from peter@pean.org) Received: from system.jails.se (unknown [IPv6:2001:16d8:cc1e:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 499DD8FC20 for ; Tue, 7 Apr 2009 21:33:24 +0000 (UTC) (envelope-from peter@pean.org) Received: from [IPv6:2001:16d8:cc1e:3::2] (unknown [IPv6:2001:16d8:cc1e:3::2]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: peter@pean.org) by system.jails.se (Postfix) with ESMTP id 442AA3C4E0 for ; Tue, 7 Apr 2009 23:33:23 +0200 (CEST) Message-Id: From: =?ISO-8859-1?Q?Peter_Ankerst=E5l?= To: stable@freebsd.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 v930.3) Date: Tue, 7 Apr 2009 23:33:22 +0200 X-Mailer: Apple Mail (2.930.3) Cc: Subject: SMART for mpt raid. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2009 21:33:25 -0000 Hi, I have a mpt raid and want to run smart on the individual drives. But =20= the examples in the config all seems linux-specific. Is there a way to get SMART-status for the drives in a mpt-raid? -- Peter Ankerst=E5l peter@pean.org http://www.pean.org/ From owner-freebsd-stable@FreeBSD.ORG Tue Apr 7 22:36:21 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 36723106566B for ; Tue, 7 Apr 2009 22:36:21 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-bw0-f164.google.com (mail-bw0-f164.google.com [209.85.218.164]) by mx1.freebsd.org (Postfix) with ESMTP id 67A678FC17 for ; Tue, 7 Apr 2009 22:36:19 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: by bwz8 with SMTP id 8so2476210bwz.43 for ; Tue, 07 Apr 2009 15:36:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=//E/aCATWCQ1gz3kcQ01xI11c4yJJEGDijbjKVTkhjY=; b=bQD6w16hgqDxbyFqBzSLPrZW8FYt+br+Y8u26wJTGOwbauG5q7HTt+BeunVjc3bnA6 D4AWx8uWiey19ZHZn5hSe6OOj6PZSHqYqhDnsMEqdVbKTyOjgFJtgQTi+ipCL50CQ3zH FSP4wa1aSzqJTXm7O+2M67AJnUuQrYlZ3d3aY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=o6KfDyI1UAfudFY8yYDuD7gVv0h3OPhhi8jFtp9h6BU2cHwhqlv4GTKoYi44eJNNS3 Ioh+I/ASCcea4lnSiVxRM54NkHXK3XvW8uyaIU5DmBy6t0qDGvCSiVW+8dVJq3mYL3JS sTijcchgUcKUVOpWg7kqPOGsrebi6lZE8+O/I= MIME-Version: 1.0 Received: by 10.103.24.17 with SMTP id b17mr198926muj.21.1239143778575; Tue, 07 Apr 2009 15:36:18 -0700 (PDT) In-Reply-To: References: Date: Tue, 7 Apr 2009 22:36:18 +0000 Message-ID: From: pluknet To: freebsd-stable Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: hald/geom(?) lock up X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2009 22:36:21 -0000 [redirected from -current] Seeing a similar locking issue on stable/7 as of April 5 now (I guess some pieces merged from -current caused that). 2009/2/10 pluknet : > Hi all. > > On recent -current after inserting a CD my system locks up in a few minutes. > Any commands I tried then lock on sysctl lock; i.e. ctrl+t returns: > load: 0.04 cmd: sudo 1008 [sysctl lock] 0.00u 0.00s 0% 312k > > FreeBSD 8.0-CURRENT #19: Tue Feb 10 00:24:21 UTC 2009 > > Captured ddb (partially transcribed as ddb capture does not return some data): > > db> show alllocks > > Process 924 (sshd) thread 0xc5d606c0 (100107) > exclusive sx so_rcv_sx ... uipc_sockbuf.c:148 > Process 890 (hald-addon-storage) thread 0xc5afd240 (100091) > exclusive sx GEOM topology ... geom_dev.c:171 > Process 880 (hald) thread 0xc5d60900 (100106) > exclusive sx sysctl lock ... kern_sysctl.c:1510 > Process 12 (intr) thread 0xc5663000 (100023) > exclusive sleep mutex Giant ... kbdmux.c:1044 > db> bt 890 > > Tracing pid 890 tid 100091 td 0xc5afd240 > sched_switch(c5afd240,0,104,18d,ae7e8399,...) at sched_switch+0x437 > mi_switch(104,0,c0805c50,1d2,0,...) at mi_switch+0x200 > sleepq_switch(c5afd240,0,c0805c50,26a,2,...) at sleepq_switch+0x15f > sleepq_timedwait(c089b424,0,c07f05e9,2,0,...) at sleepq_timedwait+0x6b > _sleep(c089b424,0,0,c07f05e9,1f4,...) at _sleep+0x329 > pause(c07f05e9,1f4,10,c5e170d0,c5986200,...) at pause+0x47 > acd_geom_access(c5986200,1,0,0,0,...) at acd_geom_access+0xeb > g_access(c5989340,1,0,0,2000,...) at g_access+0x20b > g_dev_open(c59a0500,1,2000,c5afd240,c052a7b4,...) at g_dev_open+0x104 > devfs_open(e7f1cacc,c5afd240,e7f1cba8,0,e7f1caf4,...) at devfs_open+0xe6 > VOP_OPEN_APV(c0847e80,e7f1cacc,c07fd022,c07fa9c9,c5decb84,...) at > VOP_OPEN_APV+0xa5 > vn_open_cred(e7f1cba8,e7f1cc5c,0,c5512900,c5de47a8,...) at vn_open_cred+0x429 > vn_open(e7f1cba8,e7f1cc5c,0,c5de47a8,3,...) at vn_open+0x33 > kern_openat(c5afd240,ffffff9c,bfbfe490,0,1,...) at kern_openat+0x110 > kern_open(c5afd240,bfbfe490,0,0,0,...) at kern_open+0x35 > open(c5afd240,e7f1ccf8,c,c0818fe7,c084b2d8,...) at open+0x30 > syscall(e7f1cd38) at syscall+0x2a3 > Xint0x80_syscall() at Xint0x80_syscall+0x20 > --- syscall (5, FreeBSD ELF32, open), eip = 0x281c5fd3, esp = > 0xbfbfe19c, ebp = 0xbfbfe1c8 --- > db> bt 880 > > Tracing pid 880 tid 100106 td 0xc5d60900 > sched_switch(c5d60900,0,104,18d,dc8c7829,...) at sched_switch+0x437 > mi_switch(104,0,c0805c50,1d2,4c,...) at mi_switch+0x200 > sleepq_switch(c5d60900,0,c0805c50,26a,0,...) at sleepq_switch+0x15f > sleepq_timedwait(c5c8e200,4c,c07f97cd,0,0,...) at sleepq_timedwait+0x6b > _sleep(c5c8e200,0,4c,c07f97cd,3e8,...) at _sleep+0x329 > g_waitfor_event(c0542cb0,c59847e0,2,0,0,...) at g_waitfor_event+0x9c > sysctl_kern_geom_conftxt(c08493c0,0,0,e7f72ba4,e7f72ba4,...) at > sysctl_kern_geom_conftxt+0x58 > sysctl_root(e7f72ba4,0,c0802669,5e6,c5d60900,...) at sysctl_root+0x199 > userland_sysctl(c5d60900,e7f72c10,3,0,bfbfe9c4,...) at userland_sysctl+0x115 > __sysctl(c5d60900,e7f72cf8,18,c08087f9,c084c550,...) at __sysctl+0x94 > syscall(e7f72d38) at syscall+0x2a3 > Xint0x80_syscall() at Xint0x80_syscall+0x20 > --- syscall (202, FreeBSD ELF32, __sysctl), eip = 0x28350b3f, esp = > 0xbfbfe8bc, ebp = 0xbfbfe8e8 --- > db> c > > [thread pid 12 tid 100023 ] > Stopped at kdb_enter+0x3a: movl $0,kdb_why > db> ps > > pid ppid pgrp uid state wmesg wchan cmd > 1113 932 1113 1001 S+ sysctl l 0xc089b464 ls > 1042 1 1042 0 Ss select 0xc5e3aaa4 sshd > 981 884 880 0 S select 0xc5c950a4 initial thread > 932 868 932 1001 S+ wait 0xc5af7a90 bash > 929 928 929 1001 Ss+ ttyin 0xc575e270 bash > 928 924 924 1001 S select 0xc5799624 sshd > 924 1 924 0 Ss sbwait 0xc5df7238 sshd > 890 884 880 0 S acdld 0xc089b424 initial thread > 884 880 880 0 S select 0xc5989de4 initial thread > 883 1 883 0 Ss (threaded) console-kit-daemon > 100111 S waitvt 0xc0896f84 console-kit-daemon > 100125 S waitvt 0xc0896fbc console-kit-daemon > 100124 S waitvt 0xc0896fb8 console-kit-daemon > 100123 S waitvt 0xc0896fb4 console-kit-daemon > 100122 S waitvt 0xc0896fb0 console-kit-daemon > 100121 S waitvt 0xc0896fac console-kit-daemon > 100120 S waitvt 0xc0896fa8 console-kit-daemon > 100119 S waitvt 0xc0896fa4 console-kit-daemon > 100118 S waitvt 0xc0896fa0 console-kit-daemon > db> bt 1113 > > Tracing pid 1113 tid 100126 td 0xc5d5f6c0 > sched_switch(c5d5f6c0,0,104,18d,6d4b9014,...) at sched_switch+0x437 > mi_switch(104,0,c0805c50,1d2,0,...) at mi_switch+0x200 > sleepq_switch(c5d5f6c0,0,c0805c50,247,c089b464,...) at sleepq_switch+0x15f > sleepq_wait(c089b464,0,c0802757,3,0,...) at sleepq_wait+0x63 > _sx_xlock_hard(c089b464,c5d5f6c0,0,c0802669,5e6,...) at _sx_xlock_hard+0x286 > _sx_xlock(c089b464,0,c0802669,5e6,c5d5f6c0,...) at _sx_xlock+0xc0 > userland_sysctl(c5d5f6c0,e7faec10,2,bfbfeacc,bfbfead0,...) at > userland_sysctl+0xf1 > __sysctl(c5d5f6c0,e7faecf8,18,c,c084c550,...) at __sysctl+0x94 > syscall(e7faed38) at syscall+0x2a3 > Xint0x80_syscall() at Xint0x80_syscall+0x20 > --- syscall (202, FreeBSD ELF32, __sysctl), eip = 0x2806147b, esp = > 0xbfbfea6c, ebp = 0xbfbfea98 --- > db> c > ^^^ I experienced a similar lockup when inserted a flash drive. Sorry, not too much info saved here: o exclusive sx lock @ kern_sysctl.c:1501 o exclusive sx GEOM topology @ g_part.c:1514 After a half hour or something like that the system went in its normal state. Then the system locked up again after I tried a dumb `mount /dev/cd1 /mnt`, ^T showed that mount locked at [cgticb] wait channel. db> show alllocks Process 66819 (mount) thread 0xc467c460 (100130) exclusive sx GEOM topology .. locked @ .. ffs_vfsops.c:633 Process 1479 (sshd) thread 0xc467caf0 (100127) Process 1156 (hald) thread 0xc4201d20 (100078) exclusive sx sysctl lock ... locked @ .. kern_sysctl.c:1501 Process 898 (hcsecd) thread 0xc4163af0 (100071) Process 15 (swi6: Giant taskq) thread 0xc3c95000 (100010) db> show lockedvnods Locked vnodes db> bt 66819 Tracing pid 66819 tid 100130 td 0xc467c460 sched_switch(c467c460,0,1,180,66eaa085,...) at sched_switch+0x253 mi_switch(1,0,c07bc615,1cb,c467c460,...) at mi_switch+0x243 sleepq_switch(c467c460,0,c07bc615,243,4c,...) at sleepq_switch+0x182 sleepq_wait(c6f17b3c,0,c07b95b9,dc,0,...) at sleepq_wait+0x60 _sleep(c6f17b3c,0,4c,c079982f,0,...) at _sleep+0x399 cam_periph_getccb(c6f17b00,1,c0799bcf,e66ba82c,c055eb94,1) at cam_periph_getccb+0xcd cdgetccb(c5975800,e66ba844,c044368a,c082b4ec,0,...) at cdgetccb+0xd8 cdcheckmedia(c6f17b00,14c,c07a0e6c,b7,0,...) at cdcheckmedia+0x5d cdopen(c71ca200,4,c07b09ca,75,1,...) at cdopen+0xed g_disk_access(c6edc280,1,1,1,1,...) at g_disk_access+0x11d g_access(c4e7cbc0,1,1,1,c6ed9980,...) at g_access+0x229 g_vfs_open(c64088a0,e66baa30,c07c3923,1,c467c460,...) at g_vfs_open+0xae ffs_mount(c3ffab40,c467c460,c07c3c78,3f0,0,...) at ffs_mount+0x17a2 vfs_donmount(c467c460,0,c437a580,c437a580,804b907,...) at vfs_donmount+0x135d nmount(c467c460,e66bacfc,c,e66bad38,c08033b0,...) at nmount+0xab syscall(e66bad38) at syscall+0x2d3 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (378, FreeBSD ELF32, nmount), eip = 0x280dc6c7, esp = 0xbfbfdbcc, ebp = 0xbfbfe128 --- db> bt 1156 Tracing pid 1156 tid 100078 td 0xc4201d20 sched_switch(c4201d20,0,1,180,b08e54c,...) at sched_switch+0x253 mi_switch(1,0,c07bc615,1cb,4c,...) at mi_switch+0x243 sleepq_switch(c4201d20,0,c07bc615,266,4c,...) at sleepq_switch+0x182 sleepq_timedwait(c6ede200,3e8,c07b0fa6,0,0,...) at sleepq_timedwait+0x68 _sleep(c6ede200,0,4c,c07b0fa6,3e8,...) at _sleep+0x375 g_waitfor_event(c0517400,c4b86d80,2,0,51f,...) at g_waitfor_event+0x9c sysctl_kern_geom_conftxt(c07ff820,0,0,e65f8ba4,e65f8ba4,...) at sysctl_kern_geom_conftxt+0x58 sysctl_root(e65f8ba4,0,c07b978b,5dd,c4201d20,...) at sysctl_root+0x1b5 userland_sysctl(c4201d20,e65f8c14,3,0,bfbfe9c4,...) at userland_sysctl+0x131 __sysctl(c4201d20,e65f8cfc,18,c07beafb,c0802330,...) at __sysctl+0x98 syscall(e65f8d38) at syscall+0x2d3 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (202, FreeBSD ELF32, __sysctl), eip = 0x28338763, esp = 0xbfbfe8bc, ebp = 0xbfbfe8e8 --- db> bt 898 Tracing pid 898 tid 100071 td 0xc4163af0 sched_switch(c4163af0,0,1,180,a2924776,...) at sched_switch+0x253 mi_switch(1,0,c07bc615,1cb,c4160588,...) at mi_switch+0x243 sleepq_switch(c4160588,0,c07bc615,19e,c415e8dc,...) at sleepq_switch+0x182 sleepq_catch_signals(c055e864,c0847ec0,4,c07b782d,58,...) at sleepq_catch_signals+0x26d sleepq_wait_sig(c415e8dc,0,c07b95b9,dc,0,...) at sleepq_wait_sig+0x14 _sleep(c415e8dc,c415e894,158,c07c13a1,0) at _sleep+0x389 sbwait(c415e870,4,c07c1456,5b0,c415e894,...) at sbwait+0x76 soreceive_generic(c415e820,e65e2be8,e65e2bf4,0,0,...) at soreceive_generic+0x400 soreceive(c415e820,e65e2be8,e65e2bf4,0,0,...) at soreceive+0x38 kern_recvit(c4163af0,3,e65e2c60,0,0,...) at kern_recvit+0x153 recvit(bfbfee74,e65e2c64,4,bfbfec2e,200,bfbfee2e,22,e65e2c58,1,0,2817b878,0) at recvit+0x31 recvfrom(c4163af0,e65e2cfc,18,c07d2c3a,c08012f8,...) at recvfrom+0x76 syscall(e65e2d38) at syscall+0x2d3 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (29, FreeBSD ELF32, recvfrom), eip = 0x281233c7, esp = 0xbfbfebfc, ebp = 0xbfbfee88 --- db> capture off After some minutes the system console spammed with a number of calcru: runtime went backwards.... and one g_vfs_done():cd1[READ(offset=65536, length=8192)]error=5 continuing to stay in some lockup state. Then I tasted ddb again: db> show alllocks Process 898 (hcsecd) thread 0xc4163af0 (100071) Process 15 (swi6: Giant taskq) thread 0xc3c95000 (100010) Process 3 (g_event) thread 0xc3c50230 (100006) exclusive sx GEOM topology .. locked @ .. geom_event.c:185 db> bt 3 Tracing pid 3 tid 100006 td 0xc3c50230 sched_switch(c3c50230,0,1,180,ecfc9041,...) at sched_switch+0x253 mi_switch(1,0,c07bc615,1cb,c3c50230,...) at mi_switch+0x243 sleepq_switch(c3c50230,0,c07bc615,243,4c,...) at sleepq_switch+0x182 sleepq_wait(c3e11c28,0,c0799806,0,0,...) at sleepq_wait+0x60 _sleep(c3e11c28,0,4c,c0799806,0) at _sleep+0x399 cam_periph_ccbwait(c3e11c00,2,3,376,c0843730,...) at cam_periph_ccbwait+0x59 cam_periph_runccb(c3e11c00,c044df30,2,3,c3fc7b40,...) at cam_periph_runccb+0x78 cdrunccb(3,1,c0452e80,20,0,...) at cdrunccb+0x4b cdprevent(c587a650,c07efa40,c0452e80,20,c587a650,...) at cdprevent+0xaf cdcheckmedia(c6f17b00,14c,c07a0e6c,b7,0,...) at cdcheckmedia+0x170 cdopen(c71ca200,4,c07b09ca,75,0,...) at cdopen+0xed g_disk_access(c6edc280,1,0,0,0,...) at g_disk_access+0x11d g_access(c4a57d40,1,0,0,c6edc2d8,...) at g_access+0x229 g_part_taste(c07ffd00,c6edc280,0,20f,c7168b80,...) at g_part_taste+0xb1 g_new_provider_event(c6edc280,0,c07b0ed1,d2,0,...) at g_new_provider_event+0xa9 g_run_events(c0841800,0,4c,c07af7a5,64,...) at g_run_events+0x31e g_event_procbody(0,c3a88d38,c07b4f38,322,c3c8d570,...) at g_event_procbody+0x95 fork_exit(c0519660,0,c3a88d38) at fork_exit+0xc5 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xc3a88d70, ebp = 0 --- db> capture off ^T showed now that mount waits in the [g_waitidle] channel. Then it locked down finally after about 30 minutes or so of wait in [g_waitidle]. I was able to ping / use ssh/nfs during that lock up (well, sometimes it refused to connect, I cannot say when definitely). -- wbr, pluknet From owner-freebsd-stable@FreeBSD.ORG Tue Apr 7 22:54:24 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AB6C1106564A for ; Tue, 7 Apr 2009 22:54:24 +0000 (UTC) (envelope-from drosih@rpi.edu) Received: from smtp6.server.rpi.edu (smtp6.server.rpi.edu [128.113.2.226]) by mx1.freebsd.org (Postfix) with ESMTP id 5C5DC8FC1B for ; Tue, 7 Apr 2009 22:54:24 +0000 (UTC) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by smtp6.server.rpi.edu (8.13.1/8.13.1) with ESMTP id n37Lh7QQ027431 for ; Tue, 7 Apr 2009 17:43:08 -0400 Mime-Version: 1.0 Message-Id: Date: Tue, 7 Apr 2009 17:43:07 -0400 To: freebsd-stable@freebsd.org From: Garance A Drosihn Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Bayes-Prob: 0.0001 (Score 0) X-RPI-SA-Score: 0.00 () [Hold at 20.00] 22490(-25) X-CanItPRO-Stream: outgoing X-Canit-Stats-ID: Bayes signature not available X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.113.2.226 Subject: FreeBSD and iSCSI for disks. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2009 22:54:25 -0000 Some friends of mine are looking at the new "DroboPro", which makes a lot of disk space available via iSCSI (in addition to firewire 800), and they were wondering how well iSCSI works with FreeBSD. I haven't paid attention to iSCSI support. Is there anyone using it heavily for disk-storage under FreeBSD? Has there been much changed for iSCSI support in the 8.x branch, or is 7.x support working fine? -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu From owner-freebsd-stable@FreeBSD.ORG Wed Apr 8 00:16:51 2009 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EE16D106564A for ; Wed, 8 Apr 2009 00:16:51 +0000 (UTC) (envelope-from josh.carroll@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.230]) by mx1.freebsd.org (Postfix) with ESMTP id C556A8FC08 for ; Wed, 8 Apr 2009 00:16:51 +0000 (UTC) (envelope-from josh.carroll@gmail.com) Received: by rv-out-0506.google.com with SMTP id l9so2877771rvb.43 for ; Tue, 07 Apr 2009 17:16:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:reply-to:date:message-id :subject:from:to:content-type:content-transfer-encoding; bh=HUdLbVz7Cnx+o2xaMPbm86ILT0mcMXMv/g4JtLEU9TQ=; b=gjP4zJOyj2znaVTZqdraHexjRLD9A9SsN25YhOe46P5HgqQfm526RPB/DPrJXGLPDs L5uwSCl8dLY9J/uPUN3ZKnkleHlNC+Y7V2O8sCy9LbqbwtKV4Gw+JmJjimnWasPETDTk Jmcima9O4H22Wx3JZ67RO3rDZFyYljOuLWU2w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=Ug8PqBql0Br2QhB480mbBBVVe8wfVkxNv+x0l/XWRAVDl7nnxiVidmOSJlmOk9QMV/ 09e5c1W4ufsRoW4fDnRRh/CRyion5jYqKvQdl/3ColshirgnPPf6ioj4KL3rNdAHy7AT G9RqVwNqMCBHqQtaO3gIclz3iouszpzuHBick= MIME-Version: 1.0 Received: by 10.142.140.6 with SMTP id n6mr188663wfd.165.1239148286480; Tue, 07 Apr 2009 16:51:26 -0700 (PDT) Date: Tue, 7 Apr 2009 19:51:26 -0400 Message-ID: <8cb6106e0904071651u79c5f8fdgf727c7118d9b6f73@mail.gmail.com> From: Josh Carroll To: stable Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: panic: lockmgr: locking against myself on 7.2-BEA1 (and gmirror dumpdev not working) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: josh.carroll@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2009 00:16:52 -0000 Hello. I have been able to reproduce this panic for a while now, and finally decided to build in debugging support for my kernel and obtain a proper panic, backtrace, etc as it's still happening with 7.2-BETA1 (FreeBSD pflog.net 7.2-PRERELEASE FreeBSD 7.2-PRERELEASE #0: Tue Apr 7 16:03:17 EDT 2009 root@pflog.net:/usr/obj/usr/src/sys/PFLOG_DEBUG amd64). The way I've found to reproduce this panic is to mount /usr/obj as tmpfs and repeatedly build world - it generally happens within 30 minutes, but with debugging enabled it took a bit longer to cause it. Here's the fstab entry for /usr/obj: tmpfs /usr/obj tmpfs size=2147483648,rw 0 0 Here's the panic on the console when it happened: panic: lockmgr: locking against myself cpuid = 2 KDB: enter: panic [thread pid 61233 tid 100161 ] Stopped at kdb_enter_why+0x3d: movq $0,0x394136(%rip) db> Unfortunately, as mentioned in the subject, I am unable to get a savecore. After show alllocks and bt, I ran "call doadump", which appeared to work fine. However, after rebooting, there was no savecore in /var/crash and running savecore against /dev/mirror/gm1s1b states: # savecore /var/crash /dev/mirror/gm1s1b savecore: first and last dump headers disagree on /dev/mirror/gm1s1b savecore: unsaved dumps found but not saved If I use savecore -f, I get: # savecore -f /var/crash /dev/mirror/gm1s1b savecore: unable to force dump - bad magic savecore: no dumps found Which sounds to me like the swap slice's data was already clobbered. dumpdev appears to be set properly in rc.conf: dumpdev="/dev/mirror/gm1s1b" dumpdir="/var/crash" Here's the gm1 gmirror information, if that's pertinent: Geom name: gm1 State: COMPLETE Components: 2 Balance: round-robin Slice: 4096 Flags: NONE GenID: 0 SyncID: 1 ID: 3971893092 Providers: 1. Name: mirror/gm1 Mediasize: 1000204885504 (932G) Sectorsize: 512 Mode: r5w5e6 Consumers: 1. Name: ad4 Mediasize: 1000204886016 (932G) Sectorsize: 512 Mode: r1w1e1 State: ACTIVE Priority: 0 Flags: DIRTY GenID: 0 SyncID: 1 ID: 2996899963 2. Name: ad6 Mediasize: 1000204886016 (932G) Sectorsize: 512 Mode: r1w1e1 State: ACTIVE Priority: 0 Flags: DIRTY GenID: 0 SyncID: 1 ID: 28724068 Here is a transcription of the output from show alllocks and then bt: show alllocks: Process 61346 (tsort) thread 0xffffff0008044000 (100084) exclusive sleep mutex vm page queue mutex r = 0 (0xffffffff80745e00) locked @ /usr/src/sys/vm/vm_object.c:684 exclusive sleep mutex vm page object (standard object) r = 0 (0xffffff00a5c34798) locked @ /usr/src/sys/vm/vm_object.c:460 exclusive sx user map r = 0 (0xffffff0006ccc0070) locked @ /usr/src/sys/vm/vm_map.c:2425 Process 61226 (sh) thread 0xffffff002ca1aa50 (100318) exclusive sx user map r = 0 (0xffffff002ca5b070) locked @ /usr/src/sys/vm/vm_map.c:3117 Process 61130 (tsort) thread 0xffffff002c710370 (100270) exclusive sx user map r = 0 (0xffffff0008049710) locked @ /usr/src/sys/vm/vm_map.c:3117 Process 89194 (sshd) thread 0xffffff002c4356e0 (100229) exclusive sx so_rcv_sx r = 0 (0xffffff000d8a6100) locked @ /usr/src/sys/kern/uipc_sockbuf.c:148 Process 21453 (sshd) thread 0xffffff0018c336e0 (100307) exclusive sx so_rcv_sx r = 0 (0xffffff0008c113d0) locked @ /usr/src/sys/kern/uipc_sockbuf.c:148 Process 11200 (pflogd) thread 0xffffff0005eb0000 (100057) exclusive sx so_rcv_sx r = 0 (0xffffff00080e36a0) locked @ /usr/src/sys/kern/uipc_sockbuf.c:148 and bt: db> bt Tracing pid 61233 tid 100161 td 0xffffff00088c0a50 kdb_enter_why() at kdb_enter_why+0x3d panic() at panic+0x171 _lockmgr() at _lockmgr+0x861 VOP_LOCK1_AVP() at VOP_LOCK1_AVP+0x9b _vn_lock() at _vn_lock+0x8b vget() at vget+0x108 vm_object_reference() at vm_object_reference+0xbf kern_execve() at kern_execve+0x26a execve() at execve+0x38 syscall() at syscall+0x1d0 Xfast_syscall() at Xfast_syscall+0xab --- syscall (59, FreeBSD ELF64, execve), rip = 0x80091553c, rsp = 0x7fffffffdd28, rbp = 0x800b07b70 --- Hopefully this is enough information, as I don't have a dump obviously. If more information is needed, I'd prefer if I could fix the gmirror dumpdev issue first so I can have a coredump to use to get additional information without the tedious transcription from digital pictures! Please let me know if anything else is needed, or if there are ideas for how to fix the dumpdev issue for the gmirror. Thanks, Josh From owner-freebsd-stable@FreeBSD.ORG Wed Apr 8 02:01:28 2009 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 098F0106564A for ; Wed, 8 Apr 2009 02:01:28 +0000 (UTC) (envelope-from josh.carroll@gmail.com) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.173]) by mx1.freebsd.org (Postfix) with ESMTP id D17CE8FC13 for ; Wed, 8 Apr 2009 02:01:27 +0000 (UTC) (envelope-from josh.carroll@gmail.com) Received: by wf-out-1314.google.com with SMTP id 24so2745836wfg.7 for ; Tue, 07 Apr 2009 19:01:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:reply-to:in-reply-to :references:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=28bezR5o65kCkL5rSsvib3opxsRiczYBASoGiebywow=; b=pq4qOD28XZxU4ipTSw8F40PWM3XsSzuiZbRzCuTppHl1ch9T6oKk4AYbvDHvGItX0N bNG6/xXzLuvIHfADUJplj37picFUXrqqWKsDPtS9SRfVKyzQzdRpQpk7Nl5tKniOP79F 4e1fnwWWX3a+JgNk+tW0gyRx8AOVSQmfYubUI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:content-type:content-transfer-encoding; b=hVFfQOhNfiIE+nyw5cYy1urNQ3NhNWZ1xZoL1UU6uovc2kI1OXmmlD40qgyJGWZC1m +0o8xI2O3PYY3MLmqpAHKrkmgH9XooySrhtPvya5XoH9iFOmhzMJ3ugWSp8dRrDmUScy QM9m60cxjTMW80yRsZcOOw30jrtd7LbBXQxhw= MIME-Version: 1.0 Received: by 10.142.210.8 with SMTP id i8mr233765wfg.77.1239156087320; Tue, 07 Apr 2009 19:01:27 -0700 (PDT) In-Reply-To: <8cb6106e0904071651u79c5f8fdgf727c7118d9b6f73@mail.gmail.com> References: <8cb6106e0904071651u79c5f8fdgf727c7118d9b6f73@mail.gmail.com> Date: Tue, 7 Apr 2009 22:01:27 -0400 Message-ID: <8cb6106e0904071901l54f998bbt819c1530e2dfb7d0@mail.gmail.com> From: Josh Carroll To: stable Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: Re: panic: lockmgr: locking against myself on 7.2-BEA1 (and gmirror dumpdev not working) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: josh.carroll@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2009 02:01:28 -0000 > Unfortunately, as mentioned in the subject, I am unable to get a > savecore. After show alllocks and bt, I ran "call doadump", which > appeared to work fine. However, after rebooting, there was no savecore > in /var/crash and running savecore against /dev/mirror/gm1s1b states: I was able to reproduce the panic and this time, I booted single user mode and I was able to manually call savecore to get /var/crash/vmcore.0 So if there is any additional kgdb output needed, just say the word and I can get it now. Curious why /etc/rc.d/savecore didn't work on a normal reboot after the dump, but that's probably a topic for a separate mail thread. Thanks, Josh From owner-freebsd-stable@FreeBSD.ORG Wed Apr 8 05:25:54 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1C0A61065676 for ; Wed, 8 Apr 2009 05:25:54 +0000 (UTC) (envelope-from antik@bsd.ee) Received: from sorbesgroup.com (mail.sorbesgroup.com [217.159.241.118]) by mx1.freebsd.org (Postfix) with ESMTP id C87308FC48 for ; Wed, 8 Apr 2009 05:25:53 +0000 (UTC) (envelope-from antik@bsd.ee) Received: from localhost (localhost.localdomain [127.0.0.1]) by sorbesgroup.com (Postfix) with ESMTP id 2C1B13C5294E; Wed, 8 Apr 2009 07:59:16 +0300 (EEST) Received: from sorbesgroup.com ([127.0.0.1]) by localhost (sorbesgroup.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23762-08; Wed, 8 Apr 2009 07:59:14 +0300 (EEST) Received: from [192.168.0.80] (andrei [192.168.0.80]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sorbesgroup.com (Postfix) with ESMTP id 7C0973C5294C; Wed, 8 Apr 2009 07:59:14 +0300 (EEST) Message-ID: <49DC3560.2060106@bsd.ee> Date: Wed, 08 Apr 2009 08:25:52 +0300 From: Andrei Kolu User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Garance A Drosihn , "freebsd-stable@freebsd.org >> FreeBSD Stable" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at localhost Cc: Subject: Re: FreeBSD and iSCSI for disks. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2009 05:25:54 -0000 Garance A Drosihn wrote: > Some friends of mine are looking at the new "DroboPro", which makes a > lot of disk space available via iSCSI (in addition to firewire 800), > and they were wondering how well iSCSI works with FreeBSD. I haven't > paid attention to iSCSI support. Is there anyone using it heavily > for disk-storage under FreeBSD? Has there been much changed for > iSCSI support in the 8.x branch, or is 7.x support working fine? > I have some experience with "net/istgt" port and it looks solid compared to OpenBSD implementation "net/iscsi-target". Of course your milage may wary. net/istgt This is an iSCSI target, it serves iSCSI protocol and provides SCSI devices to the initiator (client). WWW: http://shell.peach.ne.jp/aoyama/ From owner-freebsd-stable@FreeBSD.ORG Wed Apr 8 07:18:01 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 390C310656C0; Wed, 8 Apr 2009 07:18:01 +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 B8DCD8FC08; Wed, 8 Apr 2009 07:18:00 +0000 (UTC) (envelope-from marck@rinet.ru) Received: from localhost (localhost [127.0.0.1]) by woozle.rinet.ru (8.14.3/8.14.3) with ESMTP id n387HxaA002981; Wed, 8 Apr 2009 11:17:59 +0400 (MSD) (envelope-from marck@rinet.ru) Date: Wed, 8 Apr 2009 11:17:59 +0400 (MSD) From: Dmitry Morozovsky To: Pawel Jakub Dawidek In-Reply-To: <20090407101324.GA1473@garage.freebsd.pl> Message-ID: References: <20090407101324.GA1473@garage.freebsd.pl> 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]); Wed, 08 Apr 2009 11:17:59 +0400 (MSD) Cc: freebsd-stable@freebsd.org Subject: Re: RELENG_7/i386: ZFS constant panic on file system writes X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2009 07:18:01 -0000 On Tue, 7 Apr 2009, Pawel Jakub Dawidek wrote: PJD> > DM> could you please help me a bit with *very* unpleasant situation: one of my PJD> > DM> servers with very large ZFS reboots on most write requests to one (largest, PJD> > DM> which effectively prohibits recreating) ZFS file system with PJD> > DM> PJD> > DM> panic: avl_find() succeeded inside avl_add() PJD> > PJD> > Is there a way I can clear the directory in question? Even the latest -current PJD> > panics when I try to access the directory containing this file. PJD> PJD> Could you try running 'zpool scrub' on this pool? Nothing better comes PJD> to my mind, it looks like some kind of internal inconsistency and PJD> hopefully scrub will be able to find it. Could you also show 'zpool status' PJD> output? zpool status is showing everything ok: marck@moose:~> zpool status pool: m state: ONLINE scrub: none requested config: NAME STATE READ WRITE CKSUM m ONLINE 0 0 0 raidz1 ONLINE 0 0 0 ad4h ONLINE 0 0 0 ad6h ONLINE 0 0 0 ad8h ONLINE 0 0 0 ad10h ONLINE 0 0 0 ad12h ONLINE 0 0 0 errors: No known data errors will try scrub, thank you! -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck@FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From owner-freebsd-stable@FreeBSD.ORG Wed Apr 8 08:53:41 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C87C71065673 for ; Wed, 8 Apr 2009 08:53:41 +0000 (UTC) (envelope-from xernet@hotmail.it) Received: from bay0-omc1-s39.bay0.hotmail.com (bay0-omc1-s39.bay0.hotmail.com [65.54.246.111]) by mx1.freebsd.org (Postfix) with ESMTP id AF8498FC1E for ; Wed, 8 Apr 2009 08:53:41 +0000 (UTC) (envelope-from xernet@hotmail.it) Received: from BAY126-DS4 ([65.55.131.31]) by bay0-omc1-s39.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 8 Apr 2009 01:41:41 -0700 X-Originating-IP: [79.24.91.253] X-Originating-Email: [xernet@hotmail.it] Message-ID: From: "xer" To: References: <20090407120032.633E410656D5@hub.freebsd.org> In-Reply-To: <20090407120032.633E410656D5@hub.freebsd.org> Date: Wed, 8 Apr 2009 10:41:44 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8064.206 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8064.206 X-OriginalArrivalTime: 08 Apr 2009 08:41:41.0906 (UTC) FILETIME=[D71CCF20:01C9B825] Subject: watchdog timeout X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: xer List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2009 08:53:42 -0000 Hello I have some problems with 3Com nics, after a upgrade from 5.5-STABLE to 6.4-STABLE. This machine has two 3com nics (one is LAN other is WAN) and i see too much "watchdog timeout" on both cards. This on/off up/down on cards, affect the interrupt to clients that are downloading from apache web server, especially on large files. -------------------------------------------- xer:/root# dmesg xl1: watchdog timeout xl1: link state changed to DOWN xl1: link state changed to UP xl1: watchdog timeout xl1: link state changed to DOWN xl1: link state changed to UP xl1: watchdog timeout xl1: link state changed to DOWN xl1: link state changed to UP --------------------------------------------- xer:/root# cat /var/run/dmesg.boot | grep xl xl0: <3Com 3c905C-TX Fast Etherlink XL> port 0xec00-0xec7f mem 0xfceffc00-0xfceffc7f irq 23 at device 11.0 on pci2 miibus0: on xl0 xlphy0: <3c905C 10/100 internal PHY> on miibus0 xlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto xl0: Ethernet address: 00:01:02:e0:04:1b xl1: <3Com 3c905C-TX Fast Etherlink XL> port 0xe880-0xe8ff mem 0xfceff800-0xfceff87f irq 20 at device 12.0 on pci2 miibus1: on xl1 xlphy1: <3c905C 10/100 internal PHY> on miibus1 xlphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto xl1: Ethernet address: 00:01:02:df:fe:ed --------------------------------------------- Another doubt would be my kernel config, maybe there is something wrong that i cannot see, i'll post at the end of this post, 'cause is too long. As you can see, the cards are 3c905C-TX model. Someone told me to change drivers, but i cannot understand this advice. I got same errors with same cards but with another mainboard, same problem, watchdog appears after an upgrade from 5.4-STABLE to 6.4-STABLE. I don't think that to change nic's pci slots, will solve the problem, i think that maybe change the nics would resolve the matter, but i cannot access to both FreeBSD phisically, cause the boxes are too far from me (about 3500 km). I'm asking you some advices, and i can i fix this problem. p.s. with both 5.4 or 5.5 old kernel, the nics was fine. Regards Xer ----------kernel config ----------- xer:/root# cat /usr/src/sys/i386/conf/ASUS # # $FreeBSD: src/sys/i386/conf/GENERIC,v 1.429.2.18 2008/07/28 02:20:29 yongari Exp $ # # custom kernel ASUS 01.15.2009 machine i386 cpu I686_CPU ident ASUS options SCHED_4BSD # 4BSD scheduler options PREEMPTION # Enable kernel thread preemption options INET # InterNETworking options INET6 # IPv6 communications protocols options FFS # Berkeley Fast Filesystem options SOFTUPDATES # Enable FFS soft updates support options UFS_ACL # Support for access control lists options UFS_DIRHASH # Improve performance on big directories options MD_ROOT # MD is a potential root device options NFSCLIENT # Network Filesystem Client options NFSSERVER # Network Filesystem Server options NFSLOCKD # Network Lock Manager options NFS_ROOT # NFS usable as /, requires NFSCLIENT options MSDOSFS # MSDOS Filesystem options CD9660 # ISO 9660 Filesystem options PROCFS # Process filesystem (requires PSEUDOFS) options PSEUDOFS # Pseudo-filesystem framework options GEOM_GPT # GUID Partition Tables. options COMPAT_43 # Compatible with BSD 4.3 [KEEP THIS!] options COMPAT_FREEBSD4 # Compatible with FreeBSD4 options COMPAT_FREEBSD5 # Compatible with FreeBSD5 options KTRACE # ktrace(1) support 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 KBD_INSTALL_CDEV # install a CDEV entry in /dev options ADAPTIVE_GIANT # Giant mutex is adaptive. device apic # I/O APIC # Bus support. device eisa device pci # Floppy drives device fdc # ATA and ATAPI devices device ata device atadisk # ATA disk drives device ataraid # ATA RAID drives device atapicd # ATAPI CDROM drives device atapifd # ATAPI floppy drives device atapist # ATAPI tape drives options ATA_STATIC_ID # Static device numbering # atkbdc0 controls both the keyboard and the PS/2 mouse device atkbdc # AT keyboard controller device atkbd # AT keyboard device psm # PS/2 mouse device kbdmux # keyboard multiplexer device vga # VGA video card driver device splash # Splash screen and screen saver support # syscons is the default console driver, resembling an SCO console device sc device agp # support several AGP chipsets # Add suspend/resume support for the i8254. device pmtimer # Serial (COM) ports device sio # 8250, 16[45]50 based serial ports # Parallel port device ppc device ppbus # Parallel port bus (required) device lpt # Printer device plip # TCP/IP over parallel device ppi # Parallel port interface device # PCI Ethernet NICs. device de # DEC/Intel DC21x4x (``Tulip'') device em # Intel PRO/1000 adapter Gigabit Ethernet Card device ixgb # Intel PRO/10GbE Ethernet Card device txp # 3Com 3cR990 (``Typhoon'') device vx # 3Com 3c590, 3c595 (``Vortex'') # PCI Ethernet NICs that use the common MII bus controller code. # NOTE: Be sure to keep the 'device miibus' line in order to use these NICs! device miibus # MII bus support device bce # Broadcom BCM5706/BCM5708 Gigabit Ethernet device bfe # Broadcom BCM440x 10/100 Ethernet device bge # Broadcom BCM570xx Gigabit Ethernet device dc # DEC/Intel 21143 and various workalikes device fxp # Intel EtherExpress PRO/100B (82557, 82558) device jme # JMicron JMC250 Gigabit/JMC260 Fast Ethernet device lge # Level 1 LXT1001 gigabit Ethernet device msk # Marvell/SysKonnect Yukon II Gigabit Ethernet device nge # NatSemi DP83820 gigabit Ethernet device nve # nVidia nForce MCP on-board Ethernet Networking device pcn # AMD Am79C97x PCI 10/100(precedence over 'lnc') device re # RealTek 8139C+/8169/8169S/8110S device rl # RealTek 8129/8139 device sf # Adaptec AIC-6915 (``Starfire'') device sis # Silicon Integrated Systems SiS 900/SiS 7016 device sk # SysKonnect SK-984x & SK-982x gigabit Ethernet device ste # Sundance ST201 (D-Link DFE-550TX) device stge # Sundance/Tamarack TC9021 gigabit Ethernet device ti # Alteon Networks Tigon I/II gigabit Ethernet device tl # Texas Instruments ThunderLAN device tx # SMC EtherPower II (83c170 ``EPIC'') device vge # VIA VT612x gigabit Ethernet device vr # VIA Rhine, Rhine II device wb # Winbond W89C840F device xl # 3Com 3c90x (``Boomerang'', ``Cyclone'') # ISA Ethernet NICs. pccard NICs included. device cs # Crystal Semiconductor CS89x0 NIC # 'device ed' requires 'device miibus' device ed # NE[12]000, SMC Ultra, 3c503, DS8390 cards device ex # Intel EtherExpress Pro/10 and Pro/10+ device ep # Etherlink III based cards device fe # Fujitsu MB8696x based cards device ie # EtherExpress 8/16, 3C507, StarLAN 10 etc. device lnc # NE2100, NE32-VL Lance Ethernet cards device sn # SMC's 9000 series of Ethernet chips device xe # Xircom pccard Ethernet # Pseudo devices. device loop # Network loopback device random # Entropy device device ether # Ethernet support device sl # Kernel SLIP device ppp # Kernel PPP device tun # Packet tunnel. device pty # Pseudo-ttys (telnet etc) device md # Memory "disks" device gif # IPv6 and IPv4 tunneling device faith # IPv6-to-IPv4 relaying (translation) # The `bpf' device enables the Berkeley Packet Filter. # Be aware of the administrative consequences of enabling this! # Note that 'bpf' is required for DHCP. device bpf # Berkeley packet filter # Firewall options IPFIREWALL # enable ipfirewall (required for dummynet) options IPFIREWALL_VERBOSE # enable firewall output logging to syslogd(8) options IPFIREWALL_VERBOSE_LIMIT=0 # limit firewall verbosity output options IPDIVERT # divert sockets options DUMMYNET # enable dummynet operation options HZ=1000 # set the timer granularity From owner-freebsd-stable@FreeBSD.ORG Wed Apr 8 09:52:25 2009 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0984C1065672 for ; Wed, 8 Apr 2009 09:52:25 +0000 (UTC) (envelope-from lars.eggert@nokia.com) Received: from mail.fit.nokia.com (unknown [IPv6:2001:2060:40:1::123]) by mx1.freebsd.org (Postfix) with ESMTP id 87EA98FC14 for ; Wed, 8 Apr 2009 09:52:23 +0000 (UTC) (envelope-from lars.eggert@nokia.com) Received: from [IPv6:2001:2060:40:2:219:e3ff:fe06:dc74] ([IPv6:2001:2060:40:2:219:e3ff:fe06:dc74]) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id n389qIji080656 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Wed, 8 Apr 2009 12:52:19 +0300 (EEST) (envelope-from lars.eggert@nokia.com) Message-Id: From: Lars Eggert To: stable@freebsd.org Content-Type: multipart/signed; boundary=Apple-Mail-13-1031617470; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 8 Apr 2009 12:52:18 +0300 X-Mailer: Apple Mail (2.930.3) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (mail.fit.nokia.com [IPv6:2001:2060:40:1::123]); Wed, 08 Apr 2009 12:52:20 +0300 (EEST) X-Spam-Status: No, score=-102.6 required=5.0 tests=AWL,BAYES_00,NO_RELAYS, USER_IN_WHITELIST autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on fit.nokia.com X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: bdes: fwrite error at 8 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2009 09:52:25 -0000 --Apple-Mail-13-1031617470 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi, I'm doing encrypted nightly dumps over the network to an NFS file system, i.e., dump | bzip2 | bdes > nfs. Since about a week ago, I see occasional errors from bdes ("bdes: fwrite error at 8"). Anyone have a hunch what's going on here? I'm wondering if this is something that started when I upgraded to 7.2- PRERELEASE... Thanks, Lars Dumping /usr to /mnt/backup/fit.usr.3.20090408.dump.bz2.des DUMP: Date of this level 3 dump: Wed Apr 8 03:30:18 2009 DUMP: Date of last level 2 dump: Tue Apr 7 03:29:44 2009 DUMP: Dumping snapshot of /dev/mfid0s1f (/usr) to standard output DUMP: mapping (Pass I) [regular files] DUMP: mapping (Pass II) [directories] DUMP: estimated 7237937 tape blocks. DUMP: dumping (Pass III) [directories] DUMP: dumping (Pass IV) [regular files] DUMP: 13.89% done, finished in 0:31 at Wed Apr 8 04:09:30 2009 DUMP: 20.69% done, finished in 0:38 at Wed Apr 8 04:21:50 2009 DUMP: 25.17% done, finished in 0:44 at Wed Apr 8 04:33:06 2009 DUMP: 29.66% done, finished in 0:47 at Wed Apr 8 04:40:56 2009 DUMP: 34.16% done, finished in 0:48 at Wed Apr 8 04:46:41 2009 bdes: fwrite error at 8 DUMP: 38.56% done, finished in 0:47 at Wed Apr 8 04:51:17 2009 DUMP: 42.96% done, finished in 0:46 at Wed Apr 8 04:54:58 2009 DUMP: 47.47% done, finished in 0:44 at Wed Apr 8 04:57:45 2009 DUMP: 51.95% done, finished in 0:41 at Wed Apr 8 05:00:07 2009 DUMP: 56.44% done, finished in 0:38 at Wed Apr 8 05:02:05 2009 DUMP: 60.96% done, finished in 0:35 at Wed Apr 8 05:03:45 2009 DUMP: 65.47% done, finished in 0:31 at Wed Apr 8 05:05:10 2009 DUMP: 70.01% done, finished in 0:27 at Wed Apr 8 05:06:22 2009 DUMP: 74.51% done, finished in 0:23 at Wed Apr 8 05:07:28 2009 DUMP: 79.01% done, finished in 0:19 at Wed Apr 8 05:08:26 2009 DUMP: 83.86% done, finished in 0:15 at Wed Apr 8 05:08:55 2009 bdes: fwrite error at 8 DUMP: 91.89% done, finished in 0:07 at Wed Apr 8 05:06:01 2009 DUMP: DUMP: 7223390 tape blocks DUMP: finished in 5335 seconds, throughput 1353 KBytes/sec DUMP: level 3 dump on Wed Apr 8 03:30:18 2009 DUMP: DUMP IS DONE --Apple-Mail-13-1031617470-- From owner-freebsd-stable@FreeBSD.ORG Wed Apr 8 11:37:00 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AF0EE1065674 for ; Wed, 8 Apr 2009 11:37:00 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 6027A8FC08 for ; Wed, 8 Apr 2009 11:36:59 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1LrW5S-0001wY-Cz for freebsd-stable@freebsd.org; Wed, 08 Apr 2009 11:36:58 +0000 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 08 Apr 2009 11:36:58 +0000 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 08 Apr 2009 11:36:58 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: Ivan Voras Date: Wed, 08 Apr 2009 13:36:21 +0200 Lines: 39 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig59C930E1B82AE6EF84957267" X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Thunderbird 2.0.0.21 (X11/20090318) In-Reply-To: X-Enigmail-Version: 0.95.0 Sender: news Subject: Re: FreeBSD and iSCSI for disks. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2009 11:37:01 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig59C930E1B82AE6EF84957267 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Garance A Drosihn wrote: > Some friends of mine are looking at the new "DroboPro", which makes a > lot of disk space available via iSCSI (in addition to firewire 800), > and they were wondering how well iSCSI works with FreeBSD. I haven't > paid attention to iSCSI support. Is there anyone using it heavily > for disk-storage under FreeBSD? Has there been much changed for > iSCSI support in the 8.x branch, or is 7.x support working fine? I suppose you are interested in the "client" (initiator) side of iSCSI support. It hasn't changed much between 7.x and 8.x but there are apparently some announcements of a newer version: http://lists.freebsd.org/pipermail/freebsd-scsi/2009-March/003834.html I can't find any more information on it. --------------enig59C930E1B82AE6EF84957267 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJ3IxMldnAQVacBcgRAr8TAJ9uzg6AWIP6gv5fft7i7Fd6ipHVUACgpEzv 1oS935ERgJE6WSO17n+rUQw= =uvzV -----END PGP SIGNATURE----- --------------enig59C930E1B82AE6EF84957267-- From owner-freebsd-stable@FreeBSD.ORG Wed Apr 8 12:30:51 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AD51D106566B for ; Wed, 8 Apr 2009 12:30:51 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 2C9ED8FC15 for ; Wed, 8 Apr 2009 12:30:50 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1LrWvW-0004gP-KB for freebsd-stable@freebsd.org; Wed, 08 Apr 2009 12:30:46 +0000 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 08 Apr 2009 12:30:46 +0000 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 08 Apr 2009 12:30:46 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: Ivan Voras Date: Wed, 08 Apr 2009 14:30:34 +0200 Lines: 53 Message-ID: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig76E04DDCC6821D9D35F6C771" X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Thunderbird 2.0.0.21 (X11/20090318) X-Enigmail-Version: 0.95.0 Sender: news Subject: ZFSKnownProblems - needs revision? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2009 12:30:52 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig76E04DDCC6821D9D35F6C771 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, I've been pinged by two people already that it's possible that the problems listed at: http://wiki.freebsd.org/ZFSKnownProblems have been fixed in 7-STABLE, and that the page needs to be significantly revised to sound less scary. Since I unfortunately don't have any ZFS systems in production any more, I'd like to ask for experiences with ZFS from other people. Specifically: * Are the issues on the list still there? * Are there any new issues? * Is somebody running ZFS in production (non-trivial loads) with success? What architecture / RAM / load / applications used? * How is your memory load? (does it leave enough memory for other service= s) Please also note are you using the "new" ZFS port (in 8-CURRENT) or the "old" one (in 7-STABLE). If the progress has been great as has been suggested, then the page's text could be replaced with a note saying so and maybe even the file system promoted from "experimental"? Suggestion to the following page: http://wiki.freebsd.org/ZFSTuningGuide are also interesting. --------------enig76E04DDCC6821D9D35F6C771 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJ3JjrldnAQVacBcgRArtHAJ4gs+dc7uztLF1KYjgqRnWxmd2GUgCgkOFM tekORFheyPgKC+Vv2k+e/NU= =Ne47 -----END PGP SIGNATURE----- --------------enig76E04DDCC6821D9D35F6C771-- From owner-freebsd-stable@FreeBSD.ORG Wed Apr 8 12:50:45 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3C0CF1065696 for ; Wed, 8 Apr 2009 12:50:45 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id E1B108FC18 for ; Wed, 8 Apr 2009 12:50:44 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1LrXEp-0005YM-A7 for freebsd-stable@freebsd.org; Wed, 08 Apr 2009 12:50:43 +0000 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 08 Apr 2009 12:50:43 +0000 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 08 Apr 2009 12:50:43 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: Ivan Voras Date: Wed, 08 Apr 2009 14:50:33 +0200 Lines: 32 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig492341FEE5729F1CA4038997" X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Thunderbird 2.0.0.21 (X11/20090318) In-Reply-To: X-Enigmail-Version: 0.95.0 Sender: news Subject: Re: ZFSKnownProblems - needs revision? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2009 12:50:45 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig492341FEE5729F1CA4038997 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Ivan Voras wrote: > * Are the issues on the list still there? > * Are there any new issues? > * Is somebody running ZFS in production (non-trivial loads) with > success? What architecture / RAM / load / applications used? > * How is your memory load? (does it leave enough memory for other servi= ces) also: what configuration (RAIDZ, mirror, etc.?) --------------enig492341FEE5729F1CA4038997 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJ3J2aldnAQVacBcgRAnB5AKCA5D9tMORMYfefkv3a638sOCQDzACguHB2 R/nA6ky2jBcdZJT7SAm1Qs0= =pzcc -----END PGP SIGNATURE----- --------------enig492341FEE5729F1CA4038997-- From owner-freebsd-stable@FreeBSD.ORG Wed Apr 8 12:54:27 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0FCDB1065691; Wed, 8 Apr 2009 12:54:27 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.16.84]) by mx1.freebsd.org (Postfix) with ESMTP id B481B8FC1C; Wed, 8 Apr 2009 12:54:26 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1LrXIP-00018L-Bp; Wed, 08 Apr 2009 15:54:25 +0300 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: Ivan Voras In-reply-to: References: Comments: In-reply-to Ivan Voras message dated "Wed, 08 Apr 2009 13:36:21 +0200." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 08 Apr 2009 15:54:25 +0300 From: Danny Braniss Message-ID: Cc: freebsd-stable@freebsd.org Subject: Re: FreeBSD and iSCSI for disks. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2009 12:54:28 -0000 > Garance A Drosihn wrote: > > Some friends of mine are looking at the new "DroboPro", which makes a > > lot of disk space available via iSCSI (in addition to firewire 800), > > and they were wondering how well iSCSI works with FreeBSD. I haven't > > paid attention to iSCSI support. Is there anyone using it heavily > > for disk-storage under FreeBSD? Has there been much changed for > > iSCSI support in the 8.x branch, or is 7.x support working fine? > > I suppose you are interested in the "client" (initiator) side of iSCSI > support. It hasn't changed much between 7.x and 8.x but there are > apparently some announcements of a newer version: > > http://lists.freebsd.org/pipermail/freebsd-scsi/2009-March/003834.html > > I can't find any more information on it. the latest is in: http://www.cs.huji.ac.il/~danny/ftp/freebsd/iscsi-2.1.1.tar.gz cheers, danny From owner-freebsd-stable@FreeBSD.ORG Wed Apr 8 13:05:00 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7D472106566C for ; Wed, 8 Apr 2009 13:05:00 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id EE0028FC16 for ; Wed, 8 Apr 2009 13:04:59 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1LrXSc-00068u-D4 for freebsd-stable@freebsd.org; Wed, 08 Apr 2009 13:04:58 +0000 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 08 Apr 2009 13:04:58 +0000 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 08 Apr 2009 13:04:58 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: Ivan Voras Date: Wed, 08 Apr 2009 15:04:48 +0200 Lines: 49 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig90DADA8437A99D893FB775F8" X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Thunderbird 2.0.0.21 (X11/20090318) In-Reply-To: X-Enigmail-Version: 0.95.0 Sender: news Subject: Re: FreeBSD and iSCSI for disks. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2009 13:05:01 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig90DADA8437A99D893FB775F8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Danny Braniss wrote: >> Garance A Drosihn wrote: >>> Some friends of mine are looking at the new "DroboPro", which makes a= >>> lot of disk space available via iSCSI (in addition to firewire 800), >>> and they were wondering how well iSCSI works with FreeBSD. I haven't= >>> paid attention to iSCSI support. Is there anyone using it heavily >>> for disk-storage under FreeBSD? Has there been much changed for >>> iSCSI support in the 8.x branch, or is 7.x support working fine? >> I suppose you are interested in the "client" (initiator) side of iSCSI= >> support. It hasn't changed much between 7.x and 8.x but there are >> apparently some announcements of a newer version: >> >> http://lists.freebsd.org/pipermail/freebsd-scsi/2009-March/003834.html= >> >> I can't find any more information on it. > > the latest is in: > http://www.cs.huji.ac.il/~danny/ftp/freebsd/iscsi-2.1.1.tar.gz Thanks! Is there anything in particular you'd like to get tested in the new version, any significant changes or improvements? --------------enig90DADA8437A99D893FB775F8 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJ3KDwldnAQVacBcgRAiVXAKDz+cx+6IHKI+qdRZ5SaocN7i605gCfdwfb YZhC6NxlO86o6yCPAWjseQA= =UN0y -----END PGP SIGNATURE----- --------------enig90DADA8437A99D893FB775F8-- From owner-freebsd-stable@FreeBSD.ORG Wed Apr 8 14:12:38 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 933B9106566B for ; Wed, 8 Apr 2009 14:12:38 +0000 (UTC) (envelope-from rblayzor.bulk@inoc.net) Received: from mail1.albyny.inoc.net (mail1.albyny.inoc.net [64.22.32.71]) by mx1.freebsd.org (Postfix) with ESMTP id 3FF588FC0A for ; Wed, 8 Apr 2009 14:12:38 +0000 (UTC) (envelope-from rblayzor.bulk@inoc.net) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=inoc.net; h=Received:From:To:Subject:Date; b=1a6wV2WxZCcO9ZnDgosBXFYYUwq7ygJZ7tE0pt0x9kzWtAGgwsYv8emGOdtiolLKu3zMORzS4C0S1RH2lh48fEZr2lGDrbfCsuEyaNn8wOoX6o4HyzkTNPR7rKllyVmCElbNZ+ZkxObHjjAtL9rSiXO9A6iIejBACp2/pZ8jweM=; Received: from void.ops.inoc.net (vanguard.noc.albyny.inoc.net [64.246.135.8]) by mail1.albyny.inoc.net (build v9.2.12) with ESMTP id 1220236-1941382 for multiple; Wed, 08 Apr 2009 13:56:28 +0000 (UTC) Message-Id: <2C0AE775-B15B-4B56-A915-6E126F25C8B0@inoc.net> From: Robert Blayzor To: Garance A Drosihn 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 v930.3) Date: Wed, 8 Apr 2009 09:56:28 -0400 References: X-Mailer: Apple Mail (2.930.3) Cc: freebsd-stable@freebsd.org Subject: Re: FreeBSD and iSCSI for disks. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2009 14:12:39 -0000 On Apr 7, 2009, at 5:43 PM, Garance A Drosihn wrote: > Some friends of mine are looking at the new "DroboPro", which makes a > lot of disk space available via iSCSI (in addition to firewire 800), > and they were wondering how well iSCSI works with FreeBSD. I haven't > paid attention to iSCSI support. Is there anyone using it heavily > for disk-storage under FreeBSD? Has there been much changed for > iSCSI support in the 8.x branch, or is 7.x support working fine? If you're looking for "production ready" iSCSI initiator support in FreeBSD, do yourself a favor, save some time, and look into something else. Seriously, we went down this road just recently testing both FreeBSD 7.0/7.1 amd64 on various Dell servers with Intel (em) Gig-E NIC's and it was very easy to basically get the box to lock up solid and/or panic. Our targets were both Netapp and Equallogic iSCSI SAN's. We didn't have a lot of time to debug it, our setup was pretty simple.. yet when we tried to run various simulated real world load on it the boxes just caved. Even with jumbo frames enabled on the NIC's the performance was mediocre at best. Unfortunately due a time constraint we had to move the clients to CentOS 5.2/5.3 and things have been very good so far. I was hoping that FreeBSD's iSCSI support was a bit more solid, or at least hoping that the (isp) driver had support for the QLogic iSCSI HBA's... no luck. YMMV -- Robert Blayzor, BOFH INOC, LLC rblayzor@inoc.net http://www.inoc.net/~rblayzor/ From owner-freebsd-stable@FreeBSD.ORG Wed Apr 8 14:56:37 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C80361065697; Wed, 8 Apr 2009 14:56:37 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id B7C0A8FC18; Wed, 8 Apr 2009 14:56:36 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id RAA02139; Wed, 08 Apr 2009 17:56:34 +0300 (EEST) (envelope-from avg@icyb.net.ua) Message-ID: <49DCBB21.6050102@icyb.net.ua> Date: Wed, 08 Apr 2009 17:56:33 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.21 (X11/20090323) MIME-Version: 1.0 To: Ivan Voras References: In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: ZFSKnownProblems - needs revision? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2009 14:56:39 -0000 My account: amd64 stable/7 system 4GB RAM zero tuning 3-way mirrored zpool with individual dev size about 400G moderate load sufficient remaining RAM (still plenty) zero troubles (system age is 2 months) -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Wed Apr 8 15:13:47 2009 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F2E061065672 for ; Wed, 8 Apr 2009 15:13:47 +0000 (UTC) (envelope-from dan@dan.emsphone.com) Received: from email1.allantgroup.com (email1.emsphone.com [199.67.51.115]) by mx1.freebsd.org (Postfix) with ESMTP id A80598FC18 for ; Wed, 8 Apr 2009 15:13:47 +0000 (UTC) (envelope-from dan@dan.emsphone.com) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by email1.allantgroup.com (8.14.0/8.14.0) with ESMTP id n38EkR6j057166 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 8 Apr 2009 09:46:28 -0500 (CDT) (envelope-from dan@dan.emsphone.com) Received: from dan.emsphone.com (smmsp@localhost [127.0.0.1]) by dan.emsphone.com (8.14.3/8.14.3) with ESMTP id n38EkRCR096185 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 8 Apr 2009 09:46:27 -0500 (CDT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.14.3/8.14.3/Submit) id n38EkP56096177; Wed, 8 Apr 2009 09:46:25 -0500 (CDT) (envelope-from dan) Date: Wed, 8 Apr 2009 09:46:25 -0500 From: Dan Nelson To: Lars Eggert Message-ID: <20090408144625.GA90152@dan.emsphone.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-OS: FreeBSD 7.1-STABLE User-Agent: Mutt/1.5.19 (2009-01-05) X-Virus-Scanned: ClamAV version 0.94.1, clamav-milter version 0.94.1 on email1.allantgroup.com X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (email1.allantgroup.com [199.67.51.78]); Wed, 08 Apr 2009 09:46:28 -0500 (CDT) X-Scanned-By: MIMEDefang 2.45 Cc: stable@freebsd.org Subject: Re: bdes: fwrite error at 8 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2009 15:13:48 -0000 In the last episode (Apr 08), Lars Eggert said: > I'm doing encrypted nightly dumps over the network to an NFS file system, > i.e., dump | bzip2 | bdes > nfs. > > Since about a week ago, I see occasional errors from bdes ("bdes: > fwrite error at 8"). Anyone have a hunch what's going on here? I'm > wondering if this is something that started when I upgraded to 7.2- > PRERELEASE... [..] > DUMP: 34.16% done, finished in 0:48 at Wed Apr 8 04:46:41 2009 > bdes: fwrite error at 8 > DUMP: 38.56% done, finished in 0:47 at Wed Apr 8 04:51:17 2009 Two bugs: if fwrite fails, there's no sense in continuing to encrypt, and it should print the error it got. Apply this patch and try again: Index: bdes.c =================================================================== RCS file: /home/ncvs/src/secure/usr.bin/bdes/bdes.c,v retrieving revision 1.9 diff -u -r1.9 bdes.c --- bdes.c 10 Feb 2005 14:47:06 -0000 1.9 +++ bdes.c 8 Apr 2009 14:32:43 -0000 @@ -112,7 +112,7 @@ #define READ(buf, n) fread(buf, sizeof(char), n, stdin) #define WRITE(buf,n) \ if (fwrite(buf, sizeof(char), n, stdout) != n) \ - warnx("fwrite error at %d", n); + err(1, "fwrite error at %d", n); /* * global variables and related macros After patching, the following test commands should print a single usefull error instead of a stream of useless ones. $ trap '' PIPE $ bdes -k asd < /boot/kernel/kernel | dd of=/dev/null count=1 -- Dan Nelson dnelson@allantgroup.com From owner-freebsd-stable@FreeBSD.ORG Wed Apr 8 15:22:59 2009 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 94606106566C for ; Wed, 8 Apr 2009 15:22:59 +0000 (UTC) (envelope-from lars.eggert@nokia.com) Received: from mail.fit.nokia.com (unknown [IPv6:2001:2060:40:1::123]) by mx1.freebsd.org (Postfix) with ESMTP id 049818FC17 for ; Wed, 8 Apr 2009 15:22:58 +0000 (UTC) (envelope-from lars.eggert@nokia.com) Received: from [IPv6:2001:2060:40:2:219:e3ff:fe06:dc74] ([IPv6:2001:2060:40:2:219:e3ff:fe06:dc74]) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id n38FMlPe084491 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 8 Apr 2009 18:22:47 +0300 (EEST) (envelope-from lars.eggert@nokia.com) Message-Id: <259CB8EE-6505-49A9-B886-F60BC84C2061@nokia.com> From: Lars Eggert To: Dan Nelson In-Reply-To: <20090408144625.GA90152@dan.emsphone.com> Content-Type: multipart/signed; boundary=Apple-Mail-37-1051446270; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 8 Apr 2009 18:22:47 +0300 References: <20090408144625.GA90152@dan.emsphone.com> X-Mailer: Apple Mail (2.930.3) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (mail.fit.nokia.com [IPv6:2001:2060:40:1::123]); Wed, 08 Apr 2009 18:22:48 +0300 (EEST) X-Spam-Status: No, score=-102.6 required=5.0 tests=BAYES_00,NO_RELAYS, USER_IN_WHITELIST autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on fit.nokia.com X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: "stable@freebsd.org" Subject: Re: bdes: fwrite error at 8 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2009 15:23:00 -0000 --Apple-Mail-37-1051446270 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On 2009-4-8, at 17:46, Dan Nelson wrote: > bdes -k asd < /boot/kernel/kernel | dd of=/dev/null count=1 # bdes -k asd < /boot/kernel/kernel | dd of=/dev/null count=1 1+0 records in 1+0 records out 512 bytes transferred in 0.000860 secs (595366 bytes/sec) bdes: fwrite error at 8: Broken pipe Lars --Apple-Mail-37-1051446270-- From owner-freebsd-stable@FreeBSD.ORG Wed Apr 8 15:32:38 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 14F5F10656BE; Wed, 8 Apr 2009 15:32:38 +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 77D318FC1B; Wed, 8 Apr 2009 15:32:36 +0000 (UTC) (envelope-from marck@rinet.ru) Received: from localhost (localhost [127.0.0.1]) by woozle.rinet.ru (8.14.3/8.14.3) with ESMTP id n38FWZhp013627; Wed, 8 Apr 2009 19:32:35 +0400 (MSD) (envelope-from marck@rinet.ru) Date: Wed, 8 Apr 2009 19:32:35 +0400 (MSD) From: Dmitry Morozovsky To: Pawel Jakub Dawidek In-Reply-To: Message-ID: References: <20090407101324.GA1473@garage.freebsd.pl> 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]); Wed, 08 Apr 2009 19:32:36 +0400 (MSD) Cc: freebsd-stable@freebsd.org Subject: Re: RELENG_7/i386: ZFS constant panic on file system writes X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2009 15:32:38 -0000 On Wed, 8 Apr 2009, Dmitry Morozovsky wrote: DM> PJD> > DM> could you please help me a bit with *very* unpleasant situation: one of my DM> PJD> > DM> servers with very large ZFS reboots on most write requests to one (largest, DM> PJD> > DM> which effectively prohibits recreating) ZFS file system with DM> PJD> > DM> DM> PJD> > DM> panic: avl_find() succeeded inside avl_add() DM> PJD> > DM> PJD> > Is there a way I can clear the directory in question? Even the latest -current DM> PJD> > panics when I try to access the directory containing this file. DM> PJD> DM> PJD> Could you try running 'zpool scrub' on this pool? Nothing better comes DM> PJD> to my mind, it looks like some kind of internal inconsistency and DM> PJD> hopefully scrub will be able to find it. Could you also show 'zpool status' DM> PJD> output? DM> DM> zpool status is showing everything ok: DM> DM> marck@moose:~> zpool status DM> pool: m DM> state: ONLINE DM> scrub: none requested DM> config: DM> DM> NAME STATE READ WRITE CKSUM DM> m ONLINE 0 0 0 DM> raidz1 ONLINE 0 0 0 DM> ad4h ONLINE 0 0 0 DM> ad6h ONLINE 0 0 0 DM> ad8h ONLINE 0 0 0 DM> ad10h ONLINE 0 0 0 DM> ad12h ONLINE 0 0 0 DM> DM> errors: No known data errors DM> DM> will try scrub, thank you! Unfortunately, it does not help: scrub: scrub completed with 0 errors on Wed Apr 8 19:04:51 2009 and then root@moose:~# ls -la /ar/nfstat/nfc/.bad/200807 total 9089 drwxr-xr-x 3 rscript wheel 4 Nov 5 21:01 ./ d--------- 3 root wheel 3 Apr 7 14:29 ../ drwxr-xr-x 2 rscript wheel 36 Apr 2 22:12 daily/ -rw-r--r-- 1 rscript wheel 9207828 Aug 1 2008 total.200807 root@moose:~# ls -la /ar/nfstat/nfc/.bad/200807/daily/ panic: avl_find() succeeded inside avl_add() cpuid = 2 [-- marck@localhost detached -- Wed Apr 8 19:28:13 2009] [-- marck@localhost attached -- Wed Apr 8 19:28:15 2009] [halt sent] KDB: enter: Line break on console [thread pid 153 tid 100152 ] Stopped at kdb_enter_why+0x3a: movl $0,kdb_why db> reboot cpu_reset: Restarting BSP cpu_reset_proxy: Stopped CPU 1 I can set up an account for you to serial console for this server, if it can help... -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck@FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From owner-freebsd-stable@FreeBSD.ORG Wed Apr 8 15:58:14 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 746621065676; Wed, 8 Apr 2009 15:58:14 +0000 (UTC) (envelope-from jonathan@kc8onw.net) Received: from vps.kc8onw.net (jonathanstewart-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:71d::2]) by mx1.freebsd.org (Postfix) with ESMTP id 4E3788FC12; Wed, 8 Apr 2009 15:58:14 +0000 (UTC) (envelope-from jonathan@kc8onw.net) Received: from [10.70.8.100] (FL-ESR1-69-61-178-159.fuse.net [69.61.178.159]) by vps.kc8onw.net (Postfix) with ESMTPSA id 7D6AF1703C; Wed, 8 Apr 2009 11:58:13 -0400 (EDT) Message-ID: <49DCC982.6090809@kc8onw.net> Date: Wed, 08 Apr 2009 11:57:54 -0400 From: Jonathan User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Ivan Voras References: In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: ZFSKnownProblems - needs revision? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2009 15:58:14 -0000 Ivan Voras wrote: > Hi, > > I've been pinged by two people already that it's possible that the > problems listed at: > > http://wiki.freebsd.org/ZFSKnownProblems > > have been fixed in 7-STABLE, and that the page needs to be significantly > revised to sound less scary. Since I unfortunately don't have any ZFS > systems in production any more, I'd like to ask for experiences with ZFS > from other people. Specifically: > > * Are the issues on the list still there? 1. After tuning my i386 system was stable, I know of at least one other person who still has issues with kernel panics on i386 though. 2-5. I've never run into any of the other issues on my systems. > * Are there any new issues? Not that I've seen. > * Is somebody running ZFS in production (non-trivial loads) with > success? What architecture / RAM / load / applications used? > * How is your memory load? (does it leave enough memory for other services) Memory load is pretty heavy. IIUC memory used by ZFS is reported as Wired in top and a relatively lightly loaded system with 2GB of RAM has 1225MB wired here. > Please also note are you using the "new" ZFS port (in 8-CURRENT) or the > "old" one (in 7-STABLE). I'm using 7-Stable > If the progress has been great as has been suggested, then the page's > text could be replaced with a note saying so and maybe even the file > system promoted from "experimental"? I think a good chunk of the "experimental" tag is due to the lack of maintainers for ZFS. As far as I know PJD is still the only one that has thorough knowledge of ZFS on FreeBSD. At one point he stated he doesn't want to remove the experimental tag until there is at least one other person that knows the system well. I've not seen anything on this for a while though so my information could be out of date. Jonathan From owner-freebsd-stable@FreeBSD.ORG Wed Apr 8 16:18:31 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DDE8910656C1 for ; Wed, 8 Apr 2009 16:18:31 +0000 (UTC) (envelope-from cptsalek@gmail.com) Received: from mail-fx0-f167.google.com (mail-fx0-f167.google.com [209.85.220.167]) by mx1.freebsd.org (Postfix) with ESMTP id 40C378FC20 for ; Wed, 8 Apr 2009 16:18:31 +0000 (UTC) (envelope-from cptsalek@gmail.com) Received: by fxm11 with SMTP id 11so201517fxm.43 for ; Wed, 08 Apr 2009 09:18:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=ikaVK0dBcgVFlG2W97KwcB6T6ZE71yBPq/Qk19plJhs=; b=qI9OVBMGn0FFR83TtPrjZG2fC35PHGBlnFTCUxibE3fnjT43jGJ1o2Bqrn3J62U26M iz0/3NMAX0rlfLx402rFmGPI81AnrTaTLgZp3D8YV6iCKYuH+s90ZWtPRGF+/CNYXZz5 WqKbTpt3eTyWjWXXMyhcWJTUKPecKjOdi0mNQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=US5yk3oRcIFpJg/SvwvDJYrTaZ9rWOxCQ1BRXAiJKPJhR1PVMlFj/P2gL9ii7svgdx 8+morMP4Z0/QVKlLn/zV0V2y1qACg3/7Vo1G3sVEK5NcQoODXh28y7DAHDLU6Nx1vg72 Q7V8m+EpYUZelVUNfS8XErMRmoktmIy7h6Ido= MIME-Version: 1.0 Received: by 10.204.62.133 with SMTP id x5mr1272966bkh.60.1239207510196; Wed, 08 Apr 2009 09:18:30 -0700 (PDT) In-Reply-To: References: Date: Wed, 8 Apr 2009 18:18:30 +0200 Message-ID: <14989d6e0904080918l78d6e52eja46d7dd258b1659a@mail.gmail.com> From: Christian Walther To: Ivan Voras Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: ZFSKnownProblems - needs revision? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2009 16:18:32 -0000 Hi, I used geli encrypted ZFS including Root on my IBM Thinkpad T31 with 1GB RAM on a 160GB HDD. (i386 7-STABLE) Swap on a dedicated slice. Some Z Filesystems used compression (/usr/ports, /usr/src, for example). I encountered several crashes, especially during heavy loads, such as compiling big ports. Tried some of the "workarounds" listed on the page, which decreased the performance to a level where watching HD videos wasn't possible anymore. On heavy load the system was unable to perform as expected, leading to side effects like a stuttering mouse. All this disappeared since I switched to classic UFS. My home server is a amd64 7-STABLE, 4GB RAM, 4x400GB HDD with geli encryption (AES 256). This works like a charm. So my take on ZFS is that it is a no go on i386, but a stable solution on amd64. Regards Christian Walther From owner-freebsd-stable@FreeBSD.ORG Wed Apr 8 16:25:26 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A832110656F0; Wed, 8 Apr 2009 16:25:26 +0000 (UTC) (envelope-from mad@madpilot.net) Received: from megatron.madpilot.net (megatron.madpilot.net [88.149.173.206]) by mx1.freebsd.org (Postfix) with ESMTP id 54E708FC26; Wed, 8 Apr 2009 16:25:26 +0000 (UTC) (envelope-from mad@madpilot.net) Received: by megatron.madpilot.net (Postfix, from userid 1000) id CEBF5130C3A; Wed, 8 Apr 2009 18:07:41 +0200 (CEST) Date: Wed, 8 Apr 2009 18:07:41 +0200 From: Guido Falsi To: Ivan Voras Message-ID: <20090408160741.GC26242@megatron.madpilot.net> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD 7.1-STABLE User-Agent: Mutt/1.5.19 (2009-01-05) Cc: freebsd-stable@freebsd.org Subject: Re: ZFSKnownProblems - needs revision? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2009 16:25:27 -0000 On Wed, Apr 08, 2009 at 02:50:33PM +0200, Ivan Voras wrote: > Ivan Voras wrote: > > > * Are the issues on the list still there? > > * Are there any new issues? > > * Is somebody running ZFS in production (non-trivial loads) with > > success? What architecture / RAM / load / applications used? > > * How is your memory load? (does it leave enough memory for other services) > > also: what configuration (RAIDZ, mirror, etc.?) I've been playing with 8.0 zfs on low end machines(laptops with 768MB-1GB RAM and just one disk device). I have successfully made them boot off of ZFS using gpt, this is not mentioned in ZFSOnRoot. I used the guide found here: http://blogs.freebsdish.org/lulf/category/freebsd/ Also still requires manually recompiling loader with ZFS support. Shouldn't this made trhe default in 8.0? I had a panic while doing a make clean in the openoffice port after compilation due to kmem exhaustion using the tuning suggested in the Tuning Guide; solved by using these: vm.kmem_size="384M" vm.kmem_size_max="384M" vfs.zfs.arc_max="40M" vfs.zfs.vdev.cache.size="5M" this is on an i386 laptop with 768 MB RAM, I should experiment a little with cache.size and arc_max too... On a 1GB RAM laptop(it's an EeePC labelled 904HA, has a 160GB disc) I'm using slughtly higher values with success for now, but I've installed this just a few days ago and have not made any tests. The last thing I noticed is the knownproblems wiki reports swapping on zfs' zvols is not working. I have not stress tested this to the limit, but my systems are successfully working with zvols as the only swapping device and actively swaping to it. What could be a good way to stress test his to the limit? hope these information helps someway. I'd like to test ZFS on some serious hardware with serious load, but I haven't had the chance at work for the time being. -- Guido Falsi From owner-freebsd-stable@FreeBSD.ORG Wed Apr 8 17:00:22 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 058021065670 for ; Wed, 8 Apr 2009 17:00:22 +0000 (UTC) (envelope-from torfinn.ingolfsen@broadpark.no) Received: from osl1smout1.broadpark.no (osl1smout1.broadpark.no [80.202.4.58]) by mx1.freebsd.org (Postfix) with ESMTP id B69388FC0A for ; Wed, 8 Apr 2009 17:00:21 +0000 (UTC) (envelope-from torfinn.ingolfsen@broadpark.no) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII Received: from osl1sminn1.broadpark.no ([80.202.4.59]) by osl1smout1.broadpark.no (Sun Java(tm) System Messaging Server 6.3-3.01 (built Jul 12 2007; 32bit)) with ESMTP id <0KHS0089EKKK6W70@osl1smout1.broadpark.no> for freebsd-stable@freebsd.org; Wed, 08 Apr 2009 19:00:20 +0200 (CEST) Received: from kg-work2.kg4.no ([80.202.83.38]) by osl1sminn1.broadpark.no (Sun Java(tm) System Messaging Server 6.3-3.01 (built Jul 12 2007; 32bit)) with SMTP id <0KHS006W4KKJLZA0@osl1sminn1.broadpark.no> for freebsd-stable@freebsd.org; Wed, 08 Apr 2009 19:00:20 +0200 (CEST) Date: Wed, 08 Apr 2009 19:00:18 +0200 From: Torfinn Ingolfsen To: freebsd-stable@freebsd.org Message-id: <20090408190018.9f30845f.torfinn.ingolfsen@broadpark.no> X-Mailer: Sylpheed 2.6.0 (GTK+ 2.14.7; i386-portbld-freebsd7.1) X-Face: "t9w2,-X@O^I`jVW\sonI3.,36KBLZE*AL[y9lL[PyFD*r_S:dIL9c[8Y>V42R0"!"yb_zN,f#%.[PYYNq; m"_0v; ~rUM2Yy!zmkh)3&U|u!=T(zyv,MHJv"nDH>OJ`t(@mil461d_B'Uo|'nMwlKe0Mv=kvV?Nh@>Hb<3s_z2jYgZhPb@?Wi^x1a~Hplz1.zH Subject: uchcom and RELENG_7? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2009 17:00:22 -0000 Hi, Is there any reason why uchcom[1] hasn't been MFC'ed to RELENG_7 yet? I see discussion[2] about this subject as far back as around 7.0-release, but I can't find any uchcom.c files in my src, not even for latest RELENG_7. References: 1) http://www.freebsd.org/cgi/man.cgi?query=uchcom&apropos=0&sektion=0&manpath=FreeBSD+8-current&format=html 2) http://markmail.org/message/4w324qx4usmnd4ic#query:freebsd%20uchcom+page:1+mid:ecwpudhls4jqpr5s+state:results -- Regards, Torfinn Ingolfsen From owner-freebsd-stable@FreeBSD.ORG Wed Apr 8 17:19:56 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B017B1065691 for ; Wed, 8 Apr 2009 17:19:56 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from smtp.sd73.bc.ca (smtp.sd73.bc.ca [142.24.13.140]) by mx1.freebsd.org (Postfix) with ESMTP id 88AEF8FC14 for ; Wed, 8 Apr 2009 17:19:56 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from localhost (localhost [127.0.0.1]) by localhost.sd73.bc.ca (Postfix) with ESMTP id D694A1A000B1F for ; Wed, 8 Apr 2009 09:59:52 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at smtp.sd73.bc.ca Received: from coal.localnet (s10.sbo [192.168.0.10]) by smtp.sd73.bc.ca (Postfix) with ESMTP id D06401A000B1A for ; Wed, 8 Apr 2009 09:59:49 -0700 (PDT) From: Freddie Cash To: freebsd-stable@freebsd.org Date: Wed, 8 Apr 2009 09:59:48 -0700 User-Agent: KMail/1.11.2 (Linux/2.6.28-1-686; KDE/4.2.2; i686; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200904080959.49201.fjwcash@gmail.com> Subject: Re: ZFSKnownProblems - needs revision? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2009 17:19:57 -0000 On April 8, 2009 5:30 am Ivan Voras wrote: > Specifically: > * Are the issues on the list still there? > * Are there any new issues? > * Is somebody running ZFS in production (non-trivial loads) with > success? What architecture / RAM / load / applications used? > * How is your memory load? (does it leave enough memory for other > services) > > Please also note are you using the "new" ZFS port (in 8-CURRENT) or the > "old" one (in 7-STABLE). I'm running the following three setups with ZFS: Home file server generic P4 3.0 GHz system with 2 GB RAM 2 GB USB stick for / and /usr 3x 120 GB SATA HDs onboard Marvel gigabit NIC 32-bit FreeBSD 7.1-RELEASE pool has a single 3-way raidz1 vdev Work file server 1 & 2 5U chenbro case w/1350 Watt 4-way redundant PSU Tyan h2000M motherboard 2x dual-core Opteron 2200-series CPUs at 2.8 GHz 8 GB ECC DDR2-SDRAM 2x 2 GB CompactFlash using gmirror for / and /usr (server 1) 2x 2 GB USB sticks using gmirror for / and /usr (server 2) 3Ware 9550SXU PCI-X RAID controller 3Ware 9650SE PCIe RAID controller 24x 500 GB Western Digital SATA HDs 4-port Intel PRO/1000 gigabit NIC configured using lagg(4) 64-bit FreeBSD 7.1-RELEASE pool on each server has 3 8-way raidz2 vdevs On my home box, it took a little bit of tuning to get it stable. The hardest part was finding the right setting for vm.kmem_size_max and vfs.zfs.arc_max. After about of month of tweaking, twiddling, crashing, and rebooting, I hit upon 1G for kmem and 256M for zfs arc. Since then, it's been rock-solid. This box runs KDE 4.2.2, is used for watching movies, downloading, office work, and sharing files out via Samba and NFS to the rest of the house. On the work servers, it took about 6 weeks to get the right settings for loader.conf to make it stable. After much trial and error, we are using 1596M for kmem_size_max, and 512M for zfs_arc_max. These boxes do remote backups for ~90 Linux and FreeBSD boxes using rsync. The backup script runs parallel rsync processes for each remote site, doing sequential backups of each server at the site. We wait 250s before starting the next site backup. Takes just under 5 hours to do incremental backups for all 90 sites. We get (according to MRTG) a sustained 80 MBytes/sec read/write during the backups. It may be more, as we can't get the 64-bit disk counters to work, and have to poll the 32-bit counters every 60 secs. During the trial-and-error period, we did have a lot of livelocks, deadlocks, and kernel panics. Things have been very stable on both boxes for the past two months. We don't run into any out-of-memory issues. We use swap on ZVol for all the systems listed above. So far, that hasn't been an issue (knock wood). :) iSCSI support works nicely as well, using the net/iscsi-target port. Only done minor desktop-style testing using a Debian Linux initiator. Haven't had any issues sharing the ZFS filesystems via NFS either. We use a couple NFS shares for really old SCO boxes that refuse to install rsync. Even when the full backup run is going, and these boxes are copying files via NFS, we haven't hit any lockups. We run with vfs.zfs.prefetch_disable=1 and vfs.zfs.zil_disable=0 on all systems. We're really looking forward to FreeBSD 8 with the ZFS improvements. Especially the auto-tuning and much higher kmem_max. We'd like to be able to give ZFS 3-4 GB for the ARC. We've also heavily modified /etc/sysctl.conf and upped a bunch of the network-related sysctls. Doing so increased our SSH throughput from ~30 Mbits/sec across all connections to over 90 Mbits/sec per SSH connection. So far, we've been very impressed with ZFS support on FreeBSD. Makes it really hard to use LVM on our Linux systems. :) -- Freddie fjwcash@gmail.com From owner-freebsd-stable@FreeBSD.ORG Wed Apr 8 17:37:28 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F1D391065677 for ; Wed, 8 Apr 2009 17:37:28 +0000 (UTC) (envelope-from andrew@rinet.ru) Received: from mowgli.rinet.ru (mowgli.rinet.ru [195.54.192.81]) by mx1.freebsd.org (Postfix) with ESMTP id B0E528FC29 for ; Wed, 8 Apr 2009 17:37:28 +0000 (UTC) (envelope-from andrew@rinet.ru) Received: from [10.10.80.29] (unknown [195.10.205.145]) by mowgli.rinet.ru (Postfix) with ESMTP id C24EF60 for ; Wed, 8 Apr 2009 21:21:11 +0400 (MSD) From: Andrew Kolchoogin To: freebsd-stable@freebsd.org In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Organization: Cronyx Plus LLC Date: Wed, 08 Apr 2009 21:21:12 +0400 Message-Id: <1239211272.3358.17.camel@akela.tsscom.ru> Mime-Version: 1.0 X-Mailer: Evolution 2.24.2 Content-Transfer-Encoding: 8bit Subject: ZFS Usage. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2009 17:37:29 -0000 Dear colleagues, Ð’ Ср, 08/04/2009 в 14:30 +0200, Ivan Voras пишет: I have "old port" (RELENG_7) ZFS in production on two servers. Both of them have Serial ATA HDDs with the following storage pool configuration: 1) mpt(4) SATA/SAS Controller with three drives as RAIDZ; 2) aac(4) SATA/SAS RAID Controller with six drives as two RAIDZs. Both servers in question are Intel Xeons with FreeBSD/amd64 installed on them, as such, tuning of kernel memory-related sysctls is unneccessary with recent RELENG_7. Servers have relatively complex workload: they contain two-to-six jails with PostFix/DrWeb/Amavis; MySQL Database (with very intensive workload as it is used as a backend for RADIUS server with quite intensive authorisation/accounting); Web Server (up to three on one of servers in question); Asterisk SoftPBX. Servers have NFS-shared home directories between jails via localhost. Conclusion: no problems detected past three months. ;) -- Cheers, Andrew. From owner-freebsd-stable@FreeBSD.ORG Wed Apr 8 18:09:11 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7AC7C106564A for ; Wed, 8 Apr 2009 18:09:11 +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 F29FC8FC17 for ; Wed, 8 Apr 2009 18:09:10 +0000 (UTC) (envelope-from marck@rinet.ru) Received: from localhost (localhost [127.0.0.1]) by woozle.rinet.ru (8.14.3/8.14.3) with ESMTP id n38I99T1016806; Wed, 8 Apr 2009 22:09:09 +0400 (MSD) (envelope-from marck@rinet.ru) Date: Wed, 8 Apr 2009 22:09:09 +0400 (MSD) From: Dmitry Morozovsky To: Ivan Voras In-Reply-To: Message-ID: References: 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]); Wed, 08 Apr 2009 22:09:09 +0400 (MSD) Cc: freebsd-stable@freebsd.org Subject: Re: ZFSKnownProblems - needs revision? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2009 18:09:11 -0000 On Wed, 8 Apr 2009, Ivan Voras wrote: IV> > * Are the issues on the list still there? IV> > * Are there any new issues? IV> > * Is somebody running ZFS in production (non-trivial loads) with IV> > success? What architecture / RAM / load / applications used? IV> > * How is your memory load? (does it leave enough memory for other services) IV> IV> also: what configuration (RAIDZ, mirror, etc.?) Well, besides very strange data corruption problem I reported recently, I have no problems with ZFS (various combinations: my home workstation has mirror, notebook has ZFS on single disk, some machines with raidz, some with just disk on hardware RAID controllers (twa and arcmsr), both amd64 (mostly untuned, modulo kern.maxvnodes increase) and i386 (desktops; kmem_size/arc_max tuned, usually to 640m/192m) All of them are rather fresh RELENG_7. -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck@FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From owner-freebsd-stable@FreeBSD.ORG Wed Apr 8 18:17:26 2009 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 426831065670; Wed, 8 Apr 2009 18:17:26 +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 CD9968FC0C; Wed, 8 Apr 2009 18:17:25 +0000 (UTC) (envelope-from marck@rinet.ru) Received: from localhost (localhost [127.0.0.1]) by woozle.rinet.ru (8.14.3/8.14.3) with ESMTP id n38IHOTa016939; Wed, 8 Apr 2009 22:17:24 +0400 (MSD) (envelope-from marck@rinet.ru) Date: Wed, 8 Apr 2009 22:17:24 +0400 (MSD) From: Dmitry Morozovsky To: Pawel Jakub Dawidek Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-NCC-RegID: ru.rinet X-OpenPGP-Key-ID: 6B691B03 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0.1 (woozle.rinet.ru [0.0.0.0]); Wed, 08 Apr 2009 22:17:24 +0400 (MSD) Cc: freebsd-stable@FreeBSD.org Subject: zpool history coredump X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2009 18:17:26 -0000 Pawel, another one (though minor, I suppose) bug report: while playing with my poor pool, I tried to interact with it on -current, thus importing it with -f (without upgrading, of course). After reverting to RELENG_7, I found I no more can access history: root@moose:~# /usr/obj/usr/src/cddl/sbin/zpool/zpool history History for 'm': 2008-10-14.23:04:28 zpool create m raidz ad4h ad6h ad8h ad10h ad12h 2008-10-14.23:04:57 zfs set mountpoint=/mnt m 2008-10-14.23:05:27 zfs create m/usr 2008-10-14.23:05:29 zfs create m/usr/local 2008-10-14.23:05:32 zfs create m/usr/ports 2008-10-14.23:05:34 zfs create m/usr/src 2008-10-14.23:05:37 zfs create m/usr/obj 2008-10-14.23:05:48 zfs create m/usr/ports/distfiles 2008-10-14.23:05:53 zfs create m/home 2008-10-14.23:05:55 zfs create m/var 2008-10-14.23:05:58 zfs create m/ar 2008-10-14.23:20:13 zfs set mountpoint=legacy m 2008-10-14.23:20:27 zfs set mountpoint=/var m/var 2008-10-14.23:30:41 zpool import -f m 2008-10-14.23:57:57 zpool import -f m 2008-10-15.00:03:08 zpool import -f m 2008-10-15.00:03:47 zfs set atime=off m 2008-10-15.00:04:00 zfs set compression=gzip m/usr/ports 2008-10-15.00:04:15 zfs set compression=off m/usr/ports/distfiles 2008-10-15.00:13:30 zfs set compression=gzip m/home 2008-10-15.02:08:33 zfs create m/usr/compat 2008-12-11.14:22:22 zfs snapshot m/ar@20081211 2009-01-16.11:19:32 zfs destroy m/ar@20081211 2009-03-30.19:19:07 zpool clear m 2009-04-06.20:59:09 zpool replace m ad6h ad14h 2009-04-07.13:55:42 zpool import -f m Assertion failed: (*), function nvlist_lookup_string(records[i], ZPOOL_HIST_CMD, &cmdstr) == 0, file /usr/src/cddl/sbin/zpool/../../../cddl/contrib/opensolaris/cmd/zpool/zpool_main.c, line 3338. Abort (core dumped) (gdb) bt #0 0x481dfff7 in kill () from /lib/libc.so.7 #1 0x481dff56 in raise () from /lib/libc.so.7 #2 0x481deb8a in abort () from /lib/libc.so.7 #3 0x481c6546 in __assert () from /lib/libc.so.7 #4 0x0804aca7 in get_history_one (zhp=0x4831a100, data=0xbfbfac40) at /usr/src/cddl/sbin/zpool/../../../cddl/contrib/opensolaris/cmd/zpool/zpool_main.c:3337 #5 0x0805293f in pool_list_iter (zlp=0x4830e030, unavail=0, func=0x804ab30 , data=0xbfbfac40) at /usr/src/cddl/sbin/zpool/../../../cddl/contrib/opensolaris/cmd/zpool/zpool_iter.c:165 #6 0x08052bc6 in for_each_pool (argc=0, argv=0xbfbfecc8, unavail=B_FALSE, proplist=0x0, func=0x804ab30 , data=0xbfbfac40) at /usr/src/cddl/sbin/zpool/../../../cddl/contrib/opensolaris/cmd/zpool/zpool_iter.c:239 #7 0x0804a94a in zpool_do_history (argc=0, argv=0xbfbfecc4) at /usr/src/cddl/sbin/zpool/../../../cddl/contrib/opensolaris/cmd/zpool/zpool_main.c:3365 #8 0x0804da4b in main (argc=2, argv=0xbfbfecc0) at /usr/src/cddl/sbin/zpool/../../../cddl/contrib/opensolaris/cmd/zpool/zpool_main.c:3570 -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck@FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From owner-freebsd-stable@FreeBSD.ORG Wed Apr 8 18:24:53 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E5F64106564A for ; Wed, 8 Apr 2009 18:24:53 +0000 (UTC) (envelope-from peter.esselius@gmail.com) Received: from mail-bw0-f164.google.com (mail-bw0-f164.google.com [209.85.218.164]) by mx1.freebsd.org (Postfix) with ESMTP id 6B5FB8FC08 for ; Wed, 8 Apr 2009 18:24:53 +0000 (UTC) (envelope-from peter.esselius@gmail.com) Received: by bwz8 with SMTP id 8so251103bwz.43 for ; Wed, 08 Apr 2009 11:24:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:subject :mime-version:date:references:x-mailer; bh=vyAQY3GN9ojP2G/e0nYTH9dj5sdsEannUjrmHzqp9zU=; b=hIdfDKFPKQL2Ax7UMGt4Huwsv0XXaMoMEF48ebhK8r37UZoGRcL/CUqk2w4rRWV+l3 peQkpDqnO51g6f+ayQJG9Hb8ALwCQEZor0UF8uzDxyxbRaBpvv65a4yoYJmufO1VWfUX 0XVe1LEIUIVyROxwuq7sfcMhjKvn5rntWfHVY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:in-reply-to:content-type :content-transfer-encoding:subject:mime-version:date:references :x-mailer; b=LK3YSmfU+kg/qf9ySrR4lfLFN4rslvMtpV2UvB+cNXYRckFrplrQS/XWPGAobBY+GC h9RR3LEwPy3xBTZ99i0KQCQ879DxDxPA1crmAAmDcW8q4L1+5l18LTUFhPGsxTh/TLV5 D9qBS5CfhIIv3prvSaS44mHvbCW5OESaxOxa0= Received: by 10.103.222.1 with SMTP id z1mr723594muq.121.1239213434804; Wed, 08 Apr 2009 10:57:14 -0700 (PDT) Received: from ?10.0.1.2? (c-06a3e755.023-179-626f721.cust.bredbandsbolaget.se [85.231.163.6]) by mx.google.com with ESMTPS id 12sm13219277muq.5.2009.04.08.10.57.13 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 08 Apr 2009 10:57:14 -0700 (PDT) Message-Id: From: Peter Esselius To: FreeBSD Stable In-Reply-To: <49DCBB21.6050102@icyb.net.ua> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 8 Apr 2009 19:57:12 +0200 References: <49DCBB21.6050102@icyb.net.ua> X-Mailer: Apple Mail (2.930.3) Subject: Re: ZFSKnownProblems - needs revision? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2009 18:24:54 -0000 My home fileserver: Started using zfs around 7.0-BETA2, oct-nov 07. The system is running 7-STABLE@amd64, updated once a month. 4GB RAM No kmem-tuning. 4x320gb, switched to 5x750 during the summer. No panics after switching from i386 to amd64. From owner-freebsd-stable@FreeBSD.ORG Wed Apr 8 19:26:37 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2F5BC10656CF for ; Wed, 8 Apr 2009 19:26:37 +0000 (UTC) (envelope-from piotr.smyrak@heron.pl) Received: from sys.heron.com.pl (mail.heron.pl [89.174.255.19]) by mx1.freebsd.org (Postfix) with ESMTP id 348558FC1F for ; Wed, 8 Apr 2009 19:26:35 +0000 (UTC) (envelope-from piotr.smyrak@heron.pl) Received: from [217.153.67.210] (helo=smyrak.com) by sys.heron.com.pl with esmtpa (Exim 4.69) (envelope-from ) id 1Lrd7z-000E2F-60 for freebsd-stable@freebsd.org; Wed, 08 Apr 2009 21:08:03 +0200 Date: Wed, 8 Apr 2009 21:08:05 +0200 From: Piotr Smyrak To: freebsd-stable@freebsd.org Message-ID: <20090408190805.GA1368@smyrak.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.19 (2009-01-05) Subject: no USB mice detected on GA-MA74GM-S2 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: piotr.smyrak@heron.pl List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2009 19:26:37 -0000 Hi, I recently upgraded my system to newer hardware with motherboard GIGABYTE GA-MA74GM-S2 Rev 1.0 with AMD 740G chipset (north bridge) and AMD SB700 (south) where USB support is located. Everything would be fine except there is no USB mice detection by FreeBSD at all. And I am stuck with USB mise since the mobo has no PS/2 port. First I started with my old build of 6.2, then upgraded to 6.4 STABLE, to finally upgrade to 7.2 PRERELEASE in hope of fixing the issue. None of versions gave me USB mouse support. I have tried connecting 3 various mice. No luck. The only effect I can achieve after connecting a mouse, is a somewhat delayed message on console: "uhub0: device problem (TIMEOUT), disabling port 2" The same mice worked great before changing mobo, and still continue be detected and operational on my laptop (tp x23) running 6.0. I was also able to use a mouse with no problem within Ubuntu LiveCD. I have "device ums" compiled into the kernel. As well as devices uhci, ohci and ehci, ugen and usb, too. usbdevs gives no info on any mouse. Attaching a verbose dmesg from my currently installed 7.2 build. Any help is appreciated. -- dmesg output below -- Copyright (c) 1992-2009 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 7.2-PRERELEASE #4: Sat Apr 4 20:24:14 CEST 2009 root@dsk:/usr/obj/usr/src/sys/SMYRU Preloaded elf kernel "/boot/kernel/kernel" at 0xc08b6000. Preloaded elf module "/boot/kernel/if_dc.ko" at 0xc08b6188. Preloaded elf module "/boot/kernel/miibus.ko" at 0xc08b6234. Preloaded elf module "/boot/kernel/acpi.ko" at 0xc08b62e0. Calibrating clock(s) ... i8254 clock: 1193215 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 2505346537 Hz CPU: AMD Athlon(tm) Dual Core Processor 4850e (2505.35-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x60fb2 Stepping = 2 Features=0x178bfbff Features2=0x2001 AMD Features=0xea500800 AMD Features2=0x11f TSC: P-state invariant Cores per package: 2 Data TLB: 32 entries, fully associative Instruction TLB: 32 entries, fully associative L1 data cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative L1 instruction cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative L2 internal cache: 512 kbytes, 64 bytes/line, 1 lines/tag, 8-way associative real memory = 2079195136 (1982 MB) Physical memory chunk(s): 0x0000000000001000 - 0x000000000009efff, 647168 bytes (158 pages) 0x0000000000100000 - 0x00000000003fffff, 3145728 bytes (768 pages) 0x0000000000c25000 - 0x0000000079baffff, 2029563904 bytes (495499 pages) avail memory = 2029035520 (1935 MB) Table 'FACP' at 0x7bee3040 Table 'SSDT' at 0x7bee73c0 Table 'HPET' at 0x7bee7680 Table 'MCFG' at 0x7bee76c0 Table 'APIC' at 0x7bee7300 MADT: Found table at 0x7bee7300 MP Configuration Table version 1.4 found at 0xc00f0f00 APIC: Using the MADT enumerator. MADT: Found CPU APIC ID 0 ACPI ID 0: enabled SMP: Added CPU 0 (AP) MADT: Found CPU APIC ID 1 ACPI ID 1: enabled SMP: Added CPU 1 (AP) MADT: Found CPU APIC ID 2 ACPI ID 2: disabled MADT: Found CPU APIC ID 3 ACPI ID 3: disabled ACPI APIC Table: INTR: Adding local APIC 1 as a target FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 bios32: Found BIOS32 Service Directory header at 0xc00fb100 bios32: Entry = 0xfb7c0 (c00fb7c0) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xf0000+0xb810 pnpbios: Found PnP BIOS data at 0xc00fc360 pnpbios: Entry = f0000:c390 Rev = 1.0 Other BIOS signatures found: APIC: CPU 0 has ACPI ID 0 APIC: CPU 1 has ACPI ID 1 ULE: setup cpu group 0 ULE: setup cpu 0 ULE: adding cpu 0 to group 0: cpus 1 mask 0x1 ULE: setup cpu group 1 ULE: setup cpu 1 ULE: adding cpu 1 to group 1: cpus 1 mask 0x2 ACPI: RSDP @ 0x0xf7200/0x0014 (v 0 GBT ) ACPI: RSDT @ 0x0x7bee3000/0x0038 (v 1 GBT GBTUACPI 0x42302E31 GBTU 0x01010101) ACPI: FACP @ 0x0x7bee3040/0x0074 (v 1 GBT GBTUACPI 0x42302E31 GBTU 0x01010101) ACPI: DSDT @ 0x0x7bee30c0/0x4222 (v 1 GBT GBTUACPI 0x00001000 MSFT 0x0100000C) ACPI: FACS @ 0x0x7bee0000/0x0040 ACPI: SSDT @ 0x0x7bee73c0/0x028A (v 1 PTLTD POWERNOW 0x00000001 LTP 0x00000001) ACPI: HPET @ 0x0x7bee7680/0x0038 (v 1 GBT GBTUACPI 0x42302E31 GBTU 0x00000098) ACPI: MCFG @ 0x0x7bee76c0/0x003C (v 1 GBT GBTUACPI 0x42302E31 GBTU 0x01010101) ACPI: APIC @ 0x0x7bee7300/0x0084 (v 1 GBT GBTUACPI 0x42302E31 GBTU 0x01010101) MADT: Found IO APIC ID 2, Interrupt 0 at 0xfec00000 ioapic0: Changing APIC ID to 2 ioapic0: Routing external 8259A's -> intpin 0 MADT: Interrupt override: source 0, irq 2 ioapic0: Routing IRQ 0 -> intpin 2 MADT: Interrupt override: source 9, irq 9 ioapic0: intpin 9 trigger: level ioapic0: intpin 9 polarity: low lapic0: Routing NMI -> LINT1 lapic0: LINT1 trigger: edge lapic0: LINT1 polarity: high lapic1: Routing NMI -> LINT1 lapic1: LINT1 trigger: edge lapic1: LINT1 polarity: high MADT: Ignoring local NMI routed to ACPI CPU 2 MADT: Ignoring local NMI routed to ACPI CPU 3 ioapic0 irqs 0-23 on motherboard cpu0 BSP: ID: 0x00000000 VER: 0x80050010 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00010000 err: 0x00010000 pcm: 0x00010000 kbd: new array size 4 kbd1 at kbdmux0 random: VESA: information block 56 45 53 41 00 03 b8 01 00 c0 01 00 00 00 44 00 00 01 00 01 37 0a ef 00 00 c0 81 00 00 c0 88 4c 00 c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 VESA: 51 mode(s) found VESA: v3.0, 16384k memory, flags:0x1, mode table:0xc078c524 (1000044) VESA: ATI ATOMBIOS VESA: (C) 1988-2005, ATI Technologies Inc. RS740 01.00 mem: Pentium Pro MTRR support enabled null: io: npx0: INT 16 interface acpi0: on motherboard ioapic0: routing intpin 9 (ISA IRQ 9) to vector 48 acpi0: [MPSAFE] acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: wakeup code va 0xc4b7c000 pa 0x1000 pci_open(1): mode 1 addr port (0x0cf8) is 0x8000a340 pci_open(1a): mode1res=0x80000000 (0x80000000) pci_cfgcheck: device 0 [class=060000] [hdr=00] is there (id=79111002) pcibios: BIOS version 3.00 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: \\_SB_.PCI0.SATA.SACS -> bus 0 dev 17 func 0 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: \\_SB_.PCI0.BAR1 -> bus 0 dev 0 func 0 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: \\_SB_.PCI0.SMB0.HETT -> bus 0 dev 20 func 0 acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, 7bde0000 (3) failed ACPI timer: 1/2 1/2 1/2 1/2 1/2 1/2 1/2 1/2 1/2 1/2 -> 10 Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <32-bit timer at 3.579545MHz> port 0x4008-0x400b on acpi0 pci_link0: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 6 7 10 11 Validation 0 255 N 0 3 4 5 6 7 10 11 After Disable 0 255 N 0 3 4 5 6 7 10 11 pci_link1: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 6 7 10 11 Validation 0 255 N 0 3 4 5 6 7 10 11 After Disable 0 255 N 0 3 4 5 6 7 10 11 pci_link2: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 6 7 10 11 Validation 0 255 N 0 3 4 5 6 7 10 11 After Disable 0 255 N 0 3 4 5 6 7 10 11 pci_link3: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 6 7 10 11 Validation 0 255 N 0 3 4 5 6 7 10 11 After Disable 0 255 N 0 3 4 5 6 7 10 11 pci_link4: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 6 7 10 11 Validation 0 255 N 0 3 4 5 6 7 10 11 After Disable 0 255 N 0 3 4 5 6 7 10 11 pci_link5: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 6 7 10 11 Validation 0 255 N 0 3 4 5 6 7 10 11 After Disable 0 255 N 0 3 4 5 6 7 10 11 pci_link6: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 6 7 10 11 Validation 0 255 N 0 3 4 5 6 7 10 11 After Disable 0 255 N 0 3 4 5 6 7 10 11 pci_link7: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 6 7 10 11 Validation 0 255 N 0 3 4 5 6 7 10 11 After Disable 0 255 N 0 3 4 5 6 7 10 11 acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 acpi_hpet0: vend: 0x4353 rev: 0x1 num: 3 hz: 14318180 opts: legacy_route Timecounter "HPET" frequency 14318180 Hz quality 900 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: domain=0, physical bus=0 found-> vendor=0x1002, dev=0x7911, revid=0x00 domain=0, bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x2220, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1002, dev=0x7912, revid=0x00 domain=0, bus=0, slot=1, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0007, statreg=0x0230, cachelnsz=0 (dwords) lattimer=0x63 (2970 ns), mingnt=0x08 (2000 ns), maxlat=0x00 (0 ns) found-> vendor=0x1002, dev=0x7916, revid=0x00 domain=0, bus=0, slot=6, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0007, statreg=0x0010, cachelnsz=1 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) powerspec 3 supports D0 D3 current D0 MSI supports 1 message found-> vendor=0x1002, dev=0x4390, revid=0x00 domain=0, bus=0, slot=17, func=0 class=01-01-8f, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0230, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 MSI supports 4 messages, 64 bit map[10]: type I/O Port, range 32, base 0xff00, size 3, enabled map[14]: type I/O Port, range 32, base 0xfe00, size 2, enabled map[18]: type I/O Port, range 32, base 0xfd00, size 3, enabled map[1c]: type I/O Port, range 32, base 0xfc00, size 2, enabled map[20]: type I/O Port, range 32, base 0xfb00, size 4, enabled map[24]: type Memory, range 32, base 0xfe02f000, size 10, enabled pcib0: matched entry for 0.17.INTA pcib0: slot 17 INTA hardwired to IRQ 22 found-> vendor=0x1002, dev=0x4397, revid=0x00 domain=0, bus=0, slot=18, func=0 class=0c-03-10, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x02a0, cachelnsz=1 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=3 map[10]: type Memory, range 32, base 0xfe02e000, size 12, enabled pcib0: matched entry for 0.18.INTA pcib0: slot 18 INTA hardwired to IRQ 16 found-> vendor=0x1002, dev=0x4398, revid=0x00 domain=0, bus=0, slot=18, func=1 class=0c-03-10, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x02a0, cachelnsz=1 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=3 map[10]: type Memory, range 32, base 0xfe02d000, size 12, enabled pcib0: matched entry for 0.18.INTA pcib0: slot 18 INTA hardwired to IRQ 16 found-> vendor=0x1002, dev=0x4396, revid=0x00 domain=0, bus=0, slot=18, func=2 class=0c-03-20, hdrtype=0x00, mfdev=0 cmdreg=0x0002, statreg=0x02b0, cachelnsz=1 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=10 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type Memory, range 32, base 0xfe02c000, size 8, enabled pcib0: matched entry for 0.18.INTB pcib0: slot 18 INTB hardwired to IRQ 17 found-> vendor=0x1002, dev=0x4397, revid=0x00 domain=0, bus=0, slot=19, func=0 class=0c-03-10, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x02a0, cachelnsz=1 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 map[10]: type Memory, range 32, base 0xfe02b000, size 12, enabled pcib0: matched entry for 0.19.INTA pcib0: slot 19 INTA hardwired to IRQ 18 found-> vendor=0x1002, dev=0x4398, revid=0x00 domain=0, bus=0, slot=19, func=1 class=0c-03-10, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x02a0, cachelnsz=1 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 map[10]: type Memory, range 32, base 0xfe02a000, size 12, enabled pcib0: matched entry for 0.19.INTA pcib0: slot 19 INTA hardwired to IRQ 18 found-> vendor=0x1002, dev=0x4396, revid=0x00 domain=0, bus=0, slot=19, func=2 class=0c-03-20, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x02b0, cachelnsz=1 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=11 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type Memory, range 32, base 0xfe029000, size 8, enabled pcib0: matched entry for 0.19.INTB pcib0: slot 19 INTB hardwired to IRQ 19 found-> vendor=0x1002, dev=0x4385, revid=0x3a domain=0, bus=0, slot=20, func=0 class=0c-05-00, hdrtype=0x00, mfdev=1 cmdreg=0x0403, statreg=0x9230, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1002, dev=0x439c, revid=0x00 domain=0, bus=0, slot=20, func=1 class=01-01-8a, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0230, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=255 MSI supports 2 messages map[20]: type I/O Port, range 32, base 0xfa00, size 4, enabled found-> vendor=0x1002, dev=0x4383, revid=0x00 domain=0, bus=0, slot=20, func=2 class=04-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0410, cachelnsz=1 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=3 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 64, base 0xfe024000, size 14, enabled pcib0: matched entry for 0.20.INTA pcib0: slot 20 INTA hardwired to IRQ 16 found-> vendor=0x1002, dev=0x439d, revid=0x00 domain=0, bus=0, slot=20, func=3 class=06-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x000f, statreg=0x0220, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1002, dev=0x4384, revid=0x00 domain=0, bus=0, slot=20, func=4 class=06-04-01, hdrtype=0x01, mfdev=1 cmdreg=0x0027, statreg=0x02a0, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1002, dev=0x4399, revid=0x00 domain=0, bus=0, slot=20, func=5 class=0c-03-10, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x02a0, cachelnsz=1 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=10 map[10]: type Memory, range 32, base 0xfe028000, size 12, enabled pcib0: matched entry for 0.20.INTC pcib0: slot 20 INTC hardwired to IRQ 18 found-> vendor=0x1022, dev=0x1100, revid=0x00 domain=0, bus=0, slot=24, func=0 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1022, dev=0x1101, revid=0x00 domain=0, bus=0, slot=24, func=1 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1022, dev=0x1102, revid=0x00 domain=0, bus=0, slot=24, func=2 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1022, dev=0x1103, revid=0x00 domain=0, bus=0, slot=24, func=3 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) pcib1: at device 1.0 on pci0 pcib1: domain 0 pcib1: secondary bus 1 pcib1: subordinate bus 1 pcib1: I/O decode 0xe000-0xefff pcib1: memory decode 0xfde00000-0xfdffffff pcib1: prefetched decode 0xf8000000-0xfbffffff pci1: on pcib1 pci1: domain=0, physical bus=1 found-> vendor=0x1002, dev=0x796e, revid=0x00 domain=0, bus=1, slot=5, func=0 class=03-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0010, cachelnsz=1 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 2 supports D0 D1 D2 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Prefetchable Memory, range 64, base 0xf8000000, size 26, enabled pcib1: requested memory range 0xf8000000-0xfbffffff: good map[18]: type Memory, range 64, base 0xfdff0000, size 16, enabled pcib1: requested memory range 0xfdff0000-0xfdffffff: good map[20]: type I/O Port, range 32, base 0xee00, size 8, enabled pcib1: requested I/O range 0xee00-0xeeff: in range map[24]: type Memory, range 32, base 0xfde00000, size 20, enabled pcib1: requested memory range 0xfde00000-0xfdefffff: good pcib1: matched entry for 1.5.INTA pcib1: slot 5 INTA hardwired to IRQ 18 vgapci0: port 0xee00-0xeeff mem 0xf8000000-0xfbffffff,0xfdff0000-0xfdffffff,0xfde00000-0xfdefffff irq 18 at device 5.0 on pci1 pcib2: at device 6.0 on pci0 pcib2: domain 0 pcib2: secondary bus 2 pcib2: subordinate bus 2 pcib2: I/O decode 0xd000-0xdfff pcib2: memory decode 0xfdd00000-0xfddfffff pcib2: prefetched decode 0xfda00000-0xfdafffff pci2: on pcib2 pci2: domain=0, physical bus=2 found-> vendor=0x10ec, dev=0x8168, revid=0x02 domain=0, bus=2, slot=0, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0010, cachelnsz=1 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 3 supports D0 D1 D2 D3 current D0 MSI supports 2 messages, 64 bit MSI-X supports 2 messages in map 0x20 map[10]: type I/O Port, range 32, base 0xde00, size 8, enabled pcib2: requested I/O range 0xde00-0xdeff: in range map[18]: type Prefetchable Memory, range 64, base 0xfdaff000, size 12, enabled pcib2: requested memory range 0xfdaff000-0xfdafffff: good map[20]: type Prefetchable Memory, range 64, base 0xfdae0000, size 16, enabled pcib2: requested memory range 0xfdae0000-0xfdaeffff: good pcib2: matched entry for 2.0.INTA pcib2: slot 0 INTA hardwired to IRQ 18 pci2: at device 0.0 (no driver attached) atapci0: port 0xff00-0xff07,0xfe00-0xfe03,0xfd00-0xfd07,0xfc00-0xfc03,0xfb00-0xfb0f mem 0xfe02f000-0xfe02f3ff irq 22 at device 17.0 on pci0 atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0xfb00 atapci0: Reserved 0x400 bytes for rid 0x24 type 3 at 0xfe02f000 ioapic0: routing intpin 22 (PCI IRQ 22) to vector 49 atapci0: [MPSAFE] atapci0: [ITHREAD] atapci0: AHCI Version 01.10 controller with 4 ports detected ata2: on atapci0 ata2: SATA connect time=0ms ata2: SIGNATURE: 00000101 ata2: ahci_reset devices=0x1 ata2: [MPSAFE] ata2: [ITHREAD] ata3: on atapci0 ata3: SATA connect status=00000000 ata3: ahci_reset devices=0x0 ata3: [MPSAFE] ata3: [ITHREAD] ata4: on atapci0 ata4: SATA connect status=00000000 ata4: ahci_reset devices=0x0 ata4: [MPSAFE] ata4: [ITHREAD] ata5: on atapci0 ata5: SATA connect status=00000000 ata5: ahci_reset devices=0x0 ata5: [MPSAFE] ata5: [ITHREAD] ohci0: mem 0xfe02e000-0xfe02efff irq 16 at device 18.0 on pci0 ohci0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xfe02e000 ioapic0: routing intpin 16 (PCI IRQ 16) to vector 50 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: 3 ports with 3 removable, self powered ohci1: mem 0xfe02d000-0xfe02dfff irq 16 at device 18.1 on pci0 ohci1: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xfe02d000 ohci1: [GIANT-LOCKED] ohci1: [ITHREAD] usb1: OHCI version 1.0, legacy support usb1: SMM does not respond, resetting usb1: on ohci1 usb1: USB revision 1.0 uhub1: on usb1 uhub1: 3 ports with 3 removable, self powered ehci0: mem 0xfe02c000-0xfe02c0ff irq 17 at device 18.2 on pci0 ehci0: Reserved 0x100 bytes for rid 0x10 type 3 at 0xfe02c000 ioapic0: routing intpin 17 (PCI IRQ 17) to vector 51 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] ehci0: Dropped interrupts workaround enabled usb2: EHCI version 1.0 usb2: companion controllers, 3 ports each: usb0 usb1 usb2: on ehci0 usb2: USB revision 2.0 uhub2: on usb2 uhub2: 6 ports with 6 removable, self powered ohci2: mem 0xfe02b000-0xfe02bfff irq 18 at device 19.0 on pci0 ohci2: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xfe02b000 ioapic0: routing intpin 18 (PCI IRQ 18) to vector 52 ohci2: [GIANT-LOCKED] ohci2: [ITHREAD] usb3: OHCI version 1.0, legacy support usb3: SMM does not respond, resetting usb3: on ohci2 usb3: USB revision 1.0 uhub3: on usb3 uhub3: 3 ports with 3 removable, self powered ohci3: mem 0xfe02a000-0xfe02afff irq 18 at device 19.1 on pci0 ohci3: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xfe02a000 ohci3: [GIANT-LOCKED] ohci3: [ITHREAD] usb4: OHCI version 1.0, legacy support usb4: SMM does not respond, resetting usb4: on ohci3 usb4: USB revision 1.0 uhub4: on usb4 uhub4: 3 ports with 3 removable, self powered ehci1: mem 0xfe029000-0xfe0290ff irq 19 at device 19.2 on pci0 ehci1: Reserved 0x100 bytes for rid 0x10 type 3 at 0xfe029000 ioapic0: routing intpin 19 (PCI IRQ 19) to vector 53 ehci1: [GIANT-LOCKED] ehci1: [ITHREAD] ehci1: Dropped interrupts workaround enabled usb5: EHCI version 1.0 usb5: companion controllers, 3 ports each: usb3 usb4 usb5: on ehci1 usb5: USB revision 2.0 uhub5: on usb5 uhub5: 6 ports with 6 removable, self powered pci0: at device 20.0 (no driver attached) atapci1: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xfa00-0xfa0f at device 20.1 on pci0 atapci1: Reserved 0x10 bytes for rid 0x20 type 4 at 0xfa00 ata0: on atapci1 atapci1: Reserved 0x8 bytes for rid 0x10 type 4 at 0x1f0 atapci1: Reserved 0x1 bytes for rid 0x14 type 4 at 0x3f6 ata0: reset tp1 mask=03 ostat0=7f ostat1=50 ata0: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f ata0: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f ata0: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f ata0: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f ata0: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f ata0: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f ata0: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f ata0: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f ata0: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f ata0: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f ata0: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f ata0: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f ata0: stat1=0x00 err=0x01 lsb=0x14 msb=0xeb ata0: reset tp2 stat0=ff stat1=00 devices=0x8 ioapic0: routing intpin 14 (ISA IRQ 14) to vector 54 ata0: [MPSAFE] ata0: [ITHREAD] pci0: at device 20.2 (no driver attached) isab0: at device 20.3 on pci0 isa0: on isab0 pcib3: at device 20.4 on pci0 pcib3: domain 0 pcib3: secondary bus 3 pcib3: subordinate bus 3 pcib3: I/O decode 0xc000-0xcfff pcib3: memory decode 0xfdc00000-0xfdcfffff pcib3: prefetched decode 0xfdb00000-0xfdbfffff pcib3: Subtractively decoded bridge. pci3: on pcib3 pci3: domain=0, physical bus=3 found-> vendor=0x1317, dev=0x0985, revid=0x11 domain=0, bus=3, slot=6, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0290, cachelnsz=1 (dwords) lattimer=0x20 (960 ns), mingnt=0x40 (16000 ns), maxlat=0x80 (32000 ns) intpin=a, irq=5 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type I/O Port, range 32, base 0xce00, size 8, enabled pcib3: requested I/O range 0xce00-0xceff: in range map[14]: type Memory, range 32, base 0xfdcff000, size 10, enabled pcib3: requested memory range 0xfdcff000-0xfdcff3ff: good pcib3: matched entry for 3.6.INTA pcib3: slot 6 INTA hardwired to IRQ 20 dc0: port 0xce00-0xceff mem 0xfdcff000-0xfdcff3ff irq 20 at device 6.0 on pci3 dc0: Reserved 0x100 bytes for rid 0x10 type 4 at 0xce00 miibus0: on dc0 ukphy0: PHY 1 on miibus0 ukphy0: OUI 0x000749, model 0x0001, rev. 1 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto dc0: bpf attached dc0: Ethernet address: 00:00:e8:12:73:a7 ioapic0: routing intpin 20 (PCI IRQ 20) to vector 55 dc0: [MPSAFE] dc0: [ITHREAD] ohci4: mem 0xfe028000-0xfe028fff irq 18 at device 20.5 on pci0 ohci4: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xfe028000 ohci4: [GIANT-LOCKED] ohci4: [ITHREAD] usb6: OHCI version 1.0, legacy support usb6: SMM does not respond, resetting usb6: on ohci4 usb6: USB revision 1.0 uhub6: on usb6 uhub6: 2 ports with 2 removable, self powered atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0047 atkbd: keyboard ID 0x41ab (2) kbd0 at atkbd0 kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 ioapic0: routing intpin 1 (ISA IRQ 1) to vector 56 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] cpu0: on acpi0 cpu0: switching to generic Cx mode powernow0: on cpu0 cpu1: on acpi0 powernow1: on cpu1 ata: ata0 already exists; skipping it atkbdc: atkbdc0 already exists; skipping it sc: sc0 already exists; skipping it vga: vga0 already exists; skipping it 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 isa_probe_children: probing non-PnP devices pmtimer0 on isa0 orm0: at iomem 0xc0000-0xcd7ff 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) ata1 failed to probe at port 0x170 irq 15 on isa0 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 0x378 ppc0: using extended I/O port range ppc0: SPP ppc0: at port 0x378-0x37f irq 7 on isa0 ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode ppbus0: on ppc0 ioapic0: routing intpin 7 (ISA IRQ 7) to vector 57 ppbus0: [MPSAFE] ppbus0: [ITHREAD] lpt0: on ppbus0 lpt0: Interrupt-driven port ppc0: [GIANT-LOCKED] ppc0: [ITHREAD] sio0 failed to probe at port 0x3f8 irq 4 on isa0 sio1 failed to probe at port 0x2f8 irq 3 on isa0 sio2: not probed (disabled) sio3: not probed (disabled) sn0: not probed (disabled) vt0: not probed (disabled) isa_probe_children: probing PnP devices Device configuration finished. Reducing kern.maxvnodes 130270 -> 100000 procfs registered lapic: Divisor 2, Frequency 100213866 hz Timecounter "TSC" frequency 2505346537 Hz quality -100 Timecounters tick every 1.000 msec lo0: bpf attached ata0-slave: pio=PIO4 wdma=WDMA2 udma=UDMA40 cable=40 wire acd0: setting PIO4 on IXP700 chip acd0: DMA limited to UDMA33, device found non-ATA66 cable acd0: setting UDMA33 on IXP700 chip acd0: CDRW drive at ata0 as slave acd0: read 4134KB/s (8958KB/s) write 8958KB/s (8958KB/s), 2048KB buffer, UDMA33 acd0: Reads: CDR, CDRW, CDDA stream, DVDROM, DVDR, packet acd0: Writes: CDR, CDRW, test write, burnproof acd0: Audio: play, 255 volume levels acd0: Mechanism: ejectable tray, unlocked acd0: Medium: CD-ROM 120mm data disc ata2-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire ad4: 305244MB at ata2-master SATA300 ad4: 625140335 sectors [620178C/16H/63S] 16 sectors/interrupt 1 depth queue GEOM: new disk ad4 acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 (probe0:ata0:0:1:0): error 22 (probe0:ata0:0:1:0): Unretryable Error (probe0:ata0:0:1:0): Down reving Protocol Version from 2 to 0? acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 (probe0:ata0:0:1:0): error 22 (probe0:ata0:0:1:0): Unretryable Error pass0 at ata0 bus 0 target 1 lun 0 pass0: Removable CD-ROM SCSI-0 device pass0: 33.000MB/s transfers GEOM: new disk cd0 cd0 at ata0 bus 0 target 1 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: 33.000MB/s transfers cd0: cd present [294606 x 2048 byte records] SMP: AP CPU #1 Launched! cpu1 AP: ID: 0x01000000 VER: 0x80050010 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000200ef therm: 0x00010000 err: 0x00010000 pcm: 0x00010000 ioapic0: Assigning ISA IRQ 1 to local APIC 0 ioapic0: Assigning ISA IRQ 7 to local APIC 1 ioapic0: Assigning ISA IRQ 9 to local APIC 0 ioapic0: Assigning ISA IRQ 14 to local APIC 1 ioapic0: Assigning PCI IRQ 16 to local APIC 0 ioapic0: Assigning PCI IRQ 17 to local APIC 1 ioapic0: Assigning PCI IRQ 18 to local APIC 0 ioapic0: Assigning PCI IRQ 19 to local APIC 1 ioapic0: Assigning PCI IRQ 20 to local APIC 0 ioapic0: Assigning PCI IRQ 22 to local APIC 1 scsi_cd.c::ioctl cmd=4400648b error=25 Trying to mount root from ufs:/dev/ad4s2a start_init: trying /sbin/init Linux ELF exec handler installed fuse4bsd: version 0.3.9-pre1, FUSE ABI 7.8 From owner-freebsd-stable@FreeBSD.ORG Wed Apr 8 20:49:00 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 214A51065672 for ; Wed, 8 Apr 2009 20:49:00 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from gizmo.2hip.net (gizmo.2hip.net [64.74.207.195]) by mx1.freebsd.org (Postfix) with ESMTP id C61A68FC17 for ; Wed, 8 Apr 2009 20:48:59 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from [192.168.1.156] (adsl-157-61-189.bna.bellsouth.net [70.157.61.189]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id n38KlbqL051772 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 8 Apr 2009 16:47:37 -0400 (EDT) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: piotr.smyrak@heron.pl In-Reply-To: <20090408190805.GA1368@smyrak.com> References: <20090408190805.GA1368@smyrak.com> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-dJ1DzJyAvHAqj0JuloTq" Organization: FreeBSD Date: Wed, 08 Apr 2009 15:48:04 -0500 Message-Id: <1239223684.4491.12.camel@balrog.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.24.5 FreeBSD GNOME Team Port X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_PBL, RDNS_DYNAMIC autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: freebsd-stable@freebsd.org Subject: Re: no USB mice detected on GA-MA74GM-S2 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2009 20:49:00 -0000 --=-dJ1DzJyAvHAqj0JuloTq Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed, 2009-04-08 at 21:08 +0200, Piotr Smyrak wrote: > Hi, >=20 > I recently upgraded my system to newer hardware with motherboard=20 > GIGABYTE GA-MA74GM-S2 Rev 1.0 with AMD 740G chipset (north bridge)=20 > and AMD SB700 (south) where USB support is located. Everything=20 > would be fine except there is no USB mice detection by FreeBSD at=20 > all. And I am stuck with USB mise since the mobo has no PS/2 port. >=20 > First I started with my old build of 6.2, then upgraded to 6.4=20 > STABLE, to finally upgrade to 7.2 PRERELEASE in hope of fixing the > issue. None of versions gave me USB mouse support. I have tried=20 > connecting 3 various mice. No luck. The only effect I can achieve=20 > after connecting a mouse, is a somewhat delayed message on console: rebuild/reinstall devel/libpciaccess now that you have updated kernel. robert. > "uhub0: device problem (TIMEOUT), disabling port 2" >=20 > The same mice worked great before changing mobo, and still continue=20 > be detected and operational on my laptop (tp x23) running 6.0. I was=20 > also able to use a mouse with no problem within Ubuntu LiveCD. >=20 > I have "device ums" compiled into the kernel. As well as devices uhci, > ohci and ehci, ugen and usb, too. usbdevs gives no info on any mouse. > Attaching a verbose dmesg from my currently installed 7.2 build. >=20 > Any help is appreciated.=20 >=20 > -- dmesg output below --=20 >=20 > Copyright (c) 1992-2009 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 7.2-PRERELEASE #4: Sat Apr 4 20:24:14 CEST 2009 > root@dsk:/usr/obj/usr/src/sys/SMYRU > Preloaded elf kernel "/boot/kernel/kernel" at 0xc08b6000. > Preloaded elf module "/boot/kernel/if_dc.ko" at 0xc08b6188. > Preloaded elf module "/boot/kernel/miibus.ko" at 0xc08b6234. > Preloaded elf module "/boot/kernel/acpi.ko" at 0xc08b62e0. > Calibrating clock(s) ... i8254 clock: 1193215 Hz > CLK_USE_I8254_CALIBRATION not specified - using default frequency > Timecounter "i8254" frequency 1193182 Hz quality 0 > Calibrating TSC clock ... TSC clock: 2505346537 Hz > CPU: AMD Athlon(tm) Dual Core Processor 4850e (2505.35-MHz 686-class CPU) > Origin =3D "AuthenticAMD" Id =3D 0x60fb2 Stepping =3D 2 > Features=3D0x178bfbff > Features2=3D0x2001 > AMD Features=3D0xea500800 > AMD Features2=3D0x11f > TSC: P-state invariant > Cores per package: 2 > Data TLB: 32 entries, fully associative > Instruction TLB: 32 entries, fully associative > L1 data cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative > L1 instruction cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associ= ative > L2 internal cache: 512 kbytes, 64 bytes/line, 1 lines/tag, 8-way associat= ive > real memory =3D 2079195136 (1982 MB) > Physical memory chunk(s): > 0x0000000000001000 - 0x000000000009efff, 647168 bytes (158 pages) > 0x0000000000100000 - 0x00000000003fffff, 3145728 bytes (768 pages) > 0x0000000000c25000 - 0x0000000079baffff, 2029563904 bytes (495499 pages) > avail memory =3D 2029035520 (1935 MB) > Table 'FACP' at 0x7bee3040 > Table 'SSDT' at 0x7bee73c0 > Table 'HPET' at 0x7bee7680 > Table 'MCFG' at 0x7bee76c0 > Table 'APIC' at 0x7bee7300 > MADT: Found table at 0x7bee7300 > MP Configuration Table version 1.4 found at 0xc00f0f00 > APIC: Using the MADT enumerator. > MADT: Found CPU APIC ID 0 ACPI ID 0: enabled > SMP: Added CPU 0 (AP) > MADT: Found CPU APIC ID 1 ACPI ID 1: enabled > SMP: Added CPU 1 (AP) > MADT: Found CPU APIC ID 2 ACPI ID 2: disabled > MADT: Found CPU APIC ID 3 ACPI ID 3: disabled > ACPI APIC Table: > INTR: Adding local APIC 1 as a target > FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs > cpu0 (BSP): APIC ID: 0 > cpu1 (AP): APIC ID: 1 > bios32: Found BIOS32 Service Directory header at 0xc00fb100 > bios32: Entry =3D 0xfb7c0 (c00fb7c0) Rev =3D 0 Len =3D 1 > pcibios: PCI BIOS entry at 0xf0000+0xb810 > pnpbios: Found PnP BIOS data at 0xc00fc360 > pnpbios: Entry =3D f0000:c390 Rev =3D 1.0 > Other BIOS signatures found: > APIC: CPU 0 has ACPI ID 0 > APIC: CPU 1 has ACPI ID 1 > ULE: setup cpu group 0 > ULE: setup cpu 0 > ULE: adding cpu 0 to group 0: cpus 1 mask 0x1 > ULE: setup cpu group 1 > ULE: setup cpu 1 > ULE: adding cpu 1 to group 1: cpus 1 mask 0x2 > ACPI: RSDP @ 0x0xf7200/0x0014 (v 0 GBT ) > ACPI: RSDT @ 0x0x7bee3000/0x0038 (v 1 GBT GBTUACPI 0x42302E31 GBTU 0x= 01010101) > ACPI: FACP @ 0x0x7bee3040/0x0074 (v 1 GBT GBTUACPI 0x42302E31 GBTU 0x= 01010101) > ACPI: DSDT @ 0x0x7bee30c0/0x4222 (v 1 GBT GBTUACPI 0x00001000 MSFT 0x= 0100000C) > ACPI: FACS @ 0x0x7bee0000/0x0040 > ACPI: SSDT @ 0x0x7bee73c0/0x028A (v 1 PTLTD POWERNOW 0x00000001 LTP 0x= 00000001) > ACPI: HPET @ 0x0x7bee7680/0x0038 (v 1 GBT GBTUACPI 0x42302E31 GBTU 0x= 00000098) > ACPI: MCFG @ 0x0x7bee76c0/0x003C (v 1 GBT GBTUACPI 0x42302E31 GBTU 0x= 01010101) > ACPI: APIC @ 0x0x7bee7300/0x0084 (v 1 GBT GBTUACPI 0x42302E31 GBTU 0x= 01010101) > MADT: Found IO APIC ID 2, Interrupt 0 at 0xfec00000 > ioapic0: Changing APIC ID to 2 > ioapic0: Routing external 8259A's -> intpin 0 > MADT: Interrupt override: source 0, irq 2 > ioapic0: Routing IRQ 0 -> intpin 2 > MADT: Interrupt override: source 9, irq 9 > ioapic0: intpin 9 trigger: level > ioapic0: intpin 9 polarity: low > lapic0: Routing NMI -> LINT1 > lapic0: LINT1 trigger: edge > lapic0: LINT1 polarity: high > lapic1: Routing NMI -> LINT1 > lapic1: LINT1 trigger: edge > lapic1: LINT1 polarity: high > MADT: Ignoring local NMI routed to ACPI CPU 2 > MADT: Ignoring local NMI routed to ACPI CPU 3 > ioapic0 irqs 0-23 on motherboard > cpu0 BSP: > ID: 0x00000000 VER: 0x80050010 LDR: 0x00000000 DFR: 0xffffffff > lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff > timer: 0x000100ef therm: 0x00010000 err: 0x00010000 pcm: 0x00010000 > kbd: new array size 4 > kbd1 at kbdmux0 > random: > VESA: information block > 56 45 53 41 00 03 b8 01 00 c0 01 00 00 00 44 00=20 > 00 01 00 01 37 0a ef 00 00 c0 81 00 00 c0 88 4c=20 > 00 c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00=20 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00=20 > VESA: 51 mode(s) found > VESA: v3.0, 16384k memory, flags:0x1, mode table:0xc078c524 (1000044) > VESA: ATI ATOMBIOS > VESA: (C) 1988-2005, ATI Technologies Inc. RS740 01.00 > mem: > Pentium Pro MTRR support enabled > null: > io: > npx0: INT 16 interface > acpi0: on motherboard > ioapic0: routing intpin 9 (ISA IRQ 9) to vector 48 > acpi0: [MPSAFE] > acpi0: [ITHREAD] > acpi0: Power Button (fixed) > acpi0: wakeup code va 0xc4b7c000 pa 0x1000 > pci_open(1): mode 1 addr port (0x0cf8) is 0x8000a340 > pci_open(1a): mode1res=3D0x80000000 (0x80000000) > pci_cfgcheck: device 0 [class=3D060000] [hdr=3D00] is there (id=3D7911100= 2) > pcibios: BIOS version 3.00 > acpi_bus_number: root bus has no _BBN, assuming 0 > AcpiOsDerivePciId: \\_SB_.PCI0.SATA.SACS -> bus 0 dev 17 func 0 > acpi_bus_number: root bus has no _BBN, assuming 0 > AcpiOsDerivePciId: \\_SB_.PCI0.BAR1 -> bus 0 dev 0 func 0 > acpi_bus_number: root bus has no _BBN, assuming 0 > AcpiOsDerivePciId: \\_SB_.PCI0.SMB0.HETT -> bus 0 dev 20 func 0 > acpi0: reservation of 0, a0000 (3) failed > acpi0: reservation of 100000, 7bde0000 (3) failed > ACPI timer: 1/2 1/2 1/2 1/2 1/2 1/2 1/2 1/2 1/2 1/2 -> 10 > Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 > acpi_timer0: <32-bit timer at 3.579545MHz> port 0x4008-0x400b on acpi0 > pci_link0: Index IRQ Rtd Ref IRQs > Initial Probe 0 255 N 0 3 4 5 6 7 10 11 > Validation 0 255 N 0 3 4 5 6 7 10 11 > After Disable 0 255 N 0 3 4 5 6 7 10 11 > pci_link1: Index IRQ Rtd Ref IRQs > Initial Probe 0 255 N 0 3 4 5 6 7 10 11 > Validation 0 255 N 0 3 4 5 6 7 10 11 > After Disable 0 255 N 0 3 4 5 6 7 10 11 > pci_link2: Index IRQ Rtd Ref IRQs > Initial Probe 0 255 N 0 3 4 5 6 7 10 11 > Validation 0 255 N 0 3 4 5 6 7 10 11 > After Disable 0 255 N 0 3 4 5 6 7 10 11 > pci_link3: Index IRQ Rtd Ref IRQs > Initial Probe 0 255 N 0 3 4 5 6 7 10 11 > Validation 0 255 N 0 3 4 5 6 7 10 11 > After Disable 0 255 N 0 3 4 5 6 7 10 11 > pci_link4: Index IRQ Rtd Ref IRQs > Initial Probe 0 255 N 0 3 4 5 6 7 10 11 > Validation 0 255 N 0 3 4 5 6 7 10 11 > After Disable 0 255 N 0 3 4 5 6 7 10 11 > pci_link5: Index IRQ Rtd Ref IRQs > Initial Probe 0 255 N 0 3 4 5 6 7 10 11 > Validation 0 255 N 0 3 4 5 6 7 10 11 > After Disable 0 255 N 0 3 4 5 6 7 10 11 > pci_link6: Index IRQ Rtd Ref IRQs > Initial Probe 0 255 N 0 3 4 5 6 7 10 11 > Validation 0 255 N 0 3 4 5 6 7 10 11 > After Disable 0 255 N 0 3 4 5 6 7 10 11 > pci_link7: Index IRQ Rtd Ref IRQs > Initial Probe 0 255 N 0 3 4 5 6 7 10 11 > Validation 0 255 N 0 3 4 5 6 7 10 11 > After Disable 0 255 N 0 3 4 5 6 7 10 11 > acpi_hpet0: iomem 0xfed00000-0xfed003ff on a= cpi0 > acpi_hpet0: vend: 0x4353 rev: 0x1 num: 3 hz: 14318180 opts: legacy_route > Timecounter "HPET" frequency 14318180 Hz quality 900 > acpi_button0: on acpi0 > pcib0: port 0xcf8-0xcff on acpi0 > pci0: on pcib0 > pci0: domain=3D0, physical bus=3D0 > found-> vendor=3D0x1002, dev=3D0x7911, revid=3D0x00 > domain=3D0, bus=3D0, slot=3D0, func=3D0 > class=3D06-00-00, hdrtype=3D0x00, mfdev=3D0 > cmdreg=3D0x0006, statreg=3D0x2220, cachelnsz=3D0 (dwords) > lattimer=3D0x20 (960 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) > found-> vendor=3D0x1002, dev=3D0x7912, revid=3D0x00 > domain=3D0, bus=3D0, slot=3D1, func=3D0 > class=3D06-04-00, hdrtype=3D0x01, mfdev=3D0 > cmdreg=3D0x0007, statreg=3D0x0230, cachelnsz=3D0 (dwords) > lattimer=3D0x63 (2970 ns), mingnt=3D0x08 (2000 ns), maxlat=3D0x00 (0 ns) > found-> vendor=3D0x1002, dev=3D0x7916, revid=3D0x00 > domain=3D0, bus=3D0, slot=3D6, func=3D0 > class=3D06-04-00, hdrtype=3D0x01, mfdev=3D0 > cmdreg=3D0x0007, statreg=3D0x0010, cachelnsz=3D1 (dwords) > lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) > powerspec 3 supports D0 D3 current D0 > MSI supports 1 message > found-> vendor=3D0x1002, dev=3D0x4390, revid=3D0x00 > domain=3D0, bus=3D0, slot=3D17, func=3D0 > class=3D01-01-8f, hdrtype=3D0x00, mfdev=3D0 > cmdreg=3D0x0007, statreg=3D0x0230, cachelnsz=3D0 (dwords) > lattimer=3D0x20 (960 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) > intpin=3Da, irq=3D11 > powerspec 2 supports D0 D3 current D0 > MSI supports 4 messages, 64 bit > map[10]: type I/O Port, range 32, base 0xff00, size 3, enabled > map[14]: type I/O Port, range 32, base 0xfe00, size 2, enabled > map[18]: type I/O Port, range 32, base 0xfd00, size 3, enabled > map[1c]: type I/O Port, range 32, base 0xfc00, size 2, enabled > map[20]: type I/O Port, range 32, base 0xfb00, size 4, enabled > map[24]: type Memory, range 32, base 0xfe02f000, size 10, enabled > pcib0: matched entry for 0.17.INTA > pcib0: slot 17 INTA hardwired to IRQ 22 > found-> vendor=3D0x1002, dev=3D0x4397, revid=3D0x00 > domain=3D0, bus=3D0, slot=3D18, func=3D0 > class=3D0c-03-10, hdrtype=3D0x00, mfdev=3D1 > cmdreg=3D0x0007, statreg=3D0x02a0, cachelnsz=3D1 (dwords) > lattimer=3D0x20 (960 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) > intpin=3Da, irq=3D3 > map[10]: type Memory, range 32, base 0xfe02e000, size 12, enabled > pcib0: matched entry for 0.18.INTA > pcib0: slot 18 INTA hardwired to IRQ 16 > found-> vendor=3D0x1002, dev=3D0x4398, revid=3D0x00 > domain=3D0, bus=3D0, slot=3D18, func=3D1 > class=3D0c-03-10, hdrtype=3D0x00, mfdev=3D0 > cmdreg=3D0x0007, statreg=3D0x02a0, cachelnsz=3D1 (dwords) > lattimer=3D0x20 (960 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) > intpin=3Da, irq=3D3 > map[10]: type Memory, range 32, base 0xfe02d000, size 12, enabled > pcib0: matched entry for 0.18.INTA > pcib0: slot 18 INTA hardwired to IRQ 16 > found-> vendor=3D0x1002, dev=3D0x4396, revid=3D0x00 > domain=3D0, bus=3D0, slot=3D18, func=3D2 > class=3D0c-03-20, hdrtype=3D0x00, mfdev=3D0 > cmdreg=3D0x0002, statreg=3D0x02b0, cachelnsz=3D1 (dwords) > lattimer=3D0x20 (960 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) > intpin=3Db, irq=3D10 > powerspec 2 supports D0 D1 D2 D3 current D0 > map[10]: type Memory, range 32, base 0xfe02c000, size 8, enabled > pcib0: matched entry for 0.18.INTB > pcib0: slot 18 INTB hardwired to IRQ 17 > found-> vendor=3D0x1002, dev=3D0x4397, revid=3D0x00 > domain=3D0, bus=3D0, slot=3D19, func=3D0 > class=3D0c-03-10, hdrtype=3D0x00, mfdev=3D1 > cmdreg=3D0x0007, statreg=3D0x02a0, cachelnsz=3D1 (dwords) > lattimer=3D0x20 (960 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) > intpin=3Da, irq=3D10 > map[10]: type Memory, range 32, base 0xfe02b000, size 12, enabled > pcib0: matched entry for 0.19.INTA > pcib0: slot 19 INTA hardwired to IRQ 18 > found-> vendor=3D0x1002, dev=3D0x4398, revid=3D0x00 > domain=3D0, bus=3D0, slot=3D19, func=3D1 > class=3D0c-03-10, hdrtype=3D0x00, mfdev=3D0 > cmdreg=3D0x0007, statreg=3D0x02a0, cachelnsz=3D1 (dwords) > lattimer=3D0x20 (960 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) > intpin=3Da, irq=3D10 > map[10]: type Memory, range 32, base 0xfe02a000, size 12, enabled > pcib0: matched entry for 0.19.INTA > pcib0: slot 19 INTA hardwired to IRQ 18 > found-> vendor=3D0x1002, dev=3D0x4396, revid=3D0x00 > domain=3D0, bus=3D0, slot=3D19, func=3D2 > class=3D0c-03-20, hdrtype=3D0x00, mfdev=3D0 > cmdreg=3D0x0006, statreg=3D0x02b0, cachelnsz=3D1 (dwords) > lattimer=3D0x20 (960 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) > intpin=3Db, irq=3D11 > powerspec 2 supports D0 D1 D2 D3 current D0 > map[10]: type Memory, range 32, base 0xfe029000, size 8, enabled > pcib0: matched entry for 0.19.INTB > pcib0: slot 19 INTB hardwired to IRQ 19 > found-> vendor=3D0x1002, dev=3D0x4385, revid=3D0x3a > domain=3D0, bus=3D0, slot=3D20, func=3D0 > class=3D0c-05-00, hdrtype=3D0x00, mfdev=3D1 > cmdreg=3D0x0403, statreg=3D0x9230, cachelnsz=3D0 (dwords) > lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) > found-> vendor=3D0x1002, dev=3D0x439c, revid=3D0x00 > domain=3D0, bus=3D0, slot=3D20, func=3D1 > class=3D01-01-8a, hdrtype=3D0x00, mfdev=3D0 > cmdreg=3D0x0005, statreg=3D0x0230, cachelnsz=3D0 (dwords) > lattimer=3D0x20 (960 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) > intpin=3Da, irq=3D255 > MSI supports 2 messages > map[20]: type I/O Port, range 32, base 0xfa00, size 4, enabled > found-> vendor=3D0x1002, dev=3D0x4383, revid=3D0x00 > domain=3D0, bus=3D0, slot=3D20, func=3D2 > class=3D04-03-00, hdrtype=3D0x00, mfdev=3D0 > cmdreg=3D0x0006, statreg=3D0x0410, cachelnsz=3D1 (dwords) > lattimer=3D0x20 (960 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) > intpin=3Da, irq=3D3 > powerspec 2 supports D0 D3 current D0 > map[10]: type Memory, range 64, base 0xfe024000, size 14, enabled > pcib0: matched entry for 0.20.INTA > pcib0: slot 20 INTA hardwired to IRQ 16 > found-> vendor=3D0x1002, dev=3D0x439d, revid=3D0x00 > domain=3D0, bus=3D0, slot=3D20, func=3D3 > class=3D06-01-00, hdrtype=3D0x00, mfdev=3D1 > cmdreg=3D0x000f, statreg=3D0x0220, cachelnsz=3D0 (dwords) > lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) > found-> vendor=3D0x1002, dev=3D0x4384, revid=3D0x00 > domain=3D0, bus=3D0, slot=3D20, func=3D4 > class=3D06-04-01, hdrtype=3D0x01, mfdev=3D1 > cmdreg=3D0x0027, statreg=3D0x02a0, cachelnsz=3D0 (dwords) > lattimer=3D0x40 (1920 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) > found-> vendor=3D0x1002, dev=3D0x4399, revid=3D0x00 > domain=3D0, bus=3D0, slot=3D20, func=3D5 > class=3D0c-03-10, hdrtype=3D0x00, mfdev=3D0 > cmdreg=3D0x0007, statreg=3D0x02a0, cachelnsz=3D1 (dwords) > lattimer=3D0x20 (960 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) > intpin=3Dc, irq=3D10 > map[10]: type Memory, range 32, base 0xfe028000, size 12, enabled > pcib0: matched entry for 0.20.INTC > pcib0: slot 20 INTC hardwired to IRQ 18 > found-> vendor=3D0x1022, dev=3D0x1100, revid=3D0x00 > domain=3D0, bus=3D0, slot=3D24, func=3D0 > class=3D06-00-00, hdrtype=3D0x00, mfdev=3D1 > cmdreg=3D0x0000, statreg=3D0x0010, cachelnsz=3D0 (dwords) > lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) > found-> vendor=3D0x1022, dev=3D0x1101, revid=3D0x00 > domain=3D0, bus=3D0, slot=3D24, func=3D1 > class=3D06-00-00, hdrtype=3D0x00, mfdev=3D1 > cmdreg=3D0x0000, statreg=3D0x0000, cachelnsz=3D0 (dwords) > lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) > found-> vendor=3D0x1022, dev=3D0x1102, revid=3D0x00 > domain=3D0, bus=3D0, slot=3D24, func=3D2 > class=3D06-00-00, hdrtype=3D0x00, mfdev=3D1 > cmdreg=3D0x0000, statreg=3D0x0000, cachelnsz=3D0 (dwords) > lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) > found-> vendor=3D0x1022, dev=3D0x1103, revid=3D0x00 > domain=3D0, bus=3D0, slot=3D24, func=3D3 > class=3D06-00-00, hdrtype=3D0x00, mfdev=3D1 > cmdreg=3D0x0000, statreg=3D0x0010, cachelnsz=3D0 (dwords) > lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) > pcib1: at device 1.0 on pci0 > pcib1: domain 0 > pcib1: secondary bus 1 > pcib1: subordinate bus 1 > pcib1: I/O decode 0xe000-0xefff > pcib1: memory decode 0xfde00000-0xfdffffff > pcib1: prefetched decode 0xf8000000-0xfbffffff > pci1: on pcib1 > pci1: domain=3D0, physical bus=3D1 > found-> vendor=3D0x1002, dev=3D0x796e, revid=3D0x00 > domain=3D0, bus=3D1, slot=3D5, func=3D0 > class=3D03-00-00, hdrtype=3D0x00, mfdev=3D0 > cmdreg=3D0x0007, statreg=3D0x0010, cachelnsz=3D1 (dwords) > lattimer=3D0x20 (960 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) > intpin=3Da, irq=3D10 > powerspec 2 supports D0 D1 D2 D3 current D0 > MSI supports 1 message, 64 bit > map[10]: type Prefetchable Memory, range 64, base 0xf8000000, size 26, e= nabled > pcib1: requested memory range 0xf8000000-0xfbffffff: good > map[18]: type Memory, range 64, base 0xfdff0000, size 16, enabled > pcib1: requested memory range 0xfdff0000-0xfdffffff: good > map[20]: type I/O Port, range 32, base 0xee00, size 8, enabled > pcib1: requested I/O range 0xee00-0xeeff: in range > map[24]: type Memory, range 32, base 0xfde00000, size 20, enabled > pcib1: requested memory range 0xfde00000-0xfdefffff: good > pcib1: matched entry for 1.5.INTA > pcib1: slot 5 INTA hardwired to IRQ 18 > vgapci0: port 0xee00-0xeeff mem 0xf8000000-0xfbf= fffff,0xfdff0000-0xfdffffff,0xfde00000-0xfdefffff irq 18 at device 5.0 on p= ci1 > pcib2: at device 6.0 on pci0 > pcib2: domain 0 > pcib2: secondary bus 2 > pcib2: subordinate bus 2 > pcib2: I/O decode 0xd000-0xdfff > pcib2: memory decode 0xfdd00000-0xfddfffff > pcib2: prefetched decode 0xfda00000-0xfdafffff > pci2: on pcib2 > pci2: domain=3D0, physical bus=3D2 > found-> vendor=3D0x10ec, dev=3D0x8168, revid=3D0x02 > domain=3D0, bus=3D2, slot=3D0, func=3D0 > class=3D02-00-00, hdrtype=3D0x00, mfdev=3D0 > cmdreg=3D0x0007, statreg=3D0x0010, cachelnsz=3D1 (dwords) > lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) > intpin=3Da, irq=3D10 > powerspec 3 supports D0 D1 D2 D3 current D0 > MSI supports 2 messages, 64 bit > MSI-X supports 2 messages in map 0x20 > map[10]: type I/O Port, range 32, base 0xde00, size 8, enabled > pcib2: requested I/O range 0xde00-0xdeff: in range > map[18]: type Prefetchable Memory, range 64, base 0xfdaff000, size 12, e= nabled > pcib2: requested memory range 0xfdaff000-0xfdafffff: good > map[20]: type Prefetchable Memory, range 64, base 0xfdae0000, size 16, e= nabled > pcib2: requested memory range 0xfdae0000-0xfdaeffff: good > pcib2: matched entry for 2.0.INTA > pcib2: slot 0 INTA hardwired to IRQ 18 > pci2: at device 0.0 (no driver attached) > atapci0: port 0xff00-0xff07,0xfe00-0xfe03= ,0xfd00-0xfd07,0xfc00-0xfc03,0xfb00-0xfb0f mem 0xfe02f000-0xfe02f3ff irq 22= at device 17.0 on pci0 > atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0xfb00 > atapci0: Reserved 0x400 bytes for rid 0x24 type 3 at 0xfe02f000 > ioapic0: routing intpin 22 (PCI IRQ 22) to vector 49 > atapci0: [MPSAFE] > atapci0: [ITHREAD] > atapci0: AHCI Version 01.10 controller with 4 ports detected > ata2: on atapci0 > ata2: SATA connect time=3D0ms > ata2: SIGNATURE: 00000101 > ata2: ahci_reset devices=3D0x1 > ata2: [MPSAFE] > ata2: [ITHREAD] > ata3: on atapci0 > ata3: SATA connect status=3D00000000 > ata3: ahci_reset devices=3D0x0 > ata3: [MPSAFE] > ata3: [ITHREAD] > ata4: on atapci0 > ata4: SATA connect status=3D00000000 > ata4: ahci_reset devices=3D0x0 > ata4: [MPSAFE] > ata4: [ITHREAD] > ata5: on atapci0 > ata5: SATA connect status=3D00000000 > ata5: ahci_reset devices=3D0x0 > ata5: [MPSAFE] > ata5: [ITHREAD] > ohci0: mem 0xfe02e000-0xfe02efff irq 16 a= t device 18.0 on pci0 > ohci0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xfe02e000 > ioapic0: routing intpin 16 (PCI IRQ 16) to vector 50 > 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: 3 ports with 3 removable, self powered > ohci1: mem 0xfe02d000-0xfe02dfff irq 16 a= t device 18.1 on pci0 > ohci1: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xfe02d000 > ohci1: [GIANT-LOCKED] > ohci1: [ITHREAD] > usb1: OHCI version 1.0, legacy support > usb1: SMM does not respond, resetting > usb1: on ohci1 > usb1: USB revision 1.0 > uhub1: on usb1 > uhub1: 3 ports with 3 removable, self powered > ehci0: mem 0xfe02c000-0xfe02c0ff irq = 17 at device 18.2 on pci0 > ehci0: Reserved 0x100 bytes for rid 0x10 type 3 at 0xfe02c000 > ioapic0: routing intpin 17 (PCI IRQ 17) to vector 51 > ehci0: [GIANT-LOCKED] > ehci0: [ITHREAD] > ehci0: Dropped interrupts workaround enabled > usb2: EHCI version 1.0 > usb2: companion controllers, 3 ports each: usb0 usb1 > usb2: on ehci0 > usb2: USB revision 2.0 > uhub2: on usb2 > uhub2: 6 ports with 6 removable, self powered > ohci2: mem 0xfe02b000-0xfe02bfff irq 18 a= t device 19.0 on pci0 > ohci2: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xfe02b000 > ioapic0: routing intpin 18 (PCI IRQ 18) to vector 52 > ohci2: [GIANT-LOCKED] > ohci2: [ITHREAD] > usb3: OHCI version 1.0, legacy support > usb3: SMM does not respond, resetting > usb3: on ohci2 > usb3: USB revision 1.0 > uhub3: on usb3 > uhub3: 3 ports with 3 removable, self powered > ohci3: mem 0xfe02a000-0xfe02afff irq 18 a= t device 19.1 on pci0 > ohci3: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xfe02a000 > ohci3: [GIANT-LOCKED] > ohci3: [ITHREAD] > usb4: OHCI version 1.0, legacy support > usb4: SMM does not respond, resetting > usb4: on ohci3 > usb4: USB revision 1.0 > uhub4: on usb4 > uhub4: 3 ports with 3 removable, self powered > ehci1: mem 0xfe029000-0xfe0290ff irq = 19 at device 19.2 on pci0 > ehci1: Reserved 0x100 bytes for rid 0x10 type 3 at 0xfe029000 > ioapic0: routing intpin 19 (PCI IRQ 19) to vector 53 > ehci1: [GIANT-LOCKED] > ehci1: [ITHREAD] > ehci1: Dropped interrupts workaround enabled > usb5: EHCI version 1.0 > usb5: companion controllers, 3 ports each: usb3 usb4 > usb5: on ehci1 > usb5: USB revision 2.0 > uhub5: on usb5 > uhub5: 6 ports with 6 removable, self powered > pci0: at device 20.0 (no driver attached) > atapci1: port 0x1f0-0x1f7,0x3f6,0x170-0x1= 77,0x376,0xfa00-0xfa0f at device 20.1 on pci0 > atapci1: Reserved 0x10 bytes for rid 0x20 type 4 at 0xfa00 > ata0: on atapci1 > atapci1: Reserved 0x8 bytes for rid 0x10 type 4 at 0x1f0 > atapci1: Reserved 0x1 bytes for rid 0x14 type 4 at 0x3f6 > ata0: reset tp1 mask=3D03 ostat0=3D7f ostat1=3D50 > ata0: stat0=3D0x7f err=3D0x7f lsb=3D0x7f msb=3D0x7f > ata0: stat0=3D0x7f err=3D0x7f lsb=3D0x7f msb=3D0x7f > ata0: stat0=3D0x7f err=3D0x7f lsb=3D0x7f msb=3D0x7f > ata0: stat0=3D0x7f err=3D0x7f lsb=3D0x7f msb=3D0x7f > ata0: stat0=3D0x7f err=3D0x7f lsb=3D0x7f msb=3D0x7f > ata0: stat0=3D0x7f err=3D0x7f lsb=3D0x7f msb=3D0x7f > ata0: stat0=3D0x7f err=3D0x7f lsb=3D0x7f msb=3D0x7f > ata0: stat0=3D0x7f err=3D0x7f lsb=3D0x7f msb=3D0x7f > ata0: stat0=3D0x7f err=3D0x7f lsb=3D0x7f msb=3D0x7f > ata0: stat0=3D0x7f err=3D0x7f lsb=3D0x7f msb=3D0x7f > ata0: stat0=3D0x7f err=3D0x7f lsb=3D0x7f msb=3D0x7f > ata0: stat0=3D0x7f err=3D0x7f lsb=3D0x7f msb=3D0x7f > ata0: stat1=3D0x00 err=3D0x01 lsb=3D0x14 msb=3D0xeb > ata0: reset tp2 stat0=3Dff stat1=3D00 devices=3D0x8 > ioapic0: routing intpin 14 (ISA IRQ 14) to vector 54 > ata0: [MPSAFE] > ata0: [ITHREAD] > pci0: at device 20.2 (no driver attached) > isab0: at device 20.3 on pci0 > isa0: on isab0 > pcib3: at device 20.4 on pci0 > pcib3: domain 0 > pcib3: secondary bus 3 > pcib3: subordinate bus 3 > pcib3: I/O decode 0xc000-0xcfff > pcib3: memory decode 0xfdc00000-0xfdcfffff > pcib3: prefetched decode 0xfdb00000-0xfdbfffff > pcib3: Subtractively decoded bridge. > pci3: on pcib3 > pci3: domain=3D0, physical bus=3D3 > found-> vendor=3D0x1317, dev=3D0x0985, revid=3D0x11 > domain=3D0, bus=3D3, slot=3D6, func=3D0 > class=3D02-00-00, hdrtype=3D0x00, mfdev=3D0 > cmdreg=3D0x0007, statreg=3D0x0290, cachelnsz=3D1 (dwords) > lattimer=3D0x20 (960 ns), mingnt=3D0x40 (16000 ns), maxlat=3D0x80 (32000= ns) > intpin=3Da, irq=3D5 > powerspec 2 supports D0 D1 D2 D3 current D0 > map[10]: type I/O Port, range 32, base 0xce00, size 8, enabled > pcib3: requested I/O range 0xce00-0xceff: in range > map[14]: type Memory, range 32, base 0xfdcff000, size 10, enabled > pcib3: requested memory range 0xfdcff000-0xfdcff3ff: good > pcib3: matched entry for 3.6.INTA > pcib3: slot 6 INTA hardwired to IRQ 20 > dc0: port 0xce00-0xceff mem 0xfdcff000-0xfdcf= f3ff irq 20 at device 6.0 on pci3 > dc0: Reserved 0x100 bytes for rid 0x10 type 4 at 0xce00 > miibus0: on dc0 > ukphy0: PHY 1 on miibus0 > ukphy0: OUI 0x000749, model 0x0001, rev. 1 > ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > dc0: bpf attached > dc0: Ethernet address: 00:00:e8:12:73:a7 > ioapic0: routing intpin 20 (PCI IRQ 20) to vector 55 > dc0: [MPSAFE] > dc0: [ITHREAD] > ohci4: mem 0xfe028000-0xfe028fff irq 18 a= t device 20.5 on pci0 > ohci4: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xfe028000 > ohci4: [GIANT-LOCKED] > ohci4: [ITHREAD] > usb6: OHCI version 1.0, legacy support > usb6: SMM does not respond, resetting > usb6: on ohci4 > usb6: USB revision 1.0 > uhub6: on usb6 > uhub6: 2 ports with 2 removable, self powered > atkbdc0: port 0x60,0x64 irq 1 on acpi0 > atkbd0: irq 1 on atkbdc0 > atkbd: the current kbd controller command byte 0047 > atkbd: keyboard ID 0x41ab (2) > kbd0 at atkbd0 > kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 > ioapic0: routing intpin 1 (ISA IRQ 1) to vector 56 > atkbd0: [GIANT-LOCKED] > atkbd0: [ITHREAD] > cpu0: on acpi0 > cpu0: switching to generic Cx mode > powernow0: on cpu0 > cpu1: on acpi0 > powernow1: on cpu1 > ata: ata0 already exists; skipping it > atkbdc: atkbdc0 already exists; skipping it > sc: sc0 already exists; skipping it > vga: vga0 already exists; skipping it > 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 > isa_probe_children: probing non-PnP devices > pmtimer0 on isa0 > orm0: at iomem 0xc0000-0xcd7ff pnpid ORM0000 on isa0 > sc0: at flags 0x100 on isa0 > sc0: VGA <16 virtual consoles, flags=3D0x300> > 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) > ata1 failed to probe at port 0x170 irq 15 on isa0 > 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 0x378 > ppc0: using extended I/O port range > ppc0: SPP > ppc0: at port 0x378-0x37f irq 7 on isa0 > ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode > ppbus0: on ppc0 > ioapic0: routing intpin 7 (ISA IRQ 7) to vector 57 > ppbus0: [MPSAFE] > ppbus0: [ITHREAD] > lpt0: on ppbus0 > lpt0: Interrupt-driven port > ppc0: [GIANT-LOCKED] > ppc0: [ITHREAD] > sio0 failed to probe at port 0x3f8 irq 4 on isa0 > sio1 failed to probe at port 0x2f8 irq 3 on isa0 > sio2: not probed (disabled) > sio3: not probed (disabled) > sn0: not probed (disabled) > vt0: not probed (disabled) > isa_probe_children: probing PnP devices > Device configuration finished. > Reducing kern.maxvnodes 130270 -> 100000 > procfs registered > lapic: Divisor 2, Frequency 100213866 hz > Timecounter "TSC" frequency 2505346537 Hz quality -100 > Timecounters tick every 1.000 msec > lo0: bpf attached > ata0-slave: pio=3DPIO4 wdma=3DWDMA2 udma=3DUDMA40 cable=3D40 wire > acd0: setting PIO4 on IXP700 chip > acd0: DMA limited to UDMA33, device found non-ATA66 cable > acd0: setting UDMA33 on IXP700 chip > acd0: CDRW drive at ata0 as slave > acd0: read 4134KB/s (8958KB/s) write 8958KB/s (8958KB/s), 2048KB buffer, = UDMA33 > acd0: Reads: CDR, CDRW, CDDA stream, DVDROM, DVDR, packet > acd0: Writes: CDR, CDRW, test write, burnproof > acd0: Audio: play, 255 volume levels > acd0: Mechanism: ejectable tray, unlocked > acd0: Medium: CD-ROM 120mm data disc > ata2-master: pio=3DPIO4 wdma=3DWDMA2 udma=3DUDMA133 cable=3D40 wire > ad4: 305244MB at ata2-master SATA300 > ad4: 625140335 sectors [620178C/16H/63S] 16 sectors/interrupt 1 depth que= ue > GEOM: new disk ad4 > acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=3D0x24 ascq=3D0x00=20 > (probe0:ata0:0:1:0): error 22 > (probe0:ata0:0:1:0): Unretryable Error > (probe0:ata0:0:1:0): Down reving Protocol Version from 2 to 0? > acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=3D0x24 ascq=3D0x00=20 > (probe0:ata0:0:1:0): error 22 > (probe0:ata0:0:1:0): Unretryable Error > pass0 at ata0 bus 0 target 1 lun 0 > pass0: Removable CD-ROM SCSI-0 device=20 > pass0: 33.000MB/s transfers > GEOM: new disk cd0 > cd0 at ata0 bus 0 target 1 lun 0 > cd0: Removable CD-ROM SCSI-0 device=20 > cd0: 33.000MB/s transfers > cd0: cd present [294606 x 2048 byte records] > SMP: AP CPU #1 Launched! > cpu1 AP: > ID: 0x01000000 VER: 0x80050010 LDR: 0x00000000 DFR: 0xffffffff > lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff > timer: 0x000200ef therm: 0x00010000 err: 0x00010000 pcm: 0x00010000 > ioapic0: Assigning ISA IRQ 1 to local APIC 0 > ioapic0: Assigning ISA IRQ 7 to local APIC 1 > ioapic0: Assigning ISA IRQ 9 to local APIC 0 > ioapic0: Assigning ISA IRQ 14 to local APIC 1 > ioapic0: Assigning PCI IRQ 16 to local APIC 0 > ioapic0: Assigning PCI IRQ 17 to local APIC 1 > ioapic0: Assigning PCI IRQ 18 to local APIC 0 > ioapic0: Assigning PCI IRQ 19 to local APIC 1 > ioapic0: Assigning PCI IRQ 20 to local APIC 0 > ioapic0: Assigning PCI IRQ 22 to local APIC 1 > scsi_cd.c::ioctl cmd=3D4400648b error=3D25 > Trying to mount root from ufs:/dev/ad4s2a > start_init: trying /sbin/init > Linux ELF exec handler installed > fuse4bsd: version 0.3.9-pre1, FUSE ABI 7.8 > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" --=20 Robert Noland FreeBSD --=-dJ1DzJyAvHAqj0JuloTq Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEABECAAYFAkndDYMACgkQM4TrQ4qfROOZeACfUIMSVw1DNtoWSWN/VSkEovOe 17YAoIPwyAbrNP08cqE7w9qOsxUVoYci =+qL/ -----END PGP SIGNATURE----- --=-dJ1DzJyAvHAqj0JuloTq-- From owner-freebsd-stable@FreeBSD.ORG Wed Apr 8 21:11:15 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6AD47106564A for ; Wed, 8 Apr 2009 21:11:15 +0000 (UTC) (envelope-from nakal@web.de) Received: from fmmailgate03.web.de (fmmailgate03.web.de [217.72.192.234]) by mx1.freebsd.org (Postfix) with ESMTP id 26BE08FC0A for ; Wed, 8 Apr 2009 21:11:15 +0000 (UTC) (envelope-from nakal@web.de) Received: from smtp05.web.de (fmsmtp05.dlan.cinetic.de [172.20.4.166]) by fmmailgate03.web.de (Postfix) with ESMTP id 0B719FA29873; Wed, 8 Apr 2009 22:49:28 +0200 (CEST) Received: from [217.236.27.140] (helo=zelda.local) by smtp05.web.de with asmtp (TLSv1:AES128-SHA:128) (WEB.DE 4.110 #277) id 1Lrei7-0001Zs-00; Wed, 08 Apr 2009 22:49:27 +0200 Date: Wed, 8 Apr 2009 22:49:25 +0200 From: Martin To: piotr.smyrak@heron.pl Message-ID: <20090408224925.3dd1f8ab@zelda.local> In-Reply-To: <20090408190805.GA1368@smyrak.com> References: <20090408190805.GA1368@smyrak.com> X-Mailer: Claws Mail 3.7.1 (GTK+ 2.14.7; amd64-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: nakal@web.de X-Sender: nakal@web.de X-Provags-ID: V01U2FsdGVkX1/asoxUGQEMXpL3jI7Q13kCzdCFWiMoRAYojEvr Gq0TuQMRmdhlpcBYbQzoDSGai7SHaKThP1Dyzx5zPtVKxiV0N1 n4L+taxIA= Cc: freebsd-stable@freebsd.org Subject: Re: no USB mice detected on GA-MA74GM-S2 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2009 21:11:15 -0000 Am Wed, 8 Apr 2009 21:08:05 +0200 schrieb Piotr Smyrak : > First I started with my old build of 6.2, then upgraded to 6.4 > STABLE, to finally upgrade to 7.2 PRERELEASE in hope of fixing the > issue. None of versions gave me USB mouse support. I have tried > connecting 3 various mice. No luck. The only effect I can achieve > after connecting a mouse, is a somewhat delayed message on console: Hi, I have had also problems with recent Gigabyte Mainboards and USB mice. Something is really broken in this branch. Unlike you, I could always get my mouse to work by re-attaching it. You should perhaps take a look at the BIOS USB settings, so you could get at least the re-attaching work-around to work. BIOS settings that influence the behavior of USB mice are: - any "legacy USB support" settings - so-called "BIOS support for USB mice" Because -STABLE has been really frustrating, I migrated all my desktops to -CURRENT that has the new USB-v2 stack. The USB problems disappeared there. I'm overall satisfied with -CURRENT. I've always wanted to say that FreeBSD developers do a really great job on the -CURRENT branch. It's running very stable and has plenty of new features. I know I shouldn't recommend to migrate to -CURRENT, but I'm almost sure, it runs much better than every -CURRENT I've seen before and sometimes I have the impression that it's even nicer than the -STABLE branch. Everyone who does not like the buggy USB v1, could try to do a second installation on a free partition to get rid of the annoyances. -- Martin From owner-freebsd-stable@FreeBSD.ORG Wed Apr 8 21:59:23 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DF322106564A for ; Wed, 8 Apr 2009 21:59:22 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) by mx1.freebsd.org (Postfix) with ESMTP id C972D8FC08 for ; Wed, 8 Apr 2009 21:59:20 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from localhost (localhost.codelab.cz [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id 38F5C19E023; Wed, 8 Apr 2009 23:59:13 +0200 (CEST) Received: from [192.168.1.2] (r5bb235.net.upc.cz [86.49.61.235]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id CA32B19E019; Wed, 8 Apr 2009 23:59:10 +0200 (CEST) Message-ID: <49DD1E2E.4030009@quip.cz> Date: Wed, 08 Apr 2009 23:59:10 +0200 From: Miroslav Lachman <000.fbsd@quip.cz> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: cz, cs, en, en-us MIME-Version: 1.0 To: Ivan Voras References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: ZFSKnownProblems - needs revision? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2009 21:59:23 -0000 Ivan Voras wrote: > Ivan Voras wrote: > > >>* Are the issues on the list still there? >>* Are there any new issues? >>* Is somebody running ZFS in production (non-trivial loads) with >>success? What architecture / RAM / load / applications used? >>* How is your memory load? (does it leave enough memory for other services) > > > also: what configuration (RAIDZ, mirror, etc.?) I have two production servers with ZFS. First is HP ProLiant ML110 G5 with 4x 1TB SATA Samsung drives in RAIDZ + 5GB RAM running FreeBSD 7.1-RELEASE amd64 (GENERIC) Root is on USB flash drive with UFS, main storage is on ZFS. # zfs list NAME USED AVAIL REFER MOUNTPOINT tank 1.34T 1.33T 29.9K /tank tank/system 1.04G 1.33T 28.4K /tank/system tank/system/tmp 52.4K 1.33T 52.4K /tmp tank/system/usr 611M 1.33T 95.0K /tank/system/usr tank/system/usr/obj 26.9K 1.33T 26.9K /usr/obj tank/system/usr/ports 443M 1.33T 214M /usr/ports tank/system/usr/ports/distfiles 105M 1.33T 105M /usr/ports/distfiles tank/system/usr/ports/packages 123M 1.33T 123M /usr/ports/packages tank/system/usr/src 168M 1.33T 168M /usr/src tank/system/var 459M 1.33T 213K /var tank/system/var/db 421M 1.33T 420M /var/db tank/system/var/db/pkg 387K 1.33T 387K /var/db/pkg tank/system/var/log 37.8M 1.33T 37.8M /var/log tank/system/var/run 60.6K 1.33T 60.6K /var/run tank/vol0 1.34T 1.33T 1.34T /vol0 This server is storage for backups made every night by rsync from 10 FreeBSD machines. It takes about 1 hour every night to do rsync backup of all machines. Rsync is used for "snapshots" with --link-dest= (each day has own directory and all unchenged files are hardlinked to previous day and I have history of two month back). Backups are stored on /vol0 with compression enabled. (compression is enabled on /usr/ports, /usr/src, /var/db/pkg, /vol0) # df -hi /vol0/ Filesystem Size Used Avail Capacity iused ifree %iused Mounted on tank/vol0 2.7T 1.3T 1.3T 50% 17939375 11172232 62% /vol0 This backup server is in service from october 2008 with just one panic (kmem related). After proper loader.conf tuning it is working well. # cat /boot/loader.conf ## ZFS tuning vm.kmem_size="1280M" vm.kmem_size_max="1280M" vfs.zfs.prefetch_disable="1" vfs.zfs.arc_min="16M" vfs.zfs.arc_max="128M" up 80+04:52:10 23:33:40 28 processes: 1 running, 27 sleeping CPU: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle Mem: 17M Active, 26M Inact, 1541M Wired, 328K Cache, 204M Buf, 3234M Free The second server with ZFS is used as Jails hosting. It is buil on Sun Fire X2100 M2 with 2x 500GB SATA drives + 4GB RAM running FreeBSD 7.1-STABLE amd64 from Wed Feb 11 09:56:08 CET 2009 (GENERIC kernel) The hard drives are splitted to two slices, where first slice is used for gmirrored system (about 20GB) and the rest is used for ZFS mirror. There are 5 Jails running. One with postfix as backup MX and BIND as slave DNS for little webhosting company. Few jails for webdevelopers (not heavily loaded), but last jail has 240GB of audio files for streaming throught Lighttpd with speed about 30Mbps. There are some issues with Lighttpd in conjunction with ZFS - after about 30-60 minutes, Lighttpd decrease the speed to less than 7Mbps until it is restarted, then everything works well. The server has uptime 56 days without any panic or other stability issues. Another box with Lighttpd + UFS (not in jail) is serving same files by 65Mbps without problem. (Lighttpd problem may be related to jail instead of ZFS - I did not test it yet) All jails are on compressed filesystems and there are some snapshots of each jail. # cat /boot/loader.conf ## gmirror RAID1 geom_mirror_load="YES" ## ZFS tuning vm.kmem_size="1280M" vm.kmem_size_max="1280M" kern.maxvnodes="400000" vfs.zfs.prefetch_disable="1" vfs.zfs.arc_min="16M" vfs.zfs.arc_max="128M" Miroslav Lachman From owner-freebsd-stable@FreeBSD.ORG Wed Apr 8 22:20:54 2009 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EB2061065676; Wed, 8 Apr 2009 22:20:54 +0000 (UTC) (envelope-from bkoenig@alpha-tierchen.de) Received: from alpha-tierchen.de (alpha-tierchen.de [88.198.145.202]) by mx1.freebsd.org (Postfix) with ESMTP id ACF448FC0C; Wed, 8 Apr 2009 22:20:54 +0000 (UTC) (envelope-from bkoenig@alpha-tierchen.de) Received: from webmail.alpha-tierchen.de (alpha-tierchen.de [88.198.145.202]) by alpha-tierchen.de (Postfix) with ESMTP id 2117E239190; Thu, 9 Apr 2009 00:05:06 +0200 (CEST) Received: from 212.202.40.56 (SquirrelMail authenticated user bkoenig) by webmail.alpha-tierchen.de with HTTP; Thu, 9 Apr 2009 00:05:06 +0200 (CEST) Message-ID: <70ba25e4f1a5e43ab8d99b361235dda2.squirrel@webmail.alpha-tierchen.de> Date: Thu, 9 Apr 2009 00:05:06 +0200 (CEST) From: "Bjoern Koenig" To: stable@freebsd.org User-Agent: SquirrelMail/1.4.17 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: yongari@freebsd.org Subject: fxp: stalled transfers X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2009 22:20:55 -0000 Hello, after upgrading my system from 7.1-RELEASE to recent RELENG_7 I noticed stalled network transfers in certain cases. I have an Intel PRO/100 ethernet adapter (card=0x00408086 chip=0x12298086 rev=0x0c). In general networking works fine. I can ping hosts, surf on websites and so on. But if I send large files (>1 MB) to my server the transfer stalls after a few kilobytes. This concerns FTP and SCP likewise. While trying to find a reason for this problem I did a binary search on the source tree using a generic kernel configuration and found out that the following commit is responsible for this: SVN rev 188374 on 2009-02-09 03:48:49Z by yongari MFC r185330: Implement TSO for 82550/82551 controllers. o Configure controller to use dynamic TBD as TSO requires that operation mode. o Add a dummy TBD to tx_cb_u as TSO can access one more TBD in TSO operation. o Increase a DMA segment size to 4096 to hold a full IP segment with link layer header. o Unlike other TSO capable controllers, 82550/82551 does not modify the first IP packet in TSO operation so driver should create an IP packet with proper header. Subsequent IP packets are generated from the header information in the first IP packet header. Likewise pseudo checksum also should be computed by driver for the first packet. o TSO requires one more TBD to hold total TCP payload. To make code simple for TSO/non-TSO case, increase the index of the first available TBD array. o Remove KASSERT that checks the size of a DMA segment should be less than or equal to MCLBYTES as it's no longer valid in TSO. o Tx threshold and number of TBDs field is used to store MSS in TSO. So don't set the Tx threshold in TSO case. I didn't look further on this commit for now. Please review it. Probably someone of you can give me a hint. Regards Björn From owner-freebsd-stable@FreeBSD.ORG Wed Apr 8 22:35:41 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B70C71065676 for ; Wed, 8 Apr 2009 22:35:41 +0000 (UTC) (envelope-from ivoras@gmail.com) Received: from mail-ew0-f171.google.com (mail-ew0-f171.google.com [209.85.219.171]) by mx1.freebsd.org (Postfix) with ESMTP id 476898FC25 for ; Wed, 8 Apr 2009 22:35:40 +0000 (UTC) (envelope-from ivoras@gmail.com) Received: by ewy19 with SMTP id 19so373511ewy.43 for ; Wed, 08 Apr 2009 15:35:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:from:date:x-google-sender-auth:message-id:subject:to:cc :content-type:content-transfer-encoding; bh=Yj4yF9HflzAFMFIbk6y0SXVipEjD3ghOKrevgIweFI8=; b=YMlRLkkqLCwyJxVsBPetBCLN0Q1d+oTIQ86pzCJxiD6erqk0TaeMR4IZlvRIa9Gwcx cYXLYh6mZxDBg1ExiWLL/7cAVyYM0P/c5hC8v4HcPTQVihPbkXyqtbq48ICO1G4hKSbu NyzP2OQtJoa3EE+KITSmVaKI1fWcv3T2Fx4hM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; b=ktYLqTlA7l69ZA9S8fZvZw0SHhsIoU2I4WMm/5D4w2nHdpfpHQ8p7R1Jvj0crPl8Lq GdeF60WzjTb/7W0t18gDYK+DUELmbIfvxQO1/1ICXtyJ0heoefLOuG446yWfhTMKEM0y qK4tmYBPtkGqSHLa+YGyZJWEDHT5Iq1VNz4Aw= MIME-Version: 1.0 Sender: ivoras@gmail.com Received: by 10.210.66.13 with SMTP id o13mr5524384eba.9.1239230140246; Wed, 08 Apr 2009 15:35:40 -0700 (PDT) In-Reply-To: <49DD1E2E.4030009@quip.cz> References: <49DD1E2E.4030009@quip.cz> From: Ivan Voras Date: Thu, 9 Apr 2009 00:35:25 +0200 X-Google-Sender-Auth: 991c7a46c9bd1026 Message-ID: <9bbcef730904081535l2339dc7fk6ce7957976d9425@mail.gmail.com> To: Miroslav Lachman <000.fbsd@quip.cz> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: ZFSKnownProblems - needs revision? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2009 22:35:42 -0000 2009/4/8 Miroslav Lachman <000.fbsd@quip.cz>: > (Lighttpd problem may be related to jail instead of ZFS - I did not test it > yet) Completely unrelated to ZFS, but wasn't there some issue with lighttpd and sendfile() relatively recently (sendfile is the default)? Have you tried server.network-backend = "writev" ? From owner-freebsd-stable@FreeBSD.ORG Wed Apr 8 23:26:58 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3C7C3106566B for ; Wed, 8 Apr 2009 23:26:58 +0000 (UTC) (envelope-from fbsd-stable@mawer.org) Received: from outbound.icp-qv1-irony-out2.iinet.net.au (outbound.icp-qv1-irony-out2.iinet.net.au [203.59.1.107]) by mx1.freebsd.org (Postfix) with ESMTP id B0BD78FC1B for ; Wed, 8 Apr 2009 23:26:57 +0000 (UTC) (envelope-from fbsd-stable@mawer.org) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArcBAJvI3EnLzq3r/2dsb2JhbAAI0EGDewY X-IronPort-AV: E=Sophos;i="4.40,157,1238947200"; d="scan'208";a="462952296" Received: from unknown (HELO [10.24.1.1]) ([203.206.173.235]) by outbound.icp-qv1-irony-out2.iinet.net.au with ESMTP; 09 Apr 2009 06:57:45 +0800 Message-ID: <49DD2B44.5020808@mawer.org> Date: Thu, 09 Apr 2009 08:55:00 +1000 From: Antony Mawer User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Freddie Cash References: <200904080959.49201.fjwcash@gmail.com> In-Reply-To: <200904080959.49201.fjwcash@gmail.com> X-Stationery: 0.4.8.14 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Network sysctl tuning [was Re: ZFSKnownProblems - needs revision?] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2009 23:26:58 -0000 Freddie Cash wrote: ... > We've also heavily modified /etc/sysctl.conf and upped a bunch of the > network-related sysctls. Doing so increased our SSH throughput from ~30 > Mbits/sec across all connections to over 90 Mbits/sec per SSH connection. Are you able to share any of these with the list? It would be useful to compare as a lot of these tunings people do individually and it would be good to allow others to test in their environments to see if they help, as well as potentially adding them to the tuning man-page. -- Antony From owner-freebsd-stable@FreeBSD.ORG Thu Apr 9 00:03:25 2009 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1F9B4106566B; Thu, 9 Apr 2009 00:03:25 +0000 (UTC) (envelope-from pyunyh@gmail.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 892388FC17; Thu, 9 Apr 2009 00:03:24 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by ti-out-0910.google.com with SMTP id u5so294046tia.3 for ; Wed, 08 Apr 2009 17:03:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=p7ZPRQ7HXMSsWvOpDZF3ZHPsVMONUDQ0EbtT1amtb4s=; b=ZbHxE8xQDf349LFSiWPwe21O2O0i2lfUB0xqyOg48h5OsP9/BNys/QiJpXEAw4xRFr VwgjEXq38krRPZNmX3PWwekf9cZnYtgJoiX2oi/L7HhoWI34k9Zsh+aP8gFQkHLyfDXd Vo8RSZ3UtndT4/rEODrSuljSMCDsLYiqQRxLU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=aISBdqamHbRILPUyhu482f5iyFd1Drr9SlQfcsGHyGwbIusZ2XKLhsraq+N/+tL4kV MXuA10nv2ZAuT6Etab74cTP6ZvNtw7V7qGfKzpk9rmvUeH3U9kTCPoothPbuh0fZSyT8 eVdntyR/WtTrRomCDkAgNcjBTnTSG/ikiBdas= Received: by 10.110.11.7 with SMTP id 7mr2052134tik.55.1239235403537; Wed, 08 Apr 2009 17:03:23 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ([114.111.62.249]) by mx.google.com with ESMTPS id b4sm1367984tic.36.2009.04.08.17.03.20 (version=SSLv3 cipher=RC4-MD5); Wed, 08 Apr 2009 17:03:21 -0700 (PDT) Received: by michelle.cdnetworks.co.kr (sSMTP sendmail emulation); Thu, 9 Apr 2009 09:04:27 +0900 From: Pyun YongHyeon Date: Thu, 9 Apr 2009 09:04:27 +0900 To: Bjoern Koenig Message-ID: <20090409000427.GD37714@michelle.cdnetworks.co.kr> References: <70ba25e4f1a5e43ab8d99b361235dda2.squirrel@webmail.alpha-tierchen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <70ba25e4f1a5e43ab8d99b361235dda2.squirrel@webmail.alpha-tierchen.de> User-Agent: Mutt/1.4.2.3i Cc: stable@freebsd.org, yongari@freebsd.org Subject: Re: fxp: stalled transfers X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 00:03:25 -0000 On Thu, Apr 09, 2009 at 12:05:06AM +0200, Bjoern Koenig wrote: > Hello, > > after upgrading my system from 7.1-RELEASE to recent RELENG_7 I noticed > stalled network transfers in certain cases. I have an Intel PRO/100 > ethernet adapter (card=0x00408086 chip=0x12298086 rev=0x0c). In general > networking works fine. I can ping hosts, surf on websites and so on. But > if I send large files (>1 MB) to my server the transfer stalls after a few > kilobytes. This concerns FTP and SCP likewise. While trying to find a > reason for this problem I did a binary search on the source tree using a > generic kernel configuration and found out that the following commit is > responsible for this: > > SVN rev 188374 on 2009-02-09 03:48:49Z by yongari > > MFC r185330: > Implement TSO for 82550/82551 controllers. > o Configure controller to use dynamic TBD as TSO requires that > operation mode. > o Add a dummy TBD to tx_cb_u as TSO can access one more TBD in TSO > operation. > o Increase a DMA segment size to 4096 to hold a full IP segment > with link layer header. > o Unlike other TSO capable controllers, 82550/82551 does not > modify the first IP packet in TSO operation so driver should > create an IP packet with proper header. Subsequent IP packets > are generated from the header information in the first IP packet > header. Likewise pseudo checksum also should be computed by > driver for the first packet. > o TSO requires one more TBD to hold total TCP payload. To make > code simple for TSO/non-TSO case, increase the index of the > first available TBD array. > o Remove KASSERT that checks the size of a DMA segment should be > less than or equal to MCLBYTES as it's no longer valid in TSO. > o Tx threshold and number of TBDs field is used to store MSS in > TSO. So don't set the Tx threshold in TSO case. > > > I didn't look further on this commit for now. Please review it. Probably > someone of you can give me a hint. > Could you disable TSO and try again?('ifconfig fxp0 -tso' will do the job). From owner-freebsd-stable@FreeBSD.ORG Thu Apr 9 05:52:38 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3E0A01065670; Thu, 9 Apr 2009 05:52:38 +0000 (UTC) (envelope-from mandrews@bit0.com) Received: from magnum.bit0.com (magnum.bit0.com [207.246.88.226]) by mx1.freebsd.org (Postfix) with ESMTP id 174FA8FC0A; Thu, 9 Apr 2009 05:52:37 +0000 (UTC) (envelope-from mandrews@bit0.com) Received: from fred.int.bit0.com (nat.bit0.com [207.246.88.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by magnum.bit0.com (Postfix) with ESMTPSA id 44FB7164E18; Thu, 9 Apr 2009 01:34:25 -0400 (EDT) Message-ID: <49DD88E0.7060209@bit0.com> Date: Thu, 09 Apr 2009 01:34:24 -0400 From: Mike Andrews User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Ivan Voras References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: ZFSKnownProblems - needs revision? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 05:52:38 -0000 Ivan Voras wrote: > Ivan Voras wrote: > >> * Are the issues on the list still there? >> * Are there any new issues? >> * Is somebody running ZFS in production (non-trivial loads) with >> success? What architecture / RAM / load / applications used? >> * How is your memory load? (does it leave enough memory for other services) > > also: what configuration (RAIDZ, mirror, etc.?) With 7.0 and 7.1 I had frequent livelocks with ZFS when it was unable to get more memory from the kernel. Tuning kmem up to 768K helped but didn't 100% eliminate the issues... still had to reboot systems every few weeks. Since most were either in a redundant cluster or personal machines, I kinda lived with it. With the increase in default kmem size in 7.2, I removed the kmem_size tuning and have not had a single ZFS-related hang since. The only tuning I use is vfs.zfs.arc_max="100M" and disabling prefetch (but leaving zil on) -- and I'm seriously considering throwing those two out (or at least raising arc_max) and seeing what happens. I'm much happier with how 7.2's ZFS behaves than 7.1's. It's definitely "getting there"... with one catch (see below). Anyone running an up-to-date STABLE -- on amd64, anyway -- should consider removing kmem_size tweaks from their loader.conf... You don't need 8.x for that, just 7.2-prerelease/beta. I don't know about i386, I'd be a bit nervous about ZFS on i386 given how much memory it wants on amd64... There is a significant issue with MySQL InnoDB logs getting corrupted if the system ever does crash/lose power/etc, very reproducible on demand on multiple 7.2/7.1/7.0 machines, but is not reproducible in HEAD and its newer ZFS v13 (which is why I never opened a pr on it). For now any MySQL masters I run must stay on UFS2, because of that showstopper... if anyone wants to try to look at it, I can open a pr or send more details, just ask. I have seen one file get corrupted in a zpool, in two separate instances (different machines each time), but was never able to reproduce it ever again. Next time it happens I'll dig into it a bit more. This is on about seven Core 2 Quad boxes with 8 GB of memory (some have only 4) and amd64. Most disk IO is writing http logs, which can get pretty busy on our webservers (usually hundreds of apache processes plus nginx, previously lighttpd, serving a few thousand concurrent hits)... plus some light maildir, some not-so-light rsync at night... Most are simple mirrored pairs of SATA disks. A few are hardware raid10 (LSI SAS, 3ware SAS) and ZFS is given just a single device... even though I know that's not optimal (two hardware raid1's or jbod would be more reliable)... those are personal boxes and not production though. I'm not brave enough to attempt booting off of ZFS yet; I use a small gmirrored UFS2 for /. I'm not swapping to ZFS either. From owner-freebsd-stable@FreeBSD.ORG Thu Apr 9 07:15:13 2009 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B9E6B106564A for ; Thu, 9 Apr 2009 07:15:13 +0000 (UTC) (envelope-from bkoenig@alpha-tierchen.de) Received: from alpha-tierchen.de (alpha-tierchen.de [88.198.145.202]) by mx1.freebsd.org (Postfix) with ESMTP id 7CC3B8FC1B for ; Thu, 9 Apr 2009 07:15:13 +0000 (UTC) (envelope-from bkoenig@alpha-tierchen.de) Received: from webmail.alpha-tierchen.de (alpha-tierchen.de [88.198.145.202]) by alpha-tierchen.de (Postfix) with ESMTP id 2B51E2391F0; Thu, 9 Apr 2009 09:15:12 +0200 (CEST) Received: from 212.202.40.56 (SquirrelMail authenticated user bkoenig) by webmail.alpha-tierchen.de with HTTP; Thu, 9 Apr 2009 09:15:12 +0200 (CEST) Message-ID: <2f68678165f20f2e1dae10cb0e63761d.squirrel@webmail.alpha-tierchen.de> In-Reply-To: <20090409000427.GD37714@michelle.cdnetworks.co.kr> References: <70ba25e4f1a5e43ab8d99b361235dda2.squirrel@webmail.alpha-tierchen.de> <20090409000427.GD37714@michelle.cdnetworks.co.kr> Date: Thu, 9 Apr 2009 09:15:12 +0200 (CEST) From: "Bjoern Koenig" To: pyunyh@gmail.com User-Agent: SquirrelMail/1.4.17 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: stable@freebsd.org Subject: Re: fxp: stalled transfers X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 07:15:14 -0000 pyunyh@gmail.com wrote: > Could you disable TSO and try again?('ifconfig fxp0 -tso' will do > the job). Yes, disabling TSO helps. That's a reasonable workaround for me. Thanks. Let me know if you need further information in case you want to make changes to the fxp driver regarding this problem. Björn From owner-freebsd-stable@FreeBSD.ORG Thu Apr 9 07:22:01 2009 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 892DC1065674 for ; Thu, 9 Apr 2009 07:22:01 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.230]) by mx1.freebsd.org (Postfix) with ESMTP id 56A038FC15 for ; Thu, 9 Apr 2009 07:22:01 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by rv-out-0506.google.com with SMTP id f6so163157rvb.3 for ; Thu, 09 Apr 2009 00:22:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=f6iC+nBktar4cZg700uYh3ZyV7FYAAi+mkjfOozNpTg=; b=diECcfaMrogFV8GNSNhgkGJEjRcIAKvFLOcj7rjEran8eM5fg2Zk0aWljivf7fyih0 CUlITYuyvrXicd57uTyf4GTRAHHWZd1J/V74j4gb/cMbRn9jKd5Wv5b84U9lHfI30gZG y0/2Gah/wPUO4IS24tAvimzJrobgg0OYW+kNY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=Sb68PYMbLK8IDwgNkidt2XyT50fnoFXjjiHF8UQjD0CNasL3nYbPPlvZZdl8+V+gUP Q9lgLTp86fo0FfPRepEmo3zUiM11DvBofgSbIFnIz9OIJ/7vKyMyUS9EKEcX/wZyCNXg GDhwsz00BL2iWlxlNLPVnFSz97OFEtKojOdWU= Received: by 10.141.14.17 with SMTP id r17mr920400rvi.297.1239261720993; Thu, 09 Apr 2009 00:22:00 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ([114.111.62.249]) by mx.google.com with ESMTPS id b39sm122976rvf.29.2009.04.09.00.21.59 (version=SSLv3 cipher=RC4-MD5); Thu, 09 Apr 2009 00:22:00 -0700 (PDT) Received: by michelle.cdnetworks.co.kr (sSMTP sendmail emulation); Thu, 9 Apr 2009 16:23:09 +0900 From: Pyun YongHyeon Date: Thu, 9 Apr 2009 16:23:09 +0900 To: Bjoern Koenig Message-ID: <20090409072309.GF37714@michelle.cdnetworks.co.kr> References: <70ba25e4f1a5e43ab8d99b361235dda2.squirrel@webmail.alpha-tierchen.de> <20090409000427.GD37714@michelle.cdnetworks.co.kr> <2f68678165f20f2e1dae10cb0e63761d.squirrel@webmail.alpha-tierchen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2f68678165f20f2e1dae10cb0e63761d.squirrel@webmail.alpha-tierchen.de> User-Agent: Mutt/1.4.2.3i Cc: stable@freebsd.org Subject: Re: fxp: stalled transfers X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 07:22:02 -0000 On Thu, Apr 09, 2009 at 09:15:12AM +0200, Bjoern Koenig wrote: > pyunyh@gmail.com wrote: > > > Could you disable TSO and try again?('ifconfig fxp0 -tso' will do > > the job). > > Yes, disabling TSO helps. That's a reasonable workaround for me. Thanks. > > Let me know if you need further information in case you want to make > changes to the fxp driver regarding this problem. > If you can easily reproduce the issue, can you capture stalled TCP session with tcpdump on receiving host?(Make sure to disable Rx checksum offload prior to capturing the session.) From owner-freebsd-stable@FreeBSD.ORG Thu Apr 9 07:43:08 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7882110656E5; Thu, 9 Apr 2009 07:43:08 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.16.84]) by mx1.freebsd.org (Postfix) with ESMTP id 201648FC17; Thu, 9 Apr 2009 07:43:07 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1Lroug-000A1Y-Je; Thu, 09 Apr 2009 10:43:06 +0300 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: Ivan Voras In-reply-to: References: Comments: In-reply-to Ivan Voras message dated "Wed, 08 Apr 2009 15:04:48 +0200." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 09 Apr 2009 10:43:06 +0300 From: Danny Braniss Message-ID: Cc: freebsd-stable@freebsd.org Subject: Re: FreeBSD and iSCSI for disks. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 07:43:08 -0000 > This is an OpenPGP/MIME signed message (RFC 2440 and 3156) > --------------enig90DADA8437A99D893FB775F8 > Content-Type: text/plain; charset=UTF-8 > Content-Transfer-Encoding: quoted-printable > > Danny Braniss wrote: > >> Garance A Drosihn wrote: > >>> Some friends of mine are looking at the new "DroboPro", which makes a= > > >>> lot of disk space available via iSCSI (in addition to firewire 800), > >>> and they were wondering how well iSCSI works with FreeBSD. I haven't= > > >>> paid attention to iSCSI support. Is there anyone using it heavily > >>> for disk-storage under FreeBSD? Has there been much changed for > >>> iSCSI support in the 8.x branch, or is 7.x support working fine? > >> I suppose you are interested in the "client" (initiator) side of iSCSI= > > >> support. It hasn't changed much between 7.x and 8.x but there are > >> apparently some announcements of a newer version: > >> > >> http://lists.freebsd.org/pipermail/freebsd-scsi/2009-March/003834.html= > > >> > >> I can't find any more information on it. > > > > the latest is in: > > http://www.cs.huji.ac.il/~danny/ftp/freebsd/iscsi-2.1.1.tar.gz > > Thanks! > > Is there anything in particular you'd like to get tested in the new > version, any significant changes or improvements? mainly fixed some bugs, and some code cleanup. give it a spin, and let me know what target you are testing. btw, the default tag opening is a bit concervative (1), you might want to change it to somewhat larger, say 64 or 128. cheers, danny From owner-freebsd-stable@FreeBSD.ORG Thu Apr 9 07:56:11 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 178B71065721; Thu, 9 Apr 2009 07:56:11 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) by mx1.freebsd.org (Postfix) with ESMTP id BBA7C8FC16; Thu, 9 Apr 2009 07:56:09 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from localhost (localhost.codelab.cz [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id F1E3119E023; Thu, 9 Apr 2009 09:56:06 +0200 (CEST) Received: from [192.168.1.2] (r5bb235.net.upc.cz [86.49.61.235]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id 8A62319E019; Thu, 9 Apr 2009 09:56:01 +0200 (CEST) Message-ID: <49DDAA11.1040804@quip.cz> Date: Thu, 09 Apr 2009 09:56:01 +0200 From: Miroslav Lachman <000.fbsd@quip.cz> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: cz, cs, en, en-us MIME-Version: 1.0 To: Ivan Voras References: <49DD1E2E.4030009@quip.cz> <9bbcef730904081535l2339dc7fk6ce7957976d9425@mail.gmail.com> In-Reply-To: <9bbcef730904081535l2339dc7fk6ce7957976d9425@mail.gmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: ZFSKnownProblems - needs revision? / Lighttpd X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 07:56:24 -0000 Ivan Voras wrote: > 2009/4/8 Miroslav Lachman <000.fbsd@quip.cz>: > >>(Lighttpd problem may be related to jail instead of ZFS - I did not test it >>yet) > > Completely unrelated to ZFS, but wasn't there some issue with lighttpd > and sendfile() relatively recently (sendfile is the default)? Have you > tried server.network-backend = "writev" ? I know about the problem with sendfile as I was hit by it on the main server with Lighttpd + UFS. It has different behavior and it was fixed in the latest version of Lighttpd from ports. Both servers (main with UFS and second with ZFS + Jail) are running this fixed version. I will test it with "writev", thanks for suggestion. With lower load, Lighttpd is shown in `top` with state 'kqread', but with higher load in the case of slowdown, the state is 'zfs->io'. Miroslav Lachman From owner-freebsd-stable@FreeBSD.ORG Thu Apr 9 08:35:35 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3281210656D3; Thu, 9 Apr 2009 08:35:35 +0000 (UTC) (envelope-from goran.lowkrantz@ismobile.com) Received: from mail.ismobile.com (mail.ismobile.com [62.119.44.68]) by mx1.freebsd.org (Postfix) with ESMTP id B60DA8FC1A; Thu, 9 Apr 2009 08:35:34 +0000 (UTC) (envelope-from goran.lowkrantz@ismobile.com) Received: from mail.ismobile.com (localhost [127.0.0.1]) by mail.ismobile.com (Postfix) with ESMTP id 3710A116; Thu, 9 Apr 2009 10:18:09 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=ismobile.com; h=date:from :to:cc:subject:message-id:in-reply-to:references:mime-version :content-type:content-transfer-encoding; s=selector1; bh=mflemof 9RvwGdzs62K+byvVvCwY=; b=IzWWTXZ9mEYBO8WWOt/d3/LHLA0rpzOjpwdVFM3 4QCKiCBwX45dXW9U/gBfu6Qv3F4JQAqLrRMle6iWrvYt53+Or3UY1hzTvXUE6KJU xMc9Nty5XZt1wO+u5ZvaQOIPgw1zFzKuHydkD6TjWgGmJJN8ytINLODJa/1aGBEJ aqqI= Received: from [172.16.2.179] (unknown [172.16.2.179]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.ismobile.com (Postfix) with ESMTPSA id 9A372115; Thu, 9 Apr 2009 10:18:07 +0200 (CEST) Date: Thu, 09 Apr 2009 10:18:03 +0200 From: Goran Lowkrantz To: Danny Braniss Message-ID: <24AB3B457082F236919D1D72@syn> In-Reply-To: References: X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Cc: freebsd-stable@freebsd.org, Ivan Voras Subject: Re: FreeBSD and iSCSI for disks. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 08:35:35 -0000 Trying to build 2.1.1 on a CURRENT results in this: =3D=3D=3D> iscsi/initiator (all) cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc=20 -DHAVE_KERNEL_OPTION_HEADERS -include=20 /usr/obj/usr/src/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq=20 -finline-limit=3D8000 --param inline-unit-growth=3D100 --param=20 large-function-growth=3D1000 -fno-common -g -fno-omit-frame-pointer=20 -I/usr/obj/usr/src/sys/GENERIC -mcmodel=3Dkernel -mno-red-zone = -mfpmath=3D387=20 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float=20 -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector=20 -std=3Diso9899:1999 -fstack-protector -Wall -Wredundant-decls=20 -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith=20 -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -c=20 /usr/src/sys/modules/iscsi/initiator/../../../dev/iscsi/initiator/iscsi.c /usr/src/sys/modules/iscsi/initiator/../../../dev/iscsi/initiator/iscsi.c:=20 In function 'iscsi_open': /usr/src/sys/modules/iscsi/initiator/../../../dev/iscsi/initiator/iscsi.c:12= 0:=20 error: invalid operands to binary & /usr/src/sys/modules/iscsi/initiator/../../../dev/iscsi/initiator/iscsi.c:12= 2:=20 error: invalid operands to binary & /usr/src/sys/modules/iscsi/initiator/../../../dev/iscsi/initiator/iscsi.c:12= 6:=20 error: invalid operands to binary & /usr/src/sys/modules/iscsi/initiator/../../../dev/iscsi/initiator/iscsi.c:=20 In function 'iscsi_close': /usr/src/sys/modules/iscsi/initiator/../../../dev/iscsi/initiator/iscsi.c:14= 9:=20 error: invalid operands to binary & /usr/src/sys/modules/iscsi/initiator/../../../dev/iscsi/initiator/iscsi.c:15= 4:=20 error: invalid operands to binary & /usr/src/sys/modules/iscsi/initiator/../../../dev/iscsi/initiator/iscsi.c:=20 In function 'iscsi_ioctl': /usr/src/sys/modules/iscsi/initiator/../../../dev/iscsi/initiator/iscsi.c:18= 4:=20 error: invalid operands to binary & /usr/src/sys/modules/iscsi/initiator/../../../dev/iscsi/initiator/iscsi.c:21= 0:=20 error: invalid operands to binary & /usr/src/sys/modules/iscsi/initiator/../../../dev/iscsi/initiator/iscsi.c:=20 In function 'iscsi_read': /usr/src/sys/modules/iscsi/initiator/../../../dev/iscsi/initiator/iscsi.c:29= 0:=20 error: invalid operands to binary & /glz --On April 9, 2009 10:43:06 +0300 Danny Braniss = wrote: >> This is an OpenPGP/MIME signed message (RFC 2440 and 3156) >> --------------enig90DADA8437A99D893FB775F8 >> Content-Type: text/plain; charset=3DUTF-8 >> Content-Transfer-Encoding: quoted-printable >> >> Danny Braniss wrote: >> >> Garance A Drosihn wrote: >> >>> Some friends of mine are looking at the new "DroboPro", which makes >> >>> a=3D >> >> >>> lot of disk space available via iSCSI (in addition to firewire 800), >> >>> and they were wondering how well iSCSI works with FreeBSD. I >> >>> haven't=3D >> >> >>> paid attention to iSCSI support. Is there anyone using it heavily >> >>> for disk-storage under FreeBSD? Has there been much changed for >> >>> iSCSI support in the 8.x branch, or is 7.x support working fine? >> >> I suppose you are interested in the "client" (initiator) side of >> >> iSCSI=3D >> >> >> support. It hasn't changed much between 7.x and 8.x but there are >> >> apparently some announcements of a newer version: >> >> >> >> http://lists.freebsd.org/pipermail/freebsd-scsi/2009-March/003834.htm >> >> l=3D >> >> >> >> >> I can't find any more information on it. >> > >> > the latest is in: >> > http://www.cs.huji.ac.il/~danny/ftp/freebsd/iscsi-2.1.1.tar.gz >> >> Thanks! >> >> Is there anything in particular you'd like to get tested in the new >> version, any significant changes or improvements? > mainly fixed some bugs, and some code cleanup. > > give it a spin, and let me know what target you are testing. > btw, the default tag opening is a bit concervative (1), you might want to > change it to somewhat larger, say 64 or 128. > > cheers, > danny > > > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" ................................................... the future isMobile Goran Lowkrantz System Architect, isMobile AB Sandviksgatan 81, PO Box 58, S-971 03 Lule=E5, Sweden Mobile: +46(0)70-587 87 82 http://www.ismobile.com ............................................... From owner-freebsd-stable@FreeBSD.ORG Thu Apr 9 09:02:07 2009 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 11BFB10656DF for ; Thu, 9 Apr 2009 09:02:07 +0000 (UTC) (envelope-from bkoenig@alpha-tierchen.de) Received: from alpha-tierchen.de (alpha-tierchen.de [88.198.145.202]) by mx1.freebsd.org (Postfix) with ESMTP id C84DA8FC22 for ; Thu, 9 Apr 2009 09:02:06 +0000 (UTC) (envelope-from bkoenig@alpha-tierchen.de) Received: from webmail.alpha-tierchen.de (alpha-tierchen.de [88.198.145.202]) by alpha-tierchen.de (Postfix) with ESMTP id 0AFF72391C7; Thu, 9 Apr 2009 11:02:06 +0200 (CEST) Received: from 212.202.40.56 (SquirrelMail authenticated user bkoenig) by webmail.alpha-tierchen.de with HTTP; Thu, 9 Apr 2009 11:02:06 +0200 (CEST) Message-ID: In-Reply-To: <20090409072309.GF37714@michelle.cdnetworks.co.kr> References: <70ba25e4f1a5e43ab8d99b361235dda2.squirrel@webmail.alpha-tierchen.de> <20090409000427.GD37714@michelle.cdnetworks.co.kr> <2f68678165f20f2e1dae10cb0e63761d.squirrel@webmail.alpha-tierchen.de> <20090409072309.GF37714@michelle.cdnetworks.co.kr> Date: Thu, 9 Apr 2009 11:02:06 +0200 (CEST) From: "Bjoern Koenig" To: pyunyh@gmail.com User-Agent: SquirrelMail/1.4.17 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: stable@freebsd.org Subject: Re: fxp: stalled transfers X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 09:02:07 -0000 pyunyh@gmail.com wrote: > If you can easily reproduce the issue, can you capture stalled TCP > session with tcpdump on receiving host?(Make sure to disable Rx > checksum offload prior to capturing the session.) I transferred a 256 kiB file and these are the tcpdumps: http://www.alpha-tierchen.de/~bkoenig/fxp0-with-tso.txt http://www.alpha-tierchen.de/~bkoenig/fxp0-without-tso.txt Actually the transfer doesn't stall although ftp and scp told me so. It becomes incredibly slow. It seems like that the chunks are too large and a smaller packet will be resent. I decreased the MTU from 1500 to 1492 and it works fine with TSO enabled. I also captured the traffic on my router: http://www.alpha-tierchen.de/~bkoenig/fxp0-with-tso-router.txt http://www.alpha-tierchen.de/~bkoenig/fxp0-without-tso-router.txt It reveals a suspect information: "truncated-ip - 8 bytes missing!" I almost suppose that this is a PPPoE-related configuration issue and the fxp driver is not necessarily the problem since decreasing the MTU of the LAN host solves it. Björn From owner-freebsd-stable@FreeBSD.ORG Thu Apr 9 10:55:31 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 440B5106568F for ; Thu, 9 Apr 2009 10:55:31 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id B2CC68FC1A for ; Thu, 9 Apr 2009 10:55:28 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Lrrun-0001Xe-3Y for freebsd-stable@freebsd.org; Thu, 09 Apr 2009 10:55:25 +0000 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 09 Apr 2009 10:55:25 +0000 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 09 Apr 2009 10:55:25 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: Ivan Voras Date: Thu, 09 Apr 2009 12:55:05 +0200 Lines: 44 Message-ID: References: <24AB3B457082F236919D1D72@syn> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigFFFA3FECA7122F260627E802" X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Thunderbird 2.0.0.21 (X11/20090318) In-Reply-To: <24AB3B457082F236919D1D72@syn> X-Enigmail-Version: 0.95.0 Sender: news Subject: Re: FreeBSD and iSCSI for disks. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 10:55:32 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigFFFA3FECA7122F260627E802 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Goran Lowkrantz wrote: > Trying to build 2.1.1 on a CURRENT results in this: > =3D=3D=3D> iscsi/initiator (all) > cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE > -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include > /usr/obj/usr/src/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq > -finline-limit=3D8000 --param inline-unit-growth=3D100 --param > large-function-growth=3D1000 -fno-common -g -fno-omit-frame-pointer > -I/usr/obj/usr/src/sys/GENERIC -mcmodel=3Dkernel -mno-red-zone=20 > -mfpmath=3D387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow=20 > -msoft-float -fno-asynchronous-unwind-tables -ffreestanding > -fstack-protector -std=3Diso9899:1999 -fstack-protector -Wall > -Wredundant-decls -Wnested-externs -Wstrict-prototypes=20 > -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef > -Wno-pointer-sign -fformat-extensions -c > /usr/src/sys/modules/iscsi/initiator/../../../dev/iscsi/initiator/iscsi= =2Ec > /usr/src/sys/modules/iscsi/initiator/../../../dev/iscsi/initiator/iscsi= =2Ec: Passed on 7-STABLE amd64. --------------enigFFFA3FECA7122F260627E802 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJ3dQSldnAQVacBcgRAl8MAKDax7JNFWP2drk5gb/NHhj7c/xf8wCeNL2t q/qqs76ARdMBczcY1NSFcYs= =E5E1 -----END PGP SIGNATURE----- --------------enigFFFA3FECA7122F260627E802-- From owner-freebsd-stable@FreeBSD.ORG Thu Apr 9 10:57:32 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B05A8106564A for ; Thu, 9 Apr 2009 10:57:32 +0000 (UTC) (envelope-from piotr.smyrak@heron.pl) Received: from sys.heron.com.pl (mail.heron.pl [89.174.255.19]) by mx1.freebsd.org (Postfix) with ESMTP id 6F22A8FC15 for ; Thu, 9 Apr 2009 10:57:32 +0000 (UTC) (envelope-from piotr.smyrak@heron.pl) Received: from [127.0.0.1] (helo=poczta.heron.pl) by sys.heron.com.pl with esmtp (Exim 4.69) (envelope-from ) id 1Lrrwo-0008pA-4w; Thu, 09 Apr 2009 12:57:30 +0200 From: piotr.smyrak@heron.pl To: Martin Date: Thu, 9 Apr 2009 12:57:30 +0200 Message-Id: <20090409104532.M16424@heron.pl> In-Reply-To: <20090408224925.3dd1f8ab@zelda.local> References: <20090408190805.GA1368@smyrak.com> <20090408224925.3dd1f8ab@zelda.local> X-Mailer: WebMail at HERON 2.52 20060502 X-OriginatingIP: 217.153.67.210 (smyru) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Cc: freebsd-stable@freebsd.org Subject: Re: no USB mice detected on GA-MA74GM-S2 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 10:57:33 -0000 On Wed, 8 Apr 2009 22:49:25 +0200, Martin wrote > Am Wed, 8 Apr 2009 21:08:05 +0200 > schrieb Piotr Smyrak : > > > First I started with my old build of 6.2, then upgraded to 6.4 > > STABLE, to finally upgrade to 7.2 PRERELEASE in hope of fixing the > > issue. None of versions gave me USB mouse support. I have tried > > connecting 3 various mice. No luck. The only effect I can achieve > > after connecting a mouse, is a somewhat delayed message on console: > > I have had also problems with recent Gigabyte Mainboards > and USB mice. Something is really broken in this branch. > Unlike you, I could always get my mouse to work by re- > attaching it. You should perhaps take a look at the BIOS > USB settings, so you could get at least the re-attaching > work-around to work. > > BIOS settings that influence the behavior of USB mice are: > - any "legacy USB support" settings > - so-called "BIOS support for USB mice" I have 5 options regarding USB in the BIOS: * OnChip USB controller * USB EHCI controller * USB Keyboard support * USB Mouse support * Legacy USB storage detect Should mention in the original post, I have them all but the first one disabled. I have tried many combinations including disabling the OnChip controller totally. All in vain. > Because -STABLE has been really frustrating, I migrated > all my desktops to -CURRENT that has the new USB-v2 stack. > The USB problems disappeared there. > > I'm overall satisfied with -CURRENT. I've always wanted to > say that FreeBSD developers do a really great job on the > -CURRENT branch. It's running very stable and has plenty > of new features. I know I shouldn't recommend to migrate > to -CURRENT, but I'm almost sure, it runs much better than > every -CURRENT I've seen before and sometimes I have the > impression that it's even nicer than the -STABLE branch. Well, I am not scared by -CURRENT at all, but I was hesitating to upgrade main build since it is after all a moving target and I would like to keep my main work horse as much steady as possible. Thanks for suggestions, -- Piotr Smyrak piotr.smyrak@heron.pl From owner-freebsd-stable@FreeBSD.ORG Thu Apr 9 11:01:14 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D9B1B106564A for ; Thu, 9 Apr 2009 11:01:14 +0000 (UTC) (envelope-from piotr.smyrak@heron.pl) Received: from sys.heron.com.pl (mail.heron.pl [89.174.255.19]) by mx1.freebsd.org (Postfix) with ESMTP id 97FB88FC08 for ; Thu, 9 Apr 2009 11:01:14 +0000 (UTC) (envelope-from piotr.smyrak@heron.pl) Received: from [127.0.0.1] (helo=poczta.heron.pl) by sys.heron.com.pl with esmtp (Exim 4.69) (envelope-from ) id 1Lrs0O-0009Fs-RU; Thu, 09 Apr 2009 13:01:12 +0200 From: piotr.smyrak@heron.pl To: Robert Noland Date: Thu, 9 Apr 2009 13:01:12 +0200 Message-Id: <20090409110112.M98284@heron.pl> In-Reply-To: <1239223684.4491.12.camel@balrog.2hip.net> References: <20090408190805.GA1368@smyrak.com> <1239223684.4491.12.camel@balrog.2hip.net> X-Mailer: WebMail at HERON 2.52 20060502 X-OriginatingIP: 217.153.67.210 (smyru) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Cc: freebsd-stable@freebsd.org Subject: Re: no USB mice detected on GA-MA74GM-S2 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 11:01:15 -0000 On Wed, 08 Apr 2009 15:48:04 -0500, Robert Noland wrote > On Wed, 2009-04-08 at 21:08 +0200, Piotr Smyrak wrote: > > > > I recently upgraded my system to newer hardware with motherboard > > GIGABYTE GA-MA74GM-S2 Rev 1.0 with AMD 740G chipset (north bridge) > > and AMD SB700 (south) where USB support is located. Everything > > would be fine except there is no USB mice detection by FreeBSD at > > all. And I am stuck with USB mise since the mobo has no PS/2 port. > > > > First I started with my old build of 6.2, then upgraded to 6.4 > > STABLE, to finally upgrade to 7.2 PRERELEASE in hope of fixing the > > issue. None of versions gave me USB mouse support. I have tried > > connecting 3 various mice. No luck. The only effect I can achieve > > after connecting a mouse, is a somewhat delayed message on console: > > rebuild/reinstall devel/libpciaccess now that you have > updated kernel. I think I was not clear in my first post. My issue is the kernel does not recognizes my USB mice, so I get no /dev/ums* devices at all. I have made a clean install of all my ports after upgrade. Thanks for your suggestion. -- Piotr Smyrak piotr.smyrak@heron.pl From owner-freebsd-stable@FreeBSD.ORG Thu Apr 9 11:44:51 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1B5591065673 for ; Thu, 9 Apr 2009 11:44:51 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 8A0828FC08 for ; Thu, 9 Apr 2009 11:44:50 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Lrsgb-0003N1-MM for freebsd-stable@freebsd.org; Thu, 09 Apr 2009 11:44:49 +0000 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 09 Apr 2009 11:44:49 +0000 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 09 Apr 2009 11:44:49 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: Ivan Voras Date: Thu, 09 Apr 2009 13:44:39 +0200 Lines: 84 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig8335D0C6788A1BCB5C4A4D9D" X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Thunderbird 2.0.0.21 (X11/20090318) In-Reply-To: X-Enigmail-Version: 0.95.0 Sender: news Subject: Re: FreeBSD and iSCSI for disks. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 11:44:51 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig8335D0C6788A1BCB5C4A4D9D Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Danny Braniss wrote: >> This is an OpenPGP/MIME signed message (RFC 2440 and 3156) >> --------------enig90DADA8437A99D893FB775F8 >> Content-Type: text/plain; charset=3DUTF-8 >> Content-Transfer-Encoding: quoted-printable >> >> Danny Braniss wrote: >>>> Garance A Drosihn wrote: >>>>> Some friends of mine are looking at the new "DroboPro", which makes= a=3D >>>>> lot of disk space available via iSCSI (in addition to firewire 800)= , >>>>> and they were wondering how well iSCSI works with FreeBSD. I haven= 't=3D >>>>> paid attention to iSCSI support. Is there anyone using it heavily >>>>> for disk-storage under FreeBSD? Has there been much changed for >>>>> iSCSI support in the 8.x branch, or is 7.x support working fine? >>>> I suppose you are interested in the "client" (initiator) side of iSC= SI=3D >>>> support. It hasn't changed much between 7.x and 8.x but there are >>>> apparently some announcements of a newer version: >>>> >>>> http://lists.freebsd.org/pipermail/freebsd-scsi/2009-March/003834.ht= ml=3D >>>> I can't find any more information on it. >>> the latest is in: >>> http://www.cs.huji.ac.il/~danny/ftp/freebsd/iscsi-2.1.1.tar.gz >> Thanks! >> >> Is there anything in particular you'd like to get tested in the new >> version, any significant changes or improvements? > mainly fixed some bugs, and some code cleanup. >=20 > give it a spin, and let me know what target you are testing. > btw, the default tag opening is a bit concervative (1), you might want = to > change it to somewhat larger, say 64 or 128. Hi, "camcontrol tags" hangs: Apr 9 15:36:36 terminator kernel: da3 at iscsi0 bus 0 target 1 lun 0 Apr 9 15:36:36 terminator kernel: da3: Fixed Direct Access SCSI-5 device Apr 9 15:36:38 terminator kernel: (da2:iscsi0:0:0:0): lost device Apr 9 15:36:38 terminator kernel: (da2:iscsi0:0:0:0): removing device en= try terminator:~ivoras/temp/sbin/iscontrol# ls /dev/da* /dev/da0 /dev/da0s1 /dev/da0s1a /dev/da0s1b /dev/da0s1c /dev/da1 /dev/da3 terminator:~ivoras/temp/sbin/iscontrol# camcontrol tags da3 The configuration is: target0 { targetaddress =3D 161.53.72.65 targetname =3D iqn.2007-09.jp.ne.peach:disk1 tags =3D 16 } --------------enig8335D0C6788A1BCB5C4A4D9D Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJ3d+nldnAQVacBcgRAnb/AJ9t0eh5zH5MUfZcBF4OMqIqIw3HRACfYbQ2 7HCFCIMP6H0TBOhfN51KE24= =w9pb -----END PGP SIGNATURE----- --------------enig8335D0C6788A1BCB5C4A4D9D-- From owner-freebsd-stable@FreeBSD.ORG Thu Apr 9 11:50:05 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ED8EA1065686 for ; Thu, 9 Apr 2009 11:50:05 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 68C378FC08 for ; Thu, 9 Apr 2009 11:50:05 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from root by ciao.gmane.org with local (Exim 4.43) id 1Lrsle-0003Zw-Os for freebsd-stable@freebsd.org; Thu, 09 Apr 2009 11:50:02 +0000 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 09 Apr 2009 11:50:02 +0000 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 09 Apr 2009 11:50:02 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: Ivan Voras Date: Thu, 09 Apr 2009 13:47:44 +0200 Lines: 56 Message-ID: References: <2C0AE775-B15B-4B56-A915-6E126F25C8B0@inoc.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig44ECF0E9E8C2ED92BC8DA58D" X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Thunderbird 2.0.0.21 (X11/20090318) In-Reply-To: <2C0AE775-B15B-4B56-A915-6E126F25C8B0@inoc.net> X-Enigmail-Version: 0.95.0 Sender: news Subject: Re: FreeBSD and iSCSI for disks. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 11:50:06 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig44ECF0E9E8C2ED92BC8DA58D Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Robert Blayzor wrote: > On Apr 7, 2009, at 5:43 PM, Garance A Drosihn wrote: >> Some friends of mine are looking at the new "DroboPro", which makes a >> lot of disk space available via iSCSI (in addition to firewire 800), >> and they were wondering how well iSCSI works with FreeBSD. I haven't >> paid attention to iSCSI support. Is there anyone using it heavily >> for disk-storage under FreeBSD? Has there been much changed for >> iSCSI support in the 8.x branch, or is 7.x support working fine? >=20 >=20 >=20 > If you're looking for "production ready" iSCSI initiator support in > FreeBSD, do yourself a favor, save some time, and look into something > else. Seriously, we went down this road just recently testing both > FreeBSD 7.0/7.1 amd64 on various Dell servers with Intel (em) Gig-E > NIC's and it was very easy to basically get the box to lock up solid > and/or panic. Our targets were both Netapp and Equallogic iSCSI SAN's.= =20 > We didn't have a lot of time to debug it, our setup was pretty simple..= > yet when we tried to run various simulated real world load on it the > boxes just caved. Even with jumbo frames enabled on the NIC's the > performance was mediocre at best. Unfortunately due a time constraint > we had to move the clients to CentOS 5.2/5.3 and things have been very > good so far. I was hoping that FreeBSD's iSCSI support was a bit more > solid, or at least hoping that the (isp) driver had support for the > QLogic iSCSI HBA's... no luck. I have a feeling this is because the ISCSI initiator in FreeBSD hasn't been updated since 2007. There have been patches and new development but nothing committed and/or MFC-ed. I'm just starting to evaluate it, so I can't say anything about its stability yet. --------------enig44ECF0E9E8C2ED92BC8DA58D Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJ3eBgldnAQVacBcgRAr7CAJ9jxfzTivXyXPDbco/Cex/OAvng/QCdEyEv CLCPUMOVCwz/n0YI1ascJVU= =olFs -----END PGP SIGNATURE----- --------------enig44ECF0E9E8C2ED92BC8DA58D-- From owner-freebsd-stable@FreeBSD.ORG Thu Apr 9 06:49:07 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 48C2310656ED for ; Thu, 9 Apr 2009 06:49:07 +0000 (UTC) (envelope-from freegih@gmail.com) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.187]) by mx1.freebsd.org (Postfix) with ESMTP id BF9DC8FC0A for ; Thu, 9 Apr 2009 06:49:05 +0000 (UTC) (envelope-from freegih@gmail.com) Received: by ti-out-0910.google.com with SMTP id u5so445768tia.3 for ; Wed, 08 Apr 2009 23:49:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:content-type; bh=CVGZI+NKJWPrNontksav4ngRZO3xhLoyAOgMMCDNG1Y=; b=dssFxi43Mh4aA7dagzKZu4/7tIpOENScX3GcQuTinqQ3/IEJPO7+37+XkbSwvoXuJO HjFHcYDpdZACLpU2H6SjhZgHBgWKx+w4+3CzWl/WTO5lz4gsR2IkLPEhi76scfdJK9Nu pUUDa5vgS9DMADSi3nq6GBkWiUn+4yomBR7YE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type; b=W2ohH8RN14KPXtasdHXTW5vYybuJ2tSeu/Ny0qECfGioxocPCgJokfLma1IEketWtm mjKm38VD1Ye0ZMhVhInov94DwduQ7DzRp1FHf8kl/76hlXFEcXaVRHfT4zG9RhD9fvZP /txqp1/dYaewjJXabF/tzuC/1oTsCh7HKB49U= Received: by 10.110.47.9 with SMTP id u9mr2881010tiu.54.1239258525222; Wed, 08 Apr 2009 23:28:45 -0700 (PDT) Received: from lix.xil ([58.61.214.65]) by mx.google.com with ESMTPS id 22sm49347tim.24.2009.04.08.23.28.36 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 08 Apr 2009 23:28:42 -0700 (PDT) Message-ID: <49DD95EB.9040606@gmail.com> Date: Thu, 09 Apr 2009 14:30:03 +0800 From: GOD User-Agent: Thunderbird 2.0.0.21 (X11/20090407) MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: multipart/mixed; boundary="------------050905040006050702000601" X-Mailman-Approved-At: Thu, 09 Apr 2009 12:07:45 +0000 Subject: system report 7.2 beta1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 06:49:07 -0000 This is a multi-part message in MIME format. --------------050905040006050702000601 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit I trace all of 7.* version on my laptop. But some thing is always a problem! 1. The acpi is not well supported. I try acpiconf -s 3 , the system will die. 2 The ath0 wifi support, I test and nerver find it can transfer with more than 5MB per second rate. 3 The big problem of my laptop is the intel video card, xorg eat up half of my memory,and it's very slow moving windows . Please check my log in attachments! And please tell me any more testing infomation you want ?! --------------050905040006050702000601 Content-Type: text/plain; name="dmesg.txt" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="dmesg.txt" Q29weXJpZ2h0IChjKSAxOTkyLTIwMDkgVGhlIEZyZWVCU0QgUHJvamVjdC4KQ29weXJpZ2h0 IChjKSAxOTc5LCAxOTgwLCAxOTgzLCAxOTg2LCAxOTg4LCAxOTg5LCAxOTkxLCAxOTkyLCAx OTkzLCAxOTk0CglUaGUgUmVnZW50cyBvZiB0aGUgVW5pdmVyc2l0eSBvZiBDYWxpZm9ybmlh LiBBbGwgcmlnaHRzIHJlc2VydmVkLgpGcmVlQlNEIGlzIGEgcmVnaXN0ZXJlZCB0cmFkZW1h cmsgb2YgVGhlIEZyZWVCU0QgRm91bmRhdGlvbi4KRnJlZUJTRCA3LjItUFJFUkVMRUFTRSAj MTogVHVlIEFwciAgNyAxMjozOTo0NiBDU1QgMjAwOQogICAgcm9vdEBsdm0ubmV0Oi91c3Iv b2JqL3Vzci9zcmMvc3lzL2tlcm5lbApUaW1lY291bnRlciAiaTgyNTQiIGZyZXF1ZW5jeSAx MTkzMTgyIEh6IHF1YWxpdHkgMApDUFU6IEludGVsKFIpIENvcmUoVE0pMiBEdW8gQ1BVICAg ICBUNTY3MCAgQCAxLjgwR0h6ICgxNzk1LjUxLU1IeiA2ODYtY2xhc3MgQ1BVKQogIE9yaWdp biA9ICJHZW51aW5lSW50ZWwiICBJZCA9IDB4NmZkICBTdGVwcGluZyA9IDEzCiAgRmVhdHVy ZXM9MHhiZmViZmJmZjxGUFUsVk1FLERFLFBTRSxUU0MsTVNSLFBBRSxNQ0UsQ1g4LEFQSUMs U0VQLE1UUlIsUEdFLE1DQSxDTU9WLFBBVCxQU0UzNixDTEZMVVNILERUUyxBQ1BJLE1NWCxG WFNSLFNTRSxTU0UyLFNTLEhUVCxUTSxQQkU+CiAgRmVhdHVyZXMyPTB4ZTM5ZDxTU0UzLERU RVM2NCxNT04sRFNfQ1BMLEVTVCxUTTIsU1NTRTMsQ1gxNix4VFBSLFBEQ00+CiAgQU1EIEZl YXR1cmVzPTB4MjAxMDAwMDA8TlgsTE0+CiAgQU1EIEZlYXR1cmVzMj0weDE8TEFIRj4KICBD b3JlcyBwZXIgcGFja2FnZTogMgpyZWFsIG1lbW9yeSAgPSAxMDM3NzYyNTYwICg5ODkgTUIp CmF2YWlsIG1lbW9yeSA9IDEwMDExODExODQgKDk1NCBNQikKQUNQSSBBUElDIFRhYmxlOiA8 TEVOT1ZPIFRQLTZBICAgPgpGcmVlQlNEL1NNUDogTXVsdGlwcm9jZXNzb3IgU3lzdGVtIERl dGVjdGVkOiAyIENQVXMKIGNwdTAgKEJTUCk6IEFQSUMgSUQ6ICAwCiBjcHUxIChBUCk6IEFQ SUMgSUQ6ICAxCmlvYXBpYzAgPFZlcnNpb24gMi4wPiBpcnFzIDAtMjMgb24gbW90aGVyYm9h cmQKa2JkMSBhdCBrYmRtdXgwCmFjcGkwOiA8TEVOT1ZPIFRQLTZBPiBvbiBtb3RoZXJib2Fy ZAphY3BpMDogW0lUSFJFQURdCmFjcGlfZWMwOiA8RW1iZWRkZWQgQ29udHJvbGxlcjogR1BF IDB4MWIsIEVDRFQ+IHBvcnQgMHg2MiwweDY2IG9uIGFjcGkwCmFjcGkwOiBQb3dlciBCdXR0 b24gKGZpeGVkKQp1bmtub3duOiBJL08gcmFuZ2Ugbm90IHN1cHBvcnRlZAp1bmtub3duOiBJ L08gcmFuZ2Ugbm90IHN1cHBvcnRlZAp1bmtub3duOiBJL08gcmFuZ2Ugbm90IHN1cHBvcnRl ZAp1bmtub3duOiBJL08gcmFuZ2Ugbm90IHN1cHBvcnRlZAp1bmtub3duOiBJL08gcmFuZ2Ug bm90IHN1cHBvcnRlZAp1bmtub3duOiBJL08gcmFuZ2Ugbm90IHN1cHBvcnRlZAphY3BpMDog cmVzZXJ2YXRpb24gb2YgMCwgYTAwMDAgKDMpIGZhaWxlZAphY3BpMDogcmVzZXJ2YXRpb24g b2YgMTAwMDAwLCAzZGQwMDAwMCAoMykgZmFpbGVkClRpbWVjb3VudGVyICJBQ1BJLWZhc3Qi IGZyZXF1ZW5jeSAzNTc5NTQ1IEh6IHF1YWxpdHkgMTAwMAphY3BpX3RpbWVyMDogPDI0LWJp dCB0aW1lciBhdCAzLjU3OTU0NU1Iej4gcG9ydCAweDgwOC0weDgwYiBvbiBhY3BpMAphY3Bp X2hwZXQwOiA8SGlnaCBQcmVjaXNpb24gRXZlbnQgVGltZXI+IGlvbWVtIDB4ZmVkMDAwMDAt MHhmZWQwMDNmZiBvbiBhY3BpMApUaW1lY291bnRlciAiSFBFVCIgZnJlcXVlbmN5IDE0MzE4 MTgwIEh6IHF1YWxpdHkgOTAwCnBjaWIwOiA8QUNQSSBIb3N0LVBDSSBicmlkZ2U+IHBvcnQg MHhjZjgtMHhjZmYgb24gYWNwaTAKcGNpMDogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjAKdmdh cGNpMDogPFZHQS1jb21wYXRpYmxlIGRpc3BsYXk+IHBvcnQgMHg1YzAwLTB4NWMwNyBtZW0g MHhkMDAwMDAwMC0weGRmZmZmZmZmIGlycSAxNiBhdCBkZXZpY2UgMi4wIG9uIHBjaTAKYWdw MDogPEludGVsIEdNNDUgU1ZHQSBjb250cm9sbGVyPiBvbiB2Z2FwY2kwCmFncDA6IGRldGVj dGVkIDMyNzY0ayBzdG9sZW4gbWVtb3J5CmFncDA6IGFwZXJ0dXJlIHNpemUgaXMgMjU2TQph Y3BpX3ZpZGVvMDogPEFDUEkgdmlkZW8gZXh0ZW5zaW9uPiBvbiB2Z2FwY2kwCmRybTA6IDxN b2JpbGUgSW50ZWxcTS1CXE0tLiBHTTQ1IEV4cHJlc3MgQ2hpcHNldD4gb24gdmdhcGNpMAp2 Z2FwY2kwOiBjaGlsZCBkcm0wIHJlcXVlc3RlZCBwY2lfZW5hYmxlX2J1c21hc3RlcgppbmZv OiBbZHJtXSBBR1AgYXQgMHhkMDAwMDAwMCAyNTZNQgppbmZvOiBbZHJtXSBJbml0aWFsaXpl ZCBpOTE1IDEuNi4wIDIwMDgwNzMwCnZnYXBjaTE6IDxWR0EtY29tcGF0aWJsZSBkaXNwbGF5 PiBhdCBkZXZpY2UgMi4xIG9uIHBjaTAKdWhjaTA6IDxVSENJIChnZW5lcmljKSBVU0IgY29u dHJvbGxlcj4gcG9ydCAweDU4ODAtMHg1ODlmIGlycSAxNiBhdCBkZXZpY2UgMjYuMCBvbiBw Y2kwCnVoY2kwOiBbR0lBTlQtTE9DS0VEXQp1aGNpMDogW0lUSFJFQURdCnVzYjA6IDxVSENJ IChnZW5lcmljKSBVU0IgY29udHJvbGxlcj4gb24gdWhjaTAKdXNiMDogVVNCIHJldmlzaW9u IDEuMAp1aHViMDogPEludGVsIFVIQ0kgcm9vdCBodWIsIGNsYXNzIDkvMCwgcmV2IDEuMDAv MS4wMCwgYWRkciAxPiBvbiB1c2IwCnVodWIwOiAyIHBvcnRzIHdpdGggMiByZW1vdmFibGUs IHNlbGYgcG93ZXJlZAp1aGNpMTogPFVIQ0kgKGdlbmVyaWMpIFVTQiBjb250cm9sbGVyPiBw b3J0IDB4NTgwMC0weDU4MWYgaXJxIDIxIGF0IGRldmljZSAyNi4xIG9uIHBjaTAKdWhjaTE6 IFtHSUFOVC1MT0NLRURdCnVoY2kxOiBbSVRIUkVBRF0KdXNiMTogPFVIQ0kgKGdlbmVyaWMp IFVTQiBjb250cm9sbGVyPiBvbiB1aGNpMQp1c2IxOiBVU0IgcmV2aXNpb24gMS4wCnVodWIx OiA8SW50ZWwgVUhDSSByb290IGh1YiwgY2xhc3MgOS8wLCByZXYgMS4wMC8xLjAwLCBhZGRy IDE+IG9uIHVzYjEKdWh1YjE6IDIgcG9ydHMgd2l0aCAyIHJlbW92YWJsZSwgc2VsZiBwb3dl cmVkCnVoY2kyOiA8VUhDSSAoZ2VuZXJpYykgVVNCIGNvbnRyb2xsZXI+IHBvcnQgMHg1NDgw LTB4NTQ5ZiBpcnEgMTkgYXQgZGV2aWNlIDI2LjIgb24gcGNpMAp1aGNpMjogW0dJQU5ULUxP Q0tFRF0KdWhjaTI6IFtJVEhSRUFEXQp1c2IyOiA8VUhDSSAoZ2VuZXJpYykgVVNCIGNvbnRy b2xsZXI+IG9uIHVoY2kyCnVzYjI6IFVTQiByZXZpc2lvbiAxLjAKdWh1YjI6IDxJbnRlbCBV SENJIHJvb3QgaHViLCBjbGFzcyA5LzAsIHJldiAxLjAwLzEuMDAsIGFkZHIgMT4gb24gdXNi Mgp1aHViMjogMiBwb3J0cyB3aXRoIDIgcmVtb3ZhYmxlLCBzZWxmIHBvd2VyZWQKZWhjaTA6 IDxFSENJIChnZW5lcmljKSBVU0IgMi4wIGNvbnRyb2xsZXI+IG1lbSAweGZlMGZiYzAwLTB4 ZmUwZmJmZmYgaXJxIDE4IGF0IGRldmljZSAyNi43IG9uIHBjaTAKZWhjaTA6IFtHSUFOVC1M T0NLRURdCmVoY2kwOiBbSVRIUkVBRF0KdXNiMzogRUhDSSB2ZXJzaW9uIDEuMAp1c2IzOiBj b21wYW5pb24gY29udHJvbGxlcnMsIDIgcG9ydHMgZWFjaDogdXNiMCB1c2IxIHVzYjIKdXNi MzogPEVIQ0kgKGdlbmVyaWMpIFVTQiAyLjAgY29udHJvbGxlcj4gb24gZWhjaTAKdXNiMzog VVNCIHJldmlzaW9uIDIuMAp1aHViMzogPEludGVsIEVIQ0kgcm9vdCBodWIsIGNsYXNzIDkv MCwgcmV2IDIuMDAvMS4wMCwgYWRkciAxPiBvbiB1c2IzCnVodWIzOiA2IHBvcnRzIHdpdGgg NiByZW1vdmFibGUsIHNlbGYgcG93ZXJlZApoZGFjMDogPEludGVsIDgyODAxSSBIaWdoIERl ZmluaXRpb24gQXVkaW8gQ29udHJvbGxlcj4gbWVtIDB4ZmUwZjQwMDAtMHhmZTBmN2ZmZiBp cnEgMjIgYXQgZGV2aWNlIDI3LjAgb24gcGNpMApoZGFjMDogSERBIERyaXZlciBSZXZpc2lv bjogMjAwOTAzMjlfMDEzMQpoZGFjMDogW0lUSFJFQURdCnBjaWIxOiA8QUNQSSBQQ0ktUENJ IGJyaWRnZT4gaXJxIDE2IGF0IGRldmljZSAyOC4wIG9uIHBjaTAKcGNpMTogPEFDUEkgUENJ IGJ1cz4gb24gcGNpYjEKcGNpYjI6IDxBQ1BJIFBDSS1QQ0kgYnJpZGdlPiBpcnEgMTcgYXQg ZGV2aWNlIDI4LjEgb24gcGNpMApwY2kyOiA8QUNQSSBQQ0kgYnVzPiBvbiBwY2liMgphdGgw OiA8QXRoZXJvcyA1NDI0LzI0MjQ+IGlycSAxNyBhdCBkZXZpY2UgMC4wIG9uIHBjaTIKYXRo MDogW0lUSFJFQURdCmF0aDA6IFdBUk5JTkc6IHVzaW5nIG9ic29sZXRlZCBpZl93YXRjaGRv ZyBpbnRlcmZhY2UKYXRoMDogRXRoZXJuZXQgYWRkcmVzczogMDA6MjM6NGQ6ZGM6MzE6ZDMK YXRoMDogbWFjIDE0LjIgcGh5IDcuMCByYWRpbyAxMC4yCnBjaWIzOiA8QUNQSSBQQ0ktUENJ IGJyaWRnZT4gaXJxIDE4IGF0IGRldmljZSAyOC4yIG9uIHBjaTAKcGNpMzogPEFDUEkgUENJ IGJ1cz4gb24gcGNpYjMKcGNpYjQ6IDxBQ1BJIFBDSS1QQ0kgYnJpZGdlPiBpcnEgMTkgYXQg ZGV2aWNlIDI4LjMgb24gcGNpMApwY2kxMjogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjQKcmUw OiA8UmVhbFRlayA4MTY4LzgxNjhCLzgxNjhDLzgxNjhDUC84MTY4RC84MTExQi84MTExQy84 MTExQ1AgUENJZSBHaWdhYml0IEV0aGVybmV0PiBwb3J0IDB4ZTgwMC0weGU4ZmYgbWVtIDB4 ZmNmZmYwMDAtMHhmY2ZmZmZmZiwweGZjZmUwMDAwLTB4ZmNmZWZmZmYgaXJxIDE5IGF0IGRl dmljZSAwLjAgb24gcGNpMTIKcmUwOiBVc2luZyAxIE1TSSBtZXNzYWdlcwpyZTA6IENoaXAg cmV2LiAweDNjMDAwMDAwCnJlMDogTUFDIHJldi4gMHgwMDQwMDAwMAptaWlidXMwOiA8TUlJ IGJ1cz4gb24gcmUwCnJnZXBoeTA6IDxSVEw4MTY5Uy84MTEwUy84MjExQiBtZWRpYSBpbnRl cmZhY2U+IFBIWSAxIG9uIG1paWJ1czAKcmdlcGh5MDogIDEwYmFzZVQsIDEwYmFzZVQtRkRY LCAxMDBiYXNlVFgsIDEwMGJhc2VUWC1GRFgsIDEwMDBiYXNlVCwgMTAwMGJhc2VULUZEWCwg YXV0bwpyZTA6IEV0aGVybmV0IGFkZHJlc3M6IDAwOjIyOjE1OmIxOjZmOmIyCnJlMDogW0ZJ TFRFUl0KdWhjaTM6IDxVSENJIChnZW5lcmljKSBVU0IgY29udHJvbGxlcj4gcG9ydCAweDU0 MDAtMHg1NDFmIGlycSAyMyBhdCBkZXZpY2UgMjkuMCBvbiBwY2kwCnVoY2kzOiBbR0lBTlQt TE9DS0VEXQp1aGNpMzogW0lUSFJFQURdCnVzYjQ6IDxVSENJIChnZW5lcmljKSBVU0IgY29u dHJvbGxlcj4gb24gdWhjaTMKdXNiNDogVVNCIHJldmlzaW9uIDEuMAp1aHViNDogPEludGVs IFVIQ0kgcm9vdCBodWIsIGNsYXNzIDkvMCwgcmV2IDEuMDAvMS4wMCwgYWRkciAxPiBvbiB1 c2I0CnVodWI0OiAyIHBvcnRzIHdpdGggMiByZW1vdmFibGUsIHNlbGYgcG93ZXJlZAp1aGNp NDogPFVIQ0kgKGdlbmVyaWMpIFVTQiBjb250cm9sbGVyPiBwb3J0IDB4NTA4MC0weDUwOWYg aXJxIDE5IGF0IGRldmljZSAyOS4xIG9uIHBjaTAKdWhjaTQ6IFtHSUFOVC1MT0NLRURdCnVo Y2k0OiBbSVRIUkVBRF0KdXNiNTogPFVIQ0kgKGdlbmVyaWMpIFVTQiBjb250cm9sbGVyPiBv biB1aGNpNAp1c2I1OiBVU0IgcmV2aXNpb24gMS4wCnVodWI1OiA8SW50ZWwgVUhDSSByb290 IGh1YiwgY2xhc3MgOS8wLCByZXYgMS4wMC8xLjAwLCBhZGRyIDE+IG9uIHVzYjUKdWh1YjU6 IDIgcG9ydHMgd2l0aCAyIHJlbW92YWJsZSwgc2VsZiBwb3dlcmVkCnVoY2k1OiA8VUhDSSAo Z2VuZXJpYykgVVNCIGNvbnRyb2xsZXI+IHBvcnQgMHg1MDAwLTB4NTAxZiBpcnEgMTggYXQg ZGV2aWNlIDI5LjIgb24gcGNpMAp1aGNpNTogW0dJQU5ULUxPQ0tFRF0KdWhjaTU6IFtJVEhS RUFEXQp1c2I2OiA8VUhDSSAoZ2VuZXJpYykgVVNCIGNvbnRyb2xsZXI+IG9uIHVoY2k1CnVz YjY6IFVTQiByZXZpc2lvbiAxLjAKdWh1YjY6IDxJbnRlbCBVSENJIHJvb3QgaHViLCBjbGFz cyA5LzAsIHJldiAxLjAwLzEuMDAsIGFkZHIgMT4gb24gdXNiNgp1aHViNjogMiBwb3J0cyB3 aXRoIDIgcmVtb3ZhYmxlLCBzZWxmIHBvd2VyZWQKZWhjaTE6IDxFSENJIChnZW5lcmljKSBV U0IgMi4wIGNvbnRyb2xsZXI+IG1lbSAweGZlMGZiODAwLTB4ZmUwZmJiZmYgaXJxIDIzIGF0 IGRldmljZSAyOS43IG9uIHBjaTAKZWhjaTE6IFtHSUFOVC1MT0NLRURdCmVoY2kxOiBbSVRI UkVBRF0KdXNiNzogRUhDSSB2ZXJzaW9uIDEuMAp1c2I3OiBjb21wYW5pb24gY29udHJvbGxl cnMsIDIgcG9ydHMgZWFjaDogdXNiNCB1c2I1IHVzYjYKdXNiNzogPEVIQ0kgKGdlbmVyaWMp IFVTQiAyLjAgY29udHJvbGxlcj4gb24gZWhjaTEKdXNiNzogVVNCIHJldmlzaW9uIDIuMAp1 aHViNzogPEludGVsIEVIQ0kgcm9vdCBodWIsIGNsYXNzIDkvMCwgcmV2IDIuMDAvMS4wMCwg YWRkciAxPiBvbiB1c2I3CnVodWI3OiA2IHBvcnRzIHdpdGggNiByZW1vdmFibGUsIHNlbGYg cG93ZXJlZApwY2liNTogPEFDUEkgUENJLVBDSSBicmlkZ2U+IGF0IGRldmljZSAzMC4wIG9u IHBjaTAKcGNpMTM6IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWI1CmZ3b2hjaTA6IDwxMzk0IE9w ZW4gSG9zdCBDb250cm9sbGVyIEludGVyZmFjZT4gbWVtIDB4ZmViZmY4MDAtMHhmZWJmZmZm ZiBpcnEgMTYgYXQgZGV2aWNlIDAuMCBvbiBwY2kxMwpmd29oY2kwOiBbRklMVEVSXQpmd29o Y2kwOiBPSENJIHZlcnNpb24gMS4wIChST009MCkKZndvaGNpMDogTm8uIG9mIElzb2Nocm9u b3VzIGNoYW5uZWxzIGlzIDQuCmZ3b2hjaTA6IEVVSTY0IDAwOjA2OjFiOjAwOjAwOjgyOjUx OjRlCmZ3b2hjaTA6IFBoeSAxMzk0YSBhdmFpbGFibGUgUzQwMCwgMSBwb3J0cy4KZndvaGNp MDogTGluayBTNDAwLCBtYXhfcmVjIDIwNDggYnl0ZXMuCmZpcmV3aXJlMDogPElFRUUxMzk0 KEZpcmVXaXJlKSBidXM+IG9uIGZ3b2hjaTAKZndlMDogPEV0aGVybmV0IG92ZXIgRmlyZVdp cmU+IG9uIGZpcmV3aXJlMAppZl9md2UwOiBGYWtlIEV0aGVybmV0IGFkZHJlc3M6IDAyOjA2 OjFiOjgyOjUxOjRlCmZ3ZTA6IEV0aGVybmV0IGFkZHJlc3M6IDAyOjA2OjFiOjgyOjUxOjRl CmZ3aXAwOiA8SVAgb3ZlciBGaXJlV2lyZT4gb24gZmlyZXdpcmUwCmZ3aXAwOiBGaXJld2ly ZSBhZGRyZXNzOiAwMDowNjoxYjowMDowMDo4Mjo1MTo0ZSBAIDB4ZmZmZTAwMDAwMDAwLCBT NDAwLCBtYXhyZWMgMjA0OApzYnAwOiA8U0JQLTIvU0NTSSBvdmVyIEZpcmVXaXJlPiBvbiBm aXJld2lyZTAKZGNvbnNfY3JvbTA6IDxkY29ucyBjb25maWd1cmF0aW9uIFJPTT4gb24gZmly ZXdpcmUwCmRjb25zX2Nyb20wOiBidXNfYWRkciAweDEwNzQwMDAKZndvaGNpMDogSW5pdGlh dGUgYnVzIHJlc2V0CmZ3b2hjaTA6IEJVUyByZXNldApmd29oY2kwOiBub2RlX2lkPTB4Yzgw MGZmYzAsIGdlbj0xLCBDWUNMRU1BU1RFUiBtb2RlCnBjaTEzOiA8YmFzZSBwZXJpcGhlcmFs LCBTRCBob3N0IGNvbnRyb2xsZXI+IGF0IGRldmljZSAwLjEgKG5vIGRyaXZlciBhdHRhY2hl ZCkKcGNpMTM6IDxiYXNlIHBlcmlwaGVyYWw+IGF0IGRldmljZSAwLjIgKG5vIGRyaXZlciBh dHRhY2hlZCkKcGNpMTM6IDxiYXNlIHBlcmlwaGVyYWw+IGF0IGRldmljZSAwLjMgKG5vIGRy aXZlciBhdHRhY2hlZCkKcGNpMTM6IDxiYXNlIHBlcmlwaGVyYWw+IGF0IGRldmljZSAwLjQg KG5vIGRyaXZlciBhdHRhY2hlZCkKaXNhYjA6IDxQQ0ktSVNBIGJyaWRnZT4gYXQgZGV2aWNl IDMxLjAgb24gcGNpMAppc2EwOiA8SVNBIGJ1cz4gb24gaXNhYjAKYXRhcGNpMDogPEludGVs IEFIQ0kgY29udHJvbGxlcj4gcG9ydCAweDRjMDAtMHg0YzA3LDB4NDg4MC0weDQ4ODMsMHg0 ODAwLTB4NDgwNywweDQ0ODAtMHg0NDgzLDB4NDQwMC0weDQ0MWYgbWVtIDB4ZmUwZmIwMDAt MHhmZTBmYjdmZiBpcnEgMTkgYXQgZGV2aWNlIDMxLjIgb24gcGNpMAphdGFwY2kwOiBbSVRI UkVBRF0KYXRhcGNpMDogQUhDSSBWZXJzaW9uIDAxLjIwIGNvbnRyb2xsZXIgd2l0aCA0IHBv cnRzIGRldGVjdGVkCmF0YTI6IDxBVEEgY2hhbm5lbCAwPiBvbiBhdGFwY2kwCmF0YTI6IFtJ VEhSRUFEXQphdGEzOiA8QVRBIGNoYW5uZWwgMT4gb24gYXRhcGNpMAphdGEzOiBbSVRIUkVB RF0KYXRhNDogPEFUQSBjaGFubmVsIDI+IG9uIGF0YXBjaTAKYXRhNDogcG9ydCBub3QgaW1w bGVtZW50ZWQKYXRhNDogW0lUSFJFQURdCmF0YTU6IDxBVEEgY2hhbm5lbCAzPiBvbiBhdGFw Y2kwCmF0YTU6IHBvcnQgbm90IGltcGxlbWVudGVkCmF0YTU6IFtJVEhSRUFEXQphdGE2OiA8 QVRBIGNoYW5uZWwgND4gb24gYXRhcGNpMAphdGE2OiBbSVRIUkVBRF0KYXRhNzogPEFUQSBj aGFubmVsIDU+IG9uIGF0YXBjaTAKYXRhNzogW0lUSFJFQURdCmFjcGlfYnV0dG9uMDogPFNs ZWVwIEJ1dHRvbj4gb24gYWNwaTAKYWNwaV9saWQwOiA8Q29udHJvbCBNZXRob2QgTGlkIFN3 aXRjaD4gb24gYWNwaTAKYWNwaV90ejA6IDxUaGVybWFsIFpvbmU+IG9uIGFjcGkwCmFjcGlf YWNhZDA6IDxBQyBBZGFwdGVyPiBvbiBhY3BpMApiYXR0ZXJ5MDogPEFDUEkgQ29udHJvbCBN ZXRob2QgQmF0dGVyeT4gb24gYWNwaTAKYXRrYmRjMDogPEtleWJvYXJkIGNvbnRyb2xsZXIg KGk4MDQyKT4gcG9ydCAweDYwLDB4NjQgaXJxIDEgb24gYWNwaTAKYXRrYmQwOiA8QVQgS2V5 Ym9hcmQ+IGlycSAxIG9uIGF0a2JkYzAKa2JkMCBhdCBhdGtiZDAKYXRrYmQwOiBbR0lBTlQt TE9DS0VEXQphdGtiZDA6IFtJVEhSRUFEXQpwc20wOiA8UFMvMiBNb3VzZT4gaXJxIDEyIG9u IGF0a2JkYzAKcHNtMDogW0dJQU5ULUxPQ0tFRF0KcHNtMDogW0lUSFJFQURdCnBzbTA6IG1v ZGVsIEdlbmVyaWMgUFMvMiBtb3VzZSwgZGV2aWNlIElEIDAKY3B1MDogPEFDUEkgQ1BVPiBv biBhY3BpMApBQ1BJIFdhcm5pbmcgKHRidXRpbHMtMDI0Myk6IEluY29ycmVjdCBjaGVja3N1 bSBpbiB0YWJsZSBbU1NEVF0gLSAgNEEsIHNob3VsZCBiZSBEOSBbMjAwNzAzMjBdCkFDUEkg V2FybmluZyAodGJ1dGlscy0wMjQzKTogSW5jb3JyZWN0IGNoZWNrc3VtIGluIHRhYmxlIFtB VEtHXSAtICAyQSwgc2hvdWxkIGJlIDY0IFsyMDA3MDMyMF0KZXN0MDogPEVuaGFuY2VkIFNw ZWVkU3RlcCBGcmVxdWVuY3kgQ29udHJvbD4gb24gY3B1MApwNHRjYzA6IDxDUFUgRnJlcXVl bmN5IFRoZXJtYWwgQ29udHJvbD4gb24gY3B1MApjcHUxOiA8QUNQSSBDUFU+IG9uIGFjcGkw CmVzdDE6IDxFbmhhbmNlZCBTcGVlZFN0ZXAgRnJlcXVlbmN5IENvbnRyb2w+IG9uIGNwdTEK ZXN0OiBDUFUgc3VwcG9ydHMgRW5oYW5jZWQgU3BlZWRzdGVwLCBidXQgaXMgbm90IHJlY29n bml6ZWQuCmVzdDogY3B1X3ZlbmRvciBHZW51aW5lSW50ZWwsIG1zciA2MTcwOTI1MDYwMDA5 MjUKZGV2aWNlX2F0dGFjaDogZXN0MSBhdHRhY2ggcmV0dXJuZWQgNgpwNHRjYzE6IDxDUFUg RnJlcXVlbmN5IFRoZXJtYWwgQ29udHJvbD4gb24gY3B1MQpwbXRpbWVyMCBvbiBpc2EwCm9y bTA6IDxJU0EgT3B0aW9uIFJPTT4gYXQgaW9tZW0gMHhjMDAwMC0weGNmN2ZmIHBucGlkIE9S TTAwMDAgb24gaXNhMAphdGEwIGF0IHBvcnQgMHgxZjAtMHgxZjcsMHgzZjYgaXJxIDE0IG9u IGlzYTAKYXRhMDogW0lUSFJFQURdCmF0YTEgYXQgcG9ydCAweDE3MC0weDE3NywweDM3NiBp cnEgMTUgb24gaXNhMAphdGExOiBbSVRIUkVBRF0KcHBjMDogcGFyYWxsZWwgcG9ydCBub3Qg Zm91bmQuCnNjMDogPFN5c3RlbSBjb25zb2xlPiBhdCBmbGFncyAweDEwMCBvbiBpc2EwCnNj MDogVkdBIDwxNiB2aXJ0dWFsIGNvbnNvbGVzLCBmbGFncz0weDMwMD4Kc2lvMDogY29uZmln dXJlZCBpcnEgNCBub3QgaW4gYml0bWFwIG9mIHByb2JlZCBpcnFzIDAKc2lvMDogcG9ydCBt YXkgbm90IGJlIGVuYWJsZWQKc2lvMDogY29uZmlndXJlZCBpcnEgNCBub3QgaW4gYml0bWFw IG9mIHByb2JlZCBpcnFzIDAKc2lvMDogcG9ydCBtYXkgbm90IGJlIGVuYWJsZWQKc2lvMCBh dCBwb3J0IDB4M2Y4LTB4M2ZmIGlycSA0IGZsYWdzIDB4MTAgb24gaXNhMApzaW8wOiB0eXBl IDgyNTAgb3Igbm90IHJlc3BvbmRpbmcKc2lvMDogW0ZJTFRFUl0Kc2lvMTogY29uZmlndXJl ZCBpcnEgMyBub3QgaW4gYml0bWFwIG9mIHByb2JlZCBpcnFzIDAKc2lvMTogcG9ydCBtYXkg bm90IGJlIGVuYWJsZWQKdmdhMDogPEdlbmVyaWMgSVNBIFZHQT4gYXQgcG9ydCAweDNjMC0w eDNkZiBpb21lbSAweGEwMDAwLTB4YmZmZmYgb24gaXNhMApUaW1lY291bnRlcnMgdGljayBl dmVyeSAxLjAwMCBtc2VjCmZpcmV3aXJlMDogMSBub2RlcywgbWF4aG9wIDw9IDAsIGNhYmxl IElSTSA9IDAgKG1lKQpmaXJld2lyZTA6IGJ1cyBtYW5hZ2VyIDAgKG1lKQphZDQ6IDE1MjYy N01CIDxGVUpJVFNVIE1IWjIxNjBCSCBHMSAwMDg0MDAwQT4gYXQgYXRhMi1tYXN0ZXIgU0FU QTE1MAphY2QwOiBDRFJXIDxEVkQvQ0RSVyBVSkRBNzgyL1ZCMjM+IGF0IGF0YTMtbWFzdGVy IFNBVEExNTAKaGRhYzA6IEhEQSBDb2RlYyAjMDogQ29uZXhhbnQgQ1gyMDU2MSAoSGVybW9z YSkKaGRhYzA6IEhEQSBDb2RlYyAjMjogSW50ZWwgRzQ1IEhETUkKcGNtMDogPEhEQSBDb25l eGFudCBDWDIwNTYxIChIZXJtb3NhKSBQQ00gIzAgQW5hbG9nPiBhdCBjYWQgMCBuaWQgMSBv biBoZGFjMApwY20xOiA8SERBIENvbmV4YW50IENYMjA1NjEgKEhlcm1vc2EpIFBDTSAjMSBB bmFsb2c+IGF0IGNhZCAwIG5pZCAxIG9uIGhkYWMwCnBjbTI6IDxIREEgSW50ZWwgRzQ1IEhE TUkgUENNICMwIERpZ2l0YWw+IGF0IGNhZCAyIG5pZCAxIG9uIGhkYWMwClNNUDogQVAgQ1BV ICMxIExhdW5jaGVkIQpUcnlpbmcgdG8gbW91bnQgcm9vdCBmcm9tIHVmczovZGV2L2FkNHMx YQo= --------------050905040006050702000601 Content-Type: text/plain; name="hal-device.txt" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="hal-device.txt" MDogdWRpID0gJy9vcmcvZnJlZWRlc2t0b3AvSGFsL2RldmljZXMvcHNtXzAnCiAgaW5mby51 ZGkgPSAnL29yZy9mcmVlZGVza3RvcC9IYWwvZGV2aWNlcy9wc21fMCcgIChzdHJpbmcpCiAg aW5wdXQuZGV2aWNlID0gJy9kZXYvcHNtMCcgIChzdHJpbmcpCiAgaW5mby5zdWJzeXN0ZW0g PSAncGxhdGZvcm0nICAoc3RyaW5nKQogIGlucHV0LngxMV9kcml2ZXIgPSAnbW91c2UnICAo c3RyaW5nKQogIGluZm8ucHJvZHVjdCA9ICdQUy8yIE1vdXNlJyAgKHN0cmluZykKICBpbmZv LmFkZG9ucyA9IHsgJ2hhbGQtYWRkb24tbW91c2Utc3lzbW91c2UnIH0gKHN0cmluZyBsaXN0 KQogIGZyZWVic2QuZHJpdmVyID0gJ3BzbScgIChzdHJpbmcpCiAgcGxhdGZvcm0uaWQgPSAn cHNtLjAnICAoc3RyaW5nKQogIGZyZWVic2QudW5pdCA9IDAgICgweDApICAoaW50KQogIGlu Zm8ucGFyZW50ID0gJy9vcmcvZnJlZWRlc2t0b3AvSGFsL2RldmljZXMvYXRrYmRjXzAnICAo c3RyaW5nKQogIGZyZWVic2QuZGV2aWNlX2ZpbGUgPSAnL2Rldi9wc20wJyAgKHN0cmluZykK ICBpbmZvLmNhcGFiaWxpdGllcyA9IHsgJ2lucHV0JywgJ2lucHV0Lm1vdXNlJyB9IChzdHJp bmcgbGlzdCkKICBpbmZvLmNhdGVnb3J5ID0gJ2lucHV0Lm1vdXNlJyAgKHN0cmluZykKCjE6 IHVkaSA9ICcvb3JnL2ZyZWVkZXNrdG9wL0hhbC9kZXZpY2VzL3BjbV8wX29zc19taXhlcl8w JwogIG9zcy5kZXZpY2VfZmlsZSA9ICcvZGV2L21peGVyMCcgIChzdHJpbmcpCiAgaW5mby51 ZGkgPSAnL29yZy9mcmVlZGVza3RvcC9IYWwvZGV2aWNlcy9wY21fMF9vc3NfbWl4ZXJfMCcg IChzdHJpbmcpCiAgaW5mby5wcm9kdWN0ID0gJ0hEQSBDb25leGFudCBDWDIwNTYxIChIZXJt b3NhKSBQQ00gIzAgQW5hbG9nIChtaXhlciknICAoc3RyaW5nKQogIG9zcy5vcmlnaW5hdGlu Z19kZXZpY2UgPSAnL29yZy9mcmVlZGVza3RvcC9IYWwvZGV2aWNlcy9wY21fMCcgIChzdHJp bmcpCiAgb3NzLmRldmljZV9pZCA9ICdIREEgQ29uZXhhbnQgQ1gyMDU2MSAoSGVybW9zYSkg UENNICMwIEFuYWxvZyAobWl4ZXIpJyAgKHN0cmluZykKICBvc3MudHlwZSA9ICdtaXhlcicg IChzdHJpbmcpCiAgaW5mby5wYXJlbnQgPSAnL29yZy9mcmVlZGVza3RvcC9IYWwvZGV2aWNl cy9wY21fMCcgIChzdHJpbmcpCiAgb3NzLmNhcmQgPSAwICAoMHgwKSAgKGludCkKICBpbmZv LmNhcGFiaWxpdGllcyA9IHsgJ29zcycgfSAoc3RyaW5nIGxpc3QpCiAgb3NzLmRldmljZSA9 IDAgICgweDApICAoaW50KQogIGluZm8uY2F0ZWdvcnkgPSAnb3NzJyAgKHN0cmluZykKICBv c3MuY2FyZF9pZCA9ICdzbmRfaGRhIFtNUFNBRkVdICgxcDoxdi8xcjoxdiBjaGFubmVscyBk dXBsZXggZGVmYXVsdCknICAoc3RyaW5nKQoKMjogdWRpID0gJy9vcmcvZnJlZWRlc2t0b3Av SGFsL2RldmljZXMvcGNtXzBfb3NzX3BjbV8wJwogIG9zcy5kZXZpY2VfZmlsZSA9ICcvZGV2 L2RzcDAnICAoc3RyaW5nKQogIGluZm8udWRpID0gJy9vcmcvZnJlZWRlc2t0b3AvSGFsL2Rl dmljZXMvcGNtXzBfb3NzX3BjbV8wJyAgKHN0cmluZykKICBpbmZvLnByb2R1Y3QgPSAnSERB IENvbmV4YW50IENYMjA1NjEgKEhlcm1vc2EpIFBDTSAjMCBBbmFsb2cgKHBjbSknICAoc3Ry aW5nKQogIG9zcy5vcmlnaW5hdGluZ19kZXZpY2UgPSAnL29yZy9mcmVlZGVza3RvcC9IYWwv ZGV2aWNlcy9wY21fMCcgIChzdHJpbmcpCiAgb3NzLmRldmljZV9pZCA9ICdIREEgQ29uZXhh bnQgQ1gyMDU2MSAoSGVybW9zYSkgUENNICMwIEFuYWxvZyAocGNtKScgIChzdHJpbmcpCiAg b3NzLnR5cGUgPSAncGNtJyAgKHN0cmluZykKICBpbmZvLnBhcmVudCA9ICcvb3JnL2ZyZWVk ZXNrdG9wL0hhbC9kZXZpY2VzL3BjbV8wJyAgKHN0cmluZykKICBvc3MuY2FyZCA9IDAgICgw eDApICAoaW50KQogIGluZm8uY2FwYWJpbGl0aWVzID0geyAnb3NzJyB9IChzdHJpbmcgbGlz dCkKICBvc3MuZGV2aWNlID0gMCAgKDB4MCkgIChpbnQpCiAgaW5mby5jYXRlZ29yeSA9ICdv c3MnICAoc3RyaW5nKQogIG9zcy5jYXJkX2lkID0gJ3NuZF9oZGEgW01QU0FGRV0gKDFwOjF2 LzFyOjF2IGNoYW5uZWxzIGR1cGxleCBkZWZhdWx0KScgIChzdHJpbmcpCgozOiB1ZGkgPSAn L29yZy9mcmVlZGVza3RvcC9IYWwvZGV2aWNlcy9wY21fMV9vc3NfbWl4ZXJfMScKICBvc3Mu ZGV2aWNlX2ZpbGUgPSAnL2Rldi9taXhlcjEnICAoc3RyaW5nKQogIGluZm8udWRpID0gJy9v cmcvZnJlZWRlc2t0b3AvSGFsL2RldmljZXMvcGNtXzFfb3NzX21peGVyXzEnICAoc3RyaW5n KQogIGluZm8ucHJvZHVjdCA9ICdIREEgQ29uZXhhbnQgQ1gyMDU2MSAoSGVybW9zYSkgUENN ICMxIEFuYWxvZyAobWl4ZXIpJyAgKHN0cmluZykKICBvc3Mub3JpZ2luYXRpbmdfZGV2aWNl ID0gJy9vcmcvZnJlZWRlc2t0b3AvSGFsL2RldmljZXMvcGNtXzEnICAoc3RyaW5nKQogIG9z cy5kZXZpY2VfaWQgPSAnSERBIENvbmV4YW50IENYMjA1NjEgKEhlcm1vc2EpIFBDTSAjMSBB bmFsb2cgKG1peGVyKScgIChzdHJpbmcpCiAgb3NzLnR5cGUgPSAnbWl4ZXInICAoc3RyaW5n KQogIGluZm8ucGFyZW50ID0gJy9vcmcvZnJlZWRlc2t0b3AvSGFsL2RldmljZXMvcGNtXzEn ICAoc3RyaW5nKQogIG9zcy5jYXJkID0gMSAgKDB4MSkgIChpbnQpCiAgaW5mby5jYXBhYmls aXRpZXMgPSB7ICdvc3MnIH0gKHN0cmluZyBsaXN0KQogIG9zcy5kZXZpY2UgPSAxICAoMHgx KSAgKGludCkKICBpbmZvLmNhdGVnb3J5ID0gJ29zcycgIChzdHJpbmcpCiAgb3NzLmNhcmRf aWQgPSAnc25kX2hkYSBbTVBTQUZFXSAoMXA6MXYvMXI6MXYgY2hhbm5lbHMgZHVwbGV4KScg IChzdHJpbmcpCgo0OiB1ZGkgPSAnL29yZy9mcmVlZGVza3RvcC9IYWwvZGV2aWNlcy9wY21f MV9vc3NfcGNtXzEnCiAgb3NzLmRldmljZV9maWxlID0gJy9kZXYvZHNwMScgIChzdHJpbmcp CiAgaW5mby51ZGkgPSAnL29yZy9mcmVlZGVza3RvcC9IYWwvZGV2aWNlcy9wY21fMV9vc3Nf cGNtXzEnICAoc3RyaW5nKQogIGluZm8ucHJvZHVjdCA9ICdIREEgQ29uZXhhbnQgQ1gyMDU2 MSAoSGVybW9zYSkgUENNICMxIEFuYWxvZyAocGNtKScgIChzdHJpbmcpCiAgb3NzLm9yaWdp bmF0aW5nX2RldmljZSA9ICcvb3JnL2ZyZWVkZXNrdG9wL0hhbC9kZXZpY2VzL3BjbV8xJyAg KHN0cmluZykKICBvc3MuZGV2aWNlX2lkID0gJ0hEQSBDb25leGFudCBDWDIwNTYxIChIZXJt b3NhKSBQQ00gIzEgQW5hbG9nIChwY20pJyAgKHN0cmluZykKICBvc3MudHlwZSA9ICdwY20n ICAoc3RyaW5nKQogIGluZm8ucGFyZW50ID0gJy9vcmcvZnJlZWRlc2t0b3AvSGFsL2Rldmlj ZXMvcGNtXzEnICAoc3RyaW5nKQogIG9zcy5jYXJkID0gMSAgKDB4MSkgIChpbnQpCiAgaW5m by5jYXBhYmlsaXRpZXMgPSB7ICdvc3MnIH0gKHN0cmluZyBsaXN0KQogIG9zcy5kZXZpY2Ug PSAxICAoMHgxKSAgKGludCkKICBpbmZvLmNhdGVnb3J5ID0gJ29zcycgIChzdHJpbmcpCiAg b3NzLmNhcmRfaWQgPSAnc25kX2hkYSBbTVBTQUZFXSAoMXA6MXYvMXI6MXYgY2hhbm5lbHMg ZHVwbGV4KScgIChzdHJpbmcpCgo1OiB1ZGkgPSAnL29yZy9mcmVlZGVza3RvcC9IYWwvZGV2 aWNlcy9wY21fMl9vc3NfbWl4ZXJfMicKICBvc3MuZGV2aWNlX2ZpbGUgPSAnL2Rldi9taXhl cjInICAoc3RyaW5nKQogIGluZm8udWRpID0gJy9vcmcvZnJlZWRlc2t0b3AvSGFsL2Rldmlj ZXMvcGNtXzJfb3NzX21peGVyXzInICAoc3RyaW5nKQogIGluZm8ucHJvZHVjdCA9ICdIREEg SW50ZWwgRzQ1IEhETUkgUENNICMwIERpZ2l0YWwgKG1peGVyKScgIChzdHJpbmcpCiAgb3Nz Lm9yaWdpbmF0aW5nX2RldmljZSA9ICcvb3JnL2ZyZWVkZXNrdG9wL0hhbC9kZXZpY2VzL3Bj bV8yJyAgKHN0cmluZykKICBvc3MuZGV2aWNlX2lkID0gJ0hEQSBJbnRlbCBHNDUgSERNSSBQ Q00gIzAgRGlnaXRhbCAobWl4ZXIpJyAgKHN0cmluZykKICBvc3MudHlwZSA9ICdtaXhlcicg IChzdHJpbmcpCiAgaW5mby5wYXJlbnQgPSAnL29yZy9mcmVlZGVza3RvcC9IYWwvZGV2aWNl cy9wY21fMicgIChzdHJpbmcpCiAgb3NzLmNhcmQgPSAyICAoMHgyKSAgKGludCkKICBpbmZv LmNhcGFiaWxpdGllcyA9IHsgJ29zcycgfSAoc3RyaW5nIGxpc3QpCiAgb3NzLmRldmljZSA9 IDIgICgweDIpICAoaW50KQogIGluZm8uY2F0ZWdvcnkgPSAnb3NzJyAgKHN0cmluZykKICBv c3MuY2FyZF9pZCA9ICdzbmRfaGRhIFtNUFNBRkVdICgxcDoxdi8wcjowdiBjaGFubmVscykn ICAoc3RyaW5nKQoKNjogdWRpID0gJy9vcmcvZnJlZWRlc2t0b3AvSGFsL2RldmljZXMvcGNt XzJfb3NzX3BjbV8yJwogIG9zcy5kZXZpY2VfZmlsZSA9ICcvZGV2L2RzcDInICAoc3RyaW5n KQogIGluZm8udWRpID0gJy9vcmcvZnJlZWRlc2t0b3AvSGFsL2RldmljZXMvcGNtXzJfb3Nz X3BjbV8yJyAgKHN0cmluZykKICBpbmZvLnByb2R1Y3QgPSAnSERBIEludGVsIEc0NSBIRE1J IFBDTSAjMCBEaWdpdGFsIChwY20pJyAgKHN0cmluZykKICBvc3Mub3JpZ2luYXRpbmdfZGV2 aWNlID0gJy9vcmcvZnJlZWRlc2t0b3AvSGFsL2RldmljZXMvcGNtXzInICAoc3RyaW5nKQog IG9zcy5kZXZpY2VfaWQgPSAnSERBIEludGVsIEc0NSBIRE1JIFBDTSAjMCBEaWdpdGFsIChw Y20pJyAgKHN0cmluZykKICBvc3MudHlwZSA9ICdwY20nICAoc3RyaW5nKQogIGluZm8ucGFy ZW50ID0gJy9vcmcvZnJlZWRlc2t0b3AvSGFsL2RldmljZXMvcGNtXzInICAoc3RyaW5nKQog IG9zcy5jYXJkID0gMiAgKDB4MikgIChpbnQpCiAgaW5mby5jYXBhYmlsaXRpZXMgPSB7ICdv c3MnIH0gKHN0cmluZyBsaXN0KQogIG9zcy5kZXZpY2UgPSAyICAoMHgyKSAgKGludCkKICBp bmZvLmNhdGVnb3J5ID0gJ29zcycgIChzdHJpbmcpCiAgb3NzLmNhcmRfaWQgPSAnc25kX2hk YSBbTVBTQUZFXSAoMXA6MXYvMHI6MHYgY2hhbm5lbHMpJyAgKHN0cmluZykKCjc6IHVkaSA9 ICcvb3JnL2ZyZWVkZXNrdG9wL0hhbC9kZXZpY2VzL2FjcGlfdmlkZW9fMF9kaXNwbGF5X2Rl dmljZV9sY2RfMCcKICBpbmZvLnVkaSA9ICcvb3JnL2ZyZWVkZXNrdG9wL0hhbC9kZXZpY2Vz L2FjcGlfdmlkZW9fMF9kaXNwbGF5X2RldmljZV9sY2RfMCcgIChzdHJpbmcpCiAgaW5mby5w cm9kdWN0ID0gJ2xjZCcgIChzdHJpbmcpCiAgZGlzcGxheV9kZXZpY2UudHlwZSA9ICdsY2Qn ICAoc3RyaW5nKQogIGRpc3BsYXlfZGV2aWNlLmxjZC5icmlnaHRuZXNzID0gMTAwICAoMHg2 NCkgIChpbnQpCiAgZnJlZWJzZC51bml0ID0gMCAgKDB4MCkgIChpbnQpCiAgaW5mby5wYXJl bnQgPSAnL29yZy9mcmVlZGVza3RvcC9IYWwvZGV2aWNlcy9hY3BpX3ZpZGVvXzAnICAoc3Ry aW5nKQogIGluZm8uY2FwYWJpbGl0aWVzID0geyAnZGlzcGxheV9kZXZpY2UnIH0gKHN0cmlu ZyBsaXN0KQogIGluZm8uY2F0ZWdvcnkgPSAnZGlzcGxheV9kZXZpY2UnICAoc3RyaW5nKQoK ODogdWRpID0gJy9vcmcvZnJlZWRlc2t0b3AvSGFsL2RldmljZXMvYWNwaV92aWRlb18wX2Rp c3BsYXlfZGV2aWNlX2NydF8wJwogIGluZm8udWRpID0gJy9vcmcvZnJlZWRlc2t0b3AvSGFs L2RldmljZXMvYWNwaV92aWRlb18wX2Rpc3BsYXlfZGV2aWNlX2NydF8wJyAgKHN0cmluZykK ICBpbmZvLnByb2R1Y3QgPSAnY3J0JyAgKHN0cmluZykKICBkaXNwbGF5X2RldmljZS50eXBl ID0gJ2NydCcgIChzdHJpbmcpCiAgZnJlZWJzZC51bml0ID0gMCAgKDB4MCkgIChpbnQpCiAg aW5mby5wYXJlbnQgPSAnL29yZy9mcmVlZGVza3RvcC9IYWwvZGV2aWNlcy9hY3BpX3ZpZGVv XzAnICAoc3RyaW5nKQogIGluZm8uY2FwYWJpbGl0aWVzID0geyAnZGlzcGxheV9kZXZpY2Un IH0gKHN0cmluZyBsaXN0KQogIGluZm8uY2F0ZWdvcnkgPSAnZGlzcGxheV9kZXZpY2UnICAo c3RyaW5nKQoKOTogdWRpID0gJy9vcmcvZnJlZWRlc2t0b3AvSGFsL2RldmljZXMvc2lvXzBf c2VyaWFsX3BsYXRmb3JtXzAnCiAgc2VyaWFsLmRldmljZSA9ICcvZGV2L3R0eWQwJyAgKHN0 cmluZykKICBpbmZvLnVkaSA9ICcvb3JnL2ZyZWVkZXNrdG9wL0hhbC9kZXZpY2VzL3Npb18w X3NlcmlhbF9wbGF0Zm9ybV8wJyAgKHN0cmluZykKICBzZXJpYWwucG9ydCA9IDAgICgweDAp ICAoaW50KQogIHNlcmlhbC50eXBlID0gJ3BsYXRmb3JtJyAgKHN0cmluZykKICBpbmZvLnBh cmVudCA9ICcvb3JnL2ZyZWVkZXNrdG9wL0hhbC9kZXZpY2VzL3Npb18wJyAgKHN0cmluZykK ICBpbmZvLmNhcGFiaWxpdGllcyA9IHsgJ3NlcmlhbCcgfSAoc3RyaW5nIGxpc3QpCiAgaW5m by5jYXRlZ29yeSA9ICdzZXJpYWwnICAoc3RyaW5nKQogIHNlcmlhbC5vcmlnaW5hdGluZ19k ZXZpY2UgPSAnL29yZy9mcmVlZGVza3RvcC9IYWwvZGV2aWNlcy9zaW9fMCcgIChzdHJpbmcp CgoxMDogdWRpID0gJy9vcmcvZnJlZWRlc2t0b3AvSGFsL2RldmljZXMvbmV0XzAwXzIyXzE1 X2IxXzZmX2IyJwogIGluZm8udWRpID0gJy9vcmcvZnJlZWRlc2t0b3AvSGFsL2RldmljZXMv bmV0XzAwXzIyXzE1X2IxXzZmX2IyJyAgKHN0cmluZykKICBuZXQuaW50ZXJmYWNlX3VwID0g dHJ1ZSAgKGJvb2wpCiAgaW5mby5pbnRlcmZhY2VzID0geyAnb3JnLmZyZWVkZXNrdG9wLkhh bC5EZXZpY2UuV2FrZU9uTGFuJyB9IChzdHJpbmcgbGlzdCkKICBpbmZvLnByb2R1Y3QgPSAn TmV0d29ya2luZyBJbnRlcmZhY2UnICAoc3RyaW5nKQogIG5ldC5waHlzaWNhbF9kZXZpY2Ug PSAnL29yZy9mcmVlZGVza3RvcC9IYWwvZGV2aWNlcy9wY2lfMTBlY184MTY4JyAgKHN0cmlu ZykKICBuZXQuODAyMDMubWFjX2FkZHJlc3MgPSAxNDYzOTI4MzgwNjYgICgweDIyMTViMTZm YjIpICAodWludDY0KQogIG5ldC44MDIwMy5yYXRlID0gMCAgKDB4MCkgICh1aW50NjQpCiAg bmV0LmFkZHJlc3MgPSAnMDA6MjI6MTU6YjE6NmY6YjInICAoc3RyaW5nKQogIG5ldC44MDIw My5saW5rID0gdHJ1ZSAgKGJvb2wpCiAgbmV0LmludGVyZmFjZSA9ICdyZTAnICAoc3RyaW5n KQogIG9yZy5mcmVlZGVza3RvcC5IYWwuRGV2aWNlLldha2VPbkxhbi5tZXRob2RfbmFtZXMg PSB7ICdHZXRTdXBwb3J0ZWQnLCAnR2V0RW5hYmxlZCcsICdTZXRFbmFibGVkJyB9IChzdHJp bmcgbGlzdCkKICBuZXQub3JpZ2luYXRpbmdfZGV2aWNlID0gJy9vcmcvZnJlZWRlc2t0b3Av SGFsL2RldmljZXMvcGNpXzEwZWNfODE2OCcgIChzdHJpbmcpCiAgb3JnLmZyZWVkZXNrdG9w LkhhbC5EZXZpY2UuV2FrZU9uTGFuLm1ldGhvZF9zaWduYXR1cmVzID0geyAnJywgJycsICdi JyB9IChzdHJpbmcgbGlzdCkKICBpbmZvLnBhcmVudCA9ICcvb3JnL2ZyZWVkZXNrdG9wL0hh bC9kZXZpY2VzL3BjaV8xMGVjXzgxNjgnICAoc3RyaW5nKQogIG5ldC5tZWRpYSA9ICdFdGhl cm5ldCBhdXRvc2VsZWN0IChub25lKScgIChzdHJpbmcpCiAgb3JnLmZyZWVkZXNrdG9wLkhh bC5EZXZpY2UuV2FrZU9uTGFuLm1ldGhvZF9hcmduYW1lcyA9IHsgJycsICcnLCAnZW5hYmxl JyB9IChzdHJpbmcgbGlzdCkKICBpbmZvLmNhcGFiaWxpdGllcyA9IHsgJ25ldCcsICduZXQu ODAyMDMnLCAnd2FrZV9vbl9sYW4nIH0gKHN0cmluZyBsaXN0KQogIG5ldC5hcnBfcHJvdG9f aHdfaWQgPSAxICAoMHgxKSAgKGludCkKICBvcmcuZnJlZWRlc2t0b3AuSGFsLkRldmljZS5X YWtlT25MYW4ubWV0aG9kX2V4ZWNwYXRocyA9IHsgJ2hhbC1zeXN0ZW0td29sLXN1cHBvcnRl ZCcsICdoYWwtc3lzdGVtLXdvbC1lbmFibGVkJywgJ2hhbC1zeXN0ZW0td29sLWVuYWJsZScg fSAoc3RyaW5nIGxpc3QpCiAgbmV0LmZyZWVic2QuaWZpbmRleCA9IDIgICgweDIpICAoaW50 KQogIGluZm8uY2F0ZWdvcnkgPSAnbmV0LjgwMjAzJyAgKHN0cmluZykKCjExOiB1ZGkgPSAn L29yZy9mcmVlZGVza3RvcC9IYWwvZGV2aWNlcy9uZXRfMDBfMjNfNGRfZGNfMzFfZDMnCiAg aW5mby51ZGkgPSAnL29yZy9mcmVlZGVza3RvcC9IYWwvZGV2aWNlcy9uZXRfMDBfMjNfNGRf ZGNfMzFfZDMnICAoc3RyaW5nKQogIG5ldC44MDIxMS5tYWNfYWRkcmVzcyA9IDE1MTYzMDEz MTY2NyAgKDB4MjM0ZGRjMzFkMykgICh1aW50NjQpCiAgbmV0LmludGVyZmFjZV91cCA9IHRy dWUgIChib29sKQogIGluZm8ucHJvZHVjdCA9ICdXTEFOIE5ldHdvcmtpbmcgSW50ZXJmYWNl JyAgKHN0cmluZykKICBuZXQucGh5c2ljYWxfZGV2aWNlID0gJy9vcmcvZnJlZWRlc2t0b3Av SGFsL2RldmljZXMvcGNpXzE2OGNfMDAxYycgIChzdHJpbmcpCiAgbmV0LmFkZHJlc3MgPSAn MDA6MjM6NGQ6ZGM6MzE6ZDMnICAoc3RyaW5nKQogIG5ldC5pbnRlcmZhY2UgPSAnYXRoMCcg IChzdHJpbmcpCiAgbmV0Lm9yaWdpbmF0aW5nX2RldmljZSA9ICcvb3JnL2ZyZWVkZXNrdG9w L0hhbC9kZXZpY2VzL3BjaV8xNjhjXzAwMWMnICAoc3RyaW5nKQogIGluZm8ucGFyZW50ID0g Jy9vcmcvZnJlZWRlc2t0b3AvSGFsL2RldmljZXMvcGNpXzE2OGNfMDAxYycgIChzdHJpbmcp CiAgbmV0Lm1lZGlhID0gJ0lFRUUgODAyLjExIFdpcmVsZXNzIEV0aGVybmV0IGF1dG9zZWxl Y3QgKGF1dG9zZWxlY3QpJyAgKHN0cmluZykKICBpbmZvLmNhcGFiaWxpdGllcyA9IHsgJ25l dCcsICduZXQuODAyMTEnIH0gKHN0cmluZyBsaXN0KQogIG5ldC5hcnBfcHJvdG9faHdfaWQg PSAxICAoMHgxKSAgKGludCkKICBuZXQuZnJlZWJzZC5pZmluZGV4ID0gMSAgKDB4MSkgIChp bnQpCiAgaW5mby5jYXRlZ29yeSA9ICduZXQuODAyMTEnICAoc3RyaW5nKQoKMTI6IHVkaSA9 ICcvb3JnL2ZyZWVkZXNrdG9wL0hhbC9kZXZpY2VzL3N0b3JhZ2Vfc2VyaWFsX0hFNDZfMDA3 MzgwJwogIGJsb2NrLmRldmljZSA9ICcvZGV2L2FjZDAnICAoc3RyaW5nKQogIHN0b3JhZ2Uu Y2Ryb20ud3JpdGVfc3BlZWQgPSA0MjM0ICAoMHgxMDhhKSAgKGludCkKICBibG9jay5tYWpv ciA9IDAgICgweDApICAoaW50KQogIGJsb2NrLm1pbm9yID0gMTA3ICAoMHg2YikgIChpbnQp CiAgc3RvcmFnZS5idXMgPSAnc2F0YScgIChzdHJpbmcpCiAgaW5mby51ZGkgPSAnL29yZy9m cmVlZGVza3RvcC9IYWwvZGV2aWNlcy9zdG9yYWdlX3NlcmlhbF9IRTQ2XzAwNzM4MCcgIChz dHJpbmcpCiAgc3RvcmFnZS5kcml2ZV90eXBlID0gJ2Nkcm9tJyAgKHN0cmluZykKICBmcmVl YnNkLmRyaXZlciA9ICdhY2QnICAoc3RyaW5nKQogIGluZm8uc3Vic3lzdGVtID0gJ2Jsb2Nr JyAgKHN0cmluZykKICBzdG9yYWdlLnJlbW92YWJsZSA9IHRydWUgIChib29sKQogIGZyZWVi c2QudW5pdCA9IDAgICgweDApICAoaW50KQogIGluZm8ucHJvZHVjdCA9ICdEVkQvQ0RSVyBV SkRBNzgyJyAgKHN0cmluZykKICBzdG9yYWdlLnJlcXVpcmVzX2VqZWN0ID0gdHJ1ZSAgKGJv b2wpCiAgc3RvcmFnZS5ob3RwbHVnZ2FibGUgPSBmYWxzZSAgKGJvb2wpCiAgc3RvcmFnZS5t ZWRpYV9jaGVja19lbmFibGVkID0gdHJ1ZSAgKGJvb2wpCiAgc3RvcmFnZS5hdXRvbW91bnRf ZW5hYmxlZF9oaW50ID0gdHJ1ZSAgKGJvb2wpCiAgc3RvcmFnZS5ub19wYXJ0aXRpb25zX2hp bnQgPSB0cnVlICAoYm9vbCkKICBpbmZvLnZlbmRvciA9ICdEVkQvQ0RSVycgIChzdHJpbmcp CiAgc3RvcmFnZS5yZW1vdmFibGUuc3VwcG9ydF9hc3luY19ub3RpZmljYXRpb24gPSBmYWxz ZSAgKGJvb2wpCiAgc3RvcmFnZS5vcmlnaW5hdGluZ19kZXZpY2UgPSAnL29yZy9mcmVlZGVz a3RvcC9IYWwvZGV2aWNlcy9pZGVfM18wJyAgKHN0cmluZykKICBzdG9yYWdlLm1vZGVsID0g J0RWRC9DRFJXIFVKREE3ODInICAoc3RyaW5nKQogIHN0b3JhZ2UudmVuZG9yID0gJ0RWRC9D RFJXJyAgKHN0cmluZykKICBzdG9yYWdlLnNlcmlhbCA9ICdIRTQ2IDAwNzM4MCcgIChzdHJp bmcpCiAgc3RvcmFnZS5maXJtd2FyZV9yZXZpc2lvbiA9ICdWQjIzJyAgKHN0cmluZykKICBi bG9jay5pc192b2x1bWUgPSBmYWxzZSAgKGJvb2wpCiAgZnJlZWJzZC5kZXZpY2VfZmlsZSA9 ICcvZGV2L2FjZDAnICAoc3RyaW5nKQogIGJsb2NrLnN0b3JhZ2VfZGV2aWNlID0gJy9vcmcv ZnJlZWRlc2t0b3AvSGFsL2RldmljZXMvc3RvcmFnZV9zZXJpYWxfSEU0Nl8wMDczODAnICAo c3RyaW5nKQogIHN0b3JhZ2UuY2Ryb20uY2RyID0gdHJ1ZSAgKGJvb2wpCiAgaW5mby5jYXBh YmlsaXRpZXMgPSB7ICdibG9jaycsICdzdG9yYWdlJywgJ3N0b3JhZ2UuY2Ryb20nIH0gKHN0 cmluZyBsaXN0KQogIGluZm8uY2F0ZWdvcnkgPSAnc3RvcmFnZS5jZHJvbScgIChzdHJpbmcp CiAgc3RvcmFnZS5jZHJvbS5jZHJ3ID0gdHJ1ZSAgKGJvb2wpCiAgc3RvcmFnZS5jZHJvbS5k dmQgPSB0cnVlICAoYm9vbCkKICBzdG9yYWdlLmNkcm9tLmR2ZHIgPSBmYWxzZSAgKGJvb2wp CiAgc3RvcmFnZS5jZHJvbS5kdmRydyA9IGZhbHNlICAoYm9vbCkKICBpbmZvLmFkZG9ucyA9 IHsgJ2hhbGQtYWRkb24tc3RvcmFnZScgfSAoc3RyaW5nIGxpc3QpCiAgc3RvcmFnZS5jZHJv bS5kdmRyYW0gPSBmYWxzZSAgKGJvb2wpCiAgc3RvcmFnZS5jZHJvbS5kdmRwbHVzciA9IGZh bHNlICAoYm9vbCkKICBzdG9yYWdlLmNkcm9tLmR2ZHBsdXNydyA9IGZhbHNlICAoYm9vbCkK ICBzdG9yYWdlLmNkcm9tLndyaXRlX3NwZWVkcyA9IHsgJzQyMzQnLCAnMjgyMicsICcxNDEx JywgJzcwNicgfSAoc3RyaW5nIGxpc3QpCiAgaW5mby5pbnRlcmZhY2VzID0geyAnb3JnLmZy ZWVkZXNrdG9wLkhhbC5EZXZpY2UuU3RvcmFnZScsICdvcmcuZnJlZWRlc2t0b3AuSGFsLkRl dmljZS5TdG9yYWdlJywgJ29yZy5mcmVlZGVza3RvcC5IYWwuRGV2aWNlLlN0b3JhZ2UuUmVt b3ZhYmxlJyB9IChzdHJpbmcgbGlzdCkKICBzdG9yYWdlLmNkcm9tLmR2ZHBsdXNyZGwgPSBm YWxzZSAgKGJvb2wpCiAgc3RvcmFnZS5yZW1vdmFibGUubWVkaWFfYXZhaWxhYmxlID0gZmFs c2UgIChib29sKQogIHN0b3JhZ2UuY2Ryb20uZHZkcGx1c3J3ZGwgPSBmYWxzZSAgKGJvb2wp CiAgb3JnLmZyZWVkZXNrdG9wLkhhbC5EZXZpY2UuU3RvcmFnZS5tZXRob2RfbmFtZXMgPSB7 ICdFamVjdCcsICdDbG9zZVRyYXknIH0gKHN0cmluZyBsaXN0KQogIHN0b3JhZ2UuY2Ryb20u YmQgPSBmYWxzZSAgKGJvb2wpCiAgb3JnLmZyZWVkZXNrdG9wLkhhbC5EZXZpY2UuU3RvcmFn ZS5tZXRob2Rfc2lnbmF0dXJlcyA9IHsgJ2FzJywgJ2FzJyB9IChzdHJpbmcgbGlzdCkKICBz dG9yYWdlLmNkcm9tLmJkciA9IGZhbHNlICAoYm9vbCkKICBvcmcuZnJlZWRlc2t0b3AuSGFs LkRldmljZS5TdG9yYWdlLm1ldGhvZF9hcmduYW1lcyA9IHsgJ2V4dHJhX29wdGlvbnMnLCAn ZXh0cmFfb3B0aW9ucycgfSAoc3RyaW5nIGxpc3QpCiAgc3RvcmFnZS5jZHJvbS5iZHJlID0g ZmFsc2UgIChib29sKQogIG9yZy5mcmVlZGVza3RvcC5IYWwuRGV2aWNlLlN0b3JhZ2UubWV0 aG9kX2V4ZWNwYXRocyA9IHsgJ2hhbC1zdG9yYWdlLWVqZWN0JywgJ2hhbC1zdG9yYWdlLWNs b3NldHJheScgfSAoc3RyaW5nIGxpc3QpCiAgc3RvcmFnZS5jZHJvbS5oZGR2ZCA9IGZhbHNl ICAoYm9vbCkKICBpbmZvLnBhcmVudCA9ICcvb3JnL2ZyZWVkZXNrdG9wL0hhbC9kZXZpY2Vz L2lkZV8zXzAnICAoc3RyaW5nKQogIHN0b3JhZ2UuY2Ryb20uaGRkdmRyID0gZmFsc2UgIChi b29sKQogIHN0b3JhZ2UuY2Ryb20uaGRkdmRydyA9IGZhbHNlICAoYm9vbCkKICBzdG9yYWdl LmNkcm9tLnN1cHBvcnRfbWVkaWFfY2hhbmdlZCA9IGZhbHNlICAoYm9vbCkKICBzdG9yYWdl LmNkcm9tLnJlYWRfc3BlZWQgPSA0MjM0ICAoMHgxMDhhKSAgKGludCkKCjEzOiB1ZGkgPSAn L29yZy9mcmVlZGVza3RvcC9IYWwvZGV2aWNlcy9zdG9yYWdlX3NlcmlhbF9LNjBXVDhBMkRH VEInCiAgc3RvcmFnZS5hdXRvbW91bnRfZW5hYmxlZF9oaW50ID0gdHJ1ZSAgKGJvb2wpCiAg aW5mby52ZW5kb3IgPSAnRlVKSVRTVScgIChzdHJpbmcpCiAgaW5mby51ZGkgPSAnL29yZy9m cmVlZGVza3RvcC9IYWwvZGV2aWNlcy9zdG9yYWdlX3NlcmlhbF9LNjBXVDhBMkRHVEInICAo c3RyaW5nKQogIGluZm8uc3Vic3lzdGVtID0gJ2Jsb2NrJyAgKHN0cmluZykKICBzdG9yYWdl Lm5vX3BhcnRpdGlvbnNfaGludCA9IGZhbHNlICAoYm9vbCkKICBibG9jay5kZXZpY2UgPSAn L2Rldi9hZDQnICAoc3RyaW5nKQogIHN0b3JhZ2UucmVtb3ZhYmxlLnN1cHBvcnRfYXN5bmNf bm90aWZpY2F0aW9uID0gZmFsc2UgIChib29sKQogIGluZm8ucHJvZHVjdCA9ICdGVUpJVFNV IE1IWjIxNjBCSCBHMScgIChzdHJpbmcpCiAgYmxvY2subWFqb3IgPSAwICAoMHgwKSAgKGlu dCkKICBzdG9yYWdlLm9yaWdpbmF0aW5nX2RldmljZSA9ICcvb3JnL2ZyZWVkZXNrdG9wL0hh bC9kZXZpY2VzL2lkZV8yXzAnICAoc3RyaW5nKQogIGJsb2NrLm1pbm9yID0gOTUgICgweDVm KSAgKGludCkKICBzdG9yYWdlLm1vZGVsID0gJ0ZVSklUU1UgTUhaMjE2MEJIIEcxJyAgKHN0 cmluZykKICBmcmVlYnNkLmRyaXZlciA9ICdhZCcgIChzdHJpbmcpCiAgc3RvcmFnZS5idXMg PSAnc2F0YScgIChzdHJpbmcpCiAgc3RvcmFnZS52ZW5kb3IgPSAnRlVKSVRTVScgIChzdHJp bmcpCiAgZnJlZWJzZC51bml0ID0gNCAgKDB4NCkgIChpbnQpCiAgc3RvcmFnZS5kcml2ZV90 eXBlID0gJ2Rpc2snICAoc3RyaW5nKQogIHN0b3JhZ2Uuc2VyaWFsID0gJ0s2MFdUOEEyREdU QicgIChzdHJpbmcpCiAgc3RvcmFnZS5yZW1vdmFibGUgPSBmYWxzZSAgKGJvb2wpCiAgc3Rv cmFnZS5maXJtd2FyZV9yZXZpc2lvbiA9ICcwMDg0MDAwQScgIChzdHJpbmcpCiAgaW5mby5w YXJlbnQgPSAnL29yZy9mcmVlZGVza3RvcC9IYWwvZGV2aWNlcy9pZGVfMl8wJyAgKHN0cmlu ZykKICBmcmVlYnNkLmRldmljZV9maWxlID0gJy9kZXYvYWQ0JyAgKHN0cmluZykKICBzdG9y YWdlLnJlcXVpcmVzX2VqZWN0ID0gZmFsc2UgIChib29sKQogIGJsb2NrLmlzX3ZvbHVtZSA9 IGZhbHNlICAoYm9vbCkKICBpbmZvLmNhcGFiaWxpdGllcyA9IHsgJ2Jsb2NrJywgJ3N0b3Jh Z2UnIH0gKHN0cmluZyBsaXN0KQogIHN0b3JhZ2UuaG90cGx1Z2dhYmxlID0gZmFsc2UgIChi b29sKQogIGJsb2NrLnN0b3JhZ2VfZGV2aWNlID0gJy9vcmcvZnJlZWRlc2t0b3AvSGFsL2Rl dmljZXMvc3RvcmFnZV9zZXJpYWxfSzYwV1Q4QTJER1RCJyAgKHN0cmluZykKICBpbmZvLmNh dGVnb3J5ID0gJ3N0b3JhZ2UnICAoc3RyaW5nKQogIHN0b3JhZ2UubWVkaWFfY2hlY2tfZW5h YmxlZCA9IGZhbHNlICAoYm9vbCkKCjE0OiB1ZGkgPSAnL29yZy9mcmVlZGVza3RvcC9IYWwv ZGV2aWNlcy92b2x1bWVfc2l6ZV8yMTQ3NDgzNjQ4JwogIHZvbHVtZS5udW1fYmxvY2tzID0g NDE5NDMwNCAgKDB4NDAwMDAwKSAgKHVpbnQ2NCkKICBpbmZvLnVkaSA9ICcvb3JnL2ZyZWVk ZXNrdG9wL0hhbC9kZXZpY2VzL3ZvbHVtZV9zaXplXzIxNDc0ODM2NDgnICAoc3RyaW5nKQog IGluZm8uc3Vic3lzdGVtID0gJ2Jsb2NrJyAgKHN0cmluZykKICB2b2x1bWUuaXNfbW91bnRl ZCA9IHRydWUgIChib29sKQogIGluZm8uaW50ZXJmYWNlcyA9IHsgJ29yZy5mcmVlZGVza3Rv cC5IYWwuRGV2aWNlLlZvbHVtZScgfSAoc3RyaW5nIGxpc3QpCiAgYmxvY2suZGV2aWNlID0g Jy9kZXYvYWQ0czFhJyAgKHN0cmluZykKICB2b2x1bWUuaXNfZGlzYyA9IGZhbHNlICAoYm9v bCkKICB2b2x1bWUuaXNfbW91bnRlZF9yZWFkX29ubHkgPSBmYWxzZSAgKGJvb2wpCiAgaW5m by5wcm9kdWN0ID0gJ1ZvbHVtZSAodWZzKScgIChzdHJpbmcpCiAgYmxvY2subWFqb3IgPSAw ICAoMHgwKSAgKGludCkKICB2b2x1bWUuaXNfcGFydGl0aW9uID0gZmFsc2UgIChib29sKQog IHZvbHVtZS5tb3VudF9wb2ludCA9ICcvJyAgKHN0cmluZykKICBibG9jay5taW5vciA9IDEw MCAgKDB4NjQpICAoaW50KQogIHZvbHVtZS5pZ25vcmUgPSBmYWxzZSAgKGJvb2wpCiAgdm9s dW1lLmZzdmVyc2lvbiA9ICcyJyAgKHN0cmluZykKICB2b2x1bWUuZnN1c2FnZSA9ICdmaWxl c3lzdGVtJyAgKHN0cmluZykKICBvcmcuZnJlZWRlc2t0b3AuSGFsLkRldmljZS5Wb2x1bWUu bWV0aG9kX25hbWVzID0geyAnTW91bnQnLCAnVW5tb3VudCcsICdFamVjdCcgfSAoc3RyaW5n IGxpc3QpCiAgdm9sdW1lLmZzdHlwZSA9ICd1ZnMnICAoc3RyaW5nKQogIG9yZy5mcmVlZGVz a3RvcC5IYWwuRGV2aWNlLlZvbHVtZS5tZXRob2Rfc2lnbmF0dXJlcyA9IHsgJ3NzYXMnLCAn YXMnLCAnYXMnIH0gKHN0cmluZyBsaXN0KQogIHZvbHVtZS5sYWJlbCA9ICcnICAoc3RyaW5n KQogIG9yZy5mcmVlZGVza3RvcC5IYWwuRGV2aWNlLlZvbHVtZS5tZXRob2RfYXJnbmFtZXMg PSB7ICdtb3VudF9wb2ludCBmc3R5cGUgZXh0cmFfb3B0aW9ucycsICdleHRyYV9vcHRpb25z JywgJ2V4dHJhX29wdGlvbnMnIH0gKHN0cmluZyBsaXN0KQogIGluZm8ucGFyZW50ID0gJy9v cmcvZnJlZWRlc2t0b3AvSGFsL2RldmljZXMvdm9sdW1lX3BhcnQxX3NpemVfMTYwMDM5MjQw NzA0JyAgKHN0cmluZykKICB2b2x1bWUudXVpZCA9ICcnICAoc3RyaW5nKQogIGJsb2NrLmlz X3ZvbHVtZSA9IHRydWUgIChib29sKQogIG9yZy5mcmVlZGVza3RvcC5IYWwuRGV2aWNlLlZv bHVtZS5tZXRob2RfZXhlY3BhdGhzID0geyAnaGFsLXN0b3JhZ2UtbW91bnQnLCAnaGFsLXN0 b3JhZ2UtdW5tb3VudCcsICdoYWwtc3RvcmFnZS1lamVjdCcgfSAoc3RyaW5nIGxpc3QpCiAg aW5mby5jYXBhYmlsaXRpZXMgPSB7ICdibG9jaycsICd2b2x1bWUnIH0gKHN0cmluZyBsaXN0 KQogIHZvbHVtZS5ibG9ja19zaXplID0gNTEyICAoMHgyMDApICAodWludDY0KQogIGJsb2Nr LnN0b3JhZ2VfZGV2aWNlID0gJy9vcmcvZnJlZWRlc2t0b3AvSGFsL2RldmljZXMvc3RvcmFn ZV9zZXJpYWxfSzYwV1Q4QTJER1RCJyAgKHN0cmluZykKICB2b2x1bWUubW91bnQudmFsaWRf b3B0aW9ucyA9IHsgJ3JvJywgJ25vZXhlYycsICdub2F0aW1lJyB9IChzdHJpbmcgbGlzdCkK ICBpbmZvLmNhdGVnb3J5ID0gJ3ZvbHVtZScgIChzdHJpbmcpCiAgdm9sdW1lLnNpemUgPSAy MTQ3NDgzNjQ4ICAoMHg4MDAwMDAwMCkgICh1aW50NjQpCgoxNTogdWRpID0gJy9vcmcvZnJl ZWRlc2t0b3AvSGFsL2RldmljZXMvdm9sdW1lX3NpemVfNTM2ODcwOTEyJwogIHZvbHVtZS5u dW1fYmxvY2tzID0gMTA0ODU3NiAgKDB4MTAwMDAwKSAgKHVpbnQ2NCkKICBpbmZvLnVkaSA9 ICcvb3JnL2ZyZWVkZXNrdG9wL0hhbC9kZXZpY2VzL3ZvbHVtZV9zaXplXzUzNjg3MDkxMicg IChzdHJpbmcpCiAgaW5mby5zdWJzeXN0ZW0gPSAnYmxvY2snICAoc3RyaW5nKQogIHZvbHVt ZS5pc19tb3VudGVkID0gdHJ1ZSAgKGJvb2wpCiAgaW5mby5pbnRlcmZhY2VzID0geyAnb3Jn LmZyZWVkZXNrdG9wLkhhbC5EZXZpY2UuVm9sdW1lJyB9IChzdHJpbmcgbGlzdCkKICBibG9j ay5kZXZpY2UgPSAnL2Rldi9hZDRzMWQnICAoc3RyaW5nKQogIHZvbHVtZS5pc19kaXNjID0g ZmFsc2UgIChib29sKQogIHZvbHVtZS5pc19tb3VudGVkX3JlYWRfb25seSA9IGZhbHNlICAo Ym9vbCkKICBpbmZvLnByb2R1Y3QgPSAnVm9sdW1lICh1ZnMpJyAgKHN0cmluZykKICBibG9j ay5tYWpvciA9IDAgICgweDApICAoaW50KQogIHZvbHVtZS5pc19wYXJ0aXRpb24gPSBmYWxz ZSAgKGJvb2wpCiAgdm9sdW1lLm1vdW50X3BvaW50ID0gJy90bXAnICAoc3RyaW5nKQogIGJs b2NrLm1pbm9yID0gMTAyICAoMHg2NikgIChpbnQpCiAgdm9sdW1lLmlnbm9yZSA9IGZhbHNl ICAoYm9vbCkKICB2b2x1bWUuZnN2ZXJzaW9uID0gJzInICAoc3RyaW5nKQogIHZvbHVtZS5m c3VzYWdlID0gJ2ZpbGVzeXN0ZW0nICAoc3RyaW5nKQogIG9yZy5mcmVlZGVza3RvcC5IYWwu RGV2aWNlLlZvbHVtZS5tZXRob2RfbmFtZXMgPSB7ICdNb3VudCcsICdVbm1vdW50JywgJ0Vq ZWN0JyB9IChzdHJpbmcgbGlzdCkKICB2b2x1bWUuZnN0eXBlID0gJ3VmcycgIChzdHJpbmcp CiAgb3JnLmZyZWVkZXNrdG9wLkhhbC5EZXZpY2UuVm9sdW1lLm1ldGhvZF9zaWduYXR1cmVz ID0geyAnc3NhcycsICdhcycsICdhcycgfSAoc3RyaW5nIGxpc3QpCiAgdm9sdW1lLmxhYmVs ID0gJycgIChzdHJpbmcpCiAgb3JnLmZyZWVkZXNrdG9wLkhhbC5EZXZpY2UuVm9sdW1lLm1l dGhvZF9hcmduYW1lcyA9IHsgJ21vdW50X3BvaW50IGZzdHlwZSBleHRyYV9vcHRpb25zJywg J2V4dHJhX29wdGlvbnMnLCAnZXh0cmFfb3B0aW9ucycgfSAoc3RyaW5nIGxpc3QpCiAgaW5m by5wYXJlbnQgPSAnL29yZy9mcmVlZGVza3RvcC9IYWwvZGV2aWNlcy92b2x1bWVfcGFydDFf c2l6ZV8xNjAwMzkyNDA3MDQnICAoc3RyaW5nKQogIHZvbHVtZS51dWlkID0gJycgIChzdHJp bmcpCiAgYmxvY2suaXNfdm9sdW1lID0gdHJ1ZSAgKGJvb2wpCiAgb3JnLmZyZWVkZXNrdG9w LkhhbC5EZXZpY2UuVm9sdW1lLm1ldGhvZF9leGVjcGF0aHMgPSB7ICdoYWwtc3RvcmFnZS1t b3VudCcsICdoYWwtc3RvcmFnZS11bm1vdW50JywgJ2hhbC1zdG9yYWdlLWVqZWN0JyB9IChz dHJpbmcgbGlzdCkKICBpbmZvLmNhcGFiaWxpdGllcyA9IHsgJ2Jsb2NrJywgJ3ZvbHVtZScg fSAoc3RyaW5nIGxpc3QpCiAgdm9sdW1lLmJsb2NrX3NpemUgPSA1MTIgICgweDIwMCkgICh1 aW50NjQpCiAgYmxvY2suc3RvcmFnZV9kZXZpY2UgPSAnL29yZy9mcmVlZGVza3RvcC9IYWwv ZGV2aWNlcy9zdG9yYWdlX3NlcmlhbF9LNjBXVDhBMkRHVEInICAoc3RyaW5nKQogIHZvbHVt ZS5tb3VudC52YWxpZF9vcHRpb25zID0geyAncm8nLCAnbm9leGVjJywgJ25vYXRpbWUnIH0g KHN0cmluZyBsaXN0KQogIGluZm8uY2F0ZWdvcnkgPSAndm9sdW1lJyAgKHN0cmluZykKICB2 b2x1bWUuc2l6ZSA9IDUzNjg3MDkxMiAgKDB4MjAwMDAwMDApICAodWludDY0KQoKMTY6IHVk aSA9ICcvb3JnL2ZyZWVkZXNrdG9wL0hhbC9kZXZpY2VzL3ZvbHVtZV9zaXplXzg1ODk5MzQ1 OTInCiAgdm9sdW1lLm51bV9ibG9ja3MgPSAxNjc3NzIxNiAgKDB4MTAwMDAwMCkgICh1aW50 NjQpCiAgaW5mby51ZGkgPSAnL29yZy9mcmVlZGVza3RvcC9IYWwvZGV2aWNlcy92b2x1bWVf c2l6ZV84NTg5OTM0NTkyJyAgKHN0cmluZykKICBpbmZvLnN1YnN5c3RlbSA9ICdibG9jaycg IChzdHJpbmcpCiAgdm9sdW1lLmlzX21vdW50ZWQgPSB0cnVlICAoYm9vbCkKICBpbmZvLmlu dGVyZmFjZXMgPSB7ICdvcmcuZnJlZWRlc2t0b3AuSGFsLkRldmljZS5Wb2x1bWUnIH0gKHN0 cmluZyBsaXN0KQogIGJsb2NrLmRldmljZSA9ICcvZGV2L2FkNHMxZScgIChzdHJpbmcpCiAg dm9sdW1lLmlzX2Rpc2MgPSBmYWxzZSAgKGJvb2wpCiAgdm9sdW1lLmlzX21vdW50ZWRfcmVh ZF9vbmx5ID0gZmFsc2UgIChib29sKQogIGluZm8ucHJvZHVjdCA9ICdWb2x1bWUgKHVmcykn ICAoc3RyaW5nKQogIGJsb2NrLm1ham9yID0gMCAgKDB4MCkgIChpbnQpCiAgdm9sdW1lLmlz X3BhcnRpdGlvbiA9IGZhbHNlICAoYm9vbCkKICB2b2x1bWUubW91bnRfcG9pbnQgPSAnL3Zh cicgIChzdHJpbmcpCiAgYmxvY2subWlub3IgPSAxMDMgICgweDY3KSAgKGludCkKICB2b2x1 bWUuaWdub3JlID0gZmFsc2UgIChib29sKQogIHZvbHVtZS5mc3ZlcnNpb24gPSAnMicgIChz dHJpbmcpCiAgdm9sdW1lLmZzdXNhZ2UgPSAnZmlsZXN5c3RlbScgIChzdHJpbmcpCiAgb3Jn LmZyZWVkZXNrdG9wLkhhbC5EZXZpY2UuVm9sdW1lLm1ldGhvZF9uYW1lcyA9IHsgJ01vdW50 JywgJ1VubW91bnQnLCAnRWplY3QnIH0gKHN0cmluZyBsaXN0KQogIHZvbHVtZS5mc3R5cGUg PSAndWZzJyAgKHN0cmluZykKICBvcmcuZnJlZWRlc2t0b3AuSGFsLkRldmljZS5Wb2x1bWUu bWV0aG9kX3NpZ25hdHVyZXMgPSB7ICdzc2FzJywgJ2FzJywgJ2FzJyB9IChzdHJpbmcgbGlz dCkKICB2b2x1bWUubGFiZWwgPSAnJyAgKHN0cmluZykKICBvcmcuZnJlZWRlc2t0b3AuSGFs LkRldmljZS5Wb2x1bWUubWV0aG9kX2FyZ25hbWVzID0geyAnbW91bnRfcG9pbnQgZnN0eXBl IGV4dHJhX29wdGlvbnMnLCAnZXh0cmFfb3B0aW9ucycsICdleHRyYV9vcHRpb25zJyB9IChz dHJpbmcgbGlzdCkKICBpbmZvLnBhcmVudCA9ICcvb3JnL2ZyZWVkZXNrdG9wL0hhbC9kZXZp Y2VzL3ZvbHVtZV9wYXJ0MV9zaXplXzE2MDAzOTI0MDcwNCcgIChzdHJpbmcpCiAgdm9sdW1l LnV1aWQgPSAnJyAgKHN0cmluZykKICBibG9jay5pc192b2x1bWUgPSB0cnVlICAoYm9vbCkK ICBvcmcuZnJlZWRlc2t0b3AuSGFsLkRldmljZS5Wb2x1bWUubWV0aG9kX2V4ZWNwYXRocyA9 IHsgJ2hhbC1zdG9yYWdlLW1vdW50JywgJ2hhbC1zdG9yYWdlLXVubW91bnQnLCAnaGFsLXN0 b3JhZ2UtZWplY3QnIH0gKHN0cmluZyBsaXN0KQogIGluZm8uY2FwYWJpbGl0aWVzID0geyAn YmxvY2snLCAndm9sdW1lJyB9IChzdHJpbmcgbGlzdCkKICB2b2x1bWUuYmxvY2tfc2l6ZSA9 IDUxMiAgKDB4MjAwKSAgKHVpbnQ2NCkKICBibG9jay5zdG9yYWdlX2RldmljZSA9ICcvb3Jn L2ZyZWVkZXNrdG9wL0hhbC9kZXZpY2VzL3N0b3JhZ2Vfc2VyaWFsX0s2MFdUOEEyREdUQicg IChzdHJpbmcpCiAgdm9sdW1lLm1vdW50LnZhbGlkX29wdGlvbnMgPSB7ICdybycsICdub2V4 ZWMnLCAnbm9hdGltZScgfSAoc3RyaW5nIGxpc3QpCiAgaW5mby5jYXRlZ29yeSA9ICd2b2x1 bWUnICAoc3RyaW5nKQogIHZvbHVtZS5zaXplID0gODU4OTkzNDU5MiAgKDB4MjAwMDAwMDAw KSAgKHVpbnQ2NCkKCjE3OiB1ZGkgPSAnL29yZy9mcmVlZGVza3RvcC9IYWwvZGV2aWNlcy92 b2x1bWVfc2l6ZV82ODcxOTQ3NjczNicKICB2b2x1bWUubnVtX2Jsb2NrcyA9IDEzNDIxNzcy OCAgKDB4ODAwMDAwMCkgICh1aW50NjQpCiAgaW5mby51ZGkgPSAnL29yZy9mcmVlZGVza3Rv cC9IYWwvZGV2aWNlcy92b2x1bWVfc2l6ZV82ODcxOTQ3NjczNicgIChzdHJpbmcpCiAgaW5m by5zdWJzeXN0ZW0gPSAnYmxvY2snICAoc3RyaW5nKQogIHZvbHVtZS5pc19tb3VudGVkID0g dHJ1ZSAgKGJvb2wpCiAgaW5mby5pbnRlcmZhY2VzID0geyAnb3JnLmZyZWVkZXNrdG9wLkhh bC5EZXZpY2UuVm9sdW1lJyB9IChzdHJpbmcgbGlzdCkKICBibG9jay5kZXZpY2UgPSAnL2Rl di9hZDRzMWYnICAoc3RyaW5nKQogIHZvbHVtZS5pc19kaXNjID0gZmFsc2UgIChib29sKQog IHZvbHVtZS5pc19tb3VudGVkX3JlYWRfb25seSA9IGZhbHNlICAoYm9vbCkKICBpbmZvLnBy b2R1Y3QgPSAnVm9sdW1lICh1ZnMpJyAgKHN0cmluZykKICBibG9jay5tYWpvciA9IDAgICgw eDApICAoaW50KQogIHZvbHVtZS5pc19wYXJ0aXRpb24gPSBmYWxzZSAgKGJvb2wpCiAgdm9s dW1lLm1vdW50X3BvaW50ID0gJy9ob21lJyAgKHN0cmluZykKICBibG9jay5taW5vciA9IDEw NCAgKDB4NjgpICAoaW50KQogIHZvbHVtZS5pZ25vcmUgPSBmYWxzZSAgKGJvb2wpCiAgdm9s dW1lLmZzdmVyc2lvbiA9ICcyJyAgKHN0cmluZykKICB2b2x1bWUuZnN1c2FnZSA9ICdmaWxl c3lzdGVtJyAgKHN0cmluZykKICBvcmcuZnJlZWRlc2t0b3AuSGFsLkRldmljZS5Wb2x1bWUu bWV0aG9kX25hbWVzID0geyAnTW91bnQnLCAnVW5tb3VudCcsICdFamVjdCcgfSAoc3RyaW5n IGxpc3QpCiAgdm9sdW1lLmZzdHlwZSA9ICd1ZnMnICAoc3RyaW5nKQogIG9yZy5mcmVlZGVz a3RvcC5IYWwuRGV2aWNlLlZvbHVtZS5tZXRob2Rfc2lnbmF0dXJlcyA9IHsgJ3NzYXMnLCAn YXMnLCAnYXMnIH0gKHN0cmluZyBsaXN0KQogIHZvbHVtZS5sYWJlbCA9ICcnICAoc3RyaW5n KQogIG9yZy5mcmVlZGVza3RvcC5IYWwuRGV2aWNlLlZvbHVtZS5tZXRob2RfYXJnbmFtZXMg PSB7ICdtb3VudF9wb2ludCBmc3R5cGUgZXh0cmFfb3B0aW9ucycsICdleHRyYV9vcHRpb25z JywgJ2V4dHJhX29wdGlvbnMnIH0gKHN0cmluZyBsaXN0KQogIGluZm8ucGFyZW50ID0gJy9v cmcvZnJlZWRlc2t0b3AvSGFsL2RldmljZXMvdm9sdW1lX3BhcnQxX3NpemVfMTYwMDM5MjQw NzA0JyAgKHN0cmluZykKICB2b2x1bWUudXVpZCA9ICcnICAoc3RyaW5nKQogIGJsb2NrLmlz X3ZvbHVtZSA9IHRydWUgIChib29sKQogIG9yZy5mcmVlZGVza3RvcC5IYWwuRGV2aWNlLlZv bHVtZS5tZXRob2RfZXhlY3BhdGhzID0geyAnaGFsLXN0b3JhZ2UtbW91bnQnLCAnaGFsLXN0 b3JhZ2UtdW5tb3VudCcsICdoYWwtc3RvcmFnZS1lamVjdCcgfSAoc3RyaW5nIGxpc3QpCiAg aW5mby5jYXBhYmlsaXRpZXMgPSB7ICdibG9jaycsICd2b2x1bWUnIH0gKHN0cmluZyBsaXN0 KQogIHZvbHVtZS5ibG9ja19zaXplID0gNTEyICAoMHgyMDApICAodWludDY0KQogIGJsb2Nr LnN0b3JhZ2VfZGV2aWNlID0gJy9vcmcvZnJlZWRlc2t0b3AvSGFsL2RldmljZXMvc3RvcmFn ZV9zZXJpYWxfSzYwV1Q4QTJER1RCJyAgKHN0cmluZykKICB2b2x1bWUubW91bnQudmFsaWRf b3B0aW9ucyA9IHsgJ3JvJywgJ25vZXhlYycsICdub2F0aW1lJyB9IChzdHJpbmcgbGlzdCkK ICBpbmZvLmNhdGVnb3J5ID0gJ3ZvbHVtZScgIChzdHJpbmcpCiAgdm9sdW1lLnNpemUgPSA2 ODcxOTQ3NjczNiAgKDB4MTAwMDAwMDAwMCkgICh1aW50NjQpCgoxODogdWRpID0gJy9vcmcv ZnJlZWRlc2t0b3AvSGFsL2RldmljZXMvdm9sdW1lX3NpemVfNDUwOTcxNTY2MDgnCiAgdm9s dW1lLm51bV9ibG9ja3MgPSA4ODA4MDM4NCAgKDB4NTQwMDAwMCkgICh1aW50NjQpCiAgaW5m by51ZGkgPSAnL29yZy9mcmVlZGVza3RvcC9IYWwvZGV2aWNlcy92b2x1bWVfc2l6ZV80NTA5 NzE1NjYwOCcgIChzdHJpbmcpCiAgaW5mby5zdWJzeXN0ZW0gPSAnYmxvY2snICAoc3RyaW5n KQogIHZvbHVtZS5pc19tb3VudGVkID0gdHJ1ZSAgKGJvb2wpCiAgaW5mby5pbnRlcmZhY2Vz ID0geyAnb3JnLmZyZWVkZXNrdG9wLkhhbC5EZXZpY2UuVm9sdW1lJyB9IChzdHJpbmcgbGlz dCkKICBibG9jay5kZXZpY2UgPSAnL2Rldi9hZDRzMWcnICAoc3RyaW5nKQogIHZvbHVtZS5p c19kaXNjID0gZmFsc2UgIChib29sKQogIHZvbHVtZS5pc19tb3VudGVkX3JlYWRfb25seSA9 IGZhbHNlICAoYm9vbCkKICBpbmZvLnByb2R1Y3QgPSAnVm9sdW1lICh1ZnMpJyAgKHN0cmlu ZykKICBibG9jay5tYWpvciA9IDAgICgweDApICAoaW50KQogIHZvbHVtZS5pc19wYXJ0aXRp b24gPSBmYWxzZSAgKGJvb2wpCiAgdm9sdW1lLm1vdW50X3BvaW50ID0gJy91c3InICAoc3Ry aW5nKQogIGJsb2NrLm1pbm9yID0gMTA1ICAoMHg2OSkgIChpbnQpCiAgdm9sdW1lLmlnbm9y ZSA9IGZhbHNlICAoYm9vbCkKICB2b2x1bWUuZnN2ZXJzaW9uID0gJzInICAoc3RyaW5nKQog IHZvbHVtZS5mc3VzYWdlID0gJ2ZpbGVzeXN0ZW0nICAoc3RyaW5nKQogIG9yZy5mcmVlZGVz a3RvcC5IYWwuRGV2aWNlLlZvbHVtZS5tZXRob2RfbmFtZXMgPSB7ICdNb3VudCcsICdVbm1v dW50JywgJ0VqZWN0JyB9IChzdHJpbmcgbGlzdCkKICB2b2x1bWUuZnN0eXBlID0gJ3Vmcycg IChzdHJpbmcpCiAgb3JnLmZyZWVkZXNrdG9wLkhhbC5EZXZpY2UuVm9sdW1lLm1ldGhvZF9z aWduYXR1cmVzID0geyAnc3NhcycsICdhcycsICdhcycgfSAoc3RyaW5nIGxpc3QpCiAgdm9s dW1lLmxhYmVsID0gJycgIChzdHJpbmcpCiAgb3JnLmZyZWVkZXNrdG9wLkhhbC5EZXZpY2Uu Vm9sdW1lLm1ldGhvZF9hcmduYW1lcyA9IHsgJ21vdW50X3BvaW50IGZzdHlwZSBleHRyYV9v cHRpb25zJywgJ2V4dHJhX29wdGlvbnMnLCAnZXh0cmFfb3B0aW9ucycgfSAoc3RyaW5nIGxp c3QpCiAgaW5mby5wYXJlbnQgPSAnL29yZy9mcmVlZGVza3RvcC9IYWwvZGV2aWNlcy92b2x1 bWVfcGFydDFfc2l6ZV8xNjAwMzkyNDA3MDQnICAoc3RyaW5nKQogIHZvbHVtZS51dWlkID0g JycgIChzdHJpbmcpCiAgYmxvY2suaXNfdm9sdW1lID0gdHJ1ZSAgKGJvb2wpCiAgb3JnLmZy ZWVkZXNrdG9wLkhhbC5EZXZpY2UuVm9sdW1lLm1ldGhvZF9leGVjcGF0aHMgPSB7ICdoYWwt c3RvcmFnZS1tb3VudCcsICdoYWwtc3RvcmFnZS11bm1vdW50JywgJ2hhbC1zdG9yYWdlLWVq ZWN0JyB9IChzdHJpbmcgbGlzdCkKICBpbmZvLmNhcGFiaWxpdGllcyA9IHsgJ2Jsb2NrJywg J3ZvbHVtZScgfSAoc3RyaW5nIGxpc3QpCiAgdm9sdW1lLmJsb2NrX3NpemUgPSA1MTIgICgw eDIwMCkgICh1aW50NjQpCiAgYmxvY2suc3RvcmFnZV9kZXZpY2UgPSAnL29yZy9mcmVlZGVz a3RvcC9IYWwvZGV2aWNlcy9zdG9yYWdlX3NlcmlhbF9LNjBXVDhBMkRHVEInICAoc3RyaW5n KQogIHZvbHVtZS5tb3VudC52YWxpZF9vcHRpb25zID0geyAncm8nLCAnbm9leGVjJywgJ25v YXRpbWUnIH0gKHN0cmluZyBsaXN0KQogIGluZm8uY2F0ZWdvcnkgPSAndm9sdW1lJyAgKHN0 cmluZykKICB2b2x1bWUuc2l6ZSA9IDQ1MDk3MTU2NjA4ICAoMHhhODAwMDAwMDApICAodWlu dDY0KQoKMTk6IHVkaSA9ICcvb3JnL2ZyZWVkZXNrdG9wL0hhbC9kZXZpY2VzL3ZvbHVtZV91 dWlkXzkxRDZfMUVGMicKICB2b2x1bWUubnVtX2Jsb2NrcyA9IDY4MjU4NDM0ICAoMHg0MTE4 YTgyKSAgKHVpbnQ2NCkKICBpbmZvLnVkaSA9ICcvb3JnL2ZyZWVkZXNrdG9wL0hhbC9kZXZp Y2VzL3ZvbHVtZV91dWlkXzkxRDZfMUVGMicgIChzdHJpbmcpCiAgaW5mby5zdWJzeXN0ZW0g PSAnYmxvY2snICAoc3RyaW5nKQogIHZvbHVtZS5pc19tb3VudGVkID0gdHJ1ZSAgKGJvb2wp CiAgaW5mby5pbnRlcmZhY2VzID0geyAnb3JnLmZyZWVkZXNrdG9wLkhhbC5EZXZpY2UuVm9s dW1lJyB9IChzdHJpbmcgbGlzdCkKICBibG9jay5kZXZpY2UgPSAnL2Rldi9hZDRzMWgnICAo c3RyaW5nKQogIHZvbHVtZS5pc19kaXNjID0gZmFsc2UgIChib29sKQogIHZvbHVtZS5pc19t b3VudGVkX3JlYWRfb25seSA9IGZhbHNlICAoYm9vbCkKICBpbmZvLnByb2R1Y3QgPSAnVm9s dW1lICh2ZmF0KScgIChzdHJpbmcpCiAgYmxvY2subWFqb3IgPSAwICAoMHgwKSAgKGludCkK ICB2b2x1bWUuaXNfcGFydGl0aW9uID0gZmFsc2UgIChib29sKQogIHZvbHVtZS5tb3VudF9w b2ludCA9ICcvbHZtJyAgKHN0cmluZykKICBibG9jay5taW5vciA9IDEwNiAgKDB4NmEpICAo aW50KQogIHZvbHVtZS5pZ25vcmUgPSBmYWxzZSAgKGJvb2wpCiAgdm9sdW1lLmZzdmVyc2lv biA9ICdGQVQzMicgIChzdHJpbmcpCiAgdm9sdW1lLmZzdXNhZ2UgPSAnZmlsZXN5c3RlbScg IChzdHJpbmcpCiAgb3JnLmZyZWVkZXNrdG9wLkhhbC5EZXZpY2UuVm9sdW1lLm1ldGhvZF9u YW1lcyA9IHsgJ01vdW50JywgJ1VubW91bnQnLCAnRWplY3QnIH0gKHN0cmluZyBsaXN0KQog IHZvbHVtZS5mc3R5cGUgPSAndmZhdCcgIChzdHJpbmcpCiAgb3JnLmZyZWVkZXNrdG9wLkhh bC5EZXZpY2UuVm9sdW1lLm1ldGhvZF9zaWduYXR1cmVzID0geyAnc3NhcycsICdhcycsICdh cycgfSAoc3RyaW5nIGxpc3QpCiAgdm9sdW1lLmxhYmVsID0gJycgIChzdHJpbmcpCiAgb3Jn LmZyZWVkZXNrdG9wLkhhbC5EZXZpY2UuVm9sdW1lLm1ldGhvZF9hcmduYW1lcyA9IHsgJ21v dW50X3BvaW50IGZzdHlwZSBleHRyYV9vcHRpb25zJywgJ2V4dHJhX29wdGlvbnMnLCAnZXh0 cmFfb3B0aW9ucycgfSAoc3RyaW5nIGxpc3QpCiAgaW5mby5wYXJlbnQgPSAnL29yZy9mcmVl ZGVza3RvcC9IYWwvZGV2aWNlcy92b2x1bWVfcGFydDFfc2l6ZV8xNjAwMzkyNDA3MDQnICAo c3RyaW5nKQogIHZvbHVtZS51dWlkID0gJzkxRDYtMUVGMicgIChzdHJpbmcpCiAgYmxvY2su aXNfdm9sdW1lID0gdHJ1ZSAgKGJvb2wpCiAgb3JnLmZyZWVkZXNrdG9wLkhhbC5EZXZpY2Uu Vm9sdW1lLm1ldGhvZF9leGVjcGF0aHMgPSB7ICdoYWwtc3RvcmFnZS1tb3VudCcsICdoYWwt c3RvcmFnZS11bm1vdW50JywgJ2hhbC1zdG9yYWdlLWVqZWN0JyB9IChzdHJpbmcgbGlzdCkK ICBpbmZvLmNhcGFiaWxpdGllcyA9IHsgJ2Jsb2NrJywgJ3ZvbHVtZScgfSAoc3RyaW5nIGxp c3QpCiAgdm9sdW1lLmJsb2NrX3NpemUgPSA1MTIgICgweDIwMCkgICh1aW50NjQpCiAgYmxv Y2suc3RvcmFnZV9kZXZpY2UgPSAnL29yZy9mcmVlZGVza3RvcC9IYWwvZGV2aWNlcy9zdG9y YWdlX3NlcmlhbF9LNjBXVDhBMkRHVEInICAoc3RyaW5nKQogIHZvbHVtZS5tb3VudC52YWxp ZF9vcHRpb25zID0geyAncm8nLCAnbm9leGVjJywgJ25vYXRpbWUnLCAnbG9uZ25hbWVzJywg J3Nob3J0bmFtZXMnLCAnbm93aW45NScsICctdT0nLCAnLWc9JywgJy1tPScsICctTT0nLCAn LUw9JywgJy1EPScsICdsYXJnZScgfSAoc3RyaW5nIGxpc3QpCiAgaW5mby5jYXRlZ29yeSA9 ICd2b2x1bWUnICAoc3RyaW5nKQogIHZvbHVtZS5zaXplID0gMzQ5NDgzMTgyMDggICgweDgy MzE1MDQwMCkgICh1aW50NjQpCgoyMDogdWRpID0gJy9vcmcvZnJlZWRlc2t0b3AvSGFsL2Rl dmljZXMvdm9sdW1lX3BhcnQxX3NpemVfMTYwMDM5MjQwNzA0JwogIHZvbHVtZS5wYXJ0aXRp b24ubWVkaWFfc2l6ZSA9IDE2MDAzOTI0MDcwNCAgKDB4MjU0MzE1MDQwMCkgICh1aW50NjQp CiAgdm9sdW1lLm51bV9ibG9ja3MgPSAzMTI1NzY2NDIgICgweDEyYTE4YTgyKSAgKHVpbnQ2 NCkKICBpbmZvLnVkaSA9ICcvb3JnL2ZyZWVkZXNrdG9wL0hhbC9kZXZpY2VzL3ZvbHVtZV9w YXJ0MV9zaXplXzE2MDAzOTI0MDcwNCcgIChzdHJpbmcpCiAgaW5mby5zdWJzeXN0ZW0gPSAn YmxvY2snICAoc3RyaW5nKQogIHZvbHVtZS5wYXJ0aXRpb24uc3RhcnQgPSAzMjI1NiAgKDB4 N2UwMCkgICh1aW50NjQpCiAgdm9sdW1lLmlzX21vdW50ZWQgPSBmYWxzZSAgKGJvb2wpCiAg YmxvY2suZGV2aWNlID0gJy9kZXYvYWQ0czEnICAoc3RyaW5nKQogIHZvbHVtZS5pc19kaXNj ID0gZmFsc2UgIChib29sKQogIHZvbHVtZS5pc19tb3VudGVkX3JlYWRfb25seSA9IGZhbHNl ICAoYm9vbCkKICBpbmZvLnByb2R1Y3QgPSAnVm9sdW1lJyAgKHN0cmluZykKICBibG9jay5t YWpvciA9IDAgICgweDApICAoaW50KQogIHZvbHVtZS5pc19wYXJ0aXRpb24gPSB0cnVlICAo Ym9vbCkKICB2b2x1bWUubW91bnRfcG9pbnQgPSAnJyAgKHN0cmluZykKICBibG9jay5taW5v ciA9IDk2ICAoMHg2MCkgIChpbnQpCiAgdm9sdW1lLmlnbm9yZSA9IHRydWUgIChib29sKQog IHZvbHVtZS5mc3VzYWdlID0gJ3BhcnRpdGlvbnRhYmxlJyAgKHN0cmluZykKICB2b2x1bWUu ZnN0eXBlID0gJycgIChzdHJpbmcpCiAgdm9sdW1lLmxhYmVsID0gJycgIChzdHJpbmcpCiAg aW5mby5wYXJlbnQgPSAnL29yZy9mcmVlZGVza3RvcC9IYWwvZGV2aWNlcy9zdG9yYWdlX3Nl cmlhbF9LNjBXVDhBMkRHVEInICAoc3RyaW5nKQogIHZvbHVtZS5wYXJ0aXRpb24ubnVtYmVy ID0gMSAgKDB4MSkgIChpbnQpCiAgdm9sdW1lLnV1aWQgPSAnJyAgKHN0cmluZykKICBibG9j ay5pc192b2x1bWUgPSB0cnVlICAoYm9vbCkKICBpbmZvLmNhcGFiaWxpdGllcyA9IHsgJ2Js b2NrJywgJ3ZvbHVtZScgfSAoc3RyaW5nIGxpc3QpCiAgdm9sdW1lLnBhcnRpdGlvbi5zY2hl bWUgPSAnbWJyJyAgKHN0cmluZykKICB2b2x1bWUuYmxvY2tfc2l6ZSA9IDUxMiAgKDB4MjAw KSAgKHVpbnQ2NCkKICBibG9jay5zdG9yYWdlX2RldmljZSA9ICcvb3JnL2ZyZWVkZXNrdG9w L0hhbC9kZXZpY2VzL3N0b3JhZ2Vfc2VyaWFsX0s2MFdUOEEyREdUQicgIChzdHJpbmcpCiAg aW5mby5jYXRlZ29yeSA9ICd2b2x1bWUnICAoc3RyaW5nKQogIHZvbHVtZS5wYXJ0aXRpb24u dHlwZSA9ICcweGE1JyAgKHN0cmluZykKICB2b2x1bWUuc2l6ZSA9IDE2MDAzOTI0MDcwNCAg KDB4MjU0MzE1MDQwMCkgICh1aW50NjQpCgoyMTogdWRpID0gJy9vcmcvZnJlZWRlc2t0b3Av SGFsL2RldmljZXMvY29tcHV0ZXJfc2NzaV9ob3N0JwogIGluZm8udWRpID0gJy9vcmcvZnJl ZWRlc2t0b3AvSGFsL2RldmljZXMvY29tcHV0ZXJfc2NzaV9ob3N0JyAgKHN0cmluZykKICBp bmZvLnN1YnN5c3RlbSA9ICdzY3NpX2hvc3QnICAoc3RyaW5nKQogIGluZm8ucHJvZHVjdCA9 ICdTQ1NJIEhvc3QgQWRhcHRlcicgIChzdHJpbmcpCiAgc2NzaV9ob3N0Lmhvc3QgPSAwICAo MHgwKSAgKGludCkKICBpbmZvLnBhcmVudCA9ICcvb3JnL2ZyZWVkZXNrdG9wL0hhbC9kZXZp Y2VzL2NvbXB1dGVyJyAgKHN0cmluZykKCjIyOiB1ZGkgPSAnL29yZy9mcmVlZGVza3RvcC9I YWwvZGV2aWNlcy9pZGVfM18wJwogIGluZm8udWRpID0gJy9vcmcvZnJlZWRlc2t0b3AvSGFs L2RldmljZXMvaWRlXzNfMCcgIChzdHJpbmcpCiAgaWRlLmhvc3QgPSAzICAoMHgzKSAgKGlu dCkKICBpbmZvLnN1YnN5c3RlbSA9ICdpZGUnICAoc3RyaW5nKQogIGlkZS5jaGFubmVsID0g MCAgKDB4MCkgIChpbnQpCiAgaW5mby5wcm9kdWN0ID0gJ0lERSBEZXZpY2UgKE1hc3Rlcikn ICAoc3RyaW5nKQogIGluZm8ucGFyZW50ID0gJy9vcmcvZnJlZWRlc2t0b3AvSGFsL2Rldmlj ZXMvaWRlX2hvc3RfMycgIChzdHJpbmcpCgoyMzogdWRpID0gJy9vcmcvZnJlZWRlc2t0b3Av SGFsL2RldmljZXMvaWRlXzJfMCcKICBpbmZvLnVkaSA9ICcvb3JnL2ZyZWVkZXNrdG9wL0hh bC9kZXZpY2VzL2lkZV8yXzAnICAoc3RyaW5nKQogIGlkZS5ob3N0ID0gMiAgKDB4MikgIChp bnQpCiAgaW5mby5zdWJzeXN0ZW0gPSAnaWRlJyAgKHN0cmluZykKICBpZGUuY2hhbm5lbCA9 IDAgICgweDApICAoaW50KQogIGluZm8ucHJvZHVjdCA9ICdJREUgRGV2aWNlIChNYXN0ZXIp JyAgKHN0cmluZykKICBpbmZvLnBhcmVudCA9ICcvb3JnL2ZyZWVkZXNrdG9wL0hhbC9kZXZp Y2VzL2lkZV9ob3N0XzInICAoc3RyaW5nKQoKMjQ6IHVkaSA9ICcvb3JnL2ZyZWVkZXNrdG9w L0hhbC9kZXZpY2VzL3VzYl9kZXZpY2VfMF8wX25vc2VyaWFsXzZfaWYwJwogIHVzYi5idXNf bnVtYmVyID0gNyAgKDB4NykgIChpbnQpCiAgdXNiLnZlbmRvciA9ICdJbnRlbCcgIChzdHJp bmcpCiAgaW5mby51ZGkgPSAnL29yZy9mcmVlZGVza3RvcC9IYWwvZGV2aWNlcy91c2JfZGV2 aWNlXzBfMF9ub3NlcmlhbF82X2lmMCcgIChzdHJpbmcpCiAgaW5mby5zdWJzeXN0ZW0gPSAn dXNiJyAgKHN0cmluZykKICB1c2IudmVyc2lvbl9iY2QgPSA1MTIgICgweDIwMCkgIChpbnQp CiAgdXNiLmlzX3NlbGZfcG93ZXJlZCA9IHRydWUgIChib29sKQogIHVzYi5jb25maWd1cmF0 aW9uX3ZhbHVlID0gMSAgKDB4MSkgIChpbnQpCiAgdXNiLmNhbl93YWtlX3VwID0gZmFsc2Ug IChib29sKQogIGluZm8ucHJvZHVjdCA9ICdVU0IgSHViIEludGVyZmFjZScgIChzdHJpbmcp CiAgdXNiLnByb2R1Y3RfaWQgPSAwICAoMHgwKSAgKGludCkKICB1c2IubWF4X3Bvd2VyID0g MCAgKDB4MCkgIChpbnQpCiAgdXNiLm51bV9jb25maWd1cmF0aW9ucyA9IDEgICgweDEpICAo aW50KQogIHVzYi5udW1faW50ZXJmYWNlcyA9IDEgICgweDEpICAoaW50KQogIHVzYi52ZW5k b3JfaWQgPSAwICAoMHgwKSAgKGludCkKICB1c2IubnVtX3BvcnRzID0gNiAgKDB4NikgIChp bnQpCiAgdXNiLmRldmljZV9jbGFzcyA9IDkgICgweDkpICAoaW50KQogIHVzYi5wb3J0X251 bWJlciA9IDEgICgweDEpICAoaW50KQogIHVzYi5kZXZpY2VfcmV2aXNpb25fYmNkID0gMjU2 ICAoMHgxMDApICAoaW50KQogIHVzYi5pbnRlcmZhY2UuY2xhc3MgPSA5ICAoMHg5KSAgKGlu dCkKICBpbmZvLnBhcmVudCA9ICcvb3JnL2ZyZWVkZXNrdG9wL0hhbC9kZXZpY2VzL3VzYl9k ZXZpY2VfMF8wX25vc2VyaWFsXzYnICAoc3RyaW5nKQogIHVzYi5kZXZpY2Vfc3ViY2xhc3Mg PSAwICAoMHgwKSAgKGludCkKICB1c2IuaW50ZXJmYWNlLnN1YmNsYXNzID0gMCAgKDB4MCkg IChpbnQpCiAgdXNiLnByb2R1Y3QgPSAnVVNCIEh1YiBJbnRlcmZhY2UnICAoc3RyaW5nKQog IHVzYi5pbnRlcmZhY2UucHJvdG9jb2wgPSAwICAoMHgwKSAgKGludCkKICBpbmZvLmJ1cyA9 ICd1c2InICAoc3RyaW5nKQogIHVzYi5zcGVlZF9iY2QgPSAyOTQ5MTIgICgweDQ4MDAwKSAg KGludCkKICB1c2IuZGV2aWNlX3Byb3RvY29sID0gMSAgKDB4MSkgIChpbnQpCiAgdXNiLmlu dGVyZmFjZS5udW1iZXIgPSAwICAoMHgwKSAgKGludCkKCjI1OiB1ZGkgPSAnL29yZy9mcmVl ZGVza3RvcC9IYWwvZGV2aWNlcy91c2JfZGV2aWNlXzBfMF9ub3NlcmlhbF82JwogIGluZm8u dmVuZG9yID0gJ0ludGVsJyAgKHN0cmluZykKICB1c2JfZGV2aWNlLnNwZWVkX2JjZCA9IDI5 NDkxMiAgKDB4NDgwMDApICAoaW50KQogIGluZm8udWRpID0gJy9vcmcvZnJlZWRlc2t0b3Av SGFsL2RldmljZXMvdXNiX2RldmljZV8wXzBfbm9zZXJpYWxfNicgIChzdHJpbmcpCiAgaW5m by5zdWJzeXN0ZW0gPSAndXNiX2RldmljZScgIChzdHJpbmcpCiAgdXNiX2RldmljZS5idXNf bnVtYmVyID0gNyAgKDB4NykgIChpbnQpCiAgdXNiX2RldmljZS52ZXJzaW9uX2JjZCA9IDUx MiAgKDB4MjAwKSAgKGludCkKICBpbmZvLnByb2R1Y3QgPSAnRUhDSSByb290IGh1YicgIChz dHJpbmcpCiAgdXNiX2RldmljZS5jb25maWd1cmF0aW9uX3ZhbHVlID0gMSAgKDB4MSkgIChp bnQpCiAgdXNiX2RldmljZS5wcm9kdWN0X2lkID0gMCAgKDB4MCkgIChpbnQpCiAgdXNiX2Rl dmljZS5udW1fY29uZmlndXJhdGlvbnMgPSAxICAoMHgxKSAgKGludCkKICB1c2JfZGV2aWNl LnZlbmRvcl9pZCA9IDAgICgweDApICAoaW50KQogIHVzYl9kZXZpY2UuZGV2aWNlX2NsYXNz ID0gOSAgKDB4OSkgIChpbnQpCiAgdXNiX2RldmljZS5kZXZpY2VfcmV2aXNpb25fYmNkID0g MjU2ICAoMHgxMDApICAoaW50KQogIHVzYl9kZXZpY2UuZGV2aWNlX3N1YmNsYXNzID0gMCAg KDB4MCkgIChpbnQpCiAgdXNiX2RldmljZS5wcm9kdWN0ID0gJ0VIQ0kgcm9vdCBodWInICAo c3RyaW5nKQogIGZyZWVic2QuZHJpdmVyID0gJ3VodWInICAoc3RyaW5nKQogIHVzYl9kZXZp Y2UuZGV2aWNlX3Byb3RvY29sID0gMSAgKDB4MSkgIChpbnQpCiAgdXNiX2RldmljZS52ZW5k b3IgPSAnSW50ZWwnICAoc3RyaW5nKQogIGZyZWVic2QudW5pdCA9IDcgICgweDcpICAoaW50 KQogIHVzYl9kZXZpY2UuaXNfc2VsZl9wb3dlcmVkID0gdHJ1ZSAgKGJvb2wpCiAgdXNiX2Rl dmljZS5jYW5fd2FrZV91cCA9IGZhbHNlICAoYm9vbCkKICBpbmZvLnBhcmVudCA9ICcvb3Jn L2ZyZWVkZXNrdG9wL0hhbC9kZXZpY2VzL3BjaV84MDg2XzI5M2EnICAoc3RyaW5nKQogIHVz Yl9kZXZpY2UubWF4X3Bvd2VyID0gMCAgKDB4MCkgIChpbnQpCiAgdXNiX2RldmljZS5udW1f aW50ZXJmYWNlcyA9IDEgICgweDEpICAoaW50KQogIHVzYl9kZXZpY2UubnVtX3BvcnRzID0g NiAgKDB4NikgIChpbnQpCiAgaW5mby5idXMgPSAndXNiX2RldmljZScgIChzdHJpbmcpCiAg dXNiX2RldmljZS5wb3J0X251bWJlciA9IDEgICgweDEpICAoaW50KQoKMjY6IHVkaSA9ICcv b3JnL2ZyZWVkZXNrdG9wL0hhbC9kZXZpY2VzL3VzYl9kZXZpY2VfMF8wX25vc2VyaWFsXzVf aWYwJwogIHVzYi5idXNfbnVtYmVyID0gNiAgKDB4NikgIChpbnQpCiAgdXNiLnZlbmRvciA9 ICdJbnRlbCcgIChzdHJpbmcpCiAgaW5mby51ZGkgPSAnL29yZy9mcmVlZGVza3RvcC9IYWwv ZGV2aWNlcy91c2JfZGV2aWNlXzBfMF9ub3NlcmlhbF81X2lmMCcgIChzdHJpbmcpCiAgaW5m by5zdWJzeXN0ZW0gPSAndXNiJyAgKHN0cmluZykKICB1c2IudmVyc2lvbl9iY2QgPSAyNTYg ICgweDEwMCkgIChpbnQpCiAgdXNiLmlzX3NlbGZfcG93ZXJlZCA9IHRydWUgIChib29sKQog IHVzYi5jb25maWd1cmF0aW9uX3ZhbHVlID0gMSAgKDB4MSkgIChpbnQpCiAgdXNiLmNhbl93 YWtlX3VwID0gZmFsc2UgIChib29sKQogIGluZm8ucHJvZHVjdCA9ICdVU0IgSHViIEludGVy ZmFjZScgIChzdHJpbmcpCiAgdXNiLnByb2R1Y3RfaWQgPSAwICAoMHgwKSAgKGludCkKICB1 c2IubWF4X3Bvd2VyID0gMCAgKDB4MCkgIChpbnQpCiAgdXNiLm51bV9jb25maWd1cmF0aW9u cyA9IDEgICgweDEpICAoaW50KQogIHVzYi5udW1faW50ZXJmYWNlcyA9IDEgICgweDEpICAo aW50KQogIHVzYi52ZW5kb3JfaWQgPSAwICAoMHgwKSAgKGludCkKICB1c2IubnVtX3BvcnRz ID0gMiAgKDB4MikgIChpbnQpCiAgdXNiLmRldmljZV9jbGFzcyA9IDkgICgweDkpICAoaW50 KQogIHVzYi5wb3J0X251bWJlciA9IDEgICgweDEpICAoaW50KQogIHVzYi5kZXZpY2VfcmV2 aXNpb25fYmNkID0gMjU2ICAoMHgxMDApICAoaW50KQogIHVzYi5pbnRlcmZhY2UuY2xhc3Mg PSA5ICAoMHg5KSAgKGludCkKICBpbmZvLnBhcmVudCA9ICcvb3JnL2ZyZWVkZXNrdG9wL0hh bC9kZXZpY2VzL3VzYl9kZXZpY2VfMF8wX25vc2VyaWFsXzUnICAoc3RyaW5nKQogIHVzYi5k ZXZpY2Vfc3ViY2xhc3MgPSAwICAoMHgwKSAgKGludCkKICB1c2IuaW50ZXJmYWNlLnN1YmNs YXNzID0gMCAgKDB4MCkgIChpbnQpCiAgdXNiLnByb2R1Y3QgPSAnVVNCIEh1YiBJbnRlcmZh Y2UnICAoc3RyaW5nKQogIHVzYi5pbnRlcmZhY2UucHJvdG9jb2wgPSAwICAoMHgwKSAgKGlu dCkKICBpbmZvLmJ1cyA9ICd1c2InICAoc3RyaW5nKQogIHVzYi5zcGVlZF9iY2QgPSA0NjA4 ICAoMHgxMjAwKSAgKGludCkKICB1c2IuZGV2aWNlX3Byb3RvY29sID0gMCAgKDB4MCkgIChp bnQpCiAgdXNiLmludGVyZmFjZS5udW1iZXIgPSAwICAoMHgwKSAgKGludCkKCjI3OiB1ZGkg PSAnL29yZy9mcmVlZGVza3RvcC9IYWwvZGV2aWNlcy91c2JfZGV2aWNlXzBfMF9ub3Nlcmlh bF81JwogIGluZm8udmVuZG9yID0gJ0ludGVsJyAgKHN0cmluZykKICB1c2JfZGV2aWNlLnNw ZWVkX2JjZCA9IDQ2MDggICgweDEyMDApICAoaW50KQogIGluZm8udWRpID0gJy9vcmcvZnJl ZWRlc2t0b3AvSGFsL2RldmljZXMvdXNiX2RldmljZV8wXzBfbm9zZXJpYWxfNScgIChzdHJp bmcpCiAgaW5mby5zdWJzeXN0ZW0gPSAndXNiX2RldmljZScgIChzdHJpbmcpCiAgdXNiX2Rl dmljZS5idXNfbnVtYmVyID0gNiAgKDB4NikgIChpbnQpCiAgdXNiX2RldmljZS52ZXJzaW9u X2JjZCA9IDI1NiAgKDB4MTAwKSAgKGludCkKICBpbmZvLnByb2R1Y3QgPSAnVUhDSSByb290 IGh1YicgIChzdHJpbmcpCiAgdXNiX2RldmljZS5jb25maWd1cmF0aW9uX3ZhbHVlID0gMSAg KDB4MSkgIChpbnQpCiAgdXNiX2RldmljZS5wcm9kdWN0X2lkID0gMCAgKDB4MCkgIChpbnQp CiAgdXNiX2RldmljZS5udW1fY29uZmlndXJhdGlvbnMgPSAxICAoMHgxKSAgKGludCkKICB1 c2JfZGV2aWNlLnZlbmRvcl9pZCA9IDAgICgweDApICAoaW50KQogIHVzYl9kZXZpY2UuZGV2 aWNlX2NsYXNzID0gOSAgKDB4OSkgIChpbnQpCiAgdXNiX2RldmljZS5kZXZpY2VfcmV2aXNp b25fYmNkID0gMjU2ICAoMHgxMDApICAoaW50KQogIHVzYl9kZXZpY2UuZGV2aWNlX3N1YmNs YXNzID0gMCAgKDB4MCkgIChpbnQpCiAgdXNiX2RldmljZS5wcm9kdWN0ID0gJ1VIQ0kgcm9v dCBodWInICAoc3RyaW5nKQogIGZyZWVic2QuZHJpdmVyID0gJ3VodWInICAoc3RyaW5nKQog IHVzYl9kZXZpY2UuZGV2aWNlX3Byb3RvY29sID0gMCAgKDB4MCkgIChpbnQpCiAgdXNiX2Rl dmljZS52ZW5kb3IgPSAnSW50ZWwnICAoc3RyaW5nKQogIGZyZWVic2QudW5pdCA9IDYgICgw eDYpICAoaW50KQogIHVzYl9kZXZpY2UuaXNfc2VsZl9wb3dlcmVkID0gdHJ1ZSAgKGJvb2wp CiAgdXNiX2RldmljZS5jYW5fd2FrZV91cCA9IGZhbHNlICAoYm9vbCkKICBpbmZvLnBhcmVu dCA9ICcvb3JnL2ZyZWVkZXNrdG9wL0hhbC9kZXZpY2VzL3BjaV84MDg2XzI5MzYnICAoc3Ry aW5nKQogIHVzYl9kZXZpY2UubWF4X3Bvd2VyID0gMCAgKDB4MCkgIChpbnQpCiAgdXNiX2Rl dmljZS5udW1faW50ZXJmYWNlcyA9IDEgICgweDEpICAoaW50KQogIHVzYl9kZXZpY2UubnVt X3BvcnRzID0gMiAgKDB4MikgIChpbnQpCiAgaW5mby5idXMgPSAndXNiX2RldmljZScgIChz dHJpbmcpCiAgdXNiX2RldmljZS5wb3J0X251bWJlciA9IDEgICgweDEpICAoaW50KQoKMjg6 IHVkaSA9ICcvb3JnL2ZyZWVkZXNrdG9wL0hhbC9kZXZpY2VzL3VzYl9kZXZpY2VfMF8wX25v c2VyaWFsXzRfaWYwJwogIHVzYi5idXNfbnVtYmVyID0gNSAgKDB4NSkgIChpbnQpCiAgdXNi LnZlbmRvciA9ICdJbnRlbCcgIChzdHJpbmcpCiAgaW5mby51ZGkgPSAnL29yZy9mcmVlZGVz a3RvcC9IYWwvZGV2aWNlcy91c2JfZGV2aWNlXzBfMF9ub3NlcmlhbF80X2lmMCcgIChzdHJp bmcpCiAgaW5mby5zdWJzeXN0ZW0gPSAndXNiJyAgKHN0cmluZykKICB1c2IudmVyc2lvbl9i Y2QgPSAyNTYgICgweDEwMCkgIChpbnQpCiAgdXNiLmlzX3NlbGZfcG93ZXJlZCA9IHRydWUg IChib29sKQogIHVzYi5jb25maWd1cmF0aW9uX3ZhbHVlID0gMSAgKDB4MSkgIChpbnQpCiAg dXNiLmNhbl93YWtlX3VwID0gZmFsc2UgIChib29sKQogIGluZm8ucHJvZHVjdCA9ICdVU0Ig SHViIEludGVyZmFjZScgIChzdHJpbmcpCiAgdXNiLnByb2R1Y3RfaWQgPSAwICAoMHgwKSAg KGludCkKICB1c2IubWF4X3Bvd2VyID0gMCAgKDB4MCkgIChpbnQpCiAgdXNiLm51bV9jb25m aWd1cmF0aW9ucyA9IDEgICgweDEpICAoaW50KQogIHVzYi5udW1faW50ZXJmYWNlcyA9IDEg ICgweDEpICAoaW50KQogIHVzYi52ZW5kb3JfaWQgPSAwICAoMHgwKSAgKGludCkKICB1c2Iu bnVtX3BvcnRzID0gMiAgKDB4MikgIChpbnQpCiAgdXNiLmRldmljZV9jbGFzcyA9IDkgICgw eDkpICAoaW50KQogIHVzYi5wb3J0X251bWJlciA9IDEgICgweDEpICAoaW50KQogIHVzYi5k ZXZpY2VfcmV2aXNpb25fYmNkID0gMjU2ICAoMHgxMDApICAoaW50KQogIHVzYi5pbnRlcmZh Y2UuY2xhc3MgPSA5ICAoMHg5KSAgKGludCkKICBpbmZvLnBhcmVudCA9ICcvb3JnL2ZyZWVk ZXNrdG9wL0hhbC9kZXZpY2VzL3VzYl9kZXZpY2VfMF8wX25vc2VyaWFsXzQnICAoc3RyaW5n KQogIHVzYi5kZXZpY2Vfc3ViY2xhc3MgPSAwICAoMHgwKSAgKGludCkKICB1c2IuaW50ZXJm YWNlLnN1YmNsYXNzID0gMCAgKDB4MCkgIChpbnQpCiAgdXNiLnByb2R1Y3QgPSAnVVNCIEh1 YiBJbnRlcmZhY2UnICAoc3RyaW5nKQogIHVzYi5pbnRlcmZhY2UucHJvdG9jb2wgPSAwICAo MHgwKSAgKGludCkKICBpbmZvLmJ1cyA9ICd1c2InICAoc3RyaW5nKQogIHVzYi5zcGVlZF9i Y2QgPSA0NjA4ICAoMHgxMjAwKSAgKGludCkKICB1c2IuZGV2aWNlX3Byb3RvY29sID0gMCAg KDB4MCkgIChpbnQpCiAgdXNiLmludGVyZmFjZS5udW1iZXIgPSAwICAoMHgwKSAgKGludCkK CjI5OiB1ZGkgPSAnL29yZy9mcmVlZGVza3RvcC9IYWwvZGV2aWNlcy91c2JfZGV2aWNlXzBf MF9ub3NlcmlhbF80JwogIGluZm8udmVuZG9yID0gJ0ludGVsJyAgKHN0cmluZykKICB1c2Jf ZGV2aWNlLnNwZWVkX2JjZCA9IDQ2MDggICgweDEyMDApICAoaW50KQogIGluZm8udWRpID0g Jy9vcmcvZnJlZWRlc2t0b3AvSGFsL2RldmljZXMvdXNiX2RldmljZV8wXzBfbm9zZXJpYWxf NCcgIChzdHJpbmcpCiAgaW5mby5zdWJzeXN0ZW0gPSAndXNiX2RldmljZScgIChzdHJpbmcp CiAgdXNiX2RldmljZS5idXNfbnVtYmVyID0gNSAgKDB4NSkgIChpbnQpCiAgdXNiX2Rldmlj ZS52ZXJzaW9uX2JjZCA9IDI1NiAgKDB4MTAwKSAgKGludCkKICBpbmZvLnByb2R1Y3QgPSAn VUhDSSByb290IGh1YicgIChzdHJpbmcpCiAgdXNiX2RldmljZS5jb25maWd1cmF0aW9uX3Zh bHVlID0gMSAgKDB4MSkgIChpbnQpCiAgdXNiX2RldmljZS5wcm9kdWN0X2lkID0gMCAgKDB4 MCkgIChpbnQpCiAgdXNiX2RldmljZS5udW1fY29uZmlndXJhdGlvbnMgPSAxICAoMHgxKSAg KGludCkKICB1c2JfZGV2aWNlLnZlbmRvcl9pZCA9IDAgICgweDApICAoaW50KQogIHVzYl9k ZXZpY2UuZGV2aWNlX2NsYXNzID0gOSAgKDB4OSkgIChpbnQpCiAgdXNiX2RldmljZS5kZXZp Y2VfcmV2aXNpb25fYmNkID0gMjU2ICAoMHgxMDApICAoaW50KQogIHVzYl9kZXZpY2UuZGV2 aWNlX3N1YmNsYXNzID0gMCAgKDB4MCkgIChpbnQpCiAgdXNiX2RldmljZS5wcm9kdWN0ID0g J1VIQ0kgcm9vdCBodWInICAoc3RyaW5nKQogIGZyZWVic2QuZHJpdmVyID0gJ3VodWInICAo c3RyaW5nKQogIHVzYl9kZXZpY2UuZGV2aWNlX3Byb3RvY29sID0gMCAgKDB4MCkgIChpbnQp CiAgdXNiX2RldmljZS52ZW5kb3IgPSAnSW50ZWwnICAoc3RyaW5nKQogIGZyZWVic2QudW5p dCA9IDUgICgweDUpICAoaW50KQogIHVzYl9kZXZpY2UuaXNfc2VsZl9wb3dlcmVkID0gdHJ1 ZSAgKGJvb2wpCiAgdXNiX2RldmljZS5jYW5fd2FrZV91cCA9IGZhbHNlICAoYm9vbCkKICBp bmZvLnBhcmVudCA9ICcvb3JnL2ZyZWVkZXNrdG9wL0hhbC9kZXZpY2VzL3BjaV84MDg2XzI5 MzUnICAoc3RyaW5nKQogIHVzYl9kZXZpY2UubWF4X3Bvd2VyID0gMCAgKDB4MCkgIChpbnQp CiAgdXNiX2RldmljZS5udW1faW50ZXJmYWNlcyA9IDEgICgweDEpICAoaW50KQogIHVzYl9k ZXZpY2UubnVtX3BvcnRzID0gMiAgKDB4MikgIChpbnQpCiAgaW5mby5idXMgPSAndXNiX2Rl dmljZScgIChzdHJpbmcpCiAgdXNiX2RldmljZS5wb3J0X251bWJlciA9IDEgICgweDEpICAo aW50KQoKMzA6IHVkaSA9ICcvb3JnL2ZyZWVkZXNrdG9wL0hhbC9kZXZpY2VzL3VzYl9kZXZp Y2VfMF8wX25vc2VyaWFsXzNfaWYwJwogIHVzYi5idXNfbnVtYmVyID0gNCAgKDB4NCkgIChp bnQpCiAgdXNiLnZlbmRvciA9ICdJbnRlbCcgIChzdHJpbmcpCiAgaW5mby51ZGkgPSAnL29y Zy9mcmVlZGVza3RvcC9IYWwvZGV2aWNlcy91c2JfZGV2aWNlXzBfMF9ub3NlcmlhbF8zX2lm MCcgIChzdHJpbmcpCiAgaW5mby5zdWJzeXN0ZW0gPSAndXNiJyAgKHN0cmluZykKICB1c2Iu dmVyc2lvbl9iY2QgPSAyNTYgICgweDEwMCkgIChpbnQpCiAgdXNiLmlzX3NlbGZfcG93ZXJl ZCA9IHRydWUgIChib29sKQogIHVzYi5jb25maWd1cmF0aW9uX3ZhbHVlID0gMSAgKDB4MSkg IChpbnQpCiAgdXNiLmNhbl93YWtlX3VwID0gZmFsc2UgIChib29sKQogIGluZm8ucHJvZHVj dCA9ICdVU0IgSHViIEludGVyZmFjZScgIChzdHJpbmcpCiAgdXNiLnByb2R1Y3RfaWQgPSAw ICAoMHgwKSAgKGludCkKICB1c2IubWF4X3Bvd2VyID0gMCAgKDB4MCkgIChpbnQpCiAgdXNi Lm51bV9jb25maWd1cmF0aW9ucyA9IDEgICgweDEpICAoaW50KQogIHVzYi5udW1faW50ZXJm YWNlcyA9IDEgICgweDEpICAoaW50KQogIHVzYi52ZW5kb3JfaWQgPSAwICAoMHgwKSAgKGlu dCkKICB1c2IubnVtX3BvcnRzID0gMiAgKDB4MikgIChpbnQpCiAgdXNiLmRldmljZV9jbGFz cyA9IDkgICgweDkpICAoaW50KQogIHVzYi5wb3J0X251bWJlciA9IDEgICgweDEpICAoaW50 KQogIHVzYi5kZXZpY2VfcmV2aXNpb25fYmNkID0gMjU2ICAoMHgxMDApICAoaW50KQogIHVz Yi5pbnRlcmZhY2UuY2xhc3MgPSA5ICAoMHg5KSAgKGludCkKICBpbmZvLnBhcmVudCA9ICcv b3JnL2ZyZWVkZXNrdG9wL0hhbC9kZXZpY2VzL3VzYl9kZXZpY2VfMF8wX25vc2VyaWFsXzMn ICAoc3RyaW5nKQogIHVzYi5kZXZpY2Vfc3ViY2xhc3MgPSAwICAoMHgwKSAgKGludCkKICB1 c2IuaW50ZXJmYWNlLnN1YmNsYXNzID0gMCAgKDB4MCkgIChpbnQpCiAgdXNiLnByb2R1Y3Qg PSAnVVNCIEh1YiBJbnRlcmZhY2UnICAoc3RyaW5nKQogIHVzYi5pbnRlcmZhY2UucHJvdG9j b2wgPSAwICAoMHgwKSAgKGludCkKICBpbmZvLmJ1cyA9ICd1c2InICAoc3RyaW5nKQogIHVz Yi5zcGVlZF9iY2QgPSA0NjA4ICAoMHgxMjAwKSAgKGludCkKICB1c2IuZGV2aWNlX3Byb3Rv Y29sID0gMCAgKDB4MCkgIChpbnQpCiAgdXNiLmludGVyZmFjZS5udW1iZXIgPSAwICAoMHgw KSAgKGludCkKCjMxOiB1ZGkgPSAnL29yZy9mcmVlZGVza3RvcC9IYWwvZGV2aWNlcy91c2Jf ZGV2aWNlXzBfMF9ub3NlcmlhbF8zJwogIGluZm8udmVuZG9yID0gJ0ludGVsJyAgKHN0cmlu ZykKICB1c2JfZGV2aWNlLnNwZWVkX2JjZCA9IDQ2MDggICgweDEyMDApICAoaW50KQogIGlu Zm8udWRpID0gJy9vcmcvZnJlZWRlc2t0b3AvSGFsL2RldmljZXMvdXNiX2RldmljZV8wXzBf bm9zZXJpYWxfMycgIChzdHJpbmcpCiAgaW5mby5zdWJzeXN0ZW0gPSAndXNiX2RldmljZScg IChzdHJpbmcpCiAgdXNiX2RldmljZS5idXNfbnVtYmVyID0gNCAgKDB4NCkgIChpbnQpCiAg dXNiX2RldmljZS52ZXJzaW9uX2JjZCA9IDI1NiAgKDB4MTAwKSAgKGludCkKICBpbmZvLnBy b2R1Y3QgPSAnVUhDSSByb290IGh1YicgIChzdHJpbmcpCiAgdXNiX2RldmljZS5jb25maWd1 cmF0aW9uX3ZhbHVlID0gMSAgKDB4MSkgIChpbnQpCiAgdXNiX2RldmljZS5wcm9kdWN0X2lk ID0gMCAgKDB4MCkgIChpbnQpCiAgdXNiX2RldmljZS5udW1fY29uZmlndXJhdGlvbnMgPSAx ICAoMHgxKSAgKGludCkKICB1c2JfZGV2aWNlLnZlbmRvcl9pZCA9IDAgICgweDApICAoaW50 KQogIHVzYl9kZXZpY2UuZGV2aWNlX2NsYXNzID0gOSAgKDB4OSkgIChpbnQpCiAgdXNiX2Rl dmljZS5kZXZpY2VfcmV2aXNpb25fYmNkID0gMjU2ICAoMHgxMDApICAoaW50KQogIHVzYl9k ZXZpY2UuZGV2aWNlX3N1YmNsYXNzID0gMCAgKDB4MCkgIChpbnQpCiAgdXNiX2RldmljZS5w cm9kdWN0ID0gJ1VIQ0kgcm9vdCBodWInICAoc3RyaW5nKQogIGZyZWVic2QuZHJpdmVyID0g J3VodWInICAoc3RyaW5nKQogIHVzYl9kZXZpY2UuZGV2aWNlX3Byb3RvY29sID0gMCAgKDB4 MCkgIChpbnQpCiAgdXNiX2RldmljZS52ZW5kb3IgPSAnSW50ZWwnICAoc3RyaW5nKQogIGZy ZWVic2QudW5pdCA9IDQgICgweDQpICAoaW50KQogIHVzYl9kZXZpY2UuaXNfc2VsZl9wb3dl cmVkID0gdHJ1ZSAgKGJvb2wpCiAgdXNiX2RldmljZS5jYW5fd2FrZV91cCA9IGZhbHNlICAo Ym9vbCkKICBpbmZvLnBhcmVudCA9ICcvb3JnL2ZyZWVkZXNrdG9wL0hhbC9kZXZpY2VzL3Bj aV84MDg2XzI5MzQnICAoc3RyaW5nKQogIHVzYl9kZXZpY2UubWF4X3Bvd2VyID0gMCAgKDB4 MCkgIChpbnQpCiAgdXNiX2RldmljZS5udW1faW50ZXJmYWNlcyA9IDEgICgweDEpICAoaW50 KQogIHVzYl9kZXZpY2UubnVtX3BvcnRzID0gMiAgKDB4MikgIChpbnQpCiAgaW5mby5idXMg PSAndXNiX2RldmljZScgIChzdHJpbmcpCiAgdXNiX2RldmljZS5wb3J0X251bWJlciA9IDEg ICgweDEpICAoaW50KQoKMzI6IHVkaSA9ICcvb3JnL2ZyZWVkZXNrdG9wL0hhbC9kZXZpY2Vz L3VzYl9kZXZpY2VfMF8wX25vc2VyaWFsXzJfaWYwJwogIHVzYi5idXNfbnVtYmVyID0gMyAg KDB4MykgIChpbnQpCiAgdXNiLnZlbmRvciA9ICdJbnRlbCcgIChzdHJpbmcpCiAgaW5mby51 ZGkgPSAnL29yZy9mcmVlZGVza3RvcC9IYWwvZGV2aWNlcy91c2JfZGV2aWNlXzBfMF9ub3Nl cmlhbF8yX2lmMCcgIChzdHJpbmcpCiAgaW5mby5zdWJzeXN0ZW0gPSAndXNiJyAgKHN0cmlu ZykKICB1c2IudmVyc2lvbl9iY2QgPSA1MTIgICgweDIwMCkgIChpbnQpCiAgdXNiLmlzX3Nl bGZfcG93ZXJlZCA9IHRydWUgIChib29sKQogIHVzYi5jb25maWd1cmF0aW9uX3ZhbHVlID0g MSAgKDB4MSkgIChpbnQpCiAgdXNiLmNhbl93YWtlX3VwID0gZmFsc2UgIChib29sKQogIGlu Zm8ucHJvZHVjdCA9ICdVU0IgSHViIEludGVyZmFjZScgIChzdHJpbmcpCiAgdXNiLnByb2R1 Y3RfaWQgPSAwICAoMHgwKSAgKGludCkKICB1c2IubWF4X3Bvd2VyID0gMCAgKDB4MCkgIChp bnQpCiAgdXNiLm51bV9jb25maWd1cmF0aW9ucyA9IDEgICgweDEpICAoaW50KQogIHVzYi5u dW1faW50ZXJmYWNlcyA9IDEgICgweDEpICAoaW50KQogIHVzYi52ZW5kb3JfaWQgPSAwICAo MHgwKSAgKGludCkKICB1c2IubnVtX3BvcnRzID0gNiAgKDB4NikgIChpbnQpCiAgdXNiLmRl dmljZV9jbGFzcyA9IDkgICgweDkpICAoaW50KQogIHVzYi5wb3J0X251bWJlciA9IDEgICgw eDEpICAoaW50KQogIHVzYi5kZXZpY2VfcmV2aXNpb25fYmNkID0gMjU2ICAoMHgxMDApICAo aW50KQogIHVzYi5pbnRlcmZhY2UuY2xhc3MgPSA5ICAoMHg5KSAgKGludCkKICBpbmZvLnBh cmVudCA9ICcvb3JnL2ZyZWVkZXNrdG9wL0hhbC9kZXZpY2VzL3VzYl9kZXZpY2VfMF8wX25v c2VyaWFsXzInICAoc3RyaW5nKQogIHVzYi5kZXZpY2Vfc3ViY2xhc3MgPSAwICAoMHgwKSAg KGludCkKICB1c2IuaW50ZXJmYWNlLnN1YmNsYXNzID0gMCAgKDB4MCkgIChpbnQpCiAgdXNi LnByb2R1Y3QgPSAnVVNCIEh1YiBJbnRlcmZhY2UnICAoc3RyaW5nKQogIHVzYi5pbnRlcmZh Y2UucHJvdG9jb2wgPSAwICAoMHgwKSAgKGludCkKICBpbmZvLmJ1cyA9ICd1c2InICAoc3Ry aW5nKQogIHVzYi5zcGVlZF9iY2QgPSAyOTQ5MTIgICgweDQ4MDAwKSAgKGludCkKICB1c2Iu ZGV2aWNlX3Byb3RvY29sID0gMSAgKDB4MSkgIChpbnQpCiAgdXNiLmludGVyZmFjZS5udW1i ZXIgPSAwICAoMHgwKSAgKGludCkKCjMzOiB1ZGkgPSAnL29yZy9mcmVlZGVza3RvcC9IYWwv ZGV2aWNlcy91c2JfZGV2aWNlXzBfMF9ub3NlcmlhbF8yJwogIGluZm8udmVuZG9yID0gJ0lu dGVsJyAgKHN0cmluZykKICB1c2JfZGV2aWNlLnNwZWVkX2JjZCA9IDI5NDkxMiAgKDB4NDgw MDApICAoaW50KQogIGluZm8udWRpID0gJy9vcmcvZnJlZWRlc2t0b3AvSGFsL2RldmljZXMv dXNiX2RldmljZV8wXzBfbm9zZXJpYWxfMicgIChzdHJpbmcpCiAgaW5mby5zdWJzeXN0ZW0g PSAndXNiX2RldmljZScgIChzdHJpbmcpCiAgdXNiX2RldmljZS5idXNfbnVtYmVyID0gMyAg KDB4MykgIChpbnQpCiAgdXNiX2RldmljZS52ZXJzaW9uX2JjZCA9IDUxMiAgKDB4MjAwKSAg KGludCkKICBpbmZvLnByb2R1Y3QgPSAnRUhDSSByb290IGh1YicgIChzdHJpbmcpCiAgdXNi X2RldmljZS5jb25maWd1cmF0aW9uX3ZhbHVlID0gMSAgKDB4MSkgIChpbnQpCiAgdXNiX2Rl dmljZS5wcm9kdWN0X2lkID0gMCAgKDB4MCkgIChpbnQpCiAgdXNiX2RldmljZS5udW1fY29u ZmlndXJhdGlvbnMgPSAxICAoMHgxKSAgKGludCkKICB1c2JfZGV2aWNlLnZlbmRvcl9pZCA9 IDAgICgweDApICAoaW50KQogIHVzYl9kZXZpY2UuZGV2aWNlX2NsYXNzID0gOSAgKDB4OSkg IChpbnQpCiAgdXNiX2RldmljZS5kZXZpY2VfcmV2aXNpb25fYmNkID0gMjU2ICAoMHgxMDAp ICAoaW50KQogIHVzYl9kZXZpY2UuZGV2aWNlX3N1YmNsYXNzID0gMCAgKDB4MCkgIChpbnQp CiAgdXNiX2RldmljZS5wcm9kdWN0ID0gJ0VIQ0kgcm9vdCBodWInICAoc3RyaW5nKQogIGZy ZWVic2QuZHJpdmVyID0gJ3VodWInICAoc3RyaW5nKQogIHVzYl9kZXZpY2UuZGV2aWNlX3By b3RvY29sID0gMSAgKDB4MSkgIChpbnQpCiAgdXNiX2RldmljZS52ZW5kb3IgPSAnSW50ZWwn ICAoc3RyaW5nKQogIGZyZWVic2QudW5pdCA9IDMgICgweDMpICAoaW50KQogIHVzYl9kZXZp Y2UuaXNfc2VsZl9wb3dlcmVkID0gdHJ1ZSAgKGJvb2wpCiAgdXNiX2RldmljZS5jYW5fd2Fr ZV91cCA9IGZhbHNlICAoYm9vbCkKICBpbmZvLnBhcmVudCA9ICcvb3JnL2ZyZWVkZXNrdG9w L0hhbC9kZXZpY2VzL3BjaV84MDg2XzI5M2MnICAoc3RyaW5nKQogIHVzYl9kZXZpY2UubWF4 X3Bvd2VyID0gMCAgKDB4MCkgIChpbnQpCiAgdXNiX2RldmljZS5udW1faW50ZXJmYWNlcyA9 IDEgICgweDEpICAoaW50KQogIHVzYl9kZXZpY2UubnVtX3BvcnRzID0gNiAgKDB4NikgIChp bnQpCiAgaW5mby5idXMgPSAndXNiX2RldmljZScgIChzdHJpbmcpCiAgdXNiX2RldmljZS5w b3J0X251bWJlciA9IDEgICgweDEpICAoaW50KQoKMzQ6IHVkaSA9ICcvb3JnL2ZyZWVkZXNr dG9wL0hhbC9kZXZpY2VzL3VzYl9kZXZpY2VfMF8wX25vc2VyaWFsXzFfaWYwJwogIHVzYi5i dXNfbnVtYmVyID0gMiAgKDB4MikgIChpbnQpCiAgdXNiLnZlbmRvciA9ICdJbnRlbCcgIChz dHJpbmcpCiAgaW5mby51ZGkgPSAnL29yZy9mcmVlZGVza3RvcC9IYWwvZGV2aWNlcy91c2Jf ZGV2aWNlXzBfMF9ub3NlcmlhbF8xX2lmMCcgIChzdHJpbmcpCiAgaW5mby5zdWJzeXN0ZW0g PSAndXNiJyAgKHN0cmluZykKICB1c2IudmVyc2lvbl9iY2QgPSAyNTYgICgweDEwMCkgIChp bnQpCiAgdXNiLmlzX3NlbGZfcG93ZXJlZCA9IHRydWUgIChib29sKQogIHVzYi5jb25maWd1 cmF0aW9uX3ZhbHVlID0gMSAgKDB4MSkgIChpbnQpCiAgdXNiLmNhbl93YWtlX3VwID0gZmFs c2UgIChib29sKQogIGluZm8ucHJvZHVjdCA9ICdVU0IgSHViIEludGVyZmFjZScgIChzdHJp bmcpCiAgdXNiLnByb2R1Y3RfaWQgPSAwICAoMHgwKSAgKGludCkKICB1c2IubWF4X3Bvd2Vy ID0gMCAgKDB4MCkgIChpbnQpCiAgdXNiLm51bV9jb25maWd1cmF0aW9ucyA9IDEgICgweDEp ICAoaW50KQogIHVzYi5udW1faW50ZXJmYWNlcyA9IDEgICgweDEpICAoaW50KQogIHVzYi52 ZW5kb3JfaWQgPSAwICAoMHgwKSAgKGludCkKICB1c2IubnVtX3BvcnRzID0gMiAgKDB4Mikg IChpbnQpCiAgdXNiLmRldmljZV9jbGFzcyA9IDkgICgweDkpICAoaW50KQogIHVzYi5wb3J0 X251bWJlciA9IDEgICgweDEpICAoaW50KQogIHVzYi5kZXZpY2VfcmV2aXNpb25fYmNkID0g MjU2ICAoMHgxMDApICAoaW50KQogIHVzYi5pbnRlcmZhY2UuY2xhc3MgPSA5ICAoMHg5KSAg KGludCkKICBpbmZvLnBhcmVudCA9ICcvb3JnL2ZyZWVkZXNrdG9wL0hhbC9kZXZpY2VzL3Vz Yl9kZXZpY2VfMF8wX25vc2VyaWFsXzEnICAoc3RyaW5nKQogIHVzYi5kZXZpY2Vfc3ViY2xh c3MgPSAwICAoMHgwKSAgKGludCkKICB1c2IuaW50ZXJmYWNlLnN1YmNsYXNzID0gMCAgKDB4 MCkgIChpbnQpCiAgdXNiLnByb2R1Y3QgPSAnVVNCIEh1YiBJbnRlcmZhY2UnICAoc3RyaW5n KQogIHVzYi5pbnRlcmZhY2UucHJvdG9jb2wgPSAwICAoMHgwKSAgKGludCkKICBpbmZvLmJ1 cyA9ICd1c2InICAoc3RyaW5nKQogIHVzYi5zcGVlZF9iY2QgPSA0NjA4ICAoMHgxMjAwKSAg KGludCkKICB1c2IuZGV2aWNlX3Byb3RvY29sID0gMCAgKDB4MCkgIChpbnQpCiAgdXNiLmlu dGVyZmFjZS5udW1iZXIgPSAwICAoMHgwKSAgKGludCkKCjM1OiB1ZGkgPSAnL29yZy9mcmVl ZGVza3RvcC9IYWwvZGV2aWNlcy91c2JfZGV2aWNlXzBfMF9ub3NlcmlhbF8xJwogIGluZm8u dmVuZG9yID0gJ0ludGVsJyAgKHN0cmluZykKICB1c2JfZGV2aWNlLnNwZWVkX2JjZCA9IDQ2 MDggICgweDEyMDApICAoaW50KQogIGluZm8udWRpID0gJy9vcmcvZnJlZWRlc2t0b3AvSGFs L2RldmljZXMvdXNiX2RldmljZV8wXzBfbm9zZXJpYWxfMScgIChzdHJpbmcpCiAgaW5mby5z dWJzeXN0ZW0gPSAndXNiX2RldmljZScgIChzdHJpbmcpCiAgdXNiX2RldmljZS5idXNfbnVt YmVyID0gMiAgKDB4MikgIChpbnQpCiAgdXNiX2RldmljZS52ZXJzaW9uX2JjZCA9IDI1NiAg KDB4MTAwKSAgKGludCkKICBpbmZvLnByb2R1Y3QgPSAnVUhDSSByb290IGh1YicgIChzdHJp bmcpCiAgdXNiX2RldmljZS5jb25maWd1cmF0aW9uX3ZhbHVlID0gMSAgKDB4MSkgIChpbnQp CiAgdXNiX2RldmljZS5wcm9kdWN0X2lkID0gMCAgKDB4MCkgIChpbnQpCiAgdXNiX2Rldmlj ZS5udW1fY29uZmlndXJhdGlvbnMgPSAxICAoMHgxKSAgKGludCkKICB1c2JfZGV2aWNlLnZl bmRvcl9pZCA9IDAgICgweDApICAoaW50KQogIHVzYl9kZXZpY2UuZGV2aWNlX2NsYXNzID0g OSAgKDB4OSkgIChpbnQpCiAgdXNiX2RldmljZS5kZXZpY2VfcmV2aXNpb25fYmNkID0gMjU2 ICAoMHgxMDApICAoaW50KQogIHVzYl9kZXZpY2UuZGV2aWNlX3N1YmNsYXNzID0gMCAgKDB4 MCkgIChpbnQpCiAgdXNiX2RldmljZS5wcm9kdWN0ID0gJ1VIQ0kgcm9vdCBodWInICAoc3Ry aW5nKQogIGZyZWVic2QuZHJpdmVyID0gJ3VodWInICAoc3RyaW5nKQogIHVzYl9kZXZpY2Uu ZGV2aWNlX3Byb3RvY29sID0gMCAgKDB4MCkgIChpbnQpCiAgdXNiX2RldmljZS52ZW5kb3Ig PSAnSW50ZWwnICAoc3RyaW5nKQogIGZyZWVic2QudW5pdCA9IDIgICgweDIpICAoaW50KQog IHVzYl9kZXZpY2UuaXNfc2VsZl9wb3dlcmVkID0gdHJ1ZSAgKGJvb2wpCiAgdXNiX2Rldmlj ZS5jYW5fd2FrZV91cCA9IGZhbHNlICAoYm9vbCkKICBpbmZvLnBhcmVudCA9ICcvb3JnL2Zy ZWVkZXNrdG9wL0hhbC9kZXZpY2VzL3BjaV84MDg2XzI5MzknICAoc3RyaW5nKQogIHVzYl9k ZXZpY2UubWF4X3Bvd2VyID0gMCAgKDB4MCkgIChpbnQpCiAgdXNiX2RldmljZS5udW1faW50 ZXJmYWNlcyA9IDEgICgweDEpICAoaW50KQogIHVzYl9kZXZpY2UubnVtX3BvcnRzID0gMiAg KDB4MikgIChpbnQpCiAgaW5mby5idXMgPSAndXNiX2RldmljZScgIChzdHJpbmcpCiAgdXNi X2RldmljZS5wb3J0X251bWJlciA9IDEgICgweDEpICAoaW50KQoKMzY6IHVkaSA9ICcvb3Jn L2ZyZWVkZXNrdG9wL0hhbC9kZXZpY2VzL3VzYl9kZXZpY2VfMF8wX25vc2VyaWFsXzBfaWYw JwogIHVzYi5idXNfbnVtYmVyID0gMSAgKDB4MSkgIChpbnQpCiAgdXNiLnZlbmRvciA9ICdJ bnRlbCcgIChzdHJpbmcpCiAgaW5mby51ZGkgPSAnL29yZy9mcmVlZGVza3RvcC9IYWwvZGV2 aWNlcy91c2JfZGV2aWNlXzBfMF9ub3NlcmlhbF8wX2lmMCcgIChzdHJpbmcpCiAgaW5mby5z dWJzeXN0ZW0gPSAndXNiJyAgKHN0cmluZykKICB1c2IudmVyc2lvbl9iY2QgPSAyNTYgICgw eDEwMCkgIChpbnQpCiAgdXNiLmlzX3NlbGZfcG93ZXJlZCA9IHRydWUgIChib29sKQogIHVz Yi5jb25maWd1cmF0aW9uX3ZhbHVlID0gMSAgKDB4MSkgIChpbnQpCiAgdXNiLmNhbl93YWtl X3VwID0gZmFsc2UgIChib29sKQogIGluZm8ucHJvZHVjdCA9ICdVU0IgSHViIEludGVyZmFj ZScgIChzdHJpbmcpCiAgdXNiLnByb2R1Y3RfaWQgPSAwICAoMHgwKSAgKGludCkKICB1c2Iu bWF4X3Bvd2VyID0gMCAgKDB4MCkgIChpbnQpCiAgdXNiLm51bV9jb25maWd1cmF0aW9ucyA9 IDEgICgweDEpICAoaW50KQogIHVzYi5udW1faW50ZXJmYWNlcyA9IDEgICgweDEpICAoaW50 KQogIHVzYi52ZW5kb3JfaWQgPSAwICAoMHgwKSAgKGludCkKICB1c2IubnVtX3BvcnRzID0g MiAgKDB4MikgIChpbnQpCiAgdXNiLmRldmljZV9jbGFzcyA9IDkgICgweDkpICAoaW50KQog IHVzYi5wb3J0X251bWJlciA9IDEgICgweDEpICAoaW50KQogIHVzYi5kZXZpY2VfcmV2aXNp b25fYmNkID0gMjU2ICAoMHgxMDApICAoaW50KQogIHVzYi5pbnRlcmZhY2UuY2xhc3MgPSA5 ICAoMHg5KSAgKGludCkKICBpbmZvLnBhcmVudCA9ICcvb3JnL2ZyZWVkZXNrdG9wL0hhbC9k ZXZpY2VzL3VzYl9kZXZpY2VfMF8wX25vc2VyaWFsXzAnICAoc3RyaW5nKQogIHVzYi5kZXZp Y2Vfc3ViY2xhc3MgPSAwICAoMHgwKSAgKGludCkKICB1c2IuaW50ZXJmYWNlLnN1YmNsYXNz ID0gMCAgKDB4MCkgIChpbnQpCiAgdXNiLnByb2R1Y3QgPSAnVVNCIEh1YiBJbnRlcmZhY2Un ICAoc3RyaW5nKQogIHVzYi5pbnRlcmZhY2UucHJvdG9jb2wgPSAwICAoMHgwKSAgKGludCkK ICBpbmZvLmJ1cyA9ICd1c2InICAoc3RyaW5nKQogIHVzYi5zcGVlZF9iY2QgPSA0NjA4ICAo MHgxMjAwKSAgKGludCkKICB1c2IuZGV2aWNlX3Byb3RvY29sID0gMCAgKDB4MCkgIChpbnQp CiAgdXNiLmludGVyZmFjZS5udW1iZXIgPSAwICAoMHgwKSAgKGludCkKCjM3OiB1ZGkgPSAn L29yZy9mcmVlZGVza3RvcC9IYWwvZGV2aWNlcy91c2JfZGV2aWNlXzBfMF9ub3NlcmlhbF8w JwogIGluZm8udmVuZG9yID0gJ0ludGVsJyAgKHN0cmluZykKICB1c2JfZGV2aWNlLnNwZWVk X2JjZCA9IDQ2MDggICgweDEyMDApICAoaW50KQogIGluZm8udWRpID0gJy9vcmcvZnJlZWRl c2t0b3AvSGFsL2RldmljZXMvdXNiX2RldmljZV8wXzBfbm9zZXJpYWxfMCcgIChzdHJpbmcp CiAgaW5mby5zdWJzeXN0ZW0gPSAndXNiX2RldmljZScgIChzdHJpbmcpCiAgdXNiX2Rldmlj ZS5idXNfbnVtYmVyID0gMSAgKDB4MSkgIChpbnQpCiAgdXNiX2RldmljZS52ZXJzaW9uX2Jj ZCA9IDI1NiAgKDB4MTAwKSAgKGludCkKICBpbmZvLnByb2R1Y3QgPSAnVUhDSSByb290IGh1 YicgIChzdHJpbmcpCiAgdXNiX2RldmljZS5jb25maWd1cmF0aW9uX3ZhbHVlID0gMSAgKDB4 MSkgIChpbnQpCiAgdXNiX2RldmljZS5wcm9kdWN0X2lkID0gMCAgKDB4MCkgIChpbnQpCiAg dXNiX2RldmljZS5udW1fY29uZmlndXJhdGlvbnMgPSAxICAoMHgxKSAgKGludCkKICB1c2Jf ZGV2aWNlLnZlbmRvcl9pZCA9IDAgICgweDApICAoaW50KQogIHVzYl9kZXZpY2UuZGV2aWNl X2NsYXNzID0gOSAgKDB4OSkgIChpbnQpCiAgdXNiX2RldmljZS5kZXZpY2VfcmV2aXNpb25f YmNkID0gMjU2ICAoMHgxMDApICAoaW50KQogIHVzYl9kZXZpY2UuZGV2aWNlX3N1YmNsYXNz ID0gMCAgKDB4MCkgIChpbnQpCiAgdXNiX2RldmljZS5wcm9kdWN0ID0gJ1VIQ0kgcm9vdCBo dWInICAoc3RyaW5nKQogIGZyZWVic2QuZHJpdmVyID0gJ3VodWInICAoc3RyaW5nKQogIHVz Yl9kZXZpY2UuZGV2aWNlX3Byb3RvY29sID0gMCAgKDB4MCkgIChpbnQpCiAgdXNiX2Rldmlj ZS52ZW5kb3IgPSAnSW50ZWwnICAoc3RyaW5nKQogIGZyZWVic2QudW5pdCA9IDEgICgweDEp ICAoaW50KQogIHVzYl9kZXZpY2UuaXNfc2VsZl9wb3dlcmVkID0gdHJ1ZSAgKGJvb2wpCiAg dXNiX2RldmljZS5jYW5fd2FrZV91cCA9IGZhbHNlICAoYm9vbCkKICBpbmZvLnBhcmVudCA9 ICcvb3JnL2ZyZWVkZXNrdG9wL0hhbC9kZXZpY2VzL3BjaV84MDg2XzI5MzgnICAoc3RyaW5n KQogIHVzYl9kZXZpY2UubWF4X3Bvd2VyID0gMCAgKDB4MCkgIChpbnQpCiAgdXNiX2Rldmlj ZS5udW1faW50ZXJmYWNlcyA9IDEgICgweDEpICAoaW50KQogIHVzYl9kZXZpY2UubnVtX3Bv cnRzID0gMiAgKDB4MikgIChpbnQpCiAgaW5mby5idXMgPSAndXNiX2RldmljZScgIChzdHJp bmcpCiAgdXNiX2RldmljZS5wb3J0X251bWJlciA9IDEgICgweDEpICAoaW50KQoKMzg6IHVk aSA9ICcvb3JnL2ZyZWVkZXNrdG9wL0hhbC9kZXZpY2VzL3VzYl9kZXZpY2VfMF8wX25vc2Vy aWFsX2lmMCcKICB1c2IuYnVzX251bWJlciA9IDAgICgweDApICAoaW50KQogIHVzYi52ZW5k b3IgPSAnSW50ZWwnICAoc3RyaW5nKQogIGluZm8udWRpID0gJy9vcmcvZnJlZWRlc2t0b3Av SGFsL2RldmljZXMvdXNiX2RldmljZV8wXzBfbm9zZXJpYWxfaWYwJyAgKHN0cmluZykKICBp bmZvLnN1YnN5c3RlbSA9ICd1c2InICAoc3RyaW5nKQogIHVzYi52ZXJzaW9uX2JjZCA9IDI1 NiAgKDB4MTAwKSAgKGludCkKICB1c2IuaXNfc2VsZl9wb3dlcmVkID0gdHJ1ZSAgKGJvb2wp CiAgdXNiLmNvbmZpZ3VyYXRpb25fdmFsdWUgPSAxICAoMHgxKSAgKGludCkKICB1c2IuY2Fu X3dha2VfdXAgPSBmYWxzZSAgKGJvb2wpCiAgaW5mby5wcm9kdWN0ID0gJ1VTQiBIdWIgSW50 ZXJmYWNlJyAgKHN0cmluZykKICB1c2IucHJvZHVjdF9pZCA9IDAgICgweDApICAoaW50KQog IHVzYi5tYXhfcG93ZXIgPSAwICAoMHgwKSAgKGludCkKICB1c2IubnVtX2NvbmZpZ3VyYXRp b25zID0gMSAgKDB4MSkgIChpbnQpCiAgdXNiLm51bV9pbnRlcmZhY2VzID0gMSAgKDB4MSkg IChpbnQpCiAgdXNiLnZlbmRvcl9pZCA9IDAgICgweDApICAoaW50KQogIHVzYi5udW1fcG9y dHMgPSAyICAoMHgyKSAgKGludCkKICB1c2IuZGV2aWNlX2NsYXNzID0gOSAgKDB4OSkgIChp bnQpCiAgdXNiLnBvcnRfbnVtYmVyID0gMSAgKDB4MSkgIChpbnQpCiAgdXNiLmRldmljZV9y ZXZpc2lvbl9iY2QgPSAyNTYgICgweDEwMCkgIChpbnQpCiAgdXNiLmludGVyZmFjZS5jbGFz cyA9IDkgICgweDkpICAoaW50KQogIGluZm8ucGFyZW50ID0gJy9vcmcvZnJlZWRlc2t0b3Av SGFsL2RldmljZXMvdXNiX2RldmljZV8wXzBfbm9zZXJpYWwnICAoc3RyaW5nKQogIHVzYi5k ZXZpY2Vfc3ViY2xhc3MgPSAwICAoMHgwKSAgKGludCkKICB1c2IuaW50ZXJmYWNlLnN1YmNs YXNzID0gMCAgKDB4MCkgIChpbnQpCiAgdXNiLnByb2R1Y3QgPSAnVVNCIEh1YiBJbnRlcmZh Y2UnICAoc3RyaW5nKQogIHVzYi5pbnRlcmZhY2UucHJvdG9jb2wgPSAwICAoMHgwKSAgKGlu dCkKICBpbmZvLmJ1cyA9ICd1c2InICAoc3RyaW5nKQogIHVzYi5zcGVlZF9iY2QgPSA0NjA4 ICAoMHgxMjAwKSAgKGludCkKICB1c2IuZGV2aWNlX3Byb3RvY29sID0gMCAgKDB4MCkgIChp bnQpCiAgdXNiLmludGVyZmFjZS5udW1iZXIgPSAwICAoMHgwKSAgKGludCkKCjM5OiB1ZGkg PSAnL29yZy9mcmVlZGVza3RvcC9IYWwvZGV2aWNlcy91c2JfZGV2aWNlXzBfMF9ub3Nlcmlh bCcKICBpbmZvLnZlbmRvciA9ICdJbnRlbCcgIChzdHJpbmcpCiAgdXNiX2RldmljZS5zcGVl ZF9iY2QgPSA0NjA4ICAoMHgxMjAwKSAgKGludCkKICBpbmZvLnVkaSA9ICcvb3JnL2ZyZWVk ZXNrdG9wL0hhbC9kZXZpY2VzL3VzYl9kZXZpY2VfMF8wX25vc2VyaWFsJyAgKHN0cmluZykK ICBpbmZvLnN1YnN5c3RlbSA9ICd1c2JfZGV2aWNlJyAgKHN0cmluZykKICB1c2JfZGV2aWNl LmJ1c19udW1iZXIgPSAwICAoMHgwKSAgKGludCkKICB1c2JfZGV2aWNlLnZlcnNpb25fYmNk ID0gMjU2ICAoMHgxMDApICAoaW50KQogIGluZm8ucHJvZHVjdCA9ICdVSENJIHJvb3QgaHVi JyAgKHN0cmluZykKICB1c2JfZGV2aWNlLmNvbmZpZ3VyYXRpb25fdmFsdWUgPSAxICAoMHgx KSAgKGludCkKICB1c2JfZGV2aWNlLnByb2R1Y3RfaWQgPSAwICAoMHgwKSAgKGludCkKICB1 c2JfZGV2aWNlLm51bV9jb25maWd1cmF0aW9ucyA9IDEgICgweDEpICAoaW50KQogIHVzYl9k ZXZpY2UudmVuZG9yX2lkID0gMCAgKDB4MCkgIChpbnQpCiAgdXNiX2RldmljZS5kZXZpY2Vf Y2xhc3MgPSA5ICAoMHg5KSAgKGludCkKICB1c2JfZGV2aWNlLmRldmljZV9yZXZpc2lvbl9i Y2QgPSAyNTYgICgweDEwMCkgIChpbnQpCiAgdXNiX2RldmljZS5kZXZpY2Vfc3ViY2xhc3Mg PSAwICAoMHgwKSAgKGludCkKICB1c2JfZGV2aWNlLnByb2R1Y3QgPSAnVUhDSSByb290IGh1 YicgIChzdHJpbmcpCiAgZnJlZWJzZC5kcml2ZXIgPSAndWh1YicgIChzdHJpbmcpCiAgdXNi X2RldmljZS5kZXZpY2VfcHJvdG9jb2wgPSAwICAoMHgwKSAgKGludCkKICB1c2JfZGV2aWNl LnZlbmRvciA9ICdJbnRlbCcgIChzdHJpbmcpCiAgZnJlZWJzZC51bml0ID0gMCAgKDB4MCkg IChpbnQpCiAgdXNiX2RldmljZS5pc19zZWxmX3Bvd2VyZWQgPSB0cnVlICAoYm9vbCkKICB1 c2JfZGV2aWNlLmNhbl93YWtlX3VwID0gZmFsc2UgIChib29sKQogIGluZm8ucGFyZW50ID0g Jy9vcmcvZnJlZWRlc2t0b3AvSGFsL2RldmljZXMvcGNpXzgwODZfMjkzNycgIChzdHJpbmcp CiAgdXNiX2RldmljZS5tYXhfcG93ZXIgPSAwICAoMHgwKSAgKGludCkKICB1c2JfZGV2aWNl Lm51bV9pbnRlcmZhY2VzID0gMSAgKDB4MSkgIChpbnQpCiAgdXNiX2RldmljZS5udW1fcG9y dHMgPSAyICAoMHgyKSAgKGludCkKICBpbmZvLmJ1cyA9ICd1c2JfZGV2aWNlJyAgKHN0cmlu ZykKICB1c2JfZGV2aWNlLnBvcnRfbnVtYmVyID0gMSAgKDB4MSkgIChpbnQpCgo0MDogdWRp ID0gJy9vcmcvZnJlZWRlc2t0b3AvSGFsL2RldmljZXMvYWNwaV9hY2FkXzAnCiAgaW5mby51 ZGkgPSAnL29yZy9mcmVlZGVza3RvcC9IYWwvZGV2aWNlcy9hY3BpX2FjYWRfMCcgIChzdHJp bmcpCiAgYWNfYWRhcHRlci5wcmVzZW50ID0gdHJ1ZSAgKGJvb2wpCiAgaW5mby5zdWJzeXN0 ZW0gPSAncGxhdGZvcm0nICAoc3RyaW5nKQogIGluZm8ucHJvZHVjdCA9ICdBQyBBZGFwdGVy JyAgKHN0cmluZykKICBmcmVlYnNkLmRyaXZlciA9ICdhY3BpX2FjYWQnICAoc3RyaW5nKQog IHBsYXRmb3JtLmlkID0gJ2FjcGlfYWNhZC4wJyAgKHN0cmluZykKICBmcmVlYnNkLnVuaXQg PSAwICAoMHgwKSAgKGludCkKICBwbnAuaWQgPSAnQUNQSTAwMDMnICAoc3RyaW5nKQogIGlu Zm8ucGFyZW50ID0gJy9vcmcvZnJlZWRlc2t0b3AvSGFsL2RldmljZXMvY29tcHV0ZXInICAo c3RyaW5nKQogIGluZm8uY2FwYWJpbGl0aWVzID0geyAnYWNfYWRhcHRlcicgfSAoc3RyaW5n IGxpc3QpCiAgaW5mby5jYXRlZ29yeSA9ICdhY19hZGFwdGVyJyAgKHN0cmluZykKCjQxOiB1 ZGkgPSAnL29yZy9mcmVlZGVza3RvcC9IYWwvZGV2aWNlcy9hY3BpX2J1dHRvbl8wJwogIGlu Zm8udWRpID0gJy9vcmcvZnJlZWRlc2t0b3AvSGFsL2RldmljZXMvYWNwaV9idXR0b25fMCcg IChzdHJpbmcpCiAgaW5mby5zdWJzeXN0ZW0gPSAncGxhdGZvcm0nICAoc3RyaW5nKQogIGlu Zm8ucHJvZHVjdCA9ICdTbGVlcCBCdXR0b24nICAoc3RyaW5nKQogIGZyZWVic2QuZHJpdmVy ID0gJ2FjcGlfYnV0dG9uJyAgKHN0cmluZykKICBwbGF0Zm9ybS5pZCA9ICdhY3BpX2J1dHRv bi4wJyAgKHN0cmluZykKICBmcmVlYnNkLnVuaXQgPSAwICAoMHgwKSAgKGludCkKICBwbnAu aWQgPSAnUE5QMEMwRScgIChzdHJpbmcpCiAgcG5wLmRlc2NyaXB0aW9uID0gJ0FDUEkgc2xl ZXAgYnV0dG9uIGRldmljZScgIChzdHJpbmcpCiAgYnV0dG9uLnR5cGUgPSAnc2xlZXAnICAo c3RyaW5nKQogIGluZm8ucGFyZW50ID0gJy9vcmcvZnJlZWRlc2t0b3AvSGFsL2RldmljZXMv Y29tcHV0ZXInICAoc3RyaW5nKQogIGluZm8uY2FwYWJpbGl0aWVzID0geyAnYnV0dG9uJyB9 IChzdHJpbmcgbGlzdCkKICBpbmZvLmNhdGVnb3J5ID0gJ2J1dHRvbicgIChzdHJpbmcpCgo0 MjogdWRpID0gJy9vcmcvZnJlZWRlc2t0b3AvSGFsL2RldmljZXMvYWNwaV9saWRfMCcKICBp bmZvLnVkaSA9ICcvb3JnL2ZyZWVkZXNrdG9wL0hhbC9kZXZpY2VzL2lnbm9yZWQtZGV2aWNl JyAgKHN0cmluZykKICBpbmZvLnN1YnN5c3RlbSA9ICdwbGF0Zm9ybScgIChzdHJpbmcpCiAg aW5mby5wcm9kdWN0ID0gJ0lnbm9yZWQgRGV2aWNlJyAgKHN0cmluZykKICBmcmVlYnNkLmRy aXZlciA9ICdhY3BpX2xpZCcgIChzdHJpbmcpCiAgcGxhdGZvcm0uaWQgPSAnYWNwaV9saWQu MCcgIChzdHJpbmcpCiAgZnJlZWJzZC51bml0ID0gMCAgKDB4MCkgIChpbnQpCiAgcG5wLmlk ID0gJ1BOUDBDMEQnICAoc3RyaW5nKQogIHBucC5kZXNjcmlwdGlvbiA9ICdBQ1BJIGxpZCBk ZXZpY2UnICAoc3RyaW5nKQogIGJ1dHRvbi50eXBlID0gJ2xpZCcgIChzdHJpbmcpCiAgaW5m by5wYXJlbnQgPSAnL29yZy9mcmVlZGVza3RvcC9IYWwvZGV2aWNlcy9jb21wdXRlcicgIChz dHJpbmcpCiAgaW5mby5pZ25vcmUgPSB0cnVlICAoYm9vbCkKICBidXR0b24uaGFzX3N0YXRl ID0gdHJ1ZSAgKGJvb2wpCiAgYnV0dG9uLnN0YXRlLnZhbHVlID0gZmFsc2UgIChib29sKQoK NDM6IHVkaSA9ICcvb3JnL2ZyZWVkZXNrdG9wL0hhbC9kZXZpY2VzL2FjcGlfdHpfMCcKICBp bmZvLnVkaSA9ICcvb3JnL2ZyZWVkZXNrdG9wL0hhbC9kZXZpY2VzL2FjcGlfdHpfMCcgIChz dHJpbmcpCiAgaW5mby5zdWJzeXN0ZW0gPSAncGxhdGZvcm0nICAoc3RyaW5nKQogIGluZm8u cHJvZHVjdCA9ICdUaGVybWFsIFpvbmUnICAoc3RyaW5nKQogIGZyZWVic2QuZHJpdmVyID0g J2FjcGlfdHonICAoc3RyaW5nKQogIHNlbnNvci50eXBlID0gJ3RlbXBlcmF0dXJlJyAgKHN0 cmluZykKICBwbGF0Zm9ybS5pZCA9ICdhY3BpX3R6LjAnICAoc3RyaW5nKQogIGZyZWVic2Qu dW5pdCA9IDAgICgweDApICAoaW50KQogIHNlbnNvci5sb2NhdGlvbiA9ICdjcHUnICAoc3Ry aW5nKQogIGluZm8ucGFyZW50ID0gJy9vcmcvZnJlZWRlc2t0b3AvSGFsL2RldmljZXMvY29t cHV0ZXInICAoc3RyaW5nKQogIGluZm8uY2FwYWJpbGl0aWVzID0geyAnc2Vuc29yJyB9IChz dHJpbmcgbGlzdCkKICBpbmZvLmNhdGVnb3J5ID0gJ3NlbnNvcicgIChzdHJpbmcpCgo0NDog dWRpID0gJy9vcmcvZnJlZWRlc2t0b3AvSGFsL2RldmljZXMvYWNwaV92aWRlb18wJwogIGlu Zm8udWRpID0gJy9vcmcvZnJlZWRlc2t0b3AvSGFsL2RldmljZXMvYWNwaV92aWRlb18wJyAg KHN0cmluZykKICBpbmZvLnN1YnN5c3RlbSA9ICdwbGF0Zm9ybScgIChzdHJpbmcpCiAgaW5m by5wcm9kdWN0ID0gJ0FDUEkgdmlkZW8gZXh0ZW5zaW9uJyAgKHN0cmluZykKICBmcmVlYnNk LmRyaXZlciA9ICdhY3BpX3ZpZGVvJyAgKHN0cmluZykKICBwbGF0Zm9ybS5pZCA9ICdhY3Bp X3ZpZGVvLjAnICAoc3RyaW5nKQogIGZyZWVic2QudW5pdCA9IDAgICgweDApICAoaW50KQog IGluZm8ucGFyZW50ID0gJy9vcmcvZnJlZWRlc2t0b3AvSGFsL2RldmljZXMvcGNpXzgwODZf MmE0MicgIChzdHJpbmcpCgo0NTogdWRpID0gJy9vcmcvZnJlZWRlc2t0b3AvSGFsL2Rldmlj ZXMvaWRlX2hvc3RfMCcKICBpbmZvLnVkaSA9ICcvb3JnL2ZyZWVkZXNrdG9wL0hhbC9kZXZp Y2VzL2lkZV9ob3N0XzAnICAoc3RyaW5nKQogIGluZm8uc3Vic3lzdGVtID0gJ2lkZV9ob3N0 JyAgKHN0cmluZykKICBpZGVfaG9zdC5udW1iZXIgPSAwICAoMHgwKSAgKGludCkKICBmcmVl YnNkLmRyaXZlciA9ICdhdGEnICAoc3RyaW5nKQogIGZyZWVic2QudW5pdCA9IDAgICgweDAp ICAoaW50KQogIGluZm8ucGFyZW50ID0gJy9vcmcvZnJlZWRlc2t0b3AvSGFsL2RldmljZXMv cGNpXzgwODZfMjkxOScgIChzdHJpbmcpCgo0NjogdWRpID0gJy9vcmcvZnJlZWRlc2t0b3Av SGFsL2RldmljZXMvaWRlX2hvc3RfMScKICBpbmZvLnVkaSA9ICcvb3JnL2ZyZWVkZXNrdG9w L0hhbC9kZXZpY2VzL2lkZV9ob3N0XzEnICAoc3RyaW5nKQogIGluZm8uc3Vic3lzdGVtID0g J2lkZV9ob3N0JyAgKHN0cmluZykKICBpZGVfaG9zdC5udW1iZXIgPSAxICAoMHgxKSAgKGlu dCkKICBmcmVlYnNkLmRyaXZlciA9ICdhdGEnICAoc3RyaW5nKQogIGZyZWVic2QudW5pdCA9 IDEgICgweDEpICAoaW50KQogIGluZm8ucGFyZW50ID0gJy9vcmcvZnJlZWRlc2t0b3AvSGFs L2RldmljZXMvcGNpXzgwODZfMjkxOScgIChzdHJpbmcpCgo0NzogdWRpID0gJy9vcmcvZnJl ZWRlc2t0b3AvSGFsL2RldmljZXMvaWRlX2hvc3RfMicKICBpbmZvLnVkaSA9ICcvb3JnL2Zy ZWVkZXNrdG9wL0hhbC9kZXZpY2VzL2lkZV9ob3N0XzInICAoc3RyaW5nKQogIGluZm8uc3Vi c3lzdGVtID0gJ2lkZV9ob3N0JyAgKHN0cmluZykKICBpbmZvLnByb2R1Y3QgPSAnQVRBIGNo YW5uZWwgMCcgIChzdHJpbmcpCiAgaWRlX2hvc3QubnVtYmVyID0gMiAgKDB4MikgIChpbnQp CiAgZnJlZWJzZC5kcml2ZXIgPSAnYXRhJyAgKHN0cmluZykKICBmcmVlYnNkLnVuaXQgPSAy ICAoMHgyKSAgKGludCkKICBpbmZvLnBhcmVudCA9ICcvb3JnL2ZyZWVkZXNrdG9wL0hhbC9k ZXZpY2VzL3BjaV84MDg2XzI5MjknICAoc3RyaW5nKQoKNDg6IHVkaSA9ICcvb3JnL2ZyZWVk ZXNrdG9wL0hhbC9kZXZpY2VzL2lkZV9ob3N0XzMnCiAgaW5mby51ZGkgPSAnL29yZy9mcmVl ZGVza3RvcC9IYWwvZGV2aWNlcy9pZGVfaG9zdF8zJyAgKHN0cmluZykKICBpbmZvLnN1YnN5 c3RlbSA9ICdpZGVfaG9zdCcgIChzdHJpbmcpCiAgaW5mby5wcm9kdWN0ID0gJ0FUQSBjaGFu bmVsIDEnICAoc3RyaW5nKQogIGlkZV9ob3N0Lm51bWJlciA9IDMgICgweDMpICAoaW50KQog IGZyZWVic2QuZHJpdmVyID0gJ2F0YScgIChzdHJpbmcpCiAgZnJlZWJzZC51bml0ID0gMyAg KDB4MykgIChpbnQpCiAgaW5mby5wYXJlbnQgPSAnL29yZy9mcmVlZGVza3RvcC9IYWwvZGV2 aWNlcy9wY2lfODA4Nl8yOTI5JyAgKHN0cmluZykKCjQ5OiB1ZGkgPSAnL29yZy9mcmVlZGVz a3RvcC9IYWwvZGV2aWNlcy9pZGVfaG9zdF80JwogIGluZm8udWRpID0gJy9vcmcvZnJlZWRl c2t0b3AvSGFsL2RldmljZXMvaWRlX2hvc3RfNCcgIChzdHJpbmcpCiAgaW5mby5zdWJzeXN0 ZW0gPSAnaWRlX2hvc3QnICAoc3RyaW5nKQogIGluZm8ucHJvZHVjdCA9ICdBVEEgY2hhbm5l bCAyJyAgKHN0cmluZykKICBpZGVfaG9zdC5udW1iZXIgPSA0ICAoMHg0KSAgKGludCkKICBm cmVlYnNkLmRyaXZlciA9ICdhdGEnICAoc3RyaW5nKQogIGZyZWVic2QudW5pdCA9IDQgICgw eDQpICAoaW50KQogIGluZm8ucGFyZW50ID0gJy9vcmcvZnJlZWRlc2t0b3AvSGFsL2Rldmlj ZXMvcGNpXzgwODZfMjkyOScgIChzdHJpbmcpCgo1MDogdWRpID0gJy9vcmcvZnJlZWRlc2t0 b3AvSGFsL2RldmljZXMvaWRlX2hvc3RfNScKICBpbmZvLnVkaSA9ICcvb3JnL2ZyZWVkZXNr dG9wL0hhbC9kZXZpY2VzL2lkZV9ob3N0XzUnICAoc3RyaW5nKQogIGluZm8uc3Vic3lzdGVt ID0gJ2lkZV9ob3N0JyAgKHN0cmluZykKICBpbmZvLnByb2R1Y3QgPSAnQVRBIGNoYW5uZWwg MycgIChzdHJpbmcpCiAgaWRlX2hvc3QubnVtYmVyID0gNSAgKDB4NSkgIChpbnQpCiAgZnJl ZWJzZC5kcml2ZXIgPSAnYXRhJyAgKHN0cmluZykKICBmcmVlYnNkLnVuaXQgPSA1ICAoMHg1 KSAgKGludCkKICBpbmZvLnBhcmVudCA9ICcvb3JnL2ZyZWVkZXNrdG9wL0hhbC9kZXZpY2Vz L3BjaV84MDg2XzI5MjknICAoc3RyaW5nKQoKNTE6IHVkaSA9ICcvb3JnL2ZyZWVkZXNrdG9w L0hhbC9kZXZpY2VzL2lkZV9ob3N0XzYnCiAgaW5mby51ZGkgPSAnL29yZy9mcmVlZGVza3Rv cC9IYWwvZGV2aWNlcy9pZGVfaG9zdF82JyAgKHN0cmluZykKICBpbmZvLnN1YnN5c3RlbSA9 ICdpZGVfaG9zdCcgIChzdHJpbmcpCiAgaW5mby5wcm9kdWN0ID0gJ0FUQSBjaGFubmVsIDQn ICAoc3RyaW5nKQogIGlkZV9ob3N0Lm51bWJlciA9IDYgICgweDYpICAoaW50KQogIGZyZWVi c2QuZHJpdmVyID0gJ2F0YScgIChzdHJpbmcpCiAgZnJlZWJzZC51bml0ID0gNiAgKDB4Nikg IChpbnQpCiAgaW5mby5wYXJlbnQgPSAnL29yZy9mcmVlZGVza3RvcC9IYWwvZGV2aWNlcy9w Y2lfODA4Nl8yOTI5JyAgKHN0cmluZykKCjUyOiB1ZGkgPSAnL29yZy9mcmVlZGVza3RvcC9I YWwvZGV2aWNlcy9pZGVfaG9zdF83JwogIGluZm8udWRpID0gJy9vcmcvZnJlZWRlc2t0b3Av SGFsL2RldmljZXMvaWRlX2hvc3RfNycgIChzdHJpbmcpCiAgaW5mby5zdWJzeXN0ZW0gPSAn aWRlX2hvc3QnICAoc3RyaW5nKQogIGluZm8ucHJvZHVjdCA9ICdBVEEgY2hhbm5lbCA1JyAg KHN0cmluZykKICBpZGVfaG9zdC5udW1iZXIgPSA3ICAoMHg3KSAgKGludCkKICBmcmVlYnNk LmRyaXZlciA9ICdhdGEnICAoc3RyaW5nKQogIGZyZWVic2QudW5pdCA9IDcgICgweDcpICAo aW50KQogIGluZm8ucGFyZW50ID0gJy9vcmcvZnJlZWRlc2t0b3AvSGFsL2RldmljZXMvcGNp XzgwODZfMjkyOScgIChzdHJpbmcpCgo1MzogdWRpID0gJy9vcmcvZnJlZWRlc2t0b3AvSGFs L2RldmljZXMvYXRrYmRfMCcKICBpbmZvLnVkaSA9ICcvb3JnL2ZyZWVkZXNrdG9wL0hhbC9k ZXZpY2VzL2F0a2JkXzAnICAoc3RyaW5nKQogIGlucHV0LmRldmljZSA9ICcnICAoc3RyaW5n KQogIGluZm8uc3Vic3lzdGVtID0gJ3BsYXRmb3JtJyAgKHN0cmluZykKICBpbnB1dC54MTFf ZHJpdmVyID0gJ2tiZCcgIChzdHJpbmcpCiAgaW5mby5wcm9kdWN0ID0gJ0FUIEtleWJvYXJk JyAgKHN0cmluZykKICBmcmVlYnNkLmRyaXZlciA9ICdhdGtiZCcgIChzdHJpbmcpCiAgcGxh dGZvcm0uaWQgPSAnYXRrYmQuMCcgIChzdHJpbmcpCiAgZnJlZWJzZC51bml0ID0gMCAgKDB4 MCkgIChpbnQpCiAgaW5mby5wYXJlbnQgPSAnL29yZy9mcmVlZGVza3RvcC9IYWwvZGV2aWNl cy9hdGtiZGNfMCcgIChzdHJpbmcpCiAgZnJlZWJzZC5kZXZpY2VfZmlsZSA9ICcvZGV2L2F0 a2JkMCcgIChzdHJpbmcpCiAgaW5mby5jYXBhYmlsaXRpZXMgPSB7ICdpbnB1dCcsICdpbnB1 dC5rZXlib2FyZCcgfSAoc3RyaW5nIGxpc3QpCiAgaW5mby5jYXRlZ29yeSA9ICdpbnB1dC5r ZXlib2FyZCcgIChzdHJpbmcpCgo1NDogdWRpID0gJy9vcmcvZnJlZWRlc2t0b3AvSGFsL2Rl dmljZXMvYmF0dGVyeV8wJwogIGJhdHRlcnkucmVwb3J0aW5nLmxhc3RfZnVsbCA9IDUyMjMw ICAoMHhjYzA2KSAgKGludCkKICBiYXR0ZXJ5LnJlcG9ydGluZy5sb3cgPSAxNTU0ICAoMHg2 MTIpICAoaW50KQogIGJhdHRlcnkucmVwb3J0aW5nLndhcm5pbmcgPSA1MTgwICAoMHgxNDNj KSAgKGludCkKICBiYXR0ZXJ5LmNoYXJnZV9sZXZlbC51bml0ID0gJ21XaCcgIChzdHJpbmcp CiAgaW5mby51ZGkgPSAnL29yZy9mcmVlZGVza3RvcC9IYWwvZGV2aWNlcy9iYXR0ZXJ5XzAn ICAoc3RyaW5nKQogIGJhdHRlcnkucmVwb3J0aW5nLnVuaXQgPSAnbVdoJyAgKHN0cmluZykK ICBmcmVlYnNkLmRyaXZlciA9ICdiYXR0ZXJ5JyAgKHN0cmluZykKICBpbmZvLnN1YnN5c3Rl bSA9ICdwbGF0Zm9ybScgIChzdHJpbmcpCiAgYmF0dGVyeS5jaGFyZ2VfbGV2ZWwuZGVzaWdu ID0gNTE4NDAgICgweGNhODApICAoaW50KQogIGZyZWVic2QudW5pdCA9IDAgICgweDApICAo aW50KQogIGluZm8ucHJvZHVjdCA9ICdBQ1BJIENvbnRyb2wgTWV0aG9kIEJhdHRlcnknICAo c3RyaW5nKQogIGJhdHRlcnkuY2hhcmdlX2xldmVsLmxhc3RfZnVsbCA9IDUyMjMwICAoMHhj YzA2KSAgKGludCkKICBiYXR0ZXJ5LmNoYXJnZV9sZXZlbC5jdXJyZW50ID0gNTE4NDAgICgw eGNhODApICAoaW50KQogIGJhdHRlcnkuY2hhcmdlX2xldmVsLnJhdGUgPSAwICAoMHgwKSAg KGludCkKICBiYXR0ZXJ5LmNoYXJnZV9sZXZlbC53YXJuaW5nID0gNTE4MCAgKDB4MTQzYykg IChpbnQpCiAgYmF0dGVyeS5jaGFyZ2VfbGV2ZWwubG93ID0gMTU1NCAgKDB4NjEyKSAgKGlu dCkKICBpbmZvLnZlbmRvciA9ICcnICAoc3RyaW5nKQogIGJhdHRlcnkuY2hhcmdlX2xldmVs LmdyYW51bGFyaXR5XzEgPSA1MTggICgweDIwNikgIChpbnQpCiAgYmF0dGVyeS5jaGFyZ2Vf bGV2ZWwuZ3JhbnVsYXJpdHlfMiA9IDUxOCAgKDB4MjA2KSAgKGludCkKICBiYXR0ZXJ5Lmlz X3JlY2hhcmdlYWJsZSA9IHRydWUgIChib29sKQogIGJhdHRlcnkuY2hhcmdlX2xldmVsLnBl cmNlbnRhZ2UgPSA5OSAgKDB4NjMpICAoaW50KQogIGJhdHRlcnkucmVjaGFyZ2VhYmxlLmlz X2NoYXJnaW5nID0gZmFsc2UgIChib29sKQogIHBsYXRmb3JtLmlkID0gJ2JhdHRlcnkuMCcg IChzdHJpbmcpCiAgcG5wLmlkID0gJ1BOUDBDMEEnICAoc3RyaW5nKQogIGJhdHRlcnkucmVj aGFyZ2VhYmxlLmlzX2Rpc2NoYXJnaW5nID0gZmFsc2UgIChib29sKQogIHBucC5kZXNjcmlw dGlvbiA9ICdBQ1BJIENvbnRyb2wgTWV0aG9kIEJhdHRlcnknICAoc3RyaW5nKQogIGJhdHRl cnkudmVuZG9yID0gJycgIChzdHJpbmcpCiAgYmF0dGVyeS5tb2RlbCA9ICcnICAoc3RyaW5n KQogIGluZm8uY2FwYWJpbGl0aWVzID0geyAnYmF0dGVyeScgfSAoc3RyaW5nIGxpc3QpCiAg YmF0dGVyeS50ZWNobm9sb2d5ID0gJycgIChzdHJpbmcpCiAgaW5mby5jYXRlZ29yeSA9ICdi YXR0ZXJ5JyAgKHN0cmluZykKICBiYXR0ZXJ5LnNlcmlhbCA9ICcnICAoc3RyaW5nKQogIGJh dHRlcnkudHlwZSA9ICdwcmltYXJ5JyAgKHN0cmluZykKICBiYXR0ZXJ5LnByZXNlbnQgPSB0 cnVlICAoYm9vbCkKICBiYXR0ZXJ5LnZvbHRhZ2UudW5pdCA9ICdtVicgIChzdHJpbmcpCiAg YmF0dGVyeS52b2x0YWdlLmN1cnJlbnQgPSAxMjQ4NiAgKDB4MzBjNikgIChpbnQpCiAgaW5m by5wYXJlbnQgPSAnL29yZy9mcmVlZGVza3RvcC9IYWwvZGV2aWNlcy9jb21wdXRlcicgIChz dHJpbmcpCiAgYmF0dGVyeS52b2x0YWdlLmRlc2lnbiA9IDEwODAwICAoMHgyYTMwKSAgKGlu dCkKICBiYXR0ZXJ5LnJlcG9ydGluZy5kZXNpZ24gPSA1MTg0MCAgKDB4Y2E4MCkgIChpbnQp CiAgYmF0dGVyeS5yZXBvcnRpbmcuY3VycmVudCA9IDUxODQwICAoMHhjYTgwKSAgKGludCkK ICBiYXR0ZXJ5LnJlcG9ydGluZy5yYXRlID0gMCAgKDB4MCkgIChpbnQpCgo1NTogdWRpID0g Jy9vcmcvZnJlZWRlc2t0b3AvSGFsL2RldmljZXMvY3B1XzAnCiAgaW5mby51ZGkgPSAnL29y Zy9mcmVlZGVza3RvcC9IYWwvZGV2aWNlcy9jcHVfMCcgIChzdHJpbmcpCiAgaW5mby5zdWJz eXN0ZW0gPSAncGxhdGZvcm0nICAoc3RyaW5nKQogIGluZm8ucHJvZHVjdCA9ICdBQ1BJIENQ VScgIChzdHJpbmcpCiAgZnJlZWJzZC5kcml2ZXIgPSAnY3B1JyAgKHN0cmluZykKICBwcm9j ZXNzb3IubnVtYmVyID0gMCAgKDB4MCkgIChpbnQpCiAgcGxhdGZvcm0uaWQgPSAnY3B1LjAn ICAoc3RyaW5nKQogIGZyZWVic2QudW5pdCA9IDAgICgweDApICAoaW50KQogIHByb2Nlc3Nv ci5jYW5fdGhyb3R0bGUgPSB0cnVlICAoYm9vbCkKICBwcm9jZXNzb3IubWF4aW11bV9zcGVl ZCA9IDE4MDAgICgweDcwOCkgIChpbnQpCiAgaW5mby5wYXJlbnQgPSAnL29yZy9mcmVlZGVz a3RvcC9IYWwvZGV2aWNlcy9jb21wdXRlcicgIChzdHJpbmcpCiAgaW5mby5jYXBhYmlsaXRp ZXMgPSB7ICdwcm9jZXNzb3InIH0gKHN0cmluZyBsaXN0KQogIGluZm8uY2F0ZWdvcnkgPSAn cHJvY2Vzc29yJyAgKHN0cmluZykKCjU2OiB1ZGkgPSAnL29yZy9mcmVlZGVza3RvcC9IYWwv ZGV2aWNlcy9jcHVfMScKICBpbmZvLnVkaSA9ICcvb3JnL2ZyZWVkZXNrdG9wL0hhbC9kZXZp Y2VzL2NwdV8xJyAgKHN0cmluZykKICBpbmZvLnN1YnN5c3RlbSA9ICdwbGF0Zm9ybScgIChz dHJpbmcpCiAgaW5mby5wcm9kdWN0ID0gJ0FDUEkgQ1BVJyAgKHN0cmluZykKICBmcmVlYnNk LmRyaXZlciA9ICdjcHUnICAoc3RyaW5nKQogIHByb2Nlc3Nvci5udW1iZXIgPSAxICAoMHgx KSAgKGludCkKICBwbGF0Zm9ybS5pZCA9ICdjcHUuMScgIChzdHJpbmcpCiAgZnJlZWJzZC51 bml0ID0gMSAgKDB4MSkgIChpbnQpCiAgcHJvY2Vzc29yLmNhbl90aHJvdHRsZSA9IHRydWUg IChib29sKQogIHByb2Nlc3Nvci5tYXhpbXVtX3NwZWVkID0gMTgwMCAgKDB4NzA4KSAgKGlu dCkKICBpbmZvLnBhcmVudCA9ICcvb3JnL2ZyZWVkZXNrdG9wL0hhbC9kZXZpY2VzL2NvbXB1 dGVyJyAgKHN0cmluZykKICBpbmZvLmNhcGFiaWxpdGllcyA9IHsgJ3Byb2Nlc3NvcicgfSAo c3RyaW5nIGxpc3QpCiAgaW5mby5jYXRlZ29yeSA9ICdwcm9jZXNzb3InICAoc3RyaW5nKQoK NTc6IHVkaSA9ICcvb3JnL2ZyZWVkZXNrdG9wL0hhbC9kZXZpY2VzL3BjaV84MDg2XzJhNDJf ZHJtX2k5MTVfY2FyZDAnCiAgaW5mby51ZGkgPSAnL29yZy9mcmVlZGVza3RvcC9IYWwvZGV2 aWNlcy9wY2lfODA4Nl8yYTQyX2RybV9pOTE1X2NhcmQwJyAgKHN0cmluZykKICBpbmZvLnZl bmRvciA9ICdJbnRlbCBHcmFwaGljcycgIChzdHJpbmcpCiAgaW5mby5zdWJzeXN0ZW0gPSAn ZHJtJyAgKHN0cmluZykKICBpbmZvLnByb2R1Y3QgPSAnRGlyZWN0IFJlbmRlcmluZyBNYW5h Z2VyIERldmljZScgIChzdHJpbmcpCiAgZHJtLmRyaV9saWJyYXJ5ID0gJ2k5MTUnICAoc3Ry aW5nKQogIGRybS52ZXJzaW9uID0gJ2RybSAxLjYuMCAyMDA4MDczMCcgIChzdHJpbmcpCiAg ZnJlZWJzZC5kcml2ZXIgPSAnZHJtJyAgKHN0cmluZykKICBmcmVlYnNkLnVuaXQgPSAwICAo MHgwKSAgKGludCkKICBpbmZvLnBhcmVudCA9ICcvb3JnL2ZyZWVkZXNrdG9wL0hhbC9kZXZp Y2VzL3BjaV84MDg2XzJhNDInICAoc3RyaW5nKQogIGZyZWVic2QuZGV2aWNlX2ZpbGUgPSAn L2Rldi9kcmkvY2FyZDAnICAoc3RyaW5nKQogIGluZm8uY2FwYWJpbGl0aWVzID0geyAnZHJt JyB9IChzdHJpbmcgbGlzdCkKICBpbmZvLmNhdGVnb3J5ID0gJ2RybScgIChzdHJpbmcpCgo1 ODogdWRpID0gJy9vcmcvZnJlZWRlc2t0b3AvSGFsL2RldmljZXMvcGNtXzAnCiAgaW5mby51 ZGkgPSAnL29yZy9mcmVlZGVza3RvcC9IYWwvZGV2aWNlcy9wY21fMCcgIChzdHJpbmcpCiAg aW5mby5zdWJzeXN0ZW0gPSAncGxhdGZvcm0nICAoc3RyaW5nKQogIGluZm8ucHJvZHVjdCA9 ICdIREEgQ29uZXhhbnQgQ1gyMDU2MSAoSGVybW9zYSkgUENNICMwIEFuYWxvZycgIChzdHJp bmcpCiAgZnJlZWJzZC5kcml2ZXIgPSAncGNtJyAgKHN0cmluZykKICBwbGF0Zm9ybS5pZCA9 ICdwY20uMCcgIChzdHJpbmcpCiAgZnJlZWJzZC51bml0ID0gMCAgKDB4MCkgIChpbnQpCiAg aW5mby5wYXJlbnQgPSAnL29yZy9mcmVlZGVza3RvcC9IYWwvZGV2aWNlcy9wY2lfODA4Nl8y OTNlJyAgKHN0cmluZykKCjU5OiB1ZGkgPSAnL29yZy9mcmVlZGVza3RvcC9IYWwvZGV2aWNl cy9wY21fMScKICBpbmZvLnVkaSA9ICcvb3JnL2ZyZWVkZXNrdG9wL0hhbC9kZXZpY2VzL3Bj bV8xJyAgKHN0cmluZykKICBpbmZvLnN1YnN5c3RlbSA9ICdwbGF0Zm9ybScgIChzdHJpbmcp CiAgaW5mby5wcm9kdWN0ID0gJ0hEQSBDb25leGFudCBDWDIwNTYxIChIZXJtb3NhKSBQQ00g IzEgQW5hbG9nJyAgKHN0cmluZykKICBmcmVlYnNkLmRyaXZlciA9ICdwY20nICAoc3RyaW5n KQogIHBsYXRmb3JtLmlkID0gJ3BjbS4xJyAgKHN0cmluZykKICBmcmVlYnNkLnVuaXQgPSAx ICAoMHgxKSAgKGludCkKICBpbmZvLnBhcmVudCA9ICcvb3JnL2ZyZWVkZXNrdG9wL0hhbC9k ZXZpY2VzL3BjaV84MDg2XzI5M2UnICAoc3RyaW5nKQoKNjA6IHVkaSA9ICcvb3JnL2ZyZWVk ZXNrdG9wL0hhbC9kZXZpY2VzL3BjbV8yJwogIGluZm8udWRpID0gJy9vcmcvZnJlZWRlc2t0 b3AvSGFsL2RldmljZXMvcGNtXzInICAoc3RyaW5nKQogIGluZm8uc3Vic3lzdGVtID0gJ3Bs YXRmb3JtJyAgKHN0cmluZykKICBpbmZvLnByb2R1Y3QgPSAnSERBIEludGVsIEc0NSBIRE1J IFBDTSAjMCBEaWdpdGFsJyAgKHN0cmluZykKICBmcmVlYnNkLmRyaXZlciA9ICdwY20nICAo c3RyaW5nKQogIHBsYXRmb3JtLmlkID0gJ3BjbS4yJyAgKHN0cmluZykKICBmcmVlYnNkLnVu aXQgPSAyICAoMHgyKSAgKGludCkKICBpbmZvLnBhcmVudCA9ICcvb3JnL2ZyZWVkZXNrdG9w L0hhbC9kZXZpY2VzL3BjaV84MDg2XzI5M2UnICAoc3RyaW5nKQoKNjE6IHVkaSA9ICcvb3Jn L2ZyZWVkZXNrdG9wL0hhbC9kZXZpY2VzL2F0a2JkY18wJwogIGluZm8udWRpID0gJy9vcmcv ZnJlZWRlc2t0b3AvSGFsL2RldmljZXMvYXRrYmRjXzAnICAoc3RyaW5nKQogIGluZm8uc3Vi c3lzdGVtID0gJ3BsYXRmb3JtJyAgKHN0cmluZykKICBpbmZvLnByb2R1Y3QgPSAnS2V5Ym9h cmQgY29udHJvbGxlciAoaTgwNDIpJyAgKHN0cmluZykKICBmcmVlYnNkLmRyaXZlciA9ICdh dGtiZGMnICAoc3RyaW5nKQogIHBsYXRmb3JtLmlkID0gJ2F0a2JkYy4wJyAgKHN0cmluZykK ICBmcmVlYnNkLnVuaXQgPSAwICAoMHgwKSAgKGludCkKICBwbnAuaWQgPSAnUE5QMDMwMycg IChzdHJpbmcpCiAgcG5wLmRlc2NyaXB0aW9uID0gJ0lCTSBFbmhhbmNlZCAoMTAxLzEwMi1r ZXksIFBTLzIgbW91c2Ugc3VwcG9ydCknICAoc3RyaW5nKQogIGluZm8ucGFyZW50ID0gJy9v cmcvZnJlZWRlc2t0b3AvSGFsL2RldmljZXMvY29tcHV0ZXInICAoc3RyaW5nKQoKNjI6IHVk aSA9ICcvb3JnL2ZyZWVkZXNrdG9wL0hhbC9kZXZpY2VzL3Npb18wJwogIGluZm8udWRpID0g Jy9vcmcvZnJlZWRlc2t0b3AvSGFsL2RldmljZXMvc2lvXzAnICAoc3RyaW5nKQogIGluZm8u c3Vic3lzdGVtID0gJ3BsYXRmb3JtJyAgKHN0cmluZykKICBmcmVlYnNkLmRyaXZlciA9ICdz aW8nICAoc3RyaW5nKQogIHBsYXRmb3JtLmlkID0gJ3Npby4wJyAgKHN0cmluZykKICBmcmVl YnNkLnVuaXQgPSAwICAoMHgwKSAgKGludCkKICBpbmZvLnBhcmVudCA9ICcvb3JnL2ZyZWVk ZXNrdG9wL0hhbC9kZXZpY2VzL3BjaV84MDg2XzI5MTknICAoc3RyaW5nKQoKNjM6IHVkaSA9 ICcvb3JnL2ZyZWVkZXNrdG9wL0hhbC9kZXZpY2VzL3BjaV84MDg2XzJhNDAnCiAgaW5mby51 ZGkgPSAnL29yZy9mcmVlZGVza3RvcC9IYWwvZGV2aWNlcy9wY2lfODA4Nl8yYTQwJyAgKHN0 cmluZykKICBwY2kuZGV2aWNlX3Byb3RvY29sID0gMCAgKDB4MCkgIChpbnQpCiAgaW5mby52 ZW5kb3IgPSAnSW50ZWwgQ29ycG9yYXRpb24nICAoc3RyaW5nKQogIGluZm8uc3Vic3lzdGVt ID0gJ3BjaScgIChzdHJpbmcpCiAgcGNpLnByb2R1Y3RfaWQgPSAxMDgxNiAgKDB4MmE0MCkg IChpbnQpCiAgcGNpLnZlbmRvciA9ICdJbnRlbCBDb3Jwb3JhdGlvbicgIChzdHJpbmcpCiAg cGNpLnZlbmRvcl9pZCA9IDMyOTAyICAoMHg4MDg2KSAgKGludCkKICBpbmZvLnByb2R1Y3Qg PSAnTW9iaWxlIDQgU2VyaWVzIENoaXBzZXQgTWVtb3J5IENvbnRyb2xsZXIgSHViJyAgKHN0 cmluZykKICBwY2kucHJvZHVjdCA9ICdNb2JpbGUgNCBTZXJpZXMgQ2hpcHNldCBNZW1vcnkg Q29udHJvbGxlciBIdWInICAoc3RyaW5nKQogIHBjaS5zdWJzeXNfcHJvZHVjdF9pZCA9IDg0 MTYgICgweDIwZTApICAoaW50KQogIHBjaS5zdWJzeXNfdmVuZG9yID0gJ0xlbm92bycgIChz dHJpbmcpCiAgcGNpLnN1YnN5c192ZW5kb3JfaWQgPSA2MDU4ICAoMHgxN2FhKSAgKGludCkK ICBmcmVlYnNkLmRyaXZlciA9ICdob3N0YicgIChzdHJpbmcpCiAgZnJlZWJzZC51bml0ID0g MCAgKDB4MCkgIChpbnQpCiAgcGNpLmZyZWVic2QuYnVzID0gMCAgKDB4MCkgIChpbnQpCiAg aW5mby5wYXJlbnQgPSAnL29yZy9mcmVlZGVza3RvcC9IYWwvZGV2aWNlcy9jb21wdXRlcicg IChzdHJpbmcpCiAgcGNpLmZyZWVic2QuZGV2aWNlID0gMCAgKDB4MCkgIChpbnQpCiAgcGNp LmRldmljZV9jbGFzcyA9IDYgICgweDYpICAoaW50KQogIHBjaS5mcmVlYnNkLmZ1bmN0aW9u ID0gMCAgKDB4MCkgIChpbnQpCiAgcGNpLmRldmljZV9zdWJjbGFzcyA9IDAgICgweDApICAo aW50KQogIHBjaS5mcmVlYnNkLnNlY29uZGFyeV9idXMgPSAwICAoMHgwKSAgKGludCkKCjY0 OiB1ZGkgPSAnL29yZy9mcmVlZGVza3RvcC9IYWwvZGV2aWNlcy9wY2lfODA4Nl8yYTQyJwog IGluZm8udWRpID0gJy9vcmcvZnJlZWRlc2t0b3AvSGFsL2RldmljZXMvcGNpXzgwODZfMmE0 MicgIChzdHJpbmcpCiAgcGNpLmRldmljZV9wcm90b2NvbCA9IDAgICgweDApICAoaW50KQog IGluZm8udmVuZG9yID0gJ0ludGVsIENvcnBvcmF0aW9uJyAgKHN0cmluZykKICBpbmZvLnN1 YnN5c3RlbSA9ICdwY2knICAoc3RyaW5nKQogIHBjaS5wcm9kdWN0X2lkID0gMTA4MTggICgw eDJhNDIpICAoaW50KQogIHBjaS52ZW5kb3IgPSAnSW50ZWwgQ29ycG9yYXRpb24nICAoc3Ry aW5nKQogIHBjaS52ZW5kb3JfaWQgPSAzMjkwMiAgKDB4ODA4NikgIChpbnQpCiAgaW5mby5w cm9kdWN0ID0gJ01vYmlsZSA0IFNlcmllcyBDaGlwc2V0IEludGVncmF0ZWQgR3JhcGhpY3Mg Q29udHJvbGxlcicgIChzdHJpbmcpCiAgcGNpLnByb2R1Y3QgPSAnTW9iaWxlIDQgU2VyaWVz IENoaXBzZXQgSW50ZWdyYXRlZCBHcmFwaGljcyBDb250cm9sbGVyJyAgKHN0cmluZykKICBw Y2kuc3Vic3lzX3Byb2R1Y3RfaWQgPSA4NDIwICAoMHgyMGU0KSAgKGludCkKICBwY2kuc3Vi c3lzX3ZlbmRvciA9ICdMZW5vdm8nICAoc3RyaW5nKQogIHBjaS5zdWJzeXNfdmVuZG9yX2lk ID0gNjA1OCAgKDB4MTdhYSkgIChpbnQpCiAgZnJlZWJzZC5kcml2ZXIgPSAndmdhcGNpJyAg KHN0cmluZykKICBmcmVlYnNkLnVuaXQgPSAwICAoMHgwKSAgKGludCkKICBwY2kuZnJlZWJz ZC5idXMgPSAwICAoMHgwKSAgKGludCkKICBpbmZvLnBhcmVudCA9ICcvb3JnL2ZyZWVkZXNr dG9wL0hhbC9kZXZpY2VzL2NvbXB1dGVyJyAgKHN0cmluZykKICBwY2kuZnJlZWJzZC5kZXZp Y2UgPSAyICAoMHgyKSAgKGludCkKICBwY2kuZGV2aWNlX2NsYXNzID0gMyAgKDB4MykgIChp bnQpCiAgcGNpLmZyZWVic2QuZnVuY3Rpb24gPSAwICAoMHgwKSAgKGludCkKICBwY2kuZGV2 aWNlX3N1YmNsYXNzID0gMCAgKDB4MCkgIChpbnQpCiAgcGNpLmZyZWVic2Quc2Vjb25kYXJ5 X2J1cyA9IDAgICgweDApICAoaW50KQoKNjU6IHVkaSA9ICcvb3JnL2ZyZWVkZXNrdG9wL0hh bC9kZXZpY2VzL3BjaV84MDg2XzJhNDMnCiAgaW5mby51ZGkgPSAnL29yZy9mcmVlZGVza3Rv cC9IYWwvZGV2aWNlcy9wY2lfODA4Nl8yYTQzJyAgKHN0cmluZykKICBwY2kuZGV2aWNlX3By b3RvY29sID0gMCAgKDB4MCkgIChpbnQpCiAgaW5mby52ZW5kb3IgPSAnSW50ZWwgQ29ycG9y YXRpb24nICAoc3RyaW5nKQogIGluZm8uc3Vic3lzdGVtID0gJ3BjaScgIChzdHJpbmcpCiAg cGNpLnByb2R1Y3RfaWQgPSAxMDgxOSAgKDB4MmE0MykgIChpbnQpCiAgcGNpLnZlbmRvciA9 ICdJbnRlbCBDb3Jwb3JhdGlvbicgIChzdHJpbmcpCiAgcGNpLnZlbmRvcl9pZCA9IDMyOTAy ICAoMHg4MDg2KSAgKGludCkKICBpbmZvLnByb2R1Y3QgPSAnTW9iaWxlIDQgU2VyaWVzIENo aXBzZXQgSW50ZWdyYXRlZCBHcmFwaGljcyBDb250cm9sbGVyJyAgKHN0cmluZykKICBwY2ku cHJvZHVjdCA9ICdNb2JpbGUgNCBTZXJpZXMgQ2hpcHNldCBJbnRlZ3JhdGVkIEdyYXBoaWNz IENvbnRyb2xsZXInICAoc3RyaW5nKQogIHBjaS5zdWJzeXNfcHJvZHVjdF9pZCA9IDg0MjAg ICgweDIwZTQpICAoaW50KQogIHBjaS5zdWJzeXNfdmVuZG9yID0gJ0xlbm92bycgIChzdHJp bmcpCiAgcGNpLnN1YnN5c192ZW5kb3JfaWQgPSA2MDU4ICAoMHgxN2FhKSAgKGludCkKICBm cmVlYnNkLmRyaXZlciA9ICd2Z2FwY2knICAoc3RyaW5nKQogIGZyZWVic2QudW5pdCA9IDEg ICgweDEpICAoaW50KQogIHBjaS5mcmVlYnNkLmJ1cyA9IDAgICgweDApICAoaW50KQogIGlu Zm8ucGFyZW50ID0gJy9vcmcvZnJlZWRlc2t0b3AvSGFsL2RldmljZXMvY29tcHV0ZXInICAo c3RyaW5nKQogIHBjaS5mcmVlYnNkLmRldmljZSA9IDIgICgweDIpICAoaW50KQogIHBjaS5k ZXZpY2VfY2xhc3MgPSAzICAoMHgzKSAgKGludCkKICBwY2kuZnJlZWJzZC5mdW5jdGlvbiA9 IDEgICgweDEpICAoaW50KQogIHBjaS5kZXZpY2Vfc3ViY2xhc3MgPSAxMjggICgweDgwKSAg KGludCkKICBwY2kuZnJlZWJzZC5zZWNvbmRhcnlfYnVzID0gMCAgKDB4MCkgIChpbnQpCgo2 NjogdWRpID0gJy9vcmcvZnJlZWRlc2t0b3AvSGFsL2RldmljZXMvcGNpXzgwODZfMjkzNycK ICBpbmZvLnVkaSA9ICcvb3JnL2ZyZWVkZXNrdG9wL0hhbC9kZXZpY2VzL3BjaV84MDg2XzI5 MzcnICAoc3RyaW5nKQogIHBjaS5kZXZpY2VfcHJvdG9jb2wgPSAwICAoMHgwKSAgKGludCkK ICBpbmZvLnZlbmRvciA9ICdJbnRlbCBDb3Jwb3JhdGlvbicgIChzdHJpbmcpCiAgaW5mby5z dWJzeXN0ZW0gPSAncGNpJyAgKHN0cmluZykKICBwY2kucHJvZHVjdF9pZCA9IDEwNTUxICAo MHgyOTM3KSAgKGludCkKICBwY2kudmVuZG9yID0gJ0ludGVsIENvcnBvcmF0aW9uJyAgKHN0 cmluZykKICBwY2kudmVuZG9yX2lkID0gMzI5MDIgICgweDgwODYpICAoaW50KQogIGluZm8u cHJvZHVjdCA9ICc4MjgwMUkgKElDSDkgRmFtaWx5KSBVU0IgVUhDSSBDb250cm9sbGVyICM0 JyAgKHN0cmluZykKICBwY2kucHJvZHVjdCA9ICc4MjgwMUkgKElDSDkgRmFtaWx5KSBVU0Ig VUhDSSBDb250cm9sbGVyICM0JyAgKHN0cmluZykKICBwY2kuc3Vic3lzX3Byb2R1Y3RfaWQg PSA4NDMyICAoMHgyMGYwKSAgKGludCkKICBwY2kuc3Vic3lzX3ZlbmRvciA9ICdMZW5vdm8n ICAoc3RyaW5nKQogIHBjaS5zdWJzeXNfdmVuZG9yX2lkID0gNjA1OCAgKDB4MTdhYSkgIChp bnQpCiAgZnJlZWJzZC5kcml2ZXIgPSAndWhjaScgIChzdHJpbmcpCiAgZnJlZWJzZC51bml0 ID0gMCAgKDB4MCkgIChpbnQpCiAgcGNpLmZyZWVic2QuYnVzID0gMCAgKDB4MCkgIChpbnQp CiAgaW5mby5wYXJlbnQgPSAnL29yZy9mcmVlZGVza3RvcC9IYWwvZGV2aWNlcy9jb21wdXRl cicgIChzdHJpbmcpCiAgcGNpLmZyZWVic2QuZGV2aWNlID0gMjYgICgweDFhKSAgKGludCkK ICBwY2kuZGV2aWNlX2NsYXNzID0gMTIgICgweGMpICAoaW50KQogIHBjaS5mcmVlYnNkLmZ1 bmN0aW9uID0gMCAgKDB4MCkgIChpbnQpCiAgcGNpLmRldmljZV9zdWJjbGFzcyA9IDMgICgw eDMpICAoaW50KQogIHBjaS5mcmVlYnNkLnNlY29uZGFyeV9idXMgPSAwICAoMHgwKSAgKGlu dCkKCjY3OiB1ZGkgPSAnL29yZy9mcmVlZGVza3RvcC9IYWwvZGV2aWNlcy9wY2lfODA4Nl8y OTM4JwogIGluZm8udWRpID0gJy9vcmcvZnJlZWRlc2t0b3AvSGFsL2RldmljZXMvcGNpXzgw ODZfMjkzOCcgIChzdHJpbmcpCiAgcGNpLmRldmljZV9wcm90b2NvbCA9IDAgICgweDApICAo aW50KQogIGluZm8udmVuZG9yID0gJ0ludGVsIENvcnBvcmF0aW9uJyAgKHN0cmluZykKICBp bmZvLnN1YnN5c3RlbSA9ICdwY2knICAoc3RyaW5nKQogIHBjaS5wcm9kdWN0X2lkID0gMTA1 NTIgICgweDI5MzgpICAoaW50KQogIHBjaS52ZW5kb3IgPSAnSW50ZWwgQ29ycG9yYXRpb24n ICAoc3RyaW5nKQogIHBjaS52ZW5kb3JfaWQgPSAzMjkwMiAgKDB4ODA4NikgIChpbnQpCiAg aW5mby5wcm9kdWN0ID0gJzgyODAxSSAoSUNIOSBGYW1pbHkpIFVTQiBVSENJIENvbnRyb2xs ZXIgIzUnICAoc3RyaW5nKQogIHBjaS5wcm9kdWN0ID0gJzgyODAxSSAoSUNIOSBGYW1pbHkp IFVTQiBVSENJIENvbnRyb2xsZXIgIzUnICAoc3RyaW5nKQogIHBjaS5zdWJzeXNfcHJvZHVj dF9pZCA9IDg0MzIgICgweDIwZjApICAoaW50KQogIHBjaS5zdWJzeXNfdmVuZG9yID0gJ0xl bm92bycgIChzdHJpbmcpCiAgcGNpLnN1YnN5c192ZW5kb3JfaWQgPSA2MDU4ICAoMHgxN2Fh KSAgKGludCkKICBmcmVlYnNkLmRyaXZlciA9ICd1aGNpJyAgKHN0cmluZykKICBmcmVlYnNk LnVuaXQgPSAxICAoMHgxKSAgKGludCkKICBwY2kuZnJlZWJzZC5idXMgPSAwICAoMHgwKSAg KGludCkKICBpbmZvLnBhcmVudCA9ICcvb3JnL2ZyZWVkZXNrdG9wL0hhbC9kZXZpY2VzL2Nv bXB1dGVyJyAgKHN0cmluZykKICBwY2kuZnJlZWJzZC5kZXZpY2UgPSAyNiAgKDB4MWEpICAo aW50KQogIHBjaS5kZXZpY2VfY2xhc3MgPSAxMiAgKDB4YykgIChpbnQpCiAgcGNpLmZyZWVi c2QuZnVuY3Rpb24gPSAxICAoMHgxKSAgKGludCkKICBwY2kuZGV2aWNlX3N1YmNsYXNzID0g MyAgKDB4MykgIChpbnQpCiAgcGNpLmZyZWVic2Quc2Vjb25kYXJ5X2J1cyA9IDAgICgweDAp ICAoaW50KQoKNjg6IHVkaSA9ICcvb3JnL2ZyZWVkZXNrdG9wL0hhbC9kZXZpY2VzL3BjaV84 MDg2XzI5MzknCiAgaW5mby51ZGkgPSAnL29yZy9mcmVlZGVza3RvcC9IYWwvZGV2aWNlcy9w Y2lfODA4Nl8yOTM5JyAgKHN0cmluZykKICBwY2kuZGV2aWNlX3Byb3RvY29sID0gMCAgKDB4 MCkgIChpbnQpCiAgaW5mby52ZW5kb3IgPSAnSW50ZWwgQ29ycG9yYXRpb24nICAoc3RyaW5n KQogIGluZm8uc3Vic3lzdGVtID0gJ3BjaScgIChzdHJpbmcpCiAgcGNpLnByb2R1Y3RfaWQg PSAxMDU1MyAgKDB4MjkzOSkgIChpbnQpCiAgcGNpLnZlbmRvciA9ICdJbnRlbCBDb3Jwb3Jh dGlvbicgIChzdHJpbmcpCiAgcGNpLnZlbmRvcl9pZCA9IDMyOTAyICAoMHg4MDg2KSAgKGlu dCkKICBpbmZvLnByb2R1Y3QgPSAnODI4MDFJIChJQ0g5IEZhbWlseSkgVVNCIFVIQ0kgQ29u dHJvbGxlciAjNicgIChzdHJpbmcpCiAgcGNpLnByb2R1Y3QgPSAnODI4MDFJIChJQ0g5IEZh bWlseSkgVVNCIFVIQ0kgQ29udHJvbGxlciAjNicgIChzdHJpbmcpCiAgcGNpLnN1YnN5c19w cm9kdWN0X2lkID0gODQzMiAgKDB4MjBmMCkgIChpbnQpCiAgcGNpLnN1YnN5c192ZW5kb3Ig PSAnTGVub3ZvJyAgKHN0cmluZykKICBwY2kuc3Vic3lzX3ZlbmRvcl9pZCA9IDYwNTggICgw eDE3YWEpICAoaW50KQogIGZyZWVic2QuZHJpdmVyID0gJ3VoY2knICAoc3RyaW5nKQogIGZy ZWVic2QudW5pdCA9IDIgICgweDIpICAoaW50KQogIHBjaS5mcmVlYnNkLmJ1cyA9IDAgICgw eDApICAoaW50KQogIGluZm8ucGFyZW50ID0gJy9vcmcvZnJlZWRlc2t0b3AvSGFsL2Rldmlj ZXMvY29tcHV0ZXInICAoc3RyaW5nKQogIHBjaS5mcmVlYnNkLmRldmljZSA9IDI2ICAoMHgx YSkgIChpbnQpCiAgcGNpLmRldmljZV9jbGFzcyA9IDEyICAoMHhjKSAgKGludCkKICBwY2ku ZnJlZWJzZC5mdW5jdGlvbiA9IDIgICgweDIpICAoaW50KQogIHBjaS5kZXZpY2Vfc3ViY2xh c3MgPSAzICAoMHgzKSAgKGludCkKICBwY2kuZnJlZWJzZC5zZWNvbmRhcnlfYnVzID0gMCAg KDB4MCkgIChpbnQpCgo2OTogdWRpID0gJy9vcmcvZnJlZWRlc2t0b3AvSGFsL2RldmljZXMv cGNpXzgwODZfMjkzYycKICBpbmZvLnVkaSA9ICcvb3JnL2ZyZWVkZXNrdG9wL0hhbC9kZXZp Y2VzL3BjaV84MDg2XzI5M2MnICAoc3RyaW5nKQogIHBjaS5kZXZpY2VfcHJvdG9jb2wgPSAz MiAgKDB4MjApICAoaW50KQogIGluZm8udmVuZG9yID0gJ0ludGVsIENvcnBvcmF0aW9uJyAg KHN0cmluZykKICBpbmZvLnN1YnN5c3RlbSA9ICdwY2knICAoc3RyaW5nKQogIHBjaS5wcm9k dWN0X2lkID0gMTA1NTYgICgweDI5M2MpICAoaW50KQogIHBjaS52ZW5kb3IgPSAnSW50ZWwg Q29ycG9yYXRpb24nICAoc3RyaW5nKQogIHBjaS52ZW5kb3JfaWQgPSAzMjkwMiAgKDB4ODA4 NikgIChpbnQpCiAgaW5mby5wcm9kdWN0ID0gJzgyODAxSSAoSUNIOSBGYW1pbHkpIFVTQjIg RUhDSSBDb250cm9sbGVyICMyJyAgKHN0cmluZykKICBwY2kucHJvZHVjdCA9ICc4MjgwMUkg KElDSDkgRmFtaWx5KSBVU0IyIEVIQ0kgQ29udHJvbGxlciAjMicgIChzdHJpbmcpCiAgcGNp LnN1YnN5c19wcm9kdWN0X2lkID0gODQzMyAgKDB4MjBmMSkgIChpbnQpCiAgcGNpLnN1YnN5 c192ZW5kb3IgPSAnTGVub3ZvJyAgKHN0cmluZykKICBwY2kuc3Vic3lzX3ZlbmRvcl9pZCA9 IDYwNTggICgweDE3YWEpICAoaW50KQogIGZyZWVic2QuZHJpdmVyID0gJ2VoY2knICAoc3Ry aW5nKQogIGZyZWVic2QudW5pdCA9IDAgICgweDApICAoaW50KQogIHBjaS5mcmVlYnNkLmJ1 cyA9IDAgICgweDApICAoaW50KQogIGluZm8ucGFyZW50ID0gJy9vcmcvZnJlZWRlc2t0b3Av SGFsL2RldmljZXMvY29tcHV0ZXInICAoc3RyaW5nKQogIHBjaS5mcmVlYnNkLmRldmljZSA9 IDI2ICAoMHgxYSkgIChpbnQpCiAgcGNpLmRldmljZV9jbGFzcyA9IDEyICAoMHhjKSAgKGlu dCkKICBwY2kuZnJlZWJzZC5mdW5jdGlvbiA9IDcgICgweDcpICAoaW50KQogIHBjaS5kZXZp Y2Vfc3ViY2xhc3MgPSAzICAoMHgzKSAgKGludCkKICBwY2kuZnJlZWJzZC5zZWNvbmRhcnlf YnVzID0gMCAgKDB4MCkgIChpbnQpCgo3MDogdWRpID0gJy9vcmcvZnJlZWRlc2t0b3AvSGFs L2RldmljZXMvcGNpXzgwODZfMjkzZScKICBpbmZvLnVkaSA9ICcvb3JnL2ZyZWVkZXNrdG9w L0hhbC9kZXZpY2VzL3BjaV84MDg2XzI5M2UnICAoc3RyaW5nKQogIHBjaS5kZXZpY2VfcHJv dG9jb2wgPSAwICAoMHgwKSAgKGludCkKICBpbmZvLnZlbmRvciA9ICdJbnRlbCBDb3Jwb3Jh dGlvbicgIChzdHJpbmcpCiAgaW5mby5zdWJzeXN0ZW0gPSAncGNpJyAgKHN0cmluZykKICBw Y2kucHJvZHVjdF9pZCA9IDEwNTU4ICAoMHgyOTNlKSAgKGludCkKICBwY2kudmVuZG9yID0g J0ludGVsIENvcnBvcmF0aW9uJyAgKHN0cmluZykKICBwY2kudmVuZG9yX2lkID0gMzI5MDIg ICgweDgwODYpICAoaW50KQogIGluZm8ucHJvZHVjdCA9ICc4MjgwMUkgKElDSDkgRmFtaWx5 KSBIRCBBdWRpbyBDb250cm9sbGVyJyAgKHN0cmluZykKICBwY2kucHJvZHVjdCA9ICc4Mjgw MUkgKElDSDkgRmFtaWx5KSBIRCBBdWRpbyBDb250cm9sbGVyJyAgKHN0cmluZykKICBwY2ku c3Vic3lzX3Byb2R1Y3RfaWQgPSA4NDM0ICAoMHgyMGYyKSAgKGludCkKICBwY2kuc3Vic3lz X3ZlbmRvciA9ICdMZW5vdm8nICAoc3RyaW5nKQogIHBjaS5zdWJzeXNfdmVuZG9yX2lkID0g NjA1OCAgKDB4MTdhYSkgIChpbnQpCiAgZnJlZWJzZC5kcml2ZXIgPSAnaGRhYycgIChzdHJp bmcpCiAgZnJlZWJzZC51bml0ID0gMCAgKDB4MCkgIChpbnQpCiAgcGNpLmZyZWVic2QuYnVz ID0gMCAgKDB4MCkgIChpbnQpCiAgaW5mby5wYXJlbnQgPSAnL29yZy9mcmVlZGVza3RvcC9I YWwvZGV2aWNlcy9jb21wdXRlcicgIChzdHJpbmcpCiAgcGNpLmZyZWVic2QuZGV2aWNlID0g MjcgICgweDFiKSAgKGludCkKICBwY2kuZGV2aWNlX2NsYXNzID0gNCAgKDB4NCkgIChpbnQp CiAgcGNpLmZyZWVic2QuZnVuY3Rpb24gPSAwICAoMHgwKSAgKGludCkKICBwY2kuZGV2aWNl X3N1YmNsYXNzID0gMyAgKDB4MykgIChpbnQpCiAgcGNpLmZyZWVic2Quc2Vjb25kYXJ5X2J1 cyA9IDAgICgweDApICAoaW50KQoKNzE6IHVkaSA9ICcvb3JnL2ZyZWVkZXNrdG9wL0hhbC9k ZXZpY2VzL3BjaV84MDg2XzI5NDAnCiAgaW5mby51ZGkgPSAnL29yZy9mcmVlZGVza3RvcC9I YWwvZGV2aWNlcy9wY2lfODA4Nl8yOTQwJyAgKHN0cmluZykKICBwY2kuZGV2aWNlX3Byb3Rv Y29sID0gMCAgKDB4MCkgIChpbnQpCiAgaW5mby52ZW5kb3IgPSAnSW50ZWwgQ29ycG9yYXRp b24nICAoc3RyaW5nKQogIGluZm8uc3Vic3lzdGVtID0gJ3BjaScgIChzdHJpbmcpCiAgcGNp LnByb2R1Y3RfaWQgPSAxMDU2MCAgKDB4Mjk0MCkgIChpbnQpCiAgcGNpLnZlbmRvciA9ICdJ bnRlbCBDb3Jwb3JhdGlvbicgIChzdHJpbmcpCiAgcGNpLnZlbmRvcl9pZCA9IDMyOTAyICAo MHg4MDg2KSAgKGludCkKICBpbmZvLnByb2R1Y3QgPSAnODI4MDFJIChJQ0g5IEZhbWlseSkg UENJIEV4cHJlc3MgUG9ydCAxJyAgKHN0cmluZykKICBwY2kucHJvZHVjdCA9ICc4MjgwMUkg KElDSDkgRmFtaWx5KSBQQ0kgRXhwcmVzcyBQb3J0IDEnICAoc3RyaW5nKQogIHBjaS5zdWJz eXNfcHJvZHVjdF9pZCA9IDg0MzUgICgweDIwZjMpICAoaW50KQogIHBjaS5zdWJzeXNfdmVu ZG9yID0gJ0xlbm92bycgIChzdHJpbmcpCiAgcGNpLnN1YnN5c192ZW5kb3JfaWQgPSA2MDU4 ICAoMHgxN2FhKSAgKGludCkKICBmcmVlYnNkLmRyaXZlciA9ICdwY2liJyAgKHN0cmluZykK ICBmcmVlYnNkLnVuaXQgPSAxICAoMHgxKSAgKGludCkKICBwY2kuZnJlZWJzZC5idXMgPSAw ICAoMHgwKSAgKGludCkKICBpbmZvLnBhcmVudCA9ICcvb3JnL2ZyZWVkZXNrdG9wL0hhbC9k ZXZpY2VzL2NvbXB1dGVyJyAgKHN0cmluZykKICBwY2kuZnJlZWJzZC5kZXZpY2UgPSAyOCAg KDB4MWMpICAoaW50KQogIHBjaS5kZXZpY2VfY2xhc3MgPSA2ICAoMHg2KSAgKGludCkKICBw Y2kuZnJlZWJzZC5mdW5jdGlvbiA9IDAgICgweDApICAoaW50KQogIHBjaS5kZXZpY2Vfc3Vi Y2xhc3MgPSA0ICAoMHg0KSAgKGludCkKICBwY2kuZnJlZWJzZC5zZWNvbmRhcnlfYnVzID0g MSAgKDB4MSkgIChpbnQpCgo3MjogdWRpID0gJy9vcmcvZnJlZWRlc2t0b3AvSGFsL2Rldmlj ZXMvcGNpXzE2OGNfMDAxYycKICBpbmZvLnVkaSA9ICcvb3JnL2ZyZWVkZXNrdG9wL0hhbC9k ZXZpY2VzL3BjaV8xNjhjXzAwMWMnICAoc3RyaW5nKQogIHBjaS5kZXZpY2VfcHJvdG9jb2wg PSAwICAoMHgwKSAgKGludCkKICBpbmZvLnZlbmRvciA9ICdBdGhlcm9zIENvbW11bmljYXRp b25zIEluYy4nICAoc3RyaW5nKQogIGluZm8uc3Vic3lzdGVtID0gJ3BjaScgIChzdHJpbmcp CiAgcGNpLnByb2R1Y3RfaWQgPSAyOCAgKDB4MWMpICAoaW50KQogIHBjaS52ZW5kb3IgPSAn QXRoZXJvcyBDb21tdW5pY2F0aW9ucyBJbmMuJyAgKHN0cmluZykKICBwY2kudmVuZG9yX2lk ID0gNTc3MiAgKDB4MTY4YykgIChpbnQpCiAgaW5mby5wcm9kdWN0ID0gJ0FSMjQyeCA4MDIu MTFhYmcgV2lyZWxlc3MgUENJIEV4cHJlc3MgQWRhcHRlcicgIChzdHJpbmcpCiAgcGNpLnBy b2R1Y3QgPSAnQVIyNDJ4IDgwMi4xMWFiZyBXaXJlbGVzcyBQQ0kgRXhwcmVzcyBBZGFwdGVy JyAgKHN0cmluZykKICBwY2kuc3Vic3lzX3Byb2R1Y3RfaWQgPSA1MyAgKDB4MzUpICAoaW50 KQogIHBjaS5zdWJzeXNfdmVuZG9yID0gJ0F0aGVyb3MgQ29tbXVuaWNhdGlvbnMgSW5jLicg IChzdHJpbmcpCiAgcGNpLnN1YnN5c192ZW5kb3JfaWQgPSA1NzcyICAoMHgxNjhjKSAgKGlu dCkKICBmcmVlYnNkLmRyaXZlciA9ICdhdGgnICAoc3RyaW5nKQogIGZyZWVic2QudW5pdCA9 IDAgICgweDApICAoaW50KQogIHBjaS5mcmVlYnNkLmJ1cyA9IDIgICgweDIpICAoaW50KQog IGluZm8ucGFyZW50ID0gJy9vcmcvZnJlZWRlc2t0b3AvSGFsL2RldmljZXMvcGNpXzgwODZf Mjk0MicgIChzdHJpbmcpCiAgcGNpLmZyZWVic2QuZGV2aWNlID0gMCAgKDB4MCkgIChpbnQp CiAgcGNpLmRldmljZV9jbGFzcyA9IDIgICgweDIpICAoaW50KQogIHBjaS5mcmVlYnNkLmZ1 bmN0aW9uID0gMCAgKDB4MCkgIChpbnQpCiAgcGNpLmRldmljZV9zdWJjbGFzcyA9IDAgICgw eDApICAoaW50KQogIHBjaS5mcmVlYnNkLnNlY29uZGFyeV9idXMgPSAwICAoMHgwKSAgKGlu dCkKCjczOiB1ZGkgPSAnL29yZy9mcmVlZGVza3RvcC9IYWwvZGV2aWNlcy9wY2lfODA4Nl8y OTQyJwogIGluZm8udWRpID0gJy9vcmcvZnJlZWRlc2t0b3AvSGFsL2RldmljZXMvcGNpXzgw ODZfMjk0MicgIChzdHJpbmcpCiAgcGNpLmRldmljZV9wcm90b2NvbCA9IDAgICgweDApICAo aW50KQogIGluZm8udmVuZG9yID0gJ0ludGVsIENvcnBvcmF0aW9uJyAgKHN0cmluZykKICBp bmZvLnN1YnN5c3RlbSA9ICdwY2knICAoc3RyaW5nKQogIHBjaS5wcm9kdWN0X2lkID0gMTA1 NjIgICgweDI5NDIpICAoaW50KQogIHBjaS52ZW5kb3IgPSAnSW50ZWwgQ29ycG9yYXRpb24n ICAoc3RyaW5nKQogIHBjaS52ZW5kb3JfaWQgPSAzMjkwMiAgKDB4ODA4NikgIChpbnQpCiAg aW5mby5wcm9kdWN0ID0gJzgyODAxSSAoSUNIOSBGYW1pbHkpIFBDSSBFeHByZXNzIFBvcnQg MicgIChzdHJpbmcpCiAgcGNpLnByb2R1Y3QgPSAnODI4MDFJIChJQ0g5IEZhbWlseSkgUENJ IEV4cHJlc3MgUG9ydCAyJyAgKHN0cmluZykKICBwY2kuc3Vic3lzX3Byb2R1Y3RfaWQgPSA4 NDM1ICAoMHgyMGYzKSAgKGludCkKICBwY2kuc3Vic3lzX3ZlbmRvciA9ICdMZW5vdm8nICAo c3RyaW5nKQogIHBjaS5zdWJzeXNfdmVuZG9yX2lkID0gNjA1OCAgKDB4MTdhYSkgIChpbnQp CiAgZnJlZWJzZC5kcml2ZXIgPSAncGNpYicgIChzdHJpbmcpCiAgZnJlZWJzZC51bml0ID0g MiAgKDB4MikgIChpbnQpCiAgcGNpLmZyZWVic2QuYnVzID0gMCAgKDB4MCkgIChpbnQpCiAg aW5mby5wYXJlbnQgPSAnL29yZy9mcmVlZGVza3RvcC9IYWwvZGV2aWNlcy9jb21wdXRlcicg IChzdHJpbmcpCiAgcGNpLmZyZWVic2QuZGV2aWNlID0gMjggICgweDFjKSAgKGludCkKICBw Y2kuZGV2aWNlX2NsYXNzID0gNiAgKDB4NikgIChpbnQpCiAgcGNpLmZyZWVic2QuZnVuY3Rp b24gPSAxICAoMHgxKSAgKGludCkKICBwY2kuZGV2aWNlX3N1YmNsYXNzID0gNCAgKDB4NCkg IChpbnQpCiAgcGNpLmZyZWVic2Quc2Vjb25kYXJ5X2J1cyA9IDIgICgweDIpICAoaW50KQoK NzQ6IHVkaSA9ICcvb3JnL2ZyZWVkZXNrdG9wL0hhbC9kZXZpY2VzL3BjaV84MDg2XzI5NDQn CiAgaW5mby51ZGkgPSAnL29yZy9mcmVlZGVza3RvcC9IYWwvZGV2aWNlcy9wY2lfODA4Nl8y OTQ0JyAgKHN0cmluZykKICBwY2kuZGV2aWNlX3Byb3RvY29sID0gMCAgKDB4MCkgIChpbnQp CiAgaW5mby52ZW5kb3IgPSAnSW50ZWwgQ29ycG9yYXRpb24nICAoc3RyaW5nKQogIGluZm8u c3Vic3lzdGVtID0gJ3BjaScgIChzdHJpbmcpCiAgcGNpLnByb2R1Y3RfaWQgPSAxMDU2NCAg KDB4Mjk0NCkgIChpbnQpCiAgcGNpLnZlbmRvciA9ICdJbnRlbCBDb3Jwb3JhdGlvbicgIChz dHJpbmcpCiAgcGNpLnZlbmRvcl9pZCA9IDMyOTAyICAoMHg4MDg2KSAgKGludCkKICBpbmZv LnByb2R1Y3QgPSAnODI4MDFJIChJQ0g5IEZhbWlseSkgUENJIEV4cHJlc3MgUG9ydCAzJyAg KHN0cmluZykKICBwY2kucHJvZHVjdCA9ICc4MjgwMUkgKElDSDkgRmFtaWx5KSBQQ0kgRXhw cmVzcyBQb3J0IDMnICAoc3RyaW5nKQogIHBjaS5zdWJzeXNfcHJvZHVjdF9pZCA9IDg0MzUg ICgweDIwZjMpICAoaW50KQogIHBjaS5zdWJzeXNfdmVuZG9yID0gJ0xlbm92bycgIChzdHJp bmcpCiAgcGNpLnN1YnN5c192ZW5kb3JfaWQgPSA2MDU4ICAoMHgxN2FhKSAgKGludCkKICBm cmVlYnNkLmRyaXZlciA9ICdwY2liJyAgKHN0cmluZykKICBmcmVlYnNkLnVuaXQgPSAzICAo MHgzKSAgKGludCkKICBwY2kuZnJlZWJzZC5idXMgPSAwICAoMHgwKSAgKGludCkKICBpbmZv LnBhcmVudCA9ICcvb3JnL2ZyZWVkZXNrdG9wL0hhbC9kZXZpY2VzL2NvbXB1dGVyJyAgKHN0 cmluZykKICBwY2kuZnJlZWJzZC5kZXZpY2UgPSAyOCAgKDB4MWMpICAoaW50KQogIHBjaS5k ZXZpY2VfY2xhc3MgPSA2ICAoMHg2KSAgKGludCkKICBwY2kuZnJlZWJzZC5mdW5jdGlvbiA9 IDIgICgweDIpICAoaW50KQogIHBjaS5kZXZpY2Vfc3ViY2xhc3MgPSA0ICAoMHg0KSAgKGlu dCkKICBwY2kuZnJlZWJzZC5zZWNvbmRhcnlfYnVzID0gMyAgKDB4MykgIChpbnQpCgo3NTog dWRpID0gJy9vcmcvZnJlZWRlc2t0b3AvSGFsL2RldmljZXMvcGNpXzEwZWNfODE2OCcKICBp bmZvLnVkaSA9ICcvb3JnL2ZyZWVkZXNrdG9wL0hhbC9kZXZpY2VzL3BjaV8xMGVjXzgxNjgn ICAoc3RyaW5nKQogIHBjaS5kZXZpY2VfcHJvdG9jb2wgPSAwICAoMHgwKSAgKGludCkKICBp bmZvLnZlbmRvciA9ICdSZWFsdGVrIFNlbWljb25kdWN0b3IgQ28uLCBMdGQuJyAgKHN0cmlu ZykKICBpbmZvLnN1YnN5c3RlbSA9ICdwY2knICAoc3RyaW5nKQogIHBjaS5wcm9kdWN0X2lk ID0gMzMxMjggICgweDgxNjgpICAoaW50KQogIHBjaS52ZW5kb3IgPSAnUmVhbHRlayBTZW1p Y29uZHVjdG9yIENvLiwgTHRkLicgIChzdHJpbmcpCiAgcGNpLnZlbmRvcl9pZCA9IDQzMzIg ICgweDEwZWMpICAoaW50KQogIGluZm8ucHJvZHVjdCA9ICdSVEw4MTExLzgxNjhCIFBDSSBF eHByZXNzIEdpZ2FiaXQgRXRoZXJuZXQgY29udHJvbGxlcicgIChzdHJpbmcpCiAgcGNpLnBy b2R1Y3QgPSAnUlRMODExMS84MTY4QiBQQ0kgRXhwcmVzcyBHaWdhYml0IEV0aGVybmV0IGNv bnRyb2xsZXInICAoc3RyaW5nKQogIHBjaS5zdWJzeXNfcHJvZHVjdF9pZCA9IDg0NTYgICgw eDIxMDgpICAoaW50KQogIHBjaS5zdWJzeXNfdmVuZG9yID0gJ0xlbm92bycgIChzdHJpbmcp CiAgcGNpLnN1YnN5c192ZW5kb3JfaWQgPSA2MDU4ICAoMHgxN2FhKSAgKGludCkKICBmcmVl YnNkLmRyaXZlciA9ICdyZScgIChzdHJpbmcpCiAgZnJlZWJzZC51bml0ID0gMCAgKDB4MCkg IChpbnQpCiAgcGNpLmZyZWVic2QuYnVzID0gMTIgICgweGMpICAoaW50KQogIGluZm8ucGFy ZW50ID0gJy9vcmcvZnJlZWRlc2t0b3AvSGFsL2RldmljZXMvcGNpXzgwODZfMjk0NicgIChz dHJpbmcpCiAgcGNpLmZyZWVic2QuZGV2aWNlID0gMCAgKDB4MCkgIChpbnQpCiAgcGNpLmRl dmljZV9jbGFzcyA9IDIgICgweDIpICAoaW50KQogIHBjaS5mcmVlYnNkLmZ1bmN0aW9uID0g MCAgKDB4MCkgIChpbnQpCiAgcGNpLmRldmljZV9zdWJjbGFzcyA9IDAgICgweDApICAoaW50 KQogIHBjaS5mcmVlYnNkLnNlY29uZGFyeV9idXMgPSAyNDAgICgweGYwKSAgKGludCkKCjc2 OiB1ZGkgPSAnL29yZy9mcmVlZGVza3RvcC9IYWwvZGV2aWNlcy9wY2lfODA4Nl8yOTQ2Jwog IGluZm8udWRpID0gJy9vcmcvZnJlZWRlc2t0b3AvSGFsL2RldmljZXMvcGNpXzgwODZfMjk0 NicgIChzdHJpbmcpCiAgcGNpLmRldmljZV9wcm90b2NvbCA9IDAgICgweDApICAoaW50KQog IGluZm8udmVuZG9yID0gJ0ludGVsIENvcnBvcmF0aW9uJyAgKHN0cmluZykKICBpbmZvLnN1 YnN5c3RlbSA9ICdwY2knICAoc3RyaW5nKQogIHBjaS5wcm9kdWN0X2lkID0gMTA1NjYgICgw eDI5NDYpICAoaW50KQogIHBjaS52ZW5kb3IgPSAnSW50ZWwgQ29ycG9yYXRpb24nICAoc3Ry aW5nKQogIHBjaS52ZW5kb3JfaWQgPSAzMjkwMiAgKDB4ODA4NikgIChpbnQpCiAgaW5mby5w cm9kdWN0ID0gJzgyODAxSSAoSUNIOSBGYW1pbHkpIFBDSSBFeHByZXNzIFBvcnQgNCcgIChz dHJpbmcpCiAgcGNpLnByb2R1Y3QgPSAnODI4MDFJIChJQ0g5IEZhbWlseSkgUENJIEV4cHJl c3MgUG9ydCA0JyAgKHN0cmluZykKICBwY2kuc3Vic3lzX3Byb2R1Y3RfaWQgPSA4NDM1ICAo MHgyMGYzKSAgKGludCkKICBwY2kuc3Vic3lzX3ZlbmRvciA9ICdMZW5vdm8nICAoc3RyaW5n KQogIHBjaS5zdWJzeXNfdmVuZG9yX2lkID0gNjA1OCAgKDB4MTdhYSkgIChpbnQpCiAgZnJl ZWJzZC5kcml2ZXIgPSAncGNpYicgIChzdHJpbmcpCiAgZnJlZWJzZC51bml0ID0gNCAgKDB4 NCkgIChpbnQpCiAgcGNpLmZyZWVic2QuYnVzID0gMCAgKDB4MCkgIChpbnQpCiAgaW5mby5w YXJlbnQgPSAnL29yZy9mcmVlZGVza3RvcC9IYWwvZGV2aWNlcy9jb21wdXRlcicgIChzdHJp bmcpCiAgcGNpLmZyZWVic2QuZGV2aWNlID0gMjggICgweDFjKSAgKGludCkKICBwY2kuZGV2 aWNlX2NsYXNzID0gNiAgKDB4NikgIChpbnQpCiAgcGNpLmZyZWVic2QuZnVuY3Rpb24gPSAz ICAoMHgzKSAgKGludCkKICBwY2kuZGV2aWNlX3N1YmNsYXNzID0gNCAgKDB4NCkgIChpbnQp CiAgcGNpLmZyZWVic2Quc2Vjb25kYXJ5X2J1cyA9IDEyICAoMHhjKSAgKGludCkKCjc3OiB1 ZGkgPSAnL29yZy9mcmVlZGVza3RvcC9IYWwvZGV2aWNlcy9wY2lfODA4Nl8yOTM0JwogIGlu Zm8udWRpID0gJy9vcmcvZnJlZWRlc2t0b3AvSGFsL2RldmljZXMvcGNpXzgwODZfMjkzNCcg IChzdHJpbmcpCiAgcGNpLmRldmljZV9wcm90b2NvbCA9IDAgICgweDApICAoaW50KQogIGlu Zm8udmVuZG9yID0gJ0ludGVsIENvcnBvcmF0aW9uJyAgKHN0cmluZykKICBpbmZvLnN1YnN5 c3RlbSA9ICdwY2knICAoc3RyaW5nKQogIHBjaS5wcm9kdWN0X2lkID0gMTA1NDggICgweDI5 MzQpICAoaW50KQogIHBjaS52ZW5kb3IgPSAnSW50ZWwgQ29ycG9yYXRpb24nICAoc3RyaW5n KQogIHBjaS52ZW5kb3JfaWQgPSAzMjkwMiAgKDB4ODA4NikgIChpbnQpCiAgaW5mby5wcm9k dWN0ID0gJzgyODAxSSAoSUNIOSBGYW1pbHkpIFVTQiBVSENJIENvbnRyb2xsZXIgIzEnICAo c3RyaW5nKQogIHBjaS5wcm9kdWN0ID0gJzgyODAxSSAoSUNIOSBGYW1pbHkpIFVTQiBVSENJ IENvbnRyb2xsZXIgIzEnICAoc3RyaW5nKQogIHBjaS5zdWJzeXNfcHJvZHVjdF9pZCA9IDg0 MzIgICgweDIwZjApICAoaW50KQogIHBjaS5zdWJzeXNfdmVuZG9yID0gJ0xlbm92bycgIChz dHJpbmcpCiAgcGNpLnN1YnN5c192ZW5kb3JfaWQgPSA2MDU4ICAoMHgxN2FhKSAgKGludCkK ICBmcmVlYnNkLmRyaXZlciA9ICd1aGNpJyAgKHN0cmluZykKICBmcmVlYnNkLnVuaXQgPSAz ICAoMHgzKSAgKGludCkKICBwY2kuZnJlZWJzZC5idXMgPSAwICAoMHgwKSAgKGludCkKICBp bmZvLnBhcmVudCA9ICcvb3JnL2ZyZWVkZXNrdG9wL0hhbC9kZXZpY2VzL2NvbXB1dGVyJyAg KHN0cmluZykKICBwY2kuZnJlZWJzZC5kZXZpY2UgPSAyOSAgKDB4MWQpICAoaW50KQogIHBj aS5kZXZpY2VfY2xhc3MgPSAxMiAgKDB4YykgIChpbnQpCiAgcGNpLmZyZWVic2QuZnVuY3Rp b24gPSAwICAoMHgwKSAgKGludCkKICBwY2kuZGV2aWNlX3N1YmNsYXNzID0gMyAgKDB4Mykg IChpbnQpCiAgcGNpLmZyZWVic2Quc2Vjb25kYXJ5X2J1cyA9IDAgICgweDApICAoaW50KQoK Nzg6IHVkaSA9ICcvb3JnL2ZyZWVkZXNrdG9wL0hhbC9kZXZpY2VzL3BjaV84MDg2XzI5MzUn CiAgaW5mby51ZGkgPSAnL29yZy9mcmVlZGVza3RvcC9IYWwvZGV2aWNlcy9wY2lfODA4Nl8y OTM1JyAgKHN0cmluZykKICBwY2kuZGV2aWNlX3Byb3RvY29sID0gMCAgKDB4MCkgIChpbnQp CiAgaW5mby52ZW5kb3IgPSAnSW50ZWwgQ29ycG9yYXRpb24nICAoc3RyaW5nKQogIGluZm8u c3Vic3lzdGVtID0gJ3BjaScgIChzdHJpbmcpCiAgcGNpLnByb2R1Y3RfaWQgPSAxMDU0OSAg KDB4MjkzNSkgIChpbnQpCiAgcGNpLnZlbmRvciA9ICdJbnRlbCBDb3Jwb3JhdGlvbicgIChz dHJpbmcpCiAgcGNpLnZlbmRvcl9pZCA9IDMyOTAyICAoMHg4MDg2KSAgKGludCkKICBpbmZv LnByb2R1Y3QgPSAnODI4MDFJIChJQ0g5IEZhbWlseSkgVVNCIFVIQ0kgQ29udHJvbGxlciAj MicgIChzdHJpbmcpCiAgcGNpLnByb2R1Y3QgPSAnODI4MDFJIChJQ0g5IEZhbWlseSkgVVNC IFVIQ0kgQ29udHJvbGxlciAjMicgIChzdHJpbmcpCiAgcGNpLnN1YnN5c19wcm9kdWN0X2lk ID0gODQzMiAgKDB4MjBmMCkgIChpbnQpCiAgcGNpLnN1YnN5c192ZW5kb3IgPSAnTGVub3Zv JyAgKHN0cmluZykKICBwY2kuc3Vic3lzX3ZlbmRvcl9pZCA9IDYwNTggICgweDE3YWEpICAo aW50KQogIGZyZWVic2QuZHJpdmVyID0gJ3VoY2knICAoc3RyaW5nKQogIGZyZWVic2QudW5p dCA9IDQgICgweDQpICAoaW50KQogIHBjaS5mcmVlYnNkLmJ1cyA9IDAgICgweDApICAoaW50 KQogIGluZm8ucGFyZW50ID0gJy9vcmcvZnJlZWRlc2t0b3AvSGFsL2RldmljZXMvY29tcHV0 ZXInICAoc3RyaW5nKQogIHBjaS5mcmVlYnNkLmRldmljZSA9IDI5ICAoMHgxZCkgIChpbnQp CiAgcGNpLmRldmljZV9jbGFzcyA9IDEyICAoMHhjKSAgKGludCkKICBwY2kuZnJlZWJzZC5m dW5jdGlvbiA9IDEgICgweDEpICAoaW50KQogIHBjaS5kZXZpY2Vfc3ViY2xhc3MgPSAzICAo MHgzKSAgKGludCkKICBwY2kuZnJlZWJzZC5zZWNvbmRhcnlfYnVzID0gMCAgKDB4MCkgIChp bnQpCgo3OTogdWRpID0gJy9vcmcvZnJlZWRlc2t0b3AvSGFsL2RldmljZXMvcGNpXzgwODZf MjkzNicKICBpbmZvLnVkaSA9ICcvb3JnL2ZyZWVkZXNrdG9wL0hhbC9kZXZpY2VzL3BjaV84 MDg2XzI5MzYnICAoc3RyaW5nKQogIHBjaS5kZXZpY2VfcHJvdG9jb2wgPSAwICAoMHgwKSAg KGludCkKICBpbmZvLnZlbmRvciA9ICdJbnRlbCBDb3Jwb3JhdGlvbicgIChzdHJpbmcpCiAg aW5mby5zdWJzeXN0ZW0gPSAncGNpJyAgKHN0cmluZykKICBwY2kucHJvZHVjdF9pZCA9IDEw NTUwICAoMHgyOTM2KSAgKGludCkKICBwY2kudmVuZG9yID0gJ0ludGVsIENvcnBvcmF0aW9u JyAgKHN0cmluZykKICBwY2kudmVuZG9yX2lkID0gMzI5MDIgICgweDgwODYpICAoaW50KQog IGluZm8ucHJvZHVjdCA9ICc4MjgwMUkgKElDSDkgRmFtaWx5KSBVU0IgVUhDSSBDb250cm9s bGVyICMzJyAgKHN0cmluZykKICBwY2kucHJvZHVjdCA9ICc4MjgwMUkgKElDSDkgRmFtaWx5 KSBVU0IgVUhDSSBDb250cm9sbGVyICMzJyAgKHN0cmluZykKICBwY2kuc3Vic3lzX3Byb2R1 Y3RfaWQgPSA4NDMyICAoMHgyMGYwKSAgKGludCkKICBwY2kuc3Vic3lzX3ZlbmRvciA9ICdM ZW5vdm8nICAoc3RyaW5nKQogIHBjaS5zdWJzeXNfdmVuZG9yX2lkID0gNjA1OCAgKDB4MTdh YSkgIChpbnQpCiAgZnJlZWJzZC5kcml2ZXIgPSAndWhjaScgIChzdHJpbmcpCiAgZnJlZWJz ZC51bml0ID0gNSAgKDB4NSkgIChpbnQpCiAgcGNpLmZyZWVic2QuYnVzID0gMCAgKDB4MCkg IChpbnQpCiAgaW5mby5wYXJlbnQgPSAnL29yZy9mcmVlZGVza3RvcC9IYWwvZGV2aWNlcy9j b21wdXRlcicgIChzdHJpbmcpCiAgcGNpLmZyZWVic2QuZGV2aWNlID0gMjkgICgweDFkKSAg KGludCkKICBwY2kuZGV2aWNlX2NsYXNzID0gMTIgICgweGMpICAoaW50KQogIHBjaS5mcmVl YnNkLmZ1bmN0aW9uID0gMiAgKDB4MikgIChpbnQpCiAgcGNpLmRldmljZV9zdWJjbGFzcyA9 IDMgICgweDMpICAoaW50KQogIHBjaS5mcmVlYnNkLnNlY29uZGFyeV9idXMgPSAwICAoMHgw KSAgKGludCkKCjgwOiB1ZGkgPSAnL29yZy9mcmVlZGVza3RvcC9IYWwvZGV2aWNlcy9wY2lf ODA4Nl8yOTNhJwogIGluZm8udWRpID0gJy9vcmcvZnJlZWRlc2t0b3AvSGFsL2RldmljZXMv cGNpXzgwODZfMjkzYScgIChzdHJpbmcpCiAgcGNpLmRldmljZV9wcm90b2NvbCA9IDMyICAo MHgyMCkgIChpbnQpCiAgaW5mby52ZW5kb3IgPSAnSW50ZWwgQ29ycG9yYXRpb24nICAoc3Ry aW5nKQogIGluZm8uc3Vic3lzdGVtID0gJ3BjaScgIChzdHJpbmcpCiAgcGNpLnByb2R1Y3Rf aWQgPSAxMDU1NCAgKDB4MjkzYSkgIChpbnQpCiAgcGNpLnZlbmRvciA9ICdJbnRlbCBDb3Jw b3JhdGlvbicgIChzdHJpbmcpCiAgcGNpLnZlbmRvcl9pZCA9IDMyOTAyICAoMHg4MDg2KSAg KGludCkKICBpbmZvLnByb2R1Y3QgPSAnODI4MDFJIChJQ0g5IEZhbWlseSkgVVNCMiBFSENJ IENvbnRyb2xsZXIgIzEnICAoc3RyaW5nKQogIHBjaS5wcm9kdWN0ID0gJzgyODAxSSAoSUNI OSBGYW1pbHkpIFVTQjIgRUhDSSBDb250cm9sbGVyICMxJyAgKHN0cmluZykKICBwY2kuc3Vi c3lzX3Byb2R1Y3RfaWQgPSA4NDMzICAoMHgyMGYxKSAgKGludCkKICBwY2kuc3Vic3lzX3Zl bmRvciA9ICdMZW5vdm8nICAoc3RyaW5nKQogIHBjaS5zdWJzeXNfdmVuZG9yX2lkID0gNjA1 OCAgKDB4MTdhYSkgIChpbnQpCiAgZnJlZWJzZC5kcml2ZXIgPSAnZWhjaScgIChzdHJpbmcp CiAgZnJlZWJzZC51bml0ID0gMSAgKDB4MSkgIChpbnQpCiAgcGNpLmZyZWVic2QuYnVzID0g MCAgKDB4MCkgIChpbnQpCiAgaW5mby5wYXJlbnQgPSAnL29yZy9mcmVlZGVza3RvcC9IYWwv ZGV2aWNlcy9jb21wdXRlcicgIChzdHJpbmcpCiAgcGNpLmZyZWVic2QuZGV2aWNlID0gMjkg ICgweDFkKSAgKGludCkKICBwY2kuZGV2aWNlX2NsYXNzID0gMTIgICgweGMpICAoaW50KQog IHBjaS5mcmVlYnNkLmZ1bmN0aW9uID0gNyAgKDB4NykgIChpbnQpCiAgcGNpLmRldmljZV9z dWJjbGFzcyA9IDMgICgweDMpICAoaW50KQogIHBjaS5mcmVlYnNkLnNlY29uZGFyeV9idXMg PSAwICAoMHgwKSAgKGludCkKCjgxOiB1ZGkgPSAnL29yZy9mcmVlZGVza3RvcC9IYWwvZGV2 aWNlcy9wY2lfMTE4MF8wODMyJwogIGluZm8udWRpID0gJy9vcmcvZnJlZWRlc2t0b3AvSGFs L2RldmljZXMvcGNpXzExODBfMDgzMicgIChzdHJpbmcpCiAgcGNpLmRldmljZV9wcm90b2Nv bCA9IDE2ICAoMHgxMCkgIChpbnQpCiAgaW5mby52ZW5kb3IgPSAnUmljb2ggQ28gTHRkJyAg KHN0cmluZykKICBpbmZvLnN1YnN5c3RlbSA9ICdwY2knICAoc3RyaW5nKQogIHBjaS5wcm9k dWN0X2lkID0gMjA5OCAgKDB4ODMyKSAgKGludCkKICBwY2kudmVuZG9yID0gJ1JpY29oIENv IEx0ZCcgIChzdHJpbmcpCiAgcGNpLnZlbmRvcl9pZCA9IDQ0ODAgICgweDExODApICAoaW50 KQogIGluZm8ucHJvZHVjdCA9ICdSNUM4MzIgSUVFRSAxMzk0IENvbnRyb2xsZXInICAoc3Ry aW5nKQogIHBjaS5wcm9kdWN0ID0gJ1I1QzgzMiBJRUVFIDEzOTQgQ29udHJvbGxlcicgIChz dHJpbmcpCiAgcGNpLnN1YnN5c19wcm9kdWN0X2lkID0gODQ1NyAgKDB4MjEwOSkgIChpbnQp CiAgcGNpLnN1YnN5c192ZW5kb3IgPSAnTGVub3ZvJyAgKHN0cmluZykKICBwY2kuc3Vic3lz X3ZlbmRvcl9pZCA9IDYwNTggICgweDE3YWEpICAoaW50KQogIGZyZWVic2QuZHJpdmVyID0g J2Z3b2hjaScgIChzdHJpbmcpCiAgZnJlZWJzZC51bml0ID0gMCAgKDB4MCkgIChpbnQpCiAg cGNpLmZyZWVic2QuYnVzID0gMTMgICgweGQpICAoaW50KQogIGluZm8ucGFyZW50ID0gJy9v cmcvZnJlZWRlc2t0b3AvSGFsL2RldmljZXMvcGNpXzgwODZfMjQ0OCcgIChzdHJpbmcpCiAg cGNpLmZyZWVic2QuZGV2aWNlID0gMCAgKDB4MCkgIChpbnQpCiAgcGNpLmRldmljZV9jbGFz cyA9IDEyICAoMHhjKSAgKGludCkKICBwY2kuZnJlZWJzZC5mdW5jdGlvbiA9IDAgICgweDAp ICAoaW50KQogIHBjaS5kZXZpY2Vfc3ViY2xhc3MgPSAwICAoMHgwKSAgKGludCkKICBwY2ku ZnJlZWJzZC5zZWNvbmRhcnlfYnVzID0gMCAgKDB4MCkgIChpbnQpCgo4MjogdWRpID0gJy9v cmcvZnJlZWRlc2t0b3AvSGFsL2RldmljZXMvcGNpXzExODBfMDgyMicKICBpbmZvLnVkaSA9 ICcvb3JnL2ZyZWVkZXNrdG9wL0hhbC9kZXZpY2VzL3BjaV8xMTgwXzA4MjInICAoc3RyaW5n KQogIHBjaS5kZXZpY2VfcHJvdG9jb2wgPSAwICAoMHgwKSAgKGludCkKICBpbmZvLnZlbmRv ciA9ICdSaWNvaCBDbyBMdGQnICAoc3RyaW5nKQogIGluZm8uc3Vic3lzdGVtID0gJ3BjaScg IChzdHJpbmcpCiAgcGNpLnByb2R1Y3RfaWQgPSAyMDgyICAoMHg4MjIpICAoaW50KQogIHBj aS52ZW5kb3IgPSAnUmljb2ggQ28gTHRkJyAgKHN0cmluZykKICBwY2kudmVuZG9yX2lkID0g NDQ4MCAgKDB4MTE4MCkgIChpbnQpCiAgaW5mby5wcm9kdWN0ID0gJ1I1QzgyMiBTRC9TRElP L01NQy9NUy9NU1BybyBIb3N0IEFkYXB0ZXInICAoc3RyaW5nKQogIHBjaS5wcm9kdWN0ID0g J1I1QzgyMiBTRC9TRElPL01NQy9NUy9NU1BybyBIb3N0IEFkYXB0ZXInICAoc3RyaW5nKQog IHBjaS5zdWJzeXNfcHJvZHVjdF9pZCA9IDg0NTggICgweDIxMGEpICAoaW50KQogIHBjaS5z dWJzeXNfdmVuZG9yID0gJ0xlbm92bycgIChzdHJpbmcpCiAgcGNpLnN1YnN5c192ZW5kb3Jf aWQgPSA2MDU4ICAoMHgxN2FhKSAgKGludCkKICBwY2kuZnJlZWJzZC5idXMgPSAxMyAgKDB4 ZCkgIChpbnQpCiAgaW5mby5wYXJlbnQgPSAnL29yZy9mcmVlZGVza3RvcC9IYWwvZGV2aWNl cy9wY2lfODA4Nl8yNDQ4JyAgKHN0cmluZykKICBwY2kuZnJlZWJzZC5kZXZpY2UgPSAwICAo MHgwKSAgKGludCkKICBwY2kuZGV2aWNlX2NsYXNzID0gOCAgKDB4OCkgIChpbnQpCiAgcGNp LmZyZWVic2QuZnVuY3Rpb24gPSAxICAoMHgxKSAgKGludCkKICBwY2kuZGV2aWNlX3N1YmNs YXNzID0gNSAgKDB4NSkgIChpbnQpCiAgcGNpLmZyZWVic2Quc2Vjb25kYXJ5X2J1cyA9IDAg ICgweDApICAoaW50KQoKODM6IHVkaSA9ICcvb3JnL2ZyZWVkZXNrdG9wL0hhbC9kZXZpY2Vz L3BjaV8xMTgwXzA4NDMnCiAgaW5mby51ZGkgPSAnL29yZy9mcmVlZGVza3RvcC9IYWwvZGV2 aWNlcy9wY2lfMTE4MF8wODQzJyAgKHN0cmluZykKICBwY2kuZGV2aWNlX3Byb3RvY29sID0g MCAgKDB4MCkgIChpbnQpCiAgaW5mby52ZW5kb3IgPSAnUmljb2ggQ28gTHRkJyAgKHN0cmlu ZykKICBpbmZvLnN1YnN5c3RlbSA9ICdwY2knICAoc3RyaW5nKQogIHBjaS5wcm9kdWN0X2lk ID0gMjExNSAgKDB4ODQzKSAgKGludCkKICBwY2kudmVuZG9yID0gJ1JpY29oIENvIEx0ZCcg IChzdHJpbmcpCiAgcGNpLnZlbmRvcl9pZCA9IDQ0ODAgICgweDExODApICAoaW50KQogIGlu Zm8ucHJvZHVjdCA9ICdSNUM4NDMgTU1DIEhvc3QgQ29udHJvbGxlcicgIChzdHJpbmcpCiAg cGNpLnByb2R1Y3QgPSAnUjVDODQzIE1NQyBIb3N0IENvbnRyb2xsZXInICAoc3RyaW5nKQog IHBjaS5zdWJzeXNfcHJvZHVjdF9pZCA9IDg0NTkgICgweDIxMGIpICAoaW50KQogIHBjaS5z dWJzeXNfdmVuZG9yID0gJ0xlbm92bycgIChzdHJpbmcpCiAgcGNpLnN1YnN5c192ZW5kb3Jf aWQgPSA2MDU4ICAoMHgxN2FhKSAgKGludCkKICBwY2kuZnJlZWJzZC5idXMgPSAxMyAgKDB4 ZCkgIChpbnQpCiAgaW5mby5wYXJlbnQgPSAnL29yZy9mcmVlZGVza3RvcC9IYWwvZGV2aWNl cy9wY2lfODA4Nl8yNDQ4JyAgKHN0cmluZykKICBwY2kuZnJlZWJzZC5kZXZpY2UgPSAwICAo MHgwKSAgKGludCkKICBwY2kuZGV2aWNlX2NsYXNzID0gOCAgKDB4OCkgIChpbnQpCiAgcGNp LmZyZWVic2QuZnVuY3Rpb24gPSAyICAoMHgyKSAgKGludCkKICBwY2kuZGV2aWNlX3N1YmNs YXNzID0gMTI4ICAoMHg4MCkgIChpbnQpCiAgcGNpLmZyZWVic2Quc2Vjb25kYXJ5X2J1cyA9 IDAgICgweDApICAoaW50KQoKODQ6IHVkaSA9ICcvb3JnL2ZyZWVkZXNrdG9wL0hhbC9kZXZp Y2VzL3BjaV8xMTgwXzA1OTInCiAgaW5mby51ZGkgPSAnL29yZy9mcmVlZGVza3RvcC9IYWwv ZGV2aWNlcy9wY2lfMTE4MF8wNTkyJyAgKHN0cmluZykKICBwY2kuZGV2aWNlX3Byb3RvY29s ID0gMCAgKDB4MCkgIChpbnQpCiAgaW5mby52ZW5kb3IgPSAnUmljb2ggQ28gTHRkJyAgKHN0 cmluZykKICBpbmZvLnN1YnN5c3RlbSA9ICdwY2knICAoc3RyaW5nKQogIHBjaS5wcm9kdWN0 X2lkID0gMTQyNiAgKDB4NTkyKSAgKGludCkKICBwY2kudmVuZG9yID0gJ1JpY29oIENvIEx0 ZCcgIChzdHJpbmcpCiAgcGNpLnZlbmRvcl9pZCA9IDQ0ODAgICgweDExODApICAoaW50KQog IGluZm8ucHJvZHVjdCA9ICdSNUM1OTIgTWVtb3J5IFN0aWNrIEJ1cyBIb3N0IEFkYXB0ZXIn ICAoc3RyaW5nKQogIHBjaS5wcm9kdWN0ID0gJ1I1QzU5MiBNZW1vcnkgU3RpY2sgQnVzIEhv c3QgQWRhcHRlcicgIChzdHJpbmcpCiAgcGNpLnN1YnN5c19wcm9kdWN0X2lkID0gODQ2MCAg KDB4MjEwYykgIChpbnQpCiAgcGNpLnN1YnN5c192ZW5kb3IgPSAnTGVub3ZvJyAgKHN0cmlu ZykKICBwY2kuc3Vic3lzX3ZlbmRvcl9pZCA9IDYwNTggICgweDE3YWEpICAoaW50KQogIHBj aS5mcmVlYnNkLmJ1cyA9IDEzICAoMHhkKSAgKGludCkKICBpbmZvLnBhcmVudCA9ICcvb3Jn L2ZyZWVkZXNrdG9wL0hhbC9kZXZpY2VzL3BjaV84MDg2XzI0NDgnICAoc3RyaW5nKQogIHBj aS5mcmVlYnNkLmRldmljZSA9IDAgICgweDApICAoaW50KQogIHBjaS5kZXZpY2VfY2xhc3Mg PSA4ICAoMHg4KSAgKGludCkKICBwY2kuZnJlZWJzZC5mdW5jdGlvbiA9IDMgICgweDMpICAo aW50KQogIHBjaS5kZXZpY2Vfc3ViY2xhc3MgPSAxMjggICgweDgwKSAgKGludCkKICBwY2ku ZnJlZWJzZC5zZWNvbmRhcnlfYnVzID0gMCAgKDB4MCkgIChpbnQpCgo4NTogdWRpID0gJy9v cmcvZnJlZWRlc2t0b3AvSGFsL2RldmljZXMvcGNpXzExODBfMDg1MicKICBpbmZvLnVkaSA9 ICcvb3JnL2ZyZWVkZXNrdG9wL0hhbC9kZXZpY2VzL3BjaV8xMTgwXzA4NTInICAoc3RyaW5n KQogIHBjaS5kZXZpY2VfcHJvdG9jb2wgPSAwICAoMHgwKSAgKGludCkKICBpbmZvLnZlbmRv ciA9ICdSaWNvaCBDbyBMdGQnICAoc3RyaW5nKQogIGluZm8uc3Vic3lzdGVtID0gJ3BjaScg IChzdHJpbmcpCiAgcGNpLnByb2R1Y3RfaWQgPSAyMTMwICAoMHg4NTIpICAoaW50KQogIHBj aS52ZW5kb3IgPSAnUmljb2ggQ28gTHRkJyAgKHN0cmluZykKICBwY2kudmVuZG9yX2lkID0g NDQ4MCAgKDB4MTE4MCkgIChpbnQpCiAgaW5mby5wcm9kdWN0ID0gJ3hELVBpY3R1cmUgQ2Fy ZCBDb250cm9sbGVyJyAgKHN0cmluZykKICBwY2kucHJvZHVjdCA9ICd4RC1QaWN0dXJlIENh cmQgQ29udHJvbGxlcicgIChzdHJpbmcpCiAgcGNpLnN1YnN5c19wcm9kdWN0X2lkID0gODQ2 MSAgKDB4MjEwZCkgIChpbnQpCiAgcGNpLnN1YnN5c192ZW5kb3IgPSAnTGVub3ZvJyAgKHN0 cmluZykKICBwY2kuc3Vic3lzX3ZlbmRvcl9pZCA9IDYwNTggICgweDE3YWEpICAoaW50KQog IHBjaS5mcmVlYnNkLmJ1cyA9IDEzICAoMHhkKSAgKGludCkKICBpbmZvLnBhcmVudCA9ICcv b3JnL2ZyZWVkZXNrdG9wL0hhbC9kZXZpY2VzL3BjaV84MDg2XzI0NDgnICAoc3RyaW5nKQog IHBjaS5mcmVlYnNkLmRldmljZSA9IDAgICgweDApICAoaW50KQogIHBjaS5kZXZpY2VfY2xh c3MgPSA4ICAoMHg4KSAgKGludCkKICBwY2kuZnJlZWJzZC5mdW5jdGlvbiA9IDQgICgweDQp ICAoaW50KQogIHBjaS5kZXZpY2Vfc3ViY2xhc3MgPSAxMjggICgweDgwKSAgKGludCkKICBw Y2kuZnJlZWJzZC5zZWNvbmRhcnlfYnVzID0gMCAgKDB4MCkgIChpbnQpCgo4NjogdWRpID0g Jy9vcmcvZnJlZWRlc2t0b3AvSGFsL2RldmljZXMvcGNpXzgwODZfMjQ0OCcKICBpbmZvLnVk aSA9ICcvb3JnL2ZyZWVkZXNrdG9wL0hhbC9kZXZpY2VzL3BjaV84MDg2XzI0NDgnICAoc3Ry aW5nKQogIHBjaS5kZXZpY2VfcHJvdG9jb2wgPSAxICAoMHgxKSAgKGludCkKICBpbmZvLnZl bmRvciA9ICdJbnRlbCBDb3Jwb3JhdGlvbicgIChzdHJpbmcpCiAgaW5mby5zdWJzeXN0ZW0g PSAncGNpJyAgKHN0cmluZykKICBwY2kucHJvZHVjdF9pZCA9IDkyODggICgweDI0NDgpICAo aW50KQogIHBjaS52ZW5kb3IgPSAnSW50ZWwgQ29ycG9yYXRpb24nICAoc3RyaW5nKQogIHBj aS52ZW5kb3JfaWQgPSAzMjkwMiAgKDB4ODA4NikgIChpbnQpCiAgaW5mby5wcm9kdWN0ID0g JzgyODAxIE1vYmlsZSBQQ0kgQnJpZGdlJyAgKHN0cmluZykKICBwY2kucHJvZHVjdCA9ICc4 MjgwMSBNb2JpbGUgUENJIEJyaWRnZScgIChzdHJpbmcpCiAgcGNpLnN1YnN5c19wcm9kdWN0 X2lkID0gODQzNiAgKDB4MjBmNCkgIChpbnQpCiAgcGNpLnN1YnN5c192ZW5kb3IgPSAnTGVu b3ZvJyAgKHN0cmluZykKICBwY2kuc3Vic3lzX3ZlbmRvcl9pZCA9IDYwNTggICgweDE3YWEp ICAoaW50KQogIGZyZWVic2QuZHJpdmVyID0gJ3BjaWInICAoc3RyaW5nKQogIGZyZWVic2Qu dW5pdCA9IDUgICgweDUpICAoaW50KQogIHBjaS5mcmVlYnNkLmJ1cyA9IDAgICgweDApICAo aW50KQogIGluZm8ucGFyZW50ID0gJy9vcmcvZnJlZWRlc2t0b3AvSGFsL2RldmljZXMvY29t cHV0ZXInICAoc3RyaW5nKQogIHBjaS5mcmVlYnNkLmRldmljZSA9IDMwICAoMHgxZSkgIChp bnQpCiAgcGNpLmRldmljZV9jbGFzcyA9IDYgICgweDYpICAoaW50KQogIHBjaS5mcmVlYnNk LmZ1bmN0aW9uID0gMCAgKDB4MCkgIChpbnQpCiAgcGNpLmRldmljZV9zdWJjbGFzcyA9IDQg ICgweDQpICAoaW50KQogIHBjaS5mcmVlYnNkLnNlY29uZGFyeV9idXMgPSAxMyAgKDB4ZCkg IChpbnQpCgo4NzogdWRpID0gJy9vcmcvZnJlZWRlc2t0b3AvSGFsL2RldmljZXMvcGNpXzgw ODZfMjkxOScKICBpbmZvLnVkaSA9ICcvb3JnL2ZyZWVkZXNrdG9wL0hhbC9kZXZpY2VzL3Bj aV84MDg2XzI5MTknICAoc3RyaW5nKQogIHBjaS5kZXZpY2VfcHJvdG9jb2wgPSAwICAoMHgw KSAgKGludCkKICBpbmZvLnZlbmRvciA9ICdJbnRlbCBDb3Jwb3JhdGlvbicgIChzdHJpbmcp CiAgaW5mby5zdWJzeXN0ZW0gPSAncGNpJyAgKHN0cmluZykKICBwY2kucHJvZHVjdF9pZCA9 IDEwNTIxICAoMHgyOTE5KSAgKGludCkKICBwY2kudmVuZG9yID0gJ0ludGVsIENvcnBvcmF0 aW9uJyAgKHN0cmluZykKICBwY2kudmVuZG9yX2lkID0gMzI5MDIgICgweDgwODYpICAoaW50 KQogIGluZm8ucHJvZHVjdCA9ICdJQ0g5TSBMUEMgSW50ZXJmYWNlIENvbnRyb2xsZXInICAo c3RyaW5nKQogIHBjaS5wcm9kdWN0ID0gJ0lDSDlNIExQQyBJbnRlcmZhY2UgQ29udHJvbGxl cicgIChzdHJpbmcpCiAgcGNpLnN1YnN5c19wcm9kdWN0X2lkID0gODQzOCAgKDB4MjBmNikg IChpbnQpCiAgcGNpLnN1YnN5c192ZW5kb3IgPSAnTGVub3ZvJyAgKHN0cmluZykKICBwY2ku c3Vic3lzX3ZlbmRvcl9pZCA9IDYwNTggICgweDE3YWEpICAoaW50KQogIGZyZWVic2QuZHJp dmVyID0gJ2lzYWInICAoc3RyaW5nKQogIGZyZWVic2QudW5pdCA9IDAgICgweDApICAoaW50 KQogIHBjaS5mcmVlYnNkLmJ1cyA9IDAgICgweDApICAoaW50KQogIGluZm8ucGFyZW50ID0g Jy9vcmcvZnJlZWRlc2t0b3AvSGFsL2RldmljZXMvY29tcHV0ZXInICAoc3RyaW5nKQogIHBj aS5mcmVlYnNkLmRldmljZSA9IDMxICAoMHgxZikgIChpbnQpCiAgcGNpLmRldmljZV9jbGFz cyA9IDYgICgweDYpICAoaW50KQogIHBjaS5mcmVlYnNkLmZ1bmN0aW9uID0gMCAgKDB4MCkg IChpbnQpCiAgcGNpLmRldmljZV9zdWJjbGFzcyA9IDEgICgweDEpICAoaW50KQogIHBjaS5m cmVlYnNkLnNlY29uZGFyeV9idXMgPSAwICAoMHgwKSAgKGludCkKCjg4OiB1ZGkgPSAnL29y Zy9mcmVlZGVza3RvcC9IYWwvZGV2aWNlcy9wY2lfODA4Nl8yOTI5JwogIGluZm8udWRpID0g Jy9vcmcvZnJlZWRlc2t0b3AvSGFsL2RldmljZXMvcGNpXzgwODZfMjkyOScgIChzdHJpbmcp CiAgcGNpLmRldmljZV9wcm90b2NvbCA9IDEgICgweDEpICAoaW50KQogIGluZm8udmVuZG9y ID0gJ0ludGVsIENvcnBvcmF0aW9uJyAgKHN0cmluZykKICBpbmZvLnN1YnN5c3RlbSA9ICdw Y2knICAoc3RyaW5nKQogIHBjaS5wcm9kdWN0X2lkID0gMTA1MzcgICgweDI5MjkpICAoaW50 KQogIHBjaS52ZW5kb3IgPSAnSW50ZWwgQ29ycG9yYXRpb24nICAoc3RyaW5nKQogIHBjaS52 ZW5kb3JfaWQgPSAzMjkwMiAgKDB4ODA4NikgIChpbnQpCiAgaW5mby5wcm9kdWN0ID0gJ0lD SDlNL00tRSBTQVRBIEFIQ0kgQ29udHJvbGxlcicgIChzdHJpbmcpCiAgcGNpLnByb2R1Y3Qg PSAnSUNIOU0vTS1FIFNBVEEgQUhDSSBDb250cm9sbGVyJyAgKHN0cmluZykKICBwY2kuc3Vi c3lzX3Byb2R1Y3RfaWQgPSA4NDQwICAoMHgyMGY4KSAgKGludCkKICBwY2kuc3Vic3lzX3Zl bmRvciA9ICdMZW5vdm8nICAoc3RyaW5nKQogIHBjaS5zdWJzeXNfdmVuZG9yX2lkID0gNjA1 OCAgKDB4MTdhYSkgIChpbnQpCiAgZnJlZWJzZC5kcml2ZXIgPSAnYXRhcGNpJyAgKHN0cmlu ZykKICBmcmVlYnNkLnVuaXQgPSAwICAoMHgwKSAgKGludCkKICBwY2kuZnJlZWJzZC5idXMg PSAwICAoMHgwKSAgKGludCkKICBpbmZvLnBhcmVudCA9ICcvb3JnL2ZyZWVkZXNrdG9wL0hh bC9kZXZpY2VzL2NvbXB1dGVyJyAgKHN0cmluZykKICBwY2kuZnJlZWJzZC5kZXZpY2UgPSAz MSAgKDB4MWYpICAoaW50KQogIHBjaS5kZXZpY2VfY2xhc3MgPSAxICAoMHgxKSAgKGludCkK ICBwY2kuZnJlZWJzZC5mdW5jdGlvbiA9IDIgICgweDIpICAoaW50KQogIHBjaS5kZXZpY2Vf c3ViY2xhc3MgPSA2ICAoMHg2KSAgKGludCkKICBwY2kuZnJlZWJzZC5zZWNvbmRhcnlfYnVz ID0gNzIgICgweDQ4KSAgKGludCkKCjg5OiB1ZGkgPSAnL29yZy9mcmVlZGVza3RvcC9IYWwv ZGV2aWNlcy9jb21wdXRlcicKICBpbmZvLnVkaSA9ICcvb3JnL2ZyZWVkZXNrdG9wL0hhbC9k ZXZpY2VzL2NvbXB1dGVyJyAgKHN0cmluZykKICBzeXN0ZW0uZmlybXdhcmUudmVyc2lvbiA9 ICc2QUVUNDhXVycgIChzdHJpbmcpCiAgcG93ZXJfbWFuYWdlbWVudC5jYW5fc3VzcGVuZF90 b19kaXNrID0gdHJ1ZSAgKGJvb2wpCiAgaW5mby5zdWJzeXN0ZW0gPSAndW5rbm93bicgIChz dHJpbmcpCiAgc3lzdGVtLmZpcm13YXJlLnJlbGVhc2VfZGF0ZSA9ICcxMC8wMS8yMDA4JyAg KHN0cmluZykKICBpbmZvLmludGVyZmFjZXMgPSB7ICdvcmcuZnJlZWRlc2t0b3AuSGFsLkRl dmljZS5TeXN0ZW1Qb3dlck1hbmFnZW1lbnQnIH0gKHN0cmluZyBsaXN0KQogIGluZm8ucHJv ZHVjdCA9ICdDb21wdXRlcicgIChzdHJpbmcpCiAgc3lzdGVtLmhhcmR3YXJlLnZlbmRvciA9 ICdMRU5PVk8nICAoc3RyaW5nKQogIG9yZy5mcmVlZGVza3RvcC5IYWwuRGV2aWNlLlN5c3Rl bVBvd2VyTWFuYWdlbWVudC5tZXRob2RfbmFtZXMgPSB7ICdTdXNwZW5kJywgJ1N1c3BlbmRI eWJyaWQnLCAnSGliZXJuYXRlJywgJ1NodXRkb3duJywgJ1JlYm9vdCcsICdTZXRQb3dlclNh dmUnIH0gKHN0cmluZyBsaXN0KQogIHN5c3RlbS5rZXJuZWwubmFtZSA9ICdGcmVlQlNEJyAg KHN0cmluZykKICBzeXN0ZW0uaGFyZHdhcmUucHJvZHVjdCA9ICcyNzQzN0RDJyAgKHN0cmlu ZykKICBvcmcuZnJlZWRlc2t0b3AuSGFsLkRldmljZS5TeXN0ZW1Qb3dlck1hbmFnZW1lbnQu bWV0aG9kX3NpZ25hdHVyZXMgPSB7ICdpJywgJ2knLCAnJywgJycsICcnLCAnYicgfSAoc3Ry aW5nIGxpc3QpCiAgc3lzdGVtLmtlcm5lbC52ZXJzaW9uID0gJzcuMi1QUkVSRUxFQVNFJyAg KHN0cmluZykKICBzeXN0ZW0uaGFyZHdhcmUudmVyc2lvbiA9ICdUaGlua1BhZCBTTDQwMCcg IChzdHJpbmcpCiAgb3JnLmZyZWVkZXNrdG9wLkhhbC5EZXZpY2UuU3lzdGVtUG93ZXJNYW5h Z2VtZW50Lm1ldGhvZF9hcmduYW1lcyA9IHsgJ251bV9zZWNvbmRzX3RvX3NsZWVwJywgJ251 bV9zZWNvbmRzX3RvX3NsZWVwJywgJycsICcnLCAnJywgJ2VuYWJsZV9wb3dlcl9zYXZlJyB9 IChzdHJpbmcgbGlzdCkKICBzeXN0ZW0ua2VybmVsLm1hY2hpbmUgPSAnaTM4NicgIChzdHJp bmcpCiAgc3lzdGVtLmhhcmR3YXJlLnNlcmlhbCA9ICdMM0FYQTZBJyAgKHN0cmluZykKICBv cmcuZnJlZWRlc2t0b3AuSGFsLkRldmljZS5TeXN0ZW1Qb3dlck1hbmFnZW1lbnQubWV0aG9k X2V4ZWNwYXRocyA9IHsgJ2hhbC1zeXN0ZW0tcG93ZXItc3VzcGVuZCcsICdoYWwtc3lzdGVt LXBvd2VyLXN1c3BlbmQtaHlicmlkJywgJ2hhbC1zeXN0ZW0tcG93ZXItaGliZXJuYXRlJywg J2hhbC1zeXN0ZW0tcG93ZXItc2h1dGRvd24nLCAnaGFsLXN5c3RlbS1wb3dlci1yZWJvb3Qn LCAnaGFsLXN5c3RlbS1wb3dlci1zZXQtcG93ZXItc2F2ZScgfSAoc3RyaW5nIGxpc3QpCiAg c3lzdGVtLmZvcm1mYWN0b3IgPSAnbGFwdG9wJyAgKHN0cmluZykKICBzeXN0ZW0uaGFyZHdh cmUudXVpZCA9ICc4MDgxNDRBRC04MEI2LUREODEtMzYxNi0wMDIyMTVCMTZGQjInICAoc3Ry aW5nKQogIHBvd2VyX21hbmFnZW1lbnQuaXNfcG93ZXJzYXZlX3NldCA9IGZhbHNlICAoYm9v bCkKICBwb3dlcl9tYW5hZ2VtZW50LnR5cGUgPSAnYWNwaScgIChzdHJpbmcpCiAgc3lzdGVt LmNoYXNzaXMubWFudWZhY3R1cmVyID0gJ0xFTk9WTycgIChzdHJpbmcpCiAgaW5mby5jYWxs b3V0cy5hZGQgPSB7ICdoYWwtc3RvcmFnZS1jbGVhbnVwLWFsbC1tb3VudHBvaW50cycgfSAo c3RyaW5nIGxpc3QpCiAgcG93ZXJfbWFuYWdlbWVudC5jYW5fc3VzcGVuZCA9IHRydWUgIChi b29sKQogIHN5c3RlbS5jaGFzc2lzLnR5cGUgPSAnTm90ZWJvb2snICAoc3RyaW5nKQogIHBv d2VyX21hbmFnZW1lbnQuY2FuX2hpYmVybmF0ZSA9IHRydWUgIChib29sKQogIHN5c3RlbS5w cm9kdWN0ID0gJzI3NDM3REMgVGhpbmtQYWQgU0w0MDAnICAoc3RyaW5nKQogIHN5c3RlbS5m aXJtd2FyZS52ZW5kb3IgPSAnTEVOT1ZPJyAgKHN0cmluZykKICBwb3dlcl9tYW5hZ2VtZW50 LmNhbl9zdXNwZW5kX3RvX3JhbSA9IHRydWUgIChib29sKQoK --------------050905040006050702000601 Content-Type: text/plain; name="kldstat.txt" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="kldstat.txt" SWQgUmVmcyBBZGRyZXNzICAgIFNpemUgICAgIE5hbWUKIDEgICAyMCAweGMwNDAwMDAwIGEx ZWM2MCAgIGtlcm5lbAogMiAgICAyIDB4YzBlMWYwMDAgNGE2MmMgICAgc291bmQua28KIDMg ICAgMSAweGMwZTZhMDAwIDFhZTM4ICAgIHNuZF9oZGEua28KIDQgICAgMSAweGMwZTg1MDAw IDU1ZDAgICAgIGFjcGlfdmlkZW8ua28KIDUgICAgMiAweGMwZThiMDAwIDZhNDVjICAgIGFj cGkua28KIDYgICAgMSAweGMwZWY2MDAwIGEyZDQgICAgIGk5MTUua28KIDcgICAgMiAweGMw ZjAxMDAwIDE2MzRjICAgIGRybS5rbwogOCAgICAxIDB4YzQ2ZjQwMDAgNzAwMCAgICAgbGlu cHJvY2ZzLmtvCiA5ICAgIDEgMHhjNDZmYjAwMCAyMjAwMCAgICBsaW51eC5rbwo= --------------050905040006050702000601 Content-Type: text/plain; name="sysctl_a.txt" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="sysctl_a.txt" a2Vybi5vc3R5cGU6IEZyZWVCU0QKa2Vybi5vc3JlbGVhc2U6IDcuMi1QUkVSRUxFQVNFCmtl cm4ub3NyZXZpc2lvbjogMTk5NTA2Cmtlcm4udmVyc2lvbjogRnJlZUJTRCA3LjItUFJFUkVM RUFTRSAjMTogVHVlIEFwciAgNyAxMjozOTo0NiBDU1QgMjAwOQogICAgcm9vdEBsdm0ubmV0 Oi91c3Ivb2JqL3Vzci9zcmMvc3lzL2tlcm5lbAoKa2Vybi5tYXh2bm9kZXM6IDY3NTY5Cmtl cm4ubWF4cHJvYzogNjE2NAprZXJuLm1heGZpbGVzOiAxMjMyOAprZXJuLmFyZ21heDogMjYy MTQ0Cmtlcm4uc2VjdXJlbGV2ZWw6IC0xCmtlcm4uaG9zdG5hbWU6IGx2bS5uZXQKa2Vybi5o b3N0aWQ6IDI5NzE5MDAxODMKa2Vybi5jbG9ja3JhdGU6IHsgaHogPSAxMDAwLCB0aWNrID0g MTAwMCwgcHJvZmh6ID0gMjAwMCwgc3RhdGh6ID0gMTMzIH0Ka2Vybi5wb3NpeDF2ZXJzaW9u OiAyMDAxMTIKa2Vybi5uZ3JvdXBzOiAxNgprZXJuLmpvYl9jb250cm9sOiAxCmtlcm4uc2F2 ZWRfaWRzOiAwCmtlcm4uYm9vdHRpbWU6IHsgc2VjID0gMTIzOTE5MDAzNSwgdXNlYyA9IDkx OTk2OSB9IFdlZCBBcHIgIDggMTk6Mjc6MTUgMjAwOQprZXJuLmRvbWFpbm5hbWU6IAprZXJu Lm9zcmVsZGF0ZTogNzAxMTA2Cmtlcm4uYm9vdGZpbGU6IC9ib290L2tlcm5lbC9rZXJuZWwK a2Vybi5tYXhmaWxlc3BlcnByb2M6IDExMDk1Cmtlcm4ubWF4cHJvY3BlcnVpZDogNTU0Nwpr ZXJuLmlwYy5tYXhzb2NrYnVmOiAyNjIxNDQKa2Vybi5pcGMuc29ja2J1Zl93YXN0ZV9mYWN0 b3I6IDgKa2Vybi5pcGMuc29tYXhjb25uOiAxMjgKa2Vybi5pcGMubWF4X2xpbmtoZHI6IDQw Cmtlcm4uaXBjLm1heF9wcm90b2hkcjogNjAKa2Vybi5pcGMubWF4X2hkcjogMTAwCmtlcm4u aXBjLm1heF9kYXRhbGVuOiAxMDQKa2Vybi5pcGMubm1ianVtYm8xNjogMzIwMAprZXJuLmlw Yy5ubWJqdW1ibzk6IDY0MDAKa2Vybi5pcGMubm1ianVtYm9wOiAxMjgwMAprZXJuLmlwYy5u bWJjbHVzdGVyczogMjU2MDAKa2Vybi5pcGMucGlwZXJlc2l6ZWFsbG93ZWQ6IDEKa2Vybi5p cGMucGlwZXJlc2l6ZWZhaWw6IDAKa2Vybi5pcGMucGlwZWFsbG9jZmFpbDogMAprZXJuLmlw Yy5waXBlZnJhZ3JldHJ5OiAwCmtlcm4uaXBjLnBpcGVrdmE6IDY3MTc0NAprZXJuLmlwYy5t YXhwaXBla3ZhOiAxNjc2NDkyOAprZXJuLmlwYy5tc2dzZWc6IDIwNDgKa2Vybi5pcGMubXNn c3N6OiA4Cmtlcm4uaXBjLm1zZ3RxbDogNDAKa2Vybi5pcGMubXNnbW5iOiAyMDQ4Cmtlcm4u aXBjLm1zZ21uaTogNDAKa2Vybi5pcGMubXNnbWF4OiAxNjM4NAprZXJuLmlwYy5zZW1hZW06 IDE2Mzg0Cmtlcm4uaXBjLnNlbXZteDogMzI3NjcKa2Vybi5pcGMuc2VtdXN6OiAxMzYKa2Vy bi5pcGMuc2VtdW1lOiAxMAprZXJuLmlwYy5zZW1vcG06IDEwMAprZXJuLmlwYy5zZW1tc2w6 IDYwCmtlcm4uaXBjLnNlbW1udTogMzAKa2Vybi5pcGMuc2VtbW5zOiA2MAprZXJuLmlwYy5z ZW1tbmk6IDEwCmtlcm4uaXBjLnNlbW1hcDogMzAKa2Vybi5pcGMuc2htX2FsbG93X3JlbW92 ZWQ6IDAKa2Vybi5pcGMuc2htX3VzZV9waHlzOiAwCmtlcm4uaXBjLnNobWFsbDogODE5Mgpr ZXJuLmlwYy5zaG1zZWc6IDEyOAprZXJuLmlwYy5zaG1tbmk6IDE5MgprZXJuLmlwYy5zaG1t aW46IDEKa2Vybi5pcGMuc2htbWF4OiAzMzU1NDQzMgprZXJuLmlwYy5tYXhzb2NrZXRzOiAy NTYwMAprZXJuLmlwYy5udW1vcGVuc29ja2V0czogMTA5Cmtlcm4uaXBjLm5zZmJ1ZnN1c2Vk OiAwCmtlcm4uaXBjLm5zZmJ1ZnNwZWFrOiA1Cmtlcm4uaXBjLm5zZmJ1ZnM6IDY2NTYKa2Vy bi5kdW1teTogMAprZXJuLnBzX3N0cmluZ3M6IDMyMTcwMzExNTIKa2Vybi51c3JzdGFjazog MzIxNzAzMTE2OAprZXJuLmxvZ3NpZ2V4aXQ6IDEKa2Vybi5pb3ZfbWF4OiAxMDI0Cmtlcm4u aG9zdHV1aWQ6IDgwODE0NGFkLTgwYjYtZGQ4MS0zNjE2LTAwMjIxNWIxNmZiMgprZXJuLmNh bS5jYW1fc3JjaF9oaTogMAprZXJuLmNhbS5zY3NpX2RlbGF5OiA1MDAwCmtlcm4uY2FtLmNk LnJldHJ5X2NvdW50OiA0Cmtlcm4uY2FtLmNkLmNoYW5nZXIubWF4X2J1c3lfc2Vjb25kczog MTUKa2Vybi5jYW0uY2QuY2hhbmdlci5taW5fYnVzeV9zZWNvbmRzOiA1Cmtlcm4uY2FtLmRh LmRhX3NlbmRfb3JkZXJlZDogMQprZXJuLmNhbS5kYS5kZWZhdWx0X3RpbWVvdXQ6IDYwCmtl cm4uY2FtLmRhLnJldHJ5X2NvdW50OiA0Cmtlcm4uZGNvbnMucG9sbF9oejogMTAwCmtlcm4u ZGlza3M6IGFkNAprZXJuLmdlb20uY29sbGVjdHN0YXRzOiAxCmtlcm4uZ2VvbS5kZWJ1Z2Zs YWdzOiAwCmtlcm4uZ2VvbS5sYWJlbC5kZWJ1ZzogMAprZXJuLmVsZjMyLmZhbGxiYWNrX2Jy YW5kOiAtMQprZXJuLmluaXRfc2h1dGRvd25fdGltZW91dDogMTIwCmtlcm4uaW5pdF9wYXRo OiAvc2Jpbi9pbml0Oi9zYmluL29pbml0Oi9zYmluL2luaXQuYmFrOi9yZXNjdWUvaW5pdDov c3RhbmQvc3lzaW5zdGFsbAprZXJuLmFjY3Rfc3VzcGVuZGVkOiAwCmtlcm4uYWNjdF9jb25m aWd1cmVkOiAwCmtlcm4uYWNjdF9jaGtmcmVxOiAxNQprZXJuLmFjY3RfcmVzdW1lOiA0Cmtl cm4uYWNjdF9zdXNwZW5kOiAyCmtlcm4uY3BfdGltZXM6IDI5MjgyIDE0ODggMTQ1ODcgODk0 IDIwMDY3MSAzMDE0NyAxMDgxIDE1MDIzIDQxMjggMTk1ODgxIDAgMCAwIDAgMCAwIDAgMCAw IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAw IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAw IDAgMCAwIDAgMCAwIDAKa2Vybi5jcF90aW1lOiA1OTQyOSAyNTY5IDI5NjExIDUwMjIgMzk2 NTUzCmtlcm4ub3BlbmZpbGVzOiA0NDkKa2Vybi5rcV9jYWxsb3V0bWF4OiA0MDk2Cmtlcm4u cHNfYXJnX2NhY2hlX2xpbWl0OiAyNTYKa2Vybi5zdGFja3Byb3Q6IDcKa2Vybi5yYW5kb21w aWQ6IDAKa2Vybi5sYXN0cGlkOiAyNjY5OAprZXJuLmt0cmFjZS5yZXF1ZXN0X3Bvb2w6IDEw MAprZXJuLmt0cmFjZS5nZW5pb19zaXplOiA0MDk2Cmtlcm4ubW9kdWxlX3BhdGg6IC9ib290 L2tlcm5lbDsvYm9vdC9tb2R1bGVzOy91c3IvbG9jYWwvbW9kdWxlcwprZXJuLm1hbGxvY19j b3VudDogMjY4Cmtlcm4uZmFsbGJhY2tfZWxmX2JyYW5kOiAtMQprZXJuLmZlYXR1cmVzLmNv bXBhdF9mcmVlYnNkNjogMQprZXJuLmZlYXR1cmVzLmNvbXBhdF9mcmVlYnNkNTogMQprZXJu LmZlYXR1cmVzLmNvbXBhdF9mcmVlYnNkNDogMQprZXJuLm1heHVzZXJzOiAzODQKa2Vybi5p ZGVudDogV09OREVSCmtlcm4ua3N0YWNrX3BhZ2VzOiAyCmtlcm4uc2h1dGRvd24ua3Byb2Nf c2h1dGRvd25fd2FpdDogNjAKa2Vybi5zaHV0ZG93bi5wb3dlcm9mZl9kZWxheTogNTAwMApr ZXJuLnN5bmNfb25fcGFuaWM6IDAKa2Vybi5jb3JlZmlsZTogJU4uY29yZQprZXJuLm5vZHVt cF9jb3JlZHVtcDogMAprZXJuLmNvcmVkdW1wOiAxCmtlcm4uc3VnaWRfY29yZWR1bXA6IDAK a2Vybi5zaWdxdWV1ZS5hbGxvY19mYWlsOiAwCmtlcm4uc2lncXVldWUub3ZlcmZsb3c6IDAK a2Vybi5zaWdxdWV1ZS5wcmVhbGxvY2F0ZTogMTAyNAprZXJuLnNpZ3F1ZXVlLm1heF9wZW5k aW5nX3Blcl9wcm9jOiAxMjgKa2Vybi5mb3JjZXNpZ2V4aXQ6IDEKa2Vybi5mc2NhbGU6IDIw NDgKa2Vybi50aW1lY291bnRlci50aWNrOiAxCmtlcm4udGltZWNvdW50ZXIuY2hvaWNlOiBU U0MoLTEwMCkgSFBFVCg5MDApIEFDUEktZmFzdCgxMDAwKSBpODI1NCgwKSBkdW1teSgtMTAw MDAwMCkKa2Vybi50aW1lY291bnRlci5oYXJkd2FyZTogQUNQSS1mYXN0Cmtlcm4udGltZWNv dW50ZXIuc3RlcHdhcm5pbmdzOiAwCmtlcm4udGltZWNvdW50ZXIudGMuaTgyNTQubWFzazog NjU1MzUKa2Vybi50aW1lY291bnRlci50Yy5pODI1NC5jb3VudGVyOiAzNzM1MAprZXJuLnRp bWVjb3VudGVyLnRjLmk4MjU0LmZyZXF1ZW5jeTogMTE5MzE4MgprZXJuLnRpbWVjb3VudGVy LnRjLmk4MjU0LnF1YWxpdHk6IDAKa2Vybi50aW1lY291bnRlci50Yy5BQ1BJLWZhc3QubWFz azogMTY3NzcyMTUKa2Vybi50aW1lY291bnRlci50Yy5BQ1BJLWZhc3QuY291bnRlcjogMTE4 NzkyNjUKa2Vybi50aW1lY291bnRlci50Yy5BQ1BJLWZhc3QuZnJlcXVlbmN5OiAzNTc5NTQ1 Cmtlcm4udGltZWNvdW50ZXIudGMuQUNQSS1mYXN0LnF1YWxpdHk6IDEwMDAKa2Vybi50aW1l Y291bnRlci50Yy5IUEVULm1hc2s6IDQyOTQ5NjcyOTUKa2Vybi50aW1lY291bnRlci50Yy5I UEVULmNvdW50ZXI6IDEwNzM0NDkyMzUKa2Vybi50aW1lY291bnRlci50Yy5IUEVULmZyZXF1 ZW5jeTogMTQzMTgxODAKa2Vybi50aW1lY291bnRlci50Yy5IUEVULnF1YWxpdHk6IDkwMApr ZXJuLnRpbWVjb3VudGVyLnRjLlRTQy5tYXNrOiA0Mjk0OTY3Mjk1Cmtlcm4udGltZWNvdW50 ZXIudGMuVFNDLmNvdW50ZXI6IDY0MzA5MTQ0Cmtlcm4udGltZWNvdW50ZXIudGMuVFNDLmZy ZXF1ZW5jeTogMzAwMDAwMDAwCmtlcm4udGltZWNvdW50ZXIudGMuVFNDLnF1YWxpdHk6IC0x MDAKa2Vybi50aW1lY291bnRlci5zbXBfdHNjOiAwCmtlcm4udGltZWNvdW50ZXIuaW52YXJp YW50X3RzYzogMAprZXJuLnRocmVhZHMudmlydHVhbF9jcHU6IDIKa2Vybi50aHJlYWRzLm1h eF90aHJlYWRzX2hpdHM6IDAKa2Vybi50aHJlYWRzLm1heF90aHJlYWRzX3Blcl9wcm9jOiAx NTAwCmtlcm4uY2NwdTogMAprZXJuLnNjaGVkLnByZWVtcHRpb246IDEKa2Vybi5zY2hlZC50 b3BvbG9neTogMAprZXJuLnNjaGVkLnN0ZWFsX3RocmVzaDogMQprZXJuLnNjaGVkLnN0ZWFs X2lkbGU6IDEKa2Vybi5zY2hlZC5zdGVhbF9odHQ6IDEKa2Vybi5zY2hlZC5iYWxhbmNlX2lu dGVydmFsOiAxMzMKa2Vybi5zY2hlZC5iYWxhbmNlOiAxCmtlcm4uc2NoZWQudHJ5c2VsZjog MQprZXJuLnNjaGVkLmFmZmluaXR5OiAzCmtlcm4uc2NoZWQucGlja19wcmk6IDEKa2Vybi5z Y2hlZC5wcmVlbXB0X3RocmVzaDogNjQKa2Vybi5zY2hlZC5pbnRlcmFjdDogMzAKa2Vybi5z Y2hlZC5zbGljZTogMTMKa2Vybi5zY2hlZC5uYW1lOiBVTEUKa2Vybi5kZXZzdGF0LnZlcnNp b246IDYKa2Vybi5kZXZzdGF0LmdlbmVyYXRpb246IDIzNwprZXJuLmRldnN0YXQubnVtZGV2 czogMQprZXJuLmtvYmpfbWV0aG9kY291bnQ6IDE1NAprZXJuLmxvZ193YWtldXBzX3Blcl9z ZWNvbmQ6IDUKa2Vybi5zZ3Jvd3NpejogMTMxMDcyCmtlcm4ubWF4c3NpejogNjcxMDg4NjQK a2Vybi5kZmxzc2l6OiA4Mzg4NjA4Cmtlcm4ubWF4ZHNpejogNzM0MDAzMjAwCmtlcm4uZGZs ZHNpejogMTM0MjE3NzI4Cmtlcm4ubWF4dHNpejogMTM0MjE3NzI4Cmtlcm4ubWF4YmNhY2hl OiAyMDk3MTUyMDAKa2Vybi5tYXhzd3pvbmU6IDMzNTU0NDMyCmtlcm4ubnN3YnVmOiAyNTYK a2Vybi5uYnVmOiA2OTE4Cmtlcm4ubmNhbGxvdXQ6IDE4NTA4Cmtlcm4uaHo6IDEwMDAKa2Vy bi5tc2didWZfY2xlYXI6IDAKa2Vybi5tc2didWY6IAprZXJuLmFsd2F5c19jb25zb2xlX291 dHB1dDogMAprZXJuLmxvZ19jb25zb2xlX291dHB1dDogMQprZXJuLnNtcC5mb3J3YXJkX3Jv dW5kcm9iaW5fZW5hYmxlZDogMQprZXJuLnNtcC5mb3J3YXJkX3NpZ25hbF9lbmFibGVkOiAx Cmtlcm4uc21wLmNwdXM6IDIKa2Vybi5zbXAuZGlzYWJsZWQ6IDAKa2Vybi5zbXAuYWN0aXZl OiAxCmtlcm4uc21wLm1heGNwdXM6IDE2Cmtlcm4uc21wLm1heGlkOiAxNQprZXJuLm5zZWxj b2xsOiAwCmtlcm4udHR5X25vdXQ6IDM2NjEzNAprZXJuLnR0eV9uaW46IDI4MzEKa2Vybi5k cmFpbndhaXQ6IDMwMAprZXJuLmNvbnN0dHlfd2FrZXVwc19wZXJfc2Vjb25kOiA1Cmtlcm4u Y29uc21zZ2J1Zl9zaXplOiA4MTkyCmtlcm4uY29uc211dGU6IDAKa2Vybi5jb25zb2xlOiBj b25zb2xlY3RsLGRjb25zLC9kY29ucyxjb25zb2xlY3RsLHR0eWQwLAprZXJuLm1pbnZub2Rl czogMTY4OTIKa2Vybi5tZXRhZGVsYXk6IDI4Cmtlcm4uZGlyZGVsYXk6IDI5Cmtlcm4uZmls ZWRlbGF5OiAzMAprZXJuLmNocm9vdF9hbGxvd19vcGVuX2RpcmVjdG9yaWVzOiAxCmtlcm4u cnBjLmludmFsaWQ6IDAKa2Vybi5ycGMudW5leHBlY3RlZDogMAprZXJuLnJwYy50aW1lb3V0 czogMAprZXJuLnJwYy5yZXF1ZXN0OiAwCmtlcm4ucnBjLnJldHJpZXM6IDAKa2Vybi5yYW5k b20ueWFycm93LmdlbmdhdGVpbnRlcnZhbDogMTAKa2Vybi5yYW5kb20ueWFycm93LmJpbnM6 IDEwCmtlcm4ucmFuZG9tLnlhcnJvdy5mYXN0dGhyZXNoOiAxOTIKa2Vybi5yYW5kb20ueWFy cm93LnNsb3d0aHJlc2g6IDI1NgprZXJuLnJhbmRvbS55YXJyb3cuc2xvd292ZXJ0aHJlc2g6 IDIKa2Vybi5yYW5kb20uc3lzLnNlZWRlZDogMQprZXJuLnJhbmRvbS5zeXMuaGFydmVzdC5l dGhlcm5ldDogMQprZXJuLnJhbmRvbS5zeXMuaGFydmVzdC5wb2ludF90b19wb2ludDogMQpr ZXJuLnJhbmRvbS5zeXMuaGFydmVzdC5pbnRlcnJ1cHQ6IDEKa2Vybi5yYW5kb20uc3lzLmhh cnZlc3Quc3dpOiAwCnZtLnZtdG90YWw6IApTeXN0ZW0gd2lkZSB0b3RhbHMgY29tcHV0ZWQg ZXZlcnkgZml2ZSBzZWNvbmRzOiAodmFsdWVzIGluIGtpbG9ieXRlcykKPT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KUHJvY2Vzc2VzOgkJKFJVTlE6 IDEgRGlzayBXYWl0OiAxIFBhZ2UgV2FpdDogMCBTbGVlcDogNzgpClZpcnR1YWwgTWVtb3J5 OgkJKFRvdGFsOiAyNjgwNzg0SywgQWN0aXZlIDQzMDk0NEspClJlYWwgTWVtb3J5OgkJKFRv dGFsOiAzODY0MzZLIEFjdGl2ZSAxOTY5MDRLKQpTaGFyZWQgVmlydHVhbCBNZW1vcnk6CShU b3RhbDogODQwNDhLIEFjdGl2ZTogNzk4NjRLKQpTaGFyZWQgUmVhbCBNZW1vcnk6CShUb3Rh bDogNTQzNTJLIEFjdGl2ZTogNTE4NjhLKQpGcmVlIE1lbW9yeSBQYWdlczoJMTQxMjUySwoK dm0ubG9hZGF2ZzogeyAwLjMwIDAuNDEgMC4zNCB9CnZtLnZfZnJlZV9taW46IDE1OTUKdm0u dl9mcmVlX3RhcmdldDogNjc0OQp2bS52X2ZyZWVfcmVzZXJ2ZWQ6IDM2OQp2bS52X2luYWN0 aXZlX3RhcmdldDogMTAxMjMKdm0udl9jYWNoZV9taW46IDY3NDkKdm0udl9jYWNoZV9tYXg6 IDEzNDk4CnZtLnZfcGFnZW91dF9mcmVlX21pbjogMzQKdm0ucGFnZW91dF9hbGdvcml0aG06 IDAKdm0uc3dhcF9lbmFibGVkOiAxCnZtLmttZW1fc2l6ZV9zY2FsZTogMwp2bS5rbWVtX3Np emVfbWF4OiAzMzU1NDQzMjAKdm0ua21lbV9zaXplX21pbjogMAp2bS5rbWVtX3NpemU6IDMz NTM1NTkwNAp2bS5uc3dhcGRldjogMQp2bS5kbW1heDogMzIKdm0uc3dhcF9hc3luY19tYXg6 IDQKdm0uem9uZV9jb3VudDogMTAwCnZtLnN3YXBfaWRsZV90aHJlc2hvbGQyOiAxMAp2bS5z d2FwX2lkbGVfdGhyZXNob2xkMTogMgp2bS5leGVjX21hcF9lbnRyaWVzOiAxNgp2bS5zdGF0 cy5taXNjLnplcm9fcGFnZV9jb3VudDogMQp2bS5zdGF0cy5taXNjLmNudF9wcmV6ZXJvOiAw CnZtLnN0YXRzLnZtLnZfa3RocmVhZHBhZ2VzOiAwCnZtLnN0YXRzLnZtLnZfcmZvcmtwYWdl czogMAp2bS5zdGF0cy52bS52X3Zmb3JrcGFnZXM6IDE0ODQ5MjEKdm0uc3RhdHMudm0udl9m b3JrcGFnZXM6IDMyNTQ0MzYKdm0uc3RhdHMudm0udl9rdGhyZWFkczogNTkKdm0uc3RhdHMu dm0udl9yZm9ya3M6IDAKdm0uc3RhdHMudm0udl92Zm9ya3M6IDk1MzIKdm0uc3RhdHMudm0u dl9mb3JrczogMTcxMDcKdm0uc3RhdHMudm0udl9pbnRlcnJ1cHRfZnJlZV9taW46IDIKdm0u c3RhdHMudm0udl9wYWdlb3V0X2ZyZWVfbWluOiAzNAp2bS5zdGF0cy52bS52X2NhY2hlX21h eDogMTM0OTgKdm0uc3RhdHMudm0udl9jYWNoZV9taW46IDY3NDkKdm0uc3RhdHMudm0udl9j YWNoZV9jb3VudDogOAp2bS5zdGF0cy52bS52X2luYWN0aXZlX2NvdW50OiAxMTIzNTQKdm0u c3RhdHMudm0udl9pbmFjdGl2ZV90YXJnZXQ6IDEwMTIzCnZtLnN0YXRzLnZtLnZfYWN0aXZl X2NvdW50OiAzMjQ4Ngp2bS5zdGF0cy52bS52X3dpcmVfY291bnQ6IDY1MjgwCnZtLnN0YXRz LnZtLnZfZnJlZV9jb3VudDogMzUzMDUKdm0uc3RhdHMudm0udl9mcmVlX21pbjogMTU5NQp2 bS5zdGF0cy52bS52X2ZyZWVfdGFyZ2V0OiA2NzQ5CnZtLnN0YXRzLnZtLnZfZnJlZV9yZXNl cnZlZDogMzY5CnZtLnN0YXRzLnZtLnZfcGFnZV9jb3VudDogMjQ1NjIzCnZtLnN0YXRzLnZt LnZfcGFnZV9zaXplOiA0MDk2CnZtLnN0YXRzLnZtLnZfdGZyZWU6IDMyNTkxOTMKdm0uc3Rh dHMudm0udl9wZnJlZTogMjA4NzYwMQp2bS5zdGF0cy52bS52X2RmcmVlOiAwCnZtLnN0YXRz LnZtLnZfdGNhY2hlZDogMTU5OAp2bS5zdGF0cy52bS52X3BkcGFnZXM6IDAKdm0uc3RhdHMu dm0udl9wZHdha2V1cHM6IDAKdm0uc3RhdHMudm0udl9yZWFjdGl2YXRlZDogOTM5CnZtLnN0 YXRzLnZtLnZfaW50cmFuczogMTMyCnZtLnN0YXRzLnZtLnZfdm5vZGVwZ3NvdXQ6IDAKdm0u c3RhdHMudm0udl92bm9kZXBnc2luOiAxNzc2NAp2bS5zdGF0cy52bS52X3Zub2Rlb3V0OiAw CnZtLnN0YXRzLnZtLnZfdm5vZGVpbjogMjE3NQp2bS5zdGF0cy52bS52X3N3YXBwZ3NvdXQ6 IDAKdm0uc3RhdHMudm0udl9zd2FwcGdzaW46IDAKdm0uc3RhdHMudm0udl9zd2Fwb3V0OiAw CnZtLnN0YXRzLnZtLnZfc3dhcGluOiAwCnZtLnN0YXRzLnZtLnZfb3pmb2Q6IDY3ODUyCnZt LnN0YXRzLnZtLnZfemZvZDogMTk5MTgzNAp2bS5zdGF0cy52bS52X2Nvd19vcHRpbTogMjk3 Mgp2bS5zdGF0cy52bS52X2Nvd19mYXVsdHM6IDY0ODE1MAp2bS5zdGF0cy52bS52X3ZtX2Zh dWx0czogMzI0MjA5NAp2bS5zdGF0cy5zeXMudl9zb2Z0OiAzMzg0MjQKdm0uc3RhdHMuc3lz LnZfaW50cjogMzE3MDcxCnZtLnN0YXRzLnN5cy52X3N5c2NhbGw6IDIxOTcxNzk2CnZtLnN0 YXRzLnN5cy52X3RyYXA6IDMzODExNjIKdm0uc3RhdHMuc3lzLnZfc3d0Y2g6IDQ2NjQwMDcK dm0uc3RhdHMub2JqZWN0LmJ5cGFzc2VzOiA1OTcwCnZtLnN0YXRzLm9iamVjdC5jb2xsYXBz ZXM6IDg1MzI0CnZtLnZfZnJlZV9zZXZlcmU6IDk4Mgp2bS5tYXhfcHJvY19tbWFwOiA0OTMx Nwp2bS5vbGRfbXN5bmM6IDAKdm0ubXN5bmNfZmx1c2hfZmxhZ3M6IDMKdm0uYm9vdF9wYWdl czogNDgKdm0ubWF4X3dpcmVkOiA4MDY1NQp2bS5wYWdlb3V0X2xvY2tfbWlzczogMAp2bS5k aXNhYmxlX3N3YXBzcGFjZV9wYWdlb3V0czogMAp2bS5kZWZlcl9zd2Fwc3BhY2VfcGFnZW91 dHM6IDAKdm0uc3dhcF9pZGxlX2VuYWJsZWQ6IDAKdm0ucGFnZW91dF9zdGF0c19pbnRlcnZh bDogNQp2bS5wYWdlb3V0X2Z1bGxfc3RhdHNfaW50ZXJ2YWw6IDIwCnZtLnBhZ2VvdXRfc3Rh dHNfbWF4OiA2NzQ5CnZtLm1heF9sYXVuZGVyOiAzMgp2bS5waHlzX3NlZ3M6IApTRUdNRU5U IDA6CgpzdGFydDogICAgIDB4MTAwMAplbmQ6ICAgICAgIDB4OWUwMDAKZnJlZSBsaXN0OiAw eGMwY2VjM2M4CgpTRUdNRU5UIDE6CgpzdGFydDogICAgIDB4MTAwMDAwCmVuZDogICAgICAg MHg0MDAwMDAKZnJlZSBsaXN0OiAweGMwY2VjM2M4CgpTRUdNRU5UIDI6CgpzdGFydDogICAg IDB4MTAyNTAwMAplbmQ6ICAgICAgIDB4M2NiZmYwMDAKZnJlZSBsaXN0OiAweGMwY2VjMmMw Cgp2bS5waHlzX2ZyZWU6IApGUkVFIExJU1QgMDoKCiAgT1JERVIgKFNJWkUpICB8ICBOVU1C RVIKICAgICAgICAgICAgICAgIHwgIFBPT0wgMCAgfCAgUE9PTCAxCi0tICAgICAgICAgICAg LS0gLS0gICAgICAtLSAtLSAgICAgIC0tCiAgMTAgKCAgNDA5NkspICB8ICAgICAgIDAgIHwg ICAgICAgMAogICA5ICggIDIwNDhLKSAgfCAgICAgICAwICB8ICAgICAgIDAKICAgOCAoICAx MDI0SykgIHwgICAgICAgMiAgfCAgICAgICAwCiAgIDcgKCAgIDUxMkspICB8ICAgICAgIDAg IHwgICAgICAgMAogICA2ICggICAyNTZLKSAgfCAgICAgICAxICB8ICAgICAgIDAKICAgNSAo ICAgMTI4SykgIHwgICAgICAgMSAgfCAgICAgICAwCiAgIDQgKCAgICA2NEspICB8ICAgICAg IDEgIHwgICAgICAgMAogICAzICggICAgMzJLKSAgfCAgICAgICAxICB8ICAgICAgIDAKICAg MiAoICAgIDE2SykgIHwgICAgICAgMCAgfCAgICAgICAwCiAgIDEgKCAgICAgOEspICB8ICAg ICAgIDAgIHwgICAgICAgMAogICAwICggICAgIDRLKSAgfCAgICAgICAwICB8ICAgICAgIDAK CkZSRUUgTElTVCAxOgoKICBPUkRFUiAoU0laRSkgIHwgIE5VTUJFUgogICAgICAgICAgICAg ICAgfCAgUE9PTCAwICB8ICBQT09MIDEKLS0gICAgICAgICAgICAtLSAtLSAgICAgIC0tIC0t ICAgICAgLS0KICAxMCAoICA0MDk2SykgIHwgICAgICAgMCAgfCAgICAgICAwCiAgIDkgKCAg MjA0OEspICB8ICAgICAgIDAgIHwgICAgICAgMAogICA4ICggIDEwMjRLKSAgfCAgICAgICAw ICB8ICAgICAgIDAKICAgNyAoICAgNTEySykgIHwgICAgICAgMCAgfCAgICAgICAwCiAgIDYg KCAgIDI1NkspICB8ICAgICAgIDAgIHwgICAgICAgMAogICA1ICggICAxMjhLKSAgfCAgICAg ICAwICB8ICAgICAgIDAKICAgNCAoICAgIDY0SykgIHwgICAgICAgMCAgfCAgICAgICAwCiAg IDMgKCAgICAzMkspICB8ICAgICAgIDAgIHwgICAgICAgMAogICAyICggICAgMTZLKSAgfCAg ICAgICAwICB8ICAgICAgIDAKICAgMSAoICAgICA4SykgIHwgICAgICAgMCAgfCAgICAgICAw CiAgIDAgKCAgICAgNEspICB8ICAgICAgIDAgIHwgICAgICAgMAoKdm0ucmVzZXJ2LnJlY2xh aW1lZDogMTAKdm0ucmVzZXJ2LnBhcnRwb3BxOiAKTEVWRUwgICAgIFNJWkUgIE5VTUJFUgoK ICAgLTE6IDEzODcyMEssICAgICA0NAoKdm0ucmVzZXJ2LmZyZWVkOiAxNjczCnZtLnJlc2Vy di5icm9rZW46IDAKdm0uaWRsZXplcm9fZW5hYmxlOiAwCnZtLmt2bV9mcmVlOiA0MTUyMzIw MDAKdm0ua3ZtX3NpemU6IDEwNzM3Mzc3MjgKdm0ucG1hcC5wbWFwX2NvbGxlY3RfYWN0aXZl OiAwCnZtLnBtYXAucG1hcF9jb2xsZWN0X2luYWN0aXZlOiAwCnZtLnBtYXAucHZfZW50cnlf c3BhcmU6IDEwOTE4CnZtLnBtYXAucHZfZW50cnlfYWxsb2NzOiAxNjI3MjkxMQp2bS5wbWFw LnB2X2VudHJ5X2ZyZWVzOiAxNjE5OTE1Nwp2bS5wbWFwLnBjX2NodW5rX3RyeWZhaWw6IDAK dm0ucG1hcC5wY19jaHVua19mcmVlczogNzM1NzQKdm0ucG1hcC5wY19jaHVua19hbGxvY3M6 IDczODI2CnZtLnBtYXAucGNfY2h1bmtfY291bnQ6IDI1Mgp2bS5wbWFwLnB2X2VudHJ5X2Nv dW50OiA3Mzc1NAp2bS5wbWFwLnBkZS5wcm9tb3Rpb25zOiAwCnZtLnBtYXAucGRlLnBfZmFp bHVyZXM6IDAKdm0ucG1hcC5wZGUubWFwcGluZ3M6IDAKdm0ucG1hcC5wZGUuZGVtb3Rpb25z OiAwCnZtLnBtYXAuc2hwZ3BlcnByb2M6IDIwMAp2bS5wbWFwLnB2X2VudHJ5X21heDogMTQ3 ODczNgp2bS5wbWFwLnBnX3BzX2VuYWJsZWQ6IDAKdmZzLm5mczQuYWNjZXNzX2NhY2hlX3Rp bWVvdXQ6IDYwCnZmcy5uZnMuZG93bmRlbGF5aW5pdGlhbDogMTIKdmZzLm5mcy5kb3duZGVs YXlpbnRlcnZhbDogMzAKdmZzLm5mcy5za2lwX3djY19kYXRhX29uZXJyOiAxCnZmcy5uZnMu bmZzM19qdWtlYm94X2RlbGF5OiAxMAp2ZnMubmZzLnJlY29ubmVjdHM6IDAKdmZzLm5mcy5i dWZwYWNrZXRzOiA0CnZmcy5uZnMucmVhbGlnbl9jb3VudDogMAp2ZnMubmZzLnJlYWxpZ25f dGVzdDogMAp2ZnMubmZzLmRlZmVjdDogMAp2ZnMubmZzLmlvZG1heDogMjAKdmZzLm5mcy5p b2RtaW46IDAKdmZzLm5mcy5pb2RtYXhpZGxlOiAxMjAKdmZzLm5mcy5kaXNrbGVzc19yb290 cGF0aDogCnZmcy5uZnMuZGlza2xlc3NfdmFsaWQ6IDAKdmZzLm5mcy5uZnNfaXBfcGFyYW5v aWE6IDEKdmZzLm5mcy5uZnNfZGlyZWN0aW9fYWxsb3dfbW1hcDogMQp2ZnMubmZzLm5mc19k aXJlY3Rpb19lbmFibGU6IDAKdmZzLm5mcy5jbGVhbl9wYWdlc19vbl9jbG9zZTogMQp2ZnMu bmZzLm5mc3YzX2NvbW1pdF9vbl9jbG9zZTogMAp2ZnMubmZzLnByaW1lX2FjY2Vzc19jYWNo ZTogMQp2ZnMubmZzLmFjY2Vzc19jYWNoZV90aW1lb3V0OiA2MAp2ZnMudWZzLmRpcmhhc2hf ZG9jaGVjazogMAp2ZnMudWZzLmRpcmhhc2hfbWVtOiAyMDM3MDE3CnZmcy51ZnMuZGlyaGFz aF9tYXhtZW06IDIwOTcxNTIKdmZzLnVmcy5kaXJoYXNoX21pbnNpemU6IDI1NjAKdmZzLmRl dmZzLnJ1bGVfZGVwdGg6IDEKdmZzLmRldmZzLmdlbmVyYXRpb246IDEyOQp2ZnMucGZzLnRy YWNlOiAwCnZmcy5wZnMudm5jYWNoZS5taXNzZXM6IDIKdmZzLnBmcy52bmNhY2hlLmhpdHM6 IDIKdmZzLnBmcy52bmNhY2hlLm1heGVudHJpZXM6IDEKdmZzLnBmcy52bmNhY2hlLmVudHJp ZXM6IDAKdmZzLmZsdXNod2l0aGRlcHM6IDAKdmZzLmdldG5ld2J1ZnJlc3RhcnRzOiAwCnZm cy5nZXRuZXdidWZjYWxsczogMTE5MDg4CnZmcy5oaWZyZWVidWZmZXJzOiA3NzgKdmZzLmxv ZnJlZWJ1ZmZlcnM6IDM4OQp2ZnMubnVtZnJlZWJ1ZmZlcnM6IDY4OTUKdmZzLmRpcnR5YnVm dGhyZXNoOiAxNTc0CnZmcy5oaWRpcnR5YnVmZmVyczogMTc0OQp2ZnMubG9kaXJ0eWJ1ZmZl cnM6IDg3NAp2ZnMubnVtZGlydHlidWZmZXJzOiAyMwp2ZnMucmVjdXJzaXZlZmx1c2hlczog MjIxMgp2ZnMuYWx0YnVmZmVyZmx1c2hlczogMAp2ZnMuYmR3cml0ZXNraXA6IDAKdmZzLmRp cnR5YnVmZmVyZmx1c2hlczogMAp2ZnMuaGlydW5uaW5nc3BhY2U6IDEwNDg1NzYKdmZzLmxv cnVubmluZ3NwYWNlOiA1MjQyODgKdmZzLmJ1ZmRlZnJhZ2NudDogMAp2ZnMuYnVmZnJlZWt2 YWNudDogMAp2ZnMuYnVmcmV1c2VjbnQ6IDY4NzQKdmZzLmhpYnVmc3BhY2U6IDExMjY4OTE1 Mgp2ZnMubG9idWZzcGFjZTogMTEyNjIzNjE2CnZmcy5tYXhtYWxsb2NidWZzcGFjZTogNTYz NDQ1Nwp2ZnMuYnVmbWFsbG9jc3BhY2U6IDAKdmZzLm1heGJ1ZnNwYWNlOiAxMTMzNDQ1MTIK dmZzLmJ1ZnNwYWNlOiAxMTI2MjM2MTYKdmZzLnJ1bm5pbmdidWZzcGFjZTogMAp2ZnMudm1p b2RpcmVuYWJsZTogMQp2ZnMuY2FjaGUubnVtZnVsbHBhdGhmb3VuZDogMTA3OTIKdmZzLmNh Y2hlLm51bWZ1bGxwYXRoZmFpbDQ6IDAKdmZzLmNhY2hlLm51bWZ1bGxwYXRoZmFpbDI6IDAK dmZzLmNhY2hlLm51bWZ1bGxwYXRoZmFpbDE6IDAKdmZzLmNhY2hlLm51bWZ1bGxwYXRoY2Fs bHM6IDEwNzkyCnZmcy5jYWNoZS5uY2hzdGF0czogMjE3NzM1NCAxNjg2MDQgMjEzIDAgNzc5 MTE5IDAgODgxNzggODkwOTMKdmZzLmNhY2hlLm51bW5lZ2hpdHM6IDE2ODYwNAp2ZnMuY2Fj aGUubnVtbmVnemFwczogNDQKdmZzLmNhY2hlLm51bXBvc2hpdHM6IDIxNzczNTQKdmZzLmNh Y2hlLm51bXBvc3phcHM6IDE2OQp2ZnMuY2FjaGUubnVtbWlzc3phcDogOTkKdmZzLmNhY2hl Lm51bW1pc3M6IDc3OTAyMAp2ZnMuY2FjaGUubnVtY2hlY2tzOiAzMzA5MjQ2CnZmcy5jYWNo ZS5kb3Rkb3RoaXRzOiAxMzQyNzIKdmZzLmNhY2hlLmRvdGhpdHM6IDI5MjcKdmZzLmNhY2hl Lm51bWNhbGxzOiAzMjYyNDg5CnZmcy5jYWNoZS5udW1jYWNoZTogNjE1NjYKdmZzLmNhY2hl Lm51bW5lZzogMzg0Nwp2ZnMucmVhZF9tYXg6IDgKdmZzLndyaXRlX2JlaGluZDogMQp2ZnMu bG9va3VwX3NoYXJlZDogMAp2ZnMudXNlcm1vdW50OiAxCnZmcy53b3JrbGlzdF9sZW46IDcK dmZzLnRpbWVzdGFtcF9wcmVjaXNpb246IDAKdmZzLnJlYXNzaWduYnVmY2FsbHM6IDM1NDg3 CnZmcy5mcmVldm5vZGVzOiAxNjg2Mgp2ZnMud2FudGZyZWV2bm9kZXM6IDE2ODkyCnZmcy5u dW12bm9kZXM6IDU3ODA4CnZmcy5uZnNydi5uZnNfcHJpdnBvcnQ6IDAKdmZzLm5mc3J2LmNv bW1pdF9taXNzOiAwCnZmcy5uZnNydi5jb21taXRfYmxrczogMAp2ZnMubmZzcnYuYXN5bmM6 IDAKdmZzLm5mc3J2LnJlYWxpZ25fY291bnQ6IDAKdmZzLm5mc3J2LnJlYWxpZ25fdGVzdDog MAp2ZnMubmZzcnYuZ2F0aGVyZGVsYXlfdjM6IDAKdmZzLm5mc3J2LmdhdGhlcmRlbGF5OiAx MDAwMAp2ZnMuZmZzLmRvcmVhbGxvY2Jsa3M6IDEKdmZzLmZmcy5kb2FzeW5jZnJlZTogMQp2 ZnMuZmZzLmNvbXB1dGVfc3VtbWFyeV9hdF9tb3VudDogMApuZXQubG9jYWwuc3RyZWFtLnJl Y3ZzcGFjZTogODE5MgpuZXQubG9jYWwuc3RyZWFtLnNlbmRzcGFjZTogODE5MgpuZXQubG9j YWwuZGdyYW0ucmVjdnNwYWNlOiA0MDk2Cm5ldC5sb2NhbC5kZ3JhbS5tYXhkZ3JhbTogMjA0 OApuZXQubG9jYWwucmVjeWNsZWQ6IDAKbmV0LmxvY2FsLnRhc2tjb3VudDogMApuZXQubG9j YWwuaW5mbGlnaHQ6IDAKbmV0LmluZXQuaXAucG9ydHJhbmdlLnJhbmRvbXRpbWU6IDQ1Cm5l dC5pbmV0LmlwLnBvcnRyYW5nZS5yYW5kb21jcHM6IDEwCm5ldC5pbmV0LmlwLnBvcnRyYW5n ZS5yYW5kb21pemVkOiAxCm5ldC5pbmV0LmlwLnBvcnRyYW5nZS5yZXNlcnZlZGxvdzogMApu ZXQuaW5ldC5pcC5wb3J0cmFuZ2UucmVzZXJ2ZWRoaWdoOiAxMDIzCm5ldC5pbmV0LmlwLnBv cnRyYW5nZS5oaWxhc3Q6IDY1NTM1Cm5ldC5pbmV0LmlwLnBvcnRyYW5nZS5oaWZpcnN0OiA0 OTE1MgpuZXQuaW5ldC5pcC5wb3J0cmFuZ2UubGFzdDogNjU1MzUKbmV0LmluZXQuaXAucG9y dHJhbmdlLmZpcnN0OiA0OTE1MgpuZXQuaW5ldC5pcC5wb3J0cmFuZ2UubG93bGFzdDogNjAw Cm5ldC5pbmV0LmlwLnBvcnRyYW5nZS5sb3dmaXJzdDogMTAyMwpuZXQuaW5ldC5pcC5mb3J3 YXJkaW5nOiAwCm5ldC5pbmV0LmlwLnJlZGlyZWN0OiAxCm5ldC5pbmV0LmlwLnR0bDogNjQK bmV0LmluZXQuaXAucnRleHBpcmU6IDM2MDAKbmV0LmluZXQuaXAucnRtaW5leHBpcmU6IDEw Cm5ldC5pbmV0LmlwLnJ0bWF4Y2FjaGU6IDEyOApuZXQuaW5ldC5pcC5zb3VyY2Vyb3V0ZTog MApuZXQuaW5ldC5pcC5pbnRyX3F1ZXVlX21heGxlbjogNTAKbmV0LmluZXQuaXAuaW50cl9x dWV1ZV9kcm9wczogMApuZXQuaW5ldC5pcC5hY2NlcHRfc291cmNlcm91dGU6IDAKbmV0Lmlu ZXQuaXAua2VlcGZhaXRoOiAwCm5ldC5pbmV0LmlwLmdpZnR0bDogMzAKbmV0LmluZXQuaXAu c2FtZV9wcmVmaXhfY2FycF9vbmx5OiAwCm5ldC5pbmV0LmlwLnN1Ym5ldHNfYXJlX2xvY2Fs OiAwCm5ldC5pbmV0LmlwLmZhc3Rmb3J3YXJkaW5nOiAwCm5ldC5pbmV0LmlwLm1heGZyYWdw YWNrZXRzOiA4MDAKbmV0LmluZXQuaXAubWF4ZnJhZ3NwZXJwYWNrZXQ6IDE2Cm5ldC5pbmV0 LmlwLmZyYWdwYWNrZXRzOiAwCm5ldC5pbmV0LmlwLmNoZWNrX2ludGVyZmFjZTogMApuZXQu aW5ldC5pcC5yYW5kb21faWQ6IDAKbmV0LmluZXQuaXAuc2VuZHNvdXJjZXF1ZW5jaDogMApu ZXQuaW5ldC5pcC5wcm9jZXNzX29wdGlvbnM6IDEKbmV0LmluZXQuaWNtcC5tYXNrcmVwbDog MApuZXQuaW5ldC5pY21wLmljbXBsaW06IDIwMApuZXQuaW5ldC5pY21wLmJtY2FzdGVjaG86 IDAKbmV0LmluZXQuaWNtcC5xdW90ZWxlbjogOApuZXQuaW5ldC5pY21wLnJlcGx5X2Zyb21f aW50ZXJmYWNlOiAwCm5ldC5pbmV0LmljbXAucmVwbHlfc3JjOiAKbmV0LmluZXQuaWNtcC5p Y21wbGltX291dHB1dDogMQpuZXQuaW5ldC5pY21wLmxvZ19yZWRpcmVjdDogMApuZXQuaW5l dC5pY21wLmRyb3BfcmVkaXJlY3Q6IDAKbmV0LmluZXQuaWNtcC5tYXNrZmFrZTogMApuZXQu aW5ldC50Y3AucmZjMTMyMzogMQpuZXQuaW5ldC50Y3AubXNzZGZsdDogNTEyCm5ldC5pbmV0 LnRjcC5rZWVwaWRsZTogNzIwMDAwMApuZXQuaW5ldC50Y3Aua2VlcGludHZsOiA3NTAwMApu ZXQuaW5ldC50Y3Auc2VuZHNwYWNlOiAzMjc2OApuZXQuaW5ldC50Y3AucmVjdnNwYWNlOiA2 NTUzNgpuZXQuaW5ldC50Y3Aua2VlcGluaXQ6IDc1MDAwCm5ldC5pbmV0LnRjcC5kZWxhY2t0 aW1lOiAxMDAKbmV0LmluZXQudGNwLnY2bXNzZGZsdDogMTAyNApuZXQuaW5ldC50Y3AuaG9z dGNhY2hlLnB1cmdlOiAwCm5ldC5pbmV0LnRjcC5ob3N0Y2FjaGUucHJ1bmU6IDMwMApuZXQu aW5ldC50Y3AuaG9zdGNhY2hlLmV4cGlyZTogMzYwMApuZXQuaW5ldC50Y3AuaG9zdGNhY2hl LmNvdW50OiAxCm5ldC5pbmV0LnRjcC5ob3N0Y2FjaGUuYnVja2V0bGltaXQ6IDMwCm5ldC5p bmV0LnRjcC5ob3N0Y2FjaGUuaGFzaHNpemU6IDUxMgpuZXQuaW5ldC50Y3AuaG9zdGNhY2hl LmNhY2hlbGltaXQ6IDE1MzYwCm5ldC5pbmV0LnRjcC5yZWN2YnVmX21heDogMjYyMTQ0Cm5l dC5pbmV0LnRjcC5yZWN2YnVmX2luYzogMTYzODQKbmV0LmluZXQudGNwLnJlY3ZidWZfYXV0 bzogMQpuZXQuaW5ldC50Y3AuaW5zZWN1cmVfcnN0OiAwCm5ldC5pbmV0LnRjcC5yZmMzMzkw OiAxCm5ldC5pbmV0LnRjcC5yZmMzMDQyOiAxCm5ldC5pbmV0LnRjcC5kcm9wX3N5bmZpbjog MApuZXQuaW5ldC50Y3AuZGVsYXllZF9hY2s6IDEKbmV0LmluZXQudGNwLmJsYWNraG9sZTog MApuZXQuaW5ldC50Y3AubG9nX2luX3ZhaW46IDAKbmV0LmluZXQudGNwLnNlbmRidWZfbWF4 OiAyNjIxNDQKbmV0LmluZXQudGNwLnNlbmRidWZfaW5jOiA4MTkyCm5ldC5pbmV0LnRjcC5z ZW5kYnVmX2F1dG86IDEKbmV0LmluZXQudGNwLnRzbzogMQpuZXQuaW5ldC50Y3AubmV3cmVu bzogMQpuZXQuaW5ldC50Y3AubG9jYWxfc2xvd3N0YXJ0X2ZsaWdodHNpemU6IDQKbmV0Lmlu ZXQudGNwLnNsb3dzdGFydF9mbGlnaHRzaXplOiAxCm5ldC5pbmV0LnRjcC5wYXRoX210dV9k aXNjb3Zlcnk6IDEKbmV0LmluZXQudGNwLnJlYXNzLm92ZXJmbG93czogMApuZXQuaW5ldC50 Y3AucmVhc3MubWF4cWxlbjogNDgKbmV0LmluZXQudGNwLnJlYXNzLmN1cnNlZ21lbnRzOiAw Cm5ldC5pbmV0LnRjcC5yZWFzcy5tYXhzZWdtZW50czogMTYwMApuZXQuaW5ldC50Y3Auc2Fj ay5nbG9iYWxob2xlczogMApuZXQuaW5ldC50Y3Auc2Fjay5nbG9iYWxtYXhob2xlczogNjU1 MzYKbmV0LmluZXQudGNwLnNhY2subWF4aG9sZXM6IDEyOApuZXQuaW5ldC50Y3Auc2Fjay5l bmFibGU6IDEKbmV0LmluZXQudGNwLmluZmxpZ2h0LnN0YWI6IDIwCm5ldC5pbmV0LnRjcC5p bmZsaWdodC5tYXg6IDEwNzM3MjU0NDAKbmV0LmluZXQudGNwLmluZmxpZ2h0Lm1pbjogNjE0 NApuZXQuaW5ldC50Y3AuaW5mbGlnaHQucnR0dGhyZXNoOiAxMApuZXQuaW5ldC50Y3AuaW5m bGlnaHQuZGVidWc6IDAKbmV0LmluZXQudGNwLmluZmxpZ2h0LmVuYWJsZTogMQpuZXQuaW5l dC50Y3AuaXNuX3Jlc2VlZF9pbnRlcnZhbDogMApuZXQuaW5ldC50Y3AuaWNtcF9tYXlfcnN0 OiAxCm5ldC5pbmV0LnRjcC5wY2Jjb3VudDogMwpuZXQuaW5ldC50Y3AuZG9fdGNwZHJhaW46 IDEKbmV0LmluZXQudGNwLnRjYmhhc2hzaXplOiA1MTIKbmV0LmluZXQudGNwLmxvZ19kZWJ1 ZzogMApuZXQuaW5ldC50Y3AubWlubXNzOiAyMTYKbmV0LmluZXQudGNwLnN5bmNhY2hlLnJz dF9vbl9zb2NrX2ZhaWw6IDEKbmV0LmluZXQudGNwLnN5bmNhY2hlLnJleG10bGltaXQ6IDMK bmV0LmluZXQudGNwLnN5bmNhY2hlLmhhc2hzaXplOiA1MTIKbmV0LmluZXQudGNwLnN5bmNh Y2hlLmNvdW50OiAwCm5ldC5pbmV0LnRjcC5zeW5jYWNoZS5jYWNoZWxpbWl0OiAxNTM2MApu ZXQuaW5ldC50Y3Auc3luY2FjaGUuYnVja2V0bGltaXQ6IDMwCm5ldC5pbmV0LnRjcC5zeW5j b29raWVzX29ubHk6IDAKbmV0LmluZXQudGNwLnN5bmNvb2tpZXM6IDEKbmV0LmluZXQudGNw LnRpbWVyX3JhY2U6IDAKbmV0LmluZXQudGNwLmZpbndhaXQyX3RpbWVvdXQ6IDYwMDAwCm5l dC5pbmV0LnRjcC5mYXN0X2ZpbndhaXQyX3JlY3ljbGU6IDAKbmV0LmluZXQudGNwLmFsd2F5 c19rZWVwYWxpdmU6IDEKbmV0LmluZXQudGNwLnJleG1pdF9zbG9wOiAyMDAKbmV0LmluZXQu dGNwLnJleG1pdF9taW46IDMwCm5ldC5pbmV0LnRjcC5tc2w6IDMwMDAwCm5ldC5pbmV0LnRj cC5ub2xvY2FsdGltZXdhaXQ6IDAKbmV0LmluZXQudGNwLm1heHRjcHR3OiA1MTIwCm5ldC5p bmV0LnVkcC5jaGVja3N1bTogMQpuZXQuaW5ldC51ZHAubWF4ZGdyYW06IDkyMTYKbmV0Lmlu ZXQudWRwLnJlY3ZzcGFjZTogNDIwODAKbmV0LmluZXQudWRwLnNvcmVjZWl2ZV9kZ3JhbV9l bmFibGVkOiAxCm5ldC5pbmV0LnVkcC5ibGFja2hvbGU6IDAKbmV0LmluZXQudWRwLmxvZ19p bl92YWluOiAwCm5ldC5pbmV0LnNjdHAubmF0X2ZyaWVuZGx5X2luaXQ6IDEKbmV0LmluZXQu c2N0cC5lbmFibGVfc2Fja19pbW1lZGlhdGVseTogMApuZXQuaW5ldC5zY3RwLnVkcF90dW5u ZWxpbmdfcG9ydDogMApuZXQuaW5ldC5zY3RwLnVkcF90dW5uZWxpbmdfZm9yX2NsaWVudF9l bmFibGU6IDAKbmV0LmluZXQuc2N0cC5tb2JpbGl0eV9mYXN0aGFuZG9mZjogMApuZXQuaW5l dC5zY3RwLm1vYmlsaXR5X2Jhc2U6IDAKbmV0LmluZXQuc2N0cC5kZWZhdWx0X2ZyYWdfaW50 ZXJsZWF2ZTogMQpuZXQuaW5ldC5zY3RwLmRlZmF1bHRfY2NfbW9kdWxlOiAwCm5ldC5pbmV0 LnNjdHAubG9nX2xldmVsOiAwCm5ldC5pbmV0LnNjdHAubWF4X3JldHJhbl9jaHVuazogMzAK bmV0LmluZXQuc2N0cC5taW5fcmVzaWR1YWw6IDE0NTIKbmV0LmluZXQuc2N0cC5zdHJpY3Rf ZGF0YV9vcmRlcjogMApuZXQuaW5ldC5zY3RwLmFib3J0X2F0X2xpbWl0OiAwCm5ldC5pbmV0 LnNjdHAuaGJfbWF4X2J1cnN0OiA0Cm5ldC5pbmV0LnNjdHAuZG9fc2N0cF9kcmFpbjogMQpu ZXQuaW5ldC5zY3RwLm1heF9jaGFpbmVkX21idWZzOiA1Cm5ldC5pbmV0LnNjdHAuYWJjX2xf dmFyOiAxCm5ldC5pbmV0LnNjdHAubmF0X2ZyaWVuZGx5OiAxCm5ldC5pbmV0LnNjdHAuYXV0 aF9kaXNhYmxlOiAwCm5ldC5pbmV0LnNjdHAuYXNjb25mX2F1dGhfbm9jaGs6IDAKbmV0Lmlu ZXQuc2N0cC5lYXJseV9mYXN0X3JldHJhbl9tc2VjOiAyNTAKbmV0LmluZXQuc2N0cC5lYXJs eV9mYXN0X3JldHJhbjogMApuZXQuaW5ldC5zY3RwLmN3bmRfbWF4YnVyc3Q6IDEKbmV0Lmlu ZXQuc2N0cC5jbXRfcGY6IDAKbmV0LmluZXQuc2N0cC5jbXRfdXNlX2RhYzogMApuZXQuaW5l dC5zY3RwLm5yX3NhY2tfb25fb2ZmOiAwCm5ldC5pbmV0LnNjdHAuY210X29uX29mZjogMApu ZXQuaW5ldC5zY3RwLm91dGdvaW5nX3N0cmVhbXM6IDEwCm5ldC5pbmV0LnNjdHAuYWRkX21v cmVfb25fb3V0cHV0OiAxNDUyCm5ldC5pbmV0LnNjdHAucGF0aF9ydHhfbWF4OiA1Cm5ldC5p bmV0LnNjdHAuYXNzb2NfcnR4X21heDogMTAKbmV0LmluZXQuc2N0cC5pbml0X3J0eF9tYXg6 IDgKbmV0LmluZXQuc2N0cC52YWxpZF9jb29raWVfbGlmZTogNjAwMDAKbmV0LmluZXQuc2N0 cC5pbml0X3J0b19tYXg6IDYwMDAwCm5ldC5pbmV0LnNjdHAucnRvX2luaXRpYWw6IDMwMDAK bmV0LmluZXQuc2N0cC5ydG9fbWluOiAxMDAwCm5ldC5pbmV0LnNjdHAucnRvX21heDogNjAw MDAKbmV0LmluZXQuc2N0cC5zZWNyZXRfbGlmZXRpbWU6IDM2MDAKbmV0LmluZXQuc2N0cC5z aHV0ZG93bl9ndWFyZF90aW1lOiAxODAKbmV0LmluZXQuc2N0cC5wbXR1X3JhaXNlX3RpbWU6 IDYwMApuZXQuaW5ldC5zY3RwLmhlYXJ0YmVhdF9pbnRlcnZhbDogMzAwMDAKbmV0LmluZXQu c2N0cC5hc29jX3Jlc291cmNlOiAxMApuZXQuaW5ldC5zY3RwLnN5c19yZXNvdXJjZTogMTAw MApuZXQuaW5ldC5zY3RwLnNhY2tfZnJlcTogMgpuZXQuaW5ldC5zY3RwLmRlbGF5ZWRfc2Fj a190aW1lOiAyMDAKbmV0LmluZXQuc2N0cC5jaHVua3NjYWxlOiAxMApuZXQuaW5ldC5zY3Rw Lm1pbl9zcGxpdF9wb2ludDogMjkwNApuZXQuaW5ldC5zY3RwLnBjYmhhc2hzaXplOiAyNTYK bmV0LmluZXQuc2N0cC50Y2JoYXNoc2l6ZTogMTAyNApuZXQuaW5ldC5zY3RwLm1heGNodW5r czogMzIwMApuZXQuaW5ldC5zY3RwLm1heGJ1cnN0OiA0Cm5ldC5pbmV0LnNjdHAucGVlcl9j aGtvaDogMjU2Cm5ldC5pbmV0LnNjdHAuc3RyaWN0X2luaXQ6IDEKbmV0LmluZXQuc2N0cC5s b29wYmFja19ub2NzdW06IDEKbmV0LmluZXQuc2N0cC5zdHJpY3Rfc2Fja3M6IDEKbmV0Lmlu ZXQuc2N0cC5lY25fbm9uY2U6IDAKbmV0LmluZXQuc2N0cC5lY25fZW5hYmxlOiAxCm5ldC5p bmV0LnNjdHAuYXV0b19hc2NvbmY6IDEKbmV0LmluZXQuc2N0cC5yZWN2c3BhY2U6IDIzMzAx NgpuZXQuaW5ldC5zY3RwLnNlbmRzcGFjZTogMjMzMDE2Cm5ldC5pbmV0LnJhdy5yZWN2c3Bh Y2U6IDkyMTYKbmV0LmluZXQucmF3Lm1heGRncmFtOiA5MjE2Cm5ldC5pbmV0LmFjY2YudW5s b2FkYWJsZTogMApuZXQubGluay5nZW5lcmljLnN5c3RlbS5pZmNvdW50OiA3Cm5ldC5saW5r LmV0aGVyLmluZXQubG9nX2FycF9wZXJtYW5lbnRfbW9kaWZ5OiAxCm5ldC5saW5rLmV0aGVy LmluZXQubG9nX2FycF9tb3ZlbWVudHM6IDEKbmV0LmxpbmsuZXRoZXIuaW5ldC5sb2dfYXJw X3dyb25nX2lmYWNlOiAxCm5ldC5saW5rLmV0aGVyLmluZXQucHJveHlhbGw6IDAKbmV0Lmxp bmsuZXRoZXIuaW5ldC51c2Vsb29wYmFjazogMQpuZXQubGluay5ldGhlci5pbmV0Lm1heHRy aWVzOiA1Cm5ldC5saW5rLmV0aGVyLmluZXQubWF4X2FnZTogMTIwMApuZXQubGluay5ldGhl ci5pcGZ3OiAwCm5ldC5saW5rLmdpZi5wYXJhbGxlbF90dW5uZWxzOiAwCm5ldC5saW5rLmdp Zi5tYXhfbmVzdGluZzogMQpuZXQubGluay5sb2dfbGlua19zdGF0ZV9jaGFuZ2U6IDEKbmV0 LmxpbmsudHVuLmRldmZzX2Nsb25pbmc6IDEKbmV0LmluZXQ2LmlwNi5mb3J3YXJkaW5nOiAw Cm5ldC5pbmV0Ni5pcDYucmVkaXJlY3Q6IDEKbmV0LmluZXQ2LmlwNi5obGltOiA2NApuZXQu aW5ldDYuaXA2Lm1heGZyYWdwYWNrZXRzOiA2NDAwCm5ldC5pbmV0Ni5pcDYuYWNjZXB0X3J0 YWR2OiAxCm5ldC5pbmV0Ni5pcDYua2VlcGZhaXRoOiAwCm5ldC5pbmV0Ni5pcDYubG9nX2lu dGVydmFsOiA1Cm5ldC5pbmV0Ni5pcDYuaGRybmVzdGxpbWl0OiAxNQpuZXQuaW5ldDYuaXA2 LmRhZF9jb3VudDogMQpuZXQuaW5ldDYuaXA2LmF1dG9fZmxvd2xhYmVsOiAxCm5ldC5pbmV0 Ni5pcDYuZGVmbWNhc3RobGltOiAxCm5ldC5pbmV0Ni5pcDYuZ2lmaGxpbTogMzAKbmV0Lmlu ZXQ2LmlwNi5rYW1lX3ZlcnNpb246IEZyZWVCU0QKbmV0LmluZXQ2LmlwNi51c2VfZGVwcmVj YXRlZDogMQpuZXQuaW5ldDYuaXA2LnJyX3BydW5lOiA1Cm5ldC5pbmV0Ni5pcDYudjZvbmx5 OiAxCm5ldC5pbmV0Ni5pcDYucnRleHBpcmU6IDM2MDAKbmV0LmluZXQ2LmlwNi5ydG1pbmV4 cGlyZTogMTAKbmV0LmluZXQ2LmlwNi5ydG1heGNhY2hlOiAxMjgKbmV0LmluZXQ2LmlwNi51 c2VfdGVtcGFkZHI6IDAKbmV0LmluZXQ2LmlwNi50ZW1wcGx0aW1lOiA4NjQwMApuZXQuaW5l dDYuaXA2LnRlbXB2bHRpbWU6IDYwNDgwMApuZXQuaW5ldDYuaXA2LmF1dG9fbGlua2xvY2Fs OiAxCm5ldC5pbmV0Ni5pcDYucHJlZmVyX3RlbXBhZGRyOiAwCm5ldC5pbmV0Ni5pcDYudXNl X2RlZmF1bHR6b25lOiAwCm5ldC5pbmV0Ni5pcDYubWF4ZnJhZ3M6IDY0MDAKbmV0LmluZXQ2 LmlwNi5tY2FzdF9wbXR1OiAwCm5ldC5pbmV0Ni5pY21wNi5yZWRpcmFjY2VwdDogMQpuZXQu aW5ldDYuaWNtcDYucmVkaXJ0aW1lb3V0OiA2MDAKbmV0LmluZXQ2LmljbXA2Lm5kNl9wcnVu ZTogMQpuZXQuaW5ldDYuaWNtcDYubmQ2X2RlbGF5OiA1Cm5ldC5pbmV0Ni5pY21wNi5uZDZf dW1heHRyaWVzOiAzCm5ldC5pbmV0Ni5pY21wNi5uZDZfbW1heHRyaWVzOiAzCm5ldC5pbmV0 Ni5pY21wNi5uZDZfdXNlbG9vcGJhY2s6IDEKbmV0LmluZXQ2LmljbXA2Lm5vZGVpbmZvOiAz Cm5ldC5pbmV0Ni5pY21wNi5lcnJwcHNsaW1pdDogMTAwCm5ldC5pbmV0Ni5pY21wNi5uZDZf bWF4bnVkaGludDogMApuZXQuaW5ldDYuaWNtcDYubmQ2X2RlYnVnOiAwCm5ldC5pbmV0Ni5p Y21wNi5uZDZfbWF4cXVldWVsZW46IDEKbmV0LmluZXQ2LmljbXA2Lm5kNl9vbmxpbmtfbnNf cmZjNDg2MTogMApuZXQuYnBmLm1heGluc25zOiA1MTIKbmV0LmJwZi5tYXhidWZzaXplOiA1 MjQyODgKbmV0LmJwZi5idWZzaXplOiA0MDk2Cm5ldC5pc3Iuc3dpX2NvdW50OiA0MjAKbmV0 Lmlzci5kcm9wOiAwCm5ldC5pc3IucXVldWVkOiA0MjMKbmV0Lmlzci5kZWZlcnJlZDogMApu ZXQuaXNyLmRpcmVjdGVkOiAwCm5ldC5pc3IuY291bnQ6IDAKbmV0Lmlzci5kaXJlY3Q6IDEK bmV0LnJhdy5yZWN2c3BhY2U6IDgxOTIKbmV0LnJhdy5zZW5kc3BhY2U6IDgxOTIKbmV0Lm15 X2ZpYm51bTogMApuZXQuYWRkX2FkZHJfYWxsZmliczogMQpuZXQuZmliczogMQpuZXQucm91 dGUubmV0aXNyX21heHFsZW46IDI1NgpuZXQud2xhbi5yZWN2X2JhcjogMQpuZXQud2xhbi5k ZWJ1ZzogMApuZXQud2xhbi4wLiVwYXJlbnQ6IGF0aDAKbmV0LndsYW4uMC5kZWJ1ZzogMApu ZXQud2xhbi4wLmluYWN0X3J1bjogMzAwCm5ldC53bGFuLjAuaW5hY3RfcHJvYmU6IDMwCm5l dC53bGFuLjAuaW5hY3RfYXV0aDogMTgwCm5ldC53bGFuLjAuaW5hY3RfaW5pdDogMzAKbmV0 LndsYW4uMC5kcml2ZXJfY2FwczogMTczNjY5OTE1MQpuZXQud2xhbi4wLmJtaXNzX21heDog MgpkZWJ1Zy5wZnVnaWRoYWNrOiAwCmRlYnVnLmZpcmV3aXJlX2RlYnVnOiAwCmRlYnVnLmZ3 bWVtX2RlYnVnOiAwCmRlYnVnLmlmX2Z3ZV9kZWJ1ZzogMApkZWJ1Zy5pZl9md2lwX2RlYnVn OiAwCmRlYnVnLnNicF9kZWJ1ZzogMApkZWJ1Zy5tZGRlYnVnOiAwCmRlYnVnLmVsZjMyX2xl Z2FjeV9jb3JlZHVtcDogMApkZWJ1Zy5lbGYzMl90cmFjZTogMApkZWJ1Zy5ib290dmVyYm9z ZTogMApkZWJ1Zy5ib290aG93dG86IC0yMTQ3NDgzNjQ4CmRlYnVnLmNwdWZyZXEudmVyYm9z ZTogMApkZWJ1Zy5jcHVmcmVxLmxvd2VzdDogMApkZWJ1Zy5zaXplb2YuY2Rldl9wcml2OiAy MzYKZGVidWcuc2l6ZW9mLmNkZXY6IDE4NApkZWJ1Zy5zaXplb2YuZ19iaW9xOiAzNgpkZWJ1 Zy5zaXplb2YuZ19jb25zdW1lcjogNjAKZGVidWcuc2l6ZW9mLmdfcHJvdmlkZXI6IDg4CmRl YnVnLnNpemVvZi5nX2dlb206IDY4CmRlYnVnLnNpemVvZi5nX2NsYXNzOiA2OApkZWJ1Zy5z aXplb2Yua2luZm9fcHJvYzogNzY4CmRlYnVnLnNpemVvZi5idWY6IDM1NgpkZWJ1Zy5zaXpl b2YuYmlvOiAxMzIKZGVidWcuc2l6ZW9mLnByb2M6IDY5NgpkZWJ1Zy5zaXplb2Yudm5vZGU6 IDI3NgpkZWJ1Zy5zaXplb2YuZGV2c3RhdDogMjQwCmRlYnVnLnNpemVvZi5uYW1lY2FjaGU6 IDM2CmRlYnVnLnRvX2F2Z19tcGNhbGxzOiAxNTEwCmRlYnVnLnRvX2F2Z19tdHhjYWxsczog MApkZWJ1Zy50b19hdmdfZ2NhbGxzOiA3NzgKZGVidWcudG9fYXZnX2RlcHRoOiAyNTQ4CmRl YnVnLnVtdHgudW10eF9waV9hbGxvY2F0ZWQ6IDAKZGVidWcua2RiLnN0b3BfY3B1czogMQpk ZWJ1Zy5rZGIudHJhcF9jb2RlOiAwCmRlYnVnLmtkYi50cmFwOiAwCmRlYnVnLmtkYi5wYW5p YzogMApkZWJ1Zy5rZGIuZW50ZXI6IDAKZGVidWcua2RiLmN1cnJlbnQ6IApkZWJ1Zy5rZGIu YXZhaWxhYmxlOiAKZGVidWcucm1hbl9kZWJ1ZzogMApkZWJ1Zy50dHlkZWJ1ZzogMApkZWJ1 Zy5kaXNhYmxlZnVsbHBhdGg6IDAKZGVidWcuZGlzYWJsZWN3ZDogMApkZWJ1Zy52ZnNjYWNo ZTogMQpkZWJ1Zy5udW1jYWNoZWh2OiAxNDE5NQpkZWJ1Zy5udW1jYWNoZTogNjE1NjYKZGVi dWcubnVtbmVnOiAzODQ3CmRlYnVnLm5jbmVnZmFjdG9yOiAxNgpkZWJ1Zy5uY2hhc2g6IDEz MTA3MQpkZWJ1Zy52bmxydV9ub3doZXJlOiAwCmRlYnVnLnJ1c2hfcmVxdWVzdHM6IDAKZGVi dWcubXBzYWZldmZzOiAxCmRlYnVnLmlmX3R1bl9kZWJ1ZzogMApkZWJ1Zy5ubG1fZGVidWc6 IDAKZGVidWcuY29sbGVjdHNuYXBzdGF0czogMApkZWJ1Zy5zbmFwZGVidWc6IDAKZGVidWcu ZG9wZXJzaXN0ZW5jZTogMApkZWJ1Zy5kaXJfZW50cnk6IDMzCmRlYnVnLmRpcmVjdF9ibGtf cHRyczogOApkZWJ1Zy5pbm9kZV9iaXRtYXA6IDI4CmRlYnVnLmluZGlyX2Jsa19wdHJzOiAx NQpkZWJ1Zy5zeW5jX2xpbWl0X2hpdDogMApkZWJ1Zy5pbm9fbGltaXRfaGl0OiAwCmRlYnVn LmJsa19saW1pdF9oaXQ6IDAKZGVidWcuaW5vX2xpbWl0X3B1c2g6IDAKZGVidWcuYmxrX2xp bWl0X3B1c2g6IDAKZGVidWcud29ya2xpc3RfcHVzaDogMApkZWJ1Zy5tYXhpbmRpcmRlcHM6 IDUwCmRlYnVnLnRpY2tkZWxheTogMgpkZWJ1Zy5tYXhfc29mdGRlcHM6IDI3MDI3NgpkZWJ1 Zy5kb2JrZ3Jkd3JpdGU6IDEKZGVidWcuYmlnY2dzOiAwCmRlYnVnLmRpcmNoZWNrOiAwCmRl YnVnLnBzbS5wa3RlcnJ0aHJlc2g6IDIKZGVidWcucHNtLnVzZWNzOiA1MDAwMDAKZGVidWcu cHNtLnNlY3M6IDAKZGVidWcucHNtLmVycnVzZWNzOiAwCmRlYnVnLnBzbS5lcnJzZWNzOiAy CmRlYnVnLnBzbS5oejogMjAKZGVidWcucHNtLmxvZ2xldmVsOiAwCmRlYnVnLm1pbmlkdW1w OiAxCmRlYnVnLnN0b3BfY3B1c193aXRoX25taTogMQpkZWJ1Zy5QTUFQMXVuY2hhbmdlZDog NzQzMzkyOQpkZWJ1Zy5QTUFQMWNoYW5nZWQ6IDU2MTk1CmRlYnVnLlBNQVAxY2hhbmdlZGNw dTogNTAKZGVidWcuYWNwaS5zdXNwZW5kX2JvdW5jZTogMApkZWJ1Zy5hY3BpLmRvX3Bvd2Vy c3RhdGU6IDEKZGVidWcuYWNwaS5hY3BpX2NhX3ZlcnNpb246IDIwMDcwMzIwCmRlYnVnLmFj cGkuZWMudGltZW91dDogNzUwCmRlYnVnLmFjcGkuZWMucG9sbGVkOiAwCmRlYnVnLmFjcGku ZWMuYnVyc3Q6IDAKZGVidWcuYWNwaS5iYXR0LmJhdHRfc2xlZXBfbXM6IDAKZGVidWcuYWNw aS5zZW1hcGhvcmVfZGVidWc6IDAKZGVidWcuYWNwaS5yZXN1bWVfYmVlcDogMApody5tYWNo aW5lOiBpMzg2Cmh3Lm1vZGVsOiBJbnRlbChSKSBDb3JlKFRNKTIgRHVvIENQVSAgICAgVDU2 NzAgIEAgMS44MEdIegpody5uY3B1OiAyCmh3LmJ5dGVvcmRlcjogMTIzNApody5waHlzbWVt OiAxMDI0NjIyNTkyCmh3LnVzZXJtZW06IDc1NzIxOTMyOApody5wYWdlc2l6ZTogNDA5Ngpo dy5mbG9hdGluZ3BvaW50OiAxCmh3Lm1hY2hpbmVfYXJjaDogaTM4Ngpody5yZWFsbWVtOiAx MDM3NzYyNTYwCmh3LmFhYy5pb3NpemVfbWF4OiA2NTUzNgpody5hbXIuZm9yY2Vfc2czMjog MApody5hbi5hbl9jYWNoZV9pcG9ubHk6IDEKaHcuYW4uYW5fY2FjaGVfbWNhc3Rvbmx5OiAw Cmh3LmFuLmFuX2NhY2hlX21vZGU6IGRibQpody5hbi5hbl9kdW1wOiBvZmYKaHcuYXRhLndj OiAxCmh3LmF0YS5hdGFwaV9kbWE6IDEKaHcuYXRhLmF0YV9kbWFfY2hlY2tfODBwaW46IDEK aHcuYXRhLmF0YV9kbWE6IDEKaHcuYXRoLnR4YnVmOiAyMDAKaHcuYXRoLnJ4YnVmOiA0MApo dy5hdGgucmVnZG9tYWluOiAwCmh3LmF0aC5jb3VudHJ5Y29kZTogMApody5hdGgueGNoYW5t b2RlOiAxCmh3LmF0aC5vdXRkb29yOiAxCmh3LmF0aC5jYWxpYnJhdGU6IDMwCmh3LmF0aC5o YWwuc3diYV9iYWNrb2ZmOiAwCmh3LmF0aC5oYWwuc3dfYnJ0OiAxMApody5hdGguaGFsLmRt YV9icnQ6IDIKaHcuYmNlLm1zaV9lbmFibGU6IDEKaHcuYmNlLnRzb19lbmFibGU6IDEKaHcu YmdlLmFsbG93X2FzZjogMApody5jYXJkYnVzLmNpc19kZWJ1ZzogMApody5jYXJkYnVzLmRl YnVnOiAwCmh3LmNzLnJlY3ZfZGVsYXk6IDU3MApody5jcy5pZ25vcmVfY2hlY2tzdW1fZmFp bHVyZTogMApody5jcy5kZWJ1ZzogMApody5maXJld2lyZS5ob2xkX2NvdW50OiAzCmh3LmZp cmV3aXJlLnRyeV9ibXI6IDEKaHcuZmlyZXdpcmUuZndtZW0uc3BlZWQ6IDIKaHcuZmlyZXdp cmUuZndtZW0uZXVpNjRfbG86IDAKaHcuZmlyZXdpcmUuZndtZW0uZXVpNjRfaGk6IDAKaHcu ZmlyZXdpcmUucGh5ZG1hX2VuYWJsZTogMQpody5maXJld2lyZS5ub2N5Y2xlbWFzdGVyOiAw Cmh3LmZpcmV3aXJlLmZ3ZS5yeF9xdWV1ZV9sZW46IDEyOApody5maXJld2lyZS5md2UudHhf c3BlZWQ6IDIKaHcuZmlyZXdpcmUuZndlLnN0cmVhbV9jaDogMQpody5maXJld2lyZS5md2lw LnJ4X3F1ZXVlX2xlbjogMTI4Cmh3LmZpcmV3aXJlLnNicC50YWdzOiAwCmh3LmZpcmV3aXJl LnNicC51c2VfZG9vcmJlbGw6IDAKaHcuZmlyZXdpcmUuc2JwLnNjYW5fZGVsYXk6IDUwMApo dy5maXJld2lyZS5zYnAubG9naW5fZGVsYXk6IDEwMDAKaHcuZmlyZXdpcmUuc2JwLmV4Y2x1 c2l2ZV9sb2dpbjogMQpody5maXJld2lyZS5zYnAubWF4X3NwZWVkOiAyCmh3LmZpcmV3aXJl LnNicC5hdXRvX2xvZ2luOiAxCmh3Lm1maS5tYXhfY21kczogMTI4Cmh3Lm1maS5ldmVudF9j bGFzczogMApody5tZmkuZXZlbnRfbG9jYWxlOiA2NTUzNQpody5wY2NhcmQuY2lzX2RlYnVn OiAwCmh3LnBjY2FyZC5kZWJ1ZzogMApody5jYmIuZGVidWc6IDAKaHcuY2JiLnN0YXJ0XzMy X2lvOiA0MDk2Cmh3LmNiYi5zdGFydF8xNl9pbzogMjU2Cmh3LmNiYi5zdGFydF9tZW1vcnk6 IDIyODE3MDEzNzYKaHcucGNpYy5wZDY3MjJfdnNlbnNlOiAxCmh3LnBjaWMuaW50cl9tYXNr OiA1NzAxNgpody5wY2kuaG9ub3JfbXNpX2JsYWNrbGlzdDogMQpody5wY2kuZW5hYmxlX21z aXg6IDEKaHcucGNpLmVuYWJsZV9tc2k6IDEKaHcucGNpLmRvX3Bvd2VyX3Jlc3VtZTogMQpo dy5wY2kuZG9fcG93ZXJfbm9kcml2ZXI6IDAKaHcucGNpLmVuYWJsZV9pb19tb2RlczogMQpo dy5wY2kuaG9zdF9tZW1fc3RhcnQ6IDIxNDc0ODM2NDgKaHcucGNpLmlycV9vdmVycmlkZV9t YXNrOiA1NzA4MApody5zeXNjb25zLmtiZF9kZWJ1ZzogMQpody5zeXNjb25zLmtiZF9yZWJv b3Q6IDEKaHcuc3lzY29ucy5iZWxsOiAxCmh3LnN5c2NvbnMuc2F2ZXIua2V5Ym9ubHk6IDEK aHcuc3lzY29ucy5zY19ub19zdXNwZW5kX3Z0c3dpdGNoOiAwCmh3LnVzYi51cGxjb20uaW50 ZXJ2YWw6IDEwMApody51c2IudXZzY29tLmludGVydmFsOiAxMDAKaHcudXNiLnV2c2NvbS5v cGt0c2l6ZTogOApody53aS5kZWJ1ZzogMApody53aS50eGVyYXRlOiAwCmh3LnhlLmRlYnVn OiAwCmh3LmludHJfc3Rvcm1fdGhyZXNob2xkOiAxMDAwCmh3LmF2YWlscGFnZXM6IDI1MDE1 Mgpody5idXMuZGV2Y3RsX2Rpc2FibGU6IDAKaHcuc3RlLnJ4c3luY3M6IDAKaHcucHNtLnRh cF90aW1lb3V0OiAxMjUwMDAKaHcucHNtLnRhcF90aHJlc2hvbGQ6IDI1Cmh3LmtiZC5rZXlt YXBfcmVzdHJpY3RfY2hhbmdlOiAwCmh3LmJ1c2RtYS50b3RhbF9icGFnZXM6IDgyMApody5i dXNkbWEuem9uZTAudG90YWxfYnBhZ2VzOiAzMDMKaHcuYnVzZG1hLnpvbmUwLmZyZWVfYnBh Z2VzOiAzMDMKaHcuYnVzZG1hLnpvbmUwLnJlc2VydmVkX2JwYWdlczogMApody5idXNkbWEu em9uZTAuYWN0aXZlX2JwYWdlczogMApody5idXNkbWEuem9uZTAudG90YWxfYm91bmNlZDog MApody5idXNkbWEuem9uZTAudG90YWxfZGVmZXJyZWQ6IDAKaHcuYnVzZG1hLnpvbmUwLmxv d2FkZHI6IDB4ZmZmZmZmZmYKaHcuYnVzZG1hLnpvbmUwLmFsaWdubWVudDogNDA5Ngpody5i dXNkbWEuem9uZTAuYm91bmRhcnk6IDAKaHcuYnVzZG1hLnpvbmUxLnRvdGFsX2JwYWdlczog NTE3Cmh3LmJ1c2RtYS56b25lMS5mcmVlX2JwYWdlczogNTE3Cmh3LmJ1c2RtYS56b25lMS5y ZXNlcnZlZF9icGFnZXM6IDAKaHcuYnVzZG1hLnpvbmUxLmFjdGl2ZV9icGFnZXM6IDAKaHcu YnVzZG1hLnpvbmUxLnRvdGFsX2JvdW5jZWQ6IDAKaHcuYnVzZG1hLnpvbmUxLnRvdGFsX2Rl ZmVycmVkOiAwCmh3LmJ1c2RtYS56b25lMS5sb3dhZGRyOiAweGZmZmZmZmZmCmh3LmJ1c2Rt YS56b25lMS5hbGlnbm1lbnQ6IDIKaHcuYnVzZG1hLnpvbmUxLmJvdW5kYXJ5OiA2NTUzNgpo dy5jbG9ja3JhdGU6IDYwMApody52aWFfZmVhdHVyZV94Y3J5cHQ6IDAKaHcudmlhX2ZlYXR1 cmVfcm5nOiAwCmh3Lmluc3RydWN0aW9uX3NzZTogMQpody5hcGljLmVuYWJsZV9leHRpbnQ6 IDAKaHcuc25kLmxhdGVuY3lfcHJvZmlsZTogMQpody5zbmQubGF0ZW5jeTogNQpody5zbmQu cmVwb3J0X3NvZnRfZm9ybWF0czogMQpody5zbmQuY29tcGF0X2xpbnV4X21tYXA6IDAKaHcu c25kLmZlZWRlcl9idWZmZXJzaXplOiAxNjM4NApody5zbmQuZmVlZGVyX3JhdGVfcm91bmQ6 IDI1Cmh3LnNuZC5mZWVkZXJfcmF0ZV9tYXg6IDIwMTYwMDAKaHcuc25kLmZlZWRlcl9yYXRl X21pbjogMQpody5zbmQudmVyYm9zZTogMQpody5zbmQubWF4YXV0b3ZjaGFuczogMTYKaHcu c25kLmRlZmF1bHRfdW5pdDogMApody5zbmQudmVyc2lvbjogMjAwNzA2MTYwMC9pMzg2Cmh3 LnNuZC5kZWZhdWx0X2F1dG86IDAKaHcubWlkaS5pbnN0cm9mZjogMApody5taWRpLmR1bXBy YXc6IDAKaHcubWlkaS5kZWJ1ZzogMApody5taWRpLnN0YXQudmVyYm9zZTogMApody5taWRp LnNlcS5kZWJ1ZzogMApody5hY3BpLnN1cHBvcnRlZF9zbGVlcF9zdGF0ZTogUzEgUzMgUzQg UzUKaHcuYWNwaS5wb3dlcl9idXR0b25fc3RhdGU6IFM1Cmh3LmFjcGkuc2xlZXBfYnV0dG9u X3N0YXRlOiBTMQpody5hY3BpLmxpZF9zd2l0Y2hfc3RhdGU6IE5PTkUKaHcuYWNwaS5zdGFu ZGJ5X3N0YXRlOiBTMQpody5hY3BpLnN1c3BlbmRfc3RhdGU6IFMzCmh3LmFjcGkuc2xlZXBf ZGVsYXk6IDEKaHcuYWNwaS5zNGJpb3M6IDAKaHcuYWNwaS52ZXJib3NlOiAwCmh3LmFjcGku ZGlzYWJsZV9vbl9yZWJvb3Q6IDAKaHcuYWNwaS5oYW5kbGVfcmVib290OiAwCmh3LmFjcGku cmVzZXRfdmlkZW86IDAKaHcuYWNwaS52aWRlby5leHQwLmFjdGl2ZTogMApody5hY3BpLnZp ZGVvLmNydDAuYWN0aXZlOiAwCmh3LmFjcGkudmlkZW8ubGNkMC5hY3RpdmU6IDAKaHcuYWNw aS52aWRlby5sY2QwLmJyaWdodG5lc3M6IDYwCmh3LmFjcGkudmlkZW8ubGNkMC5mdWxscG93 ZXI6IDEwMApody5hY3BpLnZpZGVvLmxjZDAuZWNvbm9teTogOTAKaHcuYWNwaS52aWRlby5s Y2QwLmxldmVsczogMTAwIDkwIDg1IDgwIDc1IDcwIDY1IDYwIDU1IDUwIDQ1IDQwIDM1IDMw IDI1IDIwCmh3LmFjcGkudGhlcm1hbC5taW5fcnVudGltZTogMApody5hY3BpLnRoZXJtYWwu cG9sbGluZ19yYXRlOiAxMApody5hY3BpLnRoZXJtYWwudXNlcl9vdmVycmlkZTogMApody5h Y3BpLnRoZXJtYWwudHowLnRlbXBlcmF0dXJlOiA0Mi4wQwpody5hY3BpLnRoZXJtYWwudHow LmFjdGl2ZTogLTEKaHcuYWNwaS50aGVybWFsLnR6MC5wYXNzaXZlX2Nvb2xpbmc6IDEKaHcu YWNwaS50aGVybWFsLnR6MC50aGVybWFsX2ZsYWdzOiAwCmh3LmFjcGkudGhlcm1hbC50ejAu X1BTVjogMTA1LjBDCmh3LmFjcGkudGhlcm1hbC50ejAuX0hPVDogLTEKaHcuYWNwaS50aGVy bWFsLnR6MC5fQ1JUOiAxMTAuMEMKaHcuYWNwaS50aGVybWFsLnR6MC5fQUN4OiAtMSAtMSAt MSAtMSAtMSAtMSAtMSAtMSAtMSAtMQpody5hY3BpLnRoZXJtYWwudHowLl9UQzE6IDIKaHcu YWNwaS50aGVybWFsLnR6MC5fVEMyOiAxMApody5hY3BpLnRoZXJtYWwudHowLl9UU1A6IDEw MApody5hY3BpLmFjbGluZTogMQpody5hY3BpLmJhdHRlcnkubGlmZTogOTkKaHcuYWNwaS5i YXR0ZXJ5LnRpbWU6IC0xCmh3LmFjcGkuYmF0dGVyeS5zdGF0ZTogMApody5hY3BpLmJhdHRl cnkudW5pdHM6IDEKaHcuYWNwaS5iYXR0ZXJ5LmluZm9fZXhwaXJlOiA1Cmh3LmFjcGkuY3B1 LmN4X2xvd2VzdDogQzEKaHcuZHJpLjAubmFtZTogaTkxNSAweDI0IHBjaTowMDAwOjAwOjAy LjAKaHcuZHJpLjAudm06IApzbG90IG9mZnNldAkgICAgICAgIHNpemUgICAgICAgdHlwZSBm bGFncyBhZGRyZXNzICAgICAgICAgICAgbXRycgogICAwIDB4MDAwMDAwMDA4MDAwMDAwMCAw eDAwMDgwMDAwICBSRUcgIDB4ODggMHgwMDAwMDAwMGU0NTIzMDAwIG5vCiAgIDEgMHgwMDAw MDAwMGM4NjFkMDAwIDB4MDAwMDIwMDAgIFNITSAgMHgyMCAweDAwMDAwMDAwYzg2MWQwMDAg bm8KICAgMiAweDAwMDAwMDAwZDAwMDAwMDAgMHgwMDAyMDAwMCAgQUdQICAweDAwIDB4MDAw MDAwMDAwMDAwMDAwMCB5ZXMKICAgMyAweDAwMDAwMDAwZDAyZmUwMDAgMHgwMGRjMDAwMCAg QUdQICAweDAwIDB4MDAwMDAwMDAwMDAwMDAwMCB5ZXMKICAgNCAweDAwMDAwMDAwZDQ5Nzgw MDAgMHgwMGRjMDAwMCAgQUdQICAweDAwIDB4MDAwMDAwMDAwMDAwMDAwMCB5ZXMKICAgNSAw eDAwMDAwMDAwZDU3MzgwMDAgMHgwMGRjMDAwMCAgQUdQICAweDAwIDB4MDAwMDAwMDAwMDAw MDAwMCB5ZXMKICAgNiAweDAwMDAwMDAwZDY0ZjgwMDAgMHgwMjAwMDAwMCAgQUdQICAweDAw IDB4MDAwMDAwMDAwMDAwMDAwMCB5ZXMKCmh3LmRyaS4wLmNsaWVudHM6IAphIGRldglwaWQg ICAgdWlkCW1hZ2ljCSAgaW9jdGxzCnkgICAwICAyNjUxICAgICAwICAgICAgICAgIDAgICAg IDMyMDgyNAoKaHcuZHJpLjAuZGVidWc6IDAKbWFjaGRlcC5lbmFibGVfcGFuaWNfa2V5OiAw Cm1hY2hkZXAuYWRqa2VybnR6OiAtMjg4MDAKbWFjaGRlcC53YWxsX2Ntb3NfY2xvY2s6IDEK bWFjaGRlcC5kaXNhYmxlX3J0Y19zZXQ6IDAKbWFjaGRlcC5jb25zcGVlZDogOTYwMAptYWNo ZGVwLmdkYnNwZWVkOiA5NjAwCm1hY2hkZXAuY29ucmNsazogMTg0MzIwMAptYWNoZGVwLmRp c2FibGVfbXRycnM6IDAKbWFjaGRlcC5ndWVzc2VkX2Jvb3RkZXY6IDI2ODY0NTE3MTIKbWFj aGRlcC5jcHVfaWRsZV9obHQ6IDEKbWFjaGRlcC5obHRfY3B1czogMAptYWNoZGVwLnByb3Rf ZmF1bHRfdHJhbnNsYXRpb246IDAKbWFjaGRlcC5wYW5pY19vbl9ubWk6IDEKbWFjaGRlcC50 c2NfZnJlcTogMTIwMDAwMDAwMAptYWNoZGVwLmk4MjU0X2ZyZXE6IDExOTMxODIKbWFjaGRl cC5hY3BpX3RpbWVyX2ZyZXE6IDM1Nzk1NDUKbWFjaGRlcC5hY3BpX3Jvb3Q6IDEwMjA2MjQK bWFjaGRlcC5obHRfbG9naWNhbF9jcHVzOiAwCm1hY2hkZXAubG9naWNhbF9jcHVzX21hc2s6 IDIKdXNlci5jc19wYXRoOiAvdXNyL2JpbjovYmluOi91c3Ivc2Jpbjovc2JpbjoKdXNlci5i Y19iYXNlX21heDogOTkKdXNlci5iY19kaW1fbWF4OiAyMDQ4CnVzZXIuYmNfc2NhbGVfbWF4 OiA5OQp1c2VyLmJjX3N0cmluZ19tYXg6IDEwMDAKdXNlci5jb2xsX3dlaWdodHNfbWF4OiAw CnVzZXIuZXhwcl9uZXN0X21heDogMzIKdXNlci5saW5lX21heDogMjA0OAp1c2VyLnJlX2R1 cF9tYXg6IDI1NQp1c2VyLnBvc2l4Ml92ZXJzaW9uOiAxOTkyMTIKdXNlci5wb3NpeDJfY19i aW5kOiAwCnVzZXIucG9zaXgyX2NfZGV2OiAwCnVzZXIucG9zaXgyX2NoYXJfdGVybTogMAp1 c2VyLnBvc2l4Ml9mb3J0X2RldjogMAp1c2VyLnBvc2l4Ml9mb3J0X3J1bjogMAp1c2VyLnBv c2l4Ml9sb2NhbGVkZWY6IDAKdXNlci5wb3NpeDJfc3dfZGV2OiAwCnVzZXIucG9zaXgyX3Vw ZTogMAp1c2VyLnN0cmVhbV9tYXg6IDIwCnVzZXIudHpuYW1lX21heDogMjU1CnAxMDAzXzFi LmFzeW5jaHJvbm91c19pbzogMApwMTAwM18xYi5tYXBwZWRfZmlsZXM6IDEKcDEwMDNfMWIu bWVtbG9jazogMApwMTAwM18xYi5tZW1sb2NrX3JhbmdlOiAwCnAxMDAzXzFiLm1lbW9yeV9w cm90ZWN0aW9uOiAwCnAxMDAzXzFiLm1lc3NhZ2VfcGFzc2luZzogMApwMTAwM18xYi5wcmlv cml0aXplZF9pbzogMApwMTAwM18xYi5wcmlvcml0eV9zY2hlZHVsaW5nOiAxCnAxMDAzXzFi LnJlYWx0aW1lX3NpZ25hbHM6IDIwMDExMgpwMTAwM18xYi5zZW1hcGhvcmVzOiAwCnAxMDAz XzFiLmZzeW5jOiAwCnAxMDAzXzFiLnNoYXJlZF9tZW1vcnlfb2JqZWN0czogMQpwMTAwM18x Yi5zeW5jaHJvbml6ZWRfaW86IDAKcDEwMDNfMWIudGltZXJzOiAyMDAxMTIKcDEwMDNfMWIu YWlvX2xpc3Rpb19tYXg6IC0xCnAxMDAzXzFiLmFpb19tYXg6IC0xCnAxMDAzXzFiLmFpb19w cmlvX2RlbHRhX21heDogLTEKcDEwMDNfMWIuZGVsYXl0aW1lcl9tYXg6IDIxNDc0ODM2NDcK cDEwMDNfMWIubXFfb3Blbl9tYXg6IDAKcDEwMDNfMWIucGFnZXNpemU6IDQwOTYKcDEwMDNf MWIucnRzaWdfbWF4OiA2MgpwMTAwM18xYi5zZW1fbnNlbXNfbWF4OiAwCnAxMDAzXzFiLnNl bV92YWx1ZV9tYXg6IDAKcDEwMDNfMWIuc2lncXVldWVfbWF4OiAxMjgKcDEwMDNfMWIudGlt ZXJfbWF4OiAzMgpzZWN1cml0eS5qYWlsLmphaWxlZDogMApzZWN1cml0eS5qYWlsLmphaWxf bWF4X2FmX2lwczogMjU1CnNlY3VyaXR5LmphaWwubW91bnRfYWxsb3dlZDogMApzZWN1cml0 eS5qYWlsLmNoZmxhZ3NfYWxsb3dlZDogMApzZWN1cml0eS5qYWlsLmFsbG93X3Jhd19zb2Nr ZXRzOiAwCnNlY3VyaXR5LmphaWwuZW5mb3JjZV9zdGF0ZnM6IDIKc2VjdXJpdHkuamFpbC5z eXN2aXBjX2FsbG93ZWQ6IDAKc2VjdXJpdHkuamFpbC5zb2NrZXRfdW5peGlwcm91dGVfb25s eTogMQpzZWN1cml0eS5qYWlsLnNldF9ob3N0bmFtZV9hbGxvd2VkOiAxCnNlY3VyaXR5LmJz ZC5zdXNlcl9lbmFibGVkOiAxCnNlY3VyaXR5LmJzZC51bnByaXZpbGVnZWRfcHJvY19kZWJ1 ZzogMQpzZWN1cml0eS5ic2QuY29uc2VydmF0aXZlX3NpZ25hbHM6IDEKc2VjdXJpdHkuYnNk LnNlZV9vdGhlcl9naWRzOiAxCnNlY3VyaXR5LmJzZC5zZWVfb3RoZXJfdWlkczogMQpzZWN1 cml0eS5ic2QudW5wcml2aWxlZ2VkX3JlYWRfbXNnYnVmOiAxCnNlY3VyaXR5LmJzZC5oYXJk bGlua19jaGVja19naWQ6IDAKc2VjdXJpdHkuYnNkLmhhcmRsaW5rX2NoZWNrX3VpZDogMApz ZWN1cml0eS5ic2QudW5wcml2aWxlZ2VkX2dldF9xdW90YTogMApjb21wYXQubGludXgub3Nz X3ZlcnNpb246IDE5ODE0NApjb21wYXQubGludXgub3NyZWxlYXNlOiAyLjYuMjAKY29tcGF0 LmxpbnV4Lm9zbmFtZTogTGludXgKZGV2Lm5leHVzLjAuJWRyaXZlcjogbmV4dXMKZGV2Lm5l eHVzLjAuJXBhcmVudDogcm9vdDAKZGV2LnJhbS4wLiVkZXNjOiBTeXN0ZW0gUkFNCmRldi5y YW0uMC4lZHJpdmVyOiByYW0KZGV2LnJhbS4wLiVwYXJlbnQ6IG5leHVzMApkZXYubnB4LjAu JWRlc2M6IG1hdGggcHJvY2Vzc29yCmRldi5ucHguMC4lZHJpdmVyOiBucHgKZGV2Lm5weC4w LiVwYXJlbnQ6IG5leHVzMApkZXYuYWNwaS4wLiVkZXNjOiBMRU5PVk8gVFAtNkEKZGV2LmFj cGkuMC4lZHJpdmVyOiBhY3BpCmRldi5hY3BpLjAuJXBhcmVudDogbmV4dXMwCmRldi5hY3Bp X2VjLjAuJWRlc2M6IEVtYmVkZGVkIENvbnRyb2xsZXI6IEdQRSAweDFiLCBFQ0RUCmRldi5h Y3BpX2VjLjAuJWRyaXZlcjogYWNwaV9lYwpkZXYuYWNwaV9lYy4wLiVsb2NhdGlvbjogaGFu ZGxlPVxfU0JfLlBDSTAuU0JSRy5FQzBfCmRldi5hY3BpX2VjLjAuJXBucGluZm86IF9ISUQ9 UE5QMEMwOSBfVUlEPTAKZGV2LmFjcGlfZWMuMC4lcGFyZW50OiBhY3BpMApkZXYuYWNwaV9z eXNyZXNvdXJjZS4wLiVkZXNjOiBTeXN0ZW0gUmVzb3VyY2UKZGV2LmFjcGlfc3lzcmVzb3Vy Y2UuMC4lZHJpdmVyOiBhY3BpX3N5c3Jlc291cmNlCmRldi5hY3BpX3N5c3Jlc291cmNlLjAu JWxvY2F0aW9uOiBoYW5kbGU9XF9TQl8uUENJMC5NQ0hfCmRldi5hY3BpX3N5c3Jlc291cmNl LjAuJXBucGluZm86IF9ISUQ9UE5QMEMwMiBfVUlEPTEwCmRldi5hY3BpX3N5c3Jlc291cmNl LjAuJXBhcmVudDogYWNwaTAKZGV2LmFjcGlfc3lzcmVzb3VyY2UuMS4lZGVzYzogU3lzdGVt IFJlc291cmNlCmRldi5hY3BpX3N5c3Jlc291cmNlLjEuJWRyaXZlcjogYWNwaV9zeXNyZXNv dXJjZQpkZXYuYWNwaV9zeXNyZXNvdXJjZS4xLiVsb2NhdGlvbjogaGFuZGxlPVxfU0JfLlBD STAuU0JSRy5STVNDCmRldi5hY3BpX3N5c3Jlc291cmNlLjEuJXBucGluZm86IF9ISUQ9UE5Q MEMwMiBfVUlEPTE2CmRldi5hY3BpX3N5c3Jlc291cmNlLjEuJXBhcmVudDogYWNwaTAKZGV2 LmFjcGlfc3lzcmVzb3VyY2UuMi4lZGVzYzogU3lzdGVtIFJlc291cmNlCmRldi5hY3BpX3N5 c3Jlc291cmNlLjIuJWRyaXZlcjogYWNwaV9zeXNyZXNvdXJjZQpkZXYuYWNwaV9zeXNyZXNv dXJjZS4yLiVsb2NhdGlvbjogaGFuZGxlPVxfU0JfLlBDSTAuU0JSRy5GV0hfCmRldi5hY3Bp X3N5c3Jlc291cmNlLjIuJXBucGluZm86IF9ISUQ9UE5QMEMwMiBfVUlEPTIKZGV2LmFjcGlf c3lzcmVzb3VyY2UuMi4lcGFyZW50OiBhY3BpMApkZXYuYWNwaV9zeXNyZXNvdXJjZS4zLiVk ZXNjOiBTeXN0ZW0gUmVzb3VyY2UKZGV2LmFjcGlfc3lzcmVzb3VyY2UuMy4lZHJpdmVyOiBh Y3BpX3N5c3Jlc291cmNlCmRldi5hY3BpX3N5c3Jlc291cmNlLjMuJWxvY2F0aW9uOiBoYW5k bGU9XF9TQl8uUENJMC5TQlJHLkZXSEUKZGV2LmFjcGlfc3lzcmVzb3VyY2UuMy4lcG5waW5m bzogX0hJRD1QTlAwQzAyIF9VSUQ9MwpkZXYuYWNwaV9zeXNyZXNvdXJjZS4zLiVwYXJlbnQ6 IGFjcGkwCmRldi5hY3BpX3N5c3Jlc291cmNlLjQuJWRlc2M6IFN5c3RlbSBSZXNvdXJjZQpk ZXYuYWNwaV9zeXNyZXNvdXJjZS40LiVkcml2ZXI6IGFjcGlfc3lzcmVzb3VyY2UKZGV2LmFj cGlfc3lzcmVzb3VyY2UuNC4lbG9jYXRpb246IGhhbmRsZT1cX1NCXy5QQ0kwLlNCUkcuT01T QwpkZXYuYWNwaV9zeXNyZXNvdXJjZS40LiVwbnBpbmZvOiBfSElEPVBOUDBDMDIgX1VJRD0w CmRldi5hY3BpX3N5c3Jlc291cmNlLjQuJXBhcmVudDogYWNwaTAKZGV2LmFjcGlfc3lzcmVz b3VyY2UuNS4lZGVzYzogU3lzdGVtIFJlc291cmNlCmRldi5hY3BpX3N5c3Jlc291cmNlLjUu JWRyaXZlcjogYWNwaV9zeXNyZXNvdXJjZQpkZXYuYWNwaV9zeXNyZXNvdXJjZS41LiVsb2Nh dGlvbjogaGFuZGxlPVxfU0JfLlBDSTAuUENJRQpkZXYuYWNwaV9zeXNyZXNvdXJjZS41LiVw bnBpbmZvOiBfSElEPVBOUDBDMDIgX1VJRD0xNwpkZXYuYWNwaV9zeXNyZXNvdXJjZS41LiVw YXJlbnQ6IGFjcGkwCmRldi5hY3BpX3N5c3Jlc291cmNlLjYuJWRlc2M6IFN5c3RlbSBSZXNv dXJjZQpkZXYuYWNwaV9zeXNyZXNvdXJjZS42LiVkcml2ZXI6IGFjcGlfc3lzcmVzb3VyY2UK ZGV2LmFjcGlfc3lzcmVzb3VyY2UuNi4lbG9jYXRpb246IGhhbmRsZT1cX1NCXy5STUVNCmRl di5hY3BpX3N5c3Jlc291cmNlLjYuJXBucGluZm86IF9ISUQ9UE5QMEMwMSBfVUlEPTEKZGV2 LmFjcGlfc3lzcmVzb3VyY2UuNi4lcGFyZW50OiBhY3BpMApkZXYuYWNwaV90aW1lci4wLiVk ZXNjOiAyNC1iaXQgdGltZXIgYXQgMy41Nzk1NDVNSHoKZGV2LmFjcGlfdGltZXIuMC4lZHJp dmVyOiBhY3BpX3RpbWVyCmRldi5hY3BpX3RpbWVyLjAuJWxvY2F0aW9uOiB1bmtub3duCmRl di5hY3BpX3RpbWVyLjAuJXBucGluZm86IHVua25vd24KZGV2LmFjcGlfdGltZXIuMC4lcGFy ZW50OiBhY3BpMApkZXYucGNpX2xpbmsuMC4lZGVzYzogQUNQSSBQQ0kgTGluayBMTktBCmRl di5wY2lfbGluay4wLiVkcml2ZXI6IHBjaV9saW5rCmRldi5wY2lfbGluay4wLiVsb2NhdGlv bjogaGFuZGxlPVxfU0JfLkxOS0EKZGV2LnBjaV9saW5rLjAuJXBucGluZm86IF9ISUQ9UE5Q MEMwRiBfVUlEPTEKZGV2LnBjaV9saW5rLjAuJXBhcmVudDogYWNwaTAKZGV2LnBjaV9saW5r LjEuJWRlc2M6IEFDUEkgUENJIExpbmsgTE5LQgpkZXYucGNpX2xpbmsuMS4lZHJpdmVyOiBw Y2lfbGluawpkZXYucGNpX2xpbmsuMS4lbG9jYXRpb246IGhhbmRsZT1cX1NCXy5MTktCCmRl di5wY2lfbGluay4xLiVwbnBpbmZvOiBfSElEPVBOUDBDMEYgX1VJRD0yCmRldi5wY2lfbGlu ay4xLiVwYXJlbnQ6IGFjcGkwCmRldi5wY2lfbGluay4yLiVkZXNjOiBBQ1BJIFBDSSBMaW5r IExOS0MKZGV2LnBjaV9saW5rLjIuJWRyaXZlcjogcGNpX2xpbmsKZGV2LnBjaV9saW5rLjIu JWxvY2F0aW9uOiBoYW5kbGU9XF9TQl8uTE5LQwpkZXYucGNpX2xpbmsuMi4lcG5waW5mbzog X0hJRD1QTlAwQzBGIF9VSUQ9MwpkZXYucGNpX2xpbmsuMi4lcGFyZW50OiBhY3BpMApkZXYu cGNpX2xpbmsuMy4lZGVzYzogQUNQSSBQQ0kgTGluayBMTktECmRldi5wY2lfbGluay4zLiVk cml2ZXI6IHBjaV9saW5rCmRldi5wY2lfbGluay4zLiVsb2NhdGlvbjogaGFuZGxlPVxfU0Jf LkxOS0QKZGV2LnBjaV9saW5rLjMuJXBucGluZm86IF9ISUQ9UE5QMEMwRiBfVUlEPTQKZGV2 LnBjaV9saW5rLjMuJXBhcmVudDogYWNwaTAKZGV2LnBjaV9saW5rLjQuJWRlc2M6IEFDUEkg UENJIExpbmsgTE5LRQpkZXYucGNpX2xpbmsuNC4lZHJpdmVyOiBwY2lfbGluawpkZXYucGNp X2xpbmsuNC4lbG9jYXRpb246IGhhbmRsZT1cX1NCXy5MTktFCmRldi5wY2lfbGluay40LiVw bnBpbmZvOiBfSElEPVBOUDBDMEYgX1VJRD01CmRldi5wY2lfbGluay40LiVwYXJlbnQ6IGFj cGkwCmRldi5wY2lfbGluay41LiVkZXNjOiBBQ1BJIFBDSSBMaW5rIExOS0YKZGV2LnBjaV9s aW5rLjUuJWRyaXZlcjogcGNpX2xpbmsKZGV2LnBjaV9saW5rLjUuJWxvY2F0aW9uOiBoYW5k bGU9XF9TQl8uTE5LRgpkZXYucGNpX2xpbmsuNS4lcG5waW5mbzogX0hJRD1QTlAwQzBGIF9V SUQ9NgpkZXYucGNpX2xpbmsuNS4lcGFyZW50OiBhY3BpMApkZXYucGNpX2xpbmsuNi4lZGVz YzogQUNQSSBQQ0kgTGluayBMTktHCmRldi5wY2lfbGluay42LiVkcml2ZXI6IHBjaV9saW5r CmRldi5wY2lfbGluay42LiVsb2NhdGlvbjogaGFuZGxlPVxfU0JfLkxOS0cKZGV2LnBjaV9s aW5rLjYuJXBucGluZm86IF9ISUQ9UE5QMEMwRiBfVUlEPTcKZGV2LnBjaV9saW5rLjYuJXBh cmVudDogYWNwaTAKZGV2LnBjaV9saW5rLjcuJWRlc2M6IEFDUEkgUENJIExpbmsgTE5LSApk ZXYucGNpX2xpbmsuNy4lZHJpdmVyOiBwY2lfbGluawpkZXYucGNpX2xpbmsuNy4lbG9jYXRp b246IGhhbmRsZT1cX1NCXy5MTktICmRldi5wY2lfbGluay43LiVwbnBpbmZvOiBfSElEPVBO UDBDMEYgX1VJRD04CmRldi5wY2lfbGluay43LiVwYXJlbnQ6IGFjcGkwCmRldi5hY3BpX2hw ZXQuMC4lZGVzYzogSGlnaCBQcmVjaXNpb24gRXZlbnQgVGltZXIKZGV2LmFjcGlfaHBldC4w LiVkcml2ZXI6IGFjcGlfaHBldApkZXYuYWNwaV9ocGV0LjAuJWxvY2F0aW9uOiB1bmtub3du CmRldi5hY3BpX2hwZXQuMC4lcG5waW5mbzogdW5rbm93bgpkZXYuYWNwaV9ocGV0LjAuJXBh cmVudDogYWNwaTAKZGV2LnBjaWIuMC4lZGVzYzogQUNQSSBIb3N0LVBDSSBicmlkZ2UKZGV2 LnBjaWIuMC4lZHJpdmVyOiBwY2liCmRldi5wY2liLjAuJWxvY2F0aW9uOiBoYW5kbGU9XF9T Ql8uUENJMApkZXYucGNpYi4wLiVwbnBpbmZvOiBfSElEPVBOUDBBMDggX1VJRD0wCmRldi5w Y2liLjAuJXBhcmVudDogYWNwaTAKZGV2LnBjaWIuMS4lZGVzYzogQUNQSSBQQ0ktUENJIGJy aWRnZQpkZXYucGNpYi4xLiVkcml2ZXI6IHBjaWIKZGV2LnBjaWIuMS4lbG9jYXRpb246IHNs b3Q9MjggZnVuY3Rpb249MCBoYW5kbGU9XF9TQl8uUENJMC5QMFAyCmRldi5wY2liLjEuJXBu cGluZm86IHZlbmRvcj0weDgwODYgZGV2aWNlPTB4Mjk0MCBzdWJ2ZW5kb3I9MHgxN2FhIHN1 YmRldmljZT0weDIwZjMgY2xhc3M9MHgwNjA0MDAKZGV2LnBjaWIuMS4lcGFyZW50OiBwY2kw CmRldi5wY2liLjEud2FrZTogMApkZXYucGNpYi4yLiVkZXNjOiBBQ1BJIFBDSS1QQ0kgYnJp ZGdlCmRldi5wY2liLjIuJWRyaXZlcjogcGNpYgpkZXYucGNpYi4yLiVsb2NhdGlvbjogc2xv dD0yOCBmdW5jdGlvbj0xIGhhbmRsZT1cX1NCXy5QQ0kwLlAwUDMKZGV2LnBjaWIuMi4lcG5w aW5mbzogdmVuZG9yPTB4ODA4NiBkZXZpY2U9MHgyOTQyIHN1YnZlbmRvcj0weDE3YWEgc3Vi ZGV2aWNlPTB4MjBmMyBjbGFzcz0weDA2MDQwMApkZXYucGNpYi4yLiVwYXJlbnQ6IHBjaTAK ZGV2LnBjaWIuMi53YWtlOiAwCmRldi5wY2liLjMuJWRlc2M6IEFDUEkgUENJLVBDSSBicmlk Z2UKZGV2LnBjaWIuMy4lZHJpdmVyOiBwY2liCmRldi5wY2liLjMuJWxvY2F0aW9uOiBzbG90 PTI4IGZ1bmN0aW9uPTIgaGFuZGxlPVxfU0JfLlBDSTAuUDBQNApkZXYucGNpYi4zLiVwbnBp bmZvOiB2ZW5kb3I9MHg4MDg2IGRldmljZT0weDI5NDQgc3VidmVuZG9yPTB4MTdhYSBzdWJk ZXZpY2U9MHgyMGYzIGNsYXNzPTB4MDYwNDAwCmRldi5wY2liLjMuJXBhcmVudDogcGNpMApk ZXYucGNpYi4zLndha2U6IDAKZGV2LnBjaWIuNC4lZGVzYzogQUNQSSBQQ0ktUENJIGJyaWRn ZQpkZXYucGNpYi40LiVkcml2ZXI6IHBjaWIKZGV2LnBjaWIuNC4lbG9jYXRpb246IHNsb3Q9 MjggZnVuY3Rpb249MyBoYW5kbGU9XF9TQl8uUENJMC5QMFA2CmRldi5wY2liLjQuJXBucGlu Zm86IHZlbmRvcj0weDgwODYgZGV2aWNlPTB4Mjk0NiBzdWJ2ZW5kb3I9MHgxN2FhIHN1YmRl dmljZT0weDIwZjMgY2xhc3M9MHgwNjA0MDAKZGV2LnBjaWIuNC4lcGFyZW50OiBwY2kwCmRl di5wY2liLjQud2FrZTogMApkZXYucGNpYi41LiVkZXNjOiBBQ1BJIFBDSS1QQ0kgYnJpZGdl CmRldi5wY2liLjUuJWRyaXZlcjogcGNpYgpkZXYucGNpYi41LiVsb2NhdGlvbjogc2xvdD0z MCBmdW5jdGlvbj0wIGhhbmRsZT1cX1NCXy5QQ0kwLlAwUDgKZGV2LnBjaWIuNS4lcG5waW5m bzogdmVuZG9yPTB4ODA4NiBkZXZpY2U9MHgyNDQ4IHN1YnZlbmRvcj0weDE3YWEgc3ViZGV2 aWNlPTB4MjBmNCBjbGFzcz0weDA2MDQwMQpkZXYucGNpYi41LiVwYXJlbnQ6IHBjaTAKZGV2 LnBjaWIuNS53YWtlOiAwCmRldi5wY2kuMC4lZGVzYzogQUNQSSBQQ0kgYnVzCmRldi5wY2ku MC4lZHJpdmVyOiBwY2kKZGV2LnBjaS4wLiVwYXJlbnQ6IHBjaWIwCmRldi5wY2kuMS4lZGVz YzogQUNQSSBQQ0kgYnVzCmRldi5wY2kuMS4lZHJpdmVyOiBwY2kKZGV2LnBjaS4xLiVwYXJl bnQ6IHBjaWIxCmRldi5wY2kuMS53YWtlOiAwCmRldi5wY2kuMi4lZGVzYzogQUNQSSBQQ0kg YnVzCmRldi5wY2kuMi4lZHJpdmVyOiBwY2kKZGV2LnBjaS4yLiVwYXJlbnQ6IHBjaWIyCmRl di5wY2kuMi53YWtlOiAwCmRldi5wY2kuMy4lZGVzYzogQUNQSSBQQ0kgYnVzCmRldi5wY2ku My4lZHJpdmVyOiBwY2kKZGV2LnBjaS4zLiVwYXJlbnQ6IHBjaWIzCmRldi5wY2kuMy53YWtl OiAwCmRldi5wY2kuMTIuJWRlc2M6IEFDUEkgUENJIGJ1cwpkZXYucGNpLjEyLiVkcml2ZXI6 IHBjaQpkZXYucGNpLjEyLiVwYXJlbnQ6IHBjaWI0CmRldi5wY2kuMTIud2FrZTogMApkZXYu cGNpLjEzLiVkZXNjOiBBQ1BJIFBDSSBidXMKZGV2LnBjaS4xMy4lZHJpdmVyOiBwY2kKZGV2 LnBjaS4xMy4lcGFyZW50OiBwY2liNQpkZXYucGNpLjEzLndha2U6IDAKZGV2Lmhvc3RiLjAu JWRlc2M6IEhvc3QgdG8gUENJIGJyaWRnZQpkZXYuaG9zdGIuMC4lZHJpdmVyOiBob3N0Ygpk ZXYuaG9zdGIuMC4lbG9jYXRpb246IHNsb3Q9MCBmdW5jdGlvbj0wCmRldi5ob3N0Yi4wLiVw bnBpbmZvOiB2ZW5kb3I9MHg4MDg2IGRldmljZT0weDJhNDAgc3VidmVuZG9yPTB4MTdhYSBz dWJkZXZpY2U9MHgyMGUwIGNsYXNzPTB4MDYwMDAwCmRldi5ob3N0Yi4wLiVwYXJlbnQ6IHBj aTAKZGV2LnZnYXBjaS4wLiVkZXNjOiBWR0EtY29tcGF0aWJsZSBkaXNwbGF5CmRldi52Z2Fw Y2kuMC4lZHJpdmVyOiB2Z2FwY2kKZGV2LnZnYXBjaS4wLiVsb2NhdGlvbjogc2xvdD0yIGZ1 bmN0aW9uPTAgaGFuZGxlPVxfU0JfLlBDSTAuVkdBXwpkZXYudmdhcGNpLjAuJXBucGluZm86 IHZlbmRvcj0weDgwODYgZGV2aWNlPTB4MmE0MiBzdWJ2ZW5kb3I9MHgxN2FhIHN1YmRldmlj ZT0weDIwZTQgY2xhc3M9MHgwMzAwMDAKZGV2LnZnYXBjaS4wLiVwYXJlbnQ6IHBjaTAKZGV2 LnZnYXBjaS4xLiVkZXNjOiBWR0EtY29tcGF0aWJsZSBkaXNwbGF5CmRldi52Z2FwY2kuMS4l ZHJpdmVyOiB2Z2FwY2kKZGV2LnZnYXBjaS4xLiVsb2NhdGlvbjogc2xvdD0yIGZ1bmN0aW9u PTEKZGV2LnZnYXBjaS4xLiVwbnBpbmZvOiB2ZW5kb3I9MHg4MDg2IGRldmljZT0weDJhNDMg c3VidmVuZG9yPTB4MTdhYSBzdWJkZXZpY2U9MHgyMGU0IGNsYXNzPTB4MDM4MDAwCmRldi52 Z2FwY2kuMS4lcGFyZW50OiBwY2kwCmRldi5hZ3AuMC4lZGVzYzogSW50ZWwgR000NSBTVkdB IGNvbnRyb2xsZXIKZGV2LmFncC4wLiVkcml2ZXI6IGFncApkZXYuYWdwLjAuJXBhcmVudDog dmdhcGNpMApkZXYuYWNwaV92aWRlby4wLiVkZXNjOiBBQ1BJIHZpZGVvIGV4dGVuc2lvbgpk ZXYuYWNwaV92aWRlby4wLiVkcml2ZXI6IGFjcGlfdmlkZW8KZGV2LmFjcGlfdmlkZW8uMC4l cGFyZW50OiB2Z2FwY2kwCmRldi5kcm0uMC4lZGVzYzogTW9iaWxlIEludGVswq4gR000NSBF eHByZXNzIENoaXBzZXQKZGV2LmRybS4wLiVkcml2ZXI6IGRybQpkZXYuZHJtLjAuJXBhcmVu dDogdmdhcGNpMApkZXYudWhjaS4wLiVkZXNjOiBVSENJIChnZW5lcmljKSBVU0IgY29udHJv bGxlcgpkZXYudWhjaS4wLiVkcml2ZXI6IHVoY2kKZGV2LnVoY2kuMC4lbG9jYXRpb246IHNs b3Q9MjYgZnVuY3Rpb249MCBoYW5kbGU9XF9TQl8uUENJMC5VU0IzCmRldi51aGNpLjAuJXBu cGluZm86IHZlbmRvcj0weDgwODYgZGV2aWNlPTB4MjkzNyBzdWJ2ZW5kb3I9MHgxN2FhIHN1 YmRldmljZT0weDIwZjAgY2xhc3M9MHgwYzAzMDAKZGV2LnVoY2kuMC4lcGFyZW50OiBwY2kw CmRldi51aGNpLjAud2FrZTogMApkZXYudWhjaS4xLiVkZXNjOiBVSENJIChnZW5lcmljKSBV U0IgY29udHJvbGxlcgpkZXYudWhjaS4xLiVkcml2ZXI6IHVoY2kKZGV2LnVoY2kuMS4lbG9j YXRpb246IHNsb3Q9MjYgZnVuY3Rpb249MSBoYW5kbGU9XF9TQl8uUENJMC5VU0I0CmRldi51 aGNpLjEuJXBucGluZm86IHZlbmRvcj0weDgwODYgZGV2aWNlPTB4MjkzOCBzdWJ2ZW5kb3I9 MHgxN2FhIHN1YmRldmljZT0weDIwZjAgY2xhc3M9MHgwYzAzMDAKZGV2LnVoY2kuMS4lcGFy ZW50OiBwY2kwCmRldi51aGNpLjEud2FrZTogMApkZXYudWhjaS4yLiVkZXNjOiBVSENJIChn ZW5lcmljKSBVU0IgY29udHJvbGxlcgpkZXYudWhjaS4yLiVkcml2ZXI6IHVoY2kKZGV2LnVo Y2kuMi4lbG9jYXRpb246IHNsb3Q9MjYgZnVuY3Rpb249MiBoYW5kbGU9XF9TQl8uUENJMC5V U0I2CmRldi51aGNpLjIuJXBucGluZm86IHZlbmRvcj0weDgwODYgZGV2aWNlPTB4MjkzOSBz dWJ2ZW5kb3I9MHgxN2FhIHN1YmRldmljZT0weDIwZjAgY2xhc3M9MHgwYzAzMDAKZGV2LnVo Y2kuMi4lcGFyZW50OiBwY2kwCmRldi51aGNpLjIud2FrZTogMApkZXYudWhjaS4zLiVkZXNj OiBVSENJIChnZW5lcmljKSBVU0IgY29udHJvbGxlcgpkZXYudWhjaS4zLiVkcml2ZXI6IHVo Y2kKZGV2LnVoY2kuMy4lbG9jYXRpb246IHNsb3Q9MjkgZnVuY3Rpb249MCBoYW5kbGU9XF9T Ql8uUENJMC5VU0IwCmRldi51aGNpLjMuJXBucGluZm86IHZlbmRvcj0weDgwODYgZGV2aWNl PTB4MjkzNCBzdWJ2ZW5kb3I9MHgxN2FhIHN1YmRldmljZT0weDIwZjAgY2xhc3M9MHgwYzAz MDAKZGV2LnVoY2kuMy4lcGFyZW50OiBwY2kwCmRldi51aGNpLjMud2FrZTogMApkZXYudWhj aS40LiVkZXNjOiBVSENJIChnZW5lcmljKSBVU0IgY29udHJvbGxlcgpkZXYudWhjaS40LiVk cml2ZXI6IHVoY2kKZGV2LnVoY2kuNC4lbG9jYXRpb246IHNsb3Q9MjkgZnVuY3Rpb249MSBo YW5kbGU9XF9TQl8uUENJMC5VU0IxCmRldi51aGNpLjQuJXBucGluZm86IHZlbmRvcj0weDgw ODYgZGV2aWNlPTB4MjkzNSBzdWJ2ZW5kb3I9MHgxN2FhIHN1YmRldmljZT0weDIwZjAgY2xh c3M9MHgwYzAzMDAKZGV2LnVoY2kuNC4lcGFyZW50OiBwY2kwCmRldi51aGNpLjQud2FrZTog MApkZXYudWhjaS41LiVkZXNjOiBVSENJIChnZW5lcmljKSBVU0IgY29udHJvbGxlcgpkZXYu dWhjaS41LiVkcml2ZXI6IHVoY2kKZGV2LnVoY2kuNS4lbG9jYXRpb246IHNsb3Q9MjkgZnVu Y3Rpb249MiBoYW5kbGU9XF9TQl8uUENJMC5VU0IyCmRldi51aGNpLjUuJXBucGluZm86IHZl bmRvcj0weDgwODYgZGV2aWNlPTB4MjkzNiBzdWJ2ZW5kb3I9MHgxN2FhIHN1YmRldmljZT0w eDIwZjAgY2xhc3M9MHgwYzAzMDAKZGV2LnVoY2kuNS4lcGFyZW50OiBwY2kwCmRldi51aGNp LjUud2FrZTogMApkZXYudXNiLjAuJWRlc2M6IFVIQ0kgKGdlbmVyaWMpIFVTQiBjb250cm9s bGVyCmRldi51c2IuMC4lZHJpdmVyOiB1c2IKZGV2LnVzYi4wLiVwYXJlbnQ6IHVoY2kwCmRl di51c2IuMS4lZGVzYzogVUhDSSAoZ2VuZXJpYykgVVNCIGNvbnRyb2xsZXIKZGV2LnVzYi4x LiVkcml2ZXI6IHVzYgpkZXYudXNiLjEuJXBhcmVudDogdWhjaTEKZGV2LnVzYi4yLiVkZXNj OiBVSENJIChnZW5lcmljKSBVU0IgY29udHJvbGxlcgpkZXYudXNiLjIuJWRyaXZlcjogdXNi CmRldi51c2IuMi4lcGFyZW50OiB1aGNpMgpkZXYudXNiLjMuJWRlc2M6IEVIQ0kgKGdlbmVy aWMpIFVTQiAyLjAgY29udHJvbGxlcgpkZXYudXNiLjMuJWRyaXZlcjogdXNiCmRldi51c2Iu My4lcGFyZW50OiBlaGNpMApkZXYudXNiLjQuJWRlc2M6IFVIQ0kgKGdlbmVyaWMpIFVTQiBj b250cm9sbGVyCmRldi51c2IuNC4lZHJpdmVyOiB1c2IKZGV2LnVzYi40LiVwYXJlbnQ6IHVo Y2kzCmRldi51c2IuNS4lZGVzYzogVUhDSSAoZ2VuZXJpYykgVVNCIGNvbnRyb2xsZXIKZGV2 LnVzYi41LiVkcml2ZXI6IHVzYgpkZXYudXNiLjUuJXBhcmVudDogdWhjaTQKZGV2LnVzYi42 LiVkZXNjOiBVSENJIChnZW5lcmljKSBVU0IgY29udHJvbGxlcgpkZXYudXNiLjYuJWRyaXZl cjogdXNiCmRldi51c2IuNi4lcGFyZW50OiB1aGNpNQpkZXYudXNiLjcuJWRlc2M6IEVIQ0kg KGdlbmVyaWMpIFVTQiAyLjAgY29udHJvbGxlcgpkZXYudXNiLjcuJWRyaXZlcjogdXNiCmRl di51c2IuNy4lcGFyZW50OiBlaGNpMQpkZXYudWh1Yi4wLiVkZXNjOiBJbnRlbCBVSENJIHJv b3QgaHViLCBjbGFzcyA5LzAsIHJldiAxLjAwLzEuMDAsIGFkZHIgMQpkZXYudWh1Yi4wLiVk cml2ZXI6IHVodWIKZGV2LnVodWIuMC4lcGFyZW50OiB1c2IwCmRldi51aHViLjEuJWRlc2M6 IEludGVsIFVIQ0kgcm9vdCBodWIsIGNsYXNzIDkvMCwgcmV2IDEuMDAvMS4wMCwgYWRkciAx CmRldi51aHViLjEuJWRyaXZlcjogdWh1YgpkZXYudWh1Yi4xLiVwYXJlbnQ6IHVzYjEKZGV2 LnVodWIuMi4lZGVzYzogSW50ZWwgVUhDSSByb290IGh1YiwgY2xhc3MgOS8wLCByZXYgMS4w MC8xLjAwLCBhZGRyIDEKZGV2LnVodWIuMi4lZHJpdmVyOiB1aHViCmRldi51aHViLjIuJXBh cmVudDogdXNiMgpkZXYudWh1Yi4zLiVkZXNjOiBJbnRlbCBFSENJIHJvb3QgaHViLCBjbGFz cyA5LzAsIHJldiAyLjAwLzEuMDAsIGFkZHIgMQpkZXYudWh1Yi4zLiVkcml2ZXI6IHVodWIK ZGV2LnVodWIuMy4lcGFyZW50OiB1c2IzCmRldi51aHViLjQuJWRlc2M6IEludGVsIFVIQ0kg cm9vdCBodWIsIGNsYXNzIDkvMCwgcmV2IDEuMDAvMS4wMCwgYWRkciAxCmRldi51aHViLjQu JWRyaXZlcjogdWh1YgpkZXYudWh1Yi40LiVwYXJlbnQ6IHVzYjQKZGV2LnVodWIuNS4lZGVz YzogSW50ZWwgVUhDSSByb290IGh1YiwgY2xhc3MgOS8wLCByZXYgMS4wMC8xLjAwLCBhZGRy IDEKZGV2LnVodWIuNS4lZHJpdmVyOiB1aHViCmRldi51aHViLjUuJXBhcmVudDogdXNiNQpk ZXYudWh1Yi42LiVkZXNjOiBJbnRlbCBVSENJIHJvb3QgaHViLCBjbGFzcyA5LzAsIHJldiAx LjAwLzEuMDAsIGFkZHIgMQpkZXYudWh1Yi42LiVkcml2ZXI6IHVodWIKZGV2LnVodWIuNi4l cGFyZW50OiB1c2I2CmRldi51aHViLjcuJWRlc2M6IEludGVsIEVIQ0kgcm9vdCBodWIsIGNs YXNzIDkvMCwgcmV2IDIuMDAvMS4wMCwgYWRkciAxCmRldi51aHViLjcuJWRyaXZlcjogdWh1 YgpkZXYudWh1Yi43LiVwYXJlbnQ6IHVzYjcKZGV2LmVoY2kuMC4lZGVzYzogRUhDSSAoZ2Vu ZXJpYykgVVNCIDIuMCBjb250cm9sbGVyCmRldi5laGNpLjAuJWRyaXZlcjogZWhjaQpkZXYu ZWhjaS4wLiVsb2NhdGlvbjogc2xvdD0yNiBmdW5jdGlvbj03IGhhbmRsZT1cX1NCXy5QQ0kw LlVTQkUKZGV2LmVoY2kuMC4lcG5waW5mbzogdmVuZG9yPTB4ODA4NiBkZXZpY2U9MHgyOTNj IHN1YnZlbmRvcj0weDE3YWEgc3ViZGV2aWNlPTB4MjBmMSBjbGFzcz0weDBjMDMyMApkZXYu ZWhjaS4wLiVwYXJlbnQ6IHBjaTAKZGV2LmVoY2kuMC53YWtlOiAwCmRldi5laGNpLjEuJWRl c2M6IEVIQ0kgKGdlbmVyaWMpIFVTQiAyLjAgY29udHJvbGxlcgpkZXYuZWhjaS4xLiVkcml2 ZXI6IGVoY2kKZGV2LmVoY2kuMS4lbG9jYXRpb246IHNsb3Q9MjkgZnVuY3Rpb249NyBoYW5k bGU9XF9TQl8uUENJMC5FVVNCCmRldi5laGNpLjEuJXBucGluZm86IHZlbmRvcj0weDgwODYg ZGV2aWNlPTB4MjkzYSBzdWJ2ZW5kb3I9MHgxN2FhIHN1YmRldmljZT0weDIwZjEgY2xhc3M9 MHgwYzAzMjAKZGV2LmVoY2kuMS4lcGFyZW50OiBwY2kwCmRldi5laGNpLjEud2FrZTogMApk ZXYuaGRhYy4wLiVkZXNjOiBJbnRlbCA4MjgwMUkgSGlnaCBEZWZpbml0aW9uIEF1ZGlvIENv bnRyb2xsZXIKZGV2LmhkYWMuMC4lZHJpdmVyOiBoZGFjCmRldi5oZGFjLjAuJWxvY2F0aW9u OiBzbG90PTI3IGZ1bmN0aW9uPTAgaGFuZGxlPVxfU0JfLlBDSTAuSERBQwpkZXYuaGRhYy4w LiVwbnBpbmZvOiB2ZW5kb3I9MHg4MDg2IGRldmljZT0weDI5M2Ugc3VidmVuZG9yPTB4MTdh YSBzdWJkZXZpY2U9MHgyMGYyIGNsYXNzPTB4MDQwMzAwCmRldi5oZGFjLjAuJXBhcmVudDog cGNpMApkZXYuaGRhYy4wLndha2U6IDAKZGV2LmhkYWMuMC5wb2xsaW5nOiAwCmRldi5oZGFj LjAucG9sbGluZ19pbnRlcnZhbDogMjUwCmRldi5oZGFjLjAucGluZHVtcDogMApkZXYuYXRo LjAuJWRlc2M6IEF0aGVyb3MgNTQyNC8yNDI0CmRldi5hdGguMC4lZHJpdmVyOiBhdGgKZGV2 LmF0aC4wLiVsb2NhdGlvbjogc2xvdD0wIGZ1bmN0aW9uPTAgaGFuZGxlPVxfU0JfLlBDSTAu UDBQMy5XTEFOCmRldi5hdGguMC4lcG5waW5mbzogdmVuZG9yPTB4MTY4YyBkZXZpY2U9MHgw MDFjIHN1YnZlbmRvcj0weDE2OGMgc3ViZGV2aWNlPTB4MDAzNSBjbGFzcz0weDAyMDAwMApk ZXYuYXRoLjAuJXBhcmVudDogcGNpMgpkZXYuYXRoLjAuc21vb3RoaW5nX3JhdGU6IDk1CmRl di5hdGguMC5zYW1wbGVfcmF0ZTogMTAKZGV2LmF0aC4wLmNvdW50cnljb2RlOiAwCmRldi5h dGguMC5yZWdkb21haW46IDEwMwpkZXYuYXRoLjAuc2xvdHRpbWU6IDIwCmRldi5hdGguMC5h Y2t0aW1lb3V0OiA0OApkZXYuYXRoLjAuY3RzdGltZW91dDogNDgKZGV2LmF0aC4wLnNvZnRs ZWQ6IDAKZGV2LmF0aC4wLmxlZHBpbjogMApkZXYuYXRoLjAubGVkb246IDAKZGV2LmF0aC4w LmxlZGlkbGU6IDI3MDAKZGV2LmF0aC4wLnR4YW50ZW5uYTogMApkZXYuYXRoLjAucnhhbnRl bm5hOiAyCmRldi5hdGguMC5kaXZlcnNpdHk6IDEKZGV2LmF0aC4wLnR4aW50cnBlcmlvZDog NQpkZXYuYXRoLjAuZGlhZzogMApkZXYuYXRoLjAudHBzY2FsZTogMApkZXYuYXRoLjAudHBj OiAwCmRldi5hdGguMC50cGFjazogNjMKZGV2LmF0aC4wLnRwY3RzOiA2MwpkZXYuYXRoLjAu cmZzaWxlbnQ6IDEKZGV2LmF0aC4wLnJma2lsbDogMQpkZXYuYXRoLjAubW9ucGFzczogMjQK ZGV2LmF0aC4wLndha2U6IDAKZGV2LnJlLjAuJWRlc2M6IFJlYWxUZWsgODE2OC84MTY4Qi84 MTY4Qy84MTY4Q1AvODE2OEQvODExMUIvODExMUMvODExMUNQIFBDSWUgR2lnYWJpdCBFdGhl cm5ldApkZXYucmUuMC4lZHJpdmVyOiByZQpkZXYucmUuMC4lbG9jYXRpb246IHNsb3Q9MCBm dW5jdGlvbj0wIGhhbmRsZT1cX1NCXy5QQ0kwLlAwUDYuR0xBTgpkZXYucmUuMC4lcG5waW5m bzogdmVuZG9yPTB4MTBlYyBkZXZpY2U9MHg4MTY4IHN1YnZlbmRvcj0weDE3YWEgc3ViZGV2 aWNlPTB4MjEwOCBjbGFzcz0weDAyMDAwMApkZXYucmUuMC4lcGFyZW50OiBwY2kxMgpkZXYu cmUuMC53YWtlOiAwCmRldi5taWlidXMuMC4lZGVzYzogTUlJIGJ1cwpkZXYubWlpYnVzLjAu JWRyaXZlcjogbWlpYnVzCmRldi5taWlidXMuMC4lcGFyZW50OiByZTAKZGV2LnJnZXBoeS4w LiVkZXNjOiBSVEw4MTY5Uy84MTEwUy84MjExQiBtZWRpYSBpbnRlcmZhY2UKZGV2LnJnZXBo eS4wLiVkcml2ZXI6IHJnZXBoeQpkZXYucmdlcGh5LjAuJWxvY2F0aW9uOiBwaHlubz0xCmRl di5yZ2VwaHkuMC4lcG5waW5mbzogb3VpPTB4NzMyIG1vZGVsPTB4MTEgcmV2PTB4MgpkZXYu cmdlcGh5LjAuJXBhcmVudDogbWlpYnVzMApkZXYuZndvaGNpLjAuJWRlc2M6IDEzOTQgT3Bl biBIb3N0IENvbnRyb2xsZXIgSW50ZXJmYWNlCmRldi5md29oY2kuMC4lZHJpdmVyOiBmd29o Y2kKZGV2LmZ3b2hjaS4wLiVsb2NhdGlvbjogc2xvdD0wIGZ1bmN0aW9uPTAgaGFuZGxlPVxf U0JfLlBDSTAuUDBQOC5DQlVTCmRldi5md29oY2kuMC4lcG5waW5mbzogdmVuZG9yPTB4MTE4 MCBkZXZpY2U9MHgwODMyIHN1YnZlbmRvcj0weDE3YWEgc3ViZGV2aWNlPTB4MjEwOSBjbGFz cz0weDBjMDAxMApkZXYuZndvaGNpLjAuJXBhcmVudDogcGNpMTMKZGV2LmZpcmV3aXJlLjAu JWRlc2M6IElFRUUxMzk0KEZpcmVXaXJlKSBidXMKZGV2LmZpcmV3aXJlLjAuJWRyaXZlcjog ZmlyZXdpcmUKZGV2LmZpcmV3aXJlLjAuJXBhcmVudDogZndvaGNpMApkZXYuZndlLjAuJWRl c2M6IEV0aGVybmV0IG92ZXIgRmlyZVdpcmUKZGV2LmZ3ZS4wLiVkcml2ZXI6IGZ3ZQpkZXYu ZndlLjAuJXBhcmVudDogZmlyZXdpcmUwCmRldi5md2lwLjAuJWRlc2M6IElQIG92ZXIgRmly ZVdpcmUKZGV2LmZ3aXAuMC4lZHJpdmVyOiBmd2lwCmRldi5md2lwLjAuJXBhcmVudDogZmly ZXdpcmUwCmRldi5zYnAuMC4lZGVzYzogU0JQLTIvU0NTSSBvdmVyIEZpcmVXaXJlCmRldi5z YnAuMC4lZHJpdmVyOiBzYnAKZGV2LnNicC4wLiVwYXJlbnQ6IGZpcmV3aXJlMApkZXYuZGNv bnNfY3JvbS4wLiVkZXNjOiBkY29ucyBjb25maWd1cmF0aW9uIFJPTQpkZXYuZGNvbnNfY3Jv bS4wLiVkcml2ZXI6IGRjb25zX2Nyb20KZGV2LmRjb25zX2Nyb20uMC4lcGFyZW50OiBmaXJl d2lyZTAKZGV2LmlzYWIuMC4lZGVzYzogUENJLUlTQSBicmlkZ2UKZGV2LmlzYWIuMC4lZHJp dmVyOiBpc2FiCmRldi5pc2FiLjAuJWxvY2F0aW9uOiBzbG90PTMxIGZ1bmN0aW9uPTAgaGFu ZGxlPVxfU0JfLlBDSTAuU0JSRwpkZXYuaXNhYi4wLiVwbnBpbmZvOiB2ZW5kb3I9MHg4MDg2 IGRldmljZT0weDI5MTkgc3VidmVuZG9yPTB4MTdhYSBzdWJkZXZpY2U9MHgyMGY2IGNsYXNz PTB4MDYwMTAwCmRldi5pc2FiLjAuJXBhcmVudDogcGNpMApkZXYuaXNhLjAuJWRlc2M6IElT QSBidXMKZGV2LmlzYS4wLiVkcml2ZXI6IGlzYQpkZXYuaXNhLjAuJXBhcmVudDogaXNhYjAK ZGV2LmF0YXBjaS4wLiVkZXNjOiBJbnRlbCBBSENJIGNvbnRyb2xsZXIKZGV2LmF0YXBjaS4w LiVkcml2ZXI6IGF0YXBjaQpkZXYuYXRhcGNpLjAuJWxvY2F0aW9uOiBzbG90PTMxIGZ1bmN0 aW9uPTIgaGFuZGxlPVxfU0JfLlBDSTAuSURFMApkZXYuYXRhcGNpLjAuJXBucGluZm86IHZl bmRvcj0weDgwODYgZGV2aWNlPTB4MjkyOSBzdWJ2ZW5kb3I9MHgxN2FhIHN1YmRldmljZT0w eDIwZjggY2xhc3M9MHgwMTA2MDEKZGV2LmF0YXBjaS4wLiVwYXJlbnQ6IHBjaTAKZGV2LmF0 YS4yLiVkZXNjOiBBVEEgY2hhbm5lbCAwCmRldi5hdGEuMi4lZHJpdmVyOiBhdGEKZGV2LmF0 YS4yLiVwYXJlbnQ6IGF0YXBjaTAKZGV2LmF0YS4zLiVkZXNjOiBBVEEgY2hhbm5lbCAxCmRl di5hdGEuMy4lZHJpdmVyOiBhdGEKZGV2LmF0YS4zLiVwYXJlbnQ6IGF0YXBjaTAKZGV2LmF0 YS40LiVkZXNjOiBBVEEgY2hhbm5lbCAyCmRldi5hdGEuNC4lZHJpdmVyOiBhdGEKZGV2LmF0 YS40LiVwYXJlbnQ6IGF0YXBjaTAKZGV2LmF0YS41LiVkZXNjOiBBVEEgY2hhbm5lbCAzCmRl di5hdGEuNS4lZHJpdmVyOiBhdGEKZGV2LmF0YS41LiVwYXJlbnQ6IGF0YXBjaTAKZGV2LmF0 YS42LiVkZXNjOiBBVEEgY2hhbm5lbCA0CmRldi5hdGEuNi4lZHJpdmVyOiBhdGEKZGV2LmF0 YS42LiVwYXJlbnQ6IGF0YXBjaTAKZGV2LmF0YS43LiVkZXNjOiBBVEEgY2hhbm5lbCA1CmRl di5hdGEuNy4lZHJpdmVyOiBhdGEKZGV2LmF0YS43LiVwYXJlbnQ6IGF0YXBjaTAKZGV2LmF0 YS4wLiVkcml2ZXI6IGF0YQpkZXYuYXRhLjAuJXBhcmVudDogaXNhMApkZXYuYXRhLjEuJWRy aXZlcjogYXRhCmRldi5hdGEuMS4lcGFyZW50OiBpc2EwCmRldi5hY3BpX2J1dHRvbi4wLiVk ZXNjOiBTbGVlcCBCdXR0b24KZGV2LmFjcGlfYnV0dG9uLjAuJWRyaXZlcjogYWNwaV9idXR0 b24KZGV2LmFjcGlfYnV0dG9uLjAuJWxvY2F0aW9uOiBoYW5kbGU9XF9TQl8uU0xQQgpkZXYu YWNwaV9idXR0b24uMC4lcG5waW5mbzogX0hJRD1QTlAwQzBFIF9VSUQ9MApkZXYuYWNwaV9i dXR0b24uMC4lcGFyZW50OiBhY3BpMApkZXYuYWNwaV9idXR0b24uMC53YWtlOiAxCmRldi5h Y3BpX2xpZC4wLiVkZXNjOiBDb250cm9sIE1ldGhvZCBMaWQgU3dpdGNoCmRldi5hY3BpX2xp ZC4wLiVkcml2ZXI6IGFjcGlfbGlkCmRldi5hY3BpX2xpZC4wLiVsb2NhdGlvbjogaGFuZGxl PVxfU0JfLkxJRF8KZGV2LmFjcGlfbGlkLjAuJXBucGluZm86IF9ISUQ9UE5QMEMwRCBfVUlE PTAKZGV2LmFjcGlfbGlkLjAuJXBhcmVudDogYWNwaTAKZGV2LmFjcGlfdHouMC4lZGVzYzog VGhlcm1hbCBab25lCmRldi5hY3BpX3R6LjAuJWRyaXZlcjogYWNwaV90egpkZXYuYWNwaV90 ei4wLiVsb2NhdGlvbjogaGFuZGxlPVxfVFpfLlRIUk0KZGV2LmFjcGlfdHouMC4lcG5waW5m bzogX0hJRD1ub25lIF9VSUQ9MApkZXYuYWNwaV90ei4wLiVwYXJlbnQ6IGFjcGkwCmRldi5h Y3BpX2FjYWQuMC4lZGVzYzogQUMgQWRhcHRlcgpkZXYuYWNwaV9hY2FkLjAuJWRyaXZlcjog YWNwaV9hY2FkCmRldi5hY3BpX2FjYWQuMC4lbG9jYXRpb246IGhhbmRsZT1cX1NCXy5QQ0kw LkFDMF8KZGV2LmFjcGlfYWNhZC4wLiVwbnBpbmZvOiBfSElEPUFDUEkwMDAzIF9VSUQ9MApk ZXYuYWNwaV9hY2FkLjAuJXBhcmVudDogYWNwaTAKZGV2LmJhdHRlcnkuMC4lZGVzYzogQUNQ SSBDb250cm9sIE1ldGhvZCBCYXR0ZXJ5CmRldi5iYXR0ZXJ5LjAuJWRyaXZlcjogYmF0dGVy eQpkZXYuYmF0dGVyeS4wLiVsb2NhdGlvbjogaGFuZGxlPVxfU0JfLlBDSTAuQkFUMApkZXYu YmF0dGVyeS4wLiVwbnBpbmZvOiBfSElEPVBOUDBDMEEgX1VJRD0wCmRldi5iYXR0ZXJ5LjAu JXBhcmVudDogYWNwaTAKZGV2LmF0cGljLjAuJWRlc2M6IEFUIGludGVycnVwdCBjb250cm9s bGVyCmRldi5hdHBpYy4wLiVkcml2ZXI6IGF0cGljCmRldi5hdHBpYy4wLiVsb2NhdGlvbjog aGFuZGxlPVxfU0JfLlBDSTAuU0JSRy5QSUNfCmRldi5hdHBpYy4wLiVwbnBpbmZvOiBfSElE PVBOUDAwMDAgX1VJRD0wCmRldi5hdHBpYy4wLiVwYXJlbnQ6IGFjcGkwCmRldi5hdGRtYS4w LiVkZXNjOiBBVCBETUEgY29udHJvbGxlcgpkZXYuYXRkbWEuMC4lZHJpdmVyOiBhdGRtYQpk ZXYuYXRkbWEuMC4lbG9jYXRpb246IGhhbmRsZT1cX1NCXy5QQ0kwLlNCUkcuRE1BRApkZXYu YXRkbWEuMC4lcG5waW5mbzogX0hJRD1QTlAwMjAwIF9VSUQ9MApkZXYuYXRkbWEuMC4lcGFy ZW50OiBhY3BpMApkZXYuYXR0aW1lci4wLiVkZXNjOiBBVCB0aW1lcgpkZXYuYXR0aW1lci4w LiVkcml2ZXI6IGF0dGltZXIKZGV2LmF0dGltZXIuMC4lbG9jYXRpb246IGhhbmRsZT1cX1NC Xy5QQ0kwLlNCUkcuVE1SXwpkZXYuYXR0aW1lci4wLiVwbnBpbmZvOiBfSElEPVBOUDAxMDAg X1VJRD0wCmRldi5hdHRpbWVyLjAuJXBhcmVudDogYWNwaTAKZGV2LmF0dGltZXIuMS4lZGVz YzogQVQgcmVhbHRpbWUgY2xvY2sKZGV2LmF0dGltZXIuMS4lZHJpdmVyOiBhdHRpbWVyCmRl di5hdHRpbWVyLjEuJWxvY2F0aW9uOiBoYW5kbGU9XF9TQl8uUENJMC5TQlJHLlJUQzAKZGV2 LmF0dGltZXIuMS4lcG5waW5mbzogX0hJRD1QTlAwQjAwIF9VSUQ9MApkZXYuYXR0aW1lci4x LiVwYXJlbnQ6IGFjcGkwCmRldi5hdGtiZGMuMC4lZGVzYzogS2V5Ym9hcmQgY29udHJvbGxl ciAoaTgwNDIpCmRldi5hdGtiZGMuMC4lZHJpdmVyOiBhdGtiZGMKZGV2LmF0a2JkYy4wLiVs b2NhdGlvbjogaGFuZGxlPVxfU0JfLlBDSTAuU0JSRy5QUzJLCmRldi5hdGtiZGMuMC4lcG5w aW5mbzogX0hJRD1QTlAwMzAzIF9VSUQ9MApkZXYuYXRrYmRjLjAuJXBhcmVudDogYWNwaTAK ZGV2LmF0a2JkLjAuJWRlc2M6IEFUIEtleWJvYXJkCmRldi5hdGtiZC4wLiVkcml2ZXI6IGF0 a2JkCmRldi5hdGtiZC4wLiVwYXJlbnQ6IGF0a2JkYzAKZGV2LnBzbWNwbnAuMC4lZGVzYzog UFMvMiBtb3VzZSBwb3J0CmRldi5wc21jcG5wLjAuJWRyaXZlcjogcHNtY3BucApkZXYucHNt Y3BucC4wLiVsb2NhdGlvbjogaGFuZGxlPVxfU0JfLlBDSTAuU0JSRy5QUzJNCmRldi5wc21j cG5wLjAuJXBucGluZm86IF9ISUQ9TEVOMDAxMyBfVUlEPTAKZGV2LnBzbWNwbnAuMC4lcGFy ZW50OiBhY3BpMApkZXYucHNtLjAuJWRlc2M6IFBTLzIgTW91c2UKZGV2LnBzbS4wLiVkcml2 ZXI6IHBzbQpkZXYucHNtLjAuJXBhcmVudDogYXRrYmRjMApkZXYubnB4aXNhLjAuJWRlc2M6 IExlZ2FjeSBJU0EgY29wcm9jZXNzb3Igc3VwcG9ydApkZXYubnB4aXNhLjAuJWRyaXZlcjog bnB4aXNhCmRldi5ucHhpc2EuMC4lbG9jYXRpb246IGhhbmRsZT1cX1NCXy5QQ0kwLlNCUkcu Q09QUgpkZXYubnB4aXNhLjAuJXBucGluZm86IF9ISUQ9UE5QMEMwNCBfVUlEPTAKZGV2Lm5w eGlzYS4wLiVwYXJlbnQ6IGFjcGkwCmRldi5jcHUuMC4lZGVzYzogQUNQSSBDUFUKZGV2LmNw dS4wLiVkcml2ZXI6IGNwdQpkZXYuY3B1LjAuJWxvY2F0aW9uOiBoYW5kbGU9XF9QUl8uUDAw MQpkZXYuY3B1LjAuJXBucGluZm86IF9ISUQ9bm9uZSBfVUlEPTAKZGV2LmNwdS4wLiVwYXJl bnQ6IGFjcGkwCmRldi5jcHUuMC5mcmVxOiAxMjAwCmRldi5jcHUuMC5mcmVxX2xldmVsczog MTgwMC8zNTAwMCAxNTc1LzMwNjI1IDEzNTAvMjYyNTAgMTIwMC8xNjAwMCAxMDUwLzE0MDAw IDkwMC8xMjAwMCA3NTAvMTAwMDAgNjAwLzgwMDAgNDUwLzYwMDAgMzAwLzQwMDAgMTUwLzIw MDAKZGV2LmNwdS4wLmN4X3N1cHBvcnRlZDogQzEvMCBDMi8xMApkZXYuY3B1LjAuY3hfbG93 ZXN0OiBDMQpkZXYuY3B1LjAuY3hfdXNhZ2U6IDEwMC4wMCUgMC4wMCUKZGV2LmNwdS4xLiVk ZXNjOiBBQ1BJIENQVQpkZXYuY3B1LjEuJWRyaXZlcjogY3B1CmRldi5jcHUuMS4lbG9jYXRp b246IGhhbmRsZT1cX1BSXy5DUFUwCmRldi5jcHUuMS4lcG5waW5mbzogX0hJRD1ub25lIF9V SUQ9MApkZXYuY3B1LjEuJXBhcmVudDogYWNwaTAKZGV2LmNwdS4xLmN4X3N1cHBvcnRlZDog QzEvMCBDMi8xMApkZXYuY3B1LjEuY3hfbG93ZXN0OiBDMQpkZXYuY3B1LjEuY3hfdXNhZ2U6 IDEwMC4wMCUgMC4wMCUKZGV2LmFjcGlfcGVyZi4wLiVkcml2ZXI6IGFjcGlfcGVyZgpkZXYu YWNwaV9wZXJmLjAuJXBhcmVudDogY3B1MApkZXYuZXN0LjAuJWRlc2M6IEVuaGFuY2VkIFNw ZWVkU3RlcCBGcmVxdWVuY3kgQ29udHJvbApkZXYuZXN0LjAuJWRyaXZlcjogZXN0CmRldi5l c3QuMC4lcGFyZW50OiBjcHUwCmRldi5lc3QuMC5mcmVxX3NldHRpbmdzOiAxODAwLzM1MDAw IDEyMDAvMTYwMDAKZGV2LmNwdWZyZXEuMC4lZHJpdmVyOiBjcHVmcmVxCmRldi5jcHVmcmVx LjAuJXBhcmVudDogY3B1MApkZXYuY3B1ZnJlcS4xLiVkcml2ZXI6IGNwdWZyZXEKZGV2LmNw dWZyZXEuMS4lcGFyZW50OiBjcHUxCmRldi5wNHRjYy4wLiVkZXNjOiBDUFUgRnJlcXVlbmN5 IFRoZXJtYWwgQ29udHJvbApkZXYucDR0Y2MuMC4lZHJpdmVyOiBwNHRjYwpkZXYucDR0Y2Mu MC4lcGFyZW50OiBjcHUwCmRldi5wNHRjYy4wLmZyZXFfc2V0dGluZ3M6IDEwMDAwLy0xIDg3 NTAvLTEgNzUwMC8tMSA2MjUwLy0xIDUwMDAvLTEgMzc1MC8tMSAyNTAwLy0xIDEyNTAvLTEK ZGV2LnA0dGNjLjEuJWRlc2M6IENQVSBGcmVxdWVuY3kgVGhlcm1hbCBDb250cm9sCmRldi5w NHRjYy4xLiVkcml2ZXI6IHA0dGNjCmRldi5wNHRjYy4xLiVwYXJlbnQ6IGNwdTEKZGV2LnA0 dGNjLjEuZnJlcV9zZXR0aW5nczogMTAwMDAvLTEgODc1MC8tMSA3NTAwLy0xIDYyNTAvLTEg NTAwMC8tMSAzNzUwLy0xIDI1MDAvLTEgMTI1MC8tMQpkZXYuYXBpYy4wLiVkZXNjOiBBUElD IHJlc291cmNlcwpkZXYuYXBpYy4wLiVkcml2ZXI6IGFwaWMKZGV2LmFwaWMuMC4lcGFyZW50 OiBuZXh1czAKZGV2LnBtdGltZXIuMC4lZHJpdmVyOiBwbXRpbWVyCmRldi5wbXRpbWVyLjAu JXBhcmVudDogaXNhMApkZXYub3JtLjAuJWRlc2M6IElTQSBPcHRpb24gUk9NCmRldi5vcm0u MC4lZHJpdmVyOiBvcm0KZGV2Lm9ybS4wLiVwbnBpbmZvOiBwbnBpZD1PUk0wMDAwCmRldi5v cm0uMC4lcGFyZW50OiBpc2EwCmRldi5zYy4wLiVkZXNjOiBTeXN0ZW0gY29uc29sZQpkZXYu c2MuMC4lZHJpdmVyOiBzYwpkZXYuc2MuMC4lcGFyZW50OiBpc2EwCmRldi5zaW8uMC4lZHJp dmVyOiBzaW8KZGV2LnNpby4wLiVwYXJlbnQ6IGlzYTAKZGV2LnZnYS4wLiVkZXNjOiBHZW5l cmljIElTQSBWR0EKZGV2LnZnYS4wLiVkcml2ZXI6IHZnYQpkZXYudmdhLjAuJXBhcmVudDog aXNhMApkZXYuYWQuNC4lZGVzYzogRlVKSVRTVSBNSFoyMTYwQkggRzEvMDA4NDAwMEEKZGV2 LmFkLjQuJWRyaXZlcjogYWQKZGV2LmFkLjQuJXBhcmVudDogYXRhMgpkZXYuc3ViZGlzay40 LiVkcml2ZXI6IHN1YmRpc2sKZGV2LnN1YmRpc2suNC4lcGFyZW50OiBhZDQKZGV2LmFjZC4w LiVkZXNjOiBEVkQvQ0RSVyBVSkRBNzgyL1ZCMjMKZGV2LmFjZC4wLiVkcml2ZXI6IGFjZApk ZXYuYWNkLjAuJXBhcmVudDogYXRhMwpkZXYucGNtLjAuJWRlc2M6IEhEQSBDb25leGFudCBD WDIwNTYxIChIZXJtb3NhKSBQQ00gIzAgQW5hbG9nCmRldi5wY20uMC4lZHJpdmVyOiBwY20K ZGV2LnBjbS4wLiVwYXJlbnQ6IGhkYWMwCmRldi5wY20uMC5wbGF5LnZjaGFuczogMQpkZXYu cGNtLjAucGxheS52Y2hhbnJhdGU6IDQ4MDAwCmRldi5wY20uMC5wbGF5LnZjaGFuZm9ybWF0 OiBzMTZsZQpkZXYucGNtLjAucmVjLnZjaGFuczogMQpkZXYucGNtLjAucmVjLnZjaGFucmF0 ZTogNDgwMDAKZGV2LnBjbS4wLnJlYy52Y2hhbmZvcm1hdDogczE2bGUKZGV2LnBjbS4wLmJ1 ZmZlcnNpemU6IDE2Mzg0CmRldi5wY20uMS4lZGVzYzogSERBIENvbmV4YW50IENYMjA1NjEg KEhlcm1vc2EpIFBDTSAjMSBBbmFsb2cKZGV2LnBjbS4xLiVkcml2ZXI6IHBjbQpkZXYucGNt LjEuJXBhcmVudDogaGRhYzAKZGV2LnBjbS4xLnBsYXkudmNoYW5zOiAxCmRldi5wY20uMS5w bGF5LnZjaGFucmF0ZTogNDgwMDAKZGV2LnBjbS4xLnBsYXkudmNoYW5mb3JtYXQ6IHMxNmxl CmRldi5wY20uMS5yZWMudmNoYW5zOiAxCmRldi5wY20uMS5yZWMudmNoYW5yYXRlOiA0ODAw MApkZXYucGNtLjEucmVjLnZjaGFuZm9ybWF0OiBzMTZsZQpkZXYucGNtLjEuYnVmZmVyc2l6 ZTogMTYzODQKZGV2LnBjbS4yLiVkZXNjOiBIREEgSW50ZWwgRzQ1IEhETUkgUENNICMwIERp Z2l0YWwKZGV2LnBjbS4yLiVkcml2ZXI6IHBjbQpkZXYucGNtLjIuJXBhcmVudDogaGRhYzAK ZGV2LnBjbS4yLnBsYXkudmNoYW5zOiAxCmRldi5wY20uMi5wbGF5LnZjaGFucmF0ZTogNDgw MDAKZGV2LnBjbS4yLnBsYXkudmNoYW5mb3JtYXQ6IHMxNmxlCmRldi5wY20uMi5idWZmZXJz aXplOiAxNjM4NApocHRtdi5zdGF0dXM6IFJvY2tldFJBSUQgMTgyeCBTQVRBIENvbnRyb2xs ZXIgZHJpdmVyIFZlcnNpb24gdjEuMTIKCg== --------------050905040006050702000601 Content-Type: text/plain; name="Xorg.0.log" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="Xorg.0.log" ClguT3JnIFggU2VydmVyIDEuNi4wClJlbGVhc2UgRGF0ZTogMjAwOS0yLTI1ClggUHJvdG9j b2wgVmVyc2lvbiAxMSwgUmV2aXNpb24gMApCdWlsZCBPcGVyYXRpbmcgU3lzdGVtOiBGcmVl QlNEIDcuMi1QUkVSRUxFQVNFIGkzODYgCkN1cnJlbnQgT3BlcmF0aW5nIFN5c3RlbTogRnJl ZUJTRCBsaXgueGlsIDcuMi1QUkVSRUxFQVNFIEZyZWVCU0QgNy4yLVBSRVJFTEVBU0UgIzE6 IFR1ZSBBcHIgIDcgMTI6Mzk6NDYgQ1NUIDIwMDkgICAgIHJvb3RAbHZtLm5ldDovdXNyL29i ai91c3Ivc3JjL3N5cy9rZXJuZWwgaTM4NgpCdWlsZCBEYXRlOiAwNyBBcHJpbCAyMDA5ICAw Mjo1OTozMlBNCiAKCUJlZm9yZSByZXBvcnRpbmcgcHJvYmxlbXMsIGNoZWNrIGh0dHA6Ly93 aWtpLngub3JnCgl0byBtYWtlIHN1cmUgdGhhdCB5b3UgaGF2ZSB0aGUgbGF0ZXN0IHZlcnNp b24uCk1hcmtlcnM6ICgtLSkgcHJvYmVkLCAoKiopIGZyb20gY29uZmlnIGZpbGUsICg9PSkg ZGVmYXVsdCBzZXR0aW5nLAoJKCsrKSBmcm9tIGNvbW1hbmQgbGluZSwgKCEhKSBub3RpY2Us IChJSSkgaW5mb3JtYXRpb25hbCwKCShXVykgd2FybmluZywgKEVFKSBlcnJvciwgKE5JKSBu b3QgaW1wbGVtZW50ZWQsICg/PykgdW5rbm93bi4KKD09KSBMb2cgZmlsZTogIi92YXIvbG9n L1hvcmcuMC5sb2ciLCBUaW1lOiBXZWQgQXByICA4IDE5OjQ1OjAyIDIwMDkKKD09KSBVc2lu ZyBjb25maWcgZmlsZTogIi9ldGMvWDExL3hvcmcuY29uZiIKKD09KSBTZXJ2ZXJMYXlvdXQg Ilgub3JnIENvbmZpZ3VyZWQiCigqKikgfC0tPlNjcmVlbiAiU2NyZWVuMCIgKDApCigqKikg fCAgIHwtLT5Nb25pdG9yICJNb25pdG9yMCIKKCoqKSB8ICAgfC0tPkRldmljZSAiQ2FyZDAi CigqKikgfC0tPklucHV0IERldmljZSAiTW91c2UwIgooKiopIHwtLT5JbnB1dCBEZXZpY2Ug IktleWJvYXJkMCIKKCoqKSBPcHRpb24gIlN0YW5kYnlUaW1lIiAiMTAiCigqKikgT3B0aW9u ICJTdXNwZW5kVGltZSIgIjEwIgooKiopIE9wdGlvbiAiT2ZmVGltZSIgIjEwIgooPT0pIEF1 dG9tYXRpY2FsbHkgYWRkaW5nIGRldmljZXMKKD09KSBBdXRvbWF0aWNhbGx5IGVuYWJsaW5n IGRldmljZXMKKCoqKSBGb250UGF0aCBzZXQgdG86CgkvdXNyL2xvY2FsL2xpYi9YMTEvZm9u dHMvbWlzYy8sCgkvdXNyL2xvY2FsL2xpYi9YMTEvZm9udHMvVFRGLywKCS91c3IvbG9jYWwv bGliL1gxMS9mb250cy9PVEYsCgkvdXNyL2xvY2FsL2xpYi9YMTEvZm9udHMvVHlwZTEvLAoJ L3Vzci9sb2NhbC9saWIvWDExL2ZvbnRzLzEwMGRwaS8sCgkvdXNyL2xvY2FsL2xpYi9YMTEv Zm9udHMvNzVkcGkvLAoJL3Vzci9sb2NhbC9saWIvWDExL2ZvbnRzL21pc2MvLAoJL3Vzci9s b2NhbC9saWIvWDExL2ZvbnRzL1RURi8sCgkvdXNyL2xvY2FsL2xpYi9YMTEvZm9udHMvT1RG LAoJL3Vzci9sb2NhbC9saWIvWDExL2ZvbnRzL1R5cGUxLywKCS91c3IvbG9jYWwvbGliL1gx MS9mb250cy8xMDBkcGkvLAoJL3Vzci9sb2NhbC9saWIvWDExL2ZvbnRzLzc1ZHBpLywKCWJ1 aWx0LWlucwooKiopIE1vZHVsZVBhdGggc2V0IHRvICIvdXNyL2xvY2FsL2xpYi94b3JnL21v ZHVsZXMiCigqKikgRXh0ZW5zaW9uICJDb21wb3NpdGUiIGlzIGVuYWJsZWQKKFdXKSBBbGxv d0VtcHR5SW5wdXQgaXMgb24sIGRldmljZXMgdXNpbmcgZHJpdmVycyAna2JkJywgJ21vdXNl JyBvciAndm1tb3VzZScgd2lsbCBiZSBkaXNhYmxlZC4KKFdXKSBEaXNhYmxpbmcgTW91c2Uw CihXVykgRGlzYWJsaW5nIEtleWJvYXJkMAooSUkpIExvYWRlciBtYWdpYzogMHg2YTAKKElJ KSBNb2R1bGUgQUJJIHZlcnNpb25zOgoJWC5PcmcgQU5TSSBDIEVtdWxhdGlvbjogMC40CglY Lk9yZyBWaWRlbyBEcml2ZXI6IDUuMAoJWC5PcmcgWElucHV0IGRyaXZlciA6IDQuMAoJWC5P cmcgU2VydmVyIEV4dGVuc2lvbiA6IDIuMAooSUkpIExvYWRlciBydW5uaW5nIG9uIGZyZWVi c2QKKC0tKSBVc2luZyBzeXNjb25zIGRyaXZlciB3aXRoIFggc3VwcG9ydCAodmVyc2lvbiAy LjApCigtLSkgdXNpbmcgVlQgbnVtYmVyIDkKCigtLSkgUENJOiooMEAwOjI6MCkgSW50ZWwg Q29ycG9yYXRpb24gTW9iaWxlIDQgU2VyaWVzIENoaXBzZXQgSW50ZWdyYXRlZCBHcmFwaGlj cyBDb250cm9sbGVyIHJldiA3LCBNZW0gQCAweDgwMDAwMDAwLzQxOTQzMDQsIDB4ZDAwMDAw MDAvMjY4NDM1NDU2LCBJL08gQCAweDAwMDA1YzAwLzgsIEJJT1MgQCAweD8/Pz8/Pz8/LzY1 NTM2CigtLSkgUENJOiAoMEAwOjI6MSkgSW50ZWwgQ29ycG9yYXRpb24gTW9iaWxlIDQgU2Vy aWVzIENoaXBzZXQgSW50ZWdyYXRlZCBHcmFwaGljcyBDb250cm9sbGVyIHJldiA3CihJSSkg U3lzdGVtIHJlc291cmNlIHJhbmdlczoKCVswXSAtMQkwCTB4MDAwZjAwMDAgLSAweDAwMGZm ZmZmICgweDEwMDAwKSBNWFtCXQoJWzFdIC0xCTAJMHgwMDBjMDAwMCAtIDB4MDAwZWZmZmYg KDB4MzAwMDApIE1YW0JdCglbMl0gLTEJMAkweDAwMDAwMDAwIC0gMHgwMDA5ZmZmZiAoMHhh MDAwMCkgTVhbQl0KCVszXSAtMQkwCTB4MDAwMGZmZmYgLSAweDAwMDBmZmZmICgweDEpIElY W0JdCglbNF0gLTEJMAkweDAwMDAwMDAwIC0gMHgwMDAwMDBmZiAoMHgxMDApIElYW0JdCihJ SSkgImV4dG1vZCIgd2lsbCBiZSBsb2FkZWQuIFRoaXMgd2FzIGVuYWJsZWQgYnkgZGVmYXVs dCBhbmQgYWxzbyBzcGVjaWZpZWQgaW4gdGhlIGNvbmZpZyBmaWxlLgooSUkpICJkYmUiIHdp bGwgYmUgbG9hZGVkLiBUaGlzIHdhcyBlbmFibGVkIGJ5IGRlZmF1bHQgYW5kIGFsc28gc3Bl Y2lmaWVkIGluIHRoZSBjb25maWcgZmlsZS4KKElJKSAiZ2x4IiB3aWxsIGJlIGxvYWRlZC4g VGhpcyB3YXMgZW5hYmxlZCBieSBkZWZhdWx0IGFuZCBhbHNvIHNwZWNpZmllZCBpbiB0aGUg Y29uZmlnIGZpbGUuCihJSSkgInJlY29yZCIgd2lsbCBiZSBsb2FkZWQuIFRoaXMgd2FzIGVu YWJsZWQgYnkgZGVmYXVsdCBhbmQgYWxzbyBzcGVjaWZpZWQgaW4gdGhlIGNvbmZpZyBmaWxl LgooSUkpICJkcmkiIHdpbGwgYmUgbG9hZGVkLiBUaGlzIHdhcyBlbmFibGVkIGJ5IGRlZmF1 bHQgYW5kIGFsc28gc3BlY2lmaWVkIGluIHRoZSBjb25maWcgZmlsZS4KKElJKSAiZHJpMiIg d2lsbCBiZSBsb2FkZWQgYnkgZGVmYXVsdC4KKElJKSBMb2FkTW9kdWxlOiAiZ2x4IgooSUkp IExvYWRpbmcgL3Vzci9sb2NhbC9saWIveG9yZy9tb2R1bGVzL2V4dGVuc2lvbnMvL2xpYmds eC5zbwooSUkpIE1vZHVsZSBnbHg6IHZlbmRvcj0iWC5PcmcgRm91bmRhdGlvbiIKCWNvbXBp bGVkIGZvciAxLjYuMCwgbW9kdWxlIHZlcnNpb24gPSAxLjAuMAoJQUJJIGNsYXNzOiBYLk9y ZyBTZXJ2ZXIgRXh0ZW5zaW9uLCB2ZXJzaW9uIDIuMAooPT0pIEFJR0xYIGRpc2FibGVkCihJ SSkgTG9hZGluZyBleHRlbnNpb24gR0xYCihJSSkgTG9hZE1vZHVsZTogImRyaSIKKElJKSBM b2FkaW5nIC91c3IvbG9jYWwvbGliL3hvcmcvbW9kdWxlcy9leHRlbnNpb25zLy9saWJkcmku c28KKElJKSBNb2R1bGUgZHJpOiB2ZW5kb3I9IlguT3JnIEZvdW5kYXRpb24iCgljb21waWxl ZCBmb3IgMS42LjAsIG1vZHVsZSB2ZXJzaW9uID0gMS4wLjAKCUFCSSBjbGFzczogWC5Pcmcg U2VydmVyIEV4dGVuc2lvbiwgdmVyc2lvbiAyLjAKKElJKSBMb2FkaW5nIGV4dGVuc2lvbiBY RnJlZTg2LURSSQooSUkpIExvYWRNb2R1bGU6ICJleHRtb2QiCihJSSkgTG9hZGluZyAvdXNy L2xvY2FsL2xpYi94b3JnL21vZHVsZXMvZXh0ZW5zaW9ucy8vbGliZXh0bW9kLnNvCihJSSkg TW9kdWxlIGV4dG1vZDogdmVuZG9yPSJYLk9yZyBGb3VuZGF0aW9uIgoJY29tcGlsZWQgZm9y IDEuNi4wLCBtb2R1bGUgdmVyc2lvbiA9IDEuMC4wCglNb2R1bGUgY2xhc3M6IFguT3JnIFNl cnZlciBFeHRlbnNpb24KCUFCSSBjbGFzczogWC5PcmcgU2VydmVyIEV4dGVuc2lvbiwgdmVy c2lvbiAyLjAKKElJKSBMb2FkaW5nIGV4dGVuc2lvbiBNSVQtU0NSRUVOLVNBVkVSCihJSSkg TG9hZGluZyBleHRlbnNpb24gWEZyZWU4Ni1WaWRNb2RlRXh0ZW5zaW9uCihJSSkgTG9hZGlu ZyBleHRlbnNpb24gWEZyZWU4Ni1ER0EKKElJKSBMb2FkaW5nIGV4dGVuc2lvbiBEUE1TCihJ SSkgTG9hZGluZyBleHRlbnNpb24gWFZpZGVvCihJSSkgTG9hZGluZyBleHRlbnNpb24gWFZp ZGVvLU1vdGlvbkNvbXBlbnNhdGlvbgooSUkpIExvYWRpbmcgZXh0ZW5zaW9uIFgtUmVzb3Vy Y2UKKElJKSBMb2FkTW9kdWxlOiAicmVjb3JkIgooSUkpIExvYWRpbmcgL3Vzci9sb2NhbC9s aWIveG9yZy9tb2R1bGVzL2V4dGVuc2lvbnMvL2xpYnJlY29yZC5zbwooSUkpIE1vZHVsZSBy ZWNvcmQ6IHZlbmRvcj0iWC5PcmcgRm91bmRhdGlvbiIKCWNvbXBpbGVkIGZvciAxLjYuMCwg bW9kdWxlIHZlcnNpb24gPSAxLjEzLjAKCU1vZHVsZSBjbGFzczogWC5PcmcgU2VydmVyIEV4 dGVuc2lvbgoJQUJJIGNsYXNzOiBYLk9yZyBTZXJ2ZXIgRXh0ZW5zaW9uLCB2ZXJzaW9uIDIu MAooSUkpIExvYWRpbmcgZXh0ZW5zaW9uIFJFQ09SRAooSUkpIExvYWRNb2R1bGU6ICJkYmUi CihJSSkgTG9hZGluZyAvdXNyL2xvY2FsL2xpYi94b3JnL21vZHVsZXMvZXh0ZW5zaW9ucy8v bGliZGJlLnNvCihJSSkgTW9kdWxlIGRiZTogdmVuZG9yPSJYLk9yZyBGb3VuZGF0aW9uIgoJ Y29tcGlsZWQgZm9yIDEuNi4wLCBtb2R1bGUgdmVyc2lvbiA9IDEuMC4wCglNb2R1bGUgY2xh c3M6IFguT3JnIFNlcnZlciBFeHRlbnNpb24KCUFCSSBjbGFzczogWC5PcmcgU2VydmVyIEV4 dGVuc2lvbiwgdmVyc2lvbiAyLjAKKElJKSBMb2FkaW5nIGV4dGVuc2lvbiBET1VCTEUtQlVG RkVSCihJSSkgTG9hZE1vZHVsZTogInh0cmFwIgooV1cpIFdhcm5pbmcsIGNvdWxkbid0IG9w ZW4gbW9kdWxlIHh0cmFwCihJSSkgVW5sb2FkTW9kdWxlOiAieHRyYXAiCihFRSkgRmFpbGVk IHRvIGxvYWQgbW9kdWxlICJ4dHJhcCIgKG1vZHVsZSBkb2VzIG5vdCBleGlzdCwgMCkKKElJ KSBMb2FkTW9kdWxlOiAiZnJlZXR5cGUiCihXVykgV2FybmluZywgY291bGRuJ3Qgb3BlbiBt b2R1bGUgZnJlZXR5cGUKKElJKSBVbmxvYWRNb2R1bGU6ICJmcmVldHlwZSIKKEVFKSBGYWls ZWQgdG8gbG9hZCBtb2R1bGUgImZyZWV0eXBlIiAobW9kdWxlIGRvZXMgbm90IGV4aXN0LCAw KQooSUkpIExvYWRNb2R1bGU6ICJkcmkyIgooSUkpIExvYWRpbmcgL3Vzci9sb2NhbC9saWIv eG9yZy9tb2R1bGVzL2V4dGVuc2lvbnMvL2xpYmRyaTIuc28KKElJKSBNb2R1bGUgZHJpMjog dmVuZG9yPSJYLk9yZyBGb3VuZGF0aW9uIgoJY29tcGlsZWQgZm9yIDEuNi4wLCBtb2R1bGUg dmVyc2lvbiA9IDEuMC4wCglBQkkgY2xhc3M6IFguT3JnIFNlcnZlciBFeHRlbnNpb24sIHZl cnNpb24gMi4wCihJSSkgTG9hZGluZyBleHRlbnNpb24gRFJJMgooSUkpIExvYWRNb2R1bGU6 ICJpbnRlbCIKKElJKSBMb2FkaW5nIC91c3IvbG9jYWwvbGliL3hvcmcvbW9kdWxlcy9kcml2 ZXJzLy9pbnRlbF9kcnYuc28KKElJKSBNb2R1bGUgaW50ZWw6IHZlbmRvcj0iWC5PcmcgRm91 bmRhdGlvbiIKCWNvbXBpbGVkIGZvciAxLjYuMCwgbW9kdWxlIHZlcnNpb24gPSAyLjYuMwoJ TW9kdWxlIGNsYXNzOiBYLk9yZyBWaWRlbyBEcml2ZXIKCUFCSSBjbGFzczogWC5PcmcgVmlk ZW8gRHJpdmVyLCB2ZXJzaW9uIDUuMAooSUkpIGludGVsOiBEcml2ZXIgZm9yIEludGVsIElu dGVncmF0ZWQgR3JhcGhpY3MgQ2hpcHNldHM6IGk4MTAsCglpODEwLWRjMTAwLCBpODEwZSwg aTgxNSwgaTgzME0sIDg0NUcsIDg1MkdNLzg1NUdNLCA4NjVHLCA5MTVHLAoJRTcyMjEgKGk5 MTUpLCA5MTVHTSwgOTQ1RywgOTQ1R00sIDk0NUdNRSwgOTY1RywgRzM1LCA5NjVRLCA5NDZH WiwKCTk2NUdNLCA5NjVHTUUvR0xFLCBHMzMsIFEzNSwgUTMzLAoJTW9iaWxlIEludGVswq4g R000NSBFeHByZXNzIENoaXBzZXQsCglJbnRlbCBJbnRlZ3JhdGVkIEdyYXBoaWNzIERldmlj ZSwgRzQ1L0c0MywgUTQ1L1E0MywgRzQxCihJSSkgUHJpbWFyeSBEZXZpY2UgaXM6IFBDSSAw MEAwMDowMjowCihJSSkgcmVzb3VyY2UgcmFuZ2VzIGFmdGVyIHhmODZDbGFpbUZpeGVkUmVz b3VyY2VzKCkgY2FsbDoKCVswXSAtMQkwCTB4MDAwZjAwMDAgLSAweDAwMGZmZmZmICgweDEw MDAwKSBNWFtCXQoJWzFdIC0xCTAJMHgwMDBjMDAwMCAtIDB4MDAwZWZmZmYgKDB4MzAwMDAp IE1YW0JdCglbMl0gLTEJMAkweDAwMDAwMDAwIC0gMHgwMDA5ZmZmZiAoMHhhMDAwMCkgTVhb Ql0KCVszXSAtMQkwCTB4MDAwMGZmZmYgLSAweDAwMDBmZmZmICgweDEpIElYW0JdCglbNF0g LTEJMAkweDAwMDAwMDAwIC0gMHgwMDAwMDBmZiAoMHgxMDApIElYW0JdCihJSSkgcmVzb3Vy Y2UgcmFuZ2VzIGFmdGVyIHByb2Jpbmc6CglbMF0gLTEJMAkweDAwMGYwMDAwIC0gMHgwMDBm ZmZmZiAoMHgxMDAwMCkgTVhbQl0KCVsxXSAtMQkwCTB4MDAwYzAwMDAgLSAweDAwMGVmZmZm ICgweDMwMDAwKSBNWFtCXQoJWzJdIC0xCTAJMHgwMDAwMDAwMCAtIDB4MDAwOWZmZmYgKDB4 YTAwMDApIE1YW0JdCglbM10gMAkwCTB4MDAwYTAwMDAgLSAweDAwMGFmZmZmICgweDEwMDAw KSBNU1tCXQoJWzRdIDAJMAkweDAwMGIwMDAwIC0gMHgwMDBiN2ZmZiAoMHg4MDAwKSBNU1tC XQoJWzVdIDAJMAkweDAwMGI4MDAwIC0gMHgwMDBiZmZmZiAoMHg4MDAwKSBNU1tCXQoJWzZd IC0xCTAJMHgwMDAwZmZmZiAtIDB4MDAwMGZmZmYgKDB4MSkgSVhbQl0KCVs3XSAtMQkwCTB4 MDAwMDAwMDAgLSAweDAwMDAwMGZmICgweDEwMCkgSVhbQl0KCVs4XSAwCTAJMHgwMDAwMDNi MCAtIDB4MDAwMDAzYmIgKDB4YykgSVNbQl0KCVs5XSAwCTAJMHgwMDAwMDNjMCAtIDB4MDAw MDAzZGYgKDB4MjApIElTW0JdCihJSSkgTG9hZGluZyBzdWIgbW9kdWxlICJ2Z2FodyIKKElJ KSBMb2FkTW9kdWxlOiAidmdhaHciCihJSSkgTG9hZGluZyAvdXNyL2xvY2FsL2xpYi94b3Jn L21vZHVsZXMvL2xpYnZnYWh3LnNvCihJSSkgTW9kdWxlIHZnYWh3OiB2ZW5kb3I9IlguT3Jn IEZvdW5kYXRpb24iCgljb21waWxlZCBmb3IgMS42LjAsIG1vZHVsZSB2ZXJzaW9uID0gMC4x LjAKCUFCSSBjbGFzczogWC5PcmcgVmlkZW8gRHJpdmVyLCB2ZXJzaW9uIDUuMAooKiopIGlu dGVsKDApOiBEZXB0aCAyNCwgKC0tKSBmcmFtZWJ1ZmZlciBicHAgMzIKKD09KSBpbnRlbCgw KTogUkdCIHdlaWdodCA4ODgKKD09KSBpbnRlbCgwKTogRGVmYXVsdCB2aXN1YWwgaXMgVHJ1 ZUNvbG9yCihJSSkgaW50ZWwoMCk6IEludGVncmF0ZWQgR3JhcGhpY3MgQ2hpcHNldDogSW50 ZWwoUikgTW9iaWxlIEludGVswq4gR000NSBFeHByZXNzIENoaXBzZXQKKC0tKSBpbnRlbCgw KTogQ2hpcHNldDogIk1vYmlsZSBJbnRlbMKuIEdNNDUgRXhwcmVzcyBDaGlwc2V0IgooLS0p IGludGVsKDApOiBMaW5lYXIgZnJhbWVidWZmZXIgYXQgMHhEMDAwMDAwMAooLS0pIGludGVs KDApOiBJTyByZWdpc3RlcnMgYXQgYWRkciAweDgwMDAwMDAwCig9PSkgaW50ZWwoMCk6IFVz aW5nIEVYQSBmb3IgYWNjZWxlcmF0aW9uCihJSSkgaW50ZWwoMCk6IDIgZGlzcGxheSBwaXBl cyBhdmFpbGFibGUuCihJSSkgTG9hZGluZyBzdWIgbW9kdWxlICJkZGMiCihJSSkgTG9hZE1v ZHVsZTogImRkYyIKKElJKSBNb2R1bGUgImRkYyIgYWxyZWFkeSBidWlsdC1pbgooSUkpIExv YWRpbmcgc3ViIG1vZHVsZSAiaTJjIgooSUkpIExvYWRNb2R1bGU6ICJpMmMiCihJSSkgTW9k dWxlICJpMmMiIGFscmVhZHkgYnVpbHQtaW4KKElJKSBpbnRlbCgwKTogT3V0cHV0IFZHQSB1 c2luZyBtb25pdG9yIHNlY3Rpb24gTW9uaXRvcjEKKCoqKSBpbnRlbCgwKTogT3B0aW9uICJS aWdodE9mIiAiTFZEUyIKKElJKSBpbnRlbCgwKTogT3V0cHV0IExWRFMgdXNpbmcgbW9uaXRv ciBzZWN0aW9uIE1vbml0b3IwCigqKikgaW50ZWwoMCk6IE9wdGlvbiAiUG9zaXRpb24iICIw IDAiCihJSSkgaW50ZWwoMCk6IEkyQyBidXMgIkxWRFNERENfQyIgaW5pdGlhbGl6ZWQuCihJ SSkgaW50ZWwoMCk6IEF0dGVtcHRpbmcgdG8gZGV0ZXJtaW5lIHBhbmVsIGZpeGVkIG1vZGUu CihJSSkgaW50ZWwoMCk6IEkyQyBkZXZpY2UgIkxWRFNERENfQzpFLUVESUQgc2VnbWVudCBy ZWdpc3RlciIgcmVnaXN0ZXJlZCBhdCBhZGRyZXNzIDB4NjAuCihJSSkgaW50ZWwoMCk6IEky QyBkZXZpY2UgIkxWRFNERENfQzpkZGMyIiByZWdpc3RlcmVkIGF0IGFkZHJlc3MgMHhBMC4K KElJKSBpbnRlbCgwKTogRURJRCB2ZW5kb3IgIkxFTiIsIHByb2QgaWQgMTY0MzMKKElJKSBp bnRlbCgwKTogSTJDIGJ1cyAiU0RWT0NUUkxfRSBmb3IgU0RWT0IiIGluaXRpYWxpemVkLgoo SUkpIGludGVsKDApOiBJMkMgZGV2aWNlICJTRFZPQ1RSTF9FIGZvciBTRFZPQjpTRFZPIENv bnRyb2xsZXIgQiIgcmVnaXN0ZXJlZCBhdCBhZGRyZXNzIDB4NzAuCihJSSkgaW50ZWwoMCk6 IE5vIFNEVk8gZGV2aWNlIGZvdW5kIG9uIFNEVk9CCihJSSkgaW50ZWwoMCk6IEkyQyBkZXZp Y2UgIlNEVk9DVFJMX0UgZm9yIFNEVk9COlNEVk8gQ29udHJvbGxlciBCIiByZW1vdmVkLgoo SUkpIGludGVsKDApOiBJMkMgYnVzICJTRFZPQ1RSTF9FIGZvciBTRFZPQiIgcmVtb3ZlZC4K KElJKSBpbnRlbCgwKTogT3V0cHV0IEhETUktMSBoYXMgbm8gbW9uaXRvciBzZWN0aW9uCihJ SSkgaW50ZWwoMCk6IEkyQyBidXMgIkhETUlERENfQiIgaW5pdGlhbGl6ZWQuCihJSSkgaW50 ZWwoMCk6IEhETUkgb3V0cHV0IDEgZGV0ZWN0ZWQKKElJKSBpbnRlbCgwKTogT3V0cHV0IFRW IGhhcyBubyBtb25pdG9yIHNlY3Rpb24KKD09KSBpbnRlbCgwKTogV3JpdGUtY29tYmluaW5n IHJhbmdlICgweGEwMDAwLDB4MTAwMDApIHdhcyBhbHJlYWR5IGNsZWFyCihJSSkgaW50ZWwo MCk6IFJlc2l6YWJsZSBmcmFtZWJ1ZmZlcjogbm90IGF2YWlsYWJsZSAoMSAzKQooSUkpIGlu dGVsKDApOiBFRElEIHZlbmRvciAiTEVOIiwgcHJvZCBpZCAxNjQzMwooSUkpIGludGVsKDAp OiBPdXRwdXQgVkdBIGRpc2Nvbm5lY3RlZAooSUkpIGludGVsKDApOiBPdXRwdXQgTFZEUyBj b25uZWN0ZWQKKElJKSBpbnRlbCgwKTogT3V0cHV0IEhETUktMSBkaXNjb25uZWN0ZWQKKElJ KSBpbnRlbCgwKTogT3V0cHV0IFRWIGRpc2Nvbm5lY3RlZAooSUkpIGludGVsKDApOiBVc2lu ZyB1c2VyIHByZWZlcmVuY2UgZm9yIGluaXRpYWwgbW9kZXMKKElJKSBpbnRlbCgwKTogT3V0 cHV0IExWRFMgdXNpbmcgaW5pdGlhbCBtb2RlIDEyODB4ODAwCig9PSkgaW50ZWwoMCk6IFdy aXRlLWNvbWJpbmluZyByYW5nZSAoMHhhMDAwMCwweDEwMDAwKSB3YXMgYWxyZWFkeSBjbGVh cgooSUkpIGludGVsKDApOiBkZXRlY3RlZCA1MTIga0IgR1RULgooSUkpIGludGVsKDApOiBk ZXRlY3RlZCAzMjc2NCBrQiBzdG9sZW4gbWVtb3J5LgooPT0pIGludGVsKDApOiB2aWRlbyBv dmVybGF5IGtleSBzZXQgdG8gMHgxMDFmZQooPT0pIGludGVsKDApOiBXaWxsIG5vdCB0cnkg dG8gZW5hYmxlIHBhZ2UgZmxpcHBpbmcKKD09KSBpbnRlbCgwKTogVHJpcGxlIGJ1ZmZlcmlu ZyBkaXNhYmxlZAooPT0pIGludGVsKDApOiBVc2luZyBnYW1tYSBjb3JyZWN0aW9uICgxLjAs IDEuMCwgMS4wKQooPT0pIGludGVsKDApOiBEUEkgc2V0IHRvICg5NiwgOTYpCihJSSkgTG9h ZGluZyBzdWIgbW9kdWxlICJmYiIKKElJKSBMb2FkTW9kdWxlOiAiZmIiCihJSSkgTG9hZGlu ZyAvdXNyL2xvY2FsL2xpYi94b3JnL21vZHVsZXMvL2xpYmZiLnNvCihJSSkgTW9kdWxlIGZi OiB2ZW5kb3I9IlguT3JnIEZvdW5kYXRpb24iCgljb21waWxlZCBmb3IgMS42LjAsIG1vZHVs ZSB2ZXJzaW9uID0gMS4wLjAKCUFCSSBjbGFzczogWC5PcmcgQU5TSSBDIEVtdWxhdGlvbiwg dmVyc2lvbiAwLjQKKElJKSBMb2FkaW5nIHN1YiBtb2R1bGUgImV4YSIKKElJKSBMb2FkTW9k dWxlOiAiZXhhIgooSUkpIExvYWRpbmcgL3Vzci9sb2NhbC9saWIveG9yZy9tb2R1bGVzLy9s aWJleGEuc28KKElJKSBNb2R1bGUgZXhhOiB2ZW5kb3I9IlguT3JnIEZvdW5kYXRpb24iCglj b21waWxlZCBmb3IgMS42LjAsIG1vZHVsZSB2ZXJzaW9uID0gMi40LjAKCUFCSSBjbGFzczog WC5PcmcgVmlkZW8gRHJpdmVyLCB2ZXJzaW9uIDUuMAooSUkpIExvYWRpbmcgc3ViIG1vZHVs ZSAicmFtZGFjIgooSUkpIExvYWRNb2R1bGU6ICJyYW1kYWMiCihJSSkgTW9kdWxlICJyYW1k YWMiIGFscmVhZHkgYnVpbHQtaW4KKElJKSBpbnRlbCgwKTogQ29tcGFyaW5nIHJlZ3MgZnJv bSBzZXJ2ZXIgc3RhcnQgdXAgdG8gQWZ0ZXIgUHJlSW5pdAooV1cpIGludGVsKDApOiBSZWdp c3RlciAweDYxMjAwIChQUF9TVEFUVVMpIGNoYW5nZWQgZnJvbSAweGMwMDAwMDA4IHRvIDB4 ZDAwMDAwMGEKKFdXKSBpbnRlbCgwKTogUFBfU1RBVFVTIGJlZm9yZTogb24sIHJlYWR5LCBz ZXF1ZW5jaW5nIGlkbGUKKFdXKSBpbnRlbCgwKTogUFBfU1RBVFVTIGFmdGVyOiBvbiwgcmVh ZHksIHNlcXVlbmNpbmcgb24KKFdXKSBpbnRlbCgwKTogUmVnaXN0ZXIgMHg3MDAyNCAoUElQ RUFTVEFUKSBjaGFuZ2VkIGZyb20gMHgwMDAwMDAwMCB0byAweDAwMDAwMjA2CihXVykgaW50 ZWwoMCk6IFBJUEVBU1RBVCBiZWZvcmU6IHN0YXR1czoKKFdXKSBpbnRlbCgwKTogUElQRUFT VEFUIGFmdGVyOiBzdGF0dXM6IFZTWU5DX0lOVF9TVEFUVVMgU1ZCTEFOS19JTlRfU1RBVFVT IFZCTEFOS19JTlRfU1RBVFVTCihXVykgaW50ZWwoMCk6IFJlZ2lzdGVyIDB4NjgwODQgKFRW X0ZJTFRFUl9DVExfMikgY2hhbmdlZCBmcm9tIDB4MDAwMTJkMmQgdG8gMHgwMDAyODI4Mwoo V1cpIGludGVsKDApOiBSZWdpc3RlciAweDY4MDg4IChUVl9GSUxURVJfQ1RMXzMpIGNoYW5n ZWQgZnJvbSAweDAwMDA5Njk2IHRvIDB4MDAwMTQxNDEKKFdXKSBpbnRlbCgwKTogUmVnaXN0 ZXIgMHgzMjFiIChGQkNfRkVOQ0VfT0ZGKSBjaGFuZ2VkIGZyb20gMHg5NjAyNTgwMCB0byAw eGVjMDBjMDAwCig9PSkgRGVwdGggMjQgcGl4bWFwIGZvcm1hdCBpcyAzMiBicHAKKElJKSBk byBJIG5lZWQgUkFDPyAgTm8sIEkgZG9uJ3QuCihJSSkgcmVzb3VyY2UgcmFuZ2VzIGFmdGVy IHByZUluaXQ6CglbMF0gLTEJMAkweDAwMGYwMDAwIC0gMHgwMDBmZmZmZiAoMHgxMDAwMCkg TVhbQl0KCVsxXSAtMQkwCTB4MDAwYzAwMDAgLSAweDAwMGVmZmZmICgweDMwMDAwKSBNWFtC XQoJWzJdIC0xCTAJMHgwMDAwMDAwMCAtIDB4MDAwOWZmZmYgKDB4YTAwMDApIE1YW0JdCglb M10gMAkwCTB4MDAwYTAwMDAgLSAweDAwMGFmZmZmICgweDEwMDAwKSBNU1tCXShPcHJEKQoJ WzRdIDAJMAkweDAwMGIwMDAwIC0gMHgwMDBiN2ZmZiAoMHg4MDAwKSBNU1tCXShPcHJEKQoJ WzVdIDAJMAkweDAwMGI4MDAwIC0gMHgwMDBiZmZmZiAoMHg4MDAwKSBNU1tCXShPcHJEKQoJ WzZdIC0xCTAJMHgwMDAwZmZmZiAtIDB4MDAwMGZmZmYgKDB4MSkgSVhbQl0KCVs3XSAtMQkw CTB4MDAwMDAwMDAgLSAweDAwMDAwMGZmICgweDEwMCkgSVhbQl0KCVs4XSAwCTAJMHgwMDAw MDNiMCAtIDB4MDAwMDAzYmIgKDB4YykgSVNbQl0oT3ByVSkKCVs5XSAwCTAJMHgwMDAwMDNj MCAtIDB4MDAwMDAzZGYgKDB4MjApIElTW0JdKE9wclUpCihJSSkgaW50ZWwoMCk6IEtlcm5l bCByZXBvcnRlZCAyNDExNTIgdG90YWwsIDAgdXNlZAooSUkpIGludGVsKDApOiBJODMwQ2hl Y2tBdmFpbGFibGVNZW1vcnk6IDk2NDYwOCBrQiBhdmFpbGFibGUKKFdXKSBpbnRlbCgwKTog RFJJMiByZXF1aXJlcyBVWEEKZHJtT3BlbkRldmljZTogbm9kZSBuYW1lIGlzIC9kZXYvZHJp L2NhcmQwCmRybU9wZW5EZXZpY2U6IG9wZW4gcmVzdWx0IGlzIDksIChPSykKZHJtT3BlbkRl dmljZTogbm9kZSBuYW1lIGlzIC9kZXYvZHJpL2NhcmQwCmRybU9wZW5EZXZpY2U6IG9wZW4g cmVzdWx0IGlzIDksIChPSykKZHJtT3BlbkJ5QnVzaWQ6IFNlYXJjaGluZyBmb3IgQnVzSUQg cGNpOjAwMDA6MDA6MDIuMApkcm1PcGVuRGV2aWNlOiBub2RlIG5hbWUgaXMgL2Rldi9kcmkv Y2FyZDAKZHJtT3BlbkRldmljZTogb3BlbiByZXN1bHQgaXMgOSwgKE9LKQpkcm1PcGVuQnlC dXNpZDogZHJtT3Blbk1pbm9yIHJldHVybnMgOQpkcm1PcGVuQnlCdXNpZDogZHJtR2V0QnVz aWQgcmVwb3J0cyBwY2k6MDAwMDowMDowMi4wCihJSSkgW2RybV0gRFJNIGludGVyZmFjZSB2 ZXJzaW9uIDEuMgooSUkpIFtkcm1dIERSTSBvcGVuIG1hc3RlciBzdWNjZWVkZWQuCihJSSkg aW50ZWwoMCk6IFtkcm1dIFVzaW5nIHRoZSBEUk0gbG9jayBTQVJFQSBhbHNvIGZvciBkcmF3 YWJsZXMuCihJSSkgaW50ZWwoMCk6IFtkcm1dIGZyYW1lYnVmZmVyIG1hcHBlZCBieSBkZHgg ZHJpdmVyCihJSSkgaW50ZWwoMCk6IFtkcm1dIGFkZGVkIDEgcmVzZXJ2ZWQgY29udGV4dCBm b3Iga2VybmVsCihJSSkgaW50ZWwoMCk6IFggY29udGV4dCBoYW5kbGUgPSAweDEKKElJKSBp bnRlbCgwKTogW2RybV0gaW5zdGFsbGVkIERSTSBzaWduYWwgaGFuZGxlcgooKiopIGludGVs KDApOiBGcmFtZWJ1ZmZlciBjb21wcmVzc2lvbiBlbmFibGVkCigqKikgaW50ZWwoMCk6IFRp bGluZyBlbmFibGVkCig9PSkgaW50ZWwoMCk6IFZpZGVvUmFtOiAyNjIxNDQgS0IKKElJKSBp bnRlbCgwKTogQXR0ZW1wdGluZyBtZW1vcnkgYWxsb2NhdGlvbiB3aXRoIHRpbGVkIGJ1ZmZl cnMuCihJSSkgaW50ZWwoMCk6IFRpbGVkIGFsbG9jYXRpb24gc3VjY2Vzc2Z1bC4KKElJKSBp bnRlbCgwKTogW2RybV0gUmVnaXN0ZXJzID0gMHg4MDAwMDAwMAooSUkpIGludGVsKDApOiBb ZHJtXSByaW5nIGJ1ZmZlciA9IDB4ZDAwMDAwMDAKKElJKSBpbnRlbCgwKTogW2RybV0gbWFw cGVkIGZyb250IGJ1ZmZlciBhdCAweGQwMmZlMDAwLCBoYW5kbGUgPSAweGQwMmZlMDAwCihJ SSkgaW50ZWwoMCk6IFtkcm1dIG1hcHBlZCBiYWNrIGJ1ZmZlciBhdCAweGQ0OTc4MDAwLCBo YW5kbGUgPSAweGQ0OTc4MDAwCihJSSkgaW50ZWwoMCk6IFtkcm1dIG1hcHBlZCBkZXB0aCBi dWZmZXIgYXQgMHhkNTczODAwMCwgaGFuZGxlID0gMHhkNTczODAwMAooSUkpIGludGVsKDAp OiBbZHJtXSBtYXBwZWQgY2xhc3NpYyB0ZXh0dXJlcyBhdCAweGQ2NGY4MDAwLCBoYW5kbGUg PSAweGQ2NGY4MDAwCihJSSkgaW50ZWwoMCk6IFtkcm1dIEluaXRpYWxpemVkIGtlcm5lbCBh Z3AgaGVhcCBtYW5hZ2VyLCAzMzU1NDQzMgooSUkpIGludGVsKDApOiBbZHJpXSB2aXN1YWwg Y29uZmlncyBpbml0aWFsaXplZAooSUkpIGludGVsKDApOiBQYWdlIEZsaXBwaW5nIGRpc2Fi bGVkCihJSSkgaW50ZWwoMCk6IHZnYUhXR2V0SU9CYXNlOiBod3AtPklPQmFzZSBpcyAweDAz ZDAsIGh3cC0+UElPT2Zmc2V0IGlzIDB4MDAwMAooPT0pIGludGVsKDApOiBXcml0ZS1jb21i aW5pbmcgcmFuZ2UgKDB4YTAwMDAsMHgxMDAwMCkgd2FzIGFscmVhZHkgY2xlYXIKKElJKSBF WEEoMCk6IE9mZnNjcmVlbiBwaXhtYXAgYXJlYSBvZiA0MzI1Mzc2MCBieXRlcwooSUkpIEVY QSgwKTogRHJpdmVyIHJlZ2lzdGVyZWQgc3VwcG9ydCBmb3IgdGhlIGZvbGxvd2luZyBvcGVy YXRpb25zOgooSUkpICAgICAgICAgU29saWQKKElJKSAgICAgICAgIENvcHkKKElJKSAgICAg ICAgIENvbXBvc2l0ZSAoUkVOREVSIGFjY2VsZXJhdGlvbikKKD09KSBpbnRlbCgwKTogQmFj a2luZyBzdG9yZSBkaXNhYmxlZAooPT0pIGludGVsKDApOiBTaWxrZW4gbW91c2UgZW5hYmxl ZAooSUkpIGludGVsKDApOiBJbml0aWFsaXppbmcgSFcgQ3Vyc29yCihJSSkgaW50ZWwoMCk6 IFtEUkldIGluc3RhbGxhdGlvbiBjb21wbGV0ZQooSUkpIGludGVsKDApOiB4Zjg2QmluZEdB UlRNZW1vcnk6IGJpbmQga2V5IDggYXQgMHgwMWZmZjAwMCAocGdvZmZzZXQgODE5MSkKKElJ KSBpbnRlbCgwKTogeGY4NkJpbmRHQVJUTWVtb3J5OiBiaW5kIGtleSA5IGF0IDB4MDIwMzYw MDAgKHBnb2Zmc2V0IDgyNDYpCihJSSkgaW50ZWwoMCk6IHhmODZCaW5kR0FSVE1lbW9yeTog YmluZCBrZXkgMTAgYXQgMHgwNDk3NjAwMCAocGdvZmZzZXQgMTg4MDYpCihJSSkgaW50ZWwo MCk6IHhmODZCaW5kR0FSVE1lbW9yeTogYmluZCBrZXkgMTEgYXQgMHgwNDk3NzAwMCAocGdv ZmZzZXQgMTg4MDcpCihJSSkgaW50ZWwoMCk6IHhmODZCaW5kR0FSVE1lbW9yeTogYmluZCBr ZXkgMTIgYXQgMHgwNDk3ODAwMCAocGdvZmZzZXQgMTg4MDgpCihJSSkgaW50ZWwoMCk6IHhm ODZCaW5kR0FSVE1lbW9yeTogYmluZCBrZXkgMTMgYXQgMHgwNTczODAwMCAocGdvZmZzZXQg MjIzMjgpCihJSSkgaW50ZWwoMCk6IHhmODZCaW5kR0FSVE1lbW9yeTogYmluZCBrZXkgMTQg YXQgMHgwNjRmODAwMCAocGdvZmZzZXQgMjU4NDgpCihJSSkgaW50ZWwoMCk6IEZpeGVkIG1l bW9yeSBhbGxvY2F0aW9uIGxheW91dDoKKElJKSBpbnRlbCgwKTogMHgwMDAwMDAwMC0weDAw MDFmZmZmOiByaW5nIGJ1ZmZlciAoMTI4IGtCKQooSUkpIGludGVsKDApOiAweDAwMDIwMDAw LTB4MDAxZjNmZmY6IGNvbXByZXNzZWQgZnJhbWUgYnVmZmVyICgxODcyIGtCLCAweDAwMDAw MDAwM2UwMjAwMDAgcGh5c2ljYWwKKQooSUkpIGludGVsKDApOiAweDAwMWY0MDAwLTB4MDAx ZmRmZmY6IEhXIGN1cnNvcnMgKDQwIGtCKQooSUkpIGludGVsKDApOiAweDAwMWZlMDAwLTB4 MDAyZmRmZmY6IGZha2UgYnVmbWdyICgxMDI0IGtCKQooSUkpIGludGVsKDApOiAweDAwMmZl MDAwLTB4MDIwMzVmZmY6IGZyb250IGJ1ZmZlciAoMjk5MjAga0IpCihJSSkgaW50ZWwoMCk6 IDB4MDFmZmYwMDA6ICAgICAgICAgICAgZW5kIG9mIHN0b2xlbiBtZW1vcnkKKElJKSBpbnRl bCgwKTogMHgwMjAzNjAwMC0weDA0OTc1ZmZmOiBleGEgb2Zmc2NyZWVuICg0MjI0MCBrQikK KElJKSBpbnRlbCgwKTogMHgwNDk3NjAwMC0weDA0OTc2ZmZmOiBwb3dlciBjb250ZXh0ICg0 IGtCKQooSUkpIGludGVsKDApOiAweDA0OTc3MDAwLTB4MDQ5NzdmZmY6IEhXIHN0YXR1cyAo NCBrQikKKElJKSBpbnRlbCgwKTogMHgwNDk3ODAwMC0weDA1NzM3ZmZmOiBiYWNrIGJ1ZmZl ciAoMTQwODAga0IpCihJSSkgaW50ZWwoMCk6IDB4MDU3MzgwMDAtMHgwNjRmN2ZmZjogZGVw dGggYnVmZmVyICgxNDA4MCBrQikKKElJKSBpbnRlbCgwKTogMHgwNjRmODAwMC0weDA4NGY3 ZmZmOiBjbGFzc2ljIHRleHR1cmVzICgzMjc2OCBrQikKKElJKSBpbnRlbCgwKTogMHgxMDAw MDAwMDogICAgICAgICAgICBlbmQgb2YgYXBlcnR1cmUKKFdXKSBpbnRlbCgwKTogRVNSIGlz IDB4MDAwMDAwMTAsIHBhZ2UgdGFibGUgZXJyb3IKKFdXKSBpbnRlbCgwKTogUEdUQkxfRVIg aXMgMHgwMDEwMDAwMCwgQ1MgaW5zdHJ1Y3Rpb24gR1RUIFBURQooV1cpIGludGVsKDApOiBF eGlzdGluZyBlcnJvcnMgZm91bmQgaW4gaGFyZHdhcmUgc3RhdGUuCihJSSkgaW50ZWwoMCk6 IHVzaW5nIFNTQyByZWZlcmVuY2UgY2xvY2sgb2YgMTAwIE1IegooSUkpIGludGVsKDApOiBT ZWxlY3Rpbmcgc3RhbmRhcmQgMTggYml0IFRNRFMgcGl4ZWwgZm9ybWF0LgooSUkpIGludGVs KDApOiBPdXRwdXQgY29uZmlndXJhdGlvbjoKKElJKSBpbnRlbCgwKTogICBQaXBlIEEgaXMg b2ZmCihJSSkgaW50ZWwoMCk6ICAgRGlzcGxheSBwbGFuZSBBIGlzIG5vdyBkaXNhYmxlZCBh bmQgY29ubmVjdGVkIHRvIHBpcGUgQS4KKElJKSBpbnRlbCgwKTogICBQaXBlIEIgaXMgb24K KElJKSBpbnRlbCgwKTogICBEaXNwbGF5IHBsYW5lIEIgaXMgbm93IGVuYWJsZWQgYW5kIGNv bm5lY3RlZCB0byBwaXBlIEIuCihJSSkgaW50ZWwoMCk6ICAgT3V0cHV0IFZHQSBpcyBjb25u ZWN0ZWQgdG8gcGlwZSBub25lCihJSSkgaW50ZWwoMCk6ICAgT3V0cHV0IExWRFMgaXMgY29u bmVjdGVkIHRvIHBpcGUgQgooSUkpIGludGVsKDApOiAgIE91dHB1dCBIRE1JLTEgaXMgY29u bmVjdGVkIHRvIHBpcGUgbm9uZQooSUkpIGludGVsKDApOiAgIE91dHB1dCBUViBpcyBjb25u ZWN0ZWQgdG8gcGlwZSBub25lCihJSSkgaW50ZWwoMCk6IFtkcm1dIGRtYSBjb250cm9sIGlu aXRpYWxpemVkLCB1c2luZyBJUlEgMTYKKElJKSBpbnRlbCgwKTogUmFuZFIgMS4yIGVuYWJs ZWQsIGlnbm9yZSB0aGUgZm9sbG93aW5nIFJhbmRSIGRpc2FibGVkIG1lc3NhZ2UuCigqKikg T3B0aW9uICJkcG1zIgooKiopIGludGVsKDApOiBEUE1TIGVuYWJsZWQKKD09KSBpbnRlbCgw KTogSW50ZWwgWHZNQyBkZWNvZGVyIGRpc2FibGVkCihJSSkgaW50ZWwoMCk6IFNldCB1cCB0 ZXh0dXJlZCB2aWRlbwooSUkpIGludGVsKDApOiBkaXJlY3QgcmVuZGVyaW5nOiBYRjg2RFJJ IEVuYWJsZWQKKFdXKSBpbnRlbCgwKTogT3B0aW9uICJQcmVmZXJlZE1vZGUiIGlzIG5vdCB1 c2VkCihXVykgaW50ZWwoMCk6IE9wdGlvbiAiUG9zaXRpb24iIGlzIG5vdCB1c2VkCigtLSkg UmFuZFIgZGlzYWJsZWQKKElJKSBJbml0aWFsaXppbmcgYnVpbHQtaW4gZXh0ZW5zaW9uIEdl bmVyaWMgRXZlbnQgRXh0ZW5zaW9uCihJSSkgSW5pdGlhbGl6aW5nIGJ1aWx0LWluIGV4dGVu c2lvbiBTSEFQRQooSUkpIEluaXRpYWxpemluZyBidWlsdC1pbiBleHRlbnNpb24gTUlULVNI TQooSUkpIEluaXRpYWxpemluZyBidWlsdC1pbiBleHRlbnNpb24gWElucHV0RXh0ZW5zaW9u CihJSSkgSW5pdGlhbGl6aW5nIGJ1aWx0LWluIGV4dGVuc2lvbiBYVEVTVAooSUkpIEluaXRp YWxpemluZyBidWlsdC1pbiBleHRlbnNpb24gQklHLVJFUVVFU1RTCihJSSkgSW5pdGlhbGl6 aW5nIGJ1aWx0LWluIGV4dGVuc2lvbiBTWU5DCihJSSkgSW5pdGlhbGl6aW5nIGJ1aWx0LWlu IGV4dGVuc2lvbiBYS0VZQk9BUkQKKElJKSBJbml0aWFsaXppbmcgYnVpbHQtaW4gZXh0ZW5z aW9uIFhDLU1JU0MKKElJKSBJbml0aWFsaXppbmcgYnVpbHQtaW4gZXh0ZW5zaW9uIFhJTkVS QU1BCihJSSkgSW5pdGlhbGl6aW5nIGJ1aWx0LWluIGV4dGVuc2lvbiBYRklYRVMKKElJKSBJ bml0aWFsaXppbmcgYnVpbHQtaW4gZXh0ZW5zaW9uIFJFTkRFUgooSUkpIEluaXRpYWxpemlu ZyBidWlsdC1pbiBleHRlbnNpb24gUkFORFIKKElJKSBJbml0aWFsaXppbmcgYnVpbHQtaW4g ZXh0ZW5zaW9uIENPTVBPU0lURQooSUkpIEluaXRpYWxpemluZyBidWlsdC1pbiBleHRlbnNp b24gREFNQUdFCihJSSkgQUlHTFg6IExvYWRlZCBhbmQgaW5pdGlhbGl6ZWQgL3Vzci9sb2Nh bC9saWIvZHJpL3N3cmFzdF9kcmkuc28KKElJKSBHTFg6IEluaXRpYWxpemVkIERSSVNXUkFT VCBHTCBwcm92aWRlciBmb3Igc2NyZWVuIDAKKElJKSBpbnRlbCgwKTogU2V0dGluZyBzY3Jl ZW4gcGh5c2ljYWwgc2l6ZSB0byAzMDMgeCAxOTAKKElJKSBjb25maWcvaGFsOiBBZGRpbmcg aW5wdXQgZGV2aWNlIFBTLzIgTW91c2UKKElJKSBMb2FkTW9kdWxlOiAibW91c2UiCihJSSkg TG9hZGluZyAvdXNyL2xvY2FsL2xpYi94b3JnL21vZHVsZXMvaW5wdXQvL21vdXNlX2Rydi5z bwooSUkpIE1vZHVsZSBtb3VzZTogdmVuZG9yPSJYLk9yZyBGb3VuZGF0aW9uIgoJY29tcGls ZWQgZm9yIDEuNi4wLCBtb2R1bGUgdmVyc2lvbiA9IDEuNC4wCglNb2R1bGUgY2xhc3M6IFgu T3JnIFhJbnB1dCBEcml2ZXIKCUFCSSBjbGFzczogWC5PcmcgWElucHV0IGRyaXZlciwgdmVy c2lvbiA0LjAKKCoqKSBQUy8yIE1vdXNlOiBEZXZpY2U6ICIvZGV2L3BzbTAiCig9PSkgUFMv MiBNb3VzZTogUHJvdG9jb2w6ICJBdXRvIgooKiopIFBTLzIgTW91c2U6IGFsd2F5cyByZXBv cnRzIGNvcmUgZXZlbnRzCigqKikgT3B0aW9uICJEZXZpY2UiICIvZGV2L3BzbTAiCig9PSkg UFMvMiBNb3VzZTogRW11bGF0ZTNCdXR0b25zLCBFbXVsYXRlM1RpbWVvdXQ6IDUwCigqKikg UFMvMiBNb3VzZTogWkF4aXNNYXBwaW5nOiBidXR0b25zIDQgYW5kIDUKKCoqKSBQUy8yIE1v dXNlOiBCdXR0b25zOiA5CigqKikgUFMvMiBNb3VzZTogU2Vuc2l0aXZpdHk6IDEKKElJKSBY SU5QVVQ6IEFkZGluZyBleHRlbmRlZCBpbnB1dCBkZXZpY2UgIlBTLzIgTW91c2UiICh0eXBl OiBNT1VTRSkKKCoqKSBQUy8yIE1vdXNlOiAoYWNjZWwpIGtlZXBpbmcgYWNjZWxlcmF0aW9u IHNjaGVtZSAxCigqKikgUFMvMiBNb3VzZTogKGFjY2VsKSBmaWx0ZXIgY2hhaW4gcHJvZ3Jl c3Npb246IDIuMDAKKCoqKSBQUy8yIE1vdXNlOiAoYWNjZWwpIGZpbHRlciBzdGFnZSAwOiAy MC4wMCBtcwooKiopIFBTLzIgTW91c2U6IChhY2NlbCkgc2V0IGFjY2VsZXJhdGlvbiBwcm9m aWxlIDAKKElJKSBQUy8yIE1vdXNlOiBTZXR1cEF1dG86IGh3LmlmdHlwZSBpcyAzLCBody5t b2RlbCBpcyAwCihJSSkgUFMvMiBNb3VzZTogU2V0dXBBdXRvOiBwcm90b2NvbCBpcyBQUy8y CihJSSkgUFMvMiBNb3VzZTogcHMyRW5hYmxlRGF0YVJlcG9ydGluZzogc3VjY2VlZGVkCihJ SSkgY29uZmlnL2hhbDogQWRkaW5nIGlucHV0IGRldmljZSBBVCBLZXlib2FyZAooSUkpIExv YWRNb2R1bGU6ICJrYmQiCihJSSkgTG9hZGluZyAvdXNyL2xvY2FsL2xpYi94b3JnL21vZHVs ZXMvaW5wdXQvL2tiZF9kcnYuc28KKElJKSBNb2R1bGUga2JkOiB2ZW5kb3I9IlguT3JnIEZv dW5kYXRpb24iCgljb21waWxlZCBmb3IgMS42LjAsIG1vZHVsZSB2ZXJzaW9uID0gMS4zLjIK CU1vZHVsZSBjbGFzczogWC5PcmcgWElucHV0IERyaXZlcgoJQUJJIGNsYXNzOiBYLk9yZyBY SW5wdXQgZHJpdmVyLCB2ZXJzaW9uIDQuMAooKiopIEFUIEtleWJvYXJkOiBhbHdheXMgcmVw b3J0cyBjb3JlIGV2ZW50cwooKiopIE9wdGlvbiAiUHJvdG9jb2wiICJzdGFuZGFyZCIKKCoq KSBBVCBLZXlib2FyZDogUHJvdG9jb2w6IHN0YW5kYXJkCigqKikgT3B0aW9uICJBdXRvUmVw ZWF0IiAiNTAwIDMwIgooKiopIE9wdGlvbiAiWGtiUnVsZXMiICJ4b3JnIgooKiopIEFUIEtl eWJvYXJkOiBYa2JSdWxlczogInhvcmciCigqKikgT3B0aW9uICJYa2JNb2RlbCIgInBjMTA1 IgooKiopIEFUIEtleWJvYXJkOiBYa2JNb2RlbDogInBjMTA1IgooKiopIE9wdGlvbiAiWGti TGF5b3V0IiAidXMiCigqKikgQVQgS2V5Ym9hcmQ6IFhrYkxheW91dDogInVzIgooKiopIE9w dGlvbiAiQ3VzdG9tS2V5Y29kZXMiICJvZmYiCigqKikgQVQgS2V5Ym9hcmQ6IEN1c3RvbUtl eWNvZGVzIGRpc2FibGVkCihJSSkgWElOUFVUOiBBZGRpbmcgZXh0ZW5kZWQgaW5wdXQgZGV2 aWNlICJBVCBLZXlib2FyZCIgKHR5cGU6IEtFWUJPQVJEKQpleGFDb3B5RGlydHk6IFBlbmRp bmcgZGFtYWdlIHJlZ2lvbiBlbXB0eSEK --------------050905040006050702000601-- From owner-freebsd-stable@FreeBSD.ORG Thu Apr 9 13:39:18 2009 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 25C86106564A for ; Thu, 9 Apr 2009 13:39:18 +0000 (UTC) (envelope-from gavin@FreeBSD.org) Received: from mail-gw1.york.ac.uk (mail-gw1.york.ac.uk [144.32.128.246]) by mx1.freebsd.org (Postfix) with ESMTP id AC5338FC15 for ; Thu, 9 Apr 2009 13:39:17 +0000 (UTC) (envelope-from gavin@FreeBSD.org) Received: from mail-gw6.york.ac.uk (mail-gw6.york.ac.uk [144.32.129.26]) by mail-gw1.york.ac.uk (8.13.6/8.13.6) with ESMTP id n39DdF37007919; Thu, 9 Apr 2009 14:39:15 +0100 (BST) 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 1LruTL-0000Iz-4u; Thu, 09 Apr 2009 14:39:15 +0100 Received: from buffy.york.ac.uk (localhost [127.0.0.1]) by buffy.york.ac.uk (8.14.3/8.14.3) with ESMTP id n39DdEs9014139; Thu, 9 Apr 2009 14:39:14 +0100 (BST) (envelope-from gavin@FreeBSD.org) Received: (from ga9@localhost) by buffy.york.ac.uk (8.14.3/8.14.3/Submit) id n39DdEuP014138; Thu, 9 Apr 2009 14:39:14 +0100 (BST) (envelope-from gavin@FreeBSD.org) X-Authentication-Warning: buffy.york.ac.uk: ga9 set sender to gavin@FreeBSD.org using -f From: Gavin Atkinson To: GOD In-Reply-To: <49DD95EB.9040606@gmail.com> References: <49DD95EB.9040606@gmail.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Thu, 09 Apr 2009 14:39:14 +0100 Message-Id: <1239284354.29188.37.camel@buffy.york.ac.uk> Mime-Version: 1.0 X-Mailer: Evolution 2.22.2 FreeBSD GNOME Team Port X-York-MailScanner: Found to be clean X-York-MailScanner-From: gavin@freebsd.org Cc: freebsd-stable@FreeBSD.org Subject: Re: system report 7.2 beta1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 13:39:18 -0000 On Thu, 2009-04-09 at 14:30 +0800, GOD wrote: > I trace all of 7.* version on my laptop. But some thing is always a > problem! > 1. The acpi is not well supported. I try acpiconf -s 3 , the system > will > die. I take it you are running i386 then? Can you try compiling SMP support out of your kernel, disabling the second core in the BIOS, and seeing if you have the same problem? If suspend starts to work then the problem is that i386 suspend isn't properly implemented for SMP. Recently, amd64 gained suspend/resume and works on SMP. Although this support hasn't been merged back to 7.x, it might be worthwhile booting the 8.0 amd64 live CD and seeing if that works for you - if it does, there's probably more chance the amd64 support will appear in 7.x before the i386 suspend support, so maybe you could consider moving to amd64. > 2 The ath0 wifi support, I test and nerver find it can transfer with > more than 5MB per second rate. > 3 The big problem of my laptop is the intel video card, xorg eat up half > of my memory,and it's very slow moving windows . I'm afraid I can't help with these, other than to say that wireless support in 8.x is much better than in 7.x. Indeed, given how close 8.0 is to being released (a few months away, I believe), it may be best either to wait, or to consider upgrading your system to -CURRENT amd64 and seeing if your problems are already resolved. Gavin From owner-freebsd-stable@FreeBSD.ORG Thu Apr 9 14:32:07 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C7F19106566C; Thu, 9 Apr 2009 14:32:07 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.16.84]) by mx1.freebsd.org (Postfix) with ESMTP id 734A38FC16; Thu, 9 Apr 2009 14:32:07 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1LrvIT-000DAG-JT; Thu, 09 Apr 2009 17:32:05 +0300 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: Ivan Voras In-reply-to: References: Comments: In-reply-to Ivan Voras message dated "Thu, 09 Apr 2009 13:44:39 +0200." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 09 Apr 2009 17:32:05 +0300 From: Danny Braniss Message-ID: Cc: freebsd-stable@freebsd.org Subject: Re: FreeBSD and iSCSI for disks. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 14:32:09 -0000 > Danny Braniss wrote: > >> This is an OpenPGP/MIME signed message (RFC 2440 and 3156) > >> --------------enig90DADA8437A99D893FB775F8 > >> Content-Type: text/plain; charset=3DUTF-8 > >> Content-Transfer-Encoding: quoted-printable > >> > >> Danny Braniss wrote: > >>>> Garance A Drosihn wrote: > >>>>> Some friends of mine are looking at the new "DroboPro", which makes= > a=3D > >>>>> lot of disk space available via iSCSI (in addition to firewire 800)= > , > >>>>> and they were wondering how well iSCSI works with FreeBSD. I haven= > 't=3D > >>>>> paid attention to iSCSI support. Is there anyone using it heavily > >>>>> for disk-storage under FreeBSD? Has there been much changed for > >>>>> iSCSI support in the 8.x branch, or is 7.x support working fine? > >>>> I suppose you are interested in the "client" (initiator) side of iSC= > SI=3D > >>>> support. It hasn't changed much between 7.x and 8.x but there are > >>>> apparently some announcements of a newer version: > >>>> > >>>> http://lists.freebsd.org/pipermail/freebsd-scsi/2009-March/003834.ht= > ml=3D > >>>> I can't find any more information on it. > >>> the latest is in: > >>> http://www.cs.huji.ac.il/~danny/ftp/freebsd/iscsi-2.1.1.tar.gz > >> Thanks! > >> > >> Is there anything in particular you'd like to get tested in the new > >> version, any significant changes or improvements? > > mainly fixed some bugs, and some code cleanup. > >=20 > > give it a spin, and let me know what target you are testing. > > btw, the default tag opening is a bit concervative (1), you might want = > to > > change it to somewhat larger, say 64 or 128. > > Hi, > > "camcontrol tags" hangs: > > Apr 9 15:36:36 terminator kernel: da3 at iscsi0 bus 0 target 1 lun 0 > Apr 9 15:36:36 terminator kernel: da3: Fixed > Direct Access SCSI-5 device > Apr 9 15:36:38 terminator kernel: (da2:iscsi0:0:0:0): lost device > Apr 9 15:36:38 terminator kernel: (da2:iscsi0:0:0:0): removing device en= > try > terminator:~ivoras/temp/sbin/iscontrol# ls /dev/da* > /dev/da0 /dev/da0s1 /dev/da0s1a /dev/da0s1b /dev/da0s1c > /dev/da1 /dev/da3 > terminator:~ivoras/temp/sbin/iscontrol# camcontrol tags da3 > > > The configuration is: > > target0 { > targetaddress =3D 161.53.72.65 > targetname =3D iqn.2007-09.jp.ne.peach:disk1 > tags =3D 16 > } > Q: what kernel? Q: what target? btw, without the camcontrol tags, is it working? danny From owner-freebsd-stable@FreeBSD.ORG Thu Apr 9 15:01:35 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 112C01065675 for ; Thu, 9 Apr 2009 15:01:35 +0000 (UTC) (envelope-from ivoras@gmail.com) Received: from mail-ew0-f171.google.com (mail-ew0-f171.google.com [209.85.219.171]) by mx1.freebsd.org (Postfix) with ESMTP id 919E68FC16 for ; Thu, 9 Apr 2009 15:01:34 +0000 (UTC) (envelope-from ivoras@gmail.com) Received: by ewy19 with SMTP id 19so687120ewy.43 for ; Thu, 09 Apr 2009 08:01:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:from:date:x-google-sender-auth:message-id:subject:to:cc :content-type:content-transfer-encoding; bh=wM01JcFzotH4OrHhwVD8T1LnXNYi8tbPzNkqh6nkBlw=; b=vrna2zogFHl4E/mkc1AFoLhOR1Uy0UwzlDWEwwTlGhYyFylH7P3mOR/TfxXQIi9PNh +2pPa//FQKoN2+imS8QdFf2G43xh17FlpXzoVMn/tOfVRR+M2IOf+oqJJ8FXDVpnQUai 4lBp1nPT4QRIdUkdOSHcaJ6gufR3XQuEcIxRc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; b=MvPvHumizRNZk0QEFawTMOGvEXUGZx9tNRCCqxGTCOLXKDLQdrxxjiBh6sDHmPRtYH nsoZgzjPiU2GEIMhtWdc8kNHaEKDBum8gm4J6O27usiE6+xSo0rytE+etMDp7WRo80Cz hBw2Dtnh9viVKn948a+IJ9ZYrkBDZfvaf4J4k= MIME-Version: 1.0 Sender: ivoras@gmail.com Received: by 10.210.105.8 with SMTP id d8mr538373ebc.51.1239289293490; Thu, 09 Apr 2009 08:01:33 -0700 (PDT) In-Reply-To: References: From: Ivan Voras Date: Thu, 9 Apr 2009 17:01:18 +0200 X-Google-Sender-Auth: 0f99bfadd972bb73 Message-ID: <9bbcef730904090801n31a0bf27of01c2d82ba1e93c8@mail.gmail.com> To: Danny Braniss Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org Subject: Re: FreeBSD and iSCSI for disks. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 15:01:35 -0000 2009/4/9 Danny Braniss : >> The configuration is: >> >> target0 { >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 targetaddress =3D3D 161.53.72.65 >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 targetname =3D3D iqn.2007-09.jp.ne.peach:dis= k1 >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 tags =3D3D 16 >> } >> > > Q: what kernel? > Q: what target? 7-STABLE AMD64. > btw, without the camcontrol tags, is it working? It appears it can be made to hang under some circumstances, possibly if there is a spelling error in the configuration file. After a reboot, both regular usage and "camcontrol tags" work. From owner-freebsd-stable@FreeBSD.ORG Thu Apr 9 15:07:58 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CC8CD10656D5; Thu, 9 Apr 2009 15:07:58 +0000 (UTC) (envelope-from lists@jnielsen.net) Received: from ns1.jnielsen.net (ns1.jnielsen.net [69.55.238.237]) by mx1.freebsd.org (Postfix) with ESMTP id A425C8FC23; Thu, 9 Apr 2009 15:07:58 +0000 (UTC) (envelope-from lists@jnielsen.net) Received: from [192.168.213.128] (jn@stealth.jnielsen.net [74.218.226.254]) (authenticated bits=0) by ns1.jnielsen.net (8.12.9p2/8.12.9) with ESMTP id n39EhRD1087824; Thu, 9 Apr 2009 10:43:28 -0400 (EDT) (envelope-from lists@jnielsen.net) From: John Nielsen To: freebsd-stable@freebsd.org Date: Thu, 9 Apr 2009 10:43:24 -0400 User-Agent: KMail/1.9.10 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200904091043.25425.lists@jnielsen.net> X-Virus-Scanned: ClamAV version 0.88.4, clamav-milter version 0.88.4 on ns1.jnielsen.net X-Virus-Status: Clean Cc: Ivan Voras Subject: Re: FreeBSD and iSCSI for disks. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 15:07:59 -0000 On Thursday 09 April 2009 10:32:05 am Danny Braniss wrote: > > Danny Braniss wrote: > > >> This is an OpenPGP/MIME signed message (RFC 2440 and 3156) > > >> --------------enig90DADA8437A99D893FB775F8 > > >> Content-Type: text/plain; charset=3D3DUTF-8 > > >> Content-Transfer-Encoding: quoted-printable > > >> > > >> Danny Braniss wrote: > > >>>> Garance A Drosihn wrote: > > >>>>> Some friends of mine are looking at the new "DroboPro", which > > >>>>> makes=3D > > > > a=3D3D > > > > >>>>> lot of disk space available via iSCSI (in addition to firewire > > >>>>> 800)=3D > > > > , > > > > >>>>> and they were wondering how well iSCSI works with FreeBSD. I > > >>>>> haven=3D > > > > 't=3D3D > > > > >>>>> paid attention to iSCSI support. Is there anyone using it > > >>>>> heavily for disk-storage under FreeBSD? Has there been much > > >>>>> changed for iSCSI support in the 8.x branch, or is 7.x support > > >>>>> working fine? > > >>>> > > >>>> I suppose you are interested in the "client" (initiator) side of > > >>>> iSC=3D > > > > SI=3D3D > > > > >>>> support. It hasn't changed much between 7.x and 8.x but there > > >>>> are apparently some announcements of a newer version: > > >>>> > > >>>> http://lists.freebsd.org/pipermail/freebsd-scsi/2009-March/00383 > > >>>>4.ht=3D > > > > ml=3D3D > > > > >>>> I can't find any more information on it. > > >>> > > >>> the latest is in: > > >>> http://www.cs.huji.ac.il/~danny/ftp/freebsd/iscsi-2.1.1.tar.gz > > >> > > >> Thanks! > > >> > > >> Is there anything in particular you'd like to get tested in the > > >> new version, any significant changes or improvements? > > > > > > mainly fixed some bugs, and some code cleanup. > > >=3D20 > > > give it a spin, and let me know what target you are testing. > > > btw, the default tag opening is a bit concervative (1), you might > > > want =3D > > > > to > > > > > change it to somewhat larger, say 64 or 128. > > > > Hi, > > > > "camcontrol tags" hangs: > > > > Apr 9 15:36:36 terminator kernel: da3 at iscsi0 bus 0 target 1 lun 0 > > Apr 9 15:36:36 terminator kernel: da3: > > Fixed Direct Access SCSI-5 device > > Apr 9 15:36:38 terminator kernel: (da2:iscsi0:0:0:0): lost device > > Apr 9 15:36:38 terminator kernel: (da2:iscsi0:0:0:0): removing > > device en=3D try > > terminator:~ivoras/temp/sbin/iscontrol# ls /dev/da* > > /dev/da0 /dev/da0s1 /dev/da0s1a /dev/da0s1b /dev/da0s1c > > /dev/da1 /dev/da3 > > terminator:~ivoras/temp/sbin/iscontrol# camcontrol tags da3 > > > > > > The configuration is: > > > > target0 { > > targetaddress =3D3D 161.53.72.65 > > targetname =3D3D iqn.2007-09.jp.ne.peach:disk1 > > tags =3D3D 16 > > } > > Q: what kernel? =46rom his previous message it looks like 7-STABLE amd64 > Q: what target? =46rom the targetname it looks like the recently committed net/istgt runnin= g=20 on another FreeBSD machine. > btw, without the camcontrol tags, is it working? That one I can't infer. :) JN From owner-freebsd-stable@FreeBSD.ORG Thu Apr 9 15:25:14 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D3140106564A for ; Thu, 9 Apr 2009 15:25:14 +0000 (UTC) (envelope-from zkolic@sbb.co.yu) Received: from smtp4.sbb.rs (smtp4.sbb.rs [89.216.2.36]) by mx1.freebsd.org (Postfix) with ESMTP id 4A51E8FC1E for ; Thu, 9 Apr 2009 15:25:13 +0000 (UTC) (envelope-from zkolic@sbb.co.yu) Received: from faust.net (cable-94-189-247-5.dynamic.sbb.rs [94.189.247.5]) by smtp4.sbb.rs (8.14.0/8.14.0) with ESMTP id n39FPCR6006226 for ; Thu, 9 Apr 2009 17:25:12 +0200 Received: by faust.net (Postfix, from userid 1001) id 2CB885C1C; Thu, 9 Apr 2009 17:25:09 +0200 (CEST) Date: Thu, 9 Apr 2009 17:25:09 +0200 From: Zoran Kolic To: freebsd-stable@freebsd.org Message-ID: <20090409152509.GA972@faust.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-SMTP-Vilter-Version: 1.3.2 X-SBB-Virus-Status: clean X-SBB-Spam-Score: -2.0 Subject: atapicam question X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 15:25:15 -0000 Howdy! Amd64, 7.1. Few days ago I replaced dieing dvd writer with brand new pioneer 116d. In the kernel I removed all not needed stuff and included atapicam and both cd and acd. Previously I used cd only with no hiss. Making dvd I first encountered error at the very beginning of the whole process: acd: Failure - Inquiry illegal request. Using growisofs I got another errors, but nothing that made dvd unusable: "failure - read_toc illegal request" and "failure - unknown cmd". Dvd that contained files with typos, with "(", ")" and "`" gave me some "looking for lun" message du- ring the write. Not shown in /var/log/messages anyway. Since I included atapicam into the kernel and it booted fine, it works with both device drivers. I found some posts that hal could be set not to probe writer, but it is not good, for acd to read dvd. Any opinion on this topic? Maybe some growisofs bug I'm not aware of. I have an impression dvd device is not broken, aside it is new one. Firmware version is 1.06, with 1.09 as the lattest on pioneer site. Another topic could be "how to reflash" dvd writer from freebsd?". Best reagards Zoran From owner-freebsd-stable@FreeBSD.ORG Thu Apr 9 16:33:12 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B4CE2106568D for ; Thu, 9 Apr 2009 16:33:12 +0000 (UTC) (envelope-from sclark46@earthlink.net) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by mx1.freebsd.org (Postfix) with ESMTP id 847F88FC1E for ; Thu, 9 Apr 2009 16:33:12 +0000 (UTC) (envelope-from sclark46@earthlink.net) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=lBVeK9iWxqpFC8qCGp/Mz4NJEDNc7b1VnY8FhboZE2Nm/Ps07ZqNjz7M2IofoJ4d; h=Received:Message-ID:Date:From:Reply-To:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [208.118.36.249] (helo=joker.seclark.com) by elasmtp-curtail.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1LrwwG-0000U3-7O for freebsd-stable@freebsd.org; Thu, 09 Apr 2009 12:17:16 -0400 Message-ID: <49DE1F8B.2080400@earthlink.net> Date: Thu, 09 Apr 2009 12:17:15 -0400 From: Stephen Clark User-Agent: Thunderbird 2.0.0.21 (X11/20090320) MIME-Version: 1.0 To: FreeBSD Stable Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: a437fbc6971e80f61aa676d7e74259b7b3291a7d08dfec792cd26df5b75dfb652be7a73a3b7def77350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 208.118.36.249 Subject: 6.x acpi powerbutton X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: sclark46@earthlink.net List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 16:33:13 -0000 Hello, I am trying to figure out what happens on a soft poweroff? Is there a userspace script that gets called? Thanks, Steve From owner-freebsd-stable@FreeBSD.ORG Thu Apr 9 17:14:05 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D100F1065670 for ; Thu, 9 Apr 2009 17:14:05 +0000 (UTC) (envelope-from ivoras@gmail.com) Received: from mail-ew0-f171.google.com (mail-ew0-f171.google.com [209.85.219.171]) by mx1.freebsd.org (Postfix) with ESMTP id 5E5B88FC0A for ; Thu, 9 Apr 2009 17:14:05 +0000 (UTC) (envelope-from ivoras@gmail.com) Received: by ewy19 with SMTP id 19so750518ewy.43 for ; Thu, 09 Apr 2009 10:14:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:from:date:x-google-sender-auth:message-id:subject:to:cc :content-type:content-transfer-encoding; bh=LrYigfiTfHvqyk84YvEP4Wfy12YHz+6/3H8jIJhQjeY=; b=VzuBCgc67IfBFLMkP05XkzCjmBwBYIRUjVzpaSq67fGncMnkhfMsurUPdF725e/v23 l9RGtj35qYFTibf5X0DNuz+mWdokBDSkfPv/U78JiqaPSJQv53TIAGl0bQNAQpDeTKIa lw0K5mrChJWpOptbsBFVpvvUUuCyYkO7PJjjk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; b=wUZExMe/X2psQ9ZrUlpEM4UNNIZ0/EA6dYmy3b5WGP0HwF2+HGF59yrNOap275g33D yxWQamkkDG31nI49O+4OW9zhUT0t2CBF6u/Wvd2CUSsMYnAA4PaEZvCdlxUcuJt0zhAI 1J0F5h9nuXaEhle8CXI3Cgv1eFBQhrwAct9oE= MIME-Version: 1.0 Sender: ivoras@gmail.com Received: by 10.210.76.4 with SMTP id y4mr2284140eba.12.1239297244398; Thu, 09 Apr 2009 10:14:04 -0700 (PDT) In-Reply-To: <200904091043.25425.lists@jnielsen.net> References: <200904091043.25425.lists@jnielsen.net> From: Ivan Voras Date: Thu, 9 Apr 2009 19:13:49 +0200 X-Google-Sender-Auth: 5d6e72bb6b92ea9f Message-ID: <9bbcef730904091013q4c0aebd0o27f66376efdfb9a6@mail.gmail.com> To: John Nielsen Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: FreeBSD and iSCSI for disks. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 17:14:06 -0000 2009/4/9 John Nielsen : >> Q: what kernel? > > From his previous message it looks like 7-STABLE amd64 > >> Q: what target? > > From the targetname it looks like the recently committed net/istgt running > on another FreeBSD machine. Correct on both :) From owner-freebsd-stable@FreeBSD.ORG Thu Apr 9 17:20:50 2009 Return-Path: Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EAA3B106566B for ; Thu, 9 Apr 2009 17:20:50 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 119C08FC1B for ; Thu, 9 Apr 2009 17:20:49 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id UAA02196; Thu, 09 Apr 2009 20:20:46 +0300 (EEST) (envelope-from avg@icyb.net.ua) Message-ID: <49DE2E6D.5050001@icyb.net.ua> Date: Thu, 09 Apr 2009 20:20:45 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.21 (X11/20090323) MIME-Version: 1.0 To: sclark46@earthlink.net, freebsd-stable@FreeBSD.ORG References: <49DE1F8B.2080400@earthlink.net> In-Reply-To: <49DE1F8B.2080400@earthlink.net> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: Re: 6.x acpi powerbutton X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 17:20:51 -0000 on 09/04/2009 19:17 Stephen Clark said the following: > Hello, > > I am trying to figure out what happens on a soft poweroff? Is there a > userspace script that gets called? If everything works correctly, then acpi driver sends a signal to init which causes a typical graceful shutdown. BTW, was this really a question for stable ml? -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Thu Apr 9 20:24:17 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A487E1065672 for ; Thu, 9 Apr 2009 20:24:17 +0000 (UTC) (envelope-from sclark46@earthlink.net) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by mx1.freebsd.org (Postfix) with ESMTP id 70C4C8FC19 for ; Thu, 9 Apr 2009 20:24:17 +0000 (UTC) (envelope-from sclark46@earthlink.net) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=VKB+RxO+5TkOaA6QnqrN30t9ExT8gREhOpuQPgbE3TL0HU8UvI4HmMza6/X2GDkf; h=Received:Message-ID:Date:From:Reply-To:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [208.118.36.249] (helo=joker.seclark.com) by elasmtp-mealy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1Ls0nI-0001hk-Jh; Thu, 09 Apr 2009 16:24:16 -0400 Message-ID: <49DE596E.2050406@earthlink.net> Date: Thu, 09 Apr 2009 16:24:14 -0400 From: Stephen Clark User-Agent: Thunderbird 2.0.0.21 (X11/20090320) To: Andriy Gapon References: <49DE1F8B.2080400@earthlink.net> <49DE2E6D.5050001@icyb.net.ua> In-Reply-To: <49DE2E6D.5050001@icyb.net.ua> Content-Transfer-Encoding: 7bit X-ELNK-Trace: a437fbc6971e80f61aa676d7e74259b7b3291a7d08dfec795e67b9f93a23d5c38ae81fd75b53ed6c350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 208.118.36.249 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org Subject: Re: 6.x acpi powerbutton X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: sclark46@earthlink.net List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 20:24:17 -0000 Andriy Gapon wrote: on 09/04/2009 19:17 Stephen Clark said the following: Hello, I am trying to figure out what happens on a soft poweroff? Is there a userspace script that gets called? If everything works correctly, then acpi driver sends a signal to init which causes a typical graceful shutdown. BTW, was this really a question for stable ml? Probably not. But I spent a couple of hours googling without much luck so I got desperate. ;-) Is there a reason it doesn't send and event like Linux that can be acted upon by user space other than signaling init? I like to have a message written in /var/log/messages that someone pressed the powerbutton. Thanks -- "They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety." (Ben Franklin) "The course of history shows that as a government grows, liberty decreases." (Thomas Jefferson) From owner-freebsd-stable@FreeBSD.ORG Thu Apr 9 20:45:13 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5E918106566C; Thu, 9 Apr 2009 20:45:13 +0000 (UTC) (envelope-from lopez.on.the.lists@yellowspace.net) Received: from mail.yellowspace.net (mail.yellowspace.net [80.190.200.164]) by mx1.freebsd.org (Postfix) with ESMTP id CCA098FC19; Thu, 9 Apr 2009 20:45:12 +0000 (UTC) (envelope-from lopez.on.the.lists@yellowspace.net) Received: from five.intranet ([93.104.36.234]) (AUTH: LOGIN lopez.on.the.lists@yellowspace.net) by mail.yellowspace.net with esmtp; Thu, 09 Apr 2009 22:35:07 +0200 id 003980F6.0000000049DE5BFB.0000F869 Message-Id: <4457FAEE-A54F-4C4A-B625-5EB3A51BD47A@yellowspace.net> From: Lorenzo Perone To: Ivan Voras 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 v930.3) Date: Thu, 9 Apr 2009 22:35:06 +0200 References: X-Mailer: Apple Mail (2.930.3) Cc: freebsd-stable@freebsd.org Subject: Re: ZFSKnownProblems - needs revision? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 20:45:13 -0000 Hi, in one production case (1), haven't seen panics or deadlocks for a long time, yet on another much more powerful machine (2), I could not get rid of "vm_thread_new: kstack allocation failed", ultimately rendering the machine useless pretty fast. This was at least till RELENG_7/november (7.1-PRERELEASE), where I decided to stop the zfs experiment for now and went back to ufs. trying to understand now if 7.2 is worth a new try, or if, for that matter, the only reasonable wait is until 8.0. perhaps worth of note, the kstack errors still occurred (albeit after more time) with all zpools exported (and system rebooted) but the zfs.ko still loaded. only after rebooting without zfs_load="YES" the server began to work seemlessly for months. I'm asking myself if/how important the underlying driver/provider (mfi, mpt, ad, ciss, etc..) can be in regard to the remaining/ recurring problems with zfs.. (since I've seen so different behaviors with different machines...)? (1) Homebrewn Opteron / 2GB RAM / SATA ad / 7.1-PRERELEASE w. usual tuning, one zpool on a SATA mirror for backups via rsync of several servers (2) DELL PE 1950 1 Quad-Xeon / 8GB RAM / LSI mpt / 7.1-PRERELEASE w. many tunings tried, one zpool on a partition on top of HW RAID 1, moderately loaded mailserver box running courier and mysql Regards, Lorenzo From owner-freebsd-stable@FreeBSD.ORG Thu Apr 9 22:09:32 2009 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D6D2410656D1 for ; Thu, 9 Apr 2009 22:09:32 +0000 (UTC) (envelope-from josemi@freebsd.jazztel.es) Received: from smtp01.jazztel.es (smtp01.jazztel.es [62.14.3.170]) by mx1.freebsd.org (Postfix) with ESMTP id 923EC8FC13 for ; Thu, 9 Apr 2009 22:09:32 +0000 (UTC) (envelope-from josemi@freebsd.jazztel.es) Received: from [87.217.187.186] (helo=antares.redesjm.local) by smtp01.jazztel.es with esmtpa (Exim 4.60) (envelope-from ) id 1Ls27q-0005EQ-CA for stable@freebsd.org; Thu, 09 Apr 2009 23:49:34 +0200 Received: from redesjm.local (orion.redesjm.local [192.168.254.16]) by antares.redesjm.local (8.14.3/8.14.3) with ESMTP id n39LnXnb092602 for ; Thu, 9 Apr 2009 23:49:33 +0200 (CEST) (envelope-from josemi@redesjm.local) Received: (from josemi@localhost) by orion.redesjm.local (8.14.3/8.14.3/Submit) id n39LKRgl008326 for stable@freebsd.org; Thu, 9 Apr 2009 23:20:27 +0200 (CEST) (envelope-from josemi) Date: Thu, 9 Apr 2009 23:20:27 +0200 (CEST) From: Jose M Rodriguez Message-Id: <200904092120.n39LKRgl008326@orion.redesjm.local> To: stable@freebsd.org X-Virus-Checked: Passed : Kaspersky at jazztel.es X-AntiSpam-Checked: Passed : Threshold - 0.0 : SA jazztel.es Cc: Subject: libc ABI changes in RELENG_7 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 22:09:34 -0000 Hi Building a samba package in a recent RELENG_7 box and install on a 7.1-RELEASE system I found ABI changes that make ldconfig fail. This is related to a new strndup symbol in libc that samba build autodetect and use. This is really necesary? -- josemi From owner-freebsd-stable@FreeBSD.ORG Thu Apr 9 22:43:32 2009 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1EC091065670 for ; Thu, 9 Apr 2009 22:43:32 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.delphij.net (delphij-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:2c9::2]) by mx1.freebsd.org (Postfix) with ESMTP id B5E958FC1F for ; Thu, 9 Apr 2009 22:43:31 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [211.166.10.233]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tarsier.delphij.net (Postfix) with ESMTPS id 5E7F02844E for ; Fri, 10 Apr 2009 06:43:30 +0800 (CST) Received: from localhost (tarsier.geekcn.org [211.166.10.233]) by tarsier.geekcn.org (Postfix) with ESMTP id B983CEC2D5E; Fri, 10 Apr 2009 06:43:29 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([211.166.10.233]) by localhost (mail.geekcn.org [211.166.10.233]) (amavisd-new, port 10024) with ESMTP id oNfCGae7GeqU; Fri, 10 Apr 2009 06:43:21 +0800 (CST) Received: from charlie.delphij.net (adsl-76-237-33-62.dsl.pltn13.sbcglobal.net [76.237.33.62]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTPSA id A0564EC2D52; Fri, 10 Apr 2009 06:43:18 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:reply-to:organization:user-agent: mime-version:to:cc:subject:references:in-reply-to: x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=PKVZD9KfarUD0w/qWIvID3Wq6lb5IIFXVwWGbJSLsv48eBZ12CNNvE3i3Q+AQgZe7 1cF4NCVx1eNEy10461IUg== Message-ID: <49DE7A03.70409@delphij.net> Date: Thu, 09 Apr 2009 15:43:15 -0700 From: Xin LI Organization: The FreeBSD Project User-Agent: Thunderbird 2.0.0.21 (X11/20090408) MIME-Version: 1.0 To: Jose M Rodriguez References: <200904092120.n39LKRgl008326@orion.redesjm.local> In-Reply-To: <200904092120.n39LKRgl008326@orion.redesjm.local> X-Enigmail-Version: 0.95.7 OpenPGP: id=18EDEBA0; url=http://www.delphij.net/delphij.asc Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: stable@freebsd.org Subject: Re: libc ABI changes in RELENG_7 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 22:43:32 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Jose, Jose M Rodriguez wrote: > Hi > Building a samba package in a recent RELENG_7 box and install on a > 7.1-RELEASE system I found ABI changes that make ldconfig fail. > > This is related to a new strndup symbol in libc that samba build autodetect > and use. This is really necesary? The only way to guarantee a package is usable under 7.1-RELEASE is to build it under a 7.1-RELEASE chroot or jail, when building it on a newer host system. That's said, we strive our best to maintain backward compatibility, i.e. make sure that newer FreeBSD versions would always run older binaries; we do want to keep some sort of upward compatibility, for instance, when you build a binary on newer FreeBSD version, it's *likely* that it can be run on older FreeBSD version, but this is not strictly guaranteed or we can not add any new functionalities into new FreeBSD versions. I personally feel very strongly against of not having a POSIX-defined libc function just because older 7.x does not have it, unless we want the whole 7.x branch to be EoL'ed soon. Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEARECAAYFAkneeYgACgkQi+vbBBjt66CUlwCeJINd92n72WiiV1fBkwR6Oisp KCkAoMDxWdNd3r1654Vddf+ZFmOILrH0 =wJnZ -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Thu Apr 9 23:10:14 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2B2DF106566C for ; Thu, 9 Apr 2009 23:10:14 +0000 (UTC) (envelope-from fjwcash@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 F1E5B8FC16 for ; Thu, 9 Apr 2009 23:10:13 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: by rv-out-0506.google.com with SMTP id l9so786230rvb.43 for ; Thu, 09 Apr 2009 16:10:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=dNJHbFORKAuqGvUqdcWfXrpORALmHM9FDZEmt/lc2bI=; b=KCfobQuNGWwZjbvyt07+aeBf/hPd8QpyzaUnUO4m/fK3t+n6n5Btkgzs8zFbd2BxbP fSl8btJGwn0LHEidwdgeJUeEjAtu0CECg193fQE30L/DUOJA1JKyyG67/utHNFWpf23E GHqCRda7lye1SAq3O8iBwWQufgODdxktQ1l4A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=ZPjOz5ARfqqF+rj+/ZLpngSAgzzcxdjQY80a+DttfhhOeAgjRy/RarJU1NtgjBvADj GhlfGf08Oida4QFLvK94rcC0gyn09Oq8qbMOtC8xvclHFQX1lyA3Ps3YErxzfIApEYaO h+RC813oB3gYNY2LRfui03WiHUsJwm42nUB7Q= MIME-Version: 1.0 Received: by 10.140.193.15 with SMTP id q15mr1220932rvf.274.1239316954522; Thu, 09 Apr 2009 15:42:34 -0700 (PDT) In-Reply-To: <49DD2B44.5020808@mawer.org> References: <200904080959.49201.fjwcash@gmail.com> <49DD2B44.5020808@mawer.org> Date: Thu, 9 Apr 2009 15:42:34 -0700 Message-ID: From: Freddie Cash To: Antony Mawer Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org Subject: Re: Network sysctl tuning [was Re: ZFSKnownProblems - needs revision?] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 23:10:14 -0000 On Wed, Apr 8, 2009 at 3:55 PM, Antony Mawer wrote: > Freddie Cash wrote: > ... >> We've also heavily modified /etc/sysctl.conf and upped a bunch of the >> network-related sysctls. =C2=A0Doing so increased our SSH throughput fro= m ~30 >> Mbits/sec across all connections to over 90 Mbits/sec per SSH connection= . > > Are you able to share any of these with the list? It would be useful to > compare as a lot of these tunings people do individually and it would be > good to allow others to test in their environments to see if they help, a= s > well as potentially adding them to the tuning man-page. They're all taken from the HPN-SSH website and various google searches related to HPN-enabled OpenSSH. I don't know exactly what all the different, individual sysctls do, nor whether this is the most optimal setup, but here's the sysctl.conf that we use. This is on 2 systems using a quad-port gigabit NIC where the top two ports are connected via lagg(4) and the bottom two ports are connected via lagg(4), with the two laggX interfaces on separate networks. I did a bunch of scp/sftp transfers of 100 MB files filled with random data pulled from /dev/random between these two boxes tweaking the options one at a time, but didn't do too much in the way of scientific/empirical measurements and comparisons beyond the throughput data that scp/sftp shows. If there are any glaring errors, gotchas, or "why would you ever do that"s, let me know. :) # General network settings net.isr.direct=3D1 # Whether to enable Direct Dispatch for netisr # IP options net.inet.ip.forwarding=3D0 # Whether to enable packet forwarding for NAT/routing net.inet.ip.process_options=3D0 # Disable processing of IP options (nothing uses this field) net.inet.ip.random_id=3D1 # Randomise the IP header ID numb= er net.inet.ip.redirect=3D0 # Whether to allow redirect packe= ts #net.inet.ip.stealth=3D0 # Whether to appear in traceroute= output # ICMP options net.inet.icmp.icmplim=3D200 # Limit ICMP packets to this many per second net.inet.icmp.drop_redirect=3D1 # Drop ICMP redirect packets net.inet.icmp.log_redirect=3D0 # Don't log ICMP redirect packets # TCP options net.inet.tcp.blackhole=3D1 # Drop packets destined to unused= ports net.inet.tcp.inflight.enable=3D0 # Use automatic TCP window-scalin= g net.inet.tcp.log_in_vain=3D0 # Don't log the blackholed packet= s net.inet.tcp.path_mtu_discovery=3D1 # Use ICMP type 3 to find the MTU= to use net.inet.tcp.recvbuf_max=3D16777216 # The max size of the receive buffer (16 MB) net.inet.tcp.recvspace=3D131072 # The initial size in bytes of the receive buffer net.inet.tcp.sack.enable=3D1 # Enable Selective ACKs net.inet.tcp.sendbuf_max=3D16777216 # The max size of the send buffer net.inet.tcp.sendspace=3D131072 # The initial size in bytes of the send buffer net.inet.tcp.syncookies=3D1 # Enable SYN cookie protection net.inet.tcp.rfc1323=3D1 # Enable RFC1323 extensions (TCP window scaling) # UDP options net.inet.udp.blackhole=3D1 # Drop packets destined to unused= ports net.inet.udp.checksum=3D1 # Enable UDP checksums net.inet.udp.log_in_vain=3D0 # Don't log the blackholed packet= s net.inet.udp.recvspace=3D65536 # Size in bytes of the receive bu= ffer # Debug options debug.minidump=3D1 # Disable the small kernel core dump (only mem in use) debug.mpsafevfs=3D1 # Enable threaded VFS subsystem # Kernel options kern.coredump=3D0 # Disable kernel core dumps kern.ipc.maxsockbuf=3D4194304 # Set the max size of the socket buffers (4 MB) kern.ipc.somaxconn=3D1024 # Expand the IP listen queue kern.maxvnodes=3D250000 # Bump up the max number of vnode= s # PCI bus options hw.pci.enable_msix=3D1 # Enable Message Signalled Interrupts - Extended hw.pci.enable_msi=3D1 # Enable Message Signalled Interr= upts hw.pci.enable_io_modes=3D1 # Enable alternate I/O access mod= es --=20 Freddie Cash fjwcash@gmail.com From owner-freebsd-stable@FreeBSD.ORG Thu Apr 9 23:15:11 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 68211106566B for ; Thu, 9 Apr 2009 23:15:11 +0000 (UTC) (envelope-from matheusber@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 178828FC1C for ; Thu, 9 Apr 2009 23:15:10 +0000 (UTC) (envelope-from matheusber@gmail.com) Received: by yx-out-2324.google.com with SMTP id 8so555607yxm.13 for ; Thu, 09 Apr 2009 16:15:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:received:received :message-id:date:subject:from:to:user-agent:mime-version :content-type:content-transfer-encoding:x-priority:importance; bh=zAIfHmWLBXzBa4f/NsZwRcV3tI8m6Qj9RTO+RVwJ1Oo=; b=nqc25omx7VxSlGPi/9OGwFJR68s5P9SNtGOW/3xChf3hmx+2wd79mEN1PUodk6VoA+ 74tQhrxF81MwGFH8EckfaTzets7gciJtJbKWI3jd5aoRaw7wIvGbrc3FmIvh+/st8X+r jtVJs0kOjWhzC082GMJTJw9hTQ6SljripVWEw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:subject:from:to:user-agent:mime-version :content-type:content-transfer-encoding:x-priority:importance; b=QJZPbUF8Zha5vXjqPiuaHbUnmIAl7P50sSGXkWq3n4cXAGLyDHoWy0Qb7HBvFz9t95 gTFjmRdJoFPkJBn8YB7DNlf6iwtgiKFg5bI0paSmB3hYAy4ziYpm2MNtbMg1iMvUWozb /UpObTnlA4dq7yya1ZbXqahEIS3iJXLy6FtNA= Received: by 10.100.166.10 with SMTP id o10mr1284221ane.53.1239318910348; Thu, 09 Apr 2009 16:15:10 -0700 (PDT) Received: from cygnus.homeunix.com ([189.71.2.75]) by mx.google.com with ESMTPS id 4sm1965870yxj.41.2009.04.09.16.15.09 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 09 Apr 2009 16:15:09 -0700 (PDT) Sender: Nenhum_de_Nos Received: by cygnus.homeunix.com (Postfix, from userid 80) id 5271FB8074; Thu, 9 Apr 2009 20:15:05 -0300 (BRT) Received: from 10.1.1.80 (SquirrelMail authenticated user matheus) by 10.1.1.10 with HTTP; Thu, 9 Apr 2009 20:15:05 -0300 (BRT) Message-ID: <94b70a65b8e00354631e491f8bf0cc25.squirrel@10.1.1.10> Date: Thu, 9 Apr 2009 20:15:05 -0300 (BRT) From: "Nenhum_de_Nos" To: freebsd-stable@freebsd.org User-Agent: SquirrelMail/1.4.15 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: anyone using seagate microdrives and freebsd ? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 23:15:11 -0000 I have on and no luck in working this config out. If anyone could give any hint. I've seen this pr http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/110407 and some other cases from some searching, but no one ever said anything about success case. thanks, matheus -- We will call you cygnus, The God of balance you shall be From owner-freebsd-stable@FreeBSD.ORG Fri Apr 10 00:14:22 2009 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 463A5106566C for ; Fri, 10 Apr 2009 00:14:22 +0000 (UTC) (envelope-from pyunyh@gmail.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 CE59F8FC16 for ; Fri, 10 Apr 2009 00:14:21 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by ti-out-0910.google.com with SMTP id u5so757996tia.3 for ; Thu, 09 Apr 2009 17:14:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=yl2r5vB6U7eaLY+H2Y/vdBSchidYVUQxR4iR4jM5NB8=; b=l6pqLPzrKk+x2xHy+Flsn40p9eM49T38xlwAbhptfTtP0qTqz1fxDzxG/yV6+LPLQ1 dGhahLLez5OUBdi8/Es9JycSgzIlcqhmIUONyIF5gBxU2scWAwHrzjJNQQ8PPq0f4oFv i7qoeQ/QjP/b8JIRGyovTaRR43heEfgThzT4c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=euZWX6qB3aR9IR+Vq+oNkJUoFDUl6AZmrsdaXLpvlFjqR+C1Rtk1IWLw22VkleCeHA q0XB5y9xWj9CdhFgz7Ii1dBIUlBRwIdZ2HRU5MlZwmjSiaB3xkhMoIrAvZ8uVt993DRT bJNpnq1kZbkGfY5rf0m/RAb4/XgHUPlBY3EhM= Received: by 10.110.68.10 with SMTP id q10mr1089539tia.30.1239322460078; Thu, 09 Apr 2009 17:14:20 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ([114.111.62.249]) by mx.google.com with ESMTPS id a4sm2980189tib.11.2009.04.09.17.14.17 (version=SSLv3 cipher=RC4-MD5); Thu, 09 Apr 2009 17:14:18 -0700 (PDT) Received: by michelle.cdnetworks.co.kr (sSMTP sendmail emulation); Fri, 10 Apr 2009 09:15:36 +0900 From: Pyun YongHyeon Date: Fri, 10 Apr 2009 09:15:36 +0900 To: Bjoern Koenig Message-ID: <20090410001536.GH37714@michelle.cdnetworks.co.kr> References: <70ba25e4f1a5e43ab8d99b361235dda2.squirrel@webmail.alpha-tierchen.de> <20090409000427.GD37714@michelle.cdnetworks.co.kr> <2f68678165f20f2e1dae10cb0e63761d.squirrel@webmail.alpha-tierchen.de> <20090409072309.GF37714@michelle.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.3i Cc: stable@freebsd.org Subject: Re: fxp: stalled transfers X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2009 00:14:22 -0000 On Thu, Apr 09, 2009 at 11:02:06AM +0200, Bjoern Koenig wrote: > pyunyh@gmail.com wrote: > > > If you can easily reproduce the issue, can you capture stalled TCP > > session with tcpdump on receiving host?(Make sure to disable Rx > > checksum offload prior to capturing the session.) > > I transferred a 256 kiB file and these are the tcpdumps: > > http://www.alpha-tierchen.de/~bkoenig/fxp0-with-tso.txt > http://www.alpha-tierchen.de/~bkoenig/fxp0-without-tso.txt > > Actually the transfer doesn't stall although ftp and scp told me so. It > becomes incredibly slow. It seems like that the chunks are too large and a > smaller packet will be resent. I decreased the MTU from 1500 to 1492 and > it works fine with TSO enabled. > > I also captured the traffic on my router: > > http://www.alpha-tierchen.de/~bkoenig/fxp0-with-tso-router.txt > http://www.alpha-tierchen.de/~bkoenig/fxp0-without-tso-router.txt > > It reveals a suspect information: "truncated-ip - 8 bytes missing!" > > I almost suppose that this is a PPPoE-related configuration issue and the > fxp driver is not necessarily the problem since decreasing the MTU of the > LAN host solves it. > I think you're right. Thanks a lot! From owner-freebsd-stable@FreeBSD.ORG Fri Apr 10 00:45:11 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D96ED106564A for ; Fri, 10 Apr 2009 00:45:11 +0000 (UTC) (envelope-from a.j.werven@student.utwente.nl) Received: from mx.utwente.nl (mx1.utsp.utwente.nl [130.89.2.12]) by mx1.freebsd.org (Postfix) with ESMTP id 57DCB8FC12 for ; Fri, 10 Apr 2009 00:45:11 +0000 (UTC) (envelope-from a.j.werven@student.utwente.nl) Received: from satellite.xs4all.nl (vpn107088.vpn.utwente.nl [130.89.107.88]) by mx.utwente.nl (8.12.10/SuSE Linux 0.7) with ESMTP id n3A0WkV8024366; Fri, 10 Apr 2009 02:32:47 +0200 Received: from satellite.xs4all.nl (localhost [127.0.0.1]) by satellite.xs4all.nl (8.14.3/8.14.3) with ESMTP id n3A0WfeV011943; Fri, 10 Apr 2009 02:32:42 +0200 (CEST) (envelope-from fonz@satellite.xs4all.nl) Received: (from fonz@localhost) by satellite.xs4all.nl (8.14.3/8.14.3/Submit) id n3A0WfnL011942; Fri, 10 Apr 2009 02:32:41 +0200 (CEST) (envelope-from fonz) From: "A.J. \"Fonz\" van Werven" Message-Id: <200904100032.n3A0WfnL011942@satellite.xs4all.nl> In-Reply-To: <94b70a65b8e00354631e491f8bf0cc25.squirrel@10.1.1.10> To: "Nenhum_de_Nos" Date: Fri, 10 Apr 2009 02:32:41 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL124c (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" X-UTwente-MailScanner-Information: Scanned by MailScanner. Contact servicedesk@icts.utwente.nl for more information. X-UTwente-MailScanner: Found to be clean X-UTwente-MailScanner-From: a.j.werven@student.utwente.nl X-Spam-Status: No Cc: freebsd-stable@freebsd.org Subject: Re: anyone using seagate microdrives and freebsd ? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2009 00:45:12 -0000 Nenhum_de_Nos wrote: > I have on and no luck in working this config out. I remember microdrives... those are from long ago, when the C64s and ZX Spectrums ruled the world ;-) Alphons (sorry, couldn't resist) -- All right, that does it Bill [Donahue]. I'm pretty sure that killing Jesus is not very Christian. -- Pope Benedict XVI, Southpark season 11 episode 5 From owner-freebsd-stable@FreeBSD.ORG Fri Apr 10 04:42:21 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7A48C106564A for ; Fri, 10 Apr 2009 04:42:21 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.232]) by mx1.freebsd.org (Postfix) with ESMTP id 463A28FC0A for ; Fri, 10 Apr 2009 04:42:21 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by rv-out-0506.google.com with SMTP id l9so875024rvb.43 for ; Thu, 09 Apr 2009 21:42:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=FJqpEIenMKBAzIps+fWd34VOT+i9yTJzCGeFYzeT6Bo=; b=NlyOgjr4oO/2DqCvjO84zJ2k5ZeLTVIzxcM7O52KzT7TpYqUiKsvyQv5mAa5wZFbVr r4uX29AqKzSAeVPPKMWK8IGO8LX/5S60qk7RwzMxO8mSWSfV7DW1Ro4kMnWUfmrgIoHh l+tbD06vqSKnJ+maDOCWSusMr4j/Q6B6MIL18= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=YiNuEA4GnapN8X7I9vaeusqc+BGhP48xb9jEA76fDfjxU8Ot51G3muvsK4uRB0DzHg r3uVvOwW6THNN7bykv0fW8Hzbyg1RVp1B1CaggHeJU34VgRtMz8nRnrr6K9/+872+f2V Z6pmZPy23EYdG1Lap+r1JDnODsSK+nlXsuIQs= Received: by 10.140.136.5 with SMTP id j5mr1342385rvd.39.1239338540875; Thu, 09 Apr 2009 21:42:20 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ([114.111.62.249]) by mx.google.com with ESMTPS id k41sm2803059rvb.46.2009.04.09.21.42.18 (version=SSLv3 cipher=RC4-MD5); Thu, 09 Apr 2009 21:42:19 -0700 (PDT) Received: by michelle.cdnetworks.co.kr (sSMTP sendmail emulation); Fri, 10 Apr 2009 13:43:40 +0900 From: Pyun YongHyeon Date: Fri, 10 Apr 2009 13:43:40 +0900 To: xer Message-ID: <20090410044340.GJ37714@michelle.cdnetworks.co.kr> References: <20090407120032.633E410656D5@hub.freebsd.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="6sX45UoQRIJXqkqR" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: freebsd-stable@freebsd.org Subject: Re: watchdog timeout X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2009 04:42:21 -0000 --6sX45UoQRIJXqkqR Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wed, Apr 08, 2009 at 10:41:44AM +0200, xer wrote: > Hello > I have some problems with 3Com nics, after a upgrade from 5.5-STABLE to > 6.4-STABLE. > > This machine has two 3com nics (one is LAN other is WAN) and i see too much > "watchdog timeout" on both cards. > This on/off up/down on cards, affect the interrupt to clients that are > downloading from apache web server, especially on large files. > > -------------------------------------------- > xer:/root# dmesg > xl1: watchdog timeout > xl1: link state changed to DOWN > xl1: link state changed to UP > xl1: watchdog timeout > xl1: link state changed to DOWN > xl1: link state changed to UP > xl1: watchdog timeout > xl1: link state changed to DOWN > xl1: link state changed to UP > --------------------------------------------- > > xer:/root# cat /var/run/dmesg.boot | grep xl > xl0: <3Com 3c905C-TX Fast Etherlink XL> port 0xec00-0xec7f mem > 0xfceffc00-0xfceffc7f irq 23 at device 11.0 on pci2 > miibus0: on xl0 > xlphy0: <3c905C 10/100 internal PHY> on miibus0 > xlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > xl0: Ethernet address: 00:01:02:e0:04:1b > xl1: <3Com 3c905C-TX Fast Etherlink XL> port 0xe880-0xe8ff mem > 0xfceff800-0xfceff87f irq 20 at device 12.0 on pci2 > miibus1: on xl1 > xlphy1: <3c905C 10/100 internal PHY> on miibus1 > xlphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > xl1: Ethernet address: 00:01:02:df:fe:ed > --------------------------------------------- > Another doubt would be my kernel config, maybe there is something wrong > that i cannot see, i'll post at the end of this post, 'cause is too long. > > As you can see, the cards are 3c905C-TX model. > Someone told me to change drivers, but i cannot understand this advice. > I got same errors with same cards but with another mainboard, same problem, > watchdog appears after an upgrade from 5.4-STABLE to 6.4-STABLE. > > I don't think that to change nic's pci slots, will solve the problem, i > think that maybe change the nics would resolve the matter, but i cannot > access to both FreeBSD phisically, cause the boxes are too far from me > (about 3500 km). > > I'm asking you some advices, and i can i fix this problem. > p.s. with both 5.4 or 5.5 old kernel, the nics was fine. > I vaguely remember there were a couple of reports on xl(4) watchdog timeouts. I'm not sure this came from missing Tx interrupts but would you try attached patch? Note, it was generated against HEAD and you should experiment the attached patch on local box prior to applying to your production server. --6sX45UoQRIJXqkqR Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="xl.watchdog.patch" Index: sys/dev/xl/if_xl.c =================================================================== --- sys/dev/xl/if_xl.c (revision 190876) +++ sys/dev/xl/if_xl.c (working copy) @@ -2097,13 +2097,13 @@ m_freem(cur_tx->xl_mbuf); cur_tx->xl_mbuf = NULL; ifp->if_opackets++; + ifp->if_drv_flags &= ~IFF_DRV_OACTIVE; cur_tx->xl_next = sc->xl_cdata.xl_tx_free; sc->xl_cdata.xl_tx_free = cur_tx; } if (sc->xl_cdata.xl_tx_head == NULL) { - ifp->if_drv_flags &= ~IFF_DRV_OACTIVE; sc->xl_wdog_timer = 0; sc->xl_cdata.xl_tx_tail = NULL; } else { @@ -2540,6 +2540,9 @@ XL_LOCK_ASSERT(sc); + if ((ifp->if_drv_flags & (IFF_DRV_RUNNING | IFF_DRV_OACTIVE)) != + IFF_DRV_RUNNING) + return; /* * Check for an available queue slot. If there are none, * punt. @@ -2668,7 +2671,8 @@ XL_LOCK_ASSERT(sc); - if (ifp->if_drv_flags & IFF_DRV_OACTIVE) + if ((ifp->if_drv_flags & (IFF_DRV_RUNNING | IFF_DRV_OACTIVE)) != + IFF_DRV_RUNNING) return; idx = sc->xl_cdata.xl_tx_prod; @@ -3207,12 +3211,31 @@ { struct ifnet *ifp = sc->xl_ifp; u_int16_t status = 0; + int misintr; XL_LOCK_ASSERT(sc); if (sc->xl_wdog_timer == 0 || --sc->xl_wdog_timer != 0) return (0); + xl_rxeof(sc); + xl_txeoc(sc); + misintr = 0; + if (sc->xl_type == XL_TYPE_905B) { + xl_txeof_90xB(sc); + if (sc->xl_cdata.xl_tx_cnt == 0) + misintr++; + } else { + xl_txeof(sc); + if (sc->xl_cdata.xl_tx_head == NULL) + misintr++; + } + if (misintr != 0) { + device_printf(sc->xl_dev, + "watchdog timeout (missed Tx interrupts) -- recovering\n"); + return (0); + } + ifp->if_oerrors++; XL_SEL_WIN(4); status = CSR_READ_2(sc, XL_W4_MEDIA_STATUS); @@ -3222,9 +3245,6 @@ device_printf(sc->xl_dev, "no carrier - transceiver cable problem?\n"); - xl_txeoc(sc); - xl_txeof(sc); - xl_rxeof(sc); xl_reset(sc); xl_init_locked(sc); --6sX45UoQRIJXqkqR-- From owner-freebsd-stable@FreeBSD.ORG Fri Apr 10 06:46:10 2009 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DE69B106566C for ; Fri, 10 Apr 2009 06:46:10 +0000 (UTC) (envelope-from bkoenig@alpha-tierchen.de) Received: from alpha-tierchen.de (alpha-tierchen.de [88.198.145.202]) by mx1.freebsd.org (Postfix) with ESMTP id 9E6A08FC12 for ; Fri, 10 Apr 2009 06:46:10 +0000 (UTC) (envelope-from bkoenig@alpha-tierchen.de) Received: from webmail.alpha-tierchen.de (alpha-tierchen.de [88.198.145.202]) by alpha-tierchen.de (Postfix) with ESMTP id 83C5123922A; Fri, 10 Apr 2009 08:46:08 +0200 (CEST) Received: from 212.202.40.56 (SquirrelMail authenticated user bkoenig) by webmail.alpha-tierchen.de with HTTP; Fri, 10 Apr 2009 08:46:08 +0200 (CEST) Message-ID: <37a8d3252c3d50682f4fb790e30e09f3.squirrel@webmail.alpha-tierchen.de> In-Reply-To: References: <70ba25e4f1a5e43ab8d99b361235dda2.squirrel@webmail.alpha-tierchen.de> <20090409000427.GD37714@michelle.cdnetworks.co.kr> <2f68678165f20f2e1dae10cb0e63761d.squirrel@webmail.alpha-tierchen.de> <20090409072309.GF37714@michelle.cdnetworks.co.kr> Date: Fri, 10 Apr 2009 08:46:08 +0200 (CEST) From: "Bjoern Koenig" To: pyunyh@gmail.com User-Agent: SquirrelMail/1.4.17 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: stable@freebsd.org Subject: Re: fxp: stalled transfers X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2009 06:46:11 -0000 I wrote: > >> If you can easily reproduce the issue, can you capture stalled TCP >> session with tcpdump on receiving host?(Make sure to disable Rx >> checksum offload prior to capturing the session.) > > I transferred a 256 kiB file and these are the tcpdumps: > > http://www.alpha-tierchen.de/~bkoenig/fxp0-with-tso.txt > http://www.alpha-tierchen.de/~bkoenig/fxp0-without-tso.txt > > Actually the transfer doesn't stall although ftp and scp told me so. It > becomes incredibly slow. It seems like that the chunks are too large and a > smaller packet will be resent. I decreased the MTU from 1500 to 1492 and > it works fine with TSO enabled. > > I also captured the traffic on my router: > > http://www.alpha-tierchen.de/~bkoenig/fxp0-with-tso-router.txt > http://www.alpha-tierchen.de/~bkoenig/fxp0-without-tso-router.txt > > It reveals a suspect information: "truncated-ip - 8 bytes missing!" > > I almost suppose that this is a PPPoE-related configuration issue and the > fxp driver is not necessarily the problem since decreasing the MTU of the > LAN host solves it. Hello, it's me again. :) It's not PPPoE-related. I was able to reproduce the behaviour within a regular LAN from host to host. I also have another symptom which denies the PPPoE assumption: If I set MTU to value X then it doesn't work with MTU X+N anymore. I'll get the message "N bytes missing!" in the tcpdump output. For example: ifconfig fxp0 mtu 1448 # works ifconfig fxp0 mtu 1412 # still works ifconfig fxp0 mtu 1448 # doesn't work (36 bytes missing) ifconfig fxp0 mtu 1400 # works ifconfig fxp0 mtu 1412 # doesn't work (12 bytes missing) Regards Björn From owner-freebsd-stable@FreeBSD.ORG Fri Apr 10 07:01:10 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B97FB1065670 for ; Fri, 10 Apr 2009 07:01:10 +0000 (UTC) (envelope-from xernet@hotmail.it) Received: from bay0-omc2-s13.bay0.hotmail.com (bay0-omc2-s13.bay0.hotmail.com [65.54.246.149]) by mx1.freebsd.org (Postfix) with ESMTP id A16768FC24 for ; Fri, 10 Apr 2009 07:01:10 +0000 (UTC) (envelope-from xernet@hotmail.it) Received: from BAY126-DS6 ([65.55.131.33]) by bay0-omc2-s13.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 10 Apr 2009 00:01:10 -0700 X-Originating-IP: [79.10.86.250] X-Originating-Email: [xernet@hotmail.it] Message-ID: From: "xer" To: References: <20090407120032.633E410656D5@hub.freebsd.org> <20090410044340.GJ37714@michelle.cdnetworks.co.kr> In-Reply-To: <20090410044340.GJ37714@michelle.cdnetworks.co.kr> Date: Fri, 10 Apr 2009 09:01:15 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8064.206 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8064.206 X-OriginalArrivalTime: 10 Apr 2009 07:01:10.0388 (UTC) FILETIME=[20DFB340:01C9B9AA] Cc: freebsd-stable@freebsd.org Subject: Re: watchdog timeout X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: xer List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2009 07:01:11 -0000 Thank you Pyun I found this another one: http://www.freebsd.org/cgi/query-pr.cgi?pr=129352 And it seems a lot different.. which one will bet to try? Regards -------------------------------------------------- From: "Pyun YongHyeon" Sent: Friday, April 10, 2009 6:43 AM To: "xer" Cc: Subject: Re: watchdog timeout > > I vaguely remember there were a couple of reports on xl(4) watchdog > timeouts. I'm not sure this came from missing Tx interrupts but > would you try attached patch? > Note, it was generated against HEAD and you should experiment the > attached patch on local box prior to applying to your production > server. > From owner-freebsd-stable@FreeBSD.ORG Fri Apr 10 07:31:37 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E41681065670 for ; Fri, 10 Apr 2009 07:31:37 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.232]) by mx1.freebsd.org (Postfix) with ESMTP id B0FFE8FC37 for ; Fri, 10 Apr 2009 07:31:37 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by rv-out-0506.google.com with SMTP id l9so923288rvb.43 for ; Fri, 10 Apr 2009 00:31:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=dkWodICQHEX4lixaVoqBn84iPO0VyC2NKTSdw1h0wlU=; b=PIAP8gWnbgERB6OwIU/OVYSowV1b+vmEALnp4Y2w+VsMBZncPKid/ayiGdIhsrrpOq ueWI2ppn0zkhVmpukou75xRYCgRYOn8NG6sAAfxQL4MfWxVRTEIJS3NrVqpzC8PSLCLA MGTnjwhsBQRqf2tgBBsYThK1aXDSmXF2+M4l0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=RWZyyNasYq6HJJ6ORWkSzcnwqQ7UtpDzm8ckzwbZVcy1ALQ0jMTnT75O1m9mYKvZpo M+KeZGuKT8cIiLr/tgTA9SW/ufjbdhyK11NL26iv3R09tBTIi/cGwqqopEcHlBE/lGco jAVwf8AArgAKtq4Z0ePNq1ZHg/9KSl3m3HiJE= Received: by 10.141.29.14 with SMTP id g14mr1402435rvj.52.1239348697416; Fri, 10 Apr 2009 00:31:37 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ([114.111.62.249]) by mx.google.com with ESMTPS id c20sm3145629rvf.40.2009.04.10.00.31.35 (version=SSLv3 cipher=RC4-MD5); Fri, 10 Apr 2009 00:31:36 -0700 (PDT) Received: by michelle.cdnetworks.co.kr (sSMTP sendmail emulation); Fri, 10 Apr 2009 16:32:59 +0900 From: Pyun YongHyeon Date: Fri, 10 Apr 2009 16:32:59 +0900 To: xer Message-ID: <20090410073259.GK37714@michelle.cdnetworks.co.kr> References: <20090407120032.633E410656D5@hub.freebsd.org> <20090410044340.GJ37714@michelle.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.3i Cc: freebsd-stable@freebsd.org Subject: Re: watchdog timeout X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2009 07:31:38 -0000 On Fri, Apr 10, 2009 at 09:01:15AM +0200, xer wrote: > Thank you Pyun > I found this another one: > http://www.freebsd.org/cgi/query-pr.cgi?pr=129352 > > And it seems a lot different.. which one will bet to try? I think the patch in the PR is not right fix. Drivers should not rearm watchdog timeouts in Tx completion handler, otherwise it would hide root cause of timeouts. if_start handler should be the only place to arm the timer. Try attached patch in previous mail. > Regards > > -------------------------------------------------- > From: "Pyun YongHyeon" > Sent: Friday, April 10, 2009 6:43 AM > To: "xer" > Cc: > Subject: Re: watchdog timeout > > > > >I vaguely remember there were a couple of reports on xl(4) watchdog > >timeouts. I'm not sure this came from missing Tx interrupts but > >would you try attached patch? > >Note, it was generated against HEAD and you should experiment the > >attached patch on local box prior to applying to your production > >server. > > From owner-freebsd-stable@FreeBSD.ORG Fri Apr 10 08:12:11 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3734A1065670; Fri, 10 Apr 2009 08:12:11 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 452608FC15; Fri, 10 Apr 2009 08:12:09 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id LAA17254; Fri, 10 Apr 2009 11:12:06 +0300 (EEST) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1] helo=edge.pp.kiev.ua) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1LsBqI-000EQ4-Jw; Fri, 10 Apr 2009 11:12:06 +0300 Message-ID: <49DEFF53.1040306@icyb.net.ua> Date: Fri, 10 Apr 2009 11:12:03 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.19 (X11/20090114) MIME-Version: 1.0 To: sclark46@earthlink.net References: <49DE1F8B.2080400@earthlink.net> <49DE2E6D.5050001@icyb.net.ua> <49DE596E.2050406@earthlink.net> In-Reply-To: <49DE596E.2050406@earthlink.net> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@freebsd.org, freebsd-stable@freebsd.org Subject: Re: 6.x acpi powerbutton X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2009 08:12:11 -0000 on 09/04/2009 23:24 Stephen Clark said the following: > Probably not. But I spent a couple of hours googling without much luck > so I got desperate. ;-) Let me introduce freebsd-acpi@freebsd.org > Is there a reason it doesn't send and event like Linux that can be acted > upon by user space other > than signaling init? I like to have a message written in > /var/log/messages that someone pressed > the powerbutton. I think that for all suspend states except S5 userland is notified via devd mechanism and potentially can veto the suspend. S5 (soft-off) is coded to start shutdown immediately. You can try to hack on acpi_ReqSleepState in sys/dev/acpica/acpi.c. I am not sure what is the reason for this special behavior of S5. But I like it, because it sometimes allows me to perform semi-clean shutdown when X goes crazy. But I also see when it could be useful to have S5 request go through userland. So this could be configurable. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Fri Apr 10 08:34:11 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EA867106566B for ; Fri, 10 Apr 2009 08:34:11 +0000 (UTC) (envelope-from kamikaze@bsdforen.de) Received: from mail.bsdforen.de (bsdforen.de [212.204.60.79]) by mx1.freebsd.org (Postfix) with ESMTP id A14508FC12 for ; Fri, 10 Apr 2009 08:34:11 +0000 (UTC) (envelope-from kamikaze@bsdforen.de) Received: from mobileKamikaze.norad (unknown [88.130.220.163]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.bsdforen.de (Postfix) with ESMTP id DD93C8A00D1; Fri, 10 Apr 2009 10:33:56 +0200 (CEST) Message-ID: <49DF0478.3020902@bsdforen.de> Date: Fri, 10 Apr 2009 10:34:00 +0200 From: Dominic Fandrey User-Agent: Thunderbird 2.0.0.21 (X11/20090408) MIME-Version: 1.0 To: miwi@FreeBSD.org, freebsd-stable@freebsd.org References: <200904091819.n39IJjDb027358@freefall.freebsd.org> In-Reply-To: <200904091819.n39IJjDb027358@freefall.freebsd.org> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: Re: ports/133541: [maintainer-update] www/xpi-modify_headers X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2009 08:34:12 -0000 miwi@FreeBSD.org wrote: > Synopsis: [maintainer-update] www/xpi-modify_headers > > State-Changed-From-To: open->feedback > State-Changed-By: miwi > State-Changed-When: Thu Apr 9 18:19:08 UTC 2009 > State-Changed-Why: > > Howdy, > > Patch rejected: > http://64bit.miwibox.org/index.php?action=describe_port&id=2152 > http://32bit.miwibox.org/index.php?action=describe_port&id=2042 > OK, this really sucks. diff has lost the -P option, that I've been relying on. Compare: http://www.freebsd.org/cgi/man.cgi?query=diff&manpath=FreeBSD+6.0-RELEASE http://www.freebsd.org/cgi/man.cgi?query=diff&manpath=FreeBSD+7.1-RELEASE It used to say: -P When comparing directories, if a file appears only in the second directory of the two, treat it as present but empty in the other. Now it's gone. Regression? > > http://www.freebsd.org/cgi/query-pr.cgi?pr=133541 > From owner-freebsd-stable@FreeBSD.ORG Fri Apr 10 10:13:22 2009 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 486DA106566B for ; Fri, 10 Apr 2009 10:13:22 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.230]) by mx1.freebsd.org (Postfix) with ESMTP id 0FE828FC19 for ; Fri, 10 Apr 2009 10:13:21 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by rv-out-0506.google.com with SMTP id l9so964214rvb.43 for ; Fri, 10 Apr 2009 03:13:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=36MkPs425K87IXjJwkN+TXHjBVJfcSfi0nl7YpGEHhI=; b=n3G4be4m+fPXmj29pzeoBaoLvsKVbV4byMDnT+EBuN6XlJNJwUBmyNZgTcN4kBBV/c U08X30TmkfREBoSz8w/rZFIc+QaYUOdUp8PFNrOovKGw7iXGswXv7jaNdFmcYPZnJgmw muLZpwy1OWCLqRuxZd9cTBNdC/Mk72zV/NFn4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=mVap8D067596BCXgFmT8gUK5BCbImWy1w9BvdmUgOGY12g9ydnDRyZDwLowvQwpGtd 0XiVV4u8L5LxBDiKgkWKziGDIKOeB7v3EFzbh28cTDyx0mDsZaOXOXomBEWSIfMWuGti ytKlB0qRiVds3vCAWKkmSi+pB4zdRsk/PsiS8= Received: by 10.140.134.10 with SMTP id h10mr1141607rvd.93.1239358401716; Fri, 10 Apr 2009 03:13:21 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ([114.111.62.249]) by mx.google.com with ESMTPS id c20sm3466298rvf.50.2009.04.10.03.13.20 (version=SSLv3 cipher=RC4-MD5); Fri, 10 Apr 2009 03:13:21 -0700 (PDT) Received: by michelle.cdnetworks.co.kr (sSMTP sendmail emulation); Fri, 10 Apr 2009 19:14:45 +0900 From: Pyun YongHyeon Date: Fri, 10 Apr 2009 19:14:45 +0900 To: Bjoern Koenig Message-ID: <20090410101445.GL37714@michelle.cdnetworks.co.kr> References: <70ba25e4f1a5e43ab8d99b361235dda2.squirrel@webmail.alpha-tierchen.de> <20090409000427.GD37714@michelle.cdnetworks.co.kr> <2f68678165f20f2e1dae10cb0e63761d.squirrel@webmail.alpha-tierchen.de> <20090409072309.GF37714@michelle.cdnetworks.co.kr> <37a8d3252c3d50682f4fb790e30e09f3.squirrel@webmail.alpha-tierchen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <37a8d3252c3d50682f4fb790e30e09f3.squirrel@webmail.alpha-tierchen.de> User-Agent: Mutt/1.4.2.3i Cc: stable@freebsd.org Subject: Re: fxp: stalled transfers X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2009 10:13:22 -0000 On Fri, Apr 10, 2009 at 08:46:08AM +0200, Bjoern Koenig wrote: > I wrote: > > > >> If you can easily reproduce the issue, can you capture stalled TCP > >> session with tcpdump on receiving host?(Make sure to disable Rx > >> checksum offload prior to capturing the session.) > > > > I transferred a 256 kiB file and these are the tcpdumps: > > > > http://www.alpha-tierchen.de/~bkoenig/fxp0-with-tso.txt > > http://www.alpha-tierchen.de/~bkoenig/fxp0-without-tso.txt > > > > Actually the transfer doesn't stall although ftp and scp told me so. It > > becomes incredibly slow. It seems like that the chunks are too large and a > > smaller packet will be resent. I decreased the MTU from 1500 to 1492 and > > it works fine with TSO enabled. > > > > I also captured the traffic on my router: > > > > http://www.alpha-tierchen.de/~bkoenig/fxp0-with-tso-router.txt > > http://www.alpha-tierchen.de/~bkoenig/fxp0-without-tso-router.txt > > > > It reveals a suspect information: "truncated-ip - 8 bytes missing!" > > > > I almost suppose that this is a PPPoE-related configuration issue and the > > fxp driver is not necessarily the problem since decreasing the MTU of the > > LAN host solves it. > > Hello, it's me again. :) > > It's not PPPoE-related. I was able to reproduce the behaviour within a > regular LAN from host to host. I also have another symptom which denies > the PPPoE assumption: > > If I set MTU to value X then it doesn't work with MTU X+N anymore. I'll > get the message "N bytes missing!" in the tcpdump output. For example: > > ifconfig fxp0 mtu 1448 # works > ifconfig fxp0 mtu 1412 # still works > ifconfig fxp0 mtu 1448 # doesn't work (36 bytes missing) > ifconfig fxp0 mtu 1400 # works > ifconfig fxp0 mtu 1412 # doesn't work (12 bytes missing) > Hmm, I can't reproduce this. Can you send me a URL to captured data for broken case? From owner-freebsd-stable@FreeBSD.ORG Fri Apr 10 14:53:26 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3A522106564A; Fri, 10 Apr 2009 14:53:26 +0000 (UTC) (envelope-from kamikaze@bsdforen.de) Received: from mail.bsdforen.de (bsdforen.de [212.204.60.79]) by mx1.freebsd.org (Postfix) with ESMTP id E8A578FC1A; Fri, 10 Apr 2009 14:53:25 +0000 (UTC) (envelope-from kamikaze@bsdforen.de) Received: from mobileKamikaze.norad (p5DCF3F99.dip.t-dialin.net [93.207.63.153]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.bsdforen.de (Postfix) with ESMTP id AED5D8A00D1; Fri, 10 Apr 2009 16:53:09 +0200 (CEST) Message-ID: <49DF5D60.9010803@bsdforen.de> Date: Fri, 10 Apr 2009 16:53:20 +0200 From: Dominic Fandrey User-Agent: Thunderbird 2.0.0.21 (X11/20090408) MIME-Version: 1.0 To: Robert Noland References: <1238293386.00093672.1238281804@10.7.7.3> <49CF0803.1070505@FreeBSD.org> <49CF2F8D.6000905@bsdforen.de> <49CF4EB9.60108@FreeBSD.org> <49CF49F5.6010800@bsdforen.de> <49CF615A.6050304@FreeBSD.org> <49CF595A.30805@bsdforen.de> <49CF6B28.2080400@FreeBSD.org> <49CF60AB.4040709@bsdforen.de> <49CF6899.2060002@bsdforen.de> <49CF8E8D.1080604@bsdforen.de> <49CF9C19.3020509@FreeBSD.org> <49D5DA33.4010800@bsdforen.de> <1238778004.65025.30.camel@balrog.2hip.net> In-Reply-To: <1238778004.65025.30.camel@balrog.2hip.net> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Alexander Motin , freebsd-stable@freebsd.org Subject: Re: powerd broken X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2009 14:53:26 -0000 Robert Noland wrote: > I've been working on the Intel vblank / irq issues. Every time I commit > something thinking that I have it resolved, it isn't. So I'm waiting on > hardware to arrive that will let me test this all more thoroughly. I do > have a patch that I think fixes most of the issues on Intel, but the ddx > driver is still doing some silly things that cause issues in some cases. > I *think* the only outstanding issue I have with Intel is if something > is rendering (synced to vblank or not) when the display goes into dpms > sleep, there isn't anything to block that app, so it renders as hard as > it can even though it isn't being displayed. In reality, this probably > isn't a huge issue, but running gears while the display is asleep keeps > the cpu at 100%, which isn't ideal. Normal apps that aren't trying to > draw as fast as they can, shouldn't cause an issue. With the latest drm, the IRQ craziness is gone. However, the crappy performance remains. 2 months ago a RELENG_7 with all packages up to date yielded 124fps in a q3 timedemo that now yields 80fps. Regards From owner-freebsd-stable@FreeBSD.ORG Fri Apr 10 16:32:09 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C51A1106566B for ; Fri, 10 Apr 2009 16:32:09 +0000 (UTC) (envelope-from petefrench@ticketswitch.com) Received: from constantine.ticketswitch.com (constantine.ticketswitch.com [IPv6:2002:57e0:1d4e:1::3]) by mx1.freebsd.org (Postfix) with ESMTP id 8CC648FC0A for ; Fri, 10 Apr 2009 16:32:09 +0000 (UTC) (envelope-from petefrench@ticketswitch.com) Received: from dilbert.rattatosk ([10.64.50.6] helo=dilbert.ticketswitch.com) by constantine.ticketswitch.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LsJeB-000B2q-MP for freebsd-stable@freebsd.org; Fri, 10 Apr 2009 17:32:07 +0100 Received: from petefrench by dilbert.ticketswitch.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LsJeB-000ETQ-LM for freebsd-stable@freebsd.org; Fri, 10 Apr 2009 17:32:07 +0100 To: freebsd-stable@freebsd.org Message-Id: From: Pete French Date: Fri, 10 Apr 2009 17:32:07 +0100 Subject: bce + lagg not working on STABLE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2009 16:32:10 -0000 I just upgraded a test server to STABLE from today (good friday, around mid-day GMT), and though it all came up without errors I could not get any network connectivity out of the machine. The ethernet uses lagg to bindle two bce interfaces together - I know here were updates to the bce drive recently, but I have not been able to try them in isolation. The box in question is an HP ProLiant DL360 G5, and I spent some time trying to get some life out of it, but to no avail. I have had to roll this back for now so can't investigate further unfortunately. Sorry, I know this is a fairly useless bug report, but I wanted to at least get the info out there that this doesn't work. Will try again when I have a bit more access to the maachine. Anyone else seen similar ? -pete. From owner-freebsd-stable@FreeBSD.ORG Fri Apr 10 17:06:03 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 18F1A1065672 for ; Fri, 10 Apr 2009 17:06:03 +0000 (UTC) (envelope-from nate@root.org) Received: from nlpi015.prodigy.net (nlpi015.sbcis.sbc.com [207.115.36.44]) by mx1.freebsd.org (Postfix) with ESMTP id D584B8FC13 for ; Fri, 10 Apr 2009 17:06:02 +0000 (UTC) (envelope-from nate@root.org) Received: from [10.0.5.18] (ppp-71-139-7-44.dsl.snfc21.pacbell.net [71.139.7.44]) (authenticated bits=0) by nlpi015.prodigy.net (8.13.8 smtpauth/dk/map_regex/8.13.8) with ESMTP id n3AGtujO024844; Fri, 10 Apr 2009 11:55:57 -0500 Message-ID: <49DF7A1C.90009@root.org> Date: Fri, 10 Apr 2009 09:55:56 -0700 From: Nate Lawson User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Andriy Gapon References: <49DE1F8B.2080400@earthlink.net> <49DE2E6D.5050001@icyb.net.ua> <49DE596E.2050406@earthlink.net> <49DEFF53.1040306@icyb.net.ua> In-Reply-To: <49DEFF53.1040306@icyb.net.ua> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: sclark46@earthlink.net, freebsd-acpi@freebsd.org, freebsd-stable@freebsd.org Subject: Re: 6.x acpi powerbutton X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2009 17:06:03 -0000 Andriy Gapon wrote: > on 09/04/2009 23:24 Stephen Clark said the following: >> Is there a reason it doesn't send and event like Linux that can be acted >> upon by user space other >> than signaling init? I like to have a message written in >> /var/log/messages that someone pressed >> the powerbutton. > > I think that for all suspend states except S5 userland is notified via > devd mechanism and potentially can veto the suspend. S5 (soft-off) is > coded to start shutdown immediately. You can try to hack on > acpi_ReqSleepState in sys/dev/acpica/acpi.c. > > I am not sure what is the reason for this special behavior of S5. But I > like it, because it sometimes allows me to perform semi-clean shutdown > when X goes crazy. But I also see when it could be useful to have S5 > request go through userland. So this could be configurable. The reason for userland getting into the loop in the first place was to run programs to shut down devices and reinit them after resume. This isn't necessary in the shutdown case because init already sends a signal, as you mention. There's already a mechanism for timing out if userland is not responding, so a suspend will ultimately happen whether or not it answers. However, that waits for a while (1 minute?) and devd used to be optional, so I thought it best to keep the existing S5 behavior (immediate shutdown). It may be ok to enable this for S5 but I don't think it's very useful. -- Nate From owner-freebsd-stable@FreeBSD.ORG Fri Apr 10 17:22:42 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 282FF106564A; Fri, 10 Apr 2009 17:22:42 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from gizmo.2hip.net (gizmo.2hip.net [64.74.207.195]) by mx1.freebsd.org (Postfix) with ESMTP id C5CE88FC20; Fri, 10 Apr 2009 17:22:41 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from [192.168.1.156] (adsl-157-33-136.bna.bellsouth.net [70.157.33.136]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id n3AHLK8L072895 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Apr 2009 13:21:20 -0400 (EDT) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: Dominic Fandrey In-Reply-To: <49DF5D60.9010803@bsdforen.de> References: <1238293386.00093672.1238281804@10.7.7.3> <49CF0803.1070505@FreeBSD.org> <49CF2F8D.6000905@bsdforen.de> <49CF4EB9.60108@FreeBSD.org> <49CF49F5.6010800@bsdforen.de> <49CF615A.6050304@FreeBSD.org> <49CF595A.30805@bsdforen.de> <49CF6B28.2080400@FreeBSD.org> <49CF60AB.4040709@bsdforen.de> <49CF6899.2060002@bsdforen.de> <49CF8E8D.1080604@bsdforen.de> <49CF9C19.3020509@FreeBSD.org> <49D5DA33.4010800@bsdforen.de> <1238778004.65025.30.camel@balrog.2hip.net> <49DF5D60.9010803@bsdforen.de> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-vDa5ChExuD0YclQviR43" Organization: FreeBSD Date: Fri, 10 Apr 2009 12:21:44 -0500 Message-Id: <1239384104.1922.70.camel@balrog.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.24.5 FreeBSD GNOME Team Port X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_PBL, RDNS_DYNAMIC autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: Alexander Motin , freebsd-stable@freebsd.org Subject: Re: powerd broken X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2009 17:22:42 -0000 --=-vDa5ChExuD0YclQviR43 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Fri, 2009-04-10 at 16:53 +0200, Dominic Fandrey wrote: > Robert Noland wrote: > > I've been working on the Intel vblank / irq issues. Every time I commi= t > > something thinking that I have it resolved, it isn't. So I'm waiting o= n > > hardware to arrive that will let me test this all more thoroughly. I d= o > > have a patch that I think fixes most of the issues on Intel, but the dd= x > > driver is still doing some silly things that cause issues in some cases= . > > I *think* the only outstanding issue I have with Intel is if something > > is rendering (synced to vblank or not) when the display goes into dpms > > sleep, there isn't anything to block that app, so it renders as hard as > > it can even though it isn't being displayed. In reality, this probably > > isn't a huge issue, but running gears while the display is asleep keeps > > the cpu at 100%, which isn't ideal. Normal apps that aren't trying to > > draw as fast as they can, shouldn't cause an issue. >=20 > With the latest drm, the IRQ craziness is gone. However, the crappy > performance remains. 2 months ago a RELENG_7 with all packages > up to date yielded 124fps in a q3 timedemo that now yields 80fps. Things are still not quite right with the Intel driver. But performance regressions are reported across Linux as well. A little of this might be us, but most of it is Intel... robert. > Regards --=20 Robert Noland FreeBSD --=-vDa5ChExuD0YclQviR43 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEABECAAYFAknfgCgACgkQM4TrQ4qfRONylQCcCayPPLOJBYn7s+mHuG1BFraH tDIAn17z3tU/ShlFKN6mN4LGc4zPrEIe =hg9S -----END PGP SIGNATURE----- --=-vDa5ChExuD0YclQviR43-- From owner-freebsd-stable@FreeBSD.ORG Fri Apr 10 17:48:27 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 74C471065674 for ; Fri, 10 Apr 2009 17:48:27 +0000 (UTC) (envelope-from jesco.freund@my-universe.com) Received: from mail.my-universe.com (selidor.my-universe.com [87.230.59.102]) by mx1.freebsd.org (Postfix) with ESMTP id 332ED8FC16 for ; Fri, 10 Apr 2009 17:48:27 +0000 (UTC) (envelope-from jesco.freund@my-universe.com) Received: from webmail.my-universe.com (unknown [127.0.40.16]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jesco.freund@my-universe.com) by mail.my-universe.com (Postfix) with ESMTPSA id E097AECD449 for ; Fri, 10 Apr 2009 19:29:52 +0200 (CEST) MIME-Version: 1.0 Date: Fri, 10 Apr 2009 19:29:52 +0200 From: Jesco Freund To: In-Reply-To: <4457FAEE-A54F-4C4A-B625-5EB3A51BD47A@yellowspace.net> References: <4457FAEE-A54F-4C4A-B625-5EB3A51BD47A@yellowspace.net> Message-ID: X-Sender: jesco.freund@my-universe.com User-Agent: RoundCube Webmail/0.2 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="UTF-8" Subject: Re: ZFSKnownProblems - needs revision? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2009 17:48:27 -0000 On Thu, 9 Apr 2009 22:35:06 +0200, Lorenzo Perone wrote: > trying to understand now if > 7.2 is worth a new try, or if, for that matter, the only reasonable > wait is until 8.0. The deadlock issues should be fixed with ZFS v.13 which is only available in CURRENT. AFAIK, RELENG_7 will most probably stick with v.6, so the problems occurring with 7.1 will be most likely the same with 7.2. HTH Jesco From owner-freebsd-stable@FreeBSD.ORG Fri Apr 10 18:30:42 2009 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B93311065670; Fri, 10 Apr 2009 18:30:42 +0000 (UTC) (envelope-from dennis.melentyev@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.155]) by mx1.freebsd.org (Postfix) with ESMTP id 205F88FC12; Fri, 10 Apr 2009 18:30:41 +0000 (UTC) (envelope-from dennis.melentyev@gmail.com) Received: by fg-out-1718.google.com with SMTP id 13so323460fge.12 for ; Fri, 10 Apr 2009 11:30:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=MKDhVJiIx2c5XupHydt914dTRABY+DSEIh8vjuHC37M=; b=S8UkNoZcAl9yINwmeE77kMyR74JcLrW0Opuyd/N1ziK09u8oZ8IfsOEn2z71aU+N3/ irmCbNm/evjZ0HqJLSf/zdmDC1T0TCTfHxUOqWcXTciy2O0rzwCbejg9ru5Odd3CFWCp NVfNaJGQEoPNg1KgMSql4S4bSIut34UhG+XPY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Y1MIwL5bVGLGhY8R1nKZrgvFL3Z0Uc+6GwlBygukRNOudyiHn5kJ0m3SKhX8MxIeLv YrpgLRzsWYPKveobpr5V6pRLxugaYTyP/H+r+A1GIxn+1Ns3/CrTkI/YI6B+o7ie8obC LuN5Wz9Fx4nYUqv9DRfrgpQdGBLv7D6VOiZIU= MIME-Version: 1.0 Received: by 10.86.68.1 with SMTP id q1mr2808456fga.22.1239386324446; Fri, 10 Apr 2009 10:58:44 -0700 (PDT) In-Reply-To: References: Date: Fri, 10 Apr 2009 20:58:44 +0300 Message-ID: From: Dennis Melentyev To: Robert Watson Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: stable@freebsd.org Subject: Re: Appeal for active bug reports relating to TCP, UDP, routing locking in 7-STABLE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2009 18:30:43 -0000 Hi Robert, Could you please have a look into PR 133572? It's pretty critical for me (no incoming VPN to the office). Looks like related to this posting for me. If more info is needed, I'd be happy to provide. Including an ssh access for you, or person you name. /dennis 2009/3/17 Robert Watson : > > Dear all: > > With 7.2 approaching, I wanted to review the set of known network bug > reports (especially panics, hangs, lock order reversals) relating to TCP, > UDP, sockets, and routing in 7-STABLE. > > If you are aware of problems along these that you can confirm definitely > occur with 7-STABLE checked out no earlier than 17 March, 2009, please dr= op > me a private e-mail with a pointer to the thread, PR, or a reminder that > you've sent me the details already. =C2=A0If you don't have a PR open on = the > problem, opening one and forwarding me the receipt so I can grab ownershi= p > would be most welcome. > > I don't promise I can get them fixed by the release, but doing a review a= nd > prioritizing the bugs that are known is a useful step in that direction. = =C2=A0I > am specifically not interested in device driver-related problems, not > because they shouldn't be fixed, but because there's only so much time in > the day and it appears folks like Pyun have it well in hand :-). > > Robert N M Watson > Computer Laboratory > University of Cambridge > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > --=20 Dennis Melentyev From owner-freebsd-stable@FreeBSD.ORG Fri Apr 10 21:43:27 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 256B8106568A for ; Fri, 10 Apr 2009 21:43:27 +0000 (UTC) (envelope-from mat.macy@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 CF3918FC30 for ; Fri, 10 Apr 2009 21:43:26 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: by yx-out-2324.google.com with SMTP id 8so791580yxm.13 for ; Fri, 10 Apr 2009 14:43:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=w83IgSusqhzbLp073IeAq0GKcZRE4esyGdJnHP9rZ+M=; b=ADGdbxdHVHHWxfCFHBMSgyRnRXJt5Vh2E7LipJbWD09Fn8uN7XJgvvwlpJWzDbmEww VAmUqdBei85gNNcSMjfTnXRbHPgeOCCpU70MryN17Icdmkr9vrprfKwXUXxDAd6MUPqs SwXTJ/tFJ3eDxPzcuV3a9Fp3KMUls4BMeDNME= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=gEBX/jb3aJe8QEe1i3EuLaGYzpAP305uOcaa3Dib/trpoctmQIy6tFDWU4V7vmby0D z9R+kjqJRgWptl/sPPkxXiJAQzt117x+TUW8z2xRaGwLMRS3+bw4y79ONqiZC76uYMuQ gb0dU+UPG/Uo3GUBxGizbZuSr02Yu0JVZ2ZN4= MIME-Version: 1.0 Sender: mat.macy@gmail.com Received: by 10.100.173.18 with SMTP id v18mr2399529ane.84.1239398603775; Fri, 10 Apr 2009 14:23:23 -0700 (PDT) In-Reply-To: References: <200904080959.49201.fjwcash@gmail.com> <49DD2B44.5020808@mawer.org> Date: Fri, 10 Apr 2009 14:23:23 -0700 X-Google-Sender-Auth: bd72febd017cef22 Message-ID: <3c1674c90904101423v68d1bb42q5b4ab510cc4cda1d@mail.gmail.com> From: Kip Macy To: Freddie Cash Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org Subject: Re: Network sysctl tuning [was Re: ZFSKnownProblems - needs revision?] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2009 21:43:28 -0000 I think most if not all of the gains are from increasing the maximum tcp socket buffer sizes. You might test it out with only those to confirm. -Kip On Thu, Apr 9, 2009 at 3:42 PM, Freddie Cash wrote: > On Wed, Apr 8, 2009 at 3:55 PM, Antony Mawer wrot= e: >> Freddie Cash wrote: >> ... >>> We've also heavily modified /etc/sysctl.conf and upped a bunch of the >>> network-related sysctls. =A0Doing so increased our SSH throughput from = ~30 >>> Mbits/sec across all connections to over 90 Mbits/sec per SSH connectio= n. >> >> Are you able to share any of these with the list? It would be useful to >> compare as a lot of these tunings people do individually and it would be >> good to allow others to test in their environments to see if they help, = as >> well as potentially adding them to the tuning man-page. > > They're all taken from the HPN-SSH website and various google searches > related to HPN-enabled OpenSSH. > > I don't know exactly what all the different, individual sysctls do, > nor whether this is the most optimal setup, but here's the sysctl.conf > that we use. =A0This is on 2 systems using a quad-port gigabit NIC where > the top two ports are connected via lagg(4) and the bottom two ports > are connected via lagg(4), with the two laggX interfaces on separate > networks. > > I did a bunch of scp/sftp transfers of 100 MB files filled with random > data pulled from /dev/random between these two boxes tweaking the > options one at a time, but didn't do too much in the way of > scientific/empirical measurements and comparisons beyond the > throughput data that scp/sftp shows. > > If there are any glaring errors, gotchas, or "why would you ever do > that"s, let me know. =A0:) > > # General network settings > net.isr.direct=3D1 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0# Wheth= er to enable Direct > Dispatch for netisr > > > # IP options > net.inet.ip.forwarding=3D0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0# Whether to en= able packet > forwarding for NAT/routing > net.inet.ip.process_options=3D0 =A0 =A0 =A0 =A0 =A0 # Disable processing = of IP > options (nothing uses this field) > net.inet.ip.random_id=3D1 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 # Randomise the= IP header ID number > net.inet.ip.redirect=3D0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0# Whether to = allow redirect packets > #net.inet.ip.stealth=3D0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0# Whether to = appear in traceroute output > > > # ICMP options > net.inet.icmp.icmplim=3D200 =A0 =A0 =A0 =A0 =A0 =A0 =A0 # Limit ICMP pack= ets to this > many per second > net.inet.icmp.drop_redirect=3D1 =A0 =A0 =A0 =A0 =A0 # Drop ICMP redirect = packets > net.inet.icmp.log_redirect=3D0 =A0 =A0 =A0 =A0 =A0 =A0# Don't log ICMP re= direct packets > > > # TCP options > net.inet.tcp.blackhole=3D1 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0# Drop packets = destined to unused ports > net.inet.tcp.inflight.enable=3D0 =A0 =A0 =A0 =A0 =A0# Use automatic TCP w= indow-scaling > net.inet.tcp.log_in_vain=3D0 =A0 =A0 =A0 =A0 =A0 =A0 =A0# Don't log the b= lackholed packets > net.inet.tcp.path_mtu_discovery=3D1 =A0 =A0 =A0 # Use ICMP type 3 to find= the MTU to use > net.inet.tcp.recvbuf_max=3D16777216 =A0 =A0 =A0 # The max size of the rec= eive > buffer (16 MB) > net.inet.tcp.recvspace=3D131072 =A0 =A0 =A0 =A0 =A0 # The initial size in= bytes of > the receive buffer > net.inet.tcp.sack.enable=3D1 =A0 =A0 =A0 =A0 =A0 =A0 =A0# Enable Selectiv= e ACKs > net.inet.tcp.sendbuf_max=3D16777216 =A0 =A0 =A0 # The max size of the sen= d buffer > net.inet.tcp.sendspace=3D131072 =A0 =A0 =A0 =A0 =A0 # The initial size in= bytes of > the send buffer > net.inet.tcp.syncookies=3D1 =A0 =A0 =A0 =A0 =A0 =A0 =A0 # Enable SYN cook= ie protection > net.inet.tcp.rfc1323=3D1 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0# Enable RFC1= 323 extensions > (TCP window scaling) > > > # UDP options > net.inet.udp.blackhole=3D1 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0# Drop packets = destined to unused ports > net.inet.udp.checksum=3D1 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 # Enable UDP ch= ecksums > net.inet.udp.log_in_vain=3D0 =A0 =A0 =A0 =A0 =A0 =A0 =A0# Don't log the b= lackholed packets > net.inet.udp.recvspace=3D65536 =A0 =A0 =A0 =A0 =A0 =A0# Size in bytes of = the receive buffer > > > # Debug options > debug.minidump=3D1 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0# Disab= le the small kernel > core dump (only mem in use) > debug.mpsafevfs=3D1 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 # Enable = threaded VFS subsystem > > > # Kernel options > kern.coredump=3D0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 # Disab= le kernel core dumps > kern.ipc.maxsockbuf=3D4194304 =A0 =A0 =A0 =A0 =A0 =A0 # Set the max size = of the > socket buffers (4 MB) > kern.ipc.somaxconn=3D1024 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 # Expand the IP= listen queue > kern.maxvnodes=3D250000 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 # Bump up the= max number of vnodes > > > # PCI bus options > hw.pci.enable_msix=3D1 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0# Enable Me= ssage Signalled > Interrupts - Extended > hw.pci.enable_msi=3D1 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 # Enable Me= ssage Signalled Interrupts > hw.pci.enable_io_modes=3D1 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0# Enable altern= ate I/O access modes > > -- > Freddie Cash > fjwcash@gmail.com > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > --=20 All that is necessary for the triumph of evil is that good men do nothing. Edmund Burke From owner-freebsd-stable@FreeBSD.ORG Sat Apr 11 03:44:44 2009 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DD87C1065672 for ; Sat, 11 Apr 2009 03:44:43 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.186]) by mx1.freebsd.org (Postfix) with ESMTP id 6D8298FC0A for ; Sat, 11 Apr 2009 03:44:43 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by ti-out-0910.google.com with SMTP id u5so1228427tia.3 for ; Fri, 10 Apr 2009 20:44:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=K6o41FTq03I4bnFVcP0P1kQmpiU8fGERQ8+pBVcFGiQ=; b=oEuk7u6nHpWWVPleyS2HxZYqVtr+IuT7zy/ACuxlOyx65259YTeE5AtjbS7sQa6crs Pc3MksD5uFO1E0tk3fMBHJWzgdwvIRmveBSrlGS2SyjUd2kH6DWbSmxJgEHWSnCad/mq MEiWxSJQz1NJQb6aKbTRkBJDB1UHRI7RqwNLE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=an+1qNh8pn4TluyM1ae1aKr6qDyjh9dbbYdxv4+jCFPH+Mo3vKN7zLJiYZ+gAVYbnG aUu6gKLFBpJD4d4euaz4owjAk212m8Wn8C2E9wN8eupm2R9dlaVOrQ4y3qKrqE7q5fwC 8NRPo/pE6AaDidsTOhhtVXj8vq2h41Gmf/cGU= Received: by 10.110.103.16 with SMTP id a16mr5823571tic.7.1239421481032; Fri, 10 Apr 2009 20:44:41 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ([114.111.62.249]) by mx.google.com with ESMTPS id 25sm3785870tif.32.2009.04.10.20.44.38 (version=SSLv3 cipher=RC4-MD5); Fri, 10 Apr 2009 20:44:39 -0700 (PDT) Received: by michelle.cdnetworks.co.kr (sSMTP sendmail emulation); Sat, 11 Apr 2009 12:46:13 +0900 From: Pyun YongHyeon Date: Sat, 11 Apr 2009 12:46:13 +0900 To: Bjoern Koenig Message-ID: <20090411034613.GA54253@michelle.cdnetworks.co.kr> References: <70ba25e4f1a5e43ab8d99b361235dda2.squirrel@webmail.alpha-tierchen.de> <20090409000427.GD37714@michelle.cdnetworks.co.kr> <2f68678165f20f2e1dae10cb0e63761d.squirrel@webmail.alpha-tierchen.de> <20090409072309.GF37714@michelle.cdnetworks.co.kr> <37a8d3252c3d50682f4fb790e30e09f3.squirrel@webmail.alpha-tierchen.de> <20090410101445.GL37714@michelle.cdnetworks.co.kr> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="X1bOJ3K7DJ5YkBrT" Content-Disposition: inline In-Reply-To: <20090410101445.GL37714@michelle.cdnetworks.co.kr> User-Agent: Mutt/1.4.2.3i Cc: stable@freebsd.org Subject: Re: fxp: stalled transfers X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Apr 2009 03:44:44 -0000 --X1bOJ3K7DJ5YkBrT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Apr 10, 2009 at 07:14:45PM +0900, Pyun YongHyeon wrote: > On Fri, Apr 10, 2009 at 08:46:08AM +0200, Bjoern Koenig wrote: > > I wrote: > > > > > >> If you can easily reproduce the issue, can you capture stalled TCP > > >> session with tcpdump on receiving host?(Make sure to disable Rx > > >> checksum offload prior to capturing the session.) > > > > > > I transferred a 256 kiB file and these are the tcpdumps: > > > > > > http://www.alpha-tierchen.de/~bkoenig/fxp0-with-tso.txt > > > http://www.alpha-tierchen.de/~bkoenig/fxp0-without-tso.txt > > > > > > Actually the transfer doesn't stall although ftp and scp told me so. It > > > becomes incredibly slow. It seems like that the chunks are too large and a > > > smaller packet will be resent. I decreased the MTU from 1500 to 1492 and > > > it works fine with TSO enabled. > > > > > > I also captured the traffic on my router: > > > > > > http://www.alpha-tierchen.de/~bkoenig/fxp0-with-tso-router.txt > > > http://www.alpha-tierchen.de/~bkoenig/fxp0-without-tso-router.txt > > > > > > It reveals a suspect information: "truncated-ip - 8 bytes missing!" > > > > > > I almost suppose that this is a PPPoE-related configuration issue and the > > > fxp driver is not necessarily the problem since decreasing the MTU of the > > > LAN host solves it. > > > > Hello, it's me again. :) > > > > It's not PPPoE-related. I was able to reproduce the behaviour within a > > regular LAN from host to host. I also have another symptom which denies > > the PPPoE assumption: > > > > If I set MTU to value X then it doesn't work with MTU X+N anymore. I'll > > get the message "N bytes missing!" in the tcpdump output. For example: > > > > ifconfig fxp0 mtu 1448 # works > > ifconfig fxp0 mtu 1412 # still works > > ifconfig fxp0 mtu 1448 # doesn't work (36 bytes missing) > > ifconfig fxp0 mtu 1400 # works > > ifconfig fxp0 mtu 1412 # doesn't work (12 bytes missing) > > > > Hmm, I can't reproduce this. Can you send me a URL to captured > data for broken case? Ok, I've reproduced it, it seems that it happens when sender and receiver has advertised different MSS. Try attached patch and let me know how it goes on your setup. --X1bOJ3K7DJ5YkBrT Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="fxp.tso.patch" Index: sys/dev/fxp/if_fxp.c =================================================================== --- sys/dev/fxp/if_fxp.c (revision 190876) +++ sys/dev/fxp/if_fxp.c (working copy) @@ -1485,7 +1485,8 @@ * checksum in the first frame driver should compute it. */ ip->ip_sum = 0; - ip->ip_len = htons(ifp->if_mtu); + ip->ip_len = htons(m->m_pkthdr.tso_segsz + (ip->ip_hl << 2) + + (tcp->th_off << 2)); tcp->th_sum = in_pseudo(ip->ip_src.s_addr, ip->ip_dst.s_addr, htons(IPPROTO_TCP + (tcp->th_off << 2) + m->m_pkthdr.tso_segsz)); --X1bOJ3K7DJ5YkBrT-- From owner-freebsd-stable@FreeBSD.ORG Sat Apr 11 08:36:26 2009 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 951C2106564A for ; Sat, 11 Apr 2009 08:36:26 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.187]) by mx1.freebsd.org (Postfix) with ESMTP id 2717B8FC12 for ; Sat, 11 Apr 2009 08:36:25 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by ti-out-0910.google.com with SMTP id u5so1320021tia.3 for ; Sat, 11 Apr 2009 01:36:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=5T2F7uTlxlnCW25h5REm762/Fc/PJZ8qlryDTM1xT8g=; b=pZ7/nAdFh7JDsBgP6Dnp32brzNnss5vnvRH3ksjnepjx57A1j9p5JSjefJk/U8qFPM +uYosraj8MnqDYWozYtOuqmzYkWzvhhIQ+SEXFZXTpCimPzbSPHLhsJpehoxuR1JXb0C XvdMul48ZvTX0p42TNYeXyt+u2rjNnBgRl/ow= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=gyZjmg/l2+RerxbQ+dk4Eo2G1F/gujqQF/ussRrkh4X4pI8JKR/KOFZPSUmyNs39pJ T4McAAN9VJwtOqckftc04rXbTkOEa9F2GvZIG7E+TwtggKWpGgKtAVAv81PnM4VSvgjW LkFpU/ejS6roNp7UDfFUN0tcBVwG7yJz53aLk= Received: by 10.110.69.5 with SMTP id r5mr2554502tia.19.1239438984920; Sat, 11 Apr 2009 01:36:24 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ([114.111.62.249]) by mx.google.com with ESMTPS id y5sm554600tia.17.2009.04.11.01.36.22 (version=SSLv3 cipher=RC4-MD5); Sat, 11 Apr 2009 01:36:23 -0700 (PDT) Received: by michelle.cdnetworks.co.kr (sSMTP sendmail emulation); Sat, 11 Apr 2009 17:37:59 +0900 From: Pyun YongHyeon Date: Sat, 11 Apr 2009 17:37:59 +0900 To: Beat Siegenthaler Message-ID: <20090411083759.GB54253@michelle.cdnetworks.co.kr> References: <49B1AC25.3000700@onetel.com> <27998819.871236382003017.JavaMail.HALO$@halo> <1d001f850903061814k2577f3ccs94be86bcc87b9efd@mail.gmail.com> <49B38AEF.8070909@beatsnet.com> <20090308093653.GD1531@michelle.cdnetworks.co.kr> <49B3FAA3.9010302@beatsnet.com> <20090309000610.GA5039@michelle.cdnetworks.co.kr> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="s2ZSL+KKDSLx8OML" Content-Disposition: inline In-Reply-To: <20090309000610.GA5039@michelle.cdnetworks.co.kr> User-Agent: Mutt/1.4.2.3i Cc: stable@freebsd.org Subject: Re: fxp unusable after make world X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Apr 2009 08:36:26 -0000 --s2ZSL+KKDSLx8OML Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Mon, Mar 09, 2009 at 09:06:10AM +0900, Pyun YongHyeon wrote: > On Sun, Mar 08, 2009 at 06:04:35PM +0100, Beat Siegenthaler wrote: > > Pyun YongHyeon wrote: > > > > > > > > I touched fxp(4) to add more hardware assistance so it could cause > > > problems on your box. Please show me dmesg output and > > > "ifconfig fxp0" > > > output. > > > > > > If you doubt checksum offloading or TSO issues, try > > > "ifconfig fxp0 -tso -txcsum -rxcsum". > > > > > And the command above fixed your issue? > It seems that fxp(4) has a TSO bug. Would you try attached patch? (Make sure to enable TSO to check whether the issue was resolved.) --s2ZSL+KKDSLx8OML Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="fxp.tso.patch" Index: sys/dev/fxp/if_fxp.c =================================================================== --- sys/dev/fxp/if_fxp.c (revision 190876) +++ sys/dev/fxp/if_fxp.c (working copy) @@ -1485,7 +1485,8 @@ * checksum in the first frame driver should compute it. */ ip->ip_sum = 0; - ip->ip_len = htons(ifp->if_mtu); + ip->ip_len = htons(m->m_pkthdr.tso_segsz + (ip->ip_hl << 2) + + (tcp->th_off << 2)); tcp->th_sum = in_pseudo(ip->ip_src.s_addr, ip->ip_dst.s_addr, htons(IPPROTO_TCP + (tcp->th_off << 2) + m->m_pkthdr.tso_segsz)); --s2ZSL+KKDSLx8OML-- From owner-freebsd-stable@FreeBSD.ORG Sat Apr 11 11:10:46 2009 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7D1EF1065670 for ; Sat, 11 Apr 2009 11:10:46 +0000 (UTC) (envelope-from raul@b2n.org) Received: from mail1.isdefe.es (mail1.isdefe.es [194.15.213.239]) by mx1.freebsd.org (Postfix) with ESMTP id 3B0F58FC1D for ; Sat, 11 Apr 2009 11:10:46 +0000 (UTC) (envelope-from raul@b2n.org) Received: from mail1.isdefe.es (mail1.isdefe.es [127.0.0.1]) by localhost.isdefe.es (Postfix) with ESMTP id 7450F2BAC26 for ; Sat, 11 Apr 2009 12:55:11 +0200 (CEST) Received: from turing.b2n.org (unknown [172.24.1.14]) by mail1.isdefe.es (Postfix) with ESMTP id 5B0E62BAC24 for ; Sat, 11 Apr 2009 12:55:11 +0200 (CEST) Received: from [10.10.10.14] (ws.pinlabs.b2n.org [10.10.10.14]) by turing.b2n.org (Postfix) with ESMTP id 7600832AC09 for ; Sat, 11 Apr 2009 12:55:29 +0200 (CEST) From: Raul To: freebsd-stable@FreeBSD.org Content-Type: text/plain Date: Sat, 11 Apr 2009 12:55:30 +0200 Message-Id: <1239447330.7119.36.camel@ws.pinlabs.b2n.org> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 7bit Cc: Subject: problems with 7.2, vm_page_insert: page already inserted X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Apr 2009 11:10:46 -0000 Hello! Last night I've switched at home from 7.1R to RELENG_7. Everything went smooth but 2 hours 46 mins later the box paniced with: vm_page_insert: page already inserted. The 1688MB dump stopped at 1417 ... there is no dump available :/. The box, a dell t105, has been rock solid (as freeBSD) until yesterday since 7.0R. It runs a bit complex mixture of things: xorp, racoon, ipsec, pf, several openvpn udp tunnels, pppoe client (mpd5), intensive use of zfs, some nfs, samba, apache, php, postgresql, mysql, dovecot, postfix ... well, the list is never ending and I have no idea where to start to track the problem. dmesg available at http://pastebin.com/m4d640f31 feel free to ask for whatever more info HELP! Thanks a lot in advance, Cheers. From owner-freebsd-stable@FreeBSD.ORG Sat Apr 11 11:49:04 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AB5B110656CA for ; Sat, 11 Apr 2009 11:49:04 +0000 (UTC) (envelope-from kamikaze@bsdforen.de) Received: from mail.bsdforen.de (bsdforen.de [212.204.60.79]) by mx1.freebsd.org (Postfix) with ESMTP id 6C9DC8FC18 for ; Sat, 11 Apr 2009 11:49:04 +0000 (UTC) (envelope-from kamikaze@bsdforen.de) Received: from mobileKamikaze.norad (p5DCF1E16.dip.t-dialin.net [93.207.30.22]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.bsdforen.de (Postfix) with ESMTP id 7EF468A00D1 for ; Sat, 11 Apr 2009 13:48:42 +0200 (CEST) Message-ID: <49E083AD.5030608@bsdforen.de> Date: Sat, 11 Apr 2009 13:49:01 +0200 From: Dominic Fandrey User-Agent: Thunderbird 2.0.0.21 (X11/20090408) MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <200904091819.n39IJjDb027358@freefall.freebsd.org> In-Reply-To: <200904091819.n39IJjDb027358@freefall.freebsd.org> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: diff regression X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Apr 2009 11:49:05 -0000 miwi@FreeBSD.org wrote: > Synopsis: [maintainer-update] www/xpi-modify_headers > > State-Changed-From-To: open->feedback > State-Changed-By: miwi > State-Changed-When: Thu Apr 9 18:19:08 UTC 2009 > State-Changed-Why: > > Howdy, > > Patch rejected: > http://64bit.miwibox.org/index.php?action=describe_port&id=2152 > http://32bit.miwibox.org/index.php?action=describe_port&id=2042 > OK, this really sucks. diff has lost the -P option, that I've been relying on. Compare: http://www.freebsd.org/cgi/man.cgi?query=diff&manpath=FreeBSD+6.0-RELEASE http://www.freebsd.org/cgi/man.cgi?query=diff&manpath=FreeBSD+7.1-RELEASE It used to say: -P When comparing directories, if a file appears only in the second directory of the two, treat it as present but empty in the other. Now it's gone. Regression? > > http://www.freebsd.org/cgi/query-pr.cgi?pr=133541 > _______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From owner-freebsd-stable@FreeBSD.ORG Sat Apr 11 12:18:39 2009 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7B328106566B for ; Sat, 11 Apr 2009 12:18:39 +0000 (UTC) (envelope-from bkoenig@alpha-tierchen.de) Received: from alpha-tierchen.de (alpha-tierchen.de [88.198.145.202]) by mx1.freebsd.org (Postfix) with ESMTP id 39EA28FC14 for ; Sat, 11 Apr 2009 12:18:39 +0000 (UTC) (envelope-from bkoenig@alpha-tierchen.de) Received: from webmail.alpha-tierchen.de (alpha-tierchen.de [88.198.145.202]) by alpha-tierchen.de (Postfix) with ESMTP id C9BE5239252; Sat, 11 Apr 2009 14:18:37 +0200 (CEST) Received: from 212.202.40.56 (SquirrelMail authenticated user bkoenig) by webmail.alpha-tierchen.de with HTTP; Sat, 11 Apr 2009 14:18:37 +0200 (CEST) Message-ID: In-Reply-To: <20090411034613.GA54253@michelle.cdnetworks.co.kr> References: <70ba25e4f1a5e43ab8d99b361235dda2.squirrel@webmail.alpha-tierchen.de> <20090409000427.GD37714@michelle.cdnetworks.co.kr> <2f68678165f20f2e1dae10cb0e63761d.squirrel@webmail.alpha-tierchen.de> <20090409072309.GF37714@michelle.cdnetworks.co.kr> <37a8d3252c3d50682f4fb790e30e09f3.squirrel@webmail.alpha-tierchen.de> <20090410101445.GL37714@michelle.cdnetworks.co.kr> <20090411034613.GA54253@michelle.cdnetworks.co.kr> Date: Sat, 11 Apr 2009 14:18:37 +0200 (CEST) From: "Bjoern Koenig" To: pyunyh@gmail.com User-Agent: SquirrelMail/1.4.17 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: stable@freebsd.org Subject: Re: fxp: stalled transfers X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Apr 2009 12:18:39 -0000 Pyun YongHyeon wrote: > Ok, I've reproduced it, it seems that it happens when sender and > receiver has advertised different MSS. Try attached patch and let > me know how it goes on your setup. The patch works. The problem is gone. Thank you. Björn From owner-freebsd-stable@FreeBSD.ORG Sat Apr 11 12:42:57 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CC66C106567A for ; Sat, 11 Apr 2009 12:42:57 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.delphij.net (delphij-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:2c9::2]) by mx1.freebsd.org (Postfix) with ESMTP id 6BB9B8FC23 for ; Sat, 11 Apr 2009 12:42:57 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [211.166.10.233]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tarsier.delphij.net (Postfix) with ESMTPS id 08E4028449 for ; Sat, 11 Apr 2009 20:42:56 +0800 (CST) Received: from localhost (tarsier.geekcn.org [211.166.10.233]) by tarsier.geekcn.org (Postfix) with ESMTP id 9D066EDDBA8; Sat, 11 Apr 2009 20:42:55 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([211.166.10.233]) by localhost (mail.geekcn.org [211.166.10.233]) (amavisd-new, port 10024) with ESMTP id 8HzcoLUkPmnz; Sat, 11 Apr 2009 20:42:49 +0800 (CST) Received: from charlie.delphij.net (unknown [219.142.131.213]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTPSA id 9E3DDEC2699; Sat, 11 Apr 2009 20:42:49 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=fTLn7kLrsze78CcrCj42XLRd0VjQkDpoOih7BE17csXH2pH3o7WdvuuuLLr0WNbvj 0vuwhamwZq/CrfUqVGbxA== Message-ID: <49E09045.30904@delphij.net> Date: Sat, 11 Apr 2009 20:42:45 +0800 From: Xin LI User-Agent: Thunderbird 2.0.0.14 (X11/20080603) MIME-Version: 1.0 To: Dominic Fandrey References: <200904091819.n39IJjDb027358@freefall.freebsd.org> <49E083AD.5030608@bsdforen.de> In-Reply-To: <49E083AD.5030608@bsdforen.de> X-Enigmail-Version: 0.95.6 OpenPGP: url=http://www.delphij.net/delphij.asc Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: diff regression X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Apr 2009 12:42:58 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dominic Fandrey wrote: | miwi@FreeBSD.org wrote: |> Synopsis: [maintainer-update] www/xpi-modify_headers |> |> State-Changed-From-To: open->feedback |> State-Changed-By: miwi |> State-Changed-When: Thu Apr 9 18:19:08 UTC 2009 |> State-Changed-Why: |> |> Howdy, |> |> Patch rejected: |> http://64bit.miwibox.org/index.php?action=describe_port&id=2152 |> http://32bit.miwibox.org/index.php?action=describe_port&id=2042 |> | | OK, this really sucks. diff has lost the -P option, that I've been | relying on. Compare: | http://www.freebsd.org/cgi/man.cgi?query=diff&manpath=FreeBSD+6.0-RELEASE | http://www.freebsd.org/cgi/man.cgi?query=diff&manpath=FreeBSD+7.1-RELEASE | | It used to say: | -P When comparing directories, if a file appears only in the second | directory of the two, treat it as present but empty in the | other. | | Now it's gone. Regression? What's wrong with -N? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkngkEUACgkQOfuToMruuMB4MwCdGvD/nC/YGkq0hYeqyq06dyPY 3JUAn399negHDECAUmTQFM/5KpmBP8Q1 =pRzw -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Sat Apr 11 12:51:38 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A29AE106566B for ; Sat, 11 Apr 2009 12:51:38 +0000 (UTC) (envelope-from kamikaze@bsdforen.de) Received: from mail.bsdforen.de (bsdforen.de [212.204.60.79]) by mx1.freebsd.org (Postfix) with ESMTP id 61A8E8FC1E for ; Sat, 11 Apr 2009 12:51:38 +0000 (UTC) (envelope-from kamikaze@bsdforen.de) Received: from mobileKamikaze.norad (p5DCF1E16.dip.t-dialin.net [93.207.30.22]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.bsdforen.de (Postfix) with ESMTP id 717B28A012C; Sat, 11 Apr 2009 14:51:16 +0200 (CEST) Message-ID: <49E09258.1040103@bsdforen.de> Date: Sat, 11 Apr 2009 14:51:36 +0200 From: Dominic Fandrey User-Agent: Thunderbird 2.0.0.21 (X11/20090408) MIME-Version: 1.0 To: Xin LI References: <200904091819.n39IJjDb027358@freefall.freebsd.org> <49E083AD.5030608@bsdforen.de> <49E09045.30904@delphij.net> In-Reply-To: <49E09045.30904@delphij.net> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: diff regression X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Apr 2009 12:51:38 -0000 Xin LI wrote: > Dominic Fandrey wrote: > | miwi@FreeBSD.org wrote: > |> Synopsis: [maintainer-update] www/xpi-modify_headers > |> > |> State-Changed-From-To: open->feedback > |> State-Changed-By: miwi > |> State-Changed-When: Thu Apr 9 18:19:08 UTC 2009 > |> State-Changed-Why: > |> > |> Howdy, > |> > |> Patch rejected: > |> http://64bit.miwibox.org/index.php?action=describe_port&id=2152 > |> http://32bit.miwibox.org/index.php?action=describe_port&id=2042 > |> > | > | OK, this really sucks. diff has lost the -P option, that I've been > | relying on. Compare: > | http://www.freebsd.org/cgi/man.cgi?query=diff&manpath=FreeBSD+6.0-RELEASE > | http://www.freebsd.org/cgi/man.cgi?query=diff&manpath=FreeBSD+7.1-RELEASE > | > | It used to say: > | -P When comparing directories, if a file appears only in > the second > | directory of the two, treat it as present but empty > in the > | other. > | > | Now it's gone. Regression? > > What's wrong with -N? Nothing, I just didn't know about -N. From owner-freebsd-stable@FreeBSD.ORG Sat Apr 11 12:53:59 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E58221065679 for ; Sat, 11 Apr 2009 12:53:59 +0000 (UTC) (envelope-from swhetzel@gmail.com) Received: from mail-qy0-f134.google.com (mail-qy0-f134.google.com [209.85.221.134]) by mx1.freebsd.org (Postfix) with ESMTP id 9F51E8FC15 for ; Sat, 11 Apr 2009 12:53:59 +0000 (UTC) (envelope-from swhetzel@gmail.com) Received: by qyk40 with SMTP id 40so2487212qyk.3 for ; Sat, 11 Apr 2009 05:53:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=sQfx7vLOp3b+ZPN2ZxfuXsrvnUV/t+ClKHDV5FrBlkU=; b=DRM75TPyLTL5mfEc00/BaO7Zs+aGg04brV/vRxcDciS9AdguhpRBWq3oUSeMeb7MNm ocwcKf5DiZD4fEMSn/XBTzjv1tg9HP0xVNHca8LDsAWA0B8MX4gUSJSsgO/UYjIVCtmx kQuU8NF7pSuHuhdycDUU6KnBBa+qsVgi/QnNg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=ryj/oaK/ojTmhzV0D0i/G7DWLH3HaJfVKFfpgvOphVezI9R15ZcYmSM8qLqTJlQR5+ 0rN9S2/ngQKHWIOzy7JPh3vjTstnXlJTLouSB+qa9g8r0D5wIxIgkwGNQnsdy2g/6k6F RFqiYC2FOM0INrCtVZZG0xv6fEoOtpFRFk4ds= MIME-Version: 1.0 Received: by 10.220.73.6 with SMTP id o6mr5478580vcj.49.1239452571701; Sat, 11 Apr 2009 05:22:51 -0700 (PDT) In-Reply-To: <49E083AD.5030608@bsdforen.de> References: <200904091819.n39IJjDb027358@freefall.freebsd.org> <49E083AD.5030608@bsdforen.de> Date: Sat, 11 Apr 2009 07:22:51 -0500 Message-ID: <790a9fff0904110522r23e8b868l753fc59fb0838402@mail.gmail.com> From: Scot Hetzel To: Dominic Fandrey Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org Subject: Re: diff regression X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Apr 2009 12:54:00 -0000 On Sat, Apr 11, 2009 at 6:49 AM, Dominic Fandrey wro= te: > OK, this really sucks. diff has lost the -P option, that I've been > relying on. Compare: > http://www.freebsd.org/cgi/man.cgi?query=3Ddiff&manpath=3DFreeBSD+6.0-REL= EASE > http://www.freebsd.org/cgi/man.cgi?query=3Ddiff&manpath=3DFreeBSD+7.1-REL= EASE > > It used to say: > =A0 =A0 =A0 -P =A0 =A0 When comparing directories, if a file appears only= in the second > =A0 =A0 =A0 =A0 =A0 =A0 =A0directory of the two, treat it =A0as =A0presen= t =A0but =A0empty =A0in =A0the > =A0 =A0 =A0 =A0 =A0 =A0 =A0other. > > Now it's gone. Regression? > >> It looks like the -P option was removed from diff between FreeBSD 6.2-Release and FreeBSD 6.3-Release (diffutils 2.8.7). You can use --unidirectional-new-file instead. Scot From owner-freebsd-stable@FreeBSD.ORG Sat Apr 11 13:31:18 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E56001065688 for ; Sat, 11 Apr 2009 13:31:18 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.delphij.net (delphij-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:2c9::2]) by mx1.freebsd.org (Postfix) with ESMTP id 83B828FC18 for ; Sat, 11 Apr 2009 13:31:18 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [211.166.10.233]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tarsier.delphij.net (Postfix) with ESMTPS id 54DA628449 for ; Sat, 11 Apr 2009 21:31:17 +0800 (CST) Received: from localhost (tarsier.geekcn.org [211.166.10.233]) by tarsier.geekcn.org (Postfix) with ESMTP id 0B3E2EBBF31; Sat, 11 Apr 2009 21:31:17 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([211.166.10.233]) by localhost (mail.geekcn.org [211.166.10.233]) (amavisd-new, port 10024) with ESMTP id EWiPqqp6PNTX; Sat, 11 Apr 2009 21:31:11 +0800 (CST) Received: from charlie.delphij.net (unknown [219.142.131.213]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTPSA id E2310EBA909; Sat, 11 Apr 2009 21:31:10 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=WgGRwwzuwsf1RGsldMQ4204HIOsUIMJVr99dRYgfVtYAdDkUZqYnU94tLSdjD4xf4 E3GApvddVsIp0ffqXWDqA== Message-ID: <49E09B9E.2010002@delphij.net> Date: Sat, 11 Apr 2009 21:31:10 +0800 From: Xin LI User-Agent: Thunderbird 2.0.0.14 (X11/20080603) MIME-Version: 1.0 To: Dominic Fandrey References: <200904091819.n39IJjDb027358@freefall.freebsd.org> <49E083AD.5030608@bsdforen.de> <49E09045.30904@delphij.net> <49E09258.1040103@bsdforen.de> In-Reply-To: <49E09258.1040103@bsdforen.de> X-Enigmail-Version: 0.95.6 OpenPGP: url=http://www.delphij.net/delphij.asc Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: diff regression X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Apr 2009 13:31:19 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dominic Fandrey wrote: | Xin LI wrote: |> Dominic Fandrey wrote: |> | miwi@FreeBSD.org wrote: |> |> Synopsis: [maintainer-update] www/xpi-modify_headers |> |> |> |> State-Changed-From-To: open->feedback |> |> State-Changed-By: miwi |> |> State-Changed-When: Thu Apr 9 18:19:08 UTC 2009 |> |> State-Changed-Why: |> |> |> |> Howdy, |> |> |> |> Patch rejected: |> |> http://64bit.miwibox.org/index.php?action=describe_port&id=2152 |> |> http://32bit.miwibox.org/index.php?action=describe_port&id=2042 |> |> |> | |> | OK, this really sucks. diff has lost the -P option, that I've been |> | relying on. Compare: |> | http://www.freebsd.org/cgi/man.cgi?query=diff&manpath=FreeBSD+6.0-RELEASE |> | http://www.freebsd.org/cgi/man.cgi?query=diff&manpath=FreeBSD+7.1-RELEASE |> | |> | It used to say: |> | -P When comparing directories, if a file appears only in |> the second |> | directory of the two, treat it as present but empty |> in the |> | other. |> | |> | Now it's gone. Regression? |> |> What's wrong with -N? | | Nothing, I just didn't know about -N. I'm not very sure, are the two option functionally same? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkngm54ACgkQOfuToMruuMBn0gCfd/NMu8to+3fG1oaAqjukmHKk PB4AnirvAUQzu1XPWgzF2XHcvuhSIWTA =LqUx -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Sat Apr 11 13:56:14 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3C8651065673 for ; Sat, 11 Apr 2009 13:56:14 +0000 (UTC) (envelope-from swhetzel@gmail.com) Received: from mail-qy0-f134.google.com (mail-qy0-f134.google.com [209.85.221.134]) by mx1.freebsd.org (Postfix) with ESMTP id E85F88FC2D for ; Sat, 11 Apr 2009 13:56:13 +0000 (UTC) (envelope-from swhetzel@gmail.com) Received: by qyk40 with SMTP id 40so2506268qyk.3 for ; Sat, 11 Apr 2009 06:56:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=S9e/BnSkQcyDkdSrOfK3+Vtv/oDoNlv4F44KXUdYT3Y=; b=t1Pm1r5vSQ9lnWLSetOyv2Zi/6ZTmrko4Lv4gBD2V2bYChYwF3BdNC0FbmC6cLfiUN V4tAb1OgWofbbzVPS0pVISrpJLe/wPc8QxXOzy7cjNhx7iJCXyS1xM+hNvS3bgjFgKui o+LbnB7nLDCDe2Trh6NmFTyMGCWFLqKvxSFbI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=NvnYcTp7VW/Rt0oYuy/la4nX4pk44WVbeU1sFiMSnECA3iK8XRbzSLsklDFaPnu3JB ywh1ecxk08FqsQHBuYbfAVGQlK3fOTRP+iHheG18Jtep7BvLzqNggUi2OA4z4VAMUJ4i R9gQosti6UzS/ZAm46IOr/K3tkvyX1W6tLq4s= MIME-Version: 1.0 Received: by 10.220.97.75 with SMTP id k11mr5514997vcn.39.1239458173317; Sat, 11 Apr 2009 06:56:13 -0700 (PDT) In-Reply-To: <49E09B9E.2010002@delphij.net> References: <200904091819.n39IJjDb027358@freefall.freebsd.org> <49E083AD.5030608@bsdforen.de> <49E09045.30904@delphij.net> <49E09258.1040103@bsdforen.de> <49E09B9E.2010002@delphij.net> Date: Sat, 11 Apr 2009 08:56:13 -0500 Message-ID: <790a9fff0904110656m8505444gc25152129d63ef48@mail.gmail.com> From: Scot Hetzel To: Xin LI Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Dominic Fandrey , freebsd-stable@freebsd.org Subject: Re: diff regression X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Apr 2009 13:56:14 -0000 On 4/11/09, Xin LI wrote: > |> | It used to say: > |> | -P When comparing directories, if a file appears only in > |> the second > |> | directory of the two, treat it as present but empty > |> in the > |> | other. > |> | > |> | Now it's gone. Regression? > |> > |> What's wrong with -N? > | > | Nothing, I just didn't know about -N. > > I'm not very sure, are the two option functionally same? According to the diff.1 man page -N (--new-file) Treat absent files as empty --unidirectional-new-file (-P) Treat absent first files as empty So it would seem the two options are different. Scot From owner-freebsd-stable@FreeBSD.ORG Sat Apr 11 16:37:47 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 44255106564A for ; Sat, 11 Apr 2009 16:37:47 +0000 (UTC) (envelope-from xernet@hotmail.it) Received: from bay0-omc1-s28.bay0.hotmail.com (bay0-omc1-s28.bay0.hotmail.com [65.54.246.100]) by mx1.freebsd.org (Postfix) with ESMTP id 2D1F98FC1D for ; Sat, 11 Apr 2009 16:37:47 +0000 (UTC) (envelope-from xernet@hotmail.it) Received: from BAY126-DS4 ([65.55.131.31]) by bay0-omc1-s28.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 11 Apr 2009 09:37:46 -0700 X-Originating-IP: [79.31.80.15] X-Originating-Email: [xernet@hotmail.it] Message-ID: From: "xer" To: References: <20090409120815.A0FAB10658D2@hub.freebsd.org> In-Reply-To: <20090409120815.A0FAB10658D2@hub.freebsd.org> Date: Sat, 11 Apr 2009 18:37:48 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8064.206 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8064.206 X-OriginalArrivalTime: 11 Apr 2009 16:37:47.0031 (UTC) FILETIME=[D87E3A70:01C9BAC3] Subject: apache 2.0.63 and php5 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: xer List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Apr 2009 16:37:47 -0000 Hello any1 Strange, i have a apache web 2.0.63 and php5 on a 6.4-STABLE, but every time i reboot the server, the php pages does not work at all, especially some self tools made with sh scripts and sudo (tail cat and some php buttons), refresh of the page does not solve the matter.. For fix it, i need to make a simple apachectl stop and start, then the php pages start to works... the logs did tell anything... any ideas? appreciate your help TIA From owner-freebsd-stable@FreeBSD.ORG Sat Apr 11 18:07:29 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6E0DC1065674 for ; Sat, 11 Apr 2009 18:07:29 +0000 (UTC) (envelope-from kometen@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.153]) by mx1.freebsd.org (Postfix) with ESMTP id EF41D8FC1F for ; Sat, 11 Apr 2009 18:07:28 +0000 (UTC) (envelope-from kometen@gmail.com) Received: by fg-out-1718.google.com with SMTP id 13so417346fge.12 for ; Sat, 11 Apr 2009 11:07:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=XKCZirY+vKztbmO0fkEHD38QnAVXWtsmOY3z1gW3ojM=; b=OR04FZcY2uWfSIcihFHrnGL+jMEIC2OM6nYK3pJ4FSmLOHckO4K5Sz/HyiY/GQgcwv 2vWqDJdQGAW15BGty2UL4F3aYkAK3AR7Z/Crp8SCrwZ9HLMcZOfjvIpYaiJ6av4ras8z xbxIDC0i/lWU5ydBUJbb3sp3KK+keDUr1ZYGk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Rh9l4HLCunlCI+PAuMGuirb4YFMaKsf14qc+nyybyYgbXn1JG2/Rw2xD1JClRj2hXK vR7eR/h/pKJpjG3rj3i0VUG6juzHQmQ5wU+qoMLeujRInQxGW3xPCd0+QZuw/mUgSHXw Rsx+tuo+Dgo43zElmlJOzszl4XP+y8/JhgdlE= MIME-Version: 1.0 Received: by 10.86.86.10 with SMTP id j10mr119337fgb.37.1239471403020; Sat, 11 Apr 2009 10:36:43 -0700 (PDT) In-Reply-To: References: <20090409120815.A0FAB10658D2@hub.freebsd.org> Date: Sat, 11 Apr 2009 19:36:42 +0200 Message-ID: From: Claus Guttesen To: xer Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: apache 2.0.63 and php5 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Apr 2009 18:07:30 -0000 > Strange, i have a apache web 2.0.63 and php5 on a 6.4-STABLE, but every time > i reboot the server, the php pages does not work at all, especially some > self tools made with sh scripts and sudo (tail cat and some php buttons), > refresh of the page does not solve the matter.. > > For fix it, i need to make a simple apachectl stop and start, then the php > pages start to works... > > the logs did tell anything... > > any ideas? Could be an apache module which is not started if the hostname is required but not yet known, since ethernet is not up and the server can't perform a dns-query. You can try to add the hostname to /etc/hosts. -- regards Claus When lenity and cruelty play for a kingdom, the gentler gamester is the soonest winner. Shakespeare