Installworld fails building Current from 4.7-R

2002-10-24 Thread Richard Cotrina
Hello :

I am getting an strange error when trying to install current ( make
installworld ). I cvsup-ed it in my 4.7- Release box, and I sompiling the
sources and the kernel without any error messages :

# make -j4 buildworld
# make buildkernel
# make installkernel
# reboot

All the above finished without problems. After rebooting, I tried to do :

# make installworld

and after a while, it finished with the following error :

== usr.bin/chpass
[ ! -e /usr/bin/chpass ] || chflags noschg /usr/bin/chpass || true
*** Signal 12

Stop in /usr/src/usr.bin/chpass.
*** Error Code 1

And the console gave me this message :

/kernel pid 21078 (sh),uid 0 : exited on signal 12 ( core dumped )

Does anyone have any ideas about what I did it wrong or it is missing ?

Thanks in advance for your help

Richard Cotrina


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: Installworld fails building Current from 4.7-R

2002-10-24 Thread Craig Rodrigues
Hi,

Did you see the instructions in /usr/src/Makefile and /usr/src/UPDATING?

This is from /usr/src/Makefile:

# For individuals wanting to upgrade their sources (even if only a
# delta of a few days):
#
# 1.  `cd /usr/src'   (or to the directory containing your source tree).
# 2.  `make buildworld'
# 3.  `make buildkernel KERNCONF=YOUR_KERNEL_HERE' (default is GENERIC).
# 4.  `make installkernel KERNCONF=YOUR_KERNEL_HERE'   (default is GENERIC).
# 5.  `reboot'(in single user mode: boot -s from the loader prompt).
# 6.  `mergemaster -p'
# 7.  `make installworld'
# 8.  `mergemaster'
# 9.  `reboot'
#
# See src/UPDATING `COMMON ITEMS' for more complete information.
#

-- 
Craig Rodrigues
http://www.gis.net/~craigr
[EMAIL PROTECTED]

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: smbfs broken?

2002-10-24 Thread Vitaly Markitantov
On Wed, Oct 23, 2002 at 11:31:50AM -0700, Terry Lambert wrote:
 AHA!
 
 The reason an FFS write resulted in an SMBFS read is that
 you had mmap()'ed an SMBFS file, and then wrote a mapped
 but-not-in-core page to the target FFS file.
 
 Knowing that the code involved is in the paging path of the
 SMBFS code is important.
 
 What happens if you:
 
   dd if=/smb/urchin/pub/bytes/8145 of=8145
 
 ?  I expect that it works, no problem.
 
 Yes, it works fine in both direction - copy from and to SMBFS.
 cp still not works correctly (nor reads nor writes to SMBFS)

-- 
 Vitaly Markitantov mailto: [EMAIL PROTECTED]
 icq: 117438950  phone: (062)332-23-90

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: Groff problems (was Re: alpha tinderbox failure)

2002-10-24 Thread Ruslan Ermilov
On Wed, Oct 23, 2002 at 05:29:40PM -0400, Andrew Gallatin wrote:
 
 
 
 Ruslan Ermilov writes:
   OK, to summarize things.  There was a single problem with two
   symptoms: 1) groff, if built dynamically, could not be run
   by ld-elf.so; 2) groff, if built statically, always failed
   with ``out of memory'', apparently due to the same bug.
   
   Static hack is safe to delete because:
   
   1.  groff that is built as part of the bootstrap-tools during
   buildworld will be built static anyway (see -DNOSHARED in
   BMAKE in Makefile.inc1)
   
   2.  if you have a vulnerable kernel and rtld-elf, static
   linkage does not address the problem -- you get spurious
   ``out of memory'' even if you link groff statically.
   
   If you agree, please feel free to commit the backout of
   the hack yourself -- I'm going to leave the computer now.  :-)
 
 Removed.  
 
 Please review the following UPDATING entry:
 
 --- UPDATING3 Sep 2002 06:13:43 -   1.217
 +++ UPDATING23 Oct 2002 21:24:44 -
 @@ -22,6 +22,19 @@
 integrity.  Re-enabling write caching can substantially
 improve
 performance.
 
 +20021023:
 +   Alphas with kernels from between 20020902 and 20021022 and/or
 +   rtld (ld-elf.so.1) older than 20021022 may experience problems
 +   with groff while doing a buildworld (kernel: out of memory,
 +   rtld: too few PT_LOAD segments).
 +
 +   So, to successfully upgrade your Alpha, you must either
 +   upgrade your kernel and rtld first (which might be a bit
 +   tricky), or avoid running the bootstrapped groff during the
 +   transitional buildworld.  To avoid running groff during the
 +   transitional upgrade run make buildworld with -DNOMAN,
 +   -DNO_SHAREDOCS, and -DNO_LPR.
 +
  20020831:
 gcc has been upgraded to 3.2.  It is not all binary compatible
 with earlier versions of gcc for c++ programs.  All c++
 
 
 Note:  I have NOT tested this, beyond verifying that a kernel from Sep
 02 works fine.
 
What commit is responsible for a breakage, this one?

: peter   2002/09/03 14:18:17 PDT
: 
:   Modified files:
: sys/kern imgact_elf.c
:   Log:
:   Make the text segment locating heuristics from rev 1.121 more reliable
:   so that it works on the Alpha.  This defines the segment that the entry
:   point exists in as 'text' and any others (usually one) as data.
: 
:   Submitted by: tmm
:   Tested on: i386, alpha
: 
:   Revision  ChangesPath
:   1.125 +10 -15src/sys/kern/imgact_elf.c

Also I have verified (on beast) that previous version of Groff (1.17.1)
does not have this problem -- groff has two PT_LOAD segments.  Anyone
cares to explain what's going on here?  Why when I remove -fno-exceptions
it creates two PT_LOAD segments, why it does not affect previous version
of Groff?


Cheers,
-- 
Ruslan Ermilov  Sysadmin and DBA,
[EMAIL PROTECTED]   Sunbay Software AG,
[EMAIL PROTECTED]  FreeBSD committer,
+380.652.512.251Simferopol, Ukraine

http://www.FreeBSD.org  The Power To Serve
http://www.oracle.com   Enabling The Information Age



msg45130/pgp0.pgp
Description: PGP signature


Lack of real long double support (was Re: libstdc++ does not contain fabsl symbol)

2002-10-24 Thread Loren James Rittle
 Note that while you're adding the C99 math stuff, you
 might want to fix up float.h, which is just wrong about long
 doubles (see PR i386/38288).

 Right, I should have said no one has started committing C99 math
 functions.

(Reading this exchange reminded me that I promised fellow gcc
developers to check on this issue with FreeBSD developers.)

The gcc mainline (what will become 3.3) recently got a new
implementation of ``software floating point emulation'' (contained in
gcc/real.[hc] which is used to format all compile-time FP constants,
etc).  Along with that change, the compiler wants to provide a copy of
float.h generated from its own knowledge of FP hardware instead of
sucking information from /usr/include/float.h, as it had done in past
gcc releases.  I know that when we install gcc as the FreeBSD system
compiler, we don't bother with such header files provided from gcc
(but, for the moment please consider that people might build
cross-compilers to FreeBSD and please consider that we test future
releases of gcc as might be used as the FreeBSD system compiler from
FSF sources).  Anyways, that work exposed some issues.

We have this in the system header:

#define LDBL_MANT_DIG   DBL_MANT_DIG
#define LDBL_MIN_EXPDBL_MIN_EXP
#define LDBL_MAX_EXPDBL_MAX_EXP
[...]

Yet, the FP hardware is actually configured by default to provide
`long double' as:

#define LDBL_MANT_DIG   53
#define LDBL_MIN_EXP(-16381)
#define LDBL_MAX_EXP16384

Indeed, FP code using long double generated by gcc 2.95.X, installed
as the FreeBSD 4 system compiler, uses the full exponent range of
-16381 to 16384.  However, printf(), etc loses on that exponent range
and reports Inf.  I suspect this is why the system header misreports
the FP hardware, thus the header describes the largest printable long
double value, not the largest that could be held in a calculation.

Anyways, two questions for FreeBSD maintainers.  How should gcc, as
provided from the FSF, describe the long double FP format for
FreeBSD/i386 4.x?  Shall we assume that no changes for FreeBSD 5.x
will occur?

Unless someone strongly prefers otherwise, the I lean towards wanting
to describe the default FP hardware setup exactly and assume that libc
changes to properly support long double stdio, etc will follow at some
point.

However, that also brings to mind: Are we happy with the current
default FP hardware setup especially if support for long double is to
be improved?  At the moment we support long double in name only.
There is no extra dynamic range over a double; as might be implied
(and allowed by the hardware).

Also, as an aside, having just learned everything there is to know
about IEEE FP from a witty 80-slide presentation on the WWW by one of
the original designers of the spec@Berkeley, I'd say that he would be
sad that we default to use 53-bit precision mode.  I'd say that it is
dumb to claim we even support long double unless we change that to
64-bit precision mode...

Regarding the comment in sys/i386/include/npx.h:

 * 64-bit precision often gives bad results with high level languages
 * because it makes the results of calculations depend on whether
 * intermediate values are stored in memory or in FPU registers.

This is pure bunk when considered in broad context.  Using 53-bit
precision mode with high level languages while making actual
calculations yields more outright undetectable precision-related
errors due to algorithm design by non-numerical analysts.  I know
which error I'd rather *not* find in my naively-written and compiled
FP code.

People that write their FP code to correctly use epsilon (the one
appropriate for the type of the float they are using) should never see
this problem, no?  I don't see why FreeBSD should cater to people that
don't know how to write FP code properly (i.e. anyone that expected
exact results across compilation switches, etc) at the expense of
being able to write code that fully utilizes the best mode available
from the CPU.

People that absolutely want to avoid the problem of spilling from
register to memory truncation changing with optimization level may
feel free to allocate long doubles instead of doubles.  Problem solved.

Anyways, that is my quick speech in favor of change.  I will help
commit bits to the FSF gcc tree that supports whatever people want to
do.  It is easy to support one FP model for FreeBSD 4 and another for
FreeBSD 5.

Regards,
Loren

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



alpha tinderbox failure

2002-10-24 Thread Dag-Erling Smorgrav
--
 Rebuilding the temporary build tree
--
 stage 1: bootstrap tools
--
 stage 2: cleaning up the object tree
--
 stage 2: rebuilding the object tree
--
 stage 2: build tools
--
 stage 3: cross tools
--
 stage 4: populating /home/des/tinderbox/alpha/obj/h/des/src/alpha/usr/include
--
 stage 4: building libraries
--
=== lib/libdisk
cc1: warnings being treated as errors
/h/des/src/lib/libdisk/disk.c:428: warning: `assignToPartition' defined but not used
*** Error code 1

