[head tinderbox] failure on i386/pc98

[FreeBSD Tinderbox]

TB --- 2013-08-14 03:02:08 - tinderbox 2.10 running on freebsd-current.sentex.ca
TB --- 2013-08-14 03:02:08 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE 
FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 
d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC  amd64
TB --- 2013-08-14 03:02:08 - starting HEAD tinderbox run for i386/pc98
TB --- 2013-08-14 03:02:08 - cleaning the object tree
TB --- 2013-08-14 03:02:08 - /usr/local/bin/svn stat /src
TB --- 2013-08-14 03:02:12 - At svn revision 254308
TB --- 2013-08-14 03:02:13 - building world
TB --- 2013-08-14 03:02:13 - CROSS_BUILD_TESTING=YES
TB --- 2013-08-14 03:02:13 - MAKEOBJDIRPREFIX=/obj
TB --- 2013-08-14 03:02:13 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2013-08-14 03:02:13 - SRCCONF=/dev/null
TB --- 2013-08-14 03:02:13 - TARGET=pc98
TB --- 2013-08-14 03:02:13 - TARGET_ARCH=i386
TB --- 2013-08-14 03:02:13 - TZ=UTC
TB --- 2013-08-14 03:02:13 - __MAKE_CONF=/dev/null
TB --- 2013-08-14 03:02:13 - cd /src
TB --- 2013-08-14 03:02:13 - /usr/bin/make -B buildworld
>>> Building an up-to-date make(1)
>>> World build started on Wed Aug 14 03:02:20 UTC 2013
>>> 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 Wed Aug 14 06:20:00 UTC 2013
TB --- 2013-08-14 06:20:00 - generating LINT kernel config
TB --- 2013-08-14 06:20:00 - cd /src/sys/pc98/conf
TB --- 2013-08-14 06:20:00 - /usr/bin/make -B LINT
TB --- 2013-08-14 06:20:01 - cd /src/sys/pc98/conf
TB --- 2013-08-14 06:20:01 - /usr/sbin/config -m LINT
TB --- 2013-08-14 06:20:01 - building LINT kernel
TB --- 2013-08-14 06:20:01 - CROSS_BUILD_TESTING=YES
TB --- 2013-08-14 06:20:01 - MAKEOBJDIRPREFIX=/obj
TB --- 2013-08-14 06:20:01 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2013-08-14 06:20:01 - SRCCONF=/dev/null
TB --- 2013-08-14 06:20:01 - TARGET=pc98
TB --- 2013-08-14 06:20:01 - TARGET_ARCH=i386
TB --- 2013-08-14 06:20:01 - TZ=UTC
TB --- 2013-08-14 06:20:01 - __MAKE_CONF=/dev/null
TB --- 2013-08-14 06:20:01 - cd /src
TB --- 2013-08-14 06:20:01 - /usr/bin/make -B buildkernel KERNCONF=LINT
>>> Kernel build for LINT started on Wed Aug 14 06:20:01 UTC 2013
>>> 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  
-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 -DGPROF -DGPROF4 -DGUPROF -fno-builtin -mno-aes -mno-avx -mno-mmx 
-mno-sse -msoft-float -ffreestanding -fstack-protector -Werror -pg 
/src/sys/fs/ext2fs/ext2_subr.c
/src/sys/fs/ext2fs/ext2_subr.c:154:4: error: format specifies type 'long' but 
the argument has type 'e4fs_daddr_t' (aka 'long long') [-Werror,-Wformat]
start, last, (long long)ep->b_blkno,
^
/src/sys/fs/ext2fs/ext2_subr.c:154:11: error: format specifies type 'long' but 
the argument has type 'e4fs_daddr_t' (aka 'long long') [-Werror,-Wformat]
start, last, (long long)ep->b_blkno,
   ^~~~
2 errors generated.
*** Error code 1

Stop.
bmake[1]: stopped in /obj/pc98.i386/src/sys/LINT
*** Error code 1

Stop.
bmake: stopped in /src
*** Error code 1

Stop in /src.
TB --- 2013-08-14 06:31:19 - WARNING: /usr/bin/make returned exit code  1 
TB --- 2013-08-14 06:31:19 - ERROR: failed to build LINT kernel
TB --- 2013-08-14 06:31:19 - 10140.37 user 1510.05 system 12551.73 real


