Re: svn commit: r368820 - head
On Sun, 20 Dec 2020 15:46:12 +0100 "Hartmann, O." wrote: > On Sun, 20 Dec 2020 02:59:44 + (UTC) > Li-Wen Hsu wrote: > > > Author: lwhsu > > Date: Sun Dec 20 02:59:44 2020 > > New Revision: 368820 > > URL: https://svnweb.freebsd.org/changeset/base/368820 > > > > Log: > > Mark the repository as being converted to Git. > > > > This is the last Subversion commit to src. > > > > Sponsored by: The FreeBSD Foundation > > > > Modified: > > head/README > > head/README.md > > > > Modified: head/README > > == > > --- head/README Sat Dec 19 22:04:46 2020(r368819) > > +++ head/README Sun Dec 20 02:59:44 2020(r368820) > > @@ -1,3 +1,5 @@ > > +This repository is being converted from Subversion to Git. > > + > > This is the top level of the FreeBSD source directory. This file > > was last revised on: > > $FreeBSD$ > > > > Modified: head/README.md > > == > > --- head/README.md Sat Dec 19 22:04:46 2020(r368819) > > +++ head/README.md Sun Dec 20 02:59:44 2020(r368820) > > @@ -1,3 +1,5 @@ > > +This repository is being converted from Subversion to Git. > > + > > FreeBSD Source: > > --- > > This is the top level of the FreeBSD source directory. This file > > ___ > > svn-src-head@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/svn-src-head > > To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org" > > Is this message of yours also the last message concerning the source changes? > Since then > you published this message, no further logs ran into list > svn-src-head@freebsd.org. > Take a look at this https://wiki.freebsd.org/git. Write access to Subversion has been disabled. -- Gary Jennejohn ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r362422 - head/sbin/dump
On Sat, 20 Jun 2020 07:57:29 -0600 Warner Losh wrote: > On Sat, Jun 20, 2020 at 7:27 AM Hans Petter Selasky wrote: > > > On 2020-06-20 13:10, Rodney W. Grimes wrote: > > >> Author: imp > > >> Date: Sat Jun 20 04:19:17 2020 > > >> New Revision: 362422 > > >> URL:https://svnweb.freebsd.org/changeset/base/362422 > > >> > > >> Log: > > >>Increase the whimsy in this file by famring dump's work out to > > minions. Adjust > > >>variables accordingly. Thankfully, we are able to do this without > > additional > > >>banana expenditures. > > > This flys in the face of its intent and as a "commit" is more > > > racially biased than the code was! > > > > > > > Hi Warner, > > > > Maybe a stupid question, but is this the correct meaning or description > > of minion? > > > > https://www.google.com/search?q=minions > > > > minion; plural noun: minions > > > > a follower or underling of a powerful person, especially a servile > > or unimportant one. > > "he gets oppressed minions like me to fob them off" > > > > "Minion" is still a person, like "slave" is, so I must say I agree with > > Rodney about this, I don't see how this makes it any better? Can you > > explain? > > > > For me, Minions come from the Despicable Me movies and sequels. They work > for Gru, who pays them for their services. They love Bananas and often do > crazy things for a banana. They work for Gru willingly. They are free to > leave at any time. They are sad at the prospect of Gru having to lay them > off. > > Minions are also, as you point out, employed by the powerful to accomplish > things. Key word here is 'employed'. Servile doesn't mean 'involuntary > servitude' but rather 'an excessive willingness to please.' Underling means > only that them are below them on the org chart. There's no inherent > implication of an abusive relationship, per se, though that happens as in > any power relationship between people. > > And the extensive searching I did before the commit showed no complaints > about the movies, or that this term had some coded, racist history. Or any > other coded history that's problematic. Or any overt history for that > matter. > > SaltStack uses it as their name for agents that carry out tasks, for > example. > > So what am I missing? > Why not simply use sub-processes? After all, that's exactly what the "minion processes" are. -- Gary Jennejohn ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r360125 - in head/usr.bin/diff: . tests
On Tue, 28 Apr 2020 07:25:18 -0500 Kyle Evans wrote: > On Tue, Apr 28, 2020 at 6:52 AM Jan Beich wrote: > > > > Kyle Evans writes: > > > > > Author: kevans > > > Date: Mon Apr 20 16:14:44 2020 > > > New Revision: 360125 > > > URL: https://svnweb.freebsd.org/changeset/base/360125 > > > > > > Log: > > > diff(1): reject conflicting formatting options > > > > > > This matches GNU diff(1) behavior and, more importantly, eliminates any > > > source of confusion if multiple formatting options are specified. > > > > > > Note that the committed diff differs slightly from the submitted: I've > > > modified it so that we initialize diff_format to something that isn't an > > > accepted format option so that we can also reject --normal -c and -c > > > --normal, which would've otherwise been accepted because the default was > > > --normal. After option parsing we default it to D_NORMAL if it's still > > > unset. > > > > > > PR: 243975 > > > Submitted by: fehmi noyan isi > > > MFC after: 1 week > > > > Appears to break ability to specify number of context lines e.g., > > > > $ diff -U999 /usr/include/sha256.h /usr/include/sha512.h > > error: conflicting output format options. > > usage: diff [-aBbdilpTtw] [-c | -e | -f | -n | -q | -u] [--ignore-case] > > [...] > > Hmm, bizarre. =-\ This example works on my machine, and I don't see > off-hand what would be preventing it for you: > > root@viper:/usr/src/usr.bin/diff# diff -U999 /usr/include/sha256.h > /usr/include/sha512.h > --- /usr/include/sha256.h 2020-04-22 21:38:54.0 -0500 > +++ /usr/include/sha512.h 2020-04-22 21:38:54.0 -0500 > @@ -1,99 +1,99 @@ > /*- > * Copyright 2005 Colin Percival > * All rights reserved. > * > [... omitted ...] > > root@viper:/usr/src/usr.bin/diff# strings /usr/bin/diff | grep 'conflicting' > error: conflicting output format options. > My /usr/bin/diff was built and installed on April 26, after this commit, and I don't see the error either. -- Gary Jennejohn ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r353700 - in head: share/man/man4 sys/amd64/conf sys/conf sys/gdb sys/i386/conf sys/kern sys/net sys/sys
On Fri, 18 Oct 2019 12:21:04 +0200
"Hartmann, O." wrote:
> On Thu, 17 Oct 2019 21:33:01 + (UTC)
> Conrad Meyer wrote:
>
> > Author: cem
> > Date: Thu Oct 17 21:33:01 2019
> > New Revision: 353700
> > URL: https://svnweb.freebsd.org/changeset/base/353700
> >
> > Log:
> > Implement NetGDB(4)
> >
> > NetGDB(4) is a component of a system using a panic-time network
> > stack to remotely debug crashed FreeBSD kernels over the network,
> > instead of traditional serial interfaces.
> >
> > There are three pieces in the complete NetGDB system.
> >
> > First, a dedicated proxy server must be running to accept
> > connections from both NetGDB and gdb(1), and pass bidirectional
> > traffic between the two protocols.
> >
> > Second, the NetGDB client is activated much like ordinary 'gdb' and
> > similarly to 'netdump' in ddb(4) after a panic. Like other
> > debugnet(4) clients (netdump(4)), the network interface on the route
> > to the proxy server must be online and support debugnet(4).
> >
> > Finally, the remote (k)gdb(1) uses 'target remote :'
> > (like any other TCP remote) to connect to the proxy server.
> >
> > The NetGDB v1 protocol speaks the literal GDB remote serial
> > protocol, and uses a 1:1 relationship between GDB packets and
> > sequences of debugnet packets (fragmented by MTU). There is no
> > encryption utilized to keep debugging sessions private, so this is
> > only appropriate for local segments or trusted networks.
> >
> > Submitted by: John Reimer (earlier
> > version) Discussed some with: emaste, markj
> > Relnotes: sure
> > Differential Revision:https://reviews.freebsd.org/D21568
> >
> > Added:
> > head/share/man/man4/netgdb.4 (contents, props changed)
> > head/sys/gdb/netgdb.c (contents, props changed)
> > head/sys/gdb/netgdb.h (contents, props changed)
> > Modified:
> > head/share/man/man4/Makefile
> > head/share/man/man4/ddb.4
> > head/sys/amd64/conf/GENERIC
> > head/sys/conf/NOTES
> > head/sys/conf/files
> > head/sys/conf/options
> > head/sys/gdb/gdb.h
> > head/sys/gdb/gdb_int.h
> > head/sys/gdb/gdb_main.c
> > head/sys/gdb/gdb_packet.c
> > head/sys/i386/conf/GENERIC
> > head/sys/kern/subr_kdb.c
> > head/sys/net/debugnet.c
> > head/sys/net/debugnet.h
> > head/sys/net/debugnet_inet.c
> > head/sys/net/debugnet_int.h
> > head/sys/sys/kdb.h
> > head/sys/sys/param.h
> >
> > Modified: head/share/man/man4/Makefile
> > ==
> > --- head/share/man/man4/MakefileThu Oct 17 21:25:50
> > 2019(r353699) +++ head/share/man/man4/Makefile Thu Oct
> > 17 21:33:01 2019(r353700) @@ -307,6 +307,7 @@ MAN=
> > aac.4 \ net80211.4 \
> > netdump.4 \
> > netfpga10g_nf10bmac.4 \
> > + netgdb.4 \
> > netgraph.4 \
> > netintro.4 \
> > netmap.4 \
> >
> [...]
>
>
> Having "nooptions NETGDB # netgdb(4) client support"
> defined in my kernel config file, buildkernel fails with the error
> shown below.
>
> [...]
> --- debugnet.o ---
> /usr/src/sys/net/debugnet.c:662:4: error: implicit declaration of
> function 'db_printf' is invalid in C99
> [-Werror,-Wimplicit-function-declaration] db_printf("%s: Could not get
> route for that server.\n", ^ /usr/src/sys/net/debugnet.c:662:4: note:
> did you mean 'if_printf'? /usr/src/sys/net/if_var.h:679:5: note:
> 'if_printf' declared here int if_printf(struct ifnet *, const char
> *, ...) __printflike(2, 3); ^
> 1 error generated.
And I also had to add "nooptions NETDUMP" to get the kernel to compile
and link.
--
Gary Jennejohn
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r349976 - head
On Thu, 25 Jul 2019 09:32:15 -0600 Ian Lepore wrote: > On Thu, 2019-07-25 at 10:27 -0300, Renato Botelho wrote: > > On 13/07/19 13:48, Ian Lepore wrote: > > > Author: ian > > > Date: Sat Jul 13 16:48:27 2019 > > > New Revision: 349976 > > > URL: https://svnweb.freebsd.org/changeset/base/349976 > > > > > > Log: > > > Add an entry mentioning the permission/mode change to daily > > > accounting files. > > > > > > Modified: > > > head/UPDATING > > > > > > Modified: head/UPDATING > > > === > > > === > > > --- head/UPDATING Sat Jul 13 16:32:19 2019(r349975) > > > +++ head/UPDATING Sat Jul 13 16:48:27 2019(r349976) > > > @@ -31,6 +31,14 @@ NOTE TO PEOPLE WHO THINK THAT FreeBSD 13.x IS > > > SLOW: > > > disable the most expensive debugging functionality run > > > "ln -s 'abort:false,junk:false' /etc/malloc.conf".) > > > > > > +20190713: > > > +Default permissions on the /var/account/acct file (and copies > > > of it rotated > > > +by periodic daily scripts) are changed from 0644 to 0640 > > > because the file > > > +contains sensitive information that should not be world- > > > readable. If the > > > +/var/account directory must be created by rc.d/accounting, the > > > mode used is > > > +now 0750. Admins who use the accounting feature are > > > encouraged to change > > > +the mode of an existing /var/account directory to 0750 or > > > 0700. > > > > Block is indented with 4 spaces instead of tabs > > > > Doh! Must've still had my editor set for the $work coding standards. > Fixed in r350324. Thanks! > I just looked at UPDATING (/usr/src is at r350348) and this is the only entry which wraps on a 80 character wide terminal. -- Gary Jennejohn ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r349969 - in head: sys/net usr.sbin/bhyve
C1, 0xF781, 0x3740, 0xF501, 0x35C0, 0x3480, 0xF441,
> + 0x3C00, 0xFCC1, 0xFD81, 0x3D40, 0xFF01, 0x3FC0, 0x3E80, 0xFE41,
> + 0xFA01, 0x3AC0, 0x3B80, 0xFB41, 0x3900, 0xF9C1, 0xF881, 0x3840,
> + 0x2800, 0xE8C1, 0xE981, 0x2940, 0xEB01, 0x2BC0, 0x2A80, 0xEA41,
> + 0xEE01, 0x2EC0, 0x2F80, 0xEF41, 0x2D00, 0xEDC1, 0xEC81, 0x2C40,
> + 0xE401, 0x24C0, 0x2580, 0xE541, 0x2700, 0xE7C1, 0xE681, 0x2640,
> + 0x2200, 0xE2C1, 0xE381, 0x2340, 0xE101, 0x21C0, 0x2080, 0xE041,
> + 0xA001, 0x60C0, 0x6180, 0xA141, 0x6300, 0xA3C1, 0xA281, 0x6240,
> + 0x6600, 0xA6C1, 0xA781, 0x6740, 0xA501, 0x65C0, 0x6480, 0xA441,
> + 0x6C00, 0xACC1, 0xAD81, 0x6D40, 0xAF01, 0x6FC0, 0x6E80, 0xAE41,
> + 0xAA01, 0x6AC0, 0x6B80, 0xAB41, 0x6900, 0xA9C1, 0xA881, 0x6840,
> + 0x7800, 0xB8C1, 0xB981, 0x7940, 0xBB01, 0x7BC0, 0x7A80, 0xBA41,
> + 0xBE01, 0x7EC0, 0x7F80, 0xBF41, 0x7D00, 0xBDC1, 0xBC81, 0x7C40,
> + 0xB401, 0x74C0, 0x7580, 0xB541, 0x7700, 0xB7C1, 0xB681, 0x7640,
> + 0x7200, 0xB2C1, 0xB381, 0x7340, 0xB101, 0x71C0, 0x7080, 0xB041,
> + 0x5000, 0x90C1, 0x9181, 0x5140, 0x9301, 0x53C0, 0x5280, 0x9241,
> + 0x9601, 0x56C0, 0x5780, 0x9741, 0x5500, 0x95C1, 0x9481, 0x5440,
> + 0x9C01, 0x5CC0, 0x5D80, 0x9D41, 0x5F00, 0x9FC1, 0x9E81, 0x5E40,
> + 0x5A00, 0x9AC1, 0x9B81, 0x5B40, 0x9901, 0x59C0, 0x5880, 0x9841,
> + 0x8801, 0x48C0, 0x4980, 0x8941, 0x4B00, 0x8BC1, 0x8A81, 0x4A40,
> + 0x4E00, 0x8EC1, 0x8F81, 0x4F40, 0x8D01, 0x4DC0, 0x4C80, 0x8C41,
> + 0x4400, 0x84C1, 0x8581, 0x4540, 0x8701, 0x47C0, 0x4680, 0x8641,
> + 0x8201, 0x42C0, 0x4380, 0x8341, 0x4100, 0x81C1, 0x8081, 0x4040
> + };
>
> - nd = >nsdata;
> + while (len--)
> + crc = (((crc >> 8) & 0xffU) ^
> + crc16_table[(crc ^ *cp++) & 0xffU]) & 0xU;
> + return crc;
> +}
>
> +static void
> +pci_nvme_init_nsdata(struct pci_nvme_softc *sc,
> +struct nvme_namespace_data *nd, uint32_t nsid,
> +uint64_t eui64)
> +{
> +
> nd->nsze = sc->nvstore.size / sc->nvstore.sectsz;
> nd->ncap = nd->nsze;
> nd->nuse = nd->nsze;
>
> /* Get LBA and backstore information from backing store */
> nd->nlbaf = 0; /* NLBAF is a 0's based value (i.e. 1 LBA Format) */
> + nd->flbas = 0;
> +
> + /* Create an EUI-64 if user did not provide one */
> + if (eui64 == 0) {
> + char *data = NULL;
> +
> + asprintf(, "%s%u%u%u", vmname, sc->nsc_pi->pi_bus,
> + sc->nsc_pi->pi_slot, sc->nsc_pi->pi_func);
> +
> + if (data != NULL) {
> + eui64 = OUI_FREEBSD_NVME_LOW | crc16(0, data,
> strlen(data));
> + free(data);
> + }
> + eui64 = (eui64 << 16) | (nsid & 0x);
> + }
> + be64enc(nd->eui64, eui64);
> +
> /* LBA data-sz = 2^lbads */
> nd->lbaf[0] = sc->nvstore.sectsz_bits << NVME_NS_DATA_LBAF_LBADS_SHIFT;
> -
> - nd->flbas = 0;
> }
>
> static void
> @@ -1817,6 +1887,8 @@ pci_nvme_parse_opts(struct pci_nvme_softc *sc, char *o
> free(uopt);
> return (-1);
> }
> + } else if (!strcmp("eui64", xopts)) {
> + sc->nvstore.eui64 = htobe64(strtoull(config, NULL, 0));
> } else if (optidx == 0) {
> snprintf(bident, sizeof(bident), "%d:%d",
>sc->nsc_pi->pi_slot, sc->nsc_pi->pi_func);
> @@ -1937,7 +2009,7 @@ pci_nvme_init(struct vmctx *ctx, struct pci_devinst *p
>
> pci_nvme_reset(sc);
> pci_nvme_init_ctrldata(sc);
> - pci_nvme_init_nsdata(sc);
> + pci_nvme_init_nsdata(sc, >nsdata, 1, sc->nvstore.eui64);
> pci_nvme_init_logpages(sc);
>
> pci_lintr_request(pi);
> ___
> svn-src-...@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/svn-src-all
> To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
--
Gary Jennejohn
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r341578 - head/sys/dev/mlx5/mlx5_en
On Mon, 17 Dec 2018 14:50:04 -0500 Andrew Gallatin wrote: > On 12/17/18 2:08 PM, Bruce Evans wrote: [snip] > > iflib uses queuing techniques to significantly pessimize em NICs with 1 > > hardware queue. On fast machines, it attempts to do 1 context switch per > > This can happen even w/o contention when "abdicate" is enabled in mp > ring. I complained about this as well, and the default was changed in > mp ring to not always "abdicate" (eg, switch to the tq to handle the > packet). Abdication substantially pessimizes Netflix style web > uncontended workloads, but it generally helps small packet forwarding. > > It is interesting that you see the opposite. I should try benchmarking > with just a single ring. > Why are iflib and ifdi compiled into EVERY kernel with device ether and/or device pci when only a few NICs actually use iflib? This is really unnecessary bloat in an already bloated kernel. I use if_re which does not use iflib. I removed iflib and ifdi from /sys/conf/files and my network still works just fine. It seems to me like these iflib entries need finer-grained options, e.g. one of the NICs which use iflib is enabled, before pulling them into the kernel build. -- Gary Jennejohn ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r340038 - in head: lib/libc/sys sys/kern
On Thu, 1 Nov 2018 20:29:27 -0700 Conrad Meyer wrote: > On Thu, Nov 1, 2018 at 5:46 PM Konstantin Belousov > wrote: > > > > On Thu, Nov 01, 2018 at 11:46:23PM +, Conrad Meyer wrote: > > > ... > > > @@ -232,7 +232,15 @@ points outside the process's allocated address space. > > > A signal was delivered before the time limit expired and > > > before any of the selected events occurred. > > > .It Bq Er EINVAL > > > -The specified time limit is invalid. One of its components is negative > > > or too large. > > > +The specified time limit is invalid. > > > +One of its components is negative or too large. > > > +.It Bq Er EINVAL > > > +The number of pollfd structures specified by > > > +.Fa nfds > > > +exceeds the system tunable > > > +.Va kern.maxfilesperproc > > > +and > > > +.Dv FD_SETSIZE . > > > > This is somewhat confusing. Looking only at the man page text, most > > straight reading of it is that nfds cannot exceed min(maxfilesperproc, > > FD_SETSIZE). But in fact nfds cannot exceed max of it, which is > > significantly different, i.e. poll(2) does not suffer from the (userspace) > > FD_SETSIZE limitation of select(2). > > min(maxfilesperproc, FD_SETSIZE) would be written as "nfds exceeds ... > maxfilesperproc OR FD_SETSIZE," rather than "and." I think the > sentence is unambiguous. > Based on Konstantin's comment I'd have to say that it is not unambiguous. As a native English speaker I had to read it several times to understand it. I think something like "exceeds both" might be clearer. -- Gary Jennejohn ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r338239 - head
On Thu, 23 Aug 2018 05:06:32 + (UTC) Warner Losh wrote: > Author: imp > Date: Thu Aug 23 05:06:31 2018 > New Revision: 338239 > URL: https://svnweb.freebsd.org/changeset/base/338239 > > Log: > Add a special note to UPDATING for the devmatch stuff. While tested, > there's an elevated risk of trouble, and you must update kernel, > userland and rc scripts for the best experience. > > Modified: > head/UPDATING > > Modified: head/UPDATING > == > --- head/UPDATING Thu Aug 23 05:06:27 2018(r338238) > +++ head/UPDATING Thu Aug 23 05:06:31 2018(r338239) > @@ -31,6 +31,11 @@ NOTE TO PEOPLE WHO THINK THAT FreeBSD 12.x IS SLOW: > disable the most expensive debugging functionality run > "ln -s 'abort:false,junk:false' /etc/malloc.conf".) > > +20170822: > + devctl freeze/that have gone into the tree, the rc scripts have been ===> typo, should be thaw > + updated to use them and devmatch has been changed. You should update > + kernel, userland and rc scripts all at the same time. > + > 20180821: > drm and drm2 have been removed. Users on powerpc, 32-bit hardware, > or with GPUs predating Radeon and i915 will need to install the > -- Gary Jennejohn ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r338172 - in head: . sys/amd64/conf sys/dev/drm sys/dev/drm2 sys/dev/drm2/i915 sys/dev/drm2/radeon sys/dev/drm2/radeon/reg_srcs sys/dev/drm2/ttm sys/i386/conf sys/modules sys/modules/d
On Wed, 22 Aug 2018 00:35:23 -0700 Matthew Macy wrote: > Johannes - do you know off hand? > -M > > On Wed, Aug 22, 2018 at 12:06 AM Andriy Gapon wrote: > > > On 22/08/2018 04:50, Matt Macy wrote: > > > Author: mmacy > > > Date: Wed Aug 22 01:50:12 2018 > > > New Revision: 338172 > > > URL: https://svnweb.freebsd.org/changeset/base/338172 > > > > > > Log: > > > Remove legacy drm and drm2 from tree > > > > > > As discussed on the MLs drm2 conflicts with the ports' version and > > there > > > is no upstream for most if not all of drm. Both have been merged in to > > > a single port. > > ... > > > Approved by: core@ > > > > I am curious if this "panic: implment me" has been addressed? > > https://lists.freebsd.org/pipermail/freebsd-current/2018-May/069428.html > > Are all the empty directories under /usr/src/sys/modules/drm2 still supposed to be in the tree? And what about /usr/src/sys/arm/nvidia/drm2? -- Gary Jennejohn ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r334650 - head/sys/dev/usb
On Tue, 5 Jun 2018 16:30:05 -0700 Eitan Adler wrote: > On 5 June 2018 at 07:01, Kevin Lo wrote: > > On Tue, Jun 05, 2018 at 09:52:38AM +, Eitan Adler wrote: > >> Author: eadler > >> Date: Tue Jun 5 09:52:38 2018 > >> New Revision: 334650 > >> URL: https://svnweb.freebsd.org/changeset/base/334650 > >> > >> Log: > >> usbdevs: sync from NetBSD > >> > >> This adds several vendors from NetBSD's copy of the same file (r1.749). > >> Prefer longer more "canonical" names where the names differed. > >> > >> Sort while here. > >> > >> Modified: > >> head/sys/dev/usb/usbdevs > >> > >> Modified: head/sys/dev/usb/usbdevs > >> == > >> --- head/sys/dev/usb/usbdevs Tue Jun 5 05:24:42 2018(r334649) > >> +++ head/sys/dev/usb/usbdevs Tue Jun 5 09:52:38 2018(r334650) > >> @@ -60,7 +60,7 @@ vendor UNKNOWN2 0x0105 Unknown vendor > >> vendor EGALAX2 0x0123 eGalax, Inc. > >> vendor CHIPSBANK 0x0204 Chipsbank Microelectronics Co. > >> vendor HUMAX 0x02ad HUMAX > >> -vendor INTENSO 0x2109 INTENSO > >> +vendor QUAN 0x01e1 Quan > > > > Doesn't sort. > > > > [snip] > > > >> +vendor INTENSO 0x2109 INTENSO > >> vendor VIALABS 0x2109 VIA Labs > > > > INTENSO has the same vendor id as VIALABS? This doesn't look right. > > From the origin (NetBSD): > > vendor INTENSO 0x2109 INTENSO > vendor VIALABS 0x2109 VIA Labs > > I noticed this earlier and thought it might relate to vendor renames > or the like. I'll try and spend more time on it. I have quite a few > replies-to-commits to catch up on: I've spent too much time on "new" > things and have to deal with the other stuff I've touched now. > Looking at the usb.if from usb.org indicates that Intenso doesn't even have a USB VID. 0x2109 is listed as VIA Labs. This entry may be the result of Intenso selling a rebadged VIA Labs product. -- Gary Jennejohn ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r329154 - in head/etc: defaults devd
On Mon, 12 Feb 2018 07:01:56 + Alexey Dokuchaev <da...@freebsd.org> wrote: > On Sun, Feb 11, 2018 at 10:55:48PM -0800, Cy Schubert wrote: > > In message <201802120651.w1c6pkqf042...@repo.freebsd.org>, Warner Losh > > writes: > > > New Revision: 329154 > > > URL: https://svnweb.freebsd.org/changeset/base/329154 > > > > > > Log: > > > Turn devmatch on by default. > > > > > > Turn devmatch on by default. However, use 'start' instead of > > > 'onestart' in the devmatch.conf file so the setting of > > > 'devmatch_enable' is honored. Give an example of what to put in > > > devd.conf if you want to disable just the run-time part of devmatch. > > > > > > ... > > > @@ -41,7 +41,7 @@ ddb_enable="NO" # Set to YES to load ddb script > > > s at b > > > ddb_config="/etc/ddb.conf" # ddb(8) config file. > > > devd_enable="YES"# Run devd, to trigger programs on device tree > > > changes. > > > devd_flags=""# Additional flags for devd(8). > > > -devmatch_enable="NO" # Demand load kernel modules based on device > > > ids. > > > +devmatch_enable="YES"# Demand load kernel modules based on device id > > > s. > > > > This assumes that everyone has /usr in /. We might want to consider > > moving devmatch to /sbin, or document that > > I was actually surprised to find out it's installed as /usr/sbin/devmatch; > /sbin indeed looks more appropriate. > > > /usr and / be merged. > > Please don't. > +1 -- Gary Jennejohn ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r327890 - head/usr.sbin/bsdinstall/partedit
On Thu, 18 Jan 2018 07:26:11 + Alexey Dokuchaev <da...@freebsd.org> wrote: > On Sat, Jan 13, 2018 at 06:53:47AM +, Alexey Dokuchaev wrote: > > On Fri, Jan 12, 2018 at 08:25:57PM +, Ed Maste wrote: > > > New Revision: 327890 > > > URL: https://svnweb.freebsd.org/changeset/base/327890 > > > > > > Log: > > > bsdinstall: disable SUJ by default > > > > > > SUJ + cg checksums produce spurious warnings after an unclean shutdown > > > (e.g. a crash). For now disable SUJ for UFS installs so installing from > > > a FreeBSD 12 snapshot results in a usable filesystem, until this can be > > > fixed. > > > > Thanks; I keep seeing it quite often. Is it safe to disable SUJ on already > > populated filesystem? Can (should) it better be done on live, mounted one, > > of better off the other booted instance of FreeBSD (from another media)? > > Ping. > The answer to your question is in tunefs(8). Snippet: The tunefs utility is designed to change the dynamic parameters of a UFS file system which affect the layout policies. The tunefs utility cannot be run on an active file system. To change an active file system, it must be downgraded to read-only or unmounted. -- Gary Jennejohn ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r325942 - head
On Fri, 17 Nov 2017 15:46:19 + (UTC) Gordon Tetlow <gor...@freebsd.org> wrote: > Author: gordon > Date: Fri Nov 17 15:46:19 2017 > New Revision: 325942 > URL: https://svnweb.freebsd.org/changeset/base/325942 > > Log: > Correct grammar nit. > > Modified: > head/UPDATING > > Modified: head/UPDATING > == > --- head/UPDATING Fri Nov 17 15:45:35 2017(r325941) > +++ head/UPDATING Fri Nov 17 15:46:19 2017(r325942) > @@ -66,7 +66,7 @@ NOTE TO PEOPLE WHO THINK THAT FreeBSD 12.x IS SLOW: > 20171102: > Building in a FreeBSD src checkout will automatically create object > directories now rather than store files in the current directory if > - 'make obj' was not ran. Calling 'make obj' is no longer necesarry. > + 'make obj' was not ran. Calling 'make obj' is no longer necessary. > This feature can be disabled by setting WITHOUT_AUTO_OBJ=yes in > /etc/src-env.conf (not /etc/src.conf), or passing the option in the > environment. > "not ran" is bad english. "not run" is correct. -- Gary Jennejohn ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r324179 - head/sys/netinet
On Sun, 1 Oct 2017 21:20:28 + (UTC)
Julien Charbon <j...@freebsd.org> wrote:
> Author: jch
> Date: Sun Oct 1 21:20:28 2017
> New Revision: 324179
> URL: https://svnweb.freebsd.org/changeset/base/324179
>
> Log:
> Fix an infinite loop in tcp_tw_2msl_scan() when an INP_TIMEWAIT inp has
> been destroyed before its tcptw with INVARIANTS undefined.
>
> This is a symmetric change of r307551:
>
> A INP_TIMEWAIT inp should not be destroyed before its tcptw, and INVARIANTS
> will catch this case. If INVARIANTS is undefined it will emit a
> log(LOG_ERR)
> and avoid a hard to debug infinite loop in tcp_tw_2msl_scan().
>
> Reported by:Ben Rubson, hselasky
> Submitted by: hselasky
> Tested by: Ben Rubson, jch
> MFC after: 1 week
> Sponsored by: Verisign, inc
> Differential Revision: https://reviews.freebsd.org/D12267
>
> Modified:
> head/sys/netinet/tcp_timewait.c
>
> Modified: head/sys/netinet/tcp_timewait.c
> ==
> --- head/sys/netinet/tcp_timewait.c Sun Oct 1 20:12:30 2017
> (r324178)
> +++ head/sys/netinet/tcp_timewait.c Sun Oct 1 21:20:28 2017
> (r324179)
> @@ -709,10 +709,29 @@ tcp_tw_2msl_scan(int reuse)
> INP_WLOCK(inp);
> tw = intotw(inp);
> if (in_pcbrele_wlocked(inp)) {
> - KASSERT(tw == NULL, ("%s: held last inp "
> - "reference but tw not NULL", __func__));
> - INP_INFO_RUNLOCK(_tcbinfo);
> - continue;
> + if (__predict_true(tw == NULL)) {
> + INP_INFO_RUNLOCK(_tcbinfo);
> + continue;
> + } else {
> + /* This should not happen as in TIMEWAIT
> + * state the inp should not be destroyed
> + * before its tcptw. If INVARIANTS is
> + * defined panic.
> + */
> +#ifdef INVARIANTS
> + panic("%s: Panic before an infinite "
> + "loop: INP_TIMEWAIT && (INP_FREED "
> + "|| inp last reference) && tw != "
> + "NULL", __func__);
> +#else
> + log(LOG_ERR, "%s: Avoid an infinite "
> + "loop: INP_TIMEWAIT && (INP_FREED "
> + "|| inp last reference) && tw != "
> + "NULL", __func__);
> +#endif
> + INP_INFO_RUNLOCK(_tcbinfo);
> + break;
> + }
> }
>
> if (tw == NULL) {
>
This file needs to include sys/syslog.h, otherwise LOG_ERR is
not defined and the kernel build fails when INVARIANTS is not
defined in the kernel config file.
--
Gary Jennejohn
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r323945 - head/sys/contrib/ipfilter/netinet
On Sat, 23 Sep 2017 06:00:17 + (UTC)
Cy Schubert <c...@freebsd.org> wrote:
> Author: cy
> Date: Sat Sep 23 06:00:17 2017
> New Revision: 323945
> URL: https://svnweb.freebsd.org/changeset/base/323945
>
> Log:
> Correct two misspellings. Also align */.
>
> Modified:
> head/sys/contrib/ipfilter/netinet/ip_nat.c
>
> Modified: head/sys/contrib/ipfilter/netinet/ip_nat.c
> ==
> --- head/sys/contrib/ipfilter/netinet/ip_nat.cSat Sep 23 01:39:16
> 2017(r323944)
> +++ head/sys/contrib/ipfilter/netinet/ip_nat.cSat Sep 23 06:00:17
> 2017(r323945)
> @@ -6093,8 +6093,8 @@ ipf_nat_icmpquerytype(icmptype)
> {
> case ICMP_ECHOREPLY:
> case ICMP_ECHO:
> - /* route aedvertisement/solliciation is currently unsupported: */
> - /* it would require rewriting the ICMP data section*/
> + /* route advertisement/soliciation is currently unsupported: */
^ still wrong - should be
solicitation.
> + /* it would require rewriting the ICMP data section */
> case ICMP_TSTAMP:
> case ICMP_TSTAMPREPLY:
> case ICMP_IREQ:
>
--
Gary Jennejohn
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r308565 - head/sys/kern
On Sat, 12 Nov 2016 08:40:28 -0800 John Baldwin <j...@freebsd.org> wrote: > On 11/12/16 1:28 AM, Gary Jennejohn wrote: > > On Sat, 12 Nov 2016 00:23:09 + (UTC) > > John Baldwin <j...@freebsd.org> wrote: > > > >> Author: jhb > >> Date: Sat Nov 12 00:23:09 2016 > >> New Revision: 308565 > >> URL: https://svnweb.freebsd.org/changeset/base/308565 > >> > >> Log: > >> Allow scheduling during early boot. > >> > >> - Send IPI wakeups once SMP is started even if cold is true. > >> - Permit preemptions when cold is true. > >> > >> These changes are needed for EARLY_AP_STARTUP. > >> > >> MFC after: 2 weeks > >> Sponsored by:Netflix > >> > >> Modified: > >> head/sys/kern/sched_4bsd.c > >> > > > > Thank you, jhb! > > I believe the previous change fixed the original issue you > reported as I was finally able to reproduce a similar hang > with sched_bind when igb0 was pinning its interrupts. It was > quite a bit of a PITA to track down. :( If you get a chance, > can you please verify that 4BSD + EARLY_AP_STARTUP now works for > you? > I'm now happily running this combination of options. -- Gary Jennejohn ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r308565 - head/sys/kern
On Sat, 12 Nov 2016 00:23:09 + (UTC) John Baldwin <j...@freebsd.org> wrote: > Author: jhb > Date: Sat Nov 12 00:23:09 2016 > New Revision: 308565 > URL: https://svnweb.freebsd.org/changeset/base/308565 > > Log: > Allow scheduling during early boot. > > - Send IPI wakeups once SMP is started even if cold is true. > - Permit preemptions when cold is true. > > These changes are needed for EARLY_AP_STARTUP. > > MFC after: 2 weeks > Sponsored by: Netflix > > Modified: > head/sys/kern/sched_4bsd.c > Thank you, jhb! -- Gary Jennejohn ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r304244 - head/sys/kern
On Tue, 16 Aug 2016 21:55:34 + (UTC)
Gleb Smirnoff <gleb...@freebsd.org> wrote:
> Author: glebius
> Date: Tue Aug 16 21:55:34 2016
> New Revision: 304244
> URL: https://svnweb.freebsd.org/changeset/base/304244
>
> Log:
> We should not be allowing a timeout to reset when a drain is in progress on
> it (either async or sync drain).
>
> At this moment the only user of drain is TCP, but TCP wouldn't reschedule a
> callout after it has drained it, since it drains only when a tcpcb is
> closed.
> This for now the problem isn't observed.
>
> Submitted by: rrs
>
> Modified:
> head/sys/kern/kern_timeout.c
>
> Modified: head/sys/kern/kern_timeout.c
> ==
> --- head/sys/kern/kern_timeout.c Tue Aug 16 21:32:05 2016
> (r304243)
> +++ head/sys/kern/kern_timeout.c Tue Aug 16 21:55:34 2016
> (r304244)
> @@ -1061,7 +1061,7 @@ callout_reset_sbt_on(struct callout *c,
>*/
> if (c->c_lock != NULL && !cc_exec_cancel(cc, direct))
> cancelled = cc_exec_cancel(cc, direct) = true;
> - if (cc_exec_waiting(cc, direct)) {
> + if (cc_exec_waiting(cc, direct) || cc_exec_drain(cc, dir)) {
> <== dir in this line should really be direct.
> /*
> * Someone has called callout_drain to kill this
>* callout. Don't reschedule.
--
Gary Jennejohn
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r293720 - head/sys/dev/hyperv/netvsc
On Tue, 12 Jan 2016 08:55:25 +0100 Joel Dahl <j...@vnode.se> wrote: > On Tue, Jan 12, 2016 at 01:41:34AM +, Sepherosa Ziehau wrote: > > Author: sephe > > Date: Tue Jan 12 01:41:34 2016 > > New Revision: 293720 > > URL: https://svnweb.freebsd.org/changeset/base/293720 > > > > Log: > > hyperv/hn: Implement SIOC[SG]IFMEDIA support > > > > Many applications and kernel modules (e.g. bridge) rely on the ifmedia > > status report; give them what they want. > > > > Submitted by: Dexuan Cui > > Reviewed by: Jun Su , me, adrian > > Modified by: me (minor) > ^^^ Really? > > % finger m...@freebsd.org > [freebsd.org] > Trying 8.8.178.110... > Login: me Name: Michael Elbel > Directory: /home/me Shell: /usr/local/bin/bash > No Mail. > Mail forwarded to: > m...@consol.de > # me > No Plan. > Michael has been in the password file since the early 1990s when jkh added him and a number of other friends/colleagues from his days in Germany, including myself (gj@, but I had a commit bit at one time). Michael never had a commit bit and I doubt that he's even logged into freefall for years. Maybe his name should be changed to melbel, which would eliminate the me/me@ kerfuffle. -- Gary Jennejohn ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r290003 - head/sys/ofed/include/linux
On Thu, 29 Oct 2015 16:28:51 +0100 Hans Petter Selasky <h...@selasky.org> wrote: > On 10/29/15 15:36, Gleb Smirnoff wrote: > >> The LinuxKPI is not a binary compatibility module, and will at some > > H> point have API's diverging from Linux, to fit BSD API's better. > > > > This statement makes the name of LinuxKPI quite pointless, as well > > as the whole idea of the KPI unclear. > > Hi, > > To be more clear. Adding bind_irq_to_cpu() is more an exception than the > default. A the moment I think Linux doesn't have an equivalent of this > function, because of Linux's interrupt model. > My question is whether a "normal" FreeBSD user has any reason to enable LinuxKPI now or in the future. -- Gary Jennejohn ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r279603 - in head: bin/rcp usr.bin/rlogin usr.bin/rsh
On Fri, 6 Mar 2015 12:05:23 +0300 Dmitry Sivachenko de...@freebsd.org wrote: On 5 __ 2015 __., at 22:22, Alfred Perlstein alf...@freebsd.org wrote: On 3/5/15 6:09 AM, David Chisnall wrote: On 5 Mar 2015, at 14:04, Dmitry Sivachenko de...@freebsd.org wrote: It is so nice to have most useful stuff out of the box. The question is whether a tool for logging into remote machines without encryption is 'the most useful stuff'. The tool is also [ab]used for network testing, but we already provide a better tool for that in the form of nc(1). David Agree. Moving it out of base +1000. It's time we made FreeBSD into an actual distro which is what is happening anyhow. This is a great time! This would become a new fool's day, really. Don't act like a monkey copying other's bad decisions. Having rich base system always were one of FreeBSD's strength, please don't break it. Exactly. If I have to screw around installing utilities which should be part of the base system (and have been there for the last 30+ years) then I might as well move to Linux, as a previous poster noted. I want BSD, not some bastardized Linux. -- Gary Jennejohn ___ 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: r268074 - head/sys/kern
On Tue, 1 Jul 2014 16:19:20 +0200
Mateusz Guzik mjgu...@gmail.com wrote:
On Tue, Jul 01, 2014 at 09:40:57AM -0400, John Baldwin wrote:
On Tuesday, July 01, 2014 2:29:15 am Mateusz Guzik wrote:
Modified: head/sys/kern/kern_sig.c
==
--- head/sys/kern/kern_sig.c Tue Jul 1 06:23:48 2014
(r268073)
+++ head/sys/kern/kern_sig.c Tue Jul 1 06:29:15 2014
(r268074)
@@ -3453,10 +3453,6 @@ sigacts_copy(struct sigacts *dest, struc
int
sigacts_shared(struct sigacts *ps)
{
- int shared;
- mtx_lock(ps-ps_mtx);
- shared = ps-ps_refcnt 1;
- mtx_unlock(ps-ps_mtx);
- return (shared);
+ return (ps-ps_refcnt 1);
}
You should KASSERT() in sigacts_shared that P_HADTHREADS is not set so that
new code does not call this function unsafely in the future.
Looks more like !P_HADTHREADS || p-p_singlethread != NULL on the first
sight, but yeah, I'll add an assertion.
Also, please fix the build with gcc, which dies with an error that
newsigacts may be use unitialzed.
What I did was set both oldsigacts and newsigacts to NULL before this
line at around 622:
if (sigacts_share(p-p_sigacts)) {
which allowed me to remove the else branch for setting oldsigacts to
NULL.
--
Gary Jennejohn
___
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: r268074 - head/sys/kern
On Tue, 1 Jul 2014 17:41:12 +0200
Mateusz Guzik mjgu...@gmail.com wrote:
On Tue, Jul 01, 2014 at 05:05:24PM +0200, Gary Jennejohn wrote:
On Tue, 1 Jul 2014 16:19:20 +0200
Mateusz Guzik mjgu...@gmail.com wrote:
On Tue, Jul 01, 2014 at 09:40:57AM -0400, John Baldwin wrote:
On Tuesday, July 01, 2014 2:29:15 am Mateusz Guzik wrote:
Modified: head/sys/kern/kern_sig.c
==
--- head/sys/kern/kern_sig.c Tue Jul 1 06:23:48 2014
(r268073)
+++ head/sys/kern/kern_sig.c Tue Jul 1 06:29:15 2014
(r268074)
@@ -3453,10 +3453,6 @@ sigacts_copy(struct sigacts *dest, struc
int
sigacts_shared(struct sigacts *ps)
{
- int shared;
- mtx_lock(ps-ps_mtx);
- shared = ps-ps_refcnt 1;
- mtx_unlock(ps-ps_mtx);
- return (shared);
+ return (ps-ps_refcnt 1);
}
You should KASSERT() in sigacts_shared that P_HADTHREADS is not set so
that
new code does not call this function unsafely in the future.
Looks more like !P_HADTHREADS || p-p_singlethread != NULL on the first
sight, but yeah, I'll add an assertion.
Also, please fix the build with gcc, which dies with an error that
newsigacts may be use unitialzed.
What I did was set both oldsigacts and newsigacts to NULL before this
line at around 622:
if (sigacts_share(p-p_sigacts)) {
which allowed me to remove the else branch for setting oldsigacts to
NULL.
Sorry for breakage.
Does the following fix the problem for you?
diff --git a/sys/kern/kern_exec.c b/sys/kern/kern_exec.c
index 91d161d..dc4eb9b 100644
--- a/sys/kern/kern_exec.c
+++ b/sys/kern/kern_exec.c
@@ -625,8 +625,10 @@ interpret:
oldsigacts = p-p_sigacts;
newsigacts = sigacts_alloc();
sigacts_copy(newsigacts, oldsigacts);
- } else
+ } else {
oldsigacts = NULL;
+ newsigacts = NULL; /* satisfy gcc */
+ }
PROC_LOCK(p);
if (oldsigacts)
Yes, this also works.
--
Gary Jennejohn
___
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: r228158 - in head: . share/mk sys/conf
On Mon, 5 Dec 2011 21:43:59 +0100
Hans Petter Selasky hsela...@c2i.net wrote:
Hi,
I see regressions when building kernel modules from /usr/ports:
On Monday 05 December 2011 14:39:56 Robert Huff wrote:
Hello:
When trying to update I get:
=== Building for cuse4bsd-kmod-0.1.21_2
make -f
/data/port-work/usr/ports/multimedia/cuse4bsd-kmod/work/cuse4bsd-kmod-0.1.
21/Makefile.lib HAVE_DEBUG=YES all Warning: Object directory not changed
from original
/data/port-work/usr/ports/multimedia/cuse4bsd-kmod/work/cuse4bsd-kmod-0.1.
21 make -f
/data/port-work/usr/ports/multimedia/cuse4bsd-kmod/work/cuse4bsd-kmod-0.1.
21/Makefile.kmod all /sys/conf/kmod.mk, line 204: Malformed conditional
(${MK_CTF} != no) /sys/conf/kmod.mk, line 206: if-less endif
make: fatal errors encountered -- cannot continue
*** Error code 1
I encountered this problem yesterday. My quick hack was to put
.if defined(MK_CTF) .endif around the offending lines, similar to
EXPORT_SYMS.
--
Gary Jennejohn
___
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: r217718 - in head/sys: conf dev/usb
On Sun, 23 Jan 2011 10:19:02 +0100 Hans Petter Selasky hsela...@freebsd.org wrote: On Saturday 22 January 2011 16:09:18 Gary Jennejohn wrote: On Sat, 22 Jan 2011 13:52:23 + (UTC) Hans Petter Selasky hsela...@freebsd.org wrote: Author: hselasky Date: Sat Jan 22 13:52:23 2011 New Revision: 217718 URL: http://svn.freebsd.org/changeset/base/217718 Log: Allow USB_HOST_ALIGN to be configured at compile time. This patch is necessary for MIPS based RouterStation Pro board and maybe other MIPS based boards as well. Submitted by: Milan Obuch Approved by:thompsa (mentor) Modified: head/sys/conf/options head/sys/dev/usb/usb_freebsd.h Modified: head/sys/conf/options = = --- head/sys/conf/options Sat Jan 22 13:18:28 2011 (r217717) +++ head/sys/conf/options Sat Jan 22 13:52:23 2011(r217718) @@ -642,6 +642,7 @@ BUS_DEBUG opt_bus.h # options for USB support USB_DEBUGopt_usb.h +USB_HOST_ALIGN opt_usb.h Sorry I didn't see this option sneaking in during r217631 :-) Anyway, two times is better than one time :-) USB_REQ_DEBUGopt_usb.h USB_VERBOSE opt_usb.h USB_EHCI_BIG_ENDIAN_DESC opt_usb.h Modified: head/sys/dev/usb/usb_freebsd.h = = --- head/sys/dev/usb/usb_freebsd.h Sat Jan 22 13:18:28 2011 (r217717) +++ head/sys/dev/usb/usb_freebsd.hSat Jan 22 13:52:23 2011 (r217718) @@ -46,7 +46,12 @@ #define USB_TD_GET_PROC(td) (td)-td_proc #define USB_PROC_GET_GID(td) (td)-p_pgid +#if defined(USB_HOST_ALIGN) (USB_HOST_ALIGN != 0) +/* USB_HOST_ALIGN is already defined and valid */ Not necessarily valid. What if the user sets it to -24? The compiler will happily accept that with the above #if-statement. IMO you should test for USB_HOST_ALIGN 0, which should always work. Defensive programming is always a good idea. I agree. Does this look OK: #if defined(USB_HOST_ALIGN) (USB_HOST_ALIGN != 0) #if (-USB_HOST_ALIGN USB_HOST_ALIGN) == USB_HOST_ALIGN #error USB_HOST_ALIGN is not power of two. #endif #if (USB_HOST_ALIGN = 0) #error USB_HOST_ALIGN is less than or equal to zero. #endif ... Looks OK to me. Rather convoluted, but the #else down below makes that necessary, I guess. +#else +#undef USB_HOST_ALIGN #define USB_HOST_ALIGN8 /* bytes, must be power of two */ +#endif #define USB_FS_ISOC_UFRAME_MAX 4/* exclusive unit */ #define USB_BUS_MAX 256 /* units */ #define USB_MAX_DEVICES 128 /* units */ -- Gary Jennejohn ___ 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: r217718 - in head/sys: conf dev/usb
On Sat, 22 Jan 2011 13:52:23 + (UTC) Hans Petter Selasky hsela...@freebsd.org wrote: Author: hselasky Date: Sat Jan 22 13:52:23 2011 New Revision: 217718 URL: http://svn.freebsd.org/changeset/base/217718 Log: Allow USB_HOST_ALIGN to be configured at compile time. This patch is necessary for MIPS based RouterStation Pro board and maybe other MIPS based boards as well. Submitted by: Milan Obuch Approved by:thompsa (mentor) Modified: head/sys/conf/options head/sys/dev/usb/usb_freebsd.h Modified: head/sys/conf/options == --- head/sys/conf/options Sat Jan 22 13:18:28 2011(r217717) +++ head/sys/conf/options Sat Jan 22 13:52:23 2011(r217718) @@ -642,6 +642,7 @@ BUS_DEBUG opt_bus.h # options for USB support USB_DEBUGopt_usb.h +USB_HOST_ALIGN opt_usb.h USB_REQ_DEBUGopt_usb.h USB_VERBOSE opt_usb.h USB_EHCI_BIG_ENDIAN_DESC opt_usb.h Modified: head/sys/dev/usb/usb_freebsd.h == --- head/sys/dev/usb/usb_freebsd.hSat Jan 22 13:18:28 2011 (r217717) +++ head/sys/dev/usb/usb_freebsd.hSat Jan 22 13:52:23 2011 (r217718) @@ -46,7 +46,12 @@ #define USB_TD_GET_PROC(td) (td)-td_proc #define USB_PROC_GET_GID(td) (td)-p_pgid +#if defined(USB_HOST_ALIGN) (USB_HOST_ALIGN != 0) +/* USB_HOST_ALIGN is already defined and valid */ Not necessarily valid. What if the user sets it to -24? The compiler will happily accept that with the above #if-statement. IMO you should test for USB_HOST_ALIGN 0, which should always work. Defensive programming is always a good idea. +#else +#undef USB_HOST_ALIGN #define USB_HOST_ALIGN8 /* bytes, must be power of two */ +#endif #define USB_FS_ISOC_UFRAME_MAX 4/* exclusive unit */ #define USB_BUS_MAX 256 /* units */ #define USB_MAX_DEVICES 128 /* units */ ___ svn-src-...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org -- Gary Jennejohn ___ 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: r216836 - head/share/misc
On Fri, 31 Dec 2010 11:55:39 + (UTC) Gavin Atkinson ga...@freebsd.org wrote: Author: gavin Date: Fri Dec 31 11:55:39 2010 New Revision: 216836 URL: http://svn.freebsd.org/changeset/base/216836 Log: For committers listed as alumni, add the date that their commit bit was returned where this information is missing and easy to determine. Move adrian@ back to the Active committers section. Hmm, I (gj@) should be in there somewhere, since I was a src committer from about 1995 until about 2007 or so. Can't find myself :( For that matter, I'm not in committers-ports.dot either, although I am still active as a ports committer. Ah well, just administrative trivia. -- Gary Jennejohn ___ 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: r215088 - head/sys/geom/part
On Wed, 10 Nov 2010 09:40:03 -0800 Marcel Moolenaar xcl...@mac.com wrote: On Nov 10, 2010, at 6:38 AM, Andrey V. Elsukov wrote: Author: ae Date: Wed Nov 10 14:38:51 2010 New Revision: 215088 URL: http://svn.freebsd.org/changeset/base/215088 Log: In r212554 name of G_PART_PARM_GEOM and G_PART_PARM_PROVIDER ctlreq parameters was changed to arg0. Fix the last place where it is used. A regression for sure. Nothing worse than having a good and clear interface messed up by a lousy implementation of geom(8)... *sigh* I wondered about this change myself. Juat because it's called arg0 in the declaration doesn't mean that the callers have to use it. Maybe ther was a good reason for it which I don't understand. Consistency, I suppose. -- Gary Jennejohn ___ 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: r214431 - head/bin/rm
On Thu, 28 Oct 2010 16:22:05 +1100 (EST) Bruce Evans b...@optusnet.com.au wrote: On Wed, 27 Oct 2010, Xin LI wrote: I think what really defeats -P is the fact that the file system or underlying data storage would not overwrite data on a file at sync(). COW is of course one of the case, journaling MAY defeat -P but is not guaranteed. FS with variable block size - I believe this really depends on the implementation. If I understood the code correctly, UFS, UFS+SU, UFS+SUJ, msdosfs and ext2fs supports rm -P as long as they are not being put on gjournal'ed disk, ZFS zvol, etc., and no snapshot is being used. And that the underlying data storage us dumb. Any flash drive now tries to minimise writes. It wouldn't take much buffering to defeat the 0xff, 0,0xff pattern. Wear leveling should result in different physical blocks being written each time if the writes get to the lowest level of storage. And that block reallocation (done by ffs1 and ffs2) doesn't choose different blocks. It seems to be hard for me to conclude all cases in short, plain English but I'm all for improvements to the manual page to describe that in an elegant and precise manner. Maybe something like: === BUGS The -P option assumes that the underlying storage overwrites file block when data is written on existing offset. Several factors including the file system and its backing store could defeat the assumption, this includes, but is not limited to file systems that uses Copy-On-Write strategy (e.g. ZFS or UFS when snapshot is being used), or backing datastore that does journaling, etc. In addition, only regular files are overwritten, other types of files are not. === Summary: it is very hard to tell whether -P works, even when you think you know what all the subsystems are doing. All this discussion leads me to the conclusion that we should just remove the -P functionality and add a remark to the man page that that was done because it isn't guaranteed to work on all file systems. Why give users a false sense of security? If they're concerned about data security then they should use geli or something similar. -- Gary Jennejohn ___ 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