Stop in /h/des/src/lib/libdisk.
*** Error code 1

Stop in /h/des/src/lib.
*** Error code 1

Stop in /h/des/src.
*** Error code 1

Stop in /h/des/src.
*** Error code 1

Stop in /h/des/src.
*** Error code 1

Stop in /h/des/src.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



ia64 tinderbox failure

2002-10-24 Thread Peter Wemm
--
 Rebuilding the temporary build tree
--
 stage 1: bootstrap tools
--
 stage 2: cleaning up the object tree
--
 stage 2: rebuilding the object tree
--
 stage 2: build tools
--
 stage 3: cross tools
--
 stage 4: populating 
/home/tinderbox/ia64/obj/home/tinderbox/ia64/src/ia64/usr/include
--
 stage 4: building libraries
--
=== lib/libdisk
cc1: warnings being treated as errors
/home/tinderbox/ia64/src/lib/libdisk/disk.c:428: warning: `assignToPartition' defined 
but not used
*** Error code 1

Stop in /home/tinderbox/ia64/src/lib/libdisk.
*** Error code 1

Stop in /home/tinderbox/ia64/src/lib.
*** Error code 1

Stop in /home/tinderbox/ia64/src.
*** Error code 1

Stop in /home/tinderbox/ia64/src.
*** Error code 1

Stop in /home/tinderbox/ia64/src.
*** Error code 1

Stop in /home/tinderbox/ia64/src.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Crash again

2002-10-24 Thread Vallo Kallaste
Hi

The same kernel compiled for purposes of smbfs debugging crashed
again. I had X, make -j2 running and no smbfs mounts. For what it's
worth, the system did hang hard (no interrupts) some minutes before
the aforementioned crash and I had to reboot by hand.


Script started on Thu Oct 24 12:37:19 2002
bash-2.05b# gdb -k /sys/i386/compile/Myhakas-5.0-SMP.vana/kernel.debug /usr/cra
sh/vmcore.0
GNU gdb 5.2.1 (FreeBSD)
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB.  Type show warranty for details.
This GDB was configured as i386-undermydesk-freebsd...
panic: bwrite: buffer is not busy???
panic messages:
---
panic: lockmgr: draining against myself
cpuid = 1; lapic.id = 0100
boot() called on cpu#1

syncing disks... panic: bwrite: buffer is not busy???
cpuid = 1; lapic.id = 0100
boot() called on cpu#1
Uptime: 21m46s
pfs_vncache_unload(): 1 entries remaining
Dumping 511 MB
 16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 256 272 288 304 320 336 352 368 
384 400 416 432 448 464 480 496
---
#0  doadump () at ../../../kern/kern_shutdown.c:223
223 dumping++;
(kgdb) where
#0  doadump () at ../../../kern/kern_shutdown.c:223
#1  0xc0236e8a in boot (howto=260) at ../../../kern/kern_shutdown.c:355
#2  0xc0237147 in panic () at ../../../kern/kern_shutdown.c:508
#3  0xc027e982 in bwrite (bp=0xce3e92dc) at ../../../kern/vfs_bio.c:796
#4  0xc027f039 in bawrite (bp=0x0) at ../../../kern/vfs_bio.c:1085
#5  0xc033b16f in ffs_fsync (ap=0xd795958c) at ../../../ufs/ffs/ffs_vnops.c:236
#6  0xc033a499 in ffs_sync (mp=0xc4057400, waitfor=2, cred=0xc13c3e80, 
td=0xc0436be0) at vnode_if.h:612
#7  0xc02939e8 in sync (td=0xc0436be0, uap=0x0)
at ../../../kern/vfs_syscalls.c:130
#8  0xc0236a6b in boot (howto=256) at ../../../kern/kern_shutdown.c:264
#9  0xc0237147 in panic () at ../../../kern/kern_shutdown.c:508
#10 0xc0228f80 in lockmgr (lkp=0xc45fd43c, flags=65543, interlkp=0xc45fd378, 
td=0xc3eb70d0) at ../../../kern/kern_lock.c:433
#11 0xc028640c in vop_stdlock (ap=0x0) at ../../../kern/vfs_default.c:279
#12 0xc0349348 in ufs_vnoperate (ap=0x0) at ../../../ufs/ufs/ufs_vnops.c:2763
#13 0xc0290d6a in vclean (vp=0xc45fd378, flags=8, td=0xc3eb70d0)
at vnode_if.h:990
#14 0xc029142a in vgonel (vp=0xc45fd378, td=0x0)
at ../../../kern/vfs_subr.c:2665
#15 0xc0291310 in vrecycle (vp=0xc45fd378, inter_lkp=0x0, td=0x0)
at ../../../kern/vfs_subr.c:2620
#16 0xc03413fc in ufs_inactive (ap=0x0) at ../../../ufs/ufs/ufs_inode.c:133
#17 0xc0349348 in ufs_vnoperate (ap=0x0) at ../../../ufs/ufs/ufs_vnops.c:2763
#18 0xc0290420 in vput (vp=0xc45fd378) at vnode_if.h:930
#19 0xc033212d in handle_workitem_freeblocks (freeblks=0xc4d07500, flags=0)
at ../../../ufs/ffs/ffs_softdep.c:2494
#20 0xc03315f4 in softdep_setup_freeblocks (ip=0xc4d4c500, length=0, 
flags=2048) at ../../../ufs/ffs/ffs_softdep.c:2077
---Type return to continue, or q return to quit---
#21 0xc0327938 in ffs_truncate (vp=0xc45fd378, length=0, flags=3072, cred=0x0, 
td=0xc3eb70d0) at ../../../ufs/ffs/ffs_inode.c:271
#22 0xc03412c8 in ufs_inactive (ap=0x0) at ../../../ufs/ufs/ufs_inode.c:100
#23 0xc0349348 in ufs_vnoperate (ap=0x0) at ../../../ufs/ufs/ufs_vnops.c:2763
#24 0xc0290420 in vput (vp=0xc45fd378) at vnode_if.h:930
#25 0xc03336c2 in handle_workitem_remove (dirrem=0xc4567140, xp=0x0)
at ../../../ufs/ffs/ffs_softdep.c:3324
#26 0xc032f0ed in process_worklist_item (matchmnt=0x0, flags=0)
at ../../../ufs/ffs/ffs_softdep.c:727
#27 0xc032eea0 in softdep_process_worklist (matchmnt=0x0)
at ../../../ufs/ffs/ffs_softdep.c:624
#28 0xc028f411 in sched_sync () at ../../../kern/vfs_subr.c:1739
#29 0xc0222e14 in fork_exit (callout=0xc028f010 sched_sync, arg=0x0, 
frame=0x0) at ../../../kern/kern_fork.c:860
(kgdb) quit
bash-2.05b# exit
exit

Script done on Thu Oct 24 12:37:38 2002
-- 

Vallo Kallaste
[EMAIL PROTECTED]

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: Crash again

2002-10-24 Thread Ian Dowse
In message [EMAIL PROTECTED], Vallo Kallaste writes:
The same kernel compiled for purposes of smbfs debugging crashed
again. I had X, make -j2 running and no smbfs mounts. For what it's
worth, the system did hang hard (no interrupts) some minutes before
the aforementioned crash and I had to reboot by hand.

From the trace, we are recursing on ufs_inactive() because it needs
to grab and release a vnode reference from within vput()-VOP_INACTIVE(),
so the second vput() causes another call to VOP_INACTIVE. This looks
like something the VINACTIVE patch I posted a while ago would fix:

http://www.maths.tcd.ie/~iedowse/FreeBSD/vinactive.diff

(Sorry, I haven't updated it, so it probably needs manual merging)
See also the comments by Don Lewis on this list (Re: nfs_inactive()
bug? - panic: lockmgr:).

Kirk, is this vput() recursion expected? If so, something like the
patch above should ensure that the second vput() does not call
VOP_INACTIVE() again.

Ian

(kgdb) where
#0  doadump () at ../../../kern/kern_shutdown.c:223
#1  0xc0236e8a in boot (howto=260) at ../../../kern/kern_shutdown.c:355
#2  0xc0237147 in panic () at ../../../kern/kern_shutdown.c:508
#3  0xc027e982 in bwrite (bp=0xce3e92dc) at ../../../kern/vfs_bio.c:796
#4  0xc027f039 in bawrite (bp=0x0) at ../../../kern/vfs_bio.c:1085
#5  0xc033b16f in ffs_fsync (ap=0xd795958c) at ../../../ufs/ffs/ffs_vnops.c:23
6
#6  0xc033a499 in ffs_sync (mp=0xc4057400, waitfor=2, cred=0xc13c3e80, 
td=0xc0436be0) at vnode_if.h:612
#7  0xc02939e8 in sync (td=0xc0436be0, uap=0x0)
at ../../../kern/vfs_syscalls.c:130
#8  0xc0236a6b in boot (howto=256) at ../../../kern/kern_shutdown.c:264
#9  0xc0237147 in panic () at ../../../kern/kern_shutdown.c:508
#10 0xc0228f80 in lockmgr (lkp=0xc45fd43c, flags=65543, interlkp=0xc45fd378, 
td=0xc3eb70d0) at ../../../kern/kern_lock.c:433
#11 0xc028640c in vop_stdlock (ap=0x0) at ../../../kern/vfs_default.c:279
#12 0xc0349348 in ufs_vnoperate (ap=0x0) at ../../../ufs/ufs/ufs_vnops.c:2763
#13 0xc0290d6a in vclean (vp=0xc45fd378, flags=8, td=0xc3eb70d0)
at vnode_if.h:990
#14 0xc029142a in vgonel (vp=0xc45fd378, td=0x0)
at ../../../kern/vfs_subr.c:2665
#15 0xc0291310 in vrecycle (vp=0xc45fd378, inter_lkp=0x0, td=0x0)
at ../../../kern/vfs_subr.c:2620
#16 0xc03413fc in ufs_inactive (ap=0x0) at ../../../ufs/ufs/ufs_inode.c:133
#17 0xc0349348 in ufs_vnoperate (ap=0x0) at ../../../ufs/ufs/ufs_vnops.c:2763
#18 0xc0290420 in vput (vp=0xc45fd378) at vnode_if.h:930
#19 0xc033212d in handle_workitem_freeblocks (freeblks=0xc4d07500, flags=0)
at ../../../ufs/ffs/ffs_softdep.c:2494
#20 0xc03315f4 in softdep_setup_freeblocks (ip=0xc4d4c500, length=0, 
flags=2048) at ../../../ufs/ffs/ffs_softdep.c:2077
---Type return to continue, or q return to quit---
#21 0xc0327938 in ffs_truncate (vp=0xc45fd378, length=0, flags=3072, cred=0x0,
 
td=0xc3eb70d0) at ../../../ufs/ffs/ffs_inode.c:271
#22 0xc03412c8 in ufs_inactive (ap=0x0) at ../../../ufs/ufs/ufs_inode.c:100
#23 0xc0349348 in ufs_vnoperate (ap=0x0) at ../../../ufs/ufs/ufs_vnops.c:2763
#24 0xc0290420 in vput (vp=0xc45fd378) at vnode_if.h:930
#25 0xc03336c2 in handle_workitem_remove (dirrem=0xc4567140, xp=0x0)
at ../../../ufs/ffs/ffs_softdep.c:3324
#26 0xc032f0ed in process_worklist_item (matchmnt=0x0, flags=0)
at ../../../ufs/ffs/ffs_softdep.c:727
#27 0xc032eea0 in softdep_process_worklist (matchmnt=0x0)
at ../../../ufs/ffs/ffs_softdep.c:624
#28 0xc028f411 in sched_sync () at ../../../kern/vfs_subr.c:1739
#29 0xc0222e14 in fork_exit (callout=0xc028f010 sched_sync, arg=0x0, 
frame=0x0) at ../../../kern/kern_fork.c:860

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



sparc64 tinderbox failure

2002-10-24 Thread Mike Barcroft
--
 Rebuilding the temporary build tree
--
 stage 1: bootstrap tools
--
 stage 2: cleaning up the object tree
--
 stage 2: rebuilding the object tree
--
 stage 2: build tools
--
 stage 3: cross tools
--
 stage 4: populating 
/tinderbox/sparc64/obj/tinderbox/sparc64/src/sparc64/usr/include
--
 stage 4: building libraries
--
=== lib/libdisk
cc1: warnings being treated as errors
/tinderbox/sparc64/src/lib/libdisk/disk.c:428: warning: `assignToPartition' defined 
but not used
*** Error code 1

