12.0->12.1 and beadm/bectl issues
Hi, After upgrading from 12.0-RELEASE-p11 to 12.1-RELEASE I was having some issues with kld_load and linux support which, after searching [1], seemed due to a missing /boot folder after the upgrade. This was fixed with 'ln -s /bootpool/boot /boot'. Then yesterday when I was trying to switch from quarterly packages to latest I wanted to use a new boot environment and so went through the beadm create and beadm activate but it wouldn't activate with a zpool.cache cp message and it left the new BE mounted under /tmp. After umounting and destroying I repeated the process with bectl and it worked fine, however, upon reboot I was not in the new BE but the same BE and the new one was still marked as activated for use next boot. So firstly: are the be* issues related to the earlier upgrade fix? Secondly: shouldn't beadm and bectl behave the same? Thirdly: how can I properly activate and boot to a new BE? Below is the command output of the beadm/bectl process described above. If there's any more information I can provide please let me know. Thanks, Jon [1] https://forums.freebsd.org/threads/cannot-identify-running-kernel-after-upgrading-to-freebsd-12.68772/ This is a two disk mirrored zpool on GELI with encrypted swap as configured out of the box by the 12.0 installer. root@prometheus:~ # uname -a FreeBSD prometheus 12.1-RELEASE-p1 FreeBSD 12.1-RELEASE-p1 GENERIC amd64 root@prometheus:~ # beadm list BEActive Mountpoint Space Created 12_0-RELEASE-p11 - -1.1G 2019-10-29 21:33 12_1-RELEASE-p1-quarterly NR / 32.7G 2019-11-05 22:24 root@prometheus:~ # beadm create test Created successfully root@prometheus:~ # beadm list BEActive Mountpoint Space Created 12_0-RELEASE-p11 - -1.1G 2019-10-29 21:33 12_1-RELEASE-p1-quarterly NR / 32.7G 2019-11-05 22:24 test - -8.0K 2019-11-20 13:24 root@prometheus:~ # beadm activate test cp: /tmp/BE-test.pJtR9Rs6/boot/zfs/zpool.cache and /boot/zfs/zpool.cache are identical (not copied). root@prometheus:~ # beadm list BEActive Mountpoint Space Created 12_0-RELEASE-p11 - - 1.1G 2019-10-29 21:33 12_1-RELEASE-p1-quarterly NR / 32.7G 2019-11-05 22:24 test - /tmp/BE-test.pJtR9Rs6 136.0K 2019-11-20 13:24 root@prometheus:~ # beadm umount test Unmounted successfully root@prometheus:~ # beadm list BEActive Mountpoint Space Created 12_0-RELEASE-p11 - -1.1G 2019-10-29 21:33 12_1-RELEASE-p1-quarterly NR / 32.7G 2019-11-05 22:24 test - - 136.0K 2019-11-20 13:24 root@prometheus:~ # beadm destroy test Are you sure you want to destroy 'test'? This action cannot be undone (y/[n]): y Destroyed successfully root@prometheus:~ # beadm list BEActive Mountpoint Space Created 12_0-RELEASE-p11 - -1.1G 2019-10-29 21:33 12_1-RELEASE-p1-quarterly NR / 32.7G 2019-11-05 22:24 root@prometheus:~ # bectl list BEActive Mountpoint Space Created 12_0-RELEASE-p11 - - 1.14G 2019-10-29 21:33 12_1-RELEASE-p1-quarterly NR / 32.7G 2019-11-05 22:24 root@prometheus:~ # bectl create test root@prometheus:~ # bectl list BEActive Mountpoint Space Created 12_0-RELEASE-p11 - - 1.14G 2019-10-29 21:33 12_1-RELEASE-p1-quarterly NR / 32.7G 2019-11-05 22:24 test - - 8K2019-11-20 13:25 root@prometheus:~ # bectl activate test successfully activated boot environment test root@prometheus:~ # bectl list BEActive Mountpoint Space Created 12_0-RELEASE-p11 - - 1.14G 2019-10-29 21:33 12_1-RELEASE-p1-quarterly N / 8K2019-11-05 22:24 test R - 32.7G 2019-11-20 13:25 root@prometheus:~ # beadm list BEActive Mountpoint Space Created 12_0-RELEASE-p11 - -1.1G 2019-10-29 21:33 12_1-RELEASE-p1-quarterly N /8.0K 2019-11-05 22:24 test R - 32.7G 2019-11-20 13:25 root@prometheus:~ # Following a reboot I'll still be running in 12_1-RELEASE-p1-quarterly and test will still be marked R. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
SV: Dummynet
Hi Vadim! -Ursprungligt meddelande- Från: owner-freebsd-sta...@freebsd.org [mailto:owner-freebsd- sta...@freebsd.org] För Vadim Goncharov Skickat: den 21 september 2010 14:48 Till: freebsd-stable@freebsd.org Ämne: Re: Dummynet Hi Jon Otterholm! On Mon, 20 Sep 2010 10:00:48 +0200; Jon Otterholm wrote about 'Dummynet': Installed a new router running 8-stable and encounter some problems when configuring dummynet pipes: When setting buckets above 1024... ipfw pipe 91 config bw 100Mbit/s mask src-ip 0x buckets 4096 ...I get the following error: Clamp sched buckets to 1024 (was 4096) Try to write buckets 4096 before mask, though this is unlikely to help, there are some troubles with 8.1's changes in parser. Didn't help. # sysctl net.inet.ip.dummynet.hash_size net.inet.ip.dummynet.hash_size: 4096 Also, make sure you're doing this before any packets actually went to dummynet (e.g. just after reboot). This is set in /etc/sysctl.conf ... from man ipfw: buckets hash-table-size Specifies the size of the hash table used for storing the various queues. Default value is 64 controlled by the sysctl(8) variable net.inet.ip.dummynet.hash_size, allowed range is 16 to 65536. Am I missing something here? This worked fine in the 7-branch. The reason is that luigi@ merged ipfw3 from -CURRENT between 8.0R and 8.1R. There are many new features and, as seen from many PRs, many new bugs. OK. I just have to wait then for luigi@ to submit fixes. Thanks for the tips and info. Should I expect and be prepared for any other flaws from the current version of dummynet in 8-STABLE? //JO ___ 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
Dummynet
Hi. Sorry for cross-posting, got nothing back from freebsd-ipfw... Installed a new router running 8-stable and encounter some problems when configuring dummynet pipes: When setting buckets above 1024... ipfw pipe 91 config bw 100Mbit/s mask src-ip 0x buckets 4096 ...I get the following error: Clamp sched buckets to 1024 (was 4096) # sysctl net.inet.ip.dummynet.hash_size net.inet.ip.dummynet.hash_size: 4096 from man ipfw: buckets hash-table-size Specifies the size of the hash table used for storing the various queues. Default value is 64 controlled by the sysctl(8) variable net.inet.ip.dummynet.hash_size, allowed range is 16 to 65536. Am I missing something here? This worked fine in the 7-branch. //JO ___ 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
7.2-RC2 Install Feedback
Folks, Just FYI-ish, yesterday I made a 7.2-RC2 bootonly CD and successfully installed it on an i386. There was one weirdness with the www packages menu where it wouldn't display the package name properly. It looked like some odd form of line wrapping that started at the right-most column and then was off-by a line such that it (maybe?) overwrote itself on the next line. It looked OK if you scrolled all the way to the bottom and then scrolled back up. Also, I banged my head against problems installing emacs (aborted with error -1), until I finally realized that xemacs-21.4 was already installed. I think there was some form of conflict (?) that prevented two versions from being installed. Seemed odd to me in any event, and not very evident why the (package) install was being rejected. Thanks! jdl ___ 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: FreeBSD 7.2-RC1 Available
Got it on Vista Home 64 VMware server
Two CPU's two gigs of ram.
Works grate so far. fast too
On Fri, 17 Apr 2009 13:15:03 -0400
Ken Smith kensm...@cse.buffalo.edu wrote:
The first of two planned Release Candidates for the
FreeBSD 7.2-RELEASE
cycle is now available. Testing of some of the recent
work would be
particularly appreciated. This includes:
- bce(4) updated (there is a report that lagg(4) does
not work after the update, fixing that may need to be
done as an Errata Notice after the release)
- testing of the threading libraries
- amr(4) should be fixed
A fix for the vm_page_insert: page already inserted
panics has been
committed to RELENG_7_1 this morning so it missed the
7.2-RC1 builds.
If you wind up being hit by that you can try a normal
source based
update to the current state of RELENG_7_1 and that
problem should go
away.
We have slipped by two days at this point but otherwise
are on track
with the target release schedule which is here:
http://www.freebsd.org/releases/7.2R/schedule.html
We continue to watch for problems both on the mailing
lists and in Gnats
but at this point we know of nothing we consider
show-stopper calibre.
Unless something that bad does surface as a result of
7.2-RC1 testing we
should be sticking to the schedule.
The ISO images and FTP install trees are available on the
FreeBSD Mirror
sites. Using the primary site as an example:
ftp://ftp.freebsd.org/pub/FreeBSD/releases/${arch}/ISO-IMAGES/7.2/
where ${arch} is one of amd64 i386, ia64, pc98, or
sparc64. The
builds for powerpc are still in progress, it should
become available
in a day or two.
Checksums for the ISO images are at the bottom of this
message. The
amd64 and i386 sets include a *preliminary* set of
packages.
If you would like to do a source-based update to 7.2-RC1
from an
already installed machine you can update your tree to
RELENG_7_1 using
normal cvsup/csup methods.
The freebsd-update(8) utility supports binary upgrades of
i386 and amd64
systems running earlier FreeBSD releases. Systems
running 7.0-RELEASE,
7.1-RELEASE, or 7.2-BETA1 can upgrade as follows:
# freebsd-update upgrade -r 7.2-RC1
During this process, FreeBSD Update may ask the user to
help by merging
some configuration files or by confirming that the
automatically performed
merging was done correctly.
# freebsd-update install
The system must be rebooted with the newly installed
kernel before continuing.
# shutdown -r now
After rebooting, freebsd-update needs to be run again to
install the new
userland components, and the system needs to be rebooted
again:
# freebsd-update install
# shutdown -r now
Users of earlier FreeBSD releases (FreeBSD 6.x) can also
use freebsd-update to
upgrade to FreeBSD 7.2-RC1, but will be prompted to
rebuild all third-party
applications (e.g., anything installed from the ports
tree) after the second
invocation of freebsd-update install, in order to
handle differences in the
system libraries between FreeBSD 6.x and FreeBSD 7.x.
Checksums:
MD5 (7.2-RC1-amd64-bootonly.iso) =
2e4474ca4924ac589adf600b1d7d7168
MD5 (7.2-RC1-amd64-disc1.iso) =
47e1a823636dec2e8a88e2d4794d87da
MD5 (7.2-RC1-amd64-disc2.iso) =
6761b5cf2ac2d8399c28b58ccdddb2a5
MD5 (7.2-RC1-amd64-disc3.iso) =
02c798036ed43f4f346518d584783a72
MD5 (7.2-RC1-amd64-docs.iso) =
ece13f382c308ce05f7dfc1aef4d0a62
MD5 (7.2-RC1-amd64-dvd1.iso) =
2a25cc807849fa2987c032c87053c8e9
MD5 (7.2-RC1-amd64-livefs.iso) =
fbff690090c9cf3d5cf1b07b6c019b40
MD5 (7.2-RC1-i386-bootonly.iso) =
85783d47f3d03dcdd6859cbe94fa41e2
MD5 (7.2-RC1-i386-disc1.iso) =
4ef516f7fa88ab6a6f67f6fba3e9e86e
MD5 (7.2-RC1-i386-disc2.iso) =
f5bf94273f64f4e4f968322990bd32eb
MD5 (7.2-RC1-i386-disc3.iso) =
634cce798ea17117a009f53e07dadda0
MD5 (7.2-RC1-i386-docs.iso) =
2b019c24576c03c382bd3748baeb473b
MD5 (7.2-RC1-i386-dvd1.iso) =
ed88046ecae36fd1dd12157534243106
MD5 (7.2-RC1-i386-livefs.iso) =
81637ca4b1668ff44047fe4b6fc71447
MD5 (7.2-RC1-ia64-bootonly.iso) =
414bf45bbbae757dff03acea5484635f
MD5 (7.2-RC1-ia64-disc1.iso) =
0f26204eaa8c63a37b34ef0101dcb278
MD5 (7.2-RC1-ia64-disc2.iso) =
cc206f814e5da015042485bfe5c30605
MD5 (7.2-RC1-ia64-disc3.iso) =
3888415a65514805546d8ad50cf0f650
MD5 (7.2-RC1-ia64-docs.iso) =
07c5c83f05248f7b7dec7e210e2cbf9e
MD5 (7.2-RC1-ia64-livefs.iso) =
df5ffb89ae0a5e9aea8cc12a75c0d14a
MD5 (7.2-RC1-pc98-bootonly.iso) =
b4b0b16bc0afa9ce734d1c4a303fc13c
MD5 (7.2-RC1-pc98-disc1.iso) =
33dd272b30bab2f1ad2a3455a177c3b5
MD5 (7.2-RC1-pc98-livefs.iso) =
7ffda81d7d91bb91db202de7c30afadd
MD5 (7.2-RC1-sparc64-bootonly.iso) =
a220e5318eb10e4ff3b6c783d76a1b28
MD5 (7.2-RC1-sparc64-disc1.iso) =
c23469659332723ce600073611497f52
MD5 (7.2-RC1-sparc64-docs.iso) =
96fc98f8ac071a5942fc25fa4ab940eb
SHA256 (7.2-RC1-amd64-bootonly.iso) =
6.3 PRERELEASE
I had 6.2 stable all setup had gnome 2.18 all humming along 100% java eclipse, tomcat, bah bah bah! updated src rebuilt only to find 6.2 is gone 6.3 prerelease! ( I think there should be a button we need to push to get software we DONT want! j/k) with my setup as it is, can i back date my cvsup file rebuild back to 6.2 stable not losing any settings or software ? ___ 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 PRERELEASE
- Original Message - From: Skip Ford [EMAIL PROTECTED] To: Jon Holstrom [EMAIL PROTECTED] Cc: freebsd-stable@freebsd.org Sent: Friday, November 09, 2007 11:55 AM Subject: Re: 6.3 PRERELEASE Jon Holstrom wrote: I had 6.2 stable all setup had gnome 2.18 all humming along 100% java eclipse, tomcat, bah bah bah! updated src rebuilt only to find 6.2 is gone 6.3 prerelease! ( I think there should be a button we need to push to get software we DONT want! j/k) with my setup as it is, can i back date my cvsup file rebuild back to 6.2 stable not losing any settings or software ? If you go back to 6.2-STABLE, you'll be left with a system that can never be updated again since 6.2-STABLE no longer exists. Any time you updated it, the name would change again which you seem to have a problem with. If you keep following RELENG_6, you'll end up running 6.3-STABLE after the release. Or, you could choose to run 6.2-RELEASE (RELENG_6_2) or 6.3-RELEASE (RELENG_6_3) after it's released. For right now, there's really no difference between 6.2-STABLE and 6.3-PRERELEASE. If you do nothing, you'll eventually be running 6.3-STABLE. -- Skip ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] Thanks Skip, this is what i was thinking, but it didnt sink in tel you said it. Peace to you ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Freebsd.org is down
Check the freebsd-questions list for more info ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
FREEBSD_4_EOL tag, last known index file?
Is there a port index file that corresponds to the FREEBSD_4_EOL tag? I am unable to rebuild the index from the tagged checkout. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
5 stable 6 stable stops with error
Intel P III 933, 1/2 gig ram, plain old P3 box Ok, installed 5.5 release. setup X gnome cvsuped the 5 stable branch Ran make buildworld make buildkernel make installkernel reboot ran mergemaster -p in the /usr/src/ dir then after i run make installworld I get the below error same thing if i do it all on 6 stable also. Can some one help me get past this please ? creating osreldate.h from newvers.sh touch: not found *** Error code 127 Stop in /usr/src/include. *** Error code 1 Stop in /usr/src/ *** Error code 1 Stop in /usr/src/ *** Error code 1 Stop in /usr/src/ *** Error code 1 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
installation issue 6.2 AMD64-bit 3ware 9550SX
I am trying to install FreeBSD-stable 6.2 64-bit from CDROM and the installation hangs. The installation hangs after the 3ware 9000 Series Storage Controller is recognized (using the twa0 driver). If I disable ACPI, I get to the sysinstall screen, however, no hard drives are detected. Here is a list of the system details (2) AMD Opteron 2210 processors Super Micro HDa8-2 Motherboard 3ware 9550SX-12 SATA RAID Controller (8) Seagate 7200.10 750 Gb SATA hard drives GeForce 7300GS PCI-E video card Sony DVD/CDROM Sony AIT4 tape drive nVidia Corp MCP55 ethernet ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Gnome2 2.16 fails on Notification-daemon-0.3.6
Installing Gnome2 2.16 on FreeBSD 5.5 stable from /x11/gnome2 port. I have looked looked and the site is gone or down 100 % http://www.galago-project.org/ How can we fix this ? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Panic on DOH! ata_alloc_request failed!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Oct 22, 2006, at 04:32 , Søren Schmidt wrote: Jon Passki wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hey all, (I'm off list, please include me in any replies) (Søren, please let me know if you do not want to be emailed in the future directly! You seem to be the ATA RAID FreeBSD goto guy. Apologies if you did not want to be solicited). I just received a panic w/ this in /var/log/messages (uname and dmesg at the end of the email / book): Oct 21 04:17:05 prometheus kernel: DOH! ata_alloc_composite failed! I fixed a few nits in this area after 6.1-RELEASE, so you should upgrade to 6-stable or 6.2-betasomething to get this fixed. I will upgrade to 6.2-R when it comes out, thanks Søren! Jon -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Darwin) iD8DBQFFO8Z3ZpJsLIS+QSIRAh6sAJ0Q9V8C5DtBzYc9Oxsdw3DXDlNemQCfaBf2 SVuv/g3sdZ/twsfYXqDeLeg= =4vCc -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Panic on DOH! ata_alloc_request failed!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hey all, (I'm off list, please include me in any replies) (Søren, please let me know if you do not want to be emailed in the future directly! You seem to be the ATA RAID FreeBSD goto guy. Apologies if you did not want to be solicited). I just received a panic w/ this in /var/log/messages (uname and dmesg at the end of the email / book): Oct 21 04:17:05 prometheus kernel: DOH! ata_alloc_composite failed! The system would have been performing a weekly dump (live snapshot) at the time. The motherboard is a SuperMicro P4SCi [1], which uses an Intel 6300ESB onboard SATA w/ RAID 0/1 support (Adaptec). I have one RAID volume created, ar0 as a RAID 1 between two 300GB disks. I previously have seen this error when we were importing a MySQL database on the box w/ heavy disk I/O. Oct 9 21:41:23 prometheus kernel: DOH! ata_alloc_request failed! Oct 9 21:41:29 prometheus kernel: FAILURE - out of memory in ata_raid_init_requ est Oct 9 21:41:29 prometheus last message repeated 2 times Oct 9 21:41:29 prometheus kernel: g_vfs_done():ar0s1e[WRITE (offset=108675514368 , length=16384)]error = 5 Oct 9 21:41:29 prometheus kernel: g_vfs_done():ar0s1e[WRITE (offset=108486344704 , length=16384)]error = 5 Oct 9 21:41:29 prometheus kernel: g_vfs_done():ar0s1e[WRITE (offset=108486623232 , length=16384)]error = 5 Oct 9 23:01:17 prometheus kernel: FAILURE - out of memory in ata_raid_init_requ est Oct 9 23:01:17 prometheus kernel: FAILURE - out of memory in ata_raid_init_requ est Oct 9 23:01:17 prometheus kernel: g_vfs_done():ar0s1e[WRITE (offset=118889250816 , length=16384)]error = 5 Oct 9 23:01:17 prometheus kernel: g_vfs_done():ar0s1e[WRITE (offset=118889742336 , length=16384)]error = 5 I've seen two other similar issues on the mailing lists: http://lists.freebsd.org/pipermail/freebsd-amd64/2006-August/008770.html http://lists.freebsd.org/pipermail/freebsd-amd64/2006-April/008047.html http://lists.freebsd.org/pipermail/freebsd-stable/2005-November/ 019559.html The first two didn't seem to have any follow-ups. This is the only bug report with ata_alloc_composite returned in the query: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/89310 I restarted the box, manually verified the array using the BIOS utils (12 errors fixed, eek!), and had to run fsck manually due to an UNEXPECTED SOFT UPDATE INCONSISTENCY on /dev/ar0s1e. I had unreferenced files, too (yeah for backups). Since I didn't have a dumpon device, I don't have a core to post. Here's the grep of sysctl alluded to in the Nov. 2005 email above: sysctl -a | grep ^ata_ ata_composit:196,0, 0,100, 3928 ata_request: 204,0, 0, 76, 127512 How do I monitor or fix this? 'sync' or restart every so often? Any assistance would be appreciated! TIA, Jon [1] http://www.supermicro.com/products/motherboard/P4/E7210/P4SCi.cfm uname -a FreeBSD prometheus.int.hursk.com 6.1-RELEASE FreeBSD 6.1-RELEASE #0: Sun May 7 04:32:43 UTC 2006 [EMAIL PROTECTED]:/usr/obj/ usr/src/sys/GENERIC i386 (who believes in patches ;-) dmesg afterboot=yes Copyright (c) 1992-2006 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 6.1-RELEASE #0: Sun May 7 04:32:43 UTC 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC ACPI APIC Table: IntelR AWRDACPI Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Intel(R) Pentium(R) 4 CPU 2.80GHz (2795.24-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 Features2=0x4400CNTX-ID,b14 Logical CPUs per core: 2 real memory = 1072562176 (1022 MB) avail memory = 1040633856 (992 MB) ioapic0: Changing APIC ID to 2 ioapic0 Version 2.0 irqs 0-23 on motherboard ioapic1 Version 2.0 irqs 24-47 on motherboard kbd1 at kbdmux0 acpi0: IntelR AWRDACPI on motherboard acpi0: Power Button (fixed) Timecounter ACPI-fast frequency 3579545 Hz quality 1000 acpi_timer0: 24-bit timer at 3.579545MHz port 0x408-0x40b on acpi0 cpu0: ACPI CPU on acpi0 acpi_button0: Power Button on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 pcib1: ACPI PCI-PCI bridge at device 3.0 on pci0 pci1: ACPI PCI bus on pcib1 em0: Intel(R) PRO/1000 Network Connection Version - 3.2.18 port 0xb000-0xb01f mem 0xf230-0xf231 irq 18 at device 1.0 on pci1 em0: Ethernet address: 00:30:48:84:01:22 pcib2: ACPI PCI-PCI bridge at device 28.0 on pci0 pci2: ACPI PCI bus on pcib2 pcib3: PCI-PCI bridge at device 1.0 on pci2 pci3: PCI bus on pcib3 sf0: Adaptec ANA-62044 10/100BaseTX port 0xc000-0xc0ff mem 0xf200-0xf207 irq 24 at device 4.0 on pci3 miibus0: MII bus on sf0 ukphy0: Generic IEEE
FreeBSD 5.5 (VMware) on Fedora core 5
Hello, I am running Fedroa core 5 Dual PIII 800, with VMware server. I am not sure if or should i install FreeBSD 5.5 stable +SMP kernel! I am looking at a basic web server config, Apache 1.3 PHP4 MySQL 4.1 OSCommerce ProFTP some sort of mail server also, POP, SMTP. Its all for the sake of learning it and doing it as of now. FreeBSD is intalled as a Virutal Machine now. but after thinking a bit, got stuck with the SMP kernel! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: more weird bugs with mmap-ing via NFS
From Mikhail Teterin [EMAIL PROTECTED], Tue, Mar 21, 2006 at 06:58:01PM -0500: I'll try the TCP mount, workaround. If it helps, we can assume, our UDP NFS is broken for sustained high bandwidth writes :-( What? I think you misunderstood. UDP NFS fairs poorly under network congestion; it has nothing to do with FreeBSD. Any iota of frame-loss will induce costly time-outs and hang-ups and quickly become intolerable. Let us consider a few cases: 1) a server attached with 1Gb ethernet and clients with 100Mb connections. Server begins sending data to a client. The client pipe is narrower and the switch begins to buffer the frames. Switches _do not_ have very much buffer space. A high-end switch may have 2MB. Likely some of this can be shared between ports; some will be reserved per port. Let us assume all of the memory is on. d(Memory_Used)/dt = 1000Mb/s - 100Mb/s = 900MB/s. Thus... in less than 10ms the switch will run out of buffer space... and then *drop* frames. oops. bye-bye UDP NFS. 2) a server is attached with 1Gb ethernet and the clients with 1Gb ethernet. Multiple clients write to the NFS server simultanteously... Okay, okay. It isn't quite this bad because there will only be so many outstanding requests, but it doesn't take many clients actively contending for a shared resource (the link to the server) to cause glitches... This is precisely the problem TCP was intended to solve. NFS UDP is an antiquated solution to TCP overhead on the underpowered machines of yesteryear. NFS UDP has essentially no use on modern hardware. -Jon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: pf: synproxy broken
On Thursday 16 March 2006 07:39, Yuriy N. Shkandybin wrote: Hello from ealier 6.0 there is problem with synproxy in pf filter: this one 6.1-PRERELEASE #2: Wed Mar 15 02:02:37 MSK 2006 pf.conf just with single rule pass in quick on lo0 proto tcp from any to any port 22 flags S/SA synproxy state result telnet 127.0.0.1 22 Trying 127.0.0.1... Connected to 127.0.0.1. Escape character is '^]'. and it's hangs pfctl -s rules -v No ALTQ support in kernel ALTQ related functions disabled pass in quick on lo0 proto tcp from any to any port = ssh flags S/SA synproxy state [ Evaluations: 966392Packets: 0 Bytes: 0 States: 1 ] pfctl -s state No ALTQ support in kernel ALTQ related functions disabled self tcp 127.0.0.1:22 - 127.0.0.1:44819 PROXY:DST without synproxy all is ok There is PR 86072 about that with unclear results. Jura Hi. Do you have set state-policy if-bound in your options section of /etc/pf.conf? That's cleared up synproxy problems for me before. hth, jon b ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: RELENG_4 on flash disk and swap
If you feel this situation is undesirable, the first thing to do is to put together the patches necessary to allow the kernel to actually track how much ram+swap might be needed to cover the address-space allocations that have been granted. This isn't trivial: just start thinking about shared allocations, forking, copy-on-writem, etc. In order to make this change costless I suspect you'll have to hide it behind a kernel config option. Maybe you'll bill it as mere instrumentation. Then worry about convincing people that overcommit shouldn't be the only option. But once you have your kernel config option to enable proper accounting it should be a short-hop to making a sysctl that can disable overcommit and enforce limits based on the previously mentioned accounting. Most importantly though you won't need to convince anyone that the default ought to be changed. SIGDANGER has essentially been rejected universally by everyone but its creators (IBM), and as it is unusual, don't expect anyone to write a program that uses it. Ditto for any solution that involves madvise or expecting programs to prefault their pages. Other suggestion: build a time machine to go back to 1990 and get early (pages guaranteed) and late (overcommitted) allocation written into POSIX. Somewhat accepted is to ensure allocations must be backed but to also support a M_NORESERVE flag in mmap to permit overcomitted allocations. Anyways, no matter what you must first give the kernel the necessary accounting code. For the record: I believe in overcommit, but I recognize that it violates the semantics people were (foolishly) taught in school. Also, when the system is page-starved it kills the largest consumer of pages that has the same UID as the process that pushed the system over the limit---not merely the largest consumer of pages. So you see, running critical services that carefully pre-allocate and fault their memory is possible within the overcommit framework. Jon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: sharedmem in jail.
There was some discussion about improving this situation a bit; i.e., by permitting an option wherein sysvipc could be per jail. Did this ever come to fruition? Ivan: you should be aware that Kris's short disclaimer really means that enabling the sysctl exposes sysvipc aware processes on the host to malicious programs in the jails (and between jails...) On Mon, 27 Feb 2006, Ivan Kolosovskiy wrote: Ivan Kolosovskiy wrote: FreeBSD 6.0-p4. Sharedmem in jail doesnot works. I got Function not implemented. Sorry, i found security.jail.sysvipc_allowed sysctl flag =) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: freeBSD 5.5 Prerelease ( 5.4 stable )
Hello Group. I CVSuped a few days back from the time of the release of 5.5 PreRelease (bata1) got 5.4 stable february 1, 10 GMT was the last day beforee 5.5 hit the CVS server(s) (calif ) Sorry i dont have the time to mess with bug tracking and what not, but i need a working OS, not a bata ! Thank you everyone for your help ! - Original Message - From: Kris Kennaway [EMAIL PROTECTED] To: Chris [EMAIL PROTECTED] Cc: Kris Kennaway [EMAIL PROTECTED]; Jon Holstrom [EMAIL PROTECTED]; freebsd-stable@freebsd.org Sent: Wednesday, February 08, 2006 9:43 PM Subject: Re: freeBSD 5.5 Prerelease ( 5.4 stable ) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: freeBSD 5.5 Prerelease ( 5.4 stable )
- Original Message - From: Bartosz Fabianowski [EMAIL PROTECTED] To: Jon Holstrom [EMAIL PROTECTED] Cc: freebsd-stable@freebsd.org Sent: Friday, February 10, 2006 12:00 PM Subject: Re: freeBSD 5.5 Prerelease ( 5.4 stable ) but i need a working OS, not a bata ! If you don't like using a beta (nothing wrong with that), you definitely should not be using -stable either. There are even less promises regarding the reliability and quality of -stable than there are of a beta. After all, during the prerelease and beta cycles, the tree is getting in shape for a release and there is a focus on fixing as many little nits as possible. In between releases, bigger MFCs might hit -stable from time to time and make it less reliable. So, while you are getting confused by the branch name changing, you should also rethink whether you want -stable at all. It really seems like you should be aiming for RELENG_5_4 (and then RELENG_5_5 once 5.5 is out) instead. - Bartosz freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] Thank you much for your input. after thinking this over a few weeks ago, it did seem to be the best bet to go for 5.4 stable. i gave 6.0 release its chance, things didnt seem to work as i needed them. 5.4 release does not support Eclipse 3.1 at all. this is why i needed 5.4 stable ! as hard as i tried to stay simple on using FreeBSD, FreeBSD led me to 5.4 stable as of Feb1, 2006 at 10:00 GMT. all working this far. Software has its own mind, it will has led us here. i could go on on about what i think about all this. but the truth is, FreeBSD software led me here ! What i am upto with freebsd 5.4 stable ? --==--==--==--==--==--==--==-- FreeBSD 5.4 stable. Apache 1.3 PHP4 MySQL 4.1 OSCommerce 2.2 MS2 JavaSDK 1.4 Tomcat 5 Eclipse 3.1 --- needs 5.4 stable PHPEclipse --==--==--==--==--==--==--==-- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: freeBSD 5.5 Prerelease ( 5.4 stable )
- Original Message - From: Jon Holstrom [EMAIL PROTECTED] To: freebsd-stable@freebsd.org Sent: Sunday, February 05, 2006 5:04 PM Subject: freeBSD 5.5 Prerelease ( 5.4 stable ) Hello Group CVSuped a 5.4 release box 2 days ago ( was going for 5-stable ) CVS server gave me 5.5 prerelease two days later everything is 100 % installed had to run pkg_deinstall on gnome-2-10 after running portupgrade to install gnome-2.12 run down on PC i worked with Compaq 5003US PIII 866 , 370 pingrid 384 megs of ram ( 1 stick of PC 133, 256 RAM, 1 stick of PC 133, 128 RAM ) 40 gig Maxtor ATA 100 onboard Intel 810 chipset 3Com networkcard This post was not a post in need of help It was has been a port to warn your all any other pore SOB's that CVSuping for 5-stable gets you 5.5 PRERELEASE ( BATA1 ) reread the darn post, i never did ask for help Have a good day everyone. Sorry to have caused a ruffle ! I will stay away from the send button.___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: freeBSD 5.5 Prerelease ( 5.4 stable )
any one know the date to get 5.4 stable ? i am not able to find the date to CVsup 5.4 stable as 5.5 is vary slow is to buggy - Original Message - From: Jon Holstrom [EMAIL PROTECTED] To: freebsd-stable@freebsd.org Sent: Sunday, February 05, 2006 5:04 PM Subject: freeBSD 5.5 Prerelease ( 5.4 stable ) Hello Group CVSuped a 5.4 release box 2 days ago ( was going for 5-stable ) CVS server gave me 5.5 prerelease two days later everything is 100 % installed had to run pkg_deinstall on gnome-2-10 after running portupgrade to install gnome-2.12 run down on PC i worked with Compaq 5003US PIII 866 , 370 pingrid 384 megs of ram ( 1 stick of PC 133, 256 RAM, 1 stick of PC 133, 128 RAM ) 40 gig Maxtor ATA 100 onboard Intel 810 chipset 3Com networkcard ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: freeBSD 5.5 Prerelease ( 5.4 stable )
i cvsuped for 5.4 stable a few days ago. server gave me 5.5 prerelease works good, gnome2-2.12 ( had to pkg_deinstall -r deinstall gnome 2.10) Xorg 6.9.0 just slow as can be - Original Message - From: Mike Jakubik [EMAIL PROTECTED] To: Jon Holstrom [EMAIL PROTECTED] Cc: freebsd-stable@freebsd.org Sent: Monday, February 06, 2006 4:45 PM Subject: Re: freeBSD 5.5 Prerelease ( 5.4 stable ) Jon Holstrom wrote: any one know the date to get 5.4 stable ? i am not able to find the date to CVsup 5.4 stable There is no such thing as 5.4-stable there is only 5-stable. as 5.5 is vary slow is to buggy 5.5 does not exist yet, how did you determine thats its slow and buggy? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
freeBSD 5.5 Prerelease ( 5.4 stable )
Hello Group CVSuped a 5.4 release box 2 days ago ( was going for 5-stable ) CVS server gave me 5.5 prerelease two days later everything is 100 % installed had to run pkg_deinstall on gnome-2-10 after running portupgrade to install gnome-2.12 run down on PC i worked with Compaq 5003US PIII 866 , 370 pingrid 384 megs of ram ( 1 stick of PC 133, 256 RAM, 1 stick of PC 133, 128 RAM ) 40 gig Maxtor ATA 100 onboard Intel 810 chipset 3Com networkcard ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NFS UDP mounts on RELENG_6?
A very critical question here is the network topology. UDP NFS _cannot_ be used across switches where the ports are operating at different speeds--unless the UDP packet size is to be smaller than MTU. Be sure and verify that every link between the server and the client are operating at the same speed. -Jon On Sun, 18 Dec 2005, Fabian Keil wrote: Oliver Brandmueller [EMAIL PROTECTED] wrote: On Fri, Dec 16, 2005 at 04:30:31PM +0100, Fabian Keil wrote: Oliver Brandmueller [EMAIL PROTECTED] wrote: I'm experiencing problems when trying to mount NFS filesystems from a RELENG_6 server (FreeBSD hudson 6.0-STABLE FreeBSD 6.0-STABLE #0: Wed Dec 14 16:59:55 CET 2005 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/NFS-32-FBSD6 i386) to either 5.4-STABLE or 6-STABLE clients. mounting works fine, but afterwards the access to the filesystem on the client stalls. As soon as I mount the FS with a TCP mount everything works as expected. The mounts worked fine on UDP when the server was 5.4-STABLE. There is just a plain GigE switch involved, no firewalls or routing. Anyone else experiencing those problems or having an idea? I just copied some files (200 MB) from a NFS Server running FreeBSD africanqueen.local 6.0-STABLE FreeBSD 6.0-STABLE #5: Thu Dec 15 19:31:12 CET 2005 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/AFRICANQUEEN i386 without problems. My client runs FreeBSD 5.4, I use GigE as well, but no switch. Which kind GigE Interface do you use? Client: [EMAIL PROTECTED] ~ $pciconf -lv| grep em0 -A 2 [EMAIL PROTECTED]:1:0: class=0x02 card=0x05491014 chip=0x101e8086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '82540EP Gigabit Ethernet Controller (Mobile)' Server: [EMAIL PROTECTED] ~ $pciconf -lv| grep re[01] -A 2 [EMAIL PROTECTED]:9:0: class=0x02 card=0x816910ec chip=0x816910ec rev=0x10 hdr=0x00 vendor = 'Realtek Semiconductor' device = 'RTL8169 Gigabit Ethernet Adapter' -- [EMAIL PROTECTED]:10:0: class=0x02 card=0x601b182d chip=0x816910ec rev=0x10 hdr=0x00 vendor = 'Realtek Semiconductor' device = 'RTL8169 Gigabit Ethernet Adapter' re0 is made by Vivanco, re1 is a Sitecom card. Fabian -- http://www.fabiankeil.de/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [SOLVED] Re: NFS UDP mounts on RELENG_6?
No shame. This is a common problem, and if you think real hard you should start getting quasy about UDP NFS under high load. The problem arises because if part of a UDP packet is lost the entire packet is lost, and as UDP NFS uses fixed packet sizes... this means the system never recovers if frames stop droping perpetually. Its easy to see how this happens for speed mismatches, the switch (vs a router) provides no buffering and therefore frames from the fast source are dropped. Now imagine that you have many clients all writing data to the NFS server at once... Suddently that pipe into the server is like a narrow straw. Ooops. I haven't see any evidence that suggests using NFS with UDP is actually useful. IMO, its a false economy. TCP processing takes on the order of 1uS of CPU time--which is on the order of the frame latency through a single switch! That is to say, nothing, but the behavior of TCP NFS under load (when it counts) is superior. TCP SACK and interrupt aggregation are better ways of squeezing extra performance out of your hardware than simply using UDP... Just my two cents. -Jon On Mon, 19 Dec 2005, Oliver Brandmueller wrote: Hi. On Mon, Dec 19, 2005 at 01:01:34AM -0800, Jon Dama wrote: A very critical question here is the network topology. UDP NFS _cannot_ be used across switches where the ports are operating at different speeds--unless the UDP packet size is to be smaller than MTU. Be sure and verify that every link between the server and the client are operating at the same speed. *ouch* shame on me. I looked at interfaces, links, errors - everything. I found the problem in a misconfiguration and you just pointed at it: The server has not been booted for a few hundred days before upgrading. From an old test there was an mtu 9000 for the NFS interface still in /etc/rc.conf (while it has been reset after failed tests with other hardware on that network manually to 1500). So: SORRY for making everybody mad here. It was just me being blind. Thanx for pointing me at that! - Oliver -- | Oliver Brandmueller | Offenbacher Str. 1 | Germany D-14197 Berlin | | Fon +49-172-3130856 | Fax +49-172-3145027 | WWW: http://the.addict.de/ | | Ich bin das Internet. Sowahr ich Gott helfe. | | Eine gewerbliche Nutzung aller enthaltenen Adressen ist nicht gestattet! | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [SOLVED] Re: NFS UDP mounts on RELENG_6?
I haven't see any evidence that suggests using NFS with UDP is actually useful. IMO, its a false economy. On modern hardware anyway. Keep in mind that NFS was written to run on a 25MHz (or so) 68020. 100% agreed. That is precisely what assumed when I made my statement. -Jon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 6.0 as storage server with raid5?
Whatever you do, don't complain about it on this list, or you'll just be told that if you really wanted raid, you should be running SCSI disks Ah, no please complain so that if s/w raid gives you trouble, there will be something to point to when and if people doubt there are still problems (if indeed there are) Though I think jim is being entirely too harsh: The scary, poorly tested part of software raid is recovery. Thousands might roll out a s/w raid but if the h/w raid wasn't cost justified its unlikely that the HDs in the raid are actually going to be pressed into failing in any reasonable period of time that would reveal trouble in the recovery/degraded operating modes. Second, if you use s/w raid, pay close attention to the way your partitions line up. Third, SATA drives are actually quite good. You're primarily looking at a degraded MTBF versus a server grade SCSI disk. This could well mean just about nothing if your transaction volume is actually pretty low. imo, it would be nice to see MTBF quoted in a few parts: MTBF while seeking regularly (i.e., at some duty cycle) and MTBF in the bearings and other rotational components alone (MTBF while the disk is spun-up), and number of spin-up/spin-down cycles. Fourth, the major limitations on SATA drives right now is that FreeBSD does not support NCQ and therefore has no access to reliable write-completion information wrt SATA drives. and adapter). I'd strongly suggest anyone using GEOM raid to do some fault insertion testing of their setup prior to actually relying on it. This is very good advice. -Jon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 6.0 cron is running on GMT
What is the output of date vs date -u on your system? What's the value of machdep.adjkerntz ? Is /etc/localtime intact? Does anything change if you rerun tzsetup? On Sat, 26 Nov 2005, Brett Glass wrote: At 07:20 PM 11/25/2005, Jon Dama wrote: Uh, the problem would be that kernel does not know that the CMOS clock is set to the local time. Standard practice is that the CMOS clock should be set to UTC. We've never set the CMOS clock to UTC/GMT on any previous version of FreeBSD, and yet have never seen this behavior. By the way, the date command does report the correct time. It's cron that seems to be getting the time wrong. --Brett Glass ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 6.0 cron is running on GMT
Uh, the problem would be that kernel does not know that the CMOS clock is set to the local time. Standard practice is that the CMOS clock should be set to UTC. libc then uses knowledge of the timezone to properly report the local time. see man adjkerntz (adjust kernel time zone) On Fri, 25 Nov 2005, Brett Glass wrote: Just created a server using FreeBSD 6.0, and it's quite stable and fast. One glitch, though: Jobs scheduled to run at midnight via /etc/crontab are running at 6 PM (midnight GMT). I've double checked, and the CMOS clock is set to local time and the time zone is specified as Mountain Standard Time. What could be going on? Is this a known problem? --Brett Glass ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Voodoo with md(4) panics system reliably
Hello,
I'm attempting to simulate unionfs on RELENG_5_4 by remounting
multiple times one vnode-backed md disk and then union mounting
others on top. Here are my steps below w/ a quick backtrace. I
have the core saved and can look into it farther if need be.
Ideas outside of ``don't do that''?
Jon
touch /root/foo
mdconfig -a -t vnode -s 32m -f /root/foo
newfs /dev/md0
mount /dev/md0 /tmp/md0
touch /tmp/md0/test1
umount /tmp/md0
mdconfig -d -u md0
# Strangeness coming
mdconfig -a -t vnode -f /root/foo -o readonly -u md0
mdconfig -a -t vnode -f /root/foo -o readonly -u md1
mdconfig -a -t vnode -f /root/foo -o readonly -u md2
mount -o ro /dev/md0 /tmp/md0
mount -o ro /dev/md1 /tmp/md1
mount -o ro /dev/md1 /tmp/md2
# Multiple mounts
touch bar{0,1,2}
mdconfig -a -t vnode -s 32m -f /root/bar0 -u md4
mdconfig -a -t vnode -s 32m -f /root/bar1 -u md5
mdconfig -a -t vnode -s 32m -f /root/bar2 -u md6
newfs /dev/md4
newfs /dev/md5
newfs /dev/md6
mount -o union /dev/md4 /tmp/md0
mount -o union /dev/md5 /tmp/md1
mount -o union /dev/md6 /tmp/md2
mount
[snip]
/dev/md0 on /tmp/md0 (ufs, local, read-only)
/dev/md1 on /tmp/md1 (ufs, local, read-only)
/dev/md2 on /tmp/md2 (ufs, local, read-only)
/dev/md4 on /tmp/md0 (ufs, local, union)
/dev/md5 on /tmp/md1 (ufs, local, union)
/dev/md6 on /tmp/md2 (ufs, local, union)
mdconfig -l
md6 md5 md4 md2 md1 md0
ls -li /tmp/md0
total 2
3 drwxrwxr-x 2 root operator 512 Oct 16 20:30 .snap
4 -rw-r--r-- 1 root wheel 0 Oct 16 20:21 test1
touch /tmp/md0/test2
ls -li /tmp/md0
total 2
3 drwxrwxr-x 2 root operator 512 Oct 16 20:30 .snap
4 -rw-r--r-- 1 root wheel 0 Oct 16 20:21 test1
4 -rw-r--r-- 1 root wheel 0 Oct 16 20:31 test2
touch /tmp/md0/test3
ls -li /tmp/md0
total 2
3 drwxrwxr-x 2 root operator 512 Oct 16 20:30 .snap
4 -rw-r--r-- 1 root wheel 0 Oct 16 20:21 test1
4 -rw-r--r-- 1 root wheel 0 Oct 16 20:31 test2
5 -rw-r--r-- 1 root wheel 0 Oct 16 20:32 test3
panic
(kgdb) bt
#0 doadump () at pcpu.h:159
#1 0xc054d2e2 in boot (howto=260) at
/usr/src/sys/kern/kern_shutdown.c:410
#2 0xc054d578 in panic (fmt=0xc0735a98 ffs_sync: rofs mod)
at /usr/src/sys/kern/kern_shutdown.c:566
#3 0xc068a5fc in ffs_sync (mp=0xc2304000, waitfor=3,
cred=0xc21dbd80,
td=0xc22efd80) at /usr/src/sys/ufs/ffs/ffs_vfsops.c:1123
#4 0xc05a23b6 in sync_fsync (ap=0xe49f2ce4)
at /usr/src/sys/kern/vfs_subr.c:3475
#5 0xc059f1cd in sched_sync () at vnode_if.h:627
#6 0xc0538e88 in fork_exit (callout=0xc059ee0c sched_sync,
arg=0x0,
frame=0xe49f2d48) at /usr/src/sys/kern/kern_fork.c:791
#7 0xc06d43bc in fork_trampoline () at
/usr/src/sys/i386/i386/exception.s:209
(kgdb) f 3
#3 0xc068a5fc in ffs_sync (mp=0xc2304000, waitfor=3,
cred=0xc21dbd80,
td=0xc22efd80) at /usr/src/sys/ufs/ffs/ffs_vfsops.c:1123
1123lockreq = LK_EXCLUSIVE | LK_NOWAIT;
(kgdb) inf f
Stack level 3, frame at 0xe49f2c94:
eip = 0xc068a5fc in ffs_sync
(/usr/src/sys/ufs/ffs/ffs_vfsops.c:1123);
saved eip 0xc05a23b6
called by frame at 0xe49f2cc4, caller of frame at 0xe49f2c3c
source language c.
Arglist at 0xe49f2c38, args: mp=0xc2304000, waitfor=3,
cred=0xc21dbd80,
td=0xc22efd80
Locals at 0xe49f2c38, Previous frame's sp is 0xe49f2c94
Saved registers:
ebx at 0xe49f2c80, ebp at 0xe49f2c8c, esi at 0xe49f2c84, edi at
0xe49f2c88,
eip at 0xe49f2c90
(kgdb) l
1118}
1119/*
1120 * Write back each (modified) inode.
1121 */
1122wait = 0;
1123lockreq = LK_EXCLUSIVE | LK_NOWAIT;
1124if (waitfor == MNT_WAIT) {
1125wait = 1;
1126lockreq = LK_EXCLUSIVE;
1127}
__
Yahoo! Mail - PC Magazine Editors' Choice 2005
http://mail.yahoo.com
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
NEC 1300A DVD-R writing
AAron could you please email the site for the firmware update? thank you in advance, Jon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SiI 3114 woes
Yes, but only in a configuration =3GB. But I thought those problems were
ironed out? I've been looking to switch that machine back to
FreeBSD/amd64 but haven't had a chance yet. Would love to know if there
are issues ahead.
-Jon
On Thu, 8 Sep 2005, Mars G. Miro wrote:
Yo list/Soren!
Has anybody successfully installed FreeBSD on the dual-Opteron TYAN
ThunderK8W S2885 ( http://www.tyan.com/products/html/thunderk8w.html )
using the onboard SiI 3114 SATA controller? This mobo is supposedly
supported:
http://www.freebsd.org/cgi/query-pr.cgi?pr=80857
But I have never been able to successfully install
FreeBSD({5.3/5.4/6.0Beta3/4} amd64/i386) on it, using SATA.
In my last attempt at installing 6.0Beta4 AMD64 on it, I get:
ad4: FAILURE - WRITE_DMA status=51READY,DSC,ERROR error=4ABORTED
LBA=105819039
g_vfs_done():ad4s1e[WRITE(offset=23695114240, length=2048)]error = 5
at the debugging console
and
panic:bundirty: buffer 0x9a7faff0 still on queue 1
cpuid = 0
KDB: enter: panic
[ thread pid 3 tid 100021 ]
Stopped at kdb_enter+0x2f: nop
db trace
Tracing pid 3 tid 100021 td 0xff007ba14be0
kdb_enter() at kdb_enter+0x2f
panic() at panic+0x249
bundirty() at bundirty+0x128
brelse() at brelse+0x831
bufdone() at bufdone+0x225
ffs_backgroundwritedone() at ffs_backgroundwritedone+0xa7
bufdone() at bufdone+0x2ad
g_vfs_done() at g_gvfs_done+0x63
g_io_schedule_up() at g_io_schedule_up+0xd4
g_up_procbody() at g_up_procbody+0x7a
fork_exit() at fork_exit+0xbb
fork_trampoline() at fork_tramploine+0xe
--- trap 0, rip = 0, rsp = 0xb2160d00, rbp = 0 ---
db
Some months ago, I did successfully install FreeBSD 5.4/amd64 on it,
using PATA IDE drives, and no problems whatsoever, so I think this has
something to do w/ the SiI 3114 driver.
Any help is much appreciated.
I do apologize for cross-posting but this concerns -stable and -amd64.
Thanks!
cheers
mars
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Sysinstall automatic filesystem size generation.
yes, that's quite generous. why isn't /tmp just an mfs mount though? On Sun, 28 Aug 2005, Colin Percival wrote: C. Michailidis wrote: Remember, I'm talking about the 'path of least resistance', I understand that I could label the slice manually with any number of different configurations. The issue I was hoping to shed some light on is... Can the auto-configuration mechanism stand to be improved?. Is it reasonable (in today's era of dirt cheap disk space) to have a mere 256MB allocated to /tmp (or /var or even /) by default? The default sizes are now currently 512 MB for / and /tmp, and 1024 MB plus space for one crashdump on /var. If anything, these are vast overkill for most systems; on /, for example, it is hard to imagine a situation where a normal user would use more than 150MB of space unless they were doing something which they shouldn't be doing. Colin Percival ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Sysinstall automatic filesystem size generation.
Um, that they may be but... I was under the impression (mistaken?) that /tmp is a directory defined under the POSIX standard and is in fact supposed to be flushed in those cases, and that /var/tmp is to be used for programs desiring persistant storage across shutdowns (scheduled and unscheduled). Perhaps it only says that a program is not allowed to rely on /tmp being persistent. I don't have a copy at hand :-/ -Jon On Mon, 29 Aug 2005, Chuck Swiger wrote: Jon Dama wrote: yes, that's quite generous. why isn't /tmp just an mfs mount though? While I like that suggestion personally, some people get perturbed about files in /tmp going away if the power fails or you reboot. -- -Chuck ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Sysinstall automatic filesystem size generation.
On Tue, 30 Aug 2005, Mark Kirkwood wrote: (FWIW - I have seen Linux + ext3 systems destroyed by power failure because the admins refused to disable write caching on ATA drives - Neither journelling or softupdates is much help if the HW is kidding you about write acknowledgment). This would certainly be case with 2.4 kernels and early 2.6 kernels. Afaik, they only made a decent attempt at solving this problem relatively recently. Ironically, phk backed out the underlying support for this safety fix from the FreeBSD kernel b.c. it wasn't integrated into the softupdates code whereas in reality the proper course of action would have been to hook it in. :-/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Sysinstall automatic filesystem size generation.
Well, I think one issue is that it destroys one of the fundamental advantages of softupdates which was that you could interleave streams of strongly ordered metadata writes without demanding a sequence for the streams collectively. By using request barriers, you are effectively forcing an additional synchronization requirement, the secret will be not forcing us all the way back to having effectively synchronous metadata writes (see below). As I understand, metadata operations are only added to the WORKLIST when their dependents have already been completed i.e., at the lowest level have had biodone called to mark the write operation completed. I am not sure how ffs_softdeps checks this property. It seems you need to add a layer of indirection. (owing to biodone being called merely when the drive has cached the request). What you know is that those operations marked completed by biodone are in fact done only after a (costly) flush cache operation is executed. Therefore you want to delay this operation for as long as possible, in fact until you actually depend on biodone being honest. I.e., at the time another operation is inserted into the WORKLIST. The secret I think is to keep track of which bp's marked B_DONE by biodone that have been certified by a flush cache. Thus permitting you to avoid some cache flushes. Furthermore, the softdep code has to be responsible for envoking the flush cache operation when it notices that the B_DONE flag that it cares about does not have a matching B_REALLY_DONE flag, which every block should have that had B_DONE set before the flush cache operation happened. I do not really know how GEOM has changed this situation. biodone seems to have been stripped of much of its old responsibilities? -Jon I'd guess that it belongs On Tue, 30 Aug 2005, Matthias Buelow wrote: Jon Dama wrote: Ironically, phk backed out the underlying support for this safety fix from the FreeBSD kernel b.c. it wasn't integrated into the softupdates code whereas in reality the proper course of action would have been to hook it in. :-/ Can it be put into softupdates at all? From what I understand (which is probably a rather sketchy idea of the matter), write barriers work because they are only used here to separate journal writes from data writes (i.e., to make sure the log is written, by flushing the cache, before any filesystem data hits the platters). I've read the softupdates paper some time ago and haven't found similar sequence points where one could insert such flushing. One would have to flush all the time, either continuously or in very short intervals, in order to keep the ordering, which then would amount to the same effects as if one simply disabled the cache. But probably I'm wrong here (I hope). mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Create 2.5TB file system on 5.4S?
Where exactly did you run into trouble? I'm guessing you made the array, you have a device for it in /dev but ran into problems (expected) using fdisk or bsdlabel. -Jon On Sun, 14 Aug 2005, Brandon Fosdick wrote: Now that my shiny new 9500S is installed and not fighting for IRQs, I've created and initialized a ~2.5TB array using the bios utility. So the next step is mounting the new array. I naively tried following the regular handbook instructions for adding a new drive and failed miserably. And after googling a bit I now know why, and realized that I knew why before, but I was being stupid. I've seen a few mentions of using gpt(8) and some vague references to using dedicated mode. But I haven't seen anything that says this is the Right Way to do it. So...what's the proper way to make a large file system? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ATA Woes.
On 7/19/05, Tony Byrne [EMAIL PROTECTED] wrote: Jul 19 13:01:48 roo kernel: ad0: FAILURE - READ_DMA status=51READY,DSC,ERROR error=40UNCORRECTABLE LBA=288810495 Jul 19 13:01:59 roo kernel: ad0: FAILURE - READ_DMA status=51READY,DSC,ERROR error=1ILLEGAL_LENGTH LBA=288810495 Jul 19 13:02:05 roo kernel: ad0: FAILURE - READ_DMA status=51READY,DSC,ERROR error=40UNCORRECTABLE LBA=288810495 Jul 19 13:02:16 roo kernel: ad0: FAILURE - READ_DMA status=51READY,DSC,ERROR error=40UNCORRECTABLE LBA=288810495 Jul 19 13:04:36 roo last message repeated 4 times I'm totally confused. I don't know enough about SMART to know whether I'm looking at real failing drives or some bug exposed by the interaction between drive firmware, hd controller and FreeBSD. What I've recently learned the hard way is that desktop drives have no place in a server. I've now failed 4 of 10 SATA drives (Maxtor and WD) in 1U rackmounts, and am moving on to trying the WD Raptor SATA drives (which claim to be low-end server). -- Jon Simola Systems Administrator ABC Communications ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ATA Woes.
On 7/19/05, Wilko Bulte [EMAIL PROTECTED] wrote: On Tue, Jul 19, 2005 at 11:22:01AM -0700, Jon Simola wrote.. I've now failed 4 of 10 SATA drives (Maxtor and WD) in 1U rackmounts, and am moving on to trying the WD Raptor SATA drives (which claim to be low-end server). Properly cooled? Yeah, they're in the Supermicro 811 chassis with hotswap SATA sleds. There's a decent amount of air flowing over the drives, and SMART says they're running about 26C. Compared to my 10Krpm SCSI array that I've burned my fingers on, frequently. -- Jon Simola Systems Administrator ABC Communications ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dangerous situation with shutdown process
No, it's at a level below softupdates that this must be done. Softupdates only understands when things have been marked completed with biodone()--the underlying scsi/ata/sata driver must make the determination as to when biodone should be called. The flush has to be done there. _IF_ the flush is being done there, then request barriers represent a performance enhancement, not an integrity enhancement. -Jon On Sat, 16 Jul 2005, Matthias Buelow wrote: Lowell Gilbert wrote: Well, break it down a little bit. If an ATA drive properly implements the cache flush command, then none of the ongoing discussion is Are you sure this is the case? Are there sequence points in softupdates where it issues a flush request and by this guarantees fs integrity? I've read thru McKusick's paper in search for an answer but haven't found any. All I've read so far on mailing lists and from googling was that softupdates doesn't work if the wb-cache is enabled. mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dangerous situation with shutdown process
On Fri, 15 Jul 2005, Matthias Buelow wrote: Why am I arguing in an uphill battle here? Is data safety no longer important to the FreeBSD community? Such issues should not even have to be discussed at all! I'm trying to tell you what you have to say to move forward on this issue: 1) tell people that they are mistaken about drives ignoring the FUA bit or flush cache 2) convince people that the performance benefit of request barriers is worth it I think we all care, but when we actually care--when money depends on it-- we adopt other measures scsi, batter backed raid, etc. -Jon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dangerous situation with shutdown process
I know my drive allows disabling of the write cache, as, apparently, the majority of IDE/SATA drives do. Yes fair enough. This command is in the specification as far back as ata-1. I guess it yields reasonable? performance? You should, however, be telling sos@ this--if he doesn't already believe it. -Jon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dangerous situation with shutdown process
softupdates is perfectly safe with SCSI. its well known that ide and sata w/wo ncq fails to provide suitable semantics for softupdates however, journaling fairs no better, and request barriers do nothing to solve the problem. Request Barriers under linux exist to prevent the low level kernel block device layer from reordering write operations from the upper file system layers. Request Barriers consist of nothing more than tagging internal queues within the Linux kernel itself. They do nothing to resolve the underlying failures of the hardware to provide proper semantics to the block device layer. but, Request Barriers are ultimately useless. They can't resolve the underlying problems with ide/sata and there are already exposed semantics for scsi. if you absolutely must use sata and have reliable writes, make use of sata with battery-backed raid controller. On Thu, 14 Jul 2005, Matthias Buelow wrote: Kevin Oberman wrote: How can I fix it on my system? SCSI or ATA? If it's ATA, turn off write cache with (atacontrol(8) or the sysctl. You do NOT want to do that. Not only will performance drop brutally (example: drop to 1/5th of normal write speed for sequential writes, probably worse for random writes) but it will also significantly reduce the lifetime of your disk. Modern disks are designed to be used with the write-back cache enabled, so don't turn it off. The problem is that disks lie about whether they have actually written data. If the power goes off before the data is in cache, it's lost. No, the problem is that FreeBSD doesn't implement request barriers and that softupdates is flawed by design and seemingly could not make use of them, even if they were available (because, as I understand it, it relies on a total ordering of all writes, unlike the partial ordering necessary for a journalled fs). Until a journalled fs that uses write request barriers is available for FreeBSD, you better had a reliable UPS. mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dangerous situation with shutdown process
if the FUA bit in the sata command header is properly respected. if the flush cache command on an ata device is properly respected. if the flush cache command on an ata device is implemented (it's optional) if the flush cache command exists when the ata device was made (it isn't in the earlier versions of the ata spec). anyways, your comments about softupdates needing total ordering versus journals needing partial ordering are wrong. softupdates only requires that you do not call 'biodone(x)' until 'x' has been committed to disk. this is 100% compatiable with the specification feature set, IF those semantics are actually present in the hardware. please see the thread beginning with the following commit message for an extensive discussion of these topics: http://lists.freebsd.org/pipermail/cvs-src/2003-April/001002.html -Jon On Thu, 14 Jul 2005, Matthias Buelow wrote: Jon Dama wrote: Request Barriers under linux exist to prevent the low level kernel block device layer from reordering write operations from the upper file system layers. Request Barriers consist of nothing more than tagging internal queues within the Linux kernel itself. They do nothing to resolve the underlying failures of the hardware to provide proper semantics to the block device layer. but, Request Barriers are ultimately useless. They can't resolve the underlying problems with ide/sata and there are already exposed semantics for scsi. If you flush the cache at barriers, on-disk integrity of the journal vs. metadata updates is guaranteed. mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
: dangerous situation with shutdown process
Well, maybe it is in't implemented properly--I can't exactly say--but the blame should not fall on the method of data integrity used by softupdates. Nor do I think softupdates would require per se more flushes. Again, the blame would have to be on whoever is not taking the measures necessary to ensure biodone() is called after the data is properly committed. The Request Barrier design only works if the answer to the IFs I asked are yes. RB cannot solve an underlying failure of the hardware semantics. There is an idea floating around that the question to those IFs is usually no. If you feel that's wrong, please try to convince people here of that fact. Because if the answers are no these issues are moot and noone can or will do anything about it. 1a) If the ata driver is not flushing then there is a integrity problem in FreeBSD. 1b) If drives aren't respecting the flush there is no point in solving 1a. 2a) If the ata driver is flushing but doing so with every request, there is a potential performance problem. 2b) If the drives aren't respecting the flush there is no point solving 2a. There are of course other reasons to dislike the requirements softupdate imposes on other aspects of the system. I've CCed people who hopefully know more about the actual implementation below softupdates than I do. -Jon Jon Dama [EMAIL PROTECTED] writes: if the FUA bit in the sata command header is properly respected. if the flush cache command on an ata device is properly respected. if the flush cache command on an ata device is implemented (it's optional) if the flush cache command exists when the ata device was made (it isn't in the earlier versions of the ata spec). or if the write-back cache can be disabled and re-enabled. anyways, your comments about softupdates needing total ordering versus journals needing partial ordering are wrong. softupdates only requires that you do not call 'biodone(x)' until 'x' has been committed to disk. Well. Can it group writes in such a way that flushing would be required only at larger intervals, or can't it? this is 100% compatiable with the specification feature set, IF those semantics are actually present in the hardware. Apparently it is not compatible with the real-world feature set and it should've been clear to the designer(s) of softupdates that write-back caches signal completion while the data is still in the cache. That's the whole purpose of these mechanisms (so they can delay and reorder the writes and write out whole tracks). You should only assume that, in that case, a seperate flush command (or a workaround that amounts to a flush) exists. Any different design assumes an oversimplified black box notion of a drive that does not correspond with reality. please see the thread beginning with the following commit message for an extensive discussion of these topics: http://lists.freebsd.org/pipermail/cvs-src/2003-April/001002.html I've seen nothing that contradicts what I've said. The point is, that the request barrier design with flushing at barriers as used in M$ Windows (and also completed in recent Linux kernels) allows safe use of disks with write-back cache enabled, while FreeBSD with softupdates apparently doesn't. I don't really care how it's implemented, or if journalling is used, or softupdates, or a quantum-tachyon-reverser mounted on the front antenna. I just want to have the same level of data safety on my hardware with FreeBSD that I would get with other systems. mkb. empty Description: Binary data ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FYI - RELENG_6 branch has been created.
BTW, Going from RELENG5 to RELENG6 requires an rm -rf /usr/obj This isn't too surprising, but its worth a note if anyone is making a migration document. Thanks, Jon On Mon, 11 Jul 2005, Scott Long wrote: Mike Tancsa wrote: At 05:04 PM 11/07/2005, Robert Watson wrote: As a further FYI, a variety of debugging features are still enabled by default in RELENG_6, including INVARINTS, WITNESS, and user space malloc debugging. These will remain enabled through the first snapshot from the Apart from the kernel settings, what other debug settings need to be turned off ? i.e. How do I turn off malloc debugging ? ---Mike ln -s aj /etc/malloc.conf Scott ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: atacontrol raid1 vs. gmirror
On 6/11/05, Paul Mather [EMAIL PROTECTED] wrote: I found array rebuilding to be troublesome on atacontrol RAID Some bits from the in-house documentation I've been writing. I've tested this on multiple occasions on my 1U Supermicro SATA boxes, so might possibly be interesting for someone. * RAID setup: (If required, FreeBSD only) - ensure that the drives are probed as ad4 and ad6 like: ad4: 76324MB [155072/16/63] at ata2-master SATA150 ad6: 76324MB [155072/16/63] at ata3-master SATA150 - if they do not probe correctly, check the BIOS settings above - perform a minimal install of FreeBSD 5.3 (do not worry about network or anything) - reboot from the installed OS and login as root - Run the command atacontrol create RAID1 ad4 ad6 to create the raid set - Reboot and reinstall the OS, choosing ar0 as the drive, which should probe like: ad4: 76324MB [155072/16/63] at ata2-master SATA150 ad6: 76324MB [155072/16/63] at ata3-master SATA150 ar0: 76324MB [9730/255/63] status: READY subdisks: disk0 READY on ad4 at ata2-master disk1 READY on ad6 at ata3-master Minimal Survival for FreeBSD software RAID1 sets * Read the atacontrol man page * atacontrol status ar0 - to check the status * atacontrol detach 2 - to detach ad4 if failed (again, use 3 for ad6). The SATA disks in the 5013C-T chassis are hotswappable, so it can be pulled once detached. * atacontrol attach 2 - to reattach ad4 once replaced * atacontrol addspare ar0 ad4 - to add the replaced ad4 as a spare on the RAID set * atacontrol rebuild ar0 - to rebuild the mirror -- Jon Simola Systems Administrator ABC Communications ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD MySQL still WAY slower than Linux
Just wondering: How much processor migration takes place on linux mysql? Do the threads mostly stick to the same processors? I've noticed that on FreeBSD the 4BSD scheduler doesn't do much to preserve cache coherency. What sort of cache/TLB misses do you see running mysql linux vs. mysql freebsd? -Jon On Sat, 11 Jun 2005, Robert Watson wrote: On Fri, 10 Jun 2005, Steve Roome wrote: We're using mostly: 5.4-STABLE FreeBSD 5.4-STABLE #0: Mon Jun 6 12:22:18 BST 2005 In my experience, the following factors make a big performance difference: - Thread package. In 5.x, you get process scope threads by default, but it turns out MySQL is tuned for system scope threads, and this is particularly visible in the supersmack benchmark, which competes many client processes against a few server threads. I'm not sure what the condition is of libthr on 5.x, but you could give it a spin. In 6.x, libthr has been largely rewritten and is a great deal faster. I think there's a compile-time option to make libpthread use system scope threads but the details ellude me. The Linuxthreads library may well provide a substantial improvement -- not as good for MySQL as the 6.x libthr, but perhaps much more appropriate than libpthread. - Locking model. Make sure that debug.mpsafenet is set to 1 (i.e., there aren't components in the kernel that force Giant over the network stack. Chances are there are none, but it's worth checking). - Twiddling hyper-threading, which helps or hurts differently in various configurations. - On a UP system, consider compiling a kernel without options SMP to reduce locking overhead. I've found the single largest remaining factor to be threading package -- over the past year or so I've about doubled MySQL performance on 5.x leading up to 5.3, largely through SMP locking work, but the remainder of the difference appears to be in the threading package. Robert N M Watson ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD MySQL still WAY slower than Linux
Try linking mysql with ptmalloc2 (instead of the system malloc obviously). Doing this has the side-benefit of ensuring that you don't need to mess with MAXDSIZ. Try linking mysql with david xu's threading library. -Jon On Fri, 10 Jun 2005, Tom Gidden wrote: Hi Kris, On 10 Jun 2005, at 18:17, Kris Kennaway wrote: Show your kernel config etc. I've been working with Steve on this project. We've been playing with various tuning factors, including kernel changes, different stripe sizes on the RAID, my.cnf tuning, libmap.conf, and although we can gain a bit here and there, we can't account for the doubling of performance with Gentoo. Anyway, I've included the dmesg and kernel config. The Gentoo install was pretty vanilla-flavoured, as neither Steve or I had installed Gentoo before, and both of us are pretty rusty on any form of Linux. Incidentally, this does not seem to be I/O-bound. The data is big enough to stay in the table cache anyway. I just noticed these particular tests were done on FreeBSD without HTT, whereas the Gentoo test was. However, I can tell you that in earlier runs, the difference between HTT and non-HTT on FreeBSD for this benchmark was negligible. Regards, Tom --- [snip] --- Copyright (c) 1992-2005 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.4-STABLE #0: Thu Jun 9 09:13:03 BST 2005 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/PE2850_i386_4 Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Intel(R) Xeon(TM) CPU 2.80GHz (2793.01-MHz 686-class CPU) Origin = GenuineIntel Id = 0xf41 Stepping = 1 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 real memory = 3489398784 (3327 MB) avail memory = 3418517504 (3260 MB) ACPI APIC Table: DELL PE BKC ioapic0: Changing APIC ID to 7 ioapic1: Changing APIC ID to 8 ioapic1: WARNING: intbase 32 != expected base 24 ioapic2: Changing APIC ID to 9 ioapic2: WARNING: intbase 64 != expected base 56 ioapic3: Changing APIC ID to 10 ioapic3: WARNING: intbase 96 != expected base 88 ioapic0 Version 2.0 irqs 0-23 on motherboard ioapic1 Version 2.0 irqs 32-55 on motherboard ioapic2 Version 2.0 irqs 64-87 on motherboard ioapic3 Version 2.0 irqs 96-119 on motherboard npx0: math processor on motherboard npx0: INT 16 interface acpi0: DELL PE BKC on motherboard acpi0: Power Button (fixed) Timecounter ACPI-fast frequency 3579545 Hz quality 1000 acpi_timer0: 24-bit timer at 3.579545MHz port 0x808-0x80b on acpi0 cpu0: ACPI CPU on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 pcib1: ACPI PCI-PCI bridge at device 2.0 on pci0 pci1: ACPI PCI bus on pcib1 pcib2: ACPI PCI-PCI bridge at device 0.0 on pci1 pci2: ACPI PCI bus on pcib2 amr0: LSILogic MegaRAID 1.51 mem 0xdfec-0xdfef, 0xd80f-0xd80f irq 46 at device 14.0 on pci2 amr0: LSILogic PERC 4e/Di Firmware 513O, BIOS H418, 256MB RAM pcib3: ACPI PCI-PCI bridge at device 0.2 on pci1 pci3: ACPI PCI bus on pcib3 pcib4: ACPI PCI-PCI bridge at device 4.0 on pci0 pci4: ACPI PCI bus on pcib4 pcib5: ACPI PCI-PCI bridge at device 5.0 on pci0 pci5: ACPI PCI bus on pcib5 pcib6: ACPI PCI-PCI bridge at device 0.0 on pci5 pci6: ACPI PCI bus on pcib6 em0: Intel(R) PRO/1000 Network Connection, Version - 1.7.35 port 0xecc0-0xecff mem 0xdfbe-0xdfbf irq 64 at device 7.0 on pci6 em0: Ethernet address: 00:11:43:ec:b1:7f em0: Speed:N/A Duplex:N/A pcib7: ACPI PCI-PCI bridge at device 0.2 on pci5 pci7: ACPI PCI bus on pcib7 em1: Intel(R) PRO/1000 Network Connection, Version - 1.7.35 port 0xdcc0-0xdcff mem 0xdf9e-0xdf9f irq 65 at device 8.0 on pci7 em1: Ethernet address: 00:11:43:ec:b1:80 em1: Speed:N/A Duplex:N/A pcib8: ACPI PCI-PCI bridge at device 6.0 on pci0 pci8: ACPI PCI bus on pcib8 pcib9: ACPI PCI-PCI bridge at device 0.0 on pci8 pci9: ACPI PCI bus on pcib9 pcib10: ACPI PCI-PCI bridge at device 0.2 on pci8 pci10: ACPI PCI bus on pcib10 pcib11: ACPI PCI-PCI bridge at device 30.0 on pci0 pci11: ACPI PCI bus on pcib11 pci11: display, VGA at device 13.0 (no driver attached) isab0: PCI-ISA bridge at device 31.0 on pci0 isa0: ISA bus on isab0 atapci0: Intel ICH5 UDMA100 controller port 0xfc00-0xfc0f, 0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 31.1 on pci0 ata0: channel #0 on atapci0 ata1: channel #1 on atapci0 atkbdc0: Keyboard controller (i8042) port 0x64,0x60 irq 1 on acpi0 atkbd0: AT Keyboard irq 1 on atkbdc0 kbd0 at atkbd0 sio0: 16550A-compatible COM port port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A orm0: ISA Option ROMs at iomem 0xec000-0xe,0xc-0xcafff on isa0 sc0: System console at flags 0x100 on isa0 sc0: VGA 16 virtual consoles, flags=0x300 vga0: Generic ISA VGA at port 0x3c0-0x3df
Re: Weird NFS problems
Yes, but surely you weren't bridging gigabit and 100Mbit before? Did you try my suggestion about binding the IP address of the NFS server to the 100Mbit side? -Jon On Tue, 31 May 2005, Skylar Thompson wrote: Jon Dama wrote: Try switching to TCP NFS. a 100MBit interface cannot keep up with a 1GBit interface in a bridge configuration. Therefore, in the long run, at full-bore you'd expect to drop 9 out of every 10 ethernet frames. MTU is 1500 therefore 1K works (it fits in one frame), 2K doesn't (your NFS transactions are split across frames, one of which will almost certainly be dropped, it's UDP so the loss of one frame invalidates the whole transaction). This is the same reason you can't use UDP with a block size greater than MTU to use NFS over your DSL or some such arrangement. Incidentially, this has nothing to do with FreeBSD. So if using TCP mounts solves your problem, don't expect Solaris NFS to magically make the UDP case work... The thing is that UDP NFS has been working for us for years. A big part of our work is performance analysis, so to change our network architecture will invalidate a large part of our data. -- -- Skylar Thompson ([EMAIL PROTECTED]) -- http://www.cs.earlham.edu/~skylar/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Weird NFS problems
Yes, but surely you weren't bridging gigabit and 100Mbit before? Did you try my suggestion about binding the IP address of the NFS server to the 100Mbit side? -Jon On Tue, 31 May 2005, Skylar Thompson wrote: Jon Dama wrote: Try switching to TCP NFS. a 100MBit interface cannot keep up with a 1GBit interface in a bridge configuration. Therefore, in the long run, at full-bore you'd expect to drop 9 out of every 10 ethernet frames. MTU is 1500 therefore 1K works (it fits in one frame), 2K doesn't (your NFS transactions are split across frames, one of which will almost certainly be dropped, it's UDP so the loss of one frame invalidates the whole transaction). This is the same reason you can't use UDP with a block size greater than MTU to use NFS over your DSL or some such arrangement. Incidentially, this has nothing to do with FreeBSD. So if using TCP mounts solves your problem, don't expect Solaris NFS to magically make the UDP case work... The thing is that UDP NFS has been working for us for years. A big part of our work is performance analysis, so to change our network architecture will invalidate a large part of our data. -- -- Skylar Thompson ([EMAIL PROTECTED]) -- http://www.cs.earlham.edu/~skylar/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Weird NFS problems
Oh, something else to try: I checked through my notes and discovered that I had gotten UDP to work in a similar configuration before. What I did was bind the IP address to fxp0 instead of em0. By doing this, the kernel seems to send the data at a pace suitable for the slow interface. -Jon On Fri, 27 May 2005, Don Lewis wrote: On 26 May, Skylar Thompson wrote: I'm having some problems with NFS serving on a FreeBSD 5.4-RELEASE machine. The FreeBSD machine is the NFS/NIS server for a group of four Linux clusters. The network archictecture looks like this: 234/24 234/24 Cluster 1 ---|--- Cluster 3 | --- em0| File server | fxp0 | -- Cluster 2 ---|--- Cluster 4 234/24230/24 em0 and fxp0 are bridged, and em0 has a 234/24 IP address while fxp0 is just in promiscuous mode. 234/24 is an 802.1q VLAN on the fxp0 side of the server, so packets are untagged at the switch just before fxp0, and are forwarded to em0 through the bridge. The problem manifests itself in large UDP NFS requests from Clusters 3 and 4. The export can be mounted fine from both those clusters, and small transfers such as with ls work fine, but the moment any serious data transfer starts, the entire mount just hangs. Running ethereal on the file server shows a a lot of fragmented packets, and RPC retransmissions on just a single request. Reducing the read and write NFS buffers on the Linux clients to 1kB from the default of 4kB solves the issue, but kills the transfer rate. The moment I go to 2kB, the problem reappearss. Clusters 1 and 2 use the default of 4kB buffers, and have no problems communicating to em0. Poking through the list archives, I ran across this message (http://lists.freebsd.org/pipermail/freebsd-stable/2003-May/001007.html) that reveals a bug in the fxp(4) driver in 4-RELEASE that incorrectly detects the capabilities of the NIC. Is this still an issue in 5-RELEASE, or am I looking at a different problem? Any ideas on how I can get the NFS buffers up to a reasonable level? That problem was fixed quite some time ago. Which transfer direction fails? Client writing to server Client reading from server Both? Do you see all the fragments in the retransmitted request? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Weird NFS problems
Oh, something else to try: I checked through my notes and discovered that I had gotten UDP to work in a similar configuration before. What I did was bind the IP address to fxp0 instead of em0. By doing this, the kernel seems to send the data at a pace suitable for the slow interface. -Jon On Fri, 27 May 2005, Don Lewis wrote: On 26 May, Skylar Thompson wrote: I'm having some problems with NFS serving on a FreeBSD 5.4-RELEASE machine. The FreeBSD machine is the NFS/NIS server for a group of four Linux clusters. The network archictecture looks like this: 234/24 234/24 Cluster 1 ---|--- Cluster 3 | --- em0| File server | fxp0 | -- Cluster 2 ---|--- Cluster 4 234/24230/24 em0 and fxp0 are bridged, and em0 has a 234/24 IP address while fxp0 is just in promiscuous mode. 234/24 is an 802.1q VLAN on the fxp0 side of the server, so packets are untagged at the switch just before fxp0, and are forwarded to em0 through the bridge. The problem manifests itself in large UDP NFS requests from Clusters 3 and 4. The export can be mounted fine from both those clusters, and small transfers such as with ls work fine, but the moment any serious data transfer starts, the entire mount just hangs. Running ethereal on the file server shows a a lot of fragmented packets, and RPC retransmissions on just a single request. Reducing the read and write NFS buffers on the Linux clients to 1kB from the default of 4kB solves the issue, but kills the transfer rate. The moment I go to 2kB, the problem reappearss. Clusters 1 and 2 use the default of 4kB buffers, and have no problems communicating to em0. Poking through the list archives, I ran across this message (http://lists.freebsd.org/pipermail/freebsd-stable/2003-May/001007.html) that reveals a bug in the fxp(4) driver in 4-RELEASE that incorrectly detects the capabilities of the NIC. Is this still an issue in 5-RELEASE, or am I looking at a different problem? Any ideas on how I can get the NFS buffers up to a reasonable level? That problem was fixed quite some time ago. Which transfer direction fails? Client writing to server Client reading from server Both? Do you see all the fragments in the retransmitted request? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Weird NFS problems
Try switching to TCP NFS. a 100MBit interface cannot keep up with a 1GBit interface in a bridge configuration. Therefore, in the long run, at full-bore you'd expect to drop 9 out of every 10 ethernet frames. MTU is 1500 therefore 1K works (it fits in one frame), 2K doesn't (your NFS transactions are split across frames, one of which will almost certainly be dropped, it's UDP so the loss of one frame invalidates the whole transaction). This is the same reason you can't use UDP with a block size greater than MTU to use NFS over your DSL or some such arrangement. Incidentially, this has nothing to do with FreeBSD. So if using TCP mounts solves your problem, don't expect Solaris NFS to magically make the UDP case work... -Jon On Fri, 27 May 2005, Don Lewis wrote: On 26 May, Skylar Thompson wrote: I'm having some problems with NFS serving on a FreeBSD 5.4-RELEASE machine. The FreeBSD machine is the NFS/NIS server for a group of four Linux clusters. The network archictecture looks like this: 234/24 234/24 Cluster 1 ---|--- Cluster 3 | --- em0| File server | fxp0 | -- Cluster 2 ---|--- Cluster 4 234/24230/24 em0 and fxp0 are bridged, and em0 has a 234/24 IP address while fxp0 is just in promiscuous mode. 234/24 is an 802.1q VLAN on the fxp0 side of the server, so packets are untagged at the switch just before fxp0, and are forwarded to em0 through the bridge. The problem manifests itself in large UDP NFS requests from Clusters 3 and 4. The export can be mounted fine from both those clusters, and small transfers such as with ls work fine, but the moment any serious data transfer starts, the entire mount just hangs. Running ethereal on the file server shows a a lot of fragmented packets, and RPC retransmissions on just a single request. Reducing the read and write NFS buffers on the Linux clients to 1kB from the default of 4kB solves the issue, but kills the transfer rate. The moment I go to 2kB, the problem reappearss. Clusters 1 and 2 use the default of 4kB buffers, and have no problems communicating to em0. Poking through the list archives, I ran across this message (http://lists.freebsd.org/pipermail/freebsd-stable/2003-May/001007.html) that reveals a bug in the fxp(4) driver in 4-RELEASE that incorrectly detects the capabilities of the NIC. Is this still an issue in 5-RELEASE, or am I looking at a different problem? Any ideas on how I can get the NFS buffers up to a reasonable level? That problem was fixed quite some time ago. Which transfer direction fails? Client writing to server Client reading from server Both? Do you see all the fragments in the retransmitted request? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Weird NFS problems
Try switching to TCP NFS. a 100MBit interface cannot keep up with a 1GBit interface in a bridge configuration. Therefore, in the long run, at full-bore you'd expect to drop 9 out of every 10 ethernet frames. MTU is 1500 therefore 1K works (it fits in one frame), 2K doesn't (your NFS transactions are split across frames, one of which will almost certainly be dropped, it's UDP so the loss of one frame invalidates the whole transaction). This is the same reason you can't use UDP with a block size greater than MTU to use NFS over your DSL or some such arrangement. Incidentially, this has nothing to do with FreeBSD. So if using TCP mounts solves your problem, don't expect Solaris NFS to magically make the UDP case work... -Jon On Fri, 27 May 2005, Don Lewis wrote: On 26 May, Skylar Thompson wrote: I'm having some problems with NFS serving on a FreeBSD 5.4-RELEASE machine. The FreeBSD machine is the NFS/NIS server for a group of four Linux clusters. The network archictecture looks like this: 234/24 234/24 Cluster 1 ---|--- Cluster 3 | --- em0| File server | fxp0 | -- Cluster 2 ---|--- Cluster 4 234/24230/24 em0 and fxp0 are bridged, and em0 has a 234/24 IP address while fxp0 is just in promiscuous mode. 234/24 is an 802.1q VLAN on the fxp0 side of the server, so packets are untagged at the switch just before fxp0, and are forwarded to em0 through the bridge. The problem manifests itself in large UDP NFS requests from Clusters 3 and 4. The export can be mounted fine from both those clusters, and small transfers such as with ls work fine, but the moment any serious data transfer starts, the entire mount just hangs. Running ethereal on the file server shows a a lot of fragmented packets, and RPC retransmissions on just a single request. Reducing the read and write NFS buffers on the Linux clients to 1kB from the default of 4kB solves the issue, but kills the transfer rate. The moment I go to 2kB, the problem reappearss. Clusters 1 and 2 use the default of 4kB buffers, and have no problems communicating to em0. Poking through the list archives, I ran across this message (http://lists.freebsd.org/pipermail/freebsd-stable/2003-May/001007.html) that reveals a bug in the fxp(4) driver in 4-RELEASE that incorrectly detects the capabilities of the NIC. Is this still an issue in 5-RELEASE, or am I looking at a different problem? Any ideas on how I can get the NFS buffers up to a reasonable level? That problem was fixed quite some time ago. Which transfer direction fails? Client writing to server Client reading from server Both? Do you see all the fragments in the retransmitted request? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Performance of 4.x vs 5.x (Re: Lifetime of FreeBSD branches)
Could this be quantified by setting up a synthetic experiement: 1) one machine uses dummynet to generate a uniform packet/sec stream 2) another machine has a process receiving those packets and recording their arrival relative to the local TSC. afaik, the TSC is the only source of wall-time that doesn't involve a system call. Is that right? Are the TSCs synchronized on SMP systems? 3) Generate another source of activity on the receiving machine to estimate the effect of PREEMPTION relative to the (lack of) quiescence. 4) use the jitter in the TSC deltas to infer the effect of preemption -Jon On Thu, 26 May 2005, Bjarne Wichmann Petersen wrote: On Wednesday 25 May 2005 23:45, Kris Kennaway wrote: On Wed, May 25, 2005 at 11:42:01PM +0200, Bjarne Wichmann Petersen wrote: I've had PREEMTION enabled in 5-STABLE for at couple of month and had the opposite experience. Eg. when clicking on a file in a fileselector (I'm using KDE) it would take 2-3 seconds before the file got highlighted. After disabling PREEMTION again responsetime seems to have improved. Are you running 5.4-RELEASE or later? Later (5.4-STABLE). Hmm... did a little testing. Sometimes I *still* get long responsetimes with PREEMPTION disabled in a seemingly random order. Bjarne ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Performance of 4.x vs 5.x (Re: Lifetime of FreeBSD branches)
It's different, yes. But the trouble is that you need a controlled interrupt source--i.e., you have to have some concept of when an event might have been handled (were it not for such and such activity). I posit that without that counterfactual talking about PREEMPTION is meaningless. The technique I mentioned--measuring and comparing the jitter was intended to quash measuring the performance of the network stack itself. Do you have an idea how you can pose that counterfactual in a synthetic arrangement more closely connected with the problem at hand? ... -Jon On Wed, 25 May 2005, Kris Kennaway wrote: On Wed, May 25, 2005 at 03:33:39PM -0700, Jon Dama wrote: Could this be quantified by setting up a synthetic experiement: 1) one machine uses dummynet to generate a uniform packet/sec stream 2) another machine has a process receiving those packets and recording their arrival relative to the local TSC. afaik, the TSC is the only source of wall-time that doesn't involve a system call. Is that right? Are the TSCs synchronized on SMP systems? 3) Generate another source of activity on the receiving machine to estimate the effect of PREEMPTION relative to the (lack of) quiescence. 4) use the jitter in the TSC deltas to infer the effect of preemption That would be attempting to benchmark something entirely different. Kris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Recent 5.4-p1 upgrade issue (lib/libc.so.5)
--- Kris Kennaway [EMAIL PROTECTED] wrote:
On Mon, May 23, 2005 at 02:57:40PM -0700, Jon Passki wrote:
--- Kris Kennaway [EMAIL PROTECTED] wrote:
Look at how make installworld does the replacement safely.
Ah, makes sense now, but let me regurgitate:
According to src/Makefile.inc1, installword sets up INSTALLTMP
with
some nifty files, along with the files previously in the obj
tree
setup by phases such as bootstrap-tools. Since these are
defined
later on in the path before the user's ${PATH}, one doesn't
shoot
one's foot off when updating the binaries, correct?
Well, it does that too, but it also installs libc itself in a
safe way
using install(1).
I'm assuming the '-S' flag for install(1)? To me, it seems very
helpful too that it's using `install` in the obj tree since
/usr/bin/install is dynamically linked to libc. Or does it not
matter that install(1) is dynamically linked since the safe way may
not be dependent upon libc? If so, that would be cool. Thanks for
the feedback.
Jon
__
Do you Yahoo!?
Yahoo! Small Business - Try our new Resources site
http://smallbusiness.yahoo.com/resources/
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Recent 5.4-p1 upgrade issue (lib/libc.so.5)
Hello, I performed an unsupported way of installing and am soliciting what I could do next time to prevent installation blues. I'm not expecting assistance from the Project, just some love :) I have a build host that created what I needed for the host being upgraded. Once it's more polished, I'll be happy to share my steps, but relatively it went well. When I attempted to update /lib/libc.so.5, though, I hit a bump. I `chflags noschg /lib/libc.so.5` and then used tar to extract the exact file. tar was able to unlink the file, and then choked. After some unrelated errors, I was in single user mode using /rescue to save my rear end, which worked well enough. Doing `ldd /sbin/tar` hinted why it probably choked, since tar is dynamically linked to /lib/libc.so.5. Here's what gets me: I was able to do a the supported upgrade process in an unsupported manner (multiuser mode via ssh w/o a shutdown inbetween, nor going into signle user mode) w/ no issues on the build host. What occurs in that process (make buildworld; make buildkernel; make installkernel; mergemaster -p; make installworld; mergemaster) where libc can be replaced (assuming it uses install(1), which is also linked against libc) without failure, but using tar causes it to fail? Ideas? TIA, Jon PGP Fingerprint: 1BB0 A946 927B 93C3 ED6A 0466 6692 6C2C 84BE 4122 Should any political party attempt to abolish social security, unemployment insurance, and eliminate labor laws and farm programs, you would not hear of that party again in our political history. There is a tiny splinter group, of course, that believes you can do these things. Among them are [...] a few other Texas oil millionaires, and an occasional politician or business man from other areas. Their number is negligible and they are stupid. [1] -- Dwight D. Eisenhower, Former President of the USA (Republican), Nov. 8, 1954 [1] http://www.eisenhowermemorial.org/presidential-papers/first-term/documents/1147.cfm __ Yahoo! Mail Mobile Take Yahoo! Mail with you! Check email on your mobile phone. http://mobile.yahoo.com/learn/mail ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Recent 5.4-p1 upgrade issue (lib/libc.so.5)
--- Kris Kennaway [EMAIL PROTECTED] wrote:
On Mon, May 23, 2005 at 10:24:15AM -0700, Jon Passki wrote:
Here's what gets me: I was able to do a the supported upgrade
process in an unsupported manner (multiuser mode via ssh w/o a
shutdown inbetween, nor going into signle user mode) w/ no
issues
on the build host. What occurs in that process (make
buildworld;
make buildkernel; make installkernel; mergemaster -p; make
installworld; mergemaster) where libc can be replaced (assuming
it
uses install(1), which is also linked against libc) without
failure, but using tar causes it to fail? Ideas?
Look at how make installworld does the replacement safely.
Ah, makes sense now, but let me regurgitate:
According to src/Makefile.inc1, installword sets up INSTALLTMP with
some nifty files, along with the files previously in the obj tree
setup by phases such as bootstrap-tools. Since these are defined
later on in the path before the user's ${PATH}, one doesn't shoot
one's foot off when updating the binaries, correct?
In my circumstance, I don't have an obj tree on the dest. host, but
I do have /rescue. I could extract that on a first run and then
perform the later extractions with the updated tar (or just do it
all if /rescue/tar works anyway). Does this seem decent? Is there
a more elegant way?
Thanks for the heads up, Kris!
Jon
__
Do you Yahoo!?
Yahoo! Small Business - Try our new Resources site
http://smallbusiness.yahoo.com/resources/
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Lifetime of FreeBSD branches
It might be beneficial (pipe-dream perhaps) if the all the BSDs coalesced around one port/packaging system. I hear that netbsd's port system has the metadata necessary to support different OSs and different OS versions within one coherent system. What do you think about the relative strengths of pkgsrc and the FreeBSD ports system? -Jon On Mon, 23 May 2005, Kris Kennaway wrote: On Tue, May 24, 2005 at 10:45:48AM +0900, Joel wrote: Random comment from the peanut gallery, but ... Thanks for the info guys. Does this security support also mean that current ports will be compatible with the release? No, there are no guarantees about that. The ports/ people generally try to make things work with older releases, but there are no gurantees there. It's simply too much work to make such guarantees, and this is after all an volunteer project (for most parts anyway). See also http://www.freebsd.org/ports/ for the official statement. Right, i didnt think so. Debian is a volunteer project too, and their packaging system supports all of their branches. I guess i should look into rolling my own packages, to be sure. And yes, i realize that we just dont have an infrastructure for something like this. I'm thinking that, if a company really doesn't have the infrastructure, there are several good options. You mention Linux. MacOSX is closer to the BSDs than Linux in many ways, tends to have relatively long-term stability, and you can pay Apple for a rather high level of support if you join their developer's program. The best option, however, may be to invest in the infrastructure -- a long term relationship with a qualified contractor, or even an employee whose primary duty would be to (learn how to) do the heavy lifting on backporting and upgrading. That way, the OS itself becomes more a part of the company's resources. Didn't someone announce a few months ago that they were going to work on supporting ports with older releases? I'm sure they'd welcome support, whether financial, material or otherwise. Kris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Problem compiling Kernel
-- Kernel build for MYKERNFILE started on Thu May 12 08:13:28 ADT 2005 -- === MYKERNFILE mkdir -p /usr/obj/usr/src/sys -- stage 1: configuring the kernel -- cd /usr/src/sys/i386/conf; PATH=/usr/obj/usr/src/i386/legacy/usr/sbin:/usr/obj/usr/src/i386/legacy/usr/bin:/usr/obj/usr/src/i386/legacy/usr/games:/usr/obj/usr/src/i386/usr/sbin:/usr/obj/usr/src/i386/usr/bin:/usr/obj/usr/src/i386/usr/games:/sbin:/bin:/usr/sbin:/usr/bin config -d /usr/obj/usr/src/sys/MYKERNFILE /usr/src/sys/i386/conf/MYKERNFILE ../../conf/files: coda/coda_fbsd.c must be optional, mandatory or standard *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. I'm using FreeBSD 5.4 Release, this only happened when I did a CVSup, some help would be great. - Thanks ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Using jails and djbdns
On 5/12/05, Tony Arcieri [EMAIL PROTECTED] wrote: Is there some easy way to reverse this order, so svscan is started first and jails started afterward? Rename the svscan.sh script to 000svscan.sh so that it shows up first in a directory listing and is run before the jail scripts (jail-x.x.x.x.sh in my case). man rc(8) has a lot of good points to read through if you have any further questions. -- Jon Simola Systems Administrator ABC Communications ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: xl(4) polling
On 5/10/05, Rob [EMAIL PROTECTED] wrote: Interestingly: HZ=1000 is apparently a problem with the xl devices (3Com 3c905B-TX), but not with the rl devices (RealTek 8139). What could cause that difference? Could a difference in buffer size on the LAN card cause this? Yes. GigE cards tend to have larger packet buffers, but that certainly doesn't solve all the problems. I've been having some problems with the em cards in particular (fxp I've had no problems with) as no matter what I've tried tuning (tcprecvspace, HZ, polling knobs) I've been seeing packet loss of about 0.5%. That doesn't seem like much, but it's an awful lot to the couple thousand users behind it. Anyways, HZ=1000 shouldn't be a CPU problem on anything faster than a 500MHz-ish processor. There are also a few lightly documented sysctls that might be useful to play with that do things like poll during the idle loop (actual usefullness in any particular case may be void in your area, many will enter, few will win). -- Jon Simola Systems Administrator ABC Communications ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Good CD Burning Software
On 04/22/05 00:51, Didier Caamano wrote: I was wondering what would be a good cd burner software for FBSD? If you like GUIs and run KDE, K3b is nice: http://www.k3b.org/ It's in ports: http://www.freshports.org/sysutils/k3b/ Jon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kernel/dmesg misreporting clock speed of CPU
On 4/22/2005 9:07 AM, John T. Yocum wrote: First off, want to say thanks to all the people that make FreeBSD possible. Very nice operating system. :) Ok, now for the problem. Been running FreeBSD 5-STABLE on my Dual Pentium Pro 200Mhz for many months now. However, yesterday I upped to 5.4-RC3, and noticed something changed during bootup. This line: CPU: Pentium Pro (145.59-MHz 686-class CPU) Note that line says 145.59-Mhz, I have 200Mhz CPUs. As well, prior to upgrading to RC-3 that line would say 199.98Mhz. Not sure if that's a bug or not. Random shot: BIOS battery died and the speed got reset to 150MHz? Then again, the speed on the Pentium Pro machine I used to have was set with a jumper (had it overclocked to 233MHz!)... Sorry if I'm way off base here, Jon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: securelevel and make installworld
On 04/20/05 15:16, Ronald Klop wrote: Can make installworld complain on startup if I try to run it with securelevel 0. It will fail half way through on some files with nochg flags or something like that. Design feature: 'schg' is the system immutable flag. Some system files are installed with 'schg' for security reasons; installworld must remove this flag in order to install a new version of these files. However, when securelevel 0 system immutable flags may not be turned off (see init(8)). An attempt to remove the system immutable flag (set 'noschg') will therefore fail. As a result, installworld fails. Canonical answer: Reboot into single user mode to perform the installworld as documented in UPDATING and section 19.4.1 of the handbook. Regards, Jon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
[PATCH] securelevel and make installworld
On 04/20/05 16:56, Ronald Klop wrote:
On Wed, 20 Apr 2005 16:28:06 -0500, Jon Noack [EMAIL PROTECTED] wrote:
On 04/20/05 15:16, Ronald Klop wrote:
Can make installworld complain on startup if I try to run it with
securelevel 0.
It will fail half way through on some files with nochg flags or
something like that.
Design feature:
'schg' is the system immutable flag. Some system files are installed
with 'schg' for security reasons; installworld must remove this flag
in order to install a new version of these files. However, when
securelevel 0 system immutable flags may not be turned off (see
init(8)). An attempt to remove the system immutable flag (set
'noschg') will therefore fail. As a result, installworld fails.
Canonical answer:
Reboot into single user mode to perform the installworld as
documented in UPDATING and section 19.4.1 of the handbook.
I understand the problem, otherwise I wouldn't have securelevel 0.
Doing a remote install in single user mode isn't always possible.
And than it isn't very nice to break the installworld with an error.
Using the idea of 'fail early' it would be very nice too have a check
for securelevel in the installworld Makefile.
The attached diff is against -CURRENT but applies cleanly to 5.4-RC3.
It adds a check to the installworld target in src/Makefile.inc1 to
ensure we are not in secure mode.
This is just a quick hack; there may be a better way to do this (with
SPECIAL_INSTALLCHECKS perhaps?).
Regards,
Jon
Index: Makefile.inc1
===
RCS file: /home/ncvs/src/Makefile.inc1,v
retrieving revision 1.492
diff -u -r1.492 Makefile.inc1
--- Makefile.inc1 6 Apr 2005 01:55:43 - 1.492
+++ Makefile.inc1 20 Apr 2005 22:39:27 -
@@ -471,6 +471,18 @@
kernel-toolchain: ${TOOLCHAIN_TGTS:N_includes:N_libraries}
#
+# checksecurelevel
+#
+# Ensures that the system is not running in secure mode.
+#
+SECURELEVEL!= sysctl -n kern.securelevel
+checksecurelevel:
+.if ${SECURELEVEL} 0
+ @echo ERROR: securelevel = ${SECURELEVEL}; cannot proceed in secure mode.
+ false
+.endif
+
+#
# Use this to add checks to installworld/installkernel targets.
#
SPECIAL_INSTALLCHECKS=
@@ -513,7 +525,7 @@
#
# Installs everything compiled by a 'buildworld'.
#
-distributeworld installworld: installcheck
+distributeworld installworld: checksecurelevel installcheck
mkdir -p ${INSTALLTMP}
for prog in [ awk cap_mkdb cat chflags chmod chown \
date echo egrep find grep \
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: RELENG_5 broken?
On 4/14/2005 8:28 AM, David Wolfskill wrote: On Thu, Apr 14, 2005 at 01:26:17PM +0200, Jose M Rodriguez wrote: Anyone seen this? [... /usr/src/sys/kern/subr_bus.c:1082: warning: no previous prototype for 'devclass_get_drivers' *** Error code 1 ... ] Yup; just a few minutes ago, with sys/kern/subr_bus.c rev. 1.156.2.6. Perhaps something was overlooked in the MFC from 2005-04-14 04:54:15 UTC? Yeah, we also need to MFC rev. 1.68 of src/sys/sys/bus.h. Jon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Adaptec 1210 weird behaviour
On 4/12/2005 2:18 PM, Edwin Groothuis wrote: On Tue, Apr 12, 2005 at 10:21:27AM -0600, Scott Long wrote: Edwin Groothuis wrote: The Adaptec 1210 is a serial ATA RAID0/1 controller. When the two disks are configured as RAID1, FreeBSD still sees two harddisks instead of one. This is with 5.3. Scary :-) Will try this weekend with 5.4 The 1210 is not a real RAID controller, it's a SATA controller with an Adaptec BIOS that does RAID 0 and 1 during boot. It's up to the OS to do the RAID operations after that. The new ATA driver in 6-current Euhm. Oh. Software RAID? A la WinModems? But then I don't understand that it gets away with advertising it as a RAID0/1 controller... The RAID functionality is implemented in the driver, so the product as a whole is a RAID0/1 controller. This is very common; in fact, most products under $150-200 are like this... Jon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: two mysterious files in RELENG_5_4
On 4/11/2005 7:24 AM, Rostislav Krasny wrote: Hello all. I have FreeBSD 5.4-RC1 installed from FTP. Today I ran cvsup to get the latest RELENG_5_4 src-all. I've seen two strange files were checkouted by cvsup: Checkout src/installworld_newk Checkout src/installworld_oldk I don't see those files on http://www.freebsd.org/cgi/cvsweb.cgi/src/?only_with_tag=RELENG_5_4 but I see them on http://www.freebsd.org/cgi/cvsweb.cgi/src/Attic/ According to the cvsweb logs those files were removed in HEAD but still exist in RELENG_5_4. But why I don't see them on the cvsweb by the first URL and why they didn't exist in my 5.4-RC1 before cvsup? Or, if they were removed in the RELENG_5_4 too, why cvsup checkouted them today? *sigh* The files were removed from HEAD but still exist in RELENG_5 and children (like RELENG_5_4). What you are experiencing is a limitation of CVSweb: files in the Attic are not handled well (the newest release, 3.0.5, doesn't do this correctly either). I recently started working on CVSweb and this is one of the things on my TODO list. I'm not sure why the 5.4-RC1 src didn't include them; perhaps files are excluded from the src depending on which arch the release is targeting? These particular files are only used for sparc64. Jon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Sound problem
On 4/7/2005 5:32 AM, Warren wrote: Why don't you post some more info about your system? For example: the output of 'uname -a', the output of 'dmesg', the type of hardware that you are using. What does 'all of a sudden' mean? Did you upgrade something? I'm not telling that I can solve your problem, but other people need to know these things before they can help. Ronald. FreeBSD 5.4-STABLE and all of a sudden means i cvsuped my ports/src and did installworld and buid kernel yesterday 6th April ... rebooted my machine and sound hasnt worked since. /dev/sndstat shows nothing in loader.conf i have: snd_via8233_load=YES # via8233 kernel i have: device sound dmesg shows no errors at all and as previously said sound was working before the reboot. loading the module using kldload shows: kldload snd_via8233.ko kldload: can't load snd_via8233.ko: Exec format error You don't have to put device sound in your kernel config. I use the following in /boot/loader.conf: sound_load=YES snd_es137x_load=YES I wonder if you are experiencing some weird interaction between using snd_via8233 as a module and compiling device sound into the kernel. Try either compiling everything into the kernel or only using modules for sound. Jon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Kernel NTP flipping between FLL and PLL modes
On 04/01/05 14:51, Vivek Khera wrote: On Apr 1, 2005, at 12:56 PM, Bob Bishop wrote: At 18:42 01/04/2005, Roland Smith wrote: On my amd64 box I also get the mode flipping, but I don't get resets. Hmm. I am getting resets on my amd64. On my dual opteron, I get flipping perhaps a handful of times per day (5.4-PRE/amd64 from march 22). On my Xeon EMT64 with hyperthreading (5.3-STABLE/amd64 from Jan 7), it happens every 2-6 hours. My 5.3-REL/i386 Xeon with hyperthreading does it about two or four times per day, no resetting. Neither one shows time step resets. On my little LAN here I have one machine syncing with the Internet that acts as a time server for 3 others. The time server machine (733MHz P3 w/ 4BSD scheduler), named 'www', logs the following: Apr 5 12:35:59 www ntpd[439]: ntpd 4.2.0-a Tue Apr 5 10:59:44 CDT 2005 (1) Apr 5 12:44:33 www ntpd[439]: kernel time sync disabled 2041 Apr 5 12:53:07 www ntpd[439]: kernel time sync enabled 2001 Apr 5 17:36:27 www ntpd[439]: kernel time sync enabled 6001 Apr 5 17:53:31 www ntpd[439]: kernel time sync enabled 2001 Apr 5 18:44:43 www ntpd[439]: kernel time sync enabled 6001 Apr 5 19:01:46 www ntpd[439]: kernel time sync enabled 2001 Apr 5 20:44:12 www ntpd[439]: kernel time sync enabled 6001 Apr 5 21:01:16 www ntpd[439]: kernel time sync enabled 2001 Apr 6 00:26:11 www ntpd[439]: kernel time sync enabled 6001 Apr 6 00:43:16 www ntpd[439]: kernel time sync enabled 2001 Apr 6 02:25:43 www ntpd[439]: kernel time sync enabled 6001 Apr 6 02:42:46 www ntpd[439]: kernel time sync enabled 2001 Apr 6 05:33:31 www ntpd[439]: kernel time sync enabled 6001 Apr 6 05:50:37 www ntpd[439]: kernel time sync enabled 2001 Apr 6 07:50:09 www ntpd[439]: kernel time sync enabled 6001 Apr 6 08:07:14 www ntpd[439]: kernel time sync enabled 2001 Apr 6 09:15:31 www ntpd[439]: kernel time sync enabled 6001 Apr 6 09:32:37 www ntpd[439]: kernel time sync enabled 2001 Apr 6 11:32:07 www ntpd[439]: kernel time sync enabled 6001 2 of the clients (800MHz P3 and Althon XP 1800+, both w/ 4BSD scheduler) don't have any weird issues at all. The third (4x 550MHz P3 Xeon w/ ULE scheduler), aptly named 'quad', hasn't flipped much but has a lot of resets: Apr 5 12:45:28 quad ntpd[708]: ntpd 4.2.0-a Tue Apr 5 10:34:52 CDT 2005 (1) Apr 5 12:54:03 quad ntpd[708]: kernel time sync disabled 2041 Apr 5 13:05:48 quad ntpd[708]: kernel time sync enabled 2001 Apr 5 16:19:52 quad ntpd[708]: time reset -0.702001 s Apr 5 17:05:57 quad ntpd[708]: time reset +1.232861 s Apr 5 17:49:57 quad ntpd[708]: time reset -0.678139 s Apr 5 19:01:45 quad ntpd[708]: time reset +0.183283 s Apr 6 03:04:23 quad ntpd[708]: time reset -0.680651 s Apr 6 03:27:53 quad ntpd[708]: time reset +0.158949 s Apr 6 03:47:04 quad ntpd[708]: time reset +0.983025 s Apr 6 04:24:39 quad ntpd[708]: time reset -1.101975 s Apr 6 04:46:09 quad ntpd[708]: time reset +0.637136 s Apr 6 11:51:31 quad ntpd[708]: kernel time sync enabled 6001 Apr 6 12:08:34 quad ntpd[708]: kernel time sync enabled 2001 Note that all machines are connected to the same 100Mbit switch and were rebooted at the same time. I only got resets on the SMP/ULE machine. Perhaps SMP or ULE make the issue worse? Jon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problems with AMD64 and 8 GB RAM?
On 03/30/05 23:14, Greg 'groggy' Lehey wrote: On Wednesday, 30 March 2005 at 21:28:36 -0700, Scott Long wrote: Greg 'groggy' Lehey wrote: On Wednesday, 30 March 2005 at 23:01:03 -0500, John Baldwin wrote: On Mar 30, 2005, at 8:54 PM, Greg 'groggy' Lehey wrote: lapic0: LINT1 trigger: edge lapic0: LINT1 polarity: high lapic1: Routing NMI - LINT1 lapic1: LINT1 trigger: edge lapic1: LINT1 polarity: high -ioapic0 Version 0.3 irqs 0-23 on motherboard +ioapic0 Version 0.0 irqs 0-23 on motherboard cpu0 BSP: ID: 0x VER: 0x00040010 LDR: 0x0100 DFR: 0x0fff lint0: 0x00010700 lint1: 0x0400 TPR: 0x SVR: 0x01ff This shows that in the - case the APIC is broken somehow (0.0 isn't a valid I/O APIC version). You mean the + case, I suppose. Yes, that's what I suspected. It would seem that the system has mapped RAM over top of the I/O APIC perhaps? That's what I suspected too, but imp doesn't think so. I'd be more inclined to believe that there is an erroneous mapping by the OS, not that things are fundamentally broken in hardware. Agreed. This has been my favourite hypothesis all along. But isn't that what jhb is saying? Your SMAP table shows everything correctly. It's becoming hard to break through your pre-concieved notions here and explain how things actually work. No, there's nothing to break through. I think you're just having problems 1. expressing yourself, and 2. understanding what I'm saying. I have no preconceived notions. All I can see here is an antagonistic attitude on your part. What's the problem? You'll recall from my first message that I asked for suggestions about how to approach the issue. jhb provided some; you haven't so far. From what you've written, it's unclear whether you disagree with jhb or not. If you do, why? If you don't, what's your point here? It would be interesting to see the contents of your MADT to see if it's trying to use a 64-bit PA for your APIC. Any suggestions about how to do so? man acpidump How do you run that on a system that won't boot? You said the system worked with 4 GB (albeit detecting only 3.5 GB). My perception of this whole ACPI thing is that it is fixed in your BIOS (although it can be overridden by the OS). As such, the amount of RAM you have in the machine shouldn't change acpidump results. Is that not correct? Jon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problems with AMD64 and 8 GB RAM?
On 03/30/05 23:49, Greg 'groggy' Lehey wrote: On Wednesday, 30 March 2005 at 22:27:43 -0700, Scott Long wrote: Jon Noack wrote: On 03/30/05 23:14, Greg 'groggy' Lehey wrote: On Wednesday, 30 March 2005 at 21:28:36 -0700, Scott Long wrote: Greg 'groggy' Lehey wrote: On Wednesday, 30 March 2005 at 23:01:03 -0500, John Baldwin wrote: It would be interesting to see the contents of your MADT to see if it's trying to use a 64-bit PA for your APIC. Any suggestions about how to do so? man acpidump How do you run that on a system that won't boot? You said the system worked with 4 GB (albeit detecting only 3.5 GB). Yes, this is correct. A number of people have explained why it only detected 3.5 GB in this configuration. My perception of this whole ACPI thing is that it is fixed in your BIOS (although it can be overridden by the OS). As such, the amount of RAM you have in the machine shouldn't change acpidump results. Is that not correct? This is absolutely correct. Ah, so you meant to say that the output from the system running with 4 GB memory is useful? That wasn't in the man page you pointed to. What it does say is: When invoked with the -t flag, the acpidump utility dumps contents of the following tables: ... MADT This may be the case, but between man page and output some terminology must have changed. I can't see any reference to anything like an MADT there. Does that mean that there isn't one, or that ACPI can't find it, or does the section APIC refer to/dump the MADT? Here's the complete output of acpidump -t, anyway: snip acpidump output Since I don't know anything about ACPI, this doesn't say too much to me. Suggestions welcome. If the APIC section is the MADT, it looks as if we should update the docco. My limited research (as in, Google) shows that the MADT was defined as part of ACPI 2.0: http://www.microsoft.com/whdc/system/platform/64bit/IA64_ACPI.mspx According to your previous link the motherboard specs, it supports both ACPI 1.0A and 2.0. Perhaps there is a BIOS knob to toggle between the two? Jon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: new LORs on 5.4 pre
On 03/30/05 08:23, Rene Ladan wrote: On Wed, Mar 30, 2005 at 05:52:13AM -0800, Kris Kennaway wrote: On Wed, Mar 30, 2005 at 11:17:50AM +0200, Rene Ladan wrote: Hi, I've stumbled over some new LORs (all continuable) on 5.4pre from 2005-03-29 09:49 UTC, thus before the bpf/DHCP fix. lock order reversal 1st 0xc0642b60 Giant (Giant) @ /usr/src/sys/kern/kern_timeout.c:256 2nd 0xc14d7264 fxp0 (network driver) @ /usr/src/sys/modules/fxp/../../dev/fxp/if_fxp.c:1233 Is your fxp module up-to-date? Stale modules (i.e. compiled for a different kernel than the one you're running) will cause problems. All modules are up to date. This LOR popped up after installing from a resume buildworld. After blowing away /usr/obj, make cleandir twice in /usr/src and rebuilding and reinstalling world+kernel, it and the others still pop up, especially after any of these commands: # dhclient fxp0 # ntpd -q % fetchmail (only at startup, not after wakeup) Browsing in links does _not_ trigger a LOR. I saw a LOR similar to the rtentry one on -CURRENT a few days ago. See my message 4 LORs and a freeze with wi(4): http://lists.freebsd.org/pipermail/freebsd-current/2005-March/047862.html Jon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: CPUTYPE=pentium-m
David O'Brien wrote: On Sat, Mar 12, 2005 at 10:48:52PM +0100, Bartosz Fabianowski wrote: Are you saying, all we need to do is commit this diff to make everyone's environment happy? Obviously, I can't speak for everyone. For me, your patch fixes the kernel. Can you try with just -mno-sse2? I'd like to litter the compile command line as little as possible. Saw the commit -- do you plan to MFC? I think this will solve my CPUTYPE?=athlon-xp issues with the loader, so it would be awesome if we could get this in before 5.4... Jon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: CPUTYPE=pentium-m
David O'Brien wrote: On Sat, Mar 12, 2005 at 10:48:52PM +0100, Bartosz Fabianowski wrote: Are you saying, all we need to do is commit this diff to make everyone's environment happy? Obviously, I can't speak for everyone. For me, your patch fixes the kernel. Can you try with just -mno-sse2? I'd like to litter the compile command line as little as possible. I had this issue a while back with my Athlon-XP box (http://lists.freebsd.org/pipermail/freebsd-current/2004-November/042127.html). Note that I would get instant reboots with CPUTYPE?=athlon-xp, CPUTYPE?=p3, and CPUTYPE?=p2. However, it worked fine with CPUTYPE?=k6-2. I think you are right to be cautious and disable anything that uses FP registers. Jon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: CPUTYPE=pentium-m
David O'Brien wrote:
On Tue, Mar 15, 2005 at 01:41:55PM -0600, Jon Noack wrote:
David O'Brien wrote:
On Sat, Mar 12, 2005 at 10:48:52PM +0100, Bartosz Fabianowski wrote:
Are you saying, all we need to do is commit this diff to make everyone's
environment happy?
Can you try with just -mno-sse2? I'd like to litter the compile command
line as little as possible.
I had this issue a while back with my Athlon-XP box
(http://lists.freebsd.org/pipermail/freebsd-current/2004-November/042127.html).
Note that I would get instant reboots with CPUTYPE?=athlon-xp, CPUTYPE?=p3,
and CPUTYPE?=p2. However, it worked fine with CPUTYPE?=k6-2. I think you
are right to be cautious and disable anything that uses FP registers.
I remember that problem but I don't know why I don't experience it, since
I also use CPUTYPE=athlon-mp on my home desktop. I suspect the problem
is SSE2 usage, which the Althon {X,M}P doesn't support.
Huh. That didn't fix it for me. I manually merged the
sys/boot/i386/Makefile.inc and sys/boot/i386/boot2/Makefile changes,
added CPUTYPE?=athlon-xp, rebuilt world and kernel, and rebooted. Same
behavior. Oh crap -- I just noticed the sys/conf/kern.mk patch.
Rebuilding kernel...
Jon
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: CPUTYPE=pentium-m
Jon Noack wrote:
David O'Brien wrote:
On Tue, Mar 15, 2005 at 01:41:55PM -0600, Jon Noack wrote:
David O'Brien wrote:
On Sat, Mar 12, 2005 at 10:48:52PM +0100, Bartosz Fabianowski wrote:
Are you saying, all we need to do is commit this diff to make
everyone's
environment happy?
Can you try with just -mno-sse2? I'd like to litter the compile
command
line as little as possible.
I had this issue a while back with my Athlon-XP box
(http://lists.freebsd.org/pipermail/freebsd-current/2004-November/042127.html).
Note that I would get instant reboots with CPUTYPE?=athlon-xp,
CPUTYPE?=p3, and CPUTYPE?=p2. However, it worked fine with
CPUTYPE?=k6-2. I think you are right to be cautious and disable
anything that uses FP registers.
I remember that problem but I don't know why I don't experience it, since
I also use CPUTYPE=athlon-mp on my home desktop. I suspect the problem
is SSE2 usage, which the Althon {X,M}P doesn't support.
Huh. That didn't fix it for me. I manually merged the
sys/boot/i386/Makefile.inc and sys/boot/i386/boot2/Makefile changes,
added CPUTYPE?=athlon-xp, rebuilt world and kernel, and rebooted. Same
behavior. Oh crap -- I just noticed the sys/conf/kern.mk patch.
Rebuilding kernel...
Well, that didn't work either. I even rebuilt the loader with a
hardcoded CPUTYPE=i686 for sys/boot/i386/Makefile.inc and
sys/boot/i386/boot2/Makefile and it STILL rebooted instantly. Is it
possible GCC compiled with CPUTYPE?=athlon-xp produces bad code? I
guess my BIOS writer could've been on crack, but the machine is rock
solid without CPUTYPE defined so I don't think it is a hardware problem.
I'm willing to debug this but I need someone's hand to hold...
Jon
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: from 5.4-PRERELEASE - 5.3-RELEASE-p5 error?
Bashar wrote: Doug White wrote: On Thu, 10 Mar 2005, Bashar wrote: Doug White wrote: On Wed, 9 Mar 2005, Bashar wrote: Hello, i was wondering just right after the downgrade been facing some issues such as: 1. server# /usr/local/bin/strace -f ps PIOCSFL: Inappropriate ioctl for device trouble opening proc file 2. mounting ext2fs partition doesn't work unless i specify -ro or it will give operation not permitted. any idea what might be causing this? How did you perform the downgrade? The strace error looks like you're still running the 5.3-STABLE binary. first i ran RELENG_5 and when i got the 5.4-PRERELEASE (which incompatible with cPanel.net software) i had to run cvsup with RELENG_5_3 after than i started getting those errors You're leaving out important details, like what you did after you cvsup'd. the usual ,cvsup'ed then cd /usr/src make buildworld make installworld cd /sys/i386/conf config mykernel cd ../compile/mykernel make depend make make install reboot This is the usual? You should read http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/makeworld.html#AEN27432 and /usr/src/UPDATING. The Canonical Way to Update Your System (for 5.x): 1) make buildworld 2) make buildkernel KERNCONF=YOUR_KERNEL_HERE 3) make installkernel KERNCONF=YOUR_KERNEL_HERE 4) reboot in single user 5) /etc/rc.d/preseedrandom 6) mergemaster -p 7) make installworld 8) mergemaster 9) reboot Jon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Just a sanity check before I sumbit a buig report
Pete French wrote: Why does sysconf(_SC_CLK_TCK) always returns 128? Check out sysconf() in src/lib/libc/gen/sysconf.c (lines 83-84 of rev. 1.10): [follow through of code showing it is defined as a constant snipped] To determine how stathz can vary, we'll have to dig deeper. Check out initclocks() in src/sys/kern/kern_clock.c (lines 196-213 of rev. 1.105.2.11): [follow through of code showing it depends on apm_attach() snipped] Thanks for that, most instructive! So the conclusion appears to be that sysconf(_SC_CLK_TCK) is doing the wrong thing by returning a constant then ? Thanks, I'll submit a pr about it. Do you mind if I attach your email to it to show the follow through of the code ? I havent looked at it myself in that much depth. sysconf(3) states that _SC_CLK_TCK is the frequency of the statistics clock in ticks per second. Considering this value varies, returning a constant is wrong. Feel free to attach my email on the PR. Also, have you verified that apm is enabled and listed with flags 0x20 in the kernel config(s) of the problematic system(s)? Jon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: from 5.4-PRERELEASE - 5.3-RELEASE-p5 error?
On 03/11/05 15:57, Bashar wrote: Jon Noack wrote: Bashar wrote: Doug White wrote: On Thu, 10 Mar 2005, Bashar wrote: Doug White wrote: On Wed, 9 Mar 2005, Bashar wrote: Hello, i was wondering just right after the downgrade been facing some issues such as: 1. server# /usr/local/bin/strace -f ps PIOCSFL: Inappropriate ioctl for device trouble opening proc file 2. mounting ext2fs partition doesn't work unless i specify -ro or it will give operation not permitted. any idea what might be causing this? How did you perform the downgrade? The strace error looks like you're still running the 5.3-STABLE binary. first i ran RELENG_5 and when i got the 5.4-PRERELEASE (which incompatible with cPanel.net software) i had to run cvsup with RELENG_5_3 after than i started getting those errors You're leaving out important details, like what you did after you cvsup'd. the usual ,cvsup'ed then cd /usr/src make buildworld make installworld cd /sys/i386/conf config mykernel cd ../compile/mykernel make depend make make install reboot This is the usual? You should read http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/makeworld.html#AEN27432 and /usr/src/UPDATING. The Canonical Way to Update Your System (for 5.x): 1) make buildworld 2) make buildkernel KERNCONF=YOUR_KERNEL_HERE 3) make installkernel KERNCONF=YOUR_KERNEL_HERE 4) reboot in single user 5) /etc/rc.d/preseedrandom 6) mergemaster -p 7) make installworld 8) mergemaster 9) reboot Cant do this for remote system as you know I was merely pointing out what was the official take on the usual. The general consensus for remote systems is to replace steps 4 and 5 with shut down as many services as possible. This has never failed me for minor updates, but caution is advised for major ones. Jon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: from 5.4-PRERELEASE - 5.3-RELEASE-p5 error?
On 03/11/05 22:32, Bashar wrote: Jon Noack wrote: On 03/11/05 15:57, Bashar wrote: Jon Noack wrote: Bashar wrote: Doug White wrote: On Thu, 10 Mar 2005, Bashar wrote: Doug White wrote: On Wed, 9 Mar 2005, Bashar wrote: Hello, i was wondering just right after the downgrade been facing some issues such as: 1. server# /usr/local/bin/strace -f ps PIOCSFL: Inappropriate ioctl for device trouble opening proc file 2. mounting ext2fs partition doesn't work unless i specify -ro or it will give operation not permitted. any idea what might be causing this? How did you perform the downgrade? The strace error looks like you're still running the 5.3-STABLE binary. first i ran RELENG_5 and when i got the 5.4-PRERELEASE (which incompatible with cPanel.net software) i had to run cvsup with RELENG_5_3 after than i started getting those errors You're leaving out important details, like what you did after you cvsup'd. the usual ,cvsup'ed then cd /usr/src make buildworld make installworld cd /sys/i386/conf config mykernel cd ../compile/mykernel make depend make make install reboot This is the usual? You should read http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/makeworld.html#AEN27432 and /usr/src/UPDATING. The Canonical Way to Update Your System (for 5.x): 1) make buildworld 2) make buildkernel KERNCONF=YOUR_KERNEL_HERE 3) make installkernel KERNCONF=YOUR_KERNEL_HERE 4) reboot in single user 5) /etc/rc.d/preseedrandom 6) mergemaster -p 7) make installworld 8) mergemaster 9) reboot Cant do this for remote system as you know I was merely pointing out what was the official take on the usual. The general consensus for remote systems is to replace steps 4 and 5 with shut down as many services as possible. This has never failed me for minor updates, but caution is advised for major ones. AFAIK 6,7,8 is not required unless i'm updating cross major freebsd version i,e v4.x - 5.x ? correct my if i'm wrong. Step 6 is rarely needed (most often for a FreeBSD version update as you describe). Steps 7 and 8 are required (although step 8 may be a noop). Jon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Just a sanity check before I sumbit a buig report
Pete French wrote:
'sysctl kern.clockrate' will return this information if you don't want to
write a program to do it for you :)
I was just using the code from time(1). Inteesring though - heres the
output:
kern.clockrate: { hz = 100, tick = 1, tickadj = 5, profhz = 100, stathz =
100 }
So that thinks stathz is 100, but sysconf(_SC_CLK_TCK) is returning 128!
What are the two machines? stathz is 128 on i386, 100 on sparc64, and 130
on amd64. Or thats the defaults at least.
These are all i386 machines - I have a number of them, all running 4.11.
I can take the same a.out and run it on all of them - on some both
numbers are 128, on other the numbers are 100 and 128.
If I go to one where both the calls return 128 though, the output
of 'sysctl kern.clockrate' is this:
kern.clockrate: { hz = 100, tick = 1, tickadj = 5, profhz = 1024, stathz =
128 }
So, it looks like theres a bug in sysconf(_SC_CLK_TCK) possibly ? because
it seems to be always returning 128, regardless of the value of stathz
as returned by 'sysctl kern.clockrate'
I can reproduce this on a number of machines BTW - the only things they have in
common is that I wrote their kernel config files at various points in time...
I infer from your kern.clockrate output that you are running 4.x.
Why does sysconf(_SC_CLK_TCK) always returns 128? Check out sysconf()
in src/lib/libc/gen/sysconf.c (lines 83-84 of rev. 1.10):
**
case _SC_CLK_TCK:
return (CLK_TCK);
**
CLK_TCK is defined in src/include/time.h (line 52 of rev. 1.15):
**
#define CLK_TCK _BSD_CLK_TCK_
**
_BSD_CLK_TCK_ is defined in src/sys/i386/include/ansi.h (line 101 of
rev. 1.18.2.4):
**
#define_BSD_CLK_TCK_ 128
**
So on i386 (and FreeBSD 4.x), sysconf(_SC_CLK_TCK) will always return
128. If you look in src/sys/alpha/include/ansi.h, you'll see that on
alpha it will always return 100.
To determine how stathz can vary, we'll have to dig deeper. Check out
initclocks() in src/sys/kern/kern_clock.c (lines 196-213 of rev.
1.105.2.11):
**
/*
* Set divisors to 1 (normal case) and let the machine-specific
* code do its bit.
*/
psdiv = pscnt = 1;
cpu_initclocks();
#ifdef DEVICE_POLLING
init_device_poll();
#endif
/*
* Compute profhz/stathz, and fix profhz if needed.
*/
i = stathz ? stathz : hz;
if (profhz == 0)
profhz = i;
psratio = profhz / i;
**
stathz and profhz are originally set by cpu_initclocks() (which is MD).
If they are not set at this point, hz is used. This must be the case
for some of your machines as both stathz and profhz equal hz. So why
aren't stathz and profhz being set earlier? Check out cpu_initclocks()
in src/sys/i386/isa/clock.c (lines 995-1008 of rev. 1.149.2.6):
** if
(statclock_disable) {
/*
* The stat interrupt mask is different without the
* statistics clock. Also, don't set the interrupt
* flag which would normally cause the RTC to generate
* interrupts.
*/
stat_imask = HWI_MASK | SWI_MASK;
rtc_statusb = RTCSB_24HR;
} else {
/* Setting stathz to nonzero early helps avoid races. */
stathz = RTC_NOPROFRATE;
profhz = RTC_PROFRATE;
}
**
If you look in src/sys/isa/rtc.h, you'll see that RTC_NOPROFRATE=128 and
RTC_PROFRATE=1024. The only way stathz and profhz will not be set here
is if statclock_disable is true. Where is statclock_disable set? Check
out apm_attach() in src/sys/i386/apm/apm.c (lines 1032-1033 of rev.
1.114.2.6):
**
if (flags 0x20)
statclock_disable = 1;
**
Thus, you must have device apm0 flags 0x20 or something similar in
your kernel config file for you to get stathz and profhz as 100. apm is
disabled in GENERIC, so by default this is not a problem; apm_attach
won't be called if apm is disabled, so the fact that GENERIC includes
flags 0x20 is irrelevant.
Jon
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: xSeries346 and FreeBSD 5.3
pck wrote: On Wed, 9 Mar 2005 19:22:09 +0800, Rong-En Fan [EMAIL PROTECTED] wrote: On Wed, 9 Mar 2005 12:10:09 +0100, pck [EMAIL PROTECTED] wrote: Welcome, I've just bought IBM xSeries346 server. There was no problem with installing FreeBSD 5.3, but problem is with LAN card - BCM5721 (I think, reseller told me this name). Is there any possibility to run this card? You have to install a 5-STABLE or manually get following files src/sys/dev/bge/* src/sys/dev/mii/miidevs src/sys/dev/mii/brgphy.c and recompile kernel. without those two mii files, you can only run 100-baseTX. From where i must download these files? I've just made cvsup on my workstation (*default release=cvs tag=RELENG_5) and got: So you updated your source to 5-STABLE. saucepan# pwd /usr/src/sys/dev/bge saucepan# ls -al total 186 drwxr-xr-x2 root wheel 512 Mar 9 12:51 . drwxr-xr-x 155 root wheel2560 Mar 9 12:53 .. -rw-r--r--1 root wheel 101313 Mar 2 21:29 if_bge.c -rw-r--r--1 root wheel 81011 Mar 2 11:08 if_bgereg.h saucepan# Looks like what I have here. Follow the directions near the bottom of /usr/src/UPDATING to update the system from source: To rebuild everything and install it on the current system. When you're done you should be running 5-STABLE (currently 5.4-PRERELEASE). Jon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: amd64 and CPUTYPE: i386 loader unusable
Dmitry Morozovsky wrote:
[EMAIL PROTECTED]:/usr/src uname -a
FreeBSD gwhx.rinet.ru 5.4-PRERELEASE FreeBSD 5.4-PRERELEASE #0: Tue Mar 1
08:22:54 UTC 2005 [EMAIL PROTECTED]:/usr/obj/lh/src/sys/MINI amd64
defining CPUTYPE=athlon64 in /etc/make conf renders loader unusable: it builds
with athlon64 optimization, and crashes (reboots) immediately. The following
patch fixes the problem for me.
I had the exact same problem with CPUTYPE?=athlonxp on an i386 system
several months ago:
http://lists.freebsd.org/pipermail/freebsd-current/2004-October/040493.html
http://lists.freebsd.org/pipermail/freebsd-current/2004-October/041981.html
http://lists.freebsd.org/pipermail/freebsd-current/2004-November/042127.html
I've just been running without CPUTYPE defined as I didn't know what
steps to take to debug it and didn't get a response to help.
I can test and debug this if someone will help me out.
Jon
Index: sys/boot/i386/Makefile.inc
===
RCS file: /home/ncvs/src/sys/boot/i386/Makefile.inc,v
retrieving revision 1.9
diff -u -r1.9 Makefile.inc
--- sys/boot/i386/Makefile.inc 9 Feb 2004 14:11:55 - 1.9
+++ sys/boot/i386/Makefile.inc 1 Mar 2005 15:32:44 -
@@ -9,6 +9,7 @@
LDFLAGS+= -nostdlib
.if ${MACHINE_ARCH} == amd64
+CPUTYPE= i686
CFLAGS+= -m32
LDFLAGS+= -m elf_i386_fbsd
AFLAGS+= --32
Sincerely,
D.Marck [DM5020, MCK-RIPE, DM3-RIPN]
*** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] ***
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 5-STABLE, MSI KT880 , fxp and SCB timeouts
Mario Sergio Fujikawa Ferreira wrote: On Wed, Feb 23, 2005 at 09:33:41PM -0600, Jon Noack wrote: On 02/23/05 21:30, Dan Nelson wrote: In the last episode (Feb 23), Jon Noack said: On 02/23/05 20:06, Mario Sergio Fujikawa Ferreira wrote: My last motherboard burned down to ashes so I got myself a brand (after 2 weeks) new MSI KT880. I am getting some weird results. 1) fxp intel etherxpress 10/100 network cards report SCB timeout as well as achieving ridiculously low transfer rates of 600 Bytes/second. Well, I got 10 KBytes/sec once but that does not count since a side box gets more than 50KB/s ;-) on the same hub. Oh, I've already switched hub ports, rj45 cables and fxp cards. Duplex mismatch? You say hub and not switch, so you might need to force the card to half-duplex. Oddly enough, the fxp(4) man page doesn't include half-duplex as a media option. Surely it supports it... Actually, it is a 5 port switch (10/100 TX). Any thoughts? I can provide as much information as necessary. By the way, another computer using exactly a fxp connected to the same switch works nicely. Try forcing full-duplex? The output of ifconfig would also be helpful (you can sanitize IP and MAC addresses)? Jon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 5-STABLE, MSI KT880 , fxp and SCB timeouts
On 02/23/05 20:06, Mario Sergio Fujikawa Ferreira wrote: My last motherboard burned down to ashes so I got myself a brand (after 2 weeks) new MSI KT880. I am getting some weird results. 1) fxp intel etherxpress 10/100 network cards report SCB timeout as well as achieving ridiculously low transfer rates of 600 Bytes/second. Well, I got 10 KBytes/sec once but that does not count since a side box gets more than 50KB/s ;-) on the same hub. Oh, I've already switched hub ports, rj45 cables and fxp cards. Duplex mismatch? You say hub and not switch, so you might need to force the card to half-duplex. Oddly enough, the fxp(4) man page doesn't include half-duplex as a media option. Surely it supports it... Jon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 5-STABLE, MSI KT880 , fxp and SCB timeouts
On 02/23/05 21:30, Dan Nelson wrote: In the last episode (Feb 23), Jon Noack said: On 02/23/05 20:06, Mario Sergio Fujikawa Ferreira wrote: My last motherboard burned down to ashes so I got myself a brand (after 2 weeks) new MSI KT880. I am getting some weird results. 1) fxp intel etherxpress 10/100 network cards report SCB timeout as well as achieving ridiculously low transfer rates of 600 Bytes/second. Well, I got 10 KBytes/sec once but that does not count since a side box gets more than 50KB/s ;-) on the same hub. Oh, I've already switched hub ports, rj45 cables and fxp cards. Duplex mismatch? You say hub and not switch, so you might need to force the card to half-duplex. Oddly enough, the fxp(4) man page doesn't include half-duplex as a media option. Surely it supports it... Autodetection on ethernet detects both speed and duplex, and full-duplex and half-duplex are either/or, so if you force a speed and don't force full-duplex, you get half-duplex by default. OK -- makes sense. I run em and fxp cards and noted that em(4) listed both while fxp(4) listed only full-duplex. Confusing... Jon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cvs tag for -STABLE for ports-supfile ? use HEAD or ???
On 02/23/05 21:55, W C wrote: I just (successfully) upgraded my remote 5.2.1 box to 5.3-STABLE Feb 22 05 with the usual buildworld buildkernel installkernel mergemaster reboot installworld mergemaster reboot etc. I want to upgrade my ports tree to that which is correct for -STABLE. Is there a ports-STABLE cvs tag I can use, or is it safe to just use HEAD, as is in the stock supfile? Using the stock ports-supfile (tag=.) is fine. The ports tree does not have versions; the ports system is version-aware so the same port will work correctly across the board (at least, that's the idea ;-). Jon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Brief window moving delay after idle..
Julio Capote wrote: I've been on RELENG_5 for about 1 week now running ULE with PREEMPT. Recently, I noticed some strange behavior that could be related to scheduling; usually I leave my computer on all night (doing nothing as I sleep), But when I'd wake up, and drag a window around, it seems this sudden rush of input catches the scheduler by surprise and everything is really slow for about 5 seconds. Its a peculiar type of slow since everything moves smoothly, just 1-2 seconds behind, theres no stuttering at all. Gkrellm shows my cpu usage to peak for the time its really slow, and then drop to normal when everything pops back into speed. I guess the best way to describe it would be bullet time on your desktop. ^^^ Sounds like a feature... ;-) Seriously, though: I recently tried ULE+PREEMPTION on a few machines and got some panics on my SMP box (http://lists.freebsd.org/pipermail/freebsd-stable/2005-February/011951.html). My UP machines haven't done anything too strange, though. *shrug* Getting a lot closer, but not quite there yet... Jon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
panic with ULE+PREEMPTION
After the recent discussion on stable@, I decided to try ULE again.
When attempting to log into Squirrelmail on my RELENG_5 server (sources
from late Wednesday night), I got the following panic:
Fatal trap 12: page fault while in kernel mode
cpuid = 1; apic id = 01
fault virtual address = 0x150
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc04e1152
stack pointer = 0x10:0xe4de1a4c
frame pointer = 0x10:0xe4de1a70
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= resume, IOPL = 0
current process = 36 (swi1: net)
Although I have KDB and DDB configured (see attached kernel config
file), I was unable to enter DDB via Ctrl+Alt+Esc. It just hung at the
panic message. Any tips on how to get DDB to work? On a related note,
I guess swap on gmirror cannot be a dumpdev:
dumpon: ioctl(DIOCSKERNELDUMP): Operation not supported
swapon: adding /dev/mirror/mirror0s1b as swap device
In any case, here's what I got out of gdb:
(gdb) l *0xc04e1152
0xc04e1152 is in sched_add_internal (/usr/src/sys/kern/sched_ule.c:1696).
1691
1692CTR5(KTR_SCHED, sched_add: %p(%s) prio %d by %p(%s),
1693td, td-td_proc-p_comm, td-td_priority, curthread,
1694curthread-td_proc-p_comm);
1695mtx_assert(sched_lock, MA_OWNED);
1696ke = td-td_kse;
1697kg = td-td_ksegrp;
1698if (ke-ke_flags KEF_ASSIGNED) {
1699if (ke-ke_flags KEF_REMOVED) {
1700SLOT_USE(ke-ke_ksegrp);
I use Squirrelmail only for convenience, so I'll leave the config as is
in case anyone can help me debug further. Note that this is
reproducible *every* time I login to Squirrelmail (click login and
near instant panic -- sometimes the page starts to load, but never
finishes). IMAP access through Thunderbird works perfectly.
Thanks,
Jon
P.S. The gmirror errors at the bottom of the dmesg are due to a failed
drive that is being RMA'd. I feel very vulnerable now... ;-)
#
# OPTIMATOR -- Optimator kernel configuration file
# version 4.0
# 2005/02/10
#
machine i386
cpu I686_CPU
ident OPTIMATOR
# To statically compile in device wiring instead of /boot/device.hints
#hints GENERIC.hints # Default places to look for devices.
makeoptions DEBUG=-g# Build kernel with gdb(1) debug symbols
options SCHED_ULE # ULE scheduler
#optionsSCHED_4BSD # 4BSD scheduler
options PREEMPTION # Enable kernel thread preemption
options INET# InterNETworking
options INET6 # IPv6 communications protocols
options FFS # Berkeley Fast Filesystem
options SOFTUPDATES # Enable FFS soft updates support
options UFS_ACL # Support for access control lists
options UFS_DIRHASH # Improve performance on big directories
options MD_ROOT # MD is a potential root device
options NFSCLIENT # Network Filesystem Client
options NFSSERVER # Network Filesystem Server
options NFS_ROOT# NFS usable as /, requires NFSCLIENT
options MSDOSFS # MSDOS Filesystem
options CD9660 # ISO 9660 Filesystem
options PROCFS # Process filesystem (requires PSEUDOFS)
options PSEUDOFS# Pseudo-filesystem framework
options GEOM_GPT# GUID Partition Tables.
options COMPAT_43 # Compatible with BSD 4.3 [KEEP THIS!]
options COMPAT_FREEBSD4 # Compatible with FreeBSD4
options SCSI_DELAY=5000 # Delay (in ms) before probing SCSI
options KTRACE # ktrace(1) support
options SYSVSHM # SYSV-style shared memory
options SYSVMSG # SYSV-style message queues
options SYSVSEM # SYSV-style semaphores
options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time
extensions
options KBD_INSTALL_CDEV# install a CDEV entry in /dev
options AHC_REG_PRETTY_PRINT# Print register bitfields in debug
# output. Adds ~128k to driver.
options AHD_REG_PRETTY_PRINT# Print register bitfields in debug
# output. Adds ~215k to driver.
options ADAPTIVE_GIANT # Giant mutex is adaptive.
# Debugging for use in -current
options KDB # Enable kernel debugger support.
options KDB_TRACE # Print a stack trace of the current
thread on the console for a panic.
options
Re: panic with ULE+PREEMPTION
On 02/11/05 22:08, Jon Noack wrote:
After the recent discussion on stable@, I decided to try ULE again. When
attempting to log into Squirrelmail on my RELENG_5 server (sources from
late Wednesday night), I got the following panic:
Fatal trap 12: page fault while in kernel mode
cpuid = 1; apic id = 01
fault virtual address = 0x150
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc04e1152
stack pointer = 0x10:0xe4de1a4c
frame pointer = 0x10:0xe4de1a70
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= resume, IOPL = 0
current process = 36 (swi1: net)
Got another one:
Fatal trap 12: page fault while in kernel mode
cpuid = 1; apic id = 01
fault virtual address = 0x4c
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc04e1094
stack pointer = 0x10:0xeb2bfa3c
frame pointer = 0x10:0xeb2bfa50
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= resume, IOPL = 0
current process = 302 (named)
(gdb) l *0xc04e1094
0xc04e1094 is in sched_choose (/usr/src/sys/kern/sched_ule.c:1650).
1645kseq_assign(kseq);
1646#endif
1647ke = kseq_choose(kseq);
1648if (ke) {
1649#ifdef SMP
1650if (ke-ke_ksegrp-kg_pri_class == PRI_IDLE)
1651if (kseq_idled(kseq) == 0)
1652goto restart;
1653#endif
1654kseq_runq_rem(kseq, ke);
Jon
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: UPDATE: ATA mkIII first official patches - please test!
On 02/09/05 16:34, Tim Welch wrote: On Wed, 2005-02-09 at 15:00 +0100, Søren Schmidt wrote: Søren Schmidt wrote: http://people.freebsd.org/~sos/ata-mk3j.diff-releng5.gz http://people.freebsd.org/~sos/ata-mk3j.diff-current.gz http://people.freebsd.org/~sos/ata-mk3j.tar.gz New version that fixes known problems so far etc now available: http://people.freebsd.org/~sos/ata-mk3k.diff-releng5.gz http://people.freebsd.org/~sos/ata-mk3k.diff-current.gz http://people.freebsd.org/~sos/ata-mk3k.tar.gz The diffs hasn't changed, so for those that has already applied those you can just untar the tarfile (still relative to /usr/src). Fixes include: o atapi-cd eject/close o SiI controllers lost some (slow) SATA disks in probe o panic when detaching disk not part of a RAID. o Cable detection failure on channels with both master and slave. As always, enjoy and let me know how it goes... A problem still exists with 48-bit addressing. This url details a fix I've been using for the last 4 months or so with no issues yet. http://lists.freebsd.org/pipermail/freebsd-hackers/2004-October/008821.html Problem was fixed in -CURRENT a couple months ago: http://docs.freebsd.org/cgi/mid.cgi?200412090731.iB97V7pB035207 MFC anyone? Jon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 50% of packets lost only on local interfaces
José M. Fandiño wrote: Kris Kennaway wrote: On Mon, Feb 07, 2005 at 11:15:52AM +0100, Jos? M. Fandi?o wrote: Jos? M. Fandi?o wrote: Chris wrote: Have tested on 3 boxes. yes, it's the intended operation and If I don't see it I don't believe it but it happens. I ever thought it would be possible. Finally, I found the culprit: CFLAGS= \ 100% of the transmited traffic is received COPTFLAGS= / CFLAGS= -pipe \ 50% of the transmited traffic is received COPTFLAGS= -pipe / That would be exceedingly strange, because the above two options are supposed to produce *no differences at all* with the code generation. I'd believe that -O and no -O could behave differently, although I don't know why you'd want to compile without -O. because by the time I was compiling the system I was no interested in compiler optimizations. Now I prefer a lightly optimized kernel than a system with 50% of packet lost in local interfaces ;-) -O is the default for -STABLE; anything else might very well cause problems. In fact, check out the CFLAGS section of /usr/share/examples/etc/make.conf: Note that optimization settings other than -O and -O2 are not recommended or supported for compiling the world or the kernel - please revert any nonstandard optimization settings to -O before submitting bug reports without patches to the developers. Jon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 50% of packets lost only on local interfaces
José M. Fandiño wrote: Jon Noack wrote: Finally, I found the culprit: CFLAGS= \ 100% of the transmited traffic is received COPTFLAGS= / CFLAGS= -pipe \ 50% of the transmited traffic is received COPTFLAGS= -pipe / That would be exceedingly strange, because the above two options are supposed to produce *no differences at all* with the code generation. I'd believe that -O and no -O could behave differently, although I don't know why you'd want to compile without -O. because by the time I was compiling the system I was no interested in compiler optimizations. Now I prefer a lightly optimized kernel than a system with 50% of packet lost in local interfaces ;-) -O is the default for -STABLE; anything else might very well cause problems. In fact, check out the CFLAGS section of /usr/share/examples/etc/make.conf: Note that optimization settings other than -O and -O2 are not recommended or supported for compiling the world or the kernel - please revert any nonstandard optimization settings to -O before submitting bug reports without patches to the developers. I think this comment was referring to higher optimizations levels than -O2, anyway removing -O shouldn't be so harmful. The explanation I've heard (I have no actual knowledge here, I'm just good at repeating others) is that gcc doesn't compile any ASM with -O0 (which is what you get with CFLAGS=-pipe). This Breaks Things(tm): http://docs.freebsd.org/cgi/mid.cgi?20020623214947.J84322 kern/52764 is another example: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/52764 More generically it makes sense that gcc treat code differently with -O0 than with -O. With the vast majority of users using -O and different code paths being taken with -O0, it doesn't surprise me at all that there are issues. It should be assumed that nonstandard means exactly what it says: something other than -O (or more recently -O2). If it breaks, try -O. If it's still broken with -O, report away. Regards, Jon P.S. Historically, the reason to use -O0 was for easier debugging. It appears that steps have been taken to ease debugging with -O to the point that it is no longer necessary to use -O0 (with the FreeBSD kernel and world, at least); I don't recall a FreeBSD developer ever asking someone to recompile with -O0 to help solve a problem... ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ATA mkIII first official patches - please test!
On 02/03/05 14:52, Søren Schmidt wrote: ATA-mkIII first official snapshot. This is the much rumoured ATA update that I've been working on for some time. It contains a number of new things, and lacks a few features of the old code. New items include: o ATA is now fully newbus'd and split into modules. This means that on a modern system you just load atapci and ata to get the base support, and then one or more of the device subdrivers atadisk atapicd atapifd atapist ataraid. All can be loaded/unloaded anytime, but for obvious reasons you dont want to unload atadisk when you have mounted filesystems. o The device identify part of the probe has been rewritten to fix the problems with odd devices the old had, and to try to remove so of the long delays some HW could provoke. o SATA devices can be hot inserted/removed and devices will be created/ removed in /dev accordingly. NOTE only supported on controllers that has this feature: Promise and Silicon Image for now. o ATA RAID support has been rewritten and and now supports these metadata formats: Adaptec HostRAID Highpoint V2 RocketRAID Highpoint V3 RocketRAID Intel MatrixRAID Integrated Technology Express LSILogic V2 MegaRAID LSILogic V3 MegaRAID Promise FastTrak Silicon Image Medley o The reinit code has been worked over to be much more robust. o The timeout code has been overhauled for races. o Lots of fixes for bugs found while doing the modulerization and reviewing the old code. Missing features form current ATA: o atapi-cd no longer has support for ATAPI changers. Todays its much cheaper and alot faster to copy those CD images to disk and serve them from there. Besides they dont seem to be made anymore, maybe for that exact reason. o ATA RAID can only read metadata not write them. This means that arrays can be picked up from the BIOS, but they cannot be created from FreeBSD. This is being worked on for the final release as is RAID5 support for Promise/Highpoing/SiI controllers. o The atapi-cam author has been informed and has had early access to this work but so far atapicam is not supported with these changes. However I do have my own atacam that puts both ATA and ATAPI devices under CAM, but its really just academic at this point. And then there all the things that I've happily forgotten about :) The snapshot is available as a patch for RELENG_5 and for CURRENT, and a common tarfile of the new ATA code. http://people.freebsd.org/~sos/ata-mk3j.diff-releng5.gz http://people.freebsd.org/~sos/ata-mk3j.diff-current.gz http://people.freebsd.org/~sos/ata-mk3j.tar.gz Both patches and the tarfile is relative to /usr/src. You might want to remove the contents of sys/dev/ata/ before unpacking the tarfile. No changes are needed to your config file, unless you want ATA as modules. As usual, even if it works on all the HW I have here in the lab, thats by far not the same as it works on YOUR system. So use glowes and safety shoes and if it breaks I dont want the pieces, but would like to hear the nifty details on how exactly it got that way :) Enjoy! Running RELENG_5 on a dual P3 machine (Abit VP6). I am using the onboard HighPoint HPT370 and had both channels of the onboard VIA 82C686B disabled in the BIOS. It hung solidly during boot attempting to probe the VIA controller (detected a GENERIC IDE controller on isa0 or something like that). When I enabled the primary channel on the VIA in the BIOS, it zipped right through the boot like normal. Other than that hang, I have not noticed any problems during the course of normal (albeit limited) usage. Some quick dd runs with bs=2048 indicated 53MB/s read and 45MB/s write with a single Hitachi 7K250 drive. It's not a big deal to leave the VIA controller enabled (it doesn't share interrupts even without APIC), but ideally it should be ignored when disabled (ACPI issue?). If you'd like me to do more, let me know. Jon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
