Re: vt(4) chops off the leftmost three columns

[Matthias Andree]

Am 14.01.2017 um 00:11 schrieb Alan Somers:
> I take it back.  The first three columns _are_ rendered, but they
> don't show up on some monitiors.  It's as if those monitors require a
> minimum amount of overscan on the left side of the screen, and vt(4)
> doesn't provide enough.  Can that be tuned?

Once upon a time, I've seen similar things on Linux, but with fewer
pixels offset, when switching framebuffer drivers - back then, the
scanning-VGA-timing was an issue. Is there any way to tweak the row and
column timings, with blank periods, viewport offsets and thereabouts?
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: security/openvpn build failure on 12-CURRENT/amd64

[Matthias Andree]

Hi Ngie,

Quite possibly an incompatibility between the port or the upstream software 
build/self-test rigging with the rather new FreeBSD 12-CURRENT. Since I do not 
have the latter, I am soliciting patches (through Bugzilla).

I am staring at 

 ff. and it does not make sense to me that or why it is failing. I am wondering 
if it is something specific to 12-CURRENT that does additional patching, or if 
sed(1) behaves in a different way. Insights welcome.

Cheers,
Matthias 

Am 1. August 2016 22:53:47 MESZ, schrieb Ngie Cooper :
>On Mon, Aug 1, 2016 at 7:31 AM, Shawn Webb 
>wrote:
>
>...
>
>> HardenedBSD's kernel and world matched and still had the very same
>> build error.
>>
>> Here's the build log: http://pastebin.com/TEBih1Sx
>
>Confirmed -- why's it looking for tcp6local/udp6local though (this
>isn't a valid protocol, and for some odd reason it's being picked up
>from the sample config file..?)? Looks like a port bug...
>Thanks,
>-Ngie
>
>$ sudo make -C /usr/ports/security/openvpn build
>...
>PASS: t_lpback.sh
>The following test will take about two minutes.
>If the addresses are in use, this test will retry up to two times.
>Options error: Bad protocol: 'udp6local'.  Allowed protocols with
>--proto option: [proto-uninitialized] [udp] [tcp-server] [tcp-client]
>[tcp] [udp6] [tcp6-server] [tcp6-client] [tcp6]
>Use --help for more information.
>Options error: Bad protocol: 'udp6local'.  Allowed protocols with
>--proto option: [proto-uninitialized] [udp] [tcp-server] [tcp-client]
>[tcp] [udp6] [tcp6-server] [tcp6-client] [tcp6]
>Use --help for more information.
>FAIL: t_cltsrv.sh
>
>1 of 2 tests failed
>(1 test was not run)
>Please report to openvpn-us...@lists.sourceforge.net
>
>*** [check-TESTS] Error code 1
>$ grep -r udp6local work/
>work/openvpn-2.3.11/sample/sample-config-files/loopback-client.test:proto
>udp6local ::1
>work/openvpn-2.3.11/sample/sample-config-files/loopback-server.test:proto
>udp6local ::1
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: security/openvpn build failure on 12-CURRENT/amd64

[Matthias Andree]

Hi Shawn,

The compilation attempt was done on an invalid configuration and has zero 
relevance whatsoever. As the log says:

!!! Jail is newer than host. (Jail: 121, Host: 1100116) !!! 
!!! This is not supported. !!! 
!!! Host kernel must be same or newer than jail. !!! 
!!! Expect build failures. !!!

I wish the builders would stop even trying to build a package on a kernel that 
is too old, it's just confusing and wasteful.

Am 1. August 2016 16:08:04 MESZ, schrieb Shawn Webb 
:
>Hey All,
>
>It looks like security/openvpn fails to build on 12-CURRENT/amd64 on
>both FreeBSD's and HardenedBSD's build infrastructure. I've verified
>that it builds fine on latest 11-STABLE/amd64. Would this be a
>regression in 12-CURRENT?
>
>Log file from FreeBSD's build:
>http://beefy4.nyi.freebsd.org/data/head-amd64-default/p419204_s303419/logs/errors/openvpn-2.3.11.log
>
>Thanks,
>
>-- 
>Shawn Webb
>Cofounder and Security Engineer
>HardenedBSD
>
>GPG Key ID:  0x6A84658F52456EEE
>GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89  3D9E 6A84 658F 5245 6EEE
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: What happened to DIOCGDINFO? Fwd: [package - head-amd64-default][misc/e2fsprogs-libblkid] Failed for e2fsprogs-libblkid-1.42.12 in build

[Matthias Andree]

Am 11.01.2015 um 04:05 schrieb Ian Lepore:

>>> Ident:  $FreeBSD: head/misc/e2fsprogs-libblkid/Makefile 370388 
>>> 2014-10-07 19:15:52Z mandree $
>>> Log URL:
>>> http://beefy2.isc.freebsd.org/data/head-amd64-default/2015-01-10_14h05m40s/logs/e2fsprogs-libblkid-1.42.12.log
>>> Build URL:  
>>> http://beefy2.isc.freebsd.org/build.html?mastername=head-amd64-default&build=2015-01-10_14h05m40s
>>> Log:
>>
>>> cc -I. -I../../lib -I../../lib 
>>> -I/wrkdirs/usr/ports/misc/e2fsprogs-libblkid/work/e2fsprogs-1.42.12/lib 
>>> -I/usr/local/include -D_THREAD_SAFE -O2 -pipe  -fstack-protector 
>>> -fno-strict-aliasing -std=gnu99 -DHAVE_CONFIG_H -c getsize.c -o getsize.o
>>> getsize.c:151:31: error: use of undeclared identifier 'DIOCGDINFO'
>>> if (part >= 0 && (ioctl(fd, DIOCGDINFO, (char *)&lab) >= 
>>> 0)) {
>>> ^
>>> 1 error generated.

> It was removed in r276737.  I don't know what replaces it.

Ted,

I am including a patch against e2fsprogs's "maint" branch to fix the
build on the future FreeBSD 11+ versions. Please apply.


Ian, Warner, *,

I think I've got a hold of this; the replacement appears to be
DIOCGMEDIASIZE from , and has been for more than a decade,
so that I had forgotten about it.

The e2fsprogs port has been using DIOCGMEDIASIZE for many years (phk
added DIOCGMEDIASIZE on 2002-04-08, I added upstream support 2003-12-28
but it underwent a few revisions, not worth bothering IMO)  judging from
the source code comments, but one of the two getsize.c source files -
the one in lib/blkid/ - lacks an #ifdef DIOCGDINFO guard and relies on
#ifdef HAVE_SYS_DISKLABEL_H only and jams the build. The other one in
lib/ext2fs/ had a guard that checked the actual ioctl #define.

Fix has been committed without Git markup in the FreeBSD ports tree,
r376742.

Thanks everybody.

Best regards,
Matthias
From 98ec1eeffd3e5752a775a73bec108945fe7a7a53 Mon Sep 17 00:00:00 2001
From: Matthias Andree 
Date: Sun, 11 Jan 2015 12:58:30 +0100
Subject: [PATCH] Fix build on FreeBSD 11 that removes DIOCGDINFO.

The replacement DIOCGMEDIASIZE has been in e2fsprogs since end of 2003,
but now the removal of the upstream system breaks the
lib/blkid/getsize.c build.  lib/ext2fs/getsize.c was unaffected because
it had already been checking if this ioctl symbol was #defined.

I haven't checked the situation on other BSDs, thus I am not sure if
others have DIOCGMEDIASIZE, so I propose to leave the DIOCGDINFO in.

Further cleanup opportunity:
consolidate lib/blkid/getsize.c and lib/ext2fs/getsize.c.

Signed-off-by: Matthias Andree 
---
 lib/blkid/getsize.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/lib/blkid/getsize.c b/lib/blkid/getsize.c
index a5c40aa..dc4cc1b 100644
--- a/lib/blkid/getsize.c
+++ b/lib/blkid/getsize.c
@@ -127,7 +127,7 @@ blkid_loff_t blkid_get_dev_size(int fd)
 			return (blkid_loff_t)this_floppy.size << 9;
 	}
 #endif
-#ifdef HAVE_SYS_DISKLABEL_H
+#if defined(HAVE_SYS_DISKLABEL_H) && defined(DIOCGDINFO)
 	{
 		int part = -1;
 		struct disklabel lab;
@@ -154,7 +154,7 @@ blkid_loff_t blkid_get_dev_size(int fd)
 return pp->p_size << 9;
 		}
 	}
