mount(2) broken?

1999-12-04 Thread Brian W. Buchanan

After an unfortunate hard reboot today, the system fscked everything and
then barfed attempting to mount /, claiming it to be unclean.  I dropped
to single-user mode and proceeded to re-fsck / and then tried to mount it
again to no avail.  Rebooting didn't help things either.

# fsck -p
/dev/wd0s1a: FILESYSTEM CLEAN; SKIPPING CHECKS
/dev/wd0s1a: clean, 157026 free (2306 frags, 19340 blocks, 0.8% fragmentation)
/dev/wd0s2f: FILESYSTEM CLEAN; SKIPPING CHECKS
/dev/wd0s2f: clean, 1089990 free (10286 frags, 134963 blocks, 0.2% fragmentation
)
/dev/wd0s2e: FILESYSTEM CLEAN; SKIPPING CHECKS
/dev/wd0s2e: clean, 564709 free (23093 frags, 67702 blocks, 1.9% fragmentation)
/dev/wd1s1e: FILESYSTEM CLEAN; SKIPPING CHECKS
/dev/wd1s1e: clean, 266984 free (72 frags, 33364 blocks, 0.0% fragmentation)
/dev/wd1s2e: FILESYSTEM CLEAN; SKIPPING CHECKS
/dev/wd1s2e: clean, 204574 free (25134 frags, 22430 blocks, 1.1% fragmentation)
# mount /
WARNING: R/W mount of / denied.  Filesystem is not clean - run fsck
mount: Operation not permitted
# mount
/dev/wd0s1a on / (ufs, local, read-only, writes: sync 12 async 3, reads: sync 11
3 async 3)
# mount
/dev/wd0s1a on / (ufs, local, read-only, writes: sync 12 async 3, reads: sync 11
3 async 3)
# mount -a
WARNING: R/W mount of / denied.  Filesystem is not clean - run fsck
mount: Operation not permitted
# mount -f /
WARNING: / was not properly dismounted
# uname -a
FreeBSD thought 4.0-CURRENT FreeBSD 4.0-CURRENT #0: Thu Dec  2 00:43:25 PST
1999 brian@thought:/usr/src/sys/compile/THOUGHT  i386


-- 
Brian Buchanan [EMAIL PROTECTED]
--
FreeBSD - The Power to Serve!   http://www.freebsd.org



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



disklabel -W now seems to not work(?)

1999-12-04 Thread Matthew Jacob


It seems that in the latest running around with things, disklabel -W
doesn't seem to quite work, at least on the alpha- it seems to set the
label writable, but the next attempt to open the disk sets the label area
non-writable again.

Before I go tracking this down as a bug, is it?

Secondly, how do people feel about having dd(1) use the DIOCWLABEL
argument to enable writing the label area of the disk if the output is a
disk and there is no offset from zero?





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



Re: Mounting one FS on more than one system

1999-12-04 Thread Kirk McKusick

To: Kirk McKusick <[EMAIL PROTECTED]>
cc: Mike Smith <[EMAIL PROTECTED]>, [EMAIL PROTECTED],
[EMAIL PROTECTED]
Subject: Re: Mounting one FS on more than one system 
In-reply-to: Your message of "Sat, 04 Dec 1999 12:44:43 PST."
 <[EMAIL PROTECTED]> 
Date: Sun, 05 Dec 1999 09:44:32 +1000
From: George Michaelson <[EMAIL PROTECTED]>

Let me start by saying that I do not have the definitive answers
to all your questions. I'll take a crack at some of them.

Allowing for cache writeback delays, is the speed of
direct-to-shared-disk fast enough that using NFS as an
"abstraction" layer would be faster than any network extant?

The gains come from being able to read data directly from the
disk rather than transferring it across the network. However,
the cost of maintaining cache coherency would be at least as
difficult and bandwidth consuming as a distributed filesystem.

Would it be as fast? would the effort to make this work
exceed the cost of making real networks exist?

As the network speed approaches the disk speed, the gains
would diminish.

It would seem that there might be opportunities to do 'cut
through' in the coding for known-private files after open
(ok, inode allocation/extension has problems) to optimize
them to at-worst 'disk+bits' instead of NFS costs.

The problem is in identifying when private goes to shared. Also
as you point out, new block and inode allocations have to be
centrally coordinated.

