Re: m4 still broken on gcc platforms

[John Hay]

On Thu, Jul 31, 2014 at 08:15:32AM +, Bjoern A. Zeeb wrote:
> Hi,
> 
> I am still seeing this with arm/power/sparc/mips.  Can somene please fix it?

Did this get fixed because I still see it on -current while trying to
build armeb for the AVILA and CAMBRIA boards.

Regards

John
-- 
John Hay -- j...@meraka.csir.co.za / j...@meraka.org.za

> 
> 
> 
> ===> usr.bin/m4/tests (all)
> cc1: warnings being treated as errors
> /scratch/tmp/bz/head.svn/usr.bin/m4/misc.c: In function 'm4errx':
> /scratch/tmp/bz/head.svn/usr.bin/m4/misc.c:268: warning: declaration of 
> 'eval' shadows a global declaration
> /scratch/tmp/bz/head.svn/usr.bin/m4/extern.h:40: warning: shadowed 
> declaration is here
> --- misc.o ---
> *** [misc.o] Error code 1
> 
> bmake: stopped in /scratch/tmp/bz/head.svn/usr.bin/m4
> cc1: warnings being treated as errors
> /scratch/tmp/bz/head.svn/usr.bin/m4/lib/ohash.c: In function 'ohash_remove':
> /scratch/tmp/bz/head.svn/usr.bin/m4/lib/ohash.c:123: warning: cast discards 
> qualifiers from pointer target type
> /scratch/tmp/bz/head.svn/usr.bin/m4/lib/ohash.c: In function 'ohash_find':
> /scratch/tmp/bz/head.svn/usr.bin/m4/lib/ohash.c:144: warning: cast discards 
> qualifiers from pointer target type
> /scratch/tmp/bz/head.svn/usr.bin/m4/lib/ohash.c: In function 'ohash_next':
> /scratch/tmp/bz/head.svn/usr.bin/m4/lib/ohash.c:183: warning: cast discards 
> qualifiers from pointer target type
> --- ohash.o ---
> *** [ohash.o] Error code 1
> 
> bmake: stopped in /scratch/tmp/bz/head.svn/usr.bin/m4
> --- all_subdir_m4 ---
> *** [all_subdir_m4] Error code 1
> 
> bmake: stopped in /scratch/tmp/bz/head.svn/usr.bin
> ===> usr.bin/mail (all)
> 
> 
> ? 
> Bjoern A. Zeeb "Come on. Learn, goddamn it.", WarGames, 1983
> 

___
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: m4 still broken on gcc platforms

[Baptiste Daroussin]

On Thu, Aug 07, 2014 at 10:15:51AM +0200, John Hay wrote:
> On Thu, Jul 31, 2014 at 08:15:32AM +, Bjoern A. Zeeb wrote:
> > Hi,
> > 
> > I am still seeing this with arm/power/sparc/mips.  Can somene please fix it?
> 
> Did this get fixed because I still see it on -current while trying to
> build armeb for the AVILA and CAMBRIA boards.
> 
It has ben fixed last week

regards,
Bapt


pgptZfuwQg_0V.pgp
Description: PGP signature

Re: m4 still broken on gcc platforms

[John Hay]

On Thu, Aug 07, 2014 at 10:23:46AM +0200, Baptiste Daroussin wrote:
> On Thu, Aug 07, 2014 at 10:15:51AM +0200, John Hay wrote:
> > On Thu, Jul 31, 2014 at 08:15:32AM +, Bjoern A. Zeeb wrote:
> > > Hi,
> > > 
> > > I am still seeing this with arm/power/sparc/mips.  Can somene please fix 
> > > it?
> > 
> > Did this get fixed because I still see it on -current while trying to
> > build armeb for the AVILA and CAMBRIA boards.
> > 
> It has ben fixed last week

It is still broken for me. Maybe it is my environment. The last time I have
updated my source tree was about 2 weeks ago and with that I could build
working AVILA and CAMBRIA boards. I have updated now so that I could get
the interrupt fixes that Ian committed a few hours ago. My tree is at
svn 269656.

The machine I am building on is running 10-stable from around 30 March,
if that makes a difference.

