Re: A couple questions regarding pcmcia cards....
And what about 3cxem556b? When somebody already asked some time ago, I looked through archives to no avail of information. It worked splendid on 2.2.7-pao ;) OpenBSD 2.6, which I have to use now isn't a solution due to it being OpenBSD. On Wed, Jan 05, 2000 at 12:03:15AM -0700, Warner Losh wrote: # In message [EMAIL PROTECTED] Frank Mayhar writes: #: Wups, I thought I read 575BT. But no, the 574BT doesn't work either; there's # : a bug somewhere in the driver. I have one of _those_, too, having read the # : same thing you did. # # Last I heard, Matt Dodd had or was waiting for a 574BT and pccard # enviornment to fix the driver. # # I have a 3CCFE575CT sitting here on my desk right now as a gentile # reminder to work on pccard/cardbus stuff :-). # # Warner -- -mishania To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: How To Burn CDs
On Fri, Aug 20, 1999 at 01:04:47PM +0200, Werner Griessl wrote: # # Don't forget cdrdao, it's able to read and burn "video(cdi)"-cd's. # Successfully done here with a philips cdr2600 burner for a philips cdi player. # It's also in ports. From what I recall, tosha's been able to deal with vcd's as well, it's just they usually start from track 2. # Werner -- -mishania To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: screen panics -current
On Sat, May 15, 1999 at 11:55:42AM +, George Cox wrote: # Well, this is just a quick note to anyone more knowledgable than me. # # screen 3.7.6 panics a current kernel. to add a little bit: when the kernel has SMP enabled. at least here, checked 3 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
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
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 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 ffs_blkfreepan...@demos.su, 4.0-C
On Wed, Mar 17, 1999 at 12:54:40PM +1030, Greg Lehey wrote:
# On Tuesday, 16 March 1999 at 22:41:22 +0300, Mikhail A. Sokolov wrote:
# Hello,
# the box is the same as in previous mail of mine which described ufs_dirbad()
# panics on 4.0-C. Panics are reproducable (run squid 2.1-pl2 with some
# 30 requests/second).
#
# These two crashes both tend to suggest a file system structure problem
# which fsck doesn't detect. What's the vp in the ffs_truncate frame?
Couldn't help agreeing more ;) See previous answer, though.
# How does it compare to the *vpp in the ufs_lookup frame of the
# previous dump?
Unfortunately, at the moment I have to admit I have been able to afford
keeping the dumps, let's wait the next time. Then again, whilst I am typing
this (below). I tend to be somewhat amazed that the frame 8 is usually the
same for many different panics this box experiences (little summary: this is
probably to be named the most panicing FreeBSD box in the world, 140 panics in
a month, all the hardware has been swapped to the same, but new (i.e. reproduced
the same configuration from spare new parts), panics were either already
announced by other peple, like, Matthew Jacob's reports, or fixed after
many other different reports, like, Matthew Dillon's work brought much more
stability to the beast, no more 'lockmgr: locking against myself' and
'vm_page*' of many kinds. Then again, this box is an experimental and was
brought to 4.0-C to check if it could survive with it, since it couldn't when
it was 3.1-S)
var/crash# gdb -k *3
initial pcb at 21c7b8
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
Btw, Kenneth, I know this is harmless, but didn't Justing's (Gibbs) explicitely
forbid the sync cache to be so verbose or I confuse wanted with the done
things?;)
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 ?? ()
(kgdb)
#
# 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
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
repeated ufs_dirbad() panics on 4.0-c
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
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
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=0xc01fe80f ufs_dirbad: bad dir)
at ../../kern/kern_shutdown.c:448
#2 0xc01bdd1a in ufs_dirbad (ip=0xc20b0800, offset=0,
how=0xc01fe7c9 mangled entry) at ../../ufs/ufs/ufs_lookup.c:566
#3 0xc01bd5be in ufs_lookup (ap=0xce271d40) at ../../ufs/ufs/ufs_lookup.c:243
#4 0xc01c23a1 in ufs_vnoperate (ap=0xce271d40)
at ../../ufs/ufs/ufs_vnops.c:2309
#5 0xc015999c in vfs_cache_lookup (ap=0xce271d9c) at vnode_if.h:55
#6 0xc01c23a1 in ufs_vnoperate (ap=0xce271d9c)
at ../../ufs/ufs/ufs_vnops.c:2309
#7 0xc015bdc1 in lookup (ndp=0xce271f04) at vnode_if.h:31
#8 0xc015b894 in namei (ndp=0xce271f04) at ../../kern/vfs_lookup.c:152
#9 0xc01632a2 in vn_open (ndp=0xce271f04, fmode=5, cmode=420)
at ../../kern/vfs_vnops.c:125
#10 0xc015fee9 in open (p=0xcce8b5a0, uap=0xce271f94)
at ../../kern/vfs_syscalls.c:928
#11 0xc01e769f in syscall (frame={tf_es = 47, tf_ds = -1078067153, tf_edi = 4,
tf_esi = 226253296, tf_ebp = -1078019504, tf_isp = -836296732,
tf_ebx = 134785100, tf_edx = 228027232, tf_ecx = 0, tf_eax = 5,
tf_trapno = 0, tf_err = 2, tf_eip = 672227132, tf_cs = 31,
tf_eflags = 534, tf_esp = -1078019532, tf_ss = 47})
at ../../i386/i386/trap.c:1101
---Type return to continue, or q return to quit---
#12 0xc01de9fc in Xint0x80_syscall ()
#13 0x808a844 in ?? ()
#14 0x808a795 in ?? ()
#15 0x80867f6 in ?? ()
#16 0x8086584 in ?? ()
#17 0x80585b0 in ?? ()
#18 0x80556a7 in ?? ()
#19 0x807a6c1 in ?? ()
#20 0x80553d3 in ?? ()
#21 0x804d229 in ?? ()
#22 0x804d163 in ?? ()
#23 0x804d3f5 in ?? ()
#24 0x8055207 in ?? ()
#25 0x8059824 in ?? ()
#26 0x805c06a in ?? ()
#27 0x8071f7f in ?? ()
#28 0x804a1b1 in ?? ()
(kgdb)
Thanks for comments,
--
-mishania
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
repeated ffs_blkfreepan...@demos.su, 4.0-C
Hello,
the box is the same as in previous mail of mine which described ufs_dirbad()
panics on 4.0-C. Panics are reproducable (run squid 2.1-pl2 with some
30 requests/second).
/var/crash# gdb -k kernel.2 vmcore.2
panicstr: ffs_blkfree: freeing free frag
panic messages:
---
panic: ffs_blkfree: freeing free frag
syncing disks... 107 52 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
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=0xc01fe159 ffs_blkfree: freeing free frag)
at ../../kern/kern_shutdown.c:448
#2 0xc01b6760 in ffs_blkfree (ip=0xc2050f00, bno=4888, size=7168)
at ../../ufs/ffs/ffs_alloc.c:1352
#3 0xc01b877f in ffs_truncate (vp=0xce247b40, length=0x,
flags=0, cred=0xc1f9c780, p=0xcce8b860) at ../../ufs/ffs/ffs_inode.c:341
#4 0xc01bff2d in ufs_setattr (ap=0xce264e30) at ../../ufs/ufs/ufs_vnops.c:499
#5 0xc01c23a1 in ufs_vnoperate (ap=0xce264e30)
at ../../ufs/ufs/ufs_vnops.c:2309
#6 0xc0163451 in vn_open (ndp=0xce264f04, fmode=1038, cmode=420)
at vnode_if.h:275
#7 0xc015fee9 in open (p=0xcce8b860, uap=0xce264f94)
at ../../kern/vfs_syscalls.c:928
#8 0xc01e769f in syscall (frame={tf_es = 47, tf_ds = -1078001617,
tf_edi = 1549, tf_esi = 191218144, tf_ebp = -107806,
tf_isp = -836349980, tf_ebx = 134788528, tf_edx = 191218128, tf_ecx = 0,
tf_eax = 5, tf_trapno = 22, tf_err = 2, tf_eip = 672227132, tf_cs = 31,
tf_eflags = 534, tf_esp = -1078011144, tf_ss = 47})
at ../../i386/i386/trap.c:1101
#9 0xc01de9fc in Xint0x80_syscall ()
#10 0x808ae54 in ?? ()
#11 0x808b3c2 in ?? ()
---Type return to continue, or q return to quit---
#12 0x8086d0b in ?? ()
#13 0x80563b6 in ?? ()
#14 0x8057e15 in ?? ()
#15 0x80580a5 in ?? ()
#16 0x805a125 in ?? ()
#17 0x805b6e6 in ?? ()
#18 0x805c10b in ?? ()
#19 0x8071f7f in ?? ()
#20 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 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
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
