Re: NFSv3 on freebsd<-->solaris

1999-08-24 Thread Doug Rabson

On Mon, 23 Aug 1999, Matthew Dillon wrote:

> :...
> :am not implying that the problem might be on the FreeBSD side, it might
> :as well be a bug in solaris NFS implementation).  
> :
> :I would greatly appreciate any help with the following problem.   I have
> :a FreeBSD NFS server (3.2-STABLE, built on Aug 3), and a Solaris 2.7
> :client.  I run into problems when trying to use NFSv3 mounts on the
> :client.   Trying to remove files from the mounted partition (on the nfs
> :client) results in multiple errors, for example:
> :
> :# rm -r /home/2/vladimir
> :rm: Unable to remove directory /home/2/vladimir/CVS/blowup/c: File exists
> :rm: Unable to remove directory /home/2/vladimir/CVS/blowup: File exists
> :rm: Unable to remove directory /home/2/vladimir/CVS/useradd: File exists
> :
> :I have tried using tcp and udp mount options with the same result.  NFSv2
> :works fine.
> :
> :Solaris client has the latest patches applied.   I would very much appreciate 
> :any comments on that.   
> 
> When you look at those directories on the server from the server are there any
> files left over?
> 
> If so then the rm -r is somehow missing some files and then is unable to 
> rmdir the directory because it isn't yet empty.

This is probably because our server detects that the directory has been
modified and rejects the solaris client's directory cookies. Instead of
recovering, the solaris client barfs. Its a solaris bug really but perhaps
we can add a knob to relax our directory modified checks.

--
Doug Rabson Mail:  [EMAIL PROTECTED]
Nonlinear Systems Ltd.  Phone: +44 181 442 9037




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



Re: Softupdates reliability?

1999-08-24 Thread Maxim Sobolev

Richard Tobin wrote:

> > >   Origin = "AuthenticAMD"  Id = 0x580  Stepping=0
>
> > You have one of the first K6-2s off the line. There were definite problems
> > with these, and as such, they were specially distinguished by having 66
> > printed on top.
>
> I have a 0x580 which has had no problems at all.  I'm pretty certain
> it doesn't have 66 stamped on it.  Are they all supposed to have this,
> or were they tested and the dodgy ones stamped 66?

I'm also have 0x580 without 66 stamped and it runs at 100MHz without any
remarkable problems.

-Maxim
--
"We believe in the Power and the Might!"
(Manowar, 1996)

Maxim V. Sobolev, Financial Analyst,
Vega International Capital
Phone: +380-(44)-246-6396
Fax: +380-(44)-220-8715
E-mail: [EMAIL PROTECTED]
ICQ: #42290709





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



Re: Softupdates reliability?

1999-08-24 Thread Stephen McKay

On Tuesday, 24th August 1999, Wilko Bulte wrote:

>Hmm. I would generally expect SCSI errors etc to occur. Assuming the driver
>reports those one would at least know the bus was whacko.

I saw no errors, but that's not entirely surprising since I was running X11
and by that time xconsole was probably swapped out, and the disk system
was stuck, so it wouldn't have been able to report anything.  I gave up on a
serial console a very long time ago because this machine is so reliable. :-)

Also, I recall (rumour?) that the ncr driver is not as robust in the face
of errors as the adaptec driver, at least with CAM.  Anybody know the facts?
I know, for example, that I can't get bad block lists using my scsi adapter,
but people using adaptecs can.  That shows that the ncr driver is in some
sense incomplete.  I've been meaning to look into that, but you know how
time gets away.

So, after all this, I still don't know if I have any real evidence of anything
at all.  I'll just have to keep at it until it happens again.

Stephen.


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



Alpha/PC98/ i4b patches

1999-08-24 Thread Julian Elischer


I've been moving devfs forward to match PHK's latest changes,
however there are some files I cannot test.

These effect the ISDN stack, the alpha port and the PC98 code.

If you can test these, 
apply the patch file found at 
   http://www.freebsd.org/~julian/

and let me know if it breaks anything.
If you don't compile DEVFS you shouldn't see any changes.
if you do you should see devices as per normal in a devfs.

I'm more interested in just checking that they don't break the 
NON_devfs case at the moment. but I can't test those 3 cases.

Could anyone who can test those parts let me know if they are safe, so I
can check them in?  Until I can check them (and a couple of others) in,
I can't make some API changes to DEVFS that make it less intrusive.

julian





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



Unhappy recent -CURRENT's (was Re: Monday strikes again)

1999-08-24 Thread Matthew D. Fuller

On Tue, Aug 24, 1999 at 03:52:15PM -0500, a little birdie told me
that Matthew D. Fuller remarked
> 
> Here is some info from the panic I got mid-late April.  I'll try
> cvsup'ing and building a new kernel tonite and see if it's fixed, but in
> case it isn't here's some info.

Update:
-CURRENT now boots just fine, no problems, except the minor detail that
it fails utterly to detect my PCI bus.  Which, needless to say, is a bit
of an inconvenience, since my ethernet card is on PCI.  This is a Compaq
Presario 575, Pentium 120 processor with 80 megs of RAM.  Ethernet card
is a 3c905.  Everything else seems to work just fine (w/ and w/o PnP
included in kernel config, tho I don't think it affects any hardware I
have).  Verbose boot messages available if someone has time to take a
look.