-#endif /* HAVE_SYS_DISKLABEL_H */
+#endif /* defined(HAVE_SYS_DISKLABEL_H) && defined(DIOCGDINFO) */
 	{
 #if defined(HAVE_FSTAT64) && !defined(__OSX_AVAILABLE_BUT_DEPRECATED)
 		struct stat64   st;
-- 
2.2.1



signature.asc
Description: OpenPGP digital signature

What happened to DIOCGDINFO? Fwd: [package - head-amd64-default][misc/e2fsprogs-libblkid] Failed for e2fsprogs-libblkid-1.42.12 in build

[Matthias Andree]

Greetings,

I am getting new reports of package build failures on head (i386 and
amd64 have reported these so far):

> Ident:  $FreeBSD: head/misc/e2fsprogs-libblkid/Makefile 370388 
> 2014-10-07 19:15:52Z mandree $
> Log URL:
> http://beefy2.isc.freebsd.org/data/head-amd64-default/2015-01-10_14h05m40s/logs/e2fsprogs-libblkid-1.42.12.log
> Build URL:  
> http://beefy2.isc.freebsd.org/build.html?mastername=head-amd64-default&build=2015-01-10_14h05m40s
> Log:

> cc -I. -I../../lib -I../../lib 
> -I/wrkdirs/usr/ports/misc/e2fsprogs-libblkid/work/e2fsprogs-1.42.12/lib 
> -I/usr/local/include -D_THREAD_SAFE -O2 -pipe  -fstack-protector 
> -fno-strict-aliasing -std=gnu99 -DHAVE_CONFIG_H -c getsize.c -o getsize.o
> getsize.c:151:31: error: use of undeclared identifier 'DIOCGDINFO'
> if (part >= 0 && (ioctl(fd, DIOCGDINFO, (char *)&lab) >= 0)) {
> ^
> 1 error generated.

I haven't been watching 11-HEAD too closely, has this DIOCGDINFO symbol
been relocated to a different header, removed (because the feature is
going away -- and which would be the replacement), or is this a
temporary failure (inadvertent error)?

To the best of my knowledge, and without retrying builds, the package
builds fine on 8/9/10.

Thanks,
Matthias
___
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: pkg 1.4 freeze please test test test!

[Matthias Andree]

Am 03.11.2014 um 22:48 schrieb Freddie Cash:
> On Mon, Nov 3, 2014 at 1:40 PM, Hans Petter Selasky  wrote:
> 
>> Is it possible when upgrading a system via "pkg" to selectivly switch
>> upgrades ON/OFF. For example I have a custom ffmpeg install and would like
>> to keep it every time I do a binary upgrade?
>>
> 
> 
> ​# man pkg-lock
> 
> ;)
> 
> I believe that's what you are looking for.​  No idea how well it works
> long-term, though, or if you lock a large number of packages.

It used to refuse portmaster upgrades of a locked port and was thus
useless for mixed binary packages + portmaster use.  I haven't yet
checked if pkg 1.4 has fixed this.

___
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: 11-CURRENT redports builders miscompiling?

[Matthias Andree]

Am 07.10.2014 um 23:57 schrieb Matthias Andree:
> Am 07.10.2014 um 22:17 schrieb Antoine Brodin:
> 
>> So,  the test fail on head,  but if you look carefully,  1480342*1024
>> = 0x5a5a... which looks like malloc junk.
> 
> Bingo, thanks for the pointer.
> 
>> But when I turn off malloc debugging ( ln -s 'abort:false,junk:false'
>> /etc/malloc.conf ) the tests succeed.
>>
>> So it looks like a bug in e2fsprogs.
> 
> Yup, reproduced with "make post-build MALLOC_OPTIONS=J", and valgrind
> also has something to complain about, so I'll forward a report upstream.
> 
> I haven't seen something in the "maint" branch since the release that
> looks like an obvious fix.
> 
> This lets 11-CURRENT and redports off the hook for now.  I wasn't aware
> redports-on-11 set MALLOC_OPTIONS=J or equivalent.

I have bisected this on upstream's Git, and the failure-inducing change
is apparently 47fee2ef

<http://git.kernel.org/cgit/fs/ext2/e2fsprogs.git/commit/?h=maint&id=47fee2ef6a23ae06f680336ffde57caa64604a4c>

I reported this in greater detail to the authors/reviewers of the patch.

Let's see what we get.  For -current/-toolchain and decke@ I consider
this closed.

Thanks to Antoine for setting me on the right track.

Cheers,
Matthias
___
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: 11-CURRENT redports builders miscompiling?

[Matthias Andree]

Am 07.10.2014 um 22:17 schrieb Antoine Brodin:

> So,  the test fail on head,  but if you look carefully,  1480342*1024
> = 0x5a5a... which looks like malloc junk.

Bingo, thanks for the pointer.

> But when I turn off malloc debugging ( ln -s 'abort:false,junk:false'
> /etc/malloc.conf ) the tests succeed.
> 
> So it looks like a bug in e2fsprogs.

Yup, reproduced with "make post-build MALLOC_OPTIONS=J", and valgrind
also has something to complain about, so I'll forward a report upstream.

I haven't seen something in the "maint" branch since the release that
looks like an obvious fix.

This lets 11-CURRENT and redports off the hook for now.  I wasn't aware
redports-on-11 set MALLOC_OPTIONS=J or equivalent.

Cheers,
Matthias
___
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: 11-CURRENT redports builders miscompiling?

[Matthias Andree]

Am 07.10.2014 um 21:32 schrieb Antoine Brodin:
> On Tue, Oct 7, 2014 at 9:26 PM, Matthias Andree  wrote:
>> Greetings,
>>
>> I have just updated sysutils/e2fsprogs and its slave ports(*), and test
>> drove them on redports.  The self-test suite is failing on 11-CURRENT
>> i386 and amd64, but not on 10 or older releases.
>>
>> 11-amd64: https://redports.org/buildarchive/20141007190638-31576
>> 11-i386:  https://redports.org/buildarchive/20141007185700-4151
>>
>> I am now wondering
>> - if there are issues with the toolchain on 11 that causes
>> miscompilation, or
>> - whether 11 is misbehaving on redports, or
>> - if e2fsprogs has code bugs that don't show on older toolchains.
> 
> Hi,
> 
> e2fsprogs version 1.42.10 tests were succeeding in a jail with a world
> from r272576 (1.5 day old)
> 
> http://gohan2.ysv.freebsd.org/data/head-amd64-default-baseline/p370135_s272576/logs/e2fsprogs-1.42.10.log
> 
> (this is poudriere,  not tinderbox)

Hi Antoine,

merci for that.

There are probably multiple changes, so if someone else can take the
newer 1.42.12 for a test on 11-current, either on a naked system or with
poudriere, that will be appreciated.  What I find odd is that the
redports logs also show output deviations from expected, for instance,
here:

> ==> 
> /work/a/ports/sysutils/e2fsprogs/work/e2fsprogs-1.42.12/tests/r_resize_inode.failed
>  <==
> --- r_resize_inode/expect 2014-08-25 03:08:16.0 +
> +++ r_resize_inode.log2014-10-07 19:10:00.0 +
> @@ -1,7 +1,7 @@
>  mke2fs -q -F -O resize_inode -o Linux -b 1024 -g 1024 test.img 16384
>  resize2fs test.img 65536
>  Resizing the filesystem on test.img to 65536 (1k) blocks.
> -The filesystem on test.img is now 65536 (1k) blocks long.
> +The filesystem on test.img is now 65536 (1480342k) blocks long.
>  
>  Pass 1: Checking inodes, blocks, and sizes
>  Pass 2: Checking directory structure

The block size is bogus, and this happens on i386 and amd64 so is not
/obviously/ an issue of sizeof(long) or thereabouts.

Cheers,
Matthias
___
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"

11-CURRENT redports builders miscompiling? (was: svn commit: r370388 - in head: devel/e2fsprogs-libss misc/e2fsprogs-libblkid misc/e2fsprogs-libuuid sysutils/e2fsprogs sysutils/e2fsprogs/files)

[Matthias Andree]

Greetings,

I have just updated sysutils/e2fsprogs and its slave ports(*), and test
drove them on redports.  The self-test suite is failing on 11-CURRENT
i386 and amd64, but not on 10 or older releases.

11-amd64: https://redports.org/buildarchive/20141007190638-31576
11-i386:  https://redports.org/buildarchive/20141007185700-4151

I am now wondering
- if there are issues with the toolchain on 11 that causes
miscompilation, or
- whether 11 is misbehaving on redports, or
- if e2fsprogs has code bugs that don't show on older toolchains.

Any insights into the 11-CURRENT tool chain quality?

Thanks.


(*) as of SVN ports revision 370388.

Cheers,
Matthias
___
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: shells/bash port, add a knob which symlinks to /bin/bash ?

[Matthias Andree]

Am 12.09.2014 um 23:38 schrieb Bryan Drewery:

> The proper fix is to fix scripts to be portable and use #! /usr/bin/env
> bash rather than /bin/bash.

Proper portability means scripting for a POSIX sh, and /bin/sh can
handle those scripts.  In the majority of cases replacing == by = in
test or [ commands suffices.

> We install all packages to PREFIX=/usr/local by default. Why should a
> bin symlink be an exception? There's no suggestion for symlinking
> includes or libraries which also hit users often.

We'd need something for fsck and thereabouts though...  if /usr is on,
for instance, an ext2 file system (which is part of the kernel after
all), we need the tools early in the boot process, before /usr is there.
___
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: local_unbound update corrupts network accessibility!

[Matthias Andree]

Am 01.08.2014 um 18:25 schrieb O. Hartmann:
> 
> After the unbound update - or coinciding this update in CURRENT - I have 
> massive and
> disturbing problems connecting to some sites, email servers and even the SVN 
> server of
> FreeBSD (ports and src).
> 
> For some name resoltions I receive
> 
> Host xxx.xxx.de not found: 2(SERVFAIL), while another domain then gets 
> resolved without
> problems.

Are you using dnssec?  Check http://dnssec.vs.uni-due.de/

___
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: CURRENT: why is CURRENT swapping so fast?

[Matthias Andree]

Am 12.06.2014 00:36, schrieb O. Hartmann:
> 
> I use my boxes for daily work and in most cases, the usage of applications is 
> the same.
> Compiling the OS and updating ports while having claws-mail and firefox 
> opened is some
> usual scenario.
> 
> I realise since a couple of weeks, if not months now, but always sticky to 
> 11.0-CURRENT,
> that the system is even with 8 GB RAM very quickly out of memory and 
> swapping. As of
> today - updating CURRENT (buildword) and also updating ports. Nothing else 
> except
> firefox. And the box is using 1% swapspace.

Are you using ZFS, and more to the point, did you recently start using it?

Do you mean "start swapping out sooner than it used to do"?

Do you expect that swap remains at 0 unless there is serious memory
pressure?

One point: Linux rolls dice when it needs memory, with a tunable that
states the chance that either a cached page gets evicted, or an in-use
page gets swapped out.

Has FreeBSD similar mechanisms these days?

> There are some strange behaviours when compiling ports or the OS itself 
> sometimes. I very
> often linker errors with something like
> 
> [...] relocation truncated to fit: R_X86_64_PC32 [...]
> 
> This strange behaviour sometimes occurs immediately I switched on the box and 
> start
> updating and building world (nothing else done so far) or updating a port. 
> When this
> error occurs, I reboot and do the very same job again - and then suddenly it 
> works. It
> seems I can not reproduce this problem either. It occurs on 11.0-CURRENT 
> since a couple
> of weeks by now and affects different hardware types (as with the unspecific 
> swapping
> experience mentioned above, either 8GB and 32GB, but it occurs on the 8GB 
> bixes much more
> often than on the 32GB system).

Given memory checks did not turn up anything: Are you sure that
case/memory/chipset/CPU cooling are still intact and not hindered by dust?

___
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: md2 on current and 10.

[Matthias Andree]

Am 09.01.2014 02:59, schrieb Mikhail T.:
> On 08.01.2014 20:05, Peter Wemm wrote:
>> The path of least resistance is to make a libmd2 port.  It's the only way I
>> can see you getting to use it on 10.0.
> *I* don't really care. *I* don't use md2 myself. I became aware of the problem
> by accident -- because one of my ports was affected (tcl-trf). But I can fix 
> the
> port, no huhu.
> 
> It just seems to me, FreeBSD as a project goofed by abruptly removing the
> functions, that have been in the base for many years. But if the 
> src-committers
> don't care to "ungoof" it -- despite my raising awareness as much (and, 
> perhaps,
> even above) as permissible by politeness -- then so be it...

Mikhail,

There have been license concerns raised about the MD2 algorithm, and
apparently it is FreeBSD policy to not burden our users with
known/surprising license restrictions.  It would also appear that this
license policy would overrule compatibility with an old algorithm (MD2).

You have _not_ responded to these license concerns, but _only_ argued
with compatibility, and along the lines of user/maintainer convenience.

The MD2 functionality can be offered through a port, where it is much
easier to handle legal concerns.  It may be inconvenient to a
maintainer, and you may be disappointed or frustrated about a lack of a
proper discontinual phase, but I see a port as the _only_ viable option.
 Making a port use libmd2, or OpenSSL-from-ports-built-with-MD2 should
(1) satisfy compatibility and (2) base system licensing requirements,
all at the same time.

What is the reason why you don't find it acceptable to offer an option
to build your affected tcl-trf port against a ports OpenSSL?

Is there a technical concern beyond adding proper _DEPENDS lines?

Is there a social concern beyond the maintainer's one-time work?

Do we have a release note entry for MD2 removal?  (I haven't checked.)
If not, can we add it before 10.0-RELEASE given there is a -RC5 now?

Cheers,
Matthias

___
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: Are clang++ and libc++ compatible?

[Matthias Andree]

Am 12.11.2013 18:13, schrieb Zhihao Yuan:

> BTW, iirc VC STL has the same issue.  But libstdc++ has an honorable
> history of supporting incomplete type in STL declaration.

A disservice, not honorable.

Nonstandard extensions, however convenient, are a pain when writing
portable code.  I am usually setting -std=c++11 -pedantic first up these
days to avoid pitfalls later. (or -std=c11)  And hope the compiler
actually complains.
___
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: Official FreeBSD Binary Packages now available for pkgng

[Matthias Andree]

Am 02.11.2013 11:50, schrieb Matthew Seaman:
> On 02/11/2013 10:15, Matthias Andree wrote:
>> I understand from Eric's pist that the issue is that through his
>> limiting proxies, the SRV are not available at all so he does not even
>> get to the point where he could get the pkgN.nyi.freebsd.org
>> <http://pkgN.nyi.freebsd.org> name back.
> 
> That doesn't make sense.  All the DNS SRV lookups on pkg.freebsd.org are
> done internally to pkg(8), which then issues an HTTP GET to the specific
> mirror selected by its internal algorithms.  The web cache won't see
> literal 'pkg.freebsd.org' anywhere in the HTTP traffic -- as far as it
> is concerned, it's a simple HTTP request to a specific mirror
> 'pkg1.nyi.freebsd.org', and can be cached using the usual processes.
> 
> What makes it cache unfriendly is that as far as the web cache is
> concerned each of the different mirrors appears to be completely
> independent of the others.  So at the moment the chance of getting a
> cache hit is reduced by a factor of three because of the traffic
> distribution across the three mirrors.

I think it does make sense - if the end user is behind a site where he
must use a proxy because his end user's computer does not resolve any
external addresses, then SRV is not getting you anywhere and you need a
HTTP(S)-based redirector.

___
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: Official FreeBSD Binary Packages now available for pkgng

[Matthias Andree]

Matthew Seaman  schrieb:
>On 02/11/2013 01:55, Eric van Gyzen wrote:
>> This kind of proxy configuration is not uncommon.  It would be
>awesome
>> if this would Just Work.  It would remove an impediment to adoption,
>> which is especially important in the kind of environments that have
>this
>> kind of proxy configuration.
>> 
>> Simply adding the mirrors' A (and ) records to pkg.freebsd.org
>might
>> suffice.
>
>You seem hung up on the idea that pkg.freebsd.org should resolve to a
>list of IP addresses.  It doesn't and for very good reasons.
>Admittedly, using eg. 'http://' as the URL scheme for PACKAGESITE URLs
>was an error -- it contravenes RFC 2616 -- which is why we will be
>switching to a new 'pkg+http://' (or 'pkg+https://', 'pkg+ftp://',
>etc.)
>set of URL schemes with pkg-1.2.x
>
>There certainly are all of the necessary A and  records in the DNS
>for the real servers that host the repositories.
>
>If I understand what you're complaining about is that you see behavious
>like the following:
>
>   * You download package foo-1.2.3.txz from pkg.freebsd.org
>
>   * Internally, that gets resolved to an HTTP request to eg.
> pkg0.isc.freebsd.org
>
>   * Your web proxy caches this package
>
>   * On another host, you also want to download foo-1.2.3.txz
>
>   * This time the SRV record gets resolved to a different mirror,
> say pkg1.nyi.freebsd.org
>
>   * Your proxy has no way of knowing that foo-1.2.3.txz from pkg1.nyi
> is exactly the same file as foo-1.2.3.txz from pkg0.isc so it
> downloads the whole package all over again.
>
>Yes, this is certainly undesirable behaviour.  I need to run some tests
>to determine if this is actually what does happen in practice.  If so,
>I've an idea about how this problem might be addressed, but it will
>require some changes to the repository configuration.
>
>In the mean time, I suggest just choosing which ever of the
>pkg.freebsd.org repositories is closest to you and using it directly --
>eg.
>
>cat < /usr/local/etc/pkg/repos/myrepo.conf
>pkg0.isc {
>url: http://pkg0.isc.freebsd.org/${ABI}/latest
>enabled: yes
>mirror_type: none
>}
>EOF
>
>Obviously, substitute which ever one of
>
>   pkg0.isc.freebsd.org   (US West)
>   pkg1.nyi.freebsd.org   (US East)
>   pkg0.bme.freebsd.org   (Europe)
>
>is appropriate.  And be prepared to deal with that specific mirror
>being
>down or replaced by some other server.
>
>> Alternatively, running an HTTP-redirection service on a host named
>> pkg.freebsd.org would offer as much flexibility as the SRV records,
>if
>> not more.  However, it would require maintenance of yet another
>central
>> service.
>
>This is already supported in pkg when using the HTTP mirror type.  This
>would entail significantly more administrative effort and hardware
>requirement to maintain and keep consistent in the specific case of
>pkg.freebsd.org  which is exactly why the SRV mirror type was selected.
>
>   Cheers,
>
>   Matthew
>
>
>-- 
>Dr Matthew J Seaman MA, D.Phil.
>PGP: http://www.infracaninophile.co.uk/pgpkey

I understand from Eric's pist that the issue is that through his limiting 
proxies, the SRV are not available at all so he does not even get to the point 
where he could get the pkgN.nyi.freebsd.org name back.
___
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: latest sbin/pkg updates seem to break HEAD

[Matthias Andree]

Am 26.10.2013 14:42, schrieb Rainer Hurling:
> Am 26.10.2013 13:04, schrieb Matthias Andree:
>> Am 26.10.2013 12:56, schrieb Rainer Hurling:
>>> After svn update my 11.0-CURRENT box to r257152, the build breaks.
>>> Obviously there is something wrong with the newest patches for sbin/pkg
>>> (or libcrypt). Am I the only one observing this?
>>>
>>> Any help is appreciated,
>>> Rainer Hurling
>>>
>>>
>>> [..snip..]
>>> ===> usr.sbin/pkg (all)
>> ...
>>> cc  -O2 -pipe  -I/usr/src/usr.sbin/pkg/../../contrib/libyaml/include 
>>> -std=gnu99 
>>> [...]
>>> -L/usr/obj/usr/src/tmp/usr/lib/private -rpath /usr/lib/private -o pkg
>>> pkg.o dns_utils.o config.o -larchive -lelf -lfetch -lyaml -lsbuf -lssl
>>>
>>> /usr/obj/usr/src/tmp/usr/bin/ld: D: invalid DSO for symbol `EVP_PKEY_free' 
>>> definition

This means that the indirect dependency pulled in from one of the given
libraries (-lssl in this case) is not eligible for resolving
EVP_PKEY_free(), because the library that provides this EVP_PKEY_free()
is not mentioned explicitly on the linker's command line.

>>> /usr/obj/usr/src/tmp/lib/libcrypto.so.7: could not read symbols: Bad value

...and this line translates to "libcrypto.so.7: was brought in as
indirect dependency, could resolve your missing symbol, but is not
permitted to. Add -lcrypto explicitly to the linker command line."

Arguably Fedora Linux offers nicer error messages if the screenshot
(URL/quote below) is authentic.

>>> cc: error: linker command failed with exit code 1 (use -v to see invocation)
>>> *** Error code 1
>>> Stop.
>>> make[4]: stopped in /usr/src/usr.sbin/pkg
>>
>> These can happen if a library is missing, for instance, -lcrypto is
>> apparently not mentioned on the linker's command line, but AFAIR the
>> clang linker accepts no unresolved symbols from .so when linking
>> executables, and -lssl likely needs -lcrypto.  This avoids run-time
>> surprises due to missing dependencies (on libcrypto, in this case).
>>
>> Try pasting that command line with -lcrypto added after -lssl, and if
>> that helps, try to debug where the -lcrypto has been or gets lost, or
>> should get added.
>>
>> HTH
> 
> Yep, adding -lcrypto seems to help. I patched usr.sbin/pkg/Makefile for it.
> 
> But I am wondering if nobody else has this problem? I did not change my
> systems sources before.

Greetings,

I discussed this a bit with Bryan Drewery on IRC, and the information
pieces that I will post here for posterity and to have this in the
archives are:

1. pkg itself calls the EVP_*() functions from libcrypto.

2. on bdrewery's system, the linker pulled libcrypto in through libssl
as an indirect dependency.  It was not supposed to do that, but happened
- as to why, we don't know.

3. The general idea, that bdrewery agrees to, is that all shared
dependencies must be specified directly on the linker's command line.
<http://fedoraproject.org/wiki/UnderstandingDSOLinkChange>
this has the screenshot with a nicer error message:

> /usr/bin/ld.bfd: rpmdumpheader.o: undefined reference to symbol 'Fopen'
> /usr/bin/ld.bfd: note: 'Fopen' is defined in DSO /usr/lib/librpmio.so.0 so 
> try adding it to the linker command line
> /usr/lib/librpmio.so.0: could not read symbols: Invalid operation

4. It's not necessarily clang that causes it, but either gold, or a
change to FreeBSD's ld in Late July that disabled the use of indirect
dependencies
<http://svnweb.freebsd.org/base?view=revision&sortby=date&revision=253839>.

Hope that helps.

Best regards
Matthias
___
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: latest sbin/pkg updates seem to break HEAD

[Matthias Andree]

Am 26.10.2013 12:56, schrieb Rainer Hurling:
> After svn update my 11.0-CURRENT box to r257152, the build breaks.
> Obviously there is something wrong with the newest patches for sbin/pkg
> (or libcrypt). Am I the only one observing this?
> 
> Any help is appreciated,
> Rainer Hurling
> 
> 
> [..snip..]
> ===> usr.sbin/pkg (all)
...
> cc  -O2 -pipe  -I/usr/src/usr.sbin/pkg/../../contrib/libyaml/include
> -std=gnu99 -Qunused-arguments -fstack-protector -Wsystem-headers -Werror
> -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes
> -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual
> -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align
> -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls
> -Wold-style-definition -Wmissing-variable-declarations -Wno-pointer-sign
> -Wno-empty-body -Wno-string-plus-int
> -L/usr/obj/usr/src/tmp/usr/lib/private -rpath /usr/lib/private -o pkg
> pkg.o dns_utils.o config.o -larchive -lelf -lfetch -lyaml -lsbuf -lssl
> 
> /usr/obj/usr/src/tmp/usr/bin/ld: D: invalid DSO for symbol
> `EVP_PKEY_free' definition
> /usr/obj/usr/src/tmp/lib/libcrypto.so.7: could not read symbols: Bad value
> cc: error: linker command failed with exit code 1 (use -v to see invocation)
> *** Error code 1
> Stop.
> make[4]: stopped in /usr/src/usr.sbin/pkg

These can happen if a library is missing, for instance, -lcrypto is
apparently not mentioned on the linker's command line, but AFAIR the
clang linker accepts no unresolved symbols from .so when linking
executables, and -lssl likely needs -lcrypto.  This avoids run-time
surprises due to missing dependencies (on libcrypto, in this case).

Try pasting that command line with -lcrypto added after -lssl, and if
that helps, try to debug where the -lcrypto has been or gets lost, or
should get added.

HTH

___
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: newcons comming

[Matthias Andree]

Am 25.10.2013 14:18, schrieb Aleksandr Rybalko:
> Hello fellow hackers!
> 
> I finally reach the point when I can work with newcons instead of
> syscons on my laptop. Yes, I know it still buggy and have a lot of
> style(9) problems. But we really have to get it into HEAD and 10.0 to
> enable shiny new Xorg features, drivers, etc.
> 
> So I ask everyone to look "hard" into that[1] and tell me your opinion.
> I expect a lot of opinions, since it have to affect almost all good
> guys, as result I have to ask to split "bug reports" into two parts:

It should only get in a "stable" (10/STABLE) version when it is solid,
stable, and free of known bugs.  Thus, please have it matured in 11/HEAD
for now, and merge when it's ready.  If that means going a point release
with older xorg stuff, then we have to live with that.

Especially if I read further down the thread that newer xorg depends on
newcons - there would be no way back for xorg should more serious issues
come up (and we cannot possibly test everything on the developer's end -
some things will only come up as users upgrade/install from 10.0-RELEASE
DVDs), which is a bigger risk.

Rather old xorg with known issues, than random regressions that might
leave us with a new xorg but _newly_ does not work at all for users,
without any other way to go back but "use 9.2".

___
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: portmaster

[Matthias Andree]

Am 17.09.2013 01:04, schrieb ajtiM:
> Again me…
> I was (am) long postmaster user. Is it possible to use on FreeBSD 10 too, 
> please? Or is better to use something different?

Portmaster works for me on FreeBSD 10-CURRENT. Be sure to use an
up-to-date ports tree and install an up-to-date portmaster.

___
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: dns/libidn puzzle

[Matthias Andree]

Am 12.09.2013 23:44, schrieb Walter Hurry:
> On 9.1, if I cd to /usr/ports/dns/libidn and issue 'sudo make config', I 
> get a dialog asking me whether I want DOCS and/or NLS.
> 
> However, on 10-CURRENT (r255358) I get this:
> 
> $ cd /usr/ports/dns/libidn
> $ sudo make config
> ===> Options unchanged
> $ 
> 
> Why the difference?

Is dialog4ports installed on your 10-CURRENT?

___
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: [PATCH] mtree should not output size if the file is not a regular file

[Matthias Andree]

Am 10.09.2013 01:51, schrieb Christos Zoulas:
> On Sep 10,  1:21am, d...@des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) wrote:
> -- Subject: Re: [PATCH] mtree should not output size if the file is not a reg
> 
> | Roll a large tarball (e.g. a complete FreeBSD installation).  Copy it to
> | different machines with different filesystems.  Untar and run mtree on
> | the result.  Notice that you get different output on each machine
> | because they report different sizes for directories; one might report
> | the actual on-disk size (which might vary depending on past contents)
> | while the other might report the number of entries.
> 
> Yes, I agree. I would like to note that the current NetBSD code looks like:
> 
> if (keys & F_SIZE &&
>   (flavor != F_NETBSD6 || S_ISREG(p->fts_statp->st_mode)))
> 
> which means that F_NETBSD6 did not print this, and we recently changed
> it to print the size for compatibility with F_FREEBSD9... We also made
> the default F_MTREE format to print the size. So I guess the thing to
> do is change the code to:
> 
> if (keys & F_SIZE &&
>   (flavor == F_FREEBSD9 || S_ISREG(p->fts_statp->st_mode)))

Uh, does that flavor == F_FREEBSD9 solve a real problem?  Or is it just
to reflect some syntax without proper semantics?

Or is this just gratuitious because someone else does nonsense we need
to do it, too?

Or is it required to cater for expectations on the other end (when
reading such an mtree description)?

If not, let's just drop the size where it's meaningless.  It's meant for
the next major update, after all.  If necessary, bump the OSREVISION.

___
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: Building current no longer possible on 8.2, worked 7 days ago

[Matthias Andree]

Am 20.05.2013 15:49, schrieb Ulrich Spörlein:
> Hey all,
> 
> I'm running the coverity builds/scan on a 8.2 VM, buildworld was fine 7d
> ago, now it's kaput:

...

> This is on src r250825 and the host is running
> FreeBSD scan.freebsd.your.org 8.2-STABLE FreeBSD 8.2-STABLE #2 r223420: Wed 
> Jun 22 11:15:56 UTC 2011
> u...@scan.freebsd.your.org:/usr/obj/usr/src/sys/GENERIC  amd64

In case you haven't noticed, FreeBSD 8.2 went out of support end of July
2012, i. e. 10 months ago...

___
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: Any objections/comments on axing out old ATA stack?

[Matthias Andree]

Am 20.04.2013 23:29, schrieb Jeremy Chadwick:

>> My feeling is that the stalls are mostly from the error handler and the
>> overall time the drive is "frozen" gets shorter. If it had not _felt_
>> faster, I'd not have left that in sysctl.conf in the first place.
> 
> Your understanding of what that sysctl does is wrong, or I'm
> misunderstanding what you're saying (very possible!).

What I am saying is a high-level view on the situation.

If I leave the default slot timeout set, whenever the computer gets into
an episode of stalls, it becomes unusable (all I/O stalled so anything
that needs disk I/O will hang) for so long that it is much faster to
depress the reset button, reboot, force fsck, and retry.

This usually entails hand-holding and manually cleaning up debris, such
as b0rked .o files from a buildworld, or similar.

These stalls happens out of the middle of the buildworld, under heavy
I/O, so I'd dispute excessive head unloading and drive spindown is the
issue -- the computer (and fans in particular) is generally very quiet,
no VGA board (just fanless onboard Radeon HD 3300), I could hear
re-spinups or parking heads.  I don't hear anything like it.

I don't know how rescheduling commands that timed out and get
rescheduled happens overall.

> How I interpret what you're saying: that the sysctl somehow "decreases
> stall times" during I/O operations that fail.  This is incorrect.

That may not be the intention of the sysctl, but it is the high-level
outcome.

> What that sysctl does is define the number of seconds that transpire
> ***before*** the CAM layer says "Okay, I didn't get a response to the
> ATA CDB I sent the disk", and then re-submits the same CDB to the disk.

The other question (to Alexander Motin) then is why do I see the
timeouts for the related slots rougly $timeout seconds apart.

Alexander, is there any way we can make the kernel dump the entire set
of pending NCQ queue entries including submitted timestamp, or timeout
values, so that we can see how much workload is queued?

Note also that the CRC count has not increased since I've put the
smartctl output online, it's still at 14 -- I would have to see CRC
errors and their consequences in Linux or Windows, too.

Linux's smartd 5.41 never mailed about an increase of the CRC value, and
I told it not to mail temperature changes.

> Rephrased: in the case of a disk stalling on an I/O request, you will
> experience the effects of that stall no matter what that sysctl is set
> to.  A lower value in that sysctl will result in CAM spitting out
> nasties on the console + hitting the CDB retry submission scenario
> sooner, which if the drive is awake/responsive by that time will go
> smoothly.
> 
> That's all it does.

That's how you have explained and I have understood it on the queue-slot
level (microscopic), but at a larger scale, I do not observe that the
shorter timeout sysctl value led to these stall episodes happen more
often (as should be the consequence if spindown were the cause of the
stalls), only recovery is faster.

> Thus a value of 5 indicates a device/drive did not respond to a CDB
> within 5 seconds, and a value of 30 indicates a device/drive did not
> respond to a CDB within 30 seconds.  Regardless, those lengths of time
> are VERY long for an I/O operation on a mechanical HDD.

Indeed they are, and because /usr is on the offending drive, I lowered
the value to 5 s, which I still deem conservative.  I know that an older
ATA standard edition permitted longer completion times for flushing HDD
internal write caches to platters (15 s IIRC).

> Oh look, it's the Samsung SpinPoint series, especially the EcoGreen
> ("EG") series.  No joke: ~60% of the "problem reports" I deal with when
> it comes to "weird wonky problems" stem from this drive series.  I have
> no idea why, but they're a common pain point for me.

I know they are, especially the larger siblings 1.5 G up.

> Politely, your analysis of the drive ("looks sane to me") is an
> indicator of why SMART output needs to be interpreted by a person who is
> familiar with the information.  That drive *does not* look sane to me.
> :-)

