svn commit: r270781 - head/etc/rc.d
Author: hrs Date: Fri Aug 29 06:31:18 2014 New Revision: 270781 URL: http://svnweb.freebsd.org/changeset/base/270781 Log: - Add a warning message when an IPv6 address is specified with no prefixlen. - Use a parameter argument in jls(8) instead of doing grep. Modified: head/etc/rc.d/jail Modified: head/etc/rc.d/jail == --- head/etc/rc.d/jail Fri Aug 29 06:23:00 2014(r270780) +++ head/etc/rc.d/jail Fri Aug 29 06:31:18 2014(r270781) @@ -321,6 +321,8 @@ jail_extract_address() elif [ "${_type}" = "inet6" ]; then # In case _maske is not set for IPv6, use /128. _mask=${_mask:-/128} + warn "$_type $_addr: an IPv6 address should always be " \ + "specified with a prefix length. /128 is used." fi } @@ -420,7 +422,7 @@ jail_status() jail_start() { - local _j _jid _jn _jl + local _j _jid _jl if [ $# = 0 ]; then return @@ -433,12 +435,10 @@ jail_start() command_args="-f $jail_conf -c" _tmp=`mktemp -t jail` || exit 3 if $command $rc_flags $command_args >> $_tmp 2>&1; then - $jail_jls -nq | while read IN; do - _jn=$(echo $IN | tr " " "\n" | grep ^name=) - _jid=$(echo $IN | tr " " "\n" | grep ^jid=) - echo -n " ${_jn#name=}" - echo "${_jid#jid=}" \ - > /var/run/jail_${_jn#name=}.id + $jail_jls jid name | while read IN; do + set -- $IN + echo -n " $2" + echo $1 > /var/run/jail_$2.id done else tail -1 $_tmp @@ -468,9 +468,8 @@ jail_start() sleep 1 for _j in $_jl; do echo -n " ${_hostname:-${_j}}" - if _jid=$($jail_jls -n -j $_j | tr " " "\n" | \ - grep ^jid=); then - echo "${_jid#jid=}" > /var/run/jail_${_j}.id + if _jid=$($jail_jls -j $_j jid); then + echo "$_jid" > /var/run/jail_${_j}.id else rm -f /var/run/jail_${_j}.id echo " cannot start jail " \ @@ -492,9 +491,8 @@ jail_start() if $command $rc_flags $command_args \ >> $_tmp 2>&1 /var/run/jail_${_j}.id + _jid=$($jail_jls -j $_j jid) + echo $_jid > /var/run/jail_${_j}.id else rm -f /var/run/jail_${_j}.id echo " cannot start jail " \ @@ -509,7 +507,7 @@ jail_start() jail_stop() { - local _j _jn + local _j if [ $# = 0 ]; then return @@ -520,16 +518,14 @@ jail_stop() command=$jail_program rc_flags=$jail_flags command_args="-f $jail_conf -r" - $jail_jls -nq | while read IN; do - _jn=$(echo $IN | tr " " "\n" | grep ^name=) - echo -n " ${_jn#name=}" + $jail_jls name | while read _j; do + echo -n " $_j" _tmp=`mktemp -t jail` || exit 3 - $command $rc_flags $command_args ${_jn#name=} \ - >> $_tmp 2>&1 - if $jail_jls -j ${_jn#name=} > /dev/null 2>&1; then + $command $rc_flags $command_args $_j >> $_tmp 2>&1 + if $jail_jls -j $_j > /dev/null 2>&1; then tail -1 $_tmp else - rm -f /var/run/jail_${_jn#name=}.id + rm -f /var/run/jail_${_j}.id fi rm -f $_tmp done ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r270780 - in head/etc: defaults rc.d
Author: hrs Date: Fri Aug 29 06:23:00 2014 New Revision: 270780 URL: http://svnweb.freebsd.org/changeset/base/270780 Log: Fix rc.d/gssd script to define the default values in a standard way. Modified: head/etc/defaults/rc.conf head/etc/rc.d/gssd Modified: head/etc/defaults/rc.conf == --- head/etc/defaults/rc.conf Fri Aug 29 02:21:02 2014(r270779) +++ head/etc/defaults/rc.conf Fri Aug 29 06:23:00 2014(r270780) @@ -282,6 +282,7 @@ kfd_enable="NO" # Run kfd (or NO) kfd_program="/usr/libexec/kfd" # path to kerberos 5 kfd daemon gssd_enable="NO" # Run the gssd daemon (or NO). +gssd_program="/usr/sbin/gssd" # Path to gssd. gssd_flags="" # Flags for gssd. rwhod_enable="NO" # Run the rwho daemon (or NO). Modified: head/etc/rc.d/gssd == --- head/etc/rc.d/gssd Fri Aug 29 02:21:02 2014(r270779) +++ head/etc/rc.d/gssd Fri Aug 29 06:23:00 2014(r270780) @@ -9,10 +9,8 @@ . /etc/rc.subr -name="gssd" +name=gssd +rcvar=gssd_enable load_rc_config $name -rcvar="gssd_enable" -command="${gssd:-/usr/sbin/${name}}" -eval ${name}_flags=\"${gssd_flags}\" run_rc_command "$1" ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r270771 - head/bin/dd
On Thu, 28 Aug 2014, Warner Losh wrote: Author: imp Date: Thu Aug 28 21:30:39 2014 New Revision: 270771 URL: http://svnweb.freebsd.org/changeset/base/270771 Log: Add canonical population of a disk / thumb drive from an image example. Modified: head/bin/dd/dd.1 Modified: head/bin/dd/dd.1 == --- head/bin/dd/dd.1Thu Aug 28 21:27:37 2014(r270770) +++ head/bin/dd/dd.1Thu Aug 28 21:30:39 2014(r270771) @@ -408,6 +408,11 @@ To create an image of a Mode-1 CD-ROM, w for data CD-ROM disks, use a block size of 2048 bytes: .Pp .Dl "dd if=/dev/acd0 of=filename.iso bs=2048" +.Pp +Write a filesystem image to a memory stick, padding the end with zeros, +if necessary, to a 1MiB boundary: +.Pp +.Dl "dd if=memstick.img of=/dev/da0 bs=1m conv=noerror,sync" .Sh SEE ALSO .Xr cp 1 , .Xr mt 1 , dd.1 doesn't use the MiB uglyness anywhere else. It even defines 1M correctly: Where sizes are specified, a decimal, octal, or hexadecimal number of bytes is expected. If the number ends with a ``b'', ``k'', ``m'', ``g'', or ``w'', the number is multiplied by 512, 1024 (1K), 1048576 (1M), 1073741824 (1G) or the number of bytes in an integer, respectively. Two or more numbers may be separated by an ``x'' to indicate a product. dd also has the correct amount of support (none) for power of 10 sizes in args. However, it is not useful to use 1M in the description of ``m''. It basically describes ``m'' by saying that it is ``M''. 1048576 is sufficient and not mistakable for 100. The technical term 1M is not used anywhere in the man page. Similarly for 1K and 1G. However2, dd also accepts upper case aliases for ``m'', etc. These are relatively recent bugs in FreeBSD. They are too recent for news of them to have reached the man page. There aren't enough letters to use 2 aliases every power of 2 size, especially starting some years after the MiB uglyness. humanize_number(3) still have much the same bugs, except it supports power of 10 sizes. expand_number(3) is a little better. humanize_number() doesn't humanize numbers. It converts integers into a string representation in a special dehumanized (scientific) format. expand_number() doesn't expand numbers. It parses string representations of integers into object representations of integers. This is rarely an expansion. Normal English usage is that "12345" is a decimal expansion of a number, not that the number is an expansion of "12345". The string representation is usually also larger in size. expand_number() documents its wastage of 2 aliases for every power of 2 size and its null support for power of 10 sizes. It doesn't explicitly document its null support for suffixes like "MiB". It still describes the suffixes as prefixes. They may be prefixes in some technical SI sense, but they are always suffixes for the parser. (Indeed, they are prefixes in the technical sense of being prefixes for units. expand_number() only "expands" raw numbers, so the units are null.) It doesn't document its support for hex and octal numbers. dd does document this, if not the complete syntax. expand_number() has some extensions like support for 3 suffixes above g, but doesn't support multpliers like dd. Otherwise, it parses string representations of numbers much like dd. humanize_number() doesn't waste letters for suffixes. It only prints upper case suffixes, except k means 1000 and K means 1024 (it has no support for floating point numbers so it doesn't need lower case suffixes like m for milli). It has an option to print power of 2 suffixes in the uglified Mi format. It has an option to print a suffix like "B", so that megabytes become "MB" or "MiB" or even "MB is the correct spelling of 104876 bytes; MiB is ugly, but not as ugly as mebiB; fortunately, this function cannot print mebi, since it only prints upper suffixes except for k." This explains some of the confusing uses of "prefix". First the digits representing the number are put in the string. Then an SI suffix is appended if necessary. Then a suffix like "B" is appended if requested. So the SI suffixes may be in the middle. expand_number() doesn't support suffixes like "B". Oops. The suffix is documented as always being printed, with a space between it and the rest, so "MB" is impossible. There is an HN_NOSPACE flag for suppressing the space before the SI suffixes, but I don't see one for the final suffix. Most callers are like df and space-constrained, so they use HN_NOSPACE and don't print a "B" suffix. I think they sometimes get the space before the empty suffix at the end, and either use this as a separator or do extra work to remove it. There is also an HN_B flag which gives a suffix in the SI position if the SI suffix is null. Most disk utilities use this, but only small files end up with a "B" suffix from this. When they do, the space before it is controlled by
Re: svn commit: r270759 - in head/sys: cddl/compat/opensolaris/kern cddl/compat/opensolaris/sys cddl/contrib/opensolaris/uts/common/fs/zfs vm
On Thu, Aug 28, 2014 at 10:11:39PM +0100, Steven Hartland wrote: > I'll MFC to 9 and possibly 8 as well at that time if relavent. Although I don't use ZFS on stable/8, your care about our best stable branch :) is much appreciated. ./danfe ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r270775 - head/sys/dev/ixl
Author: jfv Date: Fri Aug 29 00:33:31 2014 New Revision: 270775 URL: http://svnweb.freebsd.org/changeset/base/270775 Log: Fix the NOINET and NOINET6 builds. MFC after:3 days Modified: head/sys/dev/ixl/ixl_txrx.c Modified: head/sys/dev/ixl/ixl_txrx.c == --- head/sys/dev/ixl/ixl_txrx.c Thu Aug 28 23:32:56 2014(r270774) +++ head/sys/dev/ixl/ixl_txrx.c Fri Aug 29 00:33:31 2014(r270775) @@ -596,6 +596,7 @@ ixl_tx_setup_offload(struct ixl_queue *q switch (etype) { case ETHERTYPE_IP: +#ifdef INET ip = (struct ip *)(mp->m_data + elen); ip_hlen = ip->ip_hl << 2; ipproto = ip->ip_p; @@ -605,14 +606,17 @@ ixl_tx_setup_offload(struct ixl_queue *q *cmd |= I40E_TX_DESC_CMD_IIPT_IPV4_CSUM; else *cmd |= I40E_TX_DESC_CMD_IIPT_IPV4; +#endif break; case ETHERTYPE_IPV6: +#ifdef INET6 ip6 = (struct ip6_hdr *)(mp->m_data + elen); ip_hlen = sizeof(struct ip6_hdr); ipproto = ip6->ip6_nxt; th = (struct tcphdr *)((caddr_t)ip6 + ip_hlen); *cmd |= I40E_TX_DESC_CMD_IIPT_IPV6; /* Falls thru */ +#endif default: break; } ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r269134 - head/sys/vm
Hm, ok, r269134 worked but r269799 didn't. I'll keep digging, thanks! -a ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r269134 - head/sys/vm
Just tried it, it didn't work: RedBoot> load kernel.RSPRO Using default protocol (TFTP) Entry point: 0x80050100, address range: 0x8005-0x805b11cc RedBoot> RedBoot> go CPU platform: Atheros AR7161 rev 2 CPU Frequency=720 MHz CPU DDR Frequency=360 MHz CPU AHB Frequency=180 MHz platform frequency: 720 MHz CPU reference clock: 40 MHz CPU MDIO clock: 40 MHz arguments: a0 = 80050100 a1 = 8ff0 a2 = 0001 a3 = 0007 Cmd line: Environment: envp is invalid Cache info: picache_stride= 4096 picache_loopcount = 16 pdcache_stride= 4096 pdcache_loopcount = 8 cpu0: MIPS Technologies processor v116.147 MMU: Standard TLB, 16 entries L1 i-cache: 4 ways of 512 sets, 32 bytes per line L1 d-cache: 4 ways of 256 sets, 32 bytes per line Config1=0x9ee3519e Config3=0x20 KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2014 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 11.0-CURRENT #3 r269799: Fri Aug 29 00:17:22 UTC 2014 adrian@adrian-hackbox:/usr/home/adrian/work/freebsd/embedded/head/obj/mips/mips.mips/usr/home/adrian/work/freebsd/embedded/head/src/sys/RSPRO mips gcc version 4.2.1 20070831 patched [FreeBSD] WARNING: WITNESS option enabled, expect reduced performance. MEMGUARD DEBUGGING ALLOCATOR INITIALIZED: MEMGUARD map base: 0xc080 MEMGUARD map size: 45696 KBytes real memory = 33554432 (32768K bytes) avail memory = 22806528 (21MB) random device not loaded; using insecure entropy random: initialized nexus0: clock0: on nexus0 Timecounter "MIPS32" frequency 36000 Hz quality 800 Event timer "MIPS32" frequency 36000 Hz quality 800 argemdio0: at mem 0x1900-0x19000fff on nexus0 mdio0: on argemdio0 mdioproxy0: on mdio0 arswitch0: on mdio0 arswitch0: ar8316_hw_setup: MAC port == RGMII, port 4 = dedicated PHY arswitch0: ar8316_hw_setup: port 4 RGMII workaround miibus0: on arswitch0 ukphy0: PHY 0 on miibus0 ukphy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT-FDX, 1000baseT-FDX-master, auto miibus1: on arswitch0 ukphy1: PHY 1 on miibus1 ukphy1: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT-FDX, 1000baseT-FDX-master, auto miibus2: on arswitch0 ukphy2: PHY 2 on miibus2 ukphy2: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT-FDX, 1000baseT-FDX-master, auto miibus3: on arswitch0 ukphy3: PHY 3 on miibus3 ukphy3: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT-FDX, 1000baseT-FDX-master, auto etherswitch0: on arswitch0 mdio1: on arswitch0 mdioproxy1: on mdio1 apb0 at irq 4 on nexus0 uart0: <16550 or compatible> at mem 0x18020003-0x1802001a irq 3 on apb0 uart0: console (115200,n,8,1) gpio0: at mem 0x1804-0x18040fff irq 2 on apb0 gpio0: [GIANT-LOCKED] gpio0: function_set: 0x0 gpio0: function_clear: 0x0 gpio0: gpio pinmask=0xff gpioc0: on gpio0 gpiobus0: on gpio0 gpioled0: at pin(s) 2 on gpiobus0 ehci0: at mem 0x1b00-0x1bff irq 1 on nexus0 usbus0: set host controller mode usbus0: EHCI version 1.0 usbus0: set host controller mode usbus0 on ehci0 pcib0 at irq 0 on nexus0 pcib0: ar71xx_pci_attach: missing hint 'baseslot', default to AR71XX_PCI_BASE_SLOT pci0: on pcib0 ath0: irq 0 at device 17.0 on pci0 [ath] enabling AN_TOP2_FIXUP ath0: [HT] enabling HT modes ath0: [HT] 1 stream STBC receive enabled ath0: [HT] 1 stream STBC transmit enabled ath0: [HT] 2 RX streams; 2 TX streams ath0: AR9220 mac 128.2 RF5133 phy 13.0 ath0: 2GHz radio: 0x; 5GHz radio: 0x00c0 ath1: irq 1 at device 18.0 on pci0 [ath] enabling AN_TOP2_FIXUP ath1: [HT] enabling HT modes ath1: [HT] 1 stream STBC receive enabled ath1: [HT] 1 stream STBC transmit enabled ath1: [HT] 2 RX streams; 2 TX streams ath1: AR9220 mac 128.2 RF5133 phy 13.0 ath1: 2GHz radio: 0x; 5GHz radio: 0x00c0 arge0: at mem 0x1900-0x19000fff irq 2 on nexus0 arge0: arge_attach: overriding MII mode to 'RGMII' miiproxy0: on arge0 miiproxy0: attached to target mdio1 arge0: finishing attachment, phymask 0010, proxy set miibus4: on miiproxy0 ukphy4: PHY 4 on miibus4 ukphy4: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT-FDX, 1000baseT-FDX-master, auto arge0: Ethernet address: 62:73:64:c5:94:0b arge1: at mem 0x1a00-0x1a000fff irq 3 on nexus0 arge1: arge_attach: overriding MII mode to 'RGMII' arge1: finishing attachment, phymask , proxy null arge1: Ethernet address: 62:73:64:94:c2:8e spi0: at mem 0x1f00-0x1f0f on nexus0 spibus0: on spi0 mx25l0: at cs 0 on spibus0 mx25l0: mx25ll128, sector 65536 bytes, 256 sectors ar71xx_wdog0: on nexus0 Timecounters tick every 1.000 msec arswitch0port1: link state changed to DOWN arswitch0port2: link state
svn commit: r270774 - head/share/misc
Author: alonso (ports committer) Date: Thu Aug 28 23:32:56 2014 New Revision: 270774 URL: http://svnweb.freebsd.org/changeset/base/270774 Log: Add Alonso Schaich to ports developers. Mentors: makc@, rakuco@ Approved by: rakuco (mentor) Modified: head/share/misc/committers-ports.dot Modified: head/share/misc/committers-ports.dot == --- head/share/misc/committers-ports.dotThu Aug 28 22:52:20 2014 (r270773) +++ head/share/misc/committers-ports.dotThu Aug 28 23:32:56 2014 (r270774) @@ -49,6 +49,7 @@ ale [label="Alex Dupre\n...@freebsd.org\ alepulver [label="Alejandro Pulver\nalepul...@freebsd.org\n2006/04/01"] alexbl [label="Alexander Botero-Lowry\nale...@freebsd.org\n2006/09/11"] alexey [label="Alexey Degtyarev\nale...@freebsd.org\n2013/11/09"] +alonso [label="Alonso Schaich\nalo...@freebsd.org\n2014/08/14"] amdmi3 [label="Dmitry Marakasov\namd...@freebsd.org\n2008/06/19"] anray [label="Andrey Slusar\nan...@freebsd.org\n2005/12/11"] antoine [label="Antoine Brodin\nanto...@freebsd.org\n2013/04/03"] @@ -420,6 +421,7 @@ marcus -> jmallett marino -> robak +makc -> alonso makc -> bf makc -> jhale makc -> rakuco @@ -493,6 +495,8 @@ philip -> koitsu rafan -> chinsan +rakuco -> alonso + rene -> bar rene -> crees rene -> jgh ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r270759 - in head/sys: cddl/compat/opensolaris/kern cddl/compat/opensolaris/sys cddl/contrib/opensolaris/uts/common/fs/zfs vm
On Thursday 28 August 2014 17:30:17 Alan Cox wrote: > On 08/28/2014 16:15, Matthew D. Fuller wrote: > > On Thu, Aug 28, 2014 at 10:11:39PM +0100 I heard the voice of > > > > Steven Hartland, and lo! it spake thus: > >> Its very likely applicable to stable/9 although I've never used 9 > >> myself, we jumped from 9 direct to 10. > > > > This is actually hitting two different issues from the two bugs: > > > > - 191510 is about "ARC isn't greedy enough" on huge-memory machines, > > > > and from the osreldate that bug was filed on 9.2, so presumably is > > applicable. > > > > - 187594 is about "ARC is too greedy" (probably mostly on not-so-huge > > > > machines) and starves/drives the rest of the system into swap. That > > I believe came about as a result of some unrelated change in the > > 10.x stream that upset the previous balance between ARC and the rest > > of the VM, so isn't a problem on 9.x. > > 10.0 had a bug in the page daemon that was fixed in 10-STABLE about > three months ago (r265945). The ARC was not the only thing affected by > this bug. I'm concerned about potential unintended consequences of this change. Before, arc reclaim was driven by vm_paging_needed(), which was: vm_paging_needed(void) { return (vm_cnt.v_free_count + vm_cnt.v_cache_count < vm_pageout_wakeup_thresh); } Now it's ignoring the v_cache_count and looking exclusively at v_free_count. "cache" pages are free pages that just happen to have known contents. If I read this change right, zfs arc will now discard checksummed cache pages to make room for non-checksummed pages: + if (kmem_free_count() < zfs_arc_free_target) { + return (1); + } ... +kmem_free_count(void) +{ + return (vm_cnt.v_free_count); +} This seems like a pretty substantial behavior change. I'm concerned that it doesn't appear to count all the forms of "free" pages. I haven't seen the problems with the over-aggressive ARC since the page daemon bug was fixed. It's been working fine under pretty abusive loads in the freebsd cluster after that fix. (I should know better than to fire a reply off before full fact checking, but this commit worries me..) -- Peter Wemm - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com; KI6FJV UTF-8: for when a ' or ... just won\342\200\231t do\342\200\246 signature.asc Description: This is a digitally signed message part.
svn commit: r270773 - head/sys/dev/ixl
Author: jfv Date: Thu Aug 28 22:52:20 2014 New Revision: 270773 URL: http://svnweb.freebsd.org/changeset/base/270773 Log: Remove the DEV_NETMAP code from the ixl drivers, it was a placeholder and not yet ready to be defined, and its causing build errors. MFC after:3 days Modified: head/sys/dev/ixl/if_ixl.c head/sys/dev/ixl/ixl.h head/sys/dev/ixl/ixl_txrx.c Modified: head/sys/dev/ixl/if_ixl.c == --- head/sys/dev/ixl/if_ixl.c Thu Aug 28 21:45:07 2014(r270772) +++ head/sys/dev/ixl/if_ixl.c Thu Aug 28 22:52:20 2014(r270773) @@ -276,10 +276,6 @@ int ixl_atr_rate = 20; TUNABLE_INT("hw.ixl.atr_rate", &ixl_atr_rate); #endif -#ifdef DEV_NETMAP -#include -#endif /* DEV_NETMAP */ - static char *ixl_fc_string[6] = { "None", "Rx", @@ -652,10 +648,6 @@ ixl_attach(device_t dev) vsi->vlan_detach = EVENTHANDLER_REGISTER(vlan_unconfig, ixl_unregister_vlan, vsi, EVENTHANDLER_PRI_FIRST); -#ifdef DEV_NETMAP - ixl_netmap_attach(pf); -#endif /* DEV_NETMAP */ - INIT_DEBUGOUT("ixl_attach: end"); return (0); @@ -733,10 +725,6 @@ ixl_detach(device_t dev) ether_ifdetach(vsi->ifp); callout_drain(&pf->timer); -#ifdef DEV_NETMAP - netmap_detach(vsi->ifp); -#endif /* DEV_NETMAP */ - ixl_free_pci_resources(pf); bus_generic_detach(dev); if_free(vsi->ifp); @@ -2552,12 +2540,6 @@ ixl_initialize_vsi(struct ixl_vsi *vsi) rctx.tphdata_ena = 0; rctx.tphhead_ena = 0; rctx.lrxqthresh = 2; -#ifdef DEV_NETMAP - /* "CRC strip in netmap is conditional" */ - if (vsi->ifp->if_capenable & IFCAP_NETMAP && !ixl_crcstrip) - rctx.crcstrip = 0; - else -#endif /* DEV_NETMAP */ rctx.crcstrip = 1; rctx.l2tsel = 1; rctx.showiv = 1; @@ -2581,21 +2563,6 @@ ixl_initialize_vsi(struct ixl_vsi *vsi) break; } wr32(vsi->hw, I40E_QRX_TAIL(que->me), 0); -#ifdef DEV_NETMAP - /* TODO appropriately comment -* Code based on netmap code in ixgbe_init_locked() -* Messes with what the software sets as queue -* descriptor tail in hardware. -*/ - if (vsi->ifp->if_capenable & IFCAP_NETMAP) - { - struct netmap_adapter *na = NA(vsi->ifp); - struct netmap_kring *kring = &na->rx_rings[que->me]; - int t = na->num_rx_desc - 1 - kring->nr_hwavail; - - wr32(vsi->hw, I40E_QRX_TAIL(que->me), t); - } else -#endif /* DEV_NETMAP */ wr32(vsi->hw, I40E_QRX_TAIL(que->me), que->num_desc - 1); } return (err); Modified: head/sys/dev/ixl/ixl.h == --- head/sys/dev/ixl/ixl.h Thu Aug 28 21:45:07 2014(r270772) +++ head/sys/dev/ixl/ixl.h Thu Aug 28 22:52:20 2014(r270773) @@ -295,9 +295,6 @@ struct ixl_rx_buf { struct mbuf *fmp; bus_dmamap_thmap; bus_dmamap_tpmap; -#ifdef DEV_NETMAP - u64 addr; -#endif }; /* Modified: head/sys/dev/ixl/ixl_txrx.c == --- head/sys/dev/ixl/ixl_txrx.c Thu Aug 28 21:45:07 2014(r270772) +++ head/sys/dev/ixl/ixl_txrx.c Thu Aug 28 22:52:20 2014(r270773) @@ -454,17 +454,9 @@ ixl_init_tx_ring(struct ixl_queue *que) { struct tx_ring *txr = &que->txr; struct ixl_tx_buf *buf; -#ifdef DEV_NETMAP - struct ixl_vsi *vsi = que->vsi; - struct netmap_adapter *na = NA(vsi->ifp); - struct netmap_slot *slot; -#endif /* DEV_NETMAP */ /* Clear the old ring contents */ IXL_TX_LOCK(txr); -#ifdef DEV_NETMAP - slot = netmap_reset(na, NR_TX, que->me, 0); -#endif bzero((void *)txr->base, (sizeof(struct i40e_tx_desc)) * que->num_desc); @@ -488,13 +480,6 @@ ixl_init_tx_ring(struct ixl_queue *que) m_freem(buf->m_head); buf->m_head = NULL; } -#ifdef DEV_NETMAP - if (slot) - { - int si = netmap_idx_n2k(&na->tx_rings[que->me], i); - netmap_load_map(txr->tag, buf->map, NMB(slot + si)); - } -#endif /* Clear the EOP index */ buf->eop_index = -1; } @@ -573,9 +558,13 @@ ixl_tx_setup_offload(struct ixl_queue *q struct mbuf *mp, u32 *cmd, u32 *off) { struct ether_vlan_header*eh; +#ifdef INET struct ip *ip = NULL; +#endif struct tcphdr *th = NULL; +
Re: svn commit: r270759 - in head/sys: cddl/compat/opensolaris/kern cddl/compat/opensolaris/sys cddl/contrib/opensolaris/uts/common/fs/zfs vm
On 08/28/2014 16:15, Matthew D. Fuller wrote: > On Thu, Aug 28, 2014 at 10:11:39PM +0100 I heard the voice of > Steven Hartland, and lo! it spake thus: >> Its very likely applicable to stable/9 although I've never used 9 >> myself, we jumped from 9 direct to 10. > This is actually hitting two different issues from the two bugs: > > - 191510 is about "ARC isn't greedy enough" on huge-memory machines, > and from the osreldate that bug was filed on 9.2, so presumably is > applicable. > > - 187594 is about "ARC is too greedy" (probably mostly on not-so-huge > machines) and starves/drives the rest of the system into swap. That > I believe came about as a result of some unrelated change in the > 10.x stream that upset the previous balance between ARC and the rest > of the VM, so isn't a problem on 9.x. 10.0 had a bug in the page daemon that was fixed in 10-STABLE about three months ago (r265945). The ARC was not the only thing affected by this bug. ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r270755 - in head/sys: conf modules
On 28 Aug 2014, at 22:08 , Bjoern A. Zeeb wrote: > > On 28 Aug 2014, at 17:41 , Rui Paulo wrote: > >> On Aug 28, 2014, at 10:40, Jack F Vogel wrote: >>> >>> Author: jfv >>> Date: Thu Aug 28 17:40:19 2014 >>> New Revision: 270755 >>> URL: http://svnweb.freebsd.org/changeset/base/270755 >>> >>> Log: >>> Add XL710 device entries to NOTES, and directories to the module >>> Makefile so they will be built. >>> >>> MFC after: 1 day >> >> The minimum MFC timer is 3 days. > > > And it’s needed given sparc64 LINT fails with: > > /scratch/tmp/bz/head.svn/sys/dev/ixl/if_ixl.c:280:38: error: > dev/netmap/if_ixl_netmap.h: No such file or directory > > and pc98 LINT fails with: > > /scratch/tmp/bz/head.svn/sys/dev/ixl/if_ixl.c:280:10: fatal error: > 'dev/netmap/if_ixl_netmap.h' file not found > #include > ^ > 1 error generated. > /scratch/tmp/bz/head.svn/sys/dev/ixl/ixl_txrx.c:809:5: warning: 'NETMAP_API' > is not defined, evaluates to 0 [-Wundef] > #if NETMAP_API < 4 >^ > /scratch/tmp/bz/head.svn/sys/dev/ixl/ixl_txrx.c:1420:5: warning: 'NETMAP_API' > is not defined, evaluates to 0 [-Wundef] > #if NETMAP_API < 4 >^ > 2 warnings generated. > > > and I am waiting for more to come still .. . . . I guess putting it in > sys/conf/NOTES wasn’t the right decision. well maybe that’s not even the problem. most i386 LINT kernels are failing now and the NOINET and NOIP ones have a long list of warnings/errors, while LINT, VIMAGE, and NOINET6 are failing equally to pc98. I’ll refrain from posting more errors. Please fix and do a universe test build. — Bjoern A. Zeeb "Come on. Learn, goddamn it.", WarGames, 1983 ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r270755 - in head/sys: conf modules
On 28 Aug 2014, at 17:41 , Rui Paulo wrote: > On Aug 28, 2014, at 10:40, Jack F Vogel wrote: >> >> Author: jfv >> Date: Thu Aug 28 17:40:19 2014 >> New Revision: 270755 >> URL: http://svnweb.freebsd.org/changeset/base/270755 >> >> Log: >> Add XL710 device entries to NOTES, and directories to the module >> Makefile so they will be built. >> >> MFC after: 1 day > > The minimum MFC timer is 3 days. And it’s needed given sparc64 LINT fails with: /scratch/tmp/bz/head.svn/sys/dev/ixl/if_ixl.c:280:38: error: dev/netmap/if_ixl_netmap.h: No such file or directory and pc98 LINT fails with: /scratch/tmp/bz/head.svn/sys/dev/ixl/if_ixl.c:280:10: fatal error: 'dev/netmap/if_ixl_netmap.h' file not found #include ^ 1 error generated. /scratch/tmp/bz/head.svn/sys/dev/ixl/ixl_txrx.c:809:5: warning: 'NETMAP_API' is not defined, evaluates to 0 [-Wundef] #if NETMAP_API < 4 ^ /scratch/tmp/bz/head.svn/sys/dev/ixl/ixl_txrx.c:1420:5: warning: 'NETMAP_API' is not defined, evaluates to 0 [-Wundef] #if NETMAP_API < 4 ^ 2 warnings generated. and I am waiting for more to come still .. . . . I guess putting it in sys/conf/NOTES wasn’t the right decision. — Bjoern A. Zeeb "Come on. Learn, goddamn it.", WarGames, 1983 ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r270772 - head/sys/dev/ixl
Author: jfv Date: Thu Aug 28 21:45:07 2014 New Revision: 270772 URL: http://svnweb.freebsd.org/changeset/base/270772 Log: Some corrections, reformating, and additional info about the VF driver in the README. MFC after: 1 day Modified: head/sys/dev/ixl/README Modified: head/sys/dev/ixl/README == --- head/sys/dev/ixl/README Thu Aug 28 21:30:39 2014(r270771) +++ head/sys/dev/ixl/README Thu Aug 28 21:45:07 2014(r270772) @@ -1,9 +1,10 @@ -ixl FreeBSD* Base Driver for the Intel� XL710 Ethernet Controller Family + ixl FreeBSD* Base Driver and ixlv VF Driver for the +Intel XL710 Ethernet Controller Family /*$FreeBSD$*/ -July 21, 2014 +August 26, 2014 Contents @@ -11,6 +12,7 @@ Contents - Overview - Supported Adapters +- The VF Driver - Building and Installation - Additional Configurations - Known Limitations @@ -19,15 +21,21 @@ Contents Overview -This file describes the IXL FreeBSD* Base driver for the XL710 Ethernet Family of Adapters. The Driver has been developed for use with FreeBSD 10.0 or later, but should be compatible with any supported release. - -For questions related to hardware requirements, refer to the documentation supplied with your Intel XL710 adapter. All hardware requirements listed apply for use with FreeBSD. +This file describes the IXL FreeBSD* Base driver and the IXLV VF Driver +for the XL710 Ethernet Family of Adapters. The Driver has been developed +for use with FreeBSD 10.0 or later, but should be compatible with any +supported release. + +For questions related to hardware requirements, refer to the documentation +supplied with your Intel XL710 adapter. All hardware requirements listed +apply for use with FreeBSD. Supported Adapters == -The driver in this release is compatible with XL710 and X710-based Intel Ethernet Network Connections. +The drivers in this release are compatible with XL710 and X710-based +Intel Ethernet Network Connections. SFP+ Devices with Pluggable Optics @@ -49,18 +57,45 @@ QSFP+ Modules Intel TRIPLE RATE 1G/10G/40G QSFP+ LR (bailed)E40GQSFPLR QSFP+ 1G speed is not supported on XL710 based devices. -X710/XL710 Based SFP+ adapters support all passive and active limiting direct attach cables that comply with SFF-8431 v4.1 and SFF-8472 v10.4 specifications. +X710/XL710 Based SFP+ adapters support all passive and active limiting direct +attach cables that comply with SFF-8431 v4.1 and SFF-8472 v10.4 specifications. +The VF Driver +== +The VF driver is normally used in a virtualized environment where a host +driver manages SRIOV, and provides a VF device to the guest. With this +first release the only host environment tested was using Linux QEMU/KVM. +Support is planned for Xen and VMWare hosts at a later time. + +In the FreeBSD guest the IXLV driver would be loaded and will function +using the VF device assigned to it. + +The VF driver provides most of the same functionality as the CORE driver, +but is actually a slave to the Host, access to many controls are actually +accomplished by a request to the Host via what is called the "Admin queue". +These are startup and initialization events however, once in operation +the device is self-contained and should achieve near native performance. + +Some notable limitations of the VF environment: for security reasons +the driver is never permitted to be promiscuous, therefore a tcpdump +will not behave the same with the interface. Second, media info is not +available from the PF, so it will always appear as auto. -Building and Installation +Tarball Building and Installation = -NOTE: You must have kernel sources installed to compile the driver module. +NOTE: You must have kernel sources installed to compile the driver tarball. + +These instructions assume a standalone driver tarball, building the driver +already in the kernel source is simply a matter of adding the device entry +to the kernel config file, or building in the ixl or ixlv module directory. In the instructions below, x.x.x is the driver version -as indicated in thename of the driver tar. +as indicated in the name of the driver tarball. The example is +for ixl, the same procedure applies for ixlv. -1. Move the base driver tar file to the directory of your choice. For example, use /home/username/ixl or /usr/local/src/ixl. +1. Move the base driver tar file to the directory of your choice. + For example, use /home/username/ixl or /usr/local/src/ixl. 2. Untar/unzip the archive: tar xfz ixl-x.x.x.tar.gz @@ -76,7 +111,9 @@ as indicated in thename of the driver ta 5. To assign an IP address to the interface, enter the following: ifconfig ixl -6. Verify that the interface works. Enter the followi
svn commit: r270771 - head/bin/dd
Author: imp Date: Thu Aug 28 21:30:39 2014 New Revision: 270771 URL: http://svnweb.freebsd.org/changeset/base/270771 Log: Add canonical population of a disk / thumb drive from an image example. Modified: head/bin/dd/dd.1 Modified: head/bin/dd/dd.1 == --- head/bin/dd/dd.1Thu Aug 28 21:27:37 2014(r270770) +++ head/bin/dd/dd.1Thu Aug 28 21:30:39 2014(r270771) @@ -408,6 +408,11 @@ To create an image of a Mode-1 CD-ROM, w for data CD-ROM disks, use a block size of 2048 bytes: .Pp .Dl "dd if=/dev/acd0 of=filename.iso bs=2048" +.Pp +Write a filesystem image to a memory stick, padding the end with zeros, +if necessary, to a 1MiB boundary: +.Pp +.Dl "dd if=memstick.img of=/dev/da0 bs=1m conv=noerror,sync" .Sh SEE ALSO .Xr cp 1 , .Xr mt 1 , ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r270759 - in head/sys: cddl/compat/opensolaris/kern cddl/compat/opensolaris/sys cddl/contrib/opensolaris/uts/common/fs/zfs vm
On Thu, 28 Aug 2014, Steven Hartland wrote: > > Thank you, and also Karl and Devin for this work! > > > > Is this change applicable to stable/9? I suppose, pretty large base of users > > could benefit from this. > > Its very likely applicable to stable/9 although I've never used 9 myself, > we jumped from 9 direct to 10. > > My target for this is to make the cutoff for 10.1 freeze. > > I'll MFC to 9 and possibly 8 as well at that time if relavent. No rush for other stable branches, surely; also, we're at the EoL (EoS at least) for stable/8 -- but if the changeset is not too harsh I see no reason not to merge it down there. As I @work have some loaded machines with ZFS base on at least 9 (while not really memory-loaded, not more than 32G -- but sometimes rather heavy loaded with userbase apps), I would be glad to test changesets if it's feasible. Thanks again! -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r270759 - in head/sys: cddl/compat/opensolaris/kern cddl/compat/opensolaris/sys cddl/contrib/opensolaris/uts/common/fs/zfs vm
On Thu, Aug 28, 2014 at 10:11:39PM +0100 I heard the voice of Steven Hartland, and lo! it spake thus: > > Its very likely applicable to stable/9 although I've never used 9 > myself, we jumped from 9 direct to 10. This is actually hitting two different issues from the two bugs: - 191510 is about "ARC isn't greedy enough" on huge-memory machines, and from the osreldate that bug was filed on 9.2, so presumably is applicable. - 187594 is about "ARC is too greedy" (probably mostly on not-so-huge machines) and starves/drives the rest of the system into swap. That I believe came about as a result of some unrelated change in the 10.x stream that upset the previous balance between ARC and the rest of the VM, so isn't a problem on 9.x. -- Matthew Fuller (MF4839) | fulle...@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r270759 - in head/sys: cddl/compat/opensolaris/kern cddl/compat/opensolaris/sys cddl/contrib/opensolaris/uts/common/fs/zfs vm
- Original Message - From: "Dmitry Morozovsky" Steve, On Thu, 28 Aug 2014, Steven Hartland wrote: Author: smh Date: Thu Aug 28 19:50:08 2014 New Revision: 270759 URL: http://svnweb.freebsd.org/changeset/base/270759 Log: Refactor ZFS ARC reclaim logic to be more VM cooperative [snip] Credit to Karl Denninger for the original patch on which this update was based. Tested by: dteske MFC after: 1 week Relnotes: yes Sponsored by: Multiplay Thank you, and also Karl and Devin for this work! Is this change applicable to stable/9? I suppose, pretty large base of users could benefit from this. Its very likely applicable to stable/9 although I've never used 9 myself, we jumped from 9 direct to 10. My target for this is to make the cutoff for 10.1 freeze. I'll MFC to 9 and possibly 8 as well at that time if relavent. Regards Steve ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r270759 - in head/sys: cddl/compat/opensolaris/kern cddl/compat/opensolaris/sys cddl/contrib/opensolaris/uts/common/fs/zfs vm
Steve, On Thu, 28 Aug 2014, Steven Hartland wrote: > Author: smh > Date: Thu Aug 28 19:50:08 2014 > New Revision: 270759 > URL: http://svnweb.freebsd.org/changeset/base/270759 > > Log: > Refactor ZFS ARC reclaim logic to be more VM cooperative [snip] > Credit to Karl Denninger for the original patch on which this update was > based. > Tested by: dteske > MFC after: 1 week > Relnotes: yes > Sponsored by: Multiplay Thank you, and also Karl and Devin for this work! Is this change applicable to stable/9? I suppose, pretty large base of users could benefit from this. -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r270759 - in head/sys: cddl/compat/opensolaris/kern cddl/compat/opensolaris/sys cddl/contrib/opensolaris/uts/common/fs/zfs vm
Author: smh Date: Thu Aug 28 19:50:08 2014 New Revision: 270759 URL: http://svnweb.freebsd.org/changeset/base/270759 Log: Refactor ZFS ARC reclaim logic to be more VM cooperative Prior to this change we triggered ARC reclaim when kmem usage passed 3/4 of the total available, as indicated by vmem_size(kmem_arena, VMEM_ALLOC). This could lead large amounts of unused RAM e.g. on a 192GB machine with ARC the only major RAM consumer, 40GB of RAM would remain unused. The old method has also been seen to result in extreme RAM usage under certain loads, causing poor performance and stalls. We now trigger ARC reclaim when the number of free pages drops below the value defined by the new sysctl vfs.zfs.arc_free_target, which defaults to the value of vm.v_free_target. Credit to Karl Denninger for the original patch on which this update was based. PR: 191510 and 187594 Tested by:dteske MFC after:1 week Relnotes: yes Sponsored by: Multiplay Modified: head/sys/cddl/compat/opensolaris/kern/opensolaris_kmem.c head/sys/cddl/compat/opensolaris/sys/kmem.h head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c head/sys/vm/vm_pageout.c Modified: head/sys/cddl/compat/opensolaris/kern/opensolaris_kmem.c == --- head/sys/cddl/compat/opensolaris/kern/opensolaris_kmem.cThu Aug 28 18:59:39 2014(r270758) +++ head/sys/cddl/compat/opensolaris/kern/opensolaris_kmem.cThu Aug 28 19:50:08 2014(r270759) @@ -126,18 +126,47 @@ kmem_size_init(void *unused __unused) } SYSINIT(kmem_size_init, SI_SUB_KMEM, SI_ORDER_ANY, kmem_size_init, NULL); -uint64_t -kmem_size(void) +/* + * The return values from kmem_free_* are only valid once the pagedaemon + * has been initialised, before then they return 0. + * + * To ensure the returns are valid the caller can use a SYSINIT with + * subsystem set to SI_SUB_KTHREAD_PAGE and an order of at least + * SI_ORDER_SECOND. + */ +u_int +kmem_free_target(void) { - return (kmem_size_val); + return (vm_cnt.v_free_target); +} + +u_int +kmem_free_min(void) +{ + + return (vm_cnt.v_free_min); +} + +u_int +kmem_free_count(void) +{ + + return (vm_cnt.v_free_count); +} + +u_int +kmem_page_count(void) +{ + + return (vm_cnt.v_page_count); } uint64_t -kmem_used(void) +kmem_size(void) { - return (vmem_size(kmem_arena, VMEM_ALLOC)); + return (kmem_size_val); } static int Modified: head/sys/cddl/compat/opensolaris/sys/kmem.h == --- head/sys/cddl/compat/opensolaris/sys/kmem.h Thu Aug 28 18:59:39 2014 (r270758) +++ head/sys/cddl/compat/opensolaris/sys/kmem.h Thu Aug 28 19:50:08 2014 (r270759) @@ -66,7 +66,16 @@ typedef struct kmem_cache { void *zfs_kmem_alloc(size_t size, int kmflags); void zfs_kmem_free(void *buf, size_t size); uint64_t kmem_size(void); -uint64_t kmem_used(void); +u_int kmem_page_count(void); + +/* + * The return values from kmem_free_* are only valid once the pagedaemon + * has been initialised, before then they return 0. + */ +u_int kmem_free_count(void); +u_int kmem_free_target(void); +u_int kmem_free_min(void); + kmem_cache_t *kmem_cache_create(char *name, size_t bufsize, size_t align, int (*constructor)(void *, void *, int), void (*destructor)(void *, void *), void (*reclaim)(void *) __unused, void *private, vmem_t *vmp, int cflags); Modified: head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c == --- head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c Thu Aug 28 18:59:39 2014(r270758) +++ head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c Thu Aug 28 19:50:08 2014(r270759) @@ -193,9 +193,6 @@ extern int zfs_prefetch_disable; */ static boolean_t arc_warm; -/* - * These tunables are for performance analysis. - */ uint64_t zfs_arc_max; uint64_t zfs_arc_min; uint64_t zfs_arc_meta_limit = 0; @@ -204,6 +201,20 @@ int zfs_arc_shrink_shift = 0; int zfs_arc_p_min_shift = 0; int zfs_disable_dup_eviction = 0; uint64_t zfs_arc_average_blocksize = 8 * 1024; /* 8KB */ +u_int zfs_arc_free_target = (1 << 19); /* default before pagedaemon init only */ + +static int sysctl_vfs_zfs_arc_free_target(SYSCTL_HANDLER_ARGS); + +#ifdef _KERNEL +static void +arc_free_target_init(void *unused __unused) +{ + + zfs_arc_free_target = kmem_free_target(); +} +SYSINIT(arc_free_target_init, SI_SUB_KTHREAD_PAGE, SI_ORDER_ANY, +arc_free_target_init, NULL); +#endif TUNABLE_QUAD("vfs.zfs.arc_meta_limit", &zfs_arc_meta_limit); SYSCTL_DECL(_vfs_zfs); @@ -214,6 +225,35 @@ SYSCTL_UQUAD(_vfs_zfs, OID_AUTO, arc_min SYSCTL_UQUAD(_vfs_zfs, OID_AUTO, arc_average_blocksize, CTLFLAG_RDTUN, &zfs_arc_average_blocksize, 0, "ARC average blocksize"); +/* + * We
svn commit: r270758 - head/sys/dev/ixl
Author: smh Date: Thu Aug 28 18:59:39 2014 New Revision: 270758 URL: http://svnweb.freebsd.org/changeset/base/270758 Log: Fix build breakage caused by ixl driver Fix missing includes and invalid vars in ixl / ixlv driver added by r270346 which caused build failures for GENERIC kernel after it was made default by r270755. X-MFC-With: r270346 / r270755 Sponsored by: Multiplay Modified: head/sys/dev/ixl/i40e_osdep.h head/sys/dev/ixl/if_ixlv.c head/sys/dev/ixl/ixl.h Modified: head/sys/dev/ixl/i40e_osdep.h == --- head/sys/dev/ixl/i40e_osdep.h Thu Aug 28 18:33:42 2014 (r270757) +++ head/sys/dev/ixl/i40e_osdep.h Thu Aug 28 18:59:39 2014 (r270758) @@ -191,7 +191,7 @@ rd32_osdep(struct i40e_osdep *osdep, uin KASSERT(reg < osdep->mem_bus_space_size, ("ixl: register offset %#jx too large (max is %#jx", - (uintmax_t)a, (uintmax_t)osdep->mem_bus_space_size)); + (uintmax_t)reg, (uintmax_t)osdep->mem_bus_space_size)); return (bus_space_read_4(osdep->mem_bus_space_tag, osdep->mem_bus_space_handle, reg)); @@ -203,7 +203,7 @@ wr32_osdep(struct i40e_osdep *osdep, uin KASSERT(reg < osdep->mem_bus_space_size, ("ixl: register offset %#jx too large (max is %#jx", - (uintmax_t)a, (uintmax_t)osdep->mem_bus_space_size)); + (uintmax_t)reg, (uintmax_t)osdep->mem_bus_space_size)); bus_space_write_4(osdep->mem_bus_space_tag, osdep->mem_bus_space_handle, reg, value); Modified: head/sys/dev/ixl/if_ixlv.c == --- head/sys/dev/ixl/if_ixlv.c Thu Aug 28 18:33:42 2014(r270757) +++ head/sys/dev/ixl/if_ixlv.c Thu Aug 28 18:59:39 2014(r270758) @@ -2311,7 +2311,7 @@ ixlv_update_link_status(struct ixlv_sc * static void ixlv_stop(struct ixlv_sc *sc) { - mtx_assert(&sc->sc_mtx, MA_OWNED); + mtx_assert(&sc->mtx, MA_OWNED); INIT_DBG_IF(&sc->vsi->ifp, "begin"); Modified: head/sys/dev/ixl/ixl.h == --- head/sys/dev/ixl/ixl.h Thu Aug 28 18:33:42 2014(r270757) +++ head/sys/dev/ixl/ixl.h Thu Aug 28 18:59:39 2014(r270758) @@ -47,8 +47,10 @@ #include #include #include +#include #include +#include #include #include #include ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r269814 - head/sys/dev/xen/blkfront
On 28.08.2014 21:45, John-Mark Gurney wrote: > Alexander Motin wrote this message on Thu, Aug 28, 2014 at 21:23 +0300: >> Hi, Roger. >> >> It looks to me like this commit does not work as it should. I got >> problem when I just tried `newfs /dev/ada0 ; mount /dev/ada0 /mnt`. >> Somehow newfs does not produce valid filesystem. Problem is reliably >> repeatable and reverting this commit fixes it. >> >> I found at least one possible cause there: If original data buffer is >> unmapped, misaligned and not physically contiguous, then present x86 >> bus_dmamap_load_bio() implementation will process each physically >> contiguous segment separately. Due to the misalignment first and last >> physical segments may have size not multiple to 512 bytes. Since each >> segment processed separately, they are not joined together, and >> xbd_queue_cb() is getting segments not multiple to 512 bytes. Attempt to >> convert them to exact number of sectors in the driver cause data corruption. > > Are you sure this isn't a problem w/ the tag not properly specifying > the correct alignement? I don't know how to specify it stronger then this: error = bus_dma_tag_create( bus_get_dma_tag(sc->xbd_dev), /* parent */ 512, PAGE_SIZE, /* algnmnt, boundary */ BUS_SPACE_MAXADDR, /* lowaddr */ BUS_SPACE_MAXADDR, /* highaddr */ NULL, NULL, /* filter, filterarg */ sc->xbd_max_request_size, sc->xbd_max_request_segments, PAGE_SIZE, /* maxsegsize */ BUS_DMA_ALLOCNOW, /* flags */ busdma_lock_mutex, /* lockfunc */ &sc->xbd_io_lock, /* lockarg */ &sc->xbd_io_dmat); > Also, I don't think there is a way for busdma > to say that you MUST have a segment be a multiple of 512, though you > could use a 512 boundary, but that would force all segments to only be > 512 bytes... As I understand, that is mandatory requirement for this "hardware". Alike 4K alignment requirement also exist at least for SDHCI, and IIRC UHCI/OHCI hardware. Even AHCI requires both segment addresses and lengths to be even. I may be wrong, but I think it is quite likely that hardware that requires segment address alignment quite likely will have the same requirements for segments length. >> This is a bug of the busdma code, and until it is fixed I don't see >> solution other then temporary reverting this commit. >> >> On 11.08.2014 18:37, Roger Pau Monné wrote: >>> Author: royger >>> Date: Mon Aug 11 15:37:02 2014 >>> New Revision: 269814 >>> URL: http://svnweb.freebsd.org/changeset/base/269814 >>> >>> Log: >>> blkfront: add support for unmapped IO >>> >>> Using unmapped IO is really beneficial when running inside of a VM, >>> since it avoids IPIs to other vCPUs in order to invalidate the >>> mappings. >>> >>> This patch adds unmapped IO support to blkfront. The following tests >>> results have been obtained when running on a Xen host without HAP: >>> >>> PVHVM >>>3165.84 real 6354.17 user 4483.32 sys >>> PVHVM with unmapped IO >>>2099.46 real 4624.52 user 2967.38 sys >>> >>> This is because when running using shadow page tables TLB flushes and >>> range invalidations are much more expensive, so using unmapped IO >>> provides a very important performance boost. >>> >>> Sponsored by: Citrix Systems R&D >>> Tested by:robak >>> MFC after:1 week >>> PR: 191173 >>> >>> dev/xen/blkfront/blkfront.c: >>>- Add and announce support for unmapped IO. >>> >>> Modified: >>> head/sys/dev/xen/blkfront/blkfront.c >>> >>> Modified: head/sys/dev/xen/blkfront/blkfront.c >>> == >>> --- head/sys/dev/xen/blkfront/blkfront.cMon Aug 11 15:06:07 2014 >>> (r269813) >>> +++ head/sys/dev/xen/blkfront/blkfront.cMon Aug 11 15:37:02 2014 >>> (r269814) >>> @@ -272,8 +272,12 @@ xbd_queue_request(struct xbd_softc *sc, >>> { >>> int error; >>> >>> - error = bus_dmamap_load(sc->xbd_io_dmat, cm->cm_map, cm->cm_data, >>> - cm->cm_datalen, xbd_queue_cb, cm, 0); >>> + if (cm->cm_bp != NULL) >>> + error = bus_dmamap_load_bio(sc->xbd_io_dmat, cm->cm_map, >>> + cm->cm_bp, xbd_queue_cb, cm, 0); >>> + else >>> + error = bus_dmamap_load(sc->xbd_io_dmat, cm->cm_map, >>> + cm->cm_data, cm->cm_datalen, xbd_queue_cb, cm, 0); >>> if (error == EINPROGRESS) { >>> /* >>> * Maintain queuing order by freezing the queue. The next >>> @@ -333,8 +337,6 @@ xbd_bio_command(struct xbd_softc *sc) >>> } >>> >>> cm->cm_bp = bp; >>> - cm->cm_data = bp->bio_data; >>> - cm->cm_datalen = bp->bio_bcount; >>
Re: svn commit: r269814 - head/sys/dev/xen/blkfront
Alexander Motin wrote this message on Thu, Aug 28, 2014 at 21:23 +0300: > Hi, Roger. > > It looks to me like this commit does not work as it should. I got > problem when I just tried `newfs /dev/ada0 ; mount /dev/ada0 /mnt`. > Somehow newfs does not produce valid filesystem. Problem is reliably > repeatable and reverting this commit fixes it. > > I found at least one possible cause there: If original data buffer is > unmapped, misaligned and not physically contiguous, then present x86 > bus_dmamap_load_bio() implementation will process each physically > contiguous segment separately. Due to the misalignment first and last > physical segments may have size not multiple to 512 bytes. Since each > segment processed separately, they are not joined together, and > xbd_queue_cb() is getting segments not multiple to 512 bytes. Attempt to > convert them to exact number of sectors in the driver cause data corruption. Are you sure this isn't a problem w/ the tag not properly specifying the correct alignement? Also, I don't think there is a way for busdma to say that you MUST have a segment be a multiple of 512, though you could use a 512 boundary, but that would force all segments to only be 512 bytes... > This is a bug of the busdma code, and until it is fixed I don't see > solution other then temporary reverting this commit. > > On 11.08.2014 18:37, Roger Pau Monné wrote: > > Author: royger > > Date: Mon Aug 11 15:37:02 2014 > > New Revision: 269814 > > URL: http://svnweb.freebsd.org/changeset/base/269814 > > > > Log: > > blkfront: add support for unmapped IO > > > > Using unmapped IO is really beneficial when running inside of a VM, > > since it avoids IPIs to other vCPUs in order to invalidate the > > mappings. > > > > This patch adds unmapped IO support to blkfront. The following tests > > results have been obtained when running on a Xen host without HAP: > > > > PVHVM > >3165.84 real 6354.17 user 4483.32 sys > > PVHVM with unmapped IO > >2099.46 real 4624.52 user 2967.38 sys > > > > This is because when running using shadow page tables TLB flushes and > > range invalidations are much more expensive, so using unmapped IO > > provides a very important performance boost. > > > > Sponsored by: Citrix Systems R&D > > Tested by:robak > > MFC after:1 week > > PR: 191173 > > > > dev/xen/blkfront/blkfront.c: > >- Add and announce support for unmapped IO. > > > > Modified: > > head/sys/dev/xen/blkfront/blkfront.c > > > > Modified: head/sys/dev/xen/blkfront/blkfront.c > > == > > --- head/sys/dev/xen/blkfront/blkfront.cMon Aug 11 15:06:07 2014 > > (r269813) > > +++ head/sys/dev/xen/blkfront/blkfront.cMon Aug 11 15:37:02 2014 > > (r269814) > > @@ -272,8 +272,12 @@ xbd_queue_request(struct xbd_softc *sc, > > { > > int error; > > > > - error = bus_dmamap_load(sc->xbd_io_dmat, cm->cm_map, cm->cm_data, > > - cm->cm_datalen, xbd_queue_cb, cm, 0); > > + if (cm->cm_bp != NULL) > > + error = bus_dmamap_load_bio(sc->xbd_io_dmat, cm->cm_map, > > + cm->cm_bp, xbd_queue_cb, cm, 0); > > + else > > + error = bus_dmamap_load(sc->xbd_io_dmat, cm->cm_map, > > + cm->cm_data, cm->cm_datalen, xbd_queue_cb, cm, 0); > > if (error == EINPROGRESS) { > > /* > > * Maintain queuing order by freezing the queue. The next > > @@ -333,8 +337,6 @@ xbd_bio_command(struct xbd_softc *sc) > > } > > > > cm->cm_bp = bp; > > - cm->cm_data = bp->bio_data; > > - cm->cm_datalen = bp->bio_bcount; > > cm->cm_sector_number = (blkif_sector_t)bp->bio_pblkno; > > > > switch (bp->bio_cmd) { > > @@ -993,7 +995,7 @@ xbd_instance_create(struct xbd_softc *sc > > > > sc->xbd_disk->d_mediasize = sectors * sector_size; > > sc->xbd_disk->d_maxsize = sc->xbd_max_request_size; > > - sc->xbd_disk->d_flags = 0; > > + sc->xbd_disk->d_flags = DISKFLAG_UNMAPPED_BIO; > > if ((sc->xbd_flags & (XBDF_FLUSH|XBDF_BARRIER)) != 0) { > > sc->xbd_disk->d_flags |= DISKFLAG_CANFLUSHCACHE; > > device_printf(sc->xbd_dev, -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r270757 - head/contrib/binutils/ld/emultempl
Author: tijl Date: Thu Aug 28 18:33:42 2014 New Revision: 270757 URL: http://svnweb.freebsd.org/changeset/base/270757 Log: In r253839 the default behaviour of ld(1) was changed such that all libraries that need to be linked into an executable or library have to be listed on the command line explicitly. This commit fixes a bug in ld(1) where it would scan dependencies of the libraries on the command line and link them if needed if they were also found in ld.so.cache. The important bit of the patch is the initialisation of needed.by such that libraries found by scanning dependencies are marked as such and not used in the link. The patch is a backport of binutils git commit d5c8b1f8561426b41aa5330ed60f578178fe6be2 The author gave permission to use it under GPLv2 terms. PR: 192062 Exp-run by: antoine MFC after:1 week Modified: head/contrib/binutils/ld/emultempl/elf32.em Modified: head/contrib/binutils/ld/emultempl/elf32.em == --- head/contrib/binutils/ld/emultempl/elf32.em Thu Aug 28 18:11:05 2014 (r270756) +++ head/contrib/binutils/ld/emultempl/elf32.em Thu Aug 28 18:33:42 2014 (r270757) @@ -541,7 +541,8 @@ EOF #endif static bfd_boolean -gld${EMULATION_NAME}_check_ld_elf_hints (const char *name, int force) +gld${EMULATION_NAME}_check_ld_elf_hints (const struct bfd_link_needed_list *l, +int force) { static bfd_boolean initialized; static char *ld_elf_hints; @@ -584,10 +585,9 @@ gld${EMULATION_NAME}_check_ld_elf_hints if (ld_elf_hints == NULL) return FALSE; - needed.by = NULL; - needed.name = name; - return gld${EMULATION_NAME}_search_needed (ld_elf_hints, & needed, -force); + needed.by = l->by; + needed.name = l->name; + return gld${EMULATION_NAME}_search_needed (ld_elf_hints, &needed, force); } EOF # FreeBSD @@ -759,7 +759,8 @@ gld${EMULATION_NAME}_parse_ld_so_conf } static bfd_boolean -gld${EMULATION_NAME}_check_ld_so_conf (const char *name, int force) +gld${EMULATION_NAME}_check_ld_so_conf (const struct bfd_link_needed_list *l, + int force) { static bfd_boolean initialized; static char *ld_so_conf; @@ -794,8 +795,8 @@ gld${EMULATION_NAME}_check_ld_so_conf (c return FALSE; - needed.by = NULL; - needed.name = name; + needed.by = l->by; + needed.name = l->name; return gld${EMULATION_NAME}_search_needed (ld_so_conf, &needed, force); } @@ -1037,7 +1038,7 @@ if [ "x${USE_LIBPATH}" = xyes ] ; then case ${target} in *-*-freebsd* | *-*-dragonfly*) cat >>e${EMULATION_NAME}.c>e${EMULATION_NAME}.c
Re: svn commit: r269814 - head/sys/dev/xen/blkfront
Hi, Roger. It looks to me like this commit does not work as it should. I got problem when I just tried `newfs /dev/ada0 ; mount /dev/ada0 /mnt`. Somehow newfs does not produce valid filesystem. Problem is reliably repeatable and reverting this commit fixes it. I found at least one possible cause there: If original data buffer is unmapped, misaligned and not physically contiguous, then present x86 bus_dmamap_load_bio() implementation will process each physically contiguous segment separately. Due to the misalignment first and last physical segments may have size not multiple to 512 bytes. Since each segment processed separately, they are not joined together, and xbd_queue_cb() is getting segments not multiple to 512 bytes. Attempt to convert them to exact number of sectors in the driver cause data corruption. This is a bug of the busdma code, and until it is fixed I don't see solution other then temporary reverting this commit. On 11.08.2014 18:37, Roger Pau Monné wrote: > Author: royger > Date: Mon Aug 11 15:37:02 2014 > New Revision: 269814 > URL: http://svnweb.freebsd.org/changeset/base/269814 > > Log: > blkfront: add support for unmapped IO > > Using unmapped IO is really beneficial when running inside of a VM, > since it avoids IPIs to other vCPUs in order to invalidate the > mappings. > > This patch adds unmapped IO support to blkfront. The following tests > results have been obtained when running on a Xen host without HAP: > > PVHVM >3165.84 real 6354.17 user 4483.32 sys > PVHVM with unmapped IO >2099.46 real 4624.52 user 2967.38 sys > > This is because when running using shadow page tables TLB flushes and > range invalidations are much more expensive, so using unmapped IO > provides a very important performance boost. > > Sponsored by: Citrix Systems R&D > Tested by: robak > MFC after: 1 week > PR: 191173 > > dev/xen/blkfront/blkfront.c: >- Add and announce support for unmapped IO. > > Modified: > head/sys/dev/xen/blkfront/blkfront.c > > Modified: head/sys/dev/xen/blkfront/blkfront.c > == > --- head/sys/dev/xen/blkfront/blkfront.c Mon Aug 11 15:06:07 2014 > (r269813) > +++ head/sys/dev/xen/blkfront/blkfront.c Mon Aug 11 15:37:02 2014 > (r269814) > @@ -272,8 +272,12 @@ xbd_queue_request(struct xbd_softc *sc, > { > int error; > > - error = bus_dmamap_load(sc->xbd_io_dmat, cm->cm_map, cm->cm_data, > - cm->cm_datalen, xbd_queue_cb, cm, 0); > + if (cm->cm_bp != NULL) > + error = bus_dmamap_load_bio(sc->xbd_io_dmat, cm->cm_map, > + cm->cm_bp, xbd_queue_cb, cm, 0); > + else > + error = bus_dmamap_load(sc->xbd_io_dmat, cm->cm_map, > + cm->cm_data, cm->cm_datalen, xbd_queue_cb, cm, 0); > if (error == EINPROGRESS) { > /* >* Maintain queuing order by freezing the queue. The next > @@ -333,8 +337,6 @@ xbd_bio_command(struct xbd_softc *sc) > } > > cm->cm_bp = bp; > - cm->cm_data = bp->bio_data; > - cm->cm_datalen = bp->bio_bcount; > cm->cm_sector_number = (blkif_sector_t)bp->bio_pblkno; > > switch (bp->bio_cmd) { > @@ -993,7 +995,7 @@ xbd_instance_create(struct xbd_softc *sc > > sc->xbd_disk->d_mediasize = sectors * sector_size; > sc->xbd_disk->d_maxsize = sc->xbd_max_request_size; > - sc->xbd_disk->d_flags = 0; > + sc->xbd_disk->d_flags = DISKFLAG_UNMAPPED_BIO; > if ((sc->xbd_flags & (XBDF_FLUSH|XBDF_BARRIER)) != 0) { > sc->xbd_disk->d_flags |= DISKFLAG_CANFLUSHCACHE; > device_printf(sc->xbd_dev, > -- Alexander Motin ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r270755 - in head/sys: conf modules
On Aug 28, 2014, at 10:40, Jack F Vogel wrote: > > Author: jfv > Date: Thu Aug 28 17:40:19 2014 > New Revision: 270755 > URL: http://svnweb.freebsd.org/changeset/base/270755 > > Log: > Add XL710 device entries to NOTES, and directories to the module > Makefile so they will be built. > > MFC after: 1 day The minimum MFC timer is 3 days. -- Rui Paulo ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r270755 - in head/sys: conf modules
Author: jfv Date: Thu Aug 28 17:40:19 2014 New Revision: 270755 URL: http://svnweb.freebsd.org/changeset/base/270755 Log: Add XL710 device entries to NOTES, and directories to the module Makefile so they will be built. MFC after: 1 day Modified: head/sys/conf/NOTES head/sys/modules/Makefile Modified: head/sys/conf/NOTES == --- head/sys/conf/NOTES Thu Aug 28 16:26:13 2014(r270754) +++ head/sys/conf/NOTES Thu Aug 28 17:40:19 2014(r270755) @@ -2094,6 +2094,8 @@ deviceem # Intel Pro/1000 Gigabit Eth device igb # Intel Pro/1000 PCIE Gigabit Ethernet device ixgb# Intel Pro/10Gbe PCI-X Ethernet device ixgbe # Intel Pro/10Gbe PCIE Ethernet +device ixl # Intel XL710 40Gbe PCIE Ethernet +device ixlv# Intel XL710 40Gbe VF PCIE Ethernet device le # AMD Am7900 LANCE and Am79C9xx PCnet device mxge# Myricom Myri-10G 10GbE NIC device nxge# Neterion Xframe 10GbE Server/Storage Adapter Modified: head/sys/modules/Makefile == --- head/sys/modules/Makefile Thu Aug 28 16:26:13 2014(r270754) +++ head/sys/modules/Makefile Thu Aug 28 17:40:19 2014(r270755) @@ -180,6 +180,8 @@ SUBDIR= \ ${_iwnfw} \ ${_ixgb} \ ${_ixgbe} \ + ${_ixl} \ + ${_ixlv} \ jme \ joy \ kbdmux \ @@ -622,6 +624,8 @@ _iwnfw= iwnfw .endif _ixgb= ixgb _ixgbe=ixgbe +_ixl= ixl +_ixlv= ixlv _mly= mly _nfe= nfe _nvd= nvd @@ -729,6 +733,8 @@ _iwnfw= iwnfw .endif _ixgb= ixgb _ixgbe=ixgbe +_ixl= ixl +_ixlv= ixlv _linprocfs=linprocfs _linsysfs= linsysfs _linux=linux ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r269134 - head/sys/vm
On 28 August 2014 09:52, hiren panchasara wrote: > On Thu, Aug 28, 2014 at 9:30 AM, Alan Cox wrote: >> >> On Aug 28, 2014, at 3:30 AM, Adrian Chadd wrote: >> >>> Hi Alan! >>> >>> I just reverted back to the commit before this one and it fixed my MIPS32 >>> boot. >>> >>> Would you have some time to help me help you figure out why things broke? :) >>> >> >> >> Have you tried booting a kernel based on r269134? At the time, I tested a >> 64-bit MIPS kernel on gxemul, and it ran ok. Also, Hiren reports that a >> 32-bit kernel from about two weeks after r269134 works for him. >> > > To be precise, I am on r269799 which works for me. Ok. I'll jump forward to r269799 and then inch forward until I find where it broke. Thanks! -a ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r269134 - head/sys/vm
On Thu, Aug 28, 2014 at 9:30 AM, Alan Cox wrote: > > On Aug 28, 2014, at 3:30 AM, Adrian Chadd wrote: > >> Hi Alan! >> >> I just reverted back to the commit before this one and it fixed my MIPS32 >> boot. >> >> Would you have some time to help me help you figure out why things broke? :) >> > > > Have you tried booting a kernel based on r269134? At the time, I tested a > 64-bit MIPS kernel on gxemul, and it ran ok. Also, Hiren reports that a > 32-bit kernel from about two weeks after r269134 works for him. > To be precise, I am on r269799 which works for me. cheers, Hiren > >> >> >> >> >> -a >> >> >> On 26 July 2014 11:10, Alan Cox wrote: >>> Author: alc >>> Date: Sat Jul 26 18:10:18 2014 >>> New Revision: 269134 >>> URL: http://svnweb.freebsd.org/changeset/base/269134 >>> >>> Log: >>> When unwiring a region of an address space, do not assume that the >>> underlying physical pages are mapped by the pmap. If, for example, the >>> application has performed an mprotect(..., PROT_NONE) on any part of the >>> wired region, then those pages will no longer be mapped by the pmap. >>> So, using the pmap to lookup the wired pages in order to unwire them >>> doesn't always work, and when it doesn't work wired pages are leaked. >>> >>> To avoid the leak, introduce and use a new function vm_object_unwire() >>> that locates the wired pages by traversing the object and its backing >>> objects. >>> >>> At the same time, switch from using pmap_change_wiring() to the recently >>> introduced function pmap_unwire() for unwiring the region's mappings. >>> pmap_unwire() is faster, because it operates a range of virtual addresses >>> rather than a single virtual page at a time. Moreover, by operating on >>> a range, it is superpage friendly. It doesn't waste time performing >>> unnecessary demotions. >>> >>> Reported by: markj >>> Reviewed by: kib >>> Tested by:pho, jmg (arm) >>> Sponsored by: EMC / Isilon Storage Division >>> >>> Modified: >>> head/sys/vm/vm_extern.h >>> head/sys/vm/vm_fault.c >>> head/sys/vm/vm_map.c >>> head/sys/vm/vm_object.c >>> head/sys/vm/vm_object.h >>> >>> Modified: head/sys/vm/vm_extern.h >>> == >>> --- head/sys/vm/vm_extern.h Sat Jul 26 17:59:25 2014(r269133) >>> +++ head/sys/vm/vm_extern.h Sat Jul 26 18:10:18 2014(r269134) >>> @@ -81,7 +81,6 @@ int vm_fault_hold(vm_map_t map, vm_offse >>> int fault_flags, vm_page_t *m_hold); >>> int vm_fault_quick_hold_pages(vm_map_t map, vm_offset_t addr, vm_size_t len, >>> vm_prot_t prot, vm_page_t *ma, int max_count); >>> -void vm_fault_unwire(vm_map_t, vm_offset_t, vm_offset_t, boolean_t); >>> int vm_fault_wire(vm_map_t, vm_offset_t, vm_offset_t, boolean_t); >>> int vm_forkproc(struct thread *, struct proc *, struct thread *, struct >>> vmspace *, int); >>> void vm_waitproc(struct proc *); >>> >>> Modified: head/sys/vm/vm_fault.c >>> == >>> --- head/sys/vm/vm_fault.c Sat Jul 26 17:59:25 2014(r269133) >>> +++ head/sys/vm/vm_fault.c Sat Jul 26 18:10:18 2014(r269134) >>> @@ -106,6 +106,7 @@ __FBSDID("$FreeBSD$"); >>> #define PFFOR 4 >>> >>> static int vm_fault_additional_pages(vm_page_t, int, int, vm_page_t *, int >>> *); >>> +static void vm_fault_unwire(vm_map_t, vm_offset_t, vm_offset_t, boolean_t); >>> >>> #defineVM_FAULT_READ_BEHIND8 >>> #defineVM_FAULT_READ_MAX (1 + VM_FAULT_READ_AHEAD_MAX) >>> @@ -1186,7 +1187,7 @@ vm_fault_wire(vm_map_t map, vm_offset_t >>> * >>> * Unwire a range of virtual addresses in a map. >>> */ >>> -void >>> +static void >>> vm_fault_unwire(vm_map_t map, vm_offset_t start, vm_offset_t end, >>> boolean_t fictitious) >>> { >>> >>> Modified: head/sys/vm/vm_map.c >>> == >>> --- head/sys/vm/vm_map.cSat Jul 26 17:59:25 2014(r269133) >>> +++ head/sys/vm/vm_map.cSat Jul 26 18:10:18 2014(r269134) >>> @@ -132,6 +132,7 @@ static void _vm_map_init(vm_map_t map, p >>> vm_offset_t max); >>> static void vm_map_entry_deallocate(vm_map_entry_t entry, boolean_t >>> system_map); >>> static void vm_map_entry_dispose(vm_map_t map, vm_map_entry_t entry); >>> +static void vm_map_entry_unwire(vm_map_t map, vm_map_entry_t entry); >>> #ifdef INVARIANTS >>> static void vm_map_zdtor(void *mem, int size, void *arg); >>> static void vmspace_zdtor(void *mem, int size, void *arg); >>> @@ -2393,16 +2394,10 @@ done: >>>(entry->eflags & MAP_ENTRY_USER_WIRED))) { >>>if (user_unwire) >>>entry->eflags &= ~MAP_ENTRY_USER_WIRED; >>> - entry->wired_count--; >>> - if (entry->wired_count == 0) { >>> - /* >>> -
Re: svn commit: r269134 - head/sys/vm
On Aug 28, 2014, at 3:30 AM, Adrian Chadd wrote: > Hi Alan! > > I just reverted back to the commit before this one and it fixed my MIPS32 > boot. > > Would you have some time to help me help you figure out why things broke? :) > Have you tried booting a kernel based on r269134? At the time, I tested a 64-bit MIPS kernel on gxemul, and it ran ok. Also, Hiren reports that a 32-bit kernel from about two weeks after r269134 works for him. > > > > > -a > > > On 26 July 2014 11:10, Alan Cox wrote: >> Author: alc >> Date: Sat Jul 26 18:10:18 2014 >> New Revision: 269134 >> URL: http://svnweb.freebsd.org/changeset/base/269134 >> >> Log: >> When unwiring a region of an address space, do not assume that the >> underlying physical pages are mapped by the pmap. If, for example, the >> application has performed an mprotect(..., PROT_NONE) on any part of the >> wired region, then those pages will no longer be mapped by the pmap. >> So, using the pmap to lookup the wired pages in order to unwire them >> doesn't always work, and when it doesn't work wired pages are leaked. >> >> To avoid the leak, introduce and use a new function vm_object_unwire() >> that locates the wired pages by traversing the object and its backing >> objects. >> >> At the same time, switch from using pmap_change_wiring() to the recently >> introduced function pmap_unwire() for unwiring the region's mappings. >> pmap_unwire() is faster, because it operates a range of virtual addresses >> rather than a single virtual page at a time. Moreover, by operating on >> a range, it is superpage friendly. It doesn't waste time performing >> unnecessary demotions. >> >> Reported by: markj >> Reviewed by: kib >> Tested by:pho, jmg (arm) >> Sponsored by: EMC / Isilon Storage Division >> >> Modified: >> head/sys/vm/vm_extern.h >> head/sys/vm/vm_fault.c >> head/sys/vm/vm_map.c >> head/sys/vm/vm_object.c >> head/sys/vm/vm_object.h >> >> Modified: head/sys/vm/vm_extern.h >> == >> --- head/sys/vm/vm_extern.h Sat Jul 26 17:59:25 2014(r269133) >> +++ head/sys/vm/vm_extern.h Sat Jul 26 18:10:18 2014(r269134) >> @@ -81,7 +81,6 @@ int vm_fault_hold(vm_map_t map, vm_offse >> int fault_flags, vm_page_t *m_hold); >> int vm_fault_quick_hold_pages(vm_map_t map, vm_offset_t addr, vm_size_t len, >> vm_prot_t prot, vm_page_t *ma, int max_count); >> -void vm_fault_unwire(vm_map_t, vm_offset_t, vm_offset_t, boolean_t); >> int vm_fault_wire(vm_map_t, vm_offset_t, vm_offset_t, boolean_t); >> int vm_forkproc(struct thread *, struct proc *, struct thread *, struct >> vmspace *, int); >> void vm_waitproc(struct proc *); >> >> Modified: head/sys/vm/vm_fault.c >> == >> --- head/sys/vm/vm_fault.c Sat Jul 26 17:59:25 2014(r269133) >> +++ head/sys/vm/vm_fault.c Sat Jul 26 18:10:18 2014(r269134) >> @@ -106,6 +106,7 @@ __FBSDID("$FreeBSD$"); >> #define PFFOR 4 >> >> static int vm_fault_additional_pages(vm_page_t, int, int, vm_page_t *, int >> *); >> +static void vm_fault_unwire(vm_map_t, vm_offset_t, vm_offset_t, boolean_t); >> >> #defineVM_FAULT_READ_BEHIND8 >> #defineVM_FAULT_READ_MAX (1 + VM_FAULT_READ_AHEAD_MAX) >> @@ -1186,7 +1187,7 @@ vm_fault_wire(vm_map_t map, vm_offset_t >> * >> * Unwire a range of virtual addresses in a map. >> */ >> -void >> +static void >> vm_fault_unwire(vm_map_t map, vm_offset_t start, vm_offset_t end, >> boolean_t fictitious) >> { >> >> Modified: head/sys/vm/vm_map.c >> == >> --- head/sys/vm/vm_map.cSat Jul 26 17:59:25 2014(r269133) >> +++ head/sys/vm/vm_map.cSat Jul 26 18:10:18 2014(r269134) >> @@ -132,6 +132,7 @@ static void _vm_map_init(vm_map_t map, p >> vm_offset_t max); >> static void vm_map_entry_deallocate(vm_map_entry_t entry, boolean_t >> system_map); >> static void vm_map_entry_dispose(vm_map_t map, vm_map_entry_t entry); >> +static void vm_map_entry_unwire(vm_map_t map, vm_map_entry_t entry); >> #ifdef INVARIANTS >> static void vm_map_zdtor(void *mem, int size, void *arg); >> static void vmspace_zdtor(void *mem, int size, void *arg); >> @@ -2393,16 +2394,10 @@ done: >>(entry->eflags & MAP_ENTRY_USER_WIRED))) { >>if (user_unwire) >>entry->eflags &= ~MAP_ENTRY_USER_WIRED; >> - entry->wired_count--; >> - if (entry->wired_count == 0) { >> - /* >> -* Retain the map lock. >> -*/ >> - vm_fault_unwire(map, entry->start, >> entry->end, >> - entry->object.vm_object != NU
svn commit: r270754 - head/share/examples/bhyve
Author: rodrigc Date: Thu Aug 28 16:26:13 2014 New Revision: 270754 URL: http://svnweb.freebsd.org/changeset/base/270754 Log: Use "file -s", so that we can run vmrun.sh against special devices such as /dev/md memory file systems Reviewed by: neel Modified: head/share/examples/bhyve/vmrun.sh Modified: head/share/examples/bhyve/vmrun.sh == --- head/share/examples/bhyve/vmrun.sh Thu Aug 28 15:05:42 2014 (r270753) +++ head/share/examples/bhyve/vmrun.sh Thu Aug 28 16:26:13 2014 (r270754) @@ -177,10 +177,10 @@ ${BHYVECTL} --vm=${vmname} --destroy > / while [ 1 ]; do - file ${virtio_diskdev} | grep "boot sector" > /dev/null + file -s ${virtio_diskdev} | grep "boot sector" > /dev/null rc=$? if [ $rc -ne 0 ]; then - file ${virtio_diskdev} | grep ": Unix Fast File sys" > /dev/null + file -s ${virtio_diskdev} | grep ": Unix Fast File sys" > /dev/null rc=$? fi if [ $rc -ne 0 ]; then ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r270750 - head/sys/dev/drm2/radeon
Author: dumbbell Date: Thu Aug 28 12:40:31 2014 New Revision: 270750 URL: http://svnweb.freebsd.org/changeset/base/270750 Log: drm/radeon: Fix a memory leak when radeonkms is unloaded MFC after:1 week Modified: head/sys/dev/drm2/radeon/radeon_fb.c Modified: head/sys/dev/drm2/radeon/radeon_fb.c == --- head/sys/dev/drm2/radeon/radeon_fb.cThu Aug 28 11:50:52 2014 (r270749) +++ head/sys/dev/drm2/radeon/radeon_fb.cThu Aug 28 12:40:31 2014 (r270750) @@ -291,6 +291,7 @@ static int radeon_fbdev_destroy(struct d if (rfbdev->helper.fbdev) { info = rfbdev->helper.fbdev; + free(info->fb_priv, DRM_MEM_KMS); free(info, DRM_MEM_KMS); } ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r270749 - head/contrib/openbsm/bin/auditdistd
Author: ed Date: Thu Aug 28 11:50:52 2014 New Revision: 270749 URL: http://svnweb.freebsd.org/changeset/base/270749 Log: Unlock the right lock. The adist_remote_lock is not held in this place, whereas the adist_recv_list_lock lock is and is picked up during the next iteration. I found this by annotating our libpthread with Clang's -Wthread-safety attributes. I will send out a patch for this in the nearby future, because it's awesome. MFC after:2 weeks Modified: head/contrib/openbsm/bin/auditdistd/sender.c Modified: head/contrib/openbsm/bin/auditdistd/sender.c == --- head/contrib/openbsm/bin/auditdistd/sender.cThu Aug 28 09:40:44 2014(r270748) +++ head/contrib/openbsm/bin/auditdistd/sender.cThu Aug 28 11:50:52 2014(r270749) @@ -643,7 +643,7 @@ recv_thread(void *arg __unused) * we can use that. */ if (TAILQ_EMPTY(&adist_recv_list)) { - rw_unlock(&adist_remote_lock); + mtx_unlock(&adist_recv_list_lock); continue; } mtx_unlock(&adist_recv_list_lock); ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r270444 - in head/sys: kern sys
On Thu, Aug 28, 2014 at 11:21:39AM +0300, Konstantin Belousov wrote: > On Thu, Aug 28, 2014 at 05:30:09AM +0200, Mateusz Guzik wrote: > > @@ -791,6 +791,8 @@ fill_kinfo_proc_only(struct proc *p, struct kinfo_proc > > *kp) > > struct ucred *cred; > > struct sigacts *ps; > > > > + /* For proc_realparent. */ > > + sx_assert(&proctree_lock, SX_LOCKED); > > PROC_LOCK_ASSERT(p, MA_OWNED); > > bzero(kp, sizeof(*kp)); > > > > @@ -920,7 +922,9 @@ fill_kinfo_proc_only(struct proc *p, struct kinfo_proc > > *kp) > > kp->ki_acflag = p->p_acflag; > > kp->ki_lock = p->p_lock; > > if (p->p_pptr) > > - kp->ki_ppid = p->p_pptr->p_pid; > > + kp->ki_ppid = proc_realparent(p)->p_pid; > Is the check for p_pptr != NULL still needed for the call to > proc_realparent() ? If yes, I think it indicates a bug in > proc_realparent(), which should incorporate the check, instead of > enforcing it on the callers. It seems to be there for the kernel process > (pid 0). As it is proc_realparent cannot fail, so after this change callers like this one would have to have some checks anyway. On the other hand other consumers don't need to worry about this edge case, so it would only add an unnecessary branch. I have no strong opinion either way, for now I decided to just commit the patch in its current form. > > If the test can be removed, and proc_realparent() called unconditionally, > I suggest to remove assert about proctree_lock at the start of > fill_kinfo_proc_only(), since the check is done in proc_realparent(). > > Whatever decision is made there, it can be implemented after your > change is landed. The patch looks fine for me. Thanks, committed as r270745. -- Mateusz Guzik ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r270745 - in head: bin/ps sys/compat/freebsd32 sys/kern sys/sys
Author: mjg Date: Thu Aug 28 08:41:11 2014 New Revision: 270745 URL: http://svnweb.freebsd.org/changeset/base/270745 Log: Return real parent pid in kinfo (used by e.g. ps) Add a separate field which exports tracer pid and add a new keyword ("tracer") for ps to display it. This is a follow up to r270444. Reviewed by: kib MFC after:1 week Relnotes: yes Modified: head/bin/ps/keyword.c head/bin/ps/ps.1 head/sys/compat/freebsd32/freebsd32.h head/sys/kern/kern_proc.c head/sys/sys/user.h Modified: head/bin/ps/keyword.c == --- head/bin/ps/keyword.c Thu Aug 28 08:25:15 2014(r270744) +++ head/bin/ps/keyword.c Thu Aug 28 08:41:11 2014(r270745) @@ -157,6 +157,7 @@ static VAR var[] = { {"tdnam", "TDNAM", NULL, LJUST, tdnam, 0, CHAR, NULL, 0}, {"time", "TIME", NULL, USER, cputime, 0, CHAR, NULL, 0}, {"tpgid", "TPGID", NULL, 0, kvar, KOFF(ki_tpgid), UINT, PIDFMT, 0}, + {"tracer", "TRACER", NULL, 0, kvar, KOFF(ki_tracer), UINT, PIDFMT, 0}, {"tsid", "TSID", NULL, 0, kvar, KOFF(ki_tsid), UINT, PIDFMT, 0}, {"tsiz", "TSIZ", NULL, 0, kvar, KOFF(ki_tsize), PGTOK, "ld", 0}, {"tt", "TT ", NULL, 0, tname, 0, CHAR, NULL, 0}, Modified: head/bin/ps/ps.1 == --- head/bin/ps/ps.1Thu Aug 28 08:25:15 2014(r270744) +++ head/bin/ps/ps.1Thu Aug 28 08:41:11 2014(r270745) @@ -29,7 +29,7 @@ .\" @(#)ps.1 8.3 (Berkeley) 4/18/94 .\" $FreeBSD$ .\" -.Dd August 7, 2014 +.Dd August 27, 2014 .Dt PS 1 .Os .Sh NAME @@ -665,6 +665,8 @@ accumulated CPU time, user + system (ali .Cm cputime ) .It Cm tpgid control terminal process group ID +.It Cm tracer +tracer process ID .\".It Cm trss .\"text resident set size (in Kbytes) .It Cm tsid Modified: head/sys/compat/freebsd32/freebsd32.h == --- head/sys/compat/freebsd32/freebsd32.h Thu Aug 28 08:25:15 2014 (r270744) +++ head/sys/compat/freebsd32/freebsd32.h Thu Aug 28 08:41:11 2014 (r270745) @@ -343,6 +343,7 @@ struct kinfo_proc32 { charki_loginclass[LOGINCLASSLEN+1]; charki_sparestrings[50]; int ki_spareints[KI_NSPARE_INT]; + int ki_tracer; int ki_flag2; int ki_fibnum; u_int ki_cr_flags; Modified: head/sys/kern/kern_proc.c == --- head/sys/kern/kern_proc.c Thu Aug 28 08:25:15 2014(r270744) +++ head/sys/kern/kern_proc.c Thu Aug 28 08:41:11 2014(r270745) @@ -791,6 +791,8 @@ fill_kinfo_proc_only(struct proc *p, str struct ucred *cred; struct sigacts *ps; + /* For proc_realparent. */ + sx_assert(&proctree_lock, SX_LOCKED); PROC_LOCK_ASSERT(p, MA_OWNED); bzero(kp, sizeof(*kp)); @@ -920,7 +922,9 @@ fill_kinfo_proc_only(struct proc *p, str kp->ki_acflag = p->p_acflag; kp->ki_lock = p->p_lock; if (p->p_pptr) - kp->ki_ppid = p->p_pptr->p_pid; + kp->ki_ppid = proc_realparent(p)->p_pid; + if (p->p_flag & P_TRACED) + kp->ki_tracer = p->p_pptr->p_pid; } /* @@ -1166,6 +1170,7 @@ freebsd32_kinfo_proc_out(const struct ki bcopy(ki->ki_comm, ki32->ki_comm, COMMLEN + 1); bcopy(ki->ki_emul, ki32->ki_emul, KI_EMULNAMELEN + 1); bcopy(ki->ki_loginclass, ki32->ki_loginclass, LOGINCLASSLEN + 1); + CP(*ki, *ki32, ki_tracer); CP(*ki, *ki32, ki_flag2); CP(*ki, *ki32, ki_fibnum); CP(*ki, *ki32, ki_cr_flags); @@ -1287,10 +1292,11 @@ sysctl_kern_proc(SYSCTL_HANDLER_ARGS) error = sysctl_wire_old_buffer(req, 0); if (error) return (error); + sx_slock(&proctree_lock); error = pget((pid_t)name[0], PGET_CANSEE, &p); - if (error != 0) - return (error); - error = sysctl_out_proc(p, req, flags, 0); + if (error == 0) + error = sysctl_out_proc(p, req, flags, 0); + sx_sunlock(&proctree_lock); return (error); } @@ -1318,6 +1324,7 @@ sysctl_kern_proc(SYSCTL_HANDLER_ARGS) error = sysctl_wire_old_buffer(req, 0); if (error != 0) return (error); + sx_slock(&proctree_lock); sx_slock(&allproc_lock); for (doingzomb=0 ; doingzomb < 2 ; doingzomb++) { if (!doingzomb) @@ -1422,11 +1429,13 @@ sysctl_kern_proc(SYSCTL_HANDLER_ARGS) error = sysctl_out_proc(p, req, flags, doingzomb); if (error) { sx_sunlock(&allproc_lock); +
Re: svn commit: r269134 - head/sys/vm
Hi Alan! I just reverted back to the commit before this one and it fixed my MIPS32 boot. Would you have some time to help me help you figure out why things broke? :) Thanks! -a On 26 July 2014 11:10, Alan Cox wrote: > Author: alc > Date: Sat Jul 26 18:10:18 2014 > New Revision: 269134 > URL: http://svnweb.freebsd.org/changeset/base/269134 > > Log: > When unwiring a region of an address space, do not assume that the > underlying physical pages are mapped by the pmap. If, for example, the > application has performed an mprotect(..., PROT_NONE) on any part of the > wired region, then those pages will no longer be mapped by the pmap. > So, using the pmap to lookup the wired pages in order to unwire them > doesn't always work, and when it doesn't work wired pages are leaked. > > To avoid the leak, introduce and use a new function vm_object_unwire() > that locates the wired pages by traversing the object and its backing > objects. > > At the same time, switch from using pmap_change_wiring() to the recently > introduced function pmap_unwire() for unwiring the region's mappings. > pmap_unwire() is faster, because it operates a range of virtual addresses > rather than a single virtual page at a time. Moreover, by operating on > a range, it is superpage friendly. It doesn't waste time performing > unnecessary demotions. > > Reported by: markj > Reviewed by: kib > Tested by:pho, jmg (arm) > Sponsored by: EMC / Isilon Storage Division > > Modified: > head/sys/vm/vm_extern.h > head/sys/vm/vm_fault.c > head/sys/vm/vm_map.c > head/sys/vm/vm_object.c > head/sys/vm/vm_object.h > > Modified: head/sys/vm/vm_extern.h > == > --- head/sys/vm/vm_extern.h Sat Jul 26 17:59:25 2014(r269133) > +++ head/sys/vm/vm_extern.h Sat Jul 26 18:10:18 2014(r269134) > @@ -81,7 +81,6 @@ int vm_fault_hold(vm_map_t map, vm_offse > int fault_flags, vm_page_t *m_hold); > int vm_fault_quick_hold_pages(vm_map_t map, vm_offset_t addr, vm_size_t len, > vm_prot_t prot, vm_page_t *ma, int max_count); > -void vm_fault_unwire(vm_map_t, vm_offset_t, vm_offset_t, boolean_t); > int vm_fault_wire(vm_map_t, vm_offset_t, vm_offset_t, boolean_t); > int vm_forkproc(struct thread *, struct proc *, struct thread *, struct > vmspace *, int); > void vm_waitproc(struct proc *); > > Modified: head/sys/vm/vm_fault.c > == > --- head/sys/vm/vm_fault.c Sat Jul 26 17:59:25 2014(r269133) > +++ head/sys/vm/vm_fault.c Sat Jul 26 18:10:18 2014(r269134) > @@ -106,6 +106,7 @@ __FBSDID("$FreeBSD$"); > #define PFFOR 4 > > static int vm_fault_additional_pages(vm_page_t, int, int, vm_page_t *, int > *); > +static void vm_fault_unwire(vm_map_t, vm_offset_t, vm_offset_t, boolean_t); > > #defineVM_FAULT_READ_BEHIND8 > #defineVM_FAULT_READ_MAX (1 + VM_FAULT_READ_AHEAD_MAX) > @@ -1186,7 +1187,7 @@ vm_fault_wire(vm_map_t map, vm_offset_t > * > * Unwire a range of virtual addresses in a map. > */ > -void > +static void > vm_fault_unwire(vm_map_t map, vm_offset_t start, vm_offset_t end, > boolean_t fictitious) > { > > Modified: head/sys/vm/vm_map.c > == > --- head/sys/vm/vm_map.cSat Jul 26 17:59:25 2014(r269133) > +++ head/sys/vm/vm_map.cSat Jul 26 18:10:18 2014(r269134) > @@ -132,6 +132,7 @@ static void _vm_map_init(vm_map_t map, p > vm_offset_t max); > static void vm_map_entry_deallocate(vm_map_entry_t entry, boolean_t > system_map); > static void vm_map_entry_dispose(vm_map_t map, vm_map_entry_t entry); > +static void vm_map_entry_unwire(vm_map_t map, vm_map_entry_t entry); > #ifdef INVARIANTS > static void vm_map_zdtor(void *mem, int size, void *arg); > static void vmspace_zdtor(void *mem, int size, void *arg); > @@ -2393,16 +2394,10 @@ done: > (entry->eflags & MAP_ENTRY_USER_WIRED))) { > if (user_unwire) > entry->eflags &= ~MAP_ENTRY_USER_WIRED; > - entry->wired_count--; > - if (entry->wired_count == 0) { > - /* > -* Retain the map lock. > -*/ > - vm_fault_unwire(map, entry->start, entry->end, > - entry->object.vm_object != NULL && > - (entry->object.vm_object->flags & > - OBJ_FICTITIOUS) != 0); > - } > + if (entry->wired_count == 1) > + vm_map_entry_unwire(map, entry); > + else > + e
Re: svn commit: r270444 - in head/sys: kern sys
On Thu, Aug 28, 2014 at 05:30:09AM +0200, Mateusz Guzik wrote: > @@ -791,6 +791,8 @@ fill_kinfo_proc_only(struct proc *p, struct kinfo_proc > *kp) > struct ucred *cred; > struct sigacts *ps; > > + /* For proc_realparent. */ > + sx_assert(&proctree_lock, SX_LOCKED); > PROC_LOCK_ASSERT(p, MA_OWNED); > bzero(kp, sizeof(*kp)); > > @@ -920,7 +922,9 @@ fill_kinfo_proc_only(struct proc *p, struct kinfo_proc > *kp) > kp->ki_acflag = p->p_acflag; > kp->ki_lock = p->p_lock; > if (p->p_pptr) > - kp->ki_ppid = p->p_pptr->p_pid; > + kp->ki_ppid = proc_realparent(p)->p_pid; Is the check for p_pptr != NULL still needed for the call to proc_realparent() ? If yes, I think it indicates a bug in proc_realparent(), which should incorporate the check, instead of enforcing it on the callers. It seems to be there for the kernel process (pid 0). If the test can be removed, and proc_realparent() called unconditionally, I suggest to remove assert about proctree_lock at the start of fill_kinfo_proc_only(), since the check is done in proc_realparent(). Whatever decision is made there, it can be implemented after your change is landed. The patch looks fine for me. pgpVrUv1Dl5f7.pgp Description: PGP signature
svn commit: r270742 - head/sys/dev/iwn
Author: adrian Date: Thu Aug 28 07:44:59 2014 New Revision: 270742 URL: http://svnweb.freebsd.org/changeset/base/270742 Log: Inform the rate control code if a single frame AMPDU transmission succeeds but has some retries. Without this, single frame transmission in AMPDU will always look like it succeeded fine, and thus AMRR will think it's totally fine to just keep upping the rate upwards. Now, this is still not quite right! For multi-frame aggregates the completion happens in two parts - the TX done and the BA received. The driver is currently double accounting those a little - there's no way to say to the rate control code "I completed X frames, Y worked fine, there were Z retries." And it's a bit odd with iwn, as the firmware retransmits frames for us so we don't get to see how many retransmits happened; only that it took longer than normal. I may have to extend the rate control API to properly track that. So this may keep the rate lower than it should be, but that's better than keeping it higher than it should be. Tested: * 5100, STA mode Modified: head/sys/dev/iwn/if_iwn.c Modified: head/sys/dev/iwn/if_iwn.c == --- head/sys/dev/iwn/if_iwn.c Thu Aug 28 06:16:36 2014(r270741) +++ head/sys/dev/iwn/if_iwn.c Thu Aug 28 07:44:59 2014(r270742) @@ -213,7 +213,7 @@ static void iwn5000_tx_done(struct iwn_s struct iwn_rx_data *); static voidiwn_tx_done(struct iwn_softc *, struct iwn_rx_desc *, int, uint8_t); -static voidiwn_ampdu_tx_done(struct iwn_softc *, int, int, int, void *); +static voidiwn_ampdu_tx_done(struct iwn_softc *, int, int, int, int, void *); static voidiwn_cmd_done(struct iwn_softc *, struct iwn_rx_desc *); static voidiwn_notif_intr(struct iwn_softc *); static voidiwn_wakeup_intr(struct iwn_softc *); @@ -3150,6 +3150,11 @@ iwn_rx_compressed_ba(struct iwn_softc *s if (wn->agg[tid].nframes > (64 - shift)) return; + /* +* XXX does this correctly process an almost empty bitmap? +* (since it bails out when it sees an empty bitmap, but there +* may be failed bits there..) +*/ ni = tap->txa_ni; bitmap = (le64toh(ba->bitmap) >> shift) & wn->agg[tid].bitmap; for (i = 0; bitmap; i++) { @@ -3426,7 +3431,7 @@ iwn4965_tx_done(struct iwn_softc *sc, st bus_dmamap_sync(ring->data_dmat, data->map, BUS_DMASYNC_POSTREAD); if (qid >= sc->firstaggqueue) { iwn_ampdu_tx_done(sc, qid, desc->idx, stat->nframes, - &stat->status); + stat->ackfailcnt, &stat->status); } else { iwn_tx_done(sc, desc, stat->ackfailcnt, le32toh(stat->status) & 0xff); @@ -3458,7 +3463,7 @@ iwn5000_tx_done(struct iwn_softc *sc, st bus_dmamap_sync(ring->data_dmat, data->map, BUS_DMASYNC_POSTREAD); if (qid >= sc->firstaggqueue) { iwn_ampdu_tx_done(sc, qid, desc->idx, stat->nframes, - &stat->status); + stat->ackfailcnt, &stat->status); } else { iwn_tx_done(sc, desc, stat->ackfailcnt, le16toh(stat->status) & 0xff); @@ -3573,7 +3578,7 @@ iwn_cmd_done(struct iwn_softc *sc, struc static void iwn_ampdu_tx_done(struct iwn_softc *sc, int qid, int idx, int nframes, -void *stat) +int ackfailcnt, void *stat) { struct iwn_ops *ops = &sc->ops; struct ifnet *ifp = sc->sc_ifp; @@ -3591,6 +3596,15 @@ iwn_ampdu_tx_done(struct iwn_softc *sc, int bit, i, lastidx, *res, seqno, shift, start; DPRINTF(sc, IWN_DEBUG_TRACE, "->%s begin\n", __func__); + DPRINTF(sc, IWN_DEBUG_XMIT, "%s: nframes=%d, status=0x%08x\n", + __func__, + nframes, + *status); + + tap = sc->qid2tap[qid]; + tid = tap->txa_tid; + wn = (void *)tap->txa_ni; + ni = tap->txa_ni; if (nframes == 1) { if ((*status & 0xff) != 1 && (*status & 0xff) != 2) { @@ -3602,15 +3616,24 @@ iwn_ampdu_tx_done(struct iwn_softc *sc, * notification is pushed up to the rate control * layer. */ - tap = sc->qid2tap[qid]; - tid = tap->txa_tid; - wn = (void *)tap->txa_ni; - ni = tap->txa_ni; ieee80211_ratectl_tx_complete(ni->ni_vap, ni, IEEE80211_RATECTL_TX_FAILURE, &nframes, NULL); } } + /* +* We succeeded with some frames, so let's update how many +* retries were needed for this frame. +* +* XXX we can't yet pass tx_complete tx_cnt and success_cnt, +* le sigh. +*/ + ieee80211_rat