-- 
Matthew Fuller (MF4839) |[EMAIL PROTECTED]
Unix Systems Administrator  |[EMAIL PROTECTED]
Specializing in FreeBSD |http://www.over-yonder.net/
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 [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: Monday part II: The Terror Continues

1999-08-24 Thread Mike Smith

> This is the third unusable snap in a row that I've had the misfortune
> to encounter. I'm starting to think this is more than a coincidence. Did 
> somebody launch a "Piss Bill Off" contest when I wasn't looking or 
> something? If so, let me stress that you really don't want to find out
> what first prize is.

This is -current you're talking about.  I'd recommend just backing off 
a little, or don't you even care to think how good you've had it lately?

-- 
\\  The mind's the standard   \\  Mike Smith
\\  of the man.   \\  [EMAIL PROTECTED]
\\-- Joseph Merrick   \\  [EMAIL PROTECTED]




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



Re: NFSv3 on freebsd<-->solaris

1999-08-24 Thread Alfred Perlstein

On 25 Aug 1999 [EMAIL PROTECTED] wrote:

>   >> Why would solaris machine make a request with vers=4:
>   >> galois.math.uic.edu -> galileo.math.uic.edu PORTMAP C GETPORT prog=100021 
>(NLM) vers=4 proto=UDP
>   >> ?
>   >> (am I right that vers here is the same as the NFS version)?   
>   >
>   >The NLM version 4 protocol is not supported, I am working on this.
>   >
>   >Question: did you delete both checks after the Solaris 2.5 mention?
>   >or just one?  which one?
>   >
>   >-Alfred
>   >
>   >
> 
> Ah, so vers=4 has nothing to do with NFS's vers 3.

>From reading the Open Group's  XNFS book, NFSv3 clients
use the NLM version 4 protocol to gain locks, FreeBSD's
rpc.lockd doesn't have stub functions for NLMv4 locking _yet_ :)

> 
> I have deleted both checks.
> 

Interesting...

> Please let me know if you need more info or testing done.

Soon enough. :)

thank you,
-Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]]
Wintelcom systems administrator and programmer
   - http://www.wintelcom.net/ [[EMAIL PROTECTED]]




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



Re: Softupdates reliability?

1999-08-24 Thread Rodney W. Grimes

> On Tue, 24 Aug 1999, Richard Tobin wrote:
> 
> > > >   Origin = "AuthenticAMD"  Id = 0x580  Stepping=0
> > 
> > > You have one of the first K6-2s off the line. There were definite problems
> > > with these, and as such, they were specially distinguished by having 66
> > > printed on top.
> > 
> > I have a 0x580 which has had no problems at all.  I'm pretty certain
> > it doesn't have 66 stamped on it.  Are they all supposed to have this,
> > or were they tested and the dodgy ones stamped 66?
> 
> It must be the latter. My 0x580 had the 66, so it must be that the dodgy
> ones got labelled 66 and not all the 0x580s were defective.

The original K6-2's off the line where all 100MHz parts, it was later when
AMD found that some people where sticking these in 66MHz boards and trying
to run them with a 66MHz FSB and having troubles that AMD started to test
the parts for 66MHz operation, they had to make some changes in the I/O
buffers and then qualify a new part number and those are the ones stamped 66.
 Aka AMD 6K86-2-P300/66 vs AMD 6K86-2-P300/100 for those who know what a
real AMD part number is.

To the best of my knowledge no 0x580 stepping 0 chip is qualified by AMD
to run with a 66MHz FSB.

-- 
Rod Grimes - KD7CAX - (RWG25)[EMAIL PROTECTED]


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



Re: followup to apm problems.

1999-08-24 Thread Mitsuru IWASAKI

Hi,

I'd like to have full output of dmesg to investigate hardware
interference in apm.  Could you send me it later?

> 'apm -Z' for standby jumps into standby mode for like.. an instant, then
> comes right back out (while playing mp3)
[snip]
> 'zzz' or 'apm -z' for suspend jumps into suspend mode, and just the same
> way, comes right back out (while playing mp3s again)
> it should be noted that the cpu fan does turn off momentarily for both
> of these events, and the mp3 that is playing stops, then starts up again
> where it left off.
> Even without playing anything through the sound device, it does the same
> thing.

I have more questions and requests :)

When did this problem appear?  Have you put your PC in suspend/standby
state successfully before?

Did you try it on other OS? (Win, Linux, etc.)

How about executing zzz on console (non X)?

Is cli-hack helpful in your case?
  
http://www.freebsd.org/cgi/getmsg.cgi?fetch=56429+60225+/usr/local/www/db/text/1999/freebsd-current/19990815.freebsd-current+raw
  Message-Id: <[EMAIL PROTECTED]>


Could you try following script and send me the output?

#!/bin/sh
iostat -c 3
echo SUSPENDING
zzz
echo RESUMING
iostat -c 3
---

> If i leave the thing on with no activity, while running apmd, it goes
> into suspend or standby (depending on the timers set in the bios) every
> now and again, but jumps back out as soon as it does.
> Also, all the PM timer interrupts are disabled.
> 
> Motherboard is an Abit BH-6

I'm not familiar with Abit BH-6... Could you tell me current
configuration of PM related BIOS setting (and BIOS version if you
know)?

Sorry for too many questions and my poor english :)


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



Re: NFSv3 on freebsd<-->solaris

1999-08-24 Thread vladimir


>From [EMAIL PROTECTED] Wed Aug 25 01:11:10 1999
>Delivered-To: [EMAIL PROTECTED]
>Delivered-To: [EMAIL PROTECTED]
>Date: Tue, 24 Aug 1999 21:21:27 -0400 (EDT)
>From: Alfred Perlstein <[EMAIL PROTECTED]>
>To: [EMAIL PROTECTED]
>cc: [EMAIL PROTECTED]
>Subject: Re: NFSv3 on freebsd<-->solaris
>MIME-Version: 1.0
>
>On 24 Aug 1999 [EMAIL PROTECTED] wrote:
>
>> Following advice from Cejka Rudolf <[EMAIL PROTECTED]>, I have edited
>> /src/sys/nfs/nfs_syscalls.c (commented out the lines after the "Solaris 
2.5" 
>> comment). The "File exists"  errors went away, everything seemed normal,
>> but then I ran into another problem.   mailx on solaris
>> client could not lock the mailbox file anymore.   The snoop output is
>> below (I am not an NFS guru, but hope it will be useful to somebody).   
>> Here galileo is the FBSD server, galois is a Solaris 7 NFS client.   
>> Why would solaris machine make a request with vers=4:
>> galois.math.uic.edu -> galileo.math.uic.edu PORTMAP C GETPORT prog=100021 
(NLM) vers=4 proto=UDP
>> ?
>> (am I right that vers here is the same as the NFS version)?   
>
>The NLM version 4 protocol is not supported, I am working on this.
>
>Question: did you delete both checks after the Solaris 2.5 mention?
>or just one?  which one?
>
>-Alfred
>
>

