RE: new panic from fresh current (SMP)

[Martin Blapp]

Hi,

It seems to be fixed now with v 1.97 from 
/usr/src/sys/i386/i386/mp_machdep.c

thanks !



To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Re: kernel size over the last week

[Chris Costello]

On Tue, Apr 13, 1999, Snob Art Genre wrote:
> On Tue, 13 Apr 1999, Chris Costello wrote:
> 
> > On Mon, Apr 12, 1999, Snob Art Genre wrote:
> > > I just built a kernel, from sources cvsupped last night.  It's over 2
> > > megs in size, compared to 1.3 megs for a kernel built from the same
> > > config file four days ago.
> > 
> >Were there any drastic configuration differences?  It seems to
> > me that egcs binaries are a bit larger as far as file size goes,
> > but my size change went from about 1.1-1.3 MB to about 1.7 MB.
> 
> We were using egcs four days ago, weren't we?  Anyway, no, there were no
> configuration differences.

   We have been using egcs for much longer.  This is the end of
the second week.

   As I explained above, it's because egcs makes bigger binaries.

-- 
Chris Costello

Beware of programmers who carry screwdrivers.  - Leonard Brandwein


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Re: cvsup

[Matthew D. Fuller]

On Mon, Apr 12, 1999 at 10:52:52PM -0700, a little birdie told me
that John Polstra remarked
> 
> Also, try the "-s" option.  (Read about it first in cvsup(1).)  It
> greatly reduces disk activity and will make your updates go faster,
> possibly with snappier GUI updates too.

Damn, I should RTFM more often  ;)
I could definately like this.


> The GUI performance varies widely between systems.  It was so-so
> on my old P/90, but it's pretty good on my PII/400.  It may be the
> disk activity that kills the GUI performance.  Disk operations are
> non-interruptible, so if the disk is really busy the GUI thread
> doesn't get control often enough.  (I'm guessing and could be totally
> wrong, though.)

As a data point, CVSup runs nicely, but if I iconify it and deiconify it,
it takes about forEVER (maybe 10, 15 seconds on a PPro 180) to redisplay
itself completely.  Sucking down CVS repo to /usr/cvs (async, noatime).
Under 2.2-S, mind you.



---

*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
| Matthew Fuller  http://www.over-yonder.net/ |
* fulle...@futuresouth.com   fulle...@over-yonder.net *
| UNIX Systems Administrator  Specializing in FreeBSD |
*   FutureSouth Communications   ISPHelp ISP Consulting   *
|  "The only reason I'm burning my candle at both ends,   |
*is because I haven't figured out how to light the*
| middle yet" |
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Re: ftp hangs on -current

[Chris Costello]

On Wed, Apr 7, 1999, Gianmarco Giovannelli wrote:
> 
> "ftp" on 4.0-very-current (post egcs make world) randomly hangs during
> sessions...
> I never succeded in finishing a session lately. 
> To transfer some files from my home to my isp server I had to do an "ftp"
> from the server and a "get" to them...

   I don't know if this is proper behavior or not.  I get this
problem when sending an ABRT and the server doesn't respond
(because it's a broken Windows FTPd, usually) or when I'm on a
generally _bad_ route to that particular system.

   I'm not sure if it works, but I'll investigate into it:
Perhaps a test to see if read/write failed with errno = EINTR -
if it is EINTR, close() the socket and sit at the prompt, or
perhaps just exit.

   Any opinions?

-- 
Chris Costello

Bad command or file name.  Go stand in the corner.


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Re: cvsup

[John Polstra]

In article <199904121820.uaa09...@wurzelausix.cs.uni-sb.de>,
Thomas Schuerger   wrote:
> 
> Is there any way to make cvsup update its GUI properly? The window
> is almost dead when cvsup is performing updates, e.g. cvsup will update
> the window's contents very infrequently, which is rather anoying. Perhaps
> it would be a good idea to put GUI handling into a separate thread.

It _is_ in a separate thread.  You just need a faster CPU, or SCSI
disks. :-) Running FreeBSD-3.1 with soft-updates enabled might help.

Also, try the "-s" option.  (Read about it first in cvsup(1).)  It
greatly reduces disk activity and will make your updates go faster,
possibly with snappier GUI updates too.

The GUI performance varies widely between systems.  It was so-so
on my old P/90, but it's pretty good on my PII/400.  It may be the
disk activity that kills the GUI performance.  Disk operations are
non-interruptible, so if the disk is really busy the GUI thread
doesn't get control often enough.  (I'm guessing and could be totally
wrong, though.)

John
-- 
  John Polstra   j...@polstra.com
  John D. Polstra & Co., Inc.Seattle, Washington USA
  "Self-interest is the aphrodisiac of belief."   -- James V. DeLong


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Re: DoS from local users (fwd)

[Chris Costello]

On Sat, Apr 10, 1999, Matthew Dillon wrote:
> :Sun has a product for this, Solaris Resource Manager.
> 
> ... and if one user is *supposed* to be running all those processes, then
> what?  Oh, let me guess:  Now you are supposed to tune each user's account
> independantly.  For a system with general user accounts, this is a burden
> on the sysop.

   You don't need to tune user accounts, you need only put the
users in a separate login class (if that hasn't already been
done) and modify the resource limitation for that login
restriction.

> If one can't control one's users, one has no business managing them.  The
> last thing FreeBSD needs is some overly complex, sophisticated scheduler
> designed to help bozo sysops stay on their feet.

   I agree with you very much here.  Public shell systems are a
bad idea.  In my opinion, you should trust someone before you
allow them to have an account on your system.

>   -Matt
>   Matthew Dillon 
>   

-- 
Chris Costello

Computers talk to each other worse than their designers do.


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Re: kernel size over the last week

[Chris Costello]

On Mon, Apr 12, 1999, Snob Art Genre wrote:
> I just built a kernel, from sources cvsupped last night.  It's over 2
> megs in size, compared to 1.3 megs for a kernel built from the same
> config file four days ago.  Is this due to the change in the debugging
> symbol policy?  file(1) reports both kernels as 'ELF 32-bit LSB
> executable, Intel 80386, version 1 (FreeBSD), dynamically linked, not
> stripped'.

   Were there any drastic configuration differences?  It seems to
me that egcs binaries are a bit larger as far as file size goes,
but my size change went from about 1.1-1.3 MB to about 1.7 MB.

>  Ben
> 
> "You have your mind on computers, it seems." 

-- 
Chris Costello

It's redundant!  It's redundant!-R. E. Dundant


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Re: SMP broken in -CURRENT?

[William S. Duncanson]

That fixes it, thanks.

At 04:13 4/13/99 +0200, tor.e...@fast.no wrote:
>> I haven't been able to get a working SMP kernel out of -CURRENT recently.
>> I don't know exactly when it broke, because I usually rebuild on a weekly
>> basis.  The kernel hangs after:
>> APIC_IO: Testing 8254 interrupt delivery
>> and doesn't ever come back (panic or otherwise).
>> 
>> The one thing that I noticed is that on the older kernels, CPU#1 is
>> launched after the APIC_IO Testing and Routing.  On the newer kernels,
>> CPU#1 is launched far earlier.
>> 
>> Anybody have any ideas?
>
>You might want to try this patch, which disables the early start of CPU#1.
>
>Index: mp_machdep.c
>===
>RCS file: /home/ncvs/src/sys/i386/i386/mp_machdep.c,v
>retrieving revision 1.96
>diff -u -r1.96 mp_machdep.c
>--- mp_machdep.c   1999/04/11 00:43:43 1.96
>+++ mp_machdep.c   1999/04/13 02:08:54
>@@ -1930,9 +1930,11 @@
>   for (i = 0; i < mp_ncpus; i++) {
>   bcopy( (int *) PTD + KPTDI, (int *) IdlePTDS[i] + KPTDI, NKPDE 
> * sizeof 
>(int));
>   }
>+#if 0
>   wait_ap(100);
>   if (smp_started == 0)
>   printf("WARNING: Failed to start all APs\n");
>+#endif
> 
>   /* number of APs actually started */
>   return mp_ncpus - 1;
>
>
>
>
>To Unsubscribe: send mail to majord...@freebsd.org
>with "unsubscribe freebsd-smp" in the body of the message


William S. Duncanson  cae...@starkreality.com
The driving force behind the NC is the belief that the companies who brought us
things like Unix, relational databases, and Windows can make an appliance that
is inexpensive and easy to use if they choose to do that.  -- Scott Adams 


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

CVSUP, Make World, Patch mp_machdep.c, Make Kernel Works

[Thomas Dean]

I am running 4.0-current SMP, as of an hour ago, cvsup about noon,
today.

I have been holding off, watching the egcs development.

It all works.  egcs all appears to work, I rebuilt some applications.

I did a cvsup, make world, and, after applying the patch to delay
starting cpu#1, built a kernel and it all works.

I tried building a kernel before I applied the patch and the hang
problem was there.

Great job in getting it all together.

Now, to rebuild 37 ports!