Stop in /tinderbox/sparc64/src/lib/libdisk.
*** Error code 1

Stop in /tinderbox/sparc64/src/lib.
*** Error code 1

Stop in /tinderbox/sparc64/src.
*** Error code 1

Stop in /tinderbox/sparc64/src.
*** Error code 1

Stop in /tinderbox/sparc64/src.
*** Error code 1

Stop in /tinderbox/sparc64/src.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Floating point problems

2002-10-24 Thread Peter Edwards
Hi,
There was some discussion about issues with interactions between the floating 
point context and signal handling in a thread a week or so ago, and a suggestion 
that someone try and get a simple test that would fail. I was surprised how
easy it was: The following program just spins calculating the value of 6.0 / 
3.0, and traps SIGINT.

If you run it on -current (as of a few hours ago), 99% of the time, hitting 
ctl-C will cause the program to exit with an error. A 4.5 kernel never causes 
any problems.

I'm pretty sure this is what's causing the stalls and crashes in X. I've taken
stack traces of crashes, and from spinning processes, and I can spot NaNs on
the stack that shouldn't be there, etc.

I just thought it might be useful to send this, to firmly take the blame
away from the X server, and give someone a way of reproducing the bug.

fptest.c:

#include math.h
#include stdio.h
#include signal.h
#include assert.h


int count = 0;
void sigint(int sig)
{
write(2, INT\n, 4);
count++;
}

int
main(int argc, char **argv)
{
double x = 6.0;
double y = 3.0;
double d;
double err;
struct sigaction sa;

sa.sa_handler = sigint;
sa.sa_flags = 0;
sigemptyset(sa.sa_mask);
sigaction(SIGINT, sa, 0);

while (count  30) {
d = x / y;
err = 2.0 - d;
if (err != 0.0) {
fprintf(stderr, err %f!\n, err);
exit(-1);
}
}
}


-- 
Peter Edwards.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Installing from CD and MAKEDEV

2002-10-24 Thread Jun Kuriyama

I've created install CD with make iso.1 (with sources few hours
before).

I'm trying to install fresh current box with this CD.  But I got
MAKEDEV returned non-zero status dialog after extracting dists.

It seems cd /dev; sh MAKEDEV all is failed at devfs environment.

Is this my local problem?


-- 
Jun Kuriyama [EMAIL PROTECTED] // IMG SRC, Inc.
 [EMAIL PROTECTED] // FreeBSD Project

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: Lack of real long double support (was Re: libstdc++ does notcontain fabsl symbol)

2002-10-24 Thread Bruce Evans
On Thu, 24 Oct 2002, Loren James Rittle wrote:

 ...  Anyways, that work exposed some issues.

 We have this in the system header:

 #define LDBL_MANT_DIG   DBL_MANT_DIG
 #define LDBL_MIN_EXPDBL_MIN_EXP
 #define LDBL_MAX_EXPDBL_MAX_EXP
 [...]