Regards

John
-- 
John Hay -- j...@meraka.csir.co.za / j...@meraka.org.za
___
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: m4 still broken on gcc platforms

[Konstantin Belousov]

On Thu, Aug 07, 2014 at 10:23:46AM +0200, Baptiste Daroussin wrote:
> On Thu, Aug 07, 2014 at 10:15:51AM +0200, John Hay wrote:
> > On Thu, Jul 31, 2014 at 08:15:32AM +, Bjoern A. Zeeb wrote:
> > > Hi,
> > > 
> > > I am still seeing this with arm/power/sparc/mips.  Can somene please fix 
> > > it?
> > 
> > Did this get fixed because I still see it on -current while trying to
> > build armeb for the AVILA and CAMBRIA boards.
> > 
> It has ben fixed last week

The build is still broken.  I did not looked too closely, but it seems
related.

/scratch/tmp/kib/src/usr.bin/m4/misc.c: In function 'm4errx':
/scratch/tmp/kib/src/usr.bin/m4/misc.c:268: warning: declaration of 'eval' 
shadows a global declaration
/scratch/tmp/kib/src/usr.bin/m4/extern.h:40: warning: shadowed declaration is 
here



pgp0RzLhyLcGd.pgp
Description: PGP signature

Re: m4 still broken on gcc platforms

[Baptiste Daroussin]

On Thu, Aug 07, 2014 at 12:25:57PM +0300, Konstantin Belousov wrote:
> On Thu, Aug 07, 2014 at 10:23:46AM +0200, Baptiste Daroussin wrote:
> > On Thu, Aug 07, 2014 at 10:15:51AM +0200, John Hay wrote:
> > > On Thu, Jul 31, 2014 at 08:15:32AM +, Bjoern A. Zeeb wrote:
> > > > Hi,
> > > > 
> > > > I am still seeing this with arm/power/sparc/mips.  Can somene please 
> > > > fix it?
> > > 
> > > Did this get fixed because I still see it on -current while trying to
> > > build armeb for the AVILA and CAMBRIA boards.
> > > 
> > It has ben fixed last week
> 
> The build is still broken.  I did not looked too closely, but it seems
> related.
> 
> /scratch/tmp/kib/src/usr.bin/m4/misc.c: In function 'm4errx':
> /scratch/tmp/kib/src/usr.bin/m4/misc.c:268: warning: declaration of 'eval' 
> shadows a global declaration
> /scratch/tmp/kib/src/usr.bin/m4/extern.h:40: warning: shadowed declaration is 
> here
> 

Oh right I broke this yesterday

Let me fix

regards,
Bapt


pgpW4XBf39mYU.pgp
Description: PGP signature

Re: panic: aatpic_assign_cpu: bad cookie [Was: Build machine OK; laptop panics @r269515]

[Roger Pau Monné]

On 06/08/14 23:07, David Wolfskill wrote:
> On Wed, Aug 06, 2014 at 10:48:32PM +0200, Trond Endrestøl wrote:
>> ...
>> Reverting r269510 did the trick, i.e.:
>>
>> cd /usr/src && svn up && svn diff -r 269510:269509 | patch
>>
>> My i386 head VM is running smoothly with r269641M, with M meaning only 
>> the above reversal.
>> ...
> 
> Works for me, as well -- thanks!
> 
> FreeBSD 11.0-CURRENT #1333  r269622M/269622:1100028: Wed Aug  6 14:01:30 PDT 
> 2014
> 
> (I'll be providing more details to royger@ et al. in a moment.)

I think I've found the issue, but since I'm not able to reproduce it,
could someone try the following patch? (without r269510 reverted).

Thanks, Roger.

>From 91264290520a6a6eee6cd35d05a65e2dd0e61dc8 Mon Sep 17 00:00:00 2001
From: Roger Pau Monne 
Date: Thu, 7 Aug 2014 12:05:10 +0200
Subject: [PATCH] atpic: make sure atpic_init is called after IO APIC
 initialization

After r269510 the IO APIC and ATPIC initialization is done at the same
order, which means atpic_init can be called before the IO APIC has
been initalized. In that case the ATPIC will take over the interrupt
sources, preventing the IO APIC from registering them.

Reported by: David Wolfskill 
Sponsored by: Citrix Systems R&D
---
 sys/x86/isa/atpic.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/sys/x86/isa/atpic.c b/sys/x86/isa/atpic.c
index 6ce6d1a..e3fdb34 100644
--- a/sys/x86/isa/atpic.c
+++ b/sys/x86/isa/atpic.c
@@ -524,7 +524,7 @@ atpic_init(void *dummy __unused)
intr_register_source(&ai->at_intsrc);
}
 }