Ah, so vers=4 has nothing to do with NFS's vers 3.

I have deleted both checks.

Please let me know if you need more info or testing done.

Vladimir



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



VN fixed

1999-08-24 Thread Matthew Dillon

I have submitted a patch to DG that fixes VN for CURRENT.  Since VN is 
currently broken on CURRENT, the patch is on a fast-track for commit.

I've include the patch below, but beware that it may be committed 
quickly.  This also fixes swap-backed VN.  The -S option can be applied
to files now and two new options -T (truncate/create file) and -Z (write
zero's to file to pre-allocate the file blocks) have been added.

Example usage:

vnconfig -e -s labels -T -Z -S 64m /dev/vn0 /usr/obj/test
disklabel -w -r vn0 auto
newfs /dev/rvn0c
mount /dev/vn0c some_mount_point
...
umount the_mount_point...
vnconfig -u /dev/vn0

The VN device can also be used with direct-swap backing store by not
specifying a backing file.  Note that the sector size is the system
page size (4K on intel).

vnconfig -e -s labels -S 256m /dev/vn0
disklabel -w -r vn0 auto
newfs /dev/rvn0c
mount /dev/vn0c some_mount_point
...
umount the_mount_point...
vnconfig -u /dev/vn0

Performance:  The VN device operates as a raw disk device.  This means
that 'disk I/O' operations are written to the underlying storage whereas
with MFS 'disk I/O' operations are written to memory.  VN should be
reasonably efficient memory-wise at the cost of some performance (e.g. the
I/O performed).  MFS is less memory efficient (each cached block exists
in main memory twice instead of once) but if you have lots of memory MFS
will not perform any I/O.  Note that VN does take advantage of the VM
cache, of course, because the filesystem running on top of it caches
things in the VM cache.

What does this mean?  For small filesystems use MFS.  For large 
filesystems use VN.

Use of file-backed vs swap-backed VN.  It's your choice.  A swap-backed
VN device has lower I/O overhead but is not persistant and you must be
sure to have sufficient swap to hold the entire size of the VN device
to avoid running the system out of swap if someone fills up the VN
partition.  file-backed storage can be made persistant (you can even run
fsck on the file prior to mounting it).

-Matt


Index: sys/vm/vm_pager.c
===
RCS file: /home/ncvs/src/sys/vm/vm_pager.c,v
retrieving revision 1.51
diff -u -r1.51 vm_pager.c
--- vm_pager.c  1999/07/05 12:50:54 1.51
+++ vm_pager.c  1999/08/25 02:20:02
@@ -566,6 +566,7 @@
nbp->b_bufsize = nbp->b_bcount;
if ((nbp->b_flags & B_READ) == 0)
nbp->b_dirtyend = nbp->b_bcount;
+   BUF_KERNPROC(nbp);
VOP_STRATEGY(nbp->b_vp, nbp);
} else {
biodone(nbp);
Index: sys/vm/swap_pager.c
===
RCS file: /home/ncvs/src/sys/vm/swap_pager.c,v
retrieving revision 1.124
diff -u -r1.124 swap_pager.c
--- swap_pager.c1999/08/23 23:55:03 1.124
+++ swap_pager.c1999/08/25 02:20:42
@@ -857,6 +857,7 @@
if (nbp == NULL) {
nbp = getchainbuf(bp, swapdev_vp, 
B_READ|B_ASYNC);
nbp->b_blkno = blk;
+   nbp->b_bcount = 0;
nbp->b_data = data;
}
nbp->b_bcount += PAGE_SIZE;
Index: sys/dev/vn/vn.c
===
RCS file: /home/ncvs/src/sys/dev/vn/vn.c,v
retrieving revision 1.86
diff -u -r1.86 vn.c
--- vn.c1999/08/23 20:35:16 1.86
+++ vn.c1999/08/25 02:21:50
@@ -207,18 +207,23 @@
 static int
 vnopen(dev_t dev, int flags, int mode, struct proc *p)
 {
-   int unit;
struct vn_softc *vn;
 
-   unit = dkunit(dev);
-   vn = dev->si_drv1;
-   if (!vn)
+   /*
+* Locate preexisting device
+*/
+
+   if ((vn = dev->si_drv1) == NULL)
vn = vnfindvn(dev);
 
IFOPT(vn, VN_FOLLOW)
printf("vnopen(%s, 0x%x, 0x%x, %p)\n",
devtoname(dev), flags, mode, (void *)p);
 
+   /*
+* Initialize label
+*/
+
IFOPT(vn, VN_LABELS) {
if (vn->sc_flags & VNF_INITED) {
struct disklabel label;
@@ -238,8 +243,9 @@
}
if (dkslice(dev) != WHOLE_DISK_SLICE ||
dkpart(dev) != RAW_PART ||
-   mode != S_IFCHR)
+   mode != S_IFCHR) {
return (ENXIO);
+   }
}
return(0);
 }
@@ -500,7 +506,15 @@
VOP_UNLOCK(nd.ni_vp, 0, p);
vn->sc_secsize = DEV_BSIZE;
vn->sc_v

K6-2 revisions (was: Re: Softupdates reliability?)

1999-08-24 Thread Stephen McKay

On Tuesday, 24th August 1999, "Brian F. Feldman" wrote:

>On Tue, 24 Aug 1999, Richard Tobin wrote:
>
>> > >   Origin = "AuthenticAMD"  Id = 0x580  Stepping=0
>> 
>> > You have one of the first K6-2s off the line. There were definite problems
>> > with these, and as such, they were specially distinguished by having 66
>> > printed on top.
>> 
>> I have a 0x580 which has had no problems at all.  I'm pretty certain
>> it doesn't have 66 stamped on it.  Are they all supposed to have this,
>> or were they tested and the dodgy ones stamped 66?
>
>It must be the latter. My 0x580 had the 66, so it must be that the dodgy
>ones got labelled 66 and not all the 0x580s were defective.

I think the story went along the lines that AMD were making K6-2/300's for
a while, then went to a less rigorous test procedure for just a short time
until they realised that some of the processors they released wouldn't work
at 100MHz bus speeds, though they were ok at 66MHz.  So they went back to
the better testing procedure for the 100MHz models, but also released some
66MHz only models.

