Re: unrar doesn't work under current

[Riccardo Torrini]

On 18-Dec-2002 (07:33:03/GMT) Kris Kennaway wrote:

>> But what about rar/unrar ports that overwrite one each other?

> I don't know what you mean here.

Try to install /usr/ports/archivers/{rar,unrar} in any order...
And then (or even better, before then) look at installed files:

# cd /usr/ports/archivers && grep bin/unrar {un,}rar/pkg-plist
unrar/pkg-plist:bin/unrar
rar/pkg-plist:bin/unrar

At this point removing one of each port (rar,unrar) destroy the
other bin/unrar.  Is this a desidered feature?


> And _why_ rar port works (on same file) and unrar not?
> (at least this is a but in rar that doesn't do correct locking?)

Ooppss, s/but/bug/  (as stated before I need a vacancy  :-)


Riccardo.

PS: we have the same problem at least with autoconf*/automake* pair,
where installed files names overlapping.  IMVHO think this is a
Bad Thing(tm).  (Anyway this is not a -CURRENT-only problem)

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

Re: sio and ed woes - ACPI hallucinating

[ianf]

Bruce Evans wrote:
> On Tue, 17 Dec 2002 [EMAIL PROTECTED] wrote:
> 
> > I have a problem getting CURRENT to find my ISA SMC Ultra ethernet
> > card.  No matter what I do I can't stop the kernel finding a third
> > sio device on top of the memory and interrupt that the ed card
> > occupies.  The kernel correctly registers its surprise at finding
> > the third sio device since no hints for it exist:
> >
> > sio0 port 0x3f8-0x3ff irq 4 on acpi0
> > sio0: type 16550A
> > sio1 port 0x2f8-0x2ff irq 3 on acpi0
> > sio1: type 16550A
> > sio2: configured irq 10 not in bitmap of probed irqs 0
> > sio2: port may not be enabled
> > sio2 port 0x2e8-0x2ef irq 10 on acpi0
> > sio2: type 16550A
> >
> > I've tried setting hint.sio.2.disabled=1.  I've tried leaving it
> > out.  I can't not have sio because this server is my router and is
> > permanently connected to a modem.
> 
> I guess sio2 really exists.  In any case, you don't really want it

It didn't before CURRENT.  4.7-STABLE never found sio2.

> because iof the interrupt conflict.  Try using full hints for it.  I
> would have expected just the "disabled" hint to work though.  Try
> leaving out the irq hint.  This should give polled mode for sio (and
> thus no conflict with other devices using the irq) and works for the
> plain isa case.  I suspect that there is a problem with resources
> getting merged (can the irq resource be supplied by acpi even when it is
> intentionally left out of the hints?).  I avoid these problems by not
> using acpi.

It still finds it on irq 10 with the following hint!:
hint.sio.2.at="isa"
hint.sio.2.disabled="1"
hint.sio.2.port="0x3E8"
hint.sio.2.irq="5"

Leaving out the irq hint changes nothing.  I've stopped statically
compiling in the hints.  device.hints should be in /boot, right?
(Just eliminating the imbecile factor.)

Without ACPI it finds ed0 (great) and no sio2 (even better), but I
now get these messages:

unknown:  can't assign resources (port)
unknown:  can't assign resources (port)
unknown:  can't assign resources (port)
unknown:  can't assign resources (port)
unknown:  can't assign resources (port)
unknown:  can't assign resources (port)

Someone has asked about these before.  Terry suggested that turning
PnP OS on in the BIOS will make it go away.  It has always been on
in my BIOS and loading ACPI made them go away.  Perhaps the ACPI
code just doesn't warn in the same way, but the situation still
exists.  Someone else said they were harmless - the system still
works OK.  I just don't like the look of these messages.  Is it
possible to make them go away?

Is there not a way to tell ACPI to stay off the acid? :)
options ACPI_NO_HALLUCINOGENS
(No offence to the people who've done great work on it so far)

Ian

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

Re: 80386 out of GENERIC

[Ruslan Ermilov]

On Wed, Dec 18, 2002 at 03:33:42PM +1100, Bruce Evans wrote:
> On Tue, 17 Dec 2002, Ruslan Ermilov wrote:
> 
> > On Mon, Dec 16, 2002 at 09:05:40AM +1030, Greg 'groggy' Lehey wrote:
> > > I suppose it would be a good idea to include an alternatvie i386
> > > kernel on the CD-ROM.  There may be a space issue, of course.  How
> > > many people participating in this thread have an i386 with at least 12
> > > MB of memory and intended to try 5.0 on it?  How many of those don't
> > > have a machine to bootstrap off?
> > >
> > Having only alternative i386 kernel is not enough while userland
> > stuff is still compiled for i486.
> 
> Er, userland stuff is still compiled for original i386's, modulo bugs.
> E.g., in the i386 endian.h:
> 
> % #if defined(_KERNEL) && (defined(I486_CPU) || defined(I586_CPU) || 
>defined(I686_CPU)) && !defined(I386_CPU)
>   ^^^
> %
> % #define __byte_swap_int(x) \
> % __extension__ ({ register __uint32_t __X = (x); \
> %__asm ("bswap %0" : "+r" (__X)); \
> %__X; })
> % #else
> %
> % #define __byte_swap_int(x) \
> % __extension__ ({ register __uint32_t __X = (x); \
> %__asm ("xchgb %h0, %b0\n\trorl $16, %0\n\txchgb %h0, %b0" \
> % : "+q" (__X)); \
> %__X; })
> % #endif
> 
> The _KERNEL part of the ifdef limits the use of the i486 "bswap"
> instruction to the kernel, so userland is properly pessimized to support
> all x86's.  The other parts of the ifdef properly pessimize modules to
> support all x86's (options don't apply to modules so none of the XXX_CPU's
> is defined).
> 
> So kernels get the full epsilon of optimizations from turning off i386
> support, while userland doesn't get any (not counting ones from optimizing
> for non-i386 without breaking i386).
> 
Right.  I forgot for the moment that -mcpu isn't the same as -march,
and the latter is only set if CPUTYPE is also set.


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



msg48985/pgp0.pgp
Description: PGP signature

sparc64 tinderbox failure

[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/gbde
cc1: warnings being treated as errors
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c: In function 
`rijndaelKeySched':
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:41: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:41: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:48: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:48: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:66: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:66: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:70: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:70: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:77: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:77: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:83: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:83: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c: In function 
`rijndaelKeyEncToDec':
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:101: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:102: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:103: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:104: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:105: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:108: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:109: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:110: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:111: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:112: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:115: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:116: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:117: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:118: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:119: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:122: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:123: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/

Re: panic: ffs_blkfree: freeing free block

[Aurelien Nephtali]

> I introduced a bug to snapshots on 11/30/02 which did not get fixed 
> until 12/15/02 which caused background fsck to (silently) fail to fix
> certain filesystem problems. If you ran background fsck on a system
> between 11/30 and 12/15 and then ran background fsck again on a system
> after that date, the earlier missed corruption causes the panic that
> you have seen. Once fixed on a post 12/15 system, it should not recur.
> You can avoid the panic by running `fsck -f -p' on all your system
> after upgrading to a post 12/15 system. If you find continued
> evidence of trouble after following the above procedures, please
> send me mail.
> 
>   Kirk McKusick

I rebuild a brand new system and the problem is still here :/.

uname -a:
FreeBSD nebula.wanadoo.fr 5.0-CURRENT FreeBSD 5.0-CURRENT #0: Wed Dec 18 10:45:3
0 CET 2002 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/NEBULA  i386

I've also attached a new dump which matches to the new system.

-- Aurelien

Script started on Wed Dec 18 11:36:02 2002

nebula# /var/crashggdb -k

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".
(kgdb) symbol-file kernel.debug.7 
Reading symbols from kernel.debug.7...done.
(kgdb) exec-file kernel.7
(kgdb) core-file vmcore.7 
panic: from debugger
panic messages:
---
panic: ffs_blkfree: freeing free block
panic: from debugger
Uptime: 50s
Dumping 123 MB
ata0: resetting devices ..
done
 16 32 48 64 80 96 112
---
#0  doadump () at /usr/src/sys/kern/kern_shutdown.c:232
232 dumping++;
(kgdb) bt
#0  doadump () at /usr/src/sys/kern/kern_shutdown.c:232
#1  0xc021c37e in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:364
#2  0xc021c5c3 in panic () at /usr/src/sys/kern/kern_shutdown.c:517
#3  0xc013c212 in db_panic () at /usr/src/sys/ddb/db_command.c:450
#4  0xc013c192 in db_command (last_cmdp=0xc03a0a00, cmd_table=0x0, 
aux_cmd_tablep=0xc039b53c, aux_cmd_tablep_end=0xc039b540)
at /usr/src/sys/ddb/db_command.c:346
#5  0xc013c2a6 in db_command_loop () at /usr/src/sys/ddb/db_command.c:472
#6  0xc013ef9a in db_trap (type=3, code=0) at /usr/src/sys/ddb/db_trap.c:72
#7  0xc0335d42 in kdb_trap (type=3, code=0, regs=0xc850da4c)
at /usr/src/sys/i386/i386/db_interface.c:166
#8  0xc0346b2f in trap (frame=
  {tf_fs = 24, tf_es = 16, tf_ds = 16, tf_edi = -1061658176, tf_esi = 256, tf_ebp 
= -934225256, tf_isp = -934225288, tf_ebx = 0, tf_edx = 0, tf_ecx = -1069390144, 
tf_eax = 18, tf_trapno = 3, tf_err = 0, tf_eip = -1070374940, tf_cs = 8, tf_eflags = 
646, tf_esp = -1069984152, tf_ss = -1070066283})
at /usr/src/sys/i386/i386/trap.c:603
#9  0xc0337558 in calltrap () at {standard input}:98
#10 0xc021c5ab in panic (fmt=0x0) at /usr/src/sys/kern/kern_shutdown.c:503
#11 0xc02d8f0a in ffs_blkfree (fs=0xc18f3000, devvp=0xc191dce4, bno=1088, 
size=16384, inum=1088) at /usr/src/sys/ufs/ffs/ffs_alloc.c:1771
#12 0xc02e843f in indir_trunc (freeblks=0xc1b37500, dbn=4288, level=0, lbn=12, 
countp=0xc850dc10) at /usr/src/sys/ufs/ffs/ffs_softdep.c:2600
#13 0xc02e7ee5 in handle_workitem_freeblocks (freeblks=0xc1b37500, flags=0)
---Type  to continue, or q  to quit---
at /usr/src/sys/ufs/ffs/ffs_softdep.c:2466
#14 0xc02e510a in process_worklist_item (matchmnt=0x0, flags=0)
at /usr/src/sys/ufs/ffs/ffs_softdep.c:742
#15 0xc02e4e50 in softdep_process_worklist (matchmnt=0x0)
at /usr/src/sys/ufs/ffs/ffs_softdep.c:621
#16 0xc026f89e in sched_sync () at /usr/src/sys/kern/vfs_subr.c:1751
#17 0xc0208c64 in fork_exit (callout=0xc026f5b0 , arg=0x0, 
frame=0x0) at /usr/src/sys/kern/kern_fork.c:872
(kgdb) quit

nebula# /var/crasheexit


Script done on Wed Dec 18 11:36:32 2002




msg48987/pgp0.pgp
Description: PGP signature

ia64 tinderbox failure

[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/gbde
cc1: warnings being treated as errors
/home/tinderbox/ia64/src/sys/crypto/rijndael/rijndael-alg-fst.c: In function 
`rijndaelKeySched':
/home/tinderbox/ia64/src/sys/crypto/rijndael/rijndael-alg-fst.c:41: warning: cast 
increases required alignment of target type
/home/tinderbox/ia64/src/sys/crypto/rijndael/rijndael-alg-fst.c:41: warning: cast 
increases required alignment of target type
/home/tinderbox/ia64/src/sys/crypto/rijndael/rijndael-alg-fst.c:48: warning: cast 
increases required alignment of target type
/home/tinderbox/ia64/src/sys/crypto/rijndael/rijndael-alg-fst.c:48: warning: cast 
increases required alignment of target type
/home/tinderbox/ia64/src/sys/crypto/rijndael/rijndael-alg-fst.c:66: warning: cast 
increases required alignment of target type
/home/tinderbox/ia64/src/sys/crypto/rijndael/rijndael-alg-fst.c:66: warning: cast 
increases required alignment of target type
/home/tinderbox/ia64/src/sys/crypto/rijndael/rijndael-alg-fst.c:70: warning: cast 
increases required alignment of target type
/home/tinderbox/ia64/src/sys/crypto/rijndael/rijndael-alg-fst.c:70: warning: cast 
increases required alignment of target type
/home/tinderbox/ia64/src/sys/crypto/rijndael/rijndael-alg-fst.c:77: warning: cast 
increases required alignment of target type
/home/tinderbox/ia64/src/sys/crypto/rijndael/rijndael-alg-fst.c:77: warning: cast 
increases required alignment of target type
/home/tinderbox/ia64/src/sys/crypto/rijndael/rijndael-alg-fst.c:83: warning: cast 
increases required alignment of target type
/home/tinderbox/ia64/src/sys/crypto/rijndael/rijndael-alg-fst.c:83: warning: cast 
increases required alignment of target type
/home/tinderbox/ia64/src/sys/crypto/rijndael/rijndael-alg-fst.c: In function 
`rijndaelKeyEncToDec':
/home/tinderbox/ia64/src/sys/crypto/rijndael/rijndael-alg-fst.c:101: warning: cast 
increases required alignment of target type
/home/tinderbox/ia64/src/sys/crypto/rijndael/rijndael-alg-fst.c:102: warning: cast 
increases required alignment of target type
/home/tinderbox/ia64/src/sys/crypto/rijndael/rijndael-alg-fst.c:103: warning: cast 
increases required alignment of target type
/home/tinderbox/ia64/src/sys/crypto/rijndael/rijndael-alg-fst.c:104: warning: cast 
increases required alignment of target type
/home/tinderbox/ia64/src/sys/crypto/rijndael/rijndael-alg-fst.c:105: warning: cast 
increases required alignment of target type
/home/tinderbox/ia64/src/sys/crypto/rijndael/rijndael-alg-fst.c:108: warning: cast 
increases required alignment of target type
/home/tinderbox/ia64/src/sys/crypto/rijndael/rijndael-alg-fst.c:109: warning: cast 
increases required alignment of target type
/home/tinderbox/ia64/src/sys/crypto/rijndael/rijndael-alg-fst.c:110: warning: cast 
increases required alignment of target type
/home/tinderbox/ia64/src/sys/crypto/rijndael/rijndael-alg-fst.c:111: warning: cast 
increases required alignment of target type
/home/tinderbox/ia64/src/sys/crypto/rijndael/rijndael-alg-fst.c:112: warning: cast 
increases required alignment of target type
/home/tinderbox/ia64/src/sys/crypto/rijndael/rijndael-alg-fst.c:115: warning: cast 
increases required alignment of target type
/home/tinderbox/ia64/src/sys/crypto/rijndael/rijndael-alg-fst.c:116: warning: cast 
increases required alignment of target type
/home/tinderbox/ia64/src/sys/crypto/rijndael/rijndael-alg-fst.c:117: warning: cast 
increases required alignment of target type
/home/tinderbox/ia64/src/sys/crypto/rijndael/rijndael-alg-fst.c:118: warning: cast 
increases required alignment of target type
/home/tinderbox/ia64/src/sys/crypto/rijndael/rijndael-alg-fst.c:119: warning: cast 
increases required alignment of target type
/home/tinderbox/ia64/src/sys/crypto/rijndael/rijndael-alg-fst.c:122: warning: cast 
increases required alignment of target type
/home/tinderbox/ia64/src/sys/crypto/rijndael/rijndael-alg-fst.c:123: warning: cast 
increase

Re: I'm leaving the project

[Matt Dillon]

On Tue, 17 Dec 2002 10:56:19 -0800


Does anyone know why this person is trying to (poorly) 
impersonate MD?

Unfortunately not. We do not yet know who this fake Dillon 
is (the guy posting from that backplane.com address)

I've been working hard on the new ipfw[2] patch for 5.0, 
the new patch is released under the DPL. For those of you 
not familiar with it, here's the most important paragraph:

The de Raadt Public License 1.0

Redistribution and use in source and binary forms, with or 
without modification, are permitted provided that the 
following conditions are met:

* Redistributions of source code must retain the 
above copyright notice,
this list of conditions and the following 
disclaimer. 
* Redistributions in binary form must reproduce 
the above copyright notice,
this list of conditions and the following 
disclaimer in the documentation 
and/or other materials provided with the 
distribution. 
* FUCK YOU ALL ASSHOLES!

Take care,
  Matthew Dillon


_
For the best comics, toys, movies, and more,
please visit 


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

Re: 80386 out of GENERIC

[David Cuthbert]

Leif Neland wrote:

But still, would it be impossible to have both a GENERIC and a GENERIC386
kernel in the distribution?


Impossible, no... but would anyone use it?  Seems to me that it would 
just take up space.  And it's one more thing for the build gurus to keep 
a configuration for (though maybe they don't mind/care?).

As long as someone can build a 386 kernel by throwing a few flags...




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

sparc64 tinderbox failure

[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/gbde
cc1: warnings being treated as errors
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c: In function 
`rijndaelKeySched':
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:41: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:41: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:48: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:48: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:66: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:66: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:70: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:70: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:77: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:77: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:83: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:83: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c: In function 
`rijndaelKeyEncToDec':
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:101: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:102: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:103: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:104: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:105: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:108: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:109: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:110: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:111: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:112: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:115: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:116: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:117: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:118: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:119: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:122: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:123: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/

FreeBSD 5.0 (RC1) slow down

[van den Berg, Courteney]

Hi,

Has anyone here seen slow down problems when running RC1 as a guest OS
on Vmware (GSX or Workstation)? After about 2 minutes of normal running
the VM slows to an absolute crawl. On the host the processor sits at
100% with almost 100% of it kernel time. The exact amount of time
required to slow the vm down seems to depend on the amount of activity
inside the VM. It's difficult to really measure though.

The most bizzare thing is the work around that I accidentally
discovered. If I turn off acceleration (or on, it doesn't make any
difference which) in the Vmware configuration panel then the VM comes
back to life. A minute or two later though and it slows down again. So,
as long as I sit here toggling acceleration on and off everything runs
smoothly.

Anyone know a tweek or workaround for this?

I've tried XP and W2k as hosts and VMware Workstation 3.2 and GSX 2.0.1
with the same luck. 4.7-STABLE does not have this problem.

CJ

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

Re: FreeBSD 5.0 (RC1) slow down

[Vladimir B.]

÷ Wed, 18.12.2002, × 18:17, van den Berg, Courteney ÎÁÐÉÓÁÌ:

> Has anyone here seen slow down problems when running RC1 as a guest OS
> on Vmware (GSX or Workstation)? After about 2 minutes of normal running
> the VM slows to an absolute crawl. On the host the processor sits at
> 100% with almost 100% of it kernel time. The exact amount of time
> required to slow the vm down seems to depend on the amount of activity
> inside the VM. It's difficult to really measure though.
> 
> The most bizzare thing is the work around that I accidentally
> discovered. If I turn off acceleration (or on, it doesn't make any
> difference which) in the Vmware configuration panel then the VM comes
> back to life. A minute or two later though and it slows down again. So,
> as long as I sit here toggling acceleration on and off everything runs
> smoothly.
> 
> Anyone know a tweek or workaround for this?

options CPU_DISABLE_CMPXCHG

May be this will help ?

> CJ

-- 
Vladimir B. Grebenschikov <[EMAIL PROTECTED]>
TSB "Russian Express"

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

/usr/libexec/ld-elf.so.1 not installed by cd /usr/src;make install

[Julian Stacey]

With  5.0-RC1 /usr/libexec/ld-elf.so.1 is not installed by `cd
/usr/src;make install` the date stamp remains old.
(Most other stuff is installed, except kerberos & _p.a libs etc)

Presumably make world will update it (running now),
but it shouldn't need a `world' just an `install' IMO.

Julian Stacey   
jhs @ berklix.com   Computer Systems Engineer, Unix & Net Consultant, Munich.
  Ihr Rauchen => mein allergischer Kopfschmerz !  Schnupftabak probieren.
  Munich BSD Conference:http://berklix.org/conf/
  Spam phrases triggering deletion: http://berklix.com/jhs/mail/

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

Re: panic: ffs_blkfree: freeing free block

[Kirk McKusick]

I corrected a botched patch last night. Make sure that you are running
with version 1.56 2002/12/18 07:19:41 of ufs/ffs/ffs_snapshot.c.

Kirk McKusick

=-=-=-=-=

Date: Wed, 18 Dec 2002 11:43:25 +0100
From: Aurelien Nephtali <[EMAIL PROTECTED]>
To: Kirk McKusick <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED]
Subject: Re: panic: ffs_blkfree: freeing free block
X-ASK-Info: Confirmed by User

