Re: fxp0 device timeout on 5.0-RELEASE

2003-01-31 Thread Georg-W. Koltermann
Am Do, 2003-01-30 um 12.41 schrieb Sergey A. Osokin:

 3) Put hw.pci.allow_unsupported_io_range=1 into your
 /boot/loader.conf.local

Thanks, that did the trick.

Could we, maybe, add a little note about this to the release notes or
errata?  Or better yet, how about a big fat warning message if the
kernel probes a device at an unsupported address while
hw.pci.allow_unsupported_io_range==0?

--
Regards,
Georg.



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



Re: Seat-belt for source upgrades from stable to current

2003-01-31 Thread Ruslan Ermilov
On Wed, Jan 29, 2003 at 10:35:40PM -0500, Garance A Drosihn wrote:
 At 9:18 PM +0200 1/29/03, Sheldon Hearn wrote:
 Can anyone think of a good way to implement an installworld /
 installkernel seat-belt for source upgrades from stable to current?
 
 What I'm looking for is a way for installworld and installkernel
 in the current source to look for some signature in the target
 filesystem that suggests that a stable world is about to be
 upgraded to current.
 
 How about requiring the user to touch some file in / or /boot which
 indicates the branch-tag that's acceptable for installworlds?  Then
 you just need to propagate the tag from the 'cvs co' stage to some
 file under /usr/src (such as /usr/src/CVS/Tag ).
 
That's exactly the case when upgrading from -stable to -current.
Installkernel should be the first thing to install, and it will
complain with:

: You must set up a /boot/device.hints file first.

 So, maybe compare /usr/src/CVS/Tag to /boot/BRANCH_TAG, where the
 second file has to be typed in by the user, by hand.  Eh, maybe
 /boot isn't the right place for it.  Well, maybe /.branch_tag
 
 [1] Guess who just trashed a stable installation for the 3rd time
 in 3 years today?
 
 Well, I almost would have done the same thing in my latest 4.7
 install, but when I cd'ed into sys/i386/conf I thought it was
 odd that there was a GENERIC.hints file sitting there...  If
 it wasn't for my desire to compile an SMP kernel instead of
 GENERIC, I might not have noticed until it was too late!!
 
We could expand the ``installcheck'' target in Makefile.inc1 to
ask the user if he actually wants to upgrade from `uname -r`
(the running kernel) to what appears to be an argument to
cvs update in the ``update'' target in the same makefile
(-A for HEAD, and RELENG_* otherwise).

Running uname(1) from ${.OBJDIR} is a bad idea as it may not be
runnable at all.


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

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



msg51330/pgp0.pgp
Description: PGP signature


Re: Seat-belt for source upgrades from stable to current

2003-01-31 Thread Ruslan Ermilov
On Thu, Jan 30, 2003 at 11:33:16PM -0500, Mike Makonnen wrote:
 On Thu, 30 Jan 2003 20:05:06 -0800
 David Schultz [EMAIL PROTECTED] wrote:
 
  
  That's a great answer...to a different question.  ;-)
  
 
 Use the r version of the cvs commands (like cvs rlog and rdiff). They operate on
 the repository remotely, so you don't need to have the files checked out localy.
 
Er, rlog is just a synonym for log.


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

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



msg51331/pgp0.pgp
Description: PGP signature


Re: Seat-belt for source upgrades from stable to current

2003-01-31 Thread Ruslan Ermilov
On Thu, Jan 30, 2003 at 09:58:15PM -0800, David Schultz wrote:
 Thus spake Christopher Vance [EMAIL PROTECTED]:
  On Thu, Jan 30, 2003 at 09:07:11PM -0800, Steve Kargl wrote:
  : On Thu, Jan 30, 2003 at 08:05:06PM -0800, David Schultz wrote:
  :  Thus spake Steve Kargl [EMAIL PROTECTED]:
  :   On Thu, Jan 30, 2003 at 07:09:16PM -0800, David Schultz wrote:
  :OT: Is there a good way to get the CVS metadata in /usr/src and
  :/usr/ports without transferring the entire source tree over the
  :network?  On some machines, I'd like to be able to do a CVS
  :{diff,log,update} now and then, but I don't have the disk space
  :for the entire repository.  I usually end up blowing away /usr/src
  :and fetching a new copy from a CVS server, but I'm sure this is
  :far from ideal for the people who pay for that server's bandwidth.
  :
  :   
  :   anoncvs
  :   
  :   See the handbook for info.
  :  
  :  That's a great answer...to a different question.  ;-)
  : 
  : It's the correct answer.  I assumed that you knew
  : how to use cvs.
  
  cvsup gets me everything I need to track and compile both current and
  stable.
  
  I don't want to be forced into using cvs when there's a better tool
  available (for some definition of better).  I get paid to use cvs at
  work, and that's how I know to choose something else...
  
  For a while, I used to grab the whole repo (with cvsup), and used cvs
  to get current and stable out of it, but now I consider that a waste
  of space/time, and have reverted to just using cvsup to get the tags I
  want.
  
  I'm not a FreeBSD developer, and very rarely (just a handful of times)
  have had to modify existing stuff to do what I want, so I don't need
  my own repo to commit to.  With that, disappers any need to use cvs.
  
  Perhaps you can explain why cvsup is the wrong answer...
 
 I don't know about Steve, but cvsup is the wrong answer for me
 because it's a mirroring tool and not a version control tool.
 Among the things I would like to do are:
 
   - Update to a specific version of a specific file from the
 repository.
 
   - Generate a diff between two revisions in the repository,
 or between a version in the repository and some local
 patches of my own.
 
   - View logs for particular files.
 
 I asked the question in hopes that there would be some neat
 feature of cvsup that mocked up some CVS metadata for me, but
 since nobody has mentioned any such thing, I guess I'm out of
 luck.  Mirroring the entire repository is not an option on
 machines with less than 6 GB of spare disk.[1]  Transferring the
 entire source tree over the network via anoncvs is suboptimal when
 all I really want is a few kilobytes of 'CVS' subdirectories.
 But I guess it will have to do for now.
 
 
 [1] When the system is an aging dual PPro or 200MHz Alpha using
 SCSI, buying new drives is not practical.
 
Well then learn how to use anoncvs?


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

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



msg51332/pgp0.pgp
Description: PGP signature


Re: fxp0 device timeout on 5.0-RELEASE

2003-01-31 Thread Sergey A. Osokin
On Fri, Jan 31, 2003 at 09:32:07AM +0100, Georg-W. Koltermann wrote:
 Am Do, 2003-01-30 um 12.41 schrieb Sergey A. Osokin:
 
  3) Put hw.pci.allow_unsupported_io_range=1 into your
  /boot/loader.conf.local
 
 Thanks, that did the trick.
 
 Could we, maybe, add a little note about this to the release notes or
 errata?  Or better yet, how about a big fat warning message if the
 kernel probes a device at an unsupported address while
 hw.pci.allow_unsupported_io_range==0?

Yes, I send list of questions/answers about this problem to doc@.
Still no answer from. Anyway list avaliable from my home page:
http://ozz.pp.ru/eag.txt

-- 

Rgdz,/\  ASCII RIBBON CAMPAIGN
Sergey Osokin aka oZZ,   \ /AGAINST HTML MAIL
http://ozz.pp.ru/ X  AND NEWS
 / \

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



5.0-RELEASE ports.tgz file missing?

2003-01-31 Thread Dimitry Andric
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

I heard from several friends who did FTP installs of 5.0-RELEASE, that
the installer was unable to install the ports collection. So I checked
the various FTP sites, and to my amazement I couldn't find the
ports.tgz file on any of them!

See for example:

  ftp://ftp.freebsd.org/pub/FreeBSD/releases/i386/5.0-RELEASE/ports/
  ftp://ftp.nl.freebsd.org/pub/FreeBSD/releases/i386/5.0-RELEASE/ports/

or any other FreeBSD mirror sites. It is also the case for other
architectures.

However, on the 5.0-RELEASE i386 install CD I have here, there is such
a ports directory, with a ports.tgz file (and accompanying
CHECKSUM.MD5 and install.sh files).

Is this a deliberate omission on the FTP servers?

Cheers,
- --
Dimitry Andric [EMAIL PROTECTED]
PGP Key: http://www.xs4all.nl/~dim/dim.asc
Fingerprint: 7AB462D2CE35FC6D42394FCDB05EA30A2E2096A3
Lbh whfg ivbyngrq gur QZPN naq jvyy or cebfrphgrq

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

iQA/AwUBPjjeELBeowouIJajEQImXgCgrDTtvOu1EUBgJj/nzKmIz2E9/OkAn0h4
DsyEcnU3YAtJ5P2yhwXUQ5Kf
=5aHf
-END PGP SIGNATURE-


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



Re: fxp0 device timeout on 5.0-RELEASE

2003-01-31 Thread Tom Rhodes
On Fri, 31 Jan 2003 12:14:29 +0300
Sergey A. Osokin [EMAIL PROTECTED] wrote:

 On Fri, Jan 31, 2003 at 09:32:07AM +0100, Georg-W. Koltermann wrote:
  Am Do, 2003-01-30 um 12.41 schrieb Sergey A. Osokin:
  
   3) Put hw.pci.allow_unsupported_io_range=1 into your
   /boot/loader.conf.local
  
  Thanks, that did the trick.
  
  Could we, maybe, add a little note about this to the release notes
  or errata?  Or better yet, how about a big fat warning message if
  the kernel probes a device at an unsupported address while
  hw.pci.allow_unsupported_io_range==0?
 
 Yes, I send list of questions/answers about this problem to doc@.
 Still no answer from. Anyway list avaliable from my home page:
 http://ozz.pp.ru/eag.txt
 
 -- 
 
 Rgdz,/\  ASCII RIBBON CAMPAIGN
 Sergey Osokin aka oZZ,   \ /AGAINST HTML MAIL
 http://ozz.pp.ru/ X  AND NEWS
  / \

I was actually adding something when this email came into my mailbox.
Sorry for not picking up on this before.

--
Tom Rhodes

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



Re: 5.0-RELEASE ports.tgz file missing?

2003-01-31 Thread Scott Long
Dimitry Andric wrote:


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

I heard from several friends who did FTP installs of 5.0-RELEASE, that
the installer was unable to install the ports collection. So I checked
the various FTP sites, and to my amazement I couldn't find the
ports.tgz file on any of them!

See for example:

  ftp://ftp.freebsd.org/pub/FreeBSD/releases/i386/5.0-RELEASE/ports/
  ftp://ftp.nl.freebsd.org/pub/FreeBSD/releases/i386/5.0-RELEASE/ports/

or any other FreeBSD mirror sites. It is also the case for other
architectures.

However, on the 5.0-RELEASE i386 install CD I have here, there is such
a ports directory, with a ports.tgz file (and accompanying
CHECKSUM.MD5 and install.sh files).

Is this a deliberate omission on the FTP servers?

Cheers,
- --



Fixed on ftp-master, so it should work it's way out to the mirrors over 
the next few days.  I'm not sure if this is an accidental or intended 
breakage of the release scripts, but many previous releases on FreeBSD 
have the ports directory in the FTP distro.

Scott


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


Re: copy extended attributes

2003-01-31 Thread Daniel C. Sobral
I'm starting to have a bad feeling about mergemaster and /etc's full of 
acl and mac labels...

Robert Watson wrote:

I have local patches submitted by Chris Faulhaber to copy ACLs when a file
is copied (or moved between file systems) that I've been meaning to finish
testing and merge.  Likewise, for gzip, bzip, and others when a file is
replaced.  This wouldn't address the general issue of copying extended
attributes, but is a necessary step.  Presumably if we did extend cp, et
al, to copy EA's, they should explicitly copy only user namespace EAs, not
system EAs.   There's been some recent e-mail on the Linux side about
interfaces to copy ACLs from one file to another, but I haven't had a
chance to review those changes as yet to see whether we should pick them
up.


--
Daniel C. Sobral   (8-DCS)
Gerencia de Operacoes
Divisao de Comunicacao de Dados
Coordenacao de Seguranca
TCO
Fones: 55-61-313-7654/Cel: 55-61-9618-0904
E-mail: [EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]

Outros:
	[EMAIL PROTECTED]
	[EMAIL PROTECTED]
	[EMAIL PROTECTED]

There once was a jolly old bloke
Who picked up a girl for a poke.
	He took down her pants,
	Fucked her into a trance,
And then shit into her shoe for a joke.


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



Cisco vpnclient

2003-01-31 Thread Christoph Kukulies

Cisco is offering a VPN client for Linux. I wonder if it would be possible
to run this under FreeBSD. An extra linux kernel module is being built.
Is this already the 'ruled out'?

If this won't work, I'm afraid I will have to set a dedicated redhat 6.x/7.x
beside my FreeBSD gateway. Would it be possible to use NAT to
extend the VPN (I only have one dedicated fixed IP on the gateway).

Excuse if this is not exactly on target of -current.

--
Chris Christoph P. U. Kukulies [EMAIL PROTECTED]

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



Re: Profiling kills -current?

2003-01-31 Thread Tim Robbins
On Thu, Jan 30, 2003 at 04:17:39PM -0500, Robert Watson wrote:

 Looks like recent commits may have broken profiling of user applications; 
 or rather, it's also causing the kernel to crash.  I suspect (but have not
 confirmed) it was the recent KSE commit.

This commit should have fixed the problem causing the system to lock up
when profiling was used. A quick check shows that it's generating reasonable
results now, but I believe that there are other profiling bugs in -current.

==

tjr 2003/01/31 03:22:32 PST

  Modified files:
