From owner-freebsd-current@FreeBSD.ORG Sun Nov 11 00:53:14 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EC17B47C; Sun, 11 Nov 2012 00:53:14 +0000 (UTC) (envelope-from Devin.Teske@fisglobal.com) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) by mx1.freebsd.org (Postfix) with ESMTP id 988AA8FC08; Sun, 11 Nov 2012 00:53:14 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.16]) by ltcfislmsgpa05.fnfis.com (8.14.5/8.14.5) with ESMTP id qAB0rDpP030457 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 10 Nov 2012 18:53:13 -0600 Received: from [10.0.0.101] (10.14.152.61) by smtp.fisglobal.com (10.132.206.16) with Microsoft SMTP Server (TLS) id 14.2.309.2; Sat, 10 Nov 2012 18:53:11 -0600 From: Devin Teske Content-Type: multipart/mixed; boundary="Apple-Mail=_A9909A1E-E6A9-43DD-8CBB-D93045B73375" Subject: HEADS UP: Forth Optimizations Date: Sat, 10 Nov 2012 16:53:10 -0800 Message-ID: To: MIME-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) X-Originating-IP: [10.14.152.61] X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.9.8185, 1.0.431, 0.0.0000 definitions=2012-11-10_08:2012-11-10,2012-11-10,1970-01-01 signatures=0 Cc: Adrian Chadd , Devin Teske X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Devin Teske List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Nov 2012 00:53:15 -0000 --Apple-Mail=_A9909A1E-E6A9-43DD-8CBB-D93045B73375 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" Hi Everybody, Adrian (my co-mentor) wanted some additional eyes/names for review on a pat= ch I'm making to sys/boot/forth (patch attached as patch.txt). The patch makes no changes to user experience or functionality (but _does_ = fix one incident of stack leakage -- among other things). I wrote/tested this over a 2-day period using (as usual) VMware. I booted u= p several times (10+) and fiddled with many things (twiddled every knob, dr= opped to the loader prompt and went back to the menu several times, tried t= hrowing various options like boot_single=3D"YES" and boot_verbose=3D"YES" i= nto loader.conf(5) to make sure dynamic initialization is still working etc= .). The only thing I noticed after applying the patch was a drop in heap usage = (one of the goals of the patch), showing that the optimizations did their j= ob to make a leaner running menu. Also, the code is a lot more readable and= got slightly reduced in size during the process. Can someone help review this for the commit log? --=20 Devin =3D=3D=3D + This patch does not change user experience or functionality + Cleanup syntax, slim-down code, and make things more readable + Introduce new +c! operator and ilk to reduce heap usage/allocations + Fix a stack leak in [unused] cycle_menuitem function while we're here (required misconfiguration and/or missing environment vars to occur) + Add safemode_enabled? safemode_enable and safemode_disable functions + Add singleuser_enabled? singleuser_enable singleuser_disable functions + Add verbose_enabled? verbose_enable and verbose_disable functions + Centralize strings (also to reduce heap usage) PR: Submitted by: Reviewed by: Your_Name_Here, adrian (co-mentor) [pending his/your review] Approved by: adrian (co-mentor) [pending his approval] Obtained from: MFC after: Security: --This line, and those below, will be ignored-- > Description of fields to fill in above: 76 columns --| > PR: If a GNATS PR is affected by the change. > Submitted by: If someone else sent in the change. > Reviewed by: If someone else reviewed your modification. > Approved by: If you needed approval for this commit. > Obtained from: If the change is from a third party. > MFC after: N [day[s]|week[s]|month[s]]. Request a reminder email. > Security: Vulnerability reference (one per line) or description. > Empty fields above will be automatically removed. M forth/menu-commands.4th M forth/menu.4th _____________ The information contained in this message is proprietary and/or confidentia= l. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any ma= nner; and (iii) notify the sender immediately. In addition, please be aware= that any message addressed to our domain is subject to archiving and revie= w by persons other than the intended recipient. Thank you. --Apple-Mail=_A9909A1E-E6A9-43DD-8CBB-D93045B73375 Content-Disposition: attachment; filename="patch.txt" Content-Type: text/plain; name="patch.txt" Content-Transfer-Encoding: quoted-printable Index: menu-commands.4th =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- menu-commands.4th (revision 242835) +++ menu-commands.4th (working copy) @@ -31,6 +31,10 @@ include /boot/menusets.4th variable kernel_state variable root_state =20 +\=20 +\ ACPI +\=20 + : acpi_enable ( -- ) s" set acpi_load=3DYES" evaluate \ XXX deprecated but harmless s" set hint.acpi.0.disabled=3D0" evaluate @@ -58,9 +62,38 @@ variable root_state TRUE \ loop menu again ; =20 +\=20 +\ Safe Mode +\=20 + +: safemode_enabled? ( -- flag ) + s" kern.smp.disabled" getenv -1 <> dup if + swap drop ( c-addr flag -- flag ) + then +; + +: safemode_enable ( -- ) + s" set kern.smp.disabled=3D1" evaluate + s" set hw.ata.ata_dma=3D0" evaluate + s" set hw.ata.atapi_dma=3D0" evaluate + s" set hw.ata.wc=3D0" evaluate + s" set hw.eisa_slots=3D0" evaluate + s" set kern.eventtimer.periodic=3D1" evaluate + s" set kern.geom.part.check_integrity=3D0" evaluate +; + +: safemode_disable ( -- ) + s" kern.smp.disabled" unsetenv + s" hw.ata.ata_dma" unsetenv + s" hw.ata.atapi_dma" unsetenv + s" hw.ata.wc" unsetenv + s" hw.eisa_slots" unsetenv + s" kern.eventtimer.periodic" unsetenv + s" kern.geom.part.check_integrity" unsetenv +; + : init_safemode ( N -- N ) - s" kern.smp.disabled" getenv -1 <> if - drop ( n c-addr -- n ) \ unused + safemode_enabled? if toggle_menuitem ( n -- n ) then ; @@ -70,25 +103,10 @@ variable root_state =20 \ Now we're going to make the change effective =20 - s" toggle_stateN @" \ base name of toggle state var - -rot 2dup 12 + c! rot \ replace 'N' with ASCII numeral - - evaluate 0=3D if - s" kern.smp.disabled" unsetenv - s" hw.ata.ata_dma" unsetenv - s" hw.ata.atapi_dma" unsetenv - s" hw.ata.wc" unsetenv - s" hw.eisa_slots" unsetenv - s" kern.eventtimer.periodic" unsetenv - s" kern.geom.part.check_integrity" unsetenv + dup toggle_stateN @ 0=3D if + safemode_disable else - s" set kern.smp.disabled=3D1" evaluate - s" set hw.ata.ata_dma=3D0" evaluate - s" set hw.ata.atapi_dma=3D0" evaluate - s" set hw.ata.wc=3D0" evaluate - s" set hw.eisa_slots=3D0" evaluate - s" set kern.eventtimer.periodic=3D1" evaluate - s" set kern.geom.part.check_integrity=3D0" evaluate + safemode_enable then =20 menu-redraw @@ -96,9 +114,26 @@ variable root_state TRUE \ loop menu again ; =20 +\=20 +\ Single User Mode +\=20 + +: singleuser_enabled? ( -- flag ) + s" boot_single" getenv -1 <> dup if + swap drop ( c-addr flag -- flag ) + then +; + +: singleuser_enable ( -- ) + s" set boot_single=3DYES" evaluate +; + +: singleuser_disable ( -- ) + s" boot_single" unsetenv +; + : init_singleuser ( N -- N ) - s" boot_single" getenv -1 <> if - drop ( n c-addr -- n ) \ unused + singleuser_enabled? if toggle_menuitem ( n -- n ) then ; @@ -109,21 +144,35 @@ variable root_state =20 \ Now we're going to make the change effective =20 - s" toggle_stateN @" \ base name of toggle state var - -rot 2dup 12 + c! rot \ replace 'N' with ASCII numeral - - evaluate 0=3D if - s" boot_single" unsetenv + dup toggle_stateN @ 0=3D if + singleuser_disable else - s" set boot_single=3DYES" evaluate + singleuser_enable then =20 TRUE \ loop menu again ; =20 +\=20 +\ Verbose Boot +\=20 + +: verbose_enabled? ( -- flag ) + s" boot_verbose" getenv -1 <> dup if + swap drop ( c-addr flag -- flag ) + then +; + +: verbose_enable ( -- ) + s" set boot_verbose=3DYES" evaluate +; + +: verbose_disable ( -- ) + s" boot_verbose" unsetenv +; + : init_verbose ( N -- N ) - s" boot_verbose" getenv -1 <> if - drop ( n c-addr -- n ) \ unused + verbose_enabled? if toggle_menuitem ( n -- n ) then ; @@ -134,18 +183,19 @@ variable root_state =20 \ Now we're going to make the change effective =20 - s" toggle_stateN @" \ base name of toggle state var - -rot 2dup 12 + c! rot \ replace 'N' with ASCII numeral - - evaluate 0=3D if - s" boot_verbose" unsetenv + dup toggle_stateN @ 0=3D if + verbose_disable else - s" set boot_verbose=3DYES" evaluate + verbose_enable then =20 TRUE \ loop menu again ; =20 +\=20 +\ Escape to Prompt +\=20 + : goto_prompt ( N -- N FALSE ) =20 s" set autoboot_delay=3DNO" evaluate @@ -158,11 +208,12 @@ variable root_state FALSE \ exit the menu ; =20 +\=20 +\ Cyclestate (used by kernel/root below) +\=20 + : init_cyclestate ( N K -- N ) - over ( n k -- n k n ) - s" cycle_stateN" ( n k n -- n k n c-addr u ) - -rot tuck 11 + c! swap ( n k n c-addr u -- n k c-addr u ) - evaluate ( n k c-addr u -- n k addr ) + over cycle_stateN ( n k -- n k addr ) begin tuck @ ( n k addr -- n addr k c ) over <> ( n addr k c -- n addr k 0|-1 ) @@ -174,6 +225,10 @@ variable root_state 2drop ( n k addr -- n ) ; =20 +\ +\ Kernel +\=20 + : init_kernel ( N -- N ) kernel_state @ ( n -- n k ) init_cyclestate ( n k -- n ) @@ -185,21 +240,21 @@ variable root_state =20 \ Now we're going to make the change effective =20 - s" cycle_stateN" \ base name of array state var - -rot 2dup 11 + c! rot \ replace 'N' with ASCII numeral - evaluate \ translate name into address - @ \ dereference address into value + dup cycle_stateN @ dup kernel_state ! \ save a copy for re-initialization 48 + \ convert to ASCII numeral =20 s" set kernel=3D${kernel_prefix}${kernel[N]}${kernel_suffix}" - \ command to assemble full kernel-path - -rot tuck 36 + c! swap \ replace 'N' with array index value - evaluate \ sets $kernel to full kernel-path + 36 +c! \ replace 'N' with ASCII numeral + evaluate =20 TRUE \ loop menu again ; =20 +\=20 +\ Root +\=20 + : init_root ( N -- N ) root_state @ ( n -- n k ) init_cyclestate ( n k -- n ) @@ -211,21 +266,21 @@ variable root_state =20 \ Now we're going to make the change effective =20 - s" cycle_stateN" \ base name of array state var - -rot 2dup 11 + c! rot \ replace 'N' with ASCII numeral - evaluate \ translate name into address - @ \ dereference address into value + dup cycle_stateN @ dup root_state ! \ save a copy for re-initialization 48 + \ convert to ASCII numeral =20 s" set root=3D${root_prefix}${root[N]}${root_suffix}" - \ command to assemble root image-path - -rot tuck 30 + c! swap \ replace 'N' with array index value - evaluate \ sets $kernel to full kernel-path + 30 +c! \ replace 'N' with ASCII numeral + evaluate =20 TRUE \ loop menu again ; =20 +\=20 +\ Menusets +\=20 + : goto_menu ( N M -- N TRUE ) menu-unset menuset-loadsetnum ( n m -- n ) Index: menu.4th =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- menu.4th (revision 242835) +++ menu.4th (working copy) @@ -116,6 +116,48 @@ create init_text6 255 allot create init_text7 255 allot create init_text8 255 allot =20 +: +c! ( N C-ADDR/U K -- C-ADDR/U ) + 3 pick 3 pick ( n c-addr/u k -- n c-addr/u k n c-addr ) + rot + c! ( n c-addr/u k n c-addr -- n c-addr/u ) + rot drop ( n c-addr/u -- c-addr/u ) +; + +: menukeyN ( N -- ADDR ) s" menukeyN" 7 +c! evaluate ; +: init_stateN ( N -- ADDR ) s" init_stateN" 10 +c! evaluate ; +: toggle_stateN ( N -- ADDR ) s" toggle_stateN" 12 +c! evaluate ; +: cycle_stateN ( N -- ADDR ) s" cycle_stateN" 11 +c! evaluate ; +: init_textN ( N -- C-ADDR ) s" init_textN" 9 +c! evaluate ; + +: str_loader_menu_title ( -- C-ADDR/U ) s" loader_menu_title" ; +: str_loader_menu_timeout_x ( -- C-ADDR/U ) s" loader_menu_timeout_x" ; +: str_loader_menu_timeout_y ( -- C-ADDR/U ) s" loader_menu_timeout_y" ; +: str_menu_init ( -- C-ADDR/U ) s" menu_init" ; +: str_menu_timeout_command ( -- C-ADDR/U ) s" menu_timeout_command" ; +: str_menu_reboot ( -- C-ADDR/U ) s" menu_reboot" ; +: str_menu_acpi ( -- C-ADDR/U ) s" menu_acpi" ; +: str_menu_options ( -- C-ADDR/U ) s" menu_options" ; +: str_menu_optionstext ( -- C-ADDR/U ) s" menu_optionstext" ; + +: str_menu_init[x] ( -- C-ADDR/U ) s" menu_init[x]" ; +: str_menu_command[x] ( -- C-ADDR/U ) s" menu_command[x]" ; +: str_menu_caption[x] ( -- C-ADDR/U ) s" menu_caption[x]" ; +: str_ansi_caption[x] ( -- C-ADDR/U ) s" ansi_caption[x]" ; +: str_menu_keycode[x] ( -- C-ADDR/U ) s" menu_keycode[x]" ; +: str_toggled_text[x] ( -- C-ADDR/U ) s" toggled_text[x]" ; +: str_toggled_ansi[x] ( -- C-ADDR/U ) s" toggled_ansi[x]" ; +: str_menu_caption[x][y] ( -- C-ADDR/U ) s" menu_caption[x][y]" ; +: str_ansi_caption[x][y] ( -- C-ADDR/U ) s" ansi_caption[x][y]" ; + +: menu_init[x] ( N -- C-ADDR/U ) str_menu_init[x] 10 +c! = ; +: menu_command[x] ( N -- C-ADDR/U ) str_menu_command[x] 13 +c! = ; +: menu_caption[x] ( N -- C-ADDR/U ) str_menu_caption[x] 13 +c! = ; +: ansi_caption[x] ( N -- C-ADDR/U ) str_ansi_caption[x] 13 +c! = ; +: menu_keycode[x] ( N -- C-ADDR/U ) str_menu_keycode[x] 13 +c! = ; +: toggled_text[x] ( N -- C-ADDR/U ) str_toggled_text[x] 13 +c! = ; +: toggled_ansi[x] ( N -- C-ADDR/U ) str_toggled_ansi[x] 13 +c! = ; +: menu_caption[x][y] ( N M -- C-ADDR/U ) str_menu_caption[x][y] 16 +c! = 13 +c! ; +: ansi_caption[x][y] ( N M -- C-ADDR/U ) str_ansi_caption[x][y] 16 +c! = 13 +c! ; + : arch-i386? ( -- BOOL ) \ Returns TRUE (-1) on i386, FALSE (0) = otherwise. s" arch-i386" environment? dup if drop @@ -172,10 +214,7 @@ create init_text8 255 allot \ ASCII numeral equal to user-selected menu item must be on the = stack. \ We do not modify the stack, so the ASCII numeral is left on = top. =20 - s" init_textN" \ base name of buffer - -rot 2dup 9 + c! rot \ replace 'N' with ASCII num - - evaluate c@ 0=3D if + dup init_textN c@ 0=3D if \ NOTE: no need to check toggle_stateN since the first = time we \ are called, we will populate init_textN. Further, we = don't \ need to test whether menu_caption[x] (ansi_caption[x] = when @@ -184,18 +223,15 @@ create init_text8 255 allot =20 \ base name of environment variable loader_color? if - s" ansi_caption[x]" + dup ansi_caption[x] else - s" menu_caption[x]" + dup menu_caption[x] then=09 - -rot 2dup 13 + c! rot \ replace 'x' with ASCII = numeral =20 getenv dup -1 <> if =20 - s" init_textN" \ base name of buffer - 4 pick \ copy ASCII num to top - rot tuck 9 + c! swap \ replace 'N' with ASCII = num - evaluate + 2 pick ( n c-addr/u -- n c-addr/u n ) + init_textN ( n c-addr/u n -- n c-addr/u c-addr ) =20 \ now we have the buffer c-addr on top \ ( followed by c-addr/u of current caption ) @@ -227,36 +263,26 @@ create init_text8 255 allot \ negate the toggled state so that we reverse the flow on = subsequent \ calls. =20 - s" toggle_stateN @" \ base name of toggle state var - -rot 2dup 12 + c! rot \ replace 'N' with ASCII numeral - - evaluate 0=3D if + dup toggle_stateN @ 0=3D if \ state is OFF, toggle to ON =20 - \ base name of toggled text var + dup loader_color? if - s" toggled_ansi[x]" + toggled_ansi[x] else - s" toggled_text[x]" + toggled_text[x] then - -rot 2dup 13 + c! rot \ replace 'x' with ASCII num - getenv dup -1 <> if \ Assign toggled text to menu caption - - \ base name of caption var + 2 pick loader_color? if - s" ansi_caption[x]" + ansi_caption[x] else - s" menu_caption[x]" + menu_caption[x] then - 4 pick \ copy ASCII num to top - rot tuck 13 + c! swap \ replace 'x' with = ASCII num - - setenv \ set new caption + setenv else \ No toggled text, keep the same caption - drop then =20 @@ -264,30 +290,22 @@ create init_text8 255 allot else \ state is ON, toggle to OFF =20 - s" init_textN" \ base name of initial text = buffer - -rot 2dup 9 + c! rot \ replace 'N' with ASCII = numeral - evaluate \ convert string to c-addr - count \ convert c-addr to c-addr/u + dup init_textN count ( n -- n c-addr/u ) =20 - \ base name of caption var + \ Assign init_textN text to menu caption + 2 pick loader_color? if - s" ansi_caption[x]" + ansi_caption[x] else - s" menu_caption[x]" + menu_caption[x] then - 4 pick \ copy ASCII num to top - rot tuck 13 + c! swap \ replace 'x' with ASCII = numeral + setenv =20 - setenv \ set new caption - false \ new value of toggle state var (to be stored = below) + false \ new value of toggle state var (to be stored = below) then =20 \ now we'll store the new toggle state (on top of stack) - s" toggle_stateN" \ base name of toggle state var - 3 pick \ copy ASCII numeral to top - rot tuck 12 + c! swap \ replace 'N' with ASCII numeral - evaluate \ convert string to addr - ! \ store new value + over toggle_stateN ! ; =20 : cycle_menuitem ( N -- N ) \ cycles through array of choices for a = menuitem @@ -295,13 +313,8 @@ create init_text8 255 allot \ ASCII numeral equal to user-selected menu item must be on the = stack. \ We do not modify the stack, so the ASCII numeral is left on = top. =20 - s" cycle_stateN" \ base name of array state var - -rot 2dup 11 + c! rot \ replace 'N' with ASCII numeral + dup cycle_stateN dup @ 1+ \ get value and increment =20 - evaluate \ we now have a pointer to the proper variable - dup @ \ resolve the pointer (but leave it on the stack) - 1+ \ increment the value - \ Before assigning the (incremented) value back to the pointer, \ let's test for the existence of this particular array element. \ If the element exists, we'll store index value and move on. @@ -309,14 +322,12 @@ create init_text8 255 allot =20 dup 48 + \ duplicate Array index and convert to ASCII numeral =20 - \ base name of array caption text + 3 pick swap loader_color? if - s" ansi_caption[x][y]" =20 + ansi_caption[x][y] else - s" menu_caption[x][y]" =20 + menu_caption[x][y] then - -rot tuck 16 + c! swap \ replace 'y' with Array index - 4 pick rot tuck 13 + c! swap \ replace 'x' with menu choice =20 \ Now test for the existence of our incremented array index in = the \ form of $menu_caption[x][y] ($ansi_caption[x][y] with = loader_color @@ -329,19 +340,18 @@ create init_text8 255 allot drop ( incremented array index ) 0 ( new array index that will be stored later ) =20 - \ base name of caption var + 2 pick [char] 0 loader_color? if - s" ansi_caption[x][0]" + ansi_caption[x][y] else - s" menu_caption[x][0]" + menu_caption[x][y] then - 4 pick rot tuck 13 + c! swap \ replace 'x' with menu = choice - getenv dup -1 =3D if \ This is highly unlikely to occur, but to make \ sure that things move along smoothly, allocate \ a temporary NULL string =20 + drop ( getenv cruft ) s" " then then @@ -357,14 +367,14 @@ create init_text8 255 allot \=20 \ Let's perform what we need to with the above. =20 - \ base name of menuitem caption var + \ Assign array value text to menu caption + 4 pick loader_color? if - s" ansi_caption[x]" + ansi_caption[x] else - s" menu_caption[x]" + menu_caption[x] then - 6 pick rot tuck 13 + c! swap \ replace 'x' with menu choice - setenv \ set the new caption + setenv =20 swap ! \ update array state variable ; @@ -400,15 +410,15 @@ create init_text8 255 allot acpipresent? if acpienabled? if loader_color? if - s" toggled_ansi[x]" + str_toggled_ansi[x] else - s" toggled_text[x]" + str_toggled_text[x] then else loader_color? if - s" ansi_caption[x]" + str_ansi_caption[x] else - s" menu_caption[x]" + str_menu_caption[x] then then else @@ -426,7 +436,7 @@ create init_text8 255 allot : menu-create ( -- ) =20 \ Print the frame caption at (x,y) - s" loader_menu_title" getenv dup -1 =3D if + str_loader_menu_title getenv dup -1 =3D if drop s" Welcome to FreeBSD" then 24 over 2 / - 9 at-xy type=20 @@ -435,7 +445,7 @@ create init_text8 255 allot \ constructed dynamically -- as this function could conceivably = set \ the remaining environment variables to construct the menu = entirely). \=20 - s" menu_init" getenv dup -1 <> if + str_menu_init getenv dup -1 <> if evaluate else drop @@ -460,7 +470,7 @@ create init_text8 255 allot \ Initialize the ACPI option status. \=20 0 menuacpi ! - s" menu_acpi" getenv -1 <> if + str_menu_acpi getenv -1 <> if c@ dup 48 > over 57 < and if ( '1' <=3D c1 <=3D '8' ) menuacpi ! arch-i386? if acpipresent? if @@ -468,10 +478,7 @@ create init_text8 255 allot \ Set menu toggle state to active state \ (required by generic toggle_menuitem) \=20 - menuacpi @ - s" acpienabled? toggle_stateN !" - -rot tuck 25 + c! swap - evaluate + acpienabled? menuacpi @ toggle_stateN ! then then else drop @@ -482,7 +489,7 @@ create init_text8 255 allot \ Initialize the menu_options visual separator. \=20 0 menuoptions ! - s" menu_options" getenv -1 <> if + str_menu_options getenv -1 <> if c@ dup 48 > over 57 < and if ( '1' <=3D c1 <=3D '8' ) menuoptions ! else @@ -502,7 +509,7 @@ create init_text8 255 allot \ If the "Options:" separator, print it. dup menuoptions @ =3D if \ Optionally add a reboot option to the menu - s" menu_reboot" getenv -1 <> if + str_menu_reboot getenv -1 <> if drop s" Reboot" printmenuitem menureboot ! true menurebootadded ! @@ -512,7 +519,7 @@ create init_text8 255 allot menurow @ 2 + menurow ! menurow @ menuY @ + at-xy - s" menu_optionstext" getenv dup -1 <> if + str_menu_optionstext getenv dup -1 <> if type else drop ." Options:" @@ -521,17 +528,20 @@ create init_text8 255 allot =20 \ If this is the ACPI menu option, act accordingly. dup menuacpi @ =3D if - acpimenuitem ( -- C-Addr/U | -1 ) + dup acpimenuitem ( n -- n n c-addr/u | n n -1 ) + dup -1 <> if + 13 +c! ( n n c-addr/u -- n ) \ replace = 'x' + else + swap drop ( n n -1 -- n -1 ) + over menu_command[x] unsetenv + then else \ make sure we have not already initialized this = item - s" init_stateN" - -rot 2dup 10 + c! rot \ repace 'N' - evaluate dup @ 0=3D if + dup init_stateN dup @ 0=3D if 1 swap ! =20 \ If this menuitem has an initializer, = run it - s" menu_init[x]" - -rot 2dup 10 + c! rot \ replace 'x' + dup menu_init[x] getenv dup -1 <> if evaluate else @@ -542,34 +552,22 @@ create init_text8 255 allot then =20 loader_color? if - s" ansi_caption[x]" + dup ansi_caption[x] else - s" menu_caption[x]" + dup menu_caption[x] then then =20 - ( C-Addr/U | -1 ) dup -1 <> if - \ replace 'x' with current iteration - -rot 2dup 13 + c! rot - =20 \ test for environment variable getenv dup -1 <> if - printmenuitem ( C-Addr/U -- N ) - =20 - s" menukeyN !" \ generate cmd to store = result - -rot 2dup 7 + c! rot - =20 - evaluate + printmenuitem ( c-addr/u -- n ) + dup menukeyN ! else drop then else drop - - s" menu_command[x]" - -rot 2dup 13 + c! rot ( replace 'x' ) - unsetenv then =20 1+ dup 56 > \ add 1 to iterator, continue if less than = 57 @@ -578,7 +576,7 @@ create init_text8 255 allot =20 \ Optionally add a reboot option to the menu menurebootadded @ true <> if - s" menu_reboot" getenv -1 <> if + str_menu_reboot getenv -1 <> if drop \ no need for the value s" Reboot" \ menu caption (required by = printmenuitem) =20 @@ -596,45 +594,22 @@ create init_text8 255 allot \=20 : menu-timeout-update ( N -- ) =20 - dup 9 > if ( N N 9 -- N ) - drop ( N -- ) - 9 ( maximum: -- N ) - then + \ Enforce minimum/maximum + dup 9 > if drop 9 then + dup 0 < if drop 0 then =20 - dup 0 < if ( N N 0 -- N ) - drop ( N -- ) - 0 ( minimum: -- N ) - then + s" Autoboot in N seconds. [Space] to pause" ( n -- n c-addr/u ) =20 - 48 + ( convert single-digit numeral to ASCII: N 48 -- N ) + 2 pick 0> if + rot 48 + -rot ( n c-addr/u -- n' c-addr/u ) \ convert to = ASCII + 12 +c! ( n' c-addr/u -- c-addr/u ) \ replace = 'N' above =20 - s" Autoboot in N seconds. [Space] to pause" ( N -- N Addr C ) - - 2 pick 48 - 0> if ( N Addr C N 48 -- N Addr C ) - - \ Modify 'N' (Addr+12) above to reflect time-left - - -rot ( N Addr C -- C N Addr ) - tuck ( C N Addr -- C Addr N Addr ) - 12 + ( C Addr N Addr -- C Addr N Addr2 ) - c! ( C Addr N Addr2 -- C Addr ) - swap ( C Addr -- Addr C ) - - menu_timeout_x @ - menu_timeout_y @ - at-xy ( position cursor: Addr C N N -- Addr C ) - - type ( print message: Addr C -- ) - - else ( N Addr C N -- N Addr C ) - - menu_timeout_x @ - menu_timeout_y @ - at-xy ( position cursor: N Addr C N N -- N Addr C ) - - spaces ( erase message: N Addr C -- N Addr ) - 2drop ( N Addr -- ) - + menu_timeout_x @ menu_timeout_y @ at-xy \ position = cursor + type ( c-Addr/u -- ) \ print message + else + menu_timeout_x @ menu_timeout_y @ at-xy \ position = cursor + spaces ( n c-addr/u -- n c-addr ) \ erase message + 2drop ( n c-addr -- ) then =20 0 25 at-xy ( position cursor back at bottom-left ) @@ -682,7 +657,7 @@ create init_text8 255 allot \ (user did not cancel by = pressing ANY \ key) =20 - s" menu_timeout_command" getenv = dup + str_menu_timeout_command getenv = dup -1 =3D if drop \ clean-up else @@ -765,7 +740,7 @@ create init_text8 255 allot 0 menu_timeout_enabled ! \ start with automatic timeout disabled =20 \ check indication that automatic execution after delay is = requested - s" menu_timeout_command" getenv -1 <> if ( Addr C -1 -- | Addr ) + str_menu_timeout_command getenv -1 <> if ( Addr C -1 -- | Addr ) drop ( just testing existence right now: Addr -- ) =20 \ initialize state variables @@ -801,7 +776,7 @@ create init_text8 255 allot =20 menu_timeout_enabled @ 1 =3D if \ read custom column position (if set) - s" loader_menu_timeout_x" getenv dup -1 =3D if + str_loader_menu_timeout_x getenv dup -1 =3D if drop \ no custom column position menu_timeout_default_x \ use default = setting else @@ -813,7 +788,7 @@ create init_text8 255 allot menu_timeout_x ! ( store value on stack from = above ) =20 \ read custom row position (if set) - s" loader_menu_timeout_y" getenv dup -1 =3D if + str_loader_menu_timeout_y getenv dup -1 =3D if drop \ no custom row position menu_timeout_default_y \ use default = setting else @@ -852,13 +827,9 @@ create init_text8 255 allot =20 49 \ Iterator start (loop range 49 to 56; ASCII '1' to = '8') begin - s" menukeyN @" + dup menukeyN @ + rot tuck =3D if =20 - \ replace 'N' with current iteration - -rot 2dup 7 + c! rot - - evaluate rot tuck =3D if - \ Adjust for missing ACPI menuitem on = non-i386 arch-i386? true <> menuacpi @ 0<> and if menuacpi @ over 2dup < -rot =3D = or @@ -868,13 +839,8 @@ create init_text8 255 allot then then =20 - \ base env name for the value (x is a = number) - s" menu_command[x]" - - \ Copy ASCII number to string at offset = 13 - -rot 2dup 13 + c! rot - \ Test for the environment variable + dup menu_command[x] getenv dup -1 <> if \ Execute the stored procedure evaluate @@ -909,16 +875,14 @@ create init_text8 255 allot \=20 \ Check for menu keycode shortcut(s) \=20 - s" menu_keycode[x]" - -rot 2dup 13 + c! rot + dup menu_keycode[x] getenv dup -1 =3D if drop else ?number 0<> if rot tuck =3D if swap - s" menu_command[x]" - -rot 2dup 13 + c! rot + dup menu_command[x] getenv dup -1 <> if evaluate 0=3D if @@ -950,100 +914,43 @@ create init_text8 255 allot =20 49 \ Iterator start (loop range 49 to 56; ASCII '1' to '8') begin - \ Unset variables in-order of appearance in menu.4th(8) + dup menu_init[x] unsetenv \ menu initializer + dup menu_command[x] unsetenv \ menu command + dup menu_caption[x] unsetenv \ menu caption + dup ansi_caption[x] unsetenv \ ANSI caption + dup menu_keycode[x] unsetenv \ menu keycode + dup toggled_text[x] unsetenv \ toggle_menuitem = caption + dup toggled_ansi[x] unsetenv \ toggle_menuitem ANSI = caption =20 - s" menu_caption[x]" \ basename for caption variable - -rot 2dup 13 + c! rot \ replace 'x' with current = iteration - unsetenv \ not erroneous to unset unknown = var - - s" menu_command[x]" \ command basename - -rot 2dup 13 + c! rot \ replace 'x' - unsetenv - - s" menu_init[x]" \ initializer basename - -rot 2dup 10 + c! rot \ replace 'x' - unsetenv - - s" menu_keycode[x]" \ keycode basename - -rot 2dup 13 + c! rot \ replace 'x' - unsetenv - - s" ansi_caption[x]" \ ANSI caption basename - -rot 2dup 13 + c! rot \ replace 'x' - unsetenv - - s" toggled_text[x]" \ toggle_menuitem caption = basename - -rot 2dup 13 + c! rot \ replace 'x' - unsetenv - - s" toggled_ansi[x]" \ toggle_menuitem ANSI caption = basename - -rot 2dup 13 + c! rot \ replace 'x' - unsetenv - - s" menu_caption[x][y]" \ cycle_menuitem caption - -rot 2dup 13 + c! rot \ replace 'x' - 48 -rot + 48 \ Iterator start (inner range 48 to 57; ASCII '0' to = '9') begin - 16 2over rot + c! \ replace 'y' - 2dup unsetenv - - rot 1+ dup 57 > 2swap rot + \ cycle_menuitem caption and ANSI caption + 2dup menu_caption[x][y] unsetenv + 2dup ansi_caption[x][y] unsetenv + 1+ dup 57 > until - 2drop drop + drop \ inner iterator =20 - s" ansi_caption[x][y]" \ cycle_menuitem ANSI caption - -rot 2dup 13 + c! rot \ replace 'x' - 48 -rot - begin - 16 2over rot + c! \ replace 'y' - 2dup unsetenv + 0 over menukeyN ! \ used by menu-create, = menu-display + 0 over init_stateN ! \ used by menu-create + 0 over toggle_stateN ! \ used by toggle_menuitem + 0 over init_textN c! \ used by toggle_menuitem + 0 over cycle_stateN ! \ used by cycle_menuitem =20 - rot 1+ dup 57 > 2swap rot - until - 2drop drop - - s" 0 menukeyN !" \ basename for key association = var - -rot 2dup 9 + c! rot \ replace 'N' with current = iteration - evaluate \ assign zero (0) to key assoc. = var - - s" 0 init_stateN !" \ used by menu-create - -rot 2dup 12 + c! rot \ replace 'N' - evaluate - - s" 0 toggle_stateN !" \ used by toggle_menuitem - -rot 2dup 14 + c! rot \ replace 'N' - evaluate - - s" 0 cycle_stateN !" \ used by cycle_menuitem - -rot 2dup 13 + c! rot \ replace 'N' - evaluate - - s" 0 init_textN c!" \ used by toggle_menuitem - -rot 2dup 11 + c! rot \ replace 'N' - evaluate - 1+ dup 56 > \ increment, continue if less than 57 until drop \ iterator =20 - \ unset the timeout command - s" menu_timeout_command" unsetenv + str_menu_timeout_command unsetenv \ menu timeout command + str_menu_reboot unsetenv \ Reboot menu option = flag + str_menu_acpi unsetenv \ ACPI menu option flag + str_menu_options unsetenv \ Options separator flag + str_menu_optionstext unsetenv \ separator display text + str_menu_init unsetenv \ menu initializer =20 - \ clear the "Reboot" menu option flag - s" menu_reboot" unsetenv 0 menureboot ! - - \ clear the ACPI menu option flag - s" menu_acpi" unsetenv 0 menuacpi ! - - \ clear the "Options" menu separator flag - s" menu_options" unsetenv - s" menu_optionstext" unsetenv 0 menuoptions ! - - \ clear the menu initializer - s" menu_init" unsetenv ; =20 \ This function both unsets menu variables and visually erases the menu = area --Apple-Mail=_A9909A1E-E6A9-43DD-8CBB-D93045B73375-- From owner-freebsd-current@FreeBSD.ORG Sun Nov 11 01:56:56 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C2E8F99B; Sun, 11 Nov 2012 01:56:56 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 7D7A28FC08; Sun, 11 Nov 2012 01:56:56 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id qAB1utmN067332; Sat, 10 Nov 2012 20:56:55 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id qAB1utqi067329; Sun, 11 Nov 2012 01:56:55 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 11 Nov 2012 01:56:55 GMT Message-Id: <201211110156.qAB1utqi067329@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on i386/i386 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Nov 2012 01:56:57 -0000 TB --- 2012-11-10 19:50:00 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-11-10 19:50:00 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-11-10 19:50:00 - starting HEAD tinderbox run for i386/i386 TB --- 2012-11-10 19:50:00 - cleaning the object tree TB --- 2012-11-10 19:56:39 - checking out /src from svn://svn.freebsd.org/base/head TB --- 2012-11-10 19:56:39 - cd /tinderbox/HEAD/i386/i386 TB --- 2012-11-10 19:56:39 - /usr/local/bin/svn cleanup /src TB --- 2012-11-10 19:57:49 - /usr/local/bin/svn update /src TB --- 2012-11-10 19:57:57 - At svn revision 242875 TB --- 2012-11-10 19:57:58 - building world TB --- 2012-11-10 19:57:58 - CROSS_BUILD_TESTING=YES TB --- 2012-11-10 19:57:58 - MAKEOBJDIRPREFIX=/obj TB --- 2012-11-10 19:57:58 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-11-10 19:57:58 - SRCCONF=/dev/null TB --- 2012-11-10 19:57:58 - TARGET=i386 TB --- 2012-11-10 19:57:58 - TARGET_ARCH=i386 TB --- 2012-11-10 19:57:58 - TZ=UTC TB --- 2012-11-10 19:57:58 - __MAKE_CONF=/dev/null TB --- 2012-11-10 19:57:58 - cd /src TB --- 2012-11-10 19:57:58 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sat Nov 10 19:58:04 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sat Nov 10 22:54:10 UTC 2012 TB --- 2012-11-10 22:54:10 - generating LINT kernel config TB --- 2012-11-10 22:54:10 - cd /src/sys/i386/conf TB --- 2012-11-10 22:54:10 - /usr/bin/make -B LINT TB --- 2012-11-10 22:54:10 - cd /src/sys/i386/conf TB --- 2012-11-10 22:54:10 - /usr/sbin/config -m LINT TB --- 2012-11-10 22:54:10 - building LINT kernel TB --- 2012-11-10 22:54:10 - CROSS_BUILD_TESTING=YES TB --- 2012-11-10 22:54:10 - MAKEOBJDIRPREFIX=/obj TB --- 2012-11-10 22:54:10 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-11-10 22:54:10 - SRCCONF=/dev/null TB --- 2012-11-10 22:54:10 - TARGET=i386 TB --- 2012-11-10 22:54:10 - TARGET_ARCH=i386 TB --- 2012-11-10 22:54:10 - TZ=UTC TB --- 2012-11-10 22:54:10 - __MAKE_CONF=/dev/null TB --- 2012-11-10 22:54:10 - cd /src TB --- 2012-11-10 22:54:10 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Nov 10 22:54:11 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT completed on Sat Nov 10 23:25:38 UTC 2012 TB --- 2012-11-10 23:25:38 - cd /src/sys/i386/conf TB --- 2012-11-10 23:25:38 - /usr/sbin/config -m LINT-NOINET TB --- 2012-11-10 23:25:38 - building LINT-NOINET kernel TB --- 2012-11-10 23:25:38 - CROSS_BUILD_TESTING=YES TB --- 2012-11-10 23:25:38 - MAKEOBJDIRPREFIX=/obj TB --- 2012-11-10 23:25:38 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-11-10 23:25:38 - SRCCONF=/dev/null TB --- 2012-11-10 23:25:38 - TARGET=i386 TB --- 2012-11-10 23:25:38 - TARGET_ARCH=i386 TB --- 2012-11-10 23:25:38 - TZ=UTC TB --- 2012-11-10 23:25:38 - __MAKE_CONF=/dev/null TB --- 2012-11-10 23:25:38 - cd /src TB --- 2012-11-10 23:25:38 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET >>> Kernel build for LINT-NOINET started on Sat Nov 10 23:25:38 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT-NOINET completed on Sat Nov 10 23:54:30 UTC 2012 TB --- 2012-11-10 23:54:30 - cd /src/sys/i386/conf TB --- 2012-11-10 23:54:30 - /usr/sbin/config -m LINT-NOINET6 TB --- 2012-11-10 23:54:30 - building LINT-NOINET6 kernel TB --- 2012-11-10 23:54:30 - CROSS_BUILD_TESTING=YES TB --- 2012-11-10 23:54:30 - MAKEOBJDIRPREFIX=/obj TB --- 2012-11-10 23:54:30 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-11-10 23:54:30 - SRCCONF=/dev/null TB --- 2012-11-10 23:54:30 - TARGET=i386 TB --- 2012-11-10 23:54:30 - TARGET_ARCH=i386 TB --- 2012-11-10 23:54:30 - TZ=UTC TB --- 2012-11-10 23:54:30 - __MAKE_CONF=/dev/null TB --- 2012-11-10 23:54:30 - cd /src TB --- 2012-11-10 23:54:30 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET6 >>> Kernel build for LINT-NOINET6 started on Sat Nov 10 23:54:31 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT-NOINET6 completed on Sun Nov 11 00:21:37 UTC 2012 TB --- 2012-11-11 00:21:37 - cd /src/sys/i386/conf TB --- 2012-11-11 00:21:37 - /usr/sbin/config -m LINT-NOIP TB --- 2012-11-11 00:21:37 - building LINT-NOIP kernel TB --- 2012-11-11 00:21:37 - CROSS_BUILD_TESTING=YES TB --- 2012-11-11 00:21:37 - MAKEOBJDIRPREFIX=/obj TB --- 2012-11-11 00:21:37 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-11-11 00:21:37 - SRCCONF=/dev/null TB --- 2012-11-11 00:21:37 - TARGET=i386 TB --- 2012-11-11 00:21:37 - TARGET_ARCH=i386 TB --- 2012-11-11 00:21:37 - TZ=UTC TB --- 2012-11-11 00:21:37 - __MAKE_CONF=/dev/null TB --- 2012-11-11 00:21:37 - cd /src TB --- 2012-11-11 00:21:37 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOIP >>> Kernel build for LINT-NOIP started on Sun Nov 11 00:21:38 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT-NOIP completed on Sun Nov 11 00:46:29 UTC 2012 TB --- 2012-11-11 00:46:29 - cd /src/sys/i386/conf TB --- 2012-11-11 00:46:29 - /usr/sbin/config -m LINT-VIMAGE TB --- 2012-11-11 00:46:29 - building LINT-VIMAGE kernel TB --- 2012-11-11 00:46:29 - CROSS_BUILD_TESTING=YES TB --- 2012-11-11 00:46:29 - MAKEOBJDIRPREFIX=/obj TB --- 2012-11-11 00:46:29 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-11-11 00:46:29 - SRCCONF=/dev/null TB --- 2012-11-11 00:46:29 - TARGET=i386 TB --- 2012-11-11 00:46:29 - TARGET_ARCH=i386 TB --- 2012-11-11 00:46:29 - TZ=UTC TB --- 2012-11-11 00:46:29 - __MAKE_CONF=/dev/null TB --- 2012-11-11 00:46:29 - cd /src TB --- 2012-11-11 00:46:29 - /usr/bin/make -B buildkernel KERNCONF=LINT-VIMAGE >>> Kernel build for LINT-VIMAGE started on Sun Nov 11 00:46:29 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT-VIMAGE completed on Sun Nov 11 01:14:29 UTC 2012 TB --- 2012-11-11 01:14:29 - cd /src/sys/i386/conf TB --- 2012-11-11 01:14:29 - /usr/sbin/config -m GENERIC TB --- 2012-11-11 01:14:29 - building GENERIC kernel TB --- 2012-11-11 01:14:29 - CROSS_BUILD_TESTING=YES TB --- 2012-11-11 01:14:29 - MAKEOBJDIRPREFIX=/obj TB --- 2012-11-11 01:14:29 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-11-11 01:14:29 - SRCCONF=/dev/null TB --- 2012-11-11 01:14:29 - TARGET=i386 TB --- 2012-11-11 01:14:29 - TARGET_ARCH=i386 TB --- 2012-11-11 01:14:29 - TZ=UTC TB --- 2012-11-11 01:14:29 - __MAKE_CONF=/dev/null TB --- 2012-11-11 01:14:29 - cd /src TB --- 2012-11-11 01:14:29 - /usr/bin/make -B buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Sun Nov 11 01:14:29 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for GENERIC completed on Sun Nov 11 01:42:05 UTC 2012 TB --- 2012-11-11 01:42:05 - cd /src/sys/i386/conf TB --- 2012-11-11 01:42:05 - /usr/sbin/config -m PAE TB --- 2012-11-11 01:42:05 - building PAE kernel TB --- 2012-11-11 01:42:05 - CROSS_BUILD_TESTING=YES TB --- 2012-11-11 01:42:05 - MAKEOBJDIRPREFIX=/obj TB --- 2012-11-11 01:42:05 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-11-11 01:42:05 - SRCCONF=/dev/null TB --- 2012-11-11 01:42:05 - TARGET=i386 TB --- 2012-11-11 01:42:05 - TARGET_ARCH=i386 TB --- 2012-11-11 01:42:05 - TZ=UTC TB --- 2012-11-11 01:42:05 - __MAKE_CONF=/dev/null TB --- 2012-11-11 01:42:05 - cd /src TB --- 2012-11-11 01:42:05 - /usr/bin/make -B buildkernel KERNCONF=PAE >>> Kernel build for PAE started on Sun Nov 11 01:42:05 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for PAE completed on Sun Nov 11 01:50:31 UTC 2012 TB --- 2012-11-11 01:50:31 - cd /src/sys/i386/conf TB --- 2012-11-11 01:50:31 - /usr/sbin/config -m XBOX TB --- 2012-11-11 01:50:31 - building XBOX kernel TB --- 2012-11-11 01:50:31 - CROSS_BUILD_TESTING=YES TB --- 2012-11-11 01:50:31 - MAKEOBJDIRPREFIX=/obj TB --- 2012-11-11 01:50:31 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-11-11 01:50:31 - SRCCONF=/dev/null TB --- 2012-11-11 01:50:31 - TARGET=i386 TB --- 2012-11-11 01:50:31 - TARGET_ARCH=i386 TB --- 2012-11-11 01:50:31 - TZ=UTC TB --- 2012-11-11 01:50:31 - __MAKE_CONF=/dev/null TB --- 2012-11-11 01:50:31 - cd /src TB --- 2012-11-11 01:50:31 - /usr/bin/make -B buildkernel KERNCONF=XBOX >>> Kernel build for XBOX started on Sun Nov 11 01:50:31 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for XBOX completed on Sun Nov 11 01:53:24 UTC 2012 TB --- 2012-11-11 01:53:24 - cd /src/sys/i386/conf TB --- 2012-11-11 01:53:24 - /usr/sbin/config -m XEN TB --- 2012-11-11 01:53:24 - building XEN kernel TB --- 2012-11-11 01:53:24 - CROSS_BUILD_TESTING=YES TB --- 2012-11-11 01:53:24 - MAKEOBJDIRPREFIX=/obj TB --- 2012-11-11 01:53:24 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-11-11 01:53:24 - SRCCONF=/dev/null TB --- 2012-11-11 01:53:24 - TARGET=i386 TB --- 2012-11-11 01:53:24 - TARGET_ARCH=i386 TB --- 2012-11-11 01:53:24 - TZ=UTC TB --- 2012-11-11 01:53:24 - __MAKE_CONF=/dev/null TB --- 2012-11-11 01:53:24 - cd /src TB --- 2012-11-11 01:53:24 - /usr/bin/make -B buildkernel KERNCONF=XEN >>> Kernel build for XEN started on Sun Nov 11 01:53:24 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] /src/sys/dev/xen/netback/netback_unit_tests.c:500:2: error: expression result unused [-Werror,-Wunused-value] XNB_ASSERT(pkt.car_size == 110); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /src/sys/dev/xen/netback/netback_unit_tests.c:74:2: note: expanded from macro 'XNB_ASSERT' ! passed; }) ^ ~~~~~~ fatal error: too many errors emitted, stopping now [-ferror-limit=] 20 errors generated. *** [netback.o] Error code 1 Stop in /obj/i386.i386/src/sys/XEN. *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-11-11 01:56:55 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-11-11 01:56:55 - ERROR: failed to build XEN kernel TB --- 2012-11-11 01:56:55 - 15854.70 user 2935.38 system 22014.44 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Sun Nov 11 02:26:23 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8AD95FF2; Sun, 11 Nov 2012 02:26:23 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 406858FC08; Sun, 11 Nov 2012 02:26:23 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id qAB2QMhu022395; Sat, 10 Nov 2012 21:26:22 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id qAB2QMaW022393; Sun, 11 Nov 2012 02:26:22 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 11 Nov 2012 02:26:22 GMT Message-Id: <201211110226.qAB2QMaW022393@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on amd64/amd64 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Nov 2012 02:26:23 -0000 TB --- 2012-11-10 19:50:00 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-11-10 19:50:00 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-11-10 19:50:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2012-11-10 19:50:00 - cleaning the object tree TB --- 2012-11-10 19:59:48 - checking out /src from svn://svn.freebsd.org/base/head TB --- 2012-11-10 19:59:48 - cd /tinderbox/HEAD/amd64/amd64 TB --- 2012-11-10 19:59:48 - /usr/local/bin/svn cleanup /src TB --- 2012-11-10 20:00:29 - /usr/local/bin/svn update /src TB --- 2012-11-10 20:00:36 - At svn revision 242875 TB --- 2012-11-10 20:00:37 - building world TB --- 2012-11-10 20:00:37 - CROSS_BUILD_TESTING=YES TB --- 2012-11-10 20:00:37 - MAKEOBJDIRPREFIX=/obj TB --- 2012-11-10 20:00:37 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-11-10 20:00:37 - SRCCONF=/dev/null TB --- 2012-11-10 20:00:37 - TARGET=amd64 TB --- 2012-11-10 20:00:37 - TARGET_ARCH=amd64 TB --- 2012-11-10 20:00:37 - TZ=UTC TB --- 2012-11-10 20:00:37 - __MAKE_CONF=/dev/null TB --- 2012-11-10 20:00:37 - cd /src TB --- 2012-11-10 20:00:37 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sat Nov 10 20:00:41 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Sat Nov 10 23:35:10 UTC 2012 TB --- 2012-11-10 23:35:10 - generating LINT kernel config TB --- 2012-11-10 23:35:10 - cd /src/sys/amd64/conf TB --- 2012-11-10 23:35:10 - /usr/bin/make -B LINT TB --- 2012-11-10 23:35:10 - cd /src/sys/amd64/conf TB --- 2012-11-10 23:35:10 - /usr/sbin/config -m LINT TB --- 2012-11-10 23:35:10 - building LINT kernel TB --- 2012-11-10 23:35:10 - CROSS_BUILD_TESTING=YES TB --- 2012-11-10 23:35:10 - MAKEOBJDIRPREFIX=/obj TB --- 2012-11-10 23:35:10 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-11-10 23:35:10 - SRCCONF=/dev/null TB --- 2012-11-10 23:35:10 - TARGET=amd64 TB --- 2012-11-10 23:35:10 - TARGET_ARCH=amd64 TB --- 2012-11-10 23:35:10 - TZ=UTC TB --- 2012-11-10 23:35:10 - __MAKE_CONF=/dev/null TB --- 2012-11-10 23:35:10 - cd /src TB --- 2012-11-10 23:35:10 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Nov 10 23:35:10 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT completed on Sun Nov 11 00:04:48 UTC 2012 TB --- 2012-11-11 00:04:48 - cd /src/sys/amd64/conf TB --- 2012-11-11 00:04:48 - /usr/sbin/config -m LINT-NOINET TB --- 2012-11-11 00:04:48 - building LINT-NOINET kernel TB --- 2012-11-11 00:04:48 - CROSS_BUILD_TESTING=YES TB --- 2012-11-11 00:04:48 - MAKEOBJDIRPREFIX=/obj TB --- 2012-11-11 00:04:48 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-11-11 00:04:48 - SRCCONF=/dev/null TB --- 2012-11-11 00:04:48 - TARGET=amd64 TB --- 2012-11-11 00:04:48 - TARGET_ARCH=amd64 TB --- 2012-11-11 00:04:48 - TZ=UTC TB --- 2012-11-11 00:04:48 - __MAKE_CONF=/dev/null TB --- 2012-11-11 00:04:48 - cd /src TB --- 2012-11-11 00:04:48 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET >>> Kernel build for LINT-NOINET started on Sun Nov 11 00:04:49 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT-NOINET completed on Sun Nov 11 00:30:35 UTC 2012 TB --- 2012-11-11 00:30:35 - cd /src/sys/amd64/conf TB --- 2012-11-11 00:30:35 - /usr/sbin/config -m LINT-NOINET6 TB --- 2012-11-11 00:30:36 - building LINT-NOINET6 kernel TB --- 2012-11-11 00:30:36 - CROSS_BUILD_TESTING=YES TB --- 2012-11-11 00:30:36 - MAKEOBJDIRPREFIX=/obj TB --- 2012-11-11 00:30:36 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-11-11 00:30:36 - SRCCONF=/dev/null TB --- 2012-11-11 00:30:36 - TARGET=amd64 TB --- 2012-11-11 00:30:36 - TARGET_ARCH=amd64 TB --- 2012-11-11 00:30:36 - TZ=UTC TB --- 2012-11-11 00:30:36 - __MAKE_CONF=/dev/null TB --- 2012-11-11 00:30:36 - cd /src TB --- 2012-11-11 00:30:36 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET6 >>> Kernel build for LINT-NOINET6 started on Sun Nov 11 00:30:36 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT-NOINET6 completed on Sun Nov 11 00:57:33 UTC 2012 TB --- 2012-11-11 00:57:33 - cd /src/sys/amd64/conf TB --- 2012-11-11 00:57:33 - /usr/sbin/config -m LINT-NOIP TB --- 2012-11-11 00:57:33 - building LINT-NOIP kernel TB --- 2012-11-11 00:57:33 - CROSS_BUILD_TESTING=YES TB --- 2012-11-11 00:57:33 - MAKEOBJDIRPREFIX=/obj TB --- 2012-11-11 00:57:33 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-11-11 00:57:33 - SRCCONF=/dev/null TB --- 2012-11-11 00:57:33 - TARGET=amd64 TB --- 2012-11-11 00:57:33 - TARGET_ARCH=amd64 TB --- 2012-11-11 00:57:33 - TZ=UTC TB --- 2012-11-11 00:57:33 - __MAKE_CONF=/dev/null TB --- 2012-11-11 00:57:33 - cd /src TB --- 2012-11-11 00:57:33 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOIP >>> Kernel build for LINT-NOIP started on Sun Nov 11 00:57:34 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT-NOIP completed on Sun Nov 11 01:21:13 UTC 2012 TB --- 2012-11-11 01:21:13 - cd /src/sys/amd64/conf TB --- 2012-11-11 01:21:13 - /usr/sbin/config -m LINT-VIMAGE TB --- 2012-11-11 01:21:13 - building LINT-VIMAGE kernel TB --- 2012-11-11 01:21:13 - CROSS_BUILD_TESTING=YES TB --- 2012-11-11 01:21:13 - MAKEOBJDIRPREFIX=/obj TB --- 2012-11-11 01:21:13 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-11-11 01:21:13 - SRCCONF=/dev/null TB --- 2012-11-11 01:21:13 - TARGET=amd64 TB --- 2012-11-11 01:21:13 - TARGET_ARCH=amd64 TB --- 2012-11-11 01:21:13 - TZ=UTC TB --- 2012-11-11 01:21:13 - __MAKE_CONF=/dev/null TB --- 2012-11-11 01:21:13 - cd /src TB --- 2012-11-11 01:21:13 - /usr/bin/make -B buildkernel KERNCONF=LINT-VIMAGE >>> Kernel build for LINT-VIMAGE started on Sun Nov 11 01:21:13 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT-VIMAGE completed on Sun Nov 11 01:48:29 UTC 2012 TB --- 2012-11-11 01:48:29 - cd /src/sys/amd64/conf TB --- 2012-11-11 01:48:29 - /usr/sbin/config -m GENERIC TB --- 2012-11-11 01:48:29 - building GENERIC kernel TB --- 2012-11-11 01:48:29 - CROSS_BUILD_TESTING=YES TB --- 2012-11-11 01:48:29 - MAKEOBJDIRPREFIX=/obj TB --- 2012-11-11 01:48:29 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-11-11 01:48:29 - SRCCONF=/dev/null TB --- 2012-11-11 01:48:29 - TARGET=amd64 TB --- 2012-11-11 01:48:29 - TARGET_ARCH=amd64 TB --- 2012-11-11 01:48:29 - TZ=UTC TB --- 2012-11-11 01:48:29 - __MAKE_CONF=/dev/null TB --- 2012-11-11 01:48:29 - cd /src TB --- 2012-11-11 01:48:29 - /usr/bin/make -B buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Sun Nov 11 01:48:29 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for GENERIC completed on Sun Nov 11 02:17:58 UTC 2012 TB --- 2012-11-11 02:17:58 - cd /src/sys/amd64/conf TB --- 2012-11-11 02:17:58 - /usr/sbin/config -m XENHVM TB --- 2012-11-11 02:17:58 - building XENHVM kernel TB --- 2012-11-11 02:17:58 - CROSS_BUILD_TESTING=YES TB --- 2012-11-11 02:17:58 - MAKEOBJDIRPREFIX=/obj TB --- 2012-11-11 02:17:58 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-11-11 02:17:58 - SRCCONF=/dev/null TB --- 2012-11-11 02:17:58 - TARGET=amd64 TB --- 2012-11-11 02:17:58 - TARGET_ARCH=amd64 TB --- 2012-11-11 02:17:58 - TZ=UTC TB --- 2012-11-11 02:17:58 - __MAKE_CONF=/dev/null TB --- 2012-11-11 02:17:58 - cd /src TB --- 2012-11-11 02:17:58 - /usr/bin/make -B buildkernel KERNCONF=XENHVM >>> Kernel build for XENHVM started on Sun Nov 11 02:17:59 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] /src/sys/dev/xen/netback/netback_unit_tests.c:500:2: error: expression result unused [-Werror,-Wunused-value] XNB_ASSERT(pkt.car_size == 110); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /src/sys/dev/xen/netback/netback_unit_tests.c:74:2: note: expanded from macro 'XNB_ASSERT' ! passed; }) ^ ~~~~~~ fatal error: too many errors emitted, stopping now [-ferror-limit=] 20 errors generated. *** [netback.o] Error code 1 Stop in /obj/amd64.amd64/src/sys/XENHVM. *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-11-11 02:26:22 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-11-11 02:26:22 - ERROR: failed to build XENHVM kernel TB --- 2012-11-11 02:26:22 - 16656.43 user 3144.23 system 23781.94 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Sun Nov 11 09:59:10 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 378AAB72 for ; Sun, 11 Nov 2012 09:59:10 +0000 (UTC) (envelope-from alie@affle.com) Received: from mail-vc0-f182.google.com (mail-vc0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id DA7908FC08 for ; Sun, 11 Nov 2012 09:59:09 +0000 (UTC) Received: by mail-vc0-f182.google.com with SMTP id fw7so7008607vcb.13 for ; Sun, 11 Nov 2012 01:59:08 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :x-gm-message-state; bh=2vCfuJp0l96S/4O7eVUiGmD6G1cxVv/Utaq+3UZemaE=; b=OZQe7Zx1MB59HQimYDmnY4Y+BM4qBZM72dLMlK0F7LOOyNAtDoHMQbTaDMAt1ARFvq iZH8Mm3xqSrWB7m0nFJbVbBpA5kG+iyc8ZQB5YVsfVOBbjA4Mot/vvoBe+p7fF32swz/ fOonCvpsygMVRubCM33BG6lzmhFi98nlDzwF3qqDimJcHfyJ0u2u6Rj1Sqdv3OihTUBS azqp1xvS5JfE2SWbn1Wz/BzuzOPaFyqXDd8ldZSh2jktj0jcYbPVtMj00Rj9XSYH4s/w CIF9IRKL4uCy+TBngUnLbj6Jh8uVZoORmT9Oc8Ub2GiUVsvURfQBOAqAVwHEw9fyUPPj mLfw== MIME-Version: 1.0 Received: by 10.52.26.81 with SMTP id j17mr17139538vdg.63.1352627948570; Sun, 11 Nov 2012 01:59:08 -0800 (PST) Received: by 10.58.178.234 with HTTP; Sun, 11 Nov 2012 01:59:08 -0800 (PST) Date: Sun, 11 Nov 2012 17:59:08 +0800 Message-ID: Subject: Compile FreeBSD kernel with gcc48 From: Alie Tan To: freebsd-current@freebsd.org X-Gm-Message-State: ALoCoQkIh8AyOTV4DGterGUNNaWXv7OtpIRF93B28YBhJ6OmmAJtqs4/S728ERDUY/n+yO3uosF+ Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Nov 2012 09:59:10 -0000 Hi, Anyone have experience compiling FreeBSD kernel with gcc48 I have tried it but no success with this in src.conf C= /usr/local/bin/gcc48 CXX= /usr/local/bin/g++48 CWARNFLAGS= -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes \-Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual \-Wno-pointer-sign -D__FreeBSD_cc_version=0 \-Wno-unused-function -Wno-inline -Wno-format \-Wno-uninitialized -Wno-array-bounds -Wno-missing-prototypes NO_WERROR= 1 Another question, is there any benchmark for LLVM/Clang vs gcc45, gcc46, gcc47 or gcc48? Regards, Alie T From owner-freebsd-current@FreeBSD.ORG Sun Nov 11 10:26:06 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 00CBCFAC for ; Sun, 11 Nov 2012 10:26:05 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id B208F8FC0C for ; Sun, 11 Nov 2012 10:26:05 +0000 (UTC) Received: by mail-ob0-f182.google.com with SMTP id wc20so6740122obb.13 for ; Sun, 11 Nov 2012 02:26:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=7C0Z4xAhncFBwp7/ZUTMPIq4vCmLDSOUbeoN46b87E0=; b=fSeZcO3sw8tUy/vL0WNmOZaqzGL2s5pO3G7BBNDZfcBvuUmzTrtuv/CN5b1XXmwsAN jkQ1b5WdHvjB1uhPVAYfhMgG/+8Y03Zn6HU6uHnR79fMQivSrLK3dXcSbXjeDSQ4XZfI 5h8UzZpMA5k8ZpYVMqyHa9CsbnPEwfp4LBkviG3yGNWjrocXmM/O/vLjFm/HchBGGga8 uj+zrLhPiNW6Pu/rxWbZmavZOkkhDhvHkeQVbOR/foT3Ra/rn4m5jWsDGGpk7u3zXAAx 7ROkbW3rGhmUzWmpiLUKEzvieqeABKqkeT7s99Bd82F1hpJIfPRsoLIehLwx/tVMlKAt r8AA== MIME-Version: 1.0 Received: by 10.60.169.170 with SMTP id af10mr12068531oec.17.1352629564665; Sun, 11 Nov 2012 02:26:04 -0800 (PST) Received: by 10.76.143.33 with HTTP; Sun, 11 Nov 2012 02:26:04 -0800 (PST) In-Reply-To: References: Date: Sun, 11 Nov 2012 02:26:04 -0800 Message-ID: Subject: Re: Compile FreeBSD kernel with gcc48 From: Garrett Cooper To: Alie Tan Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Nov 2012 10:26:06 -0000 On Sun, Nov 11, 2012 at 1:59 AM, Alie Tan wrote: > Hi, > > Anyone have experience compiling FreeBSD kernel with gcc48 > > I have tried it but no success with this in src.conf > > C= /usr/local/bin/gcc48 > CXX= /usr/local/bin/g++48 > CWARNFLAGS= -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes > \-Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual > \-Wno-pointer-sign -D__FreeBSD_cc_version=0 \-Wno-unused-function > -Wno-inline -Wno-format \-Wno-uninitialized -Wno-array-bounds > -Wno-missing-prototypes > NO_WERROR= 1 > > Another question, is there any benchmark for LLVM/Clang vs gcc45, gcc46, > gcc47 or gcc48? > Uh, probably won't work because of FreeBSD modifications to gcc not being present in upstream IIRC... -Garrett From owner-freebsd-current@FreeBSD.ORG Sun Nov 11 11:16:25 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2C4FBA5C; Sun, 11 Nov 2012 11:16:25 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) by mx1.freebsd.org (Postfix) with ESMTP id 8092B8FC0A; Sun, 11 Nov 2012 11:16:23 +0000 (UTC) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id qABBGEHw087203 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 11 Nov 2012 12:16:14 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by mail.cicely.de (8.14.5/8.14.4) with ESMTP id qABBGBQZ005210 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 11 Nov 2012 12:16:11 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.14.2/8.14.2) with ESMTP id qABBGB2j007906; Sun, 11 Nov 2012 12:16:11 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id qABBGAOM007905; Sun, 11 Nov 2012 12:16:10 +0100 (CET) (envelope-from ticso) Date: Sun, 11 Nov 2012 12:16:10 +0100 From: Bernd Walter To: Poul-Henning Kamp Subject: Re: polling's future [was: Re: Dynamic Ticks/HZ] Message-ID: <20121111111609.GA7814@cicely7.cicely.de> References: <5097898C.9080109@rewt.org.uk> <20121105163654.GA12870@onelab2.iet.unipi.it> <5097E880.8010001@rewt.org.uk> <20121105165748.GA13098@onelab2.iet.unipi.it> <5098E526.6070101@freebsd.org> <10806.1352197657@critter.freebsd.dk> <5098E8B4.5040309@freebsd.org> <10890.1352198788@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <10890.1352198788@critter.freebsd.dk> X-Operating-System: FreeBSD cicely7.cicely.de 7.0-STABLE i386 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED=-1, BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01 autolearn=ham version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on spamd.cicely.de Cc: Davide Italiano , Joe Holden , Andre Oppermann , FreeBSD Current , Luigi Rizzo , Ryan Stone X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: ticso@cicely.de List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Nov 2012 11:16:25 -0000 On Tue, Nov 06, 2012 at 10:46:28AM +0000, Poul-Henning Kamp wrote: > -------- > In message <5098E8B4.5040309@freebsd.org>, Andre Oppermann writes: > > >> I think it should go away, and if there still is a relevant > >> usage segment, be replaced by _real_ "device-polling" which is > >> not tied to the network stack. > > > >Don't we already have the equivalent with a fast interrupt thread > >that simply acknowledges and disables the interrupt [...] > > The point is that not all hardware have interrupt-pacing, so > being able to poll at a lower rate in software would save overhead. > > I'm not sure if the hardware where this applies is still relevant, > it would probably be mostly in the embedded space. I've used polling on embedded systems to avoid userland starvation and not to gain bandwidth. Interrupts have priority over userland processes and with a CPU not capable to handle say 100MBit/s ethernet interrupt load you can't even login via console console. With polling such a machine is way more responsive and allow people to find out that there is a saturated link before pulling the plug. There are likely other solutions, but it worked well for that puprose. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-current@FreeBSD.ORG Sun Nov 11 12:07:27 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4122B975 for ; Sun, 11 Nov 2012 12:07:27 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 82B1B8FC15 for ; Sun, 11 Nov 2012 12:07:26 +0000 (UTC) Received: from porto.starpoint.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 OAA10365; Sun, 11 Nov 2012 14:07:22 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1TXWJu-0008sz-JI; Sun, 11 Nov 2012 14:07:22 +0200 Message-ID: <509F94F9.7020506@FreeBSD.org> Date: Sun, 11 Nov 2012 14:07:21 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:16.0) Gecko/20121030 Thunderbird/16.0.2 MIME-Version: 1.0 To: Garrett Cooper Subject: Re: Compile FreeBSD kernel with gcc48 References: In-Reply-To: X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org, Alie Tan X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Nov 2012 12:07:27 -0000 on 11/11/2012 12:26 Garrett Cooper said the following: > On Sun, Nov 11, 2012 at 1:59 AM, Alie Tan wrote: > >> Hi, >> >> Anyone have experience compiling FreeBSD kernel with gcc48 >> >> I have tried it but no success with this in src.conf It would be more productive to detail "no success". >> C= /usr/local/bin/gcc48 >> CXX= /usr/local/bin/g++48 >> CWARNFLAGS= -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes >> \-Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual >> \-Wno-pointer-sign -D__FreeBSD_cc_version=0 \-Wno-unused-function >> -Wno-inline -Wno-format \-Wno-uninitialized -Wno-array-bounds >> -Wno-missing-prototypes >> NO_WERROR= 1 >> >> Another question, is there any benchmark for LLVM/Clang vs gcc45, gcc46, >> gcc47 or gcc48? >> > > Uh, probably won't work because of FreeBSD modifications to gcc not being > present in upstream IIRC... Which exact modifications do you have in mind? I was able to compile the kernel with gcc46. I used these settings: CC= /usr/local/bin/gcc46 CXX= /usr/local/bin/g++46 AS= /usr/local/bin/as LD= /usr/local/bin/ld NO_WERROR=yes WERROR= CWARNFLAGS= -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes \ -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual \ -Wno-pointer-sign -D__FreeBSD_cc_version=800001 \ -Wno-unused-function -Wno-inline I guess that perhaps 'WERROR=' made the difference. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Sun Nov 11 12:09:13 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EAD04A9A; Sun, 11 Nov 2012 12:09:13 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id AEC188FC0C; Sun, 11 Nov 2012 12:09:13 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id qABC9C7L069292; Sun, 11 Nov 2012 07:09:12 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id qABC9CwO069291; Sun, 11 Nov 2012 12:09:12 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 11 Nov 2012 12:09:12 GMT Message-Id: <201211111209.qABC9CwO069291@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on i386/i386 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Nov 2012 12:09:14 -0000 TB --- 2012-11-11 05:50:01 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-11-11 05:50:01 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-11-11 05:50:01 - starting HEAD tinderbox run for i386/i386 TB --- 2012-11-11 05:50:01 - cleaning the object tree TB --- 2012-11-11 06:03:51 - checking out /src from svn://svn.freebsd.org/base/head TB --- 2012-11-11 06:03:51 - cd /tinderbox/HEAD/i386/i386 TB --- 2012-11-11 06:03:51 - /usr/local/bin/svn cleanup /src TB --- 2012-11-11 06:05:29 - /usr/local/bin/svn update /src TB --- 2012-11-11 06:05:35 - At svn revision 242885 TB --- 2012-11-11 06:05:36 - building world TB --- 2012-11-11 06:05:36 - CROSS_BUILD_TESTING=YES TB --- 2012-11-11 06:05:36 - MAKEOBJDIRPREFIX=/obj TB --- 2012-11-11 06:05:36 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-11-11 06:05:36 - SRCCONF=/dev/null TB --- 2012-11-11 06:05:36 - TARGET=i386 TB --- 2012-11-11 06:05:36 - TARGET_ARCH=i386 TB --- 2012-11-11 06:05:36 - TZ=UTC TB --- 2012-11-11 06:05:36 - __MAKE_CONF=/dev/null TB --- 2012-11-11 06:05:36 - cd /src TB --- 2012-11-11 06:05:36 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sun Nov 11 06:05:44 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sun Nov 11 09:09:38 UTC 2012 TB --- 2012-11-11 09:09:38 - generating LINT kernel config TB --- 2012-11-11 09:09:38 - cd /src/sys/i386/conf TB --- 2012-11-11 09:09:38 - /usr/bin/make -B LINT TB --- 2012-11-11 09:09:38 - cd /src/sys/i386/conf TB --- 2012-11-11 09:09:38 - /usr/sbin/config -m LINT TB --- 2012-11-11 09:09:38 - building LINT kernel TB --- 2012-11-11 09:09:38 - CROSS_BUILD_TESTING=YES TB --- 2012-11-11 09:09:38 - MAKEOBJDIRPREFIX=/obj TB --- 2012-11-11 09:09:38 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-11-11 09:09:38 - SRCCONF=/dev/null TB --- 2012-11-11 09:09:38 - TARGET=i386 TB --- 2012-11-11 09:09:38 - TARGET_ARCH=i386 TB --- 2012-11-11 09:09:38 - TZ=UTC TB --- 2012-11-11 09:09:38 - __MAKE_CONF=/dev/null TB --- 2012-11-11 09:09:38 - cd /src TB --- 2012-11-11 09:09:38 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Nov 11 09:09:38 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT completed on Sun Nov 11 09:40:00 UTC 2012 TB --- 2012-11-11 09:40:00 - cd /src/sys/i386/conf TB --- 2012-11-11 09:40:00 - /usr/sbin/config -m LINT-NOINET TB --- 2012-11-11 09:40:00 - building LINT-NOINET kernel TB --- 2012-11-11 09:40:00 - CROSS_BUILD_TESTING=YES TB --- 2012-11-11 09:40:00 - MAKEOBJDIRPREFIX=/obj TB --- 2012-11-11 09:40:00 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-11-11 09:40:00 - SRCCONF=/dev/null TB --- 2012-11-11 09:40:00 - TARGET=i386 TB --- 2012-11-11 09:40:00 - TARGET_ARCH=i386 TB --- 2012-11-11 09:40:00 - TZ=UTC TB --- 2012-11-11 09:40:00 - __MAKE_CONF=/dev/null TB --- 2012-11-11 09:40:00 - cd /src TB --- 2012-11-11 09:40:00 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET >>> Kernel build for LINT-NOINET started on Sun Nov 11 09:40:00 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT-NOINET completed on Sun Nov 11 10:07:15 UTC 2012 TB --- 2012-11-11 10:07:15 - cd /src/sys/i386/conf TB --- 2012-11-11 10:07:15 - /usr/sbin/config -m LINT-NOINET6 TB --- 2012-11-11 10:07:15 - building LINT-NOINET6 kernel TB --- 2012-11-11 10:07:15 - CROSS_BUILD_TESTING=YES TB --- 2012-11-11 10:07:15 - MAKEOBJDIRPREFIX=/obj TB --- 2012-11-11 10:07:15 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-11-11 10:07:15 - SRCCONF=/dev/null TB --- 2012-11-11 10:07:15 - TARGET=i386 TB --- 2012-11-11 10:07:15 - TARGET_ARCH=i386 TB --- 2012-11-11 10:07:15 - TZ=UTC TB --- 2012-11-11 10:07:15 - __MAKE_CONF=/dev/null TB --- 2012-11-11 10:07:15 - cd /src TB --- 2012-11-11 10:07:15 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET6 >>> Kernel build for LINT-NOINET6 started on Sun Nov 11 10:07:15 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT-NOINET6 completed on Sun Nov 11 10:33:39 UTC 2012 TB --- 2012-11-11 10:33:39 - cd /src/sys/i386/conf TB --- 2012-11-11 10:33:39 - /usr/sbin/config -m LINT-NOIP TB --- 2012-11-11 10:33:39 - building LINT-NOIP kernel TB --- 2012-11-11 10:33:39 - CROSS_BUILD_TESTING=YES TB --- 2012-11-11 10:33:39 - MAKEOBJDIRPREFIX=/obj TB --- 2012-11-11 10:33:39 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-11-11 10:33:39 - SRCCONF=/dev/null TB --- 2012-11-11 10:33:39 - TARGET=i386 TB --- 2012-11-11 10:33:39 - TARGET_ARCH=i386 TB --- 2012-11-11 10:33:39 - TZ=UTC TB --- 2012-11-11 10:33:39 - __MAKE_CONF=/dev/null TB --- 2012-11-11 10:33:39 - cd /src TB --- 2012-11-11 10:33:39 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOIP >>> Kernel build for LINT-NOIP started on Sun Nov 11 10:33:39 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT-NOIP completed on Sun Nov 11 10:59:32 UTC 2012 TB --- 2012-11-11 10:59:32 - cd /src/sys/i386/conf TB --- 2012-11-11 10:59:32 - /usr/sbin/config -m LINT-VIMAGE TB --- 2012-11-11 10:59:32 - building LINT-VIMAGE kernel TB --- 2012-11-11 10:59:32 - CROSS_BUILD_TESTING=YES TB --- 2012-11-11 10:59:32 - MAKEOBJDIRPREFIX=/obj TB --- 2012-11-11 10:59:32 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-11-11 10:59:32 - SRCCONF=/dev/null TB --- 2012-11-11 10:59:32 - TARGET=i386 TB --- 2012-11-11 10:59:32 - TARGET_ARCH=i386 TB --- 2012-11-11 10:59:32 - TZ=UTC TB --- 2012-11-11 10:59:32 - __MAKE_CONF=/dev/null TB --- 2012-11-11 10:59:32 - cd /src TB --- 2012-11-11 10:59:32 - /usr/bin/make -B buildkernel KERNCONF=LINT-VIMAGE >>> Kernel build for LINT-VIMAGE started on Sun Nov 11 10:59:32 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT-VIMAGE completed on Sun Nov 11 11:26:31 UTC 2012 TB --- 2012-11-11 11:26:31 - cd /src/sys/i386/conf TB --- 2012-11-11 11:26:31 - /usr/sbin/config -m GENERIC TB --- 2012-11-11 11:26:31 - building GENERIC kernel TB --- 2012-11-11 11:26:31 - CROSS_BUILD_TESTING=YES TB --- 2012-11-11 11:26:31 - MAKEOBJDIRPREFIX=/obj TB --- 2012-11-11 11:26:31 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-11-11 11:26:31 - SRCCONF=/dev/null TB --- 2012-11-11 11:26:31 - TARGET=i386 TB --- 2012-11-11 11:26:31 - TARGET_ARCH=i386 TB --- 2012-11-11 11:26:31 - TZ=UTC TB --- 2012-11-11 11:26:31 - __MAKE_CONF=/dev/null TB --- 2012-11-11 11:26:31 - cd /src TB --- 2012-11-11 11:26:31 - /usr/bin/make -B buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Sun Nov 11 11:26:31 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for GENERIC completed on Sun Nov 11 11:54:19 UTC 2012 TB --- 2012-11-11 11:54:19 - cd /src/sys/i386/conf TB --- 2012-11-11 11:54:19 - /usr/sbin/config -m PAE TB --- 2012-11-11 11:54:19 - building PAE kernel TB --- 2012-11-11 11:54:19 - CROSS_BUILD_TESTING=YES TB --- 2012-11-11 11:54:19 - MAKEOBJDIRPREFIX=/obj TB --- 2012-11-11 11:54:19 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-11-11 11:54:19 - SRCCONF=/dev/null TB --- 2012-11-11 11:54:19 - TARGET=i386 TB --- 2012-11-11 11:54:19 - TARGET_ARCH=i386 TB --- 2012-11-11 11:54:19 - TZ=UTC TB --- 2012-11-11 11:54:19 - __MAKE_CONF=/dev/null TB --- 2012-11-11 11:54:19 - cd /src TB --- 2012-11-11 11:54:19 - /usr/bin/make -B buildkernel KERNCONF=PAE >>> Kernel build for PAE started on Sun Nov 11 11:54:19 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for PAE completed on Sun Nov 11 12:03:01 UTC 2012 TB --- 2012-11-11 12:03:01 - cd /src/sys/i386/conf TB --- 2012-11-11 12:03:01 - /usr/sbin/config -m XBOX TB --- 2012-11-11 12:03:02 - building XBOX kernel TB --- 2012-11-11 12:03:02 - CROSS_BUILD_TESTING=YES TB --- 2012-11-11 12:03:02 - MAKEOBJDIRPREFIX=/obj TB --- 2012-11-11 12:03:02 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-11-11 12:03:02 - SRCCONF=/dev/null TB --- 2012-11-11 12:03:02 - TARGET=i386 TB --- 2012-11-11 12:03:02 - TARGET_ARCH=i386 TB --- 2012-11-11 12:03:02 - TZ=UTC TB --- 2012-11-11 12:03:02 - __MAKE_CONF=/dev/null TB --- 2012-11-11 12:03:02 - cd /src TB --- 2012-11-11 12:03:02 - /usr/bin/make -B buildkernel KERNCONF=XBOX >>> Kernel build for XBOX started on Sun Nov 11 12:03:02 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for XBOX completed on Sun Nov 11 12:05:57 UTC 2012 TB --- 2012-11-11 12:05:57 - cd /src/sys/i386/conf TB --- 2012-11-11 12:05:57 - /usr/sbin/config -m XEN TB --- 2012-11-11 12:05:58 - building XEN kernel TB --- 2012-11-11 12:05:58 - CROSS_BUILD_TESTING=YES TB --- 2012-11-11 12:05:58 - MAKEOBJDIRPREFIX=/obj TB --- 2012-11-11 12:05:58 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-11-11 12:05:58 - SRCCONF=/dev/null TB --- 2012-11-11 12:05:58 - TARGET=i386 TB --- 2012-11-11 12:05:58 - TARGET_ARCH=i386 TB --- 2012-11-11 12:05:58 - TZ=UTC TB --- 2012-11-11 12:05:58 - __MAKE_CONF=/dev/null TB --- 2012-11-11 12:05:58 - cd /src TB --- 2012-11-11 12:05:58 - /usr/bin/make -B buildkernel KERNCONF=XEN >>> Kernel build for XEN started on Sun Nov 11 12:05:58 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] /src/sys/dev/xen/netback/netback_unit_tests.c:500:2: error: expression result unused [-Werror,-Wunused-value] XNB_ASSERT(pkt.car_size == 110); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /src/sys/dev/xen/netback/netback_unit_tests.c:74:2: note: expanded from macro 'XNB_ASSERT' ! passed; }) ^ ~~~~~~ fatal error: too many errors emitted, stopping now [-ferror-limit=] 20 errors generated. *** [netback.o] Error code 1 Stop in /obj/i386.i386/src/sys/XEN. *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-11-11 12:09:12 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-11-11 12:09:12 - ERROR: failed to build XEN kernel TB --- 2012-11-11 12:09:12 - 15867.16 user 2817.22 system 22751.16 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Sun Nov 11 12:09:52 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8E9BEBCE; Sun, 11 Nov 2012 12:09:52 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-oa0-f54.google.com (mail-oa0-f54.google.com [209.85.219.54]) by mx1.freebsd.org (Postfix) with ESMTP id 3C59F8FC1C; Sun, 11 Nov 2012 12:09:52 +0000 (UTC) Received: by mail-oa0-f54.google.com with SMTP id n9so6768322oag.13 for ; Sun, 11 Nov 2012 04:09:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=XiaLi8oDnKbr9iSDA1CHZ5p38cYpC3bKbBsc8GAoSuA=; b=vW9ol8cgEsa4R+IbJmsZnD44FnGvKZCdo/g7bW0SCor3Xxvu28YWnPVf34A8CrlE86 c/98EckIVTJ77WDKz8ny7TaVUT88utL3ZOYcPVH5sbCiA3OdIGTnbOGBt6nv4YRnyk2+ 64+SKWkbOvxJf8Y7QT1qK3Jyw6LqNYyBZcnqx0kZYSysnw+nGUWttXm3AdL+rLzU0sAu 4e4fiPprOM40hZbBV5wX97HgeXACOXCLpfDddgQrYQmT4157hkRet7p1px99l831eTvt WqnCSzA6Z5kxLLDgElyvXB65FWC3XithqwMu3nfrJgDxGj/FdyLUv84kr5b1UPhgq5MC UnSw== MIME-Version: 1.0 Received: by 10.60.169.170 with SMTP id af10mr12202556oec.17.1352635791858; Sun, 11 Nov 2012 04:09:51 -0800 (PST) Received: by 10.76.143.33 with HTTP; Sun, 11 Nov 2012 04:09:51 -0800 (PST) In-Reply-To: <509F94F9.7020506@FreeBSD.org> References: <509F94F9.7020506@FreeBSD.org> Date: Sun, 11 Nov 2012 04:09:51 -0800 Message-ID: Subject: Re: Compile FreeBSD kernel with gcc48 From: Garrett Cooper To: Andriy Gapon Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-current@freebsd.org, Alie Tan X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Nov 2012 12:09:52 -0000 On Sun, Nov 11, 2012 at 4:07 AM, Andriy Gapon wrote: > on 11/11/2012 12:26 Garrett Cooper said the following: > > On Sun, Nov 11, 2012 at 1:59 AM, Alie Tan wrote: > > > >> Hi, > >> > >> Anyone have experience compiling FreeBSD kernel with gcc48 > >> > >> I have tried it but no success with this in src.conf > > It would be more productive to detail "no success". > > >> C= /usr/local/bin/gcc48 > >> CXX= /usr/local/bin/g++48 > >> CWARNFLAGS= -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes > >> \-Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual > >> \-Wno-pointer-sign -D__FreeBSD_cc_version=0 \-Wno-unused-function > >> -Wno-inline -Wno-format \-Wno-uninitialized -Wno-array-bounds > >> -Wno-missing-prototypes > >> NO_WERROR= 1 > >> > >> Another question, is there any benchmark for LLVM/Clang vs gcc45, gcc46, > >> gcc47 or gcc48? > >> > > > > Uh, probably won't work because of FreeBSD modifications to gcc not being > > present in upstream IIRC... > > Which exact modifications do you have in mind? > I was able to compile the kernel with gcc46. > > I used these settings: > > CC= /usr/local/bin/gcc46 > CXX= /usr/local/bin/g++46 > AS= /usr/local/bin/as > LD= /usr/local/bin/ld > NO_WERROR=yes > WERROR= > > CWARNFLAGS= -Wall -Wredundant-decls -Wnested-externs > -Wstrict-prototypes \ > -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual \ > -Wno-pointer-sign -D__FreeBSD_cc_version=800001 \ > -Wno-unused-function -Wno-inline > > I guess that perhaps 'WERROR=' made the difference. > -fformat-extensions ? -Garrett From owner-freebsd-current@FreeBSD.ORG Sun Nov 11 12:24:15 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 86EC6159 for ; Sun, 11 Nov 2012 12:24:15 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id C41818FC14 for ; Sun, 11 Nov 2012 12:24:14 +0000 (UTC) Received: from porto.starpoint.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 OAA10454; Sun, 11 Nov 2012 14:24:11 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1TXWaB-0008u4-3I; Sun, 11 Nov 2012 14:24:11 +0200 Message-ID: <509F98EA.5000700@FreeBSD.org> Date: Sun, 11 Nov 2012 14:24:10 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:16.0) Gecko/20121030 Thunderbird/16.0.2 MIME-Version: 1.0 To: Garrett Cooper Subject: Re: Compile FreeBSD kernel with gcc48 References: <509F94F9.7020506@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org, Alie Tan X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Nov 2012 12:24:15 -0000 on 11/11/2012 14:09 Garrett Cooper said the following: > On Sun, Nov 11, 2012 at 4:07 AM, Andriy Gapon > wrote: > > on 11/11/2012 12:26 Garrett Cooper said the following: > > On Sun, Nov 11, 2012 at 1:59 AM, Alie Tan > wrote: [snip] > >> -Wno-format [snip] > >> NO_WERROR= 1 [snip] > WERROR= [snip] > > -fformat-extensions ? The above should take care of it. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Sun Nov 11 12:27:36 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 34D9E324 for ; Sun, 11 Nov 2012 12:27:36 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) by mx1.freebsd.org (Postfix) with ESMTP id DECC58FC08 for ; Sun, 11 Nov 2012 12:27:35 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:9d32:5200:f533:2e10] (unknown [IPv6:2001:7b8:3a7:0:9d32:5200:f533:2e10]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id C22115C59; Sun, 11 Nov 2012 13:27:27 +0100 (CET) Message-ID: <509F99AE.7020706@FreeBSD.org> Date: Sun, 11 Nov 2012 13:27:26 +0100 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Alie Tan Subject: Re: Compile FreeBSD kernel with gcc48 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Nov 2012 12:27:36 -0000 On 2012-11-11 10:59, Alie Tan wrote: > Anyone have experience compiling FreeBSD kernel with gcc48 > > I have tried it but no success with this in src.conf > > C= /usr/local/bin/gcc48 > CXX= /usr/local/bin/g++48 > CWARNFLAGS= -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes > \-Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual > \-Wno-pointer-sign -D__FreeBSD_cc_version=0 \-Wno-unused-function > -Wno-inline -Wno-format \-Wno-uninitialized -Wno-array-bounds > -Wno-missing-prototypes > NO_WERROR= 1 Last time I tried, I could get it to build with a gcc 4.8 snapshot, but it failed to boot. I did not investigate a great deal, but it looked a lot like some sort of optimization bug. Note that gcc 4.8 is still experimental, so problems like this can be expected. However, with gcc 4.7.1, which is a released version, the kernel did build, and even boot. With that kernel booted, I timed how long a "make -j8 buildworld" took, compared to booting with kernels compiled by gcc in base (v4.2.1) and clang in base (v3.2), on different optimization settings. The raw results are here: http://www.andric.com/freebsd/perftest/perftest-kernel-2012-09-25b.txt Summary: - Kernels compiled with clang 3.2 at -O2 are ~8% faster in system time than kernels compiled with gcc 4.2.1 at -O2. - Kernels compiled with clang 3.2 at -O2 perform equally to kernels compiled with gcc 4.7 at -O2, there is no significant difference. - Kernels compiled with gcc 4.7 at -O3 have a slight advantage in system time (~3.6%) against kernels compiled with clang 3.2 at -O2. (I did not test a kernel compiled with clang 3.2 at -O3.) > Another question, is there any benchmark for LLVM/Clang vs gcc45, gcc46, > gcc47 or gcc48? As said, I only tested clang 3.2 against gcc 4.2 from base, and gcc 4.7.1 (hand-built, since the version from ports is inexplicably some random snapshot, not a released version). If anybody is extremely interested in more results, they should sponsor some fast hardware, and donate it to the FreeBSD Project. ;-) From owner-freebsd-current@FreeBSD.ORG Sun Nov 11 12:37:57 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2A9945AB; Sun, 11 Nov 2012 12:37:57 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id D68F88FC08; Sun, 11 Nov 2012 12:37:56 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id qABCbuvu028811; Sun, 11 Nov 2012 07:37:56 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id qABCbuZR028805; Sun, 11 Nov 2012 12:37:56 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 11 Nov 2012 12:37:56 GMT Message-Id: <201211111237.qABCbuZR028805@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on amd64/amd64 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Nov 2012 12:37:57 -0000 TB --- 2012-11-11 05:50:01 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-11-11 05:50:01 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-11-11 05:50:01 - starting HEAD tinderbox run for amd64/amd64 TB --- 2012-11-11 05:50:01 - cleaning the object tree TB --- 2012-11-11 06:05:29 - checking out /src from svn://svn.freebsd.org/base/head TB --- 2012-11-11 06:05:29 - cd /tinderbox/HEAD/amd64/amd64 TB --- 2012-11-11 06:05:29 - /usr/local/bin/svn cleanup /src TB --- 2012-11-11 06:06:55 - /usr/local/bin/svn update /src TB --- 2012-11-11 06:07:01 - At svn revision 242885 TB --- 2012-11-11 06:07:02 - building world TB --- 2012-11-11 06:07:02 - CROSS_BUILD_TESTING=YES TB --- 2012-11-11 06:07:02 - MAKEOBJDIRPREFIX=/obj TB --- 2012-11-11 06:07:02 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-11-11 06:07:02 - SRCCONF=/dev/null TB --- 2012-11-11 06:07:02 - TARGET=amd64 TB --- 2012-11-11 06:07:02 - TARGET_ARCH=amd64 TB --- 2012-11-11 06:07:02 - TZ=UTC TB --- 2012-11-11 06:07:02 - __MAKE_CONF=/dev/null TB --- 2012-11-11 06:07:02 - cd /src TB --- 2012-11-11 06:07:02 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sun Nov 11 06:07:07 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Sun Nov 11 09:46:02 UTC 2012 TB --- 2012-11-11 09:46:02 - generating LINT kernel config TB --- 2012-11-11 09:46:02 - cd /src/sys/amd64/conf TB --- 2012-11-11 09:46:02 - /usr/bin/make -B LINT TB --- 2012-11-11 09:46:02 - cd /src/sys/amd64/conf TB --- 2012-11-11 09:46:02 - /usr/sbin/config -m LINT TB --- 2012-11-11 09:46:02 - building LINT kernel TB --- 2012-11-11 09:46:02 - CROSS_BUILD_TESTING=YES TB --- 2012-11-11 09:46:02 - MAKEOBJDIRPREFIX=/obj TB --- 2012-11-11 09:46:02 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-11-11 09:46:02 - SRCCONF=/dev/null TB --- 2012-11-11 09:46:02 - TARGET=amd64 TB --- 2012-11-11 09:46:02 - TARGET_ARCH=amd64 TB --- 2012-11-11 09:46:02 - TZ=UTC TB --- 2012-11-11 09:46:02 - __MAKE_CONF=/dev/null TB --- 2012-11-11 09:46:02 - cd /src TB --- 2012-11-11 09:46:02 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Nov 11 09:46:02 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT completed on Sun Nov 11 10:14:59 UTC 2012 TB --- 2012-11-11 10:14:59 - cd /src/sys/amd64/conf TB --- 2012-11-11 10:14:59 - /usr/sbin/config -m LINT-NOINET TB --- 2012-11-11 10:14:59 - building LINT-NOINET kernel TB --- 2012-11-11 10:14:59 - CROSS_BUILD_TESTING=YES TB --- 2012-11-11 10:14:59 - MAKEOBJDIRPREFIX=/obj TB --- 2012-11-11 10:14:59 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-11-11 10:14:59 - SRCCONF=/dev/null TB --- 2012-11-11 10:14:59 - TARGET=amd64 TB --- 2012-11-11 10:14:59 - TARGET_ARCH=amd64 TB --- 2012-11-11 10:14:59 - TZ=UTC TB --- 2012-11-11 10:14:59 - __MAKE_CONF=/dev/null TB --- 2012-11-11 10:14:59 - cd /src TB --- 2012-11-11 10:14:59 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET >>> Kernel build for LINT-NOINET started on Sun Nov 11 10:14:59 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT-NOINET completed on Sun Nov 11 10:40:46 UTC 2012 TB --- 2012-11-11 10:40:46 - cd /src/sys/amd64/conf TB --- 2012-11-11 10:40:46 - /usr/sbin/config -m LINT-NOINET6 TB --- 2012-11-11 10:40:46 - building LINT-NOINET6 kernel TB --- 2012-11-11 10:40:46 - CROSS_BUILD_TESTING=YES TB --- 2012-11-11 10:40:46 - MAKEOBJDIRPREFIX=/obj TB --- 2012-11-11 10:40:46 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-11-11 10:40:46 - SRCCONF=/dev/null TB --- 2012-11-11 10:40:46 - TARGET=amd64 TB --- 2012-11-11 10:40:46 - TARGET_ARCH=amd64 TB --- 2012-11-11 10:40:46 - TZ=UTC TB --- 2012-11-11 10:40:46 - __MAKE_CONF=/dev/null TB --- 2012-11-11 10:40:46 - cd /src TB --- 2012-11-11 10:40:46 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET6 >>> Kernel build for LINT-NOINET6 started on Sun Nov 11 10:40:46 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT-NOINET6 completed on Sun Nov 11 11:07:34 UTC 2012 TB --- 2012-11-11 11:07:34 - cd /src/sys/amd64/conf TB --- 2012-11-11 11:07:34 - /usr/sbin/config -m LINT-NOIP TB --- 2012-11-11 11:07:34 - building LINT-NOIP kernel TB --- 2012-11-11 11:07:34 - CROSS_BUILD_TESTING=YES TB --- 2012-11-11 11:07:34 - MAKEOBJDIRPREFIX=/obj TB --- 2012-11-11 11:07:34 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-11-11 11:07:34 - SRCCONF=/dev/null TB --- 2012-11-11 11:07:34 - TARGET=amd64 TB --- 2012-11-11 11:07:34 - TARGET_ARCH=amd64 TB --- 2012-11-11 11:07:34 - TZ=UTC TB --- 2012-11-11 11:07:34 - __MAKE_CONF=/dev/null TB --- 2012-11-11 11:07:34 - cd /src TB --- 2012-11-11 11:07:34 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOIP >>> Kernel build for LINT-NOIP started on Sun Nov 11 11:07:34 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT-NOIP completed on Sun Nov 11 11:31:36 UTC 2012 TB --- 2012-11-11 11:31:36 - cd /src/sys/amd64/conf TB --- 2012-11-11 11:31:36 - /usr/sbin/config -m LINT-VIMAGE TB --- 2012-11-11 11:31:36 - building LINT-VIMAGE kernel TB --- 2012-11-11 11:31:36 - CROSS_BUILD_TESTING=YES TB --- 2012-11-11 11:31:36 - MAKEOBJDIRPREFIX=/obj TB --- 2012-11-11 11:31:36 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-11-11 11:31:36 - SRCCONF=/dev/null TB --- 2012-11-11 11:31:36 - TARGET=amd64 TB --- 2012-11-11 11:31:36 - TARGET_ARCH=amd64 TB --- 2012-11-11 11:31:36 - TZ=UTC TB --- 2012-11-11 11:31:36 - __MAKE_CONF=/dev/null TB --- 2012-11-11 11:31:36 - cd /src TB --- 2012-11-11 11:31:36 - /usr/bin/make -B buildkernel KERNCONF=LINT-VIMAGE >>> Kernel build for LINT-VIMAGE started on Sun Nov 11 11:31:37 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT-VIMAGE completed on Sun Nov 11 11:58:33 UTC 2012 TB --- 2012-11-11 11:58:33 - cd /src/sys/amd64/conf TB --- 2012-11-11 11:58:33 - /usr/sbin/config -m GENERIC TB --- 2012-11-11 11:58:33 - building GENERIC kernel TB --- 2012-11-11 11:58:33 - CROSS_BUILD_TESTING=YES TB --- 2012-11-11 11:58:33 - MAKEOBJDIRPREFIX=/obj TB --- 2012-11-11 11:58:33 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-11-11 11:58:33 - SRCCONF=/dev/null TB --- 2012-11-11 11:58:33 - TARGET=amd64 TB --- 2012-11-11 11:58:33 - TARGET_ARCH=amd64 TB --- 2012-11-11 11:58:33 - TZ=UTC TB --- 2012-11-11 11:58:33 - __MAKE_CONF=/dev/null TB --- 2012-11-11 11:58:33 - cd /src TB --- 2012-11-11 11:58:33 - /usr/bin/make -B buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Sun Nov 11 11:58:33 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for GENERIC completed on Sun Nov 11 12:29:27 UTC 2012 TB --- 2012-11-11 12:29:27 - cd /src/sys/amd64/conf TB --- 2012-11-11 12:29:27 - /usr/sbin/config -m XENHVM TB --- 2012-11-11 12:29:27 - building XENHVM kernel TB --- 2012-11-11 12:29:27 - CROSS_BUILD_TESTING=YES TB --- 2012-11-11 12:29:27 - MAKEOBJDIRPREFIX=/obj TB --- 2012-11-11 12:29:27 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-11-11 12:29:27 - SRCCONF=/dev/null TB --- 2012-11-11 12:29:27 - TARGET=amd64 TB --- 2012-11-11 12:29:27 - TARGET_ARCH=amd64 TB --- 2012-11-11 12:29:27 - TZ=UTC TB --- 2012-11-11 12:29:27 - __MAKE_CONF=/dev/null TB --- 2012-11-11 12:29:27 - cd /src TB --- 2012-11-11 12:29:27 - /usr/bin/make -B buildkernel KERNCONF=XENHVM >>> Kernel build for XENHVM started on Sun Nov 11 12:29:27 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] /src/sys/dev/xen/netback/netback_unit_tests.c:500:2: error: expression result unused [-Werror,-Wunused-value] XNB_ASSERT(pkt.car_size == 110); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /src/sys/dev/xen/netback/netback_unit_tests.c:74:2: note: expanded from macro 'XNB_ASSERT' ! passed; }) ^ ~~~~~~ fatal error: too many errors emitted, stopping now [-ferror-limit=] 20 errors generated. *** [netback.o] Error code 1 Stop in /obj/amd64.amd64/src/sys/XENHVM. *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-11-11 12:37:56 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-11-11 12:37:56 - ERROR: failed to build XENHVM kernel TB --- 2012-11-11 12:37:56 - 16654.77 user 3044.70 system 24475.20 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Sun Nov 11 15:58:51 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E29AB8B1; Sun, 11 Nov 2012 15:58:51 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 9EDE08FC12; Sun, 11 Nov 2012 15:58:48 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id qABFwf71095570; Sun, 11 Nov 2012 10:58:41 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id qABFwfHG095569; Sun, 11 Nov 2012 15:58:41 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 11 Nov 2012 15:58:41 GMT Message-Id: <201211111558.qABFwfHG095569@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on arm/arm Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Nov 2012 15:58:52 -0000 TB --- 2012-11-11 15:50:00 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-11-11 15:50:00 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-11-11 15:50:00 - starting HEAD tinderbox run for arm/arm TB --- 2012-11-11 15:50:00 - cleaning the object tree TB --- 2012-11-11 15:50:00 - checking out /src from svn://svn.freebsd.org/base/head TB --- 2012-11-11 15:50:00 - cd /tinderbox/HEAD/arm/arm TB --- 2012-11-11 15:50:00 - /usr/local/bin/svn cleanup /src TB --- 2012-11-11 15:52:38 - /usr/local/bin/svn update /src TB --- 2012-11-11 15:52:50 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-11 15:52:50 - WARNING: sleeping 30 s and retrying... TB --- 2012-11-11 15:53:20 - /usr/local/bin/svn update /src TB --- 2012-11-11 15:53:33 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-11 15:53:33 - WARNING: sleeping 60 s and retrying... TB --- 2012-11-11 15:54:33 - /usr/local/bin/svn update /src TB --- 2012-11-11 15:54:46 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-11 15:54:46 - WARNING: sleeping 90 s and retrying... TB --- 2012-11-11 15:56:16 - /usr/local/bin/svn update /src TB --- 2012-11-11 15:56:28 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-11 15:56:28 - WARNING: sleeping 120 s and retrying... TB --- 2012-11-11 15:58:28 - /usr/local/bin/svn update /src TB --- 2012-11-11 15:58:41 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-11 15:58:41 - ERROR: unable to check out the source tree TB --- 2012-11-11 15:58:41 - 2.74 user 4.12 system 521.17 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-arm-arm.full From owner-freebsd-current@FreeBSD.ORG Sun Nov 11 15:58:52 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E7FF88B2; Sun, 11 Nov 2012 15:58:51 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 565E68FC13; Sun, 11 Nov 2012 15:58:49 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id qABFwgZ3095579; Sun, 11 Nov 2012 10:58:42 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id qABFwgHf095578; Sun, 11 Nov 2012 15:58:42 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 11 Nov 2012 15:58:42 GMT Message-Id: <201211111558.qABFwgHf095578@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on i386/pc98 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Nov 2012 15:58:52 -0000 TB --- 2012-11-11 15:50:00 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-11-11 15:50:00 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-11-11 15:50:00 - starting HEAD tinderbox run for i386/pc98 TB --- 2012-11-11 15:50:00 - cleaning the object tree TB --- 2012-11-11 15:50:00 - checking out /src from svn://svn.freebsd.org/base/head TB --- 2012-11-11 15:50:00 - cd /tinderbox/HEAD/i386/pc98 TB --- 2012-11-11 15:50:00 - /usr/local/bin/svn cleanup /src TB --- 2012-11-11 15:52:39 - /usr/local/bin/svn update /src TB --- 2012-11-11 15:52:51 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-11 15:52:51 - WARNING: sleeping 30 s and retrying... TB --- 2012-11-11 15:53:21 - /usr/local/bin/svn update /src TB --- 2012-11-11 15:53:34 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-11 15:53:34 - WARNING: sleeping 60 s and retrying... TB --- 2012-11-11 15:54:34 - /usr/local/bin/svn update /src TB --- 2012-11-11 15:54:47 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-11 15:54:47 - WARNING: sleeping 90 s and retrying... TB --- 2012-11-11 15:56:17 - /usr/local/bin/svn update /src TB --- 2012-11-11 15:56:29 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-11 15:56:29 - WARNING: sleeping 120 s and retrying... TB --- 2012-11-11 15:58:29 - /usr/local/bin/svn update /src TB --- 2012-11-11 15:58:42 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-11 15:58:42 - ERROR: unable to check out the source tree TB --- 2012-11-11 15:58:42 - 2.56 user 4.36 system 522.27 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Sun Nov 11 16:04:57 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EE116BF9; Sun, 11 Nov 2012 16:04:56 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 9F6378FC12; Sun, 11 Nov 2012 16:04:53 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id qABG4qIc095627; Sun, 11 Nov 2012 11:04:52 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id qABG4qbJ095626; Sun, 11 Nov 2012 16:04:52 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 11 Nov 2012 16:04:52 GMT Message-Id: <201211111604.qABG4qbJ095626@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on i386/i386 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Nov 2012 16:04:57 -0000 TB --- 2012-11-11 15:50:00 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-11-11 15:50:00 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-11-11 15:50:00 - starting HEAD tinderbox run for i386/i386 TB --- 2012-11-11 15:50:00 - cleaning the object tree TB --- 2012-11-11 15:57:57 - checking out /src from svn://svn.freebsd.org/base/head TB --- 2012-11-11 15:57:57 - cd /tinderbox/HEAD/i386/i386 TB --- 2012-11-11 15:57:57 - /usr/local/bin/svn cleanup /src TB --- 2012-11-11 15:58:49 - /usr/local/bin/svn update /src TB --- 2012-11-11 15:59:01 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-11 15:59:01 - WARNING: sleeping 30 s and retrying... TB --- 2012-11-11 15:59:31 - /usr/local/bin/svn update /src TB --- 2012-11-11 15:59:44 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-11 15:59:44 - WARNING: sleeping 60 s and retrying... TB --- 2012-11-11 16:00:44 - /usr/local/bin/svn update /src TB --- 2012-11-11 16:00:57 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-11 16:00:57 - WARNING: sleeping 90 s and retrying... TB --- 2012-11-11 16:02:27 - /usr/local/bin/svn update /src TB --- 2012-11-11 16:02:40 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-11 16:02:40 - WARNING: sleeping 120 s and retrying... TB --- 2012-11-11 16:04:40 - /usr/local/bin/svn update /src TB --- 2012-11-11 16:04:52 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-11 16:04:52 - ERROR: unable to check out the source tree TB --- 2012-11-11 16:04:52 - 4.20 user 13.51 system 892.21 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Sun Nov 11 16:32:27 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7AE69252; Sun, 11 Nov 2012 16:32:27 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 2DCEE8FC2B; Sun, 11 Nov 2012 16:32:27 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id qABGWQ5K095874; Sun, 11 Nov 2012 11:32:26 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id qABGWQYk095870; Sun, 11 Nov 2012 16:32:26 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 11 Nov 2012 16:32:26 GMT Message-Id: <201211111632.qABGWQYk095870@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on powerpc/powerpc Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Nov 2012 16:32:27 -0000 TB --- 2012-11-11 16:26:13 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-11-11 16:26:13 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-11-11 16:26:13 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2012-11-11 16:26:13 - cleaning the object tree TB --- 2012-11-11 16:26:13 - checking out /src from svn://svn.freebsd.org/base/head TB --- 2012-11-11 16:26:13 - cd /tinderbox/HEAD/powerpc/powerpc TB --- 2012-11-11 16:26:13 - /usr/local/bin/svn cleanup /src TB --- 2012-11-11 16:26:23 - /usr/local/bin/svn update /src TB --- 2012-11-11 16:26:35 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-11 16:26:35 - WARNING: sleeping 30 s and retrying... TB --- 2012-11-11 16:27:05 - /usr/local/bin/svn update /src TB --- 2012-11-11 16:27:18 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-11 16:27:18 - WARNING: sleeping 60 s and retrying... TB --- 2012-11-11 16:28:18 - /usr/local/bin/svn update /src TB --- 2012-11-11 16:28:31 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-11 16:28:31 - WARNING: sleeping 90 s and retrying... TB --- 2012-11-11 16:30:01 - /usr/local/bin/svn update /src TB --- 2012-11-11 16:30:13 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-11 16:30:13 - WARNING: sleeping 120 s and retrying... TB --- 2012-11-11 16:32:13 - /usr/local/bin/svn update /src TB --- 2012-11-11 16:32:26 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-11 16:32:26 - ERROR: unable to check out the source tree TB --- 2012-11-11 16:32:26 - 2.75 user 5.81 system 372.77 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Sun Nov 11 16:32:30 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 840C9254; Sun, 11 Nov 2012 16:32:30 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 3480A8FC57; Sun, 11 Nov 2012 16:32:27 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id qABGWQu4095875; Sun, 11 Nov 2012 11:32:26 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id qABGWQJq095872; Sun, 11 Nov 2012 16:32:26 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 11 Nov 2012 16:32:26 GMT Message-Id: <201211111632.qABGWQJq095872@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on mips/mips Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Nov 2012 16:32:30 -0000 TB --- 2012-11-11 16:26:13 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-11-11 16:26:13 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-11-11 16:26:13 - starting HEAD tinderbox run for mips/mips TB --- 2012-11-11 16:26:13 - cleaning the object tree TB --- 2012-11-11 16:26:13 - checking out /src from svn://svn.freebsd.org/base/head TB --- 2012-11-11 16:26:13 - cd /tinderbox/HEAD/mips/mips TB --- 2012-11-11 16:26:13 - /usr/local/bin/svn cleanup /src TB --- 2012-11-11 16:26:23 - /usr/local/bin/svn update /src TB --- 2012-11-11 16:26:35 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-11 16:26:35 - WARNING: sleeping 30 s and retrying... TB --- 2012-11-11 16:27:05 - /usr/local/bin/svn update /src TB --- 2012-11-11 16:27:18 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-11 16:27:18 - WARNING: sleeping 60 s and retrying... TB --- 2012-11-11 16:28:18 - /usr/local/bin/svn update /src TB --- 2012-11-11 16:28:31 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-11 16:28:31 - WARNING: sleeping 90 s and retrying... TB --- 2012-11-11 16:30:01 - /usr/local/bin/svn update /src TB --- 2012-11-11 16:30:13 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-11 16:30:13 - WARNING: sleeping 120 s and retrying... TB --- 2012-11-11 16:32:13 - /usr/local/bin/svn update /src TB --- 2012-11-11 16:32:26 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-11 16:32:26 - ERROR: unable to check out the source tree TB --- 2012-11-11 16:32:26 - 2.59 user 6.09 system 372.80 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-mips-mips.full From owner-freebsd-current@FreeBSD.ORG Sun Nov 11 16:32:30 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 88DE8255; Sun, 11 Nov 2012 16:32:30 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 350708FC5B; Sun, 11 Nov 2012 16:32:27 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id qABGWQgH095876; Sun, 11 Nov 2012 11:32:26 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id qABGWQIU095871; Sun, 11 Nov 2012 16:32:26 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 11 Nov 2012 16:32:26 GMT Message-Id: <201211111632.qABGWQIU095871@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on mips64/mips Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Nov 2012 16:32:30 -0000 TB --- 2012-11-11 16:26:13 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-11-11 16:26:13 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-11-11 16:26:13 - starting HEAD tinderbox run for mips64/mips TB --- 2012-11-11 16:26:13 - cleaning the object tree TB --- 2012-11-11 16:26:13 - checking out /src from svn://svn.freebsd.org/base/head TB --- 2012-11-11 16:26:13 - cd /tinderbox/HEAD/mips64/mips TB --- 2012-11-11 16:26:13 - /usr/local/bin/svn cleanup /src TB --- 2012-11-11 16:26:23 - /usr/local/bin/svn update /src TB --- 2012-11-11 16:26:35 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-11 16:26:35 - WARNING: sleeping 30 s and retrying... TB --- 2012-11-11 16:27:05 - /usr/local/bin/svn update /src TB --- 2012-11-11 16:27:18 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-11 16:27:18 - WARNING: sleeping 60 s and retrying... TB --- 2012-11-11 16:28:18 - /usr/local/bin/svn update /src TB --- 2012-11-11 16:28:31 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-11 16:28:31 - WARNING: sleeping 90 s and retrying... TB --- 2012-11-11 16:30:01 - /usr/local/bin/svn update /src TB --- 2012-11-11 16:30:13 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-11 16:30:13 - WARNING: sleeping 120 s and retrying... TB --- 2012-11-11 16:32:13 - /usr/local/bin/svn update /src TB --- 2012-11-11 16:32:26 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-11 16:32:26 - ERROR: unable to check out the source tree TB --- 2012-11-11 16:32:26 - 2.57 user 6.12 system 372.77 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-mips64-mips.full From owner-freebsd-current@FreeBSD.ORG Sun Nov 11 16:32:33 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 29F00256; Sun, 11 Nov 2012 16:32:33 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 3489E8FC5A; Sun, 11 Nov 2012 16:32:27 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id qABGWQtg095873; Sun, 11 Nov 2012 11:32:26 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id qABGWQj3095869; Sun, 11 Nov 2012 16:32:26 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 11 Nov 2012 16:32:26 GMT Message-Id: <201211111632.qABGWQj3095869@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on ia64/ia64 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Nov 2012 16:32:33 -0000 TB --- 2012-11-11 16:26:13 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-11-11 16:26:13 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-11-11 16:26:13 - starting HEAD tinderbox run for ia64/ia64 TB --- 2012-11-11 16:26:13 - cleaning the object tree TB --- 2012-11-11 16:26:13 - checking out /src from svn://svn.freebsd.org/base/head TB --- 2012-11-11 16:26:13 - cd /tinderbox/HEAD/ia64/ia64 TB --- 2012-11-11 16:26:13 - /usr/local/bin/svn cleanup /src TB --- 2012-11-11 16:26:23 - /usr/local/bin/svn update /src TB --- 2012-11-11 16:26:35 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-11 16:26:35 - WARNING: sleeping 30 s and retrying... TB --- 2012-11-11 16:27:05 - /usr/local/bin/svn update /src TB --- 2012-11-11 16:27:18 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-11 16:27:18 - WARNING: sleeping 60 s and retrying... TB --- 2012-11-11 16:28:18 - /usr/local/bin/svn update /src TB --- 2012-11-11 16:28:31 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-11 16:28:31 - WARNING: sleeping 90 s and retrying... TB --- 2012-11-11 16:30:01 - /usr/local/bin/svn update /src TB --- 2012-11-11 16:30:13 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-11 16:30:13 - WARNING: sleeping 120 s and retrying... TB --- 2012-11-11 16:32:13 - /usr/local/bin/svn update /src TB --- 2012-11-11 16:32:26 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-11 16:32:26 - ERROR: unable to check out the source tree TB --- 2012-11-11 16:32:26 - 2.66 user 5.98 system 372.81 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Sun Nov 11 16:53:55 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0E0A01894; Sun, 11 Nov 2012 16:53:55 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 555328FC90; Sun, 11 Nov 2012 16:38:38 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id qABGcbFt095924; Sun, 11 Nov 2012 11:38:37 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id qABGcb9E095922; Sun, 11 Nov 2012 16:38:37 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 11 Nov 2012 16:38:37 GMT Message-Id: <201211111638.qABGcb9E095922@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on powerpc64/powerpc Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Nov 2012 16:53:55 -0000 TB --- 2012-11-11 16:32:26 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-11-11 16:32:26 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-11-11 16:32:26 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2012-11-11 16:32:26 - cleaning the object tree TB --- 2012-11-11 16:32:26 - checking out /src from svn://svn.freebsd.org/base/head TB --- 2012-11-11 16:32:26 - cd /tinderbox/HEAD/powerpc64/powerpc TB --- 2012-11-11 16:32:26 - /usr/local/bin/svn cleanup /src TB --- 2012-11-11 16:32:34 - /usr/local/bin/svn update /src TB --- 2012-11-11 16:32:46 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-11 16:32:46 - WARNING: sleeping 30 s and retrying... TB --- 2012-11-11 16:33:16 - /usr/local/bin/svn update /src TB --- 2012-11-11 16:33:29 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-11 16:33:29 - WARNING: sleeping 60 s and retrying... TB --- 2012-11-11 16:34:29 - /usr/local/bin/svn update /src TB --- 2012-11-11 16:34:42 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-11 16:34:42 - WARNING: sleeping 90 s and retrying... TB --- 2012-11-11 16:36:12 - /usr/local/bin/svn update /src TB --- 2012-11-11 16:36:24 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-11 16:36:24 - WARNING: sleeping 120 s and retrying... TB --- 2012-11-11 16:38:24 - /usr/local/bin/svn update /src TB --- 2012-11-11 16:38:37 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-11 16:38:37 - ERROR: unable to check out the source tree TB --- 2012-11-11 16:38:37 - 2.48 user 4.45 system 370.79 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc64-powerpc.full From owner-freebsd-current@FreeBSD.ORG Sun Nov 11 16:53:55 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 12F191896; Sun, 11 Nov 2012 16:53:55 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 555988FC92; Sun, 11 Nov 2012 16:38:38 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id qABGcb0k095925; Sun, 11 Nov 2012 11:38:37 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id qABGcb2J095923; Sun, 11 Nov 2012 16:38:37 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 11 Nov 2012 16:38:37 GMT Message-Id: <201211111638.qABGcb2J095923@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on sparc64/sparc64 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Nov 2012 16:53:55 -0000 TB --- 2012-11-11 16:32:26 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-11-11 16:32:26 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-11-11 16:32:26 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2012-11-11 16:32:26 - cleaning the object tree TB --- 2012-11-11 16:32:26 - checking out /src from svn://svn.freebsd.org/base/head TB --- 2012-11-11 16:32:26 - cd /tinderbox/HEAD/sparc64/sparc64 TB --- 2012-11-11 16:32:26 - /usr/local/bin/svn cleanup /src TB --- 2012-11-11 16:32:34 - /usr/local/bin/svn update /src TB --- 2012-11-11 16:32:46 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-11 16:32:46 - WARNING: sleeping 30 s and retrying... TB --- 2012-11-11 16:33:16 - /usr/local/bin/svn update /src TB --- 2012-11-11 16:33:29 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-11 16:33:29 - WARNING: sleeping 60 s and retrying... TB --- 2012-11-11 16:34:29 - /usr/local/bin/svn update /src TB --- 2012-11-11 16:34:42 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-11 16:34:42 - WARNING: sleeping 90 s and retrying... TB --- 2012-11-11 16:36:12 - /usr/local/bin/svn update /src TB --- 2012-11-11 16:36:24 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-11 16:36:24 - WARNING: sleeping 120 s and retrying... TB --- 2012-11-11 16:38:24 - /usr/local/bin/svn update /src TB --- 2012-11-11 16:38:37 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-11 16:38:37 - ERROR: unable to check out the source tree TB --- 2012-11-11 16:38:37 - 2.73 user 4.28 system 370.79 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Sun Nov 11 17:03:54 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8DCC19E; Sun, 11 Nov 2012 17:03:54 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 840F28FC32; Sun, 11 Nov 2012 16:11:20 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id qABGBJDf095708; Sun, 11 Nov 2012 11:11:19 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id qABGBJPT095707; Sun, 11 Nov 2012 16:11:19 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 11 Nov 2012 16:11:19 GMT Message-Id: <201211111611.qABGBJPT095707@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on mips64/mips Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Nov 2012 17:03:54 -0000 TB --- 2012-11-11 16:04:53 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-11-11 16:04:53 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-11-11 16:04:53 - starting HEAD tinderbox run for mips64/mips TB --- 2012-11-11 16:04:53 - cleaning the object tree TB --- 2012-11-11 16:04:53 - checking out /src from svn://svn.freebsd.org/base/head TB --- 2012-11-11 16:04:53 - cd /tinderbox/HEAD/mips64/mips TB --- 2012-11-11 16:04:53 - /usr/local/bin/svn cleanup /src TB --- 2012-11-11 16:05:16 - /usr/local/bin/svn update /src TB --- 2012-11-11 16:05:28 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-11 16:05:28 - WARNING: sleeping 30 s and retrying... TB --- 2012-11-11 16:05:58 - /usr/local/bin/svn update /src TB --- 2012-11-11 16:06:11 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-11 16:06:11 - WARNING: sleeping 60 s and retrying... TB --- 2012-11-11 16:07:11 - /usr/local/bin/svn update /src TB --- 2012-11-11 16:07:24 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-11 16:07:24 - WARNING: sleeping 90 s and retrying... TB --- 2012-11-11 16:08:54 - /usr/local/bin/svn update /src TB --- 2012-11-11 16:09:06 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-11 16:09:06 - WARNING: sleeping 120 s and retrying... TB --- 2012-11-11 16:11:06 - /usr/local/bin/svn update /src TB --- 2012-11-11 16:11:19 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-11 16:11:19 - ERROR: unable to check out the source tree TB --- 2012-11-11 16:11:19 - 2.66 user 3.90 system 386.53 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-mips64-mips.full From owner-freebsd-current@FreeBSD.ORG Sun Nov 11 17:13:57 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5C2B28B0; Sun, 11 Nov 2012 17:13:57 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 2CE4F8FC19; Sun, 11 Nov 2012 16:07:15 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id qABG7EOP095665; Sun, 11 Nov 2012 11:07:14 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id qABG7Eun095664; Sun, 11 Nov 2012 16:07:14 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 11 Nov 2012 16:07:14 GMT Message-Id: <201211111607.qABG7Eun095664@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on ia64/ia64 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Nov 2012 17:13:57 -0000 TB --- 2012-11-11 15:58:41 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-11-11 15:58:41 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-11-11 15:58:41 - starting HEAD tinderbox run for ia64/ia64 TB --- 2012-11-11 15:58:42 - cleaning the object tree TB --- 2012-11-11 15:58:42 - checking out /src from svn://svn.freebsd.org/base/head TB --- 2012-11-11 15:58:42 - cd /tinderbox/HEAD/ia64/ia64 TB --- 2012-11-11 15:58:42 - /usr/local/bin/svn cleanup /src TB --- 2012-11-11 16:01:11 - /usr/local/bin/svn update /src TB --- 2012-11-11 16:01:23 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-11 16:01:23 - WARNING: sleeping 30 s and retrying... TB --- 2012-11-11 16:01:53 - /usr/local/bin/svn update /src TB --- 2012-11-11 16:02:06 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-11 16:02:06 - WARNING: sleeping 60 s and retrying... TB --- 2012-11-11 16:03:06 - /usr/local/bin/svn update /src TB --- 2012-11-11 16:03:19 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-11 16:03:19 - WARNING: sleeping 90 s and retrying... TB --- 2012-11-11 16:04:49 - /usr/local/bin/svn update /src TB --- 2012-11-11 16:05:01 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-11 16:05:01 - WARNING: sleeping 120 s and retrying... TB --- 2012-11-11 16:07:01 - /usr/local/bin/svn update /src TB --- 2012-11-11 16:07:14 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-11 16:07:14 - ERROR: unable to check out the source tree TB --- 2012-11-11 16:07:14 - 2.86 user 4.20 system 512.56 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Sun Nov 11 17:13:57 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 671A78B5; Sun, 11 Nov 2012 17:13:57 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 56ABC8FC18; Sun, 11 Nov 2012 16:07:14 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id qABG7DUH095648; Sun, 11 Nov 2012 11:07:13 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id qABG7DJc095646; Sun, 11 Nov 2012 16:07:13 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 11 Nov 2012 16:07:13 GMT Message-Id: <201211111607.qABG7DJc095646@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on amd64/amd64 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Nov 2012 17:13:57 -0000 TB --- 2012-11-11 15:50:00 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-11-11 15:50:00 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-11-11 15:50:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2012-11-11 15:50:00 - cleaning the object tree TB --- 2012-11-11 15:58:30 - checking out /src from svn://svn.freebsd.org/base/head TB --- 2012-11-11 15:58:30 - cd /tinderbox/HEAD/amd64/amd64 TB --- 2012-11-11 15:58:30 - /usr/local/bin/svn cleanup /src TB --- 2012-11-11 16:01:10 - /usr/local/bin/svn update /src TB --- 2012-11-11 16:01:22 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-11 16:01:22 - WARNING: sleeping 30 s and retrying... TB --- 2012-11-11 16:01:52 - /usr/local/bin/svn update /src TB --- 2012-11-11 16:02:05 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-11 16:02:05 - WARNING: sleeping 60 s and retrying... TB --- 2012-11-11 16:03:05 - /usr/local/bin/svn update /src TB --- 2012-11-11 16:03:18 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-11 16:03:18 - WARNING: sleeping 90 s and retrying... TB --- 2012-11-11 16:04:48 - /usr/local/bin/svn update /src TB --- 2012-11-11 16:05:00 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-11 16:05:00 - WARNING: sleeping 120 s and retrying... TB --- 2012-11-11 16:07:00 - /usr/local/bin/svn update /src TB --- 2012-11-11 16:07:13 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-11 16:07:13 - ERROR: unable to check out the source tree TB --- 2012-11-11 16:07:13 - 4.22 user 15.15 system 1033.06 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Sun Nov 11 17:13:57 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6D47F8BD; Sun, 11 Nov 2012 17:13:57 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 56A9C8FC15; Sun, 11 Nov 2012 16:07:14 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id qABG7Dd6095649; Sun, 11 Nov 2012 11:07:13 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id qABG7DM8095647; Sun, 11 Nov 2012 16:07:13 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 11 Nov 2012 16:07:13 GMT Message-Id: <201211111607.qABG7DM8095647@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on mips/mips Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Nov 2012 17:13:57 -0000 TB --- 2012-11-11 15:58:43 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-11-11 15:58:43 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-11-11 15:58:43 - starting HEAD tinderbox run for mips/mips TB --- 2012-11-11 15:58:43 - cleaning the object tree TB --- 2012-11-11 15:58:43 - checking out /src from svn://svn.freebsd.org/base/head TB --- 2012-11-11 15:58:43 - cd /tinderbox/HEAD/mips/mips TB --- 2012-11-11 15:58:43 - /usr/local/bin/svn cleanup /src TB --- 2012-11-11 16:01:10 - /usr/local/bin/svn update /src TB --- 2012-11-11 16:01:22 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-11 16:01:22 - WARNING: sleeping 30 s and retrying... TB --- 2012-11-11 16:01:52 - /usr/local/bin/svn update /src TB --- 2012-11-11 16:02:05 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-11 16:02:05 - WARNING: sleeping 60 s and retrying... TB --- 2012-11-11 16:03:05 - /usr/local/bin/svn update /src TB --- 2012-11-11 16:03:18 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-11 16:03:18 - WARNING: sleeping 90 s and retrying... TB --- 2012-11-11 16:04:48 - /usr/local/bin/svn update /src TB --- 2012-11-11 16:05:00 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-11 16:05:00 - WARNING: sleeping 120 s and retrying... TB --- 2012-11-11 16:07:00 - /usr/local/bin/svn update /src TB --- 2012-11-11 16:07:13 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-11 16:07:13 - ERROR: unable to check out the source tree TB --- 2012-11-11 16:07:13 - 2.62 user 4.49 system 510.30 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-mips-mips.full From owner-freebsd-current@FreeBSD.ORG Sun Nov 11 17:13:57 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7340A8C4; Sun, 11 Nov 2012 17:13:57 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 5871D8FC8C; Sun, 11 Nov 2012 16:26:14 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id qABGQDnJ095802; Sun, 11 Nov 2012 11:26:13 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id qABGQDtv095798; Sun, 11 Nov 2012 16:26:13 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 11 Nov 2012 16:26:13 GMT Message-Id: <201211111626.qABGQDtv095798@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on i386/i386 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Nov 2012 17:13:57 -0000 TB --- 2012-11-11 16:20:00 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-11-11 16:20:00 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-11-11 16:20:00 - starting HEAD tinderbox run for i386/i386 TB --- 2012-11-11 16:20:00 - cleaning the object tree TB --- 2012-11-11 16:20:00 - checking out /src from svn://svn.freebsd.org/base/head TB --- 2012-11-11 16:20:00 - cd /tinderbox/HEAD/i386/i386 TB --- 2012-11-11 16:20:00 - /usr/local/bin/svn cleanup /src TB --- 2012-11-11 16:20:10 - /usr/local/bin/svn update /src TB --- 2012-11-11 16:20:22 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-11 16:20:22 - WARNING: sleeping 30 s and retrying... TB --- 2012-11-11 16:20:52 - /usr/local/bin/svn update /src TB --- 2012-11-11 16:21:05 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-11 16:21:05 - WARNING: sleeping 60 s and retrying... TB --- 2012-11-11 16:22:05 - /usr/local/bin/svn update /src TB --- 2012-11-11 16:22:18 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-11 16:22:18 - WARNING: sleeping 90 s and retrying... TB --- 2012-11-11 16:23:48 - /usr/local/bin/svn update /src TB --- 2012-11-11 16:24:00 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-11 16:24:00 - WARNING: sleeping 120 s and retrying... TB --- 2012-11-11 16:26:00 - /usr/local/bin/svn update /src TB --- 2012-11-11 16:26:13 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-11 16:26:13 - ERROR: unable to check out the source tree TB --- 2012-11-11 16:26:13 - 2.55 user 6.23 system 373.03 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Sun Nov 11 17:13:57 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 782AC8C5; Sun, 11 Nov 2012 17:13:57 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 5C0E58FC8D; Sun, 11 Nov 2012 16:26:14 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id qABGQDA0095800; Sun, 11 Nov 2012 11:26:13 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id qABGQDZh095796; Sun, 11 Nov 2012 16:26:13 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 11 Nov 2012 16:26:13 GMT Message-Id: <201211111626.qABGQDZh095796@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on amd64/amd64 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Nov 2012 17:13:57 -0000 TB --- 2012-11-11 16:20:00 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-11-11 16:20:00 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-11-11 16:20:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2012-11-11 16:20:00 - cleaning the object tree TB --- 2012-11-11 16:20:00 - checking out /src from svn://svn.freebsd.org/base/head TB --- 2012-11-11 16:20:00 - cd /tinderbox/HEAD/amd64/amd64 TB --- 2012-11-11 16:20:00 - /usr/local/bin/svn cleanup /src TB --- 2012-11-11 16:20:10 - /usr/local/bin/svn update /src TB --- 2012-11-11 16:20:22 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-11 16:20:22 - WARNING: sleeping 30 s and retrying... TB --- 2012-11-11 16:20:52 - /usr/local/bin/svn update /src TB --- 2012-11-11 16:21:05 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-11 16:21:05 - WARNING: sleeping 60 s and retrying... TB --- 2012-11-11 16:22:05 - /usr/local/bin/svn update /src TB --- 2012-11-11 16:22:18 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-11 16:22:18 - WARNING: sleeping 90 s and retrying... TB --- 2012-11-11 16:23:48 - /usr/local/bin/svn update /src TB --- 2012-11-11 16:24:00 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-11 16:24:00 - WARNING: sleeping 120 s and retrying... TB --- 2012-11-11 16:26:00 - /usr/local/bin/svn update /src TB --- 2012-11-11 16:26:13 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-11 16:26:13 - ERROR: unable to check out the source tree TB --- 2012-11-11 16:26:13 - 2.81 user 5.89 system 373.02 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Sun Nov 11 17:13:57 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7CF7B8C6; Sun, 11 Nov 2012 17:13:57 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 5F9F68FC8E; Sun, 11 Nov 2012 16:26:14 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id qABGQDIY095801; Sun, 11 Nov 2012 11:26:13 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id qABGQD43095797; Sun, 11 Nov 2012 16:26:13 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 11 Nov 2012 16:26:13 GMT Message-Id: <201211111626.qABGQD43095797@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on arm/arm Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Nov 2012 17:13:57 -0000 TB --- 2012-11-11 16:20:00 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-11-11 16:20:00 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-11-11 16:20:00 - starting HEAD tinderbox run for arm/arm TB --- 2012-11-11 16:20:00 - cleaning the object tree TB --- 2012-11-11 16:20:00 - checking out /src from svn://svn.freebsd.org/base/head TB --- 2012-11-11 16:20:00 - cd /tinderbox/HEAD/arm/arm TB --- 2012-11-11 16:20:00 - /usr/local/bin/svn cleanup /src TB --- 2012-11-11 16:20:10 - /usr/local/bin/svn update /src TB --- 2012-11-11 16:20:22 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-11 16:20:22 - WARNING: sleeping 30 s and retrying... TB --- 2012-11-11 16:20:52 - /usr/local/bin/svn update /src TB --- 2012-11-11 16:21:05 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-11 16:21:05 - WARNING: sleeping 60 s and retrying... TB --- 2012-11-11 16:22:05 - /usr/local/bin/svn update /src TB --- 2012-11-11 16:22:18 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-11 16:22:18 - WARNING: sleeping 90 s and retrying... TB --- 2012-11-11 16:23:48 - /usr/local/bin/svn update /src TB --- 2012-11-11 16:24:00 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-11 16:24:00 - WARNING: sleeping 120 s and retrying... TB --- 2012-11-11 16:26:00 - /usr/local/bin/svn update /src TB --- 2012-11-11 16:26:13 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-11 16:26:13 - ERROR: unable to check out the source tree TB --- 2012-11-11 16:26:13 - 2.60 user 6.07 system 373.03 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-arm-arm.full From owner-freebsd-current@FreeBSD.ORG Sun Nov 11 17:13:57 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 81C368C7; Sun, 11 Nov 2012 17:13:57 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 586448FC8B; Sun, 11 Nov 2012 16:26:14 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id qABGQDGL095799; Sun, 11 Nov 2012 11:26:13 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id qABGQDYd095795; Sun, 11 Nov 2012 16:26:13 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 11 Nov 2012 16:26:13 GMT Message-Id: <201211111626.qABGQDYd095795@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on i386/pc98 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Nov 2012 17:13:57 -0000 TB --- 2012-11-11 16:20:00 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-11-11 16:20:00 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-11-11 16:20:00 - starting HEAD tinderbox run for i386/pc98 TB --- 2012-11-11 16:20:00 - cleaning the object tree TB --- 2012-11-11 16:20:00 - checking out /src from svn://svn.freebsd.org/base/head TB --- 2012-11-11 16:20:00 - cd /tinderbox/HEAD/i386/pc98 TB --- 2012-11-11 16:20:00 - /usr/local/bin/svn cleanup /src TB --- 2012-11-11 16:20:10 - /usr/local/bin/svn update /src TB --- 2012-11-11 16:20:22 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-11 16:20:22 - WARNING: sleeping 30 s and retrying... TB --- 2012-11-11 16:20:52 - /usr/local/bin/svn update /src TB --- 2012-11-11 16:21:05 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-11 16:21:05 - WARNING: sleeping 60 s and retrying... TB --- 2012-11-11 16:22:05 - /usr/local/bin/svn update /src TB --- 2012-11-11 16:22:18 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-11 16:22:18 - WARNING: sleeping 90 s and retrying... TB --- 2012-11-11 16:23:48 - /usr/local/bin/svn update /src TB --- 2012-11-11 16:24:00 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-11 16:24:00 - WARNING: sleeping 120 s and retrying... TB --- 2012-11-11 16:26:00 - /usr/local/bin/svn update /src TB --- 2012-11-11 16:26:13 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-11 16:26:13 - ERROR: unable to check out the source tree TB --- 2012-11-11 16:26:13 - 2.79 user 5.98 system 373.01 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Sun Nov 11 17:48:51 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 93CD426F5; Sun, 11 Nov 2012 17:48:51 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 10C188FC54; Sun, 11 Nov 2012 16:13:42 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id qABGDgCc095719; Sun, 11 Nov 2012 11:13:42 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id qABGDgUw095718; Sun, 11 Nov 2012 16:13:42 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 11 Nov 2012 16:13:42 GMT Message-Id: <201211111613.qABGDgUw095718@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on powerpc64/powerpc Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Nov 2012 17:48:51 -0000 TB --- 2012-11-11 16:07:13 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-11-11 16:07:13 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-11-11 16:07:13 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2012-11-11 16:07:13 - cleaning the object tree TB --- 2012-11-11 16:07:13 - checking out /src from svn://svn.freebsd.org/base/head TB --- 2012-11-11 16:07:13 - cd /tinderbox/HEAD/powerpc64/powerpc TB --- 2012-11-11 16:07:13 - /usr/local/bin/svn cleanup /src TB --- 2012-11-11 16:07:39 - /usr/local/bin/svn update /src TB --- 2012-11-11 16:07:51 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-11 16:07:51 - WARNING: sleeping 30 s and retrying... TB --- 2012-11-11 16:08:21 - /usr/local/bin/svn update /src TB --- 2012-11-11 16:08:34 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-11 16:08:34 - WARNING: sleeping 60 s and retrying... TB --- 2012-11-11 16:09:34 - /usr/local/bin/svn update /src TB --- 2012-11-11 16:09:47 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-11 16:09:47 - WARNING: sleeping 90 s and retrying... TB --- 2012-11-11 16:11:17 - /usr/local/bin/svn update /src TB --- 2012-11-11 16:11:29 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-11 16:11:29 - WARNING: sleeping 120 s and retrying... TB --- 2012-11-11 16:13:29 - /usr/local/bin/svn update /src TB --- 2012-11-11 16:13:42 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-11 16:13:42 - ERROR: unable to check out the source tree TB --- 2012-11-11 16:13:42 - 2.72 user 4.22 system 388.73 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc64-powerpc.full From owner-freebsd-current@FreeBSD.ORG Sun Nov 11 17:48:51 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9C14E26FC; Sun, 11 Nov 2012 17:48:51 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 209248FC51; Sun, 11 Nov 2012 16:13:35 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id qABGDZfC095715; Sun, 11 Nov 2012 11:13:35 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id qABGDZ90095714; Sun, 11 Nov 2012 16:13:35 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 11 Nov 2012 16:13:35 GMT Message-Id: <201211111613.qABGDZ90095714@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on sparc64/sparc64 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Nov 2012 17:48:51 -0000 TB --- 2012-11-11 16:07:14 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-11-11 16:07:14 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-11-11 16:07:14 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2012-11-11 16:07:14 - cleaning the object tree TB --- 2012-11-11 16:07:14 - checking out /src from svn://svn.freebsd.org/base/head TB --- 2012-11-11 16:07:14 - cd /tinderbox/HEAD/sparc64/sparc64 TB --- 2012-11-11 16:07:14 - /usr/local/bin/svn cleanup /src TB --- 2012-11-11 16:07:32 - /usr/local/bin/svn update /src TB --- 2012-11-11 16:07:44 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-11 16:07:44 - WARNING: sleeping 30 s and retrying... TB --- 2012-11-11 16:08:14 - /usr/local/bin/svn update /src TB --- 2012-11-11 16:08:27 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-11 16:08:27 - WARNING: sleeping 60 s and retrying... TB --- 2012-11-11 16:09:27 - /usr/local/bin/svn update /src TB --- 2012-11-11 16:09:40 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-11 16:09:40 - WARNING: sleeping 90 s and retrying... TB --- 2012-11-11 16:11:10 - /usr/local/bin/svn update /src TB --- 2012-11-11 16:11:22 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-11 16:11:22 - WARNING: sleeping 120 s and retrying... TB --- 2012-11-11 16:13:22 - /usr/local/bin/svn update /src TB --- 2012-11-11 16:13:35 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-11 16:13:35 - ERROR: unable to check out the source tree TB --- 2012-11-11 16:13:35 - 2.57 user 4.30 system 380.68 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Sun Nov 11 17:48:51 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A106B26FD; Sun, 11 Nov 2012 17:48:51 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 27A268FC50; Sun, 11 Nov 2012 16:13:44 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id qABGDhZZ095723; Sun, 11 Nov 2012 11:13:43 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id qABGDh9a095722; Sun, 11 Nov 2012 16:13:43 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 11 Nov 2012 16:13:43 GMT Message-Id: <201211111613.qABGDh9a095722@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on powerpc/powerpc Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Nov 2012 17:48:51 -0000 TB --- 2012-11-11 16:07:13 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-11-11 16:07:13 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-11-11 16:07:13 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2012-11-11 16:07:13 - cleaning the object tree TB --- 2012-11-11 16:07:13 - checking out /src from svn://svn.freebsd.org/base/head TB --- 2012-11-11 16:07:13 - cd /tinderbox/HEAD/powerpc/powerpc TB --- 2012-11-11 16:07:13 - /usr/local/bin/svn cleanup /src TB --- 2012-11-11 16:07:40 - /usr/local/bin/svn update /src TB --- 2012-11-11 16:07:52 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-11 16:07:52 - WARNING: sleeping 30 s and retrying... TB --- 2012-11-11 16:08:22 - /usr/local/bin/svn update /src TB --- 2012-11-11 16:08:35 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-11 16:08:35 - WARNING: sleeping 60 s and retrying... TB --- 2012-11-11 16:09:35 - /usr/local/bin/svn update /src TB --- 2012-11-11 16:09:48 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-11 16:09:48 - WARNING: sleeping 90 s and retrying... TB --- 2012-11-11 16:11:18 - /usr/local/bin/svn update /src TB --- 2012-11-11 16:11:30 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-11 16:11:30 - WARNING: sleeping 120 s and retrying... TB --- 2012-11-11 16:13:30 - /usr/local/bin/svn update /src TB --- 2012-11-11 16:13:43 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2012-11-11 16:13:43 - ERROR: unable to check out the source tree TB --- 2012-11-11 16:13:43 - 2.80 user 4.12 system 389.76 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Sun Nov 11 21:41:54 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 69EF6E4E for ; Sun, 11 Nov 2012 21:41:54 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id 1C20B8FC12 for ; Sun, 11 Nov 2012 21:41:54 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) for freebsd-current@FreeBSD.org with esmtp (envelope-from ) id <1TXfHn-0047E2-88>; Sun, 11 Nov 2012 22:41:47 +0100 Received: from e178038103.adsl.alicedsl.de ([85.178.38.103] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) for freebsd-current@FreeBSD.org with esmtpsa (envelope-from ) id <1TXfHn-0037dX-4n>; Sun, 11 Nov 2012 22:41:47 +0100 Message-ID: <50A01B95.5070904@zedat.fu-berlin.de> Date: Sun, 11 Nov 2012 22:41:41 +0100 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:16.0) Gecko/20121029 Thunderbird/16.0.2 MIME-Version: 1.0 To: Current FreeBSD Subject: /lib/libgcc_s.so.1: version GCC_4.6.0 required by /usr/local/lib/gcc47/libgfortran.so.3 not found X-Enigmail-Version: 1.4.5 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig864E7D408F2FAF6A05E7773A" X-Originating-IP: 85.178.38.103 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Nov 2012 21:41:54 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig864E7D408F2FAF6A05E7773A Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable I replaced lang/gcc46 by lang/gcc47, since gcc46 doesn't build anymore on the FreeBSD 10.0-CURRENT in question. I have a small f77 program, which built well with the autotools I used and ran for ages now. But I receive this error: /lib/libgcc_s.so.1: version GCC_4.6.0 required by /usr/local/lib/gcc47/libgfortran.so.3 not found when compiled with gfortran47. The autotool environment complains about it can not run Fortran 77 compiled programs, as the error below shows. What happened here? ohartmann@thor: [prog] ./configure checking for gfortran47... gfortran47 checking whether the Fortran 77 compiler works... yes checking for Fortran 77 compiler default output file name... a.out checking for suffix of executables... checking whether we are cross compiling... configure: error: in `/home/ohartmann/Projects/prog': configure: error: cannot run Fortran 77 compiled programs. If you meant to cross compile, use `--host'. See `config.log' for more details --------------enig864E7D408F2FAF6A05E7773A Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBAgAGBQJQoBuaAAoJEOgBcD7A/5N8EhQH/3Ahva7v0Ie2y7r0r1dkhKyR 6SVlf3NGTJRhsKhF/RzNpVC1vVOCMRFLbMVTAm5shHAOtFzxkgTeZ2Q1b/Yd+bIn 6UzUVSwSxL1f6wqXr8WZjU+puHA5K7gYq6fzGEXNbtgR5ts3dSTOTE1mAIlNYy9Q OeRiUzWBlIyXjKGCaNWXgELkE1bT5Z+kE+k+nlgXs4OCfu89bZ1UiRsnwe1IgaNk VwltSU5370Yv00GS/JCVQ5tNORqYKo1Th43ITvzWOTW6E+INgcD53aSBStmAjGyY 9famIjNaxU2i2u0zs8YG/YKsMK0CfRWS83eU6jDRw6RZD9BPz1ilhtBKV4Bladw= =a3k1 -----END PGP SIGNATURE----- --------------enig864E7D408F2FAF6A05E7773A-- From owner-freebsd-current@FreeBSD.ORG Mon Nov 12 01:19:09 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D7FFA668 for ; Mon, 12 Nov 2012 01:19:09 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) by mx1.freebsd.org (Postfix) with ESMTP id 955C58FC0C for ; Mon, 12 Nov 2012 01:19:09 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.5/8.14.5) with ESMTP id qAC1J96m089170; Sun, 11 Nov 2012 17:19:09 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.5/8.14.5/Submit) id qAC1J8Do089169; Sun, 11 Nov 2012 17:19:08 -0800 (PST) (envelope-from sgk) Date: Sun, 11 Nov 2012 17:19:08 -0800 From: Steve Kargl To: "O. Hartmann" Subject: Re: /lib/libgcc_s.so.1: version GCC_4.6.0 required by /usr/local/lib/gcc47/libgfortran.so.3 not found Message-ID: <20121112011908.GB89105@troutmask.apl.washington.edu> References: <50A01B95.5070904@zedat.fu-berlin.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50A01B95.5070904@zedat.fu-berlin.de> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Current FreeBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 01:19:09 -0000 On Sun, Nov 11, 2012 at 10:41:41PM +0100, O. Hartmann wrote: > I replaced lang/gcc46 by lang/gcc47, since gcc46 doesn't build anymore > on the FreeBSD 10.0-CURRENT in question. > > I have a small f77 program, which built well with the autotools I used > and ran for ages now. But I receive this error: > > /lib/libgcc_s.so.1: version GCC_4.6.0 required by > /usr/local/lib/gcc47/libgfortran.so.3 not found > > when compiled with gfortran47. > Add -rpath /usr/local/lib/gcc47 -- Steve From owner-freebsd-current@FreeBSD.ORG Mon Nov 12 01:30:10 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D2A29816; Mon, 12 Nov 2012 01:30:10 +0000 (UTC) (envelope-from peter@rulingia.com) Received: from vps.rulingia.com (host-122-100-2-194.octopus.com.au [122.100.2.194]) by mx1.freebsd.org (Postfix) with ESMTP id 3E1098FC08; Mon, 12 Nov 2012 01:30:09 +0000 (UTC) Received: from server.rulingia.com (c220-239-241-202.belrs5.nsw.optusnet.com.au [220.239.241.202]) by vps.rulingia.com (8.14.5/8.14.5) with ESMTP id qAC1U6Rq064936 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 12 Nov 2012 12:30:07 +1100 (EST) (envelope-from peter@rulingia.com) X-Bogosity: Ham, spamicity=0.000000 Received: from server.rulingia.com (localhost.rulingia.com [127.0.0.1]) by server.rulingia.com (8.14.5/8.14.5) with ESMTP id qAC1U08p066416 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 Nov 2012 12:30:00 +1100 (EST) (envelope-from peter@server.rulingia.com) Received: (from peter@localhost) by server.rulingia.com (8.14.5/8.14.5/Submit) id qAC1U0RR066411; Mon, 12 Nov 2012 12:30:00 +1100 (EST) (envelope-from peter) Date: Mon, 12 Nov 2012 12:30:00 +1100 From: Peter Jeremy To: Devin Teske Subject: Re: HEADS UP: Forth Optimizations Message-ID: <20121112013000.GD5594@server.rulingia.com> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="i0/AhcQY5QxfSsSZ" Content-Disposition: inline In-Reply-To: X-PGP-Key: http://www.rulingia.com/keys/peter.pgp User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Adrian Chadd , freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 01:30:10 -0000 --i0/AhcQY5QxfSsSZ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2012-Nov-10 16:53:10 -0800, Devin Teske wrot= e: >Can someone help review this for the commit log? I've had a look through the proposed patch and my comments follow. Other than that, it looks good to me. >Index: menu-commands.4th >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >--- menu-commands.4th (revision 242835) >+++ menu-commands.4th (working copy) =2E.. >@@ -185,21 +240,21 @@ variable root_state =2E.. > s" set kernel=3D${kernel_prefix}${kernel[N]}${kernel_suffix}" >- \ command to assemble full kernel-path >- -rot tuck 36 + c! swap \ replace 'N' with array index value >- evaluate \ sets $kernel to full kernel-path >+ 36 +c! \ replace 'N' with ASCII numeral >+ evaluate I think the "sets $kernel to full kernel-path" comment is worth keeping. > s" set root=3D${root_prefix}${root[N]}${root_suffix}" >- \ command to assemble root image-path >- -rot tuck 30 + c! swap \ replace 'N' with array index value >- evaluate \ sets $kernel to full kernel-path >+ 30 +c! \ replace 'N' with ASCII numeral >+ evaluate Likewise, this could do with a (corrected) comment that it sets $root to the full path to root. >Index: menu.4th >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >--- menu.4th (revision 242835) >+++ menu.4th (working copy) >@@ -184,18 +223,15 @@ create init_text8 255 allot >=20 > \ base name of environment variable > loader_color? if >- s" ansi_caption[x]" >+ dup ansi_caption[x] > else >- s" menu_caption[x]" >+ dup menu_caption[x] > then=09 Could this be simplified to =3D dup =3D loader_color? if =3D ansi_caption[x] =3D else =3D menu_caption[x] =3D then=09 Or, at a higher level, should this whole block be pulled into a new word (along with similar words for toggled_{ansi,text}[x] and {ansi,menu}_caption[x][y]? >@@ -227,36 +263,26 @@ create init_text8 255 allot =2E.. > getenv dup -1 <> if > \ Assign toggled text to menu caption Some comments on stack contents around here would make it somewhat easier to follow what is going on. >@@ -329,19 +340,18 @@ create init_text8 255 allot =2E.. > \ This is highly unlikely to occur, but to make > \ sure that things move along smoothly, allocate > \ a temporary NULL string >=20 >+ drop ( getenv cruft ) > s" " > then > then Is this the memory leak? If so, can I suggest that this be commited separately since it is a simple change and is distinct from the other changes you are proposing. >@@ -357,14 +367,14 @@ create init_text8 255 allot > \=20 > \ Let's perform what we need to with the above. >=20 >- \ base name of menuitem caption var >+ \ Assign array value text to menu caption >+ 4 pick According to the docementation just above this hunk, there are only 4 items on the stack, so "4 pick" seems wrong, though it is consistent with my understanding of the old code. The "2 pick [char] 0" you added earlier seems to similarly be out-by-one, though consistent. >@@ -521,17 +528,20 @@ create init_text8 255 allot >=20 > \ If this is the ACPI menu option, act accordingly. > dup menuacpi @ =3D if >- acpimenuitem ( -- C-Addr/U | -1 ) >+ dup acpimenuitem ( n -- n n c-addr/u | n n -1 ) >+ dup -1 <> if >+ 13 +c! ( n n c-addr/u -- n ) \ replace 'x' I think the stack here should be ( n n c-addr/u -- n c-addr/u ) >@@ -950,100 +914,43 @@ create init_text8 255 allot >=20 > 49 \ Iterator start (loop range 49 to 56; ASCII '1' to '8') > begin >- \ Unset variables in-order of appearance in menu.4th(8) Does the order matter? I notice you've changed it. --i0/AhcQY5QxfSsSZ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlCgURgACgkQ/opHv/APuIdTRACgiVYnFNPNRSzqfiA5zoXv8/3K 06wAn1/tM3gsHOwCoeRuRKp5SgE8uzsS =hm9F -----END PGP SIGNATURE----- --i0/AhcQY5QxfSsSZ-- From owner-freebsd-current@FreeBSD.ORG Mon Nov 12 11:12:58 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2B82A44E; Mon, 12 Nov 2012 11:12:58 +0000 (UTC) (envelope-from zeising@freebsd.org) Received: from mail.lysator.liu.se (mail.lysator.liu.se [IPv6:2001:6b0:17:f0a0::3]) by mx1.freebsd.org (Postfix) with ESMTP id 7D4688FC0C; Mon, 12 Nov 2012 11:12:57 +0000 (UTC) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id CC6684000F; Mon, 12 Nov 2012 12:12:55 +0100 (CET) Received: by mail.lysator.liu.se (Postfix, from userid 1004) id C1B2740008; Mon, 12 Nov 2012 12:12:55 +0100 (CET) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bernadotte.lysator.liu.se X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=AWL autolearn=disabled version=3.3.1 X-Spam-Score: 0.0 Received: from mx.daemonic.se (h-45-105.a163.priv.bahnhof.se [94.254.45.105]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTPSA id 44AE540003; Mon, 12 Nov 2012 12:12:54 +0100 (CET) Received: from mailscanner.daemonic.se (mailscanner.daemonic.se [IPv6:2001:470:dca9:0:1::6]) by mx.daemonic.se (Postfix) with ESMTPS id 3Y0TpY55SDz8hVn; Mon, 12 Nov 2012 12:12:53 +0100 (CET) X-Virus-Scanned: amavisd-new at daemonic.se Received: from mx.daemonic.se ([10.1.0.3]) (using TLS with cipher CAMELLIA256-SHA) by mailscanner.daemonic.se (mailscanner.daemonic.se [10.1.0.6]) (amavisd-new, port 10025) with ESMTPS id jW9aM9hdvObE; Mon, 12 Nov 2012 12:12:50 +0100 (CET) Received: from mail.daemonic.se (mail.daemonic.se [10.1.0.4]) by mx.daemonic.se (Postfix) with ESMTPS id 3Y0TpV3NPLz8hVm; Mon, 12 Nov 2012 12:12:50 +0100 (CET) Received: from [IPv6:2001:470:dca9:1::3] (celes.daemonic.se [IPv6:2001:470:dca9:1::3]) by mail.daemonic.se (Postfix) with ESMTPSA id 3Y0TpT6BBWz9Ctj; Mon, 12 Nov 2012 12:12:49 +0100 (CET) Message-ID: <50A0D9AC.9010503@freebsd.org> Date: Mon, 12 Nov 2012 12:12:44 +0100 From: Niclas Zeising User-Agent: Mutt/1.5.21 MIME-Version: 1.0 To: Dimitry Andric Subject: Re: Traditional cpp References: <201211090658.qA96whII081757@pozo.com> <20121109072631.GQ77848@eureka.lemis.com> <509CFC88.7050606@FreeBSD.org> <20121110064621.GA10902@eureka.lemis.com> <509E3F53.4060609@FreeBSD.org> In-Reply-To: <509E3F53.4060609@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Cc: Greg 'groggy' Lehey , Koop Mast , freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 11:12:58 -0000 On 2012-11-10 12:49, Dimitry Andric wrote: > On 2012-11-10 07:46, Greg 'groggy' Lehey wrote: >> On Friday, 9 November 2012 at 13:52:24 +0100, Dimitry Andric wrote: > ... >>> Looks like yet another cpp -traditional abuse. >> Use or abuse? > > Abuse, definitely. :-) A "C Preprocessor" is clearly meant to > preprocess C, not arbitrary text files. Hear, hear! :) > > You can see the problem of this approach, when you try to use another > traditional preprocessor, like ports/devel/ucpp, for tools like Imake. > Niclas Zeising can probably tell some interesting stories about this. > > Any subtly different spacing, token parsing behaviour, etc. tend to > break those tools. They are basically relying on the specifics of the > GNU cpp implementation. I have not tried imake, but when using ucpp for other parts of the xorg bundle, most notably libX11, things broke. ucpp passed the configure check, but when used to format text files it does not seem to work the same as gnu cpp (unless you have to add some sort of command line flag that I'm unaware of). This had the unfortunate effect that locales in xorg, amongst other things, stopped working. What I ended up doing to get the xorg ports to build (at least the ports pulled in by the xorg meta port) was to simply remove the configure check for cpp -traditional, and proceed anyway. The only ill effects I've seen so far is that whitespace in cpp generated files get mangled. I have not noticed any functional problems though. For details, see ports r301687: http://svnweb.freebsd.org/ports?view=revision&revision=301687 As a side note, it seems that xorg upstream is moving away from using cpp to generate manuals, at least. For the case of imake the issue might be harder to resolve. I don't know any imake internals, and I have never used it, but it seem to me that imake uses cpp to generate and pre-process makefiles. This might be harder to fix by replacing cpp with sed/awk wizardry. It might be more worthwhile to try to fix the port that use imake to use something else, but I have no clue about how big an undertaking this would be. > > >> In any case, it's not the only one. In the Good Old >> Days people did things like that. So, it seems, does imake, and I'm >> sure others will come out of the woodwork. >> >>> Clang will most likely never support traditional preprocessing. >> >> OK. >> >>> It is probably better to just use sed or awk for this kind of >>> trickery. >> >> I'm not sure that's the way to go. It's more work than it's worth. >> >> What we really need is a traditional cpp. That's not difficult: >> there's one in 4.3BSD (all 32 kB of source). OpenBSD also had one, >> though it's gone now, so presumably that one has a clean license. >> Both appear to be from pcc. Should we import it into the tree as, >> say, tradcpp? > > Please check with Niclas and the other ports guys who have been > wrestling with exactly this issue for some time. They may have lots of > good suggestions. I have not tested anything but gnu cpp, clang cpp and ucpp. I'm not against the import of a traditional cpp, but to me it seems it might be better to just fix the cpp abuse altogether. In any case, the cpp -traditional replacement *must* be bug-for-bug compatible with gcc cpp, which I've been told is quite undocumented. Regards! -- Niclas From owner-freebsd-current@FreeBSD.ORG Mon Nov 12 14:14:59 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A5D2DD82 for ; Mon, 12 Nov 2012 14:14:59 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id 564868FC0C for ; Mon, 12 Nov 2012 14:14:59 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1TXumv-002lc7-Up>; Mon, 12 Nov 2012 15:14:58 +0100 Received: from telesto.geoinf.fu-berlin.de ([130.133.86.198]) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1TXumv-0047He-SU>; Mon, 12 Nov 2012 15:14:57 +0100 Message-ID: <50A10461.8050606@zedat.fu-berlin.de> Date: Mon, 12 Nov 2012 15:14:57 +0100 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:16.0) Gecko/20121030 Thunderbird/16.0.2 MIME-Version: 1.0 To: Steve Kargl Subject: Re: /lib/libgcc_s.so.1: version GCC_4.6.0 required by /usr/local/lib/gcc47/libgfortran.so.3 not found References: <50A01B95.5070904@zedat.fu-berlin.de> <20121112011908.GB89105@troutmask.apl.washington.edu> In-Reply-To: <20121112011908.GB89105@troutmask.apl.washington.edu> X-Enigmail-Version: 1.4.5 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig823A0F2A48391A54A3771CF6" X-Originating-IP: 130.133.86.198 Cc: Current FreeBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 14:14:59 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig823A0F2A48391A54A3771CF6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 11/12/12 02:19, Steve Kargl wrote: > On Sun, Nov 11, 2012 at 10:41:41PM +0100, O. Hartmann wrote: >> I replaced lang/gcc46 by lang/gcc47, since gcc46 doesn't build anymore= >> on the FreeBSD 10.0-CURRENT in question. >> >> I have a small f77 program, which built well with the autotools I used= >> and ran for ages now. But I receive this error: >> >> /lib/libgcc_s.so.1: version GCC_4.6.0 required by >> /usr/local/lib/gcc47/libgfortran.so.3 not found >> >> when compiled with gfortran47. >> >=20 > Add -rpath /usr/local/lib/gcc47=20 >=20 Thanks. I'll give it a try. I'm a bit curious why gcc 4.6 is working, while gcc 4.7 isn't, since I use a autotool environment (configure.ac etc.) to build the tool. Well, I was rude in changing gcc46 to gcc47 and forgot to perform "portupgrade -fo lang/gcc47 gcc-4.6.XXXX". Since "pkgdb -F" still doesn't work, I can not repair the dependencies automatically. I guess, or I suspect (but I do not really know) that a tool/libtool or similar is still assuming gcc 4.6. Thanks anyway, regards, Oliver --------------enig823A0F2A48391A54A3771CF6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBAgAGBQJQoQRhAAoJEOgBcD7A/5N8cWwH/09yn1E9Fp5BYqmlKHVaMW+u h6POkUS52CYyVSqS185ZiVg8VKOn1QcZT8EMv2BdrxBhjpb40vuIzaNMIleDFbB1 gQjQqk8Lm+Bv6cki858sssLd+X8oVVnmJxCBUpZioNbL0Daf/IzsNSC0XI+VjQuB WUeGc1lXgjO6Z3CRBfpKvZfMUJOFcQ7kCjliorkO9ROGerKTdvzF6/qCebL6S4BF gvsLk1CCJr/q1xuG08qb2FtnY+54oMUp8K2Dj3uzSkLnj/9ChiZFhd87vZqq3Ere ztlrJeEyZKPzpPkNozGRs2WUuy+opkt+TtAoHBzBSj3TYbIHmrxl5gntAc3HtqY= =bbpp -----END PGP SIGNATURE----- --------------enig823A0F2A48391A54A3771CF6-- From owner-freebsd-current@FreeBSD.ORG Mon Nov 12 14:57:50 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CCC9DEED; Mon, 12 Nov 2012 14:57:50 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 972738FC15; Mon, 12 Nov 2012 14:57:50 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id qACEvnXn043709; Mon, 12 Nov 2012 09:57:49 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id qACEvnxK043688; Mon, 12 Nov 2012 14:57:49 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 12 Nov 2012 14:57:49 GMT Message-Id: <201211121457.qACEvnxK043688@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on i386/i386 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 14:57:50 -0000 TB --- 2012-11-12 08:50:00 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-11-12 08:50:00 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-11-12 08:50:00 - starting HEAD tinderbox run for i386/i386 TB --- 2012-11-12 08:50:00 - cleaning the object tree TB --- 2012-11-12 08:50:00 - checking out /src from svn://svn.freebsd.org/base/head TB --- 2012-11-12 08:50:00 - cd /tinderbox/HEAD/i386/i386 TB --- 2012-11-12 08:50:00 - /usr/local/bin/svn cleanup /src TB --- 2012-11-12 08:52:23 - /usr/local/bin/svn update /src TB --- 2012-11-12 08:52:36 - At svn revision 242910 TB --- 2012-11-12 08:52:37 - building world TB --- 2012-11-12 08:52:37 - CROSS_BUILD_TESTING=YES TB --- 2012-11-12 08:52:37 - MAKEOBJDIRPREFIX=/obj TB --- 2012-11-12 08:52:37 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-11-12 08:52:37 - SRCCONF=/dev/null TB --- 2012-11-12 08:52:37 - TARGET=i386 TB --- 2012-11-12 08:52:37 - TARGET_ARCH=i386 TB --- 2012-11-12 08:52:37 - TZ=UTC TB --- 2012-11-12 08:52:37 - __MAKE_CONF=/dev/null TB --- 2012-11-12 08:52:37 - cd /src TB --- 2012-11-12 08:52:37 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Mon Nov 12 08:52:44 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Mon Nov 12 11:54:48 UTC 2012 TB --- 2012-11-12 11:54:48 - generating LINT kernel config TB --- 2012-11-12 11:54:48 - cd /src/sys/i386/conf TB --- 2012-11-12 11:54:48 - /usr/bin/make -B LINT TB --- 2012-11-12 11:54:48 - cd /src/sys/i386/conf TB --- 2012-11-12 11:54:48 - /usr/sbin/config -m LINT TB --- 2012-11-12 11:54:48 - building LINT kernel TB --- 2012-11-12 11:54:48 - CROSS_BUILD_TESTING=YES TB --- 2012-11-12 11:54:48 - MAKEOBJDIRPREFIX=/obj TB --- 2012-11-12 11:54:48 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-11-12 11:54:48 - SRCCONF=/dev/null TB --- 2012-11-12 11:54:48 - TARGET=i386 TB --- 2012-11-12 11:54:48 - TARGET_ARCH=i386 TB --- 2012-11-12 11:54:48 - TZ=UTC TB --- 2012-11-12 11:54:48 - __MAKE_CONF=/dev/null TB --- 2012-11-12 11:54:48 - cd /src TB --- 2012-11-12 11:54:48 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Nov 12 11:54:49 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT completed on Mon Nov 12 12:26:43 UTC 2012 TB --- 2012-11-12 12:26:43 - cd /src/sys/i386/conf TB --- 2012-11-12 12:26:43 - /usr/sbin/config -m LINT-NOINET TB --- 2012-11-12 12:26:43 - building LINT-NOINET kernel TB --- 2012-11-12 12:26:43 - CROSS_BUILD_TESTING=YES TB --- 2012-11-12 12:26:43 - MAKEOBJDIRPREFIX=/obj TB --- 2012-11-12 12:26:43 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-11-12 12:26:43 - SRCCONF=/dev/null TB --- 2012-11-12 12:26:43 - TARGET=i386 TB --- 2012-11-12 12:26:43 - TARGET_ARCH=i386 TB --- 2012-11-12 12:26:43 - TZ=UTC TB --- 2012-11-12 12:26:43 - __MAKE_CONF=/dev/null TB --- 2012-11-12 12:26:43 - cd /src TB --- 2012-11-12 12:26:43 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET >>> Kernel build for LINT-NOINET started on Mon Nov 12 12:26:43 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT-NOINET completed on Mon Nov 12 12:54:06 UTC 2012 TB --- 2012-11-12 12:54:06 - cd /src/sys/i386/conf TB --- 2012-11-12 12:54:06 - /usr/sbin/config -m LINT-NOINET6 TB --- 2012-11-12 12:54:06 - building LINT-NOINET6 kernel TB --- 2012-11-12 12:54:06 - CROSS_BUILD_TESTING=YES TB --- 2012-11-12 12:54:06 - MAKEOBJDIRPREFIX=/obj TB --- 2012-11-12 12:54:06 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-11-12 12:54:06 - SRCCONF=/dev/null TB --- 2012-11-12 12:54:06 - TARGET=i386 TB --- 2012-11-12 12:54:06 - TARGET_ARCH=i386 TB --- 2012-11-12 12:54:06 - TZ=UTC TB --- 2012-11-12 12:54:06 - __MAKE_CONF=/dev/null TB --- 2012-11-12 12:54:06 - cd /src TB --- 2012-11-12 12:54:06 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET6 >>> Kernel build for LINT-NOINET6 started on Mon Nov 12 12:54:07 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT-NOINET6 completed on Mon Nov 12 13:20:17 UTC 2012 TB --- 2012-11-12 13:20:17 - cd /src/sys/i386/conf TB --- 2012-11-12 13:20:17 - /usr/sbin/config -m LINT-NOIP TB --- 2012-11-12 13:20:17 - building LINT-NOIP kernel TB --- 2012-11-12 13:20:17 - CROSS_BUILD_TESTING=YES TB --- 2012-11-12 13:20:17 - MAKEOBJDIRPREFIX=/obj TB --- 2012-11-12 13:20:17 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-11-12 13:20:17 - SRCCONF=/dev/null TB --- 2012-11-12 13:20:17 - TARGET=i386 TB --- 2012-11-12 13:20:17 - TARGET_ARCH=i386 TB --- 2012-11-12 13:20:17 - TZ=UTC TB --- 2012-11-12 13:20:17 - __MAKE_CONF=/dev/null TB --- 2012-11-12 13:20:17 - cd /src TB --- 2012-11-12 13:20:17 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOIP >>> Kernel build for LINT-NOIP started on Mon Nov 12 13:20:17 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT-NOIP completed on Mon Nov 12 13:44:09 UTC 2012 TB --- 2012-11-12 13:44:09 - cd /src/sys/i386/conf TB --- 2012-11-12 13:44:09 - /usr/sbin/config -m LINT-VIMAGE TB --- 2012-11-12 13:44:09 - building LINT-VIMAGE kernel TB --- 2012-11-12 13:44:09 - CROSS_BUILD_TESTING=YES TB --- 2012-11-12 13:44:09 - MAKEOBJDIRPREFIX=/obj TB --- 2012-11-12 13:44:09 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-11-12 13:44:09 - SRCCONF=/dev/null TB --- 2012-11-12 13:44:09 - TARGET=i386 TB --- 2012-11-12 13:44:09 - TARGET_ARCH=i386 TB --- 2012-11-12 13:44:09 - TZ=UTC TB --- 2012-11-12 13:44:09 - __MAKE_CONF=/dev/null TB --- 2012-11-12 13:44:09 - cd /src TB --- 2012-11-12 13:44:09 - /usr/bin/make -B buildkernel KERNCONF=LINT-VIMAGE >>> Kernel build for LINT-VIMAGE started on Mon Nov 12 13:44:09 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT-VIMAGE completed on Mon Nov 12 14:12:37 UTC 2012 TB --- 2012-11-12 14:12:37 - cd /src/sys/i386/conf TB --- 2012-11-12 14:12:37 - /usr/sbin/config -m GENERIC TB --- 2012-11-12 14:12:37 - building GENERIC kernel TB --- 2012-11-12 14:12:37 - CROSS_BUILD_TESTING=YES TB --- 2012-11-12 14:12:37 - MAKEOBJDIRPREFIX=/obj TB --- 2012-11-12 14:12:37 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-11-12 14:12:37 - SRCCONF=/dev/null TB --- 2012-11-12 14:12:37 - TARGET=i386 TB --- 2012-11-12 14:12:37 - TARGET_ARCH=i386 TB --- 2012-11-12 14:12:37 - TZ=UTC TB --- 2012-11-12 14:12:37 - __MAKE_CONF=/dev/null TB --- 2012-11-12 14:12:37 - cd /src TB --- 2012-11-12 14:12:37 - /usr/bin/make -B buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Mon Nov 12 14:12:38 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for GENERIC completed on Mon Nov 12 14:39:58 UTC 2012 TB --- 2012-11-12 14:39:58 - cd /src/sys/i386/conf TB --- 2012-11-12 14:39:58 - /usr/sbin/config -m PAE TB --- 2012-11-12 14:39:58 - building PAE kernel TB --- 2012-11-12 14:39:58 - CROSS_BUILD_TESTING=YES TB --- 2012-11-12 14:39:58 - MAKEOBJDIRPREFIX=/obj TB --- 2012-11-12 14:39:58 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-11-12 14:39:58 - SRCCONF=/dev/null TB --- 2012-11-12 14:39:58 - TARGET=i386 TB --- 2012-11-12 14:39:58 - TARGET_ARCH=i386 TB --- 2012-11-12 14:39:58 - TZ=UTC TB --- 2012-11-12 14:39:58 - __MAKE_CONF=/dev/null TB --- 2012-11-12 14:39:58 - cd /src TB --- 2012-11-12 14:39:58 - /usr/bin/make -B buildkernel KERNCONF=PAE >>> Kernel build for PAE started on Mon Nov 12 14:39:58 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for PAE completed on Mon Nov 12 14:48:26 UTC 2012 TB --- 2012-11-12 14:48:26 - cd /src/sys/i386/conf TB --- 2012-11-12 14:48:26 - /usr/sbin/config -m XBOX TB --- 2012-11-12 14:48:26 - building XBOX kernel TB --- 2012-11-12 14:48:26 - CROSS_BUILD_TESTING=YES TB --- 2012-11-12 14:48:26 - MAKEOBJDIRPREFIX=/obj TB --- 2012-11-12 14:48:26 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-11-12 14:48:26 - SRCCONF=/dev/null TB --- 2012-11-12 14:48:26 - TARGET=i386 TB --- 2012-11-12 14:48:26 - TARGET_ARCH=i386 TB --- 2012-11-12 14:48:26 - TZ=UTC TB --- 2012-11-12 14:48:26 - __MAKE_CONF=/dev/null TB --- 2012-11-12 14:48:26 - cd /src TB --- 2012-11-12 14:48:26 - /usr/bin/make -B buildkernel KERNCONF=XBOX >>> Kernel build for XBOX started on Mon Nov 12 14:48:26 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for XBOX completed on Mon Nov 12 14:51:27 UTC 2012 TB --- 2012-11-12 14:51:27 - cd /src/sys/i386/conf TB --- 2012-11-12 14:51:27 - /usr/sbin/config -m XEN TB --- 2012-11-12 14:51:27 - building XEN kernel TB --- 2012-11-12 14:51:27 - CROSS_BUILD_TESTING=YES TB --- 2012-11-12 14:51:27 - MAKEOBJDIRPREFIX=/obj TB --- 2012-11-12 14:51:27 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-11-12 14:51:27 - SRCCONF=/dev/null TB --- 2012-11-12 14:51:27 - TARGET=i386 TB --- 2012-11-12 14:51:27 - TARGET_ARCH=i386 TB --- 2012-11-12 14:51:27 - TZ=UTC TB --- 2012-11-12 14:51:27 - __MAKE_CONF=/dev/null TB --- 2012-11-12 14:51:27 - cd /src TB --- 2012-11-12 14:51:27 - /usr/bin/make -B buildkernel KERNCONF=XEN >>> Kernel build for XEN started on Mon Nov 12 14:51:28 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mno-aes -mno-avx -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/i386/xen/clock.c /src/sys/i386/xen/clock.c:519:2: error: expression result unused [-Werror,-Wunused-value] do_div(__cpu_khz, info->tsc_to_system_mul); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /src/sys/i386/xen/clock.c:153:9: note: expanded from macro 'do_div' __mod; \ ^~~~~ 1 error generated. *** [clock.o] Error code 1 Stop in /obj/i386.i386/src/sys/XEN. *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-11-12 14:57:48 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-11-12 14:57:48 - ERROR: failed to build XEN kernel TB --- 2012-11-12 14:57:48 - 15981.87 user 2822.27 system 22068.81 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Mon Nov 12 18:47:44 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C6B83460; Mon, 12 Nov 2012 18:47:44 +0000 (UTC) (envelope-from Devin.Teske@fisglobal.com) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) by mx1.freebsd.org (Postfix) with ESMTP id 677788FC14; Mon, 12 Nov 2012 18:47:43 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.31]) by ltcfislmsgpa03.fnfis.com (8.14.5/8.14.5) with ESMTP id qACIlgbE025264 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 12 Nov 2012 12:47:42 -0600 Received: from [10.0.0.103] (10.14.152.61) by smtp.fisglobal.com (10.132.206.31) with Microsoft SMTP Server (TLS) id 14.2.309.2; Mon, 12 Nov 2012 12:47:41 -0600 Subject: Re: HEADS UP: Forth Optimizations MIME-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/mixed; boundary="Apple-Mail=_769728F7-62D7-41E2-9431-E82F021FEFE6" From: Devin Teske In-Reply-To: <20121112013000.GD5594@server.rulingia.com> Date: Mon, 12 Nov 2012 10:47:39 -0800 Message-ID: References: <20121112013000.GD5594@server.rulingia.com> To: Peter Jeremy X-Mailer: Apple Mail (2.1283) X-Originating-IP: [10.14.152.61] X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.9.8185, 1.0.431, 0.0.0000 definitions=2012-11-12_03:2012-11-12,2012-11-11,1970-01-01 signatures=0 Cc: Adrian Chadd , Devin Teske , freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Devin Teske List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 18:47:44 -0000 --Apple-Mail=_769728F7-62D7-41E2-9431-E82F021FEFE6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" On Nov 11, 2012, at 5:30 PM, Peter Jeremy wrote: > On 2012-Nov-10 16:53:10 -0800, Devin Teske wr= ote: >> Can someone help review this for the commit log? >=20 > I've had a look through the proposed patch and my comments follow. > Other than that, it looks good to me. >=20 Thanks Peter! Replies inline below. >> Index: menu-commands.4th >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> --- menu-commands.4th (revision 242835) >> +++ menu-commands.4th (working copy) > ... >> @@ -185,21 +240,21 @@ variable root_state > ... >> s" set kernel=3D${kernel_prefix}${kernel[N]}${kernel_suffix}" >> - \ command to assemble full kernel-path >> - -rot tuck 36 + c! swap \ replace 'N' with array index value >> - evaluate \ sets $kernel to full kernel-path >> + 36 +c! \ replace 'N' with ASCII numeral >> + evaluate >=20 > I think the "sets $kernel to full kernel-path" comment is worth keeping. >=20 Updated, thx. >> s" set root=3D${root_prefix}${root[N]}${root_suffix}" >> - \ command to assemble root image-path >> - -rot tuck 30 + c! swap \ replace 'N' with array index value >> - evaluate \ sets $kernel to full kernel-path >> + 30 +c! \ replace 'N' with ASCII numeral >> + evaluate >=20 > Likewise, this could do with a (corrected) comment that it sets $root > to the full path to root. >=20 Likewise, updated. >> Index: menu.4th >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> --- menu.4th (revision 242835) >> +++ menu.4th (working copy) >> @@ -184,18 +223,15 @@ create init_text8 255 allot >>=20 >> \ base name of environment variable >> loader_color? if >> - s" ansi_caption[x]" >> + dup ansi_caption[x] >> else >> - s" menu_caption[x]" >> + dup menu_caption[x] >> then=09 >=20 > Could this be simplified to >=20 > =3D dup > =3D loader_color? if > =3D ansi_caption[x] > =3D else > =3D menu_caption[x] > =3D then=09 >=20 Sure, done. Actually, found two occurrences of this that I corrected. > Or, at a higher level, should this whole block be pulled into a new > word (along with similar words for toggled_{ansi,text}[x] and > {ansi,menu}_caption[x][y]? >=20 I looked at the uses where ansi* is used in place of non-ansi* and it's not= just within loader_color? blocks (that was in-fact the minority of cases).= Cooking it down further would make things more complicated I fear. If I come up with a cute way to simplify this, I'll try it out in another c= ommit. >> @@ -227,36 +263,26 @@ create init_text8 255 allot > ... >> getenv dup -1 <> if >> \ Assign toggled text to menu caption >=20 > Some comments on stack contents around here would make it somewhat > easier to follow what is going on. >=20 Done. I also made updates to cycle_menuitem for similarly-dense code. >> @@ -329,19 +340,18 @@ create init_text8 255 allot > ... >> \ This is highly unlikely to occur, but to make >> \ sure that things move along smoothly, allocate >> \ a temporary NULL string >>=20 >> + drop ( getenv cruft ) >> s" " >> then >> then >=20 > Is this the memory leak? If so, can I suggest that this be commited > separately since it is a simple change and is distinct from the other > changes you are proposing. You got it. Committed as r242923 >=20 >> @@ -357,14 +367,14 @@ create init_text8 255 allot >> \=20 >> \ Let's perform what we need to with the above. >>=20 >> - \ base name of menuitem caption var >> + \ Assign array value text to menu caption >> + 4 pick >=20 > According to the docementation just above this hunk, there are only 4 > items on the stack, so "4 pick" seems wrong, though it is consistent > with my understanding of the old code. The "2 pick [char] 0" you > added earlier seems to similarly be out-by-one, though consistent. >=20 My mistake was that the comments need to be updated to say C-Addr/U not C-A= ddr (the C-Addr/U counts to make 5 items on the stack, satisfying the "4 pi= ck"). I've updated the comment to reflect the stack contents more accuratel= y. >> @@ -521,17 +528,20 @@ create init_text8 255 allot >>=20 >> \ If this is the ACPI menu option, act accordingly. >> dup menuacpi @ =3D if >> - acpimenuitem ( -- C-Addr/U | -1 ) >> + dup acpimenuitem ( n -- n n c-addr/u | n n -1 ) >> + dup -1 <> if >> + 13 +c! ( n n c-addr/u -- n ) \ replace 'x' >=20 > I think the stack here should be ( n n c-addr/u -- n c-addr/u ) >=20 Good catch! Updated. >> @@ -950,100 +914,43 @@ create init_text8 255 allot >>=20 >> 49 \ Iterator start (loop range 49 to 56; ASCII '1' to '8') >> begin >> - \ Unset variables in-order of appearance in menu.4th(8) >=20 > Does the order matter? I notice you've changed it. No, order doesn't matter. It was just a comment to myself. Since I've re-ordered things, the axiom is no longer true. Please find an updated patch attached (as patch.txt) with the aforementione= d changes. --=20 Devin _____________ The information contained in this message is proprietary and/or confidentia= l. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any ma= nner; and (iii) notify the sender immediately. In addition, please be aware= that any message addressed to our domain is subject to archiving and revie= w by persons other than the intended recipient. Thank you. --Apple-Mail=_769728F7-62D7-41E2-9431-E82F021FEFE6 Content-Disposition: attachment; filename="patch.txt" Content-Type: text/plain; name="patch.txt" Content-Transfer-Encoding: quoted-printable Index: menu-commands.4th =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- menu-commands.4th (revision 242835) +++ menu-commands.4th (working copy) @@ -31,6 +31,10 @@ include /boot/menusets.4th variable kernel_state variable root_state =20 +\=20 +\ ACPI +\=20 + : acpi_enable ( -- ) s" set acpi_load=3DYES" evaluate \ XXX deprecated but harmless s" set hint.acpi.0.disabled=3D0" evaluate @@ -58,9 +62,38 @@ variable root_state TRUE \ loop menu again ; =20 +\=20 +\ Safe Mode +\=20 + +: safemode_enabled? ( -- flag ) + s" kern.smp.disabled" getenv -1 <> dup if + swap drop ( c-addr flag -- flag ) + then +; + +: safemode_enable ( -- ) + s" set kern.smp.disabled=3D1" evaluate + s" set hw.ata.ata_dma=3D0" evaluate + s" set hw.ata.atapi_dma=3D0" evaluate + s" set hw.ata.wc=3D0" evaluate + s" set hw.eisa_slots=3D0" evaluate + s" set kern.eventtimer.periodic=3D1" evaluate + s" set kern.geom.part.check_integrity=3D0" evaluate +; + +: safemode_disable ( -- ) + s" kern.smp.disabled" unsetenv + s" hw.ata.ata_dma" unsetenv + s" hw.ata.atapi_dma" unsetenv + s" hw.ata.wc" unsetenv + s" hw.eisa_slots" unsetenv + s" kern.eventtimer.periodic" unsetenv + s" kern.geom.part.check_integrity" unsetenv +; + : init_safemode ( N -- N ) - s" kern.smp.disabled" getenv -1 <> if - drop ( n c-addr -- n ) \ unused + safemode_enabled? if toggle_menuitem ( n -- n ) then ; @@ -70,25 +103,10 @@ variable root_state =20 \ Now we're going to make the change effective =20 - s" toggle_stateN @" \ base name of toggle state var - -rot 2dup 12 + c! rot \ replace 'N' with ASCII numeral - - evaluate 0=3D if - s" kern.smp.disabled" unsetenv - s" hw.ata.ata_dma" unsetenv - s" hw.ata.atapi_dma" unsetenv - s" hw.ata.wc" unsetenv - s" hw.eisa_slots" unsetenv - s" kern.eventtimer.periodic" unsetenv - s" kern.geom.part.check_integrity" unsetenv + dup toggle_stateN @ 0=3D if + safemode_disable else - s" set kern.smp.disabled=3D1" evaluate - s" set hw.ata.ata_dma=3D0" evaluate - s" set hw.ata.atapi_dma=3D0" evaluate - s" set hw.ata.wc=3D0" evaluate - s" set hw.eisa_slots=3D0" evaluate - s" set kern.eventtimer.periodic=3D1" evaluate - s" set kern.geom.part.check_integrity=3D0" evaluate + safemode_enable then =20 menu-redraw @@ -96,9 +114,26 @@ variable root_state TRUE \ loop menu again ; =20 +\=20 +\ Single User Mode +\=20 + +: singleuser_enabled? ( -- flag ) + s" boot_single" getenv -1 <> dup if + swap drop ( c-addr flag -- flag ) + then +; + +: singleuser_enable ( -- ) + s" set boot_single=3DYES" evaluate +; + +: singleuser_disable ( -- ) + s" boot_single" unsetenv +; + : init_singleuser ( N -- N ) - s" boot_single" getenv -1 <> if - drop ( n c-addr -- n ) \ unused + singleuser_enabled? if toggle_menuitem ( n -- n ) then ; @@ -109,21 +144,35 @@ variable root_state =20 \ Now we're going to make the change effective =20 - s" toggle_stateN @" \ base name of toggle state var - -rot 2dup 12 + c! rot \ replace 'N' with ASCII numeral - - evaluate 0=3D if - s" boot_single" unsetenv + dup toggle_stateN @ 0=3D if + singleuser_disable else - s" set boot_single=3DYES" evaluate + singleuser_enable then =20 TRUE \ loop menu again ; =20 +\=20 +\ Verbose Boot +\=20 + +: verbose_enabled? ( -- flag ) + s" boot_verbose" getenv -1 <> dup if + swap drop ( c-addr flag -- flag ) + then +; + +: verbose_enable ( -- ) + s" set boot_verbose=3DYES" evaluate +; + +: verbose_disable ( -- ) + s" boot_verbose" unsetenv +; + : init_verbose ( N -- N ) - s" boot_verbose" getenv -1 <> if - drop ( n c-addr -- n ) \ unused + verbose_enabled? if toggle_menuitem ( n -- n ) then ; @@ -134,18 +183,19 @@ variable root_state =20 \ Now we're going to make the change effective =20 - s" toggle_stateN @" \ base name of toggle state var - -rot 2dup 12 + c! rot \ replace 'N' with ASCII numeral - - evaluate 0=3D if - s" boot_verbose" unsetenv + dup toggle_stateN @ 0=3D if + verbose_disable else - s" set boot_verbose=3DYES" evaluate + verbose_enable then =20 TRUE \ loop menu again ; =20 +\=20 +\ Escape to Prompt +\=20 + : goto_prompt ( N -- N FALSE ) =20 s" set autoboot_delay=3DNO" evaluate @@ -158,11 +208,12 @@ variable root_state FALSE \ exit the menu ; =20 +\=20 +\ Cyclestate (used by kernel/root below) +\=20 + : init_cyclestate ( N K -- N ) - over ( n k -- n k n ) - s" cycle_stateN" ( n k n -- n k n c-addr u ) - -rot tuck 11 + c! swap ( n k n c-addr u -- n k c-addr u ) - evaluate ( n k c-addr u -- n k addr ) + over cycle_stateN ( n k -- n k addr ) begin tuck @ ( n k addr -- n addr k c ) over <> ( n addr k c -- n addr k 0|-1 ) @@ -174,6 +225,10 @@ variable root_state 2drop ( n k addr -- n ) ; =20 +\ +\ Kernel +\=20 + : init_kernel ( N -- N ) kernel_state @ ( n -- n k ) init_cyclestate ( n k -- n ) @@ -185,21 +240,21 @@ variable root_state =20 \ Now we're going to make the change effective =20 - s" cycle_stateN" \ base name of array state var - -rot 2dup 11 + c! rot \ replace 'N' with ASCII numeral - evaluate \ translate name into address - @ \ dereference address into value + dup cycle_stateN @ dup kernel_state ! \ save a copy for re-initialization 48 + \ convert to ASCII numeral =20 s" set kernel=3D${kernel_prefix}${kernel[N]}${kernel_suffix}" - \ command to assemble full kernel-path - -rot tuck 36 + c! swap \ replace 'N' with array index value - evaluate \ sets $kernel to full kernel-path + 36 +c! \ replace 'N' with ASCII numeral + evaluate \ sets $kernel to full kernel-path =20 TRUE \ loop menu again ; =20 +\=20 +\ Root +\=20 + : init_root ( N -- N ) root_state @ ( n -- n k ) init_cyclestate ( n k -- n ) @@ -211,21 +266,21 @@ variable root_state =20 \ Now we're going to make the change effective =20 - s" cycle_stateN" \ base name of array state var - -rot 2dup 11 + c! rot \ replace 'N' with ASCII numeral - evaluate \ translate name into address - @ \ dereference address into value + dup cycle_stateN @ dup root_state ! \ save a copy for re-initialization 48 + \ convert to ASCII numeral =20 s" set root=3D${root_prefix}${root[N]}${root_suffix}" - \ command to assemble root image-path - -rot tuck 30 + c! swap \ replace 'N' with array index value - evaluate \ sets $kernel to full kernel-path + 30 +c! \ replace 'N' with ASCII numeral + evaluate \ sets $root to full root-path =20 TRUE \ loop menu again ; =20 +\=20 +\ Menusets +\=20 + : goto_menu ( N M -- N TRUE ) menu-unset menuset-loadsetnum ( n m -- n ) Index: menu.4th =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- menu.4th (revision 242923) +++ menu.4th (working copy) @@ -116,6 +116,48 @@ create init_text6 255 allot create init_text7 255 allot create init_text8 255 allot =20 +: +c! ( N C-ADDR/U K -- C-ADDR/U ) + 3 pick 3 pick ( n c-addr/u k -- n c-addr/u k n c-addr ) + rot + c! ( n c-addr/u k n c-addr -- n c-addr/u ) + rot drop ( n c-addr/u -- c-addr/u ) +; + +: menukeyN ( N -- ADDR ) s" menukeyN" 7 +c! evaluate ; +: init_stateN ( N -- ADDR ) s" init_stateN" 10 +c! evaluate ; +: toggle_stateN ( N -- ADDR ) s" toggle_stateN" 12 +c! evaluate ; +: cycle_stateN ( N -- ADDR ) s" cycle_stateN" 11 +c! evaluate ; +: init_textN ( N -- C-ADDR ) s" init_textN" 9 +c! evaluate ; + +: str_loader_menu_title ( -- C-ADDR/U ) s" loader_menu_title" ; +: str_loader_menu_timeout_x ( -- C-ADDR/U ) s" loader_menu_timeout_x" ; +: str_loader_menu_timeout_y ( -- C-ADDR/U ) s" loader_menu_timeout_y" ; +: str_menu_init ( -- C-ADDR/U ) s" menu_init" ; +: str_menu_timeout_command ( -- C-ADDR/U ) s" menu_timeout_command" ; +: str_menu_reboot ( -- C-ADDR/U ) s" menu_reboot" ; +: str_menu_acpi ( -- C-ADDR/U ) s" menu_acpi" ; +: str_menu_options ( -- C-ADDR/U ) s" menu_options" ; +: str_menu_optionstext ( -- C-ADDR/U ) s" menu_optionstext" ; + +: str_menu_init[x] ( -- C-ADDR/U ) s" menu_init[x]" ; +: str_menu_command[x] ( -- C-ADDR/U ) s" menu_command[x]" ; +: str_menu_caption[x] ( -- C-ADDR/U ) s" menu_caption[x]" ; +: str_ansi_caption[x] ( -- C-ADDR/U ) s" ansi_caption[x]" ; +: str_menu_keycode[x] ( -- C-ADDR/U ) s" menu_keycode[x]" ; +: str_toggled_text[x] ( -- C-ADDR/U ) s" toggled_text[x]" ; +: str_toggled_ansi[x] ( -- C-ADDR/U ) s" toggled_ansi[x]" ; +: str_menu_caption[x][y] ( -- C-ADDR/U ) s" menu_caption[x][y]" ; +: str_ansi_caption[x][y] ( -- C-ADDR/U ) s" ansi_caption[x][y]" ; + +: menu_init[x] ( N -- C-ADDR/U ) str_menu_init[x] 10 +c! = ; +: menu_command[x] ( N -- C-ADDR/U ) str_menu_command[x] 13 +c! = ; +: menu_caption[x] ( N -- C-ADDR/U ) str_menu_caption[x] 13 +c! = ; +: ansi_caption[x] ( N -- C-ADDR/U ) str_ansi_caption[x] 13 +c! = ; +: menu_keycode[x] ( N -- C-ADDR/U ) str_menu_keycode[x] 13 +c! = ; +: toggled_text[x] ( N -- C-ADDR/U ) str_toggled_text[x] 13 +c! = ; +: toggled_ansi[x] ( N -- C-ADDR/U ) str_toggled_ansi[x] 13 +c! = ; +: menu_caption[x][y] ( N M -- C-ADDR/U ) str_menu_caption[x][y] 16 +c! = 13 +c! ; +: ansi_caption[x][y] ( N M -- C-ADDR/U ) str_ansi_caption[x][y] 16 +c! = 13 +c! ; + : arch-i386? ( -- BOOL ) \ Returns TRUE (-1) on i386, FALSE (0) = otherwise. s" arch-i386" environment? dup if drop @@ -172,10 +214,7 @@ create init_text8 255 allot \ ASCII numeral equal to user-selected menu item must be on the = stack. \ We do not modify the stack, so the ASCII numeral is left on = top. =20 - s" init_textN" \ base name of buffer - -rot 2dup 9 + c! rot \ replace 'N' with ASCII num - - evaluate c@ 0=3D if + dup init_textN c@ 0=3D if \ NOTE: no need to check toggle_stateN since the first = time we \ are called, we will populate init_textN. Further, we = don't \ need to test whether menu_caption[x] (ansi_caption[x] = when @@ -183,19 +222,16 @@ create init_text8 255 allot \ called if the caption was NULL. =20 \ base name of environment variable + dup ( n -- n n ) \ key pressed loader_color? if - s" ansi_caption[x]" + ansi_caption[x] else - s" menu_caption[x]" + menu_caption[x] then=09 - -rot 2dup 13 + c! rot \ replace 'x' with ASCII = numeral - getenv dup -1 <> if =20 - s" init_textN" \ base name of buffer - 4 pick \ copy ASCII num to top - rot tuck 9 + c! swap \ replace 'N' with ASCII = num - evaluate + 2 pick ( n c-addr/u -- n c-addr/u n ) + init_textN ( n c-addr/u n -- n c-addr/u c-addr ) =20 \ now we have the buffer c-addr on top \ ( followed by c-addr/u of current caption ) @@ -227,67 +263,49 @@ create init_text8 255 allot \ negate the toggled state so that we reverse the flow on = subsequent \ calls. =20 - s" toggle_stateN @" \ base name of toggle state var - -rot 2dup 12 + c! rot \ replace 'N' with ASCII numeral - - evaluate 0=3D if + dup toggle_stateN @ 0=3D if \ state is OFF, toggle to ON =20 - \ base name of toggled text var + dup ( n -- n n ) \ key pressed loader_color? if - s" toggled_ansi[x]" + toggled_ansi[x] else - s" toggled_text[x]" + toggled_text[x] then - -rot 2dup 13 + c! rot \ replace 'x' with ASCII num - getenv dup -1 <> if \ Assign toggled text to menu caption - - \ base name of caption var + 2 pick ( n c-addr/u -- n c-addr/u n ) \ key = pressed loader_color? if - s" ansi_caption[x]" + ansi_caption[x] else - s" menu_caption[x]" + menu_caption[x] then - 4 pick \ copy ASCII num to top - rot tuck 13 + c! swap \ replace 'x' with = ASCII num - - setenv \ set new caption + setenv else \ No toggled text, keep the same caption - - drop + drop ( n -1 -- n ) \ getenv cruft then =20 true \ new value of toggle state var (to be stored = later) else \ state is ON, toggle to OFF =20 - s" init_textN" \ base name of initial text = buffer - -rot 2dup 9 + c! rot \ replace 'N' with ASCII = numeral - evaluate \ convert string to c-addr - count \ convert c-addr to c-addr/u + dup init_textN count ( n -- n c-addr/u ) =20 - \ base name of caption var + \ Assign init_textN text to menu caption + 2 pick ( n c-addr/u -- n c-addr/u n ) \ key pressed loader_color? if - s" ansi_caption[x]" + ansi_caption[x] else - s" menu_caption[x]" + menu_caption[x] then - 4 pick \ copy ASCII num to top - rot tuck 13 + c! swap \ replace 'x' with ASCII = numeral + setenv =20 - setenv \ set new caption - false \ new value of toggle state var (to be stored = below) + false \ new value of toggle state var (to be stored = below) then =20 \ now we'll store the new toggle state (on top of stack) - s" toggle_stateN" \ base name of toggle state var - 3 pick \ copy ASCII numeral to top - rot tuck 12 + c! swap \ replace 'N' with ASCII numeral - evaluate \ convert string to addr - ! \ store new value + over toggle_stateN ! ; =20 : cycle_menuitem ( N -- N ) \ cycles through array of choices for a = menuitem @@ -295,28 +313,23 @@ create init_text8 255 allot \ ASCII numeral equal to user-selected menu item must be on the = stack. \ We do not modify the stack, so the ASCII numeral is left on = top. =20 - s" cycle_stateN" \ base name of array state var - -rot 2dup 11 + c! rot \ replace 'N' with ASCII numeral + dup cycle_stateN dup @ 1+ \ get value and increment =20 - evaluate \ we now have a pointer to the proper variable - dup @ \ resolve the pointer (but leave it on the stack) - 1+ \ increment the value - \ Before assigning the (incremented) value back to the pointer, \ let's test for the existence of this particular array element. \ If the element exists, we'll store index value and move on. \ Otherwise, we'll loop around to zero and store that. =20 - dup 48 + \ duplicate Array index and convert to ASCII numeral + dup 48 + ( n addr k -- n addr k k' ) + \ duplicate array index and convert to ASCII numeral =20 - \ base name of array caption text + 3 pick swap ( n addr k k' -- n addr k n k' ) \ (n,k') as (x,y) loader_color? if - s" ansi_caption[x][y]" =20 + ansi_caption[x][y] else - s" menu_caption[x][y]" =20 + menu_caption[x][y] then - -rot tuck 16 + c! swap \ replace 'y' with Array index - 4 pick rot tuck 13 + c! swap \ replace 'x' with menu choice + ( n addr k n k' -- n addr k c-addr/u ) =20 \ Now test for the existence of our incremented array index in = the \ form of $menu_caption[x][y] ($ansi_caption[x][y] with = loader_color @@ -325,49 +338,47 @@ create init_text8 255 allot getenv dup -1 =3D if \ No caption set for this array index. Loop back to = zero. =20 - drop ( getenv cruft ) - drop ( incremented array index ) - 0 ( new array index that will be stored later ) + drop ( n addr k -1 -- n addr k ) \ getenv cruft + drop 0 ( n addr k -- n addr 0 ) \ new value to store = later =20 - \ base name of caption var + 2 pick [char] 0 ( n addr 0 -- n addr 0 n 48 ) \ (n,48) = as (x,y) loader_color? if - s" ansi_caption[x][0]" + ansi_caption[x][y] else - s" menu_caption[x][0]" + menu_caption[x][y] then - 4 pick rot tuck 13 + c! swap \ replace 'x' with menu = choice - + ( n addr 0 n 48 -- n addr 0 c-addr/u ) getenv dup -1 =3D if \ This is highly unlikely to occur, but to make \ sure that things move along smoothly, allocate \ a temporary NULL string =20 - drop ( getenv cruft ) - s" " + drop ( n addr 0 -1 -- n addr 0 ) \ getenv cruft + s" " ( n addr 0 -- n addr 0 c-addr/u ) then then =20 \ At this point, we should have the following on the stack (in = order, \ from bottom to top): \=20 - \ N - Ascii numeral representing the menu choice = (inherited) - \ Addr - address of our internal cycle_stateN variable - \ N - zero-based number we intend to store to the above - \ C-Addr - string value we intend to store to menu_caption[x] - \ (or ansi_caption[x] with loader_color enabled) + \ n - Ascii numeral representing the menu choice = (inherited) + \ addr - address of our internal cycle_stateN variable + \ k - zero-based number we intend to store to the = above + \ c-addr/u - string value we intend to store to = menu_caption[x] + \ (or ansi_caption[x] with loader_color enabled) \=20 \ Let's perform what we need to with the above. =20 - \ base name of menuitem caption var + \ Assign array value text to menu caption + 4 pick ( n addr k c-addr/u -- n addr k c-addr/u n ) loader_color? if - s" ansi_caption[x]" + ansi_caption[x] else - s" menu_caption[x]" + menu_caption[x] then - 6 pick rot tuck 13 + c! swap \ replace 'x' with menu choice - setenv \ set the new caption + setenv =20 - swap ! \ update array state variable + swap ! ( n addr k -- n ) \ update array state variable ; =20 : acpipresent? ( -- flag ) \ Returns TRUE if ACPI is present, FALSE = otherwise @@ -401,15 +412,15 @@ create init_text8 255 allot acpipresent? if acpienabled? if loader_color? if - s" toggled_ansi[x]" + str_toggled_ansi[x] else - s" toggled_text[x]" + str_toggled_text[x] then else loader_color? if - s" ansi_caption[x]" + str_ansi_caption[x] else - s" menu_caption[x]" + str_menu_caption[x] then then else @@ -427,7 +438,7 @@ create init_text8 255 allot : menu-create ( -- ) =20 \ Print the frame caption at (x,y) - s" loader_menu_title" getenv dup -1 =3D if + str_loader_menu_title getenv dup -1 =3D if drop s" Welcome to FreeBSD" then 24 over 2 / - 9 at-xy type=20 @@ -436,7 +447,7 @@ create init_text8 255 allot \ constructed dynamically -- as this function could conceivably = set \ the remaining environment variables to construct the menu = entirely). \=20 - s" menu_init" getenv dup -1 <> if + str_menu_init getenv dup -1 <> if evaluate else drop @@ -461,7 +472,7 @@ create init_text8 255 allot \ Initialize the ACPI option status. \=20 0 menuacpi ! - s" menu_acpi" getenv -1 <> if + str_menu_acpi getenv -1 <> if c@ dup 48 > over 57 < and if ( '1' <=3D c1 <=3D '8' ) menuacpi ! arch-i386? if acpipresent? if @@ -469,10 +480,7 @@ create init_text8 255 allot \ Set menu toggle state to active state \ (required by generic toggle_menuitem) \=20 - menuacpi @ - s" acpienabled? toggle_stateN !" - -rot tuck 25 + c! swap - evaluate + acpienabled? menuacpi @ toggle_stateN ! then then else drop @@ -483,7 +491,7 @@ create init_text8 255 allot \ Initialize the menu_options visual separator. \=20 0 menuoptions ! - s" menu_options" getenv -1 <> if + str_menu_options getenv -1 <> if c@ dup 48 > over 57 < and if ( '1' <=3D c1 <=3D '8' ) menuoptions ! else @@ -503,7 +511,7 @@ create init_text8 255 allot \ If the "Options:" separator, print it. dup menuoptions @ =3D if \ Optionally add a reboot option to the menu - s" menu_reboot" getenv -1 <> if + str_menu_reboot getenv -1 <> if drop s" Reboot" printmenuitem menureboot ! true menurebootadded ! @@ -513,7 +521,7 @@ create init_text8 255 allot menurow @ 2 + menurow ! menurow @ menuY @ + at-xy - s" menu_optionstext" getenv dup -1 <> if + str_menu_optionstext getenv dup -1 <> if type else drop ." Options:" @@ -522,17 +530,21 @@ create init_text8 255 allot =20 \ If this is the ACPI menu option, act accordingly. dup menuacpi @ =3D if - acpimenuitem ( -- C-Addr/U | -1 ) + dup acpimenuitem ( n -- n n c-addr/u | n n -1 ) + dup -1 <> if + 13 +c! ( n n c-addr/u -- n c-addr/u ) + \ replace 'x' with n + else + swap drop ( n n -1 -- n -1 ) + over menu_command[x] unsetenv + then else \ make sure we have not already initialized this = item - s" init_stateN" - -rot 2dup 10 + c! rot \ repace 'N' - evaluate dup @ 0=3D if + dup init_stateN dup @ 0=3D if 1 swap ! =20 \ If this menuitem has an initializer, = run it - s" menu_init[x]" - -rot 2dup 10 + c! rot \ replace 'x' + dup menu_init[x] getenv dup -1 <> if evaluate else @@ -542,35 +554,24 @@ create init_text8 255 allot drop then =20 + dup loader_color? if - s" ansi_caption[x]" + ansi_caption[x] else - s" menu_caption[x]" + menu_caption[x] then then =20 - ( C-Addr/U | -1 ) dup -1 <> if - \ replace 'x' with current iteration - -rot 2dup 13 + c! rot - =20 \ test for environment variable getenv dup -1 <> if - printmenuitem ( C-Addr/U -- N ) - =20 - s" menukeyN !" \ generate cmd to store = result - -rot 2dup 7 + c! rot - =20 - evaluate + printmenuitem ( c-addr/u -- n ) + dup menukeyN ! else drop then else drop - - s" menu_command[x]" - -rot 2dup 13 + c! rot ( replace 'x' ) - unsetenv then =20 1+ dup 56 > \ add 1 to iterator, continue if less than = 57 @@ -579,7 +580,7 @@ create init_text8 255 allot =20 \ Optionally add a reboot option to the menu menurebootadded @ true <> if - s" menu_reboot" getenv -1 <> if + str_menu_reboot getenv -1 <> if drop \ no need for the value s" Reboot" \ menu caption (required by = printmenuitem) =20 @@ -597,45 +598,22 @@ create init_text8 255 allot \=20 : menu-timeout-update ( N -- ) =20 - dup 9 > if ( N N 9 -- N ) - drop ( N -- ) - 9 ( maximum: -- N ) - then + \ Enforce minimum/maximum + dup 9 > if drop 9 then + dup 0 < if drop 0 then =20 - dup 0 < if ( N N 0 -- N ) - drop ( N -- ) - 0 ( minimum: -- N ) - then + s" Autoboot in N seconds. [Space] to pause" ( n -- n c-addr/u ) =20 - 48 + ( convert single-digit numeral to ASCII: N 48 -- N ) + 2 pick 0> if + rot 48 + -rot ( n c-addr/u -- n' c-addr/u ) \ convert to = ASCII + 12 +c! ( n' c-addr/u -- c-addr/u ) \ replace = 'N' above =20 - s" Autoboot in N seconds. [Space] to pause" ( N -- N Addr C ) - - 2 pick 48 - 0> if ( N Addr C N 48 -- N Addr C ) - - \ Modify 'N' (Addr+12) above to reflect time-left - - -rot ( N Addr C -- C N Addr ) - tuck ( C N Addr -- C Addr N Addr ) - 12 + ( C Addr N Addr -- C Addr N Addr2 ) - c! ( C Addr N Addr2 -- C Addr ) - swap ( C Addr -- Addr C ) - - menu_timeout_x @ - menu_timeout_y @ - at-xy ( position cursor: Addr C N N -- Addr C ) - - type ( print message: Addr C -- ) - - else ( N Addr C N -- N Addr C ) - - menu_timeout_x @ - menu_timeout_y @ - at-xy ( position cursor: N Addr C N N -- N Addr C ) - - spaces ( erase message: N Addr C -- N Addr ) - 2drop ( N Addr -- ) - + menu_timeout_x @ menu_timeout_y @ at-xy \ position = cursor + type ( c-addr/u -- ) \ print message + else + menu_timeout_x @ menu_timeout_y @ at-xy \ position = cursor + spaces ( n c-addr/u -- n c-addr ) \ erase message + 2drop ( n c-addr -- ) then =20 0 25 at-xy ( position cursor back at bottom-left ) @@ -683,7 +661,7 @@ create init_text8 255 allot \ (user did not cancel by = pressing ANY \ key) =20 - s" menu_timeout_command" getenv = dup + str_menu_timeout_command getenv = dup -1 =3D if drop \ clean-up else @@ -766,7 +744,7 @@ create init_text8 255 allot 0 menu_timeout_enabled ! \ start with automatic timeout disabled =20 \ check indication that automatic execution after delay is = requested - s" menu_timeout_command" getenv -1 <> if ( Addr C -1 -- | Addr ) + str_menu_timeout_command getenv -1 <> if ( Addr C -1 -- | Addr ) drop ( just testing existence right now: Addr -- ) =20 \ initialize state variables @@ -802,7 +780,7 @@ create init_text8 255 allot =20 menu_timeout_enabled @ 1 =3D if \ read custom column position (if set) - s" loader_menu_timeout_x" getenv dup -1 =3D if + str_loader_menu_timeout_x getenv dup -1 =3D if drop \ no custom column position menu_timeout_default_x \ use default = setting else @@ -814,7 +792,7 @@ create init_text8 255 allot menu_timeout_x ! ( store value on stack from = above ) =20 \ read custom row position (if set) - s" loader_menu_timeout_y" getenv dup -1 =3D if + str_loader_menu_timeout_y getenv dup -1 =3D if drop \ no custom row position menu_timeout_default_y \ use default = setting else @@ -853,13 +831,9 @@ create init_text8 255 allot =20 49 \ Iterator start (loop range 49 to 56; ASCII '1' to = '8') begin - s" menukeyN @" + dup menukeyN @ + rot tuck =3D if =20 - \ replace 'N' with current iteration - -rot 2dup 7 + c! rot - - evaluate rot tuck =3D if - \ Adjust for missing ACPI menuitem on = non-i386 arch-i386? true <> menuacpi @ 0<> and if menuacpi @ over 2dup < -rot =3D = or @@ -869,13 +843,8 @@ create init_text8 255 allot then then =20 - \ base env name for the value (x is a = number) - s" menu_command[x]" - - \ Copy ASCII number to string at offset = 13 - -rot 2dup 13 + c! rot - \ Test for the environment variable + dup menu_command[x] getenv dup -1 <> if \ Execute the stored procedure evaluate @@ -910,16 +879,14 @@ create init_text8 255 allot \=20 \ Check for menu keycode shortcut(s) \=20 - s" menu_keycode[x]" - -rot 2dup 13 + c! rot + dup menu_keycode[x] getenv dup -1 =3D if drop else ?number 0<> if rot tuck =3D if swap - s" menu_command[x]" - -rot 2dup 13 + c! rot + dup menu_command[x] getenv dup -1 <> if evaluate 0=3D if @@ -951,100 +918,43 @@ create init_text8 255 allot =20 49 \ Iterator start (loop range 49 to 56; ASCII '1' to '8') begin - \ Unset variables in-order of appearance in menu.4th(8) + dup menu_init[x] unsetenv \ menu initializer + dup menu_command[x] unsetenv \ menu command + dup menu_caption[x] unsetenv \ menu caption + dup ansi_caption[x] unsetenv \ ANSI caption + dup menu_keycode[x] unsetenv \ menu keycode + dup toggled_text[x] unsetenv \ toggle_menuitem = caption + dup toggled_ansi[x] unsetenv \ toggle_menuitem ANSI = caption =20 - s" menu_caption[x]" \ basename for caption variable - -rot 2dup 13 + c! rot \ replace 'x' with current = iteration - unsetenv \ not erroneous to unset unknown = var - - s" menu_command[x]" \ command basename - -rot 2dup 13 + c! rot \ replace 'x' - unsetenv - - s" menu_init[x]" \ initializer basename - -rot 2dup 10 + c! rot \ replace 'x' - unsetenv - - s" menu_keycode[x]" \ keycode basename - -rot 2dup 13 + c! rot \ replace 'x' - unsetenv - - s" ansi_caption[x]" \ ANSI caption basename - -rot 2dup 13 + c! rot \ replace 'x' - unsetenv - - s" toggled_text[x]" \ toggle_menuitem caption = basename - -rot 2dup 13 + c! rot \ replace 'x' - unsetenv - - s" toggled_ansi[x]" \ toggle_menuitem ANSI caption = basename - -rot 2dup 13 + c! rot \ replace 'x' - unsetenv - - s" menu_caption[x][y]" \ cycle_menuitem caption - -rot 2dup 13 + c! rot \ replace 'x' - 48 -rot + 48 \ Iterator start (inner range 48 to 57; ASCII '0' to = '9') begin - 16 2over rot + c! \ replace 'y' - 2dup unsetenv - - rot 1+ dup 57 > 2swap rot + \ cycle_menuitem caption and ANSI caption + 2dup menu_caption[x][y] unsetenv + 2dup ansi_caption[x][y] unsetenv + 1+ dup 57 > until - 2drop drop + drop \ inner iterator =20 - s" ansi_caption[x][y]" \ cycle_menuitem ANSI caption - -rot 2dup 13 + c! rot \ replace 'x' - 48 -rot - begin - 16 2over rot + c! \ replace 'y' - 2dup unsetenv + 0 over menukeyN ! \ used by menu-create, = menu-display + 0 over init_stateN ! \ used by menu-create + 0 over toggle_stateN ! \ used by toggle_menuitem + 0 over init_textN c! \ used by toggle_menuitem + 0 over cycle_stateN ! \ used by cycle_menuitem =20 - rot 1+ dup 57 > 2swap rot - until - 2drop drop - - s" 0 menukeyN !" \ basename for key association = var - -rot 2dup 9 + c! rot \ replace 'N' with current = iteration - evaluate \ assign zero (0) to key assoc. = var - - s" 0 init_stateN !" \ used by menu-create - -rot 2dup 12 + c! rot \ replace 'N' - evaluate - - s" 0 toggle_stateN !" \ used by toggle_menuitem - -rot 2dup 14 + c! rot \ replace 'N' - evaluate - - s" 0 cycle_stateN !" \ used by cycle_menuitem - -rot 2dup 13 + c! rot \ replace 'N' - evaluate - - s" 0 init_textN c!" \ used by toggle_menuitem - -rot 2dup 11 + c! rot \ replace 'N' - evaluate - 1+ dup 56 > \ increment, continue if less than 57 until drop \ iterator =20 - \ unset the timeout command - s" menu_timeout_command" unsetenv + str_menu_timeout_command unsetenv \ menu timeout command + str_menu_reboot unsetenv \ Reboot menu option = flag + str_menu_acpi unsetenv \ ACPI menu option flag + str_menu_options unsetenv \ Options separator flag + str_menu_optionstext unsetenv \ separator display text + str_menu_init unsetenv \ menu initializer =20 - \ clear the "Reboot" menu option flag - s" menu_reboot" unsetenv 0 menureboot ! - - \ clear the ACPI menu option flag - s" menu_acpi" unsetenv 0 menuacpi ! - - \ clear the "Options" menu separator flag - s" menu_options" unsetenv - s" menu_optionstext" unsetenv 0 menuoptions ! - - \ clear the menu initializer - s" menu_init" unsetenv ; =20 \ This function both unsets menu variables and visually erases the menu = area --Apple-Mail=_769728F7-62D7-41E2-9431-E82F021FEFE6-- From owner-freebsd-current@FreeBSD.ORG Mon Nov 12 20:22:10 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0D1DB208 for ; Mon, 12 Nov 2012 20:22:10 +0000 (UTC) (envelope-from sfourman@gmail.com) Received: from mail-ee0-f54.google.com (mail-ee0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id 8AF078FC14 for ; Mon, 12 Nov 2012 20:22:09 +0000 (UTC) Received: by mail-ee0-f54.google.com with SMTP id c13so688634eek.13 for ; Mon, 12 Nov 2012 12:22:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=zfsaVGu9calbMEHC3fQBqvS2Wc8fDlTPztqcLCvolOU=; b=DL3h7sfYq1LL8Cic2nLLCJVJig4ZFrS/i7gpWH7P/P6knp3ZwpY0xrLJPjCYdsfcWL OZGKWDqnuNVh1oV3xYhirv6OisoHNK3kLR/M2qAWx/q2eUTaYM3dfxzh65Je1QGchvE/ tB6/CpYMeNmZaGeqM52KpDcuGUSrRYzpgBP38LWmpBy9k61QaWfk5sw42jg1XJkx1dH/ QptWp2rat8kB09ohXkWZmZgm1r8tAB3/nIP/Adnsx3s1S1OID974jt+4PIp7LCSMvfK4 Btkbf997IL38fvNEx49kiHAv0SWth7qcbKzJi0amEXuW0qg0gTKx73U7vjbuExycSV77 0eHA== MIME-Version: 1.0 Received: by 10.14.203.132 with SMTP id f4mr66769754eeo.11.1352751728514; Mon, 12 Nov 2012 12:22:08 -0800 (PST) Received: by 10.14.216.201 with HTTP; Mon, 12 Nov 2012 12:22:08 -0800 (PST) Date: Mon, 12 Nov 2012 20:22:08 +0000 Message-ID: Subject: USB keyboard problem From: "Sam Fourman Jr." To: FreeBSD Current Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 20:22:10 -0000 hello, I believe my keyboard is being detected as a mouse by mistake using amd64 HEAD svn r242748 I can not use this keyboard, I have to plug in another one. this is also broken in FreeBSD 9.1RC3 is this simple to patch? any help is appreciated uhid0: on usbus0 uhid1: on usbus3 ums0: on usbus0 ums0: 3 buttons and [XYZ] coordinates ID=0 ums1: on usbus0 ums1: 7 buttons and [XYZ] coordinates ID=0 verbose dmesg follows http://www.samjess.com/keyboard.txt -- Sam Fourman Jr. From owner-freebsd-current@FreeBSD.ORG Mon Nov 12 23:11:51 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 100EBC86 for ; Mon, 12 Nov 2012 23:11:51 +0000 (UTC) (envelope-from levitch@iglou.com) Received: from rdsmtp.iglou.com (rdsmtp.iglou.com [192.107.41.63]) by mx1.freebsd.org (Postfix) with ESMTP id BD6DC8FC0C for ; Mon, 12 Nov 2012 23:11:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=iglou.com; s=alpha; h=Content-Type:MIME-Version:Message-ID:Subject:To:From:Date; bh=o9r0THOyad9a/jUI0HVKBWtb+bSMz27eMkuqin6ZLeQ=; b=P5iGzMj/vnwCfCgZf1txgKmkfTr73ML7t0v/s2wskB22rS0swjzALu7fqfA4inIwNdiIQ/9go5BovY13Ob0zbowYmr4RMgQT8xnRmFOc91Y37xPWrBr6WyddKZ1L/VT+KT/WfIcZ4HYroqjzEkzMDl2IzT6I9cMJ3I9GB0hGiFA=; Received: from iglou2.iglou.com ([192.107.41.8]:51118 helo=mail.iglou.com) by rdsmtp.iglou.com with esmtpa (Exim MTA/8.19.3) (envelope-from ) id 1TY3AO-0004ja-D0 by authid with igloumta_auth for current@freebsd.org; Mon, 12 Nov 2012 18:11:44 -0500 Received: from shell1.iglou.com ([192.107.41.17]:42638 helo=shell1) by mail.iglou.com with esmtps (TLS cipher TLSv1:AES256-SHA:256) (Exim MTA/8.19.3) (envelope-from ) id 1TY3AO-0004kW-1s for current@freebsd.org; Mon, 12 Nov 2012 18:11:44 -0500 Date: Mon, 12 Nov 2012 18:11:43 -0500 (EST) From: Darrel X-X-Sender: levitch@shell1 To: current@freebsd.org Subject: can't open '/boot/menusets.4th' Message-ID: User-Agent: Alpine 2.00 (GSO 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Originating-IP: 192.107.41.17 X-IgLou-Customer: 3cb6f76205bd20f518810676a67a982b X-Mailman-Approved-At: Mon, 12 Nov 2012 23:43:44 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 23:11:51 -0000 Hello, Today I booted r242670 from the console and noticed this error message: can't open '/boot/menusets.4th': no such file of directory Error while including /boot/menu-commands.4th, in the line include /boot/menusets.4th Error while including /boot/menu.rc, in the line include /boot/menu-commands.4th Anyone seen this before? Darrel From owner-freebsd-current@FreeBSD.ORG Mon Nov 12 23:50:10 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 80D297BB for ; Mon, 12 Nov 2012 23:50:10 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: from mail-wg0-f42.google.com (mail-wg0-f42.google.com [74.125.82.42]) by mx1.freebsd.org (Postfix) with ESMTP id 0D9868FC12 for ; Mon, 12 Nov 2012 23:50:09 +0000 (UTC) Received: by mail-wg0-f42.google.com with SMTP id fm10so1900360wgb.1 for ; Mon, 12 Nov 2012 15:50:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=+I14ukoNzWplww1hMNbzwKQ77qjM2FPw/nU9550JIPs=; b=sq5lz7buGaYHTE0sGznc9AfT8jeL9U5AHrpdTuBqokKMmkvc/L7v3oxF6oeNsX/tH/ FBS0Tw3GxeDpXXAvJIrK7VqaY65XSfhVgXAe69DRHLlXd2UR2O5H0MknVIiHW/JPioUY GLq8YEITOj9f8EJH4V3x7KaNp1Fjyz3OTCbkNiPOdqZlnhhMOAMoxzyzeO2C3bJES/oP 1gye2hJVqjbAYSbXS7KGURUB4YzBjR0uiF4+lt1SE066G2v9AYASW7DPt7hRfey2wfAA aVn7HNH8iXDvZmr9cf5HO6DU/wKi9Cx8XcOFV73RDdR475k2n2pRQmnQBiDlcLpjjXb7 BvIQ== Received: by 10.216.204.139 with SMTP id h11mr8465944weo.128.1352764203219; Mon, 12 Nov 2012 15:50:03 -0800 (PST) Received: from dft-labs.eu (n1x0n-1-pt.tunnel.tserv5.lon1.ipv6.he.net. [2001:470:1f08:1f7::2]) by mx.google.com with ESMTPS id c7sm9864911wix.6.2012.11.12.15.50.02 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 12 Nov 2012 15:50:02 -0800 (PST) Date: Tue, 13 Nov 2012 00:49:52 +0100 From: Mateusz Guzik To: Darrel Subject: Re: can't open '/boot/menusets.4th' Message-ID: <20121112234952.GA17144@dft-labs.eu> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 23:50:10 -0000 On Mon, Nov 12, 2012 at 06:11:43PM -0500, Darrel wrote: > Hello, > > Today I booted r242670 from the console and noticed this error message: > can't open '/boot/menusets.4th': no such file of directory > > Error while including /boot/menu-commands.4th, in the line > include /boot/menusets.4th > > Error while including /boot/menu.rc, in the line > include /boot/menu-commands.4th > Seems to be fixed by r242688. -- Mateusz Guzik From owner-freebsd-current@FreeBSD.ORG Mon Nov 12 23:50:32 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C68478BC; Mon, 12 Nov 2012 23:50:32 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from onyx.glenbarber.us (onyx.glenbarber.us [IPv6:2607:fc50:1000:c200::face]) by mx1.freebsd.org (Postfix) with ESMTP id 9CD868FC12; Mon, 12 Nov 2012 23:50:32 +0000 (UTC) Received: from glenbarber.us (unknown [IPv6:2001:470:8:1205:2:2:0:100]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: gjb) by onyx.glenbarber.us (Postfix) with ESMTPSA id 9A1FD23F654; Mon, 12 Nov 2012 18:50:31 -0500 (EST) Date: Mon, 12 Nov 2012 18:50:29 -0500 From: Glen Barber To: Darrel Subject: Re: can't open '/boot/menusets.4th' Message-ID: <20121112235029.GB1435@glenbarber.us> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="/NkBOFFp2J2Af1nK" Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 23:50:32 -0000 --/NkBOFFp2J2Af1nK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Nov 12, 2012 at 06:11:43PM -0500, Darrel wrote: > Hello, >=20 > Today I booted r242670 from the console and noticed this error message: > can't open '/boot/menusets.4th': no such file of directory >=20 > Error while including /boot/menu-commands.4th, in the line > include /boot/menusets.4th >=20 > Error while including /boot/menu.rc, in the line > include /boot/menu-commands.4th >=20 > Anyone seen this before? >=20 Yes. This is fixed a few hours after it was introduced. Glen --/NkBOFFp2J2Af1nK Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBCAAGBQJQoYtFAAoJEFJPDDeguUajpNYH/0MkXCaPRONQkkQxhO8WulwL VsFXPJvN4GEJa6ouL4vJB2gqN6Ivsz6DxGsb0hdq6n2wJfSnVnVOdCqr1K8CpsnK K+8Hma+sEVjaBsZaMZHqGjz4XOoyBGmhY/V3WIBz4YIwOOJE9XfSjH5xRnbwi+6a yoL3GNDy1QSIk6qvyy+XDrqz8O0062JpFWKSZEhLrn4+DvUSjp631U2BcOyfSkdj 7LQlESpG25aDSWMajl7o8YsdpiXOMwUEqEqESuLb1USUG//QELsR30vuV6SQxR5t ifdDbB1f7Yj8/r8FV6kFBkXg0aSld8m/7M8PBFQAgcufaD+dY9HtH5hUqqHYO08= =MUQr -----END PGP SIGNATURE----- --/NkBOFFp2J2Af1nK-- From owner-freebsd-current@FreeBSD.ORG Mon Nov 12 23:39:00 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1763F4BA for ; Mon, 12 Nov 2012 23:39:00 +0000 (UTC) (envelope-from levitch@iglou.com) Received: from rdsmtp.iglou.com (rdsmtp.iglou.com [192.107.41.63]) by mx1.freebsd.org (Postfix) with ESMTP id C65188FC0C for ; Mon, 12 Nov 2012 23:38:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=iglou.com; s=alpha; h=Content-Type:MIME-Version:Message-ID:Subject:To:From:Date; bh=xu3Q0EdKUoMkIVKxm97rjV2aIcUfBrGGKVeq8bx05jQ=; b=oprhukovGqNl+hDaILXExYTX7Qfj/AFnlpcVHNjJ7a0dRRB9W4my+fE27K8IkG4mV1nVB1nttxncf9EEVdYfLz/BkKwtJjX9DdKyzskY/B/zCVMTYH1+kpBUar0/v6Y7MrAduA0XTNmlWQD9BTdcwfFb7rGu5Rs7J8DI+GIPN50=; Received: from iglou2.iglou.com ([192.107.41.8]:56762 helo=mail.iglou.com) by rdsmtp.iglou.com with esmtpa (Exim MTA/8.19.3) (envelope-from ) id 1TY3al-00004I-82 by authid with igloumta_auth for current@freebsd.org; Mon, 12 Nov 2012 18:38:59 -0500 Received: from shell1.iglou.com ([192.107.41.17]:42695 helo=shell1) by mail.iglou.com with esmtps (TLS cipher TLSv1:AES256-SHA:256) (Exim MTA/8.19.3) (envelope-from ) id 1TY3ak-0000ZL-UG for current@freebsd.org; Mon, 12 Nov 2012 18:38:59 -0500 Date: Mon, 12 Nov 2012 18:38:58 -0500 (EST) From: Darrel X-X-Sender: levitch@shell1 To: current@freebsd.org Subject: Too many dynamic rules Message-ID: User-Agent: Alpine 2.00 (GSO 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Originating-IP: 192.107.41.17 X-IgLou-Customer: 3cb6f76205bd20f518810676a67a982b X-Mailman-Approved-At: Tue, 13 Nov 2012 00:06:20 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 23:39:00 -0000 Hello, Today I booted r242670 from the console and noticed an error. This is one line from the end of dmesg: ipfw: ipfw_install_state: Too many dynamic rules The ruleset has always been dynamic and has no additional rules. Search engines produced similar error messages, but no information that seems to be the correct solution. I have a basically identical ruleset on fbsd91 and no error message. Any ideas? Darrel From owner-freebsd-current@FreeBSD.ORG Tue Nov 13 00:49:45 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9312B68C; Tue, 13 Nov 2012 00:49:45 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 5BBBB8FC0C; Tue, 13 Nov 2012 00:49:45 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id qAD0nc2N052954; Mon, 12 Nov 2012 19:49:38 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id qAD0nc09052942; Tue, 13 Nov 2012 00:49:38 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 13 Nov 2012 00:49:38 GMT Message-Id: <201211130049.qAD0nc09052942@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on i386/i386 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 00:49:45 -0000 TB --- 2012-11-12 18:40:00 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-11-12 18:40:00 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-11-12 18:40:00 - starting HEAD tinderbox run for i386/i386 TB --- 2012-11-12 18:40:00 - cleaning the object tree TB --- 2012-11-12 18:48:32 - checking out /src from svn://svn.freebsd.org/base/head TB --- 2012-11-12 18:48:32 - cd /tinderbox/HEAD/i386/i386 TB --- 2012-11-12 18:48:32 - /usr/local/bin/svn cleanup /src TB --- 2012-11-12 18:50:36 - /usr/local/bin/svn update /src TB --- 2012-11-12 18:50:43 - At svn revision 242923 TB --- 2012-11-12 18:50:44 - building world TB --- 2012-11-12 18:50:44 - CROSS_BUILD_TESTING=YES TB --- 2012-11-12 18:50:44 - MAKEOBJDIRPREFIX=/obj TB --- 2012-11-12 18:50:44 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-11-12 18:50:44 - SRCCONF=/dev/null TB --- 2012-11-12 18:50:44 - TARGET=i386 TB --- 2012-11-12 18:50:44 - TARGET_ARCH=i386 TB --- 2012-11-12 18:50:44 - TZ=UTC TB --- 2012-11-12 18:50:44 - __MAKE_CONF=/dev/null TB --- 2012-11-12 18:50:44 - cd /src TB --- 2012-11-12 18:50:44 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Mon Nov 12 18:50:50 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Mon Nov 12 21:46:44 UTC 2012 TB --- 2012-11-12 21:46:44 - generating LINT kernel config TB --- 2012-11-12 21:46:44 - cd /src/sys/i386/conf TB --- 2012-11-12 21:46:44 - /usr/bin/make -B LINT TB --- 2012-11-12 21:46:44 - cd /src/sys/i386/conf TB --- 2012-11-12 21:46:44 - /usr/sbin/config -m LINT TB --- 2012-11-12 21:46:44 - building LINT kernel TB --- 2012-11-12 21:46:44 - CROSS_BUILD_TESTING=YES TB --- 2012-11-12 21:46:44 - MAKEOBJDIRPREFIX=/obj TB --- 2012-11-12 21:46:44 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-11-12 21:46:44 - SRCCONF=/dev/null TB --- 2012-11-12 21:46:44 - TARGET=i386 TB --- 2012-11-12 21:46:44 - TARGET_ARCH=i386 TB --- 2012-11-12 21:46:44 - TZ=UTC TB --- 2012-11-12 21:46:44 - __MAKE_CONF=/dev/null TB --- 2012-11-12 21:46:44 - cd /src TB --- 2012-11-12 21:46:44 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Nov 12 21:46:45 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT completed on Mon Nov 12 22:17:00 UTC 2012 TB --- 2012-11-12 22:17:00 - cd /src/sys/i386/conf TB --- 2012-11-12 22:17:00 - /usr/sbin/config -m LINT-NOINET TB --- 2012-11-12 22:17:00 - building LINT-NOINET kernel TB --- 2012-11-12 22:17:00 - CROSS_BUILD_TESTING=YES TB --- 2012-11-12 22:17:00 - MAKEOBJDIRPREFIX=/obj TB --- 2012-11-12 22:17:00 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-11-12 22:17:00 - SRCCONF=/dev/null TB --- 2012-11-12 22:17:00 - TARGET=i386 TB --- 2012-11-12 22:17:00 - TARGET_ARCH=i386 TB --- 2012-11-12 22:17:00 - TZ=UTC TB --- 2012-11-12 22:17:00 - __MAKE_CONF=/dev/null TB --- 2012-11-12 22:17:00 - cd /src TB --- 2012-11-12 22:17:00 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET >>> Kernel build for LINT-NOINET started on Mon Nov 12 22:17:00 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT-NOINET completed on Mon Nov 12 22:43:53 UTC 2012 TB --- 2012-11-12 22:43:53 - cd /src/sys/i386/conf TB --- 2012-11-12 22:43:53 - /usr/sbin/config -m LINT-NOINET6 TB --- 2012-11-12 22:43:53 - building LINT-NOINET6 kernel TB --- 2012-11-12 22:43:53 - CROSS_BUILD_TESTING=YES TB --- 2012-11-12 22:43:53 - MAKEOBJDIRPREFIX=/obj TB --- 2012-11-12 22:43:53 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-11-12 22:43:53 - SRCCONF=/dev/null TB --- 2012-11-12 22:43:53 - TARGET=i386 TB --- 2012-11-12 22:43:53 - TARGET_ARCH=i386 TB --- 2012-11-12 22:43:53 - TZ=UTC TB --- 2012-11-12 22:43:53 - __MAKE_CONF=/dev/null TB --- 2012-11-12 22:43:53 - cd /src TB --- 2012-11-12 22:43:53 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET6 >>> Kernel build for LINT-NOINET6 started on Mon Nov 12 22:43:53 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT-NOINET6 completed on Mon Nov 12 23:11:26 UTC 2012 TB --- 2012-11-12 23:11:26 - cd /src/sys/i386/conf TB --- 2012-11-12 23:11:26 - /usr/sbin/config -m LINT-NOIP TB --- 2012-11-12 23:11:26 - building LINT-NOIP kernel TB --- 2012-11-12 23:11:26 - CROSS_BUILD_TESTING=YES TB --- 2012-11-12 23:11:26 - MAKEOBJDIRPREFIX=/obj TB --- 2012-11-12 23:11:26 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-11-12 23:11:26 - SRCCONF=/dev/null TB --- 2012-11-12 23:11:26 - TARGET=i386 TB --- 2012-11-12 23:11:26 - TARGET_ARCH=i386 TB --- 2012-11-12 23:11:26 - TZ=UTC TB --- 2012-11-12 23:11:26 - __MAKE_CONF=/dev/null TB --- 2012-11-12 23:11:26 - cd /src TB --- 2012-11-12 23:11:26 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOIP >>> Kernel build for LINT-NOIP started on Mon Nov 12 23:11:26 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT-NOIP completed on Mon Nov 12 23:35:43 UTC 2012 TB --- 2012-11-12 23:35:43 - cd /src/sys/i386/conf TB --- 2012-11-12 23:35:43 - /usr/sbin/config -m LINT-VIMAGE TB --- 2012-11-12 23:35:43 - building LINT-VIMAGE kernel TB --- 2012-11-12 23:35:43 - CROSS_BUILD_TESTING=YES TB --- 2012-11-12 23:35:43 - MAKEOBJDIRPREFIX=/obj TB --- 2012-11-12 23:35:43 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-11-12 23:35:43 - SRCCONF=/dev/null TB --- 2012-11-12 23:35:43 - TARGET=i386 TB --- 2012-11-12 23:35:43 - TARGET_ARCH=i386 TB --- 2012-11-12 23:35:43 - TZ=UTC TB --- 2012-11-12 23:35:43 - __MAKE_CONF=/dev/null TB --- 2012-11-12 23:35:43 - cd /src TB --- 2012-11-12 23:35:43 - /usr/bin/make -B buildkernel KERNCONF=LINT-VIMAGE >>> Kernel build for LINT-VIMAGE started on Mon Nov 12 23:35:43 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT-VIMAGE completed on Tue Nov 13 00:04:04 UTC 2012 TB --- 2012-11-13 00:04:04 - cd /src/sys/i386/conf TB --- 2012-11-13 00:04:04 - /usr/sbin/config -m GENERIC TB --- 2012-11-13 00:04:04 - building GENERIC kernel TB --- 2012-11-13 00:04:04 - CROSS_BUILD_TESTING=YES TB --- 2012-11-13 00:04:04 - MAKEOBJDIRPREFIX=/obj TB --- 2012-11-13 00:04:04 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-11-13 00:04:04 - SRCCONF=/dev/null TB --- 2012-11-13 00:04:04 - TARGET=i386 TB --- 2012-11-13 00:04:04 - TARGET_ARCH=i386 TB --- 2012-11-13 00:04:04 - TZ=UTC TB --- 2012-11-13 00:04:04 - __MAKE_CONF=/dev/null TB --- 2012-11-13 00:04:04 - cd /src TB --- 2012-11-13 00:04:04 - /usr/bin/make -B buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Tue Nov 13 00:04:04 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for GENERIC completed on Tue Nov 13 00:30:44 UTC 2012 TB --- 2012-11-13 00:30:44 - cd /src/sys/i386/conf TB --- 2012-11-13 00:30:44 - /usr/sbin/config -m PAE TB --- 2012-11-13 00:30:44 - building PAE kernel TB --- 2012-11-13 00:30:44 - CROSS_BUILD_TESTING=YES TB --- 2012-11-13 00:30:44 - MAKEOBJDIRPREFIX=/obj TB --- 2012-11-13 00:30:44 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-11-13 00:30:44 - SRCCONF=/dev/null TB --- 2012-11-13 00:30:44 - TARGET=i386 TB --- 2012-11-13 00:30:44 - TARGET_ARCH=i386 TB --- 2012-11-13 00:30:44 - TZ=UTC TB --- 2012-11-13 00:30:44 - __MAKE_CONF=/dev/null TB --- 2012-11-13 00:30:44 - cd /src TB --- 2012-11-13 00:30:44 - /usr/bin/make -B buildkernel KERNCONF=PAE >>> Kernel build for PAE started on Tue Nov 13 00:30:44 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for PAE completed on Tue Nov 13 00:39:24 UTC 2012 TB --- 2012-11-13 00:39:24 - cd /src/sys/i386/conf TB --- 2012-11-13 00:39:24 - /usr/sbin/config -m XBOX TB --- 2012-11-13 00:39:24 - building XBOX kernel TB --- 2012-11-13 00:39:24 - CROSS_BUILD_TESTING=YES TB --- 2012-11-13 00:39:24 - MAKEOBJDIRPREFIX=/obj TB --- 2012-11-13 00:39:24 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-11-13 00:39:24 - SRCCONF=/dev/null TB --- 2012-11-13 00:39:24 - TARGET=i386 TB --- 2012-11-13 00:39:24 - TARGET_ARCH=i386 TB --- 2012-11-13 00:39:24 - TZ=UTC TB --- 2012-11-13 00:39:24 - __MAKE_CONF=/dev/null TB --- 2012-11-13 00:39:24 - cd /src TB --- 2012-11-13 00:39:24 - /usr/bin/make -B buildkernel KERNCONF=XBOX >>> Kernel build for XBOX started on Tue Nov 13 00:39:24 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for XBOX completed on Tue Nov 13 00:42:32 UTC 2012 TB --- 2012-11-13 00:42:32 - cd /src/sys/i386/conf TB --- 2012-11-13 00:42:32 - /usr/sbin/config -m XEN TB --- 2012-11-13 00:42:32 - building XEN kernel TB --- 2012-11-13 00:42:32 - CROSS_BUILD_TESTING=YES TB --- 2012-11-13 00:42:32 - MAKEOBJDIRPREFIX=/obj TB --- 2012-11-13 00:42:32 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-11-13 00:42:32 - SRCCONF=/dev/null TB --- 2012-11-13 00:42:32 - TARGET=i386 TB --- 2012-11-13 00:42:32 - TARGET_ARCH=i386 TB --- 2012-11-13 00:42:32 - TZ=UTC TB --- 2012-11-13 00:42:32 - __MAKE_CONF=/dev/null TB --- 2012-11-13 00:42:32 - cd /src TB --- 2012-11-13 00:42:32 - /usr/bin/make -B buildkernel KERNCONF=XEN >>> Kernel build for XEN started on Tue Nov 13 00:42:32 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mno-aes -mno-avx -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/i386/xen/clock.c /src/sys/i386/xen/clock.c:519:2: error: expression result unused [-Werror,-Wunused-value] do_div(__cpu_khz, info->tsc_to_system_mul); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /src/sys/i386/xen/clock.c:153:9: note: expanded from macro 'do_div' __mod; \ ^~~~~ 1 error generated. *** [clock.o] Error code 1 Stop in /obj/i386.i386/src/sys/XEN. *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-11-13 00:49:38 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-11-13 00:49:38 - ERROR: failed to build XEN kernel TB --- 2012-11-13 00:49:38 - 15985.05 user 2945.09 system 22177.66 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Tue Nov 13 02:27:09 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F15E2AB6 for ; Tue, 13 Nov 2012 02:27:09 +0000 (UTC) (envelope-from dan@dan.emsphone.com) Received: from email2.allantgroup.com (email2.emsphone.com [199.67.51.116]) by mx1.freebsd.org (Postfix) with ESMTP id 964C68FC16 for ; Tue, 13 Nov 2012 02:27:09 +0000 (UTC) Received: from dan.emsphone.com (dan.emsphone.com [172.17.17.101]) by email2.allantgroup.com (8.14.5/8.14.5) with ESMTP id qAD2NJ94044132 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 Nov 2012 20:23:19 -0600 (CST) (envelope-from dan@dan.emsphone.com) Received: from dan.emsphone.com (smmsp@localhost [127.0.0.1]) by dan.emsphone.com (8.14.5/8.14.5) with ESMTP id qAD2NIx3074964 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 Nov 2012 20:23:19 -0600 (CST) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.14.5/8.14.5/Submit) id qAD2NIKQ074963; Mon, 12 Nov 2012 20:23:18 -0600 (CST) (envelope-from dan) Date: Mon, 12 Nov 2012 20:23:18 -0600 From: Dan Nelson To: Darrel Subject: Re: Too many dynamic rules Message-ID: <20121113022318.GE20857@dan.emsphone.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-OS: FreeBSD 8.3-STABLE User-Agent: Mutt/1.5.21 (2010-09-15) X-Virus-Scanned: clamav-milter 0.97.6 at email2.allantgroup.com X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (email2.allantgroup.com [172.17.19.78]); Mon, 12 Nov 2012 20:23:19 -0600 (CST) X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00, RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on email2.allantgroup.com X-Scanned-By: MIMEDefang 2.73 Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 02:27:10 -0000 In the last episode (Nov 12), Darrel said: > Hello, > > Today I booted r242670 from the console and noticed an error. This > is one line from the end of dmesg: > > ipfw: ipfw_install_state: Too many dynamic rules > > The ruleset has always been dynamic and has no additional rules. > Search engines produced similar error messages, but no information > that seems to be the correct solution. > > I have a basically identical ruleset on fbsd91 and no error message. That means that the dynamic rules generated by the keep-state keyword hit the currently-confgured limit. If you get hit with a lot of random traffic that matches a keep-state rule, you'll get that message. It's not the rules themselves that cause this, it's the traffic. Run "sysctl net.inet.ip.fw.dyn_max net.inet.ip.fw.dyn_count" and compare the two values. If count is near to dyn_max, you can simply raise dyn_max. It's a writeable sysctl. I set it to 65535 on my systems in /etc/sysctl.conf with no apparent ill effects. -- Dan Nelson dnelson@allantgroup.com From owner-freebsd-current@FreeBSD.ORG Tue Nov 13 07:11:27 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D2E47A07 for ; Tue, 13 Nov 2012 07:11:27 +0000 (UTC) (envelope-from yerenkow@gmail.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 9368D8FC14 for ; Tue, 13 Nov 2012 07:11:27 +0000 (UTC) Received: by mail-ob0-f182.google.com with SMTP id 16so1422990obc.13 for ; Mon, 12 Nov 2012 23:11:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=IMDFK6ot2vjxFVrkM4WRJpXTG+IlUH0tBb0mbKtORwE=; b=PZJfVLRXXyUH1xBv10FBlh3wz80YLpP93MWDIFEoK0ae27tOvsKNDiuBld/6B24XR+ /IE/tGfhR9JYpkrCuP6F6WZTvW8f+rRv1a1RfZKIPwL71jtwkAySmNn5J64kMaWgtXsK nRvVlDpQzeg9ip3JE3qBm7U+05+1kcM5sXwAGiuiX37NLM1teeHwsIzogtfcoXURMMP2 k53skNguZgD+WPueV31COF6rYAc9MTgneLls5axrOcpdIv83Ud2y5Idg5O7ddriDoSsW 8CdJfaxx0m5z7zjdCY/urB6izbvHSCwsOmsrsQ+5XCQiCFVMz+/+3L4jgdsKifznHBBh qt1g== MIME-Version: 1.0 Received: by 10.182.156.99 with SMTP id wd3mr17498052obb.15.1352790681744; Mon, 12 Nov 2012 23:11:21 -0800 (PST) Received: by 10.60.58.165 with HTTP; Mon, 12 Nov 2012 23:11:21 -0800 (PST) Date: Tue, 13 Nov 2012 09:11:21 +0200 Message-ID: Subject: Simple check if current is broken From: Alexander Yerenkow To: freebsd-current Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 07:11:27 -0000 Hello there! I sometimes see in this list such mails: "I got problem with rXXXXXX" "It's known, it's fixed in rYYYYYY". Sometimes it's my problem, sometimes it's problem of other peoples. How about make simple web-service where revision numbers could be "marked" as bwoken, with minimal info - like next working rev? Can we make small sub-task while buildworld/buildkernel going, to simply fetch info about current rev and if it's broken warn user? This probably would improve user experience for those who use current, but have no time/proficiency to read commit logs. Thanks. -- Regards, Alexander Yerenkow From owner-freebsd-current@FreeBSD.ORG Tue Nov 13 10:38:03 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0126F203; Tue, 13 Nov 2012 10:38:02 +0000 (UTC) (envelope-from Devin.Teske@fisglobal.com) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) by mx1.freebsd.org (Postfix) with ESMTP id B88CF8FC08; Tue, 13 Nov 2012 10:38:02 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.31]) by ltcfislmsgpa02.fnfis.com (8.14.5/8.14.5) with ESMTP id qADAbsfS032613 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 13 Nov 2012 04:37:54 -0600 Received: from [10.0.0.103] (10.14.152.61) by smtp.fisglobal.com (10.132.206.31) with Microsoft SMTP Server (TLS) id 14.2.309.2; Tue, 13 Nov 2012 04:37:53 -0600 Subject: Re: can't open '/boot/menusets.4th' MIME-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset="us-ascii" From: Devin Teske In-Reply-To: <20121112235029.GB1435@glenbarber.us> Date: Tue, 13 Nov 2012 02:37:51 -0800 Content-Transfer-Encoding: quoted-printable Message-ID: References: <20121112235029.GB1435@glenbarber.us> To: Darrel X-Mailer: Apple Mail (2.1283) X-Originating-IP: [10.14.152.61] X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.9.8185, 1.0.431, 0.0.0000 definitions=2012-11-13_03:2012-11-13,2012-11-13,1970-01-01 signatures=0 Cc: Glen Barber , current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Devin Teske List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 10:38:03 -0000 On Nov 12, 2012, at 3:50 PM, Glen Barber wrote: > On Mon, Nov 12, 2012 at 06:11:43PM -0500, Darrel wrote: >> Hello, >>=20 >> Today I booted r242670 from the console and noticed this error message: >> can't open '/boot/menusets.4th': no such file of directory >>=20 >> Error while including /boot/menu-commands.4th, in the line >> include /boot/menusets.4th >>=20 >> Error while including /boot/menu.rc, in the line >> include /boot/menu-commands.4th >>=20 >> Anyone seen this before? >>=20 >=20 > Yes. This is fixed a few hours after it was introduced. >=20 and a few moments (minutes) after the fix, I sent an e-mail to -current war= ning everyone. --=20 Devin _____________ The information contained in this message is proprietary and/or confidentia= l. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any ma= nner; and (iii) notify the sender immediately. In addition, please be aware= that any message addressed to our domain is subject to archiving and revie= w by persons other than the intended recipient. Thank you. From owner-freebsd-current@FreeBSD.ORG Tue Nov 13 14:33:15 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D9A05389 for ; Tue, 13 Nov 2012 14:33:15 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) by mx1.freebsd.org (Postfix) with ESMTP id 83B0C8FC13 for ; Tue, 13 Nov 2012 14:33:14 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1TYHYG-0002zD-Ee for freebsd-current@freebsd.org; Tue, 13 Nov 2012 15:33:20 +0100 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 13 Nov 2012 15:33:20 +0100 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 13 Nov 2012 15:33:20 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Ivan Voras Subject: Re: Too many dynamic rules Date: Tue, 13 Nov 2012 15:33:02 +0100 Lines: 65 Message-ID: References: <20121113022318.GE20857@dan.emsphone.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigAF310259FFEEC93B3F92E424" X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:14.0) Gecko/20120812 Thunderbird/14.0 In-Reply-To: <20121113022318.GE20857@dan.emsphone.com> X-Enigmail-Version: 1.4.3 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 14:33:15 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigAF310259FFEEC93B3F92E424 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 13/11/2012 03:23, Dan Nelson wrote: > In the last episode (Nov 12), Darrel said: >> Hello, >> >> Today I booted r242670 from the console and noticed an error. This >> is one line from the end of dmesg: >> >> ipfw: ipfw_install_state: Too many dynamic rules >> >> The ruleset has always been dynamic and has no additional rules. >> Search engines produced similar error messages, but no information >> that seems to be the correct solution. >> >> I have a basically identical ruleset on fbsd91 and no error message. >=20 > That means that the dynamic rules generated by the keep-state keyword h= it > the currently-confgured limit. If you get hit with a lot of random tra= ffic > that matches a keep-state rule, you'll get that message. It's not the = rules > themselves that cause this, it's the traffic. >=20 > Run "sysctl net.inet.ip.fw.dyn_max net.inet.ip.fw.dyn_count" and compar= e the > two values. If count is near to dyn_max, you can simply raise dyn_max.= =20 > It's a writeable sysctl. I set it to 65535 on my systems in > /etc/sysctl.conf with no apparent ill effects. I have huge problems with the default settings, and I beat them down with the following: net.inet.ip.fw.dyn_max=3D8192 net.inet.ip.fw.dyn_buckets=3D1024 net.inet.ip.fw.dyn_ack_lifetime=3D60 net.inet.tcp.fast_finwait2_recycle=3D1 I also add these, though I don't think they help this particular problem:= net.inet.tcp.nolocaltimewait=3D1 net.inet.tcp.ecn.enable=3D1 --------------enigAF310259FFEEC93B3F92E424 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlCiWh4ACgkQ/QjVBj3/HSw0PwCgmnhA++xdPcKJo2OriIZVezT0 EGgAniXZHbwNHzWKUSss/eM4+BBBqEgO =4DcX -----END PGP SIGNATURE----- --------------enigAF310259FFEEC93B3F92E424-- From owner-freebsd-current@FreeBSD.ORG Tue Nov 13 15:54:45 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 75A3F508 for ; Tue, 13 Nov 2012 15:54:45 +0000 (UTC) (envelope-from levitch@iglou.com) Received: from rdsmtp.iglou.com (rdsmtp.iglou.com [192.107.41.63]) by mx1.freebsd.org (Postfix) with ESMTP id 2E1C28FC15 for ; Tue, 13 Nov 2012 15:54:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=iglou.com; s=alpha; h=Content-Type:MIME-Version:References:Message-ID:In-Reply-To:Subject:cc:To:From:Date; bh=mqoMInl5nQ3vcElYZZVIX4mQySzqFql0cxjUQ7x7sdo=; b=gmKFwaBrAcBPscSdqotj97dhwNJI/G4gjSfFhergaxGTOzqxWY8KMc0TSw4TpXUUxrU1y5h2SOT/B4JGnq/2mfprVxF9YUUv8ktDB8j5OxRCGZ4jT9ZO9SgDjB3MqBBsNAzdqGY29E7u+IVKnku3tfKf3IIzMvarpuu+2XJHaoA=; Received: from iglou3.iglou.com ([192.107.41.6]:57367 helo=mail.iglou.com) by rdsmtp.iglou.com with esmtpa (Exim MTA/8.19.3) (envelope-from ) id 1TYIp1-000339-UQ by authid with igloumta_auth for current@freebsd.org; Tue, 13 Nov 2012 10:54:43 -0500 Received: from shell1.iglou.com ([192.107.41.17]:49013 helo=shell1) by mail.iglou.com with esmtps (TLS cipher TLSv1:AES256-SHA:256) (Exim MTA/8.19.3) (envelope-from ) id 1TYIp1-0003tD-H1; Tue, 13 Nov 2012 10:54:43 -0500 Date: Tue, 13 Nov 2012 10:54:43 -0500 (EST) From: Darrel X-X-Sender: levitch@shell1 To: Dan Nelson Subject: [ solved ]: Too many dynamic rules In-Reply-To: <20121113022318.GE20857@dan.emsphone.com> Message-ID: References: <20121113022318.GE20857@dan.emsphone.com> User-Agent: Alpine 2.00 (GSO 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Originating-IP: 192.107.41.17 X-IgLou-Customer: 3cb6f76205bd20f518810676a67a982b X-Mailman-Approved-At: Tue, 13 Nov 2012 17:20:19 +0000 Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 15:54:45 -0000 >> Today I booted r242670 from the console and noticed an error. This >> is one line from the end of dmesg: >> >> ipfw: ipfw_install_state: Too many dynamic rules >> >> The ruleset has always been dynamic and has no additional rules. >> Search engines produced similar error messages, but no information >> that seems to be the correct solution. >> >> I have a basically identical ruleset on fbsd91 and no error message. > > That means that the dynamic rules generated by the keep-state keyword hit > the currently-confgured limit. If you get hit with a lot of random traffic > that matches a keep-state rule, you'll get that message. It's not the rules > themselves that cause this, it's the traffic. > That makes sense. Recently I began to run an ntp server there. > Run "sysctl net.inet.ip.fw.dyn_max net.inet.ip.fw.dyn_count" and compare the > two values. If count is near to dyn_max, you can simply raise dyn_max. > It's a writeable sysctl. I set it to 65535 on my systems in > /etc/sysctl.conf with no apparent ill effects. > This is just an internal server, so at first will try an increment: net.inet.ip.fw.dyn_max=16384 Thank you, Darrel From owner-freebsd-current@FreeBSD.ORG Tue Nov 13 20:15:31 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AEF11E51 for ; Tue, 13 Nov 2012 20:15:31 +0000 (UTC) (envelope-from jakub_lach@mailplus.pl) Received: from sam.nabble.com (sam.nabble.com [216.139.236.26]) by mx1.freebsd.org (Postfix) with ESMTP id 83D958FC0C for ; Tue, 13 Nov 2012 20:15:30 +0000 (UTC) Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1TYMtN-000795-Mn for freebsd-current@freebsd.org; Tue, 13 Nov 2012 12:15:29 -0800 Date: Tue, 13 Nov 2012 12:15:29 -0800 (PST) From: Jakub Lach To: freebsd-current@freebsd.org Message-ID: <1352837729700-5760700.post@n5.nabble.com> In-Reply-To: References: Subject: Re: Simple check if current is broken MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 20:15:31 -0000 What about cases when something is broken, but not for everybody? If only GENERIC build, how does that differ from existing tinderboxing? -- View this message in context: http://freebsd.1045724.n5.nabble.com/Simple-check-if-current-is-broken-tp5760481p5760700.html Sent from the freebsd-current mailing list archive at Nabble.com. From owner-freebsd-current@FreeBSD.ORG Tue Nov 13 21:17:11 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 86878BCA for ; Tue, 13 Nov 2012 21:17:11 +0000 (UTC) (envelope-from grog@lemis.com) Received: from w3.lemis.com (w3.lemis.com [208.86.224.149]) by mx1.freebsd.org (Postfix) with ESMTP id 49FD88FC14 for ; Tue, 13 Nov 2012 21:17:10 +0000 (UTC) Received: from eureka.lemis.com (1032.x.rootbsd.net [208.86.224.149]) by w3.lemis.com (Postfix) with ESMTP id 80B133B751; Tue, 13 Nov 2012 21:17:08 +0000 (UTC) Received: by eureka.lemis.com (Postfix, from userid 1004) id 5A243F791A; Wed, 14 Nov 2012 08:17:07 +1100 (EST) Date: Wed, 14 Nov 2012 08:17:07 +1100 From: Greg 'groggy' Lehey To: Alexander Yerenkow , Jakub Lach Subject: Re: Simple check if current is broken Message-ID: <20121113211707.GG85693@eureka.lemis.com> References: <20121113132728.5F3632C00C8@ozlabs.org> <20121113132728.593B02C00D6@ozlabs.org> <1352837729700-5760700.post@n5.nabble.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="bFsKbPszpzYNtEU6" Content-Disposition: inline In-Reply-To: <20121113132728.5F3632C00C8@ozlabs.org> <20121113132728.593B02C00D6@ozlabs.org> <1352837729700-5760700.post@n5.nabble.com> User-Agent: Mutt/1.4.2.3i Organization: The FreeBSD Project Phone: +61-3-5346-1370 Mobile: +61-418-838-708 WWW-Home-Page: http://www.FreeBSD.org/ X-PGP-Fingerprint: 9A1B 8202 BCCE B846 F92F 09AC 22E6 F290 507A 4223 Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 21:17:11 -0000 --bFsKbPszpzYNtEU6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tuesday, 13 November 2012 at 9:11:21 +0200, Alexander Yerenkow wrote: > Hello there! > I sometimes see in this list such mails: > "I got problem with rXXXXXX" > "It's known, it's fixed in rYYYYYY". > > Sometimes it's my problem, sometimes it's problem of other peoples. > > How about make simple web-service where revision numbers could be "marked" > as bwoken, with minimal info - like next working rev? > > Can we make small sub-task while buildworld/buildkernel going, to simply > fetch info about current rev and if it's broken warn user? > > This probably would improve user experience for those who use current, but > have no time/proficiency to read commit logs. On Tuesday, 13 November 2012 at 12:15:29 -0800, Jakub Lach wrote: On Tuesday, 13 November 2012 at 12:15:29 -0800, Jakub Lach wrote: > What about cases when something is broken, but not for everybody? Just say so. > If only GENERIC build, how does that differ from existing > tinderboxing? It's all in one place. The idea sounds good to me. All we need is somebody to implement it and somebody to maintain it. Greg -- Sent from my desktop computer. Finger grog@FreeBSD.org for PGP public key. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft MUA reports problems, please read http://tinyurl.com/broken-mua --bFsKbPszpzYNtEU6 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlCiuNIACgkQIubykFB6QiMz6ACdFJpQ0GeL2gqrJpMK7Kf/DjXR wlgAoJ86LZm9GJPKvhSSYhG0N6Ishr1E =Oy4B -----END PGP SIGNATURE----- --bFsKbPszpzYNtEU6-- From owner-freebsd-current@FreeBSD.ORG Tue Nov 13 23:24:26 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 664) id E93593DE; Tue, 13 Nov 2012 23:24:26 +0000 (UTC) Date: Tue, 13 Nov 2012 15:24:26 -0800 From: David O'Brien To: Greg 'groggy' Lehey Subject: Re: Traditional cpp (was: /usr/bin/calendar broken on current) Message-ID: <20121113232426.GA12182@dragon.NUXI.org> Mail-Followup-To: obrien@freebsd.org, Greg 'groggy' Lehey , Dimitry Andric , freebsd-current@freebsd.org References: <201211090658.qA96whII081757@pozo.com> <20121109072631.GQ77848@eureka.lemis.com> <509CFC88.7050606@FreeBSD.org> <20121110064621.GA10902@eureka.lemis.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20121110064621.GA10902@eureka.lemis.com> X-Operating-System: FreeBSD 10.0-CURRENT X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-current@freebsd.org, Dimitry Andric X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: obrien@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 23:24:27 -0000 On Sat, Nov 10, 2012 at 05:46:21PM +1100, Greg 'groggy' Lehey wrote: > On Friday, 9 November 2012 at 13:52:24 +0100, Dimitry Andric wrote: > > Looks like yet another cpp -traditional abuse. > > Use or abuse? In any case, it's not the only one. In the Good Old > Days people did things like that. So, it seems, does imake, and I'm > sure others will come out of the woodwork. ... > > Clang will most likely never support traditional preprocessing. ... > What we really need is a traditional cpp. That's not difficult: > there's one in 4.3BSD (all 32 kB of source). OpenBSD also had one, > though it's gone now, so presumably that one has a clean license. > Both appear to be from pcc. Should we import it into the tree as, > say, tradcpp? There is also a public domain one in the X11R5 sources. And the well writen http://mcpp.sourceforge.net/ (BSD-style-licensed), with a test suite, etc.. See 'lmcpp-summary-272.pdf' there. -- -- David (obrien@FreeBSD.org) From owner-freebsd-current@FreeBSD.ORG Tue Nov 13 23:43:16 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2DC1967B; Tue, 13 Nov 2012 23:43:16 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 87CFB8FC14; Tue, 13 Nov 2012 23:43:15 +0000 (UTC) Received: by mail-we0-f182.google.com with SMTP id x43so4437685wey.13 for ; Tue, 13 Nov 2012 15:43:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:mail-followup-to:mime-version :content-type:content-disposition:user-agent; bh=SS6YCC8wut/5HMFksbnLDc/lSk9lfMFQiOPLUM24MKM=; b=Rso8Sq8O2qttx+FR0jNNascW2w9T6F7nsJ9YnP86CBzuSM6qqxf/9NPgDPLjnTQvFy kXoPyrDdypbXQDY9lVE0DufF7TDDP6Q5sdEBzk1ONrfg4otbPVzvsREj958ud/vWVRIB D55sV04B/hrngYlpVybTYh54zaU19piWnKQLlnS9FvednsDQ/RQYKBHFyTGvR7b6ZJyj cnU8kX+btxImxOSbltDkb958FHFkGZTZM/6P6nBuXIyvnznE+Ny23jP4zDdgTUDGdXWR AFYx3qcHPrIQXi4N0WdbDnWd3kCZ0+ldZxTQuv2Wazw4cGAHMWFPDY5dkumN+u/ZdWmX cGJw== Received: by 10.216.71.76 with SMTP id q54mr943024wed.171.1352850193649; Tue, 13 Nov 2012 15:43:13 -0800 (PST) Received: from dft-labs.eu (n1x0n-1-pt.tunnel.tserv5.lon1.ipv6.he.net. [2001:470:1f08:1f7::2]) by mx.google.com with ESMTPS id hv4sm20950173wib.0.2012.11.13.15.43.12 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 13 Nov 2012 15:43:12 -0800 (PST) Date: Wed, 14 Nov 2012 00:43:03 +0100 From: Mateusz Guzik To: freebsd-current@freebsd.org Subject: compiler info in kernel identification string Message-ID: <20121113234303.GA15319@dft-labs.eu> Mail-Followup-To: Mateusz Guzik , freebsd-current@freebsd.org, avg@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) Cc: avg@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 23:43:16 -0000 Hello, avg@ suggested to include compiler version in the kernel so that it's present in uname (and one can easly tell what was used to compile it). Here is my attempt: http://people.freebsd.org/~mjg/patches/newvers-compiler.diff Basically adds compiler name and version/revision after revision of system sources. Sample output from dirty git sources: gcc: FreeBSD 10.0-CURRENT #7 r242962=264d569-dirty(gcc-4.2.1-20070831): Wed Nov 14 00:11:51 CET 2012 clang: FreeBSD 10.0-CURRENT #8 r242962=264d569-dirty(clang-r162107): Wed Nov 14 00:12:26 CET 2012 Sample output from svn with gcc: FreeBSD 10.0-CURRENT #1 r243006:243007M(gcc-4.2.1-20070831): Wed Nov 14 00:41:23 CET 2012 I have no strong opinions on format, I just want this information easly accessible. Comments? -- Mateusz Guzik From owner-freebsd-current@FreeBSD.ORG Tue Nov 13 23:51:20 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 805C686D for ; Tue, 13 Nov 2012 23:51:20 +0000 (UTC) (envelope-from andy@neu.net) Received: from mail.neu.net (unknown [IPv6:2607:fc50:0:d300:216:3eff:fe54:f1c6]) by mx1.freebsd.org (Postfix) with ESMTP id 2B7B18FC13 for ; Tue, 13 Nov 2012 23:51:19 +0000 (UTC) Received: from neu.net (neu.net [199.48.129.194]) by mail.neu.net (8.14.5/8.14.5) with ESMTP id qADNpIIU028667 for ; Tue, 13 Nov 2012 18:51:18 -0500 (EST) (envelope-from andy@neu.net) Date: Tue, 13 Nov 2012 18:51:18 -0500 (EST) From: AN To: freebsd-current@freebsd.org Subject: -Current built with clang as default + ports In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Virus-Scanned: clamav-milter 0.97.6 at my.mail.server X-Virus-Status: Clean X-Spam-Status: No, score=0.0 required=4.5 tests=RP_MATCHES_RCVD autolearn=unavailable version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on mail.neu.net X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 23:51:20 -0000 Can anyone comment on current built with clang as default compiler and ports? Are there any major problems, programs that don't run? Specifically, I am interested in how Gnome and Xorg (Gnome and Xorg built with default system gcc) work on world built with clang. I believe the work around for ports that don't build with clang is to put USE_GCC=4.7+ in the port makefile, is this correct? Any comments would be appreciated, thanks in advance. From owner-freebsd-current@FreeBSD.ORG Tue Nov 13 23:57:56 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 934919FA for ; Tue, 13 Nov 2012 23:57:56 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (m209-73.dsl.rawbw.com [198.144.209.73]) by mx1.freebsd.org (Postfix) with ESMTP id 441018FC16 for ; Tue, 13 Nov 2012 23:57:56 +0000 (UTC) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.5/8.14.5) with ESMTP id qADNvtQF020193 for ; Tue, 13 Nov 2012 15:57:55 -0800 (PST) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.5/8.14.5/Submit) id qADNvtr9020192 for freebsd-current@freebsd.org; Tue, 13 Nov 2012 15:57:55 -0800 (PST) (envelope-from david) Date: Tue, 13 Nov 2012 15:57:55 -0800 From: David Wolfskill To: freebsd-current@freebsd.org Subject: Re: compiler info in kernel identification string Message-ID: <20121113235755.GE17755@albert.catwhisker.org> References: <20121113234303.GA15319@dft-labs.eu> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="WK3l2KTTmXPVedZ6" Content-Disposition: inline In-Reply-To: <20121113234303.GA15319@dft-labs.eu> User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: freebsd-current@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 23:57:56 -0000 --WK3l2KTTmXPVedZ6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Nov 14, 2012 at 12:43:03AM +0100, Mateusz Guzik wrote: > Hello, >=20 > avg@ suggested to include compiler version in the kernel so that it's > present in uname (and one can easly tell what was used to compile it). >=20 > Here is my attempt: > http://people.freebsd.org/~mjg/patches/newvers-compiler.diff >=20 > Basically adds compiler name and version/revision after revision of > system sources. >=20 > Sample output from dirty git sources: > gcc: > FreeBSD 10.0-CURRENT #7 r242962=3D264d569-dirty(gcc-4.2.1-20070831): Wed > Nov 14 00:11:51 CET 2012 >=20 > clang: > FreeBSD 10.0-CURRENT #8 r242962=3D264d569-dirty(clang-r162107): Wed Nov 14 > 00:12:26 CET 2012 > ...=20 > I have no strong opinions on format, I just want this information easly > accessible. >=20 > Comments? > .... I like the idea, but I have long found the idea of putting this type of logic (including VCS-awareness) in newvers.sh itself something that is prone to turn what should be a rather simple script into a ... mess. What I have been using for several months has been a modified newvers.sh that uses an externally-defined function (from a file that is sourced) to handle whatever VCS-specific things I think are appropriate. (Thus, folks who want to use one VCS don't need to have newvers.sh test for VCSen they don't use; they could also provide a sample file that provides the function. An installation could use a symlink to point to the function definition of choice.... We could even have a "kitchen sink" default, that goes through all the hoops & gyrations the current code does, if folks want that.) Extending that to define a function for compiler-awareness should be straightforward -- and (IMO) avoid cluttering newvers.sh even more. Caveat: I'm not a committer. I do exercise newvers.sh a bit more than many folks, though. :-} Peace, david --=20 David H. Wolfskill david@catwhisker.org Taliban: Evil men with guns afraid of truth from a 14-year old girl. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --WK3l2KTTmXPVedZ6 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlCi3oIACgkQmprOCmdXAD3nbgCfWxAmUDhS7NA9FBV28Y+pHtiN /owAnjamV2HgFFkseMZXFAbDJB35SU87 =3+kO -----END PGP SIGNATURE----- --WK3l2KTTmXPVedZ6-- From owner-freebsd-current@FreeBSD.ORG Tue Nov 13 23:58:15 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 84101AFD; Tue, 13 Nov 2012 23:58:15 +0000 (UTC) (envelope-from erichfreebsdlist@alogreentechnologies.com) Received: from alogreentechnologies.com (alogreentechnologies.com [67.212.224.110]) by mx1.freebsd.org (Postfix) with ESMTP id 291B38FC15; Tue, 13 Nov 2012 23:58:14 +0000 (UTC) Received: from X220.ovitrap.com ([122.129.203.50]) (authenticated bits=0) by alogreentechnologies.com (8.13.1/8.13.1) with ESMTP id qADNwAO3027786; Tue, 13 Nov 2012 16:58:11 -0700 Date: Wed, 14 Nov 2012 06:58:10 +0700 From: Erich Dollansky To: Mateusz Guzik Subject: Re: compiler info in kernel identification string Message-ID: <20121114065810.1ace6c60@X220.ovitrap.com> In-Reply-To: <20121113234303.GA15319@dft-labs.eu> References: <20121113234303.GA15319@dft-labs.eu> X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.6; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, avg@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 23:58:15 -0000 Hi, On Wed, 14 Nov 2012 00:43:03 +0100 Mateusz Guzik wrote: > Hello, > > avg@ suggested to include compiler version in the kernel so that it's > present in uname (and one can easly tell what was used to compile it). > > Here is my attempt: > http://people.freebsd.org/~mjg/patches/newvers-compiler.diff > > Basically adds compiler name and version/revision after revision of > system sources. > > Sample output from dirty git sources: > gcc: > FreeBSD 10.0-CURRENT #7 r242962=264d569-dirty(gcc-4.2.1-20070831): Wed > Nov 14 00:11:51 CET 2012 > > clang: > FreeBSD 10.0-CURRENT #8 r242962=264d569-dirty(clang-r162107): Wed Nov > 14 00:12:26 CET 2012 > > Sample output from svn with gcc: > FreeBSD 10.0-CURRENT #1 r243006:243007M(gcc-4.2.1-20070831): Wed Nov > 14 00:41:23 CET 2012 > > I have no strong opinions on format, I just want this information > easly accessible. > > Comments? > this is a good idea! Erich From owner-freebsd-current@FreeBSD.ORG Wed Nov 14 00:14:15 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0A3B1F0E; Wed, 14 Nov 2012 00:14:15 +0000 (UTC) (envelope-from zhao6014@gmail.com) Received: from mail-vb0-f54.google.com (mail-vb0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 8F77F8FC14; Wed, 14 Nov 2012 00:14:14 +0000 (UTC) Received: by mail-vb0-f54.google.com with SMTP id l1so10520459vba.13 for ; Tue, 13 Nov 2012 16:14:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=7yldNng4av+ghtznZ0cXEq1zCRjOViOm+t+A5Vt3WkY=; b=lfAGsFpgzhY1qsOOBw6cI1CoMZ92xsot875na//nqHRnzABc9ip0OZX5+B040BgLoi Z47iolSKcUyt3NC4kOepi51VRVBUixkORDcexogz63602zxCazDiA2GmWkdFZyHi5Ecr jmHvVhG8K7zG7xCKX41gqHYHmqAjqeMqyVK9bQ+FY1vaOEb0ic+hmuAKwiI9qgI9Rdm/ pldlfZ7P9RDWdHmzxEJKu1Xhc15RiG2pcoJIPllWzlgya4tVYJs7FCBbkMrhxQRTTxBI 36HGRPdud60PcMtrgPdnqLv+nraVkKpjRMxFmYsv5VosMBJjoVPdAiGIsM2Fdj2tRZEN GB1A== MIME-Version: 1.0 Received: by 10.52.72.42 with SMTP id a10mr107608vdv.48.1352852048409; Tue, 13 Nov 2012 16:14:08 -0800 (PST) Received: by 10.58.208.134 with HTTP; Tue, 13 Nov 2012 16:14:08 -0800 (PST) Received: by 10.58.208.134 with HTTP; Tue, 13 Nov 2012 16:14:08 -0800 (PST) In-Reply-To: <20121113234303.GA15319@dft-labs.eu> References: <20121113234303.GA15319@dft-labs.eu> Date: Wed, 14 Nov 2012 08:14:08 +0800 Message-ID: Subject: Re: compiler info in kernel identification string From: Jov To: freebsd-current@freebsd.org, avg@freebsd.org, Mateusz Guzik Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 00:14:15 -0000 good idea. show version cmd in postgresql prints os version,compiler info etc. useful for problem report. jov =D4=DA 2012-11-14 =C9=CF=CE=E77:43=A3=AC"Mateusz Guzik" = =D0=B4=B5=C0=A3=BA > Hello, > > avg@ suggested to include compiler version in the kernel so that it's > present in uname (and one can easly tell what was used to compile it). > > Here is my attempt: > http://people.freebsd.org/~mjg/patches/newvers-compiler.diff > > Basically adds compiler name and version/revision after revision of > system sources. > > Sample output from dirty git sources: > gcc: > FreeBSD 10.0-CURRENT #7 r242962=3D264d569-dirty(gcc-4.2.1-20070831): Wed > Nov 14 00:11:51 CET 2012 > > clang: > FreeBSD 10.0-CURRENT #8 r242962=3D264d569-dirty(clang-r162107): Wed Nov 1= 4 > 00:12:26 CET 2012 > > Sample output from svn with gcc: > FreeBSD 10.0-CURRENT #1 r243006:243007M(gcc-4.2.1-20070831): Wed Nov 14 > 00:41:23 CET 2012 > > I have no strong opinions on format, I just want this information easly > accessible. > > Comments? > > -- > Mateusz Guzik > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " > From owner-freebsd-current@FreeBSD.ORG Wed Nov 14 02:10:21 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5DA86209; Wed, 14 Nov 2012 02:10:21 +0000 (UTC) (envelope-from bright@mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 3150F8FC12; Wed, 14 Nov 2012 02:10:20 +0000 (UTC) Received: from kruse-124.4.ixsystems.com (drawbridge.ixsystems.com [206.40.55.65]) by elvis.mu.org (Postfix) with ESMTPSA id B72071A3C1A; Tue, 13 Nov 2012 18:10:19 -0800 (PST) Message-ID: <50A2FDAC.6080903@mu.org> Date: Tue, 13 Nov 2012 18:10:52 -0800 From: Alfred Perlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Andre Oppermann Subject: Re: svn commit: r242910 - in user/andre/tcp_workqueue/sys: kern sys References: <201211120847.qAC8lEAM086331@svn.freebsd.org> <50A0D420.4030106@freebsd.org> In-Reply-To: <50A0D420.4030106@freebsd.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 02:10:21 -0000 Andre, do you think the variable "realmem" could be exported as something like kmemsize or something? Or maybe a function call to subr_param.c? The reason I ask is that I would like to scale things like number of default sysv semaphores to something like 64 per 1GB of "realmem". Thoughts? The reason I'm interested in this is because we just had a user run out of sysvsems on a machine with 256GB ram. -Alfred On 11/12/12 2:49 AM, Andre Oppermann wrote: > On 12.11.2012 09:47, Andre Oppermann wrote: >> Author: andre >> Date: Mon Nov 12 08:47:13 2012 >> New Revision: 242910 >> URL: http://svnweb.freebsd.org/changeset/base/242910 >> >> Log: >> Base the mbuf related limits on the available physical memory or >> kernel memory, whichever is lower. > > The commit message is a bit terse so I'm going to explain in more > detail: > > The overall mbuf related memory limit must be set so that mbufs > (and clusters of various sizes) can't exhaust physical RAM or KVM. > > I've chosen a limit of half the physical RAM or KVM (whichever is > lower) as the baseline. In any normal scenario we want to leave > at least half of the physmem/kvm for other kernel functions and > userspace to prevent it from swapping like hell. Via a tunable > it can be upped to at most 3/4 of physmem/kvm. > > Out of the overall mbuf memory limit I've chosen 2K clusters, 4K > (page size) clusters to get 1/4 each because these are the most > heavily used mbuf sizes. 2K clusters are used for MTU 1500 ethernet > inbound packets. 4K clusters are used whenever possible for sends > on sockets and thus outbound packets. > > The larger cluster sizes of 9K and 16K are limited to 1/6 of the > overall mbuf memory limit. Again, when jumbo MTU's are used these > large clusters will end up only on the inbound path. They are not > used on outbound, there it's still 4K. Yes, that will stay that > way because otherwise we run into lots of complications in the > stack. And it really isn't a problem, so don't make a scene. > > Previously the normal mbufs (256B) weren't limited at all. This > is wrong as there are certain places in the kernel that on allocation > failure of clusters try to piece together their packet from smaller > mbufs. The mbuf limit is the number of all other mbuf sizes together > plus some more to allow for standalone mbufs (ACK for example) and > to send off a copy of a cluster. FYI: Every cluster eventually also > has an mbuf associated with it. > > Unfortunately there isn't a way to set an overall limit for all > mbuf memory together as UMA doesn't support such a limiting. > > Lets work out a few examples on sizing: > > 1GB KVM: > 512MB limit for mbufs > 419,430 mbufs > 65,536 2K mbuf clusters > 32,768 4K mbuf clusters > 9,709 9K mbuf clusters > 5,461 16K mbuf clusters > > 16GB RAM: > 8GB limit for mbufs > 33,554,432 mbufs > 1,048,576 2K mbuf clusters > 524,288 4K mbuf clusters > 155,344 9K mbuf clusters > 87,381 16K mbuf clusters > > These defaults should be sufficient for event the most demanding > network loads. If you do run into these limits you probably know > exactly what you are doing and you are expected to tune those > values for your particular purpose. > > There is a side-issue with maxfiles as it relates to the maximum > number of sockets that can be opened at the same time. With web > servers and proxy caches of these days there may be some 100K or > more sockets open. Hence I've divorced maxfiles from maxusers as > well. There is a relationship of maxfiles with the callout callwheel > though which has to be investigated some more to prevent ridiculous > values from being chosen. > From owner-freebsd-current@FreeBSD.ORG Wed Nov 14 07:02:04 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2A21CF71; Wed, 14 Nov 2012 07:02:04 +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 C22218FC16; Wed, 14 Nov 2012 07:02:03 +0000 (UTC) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1TYWyx-0003b5-CF; Wed, 14 Nov 2012 09:01:55 +0200 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.3 To: Mateusz Guzik , freebsd-current@freebsd.org, avg@freebsd.org Subject: Re: compiler info in kernel identification string In-reply-to: <20121113234303.GA15319@dft-labs.eu> References: <20121113234303.GA15319@dft-labs.eu> Comments: In-reply-to Mateusz Guzik message dated "Wed, 14 Nov 2012 00:43:03 +0100." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 14 Nov 2012 09:01:55 +0200 From: Daniel Braniss Message-ID: X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 07:02:04 -0000 > Hello, > > avg@ suggested to include compiler version in the kernel so that it's > present in uname (and one can easly tell what was used to compile it). > > Here is my attempt: > http://people.freebsd.org/~mjg/patches/newvers-compiler.diff > > Basically adds compiler name and version/revision after revision of > system sources. > > Sample output from dirty git sources: > gcc: > FreeBSD 10.0-CURRENT #7 r242962=264d569-dirty(gcc-4.2.1-20070831): Wed > Nov 14 00:11:51 CET 2012 > > clang: > FreeBSD 10.0-CURRENT #8 r242962=264d569-dirty(clang-r162107): Wed Nov 14 > 00:12:26 CET 2012 > > Sample output from svn with gcc: > FreeBSD 10.0-CURRENT #1 r243006:243007M(gcc-4.2.1-20070831): Wed Nov 14 > 00:41:23 CET 2012 > > I have no strong opinions on format, I just want this information easly > accessible. > > Comments? in the old days (I'm talking before C :-) I remmeber one compiler putting such info in the code it produced, I wonder if that's the case with gcc/clang, and if so it would be nice if file(1) could show it. my 3c, danny From owner-freebsd-current@FreeBSD.ORG Wed Nov 14 09:25:49 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F3B44CBB; Wed, 14 Nov 2012 09:25:48 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id AD9028FC18; Wed, 14 Nov 2012 09:25:48 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:89d9:d735:1f7a:92e6] (unknown [IPv6:2001:7b8:3a7:0:89d9:d735:1f7a:92e6]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 244EE5C59; Wed, 14 Nov 2012 10:25:46 +0100 (CET) Message-ID: <50A3639C.9050200@FreeBSD.org> Date: Wed, 14 Nov 2012 10:25:48 +0100 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Mateusz Guzik , freebsd-current@freebsd.org, avg@freebsd.org Subject: Re: compiler info in kernel identification string References: <20121113234303.GA15319@dft-labs.eu> In-Reply-To: <20121113234303.GA15319@dft-labs.eu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 09:25:49 -0000 On 2012-11-14 00:43, Mateusz Guzik wrote: > avg@ suggested to include compiler version in the kernel so that it's > present in uname (and one can easly tell what was used to compile it). > > Here is my attempt: > http://people.freebsd.org/~mjg/patches/newvers-compiler.diff > > Basically adds compiler name and version/revision after revision of > system sources. > > Sample output from dirty git sources: > gcc: > FreeBSD 10.0-CURRENT #7 r242962=264d569-dirty(gcc-4.2.1-20070831): Wed > Nov 14 00:11:51 CET 2012 > > clang: > FreeBSD 10.0-CURRENT #8 r242962=264d569-dirty(clang-r162107): Wed Nov 14 > 00:12:26 CET 2012 > > Sample output from svn with gcc: > FreeBSD 10.0-CURRENT #1 r243006:243007M(gcc-4.2.1-20070831): Wed Nov 14 > 00:41:23 CET 2012 > > I have no strong opinions on format, I just want this information easly > accessible. Yes, this is handy to have. Note that gcc already puts an id string into each object file it produces, but sometimes during linking, these can be stripped out... Regarding the format, I don't see the necessity of parsing the version information, which will always be very fragile. Just include the complete version string in the compiler identification, similar to what Linux does, e.g. on a CentOS box: $ gcc -v 2>&1 | grep 'version ' gcc version 4.4.6 20120305 (Red Hat 4.4.6-4) (GCC) $ dmesg | grep 'gcc version ' Linux version 2.6.32-279.2.1.el6.x86_64 (mockbuild@c6b7.bsys.dev.centos.org) (gcc version 4.4.6 20120305 (Red Hat 4.4.6-4) (GCC) ) #1 SMP Fri Jul 20 01:55:29 UTC 2012 That way, you are sure never to lose information. This also works for gcc from ports (which is the reason for the space after 'version' in the grep command): $ gcc47 -v 2>&1 | grep 'version ' gcc version 4.7.3 20120929 (prerelease) (FreeBSD Ports Collection) I realize this is a bit long, but it is better to have complete than stripped information. From owner-freebsd-current@FreeBSD.ORG Wed Nov 14 09:37:53 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2C8BE475 for ; Wed, 14 Nov 2012 09:37:53 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 8198C8FC1B for ; Wed, 14 Nov 2012 09:37:52 +0000 (UTC) Received: (qmail 30236 invoked from network); 14 Nov 2012 11:11:54 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 14 Nov 2012 11:11:54 -0000 Message-ID: <50A36669.4000905@freebsd.org> Date: Wed, 14 Nov 2012 10:37:45 +0100 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Alfred Perlstein Subject: Re: svn commit: r242910 - in user/andre/tcp_workqueue/sys: kern sys References: <201211120847.qAC8lEAM086331@svn.freebsd.org> <50A0D420.4030106@freebsd.org> <50A2FDAC.6080903@mu.org> In-Reply-To: <50A2FDAC.6080903@mu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 09:37:53 -0000 On 14.11.2012 03:10, Alfred Perlstein wrote: > Andre, do you think the variable "realmem" could be exported as something like kmemsize or something? > > Or maybe a function call to subr_param.c? > > The reason I ask is that I would like to scale things like number of default sysv semaphores to > something like 64 per 1GB of "realmem". > > Thoughts? Yes, let me see whether there is a better name for it. -- Andre > The reason I'm interested in this is because we just had a user run out of sysvsems on a machine > with 256GB ram. > > -Alfred From owner-freebsd-current@FreeBSD.ORG Wed Nov 14 09:42:17 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 33D935C4; Wed, 14 Nov 2012 09:42:17 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id DD96C8FC08; Wed, 14 Nov 2012 09:42:16 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:89d9:d735:1f7a:92e6] (unknown [IPv6:2001:7b8:3a7:0:89d9:d735:1f7a:92e6]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 2708C5C59; Wed, 14 Nov 2012 10:42:16 +0100 (CET) Message-ID: <50A3677A.2030200@FreeBSD.org> Date: Wed, 14 Nov 2012 10:42:18 +0100 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Daniel Braniss Subject: Re: compiler info in kernel identification string References: <20121113234303.GA15319@dft-labs.eu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Mateusz Guzik , avg@freebsd.org, freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 09:42:17 -0000 On 2012-11-14 08:01, Daniel Braniss wrote: > in the old days (I'm talking before C :-) I remmeber one compiler > putting such info in the code it produced, I wonder if that's the case > with gcc/clang, and if so it would be nice if file(1) could show it. > my 3c, As far as I know, gcc has always included such information: $ touch empty.c $ gcc -c empty.c $ objdump -j .comment -s empty.o empty.o: file format elf32-i386-freebsd Contents of section .comment: 0000 00474343 3a202847 4e552920 342e322e .GCC: (GNU) 4.2. 0010 31203230 30373038 33312070 61746368 1 20070831 patch 0020 6564205b 46726565 4253445d 00 ed [FreeBSD]. $ gcc47 -c empty.c $ objdump -j .comment -s empty.o empty.o: file format elf32-i386-freebsd Contents of section .comment: 0000 00474343 3a202846 72656542 53442050 .GCC: (FreeBSD P 0010 6f727473 20436f6c 6c656374 696f6e29 orts Collection) 0020 20342e37 2e332032 30313230 39323920 4.7.3 20120929 0030 28707265 72656c65 61736529 00 (prerelease). There is an old LLVM PR to get the same supported for clang, but it ended up at the bottom of the pile: http://llvm.org/bugs/show_bug.cgi?id=7292 I should probably just make a patch for it, and submit it. :-) From owner-freebsd-current@FreeBSD.ORG Wed Nov 14 09:59:55 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4E080958 for ; Wed, 14 Nov 2012 09:59:55 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) by mx1.freebsd.org (Postfix) with ESMTP id 050918FC1B for ; Wed, 14 Nov 2012 09:59:54 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:89d9:d735:1f7a:92e6] (unknown [IPv6:2001:7b8:3a7:0:89d9:d735:1f7a:92e6]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 51A705C5A; Wed, 14 Nov 2012 10:59:48 +0100 (CET) Message-ID: <50A36B95.4060901@FreeBSD.org> Date: Wed, 14 Nov 2012 10:59:49 +0100 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: AN Subject: Re: -Current built with clang as default + ports References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 09:59:55 -0000 On 2012-11-14 00:51, AN wrote: > Can anyone comment on current built with clang as default compiler and > ports? Are there any major problems, programs that don't run? There are some ports that don't compile, and obviously there will be a few that do compile, but fail to run correctly. Diagnosing the causes is always an interesting venture, you encounter the most diverse problems. See https://wiki.freebsd.org/PortsAndClang for an overview, though some of the instructions are outdated, now clang is the default compiler. Of special interest are the results from the build cluster, where you can get a quick overview of which ports don't build, and how many other ports depend on them. > Specifically, I am > interested in how Gnome and Xorg (Gnome and Xorg built with default > system gcc) work on world built with clang. I don't use Gnome, but Xorg builds just fine with clang, and runs without problems for me. Regarding Gnome, and/or other big frameworks, it is probably best to ask around on the freebsd-ports mailing list, though. > I believe the work around for ports that don't build with clang is to put > USE_GCC=4.7+ in the port makefile, is this correct? Any comments would be > appreciated, thanks in advance. That depends, if the port is easy to fix (borked configure scripts are VERY common), then just fix it. Only if the port is extremely tightly coupled to gcc, or even a very specific gcc version, then use USE_GCC. From owner-freebsd-current@FreeBSD.ORG Wed Nov 14 10:31:16 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B1B273C3 for ; Wed, 14 Nov 2012 10:31:16 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 1942C8FC15 for ; Wed, 14 Nov 2012 10:31:15 +0000 (UTC) Received: (qmail 30477 invoked from network); 14 Nov 2012 12:05:17 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 14 Nov 2012 12:05:17 -0000 Message-ID: <50A372EC.5080002@freebsd.org> Date: Wed, 14 Nov 2012 11:31:08 +0100 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Looking for bge(4) , bce(4) and igb(4) cards Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: andre@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 10:31:16 -0000 Hello I currently working on a number of drivers for popular network cards and extend them with automatic hybrid interrupt/polling ithread processing with life-lock prevention (so that the driver can't consume all CPU when under heavy load or attack). To properly test this I need the proper hardware as PCIe network cards: bge(4) Broadcom BCM57xx/BCM590x bce(4) Broadcom NetXtreme II (BCM5706/5708/5709/5716) igb(4) Intel PRO/1000 i82575, i82576, i82580, i210, i350 If you have one of these and can spare it I'd be very glad if you could send it to me. I'm located in Switzerland/Europe. I can reply to you privately to give you my shipping address. Of course if you have any other PCIe Gigabit Ethernet cards with a driver in FreeBSD I'm interested in receiving one as well. Of particular interest are: em(4) Intel i82571 to i82573 lem(4) Intel i82540 to i82546 age(4) Atheros L1 GigE ??? anything else 1GigE with PCIe The same goes for 10 Gigabit Ethernet but the setup is a bit more involved and I haven't done that yet, but will do soon (the issue being expensive SPF+ optics): bxe(4) Broadcom BCM5771x 10GigE cxbge(4) Chelsio T4 10GigE ixgbe(4) Intel i82598 and i82599 10GigE mxge(4) Myricom Myri10G qlxgb(4) QLogic 3200 and 8200 10GigE sfxge(4) Solarflare Many thanks for your support! -- Andre From owner-freebsd-current@FreeBSD.ORG Wed Nov 14 11:10:42 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E7EE99C3; Wed, 14 Nov 2012 11:10:42 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id E17BC8FC15; Wed, 14 Nov 2012 11:10:41 +0000 (UTC) Received: from porto.starpoint.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 NAA20891; Wed, 14 Nov 2012 13:10:39 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1TYarf-000K2e-Go; Wed, 14 Nov 2012 13:10:39 +0200 Message-ID: <50A37C2D.9010607@FreeBSD.org> Date: Wed, 14 Nov 2012 13:10:37 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:16.0) Gecko/20121030 Thunderbird/16.0.2 MIME-Version: 1.0 To: Palle Girgensohn , Christoph Hoffmann , Daniel Kalchev , Bjorn Larsson Subject: Re: gptzfsboot error using HP Smart Array P410i Controller References: <9B96176A-7550-4B60-8F4D-0B667EEF7A15@me.com> <201108161515.50127.jhb@freebsd.org> <23B6937F-F261-4DC4-9168-96720251C98D@me.com> <4E502F2F.50209@FreeBSD.org> <9FAB808F-E5D4-4B93-9D5F-BAE025930273@me.com> <4E944197.7050803@digsys.bg> <4F4FECA4.10504@FreeBSD.org> In-Reply-To: <4F4FECA4.10504@FreeBSD.org> X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 11:10:43 -0000 Guys, if you still have the hardware and use FreeBSD, could you please try r243025? http://svnweb.freebsd.org/base?view=revision&revision=243025 -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Wed Nov 14 11:15:03 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id ECC60B43 for ; Wed, 14 Nov 2012 11:15:03 +0000 (UTC) (envelope-from rainer@ultra-secure.de) Received: from mail.ultra-secure.de (mail.ultra-secure.de [78.47.114.122]) by mx1.freebsd.org (Postfix) with ESMTP id 303058FC12 for ; Wed, 14 Nov 2012 11:15:02 +0000 (UTC) Received: (qmail 65296 invoked by uid 89); 14 Nov 2012 11:13:58 -0000 Received: by simscan 1.4.0 ppid: 65291, pid: 65293, t: 0.0366s scanners: attach: 1.4.0 clamav: 0.97.3/m:54/d:15574 Received: from unknown (HELO suse3) (rainer@ultra-secure.de@212.71.117.1) by mail.ultra-secure.de with ESMTPA; 14 Nov 2012 11:13:58 -0000 Date: Wed, 14 Nov 2012 12:13:57 +0100 From: Rainer Duffner To: freebsd-current@freebsd.org Subject: Re: Looking for bge(4) , bce(4) and igb(4) cards Message-ID: <20121114121357.01fd600e@suse3> In-Reply-To: <50A372EC.5080002@freebsd.org> References: <50A372EC.5080002@freebsd.org> X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.10; x86_64-suse-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: andre@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 11:15:04 -0000 Am Wed, 14 Nov 2012 11:31:08 +0100 schrieb Andre Oppermann : > Hello >=20 > I currently working on a number of drivers for popular network > cards and extend them with automatic hybrid interrupt/polling > ithread processing with life-lock prevention (so that the driver > can't consume all CPU when under heavy load or attack). >=20 > To properly test this I need the proper hardware as PCIe network > cards: >=20 > bge(4) Broadcom BCM57xx/BCM590x > bce(4) Broadcom NetXtreme II (BCM5706/5708/5709/5716) > igb(4) Intel PRO/1000 i82575, i82576, i82580, i210, i350 Hallo Andre, wie lange w=C3=BCrdest Du die Karten brauchen? igb(4) k=C3=B6nnte ich vielleicht leihweise organisieren. Wir werden davon eh' einen Haufen bestellen m=C3=BCssen, weil die NetFlex Karten in HPs Gen8-Servern nicht unter FreeBSD laufen - und das wird sich eher nicht =C3=A4ndern die n=C3=A4chste Zeit, so wie es aussieht.... Gruss Rainer From owner-freebsd-current@FreeBSD.ORG Wed Nov 14 11:17:31 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0FF1AC98 for ; Wed, 14 Nov 2012 11:17:31 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 5B2FB8FC08 for ; Wed, 14 Nov 2012 11:17:30 +0000 (UTC) Received: from porto.starpoint.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 NAA21004 for ; Wed, 14 Nov 2012 13:17:29 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1TYayG-000K2s-PK for freebsd-current@FreeBSD.org; Wed, 14 Nov 2012 13:17:28 +0200 Message-ID: <50A37DC8.9030108@FreeBSD.org> Date: Wed, 14 Nov 2012 13:17:28 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:16.0) Gecko/20121030 Thunderbird/16.0.2 MIME-Version: 1.0 To: freebsd-current@FreeBSD.org Subject: Re: Supermicro X8DT6 crashes in bootloader after r239066 References: <20121031053113.GA1446@itx> In-Reply-To: <20121031053113.GA1446@itx> X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 11:17:31 -0000 on 31/10/2012 07:31 Navdeep Parhar said the following: > I have one of these X8DT6 systems. It has grub2 as the primary boot > loader which then loads zfsloader. Many weeks back I updated the BIOS, > grub, and FreeBSD and ran into a similar problem -- zfsloader would > start, print a few messages, and then the system would reboot. I > tracked it down to the int 0x13 call (with eax=0x4800) in bd_int13probe. > It would walk past the end of the edd_params structure and corrupt the > return address on the stack. I worked around it by padding edd_params. > I was planning to debug it further to find out which of the 3 things > that were updated caused the problem but Other Things(tm) came up. See > if this works for you too: > > diff -r d35d326e437a -r e5228169f3f1 sys/boot/i386/common/edd.h > --- a/sys/boot/i386/common/edd.h Tue Oct 30 21:51:09 2012 -0700 > +++ b/sys/boot/i386/common/edd.h Tue Oct 30 21:51:20 2012 -0700 > @@ -62,6 +62,7 @@ struct edd_params { > uint16_t sector_size; > uint16_t edd_params_seg; > uint16_t edd_params_off; > + char pad[64]; > }; Navdeep, I've committed a different antidote for this BIOS bug as r243025. Could you please that it works for you too? -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Wed Nov 14 11:21:45 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4B0C3EAC; Wed, 14 Nov 2012 11:21:45 +0000 (UTC) (envelope-from girgen@FreeBSD.org) Received: from melon.pingpong.net (melon.pingpong.net [79.136.116.200]) by mx1.freebsd.org (Postfix) with ESMTP id ED72A8FC08; Wed, 14 Nov 2012 11:21:44 +0000 (UTC) Received: from girgBook.local (c-4d56e155.1525-1-64736c12.cust.bredbandsbolaget.se [85.225.86.77]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by melon.pingpong.net (Postfix) with ESMTPSA id 9282C25155; Wed, 14 Nov 2012 12:13:21 +0100 (CET) Message-ID: <50A37CCF.2040409@FreeBSD.org> Date: Wed, 14 Nov 2012 12:13:19 +0100 From: Palle Girgensohn User-Agent: Postbox 3.0.6 (Macintosh/20121022) MIME-Version: 1.0 To: Andriy Gapon Subject: Re: gptzfsboot error using HP Smart Array P410i Controller References: <9B96176A-7550-4B60-8F4D-0B667EEF7A15@me.com> <201108161515.50127.jhb@freebsd.org> <23B6937F-F261-4DC4-9168-96720251C98D@me.com> <4E502F2F.50209@FreeBSD.org> <9FAB808F-E5D4-4B93-9D5F-BAE025930273@me.com> <4E944197.7050803@digsys.bg> <4F4FECA4.10504@FreeBSD.org> <50A37C2D.9010607@FreeBSD.org> In-Reply-To: <50A37C2D.9010607@FreeBSD.org> X-Enigmail-Version: 1.2.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Julian Akehurst , Bjorn Larsson , freebsd-current@FreeBSD.org, Christoph Hoffmann , Daniel Kalchev X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 11:21:45 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Thanks, We can chack it out, we are about to reinstall a machine. Migth be a HP DL380 *G6* though, does that matter? Andriy Gapon skrev: > Guys, > > if you still have the hardware and use FreeBSD, could you please try > r243025? > > http://svnweb.freebsd.org/base?view=revision&revision=243025 > -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJQo3zPAAoJEIhV+7FrxBJD/gkH/R3n0mpEssT7bqmMH4lDcOTc MmYtQSxpBDRY2Ldvq/BmaRthtmg67K0Hq3iXzQOnUnmXDqQp2wJSUsCjHOto838e 6JpO9gVqxmVXmQWAMEhCt5n60RBhgrGdnIfGlOIZSTp+jiB5KAo8FHFBHCPoq/yB 2fcqOdraoKQXWij5TAnNnyfVl08E7VubL3zj/AMB2hcHSNnX3A5GxGOiCvLGLRnR 6xNt9T/Kyc0VF/G/AGYbbKcu91LcvSpcCje8VGvWkGZUgTblUUKfGmBEHE5X5Oz6 FCGP9fdwzIx3P3zRKVJqTnoxNYPJXIuy1YEitKPL5r3jA6GQAlFDKk7y6BX6Yvk= =gXAy -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Wed Nov 14 15:38:20 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BD7D3651; Wed, 14 Nov 2012 15:38:20 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id 5BE298FC13; Wed, 14 Nov 2012 15:38:19 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.5/8.14.5) with ESMTP id qAEFcJUi094194; Wed, 14 Nov 2012 08:38:19 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id qAEFcHub023744; Wed, 14 Nov 2012 08:38:17 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Subject: Re: compiler info in kernel identification string From: Ian Lepore To: Dimitry Andric In-Reply-To: <50A3639C.9050200@FreeBSD.org> References: <20121113234303.GA15319@dft-labs.eu> <50A3639C.9050200@FreeBSD.org> Content-Type: text/plain; charset="us-ascii" Date: Wed, 14 Nov 2012 08:38:17 -0700 Message-ID: <1352907497.1217.147.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: Mateusz Guzik , avg@freebsd.org, freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 15:38:20 -0000 On Wed, 2012-11-14 at 10:25 +0100, Dimitry Andric wrote: > On 2012-11-14 00:43, Mateusz Guzik wrote: > > avg@ suggested to include compiler version in the kernel so that it's > > present in uname (and one can easly tell what was used to compile it). > > > > Here is my attempt: > > http://people.freebsd.org/~mjg/patches/newvers-compiler.diff > > > > Basically adds compiler name and version/revision after revision of > > system sources. > > > > Sample output from dirty git sources: > > gcc: > > FreeBSD 10.0-CURRENT #7 r242962=264d569-dirty(gcc-4.2.1-20070831): Wed > > Nov 14 00:11:51 CET 2012 > > > > clang: > > FreeBSD 10.0-CURRENT #8 r242962=264d569-dirty(clang-r162107): Wed Nov 14 > > 00:12:26 CET 2012 > > > > Sample output from svn with gcc: > > FreeBSD 10.0-CURRENT #1 r243006:243007M(gcc-4.2.1-20070831): Wed Nov 14 > > 00:41:23 CET 2012 > > > > I have no strong opinions on format, I just want this information easly > > accessible. > > Yes, this is handy to have. Note that gcc already puts an id string > into each object file it produces, but sometimes during linking, these > can be stripped out... > > Regarding the format, I don't see the necessity of parsing the version > information, which will always be very fragile. Just include the > complete version string in the compiler identification, similar to what > Linux does, e.g. on a CentOS box: > > $ gcc -v 2>&1 | grep 'version ' > gcc version 4.4.6 20120305 (Red Hat 4.4.6-4) (GCC) > > $ dmesg | grep 'gcc version ' > Linux version 2.6.32-279.2.1.el6.x86_64 (mockbuild@c6b7.bsys.dev.centos.org) (gcc version 4.4.6 20120305 (Red Hat 4.4.6-4) (GCC) ) #1 SMP Fri Jul 20 01:55:29 UTC 2012 > > That way, you are sure never to lose information. This also works for > gcc from ports (which is the reason for the space after 'version' in the > grep command): > > $ gcc47 -v 2>&1 | grep 'version ' > gcc version 4.7.3 20120929 (prerelease) (FreeBSD Ports Collection) > > I realize this is a bit long, but it is better to have complete than > stripped information. Rather than just taking whatever the compiler emits, the proposed patch seems to be carefully crafted to avoid breaking existing 3rd party tools which parse uname output based on the location of whitespace. I'm not sure how important that is given that the uname manpage doesn't document the output format as if it were somehow rigidly specified. I may be more sensitive to this than usual right now, after having caused a bunch of grief to our manufacturing folks at work yesterday by removing a useless line of output about an obsolete feature from a script that I didn't realize they use in their automation. -- Ian From owner-freebsd-current@FreeBSD.ORG Wed Nov 14 15:13:58 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 34EDBE6B; Wed, 14 Nov 2012 15:13:58 +0000 (UTC) (envelope-from bjwela@gmail.com) Received: from mail-la0-f54.google.com (mail-la0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id EE3B68FC16; Wed, 14 Nov 2012 15:13:56 +0000 (UTC) Received: by mail-la0-f54.google.com with SMTP id j13so537357lah.13 for ; Wed, 14 Nov 2012 07:13:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to; bh=XdM87UumtZ8ihA0MLeiCwZmloiIjTjZkWpCLH3wgM08=; b=Jn9HGduhgy8rptq/6HZ8VmByvZNVOY/G6PjQZ/LjLiQmAcibe8Q9TMP94bXLFtazWw lJM3xrjq5wrLYXouYz98Fu1Bb3EJUC5WBooz6haeXzwErbGfgObhbcOiCe06a7D2YuKI x8+rWhPGuvnq0twT2AgRgfpsIBqk93tQjEeV0B8BBOw1eITEDwstZl0P8pldh3qpwE8c 4ErWEwgppXbQI+9gwIYM3SwIV+qn8w3l3pxg6pPTzKWDCDLB6P2+wmH7vQEm2IRmdUMg /q7JtswnD0XLvX9igPSKE3URiKZhcW1H9Xy5pHNSg653QY31g4qjR15bpVxWKRq/2Q4l 19HQ== Received: by 10.152.106.4 with SMTP id gq4mr24776668lab.44.1352906035566; Wed, 14 Nov 2012 07:13:55 -0800 (PST) Received: from [192.168.1.102] (h-156-77.a148.priv.bahnhof.se. [37.123.156.77]) by mx.google.com with ESMTPS id ti4sm5166378lab.1.2012.11.14.07.13.52 (version=SSLv3 cipher=OTHER); Wed, 14 Nov 2012 07:13:53 -0800 (PST) References: <9B96176A-7550-4B60-8F4D-0B667EEF7A15@me.com> <201108161515.50127.jhb@freebsd.org> <23B6937F-F261-4DC4-9168-96720251C98D@me.com> <4E502F2F.50209@FreeBSD.org> <9FAB808F-E5D4-4B93-9D5F-BAE025930273@me.com> <4E944197.7050803@digsys.bg> <4F4FECA4.10504@FreeBSD.org> <50A37C2D.9010607@FreeBSD.org> <50A37CCF.2040409@FreeBSD.org> Mime-Version: 1.0 (1.0) In-Reply-To: <50A37CCF.2040409@FreeBSD.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <32398E0F-2056-47DB-8543-685EEF542039@gmail.com> X-Mailer: iPhone Mail (10A403) From: =?utf-8?Q?Bj=C3=B6rn_Larsson?= Subject: Re: gptzfsboot error using HP Smart Array P410i Controller Date: Wed, 14 Nov 2012 16:13:52 +0100 To: Palle Girgensohn X-Mailman-Approved-At: Wed, 14 Nov 2012 16:35:09 +0000 Cc: Julian Akehurst , "freebsd-current@FreeBSD.org" , Christoph Hoffmann , Andriy Gapon , Daniel Kalchev X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 15:13:58 -0000 Hi Andriy,=20 I still have the HW and will test this next week.=20 Thanks,=20 Bj=C3=B6rn Skickat fr=C3=A5n min iPhone 14 nov 2012 kl. 12:13 skrev Palle Girgensohn : > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > Thanks, >=20 > We can chack it out, we are about to reinstall a machine. Migth be a HP > DL380 *G6* though, does that matter? >=20 > Andriy Gapon skrev: >> Guys, >>=20 >> if you still have the hardware and use FreeBSD, could you please try >> r243025? >>=20 >> http://svnweb.freebsd.org/base?view=3Drevision&revision=3D243025 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.17 (Darwin) > Comment: GPGTools - http://gpgtools.org > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ >=20 > iQEcBAEBAgAGBQJQo3zPAAoJEIhV+7FrxBJD/gkH/R3n0mpEssT7bqmMH4lDcOTc > MmYtQSxpBDRY2Ldvq/BmaRthtmg67K0Hq3iXzQOnUnmXDqQp2wJSUsCjHOto838e > 6JpO9gVqxmVXmQWAMEhCt5n60RBhgrGdnIfGlOIZSTp+jiB5KAo8FHFBHCPoq/yB > 2fcqOdraoKQXWij5TAnNnyfVl08E7VubL3zj/AMB2hcHSNnX3A5GxGOiCvLGLRnR > 6xNt9T/Kyc0VF/G/AGYbbKcu91LcvSpcCje8VGvWkGZUgTblUUKfGmBEHE5X5Oz6 > FCGP9fdwzIx3P3zRKVJqTnoxNYPJXIuy1YEitKPL5r3jA6GQAlFDKk7y6BX6Yvk=3D > =3DgXAy > -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Wed Nov 14 19:59:49 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 344F4EEA; Wed, 14 Nov 2012 19:59:49 +0000 (UTC) (envelope-from nparhar@gmail.com) Received: from mail-pa0-f54.google.com (mail-pa0-f54.google.com [209.85.220.54]) by mx1.freebsd.org (Postfix) with ESMTP id EE4FD8FC12; Wed, 14 Nov 2012 19:59:48 +0000 (UTC) Received: by mail-pa0-f54.google.com with SMTP id kp6so582715pab.13 for ; Wed, 14 Nov 2012 11:59:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=Qb3xMU0whetY8LX3za08DUYOW2180vam9ZoN+twl22g=; b=rDg2/SjAHArkGS/xX3xTM8c0uUtnZdJkpGjgF+Ew2qpPkR0RSG/CcielOJ1t0VtGKa CjfyiiztJJuMSPkCqJvpEwFEBJfuyn8bXTcubrBwIeygLzg5IOdLaBb1zz6+R9Zd5wKC ETY56SvtdYjsypSZywi+yH9i4iutljxaGnP/z4TqgQB7jOQl0zMdGUCr94YnfA0TcjPj AcZMtOTx/khv+d/5f7CH8gZRfmyG+KLo/Nv3aMix/7CcQ117QOVKyGieTcSD4jReVa6g FHBPIwFmdvNsxCjaaNjrfTOy3vNuMLB065NVhMZkcFWfsZDOfzwuwgBhtlD/gj0F2Q0O uZOQ== Received: by 10.69.0.8 with SMTP id au8mr74769014pbd.58.1352923188735; Wed, 14 Nov 2012 11:59:48 -0800 (PST) Received: from [10.192.166.0] (stargate.chelsio.com. [67.207.112.58]) by mx.google.com with ESMTPS id x6sm8375584pav.29.2012.11.14.11.59.46 (version=SSLv3 cipher=OTHER); Wed, 14 Nov 2012 11:59:47 -0800 (PST) Message-ID: <50A3F831.2090108@gmail.com> Date: Wed, 14 Nov 2012 11:59:45 -0800 From: Navdeep Parhar User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:16.0) Gecko/20121101 Thunderbird/16.0.2 MIME-Version: 1.0 To: Andriy Gapon Subject: Re: Supermicro X8DT6 crashes in bootloader after r239066 References: <20121031053113.GA1446@itx> <50A37DC8.9030108@FreeBSD.org> In-Reply-To: <50A37DC8.9030108@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 19:59:49 -0000 On 11/14/12 03:17, Andriy Gapon wrote: > on 31/10/2012 07:31 Navdeep Parhar said the following: >> I have one of these X8DT6 systems. It has grub2 as the primary boot >> loader which then loads zfsloader. Many weeks back I updated the BIOS, >> grub, and FreeBSD and ran into a similar problem -- zfsloader would >> start, print a few messages, and then the system would reboot. I >> tracked it down to the int 0x13 call (with eax=0x4800) in bd_int13probe. >> It would walk past the end of the edd_params structure and corrupt the >> return address on the stack. I worked around it by padding edd_params. >> I was planning to debug it further to find out which of the 3 things >> that were updated caused the problem but Other Things(tm) came up. See >> if this works for you too: >> >> diff -r d35d326e437a -r e5228169f3f1 sys/boot/i386/common/edd.h >> --- a/sys/boot/i386/common/edd.h Tue Oct 30 21:51:09 2012 -0700 >> +++ b/sys/boot/i386/common/edd.h Tue Oct 30 21:51:20 2012 -0700 >> @@ -62,6 +62,7 @@ struct edd_params { >> uint16_t sector_size; >> uint16_t edd_params_seg; >> uint16_t edd_params_off; >> + char pad[64]; >> }; > > Navdeep, > > I've committed a different antidote for this BIOS bug as r243025. > Could you please that it works for you too? > Yes it works for me too, thanks Andriy! Regards, Navdeep From owner-freebsd-current@FreeBSD.ORG Wed Nov 14 21:56:40 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 45814E1B for ; Wed, 14 Nov 2012 21:56:40 +0000 (UTC) (envelope-from cattelan@thebarn.com) Received: from x.digitalelves.com (x.digitalelves.com [209.98.77.55]) by mx1.freebsd.org (Postfix) with ESMTP id 9E7078FC19 for ; Wed, 14 Nov 2012 21:56:39 +0000 (UTC) Received: from Digital-Elf-6.local (74-95-101-241-Minnesota.hfc.comcastbusiness.net [74.95.101.241]) (authenticated bits=0) by x.digitalelves.com (8.14.5/8.14.5) with ESMTP id qAELucmb002628 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Wed, 14 Nov 2012 15:56:38 -0600 (CST) (envelope-from cattelan@thebarn.com) Message-ID: <50A41395.7080205@thebarn.com> Date: Wed, 14 Nov 2012 15:56:37 -0600 From: Russell Cattelan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Anybody willing to test out kload? X-Enigmail-Version: 1.4.4 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigD23560E60788DF043BB39181" X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 21:56:40 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigD23560E60788DF043BB39181 Content-Type: multipart/mixed; boundary="------------050100010201000009010505" This is a multi-part message in MIME format. --------------050100010201000009010505 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable This has been sitting on my plate for a while and I would like to get some more feedback / testing on this feature. What is really would like to find out is which drivers do not shutdown their chips correctly and thus cause stray interrupts on the kload boot. Attached is is the patch again FreeBSD current. Or if anybody wants to browse the git tree. http://git.digitalelves.com/?p=3DFreeBSD_kload.git;a=3Dsummary -Russell --------------050100010201000009010505 Content-Type: text/plain; charset=UTF-8; x-mac-type="0"; x-mac-creator="0"; name="kload.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="kload.patch" diff --git a/.gitignore b/.gitignore deleted file mode 100644 index c609633..0000000 diff --git a/sys/amd64/amd64/kload_exec.S b/sys/amd64/amd64/kload_exec.S deleted file mode 100644 index 75bff3b..0000000 --- a/sys/amd64/amd64/kload_exec.S +++ /dev/null @@ -1,180 +0,0 @@ -/* - * Copyright (c) 2011 - 2012 - * Russell Cattelan Digital Elves Inc - * Copyright (c) 2011 - 2012 - * Isilon Systems, LLC. All rights reserved. - * - * Redistribution and use in source and binary forms, with or without - * modification, are permitted provided that the following conditions - * are met: - * 1. Redistributions of source code must retain the above copyright - * notice, this list of conditions and the following disclaimer. - * 2. Redistributions in binary form must reproduce the above copyright - * notice, this list of conditions and the following disclaimer in th= e - * documentation and/or other materials provided with the distributio= n. - * - * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AN= D - * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE= - * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PU= RPOSE - * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIAB= LE - * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUE= NTIAL - * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOO= DS - * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)= - * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, S= TRICT - * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY= WAY - * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY O= F - * SUCH DAMAGE. - * - */ - -#include "assym.s" - -#define CR0_PG 0x80000000 /* PaGing enable */ - -#define X86_CR0_PE 0x00000001 /* Protection Enable */ -#define X86_CR0_MP 0x00000002 /* Monitor Coprocessor */ -#define X86_CR0_EM 0x00000004 /* Emulation */ -#define X86_CR0_TS 0x00000008 /* Task Switched */ -#define X86_CR0_ET 0x00000010 /* Extension Type */ -#define X86_CR0_NE 0x00000020 /* Numeric Error */ -#define X86_CR0_WP 0x00010000 /* Write Protect */ -#define X86_CR0_AM 0x00040000 /* Alignment Mask */ -#define X86_CR0_NW 0x20000000 /* Not Write-through */ -#define X86_CR0_CD 0x40000000 /* Cache Disable */ -#define X86_CR0_PG 0x80000000 /* Paging */ - -#define X86_CR4_PSE 0x00000010 /* enable page size extensions */ -#define X86_CR4_PAE 0x00000020 /* enable physical address extensions */ - - .globl relocate_kernel -relocate_kernel: - /* first install the new page table */ - movq 32(%rcx), %rax /* page table */ - movq 40(%rcx), %r9 /* address of control_page with new PT */ - movq %rax, %cr3 - - /* - * Set cr4 to a known state: - * - page size extensions - * - physical address extension enabled - */ - movq $(X86_CR4_PSE | X86_CR4_PAE), %rax - movq %rax, %cr4 - - /* then move the stack to the end of control page */ - lea 4096(%r9), %rsp - - /* now save stuff onto the new stack */ - pushq %rcx /* arg 4 control page */ - pushq %rdx /* arg 3 code page */ - pushq %rsi /* arg 2 kern base */ - pushq %rdi /* arg 1 va_list */ - - /* zero out flags, and disable interrupts */ - pushq $0 - popfq - cli - - /* install simple gdt */ - movq 24(%r9), %rax /* gdt */ - lgdt (%rax) - movq 56(%r9), %rax - lidt (%rax) /* null idt */ - /* - * now move to the code page - * should have been passed code_page based - * on new page table - */ - movq %rdx, %r8 - addq $(identity_mapped - relocate_kernel), %r8 - /* offset of code segment in new gdt */ - pushq $0x08 - pushq %r8 - /* jump to this spot in the new page */ - lretq -identity_mapped: - - movq $0x10,%rax - movq %rax,%ds - movq %rax,%es - movq %rax,%fs - movq %rax,%gs - movq %rax,%ss -=09 - /* - * Set cr0 to a known state: - * - Paging enabled - * - Alignment check disabled - * - Write protect disabled - * - No task switch - * - Don't do FP software emulation. - * - Proctected mode enabled - */ - movq %cr0, %rax - andq $~(X86_CR0_AM | X86_CR0_WP | X86_CR0_TS | X86_CR0_EM | X86_CR0_MP= | X86_CR0_NE), %rax - orl $(X86_CR0_PG | X86_CR0_PE), %eax - movq %rax, %cr0 - - /* Do the copies */ - cld - /* saved list of source pages */ - movq 0(%rsp), %rbx - /* - * the initial dest page - * this is KERNBASE + 0x200000 - * kernel is contigious in memory - */ - movq 8(%rsp), %rdi -0: /* top, read another word for the indirection page */ - movq (%rbx), %rcx - - addq $8, %rbx - testq $0x1, %rcx /* is it a destination page */ - jz 1f - movq %rcx, %rdi - andq $0xFFFFFFFFfffff000, %rdi - jmp 0b -1: - testq $0x2, %rcx /* is it an indirection page */ - jz 1f - movq %rcx, %rbx - andq $0xFFFFFFFFfffff000, %rbx - jmp 0b -1: - testq $0x4, %rcx /* is it the done indicator */ - jz 1f - jmp 2f -1: - testq $0x8, %rcx /* is it the source indicator */ - jz 0b /* Ignore it otherwise */ - movq %rcx, %rsi /* For every source page do a copy */ - andq $0xfffffffffffff000, %rsi - movq $512, %rcx - rep - movsq - jmp 0b -2: - /* - * set all of the registers to known values - * leave %rsp alone - */ - xorq %rax, %rax - xorq %rbx, %rbx - xorq %rcx, %rcx - xorq %rdx, %rdx - xorq %rsi, %rsi - xorq %rdi, %rdi - xorq %rbp, %rbp - - pushq 16(%r9) /* physfree */ - movq 8(%r9), %rax /* modulep */ - salq $32, %rax - pushq %rax - - pushq $0x8 - pushq 48(%r9) /* entry # kernel entry pt */ - lretq -relocate_kernel_end: - .globl relocate_kernel_size -relocate_kernel_size: - .long relocate_kernel_end - relocate_kernel diff --git a/sys/amd64/amd64/mp_machdep.c b/sys/amd64/amd64/mp_machdep.c index b085326..d2e4aad 100644 --- a/sys/amd64/amd64/mp_machdep.c +++ b/sys/amd64/amd64/mp_machdep.c @@ -78,9 +78,6 @@ __FBSDID("$FreeBSD$"); #define BIOS_RESET (0x0f) #define BIOS_WARM (0x0a) =20 - -// quick hack to access the kload page table so we can set the APs to a = know pgtbl */ -extern unsigned long kload_pgtbl; /* lock region used by kernel profiling */ int mcount_lock; =20 @@ -1412,20 +1409,10 @@ cpustop_handler(void) void cpususpend_handler(void) { - register_t cr3, rf; - register_t cr0, cr4; u_int cpu; =20 cpu =3D PCPU_GET(cpuid); =20 - printf("%s called on cpu%d\n",__FUNCTION__,cpu); - - rf =3D intr_disable(); - cr3 =3D rcr3(); - - lapic_clear_lapic(1 /* disable lapic */); - /* shutdown interrupts to the cpu and then set the mask as stopped */ - if (savectx(susppcbs[cpu])) { ctx_fpusave(susppcbs[cpu]->pcb_fpususpend); wbinvd(); @@ -1435,37 +1422,20 @@ cpususpend_handler(void) initializecpu(); PCPU_SET(switchtime, 0); PCPU_SET(switchticks, ticks); - } - - /* make sure the page table is not the same one that boot process sets = up */ - load_cr3(kload_pgtbl); =20 - /* Disable PGE. */ - cr4 =3D rcr4(); - load_cr4(cr4 & ~CR4_PGE); - - /* Disable caches (CD =3D 1, NW =3D 0) and paging*/ - cr0 =3D rcr0(); - load_cr0((cr0 & ~CR0_NW) | CR0_CD | CR0_PG); - - /* Flushes caches and TLBs. */ - wbinvd(); - invltlb(); - - halt(); + /* Indicate that we are resumed */ + CPU_CLR_ATOMIC(cpu, &suspended_cpus); + } =20 /* Wait for resume */ while (!CPU_ISSET(cpu, &started_cpus)) ia32_pause(); =20 CPU_CLR_ATOMIC(cpu, &started_cpus); - CPU_CLR_ATOMIC(cpu, &stopped_cpus); =20 - /* Restore CR3 and enable interrupts */ - load_cr3(cr3); + /* Resume MCA and local APIC */ mca_resume(); lapic_setup(0); - intr_restore(rf); } =20 /* diff --git a/sys/amd64/include/apicvar.h b/sys/amd64/include/apicvar.h index 7fded95..ae2f5b9 100644 --- a/sys/amd64/include/apicvar.h +++ b/sys/amd64/include/apicvar.h @@ -227,7 +227,6 @@ int lapic_set_lvt_triggermode(u_int apic_id, u_int lv= t, enum intr_trigger trigger); void lapic_set_tpr(u_int vector); void lapic_setup(int boot); -void lapic_clear_lapic(u_int); =20 #endif /* !LOCORE */ #endif /* _MACHINE_APICVAR_H_ */ diff --git a/sys/amd64/include/intr_machdep.h b/sys/amd64/include/intr_ma= chdep.h index a8ef1fc..700e35f 100644 --- a/sys/amd64/include/intr_machdep.h +++ b/sys/amd64/include/intr_machdep.h @@ -158,7 +158,6 @@ struct intsrc *intr_lookup_source(int vector); int intr_register_pic(struct pic *pic); int intr_register_source(struct intsrc *isrc); int intr_remove_handler(void *cookie); -int intr_clear_all_handlers(void); void intr_resume(void); void intr_suspend(void); void intrcnt_add(const char *name, u_long **countp); diff --git a/sys/boot/common/load_elf.c b/sys/boot/common/load_elf.c index 36df22c..e1e6de7 100644 --- a/sys/boot/common/load_elf.c +++ b/sys/boot/common/load_elf.c @@ -317,30 +317,25 @@ __elfN(loadimage)(struct preloaded_file *fp, elf_fi= le_t ef, u_int64_t off) continue; =20 #ifdef ELF_VERBOSE - printf("Segment: filesz 0x%llx @ 0x%016llx -> vaddr_range 0x%016llx - = 0x%016llx", - (long long)phdr[i].p_filesz, (long long)phdr[i].p_offset, - (long long)(phdr[i].p_vaddr + off), - (long long)(phdr[i].p_vaddr + off + phdr[i].p_memsz - 1)); + printf("Segment: 0x%lx@0x%lx -> 0x%lx-0x%lx", + (long)phdr[i].p_filesz, (long)phdr[i].p_offset, + (long)(phdr[i].p_vaddr + off), + (long)(phdr[i].p_vaddr + off + phdr[i].p_memsz - 1)); #else if ((phdr[i].p_flags & PF_W) =3D=3D 0) { - printf("text=3D0x%llx ", (long long)phdr[i].p_filesz); + printf("text=3D0x%lx ", (long)phdr[i].p_filesz); } else { - printf("data=3D0x%llx", (long long)phdr[i].p_filesz); + printf("data=3D0x%lx", (long)phdr[i].p_filesz); if (phdr[i].p_filesz < phdr[i].p_memsz) - printf("+0x%llx", (long long)(phdr[i].p_memsz -phdr[i].p_filesz)); + printf("+0x%lx", (long)(phdr[i].p_memsz -phdr[i].p_filesz)); printf(" "); } #endif fpcopy =3D 0; if (ef->firstlen > phdr[i].p_offset) { fpcopy =3D ef->firstlen - phdr[i].p_offset; - printf("\n%s:%d firstpage 0x%lx p_offset 0x%lx p_vaddr 0x%lx off 0x= %lx\n", - __FUNCTION__,__LINE__, - (unsigned long)ef->firstpage, - (unsigned long) phdr[i].p_offset, - (unsigned long)phdr[i].p_vaddr, - (unsigned long)off); - archsw.arch_copyin(ef->firstpage + phdr[i].p_offset, phdr[i].p_vadd= r + off, fpcopy); + archsw.arch_copyin(ef->firstpage + phdr[i].p_offset, + phdr[i].p_vaddr + off, fpcopy); } if (phdr[i].p_filesz > fpcopy) { if (kern_pread(ef->fd, phdr[i].p_vaddr + off + fpcopy, @@ -353,11 +348,9 @@ __elfN(loadimage)(struct preloaded_file *fp, elf_fil= e_t ef, u_int64_t off) /* clear space from oversized segments; eg: bss */ if (phdr[i].p_filesz < phdr[i].p_memsz) { #ifdef ELF_VERBOSE - printf("\n\t(bss: 0x%lx-0x%lx) vaddr 0x%lx size 0x%lx clearing\n",= - (long)(phdr[i].p_vaddr + off + phdr[i].p_filesz), - (long)(phdr[i].p_vaddr + off + phdr[i].p_memsz - 1), - (long)(phdr[i].p_vaddr + phdr[i].p_filesz), - (long)(phdr[i].p_memsz - phdr[i].p_filesz) ); + printf(" (bss: 0x%lx-0x%lx)", + (long)(phdr[i].p_vaddr + off + phdr[i].p_filesz), + (long)(phdr[i].p_vaddr + off + phdr[i].p_memsz - 1)); #endif =20 kern_bzero(phdr[i].p_vaddr + off + phdr[i].p_filesz, diff --git a/sys/boot/userboot/ficl/Makefile b/sys/boot/userboot/ficl/Mak= efile index d7818b9..42b9309 100644 --- a/sys/boot/userboot/ficl/Makefile +++ b/sys/boot/userboot/ficl/Makefile @@ -62,10 +62,6 @@ softcore.c: ${SOFTWORDS} softcore.awk (cd ${.CURDIR}/../../ficl/softwords; cat ${SOFTWORDS} \ | awk -f softcore.awk -v datestamp=3D"`LC_ALL=3DC date`") > ${.TARG= ET} =20 -beforedepend ${OBJS}: no-machine - -no-machine: - rm -f ${.CURDIR}/../../ficl/machine #.if ${MACHINE_CPUARCH} =3D=3D "amd64" #${SRCS:M*.c:R:S/$/.o/g}: machine # diff --git a/sys/boot/userboot/test/test.c b/sys/boot/userboot/test/test.= c index 77202c1..36258a7 100644 --- a/sys/boot/userboot/test/test.c +++ b/sys/boot/userboot/test/test.c @@ -376,12 +376,6 @@ test_getenv(void *arg, int idx) return (vars[idx]); } =20 -static int -test_buildsmap(void *arg, void **smap_void, size_t *outlen)=20 -{ - return (0); -} - struct loader_callbacks cb =3D { .putc =3D test_putc, .getc =3D test_getc, @@ -411,7 +405,6 @@ struct loader_callbacks cb =3D { .getmem =3D test_getmem, =20 .getenv =3D test_getenv, - .buildsmap =3D test_buildsmap, }; =20 void @@ -471,5 +464,5 @@ main(int argc, char** argv) term.c_lflag &=3D ~(ICANON|ECHO); tcsetattr(0, TCSAFLUSH, &term); =20 - func(&cb, NULL, USERBOOT_VERSION_4, disk_fd >=3D 0); + func(&cb, NULL, USERBOOT_VERSION_3, disk_fd >=3D 0); } diff --git a/sys/boot/userboot/userboot.h b/sys/boot/userboot/userboot.h index 0a9d2f1..e38927e 100644 --- a/sys/boot/userboot/userboot.h +++ b/sys/boot/userboot/userboot.h @@ -32,7 +32,6 @@ #define USERBOOT_VERSION_1 1 #define USERBOOT_VERSION_2 2 #define USERBOOT_VERSION_3 3 -#define USERBOOT_VERSION_4 4 =20 /* * Exit codes from the loader @@ -196,11 +195,4 @@ struct loader_callbacks { * each invocation will add 1 to the previous value of 'num'. */ const char * (*getenv)(void *arg, int num); - - /* - * build system smap - * this is for kload to build pass back in a copy of the running - * systems smap returns - */ - int (*buildsmap)(void *arg, void **smap, size_t *len); }; diff --git a/sys/boot/userboot/userboot/bootinfo64.c b/sys/boot/userboot/= userboot/bootinfo64.c index 28c47ab..fc7c14d 100644 --- a/sys/boot/userboot/userboot/bootinfo64.c +++ b/sys/boot/userboot/userboot/bootinfo64.c @@ -187,46 +187,33 @@ bios_addsmapdata(struct preloaded_file *kfp) { uint64_t lowmem, highmem; int smapnum, len; - struct smap *smap =3D NULL, *sm =3D NULL; - int error =3D 1; + struct smap smap[3], *sm; =20 - printf("%s\n",__FUNCTION__); + CALLBACK(getmem, &lowmem, &highmem); =20 - if (callbacks->buildsmap) - error =3D callbacks->buildsmap(NULL, (void **)&smap, &len); + sm =3D &smap[0]; =20 - /* either there is no buildsmap function or it failed - * revert back to using getmem and a simple smap - */ + sm->base =3D 0; /* base memory */ + sm->length =3D 640 * 1024; + sm->type =3D SMAP_TYPE_MEMORY; + sm++; =20 - if (error) { - smap =3D sm =3D malloc(3 * sizeof(struct smap)); - CALLBACK(getmem, &lowmem, &highmem); + sm->base =3D 0x100000; /* extended memory */ + sm->length =3D lowmem - 0x100000; + sm->type =3D SMAP_TYPE_MEMORY; + sm++; =20 - sm->base =3D 0; /* base memory */ - sm->length =3D 640 * 1024; - sm->type =3D SMAP_TYPE_MEMORY; - sm++; + smapnum =3D 2; =20 - sm->base =3D 0x100000; /* extended memory */ - sm->length =3D lowmem - 0x100000; - sm->type =3D SMAP_TYPE_MEMORY; - sm++; + if (highmem !=3D 0) { + sm->base =3D 4 * GB; + sm->length =3D highmem; + sm->type =3D SMAP_TYPE_MEMORY; + smapnum++; + } =20 - smapnum =3D 2; - - if (highmem !=3D 0) { - sm->base =3D 4 * GB; - sm->length =3D highmem; - sm->type =3D SMAP_TYPE_MEMORY; - smapnum++; - } - - len =3D smapnum * sizeof (struct smap); - } - - file_addmetadata(kfp, MODINFOMD_SMAP, len, smap); - free(smap); + len =3D smapnum * sizeof (struct smap); + file_addmetadata(kfp, MODINFOMD_SMAP, len, &smap[0]); } =20 /* diff --git a/sys/boot/userboot/userboot/conf.c b/sys/boot/userboot/userbo= ot/conf.c index d2c1067..0c57eba 100644 --- a/sys/boot/userboot/userboot/conf.c +++ b/sys/boot/userboot/userboot/conf.c @@ -86,11 +86,8 @@ struct file_format *file_formats[] =3D { * data structures from bootstrap.h as well. */ extern struct console userboot_console; -extern struct console comconsole; - =20 struct console *consoles[] =3D { &userboot_console, - &comconsole, NULL }; diff --git a/sys/boot/userboot/userboot/main.c b/sys/boot/userboot/userbo= ot/main.c index 0e2e0b7..4092b9b 100644 --- a/sys/boot/userboot/userboot/main.c +++ b/sys/boot/userboot/userboot/main.c @@ -36,9 +36,8 @@ __FBSDID("$FreeBSD$"); #include "disk.h" #include "libuserboot.h" =20 -#define USERBOOT_VERSION USERBOOT_VERSION_4 +#define USERBOOT_VERSION USERBOOT_VERSION_3 =20 -static char malloc_buf[512*1024]; struct loader_callbacks *callbacks; void *callbacks_arg; =20 @@ -68,47 +67,31 @@ exit(int v) } =20 void -loader_init(void) -{ - /* - * It does not hurt to re-call this as it just sets global - * ptrs that never change=20 - */ - setheap((void *)malloc_buf, (void *)(malloc_buf + 512*1024)); -} - -int loader_main(struct loader_callbacks *cb, void *arg, int version, int ndi= sks) { + static char malloc[512*1024]; const char *var; int i; -=09 + + if (version !=3D USERBOOT_VERSION) + abort(); + + callbacks =3D cb; + callbacks_arg =3D arg; + userboot_disk_maxunit =3D ndisks; + /* * initialise the heap as early as possible. Once this is done, * alloc() is usable. The stack is buried inside us, so this is * safe. */ - loader_init(); - =20 - if (cb !=3D NULL) { - callbacks =3D cb; - callbacks_arg =3D arg; - userboot_disk_maxunit =3D ndisks; - } else { - return (EFAULT); - } + setheap((void *)malloc, (void *)(malloc + 512*1024)); =20 - /* + /* * Hook up the console */ cons_probe(); =20 - if (version !=3D USERBOOT_VERSION) { - printf("%s: version expected %d got %d\n", __func__, - USERBOOT_VERSION, version); - return(EOPNOTSUPP); - } - /* * March through the device switch probing for things. */ @@ -145,11 +128,11 @@ loader_main(struct loader_callbacks *cb, void *arg,= int version, int ndisks) extract_currdev(); =20 if (setjmp(jb)) - return (0); + return; =20 interact(); /* doesn't return */ =20 - return(0); + exit(0); } =20 /* diff --git a/sys/boot/userboot/userboot/userboot_cons.c b/sys/boot/userbo= ot/userboot/userboot_cons.c index 5a9a573..5ecb7c8 100644 --- a/sys/boot/userboot/userboot/userboot_cons.c +++ b/sys/boot/userboot/userboot/userboot_cons.c @@ -50,18 +50,6 @@ struct console userboot_console =3D { userboot_cons_poll, }; =20 - -struct console comconsole =3D { - "comconsole", - "comsonsole", - 0, - userboot_cons_probe, - userboot_cons_init, - userboot_cons_putchar, - userboot_cons_getchar, - userboot_cons_poll, -}; - static void userboot_cons_probe(struct console *cp) { diff --git a/sys/conf/files b/sys/conf/files index 49de90a..5554ec0 100644 --- a/sys/conf/files +++ b/sys/conf/files @@ -2607,7 +2607,6 @@ kern/kern_khelp.c standard kern/kern_kthread.c standard kern/kern_ktr.c optional ktr kern/kern_ktrace.c standard -kern/kern_kload.c standard kern/kern_linker.c standard kern/kern_lock.c standard kern/kern_lockf.c standard diff --git a/sys/conf/files.amd64 b/sys/conf/files.amd64 index 2447c7bd..b6a474e 100644 --- a/sys/conf/files.amd64 +++ b/sys/conf/files.amd64 @@ -93,9 +93,6 @@ acpi_wakedata.h optional acpi \ no-obj no-implicit-rule before-depend \ clean "acpi_wakedata.h" # -amd64/amd64/kload_exec.S standard -amd64/amd64/kload.c standard -# amd64/amd64/amd64_mem.c optional mem #amd64/amd64/apic_vector.S standard amd64/amd64/atomic.c standard diff --git a/sys/kern/init_sysent.c b/sys/kern/init_sysent.c index f81a05f..68c24e0 100644 --- a/sys/kern/init_sysent.c +++ b/sys/kern/init_sysent.c @@ -3,7 +3,7 @@ * * DO NOT EDIT-- this file is automatically generated. * $FreeBSD$ - * created from FreeBSD + * created from FreeBSD: head/sys/kern/syscalls.master 242958 2012-11-13= 12:52:31Z kib=20 */ =20 #include "opt_compat.h" @@ -567,5 +567,4 @@ struct sysent sysent[] =3D { { AS(posix_fallocate_args), (sy_call_t *)sys_posix_fallocate, AUE_NULL,= NULL, 0, 0, 0, SY_THR_STATIC }, /* 530 =3D posix_fallocate */ { AS(posix_fadvise_args), (sy_call_t *)sys_posix_fadvise, AUE_NULL, NUL= L, 0, 0, 0, SY_THR_STATIC }, /* 531 =3D posix_fadvise */ { AS(wait6_args), (sy_call_t *)sys_wait6, AUE_WAIT6, NULL, 0, 0, 0, SY_= THR_STATIC }, /* 532 =3D wait6 */ - { AS(kload_args), (sy_call_t *)sys_kload, AUE_NULL, NULL, 0, 0, 0, SY_T= HR_STATIC }, /* 533 =3D kload */ }; diff --git a/sys/kern/kern_kload.c b/sys/kern/kern_kload.c deleted file mode 100644 index 44b468b..0000000 --- a/sys/kern/kern_kload.c +++ /dev/null @@ -1,433 +0,0 @@ -/* - * Copyright (c) 2011 - 2012 - * Russell Cattelan Digital Elves Inc - * Copyright (c) 2011 - 2012 - * Isilon Systems, LLC. All rights reserved. - * - * Redistribution and use in source and binary forms, with or without - * modification, are permitted provided that the following conditions - * are met: - * 1. Redistributions of source code must retain the above copyright - * notice, this list of conditions and the following disclaimer. - * 2. Redistributions in binary form must reproduce the above copyright - * notice, this list of conditions and the following disclaimer in th= e - * documentation and/or other materials provided with the distributio= n. - * - * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AN= D - * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE= - * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PU= RPOSE - * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIAB= LE - * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUE= NTIAL - * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOO= DS - * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)= - * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, S= TRICT - * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY= WAY - * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY O= F - * SUCH DAMAGE. - * - */ -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include - -#include -#include -#include - -#include -#include -#include -#include -#include -#include -#include -#include - - -static struct kload_items *k_items =3D NULL; -static MALLOC_DEFINE(M_KLOAD, "kload_items", "kload items"); -int kload_ready =3D 0; - -static vm_offset_t kload_image_va =3D 0; -/* - * Warning this is somewhat arbitrary, but should go - * away once the allocate delays in kmem_alloc_attr are - * fixed. - */ -#define IMAGE_PREALLOC (24 * 1024 * 1024) - -static void kload_init(void); -SYSINIT(kload_mem, SI_SUB_DRIVERS, SI_ORDER_ANY, kload_init, NULL); - -static int kload_copyin_segment(struct kload_segment *,int); -static int kload_add_page(struct kload_items *, unsigned long); -static void kload_shutdown_final(void *, int); -static struct region_descriptor *mygdt; -static vm_offset_t control_page; -static vm_offset_t code_page; -static void *gdt_desc; -static pt_entry_t *pgtbl; -unsigned long kload_pgtbl; -static unsigned long max_addr =3D 0 , min_addr =3D 0; - -#define GIGMASK (~((1<<30)-1)) -#define ONEGIG (1<<30) -#define GUEST_GDTR_LIMIT (3 * 8 - 1) - -extern char kernphys[]; -#define KLOADBASE KERNBASE - -static void -update_max_min(vm_offset_t addr, int count) -{ - int i; - - for(i =3D 0; i < count; i++) { - if (vtophys(addr + (i * PAGE_SIZE)) < min_addr) - min_addr =3D vtophys(addr + (i * PAGE_SIZE)); - if (vtophys(addr + (i * PAGE_SIZE)) > max_addr) - max_addr =3D vtophys(addr + (i * PAGE_SIZE)); - } -} - -static vm_offset_t -kload_kmem_alloc(vm_map_t map, vm_size_t size) -{ - vm_offset_t va; - int num_pages; - - va =3D kmem_alloc_attr(map, size, - M_WAITOK | M_ZERO, - 0, (1 << 30) /* 1Gig limit */, - VM_MEMATTR_WRITE_COMBINING); - - num_pages =3D roundup2(size,PAGE_SIZE) >> PAGE_SHIFT; - update_max_min(va, num_pages); - - return (va); - } - -struct kload_cpage { - unsigned long kcp_magic; /* 0 */ - unsigned long kcp_modulep; /* 1 */ - unsigned long kcp_physfree; /* 2 */ - unsigned long kcp_gdt; /* 3 */ - unsigned long kcp_pgtbl; /* 4 */ - unsigned long kcp_cp; /* 5 */ - unsigned long kcp_entry_pt; /* 6 */ - unsigned long kcp_idt; /* 7 */ -} __packed; - -static int -kload_add_page(struct kload_items *items, unsigned long item_m) -{ - vm_paddr_t phys; - unsigned long va; - - if (*items->item !=3D 0) { - printf(" item !=3D 0 0x%lx\n",*items->item); - items->item++; - items->i_count--; - } - - - if ((items->item =3D=3D items->last_item) || (items->i_count =3D=3D 0))= { - /* out of space in current page grab a new one */ - va =3D (unsigned long)kload_kmem_alloc(kernel_map,PAGE_SIZE); - if (items->head_va =3D=3D 0) - items->head_va =3D va; - - phys =3D vtophys(va); - /* store the address of indrect page */ - *items->item =3D (unsigned long) - (vtophys(va) + KLOADBASE) | KLOAD_INDIRECT; - items->item =3D (unsigned long *)va; - /* ok now move to new page to start storing address */ - items->last_item =3D (unsigned long *)va + - ((PAGE_SIZE/sizeof(unsigned long)) - 1); - items->i_count =3D ((PAGE_SIZE/sizeof(unsigned long)) - 1); - } - *items->item =3D item_m; - items->item++; - items->i_count--; - - return (0); -} - -static void -kload_init(void) -{ - int size =3D IMAGE_PREALLOC; - kload_image_va =3D kload_kmem_alloc(kernel_map, size); - printf("%s 0x%lx preallocated size %d\n", __func__, - kload_image_va, size); -} - -int -kload_copyin_segment(struct kload_segment *khdr, int seg) -{ - int i; - int num_pages; - int error =3D 0; - vm_offset_t va =3D kload_image_va; - - num_pages =3D roundup2(khdr->k_memsz,PAGE_SIZE) >> PAGE_SHIFT; - - /* check to make sure the preallocate space is beg enough */ - if (va && ((num_pages * PAGE_SIZE) > IMAGE_PREALLOC)) { - printf("%s size over 24Meg %d\n", __func__, - num_pages * PAGE_SIZE); - kmem_free(kernel_map, va, IMAGE_PREALLOC); - va =3D 0; - } - - if (va =3D=3D 0) { - va =3D kload_kmem_alloc(kernel_map, num_pages * PAGE_SIZE); - if (va =3D=3D 0) - return (ENOMEM); - } - - /* need to set up a START dst page */ - for (i =3D 0; i < num_pages; i++) { - kload_add_page(k_items, - (vtophys(va + (i * PAGE_SIZE)) + KLOADBASE) | KLOAD_SOURCE); - } - printf("%s starting copyin... ", __func__); - *k_items->item =3D KLOAD_DONE; - if ((error =3D copyin(khdr->k_buf, (void *)va, khdr->k_memsz)) !=3D 0) - return (error); - printf("copied %d bytes to va %p done marker at %p\n", - (int)khdr->k_memsz, (void *)va, &k_items->item ); - - return (error); -} - -int -sys_kload(struct thread *td, struct kload_args *uap) -{ - struct region_descriptor *null_idt; - struct kload_cpage *k_cpage; - struct kload kld; - int error =3D 0; - int i; - size_t bufsize =3D uap->buflen; - - error =3D priv_check(td, PRIV_REBOOT); - if (error) - return (error); - - /* - * hook into the shutdown/reboot path so - * we end up here before cpu reset - */ - EVENTHANDLER_REGISTER(shutdown_final, kload_shutdown_final, - NULL, SHUTDOWN_PRI_KLOAD); - - max_addr =3D 0; - min_addr =3D ~0UL; - - if (bufsize !=3D sizeof(struct kload)) { - printf("Hmm size not right %jd %jd\n", (uintmax_t)bufsize, - (uintmax_t)sizeof(struct kload)); - return (error); - } - if ((error =3D copyin(uap->buf, &kld, bufsize)) !=3D 0) - return (error); - - if (k_items =3D=3D NULL) { - if((k_items =3D malloc(sizeof(struct kload_items), - M_KLOAD, M_WAITOK|M_ZERO)) =3D=3D NULL) - return (ENOMEM); - - k_items->head =3D 0; - k_items->head_va =3D 0; - k_items->item =3D &k_items->head; - k_items->last_item =3D &k_items->head; - } - - control_page =3D kload_kmem_alloc(kernel_map, PAGE_SIZE * 2); - k_cpage =3D (struct kload_cpage *)control_page; - code_page =3D control_page + PAGE_SIZE; - - printf("copy from %p kernel_kump to 0x%lx size %d\n", - relocate_kernel, (unsigned long)code_page, relocate_kernel_size)= ; - memset((void *)control_page, 0, PAGE_SIZE * 2); - memcpy((void *)code_page, relocate_kernel, relocate_kernel_size); - - k_cpage->kcp_magic =3D 0xC0DE; - k_cpage->kcp_modulep =3D kld.k_modulep; - k_cpage->kcp_physfree =3D kld.k_physfree; - - mygdt =3D (struct region_descriptor *)kload_kmem_alloc(kernel_map, - PAGE_SIZE); - k_cpage->kcp_gdt =3D (unsigned long)vtophys(mygdt) + KLOADBASE; - - gdt_desc =3D (char *)mygdt + sizeof(struct region_descriptor); - setup_freebsd_gdt(gdt_desc); - mygdt->rd_limit =3D GUEST_GDTR_LIMIT; - mygdt->rd_base =3D (unsigned long)(vtophys(gdt_desc) + KLOADBASE); - - /* - * we pass the virt addr of control_page but we need - * new virt addr as well - */ - k_cpage->kcp_cp =3D (unsigned long)(vtophys(control_page) + KLOADBASE);= - k_cpage->kcp_entry_pt =3D kld.k_entry_pt; - - /* 10 segments should be more than enough */ - for (i =3D 0 ; (i < kld.num_hdrs && i <=3D 10); i++) - kload_copyin_segment(&kld.khdr[i],i); - - null_idt =3D (struct region_descriptor*) - kload_kmem_alloc(kernel_map,PAGE_SIZE); - k_cpage->kcp_idt =3D (unsigned long)vtophys(null_idt) + KLOADBASE; - /* Wipe the IDT. */ - null_idt->rd_limit =3D 0; - null_idt->rd_base =3D 0; - /* - * This must be built after all other allocations so it can - * build a page table entry based on min max addresses - */ - /* returns new page table phys addr */ - pgtbl =3D kload_build_page_table(); - if (pgtbl =3D=3D NULL) - return (ENOMEM); - kload_pgtbl =3D (unsigned long)pgtbl; - k_cpage->kcp_pgtbl =3D (unsigned long)pgtbl; - - kload_ready =3D 1; - - if (bootverbose) - printf("%s:\n\t" - "head_va 0x%lx (phys 0x%lx)\n\t" - "kernbase 0x%lx\n\t" - "code_page 0x%lx (phys 0x%lx)\n\t" - "control_page 0x%lx (phys 0x%lx)\n\t" - "gdt 0x%lx (phys 0x%lx)\n\t" - "idt 0x%lx (phys 0x%lx)\n\t" - "k_entry_pt 0x%lx\n\t" - "pgtbl (phys 0x%lx)\n\t" - "max_addr (phys 0x%lx)\n\t" - "min_addr (phys 0x%lx)\n\t" - "modulep (phys 0x%lx)\n\t" - "physfree (phys 0x%lx)\n", - __func__, - (unsigned long)k_items->head_va, - (unsigned long)vtophys(k_items->head_va), - (unsigned long)(KERNBASE + (vm_paddr_t)kernphys), - (unsigned long)(control_page + PAGE_SIZE), - (unsigned long)vtophys(control_page + PAGE_SIZE), - (unsigned long)control_page, - (unsigned long)vtophys(control_page), - (unsigned long)mygdt,(unsigned long)vtophys(mygdt), - (unsigned long)null_idt,(unsigned long)vtophys(null_idt), - (unsigned long)kld.k_entry_pt, - (unsigned long)pgtbl, - (unsigned long)max_addr, - (unsigned long)min_addr, - (unsigned long)kld.k_modulep, - (unsigned long)kld.k_physfree); - - if(!(uap->flags & (KLOAD_EXEC | KLOAD_REBOOT))) - goto just_load; -#if defined(SMP) - /* - * Bind us to CPU 0 so that all shutdown code runs there. Some - * systems don't shutdown properly (i.e., ACPI power off) if we - * run on another processor. - */ - printf("Binding process to cpu 0\n"); - thread_lock(curthread); - sched_bind(curthread, 0); - thread_unlock(curthread); - KASSERT(PCPU_GET(cpuid) =3D=3D 0, ("%s: not running on cpu 0", __func__= )); -#endif - if(uap->flags & KLOAD_REBOOT) { - mtx_lock(&Giant); - kern_reboot(RB_KLOAD); - /* should not return */ - mtx_unlock(&Giant); - } - /* - * the reboot code will do a module shutdown so it is not - * part kload_shutdown_final but it needs to happen. - * So in the case of exec run it here - */ - if (bootverbose) - printf("%s: module_shutdown\n", __func__); - kload_module_shutdown(); - kload_shutdown_final(NULL, RB_KLOAD); -just_load: - printf("%s: Kernel image loaded waiting for reboot\n", __func__); - return (0); -} - -static void -kload_shutdown_final(void *arg, int howto) -{ - int ret; - cpuset_t map; - - printf("%s arg %p howto 0x%x\n",__FUNCTION__, arg, howto); - - if ((howto & RB_KLOAD) =3D=3D 0) { - printf("%s not a kload reboot\n", __func__); - return; - } - /* Just to make sure we are on cpu 0 */ - KASSERT(PCPU_GET(cpuid) =3D=3D 0, ("%s: not running on cpu 0", __func__= )); - if (kload_ready) { - - printf("%s: suspend APs\n",__FUNCTION__); - map =3D all_cpus; - // we should be bound to cpu 0 at this point - printf("%s cpuid %d\n",__FUNCTION__,PCPU_GET(cpuid)); - CPU_CLR(PCPU_GET(cpuid), &map); - CPU_NAND(&map, &stopped_cpus); - if (!CPU_EMPTY(&map)) { - printf("cpu_reset: Stopping other CPUs\n"); - suspend_cpus(map); - } - - //DELAY(5000000); - - if (bootverbose) - printf("%s: clear all handlers\n", __func__); - intr_clear_all_handlers(); - - if (bootverbose) - printf("%s: loapic_clear_lapic\n", __func__); - lapic_clear_lapic(1); - - intr_suspend(); - - if (bootverbose) - printf("%s disable_interrupts cpuid %d\n", - __func__, PCPU_GET(cpuid)); - disable_intr(); - - printf("calling relocate_kernel\n"); - ret =3D relocate_kernel(vtophys(k_items->head_va) + KLOADBASE, - /* dest addr i.e. overwrite existing kernel */ - KERNBASE + (vm_paddr_t)kernphys, - vtophys(code_page) + KLOADBASE, - control_page); - /* currently this will never happen */ - printf("\trelocate_new_kernel returned %d\n",ret); - } else { - printf("kload_shutdown_final called without " - "a new kernel loaded\n"); - } -} diff --git a/sys/kern/kern_module.c b/sys/kern/kern_module.c index 2a880c5..b769320 100644 --- a/sys/kern/kern_module.c +++ b/sys/kern/kern_module.c @@ -64,7 +64,6 @@ static TAILQ_HEAD(modulelist, module) modules; struct sx modules_sx; static int nextid =3D 1; static void module_shutdown(void *, int); -void kload_module_shutdown(void); =20 static int modevent_nop(module_t mod, int what, void *arg) @@ -108,12 +107,6 @@ module_shutdown(void *arg1, int arg2) } =20 void -kload_module_shutdown(void) { - module_shutdown(NULL, 0); -} - - -void module_register_init(const void *arg) { const moduledata_t *data =3D (const moduledata_t *)arg; diff --git a/sys/kern/syscalls.c b/sys/kern/syscalls.c index 6edd7fa..96f2400 100644 --- a/sys/kern/syscalls.c +++ b/sys/kern/syscalls.c @@ -3,7 +3,7 @@ * * DO NOT EDIT-- this file is automatically generated. * $FreeBSD$ - * created from FreeBSD + * created from FreeBSD: head/sys/kern/syscalls.master 242958 2012-11-13= 12:52:31Z kib=20 */ =20 const char *syscallnames[] =3D { @@ -540,5 +540,4 @@ const char *syscallnames[] =3D { "posix_fallocate", /* 530 =3D posix_fallocate */ "posix_fadvise", /* 531 =3D posix_fadvise */ "wait6", /* 532 =3D wait6 */ - "kload", /* 533 =3D kload */ }; diff --git a/sys/kern/syscalls.master b/sys/kern/syscalls.master index eb2b648..148dea3 100644 --- a/sys/kern/syscalls.master +++ b/sys/kern/syscalls.master @@ -955,7 +955,5 @@ int *status, int options, \ struct __wrusage *wrusage, \ siginfo_t *info); } -533 AUE_NULL STD { int kload(const void *buf, size_t buflen, \ - int flags); } ; Please copy any additions and changes to the following compatability t= ables: ; sys/compat/freebsd32/syscalls.master diff --git a/sys/kern/systrace_args.c b/sys/kern/systrace_args.c index c48057a..c755f92 100644 --- a/sys/kern/systrace_args.c +++ b/sys/kern/systrace_args.c @@ -3286,15 +3286,6 @@ systrace_args(int sysnum, void *params, uint64_t *= uarg, int *n_args) *n_args =3D 6; break; } - /* kload */ - case 533: { - struct kload_args *p =3D params; - uarg[0] =3D (intptr_t) p->buf; /* const void * */ - uarg[1] =3D p->buflen; /* size_t */ - iarg[2] =3D p->flags; /* int */ - *n_args =3D 3; - break; - } default: *n_args =3D 0; break; @@ -8754,22 +8745,6 @@ systrace_entry_setargdesc(int sysnum, int ndx, cha= r *desc, size_t descsz) break; }; break; - /* kload */ - case 533: - switch(ndx) { - case 0: - p =3D "const void *"; - break; - case 1: - p =3D "size_t"; - break; - case 2: - p =3D "int"; - break; - default: - break; - }; - break; default: break; }; @@ -10663,11 +10638,6 @@ systrace_return_setargdesc(int sysnum, int ndx, = char *desc, size_t descsz) if (ndx =3D=3D 0 || ndx =3D=3D 1) p =3D "int"; break; - /* kload */ - case 533: - if (ndx =3D=3D 0 || ndx =3D=3D 1) - p =3D "int"; - break; default: break; }; diff --git a/sys/sys/eventhandler.h b/sys/sys/eventhandler.h index 31aa4e4..6d37bf4 100644 --- a/sys/sys/eventhandler.h +++ b/sys/sys/eventhandler.h @@ -173,7 +173,6 @@ typedef void (*shutdown_fn)(void *, int); #define SHUTDOWN_PRI_FIRST EVENTHANDLER_PRI_FIRST #define SHUTDOWN_PRI_DEFAULT EVENTHANDLER_PRI_ANY #define SHUTDOWN_PRI_LAST EVENTHANDLER_PRI_LAST -#define SHUTDOWN_PRI_KLOAD EVENTHANDLER_PRI_LAST - 100 =20 EVENTHANDLER_DECLARE(shutdown_pre_sync, shutdown_fn); /* before fs sync = */ EVENTHANDLER_DECLARE(shutdown_post_sync, shutdown_fn); /* after fs sync = */ diff --git a/sys/sys/kload.h b/sys/sys/kload.h deleted file mode 100644 index 0920176..0000000 --- a/sys/sys/kload.h +++ /dev/null @@ -1,88 +0,0 @@ -/* - * Copyright (c) 2011 - 2012 - * Russell Cattelan Digital Elves Inc - * Copyright (c)=20 - * Isilon Systems, LLC. All rights reserved. - * - * Redistribution and use in source and binary forms, with or without - * modification, are permitted provided that the following conditions - * are met: - * 1. Redistributions of source code must retain the above copyright - * notice, this list of conditions and the following disclaimer. - * 2. Redistributions in binary form must reproduce the above copyright - * notice, this list of conditions and the following disclaimer in th= e - * documentation and/or other materials provided with the distributio= n. - * - * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AN= D - * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE= - * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PU= RPOSE - * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIAB= LE - * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUE= NTIAL - * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOO= DS - * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)= - * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, S= TRICT - * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY= WAY - * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY O= F - * SUCH DAMAGE. - * - */ - -#ifndef __KLOAD_H__ -#define __KLOAD_H__ - -#include -#include - -#include -#include - -#define KLOAD_LOAD 0 -#define KLOAD_REBOOT (1 << 0 ) -#define KLOAD_EXEC (1 << 1 ) - -struct kload_segment { - void *k_buf; - size_t k_memsz; - unsigned long *k_pages; - unsigned long k_seg_start; -}; - -struct kload { - struct kload_segment khdr[10]; - int num_hdrs; - unsigned long k_entry_pt; - unsigned int k_modulep; - unsigned int k_physfree; -}; - -//typedef u_long kload_item_t; -#define KLOAD_DESTINATION 0x1 -#define KLOAD_INDIRECT 0x2 -#define KLOAD_DONE 0x4 -#define KLOAD_SOURCE 0x8 - -struct kload_items { - unsigned long head; - vm_offset_t head_va; - unsigned long *last_item; - unsigned long *item; - int i_count; - unsigned long flags; /* not used yet */ -}; - -/* - * defined in /kload.c - */ -pt_entry_t * kload_build_page_table(void); -void setup_freebsd_gdt(uint64_t *); -void kload_module_shutdown(void); - -/* - * defined in /kload_exec.S - */ -unsigned long relocate_kernel(unsigned long indirection_page, - unsigned long page_list, unsigned long code_page, - unsigned long control_page); -extern int relocate_kernel_size; - -#endif diff --git a/sys/sys/reboot.h b/sys/sys/reboot.h index 9b70160..6b8e25e 100644 --- a/sys/sys/reboot.h +++ b/sys/sys/reboot.h @@ -59,7 +59,6 @@ #define RB_RESERVED1 0x40000 /* reserved for internal use of boot blocks= */ #define RB_RESERVED2 0x80000 /* reserved for internal use of boot blocks= */ #define RB_PAUSE 0x100000 /* pause after each output line during probe *= / -#define RB_KLOAD 0x200000 /* reboot using kload'ed kernel image */ #define RB_MULTIPLE 0x20000000 /* use multiple consoles */ =20 #define RB_BOOTINFO 0x80000000 /* have `struct bootinfo *' arg */ diff --git a/sys/sys/syscall.h b/sys/sys/syscall.h index f90cad2..6b0cd67 100644 --- a/sys/sys/syscall.h +++ b/sys/sys/syscall.h @@ -3,7 +3,7 @@ * * DO NOT EDIT-- this file is automatically generated. * $FreeBSD$ - * created from FreeBSD + * created from FreeBSD: head/sys/kern/syscalls.master 242958 2012-11-13= 12:52:31Z kib=20 */ =20 #define SYS_syscall 0 @@ -452,5 +452,4 @@ #define SYS_posix_fallocate 530 #define SYS_posix_fadvise 531 #define SYS_wait6 532 -#define SYS_kload 533 -#define SYS_MAXSYSCALL 534 +#define SYS_MAXSYSCALL 533 diff --git a/sys/sys/syscall.mk b/sys/sys/syscall.mk index 39fd05b..25f0470 100644 --- a/sys/sys/syscall.mk +++ b/sys/sys/syscall.mk @@ -1,7 +1,7 @@ # FreeBSD system call names. # DO NOT EDIT-- this file is automatically generated. # $FreeBSD$ -# created from FreeBSD +# created from FreeBSD: head/sys/kern/syscalls.master 242958 2012-11-13 = 12:52:31Z kib=20 MIASM =3D \ syscall.o \ exit.o \ @@ -400,5 +400,4 @@ MIASM =3D \ rctl_remove_rule.o \ posix_fallocate.o \ posix_fadvise.o \ - wait6.o \ - kload.o + wait6.o diff --git a/sys/sys/sysproto.h b/sys/sys/sysproto.h index 81dac15..ef59ad5 100644 --- a/sys/sys/sysproto.h +++ b/sys/sys/sysproto.h @@ -3,7 +3,7 @@ * * DO NOT EDIT-- this file is automatically generated. * $FreeBSD$ - * created from FreeBSD + * created from FreeBSD: head/sys/kern/syscalls.master 242958 2012-11-13= 12:52:31Z kib=20 */ =20 #ifndef _SYS_SYSPROTO_H_ @@ -1762,11 +1762,6 @@ struct wait6_args { char wrusage_l_[PADL_(struct __wrusage *)]; struct __wrusage * wrusage;= char wrusage_r_[PADR_(struct __wrusage *)]; char info_l_[PADL_(siginfo_t *)]; siginfo_t * info; char info_r_[PADR_(= siginfo_t *)]; }; -struct kload_args { - char buf_l_[PADL_(const void *)]; const void * buf; char buf_r_[PADR_(c= onst void *)]; - char buflen_l_[PADL_(size_t)]; size_t buflen; char buflen_r_[PADR_(size= _t)]; - char flags_l_[PADL_(int)]; int flags; char flags_r_[PADR_(int)]; -}; int nosys(struct thread *, struct nosys_args *); void sys_sys_exit(struct thread *, struct sys_exit_args *); int sys_fork(struct thread *, struct fork_args *); @@ -2149,7 +2144,6 @@ int sys_rctl_remove_rule(struct thread *, struct rc= tl_remove_rule_args *); int sys_posix_fallocate(struct thread *, struct posix_fallocate_args *);= int sys_posix_fadvise(struct thread *, struct posix_fadvise_args *); int sys_wait6(struct thread *, struct wait6_args *); -int sys_kload(struct thread *, struct kload_args *); =20 #ifdef COMPAT_43 =20 @@ -2846,7 +2840,6 @@ int freebsd7_shmctl(struct thread *, struct freebsd= 7_shmctl_args *); #define SYS_AUE_posix_fallocate AUE_NULL #define SYS_AUE_posix_fadvise AUE_NULL #define SYS_AUE_wait6 AUE_WAIT6 -#define SYS_AUE_kload AUE_NULL =20 #undef PAD_ #undef PADL_ diff --git a/sys/x86/x86/intr_machdep.c b/sys/x86/x86/intr_machdep.c index eee7678..31cc80b 100644 --- a/sys/x86/x86/intr_machdep.c +++ b/sys/x86/x86/intr_machdep.c @@ -197,37 +197,6 @@ intr_add_handler(const char *name, int vector, drive= r_filter_t filter, } =20 int -intr_clear_all_handlers(void) -{ - int i; - struct intsrc *isrc; - - mtx_lock(&intr_table_lock); - for (i =3D 0; i < NUM_IO_INTS; i++) { - isrc =3D interrupt_sources[i]; - if (isrc !=3D NULL && isrc->is_handlers > 0) { - printf("%s:%d isrc[%d] %p is_handlers %d\n", - __FUNCTION__,__LINE__,i,isrc, - isrc->is_handlers); - isrc->is_handlers--; - if (isrc->is_handlers =3D=3D 0) { - printf("\t dis_source %p dis_intr %p\n", - isrc->is_pic->pic_disable_source, - isrc->is_pic->pic_disable_intr); - isrc->is_pic->pic_disable_source(isrc, PIC_NO_EOI); - isrc->is_pic->pic_disable_intr(isrc); - } - intrcnt_updatename(isrc); - - } - } - mtx_unlock(&intr_table_lock); - return 0; -} - - - -int intr_remove_handler(void *cookie) { struct intsrc *isrc; diff --git a/sys/x86/x86/local_apic.c b/sys/x86/x86/local_apic.c index 6593e8b..e994172 100644 --- a/sys/x86/x86/local_apic.c +++ b/sys/x86/x86/local_apic.c @@ -346,60 +346,6 @@ lapic_dump(const char* str) } =20 void -lapic_clear_lapic(u_int disable) { - - struct lapic *la; - la =3D &lapics[lapic_id()]; - - uint32_t value; - - if (bootverbose) - printf("%s lapic_id(%d) cpu(%d) la %p lapic %p\n",__FUNCTION__, - lapic_id(), PCPU_GET(cpuid), la, lapic); - - /* - * Fist we set the mask bit to keep and new interrupts from - * arriving but allowing any pending interrupts to finish - * *THEN* set the registers to default values - * If the interrupts are not allowed to clear a kload'ed / booted - * kernel will see the old interrupts before the appropriate handlers - * are in place and trigger a panic. - */ -#ifdef notyet - /* this seems to be causing APIC error in the new kernel */ - value =3D lapic->lvt_error; - value |=3D APIC_LVT_M; - lapic->lvt_error =3D value; -#endif - - value =3D lapic->lvt_timer; - value |=3D APIC_LVT_M; - lapic->lvt_timer =3D value; - - value =3D lapic->lvt_lint0; - value |=3D APIC_LVT_M; - lapic->lvt_lint0 =3D value; - - value =3D lapic->lvt_lint1; - value |=3D APIC_LVT_M; - lapic->lvt_lint1 =3D value; - - value =3D lapic->lvt_pcint; - value |=3D APIC_LVT_M; - lapic->lvt_pcint =3D value; - - /* Program timer LVT and setup handler. */ - lapic->lvt_timer =3D APIC_LVTT_M; /* masked */ - lapic->lvt_lint0 =3D APIC_LVT_M; /* masked */ - lapic->lvt_lint1 =3D APIC_LVT_M; /* masked */ - - if (disable) { - printf("\tlapic disable\n"); - lapic_disable(); - } -} - -void lapic_setup(int boot) { struct lapic *la; @@ -978,20 +924,7 @@ lapic_handle_error(void) lapic->esr =3D 0; esr =3D lapic->esr; =20 - printf("CPU%d: local APIC error 0x%x\t", PCPU_GET(cpuid), esr); - if (lapic->esr & APIC_ESR_SEND_CS_ERROR) - printf("send_cs_error\n"); - if (lapic->esr & APIC_ESR_RECEIVE_CS_ERROR) - printf("receive_cs_error\n"); - if (lapic->esr & APIC_ESR_SEND_ACCEPT) - printf("send_accept\n"); - if (lapic->esr & APIC_ESR_RECEIVE_ACCEPT) - printf("receive_accept\n"); - if (lapic->esr & APIC_ESR_SEND_ILLEGAL_VECTOR) - printf("send_illegal_vector\n"); - if (lapic->esr & APIC_ESR_ILLEGAL_REGISTER) - printf("illegal_register\n"); - + printf("CPU%d: local APIC error 0x%x\n", PCPU_GET(cpuid), esr); lapic_eoi(); } =20 diff --git a/sys/x86/x86/nexus.c b/sys/x86/x86/nexus.c index 0b28465..9ead8c8 100644 --- a/sys/x86/x86/nexus.c +++ b/sys/x86/x86/nexus.c @@ -59,7 +59,6 @@ __FBSDID("$FreeBSD$"); #include #include #include -#include =20 #include #include @@ -676,52 +675,6 @@ ram_probe(device_t dev) } =20 static int -smap_hdlr(SYSCTL_HANDLER_ARGS) { - - /* SYSCTL_HANDLER_ARGS - struct sysctl_oid *oidp, void *arg1, - intptr_t arg2, struct sysctl_req *req - */ - - struct bios_smap *smapbase; - caddr_t kmdp; - uint32_t smapsize =3D 0; - - /* Retrieve the system memory map from the loader. */ - kmdp =3D preload_search_by_type("elf kernel"); - if (kmdp =3D=3D NULL) - kmdp =3D preload_search_by_type(ELF_KERN_STR); - if (kmdp !=3D NULL) { - smapbase =3D (struct bios_smap *)preload_search_info(kmdp, - MODINFO_METADATA | MODINFOMD_SMAP); - } else { - smapbase =3D NULL; - goto out; - } - - - printf("%s smapbase %p\n",__FUNCTION__,smapbase); - smapsize =3D *((u_int32_t *)smapbase - 1); - -#if 0 - { - struct bios_smap *smap, *smapend; - smapend =3D (struct bios_smap *)((uintptr_t)smapbase + smapsize); - for (smap =3D smapbase; smap < smapend; smap++) { - printf("\ttype %d base 0x%lx length 0x%lx\n", - smap->type,smap->base, smap->length); - } - } -#endif - -out: - return (sysctl_handle_opaque(oidp, smapbase, smapsize, req)); -} -SYSCTL_PROC(_hw, OID_AUTO, smap, CTLTYPE_OPAQUE|CTLFLAG_RD|CTLFLAG_MPSAF= E, - 0, sizeof(struct bios_smap), smap_hdlr, "S,smap", - "Bios System Map"); - -static int ram_attach(device_t dev) { struct bios_smap *smapbase, *smap, *smapend; diff --git a/usr.sbin/kload/Makefile b/usr.sbin/kload/Makefile deleted file mode 100644 index 0d4a27a..0000000 --- a/usr.sbin/kload/Makefile +++ /dev/null @@ -1,15 +0,0 @@ -# $FreeBSD$ - -PROG=3D kload -SRCS=3D kload.c -NO_MAN=3D - -#DPADD+=3D ${LIBVMMAPI} -#LDADD+=3D -lvmmapi - -WARNS?=3D 3 - -CFLAGS+=3D-I${.CURDIR}/../../sys/boot/userboot -CFLAGS+=3D-I${.CURDIR}/../../sys - -.include diff --git a/usr.sbin/kload/kload.c b/usr.sbin/kload/kload.c deleted file mode 100644 index 51ac3b7..0000000 --- a/usr.sbin/kload/kload.c +++ /dev/null @@ -1,748 +0,0 @@ -/* - * Copyright (c) 2011 - 2012 - * Russell Cattelan Digital Elves Inc - * Copyright (c) 2011 - 2012 - * Isilon Systems, LLC. All rights reserved. - * - * Redistribution and use in source and binary forms, with or without - * modification, are permitted provided that the following conditions - * are met: - * 1. Redistributions of source code must retain the above copyright - * notice, this list of conditions and the following disclaimer. - * 2. Redistributions in binary form must reproduce the above copyright - * notice, this list of conditions and the following disclaimer in th= e - * documentation and/or other materials provided with the distributio= n. - * - * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AN= D - * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE= - * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PU= RPOSE - * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIAB= LE - * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUE= NTIAL - * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOO= DS - * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)= - * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, S= TRICT - * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY= WAY - * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY O= F - * SUCH DAMAGE. - * - */ - -/* - * process kill code borrowed from halt.c - */ - -#include -#include -#include -#include -#include -#include -#include -#include -#include - -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include - -char *host_base =3D "/"; -/* how can we get rid of these? I don't think we need them */ - -struct termios term, oldterm; -char *image; -size_t image_size; -size_t image_max_used =3D 0; -int disk_fd =3D -1; -uint64_t regs[16]; -uint64_t pc; -static int k_execute =3D 0; -static int k_reboot =3D 0; -static void *dl_lib; -typedef void *(*M_func)(size_t bytes, const char *file, int line); -M_func Malloc_func; -static void k_exit(void *, int); -static int shutdown_processes(void); -static u_int get_pageins(void); -static int kload_load_image(void *image,unsigned long entry_pt); - -struct load_file { - int l_isdir; - size_t l_size; - struct stat l_stat; - union { - int fd; - DIR *dir; - } l_u; -}; - -struct smap { - uint64_t base; - uint64_t length; - uint32_t type; -} __packed; - -static int -name2oid(char *name, int *oidp) -{ - int oid[2]; - int i; - size_t j; - - oid[0] =3D 0; - oid[1] =3D 3; - - j =3D CTL_MAXNAME * sizeof(int); - i =3D sysctl(oid, 2, oidp, &j, name, strlen(name)); - if (i < 0) - return (i); - j /=3D sizeof(int); - - return (j); -} - -static void -k_putc(void *arg, int chr) -{ - write(1, &chr, 1); -} - -static int -k_getc(void *arg) -{ - char chr; - if(read(0, &chr, 1) =3D=3D 1) - return (chr); - return (-1); -} - -static int -k_poll(void *arg) -{ - int n; - if (ioctl(0, FIONREAD, &n) >=3D 0) - return (n > 0); - return 0; -} - -static int -k_open(void *arg, const char *filename, void **lf_ret) -{ - struct stat st; - struct load_file *lf; - int error =3D -1; - char path[PATH_MAX]; - - if (!host_base) { - printf("Host base not set\n"); - return (ENOENT); - } - - strlcpy(path, host_base, PATH_MAX); - if (path[strlen(path) - 1] =3D=3D '/') - path[strlen(path) - 1] =3D 0; - strlcat(path, filename, PATH_MAX); - lf =3D malloc(sizeof(struct load_file)); - if (stat(path, &lf->l_stat) < 0) { - error =3D errno; - goto out; - } - - lf->l_size =3D st.st_size; - if (S_ISDIR(lf->l_stat.st_mode)) { - lf->l_isdir =3D 1; - lf->l_u.dir =3D opendir(path); - if (!lf->l_u.dir) { - error =3D EINVAL; - goto out; - } - *lf_ret =3D lf; - return (0); - } - if (S_ISREG(lf->l_stat.st_mode)) { - lf->l_isdir =3D 0; - lf->l_u.fd =3D open(path, O_RDONLY); - if (lf->l_u.fd < 0) { - error =3D EINVAL; - goto out; - } - *lf_ret =3D lf; - return (0); - } - -out: - free(lf); - return (error); -} - -static int -k_close(void *arg, void *h) -{ - struct load_file *lf =3D (struct load_file *)h; - - if (lf->l_isdir) - closedir(lf->l_u.dir); - else - close(lf->l_u.fd); - free(lf); - - return (0); -} - -static int -k_isdir(void *arg, void *h) -{ - return (((struct load_file *)h)->l_isdir); -} - -static int -k_read(void *arg, void *h, void *dst, size_t size, size_t *resid_return)= -{ - struct load_file *lf =3D (struct load_file *)h; - ssize_t sz; - - if (lf->l_isdir) - return (EINVAL); - - if((sz =3D read(lf->l_u.fd, dst, size)) < 0) - return (EINVAL); - *resid_return =3D size - sz; - return (0); -} - -static int -k_readdir(void *arg, void *h, uint32_t *fileno_return, uint8_t *type_ret= urn, - size_t *namelen_return, char *name) -{ - struct load_file *lf =3D (struct load_file *)h; - struct dirent *dp; - - if (!lf->l_isdir) - return (EINVAL); - - dp =3D readdir(lf->l_u.dir); - if (!dp) - return (ENOENT); - - /* - * Note: d_namlen is in the range 0..255 and therefore less - * than PATH_MAX so we don't need to test before copying. - */ - *fileno_return =3D dp->d_fileno; - *type_return =3D dp->d_type; - *namelen_return =3D dp->d_namlen; - memcpy(name, dp->d_name, dp->d_namlen); - name[dp->d_namlen] =3D 0; - - return (0); -} - -static int -k_seek(void *arg, void *h, uint64_t offset, int whence) -{ - struct load_file *lf =3D (struct load_file *)h; - - if (lf->l_isdir) - return (EINVAL); - - if (lseek(lf->l_u.fd, offset, whence) < 0) - return (errno); - - return (0); -} - -static int -k_stat(void *arg, void *h, - int *mode_return, int *uid_return, - int *gid_return, uint64_t *size_return) -{ - - struct load_file *lf =3D (struct load_file *)h; - - *mode_return =3D lf->l_stat.st_mode; - *uid_return =3D lf->l_stat.st_uid; - *gid_return =3D lf->l_stat.st_gid; - *size_return =3D lf->l_stat.st_size; - return (0); -} - -static int -k_diskread(void *arg, int unit, uint64_t offset, void *dst, size_t size,= - size_t *resid_return) -{ - ssize_t n; - - if (unit !=3D 0 || disk_fd =3D=3D -1) - return (EIO); - n =3D pread(disk_fd, dst, size, offset); - if (n < 0) - return (errno); - *resid_return =3D size - n; - return (0); -} - -static int -k_diskioctl(void *arg, int unit, u_long cmd, void *data) -{ - /* not supported on by kload */ - return (ENOTTY); -} - -/* - * This is really confusing since this is not really like doing copyin /= copyout - * in kernel land this will copy the data pointed to by the "from" ptr a= nd copy - * "to" the offset into the load image - */ -static int -k_copy_to_image(void *arg, const void *from, uint64_t to, size_t size) -{ - to &=3D 0x7fffffff; - if (to > image_size) - return (EFAULT); - if (to + size > image_size) { - size =3D image_size - to; - printf("WARNING this should never happen\n"); - } - memcpy(&image[to], from, size); - - if (to + size > image_max_used) - image_max_used =3D to + size; - - return (0); -} - -/* - * copyout is copying FROM the image at "from" offset to memory pointed = to by to - * ptr - */ -static int -k_copy_from_image(void *arg, uint64_t from, void *to, size_t size) -{ - from &=3D 0x7fffffff; - if (from > image_size) - return (EFAULT); - if (from + size > image_size) - size =3D image_size - from; - memcpy(to, &image[from], size); - - return (0); -} - -static void -k_setreg(void *arg, int r, uint64_t v) -{ - if (r < 0 || r >=3D 16) - return; - regs[r] =3D v; -} - -static void -k_setmsr(void *arg, int r, uint64_t v) -{ - /* Unneeded */ -} - -static void -k_setcr(void *arg, int r, uint64_t v) -{ - /* Unneeded */ -} - -static void -k_setgdt(void *arg, uint64_t v, size_t sz) -{ - /* Unneeded */ -} - -static void -k_exec(void *arg, uint64_t entry_pt) -{ -#ifdef DEBUG - printf("Execute at 0x%jx\n", entry_pt); - printf("image size max used %jd endof page %jd\n", image_max_used, - roundup2(image_max_used, PAGE_SIZE)); -#endif - kload_load_image(image, entry_pt); - k_exit(arg, 0); -} - -static void -k_delay(void *arg, int usec) -{ - usleep(usec); -} - -static void -k_exit(void *arg, int v) -{ - tcsetattr(0, TCSAFLUSH, &oldterm); - exit(v); -} - -static void -k_getmem(void *arg, uint64_t *lowmem, uint64_t *highmem) -{ - int mib[2]; - unsigned long long physmem; - size_t len; - - mib[0] =3D CTL_HW; - mib[1] =3D HW_PHYSMEM; - len =3D sizeof(physmem); - sysctl(mib, 2, &physmem, &len, NULL, 0); - - *lowmem =3D physmem; - *highmem =3D 0; - - printf("%s:%d lowmem %ju highmem %ju\n",__FUNCTION__,__LINE__, - *lowmem, - *highmem - ); -} - -static const char * -k_getenv(void *arg, int idx) -{ - static const char *vars[] =3D { - "foo=3Dbar", - "bar=3Dbarbar", - NULL - }; - - return (vars[idx]); -} - -static int -k_buildsmap(void *arg, void **smap_void, size_t *outlen)=20 -{ - struct smap *smapbase; - size_t i,j; - size_t len; - char name[] =3D "hw.smap"; - int mib[CTL_MAXNAME]; - - len =3D name2oid(name, mib); - - /* get the current smap from the running system */ - i =3D sysctl(mib, 2, 0, &j, 0, 0); - len =3D j; - - /* - * Use the malloc function from libstand/userboot.so since - * bios_addsmapdata will free the memory using the libstand Free - * so be careful to use not use standard malloc here - */ - smapbase =3D Malloc_func(j, __FILE__, __LINE__); - if (!smapbase) { - printf("kload failed to allocate space for smap\n"); - return 1; - } - - i =3D sysctl(mib, 2, smapbase, &j, NULL, 0); - - *outlen =3D len; - *smap_void =3D smapbase; - -#ifdef DEBUG - { - struct smap *smap, *smapend; - smapend =3D (struct smap *)((uintptr_t)smapbase + len); - for (smap =3D smapbase; smap < smapend; smap++) { - printf("\ttype %d base 0x%016lx length 0x%016lx\n", - smap->type, smap->base, smap->length); - } - } -#endif - - return 0; -} - -struct loader_callbacks cb =3D { - - .open =3D k_open, - .close =3D k_close, - .isdir =3D k_isdir, - .read =3D k_read, - .readdir =3D k_readdir, - .seek =3D k_seek, - .stat =3D k_stat, - - .diskread =3D k_diskread, - .diskioctl =3D k_diskioctl, - - .copyin =3D k_copy_to_image, - .copyout =3D k_copy_from_image, - .setreg =3D k_setreg, - .setmsr =3D k_setmsr, - .setcr =3D k_setcr, - .setgdt =3D k_setgdt, - .exec =3D k_exec, - - .delay =3D k_delay, - .exit =3D k_exit, - .getmem =3D k_getmem, - - .putc =3D k_putc, - .getc =3D k_getc, - .poll =3D k_poll, - .getenv =3D k_getenv, - .buildsmap =3D k_buildsmap, -}; - -static void -usage(void) -{ - printf("usage: kload [-d ] " - "[-h ] [-e | -r]\n"); - exit(1); -} - -int -main(int argc, char** argv) -{ - int (*loader_main)(struct loader_callbacks *, void *, int, int); - void (*loader_init)(void); - int (*setenv)(const char *, const char *, int); - int opt; - char *disk_image =3D NULL; - char karg[20]; - char kval[128]; - - if (geteuid()) { - errno =3D EPERM; - err(1, NULL); - } - - dl_lib =3D dlopen("/boot/userboot.so", RTLD_LOCAL); - if (!dl_lib) { - printf("%s\n", dlerror()); - return (1); - } - loader_main =3D dlsym(dl_lib, "loader_main"); - if (!loader_main) { - printf("%s\n", dlerror()); - return (1); - } - Malloc_func =3D dlsym(dl_lib, "Malloc"); - if (!Malloc_func) { - printf("%s\n", dlerror()); - return (1); - } - /* - * pull in the libstand setenv for setting name value pairs - * in the kernel env page - */ - setenv =3D dlsym(dl_lib, "setenv"); - if (!setenv) { - printf("%s\n", dlerror()); - return (1); - } - loader_init =3D dlsym(dl_lib, "loader_init"); - if (!loader_init) { - printf("%s\n", dlerror()); - return (1); - } - /* call libstand setheap to init memory allocations */ - loader_init(); - - while ((opt =3D getopt(argc, argv, "d:h:erk:")) !=3D -1) { - switch (opt) { - case 'd': - disk_image =3D optarg; - break; - - case 'h': - host_base =3D optarg; - break; - case 'e': - k_execute =3D 1; - break; - case 'r': - k_reboot =3D 1; - break; - case 'k': - memset(karg,0,sizeof(karg)); - memset(kval,0,sizeof(kval)); - if(sscanf(optarg,"%[a-zA-Z_-]=3D%s",karg,kval) =3D=3D 2) { - printf("got value %s %s\n",karg,kval); - setenv(karg, kval, 1); - } else { - fprintf(stderr,"-k failure %s\n",optarg); - } - break; - - case '?': - usage(); - } - } - - image_size =3D 128*1024*1024; - image =3D malloc(image_size); - if (disk_image) { - disk_fd =3D open(disk_image, O_RDONLY); - if (disk_fd < 0) - err(1, "Can't open disk image '%s'", disk_image); - } - - tcgetattr(0, &term); - oldterm =3D term; - term.c_iflag &=3D ~(ICRNL); - term.c_lflag &=3D ~(ICANON|ECHO); - tcsetattr(0, TCSAFLUSH, &term); - - return(loader_main(&cb, NULL, USERBOOT_VERSION_4, disk_fd >=3D 0)); -} - -static int -kload_load_image(void *image, unsigned long entry_pt) -{ - char *stack =3D (char *)image + 0x1000; /* PAGESIZE */ - struct kload kld; - int flags =3D KLOAD_LOAD; - /* - * This must the same value sys/conf/ldscript.xxx - * This value was changed at one point when a new version - * of binutils was imported. The value is aligned to - * max page size supported by given processor - */ - unsigned long kernphys =3D 0x200000; - - kld.khdr[0].k_buf =3D &((char *)image)[kernphys]; - kld.khdr[0].k_memsz =3D roundup2(image_max_used,PAGE_SIZE) - kernphys; - kld.k_entry_pt =3D entry_pt; - kld.num_hdrs =3D 1; - - /* - * pull paramaters from the stack page - * a better interface should be developed for kload - * in the future - */ - kld.k_modulep =3D ((unsigned int *)stack)[1]; - kld.k_physfree =3D ((unsigned int *)stack)[2]; - - /* - * Make sure there is 4 pages of kenv pages between the end of the - * kernel and start of free memory. - * Why you ask? Well that is a question without a good answer as of yet= - * for some strange reason some ata chips will not respond correctly - * unless free memory starts at greater than 2 pages out. - * The obvoius assumption is that something is getting stommped on but - * that has yet to be determined. Adding this workaround. - */=20 - kld.k_physfree =3D MAX(kld.k_modulep + (4 * PAGE_SIZE), kld.k_physfree)= ; - - printf("WARNING kernphys set to 0x%lx make sure this matches kernphys "= - "from sys/config/ldscript\n", kernphys); - - if (k_execute) { - flags &=3D ~KLOAD_REBOOT; - flags |=3D KLOAD_EXEC; - } - if (k_reboot) { - flags &=3D ~KLOAD_EXEC; - flags |=3D KLOAD_REBOOT; - shutdown_processes(); - } - - return (syscall(SYS_kload, &kld, sizeof(struct kload), flags)); -} - -static int -shutdown_processes(void) -{ - int i; - u_int pageins; - int sverrno; - /* - * Do a sync early on, so disks start transfers while we're off - * killing processes. Don't worry about writes done before the - * processes die, the reboot system call syncs the disks. - */ - sync(); - - /* - * Ignore signals that we can get as a result of killing - * parents, group leaders, etc. - */ - (void)signal(SIGHUP, SIG_IGN); - (void)signal(SIGINT, SIG_IGN); - (void)signal(SIGQUIT, SIG_IGN); - (void)signal(SIGTERM, SIG_IGN); - (void)signal(SIGTSTP, SIG_IGN); - - /* - * If we're running in a pipeline, we don't want to die - * after killing whatever we're writing to. - */ - (void)signal(SIGPIPE, SIG_IGN); - - /* Just stop init -- if we fail, we'll restart it. */ - if (kill(1, SIGTSTP) =3D=3D -1) - err(1, "SIGTSTP init"); - - /* Send a SIGTERM first, a chance to save the buffers. */ - if (kill(-1, SIGTERM) =3D=3D -1 && errno !=3D ESRCH) - err(1, "SIGTERM processes"); - - /* - * After the processes receive the signal, start the rest of the - * buffers on their way. Wait 5 seconds between the SIGTERM and - * the SIGKILL to give everybody a chance. If there is a lot of - * paging activity then wait longer, up to a maximum of approx - * 60 seconds. - */ - sleep(2); - for (i =3D 0; i < 20; i++) { - pageins =3D get_pageins(); - sync(); - sleep(3); - if (get_pageins() =3D=3D pageins) - break; - } - - for (i =3D 1;; ++i) { - if (kill(-1, SIGKILL) =3D=3D -1) { - if (errno =3D=3D ESRCH) - break; - goto restart; - } - if (i > 5) { - (void)fprintf(stderr, - "WARNING: some process(es) wouldn't die\n"); - break; - } - (void)sleep(2 * i); - } - return 1; -restart: - sverrno =3D errno; - errx(1, "%s%s", kill(1, SIGHUP) =3D=3D -1 ? - "(can't restart init): " : "", strerror(sverrno)); - /* NOTREACHED */ - return 0; -} - -static u_int -get_pageins(void) -{ - u_int pageins; - size_t len; - - len =3D sizeof(pageins); - if (sysctlbyname("vm.stats.vm.v_swappgsin", &pageins, &len, NULL, 0) - !=3D 0) { - warnx("v_swappgsin"); - return (0); - } - return (pageins); -} --------------050100010201000009010505-- --------------enigD23560E60788DF043BB39181 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.12 (Darwin) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlCkE5UACgkQNRmM+OaGhBjCHwCfTB6OgmDivWTsCvKHkN7topce 5LwAn0D10AKtwqGA29XqyDBdbW5l4+vD =D75I -----END PGP SIGNATURE----- --------------enigD23560E60788DF043BB39181-- From owner-freebsd-current@FreeBSD.ORG Thu Nov 15 02:46:07 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A4580314 for ; Thu, 15 Nov 2012 02:46:07 +0000 (UTC) (envelope-from alie@affle.com) Received: from mail-vc0-f182.google.com (mail-vc0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 4EC618FC12 for ; Thu, 15 Nov 2012 02:46:06 +0000 (UTC) Received: by mail-vc0-f182.google.com with SMTP id fo13so1576633vcb.13 for ; Wed, 14 Nov 2012 18:46:06 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :x-gm-message-state; bh=uQSCorq3dP1xZvEYoihW8XJp3sw5Fnjb748QkVuzLJ0=; b=olJgFvoB8oKs01ZbVCZYIAPMNcVGnBeDGXW9NA+h20HyzUo0xHDv8ghLMs7Y+mV/60 k8D2On6bi5qfc+lBohfNVEGpC0nCuRAlFPK8U5ZpINlTpFMfh2bEvnq9Hc2Dq3atjg5d QMnRqap21gmsHvFx7sxH1vc+LkgwXDBuaH3D91NemcbD7dKr0YAyIoRIgIb0YQbHcPKY ThgGkDZkOGazl5wbu3yTMtVD14e5JXiiqje5DEO5BX14BxJG3Ub09WaS5ofkuQ3jGAE1 m7Jb9cmc/Tskh6O5WgY9X00U50deEUSj1mwcgFIaBsVIKfHMsMVe7I/ZZRUIOhKqqWbC KFFQ== MIME-Version: 1.0 Received: by 10.221.0.212 with SMTP id nn20mr13988910vcb.32.1352947566084; Wed, 14 Nov 2012 18:46:06 -0800 (PST) Received: by 10.58.178.234 with HTTP; Wed, 14 Nov 2012 18:46:05 -0800 (PST) Date: Thu, 15 Nov 2012 10:46:05 +0800 Message-ID: Subject: Re: Compile FreeBSD kernel with gcc48 From: Alie Tan To: freebsd-current@freebsd.org X-Gm-Message-State: ALoCoQnPdTdVwCr4NNoueOESCngwlb//Uky9CZaxITdi8RqOtLmSeQUIuOVySX3WiwftnESI73D+ Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 02:46:07 -0000 > > On 2012-11-11 10:59, Alie Tan wrote: > > Anyone have experience compiling FreeBSD kernel with gcc48 > > > > I have tried it but no success with this in src.conf > > > > C= /usr/local/bin/gcc48 > > CXX= /usr/local/bin/g++48 > > CWARNFLAGS= -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes > > \-Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual > > \-Wno-pointer-sign -D__FreeBSD_cc_version=0 \-Wno-unused-function > > -Wno-inline -Wno-format \-Wno-uninitialized -Wno-array-bounds > > -Wno-missing-prototypes > > NO_WERROR= 1 > > Last time I tried, I could get it to build with a gcc 4.8 snapshot, but > it failed to boot. I did not investigate a great deal, but it looked a > lot like some sort of optimization bug. Note that gcc 4.8 is still > experimental, so problems like this can be expected. > > However, with gcc 4.7.1, which is a released version, the kernel did > build, and even boot. With that kernel booted, I timed how long a "make > -j8 buildworld" took, compared to booting with kernels compiled by gcc > in base (v4.2.1) and clang in base (v3.2), on different optimization > settings. The raw results are here: > > http://www.andric.com/freebsd/perftest/perftest-kernel-2012-09-25b.txt > > Summary: > - Kernels compiled with clang 3.2 at -O2 are ~8% faster in system time > than kernels compiled with gcc 4.2.1 at -O2. > - Kernels compiled with clang 3.2 at -O2 perform equally to kernels > compiled with gcc 4.7 at -O2, there is no significant difference. > - Kernels compiled with gcc 4.7 at -O3 have a slight advantage in system > time (~3.6%) against kernels compiled with clang 3.2 at -O2. > (I did not test a kernel compiled with clang 3.2 at -O3.) > > > > Another question, is there any benchmark for LLVM/Clang vs gcc45, gcc46, > > gcc47 or gcc48? > > As said, I only tested clang 3.2 against gcc 4.2 from base, and gcc > 4.7.1 (hand-built, since the version from ports is inexplicably some > random snapshot, not a released version). > > If anybody is extremely interested in more results, they should sponsor > some fast hardware, and donate it to the FreeBSD Project. ;-) No idea why since there is no compilation error. It stops at this point: /usr/local/bin/gcc48 -O2 -pipe -O3 -fno-strict-aliasing -pipe -funroll-loops -I/usr/src/lib/libc/include -I/usr/src/lib/libc/../../include -I/usr/src/lib/libc/amd64 -DNLS -D__DBINTERFACE_PRIVATE -I/usr/src/lib/libc/../../contrib/gdtoa -DINET6 -I/usr/obj/usr/src/lib/libc -I/usr/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/usr/src/lib/libc/../../contrib/tzcode/stdtime -I/usr/src/lib/libc/stdtime -I/usr/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/usr/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wno-pointer-sign -D__FreeBSD_cc_version=800001 -Wno-unused-function -Wno-inline -Wsystem-headers -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c nslexer.c -o nslexer.o In file included from /usr/src/lib/libc/net/nslexer.l:49:0: /usr/src/lib/libc/../../include/nsswitch.h:236:14: warning: redundant redeclaration of '_nsyylineno' [-Wredundant-decls] extern int _nsyylineno; And waited for couple of hours still hanging at that point with gcc48 Regards, Alie T From owner-freebsd-current@FreeBSD.ORG Thu Nov 15 04:30:07 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 99923506 for ; Thu, 15 Nov 2012 04:30:07 +0000 (UTC) (envelope-from cattelan@thebarn.com) Received: from x.digitalelves.com (x.digitalelves.com [209.98.77.55]) by mx1.freebsd.org (Postfix) with ESMTP id 188D78FC12 for ; Thu, 15 Nov 2012 04:30:06 +0000 (UTC) Received: from Digital-Elf-6.local (c-66-41-26-220.hsd1.mn.comcast.net [66.41.26.220]) (authenticated bits=0) by x.digitalelves.com (8.14.5/8.14.5) with ESMTP id qAF4Tw7D009840 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Wed, 14 Nov 2012 22:29:59 -0600 (CST) (envelope-from cattelan@thebarn.com) Message-ID: <50A46FC6.9090404@thebarn.com> Date: Wed, 14 Nov 2012 22:29:58 -0600 From: Russell Cattelan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: Anybody willing to test out kload? References: <50A41395.7080205@thebarn.com> In-Reply-To: <50A41395.7080205@thebarn.com> X-Enigmail-Version: 1.4.4 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigEF8640DC65B19FFA7A0B0F0B" X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 04:30:07 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigEF8640DC65B19FFA7A0B0F0B Content-Type: multipart/mixed; boundary="------------010401020106090303040504" This is a multi-part message in MIME format. --------------010401020106090303040504 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable A few people have pointed out I sent out the patch in reverse. :-( I messed up and reversed the tags to git diff. Here is the corrected patch. Along with a few corrections and cleanups. -Russell --------------010401020106090303040504 Content-Type: text/plain; charset=UTF-8; x-mac-type="0"; x-mac-creator="0"; name="kload.patch" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="kload.patch" ZGlmZiAtLWdpdCBhLy5naXRpZ25vcmUgYi8uZ2l0aWdub3JlCm5ldyBmaWxlIG1vZGUgMTAw NjQ0CmluZGV4IDAwMDAwMDAuLmM2MDk2MzMKZGlmZiAtLWdpdCBhL3N5cy9hbWQ2NC9hbWQ2 NC9rbG9hZC5jIGIvc3lzL2FtZDY0L2FtZDY0L2tsb2FkLmMKbmV3IGZpbGUgbW9kZSAxMDA2 NDQKaW5kZXggMDAwMDAwMC4uZWQyMDNhZQotLS0gL2Rldi9udWxsCisrKyBiL3N5cy9hbWQ2 NC9hbWQ2NC9rbG9hZC5jCkBAIC0wLDAgKzEsMTA4IEBACisvKgorICogQ29weXJpZ2h0IChj KSAyMDExIC0gMjAxMgorICoJUnVzc2VsbCBDYXR0ZWxhbiBEaWdpdGFsIEVsdmVzIEluYwor ICogQ29weXJpZ2h0IChjKSAyMDExIC0gMjAxMgorICoJSXNpbG9uIFN5c3RlbXMsIExMQy4g IEFsbCByaWdodHMgcmVzZXJ2ZWQuCisgKgorICogUmVkaXN0cmlidXRpb24gYW5kIHVzZSBp biBzb3VyY2UgYW5kIGJpbmFyeSBmb3Jtcywgd2l0aCBvciB3aXRob3V0CisgKiBtb2RpZmlj YXRpb24sIGFyZSBwZXJtaXR0ZWQgcHJvdmlkZWQgdGhhdCB0aGUgZm9sbG93aW5nIGNvbmRp dGlvbnMKKyAqIGFyZSBtZXQ6CisgKiAxLiBSZWRpc3RyaWJ1dGlvbnMgb2Ygc291cmNlIGNv ZGUgbXVzdCByZXRhaW4gdGhlIGFib3ZlIGNvcHlyaWdodAorICogICAgbm90aWNlLCB0aGlz IGxpc3Qgb2YgY29uZGl0aW9ucyBhbmQgdGhlIGZvbGxvd2luZyBkaXNjbGFpbWVyLgorICog Mi4gUmVkaXN0cmlidXRpb25zIGluIGJpbmFyeSBmb3JtIG11c3QgcmVwcm9kdWNlIHRoZSBh Ym92ZSBjb3B5cmlnaHQKKyAqICAgIG5vdGljZSwgdGhpcyBsaXN0IG9mIGNvbmRpdGlvbnMg YW5kIHRoZSBmb2xsb3dpbmcgZGlzY2xhaW1lciBpbiB0aGUKKyAqICAgIGRvY3VtZW50YXRp b24gYW5kL29yIG90aGVyIG1hdGVyaWFscyBwcm92aWRlZCB3aXRoIHRoZSBkaXN0cmlidXRp b24uCisgKgorICogVEhJUyBTT0ZUV0FSRSBJUyBQUk9WSURFRCBCWSBUSEUgQVVUSE9SIEFO RCBDT05UUklCVVRPUlMgYGBBUyBJUycnIEFORAorICogQU5ZIEVYUFJFU1MgT1IgSU1QTElF RCBXQVJSQU5USUVTLCBJTkNMVURJTkcsIEJVVCBOT1QgTElNSVRFRCBUTywgVEhFCisgKiBJ TVBMSUVEIFdBUlJBTlRJRVMgT0YgTUVSQ0hBTlRBQklMSVRZIEFORCBGSVRORVNTIEZPUiBB IFBBUlRJQ1VMQVIgUFVSUE9TRQorICogQVJFIERJU0NMQUlNRUQuICBJTiBOTyBFVkVOVCBT SEFMTCBUSEUgQVVUSE9SIE9SIENPTlRSSUJVVE9SUyBCRSBMSUFCTEUKKyAqIEZPUiBBTlkg RElSRUNULCBJTkRJUkVDVCwgSU5DSURFTlRBTCwgU1BFQ0lBTCwgRVhFTVBMQVJZLCBPUiBD T05TRVFVRU5USUFMCisgKiBEQU1BR0VTIChJTkNMVURJTkcsIEJVVCBOT1QgTElNSVRFRCBU TywgUFJPQ1VSRU1FTlQgT0YgU1VCU1RJVFVURSBHT09EUworICogT1IgU0VSVklDRVM7IExP U1MgT0YgVVNFLCBEQVRBLCBPUiBQUk9GSVRTOyBPUiBCVVNJTkVTUyBJTlRFUlJVUFRJT04p CisgKiBIT1dFVkVSIENBVVNFRCBBTkQgT04gQU5ZIFRIRU9SWSBPRiBMSUFCSUxJVFksIFdI RVRIRVIgSU4gQ09OVFJBQ1QsIFNUUklDVAorICogTElBQklMSVRZLCBPUiBUT1JUIChJTkNM VURJTkcgTkVHTElHRU5DRSBPUiBPVEhFUldJU0UpIEFSSVNJTkcgSU4gQU5ZIFdBWQorICog T1VUIE9GIFRIRSBVU0UgT0YgVEhJUyBTT0ZUV0FSRSwgRVZFTiBJRiBBRFZJU0VEIE9GIFRI RSBQT1NTSUJJTElUWSBPRgorICogU1VDSCBEQU1BR0UuCisgKgorICovCisKKyNpbmNsdWRl IDxzeXMva2xvYWQuaD4KKyNpbmNsdWRlIDxzeXMvbWFsbG9jLmg+CisjaW5jbHVkZSA8c3lz L3N5c3Byb3RvLmg+CisjaW5jbHVkZSA8c3lzL3N5c3RtLmg+CisKKyNpbmNsdWRlIDx2bS92 bV9wYXJhbS5oPgorI2luY2x1ZGUgPHZtL3ZtLmg+CisjaW5jbHVkZSA8dm0vdm1fZXh0ZXJu Lmg+CisjaW5jbHVkZSA8dm0vdm1fa2Vybi5oPgorCisjZGVmaW5lCUdVRVNUX05VTExfU0VM CQkwCisjZGVmaW5lCUdVRVNUX0NPREVfU0VMCQkxCisjZGVmaW5lCUdVRVNUX0RBVEFfU0VM CQkyCisKK3ZvaWQKK3NldHVwX2ZyZWVic2RfZ2R0KHVpbnQ2NF90ICpnZHRyKQoreworCWdk dHJbR1VFU1RfTlVMTF9TRUxdID0gMHgwMDAwMDAwMDAwMDAwMDAwOworCWdkdHJbR1VFU1Rf Q09ERV9TRUxdID0gMHgwMDIwOTgwMDAwMDAwMDAwOworCWdkdHJbR1VFU1RfREFUQV9TRUxd ID0gMHgwMDAwOTIwMDAwMDAwMDAwOworfQorCitwdF9lbnRyeV90ICoKK2tsb2FkX2J1aWxk X3BhZ2VfdGFibGUodm9pZCkKK3sKKwlwdF9lbnRyeV90ICpQVDQ7CisJcHRfZW50cnlfdCAq UFQzOworCXB0X2VudHJ5X3QgKlBUMjsKKwlpbnQgaTsKKwl1bnNpZ25lZCBsb25nIHZhOwor CisJdmEgPSAodW5zaWduZWQgbG9uZylrbWVtX2FsbG9jKGtlcm5lbF9tYXAsUEFHRV9TSVpF ICogMyk7CisJUFQ0ID0gKHB0X2VudHJ5X3QgKil2YTsKKwlQVDMgPSAocHRfZW50cnlfdCAq KShQVDQgKyAoUEFHRV9TSVpFIC8gc2l6ZW9mKHVuc2lnbmVkIGxvbmcpKSk7CisJUFQyID0g KHB0X2VudHJ5X3QgKikoUFQzICsgKFBBR0VfU0laRSAvIHNpemVvZih1bnNpZ25lZCBsb25n KSkpOworCisJaWYgKGJvb3R2ZXJib3NlKQorCQlwcmludGYoIiVzIFBUNCAweCVseCAoMHgl bHgpIFBUMyAweCVseCAoMHglbHgpICIKKwkJICAgICJQVDIgMHglbHggKDB4JWx4KVxuIiwK KwkJICAgIF9fZnVuY19fLAorCQkgICAgKHVuc2lnbmVkIGxvbmcpUFQ0LCAodW5zaWduZWQg bG9uZyl2dG9waHlzKFBUNCksCisJCSAgICAodW5zaWduZWQgbG9uZylQVDMsICh1bnNpZ25l ZCBsb25nKXZ0b3BoeXMoUFQzKSwKKwkJICAgICh1bnNpZ25lZCBsb25nKVBUMiwgKHVuc2ln bmVkIGxvbmcpdnRvcGh5cyhQVDIpKTsKKworCS8qCisJICogVGhlIGZvbGxvd2luZyBzZWN0 aW9uIGlzIGEgZGlyZWN0IGNvcHkgb2YKKwkgKiBoZWFkL3NyYy9zeXMvYm9vdC9pMzg2L2xp YmkzODYvZWxmNjRfZnJlZWJzZC5jOjkyIGF0IHIyMzY2ODgKKwkgKi8KKworCWJ6ZXJvKFBU NCwgUEFHRV9TSVpFKTsKKwliemVybyhQVDMsIFBBR0VfU0laRSk7CisJYnplcm8oUFQyLCBQ QUdFX1NJWkUpOworCisJLyoKKwkgKiBUaGlzIGlzIGtpbmRhIGJydXRhbCwgYnV0IGV2ZXJ5 IHNpbmdsZSAxR0IgVk0gbWVtb3J5IHNlZ21lbnQgcG9pbnRzCisJICogdG8gdGhlIHNhbWUg Zmlyc3QgMUdCIG9mIHBoeXNpY2FsIG1lbW9yeS4gIEJ1dCBpdCBpcyBtb3JlIHRoYW4KKwkg KiBhZGVxdWF0ZS4KKwkgKi8KKwlmb3IgKGkgPSAwOyBpIDwgNTEyOyBpKyspIHsKKwkJLyoK KwkJICogRWFjaCBzbG90IG9mIHRoZSBsZXZlbCA0IHBhZ2VzIHBvaW50cyB0byB0aGUKKwkJ ICogc2FtZSBsZXZlbCAzIHBhZ2UKKwkJICovCisJCVBUNFtpXSA9IChwdF9lbnRyeV90KSh2 dG9waHlzKFBUMykpOworCQlQVDRbaV0gfD0gUEdfViB8IFBHX1JXIHwgUEdfVTsKKworCQkv KgorCQkgKiBFYWNoIHNsb3Qgb2YgdGhlIGxldmVsIDMgcGFnZXMgcG9pbnRzIHRvIHRoZQor CQkgKiBzYW1lIGxldmVsIDIgcGFnZQorCQkgKi8KKwkJUFQzW2ldID0gKHB0X2VudHJ5X3Qp KHZ0b3BoeXMoUFQyKSk7CisJCVBUM1tpXSB8PSBQR19WIHwgUEdfUlcgfCBQR19VOworCisJ CS8qIFRoZSBsZXZlbCAyIHBhZ2Ugc2xvdHMgYXJlIG1hcHBlZCB3aXRoIDJNQiBwYWdlcyBm b3IgMUdCLiAqLworCQlQVDJbaV0gPSBpICogKDIgKiAxMDI0ICogMTAyNCk7CisJCVBUMltp XSB8PSBQR19WIHwgUEdfUlcgfCBQR19QUyB8IFBHX1U7CisJfQorCXJldHVybiAoKHB0X2Vu dHJ5X3QgKil2dG9waHlzKFBUNCkpOworfQpkaWZmIC0tZ2l0IGEvc3lzL2FtZDY0L2FtZDY0 L2tsb2FkX2V4ZWMuUyBiL3N5cy9hbWQ2NC9hbWQ2NC9rbG9hZF9leGVjLlMKbmV3IGZpbGUg bW9kZSAxMDA2NDQKaW5kZXggMDAwMDAwMC4uNzViZmYzYgotLS0gL2Rldi9udWxsCisrKyBi L3N5cy9hbWQ2NC9hbWQ2NC9rbG9hZF9leGVjLlMKQEAgLTAsMCArMSwxODAgQEAKKy8qCisg KiBDb3B5cmlnaHQgKGMpIDIwMTEgLSAyMDEyCisgKglSdXNzZWxsIENhdHRlbGFuIERpZ2l0 YWwgRWx2ZXMgSW5jCisgKiBDb3B5cmlnaHQgKGMpIDIwMTEgLSAyMDEyCisgKglJc2lsb24g U3lzdGVtcywgTExDLiAgQWxsIHJpZ2h0cyByZXNlcnZlZC4KKyAqCisgKiBSZWRpc3RyaWJ1 dGlvbiBhbmQgdXNlIGluIHNvdXJjZSBhbmQgYmluYXJ5IGZvcm1zLCB3aXRoIG9yIHdpdGhv dXQKKyAqIG1vZGlmaWNhdGlvbiwgYXJlIHBlcm1pdHRlZCBwcm92aWRlZCB0aGF0IHRoZSBm b2xsb3dpbmcgY29uZGl0aW9ucworICogYXJlIG1ldDoKKyAqIDEuIFJlZGlzdHJpYnV0aW9u cyBvZiBzb3VyY2UgY29kZSBtdXN0IHJldGFpbiB0aGUgYWJvdmUgY29weXJpZ2h0CisgKiAg ICBub3RpY2UsIHRoaXMgbGlzdCBvZiBjb25kaXRpb25zIGFuZCB0aGUgZm9sbG93aW5nIGRp c2NsYWltZXIuCisgKiAyLiBSZWRpc3RyaWJ1dGlvbnMgaW4gYmluYXJ5IGZvcm0gbXVzdCBy ZXByb2R1Y2UgdGhlIGFib3ZlIGNvcHlyaWdodAorICogICAgbm90aWNlLCB0aGlzIGxpc3Qg b2YgY29uZGl0aW9ucyBhbmQgdGhlIGZvbGxvd2luZyBkaXNjbGFpbWVyIGluIHRoZQorICog ICAgZG9jdW1lbnRhdGlvbiBhbmQvb3Igb3RoZXIgbWF0ZXJpYWxzIHByb3ZpZGVkIHdpdGgg dGhlIGRpc3RyaWJ1dGlvbi4KKyAqCisgKiBUSElTIFNPRlRXQVJFIElTIFBST1ZJREVEIEJZ IFRIRSBBVVRIT1IgQU5EIENPTlRSSUJVVE9SUyBgYEFTIElTJycgQU5ECisgKiBBTlkgRVhQ UkVTUyBPUiBJTVBMSUVEIFdBUlJBTlRJRVMsIElOQ0xVRElORywgQlVUIE5PVCBMSU1JVEVE IFRPLCBUSEUKKyAqIElNUExJRUQgV0FSUkFOVElFUyBPRiBNRVJDSEFOVEFCSUxJVFkgQU5E IEZJVE5FU1MgRk9SIEEgUEFSVElDVUxBUiBQVVJQT1NFCisgKiBBUkUgRElTQ0xBSU1FRC4g IElOIE5PIEVWRU5UIFNIQUxMIFRIRSBBVVRIT1IgT1IgQ09OVFJJQlVUT1JTIEJFIExJQUJM RQorICogRk9SIEFOWSBESVJFQ1QsIElORElSRUNULCBJTkNJREVOVEFMLCBTUEVDSUFMLCBF WEVNUExBUlksIE9SIENPTlNFUVVFTlRJQUwKKyAqIERBTUFHRVMgKElOQ0xVRElORywgQlVU IE5PVCBMSU1JVEVEIFRPLCBQUk9DVVJFTUVOVCBPRiBTVUJTVElUVVRFIEdPT0RTCisgKiBP UiBTRVJWSUNFUzsgTE9TUyBPRiBVU0UsIERBVEEsIE9SIFBST0ZJVFM7IE9SIEJVU0lORVNT IElOVEVSUlVQVElPTikKKyAqIEhPV0VWRVIgQ0FVU0VEIEFORCBPTiBBTlkgVEhFT1JZIE9G IExJQUJJTElUWSwgV0hFVEhFUiBJTiBDT05UUkFDVCwgU1RSSUNUCisgKiBMSUFCSUxJVFks IE9SIFRPUlQgKElOQ0xVRElORyBORUdMSUdFTkNFIE9SIE9USEVSV0lTRSkgQVJJU0lORyBJ TiBBTlkgV0FZCisgKiBPVVQgT0YgVEhFIFVTRSBPRiBUSElTIFNPRlRXQVJFLCBFVkVOIElG IEFEVklTRUQgT0YgVEhFIFBPU1NJQklMSVRZIE9GCisgKiBTVUNIIERBTUFHRS4KKyAqCisg Ki8KKworI2luY2x1ZGUgImFzc3ltLnMiCisKKyNkZWZpbmUJQ1IwX1BHCTB4ODAwMDAwMDAJ LyogUGFHaW5nIGVuYWJsZSAqLworCisjZGVmaW5lIFg4Nl9DUjBfUEUJMHgwMDAwMDAwMSAv KiBQcm90ZWN0aW9uIEVuYWJsZSAqLworI2RlZmluZSBYODZfQ1IwX01QCTB4MDAwMDAwMDIg LyogTW9uaXRvciBDb3Byb2Nlc3NvciAqLworI2RlZmluZSBYODZfQ1IwX0VNCTB4MDAwMDAw MDQgLyogRW11bGF0aW9uICovCisjZGVmaW5lIFg4Nl9DUjBfVFMJMHgwMDAwMDAwOCAvKiBU YXNrIFN3aXRjaGVkICovCisjZGVmaW5lIFg4Nl9DUjBfRVQJMHgwMDAwMDAxMCAvKiBFeHRl bnNpb24gVHlwZSAqLworI2RlZmluZSBYODZfQ1IwX05FCTB4MDAwMDAwMjAgLyogTnVtZXJp YyBFcnJvciAqLworI2RlZmluZSBYODZfQ1IwX1dQCTB4MDAwMTAwMDAgLyogV3JpdGUgUHJv dGVjdCAqLworI2RlZmluZSBYODZfQ1IwX0FNCTB4MDAwNDAwMDAgLyogQWxpZ25tZW50IE1h c2sgKi8KKyNkZWZpbmUgWDg2X0NSMF9OVwkweDIwMDAwMDAwIC8qIE5vdCBXcml0ZS10aHJv dWdoICovCisjZGVmaW5lIFg4Nl9DUjBfQ0QJMHg0MDAwMDAwMCAvKiBDYWNoZSBEaXNhYmxl ICovCisjZGVmaW5lIFg4Nl9DUjBfUEcJMHg4MDAwMDAwMCAvKiBQYWdpbmcgKi8KKworI2Rl ZmluZSBYODZfQ1I0X1BTRQkweDAwMDAwMDEwIC8qIGVuYWJsZSBwYWdlIHNpemUgZXh0ZW5z aW9ucyAqLworI2RlZmluZSBYODZfQ1I0X1BBRQkweDAwMDAwMDIwIC8qIGVuYWJsZSBwaHlz aWNhbCBhZGRyZXNzIGV4dGVuc2lvbnMgKi8KKworCS5nbG9ibCByZWxvY2F0ZV9rZXJuZWwK K3JlbG9jYXRlX2tlcm5lbDoKKwkvKiBmaXJzdCBpbnN0YWxsIHRoZSBuZXcgcGFnZSB0YWJs ZSAqLworCW1vdnEJMzIoJXJjeCksICVyYXggLyogcGFnZSB0YWJsZSAqLworCW1vdnEJNDAo JXJjeCksICVyOSAgLyogYWRkcmVzcyBvZiBjb250cm9sX3BhZ2Ugd2l0aCBuZXcgUFQgKi8K Kwltb3ZxCSVyYXgsICVjcjMKKworCS8qCisJICogU2V0IGNyNCB0byBhIGtub3duIHN0YXRl OgorCSAqICAtIHBhZ2Ugc2l6ZSBleHRlbnNpb25zCisJICogIC0gcGh5c2ljYWwgYWRkcmVz cyBleHRlbnNpb24gZW5hYmxlZAorCSAqLworCW1vdnEJJChYODZfQ1I0X1BTRSB8IFg4Nl9D UjRfUEFFKSwgJXJheAorCW1vdnEJJXJheCwgJWNyNAorCisJLyogdGhlbiBtb3ZlIHRoZSBz dGFjayB0byB0aGUgZW5kIG9mIGNvbnRyb2wgcGFnZSAqLworCWxlYSA0MDk2KCVyOSksICVy c3AKKworCS8qIG5vdyBzYXZlIHN0dWZmIG9udG8gdGhlIG5ldyBzdGFjayAqLworCXB1c2hx CSVyY3gJLyogYXJnIDQgY29udHJvbCBwYWdlICovCisJcHVzaHEJJXJkeAkvKiBhcmcgMyBj b2RlIHBhZ2UgKi8KKwlwdXNocQklcnNpCS8qIGFyZyAyIGtlcm4gYmFzZSAqLworCXB1c2hx CSVyZGkJLyogYXJnIDEgdmFfbGlzdCAqLworCisJLyogemVybyBvdXQgZmxhZ3MsIGFuZCBk aXNhYmxlIGludGVycnVwdHMgKi8KKwlwdXNocSAkMAorCXBvcGZxCisJY2xpCisKKwkvKiBp bnN0YWxsIHNpbXBsZSBnZHQgKi8KKwltb3ZxCTI0KCVyOSksICVyYXgJLyogZ2R0ICovCisJ bGdkdAkoJXJheCkKKwltb3ZxCTU2KCVyOSksICVyYXgKKwlsaWR0CSglcmF4KQkJLyogbnVs bCBpZHQgKi8KKwkvKgorCSAqIG5vdyBtb3ZlIHRvIHRoZSBjb2RlIHBhZ2UKKwkgKiBzaG91 bGQgaGF2ZSBiZWVuIHBhc3NlZCBjb2RlX3BhZ2UgYmFzZWQKKwkgKiBvbiBuZXcgcGFnZSB0 YWJsZQorCSAqLworCW1vdnEgJXJkeCwgJXI4CisJYWRkcQkkKGlkZW50aXR5X21hcHBlZCAt IHJlbG9jYXRlX2tlcm5lbCksICVyOAorCS8qIG9mZnNldCBvZiBjb2RlIHNlZ21lbnQgaW4g bmV3IGdkdCAqLworCXB1c2hxICQweDA4CisJcHVzaHEgJXI4CisJLyoganVtcCB0byB0aGlz IHNwb3QgaW4gdGhlIG5ldyBwYWdlICovCisJbHJldHEKK2lkZW50aXR5X21hcHBlZDoKKwor CW1vdnEgJDB4MTAsJXJheAorCW1vdnEgJXJheCwlZHMKKwltb3ZxICVyYXgsJWVzCisJbW92 cSAlcmF4LCVmcworCW1vdnEgJXJheCwlZ3MKKwltb3ZxICVyYXgsJXNzCisJCisJLyoKKwkg KiBTZXQgY3IwIHRvIGEga25vd24gc3RhdGU6CisJICogIC0gUGFnaW5nIGVuYWJsZWQKKwkg KiAgLSBBbGlnbm1lbnQgY2hlY2sgZGlzYWJsZWQKKwkgKiAgLSBXcml0ZSBwcm90ZWN0IGRp c2FibGVkCisJICogIC0gTm8gdGFzayBzd2l0Y2gKKwkgKiAgLSBEb24ndCBkbyBGUCBzb2Z0 d2FyZSBlbXVsYXRpb24uCisJICogIC0gUHJvY3RlY3RlZCBtb2RlIGVuYWJsZWQKKwkgKi8K Kwltb3ZxCSVjcjAsICVyYXgKKwlhbmRxCSR+KFg4Nl9DUjBfQU0gfCBYODZfQ1IwX1dQIHwg WDg2X0NSMF9UUyB8IFg4Nl9DUjBfRU0gfCAgWDg2X0NSMF9NUCB8IFg4Nl9DUjBfTkUpLCAl cmF4CisJb3JsCSQoWDg2X0NSMF9QRyB8IFg4Nl9DUjBfUEUpLCAlZWF4CisJbW92cQklcmF4 LCAlY3IwCisKKwkvKiBEbyB0aGUgY29waWVzICovCisJY2xkCisJLyogc2F2ZWQgbGlzdCBv ZiBzb3VyY2UgcGFnZXMgKi8KKwltb3ZxIDAoJXJzcCksICVyYngKKwkvKgorCSAqIHRoZSBp bml0aWFsIGRlc3QgcGFnZQorCSogdGhpcyBpcyBLRVJOQkFTRSArIDB4MjAwMDAwCisJKiBr ZXJuZWwgaXMgY29udGlnaW91cyBpbiBtZW1vcnkKKwkqLworCW1vdnEgOCglcnNwKSwgJXJk aQorMDoJLyogdG9wLCByZWFkIGFub3RoZXIgd29yZCBmb3IgdGhlIGluZGlyZWN0aW9uIHBh Z2UgKi8KKwltb3ZxCSglcmJ4KSwgJXJjeAorCisJYWRkcQkkOCwgJXJieAorCXRlc3RxCSQw eDEsICAgJXJjeCAgLyogaXMgaXQgYSBkZXN0aW5hdGlvbiBwYWdlICovCisJanoJMWYKKwlt b3ZxCSVyY3gsCSVyZGkKKwlhbmRxCSQweEZGRkZGRkZGZmZmZmYwMDAsICVyZGkKKwlqbXAg ICAgIDBiCisxOgorCXRlc3RxCSQweDIsCSVyY3ggIC8qIGlzIGl0IGFuIGluZGlyZWN0aW9u IHBhZ2UgKi8KKwlqegkxZgorCW1vdnEJJXJjeCwJJXJieAorCWFuZHEJJDB4RkZGRkZGRkZm ZmZmZjAwMCwgJXJieAorCWptcCAgICAgMGIKKzE6CisJdGVzdHEgICAkMHg0LCAgICVyY3gg LyogaXMgaXQgdGhlIGRvbmUgaW5kaWNhdG9yICovCisJanogICAgICAxZgorCWptcCAgICAg MmYKKzE6CisJdGVzdHEgICAkMHg4LCAgICVyY3ggLyogaXMgaXQgdGhlIHNvdXJjZSBpbmRp Y2F0b3IgKi8KKwlqeiAgICAgIDBiCSAgICAgLyogSWdub3JlIGl0IG90aGVyd2lzZSAqLwor CW1vdnEgICAgJXJjeCwgICAlcnNpIC8qIEZvciBldmVyeSBzb3VyY2UgcGFnZSBkbyBhIGNv cHkgKi8KKwlhbmRxICAgICQweGZmZmZmZmZmZmZmZmYwMDAsICVyc2kKKwltb3ZxICAgICQ1 MTIsICVyY3gKKwlyZXAKKwltb3ZzcQorCWptcCAgICAgMGIKKzI6CisJLyoKKwkgKiBzZXQg YWxsIG9mIHRoZSByZWdpc3RlcnMgdG8ga25vd24gdmFsdWVzCisJICogbGVhdmUgJXJzcCBh bG9uZQorCSAqLworCXhvcnEJJXJheCwgJXJheAorCXhvcnEJJXJieCwgJXJieAorCXhvcnEg ICAgJXJjeCwgJXJjeAorCXhvcnEgICAgJXJkeCwgJXJkeAorCXhvcnEgICAgJXJzaSwgJXJz aQorCXhvcnEgICAgJXJkaSwgJXJkaQorCXhvcnEgICAgJXJicCwgJXJicAorCisJcHVzaHEJ MTYoJXI5KQkvKiBwaHlzZnJlZSAqLworCW1vdnEJOCglcjkpLCAlcmF4CS8qIG1vZHVsZXAg Ki8KKwlzYWxxCSQzMiwgJXJheAorCXB1c2hxCSVyYXgKKworCXB1c2hxICQweDgKKwlwdXNo cQk0OCglcjkpCS8qIGVudHJ5ICMga2VybmVsIGVudHJ5IHB0ICovCisJbHJldHEKK3JlbG9j YXRlX2tlcm5lbF9lbmQ6CisJLmdsb2JsIHJlbG9jYXRlX2tlcm5lbF9zaXplCityZWxvY2F0 ZV9rZXJuZWxfc2l6ZToKKwkubG9uZyByZWxvY2F0ZV9rZXJuZWxfZW5kIC0gcmVsb2NhdGVf a2VybmVsCmRpZmYgLS1naXQgYS9zeXMvYW1kNjQvYW1kNjQvbXBfbWFjaGRlcC5jIGIvc3lz L2FtZDY0L2FtZDY0L21wX21hY2hkZXAuYwppbmRleCBkMmU0YWFkLi5iMDg1MzI2IDEwMDY0 NAotLS0gYS9zeXMvYW1kNjQvYW1kNjQvbXBfbWFjaGRlcC5jCisrKyBiL3N5cy9hbWQ2NC9h bWQ2NC9tcF9tYWNoZGVwLmMKQEAgLTc4LDYgKzc4LDkgQEAgX19GQlNESUQoIiRGcmVlQlNE JCIpOwogI2RlZmluZSBCSU9TX1JFU0VUCQkoMHgwZikKICNkZWZpbmUgQklPU19XQVJNCQko MHgwYSkKIAorCisvLyBxdWljayBoYWNrIHRvIGFjY2VzcyB0aGUga2xvYWQgcGFnZSB0YWJs ZSBzbyB3ZSBjYW4gc2V0IHRoZSBBUHMgdG8gYSBrbm93IHBndGJsICovCitleHRlcm4gdW5z aWduZWQgbG9uZyBrbG9hZF9wZ3RibDsKIC8qIGxvY2sgcmVnaW9uIHVzZWQgYnkga2VybmVs IHByb2ZpbGluZyAqLwogaW50CW1jb3VudF9sb2NrOwogCkBAIC0xNDA5LDEwICsxNDEyLDIw IEBAIGNwdXN0b3BfaGFuZGxlcih2b2lkKQogdm9pZAogY3B1c3VzcGVuZF9oYW5kbGVyKHZv aWQpCiB7CisJcmVnaXN0ZXJfdCBjcjMsIHJmOworCXJlZ2lzdGVyX3QgY3IwLCBjcjQ7CiAJ dV9pbnQgY3B1OwogCiAJY3B1ID0gUENQVV9HRVQoY3B1aWQpOwogCisJcHJpbnRmKCIlcyBj YWxsZWQgb24gY3B1JWRcbiIsX19GVU5DVElPTl9fLGNwdSk7CisKKwlyZiA9IGludHJfZGlz YWJsZSgpOworCWNyMyA9IHJjcjMoKTsKKworCWxhcGljX2NsZWFyX2xhcGljKDEgLyogZGlz YWJsZSBsYXBpYyAqLyk7CisgCS8qIHNodXRkb3duIGludGVycnVwdHMgdG8gdGhlIGNwdSBh bmQgdGhlbiBzZXQgdGhlIG1hc2sgYXMgc3RvcHBlZCAqLworCiAJaWYgKHNhdmVjdHgoc3Vz cHBjYnNbY3B1XSkpIHsKIAkJY3R4X2ZwdXNhdmUoc3VzcHBjYnNbY3B1XS0+cGNiX2ZwdXN1 c3BlbmQpOwogCQl3YmludmQoKTsKQEAgLTE0MjIsMjAgKzE0MzUsMzcgQEAgY3B1c3VzcGVu ZF9oYW5kbGVyKHZvaWQpCiAJCWluaXRpYWxpemVjcHUoKTsKIAkJUENQVV9TRVQoc3dpdGNo dGltZSwgMCk7CiAJCVBDUFVfU0VUKHN3aXRjaHRpY2tzLCB0aWNrcyk7Ci0KLQkJLyogSW5k aWNhdGUgdGhhdCB3ZSBhcmUgcmVzdW1lZCAqLwotCQlDUFVfQ0xSX0FUT01JQyhjcHUsICZz dXNwZW5kZWRfY3B1cyk7CiAJfQogCisJLyogbWFrZSBzdXJlIHRoZSBwYWdlIHRhYmxlIGlz IG5vdCB0aGUgc2FtZSBvbmUgdGhhdCBib290IHByb2Nlc3Mgc2V0cyB1cCAqLworCWxvYWRf Y3IzKGtsb2FkX3BndGJsKTsKKworCS8qIERpc2FibGUgUEdFLiAqLworCWNyNCA9IHJjcjQo KTsKKwlsb2FkX2NyNChjcjQgJiB+Q1I0X1BHRSk7CisKKwkvKiBEaXNhYmxlIGNhY2hlcyAo Q0QgPSAxLCBOVyA9IDApIGFuZCBwYWdpbmcqLworCWNyMCA9IHJjcjAoKTsKKwlsb2FkX2Ny MCgoY3IwICYgfkNSMF9OVykgfCBDUjBfQ0QgfCBDUjBfUEcpOworCisJLyogRmx1c2hlcyBj YWNoZXMgYW5kIFRMQnMuICovCisJd2JpbnZkKCk7CisJaW52bHRsYigpOworCisJaGFsdCgp OworCiAJLyogV2FpdCBmb3IgcmVzdW1lICovCiAJd2hpbGUgKCFDUFVfSVNTRVQoY3B1LCAm c3RhcnRlZF9jcHVzKSkKIAkJaWEzMl9wYXVzZSgpOwogCiAJQ1BVX0NMUl9BVE9NSUMoY3B1 LCAmc3RhcnRlZF9jcHVzKTsKKwlDUFVfQ0xSX0FUT01JQyhjcHUsICZzdG9wcGVkX2NwdXMp OwogCi0JLyogUmVzdW1lIE1DQSBhbmQgbG9jYWwgQVBJQyAqLworCS8qIFJlc3RvcmUgQ1Iz IGFuZCBlbmFibGUgaW50ZXJydXB0cyAqLworCWxvYWRfY3IzKGNyMyk7CiAJbWNhX3Jlc3Vt ZSgpOwogCWxhcGljX3NldHVwKDApOworCWludHJfcmVzdG9yZShyZik7CiB9CiAKIC8qCmRp ZmYgLS1naXQgYS9zeXMvYW1kNjQvaW5jbHVkZS9hcGljdmFyLmggYi9zeXMvYW1kNjQvaW5j bHVkZS9hcGljdmFyLmgKaW5kZXggYWUyZjViOS4uN2ZkZWQ5NSAxMDA2NDQKLS0tIGEvc3lz L2FtZDY0L2luY2x1ZGUvYXBpY3Zhci5oCisrKyBiL3N5cy9hbWQ2NC9pbmNsdWRlL2FwaWN2 YXIuaApAQCAtMjI3LDYgKzIyNyw3IEBAIGludAlsYXBpY19zZXRfbHZ0X3RyaWdnZXJtb2Rl KHVfaW50IGFwaWNfaWQsIHVfaW50IGx2dCwKIAkgICAgZW51bSBpbnRyX3RyaWdnZXIgdHJp Z2dlcik7CiB2b2lkCWxhcGljX3NldF90cHIodV9pbnQgdmVjdG9yKTsKIHZvaWQJbGFwaWNf c2V0dXAoaW50IGJvb3QpOwordm9pZAlsYXBpY19jbGVhcl9sYXBpYyh1X2ludCk7CiAKICNl bmRpZiAvKiAhTE9DT1JFICovCiAjZW5kaWYgLyogX01BQ0hJTkVfQVBJQ1ZBUl9IXyAqLwpk aWZmIC0tZ2l0IGEvc3lzL2FtZDY0L2luY2x1ZGUvaW50cl9tYWNoZGVwLmggYi9zeXMvYW1k NjQvaW5jbHVkZS9pbnRyX21hY2hkZXAuaAppbmRleCA3MDBlMzVmLi5hOGVmMWZjIDEwMDY0 NAotLS0gYS9zeXMvYW1kNjQvaW5jbHVkZS9pbnRyX21hY2hkZXAuaAorKysgYi9zeXMvYW1k NjQvaW5jbHVkZS9pbnRyX21hY2hkZXAuaApAQCAtMTU4LDYgKzE1OCw3IEBAIHN0cnVjdCBp bnRzcmMgKmludHJfbG9va3VwX3NvdXJjZShpbnQgdmVjdG9yKTsKIGludAlpbnRyX3JlZ2lz dGVyX3BpYyhzdHJ1Y3QgcGljICpwaWMpOwogaW50CWludHJfcmVnaXN0ZXJfc291cmNlKHN0 cnVjdCBpbnRzcmMgKmlzcmMpOwogaW50CWludHJfcmVtb3ZlX2hhbmRsZXIodm9pZCAqY29v a2llKTsKK2ludAlpbnRyX2NsZWFyX2FsbF9oYW5kbGVycyh2b2lkKTsKIHZvaWQJaW50cl9y ZXN1bWUodm9pZCk7CiB2b2lkCWludHJfc3VzcGVuZCh2b2lkKTsKIHZvaWQJaW50cmNudF9h ZGQoY29uc3QgY2hhciAqbmFtZSwgdV9sb25nICoqY291bnRwKTsKZGlmZiAtLWdpdCBhL3N5 cy9ib290L2NvbW1vbi9sb2FkX2VsZi5jIGIvc3lzL2Jvb3QvY29tbW9uL2xvYWRfZWxmLmMK aW5kZXggZTFlNmRlNy4uMzZkZjIyYyAxMDA2NDQKLS0tIGEvc3lzL2Jvb3QvY29tbW9uL2xv YWRfZWxmLmMKKysrIGIvc3lzL2Jvb3QvY29tbW9uL2xvYWRfZWxmLmMKQEAgLTMxNywyNSAr MzE3LDMwIEBAIF9fZWxmTihsb2FkaW1hZ2UpKHN0cnVjdCBwcmVsb2FkZWRfZmlsZSAqZnAs IGVsZl9maWxlX3QgZWYsIHVfaW50NjRfdCBvZmYpCiAJICAgIGNvbnRpbnVlOwogCiAjaWZk ZWYgRUxGX1ZFUkJPU0UKLQlwcmludGYoIlNlZ21lbnQ6IDB4JWx4QDB4JWx4IC0+IDB4JWx4 LTB4JWx4IiwKLQkgICAgKGxvbmcpcGhkcltpXS5wX2ZpbGVzeiwgKGxvbmcpcGhkcltpXS5w X29mZnNldCwKLQkgICAgKGxvbmcpKHBoZHJbaV0ucF92YWRkciArIG9mZiksCi0JICAgIChs b25nKShwaGRyW2ldLnBfdmFkZHIgKyBvZmYgKyBwaGRyW2ldLnBfbWVtc3ogLSAxKSk7CisJ cHJpbnRmKCJTZWdtZW50OiBmaWxlc3ogMHglbGx4IEAgMHglMDE2bGx4IC0+ICB2YWRkcl9y YW5nZSAweCUwMTZsbHggLSAweCUwMTZsbHgiLAorCSAgICAobG9uZyBsb25nKXBoZHJbaV0u cF9maWxlc3osIChsb25nIGxvbmcpcGhkcltpXS5wX29mZnNldCwKKwkgICAgKGxvbmcgbG9u ZykocGhkcltpXS5wX3ZhZGRyICsgb2ZmKSwKKwkgICAgKGxvbmcgbG9uZykocGhkcltpXS5w X3ZhZGRyICsgb2ZmICsgcGhkcltpXS5wX21lbXN6IC0gMSkpOwogI2Vsc2UKIAlpZiAoKHBo ZHJbaV0ucF9mbGFncyAmIFBGX1cpID09IDApIHsKLQkgICAgcHJpbnRmKCJ0ZXh0PTB4JWx4 ICIsIChsb25nKXBoZHJbaV0ucF9maWxlc3opOworCSAgICBwcmludGYoInRleHQ9MHglbGx4 ICIsIChsb25nIGxvbmcpcGhkcltpXS5wX2ZpbGVzeik7CiAJfSBlbHNlIHsKLQkgICAgcHJp bnRmKCJkYXRhPTB4JWx4IiwgKGxvbmcpcGhkcltpXS5wX2ZpbGVzeik7CisJICAgIHByaW50 ZigiZGF0YT0weCVsbHgiLCAobG9uZyBsb25nKXBoZHJbaV0ucF9maWxlc3opOwogCSAgICBp ZiAocGhkcltpXS5wX2ZpbGVzeiA8IHBoZHJbaV0ucF9tZW1zeikKLQkJcHJpbnRmKCIrMHgl bHgiLCAobG9uZykocGhkcltpXS5wX21lbXN6IC1waGRyW2ldLnBfZmlsZXN6KSk7CisJCXBy aW50ZigiKzB4JWxseCIsIChsb25nIGxvbmcpKHBoZHJbaV0ucF9tZW1zeiAtcGhkcltpXS5w X2ZpbGVzeikpOwogCSAgICBwcmludGYoIiAiKTsKIAl9CiAjZW5kaWYKIAlmcGNvcHkgPSAw OwogCWlmIChlZi0+Zmlyc3RsZW4gPiBwaGRyW2ldLnBfb2Zmc2V0KSB7CiAJICAgIGZwY29w eSA9IGVmLT5maXJzdGxlbiAtIHBoZHJbaV0ucF9vZmZzZXQ7Ci0JICAgIGFyY2hzdy5hcmNo X2NvcHlpbihlZi0+Zmlyc3RwYWdlICsgcGhkcltpXS5wX29mZnNldCwKLQkJCSAgICAgICBw aGRyW2ldLnBfdmFkZHIgKyBvZmYsIGZwY29weSk7CisJICAgIHByaW50ZigiXG4lczolZCBm aXJzdHBhZ2UgMHglbHggcF9vZmZzZXQgMHglbHggcF92YWRkciAweCVseCBvZmYgMHglbHhc biIsCisJCSAgIF9fRlVOQ1RJT05fXyxfX0xJTkVfXywKKwkJICAgKHVuc2lnbmVkIGxvbmcp ZWYtPmZpcnN0cGFnZSwKKwkJICAgKHVuc2lnbmVkIGxvbmcpIHBoZHJbaV0ucF9vZmZzZXQs CisJCSAgICh1bnNpZ25lZCBsb25nKXBoZHJbaV0ucF92YWRkciwKKwkJICAgKHVuc2lnbmVk IGxvbmcpb2ZmKTsKKwkgICAgYXJjaHN3LmFyY2hfY29weWluKGVmLT5maXJzdHBhZ2UgKyBw aGRyW2ldLnBfb2Zmc2V0LCBwaGRyW2ldLnBfdmFkZHIgKyBvZmYsIGZwY29weSk7CiAJfQog CWlmIChwaGRyW2ldLnBfZmlsZXN6ID4gZnBjb3B5KSB7CiAJICAgIGlmIChrZXJuX3ByZWFk KGVmLT5mZCwgcGhkcltpXS5wX3ZhZGRyICsgb2ZmICsgZnBjb3B5LApAQCAtMzQ4LDkgKzM1 MywxMSBAQCBfX2VsZk4obG9hZGltYWdlKShzdHJ1Y3QgcHJlbG9hZGVkX2ZpbGUgKmZwLCBl bGZfZmlsZV90IGVmLCB1X2ludDY0X3Qgb2ZmKQogCS8qIGNsZWFyIHNwYWNlIGZyb20gb3Zl cnNpemVkIHNlZ21lbnRzOyBlZzogYnNzICovCiAJaWYgKHBoZHJbaV0ucF9maWxlc3ogPCBw aGRyW2ldLnBfbWVtc3opIHsKICNpZmRlZiBFTEZfVkVSQk9TRQotCSAgICBwcmludGYoIiAo YnNzOiAweCVseC0weCVseCkiLAotCQkobG9uZykocGhkcltpXS5wX3ZhZGRyICsgb2ZmICsg cGhkcltpXS5wX2ZpbGVzeiksCi0JCShsb25nKShwaGRyW2ldLnBfdmFkZHIgKyBvZmYgKyBw aGRyW2ldLnBfbWVtc3ogLSAxKSk7CisJICAgIHByaW50ZigiXG5cdChic3M6IDB4JWx4LTB4 JWx4KSB2YWRkciAweCVseCAgc2l6ZSAweCVseCBjbGVhcmluZ1xuIiwKKwkJICAgKGxvbmcp KHBoZHJbaV0ucF92YWRkciArIG9mZiArIHBoZHJbaV0ucF9maWxlc3opLAorCQkgICAobG9u ZykocGhkcltpXS5wX3ZhZGRyICsgb2ZmICsgcGhkcltpXS5wX21lbXN6IC0gMSksCisJCSAg IChsb25nKShwaGRyW2ldLnBfdmFkZHIgKyBwaGRyW2ldLnBfZmlsZXN6KSwKKwkJICAgKGxv bmcpKHBoZHJbaV0ucF9tZW1zeiAtIHBoZHJbaV0ucF9maWxlc3opICk7CiAjZW5kaWYKIAog CSAgICBrZXJuX2J6ZXJvKHBoZHJbaV0ucF92YWRkciArIG9mZiArIHBoZHJbaV0ucF9maWxl c3osCmRpZmYgLS1naXQgYS9zeXMvYm9vdC91c2VyYm9vdC9maWNsL01ha2VmaWxlIGIvc3lz L2Jvb3QvdXNlcmJvb3QvZmljbC9NYWtlZmlsZQppbmRleCA0MmI5MzA5Li5kNzgxOGI5IDEw MDY0NAotLS0gYS9zeXMvYm9vdC91c2VyYm9vdC9maWNsL01ha2VmaWxlCisrKyBiL3N5cy9i b290L3VzZXJib290L2ZpY2wvTWFrZWZpbGUKQEAgLTYyLDYgKzYyLDEwIEBAIHNvZnRjb3Jl LmM6ICR7U09GVFdPUkRTfSBzb2Z0Y29yZS5hd2sKIAkoY2QgJHsuQ1VSRElSfS8uLi8uLi9m aWNsL3NvZnR3b3JkczsgY2F0ICR7U09GVFdPUkRTfSBcCiAJICAgIHwgYXdrIC1mIHNvZnRj b3JlLmF3ayAtdiBkYXRlc3RhbXA9ImBMQ19BTEw9QyBkYXRlYCIpID4gJHsuVEFSR0VUfQog CitiZWZvcmVkZXBlbmQgJHtPQkpTfTogbm8tbWFjaGluZQorCituby1tYWNoaW5lOgorCXJt IC1mICAgJHsuQ1VSRElSfS8uLi8uLi9maWNsL21hY2hpbmUKICMuaWYgJHtNQUNISU5FX0NQ VUFSQ0h9ID09ICJhbWQ2NCIKICMke1NSQ1M6TSouYzpSOlMvJC8uby9nfTogbWFjaGluZQog IwpkaWZmIC0tZ2l0IGEvc3lzL2Jvb3QvdXNlcmJvb3QvdGVzdC90ZXN0LmMgYi9zeXMvYm9v dC91c2VyYm9vdC90ZXN0L3Rlc3QuYwppbmRleCAzNjI1OGE3Li43NzIwMmMxIDEwMDY0NAot LS0gYS9zeXMvYm9vdC91c2VyYm9vdC90ZXN0L3Rlc3QuYworKysgYi9zeXMvYm9vdC91c2Vy Ym9vdC90ZXN0L3Rlc3QuYwpAQCAtMzc2LDYgKzM3NiwxMiBAQCB0ZXN0X2dldGVudih2b2lk ICphcmcsIGludCBpZHgpCiAJcmV0dXJuICh2YXJzW2lkeF0pOwogfQogCitzdGF0aWMgaW50 Cit0ZXN0X2J1aWxkc21hcCh2b2lkICphcmcsIHZvaWQgKipzbWFwX3ZvaWQsIHNpemVfdCAq b3V0bGVuKSAKK3sKKwlyZXR1cm4gKDApOworfQorCiBzdHJ1Y3QgbG9hZGVyX2NhbGxiYWNr cyBjYiA9IHsKIAkucHV0YyA9IHRlc3RfcHV0YywKIAkuZ2V0YyA9IHRlc3RfZ2V0YywKQEAg LTQwNSw2ICs0MTEsNyBAQCBzdHJ1Y3QgbG9hZGVyX2NhbGxiYWNrcyBjYiA9IHsKICAgICAg ICAgLmdldG1lbSA9IHRlc3RfZ2V0bWVtLAogCiAJLmdldGVudiA9IHRlc3RfZ2V0ZW52LAor CS5idWlsZHNtYXAgPSB0ZXN0X2J1aWxkc21hcCwKIH07CiAKIHZvaWQKQEAgLTQ2NCw1ICs0 NzEsNSBAQCBtYWluKGludCBhcmdjLCBjaGFyKiogYXJndikKIAl0ZXJtLmNfbGZsYWcgJj0g fihJQ0FOT058RUNITyk7CiAJdGNzZXRhdHRyKDAsIFRDU0FGTFVTSCwgJnRlcm0pOwogCi0J ZnVuYygmY2IsIE5VTEwsIFVTRVJCT09UX1ZFUlNJT05fMywgZGlza19mZCA+PSAwKTsKKwlm dW5jKCZjYiwgTlVMTCwgVVNFUkJPT1RfVkVSU0lPTl80LCBkaXNrX2ZkID49IDApOwogfQpk aWZmIC0tZ2l0IGEvc3lzL2Jvb3QvdXNlcmJvb3QvdXNlcmJvb3QuaCBiL3N5cy9ib290L3Vz ZXJib290L3VzZXJib290LmgKaW5kZXggZTM4OTI3ZS4uMGE5ZDJmMSAxMDA2NDQKLS0tIGEv c3lzL2Jvb3QvdXNlcmJvb3QvdXNlcmJvb3QuaAorKysgYi9zeXMvYm9vdC91c2VyYm9vdC91 c2VyYm9vdC5oCkBAIC0zMiw2ICszMiw3IEBACiAjZGVmaW5lCVVTRVJCT09UX1ZFUlNJT05f MSAgICAgIDEKICNkZWZpbmUJVVNFUkJPT1RfVkVSU0lPTl8yICAgICAgMgogI2RlZmluZQlV U0VSQk9PVF9WRVJTSU9OXzMgICAgICAzCisjZGVmaW5lCVVTRVJCT09UX1ZFUlNJT05fNCAg ICAgIDQKIAogLyoKICAqIEV4aXQgY29kZXMgZnJvbSB0aGUgbG9hZGVyCkBAIC0xOTUsNCAr MTk2LDExIEBAIHN0cnVjdCBsb2FkZXJfY2FsbGJhY2tzIHsKIAkgKiBlYWNoIGludm9jYXRp b24gd2lsbCBhZGQgMSB0byB0aGUgcHJldmlvdXMgdmFsdWUgb2YgJ251bScuCiAJICovCiAJ Y29uc3QgY2hhciAqCSgqZ2V0ZW52KSh2b2lkICphcmcsIGludCBudW0pOworCisJLyoKKwkg KiBidWlsZCBzeXN0ZW0gc21hcAorCSAqIHRoaXMgaXMgZm9yIGtsb2FkIHRvIGJ1aWxkIHBh c3MgYmFjayBpbiBhIGNvcHkgb2YgdGhlIHJ1bm5pbmcKKwkgKiBzeXN0ZW1zIHNtYXAgcmV0 dXJucworCSAqLworCWludCAoKmJ1aWxkc21hcCkodm9pZCAqYXJnLCB2b2lkICoqc21hcCwg c2l6ZV90ICpsZW4pOwogfTsKZGlmZiAtLWdpdCBhL3N5cy9ib290L3VzZXJib290L3VzZXJi b290L2Jvb3RpbmZvNjQuYyBiL3N5cy9ib290L3VzZXJib290L3VzZXJib290L2Jvb3RpbmZv NjQuYwppbmRleCBmYzdjMTRkLi4yOGM0N2FiIDEwMDY0NAotLS0gYS9zeXMvYm9vdC91c2Vy Ym9vdC91c2VyYm9vdC9ib290aW5mbzY0LmMKKysrIGIvc3lzL2Jvb3QvdXNlcmJvb3QvdXNl cmJvb3QvYm9vdGluZm82NC5jCkBAIC0xODcsMzMgKzE4Nyw0NiBAQCBiaW9zX2FkZHNtYXBk YXRhKHN0cnVjdCBwcmVsb2FkZWRfZmlsZSAqa2ZwKQogewogCXVpbnQ2NF90IGxvd21lbSwg aGlnaG1lbTsKIAlpbnQgc21hcG51bSwgbGVuOwotCXN0cnVjdCBzbWFwIHNtYXBbM10sICpz bTsKKwlzdHJ1Y3Qgc21hcCAqc21hcCA9IE5VTEwsICpzbSA9IE5VTEw7CisJaW50IGVycm9y ID0gMTsKIAotCUNBTExCQUNLKGdldG1lbSwgJmxvd21lbSwgJmhpZ2htZW0pOworCXByaW50 ZigiJXNcbiIsX19GVU5DVElPTl9fKTsKIAotCXNtID0gJnNtYXBbMF07CisJaWYgKGNhbGxi YWNrcy0+YnVpbGRzbWFwKQorCQllcnJvciA9IGNhbGxiYWNrcy0+YnVpbGRzbWFwKE5VTEws ICh2b2lkICoqKSZzbWFwLCAmbGVuKTsKIAotCXNtLT5iYXNlID0gMDsJCQkJLyogYmFzZSBt ZW1vcnkgKi8KLQlzbS0+bGVuZ3RoID0gNjQwICogMTAyNDsKLQlzbS0+dHlwZSA9IFNNQVBf VFlQRV9NRU1PUlk7Ci0Jc20rKzsKKwkvKiBlaXRoZXIgdGhlcmUgaXMgbm8gYnVpbGRzbWFw IGZ1bmN0aW9uIG9yIGl0IGZhaWxlZAorCSAqIHJldmVydCBiYWNrIHRvIHVzaW5nIGdldG1l bSBhbmQgYSBzaW1wbGUgc21hcAorCSAqLwogCi0Jc20tPmJhc2UgPSAweDEwMDAwMDsJCQkv KiBleHRlbmRlZCBtZW1vcnkgKi8KLQlzbS0+bGVuZ3RoID0gbG93bWVtIC0gMHgxMDAwMDA7 Ci0Jc20tPnR5cGUgPSBTTUFQX1RZUEVfTUVNT1JZOwotCXNtKys7CisJaWYgKGVycm9yKSB7 CisJCXNtYXAgPSBzbSA9IG1hbGxvYygzICogc2l6ZW9mKHN0cnVjdCBzbWFwKSk7CisJCUNB TExCQUNLKGdldG1lbSwgJmxvd21lbSwgJmhpZ2htZW0pOwogCi0Jc21hcG51bSA9IDI7CisJ CXNtLT5iYXNlID0gMDsJCQkJLyogYmFzZSBtZW1vcnkgKi8KKwkJc20tPmxlbmd0aCA9IDY0 MCAqIDEwMjQ7CisJCXNtLT50eXBlID0gU01BUF9UWVBFX01FTU9SWTsKKwkJc20rKzsKIAot ICAgICAgICBpZiAoaGlnaG1lbSAhPSAwKSB7Ci0gICAgICAgICAgICAgICAgc20tPmJhc2Ug PSA0ICogR0I7Ci0gICAgICAgICAgICAgICAgc20tPmxlbmd0aCA9IGhpZ2htZW07Ci0gICAg ICAgICAgICAgICAgc20tPnR5cGUgPSBTTUFQX1RZUEVfTUVNT1JZOwotCQlzbWFwbnVtKys7 Ci0gICAgICAgIH0KKwkJc20tPmJhc2UgPSAweDEwMDAwMDsJCQkvKiBleHRlbmRlZCBtZW1v cnkgKi8KKwkJc20tPmxlbmd0aCA9IGxvd21lbSAtIDB4MTAwMDAwOworCQlzbS0+dHlwZSA9 IFNNQVBfVFlQRV9NRU1PUlk7CisJCXNtKys7CiAKLSAgICAgICAgbGVuID0gc21hcG51bSAq IHNpemVvZiAoc3RydWN0IHNtYXApOwotICAgICAgICBmaWxlX2FkZG1ldGFkYXRhKGtmcCwg TU9ESU5GT01EX1NNQVAsIGxlbiwgJnNtYXBbMF0pOworCQlzbWFwbnVtID0gMjsKKworCQlp ZiAoaGlnaG1lbSAhPSAwKSB7CisJCQlzbS0+YmFzZSA9IDQgKiBHQjsKKwkJCXNtLT5sZW5n dGggPSBoaWdobWVtOworCQkJc20tPnR5cGUgPSBTTUFQX1RZUEVfTUVNT1JZOworCQkJc21h cG51bSsrOworCQl9CisKKwkJbGVuID0gc21hcG51bSAqIHNpemVvZiAoc3RydWN0IHNtYXAp OworCX0KKworCWZpbGVfYWRkbWV0YWRhdGEoa2ZwLCBNT0RJTkZPTURfU01BUCwgbGVuLCBz bWFwKTsKKwlmcmVlKHNtYXApOwogfQogCiAvKgpkaWZmIC0tZ2l0IGEvc3lzL2Jvb3QvdXNl cmJvb3QvdXNlcmJvb3QvY29uZi5jIGIvc3lzL2Jvb3QvdXNlcmJvb3QvdXNlcmJvb3QvY29u Zi5jCmluZGV4IDBjNTdlYmEuLmQyYzEwNjcgMTAwNjQ0Ci0tLSBhL3N5cy9ib290L3VzZXJi b290L3VzZXJib290L2NvbmYuYworKysgYi9zeXMvYm9vdC91c2VyYm9vdC91c2VyYm9vdC9j b25mLmMKQEAgLTg2LDggKzg2LDExIEBAIHN0cnVjdCBmaWxlX2Zvcm1hdCAqZmlsZV9mb3Jt YXRzW10gPSB7CiAgKiBkYXRhIHN0cnVjdHVyZXMgZnJvbSBib290c3RyYXAuaCBhcyB3ZWxs LgogICovCiBleHRlcm4gc3RydWN0IGNvbnNvbGUgdXNlcmJvb3RfY29uc29sZTsKK2V4dGVy biBzdHJ1Y3QgY29uc29sZSBjb21jb25zb2xlOworCiAKIHN0cnVjdCBjb25zb2xlICpjb25z b2xlc1tdID0gewogCSZ1c2VyYm9vdF9jb25zb2xlLAorCSZjb21jb25zb2xlLAogCU5VTEwK IH07CmRpZmYgLS1naXQgYS9zeXMvYm9vdC91c2VyYm9vdC91c2VyYm9vdC9tYWluLmMgYi9z eXMvYm9vdC91c2VyYm9vdC91c2VyYm9vdC9tYWluLmMKaW5kZXggNDA5MmI5Yi4uMGUyZTBi NyAxMDA2NDQKLS0tIGEvc3lzL2Jvb3QvdXNlcmJvb3QvdXNlcmJvb3QvbWFpbi5jCisrKyBi L3N5cy9ib290L3VzZXJib290L3VzZXJib290L21haW4uYwpAQCAtMzYsOCArMzYsOSBAQCBf X0ZCU0RJRCgiJEZyZWVCU0QkIik7CiAjaW5jbHVkZSAiZGlzay5oIgogI2luY2x1ZGUgImxp YnVzZXJib290LmgiCiAKLSNkZWZpbmUJVVNFUkJPT1RfVkVSU0lPTglVU0VSQk9PVF9WRVJT SU9OXzMKKyNkZWZpbmUJVVNFUkJPT1RfVkVSU0lPTglVU0VSQk9PVF9WRVJTSU9OXzQKIAor c3RhdGljIGNoYXIgbWFsbG9jX2J1Zls1MTIqMTAyNF07CiBzdHJ1Y3QgbG9hZGVyX2NhbGxi YWNrcyAqY2FsbGJhY2tzOwogdm9pZCAqY2FsbGJhY2tzX2FyZzsKIApAQCAtNjcsMzEgKzY4 LDQ3IEBAIGV4aXQoaW50IHYpCiB9CiAKIHZvaWQKK2xvYWRlcl9pbml0KHZvaWQpCit7CisJ LyoKKwkgKiBJdCBkb2VzIG5vdCBodXJ0IHRvIHJlLWNhbGwgdGhpcyBhcyBpdCBqdXN0IHNl dHMgZ2xvYmFsCisJICogcHRycyB0aGF0IG5ldmVyIGNoYW5nZSAKKwkgKi8KKwlzZXRoZWFw KCh2b2lkICopbWFsbG9jX2J1ZiwgKHZvaWQgKikobWFsbG9jX2J1ZiArIDUxMioxMDI0KSk7 Cit9CisKK2ludAogbG9hZGVyX21haW4oc3RydWN0IGxvYWRlcl9jYWxsYmFja3MgKmNiLCB2 b2lkICphcmcsIGludCB2ZXJzaW9uLCBpbnQgbmRpc2tzKQogewotCXN0YXRpYyBjaGFyIG1h bGxvY1s1MTIqMTAyNF07CiAJY29uc3QgY2hhciAqdmFyOwogCWludCBpOwotCi0gICAgICAg IGlmICh2ZXJzaW9uICE9IFVTRVJCT09UX1ZFUlNJT04pCi0gICAgICAgICAgICAgICAgYWJv cnQoKTsKLQotCWNhbGxiYWNrcyA9IGNiOwotICAgICAgICBjYWxsYmFja3NfYXJnID0gYXJn OwotCXVzZXJib290X2Rpc2tfbWF4dW5pdCA9IG5kaXNrczsKLQorCQogCS8qCiAJICogaW5p dGlhbGlzZSB0aGUgaGVhcCBhcyBlYXJseSBhcyBwb3NzaWJsZS4gIE9uY2UgdGhpcyBpcyBk b25lLAogCSAqIGFsbG9jKCkgaXMgdXNhYmxlLiBUaGUgc3RhY2sgaXMgYnVyaWVkIGluc2lk ZSB1cywgc28gdGhpcyBpcwogCSAqIHNhZmUuCiAJICovCi0Jc2V0aGVhcCgodm9pZCAqKW1h bGxvYywgKHZvaWQgKikobWFsbG9jICsgNTEyKjEwMjQpKTsKKwlsb2FkZXJfaW5pdCgpOwor ICAKKwlpZiAoY2IgIT0gTlVMTCkgeworCQljYWxsYmFja3MgPSBjYjsKKwkJY2FsbGJhY2tz X2FyZyA9IGFyZzsKKwkJdXNlcmJvb3RfZGlza19tYXh1bml0ID0gbmRpc2tzOworCX0gZWxz ZSB7CisJCXJldHVybiAoRUZBVUxUKTsKKwl9CiAKLSAgICAgICAgLyoKKwkvKgogICAgICAg ICAgKiBIb29rIHVwIHRoZSBjb25zb2xlCiAgICAgICAgICAqLwogCWNvbnNfcHJvYmUoKTsK IAorICAgICAgICBpZiAodmVyc2lvbiAhPSBVU0VSQk9PVF9WRVJTSU9OKSB7CisJCXByaW50 ZigiJXM6IHZlcnNpb24gZXhwZWN0ZWQgJWQgZ290ICVkXG4iLCBfX2Z1bmNfXywKKwkJICAg ICAgVVNFUkJPT1RfVkVSU0lPTiwgdmVyc2lvbik7CisJCXJldHVybihFT1BOT1RTVVBQKTsK Kwl9CisKIAkvKgogCSAqIE1hcmNoIHRocm91Z2ggdGhlIGRldmljZSBzd2l0Y2ggcHJvYmlu ZyBmb3IgdGhpbmdzLgogCSAqLwpAQCAtMTI4LDExICsxNDUsMTEgQEAgbG9hZGVyX21haW4o c3RydWN0IGxvYWRlcl9jYWxsYmFja3MgKmNiLCB2b2lkICphcmcsIGludCB2ZXJzaW9uLCBp bnQgbmRpc2tzKQogCWV4dHJhY3RfY3VycmRldigpOwogCiAJaWYgKHNldGptcChqYikpCi0J CXJldHVybjsKKwkJcmV0dXJuICgwKTsKIAogCWludGVyYWN0KCk7CQkJLyogZG9lc24ndCBy ZXR1cm4gKi8KIAotCWV4aXQoMCk7CisJcmV0dXJuKDApOwogfQogCiAvKgpkaWZmIC0tZ2l0 IGEvc3lzL2Jvb3QvdXNlcmJvb3QvdXNlcmJvb3QvdXNlcmJvb3RfY29ucy5jIGIvc3lzL2Jv b3QvdXNlcmJvb3QvdXNlcmJvb3QvdXNlcmJvb3RfY29ucy5jCmluZGV4IDVlY2I3YzguLjVh OWE1NzMgMTAwNjQ0Ci0tLSBhL3N5cy9ib290L3VzZXJib290L3VzZXJib290L3VzZXJib290 X2NvbnMuYworKysgYi9zeXMvYm9vdC91c2VyYm9vdC91c2VyYm9vdC91c2VyYm9vdF9jb25z LmMKQEAgLTUwLDYgKzUwLDE4IEBAIHN0cnVjdCBjb25zb2xlIHVzZXJib290X2NvbnNvbGUg PSB7CiAJdXNlcmJvb3RfY29uc19wb2xsLAogfTsKIAorCitzdHJ1Y3QgY29uc29sZSBjb21j b25zb2xlID0geworCSJjb21jb25zb2xlIiwKKwkiY29tc29uc29sZSIsCisJMCwKKwl1c2Vy Ym9vdF9jb25zX3Byb2JlLAorCXVzZXJib290X2NvbnNfaW5pdCwKKwl1c2VyYm9vdF9jb25z X3B1dGNoYXIsCisJdXNlcmJvb3RfY29uc19nZXRjaGFyLAorCXVzZXJib290X2NvbnNfcG9s bCwKK307CisKIHN0YXRpYyB2b2lkCiB1c2VyYm9vdF9jb25zX3Byb2JlKHN0cnVjdCBjb25z b2xlICpjcCkKIHsKZGlmZiAtLWdpdCBhL3N5cy9jb25mL2ZpbGVzIGIvc3lzL2NvbmYvZmls ZXMKaW5kZXggNTU1NGVjMC4uNDlkZTkwYSAxMDA2NDQKLS0tIGEvc3lzL2NvbmYvZmlsZXMK KysrIGIvc3lzL2NvbmYvZmlsZXMKQEAgLTI2MDcsNiArMjYwNyw3IEBAIGtlcm4va2Vybl9r aGVscC5jCQlzdGFuZGFyZAoga2Vybi9rZXJuX2t0aHJlYWQuYwkJc3RhbmRhcmQKIGtlcm4v a2Vybl9rdHIuYwkJCW9wdGlvbmFsIGt0cgoga2Vybi9rZXJuX2t0cmFjZS5jCQlzdGFuZGFy ZAora2Vybi9rZXJuX2tsb2FkLmMJCXN0YW5kYXJkCiBrZXJuL2tlcm5fbGlua2VyLmMJCXN0 YW5kYXJkCiBrZXJuL2tlcm5fbG9jay5jCQlzdGFuZGFyZAoga2Vybi9rZXJuX2xvY2tmLmMJ CXN0YW5kYXJkCmRpZmYgLS1naXQgYS9zeXMvY29uZi9maWxlcy5hbWQ2NCBiL3N5cy9jb25m L2ZpbGVzLmFtZDY0CmluZGV4IGI2YTQ3NGUuLjI0NDdjN2JkIDEwMDY0NAotLS0gYS9zeXMv Y29uZi9maWxlcy5hbWQ2NAorKysgYi9zeXMvY29uZi9maWxlcy5hbWQ2NApAQCAtOTMsNiAr OTMsOSBAQCBhY3BpX3dha2VkYXRhLmgJCQlvcHRpb25hbAlhY3BpCQkJXAogCW5vLW9iaiBu by1pbXBsaWNpdC1ydWxlCWJlZm9yZS1kZXBlbmQJCQkJXAogCWNsZWFuCQkiYWNwaV93YWtl ZGF0YS5oIgogIworYW1kNjQvYW1kNjQva2xvYWRfZXhlYy5TCXN0YW5kYXJkCithbWQ2NC9h bWQ2NC9rbG9hZC5jICAgICAgICAgICAgIHN0YW5kYXJkCisjCiBhbWQ2NC9hbWQ2NC9hbWQ2 NF9tZW0uYwkJb3B0aW9uYWwJbWVtCiAjYW1kNjQvYW1kNjQvYXBpY192ZWN0b3IuUwlzdGFu ZGFyZAogYW1kNjQvYW1kNjQvYXRvbWljLmMJCXN0YW5kYXJkCmRpZmYgLS1naXQgYS9zeXMv a2Vybi9pbml0X3N5c2VudC5jIGIvc3lzL2tlcm4vaW5pdF9zeXNlbnQuYwppbmRleCA2OGMy NGUwLi5mODFhMDVmIDEwMDY0NAotLS0gYS9zeXMva2Vybi9pbml0X3N5c2VudC5jCisrKyBi L3N5cy9rZXJuL2luaXRfc3lzZW50LmMKQEAgLTMsNyArMyw3IEBACiAgKgogICogRE8gTk9U IEVESVQtLSB0aGlzIGZpbGUgaXMgYXV0b21hdGljYWxseSBnZW5lcmF0ZWQuCiAgKiAkRnJl ZUJTRCQKLSAqIGNyZWF0ZWQgZnJvbSBGcmVlQlNEOiBoZWFkL3N5cy9rZXJuL3N5c2NhbGxz Lm1hc3RlciAyNDI5NTggMjAxMi0xMS0xMyAxMjo1MjozMVoga2liIAorICogY3JlYXRlZCBm cm9tIEZyZWVCU0QKICAqLwogCiAjaW5jbHVkZSAib3B0X2NvbXBhdC5oIgpAQCAtNTY3LDQg KzU2Nyw1IEBAIHN0cnVjdCBzeXNlbnQgc3lzZW50W10gPSB7CiAJeyBBUyhwb3NpeF9mYWxs b2NhdGVfYXJncyksIChzeV9jYWxsX3QgKilzeXNfcG9zaXhfZmFsbG9jYXRlLCBBVUVfTlVM TCwgTlVMTCwgMCwgMCwgMCwgU1lfVEhSX1NUQVRJQyB9LAkvKiA1MzAgPSBwb3NpeF9mYWxs b2NhdGUgKi8KIAl7IEFTKHBvc2l4X2ZhZHZpc2VfYXJncyksIChzeV9jYWxsX3QgKilzeXNf cG9zaXhfZmFkdmlzZSwgQVVFX05VTEwsIE5VTEwsIDAsIDAsIDAsIFNZX1RIUl9TVEFUSUMg fSwJLyogNTMxID0gcG9zaXhfZmFkdmlzZSAqLwogCXsgQVMod2FpdDZfYXJncyksIChzeV9j YWxsX3QgKilzeXNfd2FpdDYsIEFVRV9XQUlUNiwgTlVMTCwgMCwgMCwgMCwgU1lfVEhSX1NU QVRJQyB9LAkvKiA1MzIgPSB3YWl0NiAqLworCXsgQVMoa2xvYWRfYXJncyksIChzeV9jYWxs X3QgKilzeXNfa2xvYWQsIEFVRV9OVUxMLCBOVUxMLCAwLCAwLCAwLCBTWV9USFJfU1RBVElD IH0sCS8qIDUzMyA9IGtsb2FkICovCiB9OwpkaWZmIC0tZ2l0IGEvc3lzL2tlcm4va2Vybl9r bG9hZC5jIGIvc3lzL2tlcm4va2Vybl9rbG9hZC5jCm5ldyBmaWxlIG1vZGUgMTAwNjQ0Cmlu ZGV4IDAwMDAwMDAuLjYzNjgzMGUKLS0tIC9kZXYvbnVsbAorKysgYi9zeXMva2Vybi9rZXJu X2tsb2FkLmMKQEAgLTAsMCArMSw0MjQgQEAKKy8qCisgKiBDb3B5cmlnaHQgKGMpIDIwMTEg LSAyMDEyCisgKglSdXNzZWxsIENhdHRlbGFuIERpZ2l0YWwgRWx2ZXMgSW5jCisgKiBDb3B5 cmlnaHQgKGMpIDIwMTEgLSAyMDEyCisgKglJc2lsb24gU3lzdGVtcywgTExDLiAgQWxsIHJp Z2h0cyByZXNlcnZlZC4KKyAqCisgKiBSZWRpc3RyaWJ1dGlvbiBhbmQgdXNlIGluIHNvdXJj ZSBhbmQgYmluYXJ5IGZvcm1zLCB3aXRoIG9yIHdpdGhvdXQKKyAqIG1vZGlmaWNhdGlvbiwg YXJlIHBlcm1pdHRlZCBwcm92aWRlZCB0aGF0IHRoZSBmb2xsb3dpbmcgY29uZGl0aW9ucwor ICogYXJlIG1ldDoKKyAqIDEuIFJlZGlzdHJpYnV0aW9ucyBvZiBzb3VyY2UgY29kZSBtdXN0 IHJldGFpbiB0aGUgYWJvdmUgY29weXJpZ2h0CisgKiAgICBub3RpY2UsIHRoaXMgbGlzdCBv ZiBjb25kaXRpb25zIGFuZCB0aGUgZm9sbG93aW5nIGRpc2NsYWltZXIuCisgKiAyLiBSZWRp c3RyaWJ1dGlvbnMgaW4gYmluYXJ5IGZvcm0gbXVzdCByZXByb2R1Y2UgdGhlIGFib3ZlIGNv cHlyaWdodAorICogICAgbm90aWNlLCB0aGlzIGxpc3Qgb2YgY29uZGl0aW9ucyBhbmQgdGhl IGZvbGxvd2luZyBkaXNjbGFpbWVyIGluIHRoZQorICogICAgZG9jdW1lbnRhdGlvbiBhbmQv b3Igb3RoZXIgbWF0ZXJpYWxzIHByb3ZpZGVkIHdpdGggdGhlIGRpc3RyaWJ1dGlvbi4KKyAq CisgKiBUSElTIFNPRlRXQVJFIElTIFBST1ZJREVEIEJZIFRIRSBBVVRIT1IgQU5EIENPTlRS SUJVVE9SUyBgYEFTIElTJycgQU5ECisgKiBBTlkgRVhQUkVTUyBPUiBJTVBMSUVEIFdBUlJB TlRJRVMsIElOQ0xVRElORywgQlVUIE5PVCBMSU1JVEVEIFRPLCBUSEUKKyAqIElNUExJRUQg V0FSUkFOVElFUyBPRiBNRVJDSEFOVEFCSUxJVFkgQU5EIEZJVE5FU1MgRk9SIEEgUEFSVElD VUxBUiBQVVJQT1NFCisgKiBBUkUgRElTQ0xBSU1FRC4gIElOIE5PIEVWRU5UIFNIQUxMIFRI RSBBVVRIT1IgT1IgQ09OVFJJQlVUT1JTIEJFIExJQUJMRQorICogRk9SIEFOWSBESVJFQ1Qs IElORElSRUNULCBJTkNJREVOVEFMLCBTUEVDSUFMLCBFWEVNUExBUlksIE9SIENPTlNFUVVF TlRJQUwKKyAqIERBTUFHRVMgKElOQ0xVRElORywgQlVUIE5PVCBMSU1JVEVEIFRPLCBQUk9D VVJFTUVOVCBPRiBTVUJTVElUVVRFIEdPT0RTCisgKiBPUiBTRVJWSUNFUzsgTE9TUyBPRiBV U0UsIERBVEEsIE9SIFBST0ZJVFM7IE9SIEJVU0lORVNTIElOVEVSUlVQVElPTikKKyAqIEhP V0VWRVIgQ0FVU0VEIEFORCBPTiBBTlkgVEhFT1JZIE9GIExJQUJJTElUWSwgV0hFVEhFUiBJ TiBDT05UUkFDVCwgU1RSSUNUCisgKiBMSUFCSUxJVFksIE9SIFRPUlQgKElOQ0xVRElORyBO RUdMSUdFTkNFIE9SIE9USEVSV0lTRSkgQVJJU0lORyBJTiBBTlkgV0FZCisgKiBPVVQgT0Yg VEhFIFVTRSBPRiBUSElTIFNPRlRXQVJFLCBFVkVOIElGIEFEVklTRUQgT0YgVEhFIFBPU1NJ QklMSVRZIE9GCisgKiBTVUNIIERBTUFHRS4KKyAqCisgKi8KKyNpbmNsdWRlIDxzeXMvcGFy YW0uaD4KKyNpbmNsdWRlIDxzeXMvYnVzLmg+CisjaW5jbHVkZSA8c3lzL2V2ZW50aGFuZGxl ci5oPgorI2luY2x1ZGUgPHN5cy9rZXJuZWwuaD4KKyNpbmNsdWRlIDxzeXMva2xvYWQuaD4K KyNpbmNsdWRlIDxzeXMvbG9jay5oPgorI2luY2x1ZGUgPHN5cy9tYWxsb2MuaD4KKyNpbmNs dWRlIDxzeXMvbXV0ZXguaD4KKyNpbmNsdWRlIDxzeXMvcHJpdi5oPgorI2luY2x1ZGUgPHN5 cy9wcm9jLmg+CisjaW5jbHVkZSA8c3lzL3JlYm9vdC5oPgorI2luY2x1ZGUgPHN5cy9zY2hl ZC5oPgorI2luY2x1ZGUgPHN5cy9zbXAuaD4KKyNpbmNsdWRlIDxzeXMvc3lzcHJvdG8uaD4K KyNpbmNsdWRlIDxzeXMvc3lzdG0uaD4KKworI2luY2x1ZGUgPG1hY2hpbmUvaW50cl9tYWNo ZGVwLmg+CisjaW5jbHVkZSA8bWFjaGluZS9hcGljdmFyLmg+CisjaW5jbHVkZSA8bWFjaGlu ZS9zZWdtZW50cy5oPgorCisjaW5jbHVkZSA8dm0vdm1fcGFyYW0uaD4KKyNpbmNsdWRlIDx2 bS92bS5oPgorI2luY2x1ZGUgPHZtL3ZtX2V4dGVybi5oPgorI2luY2x1ZGUgPHZtL3ZtX2tl cm4uaD4KKyNpbmNsdWRlIDx2bS92bV9vYmplY3QuaD4KKyNpbmNsdWRlIDx2bS92bV9wYWdl Lmg+CisjaW5jbHVkZSA8dm0vdm1fcGFnZW91dC5oPgorI2luY2x1ZGUgPHZtL3ZtX21hcC5o PgorCisKK3N0YXRpYyBzdHJ1Y3Qga2xvYWRfaXRlbXMgKmtfaXRlbXMgPSBOVUxMOworc3Rh dGljIE1BTExPQ19ERUZJTkUoTV9LTE9BRCwgImtsb2FkX2l0ZW1zIiwgImtsb2FkIGl0ZW1z Iik7CitpbnQga2xvYWRfcmVhZHkgPSAwOworCitzdGF0aWMgdm1fb2Zmc2V0X3Qga2xvYWRf aW1hZ2VfdmEgPSAwOworLyoKKyAqIFdhcm5pbmcgdGhpcyBpcyBzb21ld2hhdCBhcmJpdHJh cnksIGJ1dCBzaG91bGQgZ28KKyAqIGF3YXkgb25jZSB0aGUgYWxsb2NhdGUgZGVsYXlzIGlu IGttZW1fYWxsb2NfYXR0ciBhcmUKKyAqIGZpeGVkLgorICovCisjZGVmaW5lCUlNQUdFX1BS RUFMTE9DCSgyNCAqIDEwMjQgKiAxMDI0KQorCitzdGF0aWMgdm9pZCBrbG9hZF9pbml0KHZv aWQpOworU1lTSU5JVChrbG9hZF9tZW0sIFNJX1NVQl9EUklWRVJTLCBTSV9PUkRFUl9BTlks IGtsb2FkX2luaXQsIE5VTEwpOworCitzdGF0aWMgaW50IGtsb2FkX2NvcHlpbl9zZWdtZW50 KHN0cnVjdCBrbG9hZF9zZWdtZW50ICosaW50KTsKK3N0YXRpYyBpbnQga2xvYWRfYWRkX3Bh Z2Uoc3RydWN0IGtsb2FkX2l0ZW1zICosIHVuc2lnbmVkIGxvbmcpOworc3RhdGljIHZvaWQg a2xvYWRfc2h1dGRvd25fZmluYWwodm9pZCAqLCBpbnQpOworc3RhdGljIHN0cnVjdCByZWdp b25fZGVzY3JpcHRvciAqbXlnZHQ7CitzdGF0aWMJdm1fb2Zmc2V0X3QgY29udHJvbF9wYWdl Oworc3RhdGljCXZtX29mZnNldF90IGNvZGVfcGFnZTsKK3N0YXRpYyAJdm9pZCAqZ2R0X2Rl c2M7CitzdGF0aWMgcHRfZW50cnlfdCAqcGd0Ymw7Cit1bnNpZ25lZCBsb25nIGtsb2FkX3Bn dGJsOworc3RhdGljIHVuc2lnbmVkIGxvbmcgbWF4X2FkZHIgPSAwICwgbWluX2FkZHIgPSAw OworCisjZGVmaW5lIEdJR01BU0sJCQkofigoMTw8MzApLTEpKQorI2RlZmluZQlPTkVHSUcJ CQkoMTw8MzApCisjZGVmaW5lCUdVRVNUX0dEVFJfTElNSVQJKDMgKiA4IC0gMSkKKworZXh0 ZXJuIGNoYXIga2VybnBoeXNbXTsKKyNkZWZpbmUJS0xPQURCQVNFCQlLRVJOQkFTRQorCitz dGF0aWMgdm9pZAordXBkYXRlX21heF9taW4odm1fb2Zmc2V0X3QgYWRkciwgaW50IGNvdW50 KQoreworCWludCBpOworCisJZm9yKGkgPSAwOyBpIDwgY291bnQ7IGkrKykgeworCQlpZiAo dnRvcGh5cyhhZGRyICsgKGkgKiBQQUdFX1NJWkUpKSA8IG1pbl9hZGRyKQorCQkJbWluX2Fk ZHIgPSB2dG9waHlzKGFkZHIgKyAoaSAqIFBBR0VfU0laRSkpOworCQlpZiAodnRvcGh5cyhh ZGRyICsgKGkgKiBQQUdFX1NJWkUpKSA+IG1heF9hZGRyKQorCQkJbWF4X2FkZHIgPSB2dG9w aHlzKGFkZHIgKyAoaSAqIFBBR0VfU0laRSkpOworCX0KK30KKworc3RhdGljIHZtX29mZnNl dF90CitrbG9hZF9rbWVtX2FsbG9jKHZtX21hcF90IG1hcCwgdm1fc2l6ZV90IHNpemUpCit7 CisJdm1fb2Zmc2V0X3QgdmE7CisJaW50IG51bV9wYWdlczsKKworCXZhID0ga21lbV9hbGxv Y19hdHRyKG1hcCwgc2l6ZSwKKwkgICAgTV9XQUlUT0sgfCBNX1pFUk8sCisJICAgIDAsICgx IDw8IDMwKSAvKiAxR2lnIGxpbWl0ICovLAorCSAgICBWTV9NRU1BVFRSX1dSSVRFX0NPTUJJ TklORyk7CisKKwludW1fcGFnZXMgPSByb3VuZHVwMihzaXplLFBBR0VfU0laRSkgPj4gUEFH RV9TSElGVDsKKwl1cGRhdGVfbWF4X21pbih2YSwgbnVtX3BhZ2VzKTsKKworCXJldHVybiAo dmEpOworCX0KKworc3RydWN0IGtsb2FkX2NwYWdlIHsKKwl1bnNpZ25lZCBsb25nIGtjcF9t YWdpYzsJLyogMCAqLworCXVuc2lnbmVkIGxvbmcga2NwX21vZHVsZXA7CS8qIDEgKi8KKwl1 bnNpZ25lZCBsb25nIGtjcF9waHlzZnJlZTsJLyogMiAqLworCXVuc2lnbmVkIGxvbmcga2Nw X2dkdDsJCS8qIDMgKi8KKwl1bnNpZ25lZCBsb25nIGtjcF9wZ3RibDsJLyogNCAqLworCXVu c2lnbmVkIGxvbmcga2NwX2NwOwkJLyogNSAqLworCXVuc2lnbmVkIGxvbmcga2NwX2VudHJ5 X3B0OwkvKiA2ICovCisJdW5zaWduZWQgbG9uZyBrY3BfaWR0OwkJLyogNyAqLworfSBfX3Bh Y2tlZDsKKworc3RhdGljIGludAora2xvYWRfYWRkX3BhZ2Uoc3RydWN0IGtsb2FkX2l0ZW1z ICppdGVtcywgdW5zaWduZWQgbG9uZyBpdGVtX20pCit7CisJdm1fcGFkZHJfdCBwaHlzOwor CXVuc2lnbmVkIGxvbmcgdmE7CisKKwlpZiAoKml0ZW1zLT5pdGVtICE9IDApIHsKKwkJcHJp bnRmKCIgaXRlbSAhPSAwIDB4JWx4XG4iLCppdGVtcy0+aXRlbSk7CisJCWl0ZW1zLT5pdGVt Kys7CisJCWl0ZW1zLT5pX2NvdW50LS07CisJfQorCisKKwlpZiAoKGl0ZW1zLT5pdGVtID09 IGl0ZW1zLT5sYXN0X2l0ZW0pIHx8IChpdGVtcy0+aV9jb3VudCA9PSAwKSkgeworCQkvKiBv dXQgb2Ygc3BhY2UgaW4gY3VycmVudCBwYWdlIGdyYWIgYSBuZXcgb25lICovCisJCXZhID0g KHVuc2lnbmVkIGxvbmcpa2xvYWRfa21lbV9hbGxvYyhrZXJuZWxfbWFwLFBBR0VfU0laRSk7 CisJCWlmIChpdGVtcy0+aGVhZF92YSA9PSAwKQorCQkJaXRlbXMtPmhlYWRfdmEgPSB2YTsK KworCQlwaHlzID0gdnRvcGh5cyh2YSk7CisJCS8qIHN0b3JlIHRoZSBhZGRyZXNzIG9mIGlu ZHJlY3QgcGFnZSAqLworCQkqaXRlbXMtPml0ZW0gPSAodW5zaWduZWQgbG9uZykKKwkJICAg ICh2dG9waHlzKHZhKSArIEtMT0FEQkFTRSkgfCBLTE9BRF9JTkRJUkVDVDsKKwkJaXRlbXMt Pml0ZW0gPSAodW5zaWduZWQgbG9uZyAqKXZhOworCQkvKiBvayBub3cgbW92ZSB0byBuZXcg cGFnZSB0byBzdGFydCBzdG9yaW5nIGFkZHJlc3MgKi8KKwkJaXRlbXMtPmxhc3RfaXRlbSA9 ICh1bnNpZ25lZCBsb25nICopdmEgKworCQkgICAgKChQQUdFX1NJWkUvc2l6ZW9mKHVuc2ln bmVkIGxvbmcpKSAtIDEpOworCQlpdGVtcy0+aV9jb3VudCA9ICgoUEFHRV9TSVpFL3NpemVv Zih1bnNpZ25lZCBsb25nKSkgLSAxKTsKKwl9CisJKml0ZW1zLT5pdGVtID0gaXRlbV9tOwor CWl0ZW1zLT5pdGVtKys7CisJaXRlbXMtPmlfY291bnQtLTsKKworCXJldHVybiAoMCk7Cit9 CisKK3N0YXRpYyB2b2lkCitrbG9hZF9pbml0KHZvaWQpCit7CisJaW50IHNpemUgPSBJTUFH RV9QUkVBTExPQzsKKwlrbG9hZF9pbWFnZV92YSA9IGtsb2FkX2ttZW1fYWxsb2Moa2VybmVs X21hcCwgc2l6ZSk7CisJcHJpbnRmKCIlcyAweCVseCBwcmVhbGxvY2F0ZWQgc2l6ZSAlZFxu IiwgX19mdW5jX18sCisJICAgIGtsb2FkX2ltYWdlX3ZhLCBzaXplKTsKK30KKworaW50Citr bG9hZF9jb3B5aW5fc2VnbWVudChzdHJ1Y3Qga2xvYWRfc2VnbWVudCAqa2hkciwgaW50IHNl ZykKK3sKKwlpbnQgaTsKKwlpbnQgbnVtX3BhZ2VzOworCWludCBlcnJvciA9IDA7CisJdm1f b2Zmc2V0X3QgdmEgPSBrbG9hZF9pbWFnZV92YTsKKworCW51bV9wYWdlcyA9IHJvdW5kdXAy KGtoZHItPmtfbWVtc3osUEFHRV9TSVpFKSA+PiBQQUdFX1NISUZUOworCisJLyogY2hlY2sg dG8gbWFrZSBzdXJlIHRoZSBwcmVhbGxvY2F0ZSBzcGFjZSBpcyBiZWcgZW5vdWdoICovCisJ aWYgKHZhICYmICgobnVtX3BhZ2VzICogUEFHRV9TSVpFKSA+IElNQUdFX1BSRUFMTE9DKSkg eworCQlwcmludGYoIiVzIHNpemUgb3ZlciAyNE1lZyAlZFxuIiwgX19mdW5jX18sCisJCQkg bnVtX3BhZ2VzICogUEFHRV9TSVpFKTsKKwkJa21lbV9mcmVlKGtlcm5lbF9tYXAsIHZhLCBJ TUFHRV9QUkVBTExPQyk7CisJCXZhID0gMDsKKwl9CisKKwlpZiAodmEgPT0gMCkgeworCQl2 YSA9IGtsb2FkX2ttZW1fYWxsb2Moa2VybmVsX21hcCwgbnVtX3BhZ2VzICogUEFHRV9TSVpF KTsKKwkJaWYgKHZhID09IDApCisJCQlyZXR1cm4gKEVOT01FTSk7CisJfQorCisJLyogIG5l ZWQgdG8gc2V0IHVwIGEgU1RBUlQgZHN0IHBhZ2UgKi8KKwlmb3IgKGkgPSAwOyBpIDwgbnVt X3BhZ2VzOyBpKyspIHsKKwkJa2xvYWRfYWRkX3BhZ2Uoa19pdGVtcywKKwkJICAgICh2dG9w aHlzKHZhICsgKGkgKiBQQUdFX1NJWkUpKSArIEtMT0FEQkFTRSkgfCBLTE9BRF9TT1VSQ0Up OworCX0KKwlwcmludGYoIiVzIHN0YXJ0aW5nIGNvcHlpbi4uLiAiLCBfX2Z1bmNfXyk7CisJ KmtfaXRlbXMtPml0ZW0gPSBLTE9BRF9ET05FOworCWlmICgoZXJyb3IgPSBjb3B5aW4oa2hk ci0+a19idWYsICh2b2lkICopdmEsIGtoZHItPmtfbWVtc3opKSAhPSAwKQorCQlyZXR1cm4g KGVycm9yKTsKKwlwcmludGYoImNvcGllZCAlZCBieXRlcyB0byB2YSAlcCBkb25lIG1hcmtl ciBhdCAlcFxuIiwKKwkgICAgICAgKGludClraGRyLT5rX21lbXN6LCAodm9pZCAqKXZhLCAm a19pdGVtcy0+aXRlbSApOworCisJcmV0dXJuIChlcnJvcik7Cit9CisKK2ludAorc3lzX2ts b2FkKHN0cnVjdCB0aHJlYWQgKnRkLCBzdHJ1Y3Qga2xvYWRfYXJncyAqdWFwKQoreworCXN0 cnVjdCByZWdpb25fZGVzY3JpcHRvciAqbnVsbF9pZHQ7CisJc3RydWN0IGtsb2FkX2NwYWdl ICprX2NwYWdlOworCXN0cnVjdCBrbG9hZCBrbGQ7CisJaW50IGVycm9yID0gMDsKKwlpbnQg aTsKKwlzaXplX3QgYnVmc2l6ZSA9IHVhcC0+YnVmbGVuOworCisJZXJyb3IgPSBwcml2X2No ZWNrKHRkLCBQUklWX1JFQk9PVCk7CisJaWYgKGVycm9yKQorCQlyZXR1cm4gKGVycm9yKTsK KworCS8qCisJICogaG9vayBpbnRvIHRoZSBzaHV0ZG93bi9yZWJvb3QgcGF0aCBzbworCSAq IHdlIGVuZCB1cCBoZXJlIGJlZm9yZSBjcHUgcmVzZXQKKwkgKi8KKwlFVkVOVEhBTkRMRVJf UkVHSVNURVIoc2h1dGRvd25fZmluYWwsIGtsb2FkX3NodXRkb3duX2ZpbmFsLAorCSAgICBO VUxMLCBTSFVURE9XTl9QUklfS0xPQUQpOworCisJbWF4X2FkZHIgPSAwOworCW1pbl9hZGRy ID0gfjBVTDsKKworCWlmIChidWZzaXplICE9IHNpemVvZihzdHJ1Y3Qga2xvYWQpKSB7CisJ CXByaW50ZigiSG1tIHNpemUgbm90IHJpZ2h0ICVqZCAlamRcbiIsICh1aW50bWF4X3QpYnVm c2l6ZSwKKwkJICAgICh1aW50bWF4X3Qpc2l6ZW9mKHN0cnVjdCBrbG9hZCkpOworCQlyZXR1 cm4gKGVycm9yKTsKKwl9CisJaWYgKChlcnJvciA9IGNvcHlpbih1YXAtPmJ1ZiwgJmtsZCwg YnVmc2l6ZSkpICE9IDApCisJCXJldHVybiAoZXJyb3IpOworCisJaWYgKGtfaXRlbXMgPT0g TlVMTCkgeworCQlpZigoa19pdGVtcyA9IG1hbGxvYyhzaXplb2Yoc3RydWN0IGtsb2FkX2l0 ZW1zKSwKKwkJCQkgICAgIE1fS0xPQUQsIE1fV0FJVE9LfE1fWkVSTykpID09IE5VTEwpCisJ CQlyZXR1cm4gKEVOT01FTSk7CisKKwkJa19pdGVtcy0+aGVhZCA9IDA7CisJCWtfaXRlbXMt PmhlYWRfdmEgPSAwOworCQlrX2l0ZW1zLT5pdGVtID0gJmtfaXRlbXMtPmhlYWQ7CisJCWtf aXRlbXMtPmxhc3RfaXRlbSA9ICZrX2l0ZW1zLT5oZWFkOworCX0KKworCWNvbnRyb2xfcGFn ZSA9IGtsb2FkX2ttZW1fYWxsb2Moa2VybmVsX21hcCwgUEFHRV9TSVpFICogMik7CisJa19j cGFnZSA9IChzdHJ1Y3Qga2xvYWRfY3BhZ2UgKiljb250cm9sX3BhZ2U7CisJY29kZV9wYWdl ID0gY29udHJvbF9wYWdlICsgUEFHRV9TSVpFOworCisJcHJpbnRmKCJjb3B5IGZyb20gJXAg a2VybmVsX2t1bXAgdG8gMHglbHggc2l6ZSAlZFxuIiwKKwkgICAgICAgcmVsb2NhdGVfa2Vy bmVsLCAodW5zaWduZWQgbG9uZyljb2RlX3BhZ2UsIHJlbG9jYXRlX2tlcm5lbF9zaXplKTsK KwltZW1zZXQoKHZvaWQgKiljb250cm9sX3BhZ2UsIDAsIFBBR0VfU0laRSAqIDIpOworCW1l bWNweSgodm9pZCAqKWNvZGVfcGFnZSwgcmVsb2NhdGVfa2VybmVsLCByZWxvY2F0ZV9rZXJu ZWxfc2l6ZSk7CisKKwlrX2NwYWdlLT5rY3BfbWFnaWMgPSAweEMwREU7CisJa19jcGFnZS0+ a2NwX21vZHVsZXAgPSBrbGQua19tb2R1bGVwOworCWtfY3BhZ2UtPmtjcF9waHlzZnJlZSA9 IGtsZC5rX3BoeXNmcmVlOworCisJbXlnZHQgPSAoc3RydWN0IHJlZ2lvbl9kZXNjcmlwdG9y ICopa2xvYWRfa21lbV9hbGxvYyhrZXJuZWxfbWFwLAorCSAgICBQQUdFX1NJWkUpOworCWtf Y3BhZ2UtPmtjcF9nZHQgPSAodW5zaWduZWQgbG9uZyl2dG9waHlzKG15Z2R0KSArIEtMT0FE QkFTRTsKKworCWdkdF9kZXNjID0gKGNoYXIgKilteWdkdCArIHNpemVvZihzdHJ1Y3QgcmVn aW9uX2Rlc2NyaXB0b3IpOworCXNldHVwX2ZyZWVic2RfZ2R0KGdkdF9kZXNjKTsKKwlteWdk dC0+cmRfbGltaXQgPSBHVUVTVF9HRFRSX0xJTUlUOworCW15Z2R0LT5yZF9iYXNlID0gKHVu c2lnbmVkIGxvbmcpKHZ0b3BoeXMoZ2R0X2Rlc2MpICsgS0xPQURCQVNFKTsKKworCS8qCisJ ICogd2UgcGFzcyB0aGUgdmlydCBhZGRyIG9mIGNvbnRyb2xfcGFnZSBidXQgd2UgbmVlZAor CSAqIG5ldyB2aXJ0IGFkZHIgYXMgd2VsbAorCSAqLworCWtfY3BhZ2UtPmtjcF9jcCA9ICh1 bnNpZ25lZCBsb25nKSh2dG9waHlzKGNvbnRyb2xfcGFnZSkgKyBLTE9BREJBU0UpOworCWtf Y3BhZ2UtPmtjcF9lbnRyeV9wdCA9IGtsZC5rX2VudHJ5X3B0OworCisJLyogMTAgc2VnbWVu dHMgc2hvdWxkIGJlIG1vcmUgdGhhbiBlbm91Z2ggKi8KKwlmb3IgKGkgPSAwIDsgKGkgPCBr bGQubnVtX2hkcnMgJiYgaSA8PSAxMCk7IGkrKykKKwkJa2xvYWRfY29weWluX3NlZ21lbnQo JmtsZC5raGRyW2ldLGkpOworCisJbnVsbF9pZHQgPSAoc3RydWN0IHJlZ2lvbl9kZXNjcmlw dG9yKikKKwkgICAga2xvYWRfa21lbV9hbGxvYyhrZXJuZWxfbWFwLFBBR0VfU0laRSk7CisJ a19jcGFnZS0+a2NwX2lkdCA9ICh1bnNpZ25lZCBsb25nKXZ0b3BoeXMobnVsbF9pZHQpICsg S0xPQURCQVNFOworCS8qIFdpcGUgdGhlIElEVC4gKi8KKwludWxsX2lkdC0+cmRfbGltaXQg PSAwOworCW51bGxfaWR0LT5yZF9iYXNlID0gMDsKKwkvKgorCSAqIFRoaXMgbXVzdCBiZSBi dWlsdCBhZnRlciBhbGwgb3RoZXIgYWxsb2NhdGlvbnMgc28gaXQgY2FuCisJICogYnVpbGQg YSBwYWdlIHRhYmxlIGVudHJ5IGJhc2VkIG9uIG1pbiBtYXggYWRkcmVzc2VzCisJICovCisJ LyogcmV0dXJucyBuZXcgcGFnZSB0YWJsZSBwaHlzIGFkZHIgKi8KKwlwZ3RibCA9IGtsb2Fk X2J1aWxkX3BhZ2VfdGFibGUoKTsKKwlpZiAocGd0YmwgPT0gTlVMTCkKKwkJcmV0dXJuIChF Tk9NRU0pOworCWtsb2FkX3BndGJsID0gKHVuc2lnbmVkIGxvbmcpcGd0Ymw7CisJa19jcGFn ZS0+a2NwX3BndGJsID0gKHVuc2lnbmVkIGxvbmcpcGd0Ymw7CisKKwlrbG9hZF9yZWFkeSA9 IDE7CisKKwlpZiAoYm9vdHZlcmJvc2UpCisJCXByaW50ZigiJXM6XG5cdCIKKwkJICAgICAg ICJoZWFkX3ZhICAgICAgICAgMHglbHggKHBoeXMgMHglbHgpXG5cdCIKKwkJICAgICAgICJr ZXJuYmFzZSAgICAgICAgMHglbHhcblx0IgorCQkgICAgICAgImNvZGVfcGFnZSAgICAgICAw eCVseCAocGh5cyAweCVseClcblx0IgorCQkgICAgICAgImNvbnRyb2xfcGFnZSAgICAweCVs eCAocGh5cyAweCVseClcblx0IgorCQkgICAgICAgImdkdCAgICAgICAgICAgICAweCVseCAo cGh5cyAweCVseClcblx0IgorCQkgICAgICAgImlkdCAgICAgICAgICAgICAweCVseCAocGh5 cyAweCVseClcblx0IgorCQkgICAgICAgImtfZW50cnlfcHQgICAgICAweCVseFxuXHQiCisJ CSAgICAgICAicGd0YmwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAocGh5cyAweCVs eClcblx0IgorCQkgICAgICAgIm1heF9hZGRyICAgICAgICAgICAgICAgICAgICAgICAgICAg KHBoeXMgMHglbHgpXG5cdCIKKwkJICAgICAgICJtaW5fYWRkciAgICAgICAgICAgICAgICAg ICAgICAgICAgIChwaHlzIDB4JWx4KVxuXHQiCisJCSAgICAgICAibW9kdWxlcCAgICAgICAg ICAgICAgICAgICAgICAgICAgICAocGh5cyAweCVseClcblx0IgorCQkgICAgICAgInBoeXNm cmVlICAgICAgICAgICAgICAgICAgICAgICAgICAgIChwaHlzIDB4JWx4KVxuIiwKKwkJICAg ICAgIF9fZnVuY19fLAorCQkgICAgICAgKHVuc2lnbmVkIGxvbmcpa19pdGVtcy0+aGVhZF92 YSwKKwkJICAgICAgICh1bnNpZ25lZCBsb25nKXZ0b3BoeXMoa19pdGVtcy0+aGVhZF92YSks CisJCSAgICAgICAodW5zaWduZWQgbG9uZykoS0VSTkJBU0UgKyAodm1fcGFkZHJfdClrZXJu cGh5cyksCisJCSAgICAgICAodW5zaWduZWQgbG9uZykoY29udHJvbF9wYWdlICsgUEFHRV9T SVpFKSwKKwkJICAgICAgICh1bnNpZ25lZCBsb25nKXZ0b3BoeXMoY29udHJvbF9wYWdlICsg UEFHRV9TSVpFKSwKKwkJICAgICAgICh1bnNpZ25lZCBsb25nKWNvbnRyb2xfcGFnZSwKKwkJ ICAgICAgICh1bnNpZ25lZCBsb25nKXZ0b3BoeXMoY29udHJvbF9wYWdlKSwKKwkJICAgICAg ICh1bnNpZ25lZCBsb25nKW15Z2R0LCh1bnNpZ25lZCBsb25nKXZ0b3BoeXMobXlnZHQpLAor CQkgICAgICAgKHVuc2lnbmVkIGxvbmcpbnVsbF9pZHQsKHVuc2lnbmVkIGxvbmcpdnRvcGh5 cyhudWxsX2lkdCksCisJCSAgICAgICAodW5zaWduZWQgbG9uZylrbGQua19lbnRyeV9wdCwK KwkJICAgICAgICh1bnNpZ25lZCBsb25nKXBndGJsLAorCQkgICAgICAgKHVuc2lnbmVkIGxv bmcpbWF4X2FkZHIsCisJCSAgICAgICAodW5zaWduZWQgbG9uZyltaW5fYWRkciwKKwkJICAg ICAgICh1bnNpZ25lZCBsb25nKWtsZC5rX21vZHVsZXAsCisJCSAgICAgICAodW5zaWduZWQg bG9uZylrbGQua19waHlzZnJlZSk7CisJCisJaWYoISh1YXAtPmZsYWdzICYgKEtMT0FEX0VY RUMgfCBLTE9BRF9SRUJPT1QpKSkKKwkJZ290byBqdXN0X2xvYWQ7CisjaWYgZGVmaW5lZChT TVApCisJLyoKKwkgKiBCaW5kIHVzIHRvIENQVSAwIHNvIHRoYXQgYWxsIHNodXRkb3duIGNv ZGUgcnVucyB0aGVyZS4gIFNvbWUKKwkgKiBzeXN0ZW1zIGRvbid0IHNodXRkb3duIHByb3Bl cmx5IChpLmUuLCBBQ1BJIHBvd2VyIG9mZikgaWYgd2UKKwkgKiBydW4gb24gYW5vdGhlciBw cm9jZXNzb3IuCisJICovCisJcHJpbnRmKCJCaW5kaW5nIHByb2Nlc3MgdG8gY3B1IDBcbiIp OworCXRocmVhZF9sb2NrKGN1cnRocmVhZCk7CisJc2NoZWRfYmluZChjdXJ0aHJlYWQsIDAp OworCXRocmVhZF91bmxvY2soY3VydGhyZWFkKTsKKwlLQVNTRVJUKFBDUFVfR0VUKGNwdWlk KSA9PSAwLCAoIiVzOiBub3QgcnVubmluZyBvbiBjcHUgMCIsIF9fZnVuY19fKSk7CisjZW5k aWYKKwlpZih1YXAtPmZsYWdzICYgS0xPQURfUkVCT09UKSB7CisJCW10eF9sb2NrKCZHaWFu dCk7CisJCWtlcm5fcmVib290KFJCX0tMT0FEKTsKKwkJLyogc2hvdWxkIG5vdCByZXR1cm4g Ki8KKwkJbXR4X3VubG9jaygmR2lhbnQpOworCX0KKwkvKgorCSAqIHRoZSByZWJvb3QgY29k ZSB3aWxsIGRvIGEgbW9kdWxlIHNodXRkb3duIHNvIGl0IGlzIG5vdAorCSAqIHBhcnQga2xv YWRfc2h1dGRvd25fZmluYWwgYnV0IGl0IG5lZWRzIHRvIGhhcHBlbi4KKwkgKiBTbyBpbiB0 aGUgY2FzZSBvZiBleGVjIHJ1biBpdCBoZXJlCisJICovCisJaWYgKGJvb3R2ZXJib3NlKQor CQlwcmludGYoIiVzOiBtb2R1bGVfc2h1dGRvd25cbiIsIF9fZnVuY19fKTsKKwlrbG9hZF9t b2R1bGVfc2h1dGRvd24oKTsKKwlrbG9hZF9zaHV0ZG93bl9maW5hbChOVUxMLCBSQl9LTE9B RCk7CitqdXN0X2xvYWQ6CisJcHJpbnRmKCIlczogS2VybmVsIGltYWdlIGxvYWRlZCB3YWl0 aW5nIGZvciByZWJvb3RcbiIsIF9fZnVuY19fKTsKKwlyZXR1cm4gKDApOworfQorCitzdGF0 aWMgdm9pZAora2xvYWRfc2h1dGRvd25fZmluYWwodm9pZCAqYXJnLCBpbnQgaG93dG8pCit7 CisJaW50IHJldDsKKwljcHVzZXRfdCBtYXA7CisKKwkvKiBKdXN0IHRvIG1ha2Ugc3VyZSB3 ZSBhcmUgb24gY3B1IDAgKi8KKwlLQVNTRVJUKFBDUFVfR0VUKGNwdWlkKSA9PSAwLCAoIiVz OiBub3QgcnVubmluZyBvbiBjcHUgMCIsIF9fZnVuY19fKSk7CisJaWYgKGtsb2FkX3JlYWR5 KSB7CisJCXByaW50ZigiJXM6IHN1c3BlbmQgQVBzXG4iLF9fRlVOQ1RJT05fXyk7CisJCW1h cCA9IGFsbF9jcHVzOworCQkvKiB3ZSBzaG91bGQgYmUgYm91bmQgdG8gY3B1IDAgYXQgdGhp cyBwb2ludCAqLworCQlwcmludGYoIiVzICBjcHVpZCAlZFxuIixfX0ZVTkNUSU9OX18sUENQ VV9HRVQoY3B1aWQpKTsKKwkJQ1BVX0NMUihQQ1BVX0dFVChjcHVpZCksICZtYXApOworCQlD UFVfTkFORCgmbWFwLCAmc3RvcHBlZF9jcHVzKTsKKwkJaWYgKCFDUFVfRU1QVFkoJm1hcCkp IHsKKwkJCXByaW50ZigiY3B1X3Jlc2V0OiBTdG9wcGluZyBvdGhlciBDUFVzXG4iKTsKKwkJ CXN1c3BlbmRfY3B1cyhtYXApOworCQl9CisKKwkJaWYgKGJvb3R2ZXJib3NlKQorCQkJcHJp bnRmKCIlczogY2xlYXIgYWxsIGhhbmRsZXJzXG4iLCBfX2Z1bmNfXyk7CisJCWludHJfY2xl YXJfYWxsX2hhbmRsZXJzKCk7CisKKwkJaWYgKGJvb3R2ZXJib3NlKQorCQkJcHJpbnRmKCIl czogbG9hcGljX2NsZWFyX2xhcGljXG4iLCBfX2Z1bmNfXyk7CisJCWxhcGljX2NsZWFyX2xh cGljKDEpOworCisJCWludHJfc3VzcGVuZCgpOworCisJCWlmIChib290dmVyYm9zZSkKKwkJ CXByaW50ZigiJXMgZGlzYWJsZV9pbnRlcnJ1cHRzIGNwdWlkICVkXG4iLAorCQkJICAgIF9f ZnVuY19fLCBQQ1BVX0dFVChjcHVpZCkpOworCQlkaXNhYmxlX2ludHIoKTsKKworCQlwcmlu dGYoImNhbGxpbmcgcmVsb2NhdGVfa2VybmVsXG4iKTsKKwkJcmV0ID0gcmVsb2NhdGVfa2Vy bmVsKHZ0b3BoeXMoa19pdGVtcy0+aGVhZF92YSkgKyBLTE9BREJBU0UsCisJCQkJICAgICAg LyogZGVzdCBhZGRyIGkuZS4gb3ZlcndyaXRlIGV4aXN0aW5nIGtlcm5lbCAqLworCQkJCSAg ICAgIEtFUk5CQVNFICsgKHZtX3BhZGRyX3Qpa2VybnBoeXMsCisJCQkJICAgICAgdnRvcGh5 cyhjb2RlX3BhZ2UpICsgS0xPQURCQVNFLAorCQkJCSAgICAgIGNvbnRyb2xfcGFnZSk7CisJ CS8qIGN1cnJlbnRseSB0aGlzIHdpbGwgbmV2ZXIgaGFwcGVuICovCisJCXByaW50ZigiXHRy ZWxvY2F0ZV9uZXdfa2VybmVsIHJldHVybmVkICVkXG4iLHJldCk7CisJfSBlbHNlIHsKKwkJ cHJpbnRmKCJrbG9hZF9zaHV0ZG93bl9maW5hbCBjYWxsZWQgd2l0aG91dCAiCisJCSAgICAi YSBuZXcga2VybmVsIGxvYWRlZFxuIik7CisJfQorfQpkaWZmIC0tZ2l0IGEvc3lzL2tlcm4v a2Vybl9tb2R1bGUuYyBiL3N5cy9rZXJuL2tlcm5fbW9kdWxlLmMKaW5kZXggYjc2OTMyMC4u MmE4ODBjNSAxMDA2NDQKLS0tIGEvc3lzL2tlcm4va2Vybl9tb2R1bGUuYworKysgYi9zeXMv a2Vybi9rZXJuX21vZHVsZS5jCkBAIC02NCw2ICs2NCw3IEBAIHN0YXRpYyBUQUlMUV9IRUFE KG1vZHVsZWxpc3QsIG1vZHVsZSkgbW9kdWxlczsKIHN0cnVjdCBzeCBtb2R1bGVzX3N4Owog c3RhdGljIGludCBuZXh0aWQgPSAxOwogc3RhdGljIHZvaWQgbW9kdWxlX3NodXRkb3duKHZv aWQgKiwgaW50KTsKK3ZvaWQga2xvYWRfbW9kdWxlX3NodXRkb3duKHZvaWQpOwogCiBzdGF0 aWMgaW50CiBtb2RldmVudF9ub3AobW9kdWxlX3QgbW9kLCBpbnQgd2hhdCwgdm9pZCAqYXJn KQpAQCAtMTA3LDYgKzEwOCwxMiBAQCBtb2R1bGVfc2h1dGRvd24odm9pZCAqYXJnMSwgaW50 IGFyZzIpCiB9CiAKIHZvaWQKK2tsb2FkX21vZHVsZV9zaHV0ZG93bih2b2lkKSB7CisJbW9k dWxlX3NodXRkb3duKE5VTEwsIDApOworfQorCisKK3ZvaWQKIG1vZHVsZV9yZWdpc3Rlcl9p bml0KGNvbnN0IHZvaWQgKmFyZykKIHsKIAljb25zdCBtb2R1bGVkYXRhX3QgKmRhdGEgPSAo Y29uc3QgbW9kdWxlZGF0YV90ICopYXJnOwpkaWZmIC0tZ2l0IGEvc3lzL2tlcm4vc3lzY2Fs bHMuYyBiL3N5cy9rZXJuL3N5c2NhbGxzLmMKaW5kZXggOTZmMjQwMC4uNmVkZDdmYSAxMDA2 NDQKLS0tIGEvc3lzL2tlcm4vc3lzY2FsbHMuYworKysgYi9zeXMva2Vybi9zeXNjYWxscy5j CkBAIC0zLDcgKzMsNyBAQAogICoKICAqIERPIE5PVCBFRElULS0gdGhpcyBmaWxlIGlzIGF1 dG9tYXRpY2FsbHkgZ2VuZXJhdGVkLgogICogJEZyZWVCU0QkCi0gKiBjcmVhdGVkIGZyb20g RnJlZUJTRDogaGVhZC9zeXMva2Vybi9zeXNjYWxscy5tYXN0ZXIgMjQyOTU4IDIwMTItMTEt MTMgMTI6NTI6MzFaIGtpYiAKKyAqIGNyZWF0ZWQgZnJvbSBGcmVlQlNECiAgKi8KIAogY29u c3QgY2hhciAqc3lzY2FsbG5hbWVzW10gPSB7CkBAIC01NDAsNCArNTQwLDUgQEAgY29uc3Qg Y2hhciAqc3lzY2FsbG5hbWVzW10gPSB7CiAJInBvc2l4X2ZhbGxvY2F0ZSIsCQkJLyogNTMw ID0gcG9zaXhfZmFsbG9jYXRlICovCiAJInBvc2l4X2ZhZHZpc2UiLAkJCS8qIDUzMSA9IHBv c2l4X2ZhZHZpc2UgKi8KIAkid2FpdDYiLAkJCS8qIDUzMiA9IHdhaXQ2ICovCisJImtsb2Fk IiwJCQkvKiA1MzMgPSBrbG9hZCAqLwogfTsKZGlmZiAtLWdpdCBhL3N5cy9rZXJuL3N5c2Nh bGxzLm1hc3RlciBiL3N5cy9rZXJuL3N5c2NhbGxzLm1hc3RlcgppbmRleCAxNDhkZWEzLi5l YjJiNjQ4IDEwMDY0NAotLS0gYS9zeXMva2Vybi9zeXNjYWxscy5tYXN0ZXIKKysrIGIvc3lz L2tlcm4vc3lzY2FsbHMubWFzdGVyCkBAIC05NTUsNSArOTU1LDcgQEAKIAkJCQkgICAgaW50 ICpzdGF0dXMsIGludCBvcHRpb25zLCBcCiAJCQkJICAgIHN0cnVjdCBfX3dydXNhZ2UgKndy dXNhZ2UsIFwKIAkJCQkgICAgc2lnaW5mb190ICppbmZvKTsgfQorNTMzCUFVRV9OVUxMCVNU RCAJeyBpbnQga2xvYWQoY29uc3Qgdm9pZCAqYnVmLCBzaXplX3QgYnVmbGVuLCBcCisJCQkJ ICBpbnQgZmxhZ3MpOyB9CiA7IFBsZWFzZSBjb3B5IGFueSBhZGRpdGlvbnMgYW5kIGNoYW5n ZXMgdG8gdGhlIGZvbGxvd2luZyBjb21wYXRhYmlsaXR5IHRhYmxlczoKIDsgc3lzL2NvbXBh dC9mcmVlYnNkMzIvc3lzY2FsbHMubWFzdGVyCmRpZmYgLS1naXQgYS9zeXMva2Vybi9zeXN0 cmFjZV9hcmdzLmMgYi9zeXMva2Vybi9zeXN0cmFjZV9hcmdzLmMKaW5kZXggYzc1NWY5Mi4u YzQ4MDU3YSAxMDA2NDQKLS0tIGEvc3lzL2tlcm4vc3lzdHJhY2VfYXJncy5jCisrKyBiL3N5 cy9rZXJuL3N5c3RyYWNlX2FyZ3MuYwpAQCAtMzI4Niw2ICszMjg2LDE1IEBAIHN5c3RyYWNl X2FyZ3MoaW50IHN5c251bSwgdm9pZCAqcGFyYW1zLCB1aW50NjRfdCAqdWFyZywgaW50ICpu X2FyZ3MpCiAJCSpuX2FyZ3MgPSA2OwogCQlicmVhazsKIAl9CisJLyoga2xvYWQgKi8KKwlj YXNlIDUzMzogeworCQlzdHJ1Y3Qga2xvYWRfYXJncyAqcCA9IHBhcmFtczsKKwkJdWFyZ1sw XSA9IChpbnRwdHJfdCkgcC0+YnVmOyAvKiBjb25zdCB2b2lkICogKi8KKwkJdWFyZ1sxXSA9 IHAtPmJ1ZmxlbjsgLyogc2l6ZV90ICovCisJCWlhcmdbMl0gPSBwLT5mbGFnczsgLyogaW50 ICovCisJCSpuX2FyZ3MgPSAzOworCQlicmVhazsKKwl9CiAJZGVmYXVsdDoKIAkJKm5fYXJn cyA9IDA7CiAJCWJyZWFrOwpAQCAtODc0NSw2ICs4NzU0LDIyIEBAIHN5c3RyYWNlX2VudHJ5 X3NldGFyZ2Rlc2MoaW50IHN5c251bSwgaW50IG5keCwgY2hhciAqZGVzYywgc2l6ZV90IGRl c2NzeikKIAkJCWJyZWFrOwogCQl9OwogCQlicmVhazsKKwkvKiBrbG9hZCAqLworCWNhc2Ug NTMzOgorCQlzd2l0Y2gobmR4KSB7CisJCWNhc2UgMDoKKwkJCXAgPSAiY29uc3Qgdm9pZCAq IjsKKwkJCWJyZWFrOworCQljYXNlIDE6CisJCQlwID0gInNpemVfdCI7CisJCQlicmVhazsK KwkJY2FzZSAyOgorCQkJcCA9ICJpbnQiOworCQkJYnJlYWs7CisJCWRlZmF1bHQ6CisJCQli cmVhazsKKwkJfTsKKwkJYnJlYWs7CiAJZGVmYXVsdDoKIAkJYnJlYWs7CiAJfTsKQEAgLTEw NjM4LDYgKzEwNjYzLDExIEBAIHN5c3RyYWNlX3JldHVybl9zZXRhcmdkZXNjKGludCBzeXNu dW0sIGludCBuZHgsIGNoYXIgKmRlc2MsIHNpemVfdCBkZXNjc3opCiAJCWlmIChuZHggPT0g MCB8fCBuZHggPT0gMSkKIAkJCXAgPSAiaW50IjsKIAkJYnJlYWs7CisJLyoga2xvYWQgKi8K KwljYXNlIDUzMzoKKwkJaWYgKG5keCA9PSAwIHx8IG5keCA9PSAxKQorCQkJcCA9ICJpbnQi OworCQlicmVhazsKIAlkZWZhdWx0OgogCQlicmVhazsKIAl9OwpkaWZmIC0tZ2l0IGEvc3lz L3N5cy9ldmVudGhhbmRsZXIuaCBiL3N5cy9zeXMvZXZlbnRoYW5kbGVyLmgKaW5kZXggNmQz N2JmNC4uMzFhYTRlNCAxMDA2NDQKLS0tIGEvc3lzL3N5cy9ldmVudGhhbmRsZXIuaAorKysg Yi9zeXMvc3lzL2V2ZW50aGFuZGxlci5oCkBAIC0xNzMsNiArMTczLDcgQEAgdHlwZWRlZiB2 b2lkICgqc2h1dGRvd25fZm4pKHZvaWQgKiwgaW50KTsKICNkZWZpbmUJU0hVVERPV05fUFJJ X0ZJUlNUCUVWRU5USEFORExFUl9QUklfRklSU1QKICNkZWZpbmUJU0hVVERPV05fUFJJX0RF RkFVTFQJRVZFTlRIQU5ETEVSX1BSSV9BTlkKICNkZWZpbmUJU0hVVERPV05fUFJJX0xBU1QJ RVZFTlRIQU5ETEVSX1BSSV9MQVNUCisjZGVmaW5lCVNIVVRET1dOX1BSSV9LTE9BRAlFVkVO VEhBTkRMRVJfUFJJX0xBU1QgLSAxMDAKIAogRVZFTlRIQU5ETEVSX0RFQ0xBUkUoc2h1dGRv d25fcHJlX3N5bmMsIHNodXRkb3duX2ZuKTsJLyogYmVmb3JlIGZzIHN5bmMgKi8KIEVWRU5U SEFORExFUl9ERUNMQVJFKHNodXRkb3duX3Bvc3Rfc3luYywgc2h1dGRvd25fZm4pOwkvKiBh ZnRlciBmcyBzeW5jICovCmRpZmYgLS1naXQgYS9zeXMvc3lzL2tsb2FkLmggYi9zeXMvc3lz L2tsb2FkLmgKbmV3IGZpbGUgbW9kZSAxMDA2NDQKaW5kZXggMDAwMDAwMC4uMDkyMDE3Ngot LS0gL2Rldi9udWxsCisrKyBiL3N5cy9zeXMva2xvYWQuaApAQCAtMCwwICsxLDg4IEBACisv KgorICogQ29weXJpZ2h0IChjKSAyMDExIC0gMjAxMgorICoJUnVzc2VsbCBDYXR0ZWxhbiBE aWdpdGFsIEVsdmVzIEluYworICogQ29weXJpZ2h0IChjKSAKKyAqCUlzaWxvbiBTeXN0ZW1z LCBMTEMuICBBbGwgcmlnaHRzIHJlc2VydmVkLgorICoKKyAqIFJlZGlzdHJpYnV0aW9uIGFu ZCB1c2UgaW4gc291cmNlIGFuZCBiaW5hcnkgZm9ybXMsIHdpdGggb3Igd2l0aG91dAorICog bW9kaWZpY2F0aW9uLCBhcmUgcGVybWl0dGVkIHByb3ZpZGVkIHRoYXQgdGhlIGZvbGxvd2lu ZyBjb25kaXRpb25zCisgKiBhcmUgbWV0OgorICogMS4gUmVkaXN0cmlidXRpb25zIG9mIHNv dXJjZSBjb2RlIG11c3QgcmV0YWluIHRoZSBhYm92ZSBjb3B5cmlnaHQKKyAqICAgIG5vdGlj ZSwgdGhpcyBsaXN0IG9mIGNvbmRpdGlvbnMgYW5kIHRoZSBmb2xsb3dpbmcgZGlzY2xhaW1l ci4KKyAqIDIuIFJlZGlzdHJpYnV0aW9ucyBpbiBiaW5hcnkgZm9ybSBtdXN0IHJlcHJvZHVj ZSB0aGUgYWJvdmUgY29weXJpZ2h0CisgKiAgICBub3RpY2UsIHRoaXMgbGlzdCBvZiBjb25k aXRpb25zIGFuZCB0aGUgZm9sbG93aW5nIGRpc2NsYWltZXIgaW4gdGhlCisgKiAgICBkb2N1 bWVudGF0aW9uIGFuZC9vciBvdGhlciBtYXRlcmlhbHMgcHJvdmlkZWQgd2l0aCB0aGUgZGlz dHJpYnV0aW9uLgorICoKKyAqIFRISVMgU09GVFdBUkUgSVMgUFJPVklERUQgQlkgVEhFIEFV VEhPUiBBTkQgQ09OVFJJQlVUT1JTIGBgQVMgSVMnJyBBTkQKKyAqIEFOWSBFWFBSRVNTIE9S IElNUExJRUQgV0FSUkFOVElFUywgSU5DTFVESU5HLCBCVVQgTk9UIExJTUlURUQgVE8sIFRI RQorICogSU1QTElFRCBXQVJSQU5USUVTIE9GIE1FUkNIQU5UQUJJTElUWSBBTkQgRklUTkVT UyBGT1IgQSBQQVJUSUNVTEFSIFBVUlBPU0UKKyAqIEFSRSBESVNDTEFJTUVELiAgSU4gTk8g RVZFTlQgU0hBTEwgVEhFIEFVVEhPUiBPUiBDT05UUklCVVRPUlMgQkUgTElBQkxFCisgKiBG T1IgQU5ZIERJUkVDVCwgSU5ESVJFQ1QsIElOQ0lERU5UQUwsIFNQRUNJQUwsIEVYRU1QTEFS WSwgT1IgQ09OU0VRVUVOVElBTAorICogREFNQUdFUyAoSU5DTFVESU5HLCBCVVQgTk9UIExJ TUlURUQgVE8sIFBST0NVUkVNRU5UIE9GIFNVQlNUSVRVVEUgR09PRFMKKyAqIE9SIFNFUlZJ Q0VTOyBMT1NTIE9GIFVTRSwgREFUQSwgT1IgUFJPRklUUzsgT1IgQlVTSU5FU1MgSU5URVJS VVBUSU9OKQorICogSE9XRVZFUiBDQVVTRUQgQU5EIE9OIEFOWSBUSEVPUlkgT0YgTElBQklM SVRZLCBXSEVUSEVSIElOIENPTlRSQUNULCBTVFJJQ1QKKyAqIExJQUJJTElUWSwgT1IgVE9S VCAoSU5DTFVESU5HIE5FR0xJR0VOQ0UgT1IgT1RIRVJXSVNFKSBBUklTSU5HIElOIEFOWSBX QVkKKyAqIE9VVCBPRiBUSEUgVVNFIE9GIFRISVMgU09GVFdBUkUsIEVWRU4gSUYgQURWSVNF RCBPRiBUSEUgUE9TU0lCSUxJVFkgT0YKKyAqIFNVQ0ggREFNQUdFLgorICoKKyAqLworCisj aWZuZGVmIF9fS0xPQURfSF9fCisjZGVmaW5lIF9fS0xPQURfSF9fCisKKyNpbmNsdWRlIDxz eXMvcGFyYW0uaD4KKyNpbmNsdWRlIDxzeXMvdHlwZXMuaD4KKworI2luY2x1ZGUgPHZtL3Zt Lmg+CisjaW5jbHVkZSA8dm0vdm1fcGFnZS5oPgorCisjZGVmaW5lIEtMT0FEX0xPQUQJCSAw CisjZGVmaW5lIEtMT0FEX1JFQk9PVAkJKDEgPDwgMCApCisjZGVmaW5lIEtMT0FEX0VYRUMJ CSgxIDw8IDEgKQorCitzdHJ1Y3Qga2xvYWRfc2VnbWVudCB7CisJdm9pZAkJICAgICAgICpr X2J1ZjsKKwlzaXplX3QJCQlrX21lbXN6OworCXVuc2lnbmVkIGxvbmcJICAgICAgICprX3Bh Z2VzOworCXVuc2lnbmVkIGxvbmcJCWtfc2VnX3N0YXJ0OworfTsKKworc3RydWN0IGtsb2Fk IHsKKwlzdHJ1Y3Qga2xvYWRfc2VnbWVudAlraGRyWzEwXTsKKwlpbnQJCQludW1faGRyczsK Kwl1bnNpZ25lZCBsb25nCQlrX2VudHJ5X3B0OworCXVuc2lnbmVkIGludAkJa19tb2R1bGVw OworCXVuc2lnbmVkIGludAkJa19waHlzZnJlZTsKK307CisKKy8vdHlwZWRlZiB1X2xvbmcg a2xvYWRfaXRlbV90OworI2RlZmluZSBLTE9BRF9ERVNUSU5BVElPTiAgMHgxCisjZGVmaW5l IEtMT0FEX0lORElSRUNUICAgICAweDIKKyNkZWZpbmUgS0xPQURfRE9ORSAgICAgICAgIDB4 NAorI2RlZmluZSBLTE9BRF9TT1VSQ0UgICAgICAgMHg4CisKK3N0cnVjdCBrbG9hZF9pdGVt cyB7CisJdW5zaWduZWQgbG9uZyBoZWFkOworCXZtX29mZnNldF90IGhlYWRfdmE7CisJdW5z aWduZWQgbG9uZyAqbGFzdF9pdGVtOworCXVuc2lnbmVkIGxvbmcgKml0ZW07CisJaW50IGlf Y291bnQ7CisJdW5zaWduZWQgbG9uZyBmbGFnczsgIC8qIG5vdCB1c2VkIHlldCAqLworfTsK KworLyoKKyAqIGRlZmluZWQgaW4gPGFyY2g+L2tsb2FkLmMKKyAqLworcHRfZW50cnlfdCAq IGtsb2FkX2J1aWxkX3BhZ2VfdGFibGUodm9pZCk7Cit2b2lkIHNldHVwX2ZyZWVic2RfZ2R0 KHVpbnQ2NF90ICopOwordm9pZCBrbG9hZF9tb2R1bGVfc2h1dGRvd24odm9pZCk7CisKKy8q CisgKiBkZWZpbmVkIGluIDxhcmNoPi9rbG9hZF9leGVjLlMKKyAqLwordW5zaWduZWQgbG9u ZyByZWxvY2F0ZV9rZXJuZWwodW5zaWduZWQgbG9uZyBpbmRpcmVjdGlvbl9wYWdlLAorICAg IHVuc2lnbmVkIGxvbmcgcGFnZV9saXN0LCB1bnNpZ25lZCBsb25nIGNvZGVfcGFnZSwKKyAg ICB1bnNpZ25lZCBsb25nIGNvbnRyb2xfcGFnZSk7CitleHRlcm4gaW50IHJlbG9jYXRlX2tl cm5lbF9zaXplOworCisjZW5kaWYKZGlmZiAtLWdpdCBhL3N5cy9zeXMvcmVib290LmggYi9z eXMvc3lzL3JlYm9vdC5oCmluZGV4IDZiOGUyNWUuLjliNzAxNjAgMTAwNjQ0Ci0tLSBhL3N5 cy9zeXMvcmVib290LmgKKysrIGIvc3lzL3N5cy9yZWJvb3QuaApAQCAtNTksNiArNTksNyBA QAogI2RlZmluZQlSQl9SRVNFUlZFRDEJMHg0MDAwMAkvKiByZXNlcnZlZCBmb3IgaW50ZXJu YWwgdXNlIG9mIGJvb3QgYmxvY2tzICovCiAjZGVmaW5lCVJCX1JFU0VSVkVEMgkweDgwMDAw CS8qIHJlc2VydmVkIGZvciBpbnRlcm5hbCB1c2Ugb2YgYm9vdCBibG9ja3MgKi8KICNkZWZp bmUJUkJfUEFVU0UJMHgxMDAwMDAgLyogcGF1c2UgYWZ0ZXIgZWFjaCBvdXRwdXQgbGluZSBk dXJpbmcgcHJvYmUgKi8KKyNkZWZpbmUJUkJfS0xPQUQJMHgyMDAwMDAgLyogcmVib290IHVz aW5nIGtsb2FkJ2VkIGtlcm5lbCBpbWFnZSAqLwogI2RlZmluZQlSQl9NVUxUSVBMRQkweDIw MDAwMDAwCS8qIHVzZSBtdWx0aXBsZSBjb25zb2xlcyAqLwogCiAjZGVmaW5lCVJCX0JPT1RJ TkZPCTB4ODAwMDAwMDAJLyogaGF2ZSBgc3RydWN0IGJvb3RpbmZvIConIGFyZyAqLwpkaWZm IC0tZ2l0IGEvc3lzL3N5cy9zeXNjYWxsLmggYi9zeXMvc3lzL3N5c2NhbGwuaAppbmRleCA2 YjBjZDY3Li5mOTBjYWQyIDEwMDY0NAotLS0gYS9zeXMvc3lzL3N5c2NhbGwuaAorKysgYi9z eXMvc3lzL3N5c2NhbGwuaApAQCAtMyw3ICszLDcgQEAKICAqCiAgKiBETyBOT1QgRURJVC0t IHRoaXMgZmlsZSBpcyBhdXRvbWF0aWNhbGx5IGdlbmVyYXRlZC4KICAqICRGcmVlQlNEJAot ICogY3JlYXRlZCBmcm9tIEZyZWVCU0Q6IGhlYWQvc3lzL2tlcm4vc3lzY2FsbHMubWFzdGVy IDI0Mjk1OCAyMDEyLTExLTEzIDEyOjUyOjMxWiBraWIgCisgKiBjcmVhdGVkIGZyb20gRnJl ZUJTRAogICovCiAKICNkZWZpbmUJU1lTX3N5c2NhbGwJMApAQCAtNDUyLDQgKzQ1Miw1IEBA CiAjZGVmaW5lCVNZU19wb3NpeF9mYWxsb2NhdGUJNTMwCiAjZGVmaW5lCVNZU19wb3NpeF9m YWR2aXNlCTUzMQogI2RlZmluZQlTWVNfd2FpdDYJNTMyCi0jZGVmaW5lCVNZU19NQVhTWVND QUxMCTUzMworI2RlZmluZQlTWVNfa2xvYWQJNTMzCisjZGVmaW5lCVNZU19NQVhTWVNDQUxM CTUzNApkaWZmIC0tZ2l0IGEvc3lzL3N5cy9zeXNjYWxsLm1rIGIvc3lzL3N5cy9zeXNjYWxs Lm1rCmluZGV4IDI1ZjA0NzAuLjM5ZmQwNWIgMTAwNjQ0Ci0tLSBhL3N5cy9zeXMvc3lzY2Fs bC5taworKysgYi9zeXMvc3lzL3N5c2NhbGwubWsKQEAgLTEsNyArMSw3IEBACiAjIEZyZWVC U0Qgc3lzdGVtIGNhbGwgbmFtZXMuCiAjIERPIE5PVCBFRElULS0gdGhpcyBmaWxlIGlzIGF1 dG9tYXRpY2FsbHkgZ2VuZXJhdGVkLgogIyAkRnJlZUJTRCQKLSMgY3JlYXRlZCBmcm9tIEZy ZWVCU0Q6IGhlYWQvc3lzL2tlcm4vc3lzY2FsbHMubWFzdGVyIDI0Mjk1OCAyMDEyLTExLTEz IDEyOjUyOjMxWiBraWIgCisjIGNyZWF0ZWQgZnJvbSBGcmVlQlNECiBNSUFTTSA9ICBcCiAJ c3lzY2FsbC5vIFwKIAlleGl0Lm8gXApAQCAtNDAwLDQgKzQwMCw1IEBAIE1JQVNNID0gIFwK IAlyY3RsX3JlbW92ZV9ydWxlLm8gXAogCXBvc2l4X2ZhbGxvY2F0ZS5vIFwKIAlwb3NpeF9m YWR2aXNlLm8gXAotCXdhaXQ2Lm8KKwl3YWl0Ni5vIFwKKwlrbG9hZC5vCmRpZmYgLS1naXQg YS9zeXMvc3lzL3N5c3Byb3RvLmggYi9zeXMvc3lzL3N5c3Byb3RvLmgKaW5kZXggZWY1OWFk NS4uODFkYWMxNSAxMDA2NDQKLS0tIGEvc3lzL3N5cy9zeXNwcm90by5oCisrKyBiL3N5cy9z eXMvc3lzcHJvdG8uaApAQCAtMyw3ICszLDcgQEAKICAqCiAgKiBETyBOT1QgRURJVC0tIHRo aXMgZmlsZSBpcyBhdXRvbWF0aWNhbGx5IGdlbmVyYXRlZC4KICAqICRGcmVlQlNEJAotICog Y3JlYXRlZCBmcm9tIEZyZWVCU0Q6IGhlYWQvc3lzL2tlcm4vc3lzY2FsbHMubWFzdGVyIDI0 Mjk1OCAyMDEyLTExLTEzIDEyOjUyOjMxWiBraWIgCisgKiBjcmVhdGVkIGZyb20gRnJlZUJT RAogICovCiAKICNpZm5kZWYgX1NZU19TWVNQUk9UT19IXwpAQCAtMTc2Miw2ICsxNzYyLDEx IEBAIHN0cnVjdCB3YWl0Nl9hcmdzIHsKIAljaGFyIHdydXNhZ2VfbF9bUEFETF8oc3RydWN0 IF9fd3J1c2FnZSAqKV07IHN0cnVjdCBfX3dydXNhZ2UgKiB3cnVzYWdlOyBjaGFyIHdydXNh Z2Vfcl9bUEFEUl8oc3RydWN0IF9fd3J1c2FnZSAqKV07CiAJY2hhciBpbmZvX2xfW1BBRExf KHNpZ2luZm9fdCAqKV07IHNpZ2luZm9fdCAqIGluZm87IGNoYXIgaW5mb19yX1tQQURSXyhz aWdpbmZvX3QgKildOwogfTsKK3N0cnVjdCBrbG9hZF9hcmdzIHsKKwljaGFyIGJ1Zl9sX1tQ QURMXyhjb25zdCB2b2lkICopXTsgY29uc3Qgdm9pZCAqIGJ1ZjsgY2hhciBidWZfcl9bUEFE Ul8oY29uc3Qgdm9pZCAqKV07CisJY2hhciBidWZsZW5fbF9bUEFETF8oc2l6ZV90KV07IHNp emVfdCBidWZsZW47IGNoYXIgYnVmbGVuX3JfW1BBRFJfKHNpemVfdCldOworCWNoYXIgZmxh Z3NfbF9bUEFETF8oaW50KV07IGludCBmbGFnczsgY2hhciBmbGFnc19yX1tQQURSXyhpbnQp XTsKK307CiBpbnQJbm9zeXMoc3RydWN0IHRocmVhZCAqLCBzdHJ1Y3Qgbm9zeXNfYXJncyAq KTsKIHZvaWQJc3lzX3N5c19leGl0KHN0cnVjdCB0aHJlYWQgKiwgc3RydWN0IHN5c19leGl0 X2FyZ3MgKik7CiBpbnQJc3lzX2Zvcmsoc3RydWN0IHRocmVhZCAqLCBzdHJ1Y3QgZm9ya19h cmdzICopOwpAQCAtMjE0NCw2ICsyMTQ5LDcgQEAgaW50CXN5c19yY3RsX3JlbW92ZV9ydWxl KHN0cnVjdCB0aHJlYWQgKiwgc3RydWN0IHJjdGxfcmVtb3ZlX3J1bGVfYXJncyAqKTsKIGlu dAlzeXNfcG9zaXhfZmFsbG9jYXRlKHN0cnVjdCB0aHJlYWQgKiwgc3RydWN0IHBvc2l4X2Zh bGxvY2F0ZV9hcmdzICopOwogaW50CXN5c19wb3NpeF9mYWR2aXNlKHN0cnVjdCB0aHJlYWQg Kiwgc3RydWN0IHBvc2l4X2ZhZHZpc2VfYXJncyAqKTsKIGludAlzeXNfd2FpdDYoc3RydWN0 IHRocmVhZCAqLCBzdHJ1Y3Qgd2FpdDZfYXJncyAqKTsKK2ludAlzeXNfa2xvYWQoc3RydWN0 IHRocmVhZCAqLCBzdHJ1Y3Qga2xvYWRfYXJncyAqKTsKIAogI2lmZGVmIENPTVBBVF80Mwog CkBAIC0yODQwLDYgKzI4NDYsNyBAQCBpbnQJZnJlZWJzZDdfc2htY3RsKHN0cnVjdCB0aHJl YWQgKiwgc3RydWN0IGZyZWVic2Q3X3NobWN0bF9hcmdzICopOwogI2RlZmluZQlTWVNfQVVF X3Bvc2l4X2ZhbGxvY2F0ZQlBVUVfTlVMTAogI2RlZmluZQlTWVNfQVVFX3Bvc2l4X2ZhZHZp c2UJQVVFX05VTEwKICNkZWZpbmUJU1lTX0FVRV93YWl0NglBVUVfV0FJVDYKKyNkZWZpbmUJ U1lTX0FVRV9rbG9hZAlBVUVfTlVMTAogCiAjdW5kZWYgUEFEXwogI3VuZGVmIFBBRExfCmRp ZmYgLS1naXQgYS9zeXMveDg2L3g4Ni9pbnRyX21hY2hkZXAuYyBiL3N5cy94ODYveDg2L2lu dHJfbWFjaGRlcC5jCmluZGV4IDMxY2M4MGIuLmVlZTc2NzggMTAwNjQ0Ci0tLSBhL3N5cy94 ODYveDg2L2ludHJfbWFjaGRlcC5jCisrKyBiL3N5cy94ODYveDg2L2ludHJfbWFjaGRlcC5j CkBAIC0xOTcsNiArMTk3LDM3IEBAIGludHJfYWRkX2hhbmRsZXIoY29uc3QgY2hhciAqbmFt ZSwgaW50IHZlY3RvciwgZHJpdmVyX2ZpbHRlcl90IGZpbHRlciwKIH0KIAogaW50CitpbnRy X2NsZWFyX2FsbF9oYW5kbGVycyh2b2lkKQoreworCWludCBpOworCXN0cnVjdCBpbnRzcmMg KmlzcmM7CisKKwltdHhfbG9jaygmaW50cl90YWJsZV9sb2NrKTsKKwlmb3IgKGkgPSAwOyBp IDwgTlVNX0lPX0lOVFM7IGkrKykgeworCQlpc3JjID0gaW50ZXJydXB0X3NvdXJjZXNbaV07 CisJCWlmIChpc3JjICE9IE5VTEwgJiYgaXNyYy0+aXNfaGFuZGxlcnMgPiAwKSB7CisJCQlw cmludGYoIiVzOiVkIGlzcmNbJWRdICVwIGlzX2hhbmRsZXJzICVkXG4iLAorCQkJICAgICAg IF9fRlVOQ1RJT05fXyxfX0xJTkVfXyxpLGlzcmMsCisJCQkgICAgICAgaXNyYy0+aXNfaGFu ZGxlcnMpOworCQkJICAgICAgIGlzcmMtPmlzX2hhbmRsZXJzLS07CisJCQlpZiAoaXNyYy0+ aXNfaGFuZGxlcnMgPT0gMCkgeworCQkJCXByaW50ZigiXHQgZGlzX3NvdXJjZSAlcCBkaXNf aW50ciAlcFxuIiwKKwkJCQkgICAgICAgaXNyYy0+aXNfcGljLT5waWNfZGlzYWJsZV9zb3Vy Y2UsCisJCQkJICAgICAgIGlzcmMtPmlzX3BpYy0+cGljX2Rpc2FibGVfaW50cik7CisJCQkJ aXNyYy0+aXNfcGljLT5waWNfZGlzYWJsZV9zb3VyY2UoaXNyYywgUElDX05PX0VPSSk7CisJ CQkJaXNyYy0+aXNfcGljLT5waWNfZGlzYWJsZV9pbnRyKGlzcmMpOworCQkJfQorCQkJaW50 cmNudF91cGRhdGVuYW1lKGlzcmMpOworCisJCX0KKwl9CisJbXR4X3VubG9jaygmaW50cl90 YWJsZV9sb2NrKTsKKwlyZXR1cm4gMDsKK30KKworCisKK2ludAogaW50cl9yZW1vdmVfaGFu ZGxlcih2b2lkICpjb29raWUpCiB7CiAJc3RydWN0IGludHNyYyAqaXNyYzsKZGlmZiAtLWdp dCBhL3N5cy94ODYveDg2L2xvY2FsX2FwaWMuYyBiL3N5cy94ODYveDg2L2xvY2FsX2FwaWMu YwppbmRleCBlOTk0MTcyLi42NTkzZThiIDEwMDY0NAotLS0gYS9zeXMveDg2L3g4Ni9sb2Nh bF9hcGljLmMKKysrIGIvc3lzL3g4Ni94ODYvbG9jYWxfYXBpYy5jCkBAIC0zNDYsNiArMzQ2 LDYwIEBAIGxhcGljX2R1bXAoY29uc3QgY2hhciogc3RyKQogfQogCiB2b2lkCitsYXBpY19j bGVhcl9sYXBpYyh1X2ludCBkaXNhYmxlKSB7CisKKwlzdHJ1Y3QgbGFwaWMgKmxhOworCWxh ID0gJmxhcGljc1tsYXBpY19pZCgpXTsKKworCXVpbnQzMl90IHZhbHVlOworCisJaWYgKGJv b3R2ZXJib3NlKQorCQlwcmludGYoIiVzIGxhcGljX2lkKCVkKSBjcHUoJWQpIGxhICVwIGxh cGljICVwXG4iLF9fRlVOQ1RJT05fXywKKwkJICAgICAgIGxhcGljX2lkKCksIFBDUFVfR0VU KGNwdWlkKSwgbGEsIGxhcGljKTsKKworCS8qCisJICogRmlzdCB3ZSBzZXQgdGhlIG1hc2sg Yml0IHRvIGtlZXAgYW5kIG5ldyBpbnRlcnJ1cHRzIGZyb20KKwkgKiBhcnJpdmluZyBidXQg YWxsb3dpbmcgYW55IHBlbmRpbmcgaW50ZXJydXB0cyB0byBmaW5pc2gKKwkgKiAqVEhFTiog c2V0IHRoZSByZWdpc3RlcnMgdG8gZGVmYXVsdCB2YWx1ZXMKKwkgKiBJZiB0aGUgaW50ZXJy dXB0cyBhcmUgbm90IGFsbG93ZWQgdG8gY2xlYXIgYSBrbG9hZCdlZCAvIGJvb3RlZAorCSAq IGtlcm5lbCB3aWxsIHNlZSB0aGUgb2xkIGludGVycnVwdHMgYmVmb3JlIHRoZSBhcHByb3By aWF0ZSBoYW5kbGVycworCSAqIGFyZSBpbiBwbGFjZSBhbmQgdHJpZ2dlciBhIHBhbmljLgor CSAqLworI2lmZGVmIG5vdHlldAorCS8qIHRoaXMgc2VlbXMgdG8gYmUgY2F1c2luZyBBUElD IGVycm9yIGluIHRoZSBuZXcga2VybmVsICovCisJdmFsdWUgPSBsYXBpYy0+bHZ0X2Vycm9y OworCXZhbHVlIHw9IEFQSUNfTFZUX007CisJbGFwaWMtPmx2dF9lcnJvciA9IHZhbHVlOwor I2VuZGlmCisKKwl2YWx1ZSA9IGxhcGljLT5sdnRfdGltZXI7CisJdmFsdWUgfD0gQVBJQ19M VlRfTTsKKwlsYXBpYy0+bHZ0X3RpbWVyID0gdmFsdWU7CisKKwl2YWx1ZSA9IGxhcGljLT5s dnRfbGludDA7CisJdmFsdWUgfD0gQVBJQ19MVlRfTTsKKwlsYXBpYy0+bHZ0X2xpbnQwID0g dmFsdWU7CisKKwl2YWx1ZSA9IGxhcGljLT5sdnRfbGludDE7CisJdmFsdWUgfD0gQVBJQ19M VlRfTTsKKwlsYXBpYy0+bHZ0X2xpbnQxID0gdmFsdWU7CisKKwl2YWx1ZSA9IGxhcGljLT5s dnRfcGNpbnQ7CisJdmFsdWUgfD0gQVBJQ19MVlRfTTsKKwlsYXBpYy0+bHZ0X3BjaW50ID0g dmFsdWU7CisKKwkvKiBQcm9ncmFtIHRpbWVyIExWVCBhbmQgc2V0dXAgaGFuZGxlci4gKi8K KwlsYXBpYy0+bHZ0X3RpbWVyID0gQVBJQ19MVlRUX007IC8qIG1hc2tlZCAqLworCWxhcGlj LT5sdnRfbGludDAgPSBBUElDX0xWVF9NOyAvKiBtYXNrZWQgKi8KKwlsYXBpYy0+bHZ0X2xp bnQxID0gQVBJQ19MVlRfTTsgLyogbWFza2VkICovCisKKwlpZiAoZGlzYWJsZSkgeworCQlw cmludGYoIlx0bGFwaWMgZGlzYWJsZVxuIik7CisJCWxhcGljX2Rpc2FibGUoKTsKKwl9Cit9 CisKK3ZvaWQKIGxhcGljX3NldHVwKGludCBib290KQogewogCXN0cnVjdCBsYXBpYyAqbGE7 CkBAIC05MjQsNyArOTc4LDIwIEBAIGxhcGljX2hhbmRsZV9lcnJvcih2b2lkKQogCWxhcGlj LT5lc3IgPSAwOwogCWVzciA9IGxhcGljLT5lc3I7CiAKLQlwcmludGYoIkNQVSVkOiBsb2Nh bCBBUElDIGVycm9yIDB4JXhcbiIsIFBDUFVfR0VUKGNwdWlkKSwgZXNyKTsKKwlwcmludGYo IkNQVSVkOiBsb2NhbCBBUElDIGVycm9yIDB4JXhcdCIsIFBDUFVfR0VUKGNwdWlkKSwgZXNy KTsKKwlpZiAobGFwaWMtPmVzciAmIEFQSUNfRVNSX1NFTkRfQ1NfRVJST1IpCisJCXByaW50 Zigic2VuZF9jc19lcnJvclxuIik7CisJaWYgKGxhcGljLT5lc3IgJiBBUElDX0VTUl9SRUNF SVZFX0NTX0VSUk9SKQorCQlwcmludGYoInJlY2VpdmVfY3NfZXJyb3JcbiIpOworCWlmIChs YXBpYy0+ZXNyICYgQVBJQ19FU1JfU0VORF9BQ0NFUFQpCisJCXByaW50Zigic2VuZF9hY2Nl cHRcbiIpOworCWlmIChsYXBpYy0+ZXNyICYgQVBJQ19FU1JfUkVDRUlWRV9BQ0NFUFQpCisJ CXByaW50ZigicmVjZWl2ZV9hY2NlcHRcbiIpOworCWlmIChsYXBpYy0+ZXNyICYgQVBJQ19F U1JfU0VORF9JTExFR0FMX1ZFQ1RPUikKKwkJcHJpbnRmKCJzZW5kX2lsbGVnYWxfdmVjdG9y XG4iKTsKKwlpZiAobGFwaWMtPmVzciAmIEFQSUNfRVNSX0lMTEVHQUxfUkVHSVNURVIpCisJ CXByaW50ZigiaWxsZWdhbF9yZWdpc3RlclxuIik7CisKIAlsYXBpY19lb2koKTsKIH0KIApk aWZmIC0tZ2l0IGEvc3lzL3g4Ni94ODYvbmV4dXMuYyBiL3N5cy94ODYveDg2L25leHVzLmMK aW5kZXggOWVhZDhjOC4uMGIyODQ2NSAxMDA2NDQKLS0tIGEvc3lzL3g4Ni94ODYvbmV4dXMu YworKysgYi9zeXMveDg2L3g4Ni9uZXh1cy5jCkBAIC01OSw2ICs1OSw3IEBAIF9fRkJTRElE KCIkRnJlZUJTRCQiKTsKICNpbmNsdWRlIDxtYWNoaW5lL2ludHJfbWFjaGRlcC5oPgogI2lu Y2x1ZGUgPHN5cy9ybWFuLmg+CiAjaW5jbHVkZSA8c3lzL2ludGVycnVwdC5oPgorI2luY2x1 ZGUgPHN5cy9zeXNjdGwuaD4KIAogI2luY2x1ZGUgPG1hY2hpbmUvdm1wYXJhbS5oPgogI2lu Y2x1ZGUgPHZtL3ZtLmg+CkBAIC02NzUsNiArNjc2LDUyIEBAIHJhbV9wcm9iZShkZXZpY2Vf dCBkZXYpCiB9CiAKIHN0YXRpYyBpbnQKK3NtYXBfaGRscihTWVNDVExfSEFORExFUl9BUkdT KSB7CisKKyAgLyogU1lTQ1RMX0hBTkRMRVJfQVJHUworICAgICBzdHJ1Y3Qgc3lzY3RsX29p ZCAqb2lkcCwgdm9pZCAqYXJnMSwKKyAgICAgaW50cHRyX3QgYXJnMiwgc3RydWN0IHN5c2N0 bF9yZXEgKnJlcQorICAqLworCisJc3RydWN0IGJpb3Nfc21hcCAqc21hcGJhc2U7CisJY2Fk ZHJfdCBrbWRwOworCXVpbnQzMl90IHNtYXBzaXplID0gMDsKKworCS8qIFJldHJpZXZlIHRo ZSBzeXN0ZW0gbWVtb3J5IG1hcCBmcm9tIHRoZSBsb2FkZXIuICovCisJa21kcCA9IHByZWxv YWRfc2VhcmNoX2J5X3R5cGUoImVsZiBrZXJuZWwiKTsKKwlpZiAoa21kcCA9PSBOVUxMKQor CQlrbWRwID0gcHJlbG9hZF9zZWFyY2hfYnlfdHlwZShFTEZfS0VSTl9TVFIpOworCWlmIChr bWRwICE9IE5VTEwpIHsKKwkJc21hcGJhc2UgPSAoc3RydWN0IGJpb3Nfc21hcCAqKXByZWxv YWRfc2VhcmNoX2luZm8oa21kcCwKKwkJCQkJCQkJICAgTU9ESU5GT19NRVRBREFUQSB8IE1P RElORk9NRF9TTUFQKTsKKwl9IGVsc2UgeworCQlzbWFwYmFzZSA9IE5VTEw7CisJCWdvdG8g b3V0OworCX0KKworCisJcHJpbnRmKCIlcyBzbWFwYmFzZSAlcFxuIixfX0ZVTkNUSU9OX18s c21hcGJhc2UpOworCXNtYXBzaXplID0gKigodV9pbnQzMl90ICopc21hcGJhc2UgLSAxKTsK KworI2lmIDAKKwl7CisJCXN0cnVjdCBiaW9zX3NtYXAgKnNtYXAsICpzbWFwZW5kOworCQlz bWFwZW5kID0gKHN0cnVjdCBiaW9zX3NtYXAgKikoKHVpbnRwdHJfdClzbWFwYmFzZSArIHNt YXBzaXplKTsKKwkJZm9yIChzbWFwID0gc21hcGJhc2U7IHNtYXAgPCBzbWFwZW5kOyBzbWFw KyspIHsKKwkJCXByaW50ZigiXHR0eXBlICVkIGJhc2UgMHglbHggbGVuZ3RoIDB4JWx4XG4i LAorCQkJICAgICAgIHNtYXAtPnR5cGUsc21hcC0+YmFzZSwgc21hcC0+bGVuZ3RoKTsKKwkJ fQorCX0KKyNlbmRpZgorCitvdXQ6CisJcmV0dXJuIChzeXNjdGxfaGFuZGxlX29wYXF1ZShv aWRwLCBzbWFwYmFzZSwgc21hcHNpemUsIHJlcSkpOworfQorU1lTQ1RMX1BST0MoX2h3LCBP SURfQVVUTywgc21hcCwgQ1RMVFlQRV9PUEFRVUV8Q1RMRkxBR19SRHxDVExGTEFHX01QU0FG RSwKKwkgICAgMCwgc2l6ZW9mKHN0cnVjdCBiaW9zX3NtYXApLCBzbWFwX2hkbHIsICJTLHNt YXAiLAorCSAgICAiQmlvcyBTeXN0ZW0gTWFwIik7CisKK3N0YXRpYyBpbnQKIHJhbV9hdHRh Y2goZGV2aWNlX3QgZGV2KQogewogCXN0cnVjdCBiaW9zX3NtYXAgKnNtYXBiYXNlLCAqc21h cCwgKnNtYXBlbmQ7CmRpZmYgLS1naXQgYS91c3Iuc2Jpbi9rbG9hZC9NYWtlZmlsZSBiL3Vz ci5zYmluL2tsb2FkL01ha2VmaWxlCm5ldyBmaWxlIG1vZGUgMTAwNjQ0CmluZGV4IDAwMDAw MDAuLjBkNGEyN2EKLS0tIC9kZXYvbnVsbAorKysgYi91c3Iuc2Jpbi9rbG9hZC9NYWtlZmls ZQpAQCAtMCwwICsxLDE1IEBACisjICRGcmVlQlNEJAorCitQUk9HPQlrbG9hZAorU1JDUz0J a2xvYWQuYworTk9fTUFOPQorCisjRFBBREQrPQkke0xJQlZNTUFQSX0KKyNMREFERCs9CS1s dm1tYXBpCisKK1dBUk5TPz0JMworCitDRkxBR1MrPS1JJHsuQ1VSRElSfS8uLi8uLi9zeXMv Ym9vdC91c2VyYm9vdAorQ0ZMQUdTKz0tSSR7LkNVUkRJUn0vLi4vLi4vc3lzCisKKy5pbmNs dWRlIDxic2QucHJvZy5taz4KZGlmZiAtLWdpdCBhL3Vzci5zYmluL2tsb2FkL2tsb2FkLmMg Yi91c3Iuc2Jpbi9rbG9hZC9rbG9hZC5jCm5ldyBmaWxlIG1vZGUgMTAwNjQ0CmluZGV4IDAw MDAwMDAuLjUxYWMzYjcKLS0tIC9kZXYvbnVsbAorKysgYi91c3Iuc2Jpbi9rbG9hZC9rbG9h ZC5jCkBAIC0wLDAgKzEsNzQ4IEBACisvKgorICogQ29weXJpZ2h0IChjKSAyMDExIC0gMjAx MgorICoJUnVzc2VsbCBDYXR0ZWxhbiBEaWdpdGFsIEVsdmVzIEluYworICogQ29weXJpZ2h0 IChjKSAyMDExIC0gMjAxMgorICoJSXNpbG9uIFN5c3RlbXMsIExMQy4gIEFsbCByaWdodHMg cmVzZXJ2ZWQuCisgKgorICogUmVkaXN0cmlidXRpb24gYW5kIHVzZSBpbiBzb3VyY2UgYW5k IGJpbmFyeSBmb3Jtcywgd2l0aCBvciB3aXRob3V0CisgKiBtb2RpZmljYXRpb24sIGFyZSBw ZXJtaXR0ZWQgcHJvdmlkZWQgdGhhdCB0aGUgZm9sbG93aW5nIGNvbmRpdGlvbnMKKyAqIGFy ZSBtZXQ6CisgKiAxLiBSZWRpc3RyaWJ1dGlvbnMgb2Ygc291cmNlIGNvZGUgbXVzdCByZXRh aW4gdGhlIGFib3ZlIGNvcHlyaWdodAorICogICAgbm90aWNlLCB0aGlzIGxpc3Qgb2YgY29u ZGl0aW9ucyBhbmQgdGhlIGZvbGxvd2luZyBkaXNjbGFpbWVyLgorICogMi4gUmVkaXN0cmli dXRpb25zIGluIGJpbmFyeSBmb3JtIG11c3QgcmVwcm9kdWNlIHRoZSBhYm92ZSBjb3B5cmln aHQKKyAqICAgIG5vdGljZSwgdGhpcyBsaXN0IG9mIGNvbmRpdGlvbnMgYW5kIHRoZSBmb2xs b3dpbmcgZGlzY2xhaW1lciBpbiB0aGUKKyAqICAgIGRvY3VtZW50YXRpb24gYW5kL29yIG90 aGVyIG1hdGVyaWFscyBwcm92aWRlZCB3aXRoIHRoZSBkaXN0cmlidXRpb24uCisgKgorICog VEhJUyBTT0ZUV0FSRSBJUyBQUk9WSURFRCBCWSBUSEUgQVVUSE9SIEFORCBDT05UUklCVVRP UlMgYGBBUyBJUycnIEFORAorICogQU5ZIEVYUFJFU1MgT1IgSU1QTElFRCBXQVJSQU5USUVT LCBJTkNMVURJTkcsIEJVVCBOT1QgTElNSVRFRCBUTywgVEhFCisgKiBJTVBMSUVEIFdBUlJB TlRJRVMgT0YgTUVSQ0hBTlRBQklMSVRZIEFORCBGSVRORVNTIEZPUiBBIFBBUlRJQ1VMQVIg UFVSUE9TRQorICogQVJFIERJU0NMQUlNRUQuICBJTiBOTyBFVkVOVCBTSEFMTCBUSEUgQVVU SE9SIE9SIENPTlRSSUJVVE9SUyBCRSBMSUFCTEUKKyAqIEZPUiBBTlkgRElSRUNULCBJTkRJ UkVDVCwgSU5DSURFTlRBTCwgU1BFQ0lBTCwgRVhFTVBMQVJZLCBPUiBDT05TRVFVRU5USUFM CisgKiBEQU1BR0VTIChJTkNMVURJTkcsIEJVVCBOT1QgTElNSVRFRCBUTywgUFJPQ1VSRU1F TlQgT0YgU1VCU1RJVFVURSBHT09EUworICogT1IgU0VSVklDRVM7IExPU1MgT0YgVVNFLCBE QVRBLCBPUiBQUk9GSVRTOyBPUiBCVVNJTkVTUyBJTlRFUlJVUFRJT04pCisgKiBIT1dFVkVS IENBVVNFRCBBTkQgT04gQU5ZIFRIRU9SWSBPRiBMSUFCSUxJVFksIFdIRVRIRVIgSU4gQ09O VFJBQ1QsIFNUUklDVAorICogTElBQklMSVRZLCBPUiBUT1JUIChJTkNMVURJTkcgTkVHTElH RU5DRSBPUiBPVEhFUldJU0UpIEFSSVNJTkcgSU4gQU5ZIFdBWQorICogT1VUIE9GIFRIRSBV U0UgT0YgVEhJUyBTT0ZUV0FSRSwgRVZFTiBJRiBBRFZJU0VEIE9GIFRIRSBQT1NTSUJJTElU WSBPRgorICogU1VDSCBEQU1BR0UuCisgKgorICovCisKKy8qCisgKiBwcm9jZXNzIGtpbGwg Y29kZSBib3Jyb3dlZCBmcm9tIGhhbHQuYworICovCisKKyNpbmNsdWRlIDxzeXMvcGFyYW0u aD4KKyNpbmNsdWRlIDxzeXMva2xvYWQuaD4KKyNpbmNsdWRlIDxzeXMvaW9jdGwuaD4KKyNp bmNsdWRlIDxzeXMvbW9kdWxlLmg+CisjaW5jbHVkZSA8c3lzL3N0YXQuaD4KKyNpbmNsdWRl IDxzeXMvc3lzY2FsbC5oPgorI2luY2x1ZGUgPHN5cy9zeXNjdGwuaD4KKyNpbmNsdWRlIDxz eXMvdHlwZXMuaD4KKyNpbmNsdWRlIDxzeXMvcGFyYW0uaD4KKworI2luY2x1ZGUgPGRpcmVu dC5oPgorI2luY2x1ZGUgPGRsZmNuLmg+CisjaW5jbHVkZSA8ZXJyLmg+CisjaW5jbHVkZSA8 ZXJybm8uaD4KKyNpbmNsdWRlIDxmY250bC5oPgorI2luY2x1ZGUgPGdldG9wdC5oPgorI2lu Y2x1ZGUgPGxpbWl0cy5oPgorI2luY2x1ZGUgPHNpZ25hbC5oPgorI2luY2x1ZGUgPHN0ZGlv Lmg+CisjaW5jbHVkZSA8c3RkbGliLmg+CisjaW5jbHVkZSA8c3RyaW5nLmg+CisjaW5jbHVk ZSA8dGVybWlvcy5oPgorI2luY2x1ZGUgPHVzZXJib290Lmg+CisjaW5jbHVkZSA8dW5pc3Rk Lmg+CisKK2NoYXIgKmhvc3RfYmFzZSA9ICIvIjsKKy8qIGhvdyBjYW4gd2UgZ2V0IHJpZCBv ZiB0aGVzZT8gSSBkb24ndCB0aGluayB3ZSBuZWVkIHRoZW0gKi8KKworc3RydWN0IHRlcm1p b3MgdGVybSwgb2xkdGVybTsKK2NoYXIgKmltYWdlOworc2l6ZV90IGltYWdlX3NpemU7Citz aXplX3QgaW1hZ2VfbWF4X3VzZWQgPSAwOworaW50IGRpc2tfZmQgPSAtMTsKK3VpbnQ2NF90 IHJlZ3NbMTZdOwordWludDY0X3QgcGM7CitzdGF0aWMgaW50IGtfZXhlY3V0ZSA9IDA7Citz dGF0aWMgaW50IGtfcmVib290ID0gMDsKK3N0YXRpYyB2b2lkICpkbF9saWI7Cit0eXBlZGVm IHZvaWQgKigqTV9mdW5jKShzaXplX3QgYnl0ZXMsIGNvbnN0IGNoYXIgKmZpbGUsIGludCBs aW5lKTsKK01fZnVuYyBNYWxsb2NfZnVuYzsKK3N0YXRpYyB2b2lkIGtfZXhpdCh2b2lkICos IGludCk7CitzdGF0aWMgaW50IHNodXRkb3duX3Byb2Nlc3Nlcyh2b2lkKTsKK3N0YXRpYyB1 X2ludCBnZXRfcGFnZWlucyh2b2lkKTsKK3N0YXRpYyBpbnQga2xvYWRfbG9hZF9pbWFnZSh2 b2lkICppbWFnZSx1bnNpZ25lZCBsb25nIGVudHJ5X3B0KTsKKworc3RydWN0IGxvYWRfZmls ZSB7CisJaW50IGxfaXNkaXI7CisJc2l6ZV90IGxfc2l6ZTsKKwlzdHJ1Y3Qgc3RhdCBsX3N0 YXQ7CisJdW5pb24geworCQlpbnQgZmQ7CisJCURJUiAqZGlyOworCX0gbF91OworfTsKKwor c3RydWN0IHNtYXAgeworCXVpbnQ2NF90CWJhc2U7CisJdWludDY0X3QJbGVuZ3RoOworCXVp bnQzMl90CXR5cGU7Cit9IF9fcGFja2VkOworCitzdGF0aWMgaW50CituYW1lMm9pZChjaGFy ICpuYW1lLCBpbnQgKm9pZHApCit7CisJaW50IG9pZFsyXTsKKwlpbnQgaTsKKwlzaXplX3Qg ajsKKworCW9pZFswXSA9IDA7CisJb2lkWzFdID0gMzsKKworCWogPSBDVExfTUFYTkFNRSAq IHNpemVvZihpbnQpOworCWkgPSBzeXNjdGwob2lkLCAyLCBvaWRwLCAmaiwgbmFtZSwgc3Ry bGVuKG5hbWUpKTsKKwlpZiAoaSA8IDApCisJCXJldHVybiAoaSk7CisJaiAvPSBzaXplb2Yo aW50KTsKKworCXJldHVybiAoaik7Cit9CisKK3N0YXRpYyB2b2lkCitrX3B1dGModm9pZCAq YXJnLCBpbnQgY2hyKQoreworCXdyaXRlKDEsICZjaHIsIDEpOworfQorCitzdGF0aWMgaW50 CitrX2dldGModm9pZCAqYXJnKQoreworCWNoYXIgY2hyOworCWlmKHJlYWQoMCwgJmNociwg MSkgPT0gMSkKKwkJcmV0dXJuIChjaHIpOworCXJldHVybiAoLTEpOworfQorCitzdGF0aWMg aW50CitrX3BvbGwodm9pZCAqYXJnKQoreworCWludCBuOworCWlmIChpb2N0bCgwLCBGSU9O UkVBRCwgJm4pID49IDApCisJCXJldHVybiAobiA+IDApOworCXJldHVybiAwOworfQorCitz dGF0aWMgaW50CitrX29wZW4odm9pZCAqYXJnLCBjb25zdCBjaGFyICpmaWxlbmFtZSwgdm9p ZCAqKmxmX3JldCkKK3sKKwlzdHJ1Y3Qgc3RhdCBzdDsKKwlzdHJ1Y3QgbG9hZF9maWxlICps ZjsKKwlpbnQgZXJyb3IgPSAtMTsKKwljaGFyIHBhdGhbUEFUSF9NQVhdOworCisJaWYgKCFo b3N0X2Jhc2UpIHsKKwkJcHJpbnRmKCJIb3N0IGJhc2Ugbm90IHNldFxuIik7CisJCXJldHVy biAoRU5PRU5UKTsKKwl9CisKKwlzdHJsY3B5KHBhdGgsIGhvc3RfYmFzZSwgUEFUSF9NQVgp OworCWlmIChwYXRoW3N0cmxlbihwYXRoKSAtIDFdID09ICcvJykKKwkJcGF0aFtzdHJsZW4o cGF0aCkgLSAxXSA9IDA7CisJc3RybGNhdChwYXRoLCBmaWxlbmFtZSwgUEFUSF9NQVgpOwor CWxmID0gbWFsbG9jKHNpemVvZihzdHJ1Y3QgbG9hZF9maWxlKSk7CisJaWYgKHN0YXQocGF0 aCwgJmxmLT5sX3N0YXQpIDwgMCkgeworCQllcnJvciA9IGVycm5vOworCQlnb3RvIG91dDsK Kwl9CisKKwlsZi0+bF9zaXplID0gc3Quc3Rfc2l6ZTsKKwlpZiAoU19JU0RJUihsZi0+bF9z dGF0LnN0X21vZGUpKSB7CisJCWxmLT5sX2lzZGlyID0gMTsKKwkJbGYtPmxfdS5kaXIgPSBv cGVuZGlyKHBhdGgpOworCQlpZiAoIWxmLT5sX3UuZGlyKSB7CisJCQllcnJvciA9IEVJTlZB TDsKKwkJCWdvdG8gb3V0OworCQl9CisJCSpsZl9yZXQgPSBsZjsKKwkJcmV0dXJuICgwKTsK Kwl9CisJaWYgKFNfSVNSRUcobGYtPmxfc3RhdC5zdF9tb2RlKSkgeworCQlsZi0+bF9pc2Rp ciA9IDA7CisJCWxmLT5sX3UuZmQgPSBvcGVuKHBhdGgsIE9fUkRPTkxZKTsKKwkJaWYgKGxm LT5sX3UuZmQgPCAwKSB7CisJCQllcnJvciA9IEVJTlZBTDsKKwkJCWdvdG8gb3V0OworCQl9 CisJCSpsZl9yZXQgPSBsZjsKKwkJcmV0dXJuICgwKTsKKwl9CisKK291dDoKKwlmcmVlKGxm KTsKKwlyZXR1cm4gKGVycm9yKTsKK30KKworc3RhdGljIGludAora19jbG9zZSh2b2lkICph cmcsIHZvaWQgKmgpCit7CisJc3RydWN0IGxvYWRfZmlsZSAqbGYgPSAoc3RydWN0IGxvYWRf ZmlsZSAqKWg7CisKKwlpZiAobGYtPmxfaXNkaXIpCisJCWNsb3NlZGlyKGxmLT5sX3UuZGly KTsKKwllbHNlCisJCWNsb3NlKGxmLT5sX3UuZmQpOworCWZyZWUobGYpOworCisJcmV0dXJu ICgwKTsKK30KKworc3RhdGljIGludAora19pc2Rpcih2b2lkICphcmcsIHZvaWQgKmgpCit7 CisJcmV0dXJuICgoKHN0cnVjdCBsb2FkX2ZpbGUgKiloKS0+bF9pc2Rpcik7Cit9CisKK3N0 YXRpYyBpbnQKK2tfcmVhZCh2b2lkICphcmcsIHZvaWQgKmgsIHZvaWQgKmRzdCwgc2l6ZV90 IHNpemUsIHNpemVfdCAqcmVzaWRfcmV0dXJuKQoreworCXN0cnVjdCBsb2FkX2ZpbGUgKmxm ID0gKHN0cnVjdCBsb2FkX2ZpbGUgKiloOworCXNzaXplX3Qgc3o7CisKKwlpZiAobGYtPmxf aXNkaXIpCisJCXJldHVybiAoRUlOVkFMKTsKKworCWlmKChzeiA9IHJlYWQobGYtPmxfdS5m ZCwgZHN0LCBzaXplKSkgPCAwKQorCQlyZXR1cm4gKEVJTlZBTCk7CisJKnJlc2lkX3JldHVy biA9IHNpemUgLSBzejsKKwlyZXR1cm4gKDApOworfQorCitzdGF0aWMgaW50CitrX3JlYWRk aXIodm9pZCAqYXJnLCB2b2lkICpoLCB1aW50MzJfdCAqZmlsZW5vX3JldHVybiwgdWludDhf dCAqdHlwZV9yZXR1cm4sCisgICAgc2l6ZV90ICpuYW1lbGVuX3JldHVybiwgY2hhciAqbmFt ZSkKK3sKKwlzdHJ1Y3QgbG9hZF9maWxlICpsZiA9IChzdHJ1Y3QgbG9hZF9maWxlICopaDsK KwlzdHJ1Y3QgZGlyZW50ICpkcDsKKworCWlmICghbGYtPmxfaXNkaXIpCisJCXJldHVybiAo RUlOVkFMKTsKKworCWRwID0gcmVhZGRpcihsZi0+bF91LmRpcik7CisJaWYgKCFkcCkKKwkJ cmV0dXJuIChFTk9FTlQpOworCisJLyoKKwkgKiBOb3RlOiBkX25hbWxlbiBpcyBpbiB0aGUg cmFuZ2UgMC4uMjU1IGFuZCB0aGVyZWZvcmUgbGVzcworCSAqIHRoYW4gUEFUSF9NQVggc28g d2UgZG9uJ3QgbmVlZCB0byB0ZXN0IGJlZm9yZSBjb3B5aW5nLgorCSAqLworCSpmaWxlbm9f cmV0dXJuID0gZHAtPmRfZmlsZW5vOworCSp0eXBlX3JldHVybiA9IGRwLT5kX3R5cGU7CisJ Km5hbWVsZW5fcmV0dXJuID0gZHAtPmRfbmFtbGVuOworCW1lbWNweShuYW1lLCBkcC0+ZF9u YW1lLCBkcC0+ZF9uYW1sZW4pOworCW5hbWVbZHAtPmRfbmFtbGVuXSA9IDA7CisKKwlyZXR1 cm4gKDApOworfQorCitzdGF0aWMgaW50CitrX3NlZWsodm9pZCAqYXJnLCB2b2lkICpoLCB1 aW50NjRfdCBvZmZzZXQsIGludCB3aGVuY2UpCit7CisJc3RydWN0IGxvYWRfZmlsZSAqbGYg PSAoc3RydWN0IGxvYWRfZmlsZSAqKWg7CisKKwlpZiAobGYtPmxfaXNkaXIpCisJCXJldHVy biAoRUlOVkFMKTsKKworCWlmIChsc2VlayhsZi0+bF91LmZkLCBvZmZzZXQsIHdoZW5jZSkg PCAwKQorCQlyZXR1cm4gKGVycm5vKTsKKworCXJldHVybiAoMCk7Cit9CisKK3N0YXRpYyBp bnQKK2tfc3RhdCh2b2lkICphcmcsIHZvaWQgKmgsCisgICAgICAgaW50ICptb2RlX3JldHVy biwgaW50ICp1aWRfcmV0dXJuLAorICAgICAgIGludCAqZ2lkX3JldHVybiwgdWludDY0X3Qg KnNpemVfcmV0dXJuKQoreworCisJc3RydWN0IGxvYWRfZmlsZSAqbGYgPSAoc3RydWN0IGxv YWRfZmlsZSAqKWg7CisKKwkqbW9kZV9yZXR1cm4gPSBsZi0+bF9zdGF0LnN0X21vZGU7CisJ KnVpZF9yZXR1cm4gPSBsZi0+bF9zdGF0LnN0X3VpZDsKKwkqZ2lkX3JldHVybiA9IGxmLT5s X3N0YXQuc3RfZ2lkOworCSpzaXplX3JldHVybiA9IGxmLT5sX3N0YXQuc3Rfc2l6ZTsKKwly ZXR1cm4gKDApOworfQorCitzdGF0aWMgaW50CitrX2Rpc2tyZWFkKHZvaWQgKmFyZywgaW50 IHVuaXQsIHVpbnQ2NF90IG9mZnNldCwgdm9pZCAqZHN0LCBzaXplX3Qgc2l6ZSwKKyAgICBz aXplX3QgKnJlc2lkX3JldHVybikKK3sKKwlzc2l6ZV90IG47CisKKwlpZiAodW5pdCAhPSAw IHx8IGRpc2tfZmQgPT0gLTEpCisJCXJldHVybiAoRUlPKTsKKwluID0gcHJlYWQoZGlza19m ZCwgZHN0LCBzaXplLCBvZmZzZXQpOworCWlmIChuIDwgMCkKKwkJcmV0dXJuIChlcnJubyk7 CisJKnJlc2lkX3JldHVybiA9IHNpemUgLSBuOworCXJldHVybiAoMCk7Cit9CisKK3N0YXRp YyBpbnQKK2tfZGlza2lvY3RsKHZvaWQgKmFyZywgaW50IHVuaXQsIHVfbG9uZyBjbWQsIHZv aWQgKmRhdGEpCit7CisJLyogbm90IHN1cHBvcnRlZCBvbiBieSBrbG9hZCAqLworCXJldHVy biAoRU5PVFRZKTsKK30KKworLyoKKyAqIFRoaXMgaXMgcmVhbGx5IGNvbmZ1c2luZyBzaW5j ZSB0aGlzIGlzIG5vdCByZWFsbHkgbGlrZSBkb2luZyBjb3B5aW4gLyBjb3B5b3V0CisgKiBp biBrZXJuZWwgbGFuZCB0aGlzIHdpbGwgY29weSB0aGUgZGF0YSBwb2ludGVkIHRvIGJ5IHRo ZSAiZnJvbSIgcHRyIGFuZCBjb3B5CisgKiAidG8iIHRoZSBvZmZzZXQgaW50byB0aGUgbG9h ZCBpbWFnZQorICovCitzdGF0aWMgaW50CitrX2NvcHlfdG9faW1hZ2Uodm9pZCAqYXJnLCBj b25zdCB2b2lkICpmcm9tLCB1aW50NjRfdCB0bywgc2l6ZV90IHNpemUpCit7CisJdG8gJj0g MHg3ZmZmZmZmZjsKKwlpZiAodG8gPiBpbWFnZV9zaXplKQorCQlyZXR1cm4gKEVGQVVMVCk7 CisJaWYgKHRvICsgc2l6ZSA+IGltYWdlX3NpemUpIHsKKwkJc2l6ZSA9IGltYWdlX3NpemUg LSB0bzsKKwkJcHJpbnRmKCJXQVJOSU5HIHRoaXMgc2hvdWxkIG5ldmVyIGhhcHBlblxuIik7 CisJfQorCW1lbWNweSgmaW1hZ2VbdG9dLCBmcm9tLCBzaXplKTsKKworCWlmICh0byArIHNp emUgPiBpbWFnZV9tYXhfdXNlZCkKKwkJaW1hZ2VfbWF4X3VzZWQgPSB0byArIHNpemU7CisK KwlyZXR1cm4gKDApOworfQorCisvKgorICogY29weW91dCBpcyBjb3B5aW5nIEZST00gdGhl IGltYWdlIGF0ICJmcm9tIiBvZmZzZXQgdG8gbWVtb3J5IHBvaW50ZWQgdG8gYnkgdG8KKyAq IHB0cgorICovCitzdGF0aWMgaW50CitrX2NvcHlfZnJvbV9pbWFnZSh2b2lkICphcmcsIHVp bnQ2NF90IGZyb20sIHZvaWQgKnRvLCBzaXplX3Qgc2l6ZSkKK3sKKwlmcm9tICY9IDB4N2Zm ZmZmZmY7CisJaWYgKGZyb20gPiBpbWFnZV9zaXplKQorCQlyZXR1cm4gKEVGQVVMVCk7CisJ aWYgKGZyb20gKyBzaXplID4gaW1hZ2Vfc2l6ZSkKKwkJc2l6ZSA9IGltYWdlX3NpemUgLSBm cm9tOworCW1lbWNweSh0bywgJmltYWdlW2Zyb21dLCBzaXplKTsKKworCXJldHVybiAoMCk7 Cit9CisKK3N0YXRpYyB2b2lkCitrX3NldHJlZyh2b2lkICphcmcsIGludCByLCB1aW50NjRf dCB2KQoreworCWlmIChyIDwgMCB8fCByID49IDE2KQorCQlyZXR1cm47CisJcmVnc1tyXSA9 IHY7Cit9CisKK3N0YXRpYyB2b2lkCitrX3NldG1zcih2b2lkICphcmcsIGludCByLCB1aW50 NjRfdCB2KQoreworCS8qIFVubmVlZGVkICovCit9CisKK3N0YXRpYyB2b2lkCitrX3NldGNy KHZvaWQgKmFyZywgaW50IHIsIHVpbnQ2NF90IHYpCit7CisJLyogVW5uZWVkZWQgKi8KK30K Kworc3RhdGljIHZvaWQKK2tfc2V0Z2R0KHZvaWQgKmFyZywgdWludDY0X3Qgdiwgc2l6ZV90 IHN6KQoreworCS8qIFVubmVlZGVkICovCit9CisKK3N0YXRpYyB2b2lkCitrX2V4ZWModm9p ZCAqYXJnLCB1aW50NjRfdCBlbnRyeV9wdCkKK3sKKyNpZmRlZiBERUJVRworCXByaW50Zigi RXhlY3V0ZSBhdCAweCVqeFxuIiwgZW50cnlfcHQpOworCXByaW50ZigiaW1hZ2Ugc2l6ZSBt YXggdXNlZCAlamQgZW5kb2YgcGFnZSAlamRcbiIsIGltYWdlX21heF91c2VkLAorCSAgICBy b3VuZHVwMihpbWFnZV9tYXhfdXNlZCwgUEFHRV9TSVpFKSk7CisjZW5kaWYKKwlrbG9hZF9s b2FkX2ltYWdlKGltYWdlLCBlbnRyeV9wdCk7CisJa19leGl0KGFyZywgMCk7Cit9CisKK3N0 YXRpYyB2b2lkCitrX2RlbGF5KHZvaWQgKmFyZywgaW50IHVzZWMpCit7CisJdXNsZWVwKHVz ZWMpOworfQorCitzdGF0aWMgdm9pZAora19leGl0KHZvaWQgKmFyZywgaW50IHYpCit7CisJ dGNzZXRhdHRyKDAsIFRDU0FGTFVTSCwgJm9sZHRlcm0pOworCWV4aXQodik7Cit9CisKK3N0 YXRpYyB2b2lkCitrX2dldG1lbSh2b2lkICphcmcsIHVpbnQ2NF90ICpsb3dtZW0sIHVpbnQ2 NF90ICpoaWdobWVtKQoreworCWludCBtaWJbMl07CisJdW5zaWduZWQgbG9uZyBsb25nIHBo eXNtZW07CisJc2l6ZV90IGxlbjsKKworCW1pYlswXSA9IENUTF9IVzsKKwltaWJbMV0gPSBI V19QSFlTTUVNOworCWxlbiA9IHNpemVvZihwaHlzbWVtKTsKKwlzeXNjdGwobWliLCAyLCAm cGh5c21lbSwgJmxlbiwgTlVMTCwgMCk7CisKKwkqbG93bWVtID0gcGh5c21lbTsKKwkqaGln aG1lbSA9IDA7CisKKwlwcmludGYoIiVzOiVkIGxvd21lbSAlanUgaGlnaG1lbSAlanVcbiIs X19GVU5DVElPTl9fLF9fTElORV9fLAorCSAgICAgICAqbG93bWVtLAorCSAgICAgICAqaGln aG1lbQorCQkpOworfQorCitzdGF0aWMgY29uc3QgY2hhciAqCitrX2dldGVudih2b2lkICph cmcsIGludCBpZHgpCit7CisJc3RhdGljIGNvbnN0IGNoYXIgKnZhcnNbXSA9IHsKKwkJImZv bz1iYXIiLAorCQkiYmFyPWJhcmJhciIsCisJCU5VTEwKKwl9OworCisJcmV0dXJuICh2YXJz W2lkeF0pOworfQorCitzdGF0aWMgaW50CitrX2J1aWxkc21hcCh2b2lkICphcmcsIHZvaWQg KipzbWFwX3ZvaWQsIHNpemVfdCAqb3V0bGVuKSAKK3sKKwlzdHJ1Y3Qgc21hcCAqc21hcGJh c2U7CisJc2l6ZV90IGksajsKKwlzaXplX3QgbGVuOworCWNoYXIgbmFtZVtdID0gImh3LnNt YXAiOworCWludCBtaWJbQ1RMX01BWE5BTUVdOworCisJbGVuID0gbmFtZTJvaWQobmFtZSwg bWliKTsKKworCS8qIGdldCB0aGUgY3VycmVudCBzbWFwIGZyb20gdGhlIHJ1bm5pbmcgc3lz dGVtICovCisJaSA9IHN5c2N0bChtaWIsIDIsIDAsICZqLCAwLCAwKTsKKwlsZW4gPSBqOwor CisJLyoKKwkgKiBVc2UgdGhlIG1hbGxvYyBmdW5jdGlvbiBmcm9tIGxpYnN0YW5kL3VzZXJi b290LnNvIHNpbmNlCisJICogYmlvc19hZGRzbWFwZGF0YSB3aWxsIGZyZWUgdGhlIG1lbW9y eSB1c2luZyB0aGUgbGlic3RhbmQgRnJlZQorCSAqIHNvIGJlIGNhcmVmdWwgdG8gdXNlIG5v dCB1c2Ugc3RhbmRhcmQgbWFsbG9jIGhlcmUKKwkgKi8KKwlzbWFwYmFzZSA9IE1hbGxvY19m dW5jKGosIF9fRklMRV9fLCBfX0xJTkVfXyk7CisJaWYgKCFzbWFwYmFzZSkgeworCQlwcmlu dGYoImtsb2FkIGZhaWxlZCB0byBhbGxvY2F0ZSBzcGFjZSBmb3Igc21hcFxuIik7CisJCXJl dHVybiAxOworCX0KKworCWkgPSBzeXNjdGwobWliLCAyLCBzbWFwYmFzZSwgJmosIE5VTEws IDApOworCisJKm91dGxlbiA9IGxlbjsKKwkqc21hcF92b2lkID0gc21hcGJhc2U7CisKKyNp ZmRlZiBERUJVRworCXsKKwkJc3RydWN0IHNtYXAgKnNtYXAsICpzbWFwZW5kOworCQlzbWFw ZW5kID0gKHN0cnVjdCBzbWFwICopKCh1aW50cHRyX3Qpc21hcGJhc2UgKyBsZW4pOworCQlm b3IgKHNtYXAgPSBzbWFwYmFzZTsgc21hcCA8IHNtYXBlbmQ7IHNtYXArKykgeworCQkJcHJp bnRmKCJcdHR5cGUgJWQgYmFzZSAweCUwMTZseCBsZW5ndGggMHglMDE2bHhcbiIsCisJCQkg ICAgICAgc21hcC0+dHlwZSwgc21hcC0+YmFzZSwgc21hcC0+bGVuZ3RoKTsKKwkJfQorCX0K KyNlbmRpZgorCisJcmV0dXJuIDA7Cit9CisKK3N0cnVjdCBsb2FkZXJfY2FsbGJhY2tzIGNi ID0geworCisJLm9wZW4gPSBrX29wZW4sCisJLmNsb3NlID0ga19jbG9zZSwKKwkuaXNkaXIg PSBrX2lzZGlyLAorCS5yZWFkID0ga19yZWFkLAorCS5yZWFkZGlyID0ga19yZWFkZGlyLAor CS5zZWVrID0ga19zZWVrLAorCS5zdGF0ID0ga19zdGF0LAorCisJLmRpc2tyZWFkID0ga19k aXNrcmVhZCwKKwkuZGlza2lvY3RsID0ga19kaXNraW9jdGwsCisKKwkuY29weWluID0ga19j b3B5X3RvX2ltYWdlLAorCS5jb3B5b3V0ID0ga19jb3B5X2Zyb21faW1hZ2UsCisJLnNldHJl ZyA9IGtfc2V0cmVnLAorCS5zZXRtc3IgPSBrX3NldG1zciwKKwkuc2V0Y3IgPSBrX3NldGNy LAorCS5zZXRnZHQgPSBrX3NldGdkdCwKKwkuZXhlYyA9IGtfZXhlYywKKworCS5kZWxheSA9 IGtfZGVsYXksCisJLmV4aXQgPSBrX2V4aXQsCisJLmdldG1lbSA9IGtfZ2V0bWVtLAorCisJ LnB1dGMgPSBrX3B1dGMsCisJLmdldGMgPSBrX2dldGMsCisJLnBvbGwgPSBrX3BvbGwsCisJ LmdldGVudiA9IGtfZ2V0ZW52LAorCS5idWlsZHNtYXAgPSBrX2J1aWxkc21hcCwKK307CisK K3N0YXRpYyB2b2lkCit1c2FnZSh2b2lkKQoreworCXByaW50ZigidXNhZ2U6IGtsb2FkIFst ZCA8ZGlzayBpbWFnZSBwYXRoPl0gIgorCSAgICAiWy1oIDxob3N0IGZpbGVzeXN0ZW0gcGF0 aD5dIFstZSB8IC1yXVxuIik7CisJZXhpdCgxKTsKK30KKworaW50CittYWluKGludCBhcmdj LCBjaGFyKiogYXJndikKK3sKKwlpbnQgKCpsb2FkZXJfbWFpbikoc3RydWN0IGxvYWRlcl9j YWxsYmFja3MgKiwgdm9pZCAqLCBpbnQsIGludCk7CisJdm9pZCAoKmxvYWRlcl9pbml0KSh2 b2lkKTsKKwlpbnQgKCpzZXRlbnYpKGNvbnN0IGNoYXIgKiwgY29uc3QgY2hhciAqLCBpbnQp OworCWludCBvcHQ7CisJY2hhciAqZGlza19pbWFnZSA9IE5VTEw7CisJY2hhciBrYXJnWzIw XTsKKwljaGFyIGt2YWxbMTI4XTsKKworCWlmIChnZXRldWlkKCkpIHsKKwkJZXJybm8gPSBF UEVSTTsKKwkJZXJyKDEsIE5VTEwpOworCX0KKworCWRsX2xpYiA9IGRsb3BlbigiL2Jvb3Qv dXNlcmJvb3Quc28iLCBSVExEX0xPQ0FMKTsKKwlpZiAoIWRsX2xpYikgeworCQlwcmludGYo IiVzXG4iLCBkbGVycm9yKCkpOworCQlyZXR1cm4gKDEpOworCX0KKwlsb2FkZXJfbWFpbiA9 IGRsc3ltKGRsX2xpYiwgImxvYWRlcl9tYWluIik7CisJaWYgKCFsb2FkZXJfbWFpbikgewor CQlwcmludGYoIiVzXG4iLCBkbGVycm9yKCkpOworCQlyZXR1cm4gKDEpOworCX0KKwlNYWxs b2NfZnVuYyA9IGRsc3ltKGRsX2xpYiwgIk1hbGxvYyIpOworCWlmICghTWFsbG9jX2Z1bmMp IHsKKwkJcHJpbnRmKCIlc1xuIiwgZGxlcnJvcigpKTsKKwkJcmV0dXJuICgxKTsKKwl9CisJ LyoKKwkgKiBwdWxsIGluIHRoZSBsaWJzdGFuZCBzZXRlbnYgZm9yIHNldHRpbmcgbmFtZSB2 YWx1ZSBwYWlycworCSAqIGluIHRoZSBrZXJuZWwgZW52IHBhZ2UKKwkgKi8KKwlzZXRlbnYg PSBkbHN5bShkbF9saWIsICJzZXRlbnYiKTsKKwlpZiAoIXNldGVudikgeworCQlwcmludGYo IiVzXG4iLCBkbGVycm9yKCkpOworCQlyZXR1cm4gKDEpOworCX0KKwlsb2FkZXJfaW5pdCA9 IGRsc3ltKGRsX2xpYiwgImxvYWRlcl9pbml0Iik7CisJaWYgKCFsb2FkZXJfaW5pdCkgewor CQlwcmludGYoIiVzXG4iLCBkbGVycm9yKCkpOworCQlyZXR1cm4gKDEpOworCX0KKwkvKiBj YWxsIGxpYnN0YW5kIHNldGhlYXAgdG8gaW5pdCBtZW1vcnkgYWxsb2NhdGlvbnMgKi8KKwls b2FkZXJfaW5pdCgpOworCisJd2hpbGUgKChvcHQgPSBnZXRvcHQoYXJnYywgYXJndiwgImQ6 aDplcms6IikpICE9IC0xKSB7CisJCXN3aXRjaCAob3B0KSB7CisJCWNhc2UgJ2QnOgorCQkJ ZGlza19pbWFnZSA9IG9wdGFyZzsKKwkJCWJyZWFrOworCisJCWNhc2UgJ2gnOgorCQkJaG9z dF9iYXNlID0gb3B0YXJnOworCQkJYnJlYWs7CisJCWNhc2UgJ2UnOgorCQkJa19leGVjdXRl ID0gMTsKKwkJCWJyZWFrOworCQljYXNlICdyJzoKKwkJCWtfcmVib290ID0gMTsKKwkJCWJy ZWFrOworCQljYXNlICdrJzoKKwkJCW1lbXNldChrYXJnLDAsc2l6ZW9mKGthcmcpKTsKKwkJ CW1lbXNldChrdmFsLDAsc2l6ZW9mKGt2YWwpKTsKKwkJCWlmKHNzY2FuZihvcHRhcmcsIiVb YS16QS1aXy1dPSVzIixrYXJnLGt2YWwpID09IDIpIHsKKwkJCQlwcmludGYoImdvdCB2YWx1 ZSAlcyAlc1xuIixrYXJnLGt2YWwpOworCQkJCXNldGVudihrYXJnLCBrdmFsLCAxKTsKKwkJ CX0gZWxzZSB7CisJCQkJZnByaW50ZihzdGRlcnIsIi1rIGZhaWx1cmUgJXNcbiIsb3B0YXJn KTsKKwkJCX0KKwkJCWJyZWFrOworCisJCWNhc2UgJz8nOgorCQkJdXNhZ2UoKTsKKwkJfQor CX0KKworCWltYWdlX3NpemUgPSAxMjgqMTAyNCoxMDI0OworCWltYWdlID0gbWFsbG9jKGlt YWdlX3NpemUpOworCWlmIChkaXNrX2ltYWdlKSB7CisJCWRpc2tfZmQgPSBvcGVuKGRpc2tf aW1hZ2UsIE9fUkRPTkxZKTsKKwkJaWYgKGRpc2tfZmQgPCAwKQorCQkJZXJyKDEsICJDYW4n dCBvcGVuIGRpc2sgaW1hZ2UgJyVzJyIsIGRpc2tfaW1hZ2UpOworCX0KKworCXRjZ2V0YXR0 cigwLCAmdGVybSk7CisJb2xkdGVybSA9IHRlcm07CisJdGVybS5jX2lmbGFnICY9IH4oSUNS TkwpOworCXRlcm0uY19sZmxhZyAmPSB+KElDQU5PTnxFQ0hPKTsKKwl0Y3NldGF0dHIoMCwg VENTQUZMVVNILCAmdGVybSk7CisKKwlyZXR1cm4obG9hZGVyX21haW4oJmNiLCBOVUxMLCBV U0VSQk9PVF9WRVJTSU9OXzQsIGRpc2tfZmQgPj0gMCkpOworfQorCitzdGF0aWMgaW50Citr bG9hZF9sb2FkX2ltYWdlKHZvaWQgKmltYWdlLCB1bnNpZ25lZCBsb25nIGVudHJ5X3B0KQor eworCWNoYXIgKnN0YWNrID0gKGNoYXIgKilpbWFnZSArIDB4MTAwMDsgLyogUEFHRVNJWkUg Ki8KKwlzdHJ1Y3Qga2xvYWQga2xkOworCWludCBmbGFncyA9IEtMT0FEX0xPQUQ7CisJLyoK KwkgKiBUaGlzIG11c3QgdGhlIHNhbWUgdmFsdWUgc3lzL2NvbmYvbGRzY3JpcHQueHh4CisJ ICogVGhpcyB2YWx1ZSB3YXMgY2hhbmdlZCBhdCBvbmUgcG9pbnQgd2hlbiBhIG5ldyB2ZXJz aW9uCisJICogb2YgYmludXRpbHMgd2FzIGltcG9ydGVkLiBUaGUgdmFsdWUgaXMgYWxpZ25l ZCB0bworCSAqIG1heCBwYWdlIHNpemUgc3VwcG9ydGVkIGJ5IGdpdmVuIHByb2Nlc3Nvcgor CSAqLworCXVuc2lnbmVkIGxvbmcga2VybnBoeXMgPSAweDIwMDAwMDsKKworCWtsZC5raGRy WzBdLmtfYnVmID0gJigoY2hhciAqKWltYWdlKVtrZXJucGh5c107CisJa2xkLmtoZHJbMF0u a19tZW1zeiA9IHJvdW5kdXAyKGltYWdlX21heF91c2VkLFBBR0VfU0laRSkgLSBrZXJucGh5 czsKKwlrbGQua19lbnRyeV9wdCA9IGVudHJ5X3B0OworCWtsZC5udW1faGRycyA9IDE7CisK KwkvKgorCSAqIHB1bGwgcGFyYW1hdGVycyBmcm9tIHRoZSBzdGFjayBwYWdlCisJICogYSBi ZXR0ZXIgaW50ZXJmYWNlIHNob3VsZCBiZSBkZXZlbG9wZWQgZm9yIGtsb2FkCisJICogaW4g dGhlIGZ1dHVyZQorCSAqLworCWtsZC5rX21vZHVsZXAgPSAoKHVuc2lnbmVkIGludCAqKXN0 YWNrKVsxXTsKKwlrbGQua19waHlzZnJlZSA9ICgodW5zaWduZWQgaW50ICopc3RhY2spWzJd OworCisJLyoKKwkgKiBNYWtlIHN1cmUgdGhlcmUgaXMgNCBwYWdlcyBvZiBrZW52IHBhZ2Vz IGJldHdlZW4gdGhlIGVuZCBvZiB0aGUKKwkgKiBrZXJuZWwgYW5kIHN0YXJ0IG9mIGZyZWUg bWVtb3J5LgorCSAqIFdoeSB5b3UgYXNrPyBXZWxsIHRoYXQgaXMgYSBxdWVzdGlvbiB3aXRo b3V0IGEgZ29vZCBhbnN3ZXIgYXMgb2YgeWV0CisJICogZm9yIHNvbWUgc3RyYW5nZSByZWFz b24gc29tZSBhdGEgY2hpcHMgd2lsbCBub3QgcmVzcG9uZCBjb3JyZWN0bHkKKwkgKiB1bmxl c3MgZnJlZSBtZW1vcnkgc3RhcnRzIGF0IGdyZWF0ZXIgdGhhbiAyIHBhZ2VzIG91dC4KKwkg KiBUaGUgb2J2b2l1cyBhc3N1bXB0aW9uIGlzIHRoYXQgc29tZXRoaW5nIGlzIGdldHRpbmcg c3RvbW1wZWQgb24gYnV0CisJICogdGhhdCBoYXMgeWV0IHRvIGJlIGRldGVybWluZWQuIEFk ZGluZyB0aGlzIHdvcmthcm91bmQuCisJICovIAorCWtsZC5rX3BoeXNmcmVlID0gTUFYKGts ZC5rX21vZHVsZXAgKyAoNCAqIFBBR0VfU0laRSksIGtsZC5rX3BoeXNmcmVlKTsKKworCXBy aW50ZigiV0FSTklORyBrZXJucGh5cyBzZXQgdG8gMHglbHggbWFrZSBzdXJlIHRoaXMgbWF0 Y2hlcyBrZXJucGh5cyAiCisJICAgICJmcm9tIHN5cy9jb25maWcvbGRzY3JpcHRcbiIsIGtl cm5waHlzKTsKKworCWlmIChrX2V4ZWN1dGUpIHsKKwkJZmxhZ3MgJj0gfktMT0FEX1JFQk9P VDsKKwkJZmxhZ3MgfD0gS0xPQURfRVhFQzsKKwl9CisJaWYgKGtfcmVib290KSB7CisJCWZs YWdzICY9IH5LTE9BRF9FWEVDOworCQlmbGFncyB8PSBLTE9BRF9SRUJPT1Q7CisJCXNodXRk b3duX3Byb2Nlc3NlcygpOworCX0KKworCXJldHVybiAoc3lzY2FsbChTWVNfa2xvYWQsICZr bGQsIHNpemVvZihzdHJ1Y3Qga2xvYWQpLCBmbGFncykpOworfQorCitzdGF0aWMgaW50Citz aHV0ZG93bl9wcm9jZXNzZXModm9pZCkKK3sKKwlpbnQgaTsKKwl1X2ludCBwYWdlaW5zOwor CWludCBzdmVycm5vOworCS8qCisJICogRG8gYSBzeW5jIGVhcmx5IG9uLCBzbyBkaXNrcyBz dGFydCB0cmFuc2ZlcnMgd2hpbGUgd2UncmUgb2ZmCisJICoga2lsbGluZyBwcm9jZXNzZXMu ICBEb24ndCB3b3JyeSBhYm91dCB3cml0ZXMgZG9uZSBiZWZvcmUgdGhlCisJICogcHJvY2Vz c2VzIGRpZSwgdGhlIHJlYm9vdCBzeXN0ZW0gY2FsbCBzeW5jcyB0aGUgZGlza3MuCisJICov CisJc3luYygpOworCisJLyoKKwkgKiBJZ25vcmUgc2lnbmFscyB0aGF0IHdlIGNhbiBnZXQg YXMgYSByZXN1bHQgb2Yga2lsbGluZworCSAqIHBhcmVudHMsIGdyb3VwIGxlYWRlcnMsIGV0 Yy4KKwkgKi8KKwkodm9pZClzaWduYWwoU0lHSFVQLCAgU0lHX0lHTik7CisJKHZvaWQpc2ln bmFsKFNJR0lOVCwgIFNJR19JR04pOworCSh2b2lkKXNpZ25hbChTSUdRVUlULCBTSUdfSUdO KTsKKwkodm9pZClzaWduYWwoU0lHVEVSTSwgU0lHX0lHTik7CisJKHZvaWQpc2lnbmFsKFNJ R1RTVFAsIFNJR19JR04pOworCisJLyoKKwkgKiBJZiB3ZSdyZSBydW5uaW5nIGluIGEgcGlw ZWxpbmUsIHdlIGRvbid0IHdhbnQgdG8gZGllCisJICogYWZ0ZXIga2lsbGluZyB3aGF0ZXZl ciB3ZSdyZSB3cml0aW5nIHRvLgorCSAqLworCSh2b2lkKXNpZ25hbChTSUdQSVBFLCBTSUdf SUdOKTsKKworCS8qIEp1c3Qgc3RvcCBpbml0IC0tIGlmIHdlIGZhaWwsIHdlJ2xsIHJlc3Rh cnQgaXQuICovCisJaWYgKGtpbGwoMSwgU0lHVFNUUCkgPT0gLTEpCisJCWVycigxLCAiU0lH VFNUUCBpbml0Iik7CisKKwkvKiBTZW5kIGEgU0lHVEVSTSBmaXJzdCwgYSBjaGFuY2UgdG8g c2F2ZSB0aGUgYnVmZmVycy4gKi8KKwlpZiAoa2lsbCgtMSwgU0lHVEVSTSkgPT0gLTEgJiYg ZXJybm8gIT0gRVNSQ0gpCisJCWVycigxLCAiU0lHVEVSTSBwcm9jZXNzZXMiKTsKKworCS8q CisJICogQWZ0ZXIgdGhlIHByb2Nlc3NlcyByZWNlaXZlIHRoZSBzaWduYWwsIHN0YXJ0IHRo ZSByZXN0IG9mIHRoZQorCSAqIGJ1ZmZlcnMgb24gdGhlaXIgd2F5LiAgV2FpdCA1IHNlY29u ZHMgYmV0d2VlbiB0aGUgU0lHVEVSTSBhbmQKKwkgKiB0aGUgU0lHS0lMTCB0byBnaXZlIGV2 ZXJ5Ym9keSBhIGNoYW5jZS4gSWYgdGhlcmUgaXMgYSBsb3Qgb2YKKwkgKiBwYWdpbmcgYWN0 aXZpdHkgdGhlbiB3YWl0IGxvbmdlciwgdXAgdG8gYSBtYXhpbXVtIG9mIGFwcHJveAorCSAq IDYwIHNlY29uZHMuCisJICovCisJc2xlZXAoMik7CisJZm9yIChpID0gMDsgaSA8IDIwOyBp KyspIHsKKwkJcGFnZWlucyA9IGdldF9wYWdlaW5zKCk7CisJCXN5bmMoKTsKKwkJc2xlZXAo Myk7CisJCWlmIChnZXRfcGFnZWlucygpID09IHBhZ2VpbnMpCisJCQlicmVhazsKKwl9CisK Kwlmb3IgKGkgPSAxOzsgKytpKSB7CisJCWlmIChraWxsKC0xLCBTSUdLSUxMKSA9PSAtMSkg eworCQkJaWYgKGVycm5vID09IEVTUkNIKQorCQkJCWJyZWFrOworCQkJZ290byByZXN0YXJ0 OworCQl9CisJCWlmIChpID4gNSkgeworCQkJKHZvaWQpZnByaW50ZihzdGRlcnIsCisJCQkg ICAgIldBUk5JTkc6IHNvbWUgcHJvY2Vzcyhlcykgd291bGRuJ3QgZGllXG4iKTsKKwkJCWJy ZWFrOworCQl9CisJCSh2b2lkKXNsZWVwKDIgKiBpKTsKKwl9CisJcmV0dXJuIDE7CityZXN0 YXJ0OgorCXN2ZXJybm8gPSBlcnJubzsKKwllcnJ4KDEsICIlcyVzIiwga2lsbCgxLCBTSUdI VVApID09IC0xID8KKwkgICAgIihjYW4ndCByZXN0YXJ0IGluaXQpOiAiIDogIiIsIHN0cmVy cm9yKHN2ZXJybm8pKTsKKwkvKiBOT1RSRUFDSEVEICovCisJcmV0dXJuIDA7Cit9CisKK3N0 YXRpYyB1X2ludAorZ2V0X3BhZ2VpbnModm9pZCkKK3sKKwl1X2ludCBwYWdlaW5zOworCXNp emVfdCBsZW47CisKKwlsZW4gPSBzaXplb2YocGFnZWlucyk7CisJaWYgKHN5c2N0bGJ5bmFt ZSgidm0uc3RhdHMudm0udl9zd2FwcGdzaW4iLCAmcGFnZWlucywgJmxlbiwgTlVMTCwgMCkK KwkgICAgIT0gMCkgeworCQl3YXJueCgidl9zd2FwcGdzaW4iKTsKKwkJcmV0dXJuICgwKTsK Kwl9CisJcmV0dXJuIChwYWdlaW5zKTsKK30K --------------010401020106090303040504-- --------------enigEF8640DC65B19FFA7A0B0F0B 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.12 (Darwin) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlCkb8YACgkQNRmM+OaGhBhXTQCeM+QAfsB8NiEQ2sZvKxXEMJRm YU4An24ju3d/k5mTmcQqik1UHaT0V3RF =T8ZP -----END PGP SIGNATURE----- --------------enigEF8640DC65B19FFA7A0B0F0B-- From owner-freebsd-current@FreeBSD.ORG Thu Nov 15 10:16:54 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6075B328 for ; Thu, 15 Nov 2012 10:16:54 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 7F0FD8FC08 for ; Thu, 15 Nov 2012 10:16:53 +0000 (UTC) Received: from porto.starpoint.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 MAA01215; Thu, 15 Nov 2012 12:16:43 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1TYwV0-000NU7-SJ; Thu, 15 Nov 2012 12:16:42 +0200 Message-ID: <50A4C109.10003@FreeBSD.org> Date: Thu, 15 Nov 2012 12:16:41 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:16.0) Gecko/20121030 Thunderbird/16.0.2 MIME-Version: 1.0 To: Russell Cattelan Subject: Re: Anybody willing to test out kload? References: <50A41395.7080205@thebarn.com> In-Reply-To: <50A41395.7080205@thebarn.com> X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 10:16:54 -0000 on 14/11/2012 23:56 Russell Cattelan said the following: > This has been sitting on my plate for a while and I would like to get some > more feedback / testing on this feature. A few words about what kload is and how to use/test it might increase chances of that actually happening. > What is really would like to find out is which drivers do not shutdown > their chips correctly and thus cause stray interrupts on the kload boot. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Thu Nov 15 11:40:43 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 639D9A55 for ; Thu, 15 Nov 2012 11:40:43 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) by mx1.freebsd.org (Postfix) with ESMTP id 0D6D78FC13 for ; Thu, 15 Nov 2012 11:40:41 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1TYxoN-0004O6-Hn for freebsd-current@freebsd.org; Thu, 15 Nov 2012 12:40:47 +0100 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, 15 Nov 2012 12:40:47 +0100 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 15 Nov 2012 12:40:47 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Ivan Voras Subject: Re: Anybody willing to test out kload? Date: Thu, 15 Nov 2012 12:40:21 +0100 Lines: 40 Message-ID: References: <50A41395.7080205@thebarn.com> <50A4C109.10003@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigB140E1379784E12C09A95ED0" X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:14.0) Gecko/20120812 Thunderbird/14.0 In-Reply-To: <50A4C109.10003@FreeBSD.org> X-Enigmail-Version: 1.4.3 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 11:40:43 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigB140E1379784E12C09A95ED0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 15/11/2012 11:16, Andriy Gapon wrote: > on 14/11/2012 23:56 Russell Cattelan said the following: >> This has been sitting on my plate for a while and I would like to get = some >> more feedback / testing on this feature. >=20 > A few words about what kload is and how to use/test it might increase c= hances > of that actually happening. Google finds this: http://www.bsdcan.org/2012/schedule/events/325.en.html I would have thought the major problem here is not the kernel itself but the drivers, leaving hardware in undetermined state (especially server hardware, which is numerous and surprisingly sensitive to there being One True Way to initialize it). --------------enigB140E1379784E12C09A95ED0 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlCk1KUACgkQ/QjVBj3/HSwGqQCfXtKk0YCnbWSVpoHYLjO/PBBT cCAAn3LNX3YIg5RXtnH6KdNDaDjSQhOj =5uEe -----END PGP SIGNATURE----- --------------enigB140E1379784E12C09A95ED0-- From owner-freebsd-current@FreeBSD.ORG Thu Nov 15 11:57:27 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9EF14E26 for ; Thu, 15 Nov 2012 11:57:27 +0000 (UTC) (envelope-from bartosz.stec@it4pro.pl) Received: from mainframe.kkip.pl (kkip.pl [78.9.102.18]) by mx1.freebsd.org (Postfix) with ESMTP id DCF508FC13 for ; Thu, 15 Nov 2012 11:57:26 +0000 (UTC) Received: from 89-69-114-93.dynamic.chello.pl ([89.69.114.93] helo=[192.168.0.100]) by mainframe.kkip.pl with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1TYy4A-0005r2-7C for freebsd-current@freebsd.org; Thu, 15 Nov 2012 12:57:18 +0100 Message-ID: <50A4D88A.2010102@it4pro.pl> Date: Thu, 15 Nov 2012 12:56:58 +0100 From: Bartosz Stec Organization: IT4Pro User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Recent CURRENT - Mounting from zfs:zroot failed with error 22. X-Authenticated-User: bartosz.stec@it4pro.pl X-Authenticator: plain X-Sender-Verify: SUCCEEDED (sender exists & accepts mail) X-Spam-Score: -8.0 X-Spam-Score-Int: -79 X-Exim-Version: 4.80.1 (build at 26-Oct-2012 17:04:45) X-Date: 2012-11-15 12:57:18 X-Connected-IP: 89.69.114.93:51356 X-Message-Linecount: 463 X-Body-Linecount: 452 X-Message-Size: 18048 X-Body-Size: 17604 X-Received-Count: 1 X-Recipient-Count: 1 X-Local-Recipient-Count: 1 X-Local-Recipient-Defer-Count: 0 X-Local-Recipient-Fail-Count: 0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 11:57:27 -0000 Hello list, I wanted to update CURRENT installation on my home server because kernel dated: # uname -a FreeBSD server.obsysa.net 10.0-CURRENT FreeBSD 10.0-CURRENT #2 r240357: Tue Sep 11 19:14:47 CEST 2012 root@server.obsysa.net:/usr/obj/usr/src/sys/ATHLON10 i386 is unstable for me. Unfortunately, I can't succesfully boot any recent CURRENT, it always ends with: Trying to mount root from zfs:zroot []... Mounting from zfs:zroot failed with error 22. at last stage. I've updated world and bootcodes on all disks to latest code, I've tried building with clang and gcc, still the same - old kernel boots, but recent current doesn't. dmesg from old kernel: http://pastebin.com/ppbvTRW8 kernel config: http://pastebin.com/K96T3hrV # gpart show => 34 78165293 ada0 GPT (37G) 34 128 1 freebsd-boot (64k) 162 2097152 2 freebsd-swap (1.0G) 2097314 76068013 3 freebsd-zfs (36G) => 34 78165293 ada1 GPT (37G) 34 128 1 freebsd-boot (64k) 162 2097152 2 freebsd-swap (1.0G) 2097314 76068013 3 freebsd-zfs (36G) => 34 78242909 ada2 GPT (37G) 34 128 1 freebsd-boot (64k) 162 2097152 2 freebsd-swap (1.0G) 2097314 76068013 3 freebsd-zfs (36G) 78165327 77616 - free - (37M) => 34 78242909 ada3 GPT (37G) 34 128 1 freebsd-boot (64k) 162 2097152 2 freebsd-swap (1.0G) 2097314 76068013 3 freebsd-zfs (36G) 78165327 77616 - free - (37M) # gpart show -l => 34 78165293 ada0 GPT (37G) 34 128 1 (null) (64k) 162 2097152 2 swap0 (1.0G) 2097314 76068013 3 disk0 (36G) => 34 78165293 ada1 GPT (37G) 34 128 1 (null) (64k) 162 2097152 2 swap1 (1.0G) 2097314 76068013 3 disk1 (36G) => 34 78242909 ada2 GPT (37G) 34 128 1 (null) (64k) 162 2097152 2 swap2 (1.0G) 2097314 76068013 3 disk2 (36G) 78165327 77616 - free - (37M) => 34 78242909 ada3 GPT (37G) 34 128 1 (null) (64k) 162 2097152 2 swap3 (1.0G) 2097314 76068013 3 disk3 (36G) 78165327 77616 - free - (37M) # zdb zroot: version: 28 name: 'zroot' state: 0 txg: 4 pool_guid: 4467765745870166865 hostid: 2539839140 hostname: 'mfsbsd' vdev_children: 2 vdev_tree: type: 'root' id: 0 guid: 4467765745870166865 create_txg: 4 children[0]: type: 'mirror' id: 0 guid: 697384422102507547 metaslab_array: 33 metaslab_shift: 28 ashift: 9 asize: 38942015488 is_log: 0 create_txg: 4 children[0]: type: 'disk' id: 0 guid: 8710134285551915560 path: '/dev/gpt/disk0' phys_path: '/dev/gpt/disk0' whole_disk: 1 create_txg: 4 children[1]: type: 'disk' id: 1 guid: 13312030606858472664 path: '/dev/gpt/disk2' phys_path: '/dev/gpt/disk2' whole_disk: 1 create_txg: 4 children[1]: type: 'mirror' id: 1 guid: 4490522279017872594 metaslab_array: 30 metaslab_shift: 28 ashift: 9 asize: 38942015488 is_log: 0 create_txg: 4 children[0]: type: 'disk' id: 0 guid: 15041339321584576645 path: '/dev/gpt/disk1' phys_path: '/dev/gpt/disk1' whole_disk: 1 create_txg: 4 children[1]: type: 'disk' id: 1 guid: 18403473023508789449 path: '/dev/gpt/disk3' phys_path: '/dev/gpt/disk3' whole_disk: 1 create_txg: 4 # zpool status -v pool: zroot state: ONLINE scan: scrub repaired 0 in 0h57m with 0 errors on Sun Nov 11 17:55:44 2012 config: NAME STATE READ WRITE CKSUM zroot ONLINE 0 0 0 mirror-0 ONLINE 0 0 0 gpt/disk0 ONLINE 0 0 0 gpt/disk2 ONLINE 0 0 0 mirror-1 ONLINE 0 0 0 gpt/disk1 ONLINE 0 0 0 gpt/disk3 ONLINE 0 0 0 grep -v # /etc/make.conf CPUTYPE?=athlon-xp KERNCONF=ATHLON10 MALLOC_PRODUCTION=YES WITHOUT_CLANG_IS_CC=YES MASTER_SITE_APACHE_HTTPD?= http://ftp.tpnet.pl/vol/d1/apache/httpd/ http://sunsite.icm.edu.pl/pub/www/apache/dist/httpd/ http://www.apache.net.pl/httpd/ ftp://ftp.task.gda.pl/pub/www/apache/dist/httpd/ ftp://sunsite.icm.edu.pl/pub/www/apache/dist/httpd/ ftp://ftp.tpnet.pl/d1/apache/httpd/ .if ${.CURDIR:M*/ports/*} CFLAGS=-O2 -pipe -fno-strict-aliasing BUILD_OPTIMIZED=YES WITH_OPENSSL=YES WITH_XCHARSET=all WITH_CHARSET=utf8 WITH_COLLATION=utf8_general_ci .endif .if ${.CURDIR:M*/usr/src/*} || ${.CURDIR:M*/usr/obj/*} CFLAGS=-O2 -pipe -fno-strict-aliasing COPTFLAGS=-O -pipe .if !defined(NOCCACHE) CC:=${CC:C,^cc,/usr/local/libexec/ccache/world/cc,1} CXX:=${CXX:C,^c\+\+,/usr/local/libexec/ccache/world/c++,1} .endif .endif PERL_VERSION=5.14.2 grep -v # /boot/loader.conf loader_logo="beastie" autoboot_delay="5" accf_http_load="YES" accf_data_load="YES" vm.kmem_size="1536M" vm.kmem_size_max="1536M" zfs_load="YES" geom_mirror_load="YES" geom_stripe_load="YES" aio_load="YES" vfs.root.mountfrom="zfs:zroot" I was cleaning /usr/obj and ccache cache to make sure they are not causing any problems, no luck. Any ideas? Regards, -- Bartosz Stec From owner-freebsd-current@FreeBSD.ORG Thu Nov 15 12:18:53 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A74A654A for ; Thu, 15 Nov 2012 12:18:53 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 9DE968FC08 for ; Thu, 15 Nov 2012 12:18:52 +0000 (UTC) Received: from porto.starpoint.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 OAA02229; Thu, 15 Nov 2012 14:18:35 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1TYyOx-000NZm-93; Thu, 15 Nov 2012 14:18:35 +0200 Message-ID: <50A4DD99.30705@FreeBSD.org> Date: Thu, 15 Nov 2012 14:18:33 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:16.0) Gecko/20121030 Thunderbird/16.0.2 MIME-Version: 1.0 To: Bartosz Stec Subject: Re: Recent CURRENT - Mounting from zfs:zroot failed with error 22. References: <50A4D88A.2010102@it4pro.pl> In-Reply-To: <50A4D88A.2010102@it4pro.pl> X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 12:18:54 -0000 on 15/11/2012 13:56 Bartosz Stec said the following: > Hello list, > I wanted to update CURRENT installation on my home server because kernel dated: > > # uname -a > FreeBSD server.obsysa.net 10.0-CURRENT FreeBSD 10.0-CURRENT #2 > r240357: Tue Sep 11 19:14:47 CEST 2012 > root@server.obsysa.net:/usr/obj/usr/src/sys/ATHLON10 i386 > > is unstable for me. > Unfortunately, I can't succesfully boot any recent CURRENT, it always ends with: > > Trying to mount root from zfs:zroot []... > Mounting from zfs:zroot failed with error 22. I am looking into this. That's probably a bug in one of my commits. > at last stage. > I've updated world and bootcodes on all disks to latest code, I've tried > building with clang and gcc, still the same - old kernel boots, but recent > current doesn't. > > dmesg from old kernel: http://pastebin.com/ppbvTRW8 > > kernel config: http://pastebin.com/K96T3hrV > > # gpart show > > => 34 78165293 ada0 GPT (37G) > 34 128 1 freebsd-boot (64k) > 162 2097152 2 freebsd-swap (1.0G) > 2097314 76068013 3 freebsd-zfs (36G) > > => 34 78165293 ada1 GPT (37G) > 34 128 1 freebsd-boot (64k) > 162 2097152 2 freebsd-swap (1.0G) > 2097314 76068013 3 freebsd-zfs (36G) > > => 34 78242909 ada2 GPT (37G) > 34 128 1 freebsd-boot (64k) > 162 2097152 2 freebsd-swap (1.0G) > 2097314 76068013 3 freebsd-zfs (36G) > 78165327 77616 - free - (37M) > > => 34 78242909 ada3 GPT (37G) > 34 128 1 freebsd-boot (64k) > 162 2097152 2 freebsd-swap (1.0G) > 2097314 76068013 3 freebsd-zfs (36G) > 78165327 77616 - free - (37M) > > # gpart show -l > > => 34 78165293 ada0 GPT (37G) > 34 128 1 (null) (64k) > 162 2097152 2 swap0 (1.0G) > 2097314 76068013 3 disk0 (36G) > > => 34 78165293 ada1 GPT (37G) > 34 128 1 (null) (64k) > 162 2097152 2 swap1 (1.0G) > 2097314 76068013 3 disk1 (36G) > > => 34 78242909 ada2 GPT (37G) > 34 128 1 (null) (64k) > 162 2097152 2 swap2 (1.0G) > 2097314 76068013 3 disk2 (36G) > 78165327 77616 - free - (37M) > > => 34 78242909 ada3 GPT (37G) > 34 128 1 (null) (64k) > 162 2097152 2 swap3 (1.0G) > 2097314 76068013 3 disk3 (36G) > 78165327 77616 - free - (37M) > > # zdb > > zroot: > version: 28 > name: 'zroot' > state: 0 > txg: 4 > pool_guid: 4467765745870166865 > hostid: 2539839140 > hostname: 'mfsbsd' > vdev_children: 2 > vdev_tree: > type: 'root' > id: 0 > guid: 4467765745870166865 > create_txg: 4 > children[0]: > type: 'mirror' > id: 0 > guid: 697384422102507547 > metaslab_array: 33 > metaslab_shift: 28 > ashift: 9 > asize: 38942015488 > is_log: 0 > create_txg: 4 > children[0]: > type: 'disk' > id: 0 > guid: 8710134285551915560 > path: '/dev/gpt/disk0' > phys_path: '/dev/gpt/disk0' > whole_disk: 1 > create_txg: 4 > children[1]: > type: 'disk' > id: 1 > guid: 13312030606858472664 > path: '/dev/gpt/disk2' > phys_path: '/dev/gpt/disk2' > whole_disk: 1 > create_txg: 4 > children[1]: > type: 'mirror' > id: 1 > guid: 4490522279017872594 > metaslab_array: 30 > metaslab_shift: 28 > ashift: 9 > asize: 38942015488 > is_log: 0 > create_txg: 4 > children[0]: > type: 'disk' > id: 0 > guid: 15041339321584576645 > path: '/dev/gpt/disk1' > phys_path: '/dev/gpt/disk1' > whole_disk: 1 > create_txg: 4 > children[1]: > type: 'disk' > id: 1 > guid: 18403473023508789449 > path: '/dev/gpt/disk3' > phys_path: '/dev/gpt/disk3' > whole_disk: 1 > create_txg: 4 > > # zpool status -v > > pool: zroot > state: ONLINE > scan: scrub repaired 0 in 0h57m with 0 errors on Sun Nov 11 > 17:55:44 2012 > config: > > NAME STATE READ WRITE CKSUM > zroot ONLINE 0 0 0 > mirror-0 ONLINE 0 0 0 > gpt/disk0 ONLINE 0 0 0 > gpt/disk2 ONLINE 0 0 0 > mirror-1 ONLINE 0 0 0 > gpt/disk1 ONLINE 0 0 0 > gpt/disk3 ONLINE 0 0 0 > > > grep -v # /etc/make.conf > > CPUTYPE?=athlon-xp > KERNCONF=ATHLON10 > MALLOC_PRODUCTION=YES > WITHOUT_CLANG_IS_CC=YES > MASTER_SITE_APACHE_HTTPD?= http://ftp.tpnet.pl/vol/d1/apache/httpd/ > http://sunsite.icm.edu.pl/pub/www/apache/dist/httpd/ > http://www.apache.net.pl/httpd/ > ftp://ftp.task.gda.pl/pub/www/apache/dist/httpd/ > ftp://sunsite.icm.edu.pl/pub/www/apache/dist/httpd/ > ftp://ftp.tpnet.pl/d1/apache/httpd/ > > .if ${.CURDIR:M*/ports/*} > CFLAGS=-O2 -pipe -fno-strict-aliasing > BUILD_OPTIMIZED=YES > WITH_OPENSSL=YES > WITH_XCHARSET=all > WITH_CHARSET=utf8 > WITH_COLLATION=utf8_general_ci > .endif > > .if ${.CURDIR:M*/usr/src/*} || ${.CURDIR:M*/usr/obj/*} > > CFLAGS=-O2 -pipe -fno-strict-aliasing > COPTFLAGS=-O -pipe > > .if !defined(NOCCACHE) > > CC:=${CC:C,^cc,/usr/local/libexec/ccache/world/cc,1} > CXX:=${CXX:C,^c\+\+,/usr/local/libexec/ccache/world/c++,1} > > .endif > > .endif > > PERL_VERSION=5.14.2 > > grep -v # /boot/loader.conf > > loader_logo="beastie" > autoboot_delay="5" > accf_http_load="YES" > accf_data_load="YES" > vm.kmem_size="1536M" > vm.kmem_size_max="1536M" > zfs_load="YES" > geom_mirror_load="YES" > geom_stripe_load="YES" > aio_load="YES" > vfs.root.mountfrom="zfs:zroot" > > I was cleaning /usr/obj and ccache cache to make sure they are not causing any > problems, no luck. Any ideas? > > Regards, > -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Thu Nov 15 13:06:12 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F3E09FA5; Thu, 15 Nov 2012 13:06:11 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 084FE8FC12; Thu, 15 Nov 2012 13:06:10 +0000 (UTC) Received: from porto.starpoint.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 PAA02734; Thu, 15 Nov 2012 15:06:09 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1TYz8z-000Nc0-7A; Thu, 15 Nov 2012 15:06:09 +0200 Message-ID: <50A4E8C0.5030608@FreeBSD.org> Date: Thu, 15 Nov 2012 15:06:08 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:16.0) Gecko/20121030 Thunderbird/16.0.2 MIME-Version: 1.0 To: freebsd-hackers@FreeBSD.org, freebsd-current@FreeBSD.org Subject: LK_SHARED/LK_DOWNGRADE adjustments to lock.9 manual page X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=X-VIET-VPS Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 13:06:12 -0000 To people knowing the code, do the following documentation changes look correct? --- a/share/man/man9/lock.9 +++ b/share/man/man9/lock.9 @@ -148,7 +148,9 @@ Flags indicating what action is to be taken. .Bl -tag -width ".Dv LK_CANRECURSE" .It Dv LK_SHARED Acquire a shared lock. -If an exclusive lock is currently held, it will be downgraded. +If an exclusive lock is currently held, +.Dv EDEADLK +will be returned. .It Dv LK_EXCLUSIVE Acquire an exclusive lock. If an exclusive lock is already held, and @@ -158,7 +160,8 @@ is not set, the system will .It Dv LK_DOWNGRADE Downgrade exclusive lock to a shared lock. Downgrading a shared lock is not permitted. -If an exclusive lock has been recursed, all references will be downgraded. +If an exclusive lock has been recursed, the system will +.Xr panic 9 . .It Dv LK_UPGRADE Upgrade a shared lock to an exclusive lock. If this call fails, the shared lock is lost. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Thu Nov 15 14:08:34 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 35733F1E for ; Thu, 15 Nov 2012 14:08:34 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id AF4328FC1D for ; Thu, 15 Nov 2012 14:08:33 +0000 (UTC) Received: by mail-we0-f182.google.com with SMTP id x43so718165wey.13 for ; Thu, 15 Nov 2012 06:08:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:subject:message-id:mail-followup-to:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=ZUUQWJ8K7G/1XEu0H2VE9LEcygmUbHVpdKwVQ2m0p8A=; b=Kim/D9YuurbEZNH+1rSlv7SWOHFVZiQxhG+kGytZicvLfjfCohOo3O8jmasnjyvD5u m/IvX5TIpA/Qaop/FKBAMvdBTgTLP3LO4mx4BIXdSCP47xpWbtxbLtGhddfNli6JVDlr dDDRsJ1OqCQUmw3dnQvpPjubREHBbwRgVOgrbSOrVuGP0fakOXAz2Oo1CeWpL5o7tKvT siPThEsXK3Jc89aajRwrtINfGnPz5e7uOka0h/ZCmhrit+rnT5JARm4HuM5QRHd+zJP8 b1F90D/NwpQL5gk/LKWgN5ieThtuKv3N+LmpWtm9G8lpwpTZf6RTBCTPYo87VCHR/dlL 3xBA== Received: by 10.216.50.141 with SMTP id z13mr591136web.29.1352988512128; Thu, 15 Nov 2012 06:08:32 -0800 (PST) Received: from dft-labs.eu (n1x0n-1-pt.tunnel.tserv5.lon1.ipv6.he.net. [2001:470:1f08:1f7::2]) by mx.google.com with ESMTPS id ey2sm7518534wib.9.2012.11.15.06.08.30 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 15 Nov 2012 06:08:30 -0800 (PST) Date: Thu, 15 Nov 2012 15:08:24 +0100 From: Mateusz Guzik To: freebsd-current@freebsd.org Subject: Re: compiler info in kernel identification string Message-ID: <20121115140823.GA4476@dft-labs.eu> Mail-Followup-To: Mateusz Guzik , freebsd-current@freebsd.org References: <20121113234303.GA15319@dft-labs.eu> <20121113235755.GE17755@albert.catwhisker.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20121113235755.GE17755@albert.catwhisker.org> User-Agent: Mutt/1.5.20 (2009-06-14) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 14:08:34 -0000 On Tue, Nov 13, 2012 at 03:57:55PM -0800, David Wolfskill wrote: > I like the idea, but I have long found the idea of putting this type of > logic (including VCS-awareness) in newvers.sh itself something that is > prone to turn what should be a rather simple script into a ... mess. I don't think newvers.sh is a mess (yet) and I find current features highly desirable. > What I have been using for several months has been a modified newvers.sh > that uses an externally-defined function (from a file that is sourced) > to handle whatever VCS-specific things I think are appropriate. (Thus, > folks who want to use one VCS don't need to have newvers.sh test for > VCSen they don't use; they could also provide a sample file that > provides the function. An installation could use a symlink to point to > the function definition of choice.... We could even have a "kitchen > sink" default, that goes through all the hoops & gyrations the current > code does, if folks want that.) newvers.sh definitely should continue to work without hints on cvs/svn/git. Moving checks to different files seems completely unnecessary for me as I don't find current checks expensive. But if you do the work I see nothing wrong with it. :) (but please note I'm in no position to accept your changes) Given that, low-cost support for custom version strings could look like this: after all standard values are filled, prepare complete version string, then source custom script if it exists. This way your script has access to everything that newvers.sh was able to determine and to complete version string, and you are free to change it however you want using detected revision/compiler/whatever or completely new data. -- Mateusz Guzik From owner-freebsd-current@FreeBSD.ORG Thu Nov 15 15:04:13 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D876CFC3 for ; Thu, 15 Nov 2012 15:04:13 +0000 (UTC) (envelope-from lars@netapp.com) Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by mx1.freebsd.org (Postfix) with ESMTP id B06508FC1D for ; Thu, 15 Nov 2012 15:04:13 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.83,258,1352102400"; d="p7s'?scan'208";a="710377741" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 15 Nov 2012 07:04:11 -0800 Received: from vmwexceht05-prd.hq.netapp.com (vmwexceht05-prd.hq.netapp.com [10.106.77.35]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id qAFF4Bsb012235 for ; Thu, 15 Nov 2012 07:04:11 -0800 (PST) Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.216]) by vmwexceht05-prd.hq.netapp.com ([10.106.77.35]) with mapi id 14.02.0318.001; Thu, 15 Nov 2012 07:04:11 -0800 From: "Eggert, Lars" To: "freebsd-current@freebsd.org" Subject: genmodes dumping core during buildworld Thread-Topic: genmodes dumping core during buildworld Thread-Index: AQHNw0J3cFhaUse5wkOXeW8yIV7Drw== Date: Thu, 15 Nov 2012 15:02:36 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.51] Content-Type: multipart/signed; boundary="Apple-Mail=_440A3DBE-5EFA-4D38-BC0B-A20B2C60BA09"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 15:04:13 -0000 --Apple-Mail=_440A3DBE-5EFA-4D38-BC0B-A20B2C60BA09 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, anyone see something similar before: > =3D=3D=3D> usr.sbin/zic/zdump (depend) > rm -f .depend > mkdep -f .depend -a -DTM_GMTOFF=3Dtm_gmtoff -DTM_ZONE=3Dtm_zone = -DSTD_INSPIRED -DPCTS -DHAVE_LONG_DOUBLE -DTZDIR=3D\"/usr/share/zoneinfo\"= -Demkdir=3Dmkdir -I/usr/src/usr.sbin/zic/zdump/.. = -I/usr/src/usr.sbin/zic/zdump/../../../contrib/tzcode/stdtime -std=3Dgnu99= /usr/src/usr.sbin/zic/zdump/../../../contrib/tzcode/zic/zdump.c = /usr/src/usr.sbin/zic/zdump/../../../contrib/tzcode/zic/ialloc.c = /usr/src/usr.sbin/zic/zdump/../../../contrib/tzcode/zic/scheck.c > echo zdump: /usr/obj/usr/src/tmp/usr/lib/libc.a >> .depend > =3D=3D=3D> usr.sbin/zzz (depend) > 1 error > *** [_depend] Error code 2 > 1 error > *** [buildworld] Error code 2 > 1 error This is in the log: > Nov 15 15:56:49 server kernel: pid 83891 (genmodes), uid 0: exited on = signal 10 (core dumped) > Nov 15 15:56:49 server kernel: pid 83893 (genmodes), uid 0: exited on = signal 10 (core dumped) > Nov 15 15:56:49 server kernel: pid 83897 (genmodes), uid 0: exited on = signal 10 (core dumped) genmodes seems to be a component of gcc? Lars= --Apple-Mail=_440A3DBE-5EFA-4D38-BC0B-A20B2C60BA09-- From owner-freebsd-current@FreeBSD.ORG Thu Nov 15 18:46:58 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2C073246; Thu, 15 Nov 2012 18:46:58 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-la0-f54.google.com (mail-la0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 355528FC0C; Thu, 15 Nov 2012 18:46:56 +0000 (UTC) Received: by mail-la0-f54.google.com with SMTP id j13so1864840lah.13 for ; Thu, 15 Nov 2012 10:46:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=QmVBcnp7QxKg2G52n36uYrO8ekdeaKsqqSKFap8YT9A=; b=v5+Wt9pKENbAid7zWt5/WTbXVyXEMc/vcjzzOQ9x70RoYnM+QVOiIrKm4OcOhm+U79 HBg2t2n4zs5hokeeq/e6CsWnMe5AHF3azfbnieOhWBdOUoPZNaBEw6J+M/qk+J4R1Bg7 HVDU101Dtz1+PWFLSdeoZ8UwJKoskRmwj/tabAIS2BRoHHYj84acp1p1SlDyyN+2W04P ECuw31rjfep60wjPS/gF53MAQBlIoAqhGd7HZmHOw8ZwvWklgKC2biI23o9adHQO7uhu T/XgnZ6gtVaE+E7A5c+RdJ04uH+y/RZZSQBfqtNHht4fxAdJrBso+C4tGX1pUMQl94kE t+Hw== MIME-Version: 1.0 Received: by 10.152.104.50 with SMTP id gb18mr2032232lab.9.1353005215940; Thu, 15 Nov 2012 10:46:55 -0800 (PST) Sender: asmrookie@gmail.com Received: by 10.112.134.5 with HTTP; Thu, 15 Nov 2012 10:46:55 -0800 (PST) In-Reply-To: <50A4E8C0.5030608@FreeBSD.org> References: <50A4E8C0.5030608@FreeBSD.org> Date: Thu, 15 Nov 2012 18:46:55 +0000 X-Google-Sender-Auth: t93cp-UE9SzJgNev7ybwPsBfpUg Message-ID: Subject: Re: LK_SHARED/LK_DOWNGRADE adjustments to lock.9 manual page From: Attilio Rao To: Andriy Gapon Content-Type: text/plain; charset=UTF-8 Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: attilio@FreeBSD.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 18:46:58 -0000 On 11/15/12, Andriy Gapon wrote: > > To people knowing the code, > > do the following documentation changes look correct? The latter chunk is not correct. It will panic only if assertions are on. I was thinking that however it would be good idea to patch lockmgr to panic also in non-debugging kernel situation. Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-current@FreeBSD.ORG Thu Nov 15 18:47:52 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 48D1B441 for ; Thu, 15 Nov 2012 18:47:52 +0000 (UTC) (envelope-from ianf@clue.co.za) Received: from zcs03.jnb1.cloudseed.co.za (zcs03.jnb1.cloudseed.co.za [41.154.0.139]) by mx1.freebsd.org (Postfix) with ESMTP id C83A48FC14 for ; Thu, 15 Nov 2012 18:47:51 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zcs03.jnb1.cloudseed.co.za (Postfix) with ESMTP id D77EA2B42C0C for ; Thu, 15 Nov 2012 20:47:42 +0200 (SAST) X-Virus-Scanned: amavisd-new at zcs03.jnb1.cloudseed.co.za Received: from zcs03.jnb1.cloudseed.co.za ([127.0.0.1]) by localhost (zcs03.jnb1.cloudseed.co.za [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 76iVs9VDHVvm for ; Thu, 15 Nov 2012 20:47:41 +0200 (SAST) Received: from clue.co.za (unknown [41.154.88.19]) by zcs03.jnb1.cloudseed.co.za (Postfix) with ESMTPSA id 907462B42BC7 for ; Thu, 15 Nov 2012 20:47:41 +0200 (SAST) Received: from localhost ([127.0.0.1] helo=clue.co.za) by clue.co.za with esmtp (Exim 4.80 (FreeBSD)) (envelope-from ) id 1TZ4TT-0000z7-H8 for current@freebsd.org; Thu, 15 Nov 2012 20:47:39 +0200 To: current@freebsd.org From: Ian FREISLICH Subject: cvsup/csup servers stale? X-Attribution: BOFH Date: Thu, 15 Nov 2012 20:47:39 +0200 Message-Id: X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 18:47:52 -0000 Hi Has the svn->cvs exporter died? Or have the cvsup/csup servers been retired as threatened in a previous thread (I might have missed the headsup)? Ian -- Ian Freislich From owner-freebsd-current@FreeBSD.ORG Thu Nov 15 18:59:12 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 022049CE for ; Thu, 15 Nov 2012 18:59:11 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: from mail-la0-f54.google.com (mail-la0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 487C58FC14 for ; Thu, 15 Nov 2012 18:59:10 +0000 (UTC) Received: by mail-la0-f54.google.com with SMTP id j13so1876898lah.13 for ; Thu, 15 Nov 2012 10:59:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=eZSvSVLredgtexTY5biJPRI6p2mxQpUux8HHKJ5zngc=; b=EobvnGqKbT/PLOXQ9ZKEo7FIeizGcZZDiodUfVkVr0JG1llhwJK6RlYk0AHpqE3f8I xCYkPaVxWzYDpJlFd8ioL1zaSg2nl6N667ahv1ZFMsDBPPPK29HLDuW84f0lI4Ph2GZp ahy85kdf0ULYbBwPDweo19z7Z25QnZy5rUOUk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=eZSvSVLredgtexTY5biJPRI6p2mxQpUux8HHKJ5zngc=; b=pg9PC41O3VYv0h8rlz0oIpjgtHdRy9iOz8JU+zqRuD2WgBpADdNOA8PjZ0S71OyD3M NG9P6xK6yu6dpNeMA6uqxJicuYZCIdej2vfGTi9NSs0mMFMCaX1A0G1l1ZTvvbQOwXKu ach33LAWf63yhBU9wi9L0kXWOkoGcpkMellDo8uqRjakXegN7AbXHK24hbIgaQh48aWD b/0HvxaE+Y6QJ+OlPoLdJK3nQhqx6i/Fxfte5T+W94M0nhZ0/uoPph2SI3y2vV1Bd6UE CS3XWNCIS/JxrbTizk+iBJ/blwIuivxv+nMyiFKg+b6SSNJOFhEJZi8VOPbXgVJ0FEN8 IGGQ== Received: by 10.152.104.115 with SMTP id gd19mr2037051lab.13.1353005950056; Thu, 15 Nov 2012 10:59:10 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.25.166 with HTTP; Thu, 15 Nov 2012 10:58:39 -0800 (PST) In-Reply-To: References: From: Eitan Adler Date: Thu, 15 Nov 2012 13:58:39 -0500 Message-ID: Subject: Re: cvsup/csup servers stale? To: Ian FREISLICH Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQlaoqu9oY3jJrJzaC+G0Y9kdZ9FJzgKmwxJGjxEMoRVEi9jotjJH+6YhP1OyjSER3bL3RM+ Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 18:59:12 -0000 On 15 November 2012 13:47, Ian FREISLICH wrote: > Hi > > Has the svn->cvs exporter died? Or have the cvsup/csup servers > been retired as threatened in a previous thread (I might have missed > the headsup)? The FreeBSD cluster is undergoing maintenance. In particular the main machines were recently physically moved, upgraded, and discombobulated. A number of services are down but we are working on fixing this as fast as possible! -- Eitan Adler From owner-freebsd-current@FreeBSD.ORG Thu Nov 15 19:09:36 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E46B2D37 for ; Thu, 15 Nov 2012 19:09:36 +0000 (UTC) (envelope-from break19@gmail.com) Received: from mail-ie0-f182.google.com (mail-ie0-f182.google.com [209.85.223.182]) by mx1.freebsd.org (Postfix) with ESMTP id 9E86C8FC08 for ; Thu, 15 Nov 2012 19:09:36 +0000 (UTC) Received: by mail-ie0-f182.google.com with SMTP id k10so3285754iea.13 for ; Thu, 15 Nov 2012 11:09:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=wHrTkUyjKCnF/AeqV7fdMvZyjTzQplucPnTQfLmscLI=; b=zgPadb/PxbMfb8xriXkevJbccaJd/kYDqQb59XkkWH8P7u8uMJfTu3z4Xhopisuash i7v4fE8WAHdAGXsw7OF4A0ctHUi6aOd28xBW+DRqFSASYBVdv/OplKjD8MBP8Xp8WK2b e/nF3Q7vWCqv2BG8OJ37SwzmD17FUYDusP0ngE/343azoGY43NgypluobMwMyZwBfRh9 85y31LtBNu4uT/E7PsiK/9bz9oAdYZoS6G9rd9q2Z2Nf8awgk7wzEKVAFdWBQja38mq1 OwL0ikdLSGeIUDX9Safz3KcIDYZxLlFznoMIPUMWOtwO7YPn7x/S91i5GAGM5fSTgNWV XZxA== Received: by 10.50.173.34 with SMTP id bh2mr835474igc.70.1353006575659; Thu, 15 Nov 2012 11:09:35 -0800 (PST) Received: from [192.168.0.199] ([173.156.239.181]) by mx.google.com with ESMTPS id x7sm4660579igk.8.2012.11.15.11.09.32 (version=SSLv3 cipher=OTHER); Thu, 15 Nov 2012 11:09:35 -0800 (PST) Message-ID: <50A53DB6.60907@gmail.com> Date: Thu, 15 Nov 2012 13:08:38 -0600 From: Chuck Burns User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: cvsup/csup servers stale? References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 19:09:37 -0000 On 11/15/2012 12:58 PM, Eitan Adler wrote: > On 15 November 2012 13:47, Ian FREISLICH wrote: >> Hi >> >> Has the svn->cvs exporter died? Or have the cvsup/csup servers >> been retired as threatened in a previous thread (I might have missed >> the headsup)? > > The FreeBSD cluster is undergoing maintenance. In particular the main > machines were recently physically moved, upgraded, and > discombobulated. > A number of services are down but we are working on fixing this as > fast as possible! > > I want my money back! :) Upgrades are always fun. *throws his hands up and shouts "whee!!" as the rollercoaster goes up and down* No worries. :) -- Chuck Burns From owner-freebsd-current@FreeBSD.ORG Thu Nov 15 19:24:10 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 48622514 for ; Thu, 15 Nov 2012 19:24:10 +0000 (UTC) (envelope-from sfourman@gmail.com) Received: from mail-ee0-f54.google.com (mail-ee0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id C46148FC14 for ; Thu, 15 Nov 2012 19:24:09 +0000 (UTC) Received: by mail-ee0-f54.google.com with SMTP id c13so1476573eek.13 for ; Thu, 15 Nov 2012 11:24:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=b/5qhda9vJAdNKIHwxzU3Y5WPVzpxjxEldh7S6jMuZQ=; b=TTDuDR9+g2g9XFXh32tj2RMGGAHHw3Dr2sxcRNsQRNTM4uJrZB28/A5O5DOHPJHuDF Ndl0fVXo1Gke3gP8YKEH6TpwBIuUXnkwni2bBTWmE3/j7Ok6ozzBIGSzjFpJgkpHoDFP g2oEBNvWrz/m80LM9PbLVzUpDZNd9zFKyNDLRpiMz3KoXrM8bB5lpYn+2RKxPUY0ktav gVwkmRlsF2qLCfSHGDw0tZ7iTIDY54UpOkxfzr38WykgcpxaEapHwxbvBpCHVQGQk42Y BUDZL7MC/loq80f9/e+XzrYCriCneZlB6j+tHSp3INFI5dmPn6YLGRB0FBKBDYvILw9G 7gTg== MIME-Version: 1.0 Received: by 10.14.184.1 with SMTP id r1mr6855622eem.4.1353007448533; Thu, 15 Nov 2012 11:24:08 -0800 (PST) Received: by 10.14.216.201 with HTTP; Thu, 15 Nov 2012 11:24:08 -0800 (PST) In-Reply-To: References: Date: Thu, 15 Nov 2012 13:24:08 -0600 Message-ID: Subject: Re: USB keyboard problem From: "Sam Fourman Jr." To: FreeBSD Current Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 19:24:10 -0000 On Mon, Nov 12, 2012 at 2:22 PM, Sam Fourman Jr. wrote: > hello, > > I believe my keyboard is being detected as a mouse by mistake using amd64 > HEAD svn r242748 > I can not use this keyboard, I have to plug in another one. > > this is also broken in FreeBSD 9.1RC3 > > is this simple to patch? any help is appreciated > > > uhid0: on usbus0 > uhid1: on > usbus3 > ums0: on usbus0 > ums0: 3 buttons and [XYZ] coordinates ID=0 > ums1: on usbus0 > ums1: 7 buttons and [XYZ] coordinates ID=0 > > > verbose dmesg follows > http://www.samjess.com/keyboard.txt > > -- > > Sam Fourman Jr. > What does "usbconfig -d X.Y dump_device_desc dump_curr_config_desc" say about > your device? > > --HPS > http://www.samjess.com/usbconfig.txt Does anyone know where I would start hacking around to fix this? Sam From owner-freebsd-current@FreeBSD.ORG Thu Nov 15 19:58:40 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 49CE1FCD for ; Thu, 15 Nov 2012 19:58:40 +0000 (UTC) (envelope-from cattelan@thebarn.com) Received: from x.digitalelves.com (x.digitalelves.com [209.98.77.55]) by mx1.freebsd.org (Postfix) with ESMTP id D9FEA8FC14 for ; Thu, 15 Nov 2012 19:58:39 +0000 (UTC) Received: from Russells-Lion-Hackintosh.local (c-66-41-26-220.hsd1.mn.comcast.net [66.41.26.220]) (authenticated bits=0) by x.digitalelves.com (8.14.5/8.14.5) with ESMTP id qAFJwb7l041731 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Thu, 15 Nov 2012 13:58:38 -0600 (CST) (envelope-from cattelan@thebarn.com) Message-ID: <50A5496A.6020406@thebarn.com> Date: Thu, 15 Nov 2012 13:58:34 -0600 From: Russell Cattelan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: Anybody willing to test out kload? References: <50A41395.7080205@thebarn.com> <50A4C109.10003@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.4.5 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig81808E65357A9818B97E8C18" X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 19:58:40 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig81808E65357A9818B97E8C18 Content-Type: multipart/mixed; boundary="------------040106060404070800040801" This is a multi-part message in MIME format. --------------040106060404070800040801 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 11/15/12 5:40 AM, Ivan Voras wrote: > On 15/11/2012 11:16, Andriy Gapon wrote: >> on 14/11/2012 23:56 Russell Cattelan said the following: >>> This has been sitting on my plate for a while and I would like to get= some >>> more feedback / testing on this feature. >> >> A few words about what kload is and how to use/test it might increase = chances >> of that actually happening. >=20 > Google finds this: > http://www.bsdcan.org/2012/schedule/events/325.en.html yes thank you. This is probably the best place for info on kload currently. I need to create a wiki page soon. >=20 > I would have thought the major problem here is not the kernel itself bu= t > the drivers, leaving hardware in undetermined state (especially server > hardware, which is numerous and surprisingly sensitive to there being > One True Way to initialize it). >=20 Yup... this is what I would like to hear about. Which drivers / cards are not behaving well and may need some attention. -Russell --------------040106060404070800040801-- --------------enig81808E65357A9818B97E8C18 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.12 (Darwin) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlClSW0ACgkQNRmM+OaGhBhFzwCaA9oZ8Zk1+eOVmNEP+VqLc/Nv fwgAmQGKDm4+T+Bqzw1qo1pcTfEIxzlS =+6Ss -----END PGP SIGNATURE----- --------------enig81808E65357A9818B97E8C18-- From owner-freebsd-current@FreeBSD.ORG Thu Nov 15 20:38:35 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4E976CA1; Thu, 15 Nov 2012 20:38:35 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 193058FC08; Thu, 15 Nov 2012 20:38:33 +0000 (UTC) Received: from porto.starpoint.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 WAA06227; Thu, 15 Nov 2012 22:38:32 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1TZ6Cl-000Nz0-Ri; Thu, 15 Nov 2012 22:38:31 +0200 Message-ID: <50A552C5.5060703@FreeBSD.org> Date: Thu, 15 Nov 2012 22:38:29 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:16.0) Gecko/20121030 Thunderbird/16.0.2 MIME-Version: 1.0 To: attilio@FreeBSD.org Subject: Re: LK_SHARED/LK_DOWNGRADE adjustments to lock.9 manual page References: <50A4E8C0.5030608@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@FreeBSD.org, freebsd-current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 20:38:35 -0000 on 15/11/2012 20:46 Attilio Rao said the following: > On 11/15/12, Andriy Gapon wrote: >> >> To people knowing the code, >> >> do the following documentation changes look correct? > > The latter chunk is not correct. > It will panic only if assertions are on. But the current content is not correct too? > I was thinking that however > it would be good idea to patch lockmgr to panic also in non-debugging > kernel situation. It would make sense indeed, IMO. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Thu Nov 15 20:44:01 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3B72AEC6 for ; Thu, 15 Nov 2012 20:44:01 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 783988FC08 for ; Thu, 15 Nov 2012 20:44:00 +0000 (UTC) Received: from porto.starpoint.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 WAA06269; Thu, 15 Nov 2012 22:43:58 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1TZ6I1-000NzD-RW; Thu, 15 Nov 2012 22:43:57 +0200 Message-ID: <50A5540D.2030707@FreeBSD.org> Date: Thu, 15 Nov 2012 22:43:57 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:16.0) Gecko/20121030 Thunderbird/16.0.2 MIME-Version: 1.0 To: Mateusz Guzik , freebsd-current@FreeBSD.org Subject: Re: compiler info in kernel identification string References: <20121113234303.GA15319@dft-labs.eu> In-Reply-To: <20121113234303.GA15319@dft-labs.eu> X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 20:44:01 -0000 on 14/11/2012 01:43 Mateusz Guzik said the following: > Hello, > > avg@ suggested to include compiler version in the kernel so that it's > present in uname (and one can easly tell what was used to compile it). > > Here is my attempt: > http://people.freebsd.org/~mjg/patches/newvers-compiler.diff When are you committing this? > Basically adds compiler name and version/revision after revision of > system sources. > > Sample output from dirty git sources: > gcc: > FreeBSD 10.0-CURRENT #7 r242962=264d569-dirty(gcc-4.2.1-20070831): Wed > Nov 14 00:11:51 CET 2012 > > clang: > FreeBSD 10.0-CURRENT #8 r242962=264d569-dirty(clang-r162107): Wed Nov 14 > 00:12:26 CET 2012 > > Sample output from svn with gcc: > FreeBSD 10.0-CURRENT #1 r243006:243007M(gcc-4.2.1-20070831): Wed Nov 14 > 00:41:23 CET 2012 > > I have no strong opinions on format, I just want this information easly > accessible. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Thu Nov 15 21:44:46 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 60DE1429; Thu, 15 Nov 2012 21:44:46 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id 76E288FC0C; Thu, 15 Nov 2012 21:44:45 +0000 (UTC) Received: by mail-lb0-f182.google.com with SMTP id gg13so2108131lbb.13 for ; Thu, 15 Nov 2012 13:44:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=FntpHllDouwqnrIGT0VbU6fCPv4Hg85yZMJs+WRa6DY=; b=dTnxR/gqiWEeKDXacNdtjBTR0RYzqscOcT9fu99pIa6QAXOtWmxV0MIhJP/fdoefzi QBXgp3wvywOYXYZDWQS9aRCvwVXGjH+aKazJYQhbL7jIzGXVovPwqeVnncr8dlOhwA9g L9jOP1FQJYv8xTskXOQxttsDPvJVSEkh4J0RKyxLJzyqv120Dyeu7iiKRa6BNPEOoIZY neOxOVKL57pbrwVXPSkWKbqZqjOjn1+6ld8I0qaItEiBrVingLFWjaWBKH9yPnjL80Ap 1BrbogWVRK7VLuPxuZ1fGO8pFtrrxn+uSSMytRaACtNtZH/PoRIXfy0s6nMpTqwP6hhK Nofw== MIME-Version: 1.0 Received: by 10.152.123.103 with SMTP id lz7mr2378431lab.21.1353015884248; Thu, 15 Nov 2012 13:44:44 -0800 (PST) Sender: asmrookie@gmail.com Received: by 10.112.134.5 with HTTP; Thu, 15 Nov 2012 13:44:44 -0800 (PST) In-Reply-To: <50A552C5.5060703@FreeBSD.org> References: <50A4E8C0.5030608@FreeBSD.org> <50A552C5.5060703@FreeBSD.org> Date: Thu, 15 Nov 2012 21:44:44 +0000 X-Google-Sender-Auth: dTPUs2IPiyxLhF5FOAaNrillnpQ Message-ID: Subject: Re: LK_SHARED/LK_DOWNGRADE adjustments to lock.9 manual page From: Attilio Rao To: Andriy Gapon Content-Type: text/plain; charset=UTF-8 Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: attilio@FreeBSD.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 21:44:46 -0000 On Thu, Nov 15, 2012 at 8:38 PM, Andriy Gapon wrote: > on 15/11/2012 20:46 Attilio Rao said the following: >> On 11/15/12, Andriy Gapon wrote: >>> >>> To people knowing the code, >>> >>> do the following documentation changes look correct? >> >> The latter chunk is not correct. >> It will panic only if assertions are on. > > But the current content is not correct too? Indeed, current content is crappy. >> I was thinking that however >> it would be good idea to patch lockmgr to panic also in non-debugging >> kernel situation. > > It would make sense indeed, IMO. Do you think you can test this patch?: http://www.freebsd.org/~attilio/lockmgr_forcerec.patch I think the LK_NOSHARE case is still fine with just asserts. Once this patch goes in, you are free to commit your documentation one. Thanks for fixing doc. Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-current@FreeBSD.ORG Thu Nov 15 23:05:40 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3C5D1469; Thu, 15 Nov 2012 23:05:40 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) by mx1.freebsd.org (Postfix) with ESMTP id E5C378FC12; Thu, 15 Nov 2012 23:05:39 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:548c:a8ca:65a3:1c17] (unknown [IPv6:2001:7b8:3a7:0:548c:a8ca:65a3:1c17]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id B33345C59; Fri, 16 Nov 2012 00:05:32 +0100 (CET) Message-ID: <50A5753D.5000001@FreeBSD.org> Date: Fri, 16 Nov 2012 00:05:33 +0100 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Andriy Gapon Subject: Re: compiler info in kernel identification string References: <20121113234303.GA15319@dft-labs.eu> <50A5540D.2030707@FreeBSD.org> In-Reply-To: <50A5540D.2030707@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Mateusz Guzik , freebsd-current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 23:05:40 -0000 On 2012-11-15 21:43, Andriy Gapon wrote:> on 14/11/2012 01:43 Mateusz Guzik said the following: >> Hello, >> >> avg@ suggested to include compiler version in the kernel so that it's >> present in uname (and one can easly tell what was used to compile it). >> >> Here is my attempt: >> http://people.freebsd.org/~mjg/patches/newvers-compiler.diff > > When are you committing this? Please don't commit it yet, we're not done reviewing. :) For starters, this hardcodes the compiler names "gcc" and "clang", and this will include incorrect information into the kernel version string, if you use another setting for ${CC}. Then, if you fix the script use ${CC}, and set it to gcc versions from ports (for example), the parsing breaks down, as I expected: $ echo $CC /usr/local/bin/gcc47 $ compiler="gcc-"`$CC --version | head -n1 | awk '{ print $3 "-" $4}'` $ echo $compiler gcc-Ports-Collection) So please fix this first. Either handle all possible variants of version output, or just put the version string verbatim into the identification. I would opt for the latter. Last but not least, I am not sure this information belongs in uname at all. Maybe it would be better to put it somewhere else, in a sysctl, or show it in dmesg. From owner-freebsd-current@FreeBSD.ORG Thu Nov 15 23:09:24 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 65C0C5EC; Thu, 15 Nov 2012 23:09:24 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) by mx1.freebsd.org (Postfix) with ESMTP id 1C8AF8FC14; Thu, 15 Nov 2012 23:09:24 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:548c:a8ca:65a3:1c17] (unknown [IPv6:2001:7b8:3a7:0:548c:a8ca:65a3:1c17]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 55D415C59; Fri, 16 Nov 2012 00:09:23 +0100 (CET) Message-ID: <50A57623.4020108@FreeBSD.org> Date: Fri, 16 Nov 2012 00:09:23 +0100 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Ian Lepore Subject: Re: compiler info in kernel identification string References: <20121113234303.GA15319@dft-labs.eu> <50A3639C.9050200@FreeBSD.org> <1352907497.1217.147.camel@revolution.hippie.lan> In-Reply-To: <1352907497.1217.147.camel@revolution.hippie.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Mateusz Guzik , avg@freebsd.org, freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 23:09:24 -0000 On 2012-11-14 16:38, Ian Lepore wrote: > On Wed, 2012-11-14 at 10:25 +0100, Dimitry Andric wrote: ... >> That way, you are sure never to lose information. This also works for >> gcc from ports (which is the reason for the space after 'version' in the >> grep command): >> >> $ gcc47 -v 2>&1 | grep 'version ' >> gcc version 4.7.3 20120929 (prerelease) (FreeBSD Ports Collection) >> >> I realize this is a bit long, but it is better to have complete than >> stripped information. > > Rather than just taking whatever the compiler emits, the proposed patch > seems to be carefully crafted to avoid breaking existing 3rd party tools > which parse uname output based on the location of whitespace. I'm not > sure how important that is given that the uname manpage doesn't document > the output format as if it were somehow rigidly specified. I can see where you're coming from, but I also think it is very fragile to depend on parsing such information from uname. If you do so, you must be prepared to accept wonky input, otherwise, just don't do it. :) And as I remarked in another reply, now that I have thought about it a bit, I would much rather see this information moved to a sysctl or dmesg line, than in uname. With the happy side effect that no existing uname parsers would be confused! From owner-freebsd-current@FreeBSD.ORG Thu Nov 15 23:35:28 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6F160372; Thu, 15 Nov 2012 23:35:28 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by mx1.freebsd.org (Postfix) with ESMTP id 9C10D8FC14; Thu, 15 Nov 2012 23:35:27 +0000 (UTC) Received: by mail-wi0-f178.google.com with SMTP id hm14so1272538wib.13 for ; Thu, 15 Nov 2012 15:35:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=A4g527LvXI6Jt39ivCJUuoyWLVq47cb3scSLP27ONrc=; b=P4lPdkX6SYFWGOCaAb7Ev2QGHzswdc0am9+dmypU/HASpiUaGSQEdw9SabVoUTVb8D cd4rtl4WndFiaVegCdIcfip9uyW2afKbjpLYwhwtKPU5DfXpkopMqEpgbOkD1TtV+0fX f3CtImGMdjxT2NGi7bK37Yana4Mv9PonQAie3Xe+GkOnnZ4Mi0j6OQ21JCBGw1b1bT3C itp+PWkZc9DOllwui3Qjh4JseulUsubW3G50Go/rwvfD8qRWyd6H+CRHXaAFFDUTChFs t5RAhqtj4tM3mQjJ/JadKG1uHLao7gK96cF8mMNQdBseuz+5yZrVJCL3EaS60vDfBIMJ kzEA== Received: by 10.180.19.197 with SMTP id h5mr2375506wie.22.1353022526571; Thu, 15 Nov 2012 15:35:26 -0800 (PST) Received: from dft-labs.eu (n1x0n-1-pt.tunnel.tserv5.lon1.ipv6.he.net. [2001:470:1f08:1f7::2]) by mx.google.com with ESMTPS id d9sm1812204wiw.0.2012.11.15.15.35.25 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 15 Nov 2012 15:35:25 -0800 (PST) Date: Fri, 16 Nov 2012 00:35:15 +0100 From: Mateusz Guzik To: Dimitry Andric Subject: Re: compiler info in kernel identification string Message-ID: <20121115233515.GB19671@dft-labs.eu> Mail-Followup-To: Mateusz Guzik , Dimitry Andric , Andriy Gapon , freebsd-current@FreeBSD.org References: <20121113234303.GA15319@dft-labs.eu> <50A5540D.2030707@FreeBSD.org> <50A5753D.5000001@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <50A5753D.5000001@FreeBSD.org> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-current@FreeBSD.org, Andriy Gapon X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 23:35:28 -0000 On Fri, Nov 16, 2012 at 12:05:33AM +0100, Dimitry Andric wrote: > For starters, this hardcodes the compiler names "gcc" and "clang", and > this will include incorrect information into the kernel version string, > if you use another setting for ${CC}. > Yes, I blindly assumed that both gcc and clang will keep format of --version. For everything else you would get 'unknown-compiler'. > > Last but not least, I am not sure this information belongs in uname at > all. Maybe it would be better to put it somewhere else, in a sysctl, or > show it in dmesg. As stated in original mail, I don't have strong opinions on this. I only care about accessibility of this information. So, here is my patch that adds information at boot time and sysctl kern.compiler: http://people.freebsd.org/~mjg/patches/compiler-info.diff Sample output: Copyright (c) 1992-2012 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 10.0-CURRENT #281 r243095=c24a389-dirty: Fri Nov 16 00:24:46 CET 2012 f@lap:/usr/obj/i386.i386/srv/repos/freebsd/sys/DEVEL i386 Compiled with cc (GCC) 4.2.1 20070831 patched [FreeBSD] <------ HERE WARNING: WITNESS option enabled, expect reduced performance. WARNING: DIAGNOSTIC option enabled, expect reduced performance. CPU: Intel(R) Core(TM)2 Duo CPU P9600 @ 2.66GHz (2635.19-MHz 686-class CPU) [..] As you can see only first line is captured and I go with assumption that --version works, I hope this is ok. -- Mateusz Guzik From owner-freebsd-current@FreeBSD.ORG Thu Nov 15 23:37:07 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 686B249D for ; Thu, 15 Nov 2012 23:37:07 +0000 (UTC) (envelope-from jakub_lach@mailplus.pl) Received: from sam.nabble.com (sam.nabble.com [216.139.236.26]) by mx1.freebsd.org (Postfix) with ESMTP id 44B0B8FC12 for ; Thu, 15 Nov 2012 23:37:06 +0000 (UTC) Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1TZ8zT-0000wD-VJ for freebsd-current@freebsd.org; Thu, 15 Nov 2012 15:36:59 -0800 Date: Thu, 15 Nov 2012 15:36:59 -0800 (PST) From: Jakub Lach To: freebsd-current@freebsd.org Message-ID: <1353022619962-5761389.post@n5.nabble.com> In-Reply-To: <50A53DB6.60907@gmail.com> References: <50A53DB6.60907@gmail.com> Subject: Re: cvsup/csup servers stale? MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 23:37:07 -0000 Good luck with employing full discombobulation! I think this is the main requirement for _cloud computing_. -- View this message in context: http://freebsd.1045724.n5.nabble.com/cvsup-csup-servers-stale-tp5761290p5761389.html Sent from the freebsd-current mailing list archive at Nabble.com. From owner-freebsd-current@FreeBSD.ORG Thu Nov 15 23:39:02 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9951D748 for ; Thu, 15 Nov 2012 23:39:02 +0000 (UTC) (envelope-from tomek.cedro@gmail.com) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id 1A0A48FC08 for ; Thu, 15 Nov 2012 23:39:01 +0000 (UTC) Received: by mail-lb0-f182.google.com with SMTP id gg13so2183231lbb.13 for ; Thu, 15 Nov 2012 15:39:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=Vq1Dm2MOg8izeqVYROyylBUQjUekTrqkUD51pnRMXB0=; b=azFD/UnTgFMd603qhsTTf1ezS1DnUbSVIQunVJbrvFsE9YcVSAhlwlDrGdlgTmB6LW iH1xkkuDYMPj5zhyqv7jGbb/nOD8Oiqxe4ZxIkszC8APE/eaUd4E3uKJzXulHZeC6wf3 68E9S0+jpCiYT1Y4rrLfdcgZJD4RTbF2LZq3KjTELT0UOPVk4OQifIcOaOmFu7jaXG+0 Ai5HypFJAXJ+pXnCAqMAaiCzJJe9DOLwCH76f1dZT56A5oKF6+J2TULn3P2VWgE94nZt J2T+HcKBW/gmS6iqjOsiuKtTjb40kXFP0k1VNbKMWLLKIqCW1qD/Qum0ZJIVye4m2kPI d5+w== MIME-Version: 1.0 Received: by 10.112.102.130 with SMTP id fo2mr1298335lbb.35.1353022740884; Thu, 15 Nov 2012 15:39:00 -0800 (PST) Received: by 10.114.12.226 with HTTP; Thu, 15 Nov 2012 15:39:00 -0800 (PST) Date: Fri, 16 Nov 2012 00:39:00 +0100 Message-ID: Subject: UTF-8 console From: Tomek CEDRO To: freebsd-current@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Mailman-Approved-At: Fri, 16 Nov 2012 00:16:56 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 23:39:02 -0000 Hello :-) I was wondering if its possible to have UTF-8 console? ISO seems to be a bit outdated these days and less comfortable for multinational applications :-) Best regards :-) Tomek -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info From owner-freebsd-current@FreeBSD.ORG Fri Nov 16 00:37:41 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3E25277C for ; Fri, 16 Nov 2012 00:37:41 +0000 (UTC) (envelope-from jakub_lach@mailplus.pl) Received: from sam.nabble.com (sam.nabble.com [216.139.236.26]) by mx1.freebsd.org (Postfix) with ESMTP id 143B18FC08 for ; Fri, 16 Nov 2012 00:37:40 +0000 (UTC) Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1TZ9wC-00079h-5Q for freebsd-current@freebsd.org; Thu, 15 Nov 2012 16:37:40 -0800 Date: Thu, 15 Nov 2012 16:37:40 -0800 (PST) From: Jakub Lach To: freebsd-current@freebsd.org Message-ID: <1353026260160-5761407.post@n5.nabble.com> In-Reply-To: References: Subject: Re: UTF-8 console MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 00:37:41 -0000 http://wiki.freebsd.org/SysconsUnicodeProject -- View this message in context: http://freebsd.1045724.n5.nabble.com/UTF-8-console-tp5761405p5761407.html Sent from the freebsd-current mailing list archive at Nabble.com. From owner-freebsd-current@FreeBSD.ORG Fri Nov 16 01:28:21 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BA8ABBA7 for ; Fri, 16 Nov 2012 01:28:21 +0000 (UTC) (envelope-from kabaev@gmail.com) Received: from mail-qc0-f182.google.com (mail-qc0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id 5FBAB8FC15 for ; Fri, 16 Nov 2012 01:28:20 +0000 (UTC) Received: by mail-qc0-f182.google.com with SMTP id k19so1855316qcs.13 for ; Thu, 15 Nov 2012 17:28:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type; bh=r04YGMeHJj8YMinV0t88zutJBX77juX6PmqTi1PaT7Y=; b=QHF9syhQX33rB6viDpdOW8mOEBuRNhc7BD3PbEBo3CmbKTrpc+5JS8FjTrRdJI1h7z 0yMfS4Or6qettekQ3amhFzPJqy1HknTUEKWErRVLaqpjwgMeLCyquGduixQsluIJ/ye3 kJJixusdqbm2ALDQPRt8QBThZPkJxvntIzNHYSqNtUv843aRhjEzLW5GgBwzwAK4hvCQ mcOfu27LM/D+zMyI4ow9M7ZIXD95fqGxt/FdSqVkNL4k+L5juop1AODXzo3j5N4oQ+lk KNHeRq9PNUNsELOPCd4iPP3p7vbQ2MlqjJg19+Qpq28MIZdw/8ZgQ0BmtUt+WAY0oC0M fd9Q== Received: by 10.224.78.148 with SMTP id l20mr3027194qak.27.1353029293874; Thu, 15 Nov 2012 17:28:13 -0800 (PST) Received: from kan.dyndns.org (c-24-63-226-98.hsd1.ma.comcast.net. [24.63.226.98]) by mx.google.com with ESMTPS id j3sm99713qek.7.2012.11.15.17.28.12 (version=SSLv3 cipher=OTHER); Thu, 15 Nov 2012 17:28:12 -0800 (PST) Date: Thu, 15 Nov 2012 20:28:07 -0500 From: Alexander Kabaev To: "Eggert, Lars" Subject: Re: genmodes dumping core during buildworld Message-ID: <20121115202807.2fb79dd0@kan.dyndns.org> In-Reply-To: References: X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.6; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/EBRPQtoqI0G7FqT1+tW3iHI"; protocol="application/pgp-signature" Cc: "freebsd-current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 01:28:22 -0000 --Sig_/EBRPQtoqI0G7FqT1+tW3iHI Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Thu, 15 Nov 2012 15:02:36 +0000 "Eggert, Lars" wrote: > Hi, >=20 > anyone see something similar before: >=20 > > =3D=3D=3D> usr.sbin/zic/zdump (depend) > > rm -f .depend > > mkdep -f .depend -a -DTM_GMTOFF=3Dtm_gmtoff -DTM_ZONE=3Dtm_zone > > -DSTD_INSPIRED -DPCTS -DHAVE_LONG_DOUBLE > > -DTZDIR=3D\"/usr/share/zoneinfo\" -Demkdir=3Dmkdir > > -I/usr/src/usr.sbin/zic/zdump/.. > > -I/usr/src/usr.sbin/zic/zdump/../../../contrib/tzcode/stdtime > > -std=3Dgnu99 /usr/src/usr.sbin/zic/zdump/../../../contrib/tzcode/zic/= zdump.c /usr/src/usr.sbin/zic/zdump/../../../contrib/tzcode/zic/ialloc.c /u= sr/src/usr.sbin/zic/zdump/../../../contrib/tzcode/zic/scheck.c > > echo zdump: /usr/obj/usr/src/tmp/usr/lib/libc.a >> .depend =3D=3D=3D> > > usr.sbin/zzz (depend) 1 error *** [_depend] Error code 2 1 error > > *** [buildworld] Error code 2 1 error >=20 > This is in the log: >=20 > > Nov 15 15:56:49 server kernel: pid 83891 (genmodes), uid 0: exited > > on signal 10 (core dumped) Nov 15 15:56:49 server kernel: pid 83893 > > (genmodes), uid 0: exited on signal 10 (core dumped) Nov 15 > > 15:56:49 server kernel: pid 83897 (genmodes), uid 0: exited on > > signal 10 (core dumped) >=20 >=20 > genmodes seems to be a component of gcc? >=20 > Lars It also happens to be the 10 years old piece of software that has not changed in recent history. Which means that (likely) you run out of memory, your CPU overheats or something else is wrong with your computer, or (less likely) it is being mis-compiled by clang. --=20 Alexander Kabaev --Sig_/EBRPQtoqI0G7FqT1+tW3iHI Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iD8DBQFQpZarQ6z1jMm+XZYRAk+VAJ9YC9EPDN8YES6MER9KqdxO0UvexACgnwQ9 HvkZP2HRg3j7/epSvopa3zE= =UzJN -----END PGP SIGNATURE----- --Sig_/EBRPQtoqI0G7FqT1+tW3iHI-- From owner-freebsd-current@FreeBSD.ORG Fri Nov 16 07:28:38 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 42276342; Fri, 16 Nov 2012 07:28:38 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 3B6C28FC13; Fri, 16 Nov 2012 07:28:36 +0000 (UTC) Received: from porto.starpoint.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 JAA12573; Fri, 16 Nov 2012 09:28:35 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1TZGLr-00013R-HP; Fri, 16 Nov 2012 09:28:35 +0200 Message-ID: <50A5EB23.9010407@FreeBSD.org> Date: Fri, 16 Nov 2012 09:28:35 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:16.0) Gecko/20121030 Thunderbird/16.0.2 MIME-Version: 1.0 To: Dimitry Andric , Mateusz Guzik Subject: Re: compiler info in kernel identification string References: <20121113234303.GA15319@dft-labs.eu> <50A5540D.2030707@FreeBSD.org> <50A5753D.5000001@FreeBSD.org> In-Reply-To: <50A5753D.5000001@FreeBSD.org> X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 07:28:38 -0000 on 16/11/2012 01:05 Dimitry Andric said the following: > For starters, this hardcodes the compiler names "gcc" and "clang", and > this will include incorrect information into the kernel version string, > if you use another setting for ${CC}. Oops, I agree. The script should definitely make use of $CC. Thank you for pointing this out. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Fri Nov 16 07:34:24 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8D3CD5B7; Fri, 16 Nov 2012 07:34:24 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 952608FC08; Fri, 16 Nov 2012 07:34:23 +0000 (UTC) Received: from porto.starpoint.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 JAA12667; Fri, 16 Nov 2012 09:34:21 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1TZGRQ-00013l-W0; Fri, 16 Nov 2012 09:34:21 +0200 Message-ID: <50A5EC7C.5050303@FreeBSD.org> Date: Fri, 16 Nov 2012 09:34:20 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:16.0) Gecko/20121030 Thunderbird/16.0.2 MIME-Version: 1.0 To: Dimitry Andric Subject: Re: compiler info in kernel identification string References: <20121113234303.GA15319@dft-labs.eu> <50A3639C.9050200@FreeBSD.org> <1352907497.1217.147.camel@revolution.hippie.lan> <50A57623.4020108@FreeBSD.org> In-Reply-To: <50A57623.4020108@FreeBSD.org> X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Ian Lepore , Mateusz Guzik , freebsd-current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 07:34:24 -0000 on 16/11/2012 01:09 Dimitry Andric said the following: > And as I remarked in another reply, now that I have thought about it a > bit, I would much rather see this information moved to a sysctl or dmesg > line, than in uname. With the happy side effect that no existing uname > parsers would be confused! I would still like to have at least compiler's "base name" or type or something in uname. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Fri Nov 16 09:20:45 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9D2B9DF1; Fri, 16 Nov 2012 09:20:45 +0000 (UTC) (envelope-from erik@cederstrand.dk) Received: from csmtp2.one.com (csmtp2.one.com [91.198.169.22]) by mx1.freebsd.org (Postfix) with ESMTP id 4F70E8FC12; Fri, 16 Nov 2012 09:20:44 +0000 (UTC) Received: from [192.168.187.69] (unknown [87.54.33.251]) by csmtp2.one.com (Postfix) with ESMTPA id 004CC304044E; Fri, 16 Nov 2012 09:20:42 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: compiler info in kernel identification string From: Erik Cederstrand In-Reply-To: <50A5EC7C.5050303@FreeBSD.org> Date: Fri, 16 Nov 2012 10:20:44 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <5B4DE1FD-5DD3-49A5-B8DB-6D4C03ABD742@cederstrand.dk> References: <20121113234303.GA15319@dft-labs.eu> <50A3639C.9050200@FreeBSD.org> <1352907497.1217.147.camel@revolution.hippie.lan> <50A57623.4020108@FreeBSD.org> <50A5EC7C.5050303@FreeBSD.org> To: Andriy Gapon X-Mailer: Apple Mail (2.1499) Cc: Ian Lepore , Mateusz Guzik , Dimitry Andric , freebsd-current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 09:20:45 -0000 Den 16/11/2012 kl. 08.34 skrev Andriy Gapon : > on 16/11/2012 01:09 Dimitry Andric said the following: >> And as I remarked in another reply, now that I have thought about it = a >> bit, I would much rather see this information moved to a sysctl or = dmesg >> line, than in uname. With the happy side effect that no existing = uname >> parsers would be confused! >=20 > I would still like to have at least compiler's "base name" or type or = something > in uname. This has been brought up before, but what about putting all this in a = separate file, e.g. /etc/buildinfo? At least I'd like this to be configurable. I'm trying to get FreeBSD = code in a shape where it can optionally produce deterministic binaries = from two different builds (i.e. comparable with md5) as long as the = binaries are functionally equivalent, and "irrelevant" info like = compiler version, hostname, username, timestamp, absolute path etc. are = a nuisance if they can't be turned off with -fno-ident, -frandom-seed, = -DSTRIP_FBSDID, ar -D and the like. Thanks, Erik= From owner-freebsd-current@FreeBSD.ORG Fri Nov 16 09:27:09 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CEE16F57; Fri, 16 Nov 2012 09:27:09 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id C84B28FC14; Fri, 16 Nov 2012 09:27:08 +0000 (UTC) Received: from porto.starpoint.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 LAA13757; Fri, 16 Nov 2012 11:27:05 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1TZICX-000175-8U; Fri, 16 Nov 2012 11:27:05 +0200 Message-ID: <50A606E7.5000302@FreeBSD.org> Date: Fri, 16 Nov 2012 11:27:03 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:16.0) Gecko/20121030 Thunderbird/16.0.2 MIME-Version: 1.0 To: Erik Cederstrand Subject: Re: compiler info in kernel identification string References: <20121113234303.GA15319@dft-labs.eu> <50A3639C.9050200@FreeBSD.org> <1352907497.1217.147.camel@revolution.hippie.lan> <50A57623.4020108@FreeBSD.org> <50A5EC7C.5050303@FreeBSD.org> <5B4DE1FD-5DD3-49A5-B8DB-6D4C03ABD742@cederstrand.dk> In-Reply-To: <5B4DE1FD-5DD3-49A5-B8DB-6D4C03ABD742@cederstrand.dk> X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Ian Lepore , Mateusz Guzik , Dimitry Andric , freebsd-current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 09:27:09 -0000 on 16/11/2012 11:20 Erik Cederstrand said the following: > Den 16/11/2012 kl. 08.34 skrev Andriy Gapon : > >> on 16/11/2012 01:09 Dimitry Andric said the following: >>> And as I remarked in another reply, now that I have thought about it a >>> bit, I would much rather see this information moved to a sysctl or dmesg >>> line, than in uname. With the happy side effect that no existing uname >>> parsers would be confused! >> >> I would still like to have at least compiler's "base name" or type or >> something in uname. > > This has been brought up before, but what about putting all this in a > separate file, e.g. /etc/buildinfo? There is a chance this file could be out of sync with kernel. > At least I'd like this to be configurable. I'm trying to get FreeBSD code in > a shape where it can optionally produce deterministic binaries from two This is a very good goal. I also would like to see it achieved. > different builds (i.e. comparable with md5) as long as the binaries are > functionally equivalent, and "irrelevant" info like compiler version, I agree about the following items, but not about compilers / compiler versions. Different compilers can (and do) produce different binaries already (and sometimes bugs). While, indeed, time of compilation should not affect the binaries (unless the phase of the Moon plays a role). > hostname, username, timestamp, absolute path etc. are a nuisance if they > can't be turned off with -fno-ident, -frandom-seed, -DSTRIP_FBSDID, ar -D and > the like. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Fri Nov 16 10:00:45 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 217B280E; Fri, 16 Nov 2012 10:00:45 +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 BBB538FC08; Fri, 16 Nov 2012 10:00:44 +0000 (UTC) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1TZIix-0008lm-Al; Fri, 16 Nov 2012 12:00:35 +0200 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.3 To: Andriy Gapon Subject: Re: compiler info in kernel identification string In-reply-to: <50A606E7.5000302@FreeBSD.org> References: <20121113234303.GA15319@dft-labs.eu> <50A3639C.9050200@FreeBSD.org> <1352907497.1217.147.camel@revolution.hippie.lan> <50A57623.4020108@FreeBSD.org> <50A5EC7C.5050303@FreeBSD.org> <5B4DE1FD-5DD3-49A5-B8DB-6D4C03ABD742@cederstrand.dk> <50A606E7.5000302@FreeBSD.org> Comments: In-reply-to Andriy Gapon message dated "Fri, 16 Nov 2012 11:27:03 +0200." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 16 Nov 2012 12:00:34 +0200 From: Daniel Braniss Message-ID: Cc: Ian Lepore , Mateusz Guzik , Dimitry Andric , Erik Cederstrand , freebsd-current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 10:00:45 -0000 > on 16/11/2012 11:20 Erik Cederstrand said the following: > > Den 16/11/2012 kl. 08.34 skrev Andriy Gapon : > > > >> on 16/11/2012 01:09 Dimitry Andric said the following: > >>> And as I remarked in another reply, now that I have thought about it a > >>> bit, I would much rather see this information moved to a sysctl or dmesg > >>> line, than in uname. With the happy side effect that no existing uname > >>> parsers would be confused! > >> > >> I would still like to have at least compiler's "base name" or type or > >> something in uname. > > > > This has been brought up before, but what about putting all this in a > > separate file, e.g. /etc/buildinfo? > > There is a chance this file could be out of sync with kernel. > > > At least I'd like this to be configurable. I'm trying to get FreeBSD code in > > a shape where it can optionally produce deterministic binaries from two > > This is a very good goal. I also would like to see it achieved. > > > different builds (i.e. comparable with md5) as long as the binaries are > > functionally equivalent, and "irrelevant" info like compiler version, > > I agree about the following items, but not about compilers / compiler versions. > Different compilers can (and do) produce different binaries already (and > sometimes bugs). > While, indeed, time of compilation should not affect the binaries (unless the > phase of the Moon plays a role). > > > hostname, username, timestamp, absolute path etc. are a nuisance if they > > can't be turned off with -fno-ident, -frandom-seed, -DSTRIP_FBSDID, ar -D and > > the like. > the question as to what compiler was used to compile the kernel is a bit of an oxymoron, since the kernel is made up of many different modules, which get compiled either by different compilers, or different compiler flags. since the compiler does 'sign' the modules it compiles (and clang will/should do it soon: http://llvm.org/bugs/show_bug.cgi?id=7292) some tool like file(1) could be modified to provide it, or config -x (8) ... IMHO, the only meaningfull information added to uname was the svn/git(and hopefully hg) rev. version. as usual, my 3c, danny From owner-freebsd-current@FreeBSD.ORG Fri Nov 16 10:19:01 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5608DF95; Fri, 16 Nov 2012 10:19:01 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 4DC4F8FC12; Fri, 16 Nov 2012 10:19:00 +0000 (UTC) Received: from porto.starpoint.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 MAA14363; Fri, 16 Nov 2012 12:18:35 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1TZJ0M-000196-Tv; Fri, 16 Nov 2012 12:18:34 +0200 Message-ID: <50A612F9.30509@FreeBSD.org> Date: Fri, 16 Nov 2012 12:18:33 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:16.0) Gecko/20121030 Thunderbird/16.0.2 MIME-Version: 1.0 To: Daniel Braniss Subject: Re: compiler info in kernel identification string References: <20121113234303.GA15319@dft-labs.eu> <50A3639C.9050200@FreeBSD.org> <1352907497.1217.147.camel@revolution.hippie.lan> <50A57623.4020108@FreeBSD.org> <50A5EC7C.5050303@FreeBSD.org> <5B4DE1FD-5DD3-49A5-B8DB-6D4C03ABD742@cederstrand.dk> <50A606E7.5000302@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Ian Lepore , Mateusz Guzik , Dimitry Andric , Erik Cederstrand , freebsd-current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 10:19:01 -0000 This is starting to turn into a bikeshed, but anyway... on 16/11/2012 12:00 Daniel Braniss said the following: > the question as to what compiler was used to compile the kernel is a bit of an > oxymoron, since the kernel is made up of many different modules, which get > compiled > either by different compilers, or different compiler flags. The canonical way to compile a kernel is to use buildkernel and compile modules along with the kernel. Other configurations are supported too, of course. > since the compiler does 'sign' the modules it compiles (and clang will/should > do it soon: http://llvm.org/bugs/show_bug.cgi?id=7292) some tool like > file(1) could be modified to provide it, or config -x (8) ... The key word in your note about clang is 'soon' as in 'not yet'. Besides, when I see a bug report with a dmesg *I* want to immediately know what compiler was used there. > IMHO, the only meaningfull information added to uname was the svn/git(and > hopefully hg) rev. version. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Fri Nov 16 10:43:28 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 60EA5679; Fri, 16 Nov 2012 10:43:28 +0000 (UTC) (envelope-from erik@cederstrand.dk) Received: from csmtp3.one.com (csmtp3.one.com [91.198.169.23]) by mx1.freebsd.org (Postfix) with ESMTP id E837B8FC16; Fri, 16 Nov 2012 10:43:27 +0000 (UTC) Received: from [192.168.187.69] (unknown [87.54.33.251]) by csmtp3.one.com (Postfix) with ESMTPA id 4788D2406AE7; Fri, 16 Nov 2012 10:43:21 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: compiler info in kernel identification string From: Erik Cederstrand In-Reply-To: <50A612F9.30509@FreeBSD.org> Date: Fri, 16 Nov 2012 11:43:22 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <0D736126-2E72-4C6E-BDF4-094E0C744D25@cederstrand.dk> References: <20121113234303.GA15319@dft-labs.eu> <50A3639C.9050200@FreeBSD.org> <1352907497.1217.147.camel@revolution.hippie.lan> <50A57623.4020108@FreeBSD.org> <50A5EC7C.5050303@FreeBSD.org> <5B4DE1FD-5DD3-49A5-B8DB-6D4C03ABD742@cederstrand.dk> <50A606E7.5000302@FreeBSD.org> <50A612F9.30509@FreeBSD.org> To: Andriy Gapon X-Mailer: Apple Mail (2.1499) Cc: Ian Lepore , Mateusz Guzik , Dimitry Andric , freebsd-current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 10:43:28 -0000 Den 16/11/2012 kl. 11.18 skrev Andriy Gapon : > This is starting to turn into a bikeshed, but anyway... >=20 > on 16/11/2012 12:00 Daniel Braniss said the following: >> the question as to what compiler was used to compile the kernel is a = bit of an >> oxymoron, since the kernel is made up of many different modules, = which get=20 >> compiled >> either by different compilers, or different compiler flags. >=20 > The canonical way to compile a kernel is to use buildkernel and = compile modules > along with the kernel. Other configurations are supported too, of = course. >=20 >> since the compiler does 'sign' the modules it compiles (and clang = will/should >> do it soon: http://llvm.org/bugs/show_bug.cgi?id=3D7292) some tool = like >> file(1) could be modified to provide it, or config -x (8) ... >=20 > The key word in your note about clang is 'soon' as in 'not yet'. >=20 > Besides, when I see a bug report with a dmesg *I* want to immediately = know what > compiler was used there. But wouldn't you want to know the compiler flags, too? And the kernel = config file? src.conf? Local patches? To solve a bug, in general you = would want sufficient information to recreate the environment locally. = Compiler version is not enough. So either you have all information in every binary, because they might = have been built outside a buildworld, or you have the general buildworld = / buildkernel configuration in a central place and expect users to = supply information about whatever non-standard setup they did. Erik= From owner-freebsd-current@FreeBSD.ORG Fri Nov 16 10:54:13 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 94F19856; Fri, 16 Nov 2012 10:54:13 +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 347F78FC12; Fri, 16 Nov 2012 10:54:12 +0000 (UTC) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1TZJYo-0009eF-CR; Fri, 16 Nov 2012 12:54:10 +0200 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.3 To: Andriy Gapon Subject: Re: compiler info in kernel identification string In-reply-to: <50A612F9.30509@FreeBSD.org> References: <20121113234303.GA15319@dft-labs.eu> <50A3639C.9050200@FreeBSD.org> <1352907497.1217.147.camel@revolution.hippie.lan> <50A57623.4020108@FreeBSD.org> <50A5EC7C.5050303@FreeBSD.org> <5B4DE1FD-5DD3-49A5-B8DB-6D4C03ABD742@cederstrand.dk> <50A606E7.5000302@FreeBSD.org> <50A612F9.30509@FreeBSD.org> Comments: In-reply-to Andriy Gapon message dated "Fri, 16 Nov 2012 12:18:33 +0200." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 16 Nov 2012 12:54:09 +0200 From: Daniel Braniss Message-ID: Cc: Ian Lepore , Mateusz Guzik , Dimitry Andric , Erik Cederstrand , freebsd-current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 10:54:13 -0000 > > This is starting to turn into a bikeshed, but anyway... > > on 16/11/2012 12:00 Daniel Braniss said the following: > > the question as to what compiler was used to compile the kernel is a bit of an > > oxymoron, since the kernel is made up of many different modules, which get > > compiled > > either by different compilers, or different compiler flags. > > The canonical way to compile a kernel is to use buildkernel and compile modules this does not guarantee uniformity, just look at the output it produces and you will see different compilers/assemblers/scripts/flags > along with the kernel. Other configurations are supported too, of course. > > > since the compiler does 'sign' the modules it compiles (and clang will/should > > do it soon: http://llvm.org/bugs/show_bug.cgi?id=7292) some tool like > > file(1) could be modified to provide it, or config -x (8) ... > > The key word in your note about clang is 'soon' as in 'not yet'. Dimitry wrote that he will handle it :-) > > Besides, when I see a bug report with a dmesg *I* want to immediately know what > compiler was used there. today it's clang vs. gcc -- transition time --, but again it's only part of the story, and soon it will only be noise. > > > IMHO, the only meaningfull information added to uname was the svn/git(and > > hopefully hg) rev. version. > > > -- > Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Fri Nov 16 10:57:32 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 59A2ED0C for ; Fri, 16 Nov 2012 10:57:32 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 8E3FE8FC0C for ; Fri, 16 Nov 2012 10:57:30 +0000 (UTC) Received: from porto.starpoint.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 MAA14835; Fri, 16 Nov 2012 12:57:21 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1TZJbs-0001BJ-S9; Fri, 16 Nov 2012 12:57:20 +0200 Message-ID: <50A61C0F.6090605@FreeBSD.org> Date: Fri, 16 Nov 2012 12:57:19 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:16.0) Gecko/20121030 Thunderbird/16.0.2 MIME-Version: 1.0 To: Erik Cederstrand Subject: Re: compiler info in kernel identification string References: <20121113234303.GA15319@dft-labs.eu> <50A3639C.9050200@FreeBSD.org> <1352907497.1217.147.camel@revolution.hippie.lan> <50A57623.4020108@FreeBSD.org> <50A5EC7C.5050303@FreeBSD.org> <5B4DE1FD-5DD3-49A5-B8DB-6D4C03ABD742@cederstrand.dk> <50A606E7.5000302@FreeBSD.org> <50A612F9.30509@FreeBSD.org> <0D736126-2E72-4C6E-BDF4-094E0C744D25@cederstrand.dk> In-Reply-To: <0D736126-2E72-4C6E-BDF4-094E0C744D25@cederstrand.dk> X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 10:57:32 -0000 [cc list trimmed] on 16/11/2012 12:43 Erik Cederstrand said the following: > Den 16/11/2012 kl. 11.18 skrev Andriy Gapon : > >> This is starting to turn into a bikeshed, but anyway... >> >> on 16/11/2012 12:00 Daniel Braniss said the following: >>> the question as to what compiler was used to compile the kernel is a bit >>> of an oxymoron, since the kernel is made up of many different modules, >>> which get compiled either by different compilers, or different compiler >>> flags. >> >> The canonical way to compile a kernel is to use buildkernel and compile >> modules along with the kernel. Other configurations are supported too, of >> course. >> >>> since the compiler does 'sign' the modules it compiles (and clang >>> will/should do it soon: http://llvm.org/bugs/show_bug.cgi?id=7292) some >>> tool like file(1) could be modified to provide it, or config -x (8) ... >> >> The key word in your note about clang is 'soon' as in 'not yet'. >> >> Besides, when I see a bug report with a dmesg *I* want to immediately know >> what compiler was used there. > > But wouldn't you want to know the compiler flags, too? And the kernel config > file? src.conf? Local patches? To solve a bug, in general you would want > sufficient information to recreate the environment locally. Compiler version > is not enough. It depends. OK? > So either you have all information in every binary, because they might have > been built outside a buildworld, or you have the general buildworld / > buildkernel configuration in a central place and expect users to supply > information about whatever non-standard setup they did. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Fri Nov 16 10:59:30 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D897DE35 for ; Fri, 16 Nov 2012 10:59:30 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 164758FC15 for ; Fri, 16 Nov 2012 10:59:29 +0000 (UTC) Received: from porto.starpoint.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 MAA14860; Fri, 16 Nov 2012 12:59:21 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1TZJdp-0001BM-0i; Fri, 16 Nov 2012 12:59:21 +0200 Message-ID: <50A61C88.9040203@FreeBSD.org> Date: Fri, 16 Nov 2012 12:59:20 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:16.0) Gecko/20121030 Thunderbird/16.0.2 MIME-Version: 1.0 To: Daniel Braniss Subject: Re: compiler info in kernel identification string References: <20121113234303.GA15319@dft-labs.eu> <50A3639C.9050200@FreeBSD.org> <1352907497.1217.147.camel@revolution.hippie.lan> <50A57623.4020108@FreeBSD.org> <50A5EC7C.5050303@FreeBSD.org> <5B4DE1FD-5DD3-49A5-B8DB-6D4C03ABD742@cederstrand.dk> <50A606E7.5000302@FreeBSD.org> <50A612F9.30509@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org, Erik Cederstrand X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 10:59:31 -0000 on 16/11/2012 12:54 Daniel Braniss said the following: >> >> This is starting to turn into a bikeshed, but anyway... >> >> on 16/11/2012 12:00 Daniel Braniss said the following: >>> the question as to what compiler was used to compile the kernel is a bit of an >>> oxymoron, since the kernel is made up of many different modules, which get >>> compiled >>> either by different compilers, or different compiler flags. >> >> The canonical way to compile a kernel is to use buildkernel and compile modules > > this does not guarantee uniformity, just look at the output it produces and > you will see > different compilers/assemblers/scripts/flags Different flags specified in the build infrastructure are OK. >> along with the kernel. Other configurations are supported too, of course. >> > >>> since the compiler does 'sign' the modules it compiles (and clang will/should >>> do it soon: http://llvm.org/bugs/show_bug.cgi?id=7292) some tool like >>> file(1) could be modified to provide it, or config -x (8) ... >> >> The key word in your note about clang is 'soon' as in 'not yet'. > Dimitry wrote that he will handle it :-) Right. 'will' is not 'did'. >> >> Besides, when I see a bug report with a dmesg *I* want to immediately know what >> compiler was used there. > today it's clang vs. gcc -- transition time --, but again it's only part of > the story, > and soon it will only be noise. Different kernel toolchains are here to stay. And it's not just clang vs gcc, but also different toolchains for embedded world, etc. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Fri Nov 16 12:09:05 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A085118A for ; Fri, 16 Nov 2012 12:09:05 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) by mx1.freebsd.org (Postfix) with ESMTP id 5444B8FC08 for ; Fri, 16 Nov 2012 12:09:04 +0000 (UTC) Received: from [192.168.0.6] (spaceball.home.andric.com [192.168.0.6]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id DC9E85C59; Fri, 16 Nov 2012 13:09:02 +0100 (CET) Message-ID: <50A62CE4.6080506@FreeBSD.org> Date: Fri, 16 Nov 2012 13:09:08 +0100 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "Eggert, Lars" Subject: Re: genmodes dumping core during buildworld References: <20121115202807.2fb79dd0@kan.dyndns.org> In-Reply-To: <20121115202807.2fb79dd0@kan.dyndns.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 12:09:05 -0000 On 2012-11-16 02:28, Alexander Kabaev wrote: > On Thu, 15 Nov 2012 15:02:36 +0000 > "Eggert, Lars" wrote: ... >>> Nov 15 15:56:49 server kernel: pid 83891 (genmodes), uid 0: exited >>> on signal 10 (core dumped) Nov 15 15:56:49 server kernel: pid 83893 >>> (genmodes), uid 0: exited on signal 10 (core dumped) Nov 15 >>> 15:56:49 server kernel: pid 83897 (genmodes), uid 0: exited on >>> signal 10 (core dumped) ... > It also happens to be the 10 years old piece of software that has not > changed in recent history. Which means that (likely) you run out of > memory, your CPU overheats or something else is wrong with your > computer, or (less likely) it is being mis-compiled by clang. As Alexander says, you must first rule out hardware problems. If it turns out there is nothing wrong with your hardware, I'm intrigued by the bus error you are getting. Is there any change you can get a backtrace on those crashes? And obviously, which compiler are you using, and which special CFLAGS, if any? From owner-freebsd-current@FreeBSD.ORG Fri Nov 16 10:00:42 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 430AD807; Fri, 16 Nov 2012 10:00:42 +0000 (UTC) (envelope-from kryanth@staff.gopc.net) Received: from mailmta01.gopc.net (mailmta01.gopc.net [202.81.214.147]) by mx1.freebsd.org (Postfix) with ESMTP id DB0108FC0C; Fri, 16 Nov 2012 10:00:41 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mailmta01.gopc.net (Postfix) with ESMTP id 6143DB5739; Fri, 16 Nov 2012 17:52:26 +0800 (WST) X-Virus-Scanned: amavisd-new at mailmta01.gopc.net Received: from mailmta01.gopc.net ([127.0.0.1]) by localhost (mailmta01.gopc.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id US+dSZe-asGN; Fri, 16 Nov 2012 17:52:23 +0800 (WST) Received: from mailstore02.gopc.net (mailstore02.gopc.net [202.81.214.166]) by mailmta01.gopc.net (Postfix) with ESMTP id D9959B5738; Fri, 16 Nov 2012 17:52:23 +0800 (WST) Message-ID: <7A917D2C-CACB-4CB5-B67D-736791C8FB2D@central-data.net> To: "=?utf-8?B?RXJpayBDZWRlcnN0cmFuZA==?=" , "=?utf-8?B?QW5kcml5IEdhcG9u?=" Subject: =?utf-8?B?UmU6IGNvbXBpbGVyIGluZm8gaW4ga2VybmVsIGlkZW50aWZpY2F0aW9uIHN0cmlu?= =?utf-8?B?Zw==?= Importance: Normal MIME-Version: 1.0 X-Mailer: Zimbra 6.0.16_GA_2998 (MobileSync - Android-EAS/4.5.2215323266.385208) From: Chris Hoy Poy Date: Fri, 16 Nov 2012 17:52:23 +0800 (WST) X-Mailman-Approved-At: Fri, 16 Nov 2012 12:43:50 +0000 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: =?utf-8?B?SWFuIExlcG9yZQ==?= , =?utf-8?B?TWF0ZXVzeiBHdXppaw==?= , =?utf-8?B?RGltaXRyeSBBbmRyaWM=?= , freebsd-current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 10:00:42 -0000 BeBei Sent from my HTC Velocity 4G on the Next G network ----- Reply message ----- From: "Erik Cederstrand" To: "Andriy Gapon" Cc: "Ian Lepore" , "Mateusz Guzik" , "Dimitry Andric" , Subject: compiler info in kernel identification string Date: Fri, Nov 16, 2012 5:21 pm Den 16/11/2012 kl. 08.34 skrev Andriy Gapon : > on 16/11/2012 01:09 Dimitry Andric said the following: >> And as I remarked in another reply, now that I have thought about it a >> bit, I would much rather see this information moved to a sysctl or dmesg >> line, than in uname. With the happy side effect that no existing uname >> parsers would be confused! > > I would still like to have at least compiler's "base name" or type or something > in uname. This has been brought up before, but what about putting all this in a separate file, e.g. /etc/buildinfo? At least I'd like this to be configurable. I'm trying to get FreeBSD code in a shape where it can optionally produce deterministic binaries from two different builds (i.e. comparable with md5) as long as the binaries are functionally equivalent, and "irrelevant" info like compiler version, hostname, username, timestamp, absolute path etc. are a nuisance if they can't be turned off with -fno-ident, -frandom-seed, -DSTRIP_FBSDID, ar -D and the like. Thanks, Erik _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Fri Nov 16 12:52:39 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C4FBEE2C for ; Fri, 16 Nov 2012 12:52:39 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe06.c2i.net [212.247.154.162]) by mx1.freebsd.org (Postfix) with ESMTP id 3F7118FC17 for ; Fri, 16 Nov 2012 12:52:38 +0000 (UTC) X-T2-Spam-Status: No, hits=-0.2 required=5.0 tests=ALL_TRUSTED, BAYES_50 Received: from [176.74.213.204] (account mc467741@c2i.net HELO laptop015.hselasky.homeunix.org) by mailfe06.swip.net (CommuniGate Pro SMTP 5.4.4) with ESMTPA id 344480467; Fri, 16 Nov 2012 13:52:36 +0100 From: Hans Petter Selasky To: freebsd-current@freebsd.org Subject: Re: USB keyboard problem Date: Fri, 16 Nov 2012 13:54:17 +0100 User-Agent: KMail/1.13.7 (FreeBSD/9.1-PRERELEASE; KDE/4.8.4; amd64; ; ) References: In-Reply-To: X-Face: 'mmZ:T{)),Oru^0c+/}w'`gU1$ubmG?lp!=R4Wy\ELYo2)@'UZ24N@d2+AyewRX}mAm; Yp |U[@, _z/([?1bCfM{_"B<.J>mICJCHAzzGHI{y7{%JVz%R~yJHIji`y>Y}k1C4TfysrsUI -%GU9V5]iUZF&nRn9mJ'?&>O MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201211161354.17043.hselasky@c2i.net> Cc: "Sam Fourman Jr." X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 12:52:39 -0000 On Thursday 15 November 2012 20:24:08 Sam Fourman Jr. wrote: > On Mon, Nov 12, 2012 at 2:22 PM, Sam Fourman Jr. wrote: > > hello, > > > > I believe my keyboard is being detected as a mouse by mistake using amd64 > > HEAD svn r242748 > > I can not use this keyboard, I have to plug in another one. > > > > this is also broken in FreeBSD 9.1RC3 > > > > is this simple to patch? any help is appreciated > > > > > > uhid0: on > > usbus0 uhid1: > addr 2> on usbus3 > > ums0: on > > usbus0 ums0: 3 buttons and [XYZ] coordinates ID=0 > > ums1: on usbus0 > > ums1: 7 buttons and [XYZ] coordinates ID=0 > > > > > > verbose dmesg follows > > http://www.samjess.com/keyboard.txt > > > > -- > > > > Sam Fourman Jr. > > What does "usbconfig -d X.Y dump_device_desc dump_curr_config_desc" say > about > > > your device? > > > > --HPS > > http://www.samjess.com/usbconfig.txt > Hi, > Does anyone know where I would start hacking around to fix this? I think you can try hack in /sys/dev/usb/input/ukbd.c to make it attach by having the probe return 0 on your device. Will look more at this later. --HPS From owner-freebsd-current@FreeBSD.ORG Fri Nov 16 14:49:28 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6999B2D4; Fri, 16 Nov 2012 14:49:28 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 1BBED8FC12; Fri, 16 Nov 2012 14:49:26 +0000 (UTC) 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 QAA16963; Fri, 16 Nov 2012 16:42:11 +0200 (EET) (envelope-from avg@FreeBSD.org) Message-ID: <50A650C2.7060407@FreeBSD.org> Date: Fri, 16 Nov 2012 16:42:10 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:16.0) Gecko/20121029 Thunderbird/16.0.2 MIME-Version: 1.0 To: attilio@FreeBSD.org Subject: Re: LK_SHARED/LK_DOWNGRADE adjustments to lock.9 manual page References: <50A4E8C0.5030608@FreeBSD.org> <50A552C5.5060703@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@FreeBSD.org, freebsd-current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 14:49:28 -0000 on 15/11/2012 23:44 Attilio Rao said the following: > Do you think you can test this patch?: > http://www.freebsd.org/~attilio/lockmgr_forcerec.patch I will use this patch in my tree, but I think that it is effectively already quite well tested by using INVARIANTS+WITNESS. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Fri Nov 16 15:41:13 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 679F34A1; Fri, 16 Nov 2012 15:41:13 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id 1C1808FC0C; Fri, 16 Nov 2012 15:41:13 +0000 (UTC) Received: from [192.168.0.6] (spaceball.home.andric.com [192.168.0.6]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 2B1415C59; Fri, 16 Nov 2012 16:41:12 +0100 (CET) Message-ID: <50A65E9C.4000704@FreeBSD.org> Date: Fri, 16 Nov 2012 16:41:16 +0100 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Daniel Braniss Subject: Re: compiler info in kernel identification string References: <20121113234303.GA15319@dft-labs.eu> <50A3639C.9050200@FreeBSD.org> <1352907497.1217.147.camel@revolution.hippie.lan> <50A57623.4020108@FreeBSD.org> <50A5EC7C.5050303@FreeBSD.org> <5B4DE1FD-5DD3-49A5-B8DB-6D4C03ABD742@cederstrand.dk> <50A606E7.5000302@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Ian Lepore , Mateusz Guzik , Erik Cederstrand , Andriy Gapon , freebsd-current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 15:41:13 -0000 On 2012-11-16 11:00, Daniel Braniss wrote: >> on 16/11/2012 11:20 Erik Cederstrand said the following: >>> Den 16/11/2012 kl. 08.34 skrev Andriy Gapon : ... >>> hostname, username, timestamp, absolute path etc. are a nuisance if they >>> can't be turned off with -fno-ident, -frandom-seed, -DSTRIP_FBSDID, ar -D and >>> the like. > the question as to what compiler was used to compile the kernel is a bit of an > oxymoron, since the kernel is made up of many different modules, which get > compiled > either by different compilers, or different compiler flags. Yes, but in practice this seldom happens. In Linux they also just print one compiler identification string at bootup, basically the compiler which the main Makefile used. > since the compiler does 'sign' the modules it compiles (and clang will/should > do it soon: http://llvm.org/bugs/show_bug.cgi?id=7292) some tool like > file(1) could be modified to provide it, or config -x (8) ... Well, gcc does this, and you get all the .comment sections merged into the final kernel executable, but identifying it from there is a bit messy. A simple sysctl is just handier. And regarding clang, I don't have the time to implement this very soon, and I doubt it is very high on the bug priority list with upstream either. They just branched for the 3.2 release, and they are much busier squashing bugs now. :) > IMHO, the only meaningfull information added to uname was the svn/git(and > hopefully hg) rev. version. AFAIK newvers.sh only handles svn and git. From owner-freebsd-current@FreeBSD.ORG Fri Nov 16 15:45:28 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2FC9EA0B; Fri, 16 Nov 2012 15:45:28 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 2CDE98FC1A; Fri, 16 Nov 2012 15:45:26 +0000 (UTC) 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 RAA17441; Fri, 16 Nov 2012 17:45:08 +0200 (EET) (envelope-from avg@FreeBSD.org) Message-ID: <50A65F83.5000604@FreeBSD.org> Date: Fri, 16 Nov 2012 17:45:07 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:16.0) Gecko/20121029 Thunderbird/16.0.2 MIME-Version: 1.0 To: Guido Falsi , Bartosz Stec Subject: problem booting to multi-vdev root pool [Was: kern/150503: [zfs] ZFS disks are UNAVAIL and corrupted after reboot] References: <509D1DEC.6040505@FreeBSD.org> <50A27243.408@madpilot.net> In-Reply-To: <50A27243.408@madpilot.net> X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org, freebsd-current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 15:45:28 -0000 on 13/11/2012 18:16 Guido Falsi said the following: > My idea, but is just a speculation, i could be very wrong, is that the geom > tasting code has some problem with multiple vdev root pools. Guido, you are absolutely correct. The code for reconstructing/tasting a root pool configuration is a modified upstream code, so it inherited a limitation from it: the support for only a single top-level vdev in a root pool. I have an idea how to add the missing support, but it turned out not to be something that I can hack together in couple of hours. So, instead I wrote the following patch that should fall back to using a root pool configuration from zpool.cache (if it's present there) for a multi-vdev root pool: http://people.freebsd.org/~avg/zfs-spa-multi_vdev_root_fallback.diff The patch also fixes a minor (single-time) memory leak. Guido, Bartosz, could you please test the patch? Apologies for the breakage. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Fri Nov 16 16:17:15 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5079470C; Fri, 16 Nov 2012 16:17:15 +0000 (UTC) (envelope-from mad@madpilot.net) Received: from winston.madpilot.net (winston.madpilot.net [78.47.75.155]) by mx1.freebsd.org (Postfix) with ESMTP id 010D38FC08; Fri, 16 Nov 2012 16:17:14 +0000 (UTC) Received: from winston.madpilot.net (localhost [127.0.0.1]) by winston.madpilot.net (Postfix) with ESMTP id 3Y34Mq3CB9zFTDB; Fri, 16 Nov 2012 17:17:11 +0100 (CET) X-Virus-Scanned: amavisd-new at madpilot.net Received: from winston.madpilot.net ([127.0.0.1]) by winston.madpilot.net (winston.madpilot.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Z1FnAPAi99A; Fri, 16 Nov 2012 17:17:09 +0100 (CET) Received: from vwg82.hq.ignesti.it (unknown [80.74.176.55]) by winston.madpilot.net (Postfix) with ESMTPSA; Fri, 16 Nov 2012 17:17:09 +0100 (CET) Message-ID: <50A66701.701@madpilot.net> Date: Fri, 16 Nov 2012 17:17:05 +0100 From: Guido Falsi User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:16.0) Gecko/20121114 Thunderbird/16.0.2 MIME-Version: 1.0 To: Andriy Gapon Subject: Re: problem booting to multi-vdev root pool [Was: kern/150503: [zfs] ZFS disks are UNAVAIL and corrupted after reboot] References: <509D1DEC.6040505@FreeBSD.org> <50A27243.408@madpilot.net> <50A65F83.5000604@FreeBSD.org> In-Reply-To: <50A65F83.5000604@FreeBSD.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Bartosz Stec , freebsd-fs@FreeBSD.org, freebsd-current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 16:17:15 -0000 On 11/16/12 16:45, Andriy Gapon wrote: > on 13/11/2012 18:16 Guido Falsi said the following: >> My idea, but is just a speculation, i could be very wrong, is that the geom >> tasting code has some problem with multiple vdev root pools. > > Guido, > > you are absolutely correct. The code for reconstructing/tasting a root pool > configuration is a modified upstream code, so it inherited a limitation from it: > the support for only a single top-level vdev in a root pool. > I have an idea how to add the missing support, but it turned out not to be > something that I can hack together in couple of hours. I can imagine, it does not look simple in any way! > > So, instead I wrote the following patch that should fall back to using a root pool > configuration from zpool.cache (if it's present there) for a multi-vdev root pool: > http://people.freebsd.org/~avg/zfs-spa-multi_vdev_root_fallback.diff > > The patch also fixes a minor (single-time) memory leak. > > Guido, Bartosz, > could you please test the patch? I have just compiler an r242910 kernel with this patch (and just this one) applied. System booted so it seems to work fine! :) > > Apologies for the breakage. > No worries, and thanks for this fix. Also thanks for all the work on ZFS! -- Guido Falsi From owner-freebsd-current@FreeBSD.ORG Fri Nov 16 16:29:46 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 06D93FCE; Fri, 16 Nov 2012 16:29:46 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) by mx1.freebsd.org (Postfix) with ESMTP id B58F08FC12; Fri, 16 Nov 2012 16:29:45 +0000 (UTC) Received: from dhcp107-16-154-228.hil-sdgodt.snd.wayport.net (dhcp107-16-154-228.hil-sdgodt.snd.wayport.net [107.16.154.228]) (authenticated bits=0) by theravensnest.org (8.14.5/8.14.5) with ESMTP id qAGGTGX0038338 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Fri, 16 Nov 2012 16:29:17 GMT (envelope-from theraven@FreeBSD.org) Subject: Re: compiler info in kernel identification string Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: David Chisnall In-Reply-To: <50A65E9C.4000704@FreeBSD.org> Date: Fri, 16 Nov 2012 08:29:18 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <8DB7E401-FE1C-42E6-90C9-C41B44C8C09E@FreeBSD.org> References: <20121113234303.GA15319@dft-labs.eu> <50A3639C.9050200@FreeBSD.org> <1352907497.1217.147.camel@revolution.hippie.lan> <50A57623.4020108@FreeBSD.org> <50A5EC7C.5050303@FreeBSD.org> <5B4DE1FD-5DD3-49A5-B8DB-6D4C03ABD742@cederstrand.dk> <50A606E7.5000302@FreeBSD.org> <50A65E9C.4000704@FreeBSD.org> To: Dimitry Andric X-Mailer: Apple Mail (2.1278) Cc: Ian Lepore , Mateusz Guzik , Erik Cederstrand , Andriy Gapon , freebsd-current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 16:29:46 -0000 On 16 Nov 2012, at 07:41, Dimitry Andric wrote: > And regarding clang, I don't have the time to implement this very = soon, > and I doubt it is very high on the bug priority list with upstream > either. They just branched for the 3.2 release, and they are much > busier squashing bugs now. :) Implementing this looks pretty trivial - just add a module-level inline = assembly block into the IR for each compilation unit. Most of the code = required in clang will be to provide the command-line flag for turning = it off. If we want this, I probably have time to implement it next week, and we = can pull it into the FreeBSD version of clang immediately. David= From owner-freebsd-current@FreeBSD.ORG Fri Nov 16 16:33:08 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 904302CE; Fri, 16 Nov 2012 16:33:08 +0000 (UTC) (envelope-from mad@madpilot.net) Received: from winston.madpilot.net (winston.madpilot.net [78.47.75.155]) by mx1.freebsd.org (Postfix) with ESMTP id 403D18FC16; Fri, 16 Nov 2012 16:33:08 +0000 (UTC) Received: from winston.madpilot.net (localhost [127.0.0.1]) by winston.madpilot.net (Postfix) with ESMTP id 3Y34k96mjBzFTDB; Fri, 16 Nov 2012 17:33:05 +0100 (CET) X-Virus-Scanned: amavisd-new at madpilot.net Received: from winston.madpilot.net ([127.0.0.1]) by winston.madpilot.net (winston.madpilot.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kkZxEZEpMvWe; Fri, 16 Nov 2012 17:33:01 +0100 (CET) Received: from vwg82.hq.ignesti.it (unknown [80.74.176.55]) by winston.madpilot.net (Postfix) with ESMTPSA; Fri, 16 Nov 2012 17:33:01 +0100 (CET) Message-ID: <50A66ABE.5030108@madpilot.net> Date: Fri, 16 Nov 2012 17:33:02 +0100 From: Guido Falsi User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:16.0) Gecko/20121114 Thunderbird/16.0.2 MIME-Version: 1.0 To: Niclas Zeising Subject: Re: problem booting to multi-vdev root pool [Was: kern/150503: [zfs] ZFS disks are UNAVAIL and corrupted after reboot] References: <509D1DEC.6040505@FreeBSD.org> <50A27243.408@madpilot.net> <50A65F83.5000604@FreeBSD.org> <50A66615.9060906@daemonic.se> In-Reply-To: <50A66615.9060906@daemonic.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Bartosz Stec , freebsd-fs@FreeBSD.org, freebsd-current@FreeBSD.org, Andriy Gapon X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 16:33:08 -0000 On 11/16/12 17:13, Niclas Zeising wrote: > > Just to confirm, since I am holding back an update pending on this. > If I have a raidz root pool, with three disks, like this: > NAME STATE READ WRITE CKSUM > zroot ONLINE 0 0 0 > raidz1-0 ONLINE 0 0 0 > gpt/disk0 ONLINE 0 0 0 > gpt/disk1 ONLINE 0 0 0 > gpt/disk2 ONLINE 0 0 0 > > Then I'm fine to update without issues. the problem is only if, as an > example, you have a mirror with striped disks, or a stripe with mirrored > disks, which it seems to me the original poster had. > Am I correct, and therefore ok to update? Yes, looks like that. The affected system pool looks like this: NAME STATE READ WRITE CKSUM tank ONLINE 0 0 0 mirror-0 ONLINE 0 0 0 gpt/disk0 ONLINE 0 0 0 gpt/disk1 ONLINE 0 0 0 mirror-1 ONLINE 0 0 0 ada2p2 ONLINE 0 0 0 gpt/disk3 ONLINE 0 0 0 other systems I have with simple mirror pools or single disks have shown no problems. BTW I don't know why the system insists on identifying the third disk as ada2p2, it has a gpt label defined just like the others. -- Guido Falsi From owner-freebsd-current@FreeBSD.ORG Fri Nov 16 16:43:27 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9532D4FA; Fri, 16 Nov 2012 16:43:27 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 9B3A58FC0C; Fri, 16 Nov 2012 16:43:26 +0000 (UTC) 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 SAA17725; Fri, 16 Nov 2012 18:42:50 +0200 (EET) (envelope-from avg@FreeBSD.org) Message-ID: <50A66D0A.7040208@FreeBSD.org> Date: Fri, 16 Nov 2012 18:42:50 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:16.0) Gecko/20121029 Thunderbird/16.0.2 MIME-Version: 1.0 To: Niclas Zeising Subject: Re: problem booting to multi-vdev root pool [Was: kern/150503: [zfs] ZFS disks are UNAVAIL and corrupted after reboot] References: <509D1DEC.6040505@FreeBSD.org> <50A27243.408@madpilot.net> <50A65F83.5000604@FreeBSD.org> <50A66615.9060906@daemonic.se> In-Reply-To: <50A66615.9060906@daemonic.se> X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Bartosz Stec , freebsd-fs@FreeBSD.org, freebsd-current@FreeBSD.org, Guido Falsi X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 16:43:27 -0000 on 16/11/2012 18:13 Niclas Zeising said the following: > Then I'm fine to update without issues. the problem is only if, as an example, you > have a mirror with striped disks, or a stripe with mirrored disks, which it seems > to me the original poster had. > Am I correct, and therefore ok to update? Yes. The problem occurs only if your pool has multiple vdevs _immediately_ under root. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Fri Nov 16 16:13:19 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3C93459A; Fri, 16 Nov 2012 16:13:19 +0000 (UTC) (envelope-from zeising@daemonic.se) Received: from mail.lysator.liu.se (mail.lysator.liu.se [IPv6:2001:6b0:17:f0a0::3]) by mx1.freebsd.org (Postfix) with ESMTP id 683588FC08; Fri, 16 Nov 2012 16:13:16 +0000 (UTC) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 7377340014; Fri, 16 Nov 2012 17:13:14 +0100 (CET) Received: by mail.lysator.liu.se (Postfix, from userid 1004) id 686744000C; Fri, 16 Nov 2012 17:13:14 +0100 (CET) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bernadotte.lysator.liu.se X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=AWL autolearn=disabled version=3.3.1 X-Spam-Score: 0.0 Received: from mx.daemonic.se (mx.daemonic.se [IPv6:2001:470:dca9:0:1::3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTPSA id E265F40005; Fri, 16 Nov 2012 17:13:13 +0100 (CET) Received: from mailscanner.daemonic.se (mailscanner.daemonic.se [IPv6:2001:470:dca9:0:1::6]) by mx.daemonic.se (Postfix) with ESMTPS id 3Y34HD4fsdz8hVn; Fri, 16 Nov 2012 17:13:12 +0100 (CET) X-Virus-Scanned: amavisd-new at daemonic.se Received: from mx.daemonic.se ([10.1.0.3]) (using TLS with cipher CAMELLIA256-SHA) by mailscanner.daemonic.se (mailscanner.daemonic.se [10.1.0.6]) (amavisd-new, port 10025) with ESMTPS id LWgNZDAa99L3; Fri, 16 Nov 2012 17:13:10 +0100 (CET) Received: from mail.daemonic.se (mail.daemonic.se [IPv6:2001:470:dca9:0:1::4]) by mx.daemonic.se (Postfix) with ESMTPS id 3Y34HB1ThRz8hVm; Fri, 16 Nov 2012 17:13:10 +0100 (CET) Received: from tifa.daemonic.se (tifa.daemonic.se [IPv6:2001:470:dca9:1::6]) by mail.daemonic.se (Postfix) with ESMTPSA id 3Y34H954Pnz9Ctj; Fri, 16 Nov 2012 17:13:09 +0100 (CET) Received: from tifa.daemonic.se (localhost [IPv6:::1]) by tifa.daemonic.se (Postfix) with ESMTP id 448F5228F2; Fri, 16 Nov 2012 17:13:09 +0100 (CET) Message-ID: <50A66615.9060906@daemonic.se> Date: Fri, 16 Nov 2012 17:13:09 +0100 From: Niclas Zeising User-Agent: Mutt/1.5.21 MIME-Version: 1.0 To: Andriy Gapon Subject: Re: problem booting to multi-vdev root pool [Was: kern/150503: [zfs] ZFS disks are UNAVAIL and corrupted after reboot] References: <509D1DEC.6040505@FreeBSD.org> <50A27243.408@madpilot.net> <50A65F83.5000604@FreeBSD.org> In-Reply-To: <50A65F83.5000604@FreeBSD.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Mailman-Approved-At: Fri, 16 Nov 2012 17:15:43 +0000 Cc: Bartosz Stec , freebsd-fs@FreeBSD.org, freebsd-current@FreeBSD.org, Guido Falsi X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 16:13:19 -0000 On 11/16/12 16:45, Andriy Gapon wrote: > on 13/11/2012 18:16 Guido Falsi said the following: >> My idea, but is just a speculation, i could be very wrong, is that the geom >> tasting code has some problem with multiple vdev root pools. > > Guido, > > you are absolutely correct. The code for reconstructing/tasting a root pool > configuration is a modified upstream code, so it inherited a limitation from it: > the support for only a single top-level vdev in a root pool. > I have an idea how to add the missing support, but it turned out not to be > something that I can hack together in couple of hours. > > So, instead I wrote the following patch that should fall back to using a root pool > configuration from zpool.cache (if it's present there) for a multi-vdev root pool: > http://people.freebsd.org/~avg/zfs-spa-multi_vdev_root_fallback.diff > > The patch also fixes a minor (single-time) memory leak. > > Guido, Bartosz, > could you please test the patch? > > Apologies for the breakage. > Just to confirm, since I am holding back an update pending on this. If I have a raidz root pool, with three disks, like this: NAME STATE READ WRITE CKSUM zroot ONLINE 0 0 0 raidz1-0 ONLINE 0 0 0 gpt/disk0 ONLINE 0 0 0 gpt/disk1 ONLINE 0 0 0 gpt/disk2 ONLINE 0 0 0 Then I'm fine to update without issues. the problem is only if, as an example, you have a mirror with striped disks, or a stripe with mirrored disks, which it seems to me the original poster had. Am I correct, and therefore ok to update? Regards! -- Niclas Zeising From owner-freebsd-current@FreeBSD.ORG Fri Nov 16 21:51:05 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1A4ECA23 for ; Fri, 16 Nov 2012 21:51:05 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id C0FD18FC08 for ; Fri, 16 Nov 2012 21:51:04 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1TZToQ-003JFK-Bu>; Fri, 16 Nov 2012 22:50:58 +0100 Received: from e178030020.adsl.alicedsl.de ([85.178.30.20] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1TZToQ-001q6J-8i>; Fri, 16 Nov 2012 22:50:58 +0100 Message-ID: <50A6B53D.3040605@zedat.fu-berlin.de> Date: Fri, 16 Nov 2012 22:50:53 +0100 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:16.0) Gecko/20121114 Thunderbird/16.0.2 MIME-Version: 1.0 To: Jakub Lach Subject: Re: UTF-8 console References: <1353026260160-5761407.post@n5.nabble.com> In-Reply-To: <1353026260160-5761407.post@n5.nabble.com> X-Enigmail-Version: 1.4.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigBBC0AECD23C8F7AD6710450D" X-Originating-IP: 85.178.30.20 Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 21:51:05 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigBBC0AECD23C8F7AD6710450D Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Am 11/16/12 01:37, schrieb Jakub Lach: > http://wiki.freebsd.org/SysconsUnicodeProject >=20 >=20 >=20 The WIKI mentions kernel configuration option TEKEN_XTERM, which is obviously obsolete in FreeBSD 10.0-CURRENT! --------------enigBBC0AECD23C8F7AD6710450D Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBAgAGBQJQprVCAAoJEOgBcD7A/5N8r98H/RwsqX7o15T3AKlFFAitmMOy teQ8ahkfMhGGA6Yj8xKCmdfAK/PRupfFT+FfI4uf9llg+0W0Dak+gx29OqT66Mga L6W2Gu6ddO/Sbq4z8olMa3HocWJ/ZTpN+YMjkJzFhGBlUydVtja2iC8eVt7t+yqd vAYLuo+Ua0JH7AiYWb/IwplWCFPDLSJS6IUoY1mnSETI9QqGVWpp1xXqpVoQact5 ScYShOU84q3xoLCqq01ceoJCFOYnotIUCa6LtUedGt1YxAYVEJ7WU8uKwun0CLwT qtq7DjxXa8c1Mfpd2jzGwRtI/P8tWlG5UXMBETuwEWuSxgyHQT86gyEFE9zjLoE= =2Gdw -----END PGP SIGNATURE----- --------------enigBBC0AECD23C8F7AD6710450D-- From owner-freebsd-current@FreeBSD.ORG Fri Nov 16 21:58:49 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 77AB7BE0 for ; Fri, 16 Nov 2012 21:58:49 +0000 (UTC) (envelope-from jakub_lach@mailplus.pl) Received: from sam.nabble.com (sam.nabble.com [216.139.236.26]) by mx1.freebsd.org (Postfix) with ESMTP id 532BB8FC16 for ; Fri, 16 Nov 2012 21:58:48 +0000 (UTC) Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1TZTw0-0007iE-0d for freebsd-current@freebsd.org; Fri, 16 Nov 2012 13:58:48 -0800 Date: Fri, 16 Nov 2012 13:58:48 -0800 (PST) From: Jakub Lach To: freebsd-current@freebsd.org Message-ID: <1353103128010-5761662.post@n5.nabble.com> In-Reply-To: <50A6B53D.3040605@zedat.fu-berlin.de> References: <1353026260160-5761407.post@n5.nabble.com> <50A6B53D.3040605@zedat.fu-berlin.de> Subject: Re: UTF-8 console MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 21:58:49 -0000 True, but info about state of project is correct, yes? -- View this message in context: http://freebsd.1045724.n5.nabble.com/UTF-8-console-tp5761405p5761662.html Sent from the freebsd-current mailing list archive at Nabble.com. From owner-freebsd-current@FreeBSD.ORG Sat Nov 17 00:00:37 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9E1D1CD4 for ; Sat, 17 Nov 2012 00:00:37 +0000 (UTC) (envelope-from ken@tydfam.jp) Received: from daemon.sub.tydfam.jp (ns.tydfam.jp [61.197.228.42]) by mx1.freebsd.org (Postfix) with ESMTP id 45C978FC12 for ; Sat, 17 Nov 2012 00:00:36 +0000 (UTC) Received: from localhost (tyd3.sub.tydfam.jp [192.168.1.3]) by daemon.sub.tydfam.jp (8.14.5/8.14.5) with ESMTP id qAGNw8w5007074 for ; Sat, 17 Nov 2012 08:58:09 +0900 (JST) (envelope-from ken@tydfam.jp) Date: Sat, 17 Nov 2012 08:58:08 +0900 (JST) Message-Id: <20121117.085808.525573020410572007.ken@tydfam.jp> To: freebsd-current@freebsd.org Subject: Q) KLDload error From: ken X-Mailer: Mew version 6.5 on Emacs 24.2 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.2 required=5.0 tests=ALL_TRUSTED,RP_MATCHES_RCVD autolearn=unavailable version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on daemon.sub.tydfam.jp X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Nov 2012 00:00:37 -0000 I have the following error at booting with current kernel. Were there any changes? Any fixed? I need to run virtualbox. Nov 17 08:32:34 t3 kernel: FreeBSD 10.0-CURRENT #12 r243164M: Sat Nov 17 08:24:30 JST 2012 Nov 17 08:32:34 t3 kernel: ken@tyd3.sub.tydfam.jp:/usr/obj/usr/head/sys/TYD3 amd64 Nov 17 08:32:34 t3 kernel: link_elf_obj: symbol vm_page_lock_queues undefined Nov 17 08:32:34 t3 kernel: KLD file vboxdrv.ko - could not finalize loading Nov 17 08:32:34 t3 kernel: CPU: Intel(R) Core(TM) i7-3960X CPU @ 3.30GHz (3309.94-MHz K8-class CPU) Nov 17 08:32:34 t3 kernel: Origin = "GenuineIntel" Id = 0x206d7 Family = 0x6 Model = 0x2d Stepping = 7 Nov 17 08:32:34 t3 kernel: Features=0xbfebfbff Nov 17 08:32:34 t3 kernel: Features2=0x1fbee3bf Nov 17 08:32:34 t3 kernel: AMD Features=0x2c100800 Nov 17 08:32:34 t3 kernel: AMD Features2=0x1 From owner-freebsd-current@FreeBSD.ORG Sat Nov 17 00:38:31 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6AB2342A for ; Sat, 17 Nov 2012 00:38:31 +0000 (UTC) (envelope-from prvs=16689e66a1=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id ED6448FC12 for ; Sat, 17 Nov 2012 00:38:30 +0000 (UTC) Received: from r2d2 ([188.220.16.49]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50001084405.msg for ; Sat, 17 Nov 2012 00:38:29 +0000 X-Spam-Processed: mail1.multiplay.co.uk, Sat, 17 Nov 2012 00:38:29 +0000 (not processed: message from valid local sender) X-MDRemoteIP: 188.220.16.49 X-Return-Path: prvs=16689e66a1=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-current@freebsd.org Message-ID: <8651A05687AA4519B13E6D03F5F1DF14@multiplay.co.uk> From: "Steven Hartland" To: , "ken" References: <20121117.085808.525573020410572007.ken@tydfam.jp> Subject: Re: Q) KLDload error Date: Sat, 17 Nov 2012 00:34:28 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Nov 2012 00:38:31 -0000 sounds like your kernel and world may be out of sync? ----- Original Message ----- From: "ken" To: Sent: Friday, November 16, 2012 11:58 PM Subject: Q) KLDload error > > I have the following error at booting with current kernel. Were there any changes? Any fixed? I need to run virtualbox. > > Nov 17 08:32:34 t3 kernel: FreeBSD 10.0-CURRENT #12 r243164M: Sat Nov 17 08:24:30 JST 2012 > Nov 17 08:32:34 t3 kernel: ken@tyd3.sub.tydfam.jp:/usr/obj/usr/head/sys/TYD3 amd64 > Nov 17 08:32:34 t3 kernel: link_elf_obj: symbol vm_page_lock_queues undefined > Nov 17 08:32:34 t3 kernel: KLD file vboxdrv.ko - could not finalize loading > Nov 17 08:32:34 t3 kernel: CPU: Intel(R) Core(TM) i7-3960X CPU @ 3.30GHz (3309.94-MHz K8-class CPU) > Nov 17 08:32:34 t3 kernel: Origin = "GenuineIntel" Id = 0x206d7 Family = 0x6 Model = 0x2d Stepping = 7 > Nov 17 08:32:34 t3 kernel: > Features=0xbfebfbff > Nov 17 08:32:34 t3 kernel: > Features2=0x1fbee3bf > Nov 17 08:32:34 t3 kernel: AMD Features=0x2c100800 > Nov 17 08:32:34 t3 kernel: AMD Features2=0x1 > > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-current@FreeBSD.ORG Sat Nov 17 01:09:28 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 12827886 for ; Sat, 17 Nov 2012 01:09:28 +0000 (UTC) (envelope-from ken@tydfam.jp) Received: from daemon.sub.tydfam.jp (ns.tydfam.jp [61.197.228.42]) by mx1.freebsd.org (Postfix) with ESMTP id 903A08FC0C for ; Sat, 17 Nov 2012 01:09:26 +0000 (UTC) Received: from localhost (tyd3.sub.tydfam.jp [192.168.1.3]) by daemon.sub.tydfam.jp (8.14.5/8.14.5) with ESMTP id qAH19MRd007419; Sat, 17 Nov 2012 10:09:22 +0900 (JST) (envelope-from ken@tydfam.jp) Date: Sat, 17 Nov 2012 10:09:22 +0900 (JST) Message-Id: <20121117.100922.100804076979099476.ken@tydfam.jp> To: killing@multiplay.co.uk Subject: Re: Q) KLDload error From: ken In-Reply-To: <8651A05687AA4519B13E6D03F5F1DF14@multiplay.co.uk> References: <20121117.085808.525573020410572007.ken@tydfam.jp> <8651A05687AA4519B13E6D03F5F1DF14@multiplay.co.uk> X-Mailer: Mew version 6.5 on Emacs 24.2 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.2 required=5.0 tests=ALL_TRUSTED,RP_MATCHES_RCVD autolearn=unavailable version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on daemon.sub.tydfam.jp Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Nov 2012 01:09:28 -0000 From: "Steven Hartland" > sounds like your kernel and world may be out of sync? No, I always DO "make buildworld && make installworld && make buildkernel && make installkernel". And I do not think they are not sync'd. From owner-freebsd-current@FreeBSD.ORG Sat Nov 17 01:14:22 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1022CB69 for ; Sat, 17 Nov 2012 01:14:22 +0000 (UTC) (envelope-from Lucas.James@LDJcs.Com.Au) Received: from mail.ldjcs.com.au (2001-44b8-419a-7700-0000-0000-0000-0004.static.ipv6.internode.on.net [IPv6:2001:44b8:419a:7700::4]) by mx1.freebsd.org (Postfix) with ESMTP id 2C2248FC08 for ; Sat, 17 Nov 2012 01:14:20 +0000 (UTC) Received: from [IPv6:2001:44b8:419a:7700:987d:808b:a35a:4e54] ([IPv6:2001:44b8:419a:7700:987d:808b:a35a:4e54]) (authenticated bits=0) by mail.ldjcs.com.au (8.14.4/8.14.4) with ESMTP id qAH1EEUF029586; Sat, 17 Nov 2012 12:14:14 +1100 (EST) (envelope-from Lucas.James@LDJcs.Com.Au) Message-ID: <50A6E51F.5030705@LDJcs.Com.Au> Date: Sat, 17 Nov 2012 12:15:11 +1100 From: Lucas James User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: ken Subject: Re: Q) KLDload error References: <20121117.085808.525573020410572007.ken@tydfam.jp> In-Reply-To: <20121117.085808.525573020410572007.ken@tydfam.jp> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (mail.ldjcs.com.au [IPv6:2001:44b8:419a:7700::4]); Sat, 17 Nov 2012 12:14:14 +1100 (EST) X-Spam-Status: No, score=-1.1 required=5.0 tests=BAYES_00,RDNS_NONE autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on mail.ldjcs.com.au Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Lucas.James@LDJcs.Com.Au List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Nov 2012 01:14:22 -0000 On 17/11/2012 10:58 AM, ken wrote: > > I have the following error at booting with current kernel. Were there any changes? Any fixed? I need to run virtualbox. > > Nov 17 08:32:34 t3 kernel: FreeBSD 10.0-CURRENT #12 r243164M: Sat Nov 17 08:24:30 JST 2012 > Nov 17 08:32:34 t3 kernel: ken@tyd3.sub.tydfam.jp:/usr/obj/usr/head/sys/TYD3 amd64 > Nov 17 08:32:34 t3 kernel: link_elf_obj: symbol vm_page_lock_queues undefined > Nov 17 08:32:34 t3 kernel: KLD file vboxdrv.ko - could not finalize loading > You will need to rebuild and install the virtualbox-ose-kmod port. regards, Lucas -- I was going to include a witty saying, but I couldn't think of one. From owner-freebsd-current@FreeBSD.ORG Sat Nov 17 02:04:11 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AE41A4E7 for ; Sat, 17 Nov 2012 02:04:11 +0000 (UTC) (envelope-from ken@tydfam.jp) Received: from daemon.sub.tydfam.jp (ns.tydfam.jp [61.197.228.42]) by mx1.freebsd.org (Postfix) with ESMTP id 4F06C8FC13 for ; Sat, 17 Nov 2012 02:04:10 +0000 (UTC) Received: from localhost (tyd3.sub.tydfam.jp [192.168.1.3]) by daemon.sub.tydfam.jp (8.14.5/8.14.5) with ESMTP id qAH2454n007736; Sat, 17 Nov 2012 11:04:06 +0900 (JST) (envelope-from ken@tydfam.jp) Date: Sat, 17 Nov 2012 11:04:05 +0900 (JST) Message-Id: <20121117.110405.806577941401349924.ken@tydfam.jp> To: Lucas.James@LDJcs.Com.Au Subject: Re: Q) KLDload error From: ken In-Reply-To: <50A6E51F.5030705@LDJcs.Com.Au> References: <20121117.085808.525573020410572007.ken@tydfam.jp> <50A6E51F.5030705@LDJcs.Com.Au> X-Mailer: Mew version 6.5 on Emacs 24.2 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.2 required=5.0 tests=ALL_TRUSTED,RP_MATCHES_RCVD autolearn=unavailable version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on daemon.sub.tydfam.jp Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Nov 2012 02:04:11 -0000 From: Lucas James > > You will need to rebuild and install the virtualbox-ose-kmod port. > > > regards, > Lucas Yes, I did and yet I have the following error with "kldload vboxdrv". Is "vm_page_lock_queues" renamed? It is in "./work/VirtualBox-4.1.22/src/VBox/Runtime/r0drv/freebsd/memobj-r0drv-freebsd.c" # tail -f /var/log/messages : : : Nov 17 10:53:17 t3 pkg: virtualbox-ose-kmod-4.1.22 installed Nov 17 10:53:55 t3 kernel: link_elf_obj: symbol vm_page_lock_queues undefined Nov 17 10:53:55 t3 kernel: linker_load_file: Unsupported file type : : : From owner-freebsd-current@FreeBSD.ORG Sat Nov 17 02:15:34 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E096B852 for ; Sat, 17 Nov 2012 02:15:34 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id D228F8FC12 for ; Sat, 17 Nov 2012 02:15:15 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.5/8.14.5) with ESMTP id qAH2F8IZ094923 for ; Fri, 16 Nov 2012 19:15:09 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id qAH2F4o7026803; Fri, 16 Nov 2012 19:15:05 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Subject: Re: Q) KLDload error From: Ian Lepore To: ken In-Reply-To: <20121117.110405.806577941401349924.ken@tydfam.jp> References: <20121117.085808.525573020410572007.ken@tydfam.jp> <50A6E51F.5030705@LDJcs.Com.Au> <20121117.110405.806577941401349924.ken@tydfam.jp> Content-Type: text/plain; charset="us-ascii" Date: Fri, 16 Nov 2012 19:15:04 -0700 Message-ID: <1353118504.1217.301.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: Lucas.James@LDJcs.Com.Au, freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Nov 2012 02:15:35 -0000 On Sat, 2012-11-17 at 11:04 +0900, ken wrote: > From: Lucas James > > > > You will need to rebuild and install the virtualbox-ose-kmod port. > > > > > > regards, > > Lucas > > Yes, I did and yet I have the following error with "kldload vboxdrv". > > Is "vm_page_lock_queues" renamed? It is in "./work/VirtualBox-4.1.22/src/VBox/Runtime/r0drv/freebsd/memobj-r0drv-freebsd.c" > > # tail -f /var/log/messages > : : : > Nov 17 10:53:17 t3 pkg: virtualbox-ose-kmod-4.1.22 installed > Nov 17 10:53:55 t3 kernel: link_elf_obj: symbol vm_page_lock_queues undefined > Nov 17 10:53:55 t3 kernel: linker_load_file: Unsupported file type > : : : It's not renamed, it's gone in favor of per-queue locks. See r242941. -- Ian From owner-freebsd-current@FreeBSD.ORG Sat Nov 17 02:18:27 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 421349FF; Sat, 17 Nov 2012 02:18:27 +0000 (UTC) (envelope-from Lucas.James@LDJcs.Com.Au) Received: from mail.ldjcs.com.au (2001-44b8-419a-7700-0000-0000-0000-0004.static.ipv6.internode.on.net [IPv6:2001:44b8:419a:7700::4]) by mx1.freebsd.org (Postfix) with ESMTP id 9ABB88FC08; Sat, 17 Nov 2012 02:18:26 +0000 (UTC) Received: from [IPv6:2001:44b8:419a:7700:987d:808b:a35a:4e54] ([IPv6:2001:44b8:419a:7700:987d:808b:a35a:4e54]) (authenticated bits=0) by mail.ldjcs.com.au (8.14.4/8.14.4) with ESMTP id qAH2IKkM067042; Sat, 17 Nov 2012 13:18:20 +1100 (EST) (envelope-from Lucas.James@LDJcs.Com.Au) Message-ID: <50A6F421.2000504@LDJcs.Com.Au> Date: Sat, 17 Nov 2012 13:19:14 +1100 From: Lucas James User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: ken Subject: Re: Q) KLDload error References: <20121117.085808.525573020410572007.ken@tydfam.jp> <50A6E51F.5030705@LDJcs.Com.Au> <20121117.110405.806577941401349924.ken@tydfam.jp> In-Reply-To: <20121117.110405.806577941401349924.ken@tydfam.jp> X-Enigmail-Version: 1.4.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigA0672B05B5DDEF8CE828A004" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (mail.ldjcs.com.au [IPv6:2001:44b8:419a:7700::4]); Sat, 17 Nov 2012 13:18:20 +1100 (EST) X-Spam-Status: No, score=-1.1 required=5.0 tests=BAYES_00,RDNS_NONE autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on mail.ldjcs.com.au Cc: alc@freebsd.org, freebsd-current@freebsd.org, vbox@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Lucas.James@LDJcs.Com.Au List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Nov 2012 02:18:27 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigA0672B05B5DDEF8CE828A004 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 17/11/2012 1:04 PM, ken wrote: > Lucas > Yes, I did and yet I have the following error with "kldload vboxdrv".= > > Is "vm_page_lock_queues" renamed? It is in "./work/VirtualBox-4.1.22/s= rc/VBox/Runtime/r0drv/freebsd/memobj-r0drv-freebsd.c" > > # tail -f /var/log/messages=20 > : : : > Nov 17 10:53:17 t3 pkg: virtualbox-ose-kmod-4.1.22 installed > Nov 17 10:53:55 t3 kernel: link_elf_obj: symbol vm_page_lock_queues und= efined > Nov 17 10:53:55 t3 kernel: linker_load_file: Unsupported file type > : : : > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.o= rg" Ahh, I see. After little more digging it would appear that alc@ removed vm_page_lock_queues in r242941, as he replaced them with multiple queues. Unfortunately this means VirtualBox will not be able to be run. I suggest submitting a PR. regards, Lucas --=20 I was going to include a witty saying, but I couldn't think of one. --------------enigA0672B05B5DDEF8CE828A004 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.9 (MingW32) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlCm9CUACgkQS5LuBv475s8kBQCgqbm3YjeSkYZh0wJgFTFwiOCN R3kAmgJAtlX97+h5jNvkn0wTkfL9zNCs =iP/E -----END PGP SIGNATURE----- --------------enigA0672B05B5DDEF8CE828A004-- From owner-freebsd-current@FreeBSD.ORG Sat Nov 17 02:24:29 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EA617B47 for ; Sat, 17 Nov 2012 02:24:29 +0000 (UTC) (envelope-from andy@neu.net) Received: from mail.neu.net (unknown [IPv6:2607:fc50:0:d300:216:3eff:fe54:f1c6]) by mx1.freebsd.org (Postfix) with ESMTP id A9E8C8FC08 for ; Sat, 17 Nov 2012 02:24:29 +0000 (UTC) Received: from neu.net (neu.net [199.48.129.194]) by mail.neu.net (8.14.5/8.14.5) with ESMTP id qAH2OQTF074130 for ; Fri, 16 Nov 2012 21:24:26 -0500 (EST) (envelope-from andy@neu.net) Date: Fri, 16 Nov 2012 21:24:26 -0500 (EST) From: AN To: freebsd-current@FreeBSD.org Subject: link_elf_obj: symbol vm_page_lock_queues undefined Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Virus-Scanned: clamav-milter 0.97.6 at my.mail.server X-Virus-Status: Clean X-Spam-Status: No, score=0.0 required=4.5 tests=RP_MATCHES_RCVD autolearn=unavailable version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on mail.neu.net X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Nov 2012 02:24:30 -0000 FreeBSD FBSD10 10.0-CURRENT FreeBSD 10.0-CURRENT #38 r243165: Fri Nov 16 20:53:48 EST 2012 root@FBSD10:/usr/obj/usr/src/sys/MYKERNEL amd64 Vbox is broken for me after recent upgrade. # dmesg Table 'FACP' at 0xc7fb0290 Table 'APIC' at 0xc7fb0390 APIC: Found table at 0xc7fb0390 APIC: Using the MADT enumerator. MADT: Found CPU APIC ID 0 ACPI ID 1: enabled SMP: Added CPU 0 (AP) MADT: Found CPU APIC ID 1 ACPI ID 2: enabled SMP: Added CPU 1 (AP) MADT: Found CPU APIC ID 2 ACPI ID 3: enabled SMP: Added CPU 2 (AP) MADT: Found CPU APIC ID 3 ACPI ID 4: enabled SMP: Added CPU 3 (AP) MADT: Found CPU APIC ID 132 ACPI ID 5: disabled MADT: Found CPU APIC ID 133 ACPI ID 6: disabled Copyright (c) 1992-2012 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 10.0-CURRENT #38 r243165: Fri Nov 16 20:53:48 EST 2012 root@FBSD10:/usr/obj/usr/src/sys/MYKERNEL amd64 Preloaded elf kernel "/boot/kernel/kernel" at 0xffffffff81e8b000. Preloaded elf obj module "/boot/kernel/amdtemp.ko" at 0xffffffff81e8b200. Preloaded elf obj module "/boot/modules/nvidia.ko" at 0xffffffff81e8b768. Preloaded elf obj module "/boot/kernel/linux.ko" at 0xffffffff81e8bd90. Preloaded elf obj module "/boot/modules/vboxdrv.ko" at 0xffffffff81e8c538. link_elf_obj: symbol vm_page_lock_queues undefined KLD file vboxdrv.ko - could not finalize loading Calibrating TSC clock ... TSC clock: 3100083911 Hz CPU: AMD Athlon(tm) II X4 645 Processor (3100.08-MHz K8-class CPU) Origin = "AuthenticAMD" Id = 0x100f53 Family = 0x10 Model = 0x5 Stepping = 3 Features=0x178bfbff Features2=0x802009 AMD Features=0xee500800 AMD Features2=0x37ff I rebuilt and reinstalled: ===> Installing for virtualbox-ose-kmod-4.1.22 ===> Registering installation for virtualbox-ose-kmod-4.1.22 # kldload vboxdrv.ko kldload: can't load vboxdrv.ko: Exec format error Log file: ov 16 21:16:40 FBSD10 kernel: link_elf_obj: symbol vm_page_lock_queues undefined Nov 16 21:16:40 FBSD10 kernel: linker_load_file: Unsupported file type Any help is appreciated, thanks in advance. From owner-freebsd-current@FreeBSD.ORG Sat Nov 17 02:38:06 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DCD63E20; Sat, 17 Nov 2012 02:38:06 +0000 (UTC) (envelope-from ken@tydfam.jp) Received: from daemon.sub.tydfam.jp (ns.tydfam.jp [61.197.228.42]) by mx1.freebsd.org (Postfix) with ESMTP id 802A38FC14; Sat, 17 Nov 2012 02:38:05 +0000 (UTC) Received: from localhost (tyd3.sub.tydfam.jp [192.168.1.3]) by daemon.sub.tydfam.jp (8.14.5/8.14.5) with ESMTP id qAH2c1CO007903; Sat, 17 Nov 2012 11:38:01 +0900 (JST) (envelope-from ken@tydfam.jp) Date: Sat, 17 Nov 2012 11:38:01 +0900 (JST) Message-Id: <20121117.113801.1164559475529499280.ken@tydfam.jp> To: Lucas.James@LDJcs.Com.Au Subject: Re: Q) KLDload error From: ken In-Reply-To: <50A6F421.2000504@LDJcs.Com.Au> References: <50A6E51F.5030705@LDJcs.Com.Au> <20121117.110405.806577941401349924.ken@tydfam.jp> <50A6F421.2000504@LDJcs.Com.Au> X-Mailer: Mew version 6.5 on Emacs 24.2 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.2 required=5.0 tests=ALL_TRUSTED,RP_MATCHES_RCVD autolearn=unavailable version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on daemon.sub.tydfam.jp Cc: alc@freebsd.org, freebsd-current@freebsd.org, vbox@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Nov 2012 02:38:07 -0000 Gee,,, It sounds not so easy as multiple queues indicates, but I hope that it is fixed soon... From: Lucas James > > Ahh, I see. After little more digging it would appear that alc@ removed > vm_page_lock_queues in r242941, as he replaced them with multiple > queues. Unfortunately this means VirtualBox will not be able to be run. > > I suggest submitting a PR. > > regards, > Lucas From owner-freebsd-current@FreeBSD.ORG Sat Nov 17 02:54:09 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CF2694A7; Sat, 17 Nov 2012 02:54:09 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-oa0-f54.google.com (mail-oa0-f54.google.com [209.85.219.54]) by mx1.freebsd.org (Postfix) with ESMTP id 773488FC08; Sat, 17 Nov 2012 02:54:09 +0000 (UTC) Received: by mail-oa0-f54.google.com with SMTP id n9so4308446oag.13 for ; Fri, 16 Nov 2012 18:54:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=vW+N4LqxeCPo6mU85XLi2pFiL/TycNjfw2cW5NQi3E8=; b=No0cCUkS6zxnWeN+1zL+ors+IDnyWnmecK8eelkri7WaufLbP9VGCQ1WMQgJKZ/xng kvHG1vUoNle21DML5ItnXgdSl5ilobEyljamO6/CVLzN/e/pNM/PaMTkGscYHWX9CGKs W8OBho4bx90BHiXtvAu12KenbT7ad0/KqYJHzelyKkDxlqKfF0sLspM7hwyTND5GKkTl 8kqIEpainKMymWWx+x7f5pV+H1d29rnctOeiE1fEL7XNBS7UAVFRlBSi2fjgPc1vESfs XCzJkGih2m+FWT+aohI6aYmzBbG7aAA8YZTEiPf2Y0K/2MjnhPSrD+Q2RVVy9XWIiO+l 4Q2A== MIME-Version: 1.0 Received: by 10.182.131.100 with SMTP id ol4mr5536688obb.38.1353120848526; Fri, 16 Nov 2012 18:54:08 -0800 (PST) Received: by 10.76.143.33 with HTTP; Fri, 16 Nov 2012 18:54:08 -0800 (PST) In-Reply-To: References: Date: Fri, 16 Nov 2012 18:54:08 -0800 Message-ID: Subject: Re: link_elf_obj: symbol vm_page_lock_queues undefined From: Garrett Cooper To: AN Content-Type: text/plain; charset=ISO-8859-1 Cc: alc@freebsd.org, freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Nov 2012 02:54:10 -0000 On Fri, Nov 16, 2012 at 6:24 PM, AN wrote: > FreeBSD FBSD10 10.0-CURRENT FreeBSD 10.0-CURRENT #38 r243165: Fri Nov 16 > 20:53:48 EST 2012 root@FBSD10:/usr/obj/usr/src/sys/MYKERNEL amd64 > > Vbox is broken for me after recent upgrade. > > # dmesg > Table 'FACP' at 0xc7fb0290 > Table 'APIC' at 0xc7fb0390 > APIC: Found table at 0xc7fb0390 > APIC: Using the MADT enumerator. > MADT: Found CPU APIC ID 0 ACPI ID 1: enabled > SMP: Added CPU 0 (AP) > MADT: Found CPU APIC ID 1 ACPI ID 2: enabled > SMP: Added CPU 1 (AP) > MADT: Found CPU APIC ID 2 ACPI ID 3: enabled > SMP: Added CPU 2 (AP) > MADT: Found CPU APIC ID 3 ACPI ID 4: enabled > SMP: Added CPU 3 (AP) > MADT: Found CPU APIC ID 132 ACPI ID 5: disabled > MADT: Found CPU APIC ID 133 ACPI ID 6: disabled > Copyright (c) 1992-2012 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 10.0-CURRENT #38 r243165: Fri Nov 16 20:53:48 EST 2012 > root@FBSD10:/usr/obj/usr/src/sys/MYKERNEL amd64 > Preloaded elf kernel "/boot/kernel/kernel" at 0xffffffff81e8b000. > Preloaded elf obj module "/boot/kernel/amdtemp.ko" at 0xffffffff81e8b200. > Preloaded elf obj module "/boot/modules/nvidia.ko" at 0xffffffff81e8b768. > Preloaded elf obj module "/boot/kernel/linux.ko" at 0xffffffff81e8bd90. > Preloaded elf obj module "/boot/modules/vboxdrv.ko" at 0xffffffff81e8c538. > link_elf_obj: symbol vm_page_lock_queues undefined > KLD file vboxdrv.ko - could not finalize loading > Calibrating TSC clock ... TSC clock: 3100083911 Hz > CPU: AMD Athlon(tm) II X4 645 Processor (3100.08-MHz K8-class CPU) > Origin = "AuthenticAMD" Id = 0x100f53 Family = 0x10 Model = 0x5 > Stepping = 3 > > Features=0x178bfbff > Features2=0x802009 > AMD > Features=0xee500800 > AMD > Features2=0x37ff > > > I rebuilt and reinstalled: > ===> Installing for virtualbox-ose-kmod-4.1.22 > ===> Registering installation for virtualbox-ose-kmod-4.1.22 > > # kldload vboxdrv.ko > kldload: can't load vboxdrv.ko: Exec format error > > Log file: > ov 16 21:16:40 FBSD10 kernel: link_elf_obj: symbol vm_page_lock_queues > undefined > Nov 16 21:16:40 FBSD10 kernel: linker_load_file: Unsupported file type > > Any help is appreciated, thanks in advance. r242941 broke virtualbox. alc@ CCed. Thanks, -Garrett From owner-freebsd-current@FreeBSD.ORG Sat Nov 17 03:15:01 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C829A966; Sat, 17 Nov 2012 03:15:01 +0000 (UTC) (envelope-from alc@rice.edu) Received: from mh10.mail.rice.edu (mh10.mail.rice.edu [128.42.201.30]) by mx1.freebsd.org (Postfix) with ESMTP id 8D6E88FC08; Sat, 17 Nov 2012 03:15:01 +0000 (UTC) Received: from mh10.mail.rice.edu (localhost.localdomain [127.0.0.1]) by mh10.mail.rice.edu (Postfix) with ESMTP id 79FED603DC; Fri, 16 Nov 2012 21:14:55 -0600 (CST) Received: from mh10.mail.rice.edu (localhost.localdomain [127.0.0.1]) by mh10.mail.rice.edu (Postfix) with ESMTP id 78739603DB; Fri, 16 Nov 2012 21:14:55 -0600 (CST) X-Virus-Scanned: by amavis-2.7.0 at mh10.mail.rice.edu, auth channel Received: from mh10.mail.rice.edu ([127.0.0.1]) by mh10.mail.rice.edu (mh10.mail.rice.edu [127.0.0.1]) (amavis, port 10026) with ESMTP id IDkRTBSxqNB4; Fri, 16 Nov 2012 21:14:55 -0600 (CST) Received: from adsl-216-63-78-18.dsl.hstntx.swbell.net (adsl-216-63-78-18.dsl.hstntx.swbell.net [216.63.78.18]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: alc) by mh10.mail.rice.edu (Postfix) with ESMTPSA id F0730603D3; Fri, 16 Nov 2012 21:14:54 -0600 (CST) Message-ID: <50A7012E.9060908@rice.edu> Date: Fri, 16 Nov 2012 21:14:54 -0600 From: Alan Cox User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:16.0) Gecko/20121111 Thunderbird/16.0.2 MIME-Version: 1.0 To: Garrett Cooper Subject: Re: link_elf_obj: symbol vm_page_lock_queues undefined References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: alc@freebsd.org, AN , freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Nov 2012 03:15:01 -0000 On 11/16/2012 20:54, Garrett Cooper wrote: > On Fri, Nov 16, 2012 at 6:24 PM, AN wrote: >> FreeBSD FBSD10 10.0-CURRENT FreeBSD 10.0-CURRENT #38 r243165: Fri Nov 16 >> 20:53:48 EST 2012 root@FBSD10:/usr/obj/usr/src/sys/MYKERNEL amd64 >> >> Vbox is broken for me after recent upgrade. >> >> # dmesg >> Table 'FACP' at 0xc7fb0290 >> Table 'APIC' at 0xc7fb0390 >> APIC: Found table at 0xc7fb0390 >> APIC: Using the MADT enumerator. >> MADT: Found CPU APIC ID 0 ACPI ID 1: enabled >> SMP: Added CPU 0 (AP) >> MADT: Found CPU APIC ID 1 ACPI ID 2: enabled >> SMP: Added CPU 1 (AP) >> MADT: Found CPU APIC ID 2 ACPI ID 3: enabled >> SMP: Added CPU 2 (AP) >> MADT: Found CPU APIC ID 3 ACPI ID 4: enabled >> SMP: Added CPU 3 (AP) >> MADT: Found CPU APIC ID 132 ACPI ID 5: disabled >> MADT: Found CPU APIC ID 133 ACPI ID 6: disabled >> Copyright (c) 1992-2012 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 10.0-CURRENT #38 r243165: Fri Nov 16 20:53:48 EST 2012 >> root@FBSD10:/usr/obj/usr/src/sys/MYKERNEL amd64 >> Preloaded elf kernel "/boot/kernel/kernel" at 0xffffffff81e8b000. >> Preloaded elf obj module "/boot/kernel/amdtemp.ko" at 0xffffffff81e8b200. >> Preloaded elf obj module "/boot/modules/nvidia.ko" at 0xffffffff81e8b768. >> Preloaded elf obj module "/boot/kernel/linux.ko" at 0xffffffff81e8bd90. >> Preloaded elf obj module "/boot/modules/vboxdrv.ko" at 0xffffffff81e8c538. >> link_elf_obj: symbol vm_page_lock_queues undefined >> KLD file vboxdrv.ko - could not finalize loading >> Calibrating TSC clock ... TSC clock: 3100083911 Hz >> CPU: AMD Athlon(tm) II X4 645 Processor (3100.08-MHz K8-class CPU) >> Origin = "AuthenticAMD" Id = 0x100f53 Family = 0x10 Model = 0x5 >> Stepping = 3 >> >> Features=0x178bfbff >> Features2=0x802009 >> AMD >> Features=0xee500800 >> AMD >> Features2=0x37ff >> >> >> I rebuilt and reinstalled: >> ===> Installing for virtualbox-ose-kmod-4.1.22 >> ===> Registering installation for virtualbox-ose-kmod-4.1.22 >> >> # kldload vboxdrv.ko >> kldload: can't load vboxdrv.ko: Exec format error >> >> Log file: >> ov 16 21:16:40 FBSD10 kernel: link_elf_obj: symbol vm_page_lock_queues >> undefined >> Nov 16 21:16:40 FBSD10 kernel: linker_load_file: Unsupported file type >> >> Any help is appreciated, thanks in advance. > r242941 broke virtualbox. alc@ CCed. > Thanks, > -Garrett > I just glanced at the virtualbox code for a couple minutes. For FreeBSD 9 and 10, these lock acquires are completely unnecessary, and have been since FreeBSD 9.0. Just delete them. They may be equally unnecessary under FreeBSD 8, but I didn't look carefully enough to answer that question. Alan From owner-freebsd-current@FreeBSD.ORG Sat Nov 17 04:02:15 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4610E1B7; Sat, 17 Nov 2012 04:02:15 +0000 (UTC) (envelope-from ken@tydfam.jp) Received: from daemon.sub.tydfam.jp (ns.tydfam.jp [61.197.228.42]) by mx1.freebsd.org (Postfix) with ESMTP id C4F1B8FC08; Sat, 17 Nov 2012 04:02:14 +0000 (UTC) Received: from localhost (tyd3.sub.tydfam.jp [192.168.1.3]) by daemon.sub.tydfam.jp (8.14.5/8.14.5) with ESMTP id qAH425F6008293; Sat, 17 Nov 2012 13:02:06 +0900 (JST) (envelope-from ken@tydfam.jp) Date: Sat, 17 Nov 2012 13:02:05 +0900 (JST) Message-Id: <20121117.130205.525573020410563046.ken@tydfam.jp> To: alc@rice.edu Subject: Re: link_elf_obj: symbol vm_page_lock_queues undefined From: ken In-Reply-To: <50A7012E.9060908@rice.edu> References: <50A7012E.9060908@rice.edu> X-Mailer: Mew version 6.5 on Emacs 24.2 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.2 required=5.0 tests=ALL_TRUSTED,RP_MATCHES_RCVD autolearn=unavailable version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on daemon.sub.tydfam.jp Cc: yanegomi@gmail.com, alc@freebsd.org, andy@neu.net, freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Nov 2012 04:02:15 -0000 Thank you, Alan. I temporary commented out vm_page_lock_queues()/vm_page_unlock_queues() in "src/VBox/Runtime/r0drv/freebsd/memobj-r0drv-freebsd.c". So far, it works!! We need to wait for official fix, but just to report that it enabled to run. Regards, From owner-freebsd-current@FreeBSD.ORG Sat Nov 17 05:21:39 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9C438EF; Sat, 17 Nov 2012 05:21:39 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 457978FC12; Sat, 17 Nov 2012 05:21:39 +0000 (UTC) Received: by mail-ob0-f182.google.com with SMTP id 16so4365091obc.13 for ; Fri, 16 Nov 2012 21:21:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=5/4Yq0s3hRW5UHQmx//WR1SeZNZE/uUNGD5oNokgNgw=; b=dznF5toUDzmMKiRo4nR5IlUQOLTCJO//HQtbvk6eWPURdTiYBarcgM2f/6aD6HaKSK 1M/ERDFNo83yl9DBRiZ1vRwVWP6owcot8wCvZJgf+Em6un3gg0rL0dpSb87b61CXwKY3 7ek4AMESuXAVb/1SEYaS/3X2yin2gzP1+mCHEZEWe/XWTk2lHSzRGZeUYdOn6G8PoIH4 ftHXOHqR0f1SUb+I0+QHn6C1Lrzw11rWW+jUI/2FkgC654YdSX3pMd24KKmqeVbjqyc3 36SoKJOGbjE0A8z9XX2xHblBwXSv+XTxPjzestw82A0ga8MdIRyL6k8+WTzf8EULv1mZ a5tA== MIME-Version: 1.0 Received: by 10.60.32.137 with SMTP id j9mr5854627oei.133.1353129698779; Fri, 16 Nov 2012 21:21:38 -0800 (PST) Received: by 10.76.143.33 with HTTP; Fri, 16 Nov 2012 21:21:38 -0800 (PST) In-Reply-To: <20121117.130205.525573020410563046.ken@tydfam.jp> References: <50A7012E.9060908@rice.edu> <20121117.130205.525573020410563046.ken@tydfam.jp> Date: Fri, 16 Nov 2012 21:21:38 -0800 Message-ID: Subject: Re: link_elf_obj: symbol vm_page_lock_queues undefined From: Garrett Cooper To: ken Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: alc@freebsd.org, andy@neu.net, freebsd-current@freebsd.org, alc@rice.edu X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Nov 2012 05:21:39 -0000 On Fri, Nov 16, 2012 at 8:02 PM, ken wrote: > Thank you, Alan. > I temporary commented out vm_page_lock_queues()/vm_page_unlock_queues() > in "src/VBox/Runtime/r0drv/freebsd/memobj-r0drv-freebsd.c". > So far, it works!! We need to wait for official fix, but just to report > that it enabled to run. > I'll produce a patch for this sometime this weekend if someone else doesn't beat me to it first... Cheers, -Garrett From owner-freebsd-current@FreeBSD.ORG Sat Nov 17 06:41:34 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 79022845; Sat, 17 Nov 2012 06:41:34 +0000 (UTC) (envelope-from wkoszek@freebsd.czest.pl) Received: from freebsd.czest.pl (freebsd.czest.pl [212.87.224.105]) by mx1.freebsd.org (Postfix) with ESMTP id ECE108FC08; Sat, 17 Nov 2012 06:41:33 +0000 (UTC) Received: from freebsd.czest.pl (freebsd.czest.pl [212.87.224.105]) by freebsd.czest.pl (8.14.5/8.14.5) with ESMTP id qAH6Uku7043511; Sat, 17 Nov 2012 06:30:46 GMT (envelope-from wkoszek@freebsd.czest.pl) Received: (from wkoszek@localhost) by freebsd.czest.pl (8.14.5/8.14.5/Submit) id qAH6Ukrs043510; Sat, 17 Nov 2012 06:30:46 GMT (envelope-from wkoszek) Date: Sat, 17 Nov 2012 06:30:46 +0000 From: "Wojciech A. Koszek" To: freebsd-current@freebsd.org, freebsd-stable@freebsd.org, freebsd-hackers@freebsd.org Subject: [Not this year] Re: FreeBSD in Google Code-In 2012? You can help too! Message-ID: <20121117063046.GN59689@FreeBSD.org> References: <20121016101957.GB53800@FreeBSD.org> <20121102201318.GI59689@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline In-Reply-To: <20121102201318.GI59689@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (freebsd.czest.pl [212.87.224.105]); Sat, 17 Nov 2012 06:30:46 +0000 (UTC) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Nov 2012 06:41:34 -0000 On Fri, Nov 02, 2012 at 08:13:18PM +0000, Wojciech A. Koszek wrote: > On Tue, Oct 16, 2012 at 10:19:57AM +0000, Wojciech A. Koszek wrote: > > (cross-posted message; please keep discussion on freebsd-hackers@) > > > > Hello, > > > > Last year FreeBSD qualified for Google Code-In 2011 event--contest for > > youngest open-source hackers in 13-17yr age range: > > > > http://www.google-melange.com/gci/homepage/google/gci2012 > > > > It was successful. We gained one more FreeBSD developer thanks to that > > (Isabell Long) We're pondering participating in the contest this year as > > well. > > > > For now we only have 25 ideas. We need at least 100. > > > > I felt all members of the FreeBSD community should help, so please submit > > your own Google Code-In 2012 ideas here: > > > > http://www.emailmeform.com/builder/form/4aU93Obxo4NYdVAgb1 > > > > Examples of previously completed tasks: > > > > http://wiki.freebsd.org/GoogleCodeIn/2011Tasks > > > > Those of you who have Wiki access, please spent 2 more minutes and submit > > straight to Wiki: > > > > http://wiki.freebsd.org/GoogleCodeIn/2012Tasks > > > > I plan to send out next e-mail if there's any progress on this project. > > > > Help will be appreciated. > > Hello, > > This is last call for action. > > As for now, we won't qualify. I suggest doc@ and ports@ and www@ and src@ > teams to try to come up with some ideas and add them to Wiki. Most of the > ideas which we have so far are more GSOC-alike. > > Unless we have at least 80 tasks of the "easy"/"medium" type, we'll have to > postpone participating in Code-In for next year. > > Thanks, Hello, We didn't make it this year. I want to thank all the people who submitted (and keep submitting) ideas for our Google Code-In wiki page: http://wiki.freebsd.org/GoogleCodeIn/2012Tasks In total I got 61 ideas over e-mail from the web form (lessons learnt: for GSOC, we should also have a web form) All of them should be on the Wiki now. I suggest we keep collecting good ideas and try to make sure this years GSOC will be successful. On the other note--NetBSD guys are in Google Code-In.. Thanks, -- Wojciech A. Koszek wkoszek@FreeBSD.czest.pl http://FreeBSD.czest.pl/~wkoszek/ From owner-freebsd-current@FreeBSD.ORG Sat Nov 17 15:24:17 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9D2FCE8D for ; Sat, 17 Nov 2012 15:24:17 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-vc0-f182.google.com (mail-vc0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 5155C8FC08 for ; Sat, 17 Nov 2012 15:24:17 +0000 (UTC) Received: by mail-vc0-f182.google.com with SMTP id fo13so5003970vcb.13 for ; Sat, 17 Nov 2012 07:24:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=Sgd2gXtipWE2v4Qg62YrLpFB7VtS4mETkHZlrfTEJnk=; b=Xp3lhc5rYSkzXg1Ico7BEVk3a/oAPfg8RkDKaZScdmiKE7mBkLfyiOoymQvP2MS0HY M2fqe0BKTDCg99zSFjLiF7dK+HlpvdDlJhtxBVZUkrV9uWsC0rFyadK3HZdxfbJP+038 jHK4DdvBelFiU9Zj4Cm1w/Jvw9VpfvXzRsiTo3Nxt9GorHWKfiHfoWXP4HeV5+Uyvnul 3jL3re0aH2nAM4KdbTrnwRL6eaFpTbSkXw/THItVGhaFSWh4o4u72gu37VrjPigJ0EBW MrUnLIIdOA7aJjnpTxms8GIgcWIauXjX/fdvjVmb31zeern8nPfVNJKMNO9xLyYAKKhy fc3g== MIME-Version: 1.0 Received: by 10.52.100.230 with SMTP id fb6mr10371729vdb.91.1353165856484; Sat, 17 Nov 2012 07:24:16 -0800 (PST) Received: by 10.58.207.114 with HTTP; Sat, 17 Nov 2012 07:24:16 -0800 (PST) Date: Sat, 17 Nov 2012 10:24:16 -0500 Message-ID: Subject: pw keeps setting /etc/group to 0600 From: Ryan Stone To: FreeBSD Current Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Nov 2012 15:24:17 -0000 /etc/group is supposed to be world-reable, right? Tools like groups or pw groupshow certainly seem to think so: [rstone@rstone-server ~]groups 1001 920 [rstone@rstone-server ~]ls -l /etc/group -rw------- 1 root 0 482 Nov 14 21:02 /etc/group [rstone@rstone-server ~]sudo chmod a+r /etc/group Password: [rstone@rstone-server ~]groups rstone vboxusers [rstone@rstone-server ~]sudo pw groupadd foo [rstone@rstone-server ~]ls -l /etc/group -rw------- 1 root 0 494 Nov 17 10:19 /etc/group [rstone@rstone-server ~] I'm not sure what caused the regression. I've been seeing the problem since I first installed -CURRENT on the machine a couple of weeks ago. From owner-freebsd-current@FreeBSD.ORG Sat Nov 17 15:16:37 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 29CA5BC2 for ; Sat, 17 Nov 2012 15:16:37 +0000 (UTC) (envelope-from ianf@cloudseed.co.za) Received: from zcs04.jnb1.cloudseed.co.za (zcs04.jnb1.cloudseed.co.za [41.154.0.161]) by mx1.freebsd.org (Postfix) with ESMTP id 57DB48FC16 for ; Sat, 17 Nov 2012 15:16:36 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zcs04.jnb1.cloudseed.co.za (Postfix) with ESMTP id EE1242A82C11 for ; Sat, 17 Nov 2012 17:07:56 +0200 (SAST) X-Virus-Scanned: amavisd-new at zcs04.jnb1.cloudseed.co.za Received: from zcs04.jnb1.cloudseed.co.za ([127.0.0.1]) by localhost (zcs04.jnb1.cloudseed.co.za [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Z3iUNIbq-a8 for ; Sat, 17 Nov 2012 17:07:56 +0200 (SAST) Received: from clue.co.za (unknown [41.154.88.19]) by zcs04.jnb1.cloudseed.co.za (Postfix) with ESMTPSA id 072CF2A82C01 for ; Sat, 17 Nov 2012 17:07:56 +0200 (SAST) Received: from localhost ([127.0.0.1] helo=clue.co.za) by clue.co.za with esmtp (Exim 4.80 (FreeBSD)) (envelope-from ) id 1TZjzu-0000R1-HA for freebsd-current@freebsd.org; Sat, 17 Nov 2012 17:07:54 +0200 To: freebsd-current@freebsd.org Subject: netisr panic? From: "Ian FREISLICH" X-Attribution: BOFH Date: Sat, 17 Nov 2012 17:07:54 +0200 Message-Id: X-Mailman-Approved-At: Sat, 17 Nov 2012 15:28:44 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Nov 2012 15:16:37 -0000 Hi I have this consistently with: FreeBSD firewall2.jnb1.gp-online.net 10.0-CURRENT FreeBSD 10.0-CURRENT #30 r243156: Fri Nov 16 20:12:33 SAST 2012 ianf@firewall2.jnb1.gp-online.net:/usr/obj/usr/src/sys/FIREWALL amd64 Fatal trap 12: page fault while in kernel mode cpuid = 4; apic id = 04 fault virtual address = 0xc fault code = supervisor read data, page not present instruction pointer = 0x20:0xffffffff8050f534 stack pointer = 0x28:0xffffff846384e9c0 frame pointer = 0x28:0xffffff846384ea00 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 11 (irq266: igb1:que 0) trap number = 12 panic: page fault cpuid = 4 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a panic() at panic+0x1ce trap_fatal() at trap_fatal+0x290 trap_pfault() at trap_pfault+0x21f trap() at trap+0x2b4 calltrap() at calltrap+0x8 --- trap 0xc, rip = 0xffffffff8050f534, rsp = 0xffffff846384e9c0, rbp = 0xffffff846384ea00 --- ether_nh_input() at ether_nh_input+0x94 netisr_dispatch_src() at netisr_dispatch_src+0x212 igb_rxeof() at igb_rxeof+0x3f0 igb_msix_que() at igb_msix_que+0xfa intr_event_execute_handlers() at intr_event_execute_handlers+0xfd ithread_loop() at ithread_loop+0x9e fork_exit() at fork_exit+0x11e fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff846384ecb0, rbp = 0 --- Uptime: 2h2m15s Dumping 1241 out of 16368 MB:..2%..11%..21%..31%..42%..51%..61%..71%..82%..91% #0 doadump (textdump=1) at /usr/src/sys/kern/kern_shutdown.c:266 266 if (textdump && textdump_pending) { (kgdb) #0 doadump (textdump=1) at /usr/src/sys/kern/kern_shutdown.c:266 #1 0xffffffff8044af04 in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:449 #2 0xffffffff8044b487 in panic (fmt=0x1
) at /usr/src/sys/kern/kern_shutdown.c:637 #3 0xffffffff80605bd0 in trap_fatal (frame=0xc, eva=) at /usr/src/sys/amd64/amd64/trap.c:872 #4 0xffffffff80605f3f in trap_pfault (frame=0xffffff846384e910, usermode=0) at /usr/src/sys/amd64/amd64/trap.c:789 #5 0xffffffff806062f4 in trap (frame=0xffffff846384e910) at /usr/src/sys/amd64/amd64/trap.c:463 #6 0xffffffff805eff6f in calltrap () at /usr/src/sys/amd64/amd64/exception.S:228 #7 0xffffffff8050f534 in ether_nh_input (m=0xfffffe012521e700) at /usr/src/sys/net/if_ethersubr.c:484 #8 0xffffffff8051a602 in netisr_dispatch_src (proto=9, source=, m=) at /usr/src/sys/net/netisr.c:1013 #9 0xffffffff803188b0 in igb_rxeof (que=0xfffffe000a183800, count=499, done=0x0) at /usr/src/sys/dev/e1000/if_igb.c:4688 #10 0xffffffff803218da in igb_msix_que (arg=) at /usr/src/sys/dev/e1000/if_igb.c:1596 #11 0xffffffff804208cd in intr_event_execute_handlers ( p=, ie=0xfffffe000a19f100) at /usr/src/sys/kern/kern_intr.c:1272 #12 0xffffffff804220fe in ithread_loop (arg=0xfffffe000a1c6660) at /usr/src/sys/kern/kern_intr.c:1285 #13 0xffffffff8041d52e in fork_exit ( callout=0xffffffff80422060 , arg=0xfffffe000a1c6660, frame=0xffffff846384ec00) at /usr/src/sys/kern/kern_fork.c:995 #14 0xffffffff805f042e in fork_trampoline () at /usr/src/sys/amd64/amd64/exception.S:602 #15 0x0000000000000000 in ?? () -- Meditating Guru Ian Freislich From owner-freebsd-current@FreeBSD.ORG Sat Nov 17 16:20:22 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7CE8E2DB; Sat, 17 Nov 2012 16:20:22 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-vb0-f54.google.com (mail-vb0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 19ABE8FC0C; Sat, 17 Nov 2012 16:20:21 +0000 (UTC) Received: by mail-vb0-f54.google.com with SMTP id l1so4922340vba.13 for ; Sat, 17 Nov 2012 08:20:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=0R8Y+GOt8YqwsWcuWaNRRq35LtQspqYVwyFzIIVgr2g=; b=wZuutgticr4bA1jwKYMKH2ZQ8+bAJur/9tlc648pBVBe/UxrrongYlqBwxD3nhet4G 8ZJCsmgSn4d7Z3fELbcunTeyQAht8iBv6Tu5g+quvdAaSSsbQNbdpv96Gl3coMtFiwSf rfuyUdMFMZPvKR5y7tlhQGxzH/RCP9g3oIX/GCpva4tqaGU3oKLj+XL2FMdfTB8roKYM FmYLBSPHvN8HOZXymqObj6Awt+60iP2T07EAmjFvxRbC7m7tkBaN+xIg6mC+n84s/7cp cI6+ti5bQGA8gdRQ51fisJZmKQhWj/9TEhWAqWhzM/I1yVz+dlffysoSWgv9cQ1XbO4p HoTQ== MIME-Version: 1.0 Received: by 10.52.155.199 with SMTP id vy7mr10718157vdb.54.1353169221399; Sat, 17 Nov 2012 08:20:21 -0800 (PST) Received: by 10.58.207.114 with HTTP; Sat, 17 Nov 2012 08:20:21 -0800 (PST) In-Reply-To: References: Date: Sat, 17 Nov 2012 11:20:21 -0500 Message-ID: Subject: Re: pw keeps setting /etc/group to 0600 From: Ryan Stone To: FreeBSD Current Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: bapt@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Nov 2012 16:20:22 -0000 Wow. So apparently things are even more broken than I though. Let's play, "What group am I in?" root@group-testing:/usr/home/rstone # cd /tmp root@group-testing:/tmp # pw groupadd testing root@group-testing:/tmp # mkdir testdir root@group-testing:/tmp # chown root:testing testdir/ root@group-testing:/tmp # chmod g+rwx testdir/ root@group-testing:/tmp # pw usermod root@group-testing:/tmp # pw groupmod testing -m rstone root@group-testing:/tmp # id rstone uid=1001(rstone) gid=1001(rstone) groups=1001(rstone),0(wheel),1002(testing) root@group-testing:/tmp # exit $ id uid=1001(rstone) gid=1001 groups=1001,0 $ id rstone uid=1001(rstone) gid=1001 groups=1001 $ touch /tmp/testdir/testfile touch: /tmp/testdir/testfile: Permission denied $ ls -ld /tmp/testdir/ drwxrwxr-x 2 root 1002 512 Nov 17 11:07 /tmp/testdir/ My original complaint that /etc/group gets permissions of 0600 is a result of a bug in libutil, which bapt@ ported pw to use in r242349. The new group manipulation API using mktemp to create a temporary file, writes the new group database to the temp file and then renames the temp file to /etc/group. The problem here is that mktemp creates a file with a mode of 600, and libutil never chmods it. That should be pretty trivial to fix. I have no idea what's happening in my example above, though. Baptiste, I have to ask: how much testing did r242349 receive before it was committed? From owner-freebsd-current@FreeBSD.ORG Sat Nov 17 16:26:59 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2340D423 for ; Sat, 17 Nov 2012 16:26:59 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-da0-f54.google.com (mail-da0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id E78D48FC14 for ; Sat, 17 Nov 2012 16:26:58 +0000 (UTC) Received: by mail-da0-f54.google.com with SMTP id z9so1668791dad.13 for ; Sat, 17 Nov 2012 08:26:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=jm6jIzyulvn2wcw6kTJzFNOmoCDKL9MCQj+fSC9Imz8=; b=Vain6gQyfRGH3AAMB+om60KwN5Xt65HLbTSqgPAsqGRTjHus8wfudHLadLjuT8Z3SV EGswPnWH+cAFittLjYRd+dpiV65UPq+Bdt7+azjvhDFzrs2r/jaIlmIFSfZa9v1VU1HT L08+oZAC0p9Oc3w6Kn6u/9UxsijI+fDlhXyikCr+IOtJcnkjhD4IC2phfbD9E+H7T5tK eo/91PbfJSdfOGgrHqh6WZQ13WmKOJR3hRGvnf89Nvp6AeHtXZ+eV8qWTW1anw8YMoy6 OHOc1AgWWKMIc9VCJ92OzIaQ8p/yg1YBTIjaobOxwXMVxTyz2ZnoMwWdhbcf8ul+PEcR GMww== MIME-Version: 1.0 Received: by 10.68.238.199 with SMTP id vm7mr24875716pbc.105.1353169618459; Sat, 17 Nov 2012 08:26:58 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.68.124.130 with HTTP; Sat, 17 Nov 2012 08:26:58 -0800 (PST) In-Reply-To: References: Date: Sat, 17 Nov 2012 08:26:58 -0800 X-Google-Sender-Auth: ziSZioYNoLoLCNCoqutKcPBe07E Message-ID: Subject: Re: netisr panic? From: Adrian Chadd To: Ian FREISLICH Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Nov 2012 16:26:59 -0000 It's a NULL ponter deref. This is my line 484 in if_ethersubr.c: eh = mtod(m, struct ether_header *); .. if that's yours, see if eh is NULL? adrian On 17 November 2012 07:07, Ian FREISLICH wrote: > Hi > > I have this consistently with: > > FreeBSD firewall2.jnb1.gp-online.net 10.0-CURRENT FreeBSD 10.0-CURRENT #30 r243156: Fri Nov 16 20:12:33 SAST 2012 ianf@firewall2.jnb1.gp-online.net:/usr/obj/usr/src/sys/FIREWALL amd64 > > > Fatal trap 12: page fault while in kernel mode > cpuid = 4; apic id = 04 > fault virtual address = 0xc > fault code = supervisor read data, page not present > instruction pointer = 0x20:0xffffffff8050f534 > stack pointer = 0x28:0xffffff846384e9c0 > frame pointer = 0x28:0xffffff846384ea00 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 11 (irq266: igb1:que 0) > trap number = 12 > panic: page fault > cpuid = 4 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > panic() at panic+0x1ce > trap_fatal() at trap_fatal+0x290 > trap_pfault() at trap_pfault+0x21f > trap() at trap+0x2b4 > calltrap() at calltrap+0x8 > --- trap 0xc, rip = 0xffffffff8050f534, rsp = 0xffffff846384e9c0, rbp = 0xffffff846384ea00 --- > ether_nh_input() at ether_nh_input+0x94 > netisr_dispatch_src() at netisr_dispatch_src+0x212 > igb_rxeof() at igb_rxeof+0x3f0 > igb_msix_que() at igb_msix_que+0xfa > intr_event_execute_handlers() at intr_event_execute_handlers+0xfd > ithread_loop() at ithread_loop+0x9e > fork_exit() at fork_exit+0x11e > fork_trampoline() at fork_trampoline+0xe > --- trap 0, rip = 0, rsp = 0xffffff846384ecb0, rbp = 0 --- > Uptime: 2h2m15s > Dumping 1241 out of 16368 MB:..2%..11%..21%..31%..42%..51%..61%..71%..82%..91% > > #0 doadump (textdump=1) at /usr/src/sys/kern/kern_shutdown.c:266 > 266 if (textdump && textdump_pending) { > (kgdb) #0 doadump (textdump=1) at /usr/src/sys/kern/kern_shutdown.c:266 > #1 0xffffffff8044af04 in kern_reboot (howto=260) > at /usr/src/sys/kern/kern_shutdown.c:449 > #2 0xffffffff8044b487 in panic (fmt=0x1
) > at /usr/src/sys/kern/kern_shutdown.c:637 > #3 0xffffffff80605bd0 in trap_fatal (frame=0xc, eva=) > at /usr/src/sys/amd64/amd64/trap.c:872 > #4 0xffffffff80605f3f in trap_pfault (frame=0xffffff846384e910, usermode=0) > at /usr/src/sys/amd64/amd64/trap.c:789 > #5 0xffffffff806062f4 in trap (frame=0xffffff846384e910) > at /usr/src/sys/amd64/amd64/trap.c:463 > #6 0xffffffff805eff6f in calltrap () > at /usr/src/sys/amd64/amd64/exception.S:228 > #7 0xffffffff8050f534 in ether_nh_input (m=0xfffffe012521e700) > at /usr/src/sys/net/if_ethersubr.c:484 > #8 0xffffffff8051a602 in netisr_dispatch_src (proto=9, > source=, m=) > at /usr/src/sys/net/netisr.c:1013 > #9 0xffffffff803188b0 in igb_rxeof (que=0xfffffe000a183800, count=499, > done=0x0) at /usr/src/sys/dev/e1000/if_igb.c:4688 > #10 0xffffffff803218da in igb_msix_que (arg=) > at /usr/src/sys/dev/e1000/if_igb.c:1596 > #11 0xffffffff804208cd in intr_event_execute_handlers ( > p=, ie=0xfffffe000a19f100) > at /usr/src/sys/kern/kern_intr.c:1272 > #12 0xffffffff804220fe in ithread_loop (arg=0xfffffe000a1c6660) > at /usr/src/sys/kern/kern_intr.c:1285 > #13 0xffffffff8041d52e in fork_exit ( > callout=0xffffffff80422060 , arg=0xfffffe000a1c6660, > frame=0xffffff846384ec00) at /usr/src/sys/kern/kern_fork.c:995 > #14 0xffffffff805f042e in fork_trampoline () > at /usr/src/sys/amd64/amd64/exception.S:602 > #15 0x0000000000000000 in ?? () > > > > -- > Meditating Guru > Ian Freislich > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Sat Nov 17 17:28:19 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5974E8CB; Sat, 17 Nov 2012 17:28:19 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by mx1.freebsd.org (Postfix) with ESMTP id AC2F98FC0C; Sat, 17 Nov 2012 17:28:18 +0000 (UTC) Received: by mail-wi0-f172.google.com with SMTP id hj6so2313090wib.13 for ; Sat, 17 Nov 2012 09:28:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=gVtefwDZ5lkRo2pf063DHOcFJCX1JFOdoN6x4sfiuW4=; b=wvQtaisOaY8qiUcs9bgORWkaRhX05nClpcpTI75Nojkpy64l4OzXxDG2XbRvuenDtY H/DwDWt+lgVKq9v08pCwBtQkuktYIyuSQ50vA6jjtp0XlkkA7UkqQauQ/sh+erBvEG2q kRaOrFCKp3B823kOc0LwkmFlbmBuRyuJ/fr+exwcPZh0JFa1WcBVOpEonH0FmX7FVYlr komkdYxeSa2RHF84lUJEy1qLQvZdVAZgHwY3rWyhseS4kQu7O/JKT4lYyXstPFmzuiFu TiwnkdFMrUJ4A7ysxmyQJZpgnMXxypR7vWSM7aOubkWQwADwnwoOjQfsska5dN2Ylg/s ctzQ== Received: by 10.216.139.209 with SMTP id c59mr3179262wej.50.1353173297553; Sat, 17 Nov 2012 09:28:17 -0800 (PST) Received: from dft-labs.eu (n1x0n-1-pt.tunnel.tserv5.lon1.ipv6.he.net. [2001:470:1f08:1f7::2]) by mx.google.com with ESMTPS id j18sm5793374wiv.9.2012.11.17.09.28.16 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 17 Nov 2012 09:28:16 -0800 (PST) Date: Sat, 17 Nov 2012 18:28:08 +0100 From: Mateusz Guzik To: Ryan Stone Subject: Re: pw keeps setting /etc/group to 0600 Message-ID: <20121117172808.GA8699@dft-labs.eu> Mail-Followup-To: Mateusz Guzik , Ryan Stone , FreeBSD Current , bapt@freebsd.org References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: bapt@freebsd.org, FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Nov 2012 17:28:19 -0000 On Sat, Nov 17, 2012 at 11:20:21AM -0500, Ryan Stone wrote: > Wow. So apparently things are even more broken than I though. Let's play, > "What group am I in?" > > root@group-testing:/usr/home/rstone # cd /tmp > root@group-testing:/tmp # pw groupadd testing > root@group-testing:/tmp # mkdir testdir > root@group-testing:/tmp # chown root:testing testdir/ > root@group-testing:/tmp # chmod g+rwx testdir/ > root@group-testing:/tmp # pw usermod > root@group-testing:/tmp # pw groupmod testing -m rstone > root@group-testing:/tmp # id rstone > uid=1001(rstone) gid=1001(rstone) groups=1001(rstone),0(wheel),1002(testing) > root@group-testing:/tmp # exit > $ id > uid=1001(rstone) gid=1001 groups=1001,0 > $ id rstone > uid=1001(rstone) gid=1001 groups=1001 > $ touch /tmp/testdir/testfile > touch: /tmp/testdir/testfile: Permission denied > $ ls -ld /tmp/testdir/ > drwxrwxr-x 2 root 1002 512 Nov 17 11:07 /tmp/testdir/ > This is not a bug and I think it always was this way. The process you used to su/sudo/whatever to root was not in testing group and didn't magically enter it after you added rstone user to that group. You have to log in again or do stuff like exec su - rstone. -- Mateusz Guzik From owner-freebsd-current@FreeBSD.ORG Sat Nov 17 18:13:28 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DE1416D; Sat, 17 Nov 2012 18:13:28 +0000 (UTC) (envelope-from ianf@clue.co.za) Received: from zcs04.jnb1.cloudseed.co.za (zcs04.jnb1.cloudseed.co.za [41.154.0.161]) by mx1.freebsd.org (Postfix) with ESMTP id 6EB928FC0C; Sat, 17 Nov 2012 18:13:27 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zcs04.jnb1.cloudseed.co.za (Postfix) with ESMTP id CC4E72A82C15; Sat, 17 Nov 2012 20:13:25 +0200 (SAST) X-Virus-Scanned: amavisd-new at zcs04.jnb1.cloudseed.co.za Received: from zcs04.jnb1.cloudseed.co.za ([127.0.0.1]) by localhost (zcs04.jnb1.cloudseed.co.za [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hHbmwN2nz+yC; Sat, 17 Nov 2012 20:13:24 +0200 (SAST) Received: from clue.co.za (unknown [41.154.88.19]) by zcs04.jnb1.cloudseed.co.za (Postfix) with ESMTPSA id 244262A82C14; Sat, 17 Nov 2012 20:13:24 +0200 (SAST) Received: from localhost ([127.0.0.1] helo=clue.co.za) by clue.co.za with esmtp (Exim 4.80 (FreeBSD)) (envelope-from ) id 1TZmtO-0000Xg-Cv; Sat, 17 Nov 2012 20:13:22 +0200 To: Adrian Chadd From: Ian FREISLICH Subject: Re: netisr panic? In-Reply-To: References: X-Attribution: BOFH Date: Sat, 17 Nov 2012 20:13:22 +0200 Message-Id: Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Nov 2012 18:13:28 -0000 Adrian Chadd wrote: > It's a NULL ponter deref. This is my line 484 in if_ethersubr.c: > > eh = mtod(m, struct ether_header *); > > > .. if that's yours, see if eh is NULL? (kgdb) frame 7 #7 0xffffffff8050f534 in ether_nh_input (m=0xfffffe012521e700) at /usr/src/sys/net/if_ethersubr.c:484 484 eh = mtod(m, struct ether_header *); (kgdb) print eh No symbol "eh" in current context. (kgdb) print *m $2 = {m_hdr = {mh_next = 0x100000000000000, mh_nextpkt = 0x10000000000, mh_data = 0x0, mh_len = 60, mh_flags = 4259842, mh_type = 0, pad = "\000\000\000\000\000"}, M_dat = {MH = {MH_pkthdr = { rcvif = 0xfffffe000a1c2000, header = 0xffffffff, len = 60, flowid = 0, csum_flags = 3840, csum_data = 65535, tso_segsz = 0, PH_vt = { vt_vtag = 4, vt_nrecs = 4}, tags = {slh_first = 0x3c000000}}, MH_dat = {MH_ext = { ext_buf = 0x69e5498600000000
, ext_free = 0x10602, ext_arg1 = 0xc000000070000, ext_arg2 = 0x100, ext_size = 2048, ref_cnt = 0xfffffe0125236d8c, ext_type = 6}, MH_databuf = "\000\000\000\000\206Ii\002\006\001\000\000\000\000\000\000\000\a\000\000\000\f\000\000\001\000\000\000\000\000\000\000\b\000\000\000\000\000\000\214m#%\001\006", '\0' }}, M_databuf = "\000 \034\n\000\000\000\000\000<\000\000\000\000\000\000\000\000\017\000\000\000\000\000\000\004\000\000\000\000\000\000\000\000<\000\000\000\000\000\000\000\000\206Ii\002\006\001\000\000\000\000\000\000\000\a\000\000\000\f\000\000\001\000\000\000\000\000\000\000\b\000\000\000\000\000\000\214m#%\001\006", '\0' }} Ian -- Ian Freislich From owner-freebsd-current@FreeBSD.ORG Sat Nov 17 18:23:56 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DE40A438; Sat, 17 Nov 2012 18:23:56 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pa0-f54.google.com (mail-pa0-f54.google.com [209.85.220.54]) by mx1.freebsd.org (Postfix) with ESMTP id A44EE8FC0C; Sat, 17 Nov 2012 18:23:56 +0000 (UTC) Received: by mail-pa0-f54.google.com with SMTP id kp6so2684355pab.13 for ; Sat, 17 Nov 2012 10:23:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=LI1X5TTHWJBVTZ1RlyuTiIcUq/ly5+Rz0aL2SMuW23E=; b=jOFxvz7cY+UdRoko3xJxiPg4HGwc2CLUkiRVqa346PbB0/mGbJA0CHu80aFPvyp4yo BsTRAavhft+pknHWOkj3WKReWwF9+L9e99egJys9x0fGddt5sMe4TV1rv0lW/i3ZB3tU So11aoGydfVaROQuI2+/tBUpsDj4fyo0egABZndQD2x86FIg6+Pt9/OqZAcoWZY6o5XP 2MUkEA6fPMDpFQN04XjzIxBVowohs2RMQo6C9yRj1VA2v90h5sRGxPbCC63YmURoBgxv +YE+vKTAWd128lYdXXh7ieFtjr3VeVha0V9KHnQSTyw81ePvSm42CvtFfftuH07HRdcs e01g== MIME-Version: 1.0 Received: by 10.68.137.198 with SMTP id qk6mr26045807pbb.60.1353176636269; Sat, 17 Nov 2012 10:23:56 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.68.124.130 with HTTP; Sat, 17 Nov 2012 10:23:56 -0800 (PST) In-Reply-To: References: Date: Sat, 17 Nov 2012 10:23:56 -0800 X-Google-Sender-Auth: gnDE4nlhRv48QKefE4HFzrExOUY Message-ID: Subject: Re: netisr panic? From: Adrian Chadd To: Ian FREISLICH Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Net , freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Nov 2012 18:23:57 -0000 Check what mtod() is doing. mbuf.h:#define mtod(m, t) ((t)((m)->m_data)) .. so if m->m_data is NULL, bam. The question is why is m_data NULL here. Someone mbuf cluey is going to have to answer that. I don't know whether the MH_dat stuff is being treated as valid but m_data isn't being updated, or something. Adrian On 17 November 2012 10:13, Ian FREISLICH wrote: > Adrian Chadd wrote: >> It's a NULL ponter deref. This is my line 484 in if_ethersubr.c: >> >> eh =3D mtod(m, struct ether_header *); >> >> >> .. if that's yours, see if eh is NULL? > > (kgdb) frame 7 > #7 0xffffffff8050f534 in ether_nh_input (m=3D0xfffffe012521e700) > at /usr/src/sys/net/if_ethersubr.c:484 > 484 eh =3D mtod(m, struct ether_header *); > (kgdb) print eh > No symbol "eh" in current context. > (kgdb) print *m > $2 =3D {m_hdr =3D {mh_next =3D 0x100000000000000, mh_nextpkt =3D 0x100000= 00000, > mh_data =3D 0x0, mh_len =3D 60, mh_flags =3D 4259842, mh_type =3D 0, > pad =3D "\000\000\000\000\000"}, M_dat =3D {MH =3D {MH_pkthdr =3D { > rcvif =3D 0xfffffe000a1c2000, header =3D 0xffffffff, len =3D 60, = flowid =3D 0, > csum_flags =3D 3840, csum_data =3D 65535, tso_segsz =3D 0, PH_vt = =3D { > vt_vtag =3D 4, vt_nrecs =3D 4}, tags =3D {slh_first =3D 0x3c000= 000}}, > MH_dat =3D {MH_ext =3D { > ext_buf =3D 0x69e5498600000000
, ext_free =3D 0x10602, ext_arg1 =3D 0xc000000070000, ext_arg2 = =3D 0x100, > ext_size =3D 2048, ref_cnt =3D 0xfffffe0125236d8c, ext_type =3D= 6}, > MH_databuf =3D "\000\000\000\000\206I=D0=B5i\002\006\001\000\000\= 000\000\000\000\000\a\000\000\000\f\000\000\001\000\000\000\000\000\000\000= \b\000\000\000\000\000\000\214m#%\001=D1=8E=D1=8F=D1=8F\006", '\0' }}, > M_databuf =3D "\000 \034\n\000=D1=8E=D1=8F=D1=8F=D1=8F=D1=8F=D1=8F=D1= =8F\000\000\000\000<\000\000\000\000\000\000\000\000\017\000\000=D1=8F=D1= =8F\000\000\000\000\004\000\000\000\000\000\000\000\000<\000\000\000\000\00= 0\000\000\000\206I=D0=B5i\002\006\001\000\000\000\000\000\000\000\a\000\000= \000\f\000\000\001\000\000\000\000\000\000\000\b\000\000\000\000\000\000\21= 4m#%\001=D1=8E=D1=8F=D1=8F\006", '\0' }} > > > Ian > > -- > Ian Freislich > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " From owner-freebsd-current@FreeBSD.ORG Sat Nov 17 21:31:19 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3F052A31; Sat, 17 Nov 2012 21:31:19 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id E904D8FC12; Sat, 17 Nov 2012 21:31:18 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 481E746B0D; Sat, 17 Nov 2012 16:31:18 -0500 (EST) Date: Sat, 17 Nov 2012 21:31:18 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Adrian Chadd Subject: Re: netisr panic? In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="621616949-1601276811-1353187878=:94966" Cc: FreeBSD Net , Ian FREISLICH , freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Nov 2012 21:31:19 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --621616949-1601276811-1353187878=:94966 Content-Type: TEXT/PLAIN; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT Panics along these lines often occur if there is a concurrency bug in a device driver such that it modifies an mbuf after dispatching to the network stack. E.g., by freeing it, reusing it, an errant dereference, etc. Not guaranteed, but that is where I'd start. Robert On Sat, 17 Nov 2012, Adrian Chadd wrote: > Check what mtod() is doing. > > mbuf.h:#define mtod(m, t) ((t)((m)->m_data)) > > .. so if m->m_data is NULL, bam. > > The question is why is m_data NULL here. Someone mbuf cluey is going > to have to answer that. I don't know whether the MH_dat stuff is being > treated as valid but m_data isn't being updated, or something. > > > Adrian > > On 17 November 2012 10:13, Ian FREISLICH wrote: >> Adrian Chadd wrote: >>> It's a NULL ponter deref. This is my line 484 in if_ethersubr.c: >>> >>> eh = mtod(m, struct ether_header *); >>> >>> >>> .. if that's yours, see if eh is NULL? >> >> (kgdb) frame 7 >> #7 0xffffffff8050f534 in ether_nh_input (m=0xfffffe012521e700) >> at /usr/src/sys/net/if_ethersubr.c:484 >> 484 eh = mtod(m, struct ether_header *); >> (kgdb) print eh >> No symbol "eh" in current context. >> (kgdb) print *m >> $2 = {m_hdr = {mh_next = 0x100000000000000, mh_nextpkt = 0x10000000000, >> mh_data = 0x0, mh_len = 60, mh_flags = 4259842, mh_type = 0, >> pad = "\000\000\000\000\000"}, M_dat = {MH = {MH_pkthdr = { >> rcvif = 0xfffffe000a1c2000, header = 0xffffffff, len = 60, flowid = 0, >> csum_flags = 3840, csum_data = 65535, tso_segsz = 0, PH_vt = { >> vt_vtag = 4, vt_nrecs = 4}, tags = {slh_first = 0x3c000000}}, >> MH_dat = {MH_ext = { >> ext_buf = 0x69e5498600000000
, ext_free = 0x10602, ext_arg1 = 0xc000000070000, ext_arg2 = 0x100, >> ext_size = 2048, ref_cnt = 0xfffffe0125236d8c, ext_type = 6}, >> MH_databuf = "\000\000\000\000\206Iеi\002\006\001\000\000\000\000\000\000\000\a\000\000\000\f\000\000\001\000\000\000\000\000\000\000\b\000\000\000\000\000\000\214m#%\001юяя\006", '\0' }}, >> M_databuf = "\000 \034\n\000юяяяяяя\000\000\000\000<\000\000\000\000\000\000\000\000\017\000\000яя\000\000\000\000\004\000\000\000\000\000\000\000\000<\000\000\000\000\000\000\000\000\206Iеi\002\006\001\000\000\000\000\000\000\000\a\000\000\000\f\000\000\001\000\000\000\000\000\000\000\b\000\000\000\000\000\000\214m#%\001юяя\006", '\0' }} >> >> >> Ian >> >> -- >> Ian Freislich >> >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" --621616949-1601276811-1353187878=:94966-- From owner-freebsd-current@FreeBSD.ORG Sat Nov 17 21:38:10 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0B2CBC0D for ; Sat, 17 Nov 2012 21:38:10 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.64.117]) by mx1.freebsd.org (Postfix) with ESMTP id 770FB8FC08 for ; Sat, 17 Nov 2012 21:38:09 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.5/8.14.5) with ESMTP id qAHLbsaX052754; Sun, 18 Nov 2012 01:37:54 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.5/8.14.5/Submit) id qAHLbspx052753; Sun, 18 Nov 2012 01:37:54 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Sun, 18 Nov 2012 01:37:54 +0400 From: Gleb Smirnoff To: Ian FREISLICH Subject: Re: netisr panic? Message-ID: <20121117213754.GI38060@FreeBSD.org> References: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="nFreZHaLTZJo0R7j" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Nov 2012 21:38:10 -0000 --nFreZHaLTZJo0R7j Content-Type: text/plain; charset=koi8-r Content-Disposition: inline On Sat, Nov 17, 2012 at 05:07:54PM +0200, Ian FREISLICH wrote: I> I have this consistently with: I> I> FreeBSD firewall2.jnb1.gp-online.net 10.0-CURRENT FreeBSD 10.0-CURRENT #30 r243156: Fri Nov 16 20:12:33 SAST 2012 ianf@firewall2.jnb1.gp-online.net:/usr/obj/usr/src/sys/FIREWALL amd64 Pretty sure this is a new version of wrong byte order panic, which no longer can happen in HEAD. Can you please try this patch? -- Totus tuus, Glebius. --nFreZHaLTZJo0R7j Content-Type: text/x-diff; charset=koi8-r Content-Disposition: attachment; filename="if_igb.c.no-relock.diff" Index: if_igb.c =================================================================== --- if_igb.c (revision 243149) +++ if_igb.c (working copy) @@ -4684,9 +4684,7 @@ if (tcp_lro_rx(&rxr->lro, m, 0) == 0) return; } - IGB_RX_UNLOCK(rxr); (*ifp->if_input)(ifp, m); - IGB_RX_LOCK(rxr); } /********************************************************************* --nFreZHaLTZJo0R7j-- From owner-freebsd-current@FreeBSD.ORG Sat Nov 17 22:17:27 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 41DFF30C; Sat, 17 Nov 2012 22:17:27 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 044A88FC0C; Sat, 17 Nov 2012 22:17:26 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id qAHMHJPQ051968; Sat, 17 Nov 2012 17:17:19 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id qAHMHJUs051967; Sat, 17 Nov 2012 22:17:19 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 17 Nov 2012 22:17:19 GMT Message-Id: <201211172217.qAHMHJUs051967@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on arm/arm Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Nov 2012 22:17:27 -0000 TB --- 2012-11-17 21:10:01 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-11-17 21:10:01 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-11-17 21:10:01 - starting HEAD tinderbox run for arm/arm TB --- 2012-11-17 21:10:01 - cleaning the object tree TB --- 2012-11-17 21:10:01 - checking out /src from svn://svn.freebsd.org/base/head TB --- 2012-11-17 21:10:01 - cd /tinderbox/HEAD/arm/arm TB --- 2012-11-17 21:10:01 - /usr/local/bin/svn cleanup /src TB --- 2012-11-17 21:14:16 - /usr/local/bin/svn update /src TB --- 2012-11-17 21:14:27 - At svn revision 243187 TB --- 2012-11-17 21:14:28 - building world TB --- 2012-11-17 21:14:28 - CROSS_BUILD_TESTING=YES TB --- 2012-11-17 21:14:28 - MAKEOBJDIRPREFIX=/obj TB --- 2012-11-17 21:14:28 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-11-17 21:14:28 - SRCCONF=/dev/null TB --- 2012-11-17 21:14:28 - TARGET=arm TB --- 2012-11-17 21:14:28 - TARGET_ARCH=arm TB --- 2012-11-17 21:14:28 - TZ=UTC TB --- 2012-11-17 21:14:28 - __MAKE_CONF=/dev/null TB --- 2012-11-17 21:14:28 - cd /src TB --- 2012-11-17 21:14:28 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sat Nov 17 21:14:36 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sat Nov 17 22:12:15 UTC 2012 TB --- 2012-11-17 22:12:15 - cd /src/sys/arm/conf TB --- 2012-11-17 22:12:15 - /usr/sbin/config -m AC100 TB --- 2012-11-17 22:12:15 - skipping AC100 kernel TB --- 2012-11-17 22:12:15 - cd /src/sys/arm/conf TB --- 2012-11-17 22:12:15 - /usr/sbin/config -m ARMADAXP TB --- 2012-11-17 22:12:15 - skipping ARMADAXP kernel TB --- 2012-11-17 22:12:15 - cd /src/sys/arm/conf TB --- 2012-11-17 22:12:15 - /usr/sbin/config -m ATMEL TB --- 2012-11-17 22:12:15 - building ATMEL kernel TB --- 2012-11-17 22:12:15 - CROSS_BUILD_TESTING=YES TB --- 2012-11-17 22:12:15 - MAKEOBJDIRPREFIX=/obj TB --- 2012-11-17 22:12:15 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-11-17 22:12:15 - SRCCONF=/dev/null TB --- 2012-11-17 22:12:15 - TARGET=arm TB --- 2012-11-17 22:12:15 - TARGET_ARCH=arm TB --- 2012-11-17 22:12:15 - TZ=UTC TB --- 2012-11-17 22:12:15 - __MAKE_CONF=/dev/null TB --- 2012-11-17 22:12:15 - cd /src TB --- 2012-11-17 22:12:15 - /usr/bin/make -B buildkernel KERNCONF=ATMEL >>> Kernel build for ATMEL started on Sat Nov 17 22:12:15 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for ATMEL completed on Sat Nov 17 22:15:50 UTC 2012 TB --- 2012-11-17 22:15:50 - cd /src/sys/arm/conf TB --- 2012-11-17 22:15:50 - /usr/sbin/config -m AVILA TB --- 2012-11-17 22:15:50 - skipping AVILA kernel TB --- 2012-11-17 22:15:50 - cd /src/sys/arm/conf TB --- 2012-11-17 22:15:50 - /usr/sbin/config -m BEAGLEBONE TB --- 2012-11-17 22:15:50 - skipping BEAGLEBONE kernel TB --- 2012-11-17 22:15:50 - cd /src/sys/arm/conf TB --- 2012-11-17 22:15:50 - /usr/sbin/config -m BWCT TB --- 2012-11-17 22:15:50 - building BWCT kernel TB --- 2012-11-17 22:15:50 - CROSS_BUILD_TESTING=YES TB --- 2012-11-17 22:15:50 - MAKEOBJDIRPREFIX=/obj TB --- 2012-11-17 22:15:50 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-11-17 22:15:50 - SRCCONF=/dev/null TB --- 2012-11-17 22:15:50 - TARGET=arm TB --- 2012-11-17 22:15:50 - TARGET_ARCH=arm TB --- 2012-11-17 22:15:50 - TZ=UTC TB --- 2012-11-17 22:15:50 - __MAKE_CONF=/dev/null TB --- 2012-11-17 22:15:50 - cd /src TB --- 2012-11-17 22:15:50 - /usr/bin/make -B buildkernel KERNCONF=BWCT >>> Kernel build for BWCT started on Sat Nov 17 22:15:50 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mcpu=arm9 -ffreestanding -Werror /src/sys/net/radix_mpath.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mcpu=arm9 -ffreestanding -Werror /src/sys/net/raw_cb.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mcpu=arm9 -ffreestanding -Werror /src/sys/net/raw_usrreq.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mcpu=arm9 -ffreestanding -Werror /src/sys/net/route.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mcpu=arm9 -ffreestanding -Werror /src/sys/net/rtsock.c cc1: warnings being treated as errors /src/sys/net/rtsock.c: In function 'sysctl_dumpentry': /src/sys/net/rtsock.c:1577: warning: unused variable 'i' [-Wunused-variable] *** [rtsock.o] Error code 1 Stop in /obj/arm.arm/src/sys/BWCT. *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-11-17 22:17:19 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-11-17 22:17:19 - ERROR: failed to build BWCT kernel TB --- 2012-11-17 22:17:19 - 2800.70 user 579.93 system 4038.50 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-arm-arm.full