-SYSINIT(atpic_init, SI_SUB_INTR, SI_ORDER_SECOND + 1, atpic_init, NULL);
+SYSINIT(atpic_init, SI_SUB_INTR, SI_ORDER_FOURTH, atpic_init, NULL);
 
 void
 atpic_handle_intr(u_int vector, struct trapframe *frame)
-- 
1.7.7.5 (Apple Git-26)

___
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: aatpic_assign_cpu: bad cookie [Was: Build machine OK; laptop panics @r269515]

[Trond Endrestøl]

On Thu, 7 Aug 2014 13:32+0200, Roger Pau Monné wrote:

> On 06/08/14 23:07, David Wolfskill wrote:
> > On Wed, Aug 06, 2014 at 10:48:32PM +0200, Trond Endrestøl wrote:
> >> ...
> >> Reverting r269510 did the trick, i.e.:
> >>
> >> cd /usr/src && svn up && svn diff -r 269510:269509 | patch
> >>
> >> My i386 head VM is running smoothly with r269641M, with M meaning only 
> >> the above reversal.
> >> ...
> > 
> > Works for me, as well -- thanks!
> > 
> > FreeBSD 11.0-CURRENT #1333  r269622M/269622:1100028: Wed Aug  6 14:01:30 
> > PDT 2014
> > 
> > (I'll be providing more details to royger@ et al. in a moment.)
> 
> I think I've found the issue, but since I'm not able to reproduce it,
> could someone try the following patch? (without r269510 reverted).

I'll try it once I'm back home, in about 3 hours.

> Thanks, Roger.

NP.

-- 
+---++
| Vennlig hilsen,   | Best regards,  |
| Trond Endrestøl,  | Trond Endrestøl,   |
| IT-ansvarlig, | System administrator,  |
| Fagskolen Innlandet,  | Gjøvik Technical College, Norway,  |
| tlf. mob.   952 62 567,   | Cellular...: +47 952 62 567,   |
| sentralbord 61 14 54 00.  | Switchboard: +47 61 14 54 00.  |
+---++
___
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"

libthr and main thread stack size

[Ivan A. Kosarev]

Hello,

According to libthr's thr_init.c (the 9.2 version) init_main_thread() 
allocates s.c. "red zone" below the main stack in order to protect other 
stacks. The size of the main stack is determined by the 
_thr_stack_initial variable that is declared extern though it doesn't 
seem it can be changed. The value of the variable is set to 4M on 64-bit 
platforms which is obviously not sufficient for the most of real programs.


Can anyone please confirm that there is no way to increase the stack 
size for the main thread and thus any program linked against libthr has 
only a few megabytes of stack memory for its main thread--whatever the 
system stack size (ulimit -s) is set to?


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"

Build failed in Jenkins: FreeBSD_HEAD #1189

[jenkins-admin]

See 

Changes:

[roberto] 10 has a new flex (2.5.37) and the config.h for unbound has been 
updated to
take this into account. Alas it breaks source upgrade from any version of
9 because flex is not built as a bootstrap-tools (it would be for older
versions).

That means "libunbound/configlexer.c" is built with the old flex but using
config.h for the new one. Build is thus broken going from 9.* to 10.

Make flex a bootstrap-tools entry if host is less than 133 to take into
account the flex update in 10.

Tested on both 9.2-RC3 and 9.3 by myself and dim@. Running buildworld in
head but as both 10 and 11 has the new flex, it will not matter.

Reviewed by:imp
Approved by:des, imp
MFC after:  1 week
Phabric:D554

[ae] Use cpuset_setithread() to apply cpu mask to taskq threads.

Sponsored by:   Yandex LLC

[bapt] Lower warnings again to 3 the right thing would be to fix the warnings
which will be done by discussing with upstream I want the m4 code to stay
as close as possible to upstream.

--
[...truncated 269369 lines...]
--- rt2661.o ---
ctfconvert -L VERSION -g rt2661.o
--- if_sn.o ---
cc  -c -O2 -pipe -fno-strict-aliasing  -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 -Wno-error-unused-function   -nostdinc  -I. 
-I 
-I 
-I 
-D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h  
-fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel 
-mno-red-zone -mno-mmx -mno-sse -msoft-float  -fno-asynchronous-unwind-tables 
-ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror  

--- syscons.o ---
cc  -c -O2 -pipe -fno-strict-aliasing  -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 -Wno-error-unused-function   -nostdinc  -I. 
-I 
-I 
-I 
-D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h  
-fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel 
-mno-red-zone -mno-mmx -mno-sse -msoft-float  -fno-asynchronous-unwind-tables 
-ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror  

--- randomdev.o ---
ctfconvert -L VERSION -g randomdev.o
--- uart_dbg.o ---
cc  -c -O2 -pipe -fno-strict-aliasing  -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 -Wno-error-unused-function   -nostdinc  -I. 
-I 
-I 
-I 
-D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h  
-fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel 
-mno-red-zone -mno-mmx -mno-sse -msoft-float  -fno-asynchronous-unwind-tables 
-ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror  

ctfconvert -L VERSION -g uart_dbg.o
--- uart_subr.o ---
cc  -c -O2 -pipe -fno-strict-aliasing  -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 -Wno-error-unused-function   -nostdinc  -I. 
-I 
-I 
-I 
-D_KERNEL

Re: panic: aatpic_assign_cpu: bad cookie [Was: Build machine OK; laptop panics @r269515]

[David Wolfskill]

On Thu, Aug 07, 2014 at 01:32:45PM +0200, Roger Pau Monné wrote:
> ...
> I think I've found the issue, but since I'm not able to reproduce it,
> could someone try the following patch? (without r269510 reverted).
> ...

That worked for me; thanks!

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Taliban: Evil cowards with guns afraid of truth from a 14-year old girl.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


pgp0orhqYlMxi.pgp
Description: PGP signature

Re: panic: aatpic_assign_cpu: bad cookie [Was: Build machine OK; laptop panics @r269515]

[Trond Endrestøl]

On Thu, 7 Aug 2014 07:49-0700, David Wolfskill wrote:

> On Thu, Aug 07, 2014 at 01:32:45PM +0200, Roger Pau Monné wrote:
> > ...
> > I think I've found the issue, but since I'm not able to reproduce it,
> > could someone try the following patch? (without r269510 reverted).
> > ...
> 
> That worked for me; thanks!

+1

Verbose dmesg for i386 head r269666M with 
http://ximalas.info/~trond/atpic_assign_cpu/sys-x86-isa-atpic.c.patch 
as the sole modification is available at 
http://ximalas.info/~trond/atpic_assign_cpu/dmesg-verbose-head-i386-r269666M.txt

-- 
+---++
| Vennlig hilsen,   | Best regards,  |
| Trond Endrestøl,  | Trond Endrestøl,   |
| IT-ansvarlig, | System administrator,  |
| Fagskolen Innlandet,  | Gjøvik Technical College, Norway,  |
| tlf. mob.   952 62 567,   | Cellular...: +47 952 62 567,   |
| sentralbord 61 14 54 00.  | Switchboard: +47 61 14 54 00.  |
+---++
___
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"

Jenkins build is back to normal : FreeBSD_HEAD #1190

[jenkins-admin]

See 

___
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"

loader lszfs command

[dteske]

Hi,

People have been pestering me to update the Forth code to present
a menu of ZFS datasets (*cough* boot environments *cough*).

Would love to, but existing code seems broken.

Can *anybody* produce meaningful output from the following?

http://svnweb.freebsd.org/base?view=revision&revision=241284

All I get on every system I've tried (multiple versions, including HEAD)
produce the following:

 OK lszfs zroot
ZFS: i/o error - all block copies unavailable
operation not permitted

It's really hard for me to start with something that's broken. Can
I get confirmation that this doesn't appear to be working as intended?
If so, I'll go ahead and try to fix it, but need to confirm that I'm ( a )
not
crazy and ( b ) seeing the same thing everybody else is seeing.
-- 
Devin

___
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: loader lszfs command

[Sean Bruno]

On Thu, 2014-08-07 at 14:17 -0700, dte...@freebsd.org wrote:
> Hi,
> 
> People have been pestering me to update the Forth code to present
> a menu of ZFS datasets (*cough* boot environments *cough*).
> 
> Would love to, but existing code seems broken.
> 
> Can *anybody* produce meaningful output from the following?
> 
> http://svnweb.freebsd.org/base?view=revision&revision=241284
> 
> All I get on every system I've tried (multiple versions, including HEAD)
> produce the following:
> 
>  OK lszfs zroot
> ZFS: i/o error - all block copies unavailable
> operation not permitted
> 
> It's really hard for me to start with something that's broken. Can
> I get confirmation that this doesn't appear to be working as intended?
> If so, I'll go ahead and try to fix it, but need to confirm that I'm ( a )
> not
> crazy and ( b ) seeing the same thing everybody else is seeing.


Hrm ... this seems to work for me.  (fairly recent 11-current)

OK lszfs zroot
$MOS
$FREE
$ORIGIN
tmp
home
usr
var
tftpboot
poudriere
OK

___
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: loader lszfs command

[Garrett Cooper]

Hi Devin!

On Thu, Aug 7, 2014 at 4:15 PM, Sean Bruno  wrote:
> On Thu, 2014-08-07 at 14:17 -0700, dte...@freebsd.org wrote:
>> Hi,
>>
>> People have been pestering me to update the Forth code to present
>> a menu of ZFS datasets (*cough* boot environments *cough*).
>>
>> Would love to, but existing code seems broken.
>>
>> Can *anybody* produce meaningful output from the following?
>>
>> http://svnweb.freebsd.org/base?view=revision&revision=241284
>>
>> All I get on every system I've tried (multiple versions, including HEAD)
>> produce the following:
>>
>>  OK lszfs zroot
>> ZFS: i/o error - all block copies unavailable
>> operation not permitted
>>
>> It's really hard for me to start with something that's broken. Can
>> I get confirmation that this doesn't appear to be working as intended?
>> If so, I'll go ahead and try to fix it, but need to confirm that I'm ( a )
>> not
>> crazy and ( b ) seeing the same thing everybody else is seeing.
>
>
> Hrm ... this seems to work for me.  (fairly recent 11-current)
>
> OK lszfs zroot
> $MOS
> $FREE
> $ORIGIN
> tmp
> home
> usr
> var
> tftpboot
> poudriere
> OK

Is the installed version you have in synch with the kernel and
zpool version for boot0, gptzfsboot, etc?
Cheers!
-Garrett
___
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: loader lszfs command

[dteske]

> -Original Message-
> From: Garrett Cooper [mailto:yaneurab...@gmail.com]
> Sent: Thursday, August 7, 2014 4:29 PM
> To: sbr...@freebsd.org
> Cc: dte...@freebsd.org; freebsd-current
> Subject: Re: loader lszfs command
> 
> Hi Devin!
> 
> On Thu, Aug 7, 2014 at 4:15 PM, Sean Bruno 
> wrote:
> > On Thu, 2014-08-07 at 14:17 -0700, dte...@freebsd.org wrote:
> >> Hi,
> >>
> >> People have been pestering me to update the Forth code to present
> >> a menu of ZFS datasets (*cough* boot environments *cough*).
> >>
> >> Would love to, but existing code seems broken.
> >>
> >> Can *anybody* produce meaningful output from the following?
> >>
> >> http://svnweb.freebsd.org/base?view=revision&revision=241284
> >>
> >> All I get on every system I've tried (multiple versions, including HEAD)
> >> produce the following:
> >>
> >>  OK lszfs zroot
> >> ZFS: i/o error - all block copies unavailable
> >> operation not permitted
> >>
> >> It's really hard for me to start with something that's broken. Can
> >> I get confirmation that this doesn't appear to be working as intended?
> >> If so, I'll go ahead and try to fix it, but need to confirm that I'm ( a )
> >> not
> >> crazy and ( b ) seeing the same thing everybody else is seeing.
> >
> >
> > Hrm ... this seems to work for me.  (fairly recent 11-current)
> >
> > OK lszfs zroot
> > $MOS
> > $FREE
> > $ORIGIN
> > tmp
> > home
> > usr
> > var
> > tftpboot
> > poudriere
> > OK
> 
> Is the installed version you have in synch with the kernel and
> zpool version for boot0, gptzfsboot, etc?

Not sure how the kernel factors into all this, but I have a
10.0-RC1 system.

Some info:

devin@scribe10 ~ $ uname -a
FreeBSD scribe10 10.0-RC1 FreeBSD 10.0-RC1 #0 r259068: Sat Dec  7 17:45:20 UTC 
2013 r...@snap.freebsd.org:/usr/obj/usr/src/sys/GENERIC  amd64

devin@scribe10 ~ $ zpool get version
NAME  PROPERTY  VALUESOURCE
bootpool  version   -default
zroot version   -default

devin@scribe10 ~ $ zfs get version
NAMEPROPERTY  VALUESOURCE
bootpoolversion   5-
zroot   version   5-
zroot/ROOT  version   5-
zroot/ROOT/default  version   5-
zroot/ROOT/default@2014-08-04-19:38:24  version   5-
zroot/ROOT/test version   5-
zroot/tmp   version   5-
zroot/usr   version   5-
zroot/usr/home  version   5-
zroot/usr/ports version   5-
zroot/usr/ports.RELEASE_9_1_0   version   5-
zroot/var   version   5-
zroot/var/crash version   5-
zroot/var/log   version   5-
zroot/var/mail  version   5-
zroot/var/tmp   version   5-

Maybe if I update boot0 to a HEAD copy maybe?
Have already tried updating /boot/loader with no change.
-- 
Devin

___
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: loader lszfs command

[Peter Wemm]

On Thursday 07 August 2014 16:42:42 dte...@freebsd.org wrote:

> Maybe if I update boot0 to a HEAD copy maybe?
> Have already tried updating /boot/loader with no change.

-r-xr-xr-x  1 root  wheel  262144 Aug  1 12:24 /boot/loader*
-r-xr-xr-x  1 root  wheel  299008 Aug  1 12:24 /boot/zfsloader*

It sounds like something is wrong with your install.

BTW; boot0 isn't involved - if you've got that far, boot0 / gptzfsboot have 
already done their part.
-- 
Peter Wemm - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com; KI6FJV
UTF-8: for when a ' or ... just won\342\200\231t do\342\200\246

signature.asc
Description: This is a digitally signed message part.

Re: loader lszfs command

[Garrett Cooper]

On Thu, Aug 7, 2014 at 4:42 PM,   wrote:
>
>> -Original Message-
>> From: Garrett Cooper [mailto:yaneurab...@gmail.com]
>> Sent: Thursday, August 7, 2014 4:29 PM
>> To: sbr...@freebsd.org
>> Cc: dte...@freebsd.org; freebsd-current
>> Subject: Re: loader lszfs command
>>
>> Hi Devin!
>>
>> On Thu, Aug 7, 2014 at 4:15 PM, Sean Bruno 
>> wrote:
>> > On Thu, 2014-08-07 at 14:17 -0700, dte...@freebsd.org wrote:
>> >> Hi,
>> >>
>> >> People have been pestering me to update the Forth code to present
>> >> a menu of ZFS datasets (*cough* boot environments *cough*).
>> >>
>> >> Would love to, but existing code seems broken.
>> >>
>> >> Can *anybody* produce meaningful output from the following?
>> >>
>> >> http://svnweb.freebsd.org/base?view=revision&revision=241284
>> >>
>> >> All I get on every system I've tried (multiple versions, including HEAD)
>> >> produce the following:
>> >>
>> >>  OK lszfs zroot
>> >> ZFS: i/o error - all block copies unavailable
>> >> operation not permitted
>> >>
>> >> It's really hard for me to start with something that's broken. Can
>> >> I get confirmation that this doesn't appear to be working as intended?
>> >> If so, I'll go ahead and try to fix it, but need to confirm that I'm ( a )
>> >> not
>> >> crazy and ( b ) seeing the same thing everybody else is seeing.
>> >
>> >
>> > Hrm ... this seems to work for me.  (fairly recent 11-current)
>> >
>> > OK lszfs zroot
>> > $MOS
>> > $FREE
>> > $ORIGIN
>> > tmp
>> > home
>> > usr
>> > var
>> > tftpboot
>> > poudriere
>> > OK
>>
>> Is the installed version you have in synch with the kernel and
>> zpool version for boot0, gptzfsboot, etc?
>
> Not sure how the kernel factors into all this, but I have a
> 10.0-RC1 system.

I was asking for information to help determine whether or not the
loader could read the zpool metadata, because it's interesting why
things worked for Sean and not for you :).
Cheers!
-Garrett
___
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: libthr and main thread stack size