Thanks, core team

tomdean


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Re: SMP broken in -CURRENT?

[Tor . Egge]

> I haven't been able to get a working SMP kernel out of -CURRENT recently.
> I don't know exactly when it broke, because I usually rebuild on a weekly
> basis.  The kernel hangs after:
> APIC_IO: Testing 8254 interrupt delivery
> and doesn't ever come back (panic or otherwise).
> 
> The one thing that I noticed is that on the older kernels, CPU#1 is
> launched after the APIC_IO Testing and Routing.  On the newer kernels,
> CPU#1 is launched far earlier.
> 
> Anybody have any ideas?

You might want to try this patch, which disables the early start of CPU#1.

Index: mp_machdep.c
===
RCS file: /home/ncvs/src/sys/i386/i386/mp_machdep.c,v
retrieving revision 1.96
diff -u -r1.96 mp_machdep.c
--- mp_machdep.c1999/04/11 00:43:43 1.96
+++ mp_machdep.c1999/04/13 02:08:54
@@ -1930,9 +1930,11 @@
for (i = 0; i < mp_ncpus; i++) {
bcopy( (int *) PTD + KPTDI, (int *) IdlePTDS[i] + KPTDI, NKPDE 
* sizeof (int));
}
+#if 0
wait_ap(100);
if (smp_started == 0)
printf("WARNING: Failed to start all APs\n");
+#endif
 
/* number of APs actually started */
return mp_ncpus - 1;




To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Further on tape & CAM problems

[Stephen Hocking-Senior Programmer PGS Tensor Perth]

When the tape hangs with an unkillable process, its relevant PS flags are 
"physstrat" and "DL+". It doesn't hang forever, just a very long time, like 
someone's confused milliseconds with microseconds, or some such.


Also, when writing to the 2nd tape in a CPIO archive, it doesn't actually 
write to the tape. systat -vmstat records lots of stuff going to the tape 
device (a SCSI QIC-525 in this case) very quickly - way beyond the speed it 
can actually do but there's no actual activity. Dump on the otherhand seems 
fine.


Stephen
-- 
  The views expressed above are not those of PGS Tensor.

"We've heard that a million monkeys at a million keyboards could produce
 the Complete Works of Shakespeare; now, thanks to the Internet, we know
 this is not true."Robert Wilensky, University of California




To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

SMP broken in -CURRENT?

[William S. Duncanson]

I haven't been able to get a working SMP kernel out of -CURRENT recently.
I don't know exactly when it broke, because I usually rebuild on a weekly
basis.  The kernel hangs after:
APIC_IO: Testing 8254 interrupt delivery
and doesn't ever come back (panic or otherwise).

The one thing that I noticed is that on the older kernels, CPU#1 is
launched after the APIC_IO Testing and Routing.  On the newer kernels,
CPU#1 is launched far earlier.

Anybody have any ideas?

On a side note, the pn0 driver appears to be broken (uniprocessor kernels
will boot, the pn0 device shows up, and is ifconfig'd, but there's no link
light on it.  It works fine with older (04/04/99) kernels).


William S. Duncanson  cae...@starkreality.com
The driving force behind the NC is the belief that the companies who brought us
things like Unix, relational databases, and Windows can make an appliance that
is inexpensive and easy to use if they choose to do that.  -- Scott Adams 


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Re: cvs commit: sys/pci pci.c

[Alfred Perlstein]

On Mon, 12 Apr 1999, Doug Rabson wrote:

> On Mon, 12 Apr 1999, Alfred Perlstein wrote:
> 
> > The problem that i faced was that the console stuff must be done even
> > before the SYSINITs are done it's generally setup from machdep.c this
> > is before a lot of stuff is really setup.
> > 
> > How early can i expect this framework to be in place so i can attach
> > a console bus/device or does it seem i have to hack this somehow?
> > 
> > What i'm planning on is a way to modularize the console code enough
> > so that during runtime the console can be moved from device to device
> > and even support a forked console (i/o on both sio and sc) revoking
> > a console and a split console (input serial, output syscons).
> 
> That sounds very worthwhile. While you are at it, can you try to factor
> out the common code from the i386 and alpha ports so that both can use the
> new mechanism.

I will try to, something i also wonder, why is there seperate sio.c
for each port? it seems like a lot of the isa stuff is duplicated
across each port making it hard to actually do this correctly.

hopefull the new stuff going into the bus code will help this, i know
drowning the code in #ifdef __alpha__/__i386__/etc is pretty nasty
but trying to keep 3 sio.c and i presume more if the other arch ports
in the works have the same isa device as even more difficult.

the seperate i386/cons.c and such will be put into an arch independant
form and i will impelement a spec to follow to be a console device.

I will bring sio and syscons on i386 into this model and i hope developers
with pc98 and alpha equip can move to it as well.

> > btw, i'm not familiar with the proper way to use this list, am i generating
> > noise by cc'ing the list or is that the proper way, or should move 
> > messages like this to -current?
> 
> This is possibly material for the current list (although personally I
> don't mind reading it here).

moved to -current :)

-Alfred



To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Re: About that 'new-bus' stuff.

[Jordan K. Hubbard]

Thank you very much for this summary!  Like most people, I don't think
this is a political issue between new-bus and newconfig, it's simply
what we've already got on the Alpha and now need to bring to the x86
 for consistency's sake.

I also suspect that once this code is in -current, and I'd personally
like to see that happen, what eventually evolves from it will probably
represent the best of both newconfig and new-bus, it being the nature
of software to constantly change. :)

- Jordan


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Re: About that 'new-bus' stuff.

[Justin T. Gibbs]

>In message <19990412175644.7de5f1...@spinner.netplex.com.au> Peter Wemm writes
>:
>:   to being able to use their drivers with less hassles.  (There will be
>:   enough fun due to differences in bus_space and bus_dma, but that's
>:   another issue)
>
>I know that many people would like to see bus_space and bus_dma
>reimported from NetBSD.  As far as I know, there is no compelling
>reason to have them be different.

For bus_space, no.  For bus_dma, there are some reasons for them
to be different in one area: the callback mechanism for returning
a valid dma mapping.  The rest of the differences are primarily
from the fact that NetBSD has enhanced or modified their interfaces
since my original work and I haven't found the time to sync us back
up.

>Warner

--
Justin




To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

new panic from fresh current (SMP)

[Martin Blapp]

aeh - forgot to say ... it is reproducable - it can't boot
And the kernel-gdbtrace isn't very useful :(

Martin



To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Re: AIC

[Nik Clayton]

On Sun, Apr 11, 1999 at 11:29:09AM -0500, Bob Willcox wrote:
> On Wed, Mar 31, 1999 at 12:28:47PM -0800, Brian Beattie wrote:
> > On Wed, 31 Mar 1999, Warner Losh wrote:
> > > The aic driver will likely oneday be ported.  However, no one has come
> > > forward to do it.  It is a highly desirable driver to have (even if
> > 
> > Umm, I'm still working on the aic driver.  Slowly, but working on it.
> > 
> > > writing it would be a pain) because the only pccard scsi cards that are
> > > out there are aic-6[23]60 based.
> > > 
> > 
> > Not having a pcmcia slot or card, I am not sure about support for this.
> 
> I have both and would be willing to test it on my laptop.

