fsck_ffs diff needs testing
Hi,
I got little feedeback on this diff posed in a rather long thread, so
I am posting it again.
Please test this, it makes fsck_ffs much faster (especially with -p)
and less memory hungry in a lot of cases.
Note that to force a check with -p you need to unmount the filesystem,
mosty practical is do it in single user mode:
# shutdown now
..
# umount -a
# fsck -pf
(Don't forget the unmount!)
Other way: pull the plug on a machine and let it reboot. That is a
more realistic check and it is safe because you already backup up all
your data, right?
-Otto
Index: dir.c
===
RCS file: /cvs/src/sbin/fsck_ffs/dir.c,v
retrieving revision 1.24
diff -u -p -r1.24 dir.c
--- dir.c 27 Oct 2009 23:59:32 - 1.24
+++ dir.c 4 Apr 2011 09:15:49 -
@@ -443,8 +443,8 @@ linkup(ino_t orphan, ino_t parentdir)
idesc.id_type = ADDR;
idesc.id_func = pass4check;
idesc.id_number = oldlfdir;
- adjust(idesc, lncntp[oldlfdir] + 1);
- lncntp[oldlfdir] = 0;
+ adjust(idesc, ILNCOUNT(oldlfdir) + 1);
+ ILNCOUNT(oldlfdir) = 0;
dp = ginode(lfdir);
}
if (GET_ISTATE(lfdir) != DFOUND) {
@@ -457,7 +457,7 @@ linkup(ino_t orphan, ino_t parentdir)
printf(\n\n);
return (0);
}
- lncntp[orphan]--;
+ ILNCOUNT(orphan)--;
if (lostdir) {
if ((changeino(orphan, .., lfdir) ALTERED) == 0
parentdir != (ino_t)-1)
@@ -465,7 +465,7 @@ linkup(ino_t orphan, ino_t parentdir)
dp = ginode(lfdir);
DIP_SET(dp, di_nlink, DIP(dp, di_nlink) + 1);
inodirty();
- lncntp[lfdir]++;
+ ILNCOUNT(lfdir)++;
pwarn(DIR I=%u CONNECTED. , orphan);
if (parentdir != (ino_t)-1) {
printf(PARENT WAS I=%u\n, parentdir);
@@ -476,7 +476,7 @@ linkup(ino_t orphan, ino_t parentdir)
* fixes the parent link count so that fsck does
* not need to be rerun.
*/
- lncntp[parentdir]++;
+ ILNCOUNT(parentdir)++;
}
if (preen == 0)
printf(\n);
@@ -636,7 +636,7 @@ allocdir(ino_t parent, ino_t request, in
DIP_SET(dp, di_nlink, 2);
inodirty();
if (ino == ROOTINO) {
- lncntp[ino] = DIP(dp, di_nlink);
+ ILNCOUNT(ino) = DIP(dp, di_nlink);
cacheino(dp, ino);
return(ino);
}
@@ -650,8 +650,8 @@ allocdir(ino_t parent, ino_t request, in
inp-i_dotdot = parent;
SET_ISTATE(ino, GET_ISTATE(parent));
if (GET_ISTATE(ino) == DSTATE) {
- lncntp[ino] = DIP(dp, di_nlink);
- lncntp[parent]++;
+ ILNCOUNT(ino) = DIP(dp, di_nlink);
+ ILNCOUNT(parent)++;
}
dp = ginode(parent);
DIP_SET(dp, di_nlink, DIP(dp, di_nlink) + 1);
Index: extern.h
===
RCS file: /cvs/src/sbin/fsck_ffs/extern.h,v
retrieving revision 1.10
diff -u -p -r1.10 extern.h
--- extern.h25 Jun 2007 19:59:55 - 1.10
+++ extern.h4 Apr 2011 09:15:49 -
@@ -54,6 +54,7 @@ int ftypeok(union dinode *);
void getpathname(char *, size_t, ino_t, ino_t);
void inocleanup(void);
void inodirty(void);
+struct inostat *inoinfo(ino_t);
intlinkup(ino_t, ino_t);
intmakeentry(ino_t, ino_t, char *);
void pass1(void);
Index: fsck.h
===
RCS file: /cvs/src/sbin/fsck_ffs/fsck.h,v
retrieving revision 1.23
diff -u -p -r1.23 fsck.h
--- fsck.h 10 Jun 2008 23:10:29 - 1.23
+++ fsck.h 4 Apr 2011 09:15:49 -
@@ -66,6 +66,19 @@ union dinode {
#define BUFSIZ 1024
#endif
+/*
+ * Each inode on the file system is described by the following structure.
+ * The linkcnt is initially set to the value in the inode. Each time it
+ * is found during the descent in passes 2, 3, and 4 the count is
+ * decremented. Any inodes whose count is non-zero after pass 4 needs to
+ * have its link count adjusted by the value remaining in ino_linkcnt.
+ */
+struct inostat {
+ charino_state; /* state of inode, see below */
+ charino_type; /* type of inode */
+ short ino_linkcnt;/* number of links not found */
+};
+
#defineUSTATE 01 /* inode not allocated */
#defineFSTATE 02 /* inode is file */
#defineDSTATE 03 /* inode is directory */
@@ -73,12 +86,20 @@ union dinode {
#defineDCLEAR 05 /* directory is to be cleared */
#defineFCLEAR 06 /* file is to be
Re: vnds considerd harmful.
On Wed, Apr 06, 2011 at 04:25:15PM -0400, Jonathan Thornburg wrote: In http://marc.info/?l=openbsd-techm=130200205608892w=1, Thordur Bjornsson thib () openbsd ! org wrote: Now that I've disallowed swapping to vnd's the purpose of vnd (vs svnd) is suspect, it serves no purpose other then providing a different way of doing what svnd does (which imo, isn't even better). So, nuke vnds (keep svnds though!). This will make svndXn the same as vndXn etc. The idea is that in a few releases we'll simply remove the svnd0 notes. ^ - nodes. With this diff svnd0 == vnd0 in your /dev. Could you clarify the semantics of the in a few releases plan? That is, are you proposing that the in a few releases OpenBSD will have (a) vnd == today's svnd, bingo. (b) vnd == today's vnd, (c) vnd == some sort of merging of today's vnd and today's svnd, or (d) something else which hasn't occured to me yet I sort of think you're proposing (a), but I'm not entirely sure that I'm parsing your wording correctly... [Hmm, I wonder if my failure-to-parse is related to a recent bout of perl hashes holding references to anonymous hashes holding references to anonymous lists. :) ] So, yeah. vnd's will become today's svnd0's and the old style bypassing of the buffer cache is gone (leaving only svnd0s). Then in a few releases, the svnd device nodes will be removed.
Re: fsck_ffs diff needs testing
On Thu, Apr 07, 2011 at 11:08:05AM +0200, Otto Moerbeek wrote:
Hi,
I got little feedeback on this diff posed in a rather long thread, so
I am posting it again.
Please test this, it makes fsck_ffs much faster (especially with -p)
and less memory hungry in a lot of cases.
Note that to force a check with -p you need to unmount the filesystem,
mosty practical is do it in single user mode:
# shutdown now
..
# umount -a
# fsck -pf
(Don't forget the unmount!)
Other way: pull the plug on a machine and let it reboot. That is a
more realistic check and it is safe because you already backup up all
your data, right?
I went the unplug route on the i386 box and amd64 box I have here, and
the diff seems to work. Reads ok. I say go for it.
Ken
-Otto
Index: dir.c
===
RCS file: /cvs/src/sbin/fsck_ffs/dir.c,v
retrieving revision 1.24
diff -u -p -r1.24 dir.c
--- dir.c 27 Oct 2009 23:59:32 - 1.24
+++ dir.c 4 Apr 2011 09:15:49 -
@@ -443,8 +443,8 @@ linkup(ino_t orphan, ino_t parentdir)
idesc.id_type = ADDR;
idesc.id_func = pass4check;
idesc.id_number = oldlfdir;
- adjust(idesc, lncntp[oldlfdir] + 1);
- lncntp[oldlfdir] = 0;
+ adjust(idesc, ILNCOUNT(oldlfdir) + 1);
+ ILNCOUNT(oldlfdir) = 0;
dp = ginode(lfdir);
}
if (GET_ISTATE(lfdir) != DFOUND) {
@@ -457,7 +457,7 @@ linkup(ino_t orphan, ino_t parentdir)
printf(\n\n);
return (0);
}
- lncntp[orphan]--;
+ ILNCOUNT(orphan)--;
if (lostdir) {
if ((changeino(orphan, .., lfdir) ALTERED) == 0
parentdir != (ino_t)-1)
@@ -465,7 +465,7 @@ linkup(ino_t orphan, ino_t parentdir)
dp = ginode(lfdir);
DIP_SET(dp, di_nlink, DIP(dp, di_nlink) + 1);
inodirty();
- lncntp[lfdir]++;
+ ILNCOUNT(lfdir)++;
pwarn(DIR I=%u CONNECTED. , orphan);
if (parentdir != (ino_t)-1) {
printf(PARENT WAS I=%u\n, parentdir);
@@ -476,7 +476,7 @@ linkup(ino_t orphan, ino_t parentdir)
* fixes the parent link count so that fsck does
* not need to be rerun.
*/
- lncntp[parentdir]++;
+ ILNCOUNT(parentdir)++;
}
if (preen == 0)
printf(\n);
@@ -636,7 +636,7 @@ allocdir(ino_t parent, ino_t request, in
DIP_SET(dp, di_nlink, 2);
inodirty();
if (ino == ROOTINO) {
- lncntp[ino] = DIP(dp, di_nlink);
+ ILNCOUNT(ino) = DIP(dp, di_nlink);
cacheino(dp, ino);
return(ino);
}
@@ -650,8 +650,8 @@ allocdir(ino_t parent, ino_t request, in
inp-i_dotdot = parent;
SET_ISTATE(ino, GET_ISTATE(parent));
if (GET_ISTATE(ino) == DSTATE) {
- lncntp[ino] = DIP(dp, di_nlink);
- lncntp[parent]++;
+ ILNCOUNT(ino) = DIP(dp, di_nlink);
+ ILNCOUNT(parent)++;
}
dp = ginode(parent);
DIP_SET(dp, di_nlink, DIP(dp, di_nlink) + 1);
Index: extern.h
===
RCS file: /cvs/src/sbin/fsck_ffs/extern.h,v
retrieving revision 1.10
diff -u -p -r1.10 extern.h
--- extern.h 25 Jun 2007 19:59:55 - 1.10
+++ extern.h 4 Apr 2011 09:15:49 -
@@ -54,6 +54,7 @@ int ftypeok(union dinode *);
void getpathname(char *, size_t, ino_t, ino_t);
void inocleanup(void);
void inodirty(void);
+struct inostat *inoinfo(ino_t);
int linkup(ino_t, ino_t);
int makeentry(ino_t, ino_t, char *);
void pass1(void);
Index: fsck.h
===
RCS file: /cvs/src/sbin/fsck_ffs/fsck.h,v
retrieving revision 1.23
diff -u -p -r1.23 fsck.h
--- fsck.h10 Jun 2008 23:10:29 - 1.23
+++ fsck.h4 Apr 2011 09:15:49 -
@@ -66,6 +66,19 @@ union dinode {
#define BUFSIZ 1024
#endif
+/*
+ * Each inode on the file system is described by the following structure.
+ * The linkcnt is initially set to the value in the inode. Each time it
+ * is found during the descent in passes 2, 3, and 4 the count is
+ * decremented. Any inodes whose count is non-zero after pass 4 needs to
+ * have its link count adjusted by the value remaining in ino_linkcnt.
+ */
+struct inostat {
+ charino_state; /* state of inode, see below */
+ charino_type; /* type of inode */
+ short ino_linkcnt;/* number of links not found */
+};
+
#define USTATE 01 /* inode not allocated */
#define FSTATE 02 /* inode is file */
#define DSTATE 03 /* inode is
Re: resurect and fix bce(4)
2011/4/3 Claudio Jeker cje...@diehard.n-r-g.com bce(4) was turned off because of limitations in the DMA engine that allows the chip to access only 1G of memory. On systems with more then 1G of memory hilarity ensued. Now I rewrote the driver to use bcopy() to copy the mbufs into a savely allocated DMA memory buffer. So the chip will now work with any ammount of memory in the machine. It works for me so if you own a bce(4) please test. FWIW, my loaner laptop from the job works fine with this, giving me bce0 back. (I used to limit ram to 1G when I needed bce before, don't have to anymore. I don't care for the performance drop, its far above 0 now) -- To our sweethearts and wives. May they never meet. -- 19th century toast
Re: fsck_ffs diff needs testing
On 2011-04-07 11.08, Otto Moerbeek wrote:
Hi,
I got little feedeback on this diff posed in a rather long thread, so
I am posting it again.
Please test this, it makes fsck_ffs much faster (especially with -p)
and less memory hungry in a lot of cases.
I've run it on a variety of file systems now and first of all, it seems
to work without regressions. It also looks like it has about 2/3 of its
previous memory footprint. However, I see very little increase in speed:
Unpatched, run with time /sbin/fsck_ffs -pf /dev/rraid0[adefghi]:
/dev/rraid0a: 2874 files, 82005 used, 46810 free (866 frags, 5743
blocks, 0.7% fragmentation)
/dev/rraid0d: 1477 files, 144486 used, 886745 free (553 frags, 110774
blocks, 0.1% fragmentation)
/dev/rraid0e: 224749 files, 1624996 used, 438155 free (48771 frags,
48673 blocks, 2.4% fragmentation)
/dev/rraid0f: 9437 files, 103157 used, 4024794 free (3370 frags, 502678
blocks, 0.1% fragmentation)
/dev/rraid0g: 498655 files, 6190187 used, 4128604 free (17188 frags,
513927 blocks, 0.2% fragmentation)
/dev/rraid0h: 90459 files, 445770 used, 2649301 free (20357 frags,
328618 blocks, 0.7% fragmentation)
/dev/rraid0i: 35896 files, 666529 used, 1266782 free (9006 frags, 157222
blocks, 0.5% fragmentation)
1m20.35s real 0m2.57s user 0m4.29s system
Patched, run with time /root/fsck_ffs -pf /dev/rraid0[adefghi]:
/dev/rraid0a: 2874 files, 82005 used, 46810 free (866 frags, 5743
blocks, 0.7% fragmentation)
/dev/rraid0d: 1477 files, 144486 used, 886745 free (553 frags, 110774
blocks, 0.1% fragmentation)
/dev/rraid0e: 224749 files, 1624996 used, 438155 free (48771 frags,
48673 blocks, 2.4% fragmentation)
/dev/rraid0f: 9437 files, 103157 used, 4024794 free (3370 frags, 502678
blocks, 0.1% fragmentation)
/dev/rraid0g: 498655 files, 6190187 used, 4128604 free (17188 frags,
513927 blocks, 0.2% fragmentation)
/dev/rraid0h: 90459 files, 445770 used, 2649301 free (20357 frags,
328618 blocks, 0.7% fragmentation)
/dev/rraid0i: 35896 files, 666529 used, 1266782 free (9006 frags, 157222
blocks, 0.5% fragmentation)
1m18.52s real 0m1.32s user 0m3.85s system
The file systems are organized like this:
skynet:~/fsck_ffs_patch# dumpfs -m /dev/rraid0a
# newfs command for /dev/rraid0a
newfs -O 1 -b 16384 -e 4096 -f 2048 -g 16384 -h 64 -m 5 -o time -s
525856 /dev/rraid0a
skynet:~/fsck_ffs_patch# dumpfs -m /dev/rraid0d
# newfs command for /dev/rraid0d
newfs -O 1 -b 16384 -e 4096 -f 2048 -g 16384 -h 64 -m 5 -o time -s
4197120 /dev/rraid0d
skynet:~/fsck_ffs_patch# dumpfs -m /dev/rraid0e
# newfs command for /dev/rraid0e
newfs -O 1 -b 16384 -e 4096 -f 2048 -g 16384 -h 64 -m 5 -o time -s
8390400 /dev/rraid0e
skynet:~/fsck_ffs_patch# dumpfs -m /dev/rraid0f
# newfs command for /dev/rraid0f
newfs -O 1 -b 16384 -e 4096 -f 2048 -g 16384 -h 64 -m 5 -o time -s
16780800 /dev/rraid0f
skynet:~/fsck_ffs_patch# dumpfs -m /dev/rraid0g
# newfs command for /dev/rraid0g
newfs -O 1 -b 16384 -e 4096 -f 2048 -g 16384 -h 64 -m 5 -o time -s
41944320 /dev/rraid0g
skynet:~/fsck_ffs_patch# dumpfs -m /dev/rraid0h
# newfs command for /dev/rraid0h
newfs -O 1 -b 16384 -e 4096 -f 2048 -g 16384 -h 64 -m 5 -o time -s
12583680 /dev/rraid0h
skynet:~/fsck_ffs_patch# dumpfs -m /dev/rraid0i
# newfs command for /dev/rraid0i
newfs -O 1 -b 16384 -e 4096 -f 2048 -g 16384 -h 64 -m 5 -o time -s
7857920 /dev/rraid0i
skynet:~/fsck_ffs_patch#
Btw, I noticed a small change in this diff compared to the one you posted
in the previous discussion thread. I assume this is the correct one to use?
skynet:~# diff fsck_ffs.patch fsck_ffs_2.patch
158c158
+++ inode.c 31 Mar 2011 16:34:27 -
---
+++ inode.c 4 Apr 2011 09:16:36 -
203c203
+ info[i].ino_state = USTATE;
---
+ SET_ISTATE(i, USTATE);
Regards,
/Benny
Note that to force a check with -p you need to unmount the filesystem,
mosty practical is do it in single user mode:
# shutdown now
..
# umount -a
# fsck -pf
(Don't forget the unmount!)
Other way: pull the plug on a machine and let it reboot. That is a
more realistic check and it is safe because you already backup up all
your data, right?
-Otto
Index: dir.c
===
RCS file: /cvs/src/sbin/fsck_ffs/dir.c,v
retrieving revision 1.24
diff -u -p -r1.24 dir.c
--- dir.c 27 Oct 2009 23:59:32 - 1.24
+++ dir.c 4 Apr 2011 09:15:49 -
@@ -443,8 +443,8 @@ linkup(ino_t orphan, ino_t parentdir)
idesc.id_type = ADDR;
idesc.id_func = pass4check;
idesc.id_number = oldlfdir;
- adjust(idesc, lncntp[oldlfdir] + 1);
- lncntp[oldlfdir] = 0;
+ adjust(idesc, ILNCOUNT(oldlfdir) + 1);
+ ILNCOUNT(oldlfdir) = 0;
dp = ginode(lfdir);
}
if (GET_ISTATE(lfdir) != DFOUND) {
@@ -457,7 +457,7 @@ linkup(ino_t orphan, ino_t parentdir)
printf(\n\n);
Re: http gzip support for ftp
Delivered-To: marty...@venck.us
Received: by 10.100.109.13 with SMTP id h13cs81395anc;
Sun, 9 Jan 2011 14:09:58 -0800 (PST)
Received: by 10.42.176.2 with SMTP id bc2mr3471559icb.517.1294610998158;
Sun, 09 Jan 2011 14:09:58 -0800 (PST)
Return-Path: owner-tech+m23...@openbsd.org
Received: from shear.ucar.edu (lists.openbsd.org [192.43.244.163])
by mx.google.com with ESMTP id
f5si189964icu.33.2011.01.09.14.09.56;
Sun, 09 Jan 2011 14:09:57 -0800 (PST)
Received-SPF: pass (google.com: manual fallback record for domain of
owner-tech+m23...@openbsd.org designates 192.43.244.163 as permitted sender)
client-ip=192.43.244.163;
Authentication-Results: mx.google.com; spf=pass (google.com: manual fallback
record for domain of owner-tech+m23...@openbsd.org designates 192.43.244.163
as permitted sender) smtp.mail=owner-tech+m23...@openbsd.org; dkim=pass (test
mode) header.i=@gmail.com
Received: from openbsd.org (localhost.ucar.edu [127.0.0.1])
by shear.ucar.edu (8.14.3/8.14.3) with ESMTP id p09M9ZNr021431;
Sun, 9 Jan 2011 15:09:35 -0700 (MST)
Received: from mail-qw0-f49.google.com (mail-qw0-f49.google.com
[209.85.216.49])
by shear.ucar.edu (8.14.3/8.14.3) with ESMTP id p09M8Qo7030584
for tech@openbsd.org; Sun, 9 Jan 2011 15:08:27 -0700 (MST)
Received: by qwj9 with SMTP id 9so18728829qwj.8
for tech@openbsd.org; Sun, 09 Jan 2011 14:08:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
h=domainkey-signature:received:received:date:from:to:cc:subject
:in-reply-to:message-id:references:user-agent:mime-version :content-type;
bh=h/uSItba1mLjBNAbFHi24e9uIaFGrvE/zyzh9me7yYw=;
b=XL2MRc5mQPtKcLk0xcUbEGn9qdUnrl6SeDWu1vs3q6WxC/wpfV2rgJanu5AiWpbf49
wtVrJKYpS9dy1CelkCIVzlg+RPUqnv32G3++umRivu257SvjpOOslVewDoQhQWObt2Ge
rOSbU0xTYAxK1Ed/VpudyiJchjG2z31yWyH+E=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;
h=date:from:to:cc:subject:in-reply-to:message-id:references
:user-agent:mime-version:content-type;
b=vy/Cr6z1/nOya7/ja1dbvBm4ImoKOvIBVNnuY9F9pk7/nk4nX79tDrpqDzmhuQAxtM
NUIjTiMhF4Iqu1yDpP9CxDFrltopI0N2v6zlVhte2HPPW3pumugdFX8PZAuyr8+H+Nxi
TDNAfVeIOfemJkkd/DClpRrGh+GwyqEa8ab+Q=
Received: by 10.224.11.20 with SMTP id r20mr26905601qar.51.1294610906191;
Sun, 09 Jan 2011 14:08:26 -0800 (PST)
Received: from mini.t3rl.org (cpe-74-66-19-205.nyc.res.rr.com
[74.66.19.205])
by mx.google.com with ESMTPS id nb15sm16014404qcb.2.2011.01.09.14.08.24
(version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 09 Jan 2011 14:08:25 -0800 (PST)
Date: Sun, 9 Jan 2011 17:08:22 -0500 (EST)
From: Ted Unangst ted.unan...@gmail.com
To: Ted Unangst ted.unan...@gmail.com
cc: tech@openbsd.org
Subject: Re: http gzip support for ftp
In-Reply-To: alpine.bso.2.00.1101091616360.14...@zvav.g3ey.bet
Message-ID: alpine.bso.2.00.1101091707210.14...@zvav.g3ey.bet
References: alpine.bso.2.00.1101091616360.14...@zvav.g3ey.bet
User-Agent: Alpine 2.00 (BSO 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
List-Help: mailto:majord...@openbsd.org?body=help
List-Owner: mailto:tech-ow...@openbsd.org
List-Post: mailto:tech@openbsd.org
List-Subscribe: mailto:majord...@openbsd.org?body=sub%20tech
List-Unsubscribe: mailto:majord...@openbsd.org?body=unsub%20tech
X-Loop: tech@openbsd.org
Precedence: list
Sender: owner-t...@openbsd.org
On Sun, 9 Jan 2011, Ted Unangst wrote:
Downloading things can go a lot faster if the server and client support
http compression. This is easily added to the ftp program's http
support.
poopers, I hard coded gzipped to 1 by accident. 3rd time's a charm.
Please test, as there are obviously lots of different web servers out
there.
Index: Makefile
===
RCS file: /home/tedu/cvs/src/usr.bin/ftp/Makefile,v
retrieving revision 1.25
diff -u -r1.25 Makefile
--- Makefile 5 May 2009 19:35:30 - 1.25
+++ Makefile 9 Jan 2011 21:14:51 -
@@ -17,8 +17,8 @@
CPPFLAGS+= -DINET6
-LDADD+= -ledit -lcurses -lutil -lssl -lcrypto
-DPADD+= ${LIBEDIT} ${LIBCURSES} ${LIBUTIL}
+LDADD+= -ledit -lcurses -lutil -lssl -lcrypto -lz
+DPADD+= ${LIBEDIT} ${LIBCURSES} ${LIBUTIL} ${LIBZ}
LDSTATIC= ${STATIC}
#COPTS+= -Wall -Wconversion -Wstrict-prototypes -Wmissing-prototypes
Index: fetch.c
===
RCS file: /home/tedu/cvs/src/usr.bin/ftp/fetch.c,v
retrieving revision 1.103
diff -u -r1.103 fetch.c
--- fetch.c 25 Aug 2010 20:32:37 - 1.103
+++ fetch.c 9 Jan 2011 22:07:12 -
@@ -63,6 +63,7 @@
#ifndef SMALL
#include openssl/ssl.h
#include openssl/err.h
+#include zlib.h
#else /* !SMALL */
#define SSL void
#endif /* !SMALL */
@@ -167,6 +168,80 @@
return (epath);
}
+#ifndef SMALL
Please put this at the end of the file, to avoid yet-another #ifndef
SMALL block.
+static size_t
+chunked_read(FILE
Re: rthreads: fix sharing of signal stacks and actions
On Wed, Apr 6, 2011 at 8:16 PM, Brad b...@comstyle.com wrote: I take it this PF diff was not supposed to be in there.. ? Index: sys/net/pf.c Yep. Not even the right thing. I'll reverse that chunk so I don't do a thib and accidentally commit it... Philip
gdt(4) iopoolification - test now or forever hold your peace
As with cac(4). You can test now or can break later.
Ken
Index: ic/gdt_common.c
===
RCS file: /cvs/src/sys/dev/ic/gdt_common.c,v
retrieving revision 1.55
diff -u -p -r1.55 gdt_common.c
--- ic/gdt_common.c 12 Oct 2010 00:53:32 - 1.55
+++ ic/gdt_common.c 13 Oct 2010 11:09:09 -
@@ -61,16 +61,12 @@ int gdt_maxcmds = GDT_MAXCMDS;
#define GDT_DRIVER_SUBVERSION 2
intgdt_async_event(struct gdt_softc *, int);
-void gdt_chain(struct gdt_softc *);
void gdt_clear_events(struct gdt_softc *);
void gdt_copy_internal_data(struct scsi_xfer *, u_int8_t *, size_t);
-struct scsi_xfer *gdt_dequeue(struct gdt_softc *);
-void gdt_enqueue(struct gdt_softc *, struct scsi_xfer *, int);
-void gdt_enqueue_ccb(struct gdt_softc *, struct gdt_ccb *);
void gdt_eval_mapping(u_int32_t, int *, int *, int *);
intgdt_exec_ccb(struct gdt_ccb *);
-void gdt_free_ccb(struct gdt_softc *, struct gdt_ccb *);
-struct gdt_ccb *gdt_get_ccb(struct gdt_softc *, int);
+void gdt_ccb_free(void *, void *);
+void *gdt_ccb_alloc(void *);
void gdt_internal_cache_cmd(struct scsi_xfer *);
intgdt_internal_cmd(struct gdt_softc *, u_int8_t, u_int16_t,
u_int32_t, u_int32_t, u_int32_t);
@@ -82,9 +78,7 @@ int gdt_ioctl_disk(struct gdt_softc *, s
intgdt_ioctl_alarm(struct gdt_softc *, struct bioc_alarm *);
intgdt_ioctl_setstate(struct gdt_softc *, struct bioc_setstate *);
#endif /* NBIO 0 */
-void gdt_raw_scsi_cmd(struct scsi_xfer *);
void gdt_scsi_cmd(struct scsi_xfer *);
-void gdt_start_ccbs(struct gdt_softc *);
intgdt_sync_event(struct gdt_softc *, int, u_int8_t,
struct scsi_xfer *);
void gdt_timeout(void *);
@@ -99,10 +93,6 @@ struct scsi_adapter gdt_switch = {
gdt_scsi_cmd, gdtminphys, 0, 0,
};
-struct scsi_adapter gdt_raw_switch = {
- gdt_raw_scsi_cmd, gdtminphys, 0, 0,
-};
-
int gdt_cnt = 0;
u_int8_t gdt_polling;
u_int8_t gdt_from_wait;
@@ -132,9 +122,8 @@ gdt_attach(struct gdt_softc *sc)
gdt_clear_events(sc);
TAILQ_INIT(sc-sc_free_ccb);
- TAILQ_INIT(sc-sc_ccbq);
- TAILQ_INIT(sc-sc_ucmdq);
- LIST_INIT(sc-sc_queue);
+ mtx_init(sc-sc_ccb_mtx, IPL_BIO);
+ scsi_iopool_init(sc-sc_iopool, sc, gdt_ccb_alloc, gdt_ccb_free);
/* Initialize the ccbs */
for (i = 0; i GDT_MAXCMDS; i++) {
@@ -484,26 +473,6 @@ gdt_attach(struct gdt_softc *sc)
config_found(sc-sc_dev, saa, scsiprint);
- sc-sc_raw_link = malloc(sc-sc_bus_cnt * sizeof (struct scsi_link),
- M_DEVBUF, M_NOWAIT | M_ZERO);
- if (sc-sc_raw_link == NULL)
- panic(gdt_attach);
-
- for (i = 0; i sc-sc_bus_cnt; i++) {
- /* Fill in the prototype scsi_link. */
- sc-sc_raw_link[i].adapter_softc = sc;
- sc-sc_raw_link[i].adapter = gdt_raw_switch;
- sc-sc_raw_link[i].adapter_target = 7;
- sc-sc_raw_link[i].openings = 4;/* XXX a guess */
- sc-sc_raw_link[i].adapter_buswidth =
- (sc-sc_class GDT_FC) ? GDT_MAXID : 16; /* XXX */
-
- bzero(saa, sizeof(saa));
- saa.saa_sc_link = sc-sc_raw_link[i];
-
- config_found(sc-sc_dev, saa, scsiprint);
- }
-
gdt_polling = 0;
return (0);
}
@@ -531,43 +500,6 @@ gdt_eval_mapping(u_int32_t size, int *cy
}
/*
- * Insert a command into the driver queue, either at the front or at the tail.
- * It's ok to overload the freelist link as these structures are never on
- * the freelist at this time.
- */
-void
-gdt_enqueue(struct gdt_softc *sc, struct scsi_xfer *xs, int infront)
-{
- if (infront || LIST_FIRST(sc-sc_queue) == NULL) {
- if (LIST_FIRST(sc-sc_queue) == NULL)
- sc-sc_queuelast = xs;
- LIST_INSERT_HEAD(sc-sc_queue, xs, free_list);
- return;
- }
- LIST_INSERT_AFTER(sc-sc_queuelast, xs, free_list);
- sc-sc_queuelast = xs;
-}
-
-/*
- * Pull a command off the front of the driver queue.
- */
-struct scsi_xfer *
-gdt_dequeue(struct gdt_softc *sc)
-{
- struct scsi_xfer *xs;
-
- xs = LIST_FIRST(sc-sc_queue);
- if (xs == NULL)
- return (NULL);
- LIST_REMOVE(xs, free_list);
-
- if (LIST_FIRST(sc-sc_queue) == NULL)
- sc-sc_queuelast = NULL;
-
- return (xs);
-}
-
-/*
* Start a SCSI operation on a cache device.
* XXX Polled operation is not yet complete. What kind of locking do we need?
*/
@@ -576,18 +508,13 @@ gdt_scsi_cmd(struct scsi_xfer *xs)
{
struct scsi_link *link = xs-sc_link;
struct gdt_softc *sc = link-adapter_softc;
- u_int8_t target = link-target;
struct gdt_ccb *ccb;
-#if 0
- struct gdt_ucmd *ucmd;
-#endif
- u_int32_t blockno, blockcnt;
struct scsi_rw *rw;
struct scsi_rw_big *rwb;
Re: [PATCH] Bypass routing table for mcast packets when using IP_MULTICAST_IF
Keeping this up.
On 17 March 2011 00:51, Christiano F. Haesbaert haesba...@haesbaert.org
wrote:
On 12 June 2010 16:26, Christiano F. Haesbaert haesba...@haesbaert.org
wrote:
Hi,
The following will disregard the routing table for multicast packets
when the application chose the interface with IP_MULTICAST_IF, if not,
normal lookup will take place.
Ripd now no longer needs to explicitly add the mcast host route to
bypass the default reject to 224/4, follows the diff to remove it.
Regarding the normal lookup when IP_MULTICAST_IF wan't set, UNP
regards it as a BSD descendant behaviour, I really don't know anything
else.
I've tested it in a small setup, if someone could confirm it in a
scarier environment would be nice.
Index: netinet/in_pcb.c
===
RCS file: /cvs/src/sys/netinet/in_pcb.c,v
retrieving revision 1.112
diff -d -u -p -w netinet/in_pcb.c
--- netinet/in_pcb.c7 May 2010 13:33:16 - 1.112
+++ netinet/in_pcb.c12 Jun 2010 19:18:49 -
@@ -819,7 +819,9 @@ in_selectsrc(struct sockaddr_in *sin, struct route *ro
}
if ((soopts SO_DONTROUTE) == 0 /*XXX*/
(ro-ro_rt == (struct rtentry *)0 ||
- ro-ro_rt-rt_ifp == (struct ifnet *)0)) {
+ ro-ro_rt-rt_ifp == (struct ifnet *)0)
+ !(IN_MULTICAST(sin-sin_addr.s_addr)
+ mopts (mopts-imo_multicast_ifp != NULL))) {
/* No route yet, so try to acquire one */
ro-ro_dst.sa_family = AF_INET;
ro-ro_dst.sa_len = sizeof(struct sockaddr_in);
Index: kroute.c
===
RCS file: /cvs/src/usr.sbin/ripd/kroute.c,v
retrieving revision 1.21
diff -d -u -p -w kroute.c
--- kroute.c2 Jan 2009 14:40:54 - 1.21
+++ kroute.c12 Jun 2010 19:19:51 -
@@ -97,9 +97,6 @@ RB_HEAD(kif_tree, kif_node) kit;
RB_PROTOTYPE(kif_tree, kif_node, entry, kif_compare)
RB_GENERATE(kif_tree, kif_node, entry, kif_compare)
-struct kroute kr_all_rip_routers;
-intflag_all_rip_routers = 0;
-
int
kif_init(void)
{
@@ -151,14 +148,6 @@ kr_init(int fs, u_int rdomain)
if (protect_lo() == -1)
return (-1);
- kr_all_rip_routers.prefix.s_addr = inet_addr(ALL_RIP_ROUTERS);
- kr_all_rip_routers.netmask.s_addr = htonl(INADDR_BROADCAST);
- kr_all_rip_routers.nexthop.s_addr = htonl(INADDR_LOOPBACK);
-
- kr_state.fib_sync = 1; /* force addition of multicast route */
- if (send_rtmsg(kr_state.fd, RTM_ADD, kr_all_rip_routers) != -1)
- flag_all_rip_routers = 1;
-
kr_state.fib_sync = fs; /* now set correct sync mode */
kr_state.rdomain = rdomain;
@@ -243,11 +232,6 @@ void
kr_shutdown(void)
{
kr_fib_decouple();
-
- if (flag_all_rip_routers) {
- kr_state.fib_sync = 1; /* force removal of mulitcast route
*/
- (void)send_rtmsg(kr_state.fd, RTM_DELETE,
kr_all_rip_routers);
- }
kroute_clear();
kif_clear();
Wow I had completely forgotten about this, I'm using this diff since
then, any comments ?
Thanks
Re: fsck_ffs diff needs testing
On Thu, Apr 07, 2011 at 04:28:25PM +0200, Benny Lofgren wrote: On 2011-04-07 15.06, Otto Moerbeek wrote: On Thu, Apr 07, 2011 at 02:34:27PM +0200, Benny Lofgren wrote: On 2011-04-07 11.08, Otto Moerbeek wrote: Hi, I got little feedeback on this diff posed in a rather long thread, so I am posting it again. Please test this, it makes fsck_ffs much faster (especially with -p) and less memory hungry in a lot of cases. I've run it on a variety of file systems now and first of all, it seems to work without regressions. It also looks like it has about 2/3 of its previous memory footprint. However, I see very little increase in speed: Were your filesystems mounted with softdep? Also, the most gain is realized with ffs1 filesystems. Apart from the / file system they had been mounted with softdep, yes. However they were of course unmounted when I ran fsck_ffs. Does softdep actually alter the physical file system structure on disk? I have always been under the impression that softdep affects stuff like how things are buffered and the order of which things are written to disk rather than *what* is written, am I mistaken? softdep does not change the layout. But only filesystems which were mounted with softdep get this optimization. There's a flag in teh superblock to signal that. Filesystem mounted with softdep have better guarantees about the cylinder group headers being consistent. -Otto And yes, they were all ffs1 filesystems. I have a 13 TB ffs2 file system on that machine as well, didn't try that now because I wanted to fire off a quick reply to your request for testing, and also you mentioned that ffs2 is less (if at all) affected by this patch. I'll be glad to run a test against that volume as well, if you think there's an interest. Expect about 50 minutes a run for one pass with the old and one pass with the new code though. :-) Regards, /Benny Unpatched, run with time /sbin/fsck_ffs -pf /dev/rraid0[adefghi]: [snip] 1m20.35s real 0m2.57s user 0m4.29s system Patched, run with time /root/fsck_ffs -pf /dev/rraid0[adefghi]: [snip] 1m18.52s real 0m1.32s user 0m3.85s system The file systems are organized like this: skynet:~/fsck_ffs_patch# dumpfs -m /dev/rraid0a # newfs command for /dev/rraid0a newfs -O 1 -b 16384 -e 4096 -f 2048 -g 16384 -h 64 -m 5 -o time -s 525856 /dev/rraid0a skynet:~/fsck_ffs_patch# dumpfs -m /dev/rraid0d # newfs command for /dev/rraid0d newfs -O 1 -b 16384 -e 4096 -f 2048 -g 16384 -h 64 -m 5 -o time -s 4197120 /dev/rraid0d skynet:~/fsck_ffs_patch# dumpfs -m /dev/rraid0e # newfs command for /dev/rraid0e newfs -O 1 -b 16384 -e 4096 -f 2048 -g 16384 -h 64 -m 5 -o time -s 8390400 /dev/rraid0e skynet:~/fsck_ffs_patch# dumpfs -m /dev/rraid0f # newfs command for /dev/rraid0f newfs -O 1 -b 16384 -e 4096 -f 2048 -g 16384 -h 64 -m 5 -o time -s 16780800 /dev/rraid0f skynet:~/fsck_ffs_patch# dumpfs -m /dev/rraid0g # newfs command for /dev/rraid0g newfs -O 1 -b 16384 -e 4096 -f 2048 -g 16384 -h 64 -m 5 -o time -s 41944320 /dev/rraid0g skynet:~/fsck_ffs_patch# dumpfs -m /dev/rraid0h # newfs command for /dev/rraid0h newfs -O 1 -b 16384 -e 4096 -f 2048 -g 16384 -h 64 -m 5 -o time -s 12583680 /dev/rraid0h skynet:~/fsck_ffs_patch# dumpfs -m /dev/rraid0i # newfs command for /dev/rraid0i newfs -O 1 -b 16384 -e 4096 -f 2048 -g 16384 -h 64 -m 5 -o time -s 7857920 /dev/rraid0i skynet:~/fsck_ffs_patch# Btw, I noticed a small change in this diff compared to the one you posted in the previous discussion thread. I assume this is the correct one to use? Yes, though that's the most recent version. -Otto skynet:~# diff fsck_ffs.patch fsck_ffs_2.patch 158c158 +++ inode.c 31 Mar 2011 16:34:27 - --- +++ inode.c 4 Apr 2011 09:16:36 - 203c203 + info[i].ino_state = USTATE; --- + SET_ISTATE(i, USTATE); Regards, /Benny -- internetlabbet.se / work: +46 8 551 124 80 / Words must Benny L?fgren/ mobile: +46 70 718 11 90 / be weighed, / fax:+46 8 551 124 89/not counted. /email: benny -at- internetlabbet.se
interleaved+mirrored ccd bugfix
Revision 1.58 of ccd.c (a mere six years ago...) introduced an
unintialized variable usage, in the case of an interleaved and mirrored
ccd; read access could favor the mirror instead of the main ccd by
incorrectly considering the main ccd is in the failure state.
The following diff ought to fix this.
Index: dev/ccd.c
===
RCS file: /cvs/src/sys/dev/ccd.c,v
retrieving revision 1.92
diff -u -p -r1.92 ccd.c
--- dev/ccd.c 22 Sep 2010 01:18:57 - 1.92
+++ dev/ccd.c 7 Apr 2011 15:32:52 -
@@ -795,6 +795,7 @@ ccdbuffer(struct ccd_softc *cs, struct b
ccdisk = ii-ii_index[off % ii-ii_ndisk];
cbn = ii-ii_startoff + off / ii-ii_ndisk;
}
+ ci = cs-sc_cinfo[ccdisk];
if (cs-sc_cflags CCDF_MIRROR) {
/* Mirrored data */
ccdisk2 = ccdisk + ii-ii_ndisk;
@@ -803,11 +804,12 @@ ccdbuffer(struct ccd_softc *cs, struct b
if (bp-b_flags B_READ
bcount bp-b_bcount / 2
(!(ci2-ci_flags CCIF_FAILED) ||
- ci-ci_flags CCIF_FAILED))
+ ci-ci_flags CCIF_FAILED)) {
ccdisk = ccdisk2;
+ ci = ci2;
+ }
}
cbn *= cs-sc_ileave;
- ci = cs-sc_cinfo[ccdisk];
CCD_DPRINTF(CCDB_IO, (ccdisk %d cbn %lld ci %p ci2 %p\n,
ccdisk, cbn, ci, ci2));
}
Re: fsck_ffs diff needs testing
On Thu, Apr 07, 2011 at 11:05:42AM -0500, Amit Kulkarni wrote: Also, depending on the usage patterns, you might have a fs where high numbered inodes are used, while the fs itself is pretty empty. Filling up a fs with lots of files and them removing a lot of them is an example that could lead to such a situation. This diff does not speed things up in such cases. ...might have an impact in my case, since I often do things like rebuilding the system including tons of packages on this machine, and that use case of course perfectly matches what you say above. I think I'll remake these file systems and run the test again just to satisfy my curiosity. But that'll have to wait until after dinner. :-) Anyway, I see improvements both in memory usage and in speed, and I see no obvoius malfunctions, so I'd say it's a go. Hi Otto, Comparing your diff with FreeBSD svn (not cvs, they dropped cvs! my bad on the initial comment) after Benny pointed this out. http://svn.freebsd.org/viewvc/base/head/sbin/fsck_ffs/pass1.c?revision=201708view=markup Look at this comment inside the file /* * This optimization speeds up future runs of fsck * by trimming down the number of inodes in cylinder * groups that formerly had many inodes but now have * fewer in use. */ and the commit entry by McKusick for rev 188110 Update the actions previously attempted by the -D option to make them robust. With these changes fsck is now able to detect and reliably rebuild corrupted cylinder group maps. The -D option is no longer necessary as it has been replaced by a prompt asking whether the corrupted cylinder group should be rebuilt and doing so when requested. These actions are only offered and taken when running fsck in manual mode. Corrupted cylinder groups found during preen mode cause the fsck to fail. Add the -r option to free up excess unused inodes. Decreasing the number of preallocated inodes reduces the running time of future runs of fsck and frees up space that can allocated to files. The -r option is ignored when running in preen mode. -- Will you please please please integrate that part of the code too!!! This is absolutely useful to have and is a fairly common situation. It will make fsck better and be a good way to partially defrag your fs. Or did you plan to keep that for later after more testing on this diff? Thanks, amit Yes, I go step by step. -Otto
Re: fsck_ffs diff needs testing
Also, depending on the usage patterns, you might have a fs where high numbered inodes are used, while the fs itself is pretty empty. Filling up a fs with lots of files and them removing a lot of them is an example that could lead to such a situation. This diff does not speed things up in such cases. ...might have an impact in my case, since I often do things like rebuilding the system including tons of packages on this machine, and that use case of course perfectly matches what you say above. I think I'll remake these file systems and run the test again just to satisfy my curiosity. But that'll have to wait until after dinner. :-) Anyway, I see improvements both in memory usage and in speed, and I see no obvoius malfunctions, so I'd say it's a go. Hi Otto, Comparing your diff with FreeBSD svn (not cvs, they dropped cvs! my bad on the initial comment) after Benny pointed this out. http://svn.freebsd.org/viewvc/base/head/sbin/fsck_ffs/pass1.c?revision=201708view=markup Look at this comment inside the file /* * This optimization speeds up future runs of fsck * by trimming down the number of inodes in cylinder * groups that formerly had many inodes but now have * fewer in use. */ and the commit entry by McKusick for rev 188110 Update the actions previously attempted by the -D option to make them robust. With these changes fsck is now able to detect and reliably rebuild corrupted cylinder group maps. The -D option is no longer necessary as it has been replaced by a prompt asking whether the corrupted cylinder group should be rebuilt and doing so when requested. These actions are only offered and taken when running fsck in manual mode. Corrupted cylinder groups found during preen mode cause the fsck to fail. Add the -r option to free up excess unused inodes. Decreasing the number of preallocated inodes reduces the running time of future runs of fsck and frees up space that can allocated to files. The -r option is ignored when running in preen mode. -- Will you please please please integrate that part of the code too!!! This is absolutely useful to have and is a fairly common situation. It will make fsck better and be a good way to partially defrag your fs. Or did you plan to keep that for later after more testing on this diff? Thanks, amit
Re: bridge ip chsum handling
On 3 April 2011 14:22, Henning Brauer henn...@openbsd.org wrote:
so we have to special case the bridge in teh stack because it doesn't
behave wrt ip checksums (yes yes, all hail layer violations).
so make the bridge behave by always peeking into the ip header, and
not just when we have a kernel with pf compiled in (aka no change
really) and apply the same cksum treatment as in ip_output. as a bonus
this makes us use hardware checksumming where available.
there is anoteh rspecial casing in pf that can also be killed by i
already have too many pf Ms, thus - later.
needs heavy testing by bridge users.
Index: net/if_bridge.c
===
RCS file: /cvs/src/sys/net/if_bridge.c,v
retrieving revision 1.188
diff -u -p -r1.188 if_bridge.c
--- net/if_bridge.c 4 Nov 2010 23:07:15 - 1.188
+++ net/if_bridge.c 3 Apr 2011 16:56:22 -
@@ -68,7 +68,6 @@
#ifdef IPSEC
#include netinet/ip_ipsp.h
-
#include net/if_enc.h
#endif
@@ -148,10 +147,8 @@ intbridge_flushrule(struct bridge_ifli
intbridge_brlconf(struct bridge_softc *, struct ifbrlconf *);
u_int8_t bridge_filterrule(struct brl_head *, struct ether_header *,
struct mbuf *);
-#if NPF 0
-struct mbuf *bridge_filter(struct bridge_softc *, int, struct ifnet *,
+struct mbuf *bridge_ip(struct bridge_softc *, int, struct ifnet *,
struct ether_header *, struct mbuf *m);
-#endif
intbridge_ifenqueue(struct bridge_softc *, struct ifnet *, struct mbuf
*);
void bridge_fragment(struct bridge_softc *, struct ifnet *,
struct ether_header *, struct mbuf *);
@@ -1065,9 +1062,8 @@ bridge_output(struct ifnet *ifp, struct
}
#endif /* IPSEC */
- /* Catch packets that need TCP/UDP/IP hardware checksumming
*/
- if (m-m_pkthdr.csum_flags M_IPV4_CSUM_OUT ||
- m-m_pkthdr.csum_flags M_TCPV4_CSUM_OUT ||
+ /* Catch packets that need TCP/UDP hardware checksumming */
+ if (m-m_pkthdr.csum_flags M_TCPV4_CSUM_OUT ||
m-m_pkthdr.csum_flags M_UDPV4_CSUM_OUT) {
m_freem(m);
splx(s);
@@ -1308,11 +1304,9 @@ bridgeintr_frame(struct bridge_softc *sc
m_freem(m);
return;
}
-#if NPF 0
- m = bridge_filter(sc, BRIDGE_IN, src_if, eh, m);
+ m = bridge_ip(sc, BRIDGE_IN, src_if, eh, m);
if (m == NULL)
return;
-#endif
/*
* If the packet is a multicast or broadcast OR if we don't
* know any better, forward it to all interfaces.
@@ -1350,11 +1344,9 @@ bridgeintr_frame(struct bridge_softc *sc
m_freem(m);
return;
}
-#if NPF 0
- m = bridge_filter(sc, BRIDGE_OUT, dst_if, eh, m);
+ m = bridge_ip(sc, BRIDGE_OUT, dst_if, eh, m);
if (m == NULL)
return;
-#endif
len = m-m_pkthdr.len;
#if NVLAN 0
@@ -1656,11 +1648,9 @@ bridge_broadcast(struct bridge_softc *sc
mc = m1;
}
-#if NPF 0
- mc = bridge_filter(sc, BRIDGE_OUT, dst_if, eh, mc);
+ mc = bridge_ip(sc, BRIDGE_OUT, dst_if, eh, mc);
if (mc == NULL)
continue;
-#endif
len = mc-m_pkthdr.len;
#if NVLAN 0
@@ -2506,7 +2496,6 @@ bridge_ipsec(struct bridge_softc *sc, st
}
#endif /* IPSEC */
-#if NPF 0
/*
* Filter IP packets by peeking into the ethernet frame. This violates
* the ISO model, but allows us to act as a IP filter at the data link
@@ -2514,7 +2503,7 @@ bridge_ipsec(struct bridge_softc *sc, st
* who've read net/if_ethersubr.c and netinet/ip_input.c
*/
struct mbuf *
-bridge_filter(struct bridge_softc *sc, int dir, struct ifnet *ifp,
+bridge_ip(struct bridge_softc *sc, int dir, struct ifnet *ifp,
struct ether_header *eh, struct mbuf *m)
{
struct llc llc;
@@ -2590,9 +2579,20 @@ bridge_filter(struct bridge_softc *sc, i
ip = mtod(m, struct ip *);
}
- if ((ip-ip_sum = in_cksum(m, hlen)) != 0) {
- ipstat.ips_badsum++;
- goto dropit;
+ if ((m-m_pkthdr.csum_flags M_IPV4_CSUM_IN_OK) == 0) {
+ if (m-m_pkthdr.csum_flags M_IPV4_CSUM_IN_BAD) {
+ ipstat.ips_inhwcsum++;
+ ipstat.ips_badsum++;
+ goto dropit;
+ }
+
+ if (in_cksum(m, hlen) != 0) {
+ ipstat.ips_badsum++;
+ goto dropit;
+ }
+ } else {
+ m-m_pkthdr.csum_flags = ~M_IPV4_CSUM_IN_OK;
+ ipstat.ips_inhwcsum++;
}
ftp-proxy: use divert-to instead of rdr-to
this allows us to get rid of the nasty NATLOOKUP ioctl and get
the original server address right from the socket. also this
paves the way to the transparent ftp-proxy mode.
if you will like this diff and nobody objects, i'll try to rip
NATLOOKUP out from the other places too.
note, that it requires you to change your rdr-to rule to do
divert:
-pass in quick proto tcp to port ftp rdr-to 127.0.0.1 port 8021
+pass in quick proto tcp to port ftp divert-to 127.0.0.1 port 8021
Index: filter.c
===
RCS file: /home/cvs/src/usr.sbin/ftp-proxy/filter.c,v
retrieving revision 1.14
diff -u -p -r1.14 filter.c
--- filter.c25 Mar 2011 14:51:31 - 1.14
+++ filter.c7 Apr 2011 16:31:30 -
@@ -42,10 +42,6 @@
int add_addr(struct sockaddr *, struct pf_pool *);
int prepare_rule(u_int32_t, struct sockaddr *, struct sockaddr *,
u_int16_t);
-int server_lookup4(struct sockaddr_in *, struct sockaddr_in *,
-struct sockaddr_in *, int *);
-int server_lookup6(struct sockaddr_in6 *, struct sockaddr_in6 *,
-struct sockaddr_in6 *, int *);
static struct pfioc_rule pfr;
static struct pfioc_trans pft;
@@ -252,82 +248,6 @@ prepare_rule(u_int32_t id, struct sockad
strlcpy(pfr.rule.tagname, tagname,
sizeof pfr.rule.tagname);
}
-
- return (0);
-}
-
-int
-server_lookup(struct sockaddr *client, struct sockaddr *proxy,
-struct sockaddr *server, int *cdomain)
-{
- if (client-sa_family == AF_INET)
- return (server_lookup4(satosin(client), satosin(proxy),
- satosin(server), cdomain));
-
- if (client-sa_family == AF_INET6)
- return (server_lookup6(satosin6(client), satosin6(proxy),
- satosin6(server), cdomain));
-
- errno = EPROTONOSUPPORT;
- return (-1);
-}
-
-int
-server_lookup4(struct sockaddr_in *client, struct sockaddr_in *proxy,
-struct sockaddr_in *server, int *cdomain)
-{
- struct pfioc_natlook pnl;
-
- memset(pnl, 0, sizeof pnl);
- pnl.direction = PF_OUT;
- pnl.af = AF_INET;
- pnl.proto = IPPROTO_TCP;
- pnl.rdomain = getrtable();
- memcpy(pnl.saddr.v4, client-sin_addr.s_addr, sizeof pnl.saddr.v4);
- memcpy(pnl.daddr.v4, proxy-sin_addr.s_addr, sizeof pnl.daddr.v4);
- pnl.sport = client-sin_port;
- pnl.dport = proxy-sin_port;
-
- if (ioctl(dev, DIOCNATLOOK, pnl) == -1)
- return (-1);
-
- memset(server, 0, sizeof(struct sockaddr_in));
- server-sin_len = sizeof(struct sockaddr_in);
- server-sin_family = AF_INET;
- memcpy(server-sin_addr.s_addr, pnl.rdaddr.v4,
- sizeof server-sin_addr.s_addr);
- server-sin_port = pnl.rdport;
- *cdomain = pnl.rrdomain;
-
- return (0);
-}
-
-int
-server_lookup6(struct sockaddr_in6 *client, struct sockaddr_in6 *proxy,
-struct sockaddr_in6 *server, int *cdomain)
-{
- struct pfioc_natlook pnl;
-
- memset(pnl, 0, sizeof pnl);
- pnl.direction = PF_OUT;
- pnl.af = AF_INET6;
- pnl.proto = IPPROTO_TCP;
- pnl.rdomain = getrtable();
- memcpy(pnl.saddr.v6, client-sin6_addr.s6_addr, sizeof pnl.saddr.v6);
- memcpy(pnl.daddr.v6, proxy-sin6_addr.s6_addr, sizeof pnl.daddr.v6);
- pnl.sport = client-sin6_port;
- pnl.dport = proxy-sin6_port;
-
- if (ioctl(dev, DIOCNATLOOK, pnl) == -1)
- return (-1);
-
- memset(server, 0, sizeof(struct sockaddr_in6));
- server-sin6_len = sizeof(struct sockaddr_in6);
- server-sin6_family = AF_INET6;
- memcpy(server-sin6_addr.s6_addr, pnl.rdaddr.v6,
- sizeof server-sin6_addr);
- server-sin6_port = pnl.rdport;
- *cdomain = pnl.rrdomain;
return (0);
}
Index: filter.h
===
RCS file: /home/cvs/src/usr.sbin/ftp-proxy/filter.h,v
retrieving revision 1.6
diff -u -p -r1.6 filter.h
--- filter.h25 Mar 2011 14:51:31 - 1.6
+++ filter.h7 Apr 2011 16:31:38 -
@@ -26,5 +26,3 @@ int do_commit(void);
int do_rollback(void);
void init_filter(char *, char *, int);
int prepare_commit(u_int32_t);
-int server_lookup(struct sockaddr *, struct sockaddr *, struct sockaddr *,
-int *);
Index: ftp-proxy.8
===
RCS file: /home/cvs/src/usr.sbin/ftp-proxy/ftp-proxy.8,v
retrieving revision 1.14
diff -u -p -r1.14 ftp-proxy.8
--- ftp-proxy.8 21 Nov 2009 13:59:31 - 1.14
+++ ftp-proxy.8 7 Apr 2011 16:49:56 -
@@ -40,7 +40,7 @@
is a proxy for the Internet File Transfer Protocol.
FTP control connections should be redirected into the proxy using the
.Xr pf 4
-.Ar rdr-to
+.Ar divert-to
command, after which the proxy connects to the server on behalf of
the client.
.Pp
@@ -169,7 +169,7 @@ needs the following rules.
Re: fsck_ffs diff needs testing
Thanks! I understand. On Thu, Apr 7, 2011 at 11:09 AM, Otto Moerbeek o...@drijf.net wrote: On Thu, Apr 07, 2011 at 11:05:42AM -0500, Amit Kulkarni wrote: Also, depending on the usage patterns, you might have a fs where high numbered inodes are used, while the fs itself is pretty empty. Filling up a fs with lots of files and them removing a lot of them is an example that could lead to such a situation. This diff does not speed things up in such cases. ...might have an impact in my case, since I often do things like rebuilding the system including tons of packages on this machine, and that use case of course perfectly matches what you say above. I think I'll remake these file systems and run the test again just to satisfy my curiosity. But that'll have to wait until after dinner. :-) Anyway, I see improvements both in memory usage and in speed, and I see no obvoius malfunctions, so I'd say it's a go. Hi Otto, Comparing your diff with FreeBSD svn (not cvs, they dropped cvs! my bad on the initial comment) after Benny pointed this out. http://svn.freebsd.org/viewvc/base/head/sbin/fsck_ffs/pass1.c?revision=201708 view=markup Look at this comment inside the file /* * This optimization speeds up future runs of fsck * by trimming down the number of inodes in cylinder * groups that formerly had many inodes but now have * fewer in use. */ and the commit entry by McKusick for rev 188110 Update the actions previously attempted by the -D option to make them robust. With these changes fsck is now able to detect and reliably rebuild corrupted cylinder group maps. The -D option is no longer necessary as it has been replaced by a prompt asking whether the corrupted cylinder group should be rebuilt and doing so when requested. These actions are only offered and taken when running fsck in manual mode. Corrupted cylinder groups found during preen mode cause the fsck to fail. Add the -r option to free up excess unused inodes. Decreasing the number of preallocated inodes reduces the running time of future runs of fsck and frees up space that can allocated to files. The -r option is ignored when running in preen mode. -- Will you please please please integrate that part of the code too!!! This is absolutely useful to have and is a fairly common situation. It will make fsck better and be a good way to partially defrag your fs. Or did you plan to keep that for later after more testing on this diff? Thanks, amit Yes, I go step by step. -Otto
Possible PF bug with block and reply-to
Hello, sorry for the long text, but I try to be thorough with the description. I have a router which connects to another machine using a Layer 2 VPN. When that connection is active, a new default route with higher (actually its numerically lower) priority is added, to overwrite the old one. Destination Gateway Flags RefsUse Mtu Prio Iface default 172.16.94.113UG 2482 -32 tun0 default 217.0.116.247UGS 20203 -48 pppoe0 For incoming connections on pppoe0 I am using reply-to, so the packets go back out where they came in. That works really good. Now, in the pf.conf I am setting set block-policy return, just to be nice and to allow for easier debugging. The problem here is, that with just having a block log at the beginning of the ruleset, those ICMP and TCP resets are being sent out using tun0 instead of pppoe0. I didn't see that at first but I guess it is to be expected. Now I added a block in log on $ext_if inet reply-to ( ... ) rule, but it seems, that the reply-to part is getting ignored here. The resets packets still go out using the tun0 interface. Unfortunately it also isn't possible to use reply-to with match rules. Sadly I just have some very basic C skills, meaning that all the PF stuff is way over my head. I hope that someone help me here. ;-) If you want to see my /etc/pf.conf, I'll send it off list. Regards, Michael Lechtermann # dmesg OpenBSD 4.9 (GENERIC) #671: Wed Mar 2 07:09:00 MST 2011 dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC cpu0: Geode(TM) Integrated Processor by AMD PCS (AuthenticAMD 586-class) 499 MHz cpu0: FPU,DE,PSE,TSC,MSR,CX8,SEP,PGE,CMOV,CFLUSH,MMX real mem = 268009472 (255MB) avail mem = 253493248 (241MB) mainbus0 at root bios0 at mainbus0: AT/286+ BIOS, date 12/10/07, BIOS32 rev. 0 @ 0xfceb2 pcibios0 at bios0: rev 2.1 @ 0xf/0x1 pcibios0: pcibios_get_intr_routing - function not supported pcibios0: PCI IRQ Routing information unavailable. pcibios0: PCI bus #0 is the last bus bios0: ROM list: 0xe/0xa800 cpu0 at mainbus0: (uniprocessor) pci0 at mainbus0 bus 0: configuration mode 1 (bios) pchb0 at pci0 dev 1 function 0 AMD Geode LX rev 0x31 glxsb0 at pci0 dev 1 function 2 AMD Geode LX Crypto rev 0x00: RNG AES vr0 at pci0 dev 9 function 0 VIA VT6105M RhineIII rev 0x96: irq 10, address 00:0d:b9:12:73:54 ukphy0 at vr0 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI 0x004063, model 0x0034 vr1 at pci0 dev 10 function 0 VIA VT6105M RhineIII rev 0x96: irq 11, address 00:0d:b9:12:73:55 ukphy1 at vr1 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI 0x004063, model 0x0034 vr2 at pci0 dev 11 function 0 VIA VT6105M RhineIII rev 0x96: irq 12, address 00:0d:b9:12:73:56 ukphy2 at vr2 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI 0x004063, model 0x0034 glxpcib0 at pci0 dev 15 function 0 AMD CS5536 ISA rev 0x03: rev 3, 32-bit 3579545Hz timer, watchdog, gpio gpio0 at glxpcib0: 32 pins pciide0 at pci0 dev 15 function 2 AMD CS5536 IDE rev 0x01: DMA, channel 0 wired to compatibility, channel 1 wired to compatibility wd0 at pciide0 channel 0 drive 0: TRANSCEND wd0: 1-sector PIO, LBA, 971MB, 1989792 sectors wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 4 pciide0: channel 1 ignored (disabled) ohci0 at pci0 dev 15 function 4 AMD CS5536 USB rev 0x02: irq 15, version 1.0, legacy support ehci0 at pci0 dev 15 function 5 AMD CS5536 USB rev 0x02: irq 15 usb0 at ehci0: USB revision 2.0 uhub0 at usb0 AMD EHCI root hub rev 2.00/1.00 addr 1 isa0 at glxpcib0 isadma0 at isa0 com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo com0: console pcppi0 at isa0 port 0x61 spkr0 at pcppi0 npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16 usb1 at ohci0: USB revision 1.0 uhub1 at usb1 AMD OHCI root hub rev 1.00/1.00 addr 1 biomask e3ef netmask ffef ttymask mtrr: K6-family MTRR support (2 registers) nvram: invalid checksum vscsi0 at root scsibus0 at vscsi0: 256 targets softraid0 at root root on wd0a swap on wd0b dump on wd0b clock: unknown CMOS layout gpioow0 at gpio0: DATA[4] open-drain pull-up onewire0 at gpioow0
Modele su cuerpo sin esfuerzos y comodamente
Abtronic X2 $ 130 Balanza digital $ 65 Elecroestimulador Etong $ 170
Re: http gzip support for ftp
On 2011/04/07 15:03, Martynas Venckus wrote: As much as I like it, I'm not sure we'll be able to enable this by default, though. There are quite some misconfigured servers out there, like: http://elinks.cz/download/elinks-0.11.7.tar.gz This one incorrectly sends: Content-Encoding: gzip While it doesn't actually compress it (twice). So the client decompresses it, and you end up actually having decompressed TAR called 'elinks-0.11.7.tar.gz'. yes, this causes a big problem for ports distfile fetching.
-current kernel freeze
Hi, upgrading GENERIC kernel from snapshot 24-Mar-2011 to -current results in system freezes after some minutes (up to some hours) without any error message, here: OpenBSD 4.9-current (GENERIC) #1: Fri Apr 8 02:20:49 CEST 2011 root@[...]:/usr/src/sys/arch/i386/compile/GENERIC cpu0: Intel(R) Xeon(TM) CPU 3.00GHz (GenuineIntel 686-class) 3.01 GHz cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLU SH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,CNXT-ID,CX16,xT PR real mem = 1073258496 (1023MB) avail mem = 1045561344 (997MB) mainbus0 at root bios0 at mainbus0: AT/286+ BIOS, date 12/31/99, BIOS32 rev. 0 @ 0xf, SMBIOS rev. 2.3 @ 0xec000 (77 entries) bios0: vendor HP version P51 date 04/26/2006 bios0: HP ProLiant DL380 G4 acpi0 at bios0: rev 2 acpi0: sleep states S0 S4 S5 acpi0: tables DSDT FACP SPCR MCFG APIC acpi0: wakeup devices acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimcfg0 at acpi0 addr 0xe000, bus 0-255 acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: apic clock running at 200MHz cpu at mainbus0: not configured ioapic0 at mainbus0: apid 8 pa 0xfec0, version 20, 24 pins ioapic1 at mainbus0: apid 9 pa 0xfec8, version 20, 24 pins ioapic2 at mainbus0: apid 10 pa 0xfec80400, version 20, 24 pins ioapic3 at mainbus0: apid 11 pa 0xfec84000, version 20, 24 pins ioapic4 at mainbus0: apid 12 pa 0xfec84400, version 20, 24 pins acpiprt0 at acpi0: bus 1 (IP2P) acpiprt1 at acpi0: bus 3 (PCXA) acpiprt2 at acpi0: bus 4 (PCXB) acpiprt3 at acpi0: bus 2 (PTA0) acpiprt4 at acpi0: bus 6 (PCXC) acpiprt5 at acpi0: bus 10 (PCXD) acpiprt6 at acpi0: bus 5 (PTC0) acpiprt7 at acpi0: bus 0 (PCI0) acpicpu0 at acpi0 acpitz0 at acpi0: critical temperature 31 degC bios0: ROM list: 0xc/0x8000 0xc8000/0x4000! 0xcc000/0x1600 0xee000/0x2000! pci0 at mainbus0 bus 0: configuration mode 1 (bios) bridge io address conflict 0x1000/0x3000 pchb0 at pci0 dev 0 function 0 Intel E7520 Host rev 0x0c ppb0 at pci0 dev 2 function 0 Intel E7520 PCIE rev 0x0c pci1 at ppb0 bus 2 ppb1 at pci1 dev 0 function 0 Intel PCIE-PCIE rev 0x09 pci2 at ppb1 bus 3 bge0 at pci2 dev 1 function 0 Broadcom BCM5704C rev 0x10, BCM5704 B0 (0x2100): apic 9 int 1 (irq 5), address 00:18:fe:72:82:73 brgphy0 at bge0 phy 1: BCM5704 10/100/1000baseT PHY, rev. 0 bge1 at pci2 dev 1 function 1 Broadcom BCM5704C rev 0x10, BCM5704 B0 (0x2100): apic 9 int 2 (irq 5), address 00:18:fe:72:82:72 brgphy1 at bge1 phy 1: BCM5704 10/100/1000baseT PHY, rev. 0 ppb2 at pci1 dev 0 function 2 Intel PCIE-PCIE rev 0x09 pci3 at ppb2 bus 4 ciss0 at pci3 dev 3 function 0 Compaq Smart Array 64xx rev 0x01: apic 10 int 3 (irq 5) ciss0: 1 LD, HW rev 1, FW 2.76/2.76, 64bit fifo scsibus0 at ciss0: 1 targets sd0 at scsibus0 targ 0 lun 0: HP, LOGICAL VOLUME, 2.76 SCSI3 0/direct fixed sd0: 69459MB, 512 bytes/sec, 142253280 sec total ppb3 at pci0 dev 6 function 0 Intel E7520 PCIE rev 0x0c: apic 8 int 16 (irq 255) pci4 at ppb3 bus 5 ppb4 at pci4 dev 0 function 0 Intel PCIE-PCIE rev 0x09 pci5 at ppb4 bus 6 em0 at pci5 dev 1 function 0 Intel PRO/1000MT (82546GB) rev 0x03: apic 11 int 2 (irq 5), address 00:04:23:d6:cc:40 em1 at pci5 dev 1 function 1 Intel PRO/1000MT (82546GB) rev 0x03: apic 11 int 1 (irq 5), address 00:04:23:d6:cc:41 ppb5 at pci4 dev 0 function 2 Intel PCIE-PCIE rev 0x09 pci6 at ppb5 bus 10 em2 at pci6 dev 1 function 0 Intel PRO/1000MT (82546GB) rev 0x03: apic 12 int 1 (irq 5), address 00:04:23:ce:cb:74 em3 at pci6 dev 1 function 1 Intel PRO/1000MT (82546GB) rev 0x03: apic 12 int 2 (irq 5), address 00:04:23:ce:cb:75 uhci0 at pci0 dev 29 function 0 Intel 82801EB/ER USB rev 0x02: apic 8 int 16 (irq 5) uhci1 at pci0 dev 29 function 1 Intel 82801EB/ER USB rev 0x02: apic 8 int 19 (irq 5) uhci2 at pci0 dev 29 function 2 Intel 82801EB/ER USB rev 0x02: apic 8 int 18 (irq 5) uhci3 at pci0 dev 29 function 3 Intel 82801EB/ER USB rev 0x02: apic 8 int 16 (irq 5) ehci0 at pci0 dev 29 function 7 Intel 82801EB/ER USB2 rev 0x02: apic 8 int 23 (irq 5) usb0 at ehci0: USB revision 2.0 uhub0 at usb0 Intel EHCI root hub rev 2.00/1.00 addr 1 ppb6 at pci0 dev 30 function 0 Intel 82801BA Hub-to-PCI rev 0xc2 pci7 at ppb6 bus 1 vga1 at pci7 dev 3 function 0 ATI Rage XL rev 0x27 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) wsdisplay0: screen 1-5 added (80x25, vt100 emulation) Compaq iLO rev 0x01 at pci7 dev 4 function 0 not configured Compaq iLO rev 0x01 at pci7 dev 4 function 2 not configured ichpcib0 at pci0 dev 31 function 0 Intel 82801EB/ER LPC rev 0x02 pciide0 at pci0 dev 31 function 1 Intel 82801EB/ER IDE rev 0x02: DMA, channel 0 configured to compatibility, channel 1 configured to compatibility atapiscsi0 at pciide0 channel 0 drive 0 scsibus1 at atapiscsi0: 2 targets cd0 at scsibus1 targ 0 lun 0: TSSTcorp, CD-ROM TS-L162C, N204 ATAPI 5/cdrom removable cd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 2 pciide0: channel 1 disabled (no drives) usb1 at uhci0: USB revision 1.0 uhub1 at usb1
Re: -current kernel freeze
On Fri, 8 Apr 2011 02:33:51 +0200, Florian Fuessl wrote: upgrading GENERIC kernel from snapshot 24-Mar-2011 to -current results in system freezes after some minutes (up to some hours) without any error message, here: OpenBSD 4.9-current (GENERIC) #1: Fri Apr 8 02:20:49 CEST 2011 root@[...]:/usr/src/sys/arch/i386/compile/GENERIC cpu0: Intel(R) Xeon(TM) CPU 3.00GHz (GenuineIntel 686-class) 3.01 GHz cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLU SH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,CNXT-ID,CX16,xT PR 8snip In case it is useful here is a close relative. Mine was based on same snap but cvs updated compiled a couple of days later: OpenBSD 4.9-current (GENERIC) #0: Mon Apr 4 13:35:18 EST 2011 r...@nero.witworx.com:/usr/src/sys/arch/i386/compile/GENERIC cpu0: Intel(R) Celeron(R) D CPU 3.20GHz (GenuineIntel 686-class) 3.21 GHz cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36, CFLUSH,DS,A CPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,CNXT-ID,CX16,xTPR, PDCM real mem = 1063305216 (1014MB) Slightly different hardware but running fine as of today. HTH, *** NOTE *** Please DO NOT CC me. I am subscribed to the list. Mail to the sender address that does not originate at the list server is tarpitted. The reply-to: address is provided for those who feel compelled to reply off list. Thankyou. Rod/ --- This life is not the real thing. It is not even in Beta. If it was, then OpenBSD would already have a man page for it.
Compactas Digitales Importadas
Consulte por otros modelos de caacute;maras y filmadoras compactas Nikon, Canon, Panasonic, Sony, JVC USD211 Sony DSC-W330 Caacute;mara digital compacta, sin visor / Sensor SuperHAD de 14,10 MP efectivos / Objetivo (en 35 mm) 26,0 - 105,0 mm / Zoom 4x (oacute;ptico) / Soportes compatibles SD Card, MemoryStick Duo, MemoryStick Pro Duo, MemoryStick Pro-HG Duo, microSDHC, MemoryStick Pro Duo High Speed / Pantalla TFT de 3,00 pulgadas USD220 Sony DSC-W350 Caacute;mara digital compacta, sin visor / Sensor SuperHAD de 14,10 MP efectivos Objetivo (en 35 mm) 26,0 - 105,0 mm / Zoom 4x (oacute;ptico) / Soportes compatibles SD Card, MemoryStick Duo, MemoryStick Pro Duo, SDHC, MemoryStick Pro-HG Duo, MemoryStick Pro Duo High Speed / Pantalla TFT de 2,70 pulgadas Sony DSC-HX1 USD 495 Canon SX130 IS USD 279 Panasonic TZ10/ZS7 USD 369 Nikon L110 USD 345
Re: -current kernel freeze
On 04/07/11 20:33, Florian Fuessl wrote: Hi, upgrading GENERIC kernel from snapshot 24-Mar-2011 to -current results in system freezes after some minutes (up to some hours) without any error message, here: OpenBSD 4.9-current (GENERIC) #1: Fri Apr 8 02:20:49 CEST 2011 root@[...]:/usr/src/sys/arch/i386/compile/GENERIC cpu0: Intel(R) Xeon(TM) CPU 3.00GHz (GenuineIntel 686-class) 3.01 GHz cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLU SH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,CNXT-ID,CX16,xT PR real mem = 1073258496 (1023MB) avail mem = 1045561344 (997MB) [snip] I can confirm this. Twice in the last day or so my package builder has frozen after a few hours. Previously on Wednesday the kernel paniced. OpenBSD 4.9-current (GENERIC.MP) #11: Thu Apr 7 21:29:35 EDT 2011 root@sata6:/usr/src/sys/arch/i386/compile/GENERIC.MP cpu0: Intel(R) Core(TM) i7-2600K CPU @ 3.40GHz (GenuineIntel 686-class) 3.51 GHz cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,PCLMUL,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,AES,XSAVE,AVX real mem = 3209814016 (3061MB) avail mem = 3147149312 (3001MB) mainbus0 at root bios0 at mainbus0: AT/286+ BIOS, date 10/20/10, SMBIOS rev. 2.7 @ 0xead50 (20 entries) bios0: vendor American Megatrends Inc. version 4.6.4 date 02/17/2011 bios0: BIOSTAR Group TP67B+ acpi0 at bios0: rev 2 acpi0: sleep states S0 S1 S4 S5 acpi0: tables DSDT FACP APIC SSDT MCFG HPET ASPT acpi0: wakeup devices PS2K(S1) PS2M(S1) UAR1(S4) BR20(S1) EUSB(S4) USBE(S4) P0P1(S4) P0P2(S4) P0P3(S4) P0P4(S4) PEX0(S4) PEX1(S4) PEX2(S4) PEX3(S4) PEX4(S4) PEX5(S4) PEX6(S4) PEX7(S4) SLPB(S0) PWRB(S4) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: unknown i686 model 0x2a, can't get bus clock (0x0) cpu0: apic clock running at 102MHz cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Core(TM) i7-2600K CPU @ 3.40GHz (GenuineIntel 686-class) 3.51 GHz cpu1: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,PCLMUL,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,AES,XSAVE,AVX cpu2 at mainbus0: apid 4 (application processor) cpu2: Intel(R) Core(TM) i7-2600K CPU @ 3.40GHz (GenuineIntel 686-class) 3.51 GHz cpu2: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,PCLMUL,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,AES,XSAVE,AVX cpu3 at mainbus0: apid 6 (application processor) cpu3: Intel(R) Core(TM) i7-2600K CPU @ 3.40GHz (GenuineIntel 686-class) 3.51 GHz cpu3: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,PCLMUL,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,AES,XSAVE,AVX cpu4 at mainbus0: apid 1 (application processor) cpu4: Intel(R) Core(TM) i7-2600K CPU @ 3.40GHz (GenuineIntel 686-class) 3.51 GHz cpu4: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,PCLMUL,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,AES,XSAVE,AVX cpu5 at mainbus0: apid 3 (application processor) cpu5: Intel(R) Core(TM) i7-2600K CPU @ 3.40GHz (GenuineIntel 686-class) 3.51 GHz cpu5: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,PCLMUL,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,AES,XSAVE,AVX cpu6 at mainbus0: apid 5 (application processor) cpu6: Intel(R) Core(TM) i7-2600K CPU @ 3.40GHz (GenuineIntel 686-class) 3.51 GHz cpu6: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,PCLMUL,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,AES,XSAVE,AVX cpu7 at mainbus0: apid 7 (application processor) cpu7: Intel(R) Core(TM) i7-2600K CPU @ 3.40GHz (GenuineIntel 686-class) 3.51 GHz cpu7: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,PCLMUL,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,AES,XSAVE,AVX ioapic0 at mainbus0: apid 0 pa 0xfec0, version 20, 24 pins acpimcfg0 at acpi0 addr 0xe000, bus 0-255 acpihpet0 at acpi0: 14318179 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 1 (P0P1) acpiprt2 at acpi0: bus -1 (P0P2) acpiprt3 at acpi0: bus -1 (P0P3) acpiprt4 at acpi0: bus -1 (P0P4) acpiprt5 at acpi0: bus 2 (PEX0) acpiprt6 at acpi0: bus 3 (PEX1) acpiprt7 at acpi0: bus 4 (PEX2) acpiprt8 at acpi0: bus -1 (PEX3) acpiprt9 at acpi0: bus -1 (PEX4) acpiprt10 at acpi0: bus -1 (PEX5) acpiprt11 at acpi0: bus -1 (PEX6)