Mine was indeed one of the earliest, but there have been no problem with it,
and during my strange disk crash the CPU kept updating the X11 load graph 
and stuff.  The problem(s) must be elsewhere.

Stephen.


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



Re: NFSv3 on freebsd<-->solaris

1999-08-24 Thread Alfred Perlstein

On 24 Aug 1999 [EMAIL PROTECTED] wrote:

> Following advice from Cejka Rudolf <[EMAIL PROTECTED]>, I have edited
> /src/sys/nfs/nfs_syscalls.c (commented out the lines after the "Solaris 2.5" 
> comment). The "File exists"  errors went away, everything seemed normal,
> but then I ran into another problem.   mailx on solaris
> client could not lock the mailbox file anymore.   The snoop output is
> below (I am not an NFS guru, but hope it will be useful to somebody).   
> Here galileo is the FBSD server, galois is a Solaris 7 NFS client.   
> Why would solaris machine make a request with vers=4:
> galois.math.uic.edu -> galileo.math.uic.edu PORTMAP C GETPORT prog=100021 (NLM) 
>vers=4 proto=UDP
> ?
> (am I right that vers here is the same as the NFS version)?   

The NLM version 4 protocol is not supported, I am working on this.

Question: did you delete both checks after the Solaris 2.5 mention?
or just one?  which one?

-Alfred



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



New kernel crashes as of yesterday

1999-08-24 Thread Stephen Hocking-Senior Programmer PGS Tensor Perth

After the vm subsystem changes that went in yesterday, I expierence crashes 
under heavy load situations (typically when running quake2 in OpenGL mode). A 
kernel built on the 23rd works fine. A kernel backtrace follows

# gdb -k kernel.debug /var/crash/vmcore.12
GNU gdb 4.18
Copyright 1998 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-unknown-freebsd"...
IdlePTD 3088384
initial pcb at 27a000
panicstr: page fault
panic messages:
---
Fatal trap 12: page fault while in kernel mode
fault virtual address   = 0x28
fault code  = supervisor read, page not present
instruction pointer = 0x8:0xc01647fa
stack pointer   = 0x10:0xc58ecdd0
frame pointer   = 0x10:0xc58ecddc
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 2 (pagedaemon)
interrupt mask  = net bio cam 
trap number = 12
panic: page fault

syncing disks... 3 done

dumping to dev (116,1), offset 483456
dump 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41 40 
39 38 37 36 35 34 33 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 
13 12 11 10 9 8 7 6 5 4 3 2 1 0
---
#0  boot (howto=256) at ../../kern/kern_shutdown.c:281
281 dumppcb.pcb_cr3 = rcr3();
(kgdb) bt
#0  boot (howto=256) at ../../kern/kern_shutdown.c:281
#1  0xc0131741 in panic (fmt=0xc024cfaf "page fault")
at ../../kern/kern_shutdown.c:529
#2  0xc0210fc6 in trap_fatal (frame=0xc58ecd90, eva=40)
at ../../i386/i386/trap.c:907
#3  0xc0210c79 in trap_pfault (frame=0xc58ecd90, usermode=0, eva=40)
at ../../i386/i386/trap.c:800
#4  0xc02108e7 in trap (frame={tf_fs = 16, tf_es = 16, tf_ds = 16, tf_edi = 1, 
  tf_esi = 34, tf_ebp = -980496932, tf_isp = -980496964, 
  tf_ebx = -1044768408, tf_edx = -980496860, tf_ecx = 34, tf_eax = 0, 
  tf_trapno = 12, tf_err = 0, tf_eip = -1072281606, tf_cs = 8, 
  tf_eflags = 66195, tf_esp = -1044768408, tf_ss = -1065942592})