If one party mounts -r the FS (eg news spool) then does
this reduce the complexity? eg /usr mounted read-mostly
for a bunch of tightly coupled boxes.

If any machine can write, then all the other machines have to
have some way of keeping their caches consistent with the
machine that did the modification.

If some other protocol is used for interlock, does this
make mmap shares across clusters faster?

Mmap sharing across machines is going to be slow. I have never
been a fan of distributed shared memory as a programming model,
and this does not look like a way of making it run any faster.

-George

--
George Michaelson |  DSTC Pty Ltd
Email: [EMAIL PROTECTED]|  University of Qld 4072
Phone: +61 7 3365 4310|  Australia
  Fax: +61 7 3365 4311|  http://www.dstc.edu.au


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



Re: Mounting one FS on more than one system

1999-12-04 Thread Frank Mayhar

Regarding a filesystem mounted on multiple boxes, check out DFS; there's
a spec available from the Open Group in the UK for $58.00:
http://www.opengroup.org/pubs/catalog.saved/p409.htm

If you allow multiple R/W mounts, it's certainly not trivial.  As Kirk said,
you need a strong coherency mechanism; DFS uses a token mechanism invented,
AFAIK, by Locus Computing Corporation.

I work on the former Locus clustering stuff (for Compaq, these days), so I
can't really contribute, but I know there are white papers and other docs out
there.
-- 
Frank Mayhar [EMAIL PROTECTED]


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



Re: Mounting one FS on more than one system

1999-12-04 Thread George Michaelson


Allowing for cache writeback delays, is the speed of direct-to-shared-disk
fast enough that using NFS as an "abstraction" layer would be faster than
any network extant?

Would it be as fast? would the effort to make this work exceed the cost
of making real networks exist?

It would seem that there might be opportunities to do 'cut through' in
the coding for known-private files after open (ok, inode allocation/extension
has problems) to optimize them to at-worst 'disk+bits' instead of NFS costs.

If one party mounts -r the FS (eg news spool) then does this reduce the
complexity? eg /usr mounted read-mostly for a bunch of tightly coupled boxes.

If some other protocol is used for interlock, does this make mmap shares
across clusters faster?

-George

--
George Michaelson |  DSTC Pty Ltd
Email: [EMAIL PROTECTED]|  University of Qld 4072
Phone: +61 7 3365 4310|  Australia
  Fax: +61 7 3365 4311|  http://www.dstc.edu.au


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



Re: Mounting one FS on more than one system

1999-12-04 Thread Kirk McKusick

To: [EMAIL PROTECTED]
cc: [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: Mounting one FS on more than one system
In-reply-to: Your message of "Sat, 04 Dec 1999 10:10:20 MST."
 <[EMAIL PROTECTED]> 
Date: Sat, 04 Dec 1999 13:53:26 -0800
From: Mike Smith <[EMAIL PROTECTED]>

(moved to -current where there are more eyes that are interested)

> P.S. Mike, at comdex I spoke to you some about clustering two 
> computers and one RAID array, remember? You mentioned that 
> someone had pursued that avenue some, perhaps not to a working 
> solution, but I don't remember who. Can you (or anyone else) point 
> me to the guilty parties? We would like to pick up the work and run 
> with it for a while.

Yup, I remember.  I also remember going through my stack
of business cards wondering whether I remembered to get
one from you; obviously not.  8)

The sticking issue that we discussed was allowing more than
one system to mount a given filesystem; I seemed to recall
that Kirk has spoken about this before, and there may be
some folks here (or Kirk himself, also copiedd) who may
have some more input on the topic.  Once this is resolved,
everything else is (relatively!) straightforward...

-- 
\\ Give a man a fish, and you feed him for a day. \\  Mike Smith
\\ Tell him he should learn how to fish himself,  \\  [EMAIL PROTECTED]
\\ and he'll hate you for a lifetime. \\  [EMAIL PROTECTED]

Mounting on more than one system is generally problematical unless
you are willing to have all systems read-only. The problem is cache
coherence between the machines. If one changes a block, the other
machines will not see it. Basically, this is why we have the NFS
filesystem. That lets a disk be mounted on one machine, but shared
out to others. If you wanted to write a protocol that would allow
for multiple machines, then you would need to have some central
coordinator running some sort of coherency protocol with a complexity
akin to that of NFS.

Kirk McKusick


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



Re: -current no longer builds on the alpha

