Re: panic: zone: entry in free

1999-07-14 Thread Dominic Mitchell

On Thu, Jul 15, 1999 at 12:08:07AM -0400, Luoqi Chen wrote:
> > I've been getting this panic when I've installed new kernels the last
> > couple of times.  The panic is occuring when I have freshly booted the
> > system with a new kernel and logged on for the first time.  It appears
> > to occur at the point at which I start fetchmail in my profile, FWIW.
> > 
> Get rid of INVARIANTS in your config file.

I realise that will stop the panic from looking at the source code, but
surely it's just covering up the problem and waiting for it to happen
later?
-- 
Dom Mitchell -- Palmer & Harvey McLane -- Unix Systems Administrator

In Mountain View did Larry Wall
Sedately launch a quiet plea:
That DOS, the ancient system, shall
On boxes pleasureless to all
Run Perl though lack they C.
-- 
**
This email and any files transmitted with it are confidential and 
intended solely for the use of the individual or entity to whom they   
are addressed. If you have received this email in error please notify 
the system manager.

This footnote also confirms that this email message has been swept by 
MIMEsweeper for the presence of computer viruses.
**


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



Re: panic: zone: entry in free

1999-07-14 Thread Luoqi Chen

> I've been getting this panic when I've installed new kernels the last
> couple of times.  The panic is occuring when I have freshly booted the
> system with a new kernel and logged on for the first time.  It appears
> to occur at the point at which I start fetchmail in my profile, FWIW.
> 
Get rid of INVARIANTS in your config file.

-lq


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



Re: Using float emulator on a system with FPU?

1999-07-14 Thread Peter Jeremy

Hi Warner,

>Without commenting on the need to have an emulator in the kernel,
>doesn't -msoft-float work faster?
Yes it does.  The kernel has to emulate an 80x87, giving you the
following sequence:
a) trap to kernel
b) decode FP instruction
c) fetch operands - possibly including copyin()
d) perform operation [this is the only bit the soft-FP code does]
e) store result - possibly including copyout()
f) return from trap

The trap/decode/copyin()/copyout()/rtt are all non-trivial.

>  Or is that a MIPS only thing...
It's documented under i386 as well.  There is a note that gcc can
still emit some hardware FP instructions (to return FP values on
the 80x87 stack), but this can be prevented with -mno-fp-ret-in-387

