svn commit: r303217 - in head/usr.sbin/pw: . tests
Author: bapt
Date: Sat Jul 23 10:19:10 2016
New Revision: 303217
URL: https://svnweb.freebsd.org/changeset/base/303217
Log:
Do not try to delete the home of the user if is is not a directory for example
"/dev/null"
PR: 211195
Submitted by: rday
Reported by: eniorm
MFC after:1 day
Modified:
head/usr.sbin/pw/rm_r.c
head/usr.sbin/pw/tests/pw_userdel.sh
Modified: head/usr.sbin/pw/rm_r.c
==
--- head/usr.sbin/pw/rm_r.c Sat Jul 23 08:23:57 2016(r303216)
+++ head/usr.sbin/pw/rm_r.c Sat Jul 23 10:19:10 2016(r303217)
@@ -50,6 +50,9 @@ rm_r(int rootfd, const char *path, uid_t
path++;
dirfd = openat(rootfd, path, O_DIRECTORY);
+ if (dirfd == -1) {
+ return;
+ }
d = fdopendir(dirfd);
while ((e = readdir(d)) != NULL) {
Modified: head/usr.sbin/pw/tests/pw_userdel.sh
==
--- head/usr.sbin/pw/tests/pw_userdel.shSat Jul 23 08:23:57 2016
(r303216)
+++ head/usr.sbin/pw/tests/pw_userdel.shSat Jul 23 10:19:10 2016
(r303217)
@@ -59,9 +59,18 @@ delete_numeric_name_body() {
${PW} userdel -n 4001
}
+atf_test_case home_not_a_dir
+home_not_a_dir_body() {
+ populate_root_etc_skel
+ touch ${HOME}/foo
+ atf_check ${RPW} useradd foo -d /foo
+ atf_check ${RPW} userdel foo -r
+}
+
atf_init_test_cases() {
atf_add_test_case rmuser_seperate_group
atf_add_test_case user_do_not_try_to_delete_root_if_user_unknown
atf_add_test_case delete_files
atf_add_test_case delete_numeric_name
+ atf_add_test_case home_not_a_dir
}
___
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: r301453 - in head/sys: arm/arm arm64/arm64 dev/fdt dev/gpio dev/iicbus dev/ofw dev/pci dev/vnic kern mips/mips sys
Dne 21.07.2016 v 17:53 Nathan Whitehorn napsal(a): > > > On 07/21/16 00:34, Michal Meloun wrote: >> Dne 20.07.2016 v 17:45 Nathan Whitehorn napsal(a): >>> >>> >>> On 07/20/16 04:28, Michal Meloun wrote: Dne 19.07.2016 v 17:06 Nathan Whitehorn napsal(a): > > > On 07/19/16 04:13, Michal Meloun wrote: >> Dne 19.07.2016 v 2:11 Nathan Whitehorn napsal(a): >> Hi Nathan, >> I’m afraid that skra is on vacation, for next 2 weeks (at >> minimum), so >> please don’t expect quick response. >> >>> Could you please describe what this change is in more detail? >> Short description is appended. >> >>> It breaks a lot of encapsulations we have worked very hard to >>> maintain, >>> moves ARM code into MI parts of the kernel, and the OFW parts >>> violate >>> IEEE 1275 (the Open Firmware standard). In particular, there is no >>> guarantee that the interrupts for a newbus (or OF) device are >>> encoded in >>> a property called "interrupts" (or, indeed, in any property at >>> all) on >>> that node and there are many, many device trees where that is >>> not the >>> case (e.g. ones with interrupt maps, as well as Apple hardware). By >>> putting that knowledge into the OF root bus device, which we >>> have tried >>> to keep it out of, this enforces a standard that doesn't >>> actually exist. >> Imho, this patch doesn’t change anything in this area. Only >> handling of >> “interrupts” property is changed, all other cases are unchanged (I >> hope). Also, INTRNG code is currently shared by ARM, ARM64 and >> MIPS. > > But "interrupts" isn't a generic part of OF. This makes it one, > incorrectly. How? Can you be little more exact ? >>> >>> Because it puts knowledge into ofwbus that expects that children at >>> arbitrary levels of nesting have interrupts defined by an >>> "interrupts" property. You could patch this through on sub-devices, >>> of course, but that's already done correctly by the existing >>> ofw_bus_map_intr() code in a much more robust way that doesn't >>> involve trying to guess how sub-buses and devices have chosen to >>> allocate resources. Why reinvent the wheel all the way through the >>> bus hierarchy? >> Nope, the code only expect that „interrupts" property is default way >> hot to get interrupt description. Any device or bus in the hierarchy >> can fill appropriate resource list, or terminate call at any level. > > "interrupts" should not be the default -- it's part of the OF bindings > for the bus and is used (notably) by simplebus. The issue of > cross-correlating RIDs is a much larger problem, however. > Can we postpone this problem while, please? > [snip] >>> >> >> The patch simply postpones reading of interrupt property to >> bus_alloc_resource() (called by consumer driver) time. >> >> Due to this, we can: >> - parse interrupt property. The interrupt driver must exist >>at this time. > > This only works with some types of interrupt properties, not all, > and breaks if the interrupt driver hasn't attached yet (which it > can't be guaranteed to -- some PPC systems have interrupt drivers > that live on the PCI bus, for example). How you can allocate (and reserve it in rman) interrupt if is not mapped (so you have not real IRQ number for it). Just for notice - multiple virtual IRQs can be mapped into single real IRQ. >>> >>> The core idea is to think of the full interrupt specifier -- the >>> interrupt parent and the full byte string in the device tree -- as >>> the IRQ rather than the interrupt pin on some chip (which is >>> usually, but not always, the first word in that byte string). The >>> "virtual" IRQ number is just a compression of that longer piece of >>> data, which usually can't fit in an rman resource. >> I understand. While this approach can works (and actually works) for >> single sourced OFW world, it immediately fails if you must be able to >> parse data from different sources (which uses different encoding) >> (OFW, UEFI / ACPI, GPIO...) within one system. > > > On PowerPC, GENERIC64 supports FDT systems (some IBM hardware), OFW > systems (Macs, some IBM hardware), systems with no device trees at all > (old-style PS3), and systems with a mixture of device tree and no > device tree (new-style PS3). On these, there is a mixture of "real" > interrupts and GPIO-type interrupts. There is no limitation that this > be used only for device-tree-type systems. > > The system requires two things: an interrupt domain key and an > arbitrary unique byte string describing the interrupt. When running > with a device tree, these are set to the phandle of the > interrupt-parent and the contents of the device tree interrupt > specifier, respectively, and the system was of course developed with > that in mind. But they don't need to be, and often aren't. You could > make the domain an elemen
Re: svn commit: r301453 - in head/sys: arm/arm arm64/arm64 dev/fdt dev/gpio dev/iicbus dev/ofw dev/pci dev/vnic kern mips/mips sys
Dne 21.07.2016 v 23:35 John Baldwin napsal(a):
> On Thursday, July 21, 2016 01:37:42 PM Andrew Turner wrote:
>> On Wed, 20 Jul 2016 13:28:53 +0200
>> Michal Meloun wrote:
>>> Dne 19.07.2016 v 17:06 Nathan Whitehorn napsal(a):
2. It partially duplicates the functionality of OFW_BUS_MAP_INTR(),
but is both problematically more general and less flexible (it has
requirements on timing of PIC attachment vs. driver resource
allocation)
>>> OFW_BUS_MAP_INTR() can parse only OFW based data and expect that
>>> parsed data are magicaly stored within the call.
>>> The new method, bus_map_intr(), can parse data from multiple sources
>>> (OFW, UEFI / ACPI, synthetic[gpio device + pin number]). It also
>>> returns parsed data back to caller.
>>> And no, it doesn't add any additional timing requirements .
>> I've been looking at ACPI on arm64. So far I have not found the need
>> for this with ACPI as we don't need to send the data to the interrupt
>> controller driver to be parsed in the way OFW/FDT needs to.
> ACPI though has a gross hack where we call BUS_CONFIG_INTR on the IRQ
> in bus_alloc_resource(). What I had advocated in the discussions
> leading up to this was to have some sort of opaque structure containing
> a set of properties (the sort of thing bus_map_resource and make_dev_s
> use) that was passed up at bus_setup_intr() time. I think it should now
> be passed up at bus_alloc_resource() time instead, but it would allow bus
> drivers to "decorate" a SYS_RES_IRQ request as it goes up the device tree
> with properties that the interrupt controller can then associate with
> the IRQ cookie it allocates in its own code. I would let the particular
> structure have different layouts for different resource types. On x86 we
> would replace bus_config_intr by passing the level and trigger-mode in
> this structure. However, I could also see allowing the memattr to be
> set for a SYS_RES_MEMORY resource so you could have a much shorter way
> than an explicit bus_map_resource to map an entire BAR as WC for example:
>
> struct alloc_resource_args {
> size_t len;
> union {
> struct {
> enum intr_trigger trigger;
> enum intr_polarity polarity;
> } irq;
> struct {
> vm_memattr_t memattr;
> } memory;
> }
> }
>
> ...
>
> union alloc_resource_args args;
>
> init_alloc_resource_args(&args, sizeof(args));
> args.memattr = VM_MEMATTR_WRITE_COMBINING;
>
> /* Uses WC for the implicit mapping. */
> res = bus_alloc_resource(, &args);
>
> ...
>
> foobus_alloc_resource(..., union alloc_resource_args *args)
> {
> union alloc_resource_args args2;
>
> switch (type) {
> case SYS_RES_IRQ:
> if (args == NULL) {
> init_alloc_resource_args(&args2, sizeof(args2));
> args = &args2;
> }
> /* Replace call to BUS_CONFIG_INTR on ACPI: */
> if (args->irq.polarity == INTR_POLARITY_CONFORMING &&
> device_has_polarity_from_CRS)
> args->irq.polarity = polarity_from_CRS;
> ...
> }
>
> However, you could associate arbitrary data with a resource request by
> adding more members to the approriate struct in the union.
>
I like this idea. Mainly if we can add 'struct alloc_resource_args' into
'struct resource_list_entry' and, eventually, also into struct resource_i.
Inability to pass something more complex as single integer between bus
enumerator (aka resource_list_entry creator) and bus_alloc_resource()
(aka resource_list_entry consumer) is serious limitation. At lest for me :)
Michal
___
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"
svn commit: r303218 - head/tools/tools/locale/tools
Author: bapt
Date: Sat Jul 23 11:24:05 2016
New Revision: 303218
URL: https://svnweb.freebsd.org/changeset/base/303218
Log:
Add another hack to add weekday to date format to more locales
While here only initialize the iconv converter when needed
Modified:
head/tools/tools/locale/tools/cldr2def.pl
Modified: head/tools/tools/locale/tools/cldr2def.pl
==
--- head/tools/tools/locale/tools/cldr2def.pl Sat Jul 23 10:19:10 2016
(r303217)
+++ head/tools/tools/locale/tools/cldr2def.pl Sat Jul 23 11:24:05 2016
(r303218)
@@ -201,12 +201,12 @@ sub callback_ampm {
my $s = shift;
my $nl = $callback{data}{l} . "_" . $callback{data}{c};
my $enc = $callback{data}{e};
- my $converter = Text::Iconv->new("utf-8", "$enc");
if ($nl eq 'ru_RU') {
if ($enc eq 'UTF-8') {
$s = 'дп;пп';
} else {
+ my $converter = Text::Iconv->new("utf-8", "$enc");
$s = $converter->convert("дп;пп");
}
}
@@ -220,6 +220,7 @@ sub callback_cformat {
$s =~ s/\.,/\./;
$s =~ s/ %Z//;
$s =~ s/ %z//;
+ $s =~ s/^"%e\./%A %e/;
$s =~ s/^"(%B %e, )/"%A, $1/;
$s =~ s/^"(%e %B )/"%A $1/;
return $s;
@@ -241,6 +242,7 @@ sub callback_dtformat {
$s =~ s/(> )(%H)/$1%A $2/;
}
$s =~ s/\.,/\./;
+ $s =~ s/^"%e\./%A %e/;
$s =~ s/^"(%B %e, )/"%A, $1/;
$s =~ s/^"(%e %B )/"%A $1/;
return $s;
___
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"
svn commit: r303219 - head/share/timedef
Author: bapt Date: Sat Jul 23 11:25:34 2016 New Revision: 303219 URL: https://svnweb.freebsd.org/changeset/base/303219 Log: Add weekday to the date format of more locales MFC after:1 day Modified: head/share/timedef/cs_CZ.ISO8859-2.src head/share/timedef/cs_CZ.UTF-8.src head/share/timedef/da_DK.ISO8859-15.src head/share/timedef/da_DK.UTF-8.src head/share/timedef/de_AT.ISO8859-15.src head/share/timedef/de_AT.UTF-8.src head/share/timedef/de_DE.ISO8859-15.src head/share/timedef/de_DE.UTF-8.src head/share/timedef/et_EE.ISO8859-15.src head/share/timedef/et_EE.UTF-8.src head/share/timedef/fi_FI.ISO8859-15.src head/share/timedef/fi_FI.UTF-8.src head/share/timedef/hr_HR.ISO8859-2.src head/share/timedef/hr_HR.UTF-8.src head/share/timedef/is_IS.ISO8859-15.src head/share/timedef/is_IS.UTF-8.src head/share/timedef/nb_NO.ISO8859-15.src head/share/timedef/nb_NO.UTF-8.src head/share/timedef/nn_NO.ISO8859-15.src head/share/timedef/nn_NO.UTF-8.src head/share/timedef/sk_SK.ISO8859-2.src head/share/timedef/sk_SK.UTF-8.src Modified: head/share/timedef/cs_CZ.ISO8859-2.src == --- head/share/timedef/cs_CZ.ISO8859-2.src Sat Jul 23 11:24:05 2016 (r303218) +++ head/share/timedef/cs_CZ.ISO8859-2.src Sat Jul 23 11:25:34 2016 (r303219) @@ -56,14 +56,14 @@ sobota %d.%m.%y # # c_fmt -%e. %B %Y %H:%M:%S +%A %e %B %Y %H:%M:%S # # AM/PM dopoledne odpoledne # # date_fmt -%e. %B %Y %H:%M:%S %Z +%A %e %B %Y %H:%M:%S %Z # # Long month names (without case ending) leden Modified: head/share/timedef/cs_CZ.UTF-8.src == --- head/share/timedef/cs_CZ.UTF-8.src Sat Jul 23 11:24:05 2016 (r303218) +++ head/share/timedef/cs_CZ.UTF-8.src Sat Jul 23 11:25:34 2016 (r303219) @@ -56,14 +56,14 @@ sobota %d.%m.%y # # c_fmt -%e. %B %Y %H:%M:%S +%A %e %B %Y %H:%M:%S # # AM/PM dopoledne odpoledne # # date_fmt -%e. %B %Y %H:%M:%S %Z +%A %e %B %Y %H:%M:%S %Z # # Long month names (without case ending) leden Modified: head/share/timedef/da_DK.ISO8859-15.src == --- head/share/timedef/da_DK.ISO8859-15.src Sat Jul 23 11:24:05 2016 (r303218) +++ head/share/timedef/da_DK.ISO8859-15.src Sat Jul 23 11:25:34 2016 (r303219) @@ -56,14 +56,14 @@ l�rdag %d/%m/%Y # # c_fmt -%e. %B %Y kl. %H.%M.%S +%A %e %B %Y kl. %H.%M.%S # # AM/PM AM PM # # date_fmt -%e. %B %Y kl. %H.%M.%S %Z +%A %e %B %Y kl. %H.%M.%S %Z # # Long month names (without case ending) januar Modified: head/share/timedef/da_DK.UTF-8.src == --- head/share/timedef/da_DK.UTF-8.src Sat Jul 23 11:24:05 2016 (r303218) +++ head/share/timedef/da_DK.UTF-8.src Sat Jul 23 11:25:34 2016 (r303219) @@ -56,14 +56,14 @@ lørdag %d/%m/%Y # # c_fmt -%e. %B %Y kl. %H.%M.%S +%A %e %B %Y kl. %H.%M.%S # # AM/PM AM PM # # date_fmt -%e. %B %Y kl. %H.%M.%S %Z +%A %e %B %Y kl. %H.%M.%S %Z # # Long month names (without case ending) januar Modified: head/share/timedef/de_AT.ISO8859-15.src == --- head/share/timedef/de_AT.ISO8859-15.src Sat Jul 23 11:24:05 2016 (r303218) +++ head/share/timedef/de_AT.ISO8859-15.src Sat Jul 23 11:25:34 2016 (r303219) @@ -56,14 +56,14 @@ Samstag %d.%m.%y # # c_fmt -%e. %B %Y um %H:%M:%S +%A %e %B %Y um %H:%M:%S # # AM/PM vorm. nachm. # # date_fmt -%e. %B %Y um %H:%M:%S %Z +%A %e %B %Y um %H:%M:%S %Z # # Long month names (without case ending) J�nner Modified: head/share/timedef/de_AT.UTF-8.src == --- head/share/timedef/de_AT.UTF-8.src Sat Jul 23 11:24:05 2016 (r303218) +++ head/share/timedef/de_AT.UTF-8.src Sat Jul 23 11:25:34 2016 (r303219) @@ -56,14 +56,14 @@ Samstag %d.%m.%y # # c_fmt -%e. %B %Y um %H:%M:%S +%A %e %B %Y um %H:%M:%S # # AM/PM vorm. nachm. # # date_fmt -%e. %B %Y um %H:%M:%S %Z +%A %e %B %Y um %H:%M:%S %Z # # Long month names (without case ending) Jänner Modified: head/share/timedef/de_DE.ISO8859-15.src == --- head/share/timedef/de_DE.ISO8859-15.src Sat Jul 23 11:24:05 2016 (r303218) +++ head/share/timedef/de_DE.ISO8859-15.src Sat Jul 23 11:25:34 2016 (r303219) @@ -56,14 +56,14 @@ Samstag %d.%m.%y # # c_fmt -%e. %B %Y um %H:%M:%S +%A %e %B %Y um %H:%M:%S # # AM/PM vorm. nachm. # # date_fmt -%e. %B %Y um %H:%M:%S %Z +%A %e %B %Y um %H:%M:%S %Z # # Long month names (without case ending) Januar Modified: head/share/timedef/de_DE.UTF-8.src ==
Re: svn commit: r303218 - head/tools/tools/locale/tools
On 23.07.2016 14:24, Baptiste Daroussin wrote:
> Author: bapt
> Date: Sat Jul 23 11:24:05 2016
> New Revision: 303218
> URL: https://svnweb.freebsd.org/changeset/base/303218
>
> Log:
> Add another hack to add weekday to date format to more locales
>
> While here only initialize the iconv converter when needed
>
> Modified:
> head/tools/tools/locale/tools/cldr2def.pl
BTW, is there any progress in generating all collates with -m ${area} as
you planned?
___
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: r303218 - head/tools/tools/locale/tools
On Sat, Jul 23, 2016 at 02:41:39PM +0300, Andrey Chernov wrote:
> On 23.07.2016 14:24, Baptiste Daroussin wrote:
> > Author: bapt
> > Date: Sat Jul 23 11:24:05 2016
> > New Revision: 303218
> > URL: https://svnweb.freebsd.org/changeset/base/303218
> >
> > Log:
> > Add another hack to add weekday to date format to more locales
> >
> > While here only initialize the iconv converter when needed
> >
> > Modified:
> > head/tools/tools/locale/tools/cldr2def.pl
>
> BTW, is there any progress in generating all collates with -m ${area} as
> you planned?
>
you mean the @modifier?
Bapt
signature.asc
Description: PGP signature
svn commit: r303223 - head/contrib/mdocml
Author: bapt Date: Sat Jul 23 11:55:15 2016 New Revision: 303223 URL: https://svnweb.freebsd.org/changeset/base/303223 Log: Update mandoc to 1.13.4 release Added: head/contrib/mdocml/man.cgi.3 - copied unchanged from r303222, vendor/mdocml/dist/man.cgi.3 Modified: head/contrib/mdocml/INSTALL head/contrib/mdocml/LICENSE head/contrib/mdocml/Makefile head/contrib/mdocml/NEWS head/contrib/mdocml/TODO head/contrib/mdocml/cgi.c head/contrib/mdocml/cgi.h.example head/contrib/mdocml/configure head/contrib/mdocml/configure.local.example head/contrib/mdocml/demandoc.c head/contrib/mdocml/libmandoc.h head/contrib/mdocml/main.c head/contrib/mdocml/main.h head/contrib/mdocml/man.1 head/contrib/mdocml/man.cgi.8 head/contrib/mdocml/mandoc.3 head/contrib/mdocml/mandoc.css head/contrib/mdocml/mandoc.db.5 head/contrib/mdocml/mandoc_headers.3 head/contrib/mdocml/mandoc_malloc.3 head/contrib/mdocml/mandocdb.c head/contrib/mdocml/manpage.c head/contrib/mdocml/manpath.c head/contrib/mdocml/mansearch.c head/contrib/mdocml/mchars_alloc.3 head/contrib/mdocml/read.c head/contrib/mdocml/tag.c head/contrib/mdocml/term.c head/contrib/mdocml/term_ascii.c head/contrib/mdocml/test-rewb-bsd.c head/contrib/mdocml/test-rewb-sysv.c Directory Properties: head/contrib/mdocml/ (props changed) Modified: head/contrib/mdocml/INSTALL == --- head/contrib/mdocml/INSTALL Sat Jul 23 11:47:04 2016(r303222) +++ head/contrib/mdocml/INSTALL Sat Jul 23 11:55:15 2016(r303223) @@ -1,4 +1,4 @@ -$Id: INSTALL,v 1.13 2015/11/07 14:01:16 schwarze Exp $ +$Id: INSTALL,v 1.15 2016/07/14 11:09:06 schwarze Exp $ About mdocml, the portable mandoc distribution -- @@ -16,7 +16,7 @@ tech@ mailing list, too. Enjoy using the mandoc toolset! -Ingo Schwarze, Karlsruhe, March 2015 +Ingo Schwarze, Karlsruhe, July 2016 Installation @@ -52,7 +52,7 @@ and go back to step 2. 4. Run "make -n install" and check whether everything will be installed to the intended places. Otherwise, put some *DIR or *NM* -variables into "configure.local" and go back to step�2. +variables into "configure.local" and go back to step 2. 5. Run "sudo make install". If you intend to build a binary package using some kind of fake root mechanism, you may need a @@ -63,7 +63,7 @@ in the "Makefile" to understand how DEST manpath(1), make sure it is configured correctly, in particular, it returns all directory trees where manual pages are installed. Otherwise, if your system uses man.conf(5), make sure it contains -a "_whatdb" line for each directory tree, and the order of these +a "manpath" line for each directory tree, and the order of these lines meets your wishes. 7. If you compiled with database support, run the command "sudo Modified: head/contrib/mdocml/LICENSE == --- head/contrib/mdocml/LICENSE Sat Jul 23 11:47:04 2016(r303222) +++ head/contrib/mdocml/LICENSE Sat Jul 23 11:55:15 2016(r303223) @@ -1,11 +1,11 @@ -$Id: LICENSE,v 1.11 2015/11/07 17:58:55 schwarze Exp $ +$Id: LICENSE,v 1.12 2016/07/07 23:46:36 schwarze Exp $ With the exceptions noted below, all code and documentation contained in the mdocml toolkit is protected by the Copyright of the following developers: Copyright (c) 2008-2012, 2014 Kristaps Dzonsons -Copyright (c) 2010-2015 Ingo Schwarze +Copyright (c) 2010-2016 Ingo Schwarze Copyright (c) 2009, 2010, 2011, 2012 Joerg Sonnenberger Copyright (c) 2013 Franco Fichtner Copyright (c) 2014 Baptiste Daroussin Modified: head/contrib/mdocml/Makefile == --- head/contrib/mdocml/MakefileSat Jul 23 11:47:04 2016 (r303222) +++ head/contrib/mdocml/MakefileSat Jul 23 11:55:15 2016 (r303223) @@ -1,7 +1,7 @@ -# $Id: Makefile,v 1.480 2015/11/07 21:53:14 schwarze Exp $ +# $Id: Makefile,v 1.488 2016/07/12 05:18:38 kristaps Exp $ # # Copyright (c) 2010, 2011, 2012 Kristaps Dzonsons -# Copyright (c) 2011, 2013, 2014, 2015 Ingo Schwarze +# Copyright (c) 2011, 2013-2016 Ingo Schwarze # # Permission to use, copy, modify, and distribute this software for any # purpose with or without fee is hereby granted, provided that the above @@ -15,7 +15,7 @@ # ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF # OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. -VERSION = 1.13.3 +VERSION = 1.13.4 # === LIST OF FILES @@ -31,6 +31,9 @@ TESTSRCS = test-dirent-namlen.c \ test-pledge.c \ test-progname.c \ test-reallocarray.c \ + test-rewb-bsd.c \ + test-rewb-sysv.c \ +
Re: svn commit: r303218 - head/tools/tools/locale/tools
On 23.07.2016 14:52, Baptiste Daroussin wrote:
> On Sat, Jul 23, 2016 at 02:41:39PM +0300, Andrey Chernov wrote:
>> On 23.07.2016 14:24, Baptiste Daroussin wrote:
>>> Author: bapt
>>> Date: Sat Jul 23 11:24:05 2016
>>> New Revision: 303218
>>> URL: https://svnweb.freebsd.org/changeset/base/303218
>>>
>>> Log:
>>> Add another hack to add weekday to date format to more locales
>>>
>>> While here only initialize the iconv converter when needed
>>>
>>> Modified:
>>> head/tools/tools/locale/tools/cldr2def.pl
>>
>> BTW, is there any progress in generating all collates with -m ${area} as
>> you planned?
>>
> you mean the @modifier?
No, I mean that:
>> Perhaps all uk_UA should be generated with -m ${area} too - Ukrainians
>> have extended Cyrillics in their alphabet and I am not sure that their
>> order match default Unicode order for Cyrillic. The same about be_BY,
>> bg_BG and sr_Cyrl_RS. They may match or may not, I don't check such
>deeply.
>>
>> It seems the safest side will be to generate all with -m ${area}
>>
>Yes that is my plan, except for the 1 or 2 that cannot be generated
>from cldr
>directly
signature.asc
Description: OpenPGP digital signature
Re: svn commit: r303218 - head/tools/tools/locale/tools
On Sat, Jul 23, 2016 at 02:58:31PM +0300, Andrey Chernov wrote:
> On 23.07.2016 14:52, Baptiste Daroussin wrote:
> > On Sat, Jul 23, 2016 at 02:41:39PM +0300, Andrey Chernov wrote:
> >> On 23.07.2016 14:24, Baptiste Daroussin wrote:
> >>> Author: bapt
> >>> Date: Sat Jul 23 11:24:05 2016
> >>> New Revision: 303218
> >>> URL: https://svnweb.freebsd.org/changeset/base/303218
> >>>
> >>> Log:
> >>> Add another hack to add weekday to date format to more locales
> >>>
> >>> While here only initialize the iconv converter when needed
> >>>
> >>> Modified:
> >>> head/tools/tools/locale/tools/cldr2def.pl
> >>
> >> BTW, is there any progress in generating all collates with -m ${area} as
> >> you planned?
> >>
> > you mean the @modifier?
>
> No, I mean that:
> >> Perhaps all uk_UA should be generated with -m ${area} too - Ukrainians
> >> have extended Cyrillics in their alphabet and I am not sure that their
> >> order match default Unicode order for Cyrillic. The same about be_BY,
> >> bg_BG and sr_Cyrl_RS. They may match or may not, I don't check such
> >deeply.
> >>
> >> It seems the safest side will be to generate all with -m ${area}
> >>
> >Yes that is my plan, except for the 1 or 2 that cannot be generated
> >from cldr
> >directly
>
Nope I haven't made any progress, and I actually did a bunch of tests of some
(honnestly not all locales) trying to get a representative set and could not
find differnce in ordering between locales generated with -m ${area}.
It would also needs lots of work on the generation tools.
I first need to write a tool that compares collation rules for various ${area}
(not done yet) to see how much this is really needed and use it in the
generation tools.
I will try to do that for 12 if it is really worth it (based on the result from
that comparison tools)
Best regards,
Bapt
signature.asc
Description: PGP signature
svn commit: r303224 - head/tools/tools/locale
Author: bapt Date: Sat Jul 23 12:34:32 2016 New Revision: 303224 URL: https://svnweb.freebsd.org/changeset/base/303224 Log: Recode the new dependency on converters/p5-Text-Iconv Modified: head/tools/tools/locale/README Modified: head/tools/tools/locale/README == --- head/tools/tools/locale/README Sat Jul 23 11:55:15 2016 (r303223) +++ head/tools/tools/locale/README Sat Jul 23 12:34:32 2016 (r303224) @@ -2,7 +2,7 @@ To generate the locales: -Tools needed: java, perl and devel/p5-Tie-IxHash +Tools needed: java, perl, devel/p5-Tie-IxHash and converters/p5-Text-Iconv fetch cldr data from: http://cldr.unicode.org extract in a directory ~/unicode/cldr/v27.0.1 for example ___ 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"
svn commit: r303225 - head/sys/dev/fb
Author: jhb
Date: Sat Jul 23 14:38:09 2016
New Revision: 303225
URL: https://svnweb.freebsd.org/changeset/base/303225
Log:
Use MTX_SYSINIT for the VESA lock.
vesa_init_done isn't a reliable guard for the mutex init. If
vesa_configure() doesn't find valid VESA info it will not set
vesa_init_done, but the lock will remain initialized. Revert r303076
and use MTX_SYSINIT to deterministically init the lock.
Reviewed by: royger
MFC after:1 week
Differential Revision:https://reviews.freebsd.org/D7290
Modified:
head/sys/dev/fb/vesa.c
Modified: head/sys/dev/fb/vesa.c
==
--- head/sys/dev/fb/vesa.c Sat Jul 23 12:34:32 2016(r303224)
+++ head/sys/dev/fb/vesa.c Sat Jul 23 14:38:09 2016(r303225)
@@ -79,6 +79,7 @@ struct adp_state {
typedef struct adp_state adp_state_t;
static struct mtx vesa_lock;
+MTX_SYSINIT(vesa_lock, &vesa_lock, "VESA lock", MTX_DEF);
static int vesa_state;
static void *vesa_state_buf;
@@ -134,7 +135,6 @@ static vi_fill_rect_t vesa_fill_rect;
static vi_bitblt_t vesa_bitblt;
static vi_diag_t vesa_diag;
static int vesa_bios_info(int level);
-static int vesa_late_load(int flags);
static video_switch_t vesavidsw = {
vesa_probe,
@@ -1142,7 +1142,7 @@ vesa_configure(int flags)
* initialization for now and try again later.
*/
if (adp == NULL) {
- vga_sub_configure = vesa_late_load;
+ vga_sub_configure = vesa_configure;
return (ENODEV);
}
@@ -1910,27 +1910,14 @@ vesa_bios_info(int level)
static int
vesa_load(void)
{
-
- return (vesa_late_load(0));
-}
-
-/*
- * To be called from the vga_sub_configure hook in case the VGA adapter is
- * not found when VESA is loaded.
- */
-static int
-vesa_late_load(int flags)
-{
int error;
if (vesa_init_done)
return (0);
- mtx_init(&vesa_lock, "VESA lock", NULL, MTX_DEF);
-
/* locate a VGA adapter */
vesa_adp = NULL;
- error = vesa_configure(flags);
+ error = vesa_configure(0);
if (error == 0)
vesa_bios_info(bootverbose);
@@ -1966,7 +1953,6 @@ vesa_unload(void)
}
vesa_bios_uninit();
- mtx_destroy(&vesa_lock);
return (error);
}
___
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"
svn commit: r303226 - head/sys/conf
Author: np
Date: Sat Jul 23 15:12:03 2016
New Revision: 303226
URL: https://svnweb.freebsd.org/changeset/base/303226
Log:
Fix kernel builds with "device cxgbe".
Modified:
head/sys/conf/files
Modified: head/sys/conf/files
==
--- head/sys/conf/files Sat Jul 23 14:38:09 2016(r303225)
+++ head/sys/conf/files Sat Jul 23 15:12:03 2016(r303226)
@@ -1243,6 +1243,7 @@ dev/cxgb/sys/uipc_mvec.c optional cxgb p
compile-with "${NORMAL_C} -I$S/dev/cxgb"
dev/cxgb/cxgb_t3fw.c optional cxgb cxgb_t3fw \
compile-with "${NORMAL_C} -I$S/dev/cxgb"
+dev/cxgbe/t4_if.m optional cxgbe pci
dev/cxgbe/t4_iov.c optional cxgbe pci \
compile-with "${NORMAL_C} -I$S/dev/cxgbe"
dev/cxgbe/t4_mp_ring.c optional cxgbe pci \
___
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"
svn commit: r303227 - head/sys/arm/conf
Author: loos Date: Sat Jul 23 17:36:17 2016 New Revision: 303227 URL: https://svnweb.freebsd.org/changeset/base/303227 Log: Remove unused USB ethernet driver from BEAGLEBONE/AM335x kernel. Modified: head/sys/arm/conf/BEAGLEBONE Modified: head/sys/arm/conf/BEAGLEBONE == --- head/sys/arm/conf/BEAGLEBONESat Jul 23 15:12:03 2016 (r303226) +++ head/sys/arm/conf/BEAGLEBONESat Jul 23 17:36:17 2016 (r303227) @@ -113,7 +113,6 @@ device bpf # USB Ethernet support, requires miibus device miibus -device axe # ASIX Electronics USB Ethernet # Device mode support and USFS template device usb_template# Control of the gadget ___ 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"
svn commit: r303230 - head/sys/dev/mii
Author: loos
Date: Sat Jul 23 18:16:40 2016
New Revision: 303230
URL: https://svnweb.freebsd.org/changeset/base/303230
Log:
Add support for the Microchip/Micrel KSZ9031 Gigabit Ethernet PHY.
Tested on uBMC and uFW.
Sponsored by: Rubicon Communications (Netgate)
Modified:
head/sys/dev/mii/micphy.c
head/sys/dev/mii/miidevs
Modified: head/sys/dev/mii/micphy.c
==
--- head/sys/dev/mii/micphy.c Sat Jul 23 17:41:47 2016(r303229)
+++ head/sys/dev/mii/micphy.c Sat Jul 23 18:16:40 2016(r303230)
@@ -67,6 +67,14 @@ __FBSDID("$FreeBSD$");
#defineMII_KSZPHY_CLK_CONTROL_PAD_SKEW 0x104
#defineMII_KSZPHY_RX_DATA_PAD_SKEW 0x105
#defineMII_KSZPHY_TX_DATA_PAD_SKEW 0x106
+/* KSZ9031 */
+#defineMII_KSZ9031_MMD_ACCESS_CTRL 0x0d
+#defineMII_KSZ9031_MMD_ACCESS_DATA 0x0e
+#define MII_KSZ9031_MMD_DATA_NOINC (1 << 14)
+#defineMII_KSZ9031_CONTROL_PAD_SKEW0x4
+#defineMII_KSZ9031_RX_DATA_PAD_SKEW0x5
+#defineMII_KSZ9031_TX_DATA_PAD_SKEW0x6
+#defineMII_KSZ9031_CLOCK_PAD_SKEW 0x8
#definePS_TO_REG(p)((p) / 200)
@@ -95,6 +103,7 @@ DRIVER_MODULE(micphy, miibus, micphy_dri
static const struct mii_phydesc micphys[] = {
MII_PHY_DESC(MICREL, KSZ9021),
+ MII_PHY_DESC(MICREL, KSZ9031),
MII_PHY_END
};
@@ -104,48 +113,128 @@ static const struct mii_phy_funcs micphy
mii_phy_reset
};
+static uint32_t
+ksz9031_read(struct mii_softc *sc, uint32_t devaddr, uint32_t reg)
+{
+ /* Set up device address and register. */
+PHY_WRITE(sc, MII_KSZ9031_MMD_ACCESS_CTRL, devaddr);
+PHY_WRITE(sc, MII_KSZ9031_MMD_ACCESS_DATA, reg);
+
+ /* Select register data for MMD and read the value. */
+PHY_WRITE(sc, MII_KSZ9031_MMD_ACCESS_CTRL,
+ MII_KSZ9031_MMD_DATA_NOINC | devaddr);
+
+ return (PHY_READ(sc, MII_KSZ9031_MMD_ACCESS_DATA));
+}
+
+static void
+ksz9031_write(struct mii_softc *sc, uint32_t devaddr, uint32_t reg,
+ uint32_t val)
+{
+
+ /* Set up device address and register. */
+ PHY_WRITE(sc, MII_KSZ9031_MMD_ACCESS_CTRL, devaddr);
+ PHY_WRITE(sc, MII_KSZ9031_MMD_ACCESS_DATA, reg);
+
+ /* Select register data for MMD and write the value. */
+ PHY_WRITE(sc, MII_KSZ9031_MMD_ACCESS_CTRL,
+ MII_KSZ9031_MMD_DATA_NOINC | devaddr);
+ PHY_WRITE(sc, MII_KSZ9031_MMD_ACCESS_DATA, val);
+}
+
+static uint32_t
+ksz9021_read(struct mii_softc *sc, uint32_t reg)
+{
+
+ PHY_WRITE(sc, MII_KSZPHY_EXTREG, reg);
+
+ return (PHY_READ(sc, MII_KSZPHY_EXTREG_READ));
+}
+
static void
-micphy_write(struct mii_softc *sc, uint32_t reg, uint32_t val)
+ksz9021_write(struct mii_softc *sc, uint32_t reg, uint32_t val)
{
PHY_WRITE(sc, MII_KSZPHY_EXTREG, KSZPHY_EXTREG_WRITE | reg);
PHY_WRITE(sc, MII_KSZPHY_EXTREG_WRITE, val);
}
-static int
-ksz9021_load_values(struct mii_softc *sc, phandle_t node, uint32_t reg,
- char *field1, char *field2,
- char *field3, char *field4)
+static void
+ksz90x1_load_values(struct mii_softc *sc, phandle_t node,
+uint32_t dev, uint32_t reg, char *field1, uint32_t f1mask, int f1off,
+char *field2, uint32_t f2mask, int f2off, char *field3, uint32_t f3mask,
+int f3off, char *field4, uint32_t f4mask, int f4off)
{
pcell_t dts_value[1];
int len;
int val;
- val = 0;
+ if (sc->mii_mpd_model == MII_MODEL_MICREL_KSZ9031)
+ val = ksz9031_read(sc, dev, reg);
+ else
+ val = ksz9021_read(sc, reg);
if ((len = OF_getproplen(node, field1)) > 0) {
OF_getencprop(node, field1, dts_value, len);
- val = PS_TO_REG(dts_value[0]);
+ val &= ~(f1mask << f1off);
+ val |= (PS_TO_REG(dts_value[0]) & f1mask) << f1off;
}
- if ((len = OF_getproplen(node, field2)) > 0) {
+ if (field2 != NULL && (len = OF_getproplen(node, field2)) > 0) {
OF_getencprop(node, field2, dts_value, len);
- val |= PS_TO_REG(dts_value[0]) << 4;
+ val &= ~(f2mask << f2off);
+ val |= (PS_TO_REG(dts_value[0]) & f2mask) << f2off;
}
- if ((len = OF_getproplen(node, field3)) > 0) {
+ if (field3 != NULL && (len = OF_getproplen(node, field3)) > 0) {
OF_getencprop(node, field3, dts_value, len);
- val |= PS_TO_REG(dts_value[0]) << 8;
+ val &= ~(f3mask << f3off);
+ val |= (PS_TO_REG(dts_value[0]) & f3mask) << f3off;
}
- if ((len = OF_getproplen(node, field4)) > 0) {
+ if (field4 != NULL && (len = OF_getproplen(node, field4)) > 0) {
OF_getencprop(node, field4,
Re: svn commit: r301453 - in head/sys: arm/arm arm64/arm64 dev/fdt dev/gpio dev/iicbus dev/ofw dev/pci dev/vnic kern mips/mips sys
On 07/23/16 03:45, Michal Meloun wrote: Dne 21.07.2016 v 17:53 Nathan Whitehorn napsal(a): On PowerPC, GENERIC64 supports FDT systems (some IBM hardware), OFW systems (Macs, some IBM hardware), systems with no device trees at all (old-style PS3), and systems with a mixture of device tree and no device tree (new-style PS3). On these, there is a mixture of "real" interrupts and GPIO-type interrupts. There is no limitation that this be used only for device-tree-type systems. The system requires two things: an interrupt domain key and an arbitrary unique byte string describing the interrupt. When running with a device tree, these are set to the phandle of the interrupt-parent and the contents of the device tree interrupt specifier, respectively, and the system was of course developed with that in mind. But they don't need to be, and often aren't. You could make the domain an element of an enum (where "ACPI" is a choice, for instance -- this is what PS3 does), or set it to a pointer to a device_t, or really anything you like. Similarly, the interrupt specifier is totally free-form. Yes, I agree. and i think that we followed the same direction. But i see two problems with this approach. - in some cases (OFW, device_t) you don't have control over domain key value, so you cannot guarantee its uniqueness. Of course, probability of collision is low, but it is. We could solve this in a number of ways, for example widening to 64 bits, or adding another value (domain type, for example). You could also make an acpi_bus_map_intr() to go with the OFW one that connect in some machine-dependent code if you have fundamentally incompatible bus enumeration mechanisms that you expect to exist simultaneously -- but, of course, no systems like this seem to actually exist, so the problem is both easily solved and totally theoretical. - within ofw_bus_map_intr() (or later - at the time when byte string must be decoded) you are not able (easily) to differentiate between different formats, thus you are not able to select appropriate decoder. The GPIO controller, for example, must be able to handle interrupts defined by standard OFW property, or by pair concurrently. In principle, you could solve that as above, or by registering a second interrupt domain for the same controller. In practice, it doesn't matter since, in the GPIO case, for example, the GPIO controller is never itself also a normal interrupt controller (i.e. the GIC and GPIO controller are always different devices). As such, the theoretical does not occur in practice. For this reason we makes domain key composite, in our model, the domain key consist of "domain key type" and "domain key value". This composite key guarantees uniqueness and it also allows to select proper parser for byte string. Yes, but this solves what is a nonexistant problem by making the system substantially less flexible and more invasive. Which is not a good tradeoff. This is, imho, only one difference between us. One of many, yes. You could, for instance, set it to one of the structures introduced in r301453 if you wanted to. I would have zero problems with changing the prototype of the existing dev/ofw function to something more generic in name, like: bus_map_intr(device_t dev, uintptr_t iparent, size_t intrlen, void *intr) instead of the existing equivalent: ofw_bus_map_intr(device_t dev, phandle_t iparent, int icells, pcell_t *intr) Our bus_map_intr() method is not indeed as replacement of ofw_bus_map_intr(). Its evolution of "how we can store more complex data to resource list (from bus enumerator) and transfer it to bus_allocate_resource() and/or to bus_setup_intr()" in driver independent way. We found no reasonable way to do it, so we postponed reading of properties to bus_allocate_resource() time. Right, but that is (a) a solved problem with ofw_bus_map_intr() and (b) this code doesn't solve it as completely. What does it let you do that the existing code does not? There has not been a single concrete example of something anyone wants to do on actual hardware so far in this discussion. But now jhb@ gives us alternative and I must say that this looks like a clean and elegant way how to make this (assuming that we can expand resource_list_entry by pointer to alloc_resource_args) Except that jhb@'s suggestion doesn't actually work for interrupts for the reasons I and others have pointed out. We could make such a system, but it would be a different one. By this, one byte string in OFW encoding can describe one IRQ and exactly same string in UEFI encoding can describe different IRQ. Or, in reverse, OFW and UEFI can describe same (and compatible) IRQ by two different strings. This is exact reason, why we discards virtual IRQ idea and I think that this fact is root issue of this clash. Probably it doesn't make sense to talk about others, unless we can find consensus on this. You ha
Re: svn commit: r301453 - in head/sys: arm/arm arm64/arm64 dev/fdt dev/gpio dev/iicbus dev/ofw dev/pci dev/vnic kern mips/mips sys
On 07/23/16 04:04, Michal Meloun wrote:
Dne 21.07.2016 v 23:35 John Baldwin napsal(a):
On Thursday, July 21, 2016 01:37:42 PM Andrew Turner wrote:
On Wed, 20 Jul 2016 13:28:53 +0200
Michal Meloun wrote:
Dne 19.07.2016 v 17:06 Nathan Whitehorn napsal(a):
2. It partially duplicates the functionality of OFW_BUS_MAP_INTR(),
but is both problematically more general and less flexible (it has
requirements on timing of PIC attachment vs. driver resource
allocation)
OFW_BUS_MAP_INTR() can parse only OFW based data and expect that
parsed data are magicaly stored within the call.
The new method, bus_map_intr(), can parse data from multiple sources
(OFW, UEFI / ACPI, synthetic[gpio device + pin number]). It also
returns parsed data back to caller.
And no, it doesn't add any additional timing requirements .
I've been looking at ACPI on arm64. So far I have not found the need
for this with ACPI as we don't need to send the data to the interrupt
controller driver to be parsed in the way OFW/FDT needs to.
ACPI though has a gross hack where we call BUS_CONFIG_INTR on the IRQ
in bus_alloc_resource(). What I had advocated in the discussions
leading up to this was to have some sort of opaque structure containing
a set of properties (the sort of thing bus_map_resource and make_dev_s
use) that was passed up at bus_setup_intr() time. I think it should now
be passed up at bus_alloc_resource() time instead, but it would allow bus
drivers to "decorate" a SYS_RES_IRQ request as it goes up the device tree
with properties that the interrupt controller can then associate with
the IRQ cookie it allocates in its own code. I would let the particular
structure have different layouts for different resource types. On x86 we
would replace bus_config_intr by passing the level and trigger-mode in
this structure. However, I could also see allowing the memattr to be
set for a SYS_RES_MEMORY resource so you could have a much shorter way
than an explicit bus_map_resource to map an entire BAR as WC for example:
struct alloc_resource_args {
size_t len;
union {
struct {
enum intr_trigger trigger;
enum intr_polarity polarity;
} irq;
struct {
vm_memattr_t memattr;
} memory;
}
}
...
union alloc_resource_args args;
init_alloc_resource_args(&args, sizeof(args));
args.memattr = VM_MEMATTR_WRITE_COMBINING;
/* Uses WC for the implicit mapping. */
res = bus_alloc_resource(, &args);
...
foobus_alloc_resource(..., union alloc_resource_args *args)
{
union alloc_resource_args args2;
switch (type) {
case SYS_RES_IRQ:
if (args == NULL) {
init_alloc_resource_args(&args2, sizeof(args2));
args = &args2;
}
/* Replace call to BUS_CONFIG_INTR on ACPI: */
if (args->irq.polarity == INTR_POLARITY_CONFORMING &&
device_has_polarity_from_CRS)
args->irq.polarity = polarity_from_CRS;
...
}
However, you could associate arbitrary data with a resource request by
adding more members to the approriate struct in the union.
I like this idea. Mainly if we can add 'struct alloc_resource_args' into
'struct resource_list_entry' and, eventually, also into struct resource_i.
Inability to pass something more complex as single integer between bus
enumerator (aka resource_list_entry creator) and bus_alloc_resource()
(aka resource_list_entry consumer) is serious limitation. At lest for me :)
Michal
Unfortunately, it doesn't actually work for resources that don't follow
the bus hierarchy, however (see earlier follow-up emails to jhb from
myself and others).
-Nathan
___
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"
svn commit: r303243 - head/sys/vm
Author: markj Date: Sat Jul 23 21:02:36 2016 New Revision: 303243 URL: https://svnweb.freebsd.org/changeset/base/303243 Log: Update a comment in vm_page_advise() to match behaviour after r290529. Reviewed by: alc MFC after:3 days Modified: head/sys/vm/vm_page.c Modified: head/sys/vm/vm_page.c == --- head/sys/vm/vm_page.c Sat Jul 23 20:50:47 2016(r303242) +++ head/sys/vm/vm_page.c Sat Jul 23 21:02:36 2016(r303243) @@ -3411,9 +3411,11 @@ vm_page_advise(vm_page_t m, int advice) vm_page_dirty(m); /* -* Place clean pages at the head of the inactive queue rather than the -* tail, thus defeating the queue's LRU operation and ensuring that the -* page will be reused quickly. +* Place clean pages near the head of the inactive queue rather than +* the tail, thus defeating the queue's LRU operation and ensuring that +* the page will be reused quickly. Dirty pages are given a chance to +* cycle once through the inactive queue before becoming eligible for +* laundering. */ _vm_page_deactivate(m, m->dirty == 0); } ___ 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"
svn commit: r303244 - head/sys/vm
Author: markj Date: Sat Jul 23 21:03:25 2016 New Revision: 303244 URL: https://svnweb.freebsd.org/changeset/base/303244 Log: Correct a comment - each page queue has its own lock. Reviewed by: alc MFC after:3 days Modified: head/sys/vm/vm_pageout.c Modified: head/sys/vm/vm_pageout.c == --- head/sys/vm/vm_pageout.cSat Jul 23 21:02:36 2016(r303243) +++ head/sys/vm/vm_pageout.cSat Jul 23 21:03:25 2016(r303244) @@ -267,7 +267,7 @@ vm_pageout_init_marker(vm_page_t marker, * * Lock vm object currently associated with `m'. VM_OBJECT_TRYWLOCK is * known to have failed and page queue must be either PQ_ACTIVE or - * PQ_INACTIVE. To avoid lock order violation, unlock the page queues + * PQ_INACTIVE. To avoid lock order violation, unlock the page queue * while locking the vm object. Use marker page to detect page queue * changes and maintain notion of next page on page queue. Return * TRUE if no changes were detected, FALSE otherwise. vm object is ___ 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: r303225 - head/sys/dev/fb
On Sat, 23 Jul 2016, John Baldwin wrote:
Log:
Use MTX_SYSINIT for the VESA lock.
I wouldn't trust this either.
vesa_init_done isn't a reliable guard for the mutex init. If
vesa_configure() doesn't find valid VESA info it will not set
vesa_init_done, but the lock will remain initialized. Revert r303076
and use MTX_SYSINIT to deterministically init the lock.
I'm fixing consoles and needed very delicate modifications for the
sio_inited guard that you added in sio. That basically works, but
it needs complicated atomic locking. Early initialization is better,
but MTX_SYSINIT()'s obfuscated order is wrong for console drivers:
X enum sysinit_sub_id {
X SI_SUB_DUMMY= 0x000,/* not executed; for linker*/
X SI_SUB_DONE = 0x001,/* processed*/
X SI_SUB_TUNABLES = 0x070,/* establish tunable values */
X SI_SUB_COPYRIGHT= 0x081,/* first use of console*/
X SI_SUB_VM = 0x100,/* virtual memory system init*/
X ...
X SI_SUB_WITNESS = 0x1A8,/* witness initialization */
X SI_SUB_MTX_POOL_DYNAMIC = 0x1AC,/* dynamic mutex pool */
X SI_SUB_LOCK = 0x1B0,/* various locks */
MTX_SYSINIT() is in SI_SUB_LOCK, but console drivers want mutexes in
(actually before) SI_SUB_COPYRIGHT, to avoid special cases.
There are many other ordering bugs near here. The copyright never was
the first use use of the console, at least on x86. kdb was. The
careful ordering to get consoles initialized as early as practical so
that kdb could be used is very broken now. In my i386 configuration,
crashes or hangs for vm86 being used uninitialized just before kdb can
be run to debug it. printf()s to consoles in getmemsize() are also
broken. printf()s to the message buffer always were broken until after
getmemsize(). amd64 doesn't use vm86 so it doesn't crash. The order
in init386() is not as obfuscated as the above.
syscons initializes its main lock (video_mtx) using mtx_init() before
SI_SUB_COPYRIGHT, and that seems to work right. It guards this with
'cold' but that is bogus so I removed it. 'cold' is true until much
later and is not needed early.
Uninitialization is more broken for consoles than initialization, but is
less of a problem since it is usually unreachable. It is only obviously
reachable for dcons, and is obviously wrong there (cnremove() doesn't
actually remove the console, but dcons tries it; no other driver even
tries it).
The SCHEDULER_STOPPED() hack caused me problems. My fixed console
drivers know a little more about when it is safe to call mutex code
than the mutex system does, except they don't want to know about
this hack. They do a check like mtx_unowned() (but more fragile).
mtx_unowned() also doesn't know about SCHEDULER_STOPPED(). mtx_unowned()
works accidentally in more cases without INVARIANTS because the inlined
mutex functions also don't know about SCHEDULER_STOPPED(). Usually they
work normally. But when they would normally block, they call the public
functions that don't block and do leave the mutex in an inconsistent
state. Then without INVARIANTS, mtx_owned() in KASSERT() is annulled
but direct mtx_owned() finds inconsistencies.
Bruce
___
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: r303209 - head/sys/powerpc/booke
On Jul 22, 2016, at 10:28 PM, Bruce Evans wrote: On Sat, 23 Jul 2016, Justin Hibbits wrote: Log: Use label math instead of hard-coding offsets for return addresses. Though the chances of the code in these sections changing are low, future-proof the sections and use label math. Not with numeric labels. I'm not future proofing it against label changes, I'm future proofing it against instruction additions/subtractions. Renumber the surrounding areas to avoid duplicate label numbers. New numeric labels tend to move the addresses of old labels. Renumbering to give unique numeric labels more than defeats their reason for existence -- you have to manage them on every change to a label anywhere in the file (and perhaps in macros and included files). You never get a error for a duplicated numeric label. Non-unique numeric labels are also a good obfuscation. Given a branch to 1f or 1b, grepping the file for 1: may find many labels 1:. You have to examine all the labels named 1: or search only near the jump to see where 1 is. Its name is supposed to not matter, but perhaps it does. I debated renumbering, and in my first iteration I didn't, but decided to for final commit, just for pure aesthetic purposes. In the future, I expect a lot of 0: labels for number labels, but as you mention below, named labels should be used for most labels anyway. Numeric labels should only be used in macros, and then only when the macro processor is too feeble to support generating unique non-numeric labels. Standard cpp is too feeble for this. I managed to remove all numeric labels in i386/exception.s (except in macros and included files), and none came back. amd64/exception.S has 19 of them, 7 with the additional style bug of being on a line with a statement or comment. Bruce - Justin ___ 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"
svn commit: r303253 - head/sys/arm/ti
Author: loos Date: Sun Jul 24 01:31:41 2016 New Revision: 303253 URL: https://svnweb.freebsd.org/changeset/base/303253 Log: Allow the use of micphy on am335x devices. The Micrel PHYs reads the optional external delays from DTB. Tested and used by uBMC and uFW. Sponsored by: Rubicon Communications (Netgate) Modified: head/sys/arm/ti/files.ti Modified: head/sys/arm/ti/files.ti == --- head/sys/arm/ti/files.tiSat Jul 23 22:50:59 2016(r303252) +++ head/sys/arm/ti/files.tiSun Jul 24 01:31:41 2016(r303253) @@ -20,6 +20,7 @@ arm/ti/ti_i2c.c optionalti_i2c arm/ti/ti_sdhci.c optionalsdhci arm/ti/ti_spi.coptionalti_spi +dev/mii/micphy.c optionalmicphy dev/uart/uart_dev_ti8250.c optionaluart dev/uart/uart_dev_ns8250.c optionaluart ___ 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: r303019 - head/sys/geom
On Tuesday, July 19, 2016 05:36:21 AM Andrey V. Elsukov wrote:
> Author: ae
> Date: Tue Jul 19 05:36:21 2016
> New Revision: 303019
> URL: https://svnweb.freebsd.org/changeset/base/303019
>
> Log:
> Use g_resize_provider() to change the size of GEOM_DISK provider,
> when it is being opened. This should fix the possible loss of a resize
> event when disk capacity changed.
Are you sure about this? We have machines in the freebsd.org cluster that now
panic on boot:
Trying to mount root from zfs:zroot []...
GEOM_PART: da0 was automatically resized.
Use `gpart commit da0` to save changes or `gpart undo da0` to revert them.
GEOM_PART: integrity check failed (da0, GPT)
Fatal trap 12: page fault while in kernel mode
cpuid = 1; apic id = 01
fault virtual address = 0x48
fault code = supervisor read data, page not present
instruction pointer = 0x20:0x80740005
stack pointer = 0x28:0xfe01f119db10
frame pointer = 0x28:0xfe01f119db30
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 13 (g_event)
[ thread pid 13 tid 100019 ]
Stopped at g_part_resize+0x35: testb $0x8,0x48(%rbx)
db> where
Tracing pid 13 tid 100019 td 0xf8000426fa00
g_part_resize() at g_part_resize+0x35/frame 0xfe01f119db30
g_resize_provider_event() at g_resize_provider_event+0xb5/frame 0xfe01f119d0
g_run_events() at g_run_events+0x20e/frame 0xfe01f119dbb0
..
It is exploding here:
g_part_resize(struct g_consumer *cp)
{
struct g_part_table *table;
G_PART_TRACE((G_T_TOPOLOGY, "%s(%s)", __func__, cp->provider->name));
g_topology_assert();
table = cp->geom->softc;
if (table->gpt_opened == 0) {
^ (table is null)
Are you creating events too soon now?
At the very least, please reconsider having this MFC'ed without getting to the
bottom of it.
--
Peter Wemm - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com; KI6FJV
UTF-8: for when a ' or ... just won\342\200\231t do\342\200\246
signature.asc
Description: This is a digitally signed message part.
Re: svn commit: r303019 - head/sys/geom
On Saturday, July 23, 2016 09:39:00 PM Peter Wemm wrote:
> On Tuesday, July 19, 2016 05:36:21 AM Andrey V. Elsukov wrote:
> > Author: ae
> > Date: Tue Jul 19 05:36:21 2016
> > New Revision: 303019
> > URL: https://svnweb.freebsd.org/changeset/base/303019
> >
> > Log:
> > Use g_resize_provider() to change the size of GEOM_DISK provider,
> > when it is being opened. This should fix the possible loss of a resize
> > event when disk capacity changed.
>
> Are you sure about this? We have machines in the freebsd.org cluster that
> now panic on boot:
>
> Trying to mount root from zfs:zroot []...
> GEOM_PART: da0 was automatically resized.
> Use `gpart commit da0` to save changes or `gpart undo da0` to revert them.
> GEOM_PART: integrity check failed (da0, GPT)
>
> Fatal trap 12: page fault while in kernel mode
> cpuid = 1; apic id = 01
> fault virtual address = 0x48
> fault code= supervisor read data, page not present
> instruction pointer = 0x20:0x80740005
> stack pointer = 0x28:0xfe01f119db10
> frame pointer = 0x28:0xfe01f119db30
> code segment = base 0x0, limit 0xf, type 0x1b
> = DPL 0, pres 1, long 1, def32 0, gran 1
> processor eflags = interrupt enabled, resume, IOPL = 0
> current process = 13 (g_event)
> [ thread pid 13 tid 100019 ]
> Stopped at g_part_resize+0x35: testb $0x8,0x48(%rbx)
>
>
>
> db> where
> Tracing pid 13 tid 100019 td 0xf8000426fa00
> g_part_resize() at g_part_resize+0x35/frame 0xfe01f119db30
> g_resize_provider_event() at g_resize_provider_event+0xb5/frame
> 0xfe01f119d0 g_run_events() at g_run_events+0x20e/frame
> 0xfe01f119dbb0
> ..
>
> It is exploding here:
> g_part_resize(struct g_consumer *cp)
> {
> struct g_part_table *table;
>
> G_PART_TRACE((G_T_TOPOLOGY, "%s(%s)", __func__,
> cp->provider->name)); g_topology_assert();
>
> table = cp->geom->softc;
> if (table->gpt_opened == 0) {
> ^ (table is null)
>
> Are you creating events too soon now?
Sometimes da0 fails, other times da1 fails.. and sometimes it is completely
fine. There is some sort of race going on with this change during the very
first moments of bootup.
--
Peter Wemm - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com; KI6FJV
UTF-8: for when a ' or ... just won\342\200\231t do\342\200\246
signature.asc
Description: This is a digitally signed message part.