If you need a desktop tester of the new AIC driver, give me a shout. 
Upgrading to 3.0 broke my CDROM and internal Zip drive :-(

N
-- 
Bagel: The carbohydrate with the hole


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

new panic from fresh current (SMP)

[Martin Blapp]

But it's not related to that caused by the NMI,
and it appears suddenly after probing soerens
ATAPI drivers. hmm - SMP: AP CPU #1 Launched!
does not appear ... what this ever means.

the previos kernel as of yesterday had:

IP Filter: initialized.  Default = pass all, Logging = disabled
SMP: AP CPU #1 Launched!   
acd0:  CDROM drive at ata0 as master
acd0: drive speed 5512KB/sec, 256KB cache
acd0: supported read types: CD-R, CD-RW, CD-DA
acd0: Audio: play, 255 volume levels
acd0: Mechanism: ejectable tray
acd0: Medium: no/blank disc inside, unlocked
afd0:  rewriteable drive at ata0 as slave
afd0: 96MB (196608 sectors), 32 cyls, 64 heads, 96 S/T, 512 B/S
afd0: Unknown media (0x0)
Waiting 5 seconds for SCSI devices to settle

now the panic ...

mp_lock = 011; cpuid = 1; lapic.id = 010
instruction pointer = 0x8:0xc024bfb8
stack pointer   = 0x10:0xff804ff8
frame pointer   = 0x10:0x0
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, IOPL = 0
current process = Idle
interrupt mask  = <- SMP: XXX
kernel: type 29 trap, code=0
Stopped at  default_halt:   ret
db>

no trace

Martin



To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

/usr permissions after upgrade

[Valentin Shopov]

After upgrade to 4.0-CURRENT ,
/usr permissions are 777, owner.group is bin.bin.
In my case I don't have separated fs for /usr, /var,
etc.,, so /usr is in root fs.

Val



_
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com



To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Re: have live system with NFS client cache problems what do i do?

[Alfred Perlstein]

On Mon, 12 Apr 1999, Maxim Sobolev wrote:

> Alfred Perlstein wrote:
> 
> > Hey, i was just doing a kernel compile over NFS and i have a weird
> > situtation.  After compiling everything the linker barfs on linking.
> >
> > gensetdefs: cd9660_bmap.o: not an ELF file
> >
> > for about 12 files...
> >
> > the compile is being done on a laptop that has my desktop's src dir
> > NFS mounted.
> >
> Hey I have pretty the same problems on my 4.0 cvsup'ed and builded few
> days ago!
> 
> As NFS server I have 3.1-stable box. 

Let's try to figure out some other commonalities to assist debugging this.  
can you please fill this in:

   Me  You   
Server version 4.0-apr6th   3.1- ???   
 Netcard   pn0 ??
 local diskda
 options   softupdates
 nfsd? yes
 ram   32meg

Client version 4.0-apr9th   4.0- ???
 Netcard   ep0 3comIII pcmcia
 local diskwd
 options   softupdates
 nfsioddon't think so
 ram   48meg

Mount type:mount server:/usr/src
/usr/src

how bugbuild kernel in
happened:  NFS mounted /usr/src
   make depend && make -j6 all

bug:   client sees files are filled
   with zeros, but server has 
   non-corrupted files

   will not link on client
   links fine on server
   if the files are copied from
   the NFS mount to local disk
   they "un-corrupt" themselves.

well?  I'm tempted to blame the 3com, but that doesn't make sense
as when you copy to local disk the files seem to become normal again...

-Alfred




To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Re: we still have NFS problems in -current?

[Matthew Dillon]

:> 
:> I found it.  The problem was introduced when we committed the
:> mmap() zero-invalid-areas patch.  !...@#$@#$#$%...@%@#%#@  NFS is such
:> a fragile piece of junk!
:
:Why do you say that? :-)

What it come down to is that due to the way m->valid is set, it is possible
for mmap() to believe that a page is entirely valid when, in fact, it
isn't, because partial NFS I/O must set the valid and dirty bits in the
vm_page_t 'inclusively'.

So, for example, if a page contains valid data from offsets 130-4095,
vm_page_t->valid will still be VM_PAGE_BITS_ALL ( 0xFF ) rather then 0xFE.

This causes mmap() to believe that the page is entirely valid when it
isn't.

Before we zerod out invalid areas the 'stale' data from a prior partial
write, e.g. say a write from offset 0 through 120, would stick around in
the buffer.  Hence, no crash.

Now the data doesn't necessarily stick around.  The write is committed,
the valid bit is clear, the new write to offsets 130-4095 sets the valid
bits again and clears the 'stale' data.

I'm working on a patch.  Sigh.  I think we may have to implement a
'completely valid' flag for vm_page_t rather then depend on comparing
m->valid against VM_PAGE_BITS_ALL.  What a mess.

For now, turn off the mmap zeroing fix.  The patch is included below.

-Matt
Matthew Dillon 




Index: vm/vm_page.c
===
RCS file: /home/ncvs/src/sys/vm/vm_page.c,v
retrieving revision 1.129
diff -u -r1.129 vm_page.c
--- vm_page.c   1999/04/05 19:38:29 1.129
+++ vm_page.c   1999/04/12 21:22:28
@@ -1491,11 +1491,13 @@
if ((frag = base & ~(DEV_BSIZE - 1)) != base &&
(m->valid & (1 << (base >> DEV_BSHIFT))) == 0
) {
+#if 0
pmap_zero_page_area(
VM_PAGE_TO_PHYS(m),
frag,
base - frag
);
+#endif
}
 