1999-12-04 Thread Wilko Bulte

As Wilko Bulte wrote ...
> As Matthew Jacob wrote ...
> 
> > > As Matthew Jacob wrote ...
> > > > 
> > > > Q'uelle strange- what I have... well, we'll see what my nightly build
> > > > brings...
> > > 
> > > Mine fell over in 'truss'. I already reported it to Marcel, looks
> > > like something was changed in kdump/mkioctls, a script that 'truss' also
> > > uses.
> > 
> > Mine's still going (I start mine at 0430 PST8PDT, the update from
> > freefall runs at 0107 PST8PDT)) Nope, what a coincidence. It *just*
> > finished. Went all the way through w/o errors on a buildworld.
> 
> My buildworld is OK now. Minor snag in the truss Makefile that Marcel
> committed already.

Make that: commited a fix for already.

Blrgh.

-- 
|   / o / /  _  Arnhem, The Netherlands   - Powered by FreeBSD -
|/|/ / / /( (_) Bulte   WWW : 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: Mounting one FS on more than one system

1999-12-04 Thread Poul-Henning Kamp

In message <[EMAIL PROTECTED]>, Mike Smith writes:

>The sticking issue that we discussed was allowing more than one system to 
>mount a given filesystem;

I pressume we're talking R/W mounts here, since a R/O mount obviously
would not be a problem.

With UFS/FFS there are significant meta-data caching which would
need not only high-level locking (for atomic rename(2) calls) but
also low-level locking (who allocates a particular free block).
In short: a major hazzle.

It might be possible to allow one machine R/W and have the others
R/O snoop on the same device, but a more agressive write policy
would be needed to get closer to real-time behaviour.

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



Mounting one FS on more than one system

1999-12-04 Thread Mike Smith


(moved to -current where there are more eyes that are interested)

> P.S. Mike, at comdex I spoke to you some about clustering two 
> computers and one RAID array, remember? You mentioned that 
> someone had pursued that avenue some, perhaps not to a working 
> solution, but I don't remember who. Can you (or anyone else) point 
> me to the guilty parties? We would like to pick up the work and run 
> with it for a while.

Yup, I remember.  I also remember going through my stack of business 
cards wondering whether I remembered to get one from you; obviously not. 
8)

The sticking issue that we discussed was allowing more than one system to 
mount a given filesystem; I seemed to recall that Kirk has spoken about 
this before, and there may be some folks here (or Kirk himself, also 
copiedd) who may have some more input on the topic.  Once this is 
resolved, everything else is (relatively!) straightforward...


-- 
\\ Give a man a fish, and you feed him for a day. \\  Mike Smith
\\ Tell him he should learn how to fish himself,  \\  [EMAIL PROTECTED]
\\ and he'll hate you for a lifetime. \\  [EMAIL PROTECTED]




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



Re: -current no longer builds on the alpha

1999-12-04 Thread Wilko Bulte

As Matthew Jacob wrote ...

> > As Matthew Jacob wrote ...
> > > 
> > > Q'uelle strange- what I have... well, we'll see what my nightly build
> > > brings...
> > 
> > Mine fell over in 'truss'. I already reported it to Marcel, looks
> > like something was changed in kdump/mkioctls, a script that 'truss' also
> > uses.
> 
> Mine's still going (I start mine at 0430 PST8PDT, the update from
> freefall runs at 0107 PST8PDT)) Nope, what a coincidence. It *just*
> finished. Went all the way through w/o errors on a buildworld.

My buildworld is OK now. Minor snag in the truss Makefile that Marcel
committed already.

> > > > It's an Aspen systems DEC Durango PC164 motherboard based system.
> > 
> > Doesn't that one have ECC memory (refering to a previous post where
> > you theorised a bit on memory problems and sig-11s ;)
> 
> It may or may not, but memory problems are typically detected pretty well

Right, that is my experience.

> on alphas and you'll get a 670 machine check if it was recoverable (which
> the PALcode has already done, except for TurboLaser if the memory problem

I don't have TL :)