This seems to be correct.  Long double precision is not really supported
either at complie time or runtime.  The default precision (on i386's)
is 53 bits, so (normalized) long doubles have a hard time getting any
larger than DBL_MAX or any smaller than DBL_MIN (you can create them
as bits or using a hardware transcendental function, but any arithmetic
on them will convert them to double precision).

 Yet, the FP hardware is actually configured by default to provide
 `long double' as:

 #define LDBL_MANT_DIG   53

I think you mean 64 (the hardware default).

 #define LDBL_MIN_EXP(-16381)
 #define LDBL_MAX_EXP16384

 Indeed, FP code using long double generated by gcc 2.95.X, installed
 as the FreeBSD 4 system compiler, uses the full exponent range of
 -16381 to 16384.  However, printf(), etc loses on that exponent range
 and reports Inf.  I suspect this is why the system header misreports
 the FP hardware, thus the header describes the largest printable long
 double value, not the largest that could be held in a calculation.

gcc can't actually support the full range, since it doesn't control
the runtime environement (it could issue a fninit before main() to
change the default, but it shouldn't and doesn't).  The exponent
range is lost long before printf() is reached.  E.g.,

long double x= DBL_MAX;
long double y = 2 * x;

gives +Inf for y since the result is doesn't fit in 53-bit precision.
The system header correctly reports this default precision.  Any header
genrated by the gcc build should be no different, since the build should
run in the target environment.

 Anyways, two questions for FreeBSD maintainers.  How should gcc, as
 provided from the FSF, describe the long double FP format for
 FreeBSD/i386 4.x?  Shall we assume that no changes for FreeBSD 5.x
 will occur?

It should use whatever is the default format for the host environment,
It still has enquire.c for doing this automatically.  I don't know
when enquire.c actually gets used.  The FreeBSD build just ignores it
and uses src/sys/${MACHINE_ARCH}/float.h.  My first encounter with this
bug suite was near enquire.c 12-14 years ago.  enquire gave different
results for -msoft-float and hardware FP because my soft-float libraries
only had 53-bit precision but hardware FP used 64-bit precision.

 ...
 However, that also brings to mind: Are we happy with the current
 default FP hardware setup especially if support for long double is to
 be improved?  At the moment we support long double in name only.
 There is no extra dynamic range over a double; as might be implied
 (and allowed by the hardware).

Not really.  Assembly is still required to get full control over precision.
I'm still waiting for (C) language support to catch up.  Been waiting for
about 14 years so far.  C99 clarified the semantics of floating point
precision but is not supported by gcc (yet?).

 Also, as an aside, having just learned everything there is to know
 about IEEE FP from a witty 80-slide presentation on the WWW by one of
 the original designers of the spec@Berkeley, I'd say that he would be
 sad that we default to use 53-bit precision mode.  I'd say that it is
 dumb to claim we even support long double unless we change that to
 64-bit precision mode...

I think he would be even unhappier with gcc's support for it.  We default
to 53-bit precision partly because Kahan's (his?) paranioa(1) is unhappy
with 64-bit precision.

 Regarding the comment in sys/i386/include/npx.h:

  * 64-bit precision often gives bad results with high level languages
  * because it makes the results of calculations depend on whether
  * intermediate values are stored in memory or in FPU registers.

 This is pure bunk when considered in broad context.  Using 53-bit
 precision mode with high level languages while making actual
 calculations yields more outright undetectable precision-related
 errors due to algorithm design by non-numerical analysts.  I know
 which error I'd rather *not* find in my naively-written and compiled
 FP code.

I think it makes no provably significant difference for naively-written
code.  I'd rather get the same (perhaps wrong) results on all machines
from naively-written code.

 People that write their FP code to correctly use epsilon (the one
 appropriate for the type of the float they are using) should never see
 this problem, no?

No.  They would see strange behaviour cause by compiler bugs.

 I don't see why FreeBSD should cater to people that
 don't know how to write FP code properly (i.e. anyone that expected
 exact results across compilation switches, etc) at the expense of
 being able to write code that fully utilizes the best mode available
 from the CPU.

IEEE754 provides many guarantees about 

Re: Groff problems (was Re: alpha tinderbox failure)

2002-10-24 Thread Andrew Gallatin

Ruslan Ermilov writes:
...
   +20021023:
   +   Alphas with kernels from between 20020902 and 20021022 and/or
   +   rtld (ld-elf.so.1) older than 20021022 may experience problems
   +   with groff while doing a buildworld (kernel: out of memory,
   +   rtld: too few PT_LOAD segments).
   +
   +   So, to successfully upgrade your Alpha, you must either
   +   upgrade your kernel and rtld first (which might be a bit
   +   tricky), or avoid running the bootstrapped groff during the
   +   transitional buildworld.  To avoid running groff during the
   +   transitional upgrade run make buildworld with -DNOMAN,
   +   -DNO_SHAREDOCS, and -DNO_LPR.
   +
20020831:
   gcc has been upgraded to 3.2.  It is not all binary compatible
   with earlier versions of gcc for c++ programs.  All c++
   
   
   Note:  I have NOT tested this, beyond verifying that a kernel from Sep
   02 works fine.
   
  What commit is responsible for a breakage, this one?
  
  : peter   2002/09/03 14:18:17 PDT
  : 
  :   Modified files:
  : sys/kern imgact_elf.c
  :   Log:
  :   Make the text segment locating heuristics from rev 1.121 more reliable
  :   so that it works on the Alpha.  This defines the segment that the entry


More or less..  The data, text and vmem limit checking in general.
Matt's initial commit on 20020830 broke Alpha totally, so the earliest
kernel that would both exhibit the problem and could get to the point of
attempting to build world would be from 20020903.I'll update
my proposed UPDATING entry with the 20020903 date so as to be more
exact.   Assuming I do that,  do you agree that its accurate enough to
be helpful?

Thanks,

Drew

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: Groff problems (was Re: alpha tinderbox failure)

2002-10-24 Thread Ruslan Ermilov
On Thu, Oct 24, 2002 at 09:12:26AM -0400, Andrew Gallatin wrote:
 
 Ruslan Ermilov writes:
 ...
+20021023:
+   Alphas with kernels from between 20020902 and 20021022 and/or
+   rtld (ld-elf.so.1) older than 20021022 may experience problems
+   with groff while doing a buildworld (kernel: out of memory,
+   rtld: too few PT_LOAD segments).
+
+   So, to successfully upgrade your Alpha, you must either
+   upgrade your kernel and rtld first (which might be a bit
+   tricky), or avoid running the bootstrapped groff during the
+   transitional buildworld.  To avoid running groff during the
+   transitional upgrade run make buildworld with -DNOMAN,
+   -DNO_SHAREDOCS, and -DNO_LPR.
+
 20020831:
gcc has been upgraded to 3.2.  It is not all binary compatible
with earlier versions of gcc for c++ programs.  All c++


Note:  I have NOT tested this, beyond verifying that a kernel from Sep
02 works fine.

   What commit is responsible for a breakage, this one?
   
   : peter   2002/09/03 14:18:17 PDT
   : 
   :   Modified files:
   : sys/kern imgact_elf.c
   :   Log:
   :   Make the text segment locating heuristics from rev 1.121 more reliable
   :   so that it works on the Alpha.  This defines the segment that the entry
 
 
 More or less..  The data, text and vmem limit checking in general.
 Matt's initial commit on 20020830 broke Alpha totally, so the earliest
 kernel that would both exhibit the problem and could get to the point of
 attempting to build world would be from 20020903.I'll update
 my proposed UPDATING entry with the 20020903 date so as to be more
 exact.   Assuming I do that,  do you agree that its accurate enough to
 be helpful?
 
Yes.  It may be worth specifying which files/revisions are responsible
for a fix -- it might be useful for those who attempt to fix their
kernel/rtld first.

One thing I'm still missing is why groff binary now comes with only
one PT_LOAD segment, and why this is Alpha specific?  And why if I
checkout old, -D2002/10/10 contrib/groff and gnu/usr.bin/groff and
compile gnu/usr.bin/groff/src/roff/groff on the same machine (I
tried it on beast.freebsd.org), it produces two PT_LOAD segments?
(These are actually two things.)


Cheers,
-- 
Ruslan Ermilov  Sysadmin and DBA,
[EMAIL PROTECTED]   Sunbay Software AG,
[EMAIL PROTECTED]  FreeBSD committer,
+380.652.512.251Simferopol, Ukraine

http://www.FreeBSD.org  The Power To Serve
http://www.oracle.com   Enabling The Information Age



msg45141/pgp0.pgp
Description: PGP signature


Re: smbfs broken?

2002-10-24 Thread Sheldon Hearn
On (2002/10/23 11:31), Terry Lambert wrote:

 AHA!
 
 The reason an FFS write resulted in an SMBFS read is that
 you had mmap()'ed an SMBFS file, and then wrote a mapped
 but-not-in-core page to the target FFS file.

Well, a similar problem occurred with cat(1), which doesn't use mmap().

However, I should have included in my message that the following
messages are received from the kernel:

Oct 23 17:53:02 axl kernel: smbfs_getpages: error 60
Oct 23 17:53:02 axl kernel: vm_fault: pager read error, pid 8022 (cp)
Oct 23 17:58:18 axl kernel: smbfs_getpages: error 4
Oct 23 17:58:18 axl kernel: vm_fault: pager read error, pid 8087 (cp)

This supports your theory.

Ciao,
Sheldon.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: Floating point problems

2002-10-24 Thread Bruce Evans
On Thu, 24 Oct 2002, Peter Edwards wrote:

 There was some discussion about issues with interactions between the floating
 point context and signal handling in a thread a week or so ago, and a suggestion
 that someone try and get a simple test that would fail. I was surprised how
 easy it was: The following program just spins calculating the value of 6.0 /
 3.0, and traps SIGINT.

 If you run it on -current (as of a few hours ago), 99% of the time, hitting
 ctl-C will cause the program to exit with an error. A 4.5 kernel never causes
 any problems.

 I'm pretty sure this is what's causing the stalls and crashes in X. I've taken
 stack traces of crashes, and from spinning processes, and I can spot NaNs on
 the stack that shouldn't be there, etc.

Thanks.  This makes the main bug clear.  The PCB_NPXINITDONE bit in the
state was not being restored.  This was confusing to debug because gdb
doesn't understand this bug so it shows the state that should have been
restored until npxdna() unrestores it consistently.  Try this fix.

%%%
Index: npx.c
===
RCS file: /home/ncvs/src/sys/i386/isa/npx.c,v
retrieving revision 1.133
diff -u -2 -r1.133 npx.c
--- npx.c   20 Oct 2002 17:30:30 -  1.133
+++ npx.c   24 Oct 2002 14:20:33 -
@@ -1004,4 +1007,5 @@
bcopy(addr, td-td_pcb-pcb_save, sizeof(*addr));
}
+   curthread-td_pcb-pcb_flags |= PCB_NPXINITDONE;
 }

%%%

Bruce


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: Floating point problems

2002-10-24 Thread Peter Edwards
Well, that's certainly fixed the problems my test app had.

As for X:
I was regularly able to hurt X by clicking randomly on the transfers 
window in Opera, and switching between it and other internal frames:
symptoms included SEGVs, minute-long hangs, etc. Invoking such rain-dances
failed to produce any positive results after about 5 mins., which is
3-4 times longer than its ever been up before under the same stress. I'll
report back in about 24 hours either way, but I think that's cured it.
--
Peter.



Bruce Evans [EMAIL PROTECTED] wrote:

 
 On Thu, 24 Oct 2002, Peter Edwards wrote:
 
  There was some discussion about issues with interactions between the floating
  point context and signal handling in a thread a week or so ago, and a suggestion
  that someone try and get a simple test that would fail. I was surprised how
  easy it was: The following program just spins calculating the value of 6.0 /
  3.0, and traps SIGINT.
 
  If you run it on -current (as of a few hours ago), 99% of the time, hitting
  ctl-C will cause the program to exit with an error. A 4.5 kernel never causes
  any problems.
 
  I'm pretty sure this is what's causing the stalls and crashes in X. I've taken
  stack traces of crashes, and from spinning processes, and I can spot NaNs on
  the stack that shouldn't be there, etc.
 
 Thanks.  This makes the main bug clear.  The PCB_NPXINITDONE bit in the
 state was not being restored.  This was confusing to debug because gdb
 doesn't understand this bug so it shows the state that should have been
 restored until npxdna() unrestores it consistently.  Try this fix.
 
 %%%
 Index: npx.c
 ===
 RCS file: /home/ncvs/src/sys/i386/isa/npx.c,v
 retrieving revision 1.133
 diff -u -2 -r1.133 npx.c
 --- npx.c 20 Oct 2002 17:30:30 -  1.133
 +++ npx.c 24 Oct 2002 14:20:33 -
 @@ -1004,4 +1007,5 @@
   bcopy(addr, td-td_pcb-pcb_save, sizeof(*addr));
   }
 + curthread-td_pcb-pcb_flags |= PCB_NPXINITDONE;
  }
 
 %%%
 
 Bruce
 
 

-- 
Peter Edwards.



To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



sparc64 tinderbox failure

2002-10-24 Thread Mike Barcroft
--
 Rebuilding the temporary build tree
--
 stage 1: bootstrap tools
--
 stage 2: cleaning up the object tree
--
 stage 2: rebuilding the object tree
--
 stage 2: build tools
--
 stage 3: cross tools
--
 stage 4: populating 
/tinderbox/sparc64/obj/tinderbox/sparc64/src/sparc64/usr/include
--
 stage 4: building libraries
--
 stage 4: make dependencies
--
 stage 4: building everything..
--
=== usr.sbin/pkg_install/info
cc1: warnings being treated as errors
/tinderbox/sparc64/src/usr.sbin/pkg_install/info/show.c: In function `show_size':
/tinderbox/sparc64/src/usr.sbin/pkg_install/info/show.c:239: warning: passing arg 1 of 
`getbsize' from incompatible pointer type
*** Error code 1

Stop in /tinderbox/sparc64/src/usr.sbin/pkg_install/info.
*** Error code 1

Stop in /tinderbox/sparc64/src/usr.sbin/pkg_install.
*** Error code 1

Stop in /tinderbox/sparc64/src/usr.sbin.
*** Error code 1

Stop in /tinderbox/sparc64/src.
*** Error code 1

Stop in /tinderbox/sparc64/src.
*** Error code 1

Stop in /tinderbox/sparc64/src.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: sparc64 tinderbox failure

2002-10-24 Thread Andrew Gallatin

Mike Barcroft writes:
   stage 4: building everything..
  --
  === usr.sbin/pkg_install/info
  cc1: warnings being treated as errors
  /tinderbox/sparc64/src/usr.sbin/pkg_install/info/show.c: In function `show_size':
  /tinderbox/sparc64/src/usr.sbin/pkg_install/info/show.c:239: warning: passing arg 1 
 of `getbsize' from incompatible pointer type
  *** Error code 1
  


I fixed this an hour or 2 ago when I hit it on my alpha.

How long does a sparc64 buildworld take on reasonably priced hardware?
Where resonable means = $1000 USD, used OK.

Drew Gallatin


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



sleeping with mountlist locked

2002-10-24 Thread Lars Eggert
Hi,

just got this when trying to umount a media from an USB CF reader:

/usr/src/sys/kern/kern_synch.c:146: sleeping with mountlist locked 
from /usr/src/sys/kern/vfs_mount.c:1321. I have a core dump, but it's of 
the second panic.

Debugger(witness_sleep)
Stopped at  Debugger+0x5a:  xchgl   %ebx,in_Debugger.0^M

db trace
Debugger(c0441373,c043e1e9,92,c04413b4,c0445a4a) at Debugger+0x5a
witness_sleep(0,c04e532c,c043e1e9,92,8) at witness_sleep+0xe0
msleep(c8770564,c04e532c,50,c0459436,0) at msleep+0x5a
acquire(c8770564,140,600,e6,464c) at acquire+0x78
lockmgr(c8770564,1030002,c87704a0,c75d3b60,eb8d4bf4) at lockmgr+0x22d
vop_stdlock(eb8d4c10,eb8d4c30,c02d6c05,eb8d4c10,0) at vop_stdlock+0x2c
ufs_vnoperate(eb8d4c10,0,c04461c0,360,c026d9c3) at ufs_vnoperate+0x18
vn_lock(c87704a0,20002,c75d3b60,529,40) at vn_lock+0xa5
dounmount(c6d22400,0,c75d3b60,bfbffc6b,0) at dounmount+0x30f
unmount(c75d3b60,eb8d4d10,c0464b1d,42d,c75d4228) at unmount+0xc7
syscall(2f,2f,2f,809a02e,80b3b3d) at syscall+0x406
Xint0x80_syscall() at Xint0x80_syscall+0x1d
--- syscall (22, FreeBSD ELF32, unmount), eip = 0x804ae8b, esp = 
0xbfbff5bc, ebp = 0xbfbff638 ---

db c
panic: sleeping thread owns a mutex
cpuid = 0; lapic.id = 
Debugger(panic)
Stopped at  Debugger+0x5a:  xchgl   %ebx,in_Debugger.0

db trace
Debugger(c043db3a,0,c043cd21,df2d7c08,1) at Debugger+0x5a
panic(c043cd21,1,c043cc46,6b,246) at panic+0x12f
propagate_priority(c23ad0d0,2,c043cc46,236,c043cc46) at 
propagate_priority+0x285
_mtx_lock_sleep(c04a1ba0,0,c0445ac2,d6e,c0445ac2) at _mtx_lock_sleep+0x129
_mtx_lock_flags(c04a1ba0,0,c0445ac2,d6e,c674da00) at _mtx_lock_flags+0x87
sync_fsync(df2d7cd0,20002,c23ad0d0,6a1,0) at sync_fsync+0xab
sched_sync(0,df2d7d48,c043b2ce,354,0) at sched_sync+0x16f
fork_exit(c02ca8a0,0,df2d7d48) at fork_exit+0x8d
fork_trampoline() at fork_trampoline+0x1a

Lars
--
Lars Eggert [EMAIL PROTECTED]   USC Information Sciences Institute


smime.p7s
Description: S/MIME Cryptographic Signature


Re: mozilla-devel problems

2002-10-24 Thread Wesley Morgan
On Thu, 24 Oct 2002, Adam Weinberger wrote:

  (10.24.2002 @ 1036 PST): Adam Weinberger said, in 2.2K: 
  I'll put in a screenshot after I get moz recompiled with XFT.
  end of Re: mozilla-devel problems from Adam Weinberger 

 FWIW, this is a screenshot of my -STABLE machine:

   http://people.freebsd.org/~adamw/smacky_ss_20021024.jpg

I just finished a build of mozilla-devel, and the fonts look just as
gorgeous as they do in Konqueror. If anyone is having problems with these
fonts, try removing the Type1 module from your X config, and/or altering
the fontpath so that directories with truetype fonts are listed first.
I've been told that the directory order does matter, but I do not know how
much this applies with the new font-config/Xft2 system.



-- 
Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread!


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



kernel broken in ip_fw2.c

2002-10-24 Thread Dennis Kristensen
Hi!

Looks like kernel is broken without the bellow patch.


-Dennis

--- /usr/src/sys/netinet/ip_fw2.c   Thu Oct 24 20:04:44 2002
+++ /usr/src/sys/netinet/ip_fw2.c.new   Thu Oct 24 22:48:43 2002
@@ -2501,7 +2501,7 @@ ipfw_ctl(struct sockopt *sopt)
for (rule = layer3_chain; rule ; rule = rule-next) {
int i = RULESIZE(rule);
bcopy(rule, bp, i);
-   ((struct ip_fw *)bp)-set_disable = set_disable;
+   ((struct ip_fw *)bp)-next_rule = set_disable;
bp = (struct ip_fw *)((char *)bp + i);
}
if (ipfw_dyn_v) {
@@ -2513,7 +2513,7 @@ ipfw_ctl(struct sockopt *sopt)
for ( p = ipfw_dyn_v[i] ; p != NULL ;
p = p-next, dst++ ) {
bcopy(p, dst, sizeof *p);
-   dst-rulenum = p-rule-rulenum;
+   dst-rule = p-rule-rulenum;
/*
 * store a non-null value in next.
 * The userland code will interpret a




To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



alpha tinderbox failure

2002-10-24 Thread Dag-Erling Smorgrav
--
 Rebuilding the temporary build tree
--
 stage 1: bootstrap tools
--
 stage 2: cleaning up the object tree
--
 stage 2: rebuilding the object tree
--
 stage 2: build tools
--
 stage 3: cross tools
--
 stage 4: populating /home/des/tinderbox/alpha/obj/h/des/src/alpha/usr/include
--
 stage 4: building libraries
--
 stage 4: make dependencies
--
 stage 4: building everything..
--
=== sbin/ipfw
/h/des/src/sbin/ipfw/ipfw2.c: In function `show_ipfw':
/h/des/src/sbin/ipfw/ipfw2.c:814: structure has no member named `set_disable'
/h/des/src/sbin/ipfw/ipfw2.c: In function `show_dyn_ipfw':
/h/des/src/sbin/ipfw/ipfw2.c:1201: structure has no member named `rulenum'
/h/des/src/sbin/ipfw/ipfw2.c: In function `sets_handler':
/h/des/src/sbin/ipfw/ipfw2.c:1435: structure has no member named `set_disable'
/h/des/src/sbin/ipfw/ipfw2.c: In function `list':
/h/des/src/sbin/ipfw/ipfw2.c:1621: structure has no member named `rulenum'
/h/des/src/sbin/ipfw/ipfw2.c:1623: structure has no member named `rulenum'
*** Error code 1

Stop in /h/des/src/sbin/ipfw.
*** Error code 1

Stop in /h/des/src/sbin.
*** Error code 1

Stop in /h/des/src.
*** Error code 1

Stop in /h/des/src.
*** Error code 1

Stop in /h/des/src.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: Installworld fails building Current from 4.7-R

2002-10-24 Thread Richard Cotrina
Yes, I did. However make installworld fails as I said.

- Original Message -
From: Craig Rodrigues [EMAIL PROTECTED]
To: Richard Cotrina [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Thursday, October 24, 2002 5:02 PM
Subject: Re: Installworld fails building Current from 4.7-R


 Hi,

 Did you see the instructions in /usr/src/Makefile and /usr/src/UPDATING?

 This is from /usr/src/Makefile:

 # For individuals wanting to upgrade their sources (even if only a
 # delta of a few days):
 #
 # 1.  `cd /usr/src'   (or to the directory containing your source
tree).
 # 2.  `make buildworld'
 # 3.  `make buildkernel KERNCONF=YOUR_KERNEL_HERE' (default is
GENERIC).
 # 4.  `make installkernel KERNCONF=YOUR_KERNEL_HERE'   (default is