at ../../i386/i386/trap.c:426
#5  0xc01647fa in spec_strategy (ap=0xc58ece24)
at ../../miscfs/specfs/spec_vnops.c:549
#6  0xc0163f69 in spec_vnoperate (ap=0xc58ece24)
at ../../miscfs/specfs/spec_vnops.c:124
#7  0xc01cfc9d in ufs_vnoperatespec (ap=0xc58ece24)
at ../../ufs/ufs/ufs_vnops.c:2330
#8  0xc01d10f0 in swap_pager_putpages (object=0xc5fc6dac, m=0xc58eced4, 
count=1, sync=0, rtvals=0xc58ece68) at vnode_if.h:891
#9  0xc01cfd07 in default_pager_putpages (object=0xc5fc6dac, m=0xc58eced4, 
c=1, sync=0, rtvals=0xc58ece68) at ../../vm/default_pager.c:137
#10 0xc01daf47 in vm_pageout_flush (mc=0xc58eced4, count=1, flags=0)
at ../../vm/vm_pager.h:145
#11 0xc01daea5 in vm_pageout_clean (m=0xc046ea10) at ../../vm/vm_pageout.c:339
#12 0xc01db7d6 in vm_pageout_scan () at ../../vm/vm_pageout.c:917
#13 0xc01dc0a9 in vm_pageout () at ../../vm/vm_pageout.c:1348
#14 0xc0204d40 in fork_trampoline ()
Cannot access memory at address 0xa000.
(kgdb) 
-- 
  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 [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: Softupdates reliability?

1999-08-24 Thread Brian F. Feldman

On Tue, 24 Aug 1999, Richard Tobin wrote:

> > >   Origin = "AuthenticAMD"  Id = 0x580  Stepping=0
> 
> > You have one of the first K6-2s off the line. There were definite problems
> > with these, and as such, they were specially distinguished by having 66
> > printed on top.
> 
> I have a 0x580 which has had no problems at all.  I'm pretty certain
> it doesn't have 66 stamped on it.  Are they all supposed to have this,
> or were they tested and the dodgy ones stamped 66?

It must be the latter. My 0x580 had the 66, so it must be that the dodgy
ones got labelled 66 and not all the 0x580s were defective.

> 
> -- Richard
> 

-- 
 Brian Fundakowski Feldman   /  "Any sufficiently advanced bug is\
 [EMAIL PROTECTED]   |   indistinguishable from a feature."  |
 FreeBSD: The Power to Serve!\-- Rich Kulawiec   /



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



Re: Monday part II: The Terror Continues

1999-08-24 Thread Wilko Bulte

As Bill Paul wrote ...

[...]

> This is the third unusable snap in a row that I've had the misfortune
> to encounter. I'm starting to think this is more than a coincidence. Did 
> somebody launch a "Piss Bill Off" contest when I wasn't looking or 
> something? If so, let me stress that you really don't want to find out
> what first prize is.

Not me. But I do assume you played an appropriate CD in the background?
By the "Boom Town Rats" ?

;-)
-- 
|   / o / /  _   Arnhem, The Netherlands- Powered by FreeBSD -
|/|/ / / /( (_) BulteWWW  : http://www.tcja.nl  http://www.freebsd.org


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



Re: whither readline.h?

1999-08-24 Thread Satoshi - Ports Wraith - Asami

 * From: Bruce Evans <[EMAIL PROTECTED]>

 * I think using bsd.subdir.mk is an error if there is anything more to
 * be done than traversing subdirs.  bsd.subdir.mk is mainly for optimising
 * this special case.
 * 
 * Using bsd.lib.mk would be bogus since there are no libraries to be made,
 * and in fact it seems to be broken (it attempts to handle "lib.a").
 * 
 * bsd.prog.mk is supposed to be usable here and seems to work right for
 * normal builds.  We use it routinely in similar (but more top heavy)
 * setups elsewhere.

Ok, can someone with a release build setup try this?  Or should I just
take Bruce's word and commit the bsd.subdir.mk -> bsd.prog.mk change
to /usr/src/gnu/lib/libreadline/Makefile ?

Satoshi


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



Re: Softupdates reliability?

1999-08-24 Thread Richard Tobin

> >   Origin = "AuthenticAMD"  Id = 0x580  Stepping=0

> You have one of the first K6-2s off the line. There were definite problems
> with these, and as such, they were specially distinguished by having 66
> printed on top.

I have a 0x580 which has had no problems at all.  I'm pretty certain
it doesn't have 66 stamped on it.  Are they all supposed to have this,
or were they tested and the dodgy ones stamped 66?

-- Richard


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



Re: libalias or libnat. Vote ?

1999-08-24 Thread John Polstra

In article <3843.935363694@localhost>,
Jordan K. Hubbard <[EMAIL PROTECTED]> wrote:
> 
> I've been on both sides of this issue, to be sure, but I have to say
> that looking at it now, I can't see any reason to change the actual
> name of the library right now unless we're also going to go whole-hog
> and change the API functions to PacketNATFoo() and such, something
> that would only really make sense (or be worth the effort, anyway) if
> we had a bunch of improvements to bring in at the same time, e.g. a
> significant rearchitecting effort.
> 
> If we don't have anything like that planned, then simply changing the
> user visible flags and man pages to strongly encourage use of -nat
> style options rather than the deprecated -alias ones will probably
> be enough of a step in the right direction for now.

I agree. Users don't know or care about the name of the library.
Programmers are used to dealing with quirks like having NAT
implemented in a library named libalias.

John
-- 
  John Polstra   [EMAIL PROTECTED]
  John D. Polstra & Co., Inc.Seattle, Washington USA
  "No matter how cynical I get, I just can't keep up."-- Nora Ephron


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



Re: problem with the ata driver

1999-08-24 Thread Nicolas Souchu

On Tue, Aug 24, 1999 at 08:39:25AM +0200, Soren Schmidt wrote:
>> Which ones, I found nothing in the LINT file related to ATA.
>
>"There is no user serviceable parts inside" :) and if patch someone just
>posted works it seems like the drive is abusing the standard. I'll look
>at it asap, then lets see how far it comes...

Ok nice, let me know.

>
>-Søren
>

-- 
[EMAIL PROTECTED] / [EMAIL PROTECTED]
FreeBSD - Turning PCs into workstations - http://www.FreeBSD.org


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



Re: Any chances to solve bin/7973?

1999-08-24 Thread Garance A Drosihn

At 8:44 AM +0200 8/24/99, Cejka Rudolf wrote:
>Garance A Drosihn wrote (1999/08/23):
>
> > Why would the filter be reading the control file?  It is just a
> > filter, supposedly reading from stdin and writing to stdout...
>
>Yes and not.
>
>You can look into apsfilter for example. It gets from control file
>JOB, USER and HOST items in case of ASCII input printing. This
>information is used for "better" printing - ASCII input is converted
>into PostScript and some additional headers are added: "Printed by USER
>from HOST', "JOB name", date of printing and others. Why we should
>lose this feature? (But I don't know, if there is any other and better
>way how to fix this problem.)

My own preference is to get lpd to set environment variables for this
sort of thing.  That way the values could be effected by other inputs
(printcap entries, etc).  I don't have any deep-seated objection to
your change (and my opinion doesn't really count for much even if I
did... :-), but my general preference is that nothing but the lpr/lpd
programs should have any idea of the format (or even existence) of
the control file.

In the specific case of USER and HOST, aren't those already passed as
parameters to the filter?  We have a somewhat customized print empire
here at RPI, but I believe it's true that the distributed lpd starts
up a print-filter with '-n  -h '.  At one point we
added another parameter to this list, only to find out that it broke
several of the filter scripts we use.  Thus, I went with environment
variables. :-)


---
Garance Alistair Drosehn   =   [EMAIL PROTECTED]
Senior Systems Programmer  or  [EMAIL PROTECTED]
Rensselaer Polytechnic Institute


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



Re: Monday strikes again

1999-08-24 Thread Matthew D. Fuller

On Mon, Aug 23, 1999 at 09:44:10PM +0100, a little birdie told me
that Doug Rabson remarked
> 
> It seems like  isa bus is never being attached for some reason. Have a
> look at nexus_attach() and see if anything suspicious is happening (like
> an error return from device_probe_and_attach()).

FWIW, I've been getting a panic on bootup for months (mid-April, maybe?)
on -CURRENT on one of my systems; could this be at all related?

Here is some info from the panic I got mid-late April.  I'll try
cvsup'ing and building a new kernel tonite and see if it's fixed, but in
case it isn't here's some info.