http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-i386-pc98.full
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: panic: UMA: Increase vm.boot_pages with 32 CPUs

[Jeff Roberson]

On Tue, 13 Aug 2013, Jim Harris wrote:





On Tue, Aug 13, 2013 at 3:05 PM, Jeff Roberson 
wrote:
  On Mon, 12 Aug 2013, Colin Percival wrote:

Hi all,

A HEAD@254238 kernel fails to boot in EC2 with
  panic: UMA: Increase vm.boot_pages

on 32-CPU instances.  Instances with up to 16 CPUs
boot fine.

I know there has been some mucking about with VM
recently -- anyone want
to claim this, or should I start doing a binary
search?


It's not any one commit really, just creeping demand for more pages
before the VM can get started.  I would suggest making boot pages
scale with MAXCPU.  Or just raising it as the panic suggests.  We
could rewrite the way that the vm gets these early pages but it's a
lot of work and typically people just bump it and forget about it.


I ran into this problem today when enabling hyperthreading on my dual-socket
Xeon E5 system.

It looks like r254025 is actually the culprit.  Specifically, the new
mallocinit()/kmeminit() now invoke the new vmem_init() before
uma_startup2(), which allocates 16 zones out of the boot pages if I am
reading this correctly.  This is all done before uma_startup2() is called,
triggering the panic.



I just disabled the quantum caches in vmem which allocate those 16 zones. 
This may alleviate the problem for now.


Thanks,
Jeff


Anything less than 28 CPUs, and the zone size (uma_zone + uma_cache *
(mp_maxid + 1)) is <= PAGE_SIZE and we can successfully boot.  So at 32
CPUs, we need two boot pages per zone which consumes more than the default
64 boot pages.  The size of these structures do not appear to have
materially changed any time recently.

Scaling with MAXCPU seems to be an OK solution, but should it be based
directly on the size of (uma_zone + uma_cache * MAXCPU)?  I am not very
familiar with uma startup, but it seems like these zones are the primary
consumers of the boot pages, so the UMA_BOOT_PAGES default should be based
directly on that size..

Regards,

-Jim


___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Early drop to debugger with DEBUG_MEMGUARD

[David Wolfskill]

On Tue, Aug 13, 2013 at 12:44:54PM -1000, Jeff Roberson wrote:
> ...
> Please try 254308.  It is working for me.

Starting from:

FreeBSD freebeast.catwhisker.org 10.0-CURRENT FreeBSD 10.0-CURRENT #1244  
r254279M/254280:143: Tue Aug 13 11:11:06 PDT 2013 
r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/sys/GENERIC  i386

I applied the patches from 254304, 254307, and 254308 and re-built,
using the "MEMGUARD" kernel config (GENERIC + "options DEBUG_MEMGUARD");
the result boots and transitions to multi-user mode:

FreeBSD freebeast.catwhisker.org 10.0-CURRENT FreeBSD 10.0-CURRENT #0  
r254279M/254280:143: Tue Aug 13 19:28:50 PDT 2013 
r...@freebeast.catwhisker.org:/common/S2/obj/usr/src/sys/MEMGUARD  i386

I call that success.  :-}

Thanks!

Peace,
david
-- 
David H. Wolfskill  da...@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.


pgp5qsThNrzsJ.pgp
Description: PGP signature

[head tinderbox] failure on i386/i386

[FreeBSD Tinderbox]

