Re: Panic with NFSv3 on a CURRENT/SMP system

1999-08-22 Thread Greg Lehey

On Saturday, 21 August 1999 at 22:30:54 -0400, Luoqi Chen wrote:
 I'm generating a core dump. Please note that as tara is my test machine, I use
 "INVARIANT"  "INVARIANT_SUPPORT". Should I remove them ?

 It seems that from my reading of the code, the panic would not had happened
 without INVARIANT.

 It is these options that caused the panic, you either remove them from the
 kernel proper, or compile the kld with them.

In all likelihood, these options didn't "cause" the panic, they just
made another bug more visible.  That's what they're there for.

Greg
--
See complete headers for address, home page and phone numbers
finger [EMAIL PROTECTED] for PGP public key


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



Re: Panic with NFSv3 on a CURRENT/SMP system

1999-08-22 Thread Ollivier Robert

According to Greg Lehey:
 In all likelihood, these options didn't "cause" the panic, they just
 made another bug more visible.  That's what they're there for.

That's what I'm thinking but compiling NFS into the kernel "fixed" my
panic. The weird part is that I'm still using INVARIANT. I don't see why the
condition is not met when compiling all these together and is when using the
kld.
-- 
Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- [EMAIL PROTECTED]
FreeBSD keltia.freenix.fr 4.0-CURRENT #73: Sat Jul 31 15:36:05 CEST 1999



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



Re: Panic with NFSv3 on a CURRENT/SMP system

1999-08-22 Thread David Malone

On Sun, Aug 22, 1999 at 10:24:33PM +0200, Ollivier Robert wrote:
 That's what I'm thinking but compiling NFS into the kernel "fixed" my
 panic. The weird part is that I'm still using INVARIANT. I don't see why the
 condition is not met when compiling all these together and is when using the
 kld.

As I understand it, compiling the kernel with INVARIENTS makes it
uncompatable with modules compiled without INVARIENTS. The reason
is probably to do with inline functions and the like - I see some
inline functions in vm_zone.h which set and check certain variables
only when INVARIANTS is defined. The variables seem also to be set
and checked in vm_zone.c.

So I suppose if you use an inline function to initialise something
without INVARIENTS in a module, and then it is checked by the kernel
which did have INVARIENTS defined things go boom...

David.


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



Panic with NFSv3 on a CURRENT/SMP system

1999-08-21 Thread Ollivier Robert

Hello,

I just got a panic when trying to play with NFSv3. The system is a dual
PentiumPro system, running CURRENT/SMP. I use NFS as a kld.

The FS on keltia is exported as:

/z  -alldirs -maproot=0 tara

And mounted on tara with

keltia:/z   /spare  rw,nfsv30 0

I tried making a directory on tara: "mkdir foo" and it succeeded. The
directory has been created on keltia:

drwxr-xr-x  2 root wheel 512 Aug 21 21:49 foo

Now, as soon as I try to go into that directory, boom!

roberto@tara:/z# cd foo
panic: zone: entry not free
mp_lock = 0001; cpuid = 0; lapic.id = 
Debugger("panic")
Stopped atDebugger+0x37:movl$0,in_Debugger
db trace
panic(c021d779,c6235e38,c01b56c4,1,c5d15d60) at panic+0xa8
zerror(1,c5d15d60,c6235ec8,c0887b80,c6235e8c) at zerror+0x3f
zalloc(c0853980) at zalloc+0x54
namei(c6235ea4,c5d15d60,c0234a04,0,80ab220) at nami+0x77
stat(c5d15d60,c6235f80,80e0c90,80e0c60,bfbfd5dc) at stat+0x44
syscall(2f,2f,2f,bfbfd5dc,80e0c60) at syscall+0x16e
Xint0x80_syscall() at Xint0x80_syscall+0x31

Current process was zsh. I found in ps (from DDB) than c5d15d60 is the "proc"
value for this process. The machine was idle (running ntpd, Postfix).

db show registers
cs  0x8 gd_npxproc
ds   0xc6230010 
es   0x802x0010
fs   0xc0250018 db_break_table+0x638
ss 0x10 gd_switchtime
eax0x12 gd_switchtime+0x2
ecx 0x1
edx  0xc026b000 cpl_lock
ebx  0xc021d779 __set_sysuninit_set_sym_M_ZONE_uninit_sys_uninit+0x8d
esp  0xc6235df8
ebp  0xc6235e00
esi   0x100 gd_prv_PADDR1+0x40
edi   0
eip  0xc01d277f Debugger+0x37
efl   0x256

I'm generating a core dump. Please note that as tara is my test machine, I use 
"INVARIANT"  "INVARIANT_SUPPORT". Should I remove them ?

It seems that from my reading of the code, the panic would not had happened
without INVARIANT.

Here is the trace from kgdb:

SMP 2 cpus
IdlePTD 3354624
initial pcb at 253280
panicstr: from debugger
panic messages:
---
panic: zone: entry not free
mp_lock = 0001; cpuid = 0; lapic.id = 
panic: from debugger
mp_lock = 0002; cpuid = 0; lapic.id = 
boot() called on cpu#0
dumping to dev (13,196609), offset 131072
dump 64 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41
40 39 38 37 36 35 34 33 32 31 30 29 28 27 26 25 24 23 2
2 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1
---
#0  boot (howto=260) at ../../kern/kern_shutdown.c:291
291 dumppcb.pcb_cr3 = rcr3();
(kgdb) where
#0  boot (howto=260) at ../../kern/kern_shutdown.c:291
#1  0xc0147201 in panic (fmt=0xc0208df4 "from debugger")
at ../../kern/kern_shutdown.c:515
#2  0xc01271f5 in db_panic (addr=-1071831169, have_addr=0, count=-1,
modif=0xc6235cc4 "") at ../../ddb/db_command.c:433
#3  0xc0127194 in db_command (last_cmdp=0xc0232970, cmd_table=0xc02327d0,
aux_cmd_tablep=0xc024f904) at ../../ddb/db_command.c:333
#4  0xc012725a in db_command_loop () at ../../ddb/db_command.c:455
#5  0xc012929b in db_trap (type=3, code=0) at ../../ddb/db_trap.c:71
#6  0xc01d24ca in kdb_trap (type=3, code=0, regs=0xc6235db8)
at ../../i386/i386/db_interface.c:157
#7  0xc01e571c in trap (frame={tf_fs = -1071316968, tf_es = -2144600048,
  tf_ds = -970784752, tf_edi = 0, tf_esi = 256, tf_ebp = -970760704,
  tf_isp = -970760732, tf_ebx = -1071523975, tf_edx = -1071206400,
  tf_ecx = 1, tf_eax = 18, tf_trapno = 3, tf_err = 0,
  tf_eip = -1071831169, tf_cs = 8, tf_eflags = 598, tf_esp = -1071499293,
  tf_ss = -10715891}) at ../../i386/i386/trap.c:534
#8  0xc01d277f in Debugger (msg=0xc020d8d2 "panic") at machine/cpufunc.h:64
#9  0xc01471f8 in panic (fmt=0xc021d779 "zone: entry not free")
at ../../kern/kern_shutdown.c:513
#10 0xc01b5a9f in zerror () at ../../vm/vm_zone.c:455
#11 0xc01b56c4 in zalloci (z=0xc0853980) at ../../vm/vm_zone.h:91
#12 0xc016af87 in namei (ndp=0xc6235ea4) at ../../vm/vm_zone.h:117
#13 0xc0171338 in stat (p=0xc5d15d60, uap=0xc6235f80)
at ../../kern/vfs_syscalls.c:1668
#14 0xc01e5f9a in syscall (frame={tf_fs = 47, tf_es = 47, tf_ds = 47,
  tf_edi = -1077946916, tf_esi = 135138400, tf_ebp = -1077946800,
  tf_isp = -970760236, tf_ebx = 135138448, tf_edx = 135138400,
  tf_ecx = 135138304, tf_eax = 188, tf_trapno = 12, tf_err = 2,
  tf_eip = 672140844, tf_cs = 31, tf_eflags = 582, tf_esp = -1077948072,
  tf_ss = 47}) at ../../i386/i386/trap.c:1056
#15 0xc01d2eb1 in Xint0x80_syscall ()
#16 0x804ba24 in ?? ()
#17 0x804b786 in ?? ()
#18 0x804b672 in ?? ()
#19 0x804b2e4 in ?? ()
#20 0x804aa4b in ?? ()
#21 0x80552be in ?? ()
#22 0x8053494 in ?? ()
#23 0x8052df3 in ?? ()
#24 0x8052a82 in ?? ()
#25 0x805f851 in ?? ()
#26 0x804a32b in ?? ()
#27 0x804a125 in ?? ()

If needed I can explore more variables.

Client (tara) is a 2x PPro/200, Intel PFX440 motherboard, 64 MB RAM. I SCSI
disk on the on-board SCSI controller 

Re: Panic with NFSv3 on a CURRENT/SMP system

1999-08-21 Thread Matthew Dillon

:Hello,
:
:I just got a panic when trying to play with NFSv3. The system is a dual
:PentiumPro system, running CURRENT/SMP. I use NFS as a kld.

The very first thing I would do is compile NFS into the kernel and not
use it as a kld.  Then see if you can repeat the problem.

-Matt


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



Re: Panic with NFSv3 on a CURRENT/SMP system

1999-08-21 Thread Luoqi Chen

 I'm generating a core dump. Please note that as tara is my test machine, I use 
 "INVARIANT"  "INVARIANT_SUPPORT". Should I remove them ?
 
 It seems that from my reading of the code, the panic would not had happened
 without INVARIANT.
 
It is these options that caused the panic, you either remove them from the
kernel proper, or compile the kld with them.

-lq


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