Re: repeated ufs_dirbad() panics on 4.0-c
On Thu, Mar 18, 1999 at 06:36:09PM -0800, Matthew Dillon wrote: # :On Thu, Mar 18, 1999 at 12:28:35PM +0300, Mikhail A. Sokolov wrote: # :# Hello, # :# panic: ffs_valloc: dup alloc # : # :And a brand new one (for today): # : # :IdlePTD 2682880 # :initial pcb at 21c7b8 # :panicstr: ffs_blkfree: freeing free frag # :panic messages: # :--- # :panic: ffs_blkfree: freeing free frag # I'm running out of ideas. Ok, three more things: Well, me too.. # First, when you updated your /usr/src/sys tree from cvs, did you also # update /usr/src/contrib/sys? aka softupdates? Yes, I'm running cvsupd server myself and stuff ;) # Second, Make sure you are using softlinks for the softupdates files in # /usr/src/sys/ufs/ffs/, pointing to their actual location in contrib, # rather then a copies of the files. Of course # Third, Try turning off reallocblks: # sysctl -w vfs.ffs.doreallocblks=0 That's been in use since decided somewhere in November, 1998 on ~90% of machines. -- -mishania To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
RE: repeated ufs_dirbad() panics on 4.0-c
-Original Message- From: Ollivier Robert [SMTP:robe...@keltia.freenix.fr] Sent: Thursday, March 18, 1999 12:26 AM To: curr...@freebsd.org Subject: Re: repeated ufs_dirbad() panics on 4.0-c According to Mikhail A. Sokolov: nope /dev/da1e17235735 7414244 844263347%/mnt/arc /dev/da2e 8617355 1724705 689265020% /mnt/spool1 /dev/da3e 8617355 1723638 689371720% /mnt/spool2 disklabel output is what you want to send us, df is not enough :-) [ML] In his case it is, because if you take a very careful look, you will see that he's using the e compatibility partition on three separate disks :) So, it's probably not overlapping, but the compatibility that may cause problems. /Marino To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: repeated ufs_dirbad() panics on 4.0-c
On Thu, Mar 18, 1999 at 12:25:57AM +0100, Ollivier Robert wrote: # According to Mikhail A. Sokolov: # nope # # /dev/da1e17235735 7414244 844263347%/mnt/arc # /dev/da2e 8617355 1724705 689265020%/mnt/spool1 # /dev/da3e 8617355 1723638 689371720%/mnt/spool2 # # disklabel output is what you want to send us, df is not enough :-) We already checked with Greg and Matthew it is neat and ok, disklabel and such. (what did you expect? ;) # Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- robe...@keltia.freenix.fr -- -mishania To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: repeated ufs_dirbad() panics on 4.0-c
Hello,
new 6 panics of such during the night. I'm gonna reproduce the machine
configuration without it using the IFT or any other but this precise IFT in
general today. The below mentioned are identical.
(Did I mention the rc knows about forced fsck -y only, no fsck -p or something?)
gdb -k kernel.3 vmcore.3
panicstr: ffs_valloc: dup alloc
panic messages:
---
panic: ffs_valloc: dup alloc
syncing disks... 147 75 2 done
(da1:ahc1:0:1:0): SYNCHRONIZE CACHE. CDB: 35 0 0 0 0 0 0 0 0 0
(da1:ahc1:0:1:0): ILLEGAL REQUEST asc:20,0
(da1:ahc1:0:1:0): Invalid command operation code
(da2:ahc1:0:2:0): SYNCHRONIZE CACHE. CDB: 35 0 0 0 0 0 0 0 0 0
(da2:ahc1:0:2:0): ILLEGAL REQUEST asc:20,0
(da2:ahc1:0:2:0): Invalid command operation code
(da3:ahc1:0:3:0): SYNCHRONIZE CACHE. CDB: 35 0 0 0 0 0 0 0 0 0
(da3:ahc1:0:3:0): ILLEGAL REQUEST asc:20,0
(da3:ahc1:0:3:0): Invalid command operation code
dumping to dev 20401, offset 821524
dump 256..
---
#0 boot (howto=256) at ../../kern/kern_shutdown.c:287
287 dumppcb.pcb_cr3 = rcr3();
(kgdb) where
#0 boot (howto=256) at ../../kern/kern_shutdown.c:287
#1 0xc013b4b9 in panic (fmt=0xc01fdf01 ffs_valloc: dup alloc)
at ../../kern/kern_shutdown.c:448
#2 0xc01b4e84 in ffs_valloc (pvp=0xce418ac0, mode=33188, cred=0xc1fab580,
vpp=0xce264cd0) at ../../ufs/ffs/ffs_alloc.c:604
#3 0xc01c21cd in ufs_makeinode (mode=33188, dvp=0xce418ac0, vpp=0xce264f14,
cnp=0xce264f28) at ../../ufs/ufs/ufs_vnops.c:2097
#4 0xc01bf9de in ufs_create (ap=0xce264e30) at ../../ufs/ufs/ufs_vnops.c:179
#5 0xc01c23a1 in ufs_vnoperate (ap=0xce264e30)
at ../../ufs/ufs/ufs_vnops.c:2309
#6 0xc01631c7 in vn_open (ndp=0xce264f04, fmode=1550, cmode=420)
at vnode_if.h:83
#7 0xc015fee9 in open (p=0xcce8b860, uap=0xce264f94)
at ../../kern/vfs_syscalls.c:928
#8 0xc01e769f in syscall (frame={tf_es = 47, tf_ds = -1078067153,
tf_edi = 1549, tf_esi = 247619088, tf_ebp = -1078010952,
tf_isp = -836349980, tf_ebx = 134788528, tf_edx = 219774816, tf_ecx = 0,
tf_eax = 5, tf_trapno = 22, tf_err = 2, tf_eip = 672227132, tf_cs = 31,
tf_eflags = 534, tf_esp = -1078010980, tf_ss = 47})
at ../../i386/i386/trap.c:1101
#9 0xc01de9fc in Xint0x80_syscall ()
#10 0x808ae54 in ?? ()
#11 0x808b3c2 in ?? ()
#12 0x8084c1f in ?? ()
#13 0x8067e87 in ?? ()
#14 0x805c06a in ?? ()
#15 0x8071f7f in ?? ()
#16 0x804a1b1 in ?? ()
--
-mishania
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: repeated ufs_dirbad() panics on 4.0-c
On Thu, Mar 18, 1999 at 12:28:35PM +0300, Mikhail A. Sokolov wrote:
# Hello,
# panic: ffs_valloc: dup alloc
And a brand new one (for today):
IdlePTD 2682880
initial pcb at 21c7b8
panicstr: ffs_blkfree: freeing free frag
panic messages:
---
panic: ffs_blkfree: freeing free frag
#0 boot (howto=256) at ../../kern/kern_shutdown.c:287
287 dumppcb.pcb_cr3 = rcr3();
(kgdb) where
#0 boot (howto=256) at ../../kern/kern_shutdown.c:287
#1 0xc013b4b9 in panic (fmt=0xc01fe159 ffs_blkfree: freeing free frag)
at ../../kern/kern_shutdown.c:448
#2 0xc01b6760 in ffs_blkfree (ip=0xc1fa6500, bno=3066, size=3072)
at ../../ufs/ffs/ffs_alloc.c:1352
#3 0xc01b877f in ffs_truncate (vp=0xce571ac0, length=0x,
flags=0, cred=0x0, p=0xcce8b2e0) at ../../ufs/ffs/ffs_inode.c:341
#4 0xc01bd1f6 in ufs_inactive (ap=0xce27cedc) at ../../ufs/ufs/ufs_inode.c:84
#5 0xc01c23a1 in ufs_vnoperate (ap=0xce27cedc)
at ../../ufs/ufs/ufs_vnops.c:2309
#6 0xc015d91e in vput (vp=0xce571ac0) at vnode_if.h:767
#7 0xc0160c4d in unlink (p=0xcce8b2e0, uap=0xce27cf94)
at ../../kern/vfs_syscalls.c:1333
#8 0xc01e769f in syscall (frame={tf_es = 47, tf_ds = 47,
tf_edi = -1077944836, tf_esi = -1077944828, tf_ebp = -1077944880,
tf_isp = -836251676, tf_ebx = -1077945904, tf_edx = -1077945871,
tf_ecx = 10, tf_eax = 10, tf_trapno = 7, tf_err = 2, tf_eip = 671698620,
tf_cs = 31, tf_eflags = 642, tf_esp = -1077945916, tf_ss = 47})
at ../../i386/i386/trap.c:1101
#9 0xc01de9fc in Xint0x80_syscall ()
#10 0x804846d in ?? ()
(kgdb)
--
-mishania
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: repeated ufs_dirbad() panics on 4.0-c
:On Thu, Mar 18, 1999 at 12:28:35PM +0300, Mikhail A. Sokolov wrote: :# Hello, :# panic: ffs_valloc: dup alloc : :And a brand new one (for today): : :IdlePTD 2682880 :initial pcb at 21c7b8 :panicstr: ffs_blkfree: freeing free frag :panic messages: :--- :panic: ffs_blkfree: freeing free frag I'm running out of ideas. Ok, three more things: First, when you updated your /usr/src/sys tree from cvs, did you also update /usr/src/contrib/sys? aka softupdates? Second, Make sure you are using softlinks for the softupdates files in /usr/src/sys/ufs/ffs/, pointing to their actual location in contrib, rather then a copies of the files. Third, Try turning off reallocblks: sysctl -w vfs.ffs.doreallocblks=0 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: repeated ufs_dirbad() panics on 4.0-c
# Are you *sure* you're running -current as of today? Justin put code in to # silence Illegal request error messages from the sync cache command. These messages, since they are occurring only during a panic, are caused by the code in dashutdown(). I didn't modify this code in my last checkin, but cannot see why it would not properly prevent the messages from being displayed. Perhaps Mikhail would be willing to instrument the code and determine why it doesn't work properly? -- Justin To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: repeated ufs_dirbad() panics on 4.0-c
On Wed, Mar 17, 1999 at 12:51:12PM +1030, Greg Lehey wrote: # On Tuesday, 16 March 1999 at 22:36:38 +0300, Mikhail A. Sokolov wrote: # Hello, # # we're experiencing repeated 4.0-C (as of today, something around 12:00 # GMT, 1999-03-16) ufs_dirbad() panics, which are the # following (below), which usually occur when squid is running. The box # doesn't have ccd, nor vinum nor anything fancy in it's config, no SMP either. # Squid's spool is hardware (IFT3102) RAID1, 2x9gb (i.e. 4 disks): # /var/crash# gdb -k kernel.1 vmcore.1 # IdlePTD 2682880 # initial pcb at 21c7b8 # panicstr: ufs_dirbad: bad dir # panic messages: # --- # panic: ufs_dirbad: bad dir # # Have you looked at the directory? Theoretically this could be a # really mangled directory structure. Yes, of course. Those swap catalogues which are not to be touched by squid are turned into it's swapfiles, sometimes there's an error of 'bad file descriptor' and such. As I said in reply to Julian, I've newfs'ed these spools plenty times, - errors are repeated and, besides, lookalike. That's a glitch in FFS somewhere, I assume: I've had similiar panics on another squid with exactly the very same hardware/software configuration, besides the fact the OS there was 3.[01]-S. Similiar panics, different scsi disks, tryed not to use the mentioned IFT RAID - no difference. I.e. I could've agreed with that this could be really doomed directory, but no, it's not that way, squid's allocating objects in memory, when it reaches the limit it'd swap it to the spool (as per LRU and such rules) and then, after it dies, I find that ~1 recursive swap file (2 disksx9gb, 256 catalogues of 16 subdirs each in 8 and 6 cache_dirs as applicable to two spools) in each of the subdirs (second level cache) has died, - has been automagically converted to contain some crap [by FFS?]. What could help is that squid is configured to use poll(), doesn't use threads, doesn't do async (i.e. as squid undestands it, it's an option there) operations. Mounts on the FS's are noatime, but that ain't is the culprit, ain't they? # Greg # -- # See complete headers for address, home page and phone numbers # finger g...@lemis.com for PGP public key -- -mishania To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: repeated ufs_dirbad() panics on 4.0-c
: :I.e. I could've agreed with that this could be really doomed directory, but no, :it's not that way, squid's allocating objects in memory, when it reaches the :limit it'd swap it to the spool (as per LRU and such rules) and then, after :it dies, I find that ~1 recursive swap file (2 disksx9gb, 256 catalogues of :16 subdirs each in 8 and 6 cache_dirs as applicable to two spools) in each :of the subdirs (second level cache) has died, - has been automagically converted :to contain some crap [by FFS?]. : :What could help is that squid is configured to use poll(), doesn't use threads, :doesn't do async (i.e. as squid undestands it, it's an option there) operations. :Mounts on the FS's are noatime, but that ain't is the culprit, ain't they? : :-- :-mishania It kinda sounds like you have two overlapping partitions. -Matt Matthew Dillon dil...@backplane.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: repeated ufs_dirbad() panics on 4.0-c
nope /dev/da1e 17235735 7414244 844263347%/mnt/arc /dev/da2e 8617355 1724705 689265020%/mnt/spool1 /dev/da3e 8617355 1723638 689371720%/mnt/spool2 On Wed, Mar 17, 1999 at 08:29:54AM -0800, Matthew Dillon wrote: # : # :What could help is that squid is configured to use poll(), doesn't use threads, # :doesn't do async (i.e. as squid undestands it, it's an option there) operations. # :Mounts on the FS's are noatime, but that ain't is the culprit, ain't they? # : # :-- # :-mishania # # It kinda sounds like you have two overlapping partitions. # # -Matt # Matthew Dillon # dil...@backplane.com -- -mishania To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: repeated ufs_dirbad() panics on 4.0-c
According to Mikhail A. Sokolov: nope /dev/da1e17235735 7414244 844263347%/mnt/arc /dev/da2e 8617355 1724705 689265020%/mnt/spool1 /dev/da3e 8617355 1723638 689371720%/mnt/spool2 disklabel output is what you want to send us, df is not enough :-) -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- robe...@keltia.freenix.fr FreeBSD keltia.freenix.fr 4.0-CURRENT #70: Sat Feb 27 09:43:08 CET 1999 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: repeated ufs_dirbad() panics on 4.0-c
Mikhail A. Sokolov wrote... Hello, we're experiencing repeated 4.0-C (as of today, something around 12:00 GMT, 1999-03-16) ufs_dirbad() panics, which are the following (below), which usually occur when squid is running. The box doesn't have ccd, nor vinum nor anything fancy in it's config, no SMP either. Squid's spool is hardware (IFT3102) RAID1, 2x9gb (i.e. 4 disks): /var/crash# gdb -k kernel.1 vmcore.1 IdlePTD 2682880 initial pcb at 21c7b8 panicstr: ufs_dirbad: bad dir panic messages: --- panic: ufs_dirbad: bad dir I have no idea why you're getting a panic, but I do have a question... syncing disks... 134 63 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 giving up (da1:ahc1:0:1:0): SYNCHRONIZE CACHE. CDB: 35 0 0 0 0 0 0 0 0 0 (da1:ahc1:0:1:0): ILLEGAL REQUEST asc:20,0 (da1:ahc1:0:1:0): Invalid command operation code (da2:ahc1:0:2:0): SYNCHRONIZE CACHE. CDB: 35 0 0 0 0 0 0 0 0 0 (da2:ahc1:0:2:0): ILLEGAL REQUEST asc:20,0 (da2:ahc1:0:2:0): Invalid command operation code (da3:ahc1:0:3:0): SYNCHRONIZE CACHE. CDB: 35 0 0 0 0 0 0 0 0 0 (da3:ahc1:0:3:0): ILLEGAL REQUEST asc:20,0 (da3:ahc1:0:3:0): Invalid command operation code Are you *sure* you're running -current as of today? Justin put code in to silence Illegal request error messages from the sync cache command. What revision of scsi_da.c do you have, and has it been modified? Ken -- Kenneth Merry k...@plutotech.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: repeated ufs_dirbad() panics on 4.0-c
On Tue, Mar 16, 1999 at 01:14:52PM -0700, Kenneth D. Merry wrote: # Mikhail A. Sokolov wrote... # Hello, # # I have no idea why you're getting a panic, but I do have a question... # # syncing disks... 134 63 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 giving up # (da1:ahc1:0:1:0): SYNCHRONIZE CACHE. CDB: 35 0 0 0 0 0 0 0 0 0 # (da1:ahc1:0:1:0): ILLEGAL REQUEST asc:20,0 # (da1:ahc1:0:1:0): Invalid command operation code # (da2:ahc1:0:2:0): SYNCHRONIZE CACHE. CDB: 35 0 0 0 0 0 0 0 0 0 # (da2:ahc1:0:2:0): ILLEGAL REQUEST asc:20,0 # (da2:ahc1:0:2:0): Invalid command operation code # (da3:ahc1:0:3:0): SYNCHRONIZE CACHE. CDB: 35 0 0 0 0 0 0 0 0 0 # (da3:ahc1:0:3:0): ILLEGAL REQUEST asc:20,0 # (da3:ahc1:0:3:0): Invalid command operation code # # Are you *sure* you're running -current as of today? Justin put code in to # silence Illegal request error messages from the sync cache command. # # What revision of scsi_da.c do you have, and has it been modified? * $Id: scsi_da.c,v 1.21 1999/03/05 23:20:20 gibbs Exp $ No, it haven't been modified, yes, I know IFT shouldn't shutup about this. Strange, but it is 4.0c as of today as described, and, to add misterious details, not all panics the box experiences are followed by such messages of sync cache. # # Ken # -- # Kenneth Merry # k...@plutotech.com -- -mishania To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: repeated ufs_dirbad() panics on 4.0-c
On Tue, Mar 16, 1999 at 11:26:33PM +0300, Mikhail A. Sokolov wrote: # # Are you *sure* you're running -current as of today? Justin put code in to # # silence Illegal request error messages from the sync cache command. # # # # What revision of scsi_da.c do you have, and has it been modified? # # * $Id: scsi_da.c,v 1.21 1999/03/05 23:20:20 gibbs Exp $ # # No, it haven't been modified, yes, I know IFT shouldn't shutup about this. Sigh, what a day. Should be silent # # Kenneth Merry -- -mishania To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: repeated ufs_dirbad() panics on 4.0-c
Mikhail A. Sokolov wrote... On Tue, Mar 16, 1999 at 01:14:52PM -0700, Kenneth D. Merry wrote: # Mikhail A. Sokolov wrote... # Hello, # # I have no idea why you're getting a panic, but I do have a question... # # syncing disks... 134 63 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 giving up # (da1:ahc1:0:1:0): SYNCHRONIZE CACHE. CDB: 35 0 0 0 0 0 0 0 0 0 # (da1:ahc1:0:1:0): ILLEGAL REQUEST asc:20,0 # (da1:ahc1:0:1:0): Invalid command operation code # (da2:ahc1:0:2:0): SYNCHRONIZE CACHE. CDB: 35 0 0 0 0 0 0 0 0 0 # (da2:ahc1:0:2:0): ILLEGAL REQUEST asc:20,0 # (da2:ahc1:0:2:0): Invalid command operation code # (da3:ahc1:0:3:0): SYNCHRONIZE CACHE. CDB: 35 0 0 0 0 0 0 0 0 0 # (da3:ahc1:0:3:0): ILLEGAL REQUEST asc:20,0 # (da3:ahc1:0:3:0): Invalid command operation code # # Are you *sure* you're running -current as of today? Justin put code in to # silence Illegal request error messages from the sync cache command. # # What revision of scsi_da.c do you have, and has it been modified? * $Id: scsi_da.c,v 1.21 1999/03/05 23:20:20 gibbs Exp $ No, it haven't been modified, yes, I know IFT shouldn't shutup about this. Strange, but it is 4.0c as of today as described, and, to add misterious details, not all panics the box experiences are followed by such messages of sync cache. Well, that's what I wanted to know. You're using the latest version of scsi_da.c, so I suppose I'll leave it up to Justin to figure out why you're seeing those error messages. (since he wrote the code) Don't worry, those messages are generally harmless. Ken -- Kenneth Merry k...@plutotech.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: repeated ufs_dirbad() panics on 4.0-c
Mikhail A. Sokolov wrote: Hello, we're experiencing repeated 4.0-C (as of today, something around 12:00 GMT, 1999-03-16) ufs_dirbad() panics, which are the following (below), which usually occur when squid is running. The box doesn't have ccd, nor vinum nor anything fancy in it's config, no SMP either. soft updates? To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: repeated ufs_dirbad() panics on 4.0-c
nope, gone one month ago, FS's rebuilt since then On Tue, Mar 16, 1999 at 02:16:59PM -0800, Julian Elischer wrote: # Mikhail A. Sokolov wrote: # # Hello, # # we're experiencing repeated 4.0-C (as of today, something around 12:00 # GMT, 1999-03-16) ufs_dirbad() panics, which are the # following (below), which usually occur when squid is running. The box # doesn't have ccd, nor vinum nor anything fancy in it's config, no SMP either. # # # soft updates? -- -mishania To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: repeated ufs_dirbad() panics on 4.0-c
On Tuesday, 16 March 1999 at 22:36:38 +0300, Mikhail A. Sokolov wrote: Hello, we're experiencing repeated 4.0-C (as of today, something around 12:00 GMT, 1999-03-16) ufs_dirbad() panics, which are the following (below), which usually occur when squid is running. The box doesn't have ccd, nor vinum nor anything fancy in it's config, no SMP either. Squid's spool is hardware (IFT3102) RAID1, 2x9gb (i.e. 4 disks): /var/crash# gdb -k kernel.1 vmcore.1 IdlePTD 2682880 initial pcb at 21c7b8 panicstr: ufs_dirbad: bad dir panic messages: --- panic: ufs_dirbad: bad dir Have you looked at the directory? Theoretically this could be a really mangled directory structure. Greg -- See complete headers for address, home page and phone numbers finger g...@lemis.com for PGP public key To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