Wilko
-- 
|   / o / /  _  Arnhem, The Netherlands   - Powered by FreeBSD -
|/|/ / / /( (_) Bulte   WWW : 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: NFS client zeroing out blocks on write?

1999-12-04 Thread Matthew Dillon

:I just upgraded a server from 2.2.8 to -current (991201 kernel) and am
:seeing some NFS corruption.  It looks like byte ranges are getting
:zeroed out by the client (or not getting written at all, and the server
:at the other end is filling with zeros?).  I've seen it while writing
:to both a Solaris 2.6 server (NFSv3) and a Netware NFS server (NFSv2),
:so I'm pretty sure it's the client causing the problem.

Hmm.  I thought we had fixed all the zeroing problems.  Are you sure
you compiled your current up from the latest source?

I am presuming there are no other clients accessing the output files
while the split is running?

Also, change your blankcheck program to display the ranges in hex,
doing so brings to light the pattern.

: fileaa
: fileab
: 168173568-168179199(5632) A062000-A063FFF
: 384966656-384972287(5632) 16F22000-16F235FF

Interesting.  It looks very similar to a problem we fixed months ago.
That problem was related only to NFSv3 and mmap(), and you aren't using
mmap() here.  It's disturbing to see this problem occur with both NFSv2
and NFSv3.

I wonder if the problem occurs between a FreeBSD client and server.

-Matt
Matthew Dillon 
<[EMAIL PROTECTED]>

:All the zeroed out blocks start on an 8k NFS boundary, and I have
:verified that the rest of the 8k block has the correct data in it. 
:Each corrupted block is always a multiple of 512 bytes long (so far
:multiples are 6, 7, 11, and 12).
:
:On this example run, each file either has no corruption at all, or has
:corruption with all the zeroed out ranges the same size.  Dunno if this
:matters, but it's interesting.
:
:If I run without nfsiod, or copy from a remote NFS mount to a remote
:NFS mount, the corruption goes way down but still happens.  I got only
:one corrupted block in my 7-gig test run in each of those test cases. 
:
:I'm afraid I don't know much about the internal workings of NFS, so I'm
:hoping my description is enough to pinpoint the problem.  
:
:-- 
:   Dan Nelson
:   [EMAIL PROTECTED]




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



HEADS UP: if_dc imports, al, ax, pn, dc and mx removed

1999-12-04 Thread Bill Paul

Heads up people: the if_dc driver and all its bits and pieces are now
in the tree and the al, ax, dm, pn and mx drivers have been removed.
People previously using these drivers need to update their /etc/rc.conf
files accordingly. Also note that if_dc should now handle 21143-based
NICs. If you were previously using if_de for a 21143 card, you may
see if_dc take over support for it depending on your kernel config.
If you have a 21143-based NIC which worked with if_de and *doesn't*
work with if_dc, please let me know ASAP. Most 10/100 NICs should
work fine: the only questionable ones are 10Mbps only versions. If
you have a NIC that doesn't work, please show me the output of
pciconf -l from your system when reporting a problem.

As usual, the place to complain is: [EMAIL PROTECTED]

-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: ide dma support not enabled

1999-12-04 Thread Richard S. Straka

Bruce Evans wrote:

> On Fri, 3 Dec 1999, Richard S. Straka wrote:
>
> > A kernel built from current source which was cvsup'ed today at
> > approximately 10:00 pm MST no longer enables DMA support on my
> > IDE drives. A previous kernel from 27 Nov had no  problems
> > recognizing and enabling IDE DMA support.
>
> This was broken in rev.1.132 of sys/pci.pci.c.
>
> Quick fix (ifdef away rev.1.132):
>
> diff -c2 pci.c~ pci.c
> *** pci.c~  Sat Dec  4 20:08:44 1999
> --- pci.c   Sat Dec  4 22:28:37 1999
> ***
> *** 879,884 
> --- 879,888 
> if (name) {
> device_set_desc_copy(dev, name);
> + #ifdef WANT_BROKEN_IDE_PCI
> /* Allow newbus drivers to match "better" */
> error = -1000;
> + #else
> +   error = 0;
> + #endif
> }
> }
>
> Bruce


Bruce,

Works like a champ.  IDE DMA is back.

Thanks,

Rich Straka
[EMAIL PROTECTED]



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



Re: incorrect output in pstat -s

1999-12-04 Thread Bruce Evans

On Sat, 4 Dec 1999, Philippe Charnier wrote:

> Hello,
> 
> Running pstat -s, I get:
> 
> Device  1K-blocks UsedAvail Capacity  Type
> /dev/rda0s2b1318080   131808 0%Interleaved
> /dev/rda1s1b 66432066432 0%Interleaved
> /dev/rda2s1b 32640032640 0%Interleaved
> /dev/rda3s1b 32640032640 0%Interleaved
> Total  2635200   263520 0%
> 
> Which I corrected with the following changes. Printing /dev/da... instead
> of /dev/rda... is maybe a better fix?