TB --- 2013-08-13 23:50:29 - tinderbox 2.10 running on freebsd-current.sentex.ca
TB --- 2013-08-13 23:50:29 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE 
FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 
d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC  amd64
TB --- 2013-08-13 23:50:29 - starting HEAD tinderbox run for i386/i386
TB --- 2013-08-13 23:50:29 - cleaning the object tree
TB --- 2013-08-13 23:50:29 - /usr/local/bin/svn stat /src
TB --- 2013-08-13 23:50:35 - At svn revision 254308
TB --- 2013-08-13 23:50:36 - building world
TB --- 2013-08-13 23:50:36 - CROSS_BUILD_TESTING=YES
TB --- 2013-08-13 23:50:36 - MAKEOBJDIRPREFIX=/obj
TB --- 2013-08-13 23:50:36 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2013-08-13 23:50:36 - SRCCONF=/dev/null
TB --- 2013-08-13 23:50:36 - TARGET=i386
TB --- 2013-08-13 23:50:36 - TARGET_ARCH=i386
TB --- 2013-08-13 23:50:36 - TZ=UTC
TB --- 2013-08-13 23:50:36 - __MAKE_CONF=/dev/null
TB --- 2013-08-13 23:50:36 - cd /src
TB --- 2013-08-13 23:50:36 - /usr/bin/make -B buildworld
>>> Building an up-to-date make(1)
>>> World build started on Tue Aug 13 23:50:43 UTC 2013
>>> 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 Wed Aug 14 03:02:25 UTC 2013
TB --- 2013-08-14 03:02:25 - generating LINT kernel config
TB --- 2013-08-14 03:02:25 - cd /src/sys/i386/conf
TB --- 2013-08-14 03:02:25 - /usr/bin/make -B LINT
TB --- 2013-08-14 03:02:25 - cd /src/sys/i386/conf
TB --- 2013-08-14 03:02:25 - /usr/sbin/config -m LINT
TB --- 2013-08-14 03:02:25 - building LINT kernel
TB --- 2013-08-14 03:02:25 - CROSS_BUILD_TESTING=YES
TB --- 2013-08-14 03:02:25 - MAKEOBJDIRPREFIX=/obj
TB --- 2013-08-14 03:02:25 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2013-08-14 03:02:25 - SRCCONF=/dev/null
TB --- 2013-08-14 03:02:25 - TARGET=i386
TB --- 2013-08-14 03:02:25 - TARGET_ARCH=i386
TB --- 2013-08-14 03:02:25 - TZ=UTC
TB --- 2013-08-14 03:02:25 - __MAKE_CONF=/dev/null
TB --- 2013-08-14 03:02:25 - cd /src
TB --- 2013-08-14 03:02:25 - /usr/bin/make -B buildkernel KERNCONF=LINT
>>> Kernel build for LINT started on Wed Aug 14 03:02:25 UTC 2013
>>> 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  
-Wno-error-tautological-compare -Wno-error-empty-body  
-Wno-error-parentheses-equality  -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 -DGPROF -DGPROF4 -DGUPROF 
-fno-builtin -mno-aes -mno-avx -mno-mmx -mno-sse -msoft-float -ffreestanding 
-fstack-protector -Werror -pg /src/sys/fs/ext2fs/ext2_subr.c
/src/sys/fs/ext2fs/ext2_subr.c:154:4: error: format specifies type 'long' but 
the argument has type 'e4fs_daddr_t' (aka 'long long') [-Werror,-Wformat]
start, last, (long long)ep->b_blkno,
^
/src/sys/fs/ext2fs/ext2_subr.c:154:11: error: format specifies type 'long' but 
the argument has type 'e4fs_daddr_t' (aka 'long long') [-Werror,-Wformat]
start, last, (long long)ep->b_blkno,
   ^~~~
2 errors generated.
*** Error code 1

Stop.
bmake[1]: stopped in /obj/i386.i386/src/sys/LINT
*** Error code 1

Stop.
bmake: stopped in /src
*** Error code 1

Stop in /src.
TB --- 2013-08-14 03:16:26 - WARNING: /usr/bin/make returned exit code  1 
TB --- 2013-08-14 03:16:26 - ERROR: failed to build LINT kernel
TB --- 2013-08-14 03:16:26 - 10022.91 user 1747.49 system 12357.14 real


http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-i386-i386.full
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

[head tinderbox] failure on arm/arm

[FreeBSD Tinderbox]