> I introduced a bug to snapshots on 11/30/02 which did not get fixed=20
> until 12/15/02 which caused background fsck to (silently) fail to fix
> certain filesystem problems. If you ran background fsck on a system
> between 11/30 and 12/15 and then ran background fsck again on a system
> after that date, the earlier missed corruption causes the panic that
> you have seen. Once fixed on a post 12/15 system, it should not recur.
> You can avoid the panic by running `fsck -f -p' on all your system
> after upgrading to a post 12/15 system. If you find continued
> evidence of trouble after following the above procedures, please
> send me mail.
>
>   Kirk McKusick

I rebuild a brand new system and the problem is still here :/.

uname -a:
FreeBSD nebula.wanadoo.fr 5.0-CURRENT FreeBSD 5.0-CURRENT #0: Wed Dec 18 10:45:30 CET 
2002 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/NEBULA  i386

I've also attached a new dump which matches to the new system.

-- Aurelien

--LQksG6bCIzRHxTLp
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename=dump
Content-Transfer-Encoding: quoted-printable

Script started on Wed Dec 18 11:36:02 2002
=0D=1B[m=1B[27m=1B[Jnebula# =1B[K=1B[61C/var/crash=1B[71Dg=08gdb -k=0D=0D
GNU gdb 5.2.1 (FreeBSD)=0D
Copyright 2002 Free Software Foundation, Inc.=0D
GDB is free software, covered by the GNU General Public License, and you ar=
e=0D
welcome to change it and/or distribute copies of it under certain condition=
s.=0D
Type "show copying" to see the conditions.=0D
There is absolutely no warranty for GDB.  Type "show warranty" for details.=
=0D
This GDB was configured as "i386-undermydesk-freebsd".=0D
(kgdb) symbol-file kernel.debug.7 =0D
Reading symbols from kernel.debug.7...done.=0D
(kgdb) exec-file kernel.7=0D
(kgdb) core-file vmcore.7 =0D
panic: from debugger=0D
panic messages:=0D
---=0D
panic: ffs_blkfree: freeing free block=0D
panic: from debugger=0D
Uptime: 50s=0D
Dumping 123 MB=0D
ata0: resetting devices ..=0D
done=0D
 16 32 48 64 80 96 112=0D
---=0D
#0  doadump () at /usr/src/sys/kern/kern_shutdown.c:232=0D
232 dumping++;=0D
(kgdb) bt=0D
#0  doadump () at /usr/src/sys/kern/kern_shutdown.c:232=0D
#1  0xc021c37e in boot (howto=3D260) at /usr/src/sys/kern/kern_shutdown.c:3=
64=0D
#2  0xc021c5c3 in panic () at /usr/src/sys/kern/kern_shutdown.c:517=0D
#3  0xc013c212 in db_panic () at /usr/src/sys/ddb/db_command.c:450=0D
#4  0xc013c192 in db_command (last_cmdp=3D0xc03a0a00, cmd_table=3D0x0, =0D
aux_cmd_tablep=3D0xc039b53c, aux_cmd_tablep_end=3D0xc039b540)=0D
at /usr/src/sys/ddb/db_command.c:346=0D
#5  0xc013c2a6 in db_command_loop () at /usr/src/sys/ddb/db_command.c:472=0D
#6  0xc013ef9a in db_trap (type=3D3, code=3D0) at /usr/src/sys/ddb/db_trap.=
c:72=0D
#7  0xc0335d42 in kdb_trap (type=3D3, code=3D0, regs=3D0xc850da4c)=0D
at /usr/src/sys/i386/i386/db_interface.c:166=0D
#8  0xc0346b2f in trap (frame=3D=0D
  {tf_fs =3D 24, tf_es =3D 16, tf_ds =3D 16, tf_edi =3D -1061658176, tf=
_esi =3D 256, tf_ebp =3D -934225256, tf_isp =3D -934225288, tf_ebx =3D 0, t=
f_edx =3D 0, tf_ecx =3D -1069390144, tf_eax =3D 18, tf_trapno =3D 3, tf_err=
 =3D 0, tf_eip =3D -1070374940, tf_cs =3D 8, tf_eflags =3D 646, tf_esp =3D =
-1069984152, tf_ss =3D -1070066283})=0D
at /usr/src/sys/i386/i386/trap.c:603=0D
#9  0xc0337558 in calltrap () at {standard input}:98=0D
#10 0xc021c5ab in panic (fmt=3D0x0) at /usr/src/sys/kern/kern_shutdown.c:50=
3=0D
#11 0xc02d8f0a in ffs_blkfree (fs=3D0xc18f3000, devvp=3D0xc191dce4, bno=3D1=
088, =0D
size=3D16384, inum=3D1088) at /usr/src/sys/ufs/ffs/ffs_alloc.c:1771=0D
#12 0xc02e843f in indir_trunc (freeblks=3D0xc1b37500, dbn=3D4288, level=3D0=
, lbn=3D12, =0D
countp=3D0xc850dc10) at /usr/src/sys/ufs/ffs/ffs_softdep.c:2600=0D
#13 0xc02e7ee5 in handle_workitem_freeblocks (freeblks=3D0xc1b37500, flags=
=3D0)=0D
---Type  to continue, or q  to quit---=0D
at /usr/src/sys/ufs/ffs/ffs_softdep.c:2466=0D
#14 0xc02e510a in process_worklist_item (matchmnt=3D0x0, flags=3D0)=0D
at /usr/src/sys/ufs/ffs/ffs_softdep.c:742=0D
#15 0xc02e4e50 in softdep_process_worklist (matchmnt=3D0x0)=0D
at /usr/src/sys/ufs/ffs/ffs_softdep.c:621=0D
#16 0xc026f89e in sched_sync () at /usr/src/sys/kern/vfs_subr.c:1751=0D
#17 0xc0208c64 in fork_exit (callout=3D0xc026f5b0 , arg=3D0x0, =
=0D
frame=3D0x0) at /usr/src/sys/kern/kern_fork.c:872=0D
(kgdb) quit=0D
=0D=1B[m=1B[27m=1B[Jnebula# =1B[K=1B[61C/var/crash=1B[71De=08exit=0D=0D

Script done on Wed Dec 18 11:36:32 2002
=0D

--LQksG6bCIzRHxTLp--

--BwCQnh7xodEAoBMC
Content-Type: application/pgp-signature

Re: panic: ffs_blkfree: freeing free block

[Aurelien Nephtali]

On Wed, Dec 18, 2002 at 08:00:19AM -0800, Kirk McKusick wrote:
> I corrected a botched patch last night. Make sure that you are running
> with version 1.56 2002/12/18 07:19:41 of ufs/ffs/ffs_snapshot.c.
> 
>   Kirk McKusick
> 
> =-=-=-=-=
> 

nebula# ident /usr/src/sys/ufs/ffs/ffs_snapshot.c
/usr/src/sys/ufs/ffs/ffs_snapshot.c:
 $FreeBSD: src/sys/ufs/ffs/ffs_snapshot.c,v 1.56 2002/12/18 07:19:41 mckusic
 k Exp $

:/

-- Aurelien



msg48996/pgp0.pgp
Description: PGP signature

Re: /usr/libexec/ld-elf.so.1 not installed by cd /usr/src;make install

[Dimitry Andric]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 2002-12-18 at 16:35:24 Julian Stacey wrote:

JS> With  5.0-RC1 /usr/libexec/ld-elf.so.1 is not installed by `cd
JS> /usr/src;make install` the date stamp remains old.

Yes it is, but it isn't modified if the freshly compiled file is
exactly the same as the currently existing file. Please check out
/usr/src/libexec/rtld-elf/Makefile, where you can see that it is
installed with flags "-fschg -C -b" to install(1).

The same thing is done for the a.out dynamic loader.

Btw, you should probably use "make installworld" instead of "make
install". :-)

Cheers,
- --
Dimitry Andric <[EMAIL PROTECTED]>
PGP Key: http://www.xs4all.nl/~dim/dim.asc
Fingerprint: 7AB462D2CE35FC6D42394FCDB05EA30A2E2096A3
Lbh ner abj va ivbyngvba bs gur QZPN

-BEGIN PGP SIGNATURE-
Version: 6.5.8ckt http://www.ipgpp.com/
Comment: http://duncan.gn.apc.org/stoa_cover.htm

iQA/AwUBPgCTjrBeowouIJajEQKd9ACeL+LiZfz8/rbGd9znUgO5Yxwh7cIAn0fa
9AGnFb1oFAr651OpWFUCtTuZ
=OH6G
-END PGP SIGNATURE-


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

ia64 tinderbox failure

[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
--
===> sys/boot/efi/loader
"/home/tinderbox/ia64/src/share/mk/bsd.prog.mk", line 37: warning: duplicate script 
for target "loader.efi" ignored
/home/tinderbox/ia64/src/sys/boot/efi/loader/main.c:39:27: machine/dig64.h: No such 
file or directory
mkdep: compile failed
*** Error code 1

Stop in /home/tinderbox/ia64/src/sys/boot/efi/loader.
*** Error code 1

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

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

Stop in /home/tinderbox/ia64/src/sys.
*** 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: 80386 out of GENERIC

[John Baldwin]

On 18-Dec-2002 Terry Lambert wrote:
> John Baldwin wrote:
>> This has nothing to do with /dev/random.  Please stop with the constant
>> FUDing Terry.
> 
>| Revision 1.296 / (download) - annotate - [select for diffs], Sun Jan 14
>| 10:11:10 2001 UTC (23 months ago) by jhb 
>| Branch: MAIN 
>| Changes since 1.295: +2 -2 lines
>| Diff to previous 1.295 (colored) 
>| 
>| Remove I386_CPU from GENERIC.  Support for the 386 seriously pessimizes
>| performance on other x86 processors.  Custom kernels can still be built
>| that will run on the 386.
> 
> The pessimization that was being discussed right before that happened
> was "harvesting entropy for /dev/random".  I can provide mailing list
> quotes about that bracketing those dates.

No, the pessimization is:

#if defined(I386_CPU) || defined(CPU_DISABLE_CMPXCHG)

static __inline int
atomic_cmpset_int(volatile u_int *dst, u_int exp, u_int src)
{
int res = exp;

__asm __volatile(
"   pushfl ;"
"   cli ;   "
"   cmpl%0,%2 ; "
"   jne 1f ;"
"   movl%1,%2 ; "
"1: "
"   sete%%al;   "
"   movzbl  %%al,%0 ;   "
"   popfl ; "
"# atomic_cmpset_int"
: "+a" (res)/* 0 (result) */
: "r" (src),/* 1 */
  "m" (*(dst))  /* 2 */
: "memory");

return (res);
}

#else /* defined(I386_CPU) */

static __inline int
atomic_cmpset_int(volatile u_int *dst, u_int exp, u_int src)
{
int res = exp;

__asm __volatile (
"   " __XSTRING(MPLOCKED) " "
"   cmpxchgl %1,%2 ;"
"   setz%%al ;  "
"   movzbl  %%al,%0 ;   "
"1: "
"# atomic_cmpset_int"
: "+a" (res)/* 0 (result) */
: "r" (src),/* 1 */
  "m" (*(dst))  /* 2 */
: "memory");

return (res);
}

#endif /* defined(I386_CPU) */

> Was there a particular pessimization other than /dev/random that you
> were thinking of when you made the commit comment?

Yes, the one above.  It came in as part of SMPng.

-- 

John Baldwin <[EMAIL PROTECTED]>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/

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

Re: panic: ffs_blkfree: freeing free block

[Aurelien Nephtali]

> 
> By hard shutdown I assume you mean hitting the reset button while
> the machine is busily running along? If so, my test machine passes
> that test. I'll keep plugging away at it though in the hopes of
> getting it to fail.
> 
>   Kirk McKusick

Yes, that's what I meant. My main box is a laptop so it only has a button to
power it on or off but I think reset or shutdown leads to the same result.

-- Aurelien



msg49000/pgp0.pgp
Description: PGP signature

Re: ARLA 0.35.11 on FreeBSD 5.0-RC1

[Love]

Garance A Drosihn <[EMAIL PROTECTED]> writes:

> At 4:15 PM +0100 12/15/02, Petr Holub wrote:
>>Hi,
>>
>>I tried to compile arla 0.35.11 on FreeBSD 5.0-RC1. First I got
>>following error:
[...]
>>Then configre and make proceeds until it stops on error shown
>>below my signature. Can anybody help?
>
> I believe arla needs to have some effort put into it to get it
> working on -current.

Some effort was put into it.

Known problem on fbsd5.0RC1 is that arla uses the pioctl syscall (339) but
the built in libkafs in freebsd uses 210 (lkmsys), set AFS_SYSCALL=339 in
your enviroment (including arlad's).

ftp://ftp.stacken.kth.se/pub/arla/snap/arla-0.36pre5.tar.gz

MD5 (arla-0.36pre5.tar.gz) = 48a9955df0e69fac5a323a48b29aec66

(untested) binaries releases for random platforms might be found in

ftp://ftp.stacken.kth.se/pub/arla/binaries/0.36pre5

Feedback is appreciated.

Love

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

Re: sio and ed woes

[Mark Murray]

> sio0 port 0x3f8-0x3ff irq 4 on acpi0
> sio0: type 16550A
> sio1 port 0x2f8-0x2ff irq 3 on acpi0
> sio1: type 16550A
> sio2: configured irq 10 not in bitmap of probed irqs 0
> sio2: port may not be enabled
> sio2 port 0x2e8-0x2ef irq 10 on acpi0
> sio2: type 16550A
> 
> I've tried setting hint.sio.2.disabled=1.  I've tried leaving it
> out.  I can't not have sio because this server is my router and is
> permanently connected to a modem.

Can you disable the integrated devices on the motherboard using the
BIOS?

> The SMC Ultra card exists on 0x280 irq 10 0xd8000.  Has current
> dropped ISA support (which was hinted at in the GENERIC/80386 thread)?

Sort of. ISA is on its way out and ACPI/PnP is taking over. You
sometimes need to go to great lengths to prevent devices from being
found. The abomination called ISA/PnP is sometimes a nuisance.

M
--
Mark Murray
iumop ap!sdn w,I idlaH

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

Re: /usr/libexec/ld-elf.so.1 not installed by cd /usr/src;make install

[Julian H. Stacey]

Dimitry Andric wrote:
> On 2002-12-18 at 16:35:24 Julian Stacey wrote:
> 
> JS> With  5.0-RC1 /usr/libexec/ld-elf.so.1 is not installed by `cd
> JS> /usr/src;make install` the date stamp remains old.
> 
> Yes it is, but it isn't modified if the freshly compiled file is
> exactly the same as the currently existing file. Please check out
> /usr/src/libexec/rtld-elf/Makefile, where you can see that it is
> installed with flags "-fschg -C -b" to install(1).

Thanks !  Sorry for my bad report, I did a (too quick) look with
`cd /usr/src ; find . -name rtld` but failed to seek rtld\*


> The same thing is done for the a.out dynamic loader.

/usr/src/libexec/rtld-aout/Makefile:
INSTALLFLAGS= -fschg -C # -C to install as atomically as possible

Does FreeBSD need to preserve the date 
( like ar r libc.a & ranlib scenarios of old) ?
or is this `atomically as possible' avoidance of date change, just a hope
that it'll be done quicker ?  in which case should we add a subsequent
touch /usr/libexec/ld-elf.so.1
so that the target directory doesn't look suspiciously un-updated ?


