Re: kern/175909: FreeBSD 9.1 ipfw lookup dst-port regression
The following reply was made to PR kern/175909; it has been noted by GNATS. From: Gleb Smirnoff To: Daniel Hagerty Cc: freebsd-gnats-sub...@freebsd.org, melif...@freebsd.org Subject: Re: kern/175909: FreeBSD 9.1 ipfw lookup dst-port regression Date: Thu, 7 Feb 2013 12:38:32 +0400 Daniel, On Wed, Feb 06, 2013 at 08:38:24PM -0500, Daniel Hagerty wrote: D> >Description: D> D> ipfw lookup dst-port rules don't seem to work. Didn't test D> similar cases, like src-port. D> D> >How-To-Repeat: D> Load these ipfw rules: D> D> table 1 add 22 D> add 1 permit log ip4 from any to any proto tcp lookup dst-port 1 D> add 00010 permit log ip from any to any proto tcp dst-port 22 D> D> Observe how on freebsd 9.1, rule 1 will never match port 22 D> traffic it should, whereas the same rules on 8.3 will hit rule 1, as D> expected. D> D> >Fix: D> I worked around it for the moment by writing the rule without a D> lookup table; don't have time to kernel spelunk. Can you please try whether the problem can be reproduced on stable/9 branch prior to revision r234597? To accomplish this you need: # svn co -r r234596 http://svn.freebsd.org/base/stable/9 # cd 9 # make buildworld buildkernel # make installkernel installworld reboot -- Totus tuus, Glebius. ___ 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/175897: operations on readonly zpool hang
The following reply was made to PR kern/175897; it has been noted by GNATS. From: Andriy Gapon To: bug-follo...@freebsd.org, jh...@symmetricom.com Cc: Subject: Re: kern/175897: operations on readonly zpool hang Date: Thu, 07 Feb 2013 10:51:21 +0200 Don't hesitate to get a full procstat -kk -a output. -- Andriy Gapon ___ 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/175645: tcpdump(1) incorrectly decodes pflog'ged UDP packet as ATALK
Synopsis: tcpdump(1) incorrectly decodes pflog'ged UDP packet as ATALK Responsible-Changed-From-To: freebsd-bugs->glebius Responsible-Changed-By: glebius Responsible-Changed-When: Thu Feb 7 09:09:50 UTC 2013 Responsible-Changed-Why: I'll look at this once I have time. http://www.freebsd.org/cgi/query-pr.cgi?pr=175645 ___ 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/175883: Add support for SCM_BINTIME for PF_LOCAL sockets
Synopsis: Add support for SCM_BINTIME for PF_LOCAL sockets Responsible-Changed-From-To: freebsd-bugs->glebius Responsible-Changed-By: glebius Responsible-Changed-When: Thu Feb 7 09:10:37 UTC 2013 Responsible-Changed-Why: I'll look at this one once I have time. http://www.freebsd.org/cgi/query-pr.cgi?pr=175883 ___ 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/175909: FreeBSD 9.1 ipfw lookup dst-port regression
Synopsis: FreeBSD 9.1 ipfw lookup dst-port regression Responsible-Changed-From-To: freebsd-bugs->melifaro Responsible-Changed-By: melifaro Responsible-Changed-When: Thu Feb 7 09:11:06 UTC 2013 Responsible-Changed-Why: I can reproduce this issue on my pre-9.1 desktop. There is no need for doing kernel recompiling. http://www.freebsd.org/cgi/query-pr.cgi?pr=175909 ___ 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"
misc/175930: CLang does not define __STDC_ISO_10646__, despite having Unicode in wchar_t
>Number: 175930
>Category: misc
>Synopsis: CLang does not define __STDC_ISO_10646__, despite having
>Unicode in wchar_t
>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: Thu Feb 07 17:50:00 UTC 2013
>Closed-Date:
>Last-Modified:
>Originator: Tim Čas
>Release:9.1-RELEASE
>Organization:
n/a
>Environment:
FreeBSD tsibsd.tsi 9.1-RELEASE FreeBSD 9.1-RELEASE #0 r243825: Tue Dec 4
09:23:10 UTC 2012 r...@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC
amd64
>Description:
wchar_t appears to be Unicode, but __STDC_ISO_10646__ is not defined.
Tested with both the core and the ports versions:
FreeBSD clang version 3.1 (branches/release_31 156863) 20120523
Target: x86_64-unknown-freebsd9.0
Thread model: posix
clang version 3.1 (branches/release_31)
Target: amd64-portbld-freebsd9.0
Thread model: posix
Test file:
--
#include
#include
#include
int main(void)
{
#ifdef __STDC_ISO_10646__
printf("__STDC_ISO_10646__ defined\n");
#else
printf("__STDC_ISO_10646__ NOT defined\n");
#endif
return 0;
}
>How-To-Repeat:
Compile and run the above test file (here "test.c"):
$ clang test.c -o test
$ ./test
__STDC_ISO_10646__ NOT defined
$ /usr/local/bin/clang test.c -o test
$ ./test
__STDC_ISO_10646__ NOT defined
>Fix:
Have the compiler define the macro to its appropriate value.
>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/168104: racoon daemon exited on signal 11 (SEGV) and was not restarted
Note that this has happened again, six months later on different hardware. Machine was under extremely light load at the time. ___ 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"
bin/175943: [PATCH] Add trim capability to gpart
>Number: 175943
>Category: bin
>Synopsis: [PATCH] Add trim capability to gpart
>Confidential: no
>Severity: non-critical
>Priority: low
>Responsible:freebsd-bugs
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: change-request
>Submitter-Id: current-users
>Arrival-Date: Thu Feb 07 23:30:00 UTC 2013
>Closed-Date:
>Last-Modified:
>Originator: Dan Nelson
>Release:FreeBSD 9.1-STABLE amd64
>Organization:
>Environment:
System: FreeBSD dan.emsphone.com 9.1-STABLE FreeBSD 9.1-STABLE #652 r246183M:
Thu Jan 31 16:32:57 CST 2013
z...@dan.emsphone.com:/usr/src/sys/amd64/compile/DANSMP amd64
>Description:
I have occasionally wanted to erase all or part of an SSD device to recover
performance after heavy random write activity. It can sort-of be done with
either newfs -E or creating+deleting a zfs pool on the area to erase, but
both write a varying amount of data after they send their BIO_DELETE calls,
and there should be a cleaner way to do it. Attached is a patch that adds a
"trim" verb to the gpart command, which opens the raw device and calls
g_delete on it.
Feel free to pick a new name if you can think of a better one. I know that
"trim" refers only to the SATA implementation, but "delete" is already
taken, "erase" implies unconditional erasure which is not true for devices
that ignore BIO_DELETE calls, and most people that want the functionality
refer to it as TRIM anyway.
>How-To-Repeat:
>Fix:
Index: geom_part.c
===
--- geom_part.c (revision 246183)
+++ geom_part.c (working copy)
@@ -90,6 +90,7 @@
static void gpart_print_error(const char *);
static void gpart_backup(struct gctl_req *, unsigned int);
static void gpart_restore(struct gctl_req *, unsigned int);
+static void gpart_trim(struct gctl_req *, unsigned int);
struct g_command PUBSYM(class_commands)[] = {
{ "add", 0, gpart_issue, {
@@ -159,6 +160,9 @@
G_OPT_SENTINEL },
"[-l | -r] [-p] [geom ...]"
},
+ { "trim", 0, gpart_trim, G_NULL_OPTS,
+ "provider"
+ },
{ "undo", 0, gpart_issue, G_NULL_OPTS,
"geom"
},
@@ -1279,3 +1283,22 @@
gctl_free(req);
exit(status);
}
+
+static void
+gpart_trim(struct gctl_req *req, unsigned int fl __unused)
+{
+ const char *s;
+ int fd;
+
+ if (gctl_get_int(req, "nargs") != 1)
+ errx(EXIT_FAILURE, "Invalid number of arguments.");
+ s = gctl_get_ascii(req, "arg0");
+ if (s == NULL)
+ abort();
+ fd = g_open(s, 1);
+ if (fd == -1)
+ err(EXIT_FAILURE, "Cannot open %s", s);
+ if (g_delete(fd, 0, g_mediasize(fd)) == -1)
+ err(EXIT_FAILURE, "g_delete call failed");
+ g_close(fd);
+}
Index: gpart.8
===
--- gpart.8 (revision 246183)
+++ gpart.8 (working copy)
@@ -144,6 +144,10 @@
.Op Fl l | r
.Op Fl p
.Op Ar geom ...
+.\" TRIM
+.Nm
+.Cm trim
+.Ar provider
.\" UNDO
.Nm
.Cm undo
@@ -471,6 +475,15 @@
.It Fl r
Show raw partition type instead of symbolic name.
.El
+.\" TRIM
+.It Cm trim
+Sends a BIO_DELETE request for the contents of the provider
+.Ar provider .
+Depending on the underlying storage device, this may may fill its blocks
+with a constant value (0x00 or 0xFF), or may do nothing. Running this
+command on a partition on an SSD device before deleting it may improve
+performance, since the SSD can immediately reuse the blocks for subsequent
+write requests.
.\" UNDO
.It Cm undo
Revert any pending changes for geom
>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/175943: [PATCH] Add trim capability to gpart
Oops. Small typo in the man page: "this may may fill its blocks" should be "this may fill its blocks" ___ 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/175943: [PATCH] Add trim capability to gpart
The following reply was made to PR bin/175943; it has been noted by GNATS. From: Dan Nelson To: freebsd-gnats-sub...@freebsd.org, freebsd-bugs@FreeBSD.org Cc: Subject: Re: bin/175943: [PATCH] Add trim capability to gpart Date: Thu, 7 Feb 2013 17:36:32 -0600 Oops. Small typo in the man page: "this may may fill its blocks" should be "this may fill its blocks" ___ 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/175897: operations on readonly zpool hang
The following reply was made to PR kern/175897; it has been noted by GNATS. From: John Hein To: Andriy Gapon Cc: Subject: Re: kern/175897: operations on readonly zpool hang Date: Thu, 7 Feb 2013 19:00:01 -0700 Andriy Gapon wrote at 10:51 +0200 on Feb 7, 2013: > Don't hesitate to get a full procstat -kk -a output. sudo procstat -kk 8168 8181 PIDTID COMM TDNAME KSTACK 8168 100087 sudo -mi_switch+0x190 sleepq_catch_signals+0x27f sleepq_wait_sig+0x16 _cv_wait_sig+0x129 seltdwait+0xac kern_select+0x6ef sys_select+0x5d amd64_syscall+0x25b Xfast_syscall+0xf7 8181 100055 zfs -mi_switch+0x190 sleepq_wait+0x44 _cv_wait+0x114 txg_wait_synced+0x85 dsl_sync_task_group_wait+0x128 dsl_sync_task_do+0x54 dsl_props_set+0x147 zfs_set_prop_nvlist+0x3ad zfs_ioc_set_prop+0x75 zfsdev_ioctl+0xe6 devfs_ioctl_f+0x7a kern_ioctl+0x106 sys_ioctl+0xfd amd64_syscall+0x25b Xfast_syscall+0xf7 ___ 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/175897: operations on readonly zpool hang
The following reply was made to PR kern/175897; it has been noted by GNATS. From: Andriy Gapon To: John Hein Cc: bug-follo...@freebsd.org Subject: Re: kern/175897: operations on readonly zpool hang Date: Fri, 08 Feb 2013 07:25:20 +0200 on 08/02/2013 04:00 John Hein said the following: > Andriy Gapon wrote at 10:51 +0200 on Feb 7, 2013: > > Don't hesitate to get a full procstat -kk -a output. > > sudo procstat -kk 8168 8181 > PIDTID COMM TDNAME KSTACK > 8168 100087 sudo -mi_switch+0x190 > sleepq_catch_signals+0x27f sleepq_wait_sig+0x16 _cv_wait_sig+0x129 > seltdwait+0xac kern_select+0x6ef sys_select+0x5d amd64_syscall+0x25b > Xfast_syscall+0xf7 > 8181 100055 zfs -mi_switch+0x190 > sleepq_wait+0x44 _cv_wait+0x114 txg_wait_synced+0x85 > dsl_sync_task_group_wait+0x128 dsl_sync_task_do+0x54 dsl_props_set+0x147 > zfs_set_prop_nvlist+0x3ad zfs_ioc_set_prop+0x75 zfsdev_ioctl+0xe6 > devfs_ioctl_f+0x7a kern_ioctl+0x106 sys_ioctl+0xfd amd64_syscall+0x25b > Xfast_syscall+0xf7 > There seems to be some mis-communication. This is not procstat *-a* output. -- Andriy Gapon ___ 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/175950: Possible deadlock in zfs after long uptime
The following reply was made to PR kern/175950; it has been noted by GNATS. From: Andriy Gapon To: bug-follo...@freebsd.org, pascal.guitier...@gmail.com Cc: Subject: Re: kern/175950: Possible deadlock in zfs after long uptime Date: Fri, 08 Feb 2013 08:26:03 +0200 Thank you for the report. You seem to have run into a problem that is triggered by either low available physical memory or low KVA. r242859 on stable/8 branch may reduce chances of the problem. Unfortunately, there is no complete resolution at the moment. If you are interested, some technical details could be found here: http://article.gmane.org/gmane.os.freebsd.stable/84981 Could you please also provide output of the following sysctls (for completeness sake): vm.stats vm.kmem_size vm.kmem_map_size vm.kmem_map_free P.S. The bad thread in your report: 1963 100308 nfsd nfsd: servicemi_switch+0x176 sleepq_wait+0x42 _sleep+0x317 arc_lowmem+0x77 kmem_malloc+0xc1 uma_large_malloc+0x4a malloc+0xd7 arc_get_data_buf+0xb5 arc_read_nolock+0x1ec arc_read+0x93 dbuf_read+0x452 dmu_tx_check_ioerr+0x9a dmu_tx_count_write+0x29c dmu_tx_hold_write+0x4a zfs_freebsd_write+0x372 VOP_WRITE_APV+0xb2 nfsrv_write+0x969 nfssvc_program+0x1a6 -- Andriy Gapon ___ 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"