GENERIC).
 # 5.  `reboot'(in single user mode: boot -s from the loader
prompt).
 # 6.  `mergemaster -p'
 # 7.  `make installworld'
 # 8.  `mergemaster'
 # 9.  `reboot'
 #
 # See src/UPDATING `COMMON ITEMS' for more complete information.
 #

 --
 Craig Rodrigues
 http://www.gis.net/~craigr
 [EMAIL PROTECTED]

 To Unsubscribe: send mail to [EMAIL PROTECTED]
 with unsubscribe freebsd-current in the body of the message



To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: sparc64 tinderbox failure

2002-10-24 Thread Jake Burkholder
Apparently, On Thu, Oct 24, 2002 at 04:19:09PM -0400,
Andrew Gallatin said words to the effect of;

 
 Mike Barcroft writes:
stage 4: building everything..
   --
   === usr.sbin/pkg_install/info
   cc1: warnings being treated as errors
   /tinderbox/sparc64/src/usr.sbin/pkg_install/info/show.c: In function `show_size':
   /tinderbox/sparc64/src/usr.sbin/pkg_install/info/show.c:239: warning: passing arg 
1 of `getbsize' from incompatible pointer type
   *** Error code 1
   
 
 
 I fixed this an hour or 2 ago when I hit it on my alpha.
 
 How long does a sparc64 buildworld take on reasonably priced hardware?
 Where resonable means = $1000 USD, used OK.

You can get a dual 300mhz ultra 60 on ebay for $900-1000 USD.  Mine
does a make -j 8 buildworld in just over 2 hours with some strategic
stuff turned off in make.conf (profiled libs, objective c, fortran).

Thu Oct 24 15:10:18 GMT 2002
 7546.53 real 10633.14 user  1818.80 sys

Search for sun ultra on ebay; I got mine from paladintech.  Ultra 10s
are cheaper but more PC class, my 300mhz does a full buildworld in about
5 hours last time I timed it.  Ultra 2 is probably the best value, but
we don't support the builtin scsi controller yet.

You can also get various new machines on sun.com for around $1000 USD,
IIRC a 500mhz blade 100 does a buildworld in around 2-3 hours.

Jake

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



ia64 tinderbox failure

2002-10-24 Thread Peter Wemm
--
 Rebuilding the temporary build tree
--
 stage 1: bootstrap tools
--
 stage 2: cleaning up the object tree
--
 stage 2: rebuilding the object tree
--
 stage 2: build tools
--
 stage 3: cross tools
--
 stage 4: populating 
/home/tinderbox/ia64/obj/home/tinderbox/ia64/src/ia64/usr/include
--
 stage 4: building libraries
--
 stage 4: make dependencies
--
 stage 4: building everything..