> Btw, you should probably use "make installworld" instead of "make
> install". :-)

Yes I suppose so after any current src/ updates,
But mine is a virginal unchanged "binaries match sources"
system, fresh from 5.0-RC1-i386-disc1.iso.  I just did a
simple install to ensure nothing else was still missing,
after a repair of hard disk libs from 5.0-RC1-i386-disc2.iso 
& then checked bin & lib dates looked OK.
BTW World started when I sent last mail.

Julian Stacey
jhs @ berklix.com   Computer Systems Engineer, Unix & Net Consultant, Munich.
  Ihr Rauchen => mein allergischer Kopfschmerz !  Schnupftabak probieren.
  Munich BSD Conference:http://berklix.org/conf/
  Spam phrases triggering deletion: http://berklix.com/jhs/mail/

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

Re: swapoff code comitted.

[Eirik Nygaard]

On Sun, Dec 15, 2002 at 02:47:51PM -0800, Matthew Dillon wrote:
> :
> :How about renaming swapon(8) into swapctl(8) after this function
> enhancemen=
> :t? 
> :This name reflects it's purpose much better and would be consistent
> with the 
> :other BSDs.
> :
> :- Christian
>
> I am not volunteering to do this, at least not right now.  I
> have too
> big a stack of things that still need to be committed, but if
> someone
> else would like to tackle this I think it would be a nice little
> project
> for a developer with some free time to waste and I would be
> happy to
> review and test the work.
>

I have made a small patch, added l, s and h switches to show
information about the swap devices. And the U switch to swapctl only
to remove all activated swap devices.
If anything else is needed let me know and I will add it.

-- 

Eirik Nygaard <[EMAIL PROTECTED]>
PGP Key: 83C55EDE


Index: sbin/swapon/Makefile
===
RCS file: /home/ncvs/src/sbin/swapon/Makefile,v
retrieving revision 1.7
diff -u -r1.7 Makefile
--- sbin/swapon/Makefile15 Dec 2002 19:17:56 -  1.7
+++ sbin/swapon/Makefile17 Dec 2002 17:00:47 -
@@ -3,7 +3,9 @@
 
 PROG=  swapon
 MAN=   swapon.8
-LINKS= ${BINDIR}/swapon ${BINDIR}/swapoff
+LINKS= ${BINDIR}/swapoff ${BINDIR}/swapon
+LINKS+=${BINDIR}/swapctl ${BINDIR}/swapon
 MLINKS=swapon.8 swapoff.8
+LDADD=   -lc -lkvm
 
 .include 
Index: sbin/swapon/swapon.c
===
RCS file: /home/ncvs/src/sbin/swapon/swapon.c,v
retrieving revision 1.13
diff -u -r1.13 swapon.c
--- sbin/swapon/swapon.c15 Dec 2002 19:17:56 -  1.13
+++ sbin/swapon/swapon.c17 Dec 2002 17:00:47 -
@@ -52,10 +52,17 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
-static void usage(const char *);
+#define MAXSWAP 100
+
+static void usage(void);
 static int is_swapoff(const char *);
+static int is_swapon(const char *);
+static int is_swapctl(const char *);
 intswap_on_off(char *name, int ignoreebusy, int do_swapoff);
+void   swaplist(int, int, int);
 
 int
 main(int argc, char **argv)