The disadvantage of soft-FP is that you wind up with lots of different
libc's - one for h/w FP, one for soft FP and maybe a few more for
different FP formats (eg FFP on M68K, or a `cut-a-few-corners-but-
give-almost-the-correct-answer-much-faster' IEEE, or single-precision
only IEEE).  This is less of a problem in an embedded system, where
the FP requirements (if needed at all) are well defined.  (The problem
is that using the wrong library generally doesn't show up until
run-time - when the results aren't what you expected).

Note that the GNU newlib defines `iprintf()' (and family) as an
integer-only printf() to avoid pulling in all the FP overhead when
it's not really needed.

Peter


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



Re: Using float emulator on a system with FPU?

1999-07-14 Thread Warner Losh

In message <[EMAIL PROTECTED]> Mike Smith writes:
: Lots (and I mean _lots_) of embedded systems use fpu-less 386 and 486 
: cores.  Alienating users of these systems would be a dumb idea.

Without commenting on the need to have an emulator in the kernel,
doesn't -msoft-float work faster?  Or is that a MIPS only thing...

Warner


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



panic: zone: entry in free

1999-07-14 Thread Dominic Mitchell

I've been getting this panic when I've installed new kernels the last
couple of times.  The panic is occuring when I have freshly booted the
system with a new kernel and logged on for the first time.  It appears
to occur at the point at which I start fetchmail in my profile, FWIW.

BTW: My home directory is mounted over nfsv3,udp from a Solaris2.6
server with amd.  I've tried getting rid of amd and it makes no
difference.

At the moment, I'm having to use a kernel from June 8th, to be able to
login...

Here's the traceback from ddb:

Debugger(0xc01d545b) at Debugger+0x37
panic(0xc01e5339, 0xc6aa6df4, 0xc0152af8, 0x1, 0) at panic+0x74
zerror(0x1, 0, 0xc6aa6f80, 0x, 0xc0f3b300) at zerror+0x3f
namei(0xc6aa6eec, 0, 0xc6aa6f80, 0x, 0xc6aa6e30) at namei+0xac
vn_open(0xc6aa6eec, 0x3, 0, 0xc6558680, 0xc01f572c) at vn_open+0x1eb
open(0xc6558680, 0xc6aa6f80, 0x, 0, 0x) at open+0xbb
syscall(0x2f, 0x2f, 0x2f, 0x, 0) at syscall+0x182
Xint0x80_syscall() at Xint0x80_syscall+0x26

Does this lot mean anything to anybody?

Unfortunately, I can't seem to get a crash dump out of the thing.  I've
tried doing both "panic" and "continue" from within ddb, and it looks as
though the dump is being written to disk, but when it comes back up,
nothing.

Here's the config file for the kernel that's crashing on me:


#
# VOODOO --- Dom's workstation.  A HP Vectra VL.
#
# $Id: VOODOO,v 1.22 1999/07/13 06:23:14 dom Exp $
#

machine "i386"
cpu "I686_CPU"
ident   VOODOO
maxusers32

# Build a debug kernel.
makeoptions DEBUG="-g"

options DDB # Kernel debugger.

options "COMPAT_43" #Compatible with BSD 4.3 [KEEP THIS!]
options "NO_F00F_HACK"
options FFS #Berkeley Fast Filesystem
options FFS_ROOT
options INET#InterNETworking
options INVARIANTS
options INVARIANT_SUPPORT
options KTRACE  #kernel tracing
options SOFTUPDATES
options SYSVMSG
options SYSVSEM
options SYSVSHM
options UCONSOLE#Allow users to grab the console
options USER_LDT#Wine.

controller  isa0at nexus?
controller  pci0at nexus?

controller  fdc0at isa? port "IO_FD1" irq 6 drq 2
diskfd0 at fdc0 drive 0

## controller   wdc0at isa? port "IO_WD1" irq 14
## disk wd0 at wdc0 drive 0 flags 0xa0ff
## controller   wdc1at isa? port "IO_WD2" irq 15
## device   wcd0#IDE CD-ROM

# Soren's new atapi stuff...
controller  ata0
device  atadisk0
device  atapicd0

# syscons is the default console driver, resembling an SCO console
controller  atkbdc0 at isa? port IO_KBD
device  atkbd0  at atkbdc? irq 1
device  psm0at atkbdc? irq 12
device  vga0at isa? port ? conflicts
device  sc0 at isa?

# Mandatory, don't remove
device  npx0at nexus? port IO_NPX irq 13

device  apm0at nexus? disable flags 0x31

device  sio0at isa? port "IO_COM1" flags 0x10 irq 4
device  sio1at isa? port "IO_COM2" irq 3

device xl0

# Parallel port bus.
controller  ppbus0
device  lpt0at ppbus?
device  plip0   at ppbus?
device  ppc0at isa? port? irq 7

pseudo-device   loop
pseudo-device   ether
pseudo-device   pty 32
pseudo-device   bpf 2
pseudo-device   snp 2   #Snoop on ttys
pseudo-device   splash


And here's the dmesg for the successful kernel that I'm running which is
pretty much the same but with a couple more filesystems compiled into it
instead of modules.  Please let me know if there's any more information
I can provide to help with tracking this down...


Copyright (c) 1992-1999 The FreeBSD Project.
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California. All rights reserved.
FreeBSD 4.0-CURRENT #18: Tue Jun  8 05:00:06 BST 1999
[EMAIL PROTECTED]:/usr/src/sys/compile/VOODOO
Timecounter "i8254"  frequency 1193182 Hz
CPU: Pentium II (299.61-MHz 686-class CPU)
  Origin = "GenuineIntel"  Id = 0x634  Stepping=4
  Features=0x80f9ff
real memory  = 67108864 (65536K bytes)
avail memory = 62611456 (61144K bytes)
Preloaded elf kernel "kernel.goodnfs" at 0xc028c000.
Preloaded elf module "if_tun.ko" at 0xc028c0a4.
Pentium Pro MTRR support enabled, default memory type is uncacheable
npx0:  on motherboard
npx0: INT 16 interface
pcib0:  on motherboard
pci0:  on pcib0
Correcting Natoma config for non-SMP
Correcting Natoma config for non-SMP
chip0:  at device 0.0 on pci0
isab0:  at device 4.0 on pci0
ata-pci0:  at device 4.1 on pci0