Re: openssl s_time: plug SSL leak in doConnection
On Fri, Aug 17, 2018 at 07:51:26PM -0500, Scott Cheloha wrote: > On Fri, Aug 17, 2018 at 04:43:03PM -0500, Scott Cheloha wrote: > > On Mon, Aug 13, 2018 at 07:20:38PM +0200, Theo Buehler wrote: > > > On Mon, Aug 13, 2018 at 07:01:25PM +0200, Jeremie Courreges-Anglas wrote: > > > > On Mon, Aug 13 2018, Scott Cheloha wrote: > > > > > tb@ spotted this one. > > > > > > > > > > If BIO_new fails we leak scon, so SSL_free it in that case. > > > > > > > > > > ok? > > > > > > > > Alternative proposal: let doConnection() and benchmark() free the > > > > resources they allocated respectively. > > > > > > > > > > I'd be ok with that as a workaround, but it doesn't change the fact that > > > doConnection() desperately needs a cleanup. > > > > > > As Joel pointed out off-list, it would probably be better to to move the > > > call to SSL_new() out of doConnection() and then simplify the latter. > > > > > > Cheloha is looking into that, and I think we can give this a bit of time. > > > > Here is such a diff. > > > > Move SSL_new() out into benchmark() and eliminate all SSL_new/SSL_free > > juggling from doConnection. Because doConnection is no longer allocating, > > have it return an integer. benchmark() is now less compact but it is > > clearer that we never leak an SSL object as all the allocations and frees > > occur within the same scope. > > > > The only behavior change is that we now always do SSL_set_connect_state > > for the connection instead of skipping that for the object's first use. > > After reading the manpage I'm pretty sure this is harmless. Can someone > > more familiar with libssl weigh in, though? > > > > The for-loop in doConnection remains peculiar, but that's cosmetic. > > Here is a cleaner version of the prior diff with input from tb. > > Thoughts? ok? Looks good. ok
Re: openssl s_time: plug SSL leak in doConnection
On Fri, Aug 17, 2018 at 04:43:03PM -0500, Scott Cheloha wrote:
> On Mon, Aug 13, 2018 at 07:20:38PM +0200, Theo Buehler wrote:
> > On Mon, Aug 13, 2018 at 07:01:25PM +0200, Jeremie Courreges-Anglas wrote:
> > > On Mon, Aug 13 2018, Scott Cheloha wrote:
> > > > tb@ spotted this one.
> > > >
> > > > If BIO_new fails we leak scon, so SSL_free it in that case.
> > > >
> > > > ok?
> > >
> > > Alternative proposal: let doConnection() and benchmark() free the
> > > resources they allocated respectively.
> > >
> >
> > I'd be ok with that as a workaround, but it doesn't change the fact that
> > doConnection() desperately needs a cleanup.
> >
> > As Joel pointed out off-list, it would probably be better to to move the
> > call to SSL_new() out of doConnection() and then simplify the latter.
> >
> > Cheloha is looking into that, and I think we can give this a bit of time.
>
> Here is such a diff.
>
> Move SSL_new() out into benchmark() and eliminate all SSL_new/SSL_free
> juggling from doConnection. Because doConnection is no longer allocating,
> have it return an integer. benchmark() is now less compact but it is
> clearer that we never leak an SSL object as all the allocations and frees
> occur within the same scope.
>
> The only behavior change is that we now always do SSL_set_connect_state
> for the connection instead of skipping that for the object's first use.
> After reading the manpage I'm pretty sure this is harmless. Can someone
> more familiar with libssl weigh in, though?
>
> The for-loop in doConnection remains peculiar, but that's cosmetic.
Here is a cleaner version of the prior diff with input from tb.
Thoughts? ok?
Index: s_time.c
===
RCS file: /cvs/src/usr.bin/openssl/s_time.c,v
retrieving revision 1.26
diff -u -p -r1.26 s_time.c
--- s_time.c14 Aug 2018 15:25:04 - 1.26
+++ s_time.c18 Aug 2018 00:51:14 -
@@ -90,7 +90,7 @@
extern int verify_depth;
static void s_time_usage(void);
-static SSL *doConnection(SSL * scon);
+static int doConnection(SSL *);
static int benchmark(int);
static SSL_CTX *tm_ctx = NULL;
@@ -345,42 +345,28 @@ s_time_main(int argc, char **argv)
/***
* doConnection - make a connection
* Args:
- * scon= earlier ssl connection for session id, or NULL
+ * scon= earlier ssl connection for session id
* Returns:
- * SSL * = the connection pointer.
+ * 1 on success, 0 on error
*/
-static SSL *
-doConnection(SSL * scon)
+static int
+doConnection(SSL *scon)
{
struct pollfd pfd[1];
- SSL *serverCon;
BIO *conn;
long verify_error;
int i;
if ((conn = BIO_new(BIO_s_connect())) == NULL)
- return (NULL);
-
-/* BIO_set_conn_port(conn,port);*/
+ return 0;
BIO_set_conn_hostname(conn, s_time_config.host);
-
- if (scon == NULL)
- serverCon = SSL_new(tm_ctx);
- else {
- serverCon = scon;
- SSL_set_connect_state(serverCon);
- }
-
- SSL_set_bio(serverCon, conn, conn);
-
- /* ok, lets connect */
+ SSL_set_connect_state(scon);
+ SSL_set_bio(scon, conn, conn);
for (;;) {
- i = SSL_connect(serverCon);
+ i = SSL_connect(scon);
if (BIO_sock_should_retry(i)) {
BIO_printf(bio_err, "DELAY\n");
-
- i = SSL_get_fd(serverCon);
- pfd[0].fd = i;
+ pfd[0].fd = SSL_get_fd(scon);
pfd[0].events = POLLIN;
poll(pfd, 1, -1);
continue;
@@ -389,17 +375,15 @@ doConnection(SSL * scon)
}
if (i <= 0) {
BIO_printf(bio_err, "ERROR\n");
- verify_error = SSL_get_verify_result(serverCon);
+ verify_error = SSL_get_verify_result(scon);
if (verify_error != X509_V_OK)
BIO_printf(bio_err, "verify error:%s\n",
X509_verify_cert_error_string(verify_error));
else
ERR_print_errors(bio_err);
- if (scon == NULL)
- SSL_free(serverCon);
- return NULL;
+ return 0;
}
- return serverCon;
+ return 1;
}
static int
@@ -415,7 +399,9 @@ benchmark(int reuse_session)
if (reuse_session) {
/* Get an SSL object so we can reuse the session id */
- if ((scon = doConnection(NULL)) == NULL) {
+ if ((scon = SSL_new(tm_ctx)) == NULL)
+ goto end;
+ if (!doConnection(scon)) {
fprintf(stderr, "Unable to get connection\n");
goto end;
}
@@ -448,7 +434,11
Re: openssl s_time: plug SSL leak in doConnection
On Mon, Aug 13, 2018 at 07:20:38PM +0200, Theo Buehler wrote:
> On Mon, Aug 13, 2018 at 07:01:25PM +0200, Jeremie Courreges-Anglas wrote:
> > On Mon, Aug 13 2018, Scott Cheloha wrote:
> > > tb@ spotted this one.
> > >
> > > If BIO_new fails we leak scon, so SSL_free it in that case.
> > >
> > > ok?
> >
> > Alternative proposal: let doConnection() and benchmark() free the
> > resources they allocated respectively.
> >
>
> I'd be ok with that as a workaround, but it doesn't change the fact that
> doConnection() desperately needs a cleanup.
>
> As Joel pointed out off-list, it would probably be better to to move the
> call to SSL_new() out of doConnection() and then simplify the latter.
>
> Cheloha is looking into that, and I think we can give this a bit of time.
Here is such a diff.
Move SSL_new() out into benchmark() and eliminate all SSL_new/SSL_free
juggling from doConnection. Because doConnection is no longer allocating,
have it return an integer. benchmark() is now less compact but it is
clearer that we never leak an SSL object as all the allocations and frees
occur within the same scope.
The only behavior change is that we now always do SSL_set_connect_state
for the connection instead of skipping that for the object's first use.
After reading the manpage I'm pretty sure this is harmless. Can someone
more familiar with libssl weigh in, though?
The for-loop in doConnection remains peculiar, but that's cosmetic.
Thoughts?
Index: s_time.c
===
RCS file: /cvs/src/usr.bin/openssl/s_time.c,v
retrieving revision 1.26
diff -u -p -r1.26 s_time.c
--- s_time.c14 Aug 2018 15:25:04 - 1.26
+++ s_time.c17 Aug 2018 20:00:00 -
@@ -90,7 +90,7 @@
extern int verify_depth;
static void s_time_usage(void);
-static SSL *doConnection(SSL * scon);
+static int doConnection(SSL *);
static int benchmark(int);
static SSL_CTX *tm_ctx = NULL;
@@ -345,42 +345,31 @@ s_time_main(int argc, char **argv)
/***
* doConnection - make a connection
* Args:
- * scon= earlier ssl connection for session id, or NULL
+ * scon= earlier ssl connection for session id
* Returns:
- * SSL * = the connection pointer.
+ * 0 on success, nonzero on error
*/
-static SSL *
-doConnection(SSL * scon)
+int
+doConnection(SSL *scon)
{
struct pollfd pfd[1];
- SSL *serverCon;
BIO *conn;
long verify_error;
int i;
if ((conn = BIO_new(BIO_s_connect())) == NULL)
- return (NULL);
+ return 1;
-/* BIO_set_conn_port(conn,port);*/
BIO_set_conn_hostname(conn, s_time_config.host);
-
- if (scon == NULL)
- serverCon = SSL_new(tm_ctx);
- else {
- serverCon = scon;
- SSL_set_connect_state(serverCon);
- }
-
- SSL_set_bio(serverCon, conn, conn);
+ SSL_set_connect_state(scon);
+ SSL_set_bio(scon, conn, conn);
/* ok, lets connect */
for (;;) {
- i = SSL_connect(serverCon);
+ i = SSL_connect(scon);
if (BIO_sock_should_retry(i)) {
BIO_printf(bio_err, "DELAY\n");
-
- i = SSL_get_fd(serverCon);
- pfd[0].fd = i;
+ pfd[0].fd = SSL_get_fd(scon);
pfd[0].events = POLLIN;
poll(pfd, 1, -1);
continue;
@@ -389,17 +378,15 @@ doConnection(SSL * scon)
}
if (i <= 0) {
BIO_printf(bio_err, "ERROR\n");
- verify_error = SSL_get_verify_result(serverCon);
+ verify_error = SSL_get_verify_result(scon);
if (verify_error != X509_V_OK)
BIO_printf(bio_err, "verify error:%s\n",
X509_verify_cert_error_string(verify_error));
else
ERR_print_errors(bio_err);
- if (scon == NULL)
- SSL_free(serverCon);
- return NULL;
+ return 1;
}
- return serverCon;
+ return 0;
}
static int
@@ -415,7 +402,9 @@ benchmark(int reuse_session)
if (reuse_session) {
/* Get an SSL object so we can reuse the session id */
- if ((scon = doConnection(NULL)) == NULL) {
+ if ((scon = SSL_new(tm_ctx)) == NULL)
+ goto end;
+ if ((doConnection(scon)) {
fprintf(stderr, "Unable to get connection\n");
goto end;
}
@@ -448,7 +437,11 @@ benchmark(int reuse_session)
for (;;) {
if (finishtime < time(NULL))
break;
- if ((scon = doConnection(reuse_session ? scon : NULL)) ==
httpd: allow for longer "tls ciphers"
Hi, The current limit on 'tls ciphers' is 255 characters which prevents using the cipher list as recommended by https://mozilla.github.io/server-side-tls/ssl-config-generator/ for example (clocks in just shy of 300 characters). tls ciphers "ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256" results in a "ciphers too long" error. I'm aware that 'secure' and 'compat' are available too, but perhaps we can increase the limit a bit? Cheers, Jasper Index: httpd.h === RCS file: /cvs/src/usr.sbin/httpd/httpd.h,v retrieving revision 1.138 diff -u -p -r1.138 httpd.h --- httpd.h 20 Jun 2018 16:43:05 - 1.138 +++ httpd.h 17 Aug 2018 12:42:37 - @@ -60,7 +60,7 @@ #define HTTPD_LOGVIS VIS_NL|VIS_TAB|VIS_CSTYLE #define HTTPD_TLS_CERT "/etc/ssl/server.crt" #define HTTPD_TLS_KEY "/etc/ssl/private/server.key" -#define HTTPD_TLS_CONFIG_MAX 255 +#define HTTPD_TLS_CONFIG_MAX 512 #define HTTPD_TLS_CIPHERS "compat" #define HTTPD_TLS_DHE_PARAMS "none" #define HTTPD_TLS_ECDHE_CURVES "default" -- jasper
Only attach MAXCPUS cpu(4) instances
Diff below reduces the number of arm64 CPUs we attach to the maximum
that we support. Without this diff a kernel running on hardware with
more than MAXCPUS CPUs will almost certainly crash.
To make this work, the code is changed to bump ncpus whenever we
attach a secondary CPU instead of bumping it when those cores are
sucessfully spun up. Should make no difference on correctly
functioning hardware.
ok?
Index: arch/arm64/arm64/cpu.c
===
RCS file: /cvs/src/sys/arch/arm64/arm64/cpu.c,v
retrieving revision 1.22
diff -u -p -r1.22 cpu.c
--- arch/arm64/arm64/cpu.c 4 Aug 2018 11:55:40 - 1.22
+++ arch/arm64/arm64/cpu.c 17 Aug 2018 17:50:09 -
@@ -211,10 +211,14 @@ int
cpu_match(struct device *parent, void *cfdata, void *aux)
{
struct fdt_attach_args *faa = aux;
+ uint64_t mpidr = READ_SPECIALREG(mpidr_el1);
char buf[32];
- if (OF_getprop(faa->fa_node, "device_type", buf, sizeof(buf)) > 0 &&
- strcmp(buf, "cpu") == 0)
+ if (OF_getprop(faa->fa_node, "device_type", buf, sizeof(buf)) <= 0 ||
+ strcmp(buf, "cpu") != 0)
+ return 0;
+
+ if (ncpus < MAXCPUS || faa->fa_reg[0].addr == (mpidr & MPIDR_AFF))
return 1;
return 0;
@@ -243,6 +247,7 @@ cpu_attach(struct device *parent, struct
ci->ci_next = cpu_info_list->ci_next;
cpu_info_list->ci_next = ci;
ci->ci_flags |= CPUF_AP;
+ ncpus++;
}
#endif
@@ -429,7 +434,6 @@ cpu_start_secondary(struct cpu_info *ci)
uint64_t tcr;
int s;
- ncpus++;
ci->ci_flags |= CPUF_PRESENT;
__asm volatile("dsb sy");
Re: inteldrm(4) regression from 6.1 to 6.2: wrong console resolution
Mark Kettenis wrote: >Maybe you can add some printf's to figure out why the timeout is >happening? Is it actually doing a delay? Is the delay too long? Or >too short? Yes, the delay is okay. The problem is that when "cold" is 1, the vblank counter never changes during a call to drm_wait_one_vblank, so the condition inside __wait_event_intr_timeout is never true and there is a timeout. In fact the vblank counter does not even change across multiple calls to drm_wait_one_vblank, unless there is in-between a call to vblank_disable_and_save followed by a call to drm_vblank_enable. It looks like this when timing every iteration of the delay(tick) loop in the patch you proposed (delays are computed using nanouptime(9); see the dmesg at the end of this email for the complete output): XXX [drm_vblank_on] XXX [drm_vblank_on] XXX [drm_vblank_enable] XXX [drm_wait_one_vblank] drm_vblank_count before wait_event_timeout: 1, cold: 1 XXX [__wait_event_intr_timeout] delay(tick): 0 10004065, ret: 10, (condition): 0 XXX [__wait_event_intr_timeout] delay(tick): 0 1154, ret: 9, (condition): 0 XXX [__wait_event_intr_timeout] delay(tick): 0 1154, ret: 8, (condition): 0 XXX [__wait_event_intr_timeout] delay(tick): 0 1154, ret: 7, (condition): 0 XXX [__wait_event_intr_timeout] delay(tick): 0 1154, ret: 6, (condition): 0 XXX [__wait_event_intr_timeout] delay(tick): 0 1154, ret: 5, (condition): 0 XXX [__wait_event_intr_timeout] delay(tick): 0 1154, ret: 4, (condition): 0 XXX [__wait_event_intr_timeout] delay(tick): 0 875, ret: 3, (condition): 0 XXX [__wait_event_intr_timeout] delay(tick): 0 1154, ret: 2, (condition): 0 XXX [__wait_event_intr_timeout] delay(tick): 0 875, ret: 1, (condition): 0 XXX [__wait_event_intr_timeout] (condition) after loop: 0 XXX [drm_wait_one_vblank] drm_vblank_count after wait_event_timeout: 1 vblank wait timed out on crtc 0 XXX [drm_wait_one_vblank] drm_vblank_count before wait_event_timeout: 1, cold: 1 XXX [__wait_event_intr_timeout] delay(tick): 0 1153, ret: 10, (condition): 0 XXX [__wait_event_intr_timeout] delay(tick): 0 1153, ret: 9, (condition): 0 XXX [__wait_event_intr_timeout] delay(tick): 0 1153, ret: 8, (condition): 0 XXX [__wait_event_intr_timeout] delay(tick): 0 1153, ret: 7, (condition): 0 XXX [__wait_event_intr_timeout] delay(tick): 0 1153, ret: 6, (condition): 0 XXX [__wait_event_intr_timeout] delay(tick): 0 1153, ret: 5, (condition): 0 XXX [__wait_event_intr_timeout] delay(tick): 0 1153, ret: 4, (condition): 0 XXX [__wait_event_intr_timeout] delay(tick): 0 1153, ret: 3, (condition): 0 XXX [__wait_event_intr_timeout] delay(tick): 0 1153, ret: 2, (condition): 0 XXX [__wait_event_intr_timeout] delay(tick): 0 1154, ret: 1, (condition): 0 XXX [__wait_event_intr_timeout] (condition) after loop: 0 XXX [drm_wait_one_vblank] drm_vblank_count after wait_event_timeout: 1 vblank wait timed out on crtc 0 (repeat the same thing three more times) XXX [drm_wait_one_vblank] drm_vblank_count after wait_event_timeout: 1 vblank wait timed out on crtc 0 XXX [drm_vblank_off] XXX [vblank_disable_and_save] XXX [drm_vblank_on] XXX [drm_vblank_enable] XXX [drm_wait_one_vblank] drm_vblank_count before wait_event_timeout: 46, cold: 1 XXX [__wait_event_intr_timeout] delay(tick): 0 1154, ret: 10, (condition): 0 XXX [__wait_event_intr_timeout] delay(tick): 0 875, ret: 9, (condition): 0 XXX [__wait_event_intr_timeout] delay(tick): 0 1154, ret: 8, (condition): 0 XXX [__wait_event_intr_timeout] delay(tick): 0 1155, ret: 7, (condition): 0 XXX [__wait_event_intr_timeout] delay(tick): 0 1154, ret: 6, (condition): 0 XXX [__wait_event_intr_timeout] delay(tick): 0 1154, ret: 5, (condition): 0 XXX [__wait_event_intr_timeout] delay(tick): 0 1155, ret: 4, (condition): 0 XXX [__wait_event_intr_timeout] delay(tick): 0 1155, ret: 3, (condition): 0 XXX [__wait_event_intr_timeout] delay(tick): 0 1155, ret: 2, (condition): 0 XXX [__wait_event_intr_timeout] delay(tick): 0 1154, ret: 1, (condition): 0 XXX [__wait_event_intr_timeout] (condition) after loop: 0 XXX [drm_wait_one_vblank] drm_vblank_count after wait_event_timeout: 46 vblank wait timed out on crtc 0 XXX [drm_wait_one_vblank] drm_vblank_count before wait_event_timeout: 46, cold: 1 XXX [__wait_event_intr_timeout] delay(tick): 0 874, ret: 10, (condition): 0 XXX [__wait_event_intr_timeout] delay(tick): 0 1153, ret: 9, (condition): 0 XXX [__wait_event_intr_timeout] delay(tick): 0 1153, ret: 8, (condition): 0 XXX [__wait_event_intr_timeout] delay(tick): 0 1153, ret: 7, (condition): 0 XXX [__wait_event_intr_timeout] delay(tick): 0 1153, ret: 6, (condition): 0 XXX [__wait_event_intr_timeout] delay(tick): 0 1154, ret: 5, (condition): 0 XXX [__wait_event_intr_timeout] delay(tick): 0 1153, ret: 4, (condition): 0 XXX [__wait_event_intr_timeout] delay(tick): 0 1153, ret: 3, (condition): 0 XXX [__wait_event_intr_timeout]
Re: poll.2: don't encourage use as sleep
On Fri, 17 Aug 2018 10:20:09 -0500, Scott Cheloha wrote: > I don't think we should encourage or even mention the possibility of the > use of poll(2) to effect millisecond timeouts. Even if the standard library > lacks such an interface. > > I'm pretty sure you can't use this hack portably, either. > > But mostly I just think it's a misuse of the interface and potentially > confusing to a reader of such code: The way to effect a sleep using poll() is to set nfds to 0, not by setting fds to NULL so that text was incorrect anyway. Since POSIX doesn't explicitly say it is supported, and since there are better APIs for this anyway I think removing the text makes sense. OK millert@ - todd
Re: poll.2: don't encourage use as sleep
And I agree. The idiom remains possible, it just doesn't need to me mentioned / encouraged. Ingo Schwarze wrote: > Hi Scott, > > Scott Cheloha wrote on Fri, Aug 17, 2018 at 10:20:09AM -0500: > > > I don't think we should encourage or even mention the possibility of the > > use of poll(2) to effect millisecond timeouts. Even if the standard > > library lacks such an interface. > > > > I'm pretty sure you can't use this hack portably, either. > > > > But mostly I just think it's a misuse of the interface and potentially > > confusing to a reader of such code: > > Nowadays, POSIX has nanosleep(2). Before that, XPG had the now > obsolete usleep(3) that appeared in 4.3BSD, but which never made > it into POSIX. Before nanosleep(2) became firmly established, using > select(2) for portably sleeping less than a second was common IIRC. > So the reason for the recommendation may be that poll(2) intends > to replace select(2). > > I agree that recommending poll(2) for the functionality of nanosleep(2) > no longer makes sense. > > Note that your diff also removes the information about what happens > when fds == NULL. If i read it correctly, POSIX does not specify > that, so you may be right that there might be some system out there > where it doesn't work. > > Leaving behaviour that is unspecified by the standard unspecified > in the manual page is often a good idea, unless we specifically > want to support it as an extension. Guaranteeing such an extension > does not seem useful to me in the present case. > > So, your diff is OK schwarze@, but i think you need another OK from > a developer who is more familiar with networking or low-level I/O. > > Yours, > Ingo > > > > Index: lib/libc/sys/poll.2 > > === > > RCS file: /cvs/src/lib/libc/sys/poll.2,v > > retrieving revision 1.35 > > diff -u -p -r1.35 poll.2 > > --- lib/libc/sys/poll.2 14 Feb 2017 17:51:14 - 1.35 > > +++ lib/libc/sys/poll.2 17 Aug 2018 14:55:48 - > > @@ -183,12 +183,6 @@ and > > flags may be used to detect when out-of-band socket data may be read > > without blocking. > > .Pp > > -In addition to I/O multiplexing, > > -.Fn poll > > -can be used to generate simple timeouts. > > -This functionality may be achieved by passing a null pointer for > > -.Fa fds . > > -.Pp > > The > > .Fn ppoll > > function is similar to >
Re: poll.2: don't encourage use as sleep
Hi Scott, Scott Cheloha wrote on Fri, Aug 17, 2018 at 10:20:09AM -0500: > I don't think we should encourage or even mention the possibility of the > use of poll(2) to effect millisecond timeouts. Even if the standard > library lacks such an interface. > > I'm pretty sure you can't use this hack portably, either. > > But mostly I just think it's a misuse of the interface and potentially > confusing to a reader of such code: Nowadays, POSIX has nanosleep(2). Before that, XPG had the now obsolete usleep(3) that appeared in 4.3BSD, but which never made it into POSIX. Before nanosleep(2) became firmly established, using select(2) for portably sleeping less than a second was common IIRC. So the reason for the recommendation may be that poll(2) intends to replace select(2). I agree that recommending poll(2) for the functionality of nanosleep(2) no longer makes sense. Note that your diff also removes the information about what happens when fds == NULL. If i read it correctly, POSIX does not specify that, so you may be right that there might be some system out there where it doesn't work. Leaving behaviour that is unspecified by the standard unspecified in the manual page is often a good idea, unless we specifically want to support it as an extension. Guaranteeing such an extension does not seem useful to me in the present case. So, your diff is OK schwarze@, but i think you need another OK from a developer who is more familiar with networking or low-level I/O. Yours, Ingo > Index: lib/libc/sys/poll.2 > === > RCS file: /cvs/src/lib/libc/sys/poll.2,v > retrieving revision 1.35 > diff -u -p -r1.35 poll.2 > --- lib/libc/sys/poll.2 14 Feb 2017 17:51:14 - 1.35 > +++ lib/libc/sys/poll.2 17 Aug 2018 14:55:48 - > @@ -183,12 +183,6 @@ and > flags may be used to detect when out-of-band socket data may be read > without blocking. > .Pp > -In addition to I/O multiplexing, > -.Fn poll > -can be used to generate simple timeouts. > -This functionality may be achieved by passing a null pointer for > -.Fa fds . > -.Pp > The > .Fn ppoll > function is similar to
poll.2: don't encourage use as sleep
I don't think we should encourage or even mention the possibility of the use of poll(2) to effect millisecond timeouts. Even if the standard library lacks such an interface. I'm pretty sure you can't use this hack portably, either. But mostly I just think it's a misuse of the interface and potentially confusing to a reader of such code: ok? -- Scott Cheloha Index: lib/libc/sys/poll.2 === RCS file: /cvs/src/lib/libc/sys/poll.2,v retrieving revision 1.35 diff -u -p -r1.35 poll.2 --- lib/libc/sys/poll.2 14 Feb 2017 17:51:14 - 1.35 +++ lib/libc/sys/poll.2 17 Aug 2018 14:55:48 - @@ -183,12 +183,6 @@ and flags may be used to detect when out-of-band socket data may be read without blocking. .Pp -In addition to I/O multiplexing, -.Fn poll -can be used to generate simple timeouts. -This functionality may be achieved by passing a null pointer for -.Fa fds . -.Pp The .Fn ppoll function is similar to
Re: Status of openbsd/macppc port?
On 17/08/18 14:27, Mark Kettenis wrote: >> Obviously I can't categorically state that QEMU's emulation is perfect, >> but it can now reliably run all of Linux, MacOS, NetBSD and FreeBSD in >> my local tests which makes me suspect that OpenBSD is trying to do >> something different here. > > Runs fairly stable as long as there is enough RAM. There is an > (unknown) pmap bug that causes memory corruption as soon as the > machine starts swapping. Right, I wonder if this is related to the invalid memory accesses I'm seeing in QEMU? Fortunately it's fairly easy to boot different images within the VM, so let's go backwards in time... OpenBSD 6.1 - Boots to userspace, but hangs quickly at the installer shell OpenBSD 6.0 - Hangs on boot just after the USB controller initialises OpenBSD 5.9 - Boots to userspace, but hangs quickly at the installer shell (qemu console logs attempt to execute a NULL opcode, so looks like we're jumping off somewhere strange?) OpenBSD 5.8 - Hangs on boot just after the USB controller initialises (qemu console logs an attempt to execute an invalid/unsupported opcode: 00 - 1c - 17 - 0a (004ad5f8) 1) OpenBSD 5.7 - Lots of "mac_intr_establish called, not yet inited" warnings in the kernel dmesg output - However it boots to userspace and the installer shell seems stable OpenBSD 5.6 - Panics with a stack smash warning: OpenBSD 5.6 (RAMDISK) #163: Fri Aug 8 09:05:59 MDT 2014 dera...@macppc.openbsd.org:/usr/src/sys/arch/macppc/compile/RAMDISK real mem = 1073741824 (1024MB) avail mem = 1029210112 (981MB) warning: no entropy supplied by boot loader mainbus0 at root: model PowerMac3,1 cpu0 at mainbus0: 7400 (Revision 0x209): 900 MHz: L2 cache not enabled mem at mainbus0 not configured mpcpcibr0 at mainbus0 pci: uni-north pci0 at mpcpcibr0 bus 0 panic: smashed stack in ofw_enumerate_pcibus Stopped at Debugger+0x10: lwz r0,36(r1) 00a00ae4: end+0x561cc fp a00ac0 nfp a00ae0 001ee6dc: panic+0xe0 fp a00ae0 nfp a00b40 001e235c: __stack_smash_handler+0x18 fp a00b40 nfp a00b60 0037ea18: ofw_enumerate_pcibus+0x1b0 fp a00b60 nfp a00bc0 0031bc90: pciattach+0xf0 fp a00bc0 nfp a00bf0 001e3e50: config_attach+0x1f0 fp a00bf0 nfp a00c40 0037dc0c: mpcpcibrattach+0x3b0 fp a00c40 nfp a00d60 001e3e50: config_attach+0x1f0 fp a00d60 nfp a00db0 003095f0: dbdma_flush+0x4d8 fp a00db0 nfp a00e90 001e3e50: config_attach+0x1f0 fp a00e90 nfp a00ee0 RUN AT LEAST 'trace' AND 'ps' AND INCLUDE OUTPUT WHEN REPORTING THIS PANIC! DO NOT EVEN BOTHER REPORTING THIS WITHOUT INCLUDING THAT INFORMATION! ddb> trace 00a00ae4: end+0x561cc fp a00ac0 nfp a00ae0 001ee6dc: panic+0xe0 fp a00ae0 nfp a00b40 001e235c: __stack_smash_handler+0x18 fp a00b40 nfp a00b60 0037ea18: ofw_enumerate_pcibus+0x1b0 fp a00b60 nfp a00bc0 0031bc90: pciattach+0xf0 fp a00bc0 nfp a00bf0 001e3e50: config_attach+0x1f0 fp a00bf0 nfp a00c40 0037dc0c: mpcpcibrattach+0x3b0 fp a00c40 nfp a00d60 001e3e50: config_attach+0x1f0 fp a00d60 nfp a00db0 003095f0: dbdma_flush+0x4d8 fp a00db0 nfp a00e90 001e3e50: config_attach+0x1f0 fp a00e90 nfp a00ee0 002f63ec: cpu_configure+0x24 fp a00ee0 nfp a00f00 001c525c: main+0x3f0 fp a00f00 nfp a00f40 001001bc: kernel_text+0xa8 fp a00f40 nfp 0 ddb> ps PID PPID PGRPUID S FLAGS WAIT COMMAND *0 -1 0 0 7 0x10200swapper ddb> OpenBSD 5.5 - Lots of "mac_intr_establish called, not yet inited" warnings in the kernel dmesg output - Panics on boot when initialising USB: uhub0 at usb0 "Apple OHCI root hub" rev 1.00/1.00 addr 1 panic: trap type 600 at 2cf4a0 (mtx_enter+0x28) lr 2cf490 Stopped at Debugger+0x10: lwz r0,20(r1) 00fc: tlbdsmsize+0x14 fp 94ba70 nfp 94ba80 001cec40: panic+0xd0 fp 94ba80 nfp 94bae0 002ce8cc: trap+0x184 fp 94bae0 nfp 94bb60 00100900: ddblow+0x1ac fp 94bb60 nfp 94bc10 002cf48c: mtx_enter+0x14 fp 94bc10 nfp 94bc20 001c4a50: config_attach+0x200 fp 94bc20 nfp 94bc60 00351018: mpcpcibrattach+0x3b0 fp 94bc60 nfp 94bd80 001c4a40: config_attach+0x1f0 fp 94bd80 nfp 94bdc0 002e4af0: mb_matchname+0x4e8 fp 94bdc0 nfp 94beb0 001c4a40: config_attach+0x1f0 fp 94beb0 nfp 94bef0 RUN AT LEAST 'trace' AND 'ps' AND INCLUDE OUTPUT WHEN REPORTING THIS PANIC! DO NOT EVEN BOTHER REPORTING THIS WITHOUT INCLUDING THAT INFORMATION! ddb> trace 00fc: tlbdsmsize+0x14 fp 94ba70 nfp 94ba80 001cec40: panic+0xd0 fp 94ba80 nfp 94bae0 002ce8cc: trap+0x184 fp 94bae0 nfp 94bb60 00100900: ddblow+0x1ac fp 94bb60 nfp 94bc10 002cf48c: mtx_enter+0x14 fp 94bc10 nfp 94bc20 001c4a50: config_attach+0x200 fp 94bc20 nfp 94bc60 00351018: mpcpcibrattach+0x3b0 fp 94bc60 nfp 94bd80 001c4a40: config_attach+0x1f0 fp 94bd80 nfp 94bdc0 002e4af0: mb_matchname+0x4e8 fp 94bdc0 nfp 94beb0 001c4a40: config_attach+0x1f0 fp 94beb0 nfp 94bef0 002d1d9c: cpu_configure+0x24 fp 94bef0 nfp 94bf00 001a7314: main+0x3cc fp 94bf00 nfp 94bf40 001001bc: kernel_text+0xa8 fp 94bf40 nfp 0 ddb> ps PID PPID PGRPUID S FLAGS WAIT COMMAND *0 -1 0 0 7
Re: Status of openbsd/macppc port?
> On Aug 17, 2018, at 8:37 AM, Solene Rapenne wrote: > > The sad state is that less and less > ports are running on them. > The last package count for 6.3 shows macppc had the most packages after amd64 and i386. Can you share examples of ports you’re missing? I’d be interested to look at anything that’s not working (and doesn’t take 3 weeks to build). ps. numpy on macppc was broken for a short period of time which took out part of the tree, but that is fixed as far as i know. see this thread: https://marc.info/?t=15321658432=1=2
Re: Status of openbsd/macppc port?
> From: Mark Cave-Ayland > Date: Fri, 17 Aug 2018 12:15:10 +0100 > > Hi all, > > I was just wondering what is the current state of the openbsd/macppc > port? As part of my recent work on qemu-system-ppc I now have a patch > that can boot OpenBSD macppc under the New World (-M mac99,via=pmu) > machine but I'm seeing quite a bit of instability in OpenBSD compared to > all my other test OSs. > > For those that are interested I have included screenshots below: > > OpenBSD 6.3 > - Hangs just after USB detection > - https://www.ilande.co.uk/tmp/qemu/openbsd-6.3.png > > OpenBSD 6.2 > - Panics just after USB detection > - https://www.ilande.co.uk/tmp/qemu/openbsd-6.2.png > > OpenBSD 6.1 > - Boots all the way to the installer but causes qemu-system-ppc to > terminate fairly easily after pressing a few keys with "qemu: fatal: > ERROR: instruction should not need address translation" > - https://www.ilande.co.uk/tmp/qemu/openbsd-6.1.png > > Note I also get a constant stream of messages on the console related to > OpenPIC: > > qemu-system-ppc: openpic_iack: bad raised IRQ 47 ctpr 8 ivpr 0x4047002f > qemu-system-ppc: openpic_iack: bad raised IRQ 47 ctpr 8 ivpr 0x4047002f > qemu-system-ppc: openpic_iack: bad raised IRQ 47 ctpr 8 ivpr 0x4047002f > qemu-system-ppc: openpic_iack: bad raised IRQ 47 ctpr 8 ivpr 0x4047002f > qemu-system-ppc: openpic_iack: bad raised IRQ 28 ctpr 8 ivpr 0x4045001c > qemu-system-ppc: openpic_iack: bad raised IRQ 28 ctpr 8 ivpr 0x4045001c > qemu-system-ppc: openpic_iack: bad raised IRQ 28 ctpr 8 ivpr 0x4045001c > etc. > > > Obviously I can't categorically state that QEMU's emulation is perfect, > but it can now reliably run all of Linux, MacOS, NetBSD and FreeBSD in > my local tests which makes me suspect that OpenBSD is trying to do > something different here. Runs fairly stable as long as there is enough RAM. There is an (unknown) pmap bug that causes memory corruption as soon as the machine starts swapping.
Re: Status of openbsd/macppc port?
Mark Cave-Ayland wrote: > On 17/08/18 13:55, Solene Rapenne wrote: > > > I'm using the macppc port since 6.1 to -current and apart failing > > harware I don't have any issue while playing Doom or rebuilind ports :) > > Hmmm. 6.1 is the latest version that I can boot to userspace, even if it > faults quickly after a few keypresses (QEMU is generally really strict > on invalid memory accesses which is basically what I see, but once the > access is tracked down it would be possible to fix it). > > I'd be interested to know if you are able to at least boot a 6.3 > installation CDROM on the Mac Mini to the installer without hanging, > which is probably the closest match to what I'm doing on real hardware. > > > ATB, > > Mark. This is interesting as I never used a CDROM for installation, I don't have a burner anymore and I'm not sure that the cdrom reader still work but boot from PXE.
Re: Status of openbsd/macppc port?
On Fri, Aug 17, 2018 at 8:48 AM, Mark Cave-Ayland wrote: > On 17/08/18 13:34, Jonathan Gray wrote: > >> On Fri, Aug 17, 2018 at 12:15:10PM +0100, Mark Cave-Ayland wrote: >>> Hi all, >>> >>> I was just wondering what is the current state of the openbsd/macppc >>> port? As part of my recent work on qemu-system-ppc I now have a patch >>> that can boot OpenBSD macppc under the New World (-M mac99,via=pmu) >>> machine but I'm seeing quite a bit of instability in OpenBSD compared to >>> all my other test OSs. >>> >>> For those that are interested I have included screenshots below: >>> >>> OpenBSD 6.3 >>> - Hangs just after USB detection >>> - https://www.ilande.co.uk/tmp/qemu/openbsd-6.3.png >>> >>> OpenBSD 6.2 >>> - Panics just after USB detection >>> - https://www.ilande.co.uk/tmp/qemu/openbsd-6.2.png >>> >>> OpenBSD 6.1 >>> - Boots all the way to the installer but causes qemu-system-ppc to >>> terminate fairly easily after pressing a few keys with "qemu: fatal: >>> ERROR: instruction should not need address translation" >>> - https://www.ilande.co.uk/tmp/qemu/openbsd-6.1.png >>> >>> Note I also get a constant stream of messages on the console related to >>> OpenPIC: >>> >>> qemu-system-ppc: openpic_iack: bad raised IRQ 47 ctpr 8 ivpr 0x4047002f >>> qemu-system-ppc: openpic_iack: bad raised IRQ 47 ctpr 8 ivpr 0x4047002f >>> qemu-system-ppc: openpic_iack: bad raised IRQ 47 ctpr 8 ivpr 0x4047002f >>> qemu-system-ppc: openpic_iack: bad raised IRQ 47 ctpr 8 ivpr 0x4047002f >>> qemu-system-ppc: openpic_iack: bad raised IRQ 28 ctpr 8 ivpr 0x4045001c >>> qemu-system-ppc: openpic_iack: bad raised IRQ 28 ctpr 8 ivpr 0x4045001c >>> qemu-system-ppc: openpic_iack: bad raised IRQ 28 ctpr 8 ivpr 0x4045001c >>> etc. >>> >>> >>> Obviously I can't categorically state that QEMU's emulation is perfect, >>> but it can now reliably run all of Linux, MacOS, NetBSD and FreeBSD in >>> my local tests which makes me suspect that OpenBSD is trying to do >>> something different here. >> >> Builds are done natively on real hardware (xserves). Your work on >> qemu-system-ppc would be improved by being able to compare to a real >> machine while it is still possible to find some that work. You could >> search bugs@ but I don't believe any of those problems have been reported >> running on actual macppc machines. > > Thanks for information. I guess there is a difference between being able > to build and run the guest OS - for example do the builds get regularly > tested on any Sawtooth-type PowerMac3,1 machines (which is effectively > what QEMU is trying to emulate)? > Hi Mark, I regularly run macppc. Here's my dmesg from a PowerMac10,2 which is a Mac Mini G4 and where I do all my ports building: http://dickman.org/openbsd/dmesg/dmesg.macppc I also have other macppc hardware which runs quite well. The only problem case is my G5 where the hard drive does not get detected. Hope this helps.
Re: Status of openbsd/macppc port?
On 17/08/18 13:55, Solene Rapenne wrote: > I'm using the macppc port since 6.1 to -current and apart failing > harware I don't have any issue while playing Doom or rebuilind ports :) Hmmm. 6.1 is the latest version that I can boot to userspace, even if it faults quickly after a few keypresses (QEMU is generally really strict on invalid memory accesses which is basically what I see, but once the access is tracked down it would be possible to fix it). I'd be interested to know if you are able to at least boot a 6.3 installation CDROM on the Mac Mini to the installer without hanging, which is probably the closest match to what I'm doing on real hardware. ATB, Mark.
Re: Status of openbsd/macppc port?
Mark Cave-Ayland wrote: > On 17/08/18 13:37, Solene Rapenne wrote: > > Mark Cave-Ayland wrote: > >> Hi all, > >> > >> I was just wondering what is the current state of the openbsd/macppc > >> port? As part of my recent work on qemu-system-ppc I now have a patch > >> that can boot OpenBSD macppc under the New World (-M mac99,via=pmu) > >> machine but I'm seeing quite a bit of instability in OpenBSD compared to > >> all my other test OSs. > > > Hello > > > > I can't help you much with your qemu issue but I can confirm you that > > the OpenBSD macppc port works really well as I use 2 macppc devices (an > > mac mini and a powerbook) often. The sad state is that less and less > > ports are running on them. > > Thanks for the response Solene. Can I ask which version of > openbsd/macppc you are currently running? > > > ATB, > > Mark. I'm using the macppc port since 6.1 to -current and apart failing harware I don't have any issue while playing Doom or rebuilind ports :)
Re: Status of openbsd/macppc port?
On 17/08/18 13:37, Solene Rapenne wrote: > Mark Cave-Ayland wrote: >> Hi all, >> >> I was just wondering what is the current state of the openbsd/macppc >> port? As part of my recent work on qemu-system-ppc I now have a patch >> that can boot OpenBSD macppc under the New World (-M mac99,via=pmu) >> machine but I'm seeing quite a bit of instability in OpenBSD compared to >> all my other test OSs. > Hello > > I can't help you much with your qemu issue but I can confirm you that > the OpenBSD macppc port works really well as I use 2 macppc devices (an > mac mini and a powerbook) often. The sad state is that less and less > ports are running on them. Thanks for the response Solene. Can I ask which version of openbsd/macppc you are currently running? ATB, Mark.
Re: Status of openbsd/macppc port?
On 17/08/18 13:34, Jonathan Gray wrote: > On Fri, Aug 17, 2018 at 12:15:10PM +0100, Mark Cave-Ayland wrote: >> Hi all, >> >> I was just wondering what is the current state of the openbsd/macppc >> port? As part of my recent work on qemu-system-ppc I now have a patch >> that can boot OpenBSD macppc under the New World (-M mac99,via=pmu) >> machine but I'm seeing quite a bit of instability in OpenBSD compared to >> all my other test OSs. >> >> For those that are interested I have included screenshots below: >> >> OpenBSD 6.3 >> - Hangs just after USB detection >> - https://www.ilande.co.uk/tmp/qemu/openbsd-6.3.png >> >> OpenBSD 6.2 >> - Panics just after USB detection >> - https://www.ilande.co.uk/tmp/qemu/openbsd-6.2.png >> >> OpenBSD 6.1 >> - Boots all the way to the installer but causes qemu-system-ppc to >> terminate fairly easily after pressing a few keys with "qemu: fatal: >> ERROR: instruction should not need address translation" >> - https://www.ilande.co.uk/tmp/qemu/openbsd-6.1.png >> >> Note I also get a constant stream of messages on the console related to >> OpenPIC: >> >> qemu-system-ppc: openpic_iack: bad raised IRQ 47 ctpr 8 ivpr 0x4047002f >> qemu-system-ppc: openpic_iack: bad raised IRQ 47 ctpr 8 ivpr 0x4047002f >> qemu-system-ppc: openpic_iack: bad raised IRQ 47 ctpr 8 ivpr 0x4047002f >> qemu-system-ppc: openpic_iack: bad raised IRQ 47 ctpr 8 ivpr 0x4047002f >> qemu-system-ppc: openpic_iack: bad raised IRQ 28 ctpr 8 ivpr 0x4045001c >> qemu-system-ppc: openpic_iack: bad raised IRQ 28 ctpr 8 ivpr 0x4045001c >> qemu-system-ppc: openpic_iack: bad raised IRQ 28 ctpr 8 ivpr 0x4045001c >> etc. >> >> >> Obviously I can't categorically state that QEMU's emulation is perfect, >> but it can now reliably run all of Linux, MacOS, NetBSD and FreeBSD in >> my local tests which makes me suspect that OpenBSD is trying to do >> something different here. > > Builds are done natively on real hardware (xserves). Your work on > qemu-system-ppc would be improved by being able to compare to a real > machine while it is still possible to find some that work. You could > search bugs@ but I don't believe any of those problems have been reported > running on actual macppc machines. Thanks for information. I guess there is a difference between being able to build and run the guest OS - for example do the builds get regularly tested on any Sawtooth-type PowerMac3,1 machines (which is effectively what QEMU is trying to emulate)? FWIW from the screenshots above the "bad IRQs" being complained about above can be show to be macgpio1 (IRQ 47) and ohci0 (IRQ 28). Is there anything special about these interrupts at all, e.g. edge vs. level triggering? ATB, Mark.
Re: Status of openbsd/macppc port?
Mark Cave-Ayland wrote: > Hi all, > > I was just wondering what is the current state of the openbsd/macppc > port? As part of my recent work on qemu-system-ppc I now have a patch > that can boot OpenBSD macppc under the New World (-M mac99,via=pmu) > machine but I'm seeing quite a bit of instability in OpenBSD compared to > all my other test OSs. > > For those that are interested I have included screenshots below: > > OpenBSD 6.3 > - Hangs just after USB detection > - https://www.ilande.co.uk/tmp/qemu/openbsd-6.3.png > > OpenBSD 6.2 > - Panics just after USB detection > - https://www.ilande.co.uk/tmp/qemu/openbsd-6.2.png > > OpenBSD 6.1 > - Boots all the way to the installer but causes qemu-system-ppc to > terminate fairly easily after pressing a few keys with "qemu: fatal: > ERROR: instruction should not need address translation" > - https://www.ilande.co.uk/tmp/qemu/openbsd-6.1.png > > Note I also get a constant stream of messages on the console related to > OpenPIC: > > qemu-system-ppc: openpic_iack: bad raised IRQ 47 ctpr 8 ivpr 0x4047002f > qemu-system-ppc: openpic_iack: bad raised IRQ 47 ctpr 8 ivpr 0x4047002f > qemu-system-ppc: openpic_iack: bad raised IRQ 47 ctpr 8 ivpr 0x4047002f > qemu-system-ppc: openpic_iack: bad raised IRQ 47 ctpr 8 ivpr 0x4047002f > qemu-system-ppc: openpic_iack: bad raised IRQ 28 ctpr 8 ivpr 0x4045001c > qemu-system-ppc: openpic_iack: bad raised IRQ 28 ctpr 8 ivpr 0x4045001c > qemu-system-ppc: openpic_iack: bad raised IRQ 28 ctpr 8 ivpr 0x4045001c > etc. > > > Obviously I can't categorically state that QEMU's emulation is perfect, > but it can now reliably run all of Linux, MacOS, NetBSD and FreeBSD in > my local tests which makes me suspect that OpenBSD is trying to do > something different here. > > > ATB, > > Mark. Hello I can't help you much with your qemu issue but I can confirm you that the OpenBSD macppc port works really well as I use 2 macppc devices (an mac mini and a powerbook) often. The sad state is that less and less ports are running on them.
Re: Status of openbsd/macppc port?
On Fri, Aug 17, 2018 at 12:15:10PM +0100, Mark Cave-Ayland wrote: > Hi all, > > I was just wondering what is the current state of the openbsd/macppc > port? As part of my recent work on qemu-system-ppc I now have a patch > that can boot OpenBSD macppc under the New World (-M mac99,via=pmu) > machine but I'm seeing quite a bit of instability in OpenBSD compared to > all my other test OSs. > > For those that are interested I have included screenshots below: > > OpenBSD 6.3 > - Hangs just after USB detection > - https://www.ilande.co.uk/tmp/qemu/openbsd-6.3.png > > OpenBSD 6.2 > - Panics just after USB detection > - https://www.ilande.co.uk/tmp/qemu/openbsd-6.2.png > > OpenBSD 6.1 > - Boots all the way to the installer but causes qemu-system-ppc to > terminate fairly easily after pressing a few keys with "qemu: fatal: > ERROR: instruction should not need address translation" > - https://www.ilande.co.uk/tmp/qemu/openbsd-6.1.png > > Note I also get a constant stream of messages on the console related to > OpenPIC: > > qemu-system-ppc: openpic_iack: bad raised IRQ 47 ctpr 8 ivpr 0x4047002f > qemu-system-ppc: openpic_iack: bad raised IRQ 47 ctpr 8 ivpr 0x4047002f > qemu-system-ppc: openpic_iack: bad raised IRQ 47 ctpr 8 ivpr 0x4047002f > qemu-system-ppc: openpic_iack: bad raised IRQ 47 ctpr 8 ivpr 0x4047002f > qemu-system-ppc: openpic_iack: bad raised IRQ 28 ctpr 8 ivpr 0x4045001c > qemu-system-ppc: openpic_iack: bad raised IRQ 28 ctpr 8 ivpr 0x4045001c > qemu-system-ppc: openpic_iack: bad raised IRQ 28 ctpr 8 ivpr 0x4045001c > etc. > > > Obviously I can't categorically state that QEMU's emulation is perfect, > but it can now reliably run all of Linux, MacOS, NetBSD and FreeBSD in > my local tests which makes me suspect that OpenBSD is trying to do > something different here. Builds are done natively on real hardware (xserves). Your work on qemu-system-ppc would be improved by being able to compare to a real machine while it is still possible to find some that work. You could search bugs@ but I don't believe any of those problems have been reported running on actual macppc machines.
Status of openbsd/macppc port?
Hi all, I was just wondering what is the current state of the openbsd/macppc port? As part of my recent work on qemu-system-ppc I now have a patch that can boot OpenBSD macppc under the New World (-M mac99,via=pmu) machine but I'm seeing quite a bit of instability in OpenBSD compared to all my other test OSs. For those that are interested I have included screenshots below: OpenBSD 6.3 - Hangs just after USB detection - https://www.ilande.co.uk/tmp/qemu/openbsd-6.3.png OpenBSD 6.2 - Panics just after USB detection - https://www.ilande.co.uk/tmp/qemu/openbsd-6.2.png OpenBSD 6.1 - Boots all the way to the installer but causes qemu-system-ppc to terminate fairly easily after pressing a few keys with "qemu: fatal: ERROR: instruction should not need address translation" - https://www.ilande.co.uk/tmp/qemu/openbsd-6.1.png Note I also get a constant stream of messages on the console related to OpenPIC: qemu-system-ppc: openpic_iack: bad raised IRQ 47 ctpr 8 ivpr 0x4047002f qemu-system-ppc: openpic_iack: bad raised IRQ 47 ctpr 8 ivpr 0x4047002f qemu-system-ppc: openpic_iack: bad raised IRQ 47 ctpr 8 ivpr 0x4047002f qemu-system-ppc: openpic_iack: bad raised IRQ 47 ctpr 8 ivpr 0x4047002f qemu-system-ppc: openpic_iack: bad raised IRQ 28 ctpr 8 ivpr 0x4045001c qemu-system-ppc: openpic_iack: bad raised IRQ 28 ctpr 8 ivpr 0x4045001c qemu-system-ppc: openpic_iack: bad raised IRQ 28 ctpr 8 ivpr 0x4045001c etc. Obviously I can't categorically state that QEMU's emulation is perfect, but it can now reliably run all of Linux, MacOS, NetBSD and FreeBSD in my local tests which makes me suspect that OpenBSD is trying to do something different here. ATB, Mark.
Re: umsm(4) and umb(4) separate loading for the same composite USB modem device
Sierra Wireless EM/MC7455 AT!USBCOMP=? !USBCOMP: AT!USBCOMP=,, - configuration index to which the composition applies, sould be 1 - 1:Generic, 2:USBIF-MBIM, 3:RNDIS config type 2/3 should only be used for specific SierraPIDs: 68B1, 9068 customized VID/PID should use config type 1 - DIAG - 0x0001, NMEA - 0x0004, MODEM- 0x0008, RMNET0 - 0x0100, RMNET1 - 0x0400, MBIM - 0x1000, *** AT!USBCOMP=1,1,100D (DIAG, NMEA, MODEM/AT, MBIM) - required preferred configuration Sierra Wireless MC7455 Qualcomm® Snapdragon™ X7 LTE-A VID=0x1199 PID=0x9071 Device Descriptor: -- 0x12bLength 0x01bDescriptorType 0x0210 bcdUSB 0x00bDeviceClass 0x00bDeviceSubClass 0x00bDeviceProtocol 0x40bMaxPacketSize0 (64 bytes) 0x1199 idVendor 0x9071 idProduct 0x0006 bcdDevice 0x01iManufacturer "Sierra Wireless, Incorporated" 0x02iProduct "Sierra Wireless MC7455 Qualcomm® Snapdragon™ X7 LTE-A" 0x03iSerialNumber "LQ63925174367653" 0x01bNumConfigurations Device Qualifier Descriptor: -- 0x0AbLength 0x06bDescriptorType 0x0210 bcdUSB 0x00bDeviceClass 0x00bDeviceSubClass 0x00bDeviceProtocol 0x40bMaxPacketSize0 (64 bytes) 0x01bNumConfigurations 0x00bReserved Configuration Descriptor: -- 0x09bLength 0x02bDescriptorType 0x00D8 wTotalLength (216 bytes) 0x05bNumInterfaces 0x01bConfigurationValue 0x00iConfiguration 0xA0bmAttributes (Bus-powered Device, Remote-Wakeup) 0xFAbMaxPower (500 mA) Interface Descriptor: -- 0x09bLength 0x04bDescriptorType 0x00bInterfaceNumber 0x00bAlternateSetting 0x02bNumEndPoints 0xFFbInterfaceClass (Vendor specific) 0xFFbInterfaceSubClass 0xFFbInterfaceProtocol 0x00iInterface Endpoint Descriptor: -- 0x07bLength 0x05bDescriptorType 0x81bEndpointAddress (IN endpoint 1) 0x02bmAttributes (Transfer: Bulk / Synch: None / Usage: Data) 0x0200 wMaxPacketSize(512 bytes) 0x00bInterval Endpoint Descriptor: -- 0x07bLength 0x05bDescriptorType 0x01bEndpointAddress (OUT endpoint 1) 0x02bmAttributes (Transfer: Bulk / Synch: None / Usage: Data) 0x0200 wMaxPacketSize(512 bytes) 0x00bInterval Interface Descriptor: -- 0x09bLength 0x04bDescriptorType 0x02bInterfaceNumber 0x00bAlternateSetting 0x03bNumEndPoints 0xFFbInterfaceClass (Vendor specific) 0x00bInterfaceSubClass 0x00bInterfaceProtocol 0x00iInterface Unknown Descriptor: -- 0x05bLength 0x24bDescriptorType Hex dump: 0x05 0x24 0x00 0x10 0x01 Unknown Descriptor: -- 0x05bLength 0x24bDescriptorType Hex dump: 0x05 0x24 0x01 0x00 0x00 Unknown Descriptor: -- 0x04bLength 0x24bDescriptorType Hex dump: 0x04 0x24 0x02 0x02 Unknown Descriptor: -- 0x05bLength 0x24bDescriptorType Hex dump: 0x05 0x24 0x06 0x00 0x00 Endpoint Descriptor: -- 0x07bLength 0x05bDescriptorType 0x83bEndpointAddress (IN endpoint 3) 0x03bmAttributes (Transfer: Interrupt / Synch: None / Usage: Data) 0x000A wMaxPacketSize(1 x 10 bytes) 0x09bInterval (256 microframes) Endpoint Descriptor: -- 0x07bLength 0x05bDescriptorType 0x82bEndpointAddress (IN endpoint 2) 0x02bmAttributes (Transfer: Bulk / Synch: None / Usage: Data) 0x0200 wMaxPacketSize(512 bytes) 0x00bInterval Endpoint Descriptor: -- 0x07bLength 0x05bDescriptorType 0x02bEndpointAddress (OUT endpoint 2) 0x02bmAttributes (Transfer: Bulk / Synch: None / Usage: Data) 0x0200 wMaxPacketSize(512 bytes) 0x00bInterval Interface Descriptor: -- 0x09bLength 0x04bDescriptorType 0x03bInterfaceNumber 0x00bAlternateSetting 0x03bNumEndPoints 0xFFbInterfaceClass (Vendor specific) 0x00bInterfaceSubClass 0x00bInterfaceProtocol 0x00iInterface Unknown Descriptor: -- 0x05bLength 0x24bDescriptorType Hex dump: 0x05 0x24 0x00 0x10 0x01 Unknown Descriptor: -- 0x05bLength 0x24bDescriptorType Hex dump: 0x05 0x24 0x01 0x00 0x00 Unknown Descriptor: -- 0x04bLength 0x24bDescriptorType Hex dump: 0x04 0x24 0x02 0x02 Unknown Descriptor: -- 0x05bLength 0x24
Re: umsm(4) and umb(4) separate loading for the same composite USB modem device
Sierra Wireless MC7304 ordinary firmware (no voice support): SWI9X15C_05.05.67.00 r31378 CARMD-EV-FRMWR1 2016/03/11 14:58:53 0 - reserved NOT SUPPORTED 1 - DM AT SUPPORTED 2 - reserved NOT SUPPORTED 3 - reserved NOT SUPPORTED 4 - reserved NOT SUPPORTED 5 - reserved NOT SUPPORTED 6 - DM NMEA ATQMI SUPPORTED 7 - DM NMEA ATRMNET1 RMNET2 RMNET3SUPPORTED 8 - DM NMEA ATMBIMSUPPORTED 9 - MBIM SUPPORTED 10 - NMEA MBIMSUPPORTED 11 - DM MBIMSUPPORTED 12 - DM NMEA MBIM SUPPORTED 13 - Config1: comp6Config2: comp8 NOT SUPPORTED 14 - Config1: comp6Config2: comp9 SUPPORTED 15 - Config1: comp6Config2: comp10NOT SUPPORTED 16 - Config1: comp6Config2: comp11NOT SUPPORTED 17 - Config1: comp6Config2: comp12NOT SUPPORTED 18 - Config1: comp7Config2: comp8 NOT SUPPORTED 19 - Config1: comp7Config2: comp9 SUPPORTED 20 - Config1: comp7Config2: comp10NOT SUPPORTED 21 - Config1: comp7Config2: comp11NOT SUPPORTED 22 - Config1: comp7Config2: comp12NOT SUPPORTED *** AT!UDUSBCOMP=8 (DM, NMEA, MODEM/AT, MBIM) - required preferred configuration MC7304 VID=0x1199 PID=0x68C0 Ordinary firmware (no voice support): SWI9X15C_05.05.67.00 r31378 CARMD-EV-FRMWR1 2016/03/11 14:58:53 Device Descriptor: -- 0x12bLength 0x01bDescriptorType 0x0200 bcdUSB 0x00bDeviceClass 0x00bDeviceSubClass 0x00bDeviceProtocol 0x40bMaxPacketSize0 (64 bytes) 0x1199 idVendor 0x68C0 idProduct 0x0006 bcdDevice 0x01iManufacturer "Sierra Wireless, Incorporated" 0x02iProduct "MC7304" 0x03iSerialNumber "" 0x01bNumConfigurations Device Qualifier Descriptor: -- 0x0AbLength 0x06bDescriptorType 0x0200 bcdUSB 0x00bDeviceClass 0x00bDeviceSubClass 0x00bDeviceProtocol 0x40bMaxPacketSize0 (64 bytes) 0x01bNumConfigurations 0x00bReserved Configuration Descriptor: -- 0x09bLength 0x02bDescriptorType 0x00D8 wTotalLength (216 bytes) 0x05bNumInterfaces 0x01bConfigurationValue 0x00iConfiguration 0xE0bmAttributes (Self-powered Device, Remote-Wakeup) 0xFAbMaxPower (500 mA) Interface Descriptor: -- 0x09bLength 0x04bDescriptorType 0x00bInterfaceNumber 0x00bAlternateSetting 0x02bNumEndPoints 0xFFbInterfaceClass (Vendor specific) 0xFFbInterfaceSubClass 0xFFbInterfaceProtocol 0x00iInterface Endpoint Descriptor: -- 0x07bLength 0x05bDescriptorType 0x81bEndpointAddress (IN endpoint 1) 0x02bmAttributes (Transfer: Bulk / Synch: None / Usage: Data) 0x0200 wMaxPacketSize(512 bytes) 0x00bInterval Endpoint Descriptor: -- 0x07bLength 0x05bDescriptorType 0x01bEndpointAddress (OUT endpoint 1) 0x02bmAttributes (Transfer: Bulk / Synch: None / Usage: Data) 0x0200 wMaxPacketSize(512 bytes) 0x00bInterval Interface Descriptor: -- 0x09bLength 0x04bDescriptorType 0x02bInterfaceNumber 0x00bAlternateSetting 0x03bNumEndPoints 0xFFbInterfaceClass (Vendor specific) 0x00bInterfaceSubClass 0x00bInterfaceProtocol 0x00iInterface Unknown Descriptor: -- 0x05bLength 0x24bDescriptorType Hex dump: 0x05 0x24 0x00 0x10 0x01 Unknown Descriptor: -- 0x05bLength 0x24bDescriptorType Hex dump: 0x05 0x24 0x01 0x00 0x00 Unknown Descriptor: -- 0x04bLength 0x24bDescriptorType Hex dump: 0x04 0x24 0x02 0x02 Unknown Descriptor: -- 0x05bLength 0x24bDescriptorType Hex dump: 0x05 0x24 0x06 0x00 0x00 Endpoint Descriptor: -- 0x07bLength 0x05bDescriptorType 0x83bEndpointAddress (IN endpoint 3) 0x03bmAttributes (Transfer: Interrupt / Synch: None / Usage: Data) 0x000C wMaxPacketSize(1 x 12 bytes) 0x09bInterval (256 microframes) Endpoint Descriptor: -- 0x07bLength 0x05bDescriptorType 0x82bEndpointAddress (IN endpoint 2) 0x02bmAttributes (Transfer: Bulk / Synch: None / Usage: Data) 0x0200 wMaxPacketSize(512 bytes) 0x00bInterval Endpoint Descriptor: -- 0x07bLength 0x05