@@ -63,41 +70,68 @@
struct fstab *fsp;
int stat;
int ch, doall;
-   int do_swapoff;
-   char *pname = argv[0];
-
-   do_swapoff = is_swapoff(pname);
-
+   int do_swapoff, do_swapon;
+   int sflag = 0, lflag = 0, hflag = 0;
+   
+   do_swapoff = is_swapoff(getprogname());
+   do_swapon  = is_swapon(getprogname());
+   
doall = 0;
-   while ((ch = getopt(argc, argv, "a")) != -1)
-   switch((char)ch) {
+   while ((ch = getopt(argc, argv, "alhsU")) != -1)
+   switch(ch) {
case 'a':
doall = 1;
break;
+   case 's':
+   sflag = 1;
+   break;
+   case 'l':
+   lflag = 1;
+   break;
+   case 'h':
+   hflag = 1;
+   break;
+   case 'U':
+   if (!do_swapon) {
+   doall = 1;
+   do_swapoff = 1;
+   break;
+   } /* Remove the if if you want the U switch to work with 
+swapon also, don't know if that is wanted */
case '?':
default:
-   usage(pname);
+   usage();
}
argv += optind;
-
+   
stat = 0;
-   if (doall)
-   while ((fsp = getfsent()) != NULL) {
-   if (strcmp(fsp->fs_type, FSTAB_SW))
-   continue;
-   if (strstr(fsp->fs_mntops, "noauto"))
-   continue;
-   if (swap_on_off(fsp->fs_spec, 1, do_swapoff))
-   stat = 1;
-   else
-   printf("%s: %sing %s as swap device\n",
-   pname, do_swapoff ? "remov" : "add",
-   fsp->fs_spec);
+   if (do_swapoff || do_swapon) {
+   if (doall) {
+   while ((fsp = getfsent()) != NULL) {
+   if (strcmp(fsp->fs_type, FSTAB_SW))
+   continue;
+   if (strstr(fsp->fs_mntops, "noauto"))
+   continue;
+   if (swap_on_off(fsp->fs_spec, 1, do_swapoff))
+   stat = 1;
+   else
+   printf("%s: %sing %s as swap device\n",
+   getprogname(), do_swapoff ? "remov" : 

Unwanted Spam 'Re: I'm leaving the project'

[Matthew Dillon]

You know, whoever you are, you must lead a very sad, paranoid,
sit-in-the-corner-the-world-is-out-to-get-me life if you think you
are actually accomplishing something here.  You are probably the
same idiot who posts all that anonymous-coward BSD-Is-Dying junk
to Slashdot.  I wouldn't be surprised at all.

-Matt
Matthew Dillon 
<[EMAIL PROTECTED]>

:...
:Received: from gator.darkhorse.com (mail.darkhorse.com [209.95.33.140])
:   by mx1.FreeBSD.org (Postfix) with ESMTP
:   id E942D43ED1; Wed, 18 Dec 2002 03:50:50 -0800 (PST)
:   (envelope-from [EMAIL PROTECTED])
:Received: from [63.242.157.226] (account <[EMAIL PROTECTED]>)
:  by gator.darkhorse.com (CommuniGate Pro WebUser 3.5.9)
:  with HTTP id 9546057; Wed, 18 Dec 2002 03:50:39 -0800
:From: "Matt Dillon" <[EMAIL PROTECTED]>
:Subject: Re: I'm leaving the project
:To: Darren Pilgrim <[EMAIL PROTECTED]>, Matt Dillon <[EMAIL PROTECTED]>
:Cc: [EMAIL PROTECTED], [EMAIL PROTECTED]
:X-Mailer: CommuniGate Pro Web Mailer v.3.5.9
:Date: Wed, 18 Dec 2002 03:50:39 -0800
:Message-ID: <[EMAIL PROTECTED]>
:In-Reply-To: <[EMAIL PROTECTED]>
:MIME-Version: 1.0
:Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
:Content-Transfer-Encoding: 8bit
:Sender: [EMAIL PROTECTED]
:List-ID: 
:List-Archive:  (Web Archive)
:List-Help:  (List Instructions)
:List-Subscribe: 
:List-Unsubscribe: 
:X-Loop: FreeBSD.ORG
:Precedence: bulk
:
:On Tue, 17 Dec 2002 10:56:19 -0800
:
:>Does anyone know why this person is trying to (poorly) 
:>impersonate MD?
:
:Unfortunately not. We do not yet know who this fake Dillon 
:is (the guy posting from that backplane.com address)
:
:I've been working hard on the new ipfw[2] patch for 5.0, 
:the new patch is released under the DPL. For those of you 
:not familiar with it, here's the most important paragraph:
:
:The de Raadt Public License 1.0
:
:Redistribution and use in source and binary forms, with or 
:without modification, are permitted provided that the 
:following conditions are met:
:
: * Redistributions of source code must retain the 
:above copyright notice,
: this list of conditions and the following 
:disclaimer. 
: * Redistributions in binary form must reproduce 
:the above copyright notice,
: this list of conditions and the following 
:disclaimer in the documentation 
: and/or other materials provided with the 
:distribution. 
: * FUCK YOU ALL ASSHOLES!
:
:Take care,
:   Matthew Dillon
:
:
:_
:For the best comics, toys, movies, and more,
:please visit 

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

i386 tinderbox failure

[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/i386/obj/local0/scratch/des/src/i386/usr/include
--
>>> stage 4: building libraries
--
>>> stage 4: make dependencies
--
>>> stage 4: building everything..
--
>>> Kernel build for GENERIC started on Wed Dec 18 09:39:09 PST 2002
--
>>> Kernel build for GENERIC completed on Wed Dec 18 10:30:49 PST 2002
--
>>> Kernel build for LINT started on Wed Dec 18 10:30:50 PST 2002
--
===> vesa
"Makefile", line 5401: warning: duplicate script for target "geom_bsd.o" ignored
"Makefile", line 5404: warning: duplicate script for target "geom_mbr.o" ignored
/local0/scratch/des/src/sys/contrib/dev/acpica/dbdisply.c:131: warning: `_THIS_MODULE' 
defined but not used
/local0/scratch/des/src/sys/contrib/dev/acpica/dbexec.c:124: warning: `_THIS_MODULE' 
defined but not used
/local0/scratch/des/src/sys/contrib/dev/acpica/dbhistry.c:124: warning: `_THIS_MODULE' 
defined but not used
/local0/scratch/des/src/sys/contrib/dev/acpica/dbinput.c:125: warning: `_THIS_MODULE' 
defined but not used
/local0/scratch/des/src/sys/contrib/dev/acpica/dbstats.c:125: warning: `_THIS_MODULE' 
defined but not used
/local0/scratch/des/src/sys/contrib/dev/acpica/dbxface.c:127: warning: `_THIS_MODULE' 
defined but not used
/local0/scratch/des/src/sys/contrib/dev/acpica/hwgpe.c:122: warning: `_THIS_MODULE' 
defined but not used
/local0/scratch/des/src/sys/contrib/dev/acpica/hwregs.c: In function 
`AcpiGetSleepTypeData':
/local0/scratch/des/src/sys/contrib/dev/acpica/hwregs.c:242: warning: cast discards 
qualifiers from pointer target type
/local0/scratch/des/src/sys/contrib/dev/acpica/nsxfname.c:125: warning: `_THIS_MODULE' 
defined but not used
/local0/scratch/des/src/sys/contrib/dev/acpica/nsxfobj.c:126: warning: `_THIS_MODULE' 
defined but not used
/local0/scratch/des/src/sys/contrib/dev/acpica/rsdump.c:124: warning: `_THIS_MODULE' 
defined but not used
/local0/scratch/des/src/sys/contrib/dev/acpica/utclib.c:129: warning: `_THIS_MODULE' 
defined but not used
/local0/scratch/des/src/sys/contrib/dev/acpica/utdebug.c:122: warning: `_THIS_MODULE' 
defined but not used
/local0/scratch/des/src/sys/contrib/dev/acpica/utglobal.c: In function 
`AcpiUtGetRegionName':
/local0/scratch/des/src/sys/contrib/dev/acpica/utglobal.c:482: warning: cast discards 
qualifiers from pointer target type
/local0/scratch/des/src/sys/contrib/dev/acpica/utglobal.c: In function 
`AcpiUtGetEventName':
/local0/scratch/des/src/sys/contrib/dev/acpica/utglobal.c:520: warning: cast discards 
qualifiers from pointer target type
/local0/scratch/des/src/sys/contrib/dev/acpica/utglobal.c: In function 
`AcpiUtGetTypeName':
/local0/scratch/des/src/sys/contrib/dev/acpica/utglobal.c:590: warning: cast discards 
qualifiers from pointer target type
/local0/scratch/des/src/sys/contrib/dev/acpica/utglobal.c:593: warning: cast discards 
qualifiers from pointer target type
/local0/scratch/des/src/sys/dev/acpica/acpi_acad.c:50: warning: `_THIS_MODULE' defined 
but not used
/local0/scratch/des/src/sys/dev/acpica/acpi_cmbat.c:56: warning: `_THIS_MODULE' 
defined but not used
/local0/scratch/des/src/sys/dev/acpica/acpi_powerres.c:272: warning: 
`acpi_pwr_deregister_consumer' defined but not used
/local0/scratch/des/src/sys/dev/acpica/acpi_powerres.c:210: warning: 
`acpi_pwr_deregister_resource' defined but not used
/local0/scratch/des/src/sys/dev/ie/if_ie.c: In function `ieattach':
/local0/scratch/des/src/sys/dev/ie/if_ie.c:778: warning: assignment discards 
qualifiers from pointer target type
/local0/scratch/des/src/sys/dev/ie/if_ie.c: In function `ieget':
/local0/scratch/des/src/sys/dev/ie/if_ie.c:1147: warning: passing arg 1 of `bcopy' 
discards qualifiers from pointer target type
/local0/scratch/des/src/sys/dev/ie/if_ie.c:1237: warning: passing arg 1 of `bcopy' 
discards qualifiers from pointer target type
/local0/scratch/des/src/sys/dev/ie/if_ie.c:1237: warning: passing arg 2 of `bcopy' 
discards qualifiers from po

Re: swapoff code comitted.

[Matthew Dillon]

:I have made a small patch, added l, s and h switches to show
:information about the swap devices. And the U switch to swapctl only
:to remove all activated swap devices.
:If anything else is needed let me know and I will add it.
:
:--=20
:
:Eirik Nygaard <[EMAIL PROTECTED]>
:PGP Key: 83C55EDE

That is a pretty good first attempt.  I have a few suggests and found 
one bug.  First the bug:

:+  is_swapctl ? "lsU" : "");

I think that was supposed to be a call to is_swapctl, not a pointer
to the function.

Suggestions:  Get rid of the is_swap*() functions and instead use
av[0] at the top of main() and use strstr() to determine if the
program is swapon, swapoff, or swapctl.  Check against "swapon" and
"swapoff" and if it is neither then default to swapctl (don't test
against "swapctl").  Store which program it is in a global variable,
e.g.  an enum like this:

enum { SWAPON, SWAPOFF, SWAPCTL } which_prog = SWAPCTL;

...
main(...)
{
if (strstr(av[0], "swapon"))
which_prog = SWAPON;
else if (strstr(av[0], "swapoff"))
which_prog = SWAPOFF;
...
}

In regards to retrieving swap information, in -current there is a
sysctl() to do it.  Take a look at /usr/src/usr.sbin/pstat/pstat.c
(in the current source tree), at the swapmode_kvm() and swapmode_sysctl()
functions.  The sysctl is much, much faster then the kvm call because
the kvm call has to run through the swap radix tree to collect the useage
information.

-Matt
Matthew Dillon 
<[EMAIL PROTECTED]>


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

Re: panic: ffs_blkfree: freeing free block

[Kirk McKusick]

I have managed to panic my system on a hard reboot and now believe
that I have found the problem on which you are faulting. I have
checked in a fix to the head of the tree (sys/ufs/ffs/ffs_snapshot.c
version 1.57). Let me know if it fixes your problem.

Kirk McKusick

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

GBDE: Bad bug fixed.

[Poul-Henning Kamp]

Marcus Reid <[EMAIL PROTECTED]> found a pair of bad bugs in the
GBDE code which could result in corrupt data under some circumstances.

The two separate bug was in the mapping code which decides where
to put the encrypted sectors on the device.

One bug affected only certain multi lock configurations, and will
probably result in a lock-out situation if hit.

The other and more serious would result in data corruption if the
requestsize was larger than the sectorsize.

If you have data on GBDE which you care about, you should do the
following:

dump(8) from the encrypted device to some media/file.
Make sure you have these versions:
  1.8   +21 -1 src/sbin/gbde/gbde.c
  1.6   +2 -2  src/sys/geom/bde/g_bde_crypt.c
  1.6   +6 -0  src/sys/geom/bde/g_bde_lock.c
  1.4   +7 -42 src/sys/geom/bde/g_bde_work.c
Recompile the kernel and gbde(8).
Teboot the new kernel.
Use gbde(8) to init the device again.
Use restore(8) to put your data back on the encrypted device.
(Delete the backup copy if it is on unsafe media).

My sincerest apologies for overlooking what in hindsight is a rather
obvious bug...

Poul-Henning

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

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

Re: 80386 out of GENERIC

[Craig Reyenga]

I can't believe this thread is still polluting the email system. 386's are
old, slow, and virtually useless. I think that the time wasted on supporting
junk hardware would be better spent on utilising the features and
capabilities of new hardware. As someone mentioned, if you want to use crap
hardware, install NetBSD. FreeBSD's goal isn't to be able to run on
anything, it's to be able to run fast on specific things. With that in mind,
put your 386's away, or find a different OS. I know it may be hard to part
with old junk, but that's life.

-Craig

- Original Message -
From: "Leif Neland" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, December 18, 2002 02:12
Subject: Re: 80386 out of GENERIC
> But still, would it be impossible to have both a GENERIC and a GENERIC386
> kernel in the distribution?
>
> Or is the whole system compiled in non-386 mode?
>
> Even so, if just one site. www.386.freebsd.org were having a 386-enabled
> version available, wouldn't that make everybody happy?
>
> Leif
>
>
> 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: swapoff code comitted.

[Eirik Nygaard]

On Wed, Dec 18, 2002 at 11:18:24AM -0800, Matthew Dillon wrote:
> 
> :I have made a small patch, added l, s and h switches to show
> :information about the swap devices. And the U switch to swapctl only
> :to remove all activated swap devices.
> :If anything else is needed let me know and I will add it.
> :
> :--=20
> :
> :Eirik Nygaard <[EMAIL PROTECTED]>
> :PGP Key: 83C55EDE
> 
> That is a pretty good first attempt.  I have a few suggests and found 
> one bug.  First the bug:
> 
> :+is_swapctl ? "lsU" : "");
> 
> I think that was supposed to be a call to is_swapctl, not a pointer
> to the function.
> 
> Suggestions:  Get rid of the is_swap*() functions and instead use
> av[0] at the top of main() and use strstr() to determine if the
> program is swapon, swapoff, or swapctl.  Check against "swapon" and
> "swapoff" and if it is neither then default to swapctl (don't test
> against "swapctl").  Store which program it is in a global variable,
> e.g.  an enum like this:
> 
> enum { SWAPON, SWAPOFF, SWAPCTL } which_prog = SWAPCTL;
> 
> In regards to retrieving swap information, in -current there is a
> sysctl() to do it.  Take a look at /usr/src/usr.sbin/pstat/pstat.c
> (in the current source tree), at the swapmode_kvm() and swapmode_sysctl()
> functions.  The sysctl is much, much faster then the kvm call because
> the kvm call has to run through the swap radix tree to collect the useage
> information.
> 

Added the enum instead of is_swap* commands and changed from kvm to
sysctl to get the swap information.

-- 

Eirik Nygaard <[EMAIL PROTECTED]>
PGP Key: 83C55EDE


? sbin/swapon/.swapon.c.swp
Index: sbin/swapon/Makefile
===
RCS file: /home/ncvs/src/sbin/swapon/Makefile,v
retrieving revision 1.7
diff -u -r1.7 Makefile
--- sbin/swapon/Makefile15 Dec 2002 19:17:56 -  1.7
+++ sbin/swapon/Makefile18 Dec 2002 20:35:53 -
@@ -3,7 +3,9 @@
 
 PROG=  swapon
 MAN=   swapon.8
-LINKS= ${BINDIR}/swapon ${BINDIR}/swapoff
-MLINKS=swapon.8 swapoff.8
+LINKS= ${BINDIR}/swapoff ${BINDIR}/swapon
+LINKS+=${BINDIR}/swapctl ${BINDIR}/swapon
+MLINKS=swapoff.8 swapon.8
+MLINKS=swapctl.8 swapon.8
 
 .include 
Index: sbin/swapon/swapon.c
===
RCS file: /home/ncvs/src/sbin/swapon/swapon.c,v
retrieving revision 1.13
diff -u -r1.13 swapon.c
--- sbin/swapon/swapon.c15 Dec 2002 19:17:56 -  1.13
+++ sbin/swapon/swapon.c18 Dec 2002 20:35:53 -
@@ -45,6 +45,11 @@
   "$FreeBSD: src/sbin/swapon/swapon.c,v 1.13 2002/12/15 19:17:56 dillon Exp $";
 #endif /* not lint */
 
+#include 
+#include 
+#include 
+#include 
+
 #include 
 #include 
 #include 
@@ -52,10 +57,13 @@
 #include 
 #include 
 #include 
+#include 
+
+static void usage(void);
+intswap_on_off(char *name, int ignoreebusy);
+void   swaplist(int, int, int);
 
-static void usage(const char *);
-static int is_swapoff(const char *);
-intswap_on_off(char *name, int ignoreebusy, int do_swapoff);
+enum { SWAPON, SWAPOFF, SWAPCTL } which_prog = SWAPCTL;
 
 int
 main(int argc, char **argv)
@@ -63,47 +71,80 @@
struct fstab *fsp;
int stat;
int ch, doall;
-   int do_swapoff;
-   char *pname = argv[0];
-
-   do_swapoff = is_swapoff(pname);
-
+   int sflag = 0, lflag = 0, hflag = 0;
+   
+   if (strstr(argv[0], "swapon"))
+   which_prog = SWAPON;
+   else if (strstr(argv[0], "swapoff"))
+   which_prog = SWAPOFF;
+   
doall = 0;
-   while ((ch = getopt(argc, argv, "a")) != -1)
-   switch((char)ch) {
+   while ((ch = getopt(argc, argv, "alhsU")) != -1)
+   switch(ch) {
case 'a':
doall = 1;
break;
+   case 's':
+   sflag = 1;
+   break;
+   case 'l':
+   lflag = 1;
+   break;
+   case 'h':
+   hflag = 1;
+   break;
+   case 'U':
+   if (which_prog != SWAPON) {
+   doall = 1;
+   which_prog = SWAPOFF;
+   break;
+   } /* Remove the if if you want the U switch to work with 
+swapon also, don't know if that is wanted */
case '?':
default:
-   usage(pname);
+   usage();
}
argv += optind;
-
+   
stat = 0;
-   if (doall)
-   while ((fsp = getfsent()) != NULL) {
-   if (strcmp(fsp->fs_type, FSTAB_SW))
-   continue;
-   if (strstr(fsp->fs_mntops, "noauto"))
-   

Re: panic: ffs_blkfree: freeing free block

[Aurelien Nephtali]

On Wed, Dec 18, 2002 at 11:50:42AM -0800, Kirk McKusick wrote:
> I have managed to panic my system on a hard reboot and now believe
> that I have found the problem on which you are faulting. I have
> checked in a fix to the head of the tree (sys/ufs/ffs/ffs_snapshot.c
> version 1.57). Let me know if it fixes your problem.
> 
>   Kirk McKusick
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message

Yep! It works now :)
Thanks :)

-- Aurelien



msg49012/pgp0.pgp
Description: PGP signature

Re: 80386 out of GENERIC

[tlambert2]

On Tue, 17 Dec 2002 19:47:24 -0800 Juli Mallett <[EMAIL PROTECTED]> wrote:
> * De: Terry Lambert  [ Data: 2002-12-17 ]
>   [ Subjecte: Re: 80386 out of GENERIC ]
> > Apparently, one of the primary markets for
> FreeBSD is embedded
> > devices.
> 
> Are you implying that these people, who are
> undoubtedly adding and
> removing lots of things in the kernel, to make
> things fit, and to
> make things do their jobs, can't be bothered to
> use the appropriate
> CPU settings?

I'm implying that they *can* be bothered.

I'm also implying that they *are* bothered.

Finally, I'm saying that the less bother, the better.

-- Terry

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

Re: 80386 out of GENERIC

[tlambert2]

On Tue, 17 Dec 2002 20:09:10 -0800 Juli Mallett <[EMAIL PROTECTED]> wrote:
> I don't think anyone wants that to happen
> (though I wouldn't put it past
> some people to want to do that).

FWIW, all I've really been doing is defending the idea that some people want
the code to run on a 386, however poorly.

But for the most part, the people who would use that approach aren't bothered
by not having 386 support there by default.

BTW, for the person who pointed out that the userland is 486, and won't run on
386, anyway, without everything rebuilt: I'm pretty sure that's not true since
the compiler upgrade, since the new compiler can't do CPU optimization
correctly, without puking things out.  8-).

-- Terry

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

Re: 80386 out of GENERIC

[Paul A. Scott]

> From: "Craig Reyenga" <[EMAIL PROTECTED]>
> I can't believe this thread is still polluting the email system. 386's are
> old, slow, and virtually useless. I think that the time wasted on supporting
> junk hardware would be better spent on utilising the features and
> capabilities of new hardware. As someone mentioned, if you want to use crap
> hardware, install NetBSD. FreeBSD's goal isn't to be able to run on
> anything, it's to be able to run fast on specific things. With that in mind,
> put your 386's away, or find a different OS. I know it may be hard to part
> with old junk, but that's life.

I take great offense in all of what you posted. Your opinion is extremely
short-sighted and one-sided. I don't have any problem with removing 386
support from GENERIC, and there need be no requirement to pre-build anything
beyond what has already been decided, but I would hope that it will be
possible to simply 'make' a 386 kernel--and all the rest--indefinitely.

-- 
Paul A. Scott
mailto:[EMAIL PROTECTED]
http://skycoast.us/pscott/


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

Re: I'm leaving the project

[William Michael Grim]

I don't care who hacked what; get over it, grow up, and move on.

William Michael Grim
Student, Southern Illinois University at Edwardsville
Unix System Administrator, SIUE, Computer Science dept.
Email: [EMAIL PROTECTED]



On Wed, 18 Dec 2002, Matt Dillon wrote:

> On Wed, 18 Dec 2002 13:22:09 -0600
>   [EMAIL PROTECTED] wrote:
> >You know, I hardly ever post here because I'm in the 
> >newbie stages of learning 
> >how the OS internals work, but you're really pissing me 
> >off.
> 
> I don't care.
> 
> >All you do is clog up my mail box, and I'm basically 
> >tired of your shit.
> 
> I don't care.
> 
> >EVERYONE on the list knows who the real Matt Dillon is; so, please, stfu.  If 
> 
> I don't care.
> 
> >Good day to you dipcrap,
> >Faker Hater
> 
> I don't know how old you are, or if you're just
> dim. If that Dillon moron hadn't backed out my
> good patches and started a flamewar over his
> shitty ipfw fix, I would have never posted that
> message. Now go and study The Design and
> Implementation of 4.4BSD by Dr. McKusick. Until
> you can tell ls from rm, get the fuck out of my
> inbox.
> 
> Yours,
>Matt 'ipfw patch' Dillon
> 
> _
> For the best comics, toys, movies, and more,
> please visit 
> 
> 


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

sparc64 tinderbox failure

[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/gbde
cc1: warnings being treated as errors
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c: In function 
`rijndaelKeySched':
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:41: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:41: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:48: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:48: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:66: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:66: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:70: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:70: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:77: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:77: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:83: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:83: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c: In function 
`rijndaelKeyEncToDec':
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:101: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:102: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:103: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:104: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:105: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:108: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:109: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:110: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:111: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:112: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:115: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:116: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:117: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:118: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:119: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:122: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:123: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/

Re: Data corruption in soft updates?

[Geoffrey T. Falk]

I've run into similar problems dual-booting 4.x and 5.x. Is there
some utility one can use to synchronize this once and for all?

IMHO, when the UFS1 superblock was changed, it should have been named
something else like UFS1_1 to avoid confusion.

gtf
--
Geoffrey T. Falk, BSc, MA, SCJ2P, SCSSadm7, FreeBSD since 1998

On 17 Dec, Kirk McKusick wrote:
> Please send me a `dumpfs /usr | head -50' output of the filesystem
> under the current system. Then clean it up with fsck and run the
> same command again. Finally, boot up under the old kernel and
> get the output both before and after fsck cleaning. What I am
> looking for is changes in the reported size of the filesystem
> because that getting out of sync is what is causing these problems.
> The basic deal is that the old UFS1 superblock stored the filesystem
> size in a 32-bit field. The new UFS1 superblock stores the filesystem
> size in a new (previously unused) 64-bit field. When you mount a
> UFS1 filesystem on a new kernel, it copies the 32-bit size field
> to the 64-bit field. At that point the filesystem size is in both
> places and should work equally well on old or new kernels. However,
> it does not update the 64-bit size field on any of the alternate
> superblocks. So, somehow, your using and copying an alternate into
> the standard location is losing the update done for the size field.
> I am not sure how that is happening, but I am hoping to catch
> where in all your messing around with alternates that is happening
> so I can cover that hole.
> 
>   Kirk McKusick



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

Re: Data corruption in soft updates?

[Nate Lawson]

On Tue, 17 Dec 2002, Kirk McKusick wrote:
> Please send me a `dumpfs /usr | head -50' output of the filesystem
> under the current system. Then clean it up with fsck and run the
> same command again. Finally, boot up under the old kernel and
> get the output both before and after fsck cleaning. What I am
> looking for is changes in the reported size of the filesystem
> because that getting out of sync is what is causing these problems.

Attached is the first one and then the result after cleaning with fsck did
differ.  The others were all identical to the latter so they are not
included.  Below is the diff between the two.  Interesting how blocks is
reduced post fsck, as you predicted.  The question is, why?

-Nate

--- dump1.txt   Wed Dec 18 13:21:56 2002
+++ dump2.txt   Wed Dec 18 13:21:56 2002
@@ -1,10 +1,10 @@
-magic  11954 (UFS1)timeWed Dec 18 12:59:07 2002
+magic  11954 (UFS1)timeWed Dec 18 05:01:50 2002
 id [ 3d59009b 700be1d7 ]
-ncg20  size819580  blocks  1794231
+ncg20  size819580  blocks  806755
 bsize  16384   shift   14  mask0xc000
 fsize  2048shift   11  mask0xf800
 frag   8   shift   3   fsbtodb 2
-minfree8%  optim   timesymlinklen 60
+minfree8%  optim   space   symlinklen 60
 maxbpg 4096maxcontig 7 contigsumsize 7
 nbfree 11421   ndir19146   nifree  272816  nffree  67693
 cpg89  bpg 11392   fpg 91136   ipg 22528
@@ -14,8 +14,8 @@
 rotdelay 0ms   rps 60  trackskew 0 interleave 1
 nsect  4096npsect  4096spc 4096
 sblkno 8   cblkno  16  iblkno  24  dblkno  1432
-cgrotor0   fmod0   ronly   0   clean   1
-flags  soft-updates 
+cgrotor0   fmod0   ronly   0   clean   0
+flags  soft-updates unknown flags (0xff80)
 
 cs[].cs_(nbfree,ndir,nifree,nffree):

(0,1482,7459,897) (31,1806,7089,6895) (134,1545,9162,8266) (336,219,19257,8645) 
@@ -28,10 +28,10 @@
 
 
 cg 0:
-magic  90255   tell8000timeWed Dec 18 12:59:07 2002
+magic  90255   tell8000timeWed Dec 18 05:01:46 2002
 cgx0   ncyl89  niblk   22528   ndblk   91136
 nbfree 0   ndir1482nifree  7459nffree  897
-rotor  90008   irotor  4016frotor  50360
+rotor  90008   irotor  4016frotor  1448
 frsum  43  35  24  32  28  25  42
 sum of frsum: 897
 clusters 1-6:  0   0   0   0   0   0


magic   11954 (UFS1)timeWed Dec 18 12:59:07 2002
id  [ 3d59009b 700be1d7 ]
ncg 20  size819580  blocks  1794231
bsize   16384   shift   14  mask0xc000
fsize   2048shift   11  mask0xf800
frag8   shift   3   fsbtodb 2
minfree 8%  optim   timesymlinklen 60
maxbpg  4096maxcontig 7 contigsumsize 7
nbfree  11421   ndir19146   nifree  272816  nffree  67693
cpg 89  bpg 11392   fpg 91136   ipg 22528
nindir  4096inopb   128 nspf4   maxfilesize 1126174852055039
sbsize  2048cgsize  16384   cgoffset 1024   cgmask  0x
csaddr  1432cssize  2048
rotdelay 0msrps 60  trackskew 0 interleave 1
nsect   4096npsect  4096spc 4096
sblkno  8   cblkno  16  iblkno  24  dblkno  1432
cgrotor 0   fmod0   ronly   0   clean   1
flags   soft-updates 

cs[].cs_(nbfree,ndir,nifree,nffree):
(0,1482,7459,897) (31,1806,7089,6895) (134,1545,9162,8266) 
(336,219,19257,8645) 
(106,279,18193,7920) (1569,620,17451,2884) (1062,966,12422,3742) 
(2266,186,21896,2570) 
(123,2970,1965,5473) (100,516,16906,6126) (1620,858,13288,1257) 
(3952,1029,14065,1560) 
(6,1678,7948,3451) (76,2172,7894,2344) (0,930,8483,3) (0,194,18873,3157) 
(40,537,14315,254) (0,789,14393,67) (0,203,20696,1000) (0,167,21061,1182) 
cylinders in last group 89
blocks in last group 11311


cg 0:
magic   90255   tell8000timeWed Dec 18 12:59:07 2002
cgx 0   ncyl89  niblk   22528   ndblk   91136
nbfree  0   ndir1482nifree  7459nffree  897
rotor   90008   irotor  4016frotor  50360
frsum   43  35  24  32  28  25  42
sum of frsum: 897
clusters 1-6:   0   0   0   0   0   0
clusters size 7 and over: 0
clusters free:  
inodes used:0-4015, 4017-6244, 6252-6255, 6258-6279, 6281, 6284-6917,
6919-6937, 6939-7007, 7026, 7033, 7042, 7045,
7047-7054, 7056-7057, 7064-7065, 7068, 7081, 7084,
7090-7092, 7101-7102, 7109-7112, 7146, 7148, 7154-7156,
7169, 7174-7176, 7178, 7188, 7190-7193, 7200,
7202-7204, 7213, 7221, 7228-7821, 7826, 7835-7839,
7844-7845, 7848-7849, 7852, 7857, 7870, 7876-7878,
7883-7886, 7888, 7898-8042, 8047, 8049-8120, 8122,
8135-8442, 8444-8446, 8448-8450, 8453-8459, 8463, 8467,
8471

빠구리 즐겁게 한번 하자...!!

[케팅 마]

live10girls





 ¼ºÇö¾Æ ´©µåÁý °ø°³ 

   http://www.live10girls.com/index.asp?ID=5621228"; 
target=_blank>http://news.hot.co.kr/2002/12/09/200212092151172100_1.jpg"; 
border="0">

   http://www.live10girls.com/index.asp?ID=5621228"; 
target=_blank>http://news.hot.co.kr/2002/12/09/200212092151172100_2.jpg"; 
border="0"> 
 
   http://www.live10girls.com/index.asp?ID=5621228"; 
target=_blank>http://news.hot.co.kr/2002/12/09/200212092151172100_3.jpg"; 
border="0"> 
 
 http://www.live10girls.com/index.asp?ID=5621228"; target="_blank">º¸·¯
°¡±â
 º» À¥»çÀÌÆ®´Â ÀÎÅÍ³Ý ¼ºÀÎ Àü¹® Æ÷¸£³ë »çÀÌÆ®·Î, ¹ýÀûÀ¸·Î ÀÌ·¯ÇÑ ³»¿ëÀ» 
¿­¶÷
   ÇÒ ¼ö ¾ø´Â ¸¸ 20¼¼ÀÇ ¿¬·É ¹Ì¸¸À̳ª ÀÌ¿Í°°Àº À½¶õÇÑ ³»¿ë¿¡ °ÅºÎ°¨À» °®´Â 
»ç¶÷
   µéÀº ÀÔÀåÀ» ±ÝÇÕ´Ï´Ù.
   ¶ÇÇÑ º» »çÀÌÆ®´Â ¹ýÀûÀ¸·Î ÀÎÅͳݿ¡¼­ À½¶õ¹°À» Àü¼ÛÇÏ´Â °ÍÀÌ ±ÝÁöµÈ Áö¿ª
À̳ª 
   ±¹°¡¸¦ ´ë»óÀ¸·Î ÇÏ´Â ¼­ºñ½º°¡ ¾Æ´ÔÀ» ¹àÈü´Ï´Ù. À§ÀÇ »çÇ׿¡ µ¿ÀÇÇÏÁö ¾Ê´Â
´Ù¸é
   Àý´ë·Î µé¾î¿ÀÁö ¸¶½Ê½Ã¿À.
   
   This web site contains sexually oriented adult material which is not 

   suitable for those who are under the age of 20. If you
   are under the age of 20 or find material of an adult nature offensive, 
or 
   
   if you are accessing this site from a country where adult material is 

   specifically prohibited by law, please leave this site immediately. By 

   entering this web page you are acknowledging that you are in fact 20 
years 
   
   of age or older, and therefore we will hold no responsibility for any 
adult 
   
   material you find on this web site. All models on this site are 20 
years of 
   
   age or older. We do not promote violent, malignant, or child 
pornography. 
   
   If you understand and accept these terms you may enter.
 











_
°í.. °¨.. µµ.. »ç.. ¶û.. ¸¸.. µé.. ±â.. MSN ·¯ºê  http://www.msn.co.kr/love/


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

Re: Unwanted Spam 'Re: I'm leaving the project'

[Brandon D. Valentine]

On Wed, Dec 18, 2002 at 10:58:59AM -0800, Matthew Dillon wrote:
> You know, whoever you are, you must lead a very sad, paranoid,
> sit-in-the-corner-the-world-is-out-to-get-me life if you think you
> are actually accomplishing something here.  You are probably the
> same idiot who posts all that anonymous-coward BSD-Is-Dying junk
> to Slashdot.  I wouldn't be surprised at all.

For a much more in-depth analysis see my explanation from the last time
one of these (and quite likely the very same) impersonators popped up on
this list:

http://www.geocrawler.com/lists/3/FreeBSD/146/0/9367929/

Game on,

Brandon D. Valentine
-- 
[EMAIL PROTECTED]  http:///www.geekpunk.net

"Everyone's been sold American.  Don't let me catch you laughing when
the jukebox cries...Everything's been sold American.  No place to go and
brother, no place to stay."  -- Kinky Friedman, "Sold American"

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

Re: ipfw userland breaks again.

[Dan Lukes]

[EMAIL PROTECTED] wrote, On 12/14/02 23:13:

> I have a patch here which makes the IPFIREWALL_DEFAULT_TO_ACCEPT tunable
> at module load time using a kernel environment variable.  Looks to me
> that it would do what you want.

	Should we think about kldload logic change ?
	Loading modules giving them a parameter string parsed on MOD_LOAD event
seems to be most generic way to do the things (not only with ipfw) ...
	The syscall allow arbitrary string as parameter, so it's not limited to
filename only, event routine declaration already has the void *data
variable, so the necesarry changes doesn't hit the userland (kldload)
nor modules code (unless they decide to parse the parameters).

Dan


--
Dan Lukes tel: +420 2 21914205, fax: +420 2 21914206
root of  FIONet, KolejNET,  webmaster  of www.freebsd.cz
AKA: [EMAIL PROTECTED], [EMAIL PROTECTED],[EMAIL PROTECTED]



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

Re: swapoff code comitted.

[Matthew Dillon]

:Added the enum instead of is_swap* commands and changed from kvm to
:sysctl to get the swap information.
:
:Eirik Nygaard <[EMAIL PROTECTED]>
:PGP Key: 83C55EDE

All right, I found a couple more bugs and fleshed it out a bit.
You got your LINKS and MLINKS reversed and forgot a +=, 
you forgot to initialize the do_swapoff variable in swap_on_off(),
and you reuse 'total' and 'used' in swaplist() in a manner which breaks
the -s option.

I have included an updated patch below based on these fixes and a few 
other minor cleanups.  I also changed the block size for -h from 1000
to 1024 bytes to make it consistent with pstat -s and friends (and
also OpenBSD and NetBSD).

I also added -A, -U, cleaned up usage(), and made the options conform
to NetBSD and OpenBSD.

The only thing really missing is for us to handle the BLOCKSIZE
environment variable like 'df' does, and appropriate additions to
the manual page (which I would be happy to do).  Once we get those in
I will commit it.

Here is an updated patch.

-Matt

Index: Makefile
===
RCS file: /home/ncvs/src/sbin/swapon/Makefile,v
retrieving revision 1.7
diff -u -r1.7 Makefile
--- Makefile15 Dec 2002 19:17:56 -  1.7
+++ Makefile18 Dec 2002 21:31:41 -
@@ -4,6 +4,8 @@
 PROG=  swapon
 MAN=   swapon.8
 LINKS= ${BINDIR}/swapon ${BINDIR}/swapoff
+LINKS+=${BINDIR}/swapon ${BINDIR}/swapctl
 MLINKS=swapon.8 swapoff.8
+MLINKS+=swapon.8 swapctl.8
 
 .include 
Index: swapon.c
===
RCS file: /home/ncvs/src/sbin/swapon/swapon.c,v
retrieving revision 1.13
diff -u -r1.13 swapon.c
--- swapon.c15 Dec 2002 19:17:56 -  1.13
+++ swapon.c18 Dec 2002 22:20:42 -
@@ -45,6 +45,11 @@
   "$FreeBSD: src/sbin/swapon/swapon.c,v 1.13 2002/12/15 19:17:56 dillon Exp $";
 #endif /* not lint */
 
+#include 
+#include 
+#include 
+#include 
+
 #include 
 #include 
 #include 
@@ -52,10 +57,13 @@
 #include 
 #include 
 #include 
+#include 
+
+static void usage(void);
+static int swap_on_off(char *name, int ignoreebusy);
+static void swaplist(int, int, int);
 
-static void usage(const char *);
-static int is_swapoff(const char *);
-intswap_on_off(char *name, int ignoreebusy, int do_swapoff);
+enum { SWAPON, SWAPOFF, SWAPCTL } orig_prog, which_prog = SWAPCTL;
 
 int
 main(int argc, char **argv)
@@ -63,48 +71,105 @@
struct fstab *fsp;
int stat;
int ch, doall;
-   int do_swapoff;
-   char *pname = argv[0];
-
-   do_swapoff = is_swapoff(pname);
-
+   int sflag = 0, lflag = 0, hflag = 0;
+   
+   if (strstr(argv[0], "swapon"))
+   which_prog = SWAPON;
+   else if (strstr(argv[0], "swapoff"))
+   which_prog = SWAPOFF;
+   orig_prog = which_prog;
+   
doall = 0;
-   while ((ch = getopt(argc, argv, "a")) != -1)
-   switch((char)ch) {
+   while ((ch = getopt(argc, argv, "AadlhksU")) != -1) {
+   switch(ch) {
+   case 'A':
+   if (which_prog == SWAPCTL) {
+   doall = 1;
+   which_prog = SWAPON;
+   } else {
+   usage();
+   }
+   break;
case 'a':
-   doall = 1;
+   if (which_prog == SWAPON || which_prog == SWAPOFF)
+   doall = 1;
+   else
+   which_prog = SWAPON;
+   break;
+   case 'd':
+   if (which_prog == SWAPCTL)
+   which_prog = SWAPOFF;
+   else
+   usage();
+   break;
+   case 's':
+   sflag = 1;
+   break;
+   case 'l':
+   lflag = 1;
+   break;
+   case 'h':
+   hflag = 'M';
+   break;
+   case 'k':
+   hflag = 'K';
+   break;
+   case 'U':
+   if (which_prog == SWAPCTL) {
+   doall = 1;
+   which_prog = SWAPOFF;
+   } else {
+   usage();
+   }
break;
case '?':
default:
-   usage(pname);
+   usage();
}
+   }
argv += optind;
-
+   
stat = 0;
-   if (doall)
-   while ((fsp = getfsent()) != NULL) {
-   if (strcmp(fsp->f

patch #3 Re: swapoff code comitted.

[Matthew Dillon]

Here's another update.  I cleaned things up even more, add BLOCKSIZE
support, and updated the manual page.  It looks quite nice now.

-Matt

Index: Makefile
===
RCS file: /home/ncvs/src/sbin/swapon/Makefile,v
retrieving revision 1.7
diff -u -r1.7 Makefile
--- Makefile15 Dec 2002 19:17:56 -  1.7
+++ Makefile18 Dec 2002 21:31:41 -
@@ -4,6 +4,8 @@
 PROG=  swapon
 MAN=   swapon.8
 LINKS= ${BINDIR}/swapon ${BINDIR}/swapoff
+LINKS+=${BINDIR}/swapon ${BINDIR}/swapctl
 MLINKS=swapon.8 swapoff.8
+MLINKS+=swapon.8 swapctl.8
 
 .include 
Index: swapon.8
===
RCS file: /home/ncvs/src/sbin/swapon/swapon.8,v
retrieving revision 1.21
diff -u -r1.21 swapon.8
--- swapon.815 Dec 2002 19:17:56 -  1.21
+++ swapon.818 Dec 2002 22:46:01 -
@@ -43,45 +43,101 @@
 .Fl a
 .Nm swap[on|off]
 .Ar special_file ...
+.Nm swapctl
+.Fl lshk
+.Nm swapctl
+.Fl AU
+.Nm swapctl
+.Fl a
+.Ar special_file ...
+.Nm swapctl
+.Fl d
+.Ar special_file ...
 .Sh DESCRIPTION
 The
+.Nm swap[on,off,ctl]
+utilties are used to control swap devices in the system.  At boot time all
+swap entries in 
+.Pa /etc/fstab
+are added automatically when the system goes multi-user.
+Swap devices are interleaved and kernels are typically configured
+to handle a maximum of 4 swap devices.  There is no priority mechanism.
+.Pp
+The
 .Nm swapon
-utility is used to specify additional devices on which paging and swapping
-are to take place.
-The system begins by swapping and paging on only a single device
-so that only one disk is required at bootstrap time.
-Calls to
-.Nm swapon
-normally occur in the system multi-user initialization file
-.Pa /etc/rc
-making all swap devices available, so that the paging and swapping
-activity is interleaved across several devices.
+utility adds the specified swap devices to the system.  If the
+.Fl a
+option is used, all swap devices in
+.Pa /etc/fstab
+will be added, unless their ``noauto'' option is also set.
 .Pp
 The
 .Nm swapoff
-utility disables paging and swapping on a device.
-Calls to
+utility removes the specified swap devices from the system.  If the
+.Fl a
+option is used, all swap devices in
+.Pa /etc/fstab
+will be removed, unless their ``noauto'' option is also set.
+Note that
 .Nm swapoff
-succeed only if disabling the device would leave enough
-remaining virtual memory to accomodate all running programs.
+will fail and refuse to remove a swap device if there is insufficient
+VM (memory + remaining swap devices) to run the system.
+.Nm Swapoff
+must move sawpped pages out of the device being removed which could
+lead to high system loads for a period of time, depending on how
+much data has been swapped out to that device.
 .Pp
-Normally, the first form is used:
-.Bl -tag -width indent
-.It Fl a
-All devices marked as ``sw''
-swap devices in
+The
+.Nm swapctl
+utility exists primarily for those familiar with other BSDs and may be
+used to add, remove, or list swap.  Note that the
+.Fl a
+option is used diferently in
+.Nm swapctl
+and indicates that a specific list of devices should be added.
+The 
+.Fl d
+option indicates that a specific list should be removed.  The
+.Fl A
+and 
+.Fl D
+options to
+.Nm swapctl
+operate on all swap entries in
 .Pa /etc/fstab
-are added to or removed from the pool of available swap
-unless their ``noauto'' option is also set.
-.El
+which do not have their ``noauto'' option set.
+.Pp
+Swap information can be generated using the
+.Nm swapinfo
+program,
+.Nm pstat
+.Fl s ,
+or
+.Nm swapctl
+.Fl lshk .
+The
+.Nm swapctl
+utility has the following options for listing swap:
+.Bl -tag -width indent
+.It Fl l
+List the devices making up system swap.
+.It Fl s
+Print a summary line for system swap.
+.It Fl h
+Output values in megabytes.
+.It Fl k
+Output values in kilobytes.
 .Pp
-The second form is used to configure or disable individual devices.
+The BLOCKSIZE environment variable is used if not specifically
+overridden.  512 byte blocks are used by default.
+.El
 .Sh SEE ALSO
 .Xr swapon 2 ,
 .Xr fstab 5 ,
 .Xr init 8 ,
 .Xr mdconfig 8 ,
 .Xr pstat 8 ,
+.Xr swapinfo 8 ,
 .Xr rc 8
 .Sh FILES
 .Bl -tag -width "/dev/{ad,da}?s?b" -compact
Index: swapon.c
===
RCS file: /home/ncvs/src/sbin/swapon/swapon.c,v
retrieving revision 1.13
diff -u -r1.13 swapon.c
--- swapon.c15 Dec 2002 19:17:56 -  1.13
+++ swapon.c18 Dec 2002 22:53:52 -
@@ -45,6 +45,11 @@
   "$FreeBSD: src/sbin/swapon/swapon.c,v 1.13 2002/12/15 19:17:56 dillon Exp $";
 #endif /* not lint */
 
+#include 
+#include 
+#include 
+#include 
+
 #include 
 #include 
 #include 
@@ -52,10 +57,13 @@
 #include 
 #include 
 #include 
+#include 
+
+static void usage(void);
+static int swap_on_off(char *name, int ignoreebusy);
+static void sw

ia64 tinderbox failure

[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/gbde
cc1: warnings being treated as errors
/home/tinderbox/ia64/src/sys/crypto/rijndael/rijndael-alg-fst.c: In function 
`rijndaelKeySched':
/home/tinderbox/ia64/src/sys/crypto/rijndael/rijndael-alg-fst.c:41: warning: cast 
increases required alignment of target type
/home/tinderbox/ia64/src/sys/crypto/rijndael/rijndael-alg-fst.c:41: warning: cast 
increases required alignment of target type
/home/tinderbox/ia64/src/sys/crypto/rijndael/rijndael-alg-fst.c:48: warning: cast 
increases required alignment of target type
/home/tinderbox/ia64/src/sys/crypto/rijndael/rijndael-alg-fst.c:48: warning: cast 
increases required alignment of target type
/home/tinderbox/ia64/src/sys/crypto/rijndael/rijndael-alg-fst.c:66: warning: cast 
increases required alignment of target type
/home/tinderbox/ia64/src/sys/crypto/rijndael/rijndael-alg-fst.c:66: warning: cast 
increases required alignment of target type
/home/tinderbox/ia64/src/sys/crypto/rijndael/rijndael-alg-fst.c:70: warning: cast 
increases required alignment of target type
/home/tinderbox/ia64/src/sys/crypto/rijndael/rijndael-alg-fst.c:70: warning: cast 
increases required alignment of target type
/home/tinderbox/ia64/src/sys/crypto/rijndael/rijndael-alg-fst.c:77: warning: cast 
increases required alignment of target type
/home/tinderbox/ia64/src/sys/crypto/rijndael/rijndael-alg-fst.c:77: warning: cast 
increases required alignment of target type
/home/tinderbox/ia64/src/sys/crypto/rijndael/rijndael-alg-fst.c:83: warning: cast 
increases required alignment of target type
/home/tinderbox/ia64/src/sys/crypto/rijndael/rijndael-alg-fst.c:83: warning: cast 
increases required alignment of target type
/home/tinderbox/ia64/src/sys/crypto/rijndael/rijndael-alg-fst.c: In function 
`rijndaelKeyEncToDec':
/home/tinderbox/ia64/src/sys/crypto/rijndael/rijndael-alg-fst.c:101: warning: cast 
increases required alignment of target type
/home/tinderbox/ia64/src/sys/crypto/rijndael/rijndael-alg-fst.c:102: warning: cast 
increases required alignment of target type
/home/tinderbox/ia64/src/sys/crypto/rijndael/rijndael-alg-fst.c:103: warning: cast 
increases required alignment of target type
/home/tinderbox/ia64/src/sys/crypto/rijndael/rijndael-alg-fst.c:104: warning: cast 
increases required alignment of target type
/home/tinderbox/ia64/src/sys/crypto/rijndael/rijndael-alg-fst.c:105: warning: cast 
increases required alignment of target type
/home/tinderbox/ia64/src/sys/crypto/rijndael/rijndael-alg-fst.c:108: warning: cast 
increases required alignment of target type
/home/tinderbox/ia64/src/sys/crypto/rijndael/rijndael-alg-fst.c:109: warning: cast 
increases required alignment of target type
/home/tinderbox/ia64/src/sys/crypto/rijndael/rijndael-alg-fst.c:110: warning: cast 
increases required alignment of target type
/home/tinderbox/ia64/src/sys/crypto/rijndael/rijndael-alg-fst.c:111: warning: cast 
increases required alignment of target type
/home/tinderbox/ia64/src/sys/crypto/rijndael/rijndael-alg-fst.c:112: warning: cast 
increases required alignment of target type
/home/tinderbox/ia64/src/sys/crypto/rijndael/rijndael-alg-fst.c:115: warning: cast 
increases required alignment of target type
/home/tinderbox/ia64/src/sys/crypto/rijndael/rijndael-alg-fst.c:116: warning: cast 
increases required alignment of target type
/home/tinderbox/ia64/src/sys/crypto/rijndael/rijndael-alg-fst.c:117: warning: cast 
increases required alignment of target type
/home/tinderbox/ia64/src/sys/crypto/rijndael/rijndael-alg-fst.c:118: warning: cast 
increases required alignment of target type
/home/tinderbox/ia64/src/sys/crypto/rijndael/rijndael-alg-fst.c:119: warning: cast 
increases required alignment of target type
/home/tinderbox/ia64/src/sys/crypto/rijndael/rijndael-alg-fst.c:122: warning: cast 
increases required alignment of target type
/home/tinderbox/ia64/src/sys/crypto/rijndael/rijndael-alg-fst.c:123: warning: cast 
increase

5.0 Install Troubles

[Ryan Sommers]

I've been having difficulty installing 5.0 from the SP2 and RC1 images I
created. I'm attempting to install in a virtual machine under vmware.
For distributions I choose Custom and only choose to install the base, I
would like to install/build&install my own selection of packages later. 

It gets through the base install fine however, when it comes up asking
if I would like to install Linux Compatability I choose yes and the
debug screen says:

/usr/libexec/ld-elf.so.1: Shared object "libssl.so.2" not found

Attempting to install any packages also results in the same error. I
haven't tried installing it on an actual machine yet, been working at
the desk and had a spare Win2K box sitting there so I decided to try it
out. Is the problem with installing it in VMware? I thought so at first
so I attempted an install of 4.7 with the same options and it went fine.

Thanks,
Ryan

-- 
Ryan "leadZERO" Sommers
[EMAIL PROTECTED]
ICQ: 1019590   AIM/MSN: leadZERO




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

Re: 5.0 Install Troubles

[Nate Lawson]

On 18 Dec 2002, Ryan Sommers wrote:
> I've been having difficulty installing 5.0 from the SP2 and RC1 images I
> created. I'm attempting to install in a virtual machine under vmware.
> For distributions I choose Custom and only choose to install the base, I
> would like to install/build&install my own selection of packages later. 
> 
> It gets through the base install fine however, when it comes up asking
> if I would like to install Linux Compatability I choose yes and the
> debug screen says:
> 
> /usr/libexec/ld-elf.so.1: Shared object "libssl.so.2" not found

It sounds like you didn't install the secure dist.  But I thought ssl had
been moved to bin so I'm not sure.

-Nate


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

Re: patch #3 Re: swapoff code comitted.

[Bruce Evans]

On Wed, 18 Dec 2002, Matthew Dillon wrote:

> Here's another update.  I cleaned things up even more, add BLOCKSIZE
> support, and updated the manual page.  It looks quite nice now.

I still dislike it.  It starts by adding style bugs to the Makefile
(changing "=" to "+=" for the initial assignments to LINKS and MLINKS)
and doesn't get any better.

Bruce


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

PFIL_HOOKS should be made default in 5.0

[Hiten Pandya]

Hi all.

A teeny-weeny issue I would like to discuss, is that we make the pfil(9)
hooks code default in 5.0, and remove the kernel option; this is because
it creates problems when PFIL_HOOKS is not in the (e.g. GENERIC) kernel,
and someone tries to load the ipfilter kernel module (ipl.ko). [1]

I have discussed this with Darren, but would just like to make it
public, so it can be discussed by the release engineers etc.  I
apologize but I do not have patches for this.

Cheers.

-- 
Hiten Pandya ([EMAIL PROTECTED], [EMAIL PROTECTED])
http://www.unixdaemons.com/~hiten/

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

Re: 5.0 Install Troubles

[Ryan Sommers]

Yah, there isn't a secure dist. I'm doing a full install now, to see if
it hits it. I don't understand why only installing base would work on
4.7 but not on 5.0.

On Wed, 2002-12-18 at 17:57, Nate Lawson wrote:
> It sounds like you didn't install the secure dist.  But I thought ssl had
> been moved to bin so I'm not sure.
> 
> -Nate
-- 
Ryan "leadZERO" Sommers
[EMAIL PROTECTED]
ICQ: 1019590   AIM/MSN: leadZERO




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

Re: PFIL_HOOKS should be made default in 5.0

[Sam Leffler]

> A teeny-weeny issue I would like to discuss, is that we make the pfil(9)
> hooks code default in 5.0, and remove the kernel option; this is because
> it creates problems when PFIL_HOOKS is not in the (e.g. GENERIC) kernel,
> and someone tries to load the ipfilter kernel module (ipl.ko). [1]
>
> I have discussed this with Darren, but would just like to make it
> public, so it can be discussed by the release engineers etc.  I
> apologize but I do not have patches for this.
>

Enabling PFIL_HOOKS changes various code paths.  Doing this so late in the
release cycle is a bad idea.  I also recall that there is a performance
penalty (at least in the bridge code) for having this enabled.

Both issues make it seem like it should stay an option for 5.0.

Sam


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

Re: patch #3 Re: swapoff code comitted.

[David Schultz]

Looks good to me, modulo a few nits.  I try not to nitpick, but
I've mentioned a few of them below.  (BDE does a better job of it
than I do anyway.  :-)

The patch puts identical functionality in two places, so maybe it
would make sense to rip support for -s out of pstat/swapinfo (and
integrate 'pstat -ss' support into swapctl).  If we really want to
go the NetBSD way, we could even integrate the swapon(2) and
swapoff(2) into swapctl(2).  Doesn't matter to me.

(BTW, when I get the chance, I'll re-run my swapoff torture tests
now that Alan Cox's new locking is in place.  Chances are the
swapoff code needs to be brought up to date..)

> Index: swapon.8
> ===
> RCS file: /home/ncvs/src/sbin/swapon/swapon.8,v
> retrieving revision 1.21
> diff -u -r1.21 swapon.8
[...]
> +.Nm Swapoff
> +must move sawpped pages out of the device being removed which could

I think you have a tpyo there.  ;-)

> +Swap information can be generated using the
> +.Nm swapinfo
> +program,
> +.Nm pstat
> +.Fl s ,
> +or
> +.Nm swapctl
> +.Fl lshk .

IIRC, swapinfo is just there for compatibility (it's a hard link
to pstat), so there's no need to advertise it.

> Index: swapon.c
> ===
> RCS file: /home/ncvs/src/sbin/swapon/swapon.c,v
> retrieving revision 1.13
> diff -u -r1.13 swapon.c
[...]
> + if (strstr(argv[0], "swapon"))
> + which_prog = SWAPON;
> + else if (strstr(argv[0], "swapoff"))
> + which_prog = SWAPOFF;

It's probably better to do a strcmp on strrchr(argv[0], '/') when
argv[0] contains a slash.  Otherwise people will wonder why
swapoff(8) breaks when they (perhaps mistakenly) compile and run
it from the src/sbin/swapon directory.

> + while ((ch = getopt(argc, argv, "AadlhksU")) != -1) {
> + switch(ch) {
> + case 'A':
> + if (which_prog == SWAPCTL) {
> + doall = 1;
> + which_prog = SWAPON;
> + } else {
> + usage();
> + }
> + break;
[...]

The repeated 'whichprog == foo' tests can be combined into a
single test at the end of the loop.

> -
> + 

?

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

Re: 80386 out of GENERIC

[Bruce Evans]

On Wed, 18 Dec 2002, John Baldwin wrote:

> On 18-Dec-2002 Terry Lambert wrote:
> > The pessimization that was being discussed right before that happened
> > was "harvesting entropy for /dev/random".  I can provide mailing list
> > quotes about that bracketing those dates.
>
> No, the pessimization is:
>
> #if defined(I386_CPU) || defined(CPU_DISABLE_CMPXCHG)
>
> static __inline int
> atomic_cmpset_int(volatile u_int *dst, u_int exp, u_int src)
> {
> int res = exp;
>
> __asm __volatile(
> "   pushfl ;"
> "   cli ;   "
> "   cmpl%0,%2 ; "
> "   jne 1f ;"
> "   movl%1,%2 ; "
> "1: "
> "   sete%%al;   "
> "   movzbl  %%al,%0 ;   "
> "   popfl ; "
> "# atomic_cmpset_int"
> : "+a" (res)/* 0 (result) */
> : "r" (src),/* 1 */
>   "m" (*(dst))  /* 2 */
> : "memory");
>
> return (res);
> }
>
> #else /* defined(I386_CPU) */
>
> static __inline int
> atomic_cmpset_int(volatile u_int *dst, u_int exp, u_int src)
> {
> int res = exp;
>
> __asm __volatile (
> "   " __XSTRING(MPLOCKED) " "
> "   cmpxchgl %1,%2 ;"
> "   setz%%al ;  "
> "   movzbl  %%al,%0 ;   "
> "1: "
> "# atomic_cmpset_int"
> : "+a" (res)/* 0 (result) */
> : "r" (src),/* 1 */
>   "m" (*(dst))  /* 2 */
> : "memory");
>
> return (res);
> }
>
> #endif /* defined(I386_CPU) */
>
> > Was there a particular pessimization other than /dev/random that you
> > were thinking of when you made the commit comment?
>
> Yes, the one above.  It came in as part of SMPng.

I think this is an insignificant pessimization (except for vmware).  The
main issue is that the i386 version doesn't actually work for SMP.  It
would need to be more comlicated and pessimal to work.

BTW, I have micro-optimized the above (to usually avoid the movzbl and
to allocate registers better, especially the hard register %al).  One
reason that I haven't committed the changes is that I haven't got around
to testing them for the CPU_I386 case.

Bruce


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

Re: patch #3 Re: swapoff code comitted.

[Matthew Dillon]

:Looks good to me, modulo a few nits.  I try not to nitpick, but
:I've mentioned a few of them below.  (BDE does a better job of it
:than I do anyway.  :-)
:
:The patch puts identical functionality in two places, so maybe it
:would make sense to rip support for -s out of pstat/swapinfo (and
:integrate 'pstat -ss' support into swapctl).  If we really want to
:go the NetBSD way, we could even integrate the swapon(2) and
:swapoff(2) into swapctl(2).  Doesn't matter to me.

I think we should keep swapon and swapoff as separate commands.
They are the most intuitive of the lot.

NetBSD's pstat supports -s, as does OpenBSD's, so there is no reason
to rip out support for -s in our pstat.

Neither OpenBSD or NetBSD have swapinfo that I can find.  We could
potentially rip out the swapinfo command though all it is is a hardlink
to pstat so it wouldn't really save us anything.

:(BTW, when I get the chance, I'll re-run my swapoff torture tests
:now that Alan Cox's new locking is in place.  Chances are the
:swapoff code needs to be brought up to date..)

I ran it across Alan and he thought it looked ok at a glance, but
I agree now that it is integrated in we should take a more involved
look at it.

:...
:[...]
:> +if (strstr(argv[0], "swapon"))
:> +which_prog = SWAPON;
:> +else if (strstr(argv[0], "swapoff"))
:> +which_prog = SWAPOFF;
:
:It's probably better to do a strcmp on strrchr(argv[0], '/') when
:argv[0] contains a slash.  Otherwise people will wonder why
:swapoff(8) breaks when they (perhaps mistakenly) compile and run
:it from the src/sbin/swapon directory.

Hmm.  How about a strstr on a strrchr.   I don't like making exact
comparisons because it removes flexibility that someone might want
in regards to hardlinks (for example, someone might want to add a
version or other suffix to differentiate certain binaries in a test
environment or in an emulation environment).  e.g. bsdswapon vs
swapon.

Isn't there a shortcut procedure to handle the NULL return case?  
I know there is one for a forward scan.  I thought there was one for
the reverse scan too.

if ((ptr = strrchr(argv[0], '/')) == NULL)
ptr = argv[0];
if (strstr(ptr, "swapon")) 
...

:> +if (which_prog == SWAPCTL) {
:> +doall = 1;
:> +which_prog = SWAPON;
:> +} else {
:> +usage();
:> +}
:> +break;
:[...]
:
:The repeated 'whichprog == foo' tests can be combined into a
:single test at the end of the loop.

They do subtly different things so I am not sure what you mean. 
You need to provide some code here.

:> -
:> +
:
:?

It's probably a space or a tab.  I'll track it down.

-Matt
Matthew Dillon 
<[EMAIL PROTECTED]>

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

Re: patch #3 Re: swapoff code comitted.

[Matthew Dillon]

:
:On Wed, 18 Dec 2002, Matthew Dillon wrote:
:
:> Here's another update.  I cleaned things up even more, add BLOCKSIZE
:> support, and updated the manual page.  It looks quite nice now.
:
:I still dislike it.  It starts by adding style bugs to the Makefile
:(changing "=" to "+=" for the initial assignments to LINKS and MLINKS)
:and doesn't get any better.
:
:Bruce

It hasn't been committed yet so please feel free to email me 
patches for stylistic issues over the next day or two.

In regards to having a swapctl command at all, I think anything
that offers familiarity between the BSDs is a good thing to have.
If anything we should remove 'swapinfo'.  'pstat -s' is actually
shorter and easier to type :-)

-Matt
Matthew Dillon 
<[EMAIL PROTECTED]>

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

GEOM panic

[Craig Rodrigues]

Hi,

I just did a cvsup and rebuilt my kernel, and now my kernel
panics upon bootup.  I don't have a serial console, so I wrote
down the error messages that I saw:

I saw this one in the middle of some GEOM debug statements:
ar: FreeBSD check1 failed

Further along I saw:

Lock GEOM topology not exclusively locked @ /usr/src/sys/geom/geom_slice.c:303
Lock GEOM topology not exclusively locked @ /usr/src/sys/geom/geom_subr.c:176
Lock GEOM topology not exclusively locked @ /usr/src/sys/geom/geom_event.c:279
GEOM: configure da0s5, start 31744 length 63107072 end 6318815
Lock GEOM topology not exclusively locked @ /usr/src/sys/geom/geom_mbr.c:405
panic: Assertion sx->sx_cnt == -1 failed at /usr/src/sys/kern/kern_sx.c:242

A stacktrace in ddb shows:

panic()
_sx_unlock()
gc_mbrext_taste
g_do_event()
one_event()
g_run_events()
g_event_procbody()
fork_exit()
fork_trampoline()

The versions of some of the GEOM files in question:

 $FreeBSD: src/sys/geom/geom_slice.c,v 1.32 2002/12/17 21:31:58 phk Exp $
 $FreeBSD: src/sys/geom/geom_subr.c,v 1.24 2002/12/16 22:33:27 phk Exp $
 $FreeBSD: src/sys/geom/geom_event.c,v 1.15 2002/11/04 09:31:02 phk Exp $
 $FreeBSD: src/sys/geom/geom_mbr.c,v 1.28 2002/12/17 09:44:10 phk Exp $


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

Eat pizza and lose weight

[daegs]

Hello !

If you're like me, you've tried EVERYTHING to lose
weight.  I know how you feel - the special diets,
miracle pills, and fancy exercise equipment never helped
me lose a pound either.  It seemed like the harder I tried,
the bigger I got, until I heard about a product called
Power Diet Plus.

You're probably thinking to yourself, "Oh geez, not another
miracle diet pill!"  Like you, I was skeptical at first, but 
my sister swore it helped her lose 23 pounds in just two weeks, 
so I told her I'd give it a shot.  I mean, there was nothing 
to lose except a lot of weight!  Let me tell you, it was
the best decision I've ever made. Period.  Six months later,
as I'm writing this message to you, I've gone from 355 pounds
to 210 pounds, and I haven't changed my exercise routine or diet
at all.  Yes, I still eat pizza, and lots of it!

I was so happy with the results that I contacted the manufacturer
and got permission to resell it - at a BIG discount.  I want
to help other people lose weight like I did, because it
does so much for your self-esteem, not to mention your health.
I give you my personal pledge that Power Diet Plus
absolutely WILL WORK FOR YOU.  If it doesn't, you can return it
any time for a full refund.

If you are frustrated with trying other products, not having 
any success, and just not getting the results you were promised,
then I recommend the only product that worked for me - POWER DIET
PLUS.

You're probably asking yourself, "Ok, so how does this stuff
actually work?"

Power Diet Plus contains Lipotropic fat burners which are 
scientifically proven to increase metabolism and cause rapid 
weight loss. No "hocus pocus" in these pills - just RESULTS, RESULTS, 
RESULTS!! 

Here is the bottom line ...

I can help you lose 10-15 pounds per week naturally, without
exercising and without having to eat rice cakes all day.  
Just try it for one month - there's nothing to lose, and everything 
to gain.  You will lose weight fast - GUARANTEED.  That is my
pledge to you.  

To order Power Diet Plus on our secure server, just click
on the link below:

http://www.cbphost.net/webuser/qse/powerorder.htm

If our main webpage is unavailable, please order from our backup site
by clicking below:
http://coprohgh.diy.163.com/images/powerorder.htm

To see what some of our customers have said about this product, 
visit http://www.cbphost.net/webuser/qse/testimonials.htm

To see a list of ingredients and for more information
on test studies and how it will help you lose weight, visit 
http://www.cbphost.net/webuser/qse/howitworks.htm


0255TQKi4-872gRYG1045Jfvg8-771hWUH5689jcCY2-681aFYq3732HLPk7-476uusD1l65

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

Frequent lockups with SMP and heavy NFS access

[Greg 'groggy' Lehey]

I've been experiencing a lot of lockups (system completely dead, no
reaction at the keyboard, can't ping) on an Intel SMP machine running
CURRENT.  Normally I do my kernel builds over NFS, but in the last few
months I haven't been able to complete a 'make world'.  Along with
-DNOCLEAN I can get a build done in about 4 attempts; local builds
work fine.  NFS builds also work fine with other single processor
machines.

Questions:

1.  Has anybody else seen this?
2.  How should I approach looking for the problem?

Greg
--
See complete headers for address and phone numbers

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

Re: Frequent lockups with SMP and heavy NFS access

[Greg 'groggy' Lehey]

On Wednesday, 18 December 2002 at 22:36:08 -0600, Dan Nelson wrote:
> In the last episode (Dec 19), Greg 'groggy' Lehey said:
>> I've been experiencing a lot of lockups (system completely dead, no
>> reaction at the keyboard, can't ping) on an Intel SMP machine running
>> CURRENT.  Normally I do my kernel builds over NFS, but in the last
>> few months I haven't been able to complete a 'make world'.  Along
>> with -DNOCLEAN I can get a build done in about 4 attempts; local
>> builds work fine.  NFS builds also work fine with other single
>> processor machines.
>>
>> Questions:
>>
>> 1.  Has anybody else seen this?
>> 2.  How should I approach looking for the problem?
>
> I've seen intermittent lockups where everything is dead, but I can
> break into DDB via serial console.  They may be NFS-related, as it
> often crashes a half-hour before I get in to work, which could be due
> to co-workers trying to bulid from my NFS-exported ports tree.  ps
> inside DDB doesn't show anything obviously wrong to my untrained eyes.

Well, then at least you can get a dump and others can look.  In my
case, the machine is completely catatonic.

Greg
--
See complete headers for address and phone numbers

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

Re: Kernel hangs during boot (new GEOM problem)

[walt]

walt wrote:


I built world+kernel about an hour ago ( Dec 17 about 23:00 UTC)
and the kernel hangs in the middle of printing phk's GEOM diagnostics:




I noticed some GEOM-related commits in today's cvsup, but unfortunately
they didn't solve this problem.  The kernel still hangs before printing
any of the geom diagnostics for the 2nd IDE drive, and responds only to
the hard reset button.

Meanwhile I'm running with NO_GEOM.

I'd be happy to do any diagnostic tests that might be helpful, but I'm
new to kernel debugging so I'd need some fairly detailed hints first.


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

Re: Frequent lockups with SMP and heavy NFS access

[Dan Nelson]

In the last episode (Dec 19), Greg 'groggy' Lehey said:
> I've been experiencing a lot of lockups (system completely dead, no
> reaction at the keyboard, can't ping) on an Intel SMP machine running
> CURRENT.  Normally I do my kernel builds over NFS, but in the last
> few months I haven't been able to complete a 'make world'.  Along
> with -DNOCLEAN I can get a build done in about 4 attempts; local
> builds work fine.  NFS builds also work fine with other single
> processor machines.
> 
> Questions:
> 
> 1.  Has anybody else seen this?
> 2.  How should I approach looking for the problem?

I've seen intermittent lockups where everything is dead, but I can
break into DDB via serial console.  They may be NFS-related, as it
often crashes a half-hour before I get in to work, which could be due
to co-workers trying to bulid from my NFS-exported ports tree.  ps
inside DDB doesn't show anything obviously wrong to my untrained eyes.

-- 
Dan Nelson
[EMAIL PROTECTED]

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

Re: GEOM panic

[phk]

In message <[EMAIL PROTECTED]>, Craig Rodrigues writes:
>Hi,
>
>I just did a cvsup and rebuilt my kernel, and now my kernel
>panics upon bootup.  I don't have a serial console, so I wrote
>down the error messages that I saw:
>
>I saw this one in the middle of some GEOM debug statements:
>ar: FreeBSD check1 failed

Can you try this patch please ?

Index: geom_mbr.c
===
RCS file: /home/ncvs/src/sys/geom/geom_mbr.c,v
retrieving revision 1.28
diff -u -r1.28 geom_mbr.c
--- geom_mbr.c  17 Dec 2002 09:44:10 -  1.28
+++ geom_mbr.c  19 Dec 2002 06:22:00 -
@@ -393,6 +397,7 @@
g_mbr_print(1, dp + 1);
if ((dp[0].dp_flag & 0x7f) == 0 &&
 dp[0].dp_size != 0 && dp[0].dp_typ != 0) {
+   g_topology_lock();
g_slice_config(gp, slice, G_SLICE_CONFIG_SET,
(((off_t)dp[0].dp_start) << 9ULL) + off,
((off_t)dp[0].dp_size) << 9ULL,
-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

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

i386 tinderbox failure

[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/i386/obj/local0/scratch/des/src/i386/usr/include
--
>>> stage 4: building libraries
--
>>> stage 4: make dependencies
--
>>> stage 4: building everything..
--
>>> Kernel build for GENERIC started on Wed Dec 18 21:36:06 PST 2002
--
>>> Kernel build for GENERIC completed on Wed Dec 18 22:27:42 PST 2002
--
>>> Kernel build for LINT started on Wed Dec 18 22:27:42 PST 2002
--
===> vesa
"Makefile", line 5401: warning: duplicate script for target "geom_bsd.o" ignored
"Makefile", line 5404: warning: duplicate script for target "geom_mbr.o" ignored
/local0/scratch/des/src/sys/contrib/dev/acpica/dbdisply.c:131: warning: `_THIS_MODULE' 
defined but not used
/local0/scratch/des/src/sys/contrib/dev/acpica/dbexec.c:124: warning: `_THIS_MODULE' 
defined but not used
/local0/scratch/des/src/sys/contrib/dev/acpica/dbhistry.c:124: warning: `_THIS_MODULE' 
defined but not used
/local0/scratch/des/src/sys/contrib/dev/acpica/dbinput.c:125: warning: `_THIS_MODULE' 
defined but not used
/local0/scratch/des/src/sys/contrib/dev/acpica/dbstats.c:125: warning: `_THIS_MODULE' 
defined but not used
/local0/scratch/des/src/sys/contrib/dev/acpica/dbxface.c:127: warning: `_THIS_MODULE' 
defined but not used
/local0/scratch/des/src/sys/contrib/dev/acpica/hwgpe.c:122: warning: `_THIS_MODULE' 
defined but not used
/local0/scratch/des/src/sys/contrib/dev/acpica/hwregs.c: In function 
`AcpiGetSleepTypeData':
/local0/scratch/des/src/sys/contrib/dev/acpica/hwregs.c:242: warning: cast discards 
qualifiers from pointer target type
/local0/scratch/des/src/sys/contrib/dev/acpica/nsxfname.c:125: warning: `_THIS_MODULE' 
defined but not used
/local0/scratch/des/src/sys/contrib/dev/acpica/nsxfobj.c:126: warning: `_THIS_MODULE' 
defined but not used
/local0/scratch/des/src/sys/contrib/dev/acpica/rsdump.c:124: warning: `_THIS_MODULE' 
defined but not used
/local0/scratch/des/src/sys/contrib/dev/acpica/utclib.c:129: warning: `_THIS_MODULE' 
defined but not used
/local0/scratch/des/src/sys/contrib/dev/acpica/utdebug.c:122: warning: `_THIS_MODULE' 
defined but not used
/local0/scratch/des/src/sys/contrib/dev/acpica/utglobal.c: In function 
`AcpiUtGetRegionName':
/local0/scratch/des/src/sys/contrib/dev/acpica/utglobal.c:482: warning: cast discards 
qualifiers from pointer target type
/local0/scratch/des/src/sys/contrib/dev/acpica/utglobal.c: In function 
`AcpiUtGetEventName':
/local0/scratch/des/src/sys/contrib/dev/acpica/utglobal.c:520: warning: cast discards 
qualifiers from pointer target type
/local0/scratch/des/src/sys/contrib/dev/acpica/utglobal.c: In function 
`AcpiUtGetTypeName':
/local0/scratch/des/src/sys/contrib/dev/acpica/utglobal.c:590: warning: cast discards 
qualifiers from pointer target type
/local0/scratch/des/src/sys/contrib/dev/acpica/utglobal.c:593: warning: cast discards 
qualifiers from pointer target type
/local0/scratch/des/src/sys/dev/acpica/acpi_acad.c:50: warning: `_THIS_MODULE' defined 
but not used
/local0/scratch/des/src/sys/dev/acpica/acpi_cmbat.c:56: warning: `_THIS_MODULE' 
defined but not used
/local0/scratch/des/src/sys/dev/acpica/acpi_powerres.c:272: warning: 
`acpi_pwr_deregister_consumer' defined but not used
/local0/scratch/des/src/sys/dev/acpica/acpi_powerres.c:210: warning: 
`acpi_pwr_deregister_resource' defined but not used
/local0/scratch/des/src/sys/dev/ie/if_ie.c: In function `ieattach':
/local0/scratch/des/src/sys/dev/ie/if_ie.c:778: warning: assignment discards 
qualifiers from pointer target type
/local0/scratch/des/src/sys/dev/ie/if_ie.c: In function `ieget':
/local0/scratch/des/src/sys/dev/ie/if_ie.c:1147: warning: passing arg 1 of `bcopy' 
discards qualifiers from pointer target type
/local0/scratch/des/src/sys/dev/ie/if_ie.c:1237: warning: passing arg 1 of `bcopy' 
discards qualifiers from pointer target type
/local0/scratch/des/src/sys/dev/ie/if_ie.c:1237: warning: passing arg 2 of `bcopy' 
discards qualifiers from po