Re: NFS network load on 5.4-STABLE
On Sat, 2005-11-26 at 21:49 -0500, Chuck Swiger wrote: > Mike Eubanks wrote: > > As soon as I mount my NFS file systems, the network load increases to a > > constant 80%-90% of network bandwidth, even when the file systems are > > not in use. NFS stats on the client machine (nfsstat -c) produce the > > following: > [ ... ] > > Fsstat and Requests are increasing very rapidly. Both the client and > > server are i386 5.4-STABLE machines. Is this behaviour normal? > > Sort of. Some fancy parts of X like file-manager/exporer applications tend > to > call fstat() a lot, but it's probably tunable, and if you enable NFS > attribute > caching that will help a lot. Thank you for the reply Chuck. It seems that it is something to do with Gnome. I haven't done an upgrade to 2.12 yet, but the difference did happen when I refreshed my user configuration to remove any stale config files. Using the "top -mio" command I get the following: VCSW IVCSW READ WRITE FAULT TOTAL PERCENT COMMAND 38 56 0 0 0 0 0.00% libgtop_server 94 16 0 0 0 0 0.00% Xorg 4 0 0 0 0 0 0.00% top 0 0 0 0 0 0 0.00% mozilla-bin 115 40 0 0 0 0 0.00% multiload-appl 42 1 0 0 0 0 0.00% anjuta-bin 0 0 0 0 0 0 0.00% evolution-2.2 130 9 0 0 0 0 0.00% gnome-terminal 15 10 0 0 0 0 0.00% clock-applet 42 0 0 0 0 0 0.00% mixer_applet2 10 0 0 0 0 0 0.00% metacity 3 0 0 0 0 0 0.00% nautilus 4 0 0 0 0 0 0.00% wnck-applet When I unmount the NFS share, the involuntary context switches drop to nearly 0 and the voluntary context switches drop significantly. Other than that, everything else stayed at 0. I have dumped the traffic on the network adapter in question. With abbreviated host names, there are miles of the following. + file-manager/explorer? | client.220312819 > server.nfs: 96 fsstat [|nfs] server.nfs > client.220312819: reply ok 168 fsstat POST: DIR 755 ids 1001/0 [|nfs] client.220312820 > server.nfs: 96 fsstat [|nfs] server.nfs > client.220312820: reply ok 168 fsstat POST: DIR 755 ids 1001/0 [|nfs] client.220312821 > server.nfs: 96 fsstat [|nfs] server.nfs > client.220312821: reply ok 168 fsstat POST: DIR 755 ids 0/0 [|nfs] client.220312822 > server.nfs: 96 fsstat [|nfs] server.nfs > client.220312822: reply ok 168 fsstat POST: DIR 755 ids 0/0 [|nfs] client.220312823 > server.nfs: 96 fsstat [|nfs] server.nfs > client.220312823: reply ok 168 fsstat POST: DIR 755 ids 0/0 [|nfs] If this is enough evidence for the file-manager/explore, I'll just have to accept it for now. I can't find anything about tuning them. As far as attribute caching, do you mean the `-o ac*' options to mount_nfs? I also noticed two sysctl values, although, I left them unmodified. vfs.nfs.access_cache_timeout: 2 vfs.nfs4.access_cache_timeout: 60 > "ls /afs", if available, is a wonderful test of > whether a program/file-manager is being polite. I better read a book on this first if you're talking about the Andrew File System. Any suggestions? > > Anyway, "top -mio" is likely to be informative. > -- Mike Eubanks <[EMAIL PROTECTED]> ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
dhclient problem with static leases
Hello,
I recently upgraded from FreeBSD 5.4 to 6.0 and now my dhclient
configuration (which did work perfectly with the ISC dhclient) doesn't work
anymore.
I'm using a static lease in dhclient.conf (see below) since the laptop I'm
running FreeBSD on is roaming between different networks.
On the network without a (useful) DHCP server dhclient prints the following
messages, but leaves sis0 (and the routing table and resolv.conf)
unconfigured:
DHCPDISCOVER on sis0 to 255.255.255.255 port 67 interval 5
DHCPNACK from 192.168.0.1 rejected.
DHCPOFFER from 192.168.123.254 rejected.
DHCPOFFER from 192.168.0.1 rejected.
DHCPOFFER from 192.168.0.1 rejected.
DHCPDISCOVER on sis0 to 255.255.255.255 port 67 interval 6
DHCPOFFER from 192.168.123.254 rejected.
DHCPOFFER from 192.168.0.1 rejected.
No DHCPOFFERS received.
Trying recorded lease 134.60.220.229
bound: renewal in 855549552 seconds.
If dhclient gets its lease from a "real" DHCP server everything works fine.
Is there anything I could try to get it working?
Or is it a bug in dhclient?
Jonas
dhclient.conf:
--
# $FreeBSD: src/etc/dhclient.conf,v 1.3 2001/10/27 03:14:37 rwatson Exp $
#
# This file is required by the ISC DHCP client.
# See ``man 5 dhclient.conf'' for details.
#
# In most cases an empty file is sufficient for most people as the
# defaults are usually fine.
#
timeout 10;
retry 36000;
reject 192.168.0.1;
reject 192.168.5.50;
reject 192.168.123.254;
reject 192.168.0.254;
lease {
interface "sis0";
fixed-address 134.60.220.229;
option subnet-mask 255.255.254.0;
option routers 134.60.220.99;
option domain-name-servers 134.60.220.1;
option domain-name "wh-hms.uni-ulm.de";
# option dhcp-lease-time 654321; # lang genug ;)
# option dhcp-renewal-time 65321;
# option dhcp-rebinding-time 65321;
option dhcp-lease-time -1;
# Dummy-Werte:
renew 0 2033/01/01 00:00:00;
rebind 0 2033/01/02 00:00:00;
expire 0 2033/01/03 00:00:00;
}
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: dhclient problem with static leases
On Sun, Nov 27, 2005 at 12:16:25PM +0100, Jonas Wolz wrote: Jonas, > I recently upgraded from FreeBSD 5.4 to 6.0 and now my dhclient > configuration (which did work perfectly with the ISC dhclient) doesn't work > anymore. I'm at BSDCon europe at the moment and noticed strange behavior with dhclient the last days. Removing /var/db/dhclient.leases* fixed the problem not getting a lease for me and several other people over here. -- Regards, Richard. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ACPI problems with Dell laptops
On Saturday, 26 November 2005 at 20:25:58 -0600, Eric Anderson wrote: > Greg 'groggy' Lehey wrote: >> I've had both Dell and ThinkPad (no longer IBM). I prefer Dell, >> despite their attempts to convince me otherwise. >> >> However, we currently seem to have significant ACPI problems with Dell >> laptops. I'm writing this on an Inspiron 6000 running 7-CURRENT, but >> the same problems occur with 6.0: if I enable ACPI, timing goes to >> hell, and some things just time out. There was a similar message a >> couple of days ago from an owner of (I think) the latest Latitude >> machine, which sounded even worse. My requests for feedback about how >> to solve the problem have so far not been resolved. If you're >> otherwise tending towards Dell, I'd suggest you watch this space until >> there's some indication that the problems will be resolved. > > Which scheduler are you using? The standard (ULE). I don't think the problem's related to the scheduler: it shows all the signs of being an interrupt space problem. > Also, have you tried disabling apic? I think you mean ACPI. This machine doesn't have an APIC. To answer the presumed question: Yes, as I said above, the problems only occur when I enable ACPI. Since then I've also discovered that the builtin wireless card doesn't work either. It's: iwi0: mem 0xdfcfd000-0xdfcfdfff irq 10 at device 3.0 on pci3 iwi0: Ethernet address: 00:13:ce:46:28:49 After downloading the firmware, I can set IP addresses and such, but I always get "no carrier": iwi0: flags=8802 mtu 1500 ether 00:13:ce:46:28:49 media: IEEE 802.11 Wireless Ethernet autoselect status: no carrier ssid "" channel 1 (2412) authmode OPEN privacy OFF deftxkey UNDEF powersavemode OFF powersavesleep 100 txpowmax 100 txpower 100 rtsthreshold 2346 fragthreshold 2346 -pureg protmode CTS -wme roaming AUTO bintval 0 When I run dhclient on the interface, I get: DHCPDISCOVER on iwi0 to 255.255.255.255 port 67 interval 6 DHCPDISCOVER on iwi0 to 255.255.255.255 port 67 interval 15 send_packet: Network is down On the console I get the detailed error message: iwi0: fatal error This machine also has Linux on it, and the card works fine with Linux, so it's obviously a FreeBSD-related problem. Greg -- See complete headers for address and phone numbers ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: dhclient problem with static leases
Richard Arends wrote: > Removing /var/db/dhclient.leases* fixed the > problem not getting a lease for me and several other people over here. I'm currently not at the location with the network without a DHCP server, but IIRC I tried that already and it didn't help. It also seems to me that my problem is a bit different: In my case dhclient gets its "lease", but doesn't configure the interface according to it if it is a static lease (and not a lease received from a DHCP server): If there is a DHCP server everything works: nobby:/etc# /etc/rc.d/netif start DHCPDISCOVER on sis0 to 255.255.255.255 port 67 interval 4 DHCPOFFER from 192.168.2.1 DHCPREQUEST on sis0 to 255.255.255.255 port 67 DHCPACK from 192.168.2.1 bound to 192.168.2.3 -- renewal in 7200 seconds. lo0: flags=8049 mtu 16384 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 inet 127.0.0.1 netmask 0xff00 sis0: flags=8843 mtu 1500 options=8 inet6 fe80::2c0:9fff:fe28:2460%sis0 prefixlen 64 scopeid 0x1 inet 192.168.2.3 netmask 0xff00 broadcast 192.168.2.255 ether 00:c0:9f:28:24:60 media: Ethernet autoselect (100baseTX ) status: active nobby:/etc# If there isn't a DHCP server (simulated in my home network by shutting the DHCP server down): nobby:/etc# rm /var/db/dhclient.leases.sis0 nobby:/etc# /etc/rc.d/netif start DHCPDISCOVER on sis0 to 255.255.255.255 port 67 interval 4 DHCPDISCOVER on sis0 to 255.255.255.255 port 67 interval 6 DHCPDISCOVER on sis0 to 255.255.255.255 port 67 interval 1 No DHCPOFFERS received. Trying recorded lease 134.60.220.229 bound: renewal in 855056052 seconds. lo0: flags=8049 mtu 16384 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 inet 127.0.0.1 netmask 0xff00 sis0: flags=8843 mtu 1500 options=8 inet6 fe80::2c0:9fff:fe28:2460%sis0 prefixlen 64 scopeid 0x1 ether 00:c0:9f:28:24:60 media: Ethernet autoselect (100baseTX ) status: active nobby:/etc# As you can see, dhclient seems to "get" the static lease but doesn't correctly bind to it in the latter case. Jonas ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ACPI problems with Dell laptops
Greg 'groggy' Lehey wrote: On Saturday, 26 November 2005 at 20:25:58 -0600, Eric Anderson wrote: Greg 'groggy' Lehey wrote: I've had both Dell and ThinkPad (no longer IBM). I prefer Dell, despite their attempts to convince me otherwise. However, we currently seem to have significant ACPI problems with Dell laptops. I'm writing this on an Inspiron 6000 running 7-CURRENT, but the same problems occur with 6.0: if I enable ACPI, timing goes to hell, and some things just time out. There was a similar message a couple of days ago from an owner of (I think) the latest Latitude machine, which sounded even worse. My requests for feedback about how to solve the problem have so far not been resolved. If you're otherwise tending towards Dell, I'd suggest you watch this space until there's some indication that the problems will be resolved. Which scheduler are you using? The standard (ULE). I don't think the problem's related to the scheduler: it shows all the signs of being an interrupt space problem. Fine - I'm just offering the parts that I recall working around it for me - if you are unwilling to at least try it, maybe someone else can and report back so we know if it is or isn't related. Also, have you tried disabling apic? I think you mean ACPI. This machine doesn't have an APIC. No, I meant apic. I realize it doesn't have one, but did you try disabling it? To answer the presumed question: Yes, as I said above, the problems only occur when I enable ACPI. Since then I've also discovered that the builtin wireless card doesn't work either. It's: iwi0: mem 0xdfcfd000-0xdfcfdfff irq 10 at device 3.0 on pci3 iwi0: Ethernet address: 00:13:ce:46:28:49 After downloading the firmware, I can set IP addresses and such, but I always get "no carrier": iwi0: flags=8802 mtu 1500 ether 00:13:ce:46:28:49 media: IEEE 802.11 Wireless Ethernet autoselect status: no carrier ssid "" channel 1 (2412) authmode OPEN privacy OFF deftxkey UNDEF powersavemode OFF powersavesleep 100 txpowmax 100 txpower 100 rtsthreshold 2346 fragthreshold 2346 -pureg protmode CTS -wme roaming AUTO bintval 0 When I run dhclient on the interface, I get: DHCPDISCOVER on iwi0 to 255.255.255.255 port 67 interval 6 DHCPDISCOVER on iwi0 to 255.255.255.255 port 67 interval 15 send_packet: Network is down On the console I get the detailed error message: iwi0: fatal error This machine also has Linux on it, and the card works fine with Linux, so it's obviously a FreeBSD-related problem. I also had problems with it. I ended up replacing it with a mini-pci atheros card. Eric -- Eric AndersonSr. Systems AdministratorCentaur Technology Anything that works is better than anything that doesn't. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
interesting nit
Just a generic 'heads-up', since this is an unsupported optimisation, and a question; compiling a kernel with '-march=pentium2' mostly works with the only observed problem being that something is amiss with the kernel PLL for NTP. The clock drifts beyond the bounds that NTPD will correct :-( Does this impact any other '-march' variants? Michael ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Stable Worldstones - Intel P4 vs AMD
Running -Stable make world with recent Intel and AMD hardware yielded some interesting results. One machine: CPU: AMD Athlon(tm) 64 Processor 3200+ (2010.31-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x20ff0 Stepping = 0 Other machine: CPU: Intel(R) Pentium(R) 4 CPU 3.60GHz (3600.12-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf34 Stepping = 4 The Intel machine had hyperthreading disabled in the bios. kernel config for both machines was GENERIC Running 'make world' several times on FreeBSD 6.0-STABLE from 11-26-05 a couple of representative timings were: AMD Athlon 64 45:42 45:19 Intel P4 55:22 54:57 Are there any optimizations for the P4 which might be added to the GENERIC kernel config to improve the performance ? -kim -- w8hdkim err gmail.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Handbook DHCPD needs update?
(This missive is going to both freebsd-stable and freebsd-doc.) Hi all, I just got done setting up my brand spankin' new FreeBSD 6 (release) server for DHCPD, and I found an ommision in the online handbook. I'm a newbie at FreeBSD but I'm pretty sure about this. In short, the handbook never mentions that one needs to add the following lines to /etc/rc.conf: dhcpd_enable="YES" dhcpd_ifaces="dc0" If one doesn't do that, the script that the handbook says to use to start dhcpd won't work, even if you do it manually as the handbook instructs: # /usr/local/etc/rc.d/isc-dhcpd.sh start This won't work. This script snarfs values out of /etc/rc.conf, and the default (in the script above) for dhcpd_enable is NO. Hence the script alone won't start anything. (When you check the handbook, make sure you scrolldown to section 24.5.7. The first part of the DHCP section explains how to set up the client (dhclient). That part does have the correct setup for /etc/rc.conf. Scroll down to the server section, dhcpd, to see what I'm talknin' about.) Anyhoo, what's the best way to fix this? I could submit a patch, but it might be faster for someone else. I've never submitted a patch to the documentation. Peace, out. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Stable Worldstones - Intel P4 vs AMD
Kim Culhan sat at his 'puter and typed on 11/28/2005 1:05: Running -Stable make world with recent Intel and AMD hardware yielded some interesting results. One machine: CPU: AMD Athlon(tm) 64 Processor 3200+ (2010.31-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x20ff0 Stepping = 0 Other machine: CPU: Intel(R) Pentium(R) 4 CPU 3.60GHz (3600.12-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf34 Stepping = 4 The Intel machine had hyperthreading disabled in the bios. kernel config for both machines was GENERIC Running 'make world' several times on FreeBSD 6.0-STABLE from 11-26-05 a couple of representative timings were: AMD Athlon 64 45:42 45:19 Intel P4 55:22 54:57 Are there any optimizations for the P4 which might be added to the GENERIC kernel config to improve the performance ? -kim -- w8hdkim err gmail.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]" Let us have a look at /etc/make.conf. BTW, my *personal* opinion is AMD implements much better pipelining and concurrent processing compared to the Intel platform. So what you see is not something entirely unexpected. Thanks S. -- --- \ / | Subhro Sankha Kar \./ | GSM: +919831010002 -- Fax: +919831832913 (0Y0) |MSN: [EMAIL PROTECTED] -- Yahoo!: subhro82 -ooO--(_)--Ooo- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Handbook DHCPD needs update?
On Sunday 27 November 2005 11:57, Mark Space wrote: > (This missive is going to both freebsd-stable and freebsd-doc.) > > Hi all, I just got done setting up my brand spankin' new FreeBSD 6 > (release) server for DHCPD, and I found an ommision in the online > handbook. I'm a newbie at FreeBSD but I'm pretty sure about this. > > In short, the handbook never mentions that one needs to add the > following lines to /etc/rc.conf: > > dhcpd_enable="YES" > dhcpd_ifaces="dc0" > > If one doesn't do that, the script that the handbook says to use to > start dhcpd won't work, even if you do it manually as the handbook > instructs: > > # /usr/local/etc/rc.d/isc-dhcpd.sh start > > > This won't work. This script snarfs values out of /etc/rc.conf, and > the default (in the script above) for dhcpd_enable is NO. Hence the > script alone won't start anything. (When you check the handbook, make > sure you scrolldown to section 24.5.7. The first part of the DHCP > section explains how to set up the client (dhclient). That part does > have the correct setup for /etc/rc.conf. Scroll down to the server > section, dhcpd, to see what I'm talknin' about.) > > Anyhoo, what's the best way to fix this? I could submit a patch, but it > might be faster for someone else. I've never submitted a patch to the > documentation. > > Peace, out. Might be better to post this in [EMAIL PROTECTED] -Mike ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
ata (raid) patches
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
For those game enough to try the results of my handiwork ;-), enclosed
is a patch against the files in /usr/src/sys/dev/ata for RELENG_6 (and
possibly others) with the following objectives:
1) the ata-raid driver currently leaks ata_composite and ata_request
structures into "neverland" in a mirrored configuration. This can be
observed using "sysctl -a | grep ^ata_" and noting the increasing
"in-use" count as time goes on. Eventually, this causes the kernel to
run out of memory. This is fixed by tracking the request counts on each
composite request.
2) another part of this patch is to ata-queue where a channel lock is
asserted in a (hopefully rare) rebuild process even if the dependencies
flag is set (we're waiting for a read). Moving the test for a dependency
outside of the lock saves waiting on it when nothing can be done. A
small nit with near negligible impact but, when you're waiting for a
rebuild ...
3) another part of this patch is to ata-raid where the choice of drive
from which to read favours one side of a mirror even when both drives
are near the block(s) we want. Because the mirror is on another channel
on the Highpoint controller, it performs (marginally :-() better when we
toggle between them.
As usual, this patch comes with no warranty ... it works for me. "If it
breaks your system, you own all the pieces".
I recommend you back up your system before testing,
Michael
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (MingW32)
iD8DBQFDihFsiJykeV6HPMURAlHQAJ9UO/vD8rp/V3+zh89qBBOPGQ+cugCg5qGp
9N8FaffInZMuOIMSGICV70c=
=NZTT
-END PGP SIGNATURE-
*** /usr/src/sys/dev/ata/ata-all.h.orig Sun Nov 27 14:17:57 2005
--- /usr/src/sys/dev/ata/ata-all.h Sun Nov 27 14:22:05 2005
***
*** 331,336
--- 331,337
u_int32_t wr_depend; /* write depends on subdisks
*/
u_int32_t wr_done;/* done write subdisks */
struct ata_request *request[32]; /* size must match maps above
*/
+ long count; /* count required of this
composite */
caddr_t data_1;
caddr_t data_2;
};
*** /usr/src/sys/dev/ata/ata-queue.c.orig Sun Nov 27 14:17:57 2005
--- /usr/src/sys/dev/ata/ata-queue.cSun Nov 27 14:40:43 2005
***
*** 182,209
}
/* check we are in the right state and has no dependencies */
! mtx_lock(&ch->state_mtx);
! if (ch->state == ATA_IDLE && !dependencies) {
! ATA_DEBUG_RQ(request, "starting");
! TAILQ_REMOVE(&ch->ata_queue, request, chain);
! ch->running = request;
! ch->state = ATA_ACTIVE;
!
! /* if we are the freezing point release it */
! if (ch->freezepoint == request)
! ch->freezepoint = NULL;
!
! if (ch->hw.begin_transaction(request) == ATA_OP_FINISHED) {
! ch->running = NULL;
! ch->state = ATA_IDLE;
! mtx_unlock(&ch->state_mtx);
! mtx_unlock(&ch->queue_mtx);
! ATA_LOCKING(dev, ATA_LF_UNLOCK);
! ata_finish(request);
! return;
}
}
- mtx_unlock(&ch->state_mtx);
}
}
mtx_unlock(&ch->queue_mtx);
--- 182,211
}
/* check we are in the right state and has no dependencies */
! if (!dependencies) {
! mtx_lock(&ch->state_mtx);
! if (ch->state == ATA_IDLE) {
! ATA_DEBUG_RQ(request, "starting");
! TAILQ_REMOVE(&ch->ata_queue, request, chain);
! ch->running = request;
! ch->state = ATA_ACTIVE;
!
! /* if we are the freezing point release it */
! if (ch->freezepoint == request)
! ch->freezepoint = NULL;
!
! if (ch->hw.begin_transaction(request) == ATA_OP_FINISHED) {
! ch->running = NULL;
! ch->state = ATA_IDLE;
! mtx_unlock(&ch->state_mtx);
! mtx_unlock(&ch->queue_mtx);
! ATA_LOCKING(dev, ATA_LF_UNLOCK);
! ata_finish(request);
! return;
! }
}
+ mtx_unlock(&ch->state_mtx);
}
}
}
mtx_unlock(&ch->queue_mtx);
***
*** 426,432
composite->wr_done |= (1 << request->this);
if (composite->wr_depend &&
! (composite->rd_done & composite->wr_depend)==composite->wr_depend &&
(composite->wr_needed & (~composite->wr_done))) {
index = ((composite->wr_needed & (~composite->wr_done))) - 1;
}
--- 428,434
Re: Stable Worldstones - Intel P4 vs AMD
On 11/27/05, Subhro <[EMAIL PROTECTED]> wrote: > Kim Culhan sat at his 'puter and typed on 11/28/2005 1:05: > > Running -Stable make world with recent Intel and AMD hardware > > yielded some interesting results. > Let us have a look at /etc/make.conf. BTW, my *personal* opinion is AMD > implements much better pipelining and concurrent processing compared to > the Intel platform. So what you see is not something entirely unexpected. No /etc/make.conf in either case -kim -- w8hdkim err gmail.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Stable Worldstones - Intel P4 vs AMD
On 11/27/05, Kim Culhan <[EMAIL PROTECTED]> wrote: > On 11/27/05, Subhro <[EMAIL PROTECTED]> wrote: > > Kim Culhan sat at his 'puter and typed on 11/28/2005 1:05: > > > > Running -Stable make world with recent Intel and AMD hardware > > > yielded some interesting results. > > > Let us have a look at /etc/make.conf. BTW, my *personal* opinion is AMD > > implements much better pipelining and concurrent processing compared to > > the Intel platform. So what you see is not something entirely unexpected. > > No /etc/make.conf in either case > > -kim Are you using the same disks, and disk controllers on each machine? building work+kernel does a fair amount of disk I/O, so that would be one thing to investigate. -p -- ~~o0OO0o~~ Pete Wright www.nycbug.org NYC's *BSD User Group ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Stable Worldstones - Intel P4 vs AMD
Kim Culhan sat at his 'puter and typed on 11/28/2005 1:40: On 11/27/05, Subhro <[EMAIL PROTECTED]> wrote: Kim Culhan sat at his 'puter and typed on 11/28/2005 1:05: Running -Stable make world with recent Intel and AMD hardware yielded some interesting results. Let us have a look at /etc/make.conf. BTW, my *personal* opinion is AMD implements much better pipelining and concurrent processing compared to the Intel platform. So what you see is not something entirely unexpected. No /etc/make.conf in either case -kim -- w8hdkim err gmail.com Have a look at man 'make.conf' without the 's. Specially look closely at the CFLAGS, COPTFLAGS and CPUTYPE variables. Also please be kind enough not to send in HTML mails in this list. It's really irritating to decipher mail content from within HTML tags for unlucky souls like me who use a text based mail client to read mails. Thanks S. -- --- \ / | Subhro Sankha Kar \./ | GSM: +919831010002 -- Fax: +919831832913 (0Y0) |MSN: [EMAIL PROTECTED] -- Yahoo!: subhro82 -ooO--(_)--Ooo- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: interesting nit
On Sun, Nov 27, 2005 at 01:39:42PM -0500, Michael Butler wrote: > Just a generic 'heads-up', since this is an unsupported optimisation, > and a question; compiling a kernel with '-march=pentium2' mostly works > with the only observed problem being that something is amiss with the > kernel PLL for NTP. The clock drifts beyond the bounds that NTPD will > correct :-( Does this impact any other '-march' variants? You forgot to mention any details about your FreeBSD version :-) Kris pgppFrBRh6KRs.pgp Description: PGP signature
Re: interesting nit
Kris Kennaway wrote: You forgot to mention any details about your FreeBSD version :-) Sorry - RELENG_6, Michael ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: NFS network load on 5.4-STABLE
On Sun, Nov 27, 2005 at 01:27:38AM -0800, Mike Eubanks wrote: > On Sat, 2005-11-26 at 21:49 -0500, Chuck Swiger wrote: > > Mike Eubanks wrote: > > > As soon as I mount my NFS file systems, the network load increases to a > > > constant 80%-90% of network bandwidth, even when the file systems are > > > not in use. NFS stats on the client machine (nfsstat -c) produce the > > > following: > > [ ... ] > > > Fsstat and Requests are increasing very rapidly. Both the client and > > > server are i386 5.4-STABLE machines. Is this behaviour normal? > > > > Sort of. Some fancy parts of X like file-manager/exporer applications tend > > to > > call fstat() a lot, but it's probably tunable, and if you enable NFS > > attribute > > caching that will help a lot. > > Thank you for the reply Chuck. It seems that it is something to do > with Gnome. I haven't done an upgrade to 2.12 yet, but the difference > did happen when I refreshed my user configuration to remove any stale > config files. Using the "top -mio" command I get the following: > > VCSW IVCSW READ WRITE FAULT TOTAL PERCENT COMMAND > 38 56 0 0 0 0 0.00% libgtop_server > 94 16 0 0 0 0 0.00% Xorg >4 0 0 0 0 0 0.00% top >0 0 0 0 0 0 0.00% mozilla-bin > 115 40 0 0 0 0 0.00% multiload-appl > 42 1 0 0 0 0 0.00% anjuta-bin >0 0 0 0 0 0 0.00% evolution-2.2 > 130 9 0 0 0 0 0.00% gnome-terminal > 15 10 0 0 0 0 0.00% clock-applet > 42 0 0 0 0 0 0.00% mixer_applet2 > 10 0 0 0 0 0 0.00% metacity >3 0 0 0 0 0 0.00% nautilus >4 0 0 0 0 0 0.00% wnck-applet That doesn't look like it is showing a problem to me. In particular it is indicating 0 I/O. > + file-manager/explorer? > | > client.220312819 > server.nfs: 96 fsstat [|nfs] > server.nfs > client.220312819: reply ok 168 fsstat POST: DIR 755 ids > 1001/0 [|nfs] > client.220312820 > server.nfs: 96 fsstat [|nfs] > server.nfs > client.220312820: reply ok 168 fsstat POST: DIR 755 ids > 1001/0 [|nfs] > client.220312821 > server.nfs: 96 fsstat [|nfs] > server.nfs > client.220312821: reply ok 168 fsstat POST: DIR 755 ids 0/0 > [|nfs] > client.220312822 > server.nfs: 96 fsstat [|nfs] > server.nfs > client.220312822: reply ok 168 fsstat POST: DIR 755 ids 0/0 > [|nfs] > client.220312823 > server.nfs: 96 fsstat [|nfs] > server.nfs > client.220312823: reply ok 168 fsstat POST: DIR 755 ids 0/0 > [|nfs] > > If this is enough evidence for the file-manager/explore, It's evidence that something is peforming NFS I/O, but it doesn't show what. Perhaps you needed to also use the top -S flag, or to sort the output by typing 'ototal'. > I'll just have > to accept it for now. I can't find anything about tuning them. As far > as attribute caching, do you mean the `-o ac*' options to mount_nfs? I > also noticed two sysctl values, although, I left them unmodified. > > vfs.nfs.access_cache_timeout: 2 > vfs.nfs4.access_cache_timeout: 60 Increase the former (you're not using nfs4). Try 60 seconds, for example. The downside is that you'll have to wait up to a minute for access changes on the server to be visible to the client, but that's usually not a big deal unless you're accessing a lot of dynamically created and destroyed files. Kris pgpYNDnhjEB5j.pgp Description: PGP signature
Re: ata (raid) patches
Michael Butler wrote: 1) the ata-raid driver currently leaks ata_composite and ata_request structures into "neverland" in a mirrored configuration. This can be observed using "sysctl -a | grep ^ata_" and noting the increasing "in-use" count as time goes on. Eventually, this causes the kernel to run out of memory. This is fixed by tracking the request counts on each composite request. Looks pretty much on the spot, I'll look this one over and get it committed once I'm satisfied with it fixing the bug, thanks a bunch for hunting this one down ! 2) another part of this patch is to ata-queue where a channel lock is asserted in a (hopefully rare) rebuild process even if the dependencies flag is set (we're waiting for a read). Moving the test for a dependency outside of the lock saves waiting on it when nothing can be done. A small nit with near negligible impact but, when you're waiting for a rebuild ... I dont think you can measure this actually, but it doesn't hurt at least to move the lock outside. 3) another part of this patch is to ata-raid where the choice of drive from which to read favours one side of a mirror even when both drives are near the block(s) we want. Because the mirror is on another channel on the Highpoint controller, it performs (marginally :-() better when we toggle between them. Hmm, well, depends on what sort of behavior one wants to optimise for. I have a few other patches for optimisations but havn't decided what to eventually use yet. Guess its time for me to run some tests on this.. I'll look into get this integrated, again thanks for digging in and doing the hard work of finding the problem(s) !! -Søren ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ata (raid) patches
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Søren Schmidt wrote: |> 3) another part of this patch is to ata-raid where the choice of drive |> from which to read favours one side of a mirror even when both drives |> are near the block(s) we want. Because the mirror is on another channel |> on the Highpoint controller, it performs (marginally :-() better when we |> toggle between them. | | | Hmm, well, depends on what sort of behavior one wants to optimise for. I | have a few other patches for optimisations but havn't decided what to | eventually use yet. Guess its time for me to run some tests on this.. On further investigation, I'd failed to notice (doh!) that rdp->toggle isn't preserved between requests and that one unobvious side-effect of the original code is that it does slightly better than my patched version .. . I'll rework this and see if I can make it do better, Michael -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) iD8DBQFDijcSiJykeV6HPMURAiRkAJ4omvpWlXhsJn+B17jZiyCwCl58DgCdFXJJ EndsDJBOOn/m3Dl5fQkMziA= =6dn0 -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]"
Freebsd 5.3 screw up.... deleted /lib/libc.so.5
After I deleted this very valuable file I realized what I did. Since I don't have a old boot disk laying around is my only option to upgrade to a newer version of freebsd? ___ 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.3 screw up.... deleted /lib/libc.so.5
On Sunday 27 November 2005 16:42, ebm wrote: > After I deleted this very valuable file I realized what I did. Since I > don't have a old boot disk laying around is my only option to upgrade to > a newer version of freebsd? Try this: cd /usr/sbin ./sysinstall then install the minimal binary package afterwords to a cvsup/make buildworld to get current again -Mike ___ 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.3 screw up.... deleted /lib/libc.so.5
On 11/27/05, ebm <[EMAIL PROTECTED]> wrote: > After I deleted this very valuable file I realized what I did. Since I > don't have a old boot disk laying around is my only option to upgrade to > a newer version of freebsd? Unfortunately after FreeBSD 4 all of the binaries needed to boot are dynamically linked, so you are not going to be able to reboot the server, and you're not going to want to log out. There is still hope however -- the /rescue directory contains a statically linked binary and a whole bunch of hardlinks, including 'mount' and 'cp'. If you can get libc.so.5 onto a floppy somewhere else you may be able to copy it into place with these utilities. http://dpk.net/libc.so.5 That's a copy of libc from a FreeBSD 5.3-RELEASE-p5 system. Alternately, you could try installing the minimum binary package as suggested by Michael (however you'll need to use /stand/sysinstall since it is static) ___ 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.3 screw up.... deleted /lib/libc.so.5
On Sun, Nov 27, 2005 at 05:29:36PM -0800 I heard the voice of David Kirchner, and lo! it spake thus: > > There is still hope however -- the /rescue directory contains a > statically linked binary and a whole bunch of hardlinks, including > 'mount' and 'cp'. If you can get libc.so.5 onto a floppy somewhere > else you may be able to copy it into place with these utilities. Note that it also has mount_nfs and rcp, so if you've got another box handy 'nearby', you can get creative like that. -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: NFS network load on 5.4-STABLE
On Sun, 2005-11-27 at 15:43 -0500, Kris Kennaway wrote: > On Sun, Nov 27, 2005 at 01:27:38AM -0800, Mike Eubanks wrote: > > On Sat, 2005-11-26 at 21:49 -0500, Chuck Swiger wrote: > > > Mike Eubanks wrote: > > > > As soon as I mount my NFS file systems, the network load > > > > increases to a constant 80%-90% of network bandwidth, even > > > > when the file systems are not in use. NFS stats on the client > > > > machine (nfsstat -c) produce the following: > > > > > > > [ ... ] > > > > Fsstat and Requests are increasing very rapidly. Both the client and > > > > server are i386 5.4-STABLE machines. Is this behaviour normal? > > > > > > Sort of. Some fancy parts of X like file-manager/exporer > > > applications tend to call fstat() a lot, but it's probably > > > tunable, and if you enable NFS attribute caching that will > > > help a lot. > > > > Thank you for the reply Chuck. It seems that it is something to do > > with Gnome. I haven't done an upgrade to 2.12 yet, but the difference > > did happen when I refreshed my user configuration to remove any stale > > config files. Using the "top -mio" command I get the following: > > > > [ ... ] > > > > That doesn't look like it is showing a problem to me. In particular > it is indicating 0 I/O. > > > + file-manager/explorer? > > | > > client.220312819 > server.nfs: 96 fsstat [|nfs] > > server.nfs > client.220312819: reply ok 168 fsstat POST: DIR 755 ids > > 1001/0 [|nfs] > > > > If this is enough evidence for the file-manager/explore, > > It's evidence that something is peforming NFS I/O, but it doesn't show > what. Perhaps you needed to also use the top -S flag, or to sort the > output by typing 'ototal'. > > > I'll just have > > to accept it for now. I can't find anything about tuning them. As far > > as attribute caching, do you mean the `-o ac*' options to mount_nfs? I > > also noticed two sysctl values, although, I left them unmodified. > > > > vfs.nfs.access_cache_timeout: 2 > > vfs.nfs4.access_cache_timeout: 60 > > Increase the former (you're not using nfs4). Try 60 seconds, for > example. The downside is that you'll have to wait up to a minute for > access changes on the server to be visible to the client, but that's > usually not a big deal unless you're accessing a lot of dynamically > created and destroyed files. > I made the sysctl modification. Still no luck though. The only process that had any activity using the top with the -S option, or after sorting by total, was the swapper/syncer. Even then, it was hardly active. The network traffic persists. -- Mike Eubanks <[EMAIL PROTECTED]> ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
recomendations please for new freebsd development system
Hi Like the title.. I need to build a new systemsupporting a substantial mysql database application for a development team and also able to provide: 1. fast as possible compile times 2. raid 6 support with 6-10 terabytes of data storage 3. 1 terabyte fast data storage 4. 8G or more of ram 5. excellent graphics performance and capabilities with high quality sound/video supporting dual high resolution monitors and surround sound. 6. Back up facilities for 6-10 terabytes. Would anyone be so bold as to make some recommendations for a reliable motherboard/processor combination on the assumption that this is to be a dual processor system running freebsd 6.0 Thanks in advance david ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
