Re: rm -rf question

2001-05-24 Thread J Wunsch

Alexander Langer [EMAIL PROTECTED] wrote:

 It's xargs job to workaround that:
 
 ls | xargs rm -rf 

rm -rf /home/gary/public_html/mrtg/david

should have worked as well.  It also removes the directory itself,
yes, but since it's then rm(1) that does the directory handling,
there's no longer a limitation in the arg list that applies.

-- 
cheers, Jorg   .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)

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



Re: rm -rf question

2001-05-24 Thread Ceri

On Thu, May 24, 2001 at 10:40:46AM +0200, J Wunsch said:
 Alexander Langer [EMAIL PROTECTED] wrote:
 
  ls | xargs rm -rf 
 
 rm -rf /home/gary/public_html/mrtg/david
 
If you're running as root, neither of those do the same thing
as
rm -rf /home/gary/public_html/mrtg/david/*

What if that directory also has a few file called .dont_delete
in it ?  You both just deleted it (note disclaimer about running
as root for the first one - the ls -A alias being the reason).

Ceri

-- 
Your local RFC Nazi

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



Re: harddisk faillure or kernel problem ?

2001-05-24 Thread Stephan van Beerschoten

Oops, I accidently mailed this to -CURRENT. Sorry folks.
 I bounced it to -STABLE

On Wed, 23 May 2001, Stephan van Beerschoten wrote:

 For a while now I keep having the following logentries in my messages file:
 
 May 23 13:59:40 enigma /kernel: ad0s1a: UDMA ICRC error reading fsbn 1704031 of 
720912-720913 (ad0s1 bn 17040
 31; cn 1803 tn 3 sn 7) retrying
 May 23 13:59:40 enigma /kernel: ad0s1a: UDMA ICRC error reading fsbn 2857979 of 
1297886-1297887 (ad0s1 bn 285
 7979; cn 3024 tn 4 sn 47) retrying
 May 23 13:59:40 enigma /kernel: ad0s1a: UDMA ICRC error reading fsbn 3689535 of 
1713664-1713677 (ad0s1 bn 368
 9535; cn 3904 tn 4 sn 3) retrying
 May 23 13:59:40 enigma /kernel: ad0s1a: UDMA ICRC error reading fsbn 4198463 of 
1968128-1968129 (ad0s1 bn 419
 8463; cn 4442 tn 12 sn 17) retrying
 May 23 13:59:40 enigma /kernel: ad0s1a: UDMA ICRC error reading fsbn 4607039 of 
2172416-2172419 (ad0s1 bn 460
 7039; cn 4875 tn 2 sn 38) retrying
 
 Is this because of some UDMA option in my kernel that I have or may have missed, or 
is this really hardware ?
  I've had this for months now and never actually bothered because it never gave me 
any problems,
  at least not noticable ones. I use the machine remotely mainly, so harddisk speeds 
that may
  have dropped because of this are hardly noticable if you're just doing commandline 
work.
 
 Diagnoses: Do I need to replace hardware here, or not ?
 
 FreeBSD .xx.xxx.xx.xx 4.3-STABLE FreeBSD 4.3-STABLE #3: Tue May 15 20:23:48 CEST 
2001 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/ENIGMA  i386
 
 
 Thanks, 
  Stephan
 
 -- 
 Stephan van Beerschoten [SVB21-RIPE]   [EMAIL PROTECTED]
   PGP fingerprint:  4557 9761 B212 FB4C  778D 3529 C42A 2D27
  To err is human, to forgive is Not Company Policy
 
 To Unsubscribe: send mail to [EMAIL PROTECTED]
 with unsubscribe freebsd-current in the body of the message

-- 
Stephan van Beerschoten [SVB21-RIPE]   [EMAIL PROTECTED]
  PGP fingerprint:  4557 9761 B212 FB4C  778D 3529 C42A 2D27
 To err is human, to forgive is Not Company Policy

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



Re: rm -rf question

2001-05-24 Thread Peter Wemm

J Wunsch wrote:
 Alexander Langer [EMAIL PROTECTED] wrote:
 
  It's xargs job to workaround that:
  
  ls | xargs rm -rf 
 
 rm -rf /home/gary/public_html/mrtg/david
 
 should have worked as well.  It also removes the directory itself,
 yes, but since it's then rm(1) that does the directory handling,
 there's no longer a limitation in the arg list that applies.

Incidently, find /home/gary/public_html/mrtg/david -delete would have
worked as well, and would not have deleted the top directory.

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: Tonights panic: free_newdirblk+0x73: movl %eax,0x10(%e

2001-05-24 Thread Michael Harnois

On Wed, 23 May 2001 22:10:09 -0300 (ADT), The Hermit Hacker [EMAIL PROTECTED] said:

 Oops ... neat, now it just locked up solid and ctl-alt-esc
 doesn't even get me to debugger :(

This has been my experience for about a week on the -current kernel
... I held out high hopes that these changes by John and Alfred over
the past 24 hours or so would fix it, but no go ...

-- 
Michael D. Harnois[EMAIL PROTECTED]
Redeemer Lutheran Church  Washburn, Iowa 
 It's not what we don't know that hurts us, 
 it's what we know for certain that just ain't so. -- Mark Twain

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



Re: Tonights panic: free_newdirblk+0x73: movl %eax,0x10(%e

2001-05-24 Thread Edwin Culp

Quoting Michael Harnois [EMAIL PROTECTED]:

 On Wed, 23 May 2001 22:10:09 -0300 (ADT), The Hermit Hacker [EMAIL PROTECTED]
 said:
 
  Oops ... neat, now it just locked up solid and ctl-alt-esc
  doesn't even get me to debugger :(
 
 This has been my experience for about a week on the -current kernel
 ... I held out high hopes that these changes by John and Alfred over
 the past 24 hours or so would fix it, but no go ...

Actually, I cvsuped after John's changes yesterday and built a new kernel on my
memory poor k-6 300 that had been sideline for 3 or 4 days and I have been using
it for 12 hours with no lockups, although I am still holding my breath:-)  I
haven't been able to make a world after two tries in these 12 hours, but maybe
it's better:-).

Thanks to John, Alfred and everyone who contributed to the patch,

ed

---
   The illiterate of the 21st century will not be
 those who cannot read and write, 
   but those who cannot learn, unlearn and relearn. 
--Alvin Toffler

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



Re: sbin/vinum broken

2001-05-24 Thread Ruslan Ermilov

On Thu, May 24, 2001 at 09:24:56AM +0930, Greg Lehey wrote:
 On Wednesday, 23 May 2001 at 16:56:39 +0300, Ruslan Ermilov wrote:
  Hi!
 
  src/sbin/vinum is broken at the moment.
  It doesn't build without -DVINUMDEBUG.
 
 *sigh*.  I could have sworn I tested this, but it seems I did it in a
 parallel universe.  It's fixed now, I think.  me-pointyhat++;
 
 
  A quick workaround:
 
  Index: Makefile
  ===
  RCS file: /home/ncvs/src/sbin/vinum/Makefile,v
  retrieving revision 1.20
  diff -u -r1.20 Makefile
  --- Makefile2001/05/23 05:24:53 1.20
  +++ Makefile2001/05/23 13:55:24
  @@ -5,6 +5,7 @@
   MAN=   vinum.8
 
   CFLAGS+=   -I${.CURDIR}/../../sys -Wall
  +CFLAGS+=   -DVINUMDEBUG
 
 This didn't work for me:
 
 === root@zaphod (/dev/ttyp1) /src/FreeBSD/5.0-CURRENT/src/sbin/vinum 4 - make
 Warning: Using /wantadilla/home/obj/src/FreeBSD/5.0-CURRENT/src/sbin/vinum as object 
directory instead of canonical /usr/obj/src/FreeBSD/5.0-CURRENT/src/sbin/vinum
 cc -O -pipe -c /src/FreeBSD/5.0-CURRENT/src/sbin/vinum/v.c
 In file included from /src/FreeBSD/5.0-CURRENT/src/sbin/vinum/v.c:57:
 /src/FreeBSD/5.0-CURRENT/src/sbin/vinum/vext.h:75: dev/vinum/vinumvar.h: No such 
file or directory
 /src/FreeBSD/5.0-CURRENT/src/sbin/vinum/vext.h:76: dev/vinum/vinumio.h: No such file 
or directory
 /src/FreeBSD/5.0-CURRENT/src/sbin/vinum/vext.h:77: dev/vinum/vinumkw.h: No such file 
or directory
 /src/FreeBSD/5.0-CURRENT/src/sbin/vinum/vext.h:78: dev/vinum/vinumutil.h: No such 
file or directory
 
 Am I missing something?
 
I bet you specified CFLAGS on a command line, and that clobbered
CFLAGS+=-I${.CURDIR}/../../sys from Makefile.  Otherwise, I fail
to see why there's no -I... in the above output.

Missing /usr/include/dev/vinum headers, yeah?  :-)


Cheers,
-- 
Ruslan Ermilov  Oracle Developer/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

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



Re: Tonights panic: free_newdirblk+0x73: movl %eax,0x10(%e

2001-05-24 Thread John Baldwin


On 24-May-01 Michael Harnois wrote:
 On Wed, 23 May 2001 22:10:09 -0300 (ADT), The Hermit Hacker [EMAIL PROTECTED]
 said:
 
  Oops ... neat, now it just locked up solid and ctl-alt-esc
  doesn't even get me to debugger :(
 
 This has been my experience for about a week on the -current kernel
 ... I held out high hopes that these changes by John and Alfred over
 the past 24 hours or so would fix it, but no go ...

I had a epiphany this morning, and will be committing a bandaid to get current
workign again on SMP systems.  The problem occurs when we take a fault while
hold the vm lock already.  In that case, the VM was in an inconsistent state
when we faulted.  That's why we were holding the lock when we faulted.  Well,
there are places in the fault handler where we release the vm lock to sleep or
acquire Giant or some such.  When we do so, we allow another thread to try and
dink with the VM, which can lead to threads trying to use free'd pages, etc. on
SMP systems.  The bandaid is to stick all the VM related syscalls that were
marked MPSAFE back under Giant for the time being, which I will do shortly.

-- 

John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/
PGP Key: http://www.baldwin.cx/~john/pgpkey.asc
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: GENERIC kernel hangs at boot (uhci-related)

2001-05-24 Thread Warner Losh

In message [EMAIL PROTECTED] Nick Hibma writes:
: 'It' in the second case refers to the PCI irq allocation code I presume?
: An irq that is 0 or 255 is invalid and should not be allocated to a PCI
: device. But speaking about rev1.32, how would you assign an interrupt as
: is stated in the log message for rev1.32?

255 means none assigned.  The INTPIN register determines if you
should allocate a irq to the device or not.

Warner

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



Re: GENERIC kernel hangs at boot (uhci-related)

2001-05-24 Thread Warner Losh

In message [EMAIL PROTECTED] [EMAIL PROTECTED] 
writes:
: The problem is not that the PCI device is not initialised, but that the
: device is assigned a bogus irq (0/255) by the BIOS. 

That's not true.  They are the default values by the chip.  The BIOS
likely isn't initializing the chip at all.  The PCI infrastructure
should do the right thing, and mike's new code does do the right
thing.

Warner

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



Re: ** HEADS UP **: sys/miscfs file systems moved

2001-05-24 Thread Warner Losh

In message [EMAIL PROTECTED] Brian Somers writes:
: It may also be worth mentioning that people should move /usr/include 
: to (say) /usr/include.not before their next installworld and nuke 
: /usr/include.not after it completes.

Eh?  that's a bug in the installation proceedure then.

Warner

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



Re: Date for a working -current?

2001-05-24 Thread Warner Losh

In message [EMAIL PROTECTED] Joseph Koshy writes:
: I'm in the processing of bring a 5-current system of Oct 2000 vintage
: more upto-date. 

May 18th, 2001 12:00:00 is what I've been using.

Warner

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



Re: Date for a working -current?

2001-05-24 Thread Peter Wemm

Warner Losh wrote:
 In message [EMAIL PROTECTED] Joseph Koshy writes:
 : I'm in the processing of bring a 5-current system of Oct 2000 vintage
 : more upto-date. 
 
 May 18th, 2001 12:00:00 is what I've been using.
 
 Warner

But you may want to cd sys/ufs/ffs; cvs update -A *softdep*
straight afterwards.  I dont know if your date comes before the soft updates
problems, but updating those files to HEAD solves the problems that are in
softdep immediately before the VM problems.

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: sbin/vinum broken

2001-05-24 Thread Greg Lehey

On Thursday, 24 May 2001 at 18:28:19 +0300, Ruslan Ermilov wrote:
 On Thu, May 24, 2001 at 09:24:56AM +0930, Greg Lehey wrote:
 On Wednesday, 23 May 2001 at 16:56:39 +0300, Ruslan Ermilov wrote:
 Hi!

 src/sbin/vinum is broken at the moment.
 It doesn't build without -DVINUMDEBUG.

 *sigh*.  I could have sworn I tested this, but it seems I did it in a
 parallel universe.  It's fixed now, I think.  me-pointyhat++;


 A quick workaround:

 Index: Makefile
 ===
 RCS file: /home/ncvs/src/sbin/vinum/Makefile,v
 retrieving revision 1.20
 diff -u -r1.20 Makefile
 --- Makefile2001/05/23 05:24:53 1.20
 +++ Makefile2001/05/23 13:55:24
 @@ -5,6 +5,7 @@
  MAN=   vinum.8

  CFLAGS+=   -I${.CURDIR}/../../sys -Wall
 +CFLAGS+=   -DVINUMDEBUG

 This didn't work for me:

 === root@zaphod (/dev/ttyp1) /src/FreeBSD/5.0-CURRENT/src/sbin/vinum 4 - make
 Warning: Using /wantadilla/home/obj/src/FreeBSD/5.0-CURRENT/src/sbin/vinum as 
object directory instead of canonical /usr/obj/src/FreeBSD/5.0-CURRENT/src/sbin/vinum
 cc -O -pipe -c /src/FreeBSD/5.0-CURRENT/src/sbin/vinum/v.c
 In file included from /src/FreeBSD/5.0-CURRENT/src/sbin/vinum/v.c:57:
 /src/FreeBSD/5.0-CURRENT/src/sbin/vinum/vext.h:75: dev/vinum/vinumvar.h: No such 
file or directory
 /src/FreeBSD/5.0-CURRENT/src/sbin/vinum/vext.h:76: dev/vinum/vinumio.h: No such 
file or directory
 /src/FreeBSD/5.0-CURRENT/src/sbin/vinum/vext.h:77: dev/vinum/vinumkw.h: No such 
file or directory
 /src/FreeBSD/5.0-CURRENT/src/sbin/vinum/vext.h:78: dev/vinum/vinumutil.h: No such 
file or directory

 Am I missing something?

 I bet you specified CFLAGS on a command line, and that clobbered
 CFLAGS+=-I${.CURDIR}/../../sys from Makefile.

No, that wasn't it.

 Otherwise, I fail to see why there's no -I... in the above output.

So do I.  It works now.  But I don't understand what has changed.  

 Missing /usr/include/dev/vinum headers, yeah?  :-)

No, of course not.  With the -I it worked fine.

Greg
--
Finger [EMAIL PROTECTED] for PGP public key
See complete headers for address and phone numbers

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



Re: mount_mfs (Re: smbfs)

2001-05-24 Thread Kris Kennaway

On Thu, May 24, 2001 at 10:35:43PM -0400, Mikhail Teterin wrote:
 On 24 May, Kris Kennaway wrote:
  On Thu, May 24, 2001 at 06:13:21PM -0700, Gordon Tetlow wrote:
  Should there be a mount_smbfs to go with this? How does one mount smb
  shares otherwise?
  
  It's in the smbfs port.
 
 Shouldn't it move to the base system now?
 
 BTW, what happened to mount_mfs in current? It still gives this nasty
 warning about migrating to mdconfig, waits 15 seconds and then panics
 my machine.

Mine too.  It also appears there's no canonical (i.e. rc.conf) knob
for configuring /tmp as a MD (there are however instructions in the
manpage which I hacked in manually on my system)

Kris

 PGP signature


Re: mount_mfs (Re: smbfs)

2001-05-24 Thread Dima Dorfman

Kris Kennaway [EMAIL PROTECTED] writes:
 
 --3MwIy2ne0vdjdPXF
 Content-Type: text/plain; charset=us-ascii
 Content-Disposition: inline
 Content-Transfer-Encoding: quoted-printable
 
 On Thu, May 24, 2001 at 10:35:43PM -0400, Mikhail Teterin wrote:
  On 24 May, Kris Kennaway wrote:
   On Thu, May 24, 2001 at 06:13:21PM -0700, Gordon Tetlow wrote:
   Should there be a mount_smbfs to go with this? How does one mount smb
   shares otherwise?
  
   It's in the smbfs port.
 
  Shouldn't it move to the base system now?
 
  BTW, what happened to mount_mfs in current? It still gives this nasty
  warning about migrating to mdconfig, waits 15 seconds and then panics
  my machine.
 
 Mine too.  It also appears there's no canonical (i.e. rc.conf) knob
 for configuring /tmp as a MD (there are however instructions in the
 manpage which I hacked in manually on my system)

Sheldon Hearn posted a patch to add such a knob around January when we
were having this exact discussion.  Personally, I think it only solves
half a problem; what if you want /tmp and /tmp2?  And why should it be
limited to boot-up?  Perhaps there's use for a program which emulates
mount_mfs using md.

I actually wrote a short program that emulates *all* of mount_mfs's
umpteen options with md, disklabel, and newfs, but nobody seemed
interested.  My choice of name (mount_md) wasn't particuarly good,
either.  Look at the -hackers and cvs-all archives around late January
and early February for the discussions.  I still have that program,
and it works great, so perhaps I should make it a port (comments?).

Regards,

Dima Dorfman
[EMAIL PROTECTED]

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



Re: tail -f over NFS in -stable

2001-05-24 Thread Doug Barton

Blast from the past. This patch seemed reasonable to me at the time, but I
notice you didn't commit it. Any reason why? The issue has just come up
again on -questions.

Doug

Ben Smithurst wrote:
 
 Fred Gilham wrote:
 
  In 4.1-stable tail -f over NFS polls rather than blocking.
 
 Yes, this is acknowledged in the kqueue() manual page.  Try this patch,
 it seems to work for me so I might commit it if no-one objects.
 
 Index: forward.c
 ===
 RCS file: /usr/cvs/src/usr.bin/tail/forward.c,v
 retrieving revision 1.15
 diff -u -r1.15 forward.c
 --- forward.c   2000/07/18 19:38:38 1.15
 +++ forward.c   2000/09/02 16:16:40
 @@ -40,7 +40,8 @@
  static char sccsid[] = @(#)forward.c  8.1 (Berkeley) 6/6/93;
  #endif /* not lint */
 
 -#include sys/types.h
 +#include sys/param.h
 +#include sys/mount.h
  #include sys/stat.h
  #include sys/time.h
  #include sys/mman.h
 @@ -96,6 +97,7 @@
 int action = USE_SLEEP;
 struct kevent ev[2];
 struct stat sb2;
 +   struct statfs statfsbuf;
 
 switch(style) {
 case FBYTES:
 @@ -170,7 +172,10 @@
 break;
 }
 
 -   if (fflag) {
 +   if (statfs(fname, statfsbuf) != 0)
 +   err(1, statfs %s, fname);
 +
 +   if (fflag  strcmp(statfsbuf.f_fstypename, ufs) == 0) {
 kq = kqueue();
 if (kq  0)
 err(1, kqueue);
 --
 Ben Smithurst / [EMAIL PROTECTED] / PGP: 0x99392F7D
 FreeBSD Documentation Project /
 
 To Unsubscribe: send mail to [EMAIL PROTECTED]
 with unsubscribe freebsd-stable in the body of the message

-- 
I need someone really bad. Are you really bad?

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



Re: ** HEADS UP **: sys/miscfs file systems moved

2001-05-24 Thread Doug Barton

Warner Losh wrote:
 
 In message [EMAIL PROTECTED] Brian Somers writes:
 : It may also be worth mentioning that people should move /usr/include
 : to (say) /usr/include.not before their next installworld and nuke
 : /usr/include.not after it completes.
 
 Eh?  that's a bug in the installation proceedure then.

I just upgraded to the latest -current and didn't have to do this.

Doug

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



Re: Boot time memory issue

2001-05-24 Thread Valentin Nechayev

 Sun, May 20, 2001 at 19:53:29, barry (Barry Lustig) wrote about Boot time memory 
issue: 

Do verbose boot (`boot -v') with large SC_HISTORY_SIZE (1000 at least,
2000 at most), and after boot check for SMAP ... lines at the very
beginning of the kernel boot log at /dev/console. (They are not written
to log viewable with dmesg.) Another way is to use serial console.
With this SMAP lines one can say more concrete diagnosis.

 I was curious whether the memory limitation on the Sony VAIO Z505
 machines was an actual hardware limitation or a marketing issue.  I just
 tried adding a 256MB module to my machine.  The BIOS seemed to mostly
 recognize it.
 It did see 320MB of RAM, but had problems when testing all of it. 
 Current (from
 a couple of weeks ago) boots, but gives me:
   Too many holes in the physical address space, giving up
 
 and comes up showing 64MB of RAM.  Is this something that can be worked
 around, or have I run up against an actual hardware limit on the
 machine?


/netch

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