Re: Freeze on my laptop.
Demelier David wrote: I'm so sad because FreeBSD is the one which can runs almost perfectly on my laptop. But it freezes. Sometime I just do anything and I want to click on a link in firefox, or open a terminal and then freeze. Sounds like a problem with the X graphics driver.. when it next happens, can you press Alt+F1 or Ctrl+Alt+F1 to get back to a text console? You might like to try upgrading your version of X to a newer version. - Andrew ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Only 70% of theoretical peak performance on FreeBSD 8/amd64, Corei7 920
The statements about the scheduler flipping between cores is also somewhat false, ULE does the right thing now for long-running computational threads. Furthermore, I can't see how a Gflops benchmark which fits in the CPU cache has anything to do with the memory architecture of the operating system. I assume to reach these results the benchmark was multi-threaded, and so I think I'd start by looking at the scheduler. Before that I'd probably look at the libraries, how they were compiled, differences in the compiler etc. - Andrew ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: hardware for home use large storage
http://www.supermicro.com/products/motherboard/ATOM/ICH9/X7SPA.cfm?typ=H Supermicro just released a new Mini-ITX fanless Atom server board with 6xSATA ports (based on Intel ICH9) and a PCIe 16x slot. It takes up to 4GB of RAM, and there's even a version with KVM-over-LAN for headless operation and remote management. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: ionice in FreeBSD?
Jordi Espasa Clofent wrote: ¿Is there some ionice(1) equivalent in FreeBSD? No. - Andrew ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: An old gripe: Reading via mmap stinks
Hi Mikhail, I assume these tests were done on UFS. Have you tried ZFS? I'm curious to see the results. - Andrew ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: ZFS performance degradation over time
Ivan Voras wrote: It is true that ZFS in theory doesn't do very well with random writes of any kind - the kind that torrent clients do should actually be the worst case for ZFS, *but*, this very much depends on the actual workload. ZFS has aggressive read-ahead for sequential read-aheads, so its worth noting that the performance problem can be mitigated by having lots of RAM free for read-ahead, as well as multiple vdevs in the zpool (so that it can be seeking all disks at once) - Andrew ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: gconcat file system damage
Peter C. Lai wrote: What is the status of growfs(8) then? As far as I can tell, it doesn't work reliably with UFS2 partitions, and it doesn't work at all with large partitions. People who do try to use it, can end up with corrupted filesystems... and the code is currently unmaintained. - Andrew ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: How to enable CPU turbo mode on FreeBSD?
Pierre-Luc Drouin wrote: I have an overclocked i7 920 CPU for which I have enabled Turbo Mode in the BIOS (21x multiplier). The base clock is set at 190 MHz, so the CPU frequency with Turbo mode activated should be 3990 MHz. However the maximum value FreeBSD amd64 shows for the CPU frequency in dmesg and sysctl is 3790 MHz. How can I enable the Turbo Mode? The turbo mode doesn't show up in dmesg or sysctl, it dynamically overclocks inside the CPU. Also, some motherboards silently disable turbo mode when you overclock the base clock. You may need to use a benchmark running on 1 vs 4 cores to see if turbo mode is having any effect. - Andrew ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: gconcat file system damage
How did you expand the filesystem onto the new volume? UFS2 expansion is not supported. I originally created the concatted disk in two steps. First I created the concat on my new mirrored disks and copied the files from my existing mirror in there. Second I appended the existing mirror to my concatted disk. It seemed to work fine, but now I'm seeing so much errors that I can only mount the concat r/o! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Cannot rm files when ZFS is full
The performance of ZFS is quite bad when the volume is nearly full anyway. I would recommend creating a parent filesystem with a space limit of 90% of the pool size, and then creating your other filesystems under that. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: ZFS - thanks
Patrick M. Hausen wrote: You cannot escape the poor write performance of RAID 5 and comparable setups with or without hardware. No matter how much you cache, one time a block must be written to disk. ZFS RAIDZ works differently: It is based on variable-sized blocks written to the disks based on incoming data stream, grouped into transactions. This makes it very efficient for clustering multi-threaded random I/O writes together into large physical disk writes. (The downside is it has to read the entire "stripe" even if you are only reading one byte, in order to calculate and verify the checksum.) - Andrew ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: ZFS: drive replacement performance
Mahlon E. Smith wrote: Strangely, the ETA is jumping all over the place, from 50 hours to 2000+ hours. Never seen the percent complete over 0.01% done, but then it goes back to 0.00%. Are you taking snapshots from crontab? Older versions of the ZFS code re-started scrubbing whenever a snapshot was taken. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: File system corruption
Pat Wendorf wrote: I spoke too soon I guess: A buddy of mine at the hosting provider took down the box and did a fsck -y on the var partition, this seems to have cleaned it up. It looks like the regular fsck -p could not repair it. You may like to put fsck_y_enable="YES" in your /etc/rc.conf, though this does not affect the root volume. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: experiences with Supermicro Twin servers? (6016TT / 6026TT / 6015TW)
Miroslav Lachman wrote: are there somebody with some experiences (bad or good) with Supermicro Twin servers? Mainly with 2U model 6026TT-TF or 1U model 6016TT-TF build on top of Intel 5520 Tylersburg (or any other?) They lack PS2 ports so you need USB keyboard to work properly. When I tried FreeBSD 7.1 on the previous generation (based on Intel 5400 Seaburg), the keyboard would not work at all, even though it worked with 7.0. The IPMI daughterboard conflicts with the on-board LAN when FreeBSD is running, causing packet loss and reduced performance and sometimes locks you out. So you need to use IPMI with a dedicated external LAN port - which then blocks the only available PCIe slot. - Andrew ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: backup strategy (Re: dump | restore fails)
Mikhail T. wrote: > To qualify for your (and your kind's) recognition then, a person > needs to have at least as much extra storage capacity as the > largest filesystem they are backing up. They also need > non-trivial scripting abilities, because the OS doesn't > include anything like what you are describing Mikhail, users would be well advised to check their backups using this option, without having to have the space to restore: -N Do the extraction normally, but do not actually write any changes to disk. This can be used to check the integrity of dump media or other test purposes. RESTORE(8) FreeBSD System Manager's Manual ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: dump | restore fails: unknown tape header type 1853384566
Mikhail T. wrote: > Now can one get /real/ support for the most basic functionality of the > most advanced modern Unix in the world? Thanks, I think before this goes any further, you will need to try rebooting/unmouting it, running fsck on it, and then dump the unmounted partition and see how that goes. - Andrew ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: dump | restore fails: unknown tape header type 1853384566
Mikhail T. wrote: dump 0aCf 64 /ibm/ibmo.0.2009-03-24.dump /old DUMP: WARNING: should use -L when dumping live read-write filesystems! I thought you said it was a read-only filesystem? In my experience, restore can sometimes throw warnings if you dump a live filesystem. It might be causing your errors? If possible, can you try completely unmounting the filesystem you are dumping and trying again? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Installing FreeBSD from USB flash drive - some experiments
Here's the steps I use to create a 1GB USB image: # dd if=/dev/zero of=bootable.image bs=1m count=1 oseek=1000 conv=sparse # mdconfig -a -t vnode -f bootable.image -u 0 # newfs -m 0 -o space -n /dev/md0 # mount /dev/md0 /mnt # cd /usr/src # make installworld DESTDIR=/mnt # make distribution DESTDIR=/mnt # make installkernel DESTDIR=/mnt # umount /mnt At this point you have a file "bootable.image" but instead of actually making that a bootable dd image, I choose to create a dump file which is a bit more flexible as you can restore it to a USB stick of any size. # dump -0 -C 8 -f - /dev/md0 | gzip -9 > bootable.dump.gz # mdconfig -d -u 0 At this point, you have a dump file which you can use to create a bootable USB as follows: Assuming the USB stick is /dev/da0 ! # dd if=/dev/zero of=/dev/da0 bs=16k # fdisk -BI /dev/da0 # disklabel -B -w /dev/da0s1 # newfs -m 0 -o space -n /dev/da0s1a # mount -o noatime,async /dev/da0s1a /mnt # gzcat bootable.dump.gz | ( cd /mnt ; restore -rvf - ) # umount /mnt Hope that helps - Andrew ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Performance with hundreds of nullfs mounts?
Ivan Voras wrote: I seem to remember hearing an anecdote somewhere that using hundreds (or thousands?) nullfs mounts for jails results in unreasonably bad file system access performance. Does somebody have this kind of setup / is it true? I'm using about several readonly nullfs mounts per jail: usr, bin sbin, lib, libexec, with ~20 jails per machine, and the speed is just fine, on 7.0-STABLE. - Andrew ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: gmirror does not initialize properally
Sorry, I meant "label -h" instead of just plain "label"... was getting confused with gstripe. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: gmirror does not initialize properally
Perhaps you used "gmirror configure" instead of "gmirror label" when you created the gmirror? You need to use "label" mode to actually save the configuration to disks for use on next bootup. - Andrew ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: jail: external and localhost distinction
Dmitry Morozovsky wrote: am I right concluding that under FreeBSD jail there is no way to attach two processes to the same port of external interface address and localhost? I tried to move rather standard two-tier nginx(ip:80)+apache(127.1:80) scheme into a jail and on apache start got In FreeBSD jails, the loopback interface doesn't exist - 127.0.0.1 is hardwired internally to point to the (external) jail IP. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: problem with "cold" hardware? [Was: panic in callout_reset: bad link in callwheel]
Andriy Gapon wrote: Previously I heard about problems with hardware running hot, but not with it being "cold". I put the word in quotes, because the system is in a room with normal room temperature. Any guesses what hardware part might be acting up like this? Power supply. Give all the capacitors a visual check. Or you may be drawing too much power from your rated supply. - Andrew ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: problems with sata disks (taskqueue timeout)
I think that if you use eSATA you probably need dedicated eSATA controller ports. eSATA standard specifies a higher voltage for the longer cable distances. Judging from the sporadic problem reports, Promise TX4 is probably not the best at signal purity to begin with so using it for eSATA pushes it over the edge. Hope that helps, - Andrew ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: fsck_y_enable: suboptimal/odd?
Andriy Gapon wrote: To me it seems like fsck_y passes suboptimal flags to fsck, it doesn't have to examine each and every filesystem in fstab. I think think this is because it does a quick check first to see if it can run the fsck in background after boot into multi-user mode. If it cannot, then fsck exits and is re-run with fsck -y and runs in foreground mode. - Andrew ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: ZFSv13 in RELENG7
Ivan Voras wrote: Andrew Snow wrote: Oliver Fromme wrote: On the other hand, 8-current seems to run quite stable at the moment; I have it running on a workstation for several weeks without problems. What date of CURRENT are you running? I tracked down crashes related to changes in SMBFS, but I am still experiencing almost weekly crashes such as machine running out of swap space in the middle of the night for no apparent reason.. Are you running rsync? Are the crashes happenning at about 3 am? (these two questions are unrelated) Yes, running lots of rsync. Also, yes, crashes have happened at night, not sure about 3am specifically, I've noticed more like 4am, 5am. But they always seem to happen when I'm not around. Most of our rsync processes happen at night starting from 7pm and running all night. - Andrew ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: ZFSv13 in RELENG7
Oliver Fromme wrote: On the other hand, 8-current seems to run quite stable at the moment; I have it running on a workstation for several weeks without problems. What date of CURRENT are you running? I tracked down crashes related to changes in SMBFS, but I am still experiencing almost weekly crashes such as machine running out of swap space in the middle of the night for no apparent reason.. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: slow zvol performance compared to files on the same pool
Pete French wrote: I was experimenting with iscsi earlier, using both a flat file as the backing store and also a zvol. I noticed that the zvol was giving me dreadful performance - reading at about 20 meg/second and writing at about 12. the fklat file gives about 45 meg/second both ways. i thouht it was to do wuth the iscsi layer, but I then tried it using dd on the machinbe itself and got the same results. it seems very curious - I am creating both the filesystem for the iscsi file and the zvol on the same pool, so the underlying discs (4 x 15k SCSI drives on U320) are the same in both places, as is the pool. anybody got any opinions ? this is on 7.1-RC2, but I have nothing else to compare it to. On 7.x (where ZFS is really quite broken for server use - don't waste too much time on it) the ZVOL code did an "fsync" after every single block write. Its a testament to your fast disks that you got as high as 12mb/s. I don't know why your read speed was so bad, but you should try again on 8-current as numerous fixes and improvements have happened. - Andrew ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: lagg(4) and failover
lagg is ultimately a problem as a high-availability solution since most switches do not support multi-switch 802.3ad yet, and most probably never well. So you are limited to a single switch. So 802.3ad is good only for aggregation, and not for high availability. What about using STP or RSTP instead of lagg? Which L2 managed switches like 3com and HP support. Then you could connect each of two NICs to a different switch, as well as connect the switches to each other. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: MFC ZFS: when?
The problem appears to be that the latest ZFS commit in 8-CURRENT relies on too many other new features that aren't in 7.1. After 7.1 is released, then perhaps ZFS and the other new code it requires can be moved into 7-STABLE? - Andrew ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: (actually ZFS) Re: Will XFS be adopted
Rudy wrote: Speaking of losing data on a ZFS system, I haven't yet (knock on wood) had a disk failure. Anyone have a disk failure occur and have an easy/hard time replacing the bad disk? On a system with AHCI, I can literally yank the SATA disks, zfs keeps working after a pause, and when I replace them, it rebuilds without intervention. However with the latest 8-current this stopped working and now the system crashes when I try this without using "atacontrol". But it seems related to ATA code and not ZFS. - Andrew ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Anyone used rsync scriptology for incremental backup?
Nikolay Denev wrote: Do you experience problems with the snapshots? Last time I tried something similiar for backups the bachine began to spit errors after a few days of snapshots. http://lists.freebsd.org/pipermail/freebsd-fs/2008-February/004413.html Haven't seen that one specifically, but I experienced several big problems with ZFS on 7.x, and when I upgraded to 8-current (~July) with pjd's extra patches, it solved everything. Best thing now is to sit tight and wait for the patches to make it back into the source tree. - Andrew ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Anyone used rsync scriptology for incremental backup?
I've written a backup system using rsync's ability to generate "diff" files using batch file mode. It works like this: 1. We take a backup of the live system and store that 2. We generate a diff batch file against an older copy 3. We update the older copy to be identical to the current copy In this way, each day we generate a batch file that lets us step back one day. The diffs themselves, compressed with gzip, and extremely space efficient. We can step back potentially hundreds of days, though it seems to throw errors sometimes when backing up Windows boxes, which I haven't tracked down yet. But to be honest, soon you can save yourself a lot of hassle by simply using ZFS and taking snapshots. It'll be faster, and with compression very space efficient. - Andrew ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Short SMART check causes disk op timeouts
IMO, A much better option to run on a weekly basis is to use a RAID controller with "verify" feature (eg. 3ware) or use ZFS "scrub" mode. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: non-root user can not create zfs filesystem?
lhmwzy wrote: where is the patch? I can't find it in freebsd-fs@ and [EMAIL PROTECTED] http://people.freebsd.org/~pjd/patches/zfs_20080727.patch.bz2 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: zfs quota question
I love ZFS, but I suddenly found out last night that I have lost the ability tto do a 'du' on a directory to work out if it will fit onto a CD or not :-) I have created a shell script, /usr/local/bin/dirsize : #!/bin/sh find $1 -type f -ls | awk '{j += $7} END {print j}' Usage: dirsize ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
trying to track down UFS "dup alloc" message on iSCSI
I am playing with an iSCSI device on FreeBSD client running UFS2 on the device over a LAN. Everything works well until I reboot the iSCSI server - the client pauses for a minute or so then continues working after iSCSI server comes back. No I/O errors are reported. Everything seems to work fine for a little while! But shortly afterwards, I get a panic with the message panic: ffs_valloc: dup alloc It seems related to the length of the delay the iSCSI device is paused - restarting the iSCSI target daemon process doesn't cause the problem but rebooting the whole target box does cause it. 1. Could this be related to the patch Matt Dillon created years ago which I found here? http://leaf.dragonflybsd.org/mailarchive/bugs/2005-01/msg00093.html 2. Can anyone think of any other reason this might happen? I know I am stretching UFS to the limits here, expecting it to pause and restart after more than a minute of locked disk :-) However, since all I/O eventually complete successfully and no errors are reported, I find it suspicious. Cheers - Andrew ps. running latest iSCSI code 2.1 on latest 7-STABLE box. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: recommended setup for amd64 7-STABLE with ZFS, Samba 3.2 and possibly ACLs?
Holger Kipp wrote: - FreeBSD 7-Stable (amd64 with 8GB RAM) + special tuning necessary (apart from increasing kernel memory to 1 or more GB for ZFS) I haven't had much luck running ZFS under heavy load on 7-stable, I was forced to install 8-current and use the latest patch set posted by pjd. Don't jump in until you've tested it with a realistic production load. The nice thing was that 8-current didn't require any special kernel or memory tuning at all (except for disabling ZIL, but not everyone seems to have to do this). - Samba 3.2 + ACLs possible directly under ZFS? As far as I know ZFS does not support ACLs under FreeBSD at this time, and implementing it is non-trivial. - Andrew ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: UNEXPECTED SOFT UPDATE INCONSISTENCY; RUN fsck MANUALLY
Jeremy Chadwick wrote: You're the first person I've encountered who has had to disable the ZIL to get stability in ZFS; ouch, that must hurt. Its not so bad: this machine is doing backups with rsync, sometimes running 50 simultaneously. This workload doesn't contain any need for synchronous operations, and any files which didn't get written after a crash can simply be re-rsync. But I hope eventually it will be fixed! I'm talking about the most commonly-encountered problem: kmem exhaustion. People want to be able to install FreeBSD then say "Okay! Time to give ZFS a try!" on some separate disks, and have it work. Personally I don't think there's much point worrying about how to boot off ZFS at this stage until the code is up to date, stable, and running 7-STABLE branch. Until then I will also prefer to have a UFS root volume and just run ZFS for /usr and /home, because I still don't completely trust ZFS and I have a high value on being able to boot the system and have my tools available in /bin and /sbin. - Andrew ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: UNEXPECTED SOFT UPDATE INCONSISTENCY; RUN fsck MANUALLY
Dan Nelson wrote: That'd be handy, but at least on my system the data prefetcher isn't really called often enough to make a difference either way (assuming the counts are accurate). Metadata prefetch is a big win, however. arcstats.prefetch_data_hits: 4538242 (13%) arcstats.prefetch_data_misses: 29298997 arcstats.prefetch_metadata_hits: 593799808 (96%) arcstats.prefetch_metadata_misses: 21582847 You are much luckier than me. For obvious reasons, I would like to completely disable data prefetch but leave on metadata prefetch. I believe it would speed up the filesystem plus save RAM (less wasted use of ARC). But especially desktop systems would not need to waste space on such aggressive prefetching. - Andrew ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: UNEXPECTED SOFT UPDATE INCONSISTENCY; RUN fsck MANUALLY
Zaphod Beeblebrox wrote: Also, there exists data within the ARC (I'm always tempted to say the ARC Cache, but that is redundant) that is also then in paging memory. OK, but one advantage of ZFS memory consumption is under heavy write loads, where much of the memory is used to store and reorder writes. The heavy memory consumption under reading is a shame, but ZFS has to cache and use more metadata than UFS, so its a price you pay for the extra features and benefits. What I think we need is a way to turn off read-caching except for metadata. This allows ARC to only be used more efficiently. Currently you can turn all read-ahead on or off, with the provided sysctl tunables, but would be easy to implement a metadata-only option. I found that access speed suffers when metadata is not prefetched. If you are running an X workstation with 2GB or less memory, then I agree ZFS is a bad default choice. For my workstation I would still use ZFS, I would: * turn down ARC size, * turn off read-ahead except for metadata, * and even turn off ZIL and write cache flushing, which solves the annoyance of unpredictable delays when flushing buffers. Not a good choice for a server but perfect for a workstation. - Andrew ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: UNEXPECTED SOFT UPDATE INCONSISTENCY; RUN fsck MANUALLY
Matthew Dillon wrote: It can take 6 hours to fsck a full 1TB HD. It can take over a day to fsck larger setups. Putting in a few sleeps here and there just makes the run time even longer and perpetuates the pain. We have a box with millions of files spread over 2TB, on a 16 disk RAID. Foreground fsck takes almost 8 hours, so background fsck, which takes almost 24 hours or more, is my only option when I want to bring the box back online quickly. And UFS Snapshots are so slow as to be completely useless. I've now converted the volume to ZFS, and am now enjoying instant boot time and higher speed I/O under heavy load, at the expense of memory consumption. My recommendation? Default UFS back to a synchronous fsck and stop treating ZFS (your only real alternative) as being so ultra-alpha that it shouldn't be used. Completely agree. ZFS is the way of the future for FreeBSD. In my latest testing, the memory problems are now under control, there is just stability problems with random lockups after days of heavy load unless I turn off ZIL. So its nearly there. If only ZFS also supported a network distributed mode. Or can we convince you to port Hammer to FreeBSD? :-) - Andrew ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: UNEXPECTED SOFT UPDATE INCONSISTENCY; RUN fsck MANUALLY
However, as a core general purpose filesystem, it seems to have flaws, not the least of which is a re-separation of file cache and memory cache. For me, this doesn't matter because ZFS is so much faster than UFS overall. Even if you don't use any of its features, the latest version does sequential I/O and heavy random I/O faster than UFS on the same hardware for me. Cases where UFS is faster are proving to be the exception rather than the rule. However, I cannot recommend its use until it is stable, which it currently still is not, under very heavy load. - Andrew ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Upcoming Releases Schedule...
Another thing that I believe would help: Voting on PRs. Currently a maintainer has no idea if a PR is due to one guy's flakey hardware or if 50 people have had the same problem and are waiting for a fix. For each major problem report, there are probably many people who tried FreeBSD on particular hardware and just silently gave up when it failed. Ability to "vote up" on a PR on the freebsd website would give maintainers a tool to see which PRs are affecting the userbase. - Andrew ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Upcoming Releases Schedule...
Mark Linimon wrote: So, in your opinion, what's the way to reconcile all these demands (features + stability + long-term support of release branches) with a group that is 95%-plus volunteer effort? Its important to me that people keep using FreeBSD. Numbers are important. To that end I'm happy for developers to keep working hardest on the parts of FreeBSD they find most rewarding. Something's got to give and you can't stop it by creating more beaurocracy and red tape. Another thing I think is important is for new hardware to be perpetually sent to those who can implement drivers and create patches. I don't feel the FreeBSD foundation is doing enough in that regard. Not talking about big ticket items like server farms, just new motherboards every time a new CPU or chipset is released. - Andrew ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Upcoming Releases Schedule...
Jo Rhett wrote: Because frankly we're going to be forced to run our own internal release management process instead. I guess this is not surprising, as this appears to be what every other business using significant amounts of freebsd in production are doing today. I'm afraid you've hit the nail on the head. Stable, Current, these words mean nothing to me anymore, I'm using 8-CURRENT to get stable ZFS with the ata driver from 7 (because 8's doesn't work), and the old BTX loader because the new one locks up on all my newer hardware. Then there's the bag of patches I am now carrying around from release to release, some for bug fixes and some for feature enhancements, none of which are in the base system for whatever reason. I think FreeBSD is getting in a difficult position now because there's so much cool new stuff being shoe-horned in, but without the necessary volume of contributors to back it up with testing and bug fixes. There's some truth to what you say, in that I would love to be directly contributing to the FreeBSD effort but instead I feel I'm running around putting out little fires all the time. Plus this era of 4 to 8 CPU cores has meant I am seeing bugs that are difficult to pin down and only occur under production load. - Andrew ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: IPMI Console: No luck once OS is booted
Larry Rosenman wrote: There is a key release timeout checkbox on the keyboard/mouse settings tab for the KVM that wasn't checked. Checking it fixed it. Sorry for the noise. :( Actually, it worked *ONCE*, and now is not behaving itself. Any ideas from other SuperMicro users? In the IPMI card's web interface, I remember having to fiddle with the "Keyboard/Mouse emulation" option to solve this problem. Try changing to the alternative settings. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: IMPORTANT! Network is unreachable
Usually if there is more than IP in a given subnet on an interface, you give it a /32 netmask. Only the first IP in a subnet should have the full netmask. So your example should look like this: inet 10.11.16.14 netmask 0xff00 broadcast 10.11.16.255 inet 10.11.16.9 netmask 0x broadcast 10.11.16.9 KES wrote: # uname -a FreeBSD gorodok.kes.net.ua 7.0-RELEASE-p3 FreeBSD 7.0-RELEASE-p3 #0: Sun Aug 3 13:18:21 EEST 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/KES_KERN_v7 i386 # netstat -nr Routing tables Internet: DestinationGatewayFlagsRefs Use Netif Expire default10.11.16.1 UGS 0 3758rl0 10.0.0.0/1610.11.16.2 UG 0 150rl0 10.11.15.0/24 link#2 UC 00rl1 10.11.16.0/24 link#1 UC 00rl0 10.11.16.1 00:e0:4c:59:50:7e UHLW2 421rl0953 10.11.16.2 00:03:79:01:9b:d0 UHLW20rl0786 127.0.0.1 127.0.0.1 UH 0 122lo0 Internet6: Destination Gateway Flags Netif Expire ::1 ::1 UHL lo0 fe80::%lo0/64 fe80::1%lo0 U lo0 fe80::1%lo0 link#4UHL lo0 ff01:4::/32 fe80::1%lo0 UC lo0 ff02::%lo0/32 fe80::1%lo0 UC lo0 # ifconfig rl0 rl0: flags=8843 metric 0 mtu 1500 options=8 ether 00:0e:2e:db:4f:d4 inet 10.11.16.14 netmask 0xff00 broadcast 10.11.16.255 inet 10.11.16.9 netmask 0xff00 broadcast 10.11.16.255 media: Ethernet autoselect (100baseTX ) status: active ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Stable SATA pci card for FreeBSD 6.x/7.0
I heartily recommend 3ware controllers for FreeBSD 6/7, even if you only need 2 ports. - Andrew ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Multi-machine mirroring choices
We have deployed an IMAP server running on Cyrus on FreeBSD 6.2, with a 500GB UFS2 partition mirrored with geom_mirror and geom_gate across a dedicated 1gbps link. It has proven to be very stable and reliable after appropriate tweaking. The uptime of the mirror is usually 1-3 months, sometimes it seems to break randomly, possibly because our timeout is too low. In any case, it doesn't take too long to rebuild at about 60mb/s. (I recently tested the same solution with FreeBSD-7 and found it now goes at a full 100mb/s.) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: taskqueue timeout
Matthew Dillon wrote: Try that first. If it helps then it is a known issue. Basically a combination of the on-disk write cache and possible ECC corrections, remappings, or excessive remapped sectors can cause the drive to take much longer then normal to complete a request. The default 5-second timeout is insufficient. From Western Digital's line of "enterprise" drives: "RAID-specific time-limited error recovery (TLER) - Pioneered by WD, this feature prevents drive fallout caused by the extended hard drive error-recovery processes common to desktop drives." Western Digital's information sheet on TLER states that they found most RAID controllers will wait 8 seconds for a disk to respond before dropping it from the RAID set. Consequently they changed their "enterprise" drives to try reading a bad sector for only 7 seconds before returning an error. Therefore I think the FreeBSD timeout should also be set to 8 seconds instead of 5 seconds. Desktop-targetted drives will not respond for over 10 seconds, up to minutes, so its not worth setting the FreeBSD timeout any higher. More info: http://www.wdc.com/en/library/sata/2579-001098.pdf http://en.wikipedia.org/wiki/Time-Limited_Error_Recovery - Andrew ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: BIND update?
Xin LI wrote: Speaking as my own: Base system needs more conservative QA process, e.g. ... rushing into a "presumably patched" state would not be a very good solution. I second this opinion. When there is hype all over the net about a new vulnerability, it is too easy to allow ill-considered changes to be rushed in without enough critical thought and testing. - Andrew ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 6.3-RELEASE versus 5.2-RELEASE
Joe Kelsey wrote: The entire problem comes down to the definition of -RELEASE. Jo apparantly feels that they can ONLY run -RELEASE branded code at their workplace. That means that they cannot run any form of -STABLE. Interesting, and unfortunate. Empirically, I always felt that the -STABLE branch shortly after each -RELEASE is the most stable. I suspect the reason is large numbers of people install or upgrade to a -RELEASE, discover and report a number of bugs which subsequently get fixed. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: console access
Jeremy Chadwick wrote: Okay, so then your original comment ("The same thing happened when trying to use a USB CDROM drive, so I suspect USB boot support is at fault somehow") might actually not be caused by FreeBSD at all? The reason I say that: OK, good point. I didn't try any other OS, I just tried FreeBSD 6 and 7 off a USB CDROM drive, virtual media CDROM, and virtual media floppy, both of which use USB emulation. I assumed that if I tried, say, a Windows CD, it would just work because that's usually Supermicro's target market. What Supermicro box is having USB booting problems? Its a rather new X7DWT motherboard (Intel 5400 chipset, Xeon CPU) Good luck with getting your USB drives back :-) - Andrew ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: console access
Jeremy Chadwick wrote: Supermicro IPMI cards are notoriously buggy. A few of the system engineers at Yahoo! who I know continually bitch and moan about how horrible they are. My advice: do not install the IPMI card which is causing your problems. The remote KVM control feature was an important requirement so the card is staying. Luckily it uses the Intel gigabit NIC which seems to work well in 7-STABLE, I have no complaints so far. Every feature works well except virtual media. Booting FreeBSD off of USB devices is known to be broken; see "BTX, boot2, and loader" section at the below URL: http://wiki.freebsd.org/JeremyChadwick/Commonly_reported_issues Thats interesting - I regularly use USB sticks to boot freebsd as its easier for installation on cluster machines/routers that lack CDROM drives. I've used it on, I think, half a dozen different motherboards/architectures and its worked well on all of them, the Supermicro box was the only broken one. Because virtual media emulates a USB device I'm pretty sure thats why it wasnt working - the USB problem, not a problem with the IPMI card. - Andrew ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: console access
Andy Kosela wrote: Then you can even remotely mount iso images from your laptop at home directly on the server (very handy sometimes). Incidentally, when I tried to use a Supermicro IPMI card for networked remote media, FreeBSD boot loader crashed the machine (video went haywire and it didnt boot). The same thing happened when trying to use a USB CDROM drive, so I suspect USB boot support is at fault somehow. - Andrew ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
cpufreq broken on core2duo (was: powerd is doing nothing?)
Evren Yurtesen wrote: When you say that it doesnt work, does it give an error or? In my case it doesnt give any errors just says it set it but I see that nothing is set. Here's one box: CPU: Intel(R) Core(TM)2 Duo CPU E8500 @ 3.16GHz cpu0: on acpi0 est0: on cpu0 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 61a49200600091a device_attach: est0 attach returned 6 p4tcc0: on cpu0 Here's another one: CPU: Intel(R) Xeon(R) CPU E5410 @ 2.33GHz cpu0: on acpi0 est0: on cpu0 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 720072006000720 device_attach: est0 attach returned 6 p4tcc0: on cpu0 SYSCTLs On the first one: dev.cpu.0.freq: 2786 dev.cpu.0.freq_levels: 2786/-1 2437/-1 2089/-1 1741/-1 1393/-1 1044/-1 696/-1 348/-1 Attempting to change dev.cpu.0.freq has no effect and says: sysctl: dev.cpu.0.freq: Invalid argument ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: powerd is doing nothing?
The problem is not powerd but cpufreq. While cpufreq appears to work well on my Athlon X2, it has never worked on any of my Core2Duo or Core-based Xeon servers. This is a great shame as these newer Intel chips have the capability to clock up and down very quickly and seamlessly. Who can fix the cpufreq driver? I think it simply hasn't been updated with the latest data from Intel. - Andrew ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Bad TCP performance with large MTU on 7-stable.
Arnaud Houdelette wrote: I also tried with tso disabled. Same results. Is it related to the re(4) driver ? Or to the TCP stack ? Having used em driver with 7-RELEASE and 7-STABLE, I can assure you that large MTU size (9100) works well and gives 100mb/s transfer rates easily. So I can only conclude it is releated to the re driver. - Andrew ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: thread scheduling at mutex unlock
But I think that it is not "fair" that at re-lock former owner gets the lock immediately and the thread that waited on it for longer time doesn't get a chance. I believe this is what yield() is for. Before attempting a re-lock you should call yield() to allow other threads a chance to run. (Side note: On FreeBSD, I believe only high priority threads will run when you yield(). As a workaround, I think you have to lower the thread's priority before yield() and then raise it again afterwards.) - Andrew ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Dreadful gmirror performance - suggested changes to 'prefer'
I havent looked at the code in detail, but I can't see that it would be too difficult. What do people think ? If the first drive is always priority=0, then it is going to be stuck at the highest priority, or under your plan, the lower priority. My original idea OTOH (starting the counting at 100) solves the problem with aone-line patch. Call me biased but this is what I prefer :-) - Andrew ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Best-performing disk I/O options for a DBMS server on 7-STABLE
Karl Denninger wrote: I assume SCSI is the best path forward (either SA/SCSI or traditional) but have been out of the loop on the card(s) that work properly for a good long while. I've used several of the new 3ware SATA PCI-express cards: 2, 4 and 16 ports. They always work really well under FreeBSD 6 and 7, and are very fast. I haven't tried their SAS cards personally but I understand that it is equally good. FWIW, I have had bad experiences with Areca. - Andrew ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Dreadful gmirror performance, though each half works fine
Zaphod Beeblebrox wrote: I use this patch for sbin/geom/class/mirror/geom_mirror.c Change: md.md_priority = i - 1; To: md.md_priority = i - 1 + 100; I hate to ask for the "right" solution, but shouldn't we be patching the gmirror userland to accept a priority argument to label and make the kernel part listen to that? This patch does make sense --- but it doesn't go far enough. Also, it seems sensible that you should be able to modify the priority values of a running disk. Both of those are good ideas. But for years, no one can be bothered making a patch. At least my patch is only one line, and solves 90% of the problem, and still no one can be bothered committing it. Maybe we should apply my patch for now, until someone works on the rest. - Andrew ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Dreadful gmirror performance, though each half works fine
Pete French wrote: I did some benchmarking, and "load" gives me a bit better performance than "round-robin" so I've elected to use that. Haven't tried "prefer" as syncing all the drives backwards and forwards to get the preferences set seems a bit too much like hard work! I use this patch for sbin/geom/class/mirror/geom_mirror.c Change: md.md_priority = i - 1; To: md.md_priority = i - 1 + 100; This makes the first disk with a priority of 100 instead of 0, which makes it much easier to use "prefer" properly. It's frustrating, it is *so* close to being workable with iscsi, and the performance is very good, but if it is going to keep locking up on me then I just cant use it that way :-( After failing many times with iSCSI, I use geom_gate with the following ggatec options: -t 30 -q 32768 -R 262144 -S 262144 -o rw It seems to be very reliable and fast, but you have to use "prefer" to get good performance, I only write across the network and not read. Load and round-robin lead to slow reads during periods of heavy writes. Hope that helps, - Andrew ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Panic in kqueue_close from kern_close
Hello, Can anyone help me try and work out what went wrong here? I am running on 7.0-PRERELEASE on amd64. However, the file kern_event.c hasn't changed anytime since then in 7-STABLE. Fatal trap 12: page fault while in kernel mode cpuid = 2; apic id = 02 fault virtual address = 0x9a050 fault code = supervisor write data, page not present instruction pointer = 0x8:0x8027f877 stack pointer = 0x10:0xb4c0a9e0 frame pointer = 0x10:0xff005c0ccda0 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 12949 (smtpd) trap number = 12 panic: page fault cpuid = 2 Uptime: 6d11h8m19s Physical memory: 8183 MB (kgdb) bt #0 doadump () at pcpu.h:194 #1 0x0004 in ?? () #2 0x8029e6ef in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409 #3 0x8029eb37 in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:563 #4 0x803df54e in trap_fatal (frame=0xc, eva=Variable "eva" is not available. ) at /usr/src/sys/amd64/amd64/trap.c:724 #5 0x803df903 in trap_pfault (frame=0xb4c0a930, usermode=0) at /usr/src/sys/amd64/amd64/trap.c:641 #6 0x803e00a1 in trap (frame=0xb4c0a930) at /usr/src/sys/amd64/amd64/trap.c:410 #7 0x803c6fde in calltrap () at /usr/src/sys/amd64/amd64/exception.S:169 #8 0x8027f877 in kqueue_close (fp=0xff0114352000, td=0xff003bcb3680) at /usr/src/sys/kern/kern_event.c:1457 #9 0x802762cf in fdrop (fp=0xff0114352000, td=0xff003bcb3680) at file.h:297 #10 0x802775cd in closef (fp=0xff0114352000, td=0xff003bcb3680) at /usr/src/sys/kern/kern_descrip.c:1958 #11 0x80277d3e in kern_close (td=0xff003bcb3680, fd=Variable "fd" is not available. ) at /usr/src/sys/kern/kern_descrip.c:1054 #12 0x803dfaeb in syscall (frame=0xb4c0ac70) at /usr/src/sys/amd64/amd64/trap.c:852 #13 0x803c71eb in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:290 #14 0x000800bee16c in ?? () Previous frame inner to this frame (corrupt stack?) The offending line: #8 0x8027f877 in kqueue_close (fp=0xff0114352000, td=0xff003bcb3680) at /usr/src/sys/kern/kern_event.c:1457 1457while ((kn = SLIST_FIRST(&kq->kq_knlist[i])) != NULL) { The process that made the syscall was a postfix smtpd inside a jail. It had been running fine for almost a week before this. Any hints appreciated, - Andrew ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"