Re: Nvidia driver
On Oct 02, Daniel O'Connor wrote: My wife's computer did this. In the end I turned down all the knobs I could find (mostly AGP speed stuff). It still dies when trying OpenGL though. hw.nvidia.agp.card.rates: 2x 1x hw.nvidia.agp.card.fw: not supported hw.nvidia.agp.card.sba: supported hw.nvidia.agp.card.registers: 0x1f000203:0x hw.nvidia.agp.status.status: disabled hw.nvidia.agp.status.driver: n/a hw.nvidia.agp.status.rate: n/a hw.nvidia.agp.status.fw: n/a hw.nvidia.agp.status.sba: n/a hw.nvidia.version: NVIDIA FreeBSD x86 nvidia.ko Kernel Module 1.0-3203 Wed Oct 30 06:06:58 PST 2002 hw.nvidia.registry.EnableAGPSBA: 0 hw.nvidia.registry.EnableAGPFW: 0 hw.nvidia.registry.SoftEDIDs: 1 hw.nvidia.registry.Mobile: 4294967295 hw.nvidia.cards.0.model: RIVA TNT2 hw.nvidia.cards.0.irq: 11 hw.nvidia.cards.0.vbios: 02.05.01.00.00 hw.nvidia.cards.0.type: AGP ... Section Device Option NvAgp 0 Identifier Card1 Driver nvidia VendorName NVidia BoardName Riva TNT2 BusID PCI:1:0:0 EndSection ... agp0: VIA 82C8363 (Apollo KT133A) host to PCI bridge mem 0xd000-0xd3ff at device 0.0 on pci0 ... nvidia0: RIVA TNT2 mem 0xd400-0xd5ff,0xd600-0xd6ff irq 11 at device 0.0 on pci1 .. This is a 4.8 system though. How do you turn those down? /boot/loader.conf? I tried saying hw.nvidia.card.rates=2x 1x but that didn't seem to do anything (I have a feeling that putting that in /boot/loader.conf makes no sense...please consider this a desperate cry for help.) Is it a bad sign that my sysctl has some weird values in it? sysctl -a | grep nvidia nvidia2113K 13K 21 16,32,256 hw.nvidia.agp.card.rates: 4x 2x 1x hw.nvidia.agp.card.fw: supported hw.nvidia.agp.card.sba: supported hw.nvidia.agp.card.registers: 0x1f000217:0x0100 hw.nvidia.agp.status.status: disabled hw.nvidia.agp.status.driver: n/a hw.nvidia.agp.status.rate: n/a hw.nvidia.agp.status.fw: n/a hw.nvidia.agp.status.sba: n/a hw.nvidia.version: NVIDIA FreeBSD x86 nvidia.ko Kernel Module 1.0-4365 Wed May 28 09:20:25 PDT 2003 hw.nvidia.registry.EnableVia4x: 0 hw.nvidia.registry.EnableALiAGP: 0 hw.nvidia.registry.EnableAGPSBA: 0 hw.nvidia.registry.EnableAGPFW: 0 hw.nvidia.registry.SoftEDIDs: 1 hw.nvidia.registry.Mobile: 4294967295 hw.nvidia.registry.ResmanDebugLevel: 4294967295 hw.nvidia.registry.FlatPanelMode: 0 hw.nvidia.registry.UpdateKernelAGP: 1 hw.nvidia.cards.0.model: GeForce4 4200 Go hw.nvidia.cards.0.irq: 11 hw.nvidia.cards.0.vbios: ??.??.??.??.?? hw.nvidia.cards.0.type: AGP I have yet to try the posted suggestion of NOT loading agp into the kernel or having it as a module...maybe that's what WITH_FREEBSD_AGP refers to...hm. Thanks, Mike ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problem upgrading 4.8 to 5.1
On Thu, 02 Oct 2003 23:08:53 +0200 John Angelmo [EMAIL PROTECTED] wrote: OK I'm trying to upgrade from 4.8 (pre 4.9) to 5.1 (using the 5_1 tag with cvsup) The problem I get is this: cc -fpic -DPIC -O -pipe -DPTHREAD_KERNEL -I/usr/src/lib/libpthread/../libc/include -I/usr/src/lib/libpthread/thread -I/usr/src/lib/libpthread/../../include -I/usr/src/lib/libpthread/arch/i386/include -I/usr/src/lib/libpthread/sys -I/usr/src/lib/libpthread/../../libexec/rtld-elf -fno-builtin -D_LOCK_DEBUG -D_PTHREADS_INVARIANTS -Wall -c /usr/src/lib/libpthread/sys/lock.c -o lock.So building shared library libkse.so.1 thr_libc.So: In function `sigaction': thr_libc.So(.text+0x54): multiple definition of `_sigaction' thr_sigaction.So(.text+0x0): first defined here thr_libc.So: In function `sigprocmask': thr_libc.So(.text+0x34): multiple definition of `_sigprocmask' thr_sigprocmask.So(.text+0x0): first defined here *** Error code 1 Stop in /usr/src/lib/libpthread. *** Error code 1 Stop in /usr/src/lib. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. Is this a known problem and what can I do about it? /John ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] The problem is known. See the Problem Report bin/53201 http://www.freebsd.org/cgi/query-pr.cgi?pr=bin%2F53201 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: scsi-cd + GEOM
In message [EMAIL PROTECTED], Dan Nelson writes:
Seems like it does, if there is a disc present or the tray is open there
is no delay only with tray closed and no disc inserted.
Maybe this is only an issue with this drive model or at least my
drive...
No, it happens to me too. It looks like cd probing was done
asynchronously until about a week ago, so what used to happen was:
I'm not a SCSI device specialist, and I'm somewhat surprised that
drives should take that long to figure out if they have a media
or not. Comparing to the DA driver, I can see that the CD driver
does not even try to do a TEST UNIT READY before trying to find
the size and that seems like an oversight to me.
Can you try this patch ?
You may get some weird console messages, but as far as I can tell
they're not important. There may be a way to say to CAM I do
expect to get an error so don't whine, but I'm not sure how
that is done.
And yes, we need to seriously look at how removable devices work
now that we have an infrastructure which truly supports this, but
it is not high on my priority list. If somebody with SCSI CAM
clue wants to step in, contact me.
Poul-Henning
Index: scsi_cd.c
===
RCS file: /home/ncvs/src/sys/cam/scsi/scsi_cd.c,v
retrieving revision 1.84
diff -u -r1.84 scsi_cd.c
--- scsi_cd.c 30 Sep 2003 07:52:15 - 1.84
+++ scsi_cd.c 3 Oct 2003 08:14:36 -
@@ -2852,6 +2852,21 @@
ccb = cdgetccb(periph, /* priority */ 1);
+ scsi_test_unit_ready(ccb-csio, 0, cddone,
+ MSG_SIMPLE_Q_TAG, SSD_FULL_SIZE, 1000);
+ ccb-ccb_h.ccb_bp = NULL;
+ error = cam_periph_runccb(ccb, NULL,
+ /*cam_flags*/0,
+ /*sense_flags*/SF_RETRY_UA,
+ softc-disk.d_devstat);
+
+ if ((ccb-ccb_h.status CAM_STATUS_MASK) != CAM_REQ_CMP) {
+printf(CD failed TUR\n);
+ xpt_release_ccb(ccb);
+ return (ENXIO);
+ }
+printf(CD passed TUR\n);
+
rcap_buf = malloc(sizeof(struct scsi_read_capacity_data),
M_TEMP, M_WAITOK);
Index: scsi_da.c
===
RCS file: /home/ncvs/src/sys/cam/scsi/scsi_da.c,v
retrieving revision 1.159
diff -u -r1.159 scsi_da.c
--- scsi_da.c 4 Sep 2003 01:01:20 - 1.159
+++ scsi_da.c 25 Sep 2003 21:49:24 -
@@ -367,6 +367,16 @@
{T_DIRECT, SIP_MEDIA_REMOVABLE, JUNGSOFT, NEXDISK*, *},
/*quirks*/ DA_Q_NO_SYNC_CACHE
},
+ {
+ /*
+* PQI Travel Flash, rev 1.10/2.05, addr 2
+* General Flash Disk Drive 2.05
+* Serial Number ST92163-2000
+*/
+ {T_DIRECT, SIP_MEDIA_REMOVABLE, General Flash Disk Drive,
+*, *},
+ /*quirks*/ DA_Q_NO_SYNC_CACHE
+ },
{
/*
* Creative Nomad MUVO mp3 player (USB)
@@ -1683,13 +1693,34 @@
block_len = 0;
maxsector = 0;
error = 0;
+ rcap = NULL;
+
+ ccb = cam_periph_getccb(periph, /*priority*/1);
+
+ scsi_test_unit_ready(ccb-csio, 0, dadone,
+ MSG_SIMPLE_Q_TAG, SSD_FULL_SIZE, 1000);
+ ccb-ccb_h.ccb_bp = NULL;
+ error = cam_periph_runccb(ccb, NULL,
+ /*cam_flags*/0,
+ /*sense_flags*/SF_RETRY_UA,
+ softc-disk.d_devstat);
+
+ if ((ccb-ccb_h.status CAM_STATUS_MASK) != CAM_REQ_CMP) {
+ error = ENXIO;
+ goto done;
+ }
+
+ if ((ccb-ccb_h.status CAM_DEV_QFRZN) != 0)
+ cam_release_devq(ccb-ccb_h.path,
+/*relsim_flags*/0,
+/*reduction*/0,
+/*timeout*/0,
+/*getcount_only*/0);
/* Do a read capacity */
rcap = (struct scsi_read_capacity_data *)malloc(sizeof(*rcaplong),
M_TEMP,
M_WAITOK);
-
- ccb = cam_periph_getccb(periph, /*priority*/1);
scsi_read_capacity(ccb-csio,
/*retries*/4,
/*cbfncp*/dadone,
@@ -1758,7 +1789,8 @@
xpt_release_ccb(ccb);
- free(rcap, M_TEMP);
+ if (rcap != NULL)
+ free(rcap, M_TEMP);
return (error);
}
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
[EMAIL PROTECTED] mailing list
Re: scsi-cd + GEOM
In message [EMAIL PROTECTED], Poul-Henning Kamp writes: In message [EMAIL PROTECTED], Dan Nelson writes: Can you try this patch ? Oops! ignore the scsi_da.c patch! Index: scsi_da.c === RCS file: /home/ncvs/src/sys/cam/scsi/scsi_da.c,v retrieving revision 1.159 diff -u -r1.159 scsi_da.c -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /bin/sh terminated abnormally
Kris Kennaway [EMAIL PROTECTED] writes: Yes, since you have run installworld you have now installed a 5.x /bin/sh binary, which cannot run on the 4.x kernel you are running. He *hasn't* run installworld; installworld would have installed the new loader. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Nvidia driver
On Friday 03 October 2003 16:34, Mike Hunter wrote: How do you turn those down? /boot/loader.conf? I tried saying hw.nvidia.card.rates=2x 1x but that didn't seem to do anything (I have a feeling that putting that in /boot/loader.conf makes no sense...please consider this a desperate cry for help.) Hmm, I am trying to remember :) Ahh! Here is a fragment of my loader.conf.. nvidia_load=YES machdep.disable_mtrrs=1 hw.nvidia.registry.ReqAGPRate=1 Is it a bad sign that my sysctl has some weird values in it? Possibly :) I see it's a GeForce 4 Go.. They seem to be a bit weird from various posts on the lists :( -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 9A8C 569F 685A D928 5140 AE4B 319B 41F4 5D17 FDD5 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
file system (UFS2) consistancy after -current crash?
After crashes recently ive been geting softupdate inconsistancies. Directories in which a file has recently been renamed have neither the old file nor the new file. fsck -y recovers the inode and drops it in lost in found. I was under the impression that atomic rename() synced all the way to the disk before returning? Does softupdate enabled/disable have any bearing on this? The disks themselfs are a raid5 on an adaptec 5400s. We have had some problems recently with aac (the 5400s driver) related crashes we have been working with Scott Long on. I was wondering if maybe rename is only syncing as far as the raid controller memory? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
HP ProLiant DL360G3 rebuttal... ;-)
Hi, I read your article about the fan control in a DL380G3. We have the same problem. We ran at full speed from cold boot. Installed is the latest bios, but the fans don't slow down. Cooling is proper in the server room. The call is open at HP...but they are so slow with the reaction. :-( BR Andreas Andreas Bauer Surface Specialties Germany GmbH Co. KG Site Leader IT Operations Helbingstr. 46 D - 22047 Hamburg Tel.: +49 (0) 40 / 69 43 - 229 FAX:+49 (0) 40 / 69 43 - 203 e-mail: [EMAIL PROTECTED] - Legal Notice: This electronic mail and its attachments are intended solely for the person(s) to whom they are addressed and contain information which is confidential or otherwise protected from disclosure, except for the purpose they are intended to. Dissemination, distribution, or reproduction by anyone other than their intended recipients is prohibited and may be illegal. If you are not an intended recipient, please immediately inform the sender and send him/her back the present e-mail and its attachments and destroy any copies which may be in your possession. - ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: scsi-cd + GEOM
On Fri, 2003-10-03 at 10:30, Poul-Henning Kamp wrote: Can you try this patch ? You may get some weird console messages, but as far as I can tell they're not important. There may be a way to say to CAM I do expect to get an error so don't whine, but I'm not sure how that is done. I 've applied the scsi_cd.c patch but it didn't resolve the problem, i just get these extra messages: -- long delay -- CD failed TUR CD failed TUR cd1 at ahc0 bus 0 target 3 lun 0 cd1: PLEXTOR CD-ROM PX-40TS 1.05 Removable CD-ROM SCSI-2 device cd1: 20.000MB/s transfers (20.000MHz, offset 15) cd1: Attempt to query device size failed: NOT READY, Medium not present - tray closed CD failed TUR CD failed TUR Regards, Sascha ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Improvements to fsck performance in -current ...?
Terry Lambert wrote: Unfortunately, IDE disks do not permit disconnected writes, due to a bug in the original IDE implementation, Therefore IDE disks almost universally lie to the driver any time write caching is enabled on an IDE drive. I understand that SATA has fixed a number of problems in the command set over PATA. Does anyone know if SATA handles this issue correctly? Tim ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Improvements to fsck performance in -current ...?
Don Lewis wrote:
On 2 Oct, Terry Lambert wrote:
[...]
Actually, write caching is not so much the problem, as the disk
reporting that the write has completed before the contents of
the transaction saved in the write cache have actually been
committed to stable storage.
Unfortunately, IDE disks do not permit disconnected writes, due
to a bug in the original IDE implementation, which has been
carried forward for [insert no good reason here].
Therefore IDE disks almost universally lie to the driver any
time write caching is enabled on an IDE drive.
In most cases, if you use SCSI, the problem will go away.
Nope, they lie as well unless you turn of the WCE bit. Fortunately
with tagged command queuing there is very little performance penalty for
doing this in most cases. The main exception to this is when you run
newfs which talks to the raw partition and only has one command
outstanding at a time.
Back in the days when our SCSI implementation would spam the console
whenever it reduced the number of tagged openings because the drive
indicated that its queue was full, I'd see the number of tagged openings
stay at 63 if write caching was disabled, but the number would drop
significantly under load (50%?) if write caching was enabled. I always
suspected that the drive's cache was full of data for write commands
that it had indicated to the host as being complete even though the data
hadn't been written to stable storage.
Unfortunately SCSI drives all seem to ship with the WCE bit set,
probably for benchmarking reasons, so I always have to remember to
turn this bit off whenever I install a new drive.
A message from this morning ('file system (UFS2) consistancy
after -current crash?') to this list describes exactly the
situation on my fileserver a few month ago, except my machine
runs with FreeBSD 4-STABLE and has an ICP-Vortex 6528RD controller.
I think, disk's or controllers (short hardware) write cache
is a problem. Maybe it shouldn't be in theory, but it is in
real world :-)
Best regards,
Jens
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NFS corruption on p4 machines (please test)
Kris, Kris Kennaway wrote: For some months now I have been experiencing NFS corruption on the three machines in the dosirak.kr package cluster - these are SMP pentium 4 machines that run -CURRENT. Setting DISABLE_PSE and DISABLE_PG_G does not fix these problems. I am able to easily reproduce these problems using /usr/src/tools/regression/fsx on a loopback nfs mount - they are not deterministic, but it blows up within about 8000 operations (less than a minute of operation). In fact sometimes it even manages to make fsx segfault, which is fairly impressive :) Just mount something rw via loopback nfs, and run 'fsx foo' on the nfs filesystem for a few minutes. I just ran an fsx cycle on my desktop machine over a TCP mount, and it seemed to work fine: [EMAIL PROTECTED]: /usr/src/tools/regression/fsx] ./fsx /tmp/nfs/x truncating to largest ever: 0x13e76 truncating to largest ever: 0x2e52c truncating to largest ever: 0x3c2c2 truncating to largest ever: 0x3f15f truncating to largest ever: 0x3fcb9 truncating to largest ever: 0x3fe96 truncating to largest ever: 0x3ff9d truncating to largest ever: 0x3 skipping zero size read skipping zero size write skipping zero size write ^Csignal 2 testcalls = 166863 Lars -- Lars Eggert [EMAIL PROTECTED] USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: Improvements to fsck performance in -current ...?
Jens Rehsack wrote:
Don Lewis wrote:
On 2 Oct, Terry Lambert wrote:
[...]
Actually, write caching is not so much the problem, as the disk
reporting that the write has completed before the contents of
the transaction saved in the write cache have actually been
committed to stable storage.
Unfortunately, IDE disks do not permit disconnected writes, due
to a bug in the original IDE implementation, which has been
carried forward for [insert no good reason here].
Therefore IDE disks almost universally lie to the driver any
time write caching is enabled on an IDE drive.
In most cases, if you use SCSI, the problem will go away.
Nope, they lie as well unless you turn of the WCE bit. Fortunately
with tagged command queuing there is very little performance penalty for
doing this in most cases. The main exception to this is when you run
newfs which talks to the raw partition and only has one command
outstanding at a time.
Back in the days when our SCSI implementation would spam the console
whenever it reduced the number of tagged openings because the drive
indicated that its queue was full, I'd see the number of tagged openings
stay at 63 if write caching was disabled, but the number would drop
significantly under load (50%?) if write caching was enabled. I always
suspected that the drive's cache was full of data for write commands
that it had indicated to the host as being complete even though the data
hadn't been written to stable storage.
Unfortunately SCSI drives all seem to ship with the WCE bit set,
probably for benchmarking reasons, so I always have to remember to
turn this bit off whenever I install a new drive.
A message from this morning ('file system (UFS2) consistancy
after -current crash?') to this list describes exactly the
situation on my fileserver a few month ago, except my machine
runs with FreeBSD 4-STABLE and has an ICP-Vortex 6528RD controller.
I think, disk's or controllers (short hardware) write cache
is a problem. Maybe it shouldn't be in theory, but it is in
real world :-)
This is somewhat relevent to a discussion occurring this week on the
PostgreSQL performance mailing list.
A fellow was testing a number of caching options for disk drives, in
conjunction with the performance impact it had on Postgre. Near the
end of the discussion and his testing, he decided to do a plug test
(i.e., pull the power plug out of the wall while Postgre was running a
benchmark and see if the database was recoverable on reboot).
The tests don't 100% apply, since he was testing with Linux and XFS,
but I think the results speak VOLUMES!
Every single plug test with WC enabled on the IDE drives resulted in
an unrecoverable database - every time, even with XFS' journalling,
and no matter what sync options he had enabled in Postgres.
Every single plug test with WC disabled on the IDE drives resulted
in a filesystem and database that was recoverable, even when sync
was turned totally off in Postgres.
Additionally, he noticed that turning WC on resulted in something
like 40x performance improvement.
To me, this means:
a) if you want reliable, don't use IDE with WC
b) if you want reliable and fast, don't use IDE, period, use SCSI.
--
Bill Moran
Potential Technologies
http://www.potentialtech.com
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NFS corruption on p4 machines (please test)
Lars Eggert wrote: Kris Kennaway wrote: Just mount something rw via loopback nfs, and run 'fsx foo' on the nfs filesystem for a few minutes. I just ran an fsx cycle on my desktop machine over a TCP mount, and it seemed to work fine: I should have mentioned that this is a Pentium 4 Xeon SMP machine running -current. Lars -- Lars Eggert [EMAIL PROTECTED] USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: Improvements to fsck performance in -current ...?
Bill Moran wrote: [...] To me, this means: a) if you want reliable, don't use IDE with WC Reducable of 'don't use IDE' :-) b) if you want reliable and fast, don't use IDE, period, use SCSI. If you look at the recent postings, SCSI didn't help you out everytime. I use the fileserver in current configuration for nearly 5 years, and only once this happend, each other case all filesystems including hold data was recoverable. Jens ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NFS corruption on p4 machines (please test)
On Fri, Oct 03, 2003 at 10:10:20AM -0700, Lars Eggert wrote: Kris, Kris Kennaway wrote: For some months now I have been experiencing NFS corruption on the three machines in the dosirak.kr package cluster - these are SMP pentium 4 machines that run -CURRENT. Setting DISABLE_PSE and DISABLE_PG_G does not fix these problems. I am able to easily reproduce these problems using /usr/src/tools/regression/fsx on a loopback nfs mount - they are not deterministic, but it blows up within about 8000 operations (less than a minute of operation). In fact sometimes it even manages to make fsx segfault, which is fairly impressive :) Just mount something rw via loopback nfs, and run 'fsx foo' on the nfs filesystem for a few minutes. I just ran an fsx cycle on my desktop machine over a TCP mount, and it seemed to work fine: Thanks. What hardware specs? Kris pgp0.pgp Description: PGP signature
freeing preloads
Is it possible to free memory associated with preload_search_by_type? The reason for this is that SEBSD uses the bootloader to read a large policy file at startup, but it is converted into a different format for use, and the original is not needed after parsing. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
lots of exclusive sleep mutex
Hi, I've seen lots of messages on rescent -CURRENT malloc() of 16 with the following non-sleepable locks held: exclusive sleep mutex g_xdown r = 0 (0xe044eca8) locked @ /usr/src/sys/geom/geom_io.c:351 malloc() of 16 with the following non-sleepable locks held: exclusive sleep mutex g_xdown r = 0 (0xe044eca8) locked @ /usr/src/sys/geom/geom_io.c:351 uname -av is FreeBSD x225.dmz 5.1-CURRENT FreeBSD 5.1-CURRENT #0: Fri Oct 3 23:47:45 CST 2003 [EMAIL PROTECTED]:/d/obj/usr/src/sys/XEON5 i386 Clive ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
HEADS UP: can't find kernel source tree error when building the kernel.
On Fri, Oct 03, 2003 at 12:28:42PM -0500, Jacques A. Vidrine wrote:
On Fri, Oct 03, 2003 at 07:57:51PM +0300, Clau wrote:
hello,
i just downloaded via cvsup the latest kernel for freebsd 5.1.
i had a problem with it, more exactly when i did a make depend
it stopped at some place, and gave me this error:
can't find kernel source tree
i fixed this by modifying this piece of code from /usr/src/sys/conf/kmod.mk
(it starts with line 167 in the file)
.for _dir in ${.CURDIR}/../.. ${.CURDIR}/../../.. /sys /usr/src/sys
.if !defined(SYSDIR) exists(${_dir}/kern/)
SYSDIR= ${_dir}
.endif
.endfor
.if !defined(SYSDIR) || !exists(${SYSDIR}/kern/)
.error can't find kernel source tree
.endif
i removed the last / from /kern/ and now it seems it can find the
directory.
i don't know if this is a general problem, or it is just in the case of
my system.
How are you building the kernel? Are you using `make buildworld' first
and then `make buildkernel' (or `make kernel')?
Maybe now it will be more obvious why I thought that upgrade_checks
should always be done, for all standard src/Makefile targets.
Currently, you either need to upgrade your /usr/bin/make binary
manually, or to use this command from /usr/src:
make buildkernel -DALWAYS_CHECK_MAKE ...
with up-to-date tools/regression/usr.bin/make/ and usr.bin/make/
sources.
Cheers,
--
Ruslan Ermilov Sysadmin and DBA,
[EMAIL PROTECTED] Sunbay Software Ltd,
[EMAIL PROTECTED] FreeBSD committer
pgp0.pgp
Description: PGP signature
Panic w/ sources of yesterday
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240
No locals.
#1 0xc04c79d9 in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:372
No locals.
#2 0xc04c7d07 in panic () at /usr/src/sys/kern/kern_shutdown.c:550
td = (struct thread *) 0xc160d850
bootopt = 256
newpanic = 1
ap = 0xc67a17e8 \030zÆBÙEÀÄÌ]À
buf = from debugger, '\0' repeats 242 times
#3 0xc045d9e2 in db_panic () at /usr/src/sys/ddb/db_command.c:450
No locals.
#4 0xc045d942 in db_command (last_cmdp=0xc066a0c0, cmd_table=0x0,
aux_cmd_tablep=0xc063cb54,
aux_cmd_tablep_end=0xc063cb58) at /usr/src/sys/ddb/db_command.c:346
cmd = (struct command *) 0xc060b680
t = 0
modif =
\0ªfÀH\230mÀ0\030zÆ\r\0\0\0À\203lÀ\r\0\0\0\001\0\0\0P\030zƦ)]À\200ikÀ\aK\0
D\204lÀ\0jÀ ªfÀx\0\0\0
ªfÀH\230mÀt\030zÆaøEÀ?LaÀ\020öEÀ\0\0\0\0\020\0\0\0H\230mÀ ªfÀvïEÀ
ªfÀP¢fÀx\0\0\0\003\0\0
addr = -1067594556
count = -1
have_addr = 0
result = 0
#5 0xc045da85 in db_command_loop () at /usr/src/sys/ddb/db_command.c:472
No locals.
#6 0xc0460a85 in db_trap (type=3, code=0) at /usr/src/sys/ddb/db_trap.c:73
bkpt = 0
#7 0xc05dca0c in kdb_trap (type=3, code=0, regs=0xc67a1968)
at /usr/src/sys/i386/i386/db_interface.c:171
ef = 70
ddb_mode = 1
#8 0xc05ed61a in trap (frame=
{tf_fs = 24, tf_es = 16, tf_ds = 16, tf_edi = -1066780496, tf_esi =
-1060966128, tf_ebp = -965076556, tf_isp = -965076588, tf_ebx = 0, tf_edx =
0, tf_ecx = 0, tf_eax = 25, tf_trapno = 3, tf_err = 0, tf_eip = -1067594556,
tf_cs = 8, tf_eflags = 646, tf_esp = -1067227721, tf_ss = -1067393707}) at
/usr/src/sys/i386/i386/trap.c:578
td = (struct thread *) 0xc160d850
p = (struct proc *) 0xc17c65ac
sticks = 3329890656
i = 0
ucode = 0
type = 3
code = 0
eva = 0
#9 0xc05de3b8 in calltrap () at {standard input}:102
No locals.
#10 0xc04ec4ef in witness_lock (lock=0xc0c2f110, flags=8,
file=0xc063316d /usr/src/sys/vm/vm_kern.c, line=328)
at /usr/src/sys/kern/subr_witness.c:839
lock_list = (struct lock_list_entry **) 0xc160d8bc
lle = (struct lock_list_entry *) 0xc06a38b0
lock1 = (struct lock_instance *) 0x0
lock2 = (struct lock_instance *) 0x0
class = (struct lock_class *) 0xc06a38b0
w = (struct witness *) 0xc0680e90
w1 = (struct witness *) 0xc0680f08
td = (struct thread *) 0x0
i = -1
go_into_ddb = 1
#11 0xc04beb1a in _mtx_lock_flags (m=0x0, opts=0, file=0xc06a38b0 ,
line=-1060966128)
at /usr/src/sys/kern/kern_mutex.c:336
No locals.
#12 0xc05a6796 in _vm_map_lock (map=0x0, file=0x0, line=0) at
/usr/src/sys/vm/vm_map.c:352
No locals.
#13 0xc05a5a7a in kmem_malloc (map=0xc0c2f0b0, size=4096, flags=257)
at /usr/src/sys/vm/vm_kern.c:328
offset = 731
i = 3234001168
entry = 0xc67a1a9c
addr = 3235708928
m = 0x0
pflags = -1066780496
#14 0xc05b5df7 in page_alloc (zone=0xc0c3a3c0, bytes=0, pflag=0x0, wait=0)
at /usr/src/sys/vm/uma_core.c:845
p = (void *) 0x0
#15 0xc05b5ae7 in slab_zalloc (zone=0xc0c3a3c0, wait=257) at
/usr/src/sys/vm/uma_core.c:753
slab = 0x0
mem = (u_int8_t *) 0xc160d8bc °8jÀ
flags = 2 '\002'
i = 257
#16 0xc05b6ba6 in uma_zone_slab (zone=0xc0c3a3c0, flags=1) at
/usr/src/sys/vm/uma_core.c:1539
slab = 0x0
#17 0xc05b6e5e in uma_zalloc_internal (zone=0xc0c3a3c0, udata=0x0, flags=1)
at /usr/src/sys/vm/uma_core.c:1678
slab = 0x0
item = (void *) 0xc0c3a3d4
#18 0xc05b4f3e in bucket_alloc (entries=0, bflags=0) at
/usr/src/sys/vm/uma_core.c:267
ubz = (struct uma_bucket_zone *) 0xc065de44
bucket = 0x0
idx = 0
#19 0xc05b7116 in uma_zfree_arg (zone=0xc0c20240, item=0xca81e33c, udata=0x0)
at /usr/src/sys/vm/uma_core.c:1812
cache = 0xc0c202f0
bucket = 0xc065de44
bflags = 0
cpu = 0
skip = 0
#20 0xc05a0a5f in swp_pager_meta_ctl (object=0xc1c20534,
pindex=14301769181853384735, flags=2)
at /usr/src/sys/vm/uma.h:262
pswap = (struct swblock **) 0xc165d3d0
swap = (struct swblock *) 0xca81e33c
r1 = 2147483648
idx = 31
#21 0xc059f45a in swap_pager_unswapped (m=0x0) at
/usr/src/sys/vm/swap_pager.c:957
No locals.
#22 0xc05a2e5b in vm_fault (map=0xc0e0ddc8, vaddr=140713984, fault_type=2
'\002', fault_flags=8)
at /usr/src/sys/vm/vm_pager.h:191
prot = 7 '\a'
is_first_object_locked = -1066928736
result = 31
growstack = 1
wired = 0
map_generation = 52
next_object = 0x1f
marray = {0x0, 0x0, 0xc67a1c94, 0x246, 0xc064deac, 0x8, 0xc17c6618,
0x2c2, 0xc0637f0d,
0xc67a1cbc, 0xc04beb62, 0xc17c6618, 0x8, 0xc0637f0d, 0x2c2, 0xc06a38b4}
hardfault = 0
faultcount = 0
fs = {m = 0xc0cf9a70, object = 0xc1c20534, pindex = 1503, first_m =
0x0,
first_object
Re: HEADS UP: can't find kernel source tree error when building the kernel.
On Fri, Oct 03, 2003 at 09:02:19PM +0300, Ruslan Ermilov wrote: Maybe now it will be more obvious why I thought that upgrade_checks should always be done, for all standard src/Makefile targets. Currently, you either need to upgrade your /usr/bin/make binary manually, or to use this command from /usr/src: make buildkernel -DALWAYS_CHECK_MAKE ... with up-to-date tools/regression/usr.bin/make/ and usr.bin/make/ sources. I don't think the original poster was building his kernel with src/Makefile targets. I believe he was doing it the old-fashioned way: manual config, make depend, make kernel. Cheers, -- Jacques Vidrine . NTT/Verio SME . FreeBSD UNIX . Heimdal [EMAIL PROTECTED] . [EMAIL PROTECTED] . [EMAIL PROTECTED] . [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NFS corruption on p4 machines (please test)
Kris Kennaway wrote: On Fri, Oct 03, 2003 at 10:10:20AM -0700, Lars Eggert wrote: Kris, Kris Kennaway wrote: For some months now I have been experiencing NFS corruption on the three machines in the dosirak.kr package cluster - these are SMP pentium 4 machines that run -CURRENT. Setting DISABLE_PSE and DISABLE_PG_G does not fix these problems. I am able to easily reproduce these problems using /usr/src/tools/regression/fsx on a loopback nfs mount - they are not deterministic, but it blows up within about 8000 operations (less than a minute of operation). In fact sometimes it even manages to make fsx segfault, which is fairly impressive :) Just mount something rw via loopback nfs, and run 'fsx foo' on the nfs filesystem for a few minutes. I just ran an fsx cycle on my desktop machine over a TCP mount, and it seemed to work fine: Thanks. What hardware specs? Attached. Lars -- Lars Eggert [EMAIL PROTECTED] USC Information Sciences Institute cam: using minimum scsi_delay (100ms) Copyright (c) 1992-2003 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.1-CURRENT #0: Tue Sep 30 10:11:59 PDT 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/KERNEL-1.31 Preloaded elf kernel /boot/kernel/kernel at 0xc06ed000. Preloaded elf module /boot/kernel/vesa.ko at 0xc06ed21c. Preloaded elf module /boot/kernel/md.ko at 0xc06ed2c8. Preloaded elf module /boot/kernel/linux.ko at 0xc06ed370. Preloaded elf module /boot/kernel/if_gif.ko at 0xc06ed41c. Preloaded elf module /boot/kernel/if_tun.ko at 0xc06ed4c8. Preloaded elf module /boot/kernel/ipfw.ko at 0xc06ed574. Preloaded elf module /boot/kernel/if_an.ko at 0xc06ed620. Preloaded elf module /boot/kernel/wlan.ko at 0xc06ed6cc. Preloaded elf module /boot/kernel/rc4.ko at 0xc06ed778. Preloaded elf module /boot/kernel/pccard.ko at 0xc06ed820. Preloaded elf module /boot/kernel/if_em.ko at 0xc06ed8cc. Preloaded elf module /boot/kernel/if_fxp.ko at 0xc06ed978. Preloaded elf module /boot/kernel/miibus.ko at 0xc06eda24. Preloaded elf module /boot/kernel/if_lnc.ko at 0xc06edad0. Preloaded elf module /boot/kernel/if_wi.ko at 0xc06edb7c. Preloaded elf module /boot/kernel/if_xl.ko at 0xc06edc28. Preloaded elf module /boot/kernel/snd_emu10k1.ko at 0xc06edcd4. Preloaded elf module /boot/kernel/snd_pcm.ko at 0xc06edd84. Preloaded elf module /boot/kernel/snd_es137x.ko at 0xc06ede30. Preloaded elf module /boot/kernel/snd_ich.ko at 0xc06edee0. Preloaded elf module /boot/kernel/snd_maestro3.ko at 0xc06edf8c. Preloaded elf module /boot/kernel/ugen.ko at 0xc06ee040. Preloaded elf module /boot/kernel/usb.ko at 0xc06ee0ec. Preloaded elf module /boot/kernel/uhid.ko at 0xc06ee194. Preloaded elf module /boot/kernel/ukbd.ko at 0xc06ee240. Preloaded elf module /boot/kernel/ulpt.ko at 0xc06ee2ec. Preloaded elf module /boot/kernel/ums.ko at 0xc06ee398. Preloaded elf module /boot/kernel/umass.ko at 0xc06ee440. Preloaded elf module /boot/kernel/umodem.ko at 0xc06ee4ec. Preloaded elf module /boot/kernel/ucom.ko at 0xc06ee598. Preloaded elf module /boot/kernel/bktr.ko at 0xc06ee644. Preloaded elf module /boot/kernel/bktr_mem.ko at 0xc06ee6f0. Preloaded elf module /boot/kernel/agp.ko at 0xc06ee7a0. Preloaded elf module /boot/kernel/random.ko at 0xc06ee848. Preloaded elf module /boot/kernel/ip_mroute.ko at 0xc06ee8f4. Preloaded elf module /boot/kernel/ip6fw.ko at 0xc06ee9a4. Preloaded elf module /boot/kernel/netgraph.ko at 0xc06eea50. Preloaded elf module /boot/kernel/dummynet.ko at 0xc06eeb00. Preloaded elf module /boot/kernel/radeon.ko at 0xc06eebb0. Preloaded elf module /boot/kernel/r128.ko at 0xc06eec5c. Preloaded elf module /boot/kernel/ahc.ko at 0xc06eed08. Preloaded elf module /boot/kernel/mpt.ko at 0xc06eedb0. Preloaded elf module /boot/kernel/fdc.ko at 0xc06eee58. Preloaded elf module /boot/kernel/cbb.ko at 0xc06eef00. Preloaded elf module /boot/kernel/exca.ko at 0xc06eefa8. Preloaded elf module /boot/kernel/cardbus.ko at 0xc06ef054. Preloaded elf module /boot/kernel/lpt.ko at 0xc06ef100. Preloaded elf module /boot/kernel/ubsa.ko at 0xc06ef1a8. Preloaded elf module /boot/kernel/firewire.ko at 0xc06ef254. Preloaded elf module /boot/kernel/sbp.ko at 0xc06ef304. Preloaded elf module /boot/kernel/smbus.ko at 0xc06ef3ac. Preloaded elf module /boot/kernel/intpm.ko at 0xc06ef458. Preloaded elf module /boot/kernel/smb.ko at 0xc06ef504. Preloaded elf module /boot/kernel/iicbus.ko at 0xc06ef5ac. Preloaded elf module /boot/kernel/iic.ko at 0xc06ef658. Preloaded elf module /boot/kernel/iicsmb.ko at 0xc06ef700. Preloaded elf module /boot/kernel/uart.ko at 0xc06ef7ac. Preloaded elf module /boot/kernel/acpi.ko at 0xc06ef858. Timecounter i8254 frequency 1193121 Hz quality 0 CPU: Intel(R) XEON(TM) CPU 2.40GHz (2372.81-MHz 686-class CPU) Origin = GenuineIntel Id = 0xf24 Stepping = 4
RE: Panic w/ sources of yesterday
On 03-Oct-2003 Robin P. Blanchard wrote: No locals. #12 0xc05a6796 in _vm_map_lock (map=0x0, file=0x0, line=0) at /usr/src/sys/vm/vm_map.c:352 No locals. #13 0xc05a5a7a in kmem_malloc (map=0xc0c2f0b0, size=4096, flags=257) at /usr/src/sys/vm/vm_kern.c:328 offset = 731 i = 3234001168 entry = 0xc67a1a9c addr = 3235708928 m = 0x0 pflags = -1066780496 This would appear to be the problem here, vm_map_lock() called with a NULL map. Do you have the panic messages themselves by chance? -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: can't find kernel source tree error when building the kernel.
On Fri, Oct 03, 2003 at 09:02:19PM +0300, Ruslan Ermilov wrote: How are you building the kernel? Are you using `make buildworld' first and then `make buildkernel' (or `make kernel')? Maybe now it will be more obvious why I thought that upgrade_checks should always be done, for all standard src/Makefile targets. It has already been obvious why you thought upgrade_checks should always be done. The obviousness of your thoughts says nothing about the correctness or sensibility of your thoughts, though. You still fail to see that buildkernel is not always the way people build kernels and buildworld not a target that's made on a daily basis. You therefore continue to break the development environment for a significant portion of the -current developers by failing to use common sense and hanging on to obvious and obviously flawed points of view. To be less vague about this: your change to kmod.mk was not made after giving a dependent change, i.e. the fix to make(1), sufficient time to take effect by the natural course of events. Instead you made a change that takes effect immediately right after making a change that only takes effect after an install and then attribute breakages to other causes then your own actions. I consider that a severe lack of good judgement. The Marcel approved way of doing this would be: 1. fix make(1), 2. Wait a month (or so) or until after the next release, whichever comes first, 3. Change kmod.mk. If something else needs to be fixed that depends on changing kmod.mk so that you don't have the time to let nature do it's thing, you send a HEADS UP to tell people that they need to build and install make(1) to restore universal balance. Under no circumstances are you to break the development environment gratuitously and turn it into a political event that allows you to draw attention (obviously) to your (obvious) thoughts. END OF LINE -- Master Control, TRON -- Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
GEOM BDE stats / questions about crypto transformations
We are looking at doing some offsite backup at a generally physically secure location. Still we are not that trusting of our data living off site. So GEOM BDE seems to be a good fit to further reduce the risk. The hardware we have is a 2.2 Celeron as well as a HiFn card to assist with 3des transformations. (basically one backup server here at HQ pushing off big dump files via ssh) and other stuff with FAST_IPSEC tunnels to the off site location. For storage, we have a 3ware 7810 with RAID5. The link speed between us is anywhere from 10Mb/s to 40Mb/s (depends on what is available during the time of day-- we only will use excess bandwidth) This should allow us to fully backup our data in 24hrs. I wanted to make sure I could write out to the disk with at least that speed. Doing a simple test with bonnie as well as simulating it via scp, its a bit close. ---Sequential Output ---Sequential Input-- --Random-- -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks--- MachineMB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU 54000 16746 56.0 17152 29.4 11675 24.7 24569 68.9 34602 27.7 129.7 3.1 5EH 4000 4961 17.1 5145 9.1 3720 8.0 9996 28.8 12347 11.3 119.5 2.9 5E 4000 4953 17.1 5132 9.4 3790 7.9 10522 30.6 13125 12.3 120.1 2.8 5 = Regular RAID 5 UFS mount 5EH = RAID 5 with HiFn crpto card from Soekris on a BDE encrypted mount 5E = BDE encrypted mount The hiFn card doesnt seem to make much difference as it only offloads MD5 calculations. However, overall the CPU is lower when running with the hifn card defined in the kernel. It makes a large difference in CPU usage when scp'ing a file across using 3des. Perhaps when the new Soekris card which does AES comes out, these numbers will speed up. In the mean time is anyone using this in production ? Are you using any USB keys for the storing the pass phrase ? If so, can you give me some details as to how you set it up ? Thanks, ---Mike Mike Tancsa, tel +1 519 651 3400 Sentex Communications,[EMAIL PROTECTED] Providing Internet since 1994www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: GEOM BDE stats / questions about crypto transformations
In message [EMAIL PROTECTED], Mike Tancsa writes: However, overall the CPU is lower when running with the hifn card defined in the kernel. It makes a large difference in CPU usage when scp'ing a file across using 3des. Perhaps when the new Soekris card which does AES comes out, these numbers will speed up. In the mean time is anyone using this in production ? Are you using any USB keys for the storing the pass phrase ? If so, can you give me some details as to how you set it up ? I have a rewrite of the userland tool (gbde(8)) in progress, amongst other things it will improve the key-handling a fair bit. I don't have an ETA right now, but I hope to make it before 5.2 -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
usb keyboard not working in single user mode
Hello I've got 5.1-current running on an IBM BladeCenter HS20. This thing has a USB KVM built-in. It's working in multi-user mode. Problem is when I boot to single user, can't do anything. I'm looking for a way to fire up the usbd in single user mode. So far I've tried: Loading usbd.ko, ugen.ko, ukbd.ko modules via loader.conf. NO GOOD, hangs the system. Setting /usr/sbin/usbd in /etc/ttys so that init(8) can run the usbd. If anyone needs access I can supply a root login via ssh. Thanks Ken McKittrick ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: can't find kernel source tree error when building the kernel.
In message: [EMAIL PROTECTED] Marcel Moolenaar [EMAIL PROTECTED] writes: : The Marcel approved way of doing this would be: : 1. fix make(1), : 2. Wait a month (or so) or until after the next release, whichever :comes first, : 3. Change kmod.mk. Agreed. I just arbitrarily decided that this was right. I reverted the change so I could compile new kernels again w/o upgrading my make. Let's move on and revert my reverting in about a month. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: TEST PLEASE: if_tun patch
On Tue, Sep 30, 2003 at 03:17:05PM -0700, Brooks Davis wrote: It looks strange to have `ifconfig create' vlan interface on tap, while tap uses different semantics and can disappear after closing it? With ef it is even worse, pseudo-devices are created while ef is starting, so ef module must be loaded after creating every ethernet device. That's really evil. :-) The proper fix for the vanishing tap is probably some standard way for parents to know who their children are so they can hunt then down and notify them that they are being orphaned when they die. What the device would do it up to it since some devices like vlan and ef devices might as well die off, but an etherchannel device should just stop sending things to that interface. I like to have all tun/tap interfaces to exist on my system, whether they are opened or not. Interface list is constant, what makes me and my stats more happy, same about firewall rules (rc.d/ppp calls ipfilter resync for example, this would be a bit inconvenient to do the same for 20 /dev/tun). I would like my tun/tap interface *not to* disappear entirely when device is closed, uless I manually do something like ifconfig tun0 destroy. :) For ef, I'm thinking of expanding cloning so that we pass the requested name to each cloner for tasting and it decides if it can do that. Then vlans would be created and configured by doing something like: ifconfig fxp0.10 create and you could come up with a similar syntax for ef by appending f# to any ethernet's name to get the appropriate frame interface. A corrected form of the existing behavior could easily be implemented in userland by devd. Sounds very sensible. -- Pawe Maachowski ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: can't compile kernel without bpf
Ivan Doleal wrote: As for kernel compilation (wireless does need bpf), this was it! The new 802.11 layer (device wlan) and some WiFi device drivers (ath and wi) uses the bpfattach2() function call. The bpfattach2() implementation has no stub counterpart in non-bpf section of net/bpf.c, so the kernel can't be succesfully linked without BPF support. It's the immediate cause why we need bpf in kernel now. The question is - is presence of bpf mandatory for functionality of 802.11 devices ? I think the correct answer is NO, so it's bug and stub bpfattach2() should be added to apropriate place of net/bpf.c. But I'm not sure. Someone who know should decide and send PR ... Dan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: file system (UFS2) consistancy after -current crash? (fwd)
Date: Fri, 03 Oct 2003 05:03:34 -0600 From: Aaron Wohl [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: file system (UFS2) consistancy after -current crash? After crashes recently ive been geting softupdate inconsistancies. Directories in which a file has recently been renamed have neither the old file nor the new file. fsck -y recovers the inode and drops it in lost in found. I was under the impression that atomic rename() synced all the way to the disk before returning? Does softupdate enabled/disable have any bearing on this? The disks themselfs are a raid5 on an adaptec 5400s. We have had some problems recently with aac (the 5400s driver) related crashes we have been working with Scott Long on. I was wondering if maybe rename is only syncing as far as the raid controller memory? The problem that we have been having with many of the RAID systems is that they give an I/O completion interrupt after they copy the change into their memeory, but before the I/O is completed to the disk. Since the filesystem uses the I/O completion interrupt as an indication that the change is on disk, it proceeds to the next step. If the RAID ultimately fails to get the data to the disk, inconsistencies arise. This problem can arise whether or not soft updates are being used, but because soft updates makes individual changes over a longer time period (potentially up to a minute rather than the few milliseconds of 2-3 synchronous writes), it is more likely to be apparent after a crash. None of this helped by a journalling filesystem as the RAID lies about writing the log so you may not have it available to do a rollback after a crash. As we discovered with IDE disks, disabling the write cache enable feature causes a massive performance hit, so in practice that does not seem like a viable strategy. What does work is to use tag-queueing. Unfortunately tag-queueing is found primarily in SCSI systems, though it is starting to show up in the high-end IDE disks. Kirk McKusick ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
[security-advisories@freebsd.org: [FreeBSD-Announce] FreeBSD Security Advisory FreeBSD-SA-03:17.procfs]
I'm finally motivated to ask, why don't security advisories contain the equivalent revs for -head? Surely I can't be the only person following -current who doesn't build every day. This notable omission has been true of every security advisory I can remember, and I've never understood it. If I'm missing some logic that makes it the right thing to do, can somebody please enlighten me? Thanks, Barney - Forwarded message from FreeBSD Security Advisories [EMAIL PROTECTED] - VI. Correction details The following list contains the revision numbers of each file that was corrected in FreeBSD. Branch Revision Path - - RELENG_4 src/sys/i386/linux/linprocfs/linprocfs_misc.c 1.3.2.9 src/sys/kern/kern_subr.c 1.31.2.3 src/sys/miscfs/procfs/procfs_dbregs.c 1.4.2.4 src/sys/miscfs/procfs/procfs_fpregs.c 1.11.2.4 src/sys/miscfs/procfs/procfs_regs.c1.10.2.4 src/sys/miscfs/procfs/procfs_rlimit.c 1.5.2.1 src/sys/miscfs/procfs/procfs_status.c 1.20.2.5 src/sys/sys/uio.h 1.11.2.2 RELENG_5_1 src/UPDATING 1.251.2.11 src/sys/conf/newvers.sh 1.50.2.11 src/sys/fs/procfs/procfs_dbregs.c 1.22.2.1 src/sys/fs/procfs/procfs_fpregs.c 1.28.2.1 src/sys/fs/procfs/procfs_regs.c1.27.2.1 src/sys/fs/pseudofs/pseudofs_vnops.c 1.35.2.1 src/sys/kern/kern_subr.c 1.74.2.1 src/sys/sys/uio.h 1.27.2.1 etc. - End forwarded message - -- Barney Wolff http://www.databus.com/bwresume.pdf I'm available by contract or FT, in the NYC metro area or via the 'Net. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [security-advisories@freebsd.org: [FreeBSD-Announce] FreeBSD Security Advisory FreeBSD-SA-03:17.procfs]
On Fri, Oct 03, 2003 at 09:45:27PM -0400, Barney Wolff wrote: I'm finally motivated to ask, why don't security advisories contain the equivalent revs for -head? Surely I can't be the only person following -current who doesn't build every day. Simply because the SO does not support -CURRENT. Regards, -- wca ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [security-advisories@freebsd.org: [FreeBSD-Announce] FreeBSD Security Advisory FreeBSD-SA-03:17.procfs]
On Fri, Oct 03, 2003 at 06:54:04PM -0700, Will Andrews wrote: On Fri, Oct 03, 2003 at 09:45:27PM -0400, Barney Wolff wrote: I'm finally motivated to ask, why don't security advisories contain the equivalent revs for -head? Surely I can't be the only person following -current who doesn't build every day. Simply because the SO does not support -CURRENT. Does this mean that the situation can ever arise where a security bug is corrected in the advisory's announced releases but not in -current? Or, can we assume that as of the time of the security announcement the vulnerability has *always* been corrected in -current? Thanks, Barney -- Barney Wolff http://www.databus.com/bwresume.pdf I'm available by contract or FT, in the NYC metro area or via the 'Net. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Improvements to fsck performance in -current ...?
Bill Moran wrote:
Jens Rehsack wrote:
Don Lewis wrote:
On 2 Oct, Terry Lambert wrote:
[...]
Actually, write caching is not so much the problem, as the disk
reporting that the write has completed before the contents of
the transaction saved in the write cache have actually been
committed to stable storage.
Unfortunately, IDE disks do not permit disconnected writes, due
to a bug in the original IDE implementation, which has been
carried forward for [insert no good reason here].
Therefore IDE disks almost universally lie to the driver any
time write caching is enabled on an IDE drive.
In most cases, if you use SCSI, the problem will go away.
Nope, they lie as well unless you turn of the WCE bit. Fortunately
with tagged command queuing there is very little performance penalty for
doing this in most cases. The main exception to this is when you run
newfs which talks to the raw partition and only has one command
outstanding at a time.
Back in the days when our SCSI implementation would spam the console
whenever it reduced the number of tagged openings because the drive
indicated that its queue was full, I'd see the number of tagged openings
stay at 63 if write caching was disabled, but the number would drop
significantly under load (50%?) if write caching was enabled. I always
suspected that the drive's cache was full of data for write commands
that it had indicated to the host as being complete even though the data
hadn't been written to stable storage.
Unfortunately SCSI drives all seem to ship with the WCE bit set,
probably for benchmarking reasons, so I always have to remember to
turn this bit off whenever I install a new drive.
A message from this morning ('file system (UFS2) consistancy
after -current crash?') to this list describes exactly the
situation on my fileserver a few month ago, except my machine
runs with FreeBSD 4-STABLE and has an ICP-Vortex 6528RD controller.
I think, disk's or controllers (short hardware) write cache
is a problem. Maybe it shouldn't be in theory, but it is in
real world :-)
This is somewhat relevent to a discussion occurring this week on the
PostgreSQL performance mailing list.
A fellow was testing a number of caching options for disk drives, in
conjunction with the performance impact it had on Postgre. Near the
end of the discussion and his testing, he decided to do a plug test
(i.e., pull the power plug out of the wall while Postgre was running a
benchmark and see if the database was recoverable on reboot).
The tests don't 100% apply, since he was testing with Linux and XFS,
but I think the results speak VOLUMES!
You realize the sync() and fsync() commandos are severely BROKEN
under Linux already on VFS level? OK. kernel 2.6 will get it
right somehow. But until then one should not even think about
using Linux in a trully sensitive environment as a DB server.
I doubt seriously that it is the disk caching which is to be blamed here, since
otherwise crashing on journaling filesystems would be almost for sure
desasterous every time you do it... The cache sized on disks
are so thinny in comparision to the sector size that you will almost
immediately have the caches flushed anyway by a margin of well below
one second.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [security-advisories@freebsd.org: [FreeBSD-Announce] FreeBSD Security Advisory FreeBSD-SA-03:17.procfs]
On Fri, Oct 03, 2003 at 10:10:41PM -0400, Barney Wolff wrote: Does this mean that the situation can ever arise where a security bug is corrected in the advisory's announced releases but not in -current? Or, can we assume that as of the time of the security announcement the vulnerability has *always* been corrected in -current? No. Yes. The rule is that changes are always committed to -CURRENT first, unless they do not apply. This rule is rarely broken in FreeBSD, and certainly never broken for security issues. Regards, -- wca ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [security-advisories@freebsd.org: [FreeBSD-Announce] FreeBSD Security Advisory FreeBSD-SA-03:17.procfs]
On Fri, Oct 03, 2003 at 10:10:41PM -0400, Barney Wolff wrote: Does this mean that the situation can ever arise where a security bug is corrected in the advisory's announced releases but not in -current? No. Well, at least not to date. Or, can we assume that as of the time of the security announcement the vulnerability has *always* been corrected in -current? Yes. You will need to run cvsup to update your sources and at a minimum rebuild the vulnerable application. -- Steve ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [security-advisories@freebsd.org: [FreeBSD-Announce] FreeBSD Security Advisory FreeBSD-SA-03:17.procfs]
On Fri, Oct 03, 2003 at 07:17:50PM -0700, Will Andrews wrote: ... The rule is that changes are always committed to -CURRENT first, unless they do not apply. This rule is rarely broken in FreeBSD, and certainly never broken for security issues. That's of course expected and appreciated. But consider the different actions required of a reasonably paranoid FreeBSD SA on receipt of a security advisory: If following anything but -current, cvsup and check the versions of the listed files. If following -current, either trust that the updates made it to the mirror of choice, or look up on www.freebsd.org what the latest versions of the listed files are and check that you have them. Since the SO is presumably taking the changes from -current, I hope it would not be too much of an imposition to list those versions in the advisory as well. Thanks, Barney -- Barney Wolff http://www.databus.com/bwresume.pdf I'm available by contract or FT, in the NYC metro area or via the 'Net. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Q) Does em0 work under HTT?
Hi!
Does em{0,1} work under Hyperthreding enabled?
em0, seemingly is not working under my environment;
FreeBSD 5.1-CURRENT #15: Sat Oct 4 09:46:38 JST 2003
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/TYD3
Preloaded elf kernel /boot/kernel/kernel at 0xc0aae000.
Preloaded elf module /boot/kernel/acpi.ko at 0xc0aae2bc.
Timecounter i8254 frequency 1193182 Hz quality 0
CPU: Intel(R) Xeon(TM) CPU 2.80GHz (2799.22-MHz 686-class CPU)
Origin = GenuineIntel Id = 0xf27 Stepping = 7
Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,C
MOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE
Hyperthreading: 2 logical CPUs
However, I am not sure if it is because of HTT
enabled or not.
Any comments/suggestions are very appreciated.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [security-advisories@freebsd.org: [FreeBSD-Announce] FreeBSD Security Advisory FreeBSD-SA-03:17.procfs]
On Fri, Oct 03, 2003 at 10:48:53PM -0400, Barney Wolff wrote: On Fri, Oct 03, 2003 at 07:17:50PM -0700, Will Andrews wrote: ... The rule is that changes are always committed to -CURRENT first, unless they do not apply. This rule is rarely broken in FreeBSD, and certainly never broken for security issues. That's of course expected and appreciated. But consider the different actions required of a reasonably paranoid FreeBSD SA on receipt of a security advisory: If following anything but -current, cvsup and check the versions of the listed files. If following -current, either trust that the updates made it to the mirror of choice, or look up on www.freebsd.org what the latest versions of the listed files are and check that you have them. Since the SO is presumably taking the changes from -current, I hope it would not be too much of an imposition to list those versions in the advisory as well. If you're running -current, then you are reading the cvs-all or at least the cvs-src mailing list. It should be apparent that the fixes hit -current before the SA is announced. -- Steve ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
can't find kernel source tree error when building the kernel.
hello,
i just downloaded via cvsup the latest kernel for freebsd 5.1.
i had a problem with it, more exactly when i did a make depend
it stopped at some place, and gave me this error:
can't find kernel source tree
i fixed this by modifying this piece of code from /usr/src/sys/conf/kmod.mk
(it starts with line 167 in the file)
.for _dir in ${.CURDIR}/../.. ${.CURDIR}/../../.. /sys /usr/src/sys
.if !defined(SYSDIR) exists(${_dir}/kern/)
SYSDIR= ${_dir}
.endif
.endfor
.if !defined(SYSDIR) || !exists(${SYSDIR}/kern/)
.error can't find kernel source tree
.endif
i removed the last / from /kern/ and now it seems it can find the
directory.
i don't know if this is a general problem, or it is just in the case of
my system.
Claudiu Dragalina-Paraipan.
[EMAIL PROTECTED]
smime.p7s
Description: S/MIME Cryptographic Signature
Re: can't find kernel source tree error when building the kernel.
Hello Clau, C i removed the last / from /kern/ and now it seems it can find the C directory. C i don't know if this is a general problem, or it is just in the case of C my system. Same here. Setting SYSDIR helped for now. But the last commit message to kmod.mk: Revert rev. 1.86, I've fixed make(1) (make/dir.c,v 1.32). Hints that rebuilding make would be an alternative fix. -- Best regards, Maxmailto:[EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: can't find kernel source tree error when building the kernel.
On Fri, Oct 03, 2003 at 07:57:51PM +0300, Clau wrote:
hello,
i just downloaded via cvsup the latest kernel for freebsd 5.1.
i had a problem with it, more exactly when i did a make depend
it stopped at some place, and gave me this error:
can't find kernel source tree
i fixed this by modifying this piece of code from /usr/src/sys/conf/kmod.mk
(it starts with line 167 in the file)
.for _dir in ${.CURDIR}/../.. ${.CURDIR}/../../.. /sys /usr/src/sys
.if !defined(SYSDIR) exists(${_dir}/kern/)
SYSDIR= ${_dir}
.endif
.endfor
.if !defined(SYSDIR) || !exists(${SYSDIR}/kern/)
.error can't find kernel source tree
.endif
i removed the last / from /kern/ and now it seems it can find the
directory.
i don't know if this is a general problem, or it is just in the case of
my system.
How are you building the kernel? Are you using `make buildworld' first
and then `make buildkernel' (or `make kernel')?
Cheers,
--
Jacques Vidrine . NTT/Verio SME . FreeBSD UNIX . Heimdal
[EMAIL PROTECTED] . [EMAIL PROTECTED] . [EMAIL PROTECTED] . [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: can't find kernel source tree error when building the kernel.
Jacques A. Vidrine wrote:
On Fri, Oct 03, 2003 at 07:57:51PM +0300, Clau wrote:
hello,
i just downloaded via cvsup the latest kernel for freebsd 5.1.
i had a problem with it, more exactly when i did a make depend
it stopped at some place, and gave me this error:
can't find kernel source tree
i fixed this by modifying this piece of code from /usr/src/sys/conf/kmod.mk
(it starts with line 167 in the file)
.for _dir in ${.CURDIR}/../.. ${.CURDIR}/../../.. /sys /usr/src/sys
.if !defined(SYSDIR) exists(${_dir}/kern/)
SYSDIR= ${_dir}
.endif
.endfor
.if !defined(SYSDIR) || !exists(${SYSDIR}/kern/)
.error can't find kernel source tree
.endif
i removed the last / from /kern/ and now it seems it can find the
directory.
i don't know if this is a general problem, or it is just in the case of
my system.
How are you building the kernel? Are you using `make buildworld' first
and then `make buildkernel' (or `make kernel')?
Cheers,
cd /sys/i386/conf
/usr/sbin/config MYCONFIG
cd ../compile/MYCONFIG
make depend
make
make install
this is the entire process i do.
With respect,
Claudiu Dragalina-Paraipan.
[EMAIL PROTECTED]
smime.p7s
Description: S/MIME Cryptographic Signature
HEADSUP: routing table locking changes committed
I just committed a large set of changes to lock routing table entries. I've been running with these changes for several months w/o ill effects but as always beware. You will see some LOR's that I expect will go away with forthcoming work from Andre Oppermann. If not they'll get fixed before the 5.2 release. The most likely one you'll see is when ejecting a network card from a laptop. Please contact me directly if you see any problems that look related to these changes. Sam ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Q) Does em0 work under HTT?
At 09:51 PM 10/3/2003, you wrote:
Hi!
Does em{0,1} work under Hyperthreding enabled?
em0, seemingly is not working under my environment;
FreeBSD 5.1-CURRENT #15: Sat Oct 4 09:46:38 JST 2003
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/TYD3
Preloaded elf kernel /boot/kernel/kernel at 0xc0aae000.
Preloaded elf module /boot/kernel/acpi.ko at 0xc0aae2bc.
Timecounter i8254 frequency 1193182 Hz quality 0
CPU: Intel(R) Xeon(TM) CPU 2.80GHz (2799.22-MHz 686-class CPU)
Origin = GenuineIntel Id = 0xf27 Stepping = 7
Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,C
MOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE
Hyperthreading: 2 logical CPUs
However, I am not sure if it is because of HTT
enabled or not.
It seems to be working on mine just fine:
insane:/home/dave 4:05am [10] dmesg
Copyright (c) 1992-2003 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD 5.1-RELEASE #3: Thu Oct 2 16:26:09 EST 2003
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/INSANE1
Preloaded elf kernel /boot/kernel/kernel at 0xc0541000.
Timecounter i8254 frequency 1193182 Hz
Timecounter TSC frequency 2839788556 Hz
CPU: Intel(R) Pentium(R) 4 CPU 2.80GHz (2839.79-MHz 686-class CPU)
Origin = GenuineIntel Id = 0xf29 Stepping = 9
Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE
Hyperthreading: 2 logical CPUs
real memory = 1073676288 (1023 MB)
avail memory = 1037438976 (989 MB)
Pentium Pro MTRR support enabled
em0: Intel(R) PRO/1000 Network Connection, Version - 1.5.31 port
0xbc00-0xbc1f mem 0xff8e-0xff8f irq 10 at device 1.0 on pci2
em0: Speed:100 Mbps Duplex:Full
This is an MSI 875P Neo MB.
Do you have it enabled in the bios?
dave
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Q) Does em0 work under HTT?
From: dave [EMAIL PROTECTED] This is an MSI 875P Neo MB. Do you have it enabled in the bios? dave Yes, I enable HTT in the bios because without enabling it, freebsd-current does not recognize HTT. I mean that; with bios HTT disables; /sys/i386/i386/identcpu.c (cpu_procinfo CPUID_HTT_CORES) 16) returns 1 !! while bios HTT enables; /sys/i386/i386/identcpu.c (cpu_procinfo CPUID_HTT_CORES) 16) returns 2. My board is SuperMicro X5DAL-G. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