Printing the 'r's is a temporary bug (*).  The extra column that you added
is required anyway for printing 2-digit unit numbers in "/dev/rda10s1b".
One more column is required for printing 3-digit unit numbers in
"/dev/rda100s1b".  We support unit numbers up to 511, except for bugs like
this.  Several more columns are required for printing verbose driver names
like "amrd".

(*) If you have a current -current with /dev/da0s2b being a character
device with the same device number as /dev/rda0s2b, then dev_mkdb(8)
won't be able to create a one to one mapping between disk numbers and
disk names.  If /dev/da0s2b is still a block device, then there are
more confusing aliasing problems due to the kernel translating the
device numbers of bdevs without translating the corresponding names.

Bruce



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



Re: Problem with syscons in VESA mode

1999-12-04 Thread Jeroen Ruigrok/Asmodai

-On [19991202 19:24], Maxim Sobolev ([EMAIL PROTECTED]) wrote:
>Tony Finch wrote:
>> Maxim Sobolev <[EMAIL PROTECTED]> wrote:
>> >
>> >but sometimes when I'm building world or some other app text
>> >suddenly shifts from the edge of the screen by several spaces and
>> >all text passed to the console after that also being printed with
>> >that offset.
>>
>> I've seen this on -stable with standard large modes set by
>> vidcontrol.
>
>It is interesting. Seems like it is not only VESA modes bug. Strange
>that nobody else observed this misbehaviour.

I see exact the same behaviour.  When I switch between vty's the cursor
seems to move back to the position where it should've been and when I
press enter the new lines start at the normal position again.

This is in VESA_132x25 using:

VESA: v2.0, 4096k memory, flags:0x0, mode table:0xc02cc1c8 (1a8)
VESA: Tseng Labs ET6000

-- 
Jeroen Ruigrok van der Werven/Asmodai  asmodai(at)wxs.nl
The BSD Programmer's Documentation Project 
Network/Security SpecialistBSD: Technical excellence at its best
Learn e-mail netiquette: http://www.lemis.com/email.html
...fools rush in where Daemons fear to tread.


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



Re: -current no longer builds on the alpha

1999-12-04 Thread Matthew Jacob



> As Matthew Jacob wrote ...
> > 
> > Q'uelle strange- what I have... well, we'll see what my nightly build
> > brings...
> 
> Mine fell over in 'truss'. I already reported it to Marcel, looks
> like something was changed in kdump/mkioctls, a script that 'truss' also
> uses.

Mine's still going (I start mine at 0430 PST8PDT, the update from
freefall runs at 0107 PST8PDT)) Nope, what a coincidence. It *just*
finished. Went all the way through w/o errors on a buildworld.

> 
> > 
> > On Fri, 3 Dec 1999, Jordan K. Hubbard wrote:
> > 
> > > > What is beast? I was happily able to build -current at about 5 this
> > > > morning on a pc164.
> > > 
> > > It's an Aspen systems DEC Durango PC164 motherboard based system.
> 
> Doesn't that one have ECC memory (refering to a previous post where
> you theorised a bit on memory problems and sig-11s ;)

It may or may not, but memory problems are typically detected pretty well
on alphas and you'll get a 670 machine check if it was recoverable (which
the PALcode has already done, except for TurboLaser if the memory problem
was caused by one of the I/O boards (PALcode cannot go offboard to read
registers on another board to find out what address was porked, IIRC)), or
a 660 machine check, which is a panic. At any rate, this is a different
entry point than mmu traps.

It's not like I don't get sig-11s... ctags always seems to core dump on
me- somewhere up in libc.

-matt




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



incorrect output in pstat -s

1999-12-04 Thread Philippe Charnier

Hello,

Running pstat -s, I get:

Device  1K-blocks UsedAvail Capacity  Type
/dev/rda0s2b1318080   131808 0%Interleaved
/dev/rda1s1b 66432066432 0%Interleaved
/dev/rda2s1b 32640032640 0%Interleaved
/dev/rda3s1b 32640032640 0%Interleaved
Total  2635200   263520 0%