Bootup gets to here:
isab0:  at device 15.0 on pci0

and them *boom*
Fatal trap 12: page fault while in kernel mode


fault virtual address = 0x24000208
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc01456f5
stack pointer = 0x10:0xc02d5ef8
frame pointer = 0x10:0xc02d5f04
code segment = base 0x0, limit 0xf, type 0x1b
 = DRL 0, pres 1, def32 1, gran 1
processor eflags = interrupts enabled, resume, IOPL=0
current process = 0 ( )
interrupt mask = net tty bio cam
kernel: type 12 trap, code:0

DDB reveals
Stopped at device_probe_and_attach+0x9movl  0x8(%ebx),%edi

trace shows:
device_probe_and_attach(24000200) at device_probe_and_attach+0x9
bus_generic_attach(c09e1880, c02d5f38, c0145737, c09e1880, c09e1880)
  at bus_generic_attach+0x16
DEVICE_ATTACH(c09e1880, c09e1880, 0, c061cb40, c02d5f48)
  at DEVICE_ATTACH+0x25




-- 
Matthew Fuller (MF4839) |[EMAIL PROTECTED]
Unix Systems Administrator  |[EMAIL PROTECTED]
Specializing in FreeBSD |http://www.over-yonder.net/
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 [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: whither readline.h?

1999-08-24 Thread Bruce Evans

>It is probably because /usr/src/gnu/lib/libreadline/Makefile use
>bsd.subdir.mk and not bsd.lib.mk. Their distribute targets are different.
>I don't know if you can just slot bsd.lib.mk in there because the
>libreadline have some subdirs that have to be handled.

I think using bsd.subdir.mk is an error if there is anything more to
be done than traversing subdirs.  bsd.subdir.mk is mainly for optimising
this special case.

Using bsd.lib.mk would be bogus since there are no libraries to be made,
and in fact it seems to be broken (it attempts to handle "lib.a").

bsd.prog.mk is supposed to be usable here and seems to work right for
normal builds.  We use it routinely in similar (but more top heavy)
setups elsewhere.

Bruce


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



Monday part II: The Terror Continues

1999-08-24 Thread Bill Paul

So today my ISA bus is detected properly and the kernel gets as far as
trying to launch /stand/sysinstall, but then, just when I thought it was
safe to try and load a new snapshot:

rootfs is 2880 Kbyte compiled in MFS
spec_getpages: I/O read failure: (error code=0) bp 0xc34fc3a0 vp 0xc7ed8ec0
   size: 0, resid: 0, a_count: 49152, valid: 0x0
   nread: 0, reqpage: 0, pindex: 0, pcount: 12
exec /stand/sysinstall: error 5
init: not found
panic: no init

This has nothing to do with the 486 though; I tried it on a laptop
that was handy and it blew up the same way. I tried yesterday's mfsroot
image and it doesn't work with that either.

The August 16th snapshot's kernel and mfsroot images seem to work.
The August 16th snapshot's kernel and yesterday's mfsroot image also
works.

This is the third unusable snap in a row that I've had the misfortune
to encounter. I'm starting to think this is more than a coincidence. Did 
somebody launch a "Piss Bill Off" contest when I wasn't looking or 
something? If so, let me stress that you really don't want to find out
what first prize is.

-Bill

-- 
=
-Bill Paul(212) 854-6020 | System Manager, Master of Unix-Fu
Work: [EMAIL PROTECTED] | Center for Telecommunications Research
Home:  [EMAIL PROTECTED] | Columbia University, New York City
=
 "It is not I who am crazy; it is I who am mad!" - Ren Hoek, "Space Madness"
=


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



Re: Monday part II: The Terror Continues

1999-08-24 Thread Poul-Henning Kamp


I just found out myself, fix (I hope) committed.

>spec_getpages: I/O read failure: (error code=0) bp 0xc34fc3a0 vp 0xc7ed8ec0
>   size: 0, resid: 0, a_count: 49152, valid: 0x0
>   nread: 0, reqpage: 0, pindex: 0, pcount: 12

--
Poul-Henning Kamp FreeBSD coreteam member
[EMAIL PROTECTED]   "Real hackers run -current on their laptop."
FreeBSD -- It will take a long time before progress goes too far!


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



Re: NFSv3 on freebsd<-->solaris

1999-08-24 Thread vladimir

Following advice from Cejka Rudolf <[EMAIL PROTECTED]>, I have edited
/src/sys/nfs/nfs_syscalls.c (commented out the lines after the "Solaris 2.5" 
comment). The "File exists"  errors went away, everything seemed normal,
but then I ran into another problem.   mailx on solaris
client could not lock the mailbox file anymore.   The snoop output is
below (I am not an NFS guru, but hope it will be useful to somebody).   
Here galileo is the FBSD server, galois is a Solaris 7 NFS client.   
Why would solaris machine make a request with vers=4:
galois.math.uic.edu -> galileo.math.uic.edu PORTMAP C GETPORT prog=100021 (NLM) vers=4 
proto=UDP
?
(am I right that vers here is the same as the NFS version)?   

Vladimir

PS I am not sure these questions are appropriate for this list, please
direct me to some other resource if this is not the case.
Thanks!




galois.math.uic.edu -> galileo.math.uic.edu NFS C LOOKUP3 FH=6CF3 Maildir
galileo.math.uic.edu -> galois.math.uic.edu NFS R LOOKUP3 OK FH=20ED
galois.math.uic.edu -> galileo.math.uic.edu NFS C GETATTR3 FH=9EF4
galileo.math.uic.edu -> galois.math.uic.edu NFS R GETATTR3 OK
galois.math.uic.edu -> galileo.math.uic.edu NFS C GETATTR3 FH=B452
galileo.math.uic.edu -> galois.math.uic.edu NFS R GETATTR3 OK
galois.math.uic.edu -> galileo.math.uic.edu NFS C GETATTR3 FH=107B
galileo.math.uic.edu -> galois.math.uic.edu NFS R GETATTR3 OK
galois.math.uic.edu -> galileo.math.uic.edu NFS C LOOKUP3 FH=92D1 vladimir
galileo.math.uic.edu -> galois.math.uic.edu NFS R LOOKUP3 OK FH=6CF3
galois.math.uic.edu -> galileo.math.uic.edu NFS C LOOKUP3 FH=6CF3 Mailbox
galileo.math.uic.edu -> galois.math.uic.edu NFS R LOOKUP3 OK FH=0BEF
galois.math.uic.edu -> galileo.math.uic.edu NFS C LOOKUP3 FH=6CF3 Mailbox
galileo.math.uic.edu -> galois.math.uic.edu NFS R LOOKUP3 OK FH=0BEF
galois.math.uic.edu -> galileo.math.uic.edu PORTMAP C GETPORT prog=100021 (NLM) vers=4 
proto=UDP
galileo.math.uic.edu -> galois.math.uic.edu PORTMAP R GETPORT port=1005
galois.math.uic.edu -> galileo.math.uic.edu NLM C LOCK4 OH=1FAB FH=0BEF PID=4106 
Region=0:0
galileo.math.uic.edu -> galois.math.uic.edu RPC R (#17) XID=4282729491 Program number 
mismatch (low=1, high=3)
galois.math.uic.edu -> galileo.math.uic.edu PORTMAP C GETPORT prog=100021 (NLM) vers=4 
proto=UDP
galileo.math.uic.edu -> galois.math.uic.edu PORTMAP R GETPORT port=1005
galois.math.uic.edu -> galileo.math.uic.edu NLM C UNLOCK4 OH=1FAC FH=0BEF PID=4106 
Region=0:0
galileo.math.uic.edu -> galois.math.uic.edu RPC R (#21) XID=4282729493 Program number 
mismatch (low=1, high=3)




>   >From [EMAIL PROTECTED] Tue Aug 24 03:44:09 1999
>   >Delivered-To: [EMAIL PROTECTED]
>   >Delivered-To: [EMAIL PROTECTED]
>   >Date: Mon, 23 Aug 1999 20:44:39 -0700 (PDT)
>   >From: Matthew Dillon <[EMAIL PROTECTED]>
>   >To: "David O'Brien" <[EMAIL PROTECTED]>
>   >Cc: [EMAIL PROTECTED], [EMAIL PROTECTED]
>   >Subject: Re: NFSv3 on freebsd<-->solaris
>   >
>   >:...
>   >:am not implying that the problem might be on the FreeBSD side, it 
might
>   >:as well be a bug in solaris NFS implementation).  
>   >:
>   >:I would greatly appreciate any help with the following problem.   I 
have
>   >:a FreeBSD NFS server (3.2-STABLE, built on Aug 3), and a Solaris 2.7
>   >:client.  I run into problems when trying to use NFSv3 mounts on the
>   >:client.   Trying to remove files from the mounted partition (on the 
nfs
>   >:client) results in multiple errors, for example:
>   >:
>   >:# rm -r /home/2/vladimir
>   >:rm: Unable to remove directory /home/2/vladimir/CVS/blowup/c: 
File exists
>   >:rm: Unable to remove directory /home/2/vladimir/CVS/blowup: File 
exists
>   >:rm: Unable to remove directory /home/2/vladimir/CVS/useradd: 
File exists
>   >:
>   >:I have tried using tcp and udp mount options with the same result.  
NFSv2
>   >:works fine.
>   >:
>   >:Solaris client has the latest patches applied.   I would very much 
appreciate 
>   >:any comments on that.   
>   >
>   >When you look at those directories on the server from the server 
are there any
>   >files left over?
>
>There are files  left over.   
>
>   >
>   >If so then the rm -r is somehow missing some files and then is 
unable to 
>   >rmdir the directory because it isn't yet empty.


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



Re: SIO "lost interrupt" status in current?

1999-08-24 Thread Nate Williams

>   > I'm actually pretty sure it happens even without X11 live. This worries m
>  e!
>   > changing the modem serial speed down from 57600 through 33600 to 19200 ma
>  de
>   > no difference.  This also worries me.
>   
>   If the speed isn't being set down, then somehow interrupts are being
>   turned off for a very long time, possibly by another device driver, or
>   possibly you have bad hardware.
> 
> If interrupts were off, wouldn't I see other things like mice freezes or
> X-repaint problems?

Nope, because they are less sensitive to the timing then serial lines.

> I'd go with either of these actually. Any suggestions for debug methods?

Look through the mailing lists.  I'm sure Bruce had some debug ideas in
the past.



Nate


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



Re: Softupdates reliability?

1999-08-24 Thread Brian F. Feldman

On Tue, 24 Aug 1999, Stephen McKay wrote:

> 
> Oh, and Brian wanted to know the processor revision.  I don't know of any
> problems with K6-2/300s, but here's the info:
> 
> CPU: AMD-K6(tm) 3D processor (300.68-MHz 586-class CPU)
>   Origin = "AuthenticAMD"  Id = 0x580  Stepping=0
>   Features=0x8001bf

You have one of the first K6-2s off the line. There were definite problems
with these, and as such, they were specially distinguished by having 66
printed on top.

What is your FSB running at? These chips (the very early 300s) can not
handle >66MHz, and I've had a K6-2 0x580 go _completely_ bad easily.
For peace of mind, even if it's not the problem (which it very well could
be), I'd upgrade to a later revision. You can get one of these relatively
cheap:

CPU: AMD-K6(tm) 3D processor (350.81-MHz 586-class CPU)
  Origin = "AuthenticAMD"  Id = 0x58c  Stepping = 12
  Features=0x8021bf
  AMD Features=0x8800


> 
> Stephen
> 

-- 
 Brian Fundakowski Feldman   /  "Any sufficiently advanced bug is\
 [EMAIL PROTECTED]   |   indistinguishable from a feature."  |
 FreeBSD: The Power to Serve!\-- Rich Kulawiec   /



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



Re: NFSv3 on freebsd<-->solaris

1999-08-24 Thread Cejka Rudolf


David O'Brien wrote (1999/08/23):
> - - Forwarded message from [EMAIL PROTECTED] -
> Solaris 7 machines cannot use NFSv3 mounts from a FreeBSD NFS server.
> ...
> # rm -r /home/2/vladimir
> rm: Unable to remove directory /home/2/vladimir/CVS/blowup/c: File exists
> ...

Yes, this is very well known problem. Please look at kern/5890 (by Remy
Nonnenmacher). In our environment we had to use suggested patch to use
FreeBSD as NFS server and Solaris NFS clients (v3).

There was another discussion about it in the middle of November 1998
(initiated by me and followed by helpful answer from Remy) on -current
mailing list.

As I see, the kern/5890 is stopped with following question:

  Hi Remy, (Sat Apr 25 22:21:50 PDT 1998)
  Can you retest this bug?  Peter made many changes to sys/nfs/nfs_serv.c
  over the summer.  From the commit logs, I suspect it might be fixed.

I can answer: Yes, the problem is still here (3.2-RELEASE and -CURRENT).
I am closely observing cvs logs and looking for fix because this is
unpleasant bug for us - but latest fix for readdirplus() still
didn't help...

(What about new kernel compilation option SOLARIS_NFSV3 or
new sysctl variable? :-)

-- 
Rudolf Cejka   ([EMAIL PROTECTED];  http://www.fee.vutbr.cz/~cejkar)
Brno University of Technology, Faculty of El. Engineering and Comp. Science
Bozetechova 2, 612 66  Brno, Czech Republic


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



Re: whither readline.h?

1999-08-24 Thread John Hay

>  * From: "David O'Brien" <[EMAIL PROTECTED]>
> 
>  * > /usr/include/readline/readline.h (and whatever else that's supposed to
>  * > be in that directory) has been missing from 4-current and 3-stable
>  * > snaps for awhile.  Does anyone know why?
>  * 
>  * I just checked that cd /usr/src/gnu/lib/libreadline ; make obj all install
>  * does the right thing.  Ideas where to look next?
> 
> I dunno.  Maybe the release Makefiles?  (Jordan CC'd)
> 

It is probably because /usr/src/gnu/lib/libreadline/Makefile use
bsd.subdir.mk and not bsd.lib.mk. Their distribute targets are different.
I don't know if you can just slot bsd.lib.mk in there because the
libreadline have some subdirs that have to be handled.

John
-- 
John Hay -- [EMAIL PROTECTED]


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



Re: Softupdates reliability?

1999-08-24 Thread Wilko Bulte

As Peter Jeremy wrote ...
> Stephen McKay <[EMAIL PROTECTED]> wrote:
> >I was extracting from the Exabyte to the DDRS disk while applying a CTM
> >update from that disk against one of the DCAS disks when it crashed.  The
> >Exabyte went wonky (took about 6 goes to get the tape ejected) and the
> >rest of the disk system locked up.  The SCSI adapter was so confused I
> >had to power down.
> 
> The exact order of events is not clear from this.  In general, I'd say
> that if something managed to upset the SCSI bus sufficiently to
> confuse every target on it, then there's a reasonably likelihood that
> data transfers were also corrupted.  A serious bus corruption during a
> disk write (either command or data phase) would have a reasonable
> chance of resulting in corrupt data on the disk (either the wrong data
> in the right place or the right data in the wrong place).

Hmm. I would generally expect SCSI errors etc to occur. Assuming the driver
reports those one would at least know the bus was whacko.


-- 
|   / o / /  _   Arnhem, The Netherlands- Powered by FreeBSD -
|/|/ / / /( (_) BulteWWW  : http://www.tcja.nl  http://www.freebsd.org


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



Re: followup to apm problems.

1999-08-24 Thread Mike Muir

Yeh, i just got all the latest sources (as of 24th August) and made em:
$Id: apm.c,v 1.103 1999/08/23 20:58:36 phk Exp $

So yes i do have that recent version, but my problems persist. :(

Nick Hibma wrote:
> 
> Are you running CURRENT?
> 
> Could you check whether you have at least rev. 101 of
> src/sys/i386/apm/apm.c


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



Re: whither readline.h?

1999-08-24 Thread Satoshi - Ports Wraith - Asami

 * From: "David O'Brien" <[EMAIL PROTECTED]>

 * > /usr/include/readline/readline.h (and whatever else that's supposed to
 * > be in that directory) has been missing from 4-current and 3-stable
 * > snaps for awhile.  Does anyone know why?
 * 
 * I just checked that cd /usr/src/gnu/lib/libreadline ; make obj all install
 * does the right thing.  Ideas where to look next?

I dunno.  Maybe the release Makefiles?  (Jordan CC'd)

Satoshi


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



Re: Softupdates reliability?

1999-08-24 Thread Stephen McKay

On Tuesday, 24th August 1999, Peter Jeremy wrote:

>The exact order of events is not clear from this.  In general, I'd say
>that if something managed to upset the SCSI bus sufficiently to
>confuse every target on it, then there's a reasonably likelihood that
>data transfers were also corrupted.  A serious bus corruption during a
>disk write (either command or data phase) would have a reasonable
>chance of resulting in corrupt data on the disk (either the wrong data
>in the right place or the right data in the wrong place).

Yes, I can't tell whether the confused SCSI adapter upset the Exabyte and
maybe zero'd some disk sectors, or whether the Exabyte went bananas first
and took out everything else.  This system gets a LOT of use (I'm using it
right now), but the Exabyte obviously isn't used as often as the disks.
I might move the Exabyte on to an aha1542 as a precaution.

>I'm not sure how to go about isolating the problem.  I don't suppose
>you happened to bump one of the cables, or suffer a power glitch?

No power glitch or bumped cables.  All quality gear, no overclocking, good
cooling, surge suppressors, etc.  I don't like "It was just one of those
things".  That's not how computers work.  I've either got bad hardware or
there are bugs.  To counter the bugs, I'm about to go to the latest -stable.
Bad hardware will show itself eventually.  What I really should do is
build a test system with softupdates and crash it a lot.  (Using DDB
to pause, then switch off, so no partial writes.)  Could take a while...

Oh, and Brian wanted to know the processor revision.  I don't know of any
problems with K6-2/300s, but here's the info:

CPU: AMD-K6(tm) 3D processor (300.68-MHz 586-class CPU)
  Origin = "AuthenticAMD"  Id = 0x580  Stepping=0
  Features=0x8001bf

Stephen


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