--
=== sbin/ipfw
/home/tinderbox/ia64/src/sbin/ipfw/ipfw2.c: In function `show_ipfw':
/home/tinderbox/ia64/src/sbin/ipfw/ipfw2.c:814: structure has no member named 
`set_disable'
/home/tinderbox/ia64/src/sbin/ipfw/ipfw2.c: In function `show_dyn_ipfw':
/home/tinderbox/ia64/src/sbin/ipfw/ipfw2.c:1201: structure has no member named 
`rulenum'
/home/tinderbox/ia64/src/sbin/ipfw/ipfw2.c: In function `sets_handler':
/home/tinderbox/ia64/src/sbin/ipfw/ipfw2.c:1435: structure has no member named 
`set_disable'
/home/tinderbox/ia64/src/sbin/ipfw/ipfw2.c: In function `list':
/home/tinderbox/ia64/src/sbin/ipfw/ipfw2.c:1621: structure has no member named 
`rulenum'
/home/tinderbox/ia64/src/sbin/ipfw/ipfw2.c:1623: structure has no member named 
`rulenum'
*** Error code 1

Stop in /home/tinderbox/ia64/src/sbin/ipfw.
*** Error code 1

Stop in /home/tinderbox/ia64/src/sbin.
*** Error code 1

Stop in /home/tinderbox/ia64/src.
*** Error code 1

Stop in /home/tinderbox/ia64/src.
*** Error code 1

Stop in /home/tinderbox/ia64/src.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: Installworld fails building Current from 4.7-R

2002-10-24 Thread Mike Hunter


On Thu, 24 Oct 2002, Richard Cotrina wrote:

 Yes, I did. However make installworld fails as I said.

I ran into the same problem going from 4.6 to 5.0-CURRENT.

We used truss to see that sh was making funny calls, and concluded that
we'd need to run from the kernel to get it working.  We installed the
new kernel and were able to complete the install.

Definitely not knowledgeable enough to be posting to freebsd-current,

Mike Hunter


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: kernel broken in ip_fw2.c

2002-10-24 Thread Maxime Henrion
Dennis Kristensen wrote:
 Hi!
 
 Looks like kernel is broken without the bellow patch.

The below patch is incorrect, I just forgot to commit changes to
ip_fw.h.  This should be fixed now.

Cheers,
Maxime

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: Installworld fails building Current from 4.7-R

2002-10-24 Thread Nate Lawson
On Thu, 24 Oct 2002, Mike Hunter wrote:
 On Thu, 24 Oct 2002, Richard Cotrina wrote:
 
  Yes, I did. However make installworld fails as I said.
 
 I ran into the same problem going from 4.6 to 5.0-CURRENT.
 
 We used truss to see that sh was making funny calls, and concluded that
 we'd need to run from the kernel to get it working.  We installed the
 new kernel and were able to complete the install.
 
 Definitely not knowledgeable enough to be posting to freebsd-current,
 
 Mike Hunter

That's why there is a reboot between installing the new kernel and doing
installworld.  You need to run the new kernel to have the ABI match.

-Nate


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



libgtop port and v_tag changes

2002-10-24 Thread Nate Lawson
On Thu, 24 Oct 2002, John Baldwin wrote:
 Speaking of v_tag, can you fix the devel/libgtop port on current?
 This is the patch I used to get it building the other day:
 
  cat patch-sysdeps_freebsd_procmap.c 
 --- sysdeps/freebsd/procmap.c.orig  Tue Oct 15 20:00:35 2002
 +++ sysdeps/freebsd/procmap.c   Tue Oct 15 20:05:54 2002
 @@ -251,6 +251,7 @@
   vnode, sizeof (vnode)) != sizeof (vnode))
 glibtop_error_io_r (server, kvm_read (vnode));
  
 +#if __FreeBSD_version  50
 if ((vnode.v_type != VREG) || (vnode.v_tag != VT_UFS) ||
 !vnode.v_data) continue;
  
 @@ -261,6 +262,7 @@
  
 maps [i-1].inode  = inode.i_number;
 maps [i-1].device = inode.i_dev;
 +#endif
  #endif
 } while (entry.next != first);
 
 -- 
 
 John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/
 Power Users Use the Power to Serve!  -  http://www.FreeBSD.org/

I assume Joe has a better version he planned to commit as referenced by
this email:

  [EMAIL PROTECTED]

I like his patch better because it still handles the non CURRENT case.  
Joe?

-Nate


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: Lack of real long double support (was Re: libstdc++ does notcontain fabsl symbol)

2002-10-24 Thread Loren James Rittle
Thanks for the quick answer Bruce.  Based on the statement: ``It
should use whatever is the default format for the host environment''
and the statements that make it clear gcc isn't changing its default
precision setting anytime soon, I think I now know how to make a
correct patch for the FSF gcc mainline.  More details in line below.

Regards,
Loren

 ...  Anyways, that work exposed some issues.

 We have this in the system header:

 #define LDBL_MANT_DIG   DBL_MANT_DIG
 #define LDBL_MIN_EXPDBL_MIN_EXP
 #define LDBL_MAX_EXPDBL_MAX_EXP
 [...]

 This seems to be correct.  Long double precision is not really supported
 either at complie time or runtime.  The default precision (on i386's)
 is 53 bits, so (normalized) long doubles have a hard time getting any
 larger than DBL_MAX or any smaller than DBL_MIN (you can create them
 as bits or using a hardware transcendental function, but any arithmetic
 on them will convert them to double precision).

It is easy to generate, with arithmetic, a long double value outside
the *exponent* range above no matter how the precision is set; it is
not truncated to Inf until it is actually cast to a double (as is
currently done just before a long double is printed with stdio).  See
below for a program that demonstrates this behavior.

 Yet, the FP hardware is actually configured by default to provide
 `long double' as:

 #define LDBL_MANT_DIG   53

 I think you mean 64 (the hardware default).

No sir, I did mean as configured in the system startup code, it is
forced to 53-bits (that choice affects long double as well as double).
But there are no IEEE control bits to limit the size of the exponent
field, are there?  Thus, the following describes the exact size of the
HW's exponent field of a long double as configured by default:

 #define LDBL_MIN_EXP(-16381)
 #define LDBL_MAX_EXP16384

 gcc can't actually support the full range, since it doesn't control
 the runtime environement (it could issue a fninit before main() to
 change the default, but it shouldn't and doesn't).  The exponent
 range is lost long before printf() is reached.  E.g.,

   long double x= DBL_MAX;
   long double y = 2 * x;

 gives +Inf for y since the result is doesn't fit in 53-bit precision.

As you know, the selection of maximum precision is orthogonal to the
number of bits used for the exponent.

I do wish you were correct.  Have you looked at the raw memory of y?
It is *not* the bit pattern for +Inf.  If y were +Inf, then based on
the properties of IEEE math, the following would report Inf not
DBL_MAX/2:

#include float.h
int main (void)
{
  long double x= LDBL_MAX; // Same as DBL_MAX in current float.h
  long double y = 2e100 * x; // If LDBL_MAX was correct, we should latch Inf.
  long double z = y / 4e100;
  printf (%Lg\n, z);
}

It does, in fact, report DBL_MAX/2 with the system compiler on FreeBSD
4.  FYI, I reviewed the generated code to ensure it was using run-time
calculations not compile-time calculations.  I'd call that a rather
easy time getting a normalized long double much larger than
LDBL_MAX/DBL_MAX.  This test alone proves in my mind that the
float.h system header for i386 is itself wrong.

 The system header correctly reports this default precision.  Any header
 genrated by the gcc build should be no different, since the build should
 run in the target environment.

I agree that the precision setting in the system header is fine.  The
size of the exponent field is buggy.  I held the opinion you have but
while trying to convince RTH (the guy that rewrote gcc FP support), I
did enough research that also leads me to think that it is the header
itself which is buggy.

If you really want, I can tell RTH that FreeBSD/i386 absolutely wants
`long double' to be:

53 mantissa bits
1024 max exponent

And we can let the chips fall where they may but that is lie verses
the hardware setup just to match a buggy system header.  Attempting to
get that patch in was what triggered my research and first post.

 Anyways, two questions for FreeBSD maintainers.  How should gcc, as
 provided from the FSF, describe the long double FP format for
 FreeBSD/i386 4.x?  Shall we assume that no changes for FreeBSD 5.x
 will occur?

 It should use whatever is the default format for the host environment,
 It still has enquire.c for doing this automatically.  [...]

I fear I didn't explain clearly enough.  enquire.c is completely
*gone* in gcc 3.3.  This is why gcc needs to fully understand the
exact FP default configuration.  As you noted, enquire.c was buggy.

 I think he would be even unhappier with gcc's support for it.  We default
 to 53-bit precision partly because Kahan's (his?) paranioa(1) is unhappy
 with 64-bit precision.

I can't disagree with the first statement.  However, support for FP in
gcc has just been rewritten and the paranioa test was pulled into gcc.
Perhaps it is time to revisit some past assumptions related to FP when
gcc 3.3 is imported as the system compiler.  And of 

Re: Installworld fails building Current from 4.7-R

2002-10-24 Thread Nate Lawson
[Redirected to current@ with sender's approval]

On Thu, 24 Oct 2002, Mike Hunter wrote:
 On Thu, 24 Oct 2002, Nate Lawson wrote:
 
  That's why there is a reboot between installing the new kernel and doing
  installworld.  You need to run the new kernel to have the ABI match.
 
 From my understanding of what was written earlier today (and what the guy
 who was helping me said) the boot loader is not updated during that first
 reboot, and therefore the old kernel is booted on that reboot.
 5.0-current moves the default location of the kernel IIRC.
 
 I'm pretty sure that I followed the UPDATING directions to the letter.
 
 Mike

I've run into the same problem in the past but manually selected the new
kernel.  Should we add the explicit step that you need to load
/boot/kernel/kernel when upgrading?  Or has that been fixed?

-Nate


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: sparc64 tinderbox failure

2002-10-24 Thread Kris Kennaway
On Thu, Oct 24, 2002 at 06:39:15PM -0400, Jake Burkholder wrote:

 You can get a dual 300mhz ultra 60 on ebay for $900-1000 USD.  Mine
 does a make -j 8 buildworld in just over 2 hours with some strategic
 stuff turned off in make.conf (profiled libs, objective c, fortran).

I got my ultra 30 on ebay for $250..it's just (still) missing a disk.
You can find good bargains if you're willing to be patient and hunt
for them.

My NFS-backed buildworld times probably aren't relevant here :-)

Kris


msg45160/pgp0.pgp
Description: PGP signature


kernel broken?

2002-10-24 Thread Julian Elischer

I thought this might be one on mine, but
it doesn't look like mine..

(I'm busy recompiling a version with my latest changes backed out 
to check though.. in the mean  while.. if anyone wants to claim
this)

IPsec: Initialized Security Association Processing.
ad0: 9541MB ST310211A [19386/16/63] at ata0-master UDMA100
acd0: CDROM CDU5211 at ata1-master PIO4
Mounting root from ufs:/dev/ad0s1a
Enter full pathname of shell or RETURN for /bin/sh: 
# fsck -p
lock order reversal
 1st 0xc0420400 spechash (spechash) @ ../../../kern/vfs_subr.c:1962
 2nd 0xc1d6f228 process lock (process lock) @
../../../i386/i386/trap.c:731


Fatal trap 12: page fault while in kernel mode
fault virtual address   = 0x78
fault code  = supervisor write, page not present
instruction pointer = 0x8:0xc0217f58
stack pointer   = 0x10:0xcc34a8d8
frame pointer   = 0x10:0xcc34a8f0
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 42 (fsck)
kernel: type 12 trap, code=0
Stopped at  v_incr_usecount+0x48:   addl%esi,0x78(%eax)
db Context switches not allowed in the debugger.
db tr
v_incr_usecount(c1d76cb8,,c037b472,863,cc34a92c) at
v_incr_usecount+0x48vrele(c1d76cb8,c1c90a00,c036cc7a,6,100) at
vrele+0xb0
addaliasu(c1d76cb8,402,c1cb6200,cc34a9c0,c1d73b00) at addaliasu+0x1ad
devfs_allocv(c1d8f880,c1c90a00,cc34ac38,c0f26340,c01e6fe0) at
devfs_allocv+0xee
devfs_lookupx(cc34ab50,1,0,c0f26340,6) at devfs_lookupx+0x58f
devfs_lookup(cc34ab50,c0f26340,0,c0f26340,c037b472) at devfs_lookup+0x4b
lookup(cc34ac24,0,c037ad9a,a4,cc34abb8) at lookup+0x302
namei(cc34ac24,c01bb4bd,c03fbac0,1,c037264a) at namei+0x24e
stat(c0f26340,cc34ad10,c039bed6,409,2) at stat+0x52
syscall(2f,2f,2f,8057e86,805b52f) at syscall+0x28e
Xint0x80_syscall() at Xint0x80_syscall+0x1d





To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: kernel broken? (devfs maybe?)

2002-10-24 Thread Julian Elischer
nope.. not mine..(just backed everything out here and retested..
still got it..)

don't know if the lock reversal is related...
That may be an orthogonal bug..


On Thu, 24 Oct 2002, Julian Elischer wrote:

 
 I thought this might be one on mine, but
 it doesn't look like mine..
 
 (I'm busy recompiling a version with my latest changes backed out 
 to check though.. in the mean  while.. if anyone wants to claim
 this)
 
 IPsec: Initialized Security Association Processing.
 ad0: 9541MB ST310211A [19386/16/63] at ata0-master UDMA100
 acd0: CDROM CDU5211 at ata1-master PIO4
 Mounting root from ufs:/dev/ad0s1a
 Enter full pathname of shell or RETURN for /bin/sh: 
 # fsck -p
 lock order reversal
  1st 0xc0420400 spechash (spechash) @ ../../../kern/vfs_subr.c:1962
  2nd 0xc1d6f228 process lock (process lock) @
 ../../../i386/i386/trap.c:731
 
 
 Fatal trap 12: page fault while in kernel mode
 fault virtual address = 0x78
 fault code= supervisor write, page not present
 instruction pointer   = 0x8:0xc0217f58
 stack pointer = 0x10:0xcc34a8d8
 frame pointer = 0x10:0xcc34a8f0
 code segment  = base 0x0, limit 0xf, type 0x1b
   = DPL 0, pres 1, def32 1, gran 1
 processor eflags  = interrupt enabled, resume, IOPL = 0
 current process   = 42 (fsck)
 kernel: type 12 trap, code=0
 Stopped at  v_incr_usecount+0x48:   addl%esi,0x78(%eax)
 db Context switches not allowed in the debugger.
 db tr
 v_incr_usecount(c1d76cb8,,c037b472,863,cc34a92c) at
 v_incr_usecount+0x48vrele(c1d76cb8,c1c90a00,c036cc7a,6,100) at
 vrele+0xb0
 addaliasu(c1d76cb8,402,c1cb6200,cc34a9c0,c1d73b00) at addaliasu+0x1ad
 devfs_allocv(c1d8f880,c1c90a00,cc34ac38,c0f26340,c01e6fe0) at
 devfs_allocv+0xee
 devfs_lookupx(cc34ab50,1,0,c0f26340,6) at devfs_lookupx+0x58f
 devfs_lookup(cc34ab50,c0f26340,0,c0f26340,c037b472) at devfs_lookup+0x4b
 lookup(cc34ac24,0,c037ad9a,a4,cc34abb8) at lookup+0x302
 namei(cc34ac24,c01bb4bd,c03fbac0,1,c037264a) at namei+0x24e
 stat(c0f26340,cc34ad10,c039bed6,409,2) at stat+0x52
 syscall(2f,2f,2f,8057e86,805b52f) at syscall+0x28e
 Xint0x80_syscall() at Xint0x80_syscall+0x1d
 
 
 
 
 
 To Unsubscribe: send mail to [EMAIL PROTECTED]
 with unsubscribe freebsd-current in the body of the message
 


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



sparc64 tinderbox failure

2002-10-24 Thread Mike Barcroft
--
 Rebuilding the temporary build tree
--
 stage 1: bootstrap tools
--
 stage 2: cleaning up the object tree
--
 stage 2: rebuilding the object tree
--
 stage 2: build tools
--
 stage 3: cross tools
--
 stage 4: populating 
/tinderbox/sparc64/obj/tinderbox/sparc64/src/sparc64/usr/include
--
 stage 4: building libraries
--
 stage 4: make dependencies
--
 stage 4: building everything..
--
=== sbin/ipfw
/tinderbox/sparc64/src/sbin/ipfw/ipfw2.c: In function `show_ipfw':
/tinderbox/sparc64/src/sbin/ipfw/ipfw2.c:814: structure has no member named 
`set_disable'
/tinderbox/sparc64/src/sbin/ipfw/ipfw2.c: In function `show_dyn_ipfw':
/tinderbox/sparc64/src/sbin/ipfw/ipfw2.c:1201: structure has no member named `rulenum'
/tinderbox/sparc64/src/sbin/ipfw/ipfw2.c: In function `sets_handler':
/tinderbox/sparc64/src/sbin/ipfw/ipfw2.c:1435: structure has no member named 
`set_disable'
/tinderbox/sparc64/src/sbin/ipfw/ipfw2.c: In function `list':
/tinderbox/sparc64/src/sbin/ipfw/ipfw2.c:1621: structure has no member named `rulenum'
/tinderbox/sparc64/src/sbin/ipfw/ipfw2.c:1623: structure has no member named `rulenum'
*** Error code 1

