Re: guide to downgrading from 5.0 to 4.4-STABLE
On Fri, Nov 02, 2001 at 06:35:40AM -0800, David Wolfskill wrote: Aye; feel free to holler if you find your machine wedged. It can be Very Helpful to have another fallback machine for various reasons Hi Well, after a couple of false starts, managed to downgrade successfully and so far, everything (including X) seems to be functioning. I couldn't do a binary install as the scsi cdrom, whilst detecting the root partition on the cd, wouldnt boot from it, and I didn't have access to a floppy drive or cable. I did have a spare atapi cdrom, but it wasn't a bootable device. (What puzzles me is that the scsi cdrw and cdrom are well supported and booting from scsi was enabled as primary in the bios, but that's for another day). Anyhow, removed /usr/src, /usr/doc and switched the cvsupfile tag from . to 4.4, cvsupped everything down and followed the instructions in UPDATING as if I was upgrading from 4.0 to 4.4, apart from initially doing a make clean in /usr/src make buildworld proceeded without a hitch as did make buildkernel and installkernel. make installworld was toast because /modules didnt exsist, made that dir and restarted installworld, it installed cleanly (then mergemaster of course) (yes it does help to have more than one freebsd box :) fingers crossed he box seems to be working fine. I would expect some programs not to work because of dependency failure, but havent seen that yet thanks for your help -- John - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Panic with PCCARD
Hi Warner, From: Warner Losh [EMAIL PROTECTED] Date: Fri, 02 Nov 2001 10:36:00 -0700 ::: Now my pccard-modem gets attached as sio2, instead of sio3 like few days ::: ago which seemed bogus, because my system don't have sio2! :: ::Interesting. Do you have a sio2 that is disabled on isa or a sio3 ::that's disabled? :: ::I didn't see these problems on my machine when I tested, so I'm ::interested to see why/how they happen. I don't have any settings done for either sio2 nor sio3. My pccard modem used to attach as sio2, until pcic related changes were made on early June, that caused it to attach as sio3. But I didn't bother repoting back then. There may have been some interaction related problem between kernel pccard code and pccardd that was corrected by this commit. Regards, Haro =-- _ _Munehiro (haro) Matsuda -|- /_\ |_|_| Business Incubation Dept., Kubota Corp. /|\ |_| |_|_| 1-3 Nihonbashi-Muromachi 3-Chome Chuo-ku Tokyo 103-8310, Japan Tel: +81-3-3245-3318 Fax: +81-3-3245-3315 Email: [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
SCSI-IDE
Is there any working thread for doing a SCSI-IDE translation like NetBSD and LINUX has? This is very useful to get proggys like cdrecord (and the GUIs [GnomeToaster]) running on IDE cd writers. Jan To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: SCSI-IDE
On Sun, Nov 04, 2001 at 11:43:57PM +0100, Jan Stocker wrote: Is there any working thread for doing a SCSI-IDE translation like NetBSD and LINUX has? This is very useful to get proggys like cdrecord (and the GUIs [GnomeToaster]) running on IDE cd writers. It would require that someone write an ATA SIM for CAM. As yet, no one has stepped forward to volunteer. Scott To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: panic at shutdown
2. cvsup to r1.96 of tty_cons.c, which should fix this, but due to lack of testers and the inability to reproduce it here, is unverified. I've been testing it, and haven't had any panics, but since the panic was irregular anyway it's hard to say that it's fixed. Bill To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: latest -current broke netscape's name lookup?
awk does not copy input lines to its output unless asked; you can
ask with either an explicit print or an empty action.
Using an input file like:
gibberish
stuff
this doesn't match
here is some garbola
I don't want this file in the ouptut
here's some more stuff
and another line
and another
and another
ooh baby
hosts: files dns
don't print this either
the awk program in /etc/rc.network, without the //{next}, and
changing quit to exit, prints:
# Auto-generated, do not edit
hosts
bind
using either the old gawk or the new awk.
That //{next} may have been necessary during some phase of
script development, but is not necessary now.
Bill
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: buf_daemon() lockup
Hmm. Well, bufdaemon is doing the right thing by blocking
in that loop. The problem appears to be related to the
double-I/O that is occuring due to the way MD filesystems
work. A vnode-backed MD takes a strategy call and turns
around and issues a high-level filesystem write. This
can deadlock the system in wdrain.
I'll take a look at it. I think the easiest thing to do
is to simply convert the async writes into synchronous
writes when we hit the I/O pipe limit, rather then
blocking.
-Matt
Matthew Dillon
[EMAIL PROTECTED]
:I have an easy to reproduce case where my system goes into a blocking
:sleep.
:
:# mdconfig -a -t vnode -f largefile -u 0
:# newfs /dev/md0c
:# mount /dev/md0c /mnt
:# cd /mnt
:# cp -prv /boot .
:[ runs for a while and then stops ]
:
:While breaking into ddb I see that cp, and bufdaemon are asleep with
:wdrain.
:
:To my understanding, bufdaemon is the thread that takes care of flushing
:out the buffers. But as it is put to a blocking sleep, it will never get
:out of this.
:
:A quick (and dirty) fix of it is attached. It doesnt put bufdaemon to wait
:for buffers to flush. But probably this needs to be done in a different
:way. (Like not calling waitrunningbufspace() from buf_daemon())
:
:If it can be pointed out in which direction this should be solved I can
:work it out further.
:
:Thanks
:
:Mark
:
:--
:Mark Santcroos RIPE Network Coordination Centre
:http://www.ripe.net/home/mark/ New Projects Group/TTM
:
:--uQr8t48UFsdbeI+V
:Content-Type: text/plain; charset=us-ascii
:Content-Disposition: attachment; filename=vfs_bio.patch
:
:--- vfs_bio.c.orig Thu Nov 1 08:31:30 2001
:+++ vfs_bio.c Thu Nov 1 08:30:36 2001
:@@ -270,7 +270,10 @@
: {
: while (runningbufspace hirunningspace) {
: ++runningbufreq;
:+ if(curthread-td_proc-p_pid!=5)
: tsleep(runningbufreq, PVM, wdrain, 0);
:+ else
:+ break;
: }
: }
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: buf_daemon() lockup
Ok, I think I've whacked this one. Try this patch and see if it
fixes your buf_daemon() lockups. The patch also fixes the
double-data-caching that occurs with file-backed MD.
If this works for you, Mark, I'll commit it and probably also MFC it.
I'll also be able to apply the same IO_NOWDRAIN fixes to the nfs server
code for loopback mounts.
-Matt
Index: dev/md/md.c
===
RCS file: /home/ncvs/src/sys/dev/md/md.c,v
retrieving revision 1.47
diff -u -r1.47 md.c
--- dev/md/md.c 2001/10/11 23:38:13 1.47
+++ dev/md/md.c 2001/11/04 23:54:18
@@ -388,13 +388,18 @@
auio.uio_td = curthread;
if (VOP_ISLOCKED(sc-vnode, NULL))
vprint(unexpected md driver lock, sc-vnode);
+ /*
+* When reading set IO_DIRECT to try to avoid double-caching
+* the data. When writing IO_DIRECT is not optimal, but we
+* must set IO_NOWDRAIN to avoid a wdrain deadlock.
+*/
if (bp-bio_cmd == BIO_READ) {
vn_lock(sc-vnode, LK_EXCLUSIVE | LK_RETRY, curthread);
- error = VOP_READ(sc-vnode, auio, 0, sc-cred);
+ error = VOP_READ(sc-vnode, auio, IO_DIRECT, sc-cred);
} else {
(void) vn_start_write(sc-vnode, mp, V_WAIT);
vn_lock(sc-vnode, LK_EXCLUSIVE | LK_RETRY, curthread);
- error = VOP_WRITE(sc-vnode, auio, 0, sc-cred);
+ error = VOP_WRITE(sc-vnode, auio, IO_NOWDRAIN, sc-cred);
vn_finished_write(mp);
}
VOP_UNLOCK(sc-vnode, 0, curthread);
Index: kern/vfs_bio.c
===
RCS file: /home/ncvs/src/sys/kern/vfs_bio.c,v
retrieving revision 1.291
diff -u -r1.291 vfs_bio.c
--- kern/vfs_bio.c 2001/10/21 06:26:55 1.291
+++ kern/vfs_bio.c 2001/11/04 23:41:19
@@ -758,11 +758,15 @@
int rtval = bufwait(bp);
brelse(bp);
return (rtval);
- } else {
+ } else if ((oldflags B_NOWDRAIN) == 0) {
/*
* don't allow the async write to saturate the I/O
-* system. There is no chance of deadlock here because
-* we are blocking on I/O that is already in-progress.
+* system. Deadlocks can occur only if a device strategy
+* routine (like in MD) turns around and issues another
+* high-level write, in which case B_NOWDRAIN is expected
+* to be set. Otherwise we will not deadlock here because
+* we are blocking waiting for I/O that is already in-progress
+* to complete.
*/
waitrunningbufspace();
}
@@ -1286,7 +1290,8 @@
/* unlock */
BUF_UNLOCK(bp);
- bp-b_flags = ~(B_ASYNC | B_NOCACHE | B_AGE | B_RELBUF | B_DIRECT);
+ bp-b_flags = ~(B_ASYNC | B_NOCACHE | B_AGE | B_RELBUF |
+ B_DIRECT | B_NOWDRAIN);
bp-b_ioflags = ~BIO_ORDERED;
if ((bp-b_flags B_DELWRI) == 0 (bp-b_xflags BX_VNDIRTY))
panic(brelse: not dirty);
Index: sys/buf.h
===
RCS file: /home/ncvs/src/sys/sys/buf.h,v
retrieving revision 1.121
diff -u -r1.121 buf.h
--- sys/buf.h 2001/09/12 08:38:04 1.121
+++ sys/buf.h 2001/11/04 23:30:25
@@ -192,6 +192,11 @@
* the pages underlying the buffer. B_DIRECT is
* sticky until the buffer is released and typically
* only has an effect when B_RELBUF is also set.
+ *
+ * B_NOWDRAIN This flag should be set when a device (like MD)
+ * does a turn-around VOP_WRITE from its strategy
+ * routine. This flag prevents bwrite() from blocking
+ * in wdrain, avoiding a deadlock situation.
*/
#defineB_AGE 0x0001 /* Move to age queue when I/O done. */
@@ -204,7 +209,7 @@
#defineB_DELWRI0x0080 /* Delay I/O until buffer reused. */
#defineB_DONE 0x0200 /* I/O completed. */
#defineB_EINTR 0x0400 /* I/O was interrupted */
-#defineB_0800 0x0800 /* Available flag. */
+#defineB_NOWDRAIN 0x0800 /* Avoid wdrain deadlock */
#defineB_SCANNED 0x1000 /* VOP_FSYNC funcs mark written bufs */
#defineB_INVAL 0x2000 /* Does not contain valid info. */
#defineB_LOCKED0x4000 /* Locked in core (not reusable). */
Index: sys/vnode.h
more on ... Re: buf_daemon() lockup
Hmm.. that last patch didn't do it. I've noticed some errors on the console before the lockup: unexpected md driver lock: 0xe1813900: type VREG, usecount 2, writecount 1, refcount 3871, flags (VOBJBUF) tag VT_UFS, ino 4, on dev da0s1h (13, 131079) lock type inode: EXCL (count 1) by pid 6 unexpected md driver lock: 0xe1813900: type VREG, usecount 1, writecount 1, refcount 3874, flags (VOBJBUF) tag VT_UFS, ino 4, on dev da0s1h (13, 131079) lock type inode: EXCL (count 1) by pid 6 This occured both with and without my patch. Perhaps it is responsible for the problem? My 'cp -pr /boot /mnt' gets stuck in an inode lock and bufdaemon gets stuck in wdrain. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