TB --- 2013-08-13 23:50:29 - tinderbox 2.10 running on freebsd-current.sentex.ca
TB --- 2013-08-13 23:50:29 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE 
FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 
d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC  amd64
TB --- 2013-08-13 23:50:29 - starting HEAD tinderbox run for arm/arm
TB --- 2013-08-13 23:50:30 - cleaning the object tree
TB --- 2013-08-13 23:50:30 - /usr/local/bin/svn stat /src
TB --- 2013-08-13 23:50:35 - At svn revision 254308
TB --- 2013-08-13 23:50:36 - building world
TB --- 2013-08-13 23:50:36 - CROSS_BUILD_TESTING=YES
TB --- 2013-08-13 23:50:36 - MAKEOBJDIRPREFIX=/obj
TB --- 2013-08-13 23:50:36 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2013-08-13 23:50:36 - SRCCONF=/dev/null
TB --- 2013-08-13 23:50:36 - TARGET=arm
TB --- 2013-08-13 23:50:36 - TARGET_ARCH=arm
TB --- 2013-08-13 23:50:36 - TZ=UTC
TB --- 2013-08-13 23:50:36 - __MAKE_CONF=/dev/null
TB --- 2013-08-13 23:50:36 - cd /src
TB --- 2013-08-13 23:50:36 - /usr/bin/make -B buildworld
>>> Building an up-to-date make(1)
>>> World build started on Tue Aug 13 23:50:43 UTC 2013
>>> 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 Wed Aug 14 02:51:22 UTC 2013
TB --- 2013-08-14 02:51:22 - generating LINT kernel config
TB --- 2013-08-14 02:51:22 - cd /src/sys/arm/conf
TB --- 2013-08-14 02:51:22 - /usr/bin/make -B LINT
TB --- 2013-08-14 02:51:22 - cd /src/sys/arm/conf
TB --- 2013-08-14 02:51:22 - /usr/sbin/config -m LINT
TB --- 2013-08-14 02:51:22 - building LINT kernel
TB --- 2013-08-14 02:51:22 - CROSS_BUILD_TESTING=YES
TB --- 2013-08-14 02:51:22 - MAKEOBJDIRPREFIX=/obj
TB --- 2013-08-14 02:51:22 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2013-08-14 02:51:22 - SRCCONF=/dev/null
TB --- 2013-08-14 02:51:22 - TARGET=arm
TB --- 2013-08-14 02:51:22 - TARGET_ARCH=arm
TB --- 2013-08-14 02:51:22 - TZ=UTC
TB --- 2013-08-14 02:51:22 - __MAKE_CONF=/dev/null
TB --- 2013-08-14 02:51:22 - cd /src
TB --- 2013-08-14 02:51:22 - /usr/bin/make -B buildkernel KERNCONF=LINT
>>> Kernel build for LINT started on Wed Aug 14 02:51:22 UTC 2013
>>> 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  
-Wno-error-tautological-compare -Wno-error-empty-body  
-Wno-error-parentheses-equality  -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-builtin -funwind-tables 
-mllvm -arm-enable-ehabi -ffreestanding -Werror  /src/sys/fs/ext2fs/ext2_subr.c
/src/sys/fs/ext2fs/ext2_subr.c:154:4: error: format specifies type 'long' but 
the argument has type 'e4fs_daddr_t' (aka 'long long') [-Werror,-Wformat]
start, last, (long long)ep->b_blkno,
^
/src/sys/fs/ext2fs/ext2_subr.c:154:11: error: format specifies type 'long' but 
the argument has type 'e4fs_daddr_t' (aka 'long long') [-Werror,-Wformat]
start, last, (long long)ep->b_blkno,
   ^~~~
2 errors generated.
*** Error code 1

Stop.
bmake[1]: stopped in /obj/arm.arm/src/sys/LINT
*** Error code 1

Stop.
bmake: stopped in /src
*** Error code 1

Stop in /src.
TB --- 2013-08-14 03:02:07 - WARNING: /usr/bin/make returned exit code  1 
TB --- 2013-08-14 03:02:07 - ERROR: failed to build LINT kernel
TB --- 2013-08-14 03:02:07 - 9149.54 user 1634.58 system 11497.91 real


http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-arm-arm.full
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: panic: UMA: Increase vm.boot_pages with 32 CPUs

[Jim Harris]

On Tue, Aug 13, 2013 at 3:05 PM, Jeff Roberson wrote:

> On Mon, 12 Aug 2013, Colin Percival wrote:
>
>  Hi all,
>>
>> A HEAD@254238 kernel fails to boot in EC2 with
>>
>>> panic: UMA: Increase vm.boot_pages
>>>
>> on 32-CPU instances.  Instances with up to 16 CPUs boot fine.
>>
>> I know there has been some mucking about with VM recently -- anyone want
>> to claim this, or should I start doing a binary search?
>>
>
> It's not any one commit really, just creeping demand for more pages before
> the VM can get started.  I would suggest making boot pages scale with
> MAXCPU.  Or just raising it as the panic suggests.  We could rewrite the
> way that the vm gets these early pages but it's a lot of work and typically
> people just bump it and forget about it.
>
>
I ran into this problem today when enabling hyperthreading on my
dual-socket Xeon E5 system.