Which I corrected with the following changes. Printing /dev/da... instead
of /dev/rda... is maybe a better fix?

Index: pstat.c
===
RCS file: /home0h/FreeBSD.cvsroot/src/usr.sbin/pstat/pstat.c,v
retrieving revision 1.46
diff -u -r1.46 pstat.c
--- pstat.c 1999/11/27 17:03:07 1.46
+++ pstat.c 1999/12/04 13:42:02
@@ -996,13 +996,13 @@
 
header = getbsize(&hlen, &blocksize);
if (totalflag == 0) {
-   (void)printf("%-11s %*s %8s %8s %8s  %s\n",
+   (void)printf("%-12s %*s %8s %8s %8s  %s\n",
"Device", hlen, header,
"Used", "Avail", "Capacity", "Type");
 
for (i = 0; i < n; ++i) {
(void)printf(
-   "%-11s %*d ",
+   "%-12s %*d ",
kswap[i].ksw_devname,
hlen,
CONVERT(kswap[i].ksw_total)
@@ -1029,7 +1029,7 @@
);
} else if (n > 1) {
(void)printf(
-   "%-11s %*d %8d %8d %5.0f%%\n",
+   "%-12s %*d %8d %8d %5.0f%%\n",
"Total",
hlen, 
CONVERT(kswap[n].ksw_total),

---- 
Philippe Charnier charnier@{lirmm.fr,xp11.frmug.org,FreeBSD.org}

``a PC not running FreeBSD is like a venusian with no tentacles'' 



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



Re: Importing OpenSSL

1999-12-04 Thread Garrett Wollman

< said:

> NO.  There are not patent problems until you *USE* the code.

That's not clear.  See also ``contributory infringement''.

-GAWollman

--
Garrett A. Wollman   | O Siem / We are all family / O Siem / We're all the same
[EMAIL PROTECTED]  | O Siem / The fires of freedom 
Opinions not those of| Dance in the burning flame
MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick


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



Re: ide dma support not enabled

1999-12-04 Thread Bruce Evans

On Fri, 3 Dec 1999, Richard S. Straka wrote:

> A kernel built from current source which was cvsup'ed today at
> approximately 10:00 pm MST no longer enables DMA support on my
> IDE drives. A previous kernel from 27 Nov had no  problems
> recognizing and enabling IDE DMA support.

This was broken in rev.1.132 of sys/pci.pci.c.

Quick fix (ifdef away rev.1.132):

diff -c2 pci.c~ pci.c
*** pci.c~  Sat Dec  4 20:08:44 1999
--- pci.c   Sat Dec  4 22:28:37 1999
***
*** 879,884 
--- 879,888 
if (name) {
device_set_desc_copy(dev, name);
+ #ifdef WANT_BROKEN_IDE_PCI
/* Allow newbus drivers to match "better" */
error = -1000;
+ #else
+   error = 0;
+ #endif
}
}

Bruce



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



Re: More crashes under heavy exec() load in -CURRENT (and strangesavecore)

1999-12-04 Thread Bruce Evans

> #0  boot (howto=256) at ../../kern/kern_shutdown.c:273
> 273 dumppcb.pcb_cr3 = rcr3();
> (kgdb) bt
> #0  boot (howto=256) at ../../kern/kern_shutdown.c:273
> #1  0xc0132295 in panic (fmt=0xc0244fcf "page fault") at 
>../../kern/kern_shutdown.c:523
> #2  0xc02158e2 in trap_fatal (frame=0xcf71ad9c, eva=0) at ../../i386/i386/trap.c:908
> #3  0xc0215595 in trap_pfault (frame=0xcf71ad9c, usermode=0, eva=0) at 
>../../i386/i386/trap.c:801
> #4  0xc0215167 in trap (frame={tf_fs = 16, tf_es = 16, tf_ds = 16777232, tf_edi = 0, 
>tf_esi = -1071179392, tf_ebp = -814633492, 
>   tf_isp = -814633528, tf_ebx = -1071179392, tf_edx = 0, tf_ecx = 11, tf_eax = 
>0, tf_trapno = 12, tf_err = 2, 
>   tf_eip = -1071807687, tf_cs = 8, tf_eflags = 66118, tf_esp = -1071172824, 
>tf_ss = -814624768})
> at ../../i386/i386/trap.c:425
> #5  0xc01d8339 in _vm_map_clip_end (map=0xc0273328, entry=0xc0271980, 
>end=3480358912) at ../../vm/vm_map.c:835
> #6  0xc01d93bf in vm_map_delete (map=0xc0273328, start=3480342528, end=3480358912) 
>at ../../vm/vm_map.c:1751
> #7  0xc01d9536 in vm_map_remove (map=0xc0273328, start=3480342528, end=3480358912) 
>at ../../vm/vm_map.c:1822
> #8  0xc01d747d in kmem_free (map=0xc0273328, addr=3480342528, size=16384) at 
>../../vm/vm_kern.c:233
> #9  0xc0141731 in pipeclose (cpipe=0xccd40a20) at ../../kern/sys_pipe.c:1093
> #10 0xc014161d in pipe_close (fp=0xc3154540, p=0xcf67a300) at 
>../../kern/sys_pipe.c:1049

