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: How to add a new bootdevice to the new boot code ???
> It seems Robert Nordier wrote: > > If the problem is the bootblocks, why not send a message to Robert > > Nordier, or if it's loader, to Mike Smith or Daniel Sobral? And > > say, "This is what I want to do, what are we going to do about it?" > > or something similar? > > OK, easy enough, this is what I want to do: > > Boot from an ata disk on major# 30, device name "ad", plain and simple. > > As the bootcode is now this wont work. If its as simple as me adding > the pair 30 & "ad" somewhere, I'm satisfied, if not, I'm dissapointed :) Hah. You should be reusing the major from 'wd'; there is no other way for this to work, sorry. More eloquently, the only information the loader has is the "disk type" field from the disklabel, from which it has to decide the major for the root device (this is all historical Vax breakage, but resistance to fixing it has been strong). By picking a random number for the major for your new device, you make the situation much worse than it needs to be; the loader can't tell which ATA driver is in the kernel. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ m...@smith.net.au \\ The race is long, and in the \\ msm...@freebsd.org \\ end it's only with yourself. \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: How to add a new bootdevice to the new boot code ???
This will require relabelling all of one class or the other (new disklabel), or a major overhaul of the way that the root disk is found inside the kernel. IMHO, the latter is where the change needs to happen. SLICE might have made it a little easier, but searching won't actually be all that difficult. Someone want to do the work? > > I think you are missing the point. We will not chuck the old > wd* driver until people have crashed all MFM, RLL, ESDI and !ATA > IDE drives. > > So we WANT to be able to tell the difference... > > Poul-Henning > > In message , Matthew Jacob > w > rites: > > > >I asked Soren just this kind of question, and he declined to answer. I > >doan geddit... > > > >On Wed, 17 Mar 1999, David O'Brien wrote: > > > >> > Boot from an ata disk on major# 30, device name "ad", plain and simple. > >> > >> Does this mean ata disks won't come under CAM/da ? > >> If not, can we PLEASE rename SCSI disks back to ``sd''? > >> > >> -- > >> -- David(obr...@nuxi.com -or- obr...@freebsd.org) > >> > >> > >> To Unsubscribe: send mail to majord...@freebsd.org > >> with "unsubscribe freebsd-current" in the body of the message > >> > > > > > > > >To Unsubscribe: send mail to majord...@freebsd.org > >with "unsubscribe freebsd-current" in the body of the message > > > > -- > Poul-Henning Kamp FreeBSD coreteam member > p...@freebsd.org "Real hackers run -current on their laptop." > FreeBSD -- It will take a long time before progress goes too far! > > > To Unsubscribe: send mail to majord...@freebsd.org > with "unsubscribe freebsd-current" in the body of the message > -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ m...@smith.net.au \\ The race is long, and in the \\ msm...@freebsd.org \\ end it's only with yourself. \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: How to add a new bootdevice to the new boot code ???
SLICES, if done right, would make SO many things so much easier. Poul-Henning In message <199903180843.aaa01...@dingo.cdrom.com>, Mike Smith writes: > >This will require relabelling all of one class or the other (new >disklabel), or a major overhaul of the way that the root disk is found >inside the kernel. IMHO, the latter is where the change needs to >happen. SLICE might have made it a little easier, but searching won't >actually be all that difficult. Someone want to do the work? > >> >> I think you are missing the point. We will not chuck the old >> wd* driver until people have crashed all MFM, RLL, ESDI and !ATA >> IDE drives. >> >> So we WANT to be able to tell the difference... -- Poul-Henning Kamp FreeBSD coreteam member p...@freebsd.org "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! 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
MTRR registers
Is there a way in -current to manipulate the MTRR registers of recent intel processors? I really want to make my framebuffer write-combined. -- Frode Vatvedt Fjeld To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Annoying behaviour of sysinstall
Dear FreeBSD'ers, Can anybody explain why sysinstall (in post-install configuration mode) trying mount already configured swap devices (disk label editor)? Is it a bug or feature? Maybe it will be useful to add routine which will check if swap is already in use? Sincerely, Maxim Sobolev 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: disk quota overriding
> Dmitry Valdov wrote: > > I think that there is only one way to fix it - it's to disable making > > *hard*links to directory with mode 1777. I don't use quotas, and don't know a great deal about how they operate, but I think there's another disk filling DOS involving hard links lurking which the above measure would also solve. If a user starts making hard links to (large and growing) log files, with the new links being placed in /var/mail, then presumably those log files will not be deleted correctly as they are rolled over, and will quickly accumulate. This could not bring down a system as rapidly as growing the publicly writable directory with lots of links, but it is not desirable system behaviour. Andrew McNaughton -- --- Andrew McNaughton and...@squiz.co.nz http://www.newsroom.co.nz/ To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: disk quota overriding
Andrew McNaughton wrote: > > I don't use quotas, and don't know a great deal about how they operate, but I > think there's another disk filling DOS involving hard links lurking which the > above measure would also solve. > > If a user starts making hard links to (large and growing) log files, with the > new links being placed in /var/mail, then presumably those log files will not > be deleted correctly as they are rolled over, and will quickly accumulate. And what the f* is the user doing with read access to the log directory? -- Daniel C. Sobral(8-DCS) d...@newsguy.com d...@freebsd.org "What happened?" "It moved, sir!" To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: disk quota overriding
On Fri, 19 Mar 1999, Andrew McNaughton wrote: > > Dmitry Valdov wrote: > > > I think that there is only one way to fix it - it's to disable making > > > *hard*links to directory with mode 1777. > > I don't use quotas, and don't know a great deal about how they operate, > but I think there's another disk filling DOS involving hard links > lurking which the above measure would also solve. > > If a user starts making hard links to (large and growing) log files, > with the new links being placed in /var/mail, then presumably those log > files will not be deleted correctly as they are rolled over, and will > quickly accumulate. > > This could not bring down a system as rapidly as growing the publicly > writable directory with lots of links, but it is not desirable system > behaviour. So, yet another risk associated with allowing hard links :-). Again, presumably the answer here is either a) restrict the creation of hard links, and b) make sure that users never have write access to any partition you don't want them to have the ability to preserve files on. The linking behavior in conjunction with quotas makes a lot of sense: if a user wants to consume someone else's quota, she just hard links to their files so they cannot delete them. And if she are mean, she links to them in private directories so the victim cannot find the links. Even if the user truncates the file, the inode is still consumed in their name. Robert N Watson rob...@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: 03 01 DD 8E 15 67 48 73 25 6D 10 FC EC 68 C1 1C Carnegie Mellon Universityhttp://www.cmu.edu/ TIS Labs at Network Associates, Inc. http://www.tis.com/ Safeport Network Services http://www.safeport.com/ To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: panic: vfs_busy: unexpected lock failure
Matthew Dillon wrote:
> :On Tue, Mar 16, 1999 at 12:52:32PM -0800, Matthew Dillon wrote:
> :> A.. And if you make those AMD mounts normal nfs mounts it doesn't
> :> fry? If so, then we have a bug in AMD somewhere.
> :
> :I tried the cp several times again on a regular NFS mount, to make
> :sure, and no, it doesn't seem to panic. So yes, that seems to be
> :AMD-related. Can't it be in the vfs layer though?
> :--
> :Pierre Beyssac p...@enst.fr
>
> It's probably AMD. I'm not really up on how AMD works... hasn't someone
> done some work on it recently to fix other breakages? Maybe they could
> look at this panic.
AMD is easy to upset, and that's bad because it's holding a mountpoint in /
(ie: /host) which often gets hit by every single getcwd() call when it
gets a lstat("/host"...) or whatever. I think this is the single largest
source of load on the amd process.
The other problem is that amd is an rpc client, it depends on the libc rpc
code for robustness, and that's not the first word that springs to mind
when I think of it... When amd hangs on a dns lookup, there are all sorts
of VFS locking cascades and NFS wedges while the kernel is retrying all
those retransmitted packets to amd's pseudo-nfs server port. It's been
found to be the primary cause of the 'nfsrcv' hangs - processes wedged in
getcwd() style situations trying to stat /host.
IMHO, /host needs to move down a level to get it out of the way of
getcwd(). NFS mounts should probably move away from / as well, as they
cause traffic on each getcwd().
I think the default settings should look something like this..
/net- amd and nfs related stuff
/net/sysname/mount1 - nfs mount created by amd
/net/sysname/mount2 - nfs mount created by amd
/net/host - /host lives here instead.
and a symlink:
/host -> /net/host
I think that'll stop amd from being hammered by all those lstat()'s in
getcwd and friends in the root directory.
And instead of mounting NFS things as: /a, mount them as /net/a instead
and use a symlink.
This isn't a "fix", it's just trying to move a particularly weak link out
of the direct line of fire. A real solution would be a proper userfs
interface that could cope with kernel<->user_process protocol timeouts,
process deaths, etc. Of course, then there's always an in-kernel autofs
etc.
Cheers,
-Peter
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message
Re: panic: vfs_busy: unexpected lock failure
< said:
> AMD is easy to upset, and that's bad because it's holding a mountpoint in /
> (ie: /host) which often gets hit by every single getcwd() call when it
> gets a lstat("/host"...) or whatever. I think this is the single largest
> source of load on the amd process.
> IMHO, /host needs to move down a level to get it out of the way of
> getcwd(). NFS mounts should probably move away from / as well, as they
> cause traffic on each getcwd().
`/host' is non-standard. The Standard Configuration is `/net' is the
directory simulated by amd and `/a/${hostname}/root' is where amd
mounts the directory tree. This is done specifically to avoid getcwd
wedgitude. The example we ship would sorely puzzle anyone who is
experienced running a Standard Configuration amd.
My machine has, throughout its entire history, had `/home' simulated
by amd. I have literally *never* had amd hose my configuration (and I
would know it fast since both mail and Web service would break).
-GAWollman
--
Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same
woll...@lcs.mit.edu | O Siem / The fires of freedom
Opinions not those of| Dance in the burning flame
MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message
Confused by wcd->acd in UPDATING
Hi folks, 19990316: The name of the old wd.c and atapi.c based CDROM driver has been changed back to wcd. So update your config file to use "device wcd" instead of "device acd". Am I right in thinking that this only applies to people who are _not_ using Soren's new IDE/ATA/ATAPI driver? I ask because I don't use acd at all, I use the recommended atapicd. So I assume that this doesn't apply to me. Old and new are confusing terms in the light of the fact that there are no less than 3 drivers available for ATAPI devices. :-) Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: disk quota overriding
>Date: Wed, 17 Mar 1999 20:00:17 -0500 (EST) >From: "David H. Brierley" >On any machine which allows general users to log in, I strongly >recommend making separate file systems for /, /usr, /tmp, and /home, > I'll merely point out (since the relevance to -current, per se, is minimal at this point) that there was a recent thread on sage-memb...@usenix.org on how/whether to split up disks into separate filesystems. And mention that folks how are concerned with such issues might find that SAGE and USENIX may well be resources worth checking out. (Domain is usenix.org; I expect y'all can take Web & majordomo queries from there.) Cheers, david -- David Wolfskill UNIX System Administrator d...@whistle.comvoice: (650) 577-7158 pager: (650) 371-4621 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: Confused by wcd->acd in UPDATING
It seems Sheldon Hearn wrote: > > Hi folks, > > 19990316: > The name of the old wd.c and atapi.c based CDROM driver has > been changed back to wcd. So update your config file to use > "device wcd" instead of "device acd". > > Am I right in thinking that this only applies to people who are _not_ > using Soren's new IDE/ATA/ATAPI driver? Yes. > I ask because I don't use acd at all, I use the recommended atapicd. So > I assume that this doesn't apply to me. No. > Old and new are confusing terms in the light of the fact that there are > no less than 3 drivers available for ATAPI devices. :-) 3 ?? I can only count two, the current one (now wcd) and my new one... -Søren To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: Confused by wcd->acd in UPDATING
On Thu, 18 Mar 1999 16:57:32 +0100, Søren Schmidt wrote: > 3 ?? I can only count two, the current one (now wcd) and my new one... You're not as confused as I am. Thanks for the clarification. :-) Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: disk quota overriding
On Fri, 19 Mar 1999, Andrew McNaughton wrote: > > Dmitry Valdov wrote: > > > I think that there is only one way to fix it - it's to disable making > > > *hard*links to directory with mode 1777. > > I don't use quotas, and don't know a great deal about how they > operate, but I think there's another disk filling DOS involving hard > links lurking which the above measure would also solve. If a user > starts making hard links to (large and growing) log files, with the > new links being placed in /var/mail, then presumably those log files > will not be deleted correctly as they are rolled over, and will > quickly accumulate. > > This could not bring down a system as rapidly as growing the publicly > writable directory with lots of links, but it is not desirable system > behaviour. This is beginning to sound like a broken record: 1) I usually move mail to /var/spool/mail, 2) You can't hard link between /var and /var/spool partitions. On some machines /var/log is a filesys to prevent logfile overflows from filling /var anyway. I usually make a different /var/spool on largish machines to help upgrades go faster. I tend to unmount it, /home, and /usr/local and completely replace the OS. No doubt there are other ways to fix this... - Jy@ To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: disk quota overriding
On Thu, 18 Mar 1999, Robert Watson wrote: > The linking behavior in conjunction with quotas makes a lot of sense: if a > user wants to consume someone else's quota, she just hard links to their > files so they cannot delete them. And if she are mean, she links to them > in private directories so the victim cannot find the links. Even if the > user truncates the file, the inode is still consumed in their name. User's manager: Why can't you read your mail or write code? Now, *why* was your unix account blocked? Why did you do *that*? After I make systems fairly secure, I do not hesistate to warn users if they interfere with others. I raraly hesistate in cutting accounts off after warnings. I warn for things like filling /tmp when you vi a 100M application dumo file. I block for things like demonstrably(sp?) injuring others. As I usually log info (ls of dir, clip log msgs, etc...), I usually get cooperation from management. It has also assisted them in gathering enough records to remove such folks from the payroll - they are usually problem folks in other areas as well. Fix social problems with social tools - Jy@ To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
BIND-8.2 Released March 16, 1999
Hello! What do think about add new version of BIND to -current? Rgdz, Sergey Osokin, o...@etrust.ru 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: BIND-8.2 Released March 16, 1999
> What do think about add new version of BIND to -current?
There have been some error reports against 8.2-REL, and I think we
should let it have a few more weeks to stabilize before it is brought
into -current.
(We're running 8.2 at some important name servers here, for instance
one which is authoritative for .no. It seems to be working fine for us
now, but we had some crashes during 8.2 beta testing.)
8.2 compiles out of the box on FreeBSD ("make clean; make depend; make")
so it's very easy to setup if you really need the new features in 8.2
right now.
Steinar Haug, Nethelp consulting, sth...@nethelp.no
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