sys/kern subr_trap.c 
  Log:
  Use a local variable to store the number of ticks that elapsed in
  kernel mode instead of (unintentionally) using the global `ticks'.
  This error completely broke profiling.
  
  Revision  ChangesPath
  1.241 +3 -2  src/sys/kern/subr_trap.c

==


Tim

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



alpha tinderbox failure

2003-01-31 Thread Dag-Erling Smorgrav
--
 Rebuilding the temporary build tree
--
 stage 1: bootstrap tools
--
 stage 2: cleaning up the object tree
--
 stage 2: rebuilding the object tree
--
 stage 2: build tools
--
 stage 3: cross tools
--
 stage 4: populating /home/des/tinderbox/alpha/obj/h/des/src/alpha/usr/include
--
 stage 4: building libraries
--
 stage 4: make dependencies
--
 stage 4: building everything..
--
 Kernel build for GENERIC started on Fri Jan 31 03:09:35 PST 2003
--
 Kernel build for GENERIC completed on Fri Jan 31 03:40:44 PST 2003
--
 Kernel build for LINT started on Fri Jan 31 03:40:45 PST 2003
--
=== vinum
Makefile, line 4443: warning: duplicate script for target geom_bsd.o ignored
/h/des/src/sys/dev/lmc/if_lmc.c:32:2: warning: #warning The lmc driver is broken and 
is not compiled with LINT
/h/des/src/sys/dev/pdq/pdq.c: In function `pdq_initialize':
/h/des/src/sys/dev/pdq/pdq.c:1606: warning: cast discards qualifiers from pointer 
target type
/h/des/src/sys/pci/meteor.c:149:2: warning: #warning The meteor driver is broken and 
is not compiled with LINT
/h/des/src/sys/pci/simos.c:30:2: warning: #warning The simos driver is broken and is 
not compiled with LINT
/h/des/src/sys/dev/gfb/gfb_pci.c: In function `pcigfb_open':
/h/des/src/sys/dev/gfb/gfb_pci.c:268: `gfb_devclass' undeclared (first use in this 
function)
/h/des/src/sys/dev/gfb/gfb_pci.c:268: (Each undeclared identifier is reported only once
/h/des/src/sys/dev/gfb/gfb_pci.c:268: for each function it appears in.)
cc1: warnings being treated as errors
/h/des/src/sys/dev/gfb/gfb_pci.c:275: warning: passing arg 1 of `genfbopen' from 
incompatible pointer type
/h/des/src/sys/dev/gfb/gfb_pci.c: In function `pcigfb_close':
/h/des/src/sys/dev/gfb/gfb_pci.c:284: `gfb_devclass' undeclared (first use in this 
function)
/h/des/src/sys/dev/gfb/gfb_pci.c:285: warning: passing arg 1 of `genfbclose' from 
incompatible pointer type
/h/des/src/sys/dev/gfb/gfb_pci.c: In function `pcigfb_read':
/h/des/src/sys/dev/gfb/gfb_pci.c:293: `gfb_devclass' undeclared (first use in this 
function)
/h/des/src/sys/dev/gfb/gfb_pci.c:294: warning: passing arg 1 of `genfbread' from 
incompatible pointer type
/h/des/src/sys/dev/gfb/gfb_pci.c: In function `pcigfb_write':
/h/des/src/sys/dev/gfb/gfb_pci.c:302: `gfb_devclass' undeclared (first use in this 
function)
/h/des/src/sys/dev/gfb/gfb_pci.c:303: warning: passing arg 1 of `genfbwrite' from 
incompatible pointer type
/h/des/src/sys/dev/gfb/gfb_pci.c: In function `pcigfb_ioctl':
/h/des/src/sys/dev/gfb/gfb_pci.c:311: `gfb_devclass' undeclared (first use in this 
function)
/h/des/src/sys/dev/gfb/gfb_pci.c:312: warning: passing arg 1 of `genfbioctl' from 
incompatible pointer type
/h/des/src/sys/dev/gfb/gfb_pci.c: In function `pcigfb_mmap':
/h/des/src/sys/dev/gfb/gfb_pci.c:320: `gfb_devclass' undeclared (first use in this 
function)
/h/des/src/sys/dev/gfb/gfb_pci.c:321: warning: passing arg 1 of `genfbmmap' from 
incompatible pointer type
*** Error code 1

Stop in /h/des/obj/h/des/src/sys/LINT.
*** Error code 1

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

Stop in /h/des/src.

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



Re: 4.7-amd cannot mount exports from 5.0-RELEASE

2003-01-31 Thread Michael Nottebrock
Am Dienstag, 28. Januar 2003 21:52 schrieb Martin Blapp:
 Hi,

  Can this please be committed to or at least prepared as a patch for
  RELENG_5_0? I myself consider fixing automount access to 5.0-RELEASE nfs

 Feel free to add this patch:

 http://people.freebsd.org/~mbr/patches/committed/patch-rpc_oldreply.diff

I'm sorry to have to bother you further, but this patch does not solve the 
problem completely. Amd works partially now, but I still get 'mountd rpc 
failed: RPC: Unable to receive' errors when I try to access 
/host/hostname/otherexportthan / (nfsd on hostname exports / 
-alldirs,/usr -alldirs,/var -alldirs) and I can only access the / export. 

/host/ip-address/usr or /host/ip-address/var, where ip-address is the 
ip-address of the same machine as host above, works as expected.

-- 
Regards,
Michael Nottebrock

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



ACPI kernel: no ata0 / no ide disks

2003-01-31 Thread Thomas Stratmann
Hi everyone,

I finally got 5.0 of last week on my Tosh. Libretto 110ct
running. Took me several days of headache and bootstrap problems, nfs
mount and chroot finally solved my problems. (My laptop is a multiboot
box with a 4.7 FBSD as well so I could mount the filesystem dedicated to
the 5.0 system. I cast a naked 5.0 install onto my other box to do the
chrooted kernel/world compiling)

Currently I still have two serious problems with my 5.0 kernel, which is
in one case GENERIC itself and in the other basically GENERIC again,
except I commented out SCSI and USB stuff, uncommented several
debugging opts (I knew I would be running into trouble some time...) and
only   cpu I586_CPU   of the cpu lines.

I state both problems here since I think they could be related (but
probably are not).

Problem 1)
occurred with the GENERIC kernel, and as well with the new kernel when I
unset acpi_load
in the final boot stage (the aprop. module probably just didn't exist
prior installation of the custom kernel for some reason, so this all is
not about switching the kernel). The symptom is that booting seems to
hang (it turned out to be some kind of timeout of 5mins or so) at device
probing time right after
vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on
isa0
Booting -v showed that this delay happens in function
isa_probe_pnp_children (could as well be isa_pnp_probe_children or so).
When probing continues, the next five lines are of the kind
unknown: PNP0303 can't assign resources (port)
where one line has (irq) instead of (port). Sorry I have no means of
appending dmesg at this moment. So, it works, but booting means making
coffee in between.

Here some device topology of this setup that might be interesting for
problem 2:
ad0 at ata0-master, ata0 on isa0 on motherboard.
pci0 on pcib0 at pcibus 0 on motherboard.

Problem 2) occurred when the acpi module was loaded: the kernel found no
disks! The words 'isa' and 'ata' do not appear on the screen, but now my
pci topology is
pci0 on pcib0 on acpi0 on motherboard.
acpi0 is TOSHIB 750  (spaces exactly as on screen)

I'm new to acpi and not very good in hardware, so this is really
confusing to me. I cannot tell in what way this topology is normal or
abnormal, but I would like to use both acpi and my disk!

Another thing confuses me, maybe someone can give me some enlightenment:
Rebooting without acpi, I noticed that syslogd took long to start up,
together with lots of disk activity. dmesg showed the boot messages from
all previous boots (which probably syslogd spooled from somewhere, which
would explain the long startup and disk light), including the failed
boots with acpi support. Now, in these latter cases my kernel saw no
disk, so where did the information go that magically appeared later in
my dmesg? This is a riddle to me!