It looks like r254025 is actually the culprit.  Specifically, the new
mallocinit()/kmeminit() now invoke the new vmem_init() before
uma_startup2(), which allocates 16 zones out of the boot pages if I am
reading this correctly.  This is all done before uma_startup2() is called,
triggering the panic.

Anything less than 28 CPUs, and the zone size (uma_zone + uma_cache *
(mp_maxid + 1)) is <= PAGE_SIZE and we can successfully boot.  So at 32
CPUs, we need two boot pages per zone which consumes more than the default
64 boot pages.  The size of these structures do not appear to have
materially changed any time recently.

Scaling with MAXCPU seems to be an OK solution, but should it be based
directly on the size of (uma_zone + uma_cache * MAXCPU)?  I am not very
familiar with uma startup, but it seems like these zones are the primary
consumers of the boot pages, so the UMA_BOOT_PAGES default should be based
directly on that size..

Regards,

-Jim
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Hang with nvidia-driver

[Alex]

I can confirm that the patch found on the pastebin fixes the problem.


On Tue, Aug 13, 2013 at 3:06 PM, Mark Johnston  wrote:

> On Tue, Aug 13, 2013 at 2:37 PM, Alex  wrote:
>
>> Hi. I just upgraded to revision 254271 and am experiencing a hang when
>> slim
>> starts. The monitor goes blank (no signal) and the fans increase in speed,
>> suggesting high CPU usage. I have a GeForce GT 440. As suggested on the
>> forums, I tried setting "machdep.disable_mtrrs=1" at the boot loader, but
>> this did not help.
>>
>> Does anyone have any advice?
>>
>> Thanks,
>> Alex
>>
>
> I ran into a similar problem a few days ago. Applying the nvidia-driver
> Makefile
> patch from the follow-ups in the PR below and rebuilding the driver fixed
> the
> problem for me:
>
> http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/181144
>
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Positional arguments/load command broken in boot loader; cannot load old kernel

[Garrett Cooper]

Sorry. Hit the send button too soon...

On Aug 13, 2013, at 10:15 AM, Xin Li  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> On 08/13/13 09:36, Garrett Cooper wrote:
>> I made the mistake of installing CURRENT on my file server at home 
>> this morning and thought I could just boot the old kernel, do a
>> zfs rollback, then continue on my merry way.
>> 
>> Turns out I was horribly wrong.
>> 
>> In addition to colors added to the boot loader (h shiny!!!),
>> it appears the loading kernels with the load sub command from zfs
>> pools does not work (load kernel.old, boot -s kernel.old, etc).
>> Period. It works just fine with my stable/9 kernel/userland, but
>> not the CURRENT one.
> 
> Don't work -- how?  I rebuild my laptop daily and does not see that
> and I don't see a way Devin's changes could possibility cause problems
> like this.

Unfortunately I don't have definitive data other than the symptoms I noted, and 
some other data I can put together when I can unripple my home machine.

> BTW since this sounds like a ZFS related issue -- did you do a 'zpool
> upgrade' without updating loader or boot block and used some new features?

Nope. An important item that I realized is that my boot0 bits are still based 
on stable/9 sources built on August 9th (with backports from CURRENT so 
zfsboottest works with the stable/9 sources), so it might actually be that the 
upgrade path from 9 to 10 doesn't "just work" without resetting the boot bits 
with gpart.

Would be nice if mergemaster -p automated this, or something along those 
lines... I feel that due to the amount of churn in ZFS, there are edge cases 
where due to things getting out of synch a system can easily become unbootable.

Thanks!
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Positional arguments/load command broken in boot loader; cannot load old kernel

[Garrett Cooper]

I made the mistake of installing CURRENT on my file server at home this morning 
and thought I could just boot the old kernel, do a zfs rollback, then continue 
on my merry way.

Turns out I was horribly wrong.

In addition to colors added to the boot loader (h shiny!!!), it appears the 
loading kernels with the load sub command from zfs pools does not work (load 
kernel.old, boot -s kernel.old, etc). Period. It works just fine with my 
stable/9 kernel/userland, but not the CURRENT one.

Please fix this; I hate having to resort to grabbing install media to have to 
fix my machines, and I'm sure you're going to have other devs and users jump 
down your throat about this.

Thanks..
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Early drop to debugger with DEBUG_MEMGUARD

