svn commit: r242425 - head/sys/dev/ti
Author: yongari
Date: Thu Nov 1 05:39:21 2012
New Revision: 242425
URL: http://svn.freebsd.org/changeset/base/242425
Log:
Remove TCP/UDP checksum offloading feature for IP fragmented
datagrams. Traditionally upper stack fragmented packets without
computing TCP/UDP checksum and these datagrams were passed to
driver. But there are chances that other packets slip into the
interface queue in SMP world. If this happens firmware running on
MIPS 4000 processor in the controller would see mixed packets and
it shall send out corrupted packets.
While I'm here simplify checksum offloading setup.
MFC After:1 week
Modified:
head/sys/dev/ti/if_ti.c
Modified: head/sys/dev/ti/if_ti.c
==
--- head/sys/dev/ti/if_ti.c Thu Nov 1 04:07:08 2012(r242424)
+++ head/sys/dev/ti/if_ti.c Thu Nov 1 05:39:21 2012(r242425)
@@ -127,7 +127,7 @@ __FBSDID("$FreeBSD$");
#include
-#define TI_CSUM_FEATURES (CSUM_IP | CSUM_TCP | CSUM_UDP | CSUM_IP_FRAGS)
+#define TI_CSUM_FEATURES (CSUM_IP | CSUM_TCP | CSUM_UDP)
/*
* We can only turn on header splitting if we're using extended receive
* BDs.
@@ -3082,16 +3082,10 @@ ti_encap(struct ti_softc *sc, struct mbu
m = *m_head;
csum_flags = 0;
- if (m->m_pkthdr.csum_flags) {
- if (m->m_pkthdr.csum_flags & CSUM_IP)
- csum_flags |= TI_BDFLAG_IP_CKSUM;
- if (m->m_pkthdr.csum_flags & (CSUM_TCP | CSUM_UDP))
- csum_flags |= TI_BDFLAG_TCP_UDP_CKSUM;
- if (m->m_flags & M_LASTFRAG)
- csum_flags |= TI_BDFLAG_IP_FRAG_END;
- else if (m->m_flags & M_FRAG)
- csum_flags |= TI_BDFLAG_IP_FRAG;
- }
+ if (m->m_pkthdr.csum_flags & CSUM_IP)
+ csum_flags |= TI_BDFLAG_IP_CKSUM;
+ if (m->m_pkthdr.csum_flags & (CSUM_TCP | CSUM_UDP))
+ csum_flags |= TI_BDFLAG_TCP_UDP_CKSUM;
frag = sc->ti_tx_saved_prodidx;
for (i = 0; i < nseg; i++) {
___
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: r242426 - head/sys/dev/bge
Author: yongari
Date: Thu Nov 1 06:02:27 2012
New Revision: 242426
URL: http://svn.freebsd.org/changeset/base/242426
Log:
TCP/UDP checksum offloading feature for IP fragmented datagram was
removed in r99417. bge(4) controllers can do TCP checksum offload
for IP fragmented datagrams but unlike ti(4), it lacks UDP checksum
offloading for IP fragmented datagrams. The problem was bge(4)
blindly requested TCP/UDP checksum for IP fragmented datagrams such
that it resulted in corrupted UDP datagrams before r99417.
Remove remaining code for TCP checksum offloading for IP fragmented
datagrams which should have been removed in r99417.
Modified:
head/sys/dev/bge/if_bge.c
Modified: head/sys/dev/bge/if_bge.c
==
--- head/sys/dev/bge/if_bge.c Thu Nov 1 05:39:21 2012(r242425)
+++ head/sys/dev/bge/if_bge.c Thu Nov 1 06:02:27 2012(r242426)
@@ -5103,10 +5103,6 @@ bge_encap(struct bge_softc *sc, struct m
return (error);
}
}
- if (m->m_flags & M_LASTFRAG)
- csum_flags |= BGE_TXBDFLAG_IP_FRAG_END;
- else if (m->m_flags & M_FRAG)
- csum_flags |= BGE_TXBDFLAG_IP_FRAG;
}
if ((m->m_pkthdr.csum_flags & CSUM_TSO) == 0) {
@@ -5228,29 +5224,6 @@ bge_start_locked(struct ifnet *ifp)
break;
/*
-* XXX
-* The code inside the if() block is never reached since we
-* must mark CSUM_IP_FRAGS in our if_hwassist to start getting
-* requests to checksum TCP/UDP in a fragmented packet.
-*
-* XXX
-* safety overkill. If this is a fragmented packet chain
-* with delayed TCP/UDP checksums, then only encapsulate
-* it if we have enough descriptors to handle the entire
-* chain at once.
-* (paranoia -- may not actually be needed)
-*/
- if (m_head->m_flags & M_FIRSTFRAG &&
- m_head->m_pkthdr.csum_flags & (CSUM_DELAY_DATA)) {
- if ((BGE_TX_RING_CNT - sc->bge_txcnt) <
- m_head->m_pkthdr.csum_data + 16) {
- IFQ_DRV_PREPEND(&ifp->if_snd, m_head);
- ifp->if_drv_flags |= IFF_DRV_OACTIVE;
- break;
- }
- }
-
- /*
* Pack the data into the transmit ring. If we
* don't have room, set the OACTIVE flag and wait
* for the NIC to drain the ring.
___
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: r242425 - head/sys/dev/ti
so where'd this happen? interleaved TX nowdays via if_transmit() ?
Adrian
On 31 October 2012 22:39, Pyun YongHyeon wrote:
> Author: yongari
> Date: Thu Nov 1 05:39:21 2012
> New Revision: 242425
> URL: http://svn.freebsd.org/changeset/base/242425
>
> Log:
> Remove TCP/UDP checksum offloading feature for IP fragmented
> datagrams. Traditionally upper stack fragmented packets without
> computing TCP/UDP checksum and these datagrams were passed to
> driver. But there are chances that other packets slip into the
> interface queue in SMP world. If this happens firmware running on
> MIPS 4000 processor in the controller would see mixed packets and
> it shall send out corrupted packets.
> While I'm here simplify checksum offloading setup.
>
> MFC After:1 week
>
> Modified:
> head/sys/dev/ti/if_ti.c
>
> Modified: head/sys/dev/ti/if_ti.c
> ==
> --- head/sys/dev/ti/if_ti.c Thu Nov 1 04:07:08 2012(r242424)
> +++ head/sys/dev/ti/if_ti.c Thu Nov 1 05:39:21 2012(r242425)
> @@ -127,7 +127,7 @@ __FBSDID("$FreeBSD$");
>
> #include
>
> -#define TI_CSUM_FEATURES (CSUM_IP | CSUM_TCP | CSUM_UDP |
> CSUM_IP_FRAGS)
> +#define TI_CSUM_FEATURES (CSUM_IP | CSUM_TCP | CSUM_UDP)
> /*
> * We can only turn on header splitting if we're using extended receive
> * BDs.
> @@ -3082,16 +3082,10 @@ ti_encap(struct ti_softc *sc, struct mbu
>
> m = *m_head;
> csum_flags = 0;
> - if (m->m_pkthdr.csum_flags) {
> - if (m->m_pkthdr.csum_flags & CSUM_IP)
> - csum_flags |= TI_BDFLAG_IP_CKSUM;
> - if (m->m_pkthdr.csum_flags & (CSUM_TCP | CSUM_UDP))
> - csum_flags |= TI_BDFLAG_TCP_UDP_CKSUM;
> - if (m->m_flags & M_LASTFRAG)
> - csum_flags |= TI_BDFLAG_IP_FRAG_END;
> - else if (m->m_flags & M_FRAG)
> - csum_flags |= TI_BDFLAG_IP_FRAG;
> - }
> + if (m->m_pkthdr.csum_flags & CSUM_IP)
> + csum_flags |= TI_BDFLAG_IP_CKSUM;
> + if (m->m_pkthdr.csum_flags & (CSUM_TCP | CSUM_UDP))
> + csum_flags |= TI_BDFLAG_TCP_UDP_CKSUM;
>
> frag = sc->ti_tx_saved_prodidx;
> for (i = 0; i < nseg; i++) {
___
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: r242425 - head/sys/dev/ti
On Wed, Oct 31, 2012 at 11:16:43PM -0700, Adrian Chadd wrote: > so where'd this happen? interleaved TX nowdays via if_transmit() ? > if_output after fragmentation. > > > Adrian > > On 31 October 2012 22:39, Pyun YongHyeon wrote: > > Author: yongari > > Date: Thu Nov 1 05:39:21 2012 > > New Revision: 242425 > > URL: http://svn.freebsd.org/changeset/base/242425 > > > > Log: > > Remove TCP/UDP checksum offloading feature for IP fragmented > > datagrams. Traditionally upper stack fragmented packets without > > computing TCP/UDP checksum and these datagrams were passed to > > driver. But there are chances that other packets slip into the > > interface queue in SMP world. If this happens firmware running on > > MIPS 4000 processor in the controller would see mixed packets and > > it shall send out corrupted packets. > > While I'm here simplify checksum offloading setup. ___ 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: r242427 - head/share/man/man4
Author: joel (doc committer) Date: Thu Nov 1 07:51:50 2012 New Revision: 242427 URL: http://svn.freebsd.org/changeset/base/242427 Log: Minor mdoc fix. Modified: head/share/man/man4/textdump.4 Modified: head/share/man/man4/textdump.4 == --- head/share/man/man4/textdump.4 Thu Nov 1 06:02:27 2012 (r242426) +++ head/share/man/man4/textdump.4 Thu Nov 1 07:51:50 2012 (r242427) @@ -149,7 +149,7 @@ sets textdumps to be the default manner will be no need to .Xr sysctl 8 or use the -.Cr textdump set +.Ic textdump set .Xr ddb 8 commands. .It Cd TEXTDUMP_VERBOSE ___ 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: r242428 - head/share/man/man4
Author: joel (doc committer) Date: Thu Nov 1 07:53:21 2012 New Revision: 242428 URL: http://svn.freebsd.org/changeset/base/242428 Log: Nuke whitespace. Modified: head/share/man/man4/textdump.4 Modified: head/share/man/man4/textdump.4 == --- head/share/man/man4/textdump.4 Thu Nov 1 07:51:50 2012 (r242427) +++ head/share/man/man4/textdump.4 Thu Nov 1 07:53:21 2012 (r242428) @@ -36,7 +36,6 @@ .Sh SYNOPSIS .Cd options KDB .Cd options DDB - .Cd options TEXTDUMP_VERBOSE .Cd options TEXTDUMP_PREFERRED .Sh DESCRIPTION @@ -121,7 +120,7 @@ sysctl to 1 using it is possible to request that the next dump be a textdump. One can also directly trigger a textdump in .Xr ddb 4 -by running the command +by running the command .Ic textdump dump . .Pp If at the @@ -144,7 +143,7 @@ Additional kernel .Xr config 8 options: .Bl -tag -width TEXTDUMP_PREFERRED -.It Cd TEXTDUMP_PREFERRED +.It Cd TEXTDUMP_PREFERRED sets textdumps to be the default manner of doing dumps. This means there will be no need to .Xr sysctl 8 ___ 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: r242429 - head/lib/libc/sys
Author: jilles Date: Thu Nov 1 09:38:28 2012 New Revision: 242429 URL: http://svn.freebsd.org/changeset/base/242429 Log: fcntl(2): Fix typos in name of constant "F_DUP2FD_CLOEXEC". MFC after:1 week Modified: head/lib/libc/sys/fcntl.2 Modified: head/lib/libc/sys/fcntl.2 == --- head/lib/libc/sys/fcntl.2 Thu Nov 1 07:53:21 2012(r242428) +++ head/lib/libc/sys/fcntl.2 Thu Nov 1 09:38:28 2012(r242429) @@ -94,7 +94,7 @@ It is functionally equivalent to .Bd -literal -offset indent dup2(fd, arg) .Ed -.It Dv F_DU2PFD_CLOEXEC +.It Dv F_DUP2FD_CLOEXEC Like .Dv F_DUP2FD , but the @@ -104,7 +104,7 @@ flag associated with the new file descri The .Dv F_DUP2FD and -.Dv F_DUP2DF_CLOEXEC +.Dv F_DUP2FD_CLOEXEC constants are not portable, so they should not be used if portability is needed. Use ___ 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: r242402 - in head/sys: kern vm
On Wed, Oct 31, 2012 at 06:33:51PM +, Attilio Rao wrote: A> > Doesn't this padding to cache line size only help x86 processors in an A> > SMP kernel? I was expecting to see some #ifdef SMP so that we don't pay A> > a big price for no gain in small-memory ARM systems and such. But maybe A> > I'm misunderstanding the reason for the padding. A> A> I didn't want to do this because this would be meaning that SMP option A> may become a completely killer for modules/kernel ABI compatibility. Do we support loading non-SMP modules on SMP kernel and vice versa? -- Totus tuus, Glebius. ___ 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: r242402 - in head/sys: kern vm
On 11/1/12, Gleb Smirnoff wrote: > On Wed, Oct 31, 2012 at 06:33:51PM +, Attilio Rao wrote: > A> > Doesn't this padding to cache line size only help x86 processors in an > A> > SMP kernel? I was expecting to see some #ifdef SMP so that we don't > pay > A> > a big price for no gain in small-memory ARM systems and such. But > maybe > A> > I'm misunderstanding the reason for the padding. > A> > A> I didn't want to do this because this would be meaning that SMP option > A> may become a completely killer for modules/kernel ABI compatibility. > > Do we support loading non-SMP modules on SMP kernel and vice versa? Actually that's my point, we do. Attilio -- Peace can only be achieved by understanding - A. Einstein ___ 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: r242430 - head/usr.bin/sort
Author: gabor
Date: Thu Nov 1 11:38:34 2012
New Revision: 242430
URL: http://svn.freebsd.org/changeset/base/242430
Log:
- Portability changes for ARM
- Allow larger sort memory on 64-bit platforms
Submitted by: Oleg Moskalenko
Modified:
head/usr.bin/sort/bwstring.c
head/usr.bin/sort/bwstring.h
head/usr.bin/sort/coll.c
head/usr.bin/sort/coll.h
head/usr.bin/sort/file.c
head/usr.bin/sort/file.h
head/usr.bin/sort/radixsort.c
head/usr.bin/sort/sort.c
head/usr.bin/sort/sort.h
Modified: head/usr.bin/sort/bwstring.c
==
--- head/usr.bin/sort/bwstring.cThu Nov 1 09:38:28 2012
(r242429)
+++ head/usr.bin/sort/bwstring.cThu Nov 1 11:38:34 2012
(r242430)
@@ -69,7 +69,7 @@ initialise_months(void)
continue;
if (debug_sort)
printf("month[%d]=%s\n", i, tmp);
- len = strlen(tmp);
+ len = strlen((char*)tmp);
if (len < 1)
continue;
while (isblank(*tmp))
@@ -95,13 +95,13 @@ initialise_months(void)
continue;
if (debug_sort)
printf("month[%d]=%s\n", i, tmp);
- len = strlen(tmp);
+ len = strlen((char*)tmp);
if (len < 1)
continue;
while (isblank(*tmp))
++tmp;
m = sort_malloc(SIZEOF_WCHAR_STRING(len + 1));
- if (mbstowcs(m, tmp, len) == ((size_t) -1))
+ if (mbstowcs(m, (char*)tmp, len) == ((size_t)
-1))
continue;
m[len] = L'\0';
for (unsigned int j = 0; j < len; j++)
@@ -421,7 +421,7 @@ bwsnocpy(struct bwstring *dst, const str
* The output is ended either with '\n' (nl == true)
* or '\0' (nl == false).
*/
-int
+size_t
bwsfwrite(struct bwstring *bws, FILE *f, bool zero_ended)
{
@@ -442,11 +442,11 @@ bwsfwrite(struct bwstring *bws, FILE *f,
} else {
wchar_t eols;
- int printed = 0;
+ size_t printed = 0;
eols = zero_ended ? btowc('\0') : btowc('\n');
- while (printed < (int) BWSLEN(bws)) {
+ while (printed < BWSLEN(bws)) {
const wchar_t *s = bws->data.wstr + printed;
if (*s == L'\0') {
@@ -479,7 +479,7 @@ bwsfwrite(struct bwstring *bws, FILE *f,
struct bwstring *
bwsfgetln(FILE *f, size_t *len, bool zero_ended, struct reader_buffer *rb)
{
- wchar_t eols;
+ wint_t eols;
eols = zero_ended ? btowc('\0') : btowc('\n');
@@ -494,7 +494,7 @@ bwsfgetln(FILE *f, size_t *len, bool zer
return (NULL);
}
if (*len > 0) {
- if (ret[*len - 1] == eols)
+ if (ret[*len - 1] == (wchar_t)eols)
--(*len);
}
return (bwssbdup(ret, *len));
@@ -513,11 +513,9 @@ bwsfgetln(FILE *f, size_t *len, bool zer
if (ret[*len - 1] == '\n')
--(*len);
}
- return (bwscsbdup(ret, *len));
+ return (bwscsbdup((unsigned char*)ret, *len));
} else {
- wchar_t c = 0;
-
*len = 0;
if (feof(f))
@@ -532,6 +530,8 @@ bwsfgetln(FILE *f, size_t *len, bool zer
if (MB_CUR_MAX == 1)
while (!feof(f)) {
+ int c;
+
c = fgetc(f);
if (c == EOF) {
@@ -553,6 +553,8 @@ bwsfgetln(FILE *f, size_t *len, bool zer
}
else
while (!feof(f)) {
+ wint_t c = 0;
+
c = fgetwc(f);
if (c == WEOF) {
@@ -750,7 +752,7 @@ bwscoll(const struct bwstring *bws1, con
} else if (s2[i] == 0)
return (+1);
- res = strcoll(s1 + i, s2 + i);
+ res = strcoll((const char*)(s1
+ i), (const char*)(s2 + i));
if (res)
return (res);
@
Re: svn commit: r242402 - in head/sys: kern vm
On 10/31/12, Andre Oppermann wrote: > On 31.10.2012 19:10, Attilio Rao wrote: >> On Wed, Oct 31, 2012 at 6:07 PM, Attilio Rao wrote: >>> Author: attilio >>> Date: Wed Oct 31 18:07:18 2012 >>> New Revision: 242402 >>> URL: http://svn.freebsd.org/changeset/base/242402 >>> >>> Log: >>>Rework the known mutexes to benefit about staying on their own >>>cache line in order to avoid manual frobbing but using >>>struct mtx_padalign. >> >> Interested developers can now dig and look for other mutexes to >> convert and just do it. >> Please, however, try to enclose a description about the benchmark >> which lead you believe the necessity to pad the mutex and possibly >> some numbers, in particular when the lock belongs to structures or the >> ABI itself. >> >> Next steps involve porting the same mtx(9) changes to rwlock(9) and >> port pvh global pmap lock to rwlock_padalign. > > I'd say for an rwlock you can make it unconditional. The very purpose > of it is to be aquired by multiple CPU's causing cache line dirtying > for every concurrent reader. Rwlocks are only ever used because multiple > concurrent readers are expected. I thought about it, but I think the same arguments as for mutexes remains. The real problem is that having default rwlocks pad-aligned will put showstoppers for their usage in sensitive structures. For example, I have plans to use them in vm_object at some point to replace VM_OBJECT_LOCK and I do want to avoid the extra-bloat for such structures. Also, please keep in mind that there is no direct relation between "read acquisition" and "high contention" with the latter being the real reason for having pad-aligned locks. Attilio -- Peace can only be achieved by understanding - A. Einstein ___ 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: r242431 - head/sys/arm/mv/armadaxp
Author: cognet Date: Thu Nov 1 12:26:31 2012 New Revision: 242431 URL: http://svn.freebsd.org/changeset/base/242431 Log: Fix build for SMP. Submitted by: Giovanni Trematerra Modified: head/sys/arm/mv/armadaxp/armadaxp_mp.c Modified: head/sys/arm/mv/armadaxp/armadaxp_mp.c == --- head/sys/arm/mv/armadaxp/armadaxp_mp.c Thu Nov 1 11:38:34 2012 (r242430) +++ head/sys/arm/mv/armadaxp/armadaxp_mp.c Thu Nov 1 12:26:31 2012 (r242431) @@ -179,7 +179,7 @@ platform_mp_start_ap(void) for (cpu_num = 1; cpu_num < mp_ncpus; cpu_num++ ) bus_space_write_4(fdtbus_bs_tag, CPU_PMU(cpu_num), CPU_PMU_BOOT, - pmap_kextract(mpentry)); + pmap_kextract((vm_offset_t)mpentry)); cpu_idcache_wbinv_all(); ___ 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: r242402 - in head/sys: kern vm
On Thu, 2012-11-01 at 10:42 +, Attilio Rao wrote: > On 11/1/12, Gleb Smirnoff wrote: > > On Wed, Oct 31, 2012 at 06:33:51PM +, Attilio Rao wrote: > > A> > Doesn't this padding to cache line size only help x86 processors in an > > A> > SMP kernel? I was expecting to see some #ifdef SMP so that we don't > > pay > > A> > a big price for no gain in small-memory ARM systems and such. But > > maybe > > A> > I'm misunderstanding the reason for the padding. > > A> > > A> I didn't want to do this because this would be meaning that SMP option > > A> may become a completely killer for modules/kernel ABI compatibility. > > > > Do we support loading non-SMP modules on SMP kernel and vice versa? > > Actually that's my point, we do. > > Attilio > > Well we've got other similar problems lurking then. What about a module compiled on an arm system that had #define CACHE_LINE_SIZE 32 and then it gets run on a different arm system whose kernel is compiled with #define CACHE_LINE_SIZE 64? -- Ian ___ 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: r242402 - in head/sys: kern vm
On Thu, Nov 1, 2012 at 2:01 PM, Ian Lepore wrote: > On Thu, 2012-11-01 at 10:42 +, Attilio Rao wrote: >> On 11/1/12, Gleb Smirnoff wrote: >> > On Wed, Oct 31, 2012 at 06:33:51PM +, Attilio Rao wrote: >> > A> > Doesn't this padding to cache line size only help x86 processors in an >> > A> > SMP kernel? I was expecting to see some #ifdef SMP so that we don't >> > pay >> > A> > a big price for no gain in small-memory ARM systems and such. But >> > maybe >> > A> > I'm misunderstanding the reason for the padding. >> > A> >> > A> I didn't want to do this because this would be meaning that SMP option >> > A> may become a completely killer for modules/kernel ABI compatibility. >> > >> > Do we support loading non-SMP modules on SMP kernel and vice versa? >> >> Actually that's my point, we do. >> >> Attilio >> >> > > Well we've got other similar problems lurking then. What about a module > compiled on an arm system that had #define CACHE_LINE_SIZE 32 and then > it gets run on a different arm system whose kernel is compiled with > #define CACHE_LINE_SIZE 64? That should not happen. Is that a real case where you build a module for an ARM family and want to run against a kernel compiled for another? CACHE_LINE_SIZE must not change during a STABLE release lifetime, of course, for the same arch. Attilio -- Peace can only be achieved by understanding - A. Einstein ___ 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: r242402 - in head/sys: kern vm
On Thu, Nov 1, 2012 at 2:05 PM, Attilio Rao wrote: > On Thu, Nov 1, 2012 at 2:01 PM, Ian Lepore > wrote: >> On Thu, 2012-11-01 at 10:42 +, Attilio Rao wrote: >>> On 11/1/12, Gleb Smirnoff wrote: >>> > On Wed, Oct 31, 2012 at 06:33:51PM +, Attilio Rao wrote: >>> > A> > Doesn't this padding to cache line size only help x86 processors in >>> > an >>> > A> > SMP kernel? I was expecting to see some #ifdef SMP so that we don't >>> > pay >>> > A> > a big price for no gain in small-memory ARM systems and such. But >>> > maybe >>> > A> > I'm misunderstanding the reason for the padding. >>> > A> >>> > A> I didn't want to do this because this would be meaning that SMP option >>> > A> may become a completely killer for modules/kernel ABI compatibility. >>> > >>> > Do we support loading non-SMP modules on SMP kernel and vice versa? >>> >>> Actually that's my point, we do. >>> >>> Attilio >>> >>> >> >> Well we've got other similar problems lurking then. What about a module >> compiled on an arm system that had #define CACHE_LINE_SIZE 32 and then >> it gets run on a different arm system whose kernel is compiled with >> #define CACHE_LINE_SIZE 64? > > That should not happen. Is that a real case where you build a module > for an ARM family and want to run against a kernel compiled for > another? Besides that, the ARM CACHE_LINE_SIZE is defined in the shared headers so there is no way this can be a problem. Attilio -- Peace can only be achieved by understanding - A. Einstein ___ 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: r242402 - in head/sys: kern vm
On 01.11.2012 12:53, Attilio Rao wrote: On 10/31/12, Andre Oppermann wrote: On 31.10.2012 19:10, Attilio Rao wrote: On Wed, Oct 31, 2012 at 6:07 PM, Attilio Rao wrote: Author: attilio Date: Wed Oct 31 18:07:18 2012 New Revision: 242402 URL: http://svn.freebsd.org/changeset/base/242402 Log: Rework the known mutexes to benefit about staying on their own cache line in order to avoid manual frobbing but using struct mtx_padalign. Interested developers can now dig and look for other mutexes to convert and just do it. Please, however, try to enclose a description about the benchmark which lead you believe the necessity to pad the mutex and possibly some numbers, in particular when the lock belongs to structures or the ABI itself. Next steps involve porting the same mtx(9) changes to rwlock(9) and port pvh global pmap lock to rwlock_padalign. I'd say for an rwlock you can make it unconditional. The very purpose of it is to be aquired by multiple CPU's causing cache line dirtying for every concurrent reader. Rwlocks are only ever used because multiple concurrent readers are expected. I thought about it, but I think the same arguments as for mutexes remains. The real problem is that having default rwlocks pad-aligned will put showstoppers for their usage in sensitive structures. For example, I have plans to use them in vm_object at some point to replace VM_OBJECT_LOCK and I do want to avoid the extra-bloat for such structures. Also, please keep in mind that there is no direct relation between "read acquisition" and "high contention" with the latter being the real reason for having pad-aligned locks. I do not agree. If there is no contention then there is no need for a rwlock, a normal mutex would be sufficient. A rwlock is used when multiple concurrent readers are expected. Each read lock and unlock dirties the cache line for all other CPU's. Please note that I don't want to prevent you from doing the work all over for rwlocks. It's just that the use case for a non-padded rwlock is very narrow. -- Andre ___ 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: r242402 - in head/sys: kern vm
On Thu, 2012-11-01 at 14:07 +, Attilio Rao wrote: > On Thu, Nov 1, 2012 at 2:05 PM, Attilio Rao wrote: > > On Thu, Nov 1, 2012 at 2:01 PM, Ian Lepore > > wrote: > >> On Thu, 2012-11-01 at 10:42 +, Attilio Rao wrote: > >>> On 11/1/12, Gleb Smirnoff wrote: > >>> > On Wed, Oct 31, 2012 at 06:33:51PM +, Attilio Rao wrote: > >>> > A> > Doesn't this padding to cache line size only help x86 processors > >>> > in an > >>> > A> > SMP kernel? I was expecting to see some #ifdef SMP so that we > >>> > don't > >>> > pay > >>> > A> > a big price for no gain in small-memory ARM systems and such. But > >>> > maybe > >>> > A> > I'm misunderstanding the reason for the padding. > >>> > A> > >>> > A> I didn't want to do this because this would be meaning that SMP > >>> > option > >>> > A> may become a completely killer for modules/kernel ABI compatibility. > >>> > > >>> > Do we support loading non-SMP modules on SMP kernel and vice versa? > >>> > >>> Actually that's my point, we do. > >>> > >>> Attilio > >>> > >>> > >> > >> Well we've got other similar problems lurking then. What about a module > >> compiled on an arm system that had #define CACHE_LINE_SIZE 32 and then > >> it gets run on a different arm system whose kernel is compiled with > >> #define CACHE_LINE_SIZE 64? > > > > That should not happen. Is that a real case where you build a module > > for an ARM family and want to run against a kernel compiled for > > another? > > Besides that, the ARM CACHE_LINE_SIZE is defined in the shared headers > so there is no way this can be a problem. I've been under the impression that in the ARM and MIPS worlds, the cache line size can change from one family/series of chips to another, just as support for SMP can change from one family to another. If I'm not mistaken in that assumption, then there can't be something like a generic arm module that will run on any arm kernel regardless of how the kernel was built, not if compile-time constants get cooked into the binaries in a way that affects the ABI/KBI. Back from some quick googling... yep, arm cortex-a8 processors have a 64-byte cache line size. Maybe we don't support those yet, which is why the value appears to be constant in arm param.h right now. -- Ian ___ 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: r242421 - head/sys/dev/ixgbe
On 01.11.2012 00:50, Jack F Vogel wrote: Author: jfv Date: Wed Oct 31 23:50:36 2012 New Revision: 242421 URL: http://svn.freebsd.org/changeset/base/242421 Log: A few important fixes: - Testing TSO6 has led me to discover that HW RSC is a problematic feature, it is ONLY designed to work with IPv4 in the first place, and if IP forwarding is done it can't be disabled as LRO in the stack, also initial testing we've done at Intel shows an equal performance using TSO[46] on the TX and LRO on RX, if you ran older code on 82599 or later hardware you actually could have detrimental performance for this reason. So I am disabling the feature by default and all our adapters will now use LRO instead. Yes, it's very important that LRO is *not* used when forwarding is enabled (= acting as a router). - If you have flow control off and multiple queues it was possible when the buffer of one queue becomes full that all RX movement is stalled, to eliminate this problem a feature bit is now set that will allow packets to be dropped when full rather than stall. Note, the default is to have flow control on, and this keeps this from happening. - Because of the recent fixes in the stack, LRO is now auto-disabled when problematic, so I have decided to enable it by default in the capabilities in the driver. A very important cautionary note here: LRO is only good when combined with very low RTTs (that is in LAN environments). On everything over 5ms is breaks the TCP ACK clock badly and performance will suffer greatly. This is because every ACK increases the congestion window. With a greatly reduced ACK rate the ramping up of CWND on startup and after a loss event is severely limited. Combined with ABC (appropriate byte counting) where the CWND increases only once per ACK by at most one MSS the effect is greatly pronounced as well. The higher the RTT goes the worse the effects become. I haven't checked yet whether our soft-LRO does ACK compression or not. If it does, we need a workaround and some tcp_input magic to reduce the negative impact. I'm looking into it. - There are some 1G modules used by some customers, a couple small tweaks to properly support those in the media code. - A note: we have now done some testing of TSO6 and using LRO with IPv6 and it all works great!! Seeing line rate in both directions in best cases. Thanks bz for your excellent work!! Indeed! Modified: head/sys/dev/ixgbe/ixgbe.c -- Andre ___ 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: r242402 - in head/sys: kern vm
On 11/1/12, Ian Lepore wrote: > On Thu, 2012-11-01 at 14:07 +, Attilio Rao wrote: >> On Thu, Nov 1, 2012 at 2:05 PM, Attilio Rao wrote: >> > On Thu, Nov 1, 2012 at 2:01 PM, Ian Lepore >> > wrote: >> >> On Thu, 2012-11-01 at 10:42 +, Attilio Rao wrote: >> >>> On 11/1/12, Gleb Smirnoff wrote: >> >>> > On Wed, Oct 31, 2012 at 06:33:51PM +, Attilio Rao wrote: >> >>> > A> > Doesn't this padding to cache line size only help x86 >> >>> > processors in an >> >>> > A> > SMP kernel? I was expecting to see some #ifdef SMP so that we >> >>> > don't >> >>> > pay >> >>> > A> > a big price for no gain in small-memory ARM systems and such. >> >>> > But >> >>> > maybe >> >>> > A> > I'm misunderstanding the reason for the padding. >> >>> > A> >> >>> > A> I didn't want to do this because this would be meaning that SMP >> >>> > option >> >>> > A> may become a completely killer for modules/kernel ABI >> >>> > compatibility. >> >>> > >> >>> > Do we support loading non-SMP modules on SMP kernel and vice versa? >> >>> >> >>> Actually that's my point, we do. >> >>> >> >>> Attilio >> >>> >> >>> >> >> >> >> Well we've got other similar problems lurking then. What about a >> >> module >> >> compiled on an arm system that had #define CACHE_LINE_SIZE 32 and then >> >> it gets run on a different arm system whose kernel is compiled with >> >> #define CACHE_LINE_SIZE 64? >> > >> > That should not happen. Is that a real case where you build a module >> > for an ARM family and want to run against a kernel compiled for >> > another? >> >> Besides that, the ARM CACHE_LINE_SIZE is defined in the shared headers >> so there is no way this can be a problem. > > I've been under the impression that in the ARM and MIPS worlds, the > cache line size can change from one family/series of chips to another, > just as support for SMP can change from one family to another. If I'm > not mistaken in that assumption, then there can't be something like a > generic arm module that will run on any arm kernel regardless of how the > kernel was built, not if compile-time constants get cooked into the > binaries in a way that affects the ABI/KBI. I'm far from being an ARM expert so I trust what you say. This only means you cannot build a module for a family and expect to retain ABI compatibility among all the ARM families. If cache-lines are different I don't think there is much we can do, which has nothing to do with pad-align locking. Attilio -- Peace can only be achieved by understanding - A. Einstein ___ 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: r242402 - in head/sys: kern vm
On Thu, 2012-11-01 at 14:43 +, Attilio Rao wrote: > On 11/1/12, Ian Lepore wrote: > > On Thu, 2012-11-01 at 14:07 +, Attilio Rao wrote: > >> On Thu, Nov 1, 2012 at 2:05 PM, Attilio Rao wrote: > >> > On Thu, Nov 1, 2012 at 2:01 PM, Ian Lepore > >> > wrote: > >> >> On Thu, 2012-11-01 at 10:42 +, Attilio Rao wrote: > >> >>> On 11/1/12, Gleb Smirnoff wrote: > >> >>> > On Wed, Oct 31, 2012 at 06:33:51PM +, Attilio Rao wrote: > >> >>> > A> > Doesn't this padding to cache line size only help x86 > >> >>> > processors in an > >> >>> > A> > SMP kernel? I was expecting to see some #ifdef SMP so that we > >> >>> > don't > >> >>> > pay > >> >>> > A> > a big price for no gain in small-memory ARM systems and such. > >> >>> > But > >> >>> > maybe > >> >>> > A> > I'm misunderstanding the reason for the padding. > >> >>> > A> > >> >>> > A> I didn't want to do this because this would be meaning that SMP > >> >>> > option > >> >>> > A> may become a completely killer for modules/kernel ABI > >> >>> > compatibility. > >> >>> > > >> >>> > Do we support loading non-SMP modules on SMP kernel and vice versa? > >> >>> > >> >>> Actually that's my point, we do. > >> >>> > >> >>> Attilio > >> >>> > >> >>> > >> >> > >> >> Well we've got other similar problems lurking then. What about a > >> >> module > >> >> compiled on an arm system that had #define CACHE_LINE_SIZE 32 and then > >> >> it gets run on a different arm system whose kernel is compiled with > >> >> #define CACHE_LINE_SIZE 64? > >> > > >> > That should not happen. Is that a real case where you build a module > >> > for an ARM family and want to run against a kernel compiled for > >> > another? > >> > >> Besides that, the ARM CACHE_LINE_SIZE is defined in the shared headers > >> so there is no way this can be a problem. > > > > I've been under the impression that in the ARM and MIPS worlds, the > > cache line size can change from one family/series of chips to another, > > just as support for SMP can change from one family to another. If I'm > > not mistaken in that assumption, then there can't be something like a > > generic arm module that will run on any arm kernel regardless of how the > > kernel was built, not if compile-time constants get cooked into the > > binaries in a way that affects the ABI/KBI. > > I'm far from being an ARM expert so I trust what you say. > This only means you cannot build a module for a family and expect to > retain ABI compatibility among all the ARM families. If cache-lines > are different I don't think there is much we can do, which has nothing > to do with pad-align locking. > I do a lot of work with armv4 and recently v5 chips, but nothing with the v6/v7 stuff yet, so I'm not really an expert on these issues either. I've heard some talk from the folks working on arm v6/v7 support about things like unified kernels and an arm GENERIC kernel config, but I'm pretty hazy myself on how that vision is shaping up. -- Ian ___ 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: r242432 - in head/sys: amd64/amd64 amd64/include x86/include
Author: kib
Date: Thu Nov 1 15:14:37 2012
New Revision: 242432
URL: http://svn.freebsd.org/changeset/base/242432
Log:
Provide the reading and display of the Standard Extended Features,
introduced with the IvyBridge CPUs. Provide the definitions for new
bits in CR3 and CR4 registers.
Tested by:avg, Michael Moll
MFC after:2 weeks
Modified:
head/sys/amd64/amd64/identcpu.c
head/sys/amd64/amd64/initcpu.c
head/sys/amd64/include/md_var.h
head/sys/x86/include/specialreg.h
Modified: head/sys/amd64/amd64/identcpu.c
==
--- head/sys/amd64/amd64/identcpu.c Thu Nov 1 12:26:31 2012
(r242431)
+++ head/sys/amd64/amd64/identcpu.c Thu Nov 1 15:14:37 2012
(r242432)
@@ -384,6 +384,18 @@ printcpuinfo(void)
);
}
+ if (cpu_stdext_feature != 0) {
+ printf("\n Standard Extended Features=0x%b",
+ cpu_stdext_feature,
+ "\020"
+ "\001GSFSBASE"
+ "\002TSCADJ"
+ "\010SMEP"
+ "\012ENHMOVSB"
+ "\013INVPCID"
+ );
+ }
+
if (via_feature_rng != 0 || via_feature_xcrypt != 0)
print_via_padlock_info();
@@ -501,6 +513,11 @@ identify_cpu(void)
}
}
+ if (cpu_high >= 7) {
+ cpuid_count(7, 0, regs);
+ cpu_stdext_feature = regs[1];
+ }
+
if (cpu_vendor_id == CPU_VENDOR_INTEL ||
cpu_vendor_id == CPU_VENDOR_AMD ||
cpu_vendor_id == CPU_VENDOR_CENTAUR) {
Modified: head/sys/amd64/amd64/initcpu.c
==
--- head/sys/amd64/amd64/initcpu.c Thu Nov 1 12:26:31 2012
(r242431)
+++ head/sys/amd64/amd64/initcpu.c Thu Nov 1 15:14:37 2012
(r242432)
@@ -72,6 +72,7 @@ u_int cpu_vendor_id; /* CPU vendor ID *
u_int cpu_fxsr; /* SSE enabled */
u_int cpu_mxcsr_mask; /* Valid bits in mxcsr */
u_int cpu_clflush_line_size = 32;
+u_int cpu_stdext_feature;
u_int cpu_max_ext_state_size;
SYSCTL_UINT(_hw, OID_AUTO, via_feature_rng, CTLFLAG_RD,
Modified: head/sys/amd64/include/md_var.h
==
--- head/sys/amd64/include/md_var.h Thu Nov 1 12:26:31 2012
(r242431)
+++ head/sys/amd64/include/md_var.h Thu Nov 1 15:14:37 2012
(r242432)
@@ -48,6 +48,7 @@ externu_int amd_pminfo;
extern u_int via_feature_rng;
extern u_int via_feature_xcrypt;
extern u_int cpu_clflush_line_size;
+extern u_int cpu_stdext_feature;
extern u_int cpu_fxsr;
extern u_int cpu_high;
extern u_int cpu_id;
Modified: head/sys/x86/include/specialreg.h
==
--- head/sys/x86/include/specialreg.h Thu Nov 1 12:26:31 2012
(r242431)
+++ head/sys/x86/include/specialreg.h Thu Nov 1 15:14:37 2012
(r242432)
@@ -52,6 +52,8 @@
#defineCR0_NW 0x2000 /* Not Write-through */
#defineCR0_CD 0x4000 /* Cache Disable */
+#defineCR3_PCID_SAVE 0x8000
+
/*
* Bits in PPro special registers
*/
@@ -66,7 +68,10 @@
#defineCR4_PCE 0x0100 /* Performance monitoring counter
enable */
#defineCR4_FXSR 0x0200 /* Fast FPU save/restore used by OS */
#defineCR4_XMM 0x0400 /* enable SIMD/MMX2 to use except 16 */
+#defineCR4_FSGSBASE 0x0001 /* Enable FS/GS BASE accessing
instructions */
+#defineCR4_PCIDE 0x0002/* Enable Context ID */
#defineCR4_XSAVE 0x0004/* XSETBV/XGETBV */
+#defineCR4_SMEP 0x0010 /* Supervisor-Mode Execution Prevention
*/
/*
* Bits in AMD64 special registers. EFER is 64 bits wide.
@@ -272,6 +277,12 @@
#defineAMDID_COREID_SIZE 0xf000
#defineAMDID_COREID_SIZE_SHIFT 12
+#defineCPUID_STDEXT_FSGSBASE 0x0001
+#defineCPUID_STDEXT_TSC_ADJUST 0x0002
+#defineCPUID_STDEXT_SMEP 0x0080
+#defineCPUID_STDEXT_ENH_MOVSB 0x0200
+#defineCPUID_STDEXT_INVPCID0x0400
+
/*
* CPUID manufacturers identifiers
*/
___
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: r242433 - head/sys/amd64/amd64
Author: kib
Date: Thu Nov 1 15:17:43 2012
New Revision: 242433
URL: http://svn.freebsd.org/changeset/base/242433
Log:
Enable the new instructions for reading and writing bases for %fs,
%gs, when supported. Note that WRFSBASE and WRGSBASE are not very
useful on FreeBSD right now, because a return from the kernel mode to
userspace reloads the bases specified by the sysarch(2) syscall, most
likely.
Enable the Supervisor Mode Execution Prevention (SMEP) when
supported. Since the loader(8) performs hand-off to the kernel with
the page tables which contradict the SMEP, postpone enabling the SMEP
on BSP until pmap switched for the proper kernel tables.
Debugged with the help from: avg
Tested by:avg, Michael Moll
MFC after:1 month
Modified:
head/sys/amd64/amd64/initcpu.c
head/sys/amd64/amd64/pmap.c
Modified: head/sys/amd64/amd64/initcpu.c
==
--- head/sys/amd64/amd64/initcpu.c Thu Nov 1 15:14:37 2012
(r242432)
+++ head/sys/amd64/amd64/initcpu.c Thu Nov 1 15:17:43 2012
(r242433)
@@ -34,6 +34,7 @@ __FBSDID("$FreeBSD$");
#include
#include
+#include
#include
#include
@@ -153,11 +154,25 @@ void
initializecpu(void)
{
uint64_t msr;
+ uint32_t cr4;
+ cr4 = rcr4();
if ((cpu_feature & CPUID_XMM) && (cpu_feature & CPUID_FXSR)) {
- load_cr4(rcr4() | CR4_FXSR | CR4_XMM);
+ cr4 |= CR4_FXSR | CR4_XMM;
cpu_fxsr = hw_instruction_sse = 1;
}
+ if (cpu_stdext_feature & CPUID_STDEXT_FSGSBASE)
+ cr4 |= CR4_FSGSBASE;
+
+ /*
+* Postpone enabling the SMEP on the boot CPU until the page
+* tables are switched from the boot loader identity mapping
+* to the kernel tables. The boot loader enables the U bit in
+* its tables.
+*/
+ if (!IS_BSP() && (cpu_stdext_feature & CPUID_STDEXT_SMEP))
+ cr4 |= CR4_SMEP;
+ load_cr4(cr4);
if ((amd_feature & AMDID_NX) != 0) {
msr = rdmsr(MSR_EFER) | EFER_NXE;
wrmsr(MSR_EFER, msr);
Modified: head/sys/amd64/amd64/pmap.c
==
--- head/sys/amd64/amd64/pmap.c Thu Nov 1 15:14:37 2012(r242432)
+++ head/sys/amd64/amd64/pmap.c Thu Nov 1 15:17:43 2012(r242433)
@@ -622,6 +622,8 @@ pmap_bootstrap(vm_paddr_t *firstaddr)
/* XXX do %cr0 as well */
load_cr4(rcr4() | CR4_PGE | CR4_PSE);
load_cr3(KPML4phys);
+ if (cpu_stdext_feature & CPUID_STDEXT_SMEP)
+ load_cr4(rcr4() | CR4_SMEP);
/*
* Initialize the kernel pmap (which is statically allocated).
___
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: r242434 - head/sys/vm
Author: alc
Date: Thu Nov 1 16:20:02 2012
New Revision: 242434
URL: http://svn.freebsd.org/changeset/base/242434
Log:
In general, we call pmap_remove_all() before calling vm_page_cache(). So,
the call to pmap_remove_all() within vm_page_cache() is usually redundant.
This change eliminates that call to pmap_remove_all() and introduces a
call to pmap_remove_all() before vm_page_cache() in the one place where
it didn't already exist.
When iterating over a paging queue, if the object containing the current
page has a zero reference count, then the page can't have any managed
mappings. So, a call to pmap_remove_all() is pointless.
Change a panic() call in vm_page_cache() to a KASSERT().
MFC after:6 weeks
Modified:
head/sys/vm/vm_page.c
head/sys/vm/vm_pageout.c
Modified: head/sys/vm/vm_page.c
==
--- head/sys/vm/vm_page.c Thu Nov 1 15:17:43 2012(r242433)
+++ head/sys/vm/vm_page.c Thu Nov 1 16:20:02 2012(r242434)
@@ -2277,9 +2277,9 @@ vm_page_cache(vm_page_t m)
if ((m->oflags & (VPO_UNMANAGED | VPO_BUSY)) || m->busy ||
m->hold_count || m->wire_count)
panic("vm_page_cache: attempting to cache busy page");
- pmap_remove_all(m);
- if (m->dirty != 0)
- panic("vm_page_cache: page %p is dirty", m);
+ KASSERT(!pmap_page_is_mapped(m),
+ ("vm_page_cache: page %p is mapped", m));
+ KASSERT(m->dirty == 0, ("vm_page_cache: page %p is dirty", m));
if (m->valid == 0 || object->type == OBJT_DEFAULT ||
(object->type == OBJT_SWAP &&
!vm_pager_has_page(object, m->pindex, NULL, NULL))) {
Modified: head/sys/vm/vm_pageout.c
==
--- head/sys/vm/vm_pageout.cThu Nov 1 15:17:43 2012(r242433)
+++ head/sys/vm/vm_pageout.cThu Nov 1 16:20:02 2012(r242434)
@@ -594,7 +594,7 @@ vm_pageout_launder(int queue, int tries,
continue;
}
vm_page_test_dirty(m);
- if (m->dirty == 0)
+ if (m->dirty == 0 && object->ref_count != 0)
pmap_remove_all(m);
if (m->dirty != 0) {
vm_page_unlock(m);
@@ -1059,31 +1059,16 @@ vm_pageout_scan(int pass)
}
/*
-* If the upper level VM system does not believe that the page
-* is fully dirty, but it is mapped for write access, then we
-* consult the pmap to see if the page's dirty status should
-* be updated.
+* If the page appears to be clean at the machine-independent
+* layer, then remove all of its mappings from the pmap in
+* anticipation of placing it onto the cache queue. If,
+* however, any of the page's mappings allow write access,
+* then the page may still be modified until the last of those
+* mappings are removed.
*/
- if (m->dirty != VM_PAGE_BITS_ALL &&
- pmap_page_is_write_mapped(m)) {
- /*
-* Avoid a race condition: Unless write access is
-* removed from the page, another processor could
-* modify it before all access is removed by the call
-* to vm_page_cache() below. If vm_page_cache() finds
-* that the page has been modified when it removes all
-* access, it panics because it cannot cache dirty
-* pages. In principle, we could eliminate just write
-* access here rather than all access. In the expected
-* case, when there are no last instant modifications
-* to the page, removing all access will be cheaper
-* overall.
-*/
- if (pmap_is_modified(m))
- vm_page_dirty(m);
- else if (m->dirty == 0)
- pmap_remove_all(m);
- }
+ vm_page_test_dirty(m);
+ if (m->dirty == 0 && object->ref_count != 0)
+ pmap_remove_all(m);
if (m->valid == 0) {
/*
___
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: r242435 - head/sys/dev/sound/pcm
Author: hselasky Date: Thu Nov 1 16:39:01 2012 New Revision: 242435 URL: http://svn.freebsd.org/changeset/base/242435 Log: Add missing inclusion guard. Modified: head/sys/dev/sound/pcm/mixer.h Modified: head/sys/dev/sound/pcm/mixer.h == --- head/sys/dev/sound/pcm/mixer.h Thu Nov 1 16:20:02 2012 (r242434) +++ head/sys/dev/sound/pcm/mixer.h Thu Nov 1 16:39:01 2012 (r242435) @@ -27,6 +27,9 @@ * $FreeBSD$ */ +#ifndef _PCM_MIXER_H_ +#define_PCM_MIXER_H_ + struct snd_mixer *mixer_create(device_t dev, kobj_class_t cls, void *devinfo, const char *desc); int mixer_delete(struct snd_mixer *m); @@ -75,3 +78,5 @@ extern int mixer_count; sizeof(oss_mixer_enuminfo)) #define MIXER_DECLARE(name) static DEFINE_CLASS(name, name ## _methods, MIXER_SIZE) + +#endif /* _PCM_MIXER_H_ */ ___ 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: r242438 - head/sys/dev/sound/usb
Author: hselasky
Date: Thu Nov 1 16:54:26 2012
New Revision: 242438
URL: http://svn.freebsd.org/changeset/base/242438
Log:
Export all mixer nodes into dev.pcm.X.mixer.Y sysctl nodes, hence the
PCM API doesn't support showing all the knobs. Make sure all the USB audio
mixer nodes are freed at detach. Before this patch USB audio would leak
some memory at detach. Print out buffer sizes in number of samples at attach.
Fix setting of volume controls when the number of channels is greater than
two.
MFC after:1 week
Modified:
head/sys/dev/sound/usb/uaudio.c
Modified: head/sys/dev/sound/usb/uaudio.c
==
--- head/sys/dev/sound/usb/uaudio.c Thu Nov 1 16:52:00 2012
(r242437)
+++ head/sys/dev/sound/usb/uaudio.c Thu Nov 1 16:54:26 2012
(r242438)
@@ -71,6 +71,7 @@ __FBSDID("$FreeBSD$");
#include
#include
#include
+#include
#defineUSB_DEBUG_VAR uaudio_debug
#include
@@ -138,14 +139,16 @@ union uaudio_sed {
};
struct uaudio_mixer_node {
+ const char *name;
+
int32_t minval;
int32_t maxval;
-#defineMIX_MAX_CHAN 8
+#defineMIX_MAX_CHAN 16
int32_t wValue[MIX_MAX_CHAN]; /* using nchan */
uint32_t mul;
uint32_t ctl;
- uint16_t wData[MIX_MAX_CHAN]; /* using nchan */
+ int wData[MIX_MAX_CHAN];/* using nchan */
uint16_t wIndex;
uint8_t update[(MIX_MAX_CHAN + 7) / 8];
@@ -165,6 +168,8 @@ struct uaudio_mixer_node {
uint8_t slctrtype[MAX_SELECTOR_INPUT_PIN];
uint8_t class;
+ uint8_t desc[64];
+
struct uaudio_mixer_node *next;
};
@@ -277,7 +282,9 @@ struct uaudio_softc {
struct uaudio_chan sc_play_chan;
struct umidi_chan sc_midi_chan;
struct uaudio_search_result sc_mixer_clocks;
+ struct sysctl_ctx_list sc_sysctl_ctx;
+ struct mtx *sc_mixer_lock;
struct usb_device *sc_udev;
struct usb_xfer *sc_mixer_xfer[1];
struct uaudio_mixer_node *sc_mixer_root;
@@ -399,6 +406,13 @@ static usb_callback_t uaudio_mixer_write
static usb_callback_t umidi_bulk_read_callback;
static usb_callback_t umidi_bulk_write_callback;
+/* USB mixer */
+
+static int uaudio_mixer_sysctl_handler(SYSCTL_HANDLER_ARGS);
+static void uaudio_mixer_ctl_free(struct uaudio_softc *);
+static void uaudio_mixer_register_sysctl(struct uaudio_softc *, device_t);
+static void uaudio_mixer_reload_all(struct uaudio_softc *);
+
/* USB audio v1.0 */
static voiduaudio_mixer_add_mixer(struct uaudio_softc *,
@@ -700,6 +714,8 @@ uaudio_attach(device_t dev)
if (usb_test_quirk(uaa, UQ_AU_VENDOR_CLASS))
sc->sc_uq_au_vendor_class = 1;
+ sysctl_ctx_init(&sc->sc_sysctl_ctx);
+
umidi_init(dev);
device_set_usb_desc(dev);
@@ -720,19 +736,27 @@ uaudio_attach(device_t dev)
sc->sc_mixer_count);
if (sc->sc_play_chan.valid) {
- device_printf(dev, "Play: %d Hz, %d ch, %s format.\n",
+ device_printf(dev, "Play: %d Hz, %d ch, %s format, "
+ "2x%d samples buffer.\n",
sc->sc_play_chan.sample_rate,
sc->sc_play_chan.channels,
- sc->sc_play_chan.p_fmt->description);
+ sc->sc_play_chan.p_fmt->description,
+ (sc->sc_play_chan.bytes_per_frame[0] *
+ sc->sc_play_chan.intr_frames) /
+ sc->sc_play_chan.sample_size);
} else {
device_printf(dev, "No playback.\n");
}
if (sc->sc_rec_chan.valid) {
- device_printf(dev, "Record: %d Hz, %d ch, %s format.\n",
+ device_printf(dev, "Record: %d Hz, %d ch, %s format, "
+ "2x%d samples buffer.\n",
sc->sc_rec_chan.sample_rate,
- sc->sc_play_chan.channels,
- sc->sc_rec_chan.p_fmt->description);
+ sc->sc_rec_chan.channels,
+ sc->sc_rec_chan.p_fmt->description,
+ (sc->sc_rec_chan.bytes_per_frame[0] *
+ sc->sc_rec_chan.intr_frames) /
+ sc->sc_rec_chan.sample_size);
} else {
device_printf(dev, "No recording.\n");
}
@@ -773,6 +797,10 @@ uaudio_attach(device_t dev)
DPRINTF("child attach failed\n");
goto detach;
}
+
+ /* reload all mixer settings */
+ uaudio_mixer_reload_all(sc);
+
return (0); /* success */
detach:
@@ -808,9 +836,8 @@ uaudio_attach_sub(device_t dev, kobj_cla
*/
uaudio_pcm_setflags(dev, SD_F_SOFTPCMVOL);
}
- if (mixer_init(dev, mixer_class, sc)) {
+ if (mixer_init(dev, mixer_class, sc))
goto detach;
- }
sc->sc_mixer_init = 1;
svn commit: r242439 - in head/sys: dev/null geom kern sys
Author: alfred
Date: Thu Nov 1 17:01:05 2012
New Revision: 242439
URL: http://svn.freebsd.org/changeset/base/242439
Log:
Provide a device name in the sysctl tree for programs to query the
state of crashdump target devices.
This will be used to add a "-l" (ell) flag to dumpon(8) to list the
currently configured dumpdev.
Reviewed by: phk
Modified:
head/sys/dev/null/null.c
head/sys/geom/geom_dev.c
head/sys/kern/kern_shutdown.c
head/sys/sys/conf.h
Modified: head/sys/dev/null/null.c
==
--- head/sys/dev/null/null.cThu Nov 1 16:54:26 2012(r242438)
+++ head/sys/dev/null/null.cThu Nov 1 17:01:05 2012(r242439)
@@ -91,7 +91,7 @@ null_ioctl(struct cdev *dev __unused, u_
case DIOCSKERNELDUMP:
error = priv_check(td, PRIV_SETDUMPER);
if (error == 0)
- error = set_dumper(NULL);
+ error = set_dumper(NULL, NULL);
break;
case FIONBIO:
break;
Modified: head/sys/geom/geom_dev.c
==
--- head/sys/geom/geom_dev.cThu Nov 1 16:54:26 2012(r242438)
+++ head/sys/geom/geom_dev.cThu Nov 1 17:01:05 2012(r242439)
@@ -359,7 +359,7 @@ g_dev_ioctl(struct cdev *dev, u_long cmd
case DIOCSKERNELDUMP:
u = *((u_int *)data);
if (!u) {
- set_dumper(NULL);
+ set_dumper(NULL, NULL);
error = 0;
break;
}
@@ -368,7 +368,7 @@ g_dev_ioctl(struct cdev *dev, u_long cmd
i = sizeof kd;
error = g_io_getattr("GEOM::kerneldump", cp, &i, &kd);
if (!error) {
- error = set_dumper(&kd.di);
+ error = set_dumper(&kd.di, devtoname(dev));
if (!error)
dev->si_flags |= SI_DUMPDEV;
}
@@ -526,7 +526,7 @@ g_dev_orphan(struct g_consumer *cp)
/* Reset any dump-area set on this device */
if (dev->si_flags & SI_DUMPDEV)
- set_dumper(NULL);
+ set_dumper(NULL, NULL);
/* Destroy the struct cdev *so we get no more requests */
destroy_dev(dev);
Modified: head/sys/kern/kern_shutdown.c
==
--- head/sys/kern/kern_shutdown.c Thu Nov 1 16:54:26 2012
(r242438)
+++ head/sys/kern/kern_shutdown.c Thu Nov 1 17:01:05 2012
(r242439)
@@ -712,18 +712,28 @@ kthread_shutdown(void *arg, int howto)
printf("done\n");
}
+static char dumpdevname[sizeof(((struct cdev*)NULL)->si_name)];
+SYSCTL_STRING(_kern_shutdown, OID_AUTO, dumpdevname, CTLFLAG_RD,
+dumpdevname, 0, "Device for kernel dumps");
+
/* Registration of dumpers */
int
-set_dumper(struct dumperinfo *di)
+set_dumper(struct dumperinfo *di, const char *devname)
{
if (di == NULL) {
bzero(&dumper, sizeof dumper);
+ dumpdevname[0] = '\0';
return (0);
}
if (dumper.dumper != NULL)
return (EBUSY);
dumper = *di;
+ strlcpy(dumpdevname, devname, sizeof(dumpdevname));
+ if (strlen(dumpdevname) != strlen(devname)) {
+ printf("set_dumper: device name truncated from '%s' -> '%s'\n",
+ devname, dumpdevname);
+ }
return (0);
}
Modified: head/sys/sys/conf.h
==
--- head/sys/sys/conf.h Thu Nov 1 16:54:26 2012(r242438)
+++ head/sys/sys/conf.h Thu Nov 1 17:01:05 2012(r242439)
@@ -331,7 +331,7 @@ struct dumperinfo {
off_t mediasize; /* Space available in bytes. */
};
-int set_dumper(struct dumperinfo *);
+int set_dumper(struct dumperinfo *, const char *_devname);
int dump_write(struct dumperinfo *, void *, vm_offset_t, off_t, size_t);
void dumpsys(struct dumperinfo *);
int doadump(boolean_t);
___
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: r242440 - head/share/man/man4
Author: alfred Date: Thu Nov 1 17:13:04 2012 New Revision: 242440 URL: http://svn.freebsd.org/changeset/base/242440 Log: Add whitespace between mandatory and optional kernel config options. Approved by: joel Modified: head/share/man/man4/textdump.4 Modified: head/share/man/man4/textdump.4 == --- head/share/man/man4/textdump.4 Thu Nov 1 17:01:05 2012 (r242439) +++ head/share/man/man4/textdump.4 Thu Nov 1 17:13:04 2012 (r242440) @@ -36,6 +36,7 @@ .Sh SYNOPSIS .Cd options KDB .Cd options DDB +.Pp .Cd options TEXTDUMP_VERBOSE .Cd options TEXTDUMP_PREFERRED .Sh DESCRIPTION ___ 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: r242441 - head/share/man/man4
Author: joel (doc committer) Date: Thu Nov 1 17:17:05 2012 New Revision: 242441 URL: http://svn.freebsd.org/changeset/base/242441 Log: Sort textdump options list. Submitted by: bde Modified: head/share/man/man4/ddb.4 Modified: head/share/man/man4/ddb.4 == --- head/share/man/man4/ddb.4 Thu Nov 1 17:13:04 2012(r242440) +++ head/share/man/man4/ddb.4 Thu Nov 1 17:17:05 2012(r242441) @@ -1173,10 +1173,15 @@ See the .Sx SCRIPTING section for more information on the scripting facility. .Pp +.It Ic textdump dump .It Ic textdump set .It Ic textdump status .It Ic textdump unset -.It Ic textdump dump +Use the +.Ic textdump dump +command to immediately perform a textdump. +More information may be found in +.Xr textdump 4 . The .Ic textdump set command may be used to force the next kernel core dump to be a textdump @@ -1185,11 +1190,6 @@ rather than a traditional memory dump or reports whether a textdump has been scheduled. .Ic textdump unset cancels a request to perform a textdump as the next kernel core dump. -Use the -.Ic textdump dump -command to immediately perform a textdump. -More information may be found in -.Xr textdump 4 . .El .Sh VARIABLES The debugger accesses registers and variables as ___ 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: r242417 - head/sys/dev/sound/pci/hda
On 01.11.2012 2:11, Alexander Motin wrote: > Author: mav > Date: Wed Oct 31 22:11:51 2012 > New Revision: 242417 > URL: http://svn.freebsd.org/changeset/base/242417 > > Log: > ASUS EeePC 1001px has strange variant of ALC269 CODEC, that mutes speaker > if unused in that configuration mixer at NID 15 is muted. Probably CODEC > incorrectly reports its internal connections. Hide that muter from the > driver to avoid muting and make built-in speaker work. Realteks mutes speakers in case headphones are plugged in. Perhaps it is related to this thing. ___ 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: r242451 - head/sbin/dumpon
Author: alfred
Date: Thu Nov 1 18:59:19 2012
New Revision: 242451
URL: http://svn.freebsd.org/changeset/base/242451
Log:
Add an option to display the current dump device via dumpon -l.
MFC after:2 weeks
Modified:
head/sbin/dumpon/dumpon.8
head/sbin/dumpon/dumpon.c
Directory Properties:
head/sbin/dumpon/ (props changed)
Modified: head/sbin/dumpon/dumpon.8
==
--- head/sbin/dumpon/dumpon.8 Thu Nov 1 18:55:17 2012(r242450)
+++ head/sbin/dumpon/dumpon.8 Thu Nov 1 18:59:19 2012(r242451)
@@ -41,6 +41,8 @@
.Nm
.Op Fl v
.Cm off
+.Nm
+.Fl l
.Sh DESCRIPTION
The
.Nm
@@ -72,6 +74,13 @@ total amount of physical memory as repor
variable.
.Pp
The
+.Fl l
+flag causes
+.Nm
+to print the current dump device or _PATH_DEVNULL ("/dev/null") if no device is
+configured.
+.Pp
+The
.Fl v
flag causes
.Nm
Modified: head/sbin/dumpon/dumpon.c
==
--- head/sbin/dumpon/dumpon.c Thu Nov 1 18:55:17 2012(r242450)
+++ head/sbin/dumpon/dumpon.c Thu Nov 1 18:59:19 2012(r242451)
@@ -46,6 +46,7 @@ __FBSDID("$FreeBSD$");
#include
#include
+#include
#include
#include
#include
@@ -60,9 +61,10 @@ static int verbose;
static void
usage(void)
{
- fprintf(stderr, "%s\n%s\n",
+ fprintf(stderr, "%s\n%s\n%s\n",
"usage: dumpon [-v] special_file",
- " dumpon [-v] off");
+ " dumpon [-v] off",
+ " dumpon -l");
exit(EX_USAGE);
}
@@ -92,15 +94,45 @@ check_size(int fd, const char *fn)
}
}
+static void
+listdumpdev(void)
+{
+ char dumpdev[PATH_MAX];
+ size_t len;
+ const char *sysctlname = "kern.shutdown.dumpdevname";
+
+ len = sizeof(dumpdev);
+ if (sysctlbyname(sysctlname, &dumpdev, &len, NULL, 0) != 0) {
+ if (errno == ENOMEM) {
+ err(EX_OSERR, "Kernel returned too large of a buffer
for '%s'\n",
+ sysctlname);
+ } else {
+ err(EX_OSERR, "Sysctl get '%s'\n", sysctlname);
+ }
+ }
+ if (verbose) {
+ printf("kernel dumps on ");
+ }
+ if (strlen(dumpdev) == 0) {
+ printf("%s\n", _PATH_DEVNULL);
+ } else {
+ printf("%s\n", dumpdev);
+ }
+}
+
int
main(int argc, char *argv[])
{
int ch;
int i, fd;
u_int u;
+ int do_listdumpdev = 0;
- while ((ch = getopt(argc, argv, "v")) != -1)
+ while ((ch = getopt(argc, argv, "lv")) != -1)
switch((char)ch) {
+ case 'l':
+ do_listdumpdev = 1;
+ break;
case 'v':
verbose = 1;
break;
@@ -111,6 +143,11 @@ main(int argc, char *argv[])
argc -= optind;
argv += optind;
+ if (do_listdumpdev) {
+ listdumpdev();
+ exit(EX_OK);
+ }
+
if (argc != 1)
usage();
___
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: r242452 - head/etc/root
Author: eadler Date: Thu Nov 1 19:38:03 2012 New Revision: 242452 URL: http://svn.freebsd.org/changeset/base/242452 Log: The test fails with "exit 1" if /usr/games/fortune doesn't actually exist. Fix that. PR: conf/71994 Submitted by: Mikael Eklund Reviewed by: crees Reviewed by: jilles Approved by: cperciva (implicit) MFC after:3 days Modified: head/etc/root/dot.login Modified: head/etc/root/dot.login == --- head/etc/root/dot.login Thu Nov 1 18:59:19 2012(r242451) +++ head/etc/root/dot.login Thu Nov 1 19:38:03 2012(r242452) @@ -6,4 +6,4 @@ # # Uncomment to display a random cookie each login: -# [ -x /usr/games/fortune ] && /usr/games/fortune -s +# if ( -x /usr/games/fortune ) /usr/games/fortune -s ___ 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: r242453 - head/sys/dev/sound/usb
Author: hselasky
Date: Thu Nov 1 20:09:48 2012
New Revision: 242453
URL: http://svn.freebsd.org/changeset/base/242453
Log:
Fix sysctl free bug in last commit, which eventually leads to a panic.
Add software mixer table for FastTrack Ultra.
Only set volume controls which are valid at startup for standard
USB audio devices, so that settings like treble and bass use
the reset defaults.
MFC after:1 week
Modified:
head/sys/dev/sound/usb/uaudio.c
Modified: head/sys/dev/sound/usb/uaudio.c
==
--- head/sys/dev/sound/usb/uaudio.c Thu Nov 1 19:38:03 2012
(r242452)
+++ head/sys/dev/sound/usb/uaudio.c Thu Nov 1 20:09:48 2012
(r242453)
@@ -167,6 +167,7 @@ struct uaudio_mixer_node {
#defineMAX_SELECTOR_INPUT_PIN 256
uint8_t slctrtype[MAX_SELECTOR_INPUT_PIN];
uint8_t class;
+ uint8_t val_default;
uint8_t desc[64];
@@ -282,7 +283,6 @@ struct uaudio_softc {
struct uaudio_chan sc_play_chan;
struct umidi_chan sc_midi_chan;
struct uaudio_search_result sc_mixer_clocks;
- struct sysctl_ctx_list sc_sysctl_ctx;
struct mtx *sc_mixer_lock;
struct usb_device *sc_udev;
@@ -412,6 +412,7 @@ static int uaudio_mixer_sysctl_handler(S
static void uaudio_mixer_ctl_free(struct uaudio_softc *);
static void uaudio_mixer_register_sysctl(struct uaudio_softc *, device_t);
static void uaudio_mixer_reload_all(struct uaudio_softc *);
+static void uaudio_mixer_controls_create_ftu(struct uaudio_softc *);
/* USB audio v1.0 */
@@ -714,8 +715,6 @@ uaudio_attach(device_t dev)
if (usb_test_quirk(uaa, UQ_AU_VENDOR_CLASS))
sc->sc_uq_au_vendor_class = 1;
- sysctl_ctx_init(&sc->sc_sysctl_ctx);
-
umidi_init(dev);
device_set_usb_desc(dev);
@@ -732,6 +731,15 @@ uaudio_attach(device_t dev)
sc->sc_audio_rev >> 8,
sc->sc_audio_rev & 0xff);
+ if (sc->sc_mixer_count == 0) {
+ if (uaa->info.idVendor == USB_VENDOR_MAUDIO &&
+ (uaa->info.idProduct == USB_PRODUCT_MAUDIO_FASTTRACKULTRA ||
+ uaa->info.idProduct ==
USB_PRODUCT_MAUDIO_FASTTRACKULTRA8R)) {
+ DPRINTF("Generating mixer descriptors\n");
+ uaudio_mixer_controls_create_ftu(sc);
+ }
+ }
+
DPRINTF("%d mixer controls\n",
sc->sc_mixer_count);
@@ -896,10 +904,6 @@ uaudio_detach(device_t dev)
{
struct uaudio_softc *sc = device_get_softc(dev);
- /* free all sysctls */
-
- sysctl_ctx_free(&sc->sc_sysctl_ctx);
-
/*
* Stop USB transfers early so that any audio applications
* will time out and close opened /dev/dspX.Y device(s), if
@@ -2147,7 +2151,7 @@ uaudio_mixer_register_sysctl(struct uaud
int chan;
int n;
- mixer_tree = SYSCTL_ADD_NODE(&sc->sc_sysctl_ctx,
+ mixer_tree = SYSCTL_ADD_NODE(device_get_sysctl_ctx(dev),
SYSCTL_CHILDREN(device_get_sysctl_tree(dev)), OID_AUTO, "mixer",
CTLFLAG_RD, NULL, "");
@@ -2167,30 +2171,30 @@ uaudio_mixer_register_sysctl(struct uaud
pmc->name, n);
}
- control_tree = SYSCTL_ADD_NODE(&sc->sc_sysctl_ctx,
+ control_tree =
SYSCTL_ADD_NODE(device_get_sysctl_ctx(dev),
SYSCTL_CHILDREN(mixer_tree), OID_AUTO, buf,
- CTLFLAG_RD, NULL, "");
+ CTLFLAG_RD, NULL, "Mixer control nodes");
if (control_tree == NULL)
continue;
- SYSCTL_ADD_PROC(&sc->sc_sysctl_ctx,
+ SYSCTL_ADD_PROC(device_get_sysctl_ctx(dev),
SYSCTL_CHILDREN(control_tree),
OID_AUTO, "val", CTLTYPE_INT | CTLFLAG_RW, sc,
pmc->wValue[chan],
uaudio_mixer_sysctl_handler, "I", "Current value");
- SYSCTL_ADD_INT(&sc->sc_sysctl_ctx,
+ SYSCTL_ADD_INT(device_get_sysctl_ctx(dev),
SYSCTL_CHILDREN(control_tree),
OID_AUTO, "min", CTLFLAG_RD, 0, pmc->minval,
"Minimum value");
- SYSCTL_ADD_INT(&sc->sc_sysctl_ctx,
+ SYSCTL_ADD_INT(device_get_sysctl_ctx(dev),
SYSCTL_CHILDREN(control_tree),
OID_AUTO, "max", CTLFLAG_RD, 0, pmc->maxval,
"Maximum value");
- SYSCTL_ADD_STRING(&sc->sc_sysctl_ctx,
+ SYSCTL_ADD_STRING(device_get_sysctl_ctx(dev),
SYSCTL_CHILDREN(control_tree),
Re: svn commit: r242402 - in head/sys: kern vm
On 11/1/12, Andre Oppermann wrote: > On 01.11.2012 12:53, Attilio Rao wrote: >> On 10/31/12, Andre Oppermann wrote: >>> On 31.10.2012 19:10, Attilio Rao wrote: On Wed, Oct 31, 2012 at 6:07 PM, Attilio Rao wrote: > Author: attilio > Date: Wed Oct 31 18:07:18 2012 > New Revision: 242402 > URL: http://svn.freebsd.org/changeset/base/242402 > > Log: > Rework the known mutexes to benefit about staying on their own > cache line in order to avoid manual frobbing but using > struct mtx_padalign. Interested developers can now dig and look for other mutexes to convert and just do it. Please, however, try to enclose a description about the benchmark which lead you believe the necessity to pad the mutex and possibly some numbers, in particular when the lock belongs to structures or the ABI itself. Next steps involve porting the same mtx(9) changes to rwlock(9) and port pvh global pmap lock to rwlock_padalign. >>> >>> I'd say for an rwlock you can make it unconditional. The very purpose >>> of it is to be aquired by multiple CPU's causing cache line dirtying >>> for every concurrent reader. Rwlocks are only ever used because >>> multiple >>> concurrent readers are expected. >> >> I thought about it, but I think the same arguments as for mutexes >> remains. >> The real problem is that having default rwlocks pad-aligned will put >> showstoppers for their usage in sensitive structures. For example, I >> have plans to use them in vm_object at some point to replace >> VM_OBJECT_LOCK and I do want to avoid the extra-bloat for such >> structures. >> >> Also, please keep in mind that there is no direct relation between >> "read acquisition" and "high contention" with the latter being the >> real reason for having pad-aligned locks. > > I do not agree. If there is no contention then there is no need for > a rwlock, a normal mutex would be sufficient. A rwlock is used when > multiple concurrent readers are expected. Each read lock and unlock > dirties the cache line for all other CPU's. > > Please note that I don't want to prevent you from doing the work all > over for rwlocks. It's just that the use case for a non-padded rwlock > is very narrow. So here is the patch for adding the decoupling infrastructure to rwlock and add the padalign type: http://www.freebsd.org/~attilio/rwlock_decoupled_padalign.patch I've tested by converting some rwlocks in the system and everything looks good to me. Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein ___ 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: r242454 - head/sys/mips/cavium
Author: jmallett
Date: Thu Nov 1 20:39:39 2012
New Revision: 242454
URL: http://svn.freebsd.org/changeset/base/242454
Log:
Don't disable PCIe just because the host is not a PCI host; the latter flag
only applies to non-PCIe systems. If PCIe is in target mode, it will simply
and gracefully fail to attach of its own accord.
Modified:
head/sys/mips/cavium/octopci.c
Modified: head/sys/mips/cavium/octopci.c
==
--- head/sys/mips/cavium/octopci.c Thu Nov 1 20:09:48 2012
(r242453)
+++ head/sys/mips/cavium/octopci.c Thu Nov 1 20:39:39 2012
(r242454)
@@ -104,10 +104,6 @@ static uint64_toctopci_cs_addr(unsigned
static void
octopci_identify(driver_t *drv, device_t parent)
{
- /* Check whether we are a PCI host. */
- if ((cvmx_sysinfo_get()->bootloader_config_flags &
CVMX_BOOTINFO_CFG_FLAG_PCI_HOST) == 0)
- return;
-
BUS_ADD_CHILD(parent, 0, "pcib", 0);
if (octeon_has_feature(OCTEON_FEATURE_PCIE))
BUS_ADD_CHILD(parent, 0, "pcib", 1);
@@ -121,6 +117,10 @@ octopci_probe(device_t dev)
return (0);
}
+ /* Check whether we are a PCI host. */
+ if ((cvmx_sysinfo_get()->bootloader_config_flags &
CVMX_BOOTINFO_CFG_FLAG_PCI_HOST) == 0)
+ return (ENXIO);
+
if (device_get_unit(dev) != 0)
return (ENXIO);
___
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: r242455 - head/sys/dev/sound/usb
Author: hselasky
Date: Thu Nov 1 20:43:23 2012
New Revision: 242455
URL: http://svn.freebsd.org/changeset/base/242455
Log:
Increase default volume for FastTracker playback channels.
MFC after:1 week
Modified:
head/sys/dev/sound/usb/uaudio.c
Modified: head/sys/dev/sound/usb/uaudio.c
==
--- head/sys/dev/sound/usb/uaudio.c Thu Nov 1 20:39:39 2012
(r242454)
+++ head/sys/dev/sound/usb/uaudio.c Thu Nov 1 20:43:23 2012
(r242455)
@@ -2250,7 +2250,7 @@ uaudio_mixer_controls_create_ftu(struct
mix.name = "mix_play";
mix.nchan = 1;
mix.update[0] = 1;
- mix.val_default = (chx == chy) ? 1 : 0;
+ mix.val_default = (chx == chy) ? 2 : 0;
snprintf(mix.desc, sizeof(mix.desc),
"DIn%d - Out%d Playback Volume", chy + 1, chx + 1);
@@ -2391,12 +2391,15 @@ uaudio_mixer_add_ctl_sub(struct uaudio_s
for (ch = 0; ch < p_mc_new->nchan; ch++) {
switch (p_mc_new->val_default) {
case 1:
+ /* 50% */
p_mc_new->wData[ch] = (p_mc_new->maxval +
p_mc_new->minval) / 2;
break;
case 2:
+ /* 100% */
p_mc_new->wData[ch] = p_mc_new->maxval;
break;
default:
+ /* 0% */
p_mc_new->wData[ch] = p_mc_new->minval;
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"
svn commit: r242458 - head/sys/dev/sound/usb
Author: hselasky
Date: Thu Nov 1 20:58:55 2012
New Revision: 242458
URL: http://svn.freebsd.org/changeset/base/242458
Log:
Correct buffer size printout.
MFC after:1 week
Modified:
head/sys/dev/sound/usb/uaudio.c
Modified: head/sys/dev/sound/usb/uaudio.c
==
--- head/sys/dev/sound/usb/uaudio.c Thu Nov 1 20:47:18 2012
(r242457)
+++ head/sys/dev/sound/usb/uaudio.c Thu Nov 1 20:58:55 2012
(r242458)
@@ -745,26 +745,20 @@ uaudio_attach(device_t dev)
if (sc->sc_play_chan.valid) {
device_printf(dev, "Play: %d Hz, %d ch, %s format, "
- "2x%d samples buffer.\n",
+ "2x8ms buffer.\n",
sc->sc_play_chan.sample_rate,
sc->sc_play_chan.channels,
- sc->sc_play_chan.p_fmt->description,
- (sc->sc_play_chan.bytes_per_frame[0] *
- sc->sc_play_chan.intr_frames) /
- sc->sc_play_chan.sample_size);
+ sc->sc_play_chan.p_fmt->description);
} else {
device_printf(dev, "No playback.\n");
}
if (sc->sc_rec_chan.valid) {
device_printf(dev, "Record: %d Hz, %d ch, %s format, "
- "2x%d samples buffer.\n",
+ "2x8ms buffer.\n",
sc->sc_rec_chan.sample_rate,
sc->sc_rec_chan.channels,
- sc->sc_rec_chan.p_fmt->description,
- (sc->sc_rec_chan.bytes_per_frame[0] *
- sc->sc_rec_chan.intr_frames) /
- sc->sc_rec_chan.sample_size);
+ sc->sc_rec_chan.p_fmt->description);
} else {
device_printf(dev, "No recording.\n");
}
___
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: r242459 - head/share/man/man9
Author: jimharris Date: Thu Nov 1 21:00:13 2012 New Revision: 242459 URL: http://svn.freebsd.org/changeset/base/242459 Log: Add descriptions for callout_reset_on and callout_schedule_on and their curcpu variants. Discussed with: mav, davide MFC after:1 week Modified: head/share/man/man9/timeout.9 Modified: head/share/man/man9/timeout.9 == --- head/share/man/man9/timeout.9 Thu Nov 1 20:58:55 2012 (r242458) +++ head/share/man/man9/timeout.9 Thu Nov 1 21:00:13 2012 (r242459) @@ -29,7 +29,7 @@ .\" .\" $FreeBSD$ .\" -.Dd August 2, 2008 +.Dd November 1, 2012 .Dt TIMEOUT 9 .Os .Sh NAME @@ -42,7 +42,11 @@ .Nm callout_stop , .Nm callout_drain , .Nm callout_reset , +.Nm callout_reset_on , +.Nm callout_reset_curcpu , .Nm callout_schedule , +.Nm callout_schedule_on , +.Nm callout_schedule_curcpu , .Nm callout_pending , .Nm callout_active , .Nm callout_deactivate @@ -75,8 +79,18 @@ struct callout_handle handle = CALLOUT_H .Ft int .Fn callout_reset "struct callout *c" "int ticks" "timeout_t *func" "void *arg" .Ft int +.Fn callout_reset_on "struct callout *c" "int ticks" "timeout_t *func" \ +"void *arg" "int cpu" +.Ft int +.Fn callout_reset_curcpu "struct callout *c" "int ticks" "timeout_t *func" \ +"void *arg" +.Ft int .Fn callout_schedule "struct callout *c" "int ticks" .Ft int +.Fn callout_schedule_on "struct callout *c" "int ticks" "int cpu" +.Ft int +.Fn callout_schedule_curcpu "struct callout *c" "int ticks" +.Ft int .Fn callout_pending "struct callout *c" .Ft int .Fn callout_active "struct callout *c" @@ -302,6 +316,26 @@ and parameters extracted from the callout structure (though possibly with lower overhead). .Pp +The functions +.Fn callout_reset_on +and +.Fn callout_schedule_on +are equivalent to +.Fn callout_reset +and +.Fn callout_schedule +but take an extra parameter specifying the target CPU for the callout. +.Pp +The functions +.Fn callout_reset_curcpu +and +.Fn callout_schedule_curcpu +are wrappers for +.Fn callout_reset_on +and +.Fn callout_schedule_on +using the current CPU as the target CPU. +.Pp The macros .Fn callout_pending , .Fn callout_active ___ 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: r242460 - head/lib/libc/stdio
Author: jilles Date: Thu Nov 1 22:47:42 2012 New Revision: 242460 URL: http://svn.freebsd.org/changeset/base/242460 Log: fopen(3): Mention that the "x" mode option is from C11. MFC after:1 week Modified: head/lib/libc/stdio/fopen.3 Modified: head/lib/libc/stdio/fopen.3 == --- head/lib/libc/stdio/fopen.3 Thu Nov 1 21:00:13 2012(r242459) +++ head/lib/libc/stdio/fopen.3 Thu Nov 1 22:47:42 2012(r242460) @@ -267,7 +267,11 @@ and .Fn freopen functions conform to -.St -isoC . +.St -isoC , +with the exception of the +.Dq Li x +mode option which conforms to +.St -isoC-2011 . The .Fn fdopen function ___ 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: r242462 - head/etc
Author: eadler Date: Fri Nov 2 00:17:30 2012 New Revision: 242462 URL: http://svn.freebsd.org/changeset/base/242462 Log: 10 years too late add support for "2.88MB 3.5in Extra High Density" floppies. Its unlikely that anyone actually uses these or cares about these anymore, since we support other floppy types and this change doesn't hurt - just add it. PR: conf/40777 Submitted by: Antti Kantee Arrival-Date: Fri Jul 19 08:50:02 PDT 2002 Approved by: cperciva (implicit) MFC after:1 week Modified: head/etc/disktab Modified: head/etc/disktab == --- head/etc/disktabThu Nov 1 22:51:44 2012(r242461) +++ head/etc/disktabFri Nov 2 00:17:30 2012(r242462) @@ -42,6 +42,12 @@ fd1440|floppy|floppy3|3in|3.5in High Den :pa#2880:oa#0:ba#4096:fa#512:\ :pc#2880:oc#0:bc#4096:fc#512: +fd2880|2.88MB 3.5in Extra High Density Floppy:\ + :ty=floppy:se#512:nt#2:rm#300:ns#36:nc#80:\ + :pa#5760:oa#0:ba#4096:fa#512:\ + :pb#5760:ob#0:bb#4096:fa#512:\ + :pc#5760:oc#0:bb#4096:fa#512: + # # Stressed floppy-formats. No guarantees given. # ___ 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: r242463 - in head: . sbin/ipfw sys/net sys/netinet sys/netinet6 sys/netpfil/ipfw
Author: ae
Date: Fri Nov 2 01:20:55 2012
New Revision: 242463
URL: http://svn.freebsd.org/changeset/base/242463
Log:
Remove the recently added sysctl variable net.pfil.forward.
Instead, add protocol specific mbuf flags M_IP_NEXTHOP and
M_IP6_NEXTHOP. Use them to indicate that the mbuf's chain
contains the PACKET_TAG_IPFORWARD tag. And do a tag lookup
only when this flag is set.
Suggested by: andre
Modified:
head/UPDATING
head/sbin/ipfw/ipfw.8
head/sys/net/pfil.c
head/sys/net/pfil.h
head/sys/netinet/ip_fastfwd.c
head/sys/netinet/ip_input.c
head/sys/netinet/ip_output.c
head/sys/netinet/ip_var.h
head/sys/netinet/tcp_input.c
head/sys/netinet/udp_usrreq.c
head/sys/netinet6/ip6_forward.c
head/sys/netinet6/ip6_input.c
head/sys/netinet6/ip6_output.c
head/sys/netinet6/ip6_var.h
head/sys/netinet6/udp6_usrreq.c
head/sys/netpfil/ipfw/ip_fw2.c
head/sys/netpfil/ipfw/ip_fw_pfil.c
Modified: head/UPDATING
==
--- head/UPDATING Fri Nov 2 00:17:30 2012(r242462)
+++ head/UPDATING Fri Nov 2 01:20:55 2012(r242463)
@@ -24,10 +24,9 @@ NOTE TO PEOPLE WHO THINK THAT FreeBSD 10
disable the most expensive debugging functionality run
"ln -s 'abort:false,junk:false' /etc/malloc.conf".)
-20121025:
+20121102:
The IPFIREWALL_FORWARD kernel option has been removed. Its
- functionality now can be turned on using the net.pfil.forward
- sysctl variable.
+ functionality now turned on by default.
20121023:
The ZERO_COPY_SOCKET kernel option has been removed and
Modified: head/sbin/ipfw/ipfw.8
==
--- head/sbin/ipfw/ipfw.8 Fri Nov 2 00:17:30 2012(r242462)
+++ head/sbin/ipfw/ipfw.8 Fri Nov 2 01:20:55 2012(r242463)
@@ -774,14 +774,6 @@ This makes the
.Xr netstat 1
entry look rather weird but is intended for
use with transparent proxy servers.
-.Pp
-To enable
-.Cm fwd
-the
-.Xr sysctl 8
-variable
-.Va net.pfil.forward
-should be set to 1.
.It Cm nat Ar nat_nr | tablearg
Pass packet to a
nat instance
Modified: head/sys/net/pfil.c
==
--- head/sys/net/pfil.c Fri Nov 2 00:17:30 2012(r242462)
+++ head/sys/net/pfil.c Fri Nov 2 01:20:55 2012(r242463)
@@ -37,7 +37,6 @@
#include
#include
#include
-#include
#include
#include
#include
@@ -65,11 +64,6 @@ VNET_DEFINE(struct pfilheadhead, pfil_he
VNET_DEFINE(struct rmlock, pfil_lock);
#defineV_pfil_lock VNET(pfil_lock)
-VNET_DEFINE(int, pfilforward) = 0;
-SYSCTL_NODE(_net, OID_AUTO, pfil, CTLFLAG_RW, 0, "Packer filter interface");
-SYSCTL_VNET_INT(_net_pfil, OID_AUTO, forward, CTLFLAG_RW,
-&VNET_NAME(pfilforward), 0,
-"Enable forwarding performed by packet filters");
/*
* pfil_run_hooks() runs the specified packet filter hooks.
*/
Modified: head/sys/net/pfil.h
==
--- head/sys/net/pfil.h Fri Nov 2 00:17:30 2012(r242462)
+++ head/sys/net/pfil.h Fri Nov 2 01:20:55 2012(r242463)
@@ -38,14 +38,11 @@
#include
#include
#include
-#include
struct mbuf;
struct ifnet;
struct inpcb;
-VNET_DECLARE(int, pfilforward);
-#defineV_pfilforward VNET(pfilforward)
/*
* The packet filter hooks are designed for anything to call them to
* possibly intercept the packet.
Modified: head/sys/netinet/ip_fastfwd.c
==
--- head/sys/netinet/ip_fastfwd.c Fri Nov 2 00:17:30 2012
(r242462)
+++ head/sys/netinet/ip_fastfwd.c Fri Nov 2 01:20:55 2012
(r242463)
@@ -446,7 +446,7 @@ passin:
/*
* Destination address changed?
*/
- if (V_pfilforward != 0)
+ if (m->m_flags & M_IP_NEXTHOP)
fwd_tag = m_tag_find(m, PACKET_TAG_IPFORWARD, NULL);
if (odest.s_addr != dest.s_addr || fwd_tag != NULL) {
/*
@@ -469,6 +469,7 @@ forwardlocal:
dest.s_addr = ((struct sockaddr_in *)
(fwd_tag + 1))->sin_addr.s_addr;
m_tag_delete(m, fwd_tag);
+ m->m_flags &= ~M_IP_NEXTHOP;
}
RTFREE(ro.ro_rt);
if ((dst = ip_findroute(&ro, dest, m)) == NULL)
Modified: head/sys/netinet/ip_input.c
==
--- head/sys/netinet/ip_input.c Fri Nov 2 00:17:30 2012(r242462)
+++ head/sys/netinet/ip_input.c Fri Nov 2 01:20:55 2012(r242463)
@@ -509,23 +509,22 @@ tooshort:
dchg = (odst.s_addr != ip->ip_dst.s_addr);
ifp = m->m_pkthdr.rcvif;
- if (V_pfilforward == 0)
-
Re: svn commit: r242402 - in head/sys: kern vm
On Nov 1, 2012, at 7:37 AM, Ian Lepore wrote: > > Back from some quick googling... yep, arm cortex-a8 processors have a > 64-byte cache line size. Maybe we don't support those yet, which is why > the value appears to be constant in arm param.h right now. Beaglebone runs a Cortex-A8. There's a lot of folks playing with those. Tim ___ 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: r242465 - head/sys/mips/mips
Author: adrian
Date: Fri Nov 2 05:22:32 2012
New Revision: 242465
URL: http://svn.freebsd.org/changeset/base/242465
Log:
Free the dma map -after- it's checked, not before. Or you'll be
potentially referencing already-freed memory.
Modified:
head/sys/mips/mips/busdma_machdep.c
Modified: head/sys/mips/mips/busdma_machdep.c
==
--- head/sys/mips/mips/busdma_machdep.c Fri Nov 2 01:32:22 2012
(r242464)
+++ head/sys/mips/mips/busdma_machdep.c Fri Nov 2 05:22:32 2012
(r242465)
@@ -549,7 +549,6 @@ int
bus_dmamap_destroy(bus_dma_tag_t dmat, bus_dmamap_t map)
{
- _busdma_free_dmamap(map);
if (STAILQ_FIRST(&map->bpages) != NULL) {
CTR3(KTR_BUSDMA, "%s: tag %p error %d",
__func__, dmat, EBUSY);
@@ -558,6 +557,7 @@ bus_dmamap_destroy(bus_dma_tag_t dmat, b
if (dmat->bounce_zone)
dmat->bounce_zone->map_count--;
dmat->map_count--;
+ _busdma_free_dmamap(map);
CTR2(KTR_BUSDMA, "%s: tag %p error 0", __func__, dmat);
return (0);
}
___
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: r242466 - head/sys/mips/mips
Author: adrian Date: Fri Nov 2 05:23:05 2012 New Revision: 242466 URL: http://svn.freebsd.org/changeset/base/242466 Log: Drop this from 500 to 128, to save a little space on memory constrained platforms. Modified: head/sys/mips/mips/busdma_machdep.c Modified: head/sys/mips/mips/busdma_machdep.c == --- head/sys/mips/mips/busdma_machdep.c Fri Nov 2 05:22:32 2012 (r242465) +++ head/sys/mips/mips/busdma_machdep.c Fri Nov 2 05:23:05 2012 (r242466) @@ -153,7 +153,7 @@ static STAILQ_HEAD(, bus_dmamap) bounce_ static TAILQ_HEAD(,bus_dmamap) dmamap_freelist = TAILQ_HEAD_INITIALIZER(dmamap_freelist); -#define BUSDMA_STATIC_MAPS 500 +#define BUSDMA_STATIC_MAPS 128 static struct bus_dmamap map_pool[BUSDMA_STATIC_MAPS]; static struct mtx busdma_mtx; ___ 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: r242467 - head/sys/dev/drm2
Author: glebius
Date: Fri Nov 2 05:26:33 2012
New Revision: 242467
URL: http://svn.freebsd.org/changeset/base/242467
Log:
- If DRM_DEBUG_DEFAULT_ON is defined, then initialize drm_debug_flagi to
all supported debugging bits.
- If DRM_DEBUG_DEFAULT_ON isn't defined, then initialize drm_debug_flag
to zero.
DRM_DEBUG_DEFAULT_ON is defined when module is build with -DDEBUG_DRM
or if kernel config has 'options DEBUG_DRM'.
Reviewed by: kib
Modified:
head/sys/dev/drm2/drm_drv.c
Modified: head/sys/dev/drm2/drm_drv.c
==
--- head/sys/dev/drm2/drm_drv.c Fri Nov 2 05:23:05 2012(r242466)
+++ head/sys/dev/drm2/drm_drv.c Fri Nov 2 05:26:33 2012(r242467)
@@ -44,9 +44,10 @@ __FBSDID("$FreeBSD$");
#include
#ifdef DRM_DEBUG_DEFAULT_ON
-int drm_debug_flag = 1;
+int drm_debug_flag = (DRM_DEBUGBITS_DEBUG | DRM_DEBUGBITS_KMS |
+DRM_DEBUGBITS_FAILED_IOCTL);
#else
-int drm_debug_flag = 2;
+int drm_debug_flag = 0;
#endif
int drm_notyet_flag = 0;
___
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"
