Re: CVS: cvs.openbsd.org: src
On Tue, 10 Oct 2023 10:14:10 -0700, Chris Cappuccio wrote: > The Message-ID should be added to any message that doesn't have one. > An existing Message-ID should not be removed or changed. > > The RFC says it "MAY be applied when necessary by an originating SMTP server" > so the port numbers aren't a terrible idea, but it leaves open plenty > of room to not add one if someone isn't following the 465/587 scheme. But smtpd may not be the originating SMTP server. For "local" messages (that originated on the server) it knows to add the Message-ID if missing. I don't think it should be adding it to relayed messages. Messages received on the submission port are special, they need to be treated as local even though they originated elsewhere. - todd
Re: CVS: cvs.openbsd.org: src
Todd C. Miller [mill...@openbsd.org] wrote: > On Tue, 10 Oct 2023 10:50:08 +0100, Stuart Henderson wrote: > > > Presumably 465 should be treated the same, though the hardcoded ports > > don't feel entirely right here - this is presumably something that would > > want adding for any connection which is allowed to relay .. > > Yes, I think so. Hard-coding ports is not great but there isn't a > way in the config file to indicate that explicitly. > The Message-ID should be added to any message that doesn't have one. An existing Message-ID should not be removed or changed. The RFC says it "MAY be applied when necessary by an originating SMTP server" so the port numbers aren't a terrible idea, but it leaves open plenty of room to not add one if someone isn't following the 465/587 scheme. If the smtp_tx_dataline or a subset could be called when we know the message isn't being delivered locally, that would be ideal and avoid the need to lookup port numbers. Chris
Re: CVS: cvs.openbsd.org: src
On Tue, 10 Oct 2023 10:50:08 +0100, Stuart Henderson wrote: > Presumably 465 should be treated the same, though the hardcoded ports > don't feel entirely right here - this is presumably something that would > want adding for any connection which is allowed to relay .. Yes, I think so. Hard-coding ports is not great but there isn't a way in the config file to indicate that explicitly. - todd
Re: CVS: cvs.openbsd.org: src
On 2023/10/09 14:55, Todd C. Miller wrote: > CVSROOT: /cvs > Module name: src > Changes by: mill...@cvs.openbsd.org 2023/10/09 14:55:33 > > Modified files: > usr.sbin/smtpd : smtp_session.c > > Log message: > Add Message-Id as needed for messages received on the submission port. > > Since listener->port is in network byte order we need to compare > against htons(587). The fix for this got dropped in the rewrite > in revision 1.335. Presumably 465 should be treated the same, though the hardcoded ports don't feel entirely right here - this is presumably something that would want adding for any connection which is allowed to relay .. Index: smtp_session.c === RCS file: /cvs/src/usr.sbin/smtpd/smtp_session.c,v retrieving revision 1.436 diff -u -p -r1.436 smtp_session.c --- smtp_session.c 9 Oct 2023 20:55:32 - 1.436 +++ smtp_session.c 10 Oct 2023 09:41:05 - @@ -2624,6 +2624,7 @@ smtp_tx_dataline(struct smtp_tx *tx, con case RFC5322_END_OF_HEADERS: if (tx->session->listener->local || + tx->session->listener->port == htons(465) || tx->session->listener->port == htons(587)) { if (!tx->has_date) {
Re: CVS: cvs.openbsd.org: src
This change fixes another wart in unveil/pledge which wasn't resolved in the original design. pledge allows bypass-reading of /usr/share/zoneinfo/ files for TZ=zone but absolute path support remained a wart. Once again, we have to remove a rarely used behavior of libc. During pledge and unveil propagation in programs, and even earlier with privsep development (meaning use of chroot), we added many early calls to tzset() in programs. Some programs stopped using chroot, and rely upon pledge and unveil instead. Many of those tzset() calls could potentially be removed because other libc functions can initialize late due to the zoneinfo directory bypass. When doing so, please remmber -portable versions will still need to perform the initialization calls early, and also the chroot case still needs early initialization also. Todd C. Miller wrote: > CVSROOT: /cvs > Module name: src > Changes by: mill...@cvs.openbsd.org 2022/09/21 09:57:49 > > Modified files: > lib/libc/time : localtime.c tzset.3 > > Log message: > tzset: ignore TZ if it contains an absolute path or issetugid(). > Reading time zone files from user-controlled paths can result in > pledge(2) or unveil(2) violations. We also ignore files that contain > a '.' character to avoid paths containing ".." or hidden files. > Work with and OK deraadt@ >
Re: [EXTERNAL] Re: CVS: cvs.openbsd.org: src
Once initially defined engineid should be static, a lot of SNMP polling applications use engineid as device identifier. Consistency and uniqueness are both important. Some polling system will not allow you to add another snmp device If engineid is a duplicate. Network devices usually derive engineid from lowest "numbered" interface. Unfortunately you can manually set them, this is bad when someone creates a configuration base template which has engineid defined, then you end up with 100's of network devices with the same engineid. I've spent quite a bit of time cleaning up from the mess this created. diana
Re: CVS: cvs.openbsd.org: src
On Mon, 2021-08-09 at 21:58 +0100, Stuart Henderson wrote: > On 2021/08/09 22:35, Martijn van Duren wrote: > > Moving to tech@ > > > > On Mon, 2021-08-09 at 20:56 +0100, Stuart Henderson wrote: > > > On 2021/08/09 12:14, Martijn van Duren wrote: > > > > CVSROOT:/cvs > > > > Module name:src > > > > Changes by: mart...@cvs.openbsd.org2021/08/09 12:14:53 > > > > > > > > Modified files: > > > > usr.sbin/snmpd : parse.y snmpd.c snmpd.conf.5 snmpd.h snmpe.c > > > > util.c > > > > > > > > Log message: > > > > Allow setting the engineid. > > > > > > > > The previous engineid was based aronud the engine boottime and a random > > > > value, which gives problems when sending/receiving unacknowledged PDUs > > > > (trapv2) over SNMPv3 with authentication enabled, which need a > > > > consistent > > > > engineid across restarts to determine the correct user from the sender. > > > > > > > > The new default engineid takes a sha256 hash (chosen for its longer > > > > output) > > > > of gethostname(3) and places the first 27 bytes after the new format > > > > number > > > > 129. This should give us a very low probability of collisions, assuming > > > > all machines have a unique name. > > > > > > what happens if there's a collision? i'm not sure it's safe to assume > > > unique names. > > > > The engineid is used to load the engine context of the originator agent. > > For unacknowledged pdu's this means at least loading the remote users > > (unlike get requests the users, keys and engineid are from the > > originator). > > > > If there's a collision for trapv2 this means that if a user exists on > > both remote agents but with different keys one of them will fail. > > > > But if you want to enter a new user of a new system and you find that > > that engineid already exist it should be a pretty big red flag that > > there's a collision and the new system can explicitly set the engineid. > > Similar if you ever want to set up something like "this engineid can > > only send from this ip": If you see that a new systems engineid already > > has such restriction it means you have to manually set the engineid. > > > > For existing get requests we don't have any risk: For acknowledged PDUs > > (get*/set) the engineid will be discovered (RFC3414 Section 4). And > > people can't have any hefty restrictions in place as is, because > > previously it was randomly generated at startup, so no persistent > > engineid to check on. > > > > I don't see any big risks here. > > > > A minor risk would be that if a hostname ever changes traps won't be > > received anymore, since the engineid changes. But changing a hostname > > seems like something that doesn't happen very often and brings with it > > a lot more migration research. > > > > But considering the question if there was a better idea for generating > > a consistent engineid by jmatthew@ on the 1st without any feedback I > > went with this one. > > If you still feel like there's a risk here after my previous reasoning > > feel free to come up with an alternative. We still have time to change > > it, and even then we have the range 130-255 to implement new formats > > (although then we come back to the discussion about defaults without > > negotiation) > > > > > > > The other formats as specified in SNMP-FRAMEWORK-MIB (RFC3411) are also > > > > supported as well as arbitrary formats in the range 128-255 for other > > > > private enterprise numbers in hex format. > > > > > > > > OK jmatthew@ > > > > > > > > > > > > > Thanks. I haven't looked closely at this before, I just know that it's > common for agents to set it randomly at startup (net-snmp docs say "must > be consistent through time and should not change or conflict with another > agent's engineID. Ever." which isn't exactly clear which is the stronger > requirement - consistency or not conflicting). I'd say the not changing. Because it determines how a password is changed to an auth-/priv-key, which is needed to decipher an incoming unacknowledged trap. However, users will always find some legitimate reason to change it. But that should be their burden. If during setup it's found that a conflict occurs it should be fine to change the engineid, but if you change it in production authentication might fail. > > Regarding the commit, the manual doesn't mention that there's a default. > Should it? e.g. maybe Manpages: not my strong suit :-) I've documented it under hosthash: "This format is the default" Maybe it should be more clear. Does this read better (including some extra explanation for your prior questions)? Index: snmpd.conf.5 === RCS file: /cvs/src/usr.sbin/snmpd/snmpd.conf.5,v retrieving revision 1.54 diff -u -p -r1.54 snmpd.conf.5 --- snmpd.conf.59 Aug 2021 19:13:08 - 1.54 +++ snmpd.conf.59 Aug 2021 22:16:18 - @@ -158,6 +158,12 @@ specifies the privat
Re: CVS: cvs.openbsd.org: src
On 2021/08/09 22:35, Martijn van Duren wrote: > Moving to tech@ > > On Mon, 2021-08-09 at 20:56 +0100, Stuart Henderson wrote: > > On 2021/08/09 12:14, Martijn van Duren wrote: > > > CVSROOT:/cvs > > > Module name:src > > > Changes by: mart...@cvs.openbsd.org2021/08/09 12:14:53 > > > > > > Modified files: > > > usr.sbin/snmpd : parse.y snmpd.c snmpd.conf.5 snmpd.h snmpe.c > > > util.c > > > > > > Log message: > > > Allow setting the engineid. > > > > > > The previous engineid was based aronud the engine boottime and a random > > > value, which gives problems when sending/receiving unacknowledged PDUs > > > (trapv2) over SNMPv3 with authentication enabled, which need a consistent > > > engineid across restarts to determine the correct user from the sender. > > > > > > The new default engineid takes a sha256 hash (chosen for its longer > > > output) > > > of gethostname(3) and places the first 27 bytes after the new format > > > number > > > 129. This should give us a very low probability of collisions, assuming > > > all machines have a unique name. > > > > what happens if there's a collision? i'm not sure it's safe to assume > > unique names. > > The engineid is used to load the engine context of the originator agent. > For unacknowledged pdu's this means at least loading the remote users > (unlike get requests the users, keys and engineid are from the > originator). > > If there's a collision for trapv2 this means that if a user exists on > both remote agents but with different keys one of them will fail. > > But if you want to enter a new user of a new system and you find that > that engineid already exist it should be a pretty big red flag that > there's a collision and the new system can explicitly set the engineid. > Similar if you ever want to set up something like "this engineid can > only send from this ip": If you see that a new systems engineid already > has such restriction it means you have to manually set the engineid. > > For existing get requests we don't have any risk: For acknowledged PDUs > (get*/set) the engineid will be discovered (RFC3414 Section 4). And > people can't have any hefty restrictions in place as is, because > previously it was randomly generated at startup, so no persistent > engineid to check on. > > I don't see any big risks here. > > A minor risk would be that if a hostname ever changes traps won't be > received anymore, since the engineid changes. But changing a hostname > seems like something that doesn't happen very often and brings with it > a lot more migration research. > > But considering the question if there was a better idea for generating > a consistent engineid by jmatthew@ on the 1st without any feedback I > went with this one. > If you still feel like there's a risk here after my previous reasoning > feel free to come up with an alternative. We still have time to change > it, and even then we have the range 130-255 to implement new formats > (although then we come back to the discussion about defaults without > negotiation) > > > > > The other formats as specified in SNMP-FRAMEWORK-MIB (RFC3411) are also > > > supported as well as arbitrary formats in the range 128-255 for other > > > private enterprise numbers in hex format. > > > > > > OK jmatthew@ > > > > > > > Thanks. I haven't looked closely at this before, I just know that it's common for agents to set it randomly at startup (net-snmp docs say "must be consistent through time and should not change or conflict with another agent's engineID. Ever." which isn't exactly clear which is the stronger requirement - consistency or not conflicting). Regarding the commit, the manual doesn't mention that there's a default. Should it? e.g. maybe Index: snmpd.conf.5 === RCS file: /cvs/src/usr.sbin/snmpd/snmpd.conf.5,v retrieving revision 1.54 diff -u -p -r1.54 snmpd.conf.5 --- snmpd.conf.59 Aug 2021 19:13:08 - 1.54 +++ snmpd.conf.59 Aug 2021 20:57:10 - @@ -153,6 +153,7 @@ generation for the .Ar auth and .Ar key . +By default, a hash of the system hostname is used. .Ar enterprise specifies the private enterprise number of the instance and can be either an integer or .
Re: CVS: cvs.openbsd.org: src
Moving to tech@ On Mon, 2021-08-09 at 20:56 +0100, Stuart Henderson wrote: > On 2021/08/09 12:14, Martijn van Duren wrote: > > CVSROOT:/cvs > > Module name:src > > Changes by: mart...@cvs.openbsd.org2021/08/09 12:14:53 > > > > Modified files: > > usr.sbin/snmpd : parse.y snmpd.c snmpd.conf.5 snmpd.h snmpe.c > > util.c > > > > Log message: > > Allow setting the engineid. > > > > The previous engineid was based aronud the engine boottime and a random > > value, which gives problems when sending/receiving unacknowledged PDUs > > (trapv2) over SNMPv3 with authentication enabled, which need a consistent > > engineid across restarts to determine the correct user from the sender. > > > > The new default engineid takes a sha256 hash (chosen for its longer output) > > of gethostname(3) and places the first 27 bytes after the new format number > > 129. This should give us a very low probability of collisions, assuming > > all machines have a unique name. > > what happens if there's a collision? i'm not sure it's safe to assume > unique names. The engineid is used to load the engine context of the originator agent. For unacknowledged pdu's this means at least loading the remote users (unlike get requests the users, keys and engineid are from the originator). If there's a collision for trapv2 this means that if a user exists on both remote agents but with different keys one of them will fail. But if you want to enter a new user of a new system and you find that that engineid already exist it should be a pretty big red flag that there's a collision and the new system can explicitly set the engineid. Similar if you ever want to set up something like "this engineid can only send from this ip": If you see that a new systems engineid already has such restriction it means you have to manually set the engineid. For existing get requests we don't have any risk: For acknowledged PDUs (get*/set) the engineid will be discovered (RFC3414 Section 4). And people can't have any hefty restrictions in place as is, because previously it was randomly generated at startup, so no persistent engineid to check on. I don't see any big risks here. A minor risk would be that if a hostname ever changes traps won't be received anymore, since the engineid changes. But changing a hostname seems like something that doesn't happen very often and brings with it a lot more migration research. But considering the question if there was a better idea for generating a consistent engineid by jmatthew@ on the 1st without any feedback I went with this one. If you still feel like there's a risk here after my previous reasoning feel free to come up with an alternative. We still have time to change it, and even then we have the range 130-255 to implement new formats (although then we come back to the discussion about defaults without negotiation) > > > The other formats as specified in SNMP-FRAMEWORK-MIB (RFC3411) are also > > supported as well as arbitrary formats in the range 128-255 for other > > private enterprise numbers in hex format. > > > > OK jmatthew@ > > >
Re: sshd proctitle [Re: CVS: cvs.openbsd.org: src]
On Fri, 24 Jan 2020, Stuart Henderson wrote: > That works - etc/rc.d/sshd diff to match as follows: > > Index: sshd > === > RCS file: /cvs/src/etc/rc.d/sshd,v > retrieving revision 1.5 > diff -u -p -r1.5 sshd > --- sshd 22 Jan 2020 13:14:51 - 1.5 > +++ sshd 24 Jan 2020 11:59:52 - > @@ -6,7 +6,7 @@ daemon="/usr/sbin/sshd" > > . /etc/rc.d/rc.subr > > -pexp="sshd: \[listener\].*" > +pexp="sshd: ${daemon}${daemon_flags:+ ${daemon_flags}} \[listener\].*" > > rc_reload() { > ${daemon} ${daemon_flags} -t && pkill -HUP -xf "${pexp}" ok djm
Re: sshd proctitle [Re: CVS: cvs.openbsd.org: src]
On Fri, 24 Jan 2020, Antoine Jacoutot wrote: > Great :-) > Ok aja committed, the proctitle looks like this now in case the rc scripts need further tweaking: $ pgrep -lf sshd 12844 sshd: /usr/sbin/sshd -f /etc/ssh/sshd_config [listener] 0 of 10-100 startups
Re: sshd proctitle [Re: CVS: cvs.openbsd.org: src]
Great :-) Ok aja — Antoine > On 24 Jan 2020, at 13:02, Stuart Henderson wrote: > > On 2020/01/23 21:20, Damien Miller wrote: >>> On Thu, 23 Jan 2020, Damien Miller wrote: >>> On Thu, 23 Jan 2020, Damien Miller wrote: >>> What information would you like there? We could put the first N listen addrs in the proctitle if that would help. >>> >>> Maybe like this: >>> >>> 63817 ?? S0:00.05 sshd: [listen] on [0.0.0.0]:22, [::]:22, 0 of >>> 10-100 >> >> antoine@ said this was not sufficient, so please try the following: >> >> 63817 ?? I0:00.09 sshd: /usr/sbin/sshd [listener] 0 of 10-100 >> startups > > That works - etc/rc.d/sshd diff to match as follows: > > Index: sshd > === > RCS file: /cvs/src/etc/rc.d/sshd,v > retrieving revision 1.5 > diff -u -p -r1.5 sshd > --- sshd22 Jan 2020 13:14:51 -1.5 > +++ sshd24 Jan 2020 11:59:52 - > @@ -6,7 +6,7 @@ daemon="/usr/sbin/sshd" > > . /etc/rc.d/rc.subr > > -pexp="sshd: \[listener\].*" > +pexp="sshd: ${daemon}${daemon_flags:+ ${daemon_flags}} \[listener\].*" > > rc_reload() { >${daemon} ${daemon_flags} -t && pkill -HUP -xf "${pexp}" > > > >> >> diff --git a/sshd.c b/sshd.c >> index f6139fe..b7ed0f3 100644 >> --- a/sshd.c >> +++ b/sshd.c >> @@ -240,6 +240,8 @@ void destroy_sensitive_data(void); >> void demote_sensitive_data(void); >> static void do_ssh2_kex(struct ssh *); >> >> +static char *listener_proctitle; >> + >> /* >> * Close all listening sockets >> */ >> @@ -1032,9 +1034,9 @@ server_accept_loop(int *sock_in, int *sock_out, int >> *newsock, int *config_s) >> */ >>for (;;) { >>if (ostartups != startups) { >> -setproctitle("[listener] %d of %d-%d startups", >> -startups, options.max_startups_begin, >> -options.max_startups); >> +setproctitle("%s [listener] %d of %d-%d startups", >> +listener_proctitle, startups, >> +options.max_startups_begin, options.max_startups); >>ostartups = startups; >>} >>if (received_sighup) { >> @@ -1347,6 +1349,41 @@ accumulate_host_timing_secret(struct sshbuf >> *server_cfg, >>sshbuf_free(buf); >> } >> >> +static void >> +xextendf(char **s, const char *sep, const char *fmt, ...) >> +__attribute__((__format__ (printf, 3, 4))) __attribute__((__nonnull__ >> (3))); >> +static void >> +xextendf(char **sp, const char *sep, const char *fmt, ...) >> +{ >> +va_list ap; >> +char *tmp1, *tmp2; >> + >> +va_start(ap, fmt); >> +xvasprintf(&tmp1, fmt, ap); >> +va_end(ap); >> + >> +if (*sp == NULL || **sp == '\0') { >> +free(*sp); >> +*sp = tmp1; >> +return; >> +} >> +xasprintf(&tmp2, "%s%s%s", *sp, sep, tmp1); >> +free(tmp1); >> +free(*sp); >> +*sp = tmp2; >> +} >> + >> +static char * >> +prepare_proctitle(int ac, char **av) >> +{ >> +char *ret = NULL; >> +int i; >> + >> +for (i = 0; i < ac; i++) >> +xextendf(&ret, " ", "%s", av[i]); >> +return ret; >> +} >> + >> /* >> * Main program for the daemon. >> */ >> @@ -1774,6 +1811,7 @@ main(int ac, char **av) >>rexec_argv[rexec_argc] = "-R"; >>rexec_argv[rexec_argc + 1] = NULL; >>} >> +listener_proctitle = prepare_proctitle(ac, av); >> >>/* Ensure that umask disallows at least group and world write */ >>new_umask = umask(0077) | 0022; >> >
Re: sshd proctitle [Re: CVS: cvs.openbsd.org: src]
On 2020/01/23 21:20, Damien Miller wrote: > On Thu, 23 Jan 2020, Damien Miller wrote: > > > On Thu, 23 Jan 2020, Damien Miller wrote: > > > > > What information would you like there? We could put the first N listen > > > addrs in the proctitle if that would help. > > > > Maybe like this: > > > > 63817 ?? S0:00.05 sshd: [listen] on [0.0.0.0]:22, [::]:22, 0 of > > 10-100 > > antoine@ said this was not sufficient, so please try the following: > > 63817 ?? I0:00.09 sshd: /usr/sbin/sshd [listener] 0 of 10-100 > startups That works - etc/rc.d/sshd diff to match as follows: Index: sshd === RCS file: /cvs/src/etc/rc.d/sshd,v retrieving revision 1.5 diff -u -p -r1.5 sshd --- sshd22 Jan 2020 13:14:51 - 1.5 +++ sshd24 Jan 2020 11:59:52 - @@ -6,7 +6,7 @@ daemon="/usr/sbin/sshd" . /etc/rc.d/rc.subr -pexp="sshd: \[listener\].*" +pexp="sshd: ${daemon}${daemon_flags:+ ${daemon_flags}} \[listener\].*" rc_reload() { ${daemon} ${daemon_flags} -t && pkill -HUP -xf "${pexp}" > > diff --git a/sshd.c b/sshd.c > index f6139fe..b7ed0f3 100644 > --- a/sshd.c > +++ b/sshd.c > @@ -240,6 +240,8 @@ void destroy_sensitive_data(void); > void demote_sensitive_data(void); > static void do_ssh2_kex(struct ssh *); > > +static char *listener_proctitle; > + > /* > * Close all listening sockets > */ > @@ -1032,9 +1034,9 @@ server_accept_loop(int *sock_in, int *sock_out, int > *newsock, int *config_s) >*/ > for (;;) { > if (ostartups != startups) { > - setproctitle("[listener] %d of %d-%d startups", > - startups, options.max_startups_begin, > - options.max_startups); > + setproctitle("%s [listener] %d of %d-%d startups", > + listener_proctitle, startups, > + options.max_startups_begin, options.max_startups); > ostartups = startups; > } > if (received_sighup) { > @@ -1347,6 +1349,41 @@ accumulate_host_timing_secret(struct sshbuf > *server_cfg, > sshbuf_free(buf); > } > > +static void > +xextendf(char **s, const char *sep, const char *fmt, ...) > +__attribute__((__format__ (printf, 3, 4))) __attribute__((__nonnull__ > (3))); > +static void > +xextendf(char **sp, const char *sep, const char *fmt, ...) > +{ > + va_list ap; > + char *tmp1, *tmp2; > + > + va_start(ap, fmt); > + xvasprintf(&tmp1, fmt, ap); > + va_end(ap); > + > + if (*sp == NULL || **sp == '\0') { > + free(*sp); > + *sp = tmp1; > + return; > + } > + xasprintf(&tmp2, "%s%s%s", *sp, sep, tmp1); > + free(tmp1); > + free(*sp); > + *sp = tmp2; > +} > + > +static char * > +prepare_proctitle(int ac, char **av) > +{ > + char *ret = NULL; > + int i; > + > + for (i = 0; i < ac; i++) > + xextendf(&ret, " ", "%s", av[i]); > + return ret; > +} > + > /* > * Main program for the daemon. > */ > @@ -1774,6 +1811,7 @@ main(int ac, char **av) > rexec_argv[rexec_argc] = "-R"; > rexec_argv[rexec_argc + 1] = NULL; > } > + listener_proctitle = prepare_proctitle(ac, av); > > /* Ensure that umask disallows at least group and world write */ > new_umask = umask(0077) | 0022; >
Re: sshd proctitle [Re: CVS: cvs.openbsd.org: src]
On Thu, 23 Jan 2020, Damien Miller wrote: > On Thu, 23 Jan 2020, Damien Miller wrote: > > > What information would you like there? We could put the first N listen > > addrs in the proctitle if that would help. > > Maybe like this: > > 63817 ?? S0:00.05 sshd: [listen] on [0.0.0.0]:22, [::]:22, 0 of > 10-100 antoine@ said this was not sufficient, so please try the following: 63817 ?? I0:00.09 sshd: /usr/sbin/sshd [listener] 0 of 10-100 startups diff --git a/sshd.c b/sshd.c index f6139fe..b7ed0f3 100644 --- a/sshd.c +++ b/sshd.c @@ -240,6 +240,8 @@ void destroy_sensitive_data(void); void demote_sensitive_data(void); static void do_ssh2_kex(struct ssh *); +static char *listener_proctitle; + /* * Close all listening sockets */ @@ -1032,9 +1034,9 @@ server_accept_loop(int *sock_in, int *sock_out, int *newsock, int *config_s) */ for (;;) { if (ostartups != startups) { - setproctitle("[listener] %d of %d-%d startups", - startups, options.max_startups_begin, - options.max_startups); + setproctitle("%s [listener] %d of %d-%d startups", + listener_proctitle, startups, + options.max_startups_begin, options.max_startups); ostartups = startups; } if (received_sighup) { @@ -1347,6 +1349,41 @@ accumulate_host_timing_secret(struct sshbuf *server_cfg, sshbuf_free(buf); } +static void +xextendf(char **s, const char *sep, const char *fmt, ...) +__attribute__((__format__ (printf, 3, 4))) __attribute__((__nonnull__ (3))); +static void +xextendf(char **sp, const char *sep, const char *fmt, ...) +{ + va_list ap; + char *tmp1, *tmp2; + + va_start(ap, fmt); + xvasprintf(&tmp1, fmt, ap); + va_end(ap); + + if (*sp == NULL || **sp == '\0') { + free(*sp); + *sp = tmp1; + return; + } + xasprintf(&tmp2, "%s%s%s", *sp, sep, tmp1); + free(tmp1); + free(*sp); + *sp = tmp2; +} + +static char * +prepare_proctitle(int ac, char **av) +{ + char *ret = NULL; + int i; + + for (i = 0; i < ac; i++) + xextendf(&ret, " ", "%s", av[i]); + return ret; +} + /* * Main program for the daemon. */ @@ -1774,6 +1811,7 @@ main(int ac, char **av) rexec_argv[rexec_argc] = "-R"; rexec_argv[rexec_argc + 1] = NULL; } + listener_proctitle = prepare_proctitle(ac, av); /* Ensure that umask disallows at least group and world write */ new_umask = umask(0077) | 0022;
Re: sshd proctitle [Re: CVS: cvs.openbsd.org: src]
On Thu, Jan 23, 2020 at 02:36:43PM +1100, Damien Miller wrote: > On Wed, 22 Jan 2020, Stuart Henderson wrote: > > > On 2020/01/21 15:39, Damien Miller wrote: > > > CVSROOT: /cvs > > > Module name: src > > > Changes by: d...@cvs.openbsd.org2020/01/21 15:39:57 > > > > > > Modified files: > > > usr.bin/ssh: sshd.c > > > > > > Log message: > > > expose the number of currently-authenticating connections > > > along with the MaxStartups limit in the proctitle; > > > suggestion from Philipp Marek, w/ feedback from Craig Miskell > > > ok dtucker@ > > > > > > > It's nice to have this information visible, but it brings some problems. > > You can't now distinguish between multiple sshd processes (e.g. if you > > run several on different ports it's hard to figure out which one to > > signal if needed). > > How could you discern between different sshd processes before? Just the > command-line args? Yes. e.g. for 2 different sshd running: root 92105 0.0 0.0 1360 1296 ?? I Wed07AM0:00.05 /usr/sbin/sshd root 68236 0.0 0.0 1372 1364 ?? S 7:08AM0:00.00 /usr/sbin/sshd -f /etc/ssh/sshd_config2 > What information would you like there? We could put the first N listen > addrs in the proctitle if that would help. Can't we put the args back and append the new things we expose? That will also be easier to know which currently-authenticating / MaxStartups sshd process we are talking about if we run several. proctitle bit us in the arse several times in the past with rc.d. My 2 cents, maybe I am talking garbage. -- Antoine
Re: sshd proctitle [Re: CVS: cvs.openbsd.org: src]
On Thu, 23 Jan 2020, Damien Miller wrote: > On Wed, 22 Jan 2020, Stuart Henderson wrote: > > > On 2020/01/21 15:39, Damien Miller wrote: > > > CVSROOT: /cvs > > > Module name: src > > > Changes by: d...@cvs.openbsd.org2020/01/21 15:39:57 > > > > > > Modified files: > > > usr.bin/ssh: sshd.c > > > > > > Log message: > > > expose the number of currently-authenticating connections > > > along with the MaxStartups limit in the proctitle; > > > suggestion from Philipp Marek, w/ feedback from Craig Miskell > > > ok dtucker@ > > > > > > > It's nice to have this information visible, but it brings some problems. > > You can't now distinguish between multiple sshd processes (e.g. if you > > run several on different ports it's hard to figure out which one to > > signal if needed). > > How could you discern between different sshd processes before? Just the > command-line args? > > What information would you like there? We could put the first N listen > addrs in the proctitle if that would help. Maybe like this: 63817 ?? S0:00.05 sshd: [listen] on [0.0.0.0]:22, [::]:22, 0 of 10-100 ok? diff --git a/sshd.c b/sshd.c index ec644c9..15014d1 100644 --- a/sshd.c +++ b/sshd.c @@ -240,6 +240,9 @@ void destroy_sensitive_data(void); void demote_sensitive_data(void); static void do_ssh2_kex(struct ssh *); +/* Listen info for proctitle */ +static char *proctitle_listen_addr; + /* * Close all listening sockets */ @@ -913,7 +916,7 @@ listen_on_addrs(struct listenaddr *la) { int ret, listen_sock; struct addrinfo *ai; - char ntop[NI_MAXHOST], strport[NI_MAXSERV]; + char *cp, ntop[NI_MAXHOST], strport[NI_MAXSERV]; for (ai = la->addrs; ai; ai = ai->ai_next) { if (ai->ai_family != AF_INET && ai->ai_family != AF_INET6) @@ -973,6 +976,15 @@ listen_on_addrs(struct listenaddr *la) ntop, strport, la->rdomain == NULL ? "" : " rdomain ", la->rdomain == NULL ? "" : la->rdomain); + if (num_listen_socks < 3) { + cp = proctitle_listen_addr; + xasprintf(&proctitle_listen_addr, "%s%s[%s]:%s%s%s", + cp == NULL ? "" : cp, cp == NULL ? "" : ", ", + ntop, strport, + la->rdomain == NULL ? "" : " rdomain ", + la->rdomain == NULL ? "" : la->rdomain); + free(cp); + } } } @@ -1030,7 +1042,9 @@ server_accept_loop(int *sock_in, int *sock_out, int *newsock, int *config_s) */ for (;;) { if (ostartups != startups) { - setproctitle("[listener] %d of %d-%d startups", + setproctitle("[listen] on %s%s, " + "%d of %d-%d startups", proctitle_listen_addr, + num_listen_socks > 3 ? " [...]" : "", startups, options.max_startups_begin, options.max_startups); ostartups = startups;
Re: sshd proctitle [Re: CVS: cvs.openbsd.org: src]
On Wed, 22 Jan 2020, Stuart Henderson wrote: > On 2020/01/21 15:39, Damien Miller wrote: > > CVSROOT:/cvs > > Module name:src > > Changes by: d...@cvs.openbsd.org2020/01/21 15:39:57 > > > > Modified files: > > usr.bin/ssh: sshd.c > > > > Log message: > > expose the number of currently-authenticating connections > > along with the MaxStartups limit in the proctitle; > > suggestion from Philipp Marek, w/ feedback from Craig Miskell > > ok dtucker@ > > > > It's nice to have this information visible, but it brings some problems. > You can't now distinguish between multiple sshd processes (e.g. if you > run several on different ports it's hard to figure out which one to > signal if needed). How could you discern between different sshd processes before? Just the command-line args? What information would you like there? We could put the first N listen addrs in the proctitle if that would help. -d
Re: sshd proctitle [Re: CVS: cvs.openbsd.org: src]
I guess this needs to be changed again, to retain more info from the original title. Stuart Henderson wrote: > On 2020/01/21 15:39, Damien Miller wrote: > > CVSROOT:/cvs > > Module name:src > > Changes by: d...@cvs.openbsd.org2020/01/21 15:39:57 > > > > Modified files: > > usr.bin/ssh: sshd.c > > > > Log message: > > expose the number of currently-authenticating connections > > along with the MaxStartups limit in the proctitle; > > suggestion from Philipp Marek, w/ feedback from Craig Miskell > > ok dtucker@ > > > > It's nice to have this information visible, but it brings some problems. > You can't now distinguish between multiple sshd processes (e.g. if you > run several on different ports it's hard to figure out which one to > signal if needed). > > The rc.d script also needs updating because it uses pgrep to find the > matching process: > > Index: sshd > === > RCS file: /cvs/src/etc/rc.d/sshd,v > retrieving revision 1.4 > diff -u -p -r1.4 sshd > --- sshd 11 Jan 2018 19:52:12 - 1.4 > +++ sshd 22 Jan 2020 12:52:15 - > @@ -6,6 +6,8 @@ daemon="/usr/sbin/sshd" > > . /etc/rc.d/rc.subr > > +pexp="sshd: \[listener\].*" > + > rc_reload() { > ${daemon} ${daemon_flags} -t && pkill -HUP -xf "${pexp}" > } > >
sshd proctitle [Re: CVS: cvs.openbsd.org: src]
On 2020/01/21 15:39, Damien Miller wrote: > CVSROOT: /cvs > Module name: src > Changes by: d...@cvs.openbsd.org2020/01/21 15:39:57 > > Modified files: > usr.bin/ssh: sshd.c > > Log message: > expose the number of currently-authenticating connections > along with the MaxStartups limit in the proctitle; > suggestion from Philipp Marek, w/ feedback from Craig Miskell > ok dtucker@ > It's nice to have this information visible, but it brings some problems. You can't now distinguish between multiple sshd processes (e.g. if you run several on different ports it's hard to figure out which one to signal if needed). The rc.d script also needs updating because it uses pgrep to find the matching process: Index: sshd === RCS file: /cvs/src/etc/rc.d/sshd,v retrieving revision 1.4 diff -u -p -r1.4 sshd --- sshd11 Jan 2018 19:52:12 - 1.4 +++ sshd22 Jan 2020 12:52:15 - @@ -6,6 +6,8 @@ daemon="/usr/sbin/sshd" . /etc/rc.d/rc.subr +pexp="sshd: \[listener\].*" + rc_reload() { ${daemon} ${daemon_flags} -t && pkill -HUP -xf "${pexp}" }
Re: pthread process-private futexes [Re: CVS: cvs.openbsd.org: src]
On 24/10/19(Thu) 13:30, Stuart Henderson wrote: > On 2019/10/21 04:06, Martin Pieuchot wrote: > > CVSROOT:/cvs > > Module name:src > > Changes by: m...@cvs.openbsd.org2019/10/21 04:06:31 > > > > Modified files: > > lib/librthread : synch.h > > > > Log message: > > Use process-private futexes to avoid the uvm_map lookup overhead. > > > > While here kill unused _wait() function. > > > > ok visa@ > > > > I'm going to back this one out for now - it causes hangs with Python > (seems to be 100% reproducible). Easy/fast test case: > > cd /usr/ports/graphics/py-Pillow > make > > With this commit, it hangs after > > writing manifest file 'src/Pillow.egg-info/SOURCES.txt' robert@ figured out that Python3 doesn't have that problem. If somebody could figure out which upstream change fixed the issue that would be great.
Re: pthread process-private futexes [Re: CVS: cvs.openbsd.org: src]
On 24/10/19(Thu) 13:30, Stuart Henderson wrote: > On 2019/10/21 04:06, Martin Pieuchot wrote: > > CVSROOT:/cvs > > Module name:src > > Changes by: m...@cvs.openbsd.org2019/10/21 04:06:31 > > > > Modified files: > > lib/librthread : synch.h > > > > Log message: > > Use process-private futexes to avoid the uvm_map lookup overhead. > > > > While here kill unused _wait() function. > > > > ok visa@ > > > > I'm going to back this one out for now - it causes hangs with Python > (seems to be 100% reproducible). Easy/fast test case: > > cd /usr/ports/graphics/py-Pillow > make > > With this commit, it hangs after > > writing manifest file 'src/Pillow.egg-info/SOURCES.txt' ltrace shows that sempahore are used. gdb says that sem_init() is always called with `pshared' set to 0. However python forks then sleeps in futex(2), via sem_wait(3), when private futexes are used. When non-private futexes are used it it seems that threads from a process wake up the sleeping thread from a parent process: 84294/104794 python2.7 CALL futex(0x1a49bbca3008,0x1,0,0,0) 84677/611464 python2.7 CALL futex(0x1a49bbca3008,0x2,1,0,0) To me it seems that shared semaphore, that are advertised in librthread as non-supported, are in fact used. Python has a second lock implementation using mutex and condvar, I'd be interested to know if that works.
pthread process-private futexes [Re: CVS: cvs.openbsd.org: src]
On 2019/10/21 04:06, Martin Pieuchot wrote: > CVSROOT: /cvs > Module name: src > Changes by: m...@cvs.openbsd.org2019/10/21 04:06:31 > > Modified files: > lib/librthread : synch.h > > Log message: > Use process-private futexes to avoid the uvm_map lookup overhead. > > While here kill unused _wait() function. > > ok visa@ > I'm going to back this one out for now - it causes hangs with Python (seems to be 100% reproducible). Easy/fast test case: cd /usr/ports/graphics/py-Pillow make With this commit, it hangs after writing manifest file 'src/Pillow.egg-info/SOURCES.txt'
Re: bgpd "export default-route" [Re: CVS: cvs.openbsd.org: src]
Thanks for a couple of offlist replies .. I had a partial src checkout and "make install" was installing the new binaries to / rather than /usr/sbin. I thought I had accounted for that and copied them into place but I guess with the late hour I must have missed something, as I've done a full src checkout from -current now and it's working as expected. On 2019/05/29 02:53, Stuart Henderson wrote: > On 2019/05/13 07:47, Denis Fondras wrote: > > CVSROOT:/cvs > > Module name:src > > Changes by: de...@cvs.openbsd.org 2019/05/13 07:47:36 > > > > Modified files: > > usr.sbin/bgpd : rde_update.c > > > > Log message: > > fix export default-route. > > > > OK claudio@ > > > > I've just been updating some remaining 6.3-ish boxes and running into > problems with this.. Does anyone have a config with "export default-route" > that works OK on -current that I could take a look at and see if I can > figure out what I've missed? > > I started with a working 6.3 config that has several peer groups (all > ibgp in this case). For one group it passes a full table, for another > (a couple of firewalls/VPN boxes etc) it uses "announce default-route" > to just feed a default route. > > In preparation for the update I made sure I have explicit default "deny > from/to any" rules at the top of the ruleset, "allow to group XX" for > that peer group, and no other rules that should deny the default route > being sent to them. > > After updating to 6.5, 0 routes are received at the peer. > > After spotting the above commit I updated bgpd to -current, same > again - no routes received at the peer. > > -current$ bgpctl sh rib out > flags: * = Valid, > = Selected, I = via IBGP, A = Announced, >S = Stale, E = Error > origin validation state: N = not-found, V = valid, ! = invalid > origin: i = IGP, e = EGP, ? = Incomplete > > flags ovs destination gateway lpref med aspath origin > I* N 0.0.0.0/00.0.0.0100 0 i > * N 0.0.0.0/00.0.0.0100 0 i > * N 0.0.0.0/00.0.0.0100 0 i > I* N 0.0.0.0/00.0.0.0100 0 i > I* N 0.0.0.0/00.0.0.0100 0 i > I* N 0.0.0.0/00.0.0.0100 0 i > I* N 0.0.0.0/00.0.0.0100 0 i > I* N 0.0.0.0/00.0.0.0100 0 i > I* N ::/0 :: 100 0 i > > -current$ bgpctl sh rib out nei somepeer > flags: * = Valid, > = Selected, I = via IBGP, A = Announced, >S = Stale, E = Error > origin validation state: N = not-found, V = valid, ! = invalid > origin: i = IGP, e = EGP, ? = Incomplete > > flags ovs destination gateway lpref med aspath origin > I* N 0.0.0.0/00.0.0.0100 0 i > > ... I'm not sure about the 0.0.0.0 for gateway, it doesn't feel right, > but I can't compare with 6.3 because I don't see anything from "sh rib out > nei XX" > and a plain "sh rib out" isn't available there. > > somepeer$ bgpctl sh > Neighbor ASMsgRcvdMsgSent OutQ Up/Down > State/PrfRcvd > (-current) x 386398 386395 0 00:53:13 0 > (6.3) x 386382 386368 0 00:00:02 1 > > .. > > I've backed out to 2018/06/12 so I can remove my hastily-added static > defaults ;) but would be grateful for any clues .. >
bgpd "export default-route" [Re: CVS: cvs.openbsd.org: src]
On 2019/05/13 07:47, Denis Fondras wrote: > CVSROOT: /cvs > Module name: src > Changes by: de...@cvs.openbsd.org 2019/05/13 07:47:36 > > Modified files: > usr.sbin/bgpd : rde_update.c > > Log message: > fix export default-route. > > OK claudio@ > I've just been updating some remaining 6.3-ish boxes and running into problems with this.. Does anyone have a config with "export default-route" that works OK on -current that I could take a look at and see if I can figure out what I've missed? I started with a working 6.3 config that has several peer groups (all ibgp in this case). For one group it passes a full table, for another (a couple of firewalls/VPN boxes etc) it uses "announce default-route" to just feed a default route. In preparation for the update I made sure I have explicit default "deny from/to any" rules at the top of the ruleset, "allow to group XX" for that peer group, and no other rules that should deny the default route being sent to them. After updating to 6.5, 0 routes are received at the peer. After spotting the above commit I updated bgpd to -current, same again - no routes received at the peer. -current$ bgpctl sh rib out flags: * = Valid, > = Selected, I = via IBGP, A = Announced, S = Stale, E = Error origin validation state: N = not-found, V = valid, ! = invalid origin: i = IGP, e = EGP, ? = Incomplete flags ovs destination gateway lpref med aspath origin I* N 0.0.0.0/00.0.0.0100 0 i * N 0.0.0.0/00.0.0.0100 0 i * N 0.0.0.0/00.0.0.0100 0 i I* N 0.0.0.0/00.0.0.0100 0 i I* N 0.0.0.0/00.0.0.0100 0 i I* N 0.0.0.0/00.0.0.0100 0 i I* N 0.0.0.0/00.0.0.0100 0 i I* N 0.0.0.0/00.0.0.0100 0 i I* N ::/0 :: 100 0 i -current$ bgpctl sh rib out nei somepeer flags: * = Valid, > = Selected, I = via IBGP, A = Announced, S = Stale, E = Error origin validation state: N = not-found, V = valid, ! = invalid origin: i = IGP, e = EGP, ? = Incomplete flags ovs destination gateway lpref med aspath origin I* N 0.0.0.0/00.0.0.0100 0 i ... I'm not sure about the 0.0.0.0 for gateway, it doesn't feel right, but I can't compare with 6.3 because I don't see anything from "sh rib out nei XX" and a plain "sh rib out" isn't available there. somepeer$ bgpctl sh Neighbor ASMsgRcvdMsgSent OutQ Up/Down State/PrfRcvd (-current) x 386398 386395 0 00:53:13 0 (6.3) x 386382 386368 0 00:00:02 1 .. I've backed out to 2018/06/12 so I can remove my hastily-added static defaults ;) but would be grateful for any clues ..
Re: CVS: cvs.openbsd.org: src
On Fri, Dec 28, 2018 at 03:05:15PM -0700, Denis Fondras wrote: > CVSROOT: /cvs > Module name: src > Changes by: de...@cvs.openbsd.org 2018/12/28 15:05:15 > > Modified files: > usr.sbin/bgpd : kroute.c > > Log message: > move kroute_find() call later > > No need to scan the list if we return early. > > OK claudio@ > Doh! I forgot to mention this was spotted by kn@. Sorry.
Re: CVS: cvs.openbsd.org: src
> Because you can tuna meltover, but you can't tune a fish. > (hat tip to the author of the tunefs(8) manpage.) And to REO Speedwagon!
Re: CVS: cvs.openbsd.org: src
On Thu, Jul 12, 2018 at 2:11 PM Philip Guenther wrote: > CVSROOT:/cvs > Module name:src > Changes by: guent...@cvs.openbsd.org2018/07/12 08:11:11 > > Modified files: > sys/arch/amd64/amd64: cpu.c identcpu.c locore.S machdep.c pmap.c > vector.S > sys/arch/amd64/conf: ld.script > sys/arch/amd64/include: asm.h codepatch.h > > Log message: > Reorganize the Meltdown entry and exit trampolines for syscall and > traps so that the "mov %rax,%cr3" is followed by an infinite loop > which is avoided because the mapping of the code being executed is > changed. This means the sysretq/iretq isn't even present in that > flow of instructions in the kernel mapping, so userspace code can't > be speculatively reached on the kernel mapping and totally eliminates > the conditional jump over the the %cr3 change that supported CPUs > without the Meltdown vulnerability. The return paths were probably > vulnerable to Spectre v1 (and v1.1/1.2) style attacks, speculatively > executing user code post-system-call with the kernel mappings, thus > creating cache/TLB/etc side-effects. Damnit, I left out that since this evolves the _Meltdown_ fix with mapping _over_ the trampoline, we're calling this the Tuna Meltover. Because you can tuna meltover, but you can't tune a fish. (hat tip to the author of the tunefs(8) manpage.) Philip Guenther
Re: CVS: cvs.openbsd.org: src
> On Fri, Feb 9, 2018, at 3:46 PM, Theo de Raadt wrote: > > > On Thu, Feb 8, 2018, at 9:01 PM, Theo de Raadt wrote: > > > > CVSROOT:/cvs > > > > Module name:src > > > > Changes by: dera...@cvs.openbsd.org 2018/02/08 20:01:24 > > > > > > > > Modified files: > > > > sys/dev: rnd.c > > > > > > > > Log message: > > > > Situation occur where bootloader cannot supply kernel with early > > > > random data. But a new source of entropy arrived a few months ago > > > > -- KARL generates highly disturbed images for some kernels (well, > > > > not for bsd.rd) > > > > This assumes the tail of text (just before etext[]) is readable. > > > > We are trying to use a portable symbol name, and also avoid reading > > > > a locore0 which has been unmapped... > > > > ok mortimer > > > > > > > > > > I'm seeing an unaligned access fault on armv7. But should etext be > > > aligned, or should the code using it take alignment into account? > > > > Please add printf's and figure out what is going on. > > > > > > etext is coming from the linker script, and as such isn't necessarily aligned > like clang assumes it is. So clang generates LDR instead of LDRB and loses. > > I have also been seeing other similar problems for a while now (relinked > kernels getting stuck in early boot, crashes before going multiuser, etc.) on > armv7 that I think might also be alignment problems. I've been digging around > in it for a while now but don't have it 100% nailed yet. > > I will continue to look into this. > > Press SPACE to abort autoboot in 2 seconds > switch to partitions #0, OK > mmc0 is current device > SD/MMC found on device 0 > ** Unable to read file boot.scr ** > ** Unable to read file uEnv.txt ** > switch to partitions #0, OK > mmc0 is current device > Scanning mmc 0:1... > reading /am335x-boneblack.dtb > 35930 bytes read in 9 ms (3.8 MiB/s) > Found EFI removable media binary efi/boot/bootarm.efi > Scanning disks on usb... > Scanning disks on mmc... > MMC Device 2 not found > MMC Device 3 not found > Found 6 disks > reading efi/boot/bootarm.efi > 76528 bytes read in 14 ms (5.2 MiB/s) > ## Starting EFI application at 8200 ... > >> OpenBSD/armv7 BOOTARM 1.0 > boot> > booting sd0a:/bsd: 4535443+206344+562616 [277544+90+282224+244902]=0x5d8520 > > OpenBSD/armv7 booting ... > arg0 0xc08d8520 arg1 0xe05 arg2 0x8800 > Allocating page tables > freestart = 0x808d9000, free_pages = 128807 (0x0001f727) > IRQ stack: p0x80907000 v0xc0907000 > ABT stack: p0x80908000 v0xc0908000 > UND stack: p0x80909000 v0xc0909000 > SVC stack: p0x8090a000 v0xc090a000 > Creating L1 page table at 0x808dc000 > Mapping kernel > Constructing L2 page tables > undefined page pmap [ using 805216 bytes of bsd ELF symbol table ] > board type: 3589 > Copyright (c) 1982, 1986, 1989, 1991, 1993 > The Regents of the University of California. All rights reserved. > Copyright (c) 1995-2018 OpenBSD. All rights reserved. https://www.OpenBSD.org > > OpenBSD 6.2-current (GENERIC) #1: Sun Jan 28 16:48:36 CST 2018 > r...@beagle3.east.rtk0.net:/usr/src/sys/arch/armv7/compile/GENERIC > real mem = 536870912 (512MB) > avail mem = 516878336 (492MB) > Fatal kernel mode data abort: 'Alignment fault' > trapframe: 0xc090bf38 > DFSR=0001, DFAR=c0733493, spsr=2193 > r0 =c0733493, r1 =0800, r2 =c07efcdc, r3 =c073b234 > r4 =c07acce0, r5 =0005, r6 =0007, r7 =0006 > r8 =c07d3288, r9 =0332, r10=019a, r11=c090bfa8 > r12=000b, ssp=c090bf8c, slr=c05da2e4, pc =c05d8f50 > > Stopped at add_entropy_words+0x5c: ldr r8, [r0], #0x004 > ddb> show registers > spsr 0x2193 > r00xc0733493ieee80211_mira_valid_tx_mcs.max_mcs+0xf8b > r1 0x800fiqvector+0x7e4 > r20xc07efcdcentropy_add_ptr > r30xc073b234add_entropy_words.twist_table > r40xc07acce0entropy_pool > r5 0x5 > r6 0x7 > r7 0x6 > r80xc07d3288cpu_info_primary > r9 0x332fiqvector+0x316 > r100x19afiqvector+0x17e > r11 0xc090bfa8_bss_end__+0xf83e8 > r12 0xb > usr_sp 0 > usr_lr 0 > svc_sp0xc090bf8c_bss_end__+0xf83cc > svc_lr0xc05da2e4random_start+0x8c > pc0xc05d8f50add_entropy_words+0x5c > und_sp0xc090a000_bss_end__+0xf6440 > abt_sp0xc0909000_bss_end__+0xf5440 > irq_sp0xc0908000_bss_end__+0xf4440 > add_entropy_words+0x5c: ldr r8, [r0], #0x004 > > > - > > This patch fixes the abort for me. > > > Index: sys/arch/arm/conf/ldscript.tail > === > RCS file: /cvs/src/sys/arch/arm/conf/ldscript.tail,v > retrieving revision 1.5 > diff -u -p -u -r1.5 ldscript.tail > --- sys/arch/arm/c
Re: CVS: cvs.openbsd.org: src
On Fri, Feb 9, 2018, at 3:46 PM, Theo de Raadt wrote: > > On Thu, Feb 8, 2018, at 9:01 PM, Theo de Raadt wrote: > > > CVSROOT: /cvs > > > Module name: src > > > Changes by: dera...@cvs.openbsd.org 2018/02/08 20:01:24 > > > > > > Modified files: > > > sys/dev: rnd.c > > > > > > Log message: > > > Situation occur where bootloader cannot supply kernel with early > > > random data. But a new source of entropy arrived a few months ago > > > -- KARL generates highly disturbed images for some kernels (well, > > > not for bsd.rd) > > > This assumes the tail of text (just before etext[]) is readable. > > > We are trying to use a portable symbol name, and also avoid reading > > > a locore0 which has been unmapped... > > > ok mortimer > > > > > > > I'm seeing an unaligned access fault on armv7. But should etext be aligned, > > or should the code using it take alignment into account? > > Please add printf's and figure out what is going on. > > etext is coming from the linker script, and as such isn't necessarily aligned like clang assumes it is. So clang generates LDR instead of LDRB and loses. I have also been seeing other similar problems for a while now (relinked kernels getting stuck in early boot, crashes before going multiuser, etc.) on armv7 that I think might also be alignment problems. I've been digging around in it for a while now but don't have it 100% nailed yet. I will continue to look into this. Press SPACE to abort autoboot in 2 seconds switch to partitions #0, OK mmc0 is current device SD/MMC found on device 0 ** Unable to read file boot.scr ** ** Unable to read file uEnv.txt ** switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... reading /am335x-boneblack.dtb 35930 bytes read in 9 ms (3.8 MiB/s) Found EFI removable media binary efi/boot/bootarm.efi Scanning disks on usb... Scanning disks on mmc... MMC Device 2 not found MMC Device 3 not found Found 6 disks reading efi/boot/bootarm.efi 76528 bytes read in 14 ms (5.2 MiB/s) ## Starting EFI application at 8200 ... >> OpenBSD/armv7 BOOTARM 1.0 boot> booting sd0a:/bsd: 4535443+206344+562616 [277544+90+282224+244902]=0x5d8520 OpenBSD/armv7 booting ... arg0 0xc08d8520 arg1 0xe05 arg2 0x8800 Allocating page tables freestart = 0x808d9000, free_pages = 128807 (0x0001f727) IRQ stack: p0x80907000 v0xc0907000 ABT stack: p0x80908000 v0xc0908000 UND stack: p0x80909000 v0xc0909000 SVC stack: p0x8090a000 v0xc090a000 Creating L1 page table at 0x808dc000 Mapping kernel Constructing L2 page tables undefined page pmap [ using 805216 bytes of bsd ELF symbol table ] board type: 3589 Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. Copyright (c) 1995-2018 OpenBSD. All rights reserved. https://www.OpenBSD.org OpenBSD 6.2-current (GENERIC) #1: Sun Jan 28 16:48:36 CST 2018 r...@beagle3.east.rtk0.net:/usr/src/sys/arch/armv7/compile/GENERIC real mem = 536870912 (512MB) avail mem = 516878336 (492MB) Fatal kernel mode data abort: 'Alignment fault' trapframe: 0xc090bf38 DFSR=0001, DFAR=c0733493, spsr=2193 r0 =c0733493, r1 =0800, r2 =c07efcdc, r3 =c073b234 r4 =c07acce0, r5 =0005, r6 =0007, r7 =0006 r8 =c07d3288, r9 =0332, r10=019a, r11=c090bfa8 r12=000b, ssp=c090bf8c, slr=c05da2e4, pc =c05d8f50 Stopped at add_entropy_words+0x5c: ldr r8, [r0], #0x004 ddb> show registers spsr 0x2193 r00xc0733493ieee80211_mira_valid_tx_mcs.max_mcs+0xf8b r1 0x800fiqvector+0x7e4 r20xc07efcdcentropy_add_ptr r30xc073b234add_entropy_words.twist_table r40xc07acce0entropy_pool r5 0x5 r6 0x7 r7 0x6 r80xc07d3288cpu_info_primary r9 0x332fiqvector+0x316 r100x19afiqvector+0x17e r11 0xc090bfa8_bss_end__+0xf83e8 r12 0xb usr_sp 0 usr_lr 0 svc_sp0xc090bf8c_bss_end__+0xf83cc svc_lr0xc05da2e4random_start+0x8c pc0xc05d8f50add_entropy_words+0x5c und_sp0xc090a000_bss_end__+0xf6440 abt_sp0xc0909000_bss_end__+0xf5440 irq_sp0xc0908000_bss_end__+0xf4440 add_entropy_words+0x5c: ldr r8, [r0], #0x004 - This patch fixes the abort for me. Index: sys/arch/arm/conf/ldscript.tail === RCS file: /cvs/src/sys/arch/arm/conf/ldscript.tail,v retrieving revision 1.5 diff -u -p -u -r1.5 ldscript.tail --- sys/arch/arm/conf/ldscript.tail 26 Oct 2017 19:01:06 - 1.5 +++ sys/arch/arm/conf/ldscript.tail 9 Feb 2018 23:28:43 - @@ -1,5 +1,6 @@ /* $OpenBSD: ldscript.tail,v 1.5 2017/10/26 19:01:06 kettenis Exp $ */ } =0 + . = ALIGN(4); PROVIDE
Re: CVS: cvs.openbsd.org: src
> On Thu, Feb 8, 2018, at 9:01 PM, Theo de Raadt wrote: > > CVSROOT:/cvs > > Module name:src > > Changes by: dera...@cvs.openbsd.org 2018/02/08 20:01:24 > > > > Modified files: > > sys/dev: rnd.c > > > > Log message: > > Situation occur where bootloader cannot supply kernel with early > > random data. But a new source of entropy arrived a few months ago > > -- KARL generates highly disturbed images for some kernels (well, > > not for bsd.rd) > > This assumes the tail of text (just before etext[]) is readable. > > We are trying to use a portable symbol name, and also avoid reading > > a locore0 which has been unmapped... > > ok mortimer > > > > I'm seeing an unaligned access fault on armv7. But should etext be aligned, > or should the code using it take alignment into account? Please add printf's and figure out what is going on.
Re: CVS: cvs.openbsd.org: src
On Thu, Feb 8, 2018, at 9:01 PM, Theo de Raadt wrote: > CVSROOT: /cvs > Module name: src > Changes by: dera...@cvs.openbsd.org 2018/02/08 20:01:24 > > Modified files: > sys/dev: rnd.c > > Log message: > Situation occur where bootloader cannot supply kernel with early > random data. But a new source of entropy arrived a few months ago > -- KARL generates highly disturbed images for some kernels (well, > not for bsd.rd) > This assumes the tail of text (just before etext[]) is readable. > We are trying to use a portable symbol name, and also avoid reading > a locore0 which has been unmapped... > ok mortimer > I'm seeing an unaligned access fault on armv7. But should etext be aligned, or should the code using it take alignment into account?
Re: CVS: cvs.openbsd.org: src
On Fri, 8 Sep 2017, Alexander Bluhm wrote: > On Tue, Sep 05, 2017 at 10:20:12PM -0600, Philip Guenther wrote: > > CVSROOT:/cvs > > Module name:src > > Changes by: guent...@cvs.openbsd.org2017/09/05 22:20:12 > > > > Modified files: > > regress/sys/kern/ptrace: ptrace.c > > > > Log message: > > Fix declarations > > ptrace(PT_IO) memory protection faults return EACCES, not EFAULT > > Now the test fails on i386. > > /usr/src/regress/sys/kern/ptrace/ptrace -Irib > ptrace: ptrace(PT_IO): Bad address > *** Error 1 in . (Makefile:19 'io_read_i_bad') > FAILED > > Apparently i386 and amd64 return different errors. Do you know > why? Is it worth to invesitgate or shoud we just accept both cases? It was worth investigating and, having done so, I think my change was incorrect and should be reverted and the amd64 kernel fixed to return EFAULT in that case. Currently on amd64, the copyin(9) family of calls will pass through the return value of uvm_fault() and thus return not just EFAULT but possibly EACCES, ENOMEM, and EIO. Since the return value of those functions is usually passed through to userspace, that's a Bad Thing IMO and we need to fix them to always return EFAULT when uvm_fault() fails. The diff below does that by merging copy_fault and copy_efault, and ditto copystr_fault and copystr_efault, and dropping the attempt to pass the error number from trap() to the pcb_onfault callback. While here, delete the similar attempt on arm64 to pass the error number from trap() to the pcb_onfault callback...which already ignores it and always return EFAULT. ok? Philip Index: sys/arch/amd64/amd64/trap.c === RCS file: /cvs/src/sys/arch/amd64/amd64/trap.c,v retrieving revision 1.57 diff -u -p -r1.57 trap.c --- sys/arch/amd64/amd64/trap.c 25 Aug 2017 19:28:48 - 1.57 +++ sys/arch/amd64/amd64/trap.c 9 Sep 2017 23:30:19 - @@ -211,10 +211,8 @@ trap(struct trapframe *frame) goto we_re_toast; /* Check for copyin/copyout fault. */ if (pcb->pcb_onfault != 0) { - error = EFAULT; copyfault: frame->tf_rip = (u_int64_t)pcb->pcb_onfault; - frame->tf_rax = error; return; } Index: sys/arch/amd64/amd64/copy.S === RCS file: /cvs/src/sys/arch/amd64/amd64/copy.S,v retrieving revision 1.10 diff -u -p -r1.10 copy.S --- sys/arch/amd64/amd64/copy.S 25 Aug 2017 19:28:48 - 1.10 +++ sys/arch/amd64/amd64/copy.S 9 Sep 2017 23:30:19 - @@ -107,10 +107,10 @@ ENTRY(copyout) movq%rdi,%rdx addq%rax,%rdx - jc _C_LABEL(copy_efault) + jc _C_LABEL(copy_fault) movq$VM_MAXUSER_ADDRESS,%r8 cmpq%r8,%rdx - ja _C_LABEL(copy_efault) + ja _C_LABEL(copy_fault) movqCPUVAR(CURPCB),%rdx leaq_C_LABEL(copy_fault)(%rip),%r11 @@ -145,10 +145,10 @@ ENTRY(copyin) movq%rsi,%rdx addq%rax,%rdx - jc _C_LABEL(copy_efault) + jc _C_LABEL(copy_fault) movq$VM_MAXUSER_ADDRESS,%r8 cmpq%r8,%rdx - ja _C_LABEL(copy_efault) + ja _C_LABEL(copy_fault) 3: /* bcopy(%rsi, %rdi, %rax); */ movq%rax,%rcx @@ -171,13 +171,11 @@ ENTRY(copyin) xorl%eax,%eax ret -NENTRY(copy_efault) - movq$EFAULT,%rax - NENTRY(copy_fault) SMAP_CLAC movqCPUVAR(CURPCB),%rdx popqPCB_ONFAULT(%rdx) + movl$EFAULT,%eax ret ENTRY(copyoutstr) @@ -194,7 +192,7 @@ ENTRY(copyoutstr) */ movq$VM_MAXUSER_ADDRESS,%rax subq%rdi,%rax - jbe _C_LABEL(copystr_efault)/* die if CF == 1 || ZF == 1 */ + jbe _C_LABEL(copystr_fault) /* die if CF == 1 || ZF == 1 */ cmpq%rdx,%rax jae 1f movq%rax,%rdx @@ -217,8 +215,8 @@ ENTRY(copyoutstr) 2: /* rdx is zero -- return EFAULT or ENAMETOOLONG. */ movq$VM_MAXUSER_ADDRESS,%r11 cmpq%r11,%rdi - jae _C_LABEL(copystr_efault) - movq$ENAMETOOLONG,%rax + jae _C_LABEL(copystr_fault) + movl$ENAMETOOLONG,%eax jmp copystr_return ENTRY(copyinstr) @@ -236,7 +234,7 @@ ENTRY(copyinstr) */ movq$VM_MAXUSER_ADDRESS,%rax subq%rsi,%rax - jbe _C_LABEL(copystr_efault)/* die if CF == 1 || ZF == 1 */ + jbe _C_LABEL(copystr_fault) /* die if CF == 1 || ZF == 1 */ cmpq%rdx,%rax jae 1f movq%rax,%rdx @@ -259,14 +257,12 @@ ENTRY(copyinstr) 2: /* edx is zero -- return EFAULT or ENAMETOOLONG. */ m
Re: i386 zzz broken, Was: CVS: cvs.openbsd.org: src
Wed, 30 Aug 2017 16:39:18 -0700 Mike Larkin > On Wed, Aug 30, 2017 at 12:48:20AM -0700, Mike Larkin wrote: > > On Tue, Aug 29, 2017 at 04:32:04PM -0700, Mike Larkin wrote: > > > On Mon, Aug 28, 2017 at 11:18:13PM +0300, li...@wrant.com wrote: > > > > Mon, 28 Aug 2017 10:16:58 -0600 (MDT) Ted Unangst > > > > > CVSROOT: /cvs > > > > > Module name: src > > > > > Changes by: t...@cvs.openbsd.org2017/08/28 10:16:58 > > > > > > > > > > Modified files: > > > > > usr.sbin/apmd : apmd.8 apmd.c > > > > > > > > > > Log message: > > > > > add -z and -Z options to auto suspend or hibernate when low on > > > > > battery. > > > > > from Jesper Wallin > > > > > > > > > > > > > Hi tech@, > > > > > > > > Could someone please test and confirm suspend still works on i386? I am > > > > getting the laptop to wake but it's stuck, black screen, high fan speed, > > > > no response, only long press on the power button works. It used to work > > > > flawless, I suspect it might be from the last few snapshots, can't tell. > > > > > > > > Ready to provide details if this works elsewhere & someone's interested. > > > > Please let me know if it's a known/expected issue, or better sendbug(1). > > > > > > > > Kind regards, > > > > Anton Lazarov > > > > > > > > > > Hmm, I can repro this here even with qemu. It's stuck in lapic_delay. > > > > > > I'll see if I can track down what's going wrong. It would also help if you > > > could narrow down when it broke. > > > > > > -ml > > > > > > > I figured out what was going on, but it's unclear why this suddenly broke. > > > > Once we get to the bottom of what caused the breakage, I'll commit a fix. > > > > -ml > > > > We figured out what was going wrong. I just committed a fix. Should be in > snaps soon. Thanks for reporting it. > > -ml Wed, 30 Aug 2017 17:40:22 -0600 (MDT) Mike Larkin > CVSROOT: /cvs > Module name: src > Changes by: mlar...@cvs.openbsd.org 2017/08/30 17:40:22 > > Modified files: > sys/arch/amd64/amd64: acpi_wakecode.S > sys/arch/i386/i386: acpi_wakecode.S > > Log message: > adjust ACPI resume-time saved stack location to account for a different > layout used by clang on i386. Also add a clarification to amd64's version > of the same (amd64 already had such an adjustment). > > ok deraadt, tom, kettenis > Hi Mike, I just installed the snapshot immediately after it became available on the mirrors, and can confirm suspend & resume works on my i386 laptop. Hibernation works too. Thank you very much for sorting this so quick. Kind regards, Anton Lazarov
Re: i386 zzz broken, Was: CVS: cvs.openbsd.org: src
On Wed, Aug 30, 2017 at 12:48:20AM -0700, Mike Larkin wrote: > On Tue, Aug 29, 2017 at 04:32:04PM -0700, Mike Larkin wrote: > > On Mon, Aug 28, 2017 at 11:18:13PM +0300, li...@wrant.com wrote: > > > Mon, 28 Aug 2017 10:16:58 -0600 (MDT) Ted Unangst > > > > CVSROOT:/cvs > > > > Module name:src > > > > Changes by: t...@cvs.openbsd.org2017/08/28 10:16:58 > > > > > > > > Modified files: > > > > usr.sbin/apmd : apmd.8 apmd.c > > > > > > > > Log message: > > > > add -z and -Z options to auto suspend or hibernate when low on battery. > > > > from Jesper Wallin > > > > > > > > > > Hi tech@, > > > > > > Could someone please test and confirm suspend still works on i386? I am > > > getting the laptop to wake but it's stuck, black screen, high fan speed, > > > no response, only long press on the power button works. It used to work > > > flawless, I suspect it might be from the last few snapshots, can't tell. > > > > > > Ready to provide details if this works elsewhere & someone's interested. > > > Please let me know if it's a known/expected issue, or better sendbug(1). > > > > > > Kind regards, > > > Anton Lazarov > > > > > > > Hmm, I can repro this here even with qemu. It's stuck in lapic_delay. > > > > I'll see if I can track down what's going wrong. It would also help if you > > could narrow down when it broke. > > > > -ml > > > > I figured out what was going on, but it's unclear why this suddenly broke. > > Once we get to the bottom of what caused the breakage, I'll commit a fix. > > -ml > We figured out what was going wrong. I just committed a fix. Should be in snaps soon. Thanks for reporting it. -ml
Re: i386 zzz broken, Was: CVS: cvs.openbsd.org: src
On 2017/08/30 09:04, Florian Obser wrote: > On Tue, Aug 29, 2017 at 07:25:33PM -0700, Chris Cappuccio wrote: > > li...@wrant.com [li...@wrant.com] wrote: > > > > > > Please let me know if you want me to generate some dumps or similar, but > > > unfortunately, I can't yet test patches or handle compilation on my own. > > > I realise my info on this is incredibly lacking as quality & usefulness. > > > > > > > Stuart Henderson has an archive of kernels from snapshot builds that you > > can use to better narrow down when the regression started. > > > > Unfortunately I don't remember the URL. > > IIRC sthen asked for it to not be shared, it got shared on misc and he > changed the URL or shutdown the archive. Use this: > https://ftp.hostserver.de/archive/ > > It keeps all base for all archs and packages for amd64 for 80 days. Yes - I do still have the archive for some arches (amd64, armv7, i386, loongson, macppc, octeon, sparc64) - kernels only, archived daily if they changed since the previous snapshot, currently back to the start of 2015 (though I may cull them at some point). If the archive on hostserver doesn't go back far enough, let me know which arch and approx dates of interest and I'll copy the relevant files to somewhere suitable to fetch from.
Re: i386 zzz broken, Was: CVS: cvs.openbsd.org: src
On Tue, Aug 29, 2017 at 07:25:33PM -0700, Chris Cappuccio wrote: > li...@wrant.com [li...@wrant.com] wrote: > > > > Please let me know if you want me to generate some dumps or similar, but > > unfortunately, I can't yet test patches or handle compilation on my own. > > I realise my info on this is incredibly lacking as quality & usefulness. > > > > Stuart Henderson has an archive of kernels from snapshot builds that you > can use to better narrow down when the regression started. > > Unfortunately I don't remember the URL. IIRC sthen asked for it to not be shared, it got shared on misc and he changed the URL or shutdown the archive. Use this: https://ftp.hostserver.de/archive/ It keeps all base for all archs and packages for amd64 for 80 days. -- I'm not entirely sure you are real.
Re: i386 zzz broken, Was: CVS: cvs.openbsd.org: src
On Tue, Aug 29, 2017 at 04:32:04PM -0700, Mike Larkin wrote: > On Mon, Aug 28, 2017 at 11:18:13PM +0300, li...@wrant.com wrote: > > Mon, 28 Aug 2017 10:16:58 -0600 (MDT) Ted Unangst > > > CVSROOT: /cvs > > > Module name: src > > > Changes by: t...@cvs.openbsd.org2017/08/28 10:16:58 > > > > > > Modified files: > > > usr.sbin/apmd : apmd.8 apmd.c > > > > > > Log message: > > > add -z and -Z options to auto suspend or hibernate when low on battery. > > > from Jesper Wallin > > > > > > > Hi tech@, > > > > Could someone please test and confirm suspend still works on i386? I am > > getting the laptop to wake but it's stuck, black screen, high fan speed, > > no response, only long press on the power button works. It used to work > > flawless, I suspect it might be from the last few snapshots, can't tell. > > > > Ready to provide details if this works elsewhere & someone's interested. > > Please let me know if it's a known/expected issue, or better sendbug(1). > > > > Kind regards, > > Anton Lazarov > > > > Hmm, I can repro this here even with qemu. It's stuck in lapic_delay. > > I'll see if I can track down what's going wrong. It would also help if you > could narrow down when it broke. > > -ml > I figured out what was going on, but it's unclear why this suddenly broke. Once we get to the bottom of what caused the breakage, I'll commit a fix. -ml
Re: i386 zzz broken, Was: CVS: cvs.openbsd.org: src
li...@wrant.com [li...@wrant.com] wrote: > > Please let me know if you want me to generate some dumps or similar, but > unfortunately, I can't yet test patches or handle compilation on my own. > I realise my info on this is incredibly lacking as quality & usefulness. > Stuart Henderson has an archive of kernels from snapshot builds that you can use to better narrow down when the regression started. Unfortunately I don't remember the URL. Someone who has it easily accessible may choose to provide it in a reply. You should be able to boot the older kernels with either the 6.2-beta userland, or with the 6.1 userland. One or the other will work typically. If you can try them and narrow down, that's all that's necessary. Chris
Re: i386 zzz broken, Was: CVS: cvs.openbsd.org: src
Tue, 29 Aug 2017 16:32:04 -0700 Mike Larkin > On Mon, Aug 28, 2017 at 11:18:13PM +0300, li...@wrant.com wrote: > > Mon, 28 Aug 2017 10:16:58 -0600 (MDT) Ted Unangst > > > CVSROOT: /cvs > > > Module name: src > > > Changes by: t...@cvs.openbsd.org2017/08/28 10:16:58 > > > > > > Modified files: > > > usr.sbin/apmd : apmd.8 apmd.c > > > > > > Log message: > > > add -z and -Z options to auto suspend or hibernate when low on battery. > > > from Jesper Wallin > > > > > > > Hi tech@, > > > > Could someone please test and confirm suspend still works on i386? I am > > getting the laptop to wake but it's stuck, black screen, high fan speed, > > no response, only long press on the power button works. It used to work > > flawless, I suspect it might be from the last few snapshots, can't tell. > > > > Ready to provide details if this works elsewhere & someone's interested. > > Please let me know if it's a known/expected issue, or better sendbug(1). > > > > Kind regards, > > Anton Lazarov > > > > Hmm, I can repro this here even with qemu. It's stuck in lapic_delay. > > I'll see if I can track down what's going wrong. It would also help if you > could narrow down when it broke. > > -ml > Hi Mike, Thank you for looking into this. I'm using the laptop as a 24/7 desktop machine, and rarely suspend it to be honest, especially since it started having this problem, maybe somewhere after the last release. Sorry that I can not be more specific about it, I'll keep a track on this from now. Please let me know if you want me to generate some dumps or similar, but unfortunately, I can't yet test patches or handle compilation on my own. I realise my info on this is incredibly lacking as quality & usefulness. Kind regards, Anton Lazarov > > OpenBSD 6.2-beta (GENERIC.MP) #91: Sun Aug 27 17:26:00 MDT 2017 > > dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP > > cpu0: Intel(R) Atom(TM) CPU N280 @ 1.66GHz ("GenuineIntel" 686-class) 1.67 > > GHz > > cpu0: > > FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,NXE,SSE3,DTES64,MWAIT,DS-CPL,EST,TM2,SSSE3,xTPR,PDCM,MOVBE,LAHF,PERF,SENSOR > > real mem = 1064452096 (1015MB) > > avail mem = 1029943296 (982MB) > > mpath0 at root > > scsibus0 at mpath0: 256 targets > > mainbus0 at root > > bios0 at mainbus0: date 04/18/11, BIOS32 rev. 0 @ 0xf0010, SMBIOS rev. 2.5 > > @ 0xf0720 (30 entries) > > bios0: vendor American Megatrends Inc. version "1601" date 04/18/2011 > > bios0: ASUSTeK Computer INC. 1005HA > > acpi0 at bios0: rev 0 > > acpi0: sleep states S0 S3 S4 S5 > > acpi0: tables DSDT FACP APIC MCFG OEMB HPET SSDT > > acpi0: wakeup devices P0P2(S4) P0P1(S4) HDAC(S4) P0P4(S4) P0P8(S4) P0P5(S4) > > P0P7(S4) P0P9(S4) P0P6(S4) > > acpitimer0 at acpi0: 3579545 Hz, 24 bits > > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat > > cpu0 at mainbus0: apid 0 (boot processor) > > mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges > > cpu0: apic clock running at 166MHz > > cpu0: mwait min=64, max=64, C-substates=0.2.2.0.2, IBE > > cpu1 at mainbus0: apid 1 (application processor) > > cpu1: Intel(R) Atom(TM) CPU N280 @ 1.66GHz ("GenuineIntel" 686-class) 1.67 > > GHz > > cpu1: > > FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,NXE,SSE3,DTES64,MWAIT,DS-CPL,EST,TM2,SSSE3,xTPR,PDCM,MOVBE,LAHF,PERF,SENSOR > > ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins > > acpimcfg0 at acpi0 addr 0xe000, bus 0-63 > > acpihpet0 at acpi0: 14318179 Hz > > acpiprt0 at acpi0: bus 0 (PCI0) > > acpiprt1 at acpi0: bus 2 (P0P5) > > acpiprt2 at acpi0: bus 1 (P0P7) > > acpiprt3 at acpi0: bus -1 (P0P6) > > acpiec0 at acpi0 > > acpicpu0 at acpi0: !C2(500@1 mwait.1@0x10), C1(1000@1 mwait.1), PSS > > acpicpu1 at acpi0: !C2(500@1 mwait.1@0x10), C1(1000@1 mwait.1), PSS > > acpitz0 at acpi0: critical temperature is 88 degC > > "SYN0A13" at acpi0 not configured > > acpibat0 at acpi0: BAT0 model "1005HA" serial type LION oem "ASUS" > > acpiac0 at acpi0: AC unit online > > acpibtn0 at acpi0: LID_ > > acpibtn1 at acpi0: SLPB > > acpibtn2 at acpi0: PWRB > > "PNP0C14" at acpi0 not configured > > acpivideo0 at acpi0: VGA_ > > acpivout0 at acpivideo0: LCDD > > bios0: ROM list: 0xc/0xec00! 0xcf000/0x1000 > > cpu0: Enhanced SpeedStep 1667 MHz: speeds: 1667, 1333, 1000 MHz > > pci0 at mainbus0 bus 0: configuration mode 1 (bios) > > pchb0 at pci0 dev 0 function 0 "Intel 82945GME Host" rev 0x03 > > inteldrm0 at pci0 dev 2 function 0 "Intel 82945GME Video" rev 0x03 > > drm0 at inteldrm0 > > intagp0 at inteldrm0 > > agp0 at intagp0: aperture at 0xd000, size 0x1000 > > inteldrm0: apic 2 int 16 > > inteldrm0: 1024x600, 32bpp > > wsdisplay0 at inteldrm0 mux 1: console (std, vt100 emulation) > > wsdisplay0: screen 1-5 added (std, vt100 emulation) > > "Intel 82945GM Video" rev 0x03 at pci0 dev 2 function 1 not configured >
i386 zzz broken, Was: CVS: cvs.openbsd.org: src
On Mon, Aug 28, 2017 at 11:18:13PM +0300, li...@wrant.com wrote: > Mon, 28 Aug 2017 10:16:58 -0600 (MDT) Ted Unangst > > CVSROOT:/cvs > > Module name:src > > Changes by: t...@cvs.openbsd.org2017/08/28 10:16:58 > > > > Modified files: > > usr.sbin/apmd : apmd.8 apmd.c > > > > Log message: > > add -z and -Z options to auto suspend or hibernate when low on battery. > > from Jesper Wallin > > > > Hi tech@, > > Could someone please test and confirm suspend still works on i386? I am > getting the laptop to wake but it's stuck, black screen, high fan speed, > no response, only long press on the power button works. It used to work > flawless, I suspect it might be from the last few snapshots, can't tell. > > Ready to provide details if this works elsewhere & someone's interested. > Please let me know if it's a known/expected issue, or better sendbug(1). > > Kind regards, > Anton Lazarov > Hmm, I can repro this here even with qemu. It's stuck in lapic_delay. I'll see if I can track down what's going wrong. It would also help if you could narrow down when it broke. -ml > OpenBSD 6.2-beta (GENERIC.MP) #91: Sun Aug 27 17:26:00 MDT 2017 > dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP > cpu0: Intel(R) Atom(TM) CPU N280 @ 1.66GHz ("GenuineIntel" 686-class) 1.67 GHz > cpu0: > FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,NXE,SSE3,DTES64,MWAIT,DS-CPL,EST,TM2,SSSE3,xTPR,PDCM,MOVBE,LAHF,PERF,SENSOR > real mem = 1064452096 (1015MB) > avail mem = 1029943296 (982MB) > mpath0 at root > scsibus0 at mpath0: 256 targets > mainbus0 at root > bios0 at mainbus0: date 04/18/11, BIOS32 rev. 0 @ 0xf0010, SMBIOS rev. 2.5 @ > 0xf0720 (30 entries) > bios0: vendor American Megatrends Inc. version "1601" date 04/18/2011 > bios0: ASUSTeK Computer INC. 1005HA > acpi0 at bios0: rev 0 > acpi0: sleep states S0 S3 S4 S5 > acpi0: tables DSDT FACP APIC MCFG OEMB HPET SSDT > acpi0: wakeup devices P0P2(S4) P0P1(S4) HDAC(S4) P0P4(S4) P0P8(S4) P0P5(S4) > P0P7(S4) P0P9(S4) P0P6(S4) > acpitimer0 at acpi0: 3579545 Hz, 24 bits > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat > cpu0 at mainbus0: apid 0 (boot processor) > mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges > cpu0: apic clock running at 166MHz > cpu0: mwait min=64, max=64, C-substates=0.2.2.0.2, IBE > cpu1 at mainbus0: apid 1 (application processor) > cpu1: Intel(R) Atom(TM) CPU N280 @ 1.66GHz ("GenuineIntel" 686-class) 1.67 GHz > cpu1: > FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,NXE,SSE3,DTES64,MWAIT,DS-CPL,EST,TM2,SSSE3,xTPR,PDCM,MOVBE,LAHF,PERF,SENSOR > ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins > acpimcfg0 at acpi0 addr 0xe000, bus 0-63 > acpihpet0 at acpi0: 14318179 Hz > acpiprt0 at acpi0: bus 0 (PCI0) > acpiprt1 at acpi0: bus 2 (P0P5) > acpiprt2 at acpi0: bus 1 (P0P7) > acpiprt3 at acpi0: bus -1 (P0P6) > acpiec0 at acpi0 > acpicpu0 at acpi0: !C2(500@1 mwait.1@0x10), C1(1000@1 mwait.1), PSS > acpicpu1 at acpi0: !C2(500@1 mwait.1@0x10), C1(1000@1 mwait.1), PSS > acpitz0 at acpi0: critical temperature is 88 degC > "SYN0A13" at acpi0 not configured > acpibat0 at acpi0: BAT0 model "1005HA" serial type LION oem "ASUS" > acpiac0 at acpi0: AC unit online > acpibtn0 at acpi0: LID_ > acpibtn1 at acpi0: SLPB > acpibtn2 at acpi0: PWRB > "PNP0C14" at acpi0 not configured > acpivideo0 at acpi0: VGA_ > acpivout0 at acpivideo0: LCDD > bios0: ROM list: 0xc/0xec00! 0xcf000/0x1000 > cpu0: Enhanced SpeedStep 1667 MHz: speeds: 1667, 1333, 1000 MHz > pci0 at mainbus0 bus 0: configuration mode 1 (bios) > pchb0 at pci0 dev 0 function 0 "Intel 82945GME Host" rev 0x03 > inteldrm0 at pci0 dev 2 function 0 "Intel 82945GME Video" rev 0x03 > drm0 at inteldrm0 > intagp0 at inteldrm0 > agp0 at intagp0: aperture at 0xd000, size 0x1000 > inteldrm0: apic 2 int 16 > inteldrm0: 1024x600, 32bpp > wsdisplay0 at inteldrm0 mux 1: console (std, vt100 emulation) > wsdisplay0: screen 1-5 added (std, vt100 emulation) > "Intel 82945GM Video" rev 0x03 at pci0 dev 2 function 1 not configured > azalia0 at pci0 dev 27 function 0 "Intel 82801GB HD Audio" rev 0x02: msi > azalia0: codecs: Realtek ALC269 > audio0 at azalia0 > ppb0 at pci0 dev 28 function 0 "Intel 82801GB PCIE" rev 0x02: apic 2 int 16 > pci1 at ppb0 bus 4 > ppb1 at pci0 dev 28 function 1 "Intel 82801GB PCIE" rev 0x02: apic 2 int 17 > pci2 at ppb1 bus 2 > athn0 at pci2 dev 0 function 0 "Atheros AR9285" rev 0x01: apic 2 int 17 > athn0: AR9285 rev 2 (1T1R), ROM rev 13, address 00:25:d3:5f:06:4c > ppb2 at pci0 dev 28 function 3 "Intel 82801GB PCIE" rev 0x02: apic 2 int 19 > pci3 at ppb2 bus 1 > alc0 at pci3 dev 0 function 0 "Attansic Technology L2C" rev 0xc0: msi, > address 00:26:18:93:af:0b > atphy0 at alc0 phy 0: F1 10/100/1000 PHY, rev. 11 > uhci0 at pci0 dev 29 function 0 "Intel 82801GB USB" rev 0x02: apic 2 int 23 > uhci1 a
Re: CVS: cvs.openbsd.org: src
Mon, 28 Aug 2017 10:16:58 -0600 (MDT) Ted Unangst > CVSROOT: /cvs > Module name: src > Changes by: t...@cvs.openbsd.org2017/08/28 10:16:58 > > Modified files: > usr.sbin/apmd : apmd.8 apmd.c > > Log message: > add -z and -Z options to auto suspend or hibernate when low on battery. > from Jesper Wallin > Hi tech@, Could someone please test and confirm suspend still works on i386? I am getting the laptop to wake but it's stuck, black screen, high fan speed, no response, only long press on the power button works. It used to work flawless, I suspect it might be from the last few snapshots, can't tell. Ready to provide details if this works elsewhere & someone's interested. Please let me know if it's a known/expected issue, or better sendbug(1). Kind regards, Anton Lazarov OpenBSD 6.2-beta (GENERIC.MP) #91: Sun Aug 27 17:26:00 MDT 2017 dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP cpu0: Intel(R) Atom(TM) CPU N280 @ 1.66GHz ("GenuineIntel" 686-class) 1.67 GHz cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,NXE,SSE3,DTES64,MWAIT,DS-CPL,EST,TM2,SSSE3,xTPR,PDCM,MOVBE,LAHF,PERF,SENSOR real mem = 1064452096 (1015MB) avail mem = 1029943296 (982MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: date 04/18/11, BIOS32 rev. 0 @ 0xf0010, SMBIOS rev. 2.5 @ 0xf0720 (30 entries) bios0: vendor American Megatrends Inc. version "1601" date 04/18/2011 bios0: ASUSTeK Computer INC. 1005HA acpi0 at bios0: rev 0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC MCFG OEMB HPET SSDT acpi0: wakeup devices P0P2(S4) P0P1(S4) HDAC(S4) P0P4(S4) P0P8(S4) P0P5(S4) P0P7(S4) P0P9(S4) P0P6(S4) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 166MHz cpu0: mwait min=64, max=64, C-substates=0.2.2.0.2, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel(R) Atom(TM) CPU N280 @ 1.66GHz ("GenuineIntel" 686-class) 1.67 GHz cpu1: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,NXE,SSE3,DTES64,MWAIT,DS-CPL,EST,TM2,SSSE3,xTPR,PDCM,MOVBE,LAHF,PERF,SENSOR ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins acpimcfg0 at acpi0 addr 0xe000, bus 0-63 acpihpet0 at acpi0: 14318179 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 2 (P0P5) acpiprt2 at acpi0: bus 1 (P0P7) acpiprt3 at acpi0: bus -1 (P0P6) acpiec0 at acpi0 acpicpu0 at acpi0: !C2(500@1 mwait.1@0x10), C1(1000@1 mwait.1), PSS acpicpu1 at acpi0: !C2(500@1 mwait.1@0x10), C1(1000@1 mwait.1), PSS acpitz0 at acpi0: critical temperature is 88 degC "SYN0A13" at acpi0 not configured acpibat0 at acpi0: BAT0 model "1005HA" serial type LION oem "ASUS" acpiac0 at acpi0: AC unit online acpibtn0 at acpi0: LID_ acpibtn1 at acpi0: SLPB acpibtn2 at acpi0: PWRB "PNP0C14" at acpi0 not configured acpivideo0 at acpi0: VGA_ acpivout0 at acpivideo0: LCDD bios0: ROM list: 0xc/0xec00! 0xcf000/0x1000 cpu0: Enhanced SpeedStep 1667 MHz: speeds: 1667, 1333, 1000 MHz pci0 at mainbus0 bus 0: configuration mode 1 (bios) pchb0 at pci0 dev 0 function 0 "Intel 82945GME Host" rev 0x03 inteldrm0 at pci0 dev 2 function 0 "Intel 82945GME Video" rev 0x03 drm0 at inteldrm0 intagp0 at inteldrm0 agp0 at intagp0: aperture at 0xd000, size 0x1000 inteldrm0: apic 2 int 16 inteldrm0: 1024x600, 32bpp wsdisplay0 at inteldrm0 mux 1: console (std, vt100 emulation) wsdisplay0: screen 1-5 added (std, vt100 emulation) "Intel 82945GM Video" rev 0x03 at pci0 dev 2 function 1 not configured azalia0 at pci0 dev 27 function 0 "Intel 82801GB HD Audio" rev 0x02: msi azalia0: codecs: Realtek ALC269 audio0 at azalia0 ppb0 at pci0 dev 28 function 0 "Intel 82801GB PCIE" rev 0x02: apic 2 int 16 pci1 at ppb0 bus 4 ppb1 at pci0 dev 28 function 1 "Intel 82801GB PCIE" rev 0x02: apic 2 int 17 pci2 at ppb1 bus 2 athn0 at pci2 dev 0 function 0 "Atheros AR9285" rev 0x01: apic 2 int 17 athn0: AR9285 rev 2 (1T1R), ROM rev 13, address 00:25:d3:5f:06:4c ppb2 at pci0 dev 28 function 3 "Intel 82801GB PCIE" rev 0x02: apic 2 int 19 pci3 at ppb2 bus 1 alc0 at pci3 dev 0 function 0 "Attansic Technology L2C" rev 0xc0: msi, address 00:26:18:93:af:0b atphy0 at alc0 phy 0: F1 10/100/1000 PHY, rev. 11 uhci0 at pci0 dev 29 function 0 "Intel 82801GB USB" rev 0x02: apic 2 int 23 uhci1 at pci0 dev 29 function 1 "Intel 82801GB USB" rev 0x02: apic 2 int 19 uhci2 at pci0 dev 29 function 2 "Intel 82801GB USB" rev 0x02: apic 2 int 18 uhci3 at pci0 dev 29 function 3 "Intel 82801GB USB" rev 0x02: apic 2 int 16 ehci0 at pci0 dev 29 function 7 "Intel 82801GB USB" rev 0x02: apic 2 int 23 usb0 at ehci0: USB revision 2.0 uhub0 at usb0 configuration 1 interface 0 "Intel EHCI root hub" rev 2.00/1.00 addr 1 ppb3 at pci0 dev 30 function 0 "Intel 82801B
Re: CVS: cvs.openbsd.org: src
On 07/03/17 08:30, Martijn van Duren wrote: > On 07/01/17 18:14, Mark Kettenis wrote: >> CVSROOT: /cvs >> Module name: src >> Changes by: kette...@cvs.openbsd.org2017/07/01 10:14:10 >> >> Modified files: >> sys/dev/pci/drm: drm_irq.c drm_linux.c drm_linux.h >> drm_linux_list.h drm_mm.c drm_mm.h drm_mode.h >> drm_modes.c drm_rect.c drm_rect.h >> drm_vma_manager.c files.drm i915_drm.h >> i915_pciids.h linux_hdmi.h >> sys/dev/pci/drm/i915: dvo.h dvo_ch7017.c dvo_ch7xxx.c dvo_ivch.c >>dvo_ns2501.c dvo_sil164.c dvo_tfp410.c >>i915_dma.c i915_drv.c i915_drv.h >>i915_gem.c i915_gem_context.c >>i915_gem_evict.c i915_gem_execbuffer.c >>i915_gem_gtt.c i915_gem_stolen.c >>i915_gem_tiling.c i915_gpu_error.c >>i915_irq.c i915_reg.h i915_suspend.c >>i915_trace.h intel_bios.c intel_bios.h >>intel_crt.c intel_ddi.c intel_display.c >>intel_dp.c intel_drv.h intel_dvo.c >>intel_fbdev.c intel_hdmi.c intel_i2c.c >>intel_lvds.c intel_modes.c >>intel_opregion.c intel_overlay.c >>intel_panel.c intel_pm.c >>intel_ringbuffer.c intel_ringbuffer.h >>intel_sdvo.c intel_sdvo_regs.h >>intel_sideband.c intel_sprite.c intel_tv.c >>intel_uncore.c >> sys/dev/pci/drm/radeon: atombios_crtc.c atombios_dp.c >> atombios_i2c.c nid.h r100.c radeon.h >> radeon_connectors.c radeon_device.c >> radeon_display.c radeon_fb.c >> radeon_i2c.c radeon_irq_kms.c >> radeon_kms.c radeon_legacy_crtc.c >> radeon_legacy_encoders.c radeon_mode.h >> radeon_pm.c >> sys/dev/pci/drm/ttm: ttm_bo_manager.c >> Added files: >> sys/dev/pci/drm: drm_linux_atomic.h drm_mipi_dsi.h drm_modes.h >> drm_modeset_lock.c drm_modeset_lock.h >> drm_panel.c drm_panel.h drm_plane_helper.c >> drm_plane_helper.h drm_probe_helper.c >> linux_list_sort.c linux_types.h >> linux_ww_mutex.h >> sys/dev/pci/drm/i915: i915_cmd_parser.c i915_gem_batch_pool.c >>i915_gem_batch_pool.h i915_gem_fence.c >>i915_gem_gtt.h i915_gem_render_state.c >>i915_gem_render_state.h i915_gem_userptr.c >>i915_guc_reg.h i915_guc_submission.c >>i915_params.c i915_vgpu.c i915_vgpu.h >>intel_atomic.c intel_atomic_plane.c >>intel_audio.c intel_csr.c intel_dp_mst.c >>intel_dsi.c intel_dsi.h >>intel_dsi_panel_vbt.c intel_dsi_pll.c >>intel_fbc.c intel_fifo_underrun.c >>intel_frontbuffer.c intel_gtt.c >>intel_guc.h intel_guc_fwif.h >>intel_guc_loader.c intel_hotplug.c >>intel_lrc.c intel_lrc.h intel_mocs.c >>intel_mocs.h intel_psr.c >>intel_renderstate.h >>intel_renderstate_gen6.c >>intel_renderstate_gen7.c >>intel_renderstate_gen8.c >>intel_renderstate_gen9.c >>intel_runtime_pm.c >> sys/dev/pci/drm/radeon: radeon_dp_auxch.c >> >> Log message: >> Update inteldrm(4) to code based on Linux 4.4.70. This brings us support for >> Skylake and Cherryview and better support for Broadwell and Valleyview. Also >> adds MST support. Some tweaks to the TTM code and radeondrm(4) to keep it >> working with the updated generic DRM code needed for inteldrm(4). >> >> Tested by many. >> > This change *STILL* breaks my $DAYJOB machine. > After a couple of updates where I had to revert back to an old kernel I managed to lay claim to a "new" system. This one is intel only and doesn't have any issues. If there's still interest in fixing this issue, the hardware is still available, but there's no direct need for me any more. OpenBSD 6.1-current (GENERIC.MP) #95: Wed Jul 12 19:23:28 MDT 2017 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP RTC BIOS d
Re: CVS: cvs.openbsd.org: src
Hi, On Jul 4, 2017, at 7:40 AM, Mark Kettenis wrote: >> From: Frank Groeneveld >> Date: Tue, 04 Jul 2017 09:38:18 +0200 >> >>> On Mon, Jul 3, 2017, at 08:30, Martijn van Duren wrote: >>> This change *STILL* breaks my $DAYJOB machine. >>> >>> dmesg with DRMDEBUG enabled >> >> Maybe you shouldn't chose Apple hardware ;-) I've actually had really positive experiences with running OpenBSD with Apple hardware. I had an iMac that I used as an experimental box and the only issue with it was retrieving the blob for the video card. Likewise, I had a firewall/NIDS running on a headless Mac Mini with no issues. Even more impressive, I had zero-configuration support for an Apple USB 10/100 NIC, which I expected would be a bit more of a niche device. I note that you mention ThinkPads and I know they are highly regarded within the OpenBSD community . . . I just thought I'd throw in my two cents on Apple hardware! Cheers, - J
Re: CVS: cvs.openbsd.org: src
> From: Frank Groeneveld > Date: Tue, 04 Jul 2017 09:38:18 +0200 > > On Mon, Jul 3, 2017, at 08:30, Martijn van Duren wrote: > > This change *STILL* breaks my $DAYJOB machine. > > > > dmesg with DRMDEBUG enabled > > Maybe you shouldn't chose Apple hardware ;-) Well. That machine used to work. Some change in the generic drm code or my changes to radeondrm(4) made it stop working. Hopefully the problem can be reproduced and we can get some clues what broke.
Re: CVS: cvs.openbsd.org: src
On Mon, Jul 3, 2017, at 08:30, Martijn van Duren wrote: > This change *STILL* breaks my $DAYJOB machine. > > dmesg with DRMDEBUG enabled Maybe you shouldn't chose Apple hardware ;-) Works great here on a Thinkpad X260 Mark, thank you very much! Frank
Re: CVS: cvs.openbsd.org: src
On 07/01/17 18:14, Mark Kettenis wrote: > CVSROOT: /cvs > Module name: src > Changes by: kette...@cvs.openbsd.org2017/07/01 10:14:10 > > Modified files: > sys/dev/pci/drm: drm_irq.c drm_linux.c drm_linux.h >drm_linux_list.h drm_mm.c drm_mm.h drm_mode.h >drm_modes.c drm_rect.c drm_rect.h >drm_vma_manager.c files.drm i915_drm.h >i915_pciids.h linux_hdmi.h > sys/dev/pci/drm/i915: dvo.h dvo_ch7017.c dvo_ch7xxx.c dvo_ivch.c > dvo_ns2501.c dvo_sil164.c dvo_tfp410.c > i915_dma.c i915_drv.c i915_drv.h > i915_gem.c i915_gem_context.c > i915_gem_evict.c i915_gem_execbuffer.c > i915_gem_gtt.c i915_gem_stolen.c > i915_gem_tiling.c i915_gpu_error.c > i915_irq.c i915_reg.h i915_suspend.c > i915_trace.h intel_bios.c intel_bios.h > intel_crt.c intel_ddi.c intel_display.c > intel_dp.c intel_drv.h intel_dvo.c > intel_fbdev.c intel_hdmi.c intel_i2c.c > intel_lvds.c intel_modes.c > intel_opregion.c intel_overlay.c > intel_panel.c intel_pm.c > intel_ringbuffer.c intel_ringbuffer.h > intel_sdvo.c intel_sdvo_regs.h > intel_sideband.c intel_sprite.c intel_tv.c > intel_uncore.c > sys/dev/pci/drm/radeon: atombios_crtc.c atombios_dp.c > atombios_i2c.c nid.h r100.c radeon.h > radeon_connectors.c radeon_device.c > radeon_display.c radeon_fb.c > radeon_i2c.c radeon_irq_kms.c > radeon_kms.c radeon_legacy_crtc.c > radeon_legacy_encoders.c radeon_mode.h > radeon_pm.c > sys/dev/pci/drm/ttm: ttm_bo_manager.c > Added files: > sys/dev/pci/drm: drm_linux_atomic.h drm_mipi_dsi.h drm_modes.h >drm_modeset_lock.c drm_modeset_lock.h >drm_panel.c drm_panel.h drm_plane_helper.c >drm_plane_helper.h drm_probe_helper.c >linux_list_sort.c linux_types.h >linux_ww_mutex.h > sys/dev/pci/drm/i915: i915_cmd_parser.c i915_gem_batch_pool.c > i915_gem_batch_pool.h i915_gem_fence.c > i915_gem_gtt.h i915_gem_render_state.c > i915_gem_render_state.h i915_gem_userptr.c > i915_guc_reg.h i915_guc_submission.c > i915_params.c i915_vgpu.c i915_vgpu.h > intel_atomic.c intel_atomic_plane.c > intel_audio.c intel_csr.c intel_dp_mst.c > intel_dsi.c intel_dsi.h > intel_dsi_panel_vbt.c intel_dsi_pll.c > intel_fbc.c intel_fifo_underrun.c > intel_frontbuffer.c intel_gtt.c > intel_guc.h intel_guc_fwif.h > intel_guc_loader.c intel_hotplug.c > intel_lrc.c intel_lrc.h intel_mocs.c > intel_mocs.h intel_psr.c > intel_renderstate.h > intel_renderstate_gen6.c > intel_renderstate_gen7.c > intel_renderstate_gen8.c > intel_renderstate_gen9.c > intel_runtime_pm.c > sys/dev/pci/drm/radeon: radeon_dp_auxch.c > > Log message: > Update inteldrm(4) to code based on Linux 4.4.70. This brings us support for > Skylake and Cherryview and better support for Broadwell and Valleyview. Also > adds MST support. Some tweaks to the TTM code and radeondrm(4) to keep it > working with the updated generic DRM code needed for inteldrm(4). > > Tested by many. > This change *STILL* breaks my $DAYJOB machine. dmesg with DRMDEBUG enabled OpenBSD 6.1-current (GENERIC.MP) #21: Mon Jul 3 08:14:45 CEST 2017 mart...@martijn.office.rootnet.nl:/home/martijn/src/OpenBSD/sys/arch/amd64/compile/GENERIC.MP RTC BIOS diagnostic error d1 real mem = 4253237248 (4056MB) avail mem = 4118540288 (3927MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.4 @ 0x8ed34000 (61 entries) bios0: vendor Apple Inc. version "IM121.88Z.0047.B1F.1201241648" date 01/24/12 bios0:
Re: CVS: cvs.openbsd.org: src - removal of sys/scanio.h
On Mon, May 29, 2017 at 03:40:59PM +0200, Sebastien Marie wrote: > On Mon, May 29, 2017 at 06:10:51AM -0600, Ted Unangst wrote: > > CVSROOT:/cvs > > Module name:src > > Changes by: t...@cvs.openbsd.org2017/05/29 06:10:51 > > > > Removed files: > > sys/sys: scanio.h > > > > Log message: > > scanner support died some time ago, the header can be removed too. > > a gift from miod > > > > The remove of sys/scanio.h broke usr.bin/kdump. > correction was just commited. sorry for the noise :) -- Sebastien Marie
Re: CVS: cvs.openbsd.org: src - removal of sys/scanio.h
Sebastien Marie wrote: > On Mon, May 29, 2017 at 06:10:51AM -0600, Ted Unangst wrote: > > CVSROOT:/cvs > > Module name:src > > Changes by: t...@cvs.openbsd.org2017/05/29 06:10:51 > > > > Removed files: > > sys/sys: scanio.h > > > > Log message: > > scanner support died some time ago, the header can be removed too. > > a gift from miod > > > > The remove of sys/scanio.h broke usr.bin/kdump. yes, sorry, it's fixed now.
Re: CVS: cvs.openbsd.org: src - removal of sys/scanio.h
On Mon, May 29, 2017 at 06:10:51AM -0600, Ted Unangst wrote: > CVSROOT: /cvs > Module name: src > Changes by: t...@cvs.openbsd.org2017/05/29 06:10:51 > > Removed files: > sys/sys: scanio.h > > Log message: > scanner support died some time ago, the header can be removed too. > a gift from miod > The remove of sys/scanio.h broke usr.bin/kdump. Below a diff to unbreak it. Thanks. -- Sebastien Marie Index: usr.bin/kdump/Makefile === RCS file: /cvs/src/usr.bin/kdump/Makefile,v retrieving revision 1.33 diff -u -p -r1.33 Makefile --- usr.bin/kdump/Makefile 25 Apr 2016 19:18:41 - 1.33 +++ usr.bin/kdump/Makefile 29 May 2017 13:39:52 - @@ -43,7 +43,6 @@ ioctl.c: ${.CURDIR}/Makefile ${.CURDIR}/ ${SYS_DIR}/sys/mtio.h \ ${SYS_DIR}/sys/pciio.h \ ${SYS_DIR}/sys/radioio.h \ - ${SYS_DIR}/sys/scanio.h \ ${SYS_DIR}/sys/scsiio.h \ ${SYS_DIR}/sys/sockio.h \ ${SYS_DIR}/sys/videoio.h \ Index: usr.bin/kdump/mkioctls === RCS file: /cvs/src/usr.bin/kdump/mkioctls,v retrieving revision 1.37 diff -u -p -r1.37 mkioctls --- usr.bin/kdump/mkioctls 25 Apr 2016 19:18:41 - 1.37 +++ usr.bin/kdump/mkioctls 29 May 2017 13:39:52 - @@ -73,7 +73,6 @@ BEGIN { print "#include " print "#include " print "#include " - print "#include " print "#include " print "#include " print "#include "
Re: CVS: cvs.openbsd.org: src (fwd)
> Date: Sun, 16 Oct 2016 13:58:17 -0700 > From: Philip Guenther > > Should have sent this to tech... Yes please! But by terminating the loop early, I you'll miss the case where the symbol shadows both a function and a global variable. > -- Forwarded message -- > Date: Sun, 16 Oct 2016 13:57:42 -0700 > From: Philip Guenther > To: Jeremie Courreges-Anglas > Cc: source-chan...@openbsd.org > Subject: Re: CVS: cvs.openbsd.org: src > > On Sun, 16 Oct 2016, Jeremie Courreges-Anglas wrote: > > CVSROOT:/cvs > > Module name:src > > Changes by: j...@cvs.openbsd.org2016/10/16 04:40:59 > > > > Modified files: > > usr.sbin/rpc.bootparamd: bootparamd.c > > > > Log message: > > Rename local variable 'err' to 'error', to avoid -Wshadow conflicts with > > err.h > > Ick. I know that newer gcc's have stopped generating shadow warning for > local variables vs global functions, such as this case. Making these > changes just because we have an old gcc is kinda annoying. > > So let's fix that and make our gcc a bit more like new ones. Written > without peeking at the new ones and tested against the .c file at bottom > to verify that it doesn't fail or crash on some weird combo of shadowing. > > oks? > > Philip Guenther > > > Index: c-decl.c > === > RCS file: /data/src/openbsd/src/gnu/gcc/gcc/c-decl.c,v > retrieving revision 1.4 > diff -u -p -r1.4 c-decl.c > --- c-decl.c 10 Sep 2015 10:56:35 - 1.4 > +++ c-decl.c 16 Oct 2016 20:50:10 - > @@ -1946,8 +1946,19 @@ warn_if_shadowing (tree new_decl) > warning (OPT_Wshadow, "declaration of %q+D shadows a parameter", > new_decl); > else if (DECL_FILE_SCOPE_P (old_decl)) > - warning (OPT_Wshadow, "declaration of %q+D shadows a global " > -"declaration", new_decl); > + { > + /* Don't warn about shadowing a global function unless the local > +variable is a pointer to a function */ > + if (TREE_CODE (old_decl) == FUNCTION_DECL > + && TREE_CODE (new_decl) != FUNCTION_DECL > + && (TREE_CODE (new_decl) != VAR_DECL > + || !POINTER_TYPE_P (TREE_TYPE (new_decl)) > + || TREE_CODE (TREE_TYPE (TREE_TYPE (new_decl))) > +!= FUNCTION_TYPE)) > + break; > + warning (OPT_Wshadow, "declaration of %q+D shadows a global " > + "declaration", new_decl); > + } > else if (TREE_CODE (old_decl) == FUNCTION_DECL >&& DECL_BUILT_IN (old_decl)) > { > > > > -- test-shadow.c --- > int var; > void func(void); > void (*func_ptr)(void) = func; > enum { ENUM }; > typedef int type; > > void > test_var(int var_arg, void (*func_ptr_arg)(void)) > { > int var; > int func; > int func_ptr; > int ENUM; > int type; > { > int var_arg; > int func_ptr_arg; > } > } > > void > test_func_ptr(int var_arg, void (*func_ptr_arg)(void)) > { > void (*var)(void); > void (*func)(void); > void (*func_ptr)(void); > void (*ENUM)(void); > void (*type)(void); > { > void (*var_arg)(void); > void (*func_ptr_arg)(void); > } > } > > void > test_int_ptr(int var_arg, void (*func_ptr_arg)(void)) > { > int *var; > int *func; > int *func_ptr; > int *ENUM; > int *type; > { > int *var_arg; > int *func_ptr_arg; > } > } > > void > test_enum(int var_arg, void (*func_ptr_arg)(void)) > { > enum { var }; > enum { func }; > enum { func_ptr }; > enum { ENUM }; > enum { type }; > { > enum { var_arg }; > enum { func_ptr_arg }; > } > } > > void > test_type(int var_arg, void (*func_ptr_arg)(void)) > { > typedef int var; > typedef int func; > typedef int func_ptr; > typedef int ENUM; > typedef int type; > { > typedef int var_arg; > typedef int func_ptr_arg; > } > } > > void > test_var_param( > int var, > int func, > int func_ptr, > int ENUM, > int type) > { > } > > void > test_func_ptr_param( > void (*var)(void), > void (*func)(void), > void (*func_ptr)(void), > void (*ENUM)(void), > void (*type)(void)) > { > } > >
CVS: cvs.openbsd.org: src (fwd)
Should have sent this to tech... -- Forwarded message -- Date: Sun, 16 Oct 2016 13:57:42 -0700 From: Philip Guenther To: Jeremie Courreges-Anglas Cc: source-chan...@openbsd.org Subject: Re: CVS: cvs.openbsd.org: src On Sun, 16 Oct 2016, Jeremie Courreges-Anglas wrote: > CVSROOT: /cvs > Module name: src > Changes by: j...@cvs.openbsd.org2016/10/16 04:40:59 > > Modified files: > usr.sbin/rpc.bootparamd: bootparamd.c > > Log message: > Rename local variable 'err' to 'error', to avoid -Wshadow conflicts with err.h Ick. I know that newer gcc's have stopped generating shadow warning for local variables vs global functions, such as this case. Making these changes just because we have an old gcc is kinda annoying. So let's fix that and make our gcc a bit more like new ones. Written without peeking at the new ones and tested against the .c file at bottom to verify that it doesn't fail or crash on some weird combo of shadowing. oks? Philip Guenther Index: c-decl.c === RCS file: /data/src/openbsd/src/gnu/gcc/gcc/c-decl.c,v retrieving revision 1.4 diff -u -p -r1.4 c-decl.c --- c-decl.c10 Sep 2015 10:56:35 - 1.4 +++ c-decl.c16 Oct 2016 20:50:10 - @@ -1946,8 +1946,19 @@ warn_if_shadowing (tree new_decl) warning (OPT_Wshadow, "declaration of %q+D shadows a parameter", new_decl); else if (DECL_FILE_SCOPE_P (old_decl)) - warning (OPT_Wshadow, "declaration of %q+D shadows a global " - "declaration", new_decl); + { + /* Don't warn about shadowing a global function unless the local + variable is a pointer to a function */ + if (TREE_CODE (old_decl) == FUNCTION_DECL + && TREE_CODE (new_decl) != FUNCTION_DECL + && (TREE_CODE (new_decl) != VAR_DECL + || !POINTER_TYPE_P (TREE_TYPE (new_decl)) + || TREE_CODE (TREE_TYPE (TREE_TYPE (new_decl))) + != FUNCTION_TYPE)) + break; + warning (OPT_Wshadow, "declaration of %q+D shadows a global " +"declaration", new_decl); + } else if (TREE_CODE (old_decl) == FUNCTION_DECL && DECL_BUILT_IN (old_decl)) { -- test-shadow.c --- int var; void func(void); void (*func_ptr)(void) = func; enum { ENUM }; typedef int type; void test_var(int var_arg, void (*func_ptr_arg)(void)) { int var; int func; int func_ptr; int ENUM; int type; { int var_arg; int func_ptr_arg; } } void test_func_ptr(int var_arg, void (*func_ptr_arg)(void)) { void (*var)(void); void (*func)(void); void (*func_ptr)(void); void (*ENUM)(void); void (*type)(void); { void (*var_arg)(void); void (*func_ptr_arg)(void); } } void test_int_ptr(int var_arg, void (*func_ptr_arg)(void)) { int *var; int *func; int *func_ptr; int *ENUM; int *type; { int *var_arg; int *func_ptr_arg; } } void test_enum(int var_arg, void (*func_ptr_arg)(void)) { enum { var }; enum { func }; enum { func_ptr }; enum { ENUM }; enum { type }; { enum { var_arg }; enum { func_ptr_arg }; } } void test_type(int var_arg, void (*func_ptr_arg)(void)) { typedef int var; typedef int func; typedef int func_ptr; typedef int ENUM; typedef int type; { typedef int var_arg; typedef int func_ptr_arg; } } void test_var_param( int var, int func, int func_ptr, int ENUM, int type) { } void test_func_ptr_param( void (*var)(void), void (*func)(void), void (*func_ptr)(void), void (*ENUM)(void), void (*type)(void)) { }
Re: CVS: cvs.openbsd.org: src
On August 10, 2016 11:52:29 AM GMT+02:00, Sebastien Marie wrote: >On Tue, Aug 09, 2016 at 03:24:32PM -0600, Alexander Hall wrote: >> CVSROOT: /cvs >> Module name: src >> Changes by: ha...@cvs.openbsd.org 2016/08/09 15:24:32 >> >> Modified files: >> etc: Makefile >> etc/mtree : special >> Removed files: >> etc: csh.cshrc csh.login csh.logout >> >> Log message: >> remove pointless csh placeholder files from /etc >> >> ok jung@ (some time ago) phessler@ >> > >does /etc/changelist should be cleared too ? I am unsure as it could >also make sens to keep csh.{cshrc,login,logout} entries in it. I think it makes sense to keep it, like we do for other initially non-existing files in there. /Alexander > >thanks.
Re: CVS: cvs.openbsd.org: src
On Tue, Aug 09, 2016 at 03:24:32PM -0600, Alexander Hall wrote: > CVSROOT: /cvs > Module name: src > Changes by: ha...@cvs.openbsd.org 2016/08/09 15:24:32 > > Modified files: > etc: Makefile > etc/mtree : special > Removed files: > etc: csh.cshrc csh.login csh.logout > > Log message: > remove pointless csh placeholder files from /etc > > ok jung@ (some time ago) phessler@ > does /etc/changelist should be cleared too ? I am unsure as it could also make sens to keep csh.{cshrc,login,logout} entries in it. thanks. -- Sebastien Marie Index: changelist === RCS file: /cvs/src/etc/changelist,v retrieving revision 1.112 diff -u -p -r1.112 changelist --- changelist 20 Apr 2016 12:41:30 - 1.112 +++ changelist 10 Aug 2016 09:49:59 - @@ -16,9 +16,6 @@ /etc/changelist /etc/chio.conf /etc/crontab -/etc/csh.cshrc -/etc/csh.login -/etc/csh.logout /etc/daily /etc/daily.local /etc/defaultdomain
Fwd: CVS: cvs.openbsd.org: src
For those who don't following source-changes but build -current from source... I just committed a major ABI change; threaded binaries from before late-March will no longer work and you need to follow the instructions I just committed to the FAQ's "following -current" page! This is probably a good time to wait for a snapshot and install that. That'll give ports builds a chance to catch up too. :-) Philip Guenther -- Forwarded message -- From: Philip Guenther Date: Sat, May 7, 2016 at 12:05 PM Subject: CVS: cvs.openbsd.org: src To: source-chan...@openbsd.org CVSROOT:/cvs Module name:src Changes by: guent...@cvs.openbsd.org2016/05/07 13:05:24 Modified files: Log message: Use a Thread Information Block in both single and multi-threaded programs. This stores errno, the cancelation flags, and related bits for each thread and is allocated by ld.so or libc.a. This is an ABI break from 5.9-stable! Make libpthread dlopen'able by moving the cancelation wrappers into libc and doing locking and fork/errno handling via callbacks that libpthread registers when it first initializes. 'errno' *must* be declared via now! Clean up libpthread's symbol exports like libc. On powerpc, offset the TIB/TCB/TLS data from the register per the ELF spec. Testing by various, particularly sthen@ and patrick@ ok kettenis@
Re: pppd and ioctl(TIOCSETD) (was: CVS: cvs.openbsd.org: src)
On Tue, 22 Dec 2015, David Coppa wrote: > I suspect this broke my 3G connection: Oops. Sorry. Try this diff (already committed): --- sys/kern/tty_conf.c +++ sys/kern/tty_conf.c @@ -42,6 +42,11 @@ #include #include +#include "ppp.h" +#include "nmea.h" +#include "msts.h" +#include "endrun.h" + #definettynodisc ((int (*)(dev_t, struct tty *, struct proc *))enodev) #definettyerrclose ((int (*)(struct tty *, int flags, struct proc *))enodev) #definettyerrio ((int (*)(struct tty *, struct uio *, int))enodev)
pppd and ioctl(TIOCSETD) (was: CVS: cvs.openbsd.org: src)
On Mon, 21 Dec 2015, Stefan Fritsch wrote: > CVSROOT: /cvs > Module name: src > Changes by: s...@cvs.openbsd.org2015/12/21 14:49:03 > > Modified files: > sys/kern : tty_conf.c tty_endrun.c tty_msts.c tty_nmea.c > sys/net: ppp_tty.c > sys/sys: tty.h > > Log message: > Move ppp, nmea, endrun, and msts prototypes to tty.h > > Fix inconsistent arguments for pppopen/pppclose/pppstart. > Use passed in argument p in pppopen instead of curproc. > > "Looks good to me" deraadt@ I suspect this broke my 3G connection: Dec 22 13:22:51 t420 chat[16397]: send (ATDT*99***1#^M) Dec 22 13:22:52 t420 chat[16397]: timeout set to 30 seconds Dec 22 13:22:52 t420 chat[16397]: expect (CONNECT) Dec 22 13:22:52 t420 chat[16397]: ^M Dec 22 13:22:52 t420 chat[16397]: ^M Dec 22 13:22:52 t420 chat[16397]: CONNECT Dec 22 13:22:52 t420 chat[16397]: -- got it Dec 22 13:22:52 t420 chat[16397]: send (\\d) Dec 22 13:22:53 t420 pppd[12116]: Serial connection established. Dec 22 13:22:54 t420 pppd[12116]: ioctl(TIOCSETD): Operation not supported by device I start this connection using: /usr/sbin/pppd file /etc/ppp/peers/postemobile And it always worked w/o problems until now. It's a -current from ~1 hour ago: $ sysctl kern.version kern.version=OpenBSD 5.9-beta (GENERIC.MP) #0: Tue Dec 22 12:08:24 CET 2015 dco...@t420.bsdgeek.it:/usr/src/sys/arch/amd64/compile/GENERIC.MP Ideas? TIA! David
Re: tail -n +NUM broken [Was CVS: cvs.openbsd.org: src]
Ted Unangst wrote: > > > Modified files: > > > usr.bin/tail : extern.h forward.c misc.c read.c reverse.c > > >tail.c > > > > > > Log message: > > > another try to allow tailing multiple files. maybe it works? > > > commit now to allow people to test. > > > > I just updated to very latest snapshot and tail with plus num doesn't > > work: > > > > OpenBSD 5.8-current (GENERIC.MP) #1636: Thu Nov 19 14:05:34 MST 2015 > > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > > > > $ ps auxwww | tail -n +3 | wc -l > >0 > > (Everyone else: Please report all tail bugs to either tech or bugs.) > > Definitely a regression here, the rewrite of forward() is apparently not > counting the offset correctly. So the problem is that after the for loop over files, we have: (void)fflush(stdout); if (!fflag || kq < 0) return; That code used to live a little farther down, in the loop that copied data, and didn't break until after we hit EOF. I think it may make sense to do the copying in the file loop instead. This handles one case, but I think there are more. We also need to reset the offset for each file, or later ones don't print anything. Index: forward.c === RCS file: /cvs/src/usr.bin/tail/forward.c,v retrieving revision 1.27 diff -u -p -r1.27 forward.c --- forward.c 19 Nov 2015 17:50:04 - 1.27 +++ forward.c 20 Nov 2015 00:25:17 - @@ -52,6 +52,16 @@ static const struct timespec *tfreopen(s static int kq = -1; +static void +printtail(FILE *fp) +{ + int ch; + + while (!feof(fp) && (ch = getc(fp)) != EOF) + if (putchar(ch) == EOF) + oerr(); +} + /* * forward -- display the file, from an offset, forward. * @@ -75,7 +85,7 @@ static int kq = -1; * NOREG cyclically read lines into a wrap-around array of buffers */ void -forward(struct tailfile *tf, int nfiles, enum STYLE style, off_t off) +forward(struct tailfile *tf, int nfiles, enum STYLE style, off_t origoff) { int ch; struct tailfile *ctf, *ltf; @@ -91,6 +101,7 @@ forward(struct tailfile *tf, int nfiles, warn("kqueue"); for (i = 0; i < nfiles; i++) { + off_t off = origoff; if (nfiles > 1) printfname(tf[i].fname); @@ -125,8 +136,11 @@ forward(struct tailfile *tf, int nfiles, } break; } - if (ch == '\n' && !--off) + if (ch == '\n' && !--off) { + if (!fflag) + printtail(tf[i].fp); break; + } } break; case RBYTES:
Re: tail -n +NUM broken [Was CVS: cvs.openbsd.org: src]
> > Modified files: > > usr.bin/tail : extern.h forward.c misc.c read.c reverse.c > > tail.c > > > > Log message: > > another try to allow tailing multiple files. maybe it works? > > commit now to allow people to test. > > I just updated to very latest snapshot and tail with plus num doesn't > work: > > OpenBSD 5.8-current (GENERIC.MP) #1636: Thu Nov 19 14:05:34 MST 2015 > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > > $ ps auxwww | tail -n +3 | wc -l >0 (Everyone else: Please report all tail bugs to either tech or bugs.) Definitely a regression here, the rewrite of forward() is apparently not counting the offset correctly.
Re: CVS: cvs.openbsd.org: src
On Wed, Sep 30, 2015 at 06:07:54PM +0200, Joerg Jung wrote: > On Wed, Sep 30, 2015 at 05:13:31PM +0200, Martijn van Duren wrote: > > On 09/30/15 14:15, Joerg Jung wrote: > > > Thanks! Although it does add about 5-10 seconds to my boot-time, waiting > > primarily for the temperature sensors. > > Yes, they are probed during startup. That probing is slow, as the SMC is > slow. This needs some rethinking/polishing, moving the probing to a > later point. tl;dr: please find below a refactoring diff that fixes this. The -current asmc(4) code suffers from two problems: I. The initial sensors read may take several seconds. II. The update of the sensor values tsleep()s excessively within the sensor task. The following suggestions and hints to fix these timing issues were provided to me: 1. mpi@ and Theo recommended not to tsleep() within the sensor task, mpi@ says: "Sleeping in the sensor thread might add latency to others sensors discovery." -> This is totally right, and matches II. problem statement above. 2. Theo suggested an async model using the sensor task (similar to ugold(4)), something like: sensor task comes, some command is issued, task returns, comes back later, reads result, next sensor, ... -> This sounds promising in theory, but I played a bit with this approach and it seems to be impossible to implement with asmc(4). -> The problem is that SMC requires several read() and write() operations for one command/sensor read, all of them acknowledged with waiting for the correct status, the protocol looks like this: 1. write command, wait for status "accepted", 2. write key, 4 single byte writes, each wait for status "accepted" 3. write data length expected to read, wait for status "accepted" 4. finally read data values, single byte reads each waiting for status "ready for read" Step 1-3 might take in the seldom worst case several seconds (retries + timeout). I can not see an easy way to do this async and step-by-step as waiting too long will result in "comm collision" errors or might take ages, as it reads values from up to 100 sensors using these steps. So, I came to the conclusion that solving I.+II. really requires an additional thread. 3. uebayasi@ suggested to look into sys/dev/ipmi.c, which uses a kthread to initially read all sensor values from a slow serial bus. -> This was a good hint, related ipmi code is simple and it can be easily done in the same way in asmc(4), but according to a quick grep it is the ONLY sensor driver which does it in this way, and moreover: 4. tedu@ says: "oh, don't make your own thread unless you really need the loop. you can create your own taskq as well" -> Makes sense, a quick grep revealed, that (again) ONLY one single driver does it like this: viomb(4), again using an easy pattern to copy into asmc(4). So, finally the refactoring diff below follows tedu's suggestion and uses an own taskq to solve I.+II. Tests, comments and OKs are welcome. Thanks, Regards, Joerg Index: asmc.c === RCS file: /cvs/src/sys/dev/isa/asmc.c,v retrieving revision 1.11 diff -u -p -r1.11 asmc.c --- asmc.c 15 Oct 2015 01:14:33 - 1.11 +++ asmc.c 23 Oct 2015 13:24:34 - @@ -23,6 +23,7 @@ #include #include #include +#include #include #include @@ -62,7 +63,13 @@ struct asmc_softc { bus_space_handle_t sc_ioh; struct asmc_prod*sc_prod; - uint8_t sc_lightlen; /* light data len */ + uint8_t sc_init; /* initialization done? */ + uint8_t sc_nfans; /* number of fans */ + uint8_t sc_lightlen; /* light data len */ + + struct taskq*sc_taskq; + struct task sc_task_init; + struct task sc_task_refresh; struct ksensor sc_sensor_temp[ASMC_MAXTEMP]; struct ksensor sc_sensor_fan[ASMC_MAXFAN]; @@ -72,7 +79,12 @@ struct asmc_softc { struct sensor_task *sc_sensor_task; }; -intasmc_init(struct asmc_softc *); +uint8_tasmc_status(struct asmc_softc *); +intasmc_try(struct asmc_softc *, int, const char *, uint8_t *, uint8_t); +void asmc_kbdled(struct asmc_softc *, uint8_t); + +void asmc_init(void *); +void asmc_refresh(void *); void asmc_update(void *); intasmc_match(struct device *, void *, void *); @@ -243,6 +255,8 @@ asmc_attach(struct device *parent, struc { struct asmc_softc *sc = (struct asmc_softc *)self; struct isa_attach_args *ia = aux; + uint8_t buf[6]; + int i; if (bus_space_map(ia->ia_iot, ia->ia_iobase, ia->ia_iosize, 0, &sc->sc_ioh)) { @@ -251,23 +265,64 @@ asmc_attach(struct device *parent,
Re: CVS: cvs.openbsd.org: src
On Sun, Oct 04, 2015 at 09:20:06PM +0200, Mark Kettenis wrote: > > Here is what I get on the Macmini 1,1 now: > > asmc0 at isa0 port 0x300/32 > asmc0: rev 1.3f503, 137 keys, 5 temperatures, 1 fan, 0 lights, kbdled Thanks for testing! I think printing "0 lights" is not very useful, so I will tweak the output a bit further. > hw.sensors.cpu0.temp0=54.00 degC > hw.sensors.asmc0.temp0=56.00 degC (TC0D CPU0 Die Core) > hw.sensors.asmc0.temp1=51.00 degC (TC0H CPU0 Heatsink) > hw.sensors.asmc0.temp2=55.00 degC (TC0P CPU0 Proximity) > hw.sensors.asmc0.temp3=54.00 degC (TN0P Northbridge Proximity) > hw.sensors.asmc0.temp4=55.00 degC (TN1P Northbridge 2) > hw.sensors.asmc0.fan0=1538 RPM (Master) > > To answer your earlier question: I think having asmc(4) provide the > Die Core temperature is good even though it is redundant. This allows > us to verify that cpu(4) is providing the right temperature/ Ok, fair enough.
Re: CVS: cvs.openbsd.org: src
> Date: Sun, 4 Oct 2015 14:10:18 +0200 > From: Joerg Jung > > On Wed, Sep 30, 2015 at 06:07:54PM +0200, Joerg Jung wrote: > > On Wed, Sep 30, 2015 at 05:13:31PM +0200, Martijn van Duren wrote: > > > > > > What I find somewhat strange is that although the dmesg says it has "2 > > > lights", it only shows one illuminance sensor in my sysctl. > > > > This is expected. In newer models the SMC shows up with two sensor keys, > > but only *one* provides useful/valid values (with 10bit instead of 6bit > > in older models). I probably should remove the number from the initial > > message to avoid confusion. > > I committed a fix to -current, so that it should show now the correct > number of light sensors on initialization. Here is what I get on the Macmini 1,1 now: asmc0 at isa0 port 0x300/32 asmc0: rev 1.3f503, 137 keys, 5 temperatures, 1 fan, 0 lights, kbdled hw.sensors.cpu0.temp0=54.00 degC hw.sensors.asmc0.temp0=56.00 degC (TC0D CPU0 Die Core) hw.sensors.asmc0.temp1=51.00 degC (TC0H CPU0 Heatsink) hw.sensors.asmc0.temp2=55.00 degC (TC0P CPU0 Proximity) hw.sensors.asmc0.temp3=54.00 degC (TN0P Northbridge Proximity) hw.sensors.asmc0.temp4=55.00 degC (TN1P Northbridge 2) hw.sensors.asmc0.fan0=1538 RPM (Master) To answer your earlier question: I think having asmc(4) provide the Die Core temperature is good even though it is redundant. This allows us to verify that cpu(4) is providing the right temperature/
Re: CVS: cvs.openbsd.org: src
On Wed, Sep 30, 2015 at 06:07:54PM +0200, Joerg Jung wrote: > On Wed, Sep 30, 2015 at 05:13:31PM +0200, Martijn van Duren wrote: > > > > What I find somewhat strange is that although the dmesg says it has "2 > > lights", it only shows one illuminance sensor in my sysctl. > > This is expected. In newer models the SMC shows up with two sensor keys, > but only *one* provides useful/valid values (with 10bit instead of 6bit > in older models). I probably should remove the number from the initial > message to avoid confusion. I committed a fix to -current, so that it should show now the correct number of light sensors on initialization.
Re: CVS: cvs.openbsd.org: src
On Sat, Oct 3, 2015 at 2:12 AM, Vadim Zhukov wrote: > CVSROOT:/cvs > Module name:src > Changes by: z...@cvs.openbsd.org2015/10/03 03:12:39 > > Modified files: > usr.bin/kdump : kdump.c > > Log message: > Fix wrong cast. > > This one should be an unsigned long in theory, but the formatter function > argument we're printing from is already an int (being casted from register_t > at the formatter call time). So lets fix one bug at a time. To expand a bit on why the use of int vs long is not a problem here: the only thing using long gains is 32 more bits on LP64 archs. That's critical for pointers and buffer sizes, of course, where they really are limited to 32bit on ILP32 archs, but for enumeration and bitsets/flags like ioctl's 'request' argument, an enumeration value or flag bit >=2^32 would make that value impossible to use on ILP32 archs. Perhaps some day someone will come up with an ioctl() request that is legitimately specific to LP64 archs and can thus be safely assigned a request value >=2^32, but I don't foresee that and even then we would need to be running out of ioctl requests <2^32 to make it worth it. Until then, kdump can stick with ints for enumerations and flags, perhaps serve as a compilation check against someone breaking that rule accidentally. If a bitset/flag argument needs to exceed 32bits in an MD way, it should be typed as long long and thus be portably sized. Philip Guenther
Re: CVS: cvs.openbsd.org: src
On Wed, Sep 30, 2015 at 05:13:31PM +0200, Martijn van Duren wrote: > On 09/30/15 14:15, Joerg Jung wrote: > >CVSROOT: /cvs > >Module name: src > >Changes by: j...@cvs.openbsd.org2015/09/30 06:15:12 > > > >Modified files: > > share/man/man4 : isa.4 > > sys/arch/amd64/conf: GENERIC > > sys/arch/i386/conf: GENERIC > > sys/dev/isa: files.isa > >Added files: > > share/man/man4 : asmc.4 > > sys/dev/isa: asmc.c > > > >Log message: > >add a (disabled) driver for the Apple System Management Controller (SMC) as > >found in Apple Intel based devices > > > >"go at it" deraadt@ > > > Just backported this driver to my 5.7-stable system at work (yes, I like to > live dangerous from time to time) and the driver seems to work properly. :) > Thanks! Although it does add about 5-10 seconds to my boot-time, waiting > primarily for the temperature sensors. Yes, they are probed during startup. That probing is slow, as the SMC is slow. This needs some rethinking/polishing, moving the probing to a later point. > See sysctl and dmesg output below. > > What I find somewhat strange is that although the dmesg says it has "2 > lights", it only shows one illuminance sensor in my sysctl. This is expected. In newer models the SMC shows up with two sensor keys, but only *one* provides useful/valid values (with 10bit instead of 6bit in older models). I probably should remove the number from the initial message to avoid confusion. > This does > somewhat seems to fit with the right side of my screen being marginally > darker then the left side of my screen. Although this is something that > doesn't bother me in the least it seem like something that might be worth > mentioning. > > $ sysctl | grep asmc > hw.sensors.asmc0.temp0=30.00 degC (TA0P Ambient) > hw.sensors.asmc0.temp1=51.00 degC (TC0H CPU0 Heatsink) > hw.sensors.asmc0.temp2=58.00 degC (TC0P CPU0 Proximity) > hw.sensors.asmc0.temp3=78.00 degC (TG0D GPU0 Diode) > hw.sensors.asmc0.temp4=73.00 degC (TG0H GPU0 Heatsink) > hw.sensors.asmc0.temp5=49.00 degC (TL0P LCD Proximity) > hw.sensors.asmc0.temp6=51.00 degC (TO0P Optical Drive) > hw.sensors.asmc0.temp7=67.00 degC (Tm0P Memory Controller) > hw.sensors.asmc0.fan0=997 RPM (ODD) > hw.sensors.asmc0.fan1=1099 RPM (HDD) > hw.sensors.asmc0.fan2=1198 RPM (CPU) > hw.sensors.asmc0.illuminance0=4078.00 lx (left) > $ > > OpenBSD 5.7-stable (ASMC) #1: Wed Sep 30 16:46:45 CEST 2015 > mart...@martijn.office.rootnet.nl:/usr/src/sys/arch/amd64/compile/ASMC > RTC BIOS diagnostic error d1 > real mem = 4253237248 (4056MB) > avail mem = 4136079360 (3944MB) > mpath0 at root > scsibus0 at mpath0: 256 targets > mainbus0 at root > bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xe (61 entries) > bios0: vendor Apple Inc. version "IM121.88Z.0047.B1F.1201241648" date > 01/24/12 > bios0: Apple Inc. iMac12,1 > acpi0 at bios0: rev 2 > acpi0: sleep states S0 S3 S4 S5 > acpi0: tables DSDT FACP HPET APIC SBST ECDT SSDT SSDT SSDT SSDT SSDT SSDT > SSDT SSDT MCFG SSDT SSDT SSDT > acpi0: wakeup devices P0P2(S4) GFX0(S4) EC__(S4) HDEF(S4) GIGE(S4) RP01(S4) > ARPT(S4) RP02(S4) RP03(S4) RP05(S4) EHC1(S3) EHC2(S3) > acpitimer0 at acpi0: 3579545 Hz, 24 bits > acpihpet0 at acpi0: 14318179 Hz > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat > cpu0 at mainbus0: apid 0 (boot processor) > cpu0: Intel(R) Core(TM) i5-2400S CPU @ 2.50GHz, 2500.36 MHz > cpu0: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC > cpu0: 256KB 64b/line 8-way L2 cache > cpu0: smt 0, core 0, package 0 > mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges > cpu0: apic clock running at 100MHz > cpu0: mwait min=64, max=64, C-substates=0.2.1.1.0, IBE > cpu1 at mainbus0: apid 2 (application processor) > cpu1: Intel(R) Core(TM) i5-2400S CPU @ 2.50GHz, 2500.03 MHz > cpu1: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC > cpu1: 256KB 64b/line 8-way L2 cache > cpu1: smt 0, core 1, package 0 > cpu2 at mainbus0: apid 4 (application processor) > cpu2: Intel(R) Core(TM) i5-2400S CPU @ 2.50GHz, 2500.03 MHz > cpu2: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC > cpu2: 256KB 64b/line 8-way L2 cache > cpu2: smt 0, core 2, package 0 > cpu3 at mainbus0: apid 6 (application processor) > cpu3: Intel(R) Core(TM) i5-2400S CPU @ 2.50GHz, 2500.03 MHz > cpu3: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA
Re: CVS: cvs.openbsd.org: src
On 09/30/15 14:15, Joerg Jung wrote: CVSROOT:/cvs Module name:src Changes by: j...@cvs.openbsd.org2015/09/30 06:15:12 Modified files: share/man/man4 : isa.4 sys/arch/amd64/conf: GENERIC sys/arch/i386/conf: GENERIC sys/dev/isa: files.isa Added files: share/man/man4 : asmc.4 sys/dev/isa: asmc.c Log message: add a (disabled) driver for the Apple System Management Controller (SMC) as found in Apple Intel based devices "go at it" deraadt@ Just backported this driver to my 5.7-stable system at work (yes, I like to live dangerous from time to time) and the driver seems to work properly. Thanks! Although it does add about 5-10 seconds to my boot-time, waiting primarily for the temperature sensors. See sysctl and dmesg output below. What I find somewhat strange is that although the dmesg says it has "2 lights", it only shows one illuminance sensor in my sysctl. This does somewhat seems to fit with the right side of my screen being marginally darker then the left side of my screen. Although this is something that doesn't bother me in the least it seem like something that might be worth mentioning. $ sysctl | grep asmc hw.sensors.asmc0.temp0=30.00 degC (TA0P Ambient) hw.sensors.asmc0.temp1=51.00 degC (TC0H CPU0 Heatsink) hw.sensors.asmc0.temp2=58.00 degC (TC0P CPU0 Proximity) hw.sensors.asmc0.temp3=78.00 degC (TG0D GPU0 Diode) hw.sensors.asmc0.temp4=73.00 degC (TG0H GPU0 Heatsink) hw.sensors.asmc0.temp5=49.00 degC (TL0P LCD Proximity) hw.sensors.asmc0.temp6=51.00 degC (TO0P Optical Drive) hw.sensors.asmc0.temp7=67.00 degC (Tm0P Memory Controller) hw.sensors.asmc0.fan0=997 RPM (ODD) hw.sensors.asmc0.fan1=1099 RPM (HDD) hw.sensors.asmc0.fan2=1198 RPM (CPU) hw.sensors.asmc0.illuminance0=4078.00 lx (left) $ OpenBSD 5.7-stable (ASMC) #1: Wed Sep 30 16:46:45 CEST 2015 mart...@martijn.office.rootnet.nl:/usr/src/sys/arch/amd64/compile/ASMC RTC BIOS diagnostic error d1 real mem = 4253237248 (4056MB) avail mem = 4136079360 (3944MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xe (61 entries) bios0: vendor Apple Inc. version "IM121.88Z.0047.B1F.1201241648" date 01/24/12 bios0: Apple Inc. iMac12,1 acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP HPET APIC SBST ECDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT MCFG SSDT SSDT SSDT acpi0: wakeup devices P0P2(S4) GFX0(S4) EC__(S4) HDEF(S4) GIGE(S4) RP01(S4) ARPT(S4) RP02(S4) RP03(S4) RP05(S4) EHC1(S3) EHC2(S3) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpihpet0 at acpi0: 14318179 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i5-2400S CPU @ 2.50GHz, 2500.36 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC cpu0: 256KB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 100MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.1.0, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Core(TM) i5-2400S CPU @ 2.50GHz, 2500.03 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 4 (application processor) cpu2: Intel(R) Core(TM) i5-2400S CPU @ 2.50GHz, 2500.03 MHz cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC cpu2: 256KB 64b/line 8-way L2 cache cpu2: smt 0, core 2, package 0 cpu3 at mainbus0: apid 6 (application processor) cpu3: Intel(R) Core(TM) i5-2400S CPU @ 2.50GHz, 2500.03 MHz cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC cpu3: 256KB 64b/line 8-way L2 cache cpu3: smt 0, core 3, package 0 ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins ioapic0: misconfigured as apic 0, remapped to apid 2 acpiec0 at acpi0 acpimcfg0 at acpi0 addr 0xe000, bus 0-155 acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 1 (P0P2) acpiprt2 at acpi0: bus 2 (RP01) acpiprt3 at acpi0: bus 3 (RP02) acpiprt4 at acpi0: bus 4 (RP03) acpiprt5 at acpi0:
Fwd: CVS: cvs.openbsd.org: src
A heads up on this commit: if you're following -current and using any perl modules that pull in threaded libraries from packages, such as mysql/mariadb integration via DBD::mysql, then you may want to wait the day or so until the ports package builds have caught up with the change. The perl in base built against libpthread.19.0 cannot load the mysql.so shared object linked against libpthread.18.1 Philip Guenther -- Forwarded message -- From: Philip Guenther Date: Mon, Apr 6, 2015 at 6:27 PM Subject: CVS: cvs.openbsd.org: src To: source-chan...@cvs.openbsd.org CVSROOT:/cvs Module name:src Changes by: guent...@cvs.openbsd.org2015/04/06 19:27:07 Modified files: lib/csu: crtbegin.c crtbeginS.c lib/libc : shlib_version lib/libc/arch/alpha: SYS.h lib/libc/arch/alpha/sys: fork.S lib/libc/arch/amd64: SYS.h lib/libc/arch/amd64/sys: fork.S lib/libc/arch/arm: SYS.h lib/libc/arch/arm/sys: fork.S lib/libc/arch/hppa: SYS.h lib/libc/arch/hppa/sys: fork.S lib/libc/arch/hppa64: SYS.h lib/libc/arch/hppa64/sys: fork.S lib/libc/arch/i386: SYS.h lib/libc/arch/i386/sys: fork.S lib/libc/arch/m88k: SYS.h lib/libc/arch/m88k/sys: fork.S lib/libc/arch/mips64: SYS.h lib/libc/arch/mips64/sys: fork.S lib/libc/arch/powerpc: SYS.h lib/libc/arch/powerpc/sys: fork.S lib/libc/arch/sh: SYS.h lib/libc/arch/sh/sys: fork.S lib/libc/arch/sparc: SYS.h lib/libc/arch/sparc/sys: fork.S lib/libc/arch/sparc64: SYS.h lib/libc/arch/sparc64/sys: fork.S lib/libc/arch/vax: SYS.h lib/libc/arch/vax/sys: fork.S lib/libc/include: thread_private.h lib/libc/stdlib: atexit.c lib/libc/sys : Makefile.inc lib/libc/thread: Makefile.inc unithread_malloc_lock.c lib/librthread : rthread.c rthread_fork.c rthread_libc.c shlib_version regress/lib/csu/callbacks: Makefile regress/lib/csu/callbacks/pthread_atfork: Makefile pthread_atfork_test.c Added files: lib/libc/include: atfork.h lib/libc/sys : w_fork.c lib/libc/thread: atfork.c regress/lib/csu/callbacks/pthread_atfork: expected_child.out expected_parent.out Log message: Make pthread_atfork() track the DSO that called it like atexit() does, unregistering callbacks if the DSO is unloaded. Move the callback handling from libpthread to libc, though libpthread still overrides the inner call to handle locking and thread-library reinitialization. Major version bump for both libc and libpthread. verification that this fixes various ports ajacoutot@ asm assistance miod@; ok millert@ deraadt@
Re: CVS: cvs.openbsd.org: src
The patch below should unbreak make release. On 07/15/14 11:14, Marc Espie wrote: > CVSROOT: /cvs > Module name: src > Changes by: es...@cvs.openbsd.org 2014/07/15 03:14:50 > > Removed files: > etc/mtree : BSD.local.dist > > Log message: > folded back into 4.4BSD.dist > removed to unconfuse devs > > okay aja, theo > Index: etc/Makefile === RCS file: /cvs/src/etc/Makefile,v retrieving revision 1.375 diff -u -p -r1.375 Makefile --- etc/Makefile15 Jul 2014 09:27:04 - 1.375 +++ etc/Makefile15 Jul 2014 13:59:37 - @@ -85,8 +85,6 @@ install-mtree: ${DESTDIR}${MTREEDIR} ${INSTALL} -c -o root -g wheel -m 444 mtree/4.4BSD.dist \ ${DESTDIR}${MTREEDIR} - ${INSTALL} -c -o root -g wheel -m 444 mtree/BSD.local.dist \ - ${DESTDIR}${MTREEDIR} ${INSTALL} -c -o root -g wheel -m 444 mtree/BSD.x11.dist \ ${DESTDIR}${MTREEDIR}
Re: CVS: cvs.openbsd.org: src
> I am however curious about the rational behind this change. Does it > solve any particular problem/risk? > I seldomly use this style in my own scripts when I need to be able to > dynamically determine variables at runtime. So it might be wise to know > what hidden daemons I might be facing. The rc configuration file is becoming a well-managed clean file so that a mix of "tools" and "admins" can manage it. Not quite at the level of master.passwd, which is strictly controlled. Still admin editable, but well formed so that the future automatic tools won't screw up "scripting" in the file.
Re: CVS: cvs.openbsd.org: src
On 07/12/14 14:13, Stuart Henderson wrote: On 2014/07/12 14:04, Martijn van Duren wrote: Hello tech@, I just saw the commit message below. Currently I use the source functionality to determine whether I'm in my home network or not and use it to customize sndiod_flags to redirect sound to my main server. Is there an alternative to dynamically change the rc.conf flags based on my network? Maybe sndiod_flags=NO and start sndiod from /etc/rc.local instead. OK, then I'll have to live with the new limitation. I am however curious about the rational behind this change. Does it solve any particular problem/risk? I seldomly use this style in my own scripts when I need to be able to dynamically determine variables at runtime. So it might be wise to know what hidden daemons I might be facing.
Re: CVS: cvs.openbsd.org: src
On 2014/07/12 14:04, Martijn van Duren wrote: > Hello tech@, > > I just saw the commit message below. > Currently I use the source functionality to determine whether I'm in my home > network or not and use it to customize sndiod_flags to redirect sound to my > main server. > > Is there an alternative to dynamically change the rc.conf flags based on my > network? Maybe sndiod_flags=NO and start sndiod from /etc/rc.local instead.
Re: CVS: cvs.openbsd.org: src
Hello tech@, I just saw the commit message below. Currently I use the source functionality to determine whether I'm in my home network or not and use it to customize sndiod_flags to redirect sound to my main server. Is there an alternative to dynamically change the rc.conf flags based on my network? At the moment my rc.conf.local looks as follow for sndiod: if nc -z 192.168.153.4 11025 2> /dev/null; then sndiod_flags="-f snd@192.168.153.4/0" fi Sincerely, Martijn van Duren On 07/12/14 12:14, Robert Nagy wrote: CVSROOT:/cvs Module name:src Changes by: rob...@cvs.openbsd.org 2014/07/12 04:14:03 Modified files: etc: netstart rc rc.conf etc/rc.d : rc.subr Log message: Make rc.conf a parsed configuration file and stop sourcing it as a shell script. From now on rc.conf has a fixed syntax (key=val) and it is not allowed to add anything to it besides the supported syntax, it all going to be ignored. discussed with and help from deraadt@ and halex@
Re: CVS: cvs.openbsd.org: src
On Fri, Jul 11, 2014 at 4:37 PM, Bob Beck wrote: > The fundamental probelm with this Matthew - is that next time, if we > do this, by the next release we will > be chasing what features we have imported from 1.0.2g and 10.2.z, and > 1.0.2.qq - where does it end? It ends whenever it stops helping portability for apps that are currently written for OpenSSL. We've expressly decided to ignore any API/ABI compatibility guarantees with OpenSSL, so an OpenSSL version number is inherently just a best effort to make things easier on applications to transition from OpenSSL to LibreSSL. Clang went through this same process with code that did GCC version checks. Today Clang still claims it's GCC 4.2, but in a separate version it reveals it's Clang 3.5. Existing code that only knows to check for older versions of GCC (e.g., OpenBSD's ) continues work just fine with Clang, because it picks up all of the definitions targeted towards GCC 4.2. New code that wants to make use of features in GCC 4.7 and Clang 3.5 though needs to check for both; but even if it doesn't, if it includes fallback for older versions of GCC it should still work okay with Clang. Concrete analogy: suppose LibreSSL 2.1 and OpenSSL 1.1 both add some new feature, and an application that wants to be compatible with both wants to make use of that feature. How do they version check for its availability? Naively, it would be #if LibreSSL >= 2.1 || OpenSSL >= 1.1 but that's going to cause the application to break when compiled with older versions of LibreSSL. It would actually needs to be #if LibreSSL >= 2.1 || (!defined(LibreSSL) && OpenSSL >= 1.1) We don't gain anything by making people need to write the latter, IMO.
Re: CVS: cvs.openbsd.org: src
The fundamental probelm with this Matthew - is that next time, if we do this, by the next release we will be chasing what features we have imported from 1.0.2g and 10.2.z, and 1.0.2.qq - where does it end? We will be continuing to add functionality in here from many sources, and so assuming we could just keep this as the 1.0.1g version number is completely wrong. If we do that we will be perpetually updating this to be "close to" whatever happens to be the orthogonal openssl. feature set, we're screwed. We'll be doing this forever, and be in a situation where it's as bad a what it is with ACPI, where the only safe thing to report as is "Windows" so we don't get screwed by the software trying to do incompatible junk. Now the mistake we made this go around is to not provide a way for identifying that it is libressl. that has been corrected. On Fri, Jul 11, 2014 at 4:56 PM, Matthew Dempsky wrote: > On Fri, Jul 11, 2014 at 3:41 PM, Bob Beck wrote: >> The OPENSSL_VERSION number is a guarantee for a certain version of the >> ABI. As we dont' provide that (in fact much >> of the ABI in LIbreSSL is "beyond" 1.0.1g, it is not accurate to use >> the old OPENSSL_VERSION. Essnentially this OPENSSL_VERSION >> is "bigger than 1.0.1g"'s. > > By that argument, we won't be ABI compatible with OpenSSL 2.0 either, > so we shouldn't provide OPENSSL_VERSION at all. > > My 2c is for keeping OPENSSL_VERSION_NUMBER as the most recent OpenSSL > version that we're *mostly* API/feature compatible with, and using > LIBRESSL_VERSION_NUMBER to identify the exact LibreSSL version. By > polluting the OPENSSL_VERSION_NUMBER namespace we just make things > more difficult for downstream users that want to be compatible with > both OpenSSL and LibreSSL. > > E.g., to check for a feature that was added in OpenSSL 1.2 but isn't > present in LibreSSL, that code now needs to be > > #if OPENSSL_VERSION_NUMBER >= 1.2 && !defined(LIBRESSL_VERSION_NUMBER) > > rather than simply > > #if OPENSSL_VERSION_NUMBER >= 1.2 > > Breaking the latter just seems like making it more difficult to get > people to port their software from OpenSSL to LibreSSL.
Re: CVS: cvs.openbsd.org: src
On Fri, Jul 11, 2014 at 3:41 PM, Bob Beck wrote: > The OPENSSL_VERSION number is a guarantee for a certain version of the > ABI. As we dont' provide that (in fact much > of the ABI in LIbreSSL is "beyond" 1.0.1g, it is not accurate to use > the old OPENSSL_VERSION. Essnentially this OPENSSL_VERSION > is "bigger than 1.0.1g"'s. By that argument, we won't be ABI compatible with OpenSSL 2.0 either, so we shouldn't provide OPENSSL_VERSION at all. My 2c is for keeping OPENSSL_VERSION_NUMBER as the most recent OpenSSL version that we're *mostly* API/feature compatible with, and using LIBRESSL_VERSION_NUMBER to identify the exact LibreSSL version. By polluting the OPENSSL_VERSION_NUMBER namespace we just make things more difficult for downstream users that want to be compatible with both OpenSSL and LibreSSL. E.g., to check for a feature that was added in OpenSSL 1.2 but isn't present in LibreSSL, that code now needs to be #if OPENSSL_VERSION_NUMBER >= 1.2 && !defined(LIBRESSL_VERSION_NUMBER) rather than simply #if OPENSSL_VERSION_NUMBER >= 1.2 Breaking the latter just seems like making it more difficult to get people to port their software from OpenSSL to LibreSSL.
Re: CVS: cvs.openbsd.org: src
> I'm worried that bogus codepaths will be taken in software that expects a > certain openssl version - things failing to build we can cope with in ports > easily enough, I'm more concerned about software that does build but behaves > incorrectly at runtime. If the software is that fragile, then I am happy Bob, Joel, Miod, and Ted are simplifying the interface.
Re: CVS: cvs.openbsd.org: src
I'm worried that bogus codepaths will be taken in software that expects a certain openssl version - things failing to build we can cope with in ports easily enough, I'm more concerned about software that does build but behaves incorrectly at runtime.
Re: CVS: cvs.openbsd.org: src
And seeing as how they moved 0.0.4 revisons in 9 years, call that 0.0.05 revisions per year, they have approximately 194 years of OpenSSL releases before the version numbering space will collide. On Fri, Jul 11, 2014 at 4:41 PM, Bob Beck wrote: > The OPENSSL_VERSION number is a guarantee for a certain version of the > ABI. As we dont' provide that (in fact much > of the ABI in LIbreSSL is "beyond" 1.0.1g, it is not accurate to use > the old OPENSSL_VERSION. Essnentially this OPENSSL_VERSION > is "bigger than 1.0.1g"'s. > > > > On Fri, Jul 11, 2014 at 4:15 PM, Stuart Henderson > wrote: >> On 2014/07/11 15:21, Bob Beck wrote: >>> CVSROOT: /cvs >>> Module name: src >>> Changes by: b...@cvs.openbsd.org2014/07/11 15:21:59 >>> >>> Modified files: >>> lib/libssl/src/crypto: opensslv.h >>> >>> Log message: >>> Provide LIBRESSL_VERSION_NUMBER for people who use such things to >>> detect versions distinct from OPENSSL_BLAH_WOOF.. >>> ok jsing@ tedu@ deraadt@ >>> >> >> I think it would ease porting work if the old OPENSSL_VERSION_NUMBER could >> be retained and we use LIBRESSL_VERSION_NUMBER to distinguish LibreSSL >> versions.. >> >> >> dovecot-2.2.10/dovecot-2.2.10/src/login-common/ssl-proxy-openssl.c >> http://hg.dovecot.org/dovecot-2.2/file/fd0616d553b0/src/login-common/ssl-proxy-openssl.c#l130 >> 32:#if !defined(OPENSSL_NO_ECDH) && OPENSSL_VERSION_NUMBER >= 0x1000L >> 129:#if defined(HAVE_ECDH) && OPENSSL_VERSION_NUMBER < 0x10002000L >> 1028:#if defined(HAVE_ECDH) && OPENSSL_VERSION_NUMBER < 0x10002000L >> 1041:#if OPENSSL_VERSION_NUMBER >= 0x10002000L >> 1076:#if OPENSSL_VERSION_NUMBER >= 0x00907000L >> 1156:#if defined(HAVE_ECDH) && OPENSSL_VERSION_NUMBER < 0x10002000L >> >> chromium-34.0.1847.137/chromium-34.0.1847.137/net/socket/ssl_client_socket_openssl.cc >> 54:#if OPENSSL_VERSION_NUMBER < 0x1000103fL >> ...(checking for a version of openssl other than the embedded one?) >> >> >> apache-httpd >> http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/ssl/ssl_private.h?revision=1598107&view=markup#l86 >> : #include >> : #if (OPENSSL_VERSION_NUMBER >= 0x10001000) >> : /* must be defined before including ssl.h */ >> : #define OPENSSL_NO_SSL_INTERN >> : #endif >> >> knot-dns >> https://gitlab.labs.nic.cz/labs/knot/blob/2354047b6402aa68daffe96d6f82f30f0dad1cff/src/libknot/dnssec/config.h >> : // ECDSA support requires OpenSSL version >= 1.0.1 >> : #if !defined(OPENSSL_NO_ECDSA) && OPENSSL_VERSION_NUMBER >= 0x10001000L >> : #define KNOT_ENABLE_ECDSA 1 >> : #else >> : #undef KNOT_ENABLE_ECDSA >> : #endif >>
Re: CVS: cvs.openbsd.org: src
The OPENSSL_VERSION number is a guarantee for a certain version of the ABI. As we dont' provide that (in fact much of the ABI in LIbreSSL is "beyond" 1.0.1g, it is not accurate to use the old OPENSSL_VERSION. Essnentially this OPENSSL_VERSION is "bigger than 1.0.1g"'s. On Fri, Jul 11, 2014 at 4:15 PM, Stuart Henderson wrote: > On 2014/07/11 15:21, Bob Beck wrote: >> CVSROOT: /cvs >> Module name: src >> Changes by: b...@cvs.openbsd.org2014/07/11 15:21:59 >> >> Modified files: >> lib/libssl/src/crypto: opensslv.h >> >> Log message: >> Provide LIBRESSL_VERSION_NUMBER for people who use such things to >> detect versions distinct from OPENSSL_BLAH_WOOF.. >> ok jsing@ tedu@ deraadt@ >> > > I think it would ease porting work if the old OPENSSL_VERSION_NUMBER could > be retained and we use LIBRESSL_VERSION_NUMBER to distinguish LibreSSL > versions.. > > > dovecot-2.2.10/dovecot-2.2.10/src/login-common/ssl-proxy-openssl.c > http://hg.dovecot.org/dovecot-2.2/file/fd0616d553b0/src/login-common/ssl-proxy-openssl.c#l130 > 32:#if !defined(OPENSSL_NO_ECDH) && OPENSSL_VERSION_NUMBER >= 0x1000L > 129:#if defined(HAVE_ECDH) && OPENSSL_VERSION_NUMBER < 0x10002000L > 1028:#if defined(HAVE_ECDH) && OPENSSL_VERSION_NUMBER < 0x10002000L > 1041:#if OPENSSL_VERSION_NUMBER >= 0x10002000L > 1076:#if OPENSSL_VERSION_NUMBER >= 0x00907000L > 1156:#if defined(HAVE_ECDH) && OPENSSL_VERSION_NUMBER < 0x10002000L > > chromium-34.0.1847.137/chromium-34.0.1847.137/net/socket/ssl_client_socket_openssl.cc > 54:#if OPENSSL_VERSION_NUMBER < 0x1000103fL > ...(checking for a version of openssl other than the embedded one?) > > > apache-httpd > http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/ssl/ssl_private.h?revision=1598107&view=markup#l86 > : #include > : #if (OPENSSL_VERSION_NUMBER >= 0x10001000) > : /* must be defined before including ssl.h */ > : #define OPENSSL_NO_SSL_INTERN > : #endif > > knot-dns > https://gitlab.labs.nic.cz/labs/knot/blob/2354047b6402aa68daffe96d6f82f30f0dad1cff/src/libknot/dnssec/config.h > : // ECDSA support requires OpenSSL version >= 1.0.1 > : #if !defined(OPENSSL_NO_ECDSA) && OPENSSL_VERSION_NUMBER >= 0x10001000L > : #define KNOT_ENABLE_ECDSA 1 > : #else > : #undef KNOT_ENABLE_ECDSA > : #endif >
Re: CVS: cvs.openbsd.org: src
On 2014/07/11 15:21, Bob Beck wrote: > CVSROOT: /cvs > Module name: src > Changes by: b...@cvs.openbsd.org2014/07/11 15:21:59 > > Modified files: > lib/libssl/src/crypto: opensslv.h > > Log message: > Provide LIBRESSL_VERSION_NUMBER for people who use such things to > detect versions distinct from OPENSSL_BLAH_WOOF.. > ok jsing@ tedu@ deraadt@ > I think it would ease porting work if the old OPENSSL_VERSION_NUMBER could be retained and we use LIBRESSL_VERSION_NUMBER to distinguish LibreSSL versions.. dovecot-2.2.10/dovecot-2.2.10/src/login-common/ssl-proxy-openssl.c http://hg.dovecot.org/dovecot-2.2/file/fd0616d553b0/src/login-common/ssl-proxy-openssl.c#l130 32:#if !defined(OPENSSL_NO_ECDH) && OPENSSL_VERSION_NUMBER >= 0x1000L 129:#if defined(HAVE_ECDH) && OPENSSL_VERSION_NUMBER < 0x10002000L 1028:#if defined(HAVE_ECDH) && OPENSSL_VERSION_NUMBER < 0x10002000L 1041:#if OPENSSL_VERSION_NUMBER >= 0x10002000L 1076:#if OPENSSL_VERSION_NUMBER >= 0x00907000L 1156:#if defined(HAVE_ECDH) && OPENSSL_VERSION_NUMBER < 0x10002000L chromium-34.0.1847.137/chromium-34.0.1847.137/net/socket/ssl_client_socket_openssl.cc 54:#if OPENSSL_VERSION_NUMBER < 0x1000103fL ...(checking for a version of openssl other than the embedded one?) apache-httpd http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/ssl/ssl_private.h?revision=1598107&view=markup#l86 : #include : #if (OPENSSL_VERSION_NUMBER >= 0x10001000) : /* must be defined before including ssl.h */ : #define OPENSSL_NO_SSL_INTERN : #endif knot-dns https://gitlab.labs.nic.cz/labs/knot/blob/2354047b6402aa68daffe96d6f82f30f0dad1cff/src/libknot/dnssec/config.h : // ECDSA support requires OpenSSL version >= 1.0.1 : #if !defined(OPENSSL_NO_ECDSA) && OPENSSL_VERSION_NUMBER >= 0x10001000L : #define KNOT_ENABLE_ECDSA 1 : #else : #undef KNOT_ENABLE_ECDSA : #endif
Re: CVS: cvs.openbsd.org: src
> On Thu, Jul 10, 2014 at 08:29:04AM -0600, Philip Guenther wrote: > > CVSROOT:/cvs > > Module name:src > > Changes by: guent...@cvs.openbsd.org2014/07/10 08:29:03 > > > > Modified files: > > usr.bin/rdist : common.c config-data.h > > > > Log message: > > Assume POSIX: write() takes size_t and returns ssize_t > > Do we need to do anything specific to build rdist after this change? A further commit to rdist/defs.h fixes this; it should appear in your repository mirror shortly.
Re: CVS: cvs.openbsd.org: src
On Thu, Jul 10, 2014 at 08:29:04AM -0600, Philip Guenther wrote: > CVSROOT: /cvs > Module name: src > Changes by: guent...@cvs.openbsd.org2014/07/10 08:29:03 > > Modified files: > usr.bin/rdist : common.c config-data.h > > Log message: > Assume POSIX: write() takes size_t and returns ssize_t Do we need to do anything specific to build rdist after this change? ===> usr.bin/rdist cc -O2 -pipe -I. -I/usr/src/usr.bin/rdist -DOS_H=\"os-openbsd.h\" -Wall -Wpointer-arith -Wuninitialized -Wstrict-prototypes -Wmissing-prototypes -Wunused -Wsign-compare -Wshadow -Wdeclaration-after-statement -c gram.c cc -O2 -pipe -I. -I/usr/src/usr.bin/rdist -DOS_H=\"os-openbsd.h\" -Wall -Wpointer-arith -Wuninitialized -Wstrict-prototypes -Wmissing-prototypes -Wunused -Wsign-compare -Wshadow -Wdeclaration-after-statement -c /usr/src/usr.bin/rdist/message.c cc -O2 -pipe -I. -I/usr/src/usr.bin/rdist -DOS_H=\"os-openbsd.h\" -Wall -Wpointer-arith -Wuninitialized -Wstrict-prototypes -Wmissing-prototypes -Wunused -Wsign-compare -Wshadow -Wdeclaration-after-statement -c /usr/src/usr.bin/rdist/lookup.c cc -O2 -pipe -I. -I/usr/src/usr.bin/rdist -DOS_H=\"os-openbsd.h\" -Wall -Wpointer-arith -Wuninitialized -Wstrict-prototypes -Wmissing-prototypes -Wunused -Wsign-compare -Wshadow -Wdeclaration-after-statement -c /usr/src/usr.bin/rdist/isexec.c cc -O2 -pipe -I. -I/usr/src/usr.bin/rdist -DOS_H=\"os-openbsd.h\" -Wall -Wpointer-arith -Wuninitialized -Wstrict-prototypes -Wmissing-prototypes -Wunused -Wsign-compare -Wshadow -Wdeclaration-after-statement -c /usr/src/usr.bin/rdist/expand.c cc -O2 -pipe -I. -I/usr/src/usr.bin/rdist -DOS_H=\"os-openbsd.h\" -Wall -Wpointer-arith -Wuninitialized -Wstrict-prototypes -Wmissing-prototypes -Wunused -Wsign-compare -Wshadow -Wdeclaration-after-statement -c /usr/src/usr.bin/rdist/distopt.c cc -O2 -pipe -I. -I/usr/src/usr.bin/rdist -DOS_H=\"os-openbsd.h\" -Wall -Wpointer-arith -Wuninitialized -Wstrict-prototypes -Wmissing-prototypes -Wunused -Wsign-compare -Wshadow -Wdeclaration-after-statement -c /usr/src/usr.bin/rdist/common.c cc -O2 -pipe -I. -I/usr/src/usr.bin/rdist -DOS_H=\"os-openbsd.h\" -Wall -Wpointer-arith -Wuninitialized -Wstrict-prototypes -Wmissing-prototypes -Wunused -Wsign-compare -Wshadow -Wdeclaration-after-statement -c /usr/src/usr.bin/rdist/child.cIn file included from /usr/src/usr.bin/rdist/lookup.c:32: /usr/src/usr.bin/rdist/defs.h:336: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'xwrite' cc -O2 -pipe -I. -I/usr/src/usr.bin/rdist -DOS_H=\"os-openbsd.h\" -Wall -Wpointer-arith -Wuninitialized -Wstrict-prototypes -Wmissing-prototypes -Wunused -Wsign-compare -Wshadow -Wdeclaration-after-statement -c /usr/src/usr.bin/rdist/client.c cc -O2 -pipe -I. -I/usr/src/usr.bin/rdist -DOS_H=\"os-openbsd.h\" -Wall -Wpointer-arith -Wuninitialized -Wstrict-prototypes -Wmissing-prototypes -Wunused -Wsign-compare -Wshadow -Wdeclaration-after-statement -c /usr/src/usr.bin/rdist/docmd.c cc -O2 -pipe -I. -I/usr/src/usr.bin/rdist -DOS_H=\"os-openbsd.h\" -Wall -Wpointer-arith -Wuninitialized -Wstrict-prototypes -Wmissing-prototypes -Wunused -Wsign-compare -Wshadow -Wdeclaration-after-statement -c /usr/src/usr.bin/rdist/rdist.cIn file included from /usr/src/usr.bin/rdist/message.c:32: /usr/src/usr.bin/rdist/defs.h:336: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'xwrite'In file included from /usr/src/usr.bin/rdist/gram.y:34: /usr/src/usr.bin/rdist/defs.h:336: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'xwrite' In file included from /usr/src/usr.bin/rdist/common.c:32: /usr/src/usr.bin/rdist/defs.h:336: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'xwrite' /usr/src/usr.bin/rdist/common.c:80: warning: no previous prototype for 'xwrite' In file included from /usr/src/usr.bin/rdist/expand.c:34: /usr/src/usr.bin/rdist/defs.h:336: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'xwrite' In file included from /usr/src/usr.bin/rdist/distopt.c:32: /usr/src/usr.bin/rdist/defs.h:336: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'xwrite' In file included from /usr/src/usr.bin/rdist/client.c:34: /usr/src/usr.bin/rdist/defs.h:336: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'xwrite' In file included from /usr/src/usr.bin/rdist/isexec.c:32: /usr/src/usr.bin/rdist/defs.h:336: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'xwrite' *** Error 1 in target 'common.o' *** Error 1 in target 'lookup.o' *** Error 1 in target 'message.o' *** Error 1 in target 'gram.o' In file included from /usr/src/usr.bin/rdist/child.c:32: /usr/src/usr.bin/rdist/defs.h:336: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'xwrite' In file included from /usr/src/usr.bin/rdist/docmd.c:36: /usr/src/usr.bin/rdist/defs.h:336: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'xwrite' /usr/
Re: procfs to die [was: CVS: cvs.openbsd.org: src]
I do use it occasionally, and I don't run -current so I wouldn't have noticed any breakage yet. I don't rely on it, however, it's a convenience feature that I very occasionally use, and only manually when I do. I can live without it if it dies; it was never a fully-featured implementation IMHO anyway. -Adam On June 22, 2014 4:22:16 PM CDT, Philip Guenther wrote: >If you're currently using procfs, please respond with exactly what >parts of >it are actually needed by the programs you run. Without a good reason >to >keep it, it'll be deleted, as I broke listing of /proc back in January >and >no one has noticed, suggesting that no one is actually using it... > >Philip Guenther > > >-- Forwarded message -- >From: Philip Guenther >Date: Sun, Jun 22, 2014 at 2:15 PM >Subject: CVS: cvs.openbsd.org: src >To: source-chan...@cvs.openbsd.org > > >CVSROOT:/cvs >Module name:src >Changes by: guent...@cvs.openbsd.org2014/06/22 15:15:51 > >Modified files: >sys/arch/i386/conf: GENERIC > >Log message: >PROCFS has been broken for months without complaints, so stop building >it > >suggested by sthen@ -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: procfs to die [was: CVS: cvs.openbsd.org: src]
I suspect procfs is only enabled on i386 because that's the only arch with compat_linux support? If so, anyone who relies on compat_linux support should be sure to test and report back if they have problems. On Sun, Jun 22, 2014 at 2:22 PM, Philip Guenther wrote: > If you're currently using procfs, please respond with exactly what parts of > it are actually needed by the programs you run. Without a good reason to > keep it, it'll be deleted, as I broke listing of /proc back in January and > no one has noticed, suggesting that no one is actually using it... > > Philip Guenther > > > -- Forwarded message -- > From: Philip Guenther > Date: Sun, Jun 22, 2014 at 2:15 PM > Subject: CVS: cvs.openbsd.org: src > To: source-chan...@cvs.openbsd.org > > > CVSROOT:/cvs > Module name:src > Changes by: guent...@cvs.openbsd.org2014/06/22 15:15:51 > > Modified files: > sys/arch/i386/conf: GENERIC > > Log message: > PROCFS has been broken for months without complaints, so stop building it > > suggested by sthen@
procfs to die [was: CVS: cvs.openbsd.org: src]
If you're currently using procfs, please respond with exactly what parts of it are actually needed by the programs you run. Without a good reason to keep it, it'll be deleted, as I broke listing of /proc back in January and no one has noticed, suggesting that no one is actually using it... Philip Guenther -- Forwarded message -- From: Philip Guenther Date: Sun, Jun 22, 2014 at 2:15 PM Subject: CVS: cvs.openbsd.org: src To: source-chan...@cvs.openbsd.org CVSROOT:/cvs Module name:src Changes by: guent...@cvs.openbsd.org2014/06/22 15:15:51 Modified files: sys/arch/i386/conf: GENERIC Log message: PROCFS has been broken for months without complaints, so stop building it suggested by sthen@
Re: CVS: cvs.openbsd.org: src
2013/11/19 Bob Beck : > I'm inclined to agree with marc here - we bump minors on api additions > - and yes, it was stubbed there before so it's not really an > "addition" but it was stubbed to fail and had to be worked around - > bump the minor - not like it's a big deal. > > On Tue, Nov 19, 2013 at 12:02 AM, Marc Espie wrote: >> On Tue, Nov 19, 2013 at 12:11:17AM -0500, Ted Unangst wrote: >>> On Mon, Nov 18, 2013 at 18:49, Philip Guenther wrote: >>> >>> >> btw, no library version change because the function stubs already >>> >> existed. >>> > >>> > Hmm, since this is actually offering new functionality (by sem_open() >>> > and friends no longer always failing), I think it a minor bump would >>> > be appropriate. Consider that a program with an autoconf test of >>> > sem_open() will now return a different answer, just as if sem_open() >>> > was completely new. no? >>> >>> I hear you, but disagree. We fix program disabling bugs in libraries >>> frequently without bumping. I have always thought of library >>> versioning being more about "program integrity", as in all the pieces >>> you expect to find are all there, but it doesn't say anything about >>> the inner workings of the pieces. >> >> As theo says, there are other library bumps later, but you're wrong. >> >> Use-case: new packages, slightly older snapshots. New packages actually >> make use of sem_open, because of said added functionality. Without a bump, >> pkg_add will allow to add them, and they won't work, because the >> functionality >> wasn't there... >> >> It is added functionality. It's not a minor bugfix. I know at least one software piece for which changing the behaviour of sem_open() changes the behaviour of this software itself - KSharedDataCache from kdelibs (the one I've talked on EuroBSDCon, btw). It tries at run-time to call sem_open(foo, 1), and if it fails, goes other way; and particular execution path affects the on-disk structures, too! In case of KSharedDataCache it isn't really an issue (cache could be rebuilt in the worst case), but there could be others in ports with much worse effects. I mean, behavior change in this case should be probably accompanied with major lib version bump, so we could at least differentiate packages. -- WBR, Vadim Zhukov
Re: CVS: cvs.openbsd.org: src
I'm inclined to agree with marc here - we bump minors on api additions - and yes, it was stubbed there before so it's not really an "addition" but it was stubbed to fail and had to be worked around - bump the minor - not like it's a big deal. On Tue, Nov 19, 2013 at 12:02 AM, Marc Espie wrote: > On Tue, Nov 19, 2013 at 12:11:17AM -0500, Ted Unangst wrote: >> On Mon, Nov 18, 2013 at 18:49, Philip Guenther wrote: >> >> >> btw, no library version change because the function stubs already >> >> existed. >> > >> > Hmm, since this is actually offering new functionality (by sem_open() >> > and friends no longer always failing), I think it a minor bump would >> > be appropriate. Consider that a program with an autoconf test of >> > sem_open() will now return a different answer, just as if sem_open() >> > was completely new. no? >> >> I hear you, but disagree. We fix program disabling bugs in libraries >> frequently without bumping. I have always thought of library >> versioning being more about "program integrity", as in all the pieces >> you expect to find are all there, but it doesn't say anything about >> the inner workings of the pieces. > > As theo says, there are other library bumps later, but you're wrong. > > Use-case: new packages, slightly older snapshots. New packages actually > make use of sem_open, because of said added functionality. Without a bump, > pkg_add will allow to add them, and they won't work, because the functionality > wasn't there... > > It is added functionality. It's not a minor bugfix. >
Re: CVS: cvs.openbsd.org: src
> On Tue, Nov 19, 2013 at 12:11:17AM -0500, Ted Unangst wrote: > > On Mon, Nov 18, 2013 at 18:49, Philip Guenther wrote: > > > > >> btw, no library version change because the function stubs already > > >> existed. > > > > > > Hmm, since this is actually offering new functionality (by sem_open() > > > and friends no longer always failing), I think it a minor bump would > > > be appropriate. Consider that a program with an autoconf test of > > > sem_open() will now return a different answer, just as if sem_open() > > > was completely new. no? > > > > I hear you, but disagree. We fix program disabling bugs in libraries > > frequently without bumping. I have always thought of library > > versioning being more about "program integrity", as in all the pieces > > you expect to find are all there, but it doesn't say anything about > > the inner workings of the pieces. > > As theo says, there are other library bumps later, but you're wrong. > > Use-case: new packages, slightly older snapshots. New packages actually > make use of sem_open, because of said added functionality. Without a bump, > pkg_add will allow to add them, and they won't work, because the functionality > wasn't there... > > It is added functionality. It's not a minor bugfix. The current window you are arguying about is maybe from Oct 24, definately Oct 22. For many pkgs, a few other intermediate bumps mattered. A libc crank is coming uhm, rather shortly. Melodrama.
Re: CVS: cvs.openbsd.org: src
On Tue, Nov 19, 2013 at 12:11:17AM -0500, Ted Unangst wrote: > On Mon, Nov 18, 2013 at 18:49, Philip Guenther wrote: > > >> btw, no library version change because the function stubs already > >> existed. > > > > Hmm, since this is actually offering new functionality (by sem_open() > > and friends no longer always failing), I think it a minor bump would > > be appropriate. Consider that a program with an autoconf test of > > sem_open() will now return a different answer, just as if sem_open() > > was completely new. no? > > I hear you, but disagree. We fix program disabling bugs in libraries > frequently without bumping. I have always thought of library > versioning being more about "program integrity", as in all the pieces > you expect to find are all there, but it doesn't say anything about > the inner workings of the pieces. As theo says, there are other library bumps later, but you're wrong. Use-case: new packages, slightly older snapshots. New packages actually make use of sem_open, because of said added functionality. Without a bump, pkg_add will allow to add them, and they won't work, because the functionality wasn't there... It is added functionality. It's not a minor bugfix.
Re: CVS: cvs.openbsd.org: src
On Mon, Nov 18, 2013 at 18:49, Philip Guenther wrote: >> btw, no library version change because the function stubs already >> existed. > > Hmm, since this is actually offering new functionality (by sem_open() > and friends no longer always failing), I think it a minor bump would > be appropriate. Consider that a program with an autoconf test of > sem_open() will now return a different answer, just as if sem_open() > was completely new. no? I hear you, but disagree. We fix program disabling bugs in libraries frequently without bumping. I have always thought of library versioning being more about "program integrity", as in all the pieces you expect to find are all there, but it doesn't say anything about the inner workings of the pieces.
Re: CVS: cvs.openbsd.org: src
> On Mon, Nov 18, 2013 at 3:19 PM, Ted Unangst wrote: > > On Mon, Nov 18, 2013 at 16:10, Ted Unangst wrote: > >> CVSROOT: /cvs > >> Module name: src > >> Changes by: t...@cvs.openbsd.org2013/11/18 16:10:48 > >> > >> Modified files: > >> lib/librthread : rthread.h rthread_sem.c > >> > >> Log message: > >> interprocess semaphores ala sem_open. mostly following in the pattern > >> of shm_open. with some additions and fixes from zhuk. > > > > btw, no library version change because the function stubs already > > existed. > > Hmm, since this is actually offering new functionality (by sem_open() > and friends no longer always failing), I think it a minor bump would > be appropriate. Consider that a program with an autoconf test of > sem_open() will now return a different answer, just as if sem_open() > was completely new. no? Well... considering recent library cranks, is that really a concern?
Re: CVS: cvs.openbsd.org: src
On Mon, Nov 18, 2013 at 3:19 PM, Ted Unangst wrote: > On Mon, Nov 18, 2013 at 16:10, Ted Unangst wrote: >> CVSROOT: /cvs >> Module name: src >> Changes by: t...@cvs.openbsd.org2013/11/18 16:10:48 >> >> Modified files: >> lib/librthread : rthread.h rthread_sem.c >> >> Log message: >> interprocess semaphores ala sem_open. mostly following in the pattern >> of shm_open. with some additions and fixes from zhuk. > > btw, no library version change because the function stubs already > existed. Hmm, since this is actually offering new functionality (by sem_open() and friends no longer always failing), I think it a minor bump would be appropriate. Consider that a program with an autoconf test of sem_open() will now return a different answer, just as if sem_open() was completely new. no? Philip Guenther
Re: spamd: greyreader failed (Error 2) (was: Re: CVS: cvs.openbsd.org: src)
On 2013-W40-2 16:56 -0600, Todd C. Miller wrote: > On Mon, 30 Sep 2013 19:26:20 -0700, "Constantine A. Murenin" wrote: > > > Whereas it remains to be seen what kind of bug I'm facing here > > (Google reveals I'm not alone), it would appear that changes > > introduced in 5.4-current would no longer cause spamd to report > > such situation, because the 0 that would still be returned at the > > end of greyreader() would no longer cause greywatcher() to produce > > the error message that I have received (it'll still quit, though). > > Yes, that was an unrelated change that snuck in there. Personally, > I've only seen that error on shutdown, where it is spurious. If > you are getting a read error on the pipe it must mean that the spamd > on the other end died. Yes, I gather that's what it means -- the other end of the pipe is gone. However, there were no other messages reported. In my case, it was definitely not a shutdown-related error -- the system was not rebooted at that time, nor were any mail-related settings modified or any services restarted. I think it would make sense for this part to be reverted and for the error message to be brought back; otherwise, there'd pretty much not even be a record of when spamd actually stops working here. C.
Re: spamd: greyreader failed (Error 2) (was: Re: CVS: cvs.openbsd.org: src)
On Mon, 30 Sep 2013 19:26:20 -0700, "Constantine A. Murenin" wrote: > Whereas it remains to be seen what kind of bug I'm facing here > (Google reveals I'm not alone), it would appear that changes > introduced in 5.4-current would no longer cause spamd to report > such situation, because the 0 that would still be returned at the > end of greyreader() would no longer cause greywatcher() to produce > the error message that I have received (it'll still quit, though). Yes, that was an unrelated change that snuck in there. Personally, I've only seen that error on shutdown, where it is spurious. If you are getting a read error on the pipe it must mean that the spamd on the other end died. - todd
spamd: greyreader failed (Error 2) (was: Re: CVS: cvs.openbsd.org: src)
Hello, On OpenBSD 5.2 amd64, my spamd (which is used very selectively through pf(4)) seems to have died 20 days ago, after continuously running for many months, with the following final words in the logs: Sep 10 09:49:25 Cns spamd[5220]: 87.225.1.10: connected (1/1), lists: spamd-greytrap Sep 10 09:54:47 Cns spamd[29672]: greyreader failed (Error 2) There were minor changes to grey.c since 5.2. Back in 5.2, it would appear that at the end of grey.c#greyreader(), after the `grey` pipe is exhausted, greyreader() returns at the end of the function, and then grey.c#greywatcher() issues the error message, as above, unconditionally after greyreader() returns, and also exits. Whereas it remains to be seen what kind of bug I'm facing here (Google reveals I'm not alone), it would appear that changes introduced in 5.4-current would no longer cause spamd to report such situation, because the 0 that would still be returned at the end of greyreader() would no longer cause greywatcher() to produce the error message that I have received (it'll still quit, though). http://www.openbsd.org/cgi-bin/cvsweb/src/libexec/spamd/grey.c.diff?r1=1.52;r2=1.53;f=h http://www.openbsd.org/cgi-bin/cvsweb/src/libexec/spamd/grey.c.diff?r2=1.53&r1=1.52&f=u Basically, the below part of the recent commit seems to modify the behaviour that was not advertised to have been modified: @@ -979,7 +979,7 @@ greyreader(void) sync = 1; if (grey == NULL) { syslog_r(LOG_ERR, &sdata, "No greylist pipe stream!\n"); - exit(1); + return (-1); } /* grab trap suffixes */ @@ -1140,10 +1140,11 @@ greywatcher(void) */ close(pfdev); setproctitle("(%s update)", PATH_SPAMD_DB); - greyreader(); - syslog_r(LOG_ERR, &sdata, "greyreader failed (%m)"); - /* NOTREACHED */ - _exit(1); + if (greyreader() == -1) { + syslog_r(LOG_ERR, &sdata, "greyreader failed (%m)"); + _exit(1); + } + _exit(0); } http://bxr.su/o/libexec/spamd/grey.c#greywatcher Is it indeed intentional that "greyreader failed (Error 2)" will be produced no more as a result of the above change? Any ideas what caused greyreader to fail on my OpenBSD 5.2 in the first place? Cheers, Constantine. On 2013-W34-3 10:13 -0600, Todd C. Miller wrote: > CVSROOT: /cvs > Module name: src > Changes by: mill...@cvs.openbsd.org 2013/08/21 10:13:30 > > Modified files: > usr.sbin/spamdb: Makefile spamdb.c > libexec/spamd : Makefile grey.c grey.h > libexec/spamlogd: Makefile spamlogd.c > Added files: > libexec/spamd : gdcopy.c > > Log message: > Remove the use of time_t in the greylist db file and use int64_t instead > with backwards compatibility for records with 32-bit times. > OK deraadt@ beck@
Re: CVS: cvs.openbsd.org: src
On 06/08/13 03:14, Jonathan Gray wrote: On Sat, Jun 08, 2013 at 03:06:26AM -0400, Scott McEachern wrote: On 06/08/13 02:38, Ville Valkonen wrote: Hi, did you compile the recent Xenocara too? No, I didn't get that far. Just the kernel. That's how I know it wasn't the recent xenocara updates that caused the problem and believe this specific commit is the culprit. However, you did get me thinking... I'll skip using X and go console-only, build the new xenocara and see if the problem goes away. I'll bet that kernel commit requires the new X. I'll post the results in a bit. You'll need to build at least libdrm as mentioned here: http://www.openbsd.org/faq/current.html#20130607b The X builds in the snapshots aren't updated as often as the rest of the sets so it may take some time for snapshots to catch up. Yep, just read "following current" and did a facepalm. I'm building a new system now. I'm sure everything will be fine. Sorry for the noise... -- Scott McEachern https://www.blackstaff.ca "Those who would give up essential liberty to purchase a little temporary safety deserve neither liberty nor safety." -- Benjamin Franklin
Re: CVS: cvs.openbsd.org: src
On Sat, Jun 08, 2013 at 03:06:26AM -0400, Scott McEachern wrote: > On 06/08/13 02:38, Ville Valkonen wrote: > >Hi, did you compile the recent Xenocara too? > > No, I didn't get that far. Just the kernel. That's how I know it > wasn't the recent xenocara updates that caused the problem and > believe this specific commit is the culprit. > > However, you did get me thinking... > > I'll skip using X and go console-only, build the new xenocara and > see if the problem goes away. I'll bet that kernel commit requires > the new X. I'll post the results in a bit. You'll need to build at least libdrm as mentioned here: http://www.openbsd.org/faq/current.html#20130607b The X builds in the snapshots aren't updated as often as the rest of the sets so it may take some time for snapshots to catch up.
Re: CVS: cvs.openbsd.org: src
On 06/08/13 02:38, Ville Valkonen wrote: Hi, did you compile the recent Xenocara too? No, I didn't get that far. Just the kernel. That's how I know it wasn't the recent xenocara updates that caused the problem and believe this specific commit is the culprit. However, you did get me thinking... I'll skip using X and go console-only, build the new xenocara and see if the problem goes away. I'll bet that kernel commit requires the new X. I'll post the results in a bit. -- Scott McEachern https://www.blackstaff.ca "Those who would give up essential liberty to purchase a little temporary safety deserve neither liberty nor safety." -- Benjamin Franklin
Re: CVS: cvs.openbsd.org: src
Hi, did you compile the recent Xenocara too? On Jun 8, 2013 9:30 AM, "Scott McEachern" wrote: > On 06/07/13 16:46, Mark Kettenis wrote: > >> CVSROOT:/cvs >> Module name:src >> Changes by: kette...@cvs.openbsd.org2013/06/07 14:46:15 >> >> Modified files: >> sys/uvm: uvm_device.c uvm_device.h >> sys/dev/pci/drm: drm.h drmP.h drm_drv.c >> sys/dev/pci/drm/i915: i915_gem.c >> >> Log message: >> Add proper mmap(2) support for drm(4)/inteldrm(4). This changes the >> DRM_I915_GEM_MMAP and DRM_I915_GEM_MMAP_GTT ioctls to be compatible with >> Linux. This also is the first step that moves us away from accessing all >> graphics memory through the GTT, which should make things faster. >> >> ok tedu@ (for the uvm bits) >> >> > I just built a new kernel using -current sources, including this change, > in preparation to build the system. It didn't work out very well and I had > to revert to obsd. > > The kernel boot display looks normal, going from 25->40 rows properly, > however, once X starts the puffy "OpenBSD 5.3" logo is garbled beyond > recognition. The surrounding text of the hostname and name/password stuff > looks fine. After logging in and spectrwm starts, the display is > completely distorted and unusable. > > Just thought I'd let you know. dmesg from the previous (working) kernel: > > OpenBSD 5.3-current (GENERIC.MP) #1: Wed Jun 5 05:06:14 EDT 2013 > r...@elminster.blackstaff.ca:/**usr/src/sys/arch/amd64/**compile/ > GENERIC.MP > real mem = 16835637248 (16055MB) > avail mem = 16379756544 (15620MB) > mainbus0 at root > bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xeb410 (112 entries) > bios0: vendor American Megatrends Inc. version "0408" date 06/05/2012 > bios0: ASUSTeK COMPUTER INC. P8Z77-V PREMIUM > acpi0 at bios0: rev 2 > acpi0: sleep states S0 S1 S3 S4 S5 > acpi0: tables DSDT FACP APIC FPDT MCFG HPET SSDT SSDT SSDT BGRT > acpi0: wakeup devices PS2K(S4) PS2M(S4) P0P1(S4) PXSX(S4) RP01(S4) > PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) PXSX(S4) RP05(S4) > PXSX(S4) RP06(S4) PXSX(S4) [...] > acpitimer0 at acpi0: 3579545 Hz, 24 bits > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat > cpu0 at mainbus0: apid 0 (boot processor) > cpu0: Intel(R) Core(TM) i7-3770K CPU @ 3.50GHz, 3606.22 MHz > cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,**MCE,CX8,APIC,SEP,MTRR,PGE,MCA,** > CMOV,PAT,PSE36,CFLUSH,DS,ACPI,**MMX,FXSR,SSE,SSE2,SS,HTT,TM,** > PBE,SSE3,PCLMUL,DTES64,MWAIT,**DS-CPL,VMX,EST,TM2,SSSE3,CX16,** > xTPR,PDCM,PCID,SSE4.1,SSE4.2,**POPCNT,DEADLINE,AES,XSAVE,AVX,** > F16C,RDRAND,NXE,LONG,LAHF,**PERF,ITSC,FSGSBASE,SMEP,ERMS > cpu0: 256KB 64b/line 8-way L2 cache > cpu0: smt 0, core 0, package 0 > cpu0: apic clock running at 103MHz > cpu1 at mainbus0: apid 2 (application processor) > cpu1: Intel(R) Core(TM) i7-3770K CPU @ 3.50GHz, 3605.67 MHz > cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,**MCE,CX8,APIC,SEP,MTRR,PGE,MCA,** > CMOV,PAT,PSE36,CFLUSH,DS,ACPI,**MMX,FXSR,SSE,SSE2,SS,HTT,TM,** > PBE,SSE3,PCLMUL,DTES64,MWAIT,**DS-CPL,VMX,EST,TM2,SSSE3,CX16,** > xTPR,PDCM,PCID,SSE4.1,SSE4.2,**POPCNT,DEADLINE,AES,XSAVE,AVX,** > F16C,RDRAND,NXE,LONG,LAHF,**PERF,ITSC,FSGSBASE,SMEP,ERMS > cpu1: 256KB 64b/line 8-way L2 cache > cpu1: smt 0, core 1, package 0 > cpu2 at mainbus0: apid 4 (application processor) > cpu2: Intel(R) Core(TM) i7-3770K CPU @ 3.50GHz, 3605.67 MHz > cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,**MCE,CX8,APIC,SEP,MTRR,PGE,MCA,** > CMOV,PAT,PSE36,CFLUSH,DS,ACPI,**MMX,FXSR,SSE,SSE2,SS,HTT,TM,** > PBE,SSE3,PCLMUL,DTES64,MWAIT,**DS-CPL,VMX,EST,TM2,SSSE3,CX16,** > xTPR,PDCM,PCID,SSE4.1,SSE4.2,**POPCNT,DEADLINE,AES,XSAVE,AVX,** > F16C,RDRAND,NXE,LONG,LAHF,**PERF,ITSC,FSGSBASE,SMEP,ERMS > cpu2: 256KB 64b/line 8-way L2 cache > cpu2: smt 0, core 2, package 0 > cpu3 at mainbus0: apid 6 (application processor) > cpu3: Intel(R) Core(TM) i7-3770K CPU @ 3.50GHz, 3605.67 MHz > cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,**MCE,CX8,APIC,SEP,MTRR,PGE,MCA,** > CMOV,PAT,PSE36,CFLUSH,DS,ACPI,**MMX,FXSR,SSE,SSE2,SS,HTT,TM,** > PBE,SSE3,PCLMUL,DTES64,MWAIT,**DS-CPL,VMX,EST,TM2,SSSE3,CX16,** > xTPR,PDCM,PCID,SSE4.1,SSE4.2,**POPCNT,DEADLINE,AES,XSAVE,AVX,** > F16C,RDRAND,NXE,LONG,LAHF,**PERF,ITSC,FSGSBASE,SMEP,ERMS > cpu3: 256KB 64b/line 8-way L2 cache > cpu3: smt 0, core 3, package 0 > cpu4 at mainbus0: apid 1 (application processor) > cpu4: Intel(R) Core(TM) i7-3770K CPU @ 3.50GHz, 3605.67 MHz > cpu4: FPU,VME,DE,PSE,TSC,MSR,PAE,**MCE,CX8,APIC,SEP,MTRR,PGE,MCA,** > CMOV,PAT,PSE36,CFLUSH,DS,ACPI,**MMX,FXSR,SSE,SSE2,SS,HTT,TM,** > PBE,SSE3,PCLMUL,DTES64,MWAIT,**DS-CPL,VMX,EST,TM2,SSSE3,CX16,** > xTPR,PDCM,PCID,SSE4.1,SSE4.2,**POPCNT,DEADLINE,AES,XSAVE,AVX,** > F16C,RDRAND,NXE,LONG,LAHF,**PERF,ITSC,FSGSBASE,SMEP,ERMS > cpu4: 256KB 64b/line 8-way L2 cache > cpu4: smt 1, core 0, package 0 > cpu5 at mainbus0: apid 3 (application processor) > cpu5: Intel(R) Core(TM) i7-3770K CPU @ 3.50GHz, 3605.67 MHz > cpu5: FPU,VME,DE,PSE,TSC,MSR,PAE,**MCE,CX8,APIC,SEP,MTRR,PGE,MCA,** > CMOV,PAT,PSE36,CFLUSH,DS,ACPI,**MMX,FXSR,SSE,SSE2,S
Re: CVS: cvs.openbsd.org: src
On 06/07/13 16:46, Mark Kettenis wrote: CVSROOT:/cvs Module name:src Changes by: kette...@cvs.openbsd.org2013/06/07 14:46:15 Modified files: sys/uvm: uvm_device.c uvm_device.h sys/dev/pci/drm: drm.h drmP.h drm_drv.c sys/dev/pci/drm/i915: i915_gem.c Log message: Add proper mmap(2) support for drm(4)/inteldrm(4). This changes the DRM_I915_GEM_MMAP and DRM_I915_GEM_MMAP_GTT ioctls to be compatible with Linux. This also is the first step that moves us away from accessing all graphics memory through the GTT, which should make things faster. ok tedu@ (for the uvm bits) I just built a new kernel using -current sources, including this change, in preparation to build the system. It didn't work out very well and I had to revert to obsd. The kernel boot display looks normal, going from 25->40 rows properly, however, once X starts the puffy "OpenBSD 5.3" logo is garbled beyond recognition. The surrounding text of the hostname and name/password stuff looks fine. After logging in and spectrwm starts, the display is completely distorted and unusable. Just thought I'd let you know. dmesg from the previous (working) kernel: OpenBSD 5.3-current (GENERIC.MP) #1: Wed Jun 5 05:06:14 EDT 2013 r...@elminster.blackstaff.ca:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 16835637248 (16055MB) avail mem = 16379756544 (15620MB) mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xeb410 (112 entries) bios0: vendor American Megatrends Inc. version "0408" date 06/05/2012 bios0: ASUSTeK COMPUTER INC. P8Z77-V PREMIUM acpi0 at bios0: rev 2 acpi0: sleep states S0 S1 S3 S4 S5 acpi0: tables DSDT FACP APIC FPDT MCFG HPET SSDT SSDT SSDT BGRT acpi0: wakeup devices PS2K(S4) PS2M(S4) P0P1(S4) PXSX(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) PXSX(S4) RP05(S4) PXSX(S4) RP06(S4) PXSX(S4) [...] acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i7-3770K CPU @ 3.50GHz, 3606.22 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS cpu0: 256KB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 cpu0: apic clock running at 103MHz cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Core(TM) i7-3770K CPU @ 3.50GHz, 3605.67 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 4 (application processor) cpu2: Intel(R) Core(TM) i7-3770K CPU @ 3.50GHz, 3605.67 MHz cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS cpu2: 256KB 64b/line 8-way L2 cache cpu2: smt 0, core 2, package 0 cpu3 at mainbus0: apid 6 (application processor) cpu3: Intel(R) Core(TM) i7-3770K CPU @ 3.50GHz, 3605.67 MHz cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS cpu3: 256KB 64b/line 8-way L2 cache cpu3: smt 0, core 3, package 0 cpu4 at mainbus0: apid 1 (application processor) cpu4: Intel(R) Core(TM) i7-3770K CPU @ 3.50GHz, 3605.67 MHz cpu4: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS cpu4: 256KB 64b/line 8-way L2 cache cpu4: smt 1, core 0, package 0 cpu5 at mainbus0: apid 3 (application processor) cpu5: Intel(R) Core(TM) i7-3770K CPU @ 3.50GHz, 3605.67 MHz cpu5: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS cpu5: 256KB 64b/line 8-way L2 cache cpu5: smt 1, core 1, package 0 cpu6 at mainbus0: apid 5 (application processor) cpu6: Intel(R) Core(TM) i7-3770K CPU @ 3.50GHz, 3605.67 MHz cpu6: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,
Re: CVS: cvs.openbsd.org: src
On Sun, Aug 12, 2012 at 10:14 AM, Miod Vallat wrote in a commit message: ... > Passes the regress tests, and now devel/libsigsegv configure siglongjmp test > will not spin (this test is however flawed as it expects a signal handler > declared as running on the sigaltstack and `returning' through siglongjmp to > be invoked on the signal stack the next time the signal is raised). I think that's a bug in our handling of the SS_ONSTACK flag. Right now, we set that flag when switching to the stack while calling a signal handler marked for alt-stack handling and *only* clear it in sigreturn() of the sigcontext from when it first went onto the stack. The means that if a thread longjumps off the alt-stack, it has no way to ever clear the flag and utilize the alt-stack again. FreeBSD and NetBSD switched at some point to the SS_ONSTACK flag being dynamically determined from the thread's current stack pointer, which makes the handling of the alt-stack more flexible without creating any contradictions. We should pull that change over, IMO. Philip Guenther