[Konstantin Belousov]

On Thu, Aug 07, 2014 at 04:18:12PM +0400, Ivan A. Kosarev wrote:
> Hello,
> 
> According to libthr's thr_init.c (the 9.2 version) init_main_thread() 
> allocates s.c. "red zone" below the main stack in order to protect other 
> stacks. The size of the main stack is determined by the 
> _thr_stack_initial variable that is declared extern though it doesn't 
> seem it can be changed. The value of the variable is set to 4M on 64-bit 
> platforms which is obviously not sufficient for the most of real programs.
> 
> Can anyone please confirm that there is no way to increase the stack 
> size for the main thread and thus any program linked against libthr has 
> only a few megabytes of stack memory for its main thread--whatever the 
> system stack size (ulimit -s) is set to?

Yes, there is no way to change the main thread stack clamping.
Could you provide a reasonable use case for the 4MB stack ?

Anyway, I somewhat sympathize to the idea to stop clamping the main
thread stack, and to not reuse it for other threads stack carving.
This also means that non-main threads stack allocator should stop
tracking the explicit location for the stacks and rely on vm mmap(2)
base selection instead.

I do not know the motivations why the current scheme of stacks allocation
was chosen.  The changes do not look too involved.


pgpG3kDj2mpfu.pgp
Description: PGP signature