Stop in /tinderbox/sparc64/src/sbin/ipfw.
*** Error code 1

Stop in /tinderbox/sparc64/src/sbin.
*** Error code 1

Stop in /tinderbox/sparc64/src.
*** Error code 1

Stop in /tinderbox/sparc64/src.
*** Error code 1

Stop in /tinderbox/sparc64/src.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: Re: kernel broken? (devfs maybe?)

2002-10-24 Thread Andrew Gallatin

Try backing out phk's src/sys/kern/vfs_subr.c 1.416
Does that help?

Drew

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: Installworld fails building Current from 4.7-R

2002-10-24 Thread The Gupta Age

|
|I've run into the same problem in the past but manually selected the new
|kernel.  Should we add the explicit step that you need to load
|/boot/kernel/kernel when upgrading?  Or has that been fixed?
|
|-Nate

I have posted atleast twice on current to add this
info to UPDATING. guess it still hasnt been done.


Saurabh Gupta


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: libgtop port and v_tag changes

2002-10-24 Thread Joe Marcus Clarke
On Thu, 2002-10-24 at 19:13, Nate Lawson wrote:
 On Thu, 24 Oct 2002, John Baldwin wrote:
  Speaking of v_tag, can you fix the devel/libgtop port on current?
  This is the patch I used to get it building the other day:
  
   cat patch-sysdeps_freebsd_procmap.c 
  --- sysdeps/freebsd/procmap.c.orig  Tue Oct 15 20:00:35 2002
  +++ sysdeps/freebsd/procmap.c   Tue Oct 15 20:05:54 2002
  @@ -251,6 +251,7 @@
vnode, sizeof (vnode)) != sizeof (vnode))
  glibtop_error_io_r (server, kvm_read (vnode));
   
  +#if __FreeBSD_version  50
  if ((vnode.v_type != VREG) || (vnode.v_tag != VT_UFS) ||
  !vnode.v_data) continue;
   
  @@ -261,6 +262,7 @@
   
  maps [i-1].inode  = inode.i_number;
  maps [i-1].device = inode.i_dev;
  +#endif
   #endif
  } while (entry.next != first);
  
  -- 
  
  John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/
  Power Users Use the Power to Serve!  -  http://www.FreeBSD.org/
 
 I assume Joe has a better version he planned to commit as referenced by
 this email:
 
   [EMAIL PROTECTED]
 
 I like his patch better because it still handles the non CURRENT case.  
 Joe?

I committed my patch to libgtop and libgtop2 a while ago.  It should
work on both -CURRENT, not so -CURRENT, and -stable.  Checkout patch-ah
in libgtop/files.  Works like a champ on -CURRENT from Monday.

Joe

 
 -Nate
 
 
 To Unsubscribe: send mail to [EMAIL PROTECTED]
 with unsubscribe freebsd-current in the body of the message
 
-- 
PGP Key : http://www.marcuscom.com/pgp.asc



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


mi_switch deadlock?

2002-10-24 Thread Lamont Granquist


my -current box keeps freezing about every 24h.  i broke into the kernel
and forced a panic and found lots of processes stuck in mi_switch().

my uname is a build from tuesday running on an SMP machine:

uname -a
FreeBSD coredump.scriptkiddie.org 5.0-CURRENT FreeBSD 5.0-CURRENT #16: Tue
Oct 22 19:42:51 PDT 2002 
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/COREDUMP  i386

i can get more information if anyone needs it...

Script started on Thu Oct 24 18:58:57 2002
You have mail.
coredump# gdb -k kernel.debug /var/crash/vmcore.4
GNU gdb 5.2.1 (FreeBSD)
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB.  Type show warranty for details.
This GDB was configured as i386-undermydesk-freebsd...
panic: bremfree: bp 0xce62a48c not locked
panic messages:
---
panic: lockmgr: pid 8272, not exclusive lock holder 7858 unlocking
panic: from debugger
Uptime: 4h30m13s
pfs_vncache_unload(): 1 entries remaining
Dumping 511 MB
ata0: resetting devices ..
done
 16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 256 272 288 304 320 336 352 368 