I would appreciate if someone could shed some light on this.
If you need more info (dmesg's out e.g.) drop me a mail at
[EMAIL PROTECTED] and I will post it to -current.

Cheers,
Thomas

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



Re: Seat-belt for source upgrades from stable to current

2003-01-31 Thread David Wolfskill
Date: Thu, 30 Jan 2003 21:58:15 -0800
From: David Schultz [EMAIL PROTECTED]

I asked the question in hopes that there would be some neat
feature of cvsup that mocked up some CVS metadata for me, but
since nobody has mentioned any such thing, I guess I'm out of
luck.  Mirroring the entire repository is not an option on
machines with less than 6 GB of spare disk.[1]...


In the interest of providing empirical data, since this thread is being
archived and someone might see the above and come to the conclusion that
6 GB of space is required for a full mirror of the CVS repository, I
offer:

freebeast(4.7-S)[1] cd /cvs
freebeast(4.7-S)[2] du -ks .
1649982 .
freebeast(4.7-S)[3] cd /usr/src
freebeast(4.7-S)[4] !2
du -ks .
321999  .
freebeast(4.7-S)[5] 


That's  a little over 1.6 GB for the CVS repo itself, plus 350 MB for
the /usr/src working directory.  (I do have a little bit of extra stuff
in the CVS repository for local things, but it isn't significant, and
certainly doesn't change the point, which is that about 2 GB appears to
be adequate at this time.)



[1] When the system is an aging dual PPro or 200MHz Alpha using
SCSI, buying new drives is not practical.

Given the price of hardware, it might be worth considering cobbling up a
separate box for the purpose.  You may have done this, and decided that
it's not worth the cost, or is otherwise inappropriate or ineffective.
That's fine: it's your problem and your resources, so how you choose to
allocate them is (and should be) your decision.  But any solution will
cost some resources.

For me, keeping a local mirror of the CVS repository works well enough
that I'm rather surprised that it isn't done by more folks.

Cheers,
david   (links to my resume at http://www.catwhisker.org/~david)
-- 
David H. Wolfskill  [EMAIL PROTECTED]
I have no confidence in results obtained through the use of Microsoft products.
david   (links to my resume at http://www.catwhisker.org/~david)
-- 
David H. Wolfskill  [EMAIL PROTECTED]
I have no confidence in results obtained through the use of Microsoft products.

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



Re: last KSE changes

2003-01-31 Thread Philip Paeps
On 2003-01-28 11:24:41 (-0800), Julian Elischer [EMAIL PROTECTED] wrote:
 The rumour mill has been running wild on this but **AS FAR AS I KNOW** the
 breakages have been fixed, since no-one has told me directl of any current
 breakages. If you have any breakage from this commit, PLEASE TELL ME!

Is this the sort of breakage you were expecting:

On an Alpha:

 | linking kernel
 | init_main.o: In function `proc0_init':
 | init_main.o(.text+0x428): undefined reference to `kse0_sched'
 | init_main.o(.text+0x434): undefined reference to `ksegrp0_sched'
 | init_main.o(.text+0x440): undefined reference to `proc0_sched'
 | init_main.o(.text+0x44c): undefined reference to `thread0_sched'
 | *** Error code 1
 | 
 | Stop in /usr/obj/usr/src/sys/PROSPERINA.
 | *** Error code 1
 | 
 | Stop in /usr/src.
 | *** Error code 1
 | 
 | Stop in /usr/src.

On an i386:

 | linking kernel
 | init_main.o: In function `proc0_init':
 | init_main.o(.text+0x2b9): undefined reference to `kse0_sched'
 | init_main.o(.text+0x2c3): undefined reference to `ksegrp0_sched'
 | init_main.o(.text+0x2cd): undefined reference to `proc0_sched'
 | init_main.o(.text+0x2d7): undefined reference to `thread0_sched'
 | kern_clock.o: In function `statclock_process':
 | kern_clock.o(.text+0x704): undefined reference to `sched_clock'
 | kern_condvar.o: In function `cv_wait':
 | kern_condvar.o(.text+0x18f): undefined reference to `sched_sleep'
 | kern_condvar.o: In function `cv_wait_sig':
 | kern_condvar.o(.text+0x3fa): undefined reference to `sched_sleep'
 | kern_condvar.o: In function `cv_timedwait':
 | kern_condvar.o(.text+0x738): undefined reference to `sched_sleep'
 | kern_condvar.o: In function `cv_timedwait_sig':
 | kern_condvar.o(.text+0xa3a): undefined reference to `sched_sleep'
 | kern_exit.o: In function `wait1':
 | kern_exit.o(.text+0x14aa): undefined reference to `sched_exit'
 | kern_fork.o: In function `fork1':
 | kern_fork.o(.text+0xece): undefined reference to `sched_fork'
 | kern_idle.o: In function `idle_proc':
 | kern_idle.o(.text+0xb6): undefined reference to `sched_runnable'
 | kern_mutex.o: In function `propagate_priority':
 | kern_mutex.o(.text+0x7a): undefined reference to `sched_prio'
 | kern_proc.o: In function `procinit':
 | kern_proc.o(.text+0xe9): undefined reference to `sched_sizeof_proc'
 | kern_proc.o: In function `fill_kinfo_proc':
 | kern_proc.o(.text+0x149b): undefined reference to `sched_pctcpu'
 | kern_resource.o: In function `donice':
 | kern_resource.o(.text+0x9f8): undefined reference to `sched_nice'
 | kern_subr.o: In function `uio_yield':
 | kern_subr.o(.text+0x59e): undefined reference to `sched_prio'
 | kern_switch.o: In function `choosethread':
 | kern_switch.o(.text+0x9): undefined reference to `sched_choose'
 | kern_switch.o: In function `kse_reassign':
 | kern_switch.o(.text+0x147): undefined reference to `sched_add'
 | kern_switch.o: In function `adjustrunqueue':
 | kern_switch.o(.text+0x1dc): undefined reference to `sched_rem'
 | kern_switch.o(.text+0x1e4): undefined reference to `sched_add'
 | kern_switch.o(.text+0x218): undefined reference to `sched_rem'
 | kern_switch.o: In function `setrunqueue':
 | kern_switch.o(.text+0x313): undefined reference to `sched_rem'
 | kern_switch.o(.text+0x3cd): undefined reference to `sched_add'
 | kern_synch.o: In function `msleep':
 | kern_synch.o(.text+0x43b): undefined reference to `sched_sleep'
 | kern_synch.o: In function `mi_switch':
 | kern_synch.o(.text+0xc4a): undefined reference to `sched_switchout'
 | kern_synch.o(.text+0xc66): undefined reference to `sched_switchin'
 | kern_synch.o: In function `setrunnable':
 | kern_synch.o(.text+0xd6b): undefined reference to `sched_wakeup'
 | kern_synch.o: In function `yield':
 | kern_synch.o(.text+0xfb9): undefined reference to `sched_prio'
 | kern_thread.o: In function `threadinit':
 | kern_thread.o(.text+0x1287): undefined reference to `sched_sizeof_thread'
 | kern_thread.o(.text+0x12d1): undefined reference to `sched_sizeof_ksegrp'
 | kern_thread.o(.text+0x131b): undefined reference to `sched_sizeof_kse'
 | subr_trap.o: In function `userret':
 | subr_trap.o(.text+0x1b): undefined reference to `sched_userret'
 | subr_trap.o: In function `ast':
 | subr_trap.o(.text+0x5ef): undefined reference to `sched_prio'
 | ksched.o: In function `ksched_attach':
 | ksched.o(.text+0x2e): undefined reference to `sched_rr_interval'
 | ksched.o: In function `ksched_setscheduler':
 | ksched.o(.text+0x2d6): undefined reference to `sched_prio'
 | ksched.o(.text+0x3c6): undefined reference to `sched_prio'
 | vm_zeroidle.o: In function `vm_pagezero':
 | vm_zeroidle.o(.text+0x40d): undefined reference to `sched_runnable'
 | vm_pageout.o: In function `vm_pageout_scan':
 | vm_pageout.o(.text+0x199c): undefined reference to `sched_nice'
 | machdep.o: In function `cpu_idle':
 | machdep.o(.text+0x166e): undefined reference to `sched_runnable'
 | *** Error code 1
 | 
 | Stop in /usr/obj/usr/src/sys/JUNO.
 | *** Error code 1
 | 
 | Stop in /usr/src.
 | 

5.0-R: no network connectivity with generic kernel andfirewall_enable=YES

2003-01-31 Thread Georg-W. Koltermann
Hi,

I couldn't connect to anything on the network with my 5.0-RELEASE, with
the generic kernel and rc.conf containing

firewall_enable=YES
natd_interface=fxp0
natd_interface=fxp0
natd_flags=-t 255.255.255.255

The firewall loaded ok but natd silently vanished.  When I tried to
start natd manually it complained about divert being an unknown
protocol.

It seems ipfw can be loaded as a module but divert needs to be compiled
into the kernel.  Should this be documented, e.g. by a prominent comment
in defaults/rc.conf, right by the side of firewall_enable?

--
Regards,
Georg.



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



Re: last KSE changes

2003-01-31 Thread Philip Paeps
On 2003-01-31 15:13:29 (+0100), Philip Paeps [EMAIL PROTECTED] wrote:
 On 2003-01-28 11:24:41 (-0800), Julian Elischer [EMAIL PROTECTED] wrote:
  The rumour mill has been running wild on this but **AS FAR AS I KNOW** the
  breakages have been fixed, since no-one has told me directl of any current
  breakages. If you have any breakage from this commit, PLEASE TELL ME!

[...]

 Haven't been able to build a kernel for about two/three days, and your
 commit looks like the one that might be the culprit... :-)

...and it wasn't :-)  Sorry about that.

 There's nothing particularly exciting in my config files, I don't think, but
 I've attached them anyway, just in case.

Sergey pointed out that I was missing a scheduler in my configs.  Quick read
through UPDATING shed light on the matter and the kernels build nicely again!

False alarm, sorry :-o

 - Philip

-- 
Philip Paeps  Please don't CC me, I am
[EMAIL PROTECTED]   subscribed to the list.

  As soon as the flight attendant serves the coffee, the
  airliner encounters turbulence.

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



Re: stropts.h removed?

2003-01-31 Thread Mike Barcroft
Kris Kennaway [EMAIL PROTECTED] writes:
 A number of ports have started to complain about a missing stropts.h
 header..was this recently removed, and if so then what is the fix?

I don't think we've ever supported STREAMS.

Best regards,
Mike Barcroft

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



psm not working on Toshiba 1905-s301 and 5.0 Release

2003-01-31 Thread Jason
I searched the archives, found a few similair problems, and possible
resolutions, but none have worked for me.

In windows, it is shown as an Alps Glidepoint on irq12, however fbsd
refuses to find it.

The device.hints file shows the correct info.  I ran acpidump, but was not
quite sure what to look for.  (In one of the posts involving a sony with
similair problems, someone said to check for MOUE which I suspect they
meant MOUSE to get the ID to modify psm.c, but neither exist in acpidump
results)

Any ideas?



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



ftpd mkdir problems

2003-01-31 Thread David Rhodus
Using the default ftpd that comes with FreeBSD, in the mkdir command, 
why doesn't it expand '~', the cd and rmdir commands seem to. Passing 
over the code it just calls the c function with should expand it.


ftp cd ~will
250 CWD command successful.
ftp mkdir ~will/test
550 ~will/test: No such file or directory.
ftp mkdir test
257 test directory created.
ftp rmdir ~will/test
250 RMD command successful.
ftp



--
David Rhodus


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


Re: Seat-belt for source upgrades from stable to current

2003-01-31 Thread Chris BeHanna
On Friday 31 January 2003 00:58, David Schultz wrote:
 Thus spake Christopher Vance [EMAIL PROTECTED]:
  On Thu, Jan 30, 2003 at 09:07:11PM -0800, Steve Kargl wrote:
  : On Thu, Jan 30, 2003 at 08:05:06PM -0800, David Schultz wrote:
  :  Thus spake Steve Kargl [EMAIL PROTECTED]:
  :   On Thu, Jan 30, 2003 at 07:09:16PM -0800, David Schultz wrote:
  :OT: Is there a good way to get the CVS metadata in /usr/src and
  :/usr/ports without transferring the entire source tree over the
  :network?  On some machines, I'd like to be able to do a CVS
  :{diff,log,update} now and then, but I don't have the disk space
  :for the entire repository.  I usually end up blowing away
  :/usr/src and fetching a new copy from a CVS server, but I'm sure
  :this is far from ideal for the people who pay for that server's
  :bandwidth.
  :  
  :   anoncvs
  :  
  :   See the handbook for info.
  : 
  :  That's a great answer...to a different question.  ;-)
  :
  : It's the correct answer.  I assumed that you knew
  : how to use cvs.
 
  [...Chris Vance explains why cvsup is all he needs...]
 
  Perhaps you can explain why cvsup is the wrong answer...

 I don't know about Steve, but cvsup is the wrong answer for me
 because it's a mirroring tool and not a version control tool.
 Among the things I would like to do are:

   - Update to a specific version of a specific file from the
 repository.

Anoncvs will let you do this.

cvs -D $ANONCVSROOT co -r$REVISION -d $WHERE_I_WANT_IT $WHERE_IT_IS

   - Generate a diff between two revisions in the repository,

You can use CVSweb for this quite ably.  That's not a great
solution for generating patches, but it's decent enough for trolling
around the repo.

 or between a version in the repository and some local
 patches of my own.

For that, you'd most easily check out the directory in which the
files in question live, copy your local version into it, and use cvs
diff.  The repo information is cached in the CVS/ subdir, so it all
works nicely:

cvs diff -u myfile.c

   - View logs for particular files.

CVSweb is your friend.  http://cvsweb.freebsd.org

 [...old machine, limited disk space, mirroring the entire repo
 infeasible...]

 Transferring the entire source tree over the network via anoncvs is
 suboptimal when all I really want is a few kilobytes of 'CVS'
 subdirectories.  But I guess it will have to do for now.

It's unnecessary.  Use the -d option to cvs co to check out the
subdirectories into a convenient place.

 [1] When the system is an aging dual PPro or 200MHz Alpha using
 SCSI, buying new drives is not practical.

If you can afford it, retire the box to mail/firewall duty.  A
bare-bones 2.4GHz P4 system can be had for $500US if you shop hard.

-- 
Chris BeHanna  http://www.pennasoft.com 
Principal Consultant
PennaSoft Corporation   
[EMAIL PROTECTED] 



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



RE: Smart Array 5312 (Compaq)

2003-01-31 Thread Cagle, John (ISS-Houston)
Thanks, Paul!

I talked to our storage experts and as long as the driver already has 5i
support, then all that's needed is to add the new id (which your patch
does).

Thanks,
John

John Cagle [EMAIL PROTECTED]
Principal Member Technical Staff
   Industry Standard Servers
Hewlett-Packard Company

 -Original Message-
 From: Paul Saab [mailto:[EMAIL PROTECTED]] 
 Sent: Thursday, January 30, 2003 7:46 PM
 To: John
 Cc: [EMAIL PROTECTED]
 Subject: Re: Smart Array 5312 (Compaq)
 
 
 Try this patch
 
 http://people.freebsd.org/~ps/ciss.diff
 
 John ([EMAIL PROTECTED]) wrote:
  Is anyone working on a driver for said raid controller?
  Here is a pciconf -lv (from 5.0-R) and a link for some info on the 
  card.
  
  
  ne3@pci6:2:0: class=0x010400 card=0x40830e11 
 chip=0xb1780e11 rev=0x01 hdr=0x00
  class= mass storage
  subclass = RAID
  
  
 http://h18004.www1.hp.com/products/servers/pro
liantstorage/arraycontro
  llers/smartarray5312/questionsanswers.html
  
  To Unsubscribe: send mail to [EMAIL PROTECTED]
  with unsubscribe freebsd-current in the body of the message
 
 -- 
 Paul Saab
 Technical Yahoo
 [EMAIL PROTECTED] - [EMAIL PROTECTED] - [EMAIL PROTECTED]
 Do You .. uhh .. Yahoo!?
 
 To Unsubscribe: send mail to [EMAIL PROTECTED]
 with unsubscribe freebsd-current in the body of the message
 

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



Re: Fun and excitement with CURRENT

2003-01-31 Thread Kevin Oberman
 From: stark [EMAIL PROTECTED]
 Date: 30 Jan 2003 22:43:33 -0500
 Sender: [EMAIL PROTECTED]
 
 OK, I've got just 1.5 bugs left, then I'll be all CURRENT-ed :)
 
 (I'm using a brand new laptop.  Much different than getting
 BSD working on my desktops and servers :)
 
 Things that work :
 - Making the third mouse button work on an IBM T30 (trackpoint 
   touchpad model) you have to disable the touchpad in the BIOS.
 
 - Making CURRENT compile on 4.7 involves NOT using cvsupit to
   do your cvsup-ing.  or using it and editing it to use src-all
   so you actually get the whole thing.
 
 - When compiling a kernel, don't be a smartass and assume you can
   make your 4.7 KERNCONF file work in 5.0.  start over with a 5.0
   GENERIC and modify it.  You'll feel MUCH less stupid later.
 
 - X on a Radeon mobility 7500 is PERFECT.  VERY VERY HAPPY! :)

I assume IBM is still using the Mobility M7? IF so, I would not say
perfect. Are you using XFree86-Server-4.2.1? If so, the Radeon
Mobility has two well known problems.

Less serious is that line acceleration is broken and some things that
re-draw lines fast will leave black lines on the display. You can
eliminate these artifacts if you run the CVS drivers and add the
option NoLineAccel to you configuration. This will be in 4.3.0 when
it is release in about 2 weeks.

If the display is turned off by BIOS (e.g. suspend, Fn-F3, or
time-out), the display will restart very badly scrambled. No known fix
for this that I have seen, although there is a work-around of
switching to a text virtual terminal before the display turns off or
by switching to a test virtual terminal after the display comes on and
then cycling the display off and on.

 - don't use apm and acpi at the same time.

That is sound advice on any system. In fact, it looks like APM should
check on the presence of ACPI when probing and bail out (with a
suitable error) if it finds ACPI.

Is there any case on any platform when both would make any sense at
all?

 UNFORTUNATELY, that last one has a solution :
 
 - DON'T USE ACPI.  It really causes a problem.
   If I turn acpi on (in kernel or as a module
   same result) it will die a horrible, horrible
   death.  I'll get more info (as in, the text
   it says when it crashes or the text it says
   when it boots or whatever) after a couple of
   reboots, but i was so happy it worked without
   acpi i'm typing this now.  debug later :)

Try the acpi-jp list. There are many ACPI issues with IBMs (and many
others) that are currently being discovered. I'm told that the latest
BIOS makes ACPI work better, but still not correctly.

 - Sound is really really weird.  pcm doesn't work
   with the i810 onboard (it works, but sound is
   all static-y to the point of inaudibility,
   and the OSS drivers seem to have a problem.
   I think the oss drivers don't seem to work
   without ACPI.  or at least not so far.  It
   worked once, just not since :)

Odd. I have not seen this to this point, but I am not running V5 on my
T30 at the moment and I may not have ever tried it. The sound is fine
with Stable.

 so there ya go, 1.5 bugs.  The ACPI took me quite
 a while to work around because every time it booted
 with it it crashed the system before I could do
 anything productive.  REALLY ANNOYING :)
 (Is there a way to tell the kernel not to AUTOLOAD
 ACPI on boot?  That would be SUPER :)

Yes. Stop the system at the countdown and enter unset acpi_load
for a one-time fix and then add the line 'hint.acpi.0.disabled=1' to
/boot/device.hints.

 Anyways, I'll keep the machine going and hopefully
 come up with some ACPI patches in the next few days
 that cause my laptop not to die a horrible death :)
 (If you have any such patches let me know! :)

ACPI patches would be greatly appreciated. If you find something,
please be sure that you send it to [EMAIL PROTECTED] (While the
-jp indicates a Japanese language list, I have never seen a message
that lacked an English translation and the majority of the messages
are all English.)

R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: [EMAIL PROTECTED]  Phone: +1 510 486-8634


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



Re: psm not working on Toshiba 1905-s301 and 5.0 Release

2003-01-31 Thread Thomas Moestl
On Fri, 2003/01/31 at 10:00:28 -0500, Jason wrote:
 I searched the archives, found a few similair problems, and possible
 resolutions, but none have worked for me.
 
 In windows, it is shown as an Alps Glidepoint on irq12, however fbsd
 refuses to find it.
 
 The device.hints file shows the correct info.  I ran acpidump, but was not
 quite sure what to look for.  (In one of the posts involving a sony with
 similair problems, someone said to check for MOUE which I suspect they
 meant MOUSE to get the ID to modify psm.c, but neither exist in acpidump
 results)
 
 Any ideas?

I have a Satellite 1110, ignoring port errors gets the glidepoint
detection to work. To do this, add

  hint.psm.0.flags=0x1000

(or-ed with any other flags you might want) to your device.hints.

On my notebook, that is not the only quirk this glidepoint has: it
completely stops sending interrupts as soon as you stop to move the
cursor for a bit. I have found no other solution to this problem but
to poll the glidepoint - this as the obvious disadvantage of
using up some CPU time ( 0.5%), making the mouse movement feel a bit
jittery and occasionally missing some very fast klicks. Since I do not
use the glidepoint overly much, I can live with that.
If your notebook has that problem too, I can supply a patch.

- Thomas

-- 
Thomas Moestl [EMAIL PROTECTED] http://www.tu-bs.de/~y0015675/
  [EMAIL PROTECTED] http://people.FreeBSD.org/~tmm/
PGP fingerprint: 1C97 A604 2BD0 E492 51D0  9C0F 1FE6 4F1D 419C 776C

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



Re: psm not working on Toshiba 1905-s301 and 5.0 Release

2003-01-31 Thread Stuart Barkley
On Fri, 31 Jan 2003 at 10:00 -0500, Jason wrote:

 I searched the archives, found a few similair problems, and possible
 resolutions, but none have worked for me.

Perhaps you have already seen my Toshiba Satellite 1005-S157 page
which discusses a similar problem.  See:

http://www.4gh.net/hints/toshiba/satellite1005-s157.html

In November you where trying 5.0 DP2 on a Toshiba 1901-S301.  Is this
the same machine?  Did the suggestions to disable EISA and/or SCSI
help in booting or has 5.0-RELEASE addressed the initial booting
problem?

 In windows, it is shown as an Alps Glidepoint on irq12, however fbsd
 refuses to find it.

 The device.hints file shows the correct info.  I ran acpidump, but was not
 quite sure what to look for.  (In one of the posts involving a sony with
 similair problems, someone said to check for MOUE which I suspect they
 meant MOUSE to get the ID to modify psm.c, but neither exist in acpidump
 results)

 Any ideas?

I have not yet tried FreeBSD 5.0 on my laptop, but src/isa/psm.c is
pretty similar between 4.7 and -CURRENT and my patch appears to apply
cleanly:

% patch psm.c  ~/psm.c.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--
|diff -r -u ../src_dist/sys/isa/psm.c ./sys/isa/psm.c
|--- ../src_dist/sys/isa/psm.c  Wed Mar 27 11:53:35 2002
|+++ ./sys/isa/psm.cWed Oct 16 16:15:17 2002
--
Patching file psm.c using Plan A...
Hunk #1 succeeded at 632 (offset -18 lines).
Hunk #2 succeeded at 1034 (offset 34 lines).
done
%

My patch is just a hack to make my Toshiba work correctly.  I tend to
think that test_aux_port() or its callers may need some work.  I'm
don't really like adding a third hack to the already existing two
hacks which ignore other return codes.  Someone more familiar with the
mouse and keyboard driver code may want to look at moving the default
processing for test_aux_port results to be the same as the current
PSM_ACK case.

Stuart
-- 
I've never been lost; I was once bewildered for three days, but never lost!
--  Daniel Boone
diff -r -u ../src_dist/sys/isa/psm.c ./sys/isa/psm.c
--- ../src_dist/sys/isa/psm.c   Wed Mar 27 11:53:35 2002
+++ ./sys/isa/psm.c Wed Oct 16 16:15:17 2002
@@ -650,6 +650,7 @@
 
 switch((i = test_aux_port(kbdc))) {
 case 1:/* ignore this error */
+case 2:/* ignore this error */
 case PSM_ACK:
if (verbose)
log(LOG_DEBUG, psm%d: strange result for test aux port (%d).\n,
@@ -999,9 +1000,11 @@
  * error code. Even if the controller HAS error with the aux port,
  * it will be detected later...
  * XXX: another incompatible controller returns PSM_ACK (0xfa)...
+ * XXX: Toshiba Satellite 1005-S157 returns 2...
  */
 switch ((i = test_aux_port(sc-kbdc))) {
 case 1:   /* ignore this error */
+case 2:   /* ignore this error */
 case PSM_ACK:
 if (verbose)
printf(psm%d: strange result for test aux port (%d).\n,



Re: stropts.h removed?

2003-01-31 Thread Kris Kennaway
On Fri, Jan 31, 2003 at 09:21:51AM -0500, Mike Barcroft wrote:
 Kris Kennaway [EMAIL PROTECTED] writes:
  A number of ports have started to complain about a missing stropts.h
  header..was this recently removed, and if so then what is the fix?
 
 I don't think we've ever supported STREAMS.

Hmm..there must be something in the configure script that thinks we do.

e.g.

http://bento.freebsd.org/errorlogs/alpha-5-latest/nvi-1.81.5_2.log

Can you investigate?

Kris



msg51355/pgp0.pgp
Description: PGP signature


Re: last KSE changes

2003-01-31 Thread Julian Elischer
Your sources are way out of date..
specifically I think it looks like sys/proc.h is
not being updated..


On Fri, 31 Jan 2003, Philip Paeps wrote:

 On 2003-01-28 11:24:41 (-0800), Julian Elischer [EMAIL PROTECTED] wrote:
  The rumour mill has been running wild on this but **AS FAR AS I KNOW** the
  breakages have been fixed, since no-one has told me directl of any current
  breakages. If you have any breakage from this commit, PLEASE TELL ME!
 
 Is this the sort of breakage you were expecting:
 
 On an Alpha:
 
  | linking kernel
  | init_main.o: In function `proc0_init':
  | init_main.o(.text+0x428): undefined reference to `kse0_sched'
  | init_main.o(.text+0x434): undefined reference to `ksegrp0_sched'
  | init_main.o(.text+0x440): undefined reference to `proc0_sched'
  | init_main.o(.text+0x44c): undefined reference to `thread0_sched'
  | *** Error code 1
  | 
  | Stop in /usr/obj/usr/src/sys/PROSPERINA.
  | *** Error code 1
  | 
  | Stop in /usr/src.
  | *** Error code 1
  | 
  | Stop in /usr/src.
 
 On an i386:
 
  | linking kernel
  | init_main.o: In function `proc0_init':
  | init_main.o(.text+0x2b9): undefined reference to `kse0_sched'
  | init_main.o(.text+0x2c3): undefined reference to `ksegrp0_sched'

[...]



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



Hyperthreading and machdep.cpu_idle_hlt

2003-01-31 Thread Trish Lynch
So, at the request of bmilekic, I ran netpipe on a hyperthreading box (non
hyperthreading, I'll do when I can turn it off in BIOS next time I'm down
there)



however, I got a hint to turn machdep.cpu_idle_hlt on.


Dmesg: (With Hyperthreading)

CPU: Pentium 4 (1796.94-MHz 686-class CPU)
  Origin = GenuineIntel  Id = 0xf27  Stepping = 7

Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,P
GE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,b31
real memory  = 1073217536 (1023 MB)
avail memory = 1034719232 (986 MB)

Programming 24 pins in IOAPIC #0
IOAPIC #0 intpin 2 - irq 0
Programming 24 pins in IOAPIC #1
Programming 24 pins in IOAPIC #2
FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs
 cpu0 (BSP): apic id:  0, version: 0x00050014, at 0xfee0
 cpu1 (AP):  apic id:  6, version: 0x00050014, at 0xfee0
 cpu2 (AP):  apic id:  1, version: 0x00050014, at 0xfee0
 cpu3 (AP):  apic id:  7, version: 0x00050014, at 0xfee0
 io0 (APIC): apic id:  2, version: 0x00178020, at 0xfec0
 io1 (APIC): apic id:  3, version: 0x00178020, at 0xfec8
 io2 (APIC): apic id:  4, version: 0x00178020, at 0xfec80400


I tested with machdep.cpu_idle_hlt=0 and machdep.cpu_idle_hlt=1

The results are here:


http://bsdunix.net/performance

all information on what command line options I used is in there.

the difference with it on is pretty substantial, might be worth noting in
tuning(7)

-Trish

--
Trish Lynch[EMAIL PROTECTED]
Ecartis Core Team [EMAIL PROTECTED]
EFNet IRC Operator @ efnet.demon.co.ukAilleCat@EFNet
Key fingerprint = 781D 2B47 AA4B FC88 B919  0CD6 26B2 1D62 6FC1 FF16


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



Re: Seat-belt for source upgrades from stable to current

2003-01-31 Thread David Schultz
Thus spake Ruslan Ermilov [EMAIL PROTECTED]:
 On Thu, Jan 30, 2003 at 09:58:15PM -0800, David Schultz wrote:
  I don't know about Steve, but cvsup is the wrong answer for me
  because it's a mirroring tool and not a version control tool.
  Among the things I would like to do are:
  
  - Update to a specific version of a specific file from the
repository.
  
  - Generate a diff between two revisions in the repository,
or between a version in the repository and some local
patches of my own.
  
  - View logs for particular files.
  
  I asked the question in hopes that there would be some neat
  feature of cvsup that mocked up some CVS metadata for me, but
  since nobody has mentioned any such thing, I guess I'm out of
  luck.  Mirroring the entire repository is not an option on
  machines with less than 6 GB of spare disk.[1]  Transferring the
  entire source tree over the network via anoncvs is suboptimal when
  all I really want is a few kilobytes of 'CVS' subdirectories.
  But I guess it will have to do for now.
  
  
  [1] When the system is an aging dual PPro or 200MHz Alpha using
  SCSI, buying new drives is not practical.
  
 Well then learn how to use anoncvs?

I use anoncvs.  My question was, given a source or ports tree
without any CVS metadata, is there a way to obtain the tiny
corresponding CVS/Entries and CVS/Repository files without
checking out an entirely new copy of the tree via a busy, often
overloaded, anoncvs server.

Keep in mind that I'm not asking a ``can it be done?'' question.
I've been doing it for years.  Rather, I'm asking, ``can it be
done more efficiently?''  So far, the best answer I've received is
``mirror the repository locally'' (thank you, David), which I
already do on one machine to maintain a local branch and will
consider doing on others.

I have also considered writing a script to parse embedded
$FreeBSD$ tags out of source files and mock up a CVS/Entries and
CVS/Repository based on that information.  Perhaps I will try that
and see if it works passably well.

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



Re: Hyperthreading and machdep.cpu_idle_hlt

2003-01-31 Thread Matthew Dillon
:So, at the request of bmilekic, I ran netpipe on a hyperthreading box (non
:hyperthreading, I'll do when I can turn it off in BIOS next time I'm down
:there)
:...
:
:The results are here:
:
:http://bsdunix.net/performance
:
:all information on what command line options I used is in there.
:
:the difference with it on is pretty substantial, might be worth noting in
:tuning(7)
:
:-Trish
:
:--
:Trish Lynch   [EMAIL PROTECTED]

Those results are indeed quite substantial.  Before you modify 
tuning(7), though, lets wait a bit to see if anyone comes up with a
fix to the performance issue when idle_hlt is turned off.  In particular
I would like to try using a per-cpu global test in the idle loop that
avoids doing any locked bus cycles.

Unfortunately I am not sure if I have any hyperthreading capable boxes.
My primary machine is a pentium 4 but it is running -stable.

Timecounter i8254  frequency 1193182 Hz
Timecounter TSC  frequency 1296069572 Hz
CPU: Pentium 4 (1296.07-MHz 686-class CPU)
  Origin = GenuineIntel  Id = 0xf07  Stepping = 7
  Features=0x3febf9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,P
AT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,b28,ACC

It has HTT set but it's only a 1.2GHz box and I heard somewhere that only
2+ GHz P4's had hyperthreading.  I noticed some MFCs to stable that 
suggested hyperthreading support but I do not know if full hyperthreading
support has been MFCd yet or is intended to be MFCd to -stable.

-Matt
Matthew Dillon 
[EMAIL PROTECTED]

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



Re: Hyperthreading and machdep.cpu_idle_hlt

2003-01-31 Thread Daniel C. Sobral
Matthew Dillon wrote:

:So, at the request of bmilekic, I ran netpipe on a hyperthreading box (non
:hyperthreading, I'll do when I can turn it off in BIOS next time I'm down
:there)
:...
:
:The results are here:
:
:http://bsdunix.net/performance
:
:all information on what command line options I used is in there.
:
:the difference with it on is pretty substantial, might be worth noting in
:tuning(7)
:
:-Trish
:
:--
:Trish Lynch	   [EMAIL PROTECTED]

Those results are indeed quite substantial.  Before you modify 
tuning(7), though, lets wait a bit to see if anyone comes up with a
fix to the performance issue when idle_hlt is turned off.  In particular
I would like to try using a per-cpu global test in the idle loop that
avoids doing any locked bus cycles.

Unfortunately I am not sure if I have any hyperthreading capable boxes.
My primary machine is a pentium 4 but it is running -stable.

Timecounter i8254  frequency 1193182 Hz
Timecounter TSC  frequency 1296069572 Hz
CPU: Pentium 4 (1296.07-MHz 686-class CPU)
  Origin = GenuineIntel  Id = 0xf07  Stepping = 7
  Features=0x3febf9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,P
AT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,b28,ACC

It has HTT set but it's only a 1.2GHz box and I heard somewhere that only
2+ GHz P4's had hyperthreading.  I noticed some MFCs to stable that 
suggested hyperthreading support but I do not know if full hyperthreading
support has been MFCd yet or is intended to be MFCd to -stable.

AFAIK, full hyperthreading support, as it is, has been merged to 
-stable. It consists of a patch to recognize the virtual CPUs, so they 
will be dealt with like any SMP system, as long as HTT is enabled on the 
BIOS.

--
Daniel C. Sobral   (8-DCS)
Gerencia de Operacoes
Divisao de Comunicacao de Dados
Coordenacao de Seguranca
TCO
Fones: 55-61-313-7654/Cel: 55-61-9618-0904
E-mail: [EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]

Outros:
	[EMAIL PROTECTED]
	[EMAIL PROTECTED]
	[EMAIL PROTECTED]

In 1914, the first crossword puzzle was printed in a newspaper.  The
creator received $4000 down ... and $3000 across.


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


Re: Hyperthreading and machdep.cpu_idle_hlt

2003-01-31 Thread Bosko Milekic

Trish,

Thanks for the tests, it would be good to also get results with
hyperthreading turned off.  However, I need you to pass the -o
option to NPtcp and get an actual dat file, so that you can generate
the graphs using the gnuplot config file I asked you to download.
Having the results outputted in the text file is not very
meaningful.

From just eyeballing though, I can see that the maximum throughput
is much higher in the second set of results.  I'd still like the dat
files and/or the gnuplot generated pngs, especially when
hyperthreading is turned off, too.

Thanks again, Trish.

Regards,
Bosko

On Fri, Jan 31, 2003 at 01:04:52PM -0500, Trish Lynch wrote:
 So, at the request of bmilekic, I ran netpipe on a hyperthreading box (non
 hyperthreading, I'll do when I can turn it off in BIOS next time I'm down
 there)
 
 
 
 however, I got a hint to turn machdep.cpu_idle_hlt on.
 
 
 Dmesg: (With Hyperthreading)
 
 CPU: Pentium 4 (1796.94-MHz 686-class CPU)
   Origin = GenuineIntel  Id = 0xf27  Stepping = 7
 
 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,P
 GE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,b31
 real memory  = 1073217536 (1023 MB)
 avail memory = 1034719232 (986 MB)
 
 Programming 24 pins in IOAPIC #0
 IOAPIC #0 intpin 2 - irq 0
 Programming 24 pins in IOAPIC #1
 Programming 24 pins in IOAPIC #2
 FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs
  cpu0 (BSP): apic id:  0, version: 0x00050014, at 0xfee0
  cpu1 (AP):  apic id:  6, version: 0x00050014, at 0xfee0
  cpu2 (AP):  apic id:  1, version: 0x00050014, at 0xfee0
  cpu3 (AP):  apic id:  7, version: 0x00050014, at 0xfee0
  io0 (APIC): apic id:  2, version: 0x00178020, at 0xfec0
  io1 (APIC): apic id:  3, version: 0x00178020, at 0xfec8
  io2 (APIC): apic id:  4, version: 0x00178020, at 0xfec80400
 
 
 I tested with machdep.cpu_idle_hlt=0 and machdep.cpu_idle_hlt=1
 
 The results are here:
 
 
 http://bsdunix.net/performance
 
 all information on what command line options I used is in there.
 
 the difference with it on is pretty substantial, might be worth noting in
 tuning(7)
 
 -Trish
 
 --
 Trish Lynch  [EMAIL PROTECTED]
 Ecartis Core Team   [EMAIL PROTECTED]
 EFNet IRC Operator @ efnet.demon.co.uk  AilleCat@EFNet
 Key fingerprint = 781D 2B47 AA4B FC88 B919  0CD6 26B2 1D62 6FC1 FF16
 
 
 To Unsubscribe: send mail to [EMAIL PROTECTED]
 with unsubscribe freebsd-current in the body of the message
 

-- 
Bosko Milekic * [EMAIL PROTECTED] * [EMAIL PROTECTED]


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



Re: Hyperthreading and machdep.cpu_idle_hlt

2003-01-31 Thread Trish Lynch
On Fri, 31 Jan 2003, Bosko Milekic wrote:


 Trish,

 Thanks for the tests, it would be good to also get results with
 hyperthreading turned off.  However, I need you to pass the -o
 option to NPtcp and get an actual dat file, so that you can generate
 the graphs using the gnuplot config file I asked you to download.
 Having the results outputted in the text file is not very
 meaningful.

 From just eyeballing though, I can see that the maximum throughput
 is much higher in the second set of results.  I'd still like the dat
 files and/or the gnuplot generated pngs, especially when
 hyperthreading is turned off, too.

 Thanks again, Trish.

 Regards,
 Bosko



I have the .dat's for you, unfortunately, the output is different, so
you'll have to modify the .cfg for gnuplot :)

-Trish



--
Trish Lynch[EMAIL PROTECTED]
Ecartis Core Team [EMAIL PROTECTED]
EFNet IRC Operator @ efnet.demon.co.ukAilleCat@EFNet
Key fingerprint = 781D 2B47 AA4B FC88 B919  0CD6 26B2 1D62 6FC1 FF16


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



Re: Hyperthreading and machdep.cpu_idle_hlt

2003-01-31 Thread leafy
On Fri, Jan 31, 2003 at 01:45:56PM -0500, Trish Lynch wrote:
 I have the .dat's for you, unfortunately, the output is different, so
 you'll have to modify the .cfg for gnuplot :)
 
 -Trish
I have HTT for my CPU, is there any hack to the BIOS to enable HyperThreading?

Jiawei Ye

-- 
Without the userland, the kernel is useless.
 --inspired by The Tao of Programming

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



Re: Hyperthreading and machdep.cpu_idle_hlt

2003-01-31 Thread Kenneth Culver
 I have HTT for my CPU, is there any hack to the BIOS to enable
 HyperThreading?

You might try updating your BIOS.

Ken


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



Re: Hyperthreading and machdep.cpu_idle_hlt

2003-01-31 Thread Matthew Dillon

:AFAIK, full hyperthreading support, as it is, has been merged to 
:-stable. It consists of a patch to recognize the virtual CPUs, so they 
:will be dealt with like any SMP system, as long as HTT is enabled on the 
:BIOS.
:
:-- 
:Daniel C. Sobral   (8-DCS)
:Gerencia de Operacoes

Yah.  Shoot, well this Sony VAIO desktop has a P4 with HTT set in
it, but it doesn't have an APIC, the BIOS is clueless, and there
is no mptable, so I guess I am S.O.L. in regards to using hyperthreading
on this box.

-Matt
Matthew Dillon 
[EMAIL PROTECTED]


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



Re: Hyperthreading and machdep.cpu_idle_hlt

2003-01-31 Thread Bosko Milekic


On Fri, Jan 31, 2003 at 11:08:38AM -0800, Matthew Dillon wrote:
 
 :AFAIK, full hyperthreading support, as it is, has been merged to 
 :-stable. It consists of a patch to recognize the virtual CPUs, so they 
 :will be dealt with like any SMP system, as long as HTT is enabled on the 
 :BIOS.
 :
 :-- 
 :Daniel C. Sobral   (8-DCS)
 :Gerencia de Operacoes
 
 Yah.  Shoot, well this Sony VAIO desktop has a P4 with HTT set in
 it, but it doesn't have an APIC, the BIOS is clueless, and there
 is no mptable, so I guess I am S.O.L. in regards to using hyperthreading
 on this box.
 
   -Matt
   Matthew Dillon 
   [EMAIL PROTECTED]

  Why do you think that hlt-ing the CPU(s) when idle would actually
  improve performance in this case?  My only suspicion is that perhaps
  this reduces scheduling on the auxiliary 'logical' (fake) CPUs,
  thereby indirectly reducing cache ping-ponging and abuse.  I would
  imagine that both units sharing the same execution engine in the
  HTT-enabled model would be effectively 'hlt'-ed when one of the two
  threads executes an 'hlt' until the next timer tick.

  I guess we'll wait for the two other data sets from Trish: one with
  HTT off, and cpu_idle_hlt=0, and the other with HTT off, and
  cpu_idle_hlt=1, before figuring this out.

-- 
Bosko Milekic * [EMAIL PROTECTED] * [EMAIL PROTECTED]


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



NFS over TCP doesn't umount

2003-01-31 Thread Tim Kientzle
Tinkering with NFS over TCP through a firewall,
I ran across the following:

  # mount_nfs -3TN server:/path /mnt

Generates the following traffic:
   UDP exchanges with server port 111 (rpcbind)
   TCP exchanges with server ports 1023 and 2049

That is, if your firewall allows UDP 111 through,
then NFS over TCP can mount and function through it.

But, umount is a different story:

  # umount /mnt
  Bad MNT RPC: RPC: Timed out

The following tcpdump trace shows that the umount
is using UDP transport, even though the filesystem was
mounted using TCP transport:

11:21:42.811506 client.1124  server.2049: F 129:129(0) ack 125 win 1
7396 (DF)
11:21:42.811912 client.962  server.111:  udp 56
11:21:42.812446 server.2049  client.1124: . ack 130 win 33176 (DF)
11:21:42.812596 server.2049  client.1124: F 125:125(0) ack 130 win 3
3176 (DF)
11:21:42.812614 client.1124  server.2049: . ack 126 win 17395 (DF)
11:21:42.813195 server.111  client.962:  udp 28
11:21:42.813336 client.961  server.1023:  udp 128
11:21:45.817521 client.961  server.1023:  udp 128
11:21:48.827565 client.961  server.1023:  udp 128
11:21:51.837612 client.961  server.1023:  udp 128
11:21:54.847657 client.961  server.1023:  udp 128
11:21:57.857700 client.961  server.1023:  udp 128
11:22:00.867747 client.961  server.1023:  udp 128

This is reproducible with both a 4.3-RELEASE client
and a recent -CURRENT client.  The server is running
4.3-RELEASE, if it's relevant.

Tim Kientzle


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



Re: Hyperthreading and machdep.cpu_idle_hlt

2003-01-31 Thread Peter Wemm
Bosko Milekic wrote:
 
 
 On Fri, Jan 31, 2003 at 11:08:38AM -0800, Matthew Dillon wrote:
  
  :AFAIK, full hyperthreading support, as it is, has been merged to 
  :-stable. It consists of a patch to recognize the virtual CPUs, so they 
  :will be dealt with like any SMP system, as long as HTT is enabled on the 
  :BIOS.
  :
  :-- 
  :Daniel C. Sobral   (8-DCS)
  :Gerencia de Operacoes
  
  Yah.  Shoot, well this Sony VAIO desktop has a P4 with HTT set in
  it, but it doesn't have an APIC, the BIOS is clueless, and there
  is no mptable, so I guess I am S.O.L. in regards to using hyperthreadin
g
  on this box.
  
  -Matt
  Matthew Dillon 
  [EMAIL PROTECTED]
 
   Why do you think that hlt-ing the CPU(s) when idle would actually
   improve performance in this case?  My only suspicion is that perhaps
   this reduces scheduling on the auxiliary 'logical' (fake) CPUs,
   thereby indirectly reducing cache ping-ponging and abuse.  I would
   imagine that both units sharing the same execution engine in the
   HTT-enabled model would be effectively 'hlt'-ed when one of the two
   threads executes an 'hlt' until the next timer tick.

The cache and most of the execution hardware is shared.  The execution
units can run something like 4 instructions per clock.  If the idle
logical core is in a spinloop, then it is generating instructions for
execution, so you are dividing the execution resources between one context
that is doing real work, and the other context that is burning off the
excess resources.  Overall, it is a huge loss.  It is absolutely essential
that logical cpus be halted when they are not doing useful work.

Why bother with HTT on a single physical cpu system?  The problem with the
x86 instruction set is that it is Really Hard(TM) to extract enough
parallel work from the instruction stream to keep all the pipelines running
at full speed all the time.   I remember when the P4 first came out, there
was a lot of ridicule since the decoder simply didn't have enough bandwidth
to generate enough micro-ops to keep the pipelines busy in already ideal
situations.  Intel grand plan is to add lots more pipelines, more logical
cpus etc.  The P4 division figures this will scale much more effectively
than trying to make the compilers better and dedicating much more
resources trying to squeeze more parallelism out of a single x86 instruction
stream.

Under ideal circumstances, HTT would be a win.  ie: there would be lots of
processes with 5-10 threads so that we could dispatch a process to a
physical cpu and try and arrange for its threads to run on the logical
cores (think 4 or 8 or even 16 logical contexts down the road).  That way
you get a single page table tree to cache in the TLB rather than trying to
split the TLB 2 (or 4 or 8 or ...) ways.  The threads would be better
likely to have locality of reference so make better use of the physical L2
cache etc.  This happens to work well in theory on the highly threaded
windows world... Note in theory.  Windows needs HTT-aware tuning and
algorithms to make this work better, right now it seems to be not that smart
about scheduling etc.  Although, that is a lot better than the situation
that we're in right now. :-(

Personally, I doubt that HTT will buy much on FreeBSD, apart from being
buzzword compliant.  I'd actually like a compile option or boot tunable so
that it to be turned on or off (and treated like a regular Xeon SMP
system).  Single-physical-cpu systems already have this compile option, it
is called 'options SMP' :-).  But if you have 2x P4 Xeons, it would be nice to
be able to use them as a normal 2 way system rather than 4 logical ways.

Cheers,
-Peter
--
Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
All of this is for nothing if we don't go to the stars - JMS/B5


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



Re: Hyperthreading and machdep.cpu_idle_hlt

2003-01-31 Thread Matthew Dillon

:  Why do you think that hlt-ing the CPU(s) when idle would actually
:  improve performance in this case?  My only suspicion is that perhaps
:  this reduces scheduling on the auxiliary 'logical' (fake) CPUs,
:  thereby indirectly reducing cache ping-ponging and abuse.  I would
:  imagine that both units sharing the same execution engine in the
:  HTT-enabled model would be effectively 'hlt'-ed when one of the two
:  threads executes an 'hlt' until the next timer tick.
:
:  I guess we'll wait for the two other data sets from Trish: one with
:  HTT off, and cpu_idle_hlt=0, and the other with HTT off, and
:  cpu_idle_hlt=1, before figuring this out.
:
:-- 
:Bosko Milekic * [EMAIL PROTECTED] * [EMAIL PROTECTED]

 I am almost certain that it is related to pipeline stalls created
 by the fairly long (in instructions) idle loop and the locked bus
 cycles used by the mutex code.  It could also possibly be related to
 L1 cache contention.

 I think that if we can fit the idle loop for the 'logical' processor
 into a single instruction cache line and a single data cache line,
 accessing a single memory location without any locked bus cycles, that
 it would solve the problem.  Unfortunately I have no boxes I can do
 testing on so this is just a guess.

 Another solution would be to have a global mask of 'idle' cpus and send
 an IPI to them when a new KSE is scheduled on a non-idle cpu that would
 simply serve to wakeup the HLT.  IPIs are nasty, but there are large 
 (power consumption) advantages to standardizing on the HLT methodology.

-Matt
Matthew Dillon 
[EMAIL PROTECTED]

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



Re: Hyperthreading and machdep.cpu_idle_hlt

2003-01-31 Thread Matthew Dillon
:The cache and most of the execution hardware is shared.  The execution
:units can run something like 4 instructions per clock.  If the idle
:logical core is in a spinloop, then it is generating instructions for
:execution, so you are dividing the execution resources between one context
:that is doing real work, and the other context that is burning off the
:excess resources.  Overall, it is a huge loss.  It is absolutely essential
:that logical cpus be halted when they are not doing useful work.

Ah, that makes sense.  Are the two logical cpus shared 50-50?

-Matt

:Cheers,
:-Peter
:--
:Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]

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



Re: Hyperthreading and machdep.cpu_idle_hlt

2003-01-31 Thread Trish Lynch
On Fri, 31 Jan 2003, Peter Wemm wrote:


 Personally, I doubt that HTT will buy much on FreeBSD, apart from being
 buzzword compliant.  I'd actually like a compile option or boot tunable so
 that it to be turned on or off (and treated like a regular Xeon SMP
 system).  Single-physical-cpu systems already have this compile option, it
 is called 'options SMP' :-).  But if you have 2x P4 Xeons, it would be nice to
 be able to use them as a normal 2 way system rather than 4 logical ways.


boot tunable would rock, then I wouldn;t have to had had BIOS access to a
machine thats 2 hours away by car to turn HTT off (it just happened that
it was enabled by default when they installed the machine)
(which of course made it nice to try this on, but getting the second set
of data with HTT turned off is going to be a pain)

What I need is someone with an HTT capable SMP box that can turn it on and
off to run these benchmarks with HTT on and off... then we'd have a good
idea of the performance hit.

-Trish

--
Trish Lynch[EMAIL PROTECTED]
Ecartis Core Team [EMAIL PROTECTED]
EFNet IRC Operator @ efnet.demon.co.ukAilleCat@EFNet
Key fingerprint = 781D 2B47 AA4B FC88 B919  0CD6 26B2 1D62 6FC1 FF16


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



Re: Hyperthreading and machdep.cpu_idle_hlt

2003-01-31 Thread John Baldwin

On 31-Jan-2003 Daniel C. Sobral wrote:
 Matthew Dillon wrote:
 :So, at the request of bmilekic, I ran netpipe on a hyperthreading box (non
 :hyperthreading, I'll do when I can turn it off in BIOS next time I'm down
 :there)
 :...
 :
 :The results are here:
 :
 :http://bsdunix.net/performance
 :
 :all information on what command line options I used is in there.
 :
 :the difference with it on is pretty substantial, might be worth noting in
 :tuning(7)
 :
 :-Trish
 :
 :--
 :Trish Lynch[EMAIL PROTECTED]
 
 Those results are indeed quite substantial.  Before you modify 
 tuning(7), though, lets wait a bit to see if anyone comes up with a
 fix to the performance issue when idle_hlt is turned off.  In particular
 I would like to try using a per-cpu global test in the idle loop that
 avoids doing any locked bus cycles.
 
 Unfortunately I am not sure if I have any hyperthreading capable boxes.
 My primary machine is a pentium 4 but it is running -stable.
 
 Timecounter i8254  frequency 1193182 Hz
 Timecounter TSC  frequency 1296069572 Hz
 CPU: Pentium 4 (1296.07-MHz 686-class CPU)
   Origin = GenuineIntel  Id = 0xf07  Stepping = 7
   Features=0x3febf9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,P
 AT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,b28,ACC
 
 It has HTT set but it's only a 1.2GHz box and I heard somewhere that only
 2+ GHz P4's had hyperthreading.  I noticed some MFCs to stable that 
 suggested hyperthreading support but I do not know if full hyperthreading
 support has been MFCd yet or is intended to be MFCd to -stable.
 
 AFAIK, full hyperthreading support, as it is, has been merged to 
 -stable. It consists of a patch to recognize the virtual CPUs, so they 
 will be dealt with like any SMP system, as long as HTT is enabled on the 
 BIOS.

Well, sort of.  We have no way of knowing if it is off in the BIOS unless
we use the ACPI tables to enumerate CPU's (which we don't), so turning it
off in the BIOS won't turn it off in FreeBSD for the time being. :)

-- 

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

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



Re: Hyperthreading and machdep.cpu_idle_hlt

2003-01-31 Thread John Baldwin

On 31-Jan-2003 leafy wrote:
 On Fri, Jan 31, 2003 at 01:45:56PM -0500, Trish Lynch wrote:
 I have the .dat's for you, unfortunately, the output is different, so
 you'll have to modify the .cfg for gnuplot :)
 
 -Trish
 I have HTT for my CPU, is there any hack to the BIOS to enable HyperThreading?

Having HTT does _not_ mean you actually have multiple cores in your physical CPU.
You will see a separate line in your dmesg giving the number of cores per CPU
if you do.  The BIOS really has nothing to do with this, it all comes from
registers returned from the CPUID instruction.

-- 

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

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



Re: Hyperthreading and machdep.cpu_idle_hlt

2003-01-31 Thread John Baldwin

On 31-Jan-2003 Matthew Dillon wrote:
 
:AFAIK, full hyperthreading support, as it is, has been merged to 
:-stable. It consists of a patch to recognize the virtual CPUs, so they 
:will be dealt with like any SMP system, as long as HTT is enabled on the 
:BIOS.
:
:-- 
:Daniel C. Sobral   (8-DCS)
:Gerencia de Operacoes
 
 Yah.  Shoot, well this Sony VAIO desktop has a P4 with HTT set in
 it, but it doesn't have an APIC, the BIOS is clueless, and there
 is no mptable, so I guess I am S.O.L. in regards to using hyperthreading
 on this box.

HTT set just means that you can check the value returned in %ebx from
cpuid 1 to get the number of cores that your CPU contains.  It most likely
contains the value '1'.  Only Xeons and very recent desktop P4's have
multiple cores.

-- 

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

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



RE: Hyperthreading and machdep.cpu_idle_hlt

2003-01-31 Thread Don Bowman
 From: Matthew Dillon [mailto:[EMAIL PROTECTED]]
 
 :The cache and most of the execution hardware is shared.  The 
 execution
 :units can run something like 4 instructions per clock.  If the idle
 :logical core is in a spinloop, then it is generating instructions for
 :execution, so you are dividing the execution resources 
 between one context
 :that is doing real work, and the other context that is 
 burning off the
 :excess resources.  Overall, it is a huge loss.  It is 
 absolutely essential
 :that logical cpus be halted when they are not doing useful work.
 
 Ah, that makes sense.  Are the two logical cpus shared 50-50?

Hyperthreading is also called symmetric multi-threading (hyperthread
is a trademark of intel, SMT is the general term).
The two logical cpu's are like a co-operative scheduler. Whenever there
is a stall on one, the other wakes up on the same tick.
THe most common cause for the stall is an access to memory. Ie when
the first 'cpu' does a load-word, the memory controller tries to
get that from L1-L2-L3-memory, with increasing latency. The
other 'CPU' starts executing on the same cycle as the latency 
to the memory starts, and only stops when it too stalls.

Thus the worst thing you could have would be a nop-loop with
no stalls, which would squeeze the other to death.

This is common in the network-processor world (e.g. AMCC, etc)
since those applications are governed by memory latency.

As the clock rate of memory has gone up, the overall latency to
the first word has stayed relatively constant, so even though
DDR 266 memory may have a much faster throughput, it takes
just as long for that first access.

Intel also has a speculative prefetch which tries to guess 
which memory will be needed next, and bring that in. There is
an explicit prefetch in the SSE2/MMX set if you know better
than the processor. This is good for for e.g. prefetch both
halves of a tree before you do the compare.

In practise I've found intel's numbers to be true, that the
SMT gives you a ~20% boost, implying that there is nowhere
close to a 50-50% split in normal use.

--don

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



CD/RW Hangs with 5.0-RELEASE

2003-01-31 Thread Scott R.
Hello,

This is the first time since adopting 5.0 that I've tried to do anything with my cd 
drive and I'm finding it impossible to work with.  First, I installed ripit so that I 
could convert a couple CD's to mp3's.  This fails with:

dagrab: read raw ioctl failed at lba 0 length 12: Input/output error
dagrab failed on Kittie - Pain at /usr/local/bin/ripit.pl line 369.

Then, out of curiosity, I decided to see if I could even mount a regular data CD.  I 
could.  I could even unmount it.  However, the CD drive would not spit out the disc 
until I rebooted the system.  Some sort of lock on removing the CD from the drive 
stayed in place even after unmounting the drive.  I know this drive works just fine as 
I just used it under Windows on the same box a couple days ago.  I'm not sure what 
other info would be relevant, nor do I really know how to further diagnose this issue 
but I would be happy to supply any further information.  I was unable to turn up 
anything by searching on Google or in the archives.

Vitals:
5.0-RELEASE FreeBSD 5.0-RELEASE #0: Tue Jan 21 20:44:33 PST 2003

borges[117]% dmesg | grep acd0
acd0: CD-RW CD-R/RW RW7083A at ata1-master PIO4
acd0: READ_CD command timeout - resetting
acd0: READ_CD command timeout - resetting
acd0: READ_CD command timeout - resetting
acd0: READ_CD command timeout - resetting

Thanks in advance,
Scott


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



Re: Hyperthreading and machdep.cpu_idle_hlt

2003-01-31 Thread Julian Elischer


On Fri, 31 Jan 2003, John Baldwin wrote:

  AT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,b28,ACC
  
  It has HTT set but it's only a 1.2GHz box and I heard somewhere that only
  2+ GHz P4's had hyperthreading.  I noticed some MFCs to stable that 
  suggested hyperthreading support but I do not know if full hyperthreading
  support has been MFCd yet or is intended to be MFCd to -stable.
  
  AFAIK, full hyperthreading support, as it is, has been merged to 
  -stable. It consists of a patch to recognize the virtual CPUs, so they 
  will be dealt with like any SMP system, as long as HTT is enabled on the 
  BIOS.
 
 Well, sort of.  We have no way of knowing if it is off in the BIOS unless
 we use the ACPI tables to enumerate CPU's (which we don't), so turning it
 off in the BIOS won't turn it off in FreeBSD for the time being. :)
 
I have a 2,8GHz p4 here which has HTT and has a bios option for 

Interrupt mode: [APIC/PIC]

I'm using APIC mode but an SMP (today's 4.x) kernel
panics imediatly saying it can;t find an APIC.






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



Re: Hyperthreading and machdep.cpu_idle_hlt

2003-01-31 Thread Julian Elischer


On Fri, 31 Jan 2003, John Baldwin wrote:

 
 On 31-Jan-2003 leafy wrote:
  On Fri, Jan 31, 2003 at 01:45:56PM -0500, Trish Lynch wrote:
  I have the .dat's for you, unfortunately, the output is different, so
  you'll have to modify the .cfg for gnuplot :)
  
  -Trish
  I have HTT for my CPU, is there any hack to the BIOS to enable HyperThreading?
 
 Having HTT does _not_ mean you actually have multiple cores in your physical CPU.
 You will see a separate line in your dmesg giving the number of cores per CPU
 if you do.  The BIOS really has nothing to do with this, it all comes from
 registers returned from the CPUID instruction.



do you need an SMP kernel to see this?

 
 -- 
 
 John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/
 Power Users Use the Power to Serve!  -  http://www.FreeBSD.org/
 
 To Unsubscribe: send mail to [EMAIL PROTECTED]
 with unsubscribe freebsd-current in the body of the message
 


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



Re: Hyperthreading and machdep.cpu_idle_hlt

2003-01-31 Thread John Baldwin

On 31-Jan-2003 Julian Elischer wrote:
 
 
 On Fri, 31 Jan 2003, John Baldwin wrote:
 
  AT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,b28,ACC
  
  It has HTT set but it's only a 1.2GHz box and I heard somewhere that only
  2+ GHz P4's had hyperthreading.  I noticed some MFCs to stable that 
  suggested hyperthreading support but I do not know if full hyperthreading
  support has been MFCd yet or is intended to be MFCd to -stable.
  
  AFAIK, full hyperthreading support, as it is, has been merged to 
  -stable. It consists of a patch to recognize the virtual CPUs, so they 
  will be dealt with like any SMP system, as long as HTT is enabled on the 
  BIOS.
 
 Well, sort of.  We have no way of knowing if it is off in the BIOS unless
 we use the ACPI tables to enumerate CPU's (which we don't), so turning it
 off in the BIOS won't turn it off in FreeBSD for the time being. :)
 
 I have a 2,8GHz p4 here which has HTT and has a bios option for 
 
 Interrupt mode: [APIC/PIC]
 
 I'm using APIC mode but an SMP (today's 4.x) kernel
 panics imediatly saying it can;t find an APIC.

You need to have an mptable for it to work.  The mptable will
only list one processor, but it still needs to be there.

-- 

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

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



Re: Hyperthreading and machdep.cpu_idle_hlt

2003-01-31 Thread John Baldwin

On 31-Jan-2003 Julian Elischer wrote:
 
 
 On Fri, 31 Jan 2003, John Baldwin wrote:
 
 
 On 31-Jan-2003 leafy wrote:
  On Fri, Jan 31, 2003 at 01:45:56PM -0500, Trish Lynch wrote:
  I have the .dat's for you, unfortunately, the output is different, so
  you'll have to modify the .cfg for gnuplot :)
  
  -Trish
  I have HTT for my CPU, is there any hack to the BIOS to enable HyperThreading?
 
 Having HTT does _not_ mean you actually have multiple cores in your physical CPU.
 You will see a separate line in your dmesg giving the number of cores per CPU
 if you do.  The BIOS really has nothing to do with this, it all comes from
 registers returned from the CPUID instruction.
 
 
 
 do you need an SMP kernel to see this?

No.

-- 

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

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



Re: NFS over TCP doesn't umount

2003-01-31 Thread Martin Blapp

Hi,

   # umount /mnt
   Bad MNT RPC: RPC: Timed out

This behaviour is the same since we support NFS over
TCP. The problem is, that the state of the nfs_mount
isn't stored.

That means that umount cannot look at the mountflags
and decide what protocol it likes to use.

Of course we can change this, but have to kill one existing
mountflag because they are all used currently. I propose to remove
MNT_EXKERB, since all the kerberos nfs stuff has been
removed. Have a look at mount.h yourself.

If this is generally ok'd, I'll make a patch and commit
it.

Martin

Martin Blapp, [EMAIL PROTECTED] [EMAIL PROTECTED]
--
ImproWare AG, UNIXSP  ISP, Zurlindenstrasse 29, 4133 Pratteln, CH
Phone: +41 61 826 93 00 Fax: +41 61 826 93 01
PGP: finger -l [EMAIL PROTECTED]
PGP Fingerprint: B434 53FC C87C FE7B 0A18 B84C 8686 EF22 D300 551E
--

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



Re: Hyperthreading and machdep.cpu_idle_hlt

2003-01-31 Thread Julian Elischer


On Fri, 31 Jan 2003, John Baldwin wrote:

 
 On 31-Jan-2003 Julian Elischer wrote:
  
  
  On Fri, 31 Jan 2003, John Baldwin wrote:
  
   AT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,b28,ACC
   
   It has HTT set but it's only a 1.2GHz box and I heard somewhere that only
   2+ GHz P4's had hyperthreading.  I noticed some MFCs to stable that 
   suggested hyperthreading support but I do not know if full hyperthreading
   support has been MFCd yet or is intended to be MFCd to -stable.
   
   AFAIK, full hyperthreading support, as it is, has been merged to 
   -stable. It consists of a patch to recognize the virtual CPUs, so they 
   will be dealt with like any SMP system, as long as HTT is enabled on the 
   BIOS.
  
  Well, sort of.  We have no way of knowing if it is off in the BIOS unless
  we use the ACPI tables to enumerate CPU's (which we don't), so turning it
  off in the BIOS won't turn it off in FreeBSD for the time being. :)
  
  I have a 2,8GHz p4 here which has HTT and has a bios option for 
  
  Interrupt mode: [APIC/PIC]
  
  I'm using APIC mode but an SMP (today's 4.x) kernel
  panics imediatly saying it can;t find an APIC.
 
 You need to have an mptable for it to work.  The mptable will
 only list one processor, but it still needs to be there.

if that comes from the BIOS, can it be simulated for 
uniprocessor machines with HTT?


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



Re: stropts.h removed?

2003-01-31 Thread Garrett Wollman
On Fri, 31 Jan 2003 09:33:55 -0800, Kris Kennaway [EMAIL PROTECTED] said:

 Hmm..there must be something in the configure script that thinks we do.

 http://bento.freebsd.org/errorlogs/alpha-5-latest/nvi-1.81.5_2.log

It erroneously thinks that because we have the grantpt() function, we
have SEWERS and SVID3 ptys.  It needs to learn how to use the
posix_openpt() function, or else revert back to the !HAVE_SYS5_PTY
code (which is also broken: it doesn't search the full range of
possible pty names).

-GAWollman


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



Turn $25 into $45,000 MONTHLY, all automatic! 2588CMRd2-598mGjG7972Raq-23

2003-01-31 Thread newhsave
This is IT!

Don't miss out in this amazing opportunity. Join
now for $25 and earn up to $45,000 MONTHLY

Yes, I said monthly AND IT IS ALL AUTOMATED.
Get FREE information. Just click the link below.

www.mlmontarget.com

This is FREE information that will amaze you on
how much MONEY YOU CAN EARN FOR ONLY
$25 per month. Many join multiple times and it is
ALL AUTOMATED. We do all the hard work. Click
below now for FREE information.

www.mlmontarget.com

Start getting your MONEY today!!!


8454CbFV6-461bgof1523wBxl0-180ztPb3459XesT5-575PZdt8733Anqp8-647GKkY1078Nswl71

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



Re: Cisco vpnclient

2003-01-31 Thread Julian Elischer
what is the protocol they are using?


On Fri, 31 Jan 2003, Christoph Kukulies wrote:

 
 Cisco is offering a VPN client for Linux. I wonder if it would be possible
 to run this under FreeBSD. An extra linux kernel module is being built.
 Is this already the 'ruled out'?
 
 If this won't work, I'm afraid I will have to set a dedicated redhat 6.x/7.x
 beside my FreeBSD gateway. Would it be possible to use NAT to
 extend the VPN (I only have one dedicated fixed IP on the gateway).
 
 Excuse if this is not exactly on target of -current.
 
 --
 Chris Christoph P. U. Kukulies [EMAIL PROTECTED]
 
 To Unsubscribe: send mail to [EMAIL PROTECTED]
 with unsubscribe freebsd-current in the body of the message
 


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



Re: dump -L and privilege

2003-01-31 Thread Eugene M. Kim
Moreover, the fact that the number of snapshots allowed on a filesystem
is limited to a handful (src/sys/ufs/ffs/README.snapshot says 20) makes
it possible for normal users to disrupt dump -L and other important
operations that require snapshots.

Alternative 2 seems a lot more sensible.

Just my 2 KRW (1 USD ~= 1250 KRW) :D,
Eugene

On Thu, Jan 30, 2003 at 05:15:01PM -0600, Jacques A. Vidrine wrote:
 On Wed, Jan 29, 2003 at 06:17:31PM -0800, Kirk McKusick wrote:
 
 Alternative 1 `usermount'
  The first would be
  to change the default for vfs.usermount == 1 and then have dump -L
  create the snapshot in a directory owned by operator (or by
  whatever user runs the dumps). Then the snapshot could be created,
  used, and deleted by that user. 
 
 Alternative 2 `/sbin/snapshot'
  The other alternative would be to
  create a setuid-to-root program that would take a snapshot and
  chown it to the user that does dumps. This setuid program could
  then be invoked by dump -L to create a snapshot for it. 
 
 Despite a distaste for setuid executables, I think I'd prefer a simple
 /sbin/snapshot setuid program.  Primarily, enabling `vfs.usermount'
 gives more privileges to more users than I'm comfortable with.
 Secondarily, /sbin/snapshot may be useful on its own.
 
 Cheers,
 -- 
 Jacques A. Vidrine [EMAIL PROTECTED]  http://www.celabo.org/
 NTT/Verio SME  . FreeBSD UNIX .   Heimdal Kerberos
 [EMAIL PROTECTED] .  [EMAIL PROTECTED]  .  [EMAIL PROTECTED]
 
 To Unsubscribe: send mail to [EMAIL PROTECTED]
 with unsubscribe freebsd-current in the body of the message

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



Re: Hyperthreading and machdep.cpu_idle_hlt

2003-01-31 Thread John Baldwin

On 31-Jan-2003 Julian Elischer wrote:
 
 
 On Fri, 31 Jan 2003, John Baldwin wrote:
 
 
 On 31-Jan-2003 Julian Elischer wrote:
  
  
  On Fri, 31 Jan 2003, John Baldwin wrote:
  
   AT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,b28,ACC
   
   It has HTT set but it's only a 1.2GHz box and I heard somewhere that only
   2+ GHz P4's had hyperthreading.  I noticed some MFCs to stable that 
   suggested hyperthreading support but I do not know if full hyperthreading
   support has been MFCd yet or is intended to be MFCd to -stable.
   
   AFAIK, full hyperthreading support, as it is, has been merged to 
   -stable. It consists of a patch to recognize the virtual CPUs, so they 
   will be dealt with like any SMP system, as long as HTT is enabled on the 
   BIOS.
  
  Well, sort of.  We have no way of knowing if it is off in the BIOS unless
  we use the ACPI tables to enumerate CPU's (which we don't), so turning it
  off in the BIOS won't turn it off in FreeBSD for the time being. :)
  
  I have a 2,8GHz p4 here which has HTT and has a bios option for 
  
  Interrupt mode: [APIC/PIC]
  
  I'm using APIC mode but an SMP (today's 4.x) kernel
  panics imediatly saying it can;t find an APIC.
 
 You need to have an mptable for it to work.  The mptable will
 only list one processor, but it still needs to be there.
 
 if that comes from the BIOS, can it be simulated for 
 uniprocessor machines with HTT?

No.  It provides information on how to route PCI interrupts through
the IO APIC.  ACPI also has this information, but we don't handle the
IO APIC case right in ACPI yet.  That is on my todo list but is a much
larger task and will not be a 4.x feature.

-- 

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

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



KDE 3.1 Packages now available for 5.0-RELEASE

2003-01-31 Thread Andy Fawcett
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

We (kde@) have had some reported problems with the -CURRENT packages we 
made for KDE 3.1, not working correctly on FreeBSD 5.0-RELEASE, 
possibly due to our build system having a slightly newer than -RELEASE 
build of 5.0 on it.

Arjan van Leeuwen has kindly produced some packages for us which do work 
with 5.0-RELEASE, and you can find them at:

http://people.fruitsalad.org/avleeuwen/

There are still a couple of packages to come, but they will be uploaded 
later.

Regards,

Andy
(on behalf of Arjan and the whole KDE@FreeBSD team)

- -- 
Andy Fawcett | [EMAIL PROTECTED]
 | [EMAIL PROTECTED]
In an open world without walls and fences,  | [EMAIL PROTECTED]
  we wouldn't need Windows and Gates.  -- anon  | [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.1 (FreeBSD)

iD8DBQE+OveFmTJ5KYb5sqYRAlTgAKCRh/fohMLiU78q/lA9bQvI2ionQwCeO3aI
JZjhArgxco4GJ6jhz0PBQrU=
=XMbc
-END PGP SIGNATURE-


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



Mylex support under 5.0-R

2003-01-31 Thread Simon
Hi,

Is it just me or is the Mylex driver broken under FreeBSD 5.0-Release?
I couldn't dig up anything related in archives. I'm aware of bootup issues
using Mylex cards, but I already have it installed on IDE and trying to
work with a drive connected to a mylex controller locks up the system.

Thank you,
Simon



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



Re: Cisco vpnclient

2003-01-31 Thread Marcin Dalecki
Julian Elischer wrote:

what is the protocol they are using?


IPSec + IKE + group extensions.

The extensions are the problem.


On Fri, 31 Jan 2003, Christoph Kukulies wrote:



Cisco is offering a VPN client for Linux. I wonder if it would be possible
to run this under FreeBSD. An extra linux kernel module is being built.
Is this already the 'ruled out'?

If this won't work, I'm afraid I will have to set a dedicated redhat 6.x/7.x
beside my FreeBSD gateway. Would it be possible to use NAT to
extend the VPN (I only have one dedicated fixed IP on the gateway).

Excuse if this is not exactly on target of -current.

--
Chris Christoph P. U. Kukulies [EMAIL PROTECTED]

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





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





--
	Marcin Dalecki


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



alpha tinderbox failure

2003-01-31 Thread Dag-Erling Smorgrav
--
 Rebuilding the temporary build tree
--
 stage 1: bootstrap tools
--
 stage 2: cleaning up the object tree
--
 stage 2: rebuilding the object tree
--
 stage 2: build tools
--
 stage 3: cross tools
--
 stage 4: populating /home/des/tinderbox/alpha/obj/h/des/src/alpha/usr/include
--
 stage 4: building libraries
--
 stage 4: make dependencies
--
 stage 4: building everything..
--
 Kernel build for GENERIC started on Fri Jan 31 15:08:21 PST 2003
--
 Kernel build for GENERIC completed on Fri Jan 31 15:40:14 PST 2003
--
 Kernel build for LINT started on Fri Jan 31 15:40:15 PST 2003
--
=== vinum
Makefile, line 4447: warning: duplicate script for target geom_bsd.o ignored
/h/des/src/sys/dev/lmc/if_lmc.c:32:2: warning: #warning The lmc driver is broken and 
is not compiled with LINT
/h/des/src/sys/dev/pdq/pdq.c: In function `pdq_initialize':
/h/des/src/sys/dev/pdq/pdq.c:1606: warning: cast discards qualifiers from pointer 
target type
cc1: warnings being treated as errors
/h/des/src/sys/kern/vfs_syscalls.c: In function `chroot':
/h/des/src/sys/kern/vfs_syscalls.c:535: warning: `vp' might be used uninitialized in 
this function
*** Error code 1

Stop in /h/des/obj/h/des/src/sys/LINT.
*** Error code 1

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

Stop in /h/des/src.

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



Re: Smart Array 5312 (Compaq)

2003-01-31 Thread John
Well looks like it does work after all! I must not have created my install
floppies correctly (panic was couldn't find init btw) . I moved a few a
drives onto a 5i just so i could get 5.0 installed and running and 
recompiled the kernel with said patch and i can see and write to the drives. i 
have not tried booting off them yet but i will email back once i have.

Should i submit a PR for this?


On Fri, Jan 31, 2003 at 08:58:07AM -0800, Paul Saab wrote:
 The actual panic message would be a good thing to see.
 
 John ([EMAIL PROTECTED]) wrote:
  yea i tried that. 
  it almost works in 4.7. I can see the the drives in dmesg, 
  but it panics when it comes time to mount the mfs file system. 
  I'll have more time to test tomorrow (5.x, 4.x and CISS_BOARD_SA5 (no B) etc etc).
  
  
  Thanks!
  

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



State of the Union Report (backout request department)

2003-01-31 Thread Mark Linimon
(This is just a view from the sidelines; I generally do ports hacking
and not kernel hacking, and thus my views might not carry much
weight, but here goes anyways).

One of the more interesting features of the FreeBSD development
model seems to me to be the ability for people to request controversial
CVS commits to be backed out pending further technical discussion.
IMHO this seems like a wise (albeit nonintuitive) plan to avoid
meta-discussions about what should and should not have been
committed by whom and reviewed by whom (and so on and so forth).

But recently (especially since the 5.0 release) the backout request
mechanism seems to have fallen on hard times.  Without too much
difficulty, I was able to find 5 separate backout requests in this
year's archive of cvs-all alone which were not quickly honored.
(I'm not counting an ignored request for which the underlying
change was apparently security-related).  I'm not sure, but there
may have been others, possibly on freebsd-current.

The point I'm trying to make by posting this is not to take sides with
anyone, assign blame or credit, or anything like that.  I personally
came up in the old Usenet days, and thus have already gone down
that same road so many times that I would hope I've earned a lifetime 
Get-Out-Of-Flames-Free card for that reason alone (never mind
various mailing lists and other places controversy loves to incubate )

But if we've got that model, it seems to me we ought to honor it, even
if (especially if?) we think the request is frivolous or ill-intentioned.
After all, if the backout request itself wasn't controversial, it would
probably imply the original change wasn't controversial, and thus
who would care to ask to back it out in the first place?

I'm just asking folks to think about this so that the whole FreeBSD
project can move forward and ideas can rise and fall on their
technical merits, because frankly that's where the strength of
FreeBSD lies -- in its technical merits.

Mark Linimon


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



Re: Cisco vpnclient

2003-01-31 Thread Sean Chittenden
 Cisco is offering a VPN client for Linux. I wonder if it would be
 possible to run this under FreeBSD. An extra linux kernel module is
 being built.  Is this already the 'ruled out'?
 
 If this won't work, I'm afraid I will have to set a dedicated redhat
 6.x/7.x beside my FreeBSD gateway. Would it be possible to use NAT
 to extend the VPN (I only have one dedicated fixed IP on the
 gateway).

Might I suggest using pppd + ssh.  In my prior experience, it worked
worlds better than the Cisco VPN client and was likely provided a more
secure authentication (ssh keys vs. IKE?).  As an added bonus, it ssh
+ pppd doesn't hijack your interface so you can connect to the
Internet directly and to your office without having to send your
normal Internet traffic through the office.  Yes there are security
problems with this, but running ipf(w) on the split host works
exceedingly well and is generally a tighter firewall than what's put
up to protect the office.  ;)  -sc

-- 
Sean Chittenden

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



Re: Hyperthreading and machdep.cpu_idle_hlt

2003-01-31 Thread Dan Nelson
In the last episode (Jan 31), Don Bowman said:
 Thus the worst thing you could have would be a nop-loop with
 no stalls, which would squeeze the other to death.

I don't think this is possible, from looking at Intel's white papers.

 In practise I've found intel's numbers to be true, that the SMT gives
 you a ~20% boost, implying that there is nowhere close to a 50-50%
 split in normal use.

According to Hyper-Threading Technology Architecture and
Microarchitecture at
http://developer.intel.com/technology/itj/2002/volume06issue01/art01_hyper/vol6iss1_art01.pdf
, the internal schedulers make no distinction between the two logical
CPUs, and To avoid deadlock and ensure fairness, there is a limit on
the number of active entries that a logical processor can have in each
scheduler's queue.

That sounds like given identical processes running on both logical
CPUs, you will get a 50-50% balance.

I think for HT to be any help, FreeBSD's scheduler needs to know which
pairs of CPUs share resources, so it can schedule one process per pair
first, and any remaining runnable processes get put on the remaining
CPUs, possibly allocated so threads belonging to the same process run
on the same pair.

-- 
Dan Nelson
[EMAIL PROTECTED]

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



Re: Cisco vpnclient

2003-01-31 Thread Joe Marcus Clarke
On Fri, 2003-01-31 at 20:28, Sean Chittenden wrote:
  Cisco is offering a VPN client for Linux. I wonder if it would be
  possible to run this under FreeBSD. An extra linux kernel module is
  being built.  Is this already the 'ruled out'?
  
  If this won't work, I'm afraid I will have to set a dedicated redhat
  6.x/7.x beside my FreeBSD gateway. Would it be possible to use NAT
  to extend the VPN (I only have one dedicated fixed IP on the
  gateway).
 
 Might I suggest using pppd + ssh.  In my prior experience, it worked
 worlds better than the Cisco VPN client and was likely provided a more
 secure authentication (ssh keys vs. IKE?).  As an added bonus, it ssh
 + pppd doesn't hijack your interface so you can connect to the
 Internet directly and to your office without having to send your
 normal Internet traffic through the office.  Yes there are security
 problems with this, but running ipf(w) on the split host works
 exceedingly well and is generally a tighter firewall than what's put
 up to protect the office.  ;)  -sc

This is actually what I use to connect into Cisco (well, I use
ppp+ssh).  The downside is that right now, my VPN concentrator is
being moved from one building to another, and I have no FreeBSD
connectivity.  Also, other companies might only allow inbound access via
a proprietary VPN client.  For those that also offer SSH, you're right,
my make-shift VPN is much more flexible that what the Cisco VPN client
provides.

Joe

-- 
PGP Key : http://www.marcuscom.com/pgp.asc



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


Re: Cisco vpnclient

2003-01-31 Thread Marcin Dalecki
Sean Chittenden wrote:

Cisco is offering a VPN client for Linux. I wonder if it would be
possible to run this under FreeBSD. An extra linux kernel module is
being built.  Is this already the 'ruled out'?

If this won't work, I'm afraid I will have to set a dedicated redhat
6.x/7.x beside my FreeBSD gateway. Would it be possible to use NAT
to extend the VPN (I only have one dedicated fixed IP on the
gateway).



Might I suggest using pppd + ssh.  In my prior experience, it worked
worlds better than the Cisco VPN client and was likely provided a more
secure authentication (ssh keys vs. IKE?).  As an added bonus, it ssh
+ pppd doesn't hijack your interface so you can connect to the
Internet directly and to your office without having to send your
normal Internet traffic through the office.  Yes there are security
problems with this, but running ipf(w) on the split host works
exceedingly well and is generally a tighter firewall than what's put
up to protect the office.  ;)  -sc


The connection hijack by Cisco is indeed a very silly thing,
since the disabling of the routing of interfaces different
from the *one true and very secure* IPSec connection it is establishing
can be easly, very easly circumvented be deliberately changing
a string in the cisco linux kernel module. You have just to change
the string eth to eth0 or whatever in the source code there.
Well indeed some linux ethernet devices do not obey the ethXX naming
schema, namely they register themself as usbXXX devices, so
the whole thing in without any good reason in first place anyway.



--
	Marcin Dalecki


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



Re: Cisco vpnclient

2003-01-31 Thread Brandon S. Allbery
On Fri, 2003-01-31 at 21:20, Marcin Dalecki wrote:
 The connection hijack by Cisco is indeed a very silly thing,

Unfortunately, it's there because some corporate network policies demand
it.  And some companies are loath to allow Linux/FreeBSD/etc. on their
networks because it can be defeated.

-- 
brandon s allbery [openafs/solaris/japh/freebsd] [EMAIL PROTECTED]
system administrator [linux/heimdal/too many hats] [EMAIL PROTECTED]
electrical and computer engineering  KF8NH
carnegie mellon university  [better check the oblivious first -ke6sls]


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



Re: State of the Union Report (backout request department)

2003-01-31 Thread Mike Barcroft
Mark Linimon [EMAIL PROTECTED] writes:
 (This is just a view from the sidelines; I generally do ports hacking
 and not kernel hacking, and thus my views might not carry much
 weight, but here goes anyways).
 
 One of the more interesting features of the FreeBSD development
 model seems to me to be the ability for people to request controversial
 CVS commits to be backed out pending further technical discussion.
 IMHO this seems like a wise (albeit nonintuitive) plan to avoid
 meta-discussions about what should and should not have been
 committed by whom and reviewed by whom (and so on and so forth).
 
 But recently (especially since the 5.0 release) the backout request
 mechanism seems to have fallen on hard times.  Without too much
 difficulty, I was able to find 5 separate backout requests in this
 year's archive of cvs-all alone which were not quickly honored.
 (I'm not counting an ignored request for which the underlying
 change was apparently security-related).  I'm not sure, but there
 may have been others, possibly on freebsd-current.

The archives might not be telling the whole story.  A lot of times
these things get handled behind closed doors, whether private e-mail
or developer-only lists.  Thankfully though, most conflicts *do* get
resolved. :)

Best regards,
Mike Barcroft

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



Re: State of the Union Report (backout request department)

2003-01-31 Thread Juli Mallett
* De: Mike Barcroft [EMAIL PROTECTED] [ Data: 2003-01-31 ]
[ Subjecte: Re: State of the Union Report (backout request department) ]
 The archives might not be telling the whole story.  A lot of times
 these things get handled behind closed doors, whether private e-mail
 or developer-only lists.  Thankfully though, most conflicts *do* get
 resolved. :)

Might be nice if we had an internal trouble ticket system for things like
this, TODOs that are high priority, and pending MFCs.  I got the impression
NetBSD does something like this for branch pullups that are needed?
Then there's a clearer qudit trail, and it's easier to find out if things
have not been honoured.  And to keep other sorts of things from falling
behind.

Thanx,
juli.
-- 
Juli Mallett [EMAIL PROTECTED]
AIM: BSDFlata -- IRC: juli on EFnet
OpenDarwin, Mono, FreeBSD Developer
ircd-hybrid Developer, EFnet addict
FreeBSD on MIPS-Anything on FreeBSD

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



Re: State of the Union Report (backout request department)

2003-01-31 Thread Wesley Morgan
On Fri, 31 Jan 2003, Mike Barcroft wrote:

 The archives might not be telling the whole story.  A lot of times
 these things get handled behind closed doors, whether private e-mail
 or developer-only lists.  Thankfully though, most conflicts *do* get
 resolved. :)

I have always LOVED watching the commits and backouts. I find it much more
exciting to watch the actual development commit by commit, watch the
brainiacs audit each other, and resolve to the best course. It seems much
better than the way Linux traditionally did it (although they seem to have
moved to bitkeeper) and much more like a professional development team.


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

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



Re: dump -L and privilege

2003-01-31 Thread Kirk McKusick
From: Jun Kuriyama [EMAIL PROTECTED]
To: Kirk McKusick [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: dump -L and privilege
In-Reply-To: [EMAIL PROTECTED]
X-ASK-Info: Whitelist match

Is this enough?

-r-sr-x---  1 root  operator  5750 Jan 31 22:13 mksnap_ffs

o Should use filesystem device name rather than mountpoint?
o Should use the group of device rather than operator?


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

The mount command needs the mountpoint, not the device name, so
the device name would only be needed if we want to use the group
of the device rather than operator. I argue that we should use
operator rather than the group of the device because the purpose
of this command is to allow the dump program, run by people in 
the operator group, to take snapshots.

At any rate, I have cleaned up the program and provided a Makefile 
and manual page (see below). The only semantic change that I made
to your program was to do the `chown' before doing the `chmod' so
as not to open a brief hole that would allow members of the default
(wheel) group to get read access to the snapshot.

Kirk McKusick

# This is a shell archive.  Save it in a file, remove anything before
# this line, and then unpack it by entering sh file.  Note, it may
# create directories; files and directories will be owned by you and
# have default permissions.
#
# This archive contains:
#
#   mksnap_ffs/Makefile
#   mksnap_ffs/mksnap_ffs.8
#   mksnap_ffs/mksnap_ffs.c
#
mkdir mksnap_ffs
echo x - mksnap_ffs/Makefile
sed 's/^X//' mksnap_ffs/Makefile  'END-of-mksnap_ffs/Makefile'
X# $FreeBSD$
X
XPROG=  mksnap_ffs
XMAN=   mksnap_ffs.8
X
X.if defined(NOSUID)
XBINMODE=550
X.else
XBINMODE=4550
XBINOWN=root
X.endif
XBINGRP=operator
X
X.include bsd.prog.mk
END-of-mksnap_ffs/Makefile
echo x - mksnap_ffs/mksnap_ffs.8
sed 's/^X//' mksnap_ffs/mksnap_ffs.8  'END-of-mksnap_ffs/mksnap_ffs.8'
X.\
X.\ Copyright (c) 2003 Networks Associates Technology, Inc.
X.\ All rights reserved.
X.\
X.\ This software was developed for the FreeBSD Project by Marshall
X.\ Kirk McKusick and Network Associates Laboratories, the Security
X.\ Research Division of Network Associates, Inc. under DARPA/SPAWAR
X.\ contract N66001-01-C-8035 (CBOSS), as part of the DARPA CHATS
X.\ research program.
X.\
X.\ Redistribution and use in source and binary forms, with or without
X.\ modification, are permitted provided that the following conditions
X.\ are met:
X.\ 1. Redistributions of source code must retain the above copyright
X.\notice, this list of conditions and the following disclaimer.
X.\ 2. Redistributions in binary form must reproduce the above copyright
X.\notice, this list of conditions and the following disclaimer in the
X.\documentation and/or other materials provided with the distribution.
X.\ 3. The names of the authors may not be used to endorse or promote
X.\products derived from this software without specific prior written
X.\permission.
X.\
X.\ THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
X.\ ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
X.\ IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
X.\ ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
X.\ FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
X.\ DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
X.\ OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
X.\ HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
X.\ LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
X.\ OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
X.\ SUCH DAMAGE.
X.\
X.\ $FreeBSD$
X.\
X.Dd January 19, 2003
X.Dt MKSNAP_FFS 8
X.Os
X.Sh NAME
X.Nm mksnap_ffs
X.Nd take a filesystem snapshot
X.Sh SYNOPSIS
X.Nm
X.Ar mountpoint
X.Ar snapshot_name
X.Sh DESCRIPTION
XThe
X.Nm
Xcommand creates a snapshot named
X.Ar snapshot_name
Xon the filesystem mounted at
X.Ar mountpoint .
XThe
X.Ar snapshot_name
Xargument must be contained within the filesystem mounted at
X.Ar mountpoint .
X.Pp
XThe group ownership of the file is set to
X.Dq operator ;
Xthe owner of the file remains
X.Dq root .
XThe mode of the snapshot is set to be readable by the owner
Xor members of the
X.Dq operator
Xgroup.
X.Sh SEE ALSO
X.Xr chmod 2 ,
X.Xr chown 8 ,
X.Xr mount_ffs 8
X.Sh HISTORY
XA
X.Nm
Xcommand first appeared in
X.Fx 5.0 .
END-of-mksnap_ffs/mksnap_ffs.8
echo x - mksnap_ffs/mksnap_ffs.c
sed 's/^X//' mksnap_ffs/mksnap_ffs.c  'END-of-mksnap_ffs/mksnap_ffs.c'
X/*
X * Copyright (c) 2003 Networks Associates Technology, Inc.
X * All rights reserved.
X *
X * This software was developed for the FreeBSD Project by Marshall
X * Kirk McKusick and 

Re: Smart Array 5312 (Compaq)

2003-01-31 Thread Paul Saab
John ([EMAIL PROTECTED]) wrote:
 Well looks like it does work after all! I must not have created my install
 floppies correctly (panic was couldn't find init btw) . I moved a few a
 drives onto a 5i just so i could get 5.0 installed and running and 
 recompiled the kernel with said patch and i can see and write to the drives. i 
 have not tried booting off them yet but i will email back once i have.
 
 Should i submit a PR for this?

I'll commit this stuff soon.

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



Re: Seat-belt for source upgrades from stable to current

2003-01-31 Thread Giorgos Keramidas
On 2003-01-30 21:38, David Schultz [EMAIL PROTECTED] wrote:
 Thus spake Mike Makonnen [EMAIL PROTECTED]:
  Use the r version of the cvs commands (like cvs rlog and rdiff). They operate on
  the repository remotely, so you don't need to have the files checked out localy.

 That's a pretty good solution, and I use those occasionally.  It
 would be a perfect solution if there were an 'rupdate', so I don't
 have to (cd /tmp; cvs co src/file/i/want.c)
cp /tmp/src/file/i/want.c /where/i/want/it
rm -rf /tmp/src
 all the time.

# cd /tmp
# cvs -d 'repo magic' export -rHEAD src/file/i/want.c

Does `cvs export' do the trick for you?


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



Re: Seat-belt for source upgrades from stable to current

2003-01-31 Thread David Schultz
Thus spake Giorgos Keramidas [EMAIL PROTECTED]:
 On 2003-01-30 21:38, David Schultz [EMAIL PROTECTED] wrote:
  Thus spake Mike Makonnen [EMAIL PROTECTED]:
   Use the r version of the cvs commands (like cvs rlog and rdiff). They operate on
   the repository remotely, so you don't need to have the files checked out localy.
 
  That's a pretty good solution, and I use those occasionally.  It
  would be a perfect solution if there were an 'rupdate', so I don't
  have to (cd /tmp; cvs co src/file/i/want.c)
   cp /tmp/src/file/i/want.c /where/i/want/it
   rm -rf /tmp/src
  all the time.
 
   # cd /tmp
   # cvs -d 'repo magic' export -rHEAD src/file/i/want.c
 
 Does `cvs export' do the trick for you?

Actually, 'cvs export' does the opposite of what I want to do.
But thank you for mentioning it, because it's a good way to
explain what I'm trying to do, so people don't keep assuming that
my problem is not knowing how to use CVS.

'cvs checkout': create a copy of the sources AND CVS's
administrative directories

'cvs export': just create a copy of the sources

What I want to do: just create the administrative directories

I'm aware that making CVS magically discover what version I have
is a bit much to ask for, so I'm willing to tell it what tag to
use.  Unfortunately, I don't think the facility I want exists, but
I'm going to try to implement a workaround when I have a moment.

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



Re: Seat-belt for source upgrades from stable to current

2003-01-31 Thread Juli Mallett
* De: Giorgos Keramidas [EMAIL PROTECTED] [ Data: 2003-01-31 ]
[ Subjecte: Re: Seat-belt for source upgrades from stable to current ]
 On 2003-01-30 21:38, David Schultz [EMAIL PROTECTED] wrote:
  Thus spake Mike Makonnen [EMAIL PROTECTED]:
   Use the r version of the cvs commands (like cvs rlog and rdiff). They operate on
   the repository remotely, so you don't need to have the files checked out localy.
 
  That's a pretty good solution, and I use those occasionally.  It
  would be a perfect solution if there were an 'rupdate', so I don't
  have to (cd /tmp; cvs co src/file/i/want.c)
   cp /tmp/src/file/i/want.c /where/i/want/it
   rm -rf /tmp/src
  all the time.
 
   # cd /tmp
   # cvs -d 'repo magic' export -rHEAD src/file/i/want.c
 
 Does `cvs export' do the trick for you?

Further, export -d somedir might be useful in this situation to get the
files where you want them, though sometimes -d does not DWIM, so I'm
not sure :)
-- 
Juli Mallett [EMAIL PROTECTED]
AIM: BSDFlata -- IRC: juli on EFnet
OpenDarwin, Mono, FreeBSD Developer
ircd-hybrid Developer, EFnet addict
FreeBSD on MIPS-Anything on FreeBSD

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



Re: State of the Union Report (backout request department)

2003-01-31 Thread David Schultz
Thus spake Wesley Morgan [EMAIL PROTECTED]:
 On Fri, 31 Jan 2003, Mike Barcroft wrote:
 
  The archives might not be telling the whole story.  A lot of times
  these things get handled behind closed doors, whether private e-mail
  or developer-only lists.  Thankfully though, most conflicts *do* get
  resolved. :)
 
 I have always LOVED watching the commits and backouts. I find it much more
 exciting to watch the actual development commit by commit, watch the
 brainiacs audit each other, and resolve to the best course. It seems much
 better than the way Linux traditionally did it (although they seem to have
 moved to bitkeeper) and much more like a professional development team.

The problem is that once something is in the tree and someone asks
for a backout, there is a stigma attached to it.  It's as though
the original committer would be admitting that he's wrong by
backing it out, even if his commit is justified.  So he gets
defensive about it (and sometimes everyone else gets annoyed while
their builds fail), and thus a DSW breaks out and people spend
hours of their time being generally nasty and unproductive.
People need to think of backouts as a form of bookkeeping and not
as an admission of error.  They should also try to minimize their
occurrence, i.e. I shouldn't be able to read through the CVS logs
and predict ``uh oh, there's gonna be hell about this...''

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



Re: Seat-belt for source upgrades from stable to current

2003-01-31 Thread David Schultz
Thus spake Juli Mallett [EMAIL PROTECTED]:
 * De: Giorgos Keramidas [EMAIL PROTECTED] [ Data: 2003-01-31 ]
   [ Subjecte: Re: Seat-belt for source upgrades from stable to current ]
  On 2003-01-30 21:38, David Schultz [EMAIL PROTECTED] wrote:
   Thus spake Mike Makonnen [EMAIL PROTECTED]:
Use the r version of the cvs commands (like cvs rlog and rdiff). They operate 
on
the repository remotely, so you don't need to have the files checked out 
localy.
  
   That's a pretty good solution, and I use those occasionally.  It
   would be a perfect solution if there were an 'rupdate', so I don't
   have to (cd /tmp; cvs co src/file/i/want.c)
  cp /tmp/src/file/i/want.c /where/i/want/it
  rm -rf /tmp/src
   all the time.
  
  # cd /tmp
  # cvs -d 'repo magic' export -rHEAD src/file/i/want.c
  
  Does `cvs export' do the trick for you?
 
 Further, export -d somedir might be useful in this situation to get the
 files where you want them, though sometimes -d does not DWIM, so I'm
 not sure :)

That works when the revision has a symbolic tag associated with
it, but export seems to be picky and won't do numeric revision
numbers of particular files.  I guess I could always go by date.
And yes, -d is picky, too; you can't export into your working
directory.  Still, not bad...

It doesn't address the entire problem I mentioned before, because
I still want to do diffs between local revisions and the
repository.  This thread is just a subthread of the original
thread in which I guess we're talking about how to do a 'cvs
update' without a copy of the repository.  (Sorry Giorgos, your
idea actually works for updates, just not for the original
question I was asking.  I was confused.  ENOSLEEP.)

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



RE: intalling from cds

2003-01-31 Thread John Baldwin

On 31-Jan-2003 Kirk R Wythers wrote:
 I ran into a strange issue while trying to do a cd install from the
 5.0-RELEASE cds. After booting from the cd, the install skips the kernel
 configuration menue completely (I've never seen that before), then jumps
 right into sysinsall. I select 'standard install', and I see the folloing:

The USERCONFIG stuff isn't around anymore in 5.0.

 afd0
 da0
 da1
 
 adf0 is a zip250 drive on this box. Why is that showing up here? If I
 choose to use the entire disk on da0 and da1 (no dual boot concerns), and
 install the 'standard mbr' on the da0, I seem to be stuck going back to the
 'choose the drive' 
 
 afd0
 da0
 da1 
 
 menue without getting to the the disklable editor
 
 What am I doing wrong? thanks

Use Tab to move down to 'Ok' after you have finished using fdisk on
your drives and then hit Enter to continue.

-- 

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

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



intalling from cds

2003-01-31 Thread Kirk R Wythers
I ran into a strange issue while trying to do a cd install from the
5.0-RELEASE cds. After booting from the cd, the install skips the kernel
configuration menue completely (I've never seen that before), then jumps
right into sysinsall. I select 'standard install', and I see the folloing:

afd0
da0
da1

adf0 is a zip250 drive on this box. Why is that showing up here? If I
choose to use the entire disk on da0 and da1 (no dual boot concerns), and
install the 'standard mbr' on the da0, I seem to be stuck going back to the
'choose the drive' 

afd0
da0
da1 

menue without getting to the the disklable editor

What am I doing wrong? thanks


ps... sorry for cross posting, but I wasn't sure which group this fell to
the best...



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



Re: copy extended attributes

2003-01-31 Thread Doug Barton
Forgive me for being dense, but can you expand on your concerns?

Doug


On Fri, 31 Jan 2003, Daniel C. Sobral wrote:

 I'm starting to have a bad feeling about mergemaster and /etc's full of
 acl and mac labels...

 Robert Watson wrote:
 
  I have local patches submitted by Chris Faulhaber to copy ACLs when a file
  is copied (or moved between file systems) that I've been meaning to finish
  testing and merge.  Likewise, for gzip, bzip, and others when a file is
  replaced.  This wouldn't address the general issue of copying extended
  attributes, but is a necessary step.  Presumably if we did extend cp, et
  al, to copy EA's, they should explicitly copy only user namespace EAs, not
  system EAs.   There's been some recent e-mail on the Linux side about
  interfaces to copy ACLs from one file to another, but I haven't had a
  chance to review those changes as yet to see whether we should pick them
  up.



-- 

If it's moving, encrypt it. If it's not moving, encrypt
  it till it moves, then encrypt it some more.

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