date:20130104

Re: Problems in /usr/src

2013-01-04 Thread Super Bisquit

I did not know that ath_ahb was MIPS only. Why? I wanted the most/best
performance for my system's wireless.
Support for 5416 is there but the card is a 2413.

On Sat, Jan 5, 2013 at 12:03 AM, Adrian Chadd  wrote:
> ... ath_ahb is only needed for MIPS platforms. Why are you building it for 
> x86?
>
> Also, do you have the 5416 support option in your kernel?
>
>
>
> adrian
>
> On 4 January 2013 20:37, Super Bisquit  wrote:
>> In sys/modules/svr4 needs machine/_align.h to read
>> X86/include/_align.h, if that means anything.
>>
>> In sys/modules/ath_ahb: cc1: warnings being treated as errors
>> In file included from
>> /usr/src/sys/modules/ath_ahb/../../dev/ath/if_ath_ahb.c:61:
>> @/mips/atheros/ar71xxreg.h: In function 'ar71xx_ddr_flush':
>> @/mips/atheros/ar71xxreg.h:497: warning: implicit declaration of
>> function 'MIPS_PHYS_TO_KSEG1'
>> @/mips/atheros/ar71xxreg.h:497: warning: nested extern declaration of
>> 'MIPS_PHYS_TO_KSEG1' [-Wnested-externs]
>> *** Error code 1
>>
>> Stop in /usr/src/sys/modules/ath_ahb.
>> peoples#
>>
>>
>> In sys/modules/ath:fdiagnostics-show-option -c
>> /usr/src/sys/modules/ath/../../dev/ath/if_ath.c
>> /usr/src/sys/modules/ath/../../dev/ath/if_ath.c: In function 'ath_rx_proc':
>> /usr/src/sys/modules/ath/../../dev/ath/if_ath.c:3534: error: 'struct
>> ath_rx_status' has no member named 'rs_flags'
>> /usr/src/sys/modules/ath/../../dev/ath/if_ath.c:3536: error: 'struct
>> ath_rx_status' has no member named 'rs_flags'
>> /usr/src/sys/modules/ath/../../dev/ath/if_ath.c:3538: error: 'struct
>> ath_rx_status' has no member named 'rs_flags'
>> /usr/src/sys/modules/ath/../../dev/ath/if_ath.c:3540: error: 'struct
>> ath_rx_status' has no member named 'rs_flags'
>> /usr/src/sys/modules/ath/../../dev/ath/if_ath.c:3542: error: 'struct
>> ath_rx_status' has no member named 'rs_flags'
>> /usr/src/sys/modules/ath/../../dev/ath/if_ath.c:3544: error: 'struct
>> ath_rx_status' has no member named 'rs_flags'
>> /usr/src/sys/modules/ath/../../dev/ath/if_ath.c:3732: error: 'struct
>> ath_rx_status' has no member named 'rs_isaggr'
>> *** Error code 1
>>
>> Stop in /usr/src/sys/modules/ath.
>> peoples#
>>  Now sys/modules/ath_pci will build.
>>
>> When running make world or make buildworld  there is an error at
>> gnu/lib/libgcc.
>>
>> peoples# uname -a
>> FreeBSD peoples 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Tue Jan  3
>> 07:15:25 UTC 2012
>> r...@obrian.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC  i386
>> peoples#
>> ___
>> 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"
___
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: Problems in /usr/src

2013-01-04 Thread Adrian Chadd

... ath_ahb is only needed for MIPS platforms. Why are you building it for x86?

Also, do you have the 5416 support option in your kernel?



adrian

On 4 January 2013 20:37, Super Bisquit  wrote:
> In sys/modules/svr4 needs machine/_align.h to read
> X86/include/_align.h, if that means anything.
>
> In sys/modules/ath_ahb: cc1: warnings being treated as errors
> In file included from
> /usr/src/sys/modules/ath_ahb/../../dev/ath/if_ath_ahb.c:61:
> @/mips/atheros/ar71xxreg.h: In function 'ar71xx_ddr_flush':
> @/mips/atheros/ar71xxreg.h:497: warning: implicit declaration of
> function 'MIPS_PHYS_TO_KSEG1'
> @/mips/atheros/ar71xxreg.h:497: warning: nested extern declaration of
> 'MIPS_PHYS_TO_KSEG1' [-Wnested-externs]
> *** Error code 1
>
> Stop in /usr/src/sys/modules/ath_ahb.
> peoples#
>
>
> In sys/modules/ath:fdiagnostics-show-option -c
> /usr/src/sys/modules/ath/../../dev/ath/if_ath.c
> /usr/src/sys/modules/ath/../../dev/ath/if_ath.c: In function 'ath_rx_proc':
> /usr/src/sys/modules/ath/../../dev/ath/if_ath.c:3534: error: 'struct
> ath_rx_status' has no member named 'rs_flags'
> /usr/src/sys/modules/ath/../../dev/ath/if_ath.c:3536: error: 'struct
> ath_rx_status' has no member named 'rs_flags'
> /usr/src/sys/modules/ath/../../dev/ath/if_ath.c:3538: error: 'struct
> ath_rx_status' has no member named 'rs_flags'
> /usr/src/sys/modules/ath/../../dev/ath/if_ath.c:3540: error: 'struct
> ath_rx_status' has no member named 'rs_flags'
> /usr/src/sys/modules/ath/../../dev/ath/if_ath.c:3542: error: 'struct
> ath_rx_status' has no member named 'rs_flags'
> /usr/src/sys/modules/ath/../../dev/ath/if_ath.c:3544: error: 'struct
> ath_rx_status' has no member named 'rs_flags'
> /usr/src/sys/modules/ath/../../dev/ath/if_ath.c:3732: error: 'struct
> ath_rx_status' has no member named 'rs_isaggr'
> *** Error code 1
>
> Stop in /usr/src/sys/modules/ath.
> peoples#
>  Now sys/modules/ath_pci will build.
>
> When running make world or make buildworld  there is an error at
> gnu/lib/libgcc.
>
> peoples# uname -a
> FreeBSD peoples 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Tue Jan  3
> 07:15:25 UTC 2012
> r...@obrian.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC  i386
> peoples#
> ___
> 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"
___
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: clang 3.2 RC2 miscompiles libgcc?

2013-01-04 Thread Nathan Whitehorn

On 01/04/13 15:23, Konstantin Belousov wrote:
> On Fri, Jan 04, 2013 at 08:06:02PM +0100, Stefan Farfeleder wrote:
>> On Fri, Jan 04, 2013 at 08:14:38PM +0200, Konstantin Belousov wrote:
>>> On Fri, Jan 04, 2013 at 04:49:41PM +0100, Stefan Farfeleder wrote:
 Here's a minimal test case that reproduces the bug:

 $ cat throw-crash.cc
 #include 

 void f2(void) {
 std::string s;
 throw std::runtime_error("foo");
 }

 void f1(void) {
 f2();
 }

 int main(void) {
 try {
 std::string s1, s2;
 f1();
 return 0;
 } catch (const std::exception &) {
 return 1;
 }
 }
 $ g++ -O2 -finline-limit=0 throw-crash.cc 
 $ ./a.out 
 zsh: bus error (core dumped)  ./a.out
