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-defaultbuild=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 sys/disk.h, 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 matthias.and...@gmx.de
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 matthias.and...@gmx.de
---
 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-defaultbuild=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 h...@selasky.org 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

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: 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 mand...@freebsd.org 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

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 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=maintid=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: 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]

Matthew Seaman matt...@freebsd.org 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 EOF  /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: 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: 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=revisionsortby=daterevision=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: 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: 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: 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, then.  It
does use NCQ, too.  FreeBSD can be booted 

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, http://people.freebsd.org/~mandree/smartctl.log.
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]

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 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]

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
http://www.freebsd.org/doc/en/books/porters-handbook/freebsd-versions.html,
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 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: 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: 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 sys/param.h and sys/systm.h before sys/ufs/ufs/ufsmount.h.

...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 li...@eitanadler.com wrote:
 On Mon, Mar 28, 2011 at 12:19 AM, Daniel O'Connor docon...@gsoft.com.au 
 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 p...@freebsd.org writes:
 Dag-Erling Smørgrav d...@des.no writes:
 Gabor PALI p...@freebsd.org 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 d...@des.no (from Thu, 19 Aug 2010  
 11:16:23 +0200):
 
 Alexander Leidinger alexan...@leidinger.net 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]

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

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

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: 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: PTLTD  APIC  
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=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE
  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]

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]

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: 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]

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]

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]

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]

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: 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: VIA 82C686A UDMA66 controller 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=0x3ATA_SLAVE,ATA_MASTER
(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: VIA 82C686A UDMA66 controller 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: PLEXTOR CD-R   PX-W4824A 1.05 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: 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: 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: 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]

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]

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]

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]

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]

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]

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. shrug

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