14 CRC errors with a drive that moved through computers that got
modified over time, that does not run the whole day, and that was first
attached to a computer whose controller (VIA garbage) could only talk to
1.5 Gb/s ATA drives but not 3 Gb/s is not something I care about.

> Key points about these errors:
> 
[...]

> - These are conditions that short, long, select (LBA range scan), and
>   conveyance SMART tests would probably not detect.  Like I said: it
>   seems to be all over the board.

I agree that it is more likely to be a communications issue between
FreeBSD and the drive's logic, with all components, hard- and software
involved.

> Bernd Walter responded indicating that his experience indicated that the
> issue related to NCQ compatibility.  This would not surprise me.

Neither would it surprise me, but Linux should suffer, too, the

Re: Any objections/comments on axing out old ATA stack?

[Matthias Andree]

Am 04.04.2013 03:05, schrieb Jeremy Chadwick:

>>> Please provide "gpart show -p ada1" output, both here and in the PR,
>>> if you could.
>>
>> =>63  1953525105ada1  MBR  (931G)
>>   63   209714337  ada1s1  freebsd  [active]  (100G)
>>209714400 800  - free -  (400k)
>>2097152007168  ada1s2  ntfs  (34G)
>>281395200   15405  - free -  (7.5M)
>>281410605   488263545  ada1s3  linux-data  (232G)
>>769674150  1183851018  - free -  (564G)

Thanks for all the useful information provided so far (including further
down).  I know some of that already, but am not going to complain
because it is very useful in the logs.

> The problem here is that I cannot guarantee you that alignment is
> the problem.  The performance impact of writes to partitions which are
> non-aligned is quite high, and NCQ just exacerbates this problem.  I
> would love to tell you "switch to GPT and follow Warren Block's
> document***" but if your NTFS partition is Windows and is a Windows version
> older than Windows 7 GPT is not supported.

I am happy to make that realign-and-use-GPT experiment.
My Windows is "7 Professional 64-bit".

It will take me a few days because this is spare-time stuff.

> One piece of evidence that refutes my theory is that if Windows and/or
> Linux partition are something you boot into and use often, I would
> imagine NCQ would be used in both of those environments and would suffer
> from the same issue.  Although Windows tends to hide all sorts of
> transient errors from the user (sigh), Linux tends to be like FreeBSD
> with regards to such issues (on the console anyway; you wouldn't see
> such messages normally inside of X).

Now, the FreeBSD slice is the only partition on that disk that would
likely see concurrent write accesses (think "make -j8" on a quadcore
computer) which is more prone to ferret out such alignment contention.

The NTFS partition is aligned on a multi-MB boundary, so wouldn't hit
the problem anyways.

The Linux partition is in ext4 format for mostly sequential access to
files usually in excess of 10 MB each.

