ls -lh: wrong aligning of size filed for symlinks
Hi, ls -lh does misalign the size field for symlinks (missing space in front of the size), /usr/share/locale: ---snip--- drwxr-xr-x 2 root wheel 512B Jan 12 15:48 tr_TR.ISO8859-9 lrwxr-xr-x 1 root wheel 15B Jan 12 15:43 tr_TR.ISO_8859-9 - tr_TR.ISO8859-9 drwxr-xr-x 2 root wheel 512B Jan 12 15:48 uk_UA.ISO8859-5 drwxr-xr-x 2 root wheel 512B Jan 12 15:48 uk_UA.KOI8-U lrwxr-xr-x 1 root wheel 11B Jan 12 15:43 zh_CN.EUC - zh_CN.eucCN drwxr-xr-x 2 root wheel 512B Jan 12 15:48 zh_CN.eucCN drwxr-xr-x 2 root wheel 512B Jan 12 15:48 zh_TW.Big5 ---snip--- Bye, Alexander. -- The three Rs of Microsoft support: Retry, Reboot, Reinstall. http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Some dmesg errors
Hello, I've jest cvsuped to recent current and got some errors in dmesg buffer: 1) Copyright (c) 1992-2002 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.0-CURRENT #0: Sat Jan 19 15:53:25 GMT 2002 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/COCOS5 Preloaded elf kernel /boot/kernel/kernel at 0xc0358000. Preloaded elf module /boot/kernel/acpi.ko at 0xc03580a8. Timecounter i8254 frequency 1193182 Hz Timecounter TSC frequency 801821689 Hz CPU: Pentium III/Pentium III Xeon/Celeron (801.82-MHz 686-class CPU) Origin = GenuineIntel Id = 0x686 Stepping = 6 Features=0x387f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,PN,MMX,FXSR,SSE WARNING: Driver mistake: make_dev(perfmon) called before SI_SUB_DRIVERS 2) microuptime() went backwards (509.4041326 - 508.388712) microuptime() went backwards (533.4159377 - 532.512632) -- _ __ __ / \ | | / / / \ / \ --- Tomasz Paszkowski -- | |\ \| | \ \ |/ \||/ \| === IPv4://3646987138 === IPNg://3ffe:8010:88::2 === /_/ \__/ /_/ \_/ \_/ http://plikoskop.pl --- To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
[no subject]
mymail.txt To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: sudo redu
FYI: pam_setcred() call seems used in OpenSSH, ftpd, rshd, login, and su already included in FreeBSD source code. URL:http://snapshots.jp.freebsd.org/tour/current/cgi-bin/global.cgi?pattern=pam_setcredid=type=reference imp OK. This looks like a problem in 1.6.4p1 of sudo. It isn't a problem imp with 1.6.3p7_2. 1.6.4 works on -stable, but not -current. I've checked about new sudo's behavior on some OSes: Debian (woody) sudo-1.6.4.1OK (tested on 1 machine) FreeBSD 2.2.8-RELEASE sudo-1.6.5.1OK (tested on 1 machine) FreeBSD 3.4-stable sudo-1.6.5.1NG (tested on 1 machine) FreeBSD 4-stablesudo-1.6.5.1OK (tested on some machines) FreeBSD 5-current sudo-1.6.5.1OK / NG (tested on some machines) OK / NG means that some machines work fine, but some machines goes wrong. *** I don't know what's the real problem, but it seems that sudo doesn't have the problem IMHO. Anyone has a solution about this problem? -- - Makoto `MAR' Matsushita To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
FreeBSD 5.x
Is gcc 3.x going to be the default compiler starting from FBSD 5.x series? Is the development on current branch compiled using gcc 3.0 (or up)? Is 5.x series going to be based on a preemptible kernel? Thanks, Alp To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: FreeBSD 5.x
[-hackers removed from CC. One list is enough.] Alp Atici [EMAIL PROTECTED] writes: Is gcc 3.x going to be the default compiler starting from FBSD 5.x series? Is the development on current branch compiled using gcc 3.0 (or up)? Yes. Not yet. Is 5.x series going to be based on a preemptible kernel? That's the plan. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
kernel has problems starting
Hi ! I have quite a big problem. I made world with newest CURRENT. Now I have all binaries 5.0, but I can't get kernel to work. It compiles ok, installs ok, but when I start system it's stops when it tells mounting root on ufs://ad0s1a. (I used GENERIC as well as my own config) I am using VMWare (I need to have FreeBSD on my development machine, but not as main OS). I installed FreeBSD 4.4 and everything worked OK with generic kernel of 4.4, but it doesn't with generic from 5.0 If anybody has any idea why it stops, please do tell me. Andy ** * Aleksander Rozman - Andy * Fandoms: E2:EA, SAABer, Trekkie, Earthie * * [EMAIL PROTECTED] * Sentinel, BH 90210, True's Trooper, * *[EMAIL PROTECTED] * Heller's Angel, Questie, Legacy, PO5, * * Maribor, Slovenia (Europe) * Profiler, Buffy (Slayerete), Pretender* * ICQ-UIC: 4911125 * * PGP key available *http://www.atechnet.dhs.org/~andy/ * ** To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: -CURRENT AIO bug Re: How well does EVFILT_AIO work?
k Macy wrote: It turns that this problem is specific to AIO in -CURRENT. I wrote a simple program that uses the three different completion mechanisms (polling with aio_error, polling with kevent, and using SIGIO) to fill up a file by writing 8kb at a time to the file and then reading 8kb at a time from the file. I believe that I've fixed this problem. Please update to revision 1.112 of kern/vfs_aio.c and retry your tests. Best regards, Alan To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Marketing Services
Warning Unable to process data: multipart/mixed;boundary==_NextPart_000_280D_6E9D.0BCF
profiled kernel build fails was Re: -CURRENT AIO bug
Thanks for working on this. I was going to try running a profiled kernel on -CURRENT and -STABLE to see what the difference was in time distribution. On -STABLE it built without a hitch. However, on -CURRENT I got the following even after doing a make clean: ../../../libkern/mcount.c: In function `mcount': ../../../libkern/mcount.c:91: `mcount_lock' undeclared (first use in this function) ../../../libkern/mcount.c:91: (Each undeclared identifier is reported only once ../../../libkern/mcount.c:91: for each function it appears in.) machine/atomic.h:141: warning: inlining failed in call to `atomic_cmpset_int' ../../../libkern/mcount.c:91: warning: called from here machine/atomic.h:234: warning: inlining failed in call to `atomic_store_rel_int' ../../../libkern/mcount.c:242: warning: called from here ../../../libkern/mcount.c: In function `mcount': ../../../libkern/mcount.c:91: `mcount_lock' undeclared (first use in this function) ../../../libkern/mcount.c:91: (Each undeclared identifier is reported only once ../../../libkern/mcount.c:91: for each function it appears in.) machine/atomic.h:141: warning: inlining failed in call to `atomic_cmpset_int' ../../../libkern/mcount.c:91: warning: called from here machine/atomic.h:234: warning: inlining failed in call to `atomic_store_rel_int' ../../../libkern/mcount.c:242: warning: called from here --- Alan L. Cox [EMAIL PROTECTED] wrote: k Macy wrote: It turns that this problem is specific to AIO in -CURRENT. I wrote a simple program that uses the three different completion mechanisms (polling with aio_error, polling with kevent, and using SIGIO) to fill up a file by writing 8kb at a time to the file and then reading 8kb at a time from the file. I believe that I've fixed this problem. Please update to revision 1.112 of kern/vfs_aio.c and retry your tests. Best regards, Alan __ Do You Yahoo!? Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: FreeBSD 5.x
On Sat, 19 Jan 2002, Alp Atici wrote: Is gcc 3.x going to be the default compiler starting from FBSD 5.x series? Is the development on current branch compiled using gcc 3.0 (or up)? Is 5.x series going to be based on a preemptible kernel? Can't answer the gcc question, but yes, John Baldwin currently has support for preemption in his SMPng development tree. Robert N M Watson FreeBSD Core Team, TrustedBSD Project [EMAIL PROTECTED] NAI Labs, Safeport Network Services To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: FreeBSD 5.x
Alp Atici wrote:
Is gcc 3.x going to be the default compiler starting from
FBSD 5.x series? Is the development on current branch
compiled using gcc 3.0 (or up)?
I think that the cut over will happen after the compiler
no longer core dumps on:
main()
{
int i;
i = foo();
switch( i) {
default:
printf( hello, stupid compiler!\n);
break;
}
}
int
foo()
{
return( 6);
}
Is 5.x series going to be based on a preemptible kernel?
A multithreaded kernel. Do ISRs count?
-- Terry
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: kernel has problems starting
Aleksander Rozman - Andy wrote: I have quite a big problem. I made world with newest CURRENT. Now I have all binaries 5.0, but I can't get kernel to work. It compiles ok, installs ok, but when I start system it's stops when it tells mounting root on ufs://ad0s1a. (I used GENERIC as well as my own config) I am using VMWare (I need to have FreeBSD on my development machine, but not as main OS). I installed FreeBSD 4.4 and everything worked OK with generic kernel of 4.4, but it doesn't with generic from 5.0 If anybody has any idea why it stops, please do tell me. Update your bootblocks. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: FreeBSD 5.x
In the last episode (Jan 19), Terry Lambert said:
Alp Atici wrote:
Is gcc 3.x going to be the default compiler starting from FBSD 5.x
series? Is the development on current branch compiled using gcc 3.0
(or up)?
I think that the cut over will happen after the compiler
no longer core dumps on:
main()
{
int i;
i = foo();
switch( i) {
default:
printf( hello, stupid compiler!\n);
break;
}
}
int
foo()
{
return( 6);
}
Doesn't core on me (gcc30+bounds-checking port, FreeBSD-current). In
fact, I've got USE_GCC30 in my make.conf and build all my ports with it
(at least the ports that aren't broken and hardcode cc or gcc).
--
Dan Nelson
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: FreeBSD 5.x
Dan Nelson [EMAIL PROTECTED] writes:
In the last episode (Jan 19), Terry Lambert said:
Alp Atici wrote:
Is gcc 3.x going to be the default compiler starting from FBSD 5.x
series? Is the development on current branch compiled using gcc 3.0
(or up)?
I think that the cut over will happen after the compiler
no longer core dumps on:
main()
{
int i;
i = foo();
switch( i) {
default:
printf( hello, stupid compiler!\n);
break;
}
}
int
foo()
{
return( 6);
}
Doesn't core on me (gcc30+bounds-checking port, FreeBSD-current). In
fact, I've got USE_GCC30 in my make.conf and build all my ports with it
(at least the ports that aren't broken and hardcode cc or gcc).
Interesting. The sparc64 toolchain suffers from this problem, so a
number of files on the sparc64 p4 branch have custom versions.
Anyway, I'm told this problem has been fixed in 3.1, which is the
planned version of GCC for 5.0-RELEASE.
Best regards,
Mike Barcroft
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: profiled kernel build fails was Re: -CURRENT AIO bug
On Sat, 19 Jan 2002, k Macy wrote:
Thanks for working on this. I was going to try running
a profiled kernel on -CURRENT and -STABLE to see what
the difference was in time distribution. On -STABLE
it built without a hitch. However, on -CURRENT I got
the following even after doing a make clean:
../../../libkern/mcount.c: In function `mcount':
../../../libkern/mcount.c:91: `mcount_lock' undeclared
(first use in this function)
The mcount_lock stuff apparently never even compiled. It is only used
for the !GUPROF SMP case, but it cannot work in that case since
mcount_lock is not declared. Unfortunately, LINT only tests the GUPROF
case, which compiles but is even more broken at runtime in the SMP
case. GUPROF worse fine in the !SMP case and should be non-optional
(it gives about 10 times as much resolution as PROF on current
machines, instead of only 1000 times as much as on 486's when it was
written).
This fix has not been tested. It has some chance of working, because
RELENG_4 uses similar code. However, it is certainly broken if the
atomic functions that it calls are not inlined (then the functions will
call MCOUNT_ENTER() on entry). I think this only happens if mcount.c
is compiled with -O0. This bug is missing in RELENG_4 too.
%%%
Index: profile.h
===
RCS file: /home/ncvs/src/sys/i386/include/profile.h,v
retrieving revision 1.25
diff -u -2 -r1.25 profile.h
--- profile.h 30 Oct 2001 15:04:57 - 1.25
+++ profile.h 20 Jan 2002 06:05:24 -
@@ -65,4 +65,5 @@
#defineMCOUNT_DECL(s) u_long s;
#ifdef SMP
+extern int mcount_lock;
#defineMCOUNT_ENTER(s) { s = read_eflags(); disable_intr(); \
while (!atomic_cmpset_acq_int(mcount_lock, 0, 1)) \
%%%
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