Re: loader lszfs command

[Trond Endrestøl]

On Thu, 7 Aug 2014 14:17-0700, dte...@freebsd.org wrote:

> Hi,
> 
> People have been pestering me to update the Forth code to present
> a menu of ZFS datasets (*cough* boot environments *cough*).
> 
> Would love to, but existing code seems broken.
> 
> Can *anybody* produce meaningful output from the following?
> 
> http://svnweb.freebsd.org/base?view=revision&revision=241284
> 
> All I get on every system I've tried (multiple versions, including HEAD)
> produce the following:
> 
>  OK lszfs zroot
> ZFS: i/o error - all block copies unavailable
> operation not permitted
> 
> It's really hard for me to start with something that's broken. Can
> I get confirmation that this doesn't appear to be working as intended?
> If so, I'll go ahead and try to fix it, but need to confirm that I'm ( a )
> not
> crazy and ( b ) seeing the same thing everybody else is seeing.

A bit on the side, but more user friendly:

You should change the error message on line 335 to explain how to use 
lszfs, or add a "help lszfs" command.

Instead of merely complaining about "wrong number of arguments", how 
about stating something like "wrong number of arguments, need at least 
pool name"?

-- 
+---++
| Vennlig hilsen,   | Best regards,  |
| Trond Endrestøl,  | Trond Endrestøl,   |
| IT-ansvarlig, | System administrator,  |
| Fagskolen Innlandet,  | Gjøvik Technical College, Norway,  |
| tlf. mob.   952 62 567,   | Cellular...: +47 952 62 567,   |
| sentralbord 61 14 54 00.  | Switchboard: +47 61 14 54 00.  |
+---++
___
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"