>>>
>>> What is the backtrace ?
>>> Compile the system libraries (ld-elf, libc, libgcc etc) with the
>>> debugging information and obtain the backtrace once more.
>>
>> I'm afraid the backtrace is not really interesting:
>>
>> Program received signal SIGBUS, Bus error.
>> std::string::_Rep::_M_dispose (this=0x7fffd62fe8, __a=@0x7fffd628)
>> at atomicity.h:69
>> 69  _Atomic_word __result = *__mem;
>> (gdb) bt
>> #0  std::string::_Rep::_M_dispose (this=0x7fffd62fe8, 
>> __a=@0x7fffd628)
>> at atomicity.h:69
>> #1  0x00080089d168 in ~basic_string (this=0x7fffd62fe8)
>> at basic_string.h:482
>> #2  0x00401038 in main () at throw-crash.cc:16
>>
>> I think the stack is somehow corrupted after the exception was
>> performed. As with the original test case, loading an old libgcc_s.so.1
>> instead makes the program run correctly.
>>
>> It seems the std::string destructor is called with an invalid this
>> pointer for s2:
>>
>> (gdb) r
>> Starting program: /usr/home/stefan/scratch/a.out 
>>
>> Breakpoint 1, main () at throw-crash.cc:12
>> 12  int main(void) {
>> (gdb) b _Unwind_RaiseException
>> Breakpoint 2 at 0x800d420b4
>> (gdb) c
>> Continuing.
>>
>> Breakpoint 2, 0x000800d420b4 in _Unwind_RaiseException ()
>>from /lib/libgcc_s.so.1
>> (gdb) f 2
>> #2  0x00400f51 in f2 () at throw-crash.cc:5
>> 5   throw std::runtime_error("foo");
>> (gdb) p &s
>> $1 = (string *) 0x7fffd600
>> (gdb) up
>> #3  0x00400fe2 in main () at throw-crash.cc:15
>> 15  f1();
>> (gdb) p &s1
>> $2 = (string *) 0x7fffd650
>> (gdb) p &s2
>> $3 = (string *) 0x7fffd640
>>   
>> (gdb) b 'std::basic_string, 
>> std::allocator >::~basic_string()' 
>> Breakpoint 3 at 0x80089d154: file basic_string.h, line 482.
>> (gdb) c
>> Continuing.
>>
>> Breakpoint 3, ~basic_string (this=0x7fffd600) at basic_string.h:279
>> 279   _M_data() const
>> (gdb) c
>> Continuing.
>>
>> Breakpoint 3, ~basic_string (this=0x7fffd640) at basic_string.h:279
>> 279   _M_data() const
>> (gdb) c
>> Continuing.
>>
>> Breakpoint 3, ~basic_string (this=0x7fffd60f) at basic_string.h:279
>> 
>> 279   _M_data() const
>>
>> So, the address of s2 is 0x7fffd640, but the dtor is called with
>> 0x7fffd60f which is also very unaligned. I think this is the reason
>> for the crash.
> 
> Thank you for digging more.
> 
> In fact, it is more likely that there is some bug or incompatibility in
> c++ unwinder than in the libgcc itself, but as you noted, a compiler bug
> is also possible.
> 
> Anyway, I was mostly looking could the backtrace starts in rtld. Rtld bug
> also cannot be excluded at this stage, but it not much likely.
> 

If this is the same bug I was seeing, recompiling only the file
unwind-dw2.c in libgcc with GCC/old clang, leaving everything else the
same, fixed everything. This would lead me to suspect an error in one of
the many __builtins called by unwind-dw2.c.
-Nathan
___
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: clang 3.2 RC2 miscompiles libgcc?

2013-01-04 Thread Mark Atkinson

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 01/04/2013 12:23, Konstantin Belousov wrote:
> On Fri, Jan 04, 2013 at 08:06:02PM +0100, Stefan Farfeleder wrote:
>> On Fri, Jan 04, 2013 at 08:14:38PM +0200, Konstantin Belousov
>> wrote:
>>> On Fri, Jan 04, 2013 at 04:49:41PM +0100, Stefan Farfeleder
>>> wrote:
 Here's a minimal test case that reproduces the bug:
 
 $ cat throw-crash.cc #include 
 
 void f2(void) { std::string s; throw
 std::runtime_error("foo"); }
 
 void f1(void) { f2(); }
 
 int main(void) { try { std::string s1, s2; f1(); return 0; }
 catch (const std::exception &) { return 1; } } $ g++ -O2
 -finline-limit=0 throw-crash.cc $ ./a.out zsh: bus error
 (core dumped)  ./a.out
>>> 
>>> What is the backtrace ? Compile the system libraries (ld-elf,
>>> libc, libgcc etc) with the debugging information and obtain the
>>> backtrace once more.
>> 
>> I'm afraid the backtrace is not really interesting:
>> 
>> Program received signal SIGBUS, Bus error. 
>> std::string::_Rep::_M_dispose (this=0x7fffd62fe8,
>> __a=@0x7fffd628) at atomicity.h:69 69  _Atomic_word
>> __result = *__mem; (gdb) bt #0  std::string::_Rep::_M_dispose
>> (this=0x7fffd62fe8, __a=@0x7fffd628) at atomicity.h:69 #1
>> 0x00080089d168 in ~basic_string (this=0x7fffd62fe8) at
>> basic_string.h:482 #2  0x00401038 in main () at
>> throw-crash.cc:16
>> 
>> I think the stack is somehow corrupted after the exception was 
>> performed. As with the original test case, loading an old
>> libgcc_s.so.1 instead makes the program run correctly.
>> 
>> It seems the std::string destructor is called with an invalid
>> this pointer for s2:
>> 
>> (gdb) r Starting program: /usr/home/stefan/scratch/a.out
>> 
>> Breakpoint 1, main () at throw-crash.cc:12 12  int main(void)
>> { (gdb) b _Unwind_RaiseException Breakpoint 2 at 0x800d420b4 
>> (gdb) c Continuing.
>> 
>> Breakpoint 2, 0x000800d420b4 in _Unwind_RaiseException () 
>> from /lib/libgcc_s.so.1 (gdb) f 2 #2  0x00400f51 in f2 ()
>> at throw-crash.cc:5 5   throw std::runtime_error("foo"); 
>> (gdb) p &s $1 = (string *) 0x7fffd600 (gdb) up #3
>> 0x00400fe2 in main () at throw-crash.cc:15 15
>> f1(); (gdb) p &s1 $2 = (string *) 0x7fffd650 (gdb) p &s2 $3 =
>> (string *) 0x7fffd640  (gdb) b 'std::basic_string> std::char_traits, std::allocator >::~basic_string()'
>>  Breakpoint 3 at 0x80089d154: file basic_string.h, line 482. 
>> (gdb) c Continuing.
>> 
>> Breakpoint 3, ~basic_string (this=0x7fffd600) at
>> basic_string.h:279 279   _M_data() const (gdb) c 
>> Continuing.
>> 
>> Breakpoint 3, ~basic_string (this=0x7fffd640) at
>> basic_string.h:279 279   _M_data() const (gdb) c 
>> Continuing.
>> 
>> Breakpoint 3, ~basic_string (this=0x7fffd60f) at
>> basic_string.h:279  279   _M_data() const
>> 
>> So, the address of s2 is 0x7fffd640, but the dtor is called
>> with 0x7fffd60f which is also very unaligned. I think this is
>> the reason for the crash.
> 
> Thank you for digging more.
> 
> In fact, it is more likely that there is some bug or
> incompatibility in c++ unwinder than in the libgcc itself, but as
> you noted, a compiler bug is also possible.
> 
> Anyway, I was mostly looking could the backtrace starts in rtld.
> Rtld bug also cannot be excluded at this stage, but it not much
> likely.
> 

Since this is similar to the pain I was seeing rebuilding everything
with clang so I have been following this thread with much interest.

Just to add more data, I get different results.   This is all i386.

gcc v464 built using an earlier clang from -current world/kernel
r243027.  boost was also built using this revision.

$ /usr/local/bin/g++46 -O2 -I/usr/local/include -L/usr/local/lib
- -lboost_program_options -o unwinder unwinder.cc
[atkinson@moby ~/dev]$ ldd unwinder
unwinder:
libboost_program_options.so =>
/usr/local/lib/libboost_program_options.so (0x2806e000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x280c2000)
libm.so.5 => /lib/libm.so.5 (0x281a1000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x281c2000)
libc.so.7 => /lib/libc.so.7 (0x281cd000)
libthr.so.3 => /lib/libthr.so.3 (0x28317000)
[atkinson@moby ~/dev]$ ./unwinder
Abort trap (core dumped)


clang 32 built from -current world/kernel r244958 works just fine.

$ c++ -O2 -I/usr/local/include -L/usr/local/lib
- -lboost_program_options -o unwinder unwinder.cc
[atkinson@moby ~/dev]$ ./unwinder
[atkinson@moby ~/dev]$ ldd unwinder
unwinder:
libboost_program_options.so =>
/usr/local/lib/libboost_program_options.so (0x2806d000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x280c1000)
libm.so.5 => /lib/libm.so.5 (0x281a)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x281c1000)
libc.so.7 => /lib/libc.so.7 (0x281cc000)
libthr.so.3 => /lib/libthr.so.3 (0x28316000)


It might be useful to exp

Re: ZFS/RAIDZ and SAMBA: abyssimal performance

2013-01-04 Thread Rick Macklem

Fabian Keil wrote:
> Fleuriot Damien  wrote:
> 
> >
> > On Jan 4, 2013, at 4:19 PM, O. Hartmann
> >  wrote:
> >
> > > Am 01/04/13 15:45, schrieb Garrett Cooper:
> > >> On Fri, Jan 4, 2013 at 6:06 AM, Fleuriot Damien  wrote:
> > >>
> > >> ...
> > >>
> > >>> And this is under [global] in /usr/local/etc/smb.conf:
> > >>>   min receivefile size = 16384
> > >>>   aio read size = 16384
> > >>>   aio write size = 16384
> > >>>   aio write behind = yes
> > >>
> > >> These are still pretty low, depending on what your
> > >> networking/disk
> > >> setup is like; my important performance settings are:
> > >>
> > >>socket options = SO_RCVBUF=64240 SO_SNDBUF=64240
> > >>TCP_NODELAY
> > >> IPTOS_LOWDELAY IPTOS_THROUGHPUT
> > >>write cache size = 65536
> > >>aio read size = 65536
> > >>aio write size = 65536
> > >>directory name cache size = 0
> 
> > > Well, now I have peak values ~ 120 MB/s when copying. I applied
> > > Fleuriot
> > > Damien's values to /boot/loader.conf and yours to the smb.conf.
> > > Somewhere in the handbook this should be documented! it is to much
> > > efford to get SAMBA working properly with ZFS, if the tricks and
> > > problems are so widespread over several architectural aspects of
> > > the system.
> > >
> > > It could save a lot of time for adminsitartors and those which try
> > > FreeBSD as a serving system instead of Linux.
> > >
> > > Just for the record. I feel a bit confused about all the tricks
> > > and
> > > tweak now "published" for ZFS, its magic L2ARC, the kernel_vmem
> > > wizzardy
> > > thingis. The ZFS Wiki seems to be a bit outdated and confusing, it
> > > would
> > > be a great deal if all these things could be lined up a s a primer
> > > with
> > > a bit more explanations than "put this number there".
> 
> > The problem, Oliver, is that these values are system dependant.
> 
> While I agree that the values are system dependant the purpose of
> the tunables could still be documented together with a description
> of how to properly test that they have any effect at all and that
> it's an improvement compared to the defaults.
> 
What about capturing a few examples, like this one for a system with
16Gb of Ram. Basically cases of:
- this is my hardware config and here's what works well for me
It's pretty easy for people to choose the example closest to their
setup as a starting point.

Then urls to where the docs are, so people can read/fine tune from there?

rick


rick

> Scarce ZFS tuning documentation is also a problem upstream which
> probably doesn't help.
> 
> Fabian
___
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: ZFS/RAIDZ and SAMBA: abyssimal performance

2013-01-04 Thread Garrett Cooper

On Fri, Jan 4, 2013 at 12:33 PM, Garrett Cooper  wrote:

...

> The documentation is there (see the Evil ZFS Tuning Guide, etc), the
> problem is that our OS is Solaris so the directions do not directly
> apply.

Meant to say:

... is not Solaris...

Thanks,
-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: ZFS/RAIDZ and SAMBA: abyssimal performance

2013-01-04 Thread Garrett Cooper

On Fri, Jan 4, 2013 at 10:28 AM, Fabian Keil
 wrote:

...

> While I agree that the values are system dependant the purpose of
> the tunables could still be documented together with a description
> of how to properly test that they have any effect at all and that
> it's an improvement compared to the defaults.
>
> Scarce ZFS tuning documentation is also a problem upstream which
> probably doesn't help.

The documentation is there (see the Evil ZFS Tuning Guide, etc), the
problem is that our OS is Solaris so the directions do not directly
apply.

As for the Samba settings, there's already a document at samba.org
that describes what needs to be done:
http://www.samba.org/samba/docs/man/Samba-HOWTO-Collection/speed.html
.

My point is: the documentation is already there in both areas. One
just has to read, tweak, and test. There isn't a magic formula or
recipe for getting your box to go faster for all cases.

Thanks,
-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: clang 3.2 RC2 miscompiles libgcc?

2013-01-04 Thread Konstantin Belousov

On Fri, Jan 04, 2013 at 08:06:02PM +0100, Stefan Farfeleder wrote:
> On Fri, Jan 04, 2013 at 08:14:38PM +0200, Konstantin Belousov wrote:
> > On Fri, Jan 04, 2013 at 04:49:41PM +0100, Stefan Farfeleder wrote:
> > > Here's a minimal test case that reproduces the bug:
> > > 
> > > $ cat throw-crash.cc
> > > #include 
> > > 
> > > void f2(void) {
> > > std::string s;
> > > throw std::runtime_error("foo");
> > > }
> > > 
> > > void f1(void) {
> > > f2();
> > > }
> > > 
> > > int main(void) {
> > > try {
> > > std::string s1, s2;
> > > f1();
> > > return 0;
> > > } catch (const std::exception &) {
> > > return 1;
> > > }
> > > }
> > > $ g++ -O2 -finline-limit=0 throw-crash.cc 
> > > $ ./a.out 
> > > zsh: bus error (core dumped)  ./a.out
> > 
> > What is the backtrace ?
> > Compile the system libraries (ld-elf, libc, libgcc etc) with the
> > debugging information and obtain the backtrace once more.
> 
> I'm afraid the backtrace is not really interesting:
> 
> Program received signal SIGBUS, Bus error.
> std::string::_Rep::_M_dispose (this=0x7fffd62fe8, __a=@0x7fffd628)
> at atomicity.h:69
> 69  _Atomic_word __result = *__mem;
> (gdb) bt
> #0  std::string::_Rep::_M_dispose (this=0x7fffd62fe8, __a=@0x7fffd628)
> at atomicity.h:69
> #1  0x00080089d168 in ~basic_string (this=0x7fffd62fe8)
> at basic_string.h:482
> #2  0x00401038 in main () at throw-crash.cc:16
> 
> I think the stack is somehow corrupted after the exception was
> performed. As with the original test case, loading an old libgcc_s.so.1
> instead makes the program run correctly.
> 
> It seems the std::string destructor is called with an invalid this
> pointer for s2:
> 
> (gdb) r
> Starting program: /usr/home/stefan/scratch/a.out 
> 
> Breakpoint 1, main () at throw-crash.cc:12
> 12  int main(void) {
> (gdb) b _Unwind_RaiseException
> Breakpoint 2 at 0x800d420b4
> (gdb) c
> Continuing.
> 
> Breakpoint 2, 0x000800d420b4 in _Unwind_RaiseException ()
>from /lib/libgcc_s.so.1
> (gdb) f 2
> #2  0x00400f51 in f2 () at throw-crash.cc:5
> 5   throw std::runtime_error("foo");
> (gdb) p &s
> $1 = (string *) 0x7fffd600
> (gdb) up
> #3  0x00400fe2 in main () at throw-crash.cc:15
> 15  f1();
> (gdb) p &s1
> $2 = (string *) 0x7fffd650
> (gdb) p &s2
> $3 = (string *) 0x7fffd640
>   
> (gdb) b 'std::basic_string, std::allocator 
> >::~basic_string()' 
> Breakpoint 3 at 0x80089d154: file basic_string.h, line 482.
> (gdb) c
> Continuing.
> 
> Breakpoint 3, ~basic_string (this=0x7fffd600) at basic_string.h:279
> 279   _M_data() const
> (gdb) c
> Continuing.
> 
> Breakpoint 3, ~basic_string (this=0x7fffd640) at basic_string.h:279
> 279   _M_data() const
> (gdb) c
> Continuing.
> 
> Breakpoint 3, ~basic_string (this=0x7fffd60f) at basic_string.h:279
> 
> 279   _M_data() const
> 
> So, the address of s2 is 0x7fffd640, but the dtor is called with
> 0x7fffd60f which is also very unaligned. I think this is the reason
> for the crash.

Thank you for digging more.

In fact, it is more likely that there is some bug or incompatibility in
c++ unwinder than in the libgcc itself, but as you noted, a compiler bug
is also possible.

Anyway, I was mostly looking could the backtrace starts in rtld. Rtld bug
also cannot be excluded at this stage, but it not much likely.


pgpM6TAs72wPh.pgp
Description: PGP signature

Re: clang 3.2 RC2 miscompiles libgcc?

2013-01-04 Thread Stefan Farfeleder

On Fri, Jan 04, 2013 at 08:14:38PM +0200, Konstantin Belousov wrote:
> On Fri, Jan 04, 2013 at 04:49:41PM +0100, Stefan Farfeleder wrote:
> > Here's a minimal test case that reproduces the bug:
> > 
> > $ cat throw-crash.cc
> > #include 
> > 
> > void f2(void) {
> > std::string s;
> > throw std::runtime_error("foo");
> > }
> > 
> > void f1(void) {
> > f2();
> > }
> > 
> > int main(void) {
> > try {
> > std::string s1, s2;
> > f1();
> > return 0;
> > } catch (const std::exception &) {
> > return 1;
> > }
> > }
> > $ g++ -O2 -finline-limit=0 throw-crash.cc 
> > $ ./a.out 
> > zsh: bus error (core dumped)  ./a.out
> 
> What is the backtrace ?
> Compile the system libraries (ld-elf, libc, libgcc etc) with the
> debugging information and obtain the backtrace once more.

I'm afraid the backtrace is not really interesting:

Program received signal SIGBUS, Bus error.
std::string::_Rep::_M_dispose (this=0x7fffd62fe8, __a=@0x7fffd628)
at atomicity.h:69
69  _Atomic_word __result = *__mem;
(gdb) bt
#0  std::string::_Rep::_M_dispose (this=0x7fffd62fe8, __a=@0x7fffd628)
at atomicity.h:69
#1  0x00080089d168 in ~basic_string (this=0x7fffd62fe8)
at basic_string.h:482
#2  0x00401038 in main () at throw-crash.cc:16

I think the stack is somehow corrupted after the exception was
performed. As with the original test case, loading an old libgcc_s.so.1
instead makes the program run correctly.

It seems the std::string destructor is called with an invalid this
pointer for s2:

(gdb) r
Starting program: /usr/home/stefan/scratch/a.out 

Breakpoint 1, main () at throw-crash.cc:12
12  int main(void) {
(gdb) b _Unwind_RaiseException
Breakpoint 2 at 0x800d420b4
(gdb) c
Continuing.

Breakpoint 2, 0x000800d420b4 in _Unwind_RaiseException ()
   from /lib/libgcc_s.so.1
(gdb) f 2
#2  0x00400f51 in f2 () at throw-crash.cc:5
5   throw std::runtime_error("foo");
(gdb) p &s
$1 = (string *) 0x7fffd600
(gdb) up
#3  0x00400fe2 in main () at throw-crash.cc:15
15  f1();
(gdb) p &s1
$2 = (string *) 0x7fffd650
(gdb) p &s2
$3 = (string *) 0x7fffd640

(gdb) b 'std::basic_string, std::allocator 
>::~basic_string()' 
Breakpoint 3 at 0x80089d154: file basic_string.h, line 482.
(gdb) c
Continuing.

Breakpoint 3, ~basic_string (this=0x7fffd600) at basic_string.h:279
279   _M_data() const
(gdb) c
Continuing.

Breakpoint 3, ~basic_string (this=0x7fffd640) at basic_string.h:279
279   _M_data() const
(gdb) c
Continuing.

Breakpoint 3, ~basic_string (this=0x7fffd60f) at basic_string.h:279

279   _M_data() const

So, the address of s2 is 0x7fffd640, but the dtor is called with
0x7fffd60f which is also very unaligned. I think this is the reason
for the crash.

Stefan
___
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: ZFS/RAIDZ and SAMBA: abyssimal performance

2013-01-04 Thread Fabian Keil

Fleuriot Damien  wrote:

> 
> On Jan 4, 2013, at 4:19 PM, O. Hartmann  wrote:
> 
> > Am 01/04/13 15:45, schrieb Garrett Cooper:
> >> On Fri, Jan 4, 2013 at 6:06 AM, Fleuriot Damien  wrote:
> >> 
> >> ...
> >> 
> >>> And this is under [global] in /usr/local/etc/smb.conf:
> >>>   min receivefile size = 16384
> >>>   aio read size = 16384
> >>>   aio write size = 16384
> >>>   aio write behind = yes
> >> 
> >> These are still pretty low, depending on what your networking/disk
> >> setup is like; my important performance settings are:
> >> 
> >>socket options = SO_RCVBUF=64240 SO_SNDBUF=64240 TCP_NODELAY
> >> IPTOS_LOWDELAY IPTOS_THROUGHPUT
> >>write cache size = 65536
> >>aio read size = 65536
> >>aio write size = 65536
> >>directory name cache size = 0

> > Well, now I have peak values ~ 120 MB/s when copying. I applied Fleuriot
> > Damien's values to /boot/loader.conf and yours to the smb.conf.
> > Somewhere in the handbook this should be documented! it is to much
> > efford to get SAMBA working properly with ZFS, if the tricks and
> > problems are so widespread over several architectural aspects of the system.
> > 
> > It could save a lot of time for adminsitartors and those which try
> > FreeBSD as a serving system instead of Linux.
> > 
> > Just for the record. I feel a bit confused about all the tricks and
> > tweak now "published" for ZFS, its magic L2ARC, the kernel_vmem wizzardy
> > thingis. The ZFS Wiki seems to be a bit outdated and confusing, it would
> > be a great deal if all these things could be lined up a s a primer with
> > a bit more explanations than "put this number there".

> The problem, Oliver, is that these values are system dependant.

While I agree that the values are system dependant the purpose of
the tunables could still be documented together with a description
of how to properly test that they have any effect at all and that
it's an improvement compared to the defaults.

Scarce ZFS tuning documentation is also a problem upstream which
probably doesn't help.

Fabian


signature.asc
Description: PGP signature

Re: clang 3.2 RC2 miscompiles libgcc?

2013-01-04 Thread Konstantin Belousov

On Fri, Jan 04, 2013 at 04:49:41PM +0100, Stefan Farfeleder wrote:
> On Wed, Jan 02, 2013 at 02:59:50PM +0100, Stefan Farfeleder wrote:
> > On Sun, Dec 30, 2012 at 11:17:10PM +0100, Dimitry Andric wrote:
> > > 
> > > I have been playing with Stefan's testcase for a while now, and while I
> > > can reproduce the crashes, I am still at a loss about the cause.  It
> > > does seem to have something to do with throwing exceptions, but I am
> > > still not sure whether I am looking at a bug in boost, gcc, clang, or
> > > libgcc...
> > > 
> > > Do you happen to have a smaller testcase, by any chance?
> > 
> > Not yet, but I'll try to come up with something smaller.
> 
> Here's a minimal test case that reproduces the bug:
> 
> $ cat throw-crash.cc
> #include 
> 
> void f2(void) {
> std::string s;
> throw std::runtime_error("foo");
> }
> 
> void f1(void) {
> f2();
> }
> 
> int main(void) {
> try {
> std::string s1, s2;
> f1();
> return 0;
> } catch (const std::exception &) {
> return 1;
> }
> }
> $ g++ -O2 -finline-limit=0 throw-crash.cc 
> $ ./a.out 
> zsh: bus error (core dumped)  ./a.out

What is the backtrace ?
Compile the system libraries (ld-elf, libc, libgcc etc) with the
debugging information and obtain the backtrace once more.


pgpqQWwruELDD.pgp
Description: PGP signature

Re: ZFS/RAIDZ and SAMBA: abyssimal performance

2013-01-04 Thread Johan Hendriks


Fleuriot Damien schreef:

On Jan 4, 2013, at 4:19 PM, O. Hartmann  wrote:


Am 01/04/13 15:45, schrieb Garrett Cooper:

On Fri, Jan 4, 2013 at 6:06 AM, Fleuriot Damien  wrote:

...


And this is under [global] in /usr/local/etc/smb.conf:
   min receivefile size = 16384
   aio read size = 16384
   aio write size = 16384
   aio write behind = yes

These are still pretty low, depending on what your networking/disk
setup is like; my important performance settings are:

socket options = SO_RCVBUF=64240 SO_SNDBUF=64240 TCP_NODELAY
IPTOS_LOWDELAY IPTOS_THROUGHPUT
write cache size = 65536
aio read size = 65536
aio write size = 65536
directory name cache size = 0

HTH,
-Garrett

Well, now I have peak values ~ 120 MB/s when copying. I applied Fleuriot
Damien's values to /boot/loader.conf and yours to the smb.conf.
Somewhere in the handbook this should be documented! it is to much
efford to get SAMBA working properly with ZFS, if the tricks and
problems are so widespread over several architectural aspects of the system.

It could save a lot of time for adminsitartors and those which try
FreeBSD as a serving system instead of Linux.

Just for the record. I feel a bit confused about all the tricks and
tweak now "published" for ZFS, its magic L2ARC, the kernel_vmem wizzardy
thingis. The ZFS Wiki seems to be a bit outdated and confusing, it would
be a great deal if all these things could be lined up a s a primer with
a bit more explanations than "put this number there".

And by the way, it is like changing from hell to heaven having now ~ 100
MB/s throughput compared to ~1/500!

Thanks a lot,
Oliver



The problem, Oliver, is that these values are system dependant.

Notice how Garret replied that these values are a bit low (and they might be 
indeed !).

However, while you have 16gb RAM, my ZFS NAS only has 4gb.



Basically and as Jeremy Chadwick pointed out at the time, there is no one set 
of correct values for 100% of the population.

One has to adjust them step by step and decide what is best for them.



@garret: I'll try with the values you posted, although I get 90-120mbytes/s 
most of the time so I pretty much saturate my 1gbs link.

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

The only zfs tunable i use in my /boot/loader.conf is vfs.zfs.arc_max=
I  leave 4 GB for the system itself in most cases.

In my smb.conf i use the following
socket options = TCP_NODELAY SO_RCVBUF=131072 SO_SNDBUF=131072
max protocol = SMB2
But if you set that then you can not use the aio settings as samba will 
crash then.


if you use aio also make sure you load the aio module by setting the 
following in the /boot/loader.conf

aio_load="YES"

@Oliver
I see you use one device for ZIL/log and L2ARC/cache.
Be aware that you can lose the L2ARC/cache without data corruption, but 
losing the ZIL/log device might cause corrupted data.

So always create a mirror for the ZIL/log device.

gr
Johan Hendriks







___
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: r245005M: NFSv4 usermapping not working anymore

2013-01-04 Thread O. Hartmann

Am 01/04/13 18:00, schrieb Steve Kargl:
> On Fri, Jan 04, 2013 at 05:52:41PM +0100, O. Hartmann wrote:
>> Am 01/04/13 15:52, schrieb Garrett Cooper:
>>> Answering just the trivial question...
>>> On Fri, Jan 4, 2013 at 2:13 AM, O. Hartmann wrote:
 server-1: FreeBSD 10.0-CURRENT #0 r244957: Wed Jan  2 12:06:13 CET 2013

 By the way, can someone give me a hint why some boxes show up with an
 attached "M" to the SVN revision number (like r245005M)?
>>>
>>> The M stands for sources modified after checkout:
>>> http://gotofritz.net/blog/howto/svn-status-codes/
>>
>> Well, from what I received by now - does this imply that I have
>> supposedly manipulated my sources?
>>
> 
> cd /usr/src
> svn status
> 

Thanks.

Did so. And found some "sins" in GENERIC.

Oliver



signature.asc
Description: OpenPGP digital signature

Re: r245005M: NFSv4 usermapping not working anymore

2013-01-04 Thread Willem Jan Withagen

On 2013-01-04 17:52, O. Hartmann wrote:
> Am 01/04/13 15:52, schrieb Garrett Cooper:
>> Answering just the trivial question...
>>
>> On Fri, Jan 4, 2013 at 2:13 AM, O. Hartmann  
>> wrote:
>>
>> ...
>>
>>> server-1: FreeBSD 10.0-CURRENT #0 r244957: Wed Jan  2 12:06:13 CET 2013
>>>
>>> By the way, can someone give me a hint why some boxes show up with an
>>> attached "M" to the SVN revision number (like r245005M)?
>>
>> The M stands for sources modified after checkout:
>> http://gotofritz.net/blog/howto/svn-status-codes/
>> HTH,
>> -Garrett
>>
> 
> 
> Well, from what I received by now - does this imply that I have
> supposedly manipulated my sources?
> 
> Well, I'm not aware of that except that I use non-GENERIC kernel
> configuration file, but that is named different.
> 
> I'm surprised and a bit confused ...

Go to /usr/src
and go: svn status.

It will tell you the files it does not like.

?'s are for files that are not in SVN.
M are for modified files.

--WjW


___
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: r245005M: NFSv4 usermapping not working anymore

2013-01-04 Thread Dimitry Andric


On 2013-01-04 17:52, O. Hartmann wrote:

Am 01/04/13 15:52, schrieb Garrett Cooper:

Answering just the trivial question...

...

 The M stands for sources modified after checkout:
http://gotofritz.net/blog/howto/svn-status-codes/

Well, from what I received by now - does this imply that I have
supposedly manipulated my sources?

Well, I'm not aware of that except that I use non-GENERIC kernel
configuration file, but that is named different.


Just run "svn status" in your source tree, and Subversion will show you
what it thinks is modified.
___
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: r245005M: NFSv4 usermapping not working anymore

2013-01-04 Thread Steve Kargl

On Fri, Jan 04, 2013 at 05:52:41PM +0100, O. Hartmann wrote:
> Am 01/04/13 15:52, schrieb Garrett Cooper:
> > Answering just the trivial question...
> > On Fri, Jan 4, 2013 at 2:13 AM, O. Hartmann wrote:
> >> server-1: FreeBSD 10.0-CURRENT #0 r244957: Wed Jan  2 12:06:13 CET 2013
> >>
> >> By the way, can someone give me a hint why some boxes show up with an
> >> attached "M" to the SVN revision number (like r245005M)?
> > 
> > The M stands for sources modified after checkout:
> > http://gotofritz.net/blog/howto/svn-status-codes/
> 
> Well, from what I received by now - does this imply that I have
> supposedly manipulated my sources?
> 

cd /usr/src
svn status

-- 
Steve
___
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: r245005M: NFSv4 usermapping not working anymore

2013-01-04 Thread O. Hartmann

Am 01/04/13 15:52, schrieb Garrett Cooper:
> Answering just the trivial question...
> 
> On Fri, Jan 4, 2013 at 2:13 AM, O. Hartmann  
> wrote:
> 
> ...
> 
>> server-1: FreeBSD 10.0-CURRENT #0 r244957: Wed Jan  2 12:06:13 CET 2013
>>
>> By the way, can someone give me a hint why some boxes show up with an
>> attached "M" to the SVN revision number (like r245005M)?
> 
> The M stands for sources modified after checkout:
> http://gotofritz.net/blog/howto/svn-status-codes/
> HTH,
> -Garrett
> 

Well, from what I received by now - does this imply that I have
supposedly manipulated my sources?

Well, I'm not aware of that except that I use non-GENERIC kernel
configuration file, but that is named different.

I'm surprised and a bit confused ...

Oliver

signature.asc
Description: OpenPGP digital signature

Re: clang 3.2 RC2 miscompiles libgcc?

2013-01-04 Thread Stefan Farfeleder

On Wed, Jan 02, 2013 at 02:59:50PM +0100, Stefan Farfeleder wrote:
> On Sun, Dec 30, 2012 at 11:17:10PM +0100, Dimitry Andric wrote:
> > 
> > I have been playing with Stefan's testcase for a while now, and while I
> > can reproduce the crashes, I am still at a loss about the cause.  It
> > does seem to have something to do with throwing exceptions, but I am
> > still not sure whether I am looking at a bug in boost, gcc, clang, or
> > libgcc...
> > 
> > Do you happen to have a smaller testcase, by any chance?
> 
> Not yet, but I'll try to come up with something smaller.

Here's a minimal test case that reproduces the bug:

$ cat throw-crash.cc
#include 

void f2(void) {
std::string s;
throw std::runtime_error("foo");
}

void f1(void) {
f2();
}

int main(void) {
try {
std::string s1, s2;
f1();
return 0;
} catch (const std::exception &) {
return 1;
}
}
$ g++ -O2 -finline-limit=0 throw-crash.cc 
$ ./a.out 
zsh: bus error (core dumped)  ./a.out

Stefan
___
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: ZFS/RAIDZ and SAMBA: abyssimal performance

2013-01-04 Thread Fleuriot Damien


On Jan 4, 2013, at 4:19 PM, O. Hartmann  wrote:

> Am 01/04/13 15:45, schrieb Garrett Cooper:
>> On Fri, Jan 4, 2013 at 6:06 AM, Fleuriot Damien  wrote:
>> 
>> ...
>> 
>>> And this is under [global] in /usr/local/etc/smb.conf:
>>>   min receivefile size = 16384
>>>   aio read size = 16384
>>>   aio write size = 16384
>>>   aio write behind = yes
>> 
>> These are still pretty low, depending on what your networking/disk
>> setup is like; my important performance settings are:
>> 
>>socket options = SO_RCVBUF=64240 SO_SNDBUF=64240 TCP_NODELAY
>> IPTOS_LOWDELAY IPTOS_THROUGHPUT
>>write cache size = 65536
>>aio read size = 65536
>>aio write size = 65536
>>directory name cache size = 0
>> 
>> HTH,
>> -Garrett
> Well, now I have peak values ~ 120 MB/s when copying. I applied Fleuriot
> Damien's values to /boot/loader.conf and yours to the smb.conf.
> Somewhere in the handbook this should be documented! it is to much
> efford to get SAMBA working properly with ZFS, if the tricks and
> problems are so widespread over several architectural aspects of the system.
> 
> It could save a lot of time for adminsitartors and those which try
> FreeBSD as a serving system instead of Linux.
> 
> Just for the record. I feel a bit confused about all the tricks and
> tweak now "published" for ZFS, its magic L2ARC, the kernel_vmem wizzardy
> thingis. The ZFS Wiki seems to be a bit outdated and confusing, it would
> be a great deal if all these things could be lined up a s a primer with
> a bit more explanations than "put this number there".
> 
> And by the way, it is like changing from hell to heaven having now ~ 100
> MB/s throughput compared to ~1/500!
> 
> Thanks a lot,
> Oliver
> 


The problem, Oliver, is that these values are system dependant.

Notice how Garret replied that these values are a bit low (and they might be 
indeed !).

However, while you have 16gb RAM, my ZFS NAS only has 4gb.



Basically and as Jeremy Chadwick pointed out at the time, there is no one set 
of correct values for 100% of the population.

One has to adjust them step by step and decide what is best for them.



@garret: I'll try with the values you posted, although I get 90-120mbytes/s 
most of the time so I pretty much saturate my 1gbs link.

___
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: ZFS/RAIDZ and SAMBA: abyssimal performance

2013-01-04 Thread O. Hartmann

Am 01/04/13 15:45, schrieb Garrett Cooper:
> On Fri, Jan 4, 2013 at 6:06 AM, Fleuriot Damien  wrote:
> 
> ...
> 
>> And this is under [global] in /usr/local/etc/smb.conf:
>>min receivefile size = 16384
>>aio read size = 16384
>>aio write size = 16384
>>aio write behind = yes
> 
> These are still pretty low, depending on what your networking/disk
> setup is like; my important performance settings are:
> 
> socket options = SO_RCVBUF=64240 SO_SNDBUF=64240 TCP_NODELAY
> IPTOS_LOWDELAY IPTOS_THROUGHPUT
> write cache size = 65536
> aio read size = 65536
> aio write size = 65536
> directory name cache size = 0
> 
> HTH,
> -Garrett
Well, now I have peak values ~ 120 MB/s when copying. I applied Fleuriot
Damien's values to /boot/loader.conf and yours to the smb.conf.
Somewhere in the handbook this should be documented! it is to much
efford to get SAMBA working properly with ZFS, if the tricks and
problems are so widespread over several architectural aspects of the system.

It could save a lot of time for adminsitartors and those which try
FreeBSD as a serving system instead of Linux.

Just for the record. I feel a bit confused about all the tricks and
tweak now "published" for ZFS, its magic L2ARC, the kernel_vmem wizzardy
thingis. The ZFS Wiki seems to be a bit outdated and confusing, it would
be a great deal if all these things could be lined up a s a primer with
a bit more explanations than "put this number there".

And by the way, it is like changing from hell to heaven having now ~ 100
MB/s throughput compared to ~1/500!

Thanks a lot,
Oliver

signature.asc
Description: OpenPGP digital signature

Re: r245005M: NFSv4 usermapping not working anymore

2013-01-04 Thread O. Hartmann

Am 01/04/13 14:30, schrieb Rick Macklem:
> O. Hartmann wrote:
>> Since yesterday's update and buildworld on two FreeBSD 10.0-CURRENT
>> boxes, i realize a strange behaviour. I have one server exporting via
>> NFSv4 several ZFS volumes. The UID mapping went pretty well so far,
>> but
>> with a reboot of yesterday (after a buildworld), files are seen with
>> uid
>> root:wheel and users are no longer seen.
>>
> You might want to check (ifconfig -a) and see that there is a mapping
> for 127.0.0.1 for lo. That is what is used to do the upcall to nfsused
> and some systems have had this missing recently. (I had the impression
> that the problem was caused by r244678, which was reverted by r244989,
> but maybe your system still has that issue.)
> 
> Here's basically how it works, which may help with diagnosing what is
> going on:
> - when the nfsuserd starts up, it pushes a DNS domain (usually the
>   hostname with the first component stripped off) plus a couple of
>   hundred mappings acquired via getpwent()/getgrent() into the kernel
>   cache.
> (The easiest way to break it for all users is to have the wrong DNS
>  domain name. "man nfsuserd" gives you a command line option that can
>  override the default of using the hostname.)
> - Then the nfsuserd waits for upcalls for cache misses and pushes
>   mappings for those requests into the kernel.
> - The cache entries time out with a rather long default of 1hr.
> 
> To get entries, nfsused just uses the getpwent() and getgrent() libc
> calls, so it depends on whatever you have configured for that via
> /etc/nsswitch.conf.
> 
> I'll grab a new kernel and do a quick test, to see if it works ok for me.
> (The most recent commit related to this is r240720, which added support
>  to the client for numeric uids/gids in the string on the wire. This change
>  should not have affected the server.)
> 
> Good luck with it, rick
> 
>> The server and client in question are
>>
>> server: FreeBSD 10.0-CURRENT #2 r245005M: Thu Jan 3 20:25:00 CET 2013
>> client: FreeBSD 10.0-CURRENT #2 r245005M: Thu Jan 3 20:27:25 CET 2013
>>
>> I think this is not supposed to be that way. Another box, our lab's
>> server, doesn't show this phenomenon (but at the moment I have only
>> the
>> opportunity to check with a FreeBSD 9.1-STABLE client). This specific
>> server is
>>
>> server-1: FreeBSD 10.0-CURRENT #0 r244957: Wed Jan 2 12:06:13 CET 2013
>>
>> By the way, can someone give me a hint why some boxes show up with an
>> attached "M" to the SVN revision number (like r245005M)?
>>
>> Thanks,
>>
>> oh


Me stupid killed the nfsuserd="YES" entry in rc.conf on the client side!
So, by starting it again, everything works as before and expected.

Many thanks for the quick response!

Oliver



signature.asc
Description: OpenPGP digital signature

Re: r245005M: NFSv4 usermapping not working anymore

2013-01-04 Thread Garrett Cooper

Answering just the trivial question...

On Fri, Jan 4, 2013 at 2:13 AM, O. Hartmann  wrote:

...

> server-1: FreeBSD 10.0-CURRENT #0 r244957: Wed Jan  2 12:06:13 CET 2013
>
> By the way, can someone give me a hint why some boxes show up with an
> attached "M" to the SVN revision number (like r245005M)?

The M stands for sources modified after checkout:
http://gotofritz.net/blog/howto/svn-status-codes/
HTH,
-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: installworld error: ad0: FAILURE - READ_DMA status=51 error=40 LBA=28071584

2013-01-04 Thread Garrett Cooper

On Fri, Jan 4, 2013 at 3:23 AM, Anton Shterenlikht  wrote:

...

> Is my disk dying?

Uncorrectable read errors suggest yes (especially because the LBA
varies between the two error messages). I would definitely backup your
data at the very least, and as others suggested use smartmontools [via
a livecd?].
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: ZFS/RAIDZ and SAMBA: abyssimal performance

2013-01-04 Thread Garrett Cooper

On Fri, Jan 4, 2013 at 6:06 AM, Fleuriot Damien  wrote:

...

> And this is under [global] in /usr/local/etc/smb.conf:
>min receivefile size = 16384
>aio read size = 16384
>aio write size = 16384
>aio write behind = yes

These are still pretty low, depending on what your networking/disk
setup is like; my important performance settings are:

socket options = SO_RCVBUF=64240 SO_SNDBUF=64240 TCP_NODELAY
IPTOS_LOWDELAY IPTOS_THROUGHPUT
write cache size = 65536
aio read size = 65536
aio write size = 65536
directory name cache size = 0

HTH,
-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: Unbreaking gdb's catch throw

2013-01-04 Thread Dimitry Andric


On 2013-01-04 14:02, Stefan Farfeleder wrote:

On Fri, Jan 04, 2013 at 12:54:03PM +, David Chisnall wrote:

As a work-around, you can put the breakpoint on _Unwind_RaiseException instead. 
 This will work for any language, not just C++ (e.g. it will notice Objective-C 
or gcj-compiled Java exceptions).

Thank you, that works for me.


Alternatively, install the gdb port, which seems to work just fine:

$ /usr/local/bin/gdb ./throw
GNU gdb (GDB) 7.5 [GDB v7.5 for FreeBSD]
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-portbld-freebsd10.0".
For bug reporting instructions, please see:
...
Reading symbols from /tmp/throw...done.
(gdb) break __cxa_throw
Breakpoint 1 at 0x400604
(gdb) run
Starting program: /tmp/throw

Breakpoint 1, __cxxabiv1::__cxa_throw (obj=0x801c060f0,
tinfo=0x600c00 <_ZTIi@@CXXABI_1.3>, dest=0x0)
at 
/usr/src/gnu/lib/libsupc++/../../../contrib/libstdc++/libsupc++/eh_throw.cc:60
60__cxa_exception *header = __get_exception_header_from_obj (obj);
___
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: ZFS/RAIDZ and SAMBA: abyssimal performance

2013-01-04 Thread Fleuriot Damien


On Jan 4, 2013, at 2:52 PM, "O. Hartmann"  wrote:

> I use a small testing server. The hardware is most modern Intel hardware
> (i3-3220, Z77 chipset), 16GB RAM. The OS is FreeBSD 10.0-CURRENT #1
> r245036M: Fri Jan  4 12:48:53 CET 2013.
> 
> The ZFS subsystem is comprised by 3 Western Digital 3 TB harddrives (WDC
> WD30EZRX-00DC0B0 80.00A80> ATA-9 SATA 3.x device), setup as a ZFS RAIDZ:
> 
> ---
> root@gate [etc] zpool status
>  pool: ASGARD00
> state: ONLINE
>  scan: scrub repaired 0 in 1h45m with 0 errors on Sat Dec  1 20:59:44 2012
> config:
> 
>NAMESTATE READ
> WRITE CKSUM
>ASGARD00ONLINE   0
>   0 0
>  raidz1-0  ONLINE   0
>   0 0
>gptid/1e716118-1492-11e2-b828-90f6526a24d6  ONLINE   0
>   0 0
>gptid/294a6798-1492-11e2-b828-90f6526a24d6  ONLINE   0
>   0 0
>gptid/30c813f8-1492-11e2-b828-90f6526a24d6  ONLINE   0
>   0 0
>logs
>  ada0p1ONLINE   0
>   0 0
>cache
>  ada0p2ONLINE   0
>   0 0
> 
> errors: No known data errors
> ---
> 
> The "logs" and "cache" device is a single SAMSUNG 830 SSD, 60 GB
> capacity, GPT partinioned, logs (ZIL) has 5GB, cache has ~55 GB.
> 
> I think its not the optimal setup using the very same SSD for both
> caching/L2ARC and ZIL, but without the cache device the performance
> doen't differ much at the moment. Luckliy, with ZFS I can change the
> arrangement as I like.
> 
> The ZFS volumes created on the pool named ASGARD00 are standard, only
> options sharenfs/sharesmb/checksum are set to yes. Everthing elese is
> set to the defaults.
> 
> In /boot/loader.conf I set the following parameters according to many
> (and confusing!) help and suggestions on the web:
> 
> # ZFS
> #vfs.zfs.cache_flush_disable=1
> #
> #vfs.zfs.write_limit_override=1073741824 # 1GB
> vfs.zfs.l2arc_noprefetch=0
> vfs.zfs.l2arc_headroom=6
> 
> The NFSv4 performance (client is also FreeBSD 10.0-CURRENT of the same
> date) is moderate to disapointing and doesn't exceed 45 - 55 MB/s
> sustained, but here are sometimes "spikes" I can watch with "systat -vm
> 1" reporting 120 MB/s per drive (ada2/ada3/ada4, the 3x 3TB WD drives in
> RAIDZ). I still benchmark via iozone. Both server and client use JUMBO
> frames (MTU=6120), which gives better throughput compared to the
> standard MTU=1500.
> 
> The local performance on the server itself is slightly better, but
> iozone reports some strange numbers. The benchmark "writes" (using 4
> threads, 4k blocksizes, writing four times files of size 1G to the ZFS
> volume reports sometimes 150 MB/s throughput, and then 70 MB/s and
> re-writes is then 1/10 of the "write" throughput and according to the
> manual of iozone, re-write is considered to have higher values due to
> the lack of writing the meta data again. But I'm still testing this case.
> 
> Well, the ZFS volumes are also shared as SAMBA CIFS volumes and here I
> experience something that is simply described as "abyssimal"
> performance! From both a dedicated Windows 7 Pro client and a VirtualBox
> 4.2.6-client access to folders in a share, say my local home, can take
> ages! Opening files takes eons, if possible, in most cases windows
> reports "can not open ...". Copying files from Windows to the SAMBA
> share doesn't work or take ages, the throughput visible on the server
> side watched by "systat -vm 1" reports spiking 0.48 MB/s, with a hiatus
> of several seconds.
> 
> Well, the SAMBA setup is straightforward, for two weeks now I have
> permutated nearly every parameter suggested on all the web's help sites
> and I simply took the well configuration from one of our lab's FreeBSD
> 9.1-STABLE SAMBA servers and changed the local settings for IP and
> domain names etc. The working server (FreeBSD 9.1-STABLE) in question
> has a single ZFS drive and is exporting this also via NFSv4. It doesn't
> have RAIDZ setup!
> 
> Before I start benchmarking further with iozone I need to know whether
> there is an unresolved problem in FreeBSD 10.0 with ZFS/RAIDZ and SAMBA
> or whether I'm mislead and have overseen an important setup option.
> Before exposing all of my setups here I need to clearify.
> 
> I didn't find so far any issues on the web regarding SAMBA, NFSv4 and
> ZFS/RAIDZ.
> 
> Thanks in advance,
> Oliver
> 
> 



I experienced the same performance problem, then followed Jeremy Chadwick's 
advice and tuned variables a bit, I'm getting excellent performance now.


/boot/loader.conf

# Tune ZFS somewhat aye ?
vm.kmem_size="3072M"
vfs.zfs.arc_min="128M"
vfs.zfs.arc_max="2048M"

# Decrease ZFS txg timeout value from 30 (default) to 5 seconds.  This
# should increase throughput and decrease the "bursty" stalls that
# happen during immense I/O with ZFS.
# http://lists.f

ZFS/RAIDZ and SAMBA: abyssimal performance

2013-01-04 Thread O. Hartmann

I use a small testing server. The hardware is most modern Intel hardware
(i3-3220, Z77 chipset), 16GB RAM. The OS is FreeBSD 10.0-CURRENT #1
r245036M: Fri Jan  4 12:48:53 CET 2013.

The ZFS subsystem is comprised by 3 Western Digital 3 TB harddrives (WDC
WD30EZRX-00DC0B0 80.00A80> ATA-9 SATA 3.x device), setup as a ZFS RAIDZ:

---
root@gate [etc] zpool status
  pool: ASGARD00
 state: ONLINE
  scan: scrub repaired 0 in 1h45m with 0 errors on Sat Dec  1 20:59:44 2012
config:

NAMESTATE READ
WRITE CKSUM
ASGARD00ONLINE   0
   0 0
  raidz1-0  ONLINE   0
   0 0
gptid/1e716118-1492-11e2-b828-90f6526a24d6  ONLINE   0
   0 0
gptid/294a6798-1492-11e2-b828-90f6526a24d6  ONLINE   0
   0 0
gptid/30c813f8-1492-11e2-b828-90f6526a24d6  ONLINE   0
   0 0
logs
  ada0p1ONLINE   0
   0 0
cache
  ada0p2ONLINE   0
   0 0

errors: No known data errors
---

The "logs" and "cache" device is a single SAMSUNG 830 SSD, 60 GB
capacity, GPT partinioned, logs (ZIL) has 5GB, cache has ~55 GB.

I think its not the optimal setup using the very same SSD for both
caching/L2ARC and ZIL, but without the cache device the performance
doen't differ much at the moment. Luckliy, with ZFS I can change the
arrangement as I like.

The ZFS volumes created on the pool named ASGARD00 are standard, only
options sharenfs/sharesmb/checksum are set to yes. Everthing elese is
set to the defaults.

In /boot/loader.conf I set the following parameters according to many
(and confusing!) help and suggestions on the web:

# ZFS
#vfs.zfs.cache_flush_disable=1
#
#vfs.zfs.write_limit_override=1073741824 # 1GB
vfs.zfs.l2arc_noprefetch=0
vfs.zfs.l2arc_headroom=6

The NFSv4 performance (client is also FreeBSD 10.0-CURRENT of the same
date) is moderate to disapointing and doesn't exceed 45 - 55 MB/s
sustained, but here are sometimes "spikes" I can watch with "systat -vm
1" reporting 120 MB/s per drive (ada2/ada3/ada4, the 3x 3TB WD drives in
RAIDZ). I still benchmark via iozone. Both server and client use JUMBO
frames (MTU=6120), which gives better throughput compared to the
standard MTU=1500.

The local performance on the server itself is slightly better, but
iozone reports some strange numbers. The benchmark "writes" (using 4
threads, 4k blocksizes, writing four times files of size 1G to the ZFS
volume reports sometimes 150 MB/s throughput, and then 70 MB/s and
re-writes is then 1/10 of the "write" throughput and according to the
manual of iozone, re-write is considered to have higher values due to
the lack of writing the meta data again. But I'm still testing this case.

Well, the ZFS volumes are also shared as SAMBA CIFS volumes and here I
experience something that is simply described as "abyssimal"
performance! From both a dedicated Windows 7 Pro client and a VirtualBox
4.2.6-client access to folders in a share, say my local home, can take
ages! Opening files takes eons, if possible, in most cases windows
reports "can not open ...". Copying files from Windows to the SAMBA
share doesn't work or take ages, the throughput visible on the server
side watched by "systat -vm 1" reports spiking 0.48 MB/s, with a hiatus
of several seconds.

Well, the SAMBA setup is straightforward, for two weeks now I have
permutated nearly every parameter suggested on all the web's help sites
and I simply took the well configuration from one of our lab's FreeBSD
9.1-STABLE SAMBA servers and changed the local settings for IP and
domain names etc. The working server (FreeBSD 9.1-STABLE) in question
has a single ZFS drive and is exporting this also via NFSv4. It doesn't
have RAIDZ setup!

Before I start benchmarking further with iozone I need to know whether
there is an unresolved problem in FreeBSD 10.0 with ZFS/RAIDZ and SAMBA
or whether I'm mislead and have overseen an important setup option.
Before exposing all of my setups here I need to clearify.

I didn't find so far any issues on the web regarding SAMBA, NFSv4 and
ZFS/RAIDZ.

Thanks in advance,
Oliver




signature.asc
Description: OpenPGP digital signature

Re: r245005M: NFSv4 usermapping not working anymore

2013-01-04 Thread Rick Macklem

O. Hartmann wrote:
> Since yesterday's update and buildworld on two FreeBSD 10.0-CURRENT
> boxes, i realize a strange behaviour. I have one server exporting via
> NFSv4 several ZFS volumes. The UID mapping went pretty well so far,
> but
> with a reboot of yesterday (after a buildworld), files are seen with
> uid
> root:wheel and users are no longer seen.
> 
You might want to check (ifconfig -a) and see that there is a mapping
for 127.0.0.1 for lo. That is what is used to do the upcall to nfsused
and some systems have had this missing recently. (I had the impression
that the problem was caused by r244678, which was reverted by r244989,
but maybe your system still has that issue.)

Here's basically how it works, which may help with diagnosing what is
going on:
- when the nfsuserd starts up, it pushes a DNS domain (usually the
  hostname with the first component stripped off) plus a couple of
  hundred mappings acquired via getpwent()/getgrent() into the kernel
  cache.
(The easiest way to break it for all users is to have the wrong DNS
 domain name. "man nfsuserd" gives you a command line option that can
 override the default of using the hostname.)
- Then the nfsuserd waits for upcalls for cache misses and pushes
  mappings for those requests into the kernel.
- The cache entries time out with a rather long default of 1hr.

To get entries, nfsused just uses the getpwent() and getgrent() libc
calls, so it depends on whatever you have configured for that via
/etc/nsswitch.conf.

I'll grab a new kernel and do a quick test, to see if it works ok for me.
(The most recent commit related to this is r240720, which added support
 to the client for numeric uids/gids in the string on the wire. This change
 should not have affected the server.)

Good luck with it, rick

> The server and client in question are
> 
> server: FreeBSD 10.0-CURRENT #2 r245005M: Thu Jan 3 20:25:00 CET 2013
> client: FreeBSD 10.0-CURRENT #2 r245005M: Thu Jan 3 20:27:25 CET 2013
> 
> I think this is not supposed to be that way. Another box, our lab's
> server, doesn't show this phenomenon (but at the moment I have only
> the
> opportunity to check with a FreeBSD 9.1-STABLE client). This specific
> server is
> 
> server-1: FreeBSD 10.0-CURRENT #0 r244957: Wed Jan 2 12:06:13 CET 2013
> 
> By the way, can someone give me a hint why some boxes show up with an
> attached "M" to the SVN revision number (like r245005M)?
> 
> Thanks,
> 
> oh
___
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 ia64/ia64

2013-01-04 Thread FreeBSD Tinderbox

TB --- 2013-01-04 10:53:42 - tinderbox 2.10 running on freebsd-current.sentex.ca
TB --- 2013-01-04 10:53:42 - 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-01-04 10:53:42 - starting HEAD tinderbox run for ia64/ia64
TB --- 2013-01-04 10:53:42 - cleaning the object tree
TB --- 2013-01-04 10:55:17 - /usr/local/bin/svn stat /src
TB --- 2013-01-04 10:55:21 - At svn revision 245034
TB --- 2013-01-04 10:55:22 - building world
TB --- 2013-01-04 10:55:22 - CROSS_BUILD_TESTING=YES
TB --- 2013-01-04 10:55:22 - MAKEOBJDIRPREFIX=/obj
TB --- 2013-01-04 10:55:22 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2013-01-04 10:55:22 - SRCCONF=/dev/null
TB --- 2013-01-04 10:55:22 - TARGET=ia64
TB --- 2013-01-04 10:55:22 - TARGET_ARCH=ia64
TB --- 2013-01-04 10:55:22 - TZ=UTC
TB --- 2013-01-04 10:55:22 - __MAKE_CONF=/dev/null
TB --- 2013-01-04 10:55:22 - cd /src
TB --- 2013-01-04 10:55:22 - /usr/bin/make -B buildworld
>>> Building an up-to-date make(1)
>>> World build started on Fri Jan  4 10:55:27 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 Fri Jan  4 12:28:25 UTC 2013
TB --- 2013-01-04 12:28:25 - generating LINT kernel config
TB --- 2013-01-04 12:28:25 - cd /src/sys/ia64/conf
TB --- 2013-01-04 12:28:25 - /usr/bin/make -B LINT
TB --- 2013-01-04 12:28:25 - cd /src/sys/ia64/conf
TB --- 2013-01-04 12:28:25 - /usr/sbin/config -m LINT
TB --- 2013-01-04 12:28:25 - building LINT kernel
TB --- 2013-01-04 12:28:25 - CROSS_BUILD_TESTING=YES
TB --- 2013-01-04 12:28:25 - MAKEOBJDIRPREFIX=/obj
TB --- 2013-01-04 12:28:25 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2013-01-04 12:28:25 - SRCCONF=/dev/null
TB --- 2013-01-04 12:28:25 - TARGET=ia64
TB --- 2013-01-04 12:28:25 - TARGET_ARCH=ia64
TB --- 2013-01-04 12:28:25 - TZ=UTC
TB --- 2013-01-04 12:28:25 - __MAKE_CONF=/dev/null
TB --- 2013-01-04 12:28:25 - cd /src
TB --- 2013-01-04 12:28:25 - /usr/bin/make -B buildkernel KERNCONF=LINT
>>> Kernel build for LINT started on Fri Jan  4 12:28: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
>>> Kernel build for LINT completed on Fri Jan  4 13:02:15 UTC 2013
TB --- 2013-01-04 13:02:15 - cd /src/sys/ia64/conf
TB --- 2013-01-04 13:02:15 - /usr/sbin/config -m GENERIC
TB --- 2013-01-04 13:02:15 - building GENERIC kernel
TB --- 2013-01-04 13:02:15 - CROSS_BUILD_TESTING=YES
TB --- 2013-01-04 13:02:15 - MAKEOBJDIRPREFIX=/obj
TB --- 2013-01-04 13:02:15 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2013-01-04 13:02:15 - SRCCONF=/dev/null
TB --- 2013-01-04 13:02:15 - TARGET=ia64
TB --- 2013-01-04 13:02:15 - TARGET_ARCH=ia64
TB --- 2013-01-04 13:02:15 - TZ=UTC
TB --- 2013-01-04 13:02:15 - __MAKE_CONF=/dev/null
TB --- 2013-01-04 13:02:15 - cd /src
TB --- 2013-01-04 13:02:15 - /usr/bin/make -B buildkernel KERNCONF=GENERIC
>>> Kernel build for GENERIC started on Fri Jan  4 13:02:15 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
[...]
/src/sys/dev/firewire/if_fwip.c:499: undefined reference to 
`crom_add_simple_text'
/src/sys/dev/firewire/if_fwip.c:500: undefined reference to `crom_add_entry'
/src/sys/dev/firewire/if_fwip.c:501: undefined reference to 
`crom_add_simple_text'
if_fwip.o: In function `fwip_stream_input':
/src/sys/dev/firewire/if_fwip.c:840: undefined reference to 
`fw_noderesolve_nodeid'
if_fwip.o: In function `fwip_unicast_input':
/src/sys/dev/firewire/if_fwip.c:939: undefined reference to 
`fw_noderesolve_nodeid'
if_fwip.o:(.data.rel+0x80): undefined reference to 
`sysctl__hw_firewire_children'
*** [kernel.debug] Error code 1

Stop in /obj/ia64.ia64/src/sys/GENERIC.
*** [buildkernel] Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
TB --- 2013-01-04 13:10:47 - WARNING: /usr/bin/make returned exit code  1 
TB --- 2013-01-04 13:10:47 - ERROR: failed to build GENERIC kernel
TB --- 2013-01-04 13:10:47 - 6476.27 user 1154.48 system 8224.57 real


http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-ia64-ia64.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: Unbreaking gdb's catch throw

2013-01-04 Thread Stefan Farfeleder

On Fri, Jan 04, 2013 at 12:54:03PM +, David Chisnall wrote:
> 
> As a work-around, you can put the breakpoint on _Unwind_RaiseException 
> instead.  This will work for any language, not just C++ (e.g. it will notice 
> Objective-C or gcj-compiled Java exceptions).
> 

Thank you, that works for me.

Stefan
___
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: Unbreaking gdb's catch throw

2013-01-04 Thread David Chisnall


On 4 Jan 2013, at 12:49, Stefan Farfeleder wrote:

> On Fri, Jan 04, 2013 at 12:38:44PM +, David Chisnall wrote:
>> Is this on 9.1?  In -CURRENT and 9.1, libstdc++ is a filter library, and 
>> libsupc++ or or libcxxrt are the filtee.  This means that the __cxa_throw 
>> symbol appears to be in libstdc++ (for symbol versioning purposes), but is 
>> actually in the ABI library.  If you tell gdb to put the breakpoint on 
>> __cxa_throw itself, then it should tell you that there are multiple 
>> definitions and ask which one you want (if it doesn't, it's a gdb bug).  
>> 
> 
> This is on 10.0-CURRENT r244738 amd64. The commands 'b __cxa_throw' and
> 'catch throw' seemd to be identical, and gdb does not ask about multiple
> versions of __cxa_throw.
> 
> To be honest, I don't care exactly whose bug it is, I want it to work again :D

As a work-around, you can put the breakpoint on _Unwind_RaiseException instead. 
 This will work for any language, not just C++ (e.g. it will notice Objective-C 
or gcj-compiled Java exceptions).

David
___
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: Unbreaking gdb's catch throw

2013-01-04 Thread Stefan Farfeleder

On Fri, Jan 04, 2013 at 12:38:44PM +, David Chisnall wrote:
> Is this on 9.1?  In -CURRENT and 9.1, libstdc++ is a filter library, and 
> libsupc++ or or libcxxrt are the filtee.  This means that the __cxa_throw 
> symbol appears to be in libstdc++ (for symbol versioning purposes), but is 
> actually in the ABI library.  If you tell gdb to put the breakpoint on 
> __cxa_throw itself, then it should tell you that there are multiple 
> definitions and ask which one you want (if it doesn't, it's a gdb bug).  
> 

This is on 10.0-CURRENT r244738 amd64. The commands 'b __cxa_throw' and
'catch throw' seemd to be identical, and gdb does not ask about multiple
versions of __cxa_throw.

To be honest, I don't care exactly whose bug it is, I want it to work again :D

$ cat throw.cc
int main(void)
{
throw 1;
}
$ c++ -g throw.cc
$ gdb a.out
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "amd64-marcel-freebsd"...
(gdb) b main
Breakpoint 1 at 0x4007f9: file throw.cc, line 3.
(gdb) r
Starting program: /usr/home/stefan/scratch/a.out

Breakpoint 1, main () at throw.cc:3
3   throw 1;
(gdb) b __cxa_throw
Breakpoint 2 at 0x800898d34
(gdb) c
Continuing.
terminate called after throwing an instance of 'int'

Program received signal SIGABRT, Aborted.
0x000800e52fca in kill () from /lib/libc.so.7

Stefan
___
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: Unbreaking gdb's catch throw

2013-01-04 Thread Fabian Keil

Stefan Farfeleder  wrote:

> gdb's command 'catch throw' is broken on FreeBSD head. While it does set
> a breakpoint on __cxa_throw, the function seems to be never entered when
> an exception is thrown. Does someone know how to fix this? It used to
> work a couple of months ago.

My impression is that gdb from base is pretty useless in general
when compiling with a modern compiler like clang or a more recent
version of gcc.

gdb751 from the ports seems to suck a lot less.

Obviously I'm not saying that it wouldn't be nice if gdb
from base worked better, though.

Fabian

signature.asc
Description: PGP signature

Re: Unbreaking gdb's catch throw

2013-01-04 Thread David Chisnall

Is this on 9.1?  In -CURRENT and 9.1, libstdc++ is a filter library, and 
libsupc++ or or libcxxrt are the filtee.  This means that the __cxa_throw 
symbol appears to be in libstdc++ (for symbol versioning purposes), but is 
actually in the ABI library.  If you tell gdb to put the breakpoint on 
__cxa_throw itself, then it should tell you that there are multiple definitions 
and ask which one you want (if it doesn't, it's a gdb bug).  

David

On 4 Jan 2013, at 12:34, Stefan Farfeleder wrote:

> Hi,
> 
> gdb's command 'catch throw' is broken on FreeBSD head. While it does set
> a breakpoint on __cxa_throw, the function seems to be never entered when
> an exception is thrown. Does someone know how to fix this? It used to
> work a couple of months ago.
> 
> Stefan
> ___
> 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"

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

Unbreaking gdb's catch throw

2013-01-04 Thread Stefan Farfeleder

Hi,

gdb's command 'catch throw' is broken on FreeBSD head. While it does set
a breakpoint on __cxa_throw, the function seems to be never entered when
an exception is thrown. Does someone know how to fix this? It used to
work a couple of months ago.

Stefan
___
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: CFT: Overhauled CPSW driver for BeagleBone

2013-01-04 Thread Thomas Mueller

> On Tue, 1 Jan 2013 10:55:58 -0800
> Tim Kientzle  wrote:

> > On Jan 1, 2013, at 8:12 AM, Brett Wynkoop wrote:
> > > Greeting-

> > > The driver is working much better than the driver currently in
> > > head.  I have maintained an ssh connection to the BeagleBone for
> > > more than 24 hours!

> > Just committed this to -CURRENT r244939.

> > Tim

> Ok time to cvsup then rebuild the kernel followed by a buildworld!

> Thanks Tim!

> wynk...@wynn.com   http://prd4.wynn.com/wynkoop/pgp-keys.txt

Watch what you say about cvsup!  

Have you been following the many messages on the deprecation of cvs, cvsup and 
csup following the recent security breach on FreeBSD servers?

Now you need subversion port (svn) to download and update the source tree.

Tom
___
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: installworld error: ad0: FAILURE - READ_DMA status=51 error=40 LBA=28071584

2013-01-04 Thread Bas Smeelen

On 01/04/2013 12:23 PM, Anton Shterenlikht wrote:

Date: Fri, 4 Jan 2013 11:09:07 GMT
From: Anton Shterenlikht 

I got this error on make installworld:

===> sbin/dhclient (install)
install -s -o root -g wheel -m 555   dhclient /sbin
ad0: FAILURE - READ_DMA status=51 
error=40 LBA=28071584
g_vfs_done():ad0a[READ(offset=14372651008, length=16384)]error = 5
vnode_pager_getpages: I/O read error
vm_fault: pager read error, pid 12794 (install)
install: /sbin/dhclient: Bad address
*** [_proginstall] Error code 71

Stop in /usr/src/sbin/dhclient.
*** [realinstall] Error code 1

Stop in /usr/src/sbin.
*** [realinstall] Error code 1

Stop in /usr/src.
*** [reinstall] Error code 1

Stop in /usr/src.
*** [installworld] Error code 1

Stop in /usr/src.
*** Error code 1

Stop in /usr/src.

What's going on?

This is on sparc64 SunBlade 1500 silver,
updating to r244988.

The disk is:

# gpart show ad0
=>0  234432720  ad0  VTOC8  (111G)
  0   419464801  !0  (20G)
   41946480   335580002  !0  (16G)
   75504480  1589282404  !0  (75G)

#

# df
Filesystem 512-blocks UsedAvail Capacity  Mounted on
/dev/ad0a40620236 21769888 1560073258%/
devfs   220   100%/dev
#

I've run fsck -p before installworld,
and didn't see any problems.

Is my disk dying?

Diagnose with sysutils/smartmontools

# fsck
** /dev/ad0a (NO WRITE)
** Last Mounted on /
** Root file system
** Phase 1 - Check Blocks and Sizes
ad0: FAILURE - READ_DMA status=51 error=40 
LBA=23328672

CANNOT READ BLK: 23328608
CONTINUE? [yn]

Thanks

Anton

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

--
*Bas Smeelen*
/System administrator/
b.smee...@ose.nl 

Dr. Nolenslaan 157
6136GM Sittard
The Netherlands

Tel:  +31 (0) 46 4200 933
Fax: +31 (0) 46 4200 934
www.ose.nl 

This e-mail message, including any attachment(s), is confidential and 
intended solely for the addressee. Any unauthorized review, use, disclosure, 
or distribution is prohibited. If you believe this message has been sent to 
you by mistake, please notify the sender by replying to this transmission, 
and delete the message and its attachments without disclosing them.
Any views or opinions presented herein are solely those of the author and do 
not necessarily represent those of OverNite Software Europe bv.

___
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: installworld error: ad0: FAILURE - READ_DMA status=51 error=40 LBA=28071584

2013-01-04 Thread Bas Smeelen

On 01/04/2013 12:23 PM, Anton Shterenlikht wrote:

Date: Fri, 4 Jan 2013 11:09:07 GMT
From: Anton Shterenlikht 

I got this error on make installworld:

===> sbin/dhclient (install)
install -s -o root -g wheel -m 555   dhclient /sbin
ad0: FAILURE - READ_DMA status=51 
error=40 LBA=28071584
g_vfs_done():ad0a[READ(offset=14372651008, length=16384)]error = 5
vnode_pager_getpages: I/O read error
vm_fault: pager read error, pid 12794 (install)
install: /sbin/dhclient: Bad address
*** [_proginstall] Error code 71

Stop in /usr/src/sbin/dhclient.
*** [realinstall] Error code 1

Stop in /usr/src/sbin.
*** [realinstall] Error code 1

Stop in /usr/src.
*** [reinstall] Error code 1

Stop in /usr/src.
*** [installworld] Error code 1

Stop in /usr/src.
*** Error code 1

Stop in /usr/src.

What's going on?

This is on sparc64 SunBlade 1500 silver,
updating to r244988.

The disk is:

# gpart show ad0
=>0  234432720  ad0  VTOC8  (111G)
  0   419464801  !0  (20G)
   41946480   335580002  !0  (16G)
   75504480  1589282404  !0  (75G)

#

# df
Filesystem 512-blocks UsedAvail Capacity  Mounted on
/dev/ad0a40620236 21769888 1560073258%/
devfs   220   100%/dev
#

I've run fsck -p before installworld,
and didn't see any problems.

Is my disk dying?

I don't know if smartmontools work for sparc64 though

# fsck
** /dev/ad0a (NO WRITE)
** Last Mounted on /
** Root file system
** Phase 1 - Check Blocks and Sizes
ad0: FAILURE - READ_DMA status=51 error=40 
LBA=23328672

CANNOT READ BLK: 23328608
CONTINUE? [yn]

Thanks

Anton

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

--
*Bas Smeelen*
/System administrator/
b.smee...@ose.nl 

Dr. Nolenslaan 157
6136GM Sittard
The Netherlands

Tel:  +31 (0) 46 4200 933
Fax: +31 (0) 46 4200 934
www.ose.nl 

This e-mail message, including any attachment(s), is confidential and 
intended solely for the addressee. Any unauthorized review, use, disclosure, 
or distribution is prohibited. If you believe this message has been sent to 
you by mistake, please notify the sender by replying to this transmission, 
and delete the message and its attachments without disclosing them.
Any views or opinions presented herein are solely those of the author and do 
not necessarily represent those of OverNite Software Europe bv.

___
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: installworld error: ad0: FAILURE - READ_DMA status=51 error=40 LBA=28071584

2013-01-04 Thread Anton Shterenlikht

Date: Fri, 4 Jan 2013 11:09:07 GMT
From: Anton Shterenlikht 

I got this error on make installworld:

===> sbin/dhclient (install)
install -s -o root -g wheel -m 555   dhclient /sbin
ad0: FAILURE - READ_DMA status=51 
error=40 LBA=28071584
g_vfs_done():ad0a[READ(offset=14372651008, length=16384)]error = 5
vnode_pager_getpages: I/O read error
vm_fault: pager read error, pid 12794 (install)
install: /sbin/dhclient: Bad address
*** [_proginstall] Error code 71

Stop in /usr/src/sbin/dhclient.
*** [realinstall] Error code 1

Stop in /usr/src/sbin.
*** [realinstall] Error code 1

Stop in /usr/src.
*** [reinstall] Error code 1

Stop in /usr/src.
*** [installworld] Error code 1

Stop in /usr/src.
*** Error code 1

Stop in /usr/src.


What's going on?

This is on sparc64 SunBlade 1500 silver,
updating to r244988.

The disk is:

# gpart show ad0
=>0  234432720  ad0  VTOC8  (111G)
  0   419464801  !0  (20G)
   41946480   335580002  !0  (16G)
   75504480  1589282404  !0  (75G)

# 

# df
Filesystem 512-blocks UsedAvail Capacity  Mounted on
/dev/ad0a40620236 21769888 1560073258%/
devfs   220   100%/dev
# 

I've run fsck -p before installworld,
and didn't see any problems.

Is my disk dying?

# fsck 
** /dev/ad0a (NO WRITE)
** Last Mounted on /
** Root file system
** Phase 1 - Check Blocks and Sizes
ad0: FAILURE - READ_DMA status=51 error=40 
LBA=23328672

CANNOT READ BLK: 23328608
CONTINUE? [yn] 

Thanks

Anton

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

installworld error: ad0: FAILURE - READ_DMA status=51 error=40 LBA=28071584

2013-01-04 Thread Anton Shterenlikht

I got this error on make installworld:

===> sbin/dhclient (install)
install -s -o root -g wheel -m 555   dhclient /sbin
ad0: FAILURE - READ_DMA status=51 error=40 
LBA=28071584
g_vfs_done():ad0a[READ(offset=14372651008, length=16384)]error = 5
vnode_pager_getpages: I/O read error
vm_fault: pager read error, pid 12794 (install)
install: /sbin/dhclient: Bad address
*** [_proginstall] Error code 71

Stop in /usr/src/sbin/dhclient.
*** [realinstall] Error code 1

Stop in /usr/src/sbin.
*** [realinstall] Error code 1

Stop in /usr/src.
*** [reinstall] Error code 1

Stop in /usr/src.
*** [installworld] Error code 1

Stop in /usr/src.
*** Error code 1

Stop in /usr/src.


What's going on?

This is on sparc64 SunBlade 1500 silver,
updating to r244988.

The disk is:

# gpart show ad0
=>0  234432720  ad0  VTOC8  (111G)
  0   419464801  !0  (20G)
   41946480   335580002  !0  (16G)
   75504480  1589282404  !0  (75G)

# 

# df
Filesystem 512-blocks UsedAvail Capacity  Mounted on
/dev/ad0a40620236 21769888 1560073258%/
devfs   220   100%/dev
# 

I've run fsck -p before installworld,
and didn't see any problems.

Thanks

Anton
___
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 amd64/amd64

2013-01-04 Thread FreeBSD Tinderbox

TB --- 2013-01-04 09:40:20 - tinderbox 2.10 running on freebsd-current.sentex.ca
TB --- 2013-01-04 09:40:20 - 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-01-04 09:40:20 - starting HEAD tinderbox run for amd64/amd64
TB --- 2013-01-04 09:40:20 - cleaning the object tree
TB --- 2013-01-04 09:40:20 - /usr/local/bin/svn stat /src
TB --- 2013-01-04 09:40:24 - At svn revision 245034
TB --- 2013-01-04 09:40:25 - building world
TB --- 2013-01-04 09:40:25 - CROSS_BUILD_TESTING=YES
TB --- 2013-01-04 09:40:25 - MAKEOBJDIRPREFIX=/obj
TB --- 2013-01-04 09:40:25 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2013-01-04 09:40:25 - SRCCONF=/dev/null
TB --- 2013-01-04 09:40:25 - TARGET=amd64
TB --- 2013-01-04 09:40:25 - TARGET_ARCH=amd64
TB --- 2013-01-04 09:40:25 - TZ=UTC
TB --- 2013-01-04 09:40:25 - __MAKE_CONF=/dev/null
TB --- 2013-01-04 09:40:25 - cd /src
TB --- 2013-01-04 09:40:25 - /usr/bin/make -B buildworld
>>> Building an up-to-date make(1)
>>> World build started on Fri Jan  4 09:40:29 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
[...]
c++  -O2 -pipe 
-I/src/lib/clang/libclangserialization/../../../contrib/llvm/include 
-I/src/lib/clang/libclangserialization/../../../contrib/llvm/tools/clang/include
 
-I/src/lib/clang/libclangserialization/../../../contrib/llvm/tools/clang/lib/Serialization
 -I. 
-I/src/lib/clang/libclangserialization/../../../contrib/llvm/../../lib/clang/include
 -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS 
-D__STDC_CONSTANT_MACROS -fno-strict-aliasing 
-DLLVM_DEFAULT_TARGET_TRIPLE=\"x86_64-unknown-freebsd10.0\" 
-DLLVM_HOSTTRIPLE=\"x86_64-unknown-freebsd10.0\" 
-DDEFAULT_SYSROOT=\"/obj/amd64.amd64/src/tmp\" 
-I/obj/amd64.amd64/src/tmp/legacy/usr/include -fno-exceptions -fno-rtti -c 
/src/lib/clang/libclangserialization/../../../contrib/llvm/tools/clang/lib/Serialization/ASTReaderDecl.cpp
 -o ASTReaderDecl.o
c++  -O2 -pipe 
-I/src/lib/clang/libclangserialization/../../../contrib/llvm/include 
-I/src/lib/clang/libclangserialization/../../../contrib/llvm/tools/clang/include
 
-I/src/lib/clang/libclangserialization/../../../contrib/llvm/tools/clang/lib/Serialization
 -I. 
-I/src/lib/clang/libclangserialization/../../../contrib/llvm/../../lib/clang/include
 -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS 
-D__STDC_CONSTANT_MACROS -fno-strict-aliasing 
-DLLVM_DEFAULT_TARGET_TRIPLE=\"x86_64-unknown-freebsd10.0\" 
-DLLVM_HOSTTRIPLE=\"x86_64-unknown-freebsd10.0\" 
-DDEFAULT_SYSROOT=\"/obj/amd64.amd64/src/tmp\" 
-I/obj/amd64.amd64/src/tmp/legacy/usr/include -fno-exceptions -fno-rtti -c 
/src/lib/clang/libclangserialization/../../../contrib/llvm/tools/clang/lib/Serialization/ASTReaderStmt.cpp
 -o ASTReaderStmt.o
c++  -O2 -pipe 
-I/src/lib/clang/libclangserialization/../../../contrib/llvm/include 
-I/src/lib/clang/libclangserialization/../../../contrib/llvm/tools/clang/include
 
-I/src/lib/clang/libclangserialization/../../../contrib/llvm/tools/clang/lib/Serialization
 -I. 
-I/src/lib/clang/libclangserialization/../../../contrib/llvm/../../lib/clang/include
 -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS 
-D__STDC_CONSTANT_MACROS -fno-strict-aliasing 
-DLLVM_DEFAULT_TARGET_TRIPLE=\"x86_64-unknown-freebsd10.0\" 
-DLLVM_HOSTTRIPLE=\"x86_64-unknown-freebsd10.0\" 
-DDEFAULT_SYSROOT=\"/obj/amd64.amd64/src/tmp\" 
-I/obj/amd64.amd64/src/tmp/legacy/usr/include -fno-exceptions -fno-rtti -c 
/src/lib/clang/libclangserialization/../../../contrib/llvm/tools/clang/lib/Serialization/ASTWriter.cpp
 -o ASTWriter.o
/src/lib/clang/libclangserialization/../../../contrib/llvm/tools/clang/lib/Serialization/ASTWriter.cpp:
 In member function 'void 
clang::ASTWriter::WriteSourceManagerBlock(clang::SourceManager&, const 
clang::Preprocessor&, llvm::StringRef)':
/src/lib/clang/libclangserialization/../../../contrib/llvm/tools/clang/lib/Serialization/ASTWriter.cpp:1558:
 internal compiler error: in var_ann, at tree-flow-inline.h:127
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
*** [ASTWriter.o] Error code 1

Stop in /src/lib/clang/libclangserialization.
*** [all] Error code 1

Stop in /src/lib/clang.
*** [cross-tools] Error code 1

Stop in /src.
*** [_cross-tools] Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
TB --- 2013-01-04 10:17:43 - WARNING: /usr/bin/make returned exit code  1 
TB --- 2013-01-04 10:17:43 - ERROR: failed to build world
TB --- 2013-01-04 10:17:43 - 1957.48 user 189.41 system 2243.16 real


http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-amd64-amd64.full
___
freebsd-current@freebsd.or

r245005M: NFSv4 usermapping not working anymore

2013-01-04 Thread O. Hartmann

Since yesterday's update and buildworld on two FreeBSD 10.0-CURRENT
boxes, i realize a strange behaviour. I have one server exporting via
NFSv4 several ZFS volumes. The UID mapping went pretty well so far, but
with a reboot of yesterday (after a buildworld), files are seen with uid
root:wheel and users are no longer seen.

The server and client in question are

server:   FreeBSD 10.0-CURRENT #2 r245005M: Thu Jan  3 20:25:00 CET 2013
client:  FreeBSD 10.0-CURRENT #2 r245005M: Thu Jan  3 20:27:25 CET 2013

I think this is not supposed to be that way. Another box, our lab's
server, doesn't show this phenomenon (but at the moment I have only the
opportunity to check with a FreeBSD 9.1-STABLE client). This specific
server is

server-1: FreeBSD 10.0-CURRENT #0 r244957: Wed Jan  2 12:06:13 CET 2013

By the way, can someone give me a hint why some boxes show up with an
attached "M" to the SVN revision number (like r245005M)?

Thanks,

oh



signature.asc
Description: OpenPGP digital signature

Re: loopback interface broken on current

2013-01-04 Thread Gary Jennejohn

On Thu, 03 Jan 2013 20:30:18 +0900
KAHO Toshikazu  wrote:

>   Hello, 
> 
> > There is still >ifa_del_loopback_route: deletion failed: 3
> > that wasn't there before,but the 127.0.0.1 seems to be configured now:
> 
>   Do you have a line like network_interfaces="lo0 bge0" in /etc/rc.conf?
> If you have it, try to remove it.
> 
>   I think something broken, but people using automatic configuration
> don't notice the breakage.
> 

Something is definitely broken because I don't have network_interfaces
in /etc/rc.conf but my lo0 does not have even ipv6 addresses assigned.

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

43 matches

Mail list logo