384 400 416 432 448 464 480 496Copyright (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 #16: Tue Oct 22 19:42:51 PDT 2002
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/COREDUMP
Preloaded elf kernel /boot/kernel/kernel at 0xc06a5000.
Preloaded elf module /boot/kernel/acpi.ko at 0xc06a50a8.
Timecounter i8254  frequency 1193182 Hz
Timecounter TSC  frequency 1400057705 Hz
CPU: AMD Athlon(TM) XP 1600+ (1400.06-MHz 686-class CPU)
  Origin = AuthenticAMD  Id = 0x662  Stepping = 2
  
Features=0x383fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE
  AMD Features=0xc048MP,AMIE,DSP,3DNow!
real memory  = 536788992 (524208K bytes)
avail memory = 513298432 (501268K bytes)
Initializing GEOMetry subsystem
Pentium Pro MTRR support enabled
npx0: math processor on motherboard
npx0: INT 16 interface
acpi0: ASUS   A7M266-D on motherboard
Using $PIR table, 9 entries at 0xc00f1370
acpi0: power button is handled as a fixed feature programming model.
acpi0: sleep button is handled as a fixed feature programming model.
Timecounter ACPI-fast  frequency 3579545 Hz
acpi_timer0: 24-bit timer at 3.579545MHz port 0xe408-0xe40b on acpi0
acpi_cpu0: CPU on acpi0
acpi_cpu1: CPU on acpi0
acpi_button0: Power Button on acpi0
pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0
 initial configuration 
 before setting priority for links 
 before fixup boot-disabled links -
 after fixup boot-disabled links --
 arbitrated configuration -
pci0: ACPI PCI bus on pcib0
agp0: AMD 762 host to AGP bridge port 0xe800-0xe803 mem 
0xfb80-0xfb800fff,0xfc00-0xfdff at device 0.0 on pci0
pcib1: ACPI PCI-PCI bridge at device 1.0 on pci0
 initial configuration 
 before setting priority for links 
 before fixup boot-disabled links -
 after fixup boot-disabled links --
 arbitrated configuration -
pci1: ACPI PCI bus on pcib1
pci1: display, VGA at device 5.0 (no driver attached)
isab0: PCI-ISA bridge at device 7.0 on pci0
isa0: ISA bus on isab0
atapci0: AMD 768 ATA100 controller port 0xd800-0xd80f at device 7.1 on pci0
ata0: at 0x1f0 irq 14 on atapci0
ata1: at 0x170 irq 15 on atapci0
pci0: bridge, PCI-unknown at device 7.3 (no driver attached)
ahc0: Adaptec 3960D Ultra160 SCSI adapter port 0xd400-0xd4ff mem 
0xed80-0xed800fff irq 10 at device 9.0 on pci0
aic7899: Ultra160 Wide Channel A, SCSI Id=7, 32/253 SCBs
ahc1: Adaptec 3960D Ultra160 SCSI adapter port 0xd000-0xd0ff mem 
0xed00-0xed000fff irq 5 at device 9.1 on pci0
aic7899: Ultra160 Wide Channel B, SCSI Id=7, 32/253 SCBs
pcib2: ACPI PCI-PCI bridge at device 16.0 on pci0
pcib2: could not get PCI interrupt routing table for \\_SB_.PCI0.OP2P - AE_NOT_FOUND
pci2: ACPI PCI bus on pcib2
fxp0: Intel Pro 10/100B/100+ Ethernet port 0xb800-0xb83f mem 
0xeb80-0xeb8f,0xec00-0xec000fff irq 10 at device 6.0 on pci2
fxp0: Ethernet address 00:90:27:bc:09:95
inphy0: i82555 10/100 media interface on miibus0
inphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
pci2: multimedia, audio at device 8.0 (no driver attached)
pci2: input device at device 8.1 (no driver attached)
ppc0 port 0x778-0x77f,0x378-0x37f irq 7 drq 3 on acpi0
ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode
ppc0: FIFO with 16/16/9 bytes threshold
plip0: PLIP network interface on ppbus0
lpt0: Printer on ppbus0
lpt0: Interrupt-driven port
ppi0: Parallel I/O on ppbus0
sio0 

Re: Expensive timeout(9) function @an_stats_update() [/usr/src/sys/dev/an/if_an.c:724]

2002-10-24 Thread Doug Ambrisko
David Wolfskill writes:
| Noticed a bunch of:
|  Expensive timeout(9) function: 0xc0170e40(0xc274c000) 0.001114387
| 
| from running (yesterday's) -CURRENT, so I thought I'd check against
| (yesterday's kernel.debug (before I replaced it with today's).
| 
| I do have some patches to the an driver installed (from Doug Ambrisko)
| that don't seem to have been committed (yet?).
| 
| If he (or anyone else) would like me to test things, I'm willing and
| able.

I haven't seen that but -current isn't being very stable on my laptop
so I have to keep going back to -stable for my job.  I'm getting some
patches ready to commit.  Need some work on the man page.  It closes
a PR that was partially incomplete.  You might want to get rid of
that old stuff and try this.  The only timeout calls an_stats_update.
I don't really see why it would take a long time.  Note this patch
doesn't touch that function so it shouldn't fix that problem.

Doug A.

Index: sys/dev/an/if_aironet_ieee.h
===
RCS file: /cvs/src/sys/dev/an/if_aironet_ieee.h,v
retrieving revision 1.10
diff -c -r1.10 if_aironet_ieee.h
*** sys/dev/an/if_aironet_ieee.h23 Sep 2002 18:54:29 -  1.10
--- sys/dev/an/if_aironet_ieee.h25 Oct 2002 03:33:33 -
***
*** 132,137 
--- 132,156 
  };
  #endif
  
+ /*
+  * The card provides an 8-bit signal strength value (RSSI), which can
+  * be converted to a dBm power value (or a percent) using a table in
+  * the card's firmware (when available).  The tables are slightly
+  * different in individual cards, even of the same model.  If the
+  * table is not available, the mapping can be approximated by dBm =
+  * RSSI - 100.  This approximation can be seen by plotting a few
+  * tables, and also matches some info on the Intersil web site (I
+  * think they make the RF front end for the cards.  However, the linux
+  * driver uses the approximation dBm = RSSI/2 - 95.  I think that is
+  * just wrong. 
+  */
+ 
+ struct an_rssi_entry {
+   u_int8_tan_rss_pct;
+   u_int8_tan_rss_dbm;
+ };
+ 
+ 
  struct an_ltv_key {
u_int16_t   an_len;
u_int16_t   an_type;
***
*** 335,340 
--- 354,360 
  #define AN_RXMODE_80211_MONITOR_ANYBSS0x0004
  #define AN_RXMODE_LAN_MONITOR_CURBSS  0x0005
  #define AN_RXMODE_NO_8023_HEADER  0x0100
+ #define AN_RXMODE_NORMALIZED_RSSI 0x0200
  
  #define AN_RATE_1MBPS 0x0002
  #define AN_RATE_2MBPS 0x0004
***
*** 503,508 
--- 523,538 
/* ??? */
  };
  
+ /* 
+  * RSSI map.  If available in the card's firmware, this can be used to
+  * convert the 8-bit RSSI values from the card into dBm.
+  */
+ struct an_ltv_rssi_map {
+   u_int16_t   an_len;
+   u_int16_t   an_type;
+   struct an_rssi_entryan_entries[256];
+ };
+ 
  /*
   * Status (read only). Note: the manual claims this RID is 108 bytes
   * long (0x6A is the last datum, which is 2 bytes long) however when
***
*** 520,526 
u_int8_tan_macaddr[6];  /* 0x02 */
u_int16_t   an_opmode;  /* 0x08 */
u_int16_t   an_errcode; /* 0x0A */
!   u_int16_t   an_cur_signal_strength; /* 0x0C */
u_int16_t   an_ssidlen; /* 0x0E */
u_int8_tan_ssid[32];/* 0x10 */
u_int8_tan_ap_name[16]; /* 0x30 */
--- 550,556 
u_int8_tan_macaddr[6];  /* 0x02 */
u_int16_t   an_opmode;  /* 0x08 */
u_int16_t   an_errcode; /* 0x0A */
!   u_int16_t   an_signal_quality;  /* 0x0C */
u_int16_t   an_ssidlen; /* 0x0E */
u_int8_tan_ssid[32];/* 0x10 */
u_int8_tan_ap_name[16]; /* 0x30 */
***
*** 541,552 
u_int16_t   an_cur_signal_quality;  /* 0x6C */
u_int16_t   an_current_tx_rate; /* 0x6E */
u_int16_t   an_ap_device;   /* 0x70 */
!   u_int16_t   an_normalized_rssi; /* 0x72 */
u_int16_t   an_short_pre_in_use;/* 0x74 */
u_int8_tan_ap_ip_addr[4];   /* 0x76 */
!   u_int16_t   an_max_noise_prev_sec;  /* 0x7A */
!   u_int16_t   an_avg_noise_prev_min;  /* 0x7C */
!   u_int16_t   an_max_noise_prev_min;  /* 0x7E */
u_int16_t   an_spare[5];
  };
  
--- 571,585 
u_int16_t   an_cur_signal_quality;  /* 0x6C */
u_int16_t   an_current_tx_rate; /* 0x6E */
u_int16_t

Re: mi_switch deadlock?

2002-10-24 Thread Julian Elischer
On Thu, 24 Oct 2002, Lamont Granquist wrote:

 
 
 my -current box keeps freezing about every 24h.  i broke into the kernel
 and forced a panic and found lots of processes stuck in mi_switch().

Most processes are actually in mi_switch
that's the last think a process does before it is switched away from..



To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



ia64 tinderbox failure

2002-10-24 Thread Peter Wemm
--
 Rebuilding the temporary build tree
--
 stage 1: bootstrap tools
--
 stage 2: cleaning up the object tree
--
 stage 2: rebuilding the object tree
--
 stage 2: build tools
--
 stage 3: cross tools
--
 stage 4: populating 
/home/tinderbox/ia64/obj/home/tinderbox/ia64/src/ia64/usr/include
--
 stage 4: building libraries
--
 stage 4: make dependencies
--
 stage 4: building everything..
--
=== usr.sbin/sysinstall
/home/tinderbox/ia64/src/usr.sbin/sysinstall/dmenu.c: In function `dmenuOpen':
/home/tinderbox/ia64/src/usr.sbin/sysinstall/dmenu.c:291: warning: cast to pointer 
from integer of different size
/home/tinderbox/ia64/src/usr.sbin/sysinstall/dmenu.c:295: warning: cast to pointer 
from integer of different size
/home/tinderbox/ia64/src/usr.sbin/sysinstall/dmenu.c:299: warning: cast to pointer 
from integer of different size
/home/tinderbox/ia64/src/usr.sbin/sysinstall/menus.c:1370: warning: initialization 
makes integer from pointer without a cast
disks.o: In function `diskPartitionWrite':
disks.o(.text+0x2f72): undefined reference to `Write_Disk'
*** Error code 1

Stop in /home/tinderbox/ia64/src/usr.sbin/sysinstall.
*** Error code 1

Stop in /home/tinderbox/ia64/src/usr.sbin.
*** Error code 1

Stop in /home/tinderbox/ia64/src.
*** Error code 1

Stop in /home/tinderbox/ia64/src.
*** Error code 1

Stop in /home/tinderbox/ia64/src.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



is src/UPDATING up to date

2002-10-24 Thread Mathieu Arnold
Hi

I was twiddling with my yesterday's current, I was trying to make release
to see how things were going, and I saw at the top of UPDATING that :

In addition, IDE write caching is currently disabled by default
due to on-going concerns about disk write order and file system
integrity.  Re-enabling write caching can substantially improve
performance.

I looked at ata(4), told me about hw.ata.wc, which was supposed to be
enabled by default, and it was, so, my question is, is the comment above
still true, and how do I enable write cache if it is, if it's not true any
more, maybe it should be removed.

-- 
Mathieu Arnold

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: Installing from CD and MAKEDEV

2002-10-24 Thread Bruce A. Mah
If memory serves me right, Jun Kuriyama wrote:

 I've created install CD with make iso.1 (with sources few hours
 before).
 
 I'm trying to install fresh current box with this CD.  But I got
 MAKEDEV returned non-zero status dialog after extracting dists.
 
 It seems cd /dev; sh MAKEDEV all is failed at devfs environment.
 
 Is this my local problem?

I've seen this too...with a release created from sources about twelve
hours old.  I'm not in a position to troubleshoot right now...it's past
my bedtime here.  :-)

Bruce.





msg45173/pgp0.pgp
Description: PGP signature