Re: Preposterous errno values from kernel

2005-04-24 Thread Robert Backhaus 
On 4/23/05, Kris Kennaway [EMAIL PROTECTED] wrote:
 On Sat, Apr 23, 2005 at 06:34:39AM +1000, Peter Jeremy wrote:
  On Thu, 2005-Apr-21 22:04:01 -0700, Kris Kennaway wrote:
  I'm getting this on a RELENG_5_4 sparc64 system (e4500):
  
  # rm -rf *
  /bin/rm: Unknown error: 7283.
 

Just to rule things out: try
echo *

Just to make sure the shell is returning something sane.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: Preposterous errno values from kernel

2005-04-22 Thread Peter Jeremy 
On Thu, 2005-Apr-21 22:04:01 -0700, Kris Kennaway wrote:
I'm getting this on a RELENG_5_4 sparc64 system (e4500):

# rm -rf *
/bin/rm: Unknown error: 7283.

Cute.  Does it affect anything other than /bin/rm?  Is /bin/rm sane
(not some random junk that's confusing the ELF loader)?  Is this an
SMP system (which might point to locking problems)?

If this seems consistent (other than the actual errno reported), the
quickest solution would seem to be to use DDB (or kernel GDB) to
follow the execution path from execve() until it goes off the rails.

-- 
Peter Jeremy
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: Preposterous errno values from kernel

2005-04-22 Thread Kris Kennaway 
On Sat, Apr 23, 2005 at 06:34:39AM +1000, Peter Jeremy wrote:
 On Thu, 2005-Apr-21 22:04:01 -0700, Kris Kennaway wrote:
 I'm getting this on a RELENG_5_4 sparc64 system (e4500):
 
 # rm -rf *
 /bin/rm: Unknown error: 7283.
 
 Cute.  Does it affect anything other than /bin/rm?  Is /bin/rm sane
 (not some random junk that's confusing the ELF loader)?  Is this an
 SMP system (which might point to locking problems)?

I think I'm only seeing it in relation to rm, but I've done a make
world with a clean tree and had it persist.  rm seems to work in other
situations (including some other errors).  It is an SMP machine
(highly SMP; 12-CPU).

 If this seems consistent (other than the actual errno reported), the
 quickest solution would seem to be to use DDB (or kernel GDB) to
 follow the execution path from execve() until it goes off the rails.

I might have to try that.

Kris



pgpqC4Y2WHQmr.pgp
Description: PGP signature