Re: misc/179033: [dc] dc ethernet driver seems to have issues with some multiport card and mother board combinations
Old Synopsis: DC ethernet driver seems to have issues with some multiport card and mother board combinations New Synopsis: [dc] dc ethernet driver seems to have issues with some multiport card and mother board combinations Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Tue May 28 08:37:36 UTC 2013 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=179033 ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: kern/178997: Heavy disk I/O may hang system
On Mon, 27 May 2013, Klaus Weber wrote: On Mon, May 27, 2013 at 03:57:56PM +1000, Bruce Evans wrote: On Sun, 26 May 2013, Klaus Weber wrote: Description: During heavy disk I/O (two bonnie++ processes working on the same disk simultaneously) causes an extreme degradation in disk throughput (combined throughput as observed in iostat drops to ~1-3 MB/sec). The problem shows when both bonnie++ processes are in the "Rewriting..." phase. Please use the unix newline character in mail. My apologies. I submitted the report via the web-interface and did not realize that it would come out this way. Thanks. The log output somehow came out right. I found that the problem could be fixed by killing cluster_write() by turning it into bdwrite() (by editing the running kernel using ddb, since this is easier than rebuilding the kernel). I was trying many similar things since I had a theory that cluster_write() is useless. [...] If that would provide a useful datapoint, I could try if that make a difference on my system. What changes would be required to test this? Surely its not as easy as replacing the function body of cluster_write() in vfs_cluster.c with just "return bdwrite(bp);"? That should work for testing, but it is safer to edit ffs_write() and remove the block where it calls cluster_write() (or bawrite()), so that it falls through to call bdwrite() in most cases. My theory for what the bug is is that cluster_write() and cluster_read() share the limit resource of pbufs. pbufs are not managed as carefully as normal buffers. In particular, there is nothing to limit write pressure from pbufs like there is for normal buffers. Is there anything I can do to confirm rebut this? Is the number of pbufs in use visible via a sysctl, or could I add debug printfs that are triggered when certain limits are reached? Here I don't really know what to look for. First add a sysctl to read the number of free pbufs. The variable for this is cluster_pbuf_freecnt in vm. newfs -b 64k -f 8k /dev/da0p1 The default for newfs is -b 32k. This asks for buffer cache fragmentation. Someone increased the default from 16k to 32k without changing the buffer cache's preferred size (BKVASIZE = 16K). BKVASIZE has always been too small, but on 32-bit arches kernel virtual memory is too limited to have a larger BKVASIZE by default. BKVASIZE is still 16K on all arches although this problem doesn't affetc 64-bit arches. -b 64k is worse. Thank you for this explanation. I was not aware that -b 64k (or even the default values to newfs) would have this effect. I will repeat the tests with 32/4k and 16/2k, although I seem to remember that 64/8k provided a significant performance boost over the defaults. This, and the reduced fsck times was my original motivation to go with the larger values. The reduced fsck time and perhaps the reduced number of cylinder groups are the main advantages of large clusters. vfs-level clustering turns most physical i/o's into 128K-blocks (especially for large files) so there is little difference between the i/o speed for all fs block sizes unless the fs block size is very small. Given the potentially drastic effects of block sizes other than 16/2k, maybe a warning should be added to the newfs manpage? I only found the strong advice to maintain a 8:1 buffer:fragment ratio. Once the kernel misconfiguration understood eniygh for such a warning to not be FUD, it should be easy to fix. When both bonnie++ processes are in their "Rewriting" phase, the system hangs within a few seconds. Both bonnie++ processes are in state "nbufkv". bufdaemon takes about 40% CPU time and is in state "qsleep" when not active. You got the buffer cache fragmentation that you asked for. Looking at vfs_bio.c, I see that it has defrag-code in it. Should I try adding some debug output to this code to get some insight why this does not work, or not as effective as it should? Don't start there, since it is complicated and timing-dependent. Maybe add some printfs to make it easy to see when it enters and leaves defrag mode. Apparently you found a way to reproduce the serious fragmentaion problems. A key factor seems to be the "Rewriting" operation. I see no problem during the "normal" writing, nor could I reproduce it with concurrent dd runs. I don't know exactly what bonnie rewrite bmode does. Is it just read/ [modify]/write of sequential blocks with a fairly small block size? Old bonnie docs say that the block size is always 8K. One reason I don't like bonnie. Clustering should work fairly normally with that. Anything with random seeks would break clustering. Increasing BKVASIZE would take more work than this, since although it was intended to be a system parameter which could be changed to reduce the fragmentation problem, one of the many bugs in it is that it was never converted into a "new" kernel option. Another of the bugs in it is that doubling it halves the number of buffers, so doubling i
Re: kern/178997: Heavy disk I/O may hang system
The following reply was made to PR kern/178997; it has been noted by GNATS. From: Bruce Evans To: Klaus Weber Cc: Bruce Evans , freebsd-gnats-sub...@freebsd.org, freebsd-bugs@FreeBSD.org Subject: Re: kern/178997: Heavy disk I/O may hang system Date: Tue, 28 May 2013 22:03:10 +1000 (EST) On Mon, 27 May 2013, Klaus Weber wrote: > On Mon, May 27, 2013 at 03:57:56PM +1000, Bruce Evans wrote: >> On Sun, 26 May 2013, Klaus Weber wrote: Description: >>> During heavy disk I/O (two bonnie++ processes working on the same disk >>> simultaneously) causes an extreme degradation in disk throughput (combined >>> throughput as observed in iostat drops to ~1-3 MB/sec). The problem shows >>> when both bonnie++ processes are in the "Rewriting..." phase. > >> Please use the unix newline character in mail. > > My apologies. I submitted the report via the web-interface and did not > realize that it would come out this way. Thanks. The log output somehow came out right. >> I found that >> the problem could be fixed by killing cluster_write() by turning it into >> bdwrite() (by editing the running kernel using ddb, since this is easier >> than rebuilding the kernel). I was trying many similar things since I >> had a theory that cluster_write() is useless. [...] > > If that would provide a useful datapoint, I could try if that make a > difference on my system. What changes would be required to test this? > > Surely its not as easy as replacing the function body of > cluster_write() in vfs_cluster.c with just "return bdwrite(bp);"? That should work for testing, but it is safer to edit ffs_write() and remove the block where it calls cluster_write() (or bawrite()), so that it falls through to call bdwrite() in most cases. >> My theory for what the bug is is that >> cluster_write() and cluster_read() share the limit resource of pbufs. >> pbufs are not managed as carefully as normal buffers. In particular, >> there is nothing to limit write pressure from pbufs like there is for >> normal buffers. > > Is there anything I can do to confirm rebut this? Is the number of > pbufs in use visible via a sysctl, or could I add debug printfs that > are triggered when certain limits are reached? Here I don't really know what to look for. First add a sysctl to read the number of free pbufs. The variable for this is cluster_pbuf_freecnt in vm. >>> newfs -b 64k -f 8k /dev/da0p1 >> >> The default for newfs is -b 32k. This asks for buffer cache fragmentation. >> Someone increased the default from 16k to 32k without changing the buffer >> cache's preferred size (BKVASIZE = 16K). BKVASIZE has always been too >> small, but on 32-bit arches kernel virtual memory is too limited to have >> a larger BKVASIZE by default. BKVASIZE is still 16K on all arches >> although this problem doesn't affetc 64-bit arches. >> >> -b 64k is worse. > > Thank you for this explanation. I was not aware that -b 64k (or even > the default values to newfs) would have this effect. I will repeat the > tests with 32/4k and 16/2k, although I seem to remember that 64/8k > provided a significant performance boost over the defaults. This, and > the reduced fsck times was my original motivation to go with the > larger values. The reduced fsck time and perhaps the reduced number of cylinder groups are the main advantages of large clusters. vfs-level clustering turns most physical i/o's into 128K-blocks (especially for large files) so there is little difference between the i/o speed for all fs block sizes unless the fs block size is very small. > Given the potentially drastic effects of block sizes other than 16/2k, > maybe a warning should be added to the newfs manpage? I only found the > strong advice to maintain a 8:1 buffer:fragment ratio. Once the kernel misconfiguration understood eniygh for such a warning to not be FUD, it should be easy to fix. >>> When both bonnie++ processes are in their "Rewriting" phase, the system >>> hangs within a few seconds. Both bonnie++ processes are in state "nbufkv". >>> bufdaemon takes about 40% CPU time and is in state "qsleep" when not >>> active. >> >> You got the buffer cache fragmentation that you asked for. > > Looking at vfs_bio.c, I see that it has defrag-code in it. Should I > try adding some debug output to this code to get some insight why this > does not work, or not as effective as it should? Don't start there, since it is complicated and timing-dependent. Maybe add some printfs to make it easy to see when it enters and leaves defrag mode. >> Apparently you found a way to reproduce the serious fragmentaion >> problems. > > A key factor seems to be the "Rewriting" operation. I see no problem > during the "normal" writing, nor could I reproduce it with concurrent > dd runs. I don't know exactly what bonnie rewrite bmode does. Is it just read/ [modify]/write of sequential blocks with a fairly small block
kern/179048: watch(8) doesn't stop listening TTY when user releases it
>Number: 179048 >Category: kern >Synopsis: watch(8) doesn't stop listening TTY when user releases it >Confidential: no >Severity: non-critical >Priority: low >Responsible:freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Tue May 28 12:30:00 UTC 2013 >Closed-Date: >Last-Modified: >Originator: Serhii Kharchenko >Release:9.1-RELEASE-p1 >Organization: AdvancedHosters >Environment: FreeBSD test-advancedhosters.com 9.1-RELEASE-p1 FreeBSD 9.1-RELEASE-p1 #1: Fri May 24 13:37:29 UTC 2013 r...@test-advancedhosters.com:/usr/obj/usr/src/sys/Z-AMD64 amd64 >Description: When watch(8) is listening TTY and user stops using this TTY (e.g. closes SSH connection) - watch proceeds listening it. It does not exit and does not write that the session is ended. The same problem is observed when security/termlog is used. termlog also uses snp(4) device and it also does not stop listening released TTY. Looks that this problem appeared in FreeBSD-8 after pty(4) was replaced with pts(4) and snp(4) was completely rewritten. >How-To-Repeat: Just open 2 SSH sessions to the server: Session #1: root@test-advancedhosters:/root # tty /dev/pts/0 Session #2: root@test-advancedhosters:/root # watch /dev/pts/0 (and we see all the I/O of terminal /dev/pts/0) After logout of session #1 we see just "logout" word and watch proceeds listening. TTY device is present and it is disappear only after watch is killed: root@test-advancedhosters:/root # ps aux | grep watch | grep -v grep root45903 0.0 0.0 12288 1940 1 I+ 12:11PM0:00.00 watch /dev/pts/0 root@test-advancedhosters:/root # ls -la /dev/pts/0 crw-rw-rw- 1 root wheel0, 67 May 28 12:13 /dev/pts/0 root@test-advancedhosters:/root # kill 45903 root@test-advancedhosters:/root # ls -la /dev/pts/0 ls: /dev/pts/0: No such file or directory >Fix: >Release-Note: >Audit-Trail: >Unformatted: ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: bin/178664: commit references a PR
The following reply was made to PR bin/178664; it has been noted by GNATS.
From: dfil...@freebsd.org (dfilter service)
To: bug-follo...@freebsd.org
Cc:
Subject: Re: bin/178664: commit references a PR
Date: Tue, 28 May 2013 22:07:48 + (UTC)
Author: jilles
Date: Tue May 28 22:07:31 2013
New Revision: 251078
URL: http://svnweb.freebsd.org/changeset/base/251078
Log:
sleep: Improve nanosleep() error handling:
* Work around kernel bugs that cause a spurious [EINTR] return if a
debugger (such as truss(1)) is attached.
* Write an error message if an error other than [EINTR] occurs.
PR: bin/178664
Modified:
head/bin/sleep/sleep.c
Modified: head/bin/sleep/sleep.c
==
--- head/bin/sleep/sleep.c Tue May 28 22:07:23 2013(r251077)
+++ head/bin/sleep/sleep.c Tue May 28 22:07:31 2013(r251078)
@@ -43,6 +43,7 @@ __FBSDID("$FreeBSD$");
#include
#include
+#include
#include
#include
#include
@@ -87,8 +88,8 @@ main(int argc, char *argv[])
warnx("about %d second(s) left out of the original %d",
(int)time_to_sleep.tv_sec, (int)original);
report_requested = 0;
- } else
- break;
+ } else if (errno != EINTR)
+ err(1, "nanosleep");
}
return (0);
}
___
svn-src-...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: usb/178771: [usbdevs] [patch] Western Digital My Passport HD
> Responsible-Changed-From-To: freebsd-bugs->freebsd-usb > Responsible-Changed-By: linimon > Responsible-Changed-When: Sun May 19 08:22:01 UTC 2013 > Responsible-Changed-Why: > reclassify. > > http://www.freebsd.org/cgi/query-pr.cgi?pr=178771 This looks like it might fix my issue: http://www.freebsd.org/cgi/query-pr.cgi?pr=177895 Two newbie questions (links to a FAQ or general admonishment for not knowing what I'm doing welcome): 1. How do I apply this patch on a 9.1-RELEASE-p3 system for testing? I'll report back my findings. 2. If the patch does the trick, when will it get bundled into the next RELEASE version? Will it come out with the next patch level or does the minor version number need to increment first? Thanks! ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