[Jeff Roberson]

On Tue, 13 Aug 2013, Jeff Roberson wrote:


On Mon, 12 Aug 2013, David Wolfskill wrote:


On Tue, Aug 13, 2013 at 08:29:44AM +0300, Konstantin Belousov wrote:

...
The r254025 indeed introduced the problem, and Davide pointed out you a
workaround for the assertion triggering.


Right; I tried one of those -- I hope I got it right...


Proper fix for the memguard requires a policy of M_NEXTFIT or like, to
avoid a reuse of the previous allocated range as long as possible.


That's why I passed a start address as a lower bound to vmem_xalloc.  I would 
like to eventually implement nextfit.




Ah.


But, you have some further issue even after the assertion was silenced,
isn't it ?


I will fix this today and do some stress tests with memguard on.  Sorry for 
the difficulty.


Please try 254308.  It is working for me.

Thanks,
Jeff



Thanks,
Jeff



Yes; please see
 for a copy
of the message that shows the resulting panic.  (Or see previous
messages i this thread, if that's easier.)  It looks (from my naive
perspective) as if mti_zone hadn't been initialized (properly?  at
all?).

In any case, I remain willing to test, subject to Internet connectivity
flakiness where I am now and other demands on my time.

Peace,
david
--
David H. Wolfskill  da...@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.




___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: panic: UMA: Increase vm.boot_pages with 32 CPUs

[Jeff Roberson]

On Mon, 12 Aug 2013, Colin Percival wrote:


Hi all,

A HEAD@254238 kernel fails to boot in EC2 with

panic: UMA: Increase vm.boot_pages

on 32-CPU instances.  Instances with up to 16 CPUs boot fine.

I know there has been some mucking about with VM recently -- anyone want
to claim this, or should I start doing a binary search?


It's not any one commit really, just creeping demand for more pages before 
the VM can get started.  I would suggest making boot pages scale with 
MAXCPU.  Or just raising it as the panic suggests.  We could rewrite the 
way that the vm gets these early pages but it's a lot of work and 
typically people just bump it and forget about it.


Thanks,
Jeff



--
Colin Percival
Security Officer Emeritus, FreeBSD | The power to serve
Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid


___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Early drop to debugger with DEBUG_MEMGUARD

[Jeff Roberson]

On Mon, 12 Aug 2013, David Wolfskill wrote:


On Tue, Aug 13, 2013 at 08:29:44AM +0300, Konstantin Belousov wrote:

...
The r254025 indeed introduced the problem, and Davide pointed out you a
workaround for the assertion triggering.


Right; I tried one of those -- I hope I got it right...


Proper fix for the memguard requires a policy of M_NEXTFIT or like, to
avoid a reuse of the previous allocated range as long as possible.


That's why I passed a start address as a lower bound to vmem_xalloc.  I 
would like to eventually implement nextfit.




Ah.


But, you have some further issue even after the assertion was silenced,
isn't it ?


I will fix this today and do some stress tests with memguard on.  Sorry 
for the difficulty.


Thanks,
Jeff



Yes; please see
 for a copy
of the message that shows the resulting panic.  (Or see previous
messages i this thread, if that's easier.)  It looks (from my naive
perspective) as if mti_zone hadn't been initialized (properly?  at
all?).

In any case, I remain willing to test, subject to Internet connectivity
flakiness where I am now and other demands on my time.

Peace,
david
--
David H. Wolfskill  da...@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.


___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: quick hack to support "option VIMAGE" on USB Ethernet

[Craig Rodrigues]

On Mon, Aug 12, 2013 at 8:57 PM, YAMAMOTO Shigeru  wrote:

>
> My try is,
> 1) I try to enable "option VIMAGE" at r254236@HEAD.
> It causes panic at accessing V_if_index in ifindex_alloc_locked().
>

Can you provide the kernel backtrace for this panic?
It would be interesting to see where we need to initialize currvnet for USB
Ethernet.
I thought we already handled that case in subr_bus.c

--
Craig
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Hang with nvidia-driver

[Mark Johnston]

On Tue, Aug 13, 2013 at 2:37 PM, Alex  wrote:

> Hi. I just upgraded to revision 254271 and am experiencing a hang when slim
> starts. The monitor goes blank (no signal) and the fans increase in speed,
> suggesting high CPU usage. I have a GeForce GT 440. As suggested on the
> forums, I tried setting "machdep.disable_mtrrs=1" at the boot loader, but
> this did not help.
>
> Does anyone have any advice?
>
> Thanks,
> Alex
>