Linux's ext4 jumps through several hoops to end up with bulk writes,
like extents, delayed allocations (to avoid fragmentation), reordering
of data and metadata writes, serialized log writes and all that stuff,
and it would appear I am permitting it to cache writes -- Linux uses
write barriers to enforce proper ordering of journal/meta-data writes.

It would be rather hard to hit ATA taskfile timeouts, the expected rate
with which the drive needs to do a partial write is orders of magnitude
lower.

Any good "concurrent write" exercise tools for Unix that I could run on
the Linux ext4 partition that you would propose?

> If you have the time and want to put forth the effort, I would recommend
> backing up all your data on ada1, zero the first and last 1MByte of the
> drive, and then try following Warren Block's guide.  I'd just recommend
> doing this:
> 
> gpart create -s gpt ada1
> gpart add -t freebsd-ufs -b 2m ada1
> newfs -U -j /dev/ada1p1   (or remove -j if you don't want to use SUJ)

Will do.

>> - I am running with kern.cam.ada.default_timeout=5 which makes the
>> computer recover faster
> 
> I can definitely imagine cases where a drive using NCQ but doing writes
> to a non-aligned partition could take longer than 5 seconds to respond
> to an ATA CDB (this is different than a SATA or AHCI layer timeout).  I am
> not telling you "change this back to 30", but it might not be helping
> your situation at all given my above theory.

My feeling is that the stalls are mostly from the error handler and the
overall time the drive is "frozen" gets shorter. If it had not _felt_
faster, I'd not have left that in sysctl.conf in the first place.

> Finally: could you please provide output from "smartctl -x /dev/ada1"?
> I would like to rule out any possibility of your drive having some other
> kind of issue that might cause it to go catatonic.  Thanks.

I have fetched the data with Linux this time (should not make a
difference as it's all drive internal data, not host OS stuff).

Looks sane to me, .
I'll be happy to refetch this data with a more current smartctl version
under FreeBSD if required.

> 
> 
> ** -- 
> http://www.seagate.com/files/www-content/support-content/documentation/samsung/tech-specs/eco_greenf2.pdf
> 
> *** -- http://www.wonkity.com/~wblock/docs/html/ssd.html
> 




signature.asc
Description: OpenPGP digital signature

Re: Any objections/comments on axing out old ATA stack?

[Matthias Andree]

Am 04.04.2013 01:38, schrieb Jeremy Chadwick:

...

> While skimming Linux libata code and commits in the past, the only
> glaringly obvious bug/issue I see is with SB600/SB700 chipsets (the
> hardware revision apparently matters) and port multiplier (PMP) support
> and soft resets.
> 
> Are you using a port multiplier?  I doubt it, but I have to ask.

I am not using a PMP as far as I know (unless one is buried on my Asus
M4A78T-E main board). It would seem the drives are directly attached to
the south bridge's SATA ports.

>> Why only my Samsung HDD drive triggers this but not the WD drive, I do
>> not know yet.
> 
> Please provide "gpart show -p ada1" output, both here and in the PR,
> if you could.

=>63  1953525105ada1  MBR  (931G)
  63   209714337  ada1s1  freebsd  [active]  (100G)
   209714400 800  - free -  (400k)
   2097152007168  ada1s2  ntfs  (34G)
   281395200   15405  - free -  (7.5M)
   281410605   488263545  ada1s3  linux-data  (232G)
   769674150  1183851018  - free -  (564G)

HTH

Best regards
Matthias



signature.asc
Description: OpenPGP digital signature

Re: Any objections/comments on axing out old ATA stack?

[Matthias Andree]

I have just sent more information to the PR at
http://www.freebsd.org/cgi/query-pr.cgi?pr=157397

The short summary (more info in the PR) is:

- limiting tags to 31 does not help

- disabling NCQ appears to help in initial testing, but warrants more
testing

- error happens during WRITE_FPDMA_QUEUED,

- File system in question is SU+J UFS2 mounted on /usr, and I can for
instance "rm -rf /usr/obj" or just log into GNOME and try to open a
gnome-terminal to trigger stalls;

- Linux uses 31 tags (for different reason) and has no drive quirks, but
a controller quirk;

for Jeremy's topic #6, regarding the ATI/AMD SB7x0 that I am using, it
might be worthwhile investigating the AHCI_HFLAG_IGN_SERR_INTERNAL flag
- it gets set by Linux on the SB700 that my computer is using, see
ahci_error_intr() in libahci.h - I am not going to interpret that for
lack of expertise, but it does affect error handling and appears to
ignore a certain condition.

Why only my Samsung HDD drive triggers this but not the WD drive, I do
not know yet.

Hope that helps a bit.




signature.asc
Description: OpenPGP digital signature

Re: Any objections/comments on axing out old ATA stack?

[Matthias Andree]

Am 31.03.2013 23:02, schrieb Scott Long:

> So what I hear you and Matthias saying, I believe, is that it should be 
> easier to
> force disks to fall back to non-NCQ mode, and/or have a more responsive
> black-list for problematic controllers.  Would this help the situation?  It's 
> hard to
> justify holding back overall forward progress because of some bad controllers;
> we do several Tbps off of AHCI controllers with NCQ enabled on FreeBSD 9.x,
> enough to make up a sizable percentage of the internet's traffic, and we see 
> no
> problems.  How can we move forward but also take care of you guys with
> problematic hardware?

Well, I am running the driver fine off of my WD Caviar RE3 disk, and the
problematic drive also works just fine with Windows and Linux, so it
must be something between the problematic drive and the FreeBSD driver.

I would like to see any of this, in decreasing order of precedence:

- debugged driver

- assistance/instructions on helping how to debug the driver/trace NCQ
stuff/...  (as in Jeremy Chadwick's followup in this same thread - this
helps, I will attempt to procure the required information; "back then",
reducing the number of tags to 31 was ineffective, including an error
message and getting a value of 32 when reading the setting back)

- "user-space" contingency features, such as letting camcontrol limit
the number of open NCQ tags, or disable NCQ, either on a per-drive basis

I am capable of debugging C - mostly with gdb command-line, and
graphical Windows IDEs - but am unfamiliar with FreeBSD kernel
debugging. If necessary, I can pull up a second console, but the PC that
is affected is legacy-free, so serial port only works through a
serial/USB converter.



signature.asc
Description: OpenPGP digital signature

Re: Any objections/comments on axing out old ATA stack?

[Matthias Andree]

Am 31.03.2013 06:00, schrieb Peter Wemm:

> We're talking about 10.x, so if you want it fixed, you need update
> with 10.x information.
> 
> Please put 10.x diagnostics in the PR.

I will not.  The PR was filed four months before 10-CURRENT branched;
I have no reason to assume it were to be no longer pertinent -- no MFCs,
no PR followups).

(according to
,
10-CURRENT appeared on 2011-09-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: Any objections/comments on axing out old ATA stack?

[Matthias Andree]

Am 27.03.2013 22:22, schrieb Alexander Motin:
> Hi.
> 
> Since FreeBSD 9.0 we are successfully running on the new CAM-based ATA
> stack, using only some controller drivers of old ata(4) by having
> `options ATA_CAM` enabled in all kernels by default. I have a wish to
> drop non-ATA_CAM ata(4) code, unused since that time from the head
> branch to allow further ATA code cleanup.
> 
> Does any one here still uses legacy ATA stack (kernel explicitly built
> without `options ATA_CAM`) for some reason, for example as workaround
> for some regression? Does anybody have good ideas why we should not drop
> it now?

Alexander,

The regression in http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/157397
where the SATA NCQ slots stall for some Samsung drives in the new stack,
and consequently hang the computer for prolonged episodes where it is in
the NCQ error handling, disallows removal of the old driver. (Last
checked with 9.1-RELEASE at current patchlevel.)

Chances are that limiting the open queue slots to 31 might help, but
that is hearsay from what Linux would be doing.

Unless we get a fix, if you want to drop the old driver, you'll need to
add features so that

1. the new driver to lets users (down-)configure the max. number of
tagged openings

2. the new driver allows disabling NCQ altogether for individual drives

3. list the relevant Samsung drives in some quirks data base so that we
avoid the stalls while permitting users to "open it up to 32 NCQ slots".

So unless these are all addressed, I'd veto removal of the old ATA
driver - sorry!

Best regards
Matthias




signature.asc
Description: OpenPGP digital signature

Re: Changes to sbin/init/init.c (r233944) makes x11/xdm impossible to start from /etc/ttys

[Matthias Andree]

> The error xdm is loggin is:
> 
> ===
> Build Date: 07 April 2012  04:51:08PM
> 
> Current version of pixman: 0.24.2
> Before reporting problems, check http://wiki.x.org
> to make sure that you have the latest version.
> Markers: (--) probed, (**) from config file, (==) default setting,
> (++) from command line, (!!) notice, (II) informational,
> (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
> (==) Log file: "/var/log/Xorg.0.log", Time: Sat Apr  7 18:38:24 2012
> (==) Using config file: "/etc/X11/xorg.conf"
> xdm info (pid 2055): sourcing /usr/local/share/X11/xdm/Xsetup_0
> xdm error (pid 2050): Unknown session exit code 2560 from process 2055

BTW, there is an unrelated xdm error that I'd suggest you report to the
xdm maintainer - the exit code cannot be 2560; this means that xdm
doesn't process the wait/waitpid/wait3/wait4 status with
WIFEXITED/WIFSIGNALED/WEXITSTATUS/WTERMSIG.  The exit code was 10 in
this situation. (See /usr/include/sys/wait.h)
___
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: -ffast-math in Ports and wrong generated code

[Matthias Andree]

Am 03.04.2012 13:21, schrieb Andrey Simonenko:
> Hello,
> 
> I use one port from the Ports Collection, that works with FP.  Having
> reinstalled it (its version was not changed) I noticed that it started
> to work incorrectly.  After debugging and disassembling its code I found
> out that the -ffast-math option used for building was the result of
> wrongly generated code (I did not specify this option in /etc/make.conf).
> 
> At least finite() function call was eliminated from the result Assembler
> code when -ffast-math option is used, tested on 9.0-STABLE and 10.0-CURRENT.
> 
> Example test source code and generated code under 9.0-STABLE on amd64
> by gcc from the base system:

- Which port is affected?

- Any idea whence the -ffast-math option came on your system?
/etc/src.conf? Port's "make config"?
___
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: Using TMPFS for /tmp and /var/run?

[Matthias Andree]

Am 30.03.2012 21:36, schrieb Adrian Chadd:
> Let me tell you a story.
> 
> Someone decided that ext4 could have a decent speed up if it
> implemented the posix standard for not flushing files on close().
> After all, if you needed it to be guaranteed to be written to disk,
> you would call a flush routine first, before you called close().
> 
> So they did this.
> 
> Then people testing out ext4 discovered that upon crash, their
> kde/gnome profiles were corrupted.
> 
> Why? Because KDE/Gnome authors hadn't ever called flush before
> close(), and they weren't the only ones. They didn't read the
> standard, they only used the system and fixed bugs whenever their
> system behaved against their expectations. They didn't notice that the
> system was being different from the standard.
> 
> Guess what ext4 did? :)

ext4 sprouted an option (auto_da_alloc, when used with the proper data
journalling option data=ordered) to support buggy software.

Note that ext4 isn't pioneering the "fsync() required" semantics here,
there are other precedents of "0-blocks in files after crash" in Linux
file systems, such as XFS.

I'm oblivious to the current ext4 defaults WRT these semantics (and I
haven't looked at vanilla kernels for a while anyways---distros might
have changed default settings).
___
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: Using TMPFS for /tmp and /var/run?

[Matthias Andree]

Am 29.03.2012 22:52, schrieb Eric van Gyzen:

> Respectfully, no.  The default is to store /tmp in UFS, either in its
> own partition (with Auto Defaults) or in / (if no partition was created
> for it), and to refrain from clearing it at boot.  Thus, although /tmp
> is not guaranteed to persist in theory, it is rather persistent in
> practice.
> 
> My only point is:  carefully consider the change in behavior of the
> default installation before breaking the POLA.

How about using /var/tmp for the "a little longer lived" temporary stuff?
___
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: No working IDE in FreeBSD!

[Matthias Andree]

Am 23.02.2012 12:22, schrieb O. Hartmann:
> Several time ago I tried to do some development within an IDE, not even
> for lectural and educational purposes. Since most of our software is
> written in C/C++ and OpenCL, I highly prefered ANJUTA, since this IDE
> was highly customizable, flexible and even FreeBSD's ancient outdated
> version in the ports suited our needs.
> 
> Anjuta does not compile anymore for a long time. I do not know why, I
> filed a PR (ports/161494). So I was looking for an alternative.

Anjuta compiles fine for me on 9-STABLE with GCC, but I can reproduce
the build failure with clang that you've filed there.

The following lines were also posted as bug-followup:

---
(Note I'm not a member of the gnome@ team.)

While I can reproduce the build failure with clang (possibly related to
the "not portable" warnings your're seeing), building anjuta with gcc
works fine for me.

Can you post the command lines and relevant configuration files (like
make.conf) that you've used to attempt a build with GCC? Chances are you
haven't thoroughly switched to GCC.  For me, using portmaster's -m
option wouldn't work.

Note that you can pass V=1 as make argument to get the full compiler
command lines, rather than the short "CC" "CCLD" lines, to see what's
actually happening.
---


Please check the lines above.  The relevant lines from the PR seem to be:

---
*** Warning: Linking the executable benchmark against the loadable module
*** libanjuta-symbol-db.so is not portable!
./../.libs/libanjuta-symbol-db.so: undefined reference to
`sdb_engine_get_statement_by_query_id'
./../.libs/libanjuta-symbol-db.so: undefined reference to
`sdb_engine_get_tuple_id_by_unique_name'
clang: error: linker command failed with exit code 1 (use -v to see
invocation)
gmake[6]: *** [benchmark] Error 1
---

Chances are that these are genuine bugs in the Anjuta build system.
___
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: SU+J systems do not fsck themselves

[Matthias Andree]

Am 27.12.2011 22:53, schrieb David Thiel:
> I've had multiple machines now (9.0-RC3, amd64, i386 and earlier 
> 9-CURRENT on ppc) running SU+J that have had unexplained panics and 
> crashes start happening relating to disk I/O. When I end up running a 
> full fsck, it keeps turning out that the disk is dirty and corrupted, 
> but no mechanism is in place with SU+J to detect and fix this. A bgfsck 
> never happens, but a manual fsck in single-user does indeed fix the 
> crashing and weird behavior. Others have tested their SU+J volumes and 
> found them to have errors as well. This makes me super nervous.

The one thing I figured is that in the light of power outages, or
crashing virtualization hosts, you really really really need to disable
disk write caches, and this affects softupdates, journalling, asynch
file systems, just about everything.

The fact that makes matters worse is that journalling or softupdates
allow you to mount a silently-corrupted file system, whereas the
traditional UFS/UFS2 sync/asynch mounts will fsck themselves in the
foreground, so they get fixed before the FS panics.

So can you be sure that:

- your driver, chip set and hard disk execute ordered writes in order,

- your driver, chip set and hard disk actually write data to permanent
storage BEFORE acknowledging a successful write?

Whenever I fixed these issues, I had no more corruptions.

For ata and sata, there are loader tunables you will want to set,
hw.ata.wc=0 and kern.cam.ada.write_cache=0.

If your drives are under ada, ad, or ahci related control, try these
settings.  For SCSI, use camcontrol to turn the write cache off.
softupdates is supposed to rectify most of the performance penalties
incurred.

Note also that you needed to set ahci_load=YES and atapicam_load=YES in
8.X, I've never bothered to check 7.X or 9.X WRT these settings.
___
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: [rfc] removing -mpreferred-stack-boundary=2 flag for i386?

[Matthias Andree]

Am 24.12.2011 00:56, schrieb Alexander Best:
> hi there,
> 
> is -mpreferred-stack-boundary=2 really necessary for i386 builds any longer?
> i built GENERIC (including modules) with and without that flag. the results
> are:
> 
> 1654496   bytes with the flag set
> vs.
> 1654952   bytes with the flag unset
> 
> the gcc(1) man page states the following:
> 
> "
> This extra alignment does consume extra stack space, and generally
> increases code size.  Code that is sensitive to stack space usage,
> such as embedded systems and operating system kernels, may want to
> reduce the preferred alignment to -mpreferred-stack-boundary=2.
> "
> 

What do the numbers above have to do with *stack* alignment or size
(which is a run-time figure, and cannot be statically determined if any
variable-depth recursion takes place).

What are those 16... numbers, anyways? How did you obtain them?
___
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: System headers with clang?

[Matthias Andree]

Am 11.10.2011 15:31, schrieb Larry Rosenman:
> On Tue, 11 Oct 2011, Dimitry Andric wrote:
> 
>> On 2011-10-09 19:32, Larry Rosenman wrote:
>>> I had gotten a PR about sysutils/lsof not compiling with clang.  I had
>>> Vic Abell check it out, and the problem is NOT with lsof per se, but
>>> with the system headers.
>>>
>>> Is there a project afoot to update the system headers to make them clang
>>> compilable?
>>
>> The problem isn't that clang can't compile the system headers, but
>> normally these don't get included from userspace.  And they certainly
>> won't work as expected when you define _KERNEL in userspace, as the lsof
>> port foolishly does.  It probably can't be avoided in such a tool,
>> though.


Point #1: some of the headers have special requirements, like inclusion
order, or thereabouts.  Since these are kernel headers, you need to
abide by their rules.

Violated here:

>>
>>
>> ...
>>> In file included from ckkv.c:43:
>>> In file included from ./../lsof.h:195:
>>> In file included from ./../dlsof.h:190:
>>> In file included from /usr/src/sys/ufs/ufs/ufsmount.h:36:
>>> /usr/src/sys/sys/buf.h:388:2: warning: implicit declaration of
>>> function 'KASSERT' is invalid in C99
>>> [-Wimplicit-function-declaration]
>>>   KASSERT(bp->b_bufobj != NULL, ("bwrite: no bufobj bp=%p",
>>> bp));
>>>   ^

I *suppose* KASSERT is meant as a macro, but even if it's not, ...

>>> /usr/src/sys/sys/buf.h:388:33: warning: expression result unused
>>> [-Wunused-value]
>>>   KASSERT(bp->b_bufobj != NULL, ("bwrite: no bufobj bp=%p",
>>> bp));
>>>  ^
>>
>> These are more or less harmless warnings, as long as nobody calls a
>> function that uses KASSERT.  They occur because lsof's headers don't
>> include  and  before .

...I'd say that's an lsof, rather than kernel or clang, bug.

>>
>> ...
>>> In file included from ckkv.c:43:
>>> In file included from ./../lsof.h:195:
>>> In file included from ./../dlsof.h:432:
>>> In file included from /usr/include/string.h:45:
>>> /usr/include/strings.h:47:6: error: conflicting types for
>>> '__builtin_ffs'
>>> int  ffs(int) __pure2;
>>>^
>>> /usr/include/machine/cpufunc.h:140:24: note: expanded from:
>>> #defineffs(x)  __builtin_ffs(x)
>>>  ^
>>> /usr/include/strings.h:47:6: note: '__builtin_ffs' is a builtin with
>>> type 'int (unsigned int)'
>>
>> This is because the amd64 system headers redefine ffs to __builtin_ffs,
>> after which it conflicts with the declaration in /usr/include/strings.h.
>> On i386, ffs is not redefined, but I have no idea why.

Arguably __builtin_ffs() is inconsistently defined if it expects an
unsigned int argument.  POSIX demands int for ffs()'s argument.

The builtin should match that.  I can't currently point fingers at the
culprit for lack of research/information.

Chances are -fno-builtin helps.

> We need to get clang/system headers to allow warning free compilation
> just like GCC does.

Then make sure that your code is correct.  NOTE: GCC defaults to C89
with GNU extensions, clang defaults to C99.  To know how GCC treats your
code in C99 mode, try gcc -pedantic-error -std=c99 (or possibly
-pedantic without -error suffix if there are bogus warnings) and see if
it's really clang -- or rather the code...

You can override options for either in the port, see
http://wiki.freebsd.org/PortsAndClang#Problems_with_fixes and look for
USE_CSTD.

It won't make your (Vic's) code future proof, but may help for the nonce
- or not.

Of course Vic is free in writing arbitrarily nonportable code, but
before he or you go(es) pointing fingers, check if you're using kernel
headers properly and requesting compilation in the right language, and
if the code is actually conformant.
___
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: chromium port causing massive I/O faults

[Matthias Andree]

Am 25.07.2011 09:21, schrieb Alexander Best:
> On Mon Jul 25 11, Adrian Chadd wrote:
>> Is it perhaps doing disk IO using mmap?
> 
> how can i check, whether that's the case or not?

Use truss(1) for instance.

However, unless there are *practical* problems, a high number of page
faults is not an indication for problems.  Although it may sound scary,
page faults are a feature of the memory management.
___
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: chromium port causing massive I/O faults

[Matthias Andree]

Am 24.07.2011 23:25, schrieb Alexander Best:
> hi there,
> 
> i noticed that chromium, expecially in combination with nspluginwrapper and
> flash, is causing a lot of I/O faults. i ran 'top -mio -I -n 99' and after

It's causing page faults, which is a massive difference.

> only ~ 4 hours of running chromium (most of the time not loading any new
> pages), i got the following data:
> 
> last pid: 39976;  load averages:  0.37,  0.26,  0.19  up 3+02:38:30
> 23:15:26
> 72 processes:  2 running, 70 sleeping
> 
> Mem: 755M Active, 662M Inact, 447M Wired, 51M Cache, 212M Buf, 45M Free
> Swap: 10G Total, 159M Used, 10G Free, 1% Inuse


> ... is anybody else experiencing the same behavior? i also noticed a massive
> fault burst (~ 1500/sec), when closing chromium.

Is that special to Chrome or -CURRENT? Or does it also happen with
Firefox, for instance, or on -STABLE?  I suppose FF might cause even
more, it readily consumes 1.5 GB on my Linux computer after some time
running.

A page fault affecting 1500 pages/s (note it's "s" NOT "sec"!) amounts
to 6 MB/s which appears to be on the comfortable side for any halfway
modern system.

Page in/page out is quite normal behaviour for any system that has swap
space available and is running (especially idle) applications with
nontrivial memory requirements and ultimately filling up its ram.  At
some point in time, when applications have been idle for long enough,
it's more useful to page out unused pages and use them as cache instead.

Why would a swap usage of 8% of physical RAM size be a reason for
concern on a 2 GB RAM 64-bit computer?
___
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: bin/147175: [kerberos] [patch] libhx509.so contains references to MD2_* but doesn't reference libcrypto.so, which has them

[Matthias Andree]

This (GSSAPI linker failure on 9-CURRENT because its libhx509 needs MD2
but libcrypto doesn't provide it) affects security/putty 0.6.1 as well
now.   There is now lots of stuff on the web on this incompatibility.

*Someone needs to fix the GSSAPI-Kerberos/MD2 conflict before the
9-release cycle!*
___
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: Hardware RAID and FreeBSD.

[Matthias Andree]

Am 29.04.2011 02:11, schrieb Colin Mitchell:
> Hello, BSDians.
> 
> I am kind of a n00b to FreeBSD but have had great success and fun with
> it so far.
> 
> I have two old Dell servers at home.  One has Ubuntu server and is my
> web and mail server.  The other is FreeBSD, and I run servers for a
> video game on it.  I really like the FreeBSD server, especially the
> ports system, and how well it runs even though it is a 1GHz CPU.
> 
> Anyways, I bought a new lower-end computer that I was hoping to replace
> both with.  It is a dirt-cheap dual-core AMD that I had built for
> $175US.  It came with a 500GB HDD, and I would like to get another one
> to put in it.  Now, I would like to set up as a mirrored RAID setup (I
> think). I don't really know much about RAID, but I want to have the same
> disk image on both hard drives (in case one fails), and possibly three
> if I buy another HDD in the future.  Is RAID 1 what I want?  I also want
> to do SVN on it for my PhD code, as well as back up my Wordpress,
> Coppermine, etc...

Colin,

RAID 1 (or mirroring) is indeed what you want, and additionally you
should set up a backup to a separate computer (or additional external
disk) in addition to the RAID. You need a backup against accidents such
as software faults, RAM or controller faults, operator errors (newfs-ing
the wrong partition) and such.  rm -rf $foo causes the same damage to a
RAID than to a single disk if $foo happens to contain "/".

Reconsider if you want SVN for PhD code.  I'd personally prefer Git or
Mercurial or perhaps Bazaar.  Easier to set up and use and backup, and
IMNSHO more robust, and you can still set up a central repository in a
"server" purpose.

> Now, here is where the FreeBSD gurus can chime in.  I would like to get
> a hardware RAID card to tie it all together.  I am also looking for a
> cheap one, maybe $30-$60US, if this is even feasible.  Anyone have any
> suggestions?  Any successes?  

Hardware RAID cards in this price range often implement software RAID
(some Linux guys call that Fakeraid) and hide that fact, or they don't
support RAID5, or both.

The major disadvantage of hardware RAID is that usually only the very
same card, possibly with the same firmware version, can read the disks
back in case the original RAID controller dies, because the software
RAID setups often cannot understand the meta data on the disks that the
hardware writes.

The disadvantage of software RAID is that it is a bit less convenient
and needs some attention for the boot loader and boot partition support
(although RAID 1 is easy) -- you still want to be able to boot if the
primary disk drive dies (that's the whole purpose of RAID).

If you plan to go with three disks later, RAID 5 would be the canonical
configuration, it covers up the failure of any one hard disk in the
array.  Consider possible partitioning now - possibly you want /usr in a
separate RAID1 so that you can later back it up and make a RAID5 out of
it (possibly in a restore operation to defragment everything) and
everything else stays in RAID1.

Before you buy used hardware controllers (especially RAID 5), be sure to
check the web for benchmarks.  Some old hardware RAID adaptors are *way*
slower than a halfway decent mobo with software RAID.  A friend reported
rsync speeds less than 1 MB/s with a hardware RAID 5 on some old aacraid
driven board under Linux.  He doesn't remember which.  A used 3ware
controller he got (and uses a different driver) is roughly an order of
magnitude faster.

> Also, I see a lot of talk on here bout ZFS.  Is this something I should
> try, instead of the standard UFS?

Only if you have several GB of RAM, and be sure to read the ZFS tuning
guides in the FreeBSD wiki before even trying it -- so that you know
what you're buying before your purchase. :-)

For experiments, use a play computer, but beware of ZFS performance, it
degrades a lot more than UFS when the volume gets closer to filling up,
so be sure to keep sufficient free space.  I haven't got sufficient ZFS
experience to recommend a maximum fill ratio.  I got burnt and am now
experimenting with journalling UFS, which seems to be unremarkable
(which is good).

HTH
___
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: tzsetup disregards setting TZ to UTC

[Matthias Andree]

Am 28.03.2011 07:53, schrieb Garrett Cooper:
> On Sun, Mar 27, 2011 at 10:29 PM, Eitan Adler  wrote:
>> On Mon, Mar 28, 2011 at 12:19 AM, Daniel O'Connor  
>> wrote:
>>> Hi,
>>> I am trying the new installer and I find that it still asks you for a time 
>>> zone even if you answer Yes to using UTC.
>>
>> tzsetup(1) is not asking if you wish to use UTC, It is asking if your
>> local CMOS clock is set to UTC time. There is a subtle difference. See
>> adjkerntz(8) for more details.
> 
> Perhaps the wording should be changed to say "Is your clock set to
> local time?" instead?

Perhaps the installer should instead:

display CMOS and system time, and ask which one of them is correct, and
offer a third option to actually correct the timezone or time if neither
is correct.

That's much easier to grasp.
___
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: No human readable message with g_vfs

[Matthias Andree]

Am 03.01.2011 14:14, schrieb Ivan Voras:
> On 12/29/10 11:32, David Demelier wrote:
>> Hello,
>>
>> Sometimes when I use my external harddrive I get these awful message :
>>
>> g_vfs_done():da1[WRITE(offset=34590720, length=65536)]error = 5
>> /var/log/messages.1.bz2:Dec 21 18:36:07 Abricot kernel:
>> g_vfs_done():da1[WRITE(offset=34656256, length=65536)]error = 5
>> /var/log/messages.1.bz2:Dec 21 18:36:07 Abricot kernel:
>> g_vfs_done():da1[WRITE(offset=34721792, length=65536)]error = 5
>> /var/log/messages.1.bz2:Dec 21 18:36:07 Abricot kernel:
>> g_vfs_done():da1[WRITE(offset=34787328, length=65536)]error = 5
>> /var/log/messages.1.bz2:Dec 21 18:36:07 Abricot kernel:
>> g_vfs_done():da1[WRITE(offset=34852864, length=65536)]error = 5
>> /var/log/messages.1.bz2:Dec 21 22:50:28 Abricot kernel:
>> g_vfs_done():ufs/public[WRITE(offset=244271529984, length=16384)]error
>> = 5
>> /var/log/messages.1.bz2:Dec 21 22:50:28 Abricot kernel:
>> g_vfs_done():ufs/public[READ(offset=244563705856, length=131072)]error
>> = 5
>> /var/log/messages.5.bz2:Nov 29 16:36:52 Abricot kernel:
>> g_vfs_done():ufs/public[READ(offset=232718991360, length=131072)]error
>> = 5
>>
>> I think for a lambda user these are absolutely not understandable. I
> 
> Would a better message be "WRITE error on da0, offset=34590720.
> length=65536, errno=5"?

nah, strerror(errno) isn't that much of an effort

___
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: Interpreted language(s) in the base

[Matthias Andree]

Am 22.08.2010 13:21, schrieb Dag-Erling Smørgrav:
> Gabor PALI  writes:
>> Dag-Erling Smørgrav  writes:
>>> Gabor PALI  writes:
 Sorry for chiming in, just a quick idea.  If you find the "get a
 high-level language that compiled to C" idea good,
>>> I don't think it's a good idea
>> Could you be more specific on your concerns?  I am just curious.
> 
> If we want compiled code, we already have C and C++.  What we need is an
> interpreted language with good libraries so people can write scripts and
> one-liners without having to jump through too many hoops and worry about
> quoting.  The result may not be as fast as a compiled program, but it
> will be much faster than a shell script and take less time to write than
> either C or shell.

Looks a bit like a swing.  First we remove Perl from the base system
(years ago) and move to sed/awk, now we discuss using a scripting
language in the base system...
___
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: Removal of ICC (intel compiler) bits from mk

[Matthias Andree]

Am 19.08.2010 11:35, schrieb Alexander Leidinger:
> 
> Quoting Dag-Erling Smørgrav  (from Thu, 19 Aug 2010  
> 11:16:23 +0200):
> 
>> Alexander Leidinger  writes:
>>> If someone would get icc 11.x up and runnig as a port (similar to what
>>> we have for outdated icc version in the ports collection), I would
>>> have a look if my contact at Intel is still working there in a
>>> position which allows him to get a commercial license for us.
>>
>> Does that really matter?  We're not going to start building releases
>> with icc, are we?
> 
> It could matter for ports, I do not know if it matters for parts in  
> src. The commercial license is also the only way that we could get icc  
> installed on machines in the FreeBSD cluster (if there's interest to  
> have another compiler *for FreeBSD development* to check the source  
> against... the warnng and error messages are better that those of gcc,  
> I do not know how they compare to clang).

Clang is a mixed experience. I've used it only for C so far, and there are some
code issues that it doesn't check at all yet; issues that GCC or ICC would
complain about. ICC11 warnings (I've only used it on Linux for the software
where I'm upstream maintainer) seem plentiful if you request remarks, too.

However, clang diagnostics are easier to understand than GCCs and usually more
helpful - which was a design goal.

Note that devel/clang ships with a static analyzer that should now finally work,
as of clang-2.7_2. It can trace call trees back and pinpoint how, for instance,
your code forgets to check NULL dereference, where there are dead
initializations or assignments, or similar.  I found it to be a bit more solid
than GCC in my use cases, but note it's advertised as work-in-progress.
Details/Usage: http://clang-analyzer.llvm.org/scan-build.html

-- 
Matthias Andree
___
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: Official request: Please make GNU grep the default

[Matthias Andree]

I wrote:


Might be worth a read, together with profiling Doug's test case if he
could tell you how to reproduce those.


Make that "since he has provided the means to reproduce those". I had  
read, but not realized, Doug uploaded the test case.


--
Matthias Andree
___
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: Official request: Please make GNU grep the default

[Matthias Andree]

Gabor Kovesdan wrote on 2010-08-13:


Em 2010.08.13. 10:43, Doug Barton escreveu:

My reason is simple, performance. While doing some portmaster work
recently I was regression testing some changes I made to the --index*
options and noticed that things were dramatically slower than the last
time I tested those features. Thinking that I had made a programming
mistake I dug into my code, and while the regexps that I was using could
be tuned for slightly better performance the problem was not in my code.
I then installed textproc/gnugrep to compare, and the differences were
very dramatic using a highly pessimized test case (finding a match on
the last line of INDEX). The script I used to test is at
http://people.freebsd.org/~dougb/grep-time-trial.sh.txt and a typical
result was:

GNU grep
Elapsed time: 2 seconds

BSD grep
Elapsed time: 47 seconds

Ok, I'll take care of this soon, and make GNU grep default, again with a  
knob to build BSD grep. I agree with you that we cannot allow such a big  
performance drawback but I my measures only showed significant  
differences for very big searches and I didn't imagine that it could add  
up to such a big diference. I'm sorry for the bad decision I took making  
it default.


Without knowing any of the details (I am not using 9-CURRENT), Gabor, I  
suggest that you check the documentation around Google's RE2 library  
(which is in C++); there are quite a few bits of information relating to  
(including worst-case) performance of regexp matchers, both directly in  
the re2 documentation, as well as indirect through links and references.   
Might be worth a read, together with profiling Doug's test case if he  
could tell you how to reproduce those.


--
Matthias Andree
___
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: Regression in GSSAPI/libxh509 linking? [PR bin/147175]

[Matthias Andree]

Am 06.07.2010, 21:00 Uhr, schrieb Matthew Seaman:


On 06/07/2010 15:14:28, Andrew Reilly wrote:

So: how should I "fix" this, properly, on my -current system? Is it
as simple as installing heimdal from ports? I can't remove openssl-1.0:
that has 191 ports listed in its REQUIRED_BY file.


Rebuild the port of openssl-1.0.0 after modifying the OPTIONS to include
MD2=on ?


Not good given that MD2 is broken. Very broken, not just by a factor of  
2^5 or something.


Where upon rests the earlier assertion (not by Matthew) that Kerberos V  
needed MD2 checksums?
I can't seem to find that in the KRB5 protocol and checksum RFCs. If it's  
not mandatory we may want to nuke MD2 from Kerberos to remedy a  
weakness... Chapter and Verse welcome.


Thanks.

--
Matthias Andree
___
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: Regression in GSSAPI/libxh509 linking? [PR bin/147175]

[Matthias Andree]

Am 06.07.2010 10:54, schrieb Kostik Belousov:
> On Tue, Jul 06, 2010 at 10:20:28AM +0200, Matthias Andree wrote:

>> Please help: read PR bin/147175 and comment if you're knowledgeable about  
>> either run-time linking, KRB5/GSSAPI, or both :)
> 
> You need to gather and show exact command that fails.

Hi Kostik,

thanks.  I'd propose re-reading
<http://www.freebsd.org/cgi/query-pr.cgi?pr=147175>, particularly the "How to
reproduce section", and ask specific questions that pop up afterwards. :-)

> Shared object that references a symbol but does not record a dependency
> on the object providing the symbol is the bug in the build of that object
> (usually).

In that case, Andrew's proposed patch (same URL as above, which see) would be
the way to go, because it adds those dependencies to the Heimdal X.509 library
build Makefile.

However, I'm neither into -current nor into base system affairs.

Any takers?

Best regards

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

Regression in GSSAPI/libxh509 linking? [PR bin/147175]

[Matthias Andree]

Greetings,

it appears that some change to -RECENT (relative to 8-STABLE) breaks  
linking several GSSAPI applications from ports, for instance,  
mail/fetchmail if GSSAPI is enabled.


These applications then compile OK, but fail to link with MD2_Init and  
other MD2 symbols not defined, although the command line (obtained from  
krb5-config gssapi --libs) appears to list -lhx509 and -lcrypto in the  
right order (hx509 first). This is, according to the report, happening on  
-CURRENT, but does NOT happen on 8-STABLE or release candidates to 8.1.


Andrew Reilly posted a patch to the base system Kerberos to bin/147175 to  
add a dependency from the shared hx509 library on libcrypto, however there  
are open questions neither he nor I can answer -- particularly if it's  
fixing the right problem, or if instead the run-time linker needed to be  
fixed.


Please help: read PR bin/147175 and comment if you're knowledgeable about  
either run-time linking, KRB5/GSSAPI, or both :)


Thank you.

--
Matthias Andree
___
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: Cleanup for cryptographic algorithms vs. compiler optimizations

[Matthias Andree]

Am 13.06.2010, 00:52 Uhr, schrieb Bernd Walter:


In more general terms, the compiler is allowed to make any changes it
likes to the program as long as the end result behaves exactly like it
would if it hadn't been changed.  This is called the "as if" rule.  For
instance, if you call printf() or fprintf() with a format string that
does not contain any conversion specifiers, gcc will call gets() or
fgets() instead.


Amazing - this is one of the things which can get nasty if you try some
kind of microtuning.
Recently I had to implement my own atoi on a controller because using the
library one magically had blown my RAM usage by 1k on a controller with
just 8k RAM.


There are certain compiler flags to affect that. For GCC, -Os is one  
(which doesn't necessarily work in FreeBSD though, on some versions the  
compiler would go into unterminated loop, leak memory and ultimately fail  
with OOM), flags to tell the compiler that the implementation is  
freestanding, and attributes to select builtins and the likes.


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

5.2-BETA: IA32 SMP: atkbd gone, lock order reversal swap_pager/uma_core

[Matthias Andree]

I have made some experiences on a Fujitsu-Siemens Primergy RX300
(Serverworks, Xeon with HyperThreading, MegaRAID) today. I was able to
boot the 5.2-BETA ISO from CD-RW after being unsuccessful with floppies
yesterday (not that I'd particularly trust floppies...)

Here's what I've found so far:

1. KEYBOARD LOST
   I need to explicitly escape to the loader prompt and
   set hint.atkbd.0.flags=0 -- with the default of 0x1, I am unable to
   use the keyboard (tried twice, without and with re-plugging the
   keyboard, to no avail). The exact reason is unknown, the machine has remote
   management hardware on board which might interfere.

Can this flags=0 be made the default or would that interfere with USB
keyboard and headless configurations?

2. LOCK ORDER REVERSAL
   I let the machine buildworld, build a kernel and cvsup ports+doc at
   the same time through screen. Both buildworld and the kernel make
   were launched with "-j2". The machine then caught a LOR, but it may
   have happened after these tasks completed, neither make nor the cvsup
   reported an error. Here's the dmesg:

FreeBSD 5.2-BETA #0: Tue Nov 25 08:24:08 GMT 2003
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC
Preloaded elf kernel "/boot/kernel/kernel" at 0xc0a76000.
ACPI APIC Table: 
Timecounter "i8254" frequency 1193182 Hz quality 0
CPU: Intel(R) Xeon(TM) CPU 2.80GHz (2800.13-MHz 686-class CPU)
  Origin = "GenuineIntel"  Id = 0xf29  Stepping = 9
  
Features=0xbfebfbff
  Hyperthreading: 2 logical CPUs
real memory  = 536870912 (512 MB)
avail memory = 511750144 (488 MB)
FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
 cpu0 (BSP): APIC ID:  0
 cpu1 (AP): APIC ID:  1
...
SMP: AP CPU #1 Launched!
Mounting root from ufs:/dev/amrd0s4a
...
Lock order reversal
 1st 0xc55acdec vm object (vm object) @ /usr/src/sys/vm/swap_pager.c:1323
 2nd 0xc098cf60 swap_pager swhash (swap_pager swhash) @ 
/usr/src/sys/vm/swap_pager.c:1838
 3rd 0xc10398c4 vm object (vm object) @ /usr/src/sys/vm/uma_core.c:876
Stack backtrace:
(no backtrace)

Since then, no further problems have been logged in the past three and a
half hours.

-- 
Matthias Andree

Encrypt your mail: my GnuPG key ID is 0x052E7D95
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

5.2-BETA: Instant crash (GPF) on Primergy RX300

[Matthias Andree]

Hi,

just for the fun of it, I booted 5.2-BETA kern.flp/mfsroot.flp on a FSC
Primergy RX300 (1 Xeon, 512 MB RAM) with ServerWorks Chipset, onboard
Dual Adaptec 79XX (unused, disabled in BIOS), 2 * Broadcom 5704 and LSI
MegaRAID 320-1 (69 GB net RAID5 FWIW). It instantly died with a GPF
after having read the mfsroot.flp.

Is there BTW an installation kernel/mfsroot/whatever stuff that can be
PXE booted or can I generate one from an existing installation?
I find floppy images (or D/L-ing like 200 MB install ISO) ever so
inconvenient.

The same hardware is fine under SuSE Linux 9.0, here is the lspci (think
pciconf):

00:00.0 Class 0600: 1166:0014 (rev 33)
00:00.1 Class 0600: 1166:0014
00:00.2 Class 0600: 1166:0014
00:04.0 Class 0300: 1002:4752 (rev 27)
00:0f.0 Class 0600: 1166:0203 (rev a0)
00:0f.1 Class 0101: 1166:0213 (rev a0)
00:0f.2 Class 0c03: 1166:0221 (rev 05)
00:0f.3 Class 0601: 1166:0227
00:10.0 Class 0600: 1166:0110 (rev 12)
00:10.2 Class 0600: 1166:0110 (rev 12)
00:11.0 Class 0600: 1166:0101 (rev 05)
00:11.2 Class 0600: 1166:0101 (rev 05)
02:00.0 Class 0200: 14e4:1648 (rev 02)
02:00.1 Class 0200: 14e4:1648 (rev 02)
04:08.0 Class 0104: 1000:1960 (rev 01)

I may be able to capture the boot logging by booting "headless"
tomorrow. We'll see.

-- 
Matthias Andree

Encrypt your mail: my GnuPG key ID is 0x052E7D95
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Ports startup scripts in /etc/rc.d (Re: 5.2-BETA and related ports issues)

[Matthias Andree]

Robert Watson <[EMAIL PROTECTED]> writes:

> (1) Combine / and /usr into a single file system by default, and add
> /usr/local/etc/rc.d to the search order, with appropriate hacks to
> handle old-style scripts.  The devil will be in the bikeshed, but the
> implementation is easy, except for the bit where we explain that
> NFS-mounted /usr/local won't work too well.

I'd discourage that. It's fairly intrusive and breaks existing
setups. I'm NOT going to repartition and reinstall!

> (2) Reevaluate the order at routine points in the boot where new scripts
> might now be available (due to file system mounts or whatever).
> Essentially "insert the new cards into the deck, and shuffle".  This
> requires rethinking of our current approach, which assumes a static
> order is created once at the start of the boot by rcorder(8).  The
> devil will be in the big picture *and* the details of the
> implementation.

I don't think there shall be devils in the implementation details. I
admit not having looked at rcorder yet, but dependencies can be passed
on from one rcorder run to the next, through the usual process
environment.

> (3) Add /local/etc/rc.d or /local/rc.d or /etc/local/rc.d or the like, a
> new directory that third party applications are allowed to modify
> during install, and that will be present for the creation of the
> static ordering by rcorder(8) early in the boot.  The devil will be in
> the bikeshed, but the implementation is easy.

/etc/local/rc.d might work, it's quite similar to the /etc/opt approach
"configuration stuff for /opt applications" on Linux.

> I'm actually leaning towards (2) as being the best solution, as it's easy
> and functional.

Seconded from the user's view.

-- 
Matthias Andree

Encrypt your mail: my GnuPG key ID is 0x052E7D95
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Ports startup scripts in /etc/rc.d (Re: 5.2-BETA and related ports issues)

[Matthias Andree]

Richard Coleman <[EMAIL PROTECTED]> writes:

> But that kinda defeats the purpose of RCNG.  One of the best features of
> RCNG is that it makes it easier to add/delete applications from the
> system.  Not using it for this purpose reduces its utility.
>
> Let's not let the typical BSD traditionalism get in the way of using
> RCNG for what it's designed.  Don't get me wrong.  I'm not advocating
> Linux-style integration of packages/ports.  But this seems fairly
> harmless.

Ports belong into /usr/local, not into /etc. There should be some hook
that allows port start scripts to run before some base system scripts,
and if Oliver's two-staged "reevaluate" approach supports this with /
and /usr in separate partitions, then why not take his suggestion?

There's nothing that prevents RCNG from stretching out its fangs to
/usr/local/etc/rc*, in fact, hier(7) encourages that.

If I get the picture right, what's suggested is that after mounting
local file systems, the RC order is re-evaluated, and again after
mounting remote file systems ("diskless"). This would allow the system
to gradually complete its /etc/rc* picture.

Another idea would be to use unionfs or something to keep
/usr/local/etc/rc.d in the root partition for real, and when it's
shadowed by the actual /usr/local or /usr mount, punch a hole so you can
look at the rootfs with unionfs or something. I'd like Oliver's
suggestion better though.

-- 
Matthias Andree

Encrypt your mail: my GnuPG key ID is 0x052E7D95
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: NSS and PAM, dynamic vs. static

[Matthias Andree]

"Jacques A. Vidrine" <[EMAIL PROTECTED]> writes:

> On Wed, Nov 26, 2003 at 02:00:08AM +0100, Matthias Andree wrote:
>> Matthew Dillon <[EMAIL PROTECTED]> writes:
>> 
>> > How much do you intend to use NSS for?  I mean, what's the point of
>> > adopting this cool infrastructure if all you are going to do with it
>> > is make a better PAM out of it?
>> 
>> The important thing is that NSS allows to plug modules such as LDAP or
>> PostgreSQL for user base management. PAM is only halfway there and
>> doesn't give libc et al. a notion of a user or group context (in spite
>> of its "account" context), NSS does. One might discuss if PAM is really
>> needed with NSS in place, but it's hard to think of a system without
>> NSS and removing PAM now doesn't look right.
>
> NSS and PAM do not overlap.

I wonder how PAM gets "system" authentication information for pam_pwdb
or pam_unix or how it's called today and on the pertinent system if not
through NSS. Reimplementation of these "passwd/shadow/whatever"
mechanisms?

-- 
Matthias Andree

Encrypt your mail: my GnuPG key ID is 0x052E7D95
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

5.2-BETA: file system bugs considered harmful (was: 5.2-BETA: giving up on 4 buffers)

[Matthias Andree]

Bruce Evans <[EMAIL PROTECTED]> writes:

> I'm not sure if the problem is known for the read-only case.  It is
> the same problem as in the read-write case.  ext2fs hangs onto buffers,
> so shutdown cannot tell if it can look at the buffers and considers
> them to be busy.  Then since shutdown cannot tell if it synced all dirty
> buffers or which buffers are associated with which file systems, it
> doesn't unmount any file systems and all dirty file systems that aren't
> unmounted before shutdown are left dirty.  Read-only-mounted ext2fs file
> systems aren't left dirty but they break cleaning of other file systems.

Either way, I consider the underlying bugs harmful.

I tried to modify ext2 files, could read-write mount the partition,
could modify the files and sync, but when I tried to mount -u -r the
ext2 partition or umount it, I got a busy condition, and after reboot,
the changes were lost, and a while later (an hour or so) the machine
panicked in vinvalbuf().

Needless to say that after that, the machine fsck'd the whole disk (all
partitions) and, worse, my root partition was damaged, files missing.  I
had run make installworld prior to the panic. My root partition is a
regular noasync UFS1, /usr and /var are softupdates UFS2.

Because of this damage, I consider the underlying file system bugs,
whether in ext2fs or outside, to be harmful. I'm not claiming they're IN
ext2fs (because of the ufs single-user fsck, reboot problem) but they
can be triggered through ext2fs. Something's not quite right.

-- 
Matthias Andree

Encrypt your mail: my GnuPG key ID is 0x052E7D95
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

5.2-BETA: giving up on 4 buffers (ata)

[Matthias Andree]

Hi,

when I rebooted my 5.2-BETA (kernel about 24 hours old), it gave up on
flushing 4 dirty blocks.

I had three UFS1 softdep file systems mounted on one ATA drive, one ext2
file system on another ATA drive and one ext2 file system on a SCSI
drive.  Both ext2 file systems had been mounted read-only, so they can't
have had dirty blocks.

At the next reboot, FreeBSD checked all three UFS file systems as they
hadn't been umounted cleanly before. Makes me wonder if FreeBSD gave up
on the super blocks...

Regards,

-- 
Matthias Andree

Encrypt your mail: my GnuPG key ID is 0x052E7D95
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: NSS and PAM, dynamic vs. static (was: 40% slowdown with dynamic /bin/sh)

[Matthias Andree]

On Tue, 25 Nov 2003, David O'Brien wrote:

> On Wed, Nov 26, 2003 at 02:00:08AM +0100, Matthias Andree wrote:
> > As a user, I like /rescue better than the step-child that /stand/* used
> > to be. It's part of the world, which /stand wasn't.
> 
> Except that we still have /stand.  It should be shot, but some won't let
> it go...

We have it, it's buggy (I didn't bother to report it tried to create a
5th primary partition and shot all my extended partitions in turn yet)
and unbeloved -- but it doesn't get built when you type "make
buildworld", which is what my phrase was about. Sorry if I was unclear.

Maybe FreeBSD should just use Linux' fdisk which works fine and would
need only minor BSD label polishing, if any. License permitting (-:

-- 
Matthias Andree

Encrypt your mail: my GnuPG key ID is 0x052E7D95
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: IPFW2 verrevpath issue (IPv4 TCP, fresh kernel)

[Matthias Andree]

On Tue, 25 Nov 2003, Sean Chittenden wrote:

> > Is my expectation wrong or is there a pertinent IPFW2 bug in a current
> > 5.2-BETA kernel?
> 
> You're alone in this, though cjc hasn't been able to reproduce this.
> Are you on a multi-homed system?  -sc

Sort of. I do have three xl(4) NICs in my system. xl0 and xl1 are
bridged via ng_bridge(*), IP 192.168.0.1 on one card, no IP on the
other; xl2 is the transport for tun0 (which is PPPoE in my case) and
doesn't have an IP either, so "multi-homed" might read "tun0 has an
address, xl0 has another and lo0 has a third one".

These xl* cards shouldn't matter for my problem, at the time I tested my
firewall setups, the networks were idle with no other hosts attached.


I noticed that very recently there was a bug fix that made the machine
pick the right outbound address again (which it didn't for some days or
weeks, haven't compiled kernels daily) - I wonder if it's related.
Unfortunately, I don't have a 5.1-RELEASE box here to test. Would 4.9
with IPFW2 option be sufficiently similar in IPFW2 matters that it's
worthwhile testing?



(*) I have a configuration where the bridge is to have the same IP from
both xl0 and xl1. Traditional bridge code gets confused over ARP and
coughs up the MACs it would need and "locks itself out",
netgraph-bridge is fine however.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

NSS and PAM, dynamic vs. static (was: 40% slowdown with dynamic /bin/sh)

[Matthias Andree]

Matthew Dillon <[EMAIL PROTECTED]> writes:

> How much do you intend to use NSS for?  I mean, what's the point of
> adopting this cool infrastructure if all you are going to do with it
> is make a better PAM out of it?

The important thing is that NSS allows to plug modules such as LDAP or
PostgreSQL for user base management. PAM is only halfway there and
doesn't give libc et al. a notion of a user or group context (in spite
of its "account" context), NSS does. One might discuss if PAM is really
needed with NSS in place, but it's hard to think of a system without
NSS and removing PAM now doesn't look right.

Of course, you can stuff the whole NSS client side (thinking "IPC")
into a statically linked executable. To stall this discussion: I don't
mind if NSS is dynamically or statically linked. I won't let this drift
into any other dynamic <-> static discussion.

> reason that I can see, and coming up with all sorts of extra junk,
> like /rescue, to work around that fact.

As a user, I like /rescue better than the step-child that /stand/* used
to be. It's part of the world, which /stand wasn't.

One word of warning: there used to be SuSE Linux versions that wouldn't
let you log in single-user mode when the system was using NIS in
multi-user because there was nothing to communicate with through AF_UNIX
sockets yet this was expected to be able to log in. There are potholes
and pitfalls that I consider major considered with a dynamic /bin /sbin
setup.

Watch out.

-- 
Matthias Andree

Encrypt your mail: my GnuPG key ID is 0x052E7D95
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

IPFW2 verrevpath issue (IPv4 TCP, fresh kernel)

[Matthias Andree]

Hi,

I seem to have difficulties with verrevpath in IPFW2 (current kernel,
cvsupped a few hours ago) which APPEARS to not match - or am I too
whatever to configure ipfw2 properly?

Excerpt from "ipfw show":

| 0010038   3216 allow ip from any to any via lo0
| 00200 0  0 deny ip from any to 127.0.0.0/8
| 00300 0  0 deny ip from 127.0.0.0/8 to any
> 0040039  12941 deny log ip from any to any not verrevpath in
| 00500 0  0 deny ip from 192.168.0.0/24 to any in via tun0
| ...

Now, when I try to connect from my machine to a remote one with
"ssh [EMAIL PROTECTED]" I'm getting loads of

| kernel: ipfw: 400 Deny TCP 1.2.3.4:22 217.225.230.222:49228 in via tun0
| kernel: ipfw: 400 Deny TCP 1.2.3.4:22 217.225.230.222:49228 in via tun0

in syslog and the counter of the 00400 rule increases, and I don't get a
connection.  Leaving out the 00400 rule makes my outbound TCP
connections work.  (Apparently the 00400 rule swallows the SYN|ACK
packets.)

217.225.230.222 is my IP and 1.2.3.4 is the remote IP. tun0 is a PPPoE
interface, with ppp(8). I have a default route via 217.5.*.* gateway on
tun0 (both the default route and the host route for this 217.5.*.*
gateway use device tun0).

"route get 1.2.3.4" prints that 1.2.3.4 is routed via some 217.5.*.*
host which is on tun0, so this looks fine.

I'd expect that the "in via tun0" matched the outbound route as returned
by route get.

To add to the confusion, NTP (that uses UDP) is fine, the machine will
synchronize to an outside server (my ISP's DCF receiver) via the same
gateway just fine.

Is my expectation wrong or is there a pertinent IPFW2 bug in a current
5.2-BETA kernel?

-- 
Matthias Andree

Encrypt your mail: my GnuPG key ID is 0x052E7D95
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Unfortunate dynamic linking for everything

[Matthias Andree]

Richard Coleman <[EMAIL PROTECTED]> writes:

> Are you suggesting that (t)csh also move to /usr/bin to match
> /usr/bin/sh?  The screams caused by such a change would be deafening.

Would there be any screams at all?

chsh -s /bin/sh root# prevent lock-out
rm -f /bin/csh /bin/tcsh
echo NO_TCSH=true >>/etc/make.conf  # avoid resurrection of evil
# next "make world"

Looks that a system without [t]csh is supported. And it works for me.

-- 
Matthias Andree

Encrypt your mail: my GnuPG key ID is 0x052E7D95
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Update ncurses in base system?

[Matthias Andree]

Apparently, the ncurses version in the base system is 5.2, while there
is a newer 5.3 port available.

Would it make sense to import the 5.3 ncurses into the base system?

There are some ports (mail/cone) that need 5.3 and that won't work with
FreeBSD 4 either way (missing i18n/l10n features in libc.so.4 that are
in libc.so.5).

Thanks in advance,

-- 
Matthias Andree

Encrypt your mail: my GnuPG key ID is 0x052E7D95
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

HELP: ServerWorks data corruption after 350 MB with BerkeleyDB 4.0?

[Matthias Andree]

Hi,

I received a bug report against BerkeleyDB 4 that may not be BerkeleyDB
related, but a problem with FreeBSD or specific hardware in general.

Jie Song (CC'd) reported that writing files with BerkeleyDB (no
threading or something) on his ServerWorks machine causes data
corruption (detected by BerkeleyDB 4.0 library functions) when the file
sizes grow beyond 350 MB. For details, see PR #55252. Jie Song has
answered in private mail that the problem persists with both current 4.X
and current 5.X FreeBSD versions.

Does this ring a bell somewhere? Are there issues with BIOS versions
usually used on ServerWorks boards, are there hardware
detection/configuration issues in the kernel? Anything known?

Thanks in advance,

-- 
Matthias Andree

Encrypt your mail: my GnuPG key ID is 0x052E7D95
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Strange behaviour with ata(pi)/(cam) OR swapoff OR ext2fs?

[Matthias Andree]

Hi,

I have had a kernel panic recently on a recent -CURRENT, but I have no
clues where that was from (no BT either).

I do know that I've used "swapoff -a" with some dozen kBytes in swap,
and I've played a lot with atapicam (Plextor PX-4824TA, VIA
KT133), and I've had a Linux ext3 partition mounted ro at first and then
"mount -u"'d to rw.

Since I don't want to point the finger on anything yet: has anyone else
seen "swapoff -a" or r/w on ext3 partitions cause strange things?

TIA,

-- 
Matthias Andree

Encrypt your mail: my GnuPG key ID is 0x052E7D95
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

ATA probes adapters switched off in BIOS "Integrated Peripherals"?

[Matthias Andree]

Hi,

after I had a kernel with broken atapicam that wouldn't boot, I tried
disabling the secondary onboard channel of my main board (AMI BIOS, VIA
KT133 chip set).

The BIOS thought "oh well, we don't need ATA1, so we have IRQ 15 free,
let's route xl0 and xl2 there". So far so good.

ATAng happily probed and registered ata1 on the VIA chip:

Sep 22 00:36:05 merlin kernel: atapci0:  port 
0xffa0-0xffaf at device 7.1 on pci0
Sep 22 00:36:05 merlin kernel: ata0: reset tp1 mask=03 ostat0=50 ostat1=50
Sep 22 00:36:05 merlin kernel: ata0-master: stat=0xd0 err=0xd0 lsb=0xd0 msb=0xd0
Sep 22 00:36:05 merlin kernel: ata0-slave:  stat=0x80 err=0x80 lsb=0x80 msb=0x80
Sep 22 00:36:05 merlin kernel: ata0-master: stat=0x50 err=0x01 lsb=0x00 msb=0x00
Sep 22 00:36:05 merlin kernel: ata0-slave:  stat=0x50 err=0x01 lsb=0x00 msb=0x00
Sep 22 00:36:05 merlin kernel: ata0: reset tp2 mask=03 stat0=50 stat1=50 
devices=0x3
(that's fine, I have two hard disk drives)
Sep 22 00:36:05 merlin kernel: ata0: at 0x1f0 irq 14 on atapci0
Sep 22 00:36:05 merlin kernel: ata0: [MPSAFE]
Sep 22 00:36:05 merlin kernel: ata1: at 0x170 irq 15 on atapci0
Sep 22 00:36:05 merlin kernel: ata1: [MPSAFE]
...
Sep 22 00:36:05 merlin kernel: xl0: <3Com 3c900-COMBO Etherlink XL> port 0xb400-0xb43f 
irq 15 at device 9.0 on pci0
...
Sep 22 00:36:05 merlin kernel: xl1: <3Com 3c905-TX Fast Etherlink XL> port 
0xc000-0xc03f irq 9 at device 12.0 on pci0
Sep 22 00:36:05 merlin kernel: xl2: <3Com 3c905-TX Fast Etherlink XL> port 
0xc400-0xc43f irq 15 at device 13.0 on pci0
...

and later hundreds of:
Sep 22 00:36:05 merlin kernel: ata1: spurious interrupt - status=0xff error=0xff
Sep 22 00:36:05 merlin last message repeated 3 times
...
Sep 22 00:36:42 merlin kernel: ata1: spurious interrupt - status=0xff error=0xff
Sep 22 00:36:48 merlin last message repeated 20 times

However, acd0 which is the Secondary Master was _not_ detected, as I
expected.

For some reason ata seems to have missed it was running in "Primary
Only" mode and was complaining about spurious interrupts that were
xl0/xl2's.

Can ata(4) detect if ata1 is switched off?

Why does ata think the interrupt was for itself? Doesn't it need to
probe the IDE chip registers before making such claims?

Is ata ready to share the IRQ with some other card? It should (and I
believe it actually does), since my Promise chip (not shown) shares the
IRQ with xl1, bttv and the two USB root devices.


Oh, did I mention the kernel message ("dmesg") buffer is *WAY* too small
for "boot -v"?

Can we please 8-fold the buffer size for boot -v and print a warning
that boot -v bumped the message buffer size (so as to avoid heisenbugs
that are gone in -v mode)?

-- 
Matthias Andree

Encrypt your mail: my GnuPG key ID is 0x052E7D95
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

atapicam error messages at boot/appears to work nonetheless

[Matthias Andree]

I'm getting complaints from ata or atapicam during boot-up, but my
CD-ROM seems fine (reading, at least). ACPI enabled, sym driver enabled
+ in use with a 875 chip (Tekram DC-390F) and cd0, da0, sa0, sa1.

Is this something to worry about?

dmesg excerpt:

...
atapci0:  port 0xffa0-0xffaf at device 7.1 on pci0
ata0: at 0x1f0 irq 14 on atapci0
ata0: [MPSAFE]
ata1: at 0x170 irq 15 on atapci0
ata1: [MPSAFE]
...
Waiting 15 seconds for SCSI devices to settle
(probe2:ata1:0:0:0): Recovered Sense
(probe2:ata1:0:0:0): INQUIRY. CDB: 12 1 80 0 ff 0 
(probe2:ata1:0:0:0): CAM Status: SCSI Status Error
(probe2:ata1:0:0:0): SCSI Status: Check Condition
(probe2:ata1:0:0:0): ILLEGAL REQUEST asc:24,0
(probe2:ata1:0:0:0): Invalid field in CDB
(probe2:ata1:0:0:0): Recovered Sense
(probe2:ata1:0:0:0): INQUIRY. CDB: 12 1 80 0 ff 0 
(probe2:ata1:0:0:0): CAM Status: SCSI Status Error
(probe2:ata1:0:0:0): SCSI Status: Check Condition
(probe2:ata1:0:0:0): ILLEGAL REQUEST asc:24,0
(probe2:ata1:0:0:0): Invalid field in CDB
...
cd1 at ata1 bus 0 target 0 lun 0
cd1:  Removable CD-ROM SCSI-0 device 
cd1: 33.000MB/s transfers
cd1: cd present [216058 x 2048 byte records]
...
cd9660: Joliet Extension (Level 1)
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: RAM Recommendations for a VIA Mainboard?

[Matthias Andree]

Scott Reese <[EMAIL PROTECTED]> writes:

> Though I'm not sure if RAM is my problem because I'm not getting Sig 11
> errors.  I keep getting extremely consistent internal compiler errors
> pretty much whenever I try to build *anything*.  I've tried to
> buildkernel about 16 times today and each time I get stuck here (or very
> near here):
>
> /usr/src/sys/dev/aic7xxx/aic79xx.c: In function `ahd_run_data_fifo':
> /usr/src/sys/dev/aic7xxx/aic79xx.c:787: error: unrecognizable insn:

[...]

> /usr/src/sys/dev/aic7xxx/aic79xx.c:787: internal compiler error: in
> reload_cse_simplify_operands, at reload1.c:8345

An "internal compiler error" (ICE for short) can also be a compiler bug
if it happens in the same place consistently. I recall other "ICE"
Subject lines, but ignored the corresponding posts; the list archives
may help you.

If you need to be sure what it is, rsync your source code and compiler
to a different computer with similar OS and hardware and try there. If
it fails in the same place, it's VERY unlikely to be the RAM.

If you've been running cvsup -s for a while, trying to run it once
without -s might be useful in case some alteration went unnoticed by
cvsup (haven't seen that so far, and it's an old recommendation, not
sure if it still holds).

-- 
Matthias Andree

Encrypt your mail: my GnuPG key ID is 0x052E7D95
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: -pthread deprecated, but when?

[Matthias Andree]

Doug Barton <[EMAIL PROTECTED]> writes:

> @ ${CP} ${WRKSRC}/configure ${WRKSRC}/configure.Patched
> @ ${SED} -e 's#-lpthread#${PTHREAD_LIBS}#g' \

How about: ${SED} -Ee 's#-l?pthread#${PTHREAD_LIBS}#g' \

That's the one necessary to catch -pthread (such as BerkeleyDB) in
addition to -lpthread.

-- 
Matthias Andree

Encrypt your mail: my GnuPG key ID is 0x052E7D95
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: ATAng - copying atapi CD

[Matthias Andree]

Soren Schmidt <[EMAIL PROTECTED]> writes:

> Can you play those discs in your cd-rw drive ?

Is this a useful test after all? Most drives go down to 1x playing
audio, which is nowhere near 52x or what's current nowadays.

-- 
Matthias Andree

Encrypt your mail: my GnuPG key ID is 0x052E7D95
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: buildworld failure

[Matthias Andree]

"Daniel C. Sobral" <[EMAIL PROTECTED]> writes:

>>  I've been using freebsd since the 2.x days, I have always compiled world
>> and ports with -O2, and never had any instability issues due to the
>> optimizations. I have switched back to -O and -march=pentium4, the
>> buildworld finished ok.
>
> Lucky you. It does happen that these optimizations may result in code
> with no apparent problem, depending on one's hardware, though I suspect
> many people's "hardware problems" were nothing of the sort.

Not everything that breaks with -O2 is a compiler fault or hardware
running just a tad beyond the limit.

Anecdote: when bogofilter got the "unified" data base a month ago, one
data structure that used to be 8 bytes got extended to 12 bytes. Now,
the variable declaration was still "auto uint32_t cv[2]". memcpy()
copied 12 bytes into the 8 byte buffer (cv) and caused obscure test
suite failures when compiled with optimization on some architectures
(among them 32-bit SPARC), but was fine with lower or no optimization.

(details in sourceforge cvs browser, check src/datastore_db.c 1.29->1.30)

-- 
Matthias Andree

Encrypt your mail: my GnuPG key ID is 0x052E7D95
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: 2 ports broken after gcc import

[Matthias Andree]

Kenneth Culver <[EMAIL PROTECTED]> writes:

>> Just for more info, when was the last time you updated your /etc? on my
>> 4th -CURRENT machine, with the same compiler etc... I havn't updated my
>> /etc/ since June 1, and that machine works, the other 3 have been updated
>> very recently, like within the last few weeks, and they're all broken. So
>> I guess it's not a compiler issue, but some kind of configuration issue. I
>> can't think of what the problem could be though.
>>
> OK, checked over my kernel configurations and found that ACL's were in my
> kernel configuration. I took that option out and things are working again.
> I have no idea how ACL's could've caused what I was seeing, but everything
> is working now. Thanks for your help.

Might devfs propagate ACL characteristics via /dev nodes into
applications? Otherwise, the symptom you described would have made me
point to the IP firewall first.

-- 
Matthias Andree

Encrypt your mail: my GnuPG key ID is 0x052E7D95
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: recover superblock

[Matthias Andree]

John-Mark Gurney <[EMAIL PROTECTED]> writes:

> I've also had the problem of when you do use an alternate superblock
> via -b, it doesn't over drive the primary.  If you have a disk with
> bad blocks on the primary, you have to manualy rewrite it with dd.

...provided the drive automatically reassigns bad blocks on write
(ARWE). I've seen a drive shipping with ARRE set but ARWE unset - it
would reassign on read rather than write. Whatever the manufacturer had
in mind configuring the drive before shipping it...

-- 
Matthias Andree
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: /dev/shm

[Matthias Andree]

Dan Nelson <[EMAIL PROTECTED]> writes:

> There is already a functional non-procfs implementation that has been
> around long before procps top: groupsys top 3.5b12 (i.e. the top that
> all other non-Linux systems use) compiles fine on even the newest Linux
> kernels with the attached patch.

Apparently, groupsys top 3.5b12 with the patch you attached still opens
/proc on Linux. It _is_ faster, but I don't see why it's claimed
non-procfs. Any magic dances to perform during the build?

Feel free to respond off-list.

-- 
Matthias Andree
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: /dev/shm

[Matthias Andree]

On Mon, 07 Jul 2003, Marcin Dalecki wrote:

> The point is that this is one of the reasons why the top command in
> question takes a lot of relative CPU time under Linux. Some
> "faster" versions of procps utils try to cache data but the trade off
> is simply the fact that the results are not 100% accurate.

Top data is not accurate (I though that was obvious ;-).

It's an obsolete snapshot the very moment it's printed to your console,
and I bet it changes as you read with a lot of implementations because
no-one wants to beat the big kernel lock on the process list just
because some user happens to run top, might be a nice DoS otherwise,
fork-bombing top...

If you want accurate data, use a kernel debugger with remote interface
and make sure the machine does nothing except servicing the debugger
interface.

> I tought this was obvious?

Why do I care? 0.58user 0.89system 1:00.91elapsed 2%CPU -- on a 266 MHz
Pentium-II, Linux 2.4, 5 years old, with 190 processes. The box idles
73% of the time it's up, there's _ample_ CPU power left.

-- 
Matthias Andree
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: /dev/shm

[Matthias Andree]

Marcin Dalecki schrieb am 2003-07-07:

> Matthias Andree wrote:
> >Update your Linux top or run fewer processes on it then. :->
> 
> You know that file system name lookup is one of the most
> expensive system calls under UNIX?

So what? If you don't like the interface because it does ever so
expensive file system lookups (I wonder what's so expensive if no disk
drive latencies are involved), suggest a better one and donate an
implementation.

I'm sure I'd find disadvantages of non-Linux top if I only cared to
look. I don't. It works when I need it, it's not in my way otherwise,
that's as much as I care.

-- 
Matthias Andree
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: /dev/shm

[Matthias Andree]

Marcin Dalecki <[EMAIL PROTECTED]> writes:

> There isn't much either Solaris /proc or FresBSD /proc have in common with
> what Linux calls /proc. And finally on my FreeBSD box -
> kozaczek# mount
> /dev/ad0s1a on / (ufs, local, soft-updates)
> devfs on /dev (devfs, local)
> kozaczek# top
>
> And top doesn't eat tons of CPU time there like it does on Linux.

Update your Linux top or run fewer processes on it then. :->

-- 
Matthias Andree
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

acpiconf -s4 cannot wake up: ACPI bug, kernel bug, BIOS bug?

[Matthias Andree]

Hi,

I have a i386 machine with Gigabyte 7ZXR mainboard here (Duron, VIA
KT133 chipset, AMI BIOS).

acpiconf -s1 and -s5 are apparently "working" ok, -s2 is refused (OK),
-s3 is refused (might be I didn't set the jumper correctly :o) and -s4
puts the machine to some sort of sleep (power LED blinks, screen blanks,
ATA hard drives park), but it doesn't properly wake up from S4. It tries
to, spins the disks up, I can see a screen, but cannot type anything;
the machine goes back into s4 right away, and is in a permanent loop,
lay down to S4-sleep and wake up. Pressing NUM LOCK doesn't toggle the
NUM LOCK LED. X11 hasn't been started, just text console mode.

Any ideas, or questions for more detail?

-- 
Matthias Andree
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: make world failure: tar/cleaning object tree

[Matthias Andree]

On Mon, 16 Jun 2003, Kris Kennaway wrote:

> On Mon, Jun 16, 2003 at 10:21:51AM +0200, Matthias Andree wrote:
> > "make world" fails, "rm -rf /usr/obj ; make -DNOCLEAN world" is fine.
> 
> Always update with 'cvs update -PdA'

I used cvsup without -s. 

-- 
Matthias Andree
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

make world failure: tar/cleaning object tree

[Matthias Andree]

Hi,

"make world" fails, "rm -rf /usr/obj ; make -DNOCLEAN world" is fine.

make world failure happens in
--
>>> stage 2: cleaning up the object tree
--
...
===> gnu/usr.bin/tar
rm -f tar addext.o argmatch.o backupfile.o basename.o dirname.o error.o
exclude.
o full-write.o getdate.o getline.o getopt.o getopt1.o getstr.o hash.o
human.o mk
time.o modechange.o prepargs.o print-copyr.o quotearg.o safe-read.o
save-cwd.o s
avedir.o unicodeio.o xgetcwd.o xmalloc.o xstrdup.o xstrtoul.o
xstrtoumax.o buffe
r.o compare.o create.o delete.o extract.o incremen.o list.o mangle.o
misc.o name
s.o rtapelib.o tar.o update.o tar.1.gz tar.1.cat.gz
rm: tar: is a directory
*** Error code 1
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"