Re: Performance!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, Results with lock_manager and select patches and kern.hz=100 #threads#transactions/sec 1 582 5 2083 10 2030 20 2421 40 1739 60 1409 80 1124 100 1034 This is with the BETA4. May be I should upgrade to RC1? I will collect lock profiling statistics again. Best Regards Kris Kennaway wrote: Kris Kennaway wrote: Krassimir Slavchev wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello Kris, Here is the lock profiling results, see the attachment. Please, let me know if you want ssh access to this machine? Thanks, this is very interesting. The problem is already fixed in 8.0 but we were not seeing it being this much of a factor on our test hardware. Possibly it is due to your CPUs being moderately faster and causing a timing difference. Anyway, try this patch. If there is still a performance deficit then repeating the lock profiling will be useful. Kris Now with actual patch. Kris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFHhKCcxJBWvpalMpkRAi4WAJ4/lbXTq/7/rGnURw5DMICRqKnFvQCeJKWc KxGflXbc3KfvyuyTRVzStEk= =aBqO -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]
amd64 FreeBSD 7.0 RC1 live cd gmirror options
Hello all I always use the live cd to create my gmirrors with the following commands Start live cd -- fixit cdrom Livecd Then chroot /dist mount -t devfs devfs /dev gmirror load gmirror label -v -b round-robin gm0 /dev/ad0 But on the amd64 live cd I get the following error gmirror unknown command : label Usage :gmirror help gmirror list gmirror status gmirror load gmirror unload it looks like I miss a lot of gmirror options. Am I doing something wrong ? Regards, Johan Hendriks ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: amd64 FreeBSD 7.0 RC1 live cd gmirror options
Johan Hendriks wrote: it looks like I miss a lot of gmirror options. Am I doing something wrong ? Find and symlink the directory with GEOM userland libraries to /lib/geom before using it. The directory should contain geom_mirror.so and other files. OTOH, I though that a fixed for that was committed prior to RC1? signature.asc Description: OpenPGP digital signature
Re: Performance!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, Kris Kennaway wrote: Krassimir Slavchev wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, Here are lock profiling results with select patch applied. OK, you are doing I/O over TCP. Are you sure you are using TCP on both systems? Linux may not be defaulting to TCP transport for local queries. Add --pgsql-host= to your sysbench command line to make it communicate over a local domain socket, which is much more efficient. Kris Hmm, Yes linux uses local domain sockets! Here are results using local domain sockets on FreeBSD too: #threads#tranzactions/sec 1 728 5 2996 10 5301 20 3931 40 2466 60 1852 80 1424 100 1216 Just to remember: Linux (2.6.18) #threads#transactions/sec 1 693 5 3539 10 5789 20 5791 40 5661 60 5517 80 5401 100 5319 I have results using Fedora 8 on the same hardware: Linux (2.6.23) #threads#transactions/sec 1 740 5 2675 10 6486 20 6893 40 6623 60 6623 80 6522 100 6417 If we look at the results with up to 10 threads the performance of FreeBSD is very good. May be something can be tuned for number of threads number of CPUs? Are you interested in lock profiling statistics with more threads than the number of CPUs? Best Regards -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFHhMCxxJBWvpalMpkRAvuFAJ4+ab5o4DoLZXrJ3hrr6vbJG9veTgCfdjn5 d8kf8v17QhiYSn20yDgWl3E= =Tsub -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]
Re: 6.3-PRERELEASE desktop system periodically freezes momentarily
Kris Kennaway wrote: OK, you may need to set up hwpmc or LOCK_PROFILING to figure out what your system is doing at that moment. While experimenting with pmcstat I found that my problem seems to be mouse-related. I did several tests - booted, logged in with xdm, started an xterm and left 'pmcstat -S instructions' running in xterm to see where it freezes. As long as I don't touch the mouse, pmcstat output keeps scrolling by at high speed. I can wait several minutes and it just keeps scrolling. But when I start moving the mouse, soon (probably 10-20 cm of mouse movement, but I haven't done any real measurements ;) ) there is this hiccup. As I said earlier, this happens only once during the session. The same test can be done outside X, on the text console, and the behaviour is identical. I tried with two generic 2-buttons-and-a-wheel PS/2 mice and the results are identical. I don't have any USB mice at hand immediately. # grep mouse /etc/rc.conf: moused_enable=YES # grep psm /var/run/dmesg.boot psm0: PS/2 Mouse irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model IntelliMouse, device ID 3 At that point it seems that faulty hardware can't be ruled out (dying mouse port on the motherboard?). But it seems a bit strange that the problem appears exactly once during the session. I'll try with USB mouse tomorrow. -- Toomas Aas ... Enter any 11-digit prime number to continue. ___ 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 desktop system periodically freezes momentarily
Toomas Aas wrote: Kris Kennaway wrote: OK, you may need to set up hwpmc or LOCK_PROFILING to figure out what your system is doing at that moment. While experimenting with pmcstat I found that my problem seems to be mouse-related. I did several tests - booted, logged in with xdm, started an xterm and left 'pmcstat -S instructions' running in xterm to see where it freezes. As long as I don't touch the mouse, pmcstat output keeps scrolling by at high speed. I can wait several minutes and it just keeps scrolling. But when I start moving the mouse, soon (probably 10-20 cm of mouse movement, but I haven't done any real measurements ;) ) there is this hiccup. As I said earlier, this happens only once during the session. The same test can be done outside X, on the text console, and the behaviour is identical. I tried with two generic 2-buttons-and-a-wheel PS/2 mice and the results are identical. I don't have any USB mice at hand immediately. # grep mouse /etc/rc.conf: moused_enable=YES # grep psm /var/run/dmesg.boot psm0: PS/2 Mouse irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model IntelliMouse, device ID 3 At that point it seems that faulty hardware can't be ruled out (dying mouse port on the motherboard?). But it seems a bit strange that the problem appears exactly once during the session. I'll try with USB mouse tomorrow. -- Toomas Aas ... Enter any 11-digit prime number to continue. There was another report of problems with psm. Can you try with sysmouse instead? If that works around the issue then we can investigate psm further. Kris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Performance!
Krassimir Slavchev wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, Kris Kennaway wrote: Krassimir Slavchev wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, Here are lock profiling results with select patch applied. OK, you are doing I/O over TCP. Are you sure you are using TCP on both systems? Linux may not be defaulting to TCP transport for local queries. Add --pgsql-host= to your sysbench command line to make it communicate over a local domain socket, which is much more efficient. Kris Hmm, Yes linux uses local domain sockets! Here are results using local domain sockets on FreeBSD too: #threads#tranzactions/sec 1 728 5 2996 10 5301 20 3931 40 2466 60 1852 80 1424 100 1216 Just to remember: Linux (2.6.18) #threads#transactions/sec 1 693 5 3539 10 5789 20 5791 40 5661 60 5517 80 5401 100 5319 I have results using Fedora 8 on the same hardware: Linux (2.6.23) #threads#transactions/sec 1 740 5 2675 10 6486 20 6893 40 6623 60 6623 80 6522 100 6417 If we look at the results with up to 10 threads the performance of FreeBSD is very good. May be something can be tuned for number of threads number of CPUs? Are you interested in lock profiling statistics with more threads than the number of CPUs? Yes, it's still performing anomalously. Glad we're making progress though :) Kris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 7.0BETA4 desktop system also periodically freezes
I believe this same problem may also be present on 7.0, at least on the BETA releases; BETA4 is the latest I have here. I have the same problem on two systems here: periodically the systems will stop dead (no mouse action, no ping responses from other systems, processes with windows on the screen also freeze); the hangs can be anything from a few seconds to several MINUTES; then it all comes back as if nothing happened except that keyboard input during the freeze is lost. Most of my freezes are a few seconds long, some are in the 15-60 second range, but (fortunately, rarely) I have seen some that lasted 10-15 MINUTES! The only obvious indication after the return is that the system load average monitor peaks up, typically from the 0-0.5 range before the hang to 1.5-2 after the hang, then immediately decays back down. Just as if some real-time prio process had grabbed the processor exclusively for a while. Except I have no rtprio processes that I know of. It is not swap related. One of the systems here has 4GB ram and is not swapping, even after one of these freezes. It doesn't even swap while running X, with the mailer open, several xterms and firefox and a make running. I had not reported this because I figured this was yet another problem with xorg-7.3. I am unable to make it happen on demand. As yet it seems random. I am able to do CPU-intensive stuff (e.g., port builds) without problems: it doesn't trigger the freeze and I don't even see the jerky mouse problem that folk also talk of. I am running a make right now in fact, just to see if it'll do it. Of course, it's fine. But the phone might ring, so I'll stop doing things, the system will become pretty-much idle, then I'll go to move the mouse and it might be frozen. When it comes back, the small load peak shows, but top and ps show nothing unusual. As I said, I have two systems here which exhibit this. Both systems here are 7.0BETA4. Different i386 hardware; both are UP systems; one is a fast 3200Ghz processor with 4GB ram, the other is a very slow processor with not much ram at all; the scheduler is SCHED_ULE on both; and the app mix includes basic servers: /usr/sbin/wpa_supplicant dhclient /sbin/devd /usr/sbin/syslogd /usr/local/sbin/cupsd /usr/sbin/ntpd /usr/sbin/powerd /usr/sbin/sshd sendmail /usr/sbin/cron /usr/sbin/moused /usr/local/bin/xdm (on the fast system only) /usr/local/bin/X and various end-user clients such as a WM and its children (including load graph and a clock), firefox, xterms, ical, nvi, etc. Because it is unpredictable, I don't have any profiling of this for you. But I wanted to throw this out there since I am not sure the problem is 6.x-related. Oh, both systems ran 6.2-stable with xorg-6.9 and didn't have this problem. Also, there doesn't seem to be any indication of hardware issues on either. -jr signature.asc Description: PGP signature
Re: [OT] overheating Thinkpad X60s with 7.0-RC1
Hello, half offtopic: concerning the BIOS update: On 1/8/08, Nathan Lay [EMAIL PROTECTED] wrote: If you can, use DR-DOS (Caldera's DOS). Not to rag on FreeDOS or anything, but I've had bad experiences with FreeDOS and BIOS updates. http://www.drdosprojects.de/ Best Regards, Nathan Lay thanks for the link but after checking the release notes a little bit on the lenovo page for the BIOS update two things are remarkable: 1) They nowadays have a bootable CD version (most likely most people here knew already) which enables you in theory to update without a Windows. BUT 2) That is just working with an IBM CD-drive sitting in the Thinkpads Ultrabay, explicitly NOT (at least that is what it says) with an IBM docking station. Can someone here explain me the sense of having such a thing for the X-series then? On top 2*) You are not allowed to have any USB drives connected to your Thinkpad whilst updating. Wonderful, or? Bye, Johannes ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 7.0BETA4 desktop system also periodically freezes
J.R. Oldroyd wrote: I believe this same problem may also be present on 7.0, at least on the BETA releases; BETA4 is the latest I have here. I have the same problem on two systems here: periodically the systems will stop dead (no mouse action, no ping responses from other systems, processes with windows on the screen also freeze); the hangs can be anything from a few seconds to several MINUTES; then it all comes back as if nothing happened except that keyboard input during the freeze is lost. Most of my freezes are a few seconds long, some are in the 15-60 second range, but (fortunately, rarely) I have seen some that lasted 10-15 MINUTES! The only obvious indication after the return is that the system load average monitor peaks up, typically from the 0-0.5 range before the hang to 1.5-2 after the hang, then immediately decays back down. Just as if some real-time prio process had grabbed the processor exclusively for a while. Except I have no rtprio processes that I know of. It is not swap related. One of the systems here has 4GB ram and is not swapping, even after one of these freezes. It doesn't even swap while running X, with the mailer open, several xterms and firefox and a make running. I had not reported this because I figured this was yet another problem with xorg-7.3. I am unable to make it happen on demand. As yet it seems random. I am able to do CPU-intensive stuff (e.g., port builds) without problems: it doesn't trigger the freeze and I don't even see the jerky mouse problem that folk also talk of. I am running a make right now in fact, just to see if it'll do it. Of course, it's fine. But the phone might ring, so I'll stop doing things, the system will become pretty-much idle, then I'll go to move the mouse and it might be frozen. When it comes back, the small load peak shows, but top and ps show nothing unusual. As I said, I have two systems here which exhibit this. Both systems here are 7.0BETA4. Different i386 hardware; both are UP systems; one is a fast 3200Ghz processor with 4GB ram, the other is a very slow processor with not much ram at all; the scheduler is SCHED_ULE on both; and the app mix includes basic servers: /usr/sbin/wpa_supplicant dhclient /sbin/devd /usr/sbin/syslogd /usr/local/sbin/cupsd /usr/sbin/ntpd /usr/sbin/powerd /usr/sbin/sshd sendmail /usr/sbin/cron /usr/sbin/moused /usr/local/bin/xdm (on the fast system only) /usr/local/bin/X and various end-user clients such as a WM and its children (including load graph and a clock), firefox, xterms, ical, nvi, etc. Because it is unpredictable, I don't have any profiling of this for you. But I wanted to throw this out there since I am not sure the problem is 6.x-related. Oh, both systems ran 6.2-stable with xorg-6.9 and didn't have this problem. Also, there doesn't seem to be any indication of hardware issues on either. -jr OK, same requests as to the others then. Kris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 7.0BETA4 desktop system also periodically freezes
On Wed, Jan 09, 2008 at 02:18:59PM -0500, J.R. Oldroyd wrote: [...] As I said, I have two systems here which exhibit this. Both systems here are 7.0BETA4. Different i386 hardware; both are UP systems; one is a fast 3200Ghz processor with 4GB ram, the other is a very slow processor with not much ram at all; the scheduler is SCHED_ULE on both; and the app mix includes basic servers: /usr/sbin/wpa_supplicant dhclient /sbin/devd /usr/sbin/syslogd /usr/local/sbin/cupsd /usr/sbin/ntpd /usr/sbin/powerd /usr/sbin/sshd sendmail /usr/sbin/cron /usr/sbin/moused /usr/local/bin/xdm (on the fast system only) /usr/local/bin/X and various end-user clients such as a WM and its children (including load graph and a clock), firefox, xterms, ical, nvi, etc. I can only add that I see the same problem, with 7.0-PRERELEASE on a i386/SMP running SCHED_4BSD. However, for me the problem seems to manifest itself if I have installed graphics/gnash's flash web-browser plugin for firefox; it doesn't seem to happen since I've taken it off (so far). My wild-eyed guess is that it's related to threading, as there's quite a few [gtk-gnash] processes on some flash-enabled sites. Cheers. -- Jonathan Chen [EMAIL PROTECTED] -- A person should be able to do a small bit of everything, specialisation is for insects ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [OT] overheating Thinkpad X60s with 7.0-RC1
http://www.thinkwiki.org/wiki/BIOS_Upgrade/X_Series looks as if it could be valuable... Sorry for disturbing. On 1/9/08, Johannes Dieterich [EMAIL PROTECTED] wrote: Hello, half offtopic: concerning the BIOS update: On 1/8/08, Nathan Lay [EMAIL PROTECTED] wrote: If you can, use DR-DOS (Caldera's DOS). Not to rag on FreeDOS or anything, but I've had bad experiences with FreeDOS and BIOS updates. http://www.drdosprojects.de/ Best Regards, Nathan Lay thanks for the link but after checking the release notes a little bit on the lenovo page for the BIOS update two things are remarkable: 1) They nowadays have a bootable CD version (most likely most people here knew already) which enables you in theory to update without a Windows. BUT 2) That is just working with an IBM CD-drive sitting in the Thinkpads Ultrabay, explicitly NOT (at least that is what it says) with an IBM docking station. Can someone here explain me the sense of having such a thing for the X-series then? On top 2*) You are not allowed to have any USB drives connected to your Thinkpad whilst updating. Wonderful, or? Bye, Johannes ___ 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 desktop system periodically freezes momentarily
Kris Kennaway wrote: Toomas Aas wrote: # grep psm /var/run/dmesg.boot psm0: PS/2 Mouse irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model IntelliMouse, device ID 3 There was another report of problems with psm. Can you try with sysmouse instead? If that works around the issue then we can investigate psm further. Sorry, but I'm not sure I understand how to use sysmouse instead of psm. Do you mean I should run 'moused -p /dev/sysmouse' (setting moused_port=/dev/sysmouse in rc.conf)? If I do that, the mouse refuses to move. When I add more options: #/usr/sbin/moused -p /dev/sysmouse -t ps/2 -d -f moused: mouse type mismatch (mousesystems != ps/2, mousesystems is assumed) moused: proto params: f8 80 00 00 5 00 ff moused: port: /dev/sysmouse interface: sysmouse type: mousesystems model: generic moused: received char 0x87 moused: received char 0x0 moused: received char 0x0 moused: received char 0x0 moused: received char 0x0 moused: assembled full packet (len 5) 87,0,0,0,0,0,0,0 -- Toomas Aas ... Why is it called tourist season if we can't shoot at them? ___ 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 desktop system periodically freezes momentarily
Toomas Aas wrote: Kris Kennaway wrote: Toomas Aas wrote: # grep psm /var/run/dmesg.boot psm0: PS/2 Mouse irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model IntelliMouse, device ID 3 There was another report of problems with psm. Can you try with sysmouse instead? If that works around the issue then we can investigate psm further. Sorry, but I'm not sure I understand how to use sysmouse instead of psm. Do you mean I should run 'moused -p /dev/sysmouse' (setting moused_port=/dev/sysmouse in rc.conf)? If I do that, the mouse refuses to move. When I add more options: #/usr/sbin/moused -p /dev/sysmouse -t ps/2 -d -f moused: mouse type mismatch (mousesystems != ps/2, mousesystems is assumed) moused: proto params: f8 80 00 00 5 00 ff moused: port: /dev/sysmouse interface: sysmouse type: mousesystems model: generic moused: received char 0x87 moused: received char 0x0 moused: received char 0x0 moused: received char 0x0 moused: received char 0x0 moused: assembled full packet (len 5) 87,0,0,0,0,0,0,0 -- Toomas Aas ... Why is it called tourist season if we can't shoot at them? I mean use /dev/sysmouse in X instead of /dev/psm0 directly. I don't know why this would help but someone else said it did. Kris ___ 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 desktop system periodically freezes momentarily
Toomas Aas wrote: Kris Kennaway wrote: I mean use /dev/sysmouse in X instead of /dev/psm0 directly. That's how my xorg has always been configured: Section InputDevice Identifier Mouse0 Driver mouse Option Protocol auto Option Device /dev/sysmouse Option ZAxisMapping 4 5 6 7 EndSection -- Toomas Aas ... War doesn't determine who's right. War determines who's left. OK. Can you obtain a lock profiling dump? I suspect psm may be fighting with the syncer or something. Kris ___ 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 desktop system periodically freezes momentarily
Kris Kennaway wrote: I mean use /dev/sysmouse in X instead of /dev/psm0 directly. That's how my xorg has always been configured: Section InputDevice Identifier Mouse0 Driver mouse Option Protocol auto Option Device /dev/sysmouse Option ZAxisMapping 4 5 6 7 EndSection -- Toomas Aas ... War doesn't determine who's right. War determines who's left. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: What current Dell Systems are supported/work
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Richard Bates wrote: Sorry for the repost... I don't think the first one posted.. posted to freebsd.stable, freebsd-current, Freebsd-hardware I checked the hardware in the online documentation manual/hardware It only lists the bits and peices of the machine say the hard drive controller and so forth. but doesn't give you a particular system to look at as a working machine with FreeBSD 6.2 does anybody know if a Dell PowerEdge 1950 • Quad-Core Intel Xeon Processors 5400 series 3.16GHz • 4GB Ram I am looking to attach 2 machines to a SAN to make a constantly up system. Is there a Dell San and San Switch that will work with this version of BSD? Thank you for your help It has been observed that there is some interrupt related issue with certain models of Dell PowerEdge 1950/2950 on 6.2-RELEASE, to be more specific, those which are configured without a RAID controller. The symptom is that server will hang on boot after detected acd0, but this is not reliably reproducible. At our company (we deploy hundreds of 1950/2950 online during last year), our important local changes that is made for these boxes include: - backport my bce(4) changes from RELENG_6. - backport MSI support, and enable by default. (*) *: This is the default behavior for 7.0, I have not encountered the problem mentioned above on any 1950/2950 boxes so far I have tested. That's said, I would recommend that you deploy 6.3-RELEASE (with proper loader.conf configuration to enable MSI) or 7.0-RELEASE once they are out of the door. I do not have much experience with SAN devices you have mentioned, though, so perhaps it's better to listen someone else's suggestions. Cheers, - -- Xin LI [EMAIL PROTECTED] http://www.delphij.net/ FreeBSD - The Power to Serve! -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (FreeBSD) iD4DBQFHhWFpi+vbBBjt66ARAhaLAJdYQHtgCsXYYdgPvWOh0QiLARWmAKCU2sH5 9PLlYsSESqvoMHCekHtJfw== =xIhB -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]
Re: Cannot mount a nfs share after doing a snapshot
Julian H. Stacey wrote: I too saw mountd / exports just fail on 2 systems upgraded in last days from 7RC4 to newest 7 Stable (CTM src-7 80, received here Jan 6 15:15 CEST=GMT+01:00). I am not using .snap snapshot. My other AMD NFS on other FreeBSD-4 6 hosts remains OK. AMD NFS as client server was working till then. I just upgraded src/ rebooted exports failed. messages: mountd[563]: can't change attributes for / mountd[563]: bad exports list line / host1 host2 host3 named seems to resolve hosts OK though. (my usual first suspect :-) su; mount_nfs lapd:/usr /mnt [udp] lapd:/usr: Permission denied Maybe changed hosts/pam/ssh/inetd type root auth defaults between RC4 now ? My mistake. Fixed here by running mergemaster -sicvP removing ::1 from my /etc/hosts to avoid IPV6. -- Julian Stacey. Munich Computer Consultant, BSD Unix C Linux. http://berklix.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 7.0BETA4 desktop system also periodically freezes
On Wed, 09 Jan 2008 20:38:29 +0100, Kris Kennaway [EMAIL PROTECTED] wrote: OK, same requests as to the others then. I presume you mean hwpmc... In setting that up, I may have stumbled upon a possible cause. I ran pmcstat for a while and ended up with a very large output file. Having not noticed any freezes during that time, I decided to start over with the output to a different filesystem with more free space. When I removed that first output file, the resulting disk i/o for the block deallocation caused a very similar freeze for a few seconds. And when it came back, the load average graph peaked up, just as before. This appears to be repeatable: 1. create a very large file, say 1Gb or so 2. remove it 3. observe freeze during file dealloc i/o activity This on an ata drive, ufs filesystem with softupdates. Folk complaining of jerky mouse syndrome (e.g., during compilations) may be seeing the same - the compiler creates and removes lots of files. I'm not sure how this would explain those longer freezes (30s or several minutes) though. -jr signature.asc Description: PGP signature
Re: 7.0BETA4 desktop system also periodically freezes
On Wed, Jan 09, 2008 at 11:58:19PM -0500, J.R. Oldroyd wrote:
On Wed, 09 Jan 2008 20:38:29 +0100, Kris Kennaway [EMAIL PROTECTED] wrote:
OK, same requests as to the others then.
I presume you mean hwpmc...
In setting that up, I may have stumbled upon a possible cause.
I ran pmcstat for a while and ended up with a very large output
file. Having not noticed any freezes during that time, I decided
to start over with the output to a different filesystem with more
free space. When I removed that first output file, the resulting
disk i/o for the block deallocation caused a very similar freeze
for a few seconds. And when it came back, the load average graph
peaked up, just as before.
This appears to be repeatable:
1. create a very large file, say 1Gb or so
2. remove it
3. observe freeze during file dealloc i/o activity
This on an ata drive, ufs filesystem with softupdates.
Folk complaining of jerky mouse syndrome (e.g., during compilations)
may be seeing the same - the compiler creates and removes lots of
files.
I'm not sure how this would explain those longer freezes (30s or
several minutes) though.
For the SU-imposed jerkiness, try the patch below. Progress on developing
the change stalled somehow, and I would like to process with it.
diff --git a/sys/kern/vfs_mount.c b/sys/kern/vfs_mount.c
index 248ce22..005f915 100644
--- a/sys/kern/vfs_mount.c
+++ b/sys/kern/vfs_mount.c
@@ -2001,6 +2001,12 @@ __mnt_vnode_next(struct vnode **mvp, struct mount *mp)
mtx_assert(MNT_MTX(mp), MA_OWNED);
KASSERT((*mvp)-v_mount == mp, (marker vnode mount list mismatch));
+ if ((*mvp)-v_yield++ == 500) {
+ MNT_IUNLOCK(mp);
+ (*mvp)-v_yield = 0;
+ uio_yield();
+ MNT_ILOCK(mp);
+ }
vp = TAILQ_NEXT(*mvp, v_nmntvnodes);
while (vp != NULL vp-v_type == VMARKER)
vp = TAILQ_NEXT(vp, v_nmntvnodes);
diff --git a/sys/sys/vnode.h b/sys/sys/vnode.h
index 0525a43..1ac289a 100644
--- a/sys/sys/vnode.h
+++ b/sys/sys/vnode.h
@@ -131,6 +131,7 @@ struct vnode {
struct socket *vu_socket; /* v unix domain net (VSOCK) */
struct cdev *vu_cdev; /* v device (VCHR, VBLK) */
struct fifoinfo *vu_fifoinfo; /* v fifo (VFIFO) */
+ int vu_yield; /* yield count (VMARKER) */
} v_un;
/*
@@ -185,6 +186,7 @@ struct vnode {
#definev_socketv_un.vu_socket
#definev_rdev v_un.vu_cdev
#definev_fifoinfo v_un.vu_fifoinfo
+#definev_yield v_un.vu_yield
/* XXX: These are temporary to avoid a source sweep at this time */
#define v_object v_bufobj.bo_object
diff --git a/sys/ufs/ffs/ffs_softdep.c b/sys/ufs/ffs/ffs_softdep.c
index a221b66..02cf45b 100644
--- a/sys/ufs/ffs/ffs_softdep.c
+++ b/sys/ufs/ffs/ffs_softdep.c
@@ -864,6 +864,7 @@ softdep_process_worklist(mp, full)
*/
if (loopcount++ % 128 == 0) {
FREE_LOCK(lk);
+ uio_yield();
bwillwrite();
ACQUIRE_LOCK(lk);
}
pgpqUR9LGKIpo.pgp
Description: PGP signature
Re: 7.0BETA4 desktop system also periodically freezes
J.R. Oldroyd wrote: On Wed, 09 Jan 2008 20:38:29 +0100, Kris Kennaway [EMAIL PROTECTED] wrote: OK, same requests as to the others then. I presume you mean hwpmc... LOCK_PROFILING, sched_graph, hwpmc. In setting that up, I may have stumbled upon a possible cause. I ran pmcstat for a while and ended up with a very large output file. Having not noticed any freezes during that time, I decided to start over with the output to a different filesystem with more free space. When I removed that first output file, the resulting disk i/o for the block deallocation caused a very similar freeze for a few seconds. And when it came back, the load average graph peaked up, just as before. This appears to be repeatable: 1. create a very large file, say 1Gb or so 2. remove it 3. observe freeze during file dealloc i/o activity This on an ata drive, ufs filesystem with softupdates. Folk complaining of jerky mouse syndrome (e.g., during compilations) may be seeing the same - the compiler creates and removes lots of files. Yeah, this fits with my kib's hypothesis. I'm not sure how this would explain those longer freezes (30s or several minutes) though. No idea, sans data. Kris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
