Re: check KTRPOINT() before calling ktrpledge()
On Mon, Jun 20, 2016 at 11:34 PM, Michal Mazurek wrote: > Don't ktrace pledge if it is not enabled. Committed...through the real reason to do this is that KTRPOINT() is what guarantees that writing of ktrace records can't loop back into ktrace. Philip Guenther
Re: cat.1 forward refs
Jason McIntyre wrote: > therefore the pattern is currently to say it explicitly. we could > do both, but that adds verbosity. it's a trade off, no? i wouldn;t > be against documenting both bits of information, but i'm not sure > it's really worth it. > > i think it'd be wrong to lose the info about options implying other > options though. and i note where you now effectively do both (-e and -t) > you are at least as verbose as before, if not more. and "as according > to" is much less clear than "implies". Thanks, I attempted to keep a mix of old and new.
Re: acpiec: handle burst mode failure
On Sat, Jul 9, 2016 at 6:08 AM, joshua stein wrote: > On Fri, 08 Jul 2016 at 22:34:34 -0700, Philip Guenther wrote: >> On Fri, Jul 8, 2016 at 4:51 PM, joshua stein wrote: >> > If the EC fails to go into burst mode for whatever reason, the Burst >> > Acknowledge byte will not be there to read, which means the status >> > won't have EC_STAT_OBF, which means acpiec_wait will spin forever, >> > hanging the machine. >> > >> > This at least gets us moving again, ignoring the failure to enter >> > burst mode. >> >> Is it truly failing to enter burst mode, or are we just not doing the >> dance to enter correctly? Looks like we should be waiting for an SCI >> and checking for a burst acknowledge byte? > > All subsequent status fetches show that burst is not on. No newer bios for this thing? :-( ... >> So if it doesn't immediately set either the burst or OBF flag then >> we'll continue on without reading the data? That's going to break >> systems where EC isn't always fast to respond, no? > > That's why the diff also includes the change to acpiec_write_cmd to > wait until IBF is 0, so it won't get to that new status check until > the controller has processed the EC_CMD_BE fully. I don't think the spec guarantees that implication, though it may be true in practice. Wonder what Windows and Linux do on this thing. Anyway, this diff would need to be tested broadly on *unaffected* hardware to gain confidence it doesn't hurt some box that doesn't have this brokeness. Philip Guenther
Re: smu-pulsar node delays G5 boot
On Sat, Jul 09, 2016 at 10:24:59PM +0200, Mark Kettenis wrote: > > Date: Sat, 9 Jul 2016 22:07:16 +0200 > > From: Marcus Glocker > > > > On every boot on my G5 the 'smu-pulsar' node hangs for around 66 seconds > > in autoconfs config_search() it seems before the boot process continues: > > > > "smu-pulsar" at iic2 addr 0x6a not configured > > > > I don't know why. > > > > Anyone else seeing this with a 'smu-pulsar' node in his FDT? > > Anything speaking against it to skip it from autoconf for now, similar > > as we already do for 'deq' and 'tas3004'? > > That makes no sense. The delay is in no way related to this > "smu-pulsar" device. As the "not configured" message indicates, we > don't have a driver for this device. All your diff does is eliminate > that message. The delay will still be there. With this diff the delay is gone. But as said, I don't understand yet where it exactly happens. > In all likelyhood, the delay will be caused by the device that comes next. > > > > Index: maci2c.c > > === > > RCS file: /cvs/src/sys/arch/macppc/dev/maci2c.c,v > > retrieving revision 1.11 > > diff -u -p -u -p -r1.11 maci2c.c > > --- maci2c.c23 May 2016 15:23:20 - 1.11 > > +++ maci2c.c9 Jul 2016 19:55:04 - > > @@ -59,6 +59,9 @@ maciic_scan(struct device *self, struct > >the i2s port. For now hide them. */ > > if (strcmp(name, "deq") == 0 || strcmp(name, "tas3004") == 0) > > continue; > > + /* Skip the smu-pulsar node which delays the boot process. */ > > + if (strcmp(name, "smu-pulsar") == 0) > > + continue; > > if (ia.ia_name) > > config_found(self, &ia, iic_print); > > } > > > >
Re: calendar(1) handling of Weekday+5 and 31st events
Andy Bradford wrote: > And here is the patch: > > Index: calendar/day.c > === > RCS file: /home/cvs/src/usr.bin/calendar/day.c,v > retrieving revision 1.32 > diff -u -p -r1.32 day.c > --- calendar/day.c8 Dec 2015 19:04:50 - 1.32 > +++ calendar/day.c9 Jul 2016 20:53:13 - > @@ -543,8 +543,9 @@ isnow(char *endp, int bodun) > tdiff = difftime(ttmp, f_time)/ SECSPERDAY; > if (tdiff <= offset + f_dayAfter || > (bodun && tdiff == -1)) { > - if (tdiff >= 0 || > - (bodun && tdiff == -1)) { > + if ((tmtmp.tm_mon == month) && > + (tdiff >= 0 || > + (bodun && tdiff == -1))) { > if ((tmp = malloc(sizeof(struct > match))) == NULL) > err(1, NULL); > tmp->when = ttmp; > > This works because when variable_weekday returns it places a value in v1 > that is larger than a month's worth of days. For example, for July 1, > 2016, Sunday+5 gets a value of 33 in tmtmp.tm_mday for which mktime > advances advances the month to account for the extra days when creating > the timestamp. Now the months are different and should probably not > count as a match. That makes sense. I guess the failure to check month was an oversight, not expecting it could change.
calendar(1) handling of Weekday+5 and 31st events
Hello, The following patch seems to allow calendar to better handle the fifth weekday and 31st events. Currently, both events match also at the beginning of certain months which doesn't seem to make sense. For example, March 02 is considered a 31st this year and July 03 is considered a Fifth Sunday: $ sh /tmp/calendar.sh calendar -f /tmp/calendar.We1Ga8 -t 20160101 Jan 03* Fifth Sunday. calendar -f /tmp/calendar.We1Ga8 -t 20160130 Jan 31* Fifth Sunday. Jan 31* 31st. calendar -f /tmp/calendar.We1Ga8 -t 20160301 Mar 02* 31st. calendar -f /tmp/calendar.We1Ga8 -t 20160701 Jul 01* 31st. Jul 03* Fifth Sunday. calendar -f /tmp/calendar.We1Ga8 -t 20160729 Jul 31* Fifth Sunday. Jul 31* 31st. Here is how it behaves with the patch: $ sh /tmp/calendar.sh /usr/src/usr.bin/calendar/obj/calendar /usr/src/usr.bin/calendar/obj/calendar -f /tmp/calendar.83O1qH -t 20160101 /usr/src/usr.bin/calendar/obj/calendar -f /tmp/calendar.83O1qH -t 20160130 Jan 31* Fifth Sunday. Jan 31* 31st. /usr/src/usr.bin/calendar/obj/calendar -f /tmp/calendar.83O1qH -t 20160301 /usr/src/usr.bin/calendar/obj/calendar -f /tmp/calendar.83O1qH -t 20160701 /usr/src/usr.bin/calendar/obj/calendar -f /tmp/calendar.83O1qH -t 20160729 Jul 31* Fifth Sunday. Jul 31* 31st. Here is calendar.sh: $ cat /tmp/calendar.sh PROG=${1:-calendar} CALENDAR=$(mktemp -t calendar.XX) printf ' Sunday+5\tFifth Sunday. 31 *\t31st. ' >"$CALENDAR" for date in 20160101 20160130 20160301 20160701 20160729 do set -- "$PROG" -f "$CALENDAR" -t "$date" echo "$@" eval "$@" done rm "$CALENDAR" And here is the patch: Index: calendar/day.c === RCS file: /home/cvs/src/usr.bin/calendar/day.c,v retrieving revision 1.32 diff -u -p -r1.32 day.c --- calendar/day.c 8 Dec 2015 19:04:50 - 1.32 +++ calendar/day.c 9 Jul 2016 20:53:13 - @@ -543,8 +543,9 @@ isnow(char *endp, int bodun) tdiff = difftime(ttmp, f_time)/ SECSPERDAY; if (tdiff <= offset + f_dayAfter || (bodun && tdiff == -1)) { - if (tdiff >= 0 || - (bodun && tdiff == -1)) { + if ((tmtmp.tm_mon == month) && + (tdiff >= 0 || + (bodun && tdiff == -1))) { if ((tmp = malloc(sizeof(struct match))) == NULL) err(1, NULL); tmp->when = ttmp; This works because when variable_weekday returns it places a value in v1 that is larger than a month's worth of days. For example, for July 1, 2016, Sunday+5 gets a value of 33 in tmtmp.tm_mday for which mktime advances advances the month to account for the extra days when creating the timestamp. Now the months are different and should probably not count as a match. Are there any bad side-effects in this approach? Thanks, Andy -- TAI64 timestamp: 40005781686f
Re: smu-pulsar node delays G5 boot
> Date: Sat, 9 Jul 2016 22:07:16 +0200 > From: Marcus Glocker > > On every boot on my G5 the 'smu-pulsar' node hangs for around 66 seconds > in autoconfs config_search() it seems before the boot process continues: > > "smu-pulsar" at iic2 addr 0x6a not configured > > I don't know why. > > Anyone else seeing this with a 'smu-pulsar' node in his FDT? > Anything speaking against it to skip it from autoconf for now, similar > as we already do for 'deq' and 'tas3004'? That makes no sense. The delay is in no way related to this "smu-pulsar" device. As the "not configured" message indicates, we don't have a driver for this device. All your diff does is eliminate that message. The delay will still be there. In all likelyhood, the delay will be caused by the device that comes next. > Index: maci2c.c > === > RCS file: /cvs/src/sys/arch/macppc/dev/maci2c.c,v > retrieving revision 1.11 > diff -u -p -u -p -r1.11 maci2c.c > --- maci2c.c 23 May 2016 15:23:20 - 1.11 > +++ maci2c.c 9 Jul 2016 19:55:04 - > @@ -59,6 +59,9 @@ maciic_scan(struct device *self, struct > the i2s port. For now hide them. */ > if (strcmp(name, "deq") == 0 || strcmp(name, "tas3004") == 0) > continue; > + /* Skip the smu-pulsar node which delays the boot process. */ > + if (strcmp(name, "smu-pulsar") == 0) > + continue; > if (ia.ia_name) > config_found(self, &ia, iic_print); > } > >
smu-pulsar node delays G5 boot
On every boot on my G5 the 'smu-pulsar' node hangs for around 66 seconds in autoconfs config_search() it seems before the boot process continues: "smu-pulsar" at iic2 addr 0x6a not configured I don't know why. Anyone else seeing this with a 'smu-pulsar' node in his FDT? Anything speaking against it to skip it from autoconf for now, similar as we already do for 'deq' and 'tas3004'? Index: maci2c.c === RCS file: /cvs/src/sys/arch/macppc/dev/maci2c.c,v retrieving revision 1.11 diff -u -p -u -p -r1.11 maci2c.c --- maci2c.c23 May 2016 15:23:20 - 1.11 +++ maci2c.c9 Jul 2016 19:55:04 - @@ -59,6 +59,9 @@ maciic_scan(struct device *self, struct the i2s port. For now hide them. */ if (strcmp(name, "deq") == 0 || strcmp(name, "tas3004") == 0) continue; + /* Skip the smu-pulsar node which delays the boot process. */ + if (strcmp(name, "smu-pulsar") == 0) + continue; if (ia.ia_name) config_found(self, &ia, iic_print); }
Re: [armv7] introducing tipru(4)
I am pretty unhappy about drivers like this arriving in the tree. I just don't see any trustworthy way to use them, and lacking trust -- I don't understand the worth. Givings hugs to trustworthy designs is an OpenBSD agenda. Giving scowls to untrustworthy designs is another OpenBSD agenda. Uplifting ones that are semi-trustworthy to become more trustworthy... well you get the idea. So this can run some semi-proprietary code that is uploaded and runs entirely unsafely. Why bother. How many people will use this, in OpenBSD? Besides you, I anticipate noone. The right way to use a device is through deep careful integration of the featureset it has, into natural functionality that can be exposed as a sane driver interface in /dev/, or hidden even further so that it does something which makes the kernel faster. Exposing anything like this raw, is not the unix way. I wonder what we'll see next, along this line. Maybe a way to load AML code from userland on an amd64, be interpreted by the AML interpreter to control fan speeds by twiddling bits in ACPI register spaces? Or a way to load DRM code directly? I think we can all agree those type of things are a much lesser form of "progress". Abstraction is a powerful uplift, raw is raw.
Re: route6d summer cleanup
j...@wxcvbn.org (Jeremie Courreges-Anglas) writes: > j...@wxcvbn.org (Jeremie Courreges-Anglas) writes: > >> j...@wxcvbn.org (Jeremie Courreges-Anglas) writes: >> >>> Nobody cares about route6d, and it shows: runas as root, not chrooted. >>> Also it uses wide pledge(2) permissions. >>> >>> I have diffs to switch the logging to log.c and use it to support the -R >>> option and /var/run/route6d_dump. The end goal is to use a tighter >>> pledge(2) call: >>> + if (pledge("stdio inet route mcast", NULL) == -1) > > So here's the diff. > > log.c and log.h come from rtadvd. I have added a simple log queue > mechanism so that the changes in route6d.c are minimal, and so that we > stop sending crap (newlines) to syslog. Due to log_enqueue() the > conversion is mostly mechanical. I did not add checks for cases where > log_warn / fatal are called right after log_enqueue. > > This also introduces a -u option for people that may have previously > used -R. route updates can be inconditionally logged and contain > a distinctive marker. > > Tests / feedback / oks welcome. Dunno how but I failed to remove the closelog(3) call. It would be nice to get this in for 6.0, but this won't happen without proper tests. The only actual user I know is on holidays, so I'll have to find some time for tests next week. Meanwhile, reviews are still welcome. Index: Makefile === RCS file: /cvs/src/usr.sbin/route6d/Makefile,v retrieving revision 1.8 diff -u -p -r1.8 Makefile --- Makefile25 Oct 2015 22:38:48 - 1.8 +++ Makefile9 Jul 2016 18:32:02 - @@ -3,4 +3,6 @@ PROG= route6d MAN= route6d.8 +SRCS= route6d.c log.c + .include Index: log.c === RCS file: log.c diff -N log.c --- /dev/null 1 Jan 1970 00:00:00 - +++ log.c 9 Jul 2016 18:32:02 - @@ -0,0 +1,184 @@ +/* + * Copyright (c) 2003, 2004 Henning Brauer + * + * Permission to use, copy, modify, and distribute this software for any + * purpose with or without fee is hereby granted, provided that the above + * copyright notice and this permission notice appear in all copies. + * + * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES + * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF + * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR + * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES + * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN + * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF + * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include "log.h" + +static int debug; + +static char*logqueue; + +#define LOGQUEUE_SIZE 1024 + +void logit(int, const char *, ...); +void vlog(int pri, const char *fmt, va_list ap); + +void +log_init(int n_debug) +{ + extern char *__progname; + + if (logqueue == NULL) { + logqueue = calloc(LOGQUEUE_SIZE, 1); + if (logqueue == NULL) + err(1, NULL); + } + + debug = n_debug; + + if (!debug) + openlog(__progname, LOG_PID | LOG_NDELAY, LOG_DAEMON); + + tzset(); +} + +void +logit(int pri, const char *fmt, ...) +{ + va_list ap; + + va_start(ap, fmt); + vlog(pri, fmt, ap); + va_end(ap); +} + +void +log_enqueue(const char *fmt, ...) +{ + char tmpbuf[LOGQUEUE_SIZE]; + va_list ap; + + va_start(ap, fmt); + (void)vsnprintf(tmpbuf, sizeof(tmpbuf), fmt, ap); + va_end(ap); + (void)strlcat(logqueue, tmpbuf, LOGQUEUE_SIZE); +} + + +void +vlog(int pri, const char *fmt, va_list ap) +{ + chartmpbuf[1024]; + charlogbuf[LOGQUEUE_SIZE + sizeof(tmpbuf)]; + + if (!debug) { + logqueue[0] = '\0'; + return; + } + + (void)vsnprintf(tmpbuf, sizeof(tmpbuf), fmt, ap); + (void)strlcpy(logbuf, logqueue, sizeof(logbuf)); + (void)strlcat(logbuf, tmpbuf, sizeof(tmpbuf)); + + logqueue[0] = '\0'; + + if (debug) { + fprintf(stderr, "%s\n", logbuf); + fflush(stderr); + } else + syslog(pri, "%s", logbuf); +} + +void +log_warn(const char *emsg, ...) +{ + char*nfmt; + va_list ap; + + if (emsg == NULL) + logit(LOG_CRIT, "%s", strerror(errno)); + else { + va_start(ap, emsg); + + /* best effort to even work in out of memory situations */ + if (asprintf(&nfmt, "%s: %s", emsg, strerror(errno)) == -1) { + /* we tried it... */ + vlog(LOG_CRIT, emsg, ap); + logit(LOG_CRIT, "%s", strerror(errno)); +
Re: Better for mount(2)
On Sat, Jul 09, 2016 at 06:20:49PM +0300, Vadim Zhukov wrote: > Hello all. > evening. > As found by some of my students, mount(2) lacks description of some > flags used by userland. After trying to sync things out, I realized > that this page is not well organized at all. For example, unmount > syscall is mentioned closer to end, after description of flags that > it could use. > > I didn't document all of the flags involved in mount calls, since > some of them are purely kernel internal. But I could easily miss > something crucial... > > So this is my first public draft of mount(2) patch. Looking for > comments & thanks in advance! > > -- > WBR, > Vadim Zhukov > comments inline. > > Index: mount.2 > === > RCS file: /cvs/src/lib/libc/sys/mount.2,v > retrieving revision 1.46 > diff -u -p -r1.46 mount.2 > --- mount.2 27 May 2016 19:45:04 - 1.46 > +++ mount.2 9 Jul 2016 15:16:29 - > @@ -70,31 +70,57 @@ at the time > of a successful mount are swept under the carpet, so to speak, and > are unavailable until the filesystem is unmounted. > .Pp > +The > +.Fn unmount > +function call disassociates the filesystem from the specified > +mount point > +.Fa dir . > +.Pp i agree this is an improvement. > The following > .Fa flags > may be specified to > suppress default semantics which affect filesystem access. note the sentence above. it makes adding some of these options tricky since it will essentially contradict what is written there. so, assuming there is a reason to document these other flags (that is, no reason not to), you will have to change that sentence. > .Bl -tag -width MNT_SYNCHRONOUS > -.It Dv MNT_RDONLY > -The filesystem should be treated as read-only: > -even the superuser may not write to it. > +.It Dv MNT_ASYNC > +All I/O to the filesystem should be done asynchronously. ordering these alphabetically seems reasonable - i assume there's no reason for the current order? > +.It Dv MNT_FORCE > +On unmount, specifies that the filesystem should be forcibly unmounted > +even if files are still active. > +Active special devices continue to work, > +but any further accesses to any other active files result in errors s/accesses/access/ > +even if the filesystem is later remounted. > +On update, allows to forcibly change from read-write to read-only, s/allows to forcibly change/forcibly changes/ > +even if there are files open for writing. > .It Dv MNT_NOATIME > Do not update the access time on files in the filesystem unless > the modification or status change times are also being updated. > +.It Dv MNT_NODEV > +Do not interpret special files on the filesystem. > .It Dv MNT_NOEXEC > Do not allow files to be executed from the filesystem. > .It Dv MNT_NOSUID > Do not honor setuid or setgid bits on files when executing them. > -.It Dv MNT_NODEV > -Do not interpret special files on the filesystem. > -.It Dv MNT_SYNCHRONOUS > -All I/O to the filesystem should be done synchronously. > -.It Dv MNT_ASYNC > -All I/O to the filesystem should be done asynchronously. > +.It Dv MNT_RDONLY > +The filesystem should be treated as read-only: > +even the superuser may not write to it. > +.It Dv MNT_RELOAD > +Reload already mounted filesystem. i think "reload" is a bit ambiguous. what does it actually do? > +Used, e.g., by i'd change the e.g. to "for example". or at least kill the comma after the "g." > +.Xr fsck 8 . > .It Dv MNT_SOFTDEP > Use soft dependencies. > Applies to FFS filesystems only (see 'softdep' in > .Xr mount 8 ) . > +.It Dv MNT_SYNCHRONOUS > +All I/O to the filesystem should be done synchronously. > +.It Dv MNT_UPDATE > +Indicates that the mount command is being applied to an already mounted > +filesystem. > +This allows the mount flags to be changed without requiring > +that the filesystem be unmounted and remounted. > +Some filesystems may not allow all flags to be changed. > +For example, > +most filesystems will not allow a change from read-write to read-only. > .It MNT_WXALLOWED > Processes that ask for memory to be made writeable plus executable > using the > @@ -108,16 +134,6 @@ The option is typically used on the > filesystem. > .El > .Pp > -The flag > -.Dv MNT_UPDATE > -indicates that the mount command is being applied > -to an already mounted filesystem. > -This allows the mount flags to be changed without requiring > -that the filesystem be unmounted and remounted. > -Some filesystems may not allow all flags to be changed. > -For example, > -most filesystems will not allow a change from read-write to read-only. > -.Pp i'm less sure here. i think this option makes sense outwith the option list. but i guess if you change the first sentence, it might work. not convinced, though. > The > .Fa type > argument defines the type of the filesystem. > @@ -237,22 +253,6 @@ struct udf_args { > char*fspec; /* block special device to mount */ > }; > .Ed > -.Pp > -The > -.Fn
Better for mount(2)
Hello all. As found by some of my students, mount(2) lacks description of some flags used by userland. After trying to sync things out, I realized that this page is not well organized at all. For example, unmount syscall is mentioned closer to end, after description of flags that it could use. I didn't document all of the flags involved in mount calls, since some of them are purely kernel internal. But I could easily miss something crucial... So this is my first public draft of mount(2) patch. Looking for comments & thanks in advance! -- WBR, Vadim Zhukov Index: mount.2 === RCS file: /cvs/src/lib/libc/sys/mount.2,v retrieving revision 1.46 diff -u -p -r1.46 mount.2 --- mount.2 27 May 2016 19:45:04 - 1.46 +++ mount.2 9 Jul 2016 15:16:29 - @@ -70,31 +70,57 @@ at the time of a successful mount are swept under the carpet, so to speak, and are unavailable until the filesystem is unmounted. .Pp +The +.Fn unmount +function call disassociates the filesystem from the specified +mount point +.Fa dir . +.Pp The following .Fa flags may be specified to suppress default semantics which affect filesystem access. .Bl -tag -width MNT_SYNCHRONOUS -.It Dv MNT_RDONLY -The filesystem should be treated as read-only: -even the superuser may not write to it. +.It Dv MNT_ASYNC +All I/O to the filesystem should be done asynchronously. +.It Dv MNT_FORCE +On unmount, specifies that the filesystem should be forcibly unmounted +even if files are still active. +Active special devices continue to work, +but any further accesses to any other active files result in errors +even if the filesystem is later remounted. +On update, allows to forcibly change from read-write to read-only, +even if there are files open for writing. .It Dv MNT_NOATIME Do not update the access time on files in the filesystem unless the modification or status change times are also being updated. +.It Dv MNT_NODEV +Do not interpret special files on the filesystem. .It Dv MNT_NOEXEC Do not allow files to be executed from the filesystem. .It Dv MNT_NOSUID Do not honor setuid or setgid bits on files when executing them. -.It Dv MNT_NODEV -Do not interpret special files on the filesystem. -.It Dv MNT_SYNCHRONOUS -All I/O to the filesystem should be done synchronously. -.It Dv MNT_ASYNC -All I/O to the filesystem should be done asynchronously. +.It Dv MNT_RDONLY +The filesystem should be treated as read-only: +even the superuser may not write to it. +.It Dv MNT_RELOAD +Reload already mounted filesystem. +Used, e.g., by +.Xr fsck 8 . .It Dv MNT_SOFTDEP Use soft dependencies. Applies to FFS filesystems only (see 'softdep' in .Xr mount 8 ) . +.It Dv MNT_SYNCHRONOUS +All I/O to the filesystem should be done synchronously. +.It Dv MNT_UPDATE +Indicates that the mount command is being applied to an already mounted +filesystem. +This allows the mount flags to be changed without requiring +that the filesystem be unmounted and remounted. +Some filesystems may not allow all flags to be changed. +For example, +most filesystems will not allow a change from read-write to read-only. .It MNT_WXALLOWED Processes that ask for memory to be made writeable plus executable using the @@ -108,16 +134,6 @@ The option is typically used on the filesystem. .El .Pp -The flag -.Dv MNT_UPDATE -indicates that the mount command is being applied -to an already mounted filesystem. -This allows the mount flags to be changed without requiring -that the filesystem be unmounted and remounted. -Some filesystems may not allow all flags to be changed. -For example, -most filesystems will not allow a change from read-write to read-only. -.Pp The .Fa type argument defines the type of the filesystem. @@ -237,22 +253,6 @@ struct udf_args { char*fspec; /* block special device to mount */ }; .Ed -.Pp -The -.Fn unmount -function call disassociates the filesystem from the specified -mount point -.Fa dir . -.Pp -The -.Fa flags -argument may specify -.Dv MNT_FORCE -to specify that the filesystem should be forcibly unmounted even if files are -still active. -Active special devices continue to work, -but any further accesses to any other active files result in errors -even if the filesystem is later remounted. .Sh RETURN VALUES .Rv -std .Sh ERRORS
Re: acpiec: handle burst mode failure
On Fri, 08 Jul 2016 at 22:34:34 -0700, Philip Guenther wrote: > On Fri, Jul 8, 2016 at 4:51 PM, joshua stein wrote: > > If the EC fails to go into burst mode for whatever reason, the Burst > > Acknowledge byte will not be there to read, which means the status > > won't have EC_STAT_OBF, which means acpiec_wait will spin forever, > > hanging the machine. > > > > This at least gets us moving again, ignoring the failure to enter > > burst mode. > > Is it truly failing to enter burst mode, or are we just not doing the > dance to enter correctly? Looks like we should be waiting for an SCI > and checking for a burst acknowledge byte? All subsequent status fetches show that burst is not on. > ... > > @@ -196,7 +197,10 @@ void > > acpiec_burst_enable(struct acpiec_softc *sc) > > { > > acpiec_write_cmd(sc, EC_CMD_BE); > > - acpiec_read_data(sc); > > + if (acpiec_status(sc) & (EC_STAT_BURST|EC_STAT_OBF)) > > + acpiec_read_data(sc); > > + else > > + dnprintf(10, "%s: failed to enter burst mode\n", > > DEVNAME(sc)); > > } > > So if it doesn't immediately set either the burst or OBF flag then > we'll continue on without reading the data? That's going to break > systems where EC isn't always fast to respond, no? That's why the diff also includes the change to acpiec_write_cmd to wait until IBF is 0, so it won't get to that new status check until the controller has processed the EC_CMD_BE fully.
Re: [armv7] introducing tipru(4)
On Wed, Jul 6, 2016 at 5:41 AM, Damien Miller wrote: > That sounds like a reasonable compromise - it would let the admin load > code to the PRUs in rc.securelevel for later use, or set > kern.securelevel=0 in sysctl.conf if they wanted to do development > on a multi-user system. OK -- I have tested and fixed the previous design. It is now working exactly as stated in the man page from my prior mail. Below patch is now in a review-ready state. On Wed, Jul 6, 2016 at 3:27 AM, Ian Sutton wrote: > mainbus -> fdt is next. tipru(4) now attaches via flattened device tree. However, the dtb included in miniroot-am335x-60.fs is erroneously devoid of a PRU node. Here is a patch for the decompiled source file: http://ce.gl/am335x-boneblack.dts.patch And the resultant binary for convenience's sake: http://ce.gl/am335x-boneblack.dtb To replace it (on BBB, assuming root disk is sd0): # mount /dev/sd0i /mnt # curl http://ce.gl/am335x-boneblack.dtb > /mnt/am335x-boneblack.dtb # umount /mnt # reboot Ian Index: etc/etc.armv7/MAKEDEV === RCS file: /cvs/src/etc/etc.armv7/MAKEDEV,v retrieving revision 1.19 diff -u -p -r1.19 MAKEDEV --- etc/etc.armv7/MAKEDEV 21 May 2016 22:15:09 - 1.19 +++ etc/etc.armv7/MAKEDEV 9 Jul 2016 07:06:54 - @@ -4,7 +4,7 @@ # generated from: # # OpenBSD: etc.armv7/MAKEDEV.md,v 1.12 2016/05/21 21:30:22 kettenis Exp -# OpenBSD: MAKEDEV.common,v 1.88 2016/05/21 15:17:49 deraadt Exp +# OpenBSD: MAKEDEV.common,v 1.89 2016/05/26 16:29:51 deraadt Exp # OpenBSD: MAKEDEV.mi,v 1.82 2016/03/12 17:58:59 espie Exp # OpenBSD: MAKEDEV.sub,v 1.14 2005/02/07 06:14:18 david Exp # @@ -59,6 +59,7 @@ # usb*Bus control devices used by usbd for attach/detach # Special purpose devices: # apm Power management device +# tipru Programmable realtime unit # audio* Audio devices # bio ioctl tunnel pseudo-device # bktr* Video frame grabbers @@ -328,6 +329,10 @@ audio*) MKlist[${#MKlist[*]}]=";[ -e audioctl ] || ln -s audioctl$U audioctl" ;; +tipru*) + M tipru c 29 0 200 + ;; + apm*) M apm c 34 0 644 M apmctlc 34 8 644 @@ -469,14 +474,14 @@ local) ;; all) - R gpio0 gpio1 gpio2 gpio3 gpio4 gpio5 gpio6 gpio7 gpio8 vnd0 - R vnd1 vnd2 vnd3 sd0 sd1 sd2 sd3 sd4 sd5 sd6 sd7 sd8 sd9 cd0 - R cd1 rd0 tap0 tap1 tap2 tap3 tun0 tun1 tun2 tun3 bio pty0 - R diskmap vscsi0 ch0 bpf fuse pppx hotplug ptm local wscons - R pci0 pci1 pci2 pci3 uall rmidi0 rmidi1 rmidi2 rmidi3 rmidi4 - R rmidi5 rmidi6 rmidi7 tuner0 radio0 video0 video1 uk0 random - R tty00 tty01 tty02 tty03 tty04 tty05 tty06 tty07 tty08 tty09 - R tty0a tty0b apm pf wd0 wd1 wd2 wd3 std st0 st1 fd + R tipru0 gpio0 gpio1 gpio2 gpio3 gpio4 gpio5 gpio6 gpio7 + R gpio8 vnd0 vnd1 vnd2 vnd3 sd0 sd1 sd2 sd3 sd4 sd5 sd6 sd7 + R sd8 sd9 cd0 cd1 rd0 tap0 tap1 tap2 tap3 tun0 tun1 tun2 tun3 + R bio pty0 diskmap vscsi0 ch0 bpf fuse pppx hotplug ptm local + R wscons pci0 pci1 pci2 pci3 uall rmidi0 rmidi1 rmidi2 rmidi3 + R rmidi4 rmidi5 rmidi6 rmidi7 tuner0 radio0 video0 video1 uk0 + R random tty00 tty01 tty02 tty03 tty04 tty05 tty06 tty07 tty08 + R tty09 tty0a tty0b apm pf wd0 wd1 wd2 wd3 std st0 st1 fd ;; wd*|sd*) Index: etc/etc.armv7/MAKEDEV.md === RCS file: /cvs/src/etc/etc.armv7/MAKEDEV.md,v retrieving revision 1.12 diff -u -p -r1.12 MAKEDEV.md --- etc/etc.armv7/MAKEDEV.md21 May 2016 21:30:22 - 1.12 +++ etc/etc.armv7/MAKEDEV.md9 Jul 2016 07:06:54 - @@ -27,6 +27,8 @@ dnl ADVISED OF THE POSSIBILITY OF SUCH D dnl dnl __devitem(apm, apm, Power management device)dnl +__devitem(tipru, tipru, Programmable realtime unit)dnl +_mkdev(tipru, tipru*, {-M tipru c major_tipru_c 0 200-})dnl _TITLE(make) _DEV(all) _DEV(ramdisk) @@ -64,6 +66,7 @@ _DEV(ulpt, 66) _DEV(usb, 64) _TITLE(spec) _DEV(apm, 34) +_DEV(tipru, 29) _DEV(au, 36) _DEV(bio, 52) _DEV(bktr, 75) @@ -114,3 +117,4 @@ target(all, cd, 0, 1)dnl target(all, sd, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9)dnl target(all, vnd, 0, 1, 2, 3)dnl target(all, gpio, 0, 1, 2, 3, 4, 5, 6, 7, 8)dnl +target(all, tipru, 0)dnl Index: share/man/man4/man4.armv7/tipru.4 === RCS file: share/man/man4/man4.armv7/tipru.4 diff -N share/man/man4/man4.armv7/tipru.4 --- /dev/null 1 Jan 1970 00:00:00 - +++ share/man/man4/man4.armv7/tipru.4 9 Jul 2016 07:07:02 - @@ -0,0 +1,221 @@ +.\" Copyright (c) 2016 Ian Sutton +.\" +.\" Permission to use, copy, modify, and distribute this software for any +.\" purpose with or without fee is hereby granted, provided that the above +.\" copyright notice and this permission notice appear in all copies. +.\" +.\" THE SOFTWARE IS PROVIDED