PR 15235 has some fixes for pipe bugs.

Bruce



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



Re: rpc.umntall does not work with AIX [LONG]

1999-12-04 Thread Martin Blapp


Hi,

> Well, it seems like RPCMNT_UMNTALL call always fails with RPC_SYSTEMERROR on
> all systems except FreeBSD. I tested HP/UX, AIX and Solaris boxes - they all
> behave identically as follows:

exactly. The other systems reply is 5, which is MNT_IOERR for the
authentification handle. I still do not know the reason for this.
The call iteslf gets accepted and executed on the remote system.

> rpc.umntall -h $HOST always fails
> rpc.umntall -h $HOST -p $DIR - works just fine since it is using RPCMNT_UMOUNT
> umount $HOST:$DIR works just fine
> 
> Interesting, even if RPC_UMNTALL call returns error code, it nonetheless
> causes mount entry to be removed from the server, i.e. showmount -a $HOST
> output does not report my client machine as having any mounts on $HOST anymore.
> 
> All entries in my /var/db/mounttab appear to be correct, I do not think they
> are causing the problem. 
> 
> Also, I have questions regarding the following code fragment from the
> rpc.umntall.c file:

I'll fix this.

> 
> 
> It seems like it does RPCMNT_UMNTALL call for each mounttab entry regardless of
> the -k parameter passed in the command line, while man page suggests that
> it should simply skip entries for currently mounted filesystems.
> 
> 
> Furthermore, using RPC_UMNTALL in the above loop is probably not a good idea
> either because client host may have two different directories mounted from the
> same server. If -k flag is specified, you cannot use UMNTALL because it will
> remove /var/run/mountdtab entries not only for the mount point left over
> from the crash but also for all other mounts some of which may be perfectly 
> valid and should be kept intact.

I'll add a check for this. Probably it is better to kill use UMNT instead
of UMNTALL as you said.

Martin



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



Re: Importing OpenSSL

1999-12-04 Thread sthaug

> > It looks like they distribute RSA to everyone, including the US mirrors,
> > and it's not built by default unless you take explicit action to enable it
> > (i.e. it just builds a subset of the full distribution). Last time I
> 
> Hmm, according to their own press, there's some mechanism more clever
> than that which automatically downloads the "appropriate" RSA code for
> US vs non-US people.

Theo de Raadt posted the following to BUGTRAQ a couple of days ago
(extract).

"OpenBSD ships with applications using public key cryptography.
Because we are trying to make release CDROMs for the entire world, we
cannot put RSA onto the CD (yeah, major bummer).  Instead, we've made
it so that the RSA patented code stays in a package containing some
shared libraries, and our installation software installs this package
from over the 'net.

Each package contains two shared libraries: libcrypto and libssl; just
like regular OpenSSL.  People outside the USA can use these two
libraries, found in the "ssl26" package.  Non-commercial entities in
the USA cannot -- because of the patent issue -- and for them we
provide the "sslUSA26" package.  Commercial entities in the USA must
contact RSA for a licence, or wait till next September.

The "sslUSA26" package is OpenSSL, like the other package, but we have
removed the OpenSSL RSA code and replaced it with RSAREF2.  This
permits the non-commercial use of "sslUSA26" inside the USA.
Commercial users who think they can use the RSA without a licence in
the USA should see a lawyer and a therapist."

Steinar Haug, Nethelp consulting, [EMAIL PROTECTED]


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



Re: Is there anything special to do for a first time cvsup to current

1999-12-04 Thread Wilko Bulte