/*
@@ -1509,11 +1511,13 @@
if ((frag = endoff & ~(DEV_BSIZE - 1)) != endoff &&
(m->valid & (1 << (endoff >> DEV_BSHIFT))) == 0
) {
+#if 0
pmap_zero_page_area(
VM_PAGE_TO_PHYS(m),
endoff,
DEV_BSIZE - (endoff & (DEV_BSIZE - 1))
);
+#endif
}
 
/*


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Re: we still have NFS problems in -current?

[Matthew Jacob]

On Mon, 12 Apr 1999, Matthew Dillon wrote:

> :Probably- but this is sure amusing (not!):
> :
> :Compiling a kernel... directory is NFS mounted on a solaris 2.6 machine:
> :
> :
> :
> :cd9660_bmap.o: file not recognized: File format not recognized
> :*** Error code 1
> 
> I found it.  The problem was introduced when we committed the
> mmap() zero-invalid-areas patch.  !...@#$@#$#$%...@%@#%#@  NFS is such
> a fragile piece of junk!

Why do you say that? :-)

Bob Lyon still says:

+Date: Mon, 22 Mar 1999 22:00:47 -0800
+From: Bob Lyon 
+To: mja...@feral.com
+Subject: Re: NFS - Will it ever be fixed?  (fwd)
+
+
+NFS is perfect.  It needs no fixing.  (Unless, we mean
+"fix" as in what we do to dogs.
+
+/Bob


> 
> NFS is doing some illegal shit.  I'll get a patch out ASAP.

Awesome. 






To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Re: we still have NFS problems in -current?

[Matthew Dillon]

:Probably- but this is sure amusing (not!):
:
:Compiling a kernel... directory is NFS mounted on a solaris 2.6 machine:
:
:
:
:cd9660_bmap.o: file not recognized: File format not recognized
:*** Error code 1

I found it.  The problem was introduced when we committed the
mmap() zero-invalid-areas patch.  !...@#$@#$#$%...@%@#%#@  NFS is such
a fragile piece of junk!

NFS is doing some illegal shit.  I'll get a patch out ASAP.

-Matt



To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Re: swap-related problems

[Julian Elischer]

It seems to me that you might kill the forst program the has a lot of ram
in unse that has not specified a limit for itself.. programs that are wel
enough behaved to set a limit for themselves should be rewarded.

just a thought...
julian


On Sun, 11 Apr 1999, Matthew Dillon wrote:

> :I use the memory as soon as it's malloced. If it reserves a page, then
> :pagefaults it into existence, the VM system knows that that page is now
> :allocated. When I malloc the last available page for user use, the VM
> :system knows that it's the last page. I dirty it, and there are none
> :free. If I malloc(), I want to know that there is no more memory, not
> :have my process killed. This is POMA.
> :
> :Previously, the POLA, a NULL getting returned, WORKED CORRECTLY. It did this
> :for a long time. My little test program always showed this, and shows
> :that now something was broken. I'll attach it to the end.
> 
> I ran your program.  malloc() appears to work properly -- returns NULL 
> when
> the datasize limit is reached.  In my case, I set the datasize limit 
> to 64MB and ran the program.
> 
> ...
> mallocs failed at 64956
> 
> Under 4.0-current.
> 
> :> then one or two processes getting killed.  Having N random processes 
> get
> :> malloc() failures can lead to serious instability with processes.
> :
> :Only bad code doesn't check return values of malloc().
> 
> You are volunteering to run through the thousands of programs & ports
> to make sure that every one checks the return value for malloc()?
> 
> Declarations that don't solve problems are not relevant.  It's bad enough
> that we have to kill something to handle an out-of-vm situation, we
> shouldn't go off and destabilize the rest of the system while we are at 
> it.
> 
>   -Matt
> 
> 
> 
> To Unsubscribe: send mail to majord...@freebsd.org
> with "unsubscribe freebsd-current" in the body of the message
> 



To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Re: showing full host names in output from who/finger/last

[David Wolfskill]

>Date: Sun, 11 Apr 1999 19:05:30 -0400 (EDT)
>From: Robert Watson 

>I'd actually like to see wtmp only use IP addresses, never hostnames. 

I would prefer to have that be an installation-selectable option, at
least.

>Spoofed names are fairly easy to arrange; with IP filtering on border
>routers, spoofed IPs are harder.  Besides which, connections are from IPs
>and not names.  :-)  This of course sticks you with the task of DNS
>lookups when viewing wtmp, when you may already have done them at login
>time.  Probably ideally, we'd have two variable length fields, one for a
>network-supplied source, and one for a transformed source such as name,
>display name (:0), etc.  But that requires modifying the record
>format, which is always a pain.

In my case, it's more because I expect the association of hostname <-> IP
address to be rather transient compared to the interval during which the
information might be useful:  although it may be of interest to know what
the hostname was at the time of the original event, it's more likely to
be useful for me to know the IP address at the time.  And merely because
I know one of those *now* doesn't mean that I necessarily know what the
other was *then*.

(And yes, this is more of a concern when investigating such things as
dropped (but logged) ICMP redirects targeted at some of our perimeter
hosts, for example.  I'm rather less concerned within our internal nets.)

Cheers,
david
-- 
David Wolfskill UNIX System Administrator
d...@whistle.comvoice: (650) 577-7158   pager: (650) 371-4621


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

we still have NFS problems in -current?

[Matthew Jacob]

Probably- but this is sure amusing (not!):

Compiling a kernel... directory is NFS mounted on a solaris 2.6 machine:



cd9660_bmap.o: file not recognized: File format not recognized
*** Error code 1

Stop.
quarm.feral.com > file cd9660_bmap.o 
cd9660_bmap.o: MS Windows COFF Unknown CPU
Filesystem 1K-blocks UsedAvail Capacity Mounted on
bird:/src/freebsd-current/src4124565  1602999  248032139% /usr/src
quarm.feral.com > ls -l cd9660_bmap.o 
-rw-rw-r--  1 mjacob  100  890 Apr 12 12:45 cd9660_bmap.o
quarm.feral.com > rcp 
bird:/src/freebsd-current/src/sys/compile/QUARM_CHK/cd9660_bmap.o /tmp
quarm.feral.com > file /tmp/cd9660_bmap.o 
/tmp/cd9660_bmap.o: ELF 32-bit LSB relocatable, Intel 80386, version 1 
(FreeBSD), not stripped
quarm.feral.com > mv cd9660_bmap.o cd9660_bmap.o.SAVE
quarm.feral.com > make cd9660_bmap.o 
cc -c -O -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes  
-Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -fformat-extensions 
-ansi  -nostdinc -I- -I. -I../.. -I../../../include  -DKERNEL -DVM_STACK 
-include opt_global.h -elf  ../../isofs/cd9660/cd9660_bmap.c
quarm.feral.com > file cd9660_bmap.o 
cd9660_bmap.o: ELF 32-bit LSB relocatable, Intel 80386, version 1 (FreeBSD), 
not stripped
quarm.feral.com > cmp cd9660_bmap.o cd9660_bmap.o.SAVE
quarm.feral.com > file !$
file cd9660_bmap.o.SAVE
cd9660_bmap.o.SAVE: ELF 32-bit LSB relocatable, Intel 80386, version 1 
(FreeBSD), not stripped

Hmmm! Ow! Ow! Ow!

FreeBSD quarm.feral.com 4.0-CURRENT FreeBSD 4.0-CURRENT #57: Fri Apr  9 
20:17:57 PDT 1999 
mja...@quarm.feral.com:/freebsd/FreeBSD-current/sys/compile/QUARM  i386

This kernel from sources updated April 9



To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Re: About that 'new-bus' stuff.

[Matthew Jacob]

On Mon, 12 Apr 1999, Doug Rabson wrote:

> On Mon, 12 Apr 1999, Warner Losh wrote:
> 
> > In message <19990412175644.7de5f1...@spinner.netplex.com.au> Peter Wemm 
> > writes:
> > :   to being able to use their drivers with less hassles.  (There will be
> > :   enough fun due to differences in bus_space and bus_dma, but that's
> > :   another issue)
> > 
> > I know that many people would like to see bus_space and bus_dma
> > reimported from NetBSD.  As far as I know, there is no compelling
> > reason to have them be different.
> 
> I don't think there are many differences with bus_space. I don't know
> about bus_dma though.

bus_dma is somewhat different. Justin and Jason have done minor celebrity
deathmatches over this topic :-)...

neither bus_dma nor bus_space are perhaps entirely sufficient in any case.

bus_dma doesn't quite carry enough information along with it to correctly
know whether the memory object being mapped is another device or memory.
It currently can be inferred from the uses of pmap_extract, but
information such as hierarchical constraints (address and access size
limitations) has no context here. This is also a limitation for NetBSD's
bus_dma limitation.

There may be pieces missing from bus_space or another interface needs to
be there. There's a notion of DMA synchronization to ensure coherent
shared views of objects between CPUs and devices, but there isn't a notion
of endian-ness and layout to write such objects- this leads devices to
have to special case on a per-bus/per-architecture basis. 

Both of the above restrictions don't cause problems for simple machines
like workstation Alphas or i386 boxes (well, it does if you wanted to do, 
e.g., PCI<>PCI transactions), but cause tremendous heartburn for
snything more complex machines.

-matt






To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Re: About that 'new-bus' stuff.

[Doug Rabson]

On Mon, 12 Apr 1999, Warner Losh wrote:

> In message <19990412175644.7de5f1...@spinner.netplex.com.au> Peter Wemm 
> writes:
> :   to being able to use their drivers with less hassles.  (There will be
> :   enough fun due to differences in bus_space and bus_dma, but that's
> :   another issue)
> 
> I know that many people would like to see bus_space and bus_dma
> reimported from NetBSD.  As far as I know, there is no compelling
> reason to have them be different.

I don't think there are many differences with bus_space. I don't know
about bus_dma though.

--
Doug Rabson Mail:  d...@nlsystems.com
Nonlinear Systems Ltd.  Phone: +44 181 442 9037




To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Re: About that 'new-bus' stuff.

[Warner Losh]

In message <19990412175644.7de5f1...@spinner.netplex.com.au> Peter Wemm writes:
:   to being able to use their drivers with less hassles.  (There will be
:   enough fun due to differences in bus_space and bus_dma, but that's
:   another issue)

I know that many people would like to see bus_space and bus_dma
reimported from NetBSD.  As far as I know, there is no compelling
reason to have them be different.

Warner


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Re: DoS from local users (fwd)

[Anthony Kimball]

: "What was their user name again?"
: *click xterm click*
: ps aux | grep ^user | wc -l
: "Hmm, you're right, fifty processes called 'cpuwaster'."
: rmuser user
: "They've been eliminated, thank you for letting us know of problems you have!"
:
: It's called "being a sysadmin". If someone's abusing the machine, delete em.

[ Redirected to chat ]

There are several points which I would like to make in response to
this posting.

1) cpuwaster may be solving a significant problem.  One man's
   cpuwaster is another man's breadandbutter.

2) Adding useful new scheduling policy options to the system allows a good
   sysadmin to be a better sysadmin.  That's a Good Thing.
 
3) One man's sysadmin is another man's asshole.  (Made you think,
   didn't I?)








To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Re: have live system with NFS client cache problems what do i do?

[Maxim Sobolev]

Hey I have pretty the same problems on my 4.0 cvsup'ed and builded few
days ago!

As NFS server I have 3.1-stable box. 

Sincerely,

Maxim Sobolev

Alfred Perlstein wrote:

> Hey, i was just doing a kernel compile over NFS and i have a weird
> situtation.  After compiling everything the linker barfs on linking.
>
> gensetdefs: cd9660_bmap.o: not an ELF file
>
> for about 12 files...
>
> the compile is being done on a laptop that has my desktop's src dir
> NFS mounted.
>
> the card in the laptop is a 3comIII and the dekstop a pn0
>
> doing a 'file cd9660_bmap.o' on laptop (NFS client) gives me a
> cd9660_bmap.o: MS Windows COFF Unknown CPU
>
> while on the server:
> strlen.o: ELF 32-bit LSB relocatable, Intel 80386, version 1 (FreeBSD), not 
> stri
>
> it seems my client is having a really tough time with these files, i have
> copied the files that the client has corrupted to localdisk but now
> they seem fine...
>
> the client laptop is unable to link the kernel it's getting tons of
> corrupted data is seems, on the server i am able to link the kernel just
> fine.
>
> i'm using the default NFS mounts and no nfsiod.
>
> enabling nfsiod didn't help, however unmounting the NFS share and
> remounting seems to have fixed it
>
> i guess i should have taken a crash dump when the system was all
> hosed but it's fine now... *sigh*
>
> Alfred Perlstein - Admin, coder, and admirer of all things BSD.
> -- There are operating systems, and then there's FreeBSD.
> -- http://www.freebsd.org/4.0-current
>
> To Unsubscribe: send mail to majord...@freebsd.org
> with "unsubscribe freebsd-current" in the body of the message


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Re: Panic from today's current

[Wilko Bulte]

As Luoqi Chen wrote ...
> > The kernel-configfile and dmesg-output is available from:
> > http://www.attic.ch/fuchur_kernel.html
> > 
> > panic at: generic_bcopy+0x1arepe movsl (%esi), %es:(%edi) 
> > 
> > db> trace
> > generic_bcopy(c02cc380,c7bb9b1f,0,a,0) at generic_bcopy+0x1a
> > sccnputc(cff,1,c7bb9b80,c016c066) at sccnputc+0x180
> > cnputc(a,0,0,a,c7bb9bcc) at cnputc+0x3d
> > putchar(a,c7bb9bf0) at putchar+0xa6
> > kvprintf(c028da63,c016bfc0,c7bb9bf0,a,c7bb9c04) at kvprintf+0x64
> > printf(c028da49,8000,c1159b00,a8,c7bc3e60) at printf+0x3d
> > trap(10,10,a8,c1159b00,c7bb9ce8) at trap+0x462
> > calltrap() at calltrap+0x3c
> > --- trap 0x13, eip = 0xc7bb9c68, ebp = 0xc7bb9ce8 ---
> 
> Trap 19 (0x13) is NMI, this problem doesn't seem to be software related.

NMI.. could be a RAM parity error or somebody/something fooling around
with the IOCHKN line on the ISA bus.

Groeten / Cheers,
Wilko
_ __
 |   / o / /  _ Arnhem, The Netherlands
 |/|/ / / /( (_) Bulte  WWW  : http://www.tcja.nl
___ Powered by FreeBSD ___  http://www.freebsd.org _


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Re: About that 'new-bus' stuff.

[Doug Rabson]

On Tue, 13 Apr 1999, Peter Wemm wrote:

> [...]
> Right now, the core functionality is operating nicely, but there are a few
> key missing bits.  Specifically, wd.c doesn't (and can't) build, it needs
> changes like the fd.c driver.  The ISA PnP and EISA code hasn't been
> updated to use the new interfaces.  (Soren's new ata driver works).  The
> pccard etc driver compiles but has not been updated yet.  The direction
> the pccard stuff will go in isn't clear yet.

I should add that SMP machines will not work with the new-bus repository
just yet since I haven't got my head around the apic interrupt
remapping thing yet.  An SMP machine with a UP kernel would work as a
stopgap.

> 
> Hopefully Doug won't shoot me for misrepresenting something. :-)

Of course not :-)  The only thing I would change in the history is that
the kernel linker work pre-dates the alpha port and that the main reason I
wrote it was to support the new driver model.

--
Doug Rabson Mail:  d...@nlsystems.com
Nonlinear Systems Ltd.  Phone: +44 181 442 9037




To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

kernel size over the last week

[Snob Art Genre]

I just built a kernel, from sources cvsupped last night.  It's over 2
megs in size, compared to 1.3 megs for a kernel built from the same
config file four days ago.  Is this due to the change in the debugging
symbol policy?  file(1) reports both kernels as 'ELF 32-bit LSB
executable, Intel 80386, version 1 (FreeBSD), dynamically linked, not
stripped'.


 Ben

"You have your mind on computers, it seems." 



To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Re: showing full host names in output from who/finger/last

[Robert Watson]

On Mon, 12 Apr 1999, N wrote:

> Hi,
> 
> > I don't use the FreeBSD patched version, as I use the version with the
> > KerberosIV patches (unfortunately the FreeBSD port doesn't do that, but I
> > don't have time just now to make it do that :-). It seems to put the IP
> > address into the wtmp correctly. 
> 
> Are those patches freely available somewhere?

Niels,

Dug Song's kerberosiv patches are available at

http://www.monkey.org/~dugsong/ssh-afs-kerberos.html

He also has various other kerberos patches on his page there.  I submitted
a fix or two a little while ago to correct some problems with multi-homed
hosts.  I imagine they're in there at this point, but I haven't checked.

  Robert N Watson 

rob...@fledge.watson.org  http://www.watson.org/~robert/
PGP key fingerprint: 03 01 DD 8E 15 67 48 73  25 6D 10 FC EC 68 C1 1C

Carnegie Mellon Universityhttp://www.cmu.edu/
TIS Labs at Network Associates, Inc.  http://www.tis.com/
Safeport Network Services http://www.safeport.com/



To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

cvsup

[Thomas Schuerger]

Hi!

Is there any way to make cvsup update its GUI properly? The window
is almost dead when cvsup is performing updates, e.g. cvsup will update
the window's contents very infrequently, which is rather anoying. Perhaps
it would be a good idea to put GUI handling into a separate thread.


Ciao,
Thomas.



To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

About that 'new-bus' stuff.

[Peter Wemm]

As some have become aware, we have created a small sandbox repository
alongside (but seperate to) the main FreeBSD sources.

I've been asked a few times for info on what it is, so here's a quick
summary.  First, the background..

The original 386BSD and FreeBSD configuration interface was purely static.
ie: you filled in your config(8) file, ran config, compiled the kernel and
you were done.  It pretty much supported ISA devices only.  Back then, that
was quite reasonable as the devices stayed put and required a considerable
amount of effort to change.

But it's not 1992 anymore.  That nice cozy picture has changed somewhat.
Now, we've got multi-layer busses and all sorts of dynamic stuff that
changes on the fly (usb, pccard, cardbus being prime examples).  You end up
with scsi controllers on parallel ports, parallel printer bridges on usb,
etc.  As well, nearly all of these devices are self identifying.  PCI, PnP,
EISA etc all carry identification so the configuration can be determined by
asking the device directly.  This does not fit well into our nice static
config system any more.  The average system these days has very few or
perhaps even no devices that require configuration "assistance".

There was also the problem of duplication of information.  Drivers in the
kernel were written to attach to specific busses and the exact same
information had to be duplicated in the user's config file.  Some
alternatives (the original config.new, for example) were worse because they
added another copy - various Makefiles and rule files needed another set of
information to say the same thing again.  (As an aside, NetBSD has done
wonderful things to config.new, but it wasn't the direction we wanted to go).

And then along came the Alpha port.  Rather than being a descendent of the
old way of doing things, it was done from a different direction as it had
no isa-like bus to fight with.  It's configuration system is dynamic and
"hint" based.  The only place that hierarchy is enforced is in the drivers
themselves.  You don't need to duplicate that info in makefiles or config
files.  But you *can* be specific about something if you want.  For
example, if you wanted to wire da2 to a specific LUN on a specific bus on a
specific controller, you could.

And then along came the in-kernel linker.  The old driver mechanism on the
i386 cannot cope with this without serious hackery.  Various people decided
to take a shot at adapting the existing new-bus stuff to the i386.  Well,
it works very well, but isn't quite complete.

Since the people involved were having synchronization problems and having
trouble with large patchsets, we decided to set up a shared repository.
Since the aim was that the i386 port would use this, it was closely linked
with the freebsd repository and shared the same commit messages (the plan
was that the developers would need to know about it and that others who
were watching could see what was going on too).

Anyway, here's the basic objectives:

- remove (entirely) the need for static configuration, but still have
  *explicit* control when and as needed.  If the if_de driver only works
  on a pci bus, then there's no point requiring you to configure it
  specifically to attach to a pci bus in the kernel config file - the
  minimum information required is that you want it. :-)  Obviously an
  if_ed ISA driver needs hints about where to probe, but there is no
  reason why it can't have a built-in set of ports to try if the user
  chooses not to specify one.  Of course, it will use the users settings
  if they are given.

- ultimately, static configuration would be replaced with a boot-time
  dynamic method.  ie: you will be able to specify things like isa IO and
  irq settings in a config file in /boot.  You won't need to recompile to
  adjust the kernel settings, just edit the config file and reboot.

- It may well turn out that even a reboot isn't required and that the
  resources for isa configuration can be changed at runtime and the device
  re-probed with the new settings.

- userconfig would logically move to a fourth script in /boot, if not then
  it would merely be a resource editor.

- full resource management.  There is a single manager for resources like
  ports, interrupts, memory mappings etc.  This replaces the *horrible*
  kludges that try and figure out what's been used at present.

- minimize the disruption and workload for the developers.  Backwards
  compatability shims work quite nicely and old drivers work mostly
  without modifications and interface with the resource manager via the
  shims and new mechanisms.  (we could implement UDI this way!).  No
  bombshells blowing -current out of the water with major loss of
  functionality.

- *full* loadable module support, for all the busses.  (This won't work
  for linker set based drivers obviously, but with some tinkering, an
  isa_device style driver could be made loadable, or preloaded via
  loader(8) at least.)

- drastically reduce the

Re: Bad, reliable crash: Julian's "oltr" stuff & ARP

[Larry Lile]

Just so Julian doesn't get blamed here, I was the one who wrote
the Olicom "oltr" driver and made the arp changes.  Julian was
just nice enough to commit them.

The only thing I can figure, as I can't tell exactly what caused
it to punt, is that you received a token-ring arp packet that is
somewhat damaged.  Is there a token-ring<->ethernet bridge on
your network?  

What was it doing in in_arpinput when it panic'd?

Larry Lile
l...@stdio.com


On Mon, 12 Apr 1999, Ian Pallfreeman wrote:

> My -current trashbox is having some pretty severe problems which seem to
> stem from the token ring additions on March 10th. The box in question 
> wouldn't stay up for more than a few minutes.
> 
> ``savecore'' isn't working for me right now, but I've managed to delete a 
> single line of code which lets the box stay up long enough for me to do a
> make world and get to grips with all this EGCS, uh, fun. This isn't a true
> solution, obviously.
> 
> The ethernet segment to which the box is connected has lots of non-IP traffic
> (DECNET, Novell, etc), but I didn't expect to find token ring stuff on it. :-)
> 
> Ian.
> 
> *** if_ether.c.orig Mon Apr 12 16:11:12 1999
> --- if_ether.c  Mon Apr 12 16:13:22 1999
> ***
> *** 435,442 
>panic("arpintr");
>if (m->m_len >= sizeof(struct arphdr) &&
>(ar = mtod(m, struct arphdr *)) &&
> !   (ntohs(ar->ar_hrd) == ARPHRD_ETHER || 
> !  ntohs(ar->ar_hrd) == ARPHRD_IEEE802) &&
>m->m_len >=
>  sizeof(struct arphdr) + 2 * ar->ar_hln + 2 * ar->ar_pln)
> 
> --- 435,441 
>panic("arpintr");
>if (m->m_len >= sizeof(struct arphdr) &&
>(ar = mtod(m, struct arphdr *)) &&
> !   ntohs(ar->ar_hrd) == ARPHRD_ETHER &&
>m->m_len >=
>  sizeof(struct arphdr) + 2 * ar->ar_hln + 2 * ar->ar_pln)
> 
> 
> Fatal trap 12: page fault while in kernel mode
> fault virtual address   = 0x8
> fault code  = supervisor read, page not present
> instruction pointer = 0x8:0xc017e590
> stack pointer   = 0x10:0xc02248d8
> frame pointer   = 0x10:0xc0224928
> code segment= base 0x0, limit 0xf, type 0x1b
>   = DPL 0, pres type 0x1b
>   = DPL 0, press 1, def32 1, gran 1
> processor eflags= interrupt enabled, resume, IOPL = 0
> current process = Idle
> interrupt mask  = 
> kernel: type 12 trap, code=0
> Stopped at  in_arpinput+0x264:  cmpb$0,0x8(%ecx)
> db> tr
> in_arpinput(c0744100,0,0,c01ee601,c01ee5a3) at in_arpinput+0x264
> arpintr(c01ee5a3,8000,10,10,0) at arpintr+0xb4
> swi_net_next() at swi_net_next
> db> show registers
> cs 0x8
> ds  0x7e8b0010
> es0x10
> ss0x10
> eax  0x600
> ecx  0
> edx  0
> ebx 0xc0a02490
> esp 0xc02255ec  __set_pcidevice_set_sym_ide_pci_device+0x2fc0
> ebp 0xc022563c  __set_pcidevice_set_sym_ide_pci_device+0x3010
> esi 0xc073c820
> edi 0xc0a2d600
> eip 0xc017e3d4  in_arpinput+0x264
> efl0x10246
> in_arpinput+0x264:  cmpb$0,0x8(%ecx)
> db> panic
> 
> Copyright (c) 1992-1999 The FreeBSD Project.
> Copyright (c) 1982, 1986, 1989, 1991, 1993
>   The Regents of the University of California. All rights reserved.
> FreeBSD 4.0-CURRENT #1: Mon Apr 12 16:13:32 BST 1999
> i...@trauma:/usr/src/sys/compile/TRAUMA
> Timecounter "i8254"  frequency 1193182 Hz
> Timecounter "TSC"  frequency 400910920 Hz
> CPU: Pentium II/Xeon/Celeron (400.91-MHz 686-class CPU)
>   Origin = "GenuineIntel"  Id = 0x652  Stepping=2
>   
> Features=0x183f9ff
> real memory  = 134217728 (131072K bytes)
> avail memory = 127995904 (124996K bytes)
> Preloaded elf kernel "kernel" at 0xc0291000.
> Pentium Pro MTRR support enabled, default memory type is uncacheable
> ccd0: Concatenated disk driver
> Probing for devices on PCI bus 0:
> chip0:  rev 0x02 on pci0.0.0
> chip1:  rev 0x02 on pci0.1.0
> chip2:  rev 0x02 on pci0.7.0
> ide_pci0:  rev 0x01 on pci0.7.1
> chip3:  rev 0x02 on pci0.7.3
> ahc0:  rev 0x00 int a irq 10 on pci0.15.0
> ahc0: aic7880 Single Channel A, SCSI Id=7, 16/255 SCBs
> fxp0:  rev 0x05 int a irq 12 on 
> pci0.17.0
> fxp0: Ethernet address 00:90:27:10:2b:ea
> Probing for devices on PCI bus 1:
> vga0:  rev 0x01 int a irq 255 on pci1.0.0
> Probing for devices on the ISA bus:
> sc0 on isa
> sc0: VGA color <16 virtual consoles, flags=0x0>
> atkbdc0 at 0x60-0x6f on motherboard
> atkbd0 irq 1 on isa
> sio0 at 0x3f8-0x3ff irq 4 flags 0x10 on isa
> sio0: type 16550A, console
> sio1 at 0x2f8-0x2ff irq 3 on isa
> sio1: type 16550A
> fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa
> fdc0: FIFO enabled, 8 bytes threshold
> fd0: 1.44MB 3.5in
> wdc0 at 0x1f0-0x1f7 irq 14 on isa
> wdc0: unit 0 (wd0): 
> wd0: 4121MB (8440992 sectors), 8374 cyls, 16 heads, 63

Re: showing full host names in output from who/finger/last

[Robert Watson]

On Mon, 12 Apr 1999, Brian Somers wrote:

> [.]
> > I got sick of seing "invalid hostname" in my wtmps a while ago on my 2.x
> > machines.  That is an exceptionally useless piece of behavior, if you ask
> > me.  Sshd writes out IPs and I find that to be much more consistent (and
> > useful).
> 
> Sshd gets it wrong though.  It gets the full hostname and then a 
> freebsd patch changes that to an IP if the name is >UT_HOSTSIZE.

I don't use the FreeBSD patched version, as I use the version with the
KerberosIV patches (unfortunately the FreeBSD port doesn't do that, but I
don't have time just now to make it do that :-). It seems to put the IP
address into the wtmp correctly. 

But anyhow; my preference is still to either a) using only IP addresses,
or b) using two fields, one for each.  Given that connections logically
come from IP addresses, performing a transformation based on an unreliable
insecure mechanism like DNS seems like a bad idea.  It's convenient to
look at (hence a look at option b).

  Robert N Watson 

rob...@fledge.watson.org  http://www.watson.org/~robert/
PGP key fingerprint: 03 01 DD 8E 15 67 48 73  25 6D 10 FC EC 68 C1 1C

Carnegie Mellon Universityhttp://www.cmu.edu/
TIS Labs at Network Associates, Inc.  http://www.tis.com/
Safeport Network Services http://www.safeport.com/



To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Bad, reliable crash: Julian's "oltr" stuff & ARP

[Ian Pallfreeman]

My -current trashbox is having some pretty severe problems which seem to
stem from the token ring additions on March 10th. The box in question 
wouldn't stay up for more than a few minutes.

``savecore'' isn't working for me right now, but I've managed to delete a 
single line of code which lets the box stay up long enough for me to do a
make world and get to grips with all this EGCS, uh, fun. This isn't a true
solution, obviously.

The ethernet segment to which the box is connected has lots of non-IP traffic
(DECNET, Novell, etc), but I didn't expect to find token ring stuff on it. :-)

Ian.

*** if_ether.c.orig Mon Apr 12 16:11:12 1999
--- if_ether.c  Mon Apr 12 16:13:22 1999
***
*** 435,442 
 panic("arpintr");
 if (m->m_len >= sizeof(struct arphdr) &&
 (ar = mtod(m, struct arphdr *)) &&
!   (ntohs(ar->ar_hrd) == ARPHRD_ETHER || 
!  ntohs(ar->ar_hrd) == ARPHRD_IEEE802) &&
 m->m_len >=
   sizeof(struct arphdr) + 2 * ar->ar_hln + 2 * ar->ar_pln)

--- 435,441 
 panic("arpintr");
 if (m->m_len >= sizeof(struct arphdr) &&
 (ar = mtod(m, struct arphdr *)) &&
!   ntohs(ar->ar_hrd) == ARPHRD_ETHER &&
 m->m_len >=
   sizeof(struct arphdr) + 2 * ar->ar_hln + 2 * ar->ar_pln)


Fatal trap 12: page fault while in kernel mode
fault virtual address   = 0x8
fault code  = supervisor read, page not present
instruction pointer = 0x8:0xc017e590
stack pointer   = 0x10:0xc02248d8
frame pointer   = 0x10:0xc0224928
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres type 0x1b
= DPL 0, press 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = Idle
interrupt mask  = 
kernel: type 12 trap, code=0
Stopped at  in_arpinput+0x264:  cmpb$0,0x8(%ecx)
db> tr
in_arpinput(c0744100,0,0,c01ee601,c01ee5a3) at in_arpinput+0x264
arpintr(c01ee5a3,8000,10,10,0) at arpintr+0xb4
swi_net_next() at swi_net_next
db> show registers
cs 0x8
ds  0x7e8b0010
es0x10
ss0x10
eax  0x600
ecx  0
edx  0
ebx 0xc0a02490
esp 0xc02255ec  __set_pcidevice_set_sym_ide_pci_device+0x2fc0
ebp 0xc022563c  __set_pcidevice_set_sym_ide_pci_device+0x3010
esi 0xc073c820
edi 0xc0a2d600
eip 0xc017e3d4  in_arpinput+0x264
efl0x10246
in_arpinput+0x264:  cmpb$0,0x8(%ecx)
db> panic

Copyright (c) 1992-1999 The FreeBSD Project.
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California. All rights reserved.
FreeBSD 4.0-CURRENT #1: Mon Apr 12 16:13:32 BST 1999
i...@trauma:/usr/src/sys/compile/TRAUMA
Timecounter "i8254"  frequency 1193182 Hz
Timecounter "TSC"  frequency 400910920 Hz
CPU: Pentium II/Xeon/Celeron (400.91-MHz 686-class CPU)
  Origin = "GenuineIntel"  Id = 0x652  Stepping=2
  
Features=0x183f9ff
real memory  = 134217728 (131072K bytes)
avail memory = 127995904 (124996K bytes)
Preloaded elf kernel "kernel" at 0xc0291000.
Pentium Pro MTRR support enabled, default memory type is uncacheable
ccd0: Concatenated disk driver
Probing for devices on PCI bus 0:
chip0:  rev 0x02 on pci0.0.0
chip1:  rev 0x02 on pci0.1.0
chip2:  rev 0x02 on pci0.7.0
ide_pci0:  rev 0x01 on pci0.7.1
chip3:  rev 0x02 on pci0.7.3
ahc0:  rev 0x00 int a irq 10 on pci0.15.0
ahc0: aic7880 Single Channel A, SCSI Id=7, 16/255 SCBs
fxp0:  rev 0x05 int a irq 12 on 
pci0.17.0
fxp0: Ethernet address 00:90:27:10:2b:ea
Probing for devices on PCI bus 1:
vga0:  rev 0x01 int a irq 255 on pci1.0.0
Probing for devices on the ISA bus:
sc0 on isa
sc0: VGA color <16 virtual consoles, flags=0x0>
atkbdc0 at 0x60-0x6f on motherboard
atkbd0 irq 1 on isa
sio0 at 0x3f8-0x3ff irq 4 flags 0x10 on isa
sio0: type 16550A, console
sio1 at 0x2f8-0x2ff irq 3 on isa
sio1: type 16550A
fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa
fdc0: FIFO enabled, 8 bytes threshold
fd0: 1.44MB 3.5in
wdc0 at 0x1f0-0x1f7 irq 14 on isa
wdc0: unit 0 (wd0): 
wd0: 4121MB (8440992 sectors), 8374 cyls, 16 heads, 63 S/T, 512 B/S
wdc1 at 0x170-0x177 irq 15 on isa
wdc1: unit 0 (wd2): 
wd2: 3681MB (7539840 sectors), 7480 cyls, 16 heads, 63 S/T, 512 B/S
wdc1: unit 1 (wd3): 
wd3: 3681MB (7539840 sectors), 7480 cyls, 16 heads, 63 S/T, 512 B/S
ppc0 at 0x378 irq 7 on isa
ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode
plip0:  on ppbus 0
ppi0:  on ppbus 0
vga0 at 0x3b0-0x3df maddr 0xa msize 131072 on isa
npx0 on motherboard
npx0: INT 16 interface
Waiting 2 seconds for SCSI devices to settle
changing rootda1 at ahc0 bus 0 target 1 lun 0
da1:  Fixed Direct Access SCSI-2 device 
da1: 10.000MB/s transfers (10.000MHz, offset 15), Tagged Queueing Enabled
da1: 1001MB (2051000 512 byte sectors: 64H 32S/T 10

Re: showing full host names in output from who/finger/last

[Brian Somers]

[.]
> I got sick of seing "invalid hostname" in my wtmps a while ago on my 2.x
> machines.  That is an exceptionally useless piece of behavior, if you ask
> me.  Sshd writes out IPs and I find that to be much more consistent (and
> useful).

Sshd gets it wrong though.  It gets the full hostname and then a 
freebsd patch changes that to an IP if the name is >UT_HOSTSIZE.

In -current, this behaviour has been changed to call trimdomain() 
(trimdomain() has just been documented too), and if the result still 
doesn't fit in UT_HOSTSIZE it reverts to an IP number.  This should 
be pretty consistent for all the stuff in libexec now too.

>   Robert N Watson 
> 
> rob...@fledge.watson.org  http://www.watson.org/~robert/
> PGP key fingerprint: 03 01 DD 8E 15 67 48 73  25 6D 10 FC EC 68 C1 1C
> 
> Carnegie Mellon Universityhttp://www.cmu.edu/
> TIS Labs at Network Associates, Inc.  http://www.tis.com/
> Safeport Network Services http://www.safeport.com/

-- 
Brian 
     
Don't _EVER_ lose your sense of humour !  




To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Re: Netscape dumps core after XFree86 build

[Peter Wemm]

"Kevin G. Eliuk" wrote:
> On Mon, 12 Apr 1999, Kevin G. Eliuk wrote:
> > 
> > I installed linux-netscape-4.08 and it opens with bus error or signal 10.
>
> That should be "without"

I've applied Bruce Evans's patch to egcs to work around (yet another)
problem with our crappy antique a.out gas.  After rebuilding egcs, and
rebuilding the a.out XFree86 libraries, netscape works again.  I was having
the same problem as you until then.

Cheers,
-Peter




To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Re: swap-related problems

[Mikhail Teterin]

Matthew Dillon once wrote:
 
> If you unset the datasize limit and the program does not exceed
> the maximum system-supported datasize limit, malloc() should not
> return NULL even if the system is out of swap.

Can you explain why? Our malloc(3) is a little fuzzy as to the
circumstances under which malloc will fail, but on Solaris, it is
more explicit:

RETURN VALUES
If there is no available memory, malloc(), realloc(),
memalign(), valloc(), and calloc() return a null pointer.

I consider being out-of-swap as having "no available memory". Wouldn't you?

Now, for better diagnostics and for a possibility of smarter applications,
they also have:

ERRORS
 If malloc(), calloc(), or realloc() returns  unsuccessfully,
 errno will be set to indicate the following:

 ENOMEM size bytes of  memory  exceeds  the  physical
limits  of  your  system, and cannot be allo-
cated.

 EAGAIN There is not enough memory available AT  THIS
POINT  IN  TIME  to  allocate  size  bytes of
memory; but the application could  try  again
later.

> The correct solution is to set a maximum datasize limit. That is
> what it is there for. I generally unlimit the datasize for root
> and set it to around 64MB for all other users.

Wait, I want to give all the memory available to a program, but I
want it to be NOTIFIED when no more memory is left. True, I can
set the limit to the actual amount of my swap, but that would be
hard to maintain and still does not solve a problem of running
together with some other memory consuming application.

The existing situation is sort of like killing a program for trying
to write to disk in excess of the user's quota, or for being ready
to RUN when the load is 1.

-mi


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Re: colour 'ls'

[Bruce Albrecht]

Dag-Erling Smorgrav writes:
 > Oleg Ogurok  writes:
 > > I put ls as a symbolic link to gnuls, but every time I make world, the old
 > > 'ls' puts back ;-)
 > 
 > Don't do that. Instead, do:
 > 
 > # cd /usr/local/bin
 > # ln -s gnuls ls
 > 
 > and fix your PATH so /usr/local/bin comes before /bin.

Better yet, set up an alias of ls = "ls --color" when the shell is an
interactive shell, and then you don't get the color escape sequences
when running scripts or if you escape ls with \ls when outputting to a 
file.


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Re: /sys/boot, egcs vs. gcc, -Os

[Poul-Henning Kamp]

In message <199904080049.raa76...@vashon.polstra.com>, John Polstra writes:
>In article , Jeroen
>Ruigrok/Asmodai  wrote:
>
>> This raises an interesting point I think. Do we need to maintain
>> gcc/egcs compatibility? Or do we, since we track CURRENT, say:
>> "alas, that's progression for ye?"
>
>Yep, alas, that's progression for ye.  We have never supported mix
>& match of sourceballs from different releases.  We do our best
>to support running old executables on newer systems, but that's a
>completely different issue.
>
>> Has there been an `official' consensus reached about this from core or
>> commiters?
>
>I am only speaking for John Polstra, a compiler guy, here.

I agree.

--
Poul-Henning Kamp FreeBSD coreteam member
p...@freebsd.org   "Real hackers run -current on their laptop."
FreeBSD -- It will take a long time before progress goes too far!


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Re: DoS from local users (fwd)

[Ville-Pertti Keinonen]

Warner Losh  writes:

> In message <199904102057.paa27...@home.dragondata.com> Kevin Day writes:
> : i.e. uid 1001 starts 40 processes eating as much cpu as they can. Then uid
> : 1002 starts up one process. Uid 1002's process gets 50% cpu, and uid 1001's
> : 40 processes get 50% cpu shared between them. 
> 
> I've seen some experimental patches in the past that try to do just
> this.  However, there are some problems.  What if uid 1002's process
> does a sleep.  Should the 40 processes that 1001 just get 50% of the
> cpu?  Or should there be other limits.  It turns into an interesting
> research problem in a hurry.

That's a simple matter of implementation decisions.  Naturally there's
hardly ever a good reason to keep a processor idle, so the limits
should only apply when the processor would not otherwise be idle.  How
this affects the amount of runtime the processes get later depends on
how you compute percentages.

An example approach is what the class scheduling feature in Digital
UNIX does.  I'll describe it from what I remember from playing with it
a couple of years ago, so all of this is only true IIRC.  It has some
fixed scheduling period, for which it allocates cycles for that period
to scheduling classes (threads, users, groups, whatever) based on the
percentage limits.  The only addition to the scheduler is having
threads consume these cycles from the scheduling classes.  When those
cycles have been used up, threads in that class are not allowed to
run.  If an eligible processor would otherwise be idle, they may be
allowed to run despite this (the behavior is configurable in some
scope, I can't remember whether it was global or per class).

The class scheduler in Digital UNIX is, in many respects, a kludge,
and I'm not recommending that FreeBSD implement a similar mechanism.
But it is semantically "sane", and unlikely to cause additional
problems when configured with reasonable parameters.


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Re: colour 'ls'

[Daniel C. Sobral]

Oleg Ogurok wrote:
> 
> Have you ever thought about putting colour listing in 'ls' command? First
> I saw it in linux and then there's a program called 'gnuls' in ports. It
> looks really cool when you do:
> gnuls --color=yes
> Files print as usual and directories print in colour ;-)
> I put ls as a symbolic link to gnuls, but every time I make world, the old
> 'ls' puts back ;-)

There is also linuxls and colorls. Just put in your .profile:

alias ls="gnuls --color=yes"

--
Daniel C. Sobral(8-DCS)
d...@newsguy.com
d...@freebsd.org

"nothing better than the ability to perform cunning linguistics"




To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Re: Panic from today's current

[Luoqi Chen]

> The kernel-configfile and dmesg-output is available from:
> http://www.attic.ch/fuchur_kernel.html
> 
> panic at: generic_bcopy+0x1arepe movsl (%esi), %es:(%edi) 
> 
> db> trace
> generic_bcopy(c02cc380,c7bb9b1f,0,a,0) at generic_bcopy+0x1a
> sccnputc(cff,1,c7bb9b80,c016c066) at sccnputc+0x180
> cnputc(a,0,0,a,c7bb9bcc) at cnputc+0x3d
> putchar(a,c7bb9bf0) at putchar+0xa6
> kvprintf(c028da63,c016bfc0,c7bb9bf0,a,c7bb9c04) at kvprintf+0x64
> printf(c028da49,8000,c1159b00,a8,c7bc3e60) at printf+0x3d
> trap(10,10,a8,c1159b00,c7bb9ce8) at trap+0x462
> calltrap() at calltrap+0x3c
> --- trap 0x13, eip = 0xc7bb9c68, ebp = 0xc7bb9ce8 ---

Trap 19 (0x13) is NMI, this problem doesn't seem to be software related.

> ufs_lookup(c7bb9d2c,c7bb9d40,c0184946,c7bb9d2c,c79ba00e) at ufs_lookup+0x353
> ufs_vnoperate(c7bb9d2c,c79ba00e,c746e580,c7bb9f10,c746e580 at 
> ufs_vnoperate+0x15
> vfs_cache_lookup(c7bb9d84,c7bb9d94,c0186d2b,c7bb9d84,c7470e00) at 
> vfs_cache_lookup+0x26a
> ufs_vnoperate(c7bb9d84,c7470e00,c7bb9f10,c1303a00,0) at ufs_vnoperate+0x15
> lookup(c7bb9eec,0,c7bb9f84,fffc,c7b757f0) at lookup+0x2af
> namei(c7bb9eec,0,c7bb9f84,fffc,c02df240) at namei+0x291
> vn_open(c7bb9eec603,1a4c7bc3e60,c029d3f0) at vn_open+0x59
> open(c7bc3e60,c7bb9f84,8070aa0,10,8085680) at open+0xbb
> syscall(2f,2f,8085680,10,bfbfcb84) at syscall+0x182
> Xint0x80_syscall() at Xint0x80_syscall+0x4c 
> 
> It seams to be ufs-related.  Does anybody know what happened ?
> 
> Martin
> 
> Martin Blapp, mbl...@solnet.ch
> --
> SolNet, Internet Solution Provider
> Bechburgstrasse 29, 4528 Zuchwil, Switzerland
> Phone: +41 32 686 82 82, Fax: +41 32 685 96 13
> -- 
> 

-lq


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Re: Netscape dumps core after XFree86 build

[Kevin G. Eliuk]

On Mon, 12 Apr 1999, Kevin G. Eliuk wrote:
> 
> I installed linux-netscape-4.08 and it opens with bus error or signal 10.
   
That should be "without"

-- 
Regards,
Kevin G. Eliuk
Box 67, Granthams Landing, BC VON 1X0 (604)886-4040
Discover Rock Solid, Discover FreeBSD | http://www.FreeBSD.Org



To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Netscape dumps core after XFree86 build

[Kevin G. Eliuk]

Hello,

On Apr10 I rebuilt the XFree86 Port with aout compatibility libraries
running current of Apr04.  Immediately following Netscape Communicator
would dump core with a bus error.

I'm not sure if this is relevant or not, but when it dumps core the core
file name is truncated.

ca...@vanessa$ netscape
Bus error
ca...@vanessa$ ll *.core
-rw---  1 cagey  cagey  - 1425408 Apr 11 23:46
navigator-4.5.bi.core

and log output gives

pid 322 (navigator-4.5.bi), uid 1000: exited on signal 10

I installed linux-netscape-4.08 and it opens with bus error or signal 10.

I have rebuilt world early today, built flawlessy, but have not built XFree
as of yet.

Could I expect any difference from a rebuilt XFree?

I could supply requested data from ktrace or gdb though it should be
easy to duplicate the same.

-- 
Regards,
Kevin G. Eliuk
Discover Rock Solid, Discover FreeBSD | http://www.FreeBSD.Org



To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Re: showing full host names in output from who/finger/last

[Rahul Dhesi]

Robert Watson  writes:

> I'd actually like to see wtmp only use IP addresses, never hostnames. 
> Spoofed names are fairly easy to arrange; with IP filtering on border
> routers, spoofed IPs are harder
> This of course sticks you with the task of DNS
> lookups when viewing wtmp, when you may already have done them at login
> time

The 'finger', 'who', and 'w' commands on the SunOS machines here all do
DNS lookups for longer hostnames, and it's rare that there is any
significant DNS lookup delay.  The reasons are simple:  The lookup was
done when the user logged in, so the DNS server has the answer in its
cache.  And even if not, if anybody did finger/who/w in the recent past,
that caused the answer to be brought into the name server's cache.

(I do run BIND with negative caching enabled, which probably helps keep
delays short for reverse lookups where some name server is not
responding.)

Rahul


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

RE: DoS from local users (fwd)

[Ladavac Marino]

> -Original Message-
> From: Amancio Hasty [SMTP:ha...@rah.star-gate.com]
> Sent: Sunday, April 11, 1999 5:36 AM
> To:   Matthew Dillon
> Cc:   Dmitry Valdov; Brian Feldman; freebsd-current@FreeBSD.ORG
> Subject:  Re: DoS from local users (fwd) 
> 
> 
> 
> I guess any sufficiently advance science is indeed consider magic by
> some.
> 
>   Amancio
> 
[ML]  Then I would like to have a high-tech gizmo for reading my
users' minds.  Would you, perhaps, know where I could buy/borrow/steal
one of these?

:)

/Marino



To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

[no subject]

[Richard Cramer]

unsubscribe  freebsd-current  rcra...@sytex.net

-- 
Richard Cramer  rcra...@sytex.net   Phone: 703-425-2515
President   Fax:   703-425-4585
  SytexNet(tm) Sytex Access Ltd. POB 2385, Fairfax, VA 22031-0385



To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Re: colour 'ls'

[Andreas Klemm]

On Sun, Apr 11, 1999 at 10:04:15AM -0400, Oleg Ogurok wrote:
> Hi there.
> 
> Have you ever thought about putting colour listing in 'ls' command? First
> I saw it in linux and then there's a program called 'gnuls' in ports. It
> looks really cool when you do:
> gnuls --color=yes
> Files print as usual and directories print in colour ;-)
> I put ls as a symbolic link to gnuls, but every time I make world, the old
> 'ls' puts back ;-)

This is a matter of taste. I personally dislike the coloring, since
not all colors give a good contrast and for me it's unfriendly for my
eyes. If I were you, I'd put a shell alias into your shells init file:

alias   ls  '/usr/local/bin/gnuls --color=yes'

But this is nothing for -current. And I think most of us dislike
such things...


-- 
Andreas Klemm   http://www.FreeBSD.ORG/~andreas
  http://www.freebsd.org/~fsmp/SMP/SMP.html
powered by Symmetric MultiProcessor FreeBSD


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message