Re: Increase BUFSIZ to 8192
4k block size on the underlying device? On 12/05/2015 00:14, Adrian Chadd wrote: So I'm curious - why's it faster? -adrian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Panic using QLogic NetXtreme II BCM57810 with latest CURRENT snapshot
Hi! I got the following panic with a QLogic NetXtreme II BCM57810 when trying to assign an IP address using dhclient. The network card uses the bxe driver. The machine in question is a HP DL380 Gen9. Kernel page fault with the following non-sleepable locks held: shared rw if_addr_lock (if_addr_lock) locked @ /usr/src/sys/net/if.c:1539 exclusive sleep mutex bxe0_mcast_lock lockeed @ /usr/src/sys/dev/bxe/bxe.c:12548 See screenshots at the links below for details and a stack trace. I can provoke this panic at will, let me know if you need more details. Unfortunately I don't have access to a console where I can copy things out currently, so screenshots have to do. Screenshot 1: https://people.freebsd.org/~zeising/panic1.png Screenshot 2: https://people.freebsd.org/~zeising/panic2.png Regards! -- Niclas ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Increase BUFSIZ to 8192
In message 20150512032307.gp37...@funkthat.com, John-Mark Gurney writes: Also, you'd probably see even better performance by increasing the size to 64k, [...] easy: 8K on 32bit 64k on 64bit -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Increase BUFSIZ to 8192
On Tue, May 12, 2015 at 06:31:33AM +, Poul-Henning Kamp wrote: Also, you'd probably see even better performance by increasing the size to 64k, [...] easy: 8K on 32bit 64k on 64bit Need benchmarking. May be 16K is local maximum (L1 cache-efficient). ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: nmount, mountd drops high order MNT_xx flags during a mount update
David Boyd wrote: On Sun, 2015-05-10 at 09:07 -0400, Rick Macklem wrote: Oops, I did my usual and forgot to attach the patch. Here it is, rick - Original Message - Doug Rabson wrote: You could add a single integer-valued vfsopt which holds the high-order bits of f_flags? I have created a patch that does this. It is on https://reviews.freebsd.org/D2506 (I have also attached it here, for those who don't use Phabricator.) Please review/comment on this. (Feel free to add yourself as a reviewer, etc.) Also, David, if you can test this patch, it would be appreciated. Thanks for the suggestion Doug, rick On 7 May 2015 at 02:10, Rick Macklem rmack...@uoguelph.ca wrote: David Boyd reported a problem to freebsd-current@ w.r.t. the MNT_AUTOMOUNTED flag getting cleared by mountd. http://docs.FreeBSD.org/cgi/mid.cgi?1429477202.29812.38.camel I just took a look at this and it's kinda ugly... mountd acquires a list of mounts via getmntinfo() and then does an nmount() for each of them to get rid of any exports. It uses f_flags from the statfs returned by getmntinfo() as the 3rd argument to nmount(). -- Since nmount()s 3rd argument is a int, it silently drops any MNT_xx flag in the high order 32bits of f_flags. At this time, it happens that MNT_AUTOMOUNTED is the only one, but... I can think of a couple of ways to fix this, but I don't like any of them;-) 1) I suppose mountd could check for each flag set in f_flags and generate a vfsopts string for it, but that means that every time a new flag that can be updated is added to MNT_xx, this mountd.c code would have to updated. -- Ugly!! 2) Require that all flags in MNT_UPDATEMASK be in the low order 32bits. I wouldn`t mind this except in means that the MNT_xx flags must be redefined and I don`t think that could get MFC`d. 3) Add a new newernmount(2) which has a 64bit flags argument instead of int. Hopefully someone can think of a nice way to fix this, rick ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org Rick, Edward, et al, I have applied your patches to several (four) servers and have not noticed any more instances of the errant behavior. Thanks for testing it and confirming that the problem is what I thought it was. I think (hope) that this is the correct fix and wonder if this fix might make it's way into an errata. Well, at this point, it isn't obvious if it should even go in head/current. (See https://reviews.freebsd.org/D2506) The patch already in head/current (r281699) should fix your problem. (It stops mountd from updating non-exported mounts.) It has not been MFC'd, but I will look into that. I don't know if it could also be an errata. Since it now appears to be a fix for an observed bug and not just an optimization, maybe? rick Thanks for the quick responses. David Boyd. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Panic using QLogic NetXtreme II BCM57810 with latest CURRENT snapshot
On 13 May 2015 at 00:21, Niclas Zeising zeis...@freebsd.org wrote:
Hi!
I got the following panic with a QLogic NetXtreme II BCM57810 when
trying to assign an IP address using dhclient. The network card uses
the bxe driver. The machine in question is a HP DL380 Gen9.
Kernel page fault with the following non-sleepable locks held:
shared rw if_addr_lock (if_addr_lock) locked @ /usr/src/sys/net/if.c:1539
exclusive sleep mutex bxe0_mcast_lock lockeed @
/usr/src/sys/dev/bxe/bxe.c:12548
See screenshots at the links below for details and a stack trace.
I can provoke this panic at will, let me know if you need more details.
Unfortunately I don't have access to a console where I can copy things
out currently, so screenshots have to do.
Screenshot 1: https://people.freebsd.org/~zeising/panic1.png
Screenshot 2: https://people.freebsd.org/~zeising/panic2.png
I'm not in any way a network/bxe expert, and this is probably unrelated,
but I see there at least a missing unlock at the error path.
Index: sys/dev/bxe/bxe.c
===
--- sys/dev/bxe/bxe.c (revision 282468)
+++ sys/dev/bxe/bxe.c (working copy)
@@ -12551,6 +12551,7 @@
rc = ecore_config_mcast(sc, rparam, ECORE_MCAST_CMD_DEL);
if (rc 0) {
BLOGE(sc, Failed to clear multicast configuration: %d\n, rc);
+BXE_MCAST_UNLOCK(sc);
return (rc);
}
BXE_MCAST_LOCK acquires two locks: sc mutex, and if_maddr_rlock(ifp)
OTOH, in bxe_init_mcast_macs_list(), down the path, if_maddr_rlock is acquired
(and released) one more time: in if_multiaddr_array / if_multiaddr_count
functions. Is it recursive?
Another one is bcopy under lock. It is probably inlined
under bxe_handle_rx_mode_tq() in ddb, so the actual place
where it's called is not visible.
My guess is bcopy in bxe_init_mcast_macs_list():
bcopy((mta + (i * ETHER_ADDR_LEN)), mc_mac-mac, ETHER_ADDR_LEN);
Previously, there was a pointer assignment, see stable/10:
mc_mac-mac = (uint8_t *)LLADDR((struct sockaddr_dl *)ifma-ifma_addr);
mc_mac itself is malloc(M_ZERO)'ed, so that mc_mac-mac is NULL.
Probably bcopy should be restored to assignment (not even compile tested):
Index: sys/dev/bxe/bxe.c
===
--- sys/dev/bxe/bxe.c (revision 282468)
+++ sys/dev/bxe/bxe.c (working copy)
@@ -12506,7 +12506,7 @@
to be different */
for(i=0; i mcnt; i++) {
-bcopy((mta + (i * ETHER_ADDR_LEN)), mc_mac-mac, ETHER_ADDR_LEN);
+mc_mac-mac = (uint8_t *)(mta + (i * ETHER_ADDR_LEN));
ECORE_LIST_PUSH_TAIL(mc_mac-link, p-mcast_list);
BLOGD(sc, DBG_LOAD,
--
wbr,
pluknet
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