I ran into a similar problem a few days ago. Applying the nvidia-driver
Makefile
patch from the follow-ups in the PR below and rebuilding the driver fixed
the
problem for me:

http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/181144
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Hang with nvidia-driver

[Matthew Seaman]

On 13/08/2013 19:37, Alex wrote:
> Hi. I just upgraded to revision 254271 and am experiencing a hang when slim
> starts. The monitor goes blank (no signal) and the fans increase in speed,
> suggesting high CPU usage. I have a GeForce GT 440. As suggested on the
> forums, I tried setting "machdep.disable_mtrrs=1" at the boot loader, but
> this did not help.
> 
> Does anyone have any advice?

I saw the same symptoms with a recent update to x11/nvidia-driver.

Are you starting slim from /etc/ttys ?  What fixed it for me was to
scrap that and use the rc.d script to start slim.

Cheers,

Matthew

-- 
Dr Matthew J Seaman MA, D.Phil.
PGP: http://www.infracaninophile.co.uk/pgpkey




signature.asc
Description: OpenPGP digital signature

Hang with nvidia-driver

[Alex]

Hi. I just upgraded to revision 254271 and am experiencing a hang when slim
starts. The monitor goes blank (no signal) and the fans increase in speed,
suggesting high CPU usage. I have a GeForce GT 440. As suggested on the
forums, I tried setting "machdep.disable_mtrrs=1" at the boot loader, but
this did not help.

Does anyone have any advice?

Thanks,
Alex
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Positional arguments/load command broken in boot loader; cannot load old kernel

[Xin Li]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 08/13/13 09:36, Garrett Cooper wrote:
> I made the mistake of installing CURRENT on my file server at home 
> this morning and thought I could just boot the old kernel, do a
> zfs rollback, then continue on my merry way.
> 
> Turns out I was horribly wrong.
> 
> In addition to colors added to the boot loader (h shiny!!!),
> it appears the loading kernels with the load sub command from zfs
> pools does not work (load kernel.old, boot -s kernel.old, etc).
> Period. It works just fine with my stable/9 kernel/userland, but
> not the CURRENT one.

Don't work -- how?  I rebuild my laptop daily and does not see that
and I don't see a way Devin's changes could possibility cause problems
like this.

BTW since this sounds like a ZFS related issue -- did you do a 'zpool
upgrade' without updating loader or boot block and used some new features?

Cheers,
- -- 
Xin LI https://www.delphij.net/
FreeBSD - The Power to Serve!   Live free or die
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.20 (FreeBSD)

iQEcBAEBCgAGBQJSCmmWAAoJEG80Jeu8UPuztf8H/3Ya4U7YVsPlNR6cnGMMFeTB
LU3rXeQ0Eir+Tv2aQ1vh4/4HvA/iOI33/eRZEJo3tx0B+HgCNQbnECT5I1DfbO2I
Oh0BTSVWWF9ovvkFGnqbOr+XITWbYJafI4M046DgS3HjfhhO1FmHvuyfdW457gKs
UvHw3XEHyl3E4j/D5y1j7lJ0uQ/Jk5rjNKXylo/saFPrK4bb6NiRm+KH9NYm1qMD
PTx90HoAL0fEfJDutQ99zyTSspoCq13zU/rYEkzxVhqp2Eb8NYvEs9yElYYfFY+O
0FqTPf9MqZpLmtqaVSCmg9sZ5Krfl0VyRyLQwPUbuiNIolEwojoYsQma+ex56N0=
=jkdf
-END PGP SIGNATURE-
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Panic - ffs_valloc: dup alloc

[Chris Torek]

For what (little :-) ) it's worth, I got bit by this too.  Ultimately it
boils down to the problem that once the on-disk file system is sufficiently
broken, the journal doesn't have enough information for fsck to even detect
the problem, much less fix it.

(In my case the problem most likely was created by a bad bit in RAM.  That
particular hardware has no ECC.)

It seems to me that certain UFS panics (including "dup alloc", which was
the one getting me too if I remember right) should poison the journal to
force a full fsck.  This won't necessarily solve everything, but it would
at least carry the problem detection forward from the kernel into fsck...

Chris
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"