As Yusuf Goolamabbas wrote ...
> Hi, I have been doing cvsup to -stable and buildworlds for close to a
> year and have subscribed to the cvs-all list , I read archives of
> -current/-stable regularly and recently decided to do my first cvsup
> -current
> 
> After moving to -current, I did a /usr/sbin/config  and it
> complained about "machine i386" and cpu "I386_CPU". Do I have to do
> anything diffent for -current compared to -stable

Loose the "" 

See the LINT file that comes with -current

-- 
|   / o / /  _  Arnhem, The Netherlands   - Powered by FreeBSD -
|/|/ / / /( (_) Bulte   WWW : 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: -current no longer builds on the alpha

1999-12-04 Thread Wilko Bulte

As Matthew Jacob wrote ...
> 
> Q'uelle strange- what I have... well, we'll see what my nightly build
> brings...

Mine fell over in 'truss'. I already reported it to Marcel, looks
like something was changed in kdump/mkioctls, a script that 'truss' also
uses.

> 
> On Fri, 3 Dec 1999, Jordan K. Hubbard wrote:
> 
> > > What is beast? I was happily able to build -current at about 5 this
> > > morning on a pc164.
> > 
> > It's an Aspen systems DEC Durango PC164 motherboard based system.

Doesn't that one have ECC memory (refering to a previous post where
you theorised a bit on memory problems and sig-11s ;)

-- 
|   / o / /  _  Arnhem, The Netherlands   - Powered by FreeBSD -
|/|/ / / /( (_) Bulte   WWW : 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: Importing OpenSSL

1999-12-04 Thread David O'Brien

> Last time I raised this, a few people expressed concerns about their
> mirrors carrying patented code which might cause them legal issues,

NO.  There are not patent problems until you *USE* the code.
The issue is the export of encryption from the US.  That is the concern
with RSA and IDEA.  You will probably need to import RSA, IDEA, etc the
same way we do DES.  In a separate area, and then have
Internat.FreeBSD.org import it also.

-- 
-- David([EMAIL PROTECTED])


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



Re: Importing OpenSSL

1999-12-04 Thread Kris Kennaway

On Sat, 4 Dec 1999, Jordan K. Hubbard wrote:

> > It looks like they distribute RSA to everyone, including the US mirrors,
> > and it's not built by default unless you take explicit action to enable it
> > (i.e. it just builds a subset of the full distribution). Last time I
> 
> Hmm, according to their own press, there's some mechanism more clever
> than that which automatically downloads the "appropriate" RSA code for
> US vs non-US people.

Perhaps it's different in 2.6: I checked a US mirror which only carried
2.5. I'll look for a 2.6 one..

Kris



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



Re: Importing OpenSSL

1999-12-04 Thread Jordan K. Hubbard

> It looks like they distribute RSA to everyone, including the US mirrors,
> and it's not built by default unless you take explicit action to enable it
> (i.e. it just builds a subset of the full distribution). Last time I

Hmm, according to their own press, there's some mechanism more clever
than that which automatically downloads the "appropriate" RSA code for
US vs non-US people.

- Jordan


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



Is there anything special to do for a first time cvsup to current

1999-12-04 Thread Yusuf Goolamabbas

Hi, I have been doing cvsup to -stable and buildworlds for close to a
year and have subscribed to the cvs-all list , I read archives of
-current/-stable regularly and recently decided to do my first cvsup
-current

After moving to -current, I did a /usr/sbin/config  and it
complained about "machine i386" and cpu "I386_CPU". Do I have to do
anything diffent for -current compared to -stable

Cheers, Yusuf
-- 
Yusuf Goolamabbas
[EMAIL PROTECTED]


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



Re: Importing OpenSSL

1999-12-04 Thread Kris Kennaway

On Fri, 3 Dec 1999, Jordan K. Hubbard wrote:

> I think you should look at exactly how OpenBSD 2.6 has integrated it
> and then report back with your amended proposal. :-)

It looks like they distribute RSA to everyone, including the US mirrors,
and it's not built by default unless you take explicit action to enable it
(i.e. it just builds a subset of the full distribution). Last time I
raised this, a few people expressed concerns about their mirrors carrying
patented code which might cause them legal issues, but the "default is no
RSA" policy is the same as what I proposed.

Unfortunately, that will probably mean no openssh out of the box, since it
depends on RSA :-(

Kris



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